From nilesh.javali at qlogic.com  Mon Feb  1 00:17:48 2016
From: nilesh.javali at qlogic.com (Nilesh Javali)
Date: Mon, 1 Feb 2016 08:17:48 +0000
Subject: [PATCH 5/7] scsi: qla4xxx: shut up warning for rd_reg_indirect
In-Reply-To: <1453910247-3447628-6-git-send-email-arnd@arndb.de>
References: <1453910247-3447628-1-git-send-email-arnd@arndb.de>
 <1453910247-3447628-6-git-send-email-arnd@arndb.de>
Message-ID: <D2D511DF.1CBA9%nilesh.javali@qlogic.com>



On 27/01/16 9:27 PM, "Arnd Bergmann" <arnd at arndb.de> wrote:

>The qla4_83xx_rd_reg_indirect() function can fail when it is unable
>to read a register, but not all callers check its return value before
>using the register data, and gcc correctly warns about this:
>
>qla4xxx/ql4_83xx.c: In function 'qla4_83xx_process_reset_template':
>qla4xxx/ql4_83xx.c:1073:36: warning: 'value' may be used uninitialized in
>this function
>     ha->reset_tmplt.array[index++] = value;
>                                    ^
>qla4xxx/ql4_83xx.c:1050:11: note: 'value' was declared here
>  uint32_t value;
>           ^
>qla4xxx/ql4_83xx.c:902:8: warning: 'value' may be used uninitialized in
>this function
>  value &= p_rmw_hdr->test_mask;
>        ^
>qla4xxx/ql4_83xx.c:895:11: note: 'value' was declared here
>  uint32_t value;
>           ^
>In file included from ../include/linux/io.h:25:0,
>                 from ../include/linux/pci.h:31,
>                 from ../drivers/scsi/qla4xxx/ql4_def.h:16,
>                 from ../drivers/scsi/qla4xxx/ql4_83xx.c:10:
>asm/io.h:101:2: warning: 'value' may be used uninitialized in this
>function
>  asm volatile("str %1, %0"
>  ^
>qla4xxx/ql4_83xx.c:874:11: note: 'value' was declared here
>  uint32_t value;
>           ^
>
>Unfortunately, I don't see any helpful way to add proper error handling
>for this case, and the failure scenario for rd_reg seems rather obscure,
>so this bails out and makes the rd_reg accessor set the result to
>0xffffffff
>so we at least get a predictable value.
>
>Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>---
> drivers/scsi/qla4xxx/ql4_83xx.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/scsi/qla4xxx/ql4_83xx.c
>b/drivers/scsi/qla4xxx/ql4_83xx.c
>index 5d4f8e67fb25..638f72c5ab05 100644
>--- a/drivers/scsi/qla4xxx/ql4_83xx.c
>+++ b/drivers/scsi/qla4xxx/ql4_83xx.c
>@@ -46,11 +46,13 @@ int qla4_83xx_rd_reg_indirect(struct scsi_qla_host
>*ha, uint32_t addr,
> 
> 	ret_val = qla4_83xx_set_win_base(ha, addr);
> 
>-	if (ret_val == QLA_SUCCESS)
>+	if (ret_val == QLA_SUCCESS) {
> 		*data = qla4_83xx_rd_reg(ha, QLA83XX_WILDCARD);
>-	else
>+	} else {
>+		*data = 0xffffffff;
> 		ql4_printk(KERN_ERR, ha, "%s: failed read of addr 0x%x!\n",
> 			   __func__, addr);
>+	}
> 
> 	return ret_val;
> }
>-- 
>2.7.0
>

Acked-by: Nilesh Javali <nilesh.javali at qlogic.com>




From zhang.chunyan at linaro.org  Mon Feb  1 00:18:22 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Mon,  1 Feb 2016 16:18:22 +0800
Subject: [PATCH 0/6] Introduce CoreSight STM support
In-Reply-To: <1454313529-8860-1-git-send-email-zhang.chunyan@linaro.org>
References: <1454313529-8860-1-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454314702-9095-1-git-send-email-zhang.chunyan@linaro.org>

This patchset adds support for CoreSight STM IP block. It also makes
a little modification to the generic STM framework to cover the
CoreSight STM requirements. Full description follows the changelog.

Thanks,
Chunyan

Chunyan Zhang (3):
  stm class: Add ioctl get_options interface
  stm class: adds a loop to extract the first valid STM device name
  Documentations: Add explanations of the case for non-configurable
    masters

Mathieu Poirier (2):
  stm class: provision for statically assigned masterIDs
  coresight-stm: Bindings for System Trace Macrocell

Pratik Patel (1):
  coresight-stm: adding driver for CoreSight STM component

 .../ABI/testing/sysfs-bus-coresight-devices-stm    |  53 ++
 .../devicetree/bindings/arm/coresight.txt          |  28 +
 Documentation/trace/coresight.txt                  |  37 +-
 Documentation/trace/stm.txt                        |   6 +
 drivers/hwtracing/coresight/Kconfig                |  11 +
 drivers/hwtracing/coresight/Makefile               |   1 +
 drivers/hwtracing/coresight/coresight-stm.c        | 964 +++++++++++++++++++++
 drivers/hwtracing/stm/core.c                       |  29 +-
 drivers/hwtracing/stm/policy.c                     |  46 +-
 include/linux/coresight-stm.h                      |   6 +
 include/linux/stm.h                                |  11 +
 include/uapi/linux/coresight-stm.h                 |  12 +
 include/uapi/linux/stm.h                           |   1 +
 13 files changed, 1188 insertions(+), 17 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
 create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
 create mode 100644 include/linux/coresight-stm.h
 create mode 100644 include/uapi/linux/coresight-stm.h

-- 
1.9.1



From zhang.chunyan at linaro.org  Mon Feb  1 00:19:09 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Mon,  1 Feb 2016 16:19:09 +0800
Subject: [PATCH 1/6] stm class: Add ioctl get_options interface
In-Reply-To: <1454313529-8860-2-git-send-email-zhang.chunyan@linaro.org>
References: <1454313529-8860-2-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454314749-9149-1-git-send-email-zhang.chunyan@linaro.org>

There is already an interface of set_options, but no get_options yet.
Before setting any options, one would may want to see the current
status of that option by means of get_options interface. This
interface has been used in CoreSight STM driver.

Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 drivers/hwtracing/stm/core.c | 11 +++++++++++
 include/linux/stm.h          |  3 +++
 include/uapi/linux/stm.h     |  1 +
 3 files changed, 15 insertions(+)

diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index b6445d9..86bb4e3 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -571,6 +571,17 @@ stm_char_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 						    options);
 
 		break;
+
+	case STP_GET_OPTIONS:
+		if (stm_data->get_options)
+			err = stm_data->get_options(stm_data,
+						    stmf->output.master,
+						    stmf->output.channel,
+						    stmf->output.nr_chans,
+						    &options);
+
+		return copy_to_user((void __user *)arg, &options, sizeof(u64));
+
 	default:
 		break;
 	}
diff --git a/include/linux/stm.h b/include/linux/stm.h
index 9d0083d..f351d62 100644
--- a/include/linux/stm.h
+++ b/include/linux/stm.h
@@ -88,6 +88,9 @@ struct stm_data {
 	long			(*set_options)(struct stm_data *, unsigned int,
 					       unsigned int, unsigned int,
 					       unsigned long);
+	long			(*get_options)(struct stm_data *, unsigned int,
+					       unsigned int, unsigned int,
+					       u64 *);
 };
 
 int stm_register_device(struct device *parent, struct stm_data *stm_data,
diff --git a/include/uapi/linux/stm.h b/include/uapi/linux/stm.h
index 626a8d3..0dab16e 100644
--- a/include/uapi/linux/stm.h
+++ b/include/uapi/linux/stm.h
@@ -46,5 +46,6 @@ struct stp_policy_id {
 #define STP_POLICY_ID_SET	_IOWR('%', 0, struct stp_policy_id)
 #define STP_POLICY_ID_GET	_IOR('%', 1, struct stp_policy_id)
 #define STP_SET_OPTIONS		_IOW('%', 2, __u64)
+#define STP_GET_OPTIONS		_IOR('%', 3, __u64)
 
 #endif /* _UAPI_LINUX_STM_H */
-- 
1.9.1



From zhang.chunyan at linaro.org  Mon Feb  1 00:19:47 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Mon,  1 Feb 2016 16:19:47 +0800
Subject: [PATCH 2/6] stm class: adds a loop to extract the first valid STM
 device name
In-Reply-To: <1454313529-8860-3-git-send-email-zhang.chunyan@linaro.org>
References: <1454313529-8860-3-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454314787-9199-1-git-send-email-zhang.chunyan@linaro.org>

The node name of STM master management policy is a concatenation of an
STM device name to which this policy applies and following an arbitrary
string, these two strings are concatenated with a dot.

This patch adds a loop for extracting the STM device name when an
arbitrary number of dot(s) are found in this STM device name.

Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 drivers/hwtracing/stm/policy.c | 27 ++++++++++++++++-----------
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
index 11ab6d0..691686e 100644
--- a/drivers/hwtracing/stm/policy.c
+++ b/drivers/hwtracing/stm/policy.c
@@ -321,21 +321,26 @@ stp_policies_make(struct config_group *group, const char *name)
 	/*
 	 * node must look like <device_name>.<policy_name>, where
 	 * <device_name> is the name of an existing stm device and
-	 * <policy_name> is an arbitrary string
+	 * <policy_name> is an arbitrary string, when an arbitrary
+	 * number of dot(s) are found in the <device_name>, the
+	 * first matched STM device name would be extracted.
 	 */
-	p = strchr(devname, '.');
-	if (!p) {
-		kfree(devname);
-		return ERR_PTR(-EINVAL);
-	}
+	for (p = devname; ; p++) {
+		p = strchr(p, '.');
+		if (!p) {
+			kfree(devname);
+			return ERR_PTR(-EINVAL);
+		}
 
-	*p++ = '\0';
+		*p = '\0';
 
-	stm = stm_find_device(devname);
-	kfree(devname);
+		stm = stm_find_device(devname);
+		if (stm)
+			break;
+		*p = '.';
+	};
 
-	if (!stm)
-		return ERR_PTR(-ENODEV);
+	kfree(devname);
 
 	mutex_lock(&stm->policy_mutex);
 	if (stm->policy) {
-- 
1.9.1



From zhang.chunyan at linaro.org  Mon Feb  1 00:20:09 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Mon,  1 Feb 2016 16:20:09 +0800
Subject: [PATCH 3/6] stm class: provision for statically assigned masterIDs
In-Reply-To: <1454313529-8860-4-git-send-email-zhang.chunyan@linaro.org>
References: <1454313529-8860-4-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454314809-9245-1-git-send-email-zhang.chunyan@linaro.org>

From: Mathieu Poirier <mathieu.poirier at linaro.org>

Some architecture like ARM assign masterIDs statically at the HW design
phase, making masterID manipulation in the generic STM core irrelevant.

This patch adds a new 'mstatic' flag to struct stm_data that tells the
core that this specific STM device doesn't need explicit masterID
management.  In the core sw_start/end of masterID are set to '1',
i.e there is only one masterID to deal with.

Also this patch depends on [1], so that the number of masterID
is '1' too.

Finally the lower and upper bound for masterIDs as presented
in ($SYSFS)/class/stm/XYZ.stm/masters and
($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
are set to '-1'.  That way users can't confuse them with
architecture where masterID management is required (where any
other value would be valid).

[1] https://lkml.org/lkml/2015/12/22/348

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 drivers/hwtracing/stm/core.c   | 18 ++++++++++++++++--
 drivers/hwtracing/stm/policy.c | 19 +++++++++++++++++--
 include/linux/stm.h            |  8 ++++++++
 3 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 86bb4e3..cd3dc19 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -44,9 +44,15 @@ static ssize_t masters_show(struct device *dev,
 			    char *buf)
 {
 	struct stm_device *stm = to_stm_device(dev);
-	int ret;
+	int ret, sw_start, sw_end;
+
+	sw_start = stm->data->sw_start;
+	sw_end = stm->data->sw_end;
 
-	ret = sprintf(buf, "%u %u\n", stm->data->sw_start, stm->data->sw_end);
+	if (stm->data->mstatic)
+		sw_start = sw_end = STM_STATIC_MASTERID;
+
+	ret = sprintf(buf, "%d %d\n", sw_start, sw_end);
 
 	return ret;
 }
@@ -629,7 +635,15 @@ int stm_register_device(struct device *parent, struct stm_data *stm_data,
 	if (!stm_data->packet || !stm_data->sw_nchannels)
 		return -EINVAL;
 
+	/*
+	 * MasterIDs are statically set in HW. As such the core is
+	 * using a single master for interaction with this device.
+	 */
+	if (stm_data->mstatic)
+		stm_data->sw_start = stm_data->sw_end = 1;
+
 	nmasters = stm_data->sw_end - stm_data->sw_start;
+
 	stm = kzalloc(sizeof(*stm) + nmasters * sizeof(void *), GFP_KERNEL);
 	if (!stm)
 		return -ENOMEM;
diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
index 691686e..7e70ca2 100644
--- a/drivers/hwtracing/stm/policy.c
+++ b/drivers/hwtracing/stm/policy.c
@@ -80,10 +80,17 @@ static ssize_t
 stp_policy_node_masters_show(struct config_item *item, char *page)
 {
 	struct stp_policy_node *policy_node = to_stp_policy_node(item);
+	struct stm_device *stm = policy_node->policy->stm;
+	int first_master, last_master;
 	ssize_t count;
 
-	count = sprintf(page, "%u %u\n", policy_node->first_master,
-			policy_node->last_master);
+	first_master = policy_node->first_master;
+	last_master = policy_node->last_master;
+
+	if (stm && stm->data->mstatic)
+		first_master = last_master = STM_STATIC_MASTERID;
+
+	count = sprintf(page, "%d %d\n", first_master, last_master);
 
 	return count;
 }
@@ -106,6 +113,13 @@ stp_policy_node_masters_store(struct config_item *item, const char *page,
 	if (!stm)
 		goto unlock;
 
+	/*
+	 * masterIDs are statically allocated in HW, no point in trying to
+	 * change their values.
+	 */
+	if (stm->data->mstatic)
+		goto unlock;
+
 	/* must be within [sw_start..sw_end], which is an inclusive range */
 	if (first > INT_MAX || last > INT_MAX || first > last ||
 	    first < stm->data->sw_start ||
@@ -325,6 +339,7 @@ stp_policies_make(struct config_group *group, const char *name)
 	 * number of dot(s) are found in the <device_name>, the
 	 * first matched STM device name would be extracted.
 	 */
+
 	for (p = devname; ; p++) {
 		p = strchr(p, '.');
 		if (!p) {
diff --git a/include/linux/stm.h b/include/linux/stm.h
index f351d62..c9712a7 100644
--- a/include/linux/stm.h
+++ b/include/linux/stm.h
@@ -18,6 +18,11 @@
 #include <linux/device.h>
 
 /**
+ * The masterIDs are statically set in hardware and can't be queried
+ */
+#define STM_STATIC_MASTERID -1
+
+/**
  * enum stp_packet_type - STP packets that an STM driver sends
  */
 enum stp_packet_type {
@@ -46,6 +51,8 @@ struct stm_device;
  * struct stm_data - STM device description and callbacks
  * @name:		device name
  * @stm:		internal structure, only used by stm class code
+ * @mstatic:		true if masterIDs are assigned in HW.  If so @sw_start
+ *			and @sw_end are set to '1' by the core.
  * @sw_start:		first STP master available to software
  * @sw_end:		last STP master available to software
  * @sw_nchannels:	number of STP channels per master
@@ -71,6 +78,7 @@ struct stm_device;
 struct stm_data {
 	const char		*name;
 	struct stm_device	*stm;
+	bool			mstatic;
 	unsigned int		sw_start;
 	unsigned int		sw_end;
 	unsigned int		sw_nchannels;
-- 
1.9.1



From zhang.chunyan at linaro.org  Mon Feb  1 00:20:35 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Mon,  1 Feb 2016 16:20:35 +0800
Subject: [PATCH 4/6] Documentations: Add explanations of the case for
 non-configurable masters
In-Reply-To: <1454313529-8860-5-git-send-email-zhang.chunyan@linaro.org>
References: <1454313529-8860-5-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454314835-9294-1-git-send-email-zhang.chunyan@linaro.org>

For some STM hardware (e.g. ARM CoreSight STM), the masterID associated
to a source is set at the hardware level and not user configurable.
Since the masterID information isn't available to SW, introducing
a new value of -1 to reflect this reality.

Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 Documentation/trace/stm.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/trace/stm.txt b/Documentation/trace/stm.txt
index ea035f9..f03bc2b 100644
--- a/Documentation/trace/stm.txt
+++ b/Documentation/trace/stm.txt
@@ -47,6 +47,12 @@ through 127 in it. Now, any producer (trace source) identifying itself
 with "user" identification string will be allocated a master and
 channel from within these ranges.
 
+$ cat /config/stp-policy/dummy_stm.my-policy/user/masters
+-1 -1
+
+Would indicate the masters for this rule are set in hardware and
+not configurable in user space.
+
 These rules can be nested, for example, one can define a rule "dummy"
 under "user" directory from the example above and this new rule will
 be used for trace sources with the id string of "user/dummy".
-- 
1.9.1



From zhang.chunyan at linaro.org  Mon Feb  1 00:20:57 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Mon,  1 Feb 2016 16:20:57 +0800
Subject: [PATCH 5/6] coresight-stm: Bindings for System Trace Macrocell
In-Reply-To: <1454313529-8860-6-git-send-email-zhang.chunyan@linaro.org>
References: <1454313529-8860-6-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454314857-9340-1-git-send-email-zhang.chunyan@linaro.org>

From: Mathieu Poirier <mathieu.poirier at linaro.org>

The System Trace Macrocell (STM) is an IP block falling under the
CoreSight umbrella.  It's main purpose it so expose stimulus channels
to any system component for the purpose of information logging.

Bindings for this IP block adds a couple of items to the current
mandatory definition for CoreSight components.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 .../devicetree/bindings/arm/coresight.txt          | 28 ++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
index 62938eb..93147c0c 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -19,6 +19,7 @@ its hardware characteristcs.
 		- "arm,coresight-etm3x", "arm,primecell";
 		- "arm,coresight-etm4x", "arm,primecell";
 		- "qcom,coresight-replicator1x", "arm,primecell";
+		- "arm,coresight-stm", "arm,primecell"; [1]
 
 	* reg: physical base address and length of the register
 	  set(s) of the component.
@@ -36,6 +37,14 @@ its hardware characteristcs.
 	  layout using the generic DT graph presentation found in
 	  "bindings/graph.txt".
 
+* Additional required properties for System Trace Macrocells (STM):
+	* reg: along with the physical base address and length of the register
+	  set as described above, another entry is required to describe the
+	  mapping of the extended stimulus port area.
+
+	* reg-names: the only acceptable values are "stm-base" and
+	  "stm-stimulus-base", each corresponding to the areas defined in "reg".
+
 * Required properties for devices that don't show up on the AMBA bus, such as
   non-configurable replicators:
 
@@ -202,3 +211,22 @@ Example:
 			};
 		};
 	};
+
+4. STM
+	stm at 20100000 {
+		compatible = "arm,coresight-stm", "arm,primecell";
+		reg = <0 0x20100000 0 0x1000>,
+		      <0 0x28000000 0 0x180000>;
+		reg-names = "stm-base", "stm-stimulus-base";
+
+		clocks = <&soc_smc50mhz>;
+		clock-names = "apb_pclk";
+		port {
+			stm_out_port: endpoint {
+				remote-endpoint = <&main_funnel_in_port2>;
+			};
+		};
+	};
+
+[1]. There is currently two version of STM: STM32 and STM500.  Both
+have the same HW interface and as such don't need an explicit binding name.
-- 
1.9.1



From zhang.chunyan at linaro.org  Mon Feb  1 00:21:27 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Mon,  1 Feb 2016 16:21:27 +0800
Subject: [PATCH 6/6] coresight-stm: adding driver for CoreSight STM component
In-Reply-To: <1454313529-8860-7-git-send-email-zhang.chunyan@linaro.org>
References: <1454313529-8860-7-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454314887-9387-1-git-send-email-zhang.chunyan@linaro.org>

From: Pratik Patel <pratikp at codeaurora.org>

This driver adds support for the STM CoreSight IP block, allowing any
system compoment (HW or SW) to log and aggregate messages via a
single entity.

The CoreSight STM exposes an application defined number of channels
called stimulus port. Configuration is done using entries in sysfs
and channels made available to userspace via configfs.

Signed-off-by: Pratik Patel <pratikp at codeaurora.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 .../ABI/testing/sysfs-bus-coresight-devices-stm    |  53 ++
 Documentation/trace/coresight.txt                  |  37 +-
 drivers/hwtracing/coresight/Kconfig                |  11 +
 drivers/hwtracing/coresight/Makefile               |   1 +
 drivers/hwtracing/coresight/coresight-stm.c        | 964 +++++++++++++++++++++
 include/linux/coresight-stm.h                      |   6 +
 include/uapi/linux/coresight-stm.h                 |  12 +
 7 files changed, 1082 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
 create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
 create mode 100644 include/linux/coresight-stm.h
 create mode 100644 include/uapi/linux/coresight-stm.h

diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
new file mode 100644
index 0000000..2ae8624
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
@@ -0,0 +1,53 @@
+What:		/sys/bus/coresight/devices/<memory_map>.stm/enable_source
+Date:		January 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Enable/disable tracing on this specific trace macrocell.
+		Enabling the trace macrocell implies it has been configured
+		properly and a sink has been identidifed for it.  The path
+		of coresight components linking the source to the sink is
+		configured and managed automatically by the coresight framework.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/hwevent_enable
+Date:		January 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Provides access to the HW event enable register, used in
+		conjunction with HW event bank select register.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/hwevent_select
+Date:		January 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Gives access to the HW event block select register
+		(STMHEBSR) in order to configure up to 256 channels.  Used in
+		conjunction with "hwevent_enable" register as described above.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/port_enable
+Date:		January 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Provides access to the stimlus port enable register
+		(STMSPER).  Used in conjunction with "port_select" described
+		below.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/port_select
+Date:		January 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Used to determine which bank of stimulus port bit in
+		register STMSPER (see above) apply to.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/status
+Date:		January 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(R) List various control and status registers.  The specific
+		layout and content is driver specific.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/traceid
+Date:		January 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Holds the trace ID that will appear in the trace stream
+		coming from this trace entity.
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
index 0a5c329..a33c88c 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -190,8 +190,8 @@ expected to be accessed and controlled using those entries.
 Last but not least, "struct module *owner" is expected to be set to reflect
 the information carried in "THIS_MODULE".
 
-How to use
-----------
+How to use the tracer modules
+-----------------------------
 
 Before trace collection can start, a coresight sink needs to be identify.
 There is no limit on the amount of sinks (nor sources) that can be enabled at
@@ -297,3 +297,36 @@ Info                                    Tracing enabled
 Instruction     13570831        0x8026B584      E28DD00C        false   ADD      sp,sp,#0xc
 Instruction     0       0x8026B588      E8BD8000        true    LDM      sp!,{pc}
 Timestamp                                       Timestamp: 17107041535
+
+How to use the STM module
+-------------------------
+
+Using the System Trace Macrocell module is the same as the tracers - the only
+difference is that clients are driving the trace capture rather
+than the program flow through the code.
+
+As with any other CoreSight component, specifics about the STM tracer can be
+found in sysfs with more information on each entry being found in [1]:
+
+root at genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
+enable_source   hwevent_select  port_enable     subsystem       uevent
+hwevent_enable  mgmt            port_select     traceid
+root at genericarmv8:~#
+
+Like any other source a sink needs to be identified and the STM enabled before
+being used:
+
+root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
+root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
+
+From there user space applications can request and use channels using the devfs
+interface provided for that purpose by the generic STM API:
+
+root at genericarmv8:~# ls -l /dev/20100000.stm
+crw-------    1 root     root       10,  61 Jan  3 18:11 /dev/20100000.stm
+root at genericarmv8:~#
+
+Details on how to use the generic STM API can be found here [2].
+
+[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
+[2]. Documentation/trace/stm.txt
diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
index c85935f..f4a8bfa 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -77,4 +77,15 @@ config CORESIGHT_QCOM_REPLICATOR
 	  programmable ATB replicator sends the ATB trace stream from the
 	  ETB/ETF to the TPIUi and ETR.
 
+config CORESIGHT_STM
+	bool "CoreSight System Trace Macrocell driver"
+	depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) || ARM64
+	select CORESIGHT_LINKS_AND_SINKS
+	select STM
+	help
+	  This driver provides support for hardware assisted software
+	  instrumentation based tracing. This is primarily used for
+	  logging useful software events or data coming from various entities
+	  in the system, possibly running different OSs
+
 endif
diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 99f8e5f..1f6eaec 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_CORESIGHT_LINKS_AND_SINKS) += coresight-funnel.o \
 obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o coresight-etm-cp14.o
 obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
 obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
+obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
new file mode 100644
index 0000000..a086fe6
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -0,0 +1,964 @@
+/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Initial implementation by Pratik Patel
+ * (C) 2014-2015 Pratik Patel <pratikp at codeaurora.org>
+ *
+ * Serious refactoring, code cleanup and upgrading to the Coresight upstream
+ * framework by Mathieu Poirier
+ * (C) 2015-2016 Mathieu Poirier <mathieu.poirier at linaro.org>
+ *
+ * Guaranteed timing and support for various packet type coming from the
+ * generic STM API by Chunyan Zhang
+ * (C) 2015-2016 Chunyan Zhang <zhang.chunyan at linaro.org>
+ */
+#include <linux/amba/bus.h>
+#include <linux/bitmap.h>
+#include <linux/clk.h>
+#include <linux/coresight.h>
+#include <linux/coresight-stm.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/pm_runtime.h>
+#include <linux/stm.h>
+
+#include "coresight-priv.h"
+
+#define STMDMASTARTR			0xc04
+#define STMDMASTOPR			0xc08
+#define STMDMASTATR			0xc0c
+#define STMDMACTLR			0xc10
+#define STMDMAIDR			0xcfc
+#define STMHEER				0xd00
+#define STMHETER			0xd20
+#define STMHEBSR			0xd60
+#define STMHEMCR			0xd64
+#define STMHEMASTR			0xdf4
+#define STMHEFEAT1R			0xdf8
+#define STMHEIDR			0xdfc
+#define STMSPER				0xe00
+#define STMSPTER			0xe20
+#define STMPRIVMASKR			0xe40
+#define STMSPSCR			0xe60
+#define STMSPMSCR			0xe64
+#define STMSPOVERRIDER			0xe68
+#define STMSPMOVERRIDER			0xe6c
+#define STMSPTRIGCSR			0xe70
+#define STMTCSR				0xe80
+#define STMTSSTIMR			0xe84
+#define STMTSFREQR			0xe8c
+#define STMSYNCR			0xe90
+#define STMAUXCR			0xe94
+#define STMSPFEAT1R			0xea0
+#define STMSPFEAT2R			0xea4
+#define STMSPFEAT3R			0xea8
+#define STMITTRIGGER			0xee8
+#define STMITATBDATA0			0xeec
+#define STMITATBCTR2			0xef0
+#define STMITATBID			0xef4
+#define STMITATBCTR0			0xef8
+
+#define STM_32_CHANNEL			32
+#define BYTES_PER_CHANNEL		256
+#define STM_TRACE_BUF_SIZE		4096
+#define STM_SW_MASTER_END		127
+
+/* Register bit definition */
+#define STMTCSR_BUSY_BIT		23
+/* Reserve the first 10 channels for kernel usage */
+#define STM_CHANNEL_OFFSET		0
+
+enum stm_pkt_type {
+	STM_PKT_TYPE_DATA	= 0x98,
+	STM_PKT_TYPE_FLAG	= 0xE8,
+	STM_PKT_TYPE_TRIG	= 0xF8,
+};
+
+#define stm_channel_addr(drvdata, ch)	(drvdata->chs.base +	\
+					(ch * BYTES_PER_CHANNEL))
+#define stm_channel_off(type, opts)	(type & ~opts)
+
+#ifndef CONFIG_64BIT
+static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
+{
+	asm volatile("strd %1, %0"
+		     : "+Qo" (*(volatile u64 __force *)addr)
+		     : "r" (val));
+}
+#undef writeq_relaxed
+#define writeq_relaxed(v, c)	__raw_writeq((__force u64) cpu_to_le64(v), c)
+#endif
+
+static int boot_nr_channel;
+
+module_param_named(
+	boot_nr_channel, boot_nr_channel, int, S_IRUGO
+);
+
+/**
+ * struct channel_space - central management entity for extended ports
+ * @base:		memory mapped base address where channels start.
+ * @guaraneed:		is the channel delivery guaranteed.
+ */
+struct channel_space {
+	void __iomem		*base;
+	unsigned long		*guaranteed;
+};
+
+/**
+ * struct stm_drvdata - specifics associated to an STM component
+ * @base:		memory mapped base address for this component.
+ * @dev:		the device entity associated to this component.
+ * @atclk:		optional clock for the core parts of the STM.
+ * @csdev:		component vitals needed by the framework.
+ * @spinlock:		only one at a time pls.
+ * @chs:		the channels accociated to this STM.
+ * @stm:		structure associated to the generic STM interface.
+ * @enable:		this STM is being used.
+ * @traceid:		value of the current ID for this component.
+ * @write_64bit:	whether this STM supports 64 bit access.
+ * @stmsper:		settings for register STMSPER.
+ * @stmspscr:		settings for register STMSPSCR.
+ * @numsp:		the total number of stimulus port support by this STM.
+ * @stmheer:		settings for register STMHEER.
+ * @stmheter:		settings for register STMHETER.
+ * @stmhebsr:		settings for register STMHEBSR.
+ */
+struct stm_drvdata {
+	void __iomem		*base;
+	struct device		*dev;
+	struct clk		*atclk;
+	struct coresight_device	*csdev;
+	spinlock_t		spinlock;
+	struct channel_space	chs;
+	struct stm_data		stm;
+	bool			enable;
+	u8			traceid;
+	u32			write_64bit;
+	u32			stmsper;
+	u32			stmspscr;
+	u32			numsp;
+	u32			stmheer;
+	u32			stmheter;
+	u32			stmhebsr;
+};
+
+static void stm_hwevent_enable_hw(struct stm_drvdata *drvdata)
+{
+	CS_UNLOCK(drvdata->base);
+
+	writel_relaxed(drvdata->stmhebsr, drvdata->base + STMHEBSR);
+	writel_relaxed(drvdata->stmheter, drvdata->base + STMHETER);
+	writel_relaxed(drvdata->stmheer, drvdata->base + STMHEER);
+	writel_relaxed(0x01 |	/* Enable HW event tracing */
+		       0x04,	/* Error detection on event tracing */
+		       drvdata->base + STMHEMCR);
+
+	CS_LOCK(drvdata->base);
+}
+
+static void stm_port_enable_hw(struct stm_drvdata *drvdata)
+{
+	CS_UNLOCK(drvdata->base);
+	/* ATB trigger enable on direct writes to TRIG locations */
+	writel_relaxed(0x10,
+		       drvdata->base + STMSPTRIGCSR);
+	writel_relaxed(drvdata->stmspscr, drvdata->base + STMSPSCR);
+	writel_relaxed(drvdata->stmsper, drvdata->base + STMSPER);
+
+	CS_LOCK(drvdata->base);
+}
+
+static void stm_enable_hw(struct stm_drvdata *drvdata)
+{
+	if (drvdata->stmheer)
+		stm_hwevent_enable_hw(drvdata);
+
+	stm_port_enable_hw(drvdata);
+
+	CS_UNLOCK(drvdata->base);
+
+	/* 4096 byte between synchronisation packets */
+	writel_relaxed(0xFFF, drvdata->base + STMSYNCR);
+	writel_relaxed((drvdata->traceid << 16 | /* trace id */
+			0x02 |			 /* timestamp enable */
+			0x01),			 /* global STM enable */
+			drvdata->base + STMTCSR);
+
+	CS_LOCK(drvdata->base);
+}
+
+static int stm_enable(struct coresight_device *csdev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	pm_runtime_get_sync(drvdata->dev);
+
+	spin_lock(&drvdata->spinlock);
+	stm_enable_hw(drvdata);
+	drvdata->enable = true;
+	spin_unlock(&drvdata->spinlock);
+
+	dev_info(drvdata->dev, "STM tracing enabled\n");
+	return 0;
+}
+
+static void stm_hwevent_disable_hw(struct stm_drvdata *drvdata)
+{
+	CS_UNLOCK(drvdata->base);
+
+	writel_relaxed(0x0, drvdata->base + STMHEMCR);
+	writel_relaxed(0x0, drvdata->base + STMHEER);
+	writel_relaxed(0x0, drvdata->base + STMHETER);
+
+	CS_LOCK(drvdata->base);
+}
+
+static void stm_port_disable_hw(struct stm_drvdata *drvdata)
+{
+	CS_UNLOCK(drvdata->base);
+
+	writel_relaxed(0x0, drvdata->base + STMSPER);
+	writel_relaxed(0x0, drvdata->base + STMSPTRIGCSR);
+
+	CS_LOCK(drvdata->base);
+}
+
+static void stm_disable_hw(struct stm_drvdata *drvdata)
+{
+	u32 val;
+
+	CS_UNLOCK(drvdata->base);
+
+	val = readl_relaxed(drvdata->base + STMTCSR);
+	val &= ~0x1; /* clear global STM enable [0] */
+	writel_relaxed(val, drvdata->base + STMTCSR);
+
+	CS_LOCK(drvdata->base);
+
+	stm_port_disable_hw(drvdata);
+	if (drvdata->stmheer)
+		stm_hwevent_disable_hw(drvdata);
+}
+
+static void stm_disable(struct coresight_device *csdev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	spin_lock(&drvdata->spinlock);
+	stm_disable_hw(drvdata);
+	drvdata->enable = false;
+	spin_unlock(&drvdata->spinlock);
+
+	/* Wait until the engine has completely stopped */
+	coresight_timeout(drvdata, STMTCSR, STMTCSR_BUSY_BIT, 0);
+
+	pm_runtime_put(drvdata->dev);
+
+	dev_info(drvdata->dev, "STM tracing disabled\n");
+}
+
+static int stm_trace_id(struct coresight_device *csdev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	return drvdata->traceid;
+}
+
+static const struct coresight_ops_source stm_source_ops = {
+	.trace_id	= stm_trace_id,
+	.enable		= stm_enable,
+	.disable	= stm_disable,
+};
+
+static const struct coresight_ops stm_cs_ops = {
+	.source_ops	= &stm_source_ops,
+};
+
+static int stm_send_64bit(void *addr, const void *data, u32 size)
+{
+	u64 prepad = 0;
+	u64 postpad = 0;
+	char *pad;
+	u8 off, endoff;
+	u32 len = size;
+
+	off = (unsigned long)data & 0x7;
+
+	if (off) {
+		endoff = 8 - off;
+		pad = (char *)&prepad;
+		pad += off;
+
+		while (endoff && size) {
+			*pad++ = *(char *)data++;
+			endoff--;
+			size--;
+		}
+		writeq_relaxed(prepad, addr);
+	}
+
+	/* now we are 64bit aligned */
+	while (size >= 8) {
+		writeq_relaxed(*(u64 *)data, addr);
+		data += 8;
+		size -= 8;
+	}
+
+	endoff = 0;
+
+	if (size) {
+		endoff = 8 - (u8)size;
+		pad = (char *)&postpad;
+
+		while (size) {
+			*pad++ = *(char *)data++;
+			size--;
+		}
+		writeq_relaxed(postpad, addr);
+	}
+
+	return len + off + endoff;
+}
+
+static int stm_send(void *addr, const void *data, u32 size)
+{
+	u32 len = size;
+
+	if (((unsigned long)data & 0x1) && (size >= 1)) {
+		writeb_relaxed(*(u8 *)data, addr);
+		data++;
+		size--;
+	}
+	if (((unsigned long)data & 0x2) && (size >= 2)) {
+		writew_relaxed(*(u16 *)data, addr);
+		data += 2;
+		size -= 2;
+	}
+
+	/* now we are 32bit aligned */
+	while (size >= 4) {
+		writel_relaxed(*(u32 *)data, addr);
+		data += 4;
+		size -= 4;
+	}
+
+	if (size >= 2) {
+		writew_relaxed(*(u16 *)data, addr);
+		data += 2;
+		size -= 2;
+	}
+	if (size >= 1) {
+		writeb_relaxed(*(u8 *)data, addr);
+		data++;
+		size--;
+	}
+
+	return len;
+}
+
+static int stm_generic_link(struct stm_data *stm_data,
+			    unsigned int master,  unsigned int channel)
+{
+	struct stm_drvdata *drvdata = container_of(stm_data,
+						   struct stm_drvdata, stm);
+	if (!drvdata || !drvdata->csdev)
+		return -EINVAL;
+
+	return coresight_enable(drvdata->csdev);
+}
+
+static void stm_generic_unlink(struct stm_data *stm_data,
+			       unsigned int master,  unsigned int channel)
+{
+	struct stm_drvdata *drvdata = container_of(stm_data,
+						   struct stm_drvdata, stm);
+	if (!drvdata || !drvdata->csdev)
+		return;
+
+	stm_disable(drvdata->csdev);
+}
+
+static long stm_generic_set_options(struct stm_data *stm_data,
+				    unsigned int master,
+				    unsigned int channel,
+				    unsigned int nr_chans,
+				    unsigned long options)
+{
+	struct stm_drvdata *drvdata = container_of(stm_data,
+						   struct stm_drvdata, stm);
+	if (!(drvdata && drvdata->enable))
+		return -EINVAL;
+
+	if (channel >= drvdata->numsp)
+		return -EINVAL;
+
+	switch (options) {
+	case STM_OPTION_GUARANTEED:
+		set_bit(channel, drvdata->chs.guaranteed);
+		break;
+
+	case STM_OPTION_INVARIANT:
+		clear_bit(channel, drvdata->chs.guaranteed);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static long stm_generic_get_options(struct stm_data *stm_data,
+				    unsigned int master,
+				    unsigned int channel,
+				    unsigned int nr_chans,
+				    u64 *options)
+{
+	struct stm_drvdata *drvdata = container_of(stm_data,
+						   struct stm_drvdata, stm);
+	if (!(drvdata && drvdata->enable))
+		return -EINVAL;
+
+	if (channel >= drvdata->numsp)
+		return -EINVAL;
+
+	switch (*options) {
+	case STM_OPTION_GUARANTEED:
+		*options = test_bit(channel, drvdata->chs.guaranteed);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static ssize_t stm_generic_packet(struct stm_data *stm_data,
+				  unsigned int master,
+				  unsigned int channel,
+				  unsigned int packet,
+				  unsigned int flags,
+				  unsigned int size,
+				  const unsigned char *payload)
+{
+	unsigned int len = size;
+	unsigned long ch_addr;
+	struct stm_drvdata *drvdata = container_of(stm_data,
+						   struct stm_drvdata, stm);
+	if (!(drvdata && drvdata->enable))
+		return 0;
+
+	if (channel >= drvdata->numsp)
+		return 0;
+
+	ch_addr = (unsigned long)stm_channel_addr(drvdata, channel);
+
+	flags = (flags == STP_PACKET_TIMESTAMPED) ? STM_FLAG_TIMESTAMPED : 0;
+	flags |= test_bit(channel, drvdata->chs.guaranteed) ?
+			   STM_FLAG_GUARANTEED : 0;
+
+	switch (packet) {
+	case STP_PACKET_FLAG:
+		ch_addr |= stm_channel_off(STM_PKT_TYPE_FLAG, flags);
+
+		/* the generic STM API set a size of zero on flag packets. */
+		len = 1;
+		break;
+
+	case STP_PACKET_DATA:
+		ch_addr |= stm_channel_off(STM_PKT_TYPE_DATA, flags);
+		break;
+
+	default:
+		return 0;
+	}
+
+	if (drvdata->write_64bit)
+		return stm_send_64bit((void *)ch_addr, payload, len);
+
+	return stm_send((void *)ch_addr, payload, len);
+}
+
+static ssize_t hwevent_enable_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val = drvdata->stmheer;
+
+	return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
+}
+
+static ssize_t hwevent_enable_store(struct device *dev,
+				    struct device_attribute *attr,
+				    const char *buf, size_t size)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val;
+	int ret = 0;
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return -EINVAL;
+
+	drvdata->stmheer = val;
+	/* HW event enable and trigger go hand in hand */
+	drvdata->stmheter = val;
+
+	return size;
+}
+static DEVICE_ATTR_RW(hwevent_enable);
+
+static ssize_t hwevent_select_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val = drvdata->stmhebsr;
+
+	return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
+}
+
+static ssize_t hwevent_select_store(struct device *dev,
+				    struct device_attribute *attr,
+				    const char *buf, size_t size)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val;
+	int ret = 0;
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return -EINVAL;
+
+	drvdata->stmhebsr = val;
+
+	return size;
+}
+static DEVICE_ATTR_RW(hwevent_select);
+
+static ssize_t port_select_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val;
+
+	if (!drvdata->enable) {
+		val = drvdata->stmspscr;
+	} else {
+		spin_lock(&drvdata->spinlock);
+		val = readl_relaxed(drvdata->base + STMSPSCR);
+		spin_unlock(&drvdata->spinlock);
+	}
+
+	return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
+}
+
+static ssize_t port_select_store(struct device *dev,
+				 struct device_attribute *attr,
+				 const char *buf, size_t size)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val, stmsper;
+	int ret = 0;
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->stmspscr = val;
+
+	if (drvdata->enable) {
+		CS_UNLOCK(drvdata->base);
+		/* Process as per ARM's TRM recommendation */
+		stmsper = readl_relaxed(drvdata->base + STMSPER);
+		writel_relaxed(0x0, drvdata->base + STMSPER);
+		writel_relaxed(drvdata->stmspscr, drvdata->base + STMSPSCR);
+		writel_relaxed(stmsper, drvdata->base + STMSPER);
+		CS_LOCK(drvdata->base);
+	}
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(port_select);
+
+static ssize_t port_enable_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val;
+
+	if (!drvdata->enable) {
+		val = drvdata->stmsper;
+	} else {
+		spin_lock(&drvdata->spinlock);
+		val = readl_relaxed(drvdata->base + STMSPER);
+		spin_unlock(&drvdata->spinlock);
+	}
+
+	return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
+}
+
+static ssize_t port_enable_store(struct device *dev,
+				 struct device_attribute *attr,
+				 const char *buf, size_t size)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val;
+	int ret = 0;
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->stmsper = val;
+
+	if (drvdata->enable) {
+		CS_UNLOCK(drvdata->base);
+		writel_relaxed(drvdata->stmsper, drvdata->base + STMSPER);
+		CS_LOCK(drvdata->base);
+	}
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(port_enable);
+
+static ssize_t traceid_show(struct device *dev,
+			    struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->traceid;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t traceid_store(struct device *dev,
+			     struct device_attribute *attr,
+			     const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	/* traceid field is 7bit wide on STM32 */
+	drvdata->traceid = val & 0x7f;
+	return size;
+}
+static DEVICE_ATTR_RW(traceid);
+
+#define coresight_stm_simple_func(name, offset)	\
+	coresight_simple_func(struct stm_drvdata, name, offset)
+
+coresight_stm_simple_func(tcsr, STMTCSR);
+coresight_stm_simple_func(tsfreqr, STMTSFREQR);
+coresight_stm_simple_func(syncr, STMSYNCR);
+coresight_stm_simple_func(sper, STMSPER);
+coresight_stm_simple_func(spter, STMSPTER);
+coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
+coresight_stm_simple_func(spscr, STMSPSCR);
+coresight_stm_simple_func(spmscr, STMSPMSCR);
+coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
+coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
+coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
+coresight_stm_simple_func(devid, CORESIGHT_DEVID);
+
+static struct attribute *coresight_stm_attrs[] = {
+	&dev_attr_hwevent_enable.attr,
+	&dev_attr_hwevent_select.attr,
+	&dev_attr_port_enable.attr,
+	&dev_attr_port_select.attr,
+	&dev_attr_traceid.attr,
+	NULL,
+};
+
+static struct attribute *coresight_stm_mgmt_attrs[] = {
+	&dev_attr_tcsr.attr,
+	&dev_attr_tsfreqr.attr,
+	&dev_attr_syncr.attr,
+	&dev_attr_sper.attr,
+	&dev_attr_spter.attr,
+	&dev_attr_privmaskr.attr,
+	&dev_attr_spscr.attr,
+	&dev_attr_spmscr.attr,
+	&dev_attr_spfeat1r.attr,
+	&dev_attr_spfeat2r.attr,
+	&dev_attr_spfeat3r.attr,
+	&dev_attr_devid.attr,
+	NULL,
+};
+
+static const struct attribute_group coresight_stm_group = {
+	.attrs = coresight_stm_attrs,
+};
+
+static const struct attribute_group coresight_stm_mgmt_group = {
+	.attrs = coresight_stm_mgmt_attrs,
+	.name = "mgmt",
+};
+
+static const struct attribute_group *coresight_stm_groups[] = {
+	&coresight_stm_group,
+	&coresight_stm_mgmt_group,
+	NULL,
+};
+
+static int stm_get_resource_byname(struct device_node *np,
+				   char *ch_base, struct resource *res)
+{
+	const char *name = NULL;
+	int index = 0, found = 0;
+
+	while (!of_property_read_string_index(np, "reg-names", index, &name)) {
+		if (strcmp(ch_base, name)) {
+			index++;
+			continue;
+		}
+
+		/* We have a match and @index is where it's at */
+		found = 1;
+		break;
+	}
+
+	if (!found)
+		return -EINVAL;
+
+	return of_address_to_resource(np, index, res);
+}
+
+static u32 stm_fundamental_data_size(struct stm_drvdata *drvdata)
+{
+	u32 stmspfeat2r;
+
+	stmspfeat2r = readl_relaxed(drvdata->base + STMSPFEAT2R);
+	return BMVAL(stmspfeat2r, 12, 15);
+}
+
+static u32 stm_num_stimulus_port(struct stm_drvdata *drvdata)
+{
+	u32 numsp;
+
+	numsp = readl_relaxed(drvdata->base + CORESIGHT_DEVID);
+	/*
+	 * NUMPS in STMDEVID is 17 bit long and if equal to 0x0,
+	 * 32 stimulus ports are supported.
+	 */
+	numsp &= 0x1ffff;
+	if (!numsp)
+		numsp = STM_32_CHANNEL;
+	return numsp;
+}
+
+static void stm_init_default_data(struct stm_drvdata *drvdata)
+{
+	/* Don't use port selection */
+	drvdata->stmspscr = 0x0;
+	/*
+	 * Enable all channel regardless of their number.  When port
+	 * selection isn't used (see above) STMSPER applies to all
+	 * 32 channel group available, hence setting all 32 bits to 1
+	 */
+	drvdata->stmsper = ~0x0;
+
+	/*
+	 * Select arbitrary value to start with.  If there is a conflict
+	 * with other tracers the framework will deal with it.
+	 */
+	drvdata->traceid = 0x20;
+
+	/* Set invariant transaction timing on all channels */
+	bitmap_clear(drvdata->chs.guaranteed, 0, drvdata->numsp);
+}
+
+static void stm_init_generic_data(struct stm_drvdata *drvdata)
+{
+	drvdata->stm.name = dev_name(drvdata->dev);
+	drvdata->stm.mstatic = true;
+	drvdata->stm.sw_nchannels = drvdata->numsp;
+	drvdata->stm.packet = stm_generic_packet;
+	drvdata->stm.link = stm_generic_link;
+	drvdata->stm.unlink = stm_generic_unlink;
+	drvdata->stm.set_options = stm_generic_set_options;
+	drvdata->stm.get_options = stm_generic_get_options;
+}
+
+static int stm_probe(struct amba_device *adev, const struct amba_id *id)
+{
+	int ret;
+	void __iomem *base;
+	unsigned long *guaranteed;
+	struct device *dev = &adev->dev;
+	struct coresight_platform_data *pdata = NULL;
+	struct stm_drvdata *drvdata;
+	struct resource *res = &adev->res;
+	struct resource ch_res;
+	size_t res_size, bitmap_size;
+	struct coresight_desc *desc;
+	struct device_node *np = adev->dev.of_node;
+
+	if (np) {
+		pdata = of_get_coresight_platform_data(dev, np);
+		if (IS_ERR(pdata))
+			return PTR_ERR(pdata);
+		adev->dev.platform_data = pdata;
+	}
+	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+
+	drvdata->dev = &adev->dev;
+	drvdata->atclk = devm_clk_get(&adev->dev, "atclk"); /* optional */
+	if (!IS_ERR(drvdata->atclk)) {
+		ret = clk_prepare_enable(drvdata->atclk);
+		if (ret)
+			return ret;
+	}
+	dev_set_drvdata(dev, drvdata);
+
+	base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+	drvdata->base = base;
+
+	ret = stm_get_resource_byname(np, "stm-stimulus-base", &ch_res);
+	if (ret)
+		return ret;
+
+	base = devm_ioremap_resource(dev, &ch_res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+	drvdata->chs.base = base;
+
+	drvdata->write_64bit = stm_fundamental_data_size(drvdata);
+
+	if (boot_nr_channel) {
+		drvdata->numsp = boot_nr_channel;
+		res_size = min((resource_size_t)(boot_nr_channel *
+				  BYTES_PER_CHANNEL), resource_size(res));
+	} else {
+		drvdata->numsp = stm_num_stimulus_port(drvdata);
+		res_size = min((resource_size_t)(drvdata->numsp *
+				 BYTES_PER_CHANNEL), resource_size(res));
+	}
+	bitmap_size = BITS_TO_LONGS(drvdata->numsp) * sizeof(long);
+
+	guaranteed = devm_kzalloc(dev, bitmap_size, GFP_KERNEL);
+	if (!guaranteed)
+		return -ENOMEM;
+	drvdata->chs.guaranteed = guaranteed;
+
+	spin_lock_init(&drvdata->spinlock);
+
+	stm_init_default_data(drvdata);
+	stm_init_generic_data(drvdata);
+
+	if (stm_register_device(dev, &drvdata->stm, THIS_MODULE)) {
+		dev_info(dev, "stm_register_device failed, probing deffered\n");
+		return -EPROBE_DEFER;
+	}
+
+	desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
+	if (!desc) {
+		ret = -ENOMEM;
+		goto stm_unregister;
+	}
+
+	desc->type = CORESIGHT_DEV_TYPE_SOURCE;
+	desc->subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE;
+	desc->ops = &stm_cs_ops;
+	desc->pdata = pdata;
+	desc->dev = dev;
+	desc->groups = coresight_stm_groups;
+	drvdata->csdev = coresight_register(desc);
+	if (IS_ERR(drvdata->csdev)) {
+		ret = PTR_ERR(drvdata->csdev);
+		goto stm_unregister;
+	}
+
+	pm_runtime_put(&adev->dev);
+
+	dev_info(dev, "%s initialized\n", (char *)id->data);
+	return 0;
+
+stm_unregister:
+	stm_unregister_device(&drvdata->stm);
+	return ret;
+}
+
+static int stm_remove(struct amba_device *adev)
+{
+	struct stm_drvdata *drvdata = amba_get_drvdata(adev);
+
+	stm_unregister_device(&drvdata->stm);
+	coresight_unregister(drvdata->csdev);
+	return 0;
+}
+
+#ifdef CONFIG_PM
+static int stm_runtime_suspend(struct device *dev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev);
+
+	if (drvdata && !IS_ERR(drvdata->atclk))
+		clk_disable_unprepare(drvdata->atclk);
+
+	return 0;
+}
+
+static int stm_runtime_resume(struct device *dev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev);
+
+	if (drvdata && !IS_ERR(drvdata->atclk))
+		clk_prepare_enable(drvdata->atclk);
+
+	return 0;
+}
+#endif
+
+static const struct dev_pm_ops stm_dev_pm_ops = {
+	SET_RUNTIME_PM_OPS(stm_runtime_suspend, stm_runtime_resume, NULL)
+};
+
+static struct amba_id stm_ids[] = {
+	{
+		.id     = 0x0003b962,
+		.mask   = 0x0003ffff,
+		.data	= "STM32",
+	},
+	{ 0, 0},
+};
+
+static struct amba_driver stm_driver = {
+	.drv = {
+		.name   = "coresight-stm",
+		.owner	= THIS_MODULE,
+		.pm	= &stm_dev_pm_ops,
+	},
+	.probe          = stm_probe,
+	.remove         = stm_remove,
+	.id_table	= stm_ids,
+};
+
+module_amba_driver(stm_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("CoreSight System Trace Macrocell driver");
diff --git a/include/linux/coresight-stm.h b/include/linux/coresight-stm.h
new file mode 100644
index 0000000..a978bb8
--- /dev/null
+++ b/include/linux/coresight-stm.h
@@ -0,0 +1,6 @@
+#ifndef __LINUX_CORESIGHT_STM_H_
+#define __LINUX_CORESIGHT_STM_H_
+
+#include <uapi/linux/coresight-stm.h>
+
+#endif
diff --git a/include/uapi/linux/coresight-stm.h b/include/uapi/linux/coresight-stm.h
new file mode 100644
index 0000000..fa35f0b
--- /dev/null
+++ b/include/uapi/linux/coresight-stm.h
@@ -0,0 +1,12 @@
+#ifndef __UAPI_CORESIGHT_STM_H_
+#define __UAPI_CORESIGHT_STM_H_
+
+#define STM_FLAG_TIMESTAMPED   BIT(3)
+#define STM_FLAG_GUARANTEED    BIT(7)
+
+enum {
+	STM_OPTION_GUARANTEED = 0,
+	STM_OPTION_INVARIANT,
+};
+
+#endif
-- 
1.9.1



From herbert at gondor.apana.org.au  Mon Feb  1 00:22:01 2016
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Mon, 1 Feb 2016 16:22:01 +0800
Subject: [PATCH v2] crypto: atmel-sha: fix algorihtm registration
In-Reply-To: <da09591cf85a1882817bbf7cb527bb228d3f8f87.1454082992.git.cyrille.pitchen@atmel.com>
References: <da09591cf85a1882817bbf7cb527bb228d3f8f87.1454082992.git.cyrille.pitchen@atmel.com>
Message-ID: <20160201082201.GE5818@gondor.apana.org.au>

On Fri, Jan 29, 2016 at 05:04:02PM +0100, Cyrille Pitchen wrote:
> This patch implements the missing .import() and .export() mandatory
> hooks for asynchronous hash algorithms. It also sets the relevant, non
> zero, value for the .statesize field when declaring the supported SHA
> algorithms. Indeed a zero value of .statesize prevents the algorithm from
> being registered.
> 
> Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>

Applied.
-- 
Email: Herbert Xu <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From herbert at gondor.apana.org.au  Mon Feb  1 00:22:13 2016
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Mon, 1 Feb 2016 16:22:13 +0800
Subject: [PATCH] crypto: atmel-aes - remove calls of clk_prepare() from
 atomic contexts
In-Reply-To: <f8f0ac52fcfbbef5cbddb2a189128b253df7d678.1454086302.git.cyrille.pitchen@atmel.com>
References: <f8f0ac52fcfbbef5cbddb2a189128b253df7d678.1454086302.git.cyrille.pitchen@atmel.com>
Message-ID: <20160201082213.GF5818@gondor.apana.org.au>

On Fri, Jan 29, 2016 at 05:53:33PM +0100, Cyrille Pitchen wrote:
> clk_prepare()/clk_unprepare() must not be called within atomic context.
> 
> This patch calls clk_prepare() once for all from atmel_aes_probe() and
> clk_unprepare() from atmel_aes_remove().
> 
> Then calls of clk_prepare_enable()/clk_disable_unprepare() were replaced
> by calls of clk_enable()/clk_disable().
> 
> Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
> Reported-by: Matthias Mayr <matthias.mayr at student.kit.edu>

Applied to crypto.
-- 
Email: Herbert Xu <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From lee.jones at linaro.org  Mon Feb  1 00:22:45 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 1 Feb 2016 08:22:45 +0000
Subject: [PATCH 3/3] clk: Provide OF helper to mark clocks as CRITICAL
In-Reply-To: <20160201063256.GE32462@lukather>
References: <1453127331-20616-1-git-send-email-lee.jones@linaro.org>
 <1453127331-20616-4-git-send-email-lee.jones@linaro.org>
 <56A95811.8010200@arm.com> <20160201063256.GE32462@lukather>
Message-ID: <20160201082245.GV3368@x1>

On Mon, 01 Feb 2016, Maxime Ripard wrote:
> On Wed, Jan 27, 2016 at 11:51:45PM +0000, Andr? Przywara wrote:
> > Hi,
> > 
> > On 18/01/16 14:28, Lee Jones wrote:
> > > This call matches clocks which have been marked as critical in DT
> > > and sets the appropriate flag.  These flags can then be used to
> > > mark the clock core flags appropriately prior to registration.
> > 
> > I like the idea of having a generic property very much. Also this solves
> > a problem I have in a very elegant way.
> 
> Not really. It has a significant set of drawbacks that we already
> detailed in the initial thread, which are mostly related to the fact
> that the clocks are to be left on is something that totally depends on
> the software support in the kernel. Some clocks should be reported as
> critical because they are simply missing a driver for it, some should
> be because the driver for it as not been compiled, some should because
> we don't have the proper clocks drivers yet for one of their
> downstream clocks.

Exactly.  This is a not a CLK_DRIVER_NOT_{AUTHORED|UPSTREAM} or
CLK_DRIVER_NOT_ENABLED implementation, it's for CLK_CRITICALs.
Critical clocks must _never_ be turned off, no matter what, else
something really bad will happen.  In our use-case, if the clocks are
turned of, it will be catastrophic to the running system.

> Basically, it all boils down to this: some clocks should never ever be
> shutdown because <hardware reason>, and I believe it's the case Lee is
> in. But most of the current code that would use it might, and might
> even need at some point to shut down such a clock.
> 
> Mike's solution with the flags + handover was solving all this, I'm
> not sure why he's not pushed it forward.

Right, but I think you are missing part of the conversation.  Mike and
I had a face-to-face meeting in San Francisco last year.  The
conclusion was that the CLK_CRITICAL and CLK_HANDOVER solutions should
be separated.  Different handling, different code.  This submission
only solves the former problem.  I believe Mike was going to submit
and follow-up on the CLK_HANDOVER solution separately.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From shawn.lin at rock-chips.com  Mon Feb  1 00:18:40 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Mon,  1 Feb 2016 16:18:40 +0800
Subject: [PATCH] soc: rockchip: power-domain: fix err handle while probing
Message-ID: <1454314720-6391-1-git-send-email-shawn.lin@rock-chips.com>

If we fail to probe the driver, we should not directly break
from the for_each_available_child_of_node since it calls of_node_get
while iterating. This patch add of_node_put to fix the unbalanced
call pair.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
---

 drivers/soc/rockchip/pm_domains.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 534c589..4a65c5b 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -419,6 +419,7 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
 		if (error) {
 			dev_err(dev, "failed to handle node %s: %d\n",
 				node->name, error);
+			of_node_put(node);
 			goto err_out;
 		}
 	}
-- 
2.3.7




From blogic at openwrt.org  Mon Feb  1 00:25:32 2016
From: blogic at openwrt.org (John Crispin)
Date: Mon, 1 Feb 2016 09:25:32 +0100
Subject: [PATCH V4 09/11] soc: mediatek: PMIC wrap: add a slave specific
 struct
In-Reply-To: <1453948660.29651.3.camel@mtksdaap41>
References: <1453894149-44127-1-git-send-email-blogic@openwrt.org>
 <1453894149-44127-9-git-send-email-blogic@openwrt.org>
 <1453948660.29651.3.camel@mtksdaap41>
Message-ID: <56AF167C.5030501@openwrt.org>



On 28/01/2016 03:37, Henry Chen wrote:
> Hi John,
> 
> On Wed, 2016-01-27 at 12:29 +0100, John Crispin wrote:
> 
>> @@ -746,7 +786,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
>>  	pwrap_writel(wrp, 1, PWRAP_DIO_EN);
>>  
>>  	/* Read Test */
>> -	pwrap_read(wrp, PWRAP_DEW_READ_TEST, &rdata);
>> +	pwrap_dew_read(wrp, PWRAP_DEW_READ_TEST, &rdata);
>>  	if (rdata != PWRAP_DEW_READ_TEST_VAL) {
>>  		dev_err(wrp->dev, "Read test failed after switch to DIO mode: 0x%04x != 0x%04x\n",
>>  				PWRAP_DEW_READ_TEST_VAL, rdata);
>> @@ -759,12 +799,13 @@ static int pwrap_init(struct pmic_wrapper *wrp)
>>  		return ret;
>>  
>>  	/* Signature checking - using CRC */
>> -	if (pwrap_write(wrp, PWRAP_DEW_CRC_EN, 0x1))
>> +	if (pwrap_dew_write(wrp, PWRAP_DEW_CRC_EN, 0x1))
>>  		return -EFAULT;
>>  
>>  	pwrap_writel(wrp, 0x1, PWRAP_CRC_EN);
>>  	pwrap_writel(wrp, 0x0, PWRAP_SIG_MODE);
>> -	pwrap_writel(wrp, PWRAP_DEW_CRC_VAL, PWRAP_SIG_ADR);
>> +	pwrap_writel(wrp, wrp->slave->dew_regs[PWRAP_DEW_CRC_VAL],
>> +		     PWRAP_SIG_ADR);
> 
> It should be "pwrap_dew_write(wrp, PWRAP_DEW_CRC_VAL, PWRAP_SIG_ADR);",
> right?
> 
> Henry
> 

Hi Henry,

i stumbled across this aswell. however this DEW access is direct using
pwrap_writel() and not indirect pwrap_write(). hence this is correct.
the DEW wrapper only exists for pwrap_write() style access. this might
have been a bug in the original commit.

this patch however keeps the functionality as is.

	John


From henryc.chen at mediatek.com  Mon Feb  1 00:38:01 2016
From: henryc.chen at mediatek.com (Henry Chen)
Date: Mon, 1 Feb 2016 16:38:01 +0800
Subject: [PATCH V4 09/11] soc: mediatek: PMIC wrap: add a slave specific
 struct
In-Reply-To: <56AF167C.5030501@openwrt.org>
References: <1453894149-44127-1-git-send-email-blogic@openwrt.org>
 <1453894149-44127-9-git-send-email-blogic@openwrt.org>
 <1453948660.29651.3.camel@mtksdaap41> <56AF167C.5030501@openwrt.org>
Message-ID: <1454315881.2134.4.camel@mtksdaap41>

On Mon, 2016-02-01 at 09:25 +0100, John Crispin wrote:
> 
> On 28/01/2016 03:37, Henry Chen wrote:
> > Hi John,
> > 
> > On Wed, 2016-01-27 at 12:29 +0100, John Crispin wrote:
> > 
> >> @@ -746,7 +786,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
> >>  	pwrap_writel(wrp, 1, PWRAP_DIO_EN);
> >>  
> >>  	/* Read Test */
> >> -	pwrap_read(wrp, PWRAP_DEW_READ_TEST, &rdata);
> >> +	pwrap_dew_read(wrp, PWRAP_DEW_READ_TEST, &rdata);
> >>  	if (rdata != PWRAP_DEW_READ_TEST_VAL) {
> >>  		dev_err(wrp->dev, "Read test failed after switch to DIO mode: 0x%04x != 0x%04x\n",
> >>  				PWRAP_DEW_READ_TEST_VAL, rdata);
> >> @@ -759,12 +799,13 @@ static int pwrap_init(struct pmic_wrapper *wrp)
> >>  		return ret;
> >>  
> >>  	/* Signature checking - using CRC */
> >> -	if (pwrap_write(wrp, PWRAP_DEW_CRC_EN, 0x1))
> >> +	if (pwrap_dew_write(wrp, PWRAP_DEW_CRC_EN, 0x1))
> >>  		return -EFAULT;
> >>  
> >>  	pwrap_writel(wrp, 0x1, PWRAP_CRC_EN);
> >>  	pwrap_writel(wrp, 0x0, PWRAP_SIG_MODE);
> >> -	pwrap_writel(wrp, PWRAP_DEW_CRC_VAL, PWRAP_SIG_ADR);
> >> +	pwrap_writel(wrp, wrp->slave->dew_regs[PWRAP_DEW_CRC_VAL],
> >> +		     PWRAP_SIG_ADR);
> > 
> > It should be "pwrap_dew_write(wrp, PWRAP_DEW_CRC_VAL, PWRAP_SIG_ADR);",
> > right?
> > 
> > Henry
> > 
> 
> Hi Henry,
> 
> i stumbled across this aswell. however this DEW access is direct using
> pwrap_writel() and not indirect pwrap_write(). hence this is correct.
> the DEW wrapper only exists for pwrap_write() style access. this might
> have been a bug in the original commit.
> 
> this patch however keeps the functionality as is.
> 
> 	John

Hi John,

Oh. Sorry, there is no need to change, I just mixed up the parameter
val/reg of pwrap_writel() of this line.
Please keep original code, thanks.

Henry




From linus.walleij at linaro.org  Mon Feb  1 00:48:57 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  1 Feb 2016 09:48:57 +0100
Subject: [PATCH 1/2] dt-bindings: add vendor TPO
Message-ID: <1454316537-3840-1-git-send-email-linus.walleij@linaro.org>

TPO was a merger on June 5 2006 of Toppoly Optoelectronics and
Philips Mobile Display Systems. They manufactured small and medium
mobile displays.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 72e2c5a2b327..7c3c63d4dbe0 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -237,6 +237,7 @@ toradex	Toradex AG
 toshiba	Toshiba Corporation
 toumaz	Toumaz
 tplink	TP-LINK Technologies Co., Ltd.
+tpo	TPO
 tronfy	Tronfy
 truly	Truly Semiconductors Limited
 upisemi	uPI Semiconductor Corp.
-- 
2.4.3



From linus.walleij at linaro.org  Mon Feb  1 00:50:43 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  1 Feb 2016 09:50:43 +0100
Subject: [PATCH 2/2] dt-bindings: Add TPO TPG110 binding
Message-ID: <1454316643-3931-1-git-send-email-linus.walleij@linaro.org>

This adds device tree bindings for the TPO TPG110 panel found
mounted in the Nomadik NHK8815.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 .../bindings/display/panel/tpo,tpg110.txt          | 47 ++++++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt

diff --git a/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
new file mode 100644
index 000000000000..acbc6bef3593
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
@@ -0,0 +1,47 @@
+TPO TPG110 Panel
+================
+
+This binding builds on the DPI bindings, adding a few properties
+as a superset of a DPI. See panel-dpi.txt for the required DPI
+bindings.
+
+Required properties:
+- compatible : "tpo,tpg110"
+- grestb-gpio : panel reset GPIO
+- scen-gpios : serial control enable GPIO
+- scl-gpios : serial control clock line GPIO
+- sda-gpios : serial control data line GPIO
+
+Required nodes:
+- Video port for DPI input, see panel-dpi.txt
+- Panel timing for DPI setup, see panel-dpi.txt
+
+Example
+-------
+
+panel {
+	compatible = "tpo,tpg110", "panel-dpi";
+	grestb-gpios = <&stmpe_gpio44 5 GPIO_ACTIVE_LOW>;
+	scen-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
+	scl-gpios = <&gpio0 5 GPIO_ACTIVE_HIGH>;
+	sda-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
+	backlight = <&bl>;
+
+	port {
+		nomadik_clcd_panel: endpoint {
+			remote-endpoint = <&nomadik_clcd_pads>;
+		};
+	};
+
+	panel-timing {
+		clock-frequency = <33200000>;
+		hactive = <800>;
+		hback-porch = <216>;
+		hfront-porch = <40>;
+		hsync-len = <1>;
+		vactive = <480>;
+		vback-porch = <35>;
+		vfront-porch = <10>;
+		vsync-len = <1>;
+	};
+};
-- 
2.4.3



From wdc at rock-chips.com  Mon Feb  1 00:54:38 2016
From: wdc at rock-chips.com (David.Wu)
Date: Mon, 1 Feb 2016 16:54:38 +0800
Subject: [PATCH] PM / AVS: rockchip-io: add GRF and PMUGRF types to
 distinguish
In-Reply-To: <5387650.lAgTxexlF2@phil>
References: <1454155305-55516-1-git-send-email-david.wu@rock-chips.com>
 <5387650.lAgTxexlF2@phil>
Message-ID: <56AF1D4E.40307@rock-chips.com>

Hi Heiko,

? 2016/1/30 20:39, Heiko Stuebner ??:
> Hi David,
>
> Am Samstag, 30. Januar 2016, 20:01:45 schrieb David Wu:
>> As rk3368 contained two separated iodomain areas, this was
>> determined to use which regmap base address.
>>
>> Signed-off-by: David Wu <david.wu at rock-chips.com>
> I don't think we need to specify this on a driver level. Both GRF areas are
> "General register files" only located in two separate power-domains.
> So the rockchip,grf property should work for both. Especially as nothing
> keeps designers from introducing yet another GRF-area somewhere else ;-)
>
> >From when I started working on the rk3368, I still have a preliminary
> patches for that sitting here, so I've attached on how I envisoned that to
> work.

Okay, i agree to you, but it make someone a little confused just from 
the drive code,
not DT file,  about  pmugrf regmap base address.:-)

How do you feel about intergating GRF and PMU drivers in one driver?
Thanks!

>
> Heiko
>
>> ---
>>   drivers/power/avs/rockchip-io-domain.c | 32
>> ++++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8
>> deletions(-)
>>
>> diff --git a/drivers/power/avs/rockchip-io-domain.c
>> b/drivers/power/avs/rockchip-io-domain.c index 8099456..b17aeb7 100644
>> --- a/drivers/power/avs/rockchip-io-domain.c
>> +++ b/drivers/power/avs/rockchip-io-domain.c
>> @@ -47,6 +47,11 @@
>>   #define RK3368_SOC_CON15_FLASH0		BIT(14)
>>   #define RK3368_SOC_FLASH_SUPPLY_NUM	2
>>
>> +enum rockchip_iodomain_grf_type {
>> +	GRF,
>> +	PMUGRF
>> +};
>> +
>>   struct rockchip_iodomain;
>>
>>   /**
>> @@ -54,6 +59,7 @@ struct rockchip_iodomain;
>>    */
>>   struct rockchip_iodomain_soc_data {
>>   	int grf_offset;
>> +	enum rockchip_iodomain_grf_type type;
>>   	const char *supply_names[MAX_SUPPLIES];
>>   	void (*init)(struct rockchip_iodomain *iod);
>>   };
>> @@ -67,7 +73,7 @@ struct rockchip_iodomain_supply {
>>
>>   struct rockchip_iodomain {
>>   	struct device *dev;
>> -	struct regmap *grf;
>> +	struct regmap *base;
>>   	struct rockchip_iodomain_soc_data *soc_data;
>>   	struct rockchip_iodomain_supply supplies[MAX_SUPPLIES];
>>   };
>> @@ -86,7 +92,7 @@ static int rockchip_iodomain_write(struct
>> rockchip_iodomain_supply *supply, /* apply hiword-mask */
>>   	val |= (BIT(supply->idx) << 16);
>>
>> -	ret = regmap_write(iod->grf, iod->soc_data->grf_offset, val);
>> +	ret = regmap_write(iod->base, iod->soc_data->grf_offset, val);
>>   	if (ret)
>>   		dev_err(iod->dev, "Couldn't write to GRF\n");
>>
>> @@ -157,7 +163,7 @@ static void rk3288_iodomain_init(struct
>> rockchip_iodomain *iod) * instead of a special gpio.
>>   	 */
>>   	val = RK3288_SOC_CON2_FLASH0 | (RK3288_SOC_CON2_FLASH0 << 16);
>> -	ret = regmap_write(iod->grf, RK3288_SOC_CON2, val);
>> +	ret = regmap_write(iod->base, RK3288_SOC_CON2, val);
>>   	if (ret < 0)
>>   		dev_warn(iod->dev, "couldn't update flash0 ctrl\n");
>>   }
>> @@ -176,7 +182,7 @@ static void rk3368_iodomain_init(struct
>> rockchip_iodomain *iod) * instead of a special gpio.
>>   	 */
>>   	val = RK3368_SOC_CON15_FLASH0 | (RK3368_SOC_CON15_FLASH0 << 16);
>> -	ret = regmap_write(iod->grf, RK3368_SOC_CON15, val);
>> +	ret = regmap_write(iod->base, RK3368_SOC_CON15, val);
>>   	if (ret < 0)
>>   		dev_warn(iod->dev, "couldn't update flash0 ctrl\n");
>>   }
>> @@ -187,6 +193,7 @@ static void rk3368_iodomain_init(struct
>> rockchip_iodomain *iod) */
>>   static const struct rockchip_iodomain_soc_data soc_data_rk3188 = {
>>   	.grf_offset = 0x104,
>> +	.type = GRF,
>>   	.supply_names = {
>>   		NULL,
>>   		NULL,
>> @@ -209,6 +216,7 @@ static const struct rockchip_iodomain_soc_data
>> soc_data_rk3188 = {
>>
>>   static const struct rockchip_iodomain_soc_data soc_data_rk3288 = {
>>   	.grf_offset = 0x380,
>> +	.type = GRF,
>>   	.supply_names = {
>>   		"lcdc",		/* LCDC_VDD */
>>   		"dvp",		/* DVPIO_VDD */
>> @@ -226,6 +234,7 @@ static const struct rockchip_iodomain_soc_data
>> soc_data_rk3288 = {
>>
>>   static const struct rockchip_iodomain_soc_data soc_data_rk3368 = {
>>   	.grf_offset = 0x900,
>> +	.type = GRF,
>>   	.supply_names = {
>>   		NULL,		/* reserved */
>>   		"dvp",		/* DVPIO_VDD */
>> @@ -242,6 +251,7 @@ static const struct rockchip_iodomain_soc_data
>> soc_data_rk3368 = {
>>
>>   static const struct rockchip_iodomain_soc_data soc_data_rk3368_pmu = {
>>   	.grf_offset = 0x100,
>> +	.type = PMUGRF,
>>   	.supply_names = {
>>   		NULL,
>>   		NULL,
>> @@ -293,10 +303,16 @@ static int rockchip_iodomain_probe(struct
>> platform_device *pdev) match = of_match_node(rockchip_iodomain_match,
>> np);
>>   	iod->soc_data = (struct rockchip_iodomain_soc_data *)match->data;
>>
>> -	iod->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
>> -	if (IS_ERR(iod->grf)) {
>> -		dev_err(&pdev->dev, "couldn't find grf regmap\n");
>> -		return PTR_ERR(iod->grf);
>> +	if (iod->soc_data->type == PMUGRF)
>> +		iod->base = syscon_regmap_lookup_by_phandle(
>> +				np, "rockchip,pmugrf");
>> +	else
>> +		iod->base = syscon_regmap_lookup_by_phandle(
>> +				np, "rockchip,grf");
>> +	if (IS_ERR(iod->base)) {
>> +		dev_err(&pdev->dev, "couldn't find %s regmap\n",
>> +			(iod->soc_data->type == PMUGRF) ? "pmugrf" : "grf");
>> +		return PTR_ERR(iod->base);
>>   	}
>>
>>   	for (i = 0; i < MAX_SUPPLIES; i++) {

-------------- next part --------------
From 73cc56277c42fd13bed3921b07c84ac4b030321a Mon Sep 17 00:00:00 2001
From: David Wu <wdc at rock-chips.com>
Date: Wed, 24 Dec 2014 16:31:09 +0800
Subject: [PATCH 1/5] rk3368: io-domain: add io domain volt sel
Content-Type: text/plain; charset="utf-8"

Signed-off-by: David Wu <wdc at rock-chips.com>
---
 drivers/power/avs/rockchip-io-domain.c | 184 +++++++++++++++++++++++----------
 1 file changed, 130 insertions(+), 54 deletions(-)

diff --git a/drivers/power/avs/rockchip-io-domain.c b/drivers/power/avs/rockchip-io-domain.c
index b160132..d096457 100755
--- a/drivers/power/avs/rockchip-io-domain.c
+++ b/drivers/power/avs/rockchip-io-domain.c
@@ -43,19 +43,28 @@
 #define RK3288_SOC_CON2_FLASH0		BIT(7)
 #define RK3288_SOC_FLASH_SUPPLY_NUM	2
 
-#define RK3368_GRF_SOC_CON15			0x43c
-#define RK3368_GRF_SOC_CON15_FLASH0		BIT(14)
+#define RK3368_GRF_SOC_CON15		0x43c
+#define RK3368_GRF_SOC_CON15_FLASH0	BIT(14)
 #define RK3368_SOC_FLASH_SUPPLY_NUM	2
 
+#define MAX_ROCKCHIP_GRF_NUM        2
 
 struct rockchip_iodomain;
 
 /**
  * @supplies: voltage settings matching the register bits.
  */
+
+enum rockchip_iodomain_grf_type {
+	GRF,
+	PMU_GRF,
+};
+
 struct rockchip_iodomain_soc_data {
 	int grf_offset;
-	const char *supply_names[MAX_SUPPLIES];
+	int pmugrf_offset;
+	const char *grf_supply_names[MAX_SUPPLIES];
+	const char *pmugrf_supply_names[MAX_SUPPLIES];
 	void (*init)(struct rockchip_iodomain *iod);
 };
 
@@ -64,19 +73,24 @@ struct rockchip_iodomain_supply {
 	struct regulator *reg;
 	struct notifier_block nb;
 	int idx;
+	enum rockchip_iodomain_grf_type type;
 };
 
 struct rockchip_iodomain {
 	struct device *dev;
 	struct regmap *grf;
+	struct regmap *pmu;
 	struct rockchip_iodomain_soc_data *soc_data;
-	struct rockchip_iodomain_supply supplies[MAX_SUPPLIES];
+	struct rockchip_iodomain_supply grf_supplies[MAX_SUPPLIES];
+	struct rockchip_iodomain_supply pmugrf_supplies[MAX_SUPPLIES];
 };
 
 static int rockchip_iodomain_write(struct rockchip_iodomain_supply *supply,
 				   int uV)
 {
 	struct rockchip_iodomain *iod = supply->iod;
+	struct regmap *reg;
+	int offset;
 	u32 val;
 	int ret;
 
@@ -87,7 +101,15 @@ static int rockchip_iodomain_write(struct rockchip_iodomain_supply *supply,
 	/* apply hiword-mask */
 	val |= (BIT(supply->idx) << 16);
 
-	ret = regmap_write(iod->grf, iod->soc_data->grf_offset, val);
+	if (supply->type == GRF) {
+		reg = iod->grf;
+		offset = iod->soc_data->grf_offset;
+	} else if (supply->type == PMU_GRF) {
+		reg = iod->pmu;
+		offset = iod->soc_data->pmugrf_offset;
+	}
+
+	ret = regmap_write(reg, offset, val);
 	if (ret)
 		dev_err(iod->dev, "Couldn't write to GRF\n");
 
@@ -150,7 +172,7 @@ static void rk3288_iodomain_init(struct rockchip_iodomain *iod)
 	u32 val;
 
 	/* if no flash supply we should leave things alone */
-	if (!iod->supplies[RK3288_SOC_FLASH_SUPPLY_NUM].reg)
+	if (!iod->grf_supplies[RK3288_SOC_FLASH_SUPPLY_NUM].reg)
 		return;
 
 	/*
@@ -169,7 +191,7 @@ static void rk3368_iodomain_init(struct rockchip_iodomain *iod)
 	u32 val;
 
 	/* if no flash supply we should leave things alone */
-	if (!iod->supplies[RK3368_SOC_FLASH_SUPPLY_NUM].reg)
+	if (!iod->grf_supplies[RK3368_SOC_FLASH_SUPPLY_NUM].reg)
 		return;
 
 	/*
@@ -189,7 +211,7 @@ static void rk3368_iodomain_init(struct rockchip_iodomain *iod)
  */
 static const struct rockchip_iodomain_soc_data soc_data_rk3188 = {
 	.grf_offset = 0x104,
-	.supply_names = {
+	.grf_supply_names = {
 		NULL,
 		NULL,
 		NULL,
@@ -211,7 +233,7 @@ static const struct rockchip_iodomain_soc_data soc_data_rk3188 = {
 
 static const struct rockchip_iodomain_soc_data soc_data_rk3288 = {
 	.grf_offset = 0x380,
-	.supply_names = {
+	.grf_supply_names = {
 		"lcdc",		/* LCDC_VDD */
 		"dvp",		/* DVPIO_VDD */
 		"flash0",	/* FLASH0_VDD (emmc) */
@@ -228,16 +250,25 @@ static const struct rockchip_iodomain_soc_data soc_data_rk3288 = {
 
 static const struct rockchip_iodomain_soc_data soc_data_rk3368 = {
 	.grf_offset = 0x900,
-	.supply_names = {
+	.pmugrf_offset = 0x100,
+	.grf_supply_names = {
+		NULL,
+		"dvp",		/*DVP IO domain*/
+		"flash0",	/*FLASH0 IO domain*/
+		"wifi",         /*APIO2 IO domain*/
+		NULL,
+		"audio",	/*APIO3 IO domain*/
+		"sdcard",	/*SDCARD IO domain*/
+		"gpio30",	/*APIO1 IO domain*/
+		"gpio1830",	/*ADIO4 IO domain*/
+	},
+	.pmugrf_supply_names = {
+		NULL,
+		NULL,
 		NULL,
-		"dvp_v18sel",		/*DVP IO domain*/
-		"flash0_v18sel",		/*FLASH0 IO domain*/
-		"wifi_v18sel",	/*WIFI IO domain*/
 		NULL,
-		"audio_v18sel",	/*AUDIO IO domain*/
-		"sdcard_v18sel",		/*SDCARD IO domain*/
-		"gpio30_v18sel",		/*GPIO30 IO domain*/
-		"gpio1830_v18sel",	/*GPIO1830 IO domain*/
+		"pmu",	        /*PMU IO domain*/
+		"vop",	        /*LCDC IO domain*/
 	},
 	.init = rk3368_iodomain_init,
 };
@@ -259,47 +290,34 @@ static const struct of_device_id rockchip_iodomain_match[] = {
 	{ /* sentinel */ },
 };
 
-static int rockchip_iodomain_probe(struct platform_device *pdev)
+static int rockchip_iodomain_parse_supply(struct rockchip_iodomain *iod,
+					  struct device_node *np,
+					  enum rockchip_iodomain_grf_type type)
 {
-	struct device_node *np = pdev->dev.of_node;
-	const struct of_device_id *match;
-	struct rockchip_iodomain *iod;
+	struct rockchip_iodomain_supply *group_supply;
+	const char **group_supply_names;
 	int i, ret = 0;
 
-	if (!np)
-		return -ENODEV;
-
-	iod = devm_kzalloc(&pdev->dev, sizeof(*iod), GFP_KERNEL);
-	if (!iod)
-		return -ENOMEM;
-
-	iod->dev = &pdev->dev;
-	platform_set_drvdata(pdev, iod);
-
-	match = of_match_node(rockchip_iodomain_match, np);
-	iod->soc_data = (struct rockchip_iodomain_soc_data *)match->data;
-
-	iod->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
-	if (IS_ERR(iod->grf)) {
-		dev_err(&pdev->dev, "couldn't find grf regmap\n");
-		return PTR_ERR(iod->grf);
+	if (type == GRF) {
+		group_supply_names =
+			(const char **)iod->soc_data->grf_supply_names;
+		group_supply = iod->grf_supplies;
+	} else if (type == PMU_GRF) {
+		group_supply_names =
+			(const char **)iod->soc_data->pmugrf_supply_names;
+		group_supply = iod->pmugrf_supplies;
 	}
 
 	for (i = 0; i < MAX_SUPPLIES; i++) {
-		const char *supply_name = iod->soc_data->supply_names[i];
-		struct rockchip_iodomain_supply *supply = &iod->supplies[i];
+		const char *supply_name = group_supply_names[i];
+		struct rockchip_iodomain_supply *supply = &group_supply[i];
 		struct regulator *reg;
 		int uV;
-		const char *regulator_name = NULL;
 
 		if (!supply_name)
 			continue;
 
-		of_property_read_string(np, supply_name, &regulator_name);
-		if (!regulator_name)
-			continue;
-
-		reg = regulator_get(NULL, regulator_name);
+		reg = devm_regulator_get_optional(iod->dev, supply_name);
 		if (IS_ERR(reg)) {
 			ret = PTR_ERR(reg);
 
@@ -334,6 +352,7 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
 		supply->idx = i;
 		supply->iod = iod;
 		supply->reg = reg;
+		supply->type = type;
 		supply->nb.notifier_call = rockchip_iodomain_notify;
 
 		ret = rockchip_iodomain_write(supply, uV);
@@ -345,21 +364,16 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
 		/* register regulator notifier */
 		ret = regulator_register_notifier(reg, &supply->nb);
 		if (ret) {
-			dev_err(&pdev->dev,
+			dev_err(iod->dev,
 				"regulator notifier request failed\n");
 			supply->reg = NULL;
 			goto unreg_notify;
 		}
 	}
 
-	if (iod->soc_data->init)
-		iod->soc_data->init(iod);
-
-	return 0;
-
 unreg_notify:
 	for (i = MAX_SUPPLIES - 1; i >= 0; i--) {
-		struct rockchip_iodomain_supply *io_supply = &iod->supplies[i];
+		struct rockchip_iodomain_supply *io_supply = &group_supply[i];
 
 		if (io_supply->reg)
 			regulator_unregister_notifier(io_supply->reg,
@@ -369,13 +383,75 @@ unreg_notify:
 	return ret;
 }
 
+static int rockchip_iodomain_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node, *node;
+	const struct of_device_id *match;
+	struct rockchip_iodomain *iod;
+	int ret = 0;
+
+	if (!np)
+		return -ENODEV;
+
+	iod = devm_kzalloc(&pdev->dev, sizeof(*iod), GFP_KERNEL);
+	if (!iod)
+		return -ENOMEM;
+
+	iod->dev = &pdev->dev;
+	platform_set_drvdata(pdev, iod);
+
+	match = of_match_node(rockchip_iodomain_match, np);
+	iod->soc_data = (struct rockchip_iodomain_soc_data *)match->data;
+
+	iod->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+	if (IS_ERR(iod->grf)) {
+		dev_err(&pdev->dev, "couldn't find grf regmap\n");
+		return PTR_ERR(iod->grf);
+	}
+	ret = rockchip_iodomain_parse_supply(iod, np, GRF);
+	if (ret) {
+		dev_err(iod->dev,
+			"rockchip iodomain parse grf supply failed\n");
+		return ret;
+	}
+
+	/* try to find the optional reference to the pmu syscon */
+	node = of_parse_phandle(np, "rockchip,pmu", 0);
+	if (node) {
+		iod->pmu = syscon_node_to_regmap(node);
+		if (IS_ERR(iod->pmu))
+			return PTR_ERR(iod->pmu);
+		ret = rockchip_iodomain_parse_supply(iod, np, PMU_GRF);
+		if (ret) {
+			dev_err(iod->dev,
+				"rockchip iodomain parse pmu_grf supply failed\n");
+			return ret;
+		}
+	}
+
+	if (iod->soc_data->init)
+		iod->soc_data->init(iod);
+
+	return ret;
+}
+
 static int rockchip_iodomain_remove(struct platform_device *pdev)
 {
 	struct rockchip_iodomain *iod = platform_get_drvdata(pdev);
 	int i;
 
 	for (i = MAX_SUPPLIES - 1; i >= 0; i--) {
-		struct rockchip_iodomain_supply *io_supply = &iod->supplies[i];
+		struct rockchip_iodomain_supply *io_supply
+			= &iod->grf_supplies[i];
+
+		if (io_supply->reg)
+			regulator_unregister_notifier(io_supply->reg,
+						      &io_supply->nb);
+	}
+
+	for (i = MAX_SUPPLIES - 1; i >= 0; i--) {
+		struct rockchip_iodomain_supply *io_supply =
+			&iod->pmugrf_supplies[i];
 
 		if (io_supply->reg)
 			regulator_unregister_notifier(io_supply->reg,
-- 
1.9.1


From james.morse at arm.com  Mon Feb  1 00:53:27 2016
From: james.morse at arm.com (James Morse)
Date: Mon, 01 Feb 2016 08:53:27 +0000
Subject: [PATCH v4 00/13] arm64: kernel: Add support for
 hibernate/suspend-to-disk
In-Reply-To: <7hvb6chv5e.fsf@baylibre.com>
References: <1453977766-20907-1-git-send-email-james.morse@arm.com>
 <7hvb6chv5e.fsf@baylibre.com>
Message-ID: <56AF1D07.3000604@arm.com>

Hi Kevin,

On 29/01/16 22:34, Kevin Hilman wrote:
> James Morse <james.morse at arm.com> writes:
> I'd like to help in testing this so I'm just curious which platforms
> you've been testing this on.  I'm assuming a Juno (r2?), anything else?

That would be great - thanks!

I've done most of the testing on a Juno r1, but also gave it a spin on a
stray Seattle.


> Are you testing the resume from cold boot, or just from kexec?

>From cold boot. I haven't tried with kexec, but I doubt that's a use-case anyone
wants as you would resume immediately. (might be interesting for testing though)


> For cold boot on Juno, I'm assuming there would be some
> booloader/firmware changes needed to find and boot from the hibernation
> image?

Not at all! Your firmware only needs to support some mechanism to
turning CPUs off.

If you add 'resume=/dev/sda2' (or wherever your swap partition is located), the
kernel will check this partition for the hibernate-image signature, if found, it
will resume from that partition. Otherwise booting is as normal. (there is one
hoop to jump through to ensure your rootfs hasn't been mounted before the kernel
starts resume, as you could corrupt it - an initramfs in the kernel is the best
fix for this).

No firmware changes needed.

> Is that being worked on?  If not Juno, are you aware of any
> other platforms that could be tested with resume from cold boot?

Any arm64 platform with persistent storage should work. I've been using a swap
partition on a usb drive.


> Not knowing the answers to the above, I tested your branch using arm64
> defconfig + CONFIG_HIBERNATION=y on my Juno and noticed that it didn't
> stay suspended (full suspend log below) so I'm looking for
> ideas/recommenations on how to test this.

That trace looks quite normal, (one of mine below[0] for comparison). Any
failure would have happened after the point you stopped ... did you have a swap
partition 'on'?

'syscore' will freeze all processes and stop all devices, then create a
copy of the minimum amount of memory it needs to save. Then it starts
all the devices again, as it needs to write this image out to swap. This is what
you are seeing.

Once it has done this it calls poweroff or reboot.


Thanks,

James



[0] kernel output for hibernate/resume on Juno-r1:
root at localhost:/sys/power# swapon /dev/sda2
Adding 236540k swap on /dev/sda2.  Priority:-1 extents:1 across:236540k
root at localhost:/sys/power# ls
disk        pm_async           reserved_size  state
image_size  pm_freeze_timeout  resume         wakeup_count
root at localhost:/sys/power# cat disk
[shutdown] reboot suspend
root at localhost:/sys/power# echo disk > state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
PM: Preallocating image memory... done (allocated 93967 pages)
PM: Allocated 375868 kbytes in 3.74 seconds (100.49 MB/s)
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
PM: freeze of devices complete after 17.794 msecs
PM: late freeze of devices complete after 1.358 msecs
PM: noirq freeze of devices complete after 1.771 msecs
Disabling non-boot CPUs ...
PM: Creating hibernation image:
PM: Need to copy 93868 pages
PM: Hibernation image created (93868 pages copied)
PM: noirq thaw of devices complete after 1.319 msecs
PM: early thaw of devices complete after 0.890 msecs
serio serio0: device_attach() failed for 1c060000.kmi (1c060000.kmi), error: -51
7
serio serio1: device_attach() failed for 1c070000.kmi (1c070000.kmi), error: -51
7
PM: thaw of devices complete after 92.523 msecs
PM: Using 1 thread(s) for compression.
PM: Compressing and saving image data (94052 pages)...
PM: Image saving progress:   0%
atkbd serio0: keyboard reset failed on 1c060000.kmi
atkbd serio1: keyboard reset failed on 1c070000.kmi
PM: Image saving progress:  10%
PM: Image saving progress:  20%
PM: Image saving progress:  30%
PM: Image saving progress:  40%
PM: Image saving progress:  50%
PM: Image saving progress:  60%
PM: Image saving progress:  70%
PM: Image saving progress:  80%
PM: Image saving progress:  90%
PM: Image saving progress: 100%
PM: Image saving done.
PM: Wrote 376208 kbytes in 21.76 seconds (17.28 MB/s)
PM: S|
kvm: exiting hardware virtualization
reboot: Power down

Board powered down, use REBOOT to restart.

Cmd>

ARM V2M-Juno Boot loader v1.0.0
HBI0262 build 1635

ARM V2M_Juno r1 Firmware v1.3.3
Build Date: Mar 31 2015

Time :  08:25:55
Date :  01:02:2016

Press Enter to stop auto boot...
Powering up system...

Switching on ATXPSU...
PMIC RAM configuration (pms_v104.bin)...
MBtemp   : 28 degC

Configuring motherboard (rev C, var A)...
IOFPGA image \MB\HBI0262C\io_b117.bit
IOFPGA  config: PASSED
OSC CLK config: PASSED

Configuring SCC registers...
Writing SCC 0x00000054 with 0x0007FFFE
Writing SCC 0x0000005C with 0x00FE001E
Writing SCC 0x00000100 with 0x003F1000
Writing SCC 0x00000104 with 0x0001F300
Writing SCC 0x00000108 with 0x00331000
Writing SCC 0x0000010C with 0x00019300
Writing SCC 0x00000118 with 0x003F1000
Writing SCC 0x0000011C with 0x0001F100
Writing SCC 0x000000F4 with 0x00000018
Writing SCC 0x000000F8 with 0x0BEC0000
Writing SCC 0x000000FC with 0xABE40000
Writing SCC 0x00000A14 with 0x00000000
Writing SCC 0x0000000C with 0x000000C2
Writing SCC 0x00000010 with 0x000000C2

Peripheral ID0:0x000000AD
Peripheral ID1:0x000000B0
Peripheral ID2:0x0000001B
Peripheral ID3:0x00000000
Peripheral ID4:0x0000000D
Peripheral ID5:0x000000F0
Peripheral ID6:0x00000005
Peripheral ID7:0x000000B1

Programming NOR Flash
PCIE clock configured...

Testing motherboard interfaces (FPGA build 117)...
SRAM 32MB test: PASSED
LAN9118   test: PASSED
KMI1/2    test: PASSED
MMC       test: PASSED
PB/LEDs   test: PASSED
FPGA UART test: PASSED
PCIe init test: PASSED
MAC addrs test: PASSED

The default boot selection will start in   1 seconds
Downloading the file <Image> from the TFTP server
[=======================================>]    9656 Kb
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
Booting Linux on physical CPU 0x100
Linux version 4.5.0-rc1+ (morse at melchizedek) (gcc version 4.9.3 20141031 (prerel
ease) (Linaro GCC 2014.11) ) #1839 SMP PREEMPT Fri Jan 29 15:05:57 GMT 2016
Boot CPU: AArch64 Processor [410fd033]
earlycon: Early serial console at MMIO 0x7ff80000 (options '')
bootconsole [uart0] enabled
efi: Getting EFI parameters from FDT:
EFI v2.50 by ARM Juno EFI Nov 24 2015 12:36:35
efi:  ACPI=0xf95b0000  ACPI 2.0=0xf95b0014  PROP=0xfe8db4d8
cma: Reserved 16 MiB at 0x00000000fd800000
psci: probing for conduit method from DT.
psci: PSCIv1.0 detected in firmware.
psci: Using standard PSCI v0.2 function IDs
psci: Trusted OS migration not required
PERCPU: Embedded 20 pages/cpu @ffff80097ff4f000 s42240 r8192 d31488 u81920
Detected VIPT I-cache on CPU0
CPU features: enabling workaround for ARM erratum 845719
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 2060048
Kernel command line: console=ttyAMA0,115200 earlycon=pl011,0x7ff80000 root=/dev/
nfs nfsroot=10.xx.xx.xx:xx/aarch64-current resume=/dev/sda2 no_console_s
uspend ip=dhcp rw init=/bin/bash crashkernel=256M maxcpus=1
log_buf_len individual max cpu contribution: 4096 bytes
log_buf_len total cpu_extra contributions: 20480 bytes
log_buf_len min size: 16384 bytes
log_buf_len: 65536 bytes
early log buf free: 14304(87%)
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
software IO TLB [mem 0xf54a0000-0xf94a0000] (64MB) mapped at [ffff8000754a0000-f
fff80007949ffff]
Memory: 8130452K/8371264K available (6007K kernel code, 524K rwdata, 2524K rodat
a, 592K init, 229K bss, 224428K reserved, 16384K cma-reserved)
Virtual kernel memory layout:
    vmalloc : 0xffff000000000000 - 0xffff7bffbfff0000   (126974 GB)
    vmemmap : 0xffff7bffc0000000 - 0xffff7fffc0000000   (  4096 GB maximum)
              0xffff7bffc2000000 - 0xffff7bffe8000000   (   608 MB actual)
    fixed   : 0xffff7ffffa7fd000 - 0xffff7ffffac00000   (  4108 KB)
    PCI I/O : 0xffff7ffffae00000 - 0xffff7ffffbe00000   (    16 MB)
    modules : 0xffff7ffffc000000 - 0xffff800000000000   (    64 MB)
    memory  : 0xffff800000000000 - 0xffff800980000000   ( 38912 MB)
      .init : 0xffff8000008d7000 - 0xffff80000096b000   (   592 KB)
      .text : 0xffff800000080000 - 0xffff8000008d6c64   (  8540 KB)
      .data : 0xffff80000096b000 - 0xffff8000009ee200   (   525 KB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Preemptible hierarchical RCU implementation.
        Build-time adjustment of leaf fanout to 64.
        RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=6.
RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=6
NR_IRQS:64 nr_irqs:64 0
GIC: Using split EOI/Deactivate mode
GICv2m: range[mem 0x2c1c0000-0x2c1c0fff], SPI[224:255]
Architected cp15 and mmio timer(s) running at 50.00MHz (phys/phys).
clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xb8812736b, m
ax_idle_ns: 440795202655 ns
sched_clock: 56 bits at 50MHz, resolution 20ns, wraps every 4398046511100ns
Console: colour dummy device 80x25
Calibrating delay loop (skipped), value calculated using timer frequency.. 100.0
0 BogoMIPS (lpj=200000)
pid_max: default: 32768 minimum: 301
Security Framework initialized
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes)
ASID allocator initialised with 65536 entries
Remapping and enabling EFI services.
 EFI remap 0x0000000008000000 => 0000000020000000
  EFI remap 0x000000001c170000 => 0000000024000000
  EFI remap 0x00000000f94a0000 => 0000000024010000
  EFI remap 0x00000000f9520000 => 0000000024020000
  EFI remap 0x00000000f9530000 => 0000000024030000
  EFI remap 0x00000000f9540000 => 0000000024040000
  EFI remap 0x00000000f9570000 => 0000000024070000
  EFI remap 0x00000000f9580000 => 0000000024080000
  EFI remap 0x00000000f95c0000 => 00000000240a0000
  EFI remap 0x00000000f9640000 => 0000000024120000
  EFI remap 0x00000000f9650000 => 0000000024130000
  EFI remap 0x00000000f9720000 => 0000000024200000
  EFI remap 0x00000000f9730000 => 0000000024210000
  EFI remap 0x00000000f9740000 => 0000000024220000
  EFI remap 0x00000000f9780000 => 0000000024260000
  EFI remap 0x00000000f9790000 => 0000000024270000
  EFI remap 0x00000000f9800000 => 00000000242e0000
  EFI remap 0x00000000f9810000 => 00000000242f0000
  EFI remap 0x00000000f9820000 => 0000000024300000
  EFI remap 0x00000000fe820000 => 0000000024330000
  EFI remap 0x00000000fe830000 => 0000000024340000
  EFI remap 0x00000000fe840000 => 0000000024350000
  EFI remap 0x00000000fe870000 => 0000000024370000
Brought up 1 CPUs
SMP: Total of 1 processors activated.
CPU: All CPU(s) started at EL2
alternatives: patching kernel code
devtmpfs: initialized
DMI not present or invalid.
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645
041785100000 ns
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
cpuidle: using governor ladder
cpuidle: using governor menu
vdso: 2 pages (1 code @ ffff800000972000, 1 data @ ffff800000971000)
hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
DMA: preallocated 256 KiB pool for atomic allocations
Serial: AMBA PL011 UART driver
7ff80000.uart: ttyAMA0 at MMIO 0x7ff80000 (irq = 25, base_baud = 0) is a PL011 r
ev3
console [ttyAMA0] enabled
console [ttyAMA0] enabled
bootconsole [uart0] disabled
bootconsole [uart0] disabled
HugeTLB registered 2 MB page size, pre-allocated 0 pages
ACPI: Interpreter disabled.
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
dmi: Firmware registration failed.
clocksource: Switched to clocksource arch_sys_counter
VFS: Disk quotas dquot_6.6.0
VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
pnp: PnP ACPI: disabled
NET: Registered protocol family 2
TCP established hash table entries: 65536 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
UDP hash table entries: 4096 (order: 5, 131072 bytes)
UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
hw perfevents: enabled with armv8_pmuv3 PMU driver, 7 counters available
kvm [1]: interrupt-controller at 2c04f000 IRQ14
kvm [1]: timer IRQ4
kvm [1]: 8-bit VMID
kvm [1]: Hyp mode initialized successfully
futex hash table entries: 2048 (order: 6, 262144 bytes)
audit: initializing netlink subsys (disabled)
audit: type=2000 audit(0.432:1): initialized
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
fuse init (API version 7.24)
9p: Installing v9fs 9p2000 file system support
io scheduler noop registered
io scheduler cfq registered (default)
PCI host bridge /pcie-controller at 30000000 ranges:
   IO 0x5f800000..0x5fffffff -> 0x5f800000
  MEM 0x50000000..0x57ffffff -> 0x50000000
  MEM 0x4000000000..0x40ffffffff -> 0x4000000000
pci-host-generic 40000000.pcie-controller: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io  0x0000-0x7fffff] (bus address [0x5f80000
0-0x5fffffff])
pci_bus 0000:00: root bus resource [mem 0x50000000-0x57ffffff]
pci_bus 0000:00: root bus resource [mem 0x4000000000-0x40ffffffff pref]
pci 0000:03:00.0: reg 0x20: initial BAR value 0x00000000 invalid
pci 0000:03:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with
 'pcie_aspm=force'
pci 0000:08:00.0: reg 0x18: initial BAR value 0x00000000 invalid
pci 0000:00:00.0: BAR 8: assigned [mem 0x50000000-0x501fffff]
pci 0000:00:00.0: BAR 0: assigned [mem 0x4000000000-0x4000003fff 64bit pref]
pci 0000:00:00.0: BAR 7: assigned [io  0x1000-0x2fff]
pci 0000:01:00.0: BAR 8: assigned [mem 0x50000000-0x501fffff]
pci 0000:01:00.0: BAR 7: assigned [io  0x1000-0x2fff]
pci 0000:02:01.0: BAR 8: assigned [mem 0x50000000-0x500fffff]
pci 0000:02:1f.0: BAR 8: assigned [mem 0x50100000-0x501fffff]
pci 0000:02:01.0: BAR 7: assigned [io  0x1000-0x1fff]
pci 0000:02:1f.0: BAR 7: assigned [io  0x2000-0x2fff]
pci 0000:03:00.0: BAR 6: assigned [mem 0x50000000-0x5007ffff pref]
pci 0000:03:00.0: BAR 2: assigned [mem 0x50080000-0x50083fff 64bit]
pci 0000:03:00.0: BAR 0: assigned [mem 0x50084000-0x5008407f 64bit]
pci 0000:03:00.0: BAR 4: assigned [io  0x1000-0x107f]
pci 0000:02:01.0: PCI bridge to [bus 03]
pci 0000:02:01.0:   bridge window [io  0x1000-0x1fff]
pci 0000:02:01.0:   bridge window [mem 0x50000000-0x500fffff]
pci 0000:02:02.0: PCI bridge to [bus 04]
pci 0000:02:03.0: PCI bridge to [bus 05]
pci 0000:02:0c.0: PCI bridge to [bus 06]
pci 0000:02:10.0: PCI bridge to [bus 07]
pci 0000:08:00.0: BAR 0: assigned [mem 0x50100000-0x50103fff 64bit]
pci 0000:08:00.0: BAR 2: assigned [io  0x2000-0x20ff]
pci 0000:02:1f.0: PCI bridge to [bus 08]
pci 0000:02:1f.0:   bridge window [io  0x2000-0x2fff]
pci 0000:02:1f.0:   bridge window [mem 0x50100000-0x501fffff]
pci 0000:01:00.0: PCI bridge to [bus 02-08]
pci 0000:01:00.0:   bridge window [io  0x1000-0x2fff]
pci 0000:01:00.0:   bridge window [mem 0x50000000-0x501fffff]
pci 0000:00:00.0: PCI bridge to [bus 01-08]
pci 0000:00:00.0:   bridge window [io  0x1000-0x2fff]
pci 0000:00:00.0:   bridge window [mem 0x50000000-0x501fffff]
pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt
pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
pci 0000:02:01.0: Signaling PME through PCIe PME interrupt
pci 0000:03:00.0: Signaling PME through PCIe PME interrupt
pci 0000:02:02.0: Signaling PME through PCIe PME interrupt
pci 0000:02:03.0: Signaling PME through PCIe PME interrupt
pci 0000:02:0c.0: Signaling PME through PCIe PME interrupt
pci 0000:02:10.0: Signaling PME through PCIe PME interrupt
pci 0000:02:1f.0: Signaling PME through PCIe PME interrupt
pci 0000:08:00.0: Signaling PME through PCIe PME interrupt
xenfs: not registering filesystem on non-xen platform
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
msm_serial: driver initialized
loop: module loaded
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk at qualcomm.com>
sky2: driver version 1.30
sky2 0000:08:00.0: enabling device (0000 -> 0003)
sky2 0000:08:00.0: Yukon-2 UL 2 chip revision 0
sky2 0000:08:00.0 (unnamed net_device) (uninitialized): Invalid MAC address, def
aulting to random
sky2 0000:08:00.0 eth0: addr c6:94:53:3d:70:00
libphy: smsc911x-mdio: probed
Generic PHY 18000000.etherne:01: attached PHY driver [Generic PHY] (mii_bus:phy_
addr=18000000.etherne:01, irq=-1)
smsc911x 18000000.ethernet eth1: MAC Address: 00:02:f7:00:60:c5
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-platform: EHCI generic platform driver
ehci-platform 7ffc0000.ehci: EHCI Host Controller
ehci-platform 7ffc0000.ehci: new USB bus registered, assigned bus number 1
ehci-platform 7ffc0000.ehci: irq 28, io mem 0x7ffc0000
ehci-platform 7ffc0000.ehci: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-pci: OHCI PCI platform driver
ohci-platform: OHCI generic platform driver
ohci-platform 7ffb0000.ohci: Generic Platform OHCI controller
ohci-platform 7ffb0000.ohci: new USB bus registered, assigned bus number 2
ohci-platform 7ffb0000.ohci: irq 27, io mem 0x7ffb0000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
mmci-pl18x 1c050000.mmci: mmc0: PL180 manf 41 rev0 at 0x1c050000 irq 33,0 (pio)
mmci-pl18x 1c050000.mmci: DMA channels RX none, TX none
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
Synopsys Designware Multimedia Card Interface Driver
sdhci-pltfm: SDHCI platform and OF driver helper
ledtrig-cpu: registered to indicate activity on CPUs
EFI Variables Facility v0.08 2004-May-17
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
NET: Registered protocol family 17
9pnet: Installing 9P2000 support
Key type dns_resolver registered
registered taskstats version 1
rtc-efi rtc-efi: setting system clock to 2016-02-01 08:26:43 UTC (1454315203)
sky2 0000:08:00.0 eth0: enabling interface
smsc911x 18000000.ethernet eth1: SMSC911x/921x identified at 0xffff000000120000,
 IRQ: 31
usb 1-1: new high-speed USB device number 2 using ehci-platform
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1.2: new high-speed USB device number 3 using ehci-platform
usb-storage 1-1.2:1.0: USB Mass Storage device detected
scsi host0: usb-storage 1-1.2:1.0
atkbd serio0: keyboard reset failed on 1c060000.kmi
scsi 0:0:0:0: Direct-Access     TOSHIBA  TransMemory      1.00 PQ: 0 ANSI: 4
sd 0:0:0:0: [sda] 15155200 512-byte logical blocks: (7.76 GB/7.23 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DP
O or FUA
 sda: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI removable disk
atkbd serio1: keyboard reset failed on 1c070000.kmi
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 10.xx.xx.xx, my address is 10.xx.xx.xx
sky2 0000:08:00.0 eth0: disabling interface
IP-Config: Complete:
     device=eth1, hwaddr=00:02:f7:xx:xx:xx, ipaddr=10.xx.xx.xx, mask=255.255.255
.0, gw=10.xx.xx.xx
     host=10.xx.xx.xx, domain=cambridge.arm.com, nis-domain=(none)
     bootserver=0.0.0.0, rootserver=10.xx.xx.xx, rootpath=     nameserver0=10.xx
.xx.xx, nameserver1=10.xx.xx.xx
Freezing user space processes ... (elapsed 0.000 seconds) done.
PM: Using 1 thread(s) for decompression.
PM: Loading and decompressing image data (94052 pages)...
PM: Image loading progress:   0%
PM: Image loading progress:  10%
PM: Image loading progress:  20%
PM: Image loading progress:  30%
PM: Image loading progress:  40%
PM: Image loading progress:  50%
PM: Image loading progress:  60%
PM: Image loading progress:  70%
PM: Image loading progress:  80%
PM: Image loading progress:  90%
PM: Image loading progress: 100%
PM: Image loading done.
PM: Read 376208 kbytes in 7.09 seconds (53.06 MB/s)
PM: quiesce of devices complete after 16.499 msecs
PM: late quiesce of devices complete after 0.938 msecs
PM: noirq quiesce of devices complete after 11.044 msecs
Disabling non-boot CPUs ...
PM: noirq restore of devices complete after 2.397 msecs
PM: early restore of devices complete after 0.917 msecs
serio serio0: device_attach() failed for 1c060000.kmi (1c060000.kmi), error: -51
7
serio serio1: device_attach() failed for 1c070000.kmi (1c070000.kmi), error: -51
7
PM: restore of devices complete after 93.241 msecs
serio serio0: device_attach() failed for 1c060000.kmi (1c060000.kmi), error: -51
7
Restarting tasks ... done.
atkbd serio0: keyboard reset failed on 1c060000.kmi
atkbd serio1: keyboard reset failed on 1c070000.kmi
atkbd serio1: keyboard reset failed on 1c070000.kmi
root at localhost:/sys/power#
root at localhost:/sys/power# uptime
 08:27:00 up 2 days, 16:57,  2 users,  load average: 0.37, 0.14, 0.09
root at localhost:/sys/power#




From linus.walleij at linaro.org  Mon Feb  1 00:55:45 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  1 Feb 2016 09:55:45 +0100
Subject: [PATCH 1/3] ARM: realview: activate SMP on the default defconfig
Message-ID: <1454316945-4426-1-git-send-email-linus.walleij@linaro.org>

The realview has two defconfigs: realview_defconfig and
realview-smp_defconfig. We now have working SMP_ON_UP so
make them equal so we can delete the -smp variant. For
some reason NO_HZ_FULL was missing from the plain
realview_defconfig.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/configs/realview_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/realview_defconfig b/arch/arm/configs/realview_defconfig
index 8f56fb3ff51d..9f84c508a5f4 100644
--- a/arch/arm/configs/realview_defconfig
+++ b/arch/arm/configs/realview_defconfig
@@ -1,5 +1,6 @@
 # CONFIG_SWAP is not set
 CONFIG_SYSVIPC=y
+CONFIG_NO_HZ_FULL=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_PERF_EVENTS=y
@@ -21,6 +22,7 @@ CONFIG_MACH_REALVIEW_PB11MP=y
 CONFIG_MACH_REALVIEW_PB1176=y
 CONFIG_MACH_REALVIEW_PBA8=y
 CONFIG_MACH_REALVIEW_PBX=y
+CONFIG_SMP=y
 CONFIG_AEABI=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
-- 
2.4.3



From linus.walleij at linaro.org  Mon Feb  1 00:55:55 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  1 Feb 2016 09:55:55 +0100
Subject: [PATCH 2/3] ARM: realview: delete realview-smp_defconfig
Message-ID: <1454316955-4474-1-git-send-email-linus.walleij@linaro.org>

We enabled SMP in the realview_defconfig so delete the
SMP-specific defconfig.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/configs/realview-smp_defconfig | 105 --------------------------------
 1 file changed, 105 deletions(-)
 delete mode 100644 arch/arm/configs/realview-smp_defconfig

diff --git a/arch/arm/configs/realview-smp_defconfig b/arch/arm/configs/realview-smp_defconfig
deleted file mode 100644
index 93efdcfcf98f..000000000000
--- a/arch/arm/configs/realview-smp_defconfig
+++ /dev/null
@@ -1,105 +0,0 @@
-# CONFIG_SWAP is not set
-CONFIG_SYSVIPC=y
-CONFIG_NO_HZ_FULL=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
-CONFIG_LOG_BUF_SHIFT=14
-CONFIG_PERF_EVENTS=y
-CONFIG_SLAB=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-# CONFIG_BLK_DEV_BSG is not set
-# CONFIG_IOSCHED_CFQ is not set
-CONFIG_ARCH_MULTI_V6=y
-CONFIG_ARCH_REALVIEW=y
-CONFIG_REALVIEW_DT=y
-CONFIG_MACH_REALVIEW_EB=y
-CONFIG_REALVIEW_EB_ARM1136=y
-CONFIG_REALVIEW_EB_ARM1176=y
-CONFIG_REALVIEW_EB_A9MP=y
-CONFIG_REALVIEW_EB_ARM11MP=y
-CONFIG_REALVIEW_EB_ARM11MP_REVB=y
-CONFIG_MACH_REALVIEW_PB11MP=y
-CONFIG_MACH_REALVIEW_PB1176=y
-CONFIG_MACH_REALVIEW_PBA8=y
-CONFIG_MACH_REALVIEW_PBX=y
-CONFIG_SMP=y
-CONFIG_AEABI=y
-CONFIG_ZBOOT_ROM_TEXT=0x0
-CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_CMDLINE="root=/dev/nfs nfsroot=10.1.69.3:/work/nfsroot ip=dhcp console=ttyAMA0 mem=128M"
-CONFIG_VFP=y
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_INET=y
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=y
-CONFIG_IP_PNP_BOOTP=y
-# CONFIG_INET_LRO is not set
-# CONFIG_IPV6 is not set
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_MTD=y
-CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_AFS_PARTS=y
-CONFIG_MTD_BLOCK=y
-CONFIG_MTD_CFI=y
-CONFIG_MTD_CFI_INTELEXT=y
-CONFIG_MTD_CFI_AMDSTD=y
-CONFIG_MTD_ROM=y
-CONFIG_MTD_PHYSMAP=y
-CONFIG_ARM_CHARLCD=y
-CONFIG_NETDEVICES=y
-CONFIG_SMC91X=y
-CONFIG_SMSC911X=y
-CONFIG_SMSC_PHY=y
-# CONFIG_SERIO_SERPORT is not set
-CONFIG_SERIO_AMBAKMI=y
-CONFIG_LEGACY_PTY_COUNT=16
-CONFIG_SERIAL_AMBA_PL011=y
-CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
-# CONFIG_HW_RANDOM is not set
-CONFIG_I2C=y
-CONFIG_I2C_VERSATILE=y
-CONFIG_SPI=y
-CONFIG_GPIOLIB=y
-# CONFIG_HWMON is not set
-CONFIG_FB=y
-CONFIG_FB_ARMCLCD=y
-CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_LOGO=y
-# CONFIG_LOGO_LINUX_MONO is not set
-# CONFIG_LOGO_LINUX_VGA16 is not set
-CONFIG_SOUND=y
-CONFIG_SND=y
-CONFIG_SND_MIXER_OSS=y
-CONFIG_SND_PCM_OSS=y
-# CONFIG_SND_DRIVERS is not set
-CONFIG_SND_ARMAACI=y
-CONFIG_USB=y
-CONFIG_USB_ISP1760=y
-CONFIG_MMC=y
-CONFIG_MMC_ARMMMCI=y
-CONFIG_NEW_LEDS=y
-CONFIG_LEDS_CLASS=y
-CONFIG_LEDS_VERSATILE=y
-CONFIG_LEDS_TRIGGERS=y
-CONFIG_LEDS_TRIGGER_HEARTBEAT=y
-CONFIG_LEDS_TRIGGER_CPU=y
-CONFIG_RTC_CLASS=y
-CONFIG_RTC_DRV_DS1307=y
-CONFIG_RTC_DRV_PL031=y
-CONFIG_VFAT_FS=y
-CONFIG_TMPFS=y
-CONFIG_CRAMFS=y
-CONFIG_NFS_FS=y
-CONFIG_ROOT_NFS=y
-CONFIG_NLS_CODEPAGE_437=y
-CONFIG_NLS_ISO8859_1=y
-CONFIG_DEBUG_FS=y
-CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_KERNEL=y
-# CONFIG_SCHED_DEBUG is not set
-# CONFIG_FTRACE is not set
-CONFIG_DEBUG_USER=y
-# CONFIG_CRYPTO_HW is not set
-- 
2.4.3



From linus.walleij at linaro.org  Mon Feb  1 00:56:05 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  1 Feb 2016 09:56:05 +0100
Subject: [PATCH 3/3] ARM: realview: enable USB storage in the defconfig
Message-ID: <1454316965-4520-1-git-send-email-linus.walleij@linaro.org>

It is not uncommon to boot a root filesystem from a USB
pendrive and similar, so enable USB mass storage, backed
by SCSI and SD block devices in the RealView defconfig.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/configs/realview_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/realview_defconfig b/arch/arm/configs/realview_defconfig
index 9f84c508a5f4..9e77dc7b828f 100644
--- a/arch/arm/configs/realview_defconfig
+++ b/arch/arm/configs/realview_defconfig
@@ -48,6 +48,8 @@ CONFIG_MTD_CFI_AMDSTD=y
 CONFIG_MTD_ROM=y
 CONFIG_MTD_PHYSMAP=y
 CONFIG_ARM_CHARLCD=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
 CONFIG_NETDEVICES=y
 CONFIG_SMC91X=y
 CONFIG_SMSC911X=y
@@ -76,6 +78,7 @@ CONFIG_SND_PCM_OSS=y
 # CONFIG_SND_DRIVERS is not set
 CONFIG_SND_ARMAACI=y
 CONFIG_USB=y
+CONFIG_USB_STORAGE=y
 CONFIG_USB_ISP1760=y
 CONFIG_MMC=y
 CONFIG_MMC_ARMMMCI=y
-- 
2.4.3



From p.zabel at pengutronix.de  Mon Feb  1 00:56:58 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon, 01 Feb 2016 09:56:58 +0100
Subject: [PATCH v5 5/6] reset: mediatek: Add MT2701 reset controller
 dt-binding file
In-Reply-To: <1453879264-37915-6-git-send-email-jamesjj.liao@mediatek.com>
References: <1453879264-37915-1-git-send-email-jamesjj.liao@mediatek.com>
 <1453879264-37915-6-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <1454317018.3447.3.camel@pengutronix.de>

Am Mittwoch, den 27.01.2016, 15:21 +0800 schrieb James Liao:
> From: Shunli Wang <shunli.wang at mediatek.com>
> 
> Dt-binding file about reset controller is used to provide
> kinds of definition, which is referenced by dts file and
> IC-specified reset controller driver code.
> 
> Signed-off-by: Shunli Wang <shunli.wang at mediatek.com>
> Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
> Tested-by: John Crispin <blogic at openwrt.org>

In case you missed my Acked-by for patches 5 and 6, it still stands.

regards
Philipp




From linus.walleij at linaro.org  Mon Feb  1 00:57:27 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  1 Feb 2016 09:57:27 +0100
Subject: [PATCH 1/5] ARM: pb1176: add ICST307 clocks to the device tree
Message-ID: <1454317047-4698-1-git-send-email-linus.walleij@linaro.org>

This adds the five ICST307 clocks to the device tree, so we
can use these with e.g. CLCD.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/arm-realview-pb1176.dts | 35 +++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/boot/dts/arm-realview-pb1176.dts b/arch/arm/boot/dts/arm-realview-pb1176.dts
index 1bc64cda819e..5edcf596eccc 100644
--- a/arch/arm/boot/dts/arm-realview-pb1176.dts
+++ b/arch/arm/boot/dts/arm-realview-pb1176.dts
@@ -176,6 +176,41 @@
 				label = "versatile:7";
 				default-state = "off";
 			};
+			oscclk0: osc0 at 0c {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x0C>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk1: osc1 at 10 {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x10>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk2: osc2 at 14 {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x14>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk3: osc3 at 18 {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x18>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk4: osc4 at 1c {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x1c>;
+				clocks = <&xtal24mhz>;
+			};
 		};
 
 		/* Primary DevChip GIC synthesized with the CPU */
-- 
2.4.3



From linus.walleij at linaro.org  Mon Feb  1 00:57:40 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  1 Feb 2016 09:57:40 +0100
Subject: [PATCH 2/5] ARM: pb1176: add AACI to the device tree
Message-ID: <1454317060-4744-1-git-send-email-linus.walleij@linaro.org>

The device tree was missing the definition of the AACI
Advanced Audio Codec Interface, so add it. Tested on the hardware
and it works.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/arm-realview-pb1176.dts | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/arm-realview-pb1176.dts b/arch/arm/boot/dts/arm-realview-pb1176.dts
index 5edcf596eccc..3d2938c73c4e 100644
--- a/arch/arm/boot/dts/arm-realview-pb1176.dts
+++ b/arch/arm/boot/dts/arm-realview-pb1176.dts
@@ -341,6 +341,15 @@
 		compatible = "simple-bus";
 		ranges;
 
+		fpga_aaci: aaci at 10004000 {
+			compatible = "arm,pl041", "arm,primecell";
+			reg = <0x10004000 0x1000>;
+			interrupt-parent = <&intc_fpga1176>;
+			interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
 		fpga_mci: mmcsd at 10005000 {
 			compatible = "arm,pl18x", "arm,primecell";
 			reg = <0x10005000 0x1000>;
-- 
2.4.3



From linus.walleij at linaro.org  Mon Feb  1 00:57:48 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  1 Feb 2016 09:57:48 +0100
Subject: [PATCH 3/5] ARM: pb1176: add ISP1761 USB OTG host controller
Message-ID: <1454317068-4790-1-git-send-email-linus.walleij@linaro.org>

The USB host controller was missing from the device tree so add
it. This device is not inside either the development chip or the
FPGA but mounted on the board, so it ends up in the root node of
the device tree.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/arm-realview-pb1176.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/arm-realview-pb1176.dts b/arch/arm/boot/dts/arm-realview-pb1176.dts
index 3d2938c73c4e..70a1ec3bedb9 100644
--- a/arch/arm/boot/dts/arm-realview-pb1176.dts
+++ b/arch/arm/boot/dts/arm-realview-pb1176.dts
@@ -106,6 +106,14 @@
 		clock-frequency = <0>;
 	};
 
+	usb at 3b000000 {
+		compatible = "nxp,usb-isp1761";
+		reg = <0x3b000000 0x20000>;
+		interrupt-parent = <&intc_fpga1176>;
+		interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+		port1-otg;
+	};
+
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
2.4.3



From linus.walleij at linaro.org  Mon Feb  1 00:57:56 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  1 Feb 2016 09:57:56 +0100
Subject: [PATCH 4/5] ARM: pb1176: add ethernet to devicetree
Message-ID: <1454317076-4836-1-git-send-email-linus.walleij@linaro.org>

The PB1176 device tree was missing the SMSC9118 ethernet adapter,
so add it. Since this peripheral is not in either development
chip but on the board itself, it gets defined in the root node
of the device tree.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/arm-realview-pb1176.dts | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/arm-realview-pb1176.dts b/arch/arm/boot/dts/arm-realview-pb1176.dts
index 70a1ec3bedb9..95ea12b32aa5 100644
--- a/arch/arm/boot/dts/arm-realview-pb1176.dts
+++ b/arch/arm/boot/dts/arm-realview-pb1176.dts
@@ -53,6 +53,14 @@
 		regulator-boot-on;
         };
 
+	veth: fixedregulator at 0 {
+		compatible = "regulator-fixed";
+		regulator-name = "veth";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+	};
+
 	xtal24mhz: xtal24mhz at 24M {
 		#clock-cells = <0>;
 		compatible = "fixed-clock";
@@ -106,6 +114,20 @@
 		clock-frequency = <0>;
 	};
 
+	/* SMSC 9118 ethernet with PHY and EEPROM */
+	ethernet at 3a000000 {
+		compatible = "smsc,lan9118", "smsc,lan9115";
+		reg = <0x3a000000 0x10000>;
+		interrupt-parent = <&intc_fpga1176>;
+		interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+		phy-mode = "mii";
+		reg-io-width = <4>;
+		smsc,irq-active-high;
+		smsc,irq-push-pull;
+		vdd33a-supply = <&veth>;
+		vddvario-supply = <&veth>;
+	};
+
 	usb at 3b000000 {
 		compatible = "nxp,usb-isp1761";
 		reg = <0x3b000000 0x20000>;
-- 
2.4.3



From linus.walleij at linaro.org  Mon Feb  1 00:58:03 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  1 Feb 2016 09:58:03 +0100
Subject: [PATCH 5/5] ARM: realview: add the DS1338 RTC to PB1176 DT
Message-ID: <1454317083-4882-1-git-send-email-linus.walleij@linaro.org>

This adds the Versatile I2C adapter and the Dallas DS1338
RTC on it to the PB1176 device tree.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/arm-realview-pb1176.dts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/arm-realview-pb1176.dts b/arch/arm/boot/dts/arm-realview-pb1176.dts
index 95ea12b32aa5..d012ecf25127 100644
--- a/arch/arm/boot/dts/arm-realview-pb1176.dts
+++ b/arch/arm/boot/dts/arm-realview-pb1176.dts
@@ -371,6 +371,18 @@
 		compatible = "simple-bus";
 		ranges;
 
+		i2c0: i2c at 10002000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "arm,versatile-i2c";
+			reg = <0x10002000 0x1000>;
+
+			rtc at 68 {
+				compatible = "dallas,ds1338";
+				reg = <0x68>;
+			};
+		};
+
 		fpga_aaci: aaci at 10004000 {
 			compatible = "arm,pl041", "arm,primecell";
 			reg = <0x10004000 0x1000>;
-- 
2.4.3



From gg at slimlogic.co.uk  Mon Feb  1 01:01:26 2016
From: gg at slimlogic.co.uk (Graeme Gregory)
Date: Mon, 1 Feb 2016 09:01:26 +0000
Subject: [PATCH 2/3] ACPI: parse SPCR and enable matching console
In-Reply-To: <1453722324-22407-3-git-send-email-aleksey.makarov@linaro.org>
References: <1453722324-22407-1-git-send-email-aleksey.makarov@linaro.org>
 <1453722324-22407-3-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <20160201090126.GA18693@xora-haswell.xora.org.uk>

On Mon, Jan 25, 2016 at 05:45:22PM +0600, Aleksey Makarov wrote:
> 'ARM Server Base Boot Requiremets' [1] mention SPCR
> (Serial Port Console Redirection Table) [2] as a mandatory ACPI table
> that specifies the configuration of serial console.
> 
> Parse this table and check if any registered console match
> the description.  If it does, enable that console.
> 
> To implement that, introduce a new member
> int (*acpi_match)(struct console *, struct acpi_table_spcr *)
> of struct console.  It allows drivers to check if they provide
> a matching console device.
> 

Fails to compile on x86

kernel/built-in.o: In function `register_console':
(.text+0x48cba): undefined reference to `console_acpi_match'
Makefile:929: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1

Because CONFIG_ACPI_SPCR_TABLE is never set.

Graeme


> [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
> [2] http://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
> 
> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> ---
>  arch/arm64/Kconfig      |  1 +
>  drivers/acpi/Kconfig    |  3 ++
>  drivers/acpi/Makefile   |  1 +
>  drivers/acpi/spcr.c     | 85 +++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/console.h | 12 +++++++
>  kernel/printk/printk.c  | 82 +++++++++++++++++++++++++++++++++++++----------
>  6 files changed, 167 insertions(+), 17 deletions(-)
>  create mode 100644 drivers/acpi/spcr.c
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 573bebc..bf31e3c 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -4,6 +4,7 @@ config ARM64
>  	select ACPI_GENERIC_GSI if ACPI
>  	select ACPI_PCI_HOST_GENERIC if ACPI
>  	select ACPI_REDUCED_HARDWARE_ONLY if ACPI
> +	select ACPI_SPCR_TABLE if ACPI
>  	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
>  	select ARCH_HAS_ELF_RANDOMIZE
>  	select ARCH_HAS_GCOV_PROFILE_ALL
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index e315061..142a338 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -60,6 +60,9 @@ config ACPI_CCA_REQUIRED
>  config IORT_TABLE
>  	bool
>  
> +config ACPI_SPCR_TABLE
> +	bool
> +
>  config ACPI_DEBUGGER
>  	bool "AML debugger interface (EXPERIMENTAL)"
>  	select ACPI_DEBUG
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 265eb90..8316859 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -81,6 +81,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
>  obj-$(CONFIG_ACPI_BGRT)		+= bgrt.o
>  obj-$(CONFIG_ACPI_CPPC_LIB)	+= cppc_acpi.o
>  obj-$(CONFIG_IORT_TABLE) 	+= iort.o
> +obj-$(CONFIG_ACPI_SPCR_TABLE)	+= spcr.o
>  
>  # processor has its own "processor." module_param namespace
>  processor-y			:= processor_driver.o
> diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
> new file mode 100644
> index 0000000..ccb19a0
> --- /dev/null
> +++ b/drivers/acpi/spcr.c
> @@ -0,0 +1,85 @@
> +/*
> + * Copyright (c) 2012, Intel Corporation
> + * Copyright (c) 2015, Red Hat, Inc.
> + * Copyright (c) 2015, 2016 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#define pr_fmt(fmt) "ACPI: SPCR: " fmt
> +
> +#include <linux/acpi.h>
> +#include <linux/console.h>
> +#include <linux/kernel.h>
> +
> +static struct acpi_table_spcr *spcr_table;
> +
> +int console_acpi_match(struct console *c, char **options)
> +{
> +	int err;
> +
> +	if (!c->acpi_match)
> +		return -ENODEV;
> +
> +	if (!spcr_table)
> +		return -EAGAIN;
> +
> +	err = c->acpi_match(c, spcr_table);
> +	if (err < 0)
> +		return err;
> +
> +	if (options) {
> +		switch (spcr_table->baud_rate) {
> +		case 3:
> +			*options = "9600";
> +			break;
> +		case 4:
> +			*options = "19200";
> +			break;
> +		case 6:
> +			*options = "57600";
> +			break;
> +		case 7:
> +			*options = "115200";
> +			break;
> +		default:
> +			*options = "";
> +			break;
> +		}
> +	}
> +
> +	return err;
> +}
> +
> +static int __init spcr_table_detect(void)
> +{
> +	struct acpi_table_header *table;
> +	acpi_status status;
> +
> +	if (acpi_disabled)
> +		return -ENODEV;
> +
> +	status = acpi_get_table(ACPI_SIG_SPCR, 0, &table);
> +	if (ACPI_FAILURE(status)) {
> +		const char *msg = acpi_format_exception(status);
> +
> +		pr_err("Failed to get table, %s\n", msg);
> +		return -EINVAL;
> +	}
> +
> +	if (table->revision < 2)
> +		return -EOPNOTSUPP;
> +
> +	spcr_table = (struct acpi_table_spcr *)table;
> +
> +	pr_info("Console at 0x%016llx\n", spcr_table->serial_port.address);
> +
> +	acpi_register_consoles_try_again();
> +
> +	return 0;
> +}
> +
> +arch_initcall(spcr_table_detect);
> diff --git a/include/linux/console.h b/include/linux/console.h
> index bd19434..94d0bd8 100644
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -117,6 +117,7 @@ static inline int con_debug_leave(void)
>  #define CON_BRL		(32) /* Used for a braille device */
>  #define CON_EXTENDED	(64) /* Use the extended output format a la /dev/kmsg */
>  
> +struct acpi_table_spcr;
>  struct console {
>  	char	name[16];
>  	void	(*write)(struct console *, const char *, unsigned);
> @@ -125,6 +126,7 @@ struct console {
>  	void	(*unblank)(void);
>  	int	(*setup)(struct console *, char *);
>  	int	(*match)(struct console *, char *name, int idx, char *options);
> +	int	(*acpi_match)(struct console *, struct acpi_table_spcr *);
>  	short	flags;
>  	short	index;
>  	int	cflag;
> @@ -132,6 +134,16 @@ struct console {
>  	struct	 console *next;
>  };
>  
> +#ifdef CONFIG_ACPI
> +int console_acpi_match(struct console *c, char **options);
> +#else
> +static inline int console_acpi_match(struct console *c, char **options)
> +{
> +	return -ENODEV;
> +}
> +#endif
> +void acpi_register_consoles_try_again(void);
> +
>  /*
>   * for_each_console() allows you to iterate on each console
>   */
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 37e531f..3cf8cba 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2430,6 +2430,25 @@ static int __init keep_bootcon_setup(char *str)
>  
>  early_param("keep_bootcon", keep_bootcon_setup);
>  
> +static DEFINE_MUTEX(acpi_consoles_delayed_mutex);
> +static struct console *acpi_consoles_delayed;
> +
> +void acpi_register_consoles_try_again(void)
> +{
> +	mutex_lock(&acpi_consoles_delayed_mutex);
> +	while (acpi_consoles_delayed) {
> +
> +		struct console *c = acpi_consoles_delayed;
> +
> +		acpi_consoles_delayed = acpi_consoles_delayed->next;
> +
> +		mutex_unlock(&acpi_consoles_delayed_mutex);
> +		register_console(c);
> +		mutex_lock(&acpi_consoles_delayed_mutex);
> +	}
> +	mutex_unlock(&acpi_consoles_delayed_mutex);
> +}
> +
>  /*
>   * The console driver calls this routine during kernel initialization
>   * to register the console printing procedure with printk() and to
> @@ -2538,8 +2557,30 @@ void register_console(struct console *newcon)
>  		break;
>  	}
>  
> -	if (!(newcon->flags & CON_ENABLED))
> -		return;
> +	if (!(newcon->flags & CON_ENABLED)) {
> +		char *opts;
> +		int err;
> +
> +		if (newcon->index < 0)
> +			newcon->index = 0;
> +
> +		err = console_acpi_match(newcon, &opts);
> +
> +		if (err == -EAGAIN) {
> +			mutex_lock(&acpi_consoles_delayed_mutex);
> +			newcon->next = acpi_consoles_delayed;
> +			acpi_consoles_delayed = newcon;
> +			mutex_unlock(&acpi_consoles_delayed_mutex);
> +			return;
> +		} else if (err < 0) {
> +			return;
> +		} else {
> +			if (newcon->setup && newcon->setup(newcon, opts) != 0)
> +				return;
> +			newcon->flags |= CON_ENABLED | CON_CONSDEV;
> +			preferred_console = true;
> +		}
> +	}
>  
>  	/*
>  	 * If we have a bootconsole, and are switching to a real console,
> @@ -2612,34 +2653,41 @@ void register_console(struct console *newcon)
>  }
>  EXPORT_SYMBOL(register_console);
>  
> +static int delete_from_console_list(struct console **list, struct console *c)
> +{
> +	while (*list) {
> +		struct console *cur = *list;
> +
> +		if (cur == c) {
> +			*list = cur->next;
> +			return 0;
> +		}
> +		list = &cur->next;
> +	}
> +	return 1;
> +}
> +
>  int unregister_console(struct console *console)
>  {
> -        struct console *a, *b;
>  	int res;
>  
>  	pr_info("%sconsole [%s%d] disabled\n",
>  		(console->flags & CON_BOOT) ? "boot" : "" ,
>  		console->name, console->index);
>  
> +	mutex_lock(&acpi_consoles_delayed_mutex);
> +	res = delete_from_console_list(&acpi_consoles_delayed, console);
> +	mutex_unlock(&acpi_consoles_delayed_mutex);
> +	if (res == 0)
> +		return res;
> +
>  	res = _braille_unregister_console(console);
>  	if (res)
>  		return res;
>  
> -	res = 1;
>  	console_lock();
> -	if (console_drivers == console) {
> -		console_drivers=console->next;
> -		res = 0;
> -	} else if (console_drivers) {
> -		for (a=console_drivers->next, b=console_drivers ;
> -		     a; b=a, a=b->next) {
> -			if (a == console) {
> -				b->next = a->next;
> -				res = 0;
> -				break;
> -			}
> -		}
> -	}
> +
> +	res = delete_from_console_list(&console_drivers, console);
>  
>  	if (!res && (console->flags & CON_EXTENDED))
>  		nr_ext_console_drivers--;
> -- 
> 2.7.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From gg at slimlogic.co.uk  Mon Feb  1 01:13:05 2016
From: gg at slimlogic.co.uk (Graeme Gregory)
Date: Mon, 1 Feb 2016 09:13:05 +0000
Subject: [PATCH 2/3] ACPI: parse SPCR and enable matching console
In-Reply-To: <20160201090126.GA18693@xora-haswell.xora.org.uk>
References: <1453722324-22407-1-git-send-email-aleksey.makarov@linaro.org>
 <1453722324-22407-3-git-send-email-aleksey.makarov@linaro.org>
 <20160201090126.GA18693@xora-haswell.xora.org.uk>
Message-ID: <20160201091305.GB18693@xora-haswell.xora.org.uk>

On Mon, Feb 01, 2016 at 09:01:26AM +0000, Graeme Gregory wrote:
> On Mon, Jan 25, 2016 at 05:45:22PM +0600, Aleksey Makarov wrote:
> > 'ARM Server Base Boot Requiremets' [1] mention SPCR
> > (Serial Port Console Redirection Table) [2] as a mandatory ACPI table
> > that specifies the configuration of serial console.
> > 
> > Parse this table and check if any registered console match
> > the description.  If it does, enable that console.
> > 
> > To implement that, introduce a new member
> > int (*acpi_match)(struct console *, struct acpi_table_spcr *)
> > of struct console.  It allows drivers to check if they provide
> > a matching console device.
> > 
> 
> Fails to compile on x86
> 
> kernel/built-in.o: In function `register_console':
> (.text+0x48cba): undefined reference to `console_acpi_match'
> Makefile:929: recipe for target 'vmlinux' failed
> make: *** [vmlinux] Error 1
> 
> Because CONFIG_ACPI_SPCR_TABLE is never set.
> 
> Graeme
> 
> 
> > [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
> > [2] http://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
> > 
> > Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> > ---
> >  arch/arm64/Kconfig      |  1 +
> >  drivers/acpi/Kconfig    |  3 ++
> >  drivers/acpi/Makefile   |  1 +
> >  drivers/acpi/spcr.c     | 85 +++++++++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/console.h | 12 +++++++
> >  kernel/printk/printk.c  | 82 +++++++++++++++++++++++++++++++++++++----------
> >  6 files changed, 167 insertions(+), 17 deletions(-)
> >  create mode 100644 drivers/acpi/spcr.c
> > 
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 573bebc..bf31e3c 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -4,6 +4,7 @@ config ARM64
> >  	select ACPI_GENERIC_GSI if ACPI
> >  	select ACPI_PCI_HOST_GENERIC if ACPI
> >  	select ACPI_REDUCED_HARDWARE_ONLY if ACPI
> > +	select ACPI_SPCR_TABLE if ACPI
> >  	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> >  	select ARCH_HAS_ELF_RANDOMIZE
> >  	select ARCH_HAS_GCOV_PROFILE_ALL
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > index e315061..142a338 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -60,6 +60,9 @@ config ACPI_CCA_REQUIRED
> >  config IORT_TABLE
> >  	bool
> >  
> > +config ACPI_SPCR_TABLE
> > +	bool
> > +
> >  config ACPI_DEBUGGER
> >  	bool "AML debugger interface (EXPERIMENTAL)"
> >  	select ACPI_DEBUG
> > diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> > index 265eb90..8316859 100644
> > --- a/drivers/acpi/Makefile
> > +++ b/drivers/acpi/Makefile
> > @@ -81,6 +81,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
> >  obj-$(CONFIG_ACPI_BGRT)		+= bgrt.o
> >  obj-$(CONFIG_ACPI_CPPC_LIB)	+= cppc_acpi.o
> >  obj-$(CONFIG_IORT_TABLE) 	+= iort.o
> > +obj-$(CONFIG_ACPI_SPCR_TABLE)	+= spcr.o
> >  
> >  # processor has its own "processor." module_param namespace
> >  processor-y			:= processor_driver.o
> > diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
> > new file mode 100644
> > index 0000000..ccb19a0
> > --- /dev/null
> > +++ b/drivers/acpi/spcr.c
> > @@ -0,0 +1,85 @@
> > +/*
> > + * Copyright (c) 2012, Intel Corporation
> > + * Copyright (c) 2015, Red Hat, Inc.
> > + * Copyright (c) 2015, 2016 Linaro Ltd.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + */
> > +
> > +#define pr_fmt(fmt) "ACPI: SPCR: " fmt
> > +
> > +#include <linux/acpi.h>
> > +#include <linux/console.h>
> > +#include <linux/kernel.h>
> > +
> > +static struct acpi_table_spcr *spcr_table;
> > +
> > +int console_acpi_match(struct console *c, char **options)
> > +{
> > +	int err;
> > +
> > +	if (!c->acpi_match)
> > +		return -ENODEV;
> > +
> > +	if (!spcr_table)
> > +		return -EAGAIN;
> > +
> > +	err = c->acpi_match(c, spcr_table);
> > +	if (err < 0)
> > +		return err;
> > +
> > +	if (options) {
> > +		switch (spcr_table->baud_rate) {
> > +		case 3:
> > +			*options = "9600";
> > +			break;
> > +		case 4:
> > +			*options = "19200";
> > +			break;
> > +		case 6:
> > +			*options = "57600";
> > +			break;
> > +		case 7:
> > +			*options = "115200";
> > +			break;
> > +		default:
> > +			*options = "";
> > +			break;
> > +		}
> > +	}
> > +
> > +	return err;
> > +}
> > +
> > +static int __init spcr_table_detect(void)
> > +{
> > +	struct acpi_table_header *table;
> > +	acpi_status status;
> > +
> > +	if (acpi_disabled)
> > +		return -ENODEV;
> > +
> > +	status = acpi_get_table(ACPI_SIG_SPCR, 0, &table);
> > +	if (ACPI_FAILURE(status)) {
> > +		const char *msg = acpi_format_exception(status);
> > +
> > +		pr_err("Failed to get table, %s\n", msg);
> > +		return -EINVAL;
> > +	}
> > +
> > +	if (table->revision < 2)
> > +		return -EOPNOTSUPP;
> > +
> > +	spcr_table = (struct acpi_table_spcr *)table;
> > +
> > +	pr_info("Console at 0x%016llx\n", spcr_table->serial_port.address);
> > +
> > +	acpi_register_consoles_try_again();
> > +
> > +	return 0;
> > +}
> > +
> > +arch_initcall(spcr_table_detect);
> > diff --git a/include/linux/console.h b/include/linux/console.h
> > index bd19434..94d0bd8 100644
> > --- a/include/linux/console.h
> > +++ b/include/linux/console.h
> > @@ -117,6 +117,7 @@ static inline int con_debug_leave(void)
> >  #define CON_BRL		(32) /* Used for a braille device */
> >  #define CON_EXTENDED	(64) /* Use the extended output format a la /dev/kmsg */
> >  
> > +struct acpi_table_spcr;
> >  struct console {
> >  	char	name[16];
> >  	void	(*write)(struct console *, const char *, unsigned);
> > @@ -125,6 +126,7 @@ struct console {
> >  	void	(*unblank)(void);
> >  	int	(*setup)(struct console *, char *);
> >  	int	(*match)(struct console *, char *name, int idx, char *options);
> > +	int	(*acpi_match)(struct console *, struct acpi_table_spcr *);
> >  	short	flags;
> >  	short	index;
> >  	int	cflag;
> > @@ -132,6 +134,16 @@ struct console {
> >  	struct	 console *next;
> >  };
> >  
> > +#ifdef CONFIG_ACPI

This should be #ifdef CONFIG_ACPI_SPCR_TABLE

> > +int console_acpi_match(struct console *c, char **options);
> > +#else
> > +static inline int console_acpi_match(struct console *c, char **options)
> > +{
> > +	return -ENODEV;

This requires a #include <linux/errno.h> at the top of the file to work.

Graeme

> > +}
> > +#endif
> > +void acpi_register_consoles_try_again(void);
> > +
> >  /*
> >   * for_each_console() allows you to iterate on each console
> >   */
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index 37e531f..3cf8cba 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -2430,6 +2430,25 @@ static int __init keep_bootcon_setup(char *str)
> >  
> >  early_param("keep_bootcon", keep_bootcon_setup);
> >  
> > +static DEFINE_MUTEX(acpi_consoles_delayed_mutex);
> > +static struct console *acpi_consoles_delayed;
> > +
> > +void acpi_register_consoles_try_again(void)
> > +{
> > +	mutex_lock(&acpi_consoles_delayed_mutex);
> > +	while (acpi_consoles_delayed) {
> > +
> > +		struct console *c = acpi_consoles_delayed;
> > +
> > +		acpi_consoles_delayed = acpi_consoles_delayed->next;
> > +
> > +		mutex_unlock(&acpi_consoles_delayed_mutex);
> > +		register_console(c);
> > +		mutex_lock(&acpi_consoles_delayed_mutex);
> > +	}
> > +	mutex_unlock(&acpi_consoles_delayed_mutex);
> > +}
> > +
> >  /*
> >   * The console driver calls this routine during kernel initialization
> >   * to register the console printing procedure with printk() and to
> > @@ -2538,8 +2557,30 @@ void register_console(struct console *newcon)
> >  		break;
> >  	}
> >  
> > -	if (!(newcon->flags & CON_ENABLED))
> > -		return;
> > +	if (!(newcon->flags & CON_ENABLED)) {
> > +		char *opts;
> > +		int err;
> > +
> > +		if (newcon->index < 0)
> > +			newcon->index = 0;
> > +
> > +		err = console_acpi_match(newcon, &opts);
> > +
> > +		if (err == -EAGAIN) {
> > +			mutex_lock(&acpi_consoles_delayed_mutex);
> > +			newcon->next = acpi_consoles_delayed;
> > +			acpi_consoles_delayed = newcon;
> > +			mutex_unlock(&acpi_consoles_delayed_mutex);
> > +			return;
> > +		} else if (err < 0) {
> > +			return;
> > +		} else {
> > +			if (newcon->setup && newcon->setup(newcon, opts) != 0)
> > +				return;
> > +			newcon->flags |= CON_ENABLED | CON_CONSDEV;
> > +			preferred_console = true;
> > +		}
> > +	}
> >  
> >  	/*
> >  	 * If we have a bootconsole, and are switching to a real console,
> > @@ -2612,34 +2653,41 @@ void register_console(struct console *newcon)
> >  }
> >  EXPORT_SYMBOL(register_console);
> >  
> > +static int delete_from_console_list(struct console **list, struct console *c)
> > +{
> > +	while (*list) {
> > +		struct console *cur = *list;
> > +
> > +		if (cur == c) {
> > +			*list = cur->next;
> > +			return 0;
> > +		}
> > +		list = &cur->next;
> > +	}
> > +	return 1;
> > +}
> > +
> >  int unregister_console(struct console *console)
> >  {
> > -        struct console *a, *b;
> >  	int res;
> >  
> >  	pr_info("%sconsole [%s%d] disabled\n",
> >  		(console->flags & CON_BOOT) ? "boot" : "" ,
> >  		console->name, console->index);
> >  
> > +	mutex_lock(&acpi_consoles_delayed_mutex);
> > +	res = delete_from_console_list(&acpi_consoles_delayed, console);
> > +	mutex_unlock(&acpi_consoles_delayed_mutex);
> > +	if (res == 0)
> > +		return res;
> > +
> >  	res = _braille_unregister_console(console);
> >  	if (res)
> >  		return res;
> >  
> > -	res = 1;
> >  	console_lock();
> > -	if (console_drivers == console) {
> > -		console_drivers=console->next;
> > -		res = 0;
> > -	} else if (console_drivers) {
> > -		for (a=console_drivers->next, b=console_drivers ;
> > -		     a; b=a, a=b->next) {
> > -			if (a == console) {
> > -				b->next = a->next;
> > -				res = 0;
> > -				break;
> > -			}
> > -		}
> > -	}
> > +
> > +	res = delete_from_console_list(&console_drivers, console);
> >  
> >  	if (!res && (console->flags & CON_EXTENDED))
> >  		nr_ext_console_drivers--;
> > -- 
> > 2.7.0
> > 
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From jens.wiklander at linaro.org  Mon Feb  1 01:15:36 2016
From: jens.wiklander at linaro.org (Jens Wiklander)
Date: Mon,  1 Feb 2016 10:15:36 +0100
Subject: [PATCH v7 0/4] generic TEE subsystem
Message-ID: <1454318140-7962-1-git-send-email-jens.wiklander@linaro.org>

Hi,

This patch set introduces a generic TEE subsystem. The TEE subsystem will
contain drivers for various TEE implementations. A TEE (Trusted Execution
Environment) is a trusted OS running in some secure environment, for
example, TrustZone on ARM CPUs, or a separate secure co-processor etc.

Regarding use cases, TrustZone has traditionally been used for
offloading secure tasks to the secure world. Examples include: 
- Secure key handling where the OS may or may not have direct access to key
  material.
- E-commerce and payment technologies. Credentials, credit card numbers etc
  could be stored in a more secure environment.
- Trusted User Interface (TUI) to ensure that no-one can snoop PIN-codes
  etc.
- Secure boot to ensure that loaded binaries haven?t been tampered with.
  It?s not strictly needed for secure boot, but you could enhance security
  by leveraging a TEE during boot.
- Digital Rights Management (DRM), the studios provides content with
  different resolution depending on the security of the device. Higher
  security means higher resolution.

A TEE could also be used in existing and new technologies. For example IMA
(Integrity Measurement Architecture) which has been in the kernel for quite
a while. Today you can enhance security by using a TPM-chip to sign the IMA
measurement list. This is something that you also could do by leveraging a
TEE.

Another example could be in 2-factor authentication which is becoming
increasingly more important. FIDO (https://fidoalliance.org) for example
are using public key cryptography in their 2-factor authentication standard
(U2F). With FIDO, a private and public key pair will be generated for every
site you visit and the private key should never leave the local device.
This is an example where you could use secure storage in a TEE for the
private key.

Today you will find a quite a few different out of tree implementations of
TEE drivers which tends to fragment the TEE ecosystem and development. We
think it would be a good idea to have a generic TEE driver integrated in
the kernel which would serve as a base for several different TEE solutions,
no matter if they are on-chip like TrustZone or if they are on a separate
crypto co-processor.

To develop this TEE subsystem we have been using the open source TEE called
OP-TEE (https://github.com/OP-TEE/optee_os) and therefore this would be the
first TEE solution supported by this new subsystem. OP-TEE is a
GlobalPlatform compliant TEE, however this TEE subsystem is not limited to
only GlobalPlatform TEEs, instead we have tried to design it so that it
should work with other TEE solutions also.

"tee: generic TEE subsystem" brings in the generic TEE subsystem which
helps when writing a driver for a specific TEE, for example, OP-TEE.

"tee: add OP-TEE driver" is an OP-TEE driver which uses the subsystem to do
its work.

This patch set has been prepared in cooperation with Javier Gonz?lez who
proposed "Generic TrustZone Driver in Linux Kernel" patches 28 Nov 2014,
https://lwn.net/Articles/623380/ . We've since then changed the scope to
TEE instead of TrustZone.

We have discussed the design on tee-dev at lists.linaro.org (archive at
https://lists.linaro.org/pipermail/tee-dev/) with people from other
companies, including Valentin Manea <valentin.manea at huawei.com>,
Emmanuel MICHEL <emmanuel.michel at st.com>,
Jean-michel DELORME <jean-michel.delorme at st.com>,
and Joakim Bech <joakim.bech at linaro.org>. Our main concern has been to
agree on something that is generic enough to support many different
TEEs while still keeping the interface together.

v7:
* Rebased on v4.5-rc2
* Moved the ARM SMC Calling Convention support into a separate patch
  set, which is now merged

v6:
* Rebased on v4.3-rc7
* Changed smccc interface to let the compiler marshal most of the
  parameters
* Added ARCH64 capability for smccc interface
* Changed the PSCI firmware calls (both arm and arm64) to use the new
  generic smccc interface instead instead of own assembly functions.
* Move optee DT bindings to below arm/firmware
* Defines method for OP-TEE driver to call secure world in DT, smc or hvc
* Exposes implementation id of a TEE driver in sysfs
  to easily spawn corresponding tee-supplicant when device is ready
* Update OP-TEE Message Protocol to better cope with fragmented physical
  memory
* Read time directly from OP-TEE driver instead of forwarding the RPC
  request to tee-supplicant

v5:
* Replaced kref reference counting for the device with a size_t instead as
  the counter is always protected by a mutex

v4:
* Rebased on 4.1
* Redesigned the synchronization around entry exit of normal SMC
* Replaced rwsem on the driver instance with kref and completion since
  rwsem wasn't intended to be used in this way
* Expanded the TEE_IOCTL_PARAM_ATTR_TYPE_MASK to make room for
  future additional parameter types
* Documents TEE subsystem and OP-TEE driver
* Replaced TEE_IOC_CMD with TEE_IOC_OPEN_SESSION, TEE_IOC_INVOKE,
  TEE_IOC_CANCEL and TEE_IOC_CLOSE_SESSION
* DT bindings in a separate patch
* Assembly parts moved to arch/arm and arch/arm64 respectively, in a
  separate patch
* Redefined/clarified the meaning of OPTEE_SMC_SHM_CACHED
* Removed CMA usage to limit the scope of the patch set

v3:
* Rebased on 4.1-rc3 (dma_buf_export() API change)
* A couple of small sparse fixes
* Documents bindings for OP-TEE driver
* Updated MAINTAINERS

v2:
* Replaced the stubbed OP-TEE driver with a real OP-TEE driver
* Removed most APIs not needed by OP-TEE in current state
* Update Documentation/ioctl/ioctl-number.txt with correct path to tee.h
* Rename tee_shm_pool_alloc_cma() to tee_shm_pool_alloc()
* Moved tee.h into include/uapi/linux/
* Redefined tee.h IOCTL macros to be directly based on _IOR and friends
* Removed version info on the API to user space, a data blob which
  can contain an UUID is left for user space to be able to tell which
  protocol to use in TEE_IOC_CMD
* Changed user space exposed structures to only have types with __ prefix
* Dropped THIS_MODULE from tee_fops
* Reworked how the driver is registered and ref counted:
  - moved from using an embedded struct miscdevice to an embedded struct
    device.
  - uses an struct rw_semaphore as synchronization for driver detachment
  - uses alloc/register pattern from TPM

Thanks,
Jens

Jens Wiklander (4):
  dt/bindings: add bindings for optee
  tee: generic TEE subsystem
  tee: add OP-TEE driver
  Documentation: tee subsystem and op-tee driver

 Documentation/00-INDEX                             |   2 +
 .../bindings/arm/firmware/linaro,optee-tz.txt      |  31 +
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 Documentation/ioctl/ioctl-number.txt               |   1 +
 Documentation/tee.txt                              | 117 +++
 MAINTAINERS                                        |  12 +
 drivers/Kconfig                                    |   2 +
 drivers/Makefile                                   |   1 +
 drivers/tee/Kconfig                                |  18 +
 drivers/tee/Makefile                               |   4 +
 drivers/tee/optee/Kconfig                          |   8 +
 drivers/tee/optee/Makefile                         |   5 +
 drivers/tee/optee/call.c                           | 400 ++++++++++
 drivers/tee/optee/core.c                           | 522 ++++++++++++
 drivers/tee/optee/optee_msg.h                      | 423 ++++++++++
 drivers/tee/optee/optee_private.h                  | 146 ++++
 drivers/tee/optee/optee_smc.h                      | 418 ++++++++++
 drivers/tee/optee/rpc.c                            | 322 ++++++++
 drivers/tee/optee/supp.c                           | 212 +++++
 drivers/tee/tee.c                                  | 873 +++++++++++++++++++++
 drivers/tee/tee_private.h                          |  80 ++
 drivers/tee/tee_shm.c                              | 324 ++++++++
 drivers/tee/tee_shm_pool.c                         | 133 ++++
 include/linux/tee_drv.h                            | 299 +++++++
 include/uapi/linux/tee.h                           | 383 +++++++++
 25 files changed, 4737 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
 create mode 100644 Documentation/tee.txt
 create mode 100644 drivers/tee/Kconfig
 create mode 100644 drivers/tee/Makefile
 create mode 100644 drivers/tee/optee/Kconfig
 create mode 100644 drivers/tee/optee/Makefile
 create mode 100644 drivers/tee/optee/call.c
 create mode 100644 drivers/tee/optee/core.c
 create mode 100644 drivers/tee/optee/optee_msg.h
 create mode 100644 drivers/tee/optee/optee_private.h
 create mode 100644 drivers/tee/optee/optee_smc.h
 create mode 100644 drivers/tee/optee/rpc.c
 create mode 100644 drivers/tee/optee/supp.c
 create mode 100644 drivers/tee/tee.c
 create mode 100644 drivers/tee/tee_private.h
 create mode 100644 drivers/tee/tee_shm.c
 create mode 100644 drivers/tee/tee_shm_pool.c
 create mode 100644 include/linux/tee_drv.h
 create mode 100644 include/uapi/linux/tee.h

-- 
1.9.1



From jens.wiklander at linaro.org  Mon Feb  1 01:15:37 2016
From: jens.wiklander at linaro.org (Jens Wiklander)
Date: Mon,  1 Feb 2016 10:15:37 +0100
Subject: [PATCH v7 1/4] dt/bindings: add bindings for optee
In-Reply-To: <1454318140-7962-1-git-send-email-jens.wiklander@linaro.org>
References: <1454318140-7962-1-git-send-email-jens.wiklander@linaro.org>
Message-ID: <1454318140-7962-2-git-send-email-jens.wiklander@linaro.org>

Introduces linaro prefix and adds bindings for ARM TrustZone based OP-TEE
implementation.

Signed-off-by: Jens Wiklander <jens.wiklander at linaro.org>
---
 .../bindings/arm/firmware/linaro,optee-tz.txt      | 31 ++++++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.txt        |  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt

diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
new file mode 100644
index 0000000..7fd7e3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
@@ -0,0 +1,31 @@
+OP-TEE Device Tree Bindings
+
+OP-TEE is a piece of software using hardware features to provide a Trusted
+Execution Environment. The security can be provided with ARM TrustZone, but
+also by virtualization or a separate chip.
+
+We're using "linaro" as the first part of the compatible porperty for
+the reference implementation maintained by Linaro.
+
+* OP-TEE based on ARM TrustZone required properties:
+
+- compatible     : should contain "linaro,optee-tz"
+
+- method         : The method of calling the OP-TEE Trusted OS. Permitted
+                   values are:
+
+                   "smc" : SMC #0, with the register assignments specified
+		           in drivers/tee/optee/optee_smc.h
+
+                   "hvc" : HVC #0, with the register assignments specified
+		           in drivers/tee/optee/optee_smc.h
+
+
+
+Example:
+	firmware {
+		optee {
+			compatible = "linaro,optee-tz";
+			method = "smc";
+		};
+	};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 72e2c5a..0c1e2f2 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -130,6 +130,7 @@ lacie	LaCie
 lantiq	Lantiq Semiconductor
 lenovo	Lenovo Group Ltd.
 lg	LG Corporation
+linaro	Linaro Limited
 linux	Linux-specific binding
 lsi	LSI Corp. (LSI Logic)
 lltc	Linear Technology Corporation
-- 
1.9.1



From jens.wiklander at linaro.org  Mon Feb  1 01:15:40 2016
From: jens.wiklander at linaro.org (Jens Wiklander)
Date: Mon,  1 Feb 2016 10:15:40 +0100
Subject: [PATCH v7 4/4] Documentation: tee subsystem and op-tee driver
In-Reply-To: <1454318140-7962-1-git-send-email-jens.wiklander@linaro.org>
References: <1454318140-7962-1-git-send-email-jens.wiklander@linaro.org>
Message-ID: <1454318140-7962-5-git-send-email-jens.wiklander@linaro.org>

Signed-off-by: Jens Wiklander <jens.wiklander at linaro.org>
---
 Documentation/00-INDEX |   2 +
 Documentation/tee.txt  | 117 +++++++++++++++++++++++++++++++++++++++++++++++++
 MAINTAINERS            |   1 +
 3 files changed, 120 insertions(+)
 create mode 100644 Documentation/tee.txt

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index cd077ca..bd3f803 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -435,6 +435,8 @@ sysrq.txt
 	- info on the magic SysRq key.
 target/
 	- directory with info on generating TCM v4 fabric .ko modules
+tee.txt
+	- info on the TEE subsystem and drivers
 this_cpu_ops.txt
 	- List rationale behind and the way to use this_cpu operations.
 thermal/
diff --git a/Documentation/tee.txt b/Documentation/tee.txt
new file mode 100644
index 0000000..4ac91d2
--- /dev/null
+++ b/Documentation/tee.txt
@@ -0,0 +1,117 @@
+TEE subsystem
+This document describes the TEE subsystem in Linux
+
+A TEE (Trusted Execution Environment) is a trusted OS running in some
+secure environment, for example, TrustZone on ARM CPUs, or a separate
+secure co-processor etc. A TEE driver handles the details needed to
+communicate with the TEE.
+
+This subsystem deals with:
+
+- Registration of TEE drivers
+
+- Managing shared memory between Linux and the TEE
+
+- Providing a generic API to the TEE
+
+The TEE interface
+=================
+
+include/uapi/linux/tee.h defines the generic interface to a TEE.
+
+User space (the client) connects to the driver by opening /dev/tee[0-9]* or
+/dev/teepriv[0-9]*.
+
+- TEE_IOC_SHM_ALLOC allocates shared memory and returns a file descriptor which
+  user space can mmap. When user space doesn't need the file descriptor anymore
+  it should be closed. When shared memory isn't needed any longer it should be
+  unmapped with munmap() to allow the reuse of memory.
+
+- TEE_IOC_VERSION lets user space know which TEE this driver handles and
+  the its capabilities.
+
+- TEE_IOC_OPEN_SESSION opens a new session to a Trusted Application
+
+- TEE_IOC_INVOKE invokes a function in a Trusted Application
+
+- TEE_IOC_CANCEL may cancel an ongoing TEE_IOC_OPEN_SESSION or TEE_IOC_INVOKE
+
+- TEE_IOC_CLOSE_SESSION closes a session to a Trusted Application
+
+There are two classes of clients, normal clients and supplicants. The latter is
+a helper process for the TEE to access resources in Linux, for example file
+system access. A normal client opens /dev/tee[0-9]* and a supplicant opens
+/dev/teepriv[0-9].
+
+Much of the communication between clients and the TEE is opaque to the
+driver. The main job for the driver is to receive requests from the
+clients, forward them to the TEE and send back the results. In the case of
+supplicants the communication goes in the other direction, the TEE sends
+requests to the supplicant which then sends back the result.
+
+OP-TEE driver
+=============
+
+The OP-TEE driver handles OP-TEE [1] based TEEs. Currently it is only the ARM
+TrustZone based OP-TEE solution that is supported.
+
+Lowest level of communication with OP-TEE builds on ARM SMC Calling
+Convention (SMCCC) [2], which is the foundation for OP-TEE's SMC interface
+[3] used internally by the driver. Stacked on top of that is OP-TEE Message
+Protocol [4].
+
+OP-TEE SMC interface provides the basic functions required by SMCCC and some
+additional functions specific for OP-TEE. The most interesting functions are:
+
+- OPTEE_SMC_FUNCID_CALLS_UID (part of SMCCC) returns the version information
+  which is then returned by TEE_IOC_VERSION
+
+- OPTEE_SMC_CALL_GET_OS_UUID returns the particular OP-TEE implementation, used
+  to tell, for instance, a TrustZone OP-TEE apart from an OP-TEE running on a
+  separate secure co-processor.
+
+- OPTEE_SMC_CALL_WITH_ARG drives the OP-TEE message protocol
+
+- OPTEE_SMC_GET_SHM_CONFIG lets the driver and OP-TEE agree on which memory
+  range to used for shared memory between Linux and OP-TEE.
+
+The GlobalPlatform TEE Client API [5] is implemented on top of the generic
+TEE API.
+
+Picture of the relationship between the different components in the
+OP-TEE architecture.
+
+    User space                  Kernel                   Secure world
+    ~~~~~~~~~~                  ~~~~~~                   ~~~~~~~~~~~~
+ +--------+                                             +-------------+
+ | Client |                                             | Trusted     |
+ +--------+                                             | Application |
+    /\                                                  +-------------+
+    || +----------+                                           /\
+    || |tee-      |                                           ||
+    || |supplicant|                                           \/
+    || +----------+                                     +-------------+
+    \/      /\                                          | TEE Internal|
+ +-------+  ||                                          | API         |
+ + TEE   |  ||            +--------+--------+           +-------------+
+ | Client|  ||            | TEE    | OP-TEE |           | OP-TEE      |
+ | API   |  \/            | subsys | driver |           | Trusted OS  |
+ +-------+----------------+----+-------+----+-----------+-------------+
+ |      Generic TEE API        |       |     OP-TEE MSG               |
+ |      IOCTL (TEE_IOC_*)      |       |     SMCCC (OPTEE_SMC_CALL_*) |
+ +-----------------------------+       +------------------------------+
+
+RPC (Remote Procedure Call) are requests from secure world to kernel driver
+or tee-supplicant. An RPC is identified by a special range of SMCCC return
+values from OPTEE_SMC_CALL_WITH_ARG. RPC messages which are intended for the
+kernel are handled by the kernel driver. Other RPC messages will be forwarded to
+tee-supplicant without further involvement of the driver, except switching
+shared memory buffer representation.
+
+References:
+[1] https://github.com/OP-TEE/optee_os
+[2] http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
+[3] drivers/tee/optee/optee_smc.h
+[4] drivers/tee/optee/optee_msg.h
+[5] http://www.globalplatform.org/specificationsdevice.asp look for
+    "TEE Client API Specification v1.0" and click download.
diff --git a/MAINTAINERS b/MAINTAINERS
index 4a0989c..895697a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9577,6 +9577,7 @@ S:	Maintained
 F:	include/linux/tee_drv.h
 F:	include/uapi/linux/tee.h
 F:	drivers/tee/
+F:	Documentation/tee.txt
 
 THUNDERBOLT DRIVER
 M:	Andreas Noever <andreas.noever at gmail.com>
-- 
1.9.1



From jens.wiklander at linaro.org  Mon Feb  1 01:15:38 2016
From: jens.wiklander at linaro.org (Jens Wiklander)
Date: Mon,  1 Feb 2016 10:15:38 +0100
Subject: [PATCH v7 2/4] tee: generic TEE subsystem
In-Reply-To: <1454318140-7962-1-git-send-email-jens.wiklander@linaro.org>
References: <1454318140-7962-1-git-send-email-jens.wiklander@linaro.org>
Message-ID: <1454318140-7962-3-git-send-email-jens.wiklander@linaro.org>

Initial patch for generic TEE subsystem.
This subsystem provides:
* Registration/un-registration of TEE drivers.
* Shared memory between normal world and secure world.
* Ioctl interface for interaction with user space.
* Sysfs implementation_id of TEE driver

A TEE (Trusted Execution Environment) driver is a driver that interfaces
with a trusted OS running in some secure environment, for example,
TrustZone on ARM cpus, or a separate secure co-processor etc.

The TEE subsystem can serve a TEE driver for a Global Platform compliant
TEE, but it's not limited to only Global Platform TEEs.

This patch builds on other similar implementations trying to solve
the same problem:
* "optee_linuxdriver" by among others
  Jean-michel DELORME<jean-michel.delorme at st.com> and
  Emmanuel MICHEL <emmanuel.michel at st.com>
* "Generic TrustZone Driver" by Javier Gonz?lez <javier at javigon.com>

Signed-off-by: Jens Wiklander <jens.wiklander at linaro.org>
---
 Documentation/ioctl/ioctl-number.txt |   1 +
 MAINTAINERS                          |   6 +
 drivers/Kconfig                      |   2 +
 drivers/Makefile                     |   1 +
 drivers/tee/Kconfig                  |   8 +
 drivers/tee/Makefile                 |   3 +
 drivers/tee/tee.c                    | 873 +++++++++++++++++++++++++++++++++++
 drivers/tee/tee_private.h            |  80 ++++
 drivers/tee/tee_shm.c                | 324 +++++++++++++
 drivers/tee/tee_shm_pool.c           | 133 ++++++
 include/linux/tee_drv.h              | 299 ++++++++++++
 include/uapi/linux/tee.h             | 383 +++++++++++++++
 12 files changed, 2113 insertions(+)
 create mode 100644 drivers/tee/Kconfig
 create mode 100644 drivers/tee/Makefile
 create mode 100644 drivers/tee/tee.c
 create mode 100644 drivers/tee/tee_private.h
 create mode 100644 drivers/tee/tee_shm.c
 create mode 100644 drivers/tee/tee_shm_pool.c
 create mode 100644 include/linux/tee_drv.h
 create mode 100644 include/uapi/linux/tee.h

diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 91261a3..b5ce7b6 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -307,6 +307,7 @@ Code  Seq#(hex)	Include File		Comments
 0xA3	80-8F	Port ACL		in development:
 					<mailto:tlewis at mindspring.com>
 0xA3	90-9F	linux/dtlk.h
+0xA4	00-1F	uapi/linux/tee.h	Generic TEE subsystem
 0xAA	00-3F	linux/uapi/linux/userfaultfd.h
 0xAB	00-1F	linux/nbd.h
 0xAC	00-1F	linux/raw.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 30aca4a..e3dfc81e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9566,6 +9566,12 @@ F:	Documentation/trace/stm.txt
 F:	drivers/hwtracing/stm/
 F:	include/linux/stm.h
 F:	include/uapi/linux/stm.h
+TEE SUBSYSTEM
+M:	Jens Wiklander <jens.wiklander at linaro.org>
+S:	Maintained
+F:	include/linux/tee_drv.h
+F:	include/uapi/linux/tee.h
+F:	drivers/tee/
 
 THUNDERBOLT DRIVER
 M:	Andreas Noever <andreas.noever at gmail.com>
diff --git a/drivers/Kconfig b/drivers/Kconfig
index d2ac339..63baceb 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -198,4 +198,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
 
 source "drivers/fpga/Kconfig"
 
+source "drivers/tee/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 8f5d076..231b409 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -172,3 +172,4 @@ obj-$(CONFIG_STM)		+= hwtracing/stm/
 obj-$(CONFIG_ANDROID)		+= android/
 obj-$(CONFIG_NVMEM)		+= nvmem/
 obj-$(CONFIG_FPGA)		+= fpga/
+obj-$(CONFIG_TEE)		+= tee/
diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
new file mode 100644
index 0000000..64a8cd7
--- /dev/null
+++ b/drivers/tee/Kconfig
@@ -0,0 +1,8 @@
+# Generic Trusted Execution Environment Configuration
+config TEE
+	bool "Trusted Execution Environment support"
+	default n
+	select DMA_SHARED_BUFFER
+	help
+	  This implements a generic interface towards a Trusted Execution
+	  Environment (TEE).
diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
new file mode 100644
index 0000000..60d2dab
--- /dev/null
+++ b/drivers/tee/Makefile
@@ -0,0 +1,3 @@
+obj-y += tee.o
+obj-y += tee_shm.o
+obj-y += tee_shm_pool.o
diff --git a/drivers/tee/tee.c b/drivers/tee/tee.c
new file mode 100644
index 0000000..b8a1c76
--- /dev/null
+++ b/drivers/tee/tee.c
@@ -0,0 +1,873 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/device.h>
+#include <linux/cdev.h>
+#include <linux/fs.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <linux/tee_drv.h>
+#include "tee_private.h"
+
+#define TEE_NUM_DEVICES	32
+
+#define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x))
+
+/*
+ * Unprivileged devices in the in the lower half range and privileged
+ * devices in the upper half range.
+ */
+static DECLARE_BITMAP(dev_mask, TEE_NUM_DEVICES);
+static DEFINE_SPINLOCK(driver_lock);
+
+static struct class *tee_class;
+static dev_t tee_devt;
+
+static int tee_open(struct inode *inode, struct file *filp)
+{
+	int rc;
+	struct tee_device *teedev;
+	struct tee_context *ctx;
+
+	teedev = container_of(inode->i_cdev, struct tee_device, cdev);
+	if (!tee_device_get(teedev))
+		return -EINVAL;
+
+	ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+	if (!ctx) {
+		rc = -ENOMEM;
+		goto err;
+	}
+
+	ctx->teedev = teedev;
+	filp->private_data = ctx;
+	rc = teedev->desc->ops->open(ctx);
+	if (rc)
+		goto err;
+
+	return 0;
+err:
+	kfree(ctx);
+	tee_device_put(teedev);
+	return rc;
+}
+
+static int tee_release(struct inode *inode, struct file *filp)
+{
+	struct tee_context *ctx = filp->private_data;
+	struct tee_device *teedev = ctx->teedev;
+
+	ctx->teedev->desc->ops->release(ctx);
+	kfree(ctx);
+	tee_device_put(teedev);
+	return 0;
+}
+
+static int tee_ioctl_version(struct tee_context *ctx,
+		struct tee_ioctl_version_data __user *uvers)
+{
+	struct tee_ioctl_version_data vers;
+
+	ctx->teedev->desc->ops->get_version(ctx->teedev, &vers);
+	if (copy_to_user(uvers, &vers, sizeof(vers)))
+		return -EFAULT;
+	return 0;
+}
+
+static int tee_ioctl_shm_alloc(struct tee_context *ctx,
+		struct tee_ioctl_shm_alloc_data __user *udata)
+{
+	long ret;
+	struct tee_ioctl_shm_alloc_data data;
+	struct tee_shm *shm;
+
+	if (copy_from_user(&data, udata, sizeof(data)))
+		return -EFAULT;
+
+	/* Currently no input flags are supported */
+	if (data.flags)
+		return -EINVAL;
+
+	data.fd = -1;
+
+	shm = tee_shm_alloc(ctx->teedev, data.size,
+			    TEE_SHM_MAPPED | TEE_SHM_DMA_BUF);
+	if (IS_ERR(shm))
+		return PTR_ERR(shm);
+
+	data.flags = shm->flags;
+	data.size = shm->size;
+	data.fd = tee_shm_get_fd(shm);
+	if (data.fd < 0) {
+		ret = data.fd;
+		goto err;
+	}
+
+	if (copy_to_user(udata, &data, sizeof(data))) {
+		ret = -EFAULT;
+		goto err;
+	}
+	/*
+	 * When user space closes the file descriptor the shared memory
+	 * should be freed
+	 */
+	tee_shm_put(shm);
+	return 0;
+err:
+	if (data.fd >= 0)
+		tee_shm_put_fd(data.fd);
+	tee_shm_free(shm);
+	return ret;
+}
+
+static int params_from_user(struct tee_param *params, size_t num_params,
+		struct tee_ioctl_param __user *uparams)
+{
+	size_t n;
+
+	for (n = 0; n < num_params; n++) {
+		struct tee_shm *shm;
+		struct tee_ioctl_param ip;
+
+		if (copy_from_user(&ip, uparams + n, sizeof(ip)))
+			return -EFAULT;
+
+		/* All unused attribute bits has to be zero */
+		if (ip.attr & ~TEE_IOCTL_PARAM_ATTR_TYPE_MASK)
+			return -EINVAL;
+
+		params[n].attr = ip.attr;
+		switch (ip.attr) {
+		case TEE_IOCTL_PARAM_ATTR_TYPE_NONE:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT:
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT:
+			params[n].u.value.a = ip.u.value.a;
+			params[n].u.value.b = ip.u.value.b;
+			params[n].u.value.c = ip.u.value.c;
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT:
+			/*
+			 * If we fail to get a pointer to a shared memory
+			 * object (and increase the ref count) from a file
+			 * descriptor we return an error. All pointers that
+			 * has been added in params have an increased ref
+			 * count. It's the callers responibility to do
+			 * tee_shm_put() on all resolved pointers.
+			 */
+			shm = tee_shm_get_from_fd(ip.u.memref.shm_fd);
+			if (IS_ERR(shm))
+				return PTR_ERR(shm);
+
+			params[n].u.memref.shm_offs = ip.u.memref.shm_offs;
+			params[n].u.memref.size = ip.u.memref.size;
+			params[n].u.memref.shm = shm;
+			break;
+		default:
+			/* Unknown attribute */
+			return -EINVAL;
+		}
+	}
+	return 0;
+}
+
+static int params_to_user(struct tee_ioctl_param __user *uparams,
+		size_t num_params, struct tee_param *params)
+{
+	size_t n;
+
+	for (n = 0; n < num_params; n++) {
+		struct tee_ioctl_param __user *up = uparams + n;
+		struct tee_param *p = params + n;
+
+		switch (p->attr) {
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT:
+			if (put_user(p->u.value.a, &up->u.value.a) ||
+			    put_user(p->u.value.b, &up->u.value.b) ||
+			    put_user(p->u.value.c, &up->u.value.c))
+				return -EFAULT;
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT:
+			if (put_user((u64)p->u.memref.size, &up->u.memref.size))
+				return -EFAULT;
+		default:
+			break;
+		}
+	}
+	return 0;
+}
+
+static bool param_is_memref(struct tee_param *param)
+{
+	switch (param->attr & TEE_IOCTL_PARAM_ATTR_TYPE_MASK) {
+	case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT:
+	case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT:
+	case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static int tee_ioctl_open_session(struct tee_context *ctx,
+		struct tee_ioctl_buf_data __user *ubuf)
+{
+	int rc;
+	size_t n;
+	struct tee_ioctl_buf_data buf;
+	struct tee_ioctl_open_session_arg __user *uarg;
+	struct tee_ioctl_open_session_arg arg;
+	struct tee_ioctl_param __user *uparams = NULL;
+	struct tee_param *params = NULL;
+	bool have_session = false;
+
+	if (!ctx->teedev->desc->ops->open_session)
+		return -EINVAL;
+
+	if (copy_from_user(&buf, ubuf, sizeof(buf)))
+		return -EFAULT;
+
+	if (buf.buf_len > TEE_MAX_ARG_SIZE ||
+	    buf.buf_len < sizeof(struct tee_ioctl_open_session_arg))
+		return -EINVAL;
+
+	uarg = (struct tee_ioctl_open_session_arg __user *)(unsigned long)
+		buf.buf_ptr;
+	rc = copy_from_user(&arg, uarg, sizeof(arg));
+	if (rc)
+		return rc;
+
+	if (sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len)
+		return -EINVAL;
+
+	if (arg.num_params) {
+		params = kcalloc(arg.num_params, sizeof(struct tee_param),
+				GFP_KERNEL);
+		if (!params)
+			return -ENOMEM;
+		uparams = (struct tee_ioctl_param __user *)(uarg + 1);
+		rc = params_from_user(params, arg.num_params, uparams);
+		if (rc)
+			goto out;
+	}
+
+	rc = ctx->teedev->desc->ops->open_session(ctx, &arg, params);
+	if (rc)
+		goto out;
+	have_session = true;
+
+	if (put_user(arg.session, &uarg->session) ||
+	    put_user(arg.ret, &uarg->ret) ||
+	    put_user(arg.ret_origin, &uarg->ret_origin)) {
+		rc = -EFAULT;
+		goto out;
+	}
+	rc = params_to_user(uparams, arg.num_params, params);
+out:
+	/*
+	 * If we've succeeded to open the session but failed to communicate
+	 * it back to user space, close the session again to avoid leakage.
+	 */
+	if (rc && have_session && ctx->teedev->desc->ops->close_session)
+		ctx->teedev->desc->ops->close_session(ctx, arg.session);
+
+	if (params) {
+		/* Decrease ref count for all valid shared memory pointers */
+		for (n = 0; n < arg.num_params; n++)
+			if (param_is_memref(params + n) &&
+			    params[n].u.memref.shm)
+				tee_shm_put(params[n].u.memref.shm);
+		kfree(params);
+	}
+
+	return rc;
+}
+
+static int tee_ioctl_invoke(struct tee_context *ctx,
+		struct tee_ioctl_buf_data __user *ubuf)
+{
+	int rc;
+	size_t n;
+	struct tee_ioctl_buf_data buf;
+	struct tee_ioctl_invoke_arg __user *uarg;
+	struct tee_ioctl_invoke_arg arg;
+	struct tee_ioctl_param __user *uparams = NULL;
+	struct tee_param *params = NULL;
+
+	if (!ctx->teedev->desc->ops->invoke_func)
+		return -EINVAL;
+
+	rc = copy_from_user(&buf, ubuf, sizeof(buf));
+	if (rc)
+		return rc;
+
+	if (buf.buf_len > TEE_MAX_ARG_SIZE ||
+	    buf.buf_len < sizeof(struct tee_ioctl_invoke_arg))
+		return -EINVAL;
+
+	uarg = (struct tee_ioctl_invoke_arg __user *)(unsigned long)buf.buf_ptr;
+	if (copy_from_user(&arg, uarg, sizeof(arg)))
+		return -EFAULT;
+
+	if (sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len)
+		return -EINVAL;
+
+	if (arg.num_params) {
+		params = kcalloc(arg.num_params, sizeof(struct tee_param),
+				GFP_KERNEL);
+		if (!params)
+			return -ENOMEM;
+		uparams = (struct tee_ioctl_param __user *)(uarg + 1);
+		rc = params_from_user(params, arg.num_params, uparams);
+		if (rc)
+			goto out;
+	}
+
+	rc = ctx->teedev->desc->ops->invoke_func(ctx, &arg, params);
+	if (rc)
+		goto out;
+
+	if (put_user(arg.ret, &uarg->ret) ||
+	    put_user(arg.ret_origin, &uarg->ret_origin)) {
+		rc = -EFAULT;
+		goto out;
+	}
+	rc = params_to_user(uparams, arg.num_params, params);
+out:
+	if (params) {
+		/* Decrease ref count for all valid shared memory pointers */
+		for (n = 0; n < arg.num_params; n++)
+			if (param_is_memref(params + n) &&
+			    params[n].u.memref.shm)
+				tee_shm_put(params[n].u.memref.shm);
+		kfree(params);
+	}
+	return rc;
+}
+
+
+static int tee_ioctl_cancel(struct tee_context *ctx,
+		struct tee_ioctl_cancel_arg __user *uarg)
+{
+	struct tee_ioctl_cancel_arg arg;
+
+	if (!ctx->teedev->desc->ops->cancel_req)
+		return -EINVAL;
+
+	if (copy_from_user(&arg, uarg, sizeof(arg)))
+		return -EFAULT;
+
+	return ctx->teedev->desc->ops->cancel_req(ctx, arg.cancel_id,
+						  arg.session);
+}
+
+static int tee_ioctl_close_session(struct tee_context *ctx,
+		struct tee_ioctl_close_session_arg __user *uarg)
+{
+	struct tee_ioctl_close_session_arg arg;
+
+	if (!ctx->teedev->desc->ops->close_session)
+		return -EINVAL;
+
+	if (copy_from_user(&arg, uarg, sizeof(arg)))
+		return -EFAULT;
+
+	return ctx->teedev->desc->ops->close_session(ctx, arg.session);
+}
+
+static int params_to_supp(struct tee_ioctl_param __user *uparams,
+		size_t num_params, struct tee_param *params)
+{
+	int rc = 0;
+	size_t n;
+	int *fds = kmalloc_array(num_params, sizeof(int), GFP_KERNEL);
+
+	if (!fds)
+		return -ENOMEM;
+	for (n = 0; n < num_params; n++)
+		fds[n] = -1;
+
+	for (n = 0; n < num_params; n++) {
+		struct tee_ioctl_param ip;
+		struct tee_param *p = params + n;
+
+		ip.attr = p->attr & TEE_IOCTL_PARAM_ATTR_TYPE_MASK;
+		switch (p->attr) {
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT:
+			ip.u.value.a = p->u.value.a;
+			ip.u.value.b = p->u.value.b;
+			ip.u.value.c = p->u.value.c;
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT:
+			ip.u.memref.size = p->u.memref.size;
+			if (!p->u.memref.shm) {
+				ip.u.memref.shm_offs = 0;
+				ip.u.memref.shm_fd = -1;
+				break;
+			}
+			ip.u.memref.shm_offs = p->u.memref.shm_offs;
+			/*
+			 * This tee_shm_get_fd() is supposed to be matched
+			 * by a close(2) from tee-supplicant.
+			 */
+			fds[n] = tee_shm_get_fd(p->u.memref.shm);
+			if (fds[n] < 0) {
+				rc = fds[n];
+				goto out;
+			}
+			ip.u.memref.shm_fd = fds[n];
+			break;
+		default:
+			memset(&ip.u, 0, sizeof(ip.u));
+			break;
+		}
+
+		if (copy_to_user(uparams + n, &ip, sizeof(ip))) {
+			rc = -EFAULT;
+			goto out;
+		}
+	}
+out:
+	if (rc) {
+		for (n = 0; n < num_params; n++)
+			if (fds[n] >= 0)
+				tee_shm_put_fd(fds[n]);
+	}
+	kfree(fds);
+	return rc;
+}
+
+static int tee_ioctl_supp_recv(struct tee_context *ctx,
+		struct tee_ioctl_buf_data __user *ubuf)
+{
+	int rc;
+	struct tee_ioctl_buf_data buf;
+	struct tee_iocl_supp_recv_arg __user *uarg;
+	struct tee_param *params;
+	struct tee_ioctl_param __user *uparams;
+	u32 num_params;
+	u32 func;
+
+	if (!ctx->teedev->desc->ops->supp_recv)
+		return -EINVAL;
+
+	if (copy_from_user(&buf, ubuf, sizeof(buf)))
+		return -EFAULT;
+
+	if (buf.buf_len > TEE_MAX_ARG_SIZE ||
+	    buf.buf_len < sizeof(struct tee_iocl_supp_recv_arg))
+		return -EINVAL;
+
+	uarg = (struct tee_iocl_supp_recv_arg __user *)(unsigned long)
+		buf.buf_ptr;
+	if (get_user(num_params, &uarg->num_params))
+		return -EFAULT;
+
+	if (sizeof(*uarg) + TEE_IOCTL_PARAM_SIZE(num_params) != buf.buf_len)
+		return -EINVAL;
+
+	params = kcalloc(num_params, sizeof(struct tee_param), GFP_KERNEL);
+	if (!params)
+		return -ENOMEM;
+
+	rc = ctx->teedev->desc->ops->supp_recv(ctx, &func, &num_params, params);
+	if (rc)
+		goto out;
+
+	if (put_user(func, &uarg->func) ||
+	    put_user(num_params, &uarg->num_params)) {
+		rc = -EFAULT;
+		goto out;
+	}
+
+	uparams = (struct tee_ioctl_param __user *)(uarg + 1);
+	rc = params_to_supp(uparams, num_params, params);
+out:
+	kfree(params);
+	return rc;
+}
+
+static int params_from_supp(struct tee_param *params,
+		size_t num_params, struct tee_ioctl_param __user *uparams)
+{
+	size_t n;
+
+	for (n = 0; n < num_params; n++) {
+		struct tee_param *p = params + n;
+		struct tee_ioctl_param ip;
+
+		if (copy_from_user(&ip, uparams + n, sizeof(ip)))
+			return -EFAULT;
+
+		/* All unused attribute bits has to be zero */
+		if (ip.attr & ~TEE_IOCTL_PARAM_ATTR_TYPE_MASK)
+			return -EINVAL;
+
+		p->attr = ip.attr;
+		switch (ip.attr) {
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT:
+			/* Only out and in/out values can be updated */
+			p->u.value.a = ip.u.value.a;
+			p->u.value.b = ip.u.value.b;
+			p->u.value.c = ip.u.value.c;
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT:
+			/*
+			 * Only the size of the memref can be updated.
+			 * Since we don't have access to the original
+			 * parameters here, only store the supplied size.
+			 * The driver will copy the updated size into the
+			 * original parameters.
+			 */
+			p->u.memref.shm = NULL;
+			p->u.memref.shm_offs = 0;
+			p->u.memref.size = ip.u.memref.size;
+			break;
+		default:
+			memset(&p->u, 0, sizeof(p->u));
+			break;
+		}
+	}
+	return 0;
+}
+
+static int tee_ioctl_supp_send(struct tee_context *ctx,
+		struct tee_ioctl_buf_data __user *ubuf)
+{
+	long rc;
+	struct tee_ioctl_buf_data buf;
+	struct tee_iocl_supp_send_arg __user *uarg;
+	struct tee_param *params;
+	struct tee_ioctl_param __user *uparams;
+	u32 num_params;
+	u32 ret;
+
+	/* Not valid for this driver */
+	if (!ctx->teedev->desc->ops->supp_send)
+		return -EINVAL;
+
+	if (copy_from_user(&buf, ubuf, sizeof(buf)))
+		return -EFAULT;
+
+	if (buf.buf_len > TEE_MAX_ARG_SIZE ||
+	    buf.buf_len < sizeof(struct tee_iocl_supp_send_arg))
+		return -EINVAL;
+
+	uarg = (struct tee_iocl_supp_send_arg __user *)(unsigned long)
+		buf.buf_ptr;
+	if (get_user(ret, &uarg->ret) ||
+	    get_user(num_params, &uarg->num_params))
+		return -EFAULT;
+
+	if (sizeof(*uarg) + TEE_IOCTL_PARAM_SIZE(num_params) > buf.buf_len)
+		return -EINVAL;
+
+	params = kcalloc(num_params, sizeof(struct tee_param), GFP_KERNEL);
+	if (!params)
+		return -ENOMEM;
+
+	uparams = (struct tee_ioctl_param __user *)(uarg + 1);
+	rc = params_from_supp(params, num_params, uparams);
+	if (rc)
+		goto out;
+
+	rc = ctx->teedev->desc->ops->supp_send(ctx, ret, num_params, params);
+out:
+	kfree(params);
+	return rc;
+}
+
+
+static long tee_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
+{
+	struct tee_context *ctx = filp->private_data;
+	void __user *uarg = (void __user *)arg;
+
+	switch (cmd) {
+	case TEE_IOC_VERSION:
+		return tee_ioctl_version(ctx, uarg);
+	case TEE_IOC_SHM_ALLOC:
+		return tee_ioctl_shm_alloc(ctx, uarg);
+	case TEE_IOC_OPEN_SESSION:
+		return tee_ioctl_open_session(ctx, uarg);
+	case TEE_IOC_INVOKE:
+		return tee_ioctl_invoke(ctx, uarg);
+	case TEE_IOC_CANCEL:
+		return tee_ioctl_cancel(ctx, uarg);
+	case TEE_IOC_CLOSE_SESSION:
+		return tee_ioctl_close_session(ctx, uarg);
+	case TEE_IOC_SUPPL_RECV:
+		return tee_ioctl_supp_recv(ctx, uarg);
+	case TEE_IOC_SUPPL_SEND:
+		return tee_ioctl_supp_send(ctx, uarg);
+	default:
+		return -EINVAL;
+	}
+}
+
+static const struct file_operations tee_fops = {
+	.open = tee_open,
+	.release = tee_release,
+	.unlocked_ioctl = tee_ioctl,
+	.compat_ioctl = tee_ioctl,
+};
+
+static void tee_release_device(struct device *dev)
+{
+	struct tee_device *teedev = container_of(dev, struct tee_device, dev);
+
+	spin_lock(&driver_lock);
+	clear_bit(teedev->id, dev_mask);
+	spin_unlock(&driver_lock);
+	mutex_destroy(&teedev->mutex);
+	kfree(teedev);
+}
+
+struct tee_device *tee_device_alloc(const struct tee_desc *teedesc,
+			struct device *dev, struct tee_shm_pool *pool,
+			void *driver_data)
+{
+	struct tee_device *teedev;
+	void *ret;
+	int rc;
+	int offs = 0;
+
+	if (!teedesc || !teedesc->name || !teedesc->ops ||
+	    !teedesc->ops->get_version || !teedesc->ops->open ||
+	    !teedesc->ops->release || !dev || !pool)
+		return ERR_PTR(-EINVAL);
+
+	teedev = kzalloc(sizeof(*teedev), GFP_KERNEL);
+	if (!teedev) {
+		ret = ERR_PTR(-ENOMEM);
+		goto err;
+	}
+
+	if (teedesc->flags & TEE_DESC_PRIVILEGED)
+		offs = TEE_NUM_DEVICES / 2;
+
+	spin_lock(&driver_lock);
+	teedev->id = find_next_zero_bit(dev_mask, TEE_NUM_DEVICES, offs);
+	if (teedev->id < TEE_NUM_DEVICES)
+		set_bit(teedev->id, dev_mask);
+	spin_unlock(&driver_lock);
+
+	if (teedev->id >= TEE_NUM_DEVICES) {
+		ret = ERR_PTR(-ENOMEM);
+		goto err;
+	}
+
+	snprintf(teedev->name, sizeof(teedev->name), "tee%s%d",
+		 teedesc->flags & TEE_DESC_PRIVILEGED ? "priv" : "",
+		 teedev->id - offs);
+
+	teedev->dev.class = tee_class;
+	teedev->dev.release = tee_release_device;
+	teedev->dev.parent = dev;
+	teedev->dev.devt = MKDEV(MAJOR(tee_devt), teedev->id);
+
+	rc = dev_set_name(&teedev->dev, "%s", teedev->name);
+	if (rc) {
+		ret = ERR_PTR(rc);
+		goto err;
+	}
+
+	cdev_init(&teedev->cdev, &tee_fops);
+	teedev->cdev.owner = teedesc->owner;
+	teedev->cdev.kobj.parent = &teedev->dev.kobj;
+
+	dev_set_drvdata(&teedev->dev, driver_data);
+	device_initialize(&teedev->dev);
+
+	/* 1 as tee_device_unregister() does one final tee_device_put() */
+	teedev->num_users = 1;
+	init_completion(&teedev->c_no_users);
+	mutex_init(&teedev->mutex);
+
+	teedev->desc = teedesc;
+	teedev->pool = pool;
+	INIT_LIST_HEAD(&teedev->list_shm);
+
+	return teedev;
+err:
+	dev_err(dev, "could not register %s driver\n",
+		teedesc->flags & TEE_DESC_PRIVILEGED ? "privileged" : "client");
+	if (teedev && teedev->id < TEE_NUM_DEVICES) {
+		spin_lock(&driver_lock);
+		clear_bit(teedev->id, dev_mask);
+		spin_unlock(&driver_lock);
+	}
+	kfree(teedev);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(tee_device_alloc);
+
+static ssize_t implementation_id_show(struct device *dev,
+			struct device_attribute *attr, char *buf)
+{
+	struct tee_device *teedev = container_of(dev, struct tee_device, dev);
+	struct tee_ioctl_version_data vers;
+
+	teedev->desc->ops->get_version(teedev, &vers);
+	return scnprintf(buf, PAGE_SIZE, "%d\n", vers.impl_id);
+}
+static DEVICE_ATTR_RO(implementation_id);
+
+static struct attribute *tee_dev_attrs[] = {
+	&dev_attr_implementation_id.attr,
+	NULL
+};
+
+static const struct attribute_group tee_dev_group = {
+	.attrs = tee_dev_attrs,
+};
+
+int tee_device_register(struct tee_device *teedev)
+{
+	int rc;
+
+	/*
+	 * If the teedev already is registered, don't do it again. It's
+	 * obviously an error to try to register twice, but if we return
+	 * an error we'll force the driver to remove the teedev.
+	 */
+	if (teedev->flags & TEE_DEVICE_FLAG_REGISTERED) {
+		dev_err(&teedev->dev, "attempt to register twice\n");
+		return 0;
+	}
+
+	rc = cdev_add(&teedev->cdev, teedev->dev.devt, 1);
+	if (rc) {
+		dev_err(&teedev->dev,
+			"unable to cdev_add() %s, major %d, minor %d, err=%d\n",
+			teedev->name, MAJOR(teedev->dev.devt),
+			MINOR(teedev->dev.devt), rc);
+		return rc;
+	}
+
+	rc = device_add(&teedev->dev);
+	if (rc) {
+		dev_err(&teedev->dev,
+			"unable to device_add() %s, major %d, minor %d, err=%d\n",
+			teedev->name, MAJOR(teedev->dev.devt),
+			MINOR(teedev->dev.devt), rc);
+		goto err_device_add;
+	}
+
+	rc = sysfs_create_group(&teedev->dev.kobj, &tee_dev_group);
+	if (rc) {
+		dev_err(&teedev->dev,
+			"failed to create sysfs attributes, err=%d\n", rc);
+		goto err_sysfs_create_group;
+	}
+
+	teedev->flags |= TEE_DEVICE_FLAG_REGISTERED;
+	return 0;
+
+err_sysfs_create_group:
+	device_del(&teedev->dev);
+err_device_add:
+	cdev_del(&teedev->cdev);
+	return rc;
+
+}
+EXPORT_SYMBOL_GPL(tee_device_register);
+
+void tee_device_put(struct tee_device *teedev)
+{
+	mutex_lock(&teedev->mutex);
+	/* Shouldn't put in this state */
+	if (!WARN_ON(!teedev->desc)) {
+		teedev->num_users--;
+		if (!teedev->num_users) {
+			teedev->desc = NULL;
+			complete(&teedev->c_no_users);
+		}
+	}
+	mutex_unlock(&teedev->mutex);
+}
+
+bool tee_device_get(struct tee_device *teedev)
+{
+	mutex_lock(&teedev->mutex);
+	if (!teedev->desc) {
+		mutex_unlock(&teedev->mutex);
+		return false;
+	}
+	teedev->num_users++;
+	mutex_unlock(&teedev->mutex);
+	return true;
+}
+
+void tee_device_unregister(struct tee_device *teedev)
+{
+	if (!teedev)
+		return;
+
+	if (teedev->flags & TEE_DEVICE_FLAG_REGISTERED) {
+		sysfs_remove_group(&teedev->dev.kobj, &tee_dev_group);
+		cdev_del(&teedev->cdev);
+		device_del(&teedev->dev);
+	}
+
+	tee_device_put(teedev);
+	wait_for_completion(&teedev->c_no_users);
+
+	/*
+	 * No need to take a mutex any longer now since teedev->desc was
+	 * set to NULL before teedev->c_no_users was completed.
+	 */
+
+	teedev->pool = NULL;
+
+	put_device(&teedev->dev);
+}
+EXPORT_SYMBOL_GPL(tee_device_unregister);
+
+void *tee_get_drvdata(struct tee_device *teedev)
+{
+	return dev_get_drvdata(&teedev->dev);
+}
+EXPORT_SYMBOL_GPL(tee_get_drvdata);
+
+static int __init tee_init(void)
+{
+	int rc;
+
+	tee_class = class_create(THIS_MODULE, "tee");
+	if (IS_ERR(tee_class)) {
+		pr_err("couldn't create class\n");
+		return PTR_ERR(tee_class);
+	}
+
+	rc = alloc_chrdev_region(&tee_devt, 0, TEE_NUM_DEVICES, "tee");
+	if (rc < 0) {
+		pr_err("failed to allocate char dev region\n");
+		class_destroy(tee_class);
+		tee_class = NULL;
+	}
+
+	return rc;
+}
+
+subsys_initcall(tee_init);
diff --git a/drivers/tee/tee_private.h b/drivers/tee/tee_private.h
new file mode 100644
index 0000000..d32ac54
--- /dev/null
+++ b/drivers/tee/tee_private.h
@@ -0,0 +1,80 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#ifndef TEE_PRIVATE_H
+#define TEE_PRIVATE_H
+
+#include <linux/types.h>
+#include <linux/device.h>
+#include <linux/cdev.h>
+#include <linux/completion.h>
+#include <linux/mutex.h>
+#include <linux/kref.h>
+
+struct tee_device;
+
+struct tee_shm {
+	struct list_head list_node;
+	struct tee_device *teedev;
+	phys_addr_t paddr;
+	void *kaddr;
+	size_t size;
+	struct dma_buf *dmabuf;
+	u32 flags;
+};
+
+struct tee_shm_pool_mgr;
+struct tee_shm_pool_mgr_ops {
+	int (*alloc)(struct tee_shm_pool_mgr *poolmgr, struct tee_shm *shm,
+		     size_t size);
+	void (*free)(struct tee_shm_pool_mgr *poolmgr, struct tee_shm *shm);
+};
+
+struct tee_shm_pool_mgr {
+	const struct tee_shm_pool_mgr_ops *ops;
+	void *private_data;
+};
+
+struct tee_shm_pool {
+	struct tee_shm_pool_mgr private_mgr;
+	struct tee_shm_pool_mgr dma_buf_mgr;
+	void (*destroy)(struct tee_shm_pool *pool);
+	void *private_data;
+};
+
+#define TEE_DEVICE_FLAG_REGISTERED	0x1
+#define TEE_MAX_DEV_NAME_LEN		32
+
+struct tee_device {
+	char name[TEE_MAX_DEV_NAME_LEN];
+	const struct tee_desc *desc;
+	int id;
+	unsigned flags;
+
+	struct device dev;
+	struct cdev cdev;
+
+	size_t num_users;
+	struct completion c_no_users;
+	struct mutex mutex;
+
+	struct list_head list_shm;
+	struct tee_shm_pool *pool;
+};
+
+int tee_shm_init(void);
+
+bool tee_device_get(struct tee_device *teedev);
+void tee_device_put(struct tee_device *teedev);
+
+#endif /*TEE_PRIVATE_H*/
diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
new file mode 100644
index 0000000..6732e77
--- /dev/null
+++ b/drivers/tee/tee_shm.c
@@ -0,0 +1,324 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/device.h>
+#include <linux/fdtable.h>
+#include <linux/sched.h>
+#include <linux/dma-buf.h>
+#include <linux/slab.h>
+#include <linux/tee_drv.h>
+#include "tee_private.h"
+
+static void tee_shm_release(struct tee_shm *shm)
+{
+	struct tee_device *teedev = shm->teedev;
+	struct tee_shm_pool_mgr *poolm;
+
+	mutex_lock(&teedev->mutex);
+	list_del(&shm->list_node);
+	mutex_unlock(&teedev->mutex);
+
+	if (shm->flags & TEE_SHM_DMA_BUF)
+		poolm = &teedev->pool->dma_buf_mgr;
+	else
+		poolm = &teedev->pool->private_mgr;
+
+	poolm->ops->free(poolm, shm);
+	kfree(shm);
+
+	tee_device_put(teedev);
+}
+
+static struct sg_table *tee_shm_op_map_dma_buf(struct dma_buf_attachment
+			*attach, enum dma_data_direction dir)
+{
+	return NULL;
+}
+
+static void tee_shm_op_unmap_dma_buf(struct dma_buf_attachment *attach,
+			struct sg_table *table, enum dma_data_direction dir)
+{
+}
+
+static void tee_shm_op_release(struct dma_buf *dmabuf)
+{
+	struct tee_shm *shm = dmabuf->priv;
+
+	tee_shm_release(shm);
+}
+
+static void *tee_shm_op_kmap_atomic(struct dma_buf *dmabuf,
+			unsigned long pgnum)
+{
+	return NULL;
+}
+
+static void *tee_shm_op_kmap(struct dma_buf *dmabuf, unsigned long pgnum)
+{
+	return NULL;
+}
+
+static int tee_shm_op_mmap(struct dma_buf *dmabuf,
+			struct vm_area_struct *vma)
+{
+	struct tee_shm *shm = dmabuf->priv;
+	size_t size = vma->vm_end - vma->vm_start;
+
+	return remap_pfn_range(vma, vma->vm_start, shm->paddr >> PAGE_SHIFT,
+			       size, vma->vm_page_prot);
+}
+
+static struct dma_buf_ops tee_shm_dma_buf_ops = {
+	.map_dma_buf = tee_shm_op_map_dma_buf,
+	.unmap_dma_buf = tee_shm_op_unmap_dma_buf,
+	.release = tee_shm_op_release,
+	.kmap_atomic = tee_shm_op_kmap_atomic,
+	.kmap = tee_shm_op_kmap,
+	.mmap = tee_shm_op_mmap,
+};
+
+struct tee_shm *tee_shm_alloc(struct tee_device *teedev, size_t size,
+			u32 flags)
+{
+	struct tee_shm_pool_mgr *poolm = NULL;
+	struct tee_shm *shm;
+	void *ret;
+	int rc;
+
+	if (!(flags & TEE_SHM_MAPPED)) {
+		dev_err(teedev->dev.parent,
+			"only mapped allocations supported\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	if ((flags & ~(TEE_SHM_MAPPED|TEE_SHM_DMA_BUF))) {
+		dev_err(teedev->dev.parent, "invalid shm flags 0x%x", flags);
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (!tee_device_get(teedev))
+		return ERR_PTR(-EINVAL);
+
+	if (!teedev->pool) {
+		/* teedev has been detached from driver */
+		ret = ERR_PTR(-EINVAL);
+		goto err;
+	}
+
+	shm = kzalloc(sizeof(struct tee_shm), GFP_KERNEL);
+	if (!shm) {
+		ret = ERR_PTR(-ENOMEM);
+		goto err;
+	}
+
+	shm->flags = flags;
+	shm->teedev = teedev;
+	if (flags & TEE_SHM_DMA_BUF)
+		poolm = &teedev->pool->dma_buf_mgr;
+	else
+		poolm = &teedev->pool->private_mgr;
+
+	rc = poolm->ops->alloc(poolm, shm, size);
+	if (rc) {
+		ret = ERR_PTR(rc);
+		goto err;
+	}
+
+	mutex_lock(&teedev->mutex);
+	list_add_tail(&shm->list_node, &teedev->list_shm);
+	mutex_unlock(&teedev->mutex);
+
+	if (flags & TEE_SHM_DMA_BUF) {
+		DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+
+		exp_info.ops = &tee_shm_dma_buf_ops;
+		exp_info.size = shm->size;
+		exp_info.flags = O_RDWR;
+		exp_info.priv = shm;
+
+		shm->dmabuf = dma_buf_export(&exp_info);
+		if (IS_ERR(shm->dmabuf)) {
+			ret = ERR_CAST(shm->dmabuf);
+			goto err;
+		}
+	}
+
+	return shm;
+err:
+	if (poolm && shm && shm->kaddr)
+		poolm->ops->free(poolm, shm);
+	kfree(shm);
+	tee_device_put(teedev);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(tee_shm_alloc);
+
+int tee_shm_get_fd(struct tee_shm *shm)
+{
+	u32 req_flags = TEE_SHM_MAPPED | TEE_SHM_DMA_BUF;
+	int fd;
+
+	if ((shm->flags & req_flags) != req_flags)
+		return -EINVAL;
+
+	fd = dma_buf_fd(shm->dmabuf, O_CLOEXEC);
+	if (fd >= 0)
+		get_dma_buf(shm->dmabuf);
+	return fd;
+}
+EXPORT_SYMBOL_GPL(tee_shm_get_fd);
+
+int tee_shm_put_fd(int fd)
+{
+	return __close_fd(current->files, fd);
+}
+EXPORT_SYMBOL_GPL(tee_shm_put_fd);
+
+void tee_shm_free(struct tee_shm *shm)
+{
+
+	/*
+	 * dma_buf_put() decreases the dmabuf reference counter and will
+	 * call tee_shm_release() when the last reference is gone.
+	 *
+	 * In the case of driver private memory we call tee_shm_release
+	 * directly instead as it doesn't have a reference counter.
+	 */
+	if (shm->flags & TEE_SHM_DMA_BUF)
+		dma_buf_put(shm->dmabuf);
+	else
+		tee_shm_release(shm);
+}
+EXPORT_SYMBOL_GPL(tee_shm_free);
+
+static bool cmp_key_va(struct tee_shm *shm, uintptr_t va)
+{
+	uintptr_t shm_va = (uintptr_t)shm->kaddr;
+
+	return (va >= shm_va) && (va < (shm_va + shm->size));
+}
+
+static bool cmp_key_pa(struct tee_shm *shm, uintptr_t pa)
+{
+	return (pa >= shm->paddr) && (pa < (shm->paddr + shm->size));
+}
+
+static struct tee_shm *tee_shm_find_by_key(struct tee_device *teedev, u32 flags,
+			bool (*cmp)(struct tee_shm *shm, uintptr_t key),
+			uintptr_t key)
+{
+	struct tee_shm *ret = NULL;
+	struct tee_shm *shm;
+
+	mutex_lock(&teedev->mutex);
+	list_for_each_entry(shm, &teedev->list_shm, list_node) {
+		if (cmp(shm, key)) {
+			ret = shm;
+			break;
+		}
+	}
+	mutex_unlock(&teedev->mutex);
+
+	return ret;
+}
+
+struct tee_shm *tee_shm_find_by_va(struct tee_device *teedev, u32 flags,
+			void *va)
+{
+	return tee_shm_find_by_key(teedev, flags, cmp_key_va, (uintptr_t)va);
+}
+EXPORT_SYMBOL_GPL(tee_shm_find_by_va);
+
+struct tee_shm *tee_shm_find_by_pa(struct tee_device *teedev, u32 flags,
+			phys_addr_t pa)
+{
+	return tee_shm_find_by_key(teedev, flags, cmp_key_pa, pa);
+}
+EXPORT_SYMBOL_GPL(tee_shm_find_by_pa);
+
+int tee_shm_va2pa(struct tee_shm *shm, void *va, phys_addr_t *pa)
+{
+	/* Check that we're in the range of the shm */
+	if ((char *)va < (char *)shm->kaddr)
+		return -EINVAL;
+	if ((char *)va >= ((char *)shm->kaddr + shm->size))
+		return -EINVAL;
+
+	return tee_shm_get_pa(
+			shm, (unsigned long)va - (unsigned long)shm->kaddr, pa);
+}
+EXPORT_SYMBOL_GPL(tee_shm_va2pa);
+
+int tee_shm_pa2va(struct tee_shm *shm, phys_addr_t pa, void **va)
+{
+	/* Check that we're in the range of the shm */
+	if (pa < shm->paddr)
+		return -EINVAL;
+	if (pa >= (shm->paddr + shm->size))
+		return -EINVAL;
+
+	if (va) {
+		void *v = tee_shm_get_va(shm, pa - shm->paddr);
+
+		if (IS_ERR(v))
+			return PTR_ERR(v);
+		*va = v;
+	}
+	return 0;
+}
+EXPORT_SYMBOL_GPL(tee_shm_pa2va);
+
+void *tee_shm_get_va(struct tee_shm *shm, size_t offs)
+{
+	if (offs >= shm->size)
+		return ERR_PTR(-EINVAL);
+	return (char *)shm->kaddr + offs;
+}
+EXPORT_SYMBOL_GPL(tee_shm_get_va);
+
+int tee_shm_get_pa(struct tee_shm *shm, size_t offs, phys_addr_t *pa)
+{
+	if (offs >= shm->size)
+		return -EINVAL;
+	if (pa)
+		*pa = shm->paddr + offs;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(tee_shm_get_pa);
+
+static bool is_shm_dma_buf(struct dma_buf *dmabuf)
+{
+	return dmabuf->ops == &tee_shm_dma_buf_ops;
+}
+
+struct tee_shm *tee_shm_get_from_fd(int fd)
+{
+	struct dma_buf *dmabuf = dma_buf_get(fd);
+
+	if (IS_ERR(dmabuf))
+		return ERR_CAST(dmabuf);
+
+	if (!is_shm_dma_buf(dmabuf)) {
+		dma_buf_put(dmabuf);
+		return ERR_PTR(-EINVAL);
+	}
+	return dmabuf->priv;
+}
+EXPORT_SYMBOL_GPL(tee_shm_get_from_fd);
+
+void tee_shm_put(struct tee_shm *shm)
+{
+	if (shm->flags & TEE_SHM_DMA_BUF)
+		dma_buf_put(shm->dmabuf);
+}
+EXPORT_SYMBOL_GPL(tee_shm_put);
diff --git a/drivers/tee/tee_shm_pool.c b/drivers/tee/tee_shm_pool.c
new file mode 100644
index 0000000..2ef22bc
--- /dev/null
+++ b/drivers/tee/tee_shm_pool.c
@@ -0,0 +1,133 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/device.h>
+#include <linux/dma-buf.h>
+#include <linux/slab.h>
+#include <linux/genalloc.h>
+#include <linux/tee_drv.h>
+#include "tee_private.h"
+
+static int pool_op_gen_alloc(struct tee_shm_pool_mgr *poolm,
+			struct tee_shm *shm, size_t size)
+{
+	unsigned long va;
+	struct gen_pool *genpool = poolm->private_data;
+	size_t s = roundup(size, 1 << genpool->min_alloc_order);
+
+	va = gen_pool_alloc(genpool, s);
+	if (!va)
+		return -ENOMEM;
+	shm->kaddr = (void *)va;
+	shm->paddr = gen_pool_virt_to_phys(genpool, va);
+	shm->size = s;
+	return 0;
+}
+
+static void pool_op_gen_free(struct tee_shm_pool_mgr *poolm,
+			struct tee_shm *shm)
+{
+	gen_pool_free(poolm->private_data, (unsigned long)shm->kaddr,
+		      shm->size);
+	shm->kaddr = NULL;
+}
+
+static const struct tee_shm_pool_mgr_ops pool_ops_generic = {
+	.alloc = pool_op_gen_alloc,
+	.free = pool_op_gen_free,
+};
+
+static void pool_res_mem_destroy(struct tee_shm_pool *pool)
+{
+	gen_pool_destroy(pool->private_mgr.private_data);
+	gen_pool_destroy(pool->dma_buf_mgr.private_data);
+}
+
+static int pool_res_mem_mgr_init(struct tee_shm_pool_mgr *mgr,
+			struct tee_shm_pool_mem_info *info, int min_alloc_order)
+{
+	size_t page_mask = PAGE_SIZE - 1;
+	struct gen_pool *genpool = NULL;
+	int rc;
+
+	/*
+	 * Start and end must be page aligned
+	 */
+	if ((info->vaddr & page_mask) || (info->paddr & page_mask) ||
+	    (info->size & page_mask))
+		return -EINVAL;
+
+	genpool = gen_pool_create(min_alloc_order, -1);
+	if (!genpool)
+		return -ENOMEM;
+
+	gen_pool_set_algo(genpool, gen_pool_best_fit, NULL);
+	rc = gen_pool_add_virt(genpool, info->vaddr, info->paddr, info->size,
+			       -1);
+	if (rc) {
+		gen_pool_destroy(genpool);
+		return rc;
+	}
+
+	mgr->private_data = genpool;
+	mgr->ops = &pool_ops_generic;
+	return 0;
+}
+
+struct tee_shm_pool *tee_shm_pool_alloc_res_mem(struct device *dev,
+			struct tee_shm_pool_mem_info *priv_info,
+			struct tee_shm_pool_mem_info *dmabuf_info)
+{
+	struct tee_shm_pool *pool = NULL;
+	int ret;
+
+	pool = kzalloc(sizeof(*pool), GFP_KERNEL);
+	if (!pool) {
+		ret = -ENOMEM;
+		goto err;
+	}
+
+	/*
+	 * Create the pool for driver private shared memory
+	 */
+	ret = pool_res_mem_mgr_init(&pool->private_mgr, priv_info,
+				    3 /* 8 byte aligned */);
+	if (ret)
+		goto err;
+
+	/*
+	 * Create the pool for dma_buf shared memory
+	 */
+	ret = pool_res_mem_mgr_init(&pool->dma_buf_mgr, dmabuf_info,
+				    PAGE_SHIFT);
+	if (ret)
+		goto err;
+
+	pool->destroy = pool_res_mem_destroy;
+	return pool;
+err:
+	if (ret == -ENOMEM)
+		dev_err(dev, "can't allocate memory for res_mem shared memory pool\n");
+	if (pool && pool->private_mgr.private_data)
+		gen_pool_destroy(pool->private_mgr.private_data);
+	kfree(pool);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(tee_shm_pool_alloc_res_mem);
+
+void tee_shm_pool_free(struct tee_shm_pool *pool)
+{
+	pool->destroy(pool);
+	kfree(pool);
+}
+EXPORT_SYMBOL_GPL(tee_shm_pool_free);
diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h
new file mode 100644
index 0000000..06cffa6
--- /dev/null
+++ b/include/linux/tee_drv.h
@@ -0,0 +1,299 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __TEE_DRV_H
+#define __TEE_DRV_H
+
+#include <linux/types.h>
+#include <linux/list.h>
+#include <linux/tee.h>
+
+/*
+ * The file describes the API provided by the generic TEE driver to the
+ * specific TEE driver.
+ */
+
+#define TEE_SHM_MAPPED		0x1	/* Memory mapped by the kernel */
+#define TEE_SHM_DMA_BUF		0x2	/* Memory with dma-buf handle */
+
+struct tee_device;
+struct tee_shm;
+struct tee_shm_pool;
+
+/**
+ * struct tee_context - driver specific context on file pointer data
+ * @teedev:	pointer to this drivers struct tee_device
+ * @data:	driver specific context data, managed by the driver
+ */
+struct tee_context {
+	struct tee_device *teedev;
+	void *data;
+};
+
+struct tee_param_memref {
+	size_t shm_offs;
+	size_t size;
+	struct tee_shm *shm;
+};
+
+struct tee_param_value {
+	u64 a;
+	u64 b;
+	u64 c;
+};
+
+struct tee_param {
+	u64 attr;
+	union {
+		struct tee_param_memref memref;
+		struct tee_param_value value;
+	} u;
+};
+
+/**
+ * struct tee_driver_ops - driver operations vtable
+ * @get_version:	returns version of driver
+ * @open:		called when the device file is opened
+ * @release:		release this open file
+ */
+struct tee_driver_ops {
+	void (*get_version)(struct tee_device *teedev,
+			struct tee_ioctl_version_data *vers);
+	int (*open)(struct tee_context *ctx);
+	void (*release)(struct tee_context *ctx);
+	int (*open_session)(struct tee_context *ctx,
+			struct tee_ioctl_open_session_arg *arg,
+			struct tee_param *param);
+	int (*close_session)(struct tee_context *ctx, u32 session);
+	int (*invoke_func)(struct tee_context *ctx,
+			struct tee_ioctl_invoke_arg *arg,
+			struct tee_param *param);
+	int (*cancel_req)(struct tee_context *ctx, u32 cancel_id, u32 session);
+	int (*supp_recv)(struct tee_context *ctx, u32 *func, u32 *num_params,
+			struct tee_param *param);
+	int (*supp_send)(struct tee_context *ctx, u32 ret, u32 num_params,
+			struct tee_param *param);
+};
+
+/**
+ * struct tee_desc - Describes the TEE driver to the subsystem
+ * @name:	name of driver
+ * @ops:	driver operations vtable
+ * @owner:	module providing the driver
+ * @flags:	Extra properties of driver, defined by TEE_DESC_* below
+ */
+#define TEE_DESC_PRIVILEGED	0x1
+struct tee_desc {
+	const char *name;
+	const struct tee_driver_ops *ops;
+	struct module *owner;
+	u32 flags;
+};
+
+
+/**
+ * tee_device_alloc() - Allocate a new struct tee_device instance
+ * @teedesc:	Descriptor for this driver
+ * @dev:	Parent device for this device
+ * @pool:	Shared memory pool, NULL if not used
+ * @driver_data: Private driver data for this device
+ *
+ * Allocates a new struct tee_device instance. The device is
+ * removed by tee_device_unregister().
+ *
+ * @returns a pointer to a 'struct tee_device' or an ERR_PTR on failure
+ */
+struct tee_device *tee_device_alloc(const struct tee_desc *teedesc,
+			struct device *dev, struct tee_shm_pool *pool,
+			void *driver_data);
+
+/**
+ * tee_device_register() - Registers a TEE device
+ * @teedev:	Device to register
+ *
+ * tee_device_unregister() need to be called to remove the @teedev if
+ * this function fails.
+ *
+ * @returns < 0 on failure
+ */
+int tee_device_register(struct tee_device *teedev);
+
+/**
+ * tee_device_unregister() - Removes a TEE device
+ * @teedev:	Device to unregister
+ *
+ * This function should be called to remove the @teedev even if
+ * tee_device_register() hasn't been called yet. Does nothing if
+ * @teedev is NULL.
+ */
+void tee_device_unregister(struct tee_device *teedev);
+
+/**
+ * struct tee_shm_pool_mem_info - holds information needed to create a shared memory pool
+ * @vaddr:	Virtual address of start of pool
+ * @paddr:	Physical address of start of pool
+ * @size:	Size in bytes of the pool
+ */
+struct tee_shm_pool_mem_info {
+	unsigned long vaddr;
+	unsigned long paddr;
+	size_t size;
+};
+
+/**
+ * tee_shm_pool_alloc_res_mem() - Create a shared memory pool from reserved memory range
+ * @dev:	Device allocating the pool
+ * @priv_info:	Information for driver private shared memory pool
+ * @dmabuf_info: Information for dma-buf shared memory pool
+ *
+ * Start and end of pools will must be page aligned.
+ *
+ * Allocation with the flag TEE_SHM_DMA_BUF set will use the range supplied
+ * in @dmabuf, others will use the range provided by @priv.
+ *
+ * @returns pointer to a 'struct tee_shm_pool' or an ERR_PTR on failure.
+ */
+struct tee_shm_pool *tee_shm_pool_alloc_res_mem(struct device *dev,
+			struct tee_shm_pool_mem_info *priv_info,
+			struct tee_shm_pool_mem_info *dmabuf_info);
+
+/**
+ * tee_shm_pool_free() - Free a shared memory pool
+ * @pool:	The shared memory pool to free
+ *
+ * The must be no remaining shared memory allocated from this pool when
+ * this function is called.
+ */
+void tee_shm_pool_free(struct tee_shm_pool *pool);
+
+/**
+ * tee_get_drvdata() - Return driver_data pointer
+ * @returns the driver_data pointer supplied to tee_register().
+ */
+void *tee_get_drvdata(struct tee_device *teedev);
+
+/**
+ * tee_shm_alloc() - Allocate shared memory
+ * @teedev:	Driver that allocates the shared memory
+ * @size:	Requested size of shared memory
+ * @flags:	Flags setting properties for the requested shared memory.
+ *
+ * Memory allocated as global shared memory is automatically freed when the
+ * TEE file pointer is closed. The @flags field uses the bits defined by
+ * TEE_SHM_* above. TEE_SHM_MAPPED must currently always be set. If
+ * TEE_SHM_DMA_BUF global shared memory will be allocated and associated
+ * with a dma-buf handle, else driver private memory.
+ *
+ * @returns a pointer to 'struct tee_shm'
+ */
+struct tee_shm *tee_shm_alloc(struct tee_device *teedev, size_t size,
+			u32 flags);
+
+/**
+ * tee_shm_free() - Free shared memory
+ * @shm:	Handle to shared memory to free
+ */
+void tee_shm_free(struct tee_shm *shm);
+
+/**
+ * tee_shm_find_by_va() - Find a shared memory handle by a virtual address
+ * @teedev:	The device that owns the shared memory
+ * @flags:	Select which type of shared memory to locate, if
+ *		TEE_SHM_DMA_BUF global shared memory else driver private
+ *		shared memory.
+ * @va:		Virtual address covered by the shared memory
+ * @returns a Handle to shared memory
+ */
+struct tee_shm *tee_shm_find_by_va(struct tee_device *teedev, u32 flags,
+			void *va);
+/**
+ * tee_shm_find_by_pa() - Find a shared memory handle by a physical address
+ * @teedev:	The device that owns the shared memory
+ * @flags:	Select which type of shared memory to locate, if
+ *		TEE_SHM_DMA_BUF global shared memory else driver private
+ *		shared memory.
+ * @pa:		Physical address covered by the shared memory
+ * @returns a Handle to shared memory
+ */
+struct tee_shm *tee_shm_find_by_pa(struct tee_device *teedev, u32 flags,
+			phys_addr_t pa);
+
+/**
+ * tee_shm_va2pa() - Get physical address of a virtual address
+ * @shm:	Shared memory handle
+ * @va:		Virtual address to tranlsate
+ * @pa:		Returned physical address
+ * @returns 0 on success and < 0 on failure
+ */
+int tee_shm_va2pa(struct tee_shm *shm, void *va, phys_addr_t *pa);
+
+/**
+ * tee_shm_pa2va() - Get virtual address of a physical address
+ * @shm:	Shared memory handle
+ * @pa:		Physical address to tranlsate
+ * @va:		Returned virtual address
+ * @returns 0 on success and < 0 on failure
+ */
+int tee_shm_pa2va(struct tee_shm *shm, phys_addr_t pa, void **va);
+
+/**
+ * tee_shm_get_va() - Get virtual address of a shared memory plus an offset
+ * @shm:	Shared memory handle
+ * @offs:	Offset from start of this shared memory
+ * @returns virtual address of the shared memory + offs if offs is within
+ *	the bounds of this shared memory, else an ERR_PTR
+ */
+void *tee_shm_get_va(struct tee_shm *shm, size_t offs);
+
+/**
+ * tee_shm_get_pa() - Get physical address of a shared memory plus an offset
+ * @shm:	Shared memory handle
+ * @offs:	Offset from start of this shared memory
+ * @pa:		Physical address to return
+ * @returns 0 if offs is within the bounds of this shared memory, else an
+ *	error code.
+ */
+int tee_shm_get_pa(struct tee_shm *shm, size_t offs, phys_addr_t *pa);
+
+/**
+ * tee_shm_get_from_fd() - Get a shared memory handle from a file descriptor
+ * @fd:		A user space file descriptor
+ *
+ * This function increases the reference counter on the shared memory and
+ * returns a handle.
+ * @returns handle to shared memory
+ */
+struct tee_shm *tee_shm_get_from_fd(int fd);
+
+/**
+ * tee_shm_put() - Decrease reference count on a shared memory handle
+ * @shm:	Shared memory handle
+ */
+void tee_shm_put(struct tee_shm *shm);
+
+/**
+ * tee_shm_get_fd() - Increase reference count and return file descriptor
+ * @shm:	Shared memory handle
+ * @returns user space file descriptor to shared memory
+ */
+int tee_shm_get_fd(struct tee_shm *shm);
+
+/**
+ * tee_shm_put_fd() - Decrease reference count and close file descriptor
+ * @fd:		File descriptor to close
+ * @returns < 0 on failure
+ */
+int tee_shm_put_fd(int fd);
+
+#endif /*__TEE_DRV_H*/
diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h
new file mode 100644
index 0000000..319cc61
--- /dev/null
+++ b/include/uapi/linux/tee.h
@@ -0,0 +1,383 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __TEE_H
+#define __TEE_H
+
+#include <linux/ioctl.h>
+#include <linux/types.h>
+
+/*
+ * This file describes the API provided by a TEE driver to user space.
+ *
+ * Each TEE driver defines a TEE specific protocol which is used for the
+ * data passed back and forth using TEE_IOC_CMD.
+ */
+
+
+/* Helpers to make the ioctl defines */
+#define TEE_IOC_MAGIC	0xa4
+#define TEE_IOC_BASE	0
+
+/* Flags relating to shared memory */
+#define TEE_IOCTL_SHM_MAPPED	0x1	/* memory mapped in normal world */
+#define TEE_IOCTL_SHM_DMA_BUF	0x2	/* dma-buf handle on shared memory */
+
+#define TEE_MAX_ARG_SIZE	1024
+
+#define TEE_GEN_CAP_GP		(1 << 0)/* Global Platform compliant TEE */
+
+/*
+ * TEE Implementation ID
+ */
+#define TEE_IMPL_ID_OPTEE	1
+
+/*
+ * OP-TEE specific capabilities
+ */
+#define TEE_OPTEE_CAP_TZ	(1 << 0)
+
+/**
+ * struct tee_ioctl_version_data - TEE version
+ * @impl_id:	[out] TEE implementation id
+ * @impl_caps:	[out] Implementation specific capabilities
+ * @gen_caps:	[out] Generic capabilities, defined by TEE_GEN_CAPS_* above
+ *
+ * Identifies the TEE implementaion, @impl_id is one of TEE_IMPL_ID_* above.
+ * @impl_caps is implementation specific, for example TEE_OPTEE_CAP_*
+ * is valid when @impl_id == TEE_IMPL_ID_OPTEE.
+ */
+struct tee_ioctl_version_data {
+	__u32 impl_id;
+	__u32 impl_caps;
+	__u32 gen_caps;
+};
+/**
+ * TEE_IOC_VERSION - query version of TEE
+ *
+ * Takes a tee_version struct and returns with the TEE version data filled
+ * in.
+ */
+#define TEE_IOC_VERSION		_IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 0, \
+				     struct tee_ioctl_version_data)
+
+/**
+ * struct tee_ioctl_shm_alloc_data - Shared memory allocate argument
+ * @size:	[in/out] Size of shared memory to allocate
+ * @flags:	[in/out] Flags to/from allocation.
+ * @fd:		[out] dma_buf file descriptor of the shared memory
+ *
+ * The flags field should currently be zero as input. Updated by the call
+ * with actual flags as defined by TEE_IOCTL_SHM_* above.
+ * This structure is used as argument for TEE_IOC_SHM_ALLOC below.
+ */
+struct tee_ioctl_shm_alloc_data {
+	__u64 size;
+	__u32 flags;
+	__s32 fd;
+};
+/**
+ * TEE_IOC_SHM_ALLOC - allocate shared memory
+ *
+ * Allocates shared memory between the user space process and secure OS.
+ * The returned file descriptor is used to map the shared memory into user
+ * space. The shared memory is freed when the descriptor is closed and the
+ * memory is unmapped.
+ */
+#define TEE_IOC_SHM_ALLOC	_IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + 1, \
+				     struct tee_ioctl_shm_alloc_data)
+
+/**
+ * struct tee_ioctl_buf_data - Variable sized buffer
+ * @buf_ptr:	[in] A __user pointer to a buffer
+ * @buf_len:	[in] Length of the buffer above
+ *
+ * Used as argument for TEE_IOC_OPEN_SESSION, TEE_IOC_INVOKE,
+ * TEE_IOC_SUPPL_RECV, and TEE_IOC_SUPPL_SEND below.
+ */
+struct tee_ioctl_buf_data {
+	__u64 buf_ptr;
+	__u64 buf_len;
+};
+
+
+/*
+ * Attributes for struct tee_ioctl_param, selects field in the union
+ */
+#define TEE_IOCTL_PARAM_ATTR_TYPE_NONE		0	/* parameter not used */
+
+/*
+ * These defines value parameters (struct tee_ioctl_param_value)
+ */
+#define TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT	1
+#define TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT	2
+#define TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT	3	/* input and output */
+
+/*
+ * These defines shared memory reference parameters (struct
+ * tee_ioctl_param_memref)
+ */
+#define TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT	5
+#define TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT	6
+#define TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT	7	/* input and output */
+
+/*
+ * Mask for the type part of the attribute, leaves room for more types
+ */
+#define TEE_IOCTL_PARAM_ATTR_TYPE_MASK		0xff
+
+/*
+ * Matches TEEC_LOGIN_* in GP TEE Client API
+ * Is only defined for GP compliant TEEs
+ */
+#define TEE_IOCTL_LOGIN_PUBLIC			0
+#define TEE_IOCTL_LOGIN_USER			1
+#define TEE_IOCTL_LOGIN_GROUP			2
+#define TEE_IOCTL_LOGIN_APPLICATION		4
+#define TEE_IOCTL_LOGIN_USER_APPLICATION	5
+#define TEE_IOCTL_LOGIN_GROUP_APPLICATION	6
+
+/**
+ * struct tee_ioctl_param_memref - memory reference
+ * @shm_offs:	Offset into the shared memory object
+ * @size:	Size of the buffer
+ * @shm_fd:	Shared memory file descriptor
+ *
+ * Shared memory is allocated with TEE_IOC_SHM_ALLOC which returns a file
+ * descriptor connected to the shared memory object. A memref can reference
+ * a part of a shared memory by specifying an offset (@shm_offs) and @size
+ * of the object. To supply the entire shared memory object set @shm_offs to 0
+ * and @size to the previously returned size of the object.
+ */
+struct tee_ioctl_param_memref {
+	__u64 shm_offs;
+	__u64 size;
+	__s64 shm_fd;
+};
+
+/**
+ * struct tee_ioctl_param_value - values
+ * @a: first value
+ * @b: second value
+ * @c: third value
+ */
+struct tee_ioctl_param_value {
+	__u64 a;
+	__u64 b;
+	__u64 c;
+};
+
+/**
+ * struct tee_ioctl_param - parameter
+ * @attr: attributes
+ * @memref: a memory reference
+ * @value: a value
+ *
+ * @attr & TEE_PARAM_ATTR_TYPE_MASK indicates if memref or value is used in
+ * the union. TEE_PARAM_ATTR_TYPE_VALUE_* indicates value and
+ * TEE_PARAM_ATTR_TYPE_MEMREF_* indicates memref. TEE_PARAM_ATTR_TYPE_NONE
+ * indicates that none of the members are used.
+ */
+struct tee_ioctl_param {
+	__u64 attr;
+	union {
+		struct tee_ioctl_param_memref memref;
+		struct tee_ioctl_param_value value;
+	} u;
+};
+
+#define TEE_IOCTL_UUID_LEN		16
+
+/**
+ * struct tee_ioctl_open_session_arg - Open session argument
+ * @uuid:	[in] UUID of the Trusted Application
+ * @clnt_uuid:	[in] UUID of client
+ * @clnt_login:	[in] Login class of client, TEE_LOGIN_* above
+ * @cancel_id:	[in] Cancellation id, a unique value to identify this request
+ * @session:	[out] Session id
+ * @ret:	[out] return value
+ * @ret_origin	[out] origin of the return value
+ * @num_params	[in] number of parameters following this struct
+ */
+struct tee_ioctl_open_session_arg {
+	__u8 uuid[TEE_IOCTL_UUID_LEN];
+	__u8 clnt_uuid[TEE_IOCTL_UUID_LEN];
+	__u32 clnt_login;
+	__u32 cancel_id;
+	__u32 session;
+	__u32 ret;
+	__u32 ret_origin;
+	__u32 num_params;
+	/*
+	 * this struct is 8 byte aligned since the 'struct tee_ioctl_param'
+	 * which follows requires 8 byte alignment.
+	 *
+	 * Commented out element used to visualize the layout dynamic part
+	 * of the struct. This field is not available at all if
+	 * num_params == 0.
+	 *
+	 * struct tee_ioctl_param params[num_params];
+	 */
+} __aligned(8);
+
+/**
+ * TEE_IOC_OPEN_SESSION - opens a session to a Trusted Application
+ *
+ * Takes a struct tee_ioctl_buf_data which contains a struct
+ * tee_ioctl_open_session_arg followed by any array of struct
+ * tee_ioctl_param
+ */
+#define TEE_IOC_OPEN_SESSION	_IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 2, \
+				     struct tee_ioctl_buf_data)
+
+/**
+ * struct tee_ioctl_invoke_func_arg - Invokes a function in a Trusted Application
+ * @func:	[in] Trusted Application function, specific to the TA
+ * @session:	[in] Session id
+ * @cancel_id:	[in] Cancellation id, a unique value to identify this request
+ * @ret:	[out] return value
+ * @ret_origin	[out] origin of the return value
+ * @num_params	[in] number of parameters following this struct
+ */
+struct tee_ioctl_invoke_arg {
+	__u32 func;
+	__u32 session;
+	__u32 cancel_id;
+	__u32 ret;
+	__u32 ret_origin;
+	__u32 num_params;
+	/*
+	 * this struct is 8 byte aligned since the 'struct tee_ioctl_param'
+	 * which follows requires 8 byte alignment.
+	 *
+	 * Commented out element used to visualize the layout dynamic part
+	 * of the struct. This field is not available at all if
+	 * num_params == 0.
+	 *
+	 * struct tee_ioctl_param params[num_params];
+	 */
+} __aligned(8);
+
+/**
+ * TEE_IOC_INVOKE - Invokes a function in a Trusted Application
+ *
+ * Takes a struct tee_ioctl_buf_data which contains a struct
+ * tee_invoke_func_arg followed by any array of struct tee_param
+ */
+#define TEE_IOC_INVOKE		_IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 3, \
+				     struct tee_ioctl_buf_data)
+
+/**
+ * struct tee_ioctl_cancel_arg - Cancels an open session or invoke ioctl
+ * @cancel_id:	[in] Cancellation id, a unique value to identify this request
+ * @session:	[in] Session id, if the session is opened, else set to 0
+ */
+struct tee_ioctl_cancel_arg {
+	__u32 cancel_id;
+	__u32 session;
+};
+/**
+ * TEE_IOC_CANCEL - Cancels an open session or invoke
+ */
+#define TEE_IOC_CANCEL		_IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 4, \
+				     struct tee_ioctl_cancel_arg)
+
+/**
+ * struct tee_ioctl_close_session_arg - Closes an open session
+ * @session:	[in] Session id
+ */
+struct tee_ioctl_close_session_arg {
+	__u32 session;
+};
+/**
+ * TEE_IOC_CLOSE_SESSION - Closes a session
+ */
+#define TEE_IOC_CLOSE_SESSION	_IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 5, \
+				     struct tee_ioctl_close_session_arg)
+
+/**
+ * struct tee_iocl_supp_recv_arg - Receive a request for a supplicant function
+ * @func:	[in] supplicant function
+ * @num_params	[in/out] number of parameters following this struct
+ *
+ * @num_params is the number of params that tee-supplicant has room to
+ * receive when input, @num_params is the number of actual params
+ * tee-supplicant receives when output.
+ */
+struct tee_iocl_supp_recv_arg {
+	__u32 func;
+	__u32 num_params;
+	/*
+	 * this struct is 8 byte aligned since the 'struct tee_ioctl_param'
+	 * which follows requires 8 byte alignment.
+	 *
+	 * Commented out element used to visualize the layout dynamic part
+	 * of the struct. This field is not available at all if
+	 * num_params == 0.
+	 *
+	 * struct tee_ioctl_param params[num_params];
+	 */
+} __aligned(8);
+/**
+ * TEE_IOC_SUPPL_RECV - Receive a request for a supplicant function
+ *
+ * Takes a struct tee_ioctl_buf_data which contains a struct
+ * tee_iocl_supp_recv_arg followed by any array of struct tee_param
+ */
+#define TEE_IOC_SUPPL_RECV	_IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 6, \
+				     struct tee_ioctl_buf_data)
+
+
+/**
+ * struct tee_iocl_supp_send_arg - Send a response to a received request
+ * @ret:	[out] return value
+ * @num_params	[in] number of parameters following this struct
+ */
+struct tee_iocl_supp_send_arg {
+	__u32 ret;
+	__u32 num_params;
+	/*
+	 * this struct is 8 byte aligned since the 'struct tee_ioctl_param'
+	 * which follows requires 8 byte alignment.
+	 *
+	 * Commented out element used to visualize the layout dynamic part
+	 * of the struct. This field is not available at all if
+	 * num_params == 0.
+	 *
+	 * struct tee_ioctl_param params[num_params];
+	 */
+} __aligned(8);
+/**
+ * TEE_IOC_SUPPL_SEND - Receive a request for a supplicant function
+ *
+ * Takes a struct tee_ioctl_buf_data which contains a struct
+ * tee_iocl_supp_send_arg followed by any array of struct tee_param
+ */
+#define TEE_IOC_SUPPL_SEND	_IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 7, \
+				     struct tee_ioctl_buf_data)
+
+
+/*
+ * Five syscalls are used when communicating with the TEE driver.
+ * open(): opens the device associated with the driver
+ * ioctl(): as described above operating on the file descriptor from open()
+ * close(): two cases
+ *   - closes the device file descriptor
+ *   - closes a file descriptor connected to allocated shared memory
+ * mmap(): maps shared memory into user space using information from struct
+ *	   tee_ioctl_shm_alloc_data
+ * munmap(): unmaps previously shared memory
+ */
+
+#endif /*__TEE_H*/
-- 
1.9.1



From jens.wiklander at linaro.org  Mon Feb  1 01:15:39 2016
From: jens.wiklander at linaro.org (Jens Wiklander)
Date: Mon,  1 Feb 2016 10:15:39 +0100
Subject: [PATCH v7 3/4] tee: add OP-TEE driver
In-Reply-To: <1454318140-7962-1-git-send-email-jens.wiklander@linaro.org>
References: <1454318140-7962-1-git-send-email-jens.wiklander@linaro.org>
Message-ID: <1454318140-7962-4-git-send-email-jens.wiklander@linaro.org>

Adds a OP-TEE driver which also can be compiled as a loadable module.

* Targets ARM and ARM64
* Supports using reserved memory from OP-TEE as shared memory
* Probes OP-TEE version using SMCs
* Accepts requests on privileged and unprivileged device
* Uses OPTEE message protocol version 2 to communicate with secure world

Signed-off-by: Jens Wiklander <jens.wiklander at linaro.org>
---
 MAINTAINERS                       |   5 +
 drivers/tee/Kconfig               |  10 +
 drivers/tee/Makefile              |   1 +
 drivers/tee/optee/Kconfig         |   8 +
 drivers/tee/optee/Makefile        |   5 +
 drivers/tee/optee/call.c          | 400 +++++++++++++++++++++++++++++
 drivers/tee/optee/core.c          | 522 ++++++++++++++++++++++++++++++++++++++
 drivers/tee/optee/optee_msg.h     | 423 ++++++++++++++++++++++++++++++
 drivers/tee/optee/optee_private.h | 146 +++++++++++
 drivers/tee/optee/optee_smc.h     | 418 ++++++++++++++++++++++++++++++
 drivers/tee/optee/rpc.c           | 322 +++++++++++++++++++++++
 drivers/tee/optee/supp.c          | 212 ++++++++++++++++
 12 files changed, 2472 insertions(+)
 create mode 100644 drivers/tee/optee/Kconfig
 create mode 100644 drivers/tee/optee/Makefile
 create mode 100644 drivers/tee/optee/call.c
 create mode 100644 drivers/tee/optee/core.c
 create mode 100644 drivers/tee/optee/optee_msg.h
 create mode 100644 drivers/tee/optee/optee_private.h
 create mode 100644 drivers/tee/optee/optee_smc.h
 create mode 100644 drivers/tee/optee/rpc.c
 create mode 100644 drivers/tee/optee/supp.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e3dfc81e..4a0989c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8091,6 +8091,11 @@ F:	arch/*/oprofile/
 F:	drivers/oprofile/
 F:	include/linux/oprofile.h
 
+OP-TEE DRIVER
+M:	Jens Wiklander <jens.wiklander at linaro.org>
+S:	Maintained
+F:	drivers/tee/optee/
+
 ORACLE CLUSTER FILESYSTEM 2 (OCFS2)
 M:	Mark Fasheh <mfasheh at suse.com>
 M:	Joel Becker <jlbec at evilplan.org>
diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
index 64a8cd7..b269276 100644
--- a/drivers/tee/Kconfig
+++ b/drivers/tee/Kconfig
@@ -6,3 +6,13 @@ config TEE
 	help
 	  This implements a generic interface towards a Trusted Execution
 	  Environment (TEE).
+
+if TEE
+
+menu "TEE drivers"
+
+source "drivers/tee/optee/Kconfig"
+
+endmenu
+
+endif
diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
index 60d2dab..53f3c76 100644
--- a/drivers/tee/Makefile
+++ b/drivers/tee/Makefile
@@ -1,3 +1,4 @@
 obj-y += tee.o
 obj-y += tee_shm.o
 obj-y += tee_shm_pool.o
+obj-$(CONFIG_OPTEE) += optee/
diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
new file mode 100644
index 0000000..a7a8b71
--- /dev/null
+++ b/drivers/tee/optee/Kconfig
@@ -0,0 +1,8 @@
+# OP-TEE Trusted Execution Environment Configuration
+config OPTEE
+	tristate "OP-TEE"
+	default n
+	depends on HAVE_ARM_SMCCC
+	help
+	  This implements the OP-TEE Trusted Execution Environment (TEE)
+	  driver.
diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
new file mode 100644
index 0000000..92fe578
--- /dev/null
+++ b/drivers/tee/optee/Makefile
@@ -0,0 +1,5 @@
+obj-$(CONFIG_OPTEE) += optee.o
+optee-objs += core.o
+optee-objs += call.o
+optee-objs += rpc.o
+optee-objs += supp.o
diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
new file mode 100644
index 0000000..c567f98
--- /dev/null
+++ b/drivers/tee/optee/call.c
@@ -0,0 +1,400 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/types.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <linux/device.h>
+#include <linux/tee_drv.h>
+#include <linux/arm-smccc.h>
+#include "optee_private.h"
+#include "optee_smc.h"
+
+struct optee_call_waiter {
+	struct list_head list_node;
+	struct completion c;
+	bool completed;
+};
+
+static void optee_cq_wait_init(struct optee_call_queue *cq,
+			struct optee_call_waiter *w)
+{
+	mutex_lock(&cq->mutex);
+	/*
+	 * We add ourselves to the queue, but we don't wait. This
+	 * guarentees that we don't lose a completion if secure world
+	 * returns busy and another thread just exited and try to complete
+	 * someone.
+	 */
+	w->completed = false;
+	init_completion(&w->c);
+	list_add_tail(&w->list_node, &cq->waiters);
+	mutex_unlock(&cq->mutex);
+}
+
+static void optee_cq_wait_for_completion(struct optee_call_queue *cq,
+			struct optee_call_waiter *w)
+{
+	wait_for_completion(&w->c);
+
+	mutex_lock(&cq->mutex);
+
+	/* Move to end of list to get out of the way for other waiters */
+	list_del(&w->list_node);
+	w->completed = false;
+	reinit_completion(&w->c);
+	list_add_tail(&w->list_node, &cq->waiters);
+
+	mutex_unlock(&cq->mutex);
+}
+
+static void optee_cq_complete_one(struct optee_call_queue *cq)
+{
+	struct optee_call_waiter *w;
+
+	list_for_each_entry(w, &cq->waiters, list_node) {
+		if (!w->completed) {
+			complete(&w->c);
+			w->completed = true;
+			break;
+		}
+	}
+}
+
+static void optee_cq_wait_final(struct optee_call_queue *cq,
+			struct optee_call_waiter *w)
+{
+	mutex_lock(&cq->mutex);
+
+	/* Get out of the list */
+	list_del(&w->list_node);
+
+	optee_cq_complete_one(cq);
+	/*
+	 * If we're completed we've got a completion that some other task
+	 * could have used instead.
+	 */
+	if (w->completed)
+		optee_cq_complete_one(cq);
+
+	mutex_unlock(&cq->mutex);
+}
+
+/* Requires the filpstate mutex to be held */
+static struct optee_session *find_session(struct optee_context_data *ctxdata,
+			u32 session_id)
+{
+	struct optee_session *sess;
+
+	list_for_each_entry(sess, &ctxdata->sess_list, list_node)
+		if (sess->session_id == session_id)
+			return sess;
+	return NULL;
+}
+
+u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg)
+{
+	struct optee *optee = tee_get_drvdata(ctx->teedev);
+	struct optee_call_waiter w;
+	struct optee_rpc_param param = { };
+	u32 ret;
+
+	param.a0 = OPTEE_SMC_CALL_WITH_ARG;
+	reg_pair_from_64(&param.a1, &param.a2, parg);
+	/* Initialize waiter */
+	optee_cq_wait_init(&optee->call_queue, &w);
+	while (true) {
+		struct arm_smccc_res res;
+
+		optee->invoke_fn(param.a0, param.a1, param.a2, param.a3,
+				 param.a4, param.a5, param.a6, param.a7,
+				 &res);
+
+		if (res.a0 == OPTEE_SMC_RETURN_ETHREAD_LIMIT) {
+			/*
+			 * Out of threads in secure world, wait for a thread
+			 * become available.
+			 */
+			optee_cq_wait_for_completion(&optee->call_queue, &w);
+		} else if (OPTEE_SMC_RETURN_IS_RPC(res.a0)) {
+			param.a0 = res.a0;
+			param.a1 = res.a1;
+			param.a2 = res.a2;
+			param.a3 = res.a3;
+			optee_handle_rpc(ctx, &param);
+		} else {
+			ret = res.a0;
+			break;
+		}
+	}
+	/*
+	 * We're done with our thread in secure world, if there's any
+	 * thread waiters wake up one.
+	 */
+	optee_cq_wait_final(&optee->call_queue, &w);
+	return ret;
+}
+
+static struct tee_shm *get_msg_arg(struct tee_context *ctx, size_t num_params,
+			struct optee_msg_arg **msg_arg, phys_addr_t *msg_parg)
+{
+	int rc;
+	struct tee_shm *shm;
+	struct optee_msg_arg *ma;
+
+	shm = tee_shm_alloc(ctx->teedev, OPTEE_MSG_GET_ARG_SIZE(num_params),
+			    TEE_SHM_MAPPED);
+	if (IS_ERR(shm))
+		return shm;
+	ma = tee_shm_get_va(shm, 0);
+	if (IS_ERR(ma)) {
+		rc = PTR_ERR(ma);
+		goto out;
+	}
+	rc = tee_shm_get_pa(shm, 0, msg_parg);
+	if (rc)
+		goto out;
+
+	memset(ma, 0, OPTEE_MSG_GET_ARG_SIZE(num_params));
+	ma->num_params = num_params;
+	*msg_arg = ma;
+out:
+	if (rc) {
+		tee_shm_free(shm);
+		return ERR_PTR(rc);
+	}
+	return shm;
+}
+
+int optee_open_session(struct tee_context *ctx,
+			struct tee_ioctl_open_session_arg *arg,
+			struct tee_param *param)
+{
+	struct optee_context_data *ctxdata = ctx->data;
+	int rc;
+	struct tee_shm *shm;
+	struct optee_msg_arg *msg_arg;
+	phys_addr_t msg_parg;
+	struct optee_msg_param *msg_param;
+	struct optee_session *sess = NULL;
+
+	/* +2 for the meta parameters added below */
+	shm = get_msg_arg(ctx, arg->num_params + 2, &msg_arg, &msg_parg);
+	if (IS_ERR(shm))
+		return PTR_ERR(shm);
+
+	msg_arg->cmd = OPTEE_MSG_CMD_OPEN_SESSION;
+	msg_arg->cancel_id = arg->cancel_id;
+	msg_param = OPTEE_MSG_GET_PARAMS(msg_arg);
+
+	/*
+	 * Initialize and add the meta parameters needed when opening a
+	 * session.
+	 */
+	msg_param[0].attr = OPTEE_MSG_ATTR_TYPE_VALUE_INPUT |
+			    OPTEE_MSG_ATTR_META;
+	msg_param[1].attr = OPTEE_MSG_ATTR_TYPE_VALUE_INPUT |
+			    OPTEE_MSG_ATTR_META;
+	memcpy(&msg_param[0].u.value, arg->uuid, sizeof(arg->uuid));
+	memcpy(&msg_param[1].u.value, arg->uuid, sizeof(arg->clnt_uuid));
+	msg_param[1].u.value.c = arg->clnt_login;
+
+	rc = optee_to_msg_param(msg_param + 2, arg->num_params, param);
+	if (rc)
+		goto out;
+
+	sess = kzalloc(sizeof(struct optee_session), GFP_KERNEL);
+	if (!sess) {
+		rc = -ENOMEM;
+		goto out;
+	}
+
+	if (optee_do_call_with_arg(ctx, msg_parg)) {
+		msg_arg->ret = TEEC_ERROR_COMMUNICATION;
+		msg_arg->ret_origin = TEEC_ORIGIN_COMMS;
+	}
+
+	if (msg_arg->ret == TEEC_SUCCESS) {
+		/* A new session has been created, add it to the list. */
+		sess->session_id = msg_arg->session;
+		mutex_lock(&ctxdata->mutex);
+		list_add(&sess->list_node, &ctxdata->sess_list);
+		mutex_unlock(&ctxdata->mutex);
+		sess = NULL;
+	}
+
+	if (optee_from_msg_param(param, arg->num_params, msg_param + 2)) {
+		arg->ret = TEEC_ERROR_COMMUNICATION;
+		arg->ret_origin = TEEC_ORIGIN_COMMS;
+		/* Close session again to avoid leakage */
+		optee_close_session(ctx, msg_arg->session);
+	} else {
+		arg->session = msg_arg->session;
+		arg->ret = msg_arg->ret;
+		arg->ret_origin = msg_arg->ret_origin;
+	}
+out:
+	kfree(sess);
+	tee_shm_free(shm);
+	return rc;
+}
+
+int optee_close_session(struct tee_context *ctx, u32 session)
+{
+	struct optee_context_data *ctxdata = ctx->data;
+	struct tee_shm *shm;
+	struct optee_msg_arg *msg_arg;
+	phys_addr_t msg_parg;
+	struct optee_session *sess;
+
+	/* Check that the session is valid and remove it from the list */
+	mutex_lock(&ctxdata->mutex);
+	sess = find_session(ctxdata, session);
+	if (sess)
+		list_del(&sess->list_node);
+	mutex_unlock(&ctxdata->mutex);
+	if (!sess)
+		return -EINVAL;
+	kfree(sess);
+
+	shm = get_msg_arg(ctx, 0, &msg_arg, &msg_parg);
+	if (IS_ERR(shm))
+		return PTR_ERR(shm);
+
+	msg_arg->cmd = OPTEE_MSG_CMD_CLOSE_SESSION;
+	msg_arg->session = session;
+	optee_do_call_with_arg(ctx, msg_parg);
+
+	tee_shm_free(shm);
+	return 0;
+}
+
+int optee_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg,
+			struct tee_param *param)
+{
+	struct optee_context_data *ctxdata = ctx->data;
+	struct tee_shm *shm;
+	struct optee_msg_arg *msg_arg;
+	phys_addr_t msg_parg;
+	struct optee_msg_param *msg_param;
+	struct optee_session *sess;
+	int rc;
+
+	/* Check that the session is valid */
+	mutex_lock(&ctxdata->mutex);
+	sess = find_session(ctxdata, arg->session);
+	mutex_unlock(&ctxdata->mutex);
+	if (!sess)
+		return -EINVAL;
+
+	shm = get_msg_arg(ctx, arg->num_params, &msg_arg, &msg_parg);
+	if (IS_ERR(shm))
+		return PTR_ERR(shm);
+	msg_arg->cmd = OPTEE_MSG_CMD_INVOKE_COMMAND;
+	msg_arg->func = arg->func;
+	msg_arg->session = arg->session;
+	msg_arg->cancel_id = arg->cancel_id;
+	msg_param = OPTEE_MSG_GET_PARAMS(msg_arg);
+
+	rc = optee_to_msg_param(msg_param, arg->num_params, param);
+	if (rc)
+		goto out;
+
+	if (optee_do_call_with_arg(ctx, msg_parg)) {
+		msg_arg->ret = TEEC_ERROR_COMMUNICATION;
+		msg_arg->ret_origin = TEEC_ORIGIN_COMMS;
+	}
+
+	if (optee_from_msg_param(param, arg->num_params, msg_param)) {
+		msg_arg->ret = TEEC_ERROR_COMMUNICATION;
+		msg_arg->ret_origin = TEEC_ORIGIN_COMMS;
+	}
+
+	arg->ret = msg_arg->ret;
+	arg->ret_origin = msg_arg->ret_origin;
+out:
+	tee_shm_free(shm);
+	return rc;
+}
+
+int optee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session)
+{
+	struct optee_context_data *ctxdata = ctx->data;
+	struct tee_shm *shm;
+	struct optee_msg_arg *msg_arg;
+	phys_addr_t msg_parg;
+	struct optee_session *sess;
+
+	/* Check that the session is valid */
+	mutex_lock(&ctxdata->mutex);
+	sess = find_session(ctxdata, session);
+	mutex_unlock(&ctxdata->mutex);
+	if (!sess)
+		return -EINVAL;
+
+	shm = get_msg_arg(ctx, 0, &msg_arg, &msg_parg);
+	if (IS_ERR(shm))
+		return PTR_ERR(shm);
+
+	msg_arg->cmd = OPTEE_MSG_CMD_CANCEL;
+	msg_arg->session = session;
+	msg_arg->cancel_id = cancel_id;
+	optee_do_call_with_arg(ctx, msg_parg);
+
+	tee_shm_free(shm);
+	return 0;
+}
+
+void optee_enable_shm_cache(struct optee *optee)
+{
+	struct optee_call_waiter w;
+
+	/* We need to retry until secure world isn't busy. */
+	optee_cq_wait_init(&optee->call_queue, &w);
+	while (true) {
+		struct arm_smccc_res res;
+
+		optee->invoke_fn(OPTEE_SMC_ENABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0,
+				 0, &res);
+		if (res.a0 == OPTEE_SMC_RETURN_OK)
+			break;
+		optee_cq_wait_for_completion(&optee->call_queue, &w);
+	}
+	optee_cq_wait_final(&optee->call_queue, &w);
+}
+
+void optee_disable_shm_cache(struct optee *optee)
+{
+	struct optee_call_waiter w;
+
+	/* We need to retry until secure world isn't busy. */
+	optee_cq_wait_init(&optee->call_queue, &w);
+	while (true) {
+		struct arm_smccc_res res;
+
+		optee->invoke_fn(OPTEE_SMC_DISABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0,
+				 0, &res);
+		if (res.a0 == OPTEE_SMC_RETURN_ENOTAVAIL)
+			break; /* All shm's freed */
+		if (res.a0 == OPTEE_SMC_RETURN_OK) {
+			struct tee_shm *shm;
+
+			shm = reg_pair_to_ptr(res.a1, res.a2);
+			tee_shm_free(shm);
+		} else
+			optee_cq_wait_for_completion(&optee->call_queue, &w);
+	}
+	optee_cq_wait_final(&optee->call_queue, &w);
+}
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
new file mode 100644
index 0000000..874550c
--- /dev/null
+++ b/drivers/tee/optee/core.c
@@ -0,0 +1,522 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/types.h>
+#include <linux/string.h>
+#include <linux/errno.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/tee_drv.h>
+#include "optee_private.h"
+#include "optee_smc.h"
+
+#define DRIVER_NAME "optee"
+
+#define OPTEE_SHM_NUM_PRIV_PAGES	1
+
+int optee_from_msg_param(struct tee_param *params, size_t num_params,
+			const struct optee_msg_param *msg_params)
+{
+	int rc;
+	size_t n;
+	struct tee_shm *shm;
+	phys_addr_t pa;
+
+	for (n = 0; n < num_params; n++) {
+		struct tee_param *p = params + n;
+		const struct optee_msg_param *mp = msg_params + n;
+		u32 attr = mp->attr & OPTEE_MSG_ATTR_TYPE_MASK;
+
+		switch (attr) {
+		case OPTEE_MSG_ATTR_TYPE_NONE:
+			p->attr = TEE_IOCTL_PARAM_ATTR_TYPE_NONE;
+			memset(&p->u, 0, sizeof(p->u));
+			break;
+		case OPTEE_MSG_ATTR_TYPE_VALUE_INPUT:
+		case OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT:
+		case OPTEE_MSG_ATTR_TYPE_VALUE_INOUT:
+			p->attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT +
+				  attr - OPTEE_MSG_ATTR_TYPE_VALUE_INPUT;
+			p->u.value.a = mp->u.value.a;
+			p->u.value.b = mp->u.value.b;
+			p->u.value.c = mp->u.value.c;
+			break;
+		case OPTEE_MSG_ATTR_TYPE_TMEM_INPUT:
+		case OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT:
+		case OPTEE_MSG_ATTR_TYPE_TMEM_INOUT:
+			p->attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT +
+				  attr - OPTEE_MSG_ATTR_TYPE_TMEM_INPUT;
+			p->u.memref.size = mp->u.tmem.size;
+			shm = (struct tee_shm *)(unsigned long)
+				mp->u.tmem.shm_ref;
+			if (!shm) {
+				p->u.memref.shm_offs = 0;
+				p->u.memref.shm = NULL;
+				break;
+			}
+			rc = tee_shm_get_pa(shm, 0, &pa);
+			if (rc)
+				return rc;
+			p->u.memref.shm_offs = pa - mp->u.tmem.buf_ptr;
+			p->u.memref.shm = shm;
+
+			/* Check that the memref is covered by the shm object */
+			if (p->u.memref.size) {
+				size_t o = p->u.memref.shm_offs +
+					   p->u.memref.size - 1;
+
+				rc = tee_shm_get_pa(shm, o, NULL);
+				if (rc)
+					return rc;
+			}
+			break;
+		default:
+			return -EINVAL;
+		}
+	}
+	return 0;
+}
+
+int optee_to_msg_param(struct optee_msg_param *msg_params, size_t num_params,
+			const struct tee_param *params)
+{
+	int rc;
+	size_t n;
+	phys_addr_t pa;
+
+	for (n = 0; n < num_params; n++) {
+		const struct tee_param *p = params + n;
+		struct optee_msg_param *mp = msg_params + n;
+
+		switch (p->attr) {
+		case TEE_IOCTL_PARAM_ATTR_TYPE_NONE:
+			mp->attr = TEE_IOCTL_PARAM_ATTR_TYPE_NONE;
+			memset(&mp->u, 0, sizeof(mp->u));
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT:
+			mp->attr = OPTEE_MSG_ATTR_TYPE_VALUE_INPUT + p->attr -
+				   TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
+			mp->u.value.a = p->u.value.a;
+			mp->u.value.b = p->u.value.b;
+			mp->u.value.c = p->u.value.c;
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT:
+			mp->attr = OPTEE_MSG_ATTR_TYPE_TMEM_INPUT +
+				   p->attr -
+				   TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT;
+			mp->u.tmem.shm_ref = (unsigned long)p->u.memref.shm;
+			mp->u.tmem.size = p->u.memref.size;
+			if (!p->u.memref.shm) {
+				mp->u.tmem.buf_ptr = 0;
+				break;
+			}
+			rc = tee_shm_get_pa(p->u.memref.shm,
+					    p->u.memref.shm_offs, &pa);
+			if (rc)
+				return rc;
+			mp->u.tmem.buf_ptr = pa;
+			mp->attr |= OPTEE_MSG_ATTR_CACHE_PREDEFINED <<
+					OPTEE_MSG_ATTR_CACHE_SHIFT;
+			break;
+		default:
+			return -EINVAL;
+		}
+	}
+	return 0;
+}
+
+static void optee_get_version(struct tee_device *teedev,
+			struct tee_ioctl_version_data *vers)
+{
+	struct tee_ioctl_version_data v = {
+		.impl_id = TEE_IMPL_ID_OPTEE,
+		.impl_caps = TEE_OPTEE_CAP_TZ,
+		.gen_caps = TEE_GEN_CAP_GP,
+	};
+	*vers = v;
+}
+
+static int optee_open(struct tee_context *ctx)
+{
+	struct optee_context_data *ctxdata;
+
+	ctxdata = kzalloc(sizeof(*ctxdata), GFP_KERNEL);
+	if (!ctxdata)
+		return -ENOMEM;
+
+	mutex_init(&ctxdata->mutex);
+	INIT_LIST_HEAD(&ctxdata->sess_list);
+
+	ctx->data = ctxdata;
+	return 0;
+}
+
+static void optee_release(struct tee_context *ctx)
+{
+	struct optee_context_data *ctxdata = ctx->data;
+	struct tee_shm *shm;
+	struct optee_msg_arg *arg = NULL;
+	phys_addr_t parg;
+
+	if (!ctxdata)
+		return;
+
+	shm = tee_shm_alloc(ctx->teedev, sizeof(struct optee_msg_arg),
+			    TEE_SHM_MAPPED);
+	if (!IS_ERR(shm)) {
+		arg = tee_shm_get_va(shm, 0);
+		/*
+		 * If va2pa fails for some reason, we can't call
+		 * optee_close_session(), only free the memory. Secure OS
+		 * will leak sessions and finally refuse more session, but
+		 * we will at least let normal world reclaim its memory.
+		 */
+		if (!IS_ERR(arg))
+			tee_shm_va2pa(shm, arg, &parg);
+	}
+
+	while (true) {
+		struct optee_session *sess;
+
+		sess = list_first_entry_or_null(&ctxdata->sess_list,
+						struct optee_session,
+						list_node);
+		if (!sess)
+			break;
+		list_del(&sess->list_node);
+		if (!IS_ERR_OR_NULL(arg)) {
+			memset(arg, 0, sizeof(*arg));
+			arg->cmd = OPTEE_MSG_CMD_CLOSE_SESSION;
+			arg->session = sess->session_id;
+			optee_do_call_with_arg(ctx, parg);
+		}
+		kfree(sess);
+	}
+	kfree(ctxdata);
+
+	if (!IS_ERR(shm))
+		tee_shm_free(shm);
+
+	ctx->data = NULL;
+}
+
+static struct tee_driver_ops optee_ops = {
+	.get_version = optee_get_version,
+	.open = optee_open,
+	.release = optee_release,
+	.open_session = optee_open_session,
+	.close_session = optee_close_session,
+	.invoke_func = optee_invoke_func,
+	.cancel_req = optee_cancel_req,
+};
+
+static struct tee_desc optee_desc = {
+	.name = DRIVER_NAME "-clnt",
+	.ops = &optee_ops,
+	.owner = THIS_MODULE,
+};
+
+static struct tee_driver_ops optee_supp_ops = {
+	.get_version = optee_get_version,
+	.open = optee_open,
+	.release = optee_release,
+	.supp_recv = optee_supp_recv,
+	.supp_send = optee_supp_send,
+};
+
+static struct tee_desc optee_supp_desc = {
+	.name = DRIVER_NAME "-supp",
+	.ops = &optee_supp_ops,
+	.owner = THIS_MODULE,
+	.flags = TEE_DESC_PRIVILEGED,
+};
+
+static bool optee_msg_api_uid_is_optee_api(optee_invoke_fn *invoke_fn)
+{
+	struct arm_smccc_res res;
+
+	invoke_fn(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, 0, &res);
+
+	if (res.a0 == OPTEE_MSG_UID_0 && res.a1 == OPTEE_MSG_UID_1 &&
+	    res.a2 == OPTEE_MSG_UID_2 && res.a3 == OPTEE_MSG_UID_3)
+		return true;
+	return false;
+}
+
+static bool optee_msg_api_revision_is_compatible(optee_invoke_fn *invoke_fn)
+{
+	struct arm_smccc_res res;
+
+	invoke_fn(OPTEE_SMC_CALLS_REVISION, 0, 0, 0, 0, 0, 0, 0, &res);
+
+	if (res.a0 == OPTEE_MSG_REVISION_MAJOR &&
+	    (int)res.a1 >= OPTEE_MSG_REVISION_MINOR)
+		return true;
+	return false;
+}
+
+static bool optee_msg_exchange_capabilities(optee_invoke_fn *invoke_fn,
+			u32 *sec_caps)
+{
+	struct arm_smccc_res res;
+	u32 a1 = 0;
+
+	/*
+	 * TODO This isn't enough to tell if it's UP system (from kernel
+	 * point of view) or not, is_smp() returns the the information
+	 * needed, but can't be called directly from here.
+	 */
+#ifndef CONFIG_SMP
+	a1 |= OPTEE_SMC_NSEC_CAP_UNIPROCESSOR;
+#endif
+
+	invoke_fn(OPTEE_SMC_EXCHANGE_CAPABILITIES, a1, 0, 0, 0, 0, 0, 0, &res);
+
+	if (res.a0 != OPTEE_SMC_RETURN_OK)
+		return false;
+
+	*sec_caps = res.a1;
+	return true;
+}
+
+static struct tee_shm_pool *optee_config_shm_ioremap(struct device *dev,
+			optee_invoke_fn *invoke_fn,
+			void __iomem **ioremaped_shm)
+{
+	struct arm_smccc_res res;
+	struct tee_shm_pool *pool;
+	unsigned long vaddr;
+	phys_addr_t paddr;
+	size_t size;
+	phys_addr_t begin;
+	phys_addr_t end;
+	void __iomem *va;
+	struct tee_shm_pool_mem_info priv_info;
+	struct tee_shm_pool_mem_info dmabuf_info;
+
+	invoke_fn(OPTEE_SMC_GET_SHM_CONFIG, 0, 0, 0, 0, 0, 0, 0, &res);
+	if (res.a0 != OPTEE_SMC_RETURN_OK) {
+		dev_info(dev, "shm service not available\n");
+		return ERR_PTR(-ENOENT);
+	}
+
+	if (res.a3 != OPTEE_SMC_SHM_CACHED) {
+		dev_err(dev, "only normal cached shared memory supported\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	begin = roundup(res.a1, PAGE_SIZE);
+	end = rounddown(res.a1 + res.a2, PAGE_SIZE);
+	paddr = begin;
+	size = end - begin;
+
+	if (size < 2 * OPTEE_SHM_NUM_PRIV_PAGES * PAGE_SIZE) {
+		dev_err(dev, "too small shared memory area\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	va = ioremap_cache(paddr, size);
+	if (!va) {
+		dev_err(dev, "shared memory ioremap failed\n");
+		return ERR_PTR(-EINVAL);
+	}
+	vaddr = (unsigned long)va;
+
+	priv_info.vaddr = vaddr;
+	priv_info.paddr = paddr;
+	priv_info.size = OPTEE_SHM_NUM_PRIV_PAGES * PAGE_SIZE;
+	dmabuf_info.vaddr = vaddr + OPTEE_SHM_NUM_PRIV_PAGES * PAGE_SIZE;
+	dmabuf_info.paddr = paddr + OPTEE_SHM_NUM_PRIV_PAGES * PAGE_SIZE;
+	dmabuf_info.size = size - OPTEE_SHM_NUM_PRIV_PAGES * PAGE_SIZE;
+
+	pool = tee_shm_pool_alloc_res_mem(dev, &priv_info, &dmabuf_info);
+	if (IS_ERR(pool))
+		iounmap(va);
+	else
+		*ioremaped_shm = va;
+	return pool;
+}
+
+static int get_invoke_func(struct device *dev, optee_invoke_fn **invoke_fn)
+{
+	struct device_node *np = dev->of_node;
+	const char *method;
+
+	dev_info(dev, "probing for conduit method from DT.\n");
+
+	if (of_property_read_string(np, "method", &method)) {
+		dev_warn(dev, "missing \"method\" property\n");
+		return -ENXIO;
+	}
+
+	if (!strcmp("hvc", method)) {
+		*invoke_fn = arm_smccc_hvc;
+	} else if (!strcmp("smc", method)) {
+		*invoke_fn = arm_smccc_smc;
+	} else {
+		dev_warn(dev, "invalid \"method\" property: %s\n", method);
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static int optee_probe(struct platform_device *pdev)
+{
+	optee_invoke_fn *invoke_fn;
+	struct tee_shm_pool *pool;
+	struct optee *optee = NULL;
+	void __iomem *ioremaped_shm = NULL;
+	struct tee_device *teedev;
+	u32 sec_caps;
+	int rc;
+
+	rc = get_invoke_func(&pdev->dev, &invoke_fn);
+	if (rc)
+		return rc;
+
+	if (!optee_msg_api_uid_is_optee_api(invoke_fn) ||
+	    !optee_msg_api_revision_is_compatible(invoke_fn) ||
+	    !optee_msg_exchange_capabilities(invoke_fn, &sec_caps))
+		return -EINVAL;
+
+	/*
+	 * We have no other option for shared memory, if secure world
+	 * doesn't have any reserved memory we can use we can't continue.
+	 */
+	if (!(sec_caps & OPTEE_SMC_SEC_CAP_HAVE_RESERVERED_SHM))
+		return -EINVAL;
+
+	pool = optee_config_shm_ioremap(&pdev->dev, invoke_fn, &ioremaped_shm);
+	if (IS_ERR(pool))
+		return PTR_ERR(pool);
+
+	optee = devm_kzalloc(&pdev->dev, sizeof(*optee), GFP_KERNEL);
+	if (!optee) {
+		rc = -ENOMEM;
+		goto err;
+	}
+
+	optee->dev = &pdev->dev;
+	optee->invoke_fn = invoke_fn;
+
+	teedev = tee_device_alloc(&optee_desc, &pdev->dev, pool, optee);
+	if (IS_ERR(teedev)) {
+		rc = PTR_ERR(teedev);
+		goto err;
+	}
+	optee->teedev = teedev;
+
+	teedev = tee_device_alloc(&optee_supp_desc, &pdev->dev, pool, optee);
+	if (IS_ERR(teedev)) {
+		rc = PTR_ERR(teedev);
+		goto err;
+	}
+	optee->supp_teedev = teedev;
+
+	rc = tee_device_register(optee->teedev);
+	if (rc)
+		goto err;
+
+	rc = tee_device_register(optee->supp_teedev);
+	if (rc)
+		goto err;
+
+	mutex_init(&optee->call_queue.mutex);
+	INIT_LIST_HEAD(&optee->call_queue.waiters);
+	optee_wait_queue_init(&optee->wait_queue);
+	optee_supp_init(&optee->supp);
+	optee->ioremaped_shm = ioremaped_shm;
+	optee->pool = pool;
+
+	platform_set_drvdata(pdev, optee);
+
+	optee_enable_shm_cache(optee);
+
+	dev_info(&pdev->dev, "initialized driver\n");
+	return 0;
+err:
+	tee_device_unregister(optee->teedev);
+	tee_device_unregister(optee->supp_teedev);
+	if (pool)
+		tee_shm_pool_free(pool);
+	if (ioremaped_shm)
+		iounmap(optee->ioremaped_shm);
+	return rc;
+}
+
+static int optee_remove(struct platform_device *pdev)
+{
+	struct optee *optee = platform_get_drvdata(pdev);
+
+	optee_disable_shm_cache(optee);
+
+	tee_device_unregister(optee->teedev);
+	tee_device_unregister(optee->supp_teedev);
+	tee_shm_pool_free(optee->pool);
+	if (optee->ioremaped_shm)
+		iounmap(optee->ioremaped_shm);
+	optee_wait_queue_exit(&optee->wait_queue);
+	optee_supp_uninit(&optee->supp);
+	mutex_destroy(&optee->call_queue.mutex);
+	return 0;
+}
+
+static const struct of_device_id optee_match[] = {
+	{ .compatible = "linaro,optee-tz" },
+	{},
+};
+
+static struct platform_driver optee_driver = {
+	.driver = {
+		.name = DRIVER_NAME,
+		.of_match_table = optee_match,
+	},
+	.probe = optee_probe,
+	.remove = optee_remove,
+};
+
+static int __init optee_driver_init(void)
+{
+	struct device_node *node;
+
+	/*
+	 * Preferred path is /firmware/optee, but it's the matching that
+	 * matters.
+	 */
+	for_each_matching_node(node, optee_match)
+		of_platform_device_create(node, NULL, NULL);
+
+	return platform_driver_register(&optee_driver);
+}
+module_init(optee_driver_init);
+
+static void __exit optee_driver_exit(void)
+{
+	platform_driver_unregister(&optee_driver);
+}
+module_exit(optee_driver_exit);
+
+MODULE_AUTHOR("Linaro");
+MODULE_DESCRIPTION("OP-TEE driver");
+MODULE_SUPPORTED_DEVICE("");
+MODULE_VERSION("1.0");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h
new file mode 100644
index 0000000..58db178
--- /dev/null
+++ b/drivers/tee/optee/optee_msg.h
@@ -0,0 +1,423 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice,
+ * this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
+ * and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+#ifndef _OPTEE_MSG_H
+#define _OPTEE_MSG_H
+
+#include <linux/types.h>
+
+/*
+ * This file defines the OP-TEE message protocol used to communicate
+ * with an instance of OP-TEE running in secure world.
+ *
+ * This file is divided into three sections.
+ * 1. Formatting of messages.
+ * 2. Requests from normal world
+ * 3. Requests from secure world, Remote Procedure Call (RPC), handled by
+ *    tee-supplicant.
+ */
+
+/*****************************************************************************
+ * Part 1 - formatting of messages
+ *****************************************************************************/
+
+#define OPTEE_MSG_ATTR_TYPE_NONE		0x0
+#define OPTEE_MSG_ATTR_TYPE_VALUE_INPUT		0x1
+#define OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT	0x2
+#define OPTEE_MSG_ATTR_TYPE_VALUE_INOUT		0x3
+#define OPTEE_MSG_ATTR_TYPE_RMEM_INPUT		0x5
+#define OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT		0x6
+#define OPTEE_MSG_ATTR_TYPE_RMEM_INOUT		0x7
+#define OPTEE_MSG_ATTR_TYPE_TMEM_INPUT		0x9
+#define OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT		0xa
+#define OPTEE_MSG_ATTR_TYPE_TMEM_INOUT		0xb
+
+#define OPTEE_MSG_ATTR_TYPE_MASK		0xff
+
+/*
+ * Meta parameter to be absorbed by the Secure OS and not passed
+ * to the Trusted Application.
+ *
+ * Currently only used with OPTEE_MSG_CMD_OPEN_SESSION.
+ */
+#define OPTEE_MSG_ATTR_META			(1 << 8)
+
+/*
+ * The temporary shared memory object is not physically contigous and this
+ * temp memref is followed by another fragment until the last temp memref
+ * that doesn't have this bit set.
+ */
+#define OPTEE_MSG_ATTR_FRAGMENT			(1 << 9)
+
+/*
+ * Memory attributes for caching passed with temp memrefs. The actual value
+ * used is defined outside the message protocol with the exception of
+ * OPTEE_MSG_ATTR_CACHE_PREDEFINED which means the attributes already
+ * defined for the memory range should be used. If optee_smc.h is used as
+ * bearer of this protocol OPTEE_SMC_SHM_* is used for values.
+ */
+#define OPTEE_MSG_ATTR_CACHE_SHIFT		16
+#define OPTEE_MSG_ATTR_CACHE_MASK		0x7
+#define OPTEE_MSG_ATTR_CACHE_PREDEFINED		0
+
+/*
+ * Same values as TEE_LOGIN_* from TEE Internal API
+ */
+#define OPTEE_MSG_LOGIN_PUBLIC			0x00000000
+#define OPTEE_MSG_LOGIN_USER			0x00000001
+#define OPTEE_MSG_LOGIN_GROUP			0x00000002
+#define OPTEE_MSG_LOGIN_APPLICATION		0x00000004
+#define OPTEE_MSG_LOGIN_APPLICATION_USER	0x00000005
+#define OPTEE_MSG_LOGIN_APPLICATION_GROUP	0x00000006
+
+/**
+ * struct optee_msg_param_tmem - temporary memory reference
+ * @buf_ptr:	Address of the buffer
+ * @size:	Size of the buffer
+ * @shm_ref:	Temporary shared memory reference, pointer to a struct tee_shm
+ *
+ * Secure and normal world communicates pointers as physical address
+ * instead of the virtual address. This is because secure and normal world
+ * have completely independent memory mapping. Normal world can even have a
+ * hypervisor which need to translate the guest physical address (AKA IPA
+ * in ARM documentation) to a real physical address before passing the
+ * structure to secure world.
+ */
+struct optee_msg_param_tmem {
+	u64 buf_ptr;
+	u64 size;
+	u64 shm_ref;
+};
+
+/**
+ * struct optee_msg_param_rmem - registered memory reference
+ * @offs:	Offset into shared memory reference
+ * @size:	Size of the buffer
+ * @shm_ref:	Shared memory reference, pointer to a struct tee_shm
+ */
+struct optee_msg_param_rmem {
+	u64 offs;
+	u64 size;
+	u64 shm_ref;
+};
+
+/**
+ * struct optee_msg_param_value - values
+ * @a: first value
+ * @b: second value
+ * @c: third value
+ */
+struct optee_msg_param_value {
+	u64 a;
+	u64 b;
+	u64 c;
+};
+
+/**
+ * struct optee_msg_param - parameter
+ * @attr: attributes
+ * @memref: a memory reference
+ * @value: a value
+ *
+ * @attr & OPTEE_MSG_ATTR_TYPE_MASK indicates if tmem, rmem or value is used in
+ * the union. OPTEE_MSG_ATTR_TYPE_VALUE_* indicates value,
+ * OPTEE_MSG_ATTR_TYPE_TMEM_* indicates tmem and
+ * OPTEE_MSG_ATTR_TYPE_RMEM_* indicates rmem.
+ * OPTEE_MSG_ATTR_TYPE_NONE indicates that none of the members are used.
+ */
+struct optee_msg_param {
+	u64 attr;
+	union {
+		struct optee_msg_param_tmem tmem;
+		struct optee_msg_param_rmem rmem;
+		struct optee_msg_param_value value;
+	} u;
+};
+
+/**
+ * struct optee_msg_arg - call argument
+ * @cmd: Command, one of OPTEE_MSG_CMD_* or OPTEE_MSG_RPC_CMD_*
+ * @func: Trusted Application function, specific to the Trusted Application,
+ *	     used if cmd == OPTEE_MSG_CMD_INVOKE_COMMAND
+ * @session: In parameter for all OPTEE_MSG_CMD_* except
+ *	     OPTEE_MSG_CMD_OPEN_SESSION where it's an output parameter instead
+ * @cancel_id: Cancellation id, a unique value to identify this request
+ * @ret: return value
+ * @ret_origin: origin of the return value
+ * @num_params: number of parameters supplied to the OS Command
+ * @params: the parameters supplied to the OS Command
+ *
+ * All normal calls to Trusted OS uses this struct. If cmd requires further
+ * information than what these field holds it can be passed as a parameter
+ * tagged as meta (setting the OPTEE_MSG_ATTR_META bit in corresponding
+ * attrs field). All parameters tagged as meta has to come first.
+ *
+ * Temp memref parameters can be fragmented if supported by the Trusted OS
+ * (when optee_smc.h is bearer of this protocol this is indicated with
+ * OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM). If a logical memref parameter is
+ * fragmented then has all but the last fragment the
+ * OPTEE_MSG_ATTR_FRAGMENT bit set in attrs. Even if a memref is fragmented
+ * it will still be presented as a single logical memref to the Trusted
+ * Application.
+ */
+struct optee_msg_arg {
+	u32 cmd;
+	u32 func;
+	u32 session;
+	u32 cancel_id;
+	u32 pad;
+	u32 ret;
+	u32 ret_origin;
+	u32 num_params;
+
+	/*
+	 * this struct is 8 byte aligned since the 'struct optee_msg_param'
+	 * which follows requires 8 byte alignment.
+	 *
+	 * Commented out element used to visualize the layout dynamic part
+	 * of the struct. This field is not available at all if
+	 * num_params == 0.
+	 *
+	 * params is accessed through the macro OPTEE_MSG_GET_PARAMS
+	 *
+	 * struct optee_msg_param params[num_params];
+	 */
+} __aligned(8);
+
+/**
+ * OPTEE_MSG_GET_PARAMS - return pointer to struct optee_msg_param *
+ *
+ * @x: Pointer to a struct optee_msg_arg
+ *
+ * Returns a pointer to the params[] inside a struct optee_msg_arg.
+ */
+#define OPTEE_MSG_GET_PARAMS(x) \
+	(struct optee_msg_param *)(((struct optee_msg_arg *)(x)) + 1)
+
+/**
+ * OPTEE_MSG_GET_ARG_SIZE - return size of struct optee_msg_arg
+ *
+ * @num_params: Number of parameters embedded in the struct optee_msg_arg
+ *
+ * Returns the size of the struct optee_msg_arg together with the number
+ * of embedded parameters.
+ */
+#define OPTEE_MSG_GET_ARG_SIZE(num_params) \
+	(sizeof(struct optee_msg_arg) + \
+	 sizeof(struct optee_msg_param) * (num_params))
+
+/*****************************************************************************
+ * Part 2 - requests from normal world
+ *****************************************************************************/
+
+/*
+ * Return the following UID if using API specified in this file without
+ * further extentions:
+ * 384fb3e0-e7f8-11e3-af63-0002a5d5c51b.
+ * Represented in 4 32-bit words in OPTEE_MSG_UID_0, OPTEE_MSG_UID_1,
+ * OPTEE_MSG_UID_2, OPTEE_MSG_UID_3.
+ */
+#define OPTEE_MSG_UID_0			0x384fb3e0
+#define OPTEE_MSG_UID_1			0xe7f811e3
+#define OPTEE_MSG_UID_2			0xaf630002
+#define OPTEE_MSG_UID_3			0xa5d5c51b
+#define OPTEE_MSG_FUNCID_CALLS_UID	0xFF01
+
+/*
+ * Returns 2.0 if using API specified in this file without further
+ * extentions. Represented in 2 32-bit words in OPTEE_MSG_REVISION_MAJOR
+ * and OPTEE_MSG_REVISION_MINOR
+ */
+#define OPTEE_MSG_REVISION_MAJOR	2
+#define OPTEE_MSG_REVISION_MINOR	0
+#define OPTEE_MSG_FUNCID_CALLS_REVISION	0xFF03
+
+/*
+ * Get UUID of Trusted OS.
+ *
+ * Used by non-secure world to figure out which Trusted OS is installed.
+ * Note that returned UUID is the UUID of the Trusted OS, not of the API.
+ *
+ * Returns UUID in 4 32-bit words in the same way as
+ * OPTEE_MSG_FUNCID_CALLS_UID described above.
+ */
+#define OPTEE_MSG_OS_OPTEE_UUID_0	0x486178e0
+#define OPTEE_MSG_OS_OPTEE_UUID_1	0xe7f811e3
+#define OPTEE_MSG_OS_OPTEE_UUID_2	0xbc5e0002
+#define OPTEE_MSG_OS_OPTEE_UUID_3	0xa5d5c51b
+#define OPTEE_MSG_FUNCID_GET_OS_UUID	0x0000
+
+/*
+ * Get revision of Trusted OS.
+ *
+ * Used by non-secure world to figure out which version of the Trusted OS
+ * is installed. Note that the returned revision is the revision of the
+ * Trusted OS, not of the API.
+ *
+ * Returns revision in 2 32-bit words in the same way as
+ * OPTEE_MSG_CALLS_REVISION described above.
+ */
+#define OPTEE_MSG_OS_OPTEE_REVISION_MAJOR	1
+#define OPTEE_MSG_OS_OPTEE_REVISION_MINOR	0
+#define OPTEE_MSG_FUNCID_GET_OS_REVISION	0x0001
+
+/*
+ * Do a secure call with struct optee_msg_arg as argument
+ * The OPTEE_MSG_CMD_* below defines what goes in struct optee_msg_arg::cmd
+ *
+ * OPTEE_MSG_CMD_OPEN_SESSION opens a session to a Trusted Application.
+ * The first two parameters are tagged as meta, holding two value
+ * parameters to pass the following information:
+ * param[0].u.value.a-b uuid of Trusted Application
+ * param[1].u.value.a-b uuid of Client
+ * param[1].u.value.c Login class of client OPTEE_MSG_LOGIN_*
+ *
+ * OPTEE_MSG_CMD_INVOKE_COMMAND invokes a command a previously opened
+ * session to a Trusted Application.  struct optee_msg_arg::func is Trusted
+ * Application function, specific to the Trusted Application.
+ *
+ * OPTEE_MSG_CMD_CLOSE_SESSION closes a previously opened session to
+ * Trusted Application.
+ *
+ * OPTEE_MSG_CMD_CANCEL cancels a currently invoked command.
+ *
+ * OPTEE_MSG_CMD_REGISTER_SHM registers a shared memory reference. The
+ * information is passed as:
+ * [in] param[0].attr			OPTEE_MSG_ATTR_TYPE_TMEM_INPUT
+ *					[| OPTEE_MSG_ATTR_FRAGMENT]
+ * [in] param[0].u.tmem.buf_ptr		physical address (of first fragment)
+ * [in] param[0].u.tmem.size		size (of first fragment)
+ * [in] param[0].u.tmem.shm_ref		holds shared memory reference
+ * ...
+ * The shared memory can optionally be fragmented, temp memrefs can follow
+ * each other with all but the last with the OPTEE_MSG_ATTR_FRAGMENT bit set.
+ *
+ * OPTEE_MSG_CMD_UNREGISTER_SHM unregisteres a previously registered shared
+ * memory reference. The information is passed as:
+ * [in] param[0].attr			OPTEE_MSG_ATTR_TYPE_RMEM_INPUT
+ * [in] param[0].u.rmem.shm_ref		holds shared memory reference
+ * [in] param[0].u.rmem.offs		0
+ * [in] param[0].u.rmem.size		0
+ */
+#define OPTEE_MSG_CMD_OPEN_SESSION	0
+#define OPTEE_MSG_CMD_INVOKE_COMMAND	1
+#define OPTEE_MSG_CMD_CLOSE_SESSION	2
+#define OPTEE_MSG_CMD_CANCEL		3
+#define OPTEE_MSG_CMD_REGISTER_SHM	4
+#define OPTEE_MSG_CMD_UNREGISTER_SHM	5
+#define OPTEE_MSG_FUNCID_CALL_WITH_ARG	0x0004
+
+/*****************************************************************************
+ * Part 3 - Requests from secure world, RPC
+ *****************************************************************************/
+
+/*
+ * All RPC is done with a struct optee_msg_arg as bearer of information,
+ * struct optee_msg_arg::arg holds values defined by OPTEE_MSG_RPC_CMD_* below
+ *
+ * RPC communication with tee-supplicant is reversed compared to normal
+ * client communication desribed above. The supplicant receives requests
+ * and sends responses.
+ */
+
+/*
+ * Load a TA into memory, defined in tee-supplicant
+ */
+#define OPTEE_MSG_RPC_CMD_LOAD_TA	0
+
+/*
+ * Reserved
+ */
+#define OPTEE_MSG_RPC_CMD_RPMB		1
+
+/*
+ * File system access, defined in tee-supplicant
+ */
+#define OPTEE_MSG_RPC_CMD_FS		2
+
+/*
+ * Get time
+ *
+ * Returns number of seconds and nano seconds since the Epoch,
+ * 1970-01-01 00:00:00 +0000 (UTC).
+ *
+ * [out] param[0].u.value.a	Number of seconds
+ * [out] param[0].u.value.b	Number of nano seconds.
+ */
+#define OPTEE_MSG_RPC_CMD_GET_TIME	3
+
+/*
+ * Wait queue primitive, helper for secure world to implement a wait queue
+ *
+ * Waiting on a key
+ * [in] param[0].u.value.a OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP
+ * [in] param[0].u.value.b wait key
+ *
+ * Waking up a key
+ * [in] param[0].u.value.a OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP
+ * [in] param[0].u.value.b wakeup key
+ */
+#define OPTEE_MSG_RPC_CMD_WAIT_QUEUE	4
+#define OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP	0
+#define OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP	1
+
+/*
+ * Suspend execution
+ *
+ * [in] param[0].value	.a number of milliseconds to suspend
+ */
+#define OPTEE_MSG_RPC_CMD_SUSPEND	5
+
+/*
+ * Allocate a piece of shared memory
+ *
+ * Shared memory can optionally be fragmented, to support that additional
+ * spare param entries are allocated to make room for eventual fragments.
+ * The spare param entries has .attr = OPTEE_MSG_ATTR_TYPE_NONE when
+ * unused. All returned temp memrefs except the last should have the
+ * OPTEE_MSG_ATTR_FRAGMENT bit set in the attr field.
+ *
+ * [in]  param[0].u.value.a		type of memory one of
+ *					OPTEE_MSG_RPC_SHM_TYPE_* below
+ * [in]  param[0].u.value.b		requested size
+ * [in]  param[0].u.value.c		required alignment
+ *
+ * [out] param[0].u.tmem.buf_ptr	physical address (of first fragment)
+ * [out] param[0].u.tmem.size		size (of first fragment)
+ * [out] param[0].u.tmem.shm_ref	shared memory reference
+ * ...
+ * [out] param[n].u.tmem.buf_ptr	physical address
+ * [out] param[n].u.tmem.size		size
+ * [out] param[n].u.tmem.shm_ref	shared memory reference (same value
+ *					as in param[n-1].u.tmem.shm_ref)
+ */
+#define OPTEE_MSG_RPC_CMD_SHM_ALLOC	6
+/* Memory that can be shared with a non-secure user space application */
+#define OPTEE_MSG_RPC_SHM_TYPE_APPL	0
+/* Memory only shared with non-secure kernel */
+#define OPTEE_MSG_RPC_SHM_TYPE_KERNEL	1
+
+#endif /* _OPTEE_MSG_H */
diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h
new file mode 100644
index 0000000..7f13cb5
--- /dev/null
+++ b/drivers/tee/optee/optee_private.h
@@ -0,0 +1,146 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef OPTEE_PRIVATE_H
+#define OPTEE_PRIVATE_H
+
+#include <linux/types.h>
+#include <linux/semaphore.h>
+#include <linux/tee_drv.h>
+#include "optee_msg.h"
+#include <linux/arm-smccc.h>
+
+#define OPTEE_MAX_ARG_SIZE	1024
+
+/* Some Global Platform error codes used in this driver */
+#define TEEC_SUCCESS			0x00000000
+#define TEEC_ERROR_BAD_PARAMETERS	0xFFFF0006
+#define TEEC_ERROR_COMMUNICATION	0xFFFF000E
+#define TEEC_ERROR_OUT_OF_MEMORY	0xFFFF000C
+
+#define TEEC_ORIGIN_COMMS		0x00000002
+
+typedef void (optee_invoke_fn)(unsigned long, unsigned long, unsigned long,
+				unsigned long, unsigned long, unsigned long,
+				unsigned long, unsigned long,
+				struct arm_smccc_res *);
+
+struct optee_call_queue {
+	struct mutex mutex;
+	struct list_head waiters;
+};
+
+struct optee_wait_queue {
+	struct mutex mu;
+	struct list_head db;
+};
+
+struct optee_supp {
+	u32 func;
+	u32 ret;
+	size_t num_params;
+	struct tee_param *param;
+
+	bool req_posted;
+	bool supp_next_send;
+	struct mutex thrd_mutex;
+	struct mutex supp_mutex;
+	struct completion data_to_supp;
+	struct completion data_from_supp;
+};
+
+struct optee {
+	struct tee_device *supp_teedev;
+	struct tee_device *teedev;
+	struct device *dev;
+	optee_invoke_fn *invoke_fn;
+	struct optee_call_queue call_queue;
+	struct optee_wait_queue wait_queue;
+	struct optee_supp supp;
+	struct tee_shm_pool *pool;
+	void __iomem *ioremaped_shm;
+};
+
+struct optee_session {
+	struct list_head list_node;
+	u32 session_id;
+};
+
+struct optee_context_data {
+	struct mutex mutex;
+	struct list_head sess_list;
+};
+
+struct optee_rpc_param {
+	u32	a0;
+	u32	a1;
+	u32	a2;
+	u32	a3;
+	u32	a4;
+	u32	a5;
+	u32	a6;
+	u32	a7;
+};
+
+void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param);
+
+void optee_wait_queue_init(struct optee_wait_queue *wq);
+void optee_wait_queue_exit(struct optee_wait_queue *wq);
+
+u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params,
+			struct tee_param *param);
+
+int optee_supp_read(struct tee_context *ctx, void __user *buf, size_t len);
+int optee_supp_write(struct tee_context *ctx, void __user *buf, size_t len);
+void optee_supp_init(struct optee_supp *supp);
+void optee_supp_uninit(struct optee_supp *supp);
+
+int optee_supp_recv(struct tee_context *ctx, u32 *func, u32 *num_params,
+			struct tee_param *param);
+int optee_supp_send(struct tee_context *ctx, u32 ret, u32 num_params,
+			struct tee_param *param);
+
+u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg);
+int optee_open_session(struct tee_context *ctx,
+			struct tee_ioctl_open_session_arg *arg,
+			struct tee_param *param);
+int optee_close_session(struct tee_context *ctx, u32 session);
+int optee_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg,
+			struct tee_param *param);
+int optee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session);
+
+void optee_enable_shm_cache(struct optee *optee);
+void optee_disable_shm_cache(struct optee *optee);
+
+int optee_from_msg_param(struct tee_param *params, size_t num_params,
+			const struct optee_msg_param *msg_params);
+int optee_to_msg_param(struct optee_msg_param *msg_params, size_t num_params,
+			const struct tee_param *params);
+
+/*
+ * Small helpers
+ */
+
+static inline void *reg_pair_to_ptr(u32 reg0, u32 reg1)
+{
+	return (void *)(unsigned long)(((u64)reg0 << 32) | reg1);
+}
+
+static inline void reg_pair_from_64(u32 *reg0, u32 *reg1, u64 val)
+{
+	*reg0 = val >> 32;
+	*reg1 = val;
+}
+
+#endif /*OPTEE_PRIVATE_H*/
diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h
new file mode 100644
index 0000000..4aa20b9
--- /dev/null
+++ b/drivers/tee/optee/optee_smc.h
@@ -0,0 +1,418 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice,
+ * this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
+ * and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+#ifndef OPTEE_SMC_H
+#define OPTEE_SMC_H
+
+#include <linux/arm-smccc.h>
+
+#define OPTEE_SMC_STD_CALL_VAL(func_num) \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_STD_CALL, ARM_SMCCC_SMC_32, \
+			   ARM_SMCCC_OWNER_TRUSTED_OS, (func_num))
+#define OPTEE_SMC_FAST_CALL_VAL(func_num) \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \
+			   ARM_SMCCC_OWNER_TRUSTED_OS, (func_num))
+
+/*
+ * Function specified by SMC Calling convention.
+ */
+#define OPTEE_SMC_FUNCID_CALLS_COUNT	0xFF00
+#define OPTEE_SMC_CALLS_COUNT \
+	ARM_SMCCC_CALL_VAL(OPTEE_SMC_FAST_CALL, SMCCC_SMC_32, \
+			   SMCCC_OWNER_TRUSTED_OS_END, \
+			   OPTEE_SMC_FUNCID_CALLS_COUNT)
+
+/*
+ * Normal cached memory (write-back), shareable for SMP systems and not
+ * shareable for UP systems.
+ */
+#define OPTEE_SMC_SHM_CACHED		1
+
+/*
+ * a0..a7 is used as register names in the descriptions below, on arm32
+ * that translates to r0..r7 and on arm64 to w0..w7. In both cases it's
+ * 32-bit registers.
+ */
+
+/*
+ * Function specified by SMC Calling convention
+ *
+ * Return one of the following UIDs if using API specified in this file
+ * without further extentions:
+ * 65cb6b93-af0c-4617-8ed6-644a8d1140f8
+ * see also OPTEE_SMC_UID_* in optee_msg.h
+ */
+#define OPTEE_SMC_FUNCID_CALLS_UID OPTEE_MSG_FUNCID_CALLS_UID
+#define OPTEE_SMC_CALLS_UID \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \
+			   ARM_SMCCC_OWNER_TRUSTED_OS_END, \
+			   OPTEE_SMC_FUNCID_CALLS_UID)
+
+/*
+ * Function specified by SMC Calling convention
+ *
+ * Returns 2.0 if using API specified in this file without further extentions.
+ * see also OPTEE_MSG_REVISION_* in optee_msg.h
+ */
+#define OPTEE_SMC_FUNCID_CALLS_REVISION OPTEE_MSG_FUNCID_CALLS_REVISION
+#define OPTEE_SMC_CALLS_REVISION \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \
+			   ARM_SMCCC_OWNER_TRUSTED_OS_END, \
+			   OPTEE_SMC_FUNCID_CALLS_REVISION)
+
+/*
+ * Get UUID of Trusted OS.
+ *
+ * Used by non-secure world to figure out which Trusted OS is installed.
+ * Note that returned UUID is the UUID of the Trusted OS, not of the API.
+ *
+ * Returns UUID in a0-4 in the same way as OPTEE_SMC_CALLS_UID
+ * described above.
+ */
+#define OPTEE_SMC_FUNCID_GET_OS_UUID OPTEE_MSG_FUNCID_GET_OS_UUID
+#define OPTEE_SMC_CALL_GET_OS_UUID \
+	OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_GET_OS_UUID)
+
+/*
+ * Get revision of Trusted OS.
+ *
+ * Used by non-secure world to figure out which version of the Trusted OS
+ * is installed. Note that the returned revision is the revision of the
+ * Trusted OS, not of the API.
+ *
+ * Returns revision in a0-1 in the same way as OPTEE_SMC_CALLS_REVISION
+ * described above.
+ */
+#define OPTEE_SMC_FUNCID_GET_OS_REVISION OPTEE_MSG_FUNCID_GET_OS_REVISION
+#define OPTEE_SMC_CALL_GET_OS_REVISION \
+	OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_GET_OS_REVISION)
+
+/*
+ * Call with struct optee_msg_arg as argument
+ *
+ * Call register usage:
+ * a0	SMC Function ID, OPTEE_SMC*CALL_WITH_ARG
+ * a1	Upper 32bit of a 64bit physical pointer to a struct optee_msg_arg
+ * a2	Lower 32bit of a 64bit physical pointer to a struct optee_msg_arg
+ * a3	Cache settings, not used if physical pointer is in a predefined shared
+ *	memory area else per OPTEE_SMC_SHM_*
+ * a4-6	Not used
+ * a7	Hypervisor Client ID register
+ *
+ * Normal return register usage:
+ * a0	Return value, OPTEE_SMC_RETURN_*
+ * a1-3	Not used
+ * a4-7	Preserved
+ *
+ * OPTEE_SMC_RETURN_ETHREAD_LIMIT return register usage:
+ * a0	Return value, OPTEE_SMC_RETURN_ETHREAD_LIMIT
+ * a1-3	Preserved
+ * a4-7	Preserved
+ *
+ * RPC return register usage:
+ * a0	Return value, OPTEE_SMC_RETURN_IS_RPC(val)
+ * a1-2	RPC parameters
+ * a3-7	Resume information, must be preserved
+ *
+ * Possible return values:
+ * OPTEE_SMC_RETURN_UNKNOWN_FUNCTION	Trusted OS does not recognize this
+ *					function.
+ * OPTEE_SMC_RETURN_OK			Call completed, result updated in
+ *					the previously supplied struct
+ *					optee_msg_arg.
+ * OPTEE_SMC_RETURN_ETHREAD_LIMIT	Number of Trusted OS threads exceeded,
+ *					try again later.
+ * OPTEE_SMC_RETURN_EBADADDR		Bad physcial pointer to struct
+ *					optee_msg_arg.
+ * OPTEE_SMC_RETURN_EBADCMD		Bad/unknown cmd in struct optee_msg_arg
+ * OPTEE_SMC_RETURN_IS_RPC()		Call suspended by RPC call to normal
+ *					world.
+ */
+#define OPTEE_SMC_FUNCID_CALL_WITH_ARG OPTEE_MSG_FUNCID_CALL_WITH_ARG
+#define OPTEE_SMC_CALL_WITH_ARG \
+	OPTEE_SMC_STD_CALL_VAL(OPTEE_SMC_FUNCID_CALL_WITH_ARG)
+
+/*
+ * Get Shared Memory Config
+ *
+ * Returns the Secure/Non-secure shared memory config.
+ *
+ * Call register usage:
+ * a0	SMC Function ID, OPTEE_SMC_GET_SHM_CONFIG
+ * a1-6	Not used
+ * a7	Hypervisor Client ID register
+ *
+ * Have config return register usage:
+ * a0	OPTEE_SMC_RETURN_OK
+ * a1	Physical address of start of SHM
+ * a2	Size of of SHM
+ * a3	Cache settings of memory, as defined by the
+ *	OPTEE_SMC_SHM_* values above
+ * a4-7	Preserved
+ *
+ * Not available register usage:
+ * a0	OPTEE_SMC_RETURN_ENOTAVAIL
+ * a1-3 Not used
+ * a4-7	Preserved
+ */
+#define OPTEE_SMC_FUNCID_GET_SHM_CONFIG	7
+#define OPTEE_SMC_GET_SHM_CONFIG \
+	OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_GET_SHM_CONFIG)
+
+/*
+ * Exchanges capabilities between normal world and secure world
+ *
+ * Call register usage:
+ * a0	SMC Function ID, OPTEE_SMC_EXCHANGE_CAPABILITIES
+ * a1	bitfield of normal world capabilities OPTEE_SMC_NSEC_CAP_*
+ * a2-6	Not used
+ * a7	Hypervisor Client ID register
+ *
+ * Normal return register usage:
+ * a0	OPTEE_SMC_RETURN_OK
+ * a1	bitfield of secure world capabilities OPTEE_SMC_SEC_CAP_*
+ * a2-7	Preserved
+ *
+ * Error return register usage:
+ * a0	OPTEE_SMC_RETURN_ENOTAVAIL, can't use the capabilities from normal world
+ * a1	bitfield of secure world capabilities OPTEE_SMC_SEC_CAP_*
+ * a2-7 Preserved
+ */
+/* Normal world works as a uniprocessor system */
+#define OPTEE_SMC_NSEC_CAP_UNIPROCESSOR		(1 << 0)
+/* Secure world has reserved shared memory for normal world to use */
+#define OPTEE_SMC_SEC_CAP_HAVE_RESERVERED_SHM	(1 << 0)
+/* Secure world can communicate via previously unregistered shared memory */
+#define OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM	(1 << 1)
+#define OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES	9
+#define OPTEE_SMC_EXCHANGE_CAPABILITIES \
+	OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES)
+
+/*
+ * Disable and empties cache of shared memory objects
+ *
+ * Secure world can cache frequently used shared memory objects, for
+ * example objects used as RPC arguments. When secure world is idle this
+ * function returns one shared memory reference to free. To disable the
+ * cache and free all cached objects this function has to be called until
+ * it returns OPTEE_SMC_RETURN_ENOTAVAIL.
+ *
+ * Call register usage:
+ * a0	SMC Function ID, OPTEE_SMC_DISABLE_SHM_CACHE
+ * a1-6	Not used
+ * a7	Hypervisor Client ID register
+ *
+ * Normal return register usage:
+ * a0	OPTEE_SMC_RETURN_OK
+ * a1	Upper 32bit of a 64bit Shared memory cookie
+ * a2	Lower 32bit of a 64bit Shared memory cookie
+ * a3-7	Preserved
+ *
+ * Cache empty return register usage:
+ * a0	OPTEE_SMC_RETURN_ENOTAVAIL
+ * a1-7	Preserved
+ *
+ * Not idle return register usage:
+ * a0	OPTEE_SMC_RETURN_EBUSY
+ * a1-7	Preserved
+ */
+#define OPTEE_SMC_FUNCID_DISABLE_SHM_CACHE	10
+#define OPTEE_SMC_DISABLE_SHM_CACHE \
+	OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_DISABLE_SHM_CACHE)
+
+
+/*
+ * Enable cache of shared memory objects
+ *
+ * Secure world can cache frequently used shared memory objects, for
+ * example objects used as RPC arguments. When secure world is idle this
+ * function returns OPTEE_SMC_RETURN_OK and the cache is enabled. If
+ * secure world isn't idle OPTEE_SMC_RETURN_EBUSY is returned.
+ *
+ * Call register usage:
+ * a0	SMC Function ID, OPTEE_SMC_ENABLE_SHM_CACHE
+ * a1-6	Not used
+ * a7	Hypervisor Client ID register
+ *
+ * Normal return register usage:
+ * a0	OPTEE_SMC_RETURN_OK
+ * a1-7	Preserved
+ *
+ * Not idle return register usage:
+ * a0	OPTEE_SMC_RETURN_EBUSY
+ * a1-7	Preserved
+ */
+#define OPTEE_SMC_FUNCID_ENABLE_SHM_CACHE	11
+#define OPTEE_SMC_ENABLE_SHM_CACHE \
+	OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_ENABLE_SHM_CACHE)
+
+/*
+ * Resume from RPC (for example after processing an IRQ)
+ *
+ * Call register usage:
+ * a0	SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC
+ * a1-3	Value of a1-3 when OPTEE_SMC_CALL_WITH_ARG returned
+ *	OPTEE_SMC_RETURN_RPC in a0
+ *
+ * Return register usage is the same as for OPTEE_SMC_*CALL_WITH_ARG above.
+ *
+ * Possible return values
+ * OPTEE_SMC_RETURN_UNKNOWN_FUNCTION	Trusted OS does not recognize this
+ *					function.
+ * OPTEE_SMC_RETURN_OK			Original call completed, result
+ *					updated in the previously supplied.
+ *					struct optee_msg_arg
+ * OPTEE_SMC_RETURN_RPC			Call suspended by RPC call to normal
+ *					world.
+ * OPTEE_SMC_RETURN_ERESUME		Resume failed, the opaque resume
+ *					information was corrupt.
+ */
+#define OPTEE_SMC_FUNCID_RETURN_FROM_RPC	3
+#define OPTEE_SMC_CALL_RETURN_FROM_RPC \
+	OPTEE_SMC_STD_CALL_VAL(OPTEE_SMC_FUNCID_RETURN_FROM_RPC)
+
+#define OPTEE_SMC_RETURN_RPC_PREFIX_MASK	0xFFFF0000
+#define OPTEE_SMC_RETURN_RPC_PREFIX		0xFFFF0000
+#define OPTEE_SMC_RETURN_RPC_FUNC_MASK		0x0000FFFF
+
+#define OPTEE_SMC_RETURN_GET_RPC_FUNC(ret) \
+	((ret) & OPTEE_SMC_RETURN_RPC_FUNC_MASK)
+
+#define OPTEE_SMC_RPC_VAL(func)		((func) | OPTEE_SMC_RETURN_RPC_PREFIX)
+
+/*
+ * Allocate memory for RPC parameter passing. The memory is used to hold a
+ * struct optee_msg_arg.
+ *
+ * "Call" register usage:
+ * a0	This value, OPTEE_SMC_RETURN_RPC_ALLOC
+ * a1	Size in bytes of required argument memory
+ * a2	Not used
+ * a3	Resume information, must be preserved
+ * a4-5	Not used
+ * a6-7	Resume information, must be preserved
+ *
+ * "Return" register usage:
+ * a0	SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC.
+ * a1	Upper 32bits of 64bit physical pointer to allocated
+ *	memory, (a1 == 0 && a2 == 0) if size was 0 or if memory can't
+ *	be allocated.
+ * a2	Lower 32bits of 64bit physical pointer to allocated
+ *	memory, (a1 == 0 && a2 == 0) if size was 0 or if memory can't
+ *	be allocated
+ * a3	Preserved
+ * a4	Upper 32bits of 64bit Shared memory cookie used when freeing
+ *	the memory or doing an RPC
+ * a5	Lower 32bits of 64bit Shared memory cookie used when freeing
+ *	the memory or doing an RPC
+ * a6-7	Preserved
+ */
+#define OPTEE_SMC_RPC_FUNC_ALLOC	0
+#define OPTEE_SMC_RETURN_RPC_ALLOC \
+	OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_ALLOC)
+
+/*
+ * Free memory previously allocated by OPTEE_SMC_RETURN_RPC_ALLOC
+ *
+ * "Call" register usage:
+ * a0	This value, OPTEE_SMC_RETURN_RPC_FREE_ARG
+ * a1	Upper 32bits of 64bit shared memory cookie belonging to this
+ *	argument memory
+ * a2	Lower 32bits of 64bit shared memory cookie belonging to this
+ *	argument memory
+ * a3-7	Resume information, must be preserved
+ *
+ * "Return" register usage:
+ * a0	SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC.
+ * a1-2	Not used
+ * a3-7	Preserved
+ */
+#define OPTEE_SMC_RPC_FUNC_FREE		2
+#define OPTEE_SMC_RETURN_RPC_FREE \
+	OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_FREE)
+
+/*
+ * Deliver an IRQ in normal world.
+ *
+ * "Call" register usage:
+ * a0	OPTEE_SMC_RETURN_RPC_IRQ
+ * a1-7	Resume information, must be preserved
+ *
+ * "Return" register usage:
+ * a0	SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC.
+ * a1-7	Preserved
+ */
+#define OPTEE_SMC_RPC_FUNC_IRQ		4
+#define OPTEE_SMC_RETURN_RPC_IRQ \
+	OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_IRQ)
+
+/*
+ * Do an RPC request. The supplied struct optee_msg_arg tells which
+ * request to do and the parameters for the request. The following fields
+ * are used (the rest are unused):
+ * - cmd		the Request ID
+ * - ret		return value of the request, filled in by normal world
+ * - num_params		number of parameters for the request
+ * - params		the parameters
+ * - param_attrs	attributes of the parameters
+ *
+ * "Call" register usage:
+ * a0	OPTEE_SMC_RETURN_RPC_CMD
+ * a1	Upper 32bit of a 64bit Shared memory cookie holding a
+ *	struct optee_msg_arg, must be preserved, only the data should
+ *	be updated
+ * a2	Lower 32bit of a 64bit Shared memory cookie holding a
+ *	struct optee_msg_arg, must be preserved, only the data should
+ *	be updated
+ * a3-7	Resume information, must be preserved
+ *
+ * "Return" register usage:
+ * a0	SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC.
+ * a1-2	Not used
+ * a3-7	Preserved
+ */
+#define OPTEE_SMC_RPC_FUNC_CMD		5
+#define OPTEE_SMC_RETURN_RPC_CMD \
+	OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_CMD)
+
+/* Returned in a0 */
+#define OPTEE_SMC_RETURN_UNKNOWN_FUNCTION 0xFFFFFFFF
+
+/* Returned in a0 only from Trusted OS functions */
+#define OPTEE_SMC_RETURN_OK		0x0
+#define OPTEE_SMC_RETURN_ETHREAD_LIMIT	0x1
+#define OPTEE_SMC_RETURN_EBUSY		0x2
+#define OPTEE_SMC_RETURN_ERESUME	0x3
+#define OPTEE_SMC_RETURN_EBADADDR	0x4
+#define OPTEE_SMC_RETURN_EBADCMD	0x5
+#define OPTEE_SMC_RETURN_ENOMEM		0x6
+#define OPTEE_SMC_RETURN_ENOTAVAIL	0x7
+#define OPTEE_SMC_RETURN_IS_RPC(ret) \
+	(((ret) != OPTEE_SMC_RETURN_UNKNOWN_FUNCTION) && \
+	((((ret) & OPTEE_SMC_RETURN_RPC_PREFIX_MASK) == \
+		OPTEE_SMC_RETURN_RPC_PREFIX)))
+
+#endif /* OPTEE_SMC_H */
diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
new file mode 100644
index 0000000..05716e9
--- /dev/null
+++ b/drivers/tee/optee/rpc.c
@@ -0,0 +1,322 @@
+
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/sched.h>
+#include <linux/tee_drv.h>
+#include "optee_private.h"
+#include "optee_smc.h"
+
+struct wq_entry {
+	struct list_head link;
+	struct completion c;
+	u32 key;
+};
+
+void optee_wait_queue_init(struct optee_wait_queue *priv)
+{
+	mutex_init(&priv->mu);
+	INIT_LIST_HEAD(&priv->db);
+}
+
+void optee_wait_queue_exit(struct optee_wait_queue *priv)
+{
+	mutex_destroy(&priv->mu);
+}
+
+static void handle_rpc_func_cmd_get_time(struct optee_msg_arg *arg)
+{
+	struct optee_msg_param *params;
+	struct timespec64 ts;
+
+	if (arg->num_params != 1)
+		goto bad;
+	params = OPTEE_MSG_GET_PARAMS(arg);
+	if ((params->attr & OPTEE_MSG_ATTR_TYPE_MASK) !=
+			OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT)
+		goto bad;
+
+	getnstimeofday64(&ts);
+	params->u.value.a = ts.tv_sec;
+	params->u.value.b = ts.tv_nsec;
+
+	arg->ret = TEEC_SUCCESS;
+	return;
+bad:
+	arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+}
+
+static struct wq_entry *wq_entry_get(struct optee_wait_queue *wq, u32 key)
+{
+	struct wq_entry *w;
+
+	mutex_lock(&wq->mu);
+
+	list_for_each_entry(w, &wq->db, link)
+		if (w->key == key)
+			goto out;
+
+	w = kmalloc(sizeof(struct wq_entry), GFP_KERNEL);
+	if (w) {
+		init_completion(&w->c);
+		w->key = key;
+		list_add_tail(&w->link, &wq->db);
+	}
+out:
+	mutex_unlock(&wq->mu);
+	return w;
+}
+
+static void wq_sleep(struct optee_wait_queue *wq, u32 key)
+{
+	struct wq_entry *w = wq_entry_get(wq, key);
+
+	if (w) {
+		wait_for_completion(&w->c);
+		mutex_lock(&wq->mu);
+		list_del(&w->link);
+		mutex_unlock(&wq->mu);
+		kfree(w);
+	}
+}
+
+static void wq_wakeup(struct optee_wait_queue *wq, u32 key)
+{
+	struct wq_entry *w = wq_entry_get(wq, key);
+
+	if (w)
+		complete(&w->c);
+}
+
+static void handle_rpc_func_cmd_wq(struct optee *optee,
+			struct optee_msg_arg *arg)
+{
+	struct optee_msg_param *params;
+
+	if (arg->num_params != 1)
+		goto bad;
+
+	params = OPTEE_MSG_GET_PARAMS(arg);
+	if ((params->attr & OPTEE_MSG_ATTR_TYPE_MASK) !=
+			OPTEE_MSG_ATTR_TYPE_VALUE_INPUT)
+		goto bad;
+
+	switch (params->u.value.a) {
+	case OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP:
+		wq_sleep(&optee->wait_queue, params->u.value.b);
+		break;
+	case OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP:
+		wq_wakeup(&optee->wait_queue, params->u.value.b);
+		break;
+	default:
+		goto bad;
+	}
+
+	arg->ret = TEEC_SUCCESS;
+	return;
+bad:
+	arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+}
+
+static void handle_rpc_func_cmd_wait(struct optee_msg_arg *arg)
+{
+	struct optee_msg_param *params;
+	u32 msec_to_wait;
+
+	if (arg->num_params != 1)
+		goto bad;
+
+	params = OPTEE_MSG_GET_PARAMS(arg);
+	if ((params->attr & OPTEE_MSG_ATTR_TYPE_MASK) !=
+			OPTEE_MSG_ATTR_TYPE_VALUE_INPUT)
+		goto bad;
+
+	msec_to_wait = params->u.value.a;
+
+	/* set task's state to interruptible sleep */
+	set_current_state(TASK_INTERRUPTIBLE);
+
+	/* take a nap */
+	schedule_timeout(msecs_to_jiffies(msec_to_wait));
+
+	arg->ret = TEEC_SUCCESS;
+	return;
+bad:
+	arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+}
+
+static void handle_rpc_supp_cmd(struct tee_context *ctx,
+			struct optee_msg_arg *arg)
+{
+	struct tee_param *params;
+	struct optee_msg_param *msg_params = OPTEE_MSG_GET_PARAMS(arg);
+
+	arg->ret_origin = TEEC_ORIGIN_COMMS;
+
+	params = kmalloc_array(arg->num_params, sizeof(struct tee_param),
+			       GFP_KERNEL);
+	if (!params) {
+		arg->ret = TEEC_ERROR_OUT_OF_MEMORY;
+		return;
+	}
+
+	if (optee_from_msg_param(params, arg->num_params, msg_params)) {
+		arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+		goto out;
+	}
+
+	arg->ret = optee_supp_thrd_req(ctx, arg->cmd, arg->num_params, params);
+
+	if (optee_to_msg_param(msg_params, arg->num_params, params))
+		arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+out:
+	kfree(params);
+}
+
+static void handle_rpc_func_cmd_shm_alloc(struct tee_context *ctx,
+			struct optee_msg_arg *arg)
+{
+	struct tee_device *teedev = ctx->teedev;
+	struct optee_msg_param *params = OPTEE_MSG_GET_PARAMS(arg);
+	phys_addr_t pa;
+	struct tee_shm *shm;
+	u32 flags;
+	size_t sz;
+	size_t n;
+
+	arg->ret_origin = TEEC_ORIGIN_COMMS;
+
+	if (!arg->num_params ||
+	    params->attr != OPTEE_MSG_ATTR_TYPE_VALUE_INPUT) {
+		arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+		return;
+	}
+
+	for (n = 1; n < arg->num_params; n++) {
+		if (params[n].attr != OPTEE_MSG_ATTR_TYPE_NONE) {
+			arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+			return;
+		}
+	}
+
+	flags = TEE_SHM_MAPPED;
+	switch (params->u.value.a) {
+	case OPTEE_MSG_RPC_SHM_TYPE_APPL:
+		flags |= TEE_SHM_DMA_BUF;
+		break;
+	case OPTEE_MSG_RPC_SHM_TYPE_KERNEL:
+		break;
+	default:
+		arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+		return;
+	}
+	sz = params->u.value.b;
+	/* TODO pass alignment */
+	shm = tee_shm_alloc(teedev, params->u.value.b, flags);
+	if (IS_ERR(shm)) {
+		arg->ret = TEEC_ERROR_OUT_OF_MEMORY;
+		return;
+	}
+
+	if (tee_shm_get_pa(shm, 0, &pa)) {
+		arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+		goto bad;
+	}
+
+	params[0].attr = OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT;
+	params[0].u.tmem.buf_ptr = pa;
+	params[0].u.tmem.size = sz;
+	params[0].u.tmem.shm_ref = (unsigned long)shm;
+	arg->ret = TEEC_SUCCESS;
+	return;
+bad:
+	tee_shm_free(shm);
+}
+
+static void handle_rpc_func_cmd(struct tee_context *ctx, struct optee *optee,
+			struct tee_shm *shm)
+{
+	struct optee_msg_arg *arg;
+
+	arg = tee_shm_get_va(shm, 0);
+	if (IS_ERR(arg)) {
+		dev_err(optee->dev, "%s: tee_shm_get_va %p failed\n",
+			__func__, shm);
+		return;
+	}
+
+	switch (arg->cmd) {
+	case OPTEE_MSG_RPC_CMD_GET_TIME:
+		handle_rpc_func_cmd_get_time(arg);
+		break;
+	case OPTEE_MSG_RPC_CMD_WAIT_QUEUE:
+		handle_rpc_func_cmd_wq(optee, arg);
+		break;
+	case OPTEE_MSG_RPC_CMD_SUSPEND:
+		handle_rpc_func_cmd_wait(arg);
+		break;
+	case OPTEE_MSG_RPC_CMD_SHM_ALLOC:
+		handle_rpc_func_cmd_shm_alloc(ctx, arg);
+		break;
+	default:
+		handle_rpc_supp_cmd(ctx, arg);
+	}
+}
+
+void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param)
+{
+	struct tee_device *teedev = ctx->teedev;
+	struct optee *optee = tee_get_drvdata(teedev);
+	struct tee_shm *shm;
+	phys_addr_t pa;
+
+	switch (OPTEE_SMC_RETURN_GET_RPC_FUNC(param->a0)) {
+	case OPTEE_SMC_RPC_FUNC_ALLOC:
+		shm = tee_shm_alloc(teedev, param->a1, TEE_SHM_MAPPED);
+		if (!IS_ERR(shm) && !tee_shm_get_pa(shm, 0, &pa)) {
+			reg_pair_from_64(&param->a1, &param->a2, pa);
+			reg_pair_from_64(&param->a4, &param->a5,
+					 (unsigned long)shm);
+		} else {
+			param->a1 = 0;
+			param->a2 = 0;
+			param->a4 = 0;
+			param->a5 = 0;
+		}
+		break;
+	case OPTEE_SMC_RPC_FUNC_FREE:
+		shm = reg_pair_to_ptr(param->a1, param->a2);
+		tee_shm_free(shm);
+		break;
+	case OPTEE_SMC_RPC_FUNC_IRQ:
+		/*
+		 * An IRQ was raised while secure world was executing,
+		 * since all IRQs a handled in Linux a dummy RPC is
+		 * performed to let Linux take the IRQ through the normal
+		 * vector.
+		 */
+		break;
+	case OPTEE_SMC_RPC_FUNC_CMD:
+		shm = reg_pair_to_ptr(param->a1, param->a2);
+		handle_rpc_func_cmd(ctx, optee, shm);
+		break;
+	default:
+		dev_warn(optee->dev, "Unknown RPC func 0x%x\n",
+			 (u32)OPTEE_SMC_RETURN_GET_RPC_FUNC(param->a0));
+		break;
+	}
+
+	param->a0 = OPTEE_SMC_CALL_RETURN_FROM_RPC;
+}
diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c
new file mode 100644
index 0000000..b6478b6
--- /dev/null
+++ b/drivers/tee/optee/supp.c
@@ -0,0 +1,212 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include "optee_private.h"
+
+void optee_supp_init(struct optee_supp *supp)
+{
+	memset(supp, 0, sizeof(*supp));
+	mutex_init(&supp->thrd_mutex);
+	mutex_init(&supp->supp_mutex);
+	init_completion(&supp->data_to_supp);
+	init_completion(&supp->data_from_supp);
+}
+
+void optee_supp_uninit(struct optee_supp *supp)
+{
+	mutex_destroy(&supp->thrd_mutex);
+	mutex_destroy(&supp->supp_mutex);
+}
+
+u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params,
+			struct tee_param *param)
+{
+	struct optee *optee = tee_get_drvdata(ctx->teedev);
+	struct optee_supp *supp = &optee->supp;
+	u32 ret;
+
+	/*
+	 * Other threads blocks here until we've copied our answer from
+	 * supplicant.
+	 */
+	mutex_lock(&supp->thrd_mutex);
+
+	/*
+	 * We have exclusive access now since the supplicant at this
+	 * point is either doing a
+	 * wait_for_completion_interruptible(data_to_supp) or is in
+	 * userspace still about to do the ioctl() to enter
+	 * optee_supp_read() below.
+	 */
+
+	supp->func = func;
+	supp->num_params = num_params;
+	supp->param = param;
+	supp->req_posted = true;
+
+	/* Let supplicant get the data */
+	complete(&supp->data_to_supp);
+
+	/*
+	 * Wait for supplicant to process and return result, once we've
+	 * returned from wait_for_completion(data_from_supp) we have
+	 * exclusive access again.
+	 */
+	wait_for_completion(&supp->data_from_supp);
+
+	ret = supp->ret;
+	supp->param = NULL;
+	supp->req_posted = false;
+
+	/* We're done, let someone else talk to the supplicant now. */
+	mutex_unlock(&supp->thrd_mutex);
+
+	return ret;
+}
+
+int optee_supp_recv(struct tee_context *ctx, u32 *func, u32 *num_params,
+		struct tee_param *param)
+{
+	struct tee_device *teedev = ctx->teedev;
+	struct optee *optee = tee_get_drvdata(teedev);
+	struct optee_supp *supp = &optee->supp;
+	int rc;
+
+	/*
+	 * In case two supplicants or two threads in one supplicant is
+	 * calling this function simultaneously we need to protect the
+	 * data with a mutex which we'll release before returning.
+	 */
+	mutex_lock(&supp->supp_mutex);
+
+	if (supp->supp_next_send) {
+		/*
+		 * optee_supp_recv() has been called again without
+		 * a optee_supp_send() in between. Supplicant has
+		 * probably been restarted before it was able to
+		 * write back last result. Abort last request and
+		 * wait for a new.
+		 */
+		if (supp->req_posted) {
+			supp->ret = TEEC_ERROR_COMMUNICATION;
+			supp->supp_next_send = false;
+			complete(&supp->data_from_supp);
+		}
+	}
+
+	/*
+	 * This is where supplicant will be hanging most of the
+	 * time, let's make this interruptable so we can easily
+	 * restart supplicant if needed.
+	 */
+	if (wait_for_completion_interruptible(&supp->data_to_supp)) {
+		rc = -ERESTARTSYS;
+		goto out;
+	}
+
+	/* We have exlusive access to the data */
+
+	if (*num_params < supp->num_params) {
+		/*
+		 * Not enough room for parameters, tell supplicant
+		 * it failed and abort last request.
+		 */
+		supp->ret = TEEC_ERROR_COMMUNICATION;
+		rc = -EINVAL;
+		complete(&supp->data_from_supp);
+		goto out;
+	}
+
+	*func = supp->func;
+	*num_params = supp->num_params;
+	memcpy(param, supp->param,
+	       sizeof(struct tee_param) * supp->num_params);
+
+	/* Allow optee_supp_send() below to do its work */
+	supp->supp_next_send = true;
+
+	rc = 0;
+out:
+	mutex_unlock(&supp->supp_mutex);
+	return rc;
+}
+
+int optee_supp_send(struct tee_context *ctx, u32 ret, u32 num_params,
+			struct tee_param *param)
+{
+	struct tee_device *teedev = ctx->teedev;
+	struct optee *optee = tee_get_drvdata(teedev);
+	struct optee_supp *supp = &optee->supp;
+	size_t n;
+	int rc = 0;
+
+	/*
+	 * We still have exclusive access to the data since that's how we
+	 * left it when returning from optee_supp_read().
+	 */
+
+	/* See comment on mutex in optee_supp_read() above */
+	mutex_lock(&supp->supp_mutex);
+
+	if (!supp->supp_next_send) {
+		/*
+		 * Something strange is going on, supplicant shouldn't
+		 * enter optee_supp_send() in this state
+		 */
+		rc = -ENOENT;
+		goto out;
+	}
+
+	if (num_params != supp->num_params) {
+		/*
+		 * Something is wrong, let supplicant restart. Next call to
+		 * optee_supp_recv() will give an error to the requesting
+		 * thread and release it.
+		 */
+		rc = -EINVAL;
+		goto out;
+	}
+
+	/* Update out and in/out parameters */
+	for (n = 0; n < num_params; n++) {
+		struct tee_param *p = supp->param + n;
+
+		switch (p->attr) {
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT:
+			p->u.value.a = param[n].u.value.a;
+			p->u.value.b = param[n].u.value.b;
+			p->u.value.c = param[n].u.value.c;
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT:
+			p->u.memref.size = param[n].u.memref.size;
+			break;
+		default:
+			break;
+		}
+	}
+	supp->ret = ret;
+
+	/* Allow optee_supp_recv() above to do its work */
+	supp->supp_next_send = false;
+
+	/* Let the requesting thread continue */
+	complete(&supp->data_from_supp);
+out:
+	mutex_unlock(&supp->supp_mutex);
+	return rc;
+}
-- 
1.9.1



From mkarthi3 at visteon.com  Mon Feb  1 01:58:59 2016
From: mkarthi3 at visteon.com (Mutharaju, Prasanna (P.))
Date: Mon, 1 Feb 2016 09:58:59 +0000
Subject: [PATCH] ARM: davinci: Use PTR_ERR_OR_ZERO at the end of
 dm646x_init_edma
Message-ID: <20160201095736.GA6255@jci-VirtualBox>

Making use of PTR_ERR_OR_ZERO helper function

Signed-off-by: Prasanna Karthik <mkarthi3 at visteon.com>
---
 arch/arm/mach-davinci/dm646x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 70eb427..9984632 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -938,7 +938,7 @@ int __init dm646x_init_edma(struct edma_rsv_info *rsv)
 	dm646x_edma_pdata.rsv = rsv;
 
 	edma_pdev = platform_device_register_full(&dm646x_edma_device);
-	return IS_ERR(edma_pdev) ? PTR_ERR(edma_pdev) : 0;
+	return PTR_ERR_OR_ZERO(edma_pdev);
 }
 
 void __init dm646x_init(void)
-- 
1.9.1


From lkp at intel.com  Mon Feb  1 02:01:26 2016
From: lkp at intel.com (kbuild test robot)
Date: Mon, 1 Feb 2016 18:01:26 +0800
Subject: [PATCH 6/6] coresight-stm: adding driver for CoreSight STM
 component
In-Reply-To: <1454313529-8860-7-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <201602011753.FpQPQQPf%fengguang.wu@intel.com>

Hi Pratik,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.5-rc2 next-20160201]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Chunyan-Zhang/Introduce-CoreSight-STM-support/20160201-160437
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: arm-allmodconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> drivers/hwtracing/coresight/coresight-stm.c:671:27: error: unknown type name 'tcsr'
    coresight_stm_simple_func(tcsr, STMTCSR);
                              ^
   drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                               ^
>> drivers/hwtracing/coresight/coresight-stm.c:57:20: error: expected declaration specifiers or '...' before numeric constant
    #define STMTCSR    0xe80
                       ^
   drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                                     ^
   drivers/hwtracing/coresight/coresight-stm.c:671:33: note: in expansion of macro 'STMTCSR'
    coresight_stm_simple_func(tcsr, STMTCSR);
                                    ^
>> drivers/hwtracing/coresight/coresight-stm.c:672:27: error: unknown type name 'tsfreqr'
    coresight_stm_simple_func(tsfreqr, STMTSFREQR);
                              ^
   drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                               ^
   drivers/hwtracing/coresight/coresight-stm.c:59:22: error: expected declaration specifiers or '...' before numeric constant
    #define STMTSFREQR   0xe8c
                         ^
   drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                                     ^
   drivers/hwtracing/coresight/coresight-stm.c:672:36: note: in expansion of macro 'STMTSFREQR'
    coresight_stm_simple_func(tsfreqr, STMTSFREQR);
                                       ^
>> drivers/hwtracing/coresight/coresight-stm.c:673:27: error: unknown type name 'syncr'
    coresight_stm_simple_func(syncr, STMSYNCR);
                              ^
   drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                               ^
   drivers/hwtracing/coresight/coresight-stm.c:60:20: error: expected declaration specifiers or '...' before numeric constant
    #define STMSYNCR   0xe90
                       ^
   drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                                     ^
   drivers/hwtracing/coresight/coresight-stm.c:673:34: note: in expansion of macro 'STMSYNCR'
    coresight_stm_simple_func(syncr, STMSYNCR);
                                     ^
>> drivers/hwtracing/coresight/coresight-stm.c:674:27: error: unknown type name 'sper'
    coresight_stm_simple_func(sper, STMSPER);
                              ^
   drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                               ^
   drivers/hwtracing/coresight/coresight-stm.c:49:20: error: expected declaration specifiers or '...' before numeric constant
    #define STMSPER    0xe00
                       ^
   drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                                     ^
   drivers/hwtracing/coresight/coresight-stm.c:674:33: note: in expansion of macro 'STMSPER'
    coresight_stm_simple_func(sper, STMSPER);
                                    ^
>> drivers/hwtracing/coresight/coresight-stm.c:675:27: error: unknown type name 'spter'
    coresight_stm_simple_func(spter, STMSPTER);
                              ^
   drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                               ^
   drivers/hwtracing/coresight/coresight-stm.c:50:20: error: expected declaration specifiers or '...' before numeric constant
    #define STMSPTER   0xe20
                       ^
   drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                                     ^
   drivers/hwtracing/coresight/coresight-stm.c:675:34: note: in expansion of macro 'STMSPTER'
    coresight_stm_simple_func(spter, STMSPTER);
                                     ^
>> drivers/hwtracing/coresight/coresight-stm.c:676:27: error: unknown type name 'privmaskr'
    coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
                              ^
   drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                               ^
   drivers/hwtracing/coresight/coresight-stm.c:51:24: error: expected declaration specifiers or '...' before numeric constant
    #define STMPRIVMASKR   0xe40
                           ^
   drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                                     ^
   drivers/hwtracing/coresight/coresight-stm.c:676:38: note: in expansion of macro 'STMPRIVMASKR'
    coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
                                         ^
>> drivers/hwtracing/coresight/coresight-stm.c:677:27: error: unknown type name 'spscr'
    coresight_stm_simple_func(spscr, STMSPSCR);
                              ^
   drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                               ^
   drivers/hwtracing/coresight/coresight-stm.c:52:20: error: expected declaration specifiers or '...' before numeric constant
    #define STMSPSCR   0xe60
                       ^
   drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                                     ^
   drivers/hwtracing/coresight/coresight-stm.c:677:34: note: in expansion of macro 'STMSPSCR'
    coresight_stm_simple_func(spscr, STMSPSCR);
                                     ^
>> drivers/hwtracing/coresight/coresight-stm.c:678:27: error: unknown type name 'spmscr'
    coresight_stm_simple_func(spmscr, STMSPMSCR);
                              ^
   drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                               ^
   drivers/hwtracing/coresight/coresight-stm.c:53:21: error: expected declaration specifiers or '...' before numeric constant
    #define STMSPMSCR   0xe64
                        ^
   drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                                     ^
   drivers/hwtracing/coresight/coresight-stm.c:678:35: note: in expansion of macro 'STMSPMSCR'
    coresight_stm_simple_func(spmscr, STMSPMSCR);
                                      ^
>> drivers/hwtracing/coresight/coresight-stm.c:679:27: error: unknown type name 'spfeat1r'
    coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
                              ^
   drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                               ^
   drivers/hwtracing/coresight/coresight-stm.c:62:23: error: expected declaration specifiers or '...' before numeric constant
    #define STMSPFEAT1R   0xea0
                          ^
   drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                                     ^
   drivers/hwtracing/coresight/coresight-stm.c:679:37: note: in expansion of macro 'STMSPFEAT1R'
    coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
                                        ^
>> drivers/hwtracing/coresight/coresight-stm.c:680:27: error: unknown type name 'spfeat2r'
    coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
                              ^
   drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                               ^
   drivers/hwtracing/coresight/coresight-stm.c:63:23: error: expected declaration specifiers or '...' before numeric constant
    #define STMSPFEAT2R   0xea4
                          ^
   drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                                     ^
   drivers/hwtracing/coresight/coresight-stm.c:680:37: note: in expansion of macro 'STMSPFEAT2R'
    coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
                                        ^
>> drivers/hwtracing/coresight/coresight-stm.c:681:27: error: unknown type name 'spfeat3r'
    coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
                              ^
   drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                               ^
   drivers/hwtracing/coresight/coresight-stm.c:64:23: error: expected declaration specifiers or '...' before numeric constant
    #define STMSPFEAT3R   0xea8
                          ^
   drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                                     ^
   drivers/hwtracing/coresight/coresight-stm.c:681:37: note: in expansion of macro 'STMSPFEAT3R'
    coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
                                        ^
>> drivers/hwtracing/coresight/coresight-stm.c:682:27: error: unknown type name 'devid'
    coresight_stm_simple_func(devid, CORESIGHT_DEVID);
                              ^
   drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                               ^
   drivers/hwtracing/coresight/coresight-priv.h:31:26: error: expected declaration specifiers or '...' before numeric constant
    #define CORESIGHT_DEVID  0xfc8
                             ^
   drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
     coresight_simple_func(struct stm_drvdata, name, offset)
                                                     ^
   drivers/hwtracing/coresight/coresight-stm.c:682:34: note: in expansion of macro 'CORESIGHT_DEVID'
    coresight_stm_simple_func(devid, CORESIGHT_DEVID);
                                     ^
>> drivers/hwtracing/coresight/coresight-stm.c:694:3: error: 'dev_attr_tcsr' undeclared here (not in a function)
     &dev_attr_tcsr.attr,
      ^
>> drivers/hwtracing/coresight/coresight-stm.c:695:3: error: 'dev_attr_tsfreqr' undeclared here (not in a function)
     &dev_attr_tsfreqr.attr,
      ^
>> drivers/hwtracing/coresight/coresight-stm.c:696:3: error: 'dev_attr_syncr' undeclared here (not in a function)
     &dev_attr_syncr.attr,
      ^
>> drivers/hwtracing/coresight/coresight-stm.c:697:3: error: 'dev_attr_sper' undeclared here (not in a function)
     &dev_attr_sper.attr,
      ^
>> drivers/hwtracing/coresight/coresight-stm.c:698:3: error: 'dev_attr_spter' undeclared here (not in a function)
     &dev_attr_spter.attr,
      ^
>> drivers/hwtracing/coresight/coresight-stm.c:699:3: error: 'dev_attr_privmaskr' undeclared here (not in a function)
     &dev_attr_privmaskr.attr,
      ^
>> drivers/hwtracing/coresight/coresight-stm.c:700:3: error: 'dev_attr_spscr' undeclared here (not in a function)
     &dev_attr_spscr.attr,
      ^

vim +/tcsr +671 drivers/hwtracing/coresight/coresight-stm.c

   663		drvdata->traceid = val & 0x7f;
   664		return size;
   665	}
   666	static DEVICE_ATTR_RW(traceid);
   667	
   668	#define coresight_stm_simple_func(name, offset)	\
 > 669		coresight_simple_func(struct stm_drvdata, name, offset)
   670	
 > 671	coresight_stm_simple_func(tcsr, STMTCSR);
 > 672	coresight_stm_simple_func(tsfreqr, STMTSFREQR);
 > 673	coresight_stm_simple_func(syncr, STMSYNCR);
 > 674	coresight_stm_simple_func(sper, STMSPER);
 > 675	coresight_stm_simple_func(spter, STMSPTER);
 > 676	coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
 > 677	coresight_stm_simple_func(spscr, STMSPSCR);
 > 678	coresight_stm_simple_func(spmscr, STMSPMSCR);
 > 679	coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
 > 680	coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
 > 681	coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
 > 682	coresight_stm_simple_func(devid, CORESIGHT_DEVID);
   683	
   684	static struct attribute *coresight_stm_attrs[] = {
   685		&dev_attr_hwevent_enable.attr,
   686		&dev_attr_hwevent_select.attr,
   687		&dev_attr_port_enable.attr,
   688		&dev_attr_port_select.attr,
   689		&dev_attr_traceid.attr,
   690		NULL,
   691	};
   692	
   693	static struct attribute *coresight_stm_mgmt_attrs[] = {
 > 694		&dev_attr_tcsr.attr,
 > 695		&dev_attr_tsfreqr.attr,
 > 696		&dev_attr_syncr.attr,
 > 697		&dev_attr_sper.attr,
 > 698		&dev_attr_spter.attr,
 > 699		&dev_attr_privmaskr.attr,
 > 700		&dev_attr_spscr.attr,
 > 701		&dev_attr_spmscr.attr,
 > 702		&dev_attr_spfeat1r.attr,
 > 703		&dev_attr_spfeat2r.attr,
 > 704		&dev_attr_spfeat3r.attr,
 > 705		&dev_attr_devid.attr,
   706		NULL,
   707	};
   708	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 56270 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160201/3551dc0a/attachment-0001.obj>

From k at japko.eu  Mon Feb  1 02:12:26 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Mon, 1 Feb 2016 11:12:26 +0100
Subject: [PATCH] pinctrl: sunxi: Add H3 R_PIO controller support
Message-ID: <20160201101225.GA19687@box2.japko.eu>

H3 has additional PIO controller similar to what we can find on A23.
It's a 12 pin port, described in H3 Datasheet rev 1.1, pages 345-350.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 arch/arm/boot/dts/sun8i-h3.dtsi                    |  12 +++
 drivers/pinctrl/sunxi/Kconfig                      |   4 +
 drivers/pinctrl/sunxi/Makefile                     |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c         | 105 +++++++++++++++++++++
 5 files changed, 123 insertions(+)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c

diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index 9213b27..730a917 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -20,6 +20,7 @@ Required properties:
   "allwinner,sun9i-a80-pinctrl"
   "allwinner,sun9i-a80-r-pinctrl"
   "allwinner,sun8i-a83t-pinctrl"
+  "allwinner,sun8i-h3-r-pinctrl"
   "allwinner,sun8i-h3-pinctrl"
 
 - reg: Should contain the register physical address and length for the
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 1524130e..745f64c 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -493,5 +493,17 @@
 			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
 		};
+
+		r_pio: pinctrl at 01f02c00 {
+			compatible = "allwinner,sun8i-h3-r-pinctrl";
+			reg = <0x01f02c00 0x400>;
+			interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&bus_gates 69>;
+			gpio-controller;
+			#gpio-cells = <3>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+
 	};
 };
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index f8dbc8b..75a26c9 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -55,6 +55,10 @@ config PINCTRL_SUN8I_H3
 	def_bool MACH_SUN8I
 	select PINCTRL_SUNXI_COMMON
 
+config PINCTRL_SUN8I_H3_R
+	def_bool MACH_SUN8I
+	select PINCTRL_SUNXI_COMMON
+
 config PINCTRL_SUN9I_A80
 	def_bool MACH_SUN9I
 	select PINCTRL_SUNXI_COMMON
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index ef82f22..a5d56f1 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -14,5 +14,6 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23_R)	+= pinctrl-sun8i-a23-r.o
 obj-$(CONFIG_PINCTRL_SUN8I_A33)		+= pinctrl-sun8i-a33.o
 obj-$(CONFIG_PINCTRL_SUN8I_A83T)	+= pinctrl-sun8i-a83t.o
 obj-$(CONFIG_PINCTRL_SUN8I_H3)		+= pinctrl-sun8i-h3.o
+obj-$(CONFIG_PINCTRL_SUN8I_H3_R)	+= pinctrl-sun8i-h3-r.o
 obj-$(CONFIG_PINCTRL_SUN9I_A80)		+= pinctrl-sun9i-a80.o
 obj-$(CONFIG_PINCTRL_SUN9I_A80_R)	+= pinctrl-sun9i-a80-r.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
new file mode 100644
index 0000000..6271ceb
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
@@ -0,0 +1,105 @@
+/*
+ * Allwinner H3 SoCs pinctrl driver.
+ *
+ * Copyright (C) 2016 Krzysztof Adamski <k at japko.eu>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/pinctrl.h>
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin sun8i_h3_r_pins[] = {
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_twi"),         /* SCK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),	/* PL_EINT0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_twi"),         /* SDA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),	/* PL_EINT1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_uart"),        /* TX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),	/* PL_EINT2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_uart"),        /* RX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),	/* PL_EINT3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* MS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),	/* PL_EINT4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* CK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),	/* PL_EINT5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* DO */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),	/* PL_EINT6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* DI */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),	/* PL_EINT7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),	/* PL_EINT8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),	/* PL_EINT9 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_pwn"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)),	/* PL_EINT10 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_cir_rx"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 11)),	/* PL_EINT11 */
+};
+
+static const struct sunxi_pinctrl_desc sun8i_h3_r_pinctrl_data = {
+	.pins = sun8i_h3_r_pins,
+	.npins = ARRAY_SIZE(sun8i_h3_r_pins),
+	.irq_banks = 1,
+	.pin_base = PL_BASE,
+};
+
+static int sun8i_h3_r_pinctrl_probe(struct platform_device *pdev)
+{
+	return sunxi_pinctrl_init(pdev,
+				  &sun8i_h3_r_pinctrl_data);
+}
+
+static const struct of_device_id sun8i_h3_r_pinctrl_match[] = {
+	{ .compatible = "allwinner,sun8i-h3-r-pinctrl", },
+	{}
+};
+
+static struct platform_driver sun8i_h3_r_pinctrl_driver = {
+	.probe	= sun8i_h3_r_pinctrl_probe,
+	.driver	= {
+		.name		= "sun8i-h3-r-pinctrl",
+		.of_match_table	= sun8i_h3_r_pinctrl_match,
+	},
+};
+builtin_platform_driver(sun8i_h3_r_pinctrl_driver);
-- 
2.4.2



From arnd at arndb.de  Mon Feb  1 02:19:10 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 01 Feb 2016 11:19:10 +0100
Subject: [PATCH] clk: vt8500: don't return possibly uninitialized data
Message-ID: <4790407.6zgSQCdsSB@wuerfel>

The clk-vt8500.c driver would previously enter an endless loop
when invalid settings got requested, this was now fixed. However,
the driver will now return uninitialized data for a subset of those
cases instead, as the gcc correctly warns:

clk/clk-vt8500.c: In function 'wm8650_find_pll_bits':
clk/clk-vt8500.c:423:12: error: 'best_div2' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  *divisor2 = best_div2;
            ^
clk/clk-vt8500.c:422:12: error: 'best_div1' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  *divisor1 = best_div1;
            ^
clk/clk-vt8500.c:421:14: error: 'best_mul' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  *multiplier = best_mul;

This reworks the error handling in the driver so we now return
-EINVAL from clk_round_rate() and clk_set_rate() when we get
impossible inputs.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 090341b0a95d ("clk: vt8500: fix sign of possible PLL values")

diff --git a/drivers/clk/clk-vt8500.c b/drivers/clk/clk-vt8500.c
index 98c4492d2c0d..b0f76a84f1e9 100644
--- a/drivers/clk/clk-vt8500.c
+++ b/drivers/clk/clk-vt8500.c
@@ -355,7 +355,7 @@ CLK_OF_DECLARE(vt8500_device, "via,vt8500-device-clock", vtwm_device_clk_init);
 #define WM8850_BITS_TO_VAL(m, d1, d2)					\
 		((((m / 2) - 1) << 16) | ((d1 - 1) << 8) | d2)
 
-static void vt8500_find_pll_bits(unsigned long rate, unsigned long parent_rate,
+static int vt8500_find_pll_bits(unsigned long rate, unsigned long parent_rate,
 				u32 *multiplier, u32 *prediv)
 {
 	unsigned long tclk;
@@ -365,7 +365,7 @@ static void vt8500_find_pll_bits(unsigned long rate, unsigned long parent_rate,
 		pr_err("%s: requested rate out of range\n", __func__);
 		*multiplier = 0;
 		*prediv = 1;
-		return;
+		return -EINVAL;
 	}
 	if (rate <= parent_rate * 31)
 		/* use the prediv to double the resolution */
@@ -379,9 +379,11 @@ static void vt8500_find_pll_bits(unsigned long rate, unsigned long parent_rate,
 	if (tclk != rate)
 		pr_warn("%s: requested rate %lu, found rate %lu\n", __func__,
 								rate, tclk);
+
+	return 0;
 }
 
-static void wm8650_find_pll_bits(unsigned long rate, unsigned long parent_rate,
+static int wm8650_find_pll_bits(unsigned long rate, unsigned long parent_rate,
 				u32 *multiplier, u32 *divisor1, u32 *divisor2)
 {
 	u32 mul, div1;
@@ -404,7 +406,7 @@ static void wm8650_find_pll_bits(unsigned long rate, unsigned long parent_rate,
 					*multiplier = mul;
 					*divisor1 = div1;
 					*divisor2 = div2;
-					return;
+					return 0;
 				}
 
 				if (rate_err < best_err) {
@@ -415,12 +417,19 @@ static void wm8650_find_pll_bits(unsigned long rate, unsigned long parent_rate,
 				}
 			}
 
+	if (best_err == (unsigned long)-1) {
+		pr_warn("%s: impossible rate %lu\n", __func__, rate);
+		return -EINVAL;
+	}
+
 	/* if we got here, it wasn't an exact match */
 	pr_warn("%s: requested rate %lu, found rate %lu\n", __func__, rate,
 							rate - best_err);
 	*multiplier = best_mul;
 	*divisor1 = best_div1;
 	*divisor2 = best_div2;
+
+	return 0;
 }
 
 static u32 wm8750_get_filter(u32 parent_rate, u32 divisor1)
@@ -450,7 +459,7 @@ static u32 wm8750_get_filter(u32 parent_rate, u32 divisor1)
 	return 0;
 }
 
-static void wm8750_find_pll_bits(unsigned long rate, unsigned long parent_rate,
+static int wm8750_find_pll_bits(unsigned long rate, unsigned long parent_rate,
 				u32 *filter, u32 *multiplier, u32 *divisor1, u32 *divisor2)
 {
 	u32 mul;
@@ -474,7 +483,7 @@ static void wm8750_find_pll_bits(unsigned long rate, unsigned long parent_rate,
 					*multiplier = mul;
 					*divisor1 = div1;
 					*divisor2 = div2;
-					return;
+					return 0;
 				}
 
 				if (rate_err < best_err) {
@@ -485,6 +494,11 @@ static void wm8750_find_pll_bits(unsigned long rate, unsigned long parent_rate,
 				}
 			}
 
+	if (best_err == (unsigned long)-1) {
+		pr_warn("%s: impossible rate %lu\n", __func__, rate);
+		return -EINVAL;
+	}
+
 	/* if we got here, it wasn't an exact match */
 	pr_warn("%s: requested rate %lu, found rate %lu\n", __func__, rate,
 							rate - best_err);
@@ -493,9 +507,11 @@ static void wm8750_find_pll_bits(unsigned long rate, unsigned long parent_rate,
 	*multiplier = best_mul;
 	*divisor1 = best_div1;
 	*divisor2 = best_div2;
+
+	return 0;
 }
 
-static void wm8850_find_pll_bits(unsigned long rate, unsigned long parent_rate,
+static int wm8850_find_pll_bits(unsigned long rate, unsigned long parent_rate,
 				u32 *multiplier, u32 *divisor1, u32 *divisor2)
 {
 	u32 mul;
@@ -519,7 +535,7 @@ static void wm8850_find_pll_bits(unsigned long rate, unsigned long parent_rate,
 					*multiplier = mul;
 					*divisor1 = div1;
 					*divisor2 = div2;
-					return;
+					return 0;
 				}
 
 				if (rate_err < best_err) {
@@ -530,6 +546,11 @@ static void wm8850_find_pll_bits(unsigned long rate, unsigned long parent_rate,
 				}
 			}
 
+	if (best_err == (unsigned long)-1) {
+		pr_warn("%s: impossible rate %lu\n", __func__, rate);
+		return -EINVAL;
+	}
+
 	/* if we got here, it wasn't an exact match */
 	pr_warn("%s: requested rate %lu, found rate %lu\n", __func__, rate,
 							rate - best_err);
@@ -537,6 +558,8 @@ static void wm8850_find_pll_bits(unsigned long rate, unsigned long parent_rate,
 	*multiplier = best_mul;
 	*divisor1 = best_div1;
 	*divisor2 = best_div2;
+
+	return 0;
 }
 
 static int vtwm_pll_set_rate(struct clk_hw *hw, unsigned long rate,
@@ -546,31 +569,39 @@ static int vtwm_pll_set_rate(struct clk_hw *hw, unsigned long rate,
 	u32 filter, mul, div1, div2;
 	u32 pll_val;
 	unsigned long flags = 0;
+	int ret;
 
 	/* sanity check */
 
 	switch (pll->type) {
 	case PLL_TYPE_VT8500:
-		vt8500_find_pll_bits(rate, parent_rate, &mul, &div1);
-		pll_val = VT8500_BITS_TO_VAL(mul, div1);
+		ret = vt8500_find_pll_bits(rate, parent_rate, &mul, &div1);
+		if (!ret)
+			pll_val = VT8500_BITS_TO_VAL(mul, div1);
 		break;
 	case PLL_TYPE_WM8650:
-		wm8650_find_pll_bits(rate, parent_rate, &mul, &div1, &div2);
-		pll_val = WM8650_BITS_TO_VAL(mul, div1, div2);
+		ret = wm8650_find_pll_bits(rate, parent_rate, &mul, &div1, &div2);
+		if (!ret)
+			pll_val = WM8650_BITS_TO_VAL(mul, div1, div2);
 		break;
 	case PLL_TYPE_WM8750:
-		wm8750_find_pll_bits(rate, parent_rate, &filter, &mul, &div1, &div2);
-		pll_val = WM8750_BITS_TO_VAL(filter, mul, div1, div2);
+		ret = wm8750_find_pll_bits(rate, parent_rate, &filter, &mul, &div1, &div2);
+		if (!ret)
+			pll_val = WM8750_BITS_TO_VAL(filter, mul, div1, div2);
 		break;
 	case PLL_TYPE_WM8850:
-		wm8850_find_pll_bits(rate, parent_rate, &mul, &div1, &div2);
-		pll_val = WM8850_BITS_TO_VAL(mul, div1, div2);
+		ret = wm8850_find_pll_bits(rate, parent_rate, &mul, &div1, &div2);
+		if (!ret)
+			pll_val = WM8850_BITS_TO_VAL(mul, div1, div2);
 		break;
 	default:
 		pr_err("%s: invalid pll type\n", __func__);
-		return 0;
+		ret = -EINVAL;
 	}
 
+	if (ret)
+		return ret;
+
 	spin_lock_irqsave(pll->lock, flags);
 
 	vt8500_pmc_wait_busy();
@@ -588,28 +619,36 @@ static long vtwm_pll_round_rate(struct clk_hw *hw, unsigned long rate,
 	struct clk_pll *pll = to_clk_pll(hw);
 	u32 filter, mul, div1, div2;
 	long round_rate;
+	int ret;
 
 	switch (pll->type) {
 	case PLL_TYPE_VT8500:
-		vt8500_find_pll_bits(rate, *prate, &mul, &div1);
-		round_rate = VT8500_BITS_TO_FREQ(*prate, mul, div1);
+		ret = vt8500_find_pll_bits(rate, *prate, &mul, &div1);
+		if (!ret)
+			round_rate = VT8500_BITS_TO_FREQ(*prate, mul, div1);
 		break;
 	case PLL_TYPE_WM8650:
-		wm8650_find_pll_bits(rate, *prate, &mul, &div1, &div2);
-		round_rate = WM8650_BITS_TO_FREQ(*prate, mul, div1, div2);
+		ret = wm8650_find_pll_bits(rate, *prate, &mul, &div1, &div2);
+		if (!ret)
+			round_rate = WM8650_BITS_TO_FREQ(*prate, mul, div1, div2);
 		break;
 	case PLL_TYPE_WM8750:
-		wm8750_find_pll_bits(rate, *prate, &filter, &mul, &div1, &div2);
-		round_rate = WM8750_BITS_TO_FREQ(*prate, mul, div1, div2);
+		ret = wm8750_find_pll_bits(rate, *prate, &filter, &mul, &div1, &div2);
+		if (!ret)
+			round_rate = WM8750_BITS_TO_FREQ(*prate, mul, div1, div2);
 		break;
 	case PLL_TYPE_WM8850:
-		wm8850_find_pll_bits(rate, *prate, &mul, &div1, &div2);
-		round_rate = WM8850_BITS_TO_FREQ(*prate, mul, div1, div2);
+		ret = wm8850_find_pll_bits(rate, *prate, &mul, &div1, &div2);
+		if (!ret)
+			round_rate = WM8850_BITS_TO_FREQ(*prate, mul, div1, div2);
 		break;
 	default:
-		round_rate = 0;
+		ret = -EINVAL;
 	}
 
+	if (ret)
+		return ret;
+
 	return round_rate;
 }
 



From arnd at arndb.de  Mon Feb  1 02:21:46 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 01 Feb 2016 11:21:46 +0100
Subject: [PATCH v4 4/9] pinctrl: Add STM32 MCUs support
In-Reply-To: <CACRpkdaBcP6fC5Oxn+d1WPdHq1FtwMkf8Ap5VDLQFg-5UwEBAw@mail.gmail.com>
References: <1452773795-24216-1-git-send-email-mcoquelin.stm32@gmail.com>
 <1452773795-24216-5-git-send-email-mcoquelin.stm32@gmail.com>
 <CACRpkdaBcP6fC5Oxn+d1WPdHq1FtwMkf8Ap5VDLQFg-5UwEBAw@mail.gmail.com>
Message-ID: <2151471.Wut3mQ9SS7@wuerfel>

On Wednesday 27 January 2016 14:16:32 Linus Walleij wrote:
> On Thu, Jan 14, 2016 at 1:16 PM, Maxime Coquelin
> <mcoquelin.stm32 at gmail.com> wrote:
> 
> > This patch adds pinctrl and GPIO support to STMicroelectronic's STM32
> > family of MCUs.
> >
> > While it only supports STM32F429 for now, it has been designed to enable
> > support of other MCUs of the family (e.g. STM32F746).
> >
> > Acked-by: Patrice Chotard <patrice.chotard at st.com>
> > Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> 
> This patch applied for kernel v4.6.
> 

This breaks the kernel build, please revert:

drivers/pinctrl/stm32/pinctrl-stm32.c:26:47: fatal error: dt-bindings/pinctrl/pinctrl-stm32.h: No such file or directory


	Arnd


From djkurtz at chromium.org  Mon Feb  1 02:22:29 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Mon, 1 Feb 2016 18:22:29 +0800
Subject: [RFC 3/3] CMDQ: Mediatek CMDQ driver
In-Reply-To: <1454307624.22441.18.camel@mtksdaap41>
References: <1453266881-16849-1-git-send-email-hs.liao@mediatek.com>
 <1453266881-16849-4-git-send-email-hs.liao@mediatek.com>
 <CAGS+omBjD1pXKY_6bFbiGxa5bttvqg5zEvKevzSfoiMOy7ys6Q@mail.gmail.com>
 <1454053150.32413.52.camel@mtksdaap41>
 <CAGS+omBrEE21Xxh8hjcf32qfHJE0jJYvxGP6L1ihS6jcNbLvLQ@mail.gmail.com>
 <1454070262.7401.21.camel@mtksdaap41>
 <CAGS+omBhs7Ks7MVDsxHBBUdgF+0fmAa465HwvNiCzEe97Knt3Q@mail.gmail.com>
 <1454292257.22270.3.camel@mtksdaap41>
 <CAGS+omCzDisk2TfbDnWiXufWgUsCbhF_JFafaUazhSymX-MT_Q@mail.gmail.com>
 <1454307624.22441.18.camel@mtksdaap41>
Message-ID: <CAGS+omB7d3Kq1DKNHxZJjLDmin0rpkDj1kEde3zCxTiT5-xZWw@mail.gmail.com>

On Mon, Feb 1, 2016 at 2:20 PM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
> On Mon, 2016-02-01 at 12:15 +0800, Daniel Kurtz wrote:
>> On Mon, Feb 1, 2016 at 10:04 AM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
>> >
>> > On Fri, 2016-01-29 at 21:15 +0800, Daniel Kurtz wrote:
>> > > On Fri, Jan 29, 2016 at 8:24 PM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
>> > > > On Fri, 2016-01-29 at 16:42 +0800, Daniel Kurtz wrote:
>> > > >> On Fri, Jan 29, 2016 at 3:39 PM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
>> > > >> > Hi Dan,
>> > > >> >
>> > > >> > Many thanks for your comments and time.
>> > > >> > I reply my plan inline.
>> > > >> >
>> > > >> >
>> > > >> > On Thu, 2016-01-28 at 12:49 +0800, Daniel Kurtz wrote:
>> > > >> >> Hi HS,
>> > > >> >>
>> > > >> >> Sorry for the delay.  It is hard to find time to review a >3700 line
>> > > >> >> driver :-o in detail....
>> > > >> >>
>> > > >> >> Some review comments inline, although I still do not completely
>> > > >> >> understand how all that this driver does and how it works.
>> > > >> >> I'll try to find time to go through this driver in detail again next
>> > > >> >> time you post it for review.
>> > > >> >>
>> > > >> >> On Tue, Jan 19, 2016 at 9:14 PM,  <hs.liao at mediatek.com> wrote:
>> > > >> >> > From: HS Liao <hs.liao at mediatek.com>
>> > > >> >> >
>> > > >> >> > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
>> > > >> >> > CMDQ is used to help read/write registers with critical time limitation,
>> > > >> >> > such as updating display configuration during the vblank. It controls
>> > > >> >> > Global Command Engine (GCE) hardware to achieve this requirement.
>> > > >> >> > Currently, CMDQ only supports display related hardwares, but we expect
>> > > >> >> > it can be extended to other hardwares for future requirements.
>> > > >> >> >
>> > > >> >> > Signed-off-by: HS Liao <hs.liao at mediatek.com>
>> > > >> >>
>> > > >> >> [snip]
>> > > >> >>
>> > > >> >> > diff --git a/drivers/soc/mediatek/mtk-cmdq.c b/drivers/soc/mediatek/mtk-cmdq.c
>> > > >> >> > new file mode 100644
>> > > >> >> > index 0000000..7570f00
>> > > >> >> > --- /dev/null
>> > > >> >> > +++ b/drivers/soc/mediatek/mtk-cmdq.c
>> > > >
>> > > > [snip]
>> > > >
>> > > >> >> > +static const struct cmdq_subsys g_subsys[] = {
>> > > >> >> > +       {0x1400, 1, "MMSYS"},
>> > > >> >> > +       {0x1401, 2, "DISP"},
>> > > >> >> > +       {0x1402, 3, "DISP"},
>> > > >> >>
>> > > >> >> This isn't going to scale.  These addresses could be different on
>> > > >> >> different chips.
>> > > >> >> Instead of a static table like this, we probably need specify to the
>> > > >> >> connection between gce and other devices via devicetree phandles, and
>> > > >> >> then use the phandles to lookup the corresponding device address
>> > > >> >> range.
>> > > >> >
>> > > >> > I will define them in device tree.
>> > > >> > E.g.
>> > > >> > cmdq {
>> > > >> >   reg_domain = 0x14000000, 0x14010000, 0x14020000
>> > > >> > }
>> > > >>
>> > > >> The devicetree should only model hardware relationships, not software
>> > > >> considerations.
>> > > >>
>> > > >> Is the hardware constraint here for using gce with various other
>> > > >> hardware blocks?  I think we already model this by only providing a
>> > > >> gce phandle in the device tree nodes for those devices that can use
>> > > >> gce.
>> > > >>
>> > > >> Looking at the driver closer, as far as I can tell, the whole subsys
>> > > >> concept is a purely software abstraction, and only used to debug the
>> > > >> CMDQ_CODE_WRITE command.  In fact, AFAICT, everything would work fine
>> > > >> if we just completely removed the 'subsys' concept, and just passed
>> > > >> through the raw address provided by the driver.
>> > > >>
>> > > >> So, I recommend just removing 'subsys' completely from the driver -
>> > > >> from this array, and in the masks.
>> > > >>
>> > > >> Instead, if there is an error on the write command, just print the
>> > > >> address that fails.  There are other ways to deduce the subsystem from
>> > > >> a physical address.
>> > > >>
>> > > >> Thanks,
>> > > >>
>> > > >> -Dan
>> > > >
>> > > > Hi Dan,
>> > > >
>> > > > Subsys is not just for debug.
>> > > > Its main purpose is to transfer CPU address to GCE address.
>> > > > Let me explain it by "write" op,
>> > > > I list a code segment from cmdq_rec_append_command().
>> > > >
>> > > >         case CMDQ_CODE_WRITE:
>> > > >                 subsys = cmdq_subsys_from_phys_addr(cqctx, arg_a);
>> > > >                 if (subsys < 0) {
>> > > >                         dev_err(dev,
>> > > >                                 "unsupported memory base address 0x%08x\n",
>> > > >                                 arg_a);
>> > > >                         return -EFAULT;
>> > > >                 }
>> > > >
>> > > >                 *cmd_ptr++ = arg_b;
>> > > >                 *cmd_ptr++ = (CMDQ_CODE_WRITE << CMDQ_OP_CODE_SHIFT) |
>> > > >                              (arg_a & CMDQ_ARG_A_WRITE_MASK) |
>> > > >                              ((subsys & CMDQ_SUBSYS_MASK) << CMDQ_SUBSYS_SHIFT);
>> > > >                 break;
>> > > >
>> > > > Subsys is mapped from physical address via cmdq_subsys_from_phys_addr(),
>> > > > and then it becomes part of GCE command via ((subsys & CMDQ_SUBSYS_MASK)
>> > > > << CMDQ_SUBSYS_SHIFT) .
>> > > > Only low bits of physical address are the same as GCE address.
>> > > > We can get it by (arg_a & CMDQ_ARG_A_WRITE_MASK).
>> > > > MASK is used to define how many bits are valid for this op.
>> > > > So, GCE address = subsys + valid low bits.
>> > >
>> > > How are these upper bits of the "GCE address" defined?
>> > > In other words, for a given SoC, how is the mapping between physical
>> > > io addresses to GCE addresses defined?
>> > > Is this mapping fixed by hardware?
>>
>> Please answer the detailed technical questions:
>>
>> How are these upper bits of the "GCE address" defined?
>
> A GCE command is arg_a + arg_b. Both of them have 32 bits length.
> arg_a is op + subsys + addr, and arg_b is value.
> subsys + addr is less than 32bits, so we need to map address range to
> subsys.
> The mapping rule is defined by hardware.
>
>> In other words, for a given SoC, how is the mapping between physical
>> io addresses to GCE addresses defined?
>
> It is (b).
>
>>
>> (a) Does the GCE remap a continuous device IO address range?
>>
>> AFAICT, the  defines an MT8173 specific mapping of:
>>
>> For example, the g_subsys table above seems to imply that the MT8173
>> gce maps all of:
>>   0x1400ffff:0x141fffff => 0x010000:0x1fffff
>>
>> (b) Or, are the upper 5 bits of the "gce address" significant, and via
>> hardware it can map a disjoint groups of device addresses into the
>> continuous GCE address space, and really there are 0x1f distinct 64k
>> mappings:
>>
>> mmsys (1) : 0x14000000:0x1400ffff => 0x010000:0x01ffff
>> disp  (2) : 0x14010000:0x1401ffff => 0x020000:0x02ffff
>> disp  (3) : 0x14020000:0x1402ffff => 0x030000:0x03ffff
>> ...
>> ???? (1f) : 0x141fffff:0x141fffff => 0x1f0000:0x1fffff
>>
>> If the mapping is fixed and continuous (a), then I think all we need
>> is a single dts entry for the gce node that describes how it performs
>> this mapping.  And then, the gce consumers can just pass in their
>> regular physical addresses, and the gce driver can remap them directly
>> to gce addresses.
>>
>> WDYT?
>
> How about this?
> hardware_module = <address_base subsys_id mask>;
> So, the result is
> mmsys_config_base = <0x14000000 1 0xffff0000>;
> disp_rdma_config_base = <0x14010000 2 0xffff0000>;
> disp_mutex_config_base = <0x14020000 3 0xffff0000>;

What uses ID 0 and 4 - 0x1f?

According to mt8173.dtsi, here are the blocks in the address ranges above:

@1400:
  mmsys: clock-controller at 14000000
  ovl0: ovl at 1400c000
  ovl1: ovl at 1400d000
  rdma0: rdma at 1400e000
  rdma1: rdma at 1400f000

@1401:
  rdma2: rdma at 14010000
  wdma0: wdma at 14011000
  wdma1: wdma at 14012000
  color0: color at 14013000
  color1: color at 14014000
  aal at 14015000
  gamma at 14016000
  merge at 14017000
  split0: split at 14018000
  split1: split at 14019000
  ufoe at 1401a000
  dsi0: dsi at 1401b000
  dsi1: dsi at 1401c000
  dpi0: dpi at 1401d000
  pwm0: pwm at 1401e000
  pwm1: pwm at 1401f000

@1402:
  mutex: mutex at 14020000
  od at 14023000
  larb0: larb at 14021000
  smi_common: smi at 14022000
  hdmi0: hdmi at 14025000
  larb4: larb at 14027000

I assume that the gce will work with any of the devices in those
ranges, not just "mmsys", "rdma" and "mutex", right?   (Also, notice
there are two "rdma" in the @1400 range, so rdma is really not a good
name for @1401)

Further, it looks like the gce just maps a large device address range
starting at 0x14000000 to (21-bit) gce address 0x010000, rather than
31 individually addressable 64k "subsys" blocks.  Is there a counter
example that I am missing?

-Dan

>
>> -Dan
>>
>> >
>> > Yes, this mapping is fixed by hardware.
>> >
>> > > Does it vary for different SoCs?
>> >
>> > Yes, it varies for different SoCs.
>> >
>> > >
>> > > -Dan
>> > >
>> > > > That's why we need to know the mapping between the range of physical
>> > > > address and subsys.
>> > > > Please guide us a better way to code such requirement.
>> > > > Thanks for your help.
>> > > >
>> > > > Thanks,
>> > > > HS Liao
>> > > >
>> >
>> > Thanks,
>> > HS Liao
>> >
>
> Thanks,
> HS Liao
>


From gregory.clement at free-electrons.com  Mon Feb  1 02:22:45 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 01 Feb 2016 11:22:45 +0100
Subject: [PATCH net 5/6] net: mvneta: The mvneta_percpu_elect function
 should be atomic
In-Reply-To: <20160129.203810.1601035648854177084.davem@davemloft.net> (David
 Miller's message of "Fri, 29 Jan 2016 20:38:10 -0800 (PST)")
References: <1454084767-24715-1-git-send-email-gregory.clement@free-electrons.com>
 <1454084767-24715-6-git-send-email-gregory.clement@free-electrons.com>
 <20160129.203810.1601035648854177084.davem@davemloft.net>
Message-ID: <87h9hs7mru.fsf@free-electrons.com>

Hi David,
 
 On sam., janv. 30 2016, David Miller <davem at davemloft.net> wrote:

> From: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Date: Fri, 29 Jan 2016 17:26:06 +0100
>
>> @@ -370,6 +370,8 @@ struct mvneta_port {
>>  	struct net_device *dev;
>>  	struct notifier_block cpu_notifier;
>>  	int rxq_def;
>> +	/* protect  */
>> +	spinlock_t lock;
>>  
>>  	/* Core clock */
>>  	struct clk *clk;
>
> Protect what?  This comment needs a lot of improvement.

Sorry about it, this was a left-over.

>
> Everyone knows a spinlock "protects" things, so if you aren't going
> to actually describe what this lock protects, and in what contexts
> the lock is used, you might as well not say anything at all.

I can only agree with you, I will fix it for next version.

Thanks,

Gregory


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From matthias.bgg at gmail.com  Mon Feb  1 02:23:34 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 1 Feb 2016 11:23:34 +0100
Subject: [PATCH v2 0/3] Mediatek EFUSE Support
In-Reply-To: <56A0EFEA.506@linaro.org>
References: <1447930014-19579-1-git-send-email-andrew-ct.chen@mediatek.com>
 <CAGS+omA8XK6ksd7Ma8yAUbkSsHR6yQxjFrV+HGbd83UiH6T51g@mail.gmail.com>
 <566E94CA.1050700@linaro.org> <56A0A5E1.5050105@gmail.com>
 <56A0EBF0.2020703@linaro.org> <56A0EF61.5080500@gmail.com>
 <56A0EFEA.506@linaro.org>
Message-ID: <56AF3226.2070304@gmail.com>



On 21/01/16 15:49, Srinivas Kandagatla wrote:
>
>
> On 21/01/16 14:46, Matthias Brugger wrote:
>>
>>
>> On 21/01/16 15:32, Srinivas Kandagatla wrote:
>>>
>>>
>>> On 21/01/16 09:33, Matthias Brugger wrote:
>>>>
>>>>
>>>> On 14/12/15 11:07, Srinivas Kandagatla wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> On 14/12/15 04:27, Daniel Kurtz wrote:
>>>>>> Hi Srinivas,
>>>>>>
>>>>>> On Thu, Nov 19, 2015 at 6:46 PM, Andrew-CT Chen
>>>>>> <andrew-ct.chen at mediatek.com> wrote:
>>>>>>> This patch adds EFUSE support driver which is used by other drivers
>>>>>>> like thermal sensor and HDMI impedance.
>>>>>>>
>>>>>>> There are some efuses these fuses store things like calibration
>>>>>>> data,
>>>>>>> speed bins.. etc. Drivers like thermal sensor, HDMI impedance would
>>>>>>> read out this data for configuring the driver.
>>>>>>>
>>>>>>> Change in v2:
>>>>>>> 1. Rebase to 4.4-rc1
>>>>>>> 2. Modify the driver Makefile for more consistent with other drivers
>>>>>>> 3. Modify the compatible string to "mediatek,mt8173-efuse" and
>>>>>>> "mediatek,efuse"
>>>>>>
>>>>>> Do you still plan to queue this for v4.5?
>>>>>>
>>>>> Sorry guys, for the long delay in replying your pings, got busy with
>>>>> regular office stuff :-)
>>>>>
>>>>> Yes, It should go in v4.5, I did send request with my sign-off to
>>>>> Greg,
>>>>> he should take it via char-misc tree.
>>>>>
>>>>
>>>> I can't see this patches in the char-misc tree [1].
>>>> Can you please double check?
>>>
>>> Hi Matthias,
>>> Thanks for the patience. You should expect them to see after v4.5-rc1,
>>> that's when Greg said he would push the patches.
>>>
>>
>> I'm a bit puzzled. Wouldn't that mean that they will get into mainline
>> for v4.6.
>
> The delay was due to Christmas holidays, this driver is 4.5 material, so
> it would endup in v4.5-rc2 instead of v4.5-rc1.

Sorry for bothering you on this again, but I just checked v4.5-rc2 and 
it is not present. I don't see it in char-misc-[next,testing] neither.

Looks like as if this patch got forgotten. Can you please check.

Regards,
Matthias

>
> thanks
> srini
>> I just want to know if I can take patch 3/3 through my v4.5-next branch
>> (which eventually will be merged into v4.6-rc1) or if I have to wait.
>
>>
>> Thanks,
>> Matthias


From mark.rutland at arm.com  Mon Feb  1 02:23:45 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 1 Feb 2016 10:23:45 +0000
Subject: [PATCH] arm64: mm: dump: Use VA_START directly instead of
 private LOWEST_ADDR
In-Reply-To: <1454140521-741-1-git-send-email-wangkefeng.wang@huawei.com>
References: <1454140521-741-1-git-send-email-wangkefeng.wang@huawei.com>
Message-ID: <20160201102345.GB674@leverpostej>

On Sat, Jan 30, 2016 at 03:55:21PM +0800, Kefeng Wang wrote:
> Use VA_START macro in asm/memory.h instead of private LOWEST_ADDR
> definition in dump.c.
> 
> Signed-off-by: Kefeng Wang <wangkefeng.wang at huawei.com>

FWIW:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Mark.

> ---
>  arch/arm64/mm/dump.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index 0adbebb..b3c62b1 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -27,8 +27,6 @@
>  #include <asm/pgtable.h>
>  #include <asm/pgtable-hwdef.h>
>  
> -#define LOWEST_ADDR	(UL(0xffffffffffffffff) << VA_BITS)
> -
>  struct addr_marker {
>  	unsigned long start_address;
>  	const char *name;
> @@ -316,7 +314,7 @@ static int ptdump_show(struct seq_file *m, void *v)
>  		.marker = address_markers,
>  	};
>  
> -	walk_pgd(&st, &init_mm, LOWEST_ADDR);
> +	walk_pgd(&st, &init_mm, VA_START);
>  
>  	note_page(&st, 0, 0, 0);
>  	return 0;
> -- 
> 2.6.0.GIT
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From matthias.bgg at gmail.com  Mon Feb  1 02:28:39 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 1 Feb 2016 11:28:39 +0100
Subject: [PATCH] soc: mediatek: SCPSYS: Fix double enabling of regulators
In-Reply-To: <CAGS+omD=ZdLoT8fZ_vq4CvdCvAwsz2tbdEzS5Q8pAL5zAKW5yA@mail.gmail.com>
References: <1453466365-24406-1-git-send-email-s.hauer@pengutronix.de>
 <CAGS+omD=ZdLoT8fZ_vq4CvdCvAwsz2tbdEzS5Q8pAL5zAKW5yA@mail.gmail.com>
Message-ID: <56AF3357.1040707@gmail.com>



On 22/01/16 20:26, Daniel Kurtz wrote:
> On Fri, Jan 22, 2016 at 4:39 AM, Sascha Hauer<s.hauer at pengutronix.de>  wrote:
>> >
>> >With CONFIG_PM enabled do not call genpd->power_on manually as this
>> >will cause the regulators being turned on once in SCPSYS probe and
>> >then again when the genpd core turns on the domains. Instead, call
>> >genpd->power_on only with CONFIG_PM disabled and tell the genpd core
>> >that the domains are disabled when registered.
>> >
>> >Signed-off-by: Sascha Hauer<s.hauer at pengutronix.de>
> Take your pick:
> Tested-by: Daniel Kurtz<djkurtz at chromium.org>
> Reviewed-by: Daniel Kurtz<djkurtz at chromium.org>
>
>> >---

Applied, thanks.


From srinivas.kandagatla at linaro.org  Mon Feb  1 02:33:12 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Mon, 1 Feb 2016 10:33:12 +0000
Subject: [PATCH 0/4] nvmem: new drivers for v4.5
In-Reply-To: <20160111183018.GA10243@kroah.com>
References: <1449485763-391-1-git-send-email-srinivas.kandagatla@linaro.org>
 <5693AC68.6040802@linaro.org> <20160111183018.GA10243@kroah.com>
Message-ID: <56AF3468.2020806@linaro.org>

Hi Greg,

On 11/01/16 18:30, Greg KH wrote:
> On Mon, Jan 11, 2016 at 01:21:44PM +0000, Srinivas Kandagatla wrote:
>>
>>
>> On 07/12/15 10:56, Srinivas Kandagatla wrote:
>>> Hi Greg,
>>>
>>> Here are 2 new nvmem drivers which are in the mailing list for long time
>>> and are good to go for some testing and find its way to v4.5-rc*.
>>>
>>> Could you please take these patches via char-misc tree.
>> Hi Greg,
>>
>> I have not seen these patches or https://lkml.org/lkml/2015/12/14/169 appear
>> in your char-misc tree/linux-next.
>>
>> Just wanted to know whats your plan on these patches?
>
> To wait until after 4.5-rc1 is out, sorry, my patch backlog got huge
> during Nov/Dec due to other external issues, I'll be digging out from
> them after 4.5-rc1 is out.

Am not sure if this was forgotten, just wanted know if you still have 
plans to pick this series for any rc on 4.5?


thanks,
srini

>
> thanks,
>
> greg k-h
>


From arnd at arndb.de  Mon Feb  1 02:33:00 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 01 Feb 2016 11:33 +0100
Subject: [PATCH] staging: goldfish: use div64_s64 instead of do_div
Message-ID: <1676170.0qik6mzm6D@wuerfel>

The goldfish nand driver divides a signed 64-bit number (loff_t)
in multiple places using the do_div() function. This has always
been unreliable but now produces a compiler warning (since 4.5-rc1):

goldfish/goldfish_nand.c: In function 'goldfish_nand_erase':
goldfish/goldfish_nand.c:107:91: error: comparison of distinct pointer types lacks a cast [-Werror]
goldfish/goldfish_nand.c: In function 'goldfish_nand_read_oob':
goldfish/goldfish_nand.c:145:91: error: comparison of distinct pointer types lacks a cast [-Werror]

This changes the code to the equivalent div_s64{,_rem} that
works correctly for negative numbers (which we should never
get here).

The warning has shown up on ARM allmodconfig builds after the goldfish
bus driver has become visible on ARM.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: bd2f348db503 ("goldfish: refactor goldfish platform configs")

diff --git a/drivers/staging/goldfish/goldfish_nand.c b/drivers/staging/goldfish/goldfish_nand.c
index f223b3a5a428..76d60eed1490 100644
--- a/drivers/staging/goldfish/goldfish_nand.c
+++ b/drivers/staging/goldfish/goldfish_nand.c
@@ -100,11 +100,11 @@ static int goldfish_nand_erase(struct mtd_info *mtd, struct erase_info *instr)
 {
 	loff_t ofs = instr->addr;
 	u32 len = instr->len;
-	u32 rem;
+	s32 rem;
 
 	if (ofs + len > mtd->size)
 		goto invalid_arg;
-	rem = do_div(ofs, mtd->writesize);
+	ofs = div_s64_rem(ofs, mtd->writesize, &rem);
 	if (rem)
 		goto invalid_arg;
 	ofs *= (mtd->writesize + mtd->oobsize);
@@ -133,7 +133,7 @@ invalid_arg:
 static int goldfish_nand_read_oob(struct mtd_info *mtd, loff_t ofs,
 				  struct mtd_oob_ops *ops)
 {
-	u32 rem;
+	s32 rem;
 
 	if (ofs + ops->len > mtd->size)
 		goto invalid_arg;
@@ -142,7 +142,7 @@ static int goldfish_nand_read_oob(struct mtd_info *mtd, loff_t ofs,
 	if (ops->ooblen + ops->ooboffs > mtd->oobsize)
 		goto invalid_arg;
 
-	rem = do_div(ofs, mtd->writesize);
+	ofs = div_s64_rem(ofs, mtd->writesize, &rem);
 	if (rem)
 		goto invalid_arg;
 	ofs *= (mtd->writesize + mtd->oobsize);
@@ -165,7 +165,7 @@ invalid_arg:
 static int goldfish_nand_write_oob(struct mtd_info *mtd, loff_t ofs,
 				   struct mtd_oob_ops *ops)
 {
-	u32 rem;
+	s32 rem;
 
 	if (ofs + ops->len > mtd->size)
 		goto invalid_arg;
@@ -174,7 +174,7 @@ static int goldfish_nand_write_oob(struct mtd_info *mtd, loff_t ofs,
 	if (ops->ooblen + ops->ooboffs > mtd->oobsize)
 		goto invalid_arg;
 
-	rem = do_div(ofs, mtd->writesize);
+	ofs = div_s64_rem(ofs, mtd->writesize, &rem);
 	if (rem)
 		goto invalid_arg;
 	ofs *= (mtd->writesize + mtd->oobsize);
@@ -197,12 +197,12 @@ invalid_arg:
 static int goldfish_nand_read(struct mtd_info *mtd, loff_t from, size_t len,
 			      size_t *retlen, u_char *buf)
 {
-	u32 rem;
+	s32 rem;
 
 	if (from + len > mtd->size)
 		goto invalid_arg;
 
-	rem = do_div(from, mtd->writesize);
+	from = div_s64_rem(from, mtd->writesize, &rem);
 	if (rem)
 		goto invalid_arg;
 	from *= (mtd->writesize + mtd->oobsize);
@@ -219,12 +219,12 @@ invalid_arg:
 static int goldfish_nand_write(struct mtd_info *mtd, loff_t to, size_t len,
 			       size_t *retlen, const u_char *buf)
 {
-	u32 rem;
+	s32 rem;
 
 	if (to + len > mtd->size)
 		goto invalid_arg;
 
-	rem = do_div(to, mtd->writesize);
+	to = div_s64_rem(to, mtd->writesize, &rem);
 	if (rem)
 		goto invalid_arg;
 	to *= (mtd->writesize + mtd->oobsize);
@@ -240,12 +240,12 @@ invalid_arg:
 
 static int goldfish_nand_block_isbad(struct mtd_info *mtd, loff_t ofs)
 {
-	u32 rem;
+	s32 rem;
 
 	if (ofs >= mtd->size)
 		goto invalid_arg;
 
-	rem = do_div(ofs, mtd->erasesize);
+	ofs = div_s64_rem(ofs, mtd->writesize, &rem);
 	if (rem)
 		goto invalid_arg;
 	ofs *= mtd->erasesize / mtd->writesize;
@@ -261,12 +261,12 @@ invalid_arg:
 
 static int goldfish_nand_block_markbad(struct mtd_info *mtd, loff_t ofs)
 {
-	u32 rem;
+	s32 rem;
 
 	if (ofs >= mtd->size)
 		goto invalid_arg;
 
-	rem = do_div(ofs, mtd->erasesize);
+	ofs = div_s64_rem(ofs, mtd->writesize, &rem);
 	if (rem)
 		goto invalid_arg;
 	ofs *= mtd->erasesize / mtd->writesize;
@@ -321,7 +321,7 @@ static int goldfish_nand_init_device(struct platform_device *pdev,
 	mtd->oobavail = mtd->oobsize;
 	mtd->erasesize = readl(base + NAND_DEV_ERASE_SIZE) /
 			(mtd->writesize + mtd->oobsize) * mtd->writesize;
-	do_div(mtd->size, mtd->writesize + mtd->oobsize);
+	mtd->size = div_s64(mtd->size, mtd->writesize + mtd->oobsize);
 	mtd->size *= mtd->writesize;
 	dev_dbg(&pdev->dev,
 		"goldfish nand dev%d: size %llx, page %d, extra %d, erase %d\n",


From mcoquelin.stm32 at gmail.com  Mon Feb  1 02:39:31 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Mon, 1 Feb 2016 11:39:31 +0100
Subject: [PATCH v4 4/9] pinctrl: Add STM32 MCUs support
In-Reply-To: <2151471.Wut3mQ9SS7@wuerfel>
References: <1452773795-24216-1-git-send-email-mcoquelin.stm32@gmail.com>
 <1452773795-24216-5-git-send-email-mcoquelin.stm32@gmail.com>
 <CACRpkdaBcP6fC5Oxn+d1WPdHq1FtwMkf8Ap5VDLQFg-5UwEBAw@mail.gmail.com>
 <2151471.Wut3mQ9SS7@wuerfel>
Message-ID: <CALszF6DTpcU8jFwA0HL8LpkxfO5ZOdFmpHBUxA7WfYgAj_uFhg@mail.gmail.com>

2016-02-01 11:21 GMT+01:00 Arnd Bergmann <arnd at arndb.de>:
> On Wednesday 27 January 2016 14:16:32 Linus Walleij wrote:
>> On Thu, Jan 14, 2016 at 1:16 PM, Maxime Coquelin
>> <mcoquelin.stm32 at gmail.com> wrote:
>>
>> > This patch adds pinctrl and GPIO support to STMicroelectronic's STM32
>> > family of MCUs.
>> >
>> > While it only supports STM32F429 for now, it has been designed to enable
>> > support of other MCUs of the family (e.g. STM32F746).
>> >
>> > Acked-by: Patrice Chotard <patrice.chotard at st.com>
>> > Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
>>
>> This patch applied for kernel v4.6.
>>
>
> This breaks the kernel build, please revert:
>
> drivers/pinctrl/stm32/pinctrl-stm32.c:26:47: fatal error: dt-bindings/pinctrl/pinctrl-stm32.h: No such file or directory

Right, I missed to notify this dependency to Linus, sorry about that.
This dependency is no more needed, so I could just move the macros to
the driver side.

Note that I also noticed a breakage at build time due to field
renaming in gpio_chip structure (dev -> parent).

I propose to rebase the series and move the defines into the driver.
Is it ok for you?

Regards,
Maxime


From matthias.bgg at gmail.com  Mon Feb  1 02:43:11 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 1 Feb 2016 11:43:11 +0100
Subject: [PATCH V3 04/11] soc: mediatek: PMIC wrap: split SoC specific
 init into callback
In-Reply-To: <1453715604-36856-5-git-send-email-blogic@openwrt.org>
References: <1453715604-36856-1-git-send-email-blogic@openwrt.org>
 <1453715604-36856-5-git-send-email-blogic@openwrt.org>
Message-ID: <56AF36BF.2050109@gmail.com>



On 25/01/16 10:53, John Crispin wrote:
> This patch moves the SoC specific wrapper init code into separate callback
> to avoid pwrap_init() getting too large.
>
> Signed-off-by: John Crispin <blogic at openwrt.org>
> ---
>   drivers/soc/mediatek/mtk-pmic-wrap.c |   68 +++++++++++++++++++++-------------
>   1 file changed, 42 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index b22b664..ab2202d 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -372,6 +372,7 @@ struct pmic_wrapper_type {
>   	enum pwrap_type type;
>   	u32 arb_en_all;
>   	int (*init_reg_clock)(struct pmic_wrapper *wrp);
> +	int (*init_special)(struct pmic_wrapper *wrp);
>   };
>
>   static inline int pwrap_is_mt8135(struct pmic_wrapper *wrp)
> @@ -665,6 +666,41 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
>   	return 0;
>   }
>
> +static int pwrap_mt8135_init_special(struct pmic_wrapper *wrp)
> +{
> +	/* enable pwrap events and pwrap bridge in AP side */
> +	pwrap_writel(wrp, 0x1, PWRAP_EVENT_IN_EN);
> +	pwrap_writel(wrp, 0xffff, PWRAP_EVENT_DST_EN);
> +	writel(0x7f, wrp->bridge_base + PWRAP_MT8135_BRIDGE_IORD_ARB_EN);
> +	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS3_EN);
> +	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS4_EN);
> +	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_UNIT);
> +	writel(0xffff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_SRC_EN);
> +	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_TIMER_EN);
> +	writel(0x7ff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INT_EN);
> +
> +	/* enable PMIC event out and sources */
> +	if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
> +		pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
> +		dev_err(wrp->dev, "enable dewrap fail\n");
> +		return -EFAULT;
> +	}
> +
> +	return 0;
> +}
> +
> +static int pwrap_mt8173_init_special(struct pmic_wrapper *wrp)
> +{
> +	/* PMIC_DEWRAP enables */
> +	if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
> +		pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
> +		dev_err(wrp->dev, "enable dewrap fail\n");
> +		return -EFAULT;
> +	}
> +
> +	return 0;
> +}
> +
>   static int pwrap_init(struct pmic_wrapper *wrp)
>   {
>   	int ret;
> @@ -743,32 +779,10 @@ static int pwrap_init(struct pmic_wrapper *wrp)
>   	pwrap_writel(wrp, 0x5, PWRAP_STAUPD_PRD);
>   	pwrap_writel(wrp, 0xff, PWRAP_STAUPD_GRPEN);
>
> -	if (pwrap_is_mt8135(wrp)) {
> -		/* enable pwrap events and pwrap bridge in AP side */
> -		pwrap_writel(wrp, 0x1, PWRAP_EVENT_IN_EN);
> -		pwrap_writel(wrp, 0xffff, PWRAP_EVENT_DST_EN);
> -		writel(0x7f, wrp->bridge_base + PWRAP_MT8135_BRIDGE_IORD_ARB_EN);
> -		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS3_EN);
> -		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS4_EN);
> -		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_UNIT);
> -		writel(0xffff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_SRC_EN);
> -		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_TIMER_EN);
> -		writel(0x7ff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INT_EN);
> -
> -		/* enable PMIC event out and sources */
> -		if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
> -				pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
> -			dev_err(wrp->dev, "enable dewrap fail\n");
> -			return -EFAULT;
> -		}
> -	} else {
> -		/* PMIC_DEWRAP enables */
> -		if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
> -				pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
> -			dev_err(wrp->dev, "enable dewrap fail\n");
> -			return -EFAULT;
> -		}
> -	}
> +	if (wrp->master->init_special)
> +		ret = wrp->master->init_special(wrp);
> +	if (ret)
> +		return ret;
>

Check ret only if you have called init_special before.

Apart from that the patch look fine.


From matthias.bgg at gmail.com  Mon Feb  1 02:48:36 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 1 Feb 2016 11:48:36 +0100
Subject: [PATCH V3 05/11] soc: mediatek: PMIC wrap: WRAP_INT_EN needs a
 different bitmask for MT2701/7623
In-Reply-To: <1453715604-36856-6-git-send-email-blogic@openwrt.org>
References: <1453715604-36856-1-git-send-email-blogic@openwrt.org>
 <1453715604-36856-6-git-send-email-blogic@openwrt.org>
Message-ID: <56AF3804.6070205@gmail.com>



On 25/01/16 10:53, John Crispin wrote:
> MT2701 and MT7623 use a different bitmask for PWRAP_INT_EN.
>
> Signed-off-by: John Crispin <blogic at openwrt.org>
> ---
>   drivers/soc/mediatek/mtk-pmic-wrap.c |    5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index ab2202d..948fc73 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -371,6 +371,7 @@ struct pmic_wrapper_type {
>   	int *regs;
>   	enum pwrap_type type;
>   	u32 arb_en_all;
> +	u32 int_en_all;
>   	int (*init_reg_clock)(struct pmic_wrapper *wrp);
>   	int (*init_special)(struct pmic_wrapper *wrp);
>   };
> @@ -824,6 +825,7 @@ static struct pmic_wrapper_type pwrap_mt8135 = {
>   	.regs = mt8135_regs,
>   	.type = PWRAP_MT8135,
>   	.arb_en_all = 0x1ff,
> +	.int_en_all = BIT(31) | BIT(1),
>   	.init_reg_clock = pwrap_mt8135_init_reg_clock,
>   	.init_special = pwrap_mt8135_init_special,
>   };
> @@ -832,6 +834,7 @@ static struct pmic_wrapper_type pwrap_mt8173 = {
>   	.regs = mt8173_regs,
>   	.type = PWRAP_MT8173,
>   	.arb_en_all = 0x3f,
> +	.int_en_all = BIT(31) | BIT(1),
>   	.init_reg_clock = pwrap_mt8173_init_reg_clock,
>   	.init_special = pwrap_mt8173_init_special,
>   };
> @@ -945,7 +948,7 @@ static int pwrap_probe(struct platform_device *pdev)
>   			PWRAP_WDT_SRC_MASK_NO_STAUPD : PWRAP_WDT_SRC_MASK_ALL;
>   	pwrap_writel(wrp, wdt_src, PWRAP_WDT_SRC_EN);
>   	pwrap_writel(wrp, 0x1, PWRAP_TIMER_EN);
> -	pwrap_writel(wrp, ~((1 << 31) | (1 << 1)), PWRAP_INT_EN);
> +	pwrap_writel(wrp, ~wrp->master->int_en_all, PWRAP_INT_EN);
>

Set the right value in int_en_all instead of use the bitwise not in 
pwrap_writel.


From ard.biesheuvel at linaro.org  Mon Feb  1 02:54:45 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 11:54:45 +0100
Subject: [PATCH v5sub1 0/8] arm64: split linear and kernel mappings
Message-ID: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>

At the request of Catalin, this series has been split off from my series
'arm64: implement support for KASLR v4' [1]. This sub-series deals with
moving the kernel out of the linear mapping into the vmalloc area. This
is a prerequisite for independent physical and virtual randomization of
the kernel image. On top of that, considering that these changes allow
the linear mapping to start at an arbitrary offset above PAGE_OFFSET, it
should be an improvement in itself due to the fact that we can now choose
PAGE_OFFSET such that RAM can be mapped using large block sizes.

For instance, on my Seattle A0 box, the kernel is loaded 16 MB into the
lowest GB of RAM, which means __pa(PAGE_OFFSET) is not 1 GB aligned, and
the entire 16 GB of RAM will be mapping using 2 MB blocks. (Similarly,
for 64 KB granule kernels, the entire 16 GB of RAM will be mapped using
pages since __pa(PAGE_OFFSET) is not 512 MB aligned). With these changes
 __pa(PAGE_OFFSET) will always be chosen such that it is aligned to a
quantity that allows efficient mapping.

Note that of the entire KASLR series, this sub-series is the most likely to
cause problems, and hence requires the most careful review and testing. This
is due to the fact that, with these changes, the invariant __va(__pa(x)) == x
no longer holds, and any code that is based on that assumption needs to be
updated.

Changes since v4:
- added Marc's ack to patch #6
- round the kasan zero shadow region around the kernel image to swapper block
  size (#7)
- ensure that we don't clip the kernel image when clipping RAM to the linear
  region size (#8)

Patch #1 allows the low mark of memblocks discovered from the FDT to be
overridden by the architecture.

Patch #2 enables the huge-vmap generic feature for arm64. This should be an
improvement in itself, but the significance for this series is that it allows
unmap_kernel_range() to be called on the [__init_begin, __init_end) region,
which may be partially mapped using block mappings.

Patch #3 introduces KIMAGE_VADDR as a separate, preparatory step towards
decoupling the kernel placement from PAGE_OFFSET

Patch #4 implements some translation table accessors that operate on statically
allocate translation tables before the linear mapping is up.

Patch #5 decouples the fixmap initialization from the linear mapping, by using
the accessors implemented by patch #4

Patch #6 removes assumptions made my KVM regarding the placement of the kernel
image inside the linear mapping.

Patch #7 moves the kernel image from the base of the linear mapping to the base
of the vmalloc area. The modules area, which sits right below the kernel image,
is moved along and is put right before the start of the vmalloc area.

Patch #8 decouples PHYS_OFFSET from PAGE_OFFSET, which allows the linear mapping
to cover all discovered memory, regardless of where the kernel image is located
in it. This effectively allows the kernel to be loaded at any physical address
(provided that the correct alignment is used)

[1] http://thread.gmane.org/gmane.linux.kernel/2135931

Ard Biesheuvel (8):
  of/fdt: make memblock minimum physical address arch configurable
  arm64: add support for ioremap() block mappings
  arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
  arm64: pgtable: implement static [pte|pmd|pud]_offset variants
  arm64: decouple early fixmap init from linear mapping
  arm64: kvm: deal with kernel symbols outside of linear mapping
  arm64: move kernel image to base of vmalloc area
  arm64: allow kernel Image to be loaded anywhere in physical memory

 Documentation/arm64/booting.txt                      |  20 ++-
 Documentation/features/vm/huge-vmap/arch-support.txt |   2 +-
 arch/arm/include/asm/kvm_asm.h                       |   2 +
 arch/arm/kvm/arm.c                                   |   8 +-
 arch/arm64/Kconfig                                   |   1 +
 arch/arm64/include/asm/boot.h                        |   6 +
 arch/arm64/include/asm/kasan.h                       |   2 +-
 arch/arm64/include/asm/kernel-pgtable.h              |  12 ++
 arch/arm64/include/asm/kvm_asm.h                     |   2 +
 arch/arm64/include/asm/kvm_host.h                    |   8 +-
 arch/arm64/include/asm/memory.h                      |  44 ++++--
 arch/arm64/include/asm/pgtable.h                     |  23 ++-
 arch/arm64/kernel/head.S                             |   8 +-
 arch/arm64/kernel/image.h                            |  13 +-
 arch/arm64/kernel/vmlinux.lds.S                      |   4 +-
 arch/arm64/kvm/hyp.S                                 |   6 +-
 arch/arm64/mm/dump.c                                 |  12 +-
 arch/arm64/mm/init.c                                 | 123 ++++++++++++++--
 arch/arm64/mm/kasan_init.c                           |  31 +++-
 arch/arm64/mm/mmu.c                                  | 155 +++++++++++++++-----
 drivers/of/fdt.c                                     |   5 +-
 21 files changed, 378 insertions(+), 109 deletions(-)

-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 02:54:46 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 11:54:46 +0100
Subject: [PATCH v5sub1 1/8] of/fdt: make memblock minimum physical address
 arch configurable
In-Reply-To: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454324093-15998-2-git-send-email-ard.biesheuvel@linaro.org>

By default, early_init_dt_add_memory_arch() ignores memory below
the base of the kernel image since it won't be addressable via the
linear mapping. However, this is not appropriate anymore once we
decouple the kernel text mapping from the linear mapping, so archs
may want to drop the low limit entirely. So allow the minimum to be
overridden by setting MIN_MEMBLOCK_ADDR.

Acked-by: Mark Rutland <mark.rutland at arm.com>
Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/of/fdt.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79db7899..1f98156f8996 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -976,13 +976,16 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
 }
 
 #ifdef CONFIG_HAVE_MEMBLOCK
+#ifndef MIN_MEMBLOCK_ADDR
+#define MIN_MEMBLOCK_ADDR	__pa(PAGE_OFFSET)
+#endif
 #ifndef MAX_MEMBLOCK_ADDR
 #define MAX_MEMBLOCK_ADDR	((phys_addr_t)~0)
 #endif
 
 void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 {
-	const u64 phys_offset = __pa(PAGE_OFFSET);
+	const u64 phys_offset = MIN_MEMBLOCK_ADDR;
 
 	if (!PAGE_ALIGNED(base)) {
 		if (size < PAGE_SIZE - (base & ~PAGE_MASK)) {
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 02:54:47 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 11:54:47 +0100
Subject: [PATCH v5sub1 2/8] arm64: add support for ioremap() block mappings
In-Reply-To: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454324093-15998-3-git-send-email-ard.biesheuvel@linaro.org>

This wires up the existing generic huge-vmap feature, which allows
ioremap() to use PMD or PUD sized block mappings. It also adds support
to the unmap path for dealing with block mappings, which will allow us
to unmap the __init region using unmap_kernel_range() in a subsequent
patch.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 Documentation/features/vm/huge-vmap/arch-support.txt |  2 +-
 arch/arm64/Kconfig                                   |  1 +
 arch/arm64/include/asm/memory.h                      |  6 +++
 arch/arm64/mm/mmu.c                                  | 41 ++++++++++++++++++++
 4 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/Documentation/features/vm/huge-vmap/arch-support.txt b/Documentation/features/vm/huge-vmap/arch-support.txt
index af6816bccb43..df1d1f3c9af2 100644
--- a/Documentation/features/vm/huge-vmap/arch-support.txt
+++ b/Documentation/features/vm/huge-vmap/arch-support.txt
@@ -9,7 +9,7 @@
     |       alpha: | TODO |
     |         arc: | TODO |
     |         arm: | TODO |
-    |       arm64: | TODO |
+    |       arm64: |  ok  |
     |       avr32: | TODO |
     |    blackfin: | TODO |
     |         c6x: | TODO |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc62289a63e..cd767fa3037a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -49,6 +49,7 @@ config ARM64
 	select HAVE_ALIGNED_STRUCT_PAGE if SLUB
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_ARCH_BITREVERSE
+	select HAVE_ARCH_HUGE_VMAP
 	select HAVE_ARCH_JUMP_LABEL
 	select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP && !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
 	select HAVE_ARCH_KGDB
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 853953cd1f08..c65aad7b13dc 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -100,6 +100,12 @@
 #define MT_S2_NORMAL		0xf
 #define MT_S2_DEVICE_nGnRE	0x1
 
+#ifdef CONFIG_ARM64_4K_PAGES
+#define IOREMAP_MAX_ORDER	(PUD_SHIFT)
+#else
+#define IOREMAP_MAX_ORDER	(PMD_SHIFT)
+#endif
+
 #ifndef __ASSEMBLY__
 
 extern phys_addr_t		memstart_addr;
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 7711554a94f4..73383019f212 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -714,3 +714,44 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
 
 	return dt_virt;
 }
+
+int __init arch_ioremap_pud_supported(void)
+{
+	/* only 4k granule supports level 1 block mappings */
+	return IS_ENABLED(CONFIG_ARM64_4K_PAGES);
+}
+
+int __init arch_ioremap_pmd_supported(void)
+{
+	return 1;
+}
+
+int pud_set_huge(pud_t *pud, phys_addr_t phys, pgprot_t prot)
+{
+	BUG_ON(phys & ~PUD_MASK);
+	set_pud(pud, __pud(phys | PUD_TYPE_SECT | pgprot_val(mk_sect_prot(prot))));
+	return 1;
+}
+
+int pmd_set_huge(pmd_t *pmd, phys_addr_t phys, pgprot_t prot)
+{
+	BUG_ON(phys & ~PMD_MASK);
+	set_pmd(pmd, __pmd(phys | PMD_TYPE_SECT | pgprot_val(mk_sect_prot(prot))));
+	return 1;
+}
+
+int pud_clear_huge(pud_t *pud)
+{
+	if (!pud_sect(*pud))
+		return 0;
+	pud_clear(pud);
+	return 1;
+}
+
+int pmd_clear_huge(pmd_t *pmd)
+{
+	if (!pmd_sect(*pmd))
+		return 0;
+	pmd_clear(pmd);
+	return 1;
+}
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 02:54:48 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 11:54:48 +0100
Subject: [PATCH v5sub1 3/8] arm64: introduce KIMAGE_VADDR as the virtual base
 of the kernel region
In-Reply-To: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454324093-15998-4-git-send-email-ard.biesheuvel@linaro.org>

This introduces the preprocessor symbol KIMAGE_VADDR which will serve as
the symbolic virtual base of the kernel region, i.e., the kernel's virtual
offset will be KIMAGE_VADDR + TEXT_OFFSET. For now, we define it as being
equal to PAGE_OFFSET, but in the future, it will be moved below it once
we move the kernel virtual mapping out of the linear mapping.

Reviewed-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/memory.h | 10 ++++++++--
 arch/arm64/kernel/head.S        |  2 +-
 arch/arm64/kernel/vmlinux.lds.S |  4 ++--
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index c65aad7b13dc..aebc739f5a11 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -51,7 +51,8 @@
 #define VA_BITS			(CONFIG_ARM64_VA_BITS)
 #define VA_START		(UL(0xffffffffffffffff) << VA_BITS)
 #define PAGE_OFFSET		(UL(0xffffffffffffffff) << (VA_BITS - 1))
-#define MODULES_END		(PAGE_OFFSET)
+#define KIMAGE_VADDR		(PAGE_OFFSET)
+#define MODULES_END		(KIMAGE_VADDR)
 #define MODULES_VADDR		(MODULES_END - SZ_64M)
 #define PCI_IO_END		(MODULES_VADDR - SZ_2M)
 #define PCI_IO_START		(PCI_IO_END - PCI_IO_SIZE)
@@ -75,8 +76,13 @@
  * private definitions which should NOT be used outside memory.h
  * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
  */
-#define __virt_to_phys(x)	(((phys_addr_t)(x) - PAGE_OFFSET + PHYS_OFFSET))
+#define __virt_to_phys(x) ({						\
+	phys_addr_t __x = (phys_addr_t)(x);				\
+	__x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :	\
+			     (__x - KIMAGE_VADDR + PHYS_OFFSET); })
+
 #define __phys_to_virt(x)	((unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET))
+#define __phys_to_kimg(x)	((unsigned long)((x) - PHYS_OFFSET + KIMAGE_VADDR))
 
 /*
  * Convert a page to/from a physical address
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 53b9f9f128c2..04d38a058b19 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -389,7 +389,7 @@ __create_page_tables:
 	 * Map the kernel image (starting with PHYS_OFFSET).
 	 */
 	mov	x0, x26				// swapper_pg_dir
-	mov	x5, #PAGE_OFFSET
+	ldr	x5, =KIMAGE_VADDR
 	create_pgd_entry x0, x5, x3, x6
 	ldr	x6, =KERNEL_END			// __va(KERNEL_END)
 	mov	x3, x24				// phys offset
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index b78a3c772294..282e3e64a17e 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -89,7 +89,7 @@ SECTIONS
 		*(.discard.*)
 	}
 
-	. = PAGE_OFFSET + TEXT_OFFSET;
+	. = KIMAGE_VADDR + TEXT_OFFSET;
 
 	.head.text : {
 		_text = .;
@@ -186,4 +186,4 @@ ASSERT(__idmap_text_end - (__idmap_text_start & ~(SZ_4K - 1)) <= SZ_4K,
 /*
  * If padding is applied before .head.text, virt<->phys conversions will fail.
  */
-ASSERT(_text == (PAGE_OFFSET + TEXT_OFFSET), "HEAD is misaligned")
+ASSERT(_text == (KIMAGE_VADDR + TEXT_OFFSET), "HEAD is misaligned")
-- 
2.5.0



From matthias.bgg at gmail.com  Mon Feb  1 02:55:14 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 1 Feb 2016 11:55:14 +0100
Subject: [PATCH V3 08/11] soc: mediatek: PMIC wrap: remove
 pwrap_is_mt8135() and pwrap_is_mt8173()
In-Reply-To: <1453715604-36856-9-git-send-email-blogic@openwrt.org>
References: <1453715604-36856-1-git-send-email-blogic@openwrt.org>
 <1453715604-36856-9-git-send-email-blogic@openwrt.org>
Message-ID: <56AF3992.8020004@gmail.com>



On 25/01/16 10:53, John Crispin wrote:
> With ore SoCs being added the list of helper functions like these would

The commit message is something strange:
"With every new SoC being added..." maybe?

> grow. While at it also add a new flag "bridge" and use that insted of

s/insted/instead

> pwrap_is_mt8173() where appropriate.
>
> Signed-off-by: John Crispin <blogic at openwrt.org>
> ---
>   drivers/soc/mediatek/mtk-pmic-wrap.c |   27 +++++++++++----------------
>   1 file changed, 11 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index 8bb091b..54553b4 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -374,20 +374,11 @@ struct pmic_wrapper_type {
>   	u32 int_en_all;
>   	u32 spi_w;
>   	u32 wdt_src;
> +	int has_bridge;
>   	int (*init_reg_clock)(struct pmic_wrapper *wrp);
>   	int (*init_special)(struct pmic_wrapper *wrp);
>   };
>
> -static inline int pwrap_is_mt8135(struct pmic_wrapper *wrp)
> -{
> -	return wrp->master->type == PWRAP_MT8135;
> -}
> -
> -static inline int pwrap_is_mt8173(struct pmic_wrapper *wrp)
> -{
> -	return wrp->master->type == PWRAP_MT8173;
> -}
> -
>   static u32 pwrap_readl(struct pmic_wrapper *wrp, enum pwrap_regs reg)
>   {
>   	return readl(wrp->base + wrp->master->regs[reg]);
> @@ -619,11 +610,14 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
>   	pwrap_writel(wrp, 0x1, PWRAP_CIPHER_KEY_SEL);
>   	pwrap_writel(wrp, 0x2, PWRAP_CIPHER_IV_SEL);
>
> -	if (pwrap_is_mt8135(wrp)) {
> +	switch (wrp->master->type) {
> +	case PWRAP_MT8135:
>   		pwrap_writel(wrp, 1, PWRAP_CIPHER_LOAD);
>   		pwrap_writel(wrp, 1, PWRAP_CIPHER_START);
> -	} else {
> +		break;
> +	case PWRAP_MT8173:
>   		pwrap_writel(wrp, 1, PWRAP_CIPHER_EN);
> +		break;
>   	}
>
>   	/* Config cipher mode @PMIC */
> @@ -713,7 +707,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
>   	if (wrp->rstc_bridge)
>   		reset_control_reset(wrp->rstc_bridge);
>
> -	if (pwrap_is_mt8173(wrp)) {
> +	if (wrp->master->type == PWRAP_MT8173) {
>   		/* Enable DCM */
>   		pwrap_writel(wrp, 3, PWRAP_DCM_EN);
>   		pwrap_writel(wrp, 0, PWRAP_DCM_DBC_PRD);
> @@ -773,7 +767,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
>   	pwrap_writel(wrp, PWRAP_DEW_CRC_VAL, PWRAP_SIG_ADR);
>   	pwrap_writel(wrp, wrp->master->arb_en_all, PWRAP_HIPRIO_ARB_EN);
>
> -	if (pwrap_is_mt8135(wrp))
> +	if (wrp->master->type == PWRAP_MT8135)
>   		pwrap_writel(wrp, 0x7, PWRAP_RRARB_EN);
>
>   	pwrap_writel(wrp, 0x1, PWRAP_WACS0_EN);
> @@ -792,7 +786,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
>   	pwrap_writel(wrp, 1, PWRAP_INIT_DONE0);
>   	pwrap_writel(wrp, 1, PWRAP_INIT_DONE1);
>
> -	if (pwrap_is_mt8135(wrp)) {
> +	if (wrp->master->has_bridge) {
>   		writel(1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INIT_DONE3);
>   		writel(1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INIT_DONE4);
>   	}
> @@ -830,6 +824,7 @@ static struct pmic_wrapper_type pwrap_mt8135 = {
>   	.int_en_all = BIT(31) | BIT(1),
>   	.spi_w = PWRAP_MAN_CMD_SPI_WRITE,
>   	.wdt_src = PWRAP_WDT_SRC_MASK_ALL,
> +	.has_bridge = 1,
>   	.init_reg_clock = pwrap_mt8135_init_reg_clock,
>   	.init_special = pwrap_mt8135_init_special,
>   };

Please set has_bridge explicitly for mt8173.


From ard.biesheuvel at linaro.org  Mon Feb  1 02:54:51 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 11:54:51 +0100
Subject: [PATCH v5sub1 6/8] arm64: kvm: deal with kernel symbols outside of
 linear mapping
In-Reply-To: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454324093-15998-7-git-send-email-ard.biesheuvel@linaro.org>

KVM on arm64 uses a fixed offset between the linear mapping at EL1 and
the HYP mapping at EL2. Before we can move the kernel virtual mapping
out of the linear mapping, we have to make sure that references to kernel
symbols that are accessed via the HYP mapping are translated to their
linear equivalent.

Reviewed-by: Mark Rutland <mark.rutland at arm.com>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm/include/asm/kvm_asm.h    | 2 ++
 arch/arm/kvm/arm.c                | 8 +++++---
 arch/arm64/include/asm/kvm_asm.h  | 2 ++
 arch/arm64/include/asm/kvm_host.h | 8 +++++---
 arch/arm64/kvm/hyp.S              | 6 +++---
 5 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index 194c91b610ff..c35c349da069 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -79,6 +79,8 @@
 #define rr_lo_hi(a1, a2) a1, a2
 #endif
 
+#define kvm_ksym_ref(kva)	(kva)
+
 #ifndef __ASSEMBLY__
 struct kvm;
 struct kvm_vcpu;
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dda1959f0dde..975da6cfbf59 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -982,7 +982,7 @@ static void cpu_init_hyp_mode(void *dummy)
 	pgd_ptr = kvm_mmu_get_httbr();
 	stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
 	hyp_stack_ptr = stack_page + PAGE_SIZE;
-	vector_ptr = (unsigned long)__kvm_hyp_vector;
+	vector_ptr = (unsigned long)kvm_ksym_ref(__kvm_hyp_vector);
 
 	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
 
@@ -1074,13 +1074,15 @@ static int init_hyp_mode(void)
 	/*
 	 * Map the Hyp-code called directly from the host
 	 */
-	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
+	err = create_hyp_mappings(kvm_ksym_ref(__kvm_hyp_code_start),
+				  kvm_ksym_ref(__kvm_hyp_code_end));
 	if (err) {
 		kvm_err("Cannot map world-switch code\n");
 		goto out_free_mappings;
 	}
 
-	err = create_hyp_mappings(__start_rodata, __end_rodata);
+	err = create_hyp_mappings(kvm_ksym_ref(__start_rodata),
+				  kvm_ksym_ref(__end_rodata));
 	if (err) {
 		kvm_err("Cannot map rodata section\n");
 		goto out_free_mappings;
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 52b777b7d407..f5aee6e764e6 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -26,6 +26,8 @@
 #define KVM_ARM64_DEBUG_DIRTY_SHIFT	0
 #define KVM_ARM64_DEBUG_DIRTY		(1 << KVM_ARM64_DEBUG_DIRTY_SHIFT)
 
+#define kvm_ksym_ref(sym)		((void *)&sym - KIMAGE_VADDR + PAGE_OFFSET)
+
 #ifndef __ASSEMBLY__
 struct kvm;
 struct kvm_vcpu;
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 689d4c95e12f..e3d67ff8798b 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -307,7 +307,7 @@ static inline void kvm_arch_mmu_notifier_invalidate_page(struct kvm *kvm,
 struct kvm_vcpu *kvm_arm_get_running_vcpu(void);
 struct kvm_vcpu * __percpu *kvm_get_running_vcpus(void);
 
-u64 kvm_call_hyp(void *hypfn, ...);
+u64 __kvm_call_hyp(void *hypfn, ...);
 void force_vm_exit(const cpumask_t *mask);
 void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);
 
@@ -328,8 +328,8 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
 	 * Call initialization code, and switch to the full blown
 	 * HYP code.
 	 */
-	kvm_call_hyp((void *)boot_pgd_ptr, pgd_ptr,
-		     hyp_stack_ptr, vector_ptr);
+	__kvm_call_hyp((void *)boot_pgd_ptr, pgd_ptr,
+		       hyp_stack_ptr, vector_ptr);
 }
 
 static inline void kvm_arch_hardware_disable(void) {}
@@ -343,4 +343,6 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_clear_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu);
 
+#define kvm_call_hyp(f, ...) __kvm_call_hyp(kvm_ksym_ref(f), ##__VA_ARGS__)
+
 #endif /* __ARM64_KVM_HOST_H__ */
diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index 0ccdcbbef3c2..870578f84b1c 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -20,7 +20,7 @@
 #include <asm/assembler.h>
 
 /*
- * u64 kvm_call_hyp(void *hypfn, ...);
+ * u64 __kvm_call_hyp(void *hypfn, ...);
  *
  * This is not really a variadic function in the classic C-way and care must
  * be taken when calling this to ensure parameters are passed in registers
@@ -37,7 +37,7 @@
  * used to implement __hyp_get_vectors in the same way as in
  * arch/arm64/kernel/hyp_stub.S.
  */
-ENTRY(kvm_call_hyp)
+ENTRY(__kvm_call_hyp)
 	hvc	#0
 	ret
-ENDPROC(kvm_call_hyp)
+ENDPROC(__kvm_call_hyp)
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 02:54:49 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 11:54:49 +0100
Subject: [PATCH v5sub1 4/8] arm64: pgtable: implement static
 [pte|pmd|pud]_offset variants
In-Reply-To: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454324093-15998-5-git-send-email-ard.biesheuvel@linaro.org>

The page table accessors pte_offset(), pud_offset() and pmd_offset()
rely on __va translations, so they can only be used after the linear
mapping has been installed. For the early fixmap and kasan init routines,
whose page tables are allocated statically in the kernel image, these
functions will return bogus values. So implement pte_offset_kimg(),
pmd_offset_kimg() and pud_offset_kimg(), which can be used instead
before any page tables have been allocated dynamically.

Reviewed-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/pgtable.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 4229f75fd145..87355408d448 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -445,6 +445,9 @@ static inline phys_addr_t pmd_page_paddr(pmd_t pmd)
 
 #define pmd_page(pmd)		pfn_to_page(__phys_to_pfn(pmd_val(pmd) & PHYS_MASK))
 
+/* use ONLY for statically allocated translation tables */
+#define pte_offset_kimg(dir,addr)	((pte_t *)__phys_to_kimg(pte_offset_phys((dir), (addr))))
+
 /*
  * Conversion functions: convert a page and protection to a page entry,
  * and a page entry and page directory to the page they refer to.
@@ -488,6 +491,9 @@ static inline phys_addr_t pud_page_paddr(pud_t pud)
 
 #define pud_page(pud)		pfn_to_page(__phys_to_pfn(pud_val(pud) & PHYS_MASK))
 
+/* use ONLY for statically allocated translation tables */
+#define pmd_offset_kimg(dir,addr)	((pmd_t *)__phys_to_kimg(pmd_offset_phys((dir), (addr))))
+
 #else
 
 #define pud_page_paddr(pud)	({ BUILD_BUG(); 0; })
@@ -497,6 +503,8 @@ static inline phys_addr_t pud_page_paddr(pud_t pud)
 #define pmd_set_fixmap_offset(pudp, addr)	((pmd_t *)pudp)
 #define pmd_clear_fixmap()
 
+#define pmd_offset_kimg(dir,addr)	((pmd_t *)dir)
+
 #endif	/* CONFIG_PGTABLE_LEVELS > 2 */
 
 #if CONFIG_PGTABLE_LEVELS > 3
@@ -535,6 +543,9 @@ static inline phys_addr_t pgd_page_paddr(pgd_t pgd)
 
 #define pgd_page(pgd)		pfn_to_page(__phys_to_pfn(pgd_val(pgd) & PHYS_MASK))
 
+/* use ONLY for statically allocated translation tables */
+#define pud_offset_kimg(dir,addr)	((pud_t *)__phys_to_kimg(pud_offset_phys((dir), (addr))))
+
 #else
 
 #define pgd_page_paddr(pgd)	({ BUILD_BUG(); 0;})
@@ -544,6 +555,8 @@ static inline phys_addr_t pgd_page_paddr(pgd_t pgd)
 #define pud_set_fixmap_offset(pgdp, addr)	((pud_t *)pgdp)
 #define pud_clear_fixmap()
 
+#define pud_offset_kimg(dir,addr)	((pud_t *)dir)
+
 #endif  /* CONFIG_PGTABLE_LEVELS > 3 */
 
 #define pgd_ERROR(pgd)		__pgd_error(__FILE__, __LINE__, pgd_val(pgd))
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 02:54:50 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 11:54:50 +0100
Subject: [PATCH v5sub1 5/8] arm64: decouple early fixmap init from linear
 mapping
In-Reply-To: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454324093-15998-6-git-send-email-ard.biesheuvel@linaro.org>

Since the early fixmap page tables are populated using pages that are
part of the static footprint of the kernel, they are covered by the
initial kernel mapping, and we can refer to them without using __va/__pa
translations, which are tied to the linear mapping.

Since the fixmap page tables are disjoint from the kernel mapping up
to the top level pgd entry, we can refer to bm_pte[] directly, and there
is no need to walk the page tables and perform __pa()/__va() translations
at each step.

Reviewed-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/mm/mmu.c | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 73383019f212..b84915723ea0 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -583,7 +583,7 @@ static inline pud_t * fixmap_pud(unsigned long addr)
 
 	BUG_ON(pgd_none(*pgd) || pgd_bad(*pgd));
 
-	return pud_offset(pgd, addr);
+	return pud_offset_kimg(pgd, addr);
 }
 
 static inline pmd_t * fixmap_pmd(unsigned long addr)
@@ -592,16 +592,12 @@ static inline pmd_t * fixmap_pmd(unsigned long addr)
 
 	BUG_ON(pud_none(*pud) || pud_bad(*pud));
 
-	return pmd_offset(pud, addr);
+	return pmd_offset_kimg(pud, addr);
 }
 
 static inline pte_t * fixmap_pte(unsigned long addr)
 {
-	pmd_t *pmd = fixmap_pmd(addr);
-
-	BUG_ON(pmd_none(*pmd) || pmd_bad(*pmd));
-
-	return pte_offset_kernel(pmd, addr);
+	return &bm_pte[pte_index(addr)];
 }
 
 void __init early_fixmap_init(void)
@@ -613,14 +609,14 @@ void __init early_fixmap_init(void)
 
 	pgd = pgd_offset_k(addr);
 	pgd_populate(&init_mm, pgd, bm_pud);
-	pud = pud_offset(pgd, addr);
+	pud = fixmap_pud(addr);
 	pud_populate(&init_mm, pud, bm_pmd);
-	pmd = pmd_offset(pud, addr);
+	pmd = fixmap_pmd(addr);
 	pmd_populate_kernel(&init_mm, pmd, bm_pte);
 
 	/*
 	 * The boot-ioremap range spans multiple pmds, for which
-	 * we are not preparted:
+	 * we are not prepared:
 	 */
 	BUILD_BUG_ON((__fix_to_virt(FIX_BTMAP_BEGIN) >> PMD_SHIFT)
 		     != (__fix_to_virt(FIX_BTMAP_END) >> PMD_SHIFT));
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 02:54:52 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 11:54:52 +0100
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc area
In-Reply-To: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>

This moves the module area to right before the vmalloc area, and
moves the kernel image to the base of the vmalloc area. This is
an intermediate step towards implementing KASLR, which allows the
kernel image to be located anywhere in the vmalloc area.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/kasan.h   |  2 +-
 arch/arm64/include/asm/memory.h  | 21 +++--
 arch/arm64/include/asm/pgtable.h | 10 +-
 arch/arm64/mm/dump.c             | 12 +--
 arch/arm64/mm/init.c             | 23 ++---
 arch/arm64/mm/kasan_init.c       | 31 ++++++-
 arch/arm64/mm/mmu.c              | 97 +++++++++++++-------
 7 files changed, 129 insertions(+), 67 deletions(-)

diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h
index de0d21211c34..71ad0f93eb71 100644
--- a/arch/arm64/include/asm/kasan.h
+++ b/arch/arm64/include/asm/kasan.h
@@ -14,7 +14,7 @@
  * KASAN_SHADOW_END: KASAN_SHADOW_START + 1/8 of kernel virtual addresses.
  */
 #define KASAN_SHADOW_START      (VA_START)
-#define KASAN_SHADOW_END        (KASAN_SHADOW_START + (1UL << (VA_BITS - 3)))
+#define KASAN_SHADOW_END        (KASAN_SHADOW_START + KASAN_SHADOW_SIZE)
 
 /*
  * This value is used to map an address to the corresponding shadow
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index aebc739f5a11..4388651d1f0d 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -45,16 +45,15 @@
  * VA_START - the first kernel virtual address.
  * TASK_SIZE - the maximum size of a user space task.
  * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area.
- * The module space lives between the addresses given by TASK_SIZE
- * and PAGE_OFFSET - it must be within 128MB of the kernel text.
  */
 #define VA_BITS			(CONFIG_ARM64_VA_BITS)
 #define VA_START		(UL(0xffffffffffffffff) << VA_BITS)
 #define PAGE_OFFSET		(UL(0xffffffffffffffff) << (VA_BITS - 1))
-#define KIMAGE_VADDR		(PAGE_OFFSET)
-#define MODULES_END		(KIMAGE_VADDR)
-#define MODULES_VADDR		(MODULES_END - SZ_64M)
-#define PCI_IO_END		(MODULES_VADDR - SZ_2M)
+#define KIMAGE_VADDR		(MODULES_END)
+#define MODULES_END		(MODULES_VADDR + MODULES_VSIZE)
+#define MODULES_VADDR		(VA_START + KASAN_SHADOW_SIZE)
+#define MODULES_VSIZE		(SZ_64M)
+#define PCI_IO_END		(PAGE_OFFSET - SZ_2M)
 #define PCI_IO_START		(PCI_IO_END - PCI_IO_SIZE)
 #define FIXADDR_TOP		(PCI_IO_START - SZ_2M)
 #define TASK_SIZE_64		(UL(1) << VA_BITS)
@@ -72,6 +71,16 @@
 #define TASK_UNMAPPED_BASE	(PAGE_ALIGN(TASK_SIZE / 4))
 
 /*
+ * The size of the KASAN shadow region. This should be 1/8th of the
+ * size of the entire kernel virtual address space.
+ */
+#ifdef CONFIG_KASAN
+#define KASAN_SHADOW_SIZE	(UL(1) << (VA_BITS - 3))
+#else
+#define KASAN_SHADOW_SIZE	(0)
+#endif
+
+/*
  * Physical vs virtual RAM address space conversion.  These are
  * private definitions which should NOT be used outside memory.h
  * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 87355408d448..a440f5a85d08 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -36,19 +36,13 @@
  *
  * VMEMAP_SIZE: allows the whole VA space to be covered by a struct page array
  *	(rounded up to PUD_SIZE).
- * VMALLOC_START: beginning of the kernel VA space
+ * VMALLOC_START: beginning of the kernel vmalloc space
  * VMALLOC_END: extends to the available space below vmmemmap, PCI I/O space,
  *	fixed mappings and modules
  */
 #define VMEMMAP_SIZE		ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) * sizeof(struct page), PUD_SIZE)
 
-#ifndef CONFIG_KASAN
-#define VMALLOC_START		(VA_START)
-#else
-#include <asm/kasan.h>
-#define VMALLOC_START		(KASAN_SHADOW_END + SZ_64K)
-#endif
-
+#define VMALLOC_START		(MODULES_END)
 #define VMALLOC_END		(PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - SZ_64K)
 
 #define vmemmap			((struct page *)(VMALLOC_END + SZ_64K))
diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index 0adbebbc2803..e83ffb00560c 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -35,7 +35,9 @@ struct addr_marker {
 };
 
 enum address_markers_idx {
-	VMALLOC_START_NR = 0,
+	MODULES_START_NR = 0,
+	MODULES_END_NR,
+	VMALLOC_START_NR,
 	VMALLOC_END_NR,
 #ifdef CONFIG_SPARSEMEM_VMEMMAP
 	VMEMMAP_START_NR,
@@ -45,12 +47,12 @@ enum address_markers_idx {
 	FIXADDR_END_NR,
 	PCI_START_NR,
 	PCI_END_NR,
-	MODULES_START_NR,
-	MODULES_END_NR,
 	KERNEL_SPACE_NR,
 };
 
 static struct addr_marker address_markers[] = {
+	{ MODULES_VADDR,	"Modules start" },
+	{ MODULES_END,		"Modules end" },
 	{ VMALLOC_START,	"vmalloc() Area" },
 	{ VMALLOC_END,		"vmalloc() End" },
 #ifdef CONFIG_SPARSEMEM_VMEMMAP
@@ -61,9 +63,7 @@ static struct addr_marker address_markers[] = {
 	{ FIXADDR_TOP,		"Fixmap end" },
 	{ PCI_IO_START,		"PCI I/O start" },
 	{ PCI_IO_END,		"PCI I/O end" },
-	{ MODULES_VADDR,	"Modules start" },
-	{ MODULES_END,		"Modules end" },
-	{ PAGE_OFFSET,		"Kernel Mapping" },
+	{ PAGE_OFFSET,		"Linear Mapping" },
 	{ -1,			NULL },
 };
 
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3b061e67bfe..1d627cd8121c 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -36,6 +36,7 @@
 #include <linux/swiotlb.h>
 
 #include <asm/fixmap.h>
+#include <asm/kasan.h>
 #include <asm/memory.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
@@ -302,22 +303,26 @@ void __init mem_init(void)
 #ifdef CONFIG_KASAN
 		  "    kasan   : 0x%16lx - 0x%16lx   (%6ld GB)\n"
 #endif
+		  "    modules : 0x%16lx - 0x%16lx   (%6ld MB)\n"
 		  "    vmalloc : 0x%16lx - 0x%16lx   (%6ld GB)\n"
+		  "      .init : 0x%p" " - 0x%p" "   (%6ld KB)\n"
+		  "      .text : 0x%p" " - 0x%p" "   (%6ld KB)\n"
+		  "      .data : 0x%p" " - 0x%p" "   (%6ld KB)\n"
 #ifdef CONFIG_SPARSEMEM_VMEMMAP
 		  "    vmemmap : 0x%16lx - 0x%16lx   (%6ld GB maximum)\n"
 		  "              0x%16lx - 0x%16lx   (%6ld MB actual)\n"
 #endif
 		  "    fixed   : 0x%16lx - 0x%16lx   (%6ld KB)\n"
 		  "    PCI I/O : 0x%16lx - 0x%16lx   (%6ld MB)\n"
-		  "    modules : 0x%16lx - 0x%16lx   (%6ld MB)\n"
-		  "    memory  : 0x%16lx - 0x%16lx   (%6ld MB)\n"
-		  "      .init : 0x%p" " - 0x%p" "   (%6ld KB)\n"
-		  "      .text : 0x%p" " - 0x%p" "   (%6ld KB)\n"
-		  "      .data : 0x%p" " - 0x%p" "   (%6ld KB)\n",
+		  "    memory  : 0x%16lx - 0x%16lx   (%6ld MB)\n",
 #ifdef CONFIG_KASAN
 		  MLG(KASAN_SHADOW_START, KASAN_SHADOW_END),
 #endif
+		  MLM(MODULES_VADDR, MODULES_END),
 		  MLG(VMALLOC_START, VMALLOC_END),
+		  MLK_ROUNDUP(__init_begin, __init_end),
+		  MLK_ROUNDUP(_text, _etext),
+		  MLK_ROUNDUP(_sdata, _edata),
 #ifdef CONFIG_SPARSEMEM_VMEMMAP
 		  MLG((unsigned long)vmemmap,
 		      (unsigned long)vmemmap + VMEMMAP_SIZE),
@@ -326,11 +331,7 @@ void __init mem_init(void)
 #endif
 		  MLK(FIXADDR_START, FIXADDR_TOP),
 		  MLM(PCI_IO_START, PCI_IO_END),
-		  MLM(MODULES_VADDR, MODULES_END),
-		  MLM(PAGE_OFFSET, (unsigned long)high_memory),
-		  MLK_ROUNDUP(__init_begin, __init_end),
-		  MLK_ROUNDUP(_text, _etext),
-		  MLK_ROUNDUP(_sdata, _edata));
+		  MLM(PAGE_OFFSET, (unsigned long)high_memory));
 
 #undef MLK
 #undef MLM
@@ -358,8 +359,8 @@ void __init mem_init(void)
 
 void free_initmem(void)
 {
-	fixup_init();
 	free_initmem_default(0);
+	fixup_init();
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index cc569a38bc76..66c246871d2e 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -17,9 +17,11 @@
 #include <linux/start_kernel.h>
 
 #include <asm/mmu_context.h>
+#include <asm/kernel-pgtable.h>
 #include <asm/page.h>
 #include <asm/pgalloc.h>
 #include <asm/pgtable.h>
+#include <asm/sections.h>
 #include <asm/tlbflush.h>
 
 static pgd_t tmp_pg_dir[PTRS_PER_PGD] __initdata __aligned(PGD_SIZE);
@@ -33,7 +35,7 @@ static void __init kasan_early_pte_populate(pmd_t *pmd, unsigned long addr,
 	if (pmd_none(*pmd))
 		pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
 
-	pte = pte_offset_kernel(pmd, addr);
+	pte = pte_offset_kimg(pmd, addr);
 	do {
 		next = addr + PAGE_SIZE;
 		set_pte(pte, pfn_pte(virt_to_pfn(kasan_zero_page),
@@ -51,7 +53,7 @@ static void __init kasan_early_pmd_populate(pud_t *pud,
 	if (pud_none(*pud))
 		pud_populate(&init_mm, pud, kasan_zero_pmd);
 
-	pmd = pmd_offset(pud, addr);
+	pmd = pmd_offset_kimg(pud, addr);
 	do {
 		next = pmd_addr_end(addr, end);
 		kasan_early_pte_populate(pmd, addr, next);
@@ -68,7 +70,7 @@ static void __init kasan_early_pud_populate(pgd_t *pgd,
 	if (pgd_none(*pgd))
 		pgd_populate(&init_mm, pgd, kasan_zero_pud);
 
-	pud = pud_offset(pgd, addr);
+	pud = pud_offset_kimg(pgd, addr);
 	do {
 		next = pud_addr_end(addr, end);
 		kasan_early_pmd_populate(pud, addr, next);
@@ -126,9 +128,13 @@ static void __init clear_pgds(unsigned long start,
 
 void __init kasan_init(void)
 {
+	u64 kimg_shadow_start, kimg_shadow_end;
 	struct memblock_region *reg;
 	int i;
 
+	kimg_shadow_start = (u64)kasan_mem_to_shadow(_text);
+	kimg_shadow_end = (u64)kasan_mem_to_shadow(_end);
+
 	/*
 	 * We are going to perform proper setup of shadow memory.
 	 * At first we should unmap early shadow (clear_pgds() call bellow).
@@ -142,8 +148,25 @@ void __init kasan_init(void)
 
 	clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
 
+	vmemmap_populate(kimg_shadow_start, kimg_shadow_end, NUMA_NO_NODE);
+
+	/*
+	 * vmemmap_populate() has populated the shadow region that covers the
+	 * kernel image with SWAPPER_BLOCK_SIZE mappings, so we have to round
+	 * the start and end addresses to SWAPPER_BLOCK_SIZE as well, to prevent
+	 * kasan_populate_zero_shadow() from replacing the PMD block mappings
+	 * with PMD table mappings at the edges of the shadow region for the
+	 * kernel image.
+	 */
+	if (ARM64_SWAPPER_USES_SECTION_MAPS) {
+		kimg_shadow_start = round_down(kimg_shadow_start,
+					       SWAPPER_BLOCK_SIZE);
+		kimg_shadow_end = round_up(kimg_shadow_end, SWAPPER_BLOCK_SIZE);
+	}
 	kasan_populate_zero_shadow((void *)KASAN_SHADOW_START,
-			kasan_mem_to_shadow((void *)MODULES_VADDR));
+				   (void *)kimg_shadow_start);
+	kasan_populate_zero_shadow((void *)kimg_shadow_end,
+				   kasan_mem_to_shadow((void *)PAGE_OFFSET));
 
 	for_each_memblock(memory, reg) {
 		void *start = (void *)__phys_to_virt(reg->base);
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index b84915723ea0..4c4b15932963 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -53,6 +53,10 @@ u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
 unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_bss;
 EXPORT_SYMBOL(empty_zero_page);
 
+static pte_t bm_pte[PTRS_PER_PTE] __page_aligned_bss;
+static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss;
+static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss;
+
 pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 			      unsigned long size, pgprot_t vma_prot)
 {
@@ -349,14 +353,14 @@ static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end
 {
 
 	unsigned long kernel_start = __pa(_stext);
-	unsigned long kernel_end = __pa(_end);
+	unsigned long kernel_end = __pa(_etext);
 
 	/*
-	 * The kernel itself is mapped at page granularity. Map all other
-	 * memory, making sure we don't overwrite the existing kernel mappings.
+	 * Take care not to create a writable alias for the
+	 * read-only text and rodata sections of the kernel image.
 	 */
 
-	/* No overlap with the kernel. */
+	/* No overlap with the kernel text */
 	if (end < kernel_start || start >= kernel_end) {
 		__create_pgd_mapping(pgd, start, __phys_to_virt(start),
 				     end - start, PAGE_KERNEL,
@@ -365,7 +369,7 @@ static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end
 	}
 
 	/*
-	 * This block overlaps the kernel mapping. Map the portion(s) which
+	 * This block overlaps the kernel text mapping. Map the portion(s) which
 	 * don't overlap.
 	 */
 	if (start < kernel_start)
@@ -398,25 +402,28 @@ static void __init map_mem(pgd_t *pgd)
 	}
 }
 
-#ifdef CONFIG_DEBUG_RODATA
 void mark_rodata_ro(void)
 {
+	if (!IS_ENABLED(CONFIG_DEBUG_RODATA))
+		return;
+
 	create_mapping_late(__pa(_stext), (unsigned long)_stext,
 				(unsigned long)_etext - (unsigned long)_stext,
 				PAGE_KERNEL_ROX);
-
 }
-#endif
 
 void fixup_init(void)
 {
-	create_mapping_late(__pa(__init_begin), (unsigned long)__init_begin,
-			(unsigned long)__init_end - (unsigned long)__init_begin,
-			PAGE_KERNEL);
+	/*
+	 * Unmap the __init region but leave the VM area in place. This
+	 * prevents the region from being reused for kernel modules, which
+	 * is not supported by kallsyms.
+	 */
+	unmap_kernel_range((u64)__init_begin, (u64)(__init_end - __init_begin));
 }
 
 static void __init map_kernel_chunk(pgd_t *pgd, void *va_start, void *va_end,
-				    pgprot_t prot)
+				    pgprot_t prot, struct vm_struct *vma)
 {
 	phys_addr_t pa_start = __pa(va_start);
 	unsigned long size = va_end - va_start;
@@ -426,6 +433,14 @@ static void __init map_kernel_chunk(pgd_t *pgd, void *va_start, void *va_end,
 
 	__create_pgd_mapping(pgd, pa_start, (unsigned long)va_start, size, prot,
 			     early_pgtable_alloc);
+
+	vma->addr	= va_start;
+	vma->phys_addr	= pa_start;
+	vma->size	= size;
+	vma->flags	= VM_MAP;
+	vma->caller	= map_kernel_chunk;
+
+	vm_area_add_early(vma);
 }
 
 /*
@@ -433,17 +448,35 @@ static void __init map_kernel_chunk(pgd_t *pgd, void *va_start, void *va_end,
  */
 static void __init map_kernel(pgd_t *pgd)
 {
+	static struct vm_struct vmlinux_text, vmlinux_init, vmlinux_data;
 
-	map_kernel_chunk(pgd, _stext, _etext, PAGE_KERNEL_EXEC);
-	map_kernel_chunk(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC);
-	map_kernel_chunk(pgd, _data, _end, PAGE_KERNEL);
+	map_kernel_chunk(pgd, _stext, _etext, PAGE_KERNEL_EXEC, &vmlinux_text);
+	map_kernel_chunk(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC,
+			 &vmlinux_init);
+	map_kernel_chunk(pgd, _data, _end, PAGE_KERNEL, &vmlinux_data);
 
-	/*
-	 * The fixmap falls in a separate pgd to the kernel, and doesn't live
-	 * in the carveout for the swapper_pg_dir. We can simply re-use the
-	 * existing dir for the fixmap.
-	 */
-	set_pgd(pgd_offset_raw(pgd, FIXADDR_START), *pgd_offset_k(FIXADDR_START));
+	if (!pgd_val(*pgd_offset_raw(pgd, FIXADDR_START))) {
+		/*
+		 * The fixmap falls in a separate pgd to the kernel, and doesn't
+		 * live in the carveout for the swapper_pg_dir. We can simply
+		 * re-use the existing dir for the fixmap.
+		 */
+		set_pgd(pgd_offset_raw(pgd, FIXADDR_START),
+			*pgd_offset_k(FIXADDR_START));
+	} else if (CONFIG_PGTABLE_LEVELS > 3) {
+		/*
+		 * The fixmap shares its top level pgd entry with the kernel
+		 * mapping. This can really only occur when we are running
+		 * with 16k/4 levels, so we can simply reuse the pud level
+		 * entry instead.
+		 */
+		BUG_ON(!IS_ENABLED(CONFIG_ARM64_16K_PAGES));
+		set_pud(pud_set_fixmap_offset(pgd, FIXADDR_START),
+			__pud(__pa(bm_pmd) | PUD_TYPE_TABLE));
+		pud_clear_fixmap();
+	} else {
+		BUG();
+	}
 
 	kasan_copy_shadow(pgd);
 }
@@ -569,14 +602,6 @@ void vmemmap_free(unsigned long start, unsigned long end)
 }
 #endif	/* CONFIG_SPARSEMEM_VMEMMAP */
 
-static pte_t bm_pte[PTRS_PER_PTE] __page_aligned_bss;
-#if CONFIG_PGTABLE_LEVELS > 2
-static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss;
-#endif
-#if CONFIG_PGTABLE_LEVELS > 3
-static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss;
-#endif
-
 static inline pud_t * fixmap_pud(unsigned long addr)
 {
 	pgd_t *pgd = pgd_offset_k(addr);
@@ -608,8 +633,18 @@ void __init early_fixmap_init(void)
 	unsigned long addr = FIXADDR_START;
 
 	pgd = pgd_offset_k(addr);
-	pgd_populate(&init_mm, pgd, bm_pud);
-	pud = fixmap_pud(addr);
+	if (CONFIG_PGTABLE_LEVELS > 3 && !pgd_none(*pgd)) {
+		/*
+		 * We only end up here if the kernel mapping and the fixmap
+		 * share the top level pgd entry, which should only happen on
+		 * 16k/4 levels configurations.
+		 */
+		BUG_ON(!IS_ENABLED(CONFIG_ARM64_16K_PAGES));
+		pud = pud_offset_kimg(pgd, addr);
+	} else {
+		pgd_populate(&init_mm, pgd, bm_pud);
+		pud = fixmap_pud(addr);
+	}
 	pud_populate(&init_mm, pud, bm_pmd);
 	pmd = fixmap_pmd(addr);
 	pmd_populate_kernel(&init_mm, pmd, bm_pte);
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 02:54:53 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 11:54:53 +0100
Subject: [PATCH v5sub1 8/8] arm64: allow kernel Image to be loaded anywhere in
 physical memory
In-Reply-To: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454324093-15998-9-git-send-email-ard.biesheuvel@linaro.org>

This relaxes the kernel Image placement requirements, so that it
may be placed at any 2 MB aligned offset in physical memory.

This is accomplished by ignoring PHYS_OFFSET when installing
memblocks, and accounting for the apparent virtual offset of
the kernel Image. As a result, virtual address references
below PAGE_OFFSET are correctly mapped onto physical references
into the kernel Image regardless of where it sits in memory.

Note that limiting memory using mem= is not unambiguous anymore after
this change, considering that the kernel may be at the top of physical
memory, and clipping from the bottom rather than the top will discard
any 32-bit DMA addressable memory first. To deal with this, the handling
of mem= is reimplemented to clip top down, but take special care not to
clip memory that covers the kernel image.

Since mem= should not be considered a production feature, a panic notifier
handler is installed that dumps the memory limit at panic time if one was
set.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 Documentation/arm64/booting.txt         |  20 ++--
 arch/arm64/include/asm/boot.h           |   6 ++
 arch/arm64/include/asm/kernel-pgtable.h |  12 +++
 arch/arm64/include/asm/kvm_asm.h        |   2 +-
 arch/arm64/include/asm/memory.h         |  15 +--
 arch/arm64/kernel/head.S                |   6 +-
 arch/arm64/kernel/image.h               |  13 ++-
 arch/arm64/mm/init.c                    | 100 +++++++++++++++++++-
 arch/arm64/mm/mmu.c                     |   3 +
 9 files changed, 155 insertions(+), 22 deletions(-)

diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt
index 701d39d3171a..56d6d8b796db 100644
--- a/Documentation/arm64/booting.txt
+++ b/Documentation/arm64/booting.txt
@@ -109,7 +109,13 @@ Header notes:
 			1 - 4K
 			2 - 16K
 			3 - 64K
-  Bits 3-63:	Reserved.
+  Bit 3:	Kernel physical placement
+			0 - 2MB aligned base should be as close as possible
+			    to the base of DRAM, since memory below it is not
+			    accessible via the linear mapping
+			1 - 2MB aligned base may be anywhere in physical
+			    memory
+  Bits 4-63:	Reserved.
 
 - When image_size is zero, a bootloader should attempt to keep as much
   memory as possible free for use by the kernel immediately after the
@@ -117,14 +123,14 @@ Header notes:
   depending on selected features, and is effectively unbound.
 
 The Image must be placed text_offset bytes from a 2MB aligned base
-address near the start of usable system RAM and called there. Memory
-below that base address is currently unusable by Linux, and therefore it
-is strongly recommended that this location is the start of system RAM.
-The region between the 2 MB aligned base address and the start of the
-image has no special significance to the kernel, and may be used for
-other purposes.
+address anywhere in usable system RAM and called there. The region
+between the 2 MB aligned base address and the start of the image has no
+special significance to the kernel, and may be used for other purposes.
 At least image_size bytes from the start of the image must be free for
 use by the kernel.
+NOTE: versions prior to v4.6 cannot make use of memory below the
+physical offset of the Image so it is recommended that the Image be
+placed as close as possible to the start of system RAM.
 
 Any memory described to the kernel (even that below the start of the
 image) which is not marked as reserved from the kernel (e.g., with a
diff --git a/arch/arm64/include/asm/boot.h b/arch/arm64/include/asm/boot.h
index 81151b67b26b..ebf2481889c3 100644
--- a/arch/arm64/include/asm/boot.h
+++ b/arch/arm64/include/asm/boot.h
@@ -11,4 +11,10 @@
 #define MIN_FDT_ALIGN		8
 #define MAX_FDT_SIZE		SZ_2M
 
+/*
+ * arm64 requires the kernel image to placed
+ * TEXT_OFFSET bytes beyond a 2 MB aligned base
+ */
+#define MIN_KIMG_ALIGN		SZ_2M
+
 #endif
diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
index a459714ee29e..5c6375d8528b 100644
--- a/arch/arm64/include/asm/kernel-pgtable.h
+++ b/arch/arm64/include/asm/kernel-pgtable.h
@@ -79,5 +79,17 @@
 #define SWAPPER_MM_MMUFLAGS	(PTE_ATTRINDX(MT_NORMAL) | SWAPPER_PTE_FLAGS)
 #endif
 
+/*
+ * To make optimal use of block mappings when laying out the linear
+ * mapping, round down the base of physical memory to a size that can
+ * be mapped efficiently, i.e., either PUD_SIZE (4k granule) or PMD_SIZE
+ * (64k granule), or a multiple that can be mapped using contiguous bits
+ * in the page tables: 32 * PMD_SIZE (16k granule)
+ */
+#ifdef CONFIG_ARM64_64K_PAGES
+#define ARM64_MEMSTART_ALIGN	SZ_512M
+#else
+#define ARM64_MEMSTART_ALIGN	SZ_1G
+#endif
 
 #endif	/* __ASM_KERNEL_PGTABLE_H */
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index f5aee6e764e6..054ac25e7c2e 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -26,7 +26,7 @@
 #define KVM_ARM64_DEBUG_DIRTY_SHIFT	0
 #define KVM_ARM64_DEBUG_DIRTY		(1 << KVM_ARM64_DEBUG_DIRTY_SHIFT)
 
-#define kvm_ksym_ref(sym)		((void *)&sym - KIMAGE_VADDR + PAGE_OFFSET)
+#define kvm_ksym_ref(sym)		phys_to_virt((u64)&sym - kimage_voffset)
 
 #ifndef __ASSEMBLY__
 struct kvm;
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 4388651d1f0d..61005e7dd6cb 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -88,10 +88,10 @@
 #define __virt_to_phys(x) ({						\
 	phys_addr_t __x = (phys_addr_t)(x);				\
 	__x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :	\
-			     (__x - KIMAGE_VADDR + PHYS_OFFSET); })
+			     (__x - kimage_voffset); })
 
 #define __phys_to_virt(x)	((unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET))
-#define __phys_to_kimg(x)	((unsigned long)((x) - PHYS_OFFSET + KIMAGE_VADDR))
+#define __phys_to_kimg(x)	((unsigned long)((x) + kimage_voffset))
 
 /*
  * Convert a page to/from a physical address
@@ -127,13 +127,14 @@ extern phys_addr_t		memstart_addr;
 /* PHYS_OFFSET - the physical address of the start of memory. */
 #define PHYS_OFFSET		({ memstart_addr; })
 
+/* the offset between the kernel virtual and physical mappings */
+extern u64			kimage_voffset;
+
 /*
- * The maximum physical address that the linear direct mapping
- * of system RAM can cover. (PAGE_OFFSET can be interpreted as
- * a 2's complement signed quantity and negated to derive the
- * maximum size of the linear mapping.)
+ * Allow all memory at the discovery stage. We will clip it later.
  */
-#define MAX_MEMBLOCK_ADDR	({ memstart_addr - PAGE_OFFSET - 1; })
+#define MIN_MEMBLOCK_ADDR	0
+#define MAX_MEMBLOCK_ADDR	U64_MAX
 
 /*
  * PFNs are used to describe any physical page; this means
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 04d38a058b19..05b98289093e 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -428,7 +428,11 @@ __mmap_switched:
 	and	x4, x4, #~(THREAD_SIZE - 1)
 	msr	sp_el0, x4			// Save thread_info
 	str_l	x21, __fdt_pointer, x5		// Save FDT pointer
-	str_l	x24, memstart_addr, x6		// Save PHYS_OFFSET
+
+	ldr	x4, =KIMAGE_VADDR		// Save the offset between
+	sub	x4, x4, x24			// the kernel virtual and
+	str_l	x4, kimage_voffset, x5		// physical mappings
+
 	mov	x29, #0
 #ifdef CONFIG_KASAN
 	bl	kasan_early_init
diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
index 999633bd7294..c9c62cab25a4 100644
--- a/arch/arm64/kernel/image.h
+++ b/arch/arm64/kernel/image.h
@@ -42,15 +42,18 @@
 #endif
 
 #ifdef CONFIG_CPU_BIG_ENDIAN
-#define __HEAD_FLAG_BE	1
+#define __HEAD_FLAG_BE		1
 #else
-#define __HEAD_FLAG_BE	0
+#define __HEAD_FLAG_BE		0
 #endif
 
-#define __HEAD_FLAG_PAGE_SIZE ((PAGE_SHIFT - 10) / 2)
+#define __HEAD_FLAG_PAGE_SIZE	((PAGE_SHIFT - 10) / 2)
 
-#define __HEAD_FLAGS	((__HEAD_FLAG_BE << 0) |	\
-			 (__HEAD_FLAG_PAGE_SIZE << 1))
+#define __HEAD_FLAG_PHYS_BASE	1
+
+#define __HEAD_FLAGS		((__HEAD_FLAG_BE << 0) |	\
+				 (__HEAD_FLAG_PAGE_SIZE << 1) |	\
+				 (__HEAD_FLAG_PHYS_BASE << 3))
 
 /*
  * These will output as part of the Image header, which should be little-endian
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 1d627cd8121c..e8e853a1024c 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -35,8 +35,10 @@
 #include <linux/efi.h>
 #include <linux/swiotlb.h>
 
+#include <asm/boot.h>
 #include <asm/fixmap.h>
 #include <asm/kasan.h>
+#include <asm/kernel-pgtable.h>
 #include <asm/memory.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
@@ -158,9 +160,80 @@ static int __init early_mem(char *p)
 }
 early_param("mem", early_mem);
 
+/*
+ * clip_mem_range() - remove memblock memory between @min and @max until
+ *                    we meet the limit in 'memory_limit'.
+ */
+static void __init clip_mem_range(u64 min, u64 max)
+{
+	u64 mem_size, to_remove;
+	int i;
+
+again:
+	mem_size = memblock_phys_mem_size();
+	if (mem_size <= memory_limit || max <= min)
+		return;
+
+	to_remove = mem_size - memory_limit;
+
+	for (i = memblock.memory.cnt - 1; i >= 0; i--) {
+		struct memblock_region *r = memblock.memory.regions + i;
+		u64 start = max(min, r->base);
+		u64 end = min(max, r->base + r->size);
+
+		if (start >= max || end <= min)
+			continue;
+
+		if (end > min) {
+			u64 size = min(to_remove, end - max(start, min));
+
+			memblock_remove(end - size, size);
+		} else {
+			memblock_remove(start, min(max - start, to_remove));
+		}
+		goto again;
+	}
+}
+
 void __init arm64_memblock_init(void)
 {
-	memblock_enforce_memory_limit(memory_limit);
+	const s64 linear_region_size = -(s64)PAGE_OFFSET;
+
+	/*
+	 * Select a suitable value for the base of physical memory.
+	 */
+	memstart_addr = round_down(memblock_start_of_DRAM(),
+				   ARM64_MEMSTART_ALIGN);
+
+	/*
+	 * Remove the memory that we will not be able to cover with the
+	 * linear mapping. Take care not to clip the kernel which may be
+	 * high in memory.
+	 */
+	memblock_remove(max(memstart_addr + linear_region_size, __pa(_end)),
+			ULLONG_MAX);
+	if (memblock_end_of_DRAM() > linear_region_size)
+		memblock_remove(0, memblock_end_of_DRAM() - linear_region_size);
+
+	if (memory_limit != (phys_addr_t)ULLONG_MAX) {
+		u64 kbase = round_down(__pa(_text), MIN_KIMG_ALIGN);
+		u64 kend = PAGE_ALIGN(__pa(_end));
+		u64 const sz_4g = 0x100000000UL;
+
+		/*
+		 * Clip memory in order of preference:
+		 * - above the kernel and above 4 GB
+		 * - between 4 GB and the start of the kernel (if the kernel
+		 *   is loaded high in memory)
+		 * - between the kernel and 4 GB (if the kernel is loaded
+		 *   low in memory)
+		 * - below 4 GB
+		 */
+		clip_mem_range(max(sz_4g, kend), ULLONG_MAX);
+		clip_mem_range(sz_4g, kbase);
+		clip_mem_range(kend, sz_4g);
+		clip_mem_range(0, min(kbase, sz_4g));
+	}
 
 	/*
 	 * Register the kernel text, kernel data, initrd, and initial
@@ -381,3 +454,28 @@ static int __init keepinitrd_setup(char *__unused)
 
 __setup("keepinitrd", keepinitrd_setup);
 #endif
+
+/*
+ * Dump out memory limit information on panic.
+ */
+static int dump_mem_limit(struct notifier_block *self, unsigned long v, void *p)
+{
+	if (memory_limit != (phys_addr_t)ULLONG_MAX) {
+		pr_emerg("Memory Limit: %llu MB\n", memory_limit >> 20);
+	} else {
+		pr_emerg("Memory Limit: none\n");
+	}
+	return 0;
+}
+
+static struct notifier_block mem_limit_notifier = {
+	.notifier_call = dump_mem_limit,
+};
+
+static int __init register_mem_limit_dumper(void)
+{
+	atomic_notifier_chain_register(&panic_notifier_list,
+				       &mem_limit_notifier);
+	return 0;
+}
+__initcall(register_mem_limit_dumper);
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 4c4b15932963..8dda38378959 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -46,6 +46,9 @@
 
 u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
 
+u64 kimage_voffset __read_mostly;
+EXPORT_SYMBOL(kimage_voffset);
+
 /*
  * Empty_zero_page is a special page that is used for zero-initialized data
  * and COW.
-- 
2.5.0



From arnd at arndb.de  Mon Feb  1 02:38:43 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 01 Feb 2016 11:38:43 +0100
Subject: [PATCH] PM / Domains: mark genpd_poweron as __maybe_unused
Message-ID: <3864075.BdhPDUQ9fB@wuerfel>

The rework of the power domain code has made the genpd_poweron()
function local to the file it's defined in, and the only remaining
caller is conditionally compiled based on CONFIG_PM_GENERIC_DOMAINS_OF,
so we get a warning when that is disabled:

drivers/base/power/domain.c:234:12: error: 'genpd_poweron' defined but not used [-Werror=unused-function]

This adds a __maybe_unused annotation to the function so gcc can
figure out by itself that it should silently remove the definition
in this case.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: ea823c7cbffa ("PM / Domains: Remove pm_genpd_poweron() API")

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 784dbe897a5e..a14b2f1ae085 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -231,7 +231,7 @@ static int __genpd_poweron(struct generic_pm_domain *genpd, unsigned int depth)
  * genpd_poweron - Restore power to a given PM domain and its masters.
  * @genpd: PM domain to power up.
  */
-static int genpd_poweron(struct generic_pm_domain *genpd)
+static int __maybe_unused genpd_poweron(struct generic_pm_domain *genpd)
 {
 	int ret;
 



From matthias.bgg at gmail.com  Mon Feb  1 03:02:05 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 1 Feb 2016 12:02:05 +0100
Subject: [PATCH V3 09/11] soc: mediatek: PMIC wrap: add a slave specific
 struct
In-Reply-To: <1453715604-36856-10-git-send-email-blogic@openwrt.org>
References: <1453715604-36856-1-git-send-email-blogic@openwrt.org>
 <1453715604-36856-10-git-send-email-blogic@openwrt.org>
Message-ID: <56AF3B2D.7040607@gmail.com>



On 25/01/16 10:53, John Crispin wrote:
> This patch adds a new struct pwrap_slv_type that we use to store the slave
> specific data. The patch adds 2 new helper functions to access the dew
> registers. The slave type is looked up via the wrappers child node.
>
> Signed-off-by: John Crispin <blogic at openwrt.org>
> ---
>   drivers/soc/mediatek/mtk-pmic-wrap.c |  170 +++++++++++++++++++++++++---------
>   1 file changed, 124 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index 54553b4..21d8e5a 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -69,33 +69,64 @@
>   					  PWRAP_WDT_SRC_EN_HARB_STAUPD_DLE | \
>   					  PWRAP_WDT_SRC_EN_HARB_STAUPD_ALE)
>
> -/* macro for slave device wrapper registers */
> -#define PWRAP_DEW_BASE			0xbc00
> -#define PWRAP_DEW_EVENT_OUT_EN		(PWRAP_DEW_BASE + 0x0)
> -#define PWRAP_DEW_DIO_EN		(PWRAP_DEW_BASE + 0x2)
> -#define PWRAP_DEW_EVENT_SRC_EN		(PWRAP_DEW_BASE + 0x4)
> -#define PWRAP_DEW_EVENT_SRC		(PWRAP_DEW_BASE + 0x6)
> -#define PWRAP_DEW_EVENT_FLAG		(PWRAP_DEW_BASE + 0x8)
> -#define PWRAP_DEW_READ_TEST		(PWRAP_DEW_BASE + 0xa)
> -#define PWRAP_DEW_WRITE_TEST		(PWRAP_DEW_BASE + 0xc)
> -#define PWRAP_DEW_CRC_EN		(PWRAP_DEW_BASE + 0xe)
> -#define PWRAP_DEW_CRC_VAL		(PWRAP_DEW_BASE + 0x10)
> -#define PWRAP_DEW_MON_GRP_SEL		(PWRAP_DEW_BASE + 0x12)
> -#define PWRAP_DEW_MON_FLAG_SEL		(PWRAP_DEW_BASE + 0x14)
> -#define PWRAP_DEW_EVENT_TEST		(PWRAP_DEW_BASE + 0x16)
> -#define PWRAP_DEW_CIPHER_KEY_SEL	(PWRAP_DEW_BASE + 0x18)
> -#define PWRAP_DEW_CIPHER_IV_SEL		(PWRAP_DEW_BASE + 0x1a)
> -#define PWRAP_DEW_CIPHER_LOAD		(PWRAP_DEW_BASE + 0x1c)
> -#define PWRAP_DEW_CIPHER_START		(PWRAP_DEW_BASE + 0x1e)
> -#define PWRAP_DEW_CIPHER_RDY		(PWRAP_DEW_BASE + 0x20)
> -#define PWRAP_DEW_CIPHER_MODE		(PWRAP_DEW_BASE + 0x22)
> -#define PWRAP_DEW_CIPHER_SWRST		(PWRAP_DEW_BASE + 0x24)
> -#define PWRAP_MT8173_DEW_CIPHER_IV0	(PWRAP_DEW_BASE + 0x26)
> -#define PWRAP_MT8173_DEW_CIPHER_IV1	(PWRAP_DEW_BASE + 0x28)
> -#define PWRAP_MT8173_DEW_CIPHER_IV2	(PWRAP_DEW_BASE + 0x2a)
> -#define PWRAP_MT8173_DEW_CIPHER_IV3	(PWRAP_DEW_BASE + 0x2c)
> -#define PWRAP_MT8173_DEW_CIPHER_IV4	(PWRAP_DEW_BASE + 0x2e)
> -#define PWRAP_MT8173_DEW_CIPHER_IV5	(PWRAP_DEW_BASE + 0x30)
> +/* defines for slave device wrapper registers */
> +enum dew_regs {
> +	PWRAP_DEW_BASE,
> +	PWRAP_DEW_EVENT_OUT_EN,
> +	PWRAP_DEW_DIO_EN,
> +	PWRAP_DEW_EVENT_SRC_EN,
> +	PWRAP_DEW_EVENT_SRC,
> +	PWRAP_DEW_EVENT_FLAG,
> +	PWRAP_DEW_READ_TEST,
> +	PWRAP_DEW_WRITE_TEST,
> +	PWRAP_DEW_CRC_EN,
> +	PWRAP_DEW_CRC_VAL,
> +	PWRAP_DEW_MON_GRP_SEL,
> +	PWRAP_DEW_MON_FLAG_SEL,
> +	PWRAP_DEW_EVENT_TEST,
> +	PWRAP_DEW_CIPHER_KEY_SEL,
> +	PWRAP_DEW_CIPHER_IV_SEL,
> +	PWRAP_DEW_CIPHER_LOAD,
> +	PWRAP_DEW_CIPHER_START,
> +	PWRAP_DEW_CIPHER_RDY,
> +	PWRAP_DEW_CIPHER_MODE,
> +	PWRAP_DEW_CIPHER_SWRST,
> +	PWRAP_MT8173_DEW_CIPHER_IV0,
> +	PWRAP_MT8173_DEW_CIPHER_IV1,
> +	PWRAP_MT8173_DEW_CIPHER_IV2,
> +	PWRAP_MT8173_DEW_CIPHER_IV3,
> +	PWRAP_MT8173_DEW_CIPHER_IV4,
> +	PWRAP_MT8173_DEW_CIPHER_IV5,
> +};
> +
> +static const u32 mt6397_regs[] = {
> +	[PWRAP_DEW_BASE] =		0xbc00,
> +	[PWRAP_DEW_EVENT_OUT_EN] =	0xbc00,
> +	[PWRAP_DEW_DIO_EN] =		0xbc02,
> +	[PWRAP_DEW_EVENT_SRC_EN] =	0xbc04,
> +	[PWRAP_DEW_EVENT_SRC] =		0xbc06,
> +	[PWRAP_DEW_EVENT_FLAG] =	0xbc08,
> +	[PWRAP_DEW_READ_TEST] =		0xbc0a,
> +	[PWRAP_DEW_WRITE_TEST] =	0xbc0c,
> +	[PWRAP_DEW_CRC_EN] =		0xbc0e,
> +	[PWRAP_DEW_CRC_VAL] =		0xbc10,
> +	[PWRAP_DEW_MON_GRP_SEL] =	0xbc12,
> +	[PWRAP_DEW_MON_FLAG_SEL] =	0xbc14,
> +	[PWRAP_DEW_EVENT_TEST] =	0xbc16,
> +	[PWRAP_DEW_CIPHER_KEY_SEL] =	0xbc18,
> +	[PWRAP_DEW_CIPHER_IV_SEL] =	0xbc1a,
> +	[PWRAP_DEW_CIPHER_LOAD] =	0xbc1c,
> +	[PWRAP_DEW_CIPHER_START] =	0xbc1e,
> +	[PWRAP_DEW_CIPHER_RDY] =	0xbc20,
> +	[PWRAP_DEW_CIPHER_MODE] =	0xbc22,
> +	[PWRAP_DEW_CIPHER_SWRST] =	0xbc24,
> +	[PWRAP_MT8173_DEW_CIPHER_IV0] = 0xbc26,
> +	[PWRAP_MT8173_DEW_CIPHER_IV1] = 0xbc28,
> +	[PWRAP_MT8173_DEW_CIPHER_IV2] = 0xbc2a,
> +	[PWRAP_MT8173_DEW_CIPHER_IV3] = 0xbc2c,
> +	[PWRAP_MT8173_DEW_CIPHER_IV4] = 0xbc2e,
> +	[PWRAP_MT8173_DEW_CIPHER_IV5] = 0xbc30,
> +};
>
>   enum pwrap_regs {
>   	PWRAP_MUX_SEL,
> @@ -349,16 +380,26 @@ static int mt8135_regs[] = {
>   	[PWRAP_DCM_DBC_PRD] =		0x160,
>   };
>
> +enum pmic_type {
> +	PMIC_MT6397,
> +};
> +
>   enum pwrap_type {
>   	PWRAP_MT8135,
>   	PWRAP_MT8173,
>   };
>
> +struct pwrap_slv_type {
> +	const u32 *dew_regs;
> +	enum pmic_type type;
> +};
> +
>   struct pmic_wrapper {
>   	struct device *dev;
>   	void __iomem *base;
>   	struct regmap *regmap;
>   	const struct pmic_wrapper_type *master;
> +	const struct pwrap_slv_type *slave;
>   	struct clk *clk_spi;
>   	struct clk *clk_wrap;
>   	struct reset_control *rstc;
> @@ -484,6 +525,16 @@ static int pwrap_read(struct pmic_wrapper *wrp, u32 adr, u32 *rdata)
>   	return 0;
>   }
>
> +static int pwrap_dew_write(struct pmic_wrapper *wrp, u32 reg, u32 wdata)
> +{
> +	return pwrap_write(wrp, wrp->slave->dew_regs[reg], wdata);
> +}
> +
> +static int pwrap_dew_read(struct pmic_wrapper *wrp, u32 reg, u32 *rdata)
> +{
> +	return pwrap_read(wrp, wrp->slave->dew_regs[reg], rdata);
> +}
> +

I would prefer to use pwrap_[read,write] directly instead of adding 
another indirection.


From shawnguo at kernel.org  Mon Feb  1 03:07:43 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 1 Feb 2016 19:07:43 +0800
Subject: [PATCH V6] ARM: dts: imx6q-icore-rqs: Add Engicam IMX6 Q7
 initial support
In-Reply-To: <20160129080135.GA18578@panicking>
References: <20151116172318.GA513@panicking>
 <1447752697.3144.47.camel@pengutronix.de>
 <20151118151030.GA11558@panicking> <20151211083512.GB11252@tiger>
 <20151214084456.GA4305@panicking>
 <20151216181159.GC20121@panicking> <20151223022707.GG26290@tiger>
 <20151224092439.GA9078@panicking> <20160128020405.GC9070@tiger>
 <20160129080135.GA18578@panicking>
Message-ID: <20160201110743.GB10671@tiger>

On Fri, Jan 29, 2016 at 09:01:39AM +0100, Michael Trimarchi wrote:
> www.engicam.com/en/products/embedded/som/standard/i-core-rqs-m6s-dl-d-q
> 
> Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>

Applied, thanks.


From yoshihiro.shimoda.uh at renesas.com  Mon Feb  1 03:17:30 2016
From: yoshihiro.shimoda.uh at renesas.com (Yoshihiro Shimoda)
Date: Mon, 1 Feb 2016 11:17:30 +0000
Subject: [PATCH] ARM: dts: porter: add MAX3355 support
In-Reply-To: <56ABD066.7020804@cogentembedded.com>
References: <1674850.BZpGW9kEud@wasted.cogentembedded.com>
 <4506196.xOgpYRO52t@wasted.cogentembedded.com>
 <SG2PR06MB0919D09C1146EAC0681EE109D8DA0@SG2PR06MB0919.apcprd06.prod.outlook.com>
 <56ABCB69.1070800@cogentembedded.com> <56ABD066.7020804@cogentembedded.com>
Message-ID: <SG2PR06MB0919361DC5805AE3F5B74041D8DE0@SG2PR06MB0919.apcprd06.prod.outlook.com>

Hi,

> From: Sergei Shtylyov
> Sent: Saturday, January 30, 2016 5:50 AM
> 
> On 01/29/2016 11:28 PM, Sergei Shtylyov wrote:
> 
> >>> From: linux-renesas-soc-owner at vger.kernel.org
> >>> [mailto:linux-renesas-soc-owner at vger.kernel.org] On Behalf Of Sergei
> >>> Shtylyov
> >>> Sent: Wednesday, January 27, 2016 7:14 AM
> >>>
> >>> Now that Maxim Integrated MAX3355 'extcon' driver and device tree bindings
> >>> are upstream along with the 'extcon' hook  in the Renesas USBHS driver, we
> >>> can add  MAX3355 device node to  the Porter device tree and properly refer
> >>> to it from the USBHS node instead of using  "renesas,enable-gpio" property
> >>> which only allowed checking the USB ID pin  at the driver probe time;  now
> >>> this  pin's  state can be monitored dynamically!
> >>>
> >>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> >>
> >> I tested this patch on Porter, but interrupt of "usb-otg" didn't happened
> >> even if I connected/disconnected a usb convert cable (usb micro-ab to A).
> >> Remarks: I confirmed that the usb convert cable worked correctly on other
> >> board.
> >
> >     I guess I have the same cable
> 
>     No, I have mini-AB connector here and hence my cable is mini-AB to A.

I checked Porter specification and then I found 2 specifications exist...
 Porter "B" : mini AB connecter and Max3355 is on the board.
 Porter "C" : micro AB connect and Max3355 is not on the board. (Select host/peripheral by a jumper.)

I guess that your current target is "B".
If so, I think this patch is acceptable.

Best regards,
Yoshihiro Shimoda

> > and IRQs do happen for me when I connect and
> > disconnect it (as it should be).
> 
> >> Best regards,
> >> Yoshihiro Shimoda
> 
> MBR, Sergei



From shawnguo at kernel.org  Mon Feb  1 03:19:33 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 1 Feb 2016 19:19:33 +0800
Subject: [PATCH] ARM: dts: vf-colibri-eval-v3: Use enable-gpios for BL_ON
In-Reply-To: <1452322793-26020-1-git-send-email-bhuvanchandra.dv@toradex.com>
References: <1452322793-26020-1-git-send-email-bhuvanchandra.dv@toradex.com>
Message-ID: <20160201111932.GC10671@tiger>

On Sat, Jan 09, 2016 at 12:29:53PM +0530, Bhuvanchandra DV wrote:
> Use pwm-backlight driver 'enable-gpios' property for backlight on/off
> control.
> 
> Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv at toradex.com>

Applied, thanks.


From matthias.bgg at gmail.com  Mon Feb  1 03:21:09 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 1 Feb 2016 12:21:09 +0100
Subject: [PATCH V4 11/11] soc: mediatek: PMIC wrap: add MT2701/7623 support
In-Reply-To: <1453894149-44127-11-git-send-email-blogic@openwrt.org>
References: <1453894149-44127-1-git-send-email-blogic@openwrt.org>
 <1453894149-44127-11-git-send-email-blogic@openwrt.org>
Message-ID: <56AF3FA5.9060803@gmail.com>



On 27/01/16 12:29, John Crispin wrote:
> Add the registers, callbacks and data structures required to make the
> wrapper work on MT2701 and MT7623.
>
> Signed-off-by: John Crispin <blogic at openwrt.org>
> ---
>   drivers/soc/mediatek/mtk-pmic-wrap.c |  160 ++++++++++++++++++++++++++++++++++
>   1 file changed, 160 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index 793b194..dbb09c6 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -52,6 +52,7 @@
>   #define PWRAP_DEW_WRITE_TEST_VAL	0xa55a
>
>   /* macro for manual command */
> +#define PWRAP_MAN_CMD_SPI_WRITE_NEW	(1 << 14)
>   #define PWRAP_MAN_CMD_SPI_WRITE		(1 << 13)
>   #define PWRAP_MAN_CMD_OP_CSH		(0x0 << 8)
>   #define PWRAP_MAN_CMD_OP_CSL		(0x1 << 8)
> @@ -202,6 +203,17 @@ enum pwrap_regs {
>   	PWRAP_DCM_EN,
>   	PWRAP_DCM_DBC_PRD,
>
> +	/* MT2701 only regs */
> +	PWRAP_OP_TYPE,
> +	PWRAP_MSB_FIRST,
> +	PWRAP_GPS_STA,
> +	PWRAP_ADC_CMD_ADDR,
> +	PWRAP_PWRAP_ADC_CMD,
> +	PWRAP_ADC_RDY_ADDR,
> +	PWRAP_ADC_RDATA_ADDR1,
> +	PWRAP_ADC_RDATA_ADDR2,
> +	PWRAP_ADC_WRAP_SEL,
> +
>   	/* MT8135 only regs */
>   	PWRAP_CSHEXT,
>   	PWRAP_EVENT_IN_EN,
> @@ -238,6 +250,96 @@ enum pwrap_regs {
>   	PWRAP_CIPHER_EN,
>   };
>
> +static int mt2701_regs[] = {
> +	[PWRAP_MUX_SEL] =		0x0,
> +	[PWRAP_WRAP_EN] =		0x4,
> +	[PWRAP_DIO_EN] =		0x8,
> +	[PWRAP_SIDLY] =			0xc,
> +	[PWRAP_OP_TYPE] =		0x10,
> +	[PWRAP_MSB_FIRST] =		0x14,
> +	[PWRAP_RDDMY] =			0x18,
> +	[PWRAP_SI_CK_CON] =		0x1c,
> +	[PWRAP_CSHEXT_WRITE] =		0x20,
> +	[PWRAP_CSHEXT_READ] =		0x24,
> +	[PWRAP_CSLEXT_START] =		0x28,
> +	[PWRAP_CSLEXT_END] =		0x2c,
> +	[PWRAP_STAUPD_PRD] =		0x30,
> +	[PWRAP_STAUPD_GRPEN] =		0x34,
> +	[PWRAP_STAUPD_MAN_TRIG] =	0x38,
> +	[PWRAP_STAUPD_STA] =		0x3c,
> +	[PWRAP_GPS_STA] =		0x40,
> +	[PWRAP_WRAP_STA] =		0x44,
> +	[PWRAP_HARB_INIT] =		0x48,
> +	[PWRAP_HARB_HPRIO] =		0x4c,
> +	[PWRAP_HIPRIO_ARB_EN] =		0x50,
> +	[PWRAP_HARB_STA0] =		0x54,
> +	[PWRAP_HARB_STA1] =		0x58,
> +	[PWRAP_MAN_EN] =		0x5c,
> +	[PWRAP_MAN_CMD] =		0x60,
> +	[PWRAP_MAN_RDATA] =		0x64,
> +	[PWRAP_MAN_VLDCLR] =		0x68,
> +	[PWRAP_WACS0_EN] =		0x6c,
> +	[PWRAP_INIT_DONE0] =		0x70,
> +	[PWRAP_WACS0_CMD] =		0x74,
> +	[PWRAP_WACS0_RDATA] =		0x78,
> +	[PWRAP_WACS0_VLDCLR] =		0x7c,
> +	[PWRAP_WACS1_EN] =		0x80,
> +	[PWRAP_INIT_DONE1] =		0x84,
> +	[PWRAP_WACS1_CMD] =		0x88,
> +	[PWRAP_WACS1_RDATA] =		0x8c,
> +	[PWRAP_WACS1_VLDCLR] =		0x90,
> +	[PWRAP_WACS2_EN] =		0x94,
> +	[PWRAP_INIT_DONE2] =		0x98,
> +	[PWRAP_WACS2_CMD] =		0x9c,
> +	[PWRAP_WACS2_RDATA] =		0xa0,
> +	[PWRAP_WACS2_VLDCLR] =		0xa4,
> +	[PWRAP_INT_EN] =		0xa8,
> +	[PWRAP_INT_FLG_RAW] =		0xac,
> +	[PWRAP_INT_FLG] =		0xb0,
> +	[PWRAP_INT_CLR] =		0xb4,
> +	[PWRAP_SIG_ADR] =		0xb8,
> +	[PWRAP_SIG_MODE] =		0xbc,
> +	[PWRAP_SIG_VALUE] =		0xc0,
> +	[PWRAP_SIG_ERRVAL] =		0xc4,
> +	[PWRAP_CRC_EN] =		0xc8,
> +	[PWRAP_TIMER_EN] =		0xcc,
> +	[PWRAP_TIMER_STA] =		0xd0,
> +	[PWRAP_WDT_UNIT] =		0xd4,
> +	[PWRAP_WDT_SRC_EN] =		0xd8,
> +	[PWRAP_WDT_FLG] =		0xdc,
> +	[PWRAP_DEBUG_INT_SEL] =		0xe0,
> +	[PWRAP_DVFS_ADR0] =		0xe4,
> +	[PWRAP_DVFS_WDATA0] =		0xe8,
> +	[PWRAP_DVFS_ADR1] =		0xec,
> +	[PWRAP_DVFS_WDATA1] =		0xf0,
> +	[PWRAP_DVFS_ADR2] =		0xf4,
> +	[PWRAP_DVFS_WDATA2] =		0xf8,
> +	[PWRAP_DVFS_ADR3] =		0xfc,
> +	[PWRAP_DVFS_WDATA3] =		0x100,
> +	[PWRAP_DVFS_ADR4] =		0x104,
> +	[PWRAP_DVFS_WDATA4] =		0x108,
> +	[PWRAP_DVFS_ADR5] =		0x10c,
> +	[PWRAP_DVFS_WDATA5] =		0x110,
> +	[PWRAP_DVFS_ADR6] =		0x114,
> +	[PWRAP_DVFS_WDATA6] =		0x118,
> +	[PWRAP_DVFS_ADR7] =		0x11c,
> +	[PWRAP_DVFS_WDATA7] =		0x120,
> +	[PWRAP_CIPHER_KEY_SEL] =	0x124,
> +	[PWRAP_CIPHER_IV_SEL] =		0x128,
> +	[PWRAP_CIPHER_EN] =		0x12c,
> +	[PWRAP_CIPHER_RDY] =		0x130,
> +	[PWRAP_CIPHER_MODE] =		0x134,
> +	[PWRAP_CIPHER_SWRST] =		0x138,
> +	[PWRAP_DCM_EN] =		0x13c,
> +	[PWRAP_DCM_DBC_PRD] =		0x140,
> +	[PWRAP_ADC_CMD_ADDR] =		0x144,
> +	[PWRAP_PWRAP_ADC_CMD] =		0x148,
> +	[PWRAP_ADC_RDY_ADDR] =		0x14c,
> +	[PWRAP_ADC_RDATA_ADDR1] =	0x150,
> +	[PWRAP_ADC_RDATA_ADDR2] =	0x154,
> +	[PWRAP_ADC_WRAP_SEL] =		0x184,
> +};
> +
>   static int mt8173_regs[] = {
>   	[PWRAP_MUX_SEL] =		0x0,
>   	[PWRAP_WRAP_EN] =		0x4,
> @@ -399,6 +501,7 @@ enum pmic_type {
>   };
>
>   enum pwrap_type {
> +	PWRAP_MT2701,
>   	PWRAP_MT8135,
>   	PWRAP_MT8173,
>   };
> @@ -648,6 +751,30 @@ static int pwrap_mt8173_init_reg_clock(struct pmic_wrapper *wrp)
>   	return 0;
>   }
>
> +static int pwrap_mt2701_init_reg_clock(struct pmic_wrapper *wrp)
> +{
> +	switch (wrp->slave->type) {
> +	case PMIC_MT6397:
> +		pwrap_writel(wrp, 0xc, PWRAP_RDDMY);
> +		pwrap_writel(wrp, 0x4, PWRAP_CSHEXT_WRITE);
> +		pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_READ);
> +		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_START);
> +		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_END);
> +		break;
> +
> +	case PMIC_MT6323:
> +		pwrap_writel(wrp, 0x8, PWRAP_RDDMY);
> +		pwrap_dew_write(wrp, PWRAP_DEW_RDDMY_NO, 0x8);
> +		pwrap_writel(wrp, 0x5, PWRAP_CSHEXT_WRITE);
> +		pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_READ);
> +		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_START);
> +		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_END);
> +		break;
> +	}
> +
> +	return 0;
> +}
> +
>   static bool pwrap_is_cipher_ready(struct pmic_wrapper *wrp)
>   {
>   	return pwrap_readl(wrp, PWRAP_CIPHER_RDY) & 1;
> @@ -680,6 +807,7 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
>   		pwrap_writel(wrp, 1, PWRAP_CIPHER_LOAD);
>   		pwrap_writel(wrp, 1, PWRAP_CIPHER_START);
>   		break;
> +	case PWRAP_MT2701:
>   	case PWRAP_MT8173:
>   		pwrap_writel(wrp, 1, PWRAP_CIPHER_EN);
>   		break;
> @@ -772,6 +900,24 @@ static int pwrap_mt8173_init_special(struct pmic_wrapper *wrp)
>   	return 0;
>   }
>
> +static int pwrap_mt2701_init_special(struct pmic_wrapper *wrp)
> +{
> +	/* GPS_INTF initialization */
> +	switch (wrp->slave->type) {
> +	case PMIC_MT6323:
> +		pwrap_writel(wrp, 0x076c, PWRAP_ADC_CMD_ADDR);
> +		pwrap_writel(wrp, 0x8000, PWRAP_PWRAP_ADC_CMD);
> +		pwrap_writel(wrp, 0x072c, PWRAP_ADC_RDY_ADDR);
> +		pwrap_writel(wrp, 0x072e, PWRAP_ADC_RDATA_ADDR1);
> +		pwrap_writel(wrp, 0x0730, PWRAP_ADC_RDATA_ADDR2);
> +		break;
> +	default:
> +		break;
> +	}
> +
> +	return 0;
> +}
> +
>   static int pwrap_init(struct pmic_wrapper *wrp)
>   {
>   	int ret;
> @@ -915,6 +1061,17 @@ static const struct of_device_id of_slave_match_tbl[] = {
>   };
>   MODULE_DEVICE_TABLE(of, of_slave_match_tbl);
>
> +static const struct pmic_wrapper_type pwrap_mt2701 = {
> +	.regs = mt2701_regs,
> +	.type = PWRAP_MT2701,
> +	.arb_en_all = 0x3f,
> +	.int_en_all = BIT(31) | BIT(2),
> +	.spi_w = PWRAP_MAN_CMD_SPI_WRITE_NEW,
> +	.wdt_src = PWRAP_WDT_SRC_MASK_ALL,
> +	.init_reg_clock = pwrap_mt2701_init_reg_clock,
> +	.init_special = pwrap_mt2701_init_special,
> +};
> +

.has_bridge = 0,
is missing.

Would it make sense to document the pmic_wrapper_type struct so that in, 
lets say, half a year it will be easier to remember what every member is 
used for?

Regards,
Matthias


From shawnguo at kernel.org  Mon Feb  1 03:21:53 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 1 Feb 2016 19:21:53 +0800
Subject: [PATCH 1/2] of: add vendor prefix for UniWest
In-Reply-To: <b11bf2208fe30b96c4d82e634e8abe04343754de.1452717014.git.stillcompiling@gmail.com>
References: <b11bf2208fe30b96c4d82e634e8abe04343754de.1452717014.git.stillcompiling@gmail.com>
Message-ID: <20160201112153.GD10671@tiger>

On Wed, Jan 13, 2016 at 12:45:11PM -0800, Joshua Clayton wrote:
> United Western Technologies Corp, known primarily as UniWest,
> is a manufacturer of eddy current and ultrasonic testing equipment.
> 
> Signed-off-by: Joshua Clayton <stillcompiling at gmail.com>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 55df1d4..7dabdee 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -230,6 +230,7 @@ toradex	Toradex AG
>  toshiba	Toshiba Corporation
>  toumaz	Toumaz
>  tplink	TP-LINK Technologies Co., Ltd.
> +uniwest	United Western Technologies Corp (UniWest)

As far as I know, it should be added in alphabetical order.

Shawn

>  tronfy	Tronfy
>  truly	Truly Semiconductors Limited
>  upisemi	uPI Semiconductor Corp.
> -- 
> 2.5.0
> 
> 


From yunhui.cui at nxp.com  Mon Feb  1 03:23:16 2016
From: yunhui.cui at nxp.com (Yunhui Cui)
Date: Mon, 1 Feb 2016 11:23:16 +0000
Subject: [PATCH 3/3] mtd:spi-nor:fsl-quadspi:Add fast-read mode support
In-Reply-To: <56AB7C6E.2050300@atmel.com>
References: <1454067669-35274-1-git-send-email-B56489@freescale.com>
 <1454067669-35274-4-git-send-email-B56489@freescale.com>
 <56AB7C6E.2050300@atmel.com>
Message-ID: <AM3PR04MB14416F884013EEE1E889AEB994DE0@AM3PR04MB1441.eurprd04.prod.outlook.com>

Hi Cyrille,

Thanks for your suggestions very much, I'll resend version 2 patch set.

Best Regards
Yunhui

-----Original Message-----
From: Cyrille Pitchen [mailto:cyrille.pitchen at atmel.com] 
Sent: Friday, January 29, 2016 10:51 PM
To: Yunhui Cui; dwmw2 at infradead.org; computersforpeace at gmail.com; han.xu at freescale.com
Cc: linux-mtd at lists.infradead.org; linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Yao Yuan
Subject: Re: [PATCH 3/3] mtd:spi-nor:fsl-quadspi:Add fast-read mode support

Hi Yunhui,

Le 29/01/2016 12:41, Yunhui Cui a ?crit :
> The qspi driver add generic fast-read mode for different flash 
> venders, including Micron family. Also add some special operations for 
> Micron flash read/write in spi-nor.c.
> 
> Signed-off-by: Yunhui Cui <B56489 at freescale.com>
> ---
>  drivers/mtd/spi-nor/fsl-quadspi.c | 27 +++++++++++++++++++++------
>  drivers/mtd/spi-nor/spi-nor.c     |  6 +++++-
>  2 files changed, 26 insertions(+), 7 deletions(-)
> 
[...]
> diff --git a/drivers/mtd/spi-nor/spi-nor.c 
> b/drivers/mtd/spi-nor/spi-nor.c index ed0c19c..79a025c 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -763,7 +763,8 @@ static const struct flash_info spi_nor_ids[] = {
>  	{ "n25q064",     INFO(0x20ba17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
>  	{ "n25q064a",    INFO(0x20bb17, 0, 64 * 1024,  128, SECT_4K | SPI_NOR_QUAD_READ) },
>  	{ "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256, SPI_NOR_QUAD_READ) },
> -	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, SPI_NOR_QUAD_READ) },
> +	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, SPI_NOR_FAST |
> +			SPI_NOR_QUAD_READ) },
>  	{ "n25q256a",    INFO(0x20ba19, 0, 64 * 1024,  512, SECT_4K | SPI_NOR_QUAD_READ) },
>  	{ "n25q512a",    INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
>  	{ "n25q512ax3",  INFO(0x20ba20, 0, 64 * 1024, 1024, SECT_4K | 
> USE_FSR | SPI_NOR_QUAD_READ) },
This modification looks wrong.

First SPI_NOR_FAST is part of enum read_mode (from spi-nor.h) and is not intended to be used as a flag, unlike SPI_NOR_QUAD_READ (defined in spi-nor.c just below the flags field of struct flash_info).

Also, creating a new flag to choose between the Read and the Fast Read commands is not needed: see my last comment below.


> @@ -1233,6 +1234,7 @@ int spi_nor_scan(struct spi_nor *nor, const char 
> *name, enum read_mode mode)
>  
>  	if (JEDEC_MFR(info) == SNOR_MFR_ATMEL ||
>  	    JEDEC_MFR(info) == SNOR_MFR_INTEL ||
> +	    JEDEC_MFR(info) == SNOR_MFR_MICRON ||
>  	    JEDEC_MFR(info) == SNOR_MFR_SST) {
>  		write_enable(nor);
>  		write_sr(nor, 0);
This update is not related with the support of fast-read mode, it deals with the write protection. Hence it should be moved into a dedicated patch.

Also be careful as some bits of the Status Register are non-volatile on Micron memories. This modification may change their values but I guess you only want to clear the write enable/disable (7) bit.


> @@ -1317,6 +1319,8 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
>  		nor->flash_read = SPI_NOR_QUAD;
>  	} else if (mode == SPI_NOR_DUAL && info->flags & SPI_NOR_DUAL_READ) {
>  		nor->flash_read = SPI_NOR_DUAL;
> +	} else if (mode == SPI_NOR_FAST && info->flags & SPI_NOR_FAST) {
> +		nor->flash_read = SPI_NOR_FAST;
>  	}
>  
>  	/* Default commands */
> 
The spi-nor framework already checks the "m25p,fast-read" DT property to choose between the Read (0x03) and Fast Read (0x0b) command.

So the fsl-quadspi.c driver should rely on this existing property to choose which of SPI_NOR_FAST or SPI_NOR_QUAD is used as the mode argument of spi_nor_scan(). As long as mode is neither SPI_NOR_QUAD nor SPI_NOR_DUAL, the choice of the read op code is done according to whether the "m25p,fast-read" DT property is set or not.


Best regards,

Cyrille





From matthias.bgg at gmail.com  Mon Feb  1 03:25:14 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 1 Feb 2016 12:25:14 +0100
Subject: [PATCH V4 11/11] soc: mediatek: PMIC wrap: add MT2701/7623 support
In-Reply-To: <1453894149-44127-11-git-send-email-blogic@openwrt.org>
References: <1453894149-44127-1-git-send-email-blogic@openwrt.org>
 <1453894149-44127-11-git-send-email-blogic@openwrt.org>
Message-ID: <56AF409A.2040705@gmail.com>

On 27/01/16 12:29, John Crispin wrote:

[...]

>
> +static int pwrap_mt2701_init_reg_clock(struct pmic_wrapper *wrp)
> +{
> +	switch (wrp->slave->type) {
> +	case PMIC_MT6397:
> +		pwrap_writel(wrp, 0xc, PWRAP_RDDMY);
> +		pwrap_writel(wrp, 0x4, PWRAP_CSHEXT_WRITE);
> +		pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_READ);
> +		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_START);
> +		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_END);
> +		break;
> +
> +	case PMIC_MT6323:
> +		pwrap_writel(wrp, 0x8, PWRAP_RDDMY);
> +		pwrap_dew_write(wrp, PWRAP_DEW_RDDMY_NO, 0x8);
> +		pwrap_writel(wrp, 0x5, PWRAP_CSHEXT_WRITE);
> +		pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_READ);
> +		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_START);
> +		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_END);
> +		break;
> +	}
> +
> +	return 0;
> +}
> +

I forgot this:
So mt2701 can be used with both PMICs? Just wondering, as from what I 
know, SoC and PMIC a tightly coupled.

In general this series looks quite good to me.

Regards,
Matthias


From blogic at openwrt.org  Mon Feb  1 03:29:46 2016
From: blogic at openwrt.org (John Crispin)
Date: Mon, 1 Feb 2016 12:29:46 +0100
Subject: [PATCH V4 11/11] soc: mediatek: PMIC wrap: add MT2701/7623 support
In-Reply-To: <56AF409A.2040705@gmail.com>
References: <1453894149-44127-1-git-send-email-blogic@openwrt.org>
 <1453894149-44127-11-git-send-email-blogic@openwrt.org>
 <56AF409A.2040705@gmail.com>
Message-ID: <56AF41AA.9090204@openwrt.org>



On 01/02/2016 12:25, Matthias Brugger wrote:
> On 27/01/16 12:29, John Crispin wrote:
> 
> [...]
> 
>>
>> +static int pwrap_mt2701_init_reg_clock(struct pmic_wrapper *wrp)
>> +{
>> +    switch (wrp->slave->type) {
>> +    case PMIC_MT6397:
>> +        pwrap_writel(wrp, 0xc, PWRAP_RDDMY);
>> +        pwrap_writel(wrp, 0x4, PWRAP_CSHEXT_WRITE);
>> +        pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_READ);
>> +        pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_START);
>> +        pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_END);
>> +        break;
>> +
>> +    case PMIC_MT6323:
>> +        pwrap_writel(wrp, 0x8, PWRAP_RDDMY);
>> +        pwrap_dew_write(wrp, PWRAP_DEW_RDDMY_NO, 0x8);
>> +        pwrap_writel(wrp, 0x5, PWRAP_CSHEXT_WRITE);
>> +        pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_READ);
>> +        pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_START);
>> +        pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_END);
>> +        break;
>> +    }
>> +
>> +    return 0;
>> +}
>> +
> 
> I forgot this:
> So mt2701 can be used with both PMICs? Just wondering, as from what I
> know, SoC and PMIC a tightly coupled.

yes, it can be run with old and new style pmics. this is why the MAN_CMD
SPI_W bit has changed. the old BIT(13) is used to tell the wrapper what
slave type it has.

there is a way to runtime set the pmic but there is still a detail i
need to look at so it is not part of this series

> 
> In general this series looks quite good to me.
> 

i'll spin V5 during the day. busy adding dual gmac support to the
ethernet driver just now.

	John


From B56489 at freescale.com  Mon Feb  1 03:30:05 2016
From: B56489 at freescale.com (Yunhui Cui)
Date: Mon, 1 Feb 2016 19:30:05 +0800
Subject: [PATCH v2 1/4] mtd:fsl-quadspi:use the property fields of SPI-NOR
Message-ID: <1454326208-4533-1-git-send-email-B56489@freescale.com>

We can get the read/write/erase opcode from the spi nor framework
directly. This patch uses the information stored in the SPI-NOR to
remove the hardcode in the fsl_qspi_init_lut().

Signed-off-by: Yunhui Cui <B56489 at freescale.com>
---
 drivers/mtd/spi-nor/fsl-quadspi.c | 40 ++++++++++++---------------------------
 1 file changed, 12 insertions(+), 28 deletions(-)

diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
index 9ab2b51..517ffe2 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -373,9 +373,13 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
 	void __iomem *base = q->iobase;
 	int rxfifo = q->devtype_data->rxfifo;
 	u32 lut_base;
-	u8 cmd, addrlen, dummy;
 	int i;
 
+	struct spi_nor *nor = &q->nor[0];
+	u8 addrlen = (nor->addr_width == 3) ? ADDR24BIT : ADDR32BIT;
+	u8 read_op = nor->read_opcode;
+	u8 read_dm = nor->read_dummy;
+
 	fsl_qspi_unlock_lut(q);
 
 	/* Clear all the LUT table */
@@ -385,20 +389,10 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
 	/* Quad Read */
 	lut_base = SEQID_QUAD_READ * 4;
 
-	if (q->nor_size <= SZ_16M) {
-		cmd = SPINOR_OP_READ_1_1_4;
-		addrlen = ADDR24BIT;
-		dummy = 8;
-	} else {
-		/* use the 4-byte address */
-		cmd = SPINOR_OP_READ_1_1_4;
-		addrlen = ADDR32BIT;
-		dummy = 8;
-	}
-
-	qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
+	qspi_writel(q, LUT0(CMD, PAD1, read_op) | LUT1(ADDR, PAD1, addrlen),
 			base + QUADSPI_LUT(lut_base));
-	qspi_writel(q, LUT0(DUMMY, PAD1, dummy) | LUT1(FSL_READ, PAD4, rxfifo),
+	qspi_writel(q, LUT0(DUMMY, PAD1, read_dm) |
+		    LUT1(FSL_READ, PAD4, rxfifo),
 			base + QUADSPI_LUT(lut_base + 1));
 
 	/* Write enable */
@@ -409,16 +403,8 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
 	/* Page Program */
 	lut_base = SEQID_PP * 4;
 
-	if (q->nor_size <= SZ_16M) {
-		cmd = SPINOR_OP_PP;
-		addrlen = ADDR24BIT;
-	} else {
-		/* use the 4-byte address */
-		cmd = SPINOR_OP_PP;
-		addrlen = ADDR32BIT;
-	}
-
-	qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
+	qspi_writel(q, LUT0(CMD, PAD1, nor->program_opcode) |
+		    LUT1(ADDR, PAD1, addrlen),
 			base + QUADSPI_LUT(lut_base));
 	qspi_writel(q, LUT0(FSL_WRITE, PAD1, 0),
 			base + QUADSPI_LUT(lut_base + 1));
@@ -432,10 +418,8 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
 	/* Erase a sector */
 	lut_base = SEQID_SE * 4;
 
-	cmd = q->nor[0].erase_opcode;
-	addrlen = q->nor_size <= SZ_16M ? ADDR24BIT : ADDR32BIT;
-
-	qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
+	qspi_writel(q, LUT0(CMD, PAD1, nor->erase_opcode) |
+		    LUT1(ADDR, PAD1, addrlen),
 			base + QUADSPI_LUT(lut_base));
 
 	/* Erase the whole chip */
-- 
2.1.0.27.g96db324



From B56489 at freescale.com  Mon Feb  1 03:30:06 2016
From: B56489 at freescale.com (Yunhui Cui)
Date: Mon, 1 Feb 2016 19:30:06 +0800
Subject: [PATCH v2 2/4] mtd: fsl-quadspi: Rename SEQID_QUAD_READ to SEQID_READ
In-Reply-To: <1454326208-4533-1-git-send-email-B56489@freescale.com>
References: <1454326208-4533-1-git-send-email-B56489@freescale.com>
Message-ID: <1454326208-4533-2-git-send-email-B56489@freescale.com>

There are some read modes for flash, such as NORMAL, FAST,
QUAD, DDR QUAD. These modes will use the identical lut table base
So rename SEQID_QUAD_READ to SEQID_READ.

Signed-off-by: Yunhui Cui <B56489 at freescale.com>
---
 drivers/mtd/spi-nor/fsl-quadspi.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
index 517ffe2..9861290 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -193,7 +193,7 @@
 #define QUADSPI_LUT_NUM		64
 
 /* SEQID -- we can have 16 seqids at most. */
-#define SEQID_QUAD_READ		0
+#define SEQID_READ		0
 #define SEQID_WREN		1
 #define SEQID_WRDI		2
 #define SEQID_RDSR		3
@@ -386,8 +386,8 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
 	for (i = 0; i < QUADSPI_LUT_NUM; i++)
 		qspi_writel(q, 0, base + QUADSPI_LUT_BASE + i * 4);
 
-	/* Quad Read */
-	lut_base = SEQID_QUAD_READ * 4;
+	/* Read */
+	lut_base = SEQID_READ * 4;
 
 	qspi_writel(q, LUT0(CMD, PAD1, read_op) | LUT1(ADDR, PAD1, addrlen),
 			base + QUADSPI_LUT(lut_base));
@@ -468,7 +468,7 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
 {
 	switch (cmd) {
 	case SPINOR_OP_READ_1_1_4:
-		return SEQID_QUAD_READ;
+		return SEQID_READ;
 	case SPINOR_OP_WREN:
 		return SEQID_WREN;
 	case SPINOR_OP_WRDI:
-- 
2.1.0.27.g96db324



From B56489 at freescale.com  Mon Feb  1 03:30:07 2016
From: B56489 at freescale.com (Yunhui Cui)
Date: Mon, 1 Feb 2016 19:30:07 +0800
Subject: [PATCH v2 3/4] mtd:spi-nor:fsl-quadspi:Add fast-read mode support
In-Reply-To: <1454326208-4533-1-git-send-email-B56489@freescale.com>
References: <1454326208-4533-1-git-send-email-B56489@freescale.com>
Message-ID: <1454326208-4533-3-git-send-email-B56489@freescale.com>

The qspi driver add generic fast-read mode for different
flash venders. There are some different board flash work on
different mode, such fast-read, quad-mode.
So we have to modify the third entrace parameter of spi_nor_scan().

Signed-off-by: Yunhui Cui <B56489 at freescale.com>
---
 drivers/mtd/spi-nor/fsl-quadspi.c | 27 +++++++++++++++++++++------
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
index 9861290..0a31cb1 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -389,11 +389,21 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
 	/* Read */
 	lut_base = SEQID_READ * 4;
 
-	qspi_writel(q, LUT0(CMD, PAD1, read_op) | LUT1(ADDR, PAD1, addrlen),
-			base + QUADSPI_LUT(lut_base));
-	qspi_writel(q, LUT0(DUMMY, PAD1, read_dm) |
-		    LUT1(FSL_READ, PAD4, rxfifo),
-			base + QUADSPI_LUT(lut_base + 1));
+	if (nor->flash_read == SPI_NOR_FAST) {
+		qspi_writel(q, LUT0(CMD, PAD1, read_op) |
+			    LUT1(ADDR, PAD1, addrlen),
+				base + QUADSPI_LUT(lut_base));
+		qspi_writel(q,  LUT0(DUMMY, PAD1, read_dm) |
+			    LUT1(FSL_READ, PAD1, rxfifo),
+				base + QUADSPI_LUT(lut_base + 1));
+	} else if (nor->flash_read == SPI_NOR_QUAD) {
+		qspi_writel(q, LUT0(CMD, PAD1, read_op) |
+			    LUT1(ADDR, PAD1, addrlen),
+				base + QUADSPI_LUT(lut_base));
+		qspi_writel(q, LUT0(DUMMY, PAD1, read_dm) |
+			    LUT1(FSL_READ, PAD4, rxfifo),
+				base + QUADSPI_LUT(lut_base + 1));
+	}
 
 	/* Write enable */
 	lut_base = SEQID_WREN * 4;
@@ -468,6 +478,7 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
 {
 	switch (cmd) {
 	case SPINOR_OP_READ_1_1_4:
+	case SPINOR_OP_READ_FAST:
 		return SEQID_READ;
 	case SPINOR_OP_WREN:
 		return SEQID_WREN;
@@ -963,6 +974,7 @@ static int fsl_qspi_probe(struct platform_device *pdev)
 	struct spi_nor *nor;
 	struct mtd_info *mtd;
 	int ret, i = 0;
+	enum read_mode mode = SPI_NOR_QUAD;
 
 	q = devm_kzalloc(dev, sizeof(*q), GFP_KERNEL);
 	if (!q)
@@ -1064,7 +1076,10 @@ static int fsl_qspi_probe(struct platform_device *pdev)
 		/* set the chip address for READID */
 		fsl_qspi_set_base_addr(q, nor);
 
-		ret = spi_nor_scan(nor, NULL, SPI_NOR_QUAD);
+		ret = of_property_read_bool(np, "m25p,fast-read");
+		mode = (ret) ? SPI_NOR_FAST : SPI_NOR_QUAD;
+
+		ret = spi_nor_scan(nor, NULL, mode);
 		if (ret)
 			goto mutex_failed;
 
-- 
2.1.0.27.g96db324



From B56489 at freescale.com  Mon Feb  1 03:30:08 2016
From: B56489 at freescale.com (Yunhui Cui)
Date: Mon, 1 Feb 2016 19:30:08 +0800
Subject: [PATCH v2 4/4] mtd:spi_nor: Disable Micron flash HW protection
In-Reply-To: <1454326208-4533-1-git-send-email-B56489@freescale.com>
References: <1454326208-4533-1-git-send-email-B56489@freescale.com>
Message-ID: <1454326208-4533-4-git-send-email-B56489@freescale.com>

For Micron family ,The status register write enable/disable bit,
provides hardware data protection for the device.
When the enable/disable bit is set to 1, the status register
nonvolatile bits become read-only and the WRITE STATUS REGISTER
operation will not execute.

Signed-off-by: Yunhui Cui <B56489 at freescale.com>
---
 drivers/mtd/spi-nor/spi-nor.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index ed0c19c..917f814 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -39,6 +39,7 @@
 
 #define SPI_NOR_MAX_ID_LEN	6
 #define SPI_NOR_MAX_ADDR_WIDTH	4
+#define SPI_NOR_MICRON_WRITE_ENABLE	0x7f
 
 struct flash_info {
 	char		*name;
@@ -1238,6 +1239,14 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
 		write_sr(nor, 0);
 	}
 
+	if (JEDEC_MFR(info) == SNOR_MFR_MICRON) {
+		ret = read_sr(nor);
+		ret &= SPI_NOR_MICRON_WRITE_ENABLE;
+
+		write_enable(nor);
+		write_sr(nor, ret);
+	}
+
 	if (!mtd->name)
 		mtd->name = dev_name(dev);
 	mtd->priv = nor;
-- 
2.1.0.27.g96db324



From djkurtz at chromium.org  Mon Feb  1 03:42:37 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Mon, 1 Feb 2016 19:42:37 +0800
Subject: [PATCH v5] i2c: mt8173: add 4GB mode support in i2c driver.
In-Reply-To: <1454291910-19870-1-git-send-email-liguo.zhang@mediatek.com>
References: <1454291910-19870-1-git-send-email-liguo.zhang@mediatek.com>
Message-ID: <CAGS+omAaj6afPrFYyFB3M-g6bpJeVDgJvYJx5rtu5kjCH=Gtzg@mail.gmail.com>

On Mon, Feb 1, 2016 at 9:58 AM, Liguo Zhang <liguo.zhang at mediatek.com> wrote:
> If 4GB mode is enable, we should add 4gb mode support in i2c driver.
> Set 4GB mode register to support 4GB mode.
>
> Signed-off-by: Liguo Zhang <liguo.zhang at mediatek.com>
> ---
> change in v5:
> Use BIT_ULL() to fix kernel building warning.
> change in v4:
> Use BIT_ULL() to fix kernel building warning.
> change in v3:
> Only inline the computation of reg_4g_mode in mtk_i2c_set_4g_mode().
> change in v2:
> Define a static inline function mtk_i2c_set_4g_mode() for support 4g mode.
> ---
>  drivers/i2c/busses/i2c-mt65xx.c | 42 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index aec8e6c..e054205 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -60,6 +60,7 @@
>  #define I2C_DMA_INT_FLAG_NONE          0x0000
>  #define I2C_DMA_CLR_FLAG               0x0000
>  #define I2C_DMA_HARD_RST               0x0002
> +#define I2C_DMA_4G_MODE                        0x0001
>
>  #define I2C_DEFAULT_SPEED              100000  /* hz */
>  #define MAX_FS_MODE_SPEED              400000
> @@ -88,6 +89,8 @@ enum DMA_REGS_OFFSET {
>         OFFSET_RX_MEM_ADDR = 0x20,
>         OFFSET_TX_LEN = 0x24,
>         OFFSET_RX_LEN = 0x28,
> +       OFFSET_TX_4G_MODE = 0x54,
> +       OFFSET_RX_4G_MODE = 0x58,
>  };
>
>  enum i2c_trans_st_rs {
> @@ -133,6 +136,7 @@ struct mtk_i2c_compatible {
>         unsigned char dcm: 1;
>         unsigned char auto_restart: 1;
>         unsigned char aux_len_reg: 1;
> +       unsigned char support_33bits: 1;
>  };
>
>  struct mtk_i2c {
> @@ -182,6 +186,7 @@ static const struct mtk_i2c_compatible mt6577_compat = {
>         .dcm = 1,
>         .auto_restart = 0,
>         .aux_len_reg = 0,
> +       .support_33bits = 0,
>  };
>
>  static const struct mtk_i2c_compatible mt6589_compat = {
> @@ -190,6 +195,7 @@ static const struct mtk_i2c_compatible mt6589_compat = {
>         .dcm = 0,
>         .auto_restart = 0,
>         .aux_len_reg = 0,
> +       .support_33bits = 0,
>  };
>
>  static const struct mtk_i2c_compatible mt8173_compat = {
> @@ -198,6 +204,7 @@ static const struct mtk_i2c_compatible mt8173_compat = {
>         .dcm = 1,
>         .auto_restart = 1,
>         .aux_len_reg = 1,
> +       .support_33bits = 1,
>  };
>
>  static const struct of_device_id mtk_i2c_of_match[] = {
> @@ -366,6 +373,11 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned int parent_clk,
>         return 0;
>  }
>
> +static inline u32 mtk_i2c_set_4g_mode(dma_addr_t addr)
> +{
> +       return (addr & BIT_ULL(32)) ? I2C_DMA_4G_MODE : I2C_DMA_CLR_FLAG;
> +}
> +
>  static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
>                                int num, int left_num)
>  {
> @@ -373,6 +385,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
>         u16 start_reg;
>         u16 control_reg;
>         u16 restart_flag = 0;
> +       u32 reg_4g_mode = 0;

nit: unnecessary init (as Yingjoe mentioned earlier).

Otherwise, this one is:

Reviewed-by: Daniel Kurtz <djkurtz at chromium.org>


From ynorov at caviumnetworks.com  Mon Feb  1 03:42:51 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Mon, 1 Feb 2016 14:42:51 +0300
Subject: [PATCH 1/5] all: s390: move wrapper infrastructure to generic
 headers
In-Reply-To: <20160128163109.GA8529@yury-N73SV>
References: <1453741047-5498-1-git-send-email-ynorov@caviumnetworks.com>
 <1453741047-5498-2-git-send-email-ynorov@caviumnetworks.com>
 <20160128121618.GB5418@osiris> <20160128163109.GA8529@yury-N73SV>
Message-ID: <20160201114251.GB973@yury-N73SV>

On Thu, Jan 28, 2016 at 07:31:09PM +0300, Yury Norov wrote:
> On Thu, Jan 28, 2016 at 01:16:18PM +0100, Heiko Carstens wrote:
> > Hello Yury,
> > 
> > On Mon, Jan 25, 2016 at 07:57:23PM +0300, Yury Norov wrote:
> > > __SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so it's
> > > moved to arch/s390/include/asm/compat.h. Generic declaration assumes that long,
> > > unsigned long and pointer types are all 32-bit length.
> > > 
> > > linux/syscalls_structs.h header is introduced, because from now (see next patch)
> > > structure types listed there are needed for both normal and compat mode.
> > > 
> > > cond_syscall_wrapped now defined two symbols: sys_foo() and compat_sys_foo(), if
> > > compat wrappers are enabled.
> > > 
> > > Here __SC_WRAP() macro is introduced as well. s390 doesn't need it as it uses
> > > asm-generated syscall table. But architectures that generate that tables with
> > > C code (ARM64/ILP32) should redefine it as '#define __SC_WRAP(name) compat_##name'.
> > > 
> > > Signed-off-by: Yury Norov <ynorov at caviumnetworks.com>
> > 
> > ...
> > 
> 
> Hi Heiko,
> 
> > How about if you rename SYSCALL_DEFINE_WRAP to SYSCALL_COMPAT_DEFINE which
> > has the semantics that no dedicated compat system call exists (aka system
> > call is compat safe).
> > 
> > Then convert all existing SYSCALL_DEFINE'd system calls for which no compat
> > variant exists to SYSCALL_COMPAT_DEFINE.
> > 
> > This would allow to specify "compat_sys_<syscallname>" in the compat system
> > call table for _all_ system calls.
> > 
> 
> We can modify SYSCALL_DEFINEx macro to declare weak "compat_sys_<syscallname>"
> symbol for each syscall. So if strong compat symbol will be declared
> somwere else, it will owerride the weak one. Being under COMPAT_WRAPPER
> config, it will not affect someone else except s390 and aarch64/ilp32.
> The downside of this approach is that we'll have to move wrapper
> machinery to 'include/linux/syscalls.h', thought under wrapper config.
> 
> > No need to look up if a compat variant (or wrapper) exists or
> > sys_<syscallname> should be used instead. Also no possibility for security
> > bugs that could creep in because SYSCALL_DEFINE has been used instead of
> > SYSCALL_DEFINE_WRAP.
> 
> If we'll choose to stay with current approach, we'll definitely need
> to update documentation.
> 
> > 
> > Ideally the implementation would only generate an alias if no sign/zero
> > extension is necessary.
> > 
> > Trivially this would be true for system calls without arguments like e.g.
> > sys_fork() which would get a compat_sys_fork alias without any further
> > code.
> > 
> > I'm not sure how difficult it is to implement the same logic for system
> > calls that have parameters. That is: either generate a
> > compat_sys_<syscallname> wrapper function, or if the SYSCALL_COMPAT_DEFINE
> > macro figures out that no zero sign extension is required, only an alias
> > without any additional code.
> > 
> > I think in the long term something like this is much easier to maintain.
> > 
> > Does that make sense?
> 
> For me, the most important adwantage of this approach is that we don't
> need the list of 'magic' system calls anymore. It's even more
> important if we'll face a requirement to support ABI that differs from
> both natural and ilp32 ABIs. New __SC_COMPAT_CAST will do all the job
> for us.
> 
> The downsides are that we'll have unneeded wrappers for some syscalls,
> if linker will not clear them, and wasting of space if we'll find no
> way how to explain compiler to generate simple alias when it's
> enough... 
> 
> I'll play with it and write you what I'll come to.
> 
> Yury.

Hi Heiko,

I tried this idea, and I don't like what happened.
 - Wrappers around safe syscalls does exist. We can remove it by
   overcomplicating __SC_COMPAT_CAST, but I don't like it.
 - We still need to declare numerous list of new compat syscalls.
   And it becomes even bigger, as we need to declare all compat
   syscall versions not declared in include/linux/compat.h already.
   (Currently - only for unsafe syscalls.)
 - 'Weak' trick doesn't work for the whole kernel, so we'd figure out
   some new prefix for wrapped syscalls. Or declare all non-compat
   syscalls explicitly with SYSCALL_COMPAT_DEFINE. So the list of
   replacements grow. And for me, it's harder to explain why we are
   wrapping safe syscalls. Or we introduce another bunch of useless
   wrappers (with new prefix), and have to handle it in non-compat code.
 - With all listed above, we move all wrapper logic to non-compat
   'include/linux/syscalls.h' header. Which is not a good idea, if it
   doesn't benefit us much in return.

> > No need to look up if a compat variant (or wrapper) exists or
> > sys_<syscallname> should be used instead. Also no possibility for security
> > bugs that could creep in because SYSCALL_DEFINE has been used instead of
> > SYSCALL_DEFINE_WRAP.

I thought again about it. With current version, it's very easy to
define whether we have wrapper or not - just by macro we use. Once
reviewed, this list is hardly to be changed frequently. If someone is
introducing new syscall, it will attract much attention, so security
risk is minimal.

Maybe I missed some elegant implementation, and if so  I'll be happy
if someone'll point me out. But with what I see, I'd vote for what we
have now. (Plus description in docs, plus renaming new macro.)

Yury.


From majun258 at huawei.com  Mon Feb  1 03:44:54 2016
From: majun258 at huawei.com (MaJun)
Date: Mon, 1 Feb 2016 19:44:54 +0800
Subject: [RFC PATCH] irq/mbigen:Fix the problem of IO remap for duplicated
 physical address in mbigen driver
Message-ID: <1454327094-7848-1-git-send-email-majun258@huawei.com>

From: Ma Jun <majun258 at huawei.com>

For mbigen module, there is a special case that more than one mbigen 
device nodes use the same reg definition in DTS when these devices
exist in the same mbigen hardware module. 

mbigen_dev1:intc_dev1 {
	...
	reg = <0x0 0xc0080000 0x0 0x10000>;
	...
};

mbigen_dev2:intc_dev2 {
	...
	reg = <0x0 0xc0080000 0x0 0x10000>;
	...
};

On this case, devm_ioremap_resource() returns fail with info
"can't request region for resource" because of memory region check.

Because we only need to program 1 into corresponding bit into status 
register of mbigen to clear the interrupt status during runtime,
I think we can replace devm_ioremap_resource() by devm_ioremap().

Signed-off-by: Ma Jun <majun258 at huawei.com>
---
 drivers/irqchip/irq-mbigen.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 4dd3eb8..b19e528 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -250,7 +250,7 @@ static int mbigen_device_probe(struct platform_device *pdev)
 	mgn_chip->pdev = pdev;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	mgn_chip->base = devm_ioremap_resource(&pdev->dev, res);
+	mgn_chip->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
 	if (IS_ERR(mgn_chip->base))
 		return PTR_ERR(mgn_chip->base);
 
-- 
1.7.1




From matthias.bgg at gmail.com  Mon Feb  1 03:46:39 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 1 Feb 2016 12:46:39 +0100
Subject: [PATCH v6] clk: mediatek: Export CPU mux clocks for CPU frequency
 control
In-Reply-To: <CAGS+omBWEVac_in-ZDurf4R5tje3hzJPyr5nsP2Z_v7F8sSCUg@mail.gmail.com>
References: <1442230072-31593-1-git-send-email-pi-cheng.chen@linaro.org>
 <CAGS+omCkYTPyjMk6QaoxGAL4QVU8VcpWyFqWhST+iP2EFRcRYg@mail.gmail.com>
 <CALx668XVnhhLJWs7RBxvaX=SU=S9=wFVT9HMDP2edqiH4Jio4A@mail.gmail.com>
 <20151217090628.GA317@quark.deferred.io>
 <CAGS+omBWEVac_in-ZDurf4R5tje3hzJPyr5nsP2Z_v7F8sSCUg@mail.gmail.com>
Message-ID: <56AF459F.2050808@gmail.com>



On 26/01/16 11:23, Daniel Kurtz wrote:
> Hi Michael, Pi-Cheng,
>
> On Thu, Dec 17, 2015 at 1:06 AM, Michael Turquette
> <mturquette at baylibre.com> wrote:
>>
>> On 12/01, Pi-Cheng Chen wrote:
>>> On Mon, Nov 30, 2015 at 11:48 AM, Daniel Kurtz <djkurtz at chromium.org> wrote:
>>>> Hi Pi-Cheng and Michael,
>>>>
>>>> On Mon, Sep 14, 2015 at 7:27 PM, Pi-Cheng Chen <pi-cheng.chen at linaro.org> wrote:
>>>>> From: "pi-cheng.chen" <pi-cheng.chen at linaro.org>
>>>>>
>>>>> This patch adds CPU mux clocks which are used by Mediatek cpufreq driver
>>>>> for intermediate clock source switching.
>>>>
>>>> It looks like this patch was never picked up.
>>>> It is required for MT8173 cpufreq.
>>>>
>>>> What is the plan to get this one merged?
>>>
>>> Hi Dan,
>>> Mike is working on a new CCF feature called "coordinated clock rate changes"
>>> which would help to migrate mt8173-cpufreq driver to generic cpufreq-dt
>>> driver, and I am working with him to port MT8173 clock driver on the new
>>> feature. So I think that's why this patch was not picked since it will
>>> be migrated to new implementation once the new feature's ready.
>>>
>>> @Mike:
>>> Are you plannig to post those patches on the mailing list ?
>>> Or is it fine for you to take this first and then I will refine it for
>>> the new feature later?
>>
>> I plan to post those patches next week.
>
> Were these patches ever posted?
> Or should we consider going ahead and trying to merge this 4-month old
> MTK CPU mux clock patch into v4.5 before it is too late?
>

It's already too late for v4.5. The -rc are mostly bug fixes and new 
features get merged after the official v4.5 release. They will show up 
in v4.6-rc1


From djkurtz at chromium.org  Mon Feb  1 03:48:41 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Mon, 1 Feb 2016 19:48:41 +0800
Subject: [PATCH v6] clk: mediatek: Export CPU mux clocks for CPU frequency
 control
In-Reply-To: <56AF459F.2050808@gmail.com>
References: <1442230072-31593-1-git-send-email-pi-cheng.chen@linaro.org>
 <CAGS+omCkYTPyjMk6QaoxGAL4QVU8VcpWyFqWhST+iP2EFRcRYg@mail.gmail.com>
 <CALx668XVnhhLJWs7RBxvaX=SU=S9=wFVT9HMDP2edqiH4Jio4A@mail.gmail.com>
 <20151217090628.GA317@quark.deferred.io>
 <CAGS+omBWEVac_in-ZDurf4R5tje3hzJPyr5nsP2Z_v7F8sSCUg@mail.gmail.com>
 <56AF459F.2050808@gmail.com>
Message-ID: <CAGS+omDd8KTd1jtmDdzr3t=NGdsY0ND4gepmmyVuh0dD=fJ+VQ@mail.gmail.com>

On Mon, Feb 1, 2016 at 7:46 PM, Matthias Brugger <matthias.bgg at gmail.com> wrote:
>
>
> On 26/01/16 11:23, Daniel Kurtz wrote:
>>
>> Hi Michael, Pi-Cheng,
>>
>> On Thu, Dec 17, 2015 at 1:06 AM, Michael Turquette
>> <mturquette at baylibre.com> wrote:
>>>
>>>
>>> On 12/01, Pi-Cheng Chen wrote:
>>>>
>>>> On Mon, Nov 30, 2015 at 11:48 AM, Daniel Kurtz <djkurtz at chromium.org>
>>>> wrote:
>>>>>
>>>>> Hi Pi-Cheng and Michael,
>>>>>
>>>>> On Mon, Sep 14, 2015 at 7:27 PM, Pi-Cheng Chen
>>>>> <pi-cheng.chen at linaro.org> wrote:
>>>>>>
>>>>>> From: "pi-cheng.chen" <pi-cheng.chen at linaro.org>
>>>>>>
>>>>>> This patch adds CPU mux clocks which are used by Mediatek cpufreq
>>>>>> driver
>>>>>> for intermediate clock source switching.
>>>>>
>>>>>
>>>>> It looks like this patch was never picked up.
>>>>> It is required for MT8173 cpufreq.
>>>>>
>>>>> What is the plan to get this one merged?
>>>>
>>>>
>>>> Hi Dan,
>>>> Mike is working on a new CCF feature called "coordinated clock rate
>>>> changes"
>>>> which would help to migrate mt8173-cpufreq driver to generic cpufreq-dt
>>>> driver, and I am working with him to port MT8173 clock driver on the new
>>>> feature. So I think that's why this patch was not picked since it will
>>>> be migrated to new implementation once the new feature's ready.
>>>>
>>>> @Mike:
>>>> Are you plannig to post those patches on the mailing list ?
>>>> Or is it fine for you to take this first and then I will refine it for
>>>> the new feature later?
>>>
>>>
>>> I plan to post those patches next week.
>>
>>
>> Were these patches ever posted?
>> Or should we consider going ahead and trying to merge this 4-month old
>> MTK CPU mux clock patch into v4.5 before it is too late?
>>
>
> It's already too late for v4.5. The -rc are mostly bug fixes and new
> features get merged after the official v4.5 release. They will show up in
> v4.6-rc1

Which will show up in v4.6-rc1?  MediaTek's CPU mux clocks, or Mike's
"coordinated clock rate changes"?


From stillcompiling at gmail.com  Mon Feb  1 03:54:53 2016
From: stillcompiling at gmail.com (Joshua Clayton)
Date: Mon, 01 Feb 2016 03:54:53 -0800
Subject: [PATCH 1/2] of: add vendor prefix for UniWest
In-Reply-To: <20160201112153.GD10671@tiger>
References: <b11bf2208fe30b96c4d82e634e8abe04343754de.1452717014.git.stillcompiling@gmail.com>
 <20160201112153.GD10671@tiger>
Message-ID: <1558714.BL5qCUPStK@diplodocus>

Thanks, Shawn,
On Monday, February 01, 2016 07:21:53 PM Shawn Guo wrote:
> On Wed, Jan 13, 2016 at 12:45:11PM -0800, Joshua Clayton wrote:
> > United Western Technologies Corp, known primarily as UniWest,
> > is a manufacturer of eddy current and ultrasonic testing equipment.
> > 
> > Signed-off-by: Joshua Clayton <stillcompiling at gmail.com>
> > ---
> >  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index 55df1d4..7dabdee 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -230,6 +230,7 @@ toradex	Toradex AG
> >  toshiba	Toshiba Corporation
> >  toumaz	Toumaz
> >  tplink	TP-LINK Technologies Co., Ltd.
> > +uniwest	United Western Technologies Corp (UniWest)
> 
> As far as I know, it should be added in alphabetical order.
There is a V2 of this patch, which is in alphabetical order and got an ack from Rob Herring
http://lkml.iu.edu/hypermail/linux/kernel/1601.1/05563.html

I have not sent a v2 of the dts, (patch 2/2) as it didn't get any review comments. Should I resend it?

> 
> Shawn
> 
> >  tronfy	Tronfy
> >  truly	Truly Semiconductors Limited
> >  upisemi	uPI Semiconductor Corp.
> 



From mark.rutland at arm.com  Mon Feb  1 03:57:18 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 1 Feb 2016 11:57:18 +0000
Subject: [RFC PATCH] irq/mbigen:Fix the problem of IO remap for
 duplicated physical address in mbigen driver
In-Reply-To: <1454327094-7848-1-git-send-email-majun258@huawei.com>
References: <1454327094-7848-1-git-send-email-majun258@huawei.com>
Message-ID: <20160201115717.GD674@leverpostej>

On Mon, Feb 01, 2016 at 07:44:54PM +0800, MaJun wrote:
> From: Ma Jun <majun258 at huawei.com>
> 
> For mbigen module, there is a special case that more than one mbigen 
> device nodes use the same reg definition in DTS when these devices
> exist in the same mbigen hardware module. 
> 
> mbigen_dev1:intc_dev1 {
> 	...
> 	reg = <0x0 0xc0080000 0x0 0x10000>;
> 	...
> };
> 
> mbigen_dev2:intc_dev2 {
> 	...
> 	reg = <0x0 0xc0080000 0x0 0x10000>;
> 	...
> };

This doesn't sound right. If they exist in the same place, and have the
same reg, they _are_ the same device.

You'll need to explain this better.

> On this case, devm_ioremap_resource() returns fail with info
> "can't request region for resource" because of memory region check.
> 
> Because we only need to program 1 into corresponding bit into status 
> register of mbigen to clear the interrupt status during runtime,
> I think we can replace devm_ioremap_resource() by devm_ioremap().
> 
> Signed-off-by: Ma Jun <majun258 at huawei.com>
> ---
>  drivers/irqchip/irq-mbigen.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index 4dd3eb8..b19e528 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -250,7 +250,7 @@ static int mbigen_device_probe(struct platform_device *pdev)
>  	mgn_chip->pdev = pdev;
>  
>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -	mgn_chip->base = devm_ioremap_resource(&pdev->dev, res);
> +	mgn_chip->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));

These two behaving differently doesn't seem correct either...

Mark.

>  	if (IS_ERR(mgn_chip->base))
>  		return PTR_ERR(mgn_chip->base);
>  
> -- 
> 1.7.1
> 
> 


From heiko at sntech.de  Mon Feb  1 04:00:43 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Mon, 01 Feb 2016 13:00:43 +0100
Subject: [PATCH v5] pinctrl: rockchip: add support for the rk3399
In-Reply-To: <1454295501-32165-1-git-send-email-david.wu@rock-chips.com>
References: <1454295501-32165-1-git-send-email-david.wu@rock-chips.com>
Message-ID: <2810569.NLb8VW90eE@diego>

Hi David,

Am Montag, 1. Februar 2016, 10:58:21 schrieb David Wu:
> The pinctrl of rk3399 is much different from other's,
> especially the 3bits of drive strength.
> 
> Signed-off-by: David Wu <david.wu at rock-chips.com>
> Reviewed-by: Heiko Stuebner <heiko at sntech.de>

looks nice now :-)


Thanks
Heiko

> ---
> Changes in v5:
> - merge the binding-doc-addition in one patch (Linus Heiko)
> - fix the comment of bit15 drive setting (Heiko)
> 
> Change in v4: None
> 
> Change in v3:
> - use switch-case to distinguish special 3bits width per pin (Heiko)
> 
> Change in v2:
> - need spin_unlock_irqrestore for set drive default case
> 
>  .../bindings/pinctrl/rockchip,pinctrl.txt          |   1 +
>  drivers/pinctrl/pinctrl-rockchip.c                 | 369
> ++++++++++++++++++++- 2 files changed, 356 insertions(+), 14 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index
> 391ef4b..3bb9456 100644
> --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> @@ -22,6 +22,7 @@ Required properties for iomux controller:
>    - compatible: one of "rockchip,rk2928-pinctrl",
> "rockchip,rk3066a-pinctrl" "rockchip,rk3066b-pinctrl",
> "rockchip,rk3188-pinctrl"
>  		       "rockchip,rk3288-pinctrl", "rockchip,rk3368-pinctrl"
> +		       "rockchip,rk3399-pinctrl"
>    - rockchip,grf: phandle referencing a syscon providing the
>  	 "general register files"
> 
> diff --git a/drivers/pinctrl/pinctrl-rockchip.c
> b/drivers/pinctrl/pinctrl-rockchip.c index a065112..d485f22 100644
> --- a/drivers/pinctrl/pinctrl-rockchip.c
> +++ b/drivers/pinctrl/pinctrl-rockchip.c
> @@ -64,6 +64,7 @@ enum rockchip_pinctrl_type {
>  	RK3188,
>  	RK3288,
>  	RK3368,
> +	RK3399,
>  };
> 
>  /**
> @@ -86,6 +87,31 @@ struct rockchip_iomux {
>  };
> 
>  /**
> + * enum type index corresponding to rockchip_perpin_drv_list arrays index.
> + */
> +enum rockchip_pin_drv_type {
> +	DRV_TYPE_IO_DEFAULT = 0,
> +	DRV_TYPE_IO_1V8_OR_3V0,
> +	DRV_TYPE_IO_1V8_ONLY,
> +	DRV_TYPE_IO_1V8_3V0_AUTO,
> +	DRV_TYPE_IO_3V3_ONLY,
> +	DRV_TYPE_MAX
> +};
> +
> +/**
> + * @drv_type: drive strength variant using rockchip_perpin_drv_type
> + * @offset: if initialized to -1 it will be autocalculated, by specifying
> + *	    an initial offset value the relevant source offset can be reset
> + *	    to a new value for autocalculating the following drive strength
> + *	    registers. if used chips own cal_drv func instead to calculate
> + *	    registers offset, the variant could be ignored.
> + */
> +struct rockchip_drv {
> +	enum rockchip_pin_drv_type	drv_type;
> +	int				offset;
> +};
> +
> +/**
>   * @reg_base: register base of the gpio bank
>   * @reg_pull: optional separate register for additional pull settings
>   * @clk: clock of the gpio bank
> @@ -96,6 +122,7 @@ struct rockchip_iomux {
>   * @name: name of the bank
>   * @bank_num: number of the bank, to account for holes
>   * @iomux: array describing the 4 iomux sources of the bank
> + * @drv: array describing the 4 drive strength sources of the bank
>   * @valid: are all necessary informations present
>   * @of_node: dt node of this bank
>   * @drvdata: common pinctrl basedata
> @@ -115,6 +142,7 @@ struct rockchip_pin_bank {
>  	char				*name;
>  	u8				bank_num;
>  	struct rockchip_iomux		iomux[4];
> +	struct rockchip_drv		drv[4];
>  	bool				valid;
>  	struct device_node		*of_node;
>  	struct rockchip_pinctrl		*drvdata;
> @@ -151,6 +179,47 @@ struct rockchip_pin_bank {
>  		},							\
>  	}
> 
> +#define PIN_BANK_DRV_FLAGS(id, pins, label, type0, type1, type2, type3) \
> +	{								\
> +		.bank_num	= id,					\
> +		.nr_pins	= pins,					\
> +		.name		= label,				\
> +		.iomux		= {					\
> +			{ .offset = -1 },				\
> +			{ .offset = -1 },				\
> +			{ .offset = -1 },				\
> +			{ .offset = -1 },				\
> +		},							\
> +		.drv		= {					\
> +			{ .drv_type = type0, .offset = -1 },		\
> +			{ .drv_type = type1, .offset = -1 },		\
> +			{ .drv_type = type2, .offset = -1 },		\
> +			{ .drv_type = type3, .offset = -1 },		\
> +		},							\
> +	}
> +
> +#define PIN_BANK_IOMUX_DRV_FLAGS_OFFSET(id, pins, label, iom0, iom1,	\
> +					iom2, iom3, drv0, drv1, drv2,	\
> +					drv3, offset0, offset1,		\
> +					offset2, offset3)		\
> +	{								\
> +		.bank_num	= id,					\
> +		.nr_pins	= pins,					\
> +		.name		= label,				\
> +		.iomux		= {					\
> +			{ .type = iom0, .offset = -1 },			\
> +			{ .type = iom1, .offset = -1 },			\
> +			{ .type = iom2, .offset = -1 },			\
> +			{ .type = iom3, .offset = -1 },			\
> +		},							\
> +		.drv		= {					\
> +			{ .drv_type = drv0, .offset = offset0 },	\
> +			{ .drv_type = drv1, .offset = offset1 },	\
> +			{ .drv_type = drv2, .offset = offset2 },	\
> +			{ .drv_type = drv3, .offset = offset3 },	\
> +		},							\
> +	}
> +
>  /**
>   */
>  struct rockchip_pin_ctrl {
> @@ -161,6 +230,9 @@ struct rockchip_pin_ctrl {
>  	enum rockchip_pinctrl_type	type;
>  	int				grf_mux_offset;
>  	int				pmu_mux_offset;
> +	int				grf_drv_offset;
> +	int				pmu_drv_offset;
> +
>  	void	(*pull_calc_reg)(struct rockchip_pin_bank *bank,
>  				    int pin_num, struct regmap **regmap,
>  				    int *reg, u8 *bit);
> @@ -676,7 +748,68 @@ static void rk3368_calc_drv_reg_and_bit(struct
> rockchip_pin_bank *bank, }
>  }
> 
> -static int rockchip_perpin_drv_list[] = { 2, 4, 8, 12 };
> +#define RK3399_PULL_GRF_OFFSET		0xe040
> +#define RK3399_PULL_PMU_OFFSET		0x40
> +#define RK3399_DRV_3BITS_PER_PIN	3
> +
> +static void rk3399_calc_pull_reg_and_bit(struct rockchip_pin_bank *bank,
> +					 int pin_num, struct regmap **regmap,
> +					 int *reg, u8 *bit)
> +{
> +	struct rockchip_pinctrl *info = bank->drvdata;
> +
> +	/* The bank0:16 and bank1:32 pins are located in PMU */
> +	if ((bank->bank_num == 0) || (bank->bank_num == 1)) {
> +		*regmap = info->regmap_pmu;
> +		*reg = RK3399_PULL_PMU_OFFSET;
> +
> +		*reg += bank->bank_num * RK3188_PULL_BANK_STRIDE;
> +
> +		*reg += ((pin_num / RK3188_PULL_PINS_PER_REG) * 4);
> +		*bit = pin_num % RK3188_PULL_PINS_PER_REG;
> +		*bit *= RK3188_PULL_BITS_PER_PIN;
> +	} else {
> +		*regmap = info->regmap_base;
> +		*reg = RK3399_PULL_GRF_OFFSET;
> +
> +		/* correct the offset, as we're starting with the 3rd bank */
> +		*reg -= 0x20;
> +		*reg += bank->bank_num * RK3188_PULL_BANK_STRIDE;
> +		*reg += ((pin_num / RK3188_PULL_PINS_PER_REG) * 4);
> +
> +		*bit = (pin_num % RK3188_PULL_PINS_PER_REG);
> +		*bit *= RK3188_PULL_BITS_PER_PIN;
> +	}
> +}
> +
> +static void rk3399_calc_drv_reg_and_bit(struct rockchip_pin_bank *bank,
> +					int pin_num, struct regmap **regmap,
> +					int *reg, u8 *bit)
> +{
> +	struct rockchip_pinctrl *info = bank->drvdata;
> +	int drv_num = (pin_num / 8);
> +
> +	/*  The bank0:16 and bank1:32 pins are located in PMU */
> +	if ((bank->bank_num == 0) || (bank->bank_num == 1))
> +		*regmap = info->regmap_pmu;
> +	else
> +		*regmap = info->regmap_base;
> +
> +	*reg = bank->drv[drv_num].offset;
> +	if ((bank->drv[drv_num].drv_type == DRV_TYPE_IO_1V8_3V0_AUTO) ||
> +	    (bank->drv[drv_num].drv_type == DRV_TYPE_IO_3V3_ONLY))
> +		*bit = (pin_num % 8) * 3;
> +	else
> +		*bit = (pin_num % 8) * 2;
> +}
> +
> +static int rockchip_perpin_drv_list[DRV_TYPE_MAX][8] = {
> +	{ 2, 4, 8, 12, -1, -1, -1, -1 },
> +	{ 3, 6, 9, 12, -1, -1, -1, -1 },
> +	{ 5, 10, 15, 20, -1, -1, -1, -1 },
> +	{ 4, 6, 8, 10, 12, 14, 16, 18 },
> +	{ 4, 7, 10, 13, 16, 19, 22, 26 }
> +};
> 
>  static int rockchip_get_drive_perpin(struct rockchip_pin_bank *bank,
>  				     int pin_num)
> @@ -685,19 +818,74 @@ static int rockchip_get_drive_perpin(struct
> rockchip_pin_bank *bank, struct rockchip_pin_ctrl *ctrl = info->ctrl;
>  	struct regmap *regmap;
>  	int reg, ret;
> -	u32 data;
> +	u32 data, temp, rmask_bits;
>  	u8 bit;
> +	int drv_type = bank->drv[pin_num / 8].drv_type;
> 
>  	ctrl->drv_calc_reg(bank, pin_num, &regmap, &reg, &bit);
> 
> +	switch (drv_type) {
> +	case DRV_TYPE_IO_1V8_3V0_AUTO:
> +	case DRV_TYPE_IO_3V3_ONLY:
> +		rmask_bits = RK3399_DRV_3BITS_PER_PIN;
> +		switch (bit) {
> +		case 0 ... 12:
> +			/* regular case, nothing to do */
> +			break;
> +		case 15:
> +			/*
> +			 * drive-strength offset is special, as it is
> +			 * spread over 2 registers
> +			 */
> +			ret = regmap_read(regmap, reg, &data);
> +			if (ret)
> +				return ret;
> +
> +			ret = regmap_read(regmap, reg + 0x4, &temp);
> +			if (ret)
> +				return ret;
> +
> +			/*
> +			 * the bit data[15] contains bit 0 of the value
> +			 * while temp[1:0] contains bits 2 and 1
> +			 */
> +			data >>= 15;
> +			temp &= 0x3;
> +			temp <<= 1;
> +			data |= temp;
> +
> +			return rockchip_perpin_drv_list[drv_type][data];
> +		case 18 ... 21:
> +			/* setting fully enclosed in the second register */
> +			reg += 4;
> +			bit -= 16;
> +			break;
> +		default:
> +			dev_err(info->dev, "unsupported bit: %d for pinctrl drive type: 
%d\n",
> +				bit, drv_type);
> +			return -EINVAL;
> +		}
> +
> +		break;
> +	case DRV_TYPE_IO_DEFAULT:
> +	case DRV_TYPE_IO_1V8_OR_3V0:
> +	case DRV_TYPE_IO_1V8_ONLY:
> +		rmask_bits = RK3288_DRV_BITS_PER_PIN;
> +		break;
> +	default:
> +		dev_err(info->dev, "unsupported pinctrl drive type: %d\n",
> +			drv_type);
> +		return -EINVAL;
> +	}
> +
>  	ret = regmap_read(regmap, reg, &data);
>  	if (ret)
>  		return ret;
> 
>  	data >>= bit;
> -	data &= (1 << RK3288_DRV_BITS_PER_PIN) - 1;
> +	data &= (1 << rmask_bits) - 1;
> 
> -	return rockchip_perpin_drv_list[data];
> +	return rockchip_perpin_drv_list[drv_type][data];
>  }
> 
>  static int rockchip_set_drive_perpin(struct rockchip_pin_bank *bank,
> @@ -708,16 +896,23 @@ static int rockchip_set_drive_perpin(struct
> rockchip_pin_bank *bank, struct regmap *regmap;
>  	unsigned long flags;
>  	int reg, ret, i;
> -	u32 data, rmask;
> +	u32 data, rmask, rmask_bits, temp;
>  	u8 bit;
> +	int drv_type = bank->drv[pin_num / 8].drv_type;
> +
> +	dev_dbg(info->dev, "setting drive of GPIO%d-%d to %d\n",
> +		bank->bank_num, pin_num, strength);
> 
>  	ctrl->drv_calc_reg(bank, pin_num, &regmap, &reg, &bit);
> 
>  	ret = -EINVAL;
> -	for (i = 0; i < ARRAY_SIZE(rockchip_perpin_drv_list); i++) {
> -		if (rockchip_perpin_drv_list[i] == strength) {
> +	for (i = 0; i < ARRAY_SIZE(rockchip_perpin_drv_list[drv_type]); i++) {
> +		if (rockchip_perpin_drv_list[drv_type][i] == strength) {
>  			ret = i;
>  			break;
> +		} else if (rockchip_perpin_drv_list[drv_type][i] < 0) {
> +			ret = rockchip_perpin_drv_list[drv_type][i];
> +			break;
>  		}
>  	}
> 
> @@ -729,8 +924,64 @@ static int rockchip_set_drive_perpin(struct
> rockchip_pin_bank *bank,
> 
>  	spin_lock_irqsave(&bank->slock, flags);
> 
> +	switch (drv_type) {
> +	case DRV_TYPE_IO_1V8_3V0_AUTO:
> +	case DRV_TYPE_IO_3V3_ONLY:
> +		rmask_bits = RK3399_DRV_3BITS_PER_PIN;
> +		switch (bit) {
> +		case 0 ... 12:
> +			/* regular case, nothing to do */
> +			break;
> +		case 15:
> +			/*
> +			 * drive-strength offset is special, as it is spread
> +			 * over 2 registers, the bit data[15] contains bit 0
> +			 * of the value while temp[1:0] contains bits 2 and 1
> +			 */
> +			data = (ret & 0x1) << 15;
> +			temp = (ret >> 0x1) & 0x3;
> +
> +			rmask = BIT(15) | BIT(31);
> +			data |= BIT(31);
> +			ret = regmap_update_bits(regmap, reg, rmask, data);
> +			if (ret) {
> +				spin_unlock_irqrestore(&bank->slock, flags);
> +				return ret;
> +			}
> +
> +			rmask = 0x3 | (0x3 << 16);
> +			temp |= (0x3 << 16);
> +			reg += 0x4;
> +			ret = regmap_update_bits(regmap, reg, rmask, temp);
> +
> +			spin_unlock_irqrestore(&bank->slock, flags);
> +			return ret;
> +		case 18 ... 21:
> +			/* setting fully enclosed in the second register */
> +			reg += 4;
> +			bit -= 16;
> +			break;
> +		default:
> +			spin_unlock_irqrestore(&bank->slock, flags);
> +			dev_err(info->dev, "unsupported bit: %d for pinctrl drive type: 
%d\n",
> +				bit, drv_type);
> +			return -EINVAL;
> +		}
> +		break;
> +	case DRV_TYPE_IO_DEFAULT:
> +	case DRV_TYPE_IO_1V8_OR_3V0:
> +	case DRV_TYPE_IO_1V8_ONLY:
> +		rmask_bits = RK3288_DRV_BITS_PER_PIN;
> +		break;
> +	default:
> +		spin_unlock_irqrestore(&bank->slock, flags);
> +		dev_err(info->dev, "unsupported pinctrl drive type: %d\n",
> +			drv_type);
> +		return -EINVAL;
> +	}
> +
>  	/* enable the write to the equivalent lower bits */
> -	data = ((1 << RK3288_DRV_BITS_PER_PIN) - 1) << (bit + 16);
> +	data = ((1 << rmask_bits) - 1) << (bit + 16);
>  	rmask = data | (data >> 16);
>  	data |= (ret << bit);
> 
> @@ -767,6 +1018,7 @@ static int rockchip_get_pull(struct rockchip_pin_bank
> *bank, int pin_num) case RK3188:
>  	case RK3288:
>  	case RK3368:
> +	case RK3399:
>  		data >>= bit;
>  		data &= (1 << RK3188_PULL_BITS_PER_PIN) - 1;
> 
> @@ -823,6 +1075,7 @@ static int rockchip_set_pull(struct rockchip_pin_bank
> *bank, case RK3188:
>  	case RK3288:
>  	case RK3368:
> +	case RK3399:
>  		spin_lock_irqsave(&bank->slock, flags);
> 
>  		/* enable the write to the equivalent lower bits */
> @@ -1003,6 +1256,7 @@ static bool rockchip_pinconf_pull_valid(struct
> rockchip_pin_ctrl *ctrl, case RK3188:
>  	case RK3288:
>  	case RK3368:
> +	case RK3399:
>  		return (pull != PIN_CONFIG_BIAS_PULL_PIN_DEFAULT);
>  	}
> 
> @@ -1860,7 +2114,7 @@ static struct rockchip_pin_ctrl
> *rockchip_pinctrl_get_soc_data( struct device_node *np;
>  	struct rockchip_pin_ctrl *ctrl;
>  	struct rockchip_pin_bank *bank;
> -	int grf_offs, pmu_offs, i, j;
> +	int grf_offs, pmu_offs, drv_grf_offs, drv_pmu_offs, i, j;
> 
>  	match = of_match_node(rockchip_pinctrl_dt_match, node);
>  	ctrl = (struct rockchip_pin_ctrl *)match->data;
> @@ -1884,6 +2138,8 @@ static struct rockchip_pin_ctrl
> *rockchip_pinctrl_get_soc_data(
> 
>  	grf_offs = ctrl->grf_mux_offset;
>  	pmu_offs = ctrl->pmu_mux_offset;
> +	drv_pmu_offs = ctrl->pmu_drv_offset;
> +	drv_grf_offs = ctrl->grf_drv_offset;
>  	bank = ctrl->pin_banks;
>  	for (i = 0; i < ctrl->nr_banks; ++i, ++bank) {
>  		int bank_pins = 0;
> @@ -1893,27 +2149,39 @@ static struct rockchip_pin_ctrl
> *rockchip_pinctrl_get_soc_data( bank->pin_base = ctrl->nr_pins;
>  		ctrl->nr_pins += bank->nr_pins;
> 
> -		/* calculate iomux offsets */
> +		/* calculate iomux and drv offsets */
>  		for (j = 0; j < 4; j++) {
>  			struct rockchip_iomux *iom = &bank->iomux[j];
> +			struct rockchip_drv *drv = &bank->drv[j];
>  			int inc;
> 
>  			if (bank_pins >= bank->nr_pins)
>  				break;
> 
> -			/* preset offset value, set new start value */
> +			/* preset iomux offset value, set new start value */
>  			if (iom->offset >= 0) {
>  				if (iom->type & IOMUX_SOURCE_PMU)
>  					pmu_offs = iom->offset;
>  				else
>  					grf_offs = iom->offset;
> -			} else { /* set current offset */
> +			} else { /* set current iomux offset */
>  				iom->offset = (iom->type & IOMUX_SOURCE_PMU) ?
>  							pmu_offs : grf_offs;
>  			}
> 
> -			dev_dbg(d->dev, "bank %d, iomux %d has offset 0x%x\n",
> -				 i, j, iom->offset);
> +			/* preset drv offset value, set new start value */
> +			if (drv->offset >= 0) {
> +				if (iom->type & IOMUX_SOURCE_PMU)
> +					drv_pmu_offs = drv->offset;
> +				else
> +					drv_grf_offs = drv->offset;
> +			} else { /* set current drv offset */
> +				drv->offset = (iom->type & IOMUX_SOURCE_PMU) ?
> +						drv_pmu_offs : drv_grf_offs;
> +			}
> +
> +			dev_dbg(d->dev, "bank %d, iomux %d has iom_offset 0x%x drv_offset
> 0x%x\n", +				i, j, iom->offset, drv->offset);
> 
>  			/*
>  			 * Increase offset according to iomux width.
> @@ -1925,6 +2193,21 @@ static struct rockchip_pin_ctrl
> *rockchip_pinctrl_get_soc_data( else
>  				grf_offs += inc;
> 
> +			/*
> +			 * Increase offset according to drv width.
> +			 * 3bit drive-strenth'es are spread over two registers.
> +			 */
> +			if ((drv->drv_type == DRV_TYPE_IO_1V8_3V0_AUTO) ||
> +			    (drv->drv_type == DRV_TYPE_IO_3V3_ONLY))
> +				inc = 8;
> +			else
> +				inc = 4;
> +
> +			if (iom->type & IOMUX_SOURCE_PMU)
> +				drv_pmu_offs += inc;
> +			else
> +				drv_grf_offs += inc;
> +
>  			bank_pins += 8;
>  		}
>  	}
> @@ -2208,6 +2491,62 @@ static struct rockchip_pin_ctrl rk3368_pin_ctrl = {
>  		.drv_calc_reg		= rk3368_calc_drv_reg_and_bit,
>  };
> 
> +static struct rockchip_pin_bank rk3399_pin_banks[] = {
> +	PIN_BANK_IOMUX_DRV_FLAGS_OFFSET(0, 32, "gpio0", IOMUX_SOURCE_PMU,
> +					IOMUX_SOURCE_PMU,
> +					IOMUX_SOURCE_PMU,
> +					IOMUX_SOURCE_PMU,
> +					DRV_TYPE_IO_1V8_ONLY,
> +					DRV_TYPE_IO_1V8_ONLY,
> +					DRV_TYPE_IO_DEFAULT,
> +					DRV_TYPE_IO_DEFAULT,
> +					0x0,
> +					0x8,
> +					-1,
> +					-1
> +					),
> +	PIN_BANK_IOMUX_DRV_FLAGS_OFFSET(1, 32, "gpio1", IOMUX_SOURCE_PMU,
> +					IOMUX_SOURCE_PMU,
> +					IOMUX_SOURCE_PMU,
> +					IOMUX_SOURCE_PMU,
> +					DRV_TYPE_IO_1V8_OR_3V0,
> +					DRV_TYPE_IO_1V8_OR_3V0,
> +					DRV_TYPE_IO_1V8_OR_3V0,
> +					DRV_TYPE_IO_1V8_OR_3V0,
> +					0x20,
> +					0x28,
> +					0x30,
> +					0x38
> +					),
> +	PIN_BANK_DRV_FLAGS(2, 32, "gpio2", DRV_TYPE_IO_1V8_OR_3V0,
> +			   DRV_TYPE_IO_1V8_OR_3V0,
> +			   DRV_TYPE_IO_1V8_ONLY,
> +			   DRV_TYPE_IO_1V8_ONLY
> +			   ),
> +	PIN_BANK_DRV_FLAGS(3, 32, "gpio3", DRV_TYPE_IO_3V3_ONLY,
> +			   DRV_TYPE_IO_3V3_ONLY,
> +			   DRV_TYPE_IO_3V3_ONLY,
> +			   DRV_TYPE_IO_1V8_OR_3V0
> +			   ),
> +	PIN_BANK_DRV_FLAGS(4, 32, "gpio4", DRV_TYPE_IO_1V8_OR_3V0,
> +			   DRV_TYPE_IO_1V8_3V0_AUTO,
> +			   DRV_TYPE_IO_1V8_OR_3V0,
> +			   DRV_TYPE_IO_1V8_OR_3V0
> +			   ),
> +};
> +
> +static struct rockchip_pin_ctrl rk3399_pin_ctrl = {
> +		.pin_banks		= rk3399_pin_banks,
> +		.nr_banks		= ARRAY_SIZE(rk3399_pin_banks),
> +		.label			= "RK3399-GPIO",
> +		.type			= RK3399,
> +		.grf_mux_offset		= 0xe000,
> +		.pmu_mux_offset		= 0x0,
> +		.grf_drv_offset		= 0xe100,
> +		.pmu_drv_offset		= 0x80,
> +		.pull_calc_reg		= rk3399_calc_pull_reg_and_bit,
> +		.drv_calc_reg		= rk3399_calc_drv_reg_and_bit,
> +};
> 
>  static const struct of_device_id rockchip_pinctrl_dt_match[] = {
>  	{ .compatible = "rockchip,rk2928-pinctrl",
> @@ -2224,6 +2563,8 @@ static const struct of_device_id
> rockchip_pinctrl_dt_match[] = { .data = (void *)&rk3288_pin_ctrl },
>  	{ .compatible = "rockchip,rk3368-pinctrl",
>  		.data = (void *)&rk3368_pin_ctrl },
> +	{ .compatible = "rockchip,rk3399-pinctrl",
> +		.data = (void *)&rk3399_pin_ctrl },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, rockchip_pinctrl_dt_match);



From robin.murphy at arm.com  Mon Feb  1 04:00:48 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Mon,  1 Feb 2016 12:00:48 +0000
Subject: [PATCH v2] clocksource/arm_arch_timer: Enable and verify MMIO access
Message-ID: <71bf617f4083b116b2aeab24f13fc5fed99a816f.1454327031.git.robin.murphy@arm.com>

So far, we have been blindly assuming that having access to a
memory-mapped timer frame implies that the individual elements of that
frame frame are already enabled. Whilst it's the firmware's job to give
us non-secure access to frames in the first place, we should not rely
on implementations always being generous enough to also configure CNTACR
for those non-secure frames (e.g. [1]).

Explicitly enable feature-level access per-frame, and verify that the
access we want is really implemented before trying to make use of it.

[1]:https://github.com/ARM-software/tf-issues/issues/170

Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---

Changes from v1:
- Remove CNTACR_RFRQ check since the "no access, CNTFRQ reads as zero"
  case can be handled the same way the driver deals with the "CNTFRQ
  accessible, but not programmed" case.
- Reword the commit message to make more sense.

 drivers/clocksource/arm_arch_timer.c | 36 ++++++++++++++++++++++++++++--------
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index c64d543..7c567f0 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -32,6 +32,14 @@
 #define CNTTIDR		0x08
 #define CNTTIDR_VIRT(n)	(BIT(1) << ((n) * 4))
 
+#define CNTACR(n)	(0x40 + ((n) * 4))
+#define CNTACR_RPCT	BIT(0)
+#define CNTACR_RVCT	BIT(1)
+#define CNTACR_RFRQ	BIT(2)
+#define CNTACR_RVOFF	BIT(3)
+#define CNTACR_RWVT	BIT(4)
+#define CNTACR_RWPT	BIT(5)
+
 #define CNTVCT_LO	0x08
 #define CNTVCT_HI	0x0c
 #define CNTFRQ		0x10
@@ -757,7 +765,6 @@ static void __init arch_timer_mem_init(struct device_node *np)
 	}
 
 	cnttidr = readl_relaxed(cntctlbase + CNTTIDR);
-	iounmap(cntctlbase);
 
 	/*
 	 * Try to find a virtual capable frame. Otherwise fall back to a
@@ -765,20 +772,31 @@ static void __init arch_timer_mem_init(struct device_node *np)
 	 */
 	for_each_available_child_of_node(np, frame) {
 		int n;
+		u32 cntacr;
 
 		if (of_property_read_u32(frame, "frame-number", &n)) {
 			pr_err("arch_timer: Missing frame-number\n");
-			of_node_put(best_frame);
 			of_node_put(frame);
-			return;
+			goto out;
 		}
 
-		if (cnttidr & CNTTIDR_VIRT(n)) {
+		/* Try enabling everything, and see what sticks */
+		cntacr = CNTACR_RFRQ | CNTACR_RWPT | CNTACR_RPCT |
+			 CNTACR_RWVT | CNTACR_RVOFF | CNTACR_RVCT;
+		writel_relaxed(cntacr, cntctlbase + CNTACR(n));
+		cntacr = readl_relaxed(cntctlbase + CNTACR(n));
+
+		if ((cnttidr & CNTTIDR_VIRT(n)) &&
+		    !(~cntacr & (CNTACR_RWVT | CNTACR_RVCT))) {
 			of_node_put(best_frame);
 			best_frame = frame;
 			arch_timer_mem_use_virtual = true;
 			break;
 		}
+
+		if (~cntacr & (CNTACR_RWPT | CNTACR_RPCT))
+			continue;
+
 		of_node_put(best_frame);
 		best_frame = of_node_get(frame);
 	}
@@ -786,24 +804,26 @@ static void __init arch_timer_mem_init(struct device_node *np)
 	base = arch_counter_base = of_iomap(best_frame, 0);
 	if (!base) {
 		pr_err("arch_timer: Can't map frame's registers\n");
-		of_node_put(best_frame);
-		return;
+		goto out;
 	}
 
 	if (arch_timer_mem_use_virtual)
 		irq = irq_of_parse_and_map(best_frame, 1);
 	else
 		irq = irq_of_parse_and_map(best_frame, 0);
-	of_node_put(best_frame);
+
 	if (!irq) {
 		pr_err("arch_timer: Frame missing %s irq",
 		       arch_timer_mem_use_virtual ? "virt" : "phys");
-		return;
+		goto out;
 	}
 
 	arch_timer_detect_rate(base, np);
 	arch_timer_mem_register(base, irq);
 	arch_timer_common_init();
+out:
+	iounmap(cntctlbase);
+	of_node_put(best_frame);
 }
 CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
 		       arch_timer_mem_init);
-- 
2.7.0.25.gfc10eb5.dirty



From maxime.coquelin at st.com  Mon Feb  1 04:09:15 2016
From: maxime.coquelin at st.com (Maxime Coquelin)
Date: Mon, 1 Feb 2016 13:09:15 +0100
Subject: [PATCH v4 4/9] pinctrl: Add STM32 MCUs support
In-Reply-To: <CALszF6DTpcU8jFwA0HL8LpkxfO5ZOdFmpHBUxA7WfYgAj_uFhg@mail.gmail.com>
References: <1452773795-24216-1-git-send-email-mcoquelin.stm32@gmail.com>
 <1452773795-24216-5-git-send-email-mcoquelin.stm32@gmail.com>
 <CACRpkdaBcP6fC5Oxn+d1WPdHq1FtwMkf8Ap5VDLQFg-5UwEBAw@mail.gmail.com>
 <2151471.Wut3mQ9SS7@wuerfel>
 <CALszF6DTpcU8jFwA0HL8LpkxfO5ZOdFmpHBUxA7WfYgAj_uFhg@mail.gmail.com>
Message-ID: <56AF4AEB.40109@st.com>


On 02/01/2016 11:39 AM, Maxime Coquelin wrote:
> 2016-02-01 11:21 GMT+01:00 Arnd Bergmann <arnd at arndb.de>:
>> On Wednesday 27 January 2016 14:16:32 Linus Walleij wrote:
>>> On Thu, Jan 14, 2016 at 1:16 PM, Maxime Coquelin
>>> <mcoquelin.stm32 at gmail.com> wrote:
>>>
>>>> This patch adds pinctrl and GPIO support to STMicroelectronic's STM32
>>>> family of MCUs.
>>>>
>>>> While it only supports STM32F429 for now, it has been designed to enable
>>>> support of other MCUs of the family (e.g. STM32F746).
>>>>
>>>> Acked-by: Patrice Chotard <patrice.chotard at st.com>
>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
>>> This patch applied for kernel v4.6.
>>>
>> This breaks the kernel build, please revert:
>>
>> drivers/pinctrl/stm32/pinctrl-stm32.c:26:47: fatal error: dt-bindings/pinctrl/pinctrl-stm32.h: No such file or directory
> Right, I missed to notify this dependency to Linus, sorry about that.
> This dependency is no more needed, so I could just move the macros to
> the driver side.
>
> Note that I also noticed a breakage at build time due to field
> renaming in gpio_chip structure (dev -> parent).
>
> I propose to rebase the series and move the defines into the driver.
> Is it ok for you?
>
I have rebased the series, taking care to fix the mentioned problems.

Linus, do you confirm you will revert STM32 pinctrl patches from your tree?

Thanks,
Maxime



From mark.rutland at arm.com  Mon Feb  1 04:11:12 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 1 Feb 2016 12:11:12 +0000
Subject: [PATCHv2 1/3] arm64: Drop alloc function from create_mapping
In-Reply-To: <CAKv+Gu-VTg6m9PNRCEDm07nwku3YVmYkMSs-08p_SigqOdabhQ@mail.gmail.com>
References: <1454111218-3461-1-git-send-email-labbott@fedoraproject.org>
 <1454111218-3461-2-git-send-email-labbott@fedoraproject.org>
 <CAKv+Gu-VTg6m9PNRCEDm07nwku3YVmYkMSs-08p_SigqOdabhQ@mail.gmail.com>
Message-ID: <20160201121111.GE674@leverpostej>

On Sat, Jan 30, 2016 at 11:34:50AM +0100, Ard Biesheuvel wrote:
> On 30 January 2016 at 00:46, Laura Abbott <labbott at fedoraproject.org> wrote:
> >
> > create_mapping is only used in fixmap_remap_fdt. All the create_mapping
> > calls need to happen on existing translation table pages without
> > additional allocations. Rather than have an alloc function be called
> > and fail, just set it to NULL and catch it's use. Also change
> 
> s/it's/its/
> 
> > the name to create_mapping_noalloc to better capture what exactly is
> > going on.
> >
> > Signed-off-by: Laura Abbott <labbott at fedoraproject.org>
> 
> With one nit below:
> Reviewed-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

[...]

> > +/*
> > + * This function is for mapping using existing sections only.
> 
> Could you improve this comment? 'existing sections' does not quite
> cover what we expect to deal with imo
> > + */
> > +static void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
> >                                   phys_addr_t size, pgprot_t prot)

Perhaps:

/*
 * This function can only be used to modify existing table entries,
 * without allocating new levels of table. Note that this permits the
 * creation of new section or page entries.
 */

Either way:

Reviewed-by: Mark Rutland <mark.rutland at arm.com>

Thanks for putting this together!

Mark.


From shawnguo at kernel.org  Mon Feb  1 04:11:45 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 1 Feb 2016 20:11:45 +0800
Subject: [PATCH 2/2] ARM: dts: Add dts for Uniwest evi
In-Reply-To: <66c87b9536b674bdedfdbe2306def8e9bf6a585c.1452717014.git.stillcompiling@gmail.com>
References: <b11bf2208fe30b96c4d82e634e8abe04343754de.1452717014.git.stillcompiling@gmail.com>
 <66c87b9536b674bdedfdbe2306def8e9bf6a585c.1452717014.git.stillcompiling@gmail.com>
Message-ID: <20160201121145.GE10671@tiger>

On Wed, Jan 13, 2016 at 12:45:12PM -0800, Joshua Clayton wrote:
> Uniwest evi is a portable electrical eddy current non-destructive
> testing device.
> 
> Signed-off-by: Joshua Clayton <stillcompiling at gmail.com>
> ---
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 30bbc37..c284cb6 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -314,6 +314,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>  	imx6q-cubox-i.dtb \
>  	imx6q-dfi-fs700-m60.dtb \
>  	imx6q-dmo-edmqmx6.dtb \
> +	imx6q-evi.dtb \
>  	imx6q-gk802.dtb \
>  	imx6q-gw51xx.dtb \
>  	imx6q-gw52xx.dtb \
> diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
> new file mode 100644
> index 0000000..a1ca2b9
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-evi.dts
> @@ -0,0 +1,502 @@
> +/*
> + * Copyright 2016 United Western Technologies.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This file is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + *
> + */
> +
> +/dts-v1/;
> +#include "imx6q.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/ {
> +	model = "Uniwest Evi";
> +	compatible = "uniwest,imx6q-evi", "fsl,imx6q";
> +
> +	memory {
> +		reg = <0x10000000 0x40000000>;
> +	};
> +
> +	regulators {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		reg_usbh1_vbus: regulator at 0 {
> +			compatible = "regulator-fixed";
> +			reg = <0>;
> +			regulator-name = "usbh1_vbus";
> +			regulator-min-microvolt = <5000000>;
> +			regulator-max-microvolt = <5000000>;
> +			enable-active-high;
> +			startup-delay-us = <2>;
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_usbh1_hubreset>;
> +			gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
> +		};

Device tree maintainers do not like the fake simple-bus container for
these fixed regulators.  We are asked to put them directly under root
node.  In that case, we do not need the artificial 'reg' property, and
we can name node in schema like:

	reg_xxx: regulator-xxx {
		...
	}

> +
> +		reg_usb_otg_vbus: regulator at 1 {
> +			compatible = "regulator-fixed";
> +			reg = <1>;
> +			regulator-name = "usb_otg_vbus";
> +			regulator-min-microvolt = <5000000>;
> +			regulator-max-microvolt = <5000000>;
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_usbotg_vbus>;
> +			gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
> +			enable-active-high;
> +			regulator-always-on;
> +		};
> +	};

Have a new line between nodes.

> +	chosen {
> +		bootargs = "sbs-battery.force_load=1";
> +	};

We generally put 'chosen' node at the beginning along with 'memory'
node.  And do we really need this as the default bootargs?

> +
> +	panel {
> +		compatible = "sharp,lq101k1ly04";

Undocumented compatible string.

> +
> +		port {
> +			panel_in: endpoint {
> +				remote-endpoint = <&lvds0_out>;
> +			};
> +		};
> +	};
> +};
> +
> +&ecspi1 {
> +	fsl,spi-num-chipselects = <1>;
> +	cs-gpios = <&gpio4 10 GPIO_ACTIVE_LOW>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_ecspi1_extra>;

You use only one GPIO in cs-gpios.  Why do you need to set up 3 in
pinctrl_ecspi1_extra?  And why do you name the pinctrl group in the same
way as ecspi3 and ecspi5, i.e. pinctrl_ecspi1_cs?

> +	status = "okay";
> +};
> +
> +&ecspi3 {
> +	fsl,spi-num-chipselects = <3>;
> +	cs-gpios = <&gpio4 24 GPIO_ACTIVE_LOW>,
> +		<&gpio4 25 GPIO_ACTIVE_LOW>,
> +		<&gpio4 26 GPIO_ACTIVE_LOW>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs>;
> +	status = "okay";
> +};
> +
> +&ecspi5 {
> +	fsl,spi-num-chipselects = <4>;
> +	cs-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>,
> +		<&gpio1 13 GPIO_ACTIVE_LOW>,
> +		<&gpio1 12 GPIO_ACTIVE_LOW>,
> +		<&gpio2 9 GPIO_ACTIVE_HIGH>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_ecspi5 &pinctrl_ecspi5_cs>;
> +	status = "okay";

Have a new line between properties and sub-node.

> +	eeprom: m95m02 at 1 {
> +		compatible = "st,m95m02", "atmel,at25";
> +		size = <262144>;
> +		pagesize = <256>;
> +		address-width = <24>;
> +		spi-max-frequency = <5000000>;
> +		reg = <1>;
> +	};

Have a new line between nodes.

> +	pb_rtc: rtc at 3 {
> +		compatible = "nxp,rtc-pcf2123";
> +		spi-max-frequency = <2450000>;
> +		spi-cs-high;
> +		reg = <3>;
> +	};
> +};
> +
> +&fec {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_enet>;
> +	phy-mode = "rgmii";
> +	phy-reset-gpios = <&gpio1 25 0>;
> +	status = "okay";
> +};
> +
> +&gpmi {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_gpmi_nand>;
> +	status = "okay";
> +};
> +
> +&i2c2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c2>;
> +	clock-frequency = <100000>;
> +	status = "okay";
> +};
> +
> +&i2c3 {
> +	pinctrl-names = "default", "gpio";
> +	pinctrl-0 = <&pinctrl_i2c3>;
> +	pinctrl-1 = <&pinctrl_i2c3_gpio>;
> +	clock-frequency = <100000>;
> +	status = "okay";

We generally put 'status' at the bottom of the property list.

> +	scl-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
> +	sda-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>;
> +
> +	battery: sbs-battery at b {
> +		compatible = "sbs,sbs-battery";
> +		reg = <0x0b>;
> +		sbs,poll-retry-count = <100>;
> +		sbs,i2c-retry-count = <100>;
> +	};
> +};
> +
> +&ldb {
> +	status = "okay";
> +
> +	lvds0: lvds-channel at 0 {
> +		fsl,data-mapping = "jeida";
> +		fsl,data-width = <24>;
> +		status = "okay";
> +
> +		port at 4 {
> +			reg = <4>;
> +
> +			lvds0_out: endpoint {
> +				remote-endpoint = <&panel_in>;
> +			};
> +		};
> +	};
> +};
> +
> +&ssi1 {
> +	fsl,mode = "i2s-slave";

"i2s-slave" is deprecated for fsl,mode, and can be just dropped.

> +	status = "okay";
> +};
> +
> +&uart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart1>;
> +	status = "okay";
> +};
> +
> +&uart2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart2>;
> +	status = "okay";
> +};
> +
> +&usbh1 {
> +	vbus-supply = <&reg_usbh1_vbus>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usbh1>;
> +	dr_mode = "host";
> +	disable-over-current;
> +	status = "okay";
> +};
> +
> +&usbotg {
> +	vbus-supply = <&reg_usb_otg_vbus>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usbotg>;
> +	disable-over-current;
> +	dr_mode = "otg";
> +	status = "okay";
> +};
> +
> +&usdhc1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usdhc1>;
> +	non-removable;
> +	status = "okay";
> +};
> +
> +&weim {
> +	#address-cells = <2>;
> +	#size-cells = <1>;
> +	ranges = <0 0 0x08000000 0x08000000>;
> +	fsl,weim-cs-gpr = <&gpr>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_weim_fpga &pinctrl_weim_cs>;
> +	status = "okay";
> +};
> +
> +&iomuxc {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_hog>;
> +
> +	imx6q-evi {

Since commit 5fcdf6a7ed95 (pinctrl: imx: Allow parsing DT without
function nodes), this additional container node can just be saved.

> +		pinctrl_hog: hoggrp {
> +			fsl,pins = <
> +				/* CPLD Reset */
> +				MX6QDL_PAD_GPIO_19__GPIO4_IO05 0x1b0b0
> +				/* pwr mcu alert irq */
> +				MX6QDL_PAD_SD4_DAT2__GPIO2_IO10 0x1b0b0
> +				/* remainder ???? */
> +				MX6QDL_PAD_CSI0_MCLK__GPIO5_IO19 0x1b0b0
> +			>;
> +		};

Have a new line between nodes.

> +		pinctrl_ecspi1: ecspi1grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_KEY_COL1__ECSPI1_MISO 0x100b1
> +				MX6QDL_PAD_KEY_ROW0__ECSPI1_MOSI 0x100b1
> +				MX6QDL_PAD_KEY_COL0__ECSPI1_SCLK 0x100b1
> +			>;
> +		};
> +		pinctrl_ecspi1_extra: ecspi1extragrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
> +				MX6QDL_PAD_KEY_ROW1__GPIO4_IO09 0x1b0b0
> +				MX6QDL_PAD_KEY_ROW2__GPIO4_IO11 0x1b0b0
> +			>;
> +		};
> +		pinctrl_ecspi3: ecspi3grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x10068
> +				MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x10068
> +				MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x1f068
> +			>;
> +		};
> +		pinctrl_ecspi3_cs: ecspi3cs {

Please name the node consistently, like xxxgrp.

> +			fsl,pins = <
> +				MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x1b0b0
> +				MX6QDL_PAD_DISP0_DAT4__GPIO4_IO25 0x1b0b0
> +				MX6QDL_PAD_DISP0_DAT5__GPIO4_IO26 0x1b0b0
> +				MX6QDL_PAD_DISP0_DAT6__GPIO4_IO27 0x1b0b0
> +			>;
> +		};
> +		pinctrl_ecspi5: ecspi5grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_SD2_CLK__ECSPI5_SCLK 0x100b1
> +				MX6QDL_PAD_SD2_CMD__ECSPI5_MOSI 0x100b1
> +				MX6QDL_PAD_SD2_DAT0__ECSPI5_MISO 0x100b1
> +			>;
> +		};
> +		pinctrl_ecspi5_cs: ecspi5cs {
> +			fsl,pins = <
> +				MX6QDL_PAD_SD2_DAT1__GPIO1_IO14 0x1b0b0
> +				MX6QDL_PAD_SD2_DAT2__GPIO1_IO13 0x1b0b0
> +				MX6QDL_PAD_SD2_DAT3__GPIO1_IO12 0x1b0b0
> +				MX6QDL_PAD_SD4_DAT1__GPIO2_IO09 0x1b0b0
> +			>;
> +		};
> +		pinctrl_enet: enetgrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
> +				MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
> +				MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b0b0
> +				MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b0b0
> +				MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b0b0
> +				MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b0b0
> +				MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b0b0
> +				MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
> +				MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
> +				MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b0b0
> +				MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b0b0
> +				MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b0b0
> +				MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0
> +				MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0
> +				MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
> +				MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x4001b0a8
> +				MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x1b0b0
> +			>;
> +		};
> +		pinctrl_gpmi_nand: gpminandgrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_NANDF_CLE__NAND_CLE 0xb0b1
> +				MX6QDL_PAD_NANDF_ALE__NAND_ALE 0xb0b1
> +				MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0xb0b1
> +				MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0xb000
> +				MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0xb0b1
> +				MX6QDL_PAD_NANDF_CS1__NAND_CE1_B 0xb0b1
> +				MX6QDL_PAD_SD4_CMD__NAND_RE_B 0xb0b1
> +				MX6QDL_PAD_SD4_CLK__NAND_WE_B 0xb0b1
> +				MX6QDL_PAD_NANDF_D0__NAND_DATA00 0xb0b1
> +				MX6QDL_PAD_NANDF_D1__NAND_DATA01 0xb0b1
> +				MX6QDL_PAD_NANDF_D2__NAND_DATA02 0xb0b1
> +				MX6QDL_PAD_NANDF_D3__NAND_DATA03 0xb0b1
> +				MX6QDL_PAD_NANDF_D4__NAND_DATA04 0xb0b1
> +				MX6QDL_PAD_NANDF_D5__NAND_DATA05 0xb0b1
> +				MX6QDL_PAD_NANDF_D6__NAND_DATA06 0xb0b1
> +				MX6QDL_PAD_NANDF_D7__NAND_DATA07 0xb0b1
> +				MX6QDL_PAD_SD4_DAT0__NAND_DQS 0x00b1
> +			>;
> +		};
> +		pinctrl_i2c2: i2c2grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
> +				MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
> +			>;
> +		};
> +		pinctrl_i2c3: i2c3grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
> +				MX6QDL_PAD_GPIO_16__I2C3_SDA 0x4001b8b1
> +			>;
> +		};
> +		pinctrl_i2c3_gpio: i2c3gpiogrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_GPIO_5__GPIO1_IO05 0x4001b8b1
> +				MX6QDL_PAD_GPIO_16__GPIO7_IO11 0x4001b8b1
> +			>;
> +		};
> +		pinctrl_weim_cs: weim_csgrp {

weimcsgrp

> +			fsl,pins = <
> +				MX6QDL_PAD_EIM_CS0__EIM_CS0_B 0xb0b1
> +				MX6QDL_PAD_EIM_CS1__EIM_CS1_B 0xb0b1
> +			>;
> +		};
> +		pinctrl_weim_fpga: weim_fpgagrp {

weimfpgagrp

> +			fsl,pins = <
> +				/* weim misc */
> +				MX6QDL_PAD_EIM_OE__EIM_OE_B 0xb0b1
> +				MX6QDL_PAD_EIM_RW__EIM_RW 0xb0b1
> +				MX6QDL_PAD_EIM_WAIT__EIM_WAIT_B 0xb060
> +				MX6QDL_PAD_EIM_BCLK__EIM_BCLK 0xb0b1
> +				MX6QDL_PAD_EIM_LBA__EIM_LBA_B 0xb0b1
> +				MX6QDL_PAD_EIM_EB0__EIM_EB0_B 0xb0b1
> +				MX6QDL_PAD_EIM_EB1__EIM_EB1_B 0xb0b1
> +				MX6QDL_PAD_EIM_EB2__EIM_EB2_B 0xb0b1
> +				MX6QDL_PAD_EIM_EB3__EIM_EB3_B 0xb0b1
> +				/* weim data */
> +				MX6QDL_PAD_CSI0_DATA_EN__EIM_DATA00 0x1b0b0
> +				MX6QDL_PAD_CSI0_VSYNC__EIM_DATA01 0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT4__EIM_DATA02 0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT5__EIM_DATA03 0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT6__EIM_DATA04 0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT7__EIM_DATA05 0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT8__EIM_DATA06 0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT9__EIM_DATA07 0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT12__EIM_DATA08 0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT13__EIM_DATA09 0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT14__EIM_DATA10 0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT15__EIM_DATA11 0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT16__EIM_DATA12 0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT17__EIM_DATA13 0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT18__EIM_DATA14 0x1b0b0
> +				MX6QDL_PAD_CSI0_DAT19__EIM_DATA15 0x1b0b0
> +				MX6QDL_PAD_EIM_D16__EIM_DATA16 0x1b0b0
> +				MX6QDL_PAD_EIM_D17__EIM_DATA17 0x1b0b0
> +				MX6QDL_PAD_EIM_D18__EIM_DATA18 0x1b0b0
> +				MX6QDL_PAD_EIM_D19__EIM_DATA19 0x1b0b0
> +				MX6QDL_PAD_EIM_D20__EIM_DATA20 0x1b0b0
> +				MX6QDL_PAD_EIM_D21__EIM_DATA21 0x1b0b0
> +				MX6QDL_PAD_EIM_D22__EIM_DATA22 0x1b0b0
> +				MX6QDL_PAD_EIM_D23__EIM_DATA23 0x1b0b0
> +				MX6QDL_PAD_EIM_D24__EIM_DATA24 0x1b0b0
> +				MX6QDL_PAD_EIM_D25__EIM_DATA25 0x1b0b0
> +				MX6QDL_PAD_EIM_D26__EIM_DATA26 0x1b0b0
> +				MX6QDL_PAD_EIM_D27__EIM_DATA27 0x1b0b0
> +				MX6QDL_PAD_EIM_D28__EIM_DATA28 0x1b0b0
> +				MX6QDL_PAD_EIM_D29__EIM_DATA29 0x1b0b0
> +				MX6QDL_PAD_EIM_D30__EIM_DATA30 0x1b0b0
> +				MX6QDL_PAD_EIM_D31__EIM_DATA31 0x1b0b0
> +				/* weim address */
> +				MX6QDL_PAD_EIM_A25__EIM_ADDR25 0xb0b1
> +				MX6QDL_PAD_EIM_A24__EIM_ADDR24 0xb0b1
> +				MX6QDL_PAD_EIM_A23__EIM_ADDR23 0xb0b1
> +				MX6QDL_PAD_EIM_A22__EIM_ADDR22 0xb0b1
> +				MX6QDL_PAD_EIM_A21__EIM_ADDR21 0xb0b1
> +				MX6QDL_PAD_EIM_A20__EIM_ADDR20 0xb0b1
> +				MX6QDL_PAD_EIM_A19__EIM_ADDR19 0xb0b1
> +				MX6QDL_PAD_EIM_A18__EIM_ADDR18 0xb0b1
> +				MX6QDL_PAD_EIM_A17__EIM_ADDR17 0xb0b1
> +				MX6QDL_PAD_EIM_A16__EIM_ADDR16 0xb0b1
> +				MX6QDL_PAD_EIM_DA15__EIM_AD15 0xb0b1
> +				MX6QDL_PAD_EIM_DA14__EIM_AD14 0xb0b1
> +				MX6QDL_PAD_EIM_DA13__EIM_AD13 0xb0b1
> +				MX6QDL_PAD_EIM_DA12__EIM_AD12 0xb0b1
> +				MX6QDL_PAD_EIM_DA11__EIM_AD11 0xb0b1
> +				MX6QDL_PAD_EIM_DA10__EIM_AD10 0xb0b1
> +				MX6QDL_PAD_EIM_DA9__EIM_AD09 0xb0b1
> +				MX6QDL_PAD_EIM_DA8__EIM_AD08 0xb0b1
> +				MX6QDL_PAD_EIM_DA7__EIM_AD07 0xb0b1
> +				MX6QDL_PAD_EIM_DA6__EIM_AD06 0xb0b1
> +				MX6QDL_PAD_EIM_DA5__EIM_AD05 0xb0b1
> +				MX6QDL_PAD_EIM_DA4__EIM_AD04 0xb0b1
> +				MX6QDL_PAD_EIM_DA3__EIM_AD03 0xb0b1
> +				MX6QDL_PAD_EIM_DA2__EIM_AD02 0xb0b1
> +				MX6QDL_PAD_EIM_DA1__EIM_AD01 0xb0b1
> +				MX6QDL_PAD_EIM_DA0__EIM_AD00 0xb0b1
> +			>;
> +		};
> +		pinctrl_uart1: uart1grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
> +				MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
> +			>;
> +		};
> +		pinctrl_uart2: uart2grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_SD3_DAT5__UART2_TX_DATA 0x1b0b1
> +				MX6QDL_PAD_SD3_DAT4__UART2_RX_DATA 0x1b0b1
> +				MX6QDL_PAD_SD3_CLK__UART2_RTS_B 0x1b0b1
> +				MX6QDL_PAD_SD3_CMD__UART2_CTS_B 0x1b0b1
> +			>;
> +		};
> +		pinctrl_usbh1: usbh1grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_GPIO_3__USB_H1_OC 0x1b0b0
> +				/* usbh1_b OC */
> +				MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
> +			>;
> +		};
> +		pinctrl_usbh1_hubreset: usbh1hubresetgrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
> +			>;
> +		};
> +		pinctrl_usbotg: usbotggrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
> +				MX6QDL_PAD_KEY_COL4__USB_OTG_OC 0x1b0b0
> +			>;
> +		};
> +		pinctrl_usbotg_vbus: usbotg_vbusgrp {

usbotgvbusgrp

Shawn

> +			fsl,pins = <
> +				MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x000b0
> +			>;
> +		};
> +
> +		pinctrl_usdhc1: usdhc1grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17059
> +				MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10059
> +				MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17059
> +				MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17059
> +				MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17059
> +				MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17059
> +			>;
> +		};
> +	};
> +};
> -- 
> 2.5.0
> 
> 


From catalin.marinas at arm.com  Mon Feb  1 04:24:44 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 1 Feb 2016 12:24:44 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160201122444.GD15514@e104818-lin.cambridge.arm.com>

On Mon, Feb 01, 2016 at 11:54:52AM +0100, Ard Biesheuvel wrote:
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -53,6 +53,10 @@ u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
>  unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_bss;
>  EXPORT_SYMBOL(empty_zero_page);
>  
> +static pte_t bm_pte[PTRS_PER_PTE] __page_aligned_bss;
> +static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss;
> +static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss;

I applied a fixup locally to keep the compiler quiet:

--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -57,8 +57,8 @@ unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_
 EXPORT_SYMBOL(empty_zero_page);
 
 static pte_t bm_pte[PTRS_PER_PTE] __page_aligned_bss;
-static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss;
-static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss;
+static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss __maybe_unused;
+static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss __maybe_unused;
 
 pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 			      unsigned long size, pgprot_t vma_prot)

-- 
Catalin


From ard.biesheuvel at linaro.org  Mon Feb  1 04:27:59 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 1 Feb 2016 13:27:59 +0100
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <20160201122444.GD15514@e104818-lin.cambridge.arm.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <20160201122444.GD15514@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu-4FAn-f3dTKPZbiNcs_kCFN+PuxQkHwTdWN24VWhrrOA@mail.gmail.com>

On 1 February 2016 at 13:24, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 01, 2016 at 11:54:52AM +0100, Ard Biesheuvel wrote:
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -53,6 +53,10 @@ u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
>>  unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_bss;
>>  EXPORT_SYMBOL(empty_zero_page);
>>
>> +static pte_t bm_pte[PTRS_PER_PTE] __page_aligned_bss;
>> +static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss;
>> +static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss;
>
> I applied a fixup locally to keep the compiler quiet:
>
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -57,8 +57,8 @@ unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_
>  EXPORT_SYMBOL(empty_zero_page);
>
>  static pte_t bm_pte[PTRS_PER_PTE] __page_aligned_bss;
> -static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss;
> -static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss;
> +static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss __maybe_unused;
> +static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss __maybe_unused;
>

Ah yes, I dropped a memblock_free() against bm_pud in
early_fixmap_init(), since it occurred before the actual reservation,
so bm_pud may never be referenced. For bm_pmd, it should not be
required afaict.

If you prefer, I can keep the original code here:

#if CONFIG_PGTABLE_LEVELS > 2
static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss;
#endif
#if CONFIG_PGTABLE_LEVELS > 3
static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss;
#endif

-- 
Ard.


From christoffer.dall at linaro.org  Mon Feb  1 04:29:07 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 13:29:07 +0100
Subject: [PATCH v2 02/21] arm64: Allow the arch timer to use the HYP timer
In-Reply-To: <1453737235-16522-3-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-3-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201122907.GD1478@cbox>

On Mon, Jan 25, 2016 at 03:53:36PM +0000, Marc Zyngier wrote:
> With the ARMv8.1 VHE, the kernel can run in HYP mode, and thus
> use the HYP timer instead of the normal guest timer in a mostly
> transparent way, except for the interrupt line.
> 
> This patch reworks the arch timer code to allow the selection of
> the HYP PPI, possibly falling back to the guest timer if not
> available.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  drivers/clocksource/arm_arch_timer.c | 96 ++++++++++++++++++++++--------------
>  1 file changed, 59 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index c64d543..ffe9d1c 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -67,7 +67,7 @@ static int arch_timer_ppi[MAX_TIMER_PPI];
>  
>  static struct clock_event_device __percpu *arch_timer_evt;
>  
> -static bool arch_timer_use_virtual = true;
> +static enum ppi_nr arch_timer_uses_ppi = VIRT_PPI;
>  static bool arch_timer_c3stop;
>  static bool arch_timer_mem_use_virtual;
>  
> @@ -263,14 +263,20 @@ static void __arch_timer_setup(unsigned type,
>  		clk->name = "arch_sys_timer";
>  		clk->rating = 450;
>  		clk->cpumask = cpumask_of(smp_processor_id());
> -		if (arch_timer_use_virtual) {
> -			clk->irq = arch_timer_ppi[VIRT_PPI];
> +		clk->irq = arch_timer_ppi[arch_timer_uses_ppi];
> +		switch (arch_timer_uses_ppi) {
> +		case VIRT_PPI:
>  			clk->set_state_shutdown = arch_timer_shutdown_virt;
>  			clk->set_next_event = arch_timer_set_next_event_virt;
> -		} else {
> -			clk->irq = arch_timer_ppi[PHYS_SECURE_PPI];
> +			break;
> +		case PHYS_SECURE_PPI:
> +		case PHYS_NONSECURE_PPI:
> +		case HYP_PPI:
>  			clk->set_state_shutdown = arch_timer_shutdown_phys;
>  			clk->set_next_event = arch_timer_set_next_event_phys;
> +			break;
> +		default:
> +			BUG();
>  		}
>  	} else {
>  		clk->features |= CLOCK_EVT_FEAT_DYNIRQ;
> @@ -338,17 +344,20 @@ static void arch_counter_set_user_access(void)
>  	arch_timer_set_cntkctl(cntkctl);
>  }
>  
> +static bool arch_timer_has_nonsecure_ppi(void)
> +{
> +	return (arch_timer_uses_ppi == PHYS_SECURE_PPI &&
> +		arch_timer_ppi[PHYS_NONSECURE_PPI]);
> +}
> +
>  static int arch_timer_setup(struct clock_event_device *clk)
>  {
>  	__arch_timer_setup(ARCH_CP15_TIMER, clk);
>  
> -	if (arch_timer_use_virtual)
> -		enable_percpu_irq(arch_timer_ppi[VIRT_PPI], 0);
> -	else {
> -		enable_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI], 0);
> -		if (arch_timer_ppi[PHYS_NONSECURE_PPI])
> -			enable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI], 0);
> -	}
> +	enable_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi], 0);
> +
> +	if (arch_timer_has_nonsecure_ppi())
> +		enable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI], 0);
>  
>  	arch_counter_set_user_access();
>  	if (IS_ENABLED(CONFIG_ARM_ARCH_TIMER_EVTSTREAM))
> @@ -390,7 +399,7 @@ static void arch_timer_banner(unsigned type)
>  		     (unsigned long)arch_timer_rate / 1000000,
>  		     (unsigned long)(arch_timer_rate / 10000) % 100,
>  		     type & ARCH_CP15_TIMER ?
> -			arch_timer_use_virtual ? "virt" : "phys" :
> +		     (arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :
>  			"",
>  		     type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ?  "/" : "",
>  		     type & ARCH_MEM_TIMER ?
> @@ -460,7 +469,7 @@ static void __init arch_counter_register(unsigned type)
>  
>  	/* Register the CP15 based counter if we have one */
>  	if (type & ARCH_CP15_TIMER) {
> -		if (IS_ENABLED(CONFIG_ARM64) || arch_timer_use_virtual)
> +		if (IS_ENABLED(CONFIG_ARM64) || arch_timer_uses_ppi == VIRT_PPI)
>  			arch_timer_read_counter = arch_counter_get_cntvct;
>  		else
>  			arch_timer_read_counter = arch_counter_get_cntpct;
> @@ -490,13 +499,9 @@ static void arch_timer_stop(struct clock_event_device *clk)
>  	pr_debug("arch_timer_teardown disable IRQ%d cpu #%d\n",
>  		 clk->irq, smp_processor_id());
>  
> -	if (arch_timer_use_virtual)
> -		disable_percpu_irq(arch_timer_ppi[VIRT_PPI]);
> -	else {
> -		disable_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI]);
> -		if (arch_timer_ppi[PHYS_NONSECURE_PPI])
> -			disable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI]);
> -	}
> +	disable_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi]);
> +	if (arch_timer_has_nonsecure_ppi())
> +		disable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI]);
>  
>  	clk->set_state_shutdown(clk);
>  }
> @@ -562,12 +567,14 @@ static int __init arch_timer_register(void)
>  		goto out;
>  	}
>  
> -	if (arch_timer_use_virtual) {
> -		ppi = arch_timer_ppi[VIRT_PPI];
> +	ppi = arch_timer_ppi[arch_timer_uses_ppi];
> +	switch (arch_timer_uses_ppi) {
> +	case VIRT_PPI:
>  		err = request_percpu_irq(ppi, arch_timer_handler_virt,
>  					 "arch_timer", arch_timer_evt);
> -	} else {
> -		ppi = arch_timer_ppi[PHYS_SECURE_PPI];
> +		break;
> +	case PHYS_SECURE_PPI:
> +	case PHYS_NONSECURE_PPI:
>  		err = request_percpu_irq(ppi, arch_timer_handler_phys,
>  					 "arch_timer", arch_timer_evt);
>  		if (!err && arch_timer_ppi[PHYS_NONSECURE_PPI]) {
> @@ -578,6 +585,13 @@ static int __init arch_timer_register(void)
>  				free_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI],
>  						arch_timer_evt);
>  		}
> +		break;
> +	case HYP_PPI:
> +		err = request_percpu_irq(ppi, arch_timer_handler_phys,
> +					 "arch_timer", arch_timer_evt);
> +		break;
> +	default:
> +		BUG();
>  	}
>  
>  	if (err) {
> @@ -602,15 +616,10 @@ static int __init arch_timer_register(void)
>  out_unreg_notify:
>  	unregister_cpu_notifier(&arch_timer_cpu_nb);
>  out_free_irq:
> -	if (arch_timer_use_virtual)
> -		free_percpu_irq(arch_timer_ppi[VIRT_PPI], arch_timer_evt);
> -	else {
> -		free_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI],
> +	free_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi], arch_timer_evt);
> +	if (arch_timer_has_nonsecure_ppi())
> +		free_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI],
>  				arch_timer_evt);
> -		if (arch_timer_ppi[PHYS_NONSECURE_PPI])
> -			free_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI],
> -					arch_timer_evt);
> -	}
>  
>  out_free:
>  	free_percpu(arch_timer_evt);
> @@ -697,12 +706,25 @@ static void __init arch_timer_init(void)
>  	 *
>  	 * If no interrupt provided for virtual timer, we'll have to
>  	 * stick to the physical timer. It'd better be accessible...
> +	 *
> +	 * On ARMv8.1 with VH extensions, the kernel runs in HYP. VHE
> +	 * accesses to CNTP_*_EL1 registers are silently redirected to
> +	 * their CNTHP_*_EL2 counterparts, and use a different PPI
> +	 * number.
>  	 */
>  	if (is_hyp_mode_available() || !arch_timer_ppi[VIRT_PPI]) {
> -		arch_timer_use_virtual = false;
> +		bool has_ppi;
> +
> +		if (is_kernel_in_hyp_mode()) {
> +			arch_timer_uses_ppi = HYP_PPI;
> +			has_ppi = !!arch_timer_ppi[HYP_PPI];
> +		} else {
> +			arch_timer_uses_ppi = PHYS_SECURE_PPI;
> +			has_ppi = (!!arch_timer_ppi[PHYS_SECURE_PPI] ||
> +				   !!arch_timer_ppi[PHYS_NONSECURE_PPI]);

shouldn't this simply test the PHYS_SECURE_PPI since otherwise you could
potentially have the PHYS_NONSECURE_PPI but not PHYS_SECURE_PPI and
you'll try to request IRQ 0 for this later... ?

> +		}
>  
> -		if (!arch_timer_ppi[PHYS_SECURE_PPI] ||
> -		    !arch_timer_ppi[PHYS_NONSECURE_PPI]) {
> +		if (!has_ppi) {
>  			pr_warn("arch_timer: No interrupt available, giving up\n");
>  			return;
>  		}
> @@ -735,7 +757,7 @@ static void __init arch_timer_of_init(struct device_node *np)
>  	 */
>  	if (IS_ENABLED(CONFIG_ARM) &&
>  	    of_property_read_bool(np, "arm,cpu-registers-not-fw-configured"))
> -			arch_timer_use_virtual = false;
> +		arch_timer_uses_ppi = PHYS_SECURE_PPI;
>  
>  	arch_timer_init();
>  }
> -- 
> 2.1.4
> 

Thanks,
-Christoffer


From mark.rutland at arm.com  Mon Feb  1 04:29:11 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 1 Feb 2016 12:29:11 +0000
Subject: [PATCHv2 2/3] arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
In-Reply-To: <1454111218-3461-3-git-send-email-labbott@fedoraproject.org>
References: <1454111218-3461-1-git-send-email-labbott@fedoraproject.org>
 <1454111218-3461-3-git-send-email-labbott@fedoraproject.org>
Message-ID: <20160201122911.GF674@leverpostej>

Hi,

On Fri, Jan 29, 2016 at 03:46:57PM -0800, Laura Abbott wrote:
> 
> ARCH_SUPPORTS_DEBUG_PAGEALLOC provides a hook to map and unmap
> pages for debugging purposes. This requires memory be mapped
> with PAGE_SIZE mappings since breaking down larger mappings
> at runtime will lead to TLB conflicts. Check if debug_pagealloc
> is enabled at runtime and if so, map everyting with PAGE_SIZE
> pages. Implement the functions to actually map/unmap the
> pages at runtime.
> 
> 
> Signed-off-by: Laura Abbott <labbott at fedoraproject.org>

I tried to apply atop of the arm64 for-next/pgtable branch, but git
wasn't very happy about that -- which branch/patches is this based on?

I'm not sure if I'm missing something, have something I shouldn't, or if
my MTA is corrupting patches again...

> ---
>  arch/arm64/Kconfig       |  3 +++
>  arch/arm64/mm/mmu.c      | 10 +++++++---
>  arch/arm64/mm/pageattr.c | 40 +++++++++++++++++++++++++++++++++-------
>  3 files changed, 43 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 8cc6228..0f33218 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -537,6 +537,9 @@ config HOTPLUG_CPU
>  source kernel/Kconfig.preempt
>  source kernel/Kconfig.hz
>  
> +config ARCH_SUPPORTS_DEBUG_PAGEALLOC
> +	def_bool y
> +
>  config ARCH_HAS_HOLES_MEMORYMODEL
>  	def_bool y if SPARSEMEM
>  
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 103ebc0..5abbd30 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -181,7 +181,8 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
>  	do {
>  		next = pmd_addr_end(addr, end);
>  		/* try section mapping first */
> -		if (((addr | next | phys) & ~SECTION_MASK) == 0) {
> +		if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
> +		      (!debug_pagealloc_enabled() || !pgtable_alloc)) {
>  			pmd_t old_pmd =*pmd;
>  			set_pmd(pmd, __pmd(phys |
>  					   pgprot_val(mk_sect_prot(prot))));
> @@ -208,8 +209,11 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
>  }
>  
>  static inline bool use_1G_block(unsigned long addr, unsigned long next,
> -			unsigned long phys)
> +			unsigned long phys, phys_addr_t (*pgtable_alloc)(void))
>  {
> +	if (pgtable_alloc && debug_pagealloc_enabled())
> +		return false;
> +
>  	if (PAGE_SHIFT != 12)
>  		return false;
>  
> @@ -241,7 +245,7 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
>  		/*
>  		 * For 4K granule only, attempt to put down a 1GB block
>  		 */
> -		if (use_1G_block(addr, next, phys)) {
> +		if (use_1G_block(addr, next, phys, pgtable_alloc)) {
>  			pud_t old_pud = *pud;
>  			set_pud(pud, __pud(phys |
>  					   pgprot_val(mk_sect_prot(prot))));

The checks for pgtable_alloc is to allow create_mapping_noalloc to use
sections regardless, right?

I got a little confused by that initially, but that seems to make sense.

> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
> index 1360a02..69a8a7d 100644
> --- a/arch/arm64/mm/pageattr.c
> +++ b/arch/arm64/mm/pageattr.c
> @@ -38,7 +38,8 @@ static int change_page_range(pte_t *ptep, pgtable_t token, unsigned long addr,
>  }
>  
>  static int change_memory_common(unsigned long addr, int numpages,
> -				pgprot_t set_mask, pgprot_t clear_mask)
> +				pgprot_t set_mask, pgprot_t clear_mask,
> +				bool ignore_vma_check)
>  {
>  	unsigned long start = addr;
>  	unsigned long size = PAGE_SIZE*numpages;
> @@ -65,11 +66,14 @@ static int change_memory_common(unsigned long addr, int numpages,
>  	 *
>  	 * So check whether the [addr, addr + size) interval is entirely
>  	 * covered by precisely one VM area that has the VM_ALLOC flag set.
> +	 *
> +	 * The one exception to this is is we're forcing everything to be
> +	 * page mapped with DEBUG_PAGEALLOC
>  	 */
>  	area = find_vm_area((void *)addr);
> -	if (!area ||
> +	if (!ignore_vma_check && (!area ||
>  	    end > (unsigned long)area->addr + area->size ||
> -	    !(area->flags & VM_ALLOC))
> +	    !(area->flags & VM_ALLOC)))
>  		return -EINVAL;

Perhaps we could pull out everything but the VMA checks into a static
__change_memory_common. Then we can call that directly in
__kernel_map_pages, and don't need to pass a confusing boolean
parameter.

Otherwise, this looks good to me.

Mark.

>  
>  	data.set_mask = set_mask;
> @@ -86,21 +90,24 @@ int set_memory_ro(unsigned long addr, int numpages)
>  {
>  	return change_memory_common(addr, numpages,
>  					__pgprot(PTE_RDONLY),
> -					__pgprot(PTE_WRITE));
> +					__pgprot(PTE_WRITE),
> +					false);
>  }
>  
>  int set_memory_rw(unsigned long addr, int numpages)
>  {
>  	return change_memory_common(addr, numpages,
>  					__pgprot(PTE_WRITE),
> -					__pgprot(PTE_RDONLY));
> +					__pgprot(PTE_RDONLY),
> +					false);
>  }
>  
>  int set_memory_nx(unsigned long addr, int numpages)
>  {
>  	return change_memory_common(addr, numpages,
>  					__pgprot(PTE_PXN),
> -					__pgprot(0));
> +					__pgprot(0),
> +					false);
>  }
>  EXPORT_SYMBOL_GPL(set_memory_nx);
>  
> @@ -108,6 +115,25 @@ int set_memory_x(unsigned long addr, int numpages)
>  {
>  	return change_memory_common(addr, numpages,
>  					__pgprot(0),
> -					__pgprot(PTE_PXN));
> +					__pgprot(PTE_PXN),
> +					false);
>  }
>  EXPORT_SYMBOL_GPL(set_memory_x);
> +
> +#ifdef CONFIG_DEBUG_PAGEALLOC
> +void __kernel_map_pages(struct page *page, int numpages, int enable)
> +{
> +	unsigned long addr = (unsigned long) page_address(page);
> +
> +	if (enable)
> +		change_memory_common(addr, numpages,
> +					__pgprot(PTE_VALID),
> +					__pgprot(0),
> +					true);
> +	else
> +		change_memory_common(addr, numpages,
> +					__pgprot(0),
> +					__pgprot(PTE_VALID),
> +					true);
> +}
> +#endif
> -- 
> 2.5.0
> 


From zhang.chunyan at linaro.org  Mon Feb  1 04:44:05 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Mon, 1 Feb 2016 20:44:05 +0800
Subject: [PATCH 6/6] coresight-stm: adding driver for CoreSight STM
 component
In-Reply-To: <201602011753.FpQPQQPf%fengguang.wu@intel.com>
References: <1454313529-8860-7-git-send-email-zhang.chunyan@linaro.org>
 <201602011753.FpQPQQPf%fengguang.wu@intel.com>
Message-ID: <CAG2=9p_vBrgyzZohZ-LK2uoMRYEJFnyBQvUQJEgfTKCk+GvRwA@mail.gmail.com>

Hi Mathieu,

So sorry that I forgot this patch depends on [1] which hasn't been upstreamed.
How about adding the definition of coresight_simple_func() like [1]
does in the STM driver for the time being? It can be simply removed
once [1] is upstreamed. If you agree with this idea, I'll add the
definition of coresight_simple_func() in the next version of patches.

Thanks,
Chunyan

[1] https://git.linaro.org/people/mathieu.poirier/coresight.git/blobdiff/59aadd3319527addcf8dbc6e6064b15f74b244fe..76dda3d0d313a4676d43adef52ad8faec0c61b61:/drivers/hwtracing/coresight/coresight-priv.h

On Mon, Feb 1, 2016 at 6:01 PM, kbuild test robot <lkp at intel.com> wrote:
> Hi Pratik,
>
> [auto build test ERROR on robh/for-next]
> [also build test ERROR on v4.5-rc2 next-20160201]
> [if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
>
> url:    https://github.com/0day-ci/linux/commits/Chunyan-Zhang/Introduce-CoreSight-STM-support/20160201-160437
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
> config: arm-allmodconfig (attached as .config)
> reproduce:
>         wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         make.cross ARCH=arm
>
> All errors (new ones prefixed by >>):
>
>>> drivers/hwtracing/coresight/coresight-stm.c:671:27: error: unknown type name 'tcsr'
>     coresight_stm_simple_func(tcsr, STMTCSR);
>                               ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                ^
>>> drivers/hwtracing/coresight/coresight-stm.c:57:20: error: expected declaration specifiers or '...' before numeric constant
>     #define STMTCSR    0xe80
>                        ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                      ^
>    drivers/hwtracing/coresight/coresight-stm.c:671:33: note: in expansion of macro 'STMTCSR'
>     coresight_stm_simple_func(tcsr, STMTCSR);
>                                     ^
>>> drivers/hwtracing/coresight/coresight-stm.c:672:27: error: unknown type name 'tsfreqr'
>     coresight_stm_simple_func(tsfreqr, STMTSFREQR);
>                               ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                ^
>    drivers/hwtracing/coresight/coresight-stm.c:59:22: error: expected declaration specifiers or '...' before numeric constant
>     #define STMTSFREQR   0xe8c
>                          ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                      ^
>    drivers/hwtracing/coresight/coresight-stm.c:672:36: note: in expansion of macro 'STMTSFREQR'
>     coresight_stm_simple_func(tsfreqr, STMTSFREQR);
>                                        ^
>>> drivers/hwtracing/coresight/coresight-stm.c:673:27: error: unknown type name 'syncr'
>     coresight_stm_simple_func(syncr, STMSYNCR);
>                               ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                ^
>    drivers/hwtracing/coresight/coresight-stm.c:60:20: error: expected declaration specifiers or '...' before numeric constant
>     #define STMSYNCR   0xe90
>                        ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                      ^
>    drivers/hwtracing/coresight/coresight-stm.c:673:34: note: in expansion of macro 'STMSYNCR'
>     coresight_stm_simple_func(syncr, STMSYNCR);
>                                      ^
>>> drivers/hwtracing/coresight/coresight-stm.c:674:27: error: unknown type name 'sper'
>     coresight_stm_simple_func(sper, STMSPER);
>                               ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                ^
>    drivers/hwtracing/coresight/coresight-stm.c:49:20: error: expected declaration specifiers or '...' before numeric constant
>     #define STMSPER    0xe00
>                        ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                      ^
>    drivers/hwtracing/coresight/coresight-stm.c:674:33: note: in expansion of macro 'STMSPER'
>     coresight_stm_simple_func(sper, STMSPER);
>                                     ^
>>> drivers/hwtracing/coresight/coresight-stm.c:675:27: error: unknown type name 'spter'
>     coresight_stm_simple_func(spter, STMSPTER);
>                               ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                ^
>    drivers/hwtracing/coresight/coresight-stm.c:50:20: error: expected declaration specifiers or '...' before numeric constant
>     #define STMSPTER   0xe20
>                        ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                      ^
>    drivers/hwtracing/coresight/coresight-stm.c:675:34: note: in expansion of macro 'STMSPTER'
>     coresight_stm_simple_func(spter, STMSPTER);
>                                      ^
>>> drivers/hwtracing/coresight/coresight-stm.c:676:27: error: unknown type name 'privmaskr'
>     coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
>                               ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                ^
>    drivers/hwtracing/coresight/coresight-stm.c:51:24: error: expected declaration specifiers or '...' before numeric constant
>     #define STMPRIVMASKR   0xe40
>                            ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                      ^
>    drivers/hwtracing/coresight/coresight-stm.c:676:38: note: in expansion of macro 'STMPRIVMASKR'
>     coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
>                                          ^
>>> drivers/hwtracing/coresight/coresight-stm.c:677:27: error: unknown type name 'spscr'
>     coresight_stm_simple_func(spscr, STMSPSCR);
>                               ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                ^
>    drivers/hwtracing/coresight/coresight-stm.c:52:20: error: expected declaration specifiers or '...' before numeric constant
>     #define STMSPSCR   0xe60
>                        ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                      ^
>    drivers/hwtracing/coresight/coresight-stm.c:677:34: note: in expansion of macro 'STMSPSCR'
>     coresight_stm_simple_func(spscr, STMSPSCR);
>                                      ^
>>> drivers/hwtracing/coresight/coresight-stm.c:678:27: error: unknown type name 'spmscr'
>     coresight_stm_simple_func(spmscr, STMSPMSCR);
>                               ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                ^
>    drivers/hwtracing/coresight/coresight-stm.c:53:21: error: expected declaration specifiers or '...' before numeric constant
>     #define STMSPMSCR   0xe64
>                         ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                      ^
>    drivers/hwtracing/coresight/coresight-stm.c:678:35: note: in expansion of macro 'STMSPMSCR'
>     coresight_stm_simple_func(spmscr, STMSPMSCR);
>                                       ^
>>> drivers/hwtracing/coresight/coresight-stm.c:679:27: error: unknown type name 'spfeat1r'
>     coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
>                               ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                ^
>    drivers/hwtracing/coresight/coresight-stm.c:62:23: error: expected declaration specifiers or '...' before numeric constant
>     #define STMSPFEAT1R   0xea0
>                           ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                      ^
>    drivers/hwtracing/coresight/coresight-stm.c:679:37: note: in expansion of macro 'STMSPFEAT1R'
>     coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
>                                         ^
>>> drivers/hwtracing/coresight/coresight-stm.c:680:27: error: unknown type name 'spfeat2r'
>     coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
>                               ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                ^
>    drivers/hwtracing/coresight/coresight-stm.c:63:23: error: expected declaration specifiers or '...' before numeric constant
>     #define STMSPFEAT2R   0xea4
>                           ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                      ^
>    drivers/hwtracing/coresight/coresight-stm.c:680:37: note: in expansion of macro 'STMSPFEAT2R'
>     coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
>                                         ^
>>> drivers/hwtracing/coresight/coresight-stm.c:681:27: error: unknown type name 'spfeat3r'
>     coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
>                               ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                ^
>    drivers/hwtracing/coresight/coresight-stm.c:64:23: error: expected declaration specifiers or '...' before numeric constant
>     #define STMSPFEAT3R   0xea8
>                           ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                      ^
>    drivers/hwtracing/coresight/coresight-stm.c:681:37: note: in expansion of macro 'STMSPFEAT3R'
>     coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
>                                         ^
>>> drivers/hwtracing/coresight/coresight-stm.c:682:27: error: unknown type name 'devid'
>     coresight_stm_simple_func(devid, CORESIGHT_DEVID);
>                               ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                ^
>    drivers/hwtracing/coresight/coresight-priv.h:31:26: error: expected declaration specifiers or '...' before numeric constant
>     #define CORESIGHT_DEVID  0xfc8
>                              ^
>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>      coresight_simple_func(struct stm_drvdata, name, offset)
>                                                      ^
>    drivers/hwtracing/coresight/coresight-stm.c:682:34: note: in expansion of macro 'CORESIGHT_DEVID'
>     coresight_stm_simple_func(devid, CORESIGHT_DEVID);
>                                      ^
>>> drivers/hwtracing/coresight/coresight-stm.c:694:3: error: 'dev_attr_tcsr' undeclared here (not in a function)
>      &dev_attr_tcsr.attr,
>       ^
>>> drivers/hwtracing/coresight/coresight-stm.c:695:3: error: 'dev_attr_tsfreqr' undeclared here (not in a function)
>      &dev_attr_tsfreqr.attr,
>       ^
>>> drivers/hwtracing/coresight/coresight-stm.c:696:3: error: 'dev_attr_syncr' undeclared here (not in a function)
>      &dev_attr_syncr.attr,
>       ^
>>> drivers/hwtracing/coresight/coresight-stm.c:697:3: error: 'dev_attr_sper' undeclared here (not in a function)
>      &dev_attr_sper.attr,
>       ^
>>> drivers/hwtracing/coresight/coresight-stm.c:698:3: error: 'dev_attr_spter' undeclared here (not in a function)
>      &dev_attr_spter.attr,
>       ^
>>> drivers/hwtracing/coresight/coresight-stm.c:699:3: error: 'dev_attr_privmaskr' undeclared here (not in a function)
>      &dev_attr_privmaskr.attr,
>       ^
>>> drivers/hwtracing/coresight/coresight-stm.c:700:3: error: 'dev_attr_spscr' undeclared here (not in a function)
>      &dev_attr_spscr.attr,
>       ^
>
> vim +/tcsr +671 drivers/hwtracing/coresight/coresight-stm.c
>
>    663          drvdata->traceid = val & 0x7f;
>    664          return size;
>    665  }
>    666  static DEVICE_ATTR_RW(traceid);
>    667
>    668  #define coresight_stm_simple_func(name, offset) \
>  > 669          coresight_simple_func(struct stm_drvdata, name, offset)
>    670
>  > 671  coresight_stm_simple_func(tcsr, STMTCSR);
>  > 672  coresight_stm_simple_func(tsfreqr, STMTSFREQR);
>  > 673  coresight_stm_simple_func(syncr, STMSYNCR);
>  > 674  coresight_stm_simple_func(sper, STMSPER);
>  > 675  coresight_stm_simple_func(spter, STMSPTER);
>  > 676  coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
>  > 677  coresight_stm_simple_func(spscr, STMSPSCR);
>  > 678  coresight_stm_simple_func(spmscr, STMSPMSCR);
>  > 679  coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
>  > 680  coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
>  > 681  coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
>  > 682  coresight_stm_simple_func(devid, CORESIGHT_DEVID);
>    683
>    684  static struct attribute *coresight_stm_attrs[] = {
>    685          &dev_attr_hwevent_enable.attr,
>    686          &dev_attr_hwevent_select.attr,
>    687          &dev_attr_port_enable.attr,
>    688          &dev_attr_port_select.attr,
>    689          &dev_attr_traceid.attr,
>    690          NULL,
>    691  };
>    692
>    693  static struct attribute *coresight_stm_mgmt_attrs[] = {
>  > 694          &dev_attr_tcsr.attr,
>  > 695          &dev_attr_tsfreqr.attr,
>  > 696          &dev_attr_syncr.attr,
>  > 697          &dev_attr_sper.attr,
>  > 698          &dev_attr_spter.attr,
>  > 699          &dev_attr_privmaskr.attr,
>  > 700          &dev_attr_spscr.attr,
>  > 701          &dev_attr_spmscr.attr,
>  > 702          &dev_attr_spfeat1r.attr,
>  > 703          &dev_attr_spfeat2r.attr,
>  > 704          &dev_attr_spfeat3r.attr,
>  > 705          &dev_attr_devid.attr,
>    706          NULL,
>    707  };
>    708
>
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation


From djkurtz at chromium.org  Mon Feb  1 04:53:51 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Mon, 1 Feb 2016 20:53:51 +0800
Subject: [PATCH v8 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
In-Reply-To: <1454300012-32552-2-git-send-email-jitao.shi@mediatek.com>
References: <1454300012-32552-1-git-send-email-jitao.shi@mediatek.com>
 <1454300012-32552-2-git-send-email-jitao.shi@mediatek.com>
Message-ID: <CAGS+omB7wFBWZQqdD3iOONaVxZXacT0Eq+05f3FAb6YtVABzuQ@mail.gmail.com>

On Mon, Feb 1, 2016 at 12:13 PM, Jitao Shi <jitao.shi at mediatek.com> wrote:
> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
>
> Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> ---
> Changes since v7:
>  - Change ps8640_regw to ps8640_regw_bytes and remove devm_kzalloc
>  - Fine tune ps8640 power squence
>  - Add ps8640_pre_enable and ps8640_post_disable in ps8640_get_modes
>  - Remove unnecessary codes and comments
>
> The following patches are needed to support dsi host through none dsi bus:
>
> https://patchwork.kernel.org/patch/7818431/ ("drm/dsi: check for CONFIG_OF when defining of_mipi_dsi_device_add")
> https://patchwork.kernel.org/patch/7818471/ ("drm/dsi: Refactor device creation")
> https://patchwork.kernel.org/patch/7818501/ ("drm/dsi: Try to match non-DT dsi devices")
> https://patchwork.kernel.org/patch/7818531/ ("drm/dsi: Check for used channels")
> https://patchwork.kernel.org/patch/7818561/ ("drm/dsi: Add routine to unregister dsi device")
> https://patchwork.kernel.org/patch/7818541/ ("drm/dsi: Get DSI host by DT device node")
> ---
>  drivers/gpu/drm/bridge/Kconfig         |   10 +
>  drivers/gpu/drm/bridge/Makefile        |    1 +
>  drivers/gpu/drm/bridge/parade-ps8640.c | 1084 ++++++++++++++++++++++++++++++++
>  3 files changed, 1095 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 27e2022..fe8ad50 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -40,4 +40,14 @@ config DRM_PARADE_PS8622
>         ---help---
>           Parade eDP-LVDS bridge chip driver.
>
> +config DRM_PARADE_PS8640
> +       tristate "Parade PS8640 MIPI DSI to eDP Converter"
> +       depends on OF && I2C
> +       select DRM_KMS_HELPER

I think this needs:

select DRM_MIPI_DSI

Otherwise:
drivers/gpu/drm/bridge/parade-ps8640.c:400: undefined reference to
`of_find_mipi_dsi_host_by_node'
drivers/gpu/drm/bridge/parade-ps8640.c:411: undefined reference to
`mipi_dsi_attach'

> +       select DRM_PANEL

> +       ---help---
> +         Choose this option if you have PS8640 for display
> +         The PS8640 is a high-performance and low-power
> +         MIPI DSI to eDP converter
> +
>  endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index f13c33d..fbe38dc 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c
> new file mode 100644
> index 0000000..0230ab5
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -0,0 +1,1084 @@
> +/*
> + * Copyright (c) 2014 MediaTek Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/firmware.h>
> +#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_gpio.h>
> +#include <linux/of_graph.h>
> +#include <linux/regulator/consumer.h>
> +#include <asm/unaligned.h>
> +#include <drm/drm_panel.h>
> +
> +#include <drmP.h>
> +#include <drm_atomic_helper.h>
> +#include <drm_crtc_helper.h>
> +#include <drm_crtc.h>
> +#include <drm_mipi_dsi.h>
> +
> +#define PAGE2_SPI_CFG3         0x82
> +#define I2C_TO_SPI_RESET       0x20
> +#define PAGE2_ROMADD_BYTE1     0x8e
> +#define PAGE2_ROMADD_BYTE2     0x8f
> +#define PAGE2_SWSPI_WDATA      0x90
> +#define PAGE2_SWSPI_RDATA      0x91
> +#define PAGE2_SWSPI_LEN                0x92
> +#define PAGE2_SWSPI_CTL                0x93
> +#define TRIGGER_NO_READBACK    0x05
> +#define TRIGGER_READBACK       0x01
> +#define PAGE2_SPI_STATUS       0x9e
> +#define PAGE2_GPIO_L           0xa6
> +#define PAGE2_GPIO_H           0xa7
> +#define PS_GPIO9               BIT(1)
> +#define PAGE2_IROM_CTRL                0xb0
> +#define IROM_ENABLE            0xc0
> +#define IROM_DISABLE           0x80
> +#define PAGE2_SW_REST          0xbc
> +#define PAGE2_ENCTLSPI_WR      0xda
> +#define PAGE2_I2C_BYPASS       0xea
> +#define I2C_BYPASS_EN          0xd0
> +
> +#define PAGE3_SET_ADD          0xfe
> +#define PAGE3_SET_VAL          0xff
> +#define VDO_CTL_ADD            0x13
> +#define VDO_DIS                        0x18
> +#define VDO_EN                 0x1c
> +
> +#define PAGE4_REV_L            0xf0
> +#define PAGE4_REV_H            0xf1
> +#define PAGE4_CHIP_L           0xf2
> +#define PAGE4_CHIP_H           0xf3
> +
> +/* Firmware */
> +#define SPI_MAX_RETRY_CNT      8
> +#define PS_FW_NAME             "ps864x_fw.bin"
> +
> +#define FW_CHIP_ID_OFFSET      0
> +#define FW_VERSION_OFFSET      2
> +
> +#define bridge_to_ps8640(e)    container_of(e, struct ps8640, bridge)
> +#define connector_to_ps8640(e) container_of(e, struct ps8640, connector)
> +
> +struct ps8640_info {
> +       u8 family_id;
> +       u8 variant_id;
> +       u16 version;
> +};
> +
> +struct ps8640 {
> +       struct drm_connector connector;
> +       struct drm_bridge bridge;
> +       struct mipi_dsi_device *dsi;
> +       struct i2c_client *page[8];
> +       struct ps8640_driver_data *driver_data;
> +       struct regulator *pwr_1v2_supply;
> +       struct regulator *pwr_3v3_supply;
> +       struct drm_panel *panel;
> +       struct gpio_desc *gpio_rst_n;
> +       struct gpio_desc *gpio_slp_n;
> +       struct gpio_desc *gpio_mode_sel_n;
> +       bool enabled;
> +
> +       /* firmware file name */
> +       bool in_fw_update;
> +       char *fw_file;
> +       struct ps8640_info info;
> +};
> +
> +static const u8 enc_ctrl_code[6] = {0xaa, 0x55, 0x50, 0x41, 0x52, 0x44};
> +
> +static int ps8640_regr(struct i2c_client *client, u8 reg, u8 *data,
> +                      u16 data_len)

IMHO, ps8640_read() and ps8640_write() are clearer than regr and regw.

> +{
> +       int ret;
> +       struct i2c_msg msgs[] = {
> +               {
> +                .addr = client->addr,
> +                .flags = 0,
> +                .len = 1,
> +                .buf = &reg,
> +                },
> +               {
> +                .addr = client->addr,
> +                .flags = I2C_M_RD,
> +                .len = data_len,
> +                .buf = data,
> +                }
> +       };
> +
> +       ret = i2c_transfer(client->adapter, msgs, 2);
> +
> +       if (ret == 2)
> +               return 0;
> +       if (ret < 0)
> +               return ret;
> +       else
> +               return -EIO;
> +}
> +
> +static int ps8640_regw_bytes(struct i2c_client *client, u8 *data,
> +                            u16 data_len)
> +{
> +       int ret;
> +       struct i2c_msg msg;
> +
> +       msg.addr = client->addr;
> +       msg.flags = 0;
> +       msg.len = data_len;
> +       msg.buf = data;
> +
> +       ret = i2c_transfer(client->adapter, &msg, 1);
> +       if (ret == 1)
> +               return 0;
> +       if (ret < 0)
> +               return ret;
> +       else
> +               return -EIO;
> +}
> +
> +static int ps8640_regw_byte(struct i2c_client *client, u8 reg,  u8 data)
> +{
> +       int ret;
> +       struct i2c_msg msg;
> +       u8 buf[] = {reg, data};
> +
> +       msg.addr = client->addr;
> +       msg.flags = 0;
> +       msg.len = sizeof(buf);
> +       msg.buf = buf;
> +
> +       ret = i2c_transfer(client->adapter, &msg, 1);
> +       if (ret == 1)
> +               return 0;
> +       if (ret < 0)
> +               return ret;
> +       else
> +               return -EIO;
> +}
> +
> +static void ps8640_get_mcu_fw_version(struct ps8640 *ps_bridge)
> +{
> +       struct i2c_client *client = ps_bridge->page[5];
> +       u8 fw_ver[2];
> +
> +       ps8640_regr(client, 0x4, fw_ver, 2);
> +       ps_bridge->info.version = (fw_ver[0] << 8) | fw_ver[1];
> +
> +       DRM_INFO_ONCE("ps8640 rom fw version %d.%d\n", fw_ver[0], fw_ver[1]);
> +}
> +
> +static int ps8640_bridge_enable(struct ps8640 *ps_bridge)
> +{
> +       struct i2c_client *client = ps_bridge->page[3];
> +       int ret;
> +       u8 vdo_ctrl_buf[3] = {PAGE3_SET_ADD, VDO_CTL_ADD, VDO_EN};
> +
> +       ret = ps8640_regw_bytes(client, vdo_ctrl_buf, 3);
> +       return ret;

nit:  Just:

   return ps8640_regw_bytes(client, vdo_ctrl_buf, 3);

> +}
> +
> +static void ps8640_pre_enable(struct drm_bridge *bridge)
> +{
> +       struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> +       struct i2c_client *client = ps_bridge->page[2];
> +       int err, retry_cnt = 0;
> +       u8 set_vdo_done;
> +
> +       if (ps_bridge->in_fw_update)
> +               return;
> +
> +       if (ps_bridge->enabled)
> +               return;
> +
> +       err = drm_panel_prepare(ps_bridge->panel);
> +       if (err < 0) {
> +               DRM_ERROR("failed to prepare panel: %d\n", err);
> +               return;
> +       }
> +
> +       gpiod_set_value(ps_bridge->gpio_slp_n, 1);
> +       gpiod_set_value(ps_bridge->gpio_rst_n, 0);
> +
> +       err = regulator_enable(ps_bridge->pwr_1v2_supply);
> +       if (err < 0) {
> +               DRM_ERROR("failed to enable vdd12-supply: %d\n", err);
> +               goto err_panel_unprepare;
> +       }
> +
> +       err = regulator_enable(ps_bridge->pwr_3v3_supply);
> +       if (err < 0) {
> +               DRM_ERROR("failed to enable vdd33-supply: %d\n", err);
> +               goto err_regulator_1v2_disable;
> +       }
> +
> +       usleep_range(500, 700);
> +       gpiod_set_value(ps_bridge->gpio_rst_n, 1);
> +
> +       /*
> +        * Wait for the ps8640 embed mcu ready
> +        * First wait 200ms and then check the mcu ready flag every 20ms
> +        */
> +       msleep(200);
> +       do {
> +               err = ps8640_regr(client, PAGE2_GPIO_H, &set_vdo_done, 1);
> +               if (err < 0) {
> +                       DRM_ERROR("failed read PAGE2_GPIO_H: %d\n", err);
> +                       goto err_regulator_1v2_disable;
> +               }
> +               msleep(20);
> +       } while ((retry_cnt++ < 10) && ((set_vdo_done & PS_GPIO9) != PS_GPIO9));
> +
> +       if (ps_bridge->info.version == 0)
> +               ps8640_get_mcu_fw_version(ps_bridge);
> +       /* Switch access edp panel's edid through i2c */
> +       ps8640_regw_byte(client, PAGE2_I2C_BYPASS, I2C_BYPASS_EN);
> +       ps_bridge->enabled = true;
> +
> +       return;
> +
> +err_regulator_1v2_disable:
> +       regulator_disable(ps_bridge->pwr_1v2_supply);
> +err_panel_unprepare:
> +       drm_panel_unprepare(ps_bridge->panel);
> +}
> +
> +static void ps8640_enable(struct drm_bridge *bridge)
> +{
> +       struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> +       int err;
> +
> +       err = ps8640_bridge_enable(ps_bridge);
> +       if (err)
> +               DRM_ERROR("failed to enable unmutevideo: %d\n", err);
> +
> +       err = drm_panel_enable(ps_bridge->panel);
> +       if (err < 0)
> +               DRM_ERROR("failed to enable panel: %d\n", err);
> +}
> +
> +static void ps8640_disable(struct drm_bridge *bridge)
> +{
> +       struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> +       int err;
> +
> +       err = drm_panel_disable(ps_bridge->panel);
> +       if (err < 0)
> +               DRM_ERROR("failed to disable panel: %d\n", err);

Should there be a ps8640_bridge_disable() here, to undo ps8640_bridge_enable()?

> +}
> +
> +static void ps8640_post_disable(struct drm_bridge *bridge)
> +{
> +       struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> +       int err;
> +
> +       if (ps_bridge->in_fw_update)
> +               return;
> +
> +       if (!ps_bridge->enabled)
> +               return;
> +
> +       ps_bridge->enabled = false;
> +
> +       gpiod_set_value(ps_bridge->gpio_rst_n, 0);
> +       gpiod_set_value(ps_bridge->gpio_slp_n, 0);
> +       regulator_disable(ps_bridge->pwr_3v3_supply);
> +       regulator_disable(ps_bridge->pwr_1v2_supply);
> +
> +       err = drm_panel_unprepare(ps_bridge->panel);
> +       if (err)
> +               DRM_ERROR("failed to unprepare panel: %d\n", err);
> +}
> +
> +static int ps8640_get_modes(struct drm_connector *connector)
> +{
> +       struct ps8640 *ps_bridge = connector_to_ps8640(connector);
> +       bool power_off;
> +       int num_modes = 0;
> +
> +       power_off = !ps_bridge->enabled;
> +       ps8640_pre_enable(&ps_bridge->bridge);
> +
> +       num_modes = drm_panel_get_modes(ps_bridge->panel);
> +
> +       if (power_off)
> +               ps8640_post_disable(&ps_bridge->bridge);
> +
> +       return num_modes;
> +}
> +
> +static struct drm_encoder *ps8640_best_encoder(struct drm_connector *connector)
> +{
> +       struct ps8640 *ps_bridge;
> +
> +       ps_bridge = connector_to_ps8640(connector);
> +       return ps_bridge->bridge.encoder;
> +}
> +
> +static const struct drm_connector_helper_funcs ps8640_connector_helper_funcs = {
> +       .get_modes = ps8640_get_modes,
> +       .best_encoder = ps8640_best_encoder,
> +};
> +
> +static enum drm_connector_status ps8640_detect(struct drm_connector *connector,
> +                                              bool force)
> +{
> +       return connector_status_connected;
> +}
> +
> +static void ps8640_connector_destroy(struct drm_connector *connector)
> +{
> +       drm_connector_unregister(connector);
> +       drm_connector_cleanup(connector);
> +}
> +
> +static const struct drm_connector_funcs ps8640_connector_funcs = {
> +       .dpms = drm_atomic_helper_connector_dpms,
> +       .fill_modes = drm_helper_probe_single_connector_modes,
> +       .detect = ps8640_detect,
> +       .destroy = ps8640_connector_destroy,
> +       .reset = drm_atomic_helper_connector_reset,
> +       .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> +       .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +int ps8640_bridge_attach(struct drm_bridge *bridge)
> +{
> +       struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> +       struct device *dev = &ps_bridge->page[0]->dev;
> +       struct device_node *np = dev->of_node;
> +       struct device_node *port, *in_ep;
> +       struct device_node *dsi_node = NULL;
> +       struct mipi_dsi_host *host = ps_bridge->dsi->host;
> +       int ret;
> +
> +       ret = drm_connector_init(bridge->dev, &ps_bridge->connector,
> +                                &ps8640_connector_funcs,
> +                                DRM_MODE_CONNECTOR_eDP);
> +
> +       if (ret) {
> +               DRM_ERROR("Failed to initialize connector with drm: %d\n", ret);
> +               return ret;
> +       }
> +
> +       drm_connector_helper_add(&ps_bridge->connector,
> +                                &ps8640_connector_helper_funcs);
> +       drm_connector_register(&ps_bridge->connector);
> +
> +       ps_bridge->connector.dpms = DRM_MODE_DPMS_ON;
> +       drm_mode_connector_attach_encoder(&ps_bridge->connector,
> +                                         bridge->encoder);
> +
> +       if (ps_bridge->panel)
> +               drm_panel_attach(ps_bridge->panel, &ps_bridge->connector);
> +
> +       /* port at 0 is ps8640 dsi input port */
> +       port = of_graph_get_port_by_id(np, 0);
> +       if (port) {
> +               in_ep = of_get_child_by_name(port, "endpoint");
> +               of_node_put(port);
> +               if (in_ep) {
> +                       dsi_node = of_graph_get_remote_port_parent(in_ep);
> +                       of_node_put(in_ep);
> +               }
> +       }
> +       if (dsi_node) {
> +               host = of_find_mipi_dsi_host_by_node(dsi_node);
> +               of_node_put(dsi_node);
> +               if (!host)
> +                       return -ENODEV;
> +       }
> +
> +       ps_bridge->dsi->host = host;
> +       ps_bridge->dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> +                                    MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
> +       ps_bridge->dsi->format = MIPI_DSI_FMT_RGB888;
> +       ps_bridge->dsi->lanes = 4;
> +       ret = mipi_dsi_attach(ps_bridge->dsi);
> +       if (ret) {
> +               drm_panel_detach(ps_bridge->panel);
> +               return ret;
> +       }
> +
> +       return ret;
> +}
> +
> +static const struct drm_bridge_funcs ps8640_bridge_funcs = {
> +       .attach = ps8640_bridge_attach,
> +       .disable = ps8640_disable,
> +       .post_disable = ps8640_post_disable,
> +       .pre_enable = ps8640_pre_enable,
> +       .enable = ps8640_enable,
> +};
> +
> +static ssize_t ps8640_fw_file_show(struct device *dev,
> +                                  struct device_attribute *attr, char *buf)
> +{
> +       struct ps8640 *ps_bridge = dev_get_drvdata(dev);
> +
> +       return scnprintf(buf, PAGE_SIZE, "%s\n", ps_bridge->fw_file);
> +}
> +
> +static int ps8640_update_file_name(struct device *dev, char **file_name,
> +                                  const char *buf, size_t count)

Just remove this function now since fw_file is always just PS_FW_NAME.

> +{
> +       char *new_file_name;
> +
> +       /* Simple sanity check */
> +       if (count > 64) {
> +               dev_warn(dev, "File name too long\n");
> +               return -EINVAL;
> +       }
> +
> +       new_file_name = devm_kmalloc(dev, count + 1, GFP_KERNEL);
> +       if (!new_file_name)
> +               return -ENOMEM;
> +
> +       memcpy(new_file_name, buf, count + 1);
> +
> +       /* Echo into the sysfs entry may append newline at the end of buf */
> +       if (new_file_name[count - 1] == '\n')
> +               count--;
> +
> +       new_file_name[count] = '\0';
> +
> +       if (*file_name)
> +               devm_kfree(dev, *file_name);
> +
> +       *file_name = new_file_name;
> +
> +       return 0;
> +}
> +
> +/* Firmware Version is returned as Major.Minor.Build */
> +static ssize_t ps8640_fw_version_show(struct device *dev,
> +                                     struct device_attribute *attr, char *buf)
> +{
> +       struct ps8640 *ps_bridge = dev_get_drvdata(dev);
> +       struct ps8640_info *info = &ps_bridge->info;
> +
> +       return scnprintf(buf, PAGE_SIZE, "%u.%u\n", info->version >> 8,
> +                        info->version & 0xff);

Just remove this sysfs entry since fw_file is always just PS_FW_NAME.

> +}
> +
> +/* Hardware Version is returned as FamilyID.VariantID */
> +static ssize_t ps8640_hw_version_show(struct device *dev,
> +                                     struct device_attribute *attr, char *buf)
> +{
> +       struct ps8640 *ps_bridge = dev_get_drvdata(dev);
> +       struct ps8640_info *info = &ps_bridge->info;
> +
> +       return scnprintf(buf, PAGE_SIZE, "ps%u.%u\n", info->family_id,
> +                        info->variant_id);
> +}
> +
> +static int ps8640_spi_send_cmd(struct ps8640 *ps_bridge, u8 *cmd, u8 cmd_len)
> +{
> +       struct i2c_client *client = ps_bridge->page[2];
> +       u8 i;
> +       int ret;
> +
> +       ret = ps8640_regw_byte(client, PAGE2_IROM_CTRL, IROM_ENABLE);
> +       if (ret)
> +               goto err;
> +
> +       /* write command in write port */
> +       for (i = 0; i < cmd_len; i++) {
> +               ret = ps8640_regw_byte(client, PAGE2_SWSPI_WDATA, cmd[i]);
> +               if (ret)
> +                       goto err;
> +       }
> +       /* command length */
> +       ret = ps8640_regw_byte(client, PAGE2_SWSPI_LEN, cmd_len - 1);
> +       if (ret)
> +               goto err;
> +       /* trigger read */
> +       ret = ps8640_regw_byte(client, PAGE2_SWSPI_CTL, TRIGGER_NO_READBACK);
> +       if (ret)
> +               goto err;

nit: you can probably combine the write of PAGE2_SWSPI_LEN &
PAGE2_SWSPI_CTL into a single i2c transaction, here and in
ps8640_wait_spi_nobusy().

> +
> +       ret = ps8640_regw_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
> +       if (ret)
> +               goto err;
> +
> +       return 0;
> +
> +err:
> +       dev_err(&client->dev, "send command err: %d\n", ret);
> +       return ret;
> +}
> +
> +static int ps8640_wait_spi_ready(struct ps8640 *ps_bridge)
> +{
> +       struct i2c_client *client = ps_bridge->page[2];
> +       u8 spi_rdy_st, retry_cnt = 0;
> +
> +       do {
> +               ps8640_regr(client, PAGE2_SPI_STATUS, &spi_rdy_st, 1);
> +               msleep(20);
> +               if ((retry_cnt == SPI_MAX_RETRY_CNT) &&
> +                   ((spi_rdy_st & 0x0c) != 0x0c)) {
> +                       dev_err(&client->dev, "wait spi ready timeout\n");
> +                       return -EBUSY;
> +               }
> +       } while ((retry_cnt++ < SPI_MAX_RETRY_CNT) &&
> +                (spi_rdy_st & 0x0c) == 0x0c);
> +
> +       return 0;
> +}
> +
> +static int ps8640_wait_spi_nobusy(struct ps8640 *ps_bridge)
> +{
> +       struct i2c_client *client = ps_bridge->page[2];
> +       u8 spi_status, retry_cnt = 0;
> +       int ret;
> +
> +       do {
> +               /* 0x05 RDSR; Read-Status-Register */
> +               ret = ps8640_regw_byte(client, PAGE2_SWSPI_WDATA, 0x05);

Please #define this constant 0x05.


> +               if (ret)
> +                       goto err_send_cmd_exit;
> +
> +               /* command length */
> +               ret = ps8640_regw_byte(client, PAGE2_SWSPI_LEN, 0x00);
> +               if (ret)
> +                       goto err_send_cmd_exit;
> +
> +               /* trigger read */
> +               ret = ps8640_regw_byte(client, PAGE2_SWSPI_CTL,
> +                                      TRIGGER_READBACK);
> +               if (ret)
> +                       goto err_send_cmd_exit;
> +
> +               /* delay for cmd send */
> +               usleep_range(100, 300);
> +               /* wait for SPI ROM until not busy */
> +               ret = ps8640_regr(client, PAGE2_SWSPI_RDATA, &spi_status, 1);
> +               if (ret)
> +                       goto err_send_cmd_exit;
> +       } while ((retry_cnt++ < SPI_MAX_RETRY_CNT) &&
> +                (spi_status & 0x0c) == 0x0c);
> +
> +       if ((retry_cnt > SPI_MAX_RETRY_CNT) && (spi_status & 0x0c) != 0x0c) {

Please #define this constant 0x0c.


> +               ret = -EBUSY;
> +               dev_err(&client->dev, "wait spi no busy timeout: %d\n", ret);
> +               goto err_timeout;
> +       }
> +
> +       return 0;
> +
> +err_send_cmd_exit:
> +       dev_err(&client->dev, "send command err: %d\n", ret);
> +
> +err_timeout:
> +       return ret;
> +}
> +
> +static int ps8640_wait_rom_idle(struct ps8640 *ps_bridge)
> +{
> +       struct i2c_client *client = ps_bridge->page[0];
> +       int ret;
> +
> +       ret = ps8640_regw_byte(client, PAGE2_IROM_CTRL, IROM_ENABLE);
> +       if (ret)
> +               goto exit;
> +
> +       ret = ps8640_wait_spi_ready(ps_bridge);
> +       if (ret)
> +               goto exit;
> +
> +       ret = ps8640_wait_spi_nobusy(ps_bridge);
> +       if (ret)
> +               goto exit;
> +
> +       ret = ps8640_regw_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
> +       if (ret)
> +               goto exit;
> +
> +exit:
> +       if (ret)
> +               dev_err(&client->dev, "wait ps8640 rom idle fail: %d\n", ret);
> +
> +       return ret;
> +}
> +
> +static int ps8640_spi_dl_mode(struct ps8640 *ps_bridge)
> +{
> +       struct i2c_client *client = ps_bridge->page[2];
> +       int ret;
> +
> +       /* switch ps8640 mode to spi dl mode */
> +       gpiod_set_value(ps_bridge->gpio_mode_sel_n, 0);
> +
> +       /* reset spi interface */
> +       ret = ps8640_regw_byte(client, PAGE2_SW_REST, 0xc0);

Please #define these constants, 0xc0 & 0x40.  Is this a bit field?

> +       if (ret)
> +               goto exit;
> +
> +       ret = ps8640_regw_byte(client, PAGE2_SW_REST, 0x40);
> +       if (ret)
> +               goto exit;
> +
> +exit:
> +       if (ret)
> +               dev_err(&client->dev, "fail reset spi interface: %d\n", ret);
> +
> +       return ret;
> +}
> +
> +static int ps8640_rom_prepare(struct ps8640 *ps_bridge)
> +{
> +       struct i2c_client *client = ps_bridge->page[2];
> +       struct device *dev = &client->dev;
> +       u8 i, cmd[2];
> +       int ret;
> +
> +       /* Enable-Write-Status-Register */
> +       cmd[0] = 0x06;

Please #define magic numbers / constants in this function.


> +       ret = ps8640_spi_send_cmd(ps_bridge, cmd, 1);
> +       if (ret) {
> +               dev_err(dev, "failed enable-write-status-register: %d\n", ret);
> +               return ret;
> +       }
> +
> +       /* disable all protection */
> +       cmd[0] = 0x01;
> +       cmd[1] = 0x00;
> +       ret = ps8640_spi_send_cmd(ps_bridge, cmd, 2);
> +       if (ret) {
> +               dev_err(dev, "fail disable all protection: %d\n", ret);
> +               return ret;
> +       }
> +
> +       /* wait for SPI module ready */
> +       ret = ps8640_wait_rom_idle(ps_bridge);
> +       if (ret) {
> +               dev_err(dev, "fail wait rom idle: %d\n", ret);
> +               return ret;
> +       }
> +
> +       ps8640_regw_byte(client, PAGE2_IROM_CTRL, IROM_ENABLE);
> +       for (i = 0; i < 6; i++)
> +               ps8640_regw_byte(client, PAGE2_ENCTLSPI_WR, enc_ctrl_code[i]);
> +       ps8640_regw_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
> +
> +       /* Enable-Write-Status-Register */
> +       cmd[0] = 0x06;
> +       ret = ps8640_spi_send_cmd(ps_bridge, cmd, 1);
> +       if (ret) {
> +               dev_err(dev, "fail enable-write-status-register: %d\n", ret);
> +               return ret;
> +       }
> +
> +       /* chip erase command */
> +       cmd[0] = 0xc7;
> +       ret = ps8640_spi_send_cmd(ps_bridge, cmd, 1);
> +       if (ret) {
> +               dev_err(dev, "fail disable all protection: %d\n", ret);
> +               return ret;
> +       }
> +
> +       ret = ps8640_wait_rom_idle(ps_bridge);
> +       if (ret) {
> +               dev_err(dev, "fail wait rom idle: %d\n", ret);
> +               return ret;
> +       }
> +
> +       return 0;
> +}
> +
> +static int ps8640_validate_firmware(struct ps8640 *ps_bridge,
> +                                   const struct firmware *fw)
> +{
> +       struct i2c_client *client = ps_bridge->page[0];
> +       struct ps8640_info *info = &ps_bridge->info;
> +       u16 fw_chip_id, fw_version_id;
> +
> +       /*
> +        * Get the chip_id from the firmware. Make sure that it is the
> +        * right controller to do the firmware and config update.
> +        */
> +       fw_chip_id = get_unaligned_le16(fw->data + FW_CHIP_ID_OFFSET);
> +
> +       if (fw_chip_id != 0x8640) {
> +               dev_err(&client->dev,
> +                       "chip id mismatch: fw 0x%x vs. chip 0x8640\n",
> +                       fw_chip_id);
> +               return -ENODEV;
> +       }
> +
> +       fw_version_id = get_unaligned_le16(fw->data + FW_VERSION_OFFSET);
> +
> +       if (fw_chip_id != info->version) {
> +               dev_err(&client->dev,
> +                       "fw version mismatch: fw %d.%d vs. chip %d.%d\n",
> +                       fw_version_id >> 8, fw_version_id & 0xff,
> +                       info->version >> 8, info->version & 0xff);
> +               return -ENODEV;
> +       }
> +
> +       return 0;
> +}
> +
> +static int ps8640_write_rom(struct ps8640 *ps_bridge, const struct firmware *fw)
> +{
> +       struct i2c_client *client = ps_bridge->page[0];
> +       struct device *dev = &client->dev;
> +       struct i2c_client *client2 = ps_bridge->page[2];
> +       struct i2c_client *client7 = ps_bridge->page[7];
> +       unsigned int pos = 0;
> +       u8 buf[257], rom_page_id_buf[3];
> +       int ret;
> +       u16 cpy_len;
> +
> +       ps8640_regw_byte(client2, PAGE2_SPI_CFG3, I2C_TO_SPI_RESET);
> +       msleep(100);
> +       ps8640_regw_byte(client2, PAGE2_SPI_CFG3, 0x00);
> +
> +       while (pos < fw->size) {
> +               rom_page_id_buf[0] = PAGE2_ROMADD_BYTE1;
> +               rom_page_id_buf[1] = (pos >> 8) & 0xff;
> +               rom_page_id_buf[2] = (pos >> 16) & 0xff;
> +               ret = ps8640_regw_bytes(client2, rom_page_id_buf, 3);
> +               if (ret)
> +                       goto error;
> +               cpy_len = fw->size >= 256 + pos ? 256 : fw->size - pos;
> +               buf[0] = 0;
> +               memcpy(buf + 1, fw->data + pos, cpy_len);
> +               ret = ps8640_regw_bytes(client7, buf, cpy_len + 1);
> +               if (ret)
> +                       goto error;
> +
> +               pos += cpy_len;
> +
> +               dev_dbg(dev, "fw update completed %u / %zu bytes\n", pos,
> +                       fw->size);
> +       }
> +       return 0;
> +
> +error:
> +       dev_err(dev, "failed write extenal flash, %d\n", ret);
> +       return ret;
> +}
> +
> +static int ps8640_spi_normal_mode(struct ps8640 *ps_bridge)
> +{
> +       u8 cmd[2];
> +       struct i2c_client *client = ps_bridge->page[2];

Please #define magic numbers / constants in this function.

> +
> +       /* Enable-Write-Status-Register */
> +       cmd[0] = 0x06;
> +       ps8640_spi_send_cmd(ps_bridge, cmd, 1);
> +
> +       /* protect BPL/BP0/BP1 */
> +       cmd[0] = 0x01;
> +       cmd[1] = 0x8c;
> +       ps8640_spi_send_cmd(ps_bridge, cmd, 2);
> +
> +       /* wait for SPI rom ready */
> +       ps8640_wait_rom_idle(ps_bridge);
> +
> +       /* disable PS8640 mapping function */
> +       ps8640_regw_byte(client, PAGE2_ENCTLSPI_WR, 0x00);
> +
> +       gpiod_set_value(ps_bridge->gpio_mode_sel_n, 1);
> +       return 0;
> +}
> +
> +static int ps8640_enter_bl(struct ps8640 *ps_bridge)
> +{
> +       int ret;
> +
> +       ret = ps8640_spi_dl_mode(ps_bridge);
> +       if (ret)
> +               return ret;
> +
> +       ps_bridge->in_fw_update = true;

Set in_fw_update before ps8640_spi_dl_mode() to avoid a race between
between ps8640_spi_dl_mode() and ps8640_pre_enable / post_disable().

> +       return 0;
> +}
> +
> +static void ps8640_exit_bl(struct ps8640 *ps_bridge, const struct firmware *fw)
> +{
> +       ps_bridge->in_fw_update = false;
> +       ps8640_spi_normal_mode(ps_bridge);

Set in_fw_update after ps8640_spi_normal_mode() to avoid a race
between between ps8640_spi_normal_mode() and ps8640_pre_enable /
post_disable().

> +}
> +
> +static int ps8640_load_fw(struct ps8640 *ps_bridge, const struct firmware *fw)
> +{
> +       struct i2c_client *client = ps_bridge->page[0];
> +       struct device *dev = &client->dev;
> +       int ret;
> +       bool ps8640_status_backup = ps_bridge->enabled;
> +
> +       if (!ps_bridge->in_fw_update) {
> +               if (!ps8640_status_backup)
> +                       ps8640_pre_enable(&ps_bridge->bridge);
> +
> +               ret = ps8640_enter_bl(ps_bridge);
> +               if (ret)
> +                       goto exit;
> +       }
> +
> +       ret = ps8640_validate_firmware(ps_bridge, fw);
> +       if (ret)
> +               goto exit;
> +
> +       ret = ps8640_rom_prepare(ps_bridge);
> +       if (ret)
> +               goto exit;
> +
> +       ret = ps8640_write_rom(ps_bridge, fw);
> +
> +exit:
> +       if (ret)
> +               dev_err(dev, "Failed to load firmware, %d\n", ret);
> +
> +       ps8640_exit_bl(ps_bridge, fw);
> +       if (!ps8640_status_backup)
> +               ps8640_post_disable(&ps_bridge->bridge);
> +       return ret;
> +}
> +
> +static ssize_t ps8640_update_fw_store(struct device *dev,
> +                                     struct device_attribute *attr,
> +                                     const char *buf, size_t count)
> +{
> +       struct i2c_client *client = to_i2c_client(dev);
> +       struct ps8640 *ps_bridge = i2c_get_clientdata(client);
> +       const struct firmware *fw;
> +       int error;
> +
> +       error = request_firmware(&fw, ps_bridge->fw_file, dev);
> +       if (error) {
> +               dev_err(dev, "Unable to open firmware %s: %d\n",
> +                       ps_bridge->fw_file, error);
> +               return error;
> +       }
> +
> +       error = ps8640_load_fw(ps_bridge, fw);
> +       if (error)
> +               dev_err(dev, "The firmware update failed(%d)\n", error);
> +       else
> +               dev_info(dev, "The firmware update succeeded\n");
> +
> +       release_firmware(fw);
> +       return error ? error : count;
> +}
> +
> +static DEVICE_ATTR(fw_file, S_IRUGO, ps8640_fw_file_show, NULL);
> +static DEVICE_ATTR(fw_version, S_IRUGO, ps8640_fw_version_show, NULL);
> +static DEVICE_ATTR(hw_version, S_IRUGO, ps8640_hw_version_show, NULL);
> +static DEVICE_ATTR(update_fw, S_IWUSR, NULL, ps8640_update_fw_store);
> +
> +static struct attribute *ps8640_attrs[] = {
> +       &dev_attr_fw_file.attr,
> +       &dev_attr_fw_version.attr,
> +       &dev_attr_hw_version.attr,
> +       &dev_attr_update_fw.attr,
> +       NULL
> +};
> +
> +static const struct attribute_group ps8640_attr_group = {
> +       .attrs = ps8640_attrs,
> +};
> +
> +static void ps8640_remove_sysfs_group(void *data)
> +{
> +       struct ps8640 *ps_bridge = data;
> +
> +       sysfs_remove_group(&ps_bridge->page[0]->dev.kobj, &ps8640_attr_group);
> +}
> +
> +static int ps8640_probe(struct i2c_client *client,
> +                       const struct i2c_device_id *id)
> +{
> +       struct device *dev = &client->dev;
> +       struct ps8640 *ps_bridge;
> +       struct device_node *np = dev->of_node;
> +       struct device_node *port, *out_ep;
> +       struct device_node *panel_node = NULL;
> +       int i, ret;
> +
> +       ps_bridge = devm_kzalloc(dev, sizeof(*ps_bridge), GFP_KERNEL);
> +       ps_bridge->dsi = devm_kzalloc(dev, sizeof(struct mipi_dsi_device),
> +                                     GFP_KERNEL);
> +       if (!ps_bridge) {
> +               ret = -ENOMEM;
> +               goto exit;

nit: instead of "goto exit", you can just:

  return -ENOMEM; (for all of these "goto exit")

> +       }
> +       /* port at 1 is ps8640 output port */
> +       port = of_graph_get_port_by_id(np, 1);
> +       if (port) {
> +               out_ep = of_get_child_by_name(port, "endpoint");
> +               of_node_put(port);
> +               if (out_ep) {
> +                       panel_node = of_graph_get_remote_port_parent(out_ep);
> +                       of_node_put(out_ep);
> +               }
> +       }
> +       if (panel_node) {
> +               ps_bridge->panel = of_drm_find_panel(panel_node);
> +               of_node_put(panel_node);
> +               if (!ps_bridge->panel) {
> +                       ret = -EPROBE_DEFER;
> +                       goto exit;
> +               }
> +       }
> +
> +       ps_bridge->pwr_3v3_supply = devm_regulator_get(dev, "vdd33");
> +       if (IS_ERR(ps_bridge->pwr_3v3_supply)) {
> +               ret = PTR_ERR(ps_bridge->pwr_3v3_supply);
> +               dev_err(dev, "cannot get vdd33 supply: %d\n", ret);
> +               goto exit;
> +       }
> +
> +       ps_bridge->pwr_1v2_supply = devm_regulator_get(dev, "vdd12");
> +       if (IS_ERR(ps_bridge->pwr_1v2_supply)) {
> +               ret = PTR_ERR(ps_bridge->pwr_1v2_supply);
> +               dev_err(dev, "cannot get vdd12 supply: %d\n", ret);
> +               goto exit;
> +       }
> +
> +       ps_bridge->gpio_mode_sel_n = devm_gpiod_get(&client->dev, "mode-sel",
> +                                                   GPIOD_OUT_HIGH);
> +       if (IS_ERR(ps_bridge->gpio_mode_sel_n)) {
> +               ret = PTR_ERR(ps_bridge->gpio_mode_sel_n);
> +               dev_err(dev, "cannot get gpio_mode_sel_n %d\n", ret);

nit: I'd use the gpio's device tree name in the error message here, so
"mode-sel".
Same for the others, below.

  dev_err(dev, "cannot get gpio 'mode-sel' %d\n", ret);

Thanks,
-Dan


From majun258 at huawei.com  Mon Feb  1 05:06:38 2016
From: majun258 at huawei.com (majun (F))
Date: Mon, 1 Feb 2016 21:06:38 +0800
Subject: [RFC PATCH] irq/mbigen:Fix the problem of IO remap for duplicated
 physical address in mbigen driver
In-Reply-To: <20160201115717.GD674@leverpostej>
References: <1454327094-7848-1-git-send-email-majun258@huawei.com>
 <20160201115717.GD674@leverpostej>
Message-ID: <56AF585E.6050005@huawei.com>



? 2016/2/1 19:57, Mark Rutland ??:
> On Mon, Feb 01, 2016 at 07:44:54PM +0800, MaJun wrote:
>> From: Ma Jun <majun258 at huawei.com>
>>
>> For mbigen module, there is a special case that more than one mbigen 
>> device nodes use the same reg definition in DTS when these devices
>> exist in the same mbigen hardware module. 
>>
>> mbigen_dev1:intc_dev1 {
>> 	...
>> 	reg = <0x0 0xc0080000 0x0 0x10000>;
>> 	...
>> };
>>
>> mbigen_dev2:intc_dev2 {
>> 	...
>> 	reg = <0x0 0xc0080000 0x0 0x10000>;
>> 	...
>> };
> 
> This doesn't sound right. If they exist in the same place, and have the
> same reg, they _are_ the same device.
> 
> You'll need to explain this better.
> 

For a mbigen hardware module which connecte with several devices,
because these devices has different device ID,
I need to define a device node for each device in DTS file.

	mbigen
	|
------------------
| 	| 	|
dev1 	dev2 	dev3

Because of register layout,the registers related with these devices
are put together, I can't split them clearly.
So, I only make these devices which connect with
same mbigen hardware module usethe same address.

>> On this case, devm_ioremap_resource() returns fail with info
>> "can't request region for resource" because of memory region check.
>>
>> Because we only need to program 1 into corresponding bit into status 
>> register of mbigen to clear the interrupt status during runtime,
>> I think we can replace devm_ioremap_resource() by devm_ioremap().
>>
>> Signed-off-by: Ma Jun <majun258 at huawei.com>
>> ---
>>  drivers/irqchip/irq-mbigen.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
>> index 4dd3eb8..b19e528 100644
>> --- a/drivers/irqchip/irq-mbigen.c
>> +++ b/drivers/irqchip/irq-mbigen.c
>> @@ -250,7 +250,7 @@ static int mbigen_device_probe(struct platform_device *pdev)
>>  	mgn_chip->pdev = pdev;
>>  
>>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> -	mgn_chip->base = devm_ioremap_resource(&pdev->dev, res);
>> +	mgn_chip->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> 
> These two behaving differently doesn't seem correct either...

The problem is caused by memory region check fail because of duplicated address in devm_ioremap_resource().
For mbigen special case, there is no necessary to do this check.

Thanks
Ma Jun
> 
> Mark.
> 
>>  	if (IS_ERR(mgn_chip->base))
>>  		return PTR_ERR(mgn_chip->base);
>>  
>> -- 
>> 1.7.1
>>
>>
> 
> .
> 



From gregory.clement at free-electrons.com  Mon Feb  1 05:07:41 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  1 Feb 2016 14:07:41 +0100
Subject: [PATCH v2 net 0/6] mvneta fixes for SMP
Message-ID: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>

Hi,

Following this bug report:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/468173 and the
suggestions from Russell King, I reviewed all the code involving
multi-CPU. It ended with this series of patches which should improve
the stability of the driver.

The first patch fix a real bug, the other fix potential issues in the
driver.

Thanks,

Gregory

Changelog:

v1 -> v2
Fix spinlock comment. Pointed by David Miller


Gregory CLEMENT (6):
  net: mvneta: Fix for_each_present_cpu usage
  net: mvneta: Use on_each_cpu when possible
  net: mvneta: Remove unused code
  net: mvneta: Modify the queue related fields from each cpu
  net: mvneta: The mvneta_percpu_elect function should be atomic
  net: mvneta: Fix race condition during stopping

 drivers/net/ethernet/marvell/mvneta.c | 162 ++++++++++++++++++----------------
 1 file changed, 84 insertions(+), 78 deletions(-)

-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  1 05:07:44 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  1 Feb 2016 14:07:44 +0100
Subject: [PATCH v2 net 3/6] net: mvneta: Remove unused code
In-Reply-To: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454332067-16378-4-git-send-email-gregory.clement@free-electrons.com>

Since the commit 2dcf75e2793c ("net: mvneta: Associate RX queues with
each CPU") all the percpu irq are used and unmask at initialization, so
there is no point to unmask them first.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 3d6e3137f305..861b7e0d7d5f 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3009,14 +3009,6 @@ static int mvneta_open(struct net_device *dev)
 		goto err_cleanup_txqs;
 	}
 
-	/* Even though the documentation says that request_percpu_irq
-	 * doesn't enable the interrupts automatically, it actually
-	 * does so on the local CPU.
-	 *
-	 * Make sure it's disabled.
-	 */
-	mvneta_percpu_disable(pp);
-
 	/* Enable per-CPU interrupt on all the CPU to handle our RX
 	 * queue interrupts
 	 */
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  1 05:07:43 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  1 Feb 2016 14:07:43 +0100
Subject: [PATCH v2 net 2/6] net: mvneta: Use on_each_cpu when possible
In-Reply-To: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454332067-16378-3-git-send-email-gregory.clement@free-electrons.com>

Instead of using a for_each_* loop in which we just call the
smp_call_function_single macro, it is more simple to directly use the
on_each_cpu macro. Moreover, this macro ensures that the calls will be
done all at once.

Suggested-by: Russell King <rmk+kernel at arm.linux.org.uk>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 90ff5c7e19ea..3d6e3137f305 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2555,7 +2555,7 @@ static void mvneta_percpu_mask_interrupt(void *arg)
 
 static void mvneta_start_dev(struct mvneta_port *pp)
 {
-	unsigned int cpu;
+	int cpu;
 
 	mvneta_max_rx_size_set(pp, pp->pkt_size);
 	mvneta_txq_max_tx_size_set(pp, pp->pkt_size);
@@ -2571,9 +2571,8 @@ static void mvneta_start_dev(struct mvneta_port *pp)
 	}
 
 	/* Unmask interrupts. It has to be done from each CPU */
-	for_each_online_cpu(cpu)
-		smp_call_function_single(cpu, mvneta_percpu_unmask_interrupt,
-					 pp, true);
+	on_each_cpu(mvneta_percpu_unmask_interrupt, pp, true);
+
 	mvreg_write(pp, MVNETA_INTR_MISC_MASK,
 		    MVNETA_CAUSE_PHY_STATUS_CHANGE |
 		    MVNETA_CAUSE_LINK_CHANGE |
@@ -2988,7 +2987,7 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 static int mvneta_open(struct net_device *dev)
 {
 	struct mvneta_port *pp = netdev_priv(dev);
-	int ret, cpu;
+	int ret;
 
 	pp->pkt_size = MVNETA_RX_PKT_SIZE(pp->dev->mtu);
 	pp->frag_size = SKB_DATA_ALIGN(MVNETA_RX_BUF_SIZE(pp->pkt_size)) +
@@ -3021,9 +3020,7 @@ static int mvneta_open(struct net_device *dev)
 	/* Enable per-CPU interrupt on all the CPU to handle our RX
 	 * queue interrupts
 	 */
-	for_each_online_cpu(cpu)
-		smp_call_function_single(cpu, mvneta_percpu_enable,
-					 pp, true);
+	on_each_cpu(mvneta_percpu_enable, pp, true);
 
 
 	/* Register a CPU notifier to handle the case where our CPU
@@ -3310,9 +3307,7 @@ static int  mvneta_config_rss(struct mvneta_port *pp)
 
 	netif_tx_stop_all_queues(pp->dev);
 
-	for_each_online_cpu(cpu)
-		smp_call_function_single(cpu, mvneta_percpu_mask_interrupt,
-					 pp, true);
+	on_each_cpu(mvneta_percpu_mask_interrupt, pp, true);
 
 	/* We have to synchronise on the napi of each CPU */
 	for_each_online_cpu(cpu) {
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  1 05:07:42 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  1 Feb 2016 14:07:42 +0100
Subject: [PATCH v2 net 1/6] net: mvneta: Fix for_each_present_cpu usage
In-Reply-To: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454332067-16378-2-git-send-email-gregory.clement@free-electrons.com>

This patch convert the for_each_present in on_each_cpu, instead of
applying on the present cpus it will be applied only on the online cpus.
This fix a bug reported on
http://thread.gmane.org/gmane.linux.ports.arm.kernel/468173.

Using the macro on_each_cpu (instead of a for_each_* loop) also ensures
that all the calls will be done all at once.

Fixes: f86428854480 ("net: mvneta: Statically assign queues to CPUs")
Reported-by: Stefan Roese <stefan.roese at gmail.com>
Suggested-by: Jisheng Zhang <jszhang at marvell.com>
Suggested-by: Russell King <rmk+kernel at arm.linux.org.uk>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 662c2ee268c7..90ff5c7e19ea 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2564,7 +2564,7 @@ static void mvneta_start_dev(struct mvneta_port *pp)
 	mvneta_port_enable(pp);
 
 	/* Enable polling on the port */
-	for_each_present_cpu(cpu) {
+	for_each_online_cpu(cpu) {
 		struct mvneta_pcpu_port *port = per_cpu_ptr(pp->ports, cpu);
 
 		napi_enable(&port->napi);
@@ -2589,7 +2589,7 @@ static void mvneta_stop_dev(struct mvneta_port *pp)
 
 	phy_stop(pp->phy_dev);
 
-	for_each_present_cpu(cpu) {
+	for_each_online_cpu(cpu) {
 		struct mvneta_pcpu_port *port = per_cpu_ptr(pp->ports, cpu);
 
 		napi_disable(&port->napi);
@@ -3057,13 +3057,11 @@ err_cleanup_rxqs:
 static int mvneta_stop(struct net_device *dev)
 {
 	struct mvneta_port *pp = netdev_priv(dev);
-	int cpu;
 
 	mvneta_stop_dev(pp);
 	mvneta_mdio_remove(pp);
 	unregister_cpu_notifier(&pp->cpu_notifier);
-	for_each_present_cpu(cpu)
-		smp_call_function_single(cpu, mvneta_percpu_disable, pp, true);
+	on_each_cpu(mvneta_percpu_disable, pp, true);
 	free_percpu_irq(dev->irq, pp->ports);
 	mvneta_cleanup_rxqs(pp);
 	mvneta_cleanup_txqs(pp);
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  1 05:07:45 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  1 Feb 2016 14:07:45 +0100
Subject: [PATCH v2 net 4/6] net: mvneta: Modify the queue related fields from
 each cpu
In-Reply-To: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454332067-16378-5-git-send-email-gregory.clement@free-electrons.com>

In the MVNETA_INTR_* registers, the queues related fields are per cpu,
according to the datasheet (comment in [] are added by me):
"In a multi-CPU system, bits of RX[or TX] queues for which the access by
the reading[or writing] CPU is disabled are read as 0, and cannot be
cleared[or written]."

That means that each time we want to manipulate these bits we had to do
it on each cpu and not only on the current cpu.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 100 ++++++++++++++++------------------
 1 file changed, 46 insertions(+), 54 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 861b7e0d7d5f..1ed813d478e8 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1038,6 +1038,43 @@ static void mvneta_set_autoneg(struct mvneta_port *pp, int enable)
 	}
 }
 
+static void mvneta_percpu_unmask_interrupt(void *arg)
+{
+	struct mvneta_port *pp = arg;
+
+	/* All the queue are unmasked, but actually only the ones
+	 * mapped to this CPU will be unmasked
+	 */
+	mvreg_write(pp, MVNETA_INTR_NEW_MASK,
+		    MVNETA_RX_INTR_MASK_ALL |
+		    MVNETA_TX_INTR_MASK_ALL |
+		    MVNETA_MISCINTR_INTR_MASK);
+}
+
+static void mvneta_percpu_mask_interrupt(void *arg)
+{
+	struct mvneta_port *pp = arg;
+
+	/* All the queue are masked, but actually only the ones
+	 * mapped to this CPU will be masked
+	 */
+	mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0);
+	mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0);
+	mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0);
+}
+
+static void mvneta_percpu_clear_intr_cause(void *arg)
+{
+	struct mvneta_port *pp = arg;
+
+	/* All the queue are cleared, but actually only the ones
+	 * mapped to this CPU will be cleared
+	 */
+	mvreg_write(pp, MVNETA_INTR_NEW_CAUSE, 0);
+	mvreg_write(pp, MVNETA_INTR_MISC_CAUSE, 0);
+	mvreg_write(pp, MVNETA_INTR_OLD_CAUSE, 0);
+}
+
 /* This method sets defaults to the NETA port:
  *	Clears interrupt Cause and Mask registers.
  *	Clears all MAC tables.
@@ -1055,14 +1092,10 @@ static void mvneta_defaults_set(struct mvneta_port *pp)
 	int max_cpu = num_present_cpus();
 
 	/* Clear all Cause registers */
-	mvreg_write(pp, MVNETA_INTR_NEW_CAUSE, 0);
-	mvreg_write(pp, MVNETA_INTR_OLD_CAUSE, 0);
-	mvreg_write(pp, MVNETA_INTR_MISC_CAUSE, 0);
+	on_each_cpu(mvneta_percpu_clear_intr_cause, pp, true);
 
 	/* Mask all interrupts */
-	mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0);
-	mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0);
-	mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0);
+	on_each_cpu(mvneta_percpu_mask_interrupt, pp, true);
 	mvreg_write(pp, MVNETA_INTR_ENABLE, 0);
 
 	/* Enable MBUS Retry bit16 */
@@ -2528,31 +2561,6 @@ static int mvneta_setup_txqs(struct mvneta_port *pp)
 	return 0;
 }
 
-static void mvneta_percpu_unmask_interrupt(void *arg)
-{
-	struct mvneta_port *pp = arg;
-
-	/* All the queue are unmasked, but actually only the ones
-	 * maped to this CPU will be unmasked
-	 */
-	mvreg_write(pp, MVNETA_INTR_NEW_MASK,
-		    MVNETA_RX_INTR_MASK_ALL |
-		    MVNETA_TX_INTR_MASK_ALL |
-		    MVNETA_MISCINTR_INTR_MASK);
-}
-
-static void mvneta_percpu_mask_interrupt(void *arg)
-{
-	struct mvneta_port *pp = arg;
-
-	/* All the queue are masked, but actually only the ones
-	 * maped to this CPU will be masked
-	 */
-	mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0);
-	mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0);
-	mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0);
-}
-
 static void mvneta_start_dev(struct mvneta_port *pp)
 {
 	int cpu;
@@ -2603,13 +2611,10 @@ static void mvneta_stop_dev(struct mvneta_port *pp)
 	mvneta_port_disable(pp);
 
 	/* Clear all ethernet port interrupts */
-	mvreg_write(pp, MVNETA_INTR_MISC_CAUSE, 0);
-	mvreg_write(pp, MVNETA_INTR_OLD_CAUSE, 0);
+	on_each_cpu(mvneta_percpu_clear_intr_cause, pp, true);
 
 	/* Mask all ethernet port interrupts */
-	mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0);
-	mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0);
-	mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0);
+	on_each_cpu(mvneta_percpu_mask_interrupt, pp, true);
 
 	mvneta_tx_reset(pp);
 	mvneta_rx_reset(pp);
@@ -2916,9 +2921,7 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 		}
 
 		/* Mask all ethernet port interrupts */
-		mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0);
-		mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0);
-		mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0);
+		on_each_cpu(mvneta_percpu_mask_interrupt, pp, true);
 		napi_enable(&port->napi);
 
 
@@ -2933,14 +2936,8 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 		 */
 		mvneta_percpu_elect(pp);
 
-		/* Unmask all ethernet port interrupts, as this
-		 * notifier is called for each CPU then the CPU to
-		 * Queue mapping is applied
-		 */
-		mvreg_write(pp, MVNETA_INTR_NEW_MASK,
-			MVNETA_RX_INTR_MASK(rxq_number) |
-			MVNETA_TX_INTR_MASK(txq_number) |
-			MVNETA_MISCINTR_INTR_MASK);
+		/* Unmask all ethernet port interrupts */
+		on_each_cpu(mvneta_percpu_unmask_interrupt, pp, true);
 		mvreg_write(pp, MVNETA_INTR_MISC_MASK,
 			MVNETA_CAUSE_PHY_STATUS_CHANGE |
 			MVNETA_CAUSE_LINK_CHANGE |
@@ -2951,9 +2948,7 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 	case CPU_DOWN_PREPARE_FROZEN:
 		netif_tx_stop_all_queues(pp->dev);
 		/* Mask all ethernet port interrupts */
-		mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0);
-		mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0);
-		mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0);
+		on_each_cpu(mvneta_percpu_mask_interrupt, pp, true);
 
 		napi_synchronize(&port->napi);
 		napi_disable(&port->napi);
@@ -2969,10 +2964,7 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 		/* Check if a new CPU must be elected now this on is down */
 		mvneta_percpu_elect(pp);
 		/* Unmask all ethernet port interrupts */
-		mvreg_write(pp, MVNETA_INTR_NEW_MASK,
-			MVNETA_RX_INTR_MASK(rxq_number) |
-			MVNETA_TX_INTR_MASK(txq_number) |
-			MVNETA_MISCINTR_INTR_MASK);
+		on_each_cpu(mvneta_percpu_unmask_interrupt, pp, true);
 		mvreg_write(pp, MVNETA_INTR_MISC_MASK,
 			MVNETA_CAUSE_PHY_STATUS_CHANGE |
 			MVNETA_CAUSE_LINK_CHANGE |
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  1 05:07:47 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  1 Feb 2016 14:07:47 +0100
Subject: [PATCH v2 net 6/6] net: mvneta: Fix race condition during stopping
In-Reply-To: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454332067-16378-7-git-send-email-gregory.clement@free-electrons.com>

When stopping the port, the CPU notifier are still there whereas the
mvneta_stop_dev function calls mvneta_percpu_disable() on each CPUs.
It was possible to have a new CPU coming at this point which could be
racy.

This patch adds a flag preventing executing the code notifier for a new CPU
when the port is stopping.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 4d40d2fde7ca..2f53975aa6ec 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -374,6 +374,7 @@ struct mvneta_port {
 	 * ensuring that the configuration remains coherent.
 	 */
 	spinlock_t lock;
+	bool is_stopping;
 
 	/* Core clock */
 	struct clk *clk;
@@ -2916,6 +2917,11 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 	switch (action) {
 	case CPU_ONLINE:
 	case CPU_ONLINE_FROZEN:
+		/* Configuring the driver for a new CPU while the
+		 * driver is stopping is racy, so just avoid it.
+		 */
+		if (pp->is_stopping)
+			break;
 		netif_tx_stop_all_queues(pp->dev);
 
 		/* We have to synchronise on tha napi of each CPU
@@ -3054,9 +3060,17 @@ static int mvneta_stop(struct net_device *dev)
 {
 	struct mvneta_port *pp = netdev_priv(dev);
 
+	/* Inform that we are stopping so we don't want to setup the
+	 * driver for new CPUs in the notifiers
+	 */
+	pp->is_stopping = true;
 	mvneta_stop_dev(pp);
 	mvneta_mdio_remove(pp);
 	unregister_cpu_notifier(&pp->cpu_notifier);
+	/* Now that the notifier are unregistered, we can clear the
+	 * flag
+	 */
+	pp->is_stopping = false;
 	on_each_cpu(mvneta_percpu_disable, pp, true);
 	free_percpu_irq(dev->irq, pp->ports);
 	mvneta_cleanup_rxqs(pp);
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  1 05:07:46 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  1 Feb 2016 14:07:46 +0100
Subject: [PATCH v2 net 5/6] net: mvneta: The mvneta_percpu_elect function
 should be atomic
In-Reply-To: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454332067-16378-6-git-send-email-gregory.clement@free-electrons.com>

Electing a CPU must be done in an atomic way: it should be done after or
before the removal/insertion of a CPU and this function is not reentrant.

During the loop of mvneta_percpu_elect we associates the queues to the
CPUs, if there is a topology change during this loop, then the mapping
between the CPUs and the queues could be wrong. During this loop the
interrupt mask is also updating for each CPUs, It should not be changed
in the same time by other part of the driver.

This patch adds spinlock to create the needed critical sections.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 1ed813d478e8..4d40d2fde7ca 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -370,6 +370,10 @@ struct mvneta_port {
 	struct net_device *dev;
 	struct notifier_block cpu_notifier;
 	int rxq_def;
+	/* Protect the access to the percpu interrupt registers,
+	 * ensuring that the configuration remains coherent.
+	 */
+	spinlock_t lock;
 
 	/* Core clock */
 	struct clk *clk;
@@ -2855,6 +2859,11 @@ static void mvneta_percpu_elect(struct mvneta_port *pp)
 {
 	int online_cpu_idx, max_cpu, cpu, i = 0;
 
+	/* Electing a CPU must done in an atomic way: it should be
+	 * done after or before the removal/insertion of a CPU and
+	 * this function is not reentrant.
+	 */
+	spin_lock(&pp->lock);
 	online_cpu_idx = pp->rxq_def % num_online_cpus();
 	max_cpu = num_present_cpus();
 
@@ -2893,6 +2902,7 @@ static void mvneta_percpu_elect(struct mvneta_port *pp)
 		i++;
 
 	}
+	spin_unlock(&pp->lock);
 };
 
 static int mvneta_percpu_notifier(struct notifier_block *nfb,
@@ -2947,8 +2957,13 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 	case CPU_DOWN_PREPARE:
 	case CPU_DOWN_PREPARE_FROZEN:
 		netif_tx_stop_all_queues(pp->dev);
+		/* Thanks to this lock we are sure that any pending
+		 * cpu election is done
+		 */
+		spin_lock(&pp->lock);
 		/* Mask all ethernet port interrupts */
 		on_each_cpu(mvneta_percpu_mask_interrupt, pp, true);
+		spin_unlock(&pp->lock);
 
 		napi_synchronize(&port->napi);
 		napi_disable(&port->napi);
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 05:09:30 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 14:09:30 +0100
Subject: [PATCH v5sub2 0/8] arm64: implement virtual KASLR
Message-ID: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>

At the request of Catalin, this series has been split off from my series
'arm64: implement support for KASLR v4' [1]. This sub-series deals with
creating a relocatable binary, and randomizing the virtual placement of
the kernel itself, the modules and the linear region based on entropy
supplied by the bootloader in the /chosen/kaslr-seed DT property.

Changes since v4:
- add randomization of the linear region, i.e., if the linear region is
  substantially larger than the space spanned by RAM, the mapping of RAM
  is moved to a random offset inside the linear region.
- dropped the CRC check in kaslr_early_init(), since the only code that may
  modify .data through __fixmap_remap_fdt() is instrumentation that should
  deal with that correctly (For instance, the branch profiling records taken
  branches in structs allocated in .data, and these counts will not be reset
  to 0 between the first and the second call to __mmap_switched())
- add Mark's ack to patch #4

Patch #1 adds support for resolving cross-module branches via veneers if the
module is located too far from the target. This should not be necessary in the
common case even with KASRL enabled, but since the space around the kernel image
will no longer be strictly reserved for modules, there is a slight chance that
the region may be exhausted, in which case modules will be moved further away
from the kernel (and each other)

Patches #2 and #3 deal with the fact that relocations of 64-bit values are
deferred to runtime when building a PIE executable, and some values are required
before the relocation routine executes (either in the code, or as an externally
visible constant in the Image header)

Patch #4 rehuffles asm/elf.h so we can use its preprocessor constants in head.S

Patch #5 and #6 implement building vmlinux as a PIE (Position Independent
Executable) binary, which is emitted with relocation information that is
processed by the program itself in the early boot code.

Patch #7 implements KASLR, i.e., CONFIG_RANDOMIZE_BASE for the core kernel and
for the module region.

Patch #8 implements KASLR for the linear region.

[1] http://thread.gmane.org/gmane.linux.kernel/2135931

Ard Biesheuvel (8):
  arm64: add support for module PLTs
  arm64: avoid R_AARCH64_ABS64 relocations for Image header fields
  arm64: avoid dynamic relocations in early boot code
  arm64: make asm/elf.h available to asm files
  scripts/sortextable: add support for ET_DYN binaries
  arm64: add support for building vmlinux as a relocatable PIE binary
  arm64: add support for kernel ASLR
  arm64: kaslr: randomize the linear region

 arch/arm64/Kconfig                 |  34 ++++
 arch/arm64/Makefile                |  10 +-
 arch/arm64/include/asm/assembler.h |  11 ++
 arch/arm64/include/asm/elf.h       |  24 ++-
 arch/arm64/include/asm/memory.h    |   5 +-
 arch/arm64/include/asm/module.h    |  11 ++
 arch/arm64/kernel/Makefile         |   2 +
 arch/arm64/kernel/efi-entry.S      |   2 +-
 arch/arm64/kernel/head.S           | 128 +++++++++++--
 arch/arm64/kernel/image.h          |  32 ++--
 arch/arm64/kernel/kaslr.c          | 143 ++++++++++++++
 arch/arm64/kernel/module-plts.c    | 201 ++++++++++++++++++++
 arch/arm64/kernel/module.c         |  20 +-
 arch/arm64/kernel/module.lds       |   3 +
 arch/arm64/kernel/setup.c          |  29 +++
 arch/arm64/kernel/vmlinux.lds.S    |  16 ++
 arch/arm64/mm/init.c               |  22 ++-
 arch/arm64/mm/mmu.c                |  33 +++-
 scripts/sortextable.c              |   8 +-
 19 files changed, 672 insertions(+), 62 deletions(-)
 create mode 100644 arch/arm64/kernel/kaslr.c
 create mode 100644 arch/arm64/kernel/module-plts.c
 create mode 100644 arch/arm64/kernel/module.lds

-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 05:09:32 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 14:09:32 +0100
Subject: [PATCH v5sub2 2/8] arm64: avoid R_AARCH64_ABS64 relocations for Image
 header fields
In-Reply-To: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454332178-4414-3-git-send-email-ard.biesheuvel@linaro.org>

Unfortunately, the current way of using the linker to emit build time
constants into the Image header will no longer work once we switch to
the use of PIE executables. The reason is that such constants are emitted
into the binary using R_AARCH64_ABS64 relocations, which are resolved at
runtime, not at build time, and the places targeted by those relocations
will contain zeroes before that.

So refactor the endian swapping linker script constant generation code so
that it emits the upper and lower 32-bit words separately.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/assembler.h | 11 +++++++
 arch/arm64/kernel/head.S           |  6 ++--
 arch/arm64/kernel/image.h          | 32 ++++++++++++--------
 3 files changed, 33 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index d8bfcc1ce923..70f7b9e04598 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -222,4 +222,15 @@ lr	.req	x30		// link register
 	.size	__pi_##x, . - x;	\
 	ENDPROC(x)
 
+	/*
+	 * Emit a 64-bit absolute little endian symbol reference in a way that
+	 * ensures that it will be resolved at build time, even when building a
+	 * PIE binary. This requires cooperation from the linker script, which
+	 * must emit the lo32/hi32 halves individually.
+	 */
+	.macro	le64sym, sym
+	.long	\sym\()_lo32
+	.long	\sym\()_hi32
+	.endm
+
 #endif	/* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 05b98289093e..f076debf392d 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -83,9 +83,9 @@ efi_head:
 	b	stext				// branch to kernel start, magic
 	.long	0				// reserved
 #endif
-	.quad	_kernel_offset_le		// Image load offset from start of RAM, little-endian
-	.quad	_kernel_size_le			// Effective size of kernel image, little-endian
-	.quad	_kernel_flags_le		// Informative flags, little-endian
+	le64sym	_kernel_offset_le		// Image load offset from start of RAM, little-endian
+	le64sym	_kernel_size_le			// Effective size of kernel image, little-endian
+	le64sym	_kernel_flags_le		// Informative flags, little-endian
 	.quad	0				// reserved
 	.quad	0				// reserved
 	.quad	0				// reserved
diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
index c9c62cab25a4..db1bf57948f1 100644
--- a/arch/arm64/kernel/image.h
+++ b/arch/arm64/kernel/image.h
@@ -26,21 +26,27 @@
  * There aren't any ELF relocations we can use to endian-swap values known only
  * at link time (e.g. the subtraction of two symbol addresses), so we must get
  * the linker to endian-swap certain values before emitting them.
+ *
+ * Note that, in order for this to work when building the ELF64 PIE executable
+ * (for KASLR), these values should not be referenced via R_AARCH64_ABS64
+ * relocations, since these are fixed up at runtime rather than at build time
+ * when PIE is in effect. So we need to split them up in 32-bit high and low
+ * words.
  */
 #ifdef CONFIG_CPU_BIG_ENDIAN
-#define DATA_LE64(data)					\
-	((((data) & 0x00000000000000ff) << 56) |	\
-	 (((data) & 0x000000000000ff00) << 40) |	\
-	 (((data) & 0x0000000000ff0000) << 24) |	\
-	 (((data) & 0x00000000ff000000) << 8)  |	\
-	 (((data) & 0x000000ff00000000) >> 8)  |	\
-	 (((data) & 0x0000ff0000000000) >> 24) |	\
-	 (((data) & 0x00ff000000000000) >> 40) |	\
-	 (((data) & 0xff00000000000000) >> 56))
+#define DATA_LE32(data)				\
+	((((data) & 0x000000ff) << 24) |	\
+	 (((data) & 0x0000ff00) << 8)  |	\
+	 (((data) & 0x00ff0000) >> 8)  |	\
+	 (((data) & 0xff000000) >> 24))
 #else
-#define DATA_LE64(data) ((data) & 0xffffffffffffffff)
+#define DATA_LE32(data) ((data) & 0xffffffff)
 #endif
 
+#define DEFINE_IMAGE_LE64(sym, data)				\
+	sym##_lo32 = DATA_LE32((data) & 0xffffffff);		\
+	sym##_hi32 = DATA_LE32((data) >> 32)
+
 #ifdef CONFIG_CPU_BIG_ENDIAN
 #define __HEAD_FLAG_BE		1
 #else
@@ -61,9 +67,9 @@
  * endian swapped in head.S, all are done here for consistency.
  */
 #define HEAD_SYMBOLS						\
-	_kernel_size_le		= DATA_LE64(_end - _text);	\
-	_kernel_offset_le	= DATA_LE64(TEXT_OFFSET);	\
-	_kernel_flags_le	= DATA_LE64(__HEAD_FLAGS);
+	DEFINE_IMAGE_LE64(_kernel_size_le, _end - _text);	\
+	DEFINE_IMAGE_LE64(_kernel_offset_le, TEXT_OFFSET);	\
+	DEFINE_IMAGE_LE64(_kernel_flags_le, __HEAD_FLAGS);
 
 #ifdef CONFIG_EFI
 
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 05:09:31 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 14:09:31 +0100
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>

This adds support for emitting PLTs at module load time for relative
branches that are out of range. This is a prerequisite for KASLR, which
may place the kernel and the modules anywhere in the vmalloc area,
making it more likely that branch target offsets exceed the maximum
range of +/- 128 MB.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---

In this version, I removed the distinction between relocations against
.init executable sections and ordinary executable sections. The reason
is that it is hardly worth the trouble, given that .init.text usually
does not contain that many far branches, and this version now only
reserves PLT entry space for jump and call relocations against undefined
symbols (since symbols defined in the same module can be assumed to be
within +/- 128 MB)

For example, the mac80211.ko module (which is fairly sizable at ~400 KB)
built with -mcmodel=large gives the following relocation counts:

                    relocs    branches   unique     !local
  .text              3925       3347       518        219
  .init.text           11          8         7          1
  .exit.text            4          4         4          1
  .text.unlikely       81         67        36         17

('unique' means branches to unique type/symbol/addend combos, of which
!local is the subset referring to undefined symbols)

IOW, we are only emitting a single PLT entry for the .init sections, and
we are better off just adding it to the core PLT section instead.
---
 arch/arm64/Kconfig              |   9 +
 arch/arm64/Makefile             |   6 +-
 arch/arm64/include/asm/module.h |  11 ++
 arch/arm64/kernel/Makefile      |   1 +
 arch/arm64/kernel/module-plts.c | 201 ++++++++++++++++++++
 arch/arm64/kernel/module.c      |  12 ++
 arch/arm64/kernel/module.lds    |   3 +
 7 files changed, 242 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index cd767fa3037a..141f65ab0ed5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -394,6 +394,7 @@ config ARM64_ERRATUM_843419
 	bool "Cortex-A53: 843419: A load or store might access an incorrect address"
 	depends on MODULES
 	default y
+	select ARM64_MODULE_CMODEL_LARGE
 	help
 	  This option builds kernel modules using the large memory model in
 	  order to avoid the use of the ADRP instruction, which can cause
@@ -753,6 +754,14 @@ config ARM64_LSE_ATOMICS
 
 endmenu
 
+config ARM64_MODULE_CMODEL_LARGE
+	bool
+
+config ARM64_MODULE_PLTS
+	bool
+	select ARM64_MODULE_CMODEL_LARGE
+	select HAVE_MOD_ARCH_SPECIFIC
+
 endmenu
 
 menu "Boot options"
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 307237cfe728..a6bba9623836 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -43,10 +43,14 @@ endif
 
 CHECKFLAGS	+= -D__aarch64__
 
-ifeq ($(CONFIG_ARM64_ERRATUM_843419), y)
+ifeq ($(CONFIG_ARM64_MODULE_CMODEL_LARGE), y)
 KBUILD_CFLAGS_MODULE	+= -mcmodel=large
 endif
 
+ifeq ($(CONFIG_ARM64_MODULE_PLTS),y)
+KBUILD_LDFLAGS_MODULE	+= -T $(srctree)/arch/arm64/kernel/module.lds
+endif
+
 # Default value
 head-y		:= arch/arm64/kernel/head.o
 
diff --git a/arch/arm64/include/asm/module.h b/arch/arm64/include/asm/module.h
index e80e232b730e..8652fb613304 100644
--- a/arch/arm64/include/asm/module.h
+++ b/arch/arm64/include/asm/module.h
@@ -20,4 +20,15 @@
 
 #define MODULE_ARCH_VERMAGIC	"aarch64"
 
+#ifdef CONFIG_ARM64_MODULE_PLTS
+struct mod_arch_specific {
+	struct elf64_shdr	*plt;
+	int			plt_num_entries;
+	int			plt_max_entries;
+};
+#endif
+
+u64 module_emit_plt_entry(struct module *mod, const Elf64_Rela *rela,
+			  Elf64_Sym *sym);
+
 #endif /* __ASM_MODULE_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 83cd7e68e83b..e2f0a755beaa 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -30,6 +30,7 @@ arm64-obj-$(CONFIG_COMPAT)		+= sys32.o kuser32.o signal32.o 	\
 					   ../../arm/kernel/opcodes.o
 arm64-obj-$(CONFIG_FUNCTION_TRACER)	+= ftrace.o entry-ftrace.o
 arm64-obj-$(CONFIG_MODULES)		+= arm64ksyms.o module.o
+arm64-obj-$(CONFIG_ARM64_MODULE_PLTS)	+= module-plts.o
 arm64-obj-$(CONFIG_PERF_EVENTS)		+= perf_regs.o perf_callchain.o
 arm64-obj-$(CONFIG_HW_PERF_EVENTS)	+= perf_event.o
 arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT)	+= hw_breakpoint.o
diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plts.c
new file mode 100644
index 000000000000..1ce90d8450ae
--- /dev/null
+++ b/arch/arm64/kernel/module-plts.c
@@ -0,0 +1,201 @@
+/*
+ * Copyright (C) 2014-2016 Linaro Ltd. <ard.biesheuvel at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/elf.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/sort.h>
+
+struct plt_entry {
+	/*
+	 * A program that conforms to the AArch64 Procedure Call Standard
+	 * (AAPCS64) must assume that a veneer that alters IP0 (x16) and/or
+	 * IP1 (x17) may be inserted at any branch instruction that is
+	 * exposed to a relocation that supports long branches. Since that
+	 * is exactly what we are dealing with here, we are free to use x16
+	 * as a scratch register in the PLT veneers.
+	 */
+	__le32	mov0;	/* movn	x16, #0x....			*/
+	__le32	mov1;	/* movk	x16, #0x...., lsl #16		*/
+	__le32	mov2;	/* movk	x16, #0x...., lsl #32		*/
+	__le32	br;	/* br	x16				*/
+};
+
+u64 module_emit_plt_entry(struct module *mod, const Elf64_Rela *rela,
+			  Elf64_Sym *sym)
+{
+	struct plt_entry *plt = (struct plt_entry *)mod->arch.plt->sh_addr;
+	int i = mod->arch.plt_num_entries;
+	u64 val = sym->st_value + rela->r_addend;
+
+	/*
+	 * We only emit PLT entries against undefined (SHN_UNDEF) symbols,
+	 * which are listed in the ELF symtab section, but without a type
+	 * or a size.
+	 * So, similar to how the module loader uses the Elf64_Sym::st_value
+	 * field to store the resolved addresses of undefined symbols, let's
+	 * borrow the Elf64_Sym::st_size field (whose value is never used by
+	 * the module loader, even for symbols that are defined) to record
+	 * the address of a symbol's associated PLT entry as we emit it for a
+	 * zero addend relocation (which is the only kind we have to deal with
+	 * in practice). This allows us to find duplicates without having to
+	 * go through the table every time.
+	 */
+	if (rela->r_addend == 0 && sym->st_size != 0) {
+		BUG_ON(sym->st_size < (u64)plt || sym->st_size >= (u64)&plt[i]);
+		return sym->st_size;
+	}
+
+	mod->arch.plt_num_entries++;
+	BUG_ON(mod->arch.plt_num_entries > mod->arch.plt_max_entries);
+
+	/*
+	 * MOVK/MOVN/MOVZ opcode:
+	 * +--------+------------+--------+-----------+-------------+---------+
+	 * | sf[31] | opc[30:29] | 100101 | hw[22:21] | imm16[20:5] | Rd[4:0] |
+	 * +--------+------------+--------+-----------+-------------+---------+
+	 *
+	 * Rd     := 0x10 (x16)
+	 * hw     := 0b00 (no shift), 0b01 (lsl #16), 0b10 (lsl #32)
+	 * opc    := 0b11 (MOVK), 0b00 (MOVN), 0b10 (MOVZ)
+	 * sf     := 1 (64-bit variant)
+	 */
+	plt[i] = (struct plt_entry){
+		cpu_to_le32(0x92800010 | (((~val      ) & 0xffff)) << 5),
+		cpu_to_le32(0xf2a00010 | ((( val >> 16) & 0xffff)) << 5),
+		cpu_to_le32(0xf2c00010 | ((( val >> 32) & 0xffff)) << 5),
+		cpu_to_le32(0xd61f0200)
+	};
+
+	if (rela->r_addend == 0)
+		sym->st_size = (u64)&plt[i];
+
+	return (u64)&plt[i];
+}
+
+#define cmp_3way(a,b)	((a) < (b) ? -1 : (a) > (b))
+
+static int cmp_rela(const void *a, const void *b)
+{
+	const Elf64_Rela *x = a, *y = b;
+	int i;
+
+	/* sort by type, symbol index and addend */
+	i = cmp_3way(ELF64_R_TYPE(x->r_info), ELF64_R_TYPE(y->r_info));
+	if (i == 0)
+		i = cmp_3way(ELF64_R_SYM(x->r_info), ELF64_R_SYM(y->r_info));
+	if (i == 0)
+		i = cmp_3way(x->r_addend, y->r_addend);
+	return i;
+}
+
+static bool duplicate_rel(const Elf64_Rela *rela, int num)
+{
+	/*
+	 * Entries are sorted by type, symbol index and addend. That means
+	 * that, if a duplicate entry exists, it must be in the preceding
+	 * slot.
+	 */
+	return num > 0 && cmp_rela(rela + num, rela + num - 1) == 0;
+}
+
+static unsigned int count_plts(Elf64_Sym *syms, Elf64_Rela *rela, int num)
+{
+	unsigned int ret = 0;
+	Elf64_Sym *s;
+	int i;
+
+	for (i = 0; i < num; i++) {
+		switch (ELF64_R_TYPE(rela[i].r_info)) {
+		case R_AARCH64_JUMP26:
+		case R_AARCH64_CALL26:
+			/*
+			 * We only have to consider branch targets that resolve
+			 * to undefined symbols. This is not simply a heuristic,
+			 * it is a fundamental limitation, since the PLT itself
+			 * is part of the module, and needs to be within 128 MB
+			 * as well, so modules can never grow beyond that limit.
+			 */
+			s = syms + ELF64_R_SYM(rela[i].r_info);
+			if (s->st_shndx != SHN_UNDEF)
+				break;
+
+			/*
+			 * Jump relocations with non-zero addends against
+			 * undefined symbols are supported by the ELF spec, but
+			 * do not occur in practice (e.g., 'jump n bytes past
+			 * the entry point of undefined function symbol f').
+			 * So we need to support them, but there is no need to
+			 * take them into consideration when trying to optimize
+			 * this code. So let's only check for duplicates when
+			 * the addend is zero: this allows us to record the PLT
+			 * entry address in the symbol table itself, rather than
+			 * having to search the list for duplicates each time we
+			 * emit one.
+			 */
+			if (rela[i].r_addend != 0 || !duplicate_rel(rela, i))
+				ret++;
+			break;
+		}
+	}
+	return ret;
+}
+
+int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
+			      char *secstrings, struct module *mod)
+{
+	unsigned long plt_max_entries = 0;
+	Elf64_Sym *syms = NULL;
+	int i;
+
+	/*
+	 * Find the empty .plt section so we can expand it to store the PLT
+	 * entries. Record the symtab address as well.
+	 */
+	for (i = 0; i < ehdr->e_shnum; i++) {
+		if (strcmp(".plt", secstrings + sechdrs[i].sh_name) == 0)
+			mod->arch.plt = sechdrs + i;
+		else if (sechdrs[i].sh_type == SHT_SYMTAB)
+			syms = (Elf64_Sym *)sechdrs[i].sh_addr;
+	}
+
+	if (!mod->arch.plt) {
+		pr_err("%s: module PLT section missing\n", mod->name);
+		return -ENOEXEC;
+	}
+	if (!syms) {
+		pr_err("%s: module symtab section missing\n", mod->name);
+		return -ENOEXEC;
+	}
+
+	for (i = 0; i < ehdr->e_shnum; i++) {
+		Elf64_Rela *rels = (void *)ehdr + sechdrs[i].sh_offset;
+		int numrels = sechdrs[i].sh_size / sizeof(Elf64_Rela);
+		Elf64_Shdr *dstsec = sechdrs + sechdrs[i].sh_info;
+
+		if (sechdrs[i].sh_type != SHT_RELA)
+			continue;
+
+		/* ignore relocations that operate on non-exec sections */
+		if (!(dstsec->sh_flags & SHF_EXECINSTR))
+			continue;
+
+		/* sort by type, symbol index and addend */
+		sort(rels, numrels, sizeof(Elf64_Rela), cmp_rela, NULL);
+
+		plt_max_entries += count_plts(syms, rels, numrels);
+	}
+
+	mod->arch.plt->sh_type = SHT_NOBITS;
+	mod->arch.plt->sh_flags = SHF_EXECINSTR | SHF_ALLOC;
+	mod->arch.plt->sh_addralign = L1_CACHE_BYTES;
+	mod->arch.plt->sh_size = plt_max_entries * sizeof(struct plt_entry);
+	mod->arch.plt_num_entries = 0;
+	mod->arch.plt_max_entries = plt_max_entries;
+	return 0;
+}
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 93e970231ca9..84113d3e1df1 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -38,6 +38,11 @@ void *module_alloc(unsigned long size)
 				GFP_KERNEL, PAGE_KERNEL_EXEC, 0,
 				NUMA_NO_NODE, __builtin_return_address(0));
 
+	if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS))
+		p = __vmalloc_node_range(size, MODULE_ALIGN, VMALLOC_START,
+				VMALLOC_END, GFP_KERNEL, PAGE_KERNEL_EXEC, 0,
+				NUMA_NO_NODE, __builtin_return_address(0));
+
 	if (p && (kasan_module_alloc(p, size) < 0)) {
 		vfree(p);
 		return NULL;
@@ -361,6 +366,13 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
 		case R_AARCH64_CALL26:
 			ovf = reloc_insn_imm(RELOC_OP_PREL, loc, val, 2, 26,
 					     AARCH64_INSN_IMM_26);
+
+			if (IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
+			    ovf == -ERANGE) {
+				val = module_emit_plt_entry(me, &rel[i], sym);
+				ovf = reloc_insn_imm(RELOC_OP_PREL, loc, val, 2,
+						     26, AARCH64_INSN_IMM_26);
+			}
 			break;
 
 		default:
diff --git a/arch/arm64/kernel/module.lds b/arch/arm64/kernel/module.lds
new file mode 100644
index 000000000000..8949f6c6f729
--- /dev/null
+++ b/arch/arm64/kernel/module.lds
@@ -0,0 +1,3 @@
+SECTIONS {
+	.plt (NOLOAD) : { BYTE(0) }
+}
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 05:09:34 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 14:09:34 +0100
Subject: [PATCH v5sub2 4/8] arm64: make asm/elf.h available to asm files
In-Reply-To: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454332178-4414-5-git-send-email-ard.biesheuvel@linaro.org>

This reshuffles some code in asm/elf.h and puts a #ifndef __ASSEMBLY__
around its C definitions so that the CPP defines can be used in asm
source files as well.

Acked-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/elf.h | 22 ++++++++++++--------
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index faad6df49e5b..435f55952e1f 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -24,15 +24,6 @@
 #include <asm/ptrace.h>
 #include <asm/user.h>
 
-typedef unsigned long elf_greg_t;
-
-#define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))
-#define ELF_CORE_COPY_REGS(dest, regs)	\
-	*(struct user_pt_regs *)&(dest) = (regs)->user_regs;
-
-typedef elf_greg_t elf_gregset_t[ELF_NGREG];
-typedef struct user_fpsimd_state elf_fpregset_t;
-
 /*
  * AArch64 static relocation types.
  */
@@ -127,6 +118,17 @@ typedef struct user_fpsimd_state elf_fpregset_t;
  */
 #define ELF_ET_DYN_BASE	(2 * TASK_SIZE_64 / 3)
 
+#ifndef __ASSEMBLY__
+
+typedef unsigned long elf_greg_t;
+
+#define ELF_NGREG (sizeof(struct user_pt_regs) / sizeof(elf_greg_t))
+#define ELF_CORE_COPY_REGS(dest, regs)	\
+	*(struct user_pt_regs *)&(dest) = (regs)->user_regs;
+
+typedef elf_greg_t elf_gregset_t[ELF_NGREG];
+typedef struct user_fpsimd_state elf_fpregset_t;
+
 /*
  * When the program starts, a1 contains a pointer to a function to be
  * registered with atexit, as per the SVR4 ABI.  A value of 0 means we have no
@@ -186,4 +188,6 @@ extern int aarch32_setup_vectors_page(struct linux_binprm *bprm,
 
 #endif /* CONFIG_COMPAT */
 
+#endif /* !__ASSEMBLY__ */
+
 #endif
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 05:09:33 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 14:09:33 +0100
Subject: [PATCH v5sub2 3/8] arm64: avoid dynamic relocations in early boot code
In-Reply-To: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454332178-4414-4-git-send-email-ard.biesheuvel@linaro.org>

Before implementing KASLR for arm64 by building a self-relocating PIE
executable, we have to ensure that values we use before the relocation
routine is executed are not subject to dynamic relocation themselves.
This applies not only to virtual addresses, but also to values that are
supplied by the linker at build time and relocated using R_AARCH64_ABS64
relocations.

So instead, use assemble time constants, or force the use of static
relocations by folding the constants into the instructions.

Reviewed-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/kernel/efi-entry.S |  2 +-
 arch/arm64/kernel/head.S      | 39 +++++++++++++-------
 2 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
index a773db92908b..f82036e02485 100644
--- a/arch/arm64/kernel/efi-entry.S
+++ b/arch/arm64/kernel/efi-entry.S
@@ -61,7 +61,7 @@ ENTRY(entry)
 	 */
 	mov	x20, x0		// DTB address
 	ldr	x0, [sp, #16]	// relocated _text address
-	ldr	x21, =stext_offset
+	movz	x21, #:abs_g0:stext_offset
 	add	x21, x0, x21
 
 	/*
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index f076debf392d..4cad8f9f2268 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -67,12 +67,11 @@
  * in the entry routines.
  */
 	__HEAD
-
+_head:
 	/*
 	 * DO NOT MODIFY. Image header expected by Linux boot-loaders.
 	 */
 #ifdef CONFIG_EFI
-efi_head:
 	/*
 	 * This add instruction has no meaningful effect except that
 	 * its opcode forms the magic "MZ" signature required by UEFI.
@@ -94,14 +93,14 @@ efi_head:
 	.byte	0x4d
 	.byte	0x64
 #ifdef CONFIG_EFI
-	.long	pe_header - efi_head		// Offset to the PE header.
+	.long	pe_header - _head		// Offset to the PE header.
 #else
 	.word	0				// reserved
 #endif
 
 #ifdef CONFIG_EFI
 	.globl	__efistub_stext_offset
-	.set	__efistub_stext_offset, stext - efi_head
+	.set	__efistub_stext_offset, stext - _head
 	.align 3
 pe_header:
 	.ascii	"PE"
@@ -124,7 +123,7 @@ optional_header:
 	.long	_end - stext			// SizeOfCode
 	.long	0				// SizeOfInitializedData
 	.long	0				// SizeOfUninitializedData
-	.long	__efistub_entry - efi_head	// AddressOfEntryPoint
+	.long	__efistub_entry - _head		// AddressOfEntryPoint
 	.long	__efistub_stext_offset		// BaseOfCode
 
 extra_header_fields:
@@ -139,7 +138,7 @@ extra_header_fields:
 	.short	0				// MinorSubsystemVersion
 	.long	0				// Win32VersionValue
 
-	.long	_end - efi_head			// SizeOfImage
+	.long	_end - _head			// SizeOfImage
 
 	// Everything before the kernel image is considered part of the header
 	.long	__efistub_stext_offset		// SizeOfHeaders
@@ -219,11 +218,13 @@ ENTRY(stext)
 	 * On return, the CPU will be ready for the MMU to be turned on and
 	 * the TCR will have been set.
 	 */
-	ldr	x27, =__mmap_switched		// address to jump to after
+	ldr	x27, 0f				// address to jump to after
 						// MMU has been enabled
 	adr_l	lr, __enable_mmu		// return (PIC) address
 	b	__cpu_setup			// initialise processor
 ENDPROC(stext)
+	.align	3
+0:	.quad	__mmap_switched - (_head - TEXT_OFFSET) + KIMAGE_VADDR
 
 /*
  * Preserve the arguments passed by the bootloader in x0 .. x3
@@ -391,7 +392,8 @@ __create_page_tables:
 	mov	x0, x26				// swapper_pg_dir
 	ldr	x5, =KIMAGE_VADDR
 	create_pgd_entry x0, x5, x3, x6
-	ldr	x6, =KERNEL_END			// __va(KERNEL_END)
+	ldr	w6, kernel_img_size
+	add	x6, x6, x5
 	mov	x3, x24				// phys offset
 	create_block_map x0, x7, x3, x5, x6
 
@@ -408,6 +410,9 @@ __create_page_tables:
 	mov	lr, x27
 	ret
 ENDPROC(__create_page_tables)
+
+kernel_img_size:
+	.long	_end - (_head - TEXT_OFFSET)
 	.ltorg
 
 /*
@@ -415,6 +420,10 @@ ENDPROC(__create_page_tables)
  */
 	.set	initial_sp, init_thread_union + THREAD_START_SP
 __mmap_switched:
+	adr_l	x8, vectors			// load VBAR_EL1 with virtual
+	msr	vbar_el1, x8			// vector table address
+	isb
+
 	// Clear BSS
 	adr_l	x0, __bss_start
 	mov	x1, xzr
@@ -610,13 +619,19 @@ ENTRY(secondary_startup)
 	adrp	x26, swapper_pg_dir
 	bl	__cpu_setup			// initialise processor
 
-	ldr	x21, =secondary_data
-	ldr	x27, =__secondary_switched	// address to jump to after enabling the MMU
+	ldr	x8, =KIMAGE_VADDR
+	ldr	w9, 0f
+	sub	x27, x8, w9, sxtw		// address to jump to after enabling the MMU
 	b	__enable_mmu
 ENDPROC(secondary_startup)
+0:	.long	(_text - TEXT_OFFSET) - __secondary_switched
 
 ENTRY(__secondary_switched)
-	ldr	x0, [x21]			// get secondary_data.stack
+	adr_l	x5, vectors
+	msr	vbar_el1, x5
+	isb
+
+	ldr_l	x0, secondary_data		// get secondary_data.stack
 	mov	sp, x0
 	and	x0, x0, #~(THREAD_SIZE - 1)
 	msr	sp_el0, x0			// save thread_info
@@ -641,8 +656,6 @@ __enable_mmu:
 	ubfx	x2, x1, #ID_AA64MMFR0_TGRAN_SHIFT, 4
 	cmp	x2, #ID_AA64MMFR0_TGRAN_SUPPORTED
 	b.ne	__no_granule_support
-	ldr	x5, =vectors
-	msr	vbar_el1, x5
 	msr	ttbr0_el1, x25			// load TTBR0
 	msr	ttbr1_el1, x26			// load TTBR1
 	isb
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 05:09:35 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 14:09:35 +0100
Subject: [PATCH v5sub2 5/8] scripts/sortextable: add support for ET_DYN
 binaries
In-Reply-To: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454332178-4414-6-git-send-email-ard.biesheuvel@linaro.org>

Add support to scripts/sortextable for handling relocatable (PIE)
executables, whose ELF type is ET_DYN, not ET_EXEC. Other than adding
support for the new type, no changes are needed.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 scripts/sortextable.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/sortextable.c b/scripts/sortextable.c
index af247c70fb66..19d83647846c 100644
--- a/scripts/sortextable.c
+++ b/scripts/sortextable.c
@@ -266,9 +266,9 @@ do_file(char const *const fname)
 		break;
 	}  /* end switch */
 	if (memcmp(ELFMAG, ehdr->e_ident, SELFMAG) != 0
-	||  r2(&ehdr->e_type) != ET_EXEC
+	||  (r2(&ehdr->e_type) != ET_EXEC && r2(&ehdr->e_type) != ET_DYN)
 	||  ehdr->e_ident[EI_VERSION] != EV_CURRENT) {
-		fprintf(stderr, "unrecognized ET_EXEC file %s\n", fname);
+		fprintf(stderr, "unrecognized ET_EXEC/ET_DYN file %s\n", fname);
 		fail_file();
 	}
 
@@ -304,7 +304,7 @@ do_file(char const *const fname)
 		if (r2(&ehdr->e_ehsize) != sizeof(Elf32_Ehdr)
 		||  r2(&ehdr->e_shentsize) != sizeof(Elf32_Shdr)) {
 			fprintf(stderr,
-				"unrecognized ET_EXEC file: %s\n", fname);
+				"unrecognized ET_EXEC/ET_DYN file: %s\n", fname);
 			fail_file();
 		}
 		do32(ehdr, fname, custom_sort);
@@ -314,7 +314,7 @@ do_file(char const *const fname)
 		if (r2(&ghdr->e_ehsize) != sizeof(Elf64_Ehdr)
 		||  r2(&ghdr->e_shentsize) != sizeof(Elf64_Shdr)) {
 			fprintf(stderr,
-				"unrecognized ET_EXEC file: %s\n", fname);
+				"unrecognized ET_EXEC/ET_DYN file: %s\n", fname);
 			fail_file();
 		}
 		do64(ghdr, fname, custom_sort);
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 05:09:36 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 14:09:36 +0100
Subject: [PATCH v5sub2 6/8] arm64: add support for building vmlinux as a
 relocatable PIE binary
In-Reply-To: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454332178-4414-7-git-send-email-ard.biesheuvel@linaro.org>

This implements CONFIG_RELOCATABLE, which links the final vmlinux
image with a dynamic relocation section, allowing the early boot code
to perform a relocation to a different virtual address at runtime.

This is a prerequisite for KASLR (CONFIG_RANDOMIZE_BASE).

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/Kconfig              | 11 +++++++
 arch/arm64/Makefile             |  4 +++
 arch/arm64/include/asm/elf.h    |  2 ++
 arch/arm64/kernel/head.S        | 32 ++++++++++++++++++++
 arch/arm64/kernel/vmlinux.lds.S | 16 ++++++++++
 5 files changed, 65 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 141f65ab0ed5..5e155cc7b49f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -762,6 +762,17 @@ config ARM64_MODULE_PLTS
 	select ARM64_MODULE_CMODEL_LARGE
 	select HAVE_MOD_ARCH_SPECIFIC
 
+config RELOCATABLE
+	bool
+	help
+	  This builds the kernel as a Position Independent Executable (PIE),
+	  which retains all relocation metadata required to relocate the
+	  kernel binary at runtime to a different virtual address than the
+	  address it was linked at.
+	  Since AArch64 uses the RELA relocation format, this requires a
+	  relocation pass at runtime even if the kernel is loaded at the
+	  same address it was linked at.
+
 endmenu
 
 menu "Boot options"
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index a6bba9623836..6b5508a17495 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -15,6 +15,10 @@ CPPFLAGS_vmlinux.lds = -DTEXT_OFFSET=$(TEXT_OFFSET)
 OBJCOPYFLAGS	:=-O binary -R .note -R .note.gnu.build-id -R .comment -S
 GZFLAGS		:=-9
 
+ifneq ($(CONFIG_RELOCATABLE),)
+LDFLAGS_vmlinux		+= -pie
+endif
+
 KBUILD_DEFCONFIG := defconfig
 
 # Check for binutils support for specific extensions
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 435f55952e1f..24ed037f09fd 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -77,6 +77,8 @@
 #define R_AARCH64_MOVW_PREL_G2_NC	292
 #define R_AARCH64_MOVW_PREL_G3		293
 
+#define R_AARCH64_RELATIVE		1027
+
 /*
  * These are used to set parameters in the core dumps.
  */
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 4cad8f9f2268..4e69412a7323 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -29,6 +29,7 @@
 #include <asm/asm-offsets.h>
 #include <asm/cache.h>
 #include <asm/cputype.h>
+#include <asm/elf.h>
 #include <asm/kernel-pgtable.h>
 #include <asm/memory.h>
 #include <asm/pgtable-hwdef.h>
@@ -432,6 +433,37 @@ __mmap_switched:
 	bl	__pi_memset
 	dsb	ishst				// Make zero page visible to PTW
 
+#ifdef CONFIG_RELOCATABLE
+
+	/*
+	 * Iterate over each entry in the relocation table, and apply the
+	 * relocations in place.
+	 */
+	adr_l	x8, __dynsym_start		// start of symbol table
+	adr_l	x9, __reloc_start		// start of reloc table
+	adr_l	x10, __reloc_end		// end of reloc table
+
+0:	cmp	x9, x10
+	b.hs	2f
+	ldp	x11, x12, [x9], #24
+	ldr	x13, [x9, #-8]
+	cmp	w12, #R_AARCH64_RELATIVE
+	b.ne	1f
+	str	x13, [x11]
+	b	0b
+
+1:	cmp	w12, #R_AARCH64_ABS64
+	b.ne	0b
+	add	x12, x12, x12, lsl #1		// symtab offset: 24x top word
+	add	x12, x8, x12, lsr #(32 - 3)	// ... shifted into bottom word
+	ldr	x15, [x12, #8]			// Elf64_Sym::st_value
+	add	x15, x13, x15
+	str	x15, [x11]
+	b	0b
+
+2:
+#endif
+
 	adr_l	sp, initial_sp, x4
 	mov	x4, sp
 	and	x4, x4, #~(THREAD_SIZE - 1)
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 282e3e64a17e..e3f6cd740ea3 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -87,6 +87,7 @@ SECTIONS
 		EXIT_CALL
 		*(.discard)
 		*(.discard.*)
+		*(.interp .dynamic)
 	}
 
 	. = KIMAGE_VADDR + TEXT_OFFSET;
@@ -149,6 +150,21 @@ SECTIONS
 	.altinstr_replacement : {
 		*(.altinstr_replacement)
 	}
+	.rela : ALIGN(8) {
+		__reloc_start = .;
+		*(.rela .rela*)
+		__reloc_end = .;
+	}
+	.dynsym : ALIGN(8) {
+		__dynsym_start = .;
+		*(.dynsym)
+	}
+	.dynstr : {
+		*(.dynstr)
+	}
+	.hash : {
+		*(.hash)
+	}
 
 	. = ALIGN(PAGE_SIZE);
 	__init_end = .;
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 05:09:38 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 14:09:38 +0100
Subject: [PATCH v5sub2 8/8] arm64: kaslr: randomize the linear region
In-Reply-To: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454332178-4414-9-git-send-email-ard.biesheuvel@linaro.org>

When KASLR is enabled (CONFIG_RANDOMIZE_BASE=y), and entropy has been
provided by the bootloader, randomize the placement of RAM inside the
linear region if sufficient space is available. For instance, on a 4KB
granule/3 levels kernel, the linear region is 256 GB in size, and we can
choose any 1 GB aligned offset that is far enough from the top of the
address space to fit the distance between the start of the lowest memblock
and the top of the highest memblock.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/kernel/kaslr.c |  4 ++++
 arch/arm64/mm/init.c      | 22 ++++++++++++++++++--
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index b0bf628ba51f..c96f63670537 100644
--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@ -21,6 +21,7 @@
 #include <asm/sections.h>
 
 u32 __read_mostly module_load_offset;
+u16 __initdata memstart_offset_seed;
 
 static __init u64 get_kaslr_seed(void *fdt)
 {
@@ -135,5 +136,8 @@ u64 __init kaslr_early_init(u64 dt_phys)
 	module_range = MODULES_VSIZE - (u64)(_etext - _stext);
 	module_load_offset = ((module_range * (u16)seed) >> 16) & PAGE_MASK;
 
+	/* use the top 16 bits to randomize the linear region */
+	memstart_offset_seed = seed >> 48;
+
 	return offset;
 }
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index e8e853a1024c..01fdb3d04bba 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -215,6 +215,23 @@ void __init arm64_memblock_init(void)
 	if (memblock_end_of_DRAM() > linear_region_size)
 		memblock_remove(0, memblock_end_of_DRAM() - linear_region_size);
 
+	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
+		extern u16 memstart_offset_seed;
+		u64 range = linear_region_size -
+			    (memblock_end_of_DRAM() - memblock_start_of_DRAM());
+
+		/*
+		 * If the size of the linear region exceeds, by a sufficient
+		 * margin, the size of the region that the available physical
+		 * memory spans, randomize the linear region as well.
+		 */
+		if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
+			range = range / ARM64_MEMSTART_ALIGN + 1;
+			memstart_addr -= ARM64_MEMSTART_ALIGN *
+					 ((range * memstart_offset_seed) >> 16);
+		}
+	}
+
 	if (memory_limit != (phys_addr_t)ULLONG_MAX) {
 		u64 kbase = round_down(__pa(_text), MIN_KIMG_ALIGN);
 		u64 kend = PAGE_ALIGN(__pa(_end));
@@ -399,12 +416,13 @@ void __init mem_init(void)
 #ifdef CONFIG_SPARSEMEM_VMEMMAP
 		  MLG((unsigned long)vmemmap,
 		      (unsigned long)vmemmap + VMEMMAP_SIZE),
-		  MLM((unsigned long)virt_to_page(PAGE_OFFSET),
+		  MLM((unsigned long)phys_to_page(memblock_start_of_DRAM()),
 		      (unsigned long)virt_to_page(high_memory)),
 #endif
 		  MLK(FIXADDR_START, FIXADDR_TOP),
 		  MLM(PCI_IO_START, PCI_IO_END),
-		  MLM(PAGE_OFFSET, (unsigned long)high_memory));
+		  MLM(__phys_to_virt(memblock_start_of_DRAM()),
+		      (unsigned long)high_memory));
 
 #undef MLK
 #undef MLM
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 05:09:37 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 14:09:37 +0100
Subject: [PATCH v5sub2 7/8] arm64: add support for kernel ASLR
In-Reply-To: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454332178-4414-8-git-send-email-ard.biesheuvel@linaro.org>

This adds support for KASLR is implemented, based on entropy provided by
the bootloader in the /chosen/kaslr-seed DT property. Depending on the size
of the address space (VA_BITS) and the page size, the entropy in the
virtual displacement is up to 13 bits (16k/2 levels) and up to 25 bits (all
4 levels), with the sidenote that displacements that result in the kernel
image straddling a 1GB/32MB/512MB alignment boundary (for 4KB/16KB/64KB
granule kernels, respectively) are not allowed, and will be rounded up to
an acceptable value.

The module region is randomized by choosing a page aligned 128 MB region
inside the interval [_etext - 128 MB, _stext + 128 MB). This gives between
10 and 14 bits of entropy (depending on page size), independently of the
kernel randomization, but still guarantees that modules are within the
range of relative branch and jump instructions (with the caveat that, since
the module region is shared with other uses of the vmalloc area, modules
may need to be loaded further away if the module region is exhausted)

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/Kconfig              |  14 ++
 arch/arm64/include/asm/memory.h |   5 +-
 arch/arm64/kernel/Makefile      |   1 +
 arch/arm64/kernel/head.S        |  59 +++++++--
 arch/arm64/kernel/kaslr.c       | 139 ++++++++++++++++++++
 arch/arm64/kernel/module.c      |   8 +-
 arch/arm64/kernel/setup.c       |  29 ++++
 arch/arm64/mm/mmu.c             |  33 +++--
 8 files changed, 268 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 5e155cc7b49f..e3049d5c1246 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -773,6 +773,20 @@ config RELOCATABLE
 	  relocation pass at runtime even if the kernel is loaded at the
 	  same address it was linked at.
 
+config RANDOMIZE_BASE
+	bool "Randomize the address of the kernel image"
+	select ARM64_MODULE_PLTS
+	select RELOCATABLE
+	help
+	  Randomizes the virtual address at which the kernel image is
+	  loaded, as a security feature that deters exploit attempts
+	  relying on knowledge of the location of kernel internals.
+
+	  It is the bootloader's job to provide entropy, by passing a
+	  random u64 value in /chosen/kaslr-seed at kernel entry.
+
+	  If unsure, say N.
+
 endmenu
 
 menu "Boot options"
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 61005e7dd6cb..083361531a61 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -52,7 +52,7 @@
 #define KIMAGE_VADDR		(MODULES_END)
 #define MODULES_END		(MODULES_VADDR + MODULES_VSIZE)
 #define MODULES_VADDR		(VA_START + KASAN_SHADOW_SIZE)
-#define MODULES_VSIZE		(SZ_64M)
+#define MODULES_VSIZE		(SZ_128M)
 #define PCI_IO_END		(PAGE_OFFSET - SZ_2M)
 #define PCI_IO_START		(PCI_IO_END - PCI_IO_SIZE)
 #define FIXADDR_TOP		(PCI_IO_START - SZ_2M)
@@ -127,6 +127,9 @@ extern phys_addr_t		memstart_addr;
 /* PHYS_OFFSET - the physical address of the start of memory. */
 #define PHYS_OFFSET		({ memstart_addr; })
 
+/* the virtual base of the kernel image (minus TEXT_OFFSET) */
+extern u64			kimage_vaddr;
+
 /* the offset between the kernel virtual and physical mappings */
 extern u64			kimage_voffset;
 
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index e2f0a755beaa..c9aaecddb941 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -43,6 +43,7 @@ arm64-obj-$(CONFIG_PCI)			+= pci.o
 arm64-obj-$(CONFIG_ARMV8_DEPRECATED)	+= armv8_deprecated.o
 arm64-obj-$(CONFIG_ACPI)		+= acpi.o
 arm64-obj-$(CONFIG_PARAVIRT)		+= paravirt.o
+arm64-obj-$(CONFIG_RANDOMIZE_BASE)	+= kaslr.o
 
 obj-y					+= $(arm64-obj-y) vdso/
 obj-m					+= $(arm64-obj-m)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 4e69412a7323..319f896c6e74 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -210,6 +210,7 @@ section_table:
 ENTRY(stext)
 	bl	preserve_boot_args
 	bl	el2_setup			// Drop to EL1, w20=cpu_boot_mode
+	mov	x23, xzr			// KASLR offset, defaults to 0
 	adrp	x24, __PHYS_OFFSET
 	bl	set_cpu_boot_mode_flag
 	bl	__create_page_tables		// x25=TTBR0, x26=TTBR1
@@ -313,7 +314,7 @@ ENDPROC(preserve_boot_args)
 __create_page_tables:
 	adrp	x25, idmap_pg_dir
 	adrp	x26, swapper_pg_dir
-	mov	x27, lr
+	mov	x28, lr
 
 	/*
 	 * Invalidate the idmap and swapper page tables to avoid potential
@@ -392,6 +393,7 @@ __create_page_tables:
 	 */
 	mov	x0, x26				// swapper_pg_dir
 	ldr	x5, =KIMAGE_VADDR
+	add	x5, x5, x23			// add KASLR displacement
 	create_pgd_entry x0, x5, x3, x6
 	ldr	w6, kernel_img_size
 	add	x6, x6, x5
@@ -408,8 +410,7 @@ __create_page_tables:
 	dmb	sy
 	bl	__inval_cache_range
 
-	mov	lr, x27
-	ret
+	ret	x28
 ENDPROC(__create_page_tables)
 
 kernel_img_size:
@@ -421,6 +422,7 @@ kernel_img_size:
  */
 	.set	initial_sp, init_thread_union + THREAD_START_SP
 __mmap_switched:
+	mov	x28, lr				// preserve LR
 	adr_l	x8, vectors			// load VBAR_EL1 with virtual
 	msr	vbar_el1, x8			// vector table address
 	isb
@@ -449,19 +451,26 @@ __mmap_switched:
 	ldr	x13, [x9, #-8]
 	cmp	w12, #R_AARCH64_RELATIVE
 	b.ne	1f
-	str	x13, [x11]
+	add	x13, x13, x23			// relocate
+	str	x13, [x11, x23]
 	b	0b
 
 1:	cmp	w12, #R_AARCH64_ABS64
 	b.ne	0b
 	add	x12, x12, x12, lsl #1		// symtab offset: 24x top word
 	add	x12, x8, x12, lsr #(32 - 3)	// ... shifted into bottom word
+	ldrsh	w14, [x12, #6]			// Elf64_Sym::st_shndx
 	ldr	x15, [x12, #8]			// Elf64_Sym::st_value
+	cmp	w14, #-0xf			// SHN_ABS (0xfff1) ?
+	add	x14, x15, x23			// relocate
+	csel	x15, x14, x15, ne
 	add	x15, x13, x15
-	str	x15, [x11]
+	str	x15, [x11, x23]
 	b	0b
 
-2:
+2:	adr_l	x8, kimage_vaddr		// make relocated kimage_vaddr
+	dc	cvac, x8			// value visible to secondaries
+	dsb	sy				// with MMU off
 #endif
 
 	adr_l	sp, initial_sp, x4
@@ -470,7 +479,7 @@ __mmap_switched:
 	msr	sp_el0, x4			// Save thread_info
 	str_l	x21, __fdt_pointer, x5		// Save FDT pointer
 
-	ldr	x4, =KIMAGE_VADDR		// Save the offset between
+	ldr_l	x4, kimage_vaddr		// Save the offset between
 	sub	x4, x4, x24			// the kernel virtual and
 	str_l	x4, kimage_voffset, x5		// physical mappings
 
@@ -478,6 +487,16 @@ __mmap_switched:
 #ifdef CONFIG_KASAN
 	bl	kasan_early_init
 #endif
+#ifdef CONFIG_RANDOMIZE_BASE
+	cbnz	x23, 0f				// already running randomized?
+	mov	x0, x21				// pass FDT address in x0
+	bl	kaslr_early_init		// parse FDT for KASLR options
+	cbz	x0, 0f				// KASLR disabled? just proceed
+	mov	x23, x0				// record KASLR offset
+	ret	x28				// we must enable KASLR, return
+						// to __enable_mmu()
+0:
+#endif
 	b	start_kernel
 ENDPROC(__mmap_switched)
 
@@ -486,6 +505,10 @@ ENDPROC(__mmap_switched)
  * hotplug and needs to have the same protections as the text region
  */
 	.section ".text","ax"
+
+ENTRY(kimage_vaddr)
+	.quad		_text - TEXT_OFFSET
+
 /*
  * If we're fortunate enough to boot at EL2, ensure that the world is
  * sane before dropping to EL1.
@@ -651,7 +674,7 @@ ENTRY(secondary_startup)
 	adrp	x26, swapper_pg_dir
 	bl	__cpu_setup			// initialise processor
 
-	ldr	x8, =KIMAGE_VADDR
+	ldr	x8, kimage_vaddr
 	ldr	w9, 0f
 	sub	x27, x8, w9, sxtw		// address to jump to after enabling the MMU
 	b	__enable_mmu
@@ -684,6 +707,7 @@ ENDPROC(__secondary_switched)
  */
 	.section	".idmap.text", "ax"
 __enable_mmu:
+	mrs	x18, sctlr_el1			// preserve old SCTLR_EL1 value
 	mrs	x1, ID_AA64MMFR0_EL1
 	ubfx	x2, x1, #ID_AA64MMFR0_TGRAN_SHIFT, 4
 	cmp	x2, #ID_AA64MMFR0_TGRAN_SUPPORTED
@@ -701,6 +725,25 @@ __enable_mmu:
 	ic	iallu
 	dsb	nsh
 	isb
+#ifdef CONFIG_RANDOMIZE_BASE
+	mov	x19, x0				// preserve new SCTLR_EL1 value
+	blr	x27
+
+	/*
+	 * If we return here, we have a KASLR displacement in x23 which we need
+	 * to take into account by discarding the current kernel mapping and
+	 * creating a new one.
+	 */
+	msr	sctlr_el1, x18			// disable the MMU
+	isb
+	bl	__create_page_tables		// recreate kernel mapping
+
+	msr	sctlr_el1, x19			// re-enable the MMU
+	isb
+	ic	ialluis				// flush instructions fetched
+	isb					// via old mapping
+	add	x27, x27, x23			// relocated __mmap_switched
+#endif
 	br	x27
 ENDPROC(__enable_mmu)
 
diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
new file mode 100644
index 000000000000..b0bf628ba51f
--- /dev/null
+++ b/arch/arm64/kernel/kaslr.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright (C) 2016 Linaro Ltd <ard.biesheuvel at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/crc32.h>
+#include <linux/init.h>
+#include <linux/libfdt.h>
+#include <linux/mm_types.h>
+#include <linux/sched.h>
+#include <linux/types.h>
+
+#include <asm/fixmap.h>
+#include <asm/kernel-pgtable.h>
+#include <asm/memory.h>
+#include <asm/mmu.h>
+#include <asm/pgtable.h>
+#include <asm/sections.h>
+
+u32 __read_mostly module_load_offset;
+
+static __init u64 get_kaslr_seed(void *fdt)
+{
+	int node, len;
+	u64 *prop;
+	u64 ret;
+
+	node = fdt_path_offset(fdt, "/chosen");
+	if (node < 0)
+		return 0;
+
+	prop = fdt_getprop_w(fdt, node, "kaslr-seed", &len);
+	if (!prop || len != sizeof(u64))
+		return 0;
+
+	ret = fdt64_to_cpu(*prop);
+	*prop = 0;
+	return ret;
+}
+
+static __init const u8 *get_cmdline(void *fdt)
+{
+	static __initconst const u8 default_cmdline[] = CONFIG_CMDLINE;
+
+	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
+		int node;
+		const u8 *prop;
+
+		node = fdt_path_offset(fdt, "/chosen");
+		if (node < 0)
+			goto out;
+
+		prop = fdt_getprop(fdt, node, "bootargs", NULL);
+		if (!prop)
+			goto out;
+		return prop;
+	}
+out:
+	return default_cmdline;
+}
+
+extern void *__init __fixmap_remap_fdt(phys_addr_t dt_phys, int *size,
+				       pgprot_t prot);
+
+/*
+ * This routine will be executed with the kernel mapped at its default virtual
+ * address, and if it returns successfully, the kernel will be remapped, and
+ * start_kernel() will be executed from a randomized virtual offset. The
+ * relocation will result in all absolute references (e.g., static variables
+ * containing function pointers) to be reinitialized, and zero-initialized
+ * .bss variables will be reset to 0.
+ */
+u64 __init kaslr_early_init(u64 dt_phys)
+{
+	void *fdt;
+	u64 seed, offset, mask, module_range;
+	const u8 *cmdline, *str;
+	int size;
+
+	/*
+	 * Try to map the FDT early. If this fails, we simply bail,
+	 * and proceed with KASLR disabled. We will make another
+	 * attempt at mapping the FDT in setup_machine()
+	 */
+	early_fixmap_init();
+	fdt = __fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL);
+	if (!fdt)
+		return 0;
+
+	/*
+	 * Retrieve (and wipe) the seed from the FDT
+	 */
+	seed = get_kaslr_seed(fdt);
+	if (!seed)
+		return 0;
+
+	/*
+	 * Check if 'nokaslr' appears on the command line, and
+	 * return 0 if that is the case.
+	 */
+	cmdline = get_cmdline(fdt);
+	str = strstr(cmdline, "nokaslr");
+	if (str == cmdline || (str > cmdline && *(str - 1) == ' '))
+		return 0;
+
+	/*
+	 * OK, so we are proceeding with KASLR enabled. Calculate a suitable
+	 * kernel image offset from the seed. Let's place the kernel in the
+	 * lower half of the VMALLOC area (VA_BITS - 2).
+	 * Even if we could randomize at page granularity for 16k and 64k pages,
+	 * let's always round to 2 MB so we don't interfere with the ability to
+	 * map using contiguous PTEs
+	 */
+	mask = ((1UL << (VA_BITS - 2)) - 1) & ~(SZ_2M - 1);
+	offset = seed & mask;
+
+	/*
+	 * The kernel Image should not extend across a 1GB/32MB/512MB alignment
+	 * boundary (for 4KB/16KB/64KB granule kernels, respectively). If this
+	 * happens, increase the KASLR offset by the size of the kernel image.
+	 */
+	if ((((u64)_text + offset) >> SWAPPER_TABLE_SHIFT) !=
+	    (((u64)_end + offset) >> SWAPPER_TABLE_SHIFT))
+		offset = (offset + (u64)(_end - _text)) & mask;
+
+	/*
+	 * Randomize the module region, by setting module_load_offset to
+	 * a PAGE_SIZE multiple in the interval [0, module_range). This
+	 * ensures that the resulting region still covers [_stext, _etext],
+	 * and that all relative branches can be resolved without veneers.
+	 */
+	module_range = MODULES_VSIZE - (u64)(_etext - _stext);
+	module_load_offset = ((module_range * (u16)seed) >> 16) & PAGE_MASK;
+
+	return offset;
+}
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 84113d3e1df1..54702d456680 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -33,8 +33,14 @@
 void *module_alloc(unsigned long size)
 {
 	void *p;
+	u64 base = (u64)_etext - MODULES_VSIZE;
 
-	p = __vmalloc_node_range(size, MODULE_ALIGN, MODULES_VADDR, MODULES_END,
+	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
+		extern u32 module_load_offset;
+		base += module_load_offset;
+	}
+
+	p = __vmalloc_node_range(size, MODULE_ALIGN, base, base + MODULES_VSIZE,
 				GFP_KERNEL, PAGE_KERNEL_EXEC, 0,
 				NUMA_NO_NODE, __builtin_return_address(0));
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index cfed56f0ad26..42371f69def3 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -388,3 +388,32 @@ static int __init topology_init(void)
 	return 0;
 }
 subsys_initcall(topology_init);
+
+/*
+ * Dump out kernel offset information on panic.
+ */
+static int dump_kernel_offset(struct notifier_block *self, unsigned long v,
+			      void *p)
+{
+	u64 const kaslr_offset = kimage_vaddr - KIMAGE_VADDR;
+
+	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && kaslr_offset > 0) {
+		pr_emerg("Kernel Offset: 0x%llx from 0x%lx\n",
+			 kaslr_offset, KIMAGE_VADDR);
+	} else {
+		pr_emerg("Kernel Offset: disabled\n");
+	}
+	return 0;
+}
+
+static struct notifier_block kernel_offset_notifier = {
+	.notifier_call = dump_kernel_offset
+};
+
+static int __init register_kernel_offset_dumper(void)
+{
+	atomic_notifier_chain_register(&panic_notifier_list,
+				       &kernel_offset_notifier);
+	return 0;
+}
+__initcall(register_kernel_offset_dumper);
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 8dda38378959..5d7e0b801ab7 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -636,7 +636,8 @@ void __init early_fixmap_init(void)
 	unsigned long addr = FIXADDR_START;
 
 	pgd = pgd_offset_k(addr);
-	if (CONFIG_PGTABLE_LEVELS > 3 && !pgd_none(*pgd)) {
+	if (CONFIG_PGTABLE_LEVELS > 3 &&
+	    !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa(bm_pud))) {
 		/*
 		 * We only end up here if the kernel mapping and the fixmap
 		 * share the top level pgd entry, which should only happen on
@@ -693,11 +694,10 @@ void __set_fixmap(enum fixed_addresses idx,
 	}
 }
 
-void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
+void *__init __fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
 {
 	const u64 dt_virt_base = __fix_to_virt(FIX_FDT);
-	pgprot_t prot = PAGE_KERNEL_RO;
-	int size, offset;
+	int offset;
 	void *dt_virt;
 
 	/*
@@ -736,16 +736,29 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
 	if (fdt_check_header(dt_virt) != 0)
 		return NULL;
 
-	size = fdt_totalsize(dt_virt);
-	if (size > MAX_FDT_SIZE)
+	*size = fdt_totalsize(dt_virt);
+	if (*size > MAX_FDT_SIZE)
 		return NULL;
 
-	if (offset + size > SWAPPER_BLOCK_SIZE)
-		create_mapping(round_down(dt_phys, SWAPPER_BLOCK_SIZE), dt_virt_base,
-			       round_up(offset + size, SWAPPER_BLOCK_SIZE), prot);
+	if (offset + *size > SWAPPER_BLOCK_SIZE)
+		create_mapping(round_down(dt_phys, SWAPPER_BLOCK_SIZE),
+			       dt_virt_base,
+			       round_up(offset + *size, SWAPPER_BLOCK_SIZE),
+			       prot);
 
-	memblock_reserve(dt_phys, size);
+	return dt_virt;
+}
 
+void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
+{
+	void *dt_virt;
+	int size;
+
+	dt_virt = __fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL_RO);
+	if (!dt_virt)
+		return NULL;
+
+	memblock_reserve(dt_phys, size);
 	return dt_virt;
 }
 
-- 
2.5.0



From christoffer.dall at linaro.org  Mon Feb  1 05:13:00 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 14:13:00 +0100
Subject: [PATCH v2 05/21] arm64: KVM: VHE: Turn VTCR_EL2 setup into a
 reusable macro
In-Reply-To: <1453737235-16522-6-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-6-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201131300.GH1478@cbox>

On Mon, Jan 25, 2016 at 03:53:39PM +0000, Marc Zyngier wrote:
> On a VHE-capable system, there is no point in setting VTCR_EL2
> at KVM init time. We can perfectly set it up when the kernel
> boots, removing the need for a more complicated configuration.

what's the complicated configuration which is avoided?

> 
> In order to allow this, turn VTCR_EL2 setup into a macro that
> we'll be able to reuse at boot time.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/kvm_mmu.h | 23 +++++++++++++++++++++++
>  arch/arm64/kvm/hyp-init.S        | 18 +-----------------
>  2 files changed, 24 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 7364339..d3e6d7b 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -56,6 +56,29 @@
>  
>  #ifdef __ASSEMBLY__
>  
> +#include <asm/kvm_arm.h>
> +
> +.macro setup_vtcr tmp1, tmp2
> +	mov	\tmp1, #(VTCR_EL2_FLAGS & 0xffff)
> +	movk	\tmp1, #(VTCR_EL2_FLAGS >> 16), lsl #16
> +	/*
> +	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
> +	 * VTCR_EL2.
> +	 */
> +	mrs	\tmp2, id_aa64mmfr0_el1
> +	bfi	\tmp1, \tmp2, #16, #3
> +	/*
> +	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS bit in
> +	 * VTCR_EL2.
> +	 */
> +	mrs	\tmp2, ID_AA64MMFR1_EL1
> +	ubfx	\tmp2, \tmp2, #5, #1
> +	lsl	\tmp2, \tmp2, #VTCR_EL2_VS
> +	orr	\tmp1, \tmp1, \tmp2
> +
> +	msr	vtcr_el2, \tmp1
> +	isb
> +.endm

this feels like an awful lot of code in a header file.

Is it crazy to imagine wanting to have different T0SZ for different VMs
in the future?  In that case, the T0SZ stuff should stay in KVM...

Thanks,
-Christoffer

>  /*
>   * Convert a kernel VA into a HYP VA.
>   * reg: VA to be converted.
> diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
> index 3e568dc..4143e2c 100644
> --- a/arch/arm64/kvm/hyp-init.S
> +++ b/arch/arm64/kvm/hyp-init.S
> @@ -87,23 +87,7 @@ __do_hyp_init:
>  #endif
>  	msr	tcr_el2, x4
>  
> -	ldr	x4, =VTCR_EL2_FLAGS
> -	/*
> -	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
> -	 * VTCR_EL2.
> -	 */
> -	mrs	x5, ID_AA64MMFR0_EL1
> -	bfi	x4, x5, #16, #3
> -	/*
> -	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS bit in
> -	 * VTCR_EL2.
> -	 */
> -	mrs	x5, ID_AA64MMFR1_EL1
> -	ubfx	x5, x5, #5, #1
> -	lsl	x5, x5, #VTCR_EL2_VS
> -	orr	x4, x4, x5
> -
> -	msr	vtcr_el2, x4
> +	setup_vtcr x4, x5
>  
>  	mrs	x4, mair_el1
>  	msr	mair_el2, x4
> -- 
> 2.1.4
> 


From javier at dowhile0.org  Mon Feb  1 05:15:25 2016
From: javier at dowhile0.org (Javier Martinez Canillas)
Date: Mon, 1 Feb 2016 10:15:25 -0300
Subject: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
 ACT8945A
In-Reply-To: <B256D81BAE5131468A838E5D7A243641D63FE2C7@penmbx01>
References: <1453863463-30515-1-git-send-email-wenyou.yang@atmel.com>
 <1453863463-30515-2-git-send-email-wenyou.yang@atmel.com>
 <20160129001603.GM4130@sirena.org.uk>
 <B256D81BAE5131468A838E5D7A243641D63FBF8B@penmbx01>
 <20160129113518.GQ4130@sirena.org.uk>
 <CABxcv=kNKmgRytxB5ppawrAvC-GDRhV4T_UUGvpHgKp9+BsUmQ@mail.gmail.com>
 <B256D81BAE5131468A838E5D7A243641D63FE2C7@penmbx01>
Message-ID: <CABxcv=nJsWEv9KW-5iPpUnyN8ZVpx6CV07gBRaLNWqd644YOqQ@mail.gmail.com>

Hello Wenyou,

[snip]

>> >
>> > If then device is not being loaded from the DT (and it shouldn't be,
>> > the device looks like it should be instantiated directly by the MFD as
>> > it can't exist separately to that MFD) an OF table will do nothing.
>>
>> Then he should remove the .of_compatible from the MFD cell definition.
>
> I tried it,
>
> But if removed this .of_compatible, and reserved the OF table.

What we said is that you should remove both the mfd cell
.of_compatible field and the OF table. Of course removing one but
leaving the other is not correct.

> the &pdev->dev->of_node is NULL, the driver fails to get the configuration value from DT,
>

I see, you mean that you are not able to lookup the
"active-semi,vsel-high" property.

> It seems the OF table still doesn't work. Where is wrong?
>

I think the problem is with your DT binding. You have a PMIC dev node
with compatible "active-semi,act8945a" that has a child node with
compatible "active-semi,act8945a-regulator" which in turn has the
"regulators" node.

I believe what Mark says is that there shouldn't be a compatible and
node for the regulators IC since is part of the PMIC. IOW, you can't
have it as a standalone node in the DTS.

> Could you help give some suggestion?
>

I would just remove the "active-semi,act8945a-regulator" node and make
"active-semi,vsel-high" a property of the "active-semi,act8945a" node.
That way you can remove the mfd cell .of_compatible and OF table in
the regulator driver and read the "active-semi,vsel-high" using the
platform device's parent of_node.

But it's better if you wait for Mark's opinions before re-spining your patches.

Best regards,
Javier


From christoffer.dall at linaro.org  Mon Feb  1 05:16:34 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 14:16:34 +0100
Subject: [PATCH v2 06/21] arm64: KVM: VHE: Patch out use of HVC
In-Reply-To: <1453737235-16522-7-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-7-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201131634.GI1478@cbox>

On Mon, Jan 25, 2016 at 03:53:40PM +0000, Marc Zyngier wrote:
> With VHE, the host never issues an HVC instruction to get into the
> KVM code, as we can simply branch there.
> 
> Use runtime code patching to simplify things a bit.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/hyp.S           |  7 +++++++
>  arch/arm64/kvm/hyp/hyp-entry.S | 38 +++++++++++++++++++++++++++++---------
>  2 files changed, 36 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
> index 0ccdcbb..0689a74 100644
> --- a/arch/arm64/kvm/hyp.S
> +++ b/arch/arm64/kvm/hyp.S
> @@ -17,7 +17,9 @@
>  
>  #include <linux/linkage.h>
>  
> +#include <asm/alternative.h>
>  #include <asm/assembler.h>
> +#include <asm/cpufeature.h>
>  
>  /*
>   * u64 kvm_call_hyp(void *hypfn, ...);
> @@ -38,6 +40,11 @@
>   * arch/arm64/kernel/hyp_stub.S.
>   */
>  ENTRY(kvm_call_hyp)
> +alternative_if_not ARM64_HAS_VIRT_HOST_EXTN	
>  	hvc	#0
>  	ret
> +alternative_else
> +	b	__vhe_hyp_call
> +	nop
> +alternative_endif
>  ENDPROC(kvm_call_hyp)
> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
> index 93e8d983..9e0683f 100644
> --- a/arch/arm64/kvm/hyp/hyp-entry.S
> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
> @@ -38,6 +38,32 @@
>  	ldp	x0, x1, [sp], #16
>  .endm
>  
> +.macro do_el2_call
> +	/*
> +	 * Shuffle the parameters before calling the function
> +	 * pointed to in x0. Assumes parameters in x[1,2,3].
> +	 */
> +	stp	lr, xzr, [sp, #-16]!

remind me why this pair isn't just doing "str" instead of "stp" with the
xzr ?

> +	mov	lr, x0
> +	mov	x0, x1
> +	mov	x1, x2
> +	mov	x2, x3
> +	blr	lr
> +	ldp	lr, xzr, [sp], #16
> +.endm
> +
> +ENTRY(__vhe_hyp_call)
> +	do_el2_call
> +	/*
> +	 * We used to rely on having an exception return to get
> +	 * an implicit isb. In the E2H case, we don't have it anymore.
> +	 * rather than changing all the leaf functions, just do it here
> +	 * before returning to the rest of the kernel.
> +	 */

why is this not the case with an ISB before do_el2_call then?

> +	isb
> +	ret
> +ENDPROC(__vhe_hyp_call)
> +	
>  el1_sync:				// Guest trapped into EL2
>  	save_x0_to_x3
>  
> @@ -58,19 +84,13 @@ el1_sync:				// Guest trapped into EL2
>  	mrs	x0, vbar_el2
>  	b	2f
>  
> -1:	stp	lr, xzr, [sp, #-16]!
> -
> +1:
>  	/*
> -	 * Compute the function address in EL2, and shuffle the parameters.
> +	 * Perform the EL2 call
>  	 */
>  	kern_hyp_va	x0
> -	mov	lr, x0
> -	mov	x0, x1
> -	mov	x1, x2
> -	mov	x2, x3
> -	blr	lr
> +	do_el2_call
>  
> -	ldp	lr, xzr, [sp], #16
>  2:	eret
>  
>  el1_trap:
> -- 
> 2.1.4
> 


From linus.walleij at linaro.org  Mon Feb  1 05:18:57 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  1 Feb 2016 14:18:57 +0100
Subject: [PATCH] ARM: nomadik: fix up SD/MMC DT settings
Message-ID: <1454332737-631-1-git-send-email-linus.walleij@linaro.org>

The DTSI file for the Nomadik does not properly specify how the
PL180 levelshifter is connected: the Nomadik actually needs all
the five st,sig-dir-* flags set to properly control all lines out.

Further this board supports full power cycling of the card, and
since this variant has no hardware clock gating, it needs a
ridiculously low frequency setting to keep up with the ever
overflowing FIFO.

The pin configuration set-up is a bit of a mystery, because of
course these pins are a mix of inputs and outputs. However the
reference implementation sets all pins to "output" with
unspecified initial value, so let's do that here as well.

Cc: stable at vger.kernel.org
Cc: Ulf Hansson <ulf.hansson at linaro.org>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ARM SoC folks: this fixes the non-working SD/MMC card on the
Nomadik please apply this directly for fixes if Ulf is OK with
it.
---
 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 37 ++++++++++++++++--------------
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
index 50c256f0fd98..b1707f6217bf 100644
--- a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
+++ b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
@@ -128,22 +128,14 @@
 			};
 			mmcsd_default_mode: mmcsd_default {
 				mmcsd_default_cfg1 {
-					/* MCCLK */
-					pins = "GPIO8_B10";
-					ste,output = <0>;
-				};
-				mmcsd_default_cfg2 {
-					/* MCCMDDIR, MCDAT0DIR, MCDAT31DIR, MCDATDIR2 */
-					pins = "GPIO10_C11", "GPIO15_A12",
-					"GPIO16_C13", "GPIO23_D15";
-					ste,output = <1>;
-				};
-				mmcsd_default_cfg3 {
-					/* MCCMD, MCDAT3-0, MCMSFBCLK */
-					pins = "GPIO9_A10", "GPIO11_B11",
-					"GPIO12_A11", "GPIO13_C12",
-					"GPIO14_B12", "GPIO24_C15";
-					ste,input = <1>;
+					/*
+					 * MCCLK, MCCMDDIR, MCDAT0DIR, MCDAT31DIR, MCDATDIR2
+					 * MCCMD, MCDAT3-0, MCMSFBCLK
+					 */
+					pins = "GPIO8_B10", "GPIO9_A10", "GPIO10_C11", "GPIO11_B11",
+					       "GPIO12_A11", "GPIO13_C12", "GPIO14_B12", "GPIO15_A12",
+					       "GPIO16_C13", "GPIO23_D15", "GPIO24_C15";
+					ste,output = <2>;
 				};
 			};
 		};
@@ -803,10 +795,21 @@
 			clock-names = "mclk", "apb_pclk";
 			interrupt-parent = <&vica>;
 			interrupts = <22>;
-			max-frequency = <48000000>;
+			max-frequency = <400000>;
 			bus-width = <4>;
 			cap-mmc-highspeed;
 			cap-sd-highspeed;
+			full-pwr-cycle;
+			/*
+			 * The STw4811 circuit used with the Nomadik strictly
+			 * requires that all of these signal direction pins be
+			 * routed and used for its 4-bit levelshifter.
+			 */
+			st,sig-dir-dat0;
+			st,sig-dir-dat2;
+			st,sig-dir-dat31;
+			st,sig-dir-cmd;
+			st,sig-pin-fbclk;
 			pinctrl-names = "default";
 			pinctrl-0 = <&mmcsd_default_mux>, <&mmcsd_default_mode>;
 			vmmc-supply = <&vmmc_regulator>;
-- 
2.4.3



From christoffer.dall at linaro.org  Mon Feb  1 05:20:42 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 14:20:42 +0100
Subject: [PATCH v2 07/21] arm64: KVM: VHE: Patch out kern_hyp_va
In-Reply-To: <1453737235-16522-8-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-8-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201132042.GJ1478@cbox>

On Mon, Jan 25, 2016 at 03:53:41PM +0000, Marc Zyngier wrote:
> The kern_hyp_va macro is pretty meaninless with VHE, as there is
> only one mapping - the kernel one.
> 
> In order to keep the code readable and efficient, use runtime
> patching to replace the 'and' instruction used to compute the VA
> with a 'nop'.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/kvm_mmu.h | 11 ++++++++++-
>  arch/arm64/kvm/hyp/hyp.h         | 25 ++++++++++++++++++++++---
>  2 files changed, 32 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index d3e6d7b..62f0d14 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -23,13 +23,16 @@
>  #include <asm/cpufeature.h>
>  
>  /*
> - * As we only have the TTBR0_EL2 register, we cannot express
> + * As ARMv8.0 only has the TTBR0_EL2 register, we cannot express
>   * "negative" addresses. This makes it impossible to directly share
>   * mappings with the kernel.
>   *
>   * Instead, give the HYP mode its own VA region at a fixed offset from
>   * the kernel by just masking the top bits (which are all ones for a
>   * kernel address).
> + *
> + * ARMv8.1 (using VHE) does have a TTBR1_EL2, and doesn't use these
> + * macros (the entire kernel runs at EL2).
>   */
>  #define HYP_PAGE_OFFSET_SHIFT	VA_BITS
>  #define HYP_PAGE_OFFSET_MASK	((UL(1) << HYP_PAGE_OFFSET_SHIFT) - 1)
> @@ -56,6 +59,8 @@
>  
>  #ifdef __ASSEMBLY__
>  
> +#include <asm/alternative.h>
> +#include <asm/cpufeature.h>
>  #include <asm/kvm_arm.h>
>  
>  .macro setup_vtcr tmp1, tmp2
> @@ -84,7 +89,11 @@
>   * reg: VA to be converted.
>   */
>  .macro kern_hyp_va	reg
> +alternative_if_not ARM64_HAS_VIRT_HOST_EXTN	
>  	and	\reg, \reg, #HYP_PAGE_OFFSET_MASK
> +alternative_else
> +	nop
> +alternative_endif
>  .endm
>  
>  #else
> diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
> index fb27517..fc502f3 100644
> --- a/arch/arm64/kvm/hyp/hyp.h
> +++ b/arch/arm64/kvm/hyp/hyp.h
> @@ -25,9 +25,28 @@
>  
>  #define __hyp_text __section(.hyp.text) notrace
>  
> -#define kern_hyp_va(v) (typeof(v))((unsigned long)(v) & HYP_PAGE_OFFSET_MASK)
> -#define hyp_kern_va(v) (typeof(v))((unsigned long)(v) - HYP_PAGE_OFFSET \
> -						      + PAGE_OFFSET)
> +static inline unsigned long __kern_hyp_va(unsigned long v)
> +{
> +	asm volatile(ALTERNATIVE("and %0, %0, %1",
> +				 "nop",
> +				 ARM64_HAS_VIRT_HOST_EXTN)
> +		     : "+r" (v) : "i" (HYP_PAGE_OFFSET_MASK));
> +	return v;
> +}
> +
> +#define kern_hyp_va(v) (typeof(v))(__kern_hyp_va((unsigned long)(v)))
> +
> +static inline unsigned long __hyp_kern_va(unsigned long v)
> +{
> +	u64 offset = PAGE_OFFSET - HYP_PAGE_OFFSET;
> +	asm volatile(ALTERNATIVE("add %0, %0, %1",
> +				 "nop",
> +				 ARM64_HAS_VIRT_HOST_EXTN)
> +		     : "+r" (v) : "r" (offset));
> +	return v;
> +}
> +
> +#define hyp_kern_va(v) (typeof(v))(__hyp_kern_va((unsigned long)(v)))

why do we need this casting of values instead of just defining these
inlines and calling them directly with proper typing?

-Christoffer

>  
>  /**
>   * hyp_alternate_select - Generates patchable code sequences that are
> -- 
> 2.1.4
> 


From robh+dt at kernel.org  Mon Feb  1 05:22:02 2016
From: robh+dt at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 07:22:02 -0600
Subject: [PATCH 2/2] dt-bindings: Add TPO TPG110 binding
In-Reply-To: <1454316643-3931-1-git-send-email-linus.walleij@linaro.org>
References: <1454316643-3931-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <CAL_JsqJSR_fCnCvUnzJaD3-zA0SPgTxjKtbL=up2NyH0GL_56w@mail.gmail.com>

On Mon, Feb 1, 2016 at 2:50 AM, Linus Walleij <linus.walleij at linaro.org> wrote:
> This adds device tree bindings for the TPO TPG110 panel found
> mounted in the Nomadik NHK8815.
>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
>  .../bindings/display/panel/tpo,tpg110.txt          | 47 ++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
> new file mode 100644
> index 000000000000..acbc6bef3593
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
> @@ -0,0 +1,47 @@
> +TPO TPG110 Panel
> +================
> +
> +This binding builds on the DPI bindings, adding a few properties
> +as a superset of a DPI. See panel-dpi.txt for the required DPI
> +bindings.
> +
> +Required properties:
> +- compatible : "tpo,tpg110"
> +- grestb-gpio : panel reset GPIO

-gpios

The example is correct.

Otherwise,

Acked-by: Rob Herring <robh at kernel.org>

> +- scen-gpios : serial control enable GPIO
> +- scl-gpios : serial control clock line GPIO
> +- sda-gpios : serial control data line GPIO
> +
> +Required nodes:
> +- Video port for DPI input, see panel-dpi.txt
> +- Panel timing for DPI setup, see panel-dpi.txt
> +
> +Example
> +-------
> +
> +panel {
> +       compatible = "tpo,tpg110", "panel-dpi";
> +       grestb-gpios = <&stmpe_gpio44 5 GPIO_ACTIVE_LOW>;
> +       scen-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
> +       scl-gpios = <&gpio0 5 GPIO_ACTIVE_HIGH>;
> +       sda-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
> +       backlight = <&bl>;
> +
> +       port {
> +               nomadik_clcd_panel: endpoint {
> +                       remote-endpoint = <&nomadik_clcd_pads>;
> +               };
> +       };
> +
> +       panel-timing {
> +               clock-frequency = <33200000>;
> +               hactive = <800>;
> +               hback-porch = <216>;
> +               hfront-porch = <40>;
> +               hsync-len = <1>;
> +               vactive = <480>;
> +               vback-porch = <35>;
> +               vfront-porch = <10>;
> +               vsync-len = <1>;
> +       };
> +};
> --
> 2.4.3
>


From mark.rutland at arm.com  Mon Feb  1 05:25:57 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 1 Feb 2016 13:25:57 +0000
Subject: [RFC PATCH] irq/mbigen:Fix the problem of IO remap for
 duplicated physical address in mbigen driver
In-Reply-To: <56AF585E.6050005@huawei.com>
References: <1454327094-7848-1-git-send-email-majun258@huawei.com>
 <20160201115717.GD674@leverpostej> <56AF585E.6050005@huawei.com>
Message-ID: <20160201132557.GG674@leverpostej>

On Mon, Feb 01, 2016 at 09:06:38PM +0800, majun (F) wrote:
> 
> 
> ? 2016/2/1 19:57, Mark Rutland ??:
> > On Mon, Feb 01, 2016 at 07:44:54PM +0800, MaJun wrote:
> >> From: Ma Jun <majun258 at huawei.com>
> >>
> >> For mbigen module, there is a special case that more than one mbigen 
> >> device nodes use the same reg definition in DTS when these devices
> >> exist in the same mbigen hardware module. 
> >>
> >> mbigen_dev1:intc_dev1 {
> >> 	...
> >> 	reg = <0x0 0xc0080000 0x0 0x10000>;
> >> 	...
> >> };
> >>
> >> mbigen_dev2:intc_dev2 {
> >> 	...
> >> 	reg = <0x0 0xc0080000 0x0 0x10000>;
> >> 	...
> >> };
> > 
> > This doesn't sound right. If they exist in the same place, and have the
> > same reg, they _are_ the same device.
> > 
> > You'll need to explain this better.
> > 
> 
> For a mbigen hardware module which connecte with several devices,
> because these devices has different device ID,
> I need to define a device node for each device in DTS file.
> 
> 	mbigen
> 	|
> ------------------
> | 	| 	|
> dev1 	dev2 	dev3
> 
> Because of register layout,the registers related with these devices
> are put together, I can't split them clearly.
> So, I only make these devices which connect with
> same mbigen hardware module usethe same address.

This sounds like we've either mis-described the mbigen in the binding,
or we're mis-describing the relationship with the devices.

It should not be necessary to describe the same set of registers
repeatedly.

> >>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> -	mgn_chip->base = devm_ioremap_resource(&pdev->dev, res);
> >> +	mgn_chip->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> > 
> > These two behaving differently doesn't seem correct either...
> 
> The problem is caused by memory region check fail because of
> duplicated address in devm_ioremap_resource().

The check is sensible. Using devm_ioremap rather than
devm_ioremap_resource to avoid the check is not the correct solution.

> For mbigen special case, there is no necessary to do this check.

I'm not sure I fully agree.

Regardless, this is not the right solution; it is fragile at best.

Thanks,
Mark.


From sergei.shtylyov at cogentembedded.com  Mon Feb  1 05:32:05 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 1 Feb 2016 16:32:05 +0300
Subject: [PATCH v2 net 3/6] net: mvneta: Remove unused code
In-Reply-To: <1454332067-16378-4-git-send-email-gregory.clement@free-electrons.com>
References: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
 <1454332067-16378-4-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <56AF5E55.9030603@cogentembedded.com>

Hello.

On 2/1/2016 4:07 PM, Gregory CLEMENT wrote:

> Since the commit 2dcf75e2793c ("net: mvneta: Associate RX queues with
> each CPU") all the percpu irq are used and unmask at initialization, so

    Unmasked, you mean?

> there is no point to unmask them first.

    Mask, maybe (looking at the patch)?

> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>   drivers/net/ethernet/marvell/mvneta.c | 8 --------
>   1 file changed, 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index 3d6e3137f305..861b7e0d7d5f 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -3009,14 +3009,6 @@ static int mvneta_open(struct net_device *dev)
>   		goto err_cleanup_txqs;
>   	}
>
> -	/* Even though the documentation says that request_percpu_irq
> -	 * doesn't enable the interrupts automatically, it actually
> -	 * does so on the local CPU.
> -	 *
> -	 * Make sure it's disabled.
> -	 */
> -	mvneta_percpu_disable(pp);
> -
>   	/* Enable per-CPU interrupt on all the CPU to handle our RX
>   	 * queue interrupts
>   	 */

MBR, Sergei



From shawnguo at kernel.org  Mon Feb  1 05:29:16 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 1 Feb 2016 21:29:16 +0800
Subject: [PATCH v4 1/2] ARM: dts: imx6: Add support for Toradex Apalis
 iMX6Q/D SoM
In-Reply-To: <1453675703-31594-2-git-send-email-marcel.ziswiler@toradex.com>
References: <1453675703-31594-1-git-send-email-marcel.ziswiler@toradex.com>
 <1453675703-31594-2-git-send-email-marcel.ziswiler@toradex.com>
Message-ID: <20160201132916.GF10671@tiger>

On Sun, Jan 24, 2016 at 11:48:22PM +0100, Marcel Ziswiler wrote:
> From: Petr ?tetiar <ynezz at true.cz>
> 
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler at toradex.com>
> Signed-off-by: Petr ?tetiar <ynezz at true.cz>
> Reviewed-by: Stefan Agner <stefan at agner.ch>
> ---
> 
> Changes in v4:
> - integrated review feedback from Fabio
> 
> Changes in v3:
> - integrated review feedback from Petr
> - integrated review feedback from Stefan
> - move I2C DDC enablement and assignement handling into carrier board DTS where it belongs
> - move CAN nodes up a little to keep the alphabetical order
> - added an explanatory comment about PWR_I2C usage
> 
> Changes in v2:
> - clarify exact Apalis iMX6Q/D SoM type in cover letter
> - clarify exact Apalis iMX6Q/D module type and Ixora carrier board in model
>   node
> - got rid of obsolete mmc aliases
> - working SGTL5000 audio/sound integration
> - working STMPE811 touch screen controller integration
> - integrated review feedback from Lucas
> - left and even added some more comments as I don't see why putting any
>   explanatory comments in dts' should be such a bad thing to do
> - completely got rid of the memory node as that is something typically filled
>   in by the boot loader e.g. U-Boot
> - without the regulators simple-bus it no longer boots
> - even though we supposedly shipped a few hundred V1.0a modules drop DCE UART
>   support for now and simplify file layout
> - replaced obsolete no-1-8-v by mainline supported voltage-ranges = <3300 3300>
>   usdhc property and yes card detects are indeed active low (;-p)
> - integrated review feedback from Stefan
> - fixed Ethernet PHY reset & interrupt (requires Micrel PHY driver to be
>   enabled)
> - fixed HDMI DDC (requires GPIO-based bitbanging I2C to be enabled)
> - fixed SPDIF
> 
>  arch/arm/boot/dts/imx6qdl-apalis.dtsi | 1011 +++++++++++++++++++++++++++++++++
>  1 file changed, 1011 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6qdl-apalis.dtsi
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> new file mode 100644
> index 0000000..5306466
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> @@ -0,0 +1,1011 @@
> +/*
> + * Copyright 2014-2016 Toradex AG
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License
> + *     version 2 as published by the Free Software Foundation.
> + *
> + *     This file is distributed in the hope that it will be useful
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> +	model = "Toradex Apalis iMX6Q/D Module";
> +	compatible = "toradex,apalis_imx6q", "fsl,imx6q";
> +
> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm4 0 5000000>;
> +		status = "disabled";
> +	};
> +
> +	/* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
> +	i2cddc: i2c at 0 {
> +		compatible = "i2c-gpio";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_i2c_ddc>;
> +		gpios = <&gpio3 16 GPIO_ACTIVE_HIGH /* sda */
> +			 &gpio2 30 GPIO_ACTIVE_HIGH /* scl */
> +			>;
> +		i2c-gpio,delay-us = <2>;	/* ~100 kHz */
> +		status = "disabled";
> +	};
> +
> +	regulators {
> +		compatible = "simple-bus";
> +
> +		reg_1p8v: 1p8v {
> +			compatible = "regulator-fixed";
> +			regulator-name = "1P8V";
> +			regulator-min-microvolt = <1800000>;
> +			regulator-max-microvolt = <1800000>;
> +			regulator-always-on;
> +		};


As Petr already mentioned, we should try to put these fixed regulators
directly under root node.   In that case, we can drop the fake
simple-bus container node and save the artificial 'reg' property.  The
regulators can be named in the following schema:

        reg_xxx: regulator-xxx {
                ...
        }

> +
> +		reg_2p5v: 2p5v {
> +			compatible = "regulator-fixed";
> +			regulator-name = "2P5V";
> +			regulator-min-microvolt = <2500000>;
> +			regulator-max-microvolt = <2500000>;
> +			regulator-always-on;
> +		};
> +
> +		reg_3p3v: 3p3v {
> +			compatible = "regulator-fixed";
> +			regulator-name = "3P3V";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +			regulator-always-on;
> +		};
> +
> +		reg_usb_otg_vbus: usb_otg_vbus {
> +			compatible = "regulator-fixed";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_regulator_usbotg_pwr>;
> +			regulator-name = "usb_otg_vbus";
> +			regulator-min-microvolt = <5000000>;
> +			regulator-max-microvolt = <5000000>;
> +			gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
> +			enable-active-high;
> +			status = "disabled";
> +		};
> +
> +		/* on module usb hub */
> +		reg_usb_host_vbus_hub: usb_host_vbus_hub {
> +			compatible = "regulator-fixed";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_regulator_usbhub_pwr>;
> +			regulator-name = "usb_host_vbus_hub";
> +			regulator-min-microvolt = <5000000>;
> +			regulator-max-microvolt = <5000000>;
> +			gpio = <&gpio3 28 GPIO_ACTIVE_HIGH>;
> +			startup-delay-us = <2000>;
> +			enable-active-high;
> +			status = "okay";
> +		};
> +
> +		reg_usb_host_vbus: usb_host_vbus {
> +			compatible = "regulator-fixed";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_regulator_usbh_pwr>;
> +			regulator-name = "usb_host_vbus";
> +			regulator-min-microvolt = <5000000>;
> +			regulator-max-microvolt = <5000000>;
> +			gpio =  <&gpio1 0 GPIO_ACTIVE_HIGH>;
> +			enable-active-high;
> +			vin-supply = <&reg_usb_host_vbus_hub>;
> +			status = "disabled";
> +		};
> +	};
> +
> +	sound {
> +		compatible = "fsl,imx-audio-sgtl5000";
> +		model = "imx6q-apalis-sgtl5000";
> +		ssi-controller = <&ssi1>;
> +		audio-codec = <&codec>;
> +		audio-routing =
> +			"LINE_IN", "Line In Jack",
> +			"MIC_IN", "Mic Jack",
> +			"Mic Jack", "Mic Bias",
> +			"Headphone Jack", "HP_OUT";
> +		mux-int-port = <1>;
> +		mux-ext-port = <4>;
> +	};
> +
> +	sound_spdif: sound-spdif {
> +		compatible = "fsl,imx-audio-spdif";
> +		model = "imx-spdif";
> +		spdif-controller = <&spdif>;
> +		spdif-in;
> +		spdif-out;
> +		status = "disabled";
> +	};
> +};
> +
> +&audmux {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_audmux &pinctrl_audmux_mclk>;
> +	status = "okay";
> +};
> +
> +&can1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_flexcan1>;
> +	status = "disabled";
> +};
> +
> +&can2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_flexcan2>;
> +	status = "disabled";
> +};
> +
> +/* Apalis SPI1 */
> +&ecspi1 {
> +	fsl,spi-num-chipselects = <1>;
> +	cs-gpios = <&gpio5 25 GPIO_ACTIVE_HIGH>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_spi_cs1>;
> +	status = "disabled";
> +};
> +
> +/* Apalis SPI2 */
> +&ecspi2 {
> +	fsl,spi-num-chipselects = <1>;
> +	cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_spi_cs2>;
> +	status = "disabled";
> +};
> +
> +&fec {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_enet &pinctrl_enet_ctrl>;
> +	phy-mode = "rgmii";
> +	phy-handle = <&ethphy>;
> +	phy-reset-duration = <10>;
> +	phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
> +	status = "okay";
> +
> +	mdio {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		ethphy: ethernet-phy at 7 {
> +			interrupt-parent = <&gpio1>;
> +			interrupts = <30 IRQ_TYPE_LEVEL_LOW>;
> +			reg = <7>;
> +		};
> +	};
> +};
> +
> +&hdmi {
> +	status = "disabled";
> +};

The device is disabled by default in imx6qdl.dtsi, so this is not
needed.

> +
> +/*
> + * GEN1_I2C: I2C1_SDA/SCL on MXM3 209/211 (e.g. RTC on carrier
> + * board)
> + */
> +&i2c1 {
> +	clock-frequency = <100000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c1>;
> +	status = "disabled";
> +};
> +
> +/*
> + * PWR_I2C: power I2C to audio codec, PMIC, temperature sensor and
> + * touch screen controller
> + */
> +&i2c2 {
> +	clock-frequency = <100000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c2>;
> +	status = "okay";
> +
> +	pmic: pfuze100 at 08 {
> +		compatible = "fsl,pfuze100";
> +		reg = <0x08>;
> +
> +		regulators {
> +			sw1a_reg: sw1ab {
> +				regulator-min-microvolt = <300000>;
> +				regulator-max-microvolt = <1875000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +				regulator-ramp-delay = <6250>;
> +			};
> +
> +			sw1c_reg: sw1c {
> +				regulator-min-microvolt = <300000>;
> +				regulator-max-microvolt = <1875000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +				regulator-ramp-delay = <6250>;
> +			};
> +
> +			sw3a_reg: sw3a {
> +				regulator-min-microvolt = <400000>;
> +				regulator-max-microvolt = <1975000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			swbst_reg: swbst {
> +				regulator-min-microvolt = <5000000>;
> +				regulator-max-microvolt = <5150000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			snvs_reg: vsnvs {
> +				regulator-min-microvolt = <1000000>;
> +				regulator-max-microvolt = <3000000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			vref_reg: vrefddr {
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			vgen1_reg: vgen1 {
> +				regulator-min-microvolt = <800000>;
> +				regulator-max-microvolt = <1550000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			vgen2_reg: vgen2 {
> +				regulator-min-microvolt = <800000>;
> +				regulator-max-microvolt = <1550000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			vgen3_reg: vgen3 {
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			vgen4_reg: vgen4 {
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			vgen5_reg: vgen5 {
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +
> +			vgen6_reg: vgen6 {
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-boot-on;
> +				regulator-always-on;
> +			};
> +		};
> +	};
> +
> +	codec: sgtl5000 at 0a {
> +		compatible = "fsl,sgtl5000";
> +		reg = <0x0a>;
> +		clocks = <&clks 201>;
> +		VDDA-supply = <&reg_2p5v>;
> +		VDDIO-supply = <&reg_3p3v>;
> +	};
> +
> +	/* STMPE811 touch screen controller */
> +	stmpe811 at 41 {
> +		compatible = "st,stmpe811";

The compatible seems to be used by kernel without a binding document.

> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_touch_int>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		reg = <0x41>;
> +		interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
> +		interrupt-parent = <&gpio4>;
> +		interrupt-controller;
> +		id = <0>;
> +		blocks = <0x5>;
> +		irq-trigger = <0x1>;

Have a new line between properties and sub-node.

> +		stmpe_touchscreen {

Shouldn't the node name be generic as just touchscreen?  Or at least,
hyphen instead of underscore should be used in node name.

> +			compatible = "st,stmpe-ts";
> +			reg = <0>;
> +			/* 3.25 MHz ADC clock speed */
> +			st,adc-freq = <1>;
> +			/* 8 sample average control */
> +			st,ave-ctrl = <3>;
> +			/* 7 length fractional part in z */
> +			st,fraction-z = <7>;
> +			/*
> +			 * 50 mA typical 80 mA max touchscreen drivers
> +			 * current limit value
> +			 */
> +			st,i-drive = <1>;
> +			/* 12-bit ADC */
> +			st,mod-12b = <1>;
> +			/* internal ADC reference */
> +			st,ref-sel = <0>;
> +			/* ADC converstion time: 80 clocks */
> +			st,sample-time = <4>;
> +			/* 1 ms panel driver settling time */
> +			st,settling = <3>;
> +			/* 5 ms touch detect interrupt delay */
> +			st,touch-det-delay = <5>;
> +		};
> +	};
> +};
> +
> +/*
> + * GEN2_I2C, CAM: I2C3_SDA/SCL on MXM3 201/203 (unused)
> + */
> +&i2c3 {
> +	clock-frequency = <100000>;
> +	pinctrl-names = "default", "recovery";
> +	pinctrl-0 = <&pinctrl_i2c3>;
> +	pinctrl-1 = <&pinctrl_i2c3_recovery>;
> +	scl-gpios = <&gpio3 17 GPIO_ACTIVE_HIGH>;
> +	sda-gpios = <&gpio3 18 GPIO_ACTIVE_HIGH>;
> +	status = "disabled";
> +};
> +
> +&pwm1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_pwm1>;
> +	status = "disabled";
> +};
> +
> +&pwm2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_pwm2>;
> +	status = "disabled";
> +};
> +
> +&pwm3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_pwm3>;
> +	status = "disabled";
> +};
> +
> +&pwm4 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_pwm4>;
> +	status = "disabled";
> +};
> +
> +&spdif {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_spdif>;
> +	status = "disabled";
> +};
> +
> +&ssi1 {
> +	status = "okay";
> +};
> +
> +&uart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart1_dte &pinctrl_uart1_ctrl>;
> +	fsl,dte-mode;
> +	fsl,uart-has-rtscts;
> +	status = "disabled";
> +};
> +
> +&uart2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart2_dte>;
> +	fsl,dte-mode;
> +	fsl,uart-has-rtscts;
> +	status = "disabled";
> +};
> +
> +&uart4 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart4_dte>;
> +	fsl,dte-mode;
> +	status = "disabled";
> +};
> +
> +&uart5 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart5_dte>;
> +	fsl,dte-mode;
> +	status = "disabled";
> +};
> +
> +&usbh1 {
> +	status = "disabled";
> +};

This is not needed.

> +
> +&usbotg {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usbotg>;
> +	disable-over-current;
> +	status = "disabled";
> +};
> +
> +/* MMC1 */
> +&usdhc1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usdhc1>;
> +	vmmc-supply = <&reg_3p3v>;
> +	bus-width = <8>;
> +	voltage-ranges = <3300 3300>;
> +	status = "disabled";
> +};
> +
> +/* SD1 */
> +&usdhc2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usdhc2>;
> +	vmmc-supply = <&reg_3p3v>;
> +	bus-width = <4>;
> +	voltage-ranges = <3300 3300>;
> +	status = "disabled";
> +};
> +
> +/* eMMC */
> +&usdhc3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usdhc3>;
> +	vmmc-supply = <&reg_3p3v>;
> +	bus-width = <8>;
> +	voltage-ranges = <3300 3300>;
> +	non-removable;
> +	status = "okay";
> +};
> +
> +&weim {
> +	status = "disabled";
> +};
> +
> +&iomuxc {
> +	ecspi {

These function container nodes do not make too much sense now, and can
be dropped, since commit 5fcdf6a7ed95 (pinctrl: imx: Allow parsing DT
without function nodes).

> +		pinctrl_ecspi1: ecspi1grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_CSI0_DAT6__ECSPI1_MISO 0x100b1
> +				MX6QDL_PAD_CSI0_DAT5__ECSPI1_MOSI 0x100b1
> +				MX6QDL_PAD_CSI0_DAT4__ECSPI1_SCLK 0x100b1
> +			>;
> +		};

Please have a new line between nodes.

> +		pinctrl_ecspi2: ecspi2grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x100b1
> +				MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1
> +				MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1
> +			>;
> +		};
> +		pinctrl_spi_cs1: spi_cs1 {

I would like to see a consistent pinctrl group node naming schema, i.e.
xxxgrp.  In any case, underscore shouldn't be used in node name.

> +			fsl,pins = <
> +				/* SPI1 cs */
> +				MX6QDL_PAD_CSI0_DAT7__GPIO5_IO25	0x000b1
> +			>;
> +		};

I actually think one pinctrl node like the following is good enough,
with some necessary comments on the extra pins.

	pinctrl_ecspi1: ecspi1grp {
		fsl,pins = <
			MX6QDL_PAD_CSI0_DAT6__ECSPI1_MISO	0x100b1
			MX6QDL_PAD_CSI0_DAT5__ECSPI1_MOSI	0x100b1
			MX6QDL_PAD_CSI0_DAT4__ECSPI1_SCLK	0x100b1
			/* SPI1 cs */
			MX6QDL_PAD_CSI0_DAT7__GPIO5_IO25	0x000b1
		>;
	};

If you consider this for all the following pinctrl nodes, I think the
iomuxc node will become a bit clean and clear.

Shawn

> +		pinctrl_spi_cs2: spi_cs2 {
> +			fsl,pins = <
> +				/* SPI2 cs */
> +				MX6QDL_PAD_EIM_RW__GPIO2_IO26		0x000b1
> +			>;
> +		};
> +	};
> +
> +	flexcan {
> +		pinctrl_flexcan1: flexcan1grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_GPIO_7__FLEXCAN1_TX 0x1b0b0
> +				MX6QDL_PAD_GPIO_8__FLEXCAN1_RX 0x1b0b0
> +			>;
> +		};
> +		pinctrl_flexcan2: flexcan2grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x1b0b0
> +				MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x1b0b0
> +			>;
> +		};
> +	};
> +
> +	gpio {
> +		pinctrl_apalis_gpio1: apalis_gpio1 {
> +			fsl,pins = <
> +				MX6QDL_PAD_NANDF_D4__GPIO2_IO04 0x130b0
> +			>;
> +		};
> +		pinctrl_apalis_gpio2: apalis_gpio2 {
> +			fsl,pins = <
> +				MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x130b0
> +			>;
> +		};
> +		pinctrl_apalis_gpio3: apalis_gpio3 {
> +			fsl,pins = <
> +				MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x130b0
> +			>;
> +		};
> +		pinctrl_apalis_gpio4: apalis_gpio4 {
> +			fsl,pins = <
> +				MX6QDL_PAD_NANDF_D7__GPIO2_IO07 0x130b0
> +			>;
> +		};
> +		pinctrl_apalis_gpio5: apalis_gpio5 {
> +			fsl,pins = <
> +				MX6QDL_PAD_NANDF_RB0__GPIO6_IO10 0x130b0
> +			>;
> +		};
> +		pinctrl_apalis_gpio6: apalis_gpio6 {
> +			fsl,pins = <
> +				MX6QDL_PAD_NANDF_WP_B__GPIO6_IO09 0x130b0
> +			>;
> +		};
> +		pinctrl_apalis_gpio7: apalis_gpio7 {
> +			fsl,pins = <
> +				MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x130b0
> +			>;
> +		};
> +		pinctrl_apalis_gpio8: apalis_gpio8 {
> +			fsl,pins = <
> +				MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x130b0
> +			>;
> +		};
> +		pinctrl_gpio_keys: gpio_keys {
> +			fsl,pins = <
> +				/* Power button */
> +				MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x1b0b0
> +			>;
> +		};
> +	};
> +
> +	hdmi {
> +		pinctrl_hdmi_cec: hdmicecgrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
> +			>;
> +		};
> +	};
> +
> +	i2c {
> +		pinctrl_i2c_ddc: i2c_ddc {
> +			fsl,pins = <
> +				/* DDC bitbang */
> +				MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
> +				MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x1b0b0
> +			>;
> +		};
> +		pinctrl_i2c1: i2c1grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_CSI0_DAT8__I2C1_SDA 0x4001b8b1
> +				MX6QDL_PAD_CSI0_DAT9__I2C1_SCL 0x4001b8b1
> +			>;
> +		};
> +		pinctrl_i2c3: i2c3grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_EIM_D17__I2C3_SCL 0x4001b8b1
> +				MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
> +			>;
> +		};
> +		pinctrl_i2c3_recovery: i2c3-recoverygrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_EIM_D17__GPIO3_IO17 0x4001b8b1
> +				MX6QDL_PAD_EIM_D18__GPIO3_IO18 0x4001b8b1
> +			>;
> +		};
> +	};
> +
> +	/* pins used on module */
> +	imx6q-apalis {
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_reset_moci &pinctrl_emmc_reset>;
> +		pinctrl_audmux: audmuxgrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_DISP0_DAT20__AUD4_TXC	0x130b0
> +				MX6QDL_PAD_DISP0_DAT21__AUD4_TXD	0x130b0
> +				MX6QDL_PAD_DISP0_DAT22__AUD4_TXFS	0x130b0
> +				MX6QDL_PAD_DISP0_DAT23__AUD4_RXD	0x130b0
> +			>;
> +		};
> +		pinctrl_audmux_mclk: audmux_mclk {
> +			fsl,pins = <
> +				/* SGTL5000 sys_mclk */
> +				MX6QDL_PAD_GPIO_5__CCM_CLKO1 0x130b0
> +			>;
> +		};
> +		pinctrl_emmc_reset: emmc_reset {
> +			fsl,pins = <
> +				/* eMMC reset, leave it alone */
> +				MX6QDL_PAD_SD3_RST__GPIO7_IO08 0x0f058
> +			>;
> +		};
> +		pinctrl_enet: enetgrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_ENET_MDIO__ENET_MDIO		0x100b0
> +				MX6QDL_PAD_ENET_MDC__ENET_MDC		0x100b0
> +				MX6QDL_PAD_RGMII_TXC__RGMII_TXC		0x100b0
> +				MX6QDL_PAD_RGMII_TD0__RGMII_TD0		0x100b0
> +				MX6QDL_PAD_RGMII_TD1__RGMII_TD1		0x100b0
> +				MX6QDL_PAD_RGMII_TD2__RGMII_TD2		0x100b0
> +				MX6QDL_PAD_RGMII_TD3__RGMII_TD3		0x100b0
> +				MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL	0x100b0
> +				MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK	0x100b0
> +				MX6QDL_PAD_RGMII_RXC__RGMII_RXC		0x1b0b0
> +				MX6QDL_PAD_RGMII_RD0__RGMII_RD0		0x1b0b0
> +				MX6QDL_PAD_RGMII_RD1__RGMII_RD1		0x1b0b0
> +				MX6QDL_PAD_RGMII_RD2__RGMII_RD2		0x1b0b0
> +				MX6QDL_PAD_RGMII_RD3__RGMII_RD3		0x1b0b0
> +				MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL	0x1b0b0
> +			>;
> +		};
> +		pinctrl_enet_ctrl: enet_ctrlgrp {
> +			fsl,pins = <
> +				/* Ethernet PHY reset */
> +				MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25	0x000b0
> +				/* Ethernet PHY interrupt */
> +				MX6QDL_PAD_ENET_TXD0__GPIO1_IO30	0x000b1
> +			>;
> +		};
> +		pinctrl_i2c2: i2c2grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
> +				MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
> +			>;
> +		};
> +		pinctrl_ipu2_vdac: ipu2vdacgrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_DI0_DISP_CLK__IPU2_DI0_DISP_CLK 0xd1
> +				MX6QDL_PAD_DI0_PIN15__IPU2_DI0_PIN15       0xd1
> +				MX6QDL_PAD_DI0_PIN2__IPU2_DI0_PIN02        0xd1
> +				MX6QDL_PAD_DI0_PIN3__IPU2_DI0_PIN03        0xd1
> +				MX6QDL_PAD_DISP0_DAT0__IPU2_DISP0_DATA00   0xf9
> +				MX6QDL_PAD_DISP0_DAT1__IPU2_DISP0_DATA01   0xf9
> +				MX6QDL_PAD_DISP0_DAT2__IPU2_DISP0_DATA02   0xf9
> +				MX6QDL_PAD_DISP0_DAT3__IPU2_DISP0_DATA03   0xf9
> +				MX6QDL_PAD_DISP0_DAT4__IPU2_DISP0_DATA04   0xf9
> +				MX6QDL_PAD_DISP0_DAT5__IPU2_DISP0_DATA05   0xf9
> +				MX6QDL_PAD_DISP0_DAT6__IPU2_DISP0_DATA06   0xf9
> +				MX6QDL_PAD_DISP0_DAT7__IPU2_DISP0_DATA07   0xf9
> +				MX6QDL_PAD_DISP0_DAT8__IPU2_DISP0_DATA08   0xf9
> +				MX6QDL_PAD_DISP0_DAT9__IPU2_DISP0_DATA09   0xf9
> +				MX6QDL_PAD_DISP0_DAT10__IPU2_DISP0_DATA10  0xf9
> +				MX6QDL_PAD_DISP0_DAT11__IPU2_DISP0_DATA11  0xf9
> +				MX6QDL_PAD_DISP0_DAT12__IPU2_DISP0_DATA12  0xf9
> +				MX6QDL_PAD_DISP0_DAT13__IPU2_DISP0_DATA13  0xf9
> +				MX6QDL_PAD_DISP0_DAT14__IPU2_DISP0_DATA14  0xf9
> +				MX6QDL_PAD_DISP0_DAT15__IPU2_DISP0_DATA15  0xf9
> +			>;
> +		};
> +		pinctrl_regulator_usbhub_pwr: gpio_regulator_usbhub_pwr {
> +			fsl,pins = <
> +				/* USBH_HUB_EN */
> +				MX6QDL_PAD_EIM_D28__GPIO3_IO28 0x0f058
> +			>;
> +		};
> +		pinctrl_reset_moci: gpio_reset_moci {
> +			fsl,pins = <
> +				/* RESET_MOCI control */
> +				MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28 0x0f058
> +			>;
> +		};
> +		pinctrl_touch_int: touch_intgrp {
> +			fsl,pins = <
> +				/* STMPE811 interrupt */
> +				MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
> +			>;
> +		};
> +		pinctrl_usdhc3: usdhc3grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_SD3_CMD__SD3_CMD    0x17059
> +				MX6QDL_PAD_SD3_CLK__SD3_CLK    0x10059
> +				MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
> +				MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
> +				MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
> +				MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
> +				MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
> +				MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
> +				MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
> +				MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
> +			>;
> +		};
> +		pinctrl_usdhc3_100mhz: usdhc3grp-100mhz {
> +			fsl,pins = <
> +				MX6QDL_PAD_SD3_CMD__SD3_CMD 0x170b9
> +				MX6QDL_PAD_SD3_CLK__SD3_CLK 0x100b9
> +				MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x170b9
> +				MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x170b9
> +				MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x170b9
> +				MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x170b9
> +				MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x170b9
> +				MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x170b9
> +				MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x170b9
> +				MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x170b9
> +			>;
> +		};
> +		pinctrl_usdhc3_200mhz: usdhc3grp-200mhz {
> +			fsl,pins = <
> +				MX6QDL_PAD_SD3_CMD__SD3_CMD 0x170f9
> +				MX6QDL_PAD_SD3_CLK__SD3_CLK 0x100f9
> +				MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x170f9
> +				MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x170f9
> +				MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x170f9
> +				MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x170f9
> +				MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x170f9
> +				MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x170f9
> +				MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x170f9
> +				MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x170f9
> +			>;
> +		};
> +	};
> +
> +	ipu1 {
> +		pinctrl_ipu1_lcdif: ipu1lcdifgrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_EIM_A16__IPU1_DI1_DISP_CLK	0x61
> +				/* DE */
> +				MX6QDL_PAD_EIM_DA10__IPU1_DI1_PIN15	0x61
> +				/* HSync */
> +				MX6QDL_PAD_EIM_DA11__IPU1_DI1_PIN02	0x61
> +				/* VSync */
> +				MX6QDL_PAD_EIM_DA12__IPU1_DI1_PIN03	0x61
> +				MX6QDL_PAD_EIM_DA9__IPU1_DISP1_DATA00	0x61
> +				MX6QDL_PAD_EIM_DA8__IPU1_DISP1_DATA01	0x61
> +				MX6QDL_PAD_EIM_DA7__IPU1_DISP1_DATA02	0x61
> +				MX6QDL_PAD_EIM_DA6__IPU1_DISP1_DATA03	0x61
> +				MX6QDL_PAD_EIM_DA5__IPU1_DISP1_DATA04	0x61
> +				MX6QDL_PAD_EIM_DA4__IPU1_DISP1_DATA05	0x61
> +				MX6QDL_PAD_EIM_DA3__IPU1_DISP1_DATA06	0x61
> +				MX6QDL_PAD_EIM_DA2__IPU1_DISP1_DATA07	0x61
> +				MX6QDL_PAD_EIM_DA1__IPU1_DISP1_DATA08	0x61
> +				MX6QDL_PAD_EIM_DA0__IPU1_DISP1_DATA09	0x61
> +				MX6QDL_PAD_EIM_EB1__IPU1_DISP1_DATA10	0x61
> +				MX6QDL_PAD_EIM_EB0__IPU1_DISP1_DATA11	0x61
> +				MX6QDL_PAD_EIM_A17__IPU1_DISP1_DATA12	0x61
> +				MX6QDL_PAD_EIM_A18__IPU1_DISP1_DATA13	0x61
> +				MX6QDL_PAD_EIM_A19__IPU1_DISP1_DATA14	0x61
> +				MX6QDL_PAD_EIM_A20__IPU1_DISP1_DATA15	0x61
> +				MX6QDL_PAD_EIM_A21__IPU1_DISP1_DATA16	0x61
> +				MX6QDL_PAD_EIM_A22__IPU1_DISP1_DATA17	0x61
> +				MX6QDL_PAD_EIM_A23__IPU1_DISP1_DATA18	0x61
> +				MX6QDL_PAD_EIM_A24__IPU1_DISP1_DATA19	0x61
> +				MX6QDL_PAD_EIM_D31__IPU1_DISP1_DATA20	0x61
> +				MX6QDL_PAD_EIM_D30__IPU1_DISP1_DATA21	0x61
> +				MX6QDL_PAD_EIM_D26__IPU1_DISP1_DATA22	0x61
> +				MX6QDL_PAD_EIM_D27__IPU1_DISP1_DATA23	0x61
> +			>;
> +		};
> +		pinctrl_cam_mclk: cam_mclk {
> +			fsl,pins = <
> +				/* CAM sys_mclk */
> +				MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x00b0
> +			>;
> +		};
> +		pinctrl_ipu1_csi0: ipu1csi0grp { /* parallel camera */
> +			fsl,pins = <
> +				MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12  0xb0b1
> +				MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13  0xb0b1
> +				MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14  0xb0b1
> +				MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15  0xb0b1
> +				MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16  0xb0b1
> +				MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17  0xb0b1
> +				MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18  0xb0b1
> +				MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19  0xb0b1
> +				MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0xb0b1
> +				MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC    0xb0b1
> +				MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC   0xb0b1
> +			>;
> +		};
> +	};
> +
> +	pwm {
> +		pinctrl_pwm1: pwm1grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_GPIO_9__PWM1_OUT 0x1b0b1
> +			>;
> +		};
> +		pinctrl_pwm2: pwm2grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_GPIO_1__PWM2_OUT 0x1b0b1
> +			>;
> +		};
> +		pinctrl_pwm3: pwm3grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
> +			>;
> +		};
> +		pinctrl_pwm4: pwm4grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_SD4_DAT2__PWM4_OUT 0x1b0b1
> +			>;
> +		};
> +	};
> +
> +	spdif {
> +		pinctrl_spdif: spdifgrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_GPIO_16__SPDIF_IN  0x1b0b0
> +				MX6QDL_PAD_GPIO_17__SPDIF_OUT 0x1b0b0
> +			>;
> +		};
> +	};
> +
> +	uart1 {
> +		pinctrl_uart1_dce: uart1-dcegrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
> +				MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
> +			>;
> +		};
> +
> +		/* DTE mode */
> +		pinctrl_uart1_dte: uart1-dtegrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_CSI0_DAT10__UART1_RX_DATA 0x1b0b1
> +				MX6QDL_PAD_CSI0_DAT11__UART1_TX_DATA 0x1b0b1
> +				MX6QDL_PAD_EIM_D19__UART1_RTS_B 0x1b0b1
> +				MX6QDL_PAD_EIM_D20__UART1_CTS_B 0x1b0b1
> +			>;
> +		};
> +
> +		/* Additional DTR, DSR, DCD */
> +		pinctrl_uart1_ctrl: uart1-ctrlgrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_EIM_D23__UART1_DCD_B 0x1b0b0
> +				MX6QDL_PAD_EIM_D24__UART1_DTR_B 0x1b0b0
> +				MX6QDL_PAD_EIM_D25__UART1_DSR_B 0x1b0b0
> +			>;
> +		};
> +	};
> +
> +	uart2 {
> +		pinctrl_uart2_dce: uart2-dcegrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_SD4_DAT4__UART2_RX_DATA	0x1b0b1
> +				MX6QDL_PAD_SD4_DAT7__UART2_TX_DATA	0x1b0b1
> +			>;
> +		};
> +
> +		/* DTE mode */
> +		pinctrl_uart2_dte: uart2grp-dte {
> +			fsl,pins = <
> +				MX6QDL_PAD_SD4_DAT4__UART2_TX_DATA	0x1b0b1
> +				MX6QDL_PAD_SD4_DAT7__UART2_RX_DATA	0x1b0b1
> +				MX6QDL_PAD_SD4_DAT6__UART2_RTS_B	0x1b0b1
> +				MX6QDL_PAD_SD4_DAT5__UART2_CTS_B	0x1b0b1
> +			>;
> +		};
> +	};
> +
> +	uart4 {
> +		pinctrl_uart4_dce: uart4-dcegrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
> +				MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
> +			>;
> +		};
> +
> +		/* DTE mode */
> +		pinctrl_uart4_dte: uart4-dtegrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_KEY_COL0__UART4_RX_DATA 0x1b0b1
> +				MX6QDL_PAD_KEY_ROW0__UART4_TX_DATA 0x1b0b1
> +			>;
> +		};
> +	};
> +
> +	uart5 {
> +		pinctrl_uart5_dce: uart5-dcegrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_KEY_COL1__UART5_TX_DATA 0x1b0b1
> +				MX6QDL_PAD_KEY_ROW1__UART5_RX_DATA 0x1b0b1
> +			>;
> +		};
> +
> +		/* DTE mode */
> +		pinctrl_uart5_dte: uart5-dtegrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_KEY_COL1__UART5_RX_DATA 0x1b0b1
> +				MX6QDL_PAD_KEY_ROW1__UART5_TX_DATA 0x1b0b1
> +			>;
> +		};
> +	};
> +
> +	usbh {
> +		pinctrl_regulator_usbh_pwr: gpio_regulator_usbh_pwr {
> +			fsl,pins = <
> +				/* USBH_EN */
> +				MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x0f058
> +			>;
> +		};
> +	};
> +
> +	usbotg {
> +		pinctrl_usbotg: usbotggrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID 0x17059
> +			>;
> +		};
> +		pinctrl_regulator_usbotg_pwr: gpio_regulator_usbotg_pwr {
> +			fsl,pins = <
> +				/* USBO1 power en */
> +				MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x0f058
> +			>;
> +		};
> +	};
> +
> +	usdhc {
> +		pinctrl_mmc_cd: gpio_mmc_cd {
> +			fsl,pins = <
> +				 /* MMC1 CD */
> +				MX6QDL_PAD_DI0_PIN4__GPIO4_IO20 0x000b0
> +			>;
> +		};
> +		pinctrl_sd_cd: gpio_sd_cd {
> +			fsl,pins = <
> +				/* SD1 CD */
> +				MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x000b0
> +			>;
> +		};
> +		pinctrl_usdhc1: usdhc1grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_SD1_CMD__SD1_CMD    0x17071
> +				MX6QDL_PAD_SD1_CLK__SD1_CLK    0x10071
> +				MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17071
> +				MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17071
> +				MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17071
> +				MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17071
> +				MX6QDL_PAD_NANDF_D0__SD1_DATA4 0x17071
> +				MX6QDL_PAD_NANDF_D1__SD1_DATA5 0x17071
> +				MX6QDL_PAD_NANDF_D2__SD1_DATA6 0x17071
> +				MX6QDL_PAD_NANDF_D3__SD1_DATA7 0x17071
> +			>;
> +		};
> +		pinctrl_usdhc2: usdhc2grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_SD2_CMD__SD2_CMD    0x17071
> +				MX6QDL_PAD_SD2_CLK__SD2_CLK    0x10071
> +				MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17071
> +				MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17071
> +				MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17071
> +				MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17071
> +			>;
> +		};
> +	};
> +};
> -- 
> 2.5.0
> 
> 


From sergei.shtylyov at cogentembedded.com  Mon Feb  1 05:33:44 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 1 Feb 2016 16:33:44 +0300
Subject: [PATCH v2 net 5/6] net: mvneta: The mvneta_percpu_elect function
 should be atomic
In-Reply-To: <1454332067-16378-6-git-send-email-gregory.clement@free-electrons.com>
References: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
 <1454332067-16378-6-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <56AF5EB8.8010407@cogentembedded.com>

On 2/1/2016 4:07 PM, Gregory CLEMENT wrote:

> Electing a CPU must be done in an atomic way: it should be done after or
> before the removal/insertion of a CPU and this function is not reentrant.
>
> During the loop of mvneta_percpu_elect we associates the queues to the
> CPUs, if there is a topology change during this loop, then the mapping
> between the CPUs and the queues could be wrong. During this loop the
> interrupt mask is also updating for each CPUs, It should not be changed
> in the same time by other part of the driver.
>
> This patch adds spinlock to create the needed critical sections.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>   drivers/net/ethernet/marvell/mvneta.c | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index 1ed813d478e8..4d40d2fde7ca 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
[...]
> @@ -2855,6 +2859,11 @@ static void mvneta_percpu_elect(struct mvneta_port *pp)
>   {
>   	int online_cpu_idx, max_cpu, cpu, i = 0;
>
> +	/* Electing a CPU must done in an atomic way: it should be

    Must be done.

> +	 * done after or before the removal/insertion of a CPU and
> +	 * this function is not reentrant.
> +	 */
> +	spin_lock(&pp->lock);
>   	online_cpu_idx = pp->rxq_def % num_online_cpus();
>   	max_cpu = num_present_cpus();
>
[...]

MBR, Sergei



From marc.zyngier at arm.com  Mon Feb  1 05:34:16 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 1 Feb 2016 13:34:16 +0000
Subject: [PATCH v2 06/21] arm64: KVM: VHE: Patch out use of HVC
In-Reply-To: <20160201131634.GI1478@cbox>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-7-git-send-email-marc.zyngier@arm.com>
 <20160201131634.GI1478@cbox>
Message-ID: <56AF5ED8.7010303@arm.com>

On 01/02/16 13:16, Christoffer Dall wrote:
> On Mon, Jan 25, 2016 at 03:53:40PM +0000, Marc Zyngier wrote:
>> With VHE, the host never issues an HVC instruction to get into the
>> KVM code, as we can simply branch there.
>>
>> Use runtime code patching to simplify things a bit.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kvm/hyp.S           |  7 +++++++
>>  arch/arm64/kvm/hyp/hyp-entry.S | 38 +++++++++++++++++++++++++++++---------
>>  2 files changed, 36 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
>> index 0ccdcbb..0689a74 100644
>> --- a/arch/arm64/kvm/hyp.S
>> +++ b/arch/arm64/kvm/hyp.S
>> @@ -17,7 +17,9 @@
>>  
>>  #include <linux/linkage.h>
>>  
>> +#include <asm/alternative.h>
>>  #include <asm/assembler.h>
>> +#include <asm/cpufeature.h>
>>  
>>  /*
>>   * u64 kvm_call_hyp(void *hypfn, ...);
>> @@ -38,6 +40,11 @@
>>   * arch/arm64/kernel/hyp_stub.S.
>>   */
>>  ENTRY(kvm_call_hyp)
>> +alternative_if_not ARM64_HAS_VIRT_HOST_EXTN	
>>  	hvc	#0
>>  	ret
>> +alternative_else
>> +	b	__vhe_hyp_call
>> +	nop
>> +alternative_endif
>>  ENDPROC(kvm_call_hyp)
>> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
>> index 93e8d983..9e0683f 100644
>> --- a/arch/arm64/kvm/hyp/hyp-entry.S
>> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
>> @@ -38,6 +38,32 @@
>>  	ldp	x0, x1, [sp], #16
>>  .endm
>>  
>> +.macro do_el2_call
>> +	/*
>> +	 * Shuffle the parameters before calling the function
>> +	 * pointed to in x0. Assumes parameters in x[1,2,3].
>> +	 */
>> +	stp	lr, xzr, [sp, #-16]!
> 
> remind me why this pair isn't just doing "str" instead of "stp" with the
> xzr ?

Because SP has to be aligned on a 16 bytes boundary at all times.

> 
>> +	mov	lr, x0
>> +	mov	x0, x1
>> +	mov	x1, x2
>> +	mov	x2, x3
>> +	blr	lr
>> +	ldp	lr, xzr, [sp], #16
>> +.endm
>> +
>> +ENTRY(__vhe_hyp_call)
>> +	do_el2_call
>> +	/*
>> +	 * We used to rely on having an exception return to get
>> +	 * an implicit isb. In the E2H case, we don't have it anymore.
>> +	 * rather than changing all the leaf functions, just do it here
>> +	 * before returning to the rest of the kernel.
>> +	 */
> 
> why is this not the case with an ISB before do_el2_call then?

That's a good point. I guess the safest thing to do would be to add one,
but looking at the various functions we call, I don't see any that could
go wrong by not having a ISB in their prologue.

Or maybe you've identified such a case?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From leo.yan at linaro.org  Mon Feb  1 05:34:43 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Mon,  1 Feb 2016 21:34:43 +0800
Subject: [PATCH v5 0/4] mailbox: hisilicon: add Hi6220 mailbox driver
Message-ID: <1454333687-20421-1-git-send-email-leo.yan@linaro.org>

Hi6220 mailbox supports up to 32 channels. Each channel is unidirectional
with a maximum message size of 8 words. I/O is performed using register
access (there is no DMA) and the cell raises an interrupt when messages
are received.

This patch series is to implement Hi6220 mailbox driver. It registers
two channels into framework for communication with MCU, one is tx channel
and another is rx channel. Now mailbox driver is used to send message to
MCU to control dynamic voltage and frequency scaling for CPU, GPU and DDR.

Changes from v4:
* According to Jassi's suggestion, using DT binding to register channels
* Change to use operating-points-v2 to register operating points

Changes from v3:
* The patch series for enabling idle state for Hi6220 has reserved memory
  regions, so this series will not include it anymore
* Refined mailbox driver according to Jassi's suggestion;
  Removed kfifo from mailbox driver;
  Removed spinlock for ipc registers accessing, due every channel has its
  own dedicated bit in ipc register and readl/writel will introduce memory
  barrier, so don't need spinlock to protect ipc registers accessing
* After mailbox driver is ready, can use patch 4 to enable CPU's OPPs and
  stub clock driver; finally can enable CPUFreq driver for CPU frequency
  scaling

Changes from v2:
* Get rid of unused memory regions from memory node in DT, and don't use
  reserved-memory node according to Mark and Leif's suggestion; Haojian also
  has updated UEFI for efi memory info

Changes from v1:
* Correct lock usage for SMP scenario

Changes from RFC:
* According to Jassi's review, totally remove the abstract common driver
  layer and only commit driver dedicated for Hi6220
* According to Paul Bolle's review, fix typo issue for Kconfig and remove
  unnecessary dependency with OF and fix minor for mailbox driver
* Refine a little for dts nodes


Leo Yan (4):
  dt-bindings: mailbox: Document Hi6220 mailbox driver
  mailbox: Hi6220: add mailbox driver
  arm64: dts: add mailbox node for Hi6220
  arm64: dts: add Hi6220's stub clock node

 .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  |  90 +++++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi          |  67 ++++
 drivers/mailbox/Kconfig                            |   8 +
 drivers/mailbox/Makefile                           |   2 +
 drivers/mailbox/hi6220-mailbox.c                   | 407 +++++++++++++++++++++
 5 files changed, 574 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
 create mode 100644 drivers/mailbox/hi6220-mailbox.c

-- 
1.9.1



From ard.biesheuvel at linaro.org  Mon Feb  1 05:35:03 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 1 Feb 2016 14:35:03 +0100
Subject: [PATCH v5sub2 0/8] arm64: implement virtual KASLR
In-Reply-To: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <CAKv+Gu-AhLcatkDsQVeoFGJ+pTEwaW1Hy9M-fY1-VWvRc_E47w@mail.gmail.com>

On 1 February 2016 at 14:09, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> At the request of Catalin, this series has been split off from my series
> 'arm64: implement support for KASLR v4' [1]. This sub-series deals with
> creating a relocatable binary, and randomizing the virtual placement of
> the kernel itself, the modules and the linear region based on entropy
> supplied by the bootloader in the /chosen/kaslr-seed DT property.
>
> Changes since v4:
> - add randomization of the linear region, i.e., if the linear region is
>   substantially larger than the space spanned by RAM, the mapping of RAM
>   is moved to a random offset inside the linear region.
> - dropped the CRC check in kaslr_early_init(), since the only code that may
>   modify .data through __fixmap_remap_fdt() is instrumentation that should
>   deal with that correctly (For instance, the branch profiling records taken
>   branches in structs allocated in .data, and these counts will not be reset
>   to 0 between the first and the second call to __mmap_switched())
> - add Mark's ack to patch #4
>

NOTE: I have omitted the relative kallsyms and relative extable
patches, since they already queued in akpm's tree. However, while the
kallsyms patch is merely an optimization, the extable patches are in
fact required for correct operation, since the build time sorting does
not work on absolute extables (this is due to the fact that the
resolution of the relocations is deferred until runtime, and so the
extable addresses are all zero at sorting time)

http://ozlabs.org/~akpm/mmotm/broken-out/extable-add-support-for-relative-extables-to-search-and-sort-routines.patch
http://ozlabs.org/~akpm/mmotm/broken-out/arm64-switch-to-relative-exception-tables.patch



> Patch #1 adds support for resolving cross-module branches via veneers if the
> module is located too far from the target. This should not be necessary in the
> common case even with KASRL enabled, but since the space around the kernel image
> will no longer be strictly reserved for modules, there is a slight chance that
> the region may be exhausted, in which case modules will be moved further away
> from the kernel (and each other)
>
> Patches #2 and #3 deal with the fact that relocations of 64-bit values are
> deferred to runtime when building a PIE executable, and some values are required
> before the relocation routine executes (either in the code, or as an externally
> visible constant in the Image header)
>
> Patch #4 rehuffles asm/elf.h so we can use its preprocessor constants in head.S
>
> Patch #5 and #6 implement building vmlinux as a PIE (Position Independent
> Executable) binary, which is emitted with relocation information that is
> processed by the program itself in the early boot code.
>
> Patch #7 implements KASLR, i.e., CONFIG_RANDOMIZE_BASE for the core kernel and
> for the module region.
>
> Patch #8 implements KASLR for the linear region.
>
> [1] http://thread.gmane.org/gmane.linux.kernel/2135931
>
> Ard Biesheuvel (8):
>   arm64: add support for module PLTs
>   arm64: avoid R_AARCH64_ABS64 relocations for Image header fields
>   arm64: avoid dynamic relocations in early boot code
>   arm64: make asm/elf.h available to asm files
>   scripts/sortextable: add support for ET_DYN binaries
>   arm64: add support for building vmlinux as a relocatable PIE binary
>   arm64: add support for kernel ASLR
>   arm64: kaslr: randomize the linear region
>
>  arch/arm64/Kconfig                 |  34 ++++
>  arch/arm64/Makefile                |  10 +-
>  arch/arm64/include/asm/assembler.h |  11 ++
>  arch/arm64/include/asm/elf.h       |  24 ++-
>  arch/arm64/include/asm/memory.h    |   5 +-
>  arch/arm64/include/asm/module.h    |  11 ++
>  arch/arm64/kernel/Makefile         |   2 +
>  arch/arm64/kernel/efi-entry.S      |   2 +-
>  arch/arm64/kernel/head.S           | 128 +++++++++++--
>  arch/arm64/kernel/image.h          |  32 ++--
>  arch/arm64/kernel/kaslr.c          | 143 ++++++++++++++
>  arch/arm64/kernel/module-plts.c    | 201 ++++++++++++++++++++
>  arch/arm64/kernel/module.c         |  20 +-
>  arch/arm64/kernel/module.lds       |   3 +
>  arch/arm64/kernel/setup.c          |  29 +++
>  arch/arm64/kernel/vmlinux.lds.S    |  16 ++
>  arch/arm64/mm/init.c               |  22 ++-
>  arch/arm64/mm/mmu.c                |  33 +++-
>  scripts/sortextable.c              |   8 +-
>  19 files changed, 672 insertions(+), 62 deletions(-)
>  create mode 100644 arch/arm64/kernel/kaslr.c
>  create mode 100644 arch/arm64/kernel/module-plts.c
>  create mode 100644 arch/arm64/kernel/module.lds
>
> --
> 2.5.0
>


From leo.yan at linaro.org  Mon Feb  1 05:34:44 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Mon,  1 Feb 2016 21:34:44 +0800
Subject: [PATCH v5 1/4] dt-bindings: mailbox: Document Hi6220 mailbox driver
In-Reply-To: <1454333687-20421-1-git-send-email-leo.yan@linaro.org>
References: <1454333687-20421-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1454333687-20421-2-git-send-email-leo.yan@linaro.org>

Document DT binding for Hisilicon Hi6220 mailbox driver.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  | 90 ++++++++++++++++++++++
 1 file changed, 90 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt

diff --git a/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
new file mode 100644
index 0000000..96e6acc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
@@ -0,0 +1,90 @@
+Hisilicon Hi6220 Mailbox Driver
+===============================
+
+Hisilicon Hi6220 mailbox supports up to 32 channels. Each channel
+is unidirectional with a maximum message size of 8 words. I/O is
+performed using register access (there is no DMA) and the cell
+raises an interrupt when messages are received.
+
+Mailbox Device Node:
+====================
+
+Required properties:
+--------------------
+- compatible:		Shall be "hisilicon,hi6220-mbox"
+- reg:			Contains the mailbox register address range (base
+			address and length); the first item is for IPC
+			registers, the second item is shared buffer for
+			slots.
+- #mbox-cells		Common mailbox binding property to identify the number
+			of cells required for the mailbox specifier. Should be 1.
+- interrupts:		Contains the interrupt information for the mailbox
+			device. The format is dependent on which interrupt
+			controller the SoCs use.
+
+Optional Properties:
+--------------------
+- hi6220,mbox-tx-noirq: Flag to allow the client user of this mailbox driver
+			to send messages without triggering a TX completion
+			interrupt.
+
+Child Nodes:
+============
+A child node is used for representing the actual sub-mailbox device that is
+used for the communication between the host processor and a remote processor.
+Each child node should have a unique node name across all the different
+mailbox device nodes.
+
+Required properties:
+--------------------
+- hi6220,mbox-tx:	sub-mailbox descriptor property defining Tx channel
+- hi6220,mbox-rx:	sub-mailbox descriptor property defining Rx channel
+
+Sub-mailbox Descriptor Data
+---------------------------
+Each of the above hi6220,mbox-tx and hi6220,mbox-rx properties should have 3
+cells of data that represent the following:
+    Cell #1 (slot_id) - mailbox slot id used either for transmitting
+                        (hi6220,mbox-tx) or for receiving (hi6220,mbox-rx)
+    Cell #2 (dst_irq) - irq identifier index number which used by MCU.
+    Cell #3 (ack_irq) - irq identifier index number with generating a tx/rx
+                        interrupt to application processor, mailbox driver
+                        used this id to acknowledge interrupt.
+
+Example:
+--------
+
+	mailbox: mailbox at F7510000 {
+		#mbox-cells = <1>;
+		compatible = "hisilicon,hi6220-mbox";
+		reg = <0x0 0xF7510000 0x0 0x1000>, /* IPC_S */
+		      <0x0 0x06DFF800 0x0 0x0800>; /* Mailbox */
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+		mbox_stub_clock: mbox_stub_clock {
+			hi6220,mbox-rx = <0 1 10>;
+			hi6220,mbox-tx = <1 0 11>;
+		};
+	};
+
+
+Mailbox client
+===============
+
+"mboxes" and the optional "mbox-names" (please see
+Documentation/devicetree/bindings/mailbox/mailbox.txt for details). Each value
+of the mboxes property should contain a phandle to the mailbox controller
+device node and second argument is the channel index. It must be 0 (hardware
+support only one channel). The equivalent "mbox-names" property value can be
+used to give a name to the communication channel to be used by the client user.
+
+Example:
+--------
+
+	stub_clock: stub_clock {
+		compatible = "hisilicon,hi6220-stub-clk";
+		hisilicon,hi6220-clk-sram = <&sram>;
+		#clock-cells = <1>;
+		mbox-names = "mbox-tx";
+		mboxes = <&mailbox 1>;
+	};
-- 
1.9.1



From leo.yan at linaro.org  Mon Feb  1 05:34:45 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Mon,  1 Feb 2016 21:34:45 +0800
Subject: [PATCH v5 2/4] mailbox: Hi6220: add mailbox driver
In-Reply-To: <1454333687-20421-1-git-send-email-leo.yan@linaro.org>
References: <1454333687-20421-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1454333687-20421-3-git-send-email-leo.yan@linaro.org>

Add driver for Hi6220 mailbox, the mailbox communicates with MCU; for
sending data, it can support two methods for low level implementation:
one is to use interrupt as acknowledge, another is automatic mode which
without any acknowledge. These two methods have been supported in the
driver. For receiving data, it will depend on the interrupt to notify
the channel has incoming message.

Now mailbox driver is used to send message to MCU to control dynamic
voltage and frequency scaling for CPU, GPU and DDR.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 drivers/mailbox/Kconfig          |   8 +
 drivers/mailbox/Makefile         |   2 +
 drivers/mailbox/hi6220-mailbox.c | 407 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 417 insertions(+)
 create mode 100644 drivers/mailbox/hi6220-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 546d05f..b8bbeb0 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -78,6 +78,14 @@ config STI_MBOX
 	  Mailbox implementation for STMicroelectonics family chips with
 	  hardware for interprocessor communication.
 
+config HI6220_MBOX
+	tristate "Hi6220 Mailbox"
+	depends on ARCH_HISI
+	help
+	  An implementation of the hi6220 mailbox. It is used to send message
+	  between application processors and MCU. Say Y here if you want to
+	  build Hi6220 mailbox controller driver.
+
 config MAILBOX_TEST
 	tristate "Mailbox Test Client"
 	depends on OF
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 92435ef..565adda 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -17,3 +17,5 @@ obj-$(CONFIG_ALTERA_MBOX)	+= mailbox-altera.o
 obj-$(CONFIG_BCM2835_MBOX)	+= bcm2835-mailbox.o
 
 obj-$(CONFIG_STI_MBOX)		+= mailbox-sti.o
+
+obj-$(CONFIG_HI6220_MBOX)	+= hi6220-mailbox.o
diff --git a/drivers/mailbox/hi6220-mailbox.c b/drivers/mailbox/hi6220-mailbox.c
new file mode 100644
index 0000000..42db915
--- /dev/null
+++ b/drivers/mailbox/hi6220-mailbox.c
@@ -0,0 +1,407 @@
+/*
+ * Hisilicon's Hi6220 mailbox driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ * Copyright (c) 2015 Linaro Limited.
+ *
+ * Author: Leo Yan <leo.yan at linaro.org>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kfifo.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#define MBOX_CHAN_MAX			32
+
+#define MBOX_RX				0x0
+#define MBOX_TX				0x1
+
+/* Mailbox message length: 8 words */
+#define MBOX_MSG_LEN			8
+
+/* Mailbox Registers */
+#define MBOX_OFF(m)			(0x40 * (m))
+#define MBOX_MODE_REG(m)		(MBOX_OFF(m) + 0x0)
+#define MBOX_DATA_REG(m)		(MBOX_OFF(m) + 0x4)
+
+#define MBOX_STATE_MASK			(0xF << 4)
+#define MBOX_STATE_IDLE			(0x1 << 4)
+#define MBOX_STATE_TX			(0x2 << 4)
+#define MBOX_STATE_RX			(0x4 << 4)
+#define MBOX_STATE_ACK			(0x8 << 4)
+#define MBOX_ACK_CONFIG_MASK		(0x1 << 0)
+#define MBOX_ACK_AUTOMATIC		(0x1 << 0)
+#define MBOX_ACK_IRQ			(0x0 << 0)
+
+/* IPC registers */
+#define ACK_INT_RAW_REG(i)		((i) + 0x400)
+#define ACK_INT_MSK_REG(i)		((i) + 0x404)
+#define ACK_INT_STAT_REG(i)		((i) + 0x408)
+#define ACK_INT_CLR_REG(i)		((i) + 0x40c)
+#define ACK_INT_ENA_REG(i)		((i) + 0x500)
+#define ACK_INT_DIS_REG(i)		((i) + 0x504)
+#define DST_INT_RAW_REG(i)		((i) + 0x420)
+
+
+struct hi6220_mbox_chan {
+
+	/*
+	 * Description for channel's hardware info:
+	 *  - direction: tx or rx
+	 *  - dst irq: peer core's irq number
+	 *  - ack irq: local irq number
+	 *  - slot number
+	 */
+	unsigned int dir, dst_irq, ack_irq;
+	unsigned int slot;
+
+	struct hi6220_mbox *parent;
+};
+
+struct hi6220_mbox {
+	struct device *dev;
+
+	int irq;
+
+	/* flag of enabling tx's irq mode */
+	bool tx_irq_mode;
+
+	/* region for ipc event */
+	void __iomem *ipc;
+
+	/* region for mailbox */
+	void __iomem *base;
+
+	unsigned int chan_num;
+	struct hi6220_mbox_chan *mchan;
+
+	void *irq_map_chan[MBOX_CHAN_MAX];
+	struct mbox_chan *chan;
+	struct mbox_controller controller;
+};
+
+static void mbox_set_state(struct hi6220_mbox *mbox,
+			   unsigned int slot, u32 val)
+{
+	u32 status;
+
+	status = readl(mbox->base + MBOX_MODE_REG(slot));
+	status = (status & ~MBOX_STATE_MASK) | val;
+	writel(status, mbox->base + MBOX_MODE_REG(slot));
+}
+
+static void mbox_set_mode(struct hi6220_mbox *mbox,
+			  unsigned int slot, u32 val)
+{
+	u32 mode;
+
+	mode = readl(mbox->base + MBOX_MODE_REG(slot));
+	mode = (mode & ~MBOX_ACK_CONFIG_MASK) | val;
+	writel(mode, mbox->base + MBOX_MODE_REG(slot));
+}
+
+static bool hi6220_mbox_last_tx_done(struct mbox_chan *chan)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+	u32 state;
+
+	/* Only set idle state for polling mode */
+	BUG_ON(mbox->tx_irq_mode);
+
+	state = readl(mbox->base + MBOX_MODE_REG(mchan->slot));
+	return ((state & MBOX_STATE_MASK) == MBOX_STATE_IDLE);
+}
+
+static int hi6220_mbox_send_data(struct mbox_chan *chan, void *msg)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+	unsigned int slot = mchan->slot;
+	u32 *buf = msg;
+	int i;
+
+	mbox_set_state(mbox, slot, MBOX_STATE_TX);
+
+	if (mbox->tx_irq_mode)
+		mbox_set_mode(mbox, slot, MBOX_ACK_IRQ);
+	else
+		mbox_set_mode(mbox, slot, MBOX_ACK_AUTOMATIC);
+
+	for (i = 0; i < MBOX_MSG_LEN; i++)
+		writel(buf[i], mbox->base + MBOX_DATA_REG(slot) + i * 4);
+
+	/* trigger remote request */
+	writel(BIT(mchan->dst_irq), DST_INT_RAW_REG(mbox->ipc));
+	return 0;
+}
+
+static irqreturn_t hi6220_mbox_interrupt(int irq, void *p)
+{
+	struct hi6220_mbox *mbox = p;
+	struct hi6220_mbox_chan *mchan;
+	struct mbox_chan *chan;
+	unsigned int state, intr_bit, i;
+	u32 msg[MBOX_MSG_LEN];
+
+	state = readl(ACK_INT_STAT_REG(mbox->ipc));
+	if (!state) {
+		dev_warn(mbox->dev, "%s: spurious interrupt\n",
+			 __func__);
+		return IRQ_HANDLED;
+	}
+
+	while (state) {
+		intr_bit = __ffs(state);
+		state &= (state - 1);
+
+		chan = mbox->irq_map_chan[intr_bit];
+		if (!chan) {
+			dev_warn(mbox->dev, "%s: unexpected irq vector %d\n",
+				 __func__, intr_bit);
+			continue;
+		}
+
+		mchan = chan->con_priv;
+		if (mchan->dir == MBOX_TX)
+			mbox_chan_txdone(chan, 0);
+		else {
+			for (i = 0; i < MBOX_MSG_LEN; i++)
+				msg[i] = readl(mbox->base +
+					MBOX_DATA_REG(mchan->slot) + i * 4);
+
+			mbox_chan_received_data(chan, (void *)msg);
+		}
+
+		/* clear IRQ source */
+		writel(BIT(mchan->ack_irq), ACK_INT_CLR_REG(mbox->ipc));
+		mbox_set_state(mbox, mchan->slot, MBOX_STATE_IDLE);
+	}
+
+	return IRQ_HANDLED;
+}
+
+static int hi6220_mbox_startup(struct mbox_chan *chan)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+
+	mbox->irq_map_chan[mchan->ack_irq] = (void *)chan;
+
+	/* enable interrupt */
+	writel(BIT(mchan->ack_irq), ACK_INT_ENA_REG(mbox->ipc));
+	return 0;
+}
+
+static void hi6220_mbox_shutdown(struct mbox_chan *chan)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+
+	/* disable interrupt */
+	writel(BIT(mchan->ack_irq), ACK_INT_DIS_REG(mbox->ipc));
+	mbox->irq_map_chan[mchan->ack_irq] = NULL;
+}
+
+static struct mbox_chan_ops hi6220_mbox_chan_ops = {
+	.send_data    = hi6220_mbox_send_data,
+	.startup      = hi6220_mbox_startup,
+	.shutdown     = hi6220_mbox_shutdown,
+	.last_tx_done = hi6220_mbox_last_tx_done,
+};
+
+static int hi6220_mbox_init_hw(struct hi6220_mbox *mbox,
+			       struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	struct device_node *child;
+	struct hi6220_mbox_chan *mchan = mbox->mchan;
+	u32 count;
+	u32 tmp[3];
+	int idx, i;
+	int ret;
+
+	for (i = 0; i < mbox->chan_num; i++) {
+		mbox->chan[i].con_priv = &mchan[i];
+		mbox->irq_map_chan[i] = NULL;
+
+		mchan[i].parent = mbox;
+		mchan[i].slot   = i;
+	}
+
+	count = of_get_available_child_count(node);
+	if (!count) {
+		dev_err(&pdev->dev, "no available mbox devices found\n");
+		return -ENODEV;
+	}
+
+	child = NULL;
+	for (i = 0; i < count; i++) {
+		child = of_get_next_available_child(node, child);
+		ret = of_property_read_u32_array(child, "hi6220,mbox-tx",
+						 tmp, ARRAY_SIZE(tmp));
+		if (!ret) {
+			idx = tmp[0];
+			mchan[idx].dir     = MBOX_TX,
+			mchan[idx].dst_irq = tmp[1];
+			mchan[idx].ack_irq = tmp[2];
+		}
+
+		ret = of_property_read_u32_array(child, "hi6220,mbox-rx",
+						 tmp, ARRAY_SIZE(tmp));
+		if (!ret) {
+			idx = tmp[0];
+			mchan[idx].dir     = MBOX_RX,
+			mchan[idx].dst_irq = tmp[1];
+			mchan[idx].ack_irq = tmp[2];
+		}
+	}
+
+	/* mask and clear all interrupt vectors */
+	writel(0x0,  ACK_INT_MSK_REG(mbox->ipc));
+	writel(~0x0, ACK_INT_CLR_REG(mbox->ipc));
+
+	/* use interrupt for tx's ack */
+	if (of_find_property(node, "hi6220,mbox-tx-noirq", NULL))
+		mbox->tx_irq_mode = false;
+	else
+		mbox->tx_irq_mode = true;
+
+	return 0;
+}
+
+static const struct of_device_id hi6220_mbox_of_match[] = {
+	{ .compatible = "hisilicon,hi6220-mbox", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, hi6220_mbox_of_match);
+
+static int hi6220_mbox_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct hi6220_mbox *mbox;
+	struct resource *res;
+	int err;
+
+	mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+	if (!mbox)
+		return -ENOMEM;
+
+	mbox->dev = dev;
+	mbox->chan_num = MBOX_CHAN_MAX;
+	mbox->mchan = devm_kzalloc(dev,
+		mbox->chan_num * sizeof(*mbox->mchan), GFP_KERNEL);
+	if (!mbox->mchan)
+		return -ENOMEM;
+
+	mbox->chan = devm_kzalloc(dev,
+		mbox->chan_num * sizeof(*mbox->chan), GFP_KERNEL);
+	if (!mbox->chan)
+		return -ENOMEM;
+
+	mbox->irq = platform_get_irq(pdev, 0);
+	if (mbox->irq < 0)
+		return mbox->irq;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mbox->ipc = devm_ioremap_resource(dev, res);
+	if (IS_ERR(mbox->ipc)) {
+		dev_err(dev, "ioremap ipc failed\n");
+		return PTR_ERR(mbox->ipc);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	mbox->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(mbox->base)) {
+		dev_err(dev, "ioremap buffer failed\n");
+		return PTR_ERR(mbox->base);
+	}
+
+	err = devm_request_irq(dev, mbox->irq, hi6220_mbox_interrupt, 0,
+			dev_name(dev), mbox);
+	if (err) {
+		dev_err(dev, "Failed to register a mailbox IRQ handler: %d\n",
+			err);
+		return -ENODEV;
+	}
+
+	/* init hardware parameters */
+	err = hi6220_mbox_init_hw(mbox, pdev);
+	if (err) {
+		dev_err(dev, "Failed to init mbox hardware channels: %d\n",
+			err);
+		return -ENODEV;
+	}
+
+	mbox->controller.dev = dev;
+	mbox->controller.chans = &mbox->chan[0];
+	mbox->controller.num_chans = mbox->chan_num;
+	mbox->controller.ops = &hi6220_mbox_chan_ops;
+
+	if (mbox->tx_irq_mode)
+		mbox->controller.txdone_irq = true;
+	else {
+		mbox->controller.txdone_poll = true;
+		mbox->controller.txpoll_period = 5;
+	}
+
+	err = mbox_controller_register(&mbox->controller);
+	if (err) {
+		dev_err(dev, "Failed to register mailbox %d\n", err);
+		return err;
+	}
+
+	platform_set_drvdata(pdev, mbox);
+	dev_info(dev, "Mailbox enabled\n");
+	return 0;
+}
+
+static int hi6220_mbox_remove(struct platform_device *pdev)
+{
+	struct hi6220_mbox *mbox = platform_get_drvdata(pdev);
+
+	mbox_controller_unregister(&mbox->controller);
+	return 0;
+}
+
+static struct platform_driver hi6220_mbox_driver = {
+	.driver = {
+		.name = "hi6220-mbox",
+		.owner = THIS_MODULE,
+		.of_match_table = hi6220_mbox_of_match,
+	},
+	.probe	= hi6220_mbox_probe,
+	.remove	= hi6220_mbox_remove,
+};
+
+static int __init hi6220_mbox_init(void)
+{
+	return platform_driver_register(&hi6220_mbox_driver);
+}
+core_initcall(hi6220_mbox_init);
+
+static void __exit hi6220_mbox_exit(void)
+{
+	platform_driver_unregister(&hi6220_mbox_driver);
+}
+module_exit(hi6220_mbox_exit);
+
+MODULE_AUTHOR("Leo Yan <leo.yan at linaro.org>");
+MODULE_DESCRIPTION("Hi6220 mailbox driver");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1



From leo.yan at linaro.org  Mon Feb  1 05:34:46 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Mon,  1 Feb 2016 21:34:46 +0800
Subject: [PATCH v5 3/4] arm64: dts: add mailbox node for Hi6220
In-Reply-To: <1454333687-20421-1-git-send-email-leo.yan@linaro.org>
References: <1454333687-20421-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1454333687-20421-4-git-send-email-leo.yan@linaro.org>

This patch add device mailbox node for Hi6220 in DT.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 2585236..be3d962 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -249,5 +249,17 @@
 			clocks = <&ao_ctrl 27>;
 			clock-names = "apb_pclk";
 		};
+
+		mailbox: mailbox at f7510000 {
+			#mbox-cells = <1>;
+			compatible = "hisilicon,hi6220-mbox";
+			reg = <0x0 0xf7510000 0x0 0x1000>, /* IPC_S */
+			      <0x0 0x06dff800 0x0 0x0800>; /* Mailbox buffer */
+			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+			mbox_stub_clock: mbox_stub_clock {
+				hi6220,mbox-rx = <0 1 10>;
+				hi6220,mbox-tx = <1 0 11>;
+			};
+		};
 	};
 };
-- 
1.9.1



From leo.yan at linaro.org  Mon Feb  1 05:34:47 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Mon,  1 Feb 2016 21:34:47 +0800
Subject: [PATCH v5 4/4] arm64: dts: add Hi6220's stub clock node
In-Reply-To: <1454333687-20421-1-git-send-email-leo.yan@linaro.org>
References: <1454333687-20421-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1454333687-20421-5-git-send-email-leo.yan@linaro.org>

Enable SRAM node and stub clock node for Hi6220, which will use mailbox
channel 0 for CPU's frequency change.

Furthermore, add the CPU clock phandle in CPU's node and using
operating-points-v2 to register operating points. So can be used by
cpufreq-dt driver.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 55 +++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index be3d962..d46820a 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -81,6 +81,11 @@
 			device_type = "cpu";
 			reg = <0x0 0x0>;
 			enable-method = "psci";
+			clocks = <&stub_clock 0>;
+			operating-points-v2 = <&cpu_opp_table>;
+			cooling-min-level = <4>;
+			cooling-max-level = <0>;
+			#cooling-cells = <2>; /* min followed by max */
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -89,6 +94,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x1>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -97,6 +103,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x2>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -105,6 +112,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x3>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -113,6 +121,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x100>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -121,6 +130,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x101>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -129,6 +139,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x102>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -137,10 +148,42 @@
 			device_type = "cpu";
 			reg = <0x0 0x103>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 	};
 
+	cpu_opp_table: cpu_opp_table {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp00 {
+			opp-hz = /bits/ 64 <208000000>;
+			opp-microvolt = <1040000>;
+			clock-latency-ns = <500000>;
+		};
+		opp01 {
+			opp-hz = /bits/ 64 <432000000>;
+			opp-microvolt = <1040000>;
+			clock-latency-ns = <500000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <729000000>;
+			opp-microvolt = <1090000>;
+			clock-latency-ns = <500000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <960000000>;
+			opp-microvolt = <1180000>;
+			clock-latency-ns = <500000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt = <1330000>;
+			clock-latency-ns = <500000>;
+		};
+	};
+
 	gic: interrupt-controller at f6801000 {
 		compatible = "arm,gic-400";
 		reg = <0x0 0xf6801000 0 0x1000>, /* GICD */
@@ -168,6 +211,11 @@
 		#size-cells = <2>;
 		ranges;
 
+		sram: sram at fff80000 {
+			compatible = "hisilicon,hi6220-sramctrl", "syscon";
+			reg = <0x0 0xfff80000 0x0 0x12000>;
+		};
+
 		ao_ctrl: ao_ctrl at f7800000 {
 			compatible = "hisilicon,hi6220-aoctrl", "syscon";
 			reg = <0x0 0xf7800000 0x0 0x2000>;
@@ -193,6 +241,13 @@
 			#clock-cells = <1>;
 		};
 
+		stub_clock: stub_clock {
+			compatible = "hisilicon,hi6220-stub-clk";
+			hisilicon,hi6220-clk-sram = <&sram>;
+			#clock-cells = <1>;
+			mboxes = <&mailbox 1>;
+		};
+
 		uart0: uart at f8015000 {	/* console */
 			compatible = "arm,pl011", "arm,primecell";
 			reg = <0x0 0xf8015000 0x0 0x1000>;
-- 
1.9.1



From gregory.clement at free-electrons.com  Mon Feb  1 05:37:03 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 01 Feb 2016 14:37:03 +0100
Subject: [PATCH v2 net 3/6] net: mvneta: Remove unused code
In-Reply-To: <56AF5E55.9030603@cogentembedded.com> (Sergei Shtylyov's message
 of "Mon, 1 Feb 2016 16:32:05 +0300")
References: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
 <1454332067-16378-4-git-send-email-gregory.clement@free-electrons.com>
 <56AF5E55.9030603@cogentembedded.com>
Message-ID: <87d1sg7ds0.fsf@free-electrons.com>

Hi Sergei,
 
 On lun., f?vr. 01 2016, Sergei Shtylyov <sergei.shtylyov at cogentembedded.com> wrote:

> Hello.
>
> On 2/1/2016 4:07 PM, Gregory CLEMENT wrote:
>
>> Since the commit 2dcf75e2793c ("net: mvneta: Associate RX queues with
>> each CPU") all the percpu irq are used and unmask at initialization, so
>
>    Unmasked, you mean?

yes and disabled would be more appropriate actually.

>
>> there is no point to unmask them first.
>
>    Mask, maybe (looking at the patch)?

not mask, but here again disable would be more appropriate. The code
removed disables the interrupt.


Thanks,

Gregory

>
>> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
>> ---
>>   drivers/net/ethernet/marvell/mvneta.c | 8 --------
>>   1 file changed, 8 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
>> index 3d6e3137f305..861b7e0d7d5f 100644
>> --- a/drivers/net/ethernet/marvell/mvneta.c
>> +++ b/drivers/net/ethernet/marvell/mvneta.c
>> @@ -3009,14 +3009,6 @@ static int mvneta_open(struct net_device *dev)
>>   		goto err_cleanup_txqs;
>>   	}
>>
>> -	/* Even though the documentation says that request_percpu_irq
>> -	 * doesn't enable the interrupts automatically, it actually
>> -	 * does so on the local CPU.
>> -	 *
>> -	 * Make sure it's disabled.
>> -	 */
>> -	mvneta_percpu_disable(pp);
>> -
>>   	/* Enable per-CPU interrupt on all the CPU to handle our RX
>>   	 * queue interrupts
>>   	 */
>
> MBR, Sergei
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From marc.zyngier at arm.com  Mon Feb  1 05:38:57 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 1 Feb 2016 13:38:57 +0000
Subject: [PATCH v2 07/21] arm64: KVM: VHE: Patch out kern_hyp_va
In-Reply-To: <20160201132042.GJ1478@cbox>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-8-git-send-email-marc.zyngier@arm.com>
 <20160201132042.GJ1478@cbox>
Message-ID: <56AF5FF1.4010701@arm.com>

On 01/02/16 13:20, Christoffer Dall wrote:
> On Mon, Jan 25, 2016 at 03:53:41PM +0000, Marc Zyngier wrote:
>> The kern_hyp_va macro is pretty meaninless with VHE, as there is
>> only one mapping - the kernel one.
>>
>> In order to keep the code readable and efficient, use runtime
>> patching to replace the 'and' instruction used to compute the VA
>> with a 'nop'.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/include/asm/kvm_mmu.h | 11 ++++++++++-
>>  arch/arm64/kvm/hyp/hyp.h         | 25 ++++++++++++++++++++++---
>>  2 files changed, 32 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
>> index d3e6d7b..62f0d14 100644
>> --- a/arch/arm64/include/asm/kvm_mmu.h
>> +++ b/arch/arm64/include/asm/kvm_mmu.h
>> @@ -23,13 +23,16 @@
>>  #include <asm/cpufeature.h>
>>  
>>  /*
>> - * As we only have the TTBR0_EL2 register, we cannot express
>> + * As ARMv8.0 only has the TTBR0_EL2 register, we cannot express
>>   * "negative" addresses. This makes it impossible to directly share
>>   * mappings with the kernel.
>>   *
>>   * Instead, give the HYP mode its own VA region at a fixed offset from
>>   * the kernel by just masking the top bits (which are all ones for a
>>   * kernel address).
>> + *
>> + * ARMv8.1 (using VHE) does have a TTBR1_EL2, and doesn't use these
>> + * macros (the entire kernel runs at EL2).
>>   */
>>  #define HYP_PAGE_OFFSET_SHIFT	VA_BITS
>>  #define HYP_PAGE_OFFSET_MASK	((UL(1) << HYP_PAGE_OFFSET_SHIFT) - 1)
>> @@ -56,6 +59,8 @@
>>  
>>  #ifdef __ASSEMBLY__
>>  
>> +#include <asm/alternative.h>
>> +#include <asm/cpufeature.h>
>>  #include <asm/kvm_arm.h>
>>  
>>  .macro setup_vtcr tmp1, tmp2
>> @@ -84,7 +89,11 @@
>>   * reg: VA to be converted.
>>   */
>>  .macro kern_hyp_va	reg
>> +alternative_if_not ARM64_HAS_VIRT_HOST_EXTN	
>>  	and	\reg, \reg, #HYP_PAGE_OFFSET_MASK
>> +alternative_else
>> +	nop
>> +alternative_endif
>>  .endm
>>  
>>  #else
>> diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
>> index fb27517..fc502f3 100644
>> --- a/arch/arm64/kvm/hyp/hyp.h
>> +++ b/arch/arm64/kvm/hyp/hyp.h
>> @@ -25,9 +25,28 @@
>>  
>>  #define __hyp_text __section(.hyp.text) notrace
>>  
>> -#define kern_hyp_va(v) (typeof(v))((unsigned long)(v) & HYP_PAGE_OFFSET_MASK)
>> -#define hyp_kern_va(v) (typeof(v))((unsigned long)(v) - HYP_PAGE_OFFSET \
>> -						      + PAGE_OFFSET)
>> +static inline unsigned long __kern_hyp_va(unsigned long v)
>> +{
>> +	asm volatile(ALTERNATIVE("and %0, %0, %1",
>> +				 "nop",
>> +				 ARM64_HAS_VIRT_HOST_EXTN)
>> +		     : "+r" (v) : "i" (HYP_PAGE_OFFSET_MASK));
>> +	return v;
>> +}
>> +
>> +#define kern_hyp_va(v) (typeof(v))(__kern_hyp_va((unsigned long)(v)))
>> +
>> +static inline unsigned long __hyp_kern_va(unsigned long v)
>> +{
>> +	u64 offset = PAGE_OFFSET - HYP_PAGE_OFFSET;
>> +	asm volatile(ALTERNATIVE("add %0, %0, %1",
>> +				 "nop",
>> +				 ARM64_HAS_VIRT_HOST_EXTN)
>> +		     : "+r" (v) : "r" (offset));
>> +	return v;
>> +}
>> +
>> +#define hyp_kern_va(v) (typeof(v))(__hyp_kern_va((unsigned long)(v)))
> 
> why do we need this casting of values instead of just defining these
> inlines and calling them directly with proper typing?

We commonly pass both pointers and unsigned long to this helper. Do you
really want a separate helper for each type instead of one that does it all?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From catalin.marinas at arm.com  Mon Feb  1 05:41:02 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 1 Feb 2016 13:41:02 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <CAKv+Gu-4FAn-f3dTKPZbiNcs_kCFN+PuxQkHwTdWN24VWhrrOA@mail.gmail.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <20160201122444.GD15514@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-4FAn-f3dTKPZbiNcs_kCFN+PuxQkHwTdWN24VWhrrOA@mail.gmail.com>
Message-ID: <20160201134102.GE15514@e104818-lin.cambridge.arm.com>

On Mon, Feb 01, 2016 at 01:27:59PM +0100, Ard Biesheuvel wrote:
> On 1 February 2016 at 13:24, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Mon, Feb 01, 2016 at 11:54:52AM +0100, Ard Biesheuvel wrote:
> >> --- a/arch/arm64/mm/mmu.c
> >> +++ b/arch/arm64/mm/mmu.c
> >> @@ -53,6 +53,10 @@ u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
> >>  unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_bss;
> >>  EXPORT_SYMBOL(empty_zero_page);
> >>
> >> +static pte_t bm_pte[PTRS_PER_PTE] __page_aligned_bss;
> >> +static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss;
> >> +static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss;
> >
> > I applied a fixup locally to keep the compiler quiet:
> >
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -57,8 +57,8 @@ unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_
> >  EXPORT_SYMBOL(empty_zero_page);
> >
> >  static pte_t bm_pte[PTRS_PER_PTE] __page_aligned_bss;
> > -static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss;
> > -static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss;
> > +static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss __maybe_unused;
> > +static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss __maybe_unused;
> 
> Ah yes, I dropped a memblock_free() against bm_pud in
> early_fixmap_init(), since it occurred before the actual reservation,
> so bm_pud may never be referenced. For bm_pmd, it should not be
> required afaict.
> 
> If you prefer, I can keep the original code here:
> 
> #if CONFIG_PGTABLE_LEVELS > 2
> static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss;
> #endif
> #if CONFIG_PGTABLE_LEVELS > 3
> static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss;
> #endif

Looking at the CodingStyle doc, __maybe_unused is preferred, so I'll
just keep the fixup.

-- 
Catalin


From marc.zyngier at arm.com  Mon Feb  1 05:42:34 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 1 Feb 2016 13:42:34 +0000
Subject: [PATCH v2 02/21] arm64: Allow the arch timer to use the HYP timer
In-Reply-To: <20160201122907.GD1478@cbox>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-3-git-send-email-marc.zyngier@arm.com>
 <20160201122907.GD1478@cbox>
Message-ID: <56AF60CA.6040709@arm.com>

On 01/02/16 12:29, Christoffer Dall wrote:
> On Mon, Jan 25, 2016 at 03:53:36PM +0000, Marc Zyngier wrote:
>> With the ARMv8.1 VHE, the kernel can run in HYP mode, and thus
>> use the HYP timer instead of the normal guest timer in a mostly
>> transparent way, except for the interrupt line.
>>
>> This patch reworks the arch timer code to allow the selection of
>> the HYP PPI, possibly falling back to the guest timer if not
>> available.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  drivers/clocksource/arm_arch_timer.c | 96 ++++++++++++++++++++++--------------
>>  1 file changed, 59 insertions(+), 37 deletions(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>> index c64d543..ffe9d1c 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -67,7 +67,7 @@ static int arch_timer_ppi[MAX_TIMER_PPI];
>>  
>>  static struct clock_event_device __percpu *arch_timer_evt;
>>  
>> -static bool arch_timer_use_virtual = true;
>> +static enum ppi_nr arch_timer_uses_ppi = VIRT_PPI;
>>  static bool arch_timer_c3stop;
>>  static bool arch_timer_mem_use_virtual;
>>  
>> @@ -263,14 +263,20 @@ static void __arch_timer_setup(unsigned type,
>>  		clk->name = "arch_sys_timer";
>>  		clk->rating = 450;
>>  		clk->cpumask = cpumask_of(smp_processor_id());
>> -		if (arch_timer_use_virtual) {
>> -			clk->irq = arch_timer_ppi[VIRT_PPI];
>> +		clk->irq = arch_timer_ppi[arch_timer_uses_ppi];
>> +		switch (arch_timer_uses_ppi) {
>> +		case VIRT_PPI:
>>  			clk->set_state_shutdown = arch_timer_shutdown_virt;
>>  			clk->set_next_event = arch_timer_set_next_event_virt;
>> -		} else {
>> -			clk->irq = arch_timer_ppi[PHYS_SECURE_PPI];
>> +			break;
>> +		case PHYS_SECURE_PPI:
>> +		case PHYS_NONSECURE_PPI:
>> +		case HYP_PPI:
>>  			clk->set_state_shutdown = arch_timer_shutdown_phys;
>>  			clk->set_next_event = arch_timer_set_next_event_phys;
>> +			break;
>> +		default:
>> +			BUG();
>>  		}
>>  	} else {
>>  		clk->features |= CLOCK_EVT_FEAT_DYNIRQ;
>> @@ -338,17 +344,20 @@ static void arch_counter_set_user_access(void)
>>  	arch_timer_set_cntkctl(cntkctl);
>>  }
>>  
>> +static bool arch_timer_has_nonsecure_ppi(void)
>> +{
>> +	return (arch_timer_uses_ppi == PHYS_SECURE_PPI &&
>> +		arch_timer_ppi[PHYS_NONSECURE_PPI]);
>> +}
>> +
>>  static int arch_timer_setup(struct clock_event_device *clk)
>>  {
>>  	__arch_timer_setup(ARCH_CP15_TIMER, clk);
>>  
>> -	if (arch_timer_use_virtual)
>> -		enable_percpu_irq(arch_timer_ppi[VIRT_PPI], 0);
>> -	else {
>> -		enable_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI], 0);
>> -		if (arch_timer_ppi[PHYS_NONSECURE_PPI])
>> -			enable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI], 0);
>> -	}
>> +	enable_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi], 0);
>> +
>> +	if (arch_timer_has_nonsecure_ppi())
>> +		enable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI], 0);
>>  
>>  	arch_counter_set_user_access();
>>  	if (IS_ENABLED(CONFIG_ARM_ARCH_TIMER_EVTSTREAM))
>> @@ -390,7 +399,7 @@ static void arch_timer_banner(unsigned type)
>>  		     (unsigned long)arch_timer_rate / 1000000,
>>  		     (unsigned long)(arch_timer_rate / 10000) % 100,
>>  		     type & ARCH_CP15_TIMER ?
>> -			arch_timer_use_virtual ? "virt" : "phys" :
>> +		     (arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :
>>  			"",
>>  		     type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ?  "/" : "",
>>  		     type & ARCH_MEM_TIMER ?
>> @@ -460,7 +469,7 @@ static void __init arch_counter_register(unsigned type)
>>  
>>  	/* Register the CP15 based counter if we have one */
>>  	if (type & ARCH_CP15_TIMER) {
>> -		if (IS_ENABLED(CONFIG_ARM64) || arch_timer_use_virtual)
>> +		if (IS_ENABLED(CONFIG_ARM64) || arch_timer_uses_ppi == VIRT_PPI)
>>  			arch_timer_read_counter = arch_counter_get_cntvct;
>>  		else
>>  			arch_timer_read_counter = arch_counter_get_cntpct;
>> @@ -490,13 +499,9 @@ static void arch_timer_stop(struct clock_event_device *clk)
>>  	pr_debug("arch_timer_teardown disable IRQ%d cpu #%d\n",
>>  		 clk->irq, smp_processor_id());
>>  
>> -	if (arch_timer_use_virtual)
>> -		disable_percpu_irq(arch_timer_ppi[VIRT_PPI]);
>> -	else {
>> -		disable_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI]);
>> -		if (arch_timer_ppi[PHYS_NONSECURE_PPI])
>> -			disable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI]);
>> -	}
>> +	disable_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi]);
>> +	if (arch_timer_has_nonsecure_ppi())
>> +		disable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI]);
>>  
>>  	clk->set_state_shutdown(clk);
>>  }
>> @@ -562,12 +567,14 @@ static int __init arch_timer_register(void)
>>  		goto out;
>>  	}
>>  
>> -	if (arch_timer_use_virtual) {
>> -		ppi = arch_timer_ppi[VIRT_PPI];
>> +	ppi = arch_timer_ppi[arch_timer_uses_ppi];
>> +	switch (arch_timer_uses_ppi) {
>> +	case VIRT_PPI:
>>  		err = request_percpu_irq(ppi, arch_timer_handler_virt,
>>  					 "arch_timer", arch_timer_evt);
>> -	} else {
>> -		ppi = arch_timer_ppi[PHYS_SECURE_PPI];
>> +		break;
>> +	case PHYS_SECURE_PPI:
>> +	case PHYS_NONSECURE_PPI:
>>  		err = request_percpu_irq(ppi, arch_timer_handler_phys,
>>  					 "arch_timer", arch_timer_evt);
>>  		if (!err && arch_timer_ppi[PHYS_NONSECURE_PPI]) {
>> @@ -578,6 +585,13 @@ static int __init arch_timer_register(void)
>>  				free_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI],
>>  						arch_timer_evt);
>>  		}
>> +		break;
>> +	case HYP_PPI:
>> +		err = request_percpu_irq(ppi, arch_timer_handler_phys,
>> +					 "arch_timer", arch_timer_evt);
>> +		break;
>> +	default:
>> +		BUG();
>>  	}
>>  
>>  	if (err) {
>> @@ -602,15 +616,10 @@ static int __init arch_timer_register(void)
>>  out_unreg_notify:
>>  	unregister_cpu_notifier(&arch_timer_cpu_nb);
>>  out_free_irq:
>> -	if (arch_timer_use_virtual)
>> -		free_percpu_irq(arch_timer_ppi[VIRT_PPI], arch_timer_evt);
>> -	else {
>> -		free_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI],
>> +	free_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi], arch_timer_evt);
>> +	if (arch_timer_has_nonsecure_ppi())
>> +		free_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI],
>>  				arch_timer_evt);
>> -		if (arch_timer_ppi[PHYS_NONSECURE_PPI])
>> -			free_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI],
>> -					arch_timer_evt);
>> -	}
>>  
>>  out_free:
>>  	free_percpu(arch_timer_evt);
>> @@ -697,12 +706,25 @@ static void __init arch_timer_init(void)
>>  	 *
>>  	 * If no interrupt provided for virtual timer, we'll have to
>>  	 * stick to the physical timer. It'd better be accessible...
>> +	 *
>> +	 * On ARMv8.1 with VH extensions, the kernel runs in HYP. VHE
>> +	 * accesses to CNTP_*_EL1 registers are silently redirected to
>> +	 * their CNTHP_*_EL2 counterparts, and use a different PPI
>> +	 * number.
>>  	 */
>>  	if (is_hyp_mode_available() || !arch_timer_ppi[VIRT_PPI]) {
>> -		arch_timer_use_virtual = false;
>> +		bool has_ppi;
>> +
>> +		if (is_kernel_in_hyp_mode()) {
>> +			arch_timer_uses_ppi = HYP_PPI;
>> +			has_ppi = !!arch_timer_ppi[HYP_PPI];
>> +		} else {
>> +			arch_timer_uses_ppi = PHYS_SECURE_PPI;
>> +			has_ppi = (!!arch_timer_ppi[PHYS_SECURE_PPI] ||
>> +				   !!arch_timer_ppi[PHYS_NONSECURE_PPI]);
> 
> shouldn't this simply test the PHYS_SECURE_PPI since otherwise you could
> potentially have the PHYS_NONSECURE_PPI but not PHYS_SECURE_PPI and
> you'll try to request IRQ 0 for this later... ?

I don't really see how you could have the non-secure PPI, but not the
secure one, as the binding doesn't give you opportunity to do so (the
first interrupt is the secure one, then the non-secure one...).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From jonathanh at nvidia.com  Mon Feb  1 05:42:55 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Mon, 1 Feb 2016 13:42:55 +0000
Subject: [PATCH V5 02/14] soc: tegra: pmc: Protect public functions from
 potential race conditions
In-Reply-To: <CANLsYkwpkDsdZ+6B-N8RWWWLJcJuoMLYmvw-VaCJdma4O6SPhg@mail.gmail.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-3-git-send-email-jonathanh@nvidia.com>
 <CANLsYkwpkDsdZ+6B-N8RWWWLJcJuoMLYmvw-VaCJdma4O6SPhg@mail.gmail.com>
Message-ID: <56AF60DF.6050409@nvidia.com>


On 29/01/16 16:20, Mathieu Poirier wrote:
> On 28 January 2016 at 09:33, Jon Hunter <jonathanh at nvidia.com> wrote:
>> The PMC base address pointer is initialised during early boot so that
>> early platform code may used the PMC public functions. During the probe
>> of the PMC driver the base address pointer is mapped again and the initial
>> mapping is freed. This exposes a window where a device accessing the PMC
>> registers via one of the public functions, could race with the updating
>> of the pointer and lead to a invalid access. Furthermore, the only
>> protection between multiple devices attempting to access the PMC registers
>> is when setting the powergate state to on or off. None of the other public
>> functions that access the PMC registers are protected.
>>
>> Use the existing mutex to protect paths that may race with regard to
>> accessing the PMC registers.
>>
>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
>> ---
>>  drivers/soc/tegra/pmc.c | 44 +++++++++++++++++++++++++++++++++++---------
>>  1 file changed, 35 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
>> index 85b4e166273a..f8cdb7ce9755 100644
>> --- a/drivers/soc/tegra/pmc.c
>> +++ b/drivers/soc/tegra/pmc.c
>> @@ -235,7 +235,10 @@ int tegra_powergate_is_powered(int id)
>>         if (!pmc->soc || id < 0 || id >= pmc->soc->num_powergates)
>>                 return -EINVAL;
>>
>> +       mutex_lock(&pmc->powergates_lock);
>>         status = tegra_pmc_readl(PWRGATE_STATUS) & (1 << id);
>> +       mutex_unlock(&pmc->powergates_lock);
>> +
>>         return !!status;
>>  }
>>
>> @@ -250,6 +253,8 @@ int tegra_powergate_remove_clamping(int id)
>>         if (!pmc->soc || id < 0 || id >= pmc->soc->num_powergates)
>>                 return -EINVAL;
>>
>> +       mutex_lock(&pmc->powergates_lock);
>> +
>>         /*
>>          * On Tegra124 and later, the clamps for the GPU are controlled by a
>>          * separate register (with different semantics).
>> @@ -257,7 +262,7 @@ int tegra_powergate_remove_clamping(int id)
>>         if (id == TEGRA_POWERGATE_3D) {
>>                 if (pmc->soc->has_gpu_clamps) {
>>                         tegra_pmc_writel(0, GPU_RG_CNTRL);
>> -                       return 0;
>> +                       goto out;
>>                 }
>>         }
>>
>> @@ -274,6 +279,9 @@ int tegra_powergate_remove_clamping(int id)
>>
>>         tegra_pmc_writel(mask, REMOVE_CLAMPING);
>>
>> +out:
>> +       mutex_unlock(&pmc->powergates_lock);
>> +
>>         return 0;
>>  }
>>  EXPORT_SYMBOL(tegra_powergate_remove_clamping);
>> @@ -520,9 +528,11 @@ int tegra_io_rail_power_on(int id)
>>         unsigned int bit, mask;
>>         int err;
>>
>> +       mutex_lock(&pmc->powergates_lock);
>> +
>>         err = tegra_io_rail_prepare(id, &request, &status, &bit);
>>         if (err < 0)
>> -               return err;
>> +               goto error;
>>
>>         mask = 1 << bit;
>>
>> @@ -535,12 +545,15 @@ int tegra_io_rail_power_on(int id)
>>         err = tegra_io_rail_poll(status, mask, 0, 250);
>>         if (err < 0) {
>>                 pr_info("tegra_io_rail_poll() failed: %d\n", err);
>> -               return err;
>> +               goto error;
>>         }
>>
>>         tegra_io_rail_unprepare();
>>
>> -       return 0;
>> +error:
>> +       mutex_unlock(&pmc->powergates_lock);
>> +
>> +       return err < 0 ? err : 0;
> 
> Is this necessary?  Why simply not returning 'err'?  From what I see
> 'tegra_io_rail_power_on()' can only return a negative value or '0'.

Right, this is probably not necessary and so I could simplify this.

>>  }
>>  EXPORT_SYMBOL(tegra_io_rail_power_on);
>>
>> @@ -550,10 +563,12 @@ int tegra_io_rail_power_off(int id)
>>         unsigned int bit, mask;
>>         int err;
>>
>> +       mutex_lock(&pmc->powergates_lock);
>> +
>>         err = tegra_io_rail_prepare(id, &request, &status, &bit);
>>         if (err < 0) {
>>                 pr_info("tegra_io_rail_prepare() failed: %d\n", err);
>> -               return err;
>> +               goto error;
>>         }
>>
>>         mask = 1 << bit;
>> @@ -566,11 +581,14 @@ int tegra_io_rail_power_off(int id)
>>
>>         err = tegra_io_rail_poll(status, mask, mask, 250);
>>         if (err < 0)
>> -               return err;
>> +               goto error;
>>
>>         tegra_io_rail_unprepare();
>>
>> -       return 0;
>> +error:
>> +       mutex_unlock(&pmc->powergates_lock);
>> +
>> +       return err < 0 ? err : 0;
> 
> Same comment as above.
> 
>>  }
>>  EXPORT_SYMBOL(tegra_io_rail_power_off);
>>
>> @@ -817,9 +835,15 @@ static int tegra_pmc_probe(struct platform_device *pdev)
>>
>>         /* take over the memory region from the early initialization */
>>         res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +
>> +       mutex_lock(&pmc->powergates_lock);
>>         pmc->base = devm_ioremap_resource(&pdev->dev, res);
>> -       if (IS_ERR(pmc->base))
>> -               return PTR_ERR(pmc->base);
>> +       mutex_unlock(&pmc->powergates_lock);
> 
> Since the mutex is released there is a window of opportunity for
> devices to access an erroneous pointer.  A better approach might be to
> use a temporary variable, do all the initialisation that is required
> and when things look good set pmc-base to that temporary variable.

Thanks. Not sure what I was thinking here. I will fix that.

Cheers
Jon


From jonathanh at nvidia.com  Mon Feb  1 05:44:26 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Mon, 1 Feb 2016 13:44:26 +0000
Subject: [PATCH V5 05/14] soc: tegra: pmc: Wait for powergate state to
 change
In-Reply-To: <CANLsYkycbEo+wyMX8RJ9H-S5kDTjQR4nnDZc5gvf2kShOZAv9w@mail.gmail.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-6-git-send-email-jonathanh@nvidia.com>
 <CANLsYkycbEo+wyMX8RJ9H-S5kDTjQR4nnDZc5gvf2kShOZAv9w@mail.gmail.com>
Message-ID: <56AF613A.1000909@nvidia.com>


On 29/01/16 16:58, Mathieu Poirier wrote:
> On 28 January 2016 at 09:33, Jon Hunter <jonathanh at nvidia.com> wrote:
>> Currently, the function tegra_powergate_set() simply sets the desired
>> powergate state but does not wait for the state to change. In most cases
>> we should wait for the state to change before proceeding. Currently, there
>> is a case for tegra114 and tegra124 devices where we do not wait when
>> starting the secondary CPU as this is not necessary. However, this is only
>> done at boot time and so waiting here will only have a small impact on
>> boot time. Therefore, update tegra_powergate_set() to wait when setting
>> the powergate.
>>
>> By adding this feature, we can also eliminate the polling loop from
>> tegra30_boot_secondary().
>>
>> A function has been added for checking the status of the powergate and
>> so update the tegra_powergate_is_powered() to use this macro as well.
>>
>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
>> ---
>>  arch/arm/mach-tegra/platsmp.c | 16 +++-------------
>>  drivers/soc/tegra/pmc.c       |  9 ++++++++-
>>  2 files changed, 11 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
>> index f3f61dbbda97..75620ae73913 100644
>> --- a/arch/arm/mach-tegra/platsmp.c
>> +++ b/arch/arm/mach-tegra/platsmp.c
>> @@ -108,19 +108,9 @@ static int tegra30_boot_secondary(unsigned int cpu, struct task_struct *idle)
>>          * be un-gated by un-toggling the power gate register
>>          * manually.
>>          */
>> -       if (!tegra_pmc_cpu_is_powered(cpu)) {
>> -               ret = tegra_pmc_cpu_power_on(cpu);
>> -               if (ret)
>> -                       return ret;
>> -
>> -               /* Wait for the power to come up. */
>> -               timeout = jiffies + msecs_to_jiffies(100);
>> -               while (!tegra_pmc_cpu_is_powered(cpu)) {
>> -                       if (time_after(jiffies, timeout))
>> -                               return -ETIMEDOUT;
>> -                       udelay(10);
>> -               }
>> -       }
>> +       ret = tegra_pmc_cpu_power_on(cpu);
>> +       if (ret)
>> +               return ret;
>>
>>  remove_clamps:
>>         /* CPU partition is powered. Enable the CPU clock. */
>> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
>> index 99cb2fdd29e1..35ee60fd17be 100644
>> --- a/drivers/soc/tegra/pmc.c
>> +++ b/drivers/soc/tegra/pmc.c
>> @@ -28,6 +28,7 @@
>>  #include <linux/export.h>
>>  #include <linux/init.h>
>>  #include <linux/io.h>
>> +#include <linux/iopoll.h>
>>  #include <linux/of.h>
>>  #include <linux/of_address.h>
>>  #include <linux/platform_device.h>
>> @@ -186,6 +187,9 @@ static inline bool tegra_powergate_state(int id)
>>   */
>>  static int tegra_powergate_set(unsigned int id, bool new_state)
>>  {
>> +       bool status;
>> +       int err;
>> +
>>         mutex_lock(&pmc->powergates_lock);
>>
>>         if (tegra_powergate_state(id) == new_state) {
>> @@ -195,9 +199,12 @@ static int tegra_powergate_set(unsigned int id, bool new_state)
>>
>>         tegra_pmc_writel(PWRGATE_TOGGLE_START | id, PWRGATE_TOGGLE);
>>
>> +       err = readx_poll_timeout(tegra_powergate_state, id, status,
>> +                                status == new_state, 10, 100000);
>> +
> 
> I understand (and agree) with the goal of this patch but I wonder (and
> I don't know much about the system/context) if holding a mutex while
> sleeping won't incur adverse effect on other parts of the system that
> weren't use to see this wait.  One way to fix this might be to use
> "mutex_trylock()" and let callers retry as they see fit if an
> operation is already in progress.

I could unlock the mutex after writing the TOGGLE_START register. I
don't believe that we need to waiting for a powergate to change before
writing again.

Jon


From mark.rutland at arm.com  Mon Feb  1 05:44:39 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 1 Feb 2016 13:44:39 +0000
Subject: [PATCH v2] clocksource/arm_arch_timer: Enable and verify MMIO
 access
In-Reply-To: <71bf617f4083b116b2aeab24f13fc5fed99a816f.1454327031.git.robin.murphy@arm.com>
References: <71bf617f4083b116b2aeab24f13fc5fed99a816f.1454327031.git.robin.murphy@arm.com>
Message-ID: <20160201134439.GH674@leverpostej>

On Mon, Feb 01, 2016 at 12:00:48PM +0000, Robin Murphy wrote:
> So far, we have been blindly assuming that having access to a
> memory-mapped timer frame implies that the individual elements of that
> frame frame are already enabled. Whilst it's the firmware's job to give
> us non-secure access to frames in the first place, we should not rely
> on implementations always being generous enough to also configure CNTACR
> for those non-secure frames (e.g. [1]).
> 
> Explicitly enable feature-level access per-frame, and verify that the
> access we want is really implemented before trying to make use of it.
> 
> [1]:https://github.com/ARM-software/tf-issues/issues/170
> 
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>

FWIW:

Acked-by: Mark Rutland <mark.rutland at arm.com>

In future, we could probably allow for using frames as counters without
timer support and vice-versa, but as-is this at leasts validates the
assumptions we make today.

Thanks,
Mark.

> ---
> 
> Changes from v1:
> - Remove CNTACR_RFRQ check since the "no access, CNTFRQ reads as zero"
>   case can be handled the same way the driver deals with the "CNTFRQ
>   accessible, but not programmed" case.
> - Reword the commit message to make more sense.
> 
>  drivers/clocksource/arm_arch_timer.c | 36 ++++++++++++++++++++++++++++--------
>  1 file changed, 28 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index c64d543..7c567f0 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -32,6 +32,14 @@
>  #define CNTTIDR		0x08
>  #define CNTTIDR_VIRT(n)	(BIT(1) << ((n) * 4))
>  
> +#define CNTACR(n)	(0x40 + ((n) * 4))
> +#define CNTACR_RPCT	BIT(0)
> +#define CNTACR_RVCT	BIT(1)
> +#define CNTACR_RFRQ	BIT(2)
> +#define CNTACR_RVOFF	BIT(3)
> +#define CNTACR_RWVT	BIT(4)
> +#define CNTACR_RWPT	BIT(5)
> +
>  #define CNTVCT_LO	0x08
>  #define CNTVCT_HI	0x0c
>  #define CNTFRQ		0x10
> @@ -757,7 +765,6 @@ static void __init arch_timer_mem_init(struct device_node *np)
>  	}
>  
>  	cnttidr = readl_relaxed(cntctlbase + CNTTIDR);
> -	iounmap(cntctlbase);
>  
>  	/*
>  	 * Try to find a virtual capable frame. Otherwise fall back to a
> @@ -765,20 +772,31 @@ static void __init arch_timer_mem_init(struct device_node *np)
>  	 */
>  	for_each_available_child_of_node(np, frame) {
>  		int n;
> +		u32 cntacr;
>  
>  		if (of_property_read_u32(frame, "frame-number", &n)) {
>  			pr_err("arch_timer: Missing frame-number\n");
> -			of_node_put(best_frame);
>  			of_node_put(frame);
> -			return;
> +			goto out;
>  		}
>  
> -		if (cnttidr & CNTTIDR_VIRT(n)) {
> +		/* Try enabling everything, and see what sticks */
> +		cntacr = CNTACR_RFRQ | CNTACR_RWPT | CNTACR_RPCT |
> +			 CNTACR_RWVT | CNTACR_RVOFF | CNTACR_RVCT;
> +		writel_relaxed(cntacr, cntctlbase + CNTACR(n));
> +		cntacr = readl_relaxed(cntctlbase + CNTACR(n));
> +
> +		if ((cnttidr & CNTTIDR_VIRT(n)) &&
> +		    !(~cntacr & (CNTACR_RWVT | CNTACR_RVCT))) {
>  			of_node_put(best_frame);
>  			best_frame = frame;
>  			arch_timer_mem_use_virtual = true;
>  			break;
>  		}
> +
> +		if (~cntacr & (CNTACR_RWPT | CNTACR_RPCT))
> +			continue;
> +
>  		of_node_put(best_frame);
>  		best_frame = of_node_get(frame);
>  	}
> @@ -786,24 +804,26 @@ static void __init arch_timer_mem_init(struct device_node *np)
>  	base = arch_counter_base = of_iomap(best_frame, 0);
>  	if (!base) {
>  		pr_err("arch_timer: Can't map frame's registers\n");
> -		of_node_put(best_frame);
> -		return;
> +		goto out;
>  	}
>  
>  	if (arch_timer_mem_use_virtual)
>  		irq = irq_of_parse_and_map(best_frame, 1);
>  	else
>  		irq = irq_of_parse_and_map(best_frame, 0);
> -	of_node_put(best_frame);
> +
>  	if (!irq) {
>  		pr_err("arch_timer: Frame missing %s irq",
>  		       arch_timer_mem_use_virtual ? "virt" : "phys");
> -		return;
> +		goto out;
>  	}
>  
>  	arch_timer_detect_rate(base, np);
>  	arch_timer_mem_register(base, irq);
>  	arch_timer_common_init();
> +out:
> +	iounmap(cntctlbase);
> +	of_node_put(best_frame);
>  }
>  CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
>  		       arch_timer_mem_init);
> -- 
> 2.7.0.25.gfc10eb5.dirty
> 


From jonathanh at nvidia.com  Mon Feb  1 05:45:07 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Mon, 1 Feb 2016 13:45:07 +0000
Subject: [PATCH V5 06/14] soc: tegra: pmc: Fix checking of valid partitions
In-Reply-To: <CANLsYkxY5P2wQxGev0veN39nD-1cTVkZCVpX9jca7da39JJpWg@mail.gmail.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-7-git-send-email-jonathanh@nvidia.com>
 <CANLsYkxY5P2wQxGev0veN39nD-1cTVkZCVpX9jca7da39JJpWg@mail.gmail.com>
Message-ID: <56AF6163.4070204@nvidia.com>


On 29/01/16 17:08, Mathieu Poirier wrote:
> On 28 January 2016 at 09:33, Jon Hunter <jonathanh at nvidia.com> wrote:
>> The tegra power partitions are referenced by a numerical ID which are
>> the same values programmed into the PMC registers for controlling the
>> partition. For a given device, the valid partition IDs may not be
>> contiguous and so simply checking that an ID is not greater than the
>> maximum ID supported may not mean it is valid. Fix this by adding a
>> bitmap for representing the valid partitions of a device and add a
>> helper function will test if the partition is valid.
>>
>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
>> ---
>>  drivers/soc/tegra/pmc.c | 21 +++++++++++++++++----
>>  include/soc/tegra/pmc.h |  1 +
>>  2 files changed, 18 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
>> index 35ee60fd17be..032dd5c17130 100644
>> --- a/drivers/soc/tegra/pmc.c
>> +++ b/drivers/soc/tegra/pmc.c
>> @@ -132,6 +132,7 @@ struct tegra_pmc_soc {
>>   * @cpu_pwr_good_en: CPU power good signal is enabled
>>   * @lp0_vec_phys: physical base address of the LP0 warm boot code
>>   * @lp0_vec_size: size of the LP0 warm boot code
>> + * @powergates_valid: Bitmap of valid power gates
>>   * @powergates_lock: mutex for power gate register access
>>   */
>>  struct tegra_pmc {
>> @@ -156,6 +157,7 @@ struct tegra_pmc {
>>         bool cpu_pwr_good_en;
>>         u32 lp0_vec_phys;
>>         u32 lp0_vec_size;
>> +       DECLARE_BITMAP(powergates_valid, TEGRA_POWERGATE_MAX);
>>
>>         struct mutex powergates_lock;
>>  };
>> @@ -180,6 +182,11 @@ static inline bool tegra_powergate_state(int id)
>>         return (tegra_pmc_readl(PWRGATE_STATUS) & BIT(id)) != 0;
>>  }
>>
>> +static inline bool tegra_powergate_is_valid(int id)
>> +{
>> +       return test_bit(id, pmc->powergates_valid);
>> +}
>> +
>>  /**
>>   * tegra_powergate_set() - set the state of a partition
>>   * @id: partition ID
>> @@ -213,7 +220,7 @@ static int tegra_powergate_set(unsigned int id, bool new_state)
>>   */
>>  int tegra_powergate_power_on(unsigned int id)
>>  {
>> -       if (!pmc->soc || id >= pmc->soc->num_powergates)
>> +       if (!tegra_powergate_is_valid(id))
>>                 return -EINVAL;
> 
> The "!pmc-soc" condition is no longer needed?  If so the changelog
> should reflect that or a new patch that deals with just that should be
> etched.  The same comment applies for the rest of the patch.

Yes it is not necessary. I will update the changelog.

Cheers
Jon


From shawnguo at kernel.org  Mon Feb  1 05:46:07 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 1 Feb 2016 21:46:07 +0800
Subject: [PATCH v4 2/2] ARM: dts: imx6: Add support for Toradex Ixora
 carrier board
In-Reply-To: <1453675703-31594-3-git-send-email-marcel.ziswiler@toradex.com>
References: <1453675703-31594-1-git-send-email-marcel.ziswiler@toradex.com>
 <1453675703-31594-3-git-send-email-marcel.ziswiler@toradex.com>
Message-ID: <20160201134606.GG10671@tiger>

On Sun, Jan 24, 2016 at 11:48:23PM +0100, Marcel Ziswiler wrote:
> From: Petr ?tetiar <ynezz at true.cz>
> 
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler at toradex.com>
> Signed-off-by: Petr ?tetiar <ynezz at true.cz>
> Reviewed-by: Stefan Agner <stefan at agner.ch>

Copy my Linaro mailbox is unnecessary.  The kernel.org one is good
enough for me to receive your patch.

> ---
> 
> Changes in v4: None
> Changes in v3:
> - integrated review feedback from Petr
> - integrated review feedback from Stefan
> - fix comment concerning Apalis GPIO usage as GPIO7 is only used for PCIe switch reset on Apalis Evaluation board
> - move I2C DDC handling into carrier board DTS where it belongs
> - simplify RTC alias
> 
> Changes in v2:
> - clarify exact Apalis iMX6Q/D SoM type in cover letter
> - clarify exact Apalis iMX6Q/D module type and Ixora carrier board in model
>   node
> - got rid of obsolete mmc aliases
> - working SGTL5000 audio/sound integration
> - working STMPE811 touch screen controller integration
> - integrated review feedback from Lucas
> - left and even added some more comments as I don't see why putting any
>   explanatory comments in dts' should be such a bad thing to do
> - completely got rid of the memory node as that is something typically filled
>   in by the boot loader e.g. U-Boot
> - without the regulators simple-bus it no longer boots
> - even though we supposedly shipped a few hundred V1.0a modules drop DCE UART
>   support for now and simplify file layout
> - replaced obsolete no-1-8-v by mainline supported voltage-ranges = <3300 3300>
>   usdhc property and yes card detects are indeed active low (;-p)
> - integrated review feedback from Stefan
> - fixed Ethernet PHY reset & interrupt (requires Micrel PHY driver to be
>   enabled)
> - fixed HDMI DDC (requires GPIO-based bitbanging I2C to be enabled)
> - fixed SPDIF
> 
>  arch/arm/boot/dts/Makefile               |   1 +
>  arch/arm/boot/dts/imx6q-apalis-ixora.dts | 275 +++++++++++++++++++++++++++++++
>  2 files changed, 276 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6q-apalis-ixora.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index a4a6d70..0d5e11b 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -317,6 +317,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>  	imx6dl-udoo.dtb \
>  	imx6dl-wandboard.dtb \
>  	imx6dl-wandboard-revb1.dtb \
> +	imx6q-apalis-ixora.dtb \
>  	imx6q-apf6dev.dtb \
>  	imx6q-arm2.dtb \
>  	imx6q-cm-fx6.dtb \
> diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> new file mode 100644
> index 0000000..28f3b34
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> @@ -0,0 +1,275 @@
> +/*
> + * Copyright 2014-2016 Toradex AG
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License
> + *     version 2 as published by the Free Software Foundation.
> + *
> + *     This file is distributed in the hope that it will be useful
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include "imx6q.dtsi"
> +#include "imx6qdl-apalis.dtsi"
> +
> +/ {
> +	model = "Toradex Apalis iMX6Q/D Module on Ixora Carrier Board";
> +	compatible = "toradex,apalis_imx6q-ixora", "toradex,apalis_imx6q",
> +		     "fsl,imx6q";
> +
> +	aliases {
> +		i2c0 = &i2cddc;
> +		i2c1 = &i2c1;
> +		i2c2 = &i2c2;
> +		i2c3 = &i2c3;
> +	};
> +
> +	aliases {
> +		rtc0 = &rtc_i2c;
> +		rtc1 = &snvs_rtc;
> +	};
> +
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_gpio_keys>;
> +
> +		wakeup {
> +			label = "Wake-Up";
> +			gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
> +			linux,code = <KEY_WAKEUP>;
> +			debounce-interval = <10>;
> +			gpio-key,wakeup;

Please take a look at the following commit, which converts the legacy
wakeup properties to the new generic one.

https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h=imx/dt&id=1c49ad21c2cae607193da4495489c751d7147df2

> +		};
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_leds_ixora>;
> +
> +		led4-green {
> +			label = "LED_4_GREEN";
> +			gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		led4-red {
> +			label = "LED_4_RED";
> +			gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		led5-green {
> +			label = "LED_5_GREEN";
> +			gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		led5-red {
> +			label = "LED_5_RED";
> +			gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
> +		};
> +	};
> +
> +	pwmleds {
> +		compatible = "pwm-leds";

Have a new line between properties and sub-node.

> +		ledpwm1 {
> +			label = "PWM1";
> +			pwms = <&pwm1 0 50000>;
> +			max-brightness = <255>;
> +		};
> +
> +		ledpwm2 {
> +			label = "PWM2";
> +			pwms = <&pwm2 0 50000>;
> +			max-brightness = <255>;
> +		};
> +
> +		ledpwm3 {
> +			label = "PWM3";
> +			pwms = <&pwm3 0 50000>;
> +			max-brightness = <255>;
> +		};
> +	};
> +
> +	regulators {
> +		reg_usb_otg_vbus: usb_otg_vbus {
> +			status = "okay";
> +		};

It can be as simple as the following.

&reg_usb_otg_vbus {
	status = "okay";
};

> +
> +		reg_usb_host_vbus: usb_host_vbus {
> +			status = "okay";
> +		};
> +	};
> +};
> +
> +&backlight {
> +	brightness-levels = <0 127 191 223 239 247 251 255>;
> +	default-brightness-level = <1>;
> +	status = "okay";
> +};
> +
> +&can1 {
> +	status = "okay";
> +};
> +
> +&can2 {
> +	status = "okay";
> +};
> +
> +&hdmi {
> +	ddc-i2c-bus = <&i2cddc>;
> +	status = "okay";
> +};
> +
> +&i2cddc {
> +	status = "okay";
> +};
> +
> +/* GEN1_I2C: I2C1_SDA/SCL on MXM3 209/211 (e.g. RTC on carrier board) */
> +&i2c1 {
> +	status = "okay";
> +
> +	eeprom at 50 {
> +		compatible = "atmel,24c02";
> +		reg = <0x50>;
> +	};
> +
> +	/* M41T0M6 real time clock on carrier board */
> +	rtc_i2c: rtc at 68 {
> +		compatible = "st,m41t00";
> +		reg = <0x68>;
> +	};
> +};
> +
> +&ldb {
> +	status = "okay";
> +};
> +
> +&pcie {
> +	/* active-low meaning opposite of regular PERST# active-low polarity */
> +	reset-gpio = <&gpio1 28 GPIO_ACTIVE_LOW>;
> +	status = "okay";
> +};
> +
> +&pwm1 {
> +	status = "okay";
> +};
> +
> +&pwm2 {
> +	status = "okay";
> +};
> +
> +&pwm3 {
> +	status = "okay";
> +};
> +
> +&pwm4 {
> +	status = "okay";
> +};
> +
> +&sata {
> +	status = "okay";
> +};
> +
> +&sound_spdif {
> +	status = "okay";
> +};
> +
> +&spdif {
> +	status = "okay";
> +};
> +
> +&uart1 {
> +	status = "okay";
> +};
> +
> +&uart2 {
> +	status = "okay";
> +};
> +
> +&uart4 {
> +	status = "okay";
> +};
> +
> +&uart5 {
> +	status = "okay";
> +};
> +
> +&usbh1 {
> +	vbus-supply = <&reg_usb_host_vbus>;
> +	status = "okay";
> +};
> +
> +&usbotg {
> +	vbus-supply = <&reg_usb_otg_vbus>;
> +	status = "okay";
> +};
> +
> +/* SD1 */
> +&usdhc2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_sd_cd>;
> +	cd-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>;
> +	status = "okay";
> +};
> +
> +&iomuxc {
> +	/*
> +	 * Mux the Apalis GPIOs
> +	 * GPIO5, 6 used by optional fusion_F0710A kernel module
> +	 */
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_apalis_gpio1 &pinctrl_apalis_gpio2
> +		     &pinctrl_apalis_gpio3 &pinctrl_apalis_gpio4
> +		     &pinctrl_apalis_gpio5 &pinctrl_apalis_gpio6
> +		     &pinctrl_apalis_gpio7 &pinctrl_apalis_gpio8

We can have a single hog group to contain all these pins, I guess.

> +		    >;
> +
> +	leds_ixora {

Drop this container node.

Shawn

> +		pinctrl_leds_ixora: leds-ixora {
> +			fsl,pins = <
> +				MX6QDL_PAD_SD1_DAT1__GPIO1_IO17 0x1b0b0
> +				MX6QDL_PAD_SD1_DAT3__GPIO1_IO21 0x1b0b0
> +				MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0
> +				MX6QDL_PAD_NANDF_D2__GPIO2_IO02 0x1b0b0
> +			>;
> +		};
> +	};
> +};
> -- 
> 2.5.0
> 
> 


From christoffer.dall at linaro.org  Mon Feb  1 05:47:32 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 14:47:32 +0100
Subject: [PATCH v2 08/21] arm64: KVM: VHE: Introduce unified system
 register accessors
In-Reply-To: <1453737235-16522-9-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-9-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201134732.GK1478@cbox>

On Mon, Jan 25, 2016 at 03:53:42PM +0000, Marc Zyngier wrote:
> VHE brings its own bag of new system registers, or rather system
> register accessors, as it define new ways to access both guest
> and host system registers. For example, from the host:
> 
> - The host TCR_EL2 register is accessed using the TCR_EL1 accessor
> - The guest TCR_EL1 register is accessed using the TCR_EL12 accessor
> 
> Obviously, this is confusing. A way to somehow reduce the complexity
> of writing code for both ARMv8 and ARMv8.1 is to use a set of unified
> accessors that will generate the right sysreg, depending on the mode
> the CPU is running in. For example:
> 
> - read_sysreg_el1(tcr) will use TCR_EL1 on ARMv8, and TCR_EL12 on
>   ARMv8.1 with VHE.
> - read_sysreg_el2(tcr) will use TCR_EL2 on ARMv8, and TCR_EL1 on
>   ARMv8.1 with VHE.
> 
> We end up with three sets of accessors ({read,write}_sysreg_el[012])
> that can be directly used from C code. We take this opportunity to
> also add the definition for the new VHE sysregs.(

weird closing parenthesis.

> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/hyp/hyp.h | 72 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 72 insertions(+)
> 
> diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
> index fc502f3..744c919 100644
> --- a/arch/arm64/kvm/hyp/hyp.h
> +++ b/arch/arm64/kvm/hyp/hyp.h
> @@ -48,6 +48,78 @@ static inline unsigned long __hyp_kern_va(unsigned long v)
>  
>  #define hyp_kern_va(v) (typeof(v))(__hyp_kern_va((unsigned long)(v)))
>  
> +#define read_sysreg_elx(r,nvh,vh)					\
> +	({								\
> +		u64 reg;						\
> +		asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##nvh),\
> +					 "mrs_s %0, " __stringify(r##vh),\
> +					 ARM64_HAS_VIRT_HOST_EXTN)	\
> +			     : "=r" (reg));				\
> +		reg;							\
> +	})
> +
> +#define write_sysreg_elx(v,r,nvh,vh)					\
> +	do {								\
> +		u64 __val = (u64)(v);					\
> +		asm volatile(ALTERNATIVE("msr " __stringify(r##nvh) ", %x0",\
> +					 "msr_s " __stringify(r##vh) ", %x0",\
> +					 ARM64_HAS_VIRT_HOST_EXTN)	\
> +					 : : "rZ" (__val));		\

what is rZ ?
(complete Google-fu failure misery)

> +	} while (0)
> +
> +/*
> + * Unified accessors for registers that have a different encoding
> + * between VHE and non-VHE. They must be specified without their "ELx"
> + * encoding.
> + */
> +#define read_sysreg_el2(r)						\
> +	({								\
> +		u64 reg;						\
> +		asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##_EL2),\
> +					 "mrs %0, " __stringify(r##_EL1),\
> +					 ARM64_HAS_VIRT_HOST_EXTN)	\
> +			     : "=r" (reg));				\
> +		reg;							\
> +	})
> +
> +#define write_sysreg_el2(v,r)						\
> +	do {								\
> +		u64 __val = (u64)(v);					\
> +		asm volatile(ALTERNATIVE("msr " __stringify(r##_EL2) ", %x0",\
> +					 "msr " __stringify(r##_EL1) ", %x0",\
> +					 ARM64_HAS_VIRT_HOST_EXTN)	\
> +					 : : "rZ" (__val));		\
> +	} while (0)
> +
> +#define read_sysreg_el0(r)	read_sysreg_elx(r, _EL0, _EL02)
> +#define write_sysreg_el0(v,r)	write_sysreg_elx(v, r, _EL0, _EL02)
> +#define read_sysreg_el1(r)	read_sysreg_elx(r, _EL1, _EL12)
> +#define write_sysreg_el1(v,r)	write_sysreg_elx(v, r, _EL1, _EL12)
> +
> +/* The VHE specific system registers and their encoding */
> +#define sctlr_EL12              sys_reg(3, 5, 1, 0, 0)
> +#define cpacr_EL12              sys_reg(3, 5, 1, 0, 2)
> +#define ttbr0_EL12              sys_reg(3, 5, 2, 0, 0)
> +#define ttbr1_EL12              sys_reg(3, 5, 2, 0, 1)
> +#define tcr_EL12                sys_reg(3, 5, 2, 0, 2)
> +#define afsr0_EL12              sys_reg(3, 5, 5, 1, 0)
> +#define afsr1_EL12              sys_reg(3, 5, 5, 1, 1)
> +#define esr_EL12                sys_reg(3, 5, 5, 2, 0)
> +#define far_EL12                sys_reg(3, 5, 6, 0, 0)
> +#define mair_EL12               sys_reg(3, 5, 10, 2, 0)
> +#define amair_EL12              sys_reg(3, 5, 10, 3, 0)
> +#define vbar_EL12               sys_reg(3, 5, 12, 0, 0)
> +#define contextidr_EL12         sys_reg(3, 5, 13, 0, 1)
> +#define cntkctl_EL12            sys_reg(3, 5, 14, 1, 0)
> +#define cntp_tval_EL02          sys_reg(3, 5, 14, 2, 0)
> +#define cntp_ctl_EL02           sys_reg(3, 5, 14, 2, 1)
> +#define cntp_cval_EL02          sys_reg(3, 5, 14, 2, 2)
> +#define cntv_tval_EL02          sys_reg(3, 5, 14, 3, 0)
> +#define cntv_ctl_EL02           sys_reg(3, 5, 14, 3, 1)
> +#define cntv_cval_EL02          sys_reg(3, 5, 14, 3, 2)

as always, fun stuff to review.

> +#define spsr_EL12               sys_reg(3, 5, 4, 0, 0)
> +#define elr_EL12                sys_reg(3, 5, 4, 0, 1)
> +

I couldn't quite decipher the spec as to how these are the right
instruction encodings, so I'm going to trust the testing that this is
done right.

>  /**
>   * hyp_alternate_select - Generates patchable code sequences that are
>   * used to switch between two implementations of a function, depending
> -- 
> 2.1.4
> 

Thanks,
-Christoffer



From shawnguo at kernel.org  Mon Feb  1 05:48:52 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 1 Feb 2016 21:48:52 +0800
Subject: [PATCH] ARM: imx6sx-sdb: add i2c3 node
In-Reply-To: <1453675758.6691.17.camel@googlemail.com>
References: <1453675758.6691.17.camel@googlemail.com>
Message-ID: <20160201134852.GH10671@tiger>

On Sun, Jan 24, 2016 at 11:49:18PM +0100, Christoph Fritz wrote:
> This patch adds node i2c bus 3 to get the appropriate userland device
> file. So for prototyping it's possible to experiment within userland.
> 
> Signed-off-by: Christoph Fritz <chf.fritz at googlemail.com>

Applied, thanks.


From shawnguo at kernel.org  Mon Feb  1 05:53:33 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 1 Feb 2016 21:53:33 +0800
Subject: [PATCH v2 01/15] arm: use of_platform_default_populate() to
 populate default bus
In-Reply-To: <1453881180-12296-1-git-send-email-wangkefeng.wang@huawei.com>
References: <1453868872-26300-2-git-send-email-wangkefeng.wang@huawei.com>
 <1453881180-12296-1-git-send-email-wangkefeng.wang@huawei.com>
Message-ID: <20160201135333.GI10671@tiger>

On Wed, Jan 27, 2016 at 03:53:00PM +0800, Kefeng Wang wrote:
> Use helper of_platform_default_populate() in linux/of_platform
> when possible, instead of calling of_platform_populate() with
> the default match table.
> 
> Cc: Nicolas Ferre <nicolas.ferre at atmel.com>
> Cc: Ray Jui <rjui at broadcom.com>
> Cc: Lee Jones <lee at kernel.org>
> Cc: Krzysztof Halasa <khalasa at piap.pl>
> Cc: Kukjin Kim <kgene at kernel.org>
> Cc: Rob Herring <robh at kernel.org>
> Cc: Shawn Guo <shawnguo at kernel.org>
...
>  arch/arm/mach-imx/imx27-dt.c             | 2 +-
>  arch/arm/mach-imx/mach-imx51.c           | 2 +-
>  arch/arm/mach-imx/mach-imx53.c           | 2 +-
>  arch/arm/mach-imx/mach-imx6q.c           | 2 +-
>  arch/arm/mach-imx/mach-imx6sl.c          | 2 +-
>  arch/arm/mach-imx/mach-imx6sx.c          | 2 +-
>  arch/arm/mach-imx/mach-imx6ul.c          | 2 +-
>  arch/arm/mach-imx/mach-imx7d.c           | 2 +-
...
>  arch/arm/mach-mxs/mach-mxs.c             | 3 +--

Acked-by: Shawn Guo <shawnguo at kernel.org>


From christoffer.dall at linaro.org  Mon Feb  1 05:54:38 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 14:54:38 +0100
Subject: [PATCH v2 10/21] arm64: KVM: VHE: Split save/restore of sysregs
 shared between EL1 and EL2
In-Reply-To: <1453737235-16522-11-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-11-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201135438.GL1478@cbox>

On Mon, Jan 25, 2016 at 03:53:44PM +0000, Marc Zyngier wrote:
> A handful of system registers are still shared between EL1 and EL2,
> even while using VHE. These are tpidr*_el[01], actlr_el1, sp0, elr,
> and spsr.

So by shared registers you mean registers that do both have an EL0/1
version as well as an EL2 version, but where accesses aren't rewritten
transparently?

also, by sp0 do you mean sp_el0, and by elr you mean elr_el1, and by
spsr you mean spsr_el1 ?


> 
> In order to facilitate the introduction of a VHE-specific sysreg
> save/restore, make move the access to these registers to their
> own save/restore functions.
> 
> No functionnal change.

Otherwise:

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>

> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/hyp/sysreg-sr.c | 48 +++++++++++++++++++++++++++++-------------
>  1 file changed, 33 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
> index bd5b543..61bad17 100644
> --- a/arch/arm64/kvm/hyp/sysreg-sr.c
> +++ b/arch/arm64/kvm/hyp/sysreg-sr.c
> @@ -23,13 +23,29 @@
>  
>  #include "hyp.h"
>  
> -/* ctxt is already in the HYP VA space */
> +/*
> + * Non-VHE: Both host and guest must save everything.
> + *
> + * VHE: Host must save tpidr*_el[01], actlr_el1, sp0, pc, pstate, and
> + * guest must save everything.
> + */
> +
> +static void __hyp_text __sysreg_save_common_state(struct kvm_cpu_context *ctxt)
> +{
> +	ctxt->sys_regs[ACTLR_EL1]	= read_sysreg(actlr_el1);
> +	ctxt->sys_regs[TPIDR_EL0]	= read_sysreg(tpidr_el0);
> +	ctxt->sys_regs[TPIDRRO_EL0]	= read_sysreg(tpidrro_el0);
> +	ctxt->sys_regs[TPIDR_EL1]	= read_sysreg(tpidr_el1);
> +	ctxt->gp_regs.regs.sp		= read_sysreg(sp_el0);
> +	ctxt->gp_regs.regs.pc		= read_sysreg(elr_el2);
> +	ctxt->gp_regs.regs.pstate	= read_sysreg(spsr_el2);
> +}
> +
>  static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
>  {
>  	ctxt->sys_regs[MPIDR_EL1]	= read_sysreg(vmpidr_el2);
>  	ctxt->sys_regs[CSSELR_EL1]	= read_sysreg(csselr_el1);
>  	ctxt->sys_regs[SCTLR_EL1]	= read_sysreg(sctlr_el1);
> -	ctxt->sys_regs[ACTLR_EL1]	= read_sysreg(actlr_el1);
>  	ctxt->sys_regs[CPACR_EL1]	= read_sysreg(cpacr_el1);
>  	ctxt->sys_regs[TTBR0_EL1]	= read_sysreg(ttbr0_el1);
>  	ctxt->sys_regs[TTBR1_EL1]	= read_sysreg(ttbr1_el1);
> @@ -41,17 +57,11 @@ static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
>  	ctxt->sys_regs[MAIR_EL1]	= read_sysreg(mair_el1);
>  	ctxt->sys_regs[VBAR_EL1]	= read_sysreg(vbar_el1);
>  	ctxt->sys_regs[CONTEXTIDR_EL1]	= read_sysreg(contextidr_el1);
> -	ctxt->sys_regs[TPIDR_EL0]	= read_sysreg(tpidr_el0);
> -	ctxt->sys_regs[TPIDRRO_EL0]	= read_sysreg(tpidrro_el0);
> -	ctxt->sys_regs[TPIDR_EL1]	= read_sysreg(tpidr_el1);
>  	ctxt->sys_regs[AMAIR_EL1]	= read_sysreg(amair_el1);
>  	ctxt->sys_regs[CNTKCTL_EL1]	= read_sysreg(cntkctl_el1);
>  	ctxt->sys_regs[PAR_EL1]		= read_sysreg(par_el1);
>  	ctxt->sys_regs[MDSCR_EL1]	= read_sysreg(mdscr_el1);
>  
> -	ctxt->gp_regs.regs.sp		= read_sysreg(sp_el0);
> -	ctxt->gp_regs.regs.pc		= read_sysreg(elr_el2);
> -	ctxt->gp_regs.regs.pstate	= read_sysreg(spsr_el2);
>  	ctxt->gp_regs.sp_el1		= read_sysreg(sp_el1);
>  	ctxt->gp_regs.elr_el1		= read_sysreg(elr_el1);
>  	ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg(spsr_el1);
> @@ -60,11 +70,24 @@ static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
>  void __hyp_text __sysreg_save_host_state(struct kvm_cpu_context *ctxt)
>  {
>  	__sysreg_save_state(ctxt);
> +	__sysreg_save_common_state(ctxt);
>  }
>  
>  void __hyp_text __sysreg_save_guest_state(struct kvm_cpu_context *ctxt)
>  {
>  	__sysreg_save_state(ctxt);
> +	__sysreg_save_common_state(ctxt);
> +}
> +
> +static void __hyp_text __sysreg_restore_common_state(struct kvm_cpu_context *ctxt)
> +{
> +	write_sysreg(ctxt->sys_regs[ACTLR_EL1],	  actlr_el1);
> +	write_sysreg(ctxt->sys_regs[TPIDR_EL0],	  tpidr_el0);
> +	write_sysreg(ctxt->sys_regs[TPIDRRO_EL0], tpidrro_el0);
> +	write_sysreg(ctxt->sys_regs[TPIDR_EL1],	  tpidr_el1);
> +	write_sysreg(ctxt->gp_regs.regs.sp,	  sp_el0);
> +	write_sysreg(ctxt->gp_regs.regs.pc,	  elr_el2);
> +	write_sysreg(ctxt->gp_regs.regs.pstate,	  spsr_el2);
>  }
>  
>  static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
> @@ -72,7 +95,6 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
>  	write_sysreg(ctxt->sys_regs[MPIDR_EL1],	  vmpidr_el2);
>  	write_sysreg(ctxt->sys_regs[CSSELR_EL1],  csselr_el1);
>  	write_sysreg(ctxt->sys_regs[SCTLR_EL1],	  sctlr_el1);
> -	write_sysreg(ctxt->sys_regs[ACTLR_EL1],	  actlr_el1);
>  	write_sysreg(ctxt->sys_regs[CPACR_EL1],	  cpacr_el1);
>  	write_sysreg(ctxt->sys_regs[TTBR0_EL1],	  ttbr0_el1);
>  	write_sysreg(ctxt->sys_regs[TTBR1_EL1],	  ttbr1_el1);
> @@ -84,17 +106,11 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
>  	write_sysreg(ctxt->sys_regs[MAIR_EL1],	  mair_el1);
>  	write_sysreg(ctxt->sys_regs[VBAR_EL1],	  vbar_el1);
>  	write_sysreg(ctxt->sys_regs[CONTEXTIDR_EL1], contextidr_el1);
> -	write_sysreg(ctxt->sys_regs[TPIDR_EL0],	  tpidr_el0);
> -	write_sysreg(ctxt->sys_regs[TPIDRRO_EL0], tpidrro_el0);
> -	write_sysreg(ctxt->sys_regs[TPIDR_EL1],	  tpidr_el1);
>  	write_sysreg(ctxt->sys_regs[AMAIR_EL1],	  amair_el1);
>  	write_sysreg(ctxt->sys_regs[CNTKCTL_EL1], cntkctl_el1);
>  	write_sysreg(ctxt->sys_regs[PAR_EL1],	  par_el1);
>  	write_sysreg(ctxt->sys_regs[MDSCR_EL1],	  mdscr_el1);
>  
> -	write_sysreg(ctxt->gp_regs.regs.sp,	sp_el0);
> -	write_sysreg(ctxt->gp_regs.regs.pc,	elr_el2);
> -	write_sysreg(ctxt->gp_regs.regs.pstate,	spsr_el2);
>  	write_sysreg(ctxt->gp_regs.sp_el1,	sp_el1);
>  	write_sysreg(ctxt->gp_regs.elr_el1,	elr_el1);
>  	write_sysreg(ctxt->gp_regs.spsr[KVM_SPSR_EL1], spsr_el1);
> @@ -103,11 +119,13 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
>  void __hyp_text __sysreg_restore_host_state(struct kvm_cpu_context *ctxt)
>  {
>  	__sysreg_restore_state(ctxt);
> +	__sysreg_restore_common_state(ctxt);
>  }
>  
>  void __hyp_text __sysreg_restore_guest_state(struct kvm_cpu_context *ctxt)
>  {
>  	__sysreg_restore_state(ctxt);
> +	__sysreg_restore_common_state(ctxt);
>  }
>  
>  void __hyp_text __sysreg32_save_state(struct kvm_vcpu *vcpu)
> -- 
> 2.1.4
> 


From peter.ujfalusi at ti.com  Mon Feb  1 05:54:18 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Mon, 1 Feb 2016 15:54:18 +0200
Subject: [PATCH v4] dmaengine: edma: fix residue race for cyclic
In-Reply-To: <87k2mu2e16.fsf@linutronix.de>
References: <87k2mu2e16.fsf@linutronix.de>
Message-ID: <56AF638A.80209@ti.com>

On 01/28/2016 12:29 PM, John Ogness wrote:
> When retrieving the residue value, the SRC/DST fields of the
> active PaRAM are read to determine the current position of
> the DMA engine. However, the AM335x Technical Reference Manual
> states:
> 
>   11.3.3.6 Parameter Set Updates
> 
>   After the TR is read from the PaRAM (and is in the process
>   of being submitted to the EDMA3TC), the following fields are
>   updated as needed: ... SRC DST
> 
> This means SRC/DST is incremented even though the DMA transfer
> may not have started yet or is in progress. Thus if the reader
> of the residue accesses the DMA buffer too quickly, the CPU is
> misinformed about the data that has been successfully processed.
> 
> The CCSTAT.ACTV register is a boolean that is set if any TR is
> being processed by either the EMDA3CC or EDMA3TC. By polling
> this register it is possible to ensure that the residue value
> returned is valid for immediate processing. However, since the
> DMA engine may be active, polling may never hit a moment where
> no TR is being processed. To handle this, the SRC/DST is also
> polled to see if it changes. And as a last resort, a max loop
> count for the busy waiting exists to avoid an infinite loop.
> 
> Signed-off-by: John Ogness <john.ogness at linutronix.de>

Acked-by: Peter Ujfalusi <peter.ujfalusi at ti.com>

> ---
>  v1-v2 changes
>  . rebased for next-20151016
>  . added multiple exit conditions for busy wait loop
> 
>  v2-v3 changes
>  . rebased for next-20160121
>  . reduced max loops from 10000 to 1000
>  . loop countdown instead of count
>  . change debug print function and message
>  . fine-tune comments
> 
>  v3-v4 changes
>  . rebased for next-20160128
>  . moved register bit definition
> 
>  drivers/dma/edma.c |   41 ++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 40 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index d92d655..e3d7fcb 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -113,6 +113,9 @@
>  #define GET_NUM_REGN(x)		((x & 0x300000) >> 20) /* bits 20-21 */
>  #define CHMAP_EXIST		BIT(24)
>  
> +/* CCSTAT register */
> +#define EDMA_CCSTAT_ACTV	BIT(4)
> +
>  /*
>   * Max of 20 segments per channel to conserve PaRAM slots
>   * Also note that MAX_NR_SG should be atleast the no.of periods
> @@ -1680,9 +1683,20 @@ static void edma_issue_pending(struct dma_chan *chan)
>  	spin_unlock_irqrestore(&echan->vchan.lock, flags);
>  }
>  
> +/*
> + * This limit exists to avoid a possible infinite loop when waiting for proof
> + * that a particular transfer is completed. This limit can be hit if there
> + * are large bursts to/from slow devices or the CPU is never able to catch
> + * the DMA hardware idle. On an AM335x transfering 48 bytes from the UART
> + * RX-FIFO, as many as 55 loops have been seen.
> + */
> +#define EDMA_MAX_TR_WAIT_LOOPS 1000
> +
>  static u32 edma_residue(struct edma_desc *edesc)
>  {
>  	bool dst = edesc->direction == DMA_DEV_TO_MEM;
> +	int loop_count = EDMA_MAX_TR_WAIT_LOOPS;
> +	struct edma_chan *echan = edesc->echan;
>  	struct edma_pset *pset = edesc->pset;
>  	dma_addr_t done, pos;
>  	int i;
> @@ -1691,7 +1705,32 @@ static u32 edma_residue(struct edma_desc *edesc)
>  	 * We always read the dst/src position from the first RamPar
>  	 * pset. That's the one which is active now.
>  	 */
> -	pos = edma_get_position(edesc->echan->ecc, edesc->echan->slot[0], dst);
> +	pos = edma_get_position(echan->ecc, echan->slot[0], dst);
> +
> +	/*
> +	 * "pos" may represent a transfer request that is still being
> +	 * processed by the EDMACC or EDMATC. We will busy wait until
> +	 * any one of the situations occurs:
> +	 *   1. the DMA hardware is idle
> +	 *   2. a new transfer request is setup
> +	 *   3. we hit the loop limit
> +	 */
> +	while (edma_read(echan->ecc, EDMA_CCSTAT) & EDMA_CCSTAT_ACTV) {
> +		/* check if a new transfer request is setup */
> +		if (edma_get_position(echan->ecc,
> +				      echan->slot[0], dst) != pos) {
> +			break;
> +		}
> +
> +		if (!--loop_count) {
> +			dev_dbg_ratelimited(echan->vchan.chan.device->dev,
> +				"%s: timeout waiting for PaRAM update\n",
> +				__func__);
> +			break;
> +		}
> +
> +		cpu_relax();
> +	}
>  
>  	/*
>  	 * Cyclic is simple. Just subtract pset[0].addr from pos.
> 


-- 
P?ter


From shawnguo at kernel.org  Mon Feb  1 05:55:07 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 1 Feb 2016 21:55:07 +0800
Subject: [PATCH 10/15] bus: imx-weim: use of_platform_default_populate()
 to populate default bus
In-Reply-To: <1453868872-26300-11-git-send-email-wangkefeng.wang@huawei.com>
References: <1453868872-26300-1-git-send-email-wangkefeng.wang@huawei.com>
 <1453868872-26300-11-git-send-email-wangkefeng.wang@huawei.com>
Message-ID: <20160201135507.GJ10671@tiger>

On Wed, Jan 27, 2016 at 12:27:47PM +0800, Kefeng Wang wrote:
> Use helper of_platform_default_populate() in linux/of_platform
> when possible, instead of calling of_platform_populate() with
> the default match table.
> 
> Cc: Signed-off-by: Huang Shijie <b32955 at freescale.com>
> Cc: Shawn Guo <shawn.guo at linaro.org>
> Signed-off-by: Kefeng Wang <wangkefeng.wang at huawei.com>

Acked-by: Shawn Guo <shawn.guo at linaro.org>

> ---
>  drivers/bus/imx-weim.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
> index e98d15e..557a71c 100644
> --- a/drivers/bus/imx-weim.c
> +++ b/drivers/bus/imx-weim.c
> @@ -163,9 +163,8 @@ static int __init weim_parse_dt(struct platform_device *pdev,
>  	}
>  
>  	if (have_child)
> -		ret = of_platform_populate(pdev->dev.of_node,
> -				   of_default_bus_match_table,
> -				   NULL, &pdev->dev);
> +		ret = of_platform_default_populate(pdev->dev.of_node,
> +						   NULL, &pdev->dev);
>  	if (ret)
>  		dev_err(&pdev->dev, "%s fail to create devices.\n",
>  			pdev->dev.of_node->full_name);
> -- 
> 2.6.0.GIT
> 
> 


From ulf.hansson at linaro.org  Mon Feb  1 05:57:36 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Mon, 1 Feb 2016 14:57:36 +0100
Subject: [PATCH] PM / Domains: mark genpd_poweron as __maybe_unused
In-Reply-To: <3864075.BdhPDUQ9fB@wuerfel>
References: <3864075.BdhPDUQ9fB@wuerfel>
Message-ID: <CAPDyKFpHBgaQEz6kYvhV=2pLPLAtVxQjbnqL4CPv0vyvHZbHWA@mail.gmail.com>

On 1 February 2016 at 11:38, Arnd Bergmann <arnd at arndb.de> wrote:
> The rework of the power domain code has made the genpd_poweron()
> function local to the file it's defined in, and the only remaining
> caller is conditionally compiled based on CONFIG_PM_GENERIC_DOMAINS_OF,
> so we get a warning when that is disabled:
>
> drivers/base/power/domain.c:234:12: error: 'genpd_poweron' defined but not used [-Werror=unused-function]
>
> This adds a __maybe_unused annotation to the function so gcc can
> figure out by itself that it should silently remove the definition
> in this case.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: ea823c7cbffa ("PM / Domains: Remove pm_genpd_poweron() API")

Arnd,

Thanks for fixing and reporting!

Looking a bit closer to the genpd code in this reagrds, made me
realize that I think there's a better approach to fix this.
Instead of going into the details for how, I decided to send a
separate patch. You are on cc.

"[PATCH] PM / Domains: Silence compiler warning for an unused function".

Kind regards
Uffe


From christoffer.dall at linaro.org  Mon Feb  1 05:59:09 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 14:59:09 +0100
Subject: [PATCH v2 11/21] arm64: KVM: VHE: Use unified system register
 accessors
In-Reply-To: <1453737235-16522-12-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-12-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201135909.GM1478@cbox>

On Mon, Jan 25, 2016 at 03:53:45PM +0000, Marc Zyngier wrote:
> Use the recently introduced unified system register accessors for
> those sysregs that behave differently depending on VHE being in
> use or not.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>

> ---
>  arch/arm64/kvm/hyp/sysreg-sr.c | 84 +++++++++++++++++++++---------------------
>  1 file changed, 42 insertions(+), 42 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
> index 61bad17..7d7d757 100644
> --- a/arch/arm64/kvm/hyp/sysreg-sr.c
> +++ b/arch/arm64/kvm/hyp/sysreg-sr.c
> @@ -37,34 +37,34 @@ static void __hyp_text __sysreg_save_common_state(struct kvm_cpu_context *ctxt)
>  	ctxt->sys_regs[TPIDRRO_EL0]	= read_sysreg(tpidrro_el0);
>  	ctxt->sys_regs[TPIDR_EL1]	= read_sysreg(tpidr_el1);
>  	ctxt->gp_regs.regs.sp		= read_sysreg(sp_el0);
> -	ctxt->gp_regs.regs.pc		= read_sysreg(elr_el2);
> -	ctxt->gp_regs.regs.pstate	= read_sysreg(spsr_el2);
> +	ctxt->gp_regs.regs.pc		= read_sysreg_el2(elr);
> +	ctxt->gp_regs.regs.pstate	= read_sysreg_el2(spsr);
>  }
>  
>  static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
>  {
>  	ctxt->sys_regs[MPIDR_EL1]	= read_sysreg(vmpidr_el2);
>  	ctxt->sys_regs[CSSELR_EL1]	= read_sysreg(csselr_el1);
> -	ctxt->sys_regs[SCTLR_EL1]	= read_sysreg(sctlr_el1);
> -	ctxt->sys_regs[CPACR_EL1]	= read_sysreg(cpacr_el1);
> -	ctxt->sys_regs[TTBR0_EL1]	= read_sysreg(ttbr0_el1);
> -	ctxt->sys_regs[TTBR1_EL1]	= read_sysreg(ttbr1_el1);
> -	ctxt->sys_regs[TCR_EL1]		= read_sysreg(tcr_el1);
> -	ctxt->sys_regs[ESR_EL1]		= read_sysreg(esr_el1);
> -	ctxt->sys_regs[AFSR0_EL1]	= read_sysreg(afsr0_el1);
> -	ctxt->sys_regs[AFSR1_EL1]	= read_sysreg(afsr1_el1);
> -	ctxt->sys_regs[FAR_EL1]		= read_sysreg(far_el1);
> -	ctxt->sys_regs[MAIR_EL1]	= read_sysreg(mair_el1);
> -	ctxt->sys_regs[VBAR_EL1]	= read_sysreg(vbar_el1);
> -	ctxt->sys_regs[CONTEXTIDR_EL1]	= read_sysreg(contextidr_el1);
> -	ctxt->sys_regs[AMAIR_EL1]	= read_sysreg(amair_el1);
> -	ctxt->sys_regs[CNTKCTL_EL1]	= read_sysreg(cntkctl_el1);
> +	ctxt->sys_regs[SCTLR_EL1]	= read_sysreg_el1(sctlr);
> +	ctxt->sys_regs[CPACR_EL1]	= read_sysreg_el1(cpacr);
> +	ctxt->sys_regs[TTBR0_EL1]	= read_sysreg_el1(ttbr0);
> +	ctxt->sys_regs[TTBR1_EL1]	= read_sysreg_el1(ttbr1);
> +	ctxt->sys_regs[TCR_EL1]		= read_sysreg_el1(tcr);
> +	ctxt->sys_regs[ESR_EL1]		= read_sysreg_el1(esr);
> +	ctxt->sys_regs[AFSR0_EL1]	= read_sysreg_el1(afsr0);
> +	ctxt->sys_regs[AFSR1_EL1]	= read_sysreg_el1(afsr1);
> +	ctxt->sys_regs[FAR_EL1]		= read_sysreg_el1(far);
> +	ctxt->sys_regs[MAIR_EL1]	= read_sysreg_el1(mair);
> +	ctxt->sys_regs[VBAR_EL1]	= read_sysreg_el1(vbar);
> +	ctxt->sys_regs[CONTEXTIDR_EL1]	= read_sysreg_el1(contextidr);
> +	ctxt->sys_regs[AMAIR_EL1]	= read_sysreg_el1(amair);
> +	ctxt->sys_regs[CNTKCTL_EL1]	= read_sysreg_el1(cntkctl);
>  	ctxt->sys_regs[PAR_EL1]		= read_sysreg(par_el1);
>  	ctxt->sys_regs[MDSCR_EL1]	= read_sysreg(mdscr_el1);
>  
>  	ctxt->gp_regs.sp_el1		= read_sysreg(sp_el1);
> -	ctxt->gp_regs.elr_el1		= read_sysreg(elr_el1);
> -	ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg(spsr_el1);
> +	ctxt->gp_regs.elr_el1		= read_sysreg_el1(elr);
> +	ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg_el1(spsr);
>  }
>  
>  void __hyp_text __sysreg_save_host_state(struct kvm_cpu_context *ctxt)
> @@ -86,34 +86,34 @@ static void __hyp_text __sysreg_restore_common_state(struct kvm_cpu_context *ctx
>  	write_sysreg(ctxt->sys_regs[TPIDRRO_EL0], tpidrro_el0);
>  	write_sysreg(ctxt->sys_regs[TPIDR_EL1],	  tpidr_el1);
>  	write_sysreg(ctxt->gp_regs.regs.sp,	  sp_el0);
> -	write_sysreg(ctxt->gp_regs.regs.pc,	  elr_el2);
> -	write_sysreg(ctxt->gp_regs.regs.pstate,	  spsr_el2);
> +	write_sysreg_el2(ctxt->gp_regs.regs.pc,	  elr);
> +	write_sysreg_el2(ctxt->gp_regs.regs.pstate, spsr);
>  }
>  
>  static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
>  {
> -	write_sysreg(ctxt->sys_regs[MPIDR_EL1],	  vmpidr_el2);
> -	write_sysreg(ctxt->sys_regs[CSSELR_EL1],  csselr_el1);
> -	write_sysreg(ctxt->sys_regs[SCTLR_EL1],	  sctlr_el1);
> -	write_sysreg(ctxt->sys_regs[CPACR_EL1],	  cpacr_el1);
> -	write_sysreg(ctxt->sys_regs[TTBR0_EL1],	  ttbr0_el1);
> -	write_sysreg(ctxt->sys_regs[TTBR1_EL1],	  ttbr1_el1);
> -	write_sysreg(ctxt->sys_regs[TCR_EL1],	  tcr_el1);
> -	write_sysreg(ctxt->sys_regs[ESR_EL1],	  esr_el1);
> -	write_sysreg(ctxt->sys_regs[AFSR0_EL1],	  afsr0_el1);
> -	write_sysreg(ctxt->sys_regs[AFSR1_EL1],	  afsr1_el1);
> -	write_sysreg(ctxt->sys_regs[FAR_EL1],	  far_el1);
> -	write_sysreg(ctxt->sys_regs[MAIR_EL1],	  mair_el1);
> -	write_sysreg(ctxt->sys_regs[VBAR_EL1],	  vbar_el1);
> -	write_sysreg(ctxt->sys_regs[CONTEXTIDR_EL1], contextidr_el1);
> -	write_sysreg(ctxt->sys_regs[AMAIR_EL1],	  amair_el1);
> -	write_sysreg(ctxt->sys_regs[CNTKCTL_EL1], cntkctl_el1);
> -	write_sysreg(ctxt->sys_regs[PAR_EL1],	  par_el1);
> -	write_sysreg(ctxt->sys_regs[MDSCR_EL1],	  mdscr_el1);
> -
> -	write_sysreg(ctxt->gp_regs.sp_el1,	sp_el1);
> -	write_sysreg(ctxt->gp_regs.elr_el1,	elr_el1);
> -	write_sysreg(ctxt->gp_regs.spsr[KVM_SPSR_EL1], spsr_el1);
> +	write_sysreg(ctxt->sys_regs[MPIDR_EL1],		vmpidr_el2);
> +	write_sysreg(ctxt->sys_regs[CSSELR_EL1],	csselr_el1);
> +	write_sysreg_el1(ctxt->sys_regs[SCTLR_EL1],	sctlr);
> +	write_sysreg_el1(ctxt->sys_regs[CPACR_EL1],	cpacr);
> +	write_sysreg_el1(ctxt->sys_regs[TTBR0_EL1],	ttbr0);
> +	write_sysreg_el1(ctxt->sys_regs[TTBR1_EL1],	ttbr1);
> +	write_sysreg_el1(ctxt->sys_regs[TCR_EL1],	tcr);
> +	write_sysreg_el1(ctxt->sys_regs[ESR_EL1],	esr);
> +	write_sysreg_el1(ctxt->sys_regs[AFSR0_EL1],	afsr0);
> +	write_sysreg_el1(ctxt->sys_regs[AFSR1_EL1],	afsr1);
> +	write_sysreg_el1(ctxt->sys_regs[FAR_EL1],	far);
> +	write_sysreg_el1(ctxt->sys_regs[MAIR_EL1],	mair);
> +	write_sysreg_el1(ctxt->sys_regs[VBAR_EL1],	vbar);
> +	write_sysreg_el1(ctxt->sys_regs[CONTEXTIDR_EL1],contextidr);
> +	write_sysreg_el1(ctxt->sys_regs[AMAIR_EL1],	amair);
> +	write_sysreg_el1(ctxt->sys_regs[CNTKCTL_EL1], 	cntkctl);
> +	write_sysreg(ctxt->sys_regs[PAR_EL1],		par_el1);
> +	write_sysreg(ctxt->sys_regs[MDSCR_EL1],		mdscr_el1);
> +
> +	write_sysreg(ctxt->gp_regs.sp_el1,		sp_el1);
> +	write_sysreg_el1(ctxt->gp_regs.elr_el1,		elr);
> +	write_sysreg_el1(ctxt->gp_regs.spsr[KVM_SPSR_EL1],spsr);
>  }
>  
>  void __hyp_text __sysreg_restore_host_state(struct kvm_cpu_context *ctxt)
> -- 
> 2.1.4
> 


From christoffer.dall at linaro.org  Mon Feb  1 05:59:14 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 14:59:14 +0100
Subject: [PATCH v2 01/21] arm/arm64: Add new is_kernel_in_hyp_mode
 predicate
In-Reply-To: <1453737235-16522-2-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-2-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201135914.GN1478@cbox>

On Mon, Jan 25, 2016 at 03:53:35PM +0000, Marc Zyngier wrote:
> With ARMv8.1 VHE extension, it will be possible to run the kernel
> at EL2 (aka HYP mode). In order for the kernel to easily find out
> where it is running, add a new predicate that returns whether or
> not the kernel is in HYP mode.
> 
> For completeness, the 32bit code also get such a predicate (always
> returning false) so that code common to both architecture (timers,
> KVM) can use it transparently.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>

> ---
>  arch/arm/include/asm/virt.h   |  5 +++++
>  arch/arm64/include/asm/virt.h | 10 ++++++++++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
> index 4371f45..b6a3cef 100644
> --- a/arch/arm/include/asm/virt.h
> +++ b/arch/arm/include/asm/virt.h
> @@ -74,6 +74,11 @@ static inline bool is_hyp_mode_mismatched(void)
>  {
>  	return !!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH);
>  }
> +
> +static inline bool is_kernel_in_hyp_mode(void)
> +{
> +	return false;
> +}
>  #endif
>  
>  #endif /* __ASSEMBLY__ */
> diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
> index 7a5df52..9f22dd6 100644
> --- a/arch/arm64/include/asm/virt.h
> +++ b/arch/arm64/include/asm/virt.h
> @@ -23,6 +23,8 @@
>  
>  #ifndef __ASSEMBLY__
>  
> +#include <asm/ptrace.h>
> +
>  /*
>   * __boot_cpu_mode records what mode CPUs were booted in.
>   * A correctly-implemented bootloader must start all CPUs in the same mode:
> @@ -50,6 +52,14 @@ static inline bool is_hyp_mode_mismatched(void)
>  	return __boot_cpu_mode[0] != __boot_cpu_mode[1];
>  }
>  
> +static inline bool is_kernel_in_hyp_mode(void)
> +{
> +	u64 el;
> +
> +	asm("mrs %0, CurrentEL" : "=r" (el));
> +	return el == CurrentEL_EL2;
> +}
> +
>  /* The section containing the hypervisor text */
>  extern char __hyp_text_start[];
>  extern char __hyp_text_end[];
> -- 
> 2.1.4
> 


From christoffer.dall at linaro.org  Mon Feb  1 05:59:22 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 14:59:22 +0100
Subject: [PATCH v2 03/21] arm64: Add ARM64_HAS_VIRT_HOST_EXTN feature
In-Reply-To: <1453737235-16522-4-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-4-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201135922.GO1478@cbox>

On Mon, Jan 25, 2016 at 03:53:37PM +0000, Marc Zyngier wrote:
> Add a new ARM64_HAS_VIRT_HOST_EXTN features to indicate that the
> CPU has the ARMv8.1 VHE capability.
> 
> This will be used to trigger kernel patching in KVM.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/cpufeature.h |  3 ++-
>  arch/arm64/kernel/cpufeature.c      | 15 +++++++++++++--
>  2 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index 8f271b8..c705d6a 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -30,8 +30,9 @@
>  #define ARM64_HAS_LSE_ATOMICS			5
>  #define ARM64_WORKAROUND_CAVIUM_23154		6
>  #define ARM64_WORKAROUND_834220			7
> +#define ARM64_HAS_VIRT_HOST_EXTN		8
>  
> -#define ARM64_NCAPS				8
> +#define ARM64_NCAPS				9
>  
>  #ifndef __ASSEMBLY__
>  
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 5c90aa4..8d3961e 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -26,6 +26,9 @@
>  #include <asm/cpu_ops.h>
>  #include <asm/processor.h>
>  #include <asm/sysreg.h>
> +#include <asm/virt.h>
> +
> +#include <linux/irqchip/arm-gic-v3.h>
>  
>  unsigned long elf_hwcap __read_mostly;
>  EXPORT_SYMBOL_GPL(elf_hwcap);
> @@ -587,8 +590,6 @@ u64 read_system_reg(u32 id)
>  	return regp->sys_val;
>  }
>  
> -#include <linux/irqchip/arm-gic-v3.h>
> -

unrelated change?

>  static bool
>  feature_matches(u64 reg, const struct arm64_cpu_capabilities *entry)
>  {
> @@ -621,6 +622,11 @@ static bool has_useable_gicv3_cpuif(const struct arm64_cpu_capabilities *entry)
>  	return has_sre;
>  }
>  
> +static bool runs_at_el2(const struct arm64_cpu_capabilities *entry)
> +{
> +	return is_kernel_in_hyp_mode();
> +}
> +
>  static const struct arm64_cpu_capabilities arm64_features[] = {
>  	{
>  		.desc = "GIC system register CPU interface",
> @@ -651,6 +657,11 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
>  		.min_field_value = 2,
>  	},
>  #endif /* CONFIG_AS_LSE && CONFIG_ARM64_LSE_ATOMICS */
> +	{
> +		.desc = "Virtualization Host Extensions",
> +		.capability = ARM64_HAS_VIRT_HOST_EXTN,
> +		.matches = runs_at_el2,
> +	},
>  	{},
>  };
>  
> -- 
> 2.1.4
> 

Otherwise:
Acked-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Mon Feb  1 05:59:28 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 14:59:28 +0100
Subject: [PATCH v2 04/21] arm64: KVM: Skip HYP setup when already running
 in HYP
In-Reply-To: <1453737235-16522-5-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-5-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201135928.GP1478@cbox>

On Mon, Jan 25, 2016 at 03:53:38PM +0000, Marc Zyngier wrote:
> With the kernel running at EL2, there is no point trying to
> configure page tables for HYP, as the kernel is already mapped.
> 
> Take this opportunity to refactor the whole init a bit, allowing
> the various parts of the hypervisor bringup to be split across
> multiple functions.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>

> ---
>  arch/arm/kvm/arm.c | 151 +++++++++++++++++++++++++++++++++--------------------
>  arch/arm/kvm/mmu.c |   7 +++
>  2 files changed, 100 insertions(+), 58 deletions(-)
> 
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index dda1959..66e2d04 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -1035,6 +1035,67 @@ static inline void hyp_cpu_pm_init(void)
>  }
>  #endif
>  
> +static void teardown_common_resources(void)
> +{
> +	free_percpu(kvm_host_cpu_state);
> +}
> +
> +static int init_common_resources(void)
> +{
> +	kvm_host_cpu_state = alloc_percpu(kvm_cpu_context_t);
> +	if (!kvm_host_cpu_state) {
> +		kvm_err("Cannot allocate host CPU state\n");
> +		return -ENOMEM;
> +	}
> +
> +	return 0;
> +}
> +
> +static int init_subsystems(void)
> +{
> +	int err;
> +
> +	/*
> +	 * Init HYP view of VGIC
> +	 */
> +	err = kvm_vgic_hyp_init();
> +	switch (err) {
> +	case 0:
> +		vgic_present = true;
> +		break;
> +	case -ENODEV:
> +	case -ENXIO:
> +		vgic_present = false;
> +		break;
> +	default:
> +		return err;
> +	}
> +
> +	/*
> +	 * Init HYP architected timer support
> +	 */
> +	err = kvm_timer_hyp_init();
> +	if (err)
> +		return err;
> +
> +	kvm_perf_init();
> +	kvm_coproc_table_init();
> +
> +	return 0;
> +}
> +
> +static void teardown_hyp_mode(void)
> +{
> +	int cpu;
> +
> +	if (is_kernel_in_hyp_mode())
> +		return;
> +
> +	free_hyp_pgds();
> +	for_each_possible_cpu(cpu)
> +		free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
> +}
> +
>  /**
>   * Inits Hyp-mode on all online CPUs
>   */
> @@ -1043,6 +1104,9 @@ static int init_hyp_mode(void)
>  	int cpu;
>  	int err = 0;
>  
> +	if (is_kernel_in_hyp_mode())
> +		return 0;
> +
>  	/*
>  	 * Allocate Hyp PGD and setup Hyp identity mapping
>  	 */
> @@ -1065,7 +1129,7 @@ static int init_hyp_mode(void)
>  		stack_page = __get_free_page(GFP_KERNEL);
>  		if (!stack_page) {
>  			err = -ENOMEM;
> -			goto out_free_stack_pages;
> +			goto out_err;
>  		}
>  
>  		per_cpu(kvm_arm_hyp_stack_page, cpu) = stack_page;
> @@ -1077,13 +1141,13 @@ static int init_hyp_mode(void)
>  	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
>  	if (err) {
>  		kvm_err("Cannot map world-switch code\n");
> -		goto out_free_mappings;
> +		goto out_err;
>  	}
>  
>  	err = create_hyp_mappings(__start_rodata, __end_rodata);
>  	if (err) {
>  		kvm_err("Cannot map rodata section\n");
> -		goto out_free_mappings;
> +		goto out_err;
>  	}
>  
>  	/*
> @@ -1095,20 +1159,10 @@ static int init_hyp_mode(void)
>  
>  		if (err) {
>  			kvm_err("Cannot map hyp stack\n");
> -			goto out_free_mappings;
> +			goto out_err;
>  		}
>  	}
>  
> -	/*
> -	 * Map the host CPU structures
> -	 */
> -	kvm_host_cpu_state = alloc_percpu(kvm_cpu_context_t);
> -	if (!kvm_host_cpu_state) {
> -		err = -ENOMEM;
> -		kvm_err("Cannot allocate host CPU state\n");
> -		goto out_free_mappings;
> -	}
> -
>  	for_each_possible_cpu(cpu) {
>  		kvm_cpu_context_t *cpu_ctxt;
>  
> @@ -1117,7 +1171,7 @@ static int init_hyp_mode(void)
>  
>  		if (err) {
>  			kvm_err("Cannot map host CPU state: %d\n", err);
> -			goto out_free_context;
> +			goto out_err;
>  		}
>  	}
>  
> @@ -1126,34 +1180,22 @@ static int init_hyp_mode(void)
>  	 */
>  	on_each_cpu(cpu_init_hyp_mode, NULL, 1);
>  
> -	/*
> -	 * Init HYP view of VGIC
> -	 */
> -	err = kvm_vgic_hyp_init();
> -	switch (err) {
> -	case 0:
> -		vgic_present = true;
> -		break;
> -	case -ENODEV:
> -	case -ENXIO:
> -		vgic_present = false;
> -		break;
> -	default:
> -		goto out_free_context;
> -	}
> -
> -	/*
> -	 * Init HYP architected timer support
> -	 */
> -	err = kvm_timer_hyp_init();
> -	if (err)
> -		goto out_free_context;
> -
>  #ifndef CONFIG_HOTPLUG_CPU
>  	free_boot_hyp_pgd();
>  #endif
>  
> -	kvm_perf_init();
> +	cpu_notifier_register_begin();
> +
> +	err = __register_cpu_notifier(&hyp_init_cpu_nb);
> +
> +	cpu_notifier_register_done();
> +
> +	if (err) {
> +		kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
> +		goto out_err;
> +	}
> +
> +	hyp_cpu_pm_init();
>  
>  	/* set size of VMID supported by CPU */
>  	kvm_vmid_bits = kvm_get_vmid_bits();
> @@ -1162,14 +1204,9 @@ static int init_hyp_mode(void)
>  	kvm_info("Hyp mode initialized successfully\n");
>  
>  	return 0;
> -out_free_context:
> -	free_percpu(kvm_host_cpu_state);
> -out_free_mappings:
> -	free_hyp_pgds();
> -out_free_stack_pages:
> -	for_each_possible_cpu(cpu)
> -		free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
> +
>  out_err:
> +	teardown_hyp_mode();
>  	kvm_err("error initializing Hyp mode: %d\n", err);
>  	return err;
>  }
> @@ -1213,26 +1250,24 @@ int kvm_arch_init(void *opaque)
>  		}
>  	}
>  
> -	cpu_notifier_register_begin();
> +	err = init_common_resources();
> +	if (err)
> +		return err;
>  
>  	err = init_hyp_mode();
>  	if (err)
>  		goto out_err;
>  
> -	err = __register_cpu_notifier(&hyp_init_cpu_nb);
> -	if (err) {
> -		kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
> -		goto out_err;
> -	}
> -
> -	cpu_notifier_register_done();
> -
> -	hyp_cpu_pm_init();
> +	err = init_subsystems();
> +	if (err)
> +		goto out_hyp;
>  
> -	kvm_coproc_table_init();
>  	return 0;
> +
> +out_hyp:
> +	teardown_hyp_mode();
>  out_err:
> -	cpu_notifier_register_done();
> +	teardown_common_resources();
>  	return err;
>  }
>  
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index aba61fd..920d0c3 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -28,6 +28,7 @@
>  #include <asm/kvm_mmio.h>
>  #include <asm/kvm_asm.h>
>  #include <asm/kvm_emulate.h>
> +#include <asm/virt.h>
>  
>  #include "trace.h"
>  
> @@ -598,6 +599,9 @@ int create_hyp_mappings(void *from, void *to)
>  	unsigned long start = KERN_TO_HYP((unsigned long)from);
>  	unsigned long end = KERN_TO_HYP((unsigned long)to);
>  
> +	if (is_kernel_in_hyp_mode())
> +		return 0;
> +
>  	start = start & PAGE_MASK;
>  	end = PAGE_ALIGN(end);
>  
> @@ -630,6 +634,9 @@ int create_hyp_io_mappings(void *from, void *to, phys_addr_t phys_addr)
>  	unsigned long start = KERN_TO_HYP((unsigned long)from);
>  	unsigned long end = KERN_TO_HYP((unsigned long)to);
>  
> +	if (is_kernel_in_hyp_mode())
> +		return 0;
> +
>  	/* Check for a valid kernel IO mapping */
>  	if (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1))
>  		return -EINVAL;
> -- 
> 2.1.4
> 


From christoffer.dall at linaro.org  Mon Feb  1 05:59:33 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 14:59:33 +0100
Subject: [PATCH v2 09/21] arm64: KVM: VHE: Differenciate host/guest
 sysreg save/restore
In-Reply-To: <1453737235-16522-10-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-10-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201135933.GQ1478@cbox>

On Mon, Jan 25, 2016 at 03:53:43PM +0000, Marc Zyngier wrote:
> With ARMv8, host and guest share the same system register file,
> making the save/restore procedure completely symetrical.
> With VHE, host and guest now have different requirements, as they
> use different sysregs.
> 
> In order to prepare for this, add split sysreg save/restore functions
> for both host and guest. No functionnal change yet.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Mon Feb  1 06:02:13 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 15:02:13 +0100
Subject: [PATCH v2 12/21] arm64: KVM: VHE: Enable minimal sysreg
 save/restore
In-Reply-To: <1453737235-16522-13-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-13-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201140213.GR1478@cbox>

On Mon, Jan 25, 2016 at 03:53:46PM +0000, Marc Zyngier wrote:
> We're now in a position where we can introduce VHE's minimal
> save/restore, which is limited to the handful of shared sysregs.
> 
> Add the required alternative function calls that result in a
> "do nothing" call on VHE, and the normal save/restore for non-VHE.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/hyp/sysreg-sr.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
> index 7d7d757..36bbdec 100644
> --- a/arch/arm64/kvm/hyp/sysreg-sr.c
> +++ b/arch/arm64/kvm/hyp/sysreg-sr.c
> @@ -23,6 +23,9 @@
>  
>  #include "hyp.h"
>  
> +/* Yes, this does nothing, on purpose */
> +static void __hyp_text __sysreg_do_nothing(struct kvm_cpu_context *ctxt) { }
> +
>  /*
>   * Non-VHE: Both host and guest must save everything.
>   *
> @@ -67,9 +70,13 @@ static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
>  	ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg_el1(spsr);
>  }
>  
> +static hyp_alternate_select(__sysreg_call_save_state,

__sysreg_call_save_host_state for symmetry with the restore path below?

> +			    __sysreg_save_state, __sysreg_do_nothing,
> +			    ARM64_HAS_VIRT_HOST_EXTN);
> +
>  void __hyp_text __sysreg_save_host_state(struct kvm_cpu_context *ctxt)
>  {
> -	__sysreg_save_state(ctxt);
> +	__sysreg_call_save_state()(ctxt);
>  	__sysreg_save_common_state(ctxt);
>  }
>  
> @@ -116,9 +123,13 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
>  	write_sysreg_el1(ctxt->gp_regs.spsr[KVM_SPSR_EL1],spsr);
>  }
>  
> +static hyp_alternate_select(__sysreg_call_restore_host_state,
> +			    __sysreg_restore_state, __sysreg_do_nothing,
> +			    ARM64_HAS_VIRT_HOST_EXTN);
> +
>  void __hyp_text __sysreg_restore_host_state(struct kvm_cpu_context *ctxt)
>  {
> -	__sysreg_restore_state(ctxt);
> +	__sysreg_call_restore_host_state()(ctxt);
>  	__sysreg_restore_common_state(ctxt);
>  }
>  
> -- 
> 2.1.4
> 

Otherwise:

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From shawnguo at kernel.org  Mon Feb  1 06:03:01 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 1 Feb 2016 22:03:01 +0800
Subject: [PATCH net-next 39/40] ARM: dts: imx6qdl-nitrogen6x: add phy
 interrupt to eliminate polling
In-Reply-To: <1454016364-30985-40-git-send-email-troy.kisky@boundarydevices.com>
References: <1454016364-30985-1-git-send-email-troy.kisky@boundarydevices.com>
 <1454016364-30985-40-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <20160201140301.GK10671@tiger>

On Thu, Jan 28, 2016 at 02:26:03PM -0700, Troy Kisky wrote:
> Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
> ---
>  arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> index caeed56..1d42331 100644
> --- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> @@ -288,6 +288,15 @@
>  	interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
>  			      <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
>  	status = "okay";
> +	phy-handle = <&ethphy>;

Have a new line between properties and sub-node.

> +	mdio {
> +		#address-cells = <0>;
> +		#size-cells = <1>;

Ditto

Shawn

> +		ethphy: ethernet-phy at 6 {
> +			reg = <6>;
> +			interrupts-extended = <&gpio1 28 IRQ_TYPE_LEVEL_LOW>;
> +		};
> +	};
>  };
>  
>  &hdmi {
> @@ -409,6 +418,8 @@
>  				/* Phy reset */
>  				MX6QDL_PAD_ENET_RXD0__GPIO1_IO27	0x000b0
>  				MX6QDL_PAD_GPIO_6__ENET_IRQ		0x000b1
> +				/* ethernet phy interrupt */
> +				MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28	0x1b0b0
>  			>;
>  		};
>  
> -- 
> 2.5.0
> 
> 


From will.deacon at arm.com  Mon Feb  1 06:03:51 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 1 Feb 2016 14:03:51 +0000
Subject: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
In-Reply-To: <56ABD8E0.6080409@linaro.org>
References: <1453813968-2024-1-git-send-email-eric.auger@linaro.org>
 <1454017899.23148.0.camel@redhat.com> <56AB78B1.2030202@linaro.org>
 <1454096004.9301.1.camel@redhat.com> <56ABD8E0.6080409@linaro.org>
Message-ID: <20160201140351.GE6828@arm.com>

On Fri, Jan 29, 2016 at 10:25:52PM +0100, Eric Auger wrote:
> On 01/29/2016 08:33 PM, Alex Williamson wrote:
> >>> We know that x86 handles MSI vectors specially, so there is some
> >>> hardware that helps the situation.  It's not just that x86 has a fixed
> >>> range for MSI, it's how it manages that range when interrupt remapping
> >>> hardware is enabled.  A device table indexed by source-ID references a
> >>> per device table indexed by data from the MSI write itself.  So we get
> >>> much, much finer granularity,
> >> About the granularity, I think ARM GICv3 now provides a similar
> >> capability with GICv3 ITS (interrupt translation service). Along with
> >> the MSI MSG write transaction, the device outputs a DeviceID conveyed on
> >> the bus. This DeviceID (~ your source-ID) enables to index a device
> >> table. The entry in the device table points to a DeviceId interrupt
> >> translation table indexed by the EventID found in the msi msg. So the
> >> entry in the interrupt translation table eventually gives you the
> >> eventual interrupt ID targeted by the MSI MSG.
> >> This translation capability if not available in GICv2M though, ie. the
> >> one I am currently using.
> >>  
> >> Those tables currently are built by the ITS irqchip (irq-gic-v3-its.c)

That's right. GICv3/ITS disambiguates the interrupt source using the
DeviceID, which for PCI is derived from the Requester ID of the endpoint.
GICv2m is less flexible and requires a separate physical frame per guest
to achieve isolation.

Will


From shawnguo at kernel.org  Mon Feb  1 06:04:20 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 1 Feb 2016 22:04:20 +0800
Subject: [PATCH net-next 40/40] ARM: dts: imx6qdl-nitrogen6_max: add phy
 interrupt to eliminate polling
In-Reply-To: <1454016364-30985-41-git-send-email-troy.kisky@boundarydevices.com>
References: <1454016364-30985-1-git-send-email-troy.kisky@boundarydevices.com>
 <1454016364-30985-41-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <20160201140420.GL10671@tiger>

On Thu, Jan 28, 2016 at 02:26:04PM -0700, Troy Kisky wrote:
> Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
> ---
>  arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> index a35d54f..771f650 100644
> --- a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> @@ -386,6 +386,15 @@
>  	interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
>  			      <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
>  	status = "okay";
> +	phy-handle = <&ethphy>;

Please keep 'status' at the bottom of the property list.

Shawn

> +	mdio {
> +		#address-cells = <0>;
> +		#size-cells = <1>;
> +		ethphy: ethernet-phy at 6 {
> +			reg = <6>;
> +			interrupts-extended = <&gpio1 28 IRQ_TYPE_LEVEL_LOW>;
> +		};
> +	};
>  };
>  
>  &hdmi {
> -- 
> 2.5.0
> 
> 


From marc.zyngier at arm.com  Mon Feb  1 06:04:39 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 1 Feb 2016 14:04:39 +0000
Subject: [PATCH v2 08/21] arm64: KVM: VHE: Introduce unified system
 register accessors
In-Reply-To: <20160201134732.GK1478@cbox>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-9-git-send-email-marc.zyngier@arm.com>
 <20160201134732.GK1478@cbox>
Message-ID: <56AF65F7.5000404@arm.com>

On 01/02/16 13:47, Christoffer Dall wrote:
> On Mon, Jan 25, 2016 at 03:53:42PM +0000, Marc Zyngier wrote:
>> VHE brings its own bag of new system registers, or rather system
>> register accessors, as it define new ways to access both guest
>> and host system registers. For example, from the host:
>>
>> - The host TCR_EL2 register is accessed using the TCR_EL1 accessor
>> - The guest TCR_EL1 register is accessed using the TCR_EL12 accessor
>>
>> Obviously, this is confusing. A way to somehow reduce the complexity
>> of writing code for both ARMv8 and ARMv8.1 is to use a set of unified
>> accessors that will generate the right sysreg, depending on the mode
>> the CPU is running in. For example:
>>
>> - read_sysreg_el1(tcr) will use TCR_EL1 on ARMv8, and TCR_EL12 on
>>   ARMv8.1 with VHE.
>> - read_sysreg_el2(tcr) will use TCR_EL2 on ARMv8, and TCR_EL1 on
>>   ARMv8.1 with VHE.
>>
>> We end up with three sets of accessors ({read,write}_sysreg_el[012])
>> that can be directly used from C code. We take this opportunity to
>> also add the definition for the new VHE sysregs.(
> 
> weird closing parenthesis.
> 
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kvm/hyp/hyp.h | 72 ++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 72 insertions(+)
>>
>> diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
>> index fc502f3..744c919 100644
>> --- a/arch/arm64/kvm/hyp/hyp.h
>> +++ b/arch/arm64/kvm/hyp/hyp.h
>> @@ -48,6 +48,78 @@ static inline unsigned long __hyp_kern_va(unsigned long v)
>>  
>>  #define hyp_kern_va(v) (typeof(v))(__hyp_kern_va((unsigned long)(v)))
>>  
>> +#define read_sysreg_elx(r,nvh,vh)					\
>> +	({								\
>> +		u64 reg;						\
>> +		asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##nvh),\
>> +					 "mrs_s %0, " __stringify(r##vh),\
>> +					 ARM64_HAS_VIRT_HOST_EXTN)	\
>> +			     : "=r" (reg));				\
>> +		reg;							\
>> +	})
>> +
>> +#define write_sysreg_elx(v,r,nvh,vh)					\
>> +	do {								\
>> +		u64 __val = (u64)(v);					\
>> +		asm volatile(ALTERNATIVE("msr " __stringify(r##nvh) ", %x0",\
>> +					 "msr_s " __stringify(r##vh) ", %x0",\
>> +					 ARM64_HAS_VIRT_HOST_EXTN)	\
>> +					 : : "rZ" (__val));		\
> 
> what is rZ ?
> (complete Google-fu failure misery)

This gives the assembler the opportunity to generate a XZR register
access if the value is zero. See:

https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints

> 
>> +	} while (0)
>> +
>> +/*
>> + * Unified accessors for registers that have a different encoding
>> + * between VHE and non-VHE. They must be specified without their "ELx"
>> + * encoding.
>> + */
>> +#define read_sysreg_el2(r)						\
>> +	({								\
>> +		u64 reg;						\
>> +		asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##_EL2),\
>> +					 "mrs %0, " __stringify(r##_EL1),\
>> +					 ARM64_HAS_VIRT_HOST_EXTN)	\
>> +			     : "=r" (reg));				\
>> +		reg;							\
>> +	})
>> +
>> +#define write_sysreg_el2(v,r)						\
>> +	do {								\
>> +		u64 __val = (u64)(v);					\
>> +		asm volatile(ALTERNATIVE("msr " __stringify(r##_EL2) ", %x0",\
>> +					 "msr " __stringify(r##_EL1) ", %x0",\
>> +					 ARM64_HAS_VIRT_HOST_EXTN)	\
>> +					 : : "rZ" (__val));		\
>> +	} while (0)
>> +
>> +#define read_sysreg_el0(r)	read_sysreg_elx(r, _EL0, _EL02)
>> +#define write_sysreg_el0(v,r)	write_sysreg_elx(v, r, _EL0, _EL02)
>> +#define read_sysreg_el1(r)	read_sysreg_elx(r, _EL1, _EL12)
>> +#define write_sysreg_el1(v,r)	write_sysreg_elx(v, r, _EL1, _EL12)
>> +
>> +/* The VHE specific system registers and their encoding */
>> +#define sctlr_EL12              sys_reg(3, 5, 1, 0, 0)
>> +#define cpacr_EL12              sys_reg(3, 5, 1, 0, 2)
>> +#define ttbr0_EL12              sys_reg(3, 5, 2, 0, 0)
>> +#define ttbr1_EL12              sys_reg(3, 5, 2, 0, 1)
>> +#define tcr_EL12                sys_reg(3, 5, 2, 0, 2)
>> +#define afsr0_EL12              sys_reg(3, 5, 5, 1, 0)
>> +#define afsr1_EL12              sys_reg(3, 5, 5, 1, 1)
>> +#define esr_EL12                sys_reg(3, 5, 5, 2, 0)
>> +#define far_EL12                sys_reg(3, 5, 6, 0, 0)
>> +#define mair_EL12               sys_reg(3, 5, 10, 2, 0)
>> +#define amair_EL12              sys_reg(3, 5, 10, 3, 0)
>> +#define vbar_EL12               sys_reg(3, 5, 12, 0, 0)
>> +#define contextidr_EL12         sys_reg(3, 5, 13, 0, 1)
>> +#define cntkctl_EL12            sys_reg(3, 5, 14, 1, 0)
>> +#define cntp_tval_EL02          sys_reg(3, 5, 14, 2, 0)
>> +#define cntp_ctl_EL02           sys_reg(3, 5, 14, 2, 1)
>> +#define cntp_cval_EL02          sys_reg(3, 5, 14, 2, 2)
>> +#define cntv_tval_EL02          sys_reg(3, 5, 14, 3, 0)
>> +#define cntv_ctl_EL02           sys_reg(3, 5, 14, 3, 1)
>> +#define cntv_cval_EL02          sys_reg(3, 5, 14, 3, 2)
> 
> as always, fun stuff to review.

Well, short of having publicly available documentation, or force
everyone to upgrade their binutils to deal be able to cope with the new
sysregs, I don't know what else to do. I'm open to suggestions, though.

> 
>> +#define spsr_EL12               sys_reg(3, 5, 4, 0, 0)
>> +#define elr_EL12                sys_reg(3, 5, 4, 0, 1)
>> +
> 
> I couldn't quite decipher the spec as to how these are the right
> instruction encodings, so I'm going to trust the testing that this is
> done right.

If you have access to the spec, you have to play a substitution game
between the canonical encoding of the register accessed, and the
register used. For example:

SPSR_EL1 (3, 0, 4, 0, 0) -> SPSR_EL12 (3, 5, 4, 0, 0)

In practice, only Op1 changes.

	M.
-- 
Jazz is not dead. It just smells funny...


From Chris.Brandt at renesas.com  Mon Feb  1 06:08:15 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Mon, 1 Feb 2016 14:08:15 +0000
Subject: [PATCH] ARM: proc-v7.S: Adjust stack address when XIP_KERNEL
In-Reply-To: <42779466.8cExHmvANB@wuerfel>
References: <1454105474-3009-1-git-send-email-chris.brandt@renesas.com>
 <42779466.8cExHmvANB@wuerfel>
Message-ID: <SG2PR06MB0572F198B08203EBC270F7428ADE0@SG2PR06MB0572.apcprd06.prod.outlook.com>

> I have not verified the contents of the patch, but have two comments on the submission form:
>
> - replace the 'Written by Nicolas Pitre' sentence with a 'From: Nicolas
>   Pitre <nico at linaro.org>' line as the first line of the changelog text,
>   followed by an empty line, so that 'git am' can set the correct author
>   field.
>
> - put your Signed-off-by: line after Nico's for correct documentation
>   of who sent what.
>
>	Arnd


OK, thank you. That makes more sense.


Chris



From robh at kernel.org  Mon Feb  1 06:08:28 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 08:08:28 -0600
Subject: [PATCH v5 1/4] dt-bindings: mailbox: Document Hi6220 mailbox
 driver
In-Reply-To: <1454333687-20421-2-git-send-email-leo.yan@linaro.org>
References: <1454333687-20421-1-git-send-email-leo.yan@linaro.org>
 <1454333687-20421-2-git-send-email-leo.yan@linaro.org>
Message-ID: <20160201140828.GA32412@rob-hp-laptop>

On Mon, Feb 01, 2016 at 09:34:44PM +0800, Leo Yan wrote:
> Document DT binding for Hisilicon Hi6220 mailbox driver.
> 
> Signed-off-by: Leo Yan <leo.yan at linaro.org>
> ---
>  .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  | 90 ++++++++++++++++++++++
>  1 file changed, 90 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
> 
> diff --git a/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
> new file mode 100644
> index 0000000..96e6acc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
> @@ -0,0 +1,90 @@
> +Hisilicon Hi6220 Mailbox Driver
> +===============================
> +
> +Hisilicon Hi6220 mailbox supports up to 32 channels. Each channel
> +is unidirectional with a maximum message size of 8 words. I/O is
> +performed using register access (there is no DMA) and the cell
> +raises an interrupt when messages are received.
> +
> +Mailbox Device Node:
> +====================
> +
> +Required properties:
> +--------------------
> +- compatible:		Shall be "hisilicon,hi6220-mbox"
> +- reg:			Contains the mailbox register address range (base
> +			address and length); the first item is for IPC
> +			registers, the second item is shared buffer for
> +			slots.
> +- #mbox-cells		Common mailbox binding property to identify the number
> +			of cells required for the mailbox specifier. Should be 1.
> +- interrupts:		Contains the interrupt information for the mailbox
> +			device. The format is dependent on which interrupt
> +			controller the SoCs use.
> +
> +Optional Properties:
> +--------------------
> +- hi6220,mbox-tx-noirq: Flag to allow the client user of this mailbox driver
> +			to send messages without triggering a TX completion
> +			interrupt.

I don't think this belongs in DT. This should be a flag the client 
driver sets when it sends messages.

> +
> +Child Nodes:
> +============
> +A child node is used for representing the actual sub-mailbox device that is
> +used for the communication between the host processor and a remote processor.
> +Each child node should have a unique node name across all the different
> +mailbox device nodes.
> +
> +Required properties:
> +--------------------
> +- hi6220,mbox-tx:	sub-mailbox descriptor property defining Tx channel
> +- hi6220,mbox-rx:	sub-mailbox descriptor property defining Rx channel
> +
> +Sub-mailbox Descriptor Data
> +---------------------------
> +Each of the above hi6220,mbox-tx and hi6220,mbox-rx properties should have 3
> +cells of data that represent the following:
> +    Cell #1 (slot_id) - mailbox slot id used either for transmitting
> +                        (hi6220,mbox-tx) or for receiving (hi6220,mbox-rx)
> +    Cell #2 (dst_irq) - irq identifier index number which used by MCU.
> +    Cell #3 (ack_irq) - irq identifier index number with generating a tx/rx
> +                        interrupt to application processor, mailbox driver
> +                        used this id to acknowledge interrupt.
> +
> +Example:
> +--------
> +
> +	mailbox: mailbox at F7510000 {
> +		#mbox-cells = <1>;
> +		compatible = "hisilicon,hi6220-mbox";
> +		reg = <0x0 0xF7510000 0x0 0x1000>, /* IPC_S */
> +		      <0x0 0x06DFF800 0x0 0x0800>; /* Mailbox */
> +		interrupt-parent = <&gic>;
> +		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
> +		mbox_stub_clock: mbox_stub_clock {
> +			hi6220,mbox-rx = <0 1 10>;
> +			hi6220,mbox-tx = <1 0 11>;
> +		};
> +	};
> +
> +
> +Mailbox client
> +===============
> +
> +"mboxes" and the optional "mbox-names" (please see
> +Documentation/devicetree/bindings/mailbox/mailbox.txt for details). Each value
> +of the mboxes property should contain a phandle to the mailbox controller
> +device node and second argument is the channel index. It must be 0 (hardware

0? But the example has 1.

> +support only one channel). The equivalent "mbox-names" property value can be
> +used to give a name to the communication channel to be used by the client user.
> +
> +Example:
> +--------
> +
> +	stub_clock: stub_clock {
> +		compatible = "hisilicon,hi6220-stub-clk";
> +		hisilicon,hi6220-clk-sram = <&sram>;
> +		#clock-cells = <1>;
> +		mbox-names = "mbox-tx";
> +		mboxes = <&mailbox 1>;
> +	};
> -- 
> 1.9.1
> 


From chris.brandt at renesas.com  Mon Feb  1 06:08:56 2016
From: chris.brandt at renesas.com (Chris Brandt)
Date: Mon,  1 Feb 2016 09:08:56 -0500
Subject: [PATCH v2] ARM: proc-v7.S: Adjust stack address when XIP_KERNEL
In-Reply-To: <1454105474-3009-1-git-send-email-chris.brandt@renesas.com>
References: <1454105474-3009-1-git-send-email-chris.brandt@renesas.com>
Message-ID: <1454335736-10084-1-git-send-email-chris.brandt@renesas.com>

From: Nicolas Pitre <nico at linaro.org>

When XIP_KERNEL is enabled, the virt to phys address translation for RAM
is not the same as the virt to phys address translation for .text.
The only way to know where physical RAM is located is to use
PLAT_PHYS_OFFSET.
The MACRO will be useful for other places where there is a similar problem.

Signed-off-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Chris Brandt <chris.brandt at renesas.com>
---
v2:
* Fixed Signed-off to show correct author
---
 arch/arm/include/asm/memory.h | 8 ++++++++
 arch/arm/mm/proc-v7.S         | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index c79b57b..7dd2ab5 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -134,6 +134,14 @@
  */
 #define PLAT_PHYS_OFFSET	UL(CONFIG_PHYS_OFFSET)
 
+#ifdef CONFIG_XIP_KERNEL
+#define PHYS_OFFSET_FIXUP \
+	( XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR) - PAGE_OFFSET + \
+	  PLAT_PHYS_OFFSET - CONFIG_XIP_PHYS_ADDR )
+#else
+#define PHYS_OFFSET_FIXUP 0
+#endif
+
 #ifndef __ASSEMBLY__
 
 /*
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 0f92d57..1595fb2 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -487,7 +487,7 @@ __errata_finish:
 
 	.align	2
 __v7_setup_stack_ptr:
-	.word	__v7_setup_stack - .
+	.word	__v7_setup_stack - . + PHYS_OFFSET_FIXUP
 ENDPROC(__v7_setup)
 
 	.bss
-- 
1.9.1




From robh at kernel.org  Mon Feb  1 06:09:31 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 08:09:31 -0600
Subject: [PATCH] pinctrl: sunxi: Add H3 R_PIO controller support
In-Reply-To: <20160201101225.GA19687@box2.japko.eu>
References: <20160201101225.GA19687@box2.japko.eu>
Message-ID: <20160201140931.GA7238@rob-hp-laptop>

On Mon, Feb 01, 2016 at 11:12:26AM +0100, Krzysztof Adamski wrote:
> H3 has additional PIO controller similar to what we can find on A23.
> It's a 12 pin port, described in H3 Datasheet rev 1.1, pages 345-350.
> 
> Signed-off-by: Krzysztof Adamski <k at japko.eu>
> ---
> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
> arch/arm/boot/dts/sun8i-h3.dtsi                    |  12 +++

Acked-by: Rob Herring <robh at kernel.org>

> drivers/pinctrl/sunxi/Kconfig                      |   4 +
> drivers/pinctrl/sunxi/Makefile                     |   1 +
> drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c         | 105 +++++++++++++++++++++
> 5 files changed, 123 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c


From mark.rutland at arm.com  Mon Feb  1 06:10:04 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 1 Feb 2016 14:10:04 +0000
Subject: [PATCH v5sub1 2/8] arm64: add support for ioremap() block mappings
In-Reply-To: <1454324093-15998-3-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-3-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160201141004.GI674@leverpostej>

On Mon, Feb 01, 2016 at 11:54:47AM +0100, Ard Biesheuvel wrote:
> This wires up the existing generic huge-vmap feature, which allows
> ioremap() to use PMD or PUD sized block mappings. It also adds support
> to the unmap path for dealing with block mappings, which will allow us
> to unmap the __init region using unmap_kernel_range() in a subsequent
> patch.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

Reviewed-by: Mark Rutland <mark.rutland at arm.com>

I was a little bit worried about this potentially not matching the
granularity we used when creating mappings, but seeing how
p?d_clear_huge are called by unmap_kernel_range, I think this is fine.

Thanks,
Mark

> ---
>  Documentation/features/vm/huge-vmap/arch-support.txt |  2 +-
>  arch/arm64/Kconfig                                   |  1 +
>  arch/arm64/include/asm/memory.h                      |  6 +++
>  arch/arm64/mm/mmu.c                                  | 41 ++++++++++++++++++++
>  4 files changed, 49 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/features/vm/huge-vmap/arch-support.txt b/Documentation/features/vm/huge-vmap/arch-support.txt
> index af6816bccb43..df1d1f3c9af2 100644
> --- a/Documentation/features/vm/huge-vmap/arch-support.txt
> +++ b/Documentation/features/vm/huge-vmap/arch-support.txt
> @@ -9,7 +9,7 @@
>      |       alpha: | TODO |
>      |         arc: | TODO |
>      |         arm: | TODO |
> -    |       arm64: | TODO |
> +    |       arm64: |  ok  |
>      |       avr32: | TODO |
>      |    blackfin: | TODO |
>      |         c6x: | TODO |
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 8cc62289a63e..cd767fa3037a 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -49,6 +49,7 @@ config ARM64
>  	select HAVE_ALIGNED_STRUCT_PAGE if SLUB
>  	select HAVE_ARCH_AUDITSYSCALL
>  	select HAVE_ARCH_BITREVERSE
> +	select HAVE_ARCH_HUGE_VMAP
>  	select HAVE_ARCH_JUMP_LABEL
>  	select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP && !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
>  	select HAVE_ARCH_KGDB
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 853953cd1f08..c65aad7b13dc 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -100,6 +100,12 @@
>  #define MT_S2_NORMAL		0xf
>  #define MT_S2_DEVICE_nGnRE	0x1
>  
> +#ifdef CONFIG_ARM64_4K_PAGES
> +#define IOREMAP_MAX_ORDER	(PUD_SHIFT)
> +#else
> +#define IOREMAP_MAX_ORDER	(PMD_SHIFT)
> +#endif
> +
>  #ifndef __ASSEMBLY__
>  
>  extern phys_addr_t		memstart_addr;
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 7711554a94f4..73383019f212 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -714,3 +714,44 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
>  
>  	return dt_virt;
>  }
> +
> +int __init arch_ioremap_pud_supported(void)
> +{
> +	/* only 4k granule supports level 1 block mappings */
> +	return IS_ENABLED(CONFIG_ARM64_4K_PAGES);
> +}
> +
> +int __init arch_ioremap_pmd_supported(void)
> +{
> +	return 1;
> +}
> +
> +int pud_set_huge(pud_t *pud, phys_addr_t phys, pgprot_t prot)
> +{
> +	BUG_ON(phys & ~PUD_MASK);
> +	set_pud(pud, __pud(phys | PUD_TYPE_SECT | pgprot_val(mk_sect_prot(prot))));
> +	return 1;
> +}
> +
> +int pmd_set_huge(pmd_t *pmd, phys_addr_t phys, pgprot_t prot)
> +{
> +	BUG_ON(phys & ~PMD_MASK);
> +	set_pmd(pmd, __pmd(phys | PMD_TYPE_SECT | pgprot_val(mk_sect_prot(prot))));
> +	return 1;
> +}
> +
> +int pud_clear_huge(pud_t *pud)
> +{
> +	if (!pud_sect(*pud))
> +		return 0;
> +	pud_clear(pud);
> +	return 1;
> +}
> +
> +int pmd_clear_huge(pmd_t *pmd)
> +{
> +	if (!pmd_sect(*pmd))
> +		return 0;
> +	pmd_clear(pmd);
> +	return 1;
> +}
> -- 
> 2.5.0
> 


From robh at kernel.org  Mon Feb  1 06:11:23 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 08:11:23 -0600
Subject: [PATCH v7 1/4] dt/bindings: add bindings for optee
In-Reply-To: <1454318140-7962-2-git-send-email-jens.wiklander@linaro.org>
References: <1454318140-7962-1-git-send-email-jens.wiklander@linaro.org>
 <1454318140-7962-2-git-send-email-jens.wiklander@linaro.org>
Message-ID: <20160201141123.GA7792@rob-hp-laptop>

On Mon, Feb 01, 2016 at 10:15:37AM +0100, Jens Wiklander wrote:
> Introduces linaro prefix and adds bindings for ARM TrustZone based OP-TEE
> implementation.
> 
> Signed-off-by: Jens Wiklander <jens.wiklander at linaro.org>
> ---
>  .../bindings/arm/firmware/linaro,optee-tz.txt      | 31 ++++++++++++++++++++++
>  .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>  2 files changed, 32 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Mon Feb  1 06:12:40 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 08:12:40 -0600
Subject: [PATCH 1/2] dt-bindings: add vendor TPO
In-Reply-To: <1454316537-3840-1-git-send-email-linus.walleij@linaro.org>
References: <1454316537-3840-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <20160201141240.GA9289@rob-hp-laptop>

On Mon, Feb 01, 2016 at 09:48:57AM +0100, Linus Walleij wrote:
> TPO was a merger on June 5 2006 of Toppoly Optoelectronics and
> Philips Mobile Display Systems. They manufactured small and medium
> mobile displays.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <robh at kernel.org>


From christoffer.dall at linaro.org  Mon Feb  1 06:17:29 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 15:17:29 +0100
Subject: [PATCH v2 13/21] arm64: KVM: VHE: Make __fpsimd_enabled VHE aware
In-Reply-To: <1453737235-16522-14-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-14-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201141729.GS1478@cbox>

On Mon, Jan 25, 2016 at 03:53:47PM +0000, Marc Zyngier wrote:
> As non-VHE and VHE have different ways to express the trapping of
> FPSIMD registers to EL2, make __fpsimd_enabled a patchable predicate
> and provide a VHE implementation.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/hyp/hyp.h    |  5 +----
>  arch/arm64/kvm/hyp/switch.c | 19 +++++++++++++++++++
>  2 files changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
> index 5dfa883..44eaff7 100644
> --- a/arch/arm64/kvm/hyp/hyp.h
> +++ b/arch/arm64/kvm/hyp/hyp.h
> @@ -171,10 +171,7 @@ void __debug_cond_restore_host_state(struct kvm_vcpu *vcpu);
>  
>  void __fpsimd_save_state(struct user_fpsimd_state *fp_regs);
>  void __fpsimd_restore_state(struct user_fpsimd_state *fp_regs);
> -static inline bool __fpsimd_enabled(void)
> -{
> -	return !(read_sysreg(cptr_el2) & CPTR_EL2_TFP);
> -}
> +bool __fpsimd_enabled(void);
>  
>  u64 __guest_enter(struct kvm_vcpu *vcpu, struct kvm_cpu_context *host_ctxt);
>  void __noreturn __hyp_do_panic(unsigned long, ...);
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 9071dee..6f264dc 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -17,6 +17,25 @@
>  
>  #include "hyp.h"
>  
> +static bool __hyp_text __fpsimd_enabled_nvhe(void)
> +{
> +	return !(read_sysreg(cptr_el2) & CPTR_EL2_TFP);
> +}
> +
> +static bool __hyp_text __fpsimd_enabled_vhe(void)
> +{
> +	return !!(read_sysreg(cpacr_el1) & (3 << 20));

so this access to cpacr_el1 is really rewritten by the HW to access the
cptr_el2, and the cptr_el2 is redefined to have bits[21:20] have the
semantics that if the bits are both set we don't trap (FPEN), so that
means SIMD is enabled for the guest to use.  Right, simple, crisp,
clear, and intuitive.

nit: you could add a define for the bitfield somewhere reusable?

> +}
> +
> +static hyp_alternate_select(__fpsimd_is_enabled,
> +			    __fpsimd_enabled_nvhe, __fpsimd_enabled_vhe,
> +			    ARM64_HAS_VIRT_HOST_EXTN);
> +
> +bool __hyp_text __fpsimd_enabled(void)
> +{
> +	return __fpsimd_is_enabled()();
> +}
> +
>  static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
>  {
>  	u64 val;
> -- 
> 2.1.4
> 

Otherwise,
Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Mon Feb  1 06:20:45 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 15:20:45 +0100
Subject: [PATCH v2 14/21] arm64: KVM: VHE: Implement VHE
 activate/deactivate_traps
In-Reply-To: <1453737235-16522-15-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-15-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201142045.GT1478@cbox>

On Mon, Jan 25, 2016 at 03:53:48PM +0000, Marc Zyngier wrote:
> Running the kernel in HYP mode requires the HCR_E2H bit to be set
> at all times, and the HCR_TGE bit to be set when running as a host
> (and cleared when running as a guest). At the same time, the vector
>  must be set to the current role of the kernel (either host or
> hypervisor), and a couple of system registers differ between VHE
> and non-VHE.
> 
> We implement these by using another set of alternate functions
> that get dynamically patched.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/kvm_arm.h     |  1 +
>  arch/arm64/include/asm/kvm_emulate.h |  3 +++
>  arch/arm64/kvm/hyp/switch.c          | 52 +++++++++++++++++++++++++++++++++---
>  3 files changed, 53 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 738a95f..73d3826 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -23,6 +23,7 @@
>  #include <asm/types.h>
>  
>  /* Hyp Configuration Register (HCR) bits */
> +#define HCR_E2H		(UL(1) << 34)
>  #define HCR_ID		(UL(1) << 33)
>  #define HCR_CD		(UL(1) << 32)
>  #define HCR_RW_SHIFT	31
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index 3066328..5ae0c69 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -29,6 +29,7 @@
>  #include <asm/kvm_mmio.h>
>  #include <asm/ptrace.h>
>  #include <asm/cputype.h>
> +#include <asm/virt.h>
>  
>  unsigned long *vcpu_reg32(const struct kvm_vcpu *vcpu, u8 reg_num);
>  unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu);
> @@ -43,6 +44,8 @@ void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
>  static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu)
>  {
>  	vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
> +	if (is_kernel_in_hyp_mode())
> +		vcpu->arch.hcr_el2 |= HCR_E2H;
>  	if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features))
>  		vcpu->arch.hcr_el2 &= ~HCR_RW;
>  }
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 6f264dc..77f7c94 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -15,6 +15,8 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <asm/kvm_asm.h>
> +
>  #include "hyp.h"
>  
>  static bool __hyp_text __fpsimd_enabled_nvhe(void)
> @@ -36,6 +38,27 @@ bool __hyp_text __fpsimd_enabled(void)
>  	return __fpsimd_is_enabled()();
>  }
>  
> +static void __hyp_text __activate_traps_vhe(void)
> +{
> +	u64 val;
> +
> +	val = read_sysreg(cpacr_el1);
> +	val |= 1 << 28;
> +	val &= ~(3 << 20);

could you define these bitfields as well?

> +	write_sysreg(val, cpacr_el1);
> +
> +	write_sysreg(__kvm_hyp_vector, vbar_el1);
> +}
> +
> +static void __hyp_text __activate_traps_nvhe(void)
> +{
> +	write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
> +}
> +
> +static hyp_alternate_select(__activate_traps_arch,
> +			    __activate_traps_nvhe, __activate_traps_vhe,
> +			    ARM64_HAS_VIRT_HOST_EXTN);
> +
>  static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
>  {
>  	u64 val;
> @@ -55,16 +78,39 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
>  	write_sysreg(val, hcr_el2);
>  	/* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
>  	write_sysreg(1 << 15, hstr_el2);
> -	write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
>  	write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
> +	__activate_traps_arch()();
>  }
>  
> -static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
> +static void __hyp_text __deactivate_traps_vhe(void)
> +{
> +	extern char vectors[];	/* kernel exception vectors */
> +	u64 val;
> +
> +	write_sysreg(HCR_RW | HCR_TGE | HCR_E2H, hcr_el2);

perhaps we should define the EL2_HOST_HCR bit settings somewhere
globally and reuse that here?

> +
> +	val = read_sysreg(cpacr_el1);
> +	val |= 3 << 20;
> +	write_sysreg(val, cpacr_el1);
> +
> +	write_sysreg(vectors, vbar_el1);
> +}
> +
> +static void __hyp_text __deactivate_traps_nvhe(void)
>  {
>  	write_sysreg(HCR_RW, hcr_el2);
> +	write_sysreg(0, cptr_el2);

I'm noticing here that there's actually a bunch of RES1 bits in the
cptr_el2, so perhaps we should fix this as we're at it?

> +}
> +
> +static hyp_alternate_select(__deactivate_traps_arch,
> +			    __deactivate_traps_nvhe, __deactivate_traps_vhe,
> +			    ARM64_HAS_VIRT_HOST_EXTN);
> +
> +static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
> +{
> +	__deactivate_traps_arch()();
>  	write_sysreg(0, hstr_el2);
>  	write_sysreg(read_sysreg(mdcr_el2) & MDCR_EL2_HPMN_MASK, mdcr_el2);
> -	write_sysreg(0, cptr_el2);
>  }
>  
>  static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
> -- 
> 2.1.4
> 

Otherwise looks good.

-Christoffer


From marc.zyngier at arm.com  Mon Feb  1 06:21:57 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 1 Feb 2016 14:21:57 +0000
Subject: [PATCH v2 05/21] arm64: KVM: VHE: Turn VTCR_EL2 setup into a
 reusable macro
In-Reply-To: <20160201131300.GH1478@cbox>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-6-git-send-email-marc.zyngier@arm.com>
 <20160201131300.GH1478@cbox>
Message-ID: <56AF6A05.5020501@arm.com>

On 01/02/16 13:13, Christoffer Dall wrote:
> On Mon, Jan 25, 2016 at 03:53:39PM +0000, Marc Zyngier wrote:
>> On a VHE-capable system, there is no point in setting VTCR_EL2
>> at KVM init time. We can perfectly set it up when the kernel
>> boots, removing the need for a more complicated configuration.
> 
> what's the complicated configuration which is avoided?

With VHE, there is no hyp-init at all, so what we avoid is a weird init
sequence where we have to execute part of this hyp-init, but not all of it.

>>
>> In order to allow this, turn VTCR_EL2 setup into a macro that
>> we'll be able to reuse at boot time.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/include/asm/kvm_mmu.h | 23 +++++++++++++++++++++++
>>  arch/arm64/kvm/hyp-init.S        | 18 +-----------------
>>  2 files changed, 24 insertions(+), 17 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
>> index 7364339..d3e6d7b 100644
>> --- a/arch/arm64/include/asm/kvm_mmu.h
>> +++ b/arch/arm64/include/asm/kvm_mmu.h
>> @@ -56,6 +56,29 @@
>>  
>>  #ifdef __ASSEMBLY__
>>  
>> +#include <asm/kvm_arm.h>
>> +
>> +.macro setup_vtcr tmp1, tmp2
>> +	mov	\tmp1, #(VTCR_EL2_FLAGS & 0xffff)
>> +	movk	\tmp1, #(VTCR_EL2_FLAGS >> 16), lsl #16
>> +	/*
>> +	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
>> +	 * VTCR_EL2.
>> +	 */
>> +	mrs	\tmp2, id_aa64mmfr0_el1
>> +	bfi	\tmp1, \tmp2, #16, #3
>> +	/*
>> +	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS bit in
>> +	 * VTCR_EL2.
>> +	 */
>> +	mrs	\tmp2, ID_AA64MMFR1_EL1
>> +	ubfx	\tmp2, \tmp2, #5, #1
>> +	lsl	\tmp2, \tmp2, #VTCR_EL2_VS
>> +	orr	\tmp1, \tmp1, \tmp2
>> +
>> +	msr	vtcr_el2, \tmp1
>> +	isb
>> +.endm
> 
> this feels like an awful lot of code in a header file.

interrupt_head.S respectfully disagrees with you ;-).

> Is it crazy to imagine wanting to have different T0SZ for different VMs
> in the future?  In that case, the T0SZ stuff should stay in KVM...

That's a rather compelling argument indeed. I'll see if I can turn the
thing around in a slightly nicer way. How about moving it out of
hyp-init.S altogether, and into C code?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From christoffer.dall at linaro.org  Mon Feb  1 06:23:19 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 15:23:19 +0100
Subject: [PATCH v2 15/21] arm64: KVM: VHE: Use unified sysreg accessors
 for timer
In-Reply-To: <1453737235-16522-16-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-16-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201142319.GU1478@cbox>

On Mon, Jan 25, 2016 at 03:53:49PM +0000, Marc Zyngier wrote:
> Switch the timer code to the unified sysreg accessors.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>

> ---
>  arch/arm64/kvm/hyp/timer-sr.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/timer-sr.c b/arch/arm64/kvm/hyp/timer-sr.c
> index 1051e5d..f276d9e 100644
> --- a/arch/arm64/kvm/hyp/timer-sr.c
> +++ b/arch/arm64/kvm/hyp/timer-sr.c
> @@ -31,12 +31,12 @@ void __hyp_text __timer_save_state(struct kvm_vcpu *vcpu)
>  	u64 val;
>  
>  	if (kvm->arch.timer.enabled) {
> -		timer->cntv_ctl = read_sysreg(cntv_ctl_el0);
> -		timer->cntv_cval = read_sysreg(cntv_cval_el0);
> +		timer->cntv_ctl = read_sysreg_el0(cntv_ctl);
> +		timer->cntv_cval = read_sysreg_el0(cntv_cval);
>  	}
>  
>  	/* Disable the virtual timer */
> -	write_sysreg(0, cntv_ctl_el0);
> +	write_sysreg_el0(0, cntv_ctl);
>  
>  	/* Allow physical timer/counter access for the host */
>  	val = read_sysreg(cnthctl_el2);
> @@ -64,8 +64,8 @@ void __hyp_text __timer_restore_state(struct kvm_vcpu *vcpu)
>  
>  	if (kvm->arch.timer.enabled) {
>  		write_sysreg(kvm->arch.timer.cntvoff, cntvoff_el2);
> -		write_sysreg(timer->cntv_cval, cntv_cval_el0);
> +		write_sysreg_el0(timer->cntv_cval, cntv_cval);
>  		isb();
> -		write_sysreg(timer->cntv_ctl, cntv_ctl_el0);
> +		write_sysreg_el0(timer->cntv_ctl, cntv_ctl);
>  	}
>  }
> -- 
> 2.1.4
> 


From heiko at sntech.de  Mon Feb  1 06:22:44 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Mon, 01 Feb 2016 15:22:44 +0100
Subject: [PATCH v2 01/15] arm: use of_platform_default_populate() to
 populate default bus
In-Reply-To: <1453881180-12296-1-git-send-email-wangkefeng.wang@huawei.com>
References: <1453868872-26300-2-git-send-email-wangkefeng.wang@huawei.com>
 <1453881180-12296-1-git-send-email-wangkefeng.wang@huawei.com>
Message-ID: <1694609.jjsREDbl4R@diego>

Am Mittwoch, 27. Januar 2016, 15:53:00 schrieb Kefeng Wang:
> Use helper of_platform_default_populate() in linux/of_platform
> when possible, instead of calling of_platform_populate() with
> the default match table.
> 
> Signed-off-by: Kefeng Wang <wangkefeng.wang at huawei.com>
> ---


> diff --git a/arch/arm/mach-rockchip/rockchip.c
> b/arch/arm/mach-rockchip/rockchip.c index 3f07cc5..07ef8ef 100644
> --- a/arch/arm/mach-rockchip/rockchip.c
> +++ b/arch/arm/mach-rockchip/rockchip.c
> @@ -73,7 +73,7 @@ static void __init rockchip_timer_init(void)
>  static void __init rockchip_dt_init(void)
>  {
>  	rockchip_suspend_init();
> -	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +	of_platform_default_populate(NULL, NULL, NULL);
>  	platform_device_register_simple("cpufreq-dt", 0, NULL, 0);
>  }

sounds sensible, so

Acked-by: Heiko Stuebner <heiko at sntech.de>


From christoffer.dall at linaro.org  Mon Feb  1 06:24:18 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 15:24:18 +0100
Subject: [PATCH v2 16/21] arm64: KVM: VHE: Add fpsimd enabling on guest
 access
In-Reply-To: <1453737235-16522-17-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-17-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201142418.GV1478@cbox>

On Mon, Jan 25, 2016 at 03:53:50PM +0000, Marc Zyngier wrote:
> Despite the fact that a VHE enabled kernel runs at EL2, it uses
> CPACR_EL1 to trap FPSIMD access. Add the required alternative
> code to re-enable guest FPSIMD access when it has trapped to
> EL2.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/hyp/entry.S | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
> index fd0fbe9..759a0ec 100644
> --- a/arch/arm64/kvm/hyp/entry.S
> +++ b/arch/arm64/kvm/hyp/entry.S
> @@ -130,9 +130,15 @@ ENDPROC(__guest_exit)
>  ENTRY(__fpsimd_guest_restore)
>  	stp	x4, lr, [sp, #-16]!
>  
> +alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
>  	mrs	x2, cptr_el2
>  	bic	x2, x2, #CPTR_EL2_TFP
>  	msr	cptr_el2, x2
> +alternative_else
> +	mrs	x2, cpacr_el1
> +	orr	x2, x2, #(3 << 20)

nit: bitfield definition again

> +	msr	cpacr_el1, x2
> +alternative_endif
>  	isb
>  
>  	mrs	x3, tpidr_el2
> -- 
> 2.1.4
> 

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Mon Feb  1 06:26:20 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 15:26:20 +0100
Subject: [PATCH v2 17/21] arm64: KVM: VHE: Add alternative panic handling
In-Reply-To: <1453737235-16522-18-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-18-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201142620.GW1478@cbox>

On Mon, Jan 25, 2016 at 03:53:51PM +0000, Marc Zyngier wrote:
> As the kernel fully runs in HYP when VHE is enabled, we can
> directly branch to the kernel's panic() implementation, and
> not perform an exception return.
> 
> Add the alternative code to deal with this.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>

> ---
>  arch/arm64/kvm/hyp/switch.c | 35 +++++++++++++++++++++++++++--------
>  1 file changed, 27 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 77f7c94..0cadb7f 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -211,11 +211,34 @@ __alias(__guest_run) int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
>  
>  static const char __hyp_panic_string[] = "HYP panic:\nPS:%08llx PC:%016llx ESR:%08llx\nFAR:%016llx HPFAR:%016llx PAR:%016llx\nVCPU:%p\n";
>  
> -void __hyp_text __noreturn __hyp_panic(void)
> +static void __hyp_text __hyp_call_panic_nvhe(u64 spsr, u64 elr, u64 par)
>  {
>  	unsigned long str_va = (unsigned long)__hyp_panic_string;
> -	u64 spsr = read_sysreg(spsr_el2);
> -	u64 elr = read_sysreg(elr_el2);
> +
> +	__hyp_do_panic(hyp_kern_va(str_va),
> +		       spsr,  elr,
> +		       read_sysreg(esr_el2),   read_sysreg_el2(far),
> +		       read_sysreg(hpfar_el2), par,
> +		       (void *)read_sysreg(tpidr_el2));
> +}
> +
> +static void __hyp_text __hyp_call_panic_vhe(u64 spsr, u64 elr, u64 par)
> +{
> +	panic(__hyp_panic_string,
> +	      spsr,  elr,
> +	      read_sysreg_el2(esr),   read_sysreg_el2(far),
> +	      read_sysreg(hpfar_el2), par,
> +	      (void *)read_sysreg(tpidr_el2));
> +}
> +
> +static hyp_alternate_select(__hyp_call_panic,
> +			    __hyp_call_panic_nvhe, __hyp_call_panic_vhe,
> +			    ARM64_HAS_VIRT_HOST_EXTN);
> +
> +void __hyp_text __noreturn __hyp_panic(void)
> +{
> +	u64 spsr = read_sysreg_el2(spsr);
> +	u64 elr = read_sysreg_el2(elr);
>  	u64 par = read_sysreg(par_el1);
>  
>  	if (read_sysreg(vttbr_el2)) {
> @@ -230,11 +253,7 @@ void __hyp_text __noreturn __hyp_panic(void)
>  	}
>  
>  	/* Call panic for real */
> -	__hyp_do_panic(hyp_kern_va(str_va),
> -		       spsr,  elr,
> -		       read_sysreg(esr_el2),   read_sysreg(far_el2),
> -		       read_sysreg(hpfar_el2), par,
> -		       (void *)read_sysreg(tpidr_el2));
> +	__hyp_call_panic()(spsr, elr, par);
>  
>  	unreachable();
>  }
> -- 
> 2.1.4
> 


From hdegoede at redhat.com  Mon Feb  1 06:26:43 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Mon, 1 Feb 2016 15:26:43 +0100
Subject: [linux-sunxi] Problem with Allwinner H3 clocks
In-Reply-To: <20160201063731.GG32462@lukather>
References: <20160127103714.58312b152adb4148bae2f93b@free.fr>
 <56A8D5E5.30701@gmail.com> <20160127175512.87caf31b5e21a1fec91507f2@free.fr>
 <56A9098A.5010107@redhat.com>
 <20160127200217.14dce96ade71cf81bc82e6f6@free.fr>
 <56A9CE3D.4020906@redhat.com> <56AA14AA.4070502@gmail.com>
 <20160128175918.78a916a8cd7bf4c0b2f2814f@free.fr>
 <20160128192931.GB32462@lukather> <56AB05EF.2090604@redhat.com>
 <20160201063731.GG32462@lukather>
Message-ID: <56AF6B23.1010901@redhat.com>

Hi,

On 01-02-16 07:37, Maxime Ripard wrote:
> Hi,
>
> On Fri, Jan 29, 2016 at 07:25:51AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 01/28/2016 08:29 PM, Maxime Ripard wrote:
>>> On Thu, Jan 28, 2016 at 05:59:18PM +0100, Jean-Francois Moine wrote:
>>
>> <snip>
>>
>>>> The A23/A33/H3 (and surely some other SoCs) documentations about
>>>> the peripheral/periph/periph0/periph1 PLLs say:
>>>>
>>>> 	Note: The PLL Output should be fixed to 600MHz, it is not
>>>> 	recommended to vary this value arbitrarily.
>>>
>>> I don't know if it's worth it at this point. The pll6 seems to work
>>> fine at other rates. Have you experienced any breakage when running at
>>> another frequency?
>>
>> Hmm, are we actually changing the freq of pll6 on any SoCs? I know we've
>> the code to it, but given that it is shared between many pheripherals,
>> I assume we end up never changing it.
>
> We don't, but it works. Back when I was debugging the A31 DMA
> controller, I tried to do just that and nothing broke (at least as
> long as you don't switch halfway through during the boot, but at the
> time the clock is registered).
>
>> I assume / hope that the clock framework protects against reclocking
>> a clock with multiple users ...
>
> There is, but it's opt-in, and we're not using it yet for anything but
> the hstimers (and in that case, we don't prevent the reclocking, we
> just take it into account).

Shouldn't we be opt-ing in then ? At least the mmc driver makes
clk_set_rate calls, it would be bad if that somehow ends up changing the
pll6 rate while other peripherals are using it.

Regards,

Hans


From mark.rutland at arm.com  Mon Feb  1 06:32:26 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 1 Feb 2016 14:32:26 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160201143226.GJ674@leverpostej>

On Mon, Feb 01, 2016 at 11:54:52AM +0100, Ard Biesheuvel wrote:
> This moves the module area to right before the vmalloc area, and
> moves the kernel image to the base of the vmalloc area. This is
> an intermediate step towards implementing KASLR, which allows the
> kernel image to be located anywhere in the vmalloc area.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

With the fix for the issue Catalin spotted:

Reviewed-by: Mark Rutland <mark.rutland at arm.com>

Mark.

> ---
>  arch/arm64/include/asm/kasan.h   |  2 +-
>  arch/arm64/include/asm/memory.h  | 21 +++--
>  arch/arm64/include/asm/pgtable.h | 10 +-
>  arch/arm64/mm/dump.c             | 12 +--
>  arch/arm64/mm/init.c             | 23 ++---
>  arch/arm64/mm/kasan_init.c       | 31 ++++++-
>  arch/arm64/mm/mmu.c              | 97 +++++++++++++-------
>  7 files changed, 129 insertions(+), 67 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h
> index de0d21211c34..71ad0f93eb71 100644
> --- a/arch/arm64/include/asm/kasan.h
> +++ b/arch/arm64/include/asm/kasan.h
> @@ -14,7 +14,7 @@
>   * KASAN_SHADOW_END: KASAN_SHADOW_START + 1/8 of kernel virtual addresses.
>   */
>  #define KASAN_SHADOW_START      (VA_START)
> -#define KASAN_SHADOW_END        (KASAN_SHADOW_START + (1UL << (VA_BITS - 3)))
> +#define KASAN_SHADOW_END        (KASAN_SHADOW_START + KASAN_SHADOW_SIZE)
>  
>  /*
>   * This value is used to map an address to the corresponding shadow
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index aebc739f5a11..4388651d1f0d 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -45,16 +45,15 @@
>   * VA_START - the first kernel virtual address.
>   * TASK_SIZE - the maximum size of a user space task.
>   * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area.
> - * The module space lives between the addresses given by TASK_SIZE
> - * and PAGE_OFFSET - it must be within 128MB of the kernel text.
>   */
>  #define VA_BITS			(CONFIG_ARM64_VA_BITS)
>  #define VA_START		(UL(0xffffffffffffffff) << VA_BITS)
>  #define PAGE_OFFSET		(UL(0xffffffffffffffff) << (VA_BITS - 1))
> -#define KIMAGE_VADDR		(PAGE_OFFSET)
> -#define MODULES_END		(KIMAGE_VADDR)
> -#define MODULES_VADDR		(MODULES_END - SZ_64M)
> -#define PCI_IO_END		(MODULES_VADDR - SZ_2M)
> +#define KIMAGE_VADDR		(MODULES_END)
> +#define MODULES_END		(MODULES_VADDR + MODULES_VSIZE)
> +#define MODULES_VADDR		(VA_START + KASAN_SHADOW_SIZE)
> +#define MODULES_VSIZE		(SZ_64M)
> +#define PCI_IO_END		(PAGE_OFFSET - SZ_2M)
>  #define PCI_IO_START		(PCI_IO_END - PCI_IO_SIZE)
>  #define FIXADDR_TOP		(PCI_IO_START - SZ_2M)
>  #define TASK_SIZE_64		(UL(1) << VA_BITS)
> @@ -72,6 +71,16 @@
>  #define TASK_UNMAPPED_BASE	(PAGE_ALIGN(TASK_SIZE / 4))
>  
>  /*
> + * The size of the KASAN shadow region. This should be 1/8th of the
> + * size of the entire kernel virtual address space.
> + */
> +#ifdef CONFIG_KASAN
> +#define KASAN_SHADOW_SIZE	(UL(1) << (VA_BITS - 3))
> +#else
> +#define KASAN_SHADOW_SIZE	(0)
> +#endif
> +
> +/*
>   * Physical vs virtual RAM address space conversion.  These are
>   * private definitions which should NOT be used outside memory.h
>   * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 87355408d448..a440f5a85d08 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -36,19 +36,13 @@
>   *
>   * VMEMAP_SIZE: allows the whole VA space to be covered by a struct page array
>   *	(rounded up to PUD_SIZE).
> - * VMALLOC_START: beginning of the kernel VA space
> + * VMALLOC_START: beginning of the kernel vmalloc space
>   * VMALLOC_END: extends to the available space below vmmemmap, PCI I/O space,
>   *	fixed mappings and modules
>   */
>  #define VMEMMAP_SIZE		ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) * sizeof(struct page), PUD_SIZE)
>  
> -#ifndef CONFIG_KASAN
> -#define VMALLOC_START		(VA_START)
> -#else
> -#include <asm/kasan.h>
> -#define VMALLOC_START		(KASAN_SHADOW_END + SZ_64K)
> -#endif
> -
> +#define VMALLOC_START		(MODULES_END)
>  #define VMALLOC_END		(PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - SZ_64K)
>  
>  #define vmemmap			((struct page *)(VMALLOC_END + SZ_64K))
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index 0adbebbc2803..e83ffb00560c 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -35,7 +35,9 @@ struct addr_marker {
>  };
>  
>  enum address_markers_idx {
> -	VMALLOC_START_NR = 0,
> +	MODULES_START_NR = 0,
> +	MODULES_END_NR,
> +	VMALLOC_START_NR,
>  	VMALLOC_END_NR,
>  #ifdef CONFIG_SPARSEMEM_VMEMMAP
>  	VMEMMAP_START_NR,
> @@ -45,12 +47,12 @@ enum address_markers_idx {
>  	FIXADDR_END_NR,
>  	PCI_START_NR,
>  	PCI_END_NR,
> -	MODULES_START_NR,
> -	MODULES_END_NR,
>  	KERNEL_SPACE_NR,
>  };
>  
>  static struct addr_marker address_markers[] = {
> +	{ MODULES_VADDR,	"Modules start" },
> +	{ MODULES_END,		"Modules end" },
>  	{ VMALLOC_START,	"vmalloc() Area" },
>  	{ VMALLOC_END,		"vmalloc() End" },
>  #ifdef CONFIG_SPARSEMEM_VMEMMAP
> @@ -61,9 +63,7 @@ static struct addr_marker address_markers[] = {
>  	{ FIXADDR_TOP,		"Fixmap end" },
>  	{ PCI_IO_START,		"PCI I/O start" },
>  	{ PCI_IO_END,		"PCI I/O end" },
> -	{ MODULES_VADDR,	"Modules start" },
> -	{ MODULES_END,		"Modules end" },
> -	{ PAGE_OFFSET,		"Kernel Mapping" },
> +	{ PAGE_OFFSET,		"Linear Mapping" },
>  	{ -1,			NULL },
>  };
>  
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index f3b061e67bfe..1d627cd8121c 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -36,6 +36,7 @@
>  #include <linux/swiotlb.h>
>  
>  #include <asm/fixmap.h>
> +#include <asm/kasan.h>
>  #include <asm/memory.h>
>  #include <asm/sections.h>
>  #include <asm/setup.h>
> @@ -302,22 +303,26 @@ void __init mem_init(void)
>  #ifdef CONFIG_KASAN
>  		  "    kasan   : 0x%16lx - 0x%16lx   (%6ld GB)\n"
>  #endif
> +		  "    modules : 0x%16lx - 0x%16lx   (%6ld MB)\n"
>  		  "    vmalloc : 0x%16lx - 0x%16lx   (%6ld GB)\n"
> +		  "      .init : 0x%p" " - 0x%p" "   (%6ld KB)\n"
> +		  "      .text : 0x%p" " - 0x%p" "   (%6ld KB)\n"
> +		  "      .data : 0x%p" " - 0x%p" "   (%6ld KB)\n"
>  #ifdef CONFIG_SPARSEMEM_VMEMMAP
>  		  "    vmemmap : 0x%16lx - 0x%16lx   (%6ld GB maximum)\n"
>  		  "              0x%16lx - 0x%16lx   (%6ld MB actual)\n"
>  #endif
>  		  "    fixed   : 0x%16lx - 0x%16lx   (%6ld KB)\n"
>  		  "    PCI I/O : 0x%16lx - 0x%16lx   (%6ld MB)\n"
> -		  "    modules : 0x%16lx - 0x%16lx   (%6ld MB)\n"
> -		  "    memory  : 0x%16lx - 0x%16lx   (%6ld MB)\n"
> -		  "      .init : 0x%p" " - 0x%p" "   (%6ld KB)\n"
> -		  "      .text : 0x%p" " - 0x%p" "   (%6ld KB)\n"
> -		  "      .data : 0x%p" " - 0x%p" "   (%6ld KB)\n",
> +		  "    memory  : 0x%16lx - 0x%16lx   (%6ld MB)\n",
>  #ifdef CONFIG_KASAN
>  		  MLG(KASAN_SHADOW_START, KASAN_SHADOW_END),
>  #endif
> +		  MLM(MODULES_VADDR, MODULES_END),
>  		  MLG(VMALLOC_START, VMALLOC_END),
> +		  MLK_ROUNDUP(__init_begin, __init_end),
> +		  MLK_ROUNDUP(_text, _etext),
> +		  MLK_ROUNDUP(_sdata, _edata),
>  #ifdef CONFIG_SPARSEMEM_VMEMMAP
>  		  MLG((unsigned long)vmemmap,
>  		      (unsigned long)vmemmap + VMEMMAP_SIZE),
> @@ -326,11 +331,7 @@ void __init mem_init(void)
>  #endif
>  		  MLK(FIXADDR_START, FIXADDR_TOP),
>  		  MLM(PCI_IO_START, PCI_IO_END),
> -		  MLM(MODULES_VADDR, MODULES_END),
> -		  MLM(PAGE_OFFSET, (unsigned long)high_memory),
> -		  MLK_ROUNDUP(__init_begin, __init_end),
> -		  MLK_ROUNDUP(_text, _etext),
> -		  MLK_ROUNDUP(_sdata, _edata));
> +		  MLM(PAGE_OFFSET, (unsigned long)high_memory));
>  
>  #undef MLK
>  #undef MLM
> @@ -358,8 +359,8 @@ void __init mem_init(void)
>  
>  void free_initmem(void)
>  {
> -	fixup_init();
>  	free_initmem_default(0);
> +	fixup_init();
>  }
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
> index cc569a38bc76..66c246871d2e 100644
> --- a/arch/arm64/mm/kasan_init.c
> +++ b/arch/arm64/mm/kasan_init.c
> @@ -17,9 +17,11 @@
>  #include <linux/start_kernel.h>
>  
>  #include <asm/mmu_context.h>
> +#include <asm/kernel-pgtable.h>
>  #include <asm/page.h>
>  #include <asm/pgalloc.h>
>  #include <asm/pgtable.h>
> +#include <asm/sections.h>
>  #include <asm/tlbflush.h>
>  
>  static pgd_t tmp_pg_dir[PTRS_PER_PGD] __initdata __aligned(PGD_SIZE);
> @@ -33,7 +35,7 @@ static void __init kasan_early_pte_populate(pmd_t *pmd, unsigned long addr,
>  	if (pmd_none(*pmd))
>  		pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
>  
> -	pte = pte_offset_kernel(pmd, addr);
> +	pte = pte_offset_kimg(pmd, addr);
>  	do {
>  		next = addr + PAGE_SIZE;
>  		set_pte(pte, pfn_pte(virt_to_pfn(kasan_zero_page),
> @@ -51,7 +53,7 @@ static void __init kasan_early_pmd_populate(pud_t *pud,
>  	if (pud_none(*pud))
>  		pud_populate(&init_mm, pud, kasan_zero_pmd);
>  
> -	pmd = pmd_offset(pud, addr);
> +	pmd = pmd_offset_kimg(pud, addr);
>  	do {
>  		next = pmd_addr_end(addr, end);
>  		kasan_early_pte_populate(pmd, addr, next);
> @@ -68,7 +70,7 @@ static void __init kasan_early_pud_populate(pgd_t *pgd,
>  	if (pgd_none(*pgd))
>  		pgd_populate(&init_mm, pgd, kasan_zero_pud);
>  
> -	pud = pud_offset(pgd, addr);
> +	pud = pud_offset_kimg(pgd, addr);
>  	do {
>  		next = pud_addr_end(addr, end);
>  		kasan_early_pmd_populate(pud, addr, next);
> @@ -126,9 +128,13 @@ static void __init clear_pgds(unsigned long start,
>  
>  void __init kasan_init(void)
>  {
> +	u64 kimg_shadow_start, kimg_shadow_end;
>  	struct memblock_region *reg;
>  	int i;
>  
> +	kimg_shadow_start = (u64)kasan_mem_to_shadow(_text);
> +	kimg_shadow_end = (u64)kasan_mem_to_shadow(_end);
> +
>  	/*
>  	 * We are going to perform proper setup of shadow memory.
>  	 * At first we should unmap early shadow (clear_pgds() call bellow).
> @@ -142,8 +148,25 @@ void __init kasan_init(void)
>  
>  	clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
>  
> +	vmemmap_populate(kimg_shadow_start, kimg_shadow_end, NUMA_NO_NODE);
> +
> +	/*
> +	 * vmemmap_populate() has populated the shadow region that covers the
> +	 * kernel image with SWAPPER_BLOCK_SIZE mappings, so we have to round
> +	 * the start and end addresses to SWAPPER_BLOCK_SIZE as well, to prevent
> +	 * kasan_populate_zero_shadow() from replacing the PMD block mappings
> +	 * with PMD table mappings at the edges of the shadow region for the
> +	 * kernel image.
> +	 */
> +	if (ARM64_SWAPPER_USES_SECTION_MAPS) {
> +		kimg_shadow_start = round_down(kimg_shadow_start,
> +					       SWAPPER_BLOCK_SIZE);
> +		kimg_shadow_end = round_up(kimg_shadow_end, SWAPPER_BLOCK_SIZE);
> +	}
>  	kasan_populate_zero_shadow((void *)KASAN_SHADOW_START,
> -			kasan_mem_to_shadow((void *)MODULES_VADDR));
> +				   (void *)kimg_shadow_start);
> +	kasan_populate_zero_shadow((void *)kimg_shadow_end,
> +				   kasan_mem_to_shadow((void *)PAGE_OFFSET));
>  
>  	for_each_memblock(memory, reg) {
>  		void *start = (void *)__phys_to_virt(reg->base);
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index b84915723ea0..4c4b15932963 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -53,6 +53,10 @@ u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
>  unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_bss;
>  EXPORT_SYMBOL(empty_zero_page);
>  
> +static pte_t bm_pte[PTRS_PER_PTE] __page_aligned_bss;
> +static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss;
> +static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss;
> +
>  pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
>  			      unsigned long size, pgprot_t vma_prot)
>  {
> @@ -349,14 +353,14 @@ static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end
>  {
>  
>  	unsigned long kernel_start = __pa(_stext);
> -	unsigned long kernel_end = __pa(_end);
> +	unsigned long kernel_end = __pa(_etext);
>  
>  	/*
> -	 * The kernel itself is mapped at page granularity. Map all other
> -	 * memory, making sure we don't overwrite the existing kernel mappings.
> +	 * Take care not to create a writable alias for the
> +	 * read-only text and rodata sections of the kernel image.
>  	 */
>  
> -	/* No overlap with the kernel. */
> +	/* No overlap with the kernel text */
>  	if (end < kernel_start || start >= kernel_end) {
>  		__create_pgd_mapping(pgd, start, __phys_to_virt(start),
>  				     end - start, PAGE_KERNEL,
> @@ -365,7 +369,7 @@ static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end
>  	}
>  
>  	/*
> -	 * This block overlaps the kernel mapping. Map the portion(s) which
> +	 * This block overlaps the kernel text mapping. Map the portion(s) which
>  	 * don't overlap.
>  	 */
>  	if (start < kernel_start)
> @@ -398,25 +402,28 @@ static void __init map_mem(pgd_t *pgd)
>  	}
>  }
>  
> -#ifdef CONFIG_DEBUG_RODATA
>  void mark_rodata_ro(void)
>  {
> +	if (!IS_ENABLED(CONFIG_DEBUG_RODATA))
> +		return;
> +
>  	create_mapping_late(__pa(_stext), (unsigned long)_stext,
>  				(unsigned long)_etext - (unsigned long)_stext,
>  				PAGE_KERNEL_ROX);
> -
>  }
> -#endif
>  
>  void fixup_init(void)
>  {
> -	create_mapping_late(__pa(__init_begin), (unsigned long)__init_begin,
> -			(unsigned long)__init_end - (unsigned long)__init_begin,
> -			PAGE_KERNEL);
> +	/*
> +	 * Unmap the __init region but leave the VM area in place. This
> +	 * prevents the region from being reused for kernel modules, which
> +	 * is not supported by kallsyms.
> +	 */
> +	unmap_kernel_range((u64)__init_begin, (u64)(__init_end - __init_begin));
>  }
>  
>  static void __init map_kernel_chunk(pgd_t *pgd, void *va_start, void *va_end,
> -				    pgprot_t prot)
> +				    pgprot_t prot, struct vm_struct *vma)
>  {
>  	phys_addr_t pa_start = __pa(va_start);
>  	unsigned long size = va_end - va_start;
> @@ -426,6 +433,14 @@ static void __init map_kernel_chunk(pgd_t *pgd, void *va_start, void *va_end,
>  
>  	__create_pgd_mapping(pgd, pa_start, (unsigned long)va_start, size, prot,
>  			     early_pgtable_alloc);
> +
> +	vma->addr	= va_start;
> +	vma->phys_addr	= pa_start;
> +	vma->size	= size;
> +	vma->flags	= VM_MAP;
> +	vma->caller	= map_kernel_chunk;
> +
> +	vm_area_add_early(vma);
>  }
>  
>  /*
> @@ -433,17 +448,35 @@ static void __init map_kernel_chunk(pgd_t *pgd, void *va_start, void *va_end,
>   */
>  static void __init map_kernel(pgd_t *pgd)
>  {
> +	static struct vm_struct vmlinux_text, vmlinux_init, vmlinux_data;
>  
> -	map_kernel_chunk(pgd, _stext, _etext, PAGE_KERNEL_EXEC);
> -	map_kernel_chunk(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC);
> -	map_kernel_chunk(pgd, _data, _end, PAGE_KERNEL);
> +	map_kernel_chunk(pgd, _stext, _etext, PAGE_KERNEL_EXEC, &vmlinux_text);
> +	map_kernel_chunk(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC,
> +			 &vmlinux_init);
> +	map_kernel_chunk(pgd, _data, _end, PAGE_KERNEL, &vmlinux_data);
>  
> -	/*
> -	 * The fixmap falls in a separate pgd to the kernel, and doesn't live
> -	 * in the carveout for the swapper_pg_dir. We can simply re-use the
> -	 * existing dir for the fixmap.
> -	 */
> -	set_pgd(pgd_offset_raw(pgd, FIXADDR_START), *pgd_offset_k(FIXADDR_START));
> +	if (!pgd_val(*pgd_offset_raw(pgd, FIXADDR_START))) {
> +		/*
> +		 * The fixmap falls in a separate pgd to the kernel, and doesn't
> +		 * live in the carveout for the swapper_pg_dir. We can simply
> +		 * re-use the existing dir for the fixmap.
> +		 */
> +		set_pgd(pgd_offset_raw(pgd, FIXADDR_START),
> +			*pgd_offset_k(FIXADDR_START));
> +	} else if (CONFIG_PGTABLE_LEVELS > 3) {
> +		/*
> +		 * The fixmap shares its top level pgd entry with the kernel
> +		 * mapping. This can really only occur when we are running
> +		 * with 16k/4 levels, so we can simply reuse the pud level
> +		 * entry instead.
> +		 */
> +		BUG_ON(!IS_ENABLED(CONFIG_ARM64_16K_PAGES));
> +		set_pud(pud_set_fixmap_offset(pgd, FIXADDR_START),
> +			__pud(__pa(bm_pmd) | PUD_TYPE_TABLE));
> +		pud_clear_fixmap();
> +	} else {
> +		BUG();
> +	}
>  
>  	kasan_copy_shadow(pgd);
>  }
> @@ -569,14 +602,6 @@ void vmemmap_free(unsigned long start, unsigned long end)
>  }
>  #endif	/* CONFIG_SPARSEMEM_VMEMMAP */
>  
> -static pte_t bm_pte[PTRS_PER_PTE] __page_aligned_bss;
> -#if CONFIG_PGTABLE_LEVELS > 2
> -static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss;
> -#endif
> -#if CONFIG_PGTABLE_LEVELS > 3
> -static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss;
> -#endif
> -
>  static inline pud_t * fixmap_pud(unsigned long addr)
>  {
>  	pgd_t *pgd = pgd_offset_k(addr);
> @@ -608,8 +633,18 @@ void __init early_fixmap_init(void)
>  	unsigned long addr = FIXADDR_START;
>  
>  	pgd = pgd_offset_k(addr);
> -	pgd_populate(&init_mm, pgd, bm_pud);
> -	pud = fixmap_pud(addr);
> +	if (CONFIG_PGTABLE_LEVELS > 3 && !pgd_none(*pgd)) {
> +		/*
> +		 * We only end up here if the kernel mapping and the fixmap
> +		 * share the top level pgd entry, which should only happen on
> +		 * 16k/4 levels configurations.
> +		 */
> +		BUG_ON(!IS_ENABLED(CONFIG_ARM64_16K_PAGES));
> +		pud = pud_offset_kimg(pgd, addr);
> +	} else {
> +		pgd_populate(&init_mm, pgd, bm_pud);
> +		pud = fixmap_pud(addr);
> +	}
>  	pud_populate(&init_mm, pud, bm_pmd);
>  	pmd = fixmap_pmd(addr);
>  	pmd_populate_kernel(&init_mm, pmd, bm_pte);
> -- 
> 2.5.0
> 


From wens at csie.org  Mon Feb  1 06:37:45 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 1 Feb 2016 22:37:45 +0800
Subject: [linux-sunxi] Problem with Allwinner H3 clocks
In-Reply-To: <56AF6B23.1010901@redhat.com>
References: <20160127103714.58312b152adb4148bae2f93b@free.fr>
 <56A8D5E5.30701@gmail.com> <20160127175512.87caf31b5e21a1fec91507f2@free.fr>
 <56A9098A.5010107@redhat.com>
 <20160127200217.14dce96ade71cf81bc82e6f6@free.fr>
 <56A9CE3D.4020906@redhat.com> <56AA14AA.4070502@gmail.com>
 <20160128175918.78a916a8cd7bf4c0b2f2814f@free.fr>
 <20160128192931.GB32462@lukather>
 <56AB05EF.2090604@redhat.com> <20160201063731.GG32462@lukather>
 <56AF6B23.1010901@redhat.com>
Message-ID: <CAGb2v67AC+KO9mebyTosxSig7SzYm4Ovr5vCpEsX5N7YadJ-hw@mail.gmail.com>

Hi,

On Mon, Feb 1, 2016 at 10:26 PM, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
>
> On 01-02-16 07:37, Maxime Ripard wrote:
>>
>> Hi,
>>
>> On Fri, Jan 29, 2016 at 07:25:51AM +0100, Hans de Goede wrote:
>>>
>>> Hi,
>>>
>>> On 01/28/2016 08:29 PM, Maxime Ripard wrote:
>>>>
>>>> On Thu, Jan 28, 2016 at 05:59:18PM +0100, Jean-Francois Moine wrote:
>>>
>>>
>>> <snip>
>>>
>>>>> The A23/A33/H3 (and surely some other SoCs) documentations about
>>>>> the peripheral/periph/periph0/periph1 PLLs say:
>>>>>
>>>>>         Note: The PLL Output should be fixed to 600MHz, it is not
>>>>>         recommended to vary this value arbitrarily.
>>>>
>>>>
>>>> I don't know if it's worth it at this point. The pll6 seems to work
>>>> fine at other rates. Have you experienced any breakage when running at
>>>> another frequency?
>>>
>>>
>>> Hmm, are we actually changing the freq of pll6 on any SoCs? I know we've
>>> the code to it, but given that it is shared between many pheripherals,
>>> I assume we end up never changing it.
>>
>>
>> We don't, but it works. Back when I was debugging the A31 DMA
>> controller, I tried to do just that and nothing broke (at least as
>> long as you don't switch halfway through during the boot, but at the
>> time the clock is registered).
>>
>>> I assume / hope that the clock framework protects against reclocking
>>> a clock with multiple users ...
>>
>>
>> There is, but it's opt-in, and we're not using it yet for anything but
>> the hstimers (and in that case, we don't prevent the reclocking, we
>> just take it into account).
>
>
> Shouldn't we be opt-ing in then ? At least the mmc driver makes
> clk_set_rate calls, it would be bad if that somehow ends up changing the
> pll6 rate while other peripherals are using it.

The mod clocks do not have CLK_SET_RATE_PARENT set, which prevents the
CCF from propagating clk_set_rate to its parent. As is for the other
child clocks of PLL6. The only exception is the SATA clock in PLL6.

Regards
ChenYu


From robh at kernel.org  Mon Feb  1 06:39:15 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 08:39:15 -0600
Subject: [PATCH 1/3] Input: tps6507x-ts - add binding for tps6507x-ts
In-Reply-To: <1454308130-12452-2-git-send-email-sushaanth.s@ti.com>
References: <1454308130-12452-1-git-send-email-sushaanth.s@ti.com>
 <1454308130-12452-2-git-send-email-sushaanth.s@ti.com>
Message-ID: <20160201143915.GA9909@rob-hp-laptop>

On Mon, Feb 01, 2016 at 11:58:47AM +0530, Sushaanth Srirangapathi wrote:
> add binding information for tps6507x touchscreen input.
> 
> "ti,min-pressure" was added as TI specific binding because it
> was specific to tps6507x IP and not applicable or relevant for
> other touchscreen drivers.
> 
> Signed-off-by: Sushaanth Srirangapathi <sushaanth.s at ti.com>
> ---
>  Documentation/devicetree/bindings/mfd/tps6507x.txt |   10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)

Seems like you would need other properties from the common touchscreen 
binding.

Acked-by: Rob Herring <robh at kernel.org>



From christoffer.dall at linaro.org  Mon Feb  1 06:41:03 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 15:41:03 +0100
Subject: [PATCH v2 18/21] arm64: KVM: Introduce hyp_alternate_value helper
In-Reply-To: <1453737235-16522-19-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-19-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201144103.GX1478@cbox>

On Mon, Jan 25, 2016 at 03:53:52PM +0000, Marc Zyngier wrote:
> We already have hyp_alternate_select() to define a function pointer
> that gets changed by a kernel feature or workaround.
> 
> It would be useful to have a similar feature that resolves in a
> direct value, without requiring a function call. For this purpose,
> introduce hyp_alternate_value(), which returns one of two values
> depending on the state of the alternative.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/hyp/hyp.h | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
> index 44eaff7..dc75fdb 100644
> --- a/arch/arm64/kvm/hyp/hyp.h
> +++ b/arch/arm64/kvm/hyp/hyp.h
> @@ -144,6 +144,17 @@ typeof(orig) * __hyp_text fname(void)					\
>  	return val;							\
>  }
>  
> +#define hyp_alternate_value(fname, orig, alt, cond)			\
> +typeof(orig) __hyp_text fname(void)					\
> +{									\
> +	typeof(alt) val = orig;						\
> +	asm volatile(ALTERNATIVE("nop		\n",			\
> +				 "mov	%0, %1	\n",			\
> +				 cond)					\
> +		     : "+r" (val) : "r" ((typeof(orig))alt));		\
> +	return val;							\
> +}
> +
>  void __vgic_v2_save_state(struct kvm_vcpu *vcpu);
>  void __vgic_v2_restore_state(struct kvm_vcpu *vcpu);
>  
> -- 
> 2.1.4
> 
I'm really not convinced that this is more readable than simply defining
a function where needed.  Perhaps the thing that needs a definition is
the "asm volatile(ALTERNATIVE(...))" part?  I also don't see why any of
this is specific to KVM or Hyp ?

-Christoffer


From wens at csie.org  Mon Feb  1 06:42:49 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon,  1 Feb 2016 22:42:49 +0800
Subject: [PATCH 2/2] ARM: dts: sun9i: Fix apbs clock compatible
In-Reply-To: <1454337769-4130-1-git-send-email-wens@csie.org>
References: <1454337769-4130-1-git-send-email-wens@csie.org>
Message-ID: <1454337769-4130-3-git-send-email-wens@csie.org>

The APBS clock on A80 is not compatible with A23's APB0 clock. The only
reason it works is becase the lowest and default divider is the same.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/boot/dts/sun9i-a80.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index f68b3242b33a..2b4ce813b0ad 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -395,7 +395,7 @@
 		};
 
 		apbs: clk at 0800141c {
-			compatible = "allwinner,sun8i-a23-apb0-clk";
+			compatible = "allwinner,sun9i-a80-apbs-clk";
 			reg = <0x0800141c 0x4>;
 			#clock-cells = <0>;
 			clocks = <&ahbs>;
-- 
2.7.0



From wens at csie.org  Mon Feb  1 06:42:47 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon,  1 Feb 2016 22:42:47 +0800
Subject: [PATCH 0/2] clk: sunxi: Fix APBS clock for Allwinner A80
Message-ID: <1454337769-4130-1-git-send-email-wens@csie.org>

Hi everyone,

When I did the A80 PRCM support, I failed to notice the A80's APBS clock
was not the same as the A23's APB0 clock. The former is a zero-based
divider, while the latter is a power-of-two divider. But the lowest 2
dividers are the same.

The hardware defaults to the lowest setting, or a /1 divider. Since the
child gates do not propagate clk_set_rate up, and no consumers here do
clk_set_rate, this actually works.

I realized my mistake while reviewing the A83T's PRCM patches. The A83T
shares the same PRCM clocks as the A80.


Regards
ChenYu


Chen-Yu Tsai (2):
  clk: sunxi: Add support for A80 APBS clock
  ARM: dts: sun9i: Fix apbs clock compatible

 Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
 arch/arm/boot/dts/sun9i-a80.dtsi                  |  2 +-
 drivers/clk/sunxi/Makefile                        |  2 +-
 drivers/clk/sunxi/clk-sun9i-apbs.c                | 64 +++++++++++++++++++++++
 4 files changed, 67 insertions(+), 2 deletions(-)
 create mode 100644 drivers/clk/sunxi/clk-sun9i-apbs.c

-- 
2.7.0



From wens at csie.org  Mon Feb  1 06:42:48 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon,  1 Feb 2016 22:42:48 +0800
Subject: [PATCH 1/2] clk: sunxi: Add support for A80 APBS clock
In-Reply-To: <1454337769-4130-1-git-send-email-wens@csie.org>
References: <1454337769-4130-1-git-send-email-wens@csie.org>
Message-ID: <1454337769-4130-2-git-send-email-wens@csie.org>

A80's APBS clock is not the same as the APB0 clock on A23. The A80's
is a zero-based divider, while the A23's is a power-of-two divider.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
 drivers/clk/sunxi/Makefile                        |  2 +-
 drivers/clk/sunxi/clk-sun9i-apbs.c                | 64 +++++++++++++++++++++++
 3 files changed, 66 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/sunxi/clk-sun9i-apbs.c

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index e59f57b24777..fad81157798c 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -58,6 +58,7 @@ Required properties:
 	"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
 	"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
 	"allwinner,sun8i-h3-bus-gates-clk" - for the bus gates on H3
+	"allwinner,sun9i-a80-apbs-clk" - for the APBS clock on A80
 	"allwinner,sun9i-a80-apbs-gates-clk" - for the APBS gates on A80
 	"allwinner,sun4i-a10-dram-gates-clk" - for the DRAM gates on A10
 	"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 3fd7901d48e4..df433b3f789d 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -17,7 +17,7 @@ obj-y += clk-sun9i-core.o
 obj-y += clk-sun9i-mmc.o
 obj-y += clk-usb.o
 
-obj-$(CONFIG_MACH_SUN9I) += clk-sun8i-apb0.o
+obj-$(CONFIG_MACH_SUN9I) += clk-sun9i-apbs.o
 obj-$(CONFIG_MACH_SUN9I) += clk-sun9i-cpus.o
 
 obj-$(CONFIG_MFD_SUN6I_PRCM) += \
diff --git a/drivers/clk/sunxi/clk-sun9i-apbs.c b/drivers/clk/sunxi/clk-sun9i-apbs.c
new file mode 100644
index 000000000000..aacb92873621
--- /dev/null
+++ b/drivers/clk/sunxi/clk-sun9i-apbs.c
@@ -0,0 +1,64 @@
+/*
+ * Copyright (C) 2016 Chen-Yu Tsai
+ * Author: Chen-Yu Tsai <wens at csie.org>
+ *
+ * Allwinner A80 APBS clock driver
+ *
+ * License Terms: GNU General Public License v2
+ *
+ * Based on clk-sun6i-apbs.c
+ * Allwinner A31 APB0 clock driver
+ *
+ * Copyright (C) 2014 Free Electrons
+ * Author: Boris BREZILLON <boris.brezillon at free-electrons.com>
+ *
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+static void sun9i_apbs_setup(struct device_node *node)
+{
+	const char *name = node->name;
+	const char *parent;
+	struct resource res;
+	struct clk *clk;
+	void __iomem *reg;
+	int ret;
+
+	reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+	if (IS_ERR(reg)) {
+		pr_err("Could not get registers for a80-apbs-clk\n");
+		return;
+	}
+
+	parent = of_clk_get_parent_name(node, 0);
+	if (!parent)
+		return;
+
+	of_property_read_string(node, "clock-output-names", &name);
+
+	/* The A80 APBS clock is a standard 2 bit wide divider clock */
+	clk = clk_register_divider(NULL, name, parent, 0, reg, 0, 2, 0, NULL);
+	if (IS_ERR(clk)) {
+		pr_err("failed to register a80-apbs-clk: %ld\n", PTR_ERR(clk));
+		goto err_unmap;
+	}
+
+	ret = of_clk_add_provider(node, of_clk_src_simple_get, clk);
+	if (ret)
+		goto err_unregister;
+
+	return;
+
+err_unregister:
+	clk_unregister_divider(clk);
+err_unmap:
+	iounmap(reg);
+	of_address_to_resource(node, 0, &res);
+	release_mem_region(res.start, resource_size(&res));
+}
+CLK_OF_DECLARE(sun9i_apbs, "allwinner,sun9i-a80-apbs-clk", sun9i_apbs_setup);
-- 
2.7.0



From maxime.ripard at free-electrons.com  Mon Feb  1 06:45:48 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 1 Feb 2016 15:45:48 +0100
Subject: [linux-sunxi] Problem with Allwinner H3 clocks
In-Reply-To: <CAGb2v67AC+KO9mebyTosxSig7SzYm4Ovr5vCpEsX5N7YadJ-hw@mail.gmail.com>
References: <56A9098A.5010107@redhat.com>
 <20160127200217.14dce96ade71cf81bc82e6f6@free.fr>
 <56A9CE3D.4020906@redhat.com> <56AA14AA.4070502@gmail.com>
 <20160128175918.78a916a8cd7bf4c0b2f2814f@free.fr>
 <20160128192931.GB32462@lukather> <56AB05EF.2090604@redhat.com>
 <20160201063731.GG32462@lukather> <56AF6B23.1010901@redhat.com>
 <CAGb2v67AC+KO9mebyTosxSig7SzYm4Ovr5vCpEsX5N7YadJ-hw@mail.gmail.com>
Message-ID: <20160201144548.GD4652@lukather>

On Mon, Feb 01, 2016 at 10:37:45PM +0800, Chen-Yu Tsai wrote:
> >> There is, but it's opt-in, and we're not using it yet for anything but
> >> the hstimers (and in that case, we don't prevent the reclocking, we
> >> just take it into account).
> >
> > Shouldn't we be opt-ing in then ? At least the mmc driver makes
> > clk_set_rate calls, it would be bad if that somehow ends up changing the
> > pll6 rate while other peripherals are using it.
> 
> The mod clocks do not have CLK_SET_RATE_PARENT set, which prevents the
> CCF from propagating clk_set_rate to its parent. As is for the other
> child clocks of PLL6. The only exception is the SATA clock in PLL6.

The PLL6 you're talking about is not the PLL6 we're talking about ;)

We're talking about the A31's, while the SATA on the A10 / A20 is
driven by the A10's (the equivalent for the A10 would be the PLL5)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160201/3321040e/attachment.sig>

From maxime.ripard at free-electrons.com  Mon Feb  1 06:47:11 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 1 Feb 2016 15:47:11 +0100
Subject: [linux-sunxi] Problem with Allwinner H3 clocks
In-Reply-To: <56AF6B23.1010901@redhat.com>
References: <20160127175512.87caf31b5e21a1fec91507f2@free.fr>
 <56A9098A.5010107@redhat.com>
 <20160127200217.14dce96ade71cf81bc82e6f6@free.fr>
 <56A9CE3D.4020906@redhat.com> <56AA14AA.4070502@gmail.com>
 <20160128175918.78a916a8cd7bf4c0b2f2814f@free.fr>
 <20160128192931.GB32462@lukather> <56AB05EF.2090604@redhat.com>
 <20160201063731.GG32462@lukather> <56AF6B23.1010901@redhat.com>
Message-ID: <20160201144711.GE4652@lukather>

On Mon, Feb 01, 2016 at 03:26:43PM +0100, Hans de Goede wrote:
> >There is, but it's opt-in, and we're not using it yet for anything but
> >the hstimers (and in that case, we don't prevent the reclocking, we
> >just take it into account).
> 
> Shouldn't we be opt-ing in then ? At least the mmc driver makes
> clk_set_rate calls, it would be bad if that somehow ends up changing the
> pll6 rate while other peripherals are using it.

Well, no one will change the pll6 rate at the moment.

Adding code for some case that will not arise doesn't seem very useful

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160201/fce0cbfc/attachment.sig>

From robh at kernel.org  Mon Feb  1 06:49:23 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 08:49:23 -0600
Subject: [PATCH 04/14] clk: sunxi: add ahb1 clock for A83T
In-Reply-To: <1454203266-4450-5-git-send-email-vishnupatekar0510@gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-5-git-send-email-vishnupatekar0510@gmail.com>
Message-ID: <20160201144923.GA29286@rob-hp-laptop>

On Sun, Jan 31, 2016 at 09:20:56AM +0800, Vishnu Patekar wrote:
> AHB1 on A83T is similar to ahb1 on A31, except parents are different.
> clock index 0b1x is PLL6.
> 
> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt |  1 +

Acked-by: Rob Herring <robh at kernel.org>

>  drivers/clk/sunxi/clk-sunxi.c                     | 75 +++++++++++++++++++++++
>  2 files changed, 76 insertions(+)


From robh at kernel.org  Mon Feb  1 06:50:05 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 08:50:05 -0600
Subject: [PATCH 05/14] clk: sunxi: Add APB1 clock for A83T
In-Reply-To: <1454203266-4450-6-git-send-email-vishnupatekar0510@gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-6-git-send-email-vishnupatekar0510@gmail.com>
Message-ID: <20160201145005.GA29776@rob-hp-laptop>

On Sun, Jan 31, 2016 at 09:20:57AM +0800, Vishnu Patekar wrote:
> APB1 is similar to sun4i-a10-apb0-clk, except different dividers.
> 
> This adds support for apb1 on A83T.
> 
> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt |  1 +

Acked-by: Rob Herring <robh at kernel.org>

>  drivers/clk/sunxi/clk-sunxi.c                     | 17 +++++++++++++++++
>  2 files changed, 18 insertions(+)


From mark.rutland at arm.com  Mon Feb  1 06:50:14 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 1 Feb 2016 14:50:14 +0000
Subject: [PATCH v5sub1 8/8] arm64: allow kernel Image to be loaded
 anywhere in physical memory
In-Reply-To: <1454324093-15998-9-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-9-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160201145014.GK674@leverpostej>

On Mon, Feb 01, 2016 at 11:54:53AM +0100, Ard Biesheuvel wrote:
> This relaxes the kernel Image placement requirements, so that it
> may be placed at any 2 MB aligned offset in physical memory.
> 
> This is accomplished by ignoring PHYS_OFFSET when installing
> memblocks, and accounting for the apparent virtual offset of
> the kernel Image. As a result, virtual address references
> below PAGE_OFFSET are correctly mapped onto physical references
> into the kernel Image regardless of where it sits in memory.
> 
> Note that limiting memory using mem= is not unambiguous anymore after
> this change, considering that the kernel may be at the top of physical
> memory, and clipping from the bottom rather than the top will discard
> any 32-bit DMA addressable memory first. To deal with this, the handling
> of mem= is reimplemented to clip top down, but take special care not to
> clip memory that covers the kernel image.
> 
> Since mem= should not be considered a production feature, a panic notifier
> handler is installed that dumps the memory limit at panic time if one was
> set.

Good idea!

It would be great if we could follow up with a sizes.h update for SZ_4G,
though that's only a nice-to-have, and in no way should block this.

Other than that, this looks good. Thanks for putting this together!

Reviewed-by: Mark Rutland <mark.rutland at arm.com>

For the Documentation/arm64 parts we'll need to ask Fu Wei to update the
zh_CN/ translation to match.

Mark.

> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
>  Documentation/arm64/booting.txt         |  20 ++--
>  arch/arm64/include/asm/boot.h           |   6 ++
>  arch/arm64/include/asm/kernel-pgtable.h |  12 +++
>  arch/arm64/include/asm/kvm_asm.h        |   2 +-
>  arch/arm64/include/asm/memory.h         |  15 +--
>  arch/arm64/kernel/head.S                |   6 +-
>  arch/arm64/kernel/image.h               |  13 ++-
>  arch/arm64/mm/init.c                    | 100 +++++++++++++++++++-
>  arch/arm64/mm/mmu.c                     |   3 +
>  9 files changed, 155 insertions(+), 22 deletions(-)
> 
> diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt
> index 701d39d3171a..56d6d8b796db 100644
> --- a/Documentation/arm64/booting.txt
> +++ b/Documentation/arm64/booting.txt
> @@ -109,7 +109,13 @@ Header notes:
>  			1 - 4K
>  			2 - 16K
>  			3 - 64K
> -  Bits 3-63:	Reserved.
> +  Bit 3:	Kernel physical placement
> +			0 - 2MB aligned base should be as close as possible
> +			    to the base of DRAM, since memory below it is not
> +			    accessible via the linear mapping
> +			1 - 2MB aligned base may be anywhere in physical
> +			    memory
> +  Bits 4-63:	Reserved.
>  
>  - When image_size is zero, a bootloader should attempt to keep as much
>    memory as possible free for use by the kernel immediately after the
> @@ -117,14 +123,14 @@ Header notes:
>    depending on selected features, and is effectively unbound.
>  
>  The Image must be placed text_offset bytes from a 2MB aligned base
> -address near the start of usable system RAM and called there. Memory
> -below that base address is currently unusable by Linux, and therefore it
> -is strongly recommended that this location is the start of system RAM.
> -The region between the 2 MB aligned base address and the start of the
> -image has no special significance to the kernel, and may be used for
> -other purposes.
> +address anywhere in usable system RAM and called there. The region
> +between the 2 MB aligned base address and the start of the image has no
> +special significance to the kernel, and may be used for other purposes.
>  At least image_size bytes from the start of the image must be free for
>  use by the kernel.
> +NOTE: versions prior to v4.6 cannot make use of memory below the
> +physical offset of the Image so it is recommended that the Image be
> +placed as close as possible to the start of system RAM.
>  
>  Any memory described to the kernel (even that below the start of the
>  image) which is not marked as reserved from the kernel (e.g., with a
> diff --git a/arch/arm64/include/asm/boot.h b/arch/arm64/include/asm/boot.h
> index 81151b67b26b..ebf2481889c3 100644
> --- a/arch/arm64/include/asm/boot.h
> +++ b/arch/arm64/include/asm/boot.h
> @@ -11,4 +11,10 @@
>  #define MIN_FDT_ALIGN		8
>  #define MAX_FDT_SIZE		SZ_2M
>  
> +/*
> + * arm64 requires the kernel image to placed
> + * TEXT_OFFSET bytes beyond a 2 MB aligned base
> + */
> +#define MIN_KIMG_ALIGN		SZ_2M
> +
>  #endif
> diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
> index a459714ee29e..5c6375d8528b 100644
> --- a/arch/arm64/include/asm/kernel-pgtable.h
> +++ b/arch/arm64/include/asm/kernel-pgtable.h
> @@ -79,5 +79,17 @@
>  #define SWAPPER_MM_MMUFLAGS	(PTE_ATTRINDX(MT_NORMAL) | SWAPPER_PTE_FLAGS)
>  #endif
>  
> +/*
> + * To make optimal use of block mappings when laying out the linear
> + * mapping, round down the base of physical memory to a size that can
> + * be mapped efficiently, i.e., either PUD_SIZE (4k granule) or PMD_SIZE
> + * (64k granule), or a multiple that can be mapped using contiguous bits
> + * in the page tables: 32 * PMD_SIZE (16k granule)
> + */
> +#ifdef CONFIG_ARM64_64K_PAGES
> +#define ARM64_MEMSTART_ALIGN	SZ_512M
> +#else
> +#define ARM64_MEMSTART_ALIGN	SZ_1G
> +#endif
>  
>  #endif	/* __ASM_KERNEL_PGTABLE_H */
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index f5aee6e764e6..054ac25e7c2e 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -26,7 +26,7 @@
>  #define KVM_ARM64_DEBUG_DIRTY_SHIFT	0
>  #define KVM_ARM64_DEBUG_DIRTY		(1 << KVM_ARM64_DEBUG_DIRTY_SHIFT)
>  
> -#define kvm_ksym_ref(sym)		((void *)&sym - KIMAGE_VADDR + PAGE_OFFSET)
> +#define kvm_ksym_ref(sym)		phys_to_virt((u64)&sym - kimage_voffset)
>  
>  #ifndef __ASSEMBLY__
>  struct kvm;
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 4388651d1f0d..61005e7dd6cb 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -88,10 +88,10 @@
>  #define __virt_to_phys(x) ({						\
>  	phys_addr_t __x = (phys_addr_t)(x);				\
>  	__x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :	\
> -			     (__x - KIMAGE_VADDR + PHYS_OFFSET); })
> +			     (__x - kimage_voffset); })
>  
>  #define __phys_to_virt(x)	((unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET))
> -#define __phys_to_kimg(x)	((unsigned long)((x) - PHYS_OFFSET + KIMAGE_VADDR))
> +#define __phys_to_kimg(x)	((unsigned long)((x) + kimage_voffset))
>  
>  /*
>   * Convert a page to/from a physical address
> @@ -127,13 +127,14 @@ extern phys_addr_t		memstart_addr;
>  /* PHYS_OFFSET - the physical address of the start of memory. */
>  #define PHYS_OFFSET		({ memstart_addr; })
>  
> +/* the offset between the kernel virtual and physical mappings */
> +extern u64			kimage_voffset;
> +
>  /*
> - * The maximum physical address that the linear direct mapping
> - * of system RAM can cover. (PAGE_OFFSET can be interpreted as
> - * a 2's complement signed quantity and negated to derive the
> - * maximum size of the linear mapping.)
> + * Allow all memory at the discovery stage. We will clip it later.
>   */
> -#define MAX_MEMBLOCK_ADDR	({ memstart_addr - PAGE_OFFSET - 1; })
> +#define MIN_MEMBLOCK_ADDR	0
> +#define MAX_MEMBLOCK_ADDR	U64_MAX
>  
>  /*
>   * PFNs are used to describe any physical page; this means
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 04d38a058b19..05b98289093e 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -428,7 +428,11 @@ __mmap_switched:
>  	and	x4, x4, #~(THREAD_SIZE - 1)
>  	msr	sp_el0, x4			// Save thread_info
>  	str_l	x21, __fdt_pointer, x5		// Save FDT pointer
> -	str_l	x24, memstart_addr, x6		// Save PHYS_OFFSET
> +
> +	ldr	x4, =KIMAGE_VADDR		// Save the offset between
> +	sub	x4, x4, x24			// the kernel virtual and
> +	str_l	x4, kimage_voffset, x5		// physical mappings
> +
>  	mov	x29, #0
>  #ifdef CONFIG_KASAN
>  	bl	kasan_early_init
> diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
> index 999633bd7294..c9c62cab25a4 100644
> --- a/arch/arm64/kernel/image.h
> +++ b/arch/arm64/kernel/image.h
> @@ -42,15 +42,18 @@
>  #endif
>  
>  #ifdef CONFIG_CPU_BIG_ENDIAN
> -#define __HEAD_FLAG_BE	1
> +#define __HEAD_FLAG_BE		1
>  #else
> -#define __HEAD_FLAG_BE	0
> +#define __HEAD_FLAG_BE		0
>  #endif
>  
> -#define __HEAD_FLAG_PAGE_SIZE ((PAGE_SHIFT - 10) / 2)
> +#define __HEAD_FLAG_PAGE_SIZE	((PAGE_SHIFT - 10) / 2)
>  
> -#define __HEAD_FLAGS	((__HEAD_FLAG_BE << 0) |	\
> -			 (__HEAD_FLAG_PAGE_SIZE << 1))
> +#define __HEAD_FLAG_PHYS_BASE	1
> +
> +#define __HEAD_FLAGS		((__HEAD_FLAG_BE << 0) |	\
> +				 (__HEAD_FLAG_PAGE_SIZE << 1) |	\
> +				 (__HEAD_FLAG_PHYS_BASE << 3))
>  
>  /*
>   * These will output as part of the Image header, which should be little-endian
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 1d627cd8121c..e8e853a1024c 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -35,8 +35,10 @@
>  #include <linux/efi.h>
>  #include <linux/swiotlb.h>
>  
> +#include <asm/boot.h>
>  #include <asm/fixmap.h>
>  #include <asm/kasan.h>
> +#include <asm/kernel-pgtable.h>
>  #include <asm/memory.h>
>  #include <asm/sections.h>
>  #include <asm/setup.h>
> @@ -158,9 +160,80 @@ static int __init early_mem(char *p)
>  }
>  early_param("mem", early_mem);
>  
> +/*
> + * clip_mem_range() - remove memblock memory between @min and @max until
> + *                    we meet the limit in 'memory_limit'.
> + */
> +static void __init clip_mem_range(u64 min, u64 max)
> +{
> +	u64 mem_size, to_remove;
> +	int i;
> +
> +again:
> +	mem_size = memblock_phys_mem_size();
> +	if (mem_size <= memory_limit || max <= min)
> +		return;
> +
> +	to_remove = mem_size - memory_limit;
> +
> +	for (i = memblock.memory.cnt - 1; i >= 0; i--) {
> +		struct memblock_region *r = memblock.memory.regions + i;
> +		u64 start = max(min, r->base);
> +		u64 end = min(max, r->base + r->size);
> +
> +		if (start >= max || end <= min)
> +			continue;
> +
> +		if (end > min) {
> +			u64 size = min(to_remove, end - max(start, min));
> +
> +			memblock_remove(end - size, size);
> +		} else {
> +			memblock_remove(start, min(max - start, to_remove));
> +		}
> +		goto again;
> +	}
> +}
> +
>  void __init arm64_memblock_init(void)
>  {
> -	memblock_enforce_memory_limit(memory_limit);
> +	const s64 linear_region_size = -(s64)PAGE_OFFSET;
> +
> +	/*
> +	 * Select a suitable value for the base of physical memory.
> +	 */
> +	memstart_addr = round_down(memblock_start_of_DRAM(),
> +				   ARM64_MEMSTART_ALIGN);
> +
> +	/*
> +	 * Remove the memory that we will not be able to cover with the
> +	 * linear mapping. Take care not to clip the kernel which may be
> +	 * high in memory.
> +	 */
> +	memblock_remove(max(memstart_addr + linear_region_size, __pa(_end)),
> +			ULLONG_MAX);
> +	if (memblock_end_of_DRAM() > linear_region_size)
> +		memblock_remove(0, memblock_end_of_DRAM() - linear_region_size);
> +
> +	if (memory_limit != (phys_addr_t)ULLONG_MAX) {
> +		u64 kbase = round_down(__pa(_text), MIN_KIMG_ALIGN);
> +		u64 kend = PAGE_ALIGN(__pa(_end));
> +		u64 const sz_4g = 0x100000000UL;
> +
> +		/*
> +		 * Clip memory in order of preference:
> +		 * - above the kernel and above 4 GB
> +		 * - between 4 GB and the start of the kernel (if the kernel
> +		 *   is loaded high in memory)
> +		 * - between the kernel and 4 GB (if the kernel is loaded
> +		 *   low in memory)
> +		 * - below 4 GB
> +		 */
> +		clip_mem_range(max(sz_4g, kend), ULLONG_MAX);
> +		clip_mem_range(sz_4g, kbase);
> +		clip_mem_range(kend, sz_4g);
> +		clip_mem_range(0, min(kbase, sz_4g));
> +	}
>  
>  	/*
>  	 * Register the kernel text, kernel data, initrd, and initial
> @@ -381,3 +454,28 @@ static int __init keepinitrd_setup(char *__unused)
>  
>  __setup("keepinitrd", keepinitrd_setup);
>  #endif
> +
> +/*
> + * Dump out memory limit information on panic.
> + */
> +static int dump_mem_limit(struct notifier_block *self, unsigned long v, void *p)
> +{
> +	if (memory_limit != (phys_addr_t)ULLONG_MAX) {
> +		pr_emerg("Memory Limit: %llu MB\n", memory_limit >> 20);
> +	} else {
> +		pr_emerg("Memory Limit: none\n");
> +	}
> +	return 0;
> +}
> +
> +static struct notifier_block mem_limit_notifier = {
> +	.notifier_call = dump_mem_limit,
> +};
> +
> +static int __init register_mem_limit_dumper(void)
> +{
> +	atomic_notifier_chain_register(&panic_notifier_list,
> +				       &mem_limit_notifier);
> +	return 0;
> +}
> +__initcall(register_mem_limit_dumper);
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 4c4b15932963..8dda38378959 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -46,6 +46,9 @@
>  
>  u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
>  
> +u64 kimage_voffset __read_mostly;
> +EXPORT_SYMBOL(kimage_voffset);
> +
>  /*
>   * Empty_zero_page is a special page that is used for zero-initialized data
>   * and COW.
> -- 
> 2.5.0
> 


From wens at csie.org  Mon Feb  1 06:54:16 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 1 Feb 2016 22:54:16 +0800
Subject: [PATCH 04/14] clk: sunxi: add ahb1 clock for A83T
In-Reply-To: <20160201144923.GA29286@rob-hp-laptop>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-5-git-send-email-vishnupatekar0510@gmail.com>
 <20160201144923.GA29286@rob-hp-laptop>
Message-ID: <CAGb2v65zMGEagqML+2Y27M1hbdEWpMj96i0Dr5Ak67jnTcwhyw@mail.gmail.com>

On Mon, Feb 1, 2016 at 10:49 PM, Rob Herring <robh at kernel.org> wrote:
> On Sun, Jan 31, 2016 at 09:20:56AM +0800, Vishnu Patekar wrote:
>> AHB1 on A83T is similar to ahb1 on A31, except parents are different.
>> clock index 0b1x is PLL6.
>>
>> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
>> ---
>>  Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
>
> Acked-by: Rob Herring <robh at kernel.org>
>
>>  drivers/clk/sunxi/clk-sunxi.c                     | 75 +++++++++++++++++++++++
>>  2 files changed, 76 insertions(+)

Acked-by: Chen-Yu Tsai <wens at csie.org>


From gnomes at lxorguk.ukuu.org.uk  Mon Feb  1 06:54:57 2016
From: gnomes at lxorguk.ukuu.org.uk (One Thousand Gnomes)
Date: Mon, 1 Feb 2016 14:54:57 +0000
Subject: [PATCH] staging: goldfish: use div64_s64 instead of do_div
In-Reply-To: <1676170.0qik6mzm6D@wuerfel>
References: <1676170.0qik6mzm6D@wuerfel>
Message-ID: <20160201145457.7879d53f@lxorguk.ukuu.org.uk>

On Mon, 01 Feb 2016 11:33 +0100
Arnd Bergmann <arnd at arndb.de> wrote:

> The goldfish nand driver divides a signed 64-bit number (loff_t)
> in multiple places using the do_div() function. This has always
> been unreliable but now produces a compiler warning (since 4.5-rc1):
> 
> goldfish/goldfish_nand.c: In function 'goldfish_nand_erase':
> goldfish/goldfish_nand.c:107:91: error: comparison of distinct pointer types lacks a cast [-Werror]
> goldfish/goldfish_nand.c: In function 'goldfish_nand_read_oob':
> goldfish/goldfish_nand.c:145:91: error: comparison of distinct pointer types lacks a cast [-Werror]
> 
> This changes the code to the equivalent div_s64{,_rem} that
> works correctly for negative numbers (which we should never
> get here).

We can't get negatives as you say so surely the right fix is a cast or to
fix mtd->writesize ?


From catalin.marinas at arm.com  Mon Feb  1 06:56:25 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 1 Feb 2016 14:56:25 +0000
Subject: [PATCH v5sub1 2/8] arm64: add support for ioremap() block mappings
In-Reply-To: <20160201141004.GI674@leverpostej>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-3-git-send-email-ard.biesheuvel@linaro.org>
 <20160201141004.GI674@leverpostej>
Message-ID: <20160201145624.GF15514@e104818-lin.cambridge.arm.com>

On Mon, Feb 01, 2016 at 02:10:04PM +0000, Mark Rutland wrote:
> On Mon, Feb 01, 2016 at 11:54:47AM +0100, Ard Biesheuvel wrote:
> > This wires up the existing generic huge-vmap feature, which allows
> > ioremap() to use PMD or PUD sized block mappings. It also adds support
> > to the unmap path for dealing with block mappings, which will allow us
> > to unmap the __init region using unmap_kernel_range() in a subsequent
> > patch.
> > 
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> 
> Reviewed-by: Mark Rutland <mark.rutland at arm.com>
> 
> I was a little bit worried about this potentially not matching the
> granularity we used when creating mappings, but seeing how
> p?d_clear_huge are called by unmap_kernel_range, I think this is fine.

I tried the warnings below and they didn't trigger. Anyway, if we ever
unmapped more, I guess we would have quickly triggered a kernel fault.

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index fb42a5bffe47..40362d62d1e1 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -77,8 +77,10 @@ static void vunmap_pmd_range(pud_t *pud, unsigned long addr, unsigned long end)
 	pmd = pmd_offset(pud, addr);
 	do {
 		next = pmd_addr_end(addr, end);
-		if (pmd_clear_huge(pmd))
+		if (pmd_clear_huge(pmd)) {
+			WARN_ON(next < addr + PMD_SIZE);
 			continue;
+		}
 		if (pmd_none_or_clear_bad(pmd))
 			continue;
 		vunmap_pte_range(pmd, addr, next);
@@ -93,8 +95,10 @@ static void vunmap_pud_range(pgd_t *pgd, unsigned long addr, unsigned long end)
 	pud = pud_offset(pgd, addr);
 	do {
 		next = pud_addr_end(addr, end);
-		if (pud_clear_huge(pud))
+		if (pud_clear_huge(pud)) {
+			WARN_ON(next < addr + PUD_SIZE);
 			continue;
+		}
 		if (pud_none_or_clear_bad(pud))
 			continue;
 		vunmap_pmd_range(pud, addr, next);

-- 
Catalin


From robh at kernel.org  Mon Feb  1 06:57:49 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 08:57:49 -0600
Subject: [PATCH 1/2] clk: sunxi: Add support for A80 APBS clock
In-Reply-To: <1454337769-4130-2-git-send-email-wens@csie.org>
References: <1454337769-4130-1-git-send-email-wens@csie.org>
 <1454337769-4130-2-git-send-email-wens@csie.org>
Message-ID: <20160201145749.GA31544@rob-hp-laptop>

On Mon, Feb 01, 2016 at 10:42:48PM +0800, Chen-Yu Tsai wrote:
> A80's APBS clock is not the same as the APB0 clock on A23. The A80's
> is a zero-based divider, while the A23's is a power-of-two divider.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt |  1 +

Acked-by: Rob Herring <robh at kernel.org>

>  drivers/clk/sunxi/Makefile                        |  2 +-
>  drivers/clk/sunxi/clk-sun9i-apbs.c                | 64 +++++++++++++++++++++++
>  3 files changed, 66 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/clk/sunxi/clk-sun9i-apbs.c



From wens at csie.org  Mon Feb  1 06:59:58 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon,  1 Feb 2016 22:59:58 +0800
Subject: [PATCH] ARM: dts: sun9i: a80-optimus: Remove i2c3 and uart4
Message-ID: <1454338798-5929-1-git-send-email-wens@csie.org>

i2c3 and uart4 are available on the GPIO header. Though these pins only
have this one special function, the user may choose to use them as GPIOs
instead.

Since our policy is not to choose what function to present on the GPIO
headers of development boards, remove them.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/boot/dts/sun9i-a80-optimus.dts | 22 ----------------------
 1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index 958160e40fd0..d7a20d92b114 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -109,17 +109,6 @@
 	status = "okay";
 };
 
-&i2c3 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&i2c3_pins_a>;
-	status = "okay";
-};
-
-&i2c3_pins_a {
-	/* Enable internal pull-up */
-	allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
-};
-
 &ohci0 {
 	status = "okay";
 };
@@ -212,17 +201,6 @@
 	status = "okay";
 };
 
-&uart4 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&uart4_pins_a>;
-	status = "okay";
-};
-
-&uart4_pins_a {
-	/* Enable internal pull-up */
-	allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
-};
-
 &usbphy1 {
 	phy-supply = <&reg_usb1_vbus>;
 	status = "okay";
-- 
2.7.0



From robh at kernel.org  Mon Feb  1 07:00:58 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 09:00:58 -0600
Subject: [PATCH 01/14] pinctrl: sunxi: Add A83T R_PIO controller support
In-Reply-To: <1454203266-4450-2-git-send-email-vishnupatekar0510@gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-2-git-send-email-vishnupatekar0510@gmail.com>
Message-ID: <20160201150058.GA3209@rob-hp-laptop>

On Sun, Jan 31, 2016 at 09:20:53AM +0800, Vishnu Patekar wrote:
> The A83T has R_PIO pin controller, it's same as A23, execpt A83T
> interrupt bit is 6th and A83T has one extra pin PL12.
> 
> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
> ---
>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +

Acked-by: Rob Herring <robh at kernel.org>

>  drivers/pinctrl/sunxi/Kconfig                      |   5 +
>  drivers/pinctrl/sunxi/Makefile                     |   1 +
>  drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c       | 119 +++++++++++++++++++++
>  4 files changed, 126 insertions(+)
>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c


From robh at kernel.org  Mon Feb  1 07:02:18 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 09:02:18 -0600
Subject: [PATCH 02/14] clk: sunxi: Add apb0 gates for A83T
In-Reply-To: <1454203266-4450-3-git-send-email-vishnupatekar0510@gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-3-git-send-email-vishnupatekar0510@gmail.com>
Message-ID: <20160201150218.GA4290@rob-hp-laptop>

On Sun, Jan 31, 2016 at 09:20:54AM +0800, Vishnu Patekar wrote:
> APB0 is part of PRCM, and is compatible with earlier SOCs.
> apb0 gates controls R_PIO, R_UART, R_RSB, etc clocks.
> This patch adds support for APB0 gates for A83T.
> 
> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
>  drivers/clk/sunxi/clk-simple-gates.c              | 2 ++
>  2 files changed, 3 insertions(+)

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Mon Feb  1 07:03:44 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 09:03:44 -0600
Subject: [PATCH 03/14] clk: sunxi: add bus gates for A83T
In-Reply-To: <1454203266-4450-4-git-send-email-vishnupatekar0510@gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-4-git-send-email-vishnupatekar0510@gmail.com>
Message-ID: <20160201150344.GA4947@rob-hp-laptop>

On Sun, Jan 31, 2016 at 09:20:55AM +0800, Vishnu Patekar wrote:
> A83T has similar bus gates that of H3, including single gating register has
> different clock parent.
> 
> As per H3 and A83T datasheet, usbhost is under AHB2.
> 
> However,below shows allwinner source code assignment:
> bits: 26 (ehci0), 27 (ehci1), 29 (ohci0) => AHB1 for A83T.
> bits: 26 (ehci0), 27 (ehci1) => AHB1 for H3
> bits  29, 30, 31(ohci0,1,2) => AHB2 for H3.
> 
> until, this confusion is cleared keep it H3 way.
> 
> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
>  drivers/clk/sunxi/clk-sun8i-bus-gates.c           | 2 ++
>  2 files changed, 3 insertions(+)

Acked-by: Rob Herring <robh at kernel.org>


From catalin.marinas at arm.com  Mon Feb  1 07:06:24 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 1 Feb 2016 15:06:24 +0000
Subject: [PATCH v5sub1 8/8] arm64: allow kernel Image to be loaded
 anywhere in physical memory
In-Reply-To: <1454324093-15998-9-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-9-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160201150624.GG15514@e104818-lin.cambridge.arm.com>

On Mon, Feb 01, 2016 at 11:54:53AM +0100, Ard Biesheuvel wrote:
> Note that limiting memory using mem= is not unambiguous anymore after
> this change, considering that the kernel may be at the top of physical
> memory, and clipping from the bottom rather than the top will discard
> any 32-bit DMA addressable memory first. To deal with this, the handling
> of mem= is reimplemented to clip top down, but take special care not to
> clip memory that covers the kernel image.

I may have forgotten the reason - why do we need to avoid clipping the
memory that covers the kernel image? It's already mapped in the vmalloc
area, so we wouldn't need it in the linear map as well.

-- 
Catalin


From ezequiel at vanguardiasur.com.ar  Mon Feb  1 07:09:56 2016
From: ezequiel at vanguardiasur.com.ar (Ezequiel Garcia)
Date: Mon, 1 Feb 2016 12:09:56 -0300
Subject: [PATCH 1/2] clocksource/drivers/lpc32xx: Support periodic mode
In-Reply-To: <CAAEAJfAVTJm-PzhjkRmkdNG39sH7eHyEXaSX4q0=TCQ0468Heg@mail.gmail.com>
References: <1454136379-7517-1-git-send-email-ezequiel@vanguardiasur.com.ar>
 <CAGhQ9VxO7Rsus8Js_oZDBxWzEHuUHnRyoVTVmawbtXmK7tNMcw@mail.gmail.com>
 <CAAEAJfAVTJm-PzhjkRmkdNG39sH7eHyEXaSX4q0=TCQ0468Heg@mail.gmail.com>
Message-ID: <CAAEAJfD8LUV=t97RN3U4uqgzCLP89AQtHqBccKGd6-EskP9DOQ@mail.gmail.com>

On 31 January 2016 at 17:07, Ezequiel Garcia
<ezequiel at vanguardiasur.com.ar> wrote:
> On 30 January 2016 at 16:39, Joachim  Eastwood <manabian at gmail.com> wrote:
>> Hi Ezequiel,
>>
>> On 30 January 2016 at 07:46, Ezequiel Garcia
>> <ezequiel at vanguardiasur.com.ar> wrote:
>>> This commit adds the support for periodic mode. This is done by not
>>> setting the MR0S (Stop on TnMR0) bit on MCR, thus allowing
>>> interrupts to be periodically generated on MR0 matches.
>>>
>>> In order to do this, move the initial configuration that is specific to
>>> the one shot mode to clock_event_device.set_state_oneshot.
>>>
[...]
>
>>
>> I will look more closely at the new timer setup later.
>>
>> btw, didn't I look through a version of this you sent me privately
>> quite some time ago?
>> I think I had a comment about using TIMER_PR instead of TIMER_MR0
>> then. Unsure if that is still valid, though.
>>
>
> Ah, right. It was ages ago, and forgot your previous review. Sorry about that.
> Using TIMER_PR looks less invasive so I'll send a v2 using it instead.

Actually, using the prescale counter and MR0 = 1 resulted in exactly
half the number of interrupts that I expected (HZ / 2). Using this
patch, with PR=0 and MR0=ticks_per_jiggies, I can see HZ no. of
interrupts per sec.

Why did you choose to use the prescale in your oneshot implementation?
Did you test or measure the timer expire using the PR and MR0 = 1?

To be honest, I'm still trying to make some sense out of my results.
-- 
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar


From robh at kernel.org  Mon Feb  1 07:10:27 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 09:10:27 -0600
Subject: [PATCH v3 01/10] drm/hisilicon: Add device tree binding for
 hi6220 display subsystem
In-Reply-To: <1454144075-74361-2-git-send-email-xinliang.liu@linaro.org>
References: <1454144075-74361-1-git-send-email-xinliang.liu@linaro.org>
 <1454144075-74361-2-git-send-email-xinliang.liu@linaro.org>
Message-ID: <20160201151027.GA5888@rob-hp-laptop>

On Sat, Jan 30, 2016 at 04:54:26PM +0800, Xinliang Liu wrote:
> Add ADE display controller binding doc.
> Add DesignWare DSI Host Controller v1.20a binding doc.
> 
> Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
> 
> v3:
> - Make ade as the drm master node.
> - Use assigned-clocks to set clock rate.
> - Use ports to connect display relavant nodes.
> v2:
> - Move dt binding docs to bindings/display/hisilicon directory. 

Looks pretty good, just a few minor things.

> ---
>  .../bindings/display/hisilicon/dw-dsi.txt          | 60 ++++++++++++++++++++++
>  .../bindings/display/hisilicon/hisi-ade.txt        | 56 ++++++++++++++++++++
>  2 files changed, 116 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>  create mode 100644 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
> new file mode 100644
> index 000000000000..44b945a54f3f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
> @@ -0,0 +1,60 @@
> +Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
> +
> +A DSI Host Controller resides in the middle of display controller and external
> +HDMI converter.
> +
> +Required properties:
> +- compatible: value should be "hisilicon,hi6220-dsi".
> +- reg: physical base address and length of the controller's registers.
> +- clocks: the clocks needed.
> +- clock-names: the name of the clocks.
> +- ports: contains DSI controller input and output sub port. The input port
> +  connects to ADE output port, and output port connected to external HDMI

or panel or any other bridge.

> +  endpoint. See Documentation/devicetree/bindings/graph.txt for more device
> +  graph info.
> +
> +A example of HiKey board hi6220 SoC and board specific DT entry:
> +Example:
> +
> +SoC specific:
> +	dsi: dsi at 0xf4107800 {

Drop the '0x'

> +		compatible = "hisilicon,hi6220-dsi";
> +		reg = <0x0 0xf4107800 0x0 0x100>;
> +		clocks = <&media_ctrl  HI6220_DSI_PCLK>;
> +		clock-names = "pclk_dsi";
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port at 0 {
> +				reg = <0>;
> +				dsi_in: endpoint {
> +						remote-endpoint = <&ade_out>;

Indentation is wrong.

> +				};
> +			};
> +
> +			port at 1 {
> +				reg = <1>; /* 1 for output port */
> +				dsi_out: endpoint {
> +						 remote-endpoint = <&adv7533_in>;

ditto.

> +				};
> +			};
> +		};
> +	};
> +
> +Board specific:
> +	i2c2: i2c at f7102000 {
> +		...
> +
> +		adv7533: adv7533 at 39 {
> +			...
> +
> +			port {
> +				adv7533_in: endpoint {
> +					remote-endpoint = <&dsi_out>;
> +				};
> +			};
> +		};
> +	};
> +
> diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
> new file mode 100644
> index 000000000000..47925826536c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
> @@ -0,0 +1,56 @@
> +Device-Tree bindings for hisilicon ADE display controller driver
> +
> +ADE (Advanced Display Engine) is the display controller which grab image
> +data from memory, do composition, do post image processing, generate RGB
> +timing stream and transfer to DSI.
> +
> +Required properties:
> +- compatible: value should be "hisilicon,hi6220-ade".
> +- reg: physical base address and length of the controller's registers.

I see 3 ranges in the example. Please specify what each one is here.

> +- reg-names: name of physical base.
> +- interrupt: the interrupt number.
> +- clocks: the clocks needed.

Same here. Specify what the clocks are.

> +- clock-names: the name of the clocks.
> +- assigned-clocks: clocks to be assigned rate.
> +- assigned-clock-rates: clock rates which are assigned to assigned-clocks.
> +- port: the output port. This contains one endpoint subnode, with its
> +  remote-endpoint set to the phandle of the connected DSI endpoint.
> +  See Documentation/devicetree/bindings/graph.txt for more device graph info.
> +
> +Optional properties:
> +- dma-coherent: Present if dma operations are coherent.
> +
> +
> +A example of HiKey board hi6220 SoC specific DT entry:
> +Example:
> +
> +	ade: ade at f4100000 {
> +		compatible = "hisilicon,hi6220-ade";
> +		reg = <0x0 0xf4100000 0x0 0x7800>,
> +		      <0x0 0xf4410000 0x0 0x1000>,
> +		      <0x0 0xf4520000 0x0 0x1000>;
> +		reg-names = "ade_base",
> +			    "media_base",
> +			    "media_noc_base";
> +
> +		interrupts = <0 115 4>; /* ldi interrupt */
> +
> +		clocks = <&media_ctrl HI6220_ADE_CORE>,
> +			 <&media_ctrl HI6220_CODEC_JPEG>,
> +			 <&media_ctrl HI6220_ADE_PIX_SRC>;
> +		/*clock name*/
> +		clock-names  = "clk_ade_core",
> +			       "clk_codec_jpeg",
> +			       "clk_ade_pix";
> +
> +		assigned-clocks = <&media_ctrl HI6220_ADE_CORE>,
> +			<&media_ctrl HI6220_CODEC_JPEG>;
> +		assigned-clock-rates = <360000000>, <288000000>;
> +		dma-coherent;
> +
> +		port {
> +			ade_out: endpoint {
> +				remote-endpoint = <&dsi_in>;
> +			};
> +		};
> +	};
> -- 
> 1.9.1
> 


From wens at csie.org  Mon Feb  1 07:11:23 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 1 Feb 2016 23:11:23 +0800
Subject: [PATCH 02/14] clk: sunxi: Add apb0 gates for A83T
In-Reply-To: <20160201150218.GA4290@rob-hp-laptop>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-3-git-send-email-vishnupatekar0510@gmail.com>
 <20160201150218.GA4290@rob-hp-laptop>
Message-ID: <CAGb2v64VjfDVDMSO_ov0mJfXTbgB7ffehGu4N8tCTs8Kt00fRg@mail.gmail.com>

On Mon, Feb 1, 2016 at 11:02 PM, Rob Herring <robh at kernel.org> wrote:
> On Sun, Jan 31, 2016 at 09:20:54AM +0800, Vishnu Patekar wrote:
>> APB0 is part of PRCM, and is compatible with earlier SOCs.
>> apb0 gates controls R_PIO, R_UART, R_RSB, etc clocks.
>> This patch adds support for APB0 gates for A83T.
>>
>> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
>> ---
>>  Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
>>  drivers/clk/sunxi/clk-simple-gates.c              | 2 ++
>>  2 files changed, 3 insertions(+)
>
> Acked-by: Rob Herring <robh at kernel.org>

Acked-by: Chen-Yu Tsai <wens at csie.org>


From wens at csie.org  Mon Feb  1 07:13:10 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 1 Feb 2016 23:13:10 +0800
Subject: [PATCH 03/14] clk: sunxi: add bus gates for A83T
In-Reply-To: <20160201150344.GA4947@rob-hp-laptop>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-4-git-send-email-vishnupatekar0510@gmail.com>
 <20160201150344.GA4947@rob-hp-laptop>
Message-ID: <CAGb2v67BcLx8g+MDZnMyrgDpHWmQ-kcxFVqDNpMWzyJ_QoDrQA@mail.gmail.com>

On Mon, Feb 1, 2016 at 11:03 PM, Rob Herring <robh at kernel.org> wrote:
> On Sun, Jan 31, 2016 at 09:20:55AM +0800, Vishnu Patekar wrote:
>> A83T has similar bus gates that of H3, including single gating register has
>> different clock parent.
>>
>> As per H3 and A83T datasheet, usbhost is under AHB2.
>>
>> However,below shows allwinner source code assignment:
>> bits: 26 (ehci0), 27 (ehci1), 29 (ohci0) => AHB1 for A83T.
>> bits: 26 (ehci0), 27 (ehci1) => AHB1 for H3
>> bits  29, 30, 31(ohci0,1,2) => AHB2 for H3.
>>
>> until, this confusion is cleared keep it H3 way.
>>
>> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
>> ---
>>  Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
>>  drivers/clk/sunxi/clk-sun8i-bus-gates.c           | 2 ++
>>  2 files changed, 3 insertions(+)
>
> Acked-by: Rob Herring <robh at kernel.org>

Acked-by: Chen-Yu Tsai <wens at csie.org>

We should really get the clk parents sorted out though.


From ard.biesheuvel at linaro.org  Mon Feb  1 07:13:52 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 1 Feb 2016 16:13:52 +0100
Subject: [PATCH v5sub1 8/8] arm64: allow kernel Image to be loaded
 anywhere in physical memory
In-Reply-To: <20160201150624.GG15514@e104818-lin.cambridge.arm.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-9-git-send-email-ard.biesheuvel@linaro.org>
 <20160201150624.GG15514@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu8rgkBWfJXfWzWSkxyKhLOnxirycu-wdcmvRovpDB5hKw@mail.gmail.com>

On 1 February 2016 at 16:06, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 01, 2016 at 11:54:53AM +0100, Ard Biesheuvel wrote:
>> Note that limiting memory using mem= is not unambiguous anymore after
>> this change, considering that the kernel may be at the top of physical
>> memory, and clipping from the bottom rather than the top will discard
>> any 32-bit DMA addressable memory first. To deal with this, the handling
>> of mem= is reimplemented to clip top down, but take special care not to
>> clip memory that covers the kernel image.
>
> I may have forgotten the reason - why do we need to avoid clipping the
> memory that covers the kernel image? It's already mapped in the vmalloc
> area, so we wouldn't need it in the linear map as well.
>

Good question. Originally, I needed it for swapper_pg_dir, whose
pud/pmd/pte levels were accessed via __va() translations of the values
found in the higher-up table entries, but after Mark's patches, only
the top level pgd of swapper_pg_dir is still used. Similarly, for
idmap_pg_dir, we don't change any mappings at runtime so the same
applies there I think.

I will try dropping this, and see what happens.

-- 
Ard.


From robh at kernel.org  Mon Feb  1 07:14:56 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 09:14:56 -0600
Subject: [PATCH V13 08/10] dma: qcom_hidma: read the channel id from HW
In-Reply-To: <1454106914-15857-9-git-send-email-okaya@codeaurora.org>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-9-git-send-email-okaya@codeaurora.org>
Message-ID: <20160201151455.GA10961@rob-hp-laptop>

On Fri, Jan 29, 2016 at 05:35:11PM -0500, Sinan Kaya wrote:
> Removing the flexibility to choose the event channel as there is no real
> use case right now. We have been using the values in ACPI that match the HW
> defaults. OS is reading the event-channel from the HW register now.
> 
> Signed-off-by: Sinan Kaya <okaya at codeaurora.org>
> ---
>  .../devicetree/bindings/dma/qcom_hidma_mgmt.txt    |  3 --
>  drivers/dma/qcom/hidma.c                           | 39 +---------------------
>  2 files changed, 1 insertion(+), 41 deletions(-)

Acked-by: Rob Herring <robh at kernel.org>


From linux at arm.linux.org.uk  Mon Feb  1 07:20:15 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 1 Feb 2016 15:20:15 +0000
Subject: [PATCH 1/2] ARM: make virt_to_idmap() return unsigned long
In-Reply-To: <56A84748.3040108@oracle.com>
References: <E1aO8F2-00074N-E8@rmk-PC.arm.linux.org.uk>
 <56A84748.3040108@oracle.com>
Message-ID: <20160201152015.GU10826@n2100.arm.linux.org.uk>

On Tue, Jan 26, 2016 at 08:27:52PM -0800, santosh.shilimkar at oracle.com wrote:
> On 1/26/16 10:21 AM, Russell King wrote:
> >Make virt_to_idmap() return an unsigned long rather than phys_addr_t.
> >
> >Returning phys_addr_t here makes no sense, because the definition of
> >virt_to_idmap() is that it shall return a physical address which maps
> >identically with the virtual address.  Since virtual addresses are
> >limited to 32-bit, identity mapped physical addresses are as well.
> >
> >Almost all users already had an implicit narrowing cast to unsigned long
> >so let's make this official and part of this interface.
> >
> >Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
> >---
> Looks correct to me.
> 
> Vitaly,
> Could you please try out this patch and see everything continue to
> work ?

I haven't heard anything yet...  Vitaly?

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From christoffer.dall at linaro.org  Mon Feb  1 07:21:22 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 16:21:22 +0100
Subject: [PATCH v2 19/21] arm64: KVM: Move most of the fault decoding to C
In-Reply-To: <1453737235-16522-20-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-20-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201152122.GY1478@cbox>

On Mon, Jan 25, 2016 at 03:53:53PM +0000, Marc Zyngier wrote:
> The fault decoding process (including computing the IPA in the case
> of a permission fault) would be much better done in C code, as we
> have a reasonable infrastructure to deal with the VHE/non-VHE
> differences.
> 
> Let's move the whole thing to C, including the workaround for
> erratum 834220, and just patch the odd ESR_EL2 access remaining
> in hyp-entry.S.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kernel/asm-offsets.c |  3 --
>  arch/arm64/kvm/hyp/hyp-entry.S  | 69 +++--------------------------------------
>  arch/arm64/kvm/hyp/switch.c     | 54 ++++++++++++++++++++++++++++++++
>  3 files changed, 59 insertions(+), 67 deletions(-)
> 
> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> index fffa4ac6..b0ab4e9 100644
> --- a/arch/arm64/kernel/asm-offsets.c
> +++ b/arch/arm64/kernel/asm-offsets.c
> @@ -110,9 +110,6 @@ int main(void)
>    DEFINE(CPU_USER_PT_REGS,	offsetof(struct kvm_regs, regs));
>    DEFINE(CPU_FP_REGS,		offsetof(struct kvm_regs, fp_regs));
>    DEFINE(VCPU_FPEXC32_EL2,	offsetof(struct kvm_vcpu, arch.ctxt.sys_regs[FPEXC32_EL2]));
> -  DEFINE(VCPU_ESR_EL2,		offsetof(struct kvm_vcpu, arch.fault.esr_el2));
> -  DEFINE(VCPU_FAR_EL2,		offsetof(struct kvm_vcpu, arch.fault.far_el2));
> -  DEFINE(VCPU_HPFAR_EL2,	offsetof(struct kvm_vcpu, arch.fault.hpfar_el2));
>    DEFINE(VCPU_HOST_CONTEXT,	offsetof(struct kvm_vcpu, arch.host_cpu_context));
>  #endif
>  #ifdef CONFIG_CPU_PM
> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
> index 9e0683f..213de52 100644
> --- a/arch/arm64/kvm/hyp/hyp-entry.S
> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
> @@ -19,7 +19,6 @@
>  
>  #include <asm/alternative.h>
>  #include <asm/assembler.h>
> -#include <asm/asm-offsets.h>
>  #include <asm/cpufeature.h>
>  #include <asm/kvm_arm.h>
>  #include <asm/kvm_asm.h>
> @@ -67,7 +66,11 @@ ENDPROC(__vhe_hyp_call)
>  el1_sync:				// Guest trapped into EL2
>  	save_x0_to_x3
>  
> +alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
>  	mrs	x1, esr_el2
> +alternative_else
> +	mrs	x1, esr_el1
> +alternative_endif

I suppose this is not technically part of what the patch description
says it does, but ok...

>  	lsr	x2, x1, #ESR_ELx_EC_SHIFT
>  
>  	cmp	x2, #ESR_ELx_EC_HVC64
> @@ -103,72 +106,10 @@ el1_trap:
>  	cmp	x2, #ESR_ELx_EC_FP_ASIMD
>  	b.eq	__fpsimd_guest_restore
>  
> -	cmp	x2, #ESR_ELx_EC_DABT_LOW
> -	mov	x0, #ESR_ELx_EC_IABT_LOW
> -	ccmp	x2, x0, #4, ne
> -	b.ne	1f		// Not an abort we care about
> -
> -	/* This is an abort. Check for permission fault */
> -alternative_if_not ARM64_WORKAROUND_834220
> -	and	x2, x1, #ESR_ELx_FSC_TYPE
> -	cmp	x2, #FSC_PERM
> -	b.ne	1f		// Not a permission fault
> -alternative_else
> -	nop			// Use the permission fault path to
> -	nop			// check for a valid S1 translation,
> -	nop			// regardless of the ESR value.
> -alternative_endif
> -
> -	/*
> -	 * Check for Stage-1 page table walk, which is guaranteed
> -	 * to give a valid HPFAR_EL2.
> -	 */
> -	tbnz	x1, #7, 1f	// S1PTW is set
> -
> -	/* Preserve PAR_EL1 */
> -	mrs	x3, par_el1
> -	stp	x3, xzr, [sp, #-16]!
> -
> -	/*
> -	 * Permission fault, HPFAR_EL2 is invalid.
> -	 * Resolve the IPA the hard way using the guest VA.
> -	 * Stage-1 translation already validated the memory access rights.
> -	 * As such, we can use the EL1 translation regime, and don't have
> -	 * to distinguish between EL0 and EL1 access.
> -	 */
> -	mrs	x2, far_el2
> -	at	s1e1r, x2
> -	isb
> -
> -	/* Read result */
> -	mrs	x3, par_el1
> -	ldp	x0, xzr, [sp], #16	// Restore PAR_EL1 from the stack
> -	msr	par_el1, x0
> -	tbnz	x3, #0, 3f		// Bail out if we failed the translation
> -	ubfx	x3, x3, #12, #36	// Extract IPA
> -	lsl	x3, x3, #4		// and present it like HPFAR
> -	b	2f
> -
> -1:	mrs	x3, hpfar_el2
> -	mrs	x2, far_el2
> -
> -2:	mrs	x0, tpidr_el2
> -	str	w1, [x0, #VCPU_ESR_EL2]
> -	str	x2, [x0, #VCPU_FAR_EL2]
> -	str	x3, [x0, #VCPU_HPFAR_EL2]
> -
> +	mrs	x0, tpidr_el2
>  	mov	x1, #ARM_EXCEPTION_TRAP
>  	b	__guest_exit
>  
> -	/*
> -	 * Translation failed. Just return to the guest and
> -	 * let it fault again. Another CPU is probably playing
> -	 * behind our back.
> -	 */
> -3:	restore_x0_to_x3
> -
> -	eret
> -
>  el1_irq:
>  	save_x0_to_x3
>  	mrs	x0, tpidr_el2
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 0cadb7f..df2cce9 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -15,6 +15,7 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <linux/types.h>
>  #include <asm/kvm_asm.h>
>  
>  #include "hyp.h"
> @@ -150,6 +151,55 @@ static void __hyp_text __vgic_restore_state(struct kvm_vcpu *vcpu)
>  	__vgic_call_restore_state()(vcpu);
>  }
>  
> +static hyp_alternate_value(__check_arm_834220,
> +			   false, true,
> +			   ARM64_WORKAROUND_834220);
> +
> +static bool __hyp_text __populate_fault_info(struct kvm_vcpu *vcpu)
> +{
> +	u64 esr = read_sysreg_el2(esr);
> +	u8 ec = esr >> ESR_ELx_EC_SHIFT;
> +	u64 hpfar, far;
> +
> +	vcpu->arch.fault.esr_el2 = esr;
> +
> +	if (ec != ESR_ELx_EC_DABT_LOW && ec != ESR_ELx_EC_IABT_LOW)
> +		return true;
> +
> +	far = read_sysreg_el2(far);
> +
> +	if (!(esr & ESR_ELx_S1PTW) &&
> +	    (__check_arm_834220() || (esr & ESR_ELx_FSC_TYPE) == FSC_PERM)) {

this is really hard to read.  How do you feel about putting the below
block into its own function and changing to something like this:

/*
 * The HPFAR can be invalid if the stage 2 fault did not happen during a
 * stage 1 page table walk (the ESR_EL2.S1PTW bit is clear) and one of
 * the two following cases are true:
 *   1. The fault was due to a permission fault
 *   2. The processor carries errata 834220
 *
 * Therefore, for all non S1PTW faults where we either have a permission
 * fault or the errata workaround is enabled, we resolve the IPA using
 * the AT instruction.
 */
if (!(esr & ESR_ELx_S1PTW) &&
    (__check_arm_834220() || (esr & ESR_ELx_FSC_TYPE) == FSC_PERM)) {
    	if (!__translate_far_to_ipa(&hpfar))
		return false; /* Translation failed, back to guest */
} else {
	hpfar = read_sysreg(hpfar_el2);
}

not sure if it helps that much, perhaps it's just complicated by nature.

> +		u64 par, tmp;
> +
> +		/*
> +		 * Permission fault, HPFAR_EL2 is invalid. Resolve the
> +		 * IPA the hard way using the guest VA.
> +		 * Stage-1 translation already validated the memory
> +		 * access rights. As such, we can use the EL1
> +		 * translation regime, and don't have to distinguish
> +		 * between EL0 and EL1 access.
> +		 */
> +		par = read_sysreg(par_el1);

in any cas I think we also need the comment about preserving par_el1
here, which is only something we do because we may return early, IIUC.

> +		asm volatile("at s1e1r, %0" : : "r" (far));
> +		isb();
> +
> +		tmp = read_sysreg(par_el1);
> +		write_sysreg(par, par_el1);
> +
> +		if (unlikely(tmp & 1))
> +			return false; /* Translation failed, back to guest */
> +

nit: add comment /* Convert PAR to HPFAR format */

> +		hpfar = ((tmp >> 12) & ((1UL << 36) - 1)) << 4;
> +	} else {
> +		hpfar = read_sysreg(hpfar_el2);
> +	}
> +
> +	vcpu->arch.fault.far_el2 = far;
> +	vcpu->arch.fault.hpfar_el2 = hpfar;
> +	return true;
> +}
> +
>  static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
>  {
>  	struct kvm_cpu_context *host_ctxt;
> @@ -181,9 +231,13 @@ static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
>  	__debug_restore_state(vcpu, kern_hyp_va(vcpu->arch.debug_ptr), guest_ctxt);
>  
>  	/* Jump in the fire! */
> +again:
>  	exit_code = __guest_enter(vcpu, host_ctxt);
>  	/* And we're baaack! */
>  
> +	if (exit_code == ARM_EXCEPTION_TRAP && !__populate_fault_info(vcpu))
> +		goto again;
> +
>  	fp_enabled = __fpsimd_enabled();
>  
>  	__sysreg_save_guest_state(guest_ctxt);
> -- 
> 2.1.4
> 
The good news are that I couldn't find any bugs in the code.

-Christoffer


From leo.yan at linaro.org  Mon Feb  1 07:23:33 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 1 Feb 2016 23:23:33 +0800
Subject: [PATCH v5 1/4] dt-bindings: mailbox: Document Hi6220 mailbox
 driver
In-Reply-To: <20160201140828.GA32412@rob-hp-laptop>
References: <1454333687-20421-1-git-send-email-leo.yan@linaro.org>
 <1454333687-20421-2-git-send-email-leo.yan@linaro.org>
 <20160201140828.GA32412@rob-hp-laptop>
Message-ID: <20160201152333.GA22872@leoy-linaro>

Hi Rob,

Thanks for reviewing, please see below inline comments.

On Mon, Feb 01, 2016 at 08:08:28AM -0600, Rob Herring wrote:
> On Mon, Feb 01, 2016 at 09:34:44PM +0800, Leo Yan wrote:
> > Document DT binding for Hisilicon Hi6220 mailbox driver.
> > 
> > Signed-off-by: Leo Yan <leo.yan at linaro.org>
> > ---
> >  .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  | 90 ++++++++++++++++++++++
> >  1 file changed, 90 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
> > new file mode 100644
> > index 0000000..96e6acc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
> > @@ -0,0 +1,90 @@
> > +Hisilicon Hi6220 Mailbox Driver
> > +===============================
> > +
> > +Hisilicon Hi6220 mailbox supports up to 32 channels. Each channel
> > +is unidirectional with a maximum message size of 8 words. I/O is
> > +performed using register access (there is no DMA) and the cell
> > +raises an interrupt when messages are received.
> > +
> > +Mailbox Device Node:
> > +====================
> > +
> > +Required properties:
> > +--------------------
> > +- compatible:		Shall be "hisilicon,hi6220-mbox"
> > +- reg:			Contains the mailbox register address range (base
> > +			address and length); the first item is for IPC
> > +			registers, the second item is shared buffer for
> > +			slots.
> > +- #mbox-cells		Common mailbox binding property to identify the number
> > +			of cells required for the mailbox specifier. Should be 1.
> > +- interrupts:		Contains the interrupt information for the mailbox
> > +			device. The format is dependent on which interrupt
> > +			controller the SoCs use.
> > +
> > +Optional Properties:
> > +--------------------
> > +- hi6220,mbox-tx-noirq: Flag to allow the client user of this mailbox driver
> > +			to send messages without triggering a TX completion
> > +			interrupt.
> 
> I don't think this belongs in DT. This should be a flag the client 
> driver sets when it sends messages.

The client driver can set "tx_block = true" so use this flag indicates
the client thread should be blocked until data is transmitted.

But low level mailbox driver can use two method to support "tx_block"
mode:
- One method is to avoid using interrupt and mailbox framework will
  poll with mailbox's idle flag which is set by remote processor
  automatically;
- Another method is to use interrupt to notify data has been
  transmitted and interrupt handler will call completion function to
  wake up blocked client thread;

So this flag is to distinguish these two different hardware mechanism.
Do you think this is make sense or have other suggestion?

> > +
> > +Child Nodes:
> > +============
> > +A child node is used for representing the actual sub-mailbox device that is
> > +used for the communication between the host processor and a remote processor.
> > +Each child node should have a unique node name across all the different
> > +mailbox device nodes.
> > +
> > +Required properties:
> > +--------------------
> > +- hi6220,mbox-tx:	sub-mailbox descriptor property defining Tx channel
> > +- hi6220,mbox-rx:	sub-mailbox descriptor property defining Rx channel
> > +
> > +Sub-mailbox Descriptor Data
> > +---------------------------
> > +Each of the above hi6220,mbox-tx and hi6220,mbox-rx properties should have 3
> > +cells of data that represent the following:
> > +    Cell #1 (slot_id) - mailbox slot id used either for transmitting
> > +                        (hi6220,mbox-tx) or for receiving (hi6220,mbox-rx)
> > +    Cell #2 (dst_irq) - irq identifier index number which used by MCU.
> > +    Cell #3 (ack_irq) - irq identifier index number with generating a tx/rx
> > +                        interrupt to application processor, mailbox driver
> > +                        used this id to acknowledge interrupt.
> > +
> > +Example:
> > +--------
> > +
> > +	mailbox: mailbox at F7510000 {
> > +		#mbox-cells = <1>;
> > +		compatible = "hisilicon,hi6220-mbox";
> > +		reg = <0x0 0xF7510000 0x0 0x1000>, /* IPC_S */
> > +		      <0x0 0x06DFF800 0x0 0x0800>; /* Mailbox */
> > +		interrupt-parent = <&gic>;
> > +		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
> > +		mbox_stub_clock: mbox_stub_clock {
> > +			hi6220,mbox-rx = <0 1 10>;
> > +			hi6220,mbox-tx = <1 0 11>;
> > +		};
> > +	};
> > +
> > +
> > +Mailbox client
> > +===============
> > +
> > +"mboxes" and the optional "mbox-names" (please see
> > +Documentation/devicetree/bindings/mailbox/mailbox.txt for details). Each value
> > +of the mboxes property should contain a phandle to the mailbox controller
> > +device node and second argument is the channel index. It must be 0 (hardware
> 
> 0? But the example has 1.

Will fix.

Thanks,
Leo Yan

> > +support only one channel). The equivalent "mbox-names" property value can be
> > +used to give a name to the communication channel to be used by the client user.
> > +
> > +Example:
> > +--------
> > +
> > +	stub_clock: stub_clock {
> > +		compatible = "hisilicon,hi6220-stub-clk";
> > +		hisilicon,hi6220-clk-sram = <&sram>;
> > +		#clock-cells = <1>;
> > +		mbox-names = "mbox-tx";
> > +		mboxes = <&mailbox 1>;
> > +	};
> > -- 
> > 1.9.1
> > 


From christoffer.dall at linaro.org  Mon Feb  1 07:26:12 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 16:26:12 +0100
Subject: [PATCH v2 20/21] arm64: VHE: Add support for running Linux in
 EL2 mode
In-Reply-To: <1453737235-16522-21-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-21-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201152612.GZ1478@cbox>

On Mon, Jan 25, 2016 at 03:53:54PM +0000, Marc Zyngier wrote:
> With ARMv8.1 VHE, the architecture is able to (almost) transparently
> run the kernel at EL2, despite being written for EL1.
> 
> This patch takes care of the "almost" part, mostly preventing the kernel
> from dropping from EL2 to EL1, and setting up the HYP configuration.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/Kconfig       | 13 +++++++++++++
>  arch/arm64/kernel/head.S | 32 +++++++++++++++++++++++++++++++-
>  2 files changed, 44 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 8cc6228..ada34df 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -750,6 +750,19 @@ config ARM64_LSE_ATOMICS
>  	  not support these instructions and requires the kernel to be
>  	  built with binutils >= 2.25.
>  
> +config ARM64_VHE
> +	bool "Enable support for Virtualization Host Extension (VHE)"

Extensions (plural)

> +	default y
> +	help
> +	  Virtualization Host Extension (VHE) allows the kernel to run

same

> +	  directly at EL2 (instead of EL1) on processors that support
> +	  it. This leads to better performance for KVM, as it reduces

s/it/them/ then?

> +	  the cost of the world switch.
> +
> +	  Selecting this option allows the VHE feature to be detected
> +	  at runtime, and does not affect processors that do not
> +	  implement this feature.
> +
>  endmenu
>  
>  endmenu
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index ffe9c2b..2a7134c 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -30,6 +30,7 @@
>  #include <asm/cache.h>
>  #include <asm/cputype.h>
>  #include <asm/kernel-pgtable.h>
> +#include <asm/kvm_mmu.h>
>  #include <asm/memory.h>
>  #include <asm/pgtable-hwdef.h>
>  #include <asm/pgtable.h>
> @@ -464,8 +465,25 @@ CPU_LE(	bic	x0, x0, #(3 << 24)	)	// Clear the EE and E0E bits for EL1
>  	isb
>  	ret
>  
> +2:
> +#ifdef CONFIG_ARM64_VHE
> +	/*
> +	 * Check for VHE being present. For the rest of the EL2 setup,
> +	 * x2 being non-zero indicates that we do have VHE, and that the
> +	 * kernel is intended to run at EL2.
> +	 */
> +	mrs	x2, id_aa64mmfr1_el1
> +	ubfx	x2, x2, #8, #4
> +#else
> +	mov	x2, xzr
> +#endif
> +
>  	/* Hyp configuration. */
> -2:	mov	x0, #(1 << 31)			// 64-bit EL1
> +	mov	x0, #HCR_RW			// 64-bit EL1
> +	cbz	x2, set_hcr
> +	orr	x0, x0, #HCR_TGE		// Enable Host Extensions
> +	orr	x0, x0, #HCR_E2H
> +set_hcr:
>  	msr	hcr_el2, x0
>  
>  	/* Generic timers. */
> @@ -507,6 +525,9 @@ CPU_LE(	movk	x0, #0x30d0, lsl #16	)	// Clear EE and E0E on LE systems
>  
>  	/* Coprocessor traps. */
>  	mov	x0, #0x33ff
> +	cbz	x2, set_cptr
> +	orr	x0, x0, #(3 << 20)		// Don't trap FP

nit: If you make that define we discussed earlier you can use it here too

> +set_cptr:
>  	msr	cptr_el2, x0			// Disable copro. traps to EL2
>  
>  #ifdef CONFIG_COMPAT
> @@ -521,6 +542,15 @@ CPU_LE(	movk	x0, #0x30d0, lsl #16	)	// Clear EE and E0E on LE systems
>  	/* Stage-2 translation */
>  	msr	vttbr_el2, xzr
>  
> +	cbz	x2, install_el2_stub
> +
> +	setup_vtcr x4, x5
> +
> +	mov	w20, #BOOT_CPU_MODE_EL2		// This CPU booted in EL2
> +	isb
> +	ret
> +
> +install_el2_stub:
>  	/* Hypervisor stub */
>  	adrp	x0, __hyp_stub_vectors
>  	add	x0, x0, #:lo12:__hyp_stub_vectors
> -- 
> 2.1.4
> 

Otherwise:

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From robh at kernel.org  Mon Feb  1 07:35:02 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 09:35:02 -0600
Subject: [PATCH v5 2/3] Documentation: gpio: Update description for
 X-Gene standby GPIO controller DTS binding
In-Reply-To: <1454041735-8434-3-git-send-email-qnguyen@apm.com>
References: <1454041735-8434-1-git-send-email-qnguyen@apm.com>
 <1454041735-8434-3-git-send-email-qnguyen@apm.com>
Message-ID: <20160201153502.GA19725@rob-hp-laptop>

On Fri, Jan 29, 2016 at 11:28:54AM +0700, Quan Nguyen wrote:
> Update description for X-Gene standby GPIO controller DTS binding to
> support GPIO line configuration as input, output or external IRQ pin.
> 
> Signed-off-by: Y Vo <yvo at apm.com>
> Signed-off-by: Quan Nguyen <qnguyen at apm.com>
> ---
>  .../devicetree/bindings/gpio/gpio-xgene-sb.txt     | 47 ++++++++++++++++++----
>  1 file changed, 40 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
> index dae1300..7b8b4cb 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
> @@ -1,10 +1,20 @@
>  APM X-Gene Standby GPIO controller bindings
>  
> -This is a gpio controller in the standby domain.
> -
> -There are 20 GPIO pins from 0..21. There is no GPIO_DS14 or GPIO_DS15,
> -only GPIO_DS8..GPIO_DS13 support interrupts. The IRQ mapping
> -is currently 1-to-1 on interrupts 0x28 thru 0x2d.
> +This is a gpio controller in the standby domain. It also supports interrupt in
> +some particular pins which are sourced to its parent interrupt controller
> +as diagram below:
> +                           +-----------------+
> +                           | X-Gene standby  |
> +                           | GPIO controller +--------- GPIO_0
> ++------------+             |                 | ...
> +| Parent IRQ |             |                 +--------- GPIO_8/EXT_INT_0
> +| controller |  EXT_INT_0  |                 | ...
> +| (GICv2)    +-------------+                 +--------- GPIO_[N+8]/EXT_INT_N
> +|            |  ...        |                 |
> +|            |  EXT_INT_N  |                 +--------- GPIO_[N+9]
> +|            +-------------+                 | ...
> +|            |             |                 +--------- GPIO_MAX
> ++------------+             +-----------------+
>  
>  Required properties:
>  - compatible: "apm,xgene-gpio-sb" for the X-Gene Standby GPIO controller
> @@ -15,10 +25,18 @@ Required properties:
>  		0 = active high
>  		1 = active low
>  - gpio-controller: Marks the device node as a GPIO controller.
> -- interrupts: Shall contain exactly 6 interrupts.
> +- interrupts: The EXT_INT_0 parent interrupt resource must be listed first.
> +- interrupt-parent: Phandle of the parent interrupt controller.
> +- interrupt-cells: Should be two.
> +       - first cell is 0-N coresponding for EXT_INT_0 to EXT_INT_N.
> +       - second cell is used to specify flags.
> +- interrupt-controller: Marks the device node as an interrupt controller.
> +- apm,nr-gpios: Optional, specify number of gpios pin.
> +- apm,nr-irqs: Optional, specify number of interrupt pins.

When is this not 6?

> +- apm,irq-start: Optional, specify lowest gpio pin support interrupt.

What determines this value? What value is assumed if not present?

Rob


From christoffer.dall at linaro.org  Mon Feb  1 07:36:05 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 16:36:05 +0100
Subject: [PATCH v2 21/21] arm64: Panic when VHE and non VHE CPUs coexist
In-Reply-To: <1453737235-16522-22-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-22-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201153605.GA1478@cbox>

On Mon, Jan 25, 2016 at 03:53:55PM +0000, Marc Zyngier wrote:
> Having both VHE and non-VHE capable CPUs in the same system
> is likely to be a recipe for disaster.
> 
> If the boot CPU has VHE, but a secondary is not, we won't be
> able to downgrade and run the kernel at EL1. Add CPU hotplug
> to the mix, and this produces a terrifying mess.
> 
> Let's solve the problem once and for all. If you mix VHE and
> non-VHE CPUs in the same system, you deserve to loose, and this
> patch makes sure you don't get a chance.
> 
> This is implemented by storing the kernel execution level in
> a global variable. Secondaries will park themselves in a
> WFI loop if they observe a mismatch. Also, the primary CPU
> will detect that the secondary CPU has died on a mismatched
> execution level. Panic will follow.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/virt.h | 17 +++++++++++++++++
>  arch/arm64/kernel/head.S      | 19 +++++++++++++++++++
>  arch/arm64/kernel/smp.c       |  3 +++
>  3 files changed, 39 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
> index 9f22dd6..f81a345 100644
> --- a/arch/arm64/include/asm/virt.h
> +++ b/arch/arm64/include/asm/virt.h
> @@ -36,6 +36,11 @@
>   */
>  extern u32 __boot_cpu_mode[2];
>  
> +/*
> + * __run_cpu_mode records the mode the boot CPU uses for the kernel.
> + */
> +extern u32 __run_cpu_mode[2];
> +
>  void __hyp_set_vectors(phys_addr_t phys_vector_base);
>  phys_addr_t __hyp_get_vectors(void);
>  
> @@ -60,6 +65,18 @@ static inline bool is_kernel_in_hyp_mode(void)
>  	return el == CurrentEL_EL2;
>  }
>  
> +static inline bool is_kernel_mode_mismatched(void)
> +{
> +	/*
> +	 * A mismatched CPU will have written its own CurrentEL in
> +	 * __run_cpu_mode[1] (initially set to zero) after failing to
> +	 * match the value in __run_cpu_mode[0]. Thus, a non-zero
> +	 * value in __run_cpu_mode[1] is enough to detect the
> +	 * pathological case.
> +	 */
> +	return !!ACCESS_ONCE(__run_cpu_mode[1]);
> +}
> +
>  /* The section containing the hypervisor text */
>  extern char __hyp_text_start[];
>  extern char __hyp_text_end[];
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 2a7134c..bc44cf8 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -577,7 +577,23 @@ ENTRY(set_cpu_boot_mode_flag)
>  1:	str	w20, [x1]			// This CPU has booted in EL1
>  	dmb	sy
>  	dc	ivac, x1			// Invalidate potentially stale cache line
> +	adr_l	x1, __run_cpu_mode
> +	ldr	w0, [x1]
> +	mrs	x20, CurrentEL
> +	cbz	x0, skip_el_check
> +	cmp	x0, x20
> +	bne	mismatched_el

can't you do a ret here instead of writing the same value and flushing
caches etc.?

> +skip_el_check:			// Only the first CPU gets to set the rule
> +	str	w20, [x1]
> +	dmb	sy
> +	dc	ivac, x1	// Invalidate potentially stale cache line
>  	ret
> +mismatched_el:
> +	str	w20, [x1, #4]
> +	dmb	sy
> +	dc	ivac, x1	// Invalidate potentially stale cache line
> +1:	wfi

I'm no expert on SMP bringup, but doesn't this prevent the CPU from
signaling completion and thus you'll never actually reach the checking
code in __cpu_up?

Thanks,
-Christoffer

> +	b	1b
>  ENDPROC(set_cpu_boot_mode_flag)
>  
>  /*
> @@ -592,6 +608,9 @@ ENDPROC(set_cpu_boot_mode_flag)
>  ENTRY(__boot_cpu_mode)
>  	.long	BOOT_CPU_MODE_EL2
>  	.long	BOOT_CPU_MODE_EL1
> +ENTRY(__run_cpu_mode)
> +	.long	0
> +	.long	0
>  	.popsection
>  
>  	/*
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index b1adc51..bc7650a 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -113,6 +113,9 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
>  			pr_crit("CPU%u: failed to come online\n", cpu);
>  			ret = -EIO;
>  		}
> +
> +		if (is_kernel_mode_mismatched())
> +			panic("CPU%u: incompatible execution level", cpu);
>  	} else {
>  		pr_err("CPU%u: failed to boot: %d\n", cpu, ret);
>  	}
> -- 
> 2.1.4
> 


From mark.rutland at arm.com  Mon Feb  1 07:35:54 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 1 Feb 2016 15:35:54 +0000
Subject: [PATCH V13 08/10] dma: qcom_hidma: read the channel id from HW
In-Reply-To: <1454106914-15857-9-git-send-email-okaya@codeaurora.org>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-9-git-send-email-okaya@codeaurora.org>
Message-ID: <20160201153542.GA20396@leverpostej>

On Fri, Jan 29, 2016 at 05:35:11PM -0500, Sinan Kaya wrote:
> Removing the flexibility to choose the event channel as there is no real
> use case right now. We have been using the values in ACPI that match the HW
> defaults. OS is reading the event-channel from the HW register now.

Fold this in to the patches adding the binding and the driver.

There is no reason to add this then remove it within the same series.

Mark.

> Signed-off-by: Sinan Kaya <okaya at codeaurora.org>
> ---
>  .../devicetree/bindings/dma/qcom_hidma_mgmt.txt    |  3 --
>  drivers/dma/qcom/hidma.c                           | 39 +---------------------
>  2 files changed, 1 insertion(+), 41 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> index e3677a5..fd5618b 100644
> --- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> +++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> @@ -51,7 +51,6 @@ Required properties:
>  - reg: Addresses for the transfer and event channel
>  - interrupts: Should contain the event interrupt
>  - desc-count: Number of asynchronous requests this channel can handle
> -- channel-index: The HW event channel completions will be delivered.
>  - iommus: required a iommu node
>  
>  Example:
> @@ -75,7 +74,6 @@ Hypervisor OS configuration:
>  			interrupts = <0 389 0>;
>  			desc-count = <10>;
>  			iommus = <&system_mmu>;
> -			channel-index = <4>;
>  		};
>  	};
>  
> @@ -87,6 +85,5 @@ Guest OS configuration:
>  		      <0 0x5c0b0000 0x0 0x1000>;
>  		interrupts = <0 389 0>;
>  		desc-count = <10>;
> -		channel-index = <4>;
>  		iommus = <&system_mmu>;
>  	};
> diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
> index ac20bdb..7180367 100644
> --- a/drivers/dma/qcom/hidma.c
> +++ b/drivers/dma/qcom/hidma.c
> @@ -101,26 +101,6 @@ static unsigned int nr_desc_prm;
>  module_param(nr_desc_prm, uint, 0644);
>  MODULE_PARM_DESC(nr_desc_prm, "number of descriptors (default: 0)");
>  
> -#define HIDMA_MAX_CHANNELS	64
> -static int channel_idx[HIDMA_MAX_CHANNELS] = {
> -	[0 ... (HIDMA_MAX_CHANNELS - 1)] = -1
> -};
> -
> -/*
> - * Each DMA channel is associated with an event channel for interrupt
> - * delivery. The event channel index usually comes from the firmware through
> - * ACPI/DT. When a HIDMA channel is executed in the guest machine context (QEMU)
> - * the device tree gets auto-generated based on the memory and IRQ resources
> - * this driver uses on the host machine. Any device specific paraemeter such as
> - * channel-index gets ignored by the QEMU.
> - * We are using this command line parameter to pass the event channel index to
> - * the guest machine.
> - */
> -static unsigned int num_channel_idx;
> -module_param_array_named(channel_idx, channel_idx, int, &num_channel_idx,
> -			 0644);
> -MODULE_PARM_DESC(channel_idx, "channel index array for the notifications");
> -static atomic_t channel_ref_count;
>  
>  /* process completed descriptors */
>  static void hidma_process_completed(struct hidma_chan *mchan)
> @@ -592,7 +572,6 @@ static int hidma_probe(struct platform_device *pdev)
>  	struct resource *trca_resource;
>  	struct resource *evca_resource;
>  	int chirq;
> -	int current_channel_index = atomic_read(&channel_ref_count);
>  	void __iomem *evca;
>  	void __iomem *trca;
>  	int rc;
> @@ -668,22 +647,7 @@ static int hidma_probe(struct platform_device *pdev)
>  		goto dmafree;
>  	}
>  
> -	if (current_channel_index > HIDMA_MAX_CHANNELS) {
> -		rc = -EINVAL;
> -		goto dmafree;
> -	}
> -
> -	dmadev->chidx = -1;
> -	device_property_read_u32(&pdev->dev, "channel-index", &dmadev->chidx);
> -
> -	/* kernel command line override for the guest machine */
> -	if (channel_idx[current_channel_index] != -1)
> -		dmadev->chidx = channel_idx[current_channel_index];
> -
> -	if (dmadev->chidx == -1) {
> -		rc = -EINVAL;
> -		goto dmafree;
> -	}
> +	dmadev->chidx = readl(dmadev->dev_trca + 0x28);
>  
>  	/* Set DMA mask to 64 bits. */
>  	rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
> @@ -724,7 +688,6 @@ static int hidma_probe(struct platform_device *pdev)
>  	platform_set_drvdata(pdev, dmadev);
>  	pm_runtime_mark_last_busy(dmadev->ddev.dev);
>  	pm_runtime_put_autosuspend(dmadev->ddev.dev);
> -	atomic_inc(&channel_ref_count);
>  	return 0;
>  
>  uninit:
> -- 
> 1.8.2.1
> 


From catalin.marinas at arm.com  Mon Feb  1 07:36:35 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 1 Feb 2016 15:36:35 +0000
Subject: [PATCH v2 06/21] arm64: KVM: VHE: Patch out use of HVC
In-Reply-To: <56AF5ED8.7010303@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-7-git-send-email-marc.zyngier@arm.com>
 <20160201131634.GI1478@cbox> <56AF5ED8.7010303@arm.com>
Message-ID: <20160201153635.GH15514@e104818-lin.cambridge.arm.com>

On Mon, Feb 01, 2016 at 01:34:16PM +0000, Marc Zyngier wrote:
> On 01/02/16 13:16, Christoffer Dall wrote:
> > On Mon, Jan 25, 2016 at 03:53:40PM +0000, Marc Zyngier wrote:
> >> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
> >> index 93e8d983..9e0683f 100644
> >> --- a/arch/arm64/kvm/hyp/hyp-entry.S
> >> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
> >> @@ -38,6 +38,32 @@
> >>  	ldp	x0, x1, [sp], #16
> >>  .endm
> >>  
> >> +.macro do_el2_call
> >> +	/*
> >> +	 * Shuffle the parameters before calling the function
> >> +	 * pointed to in x0. Assumes parameters in x[1,2,3].
> >> +	 */
> >> +	stp	lr, xzr, [sp, #-16]!
> > 
> > remind me why this pair isn't just doing "str" instead of "stp" with the
> > xzr ?
> 
> Because SP has to be aligned on a 16 bytes boundary at all times.

You could do something like:

	sub	sp, sp, #16
	str	lr, [sp]

-- 
Catalin


From christoffer.dall at linaro.org  Mon Feb  1 07:37:03 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 16:37:03 +0100
Subject: [PATCH v2 02/21] arm64: Allow the arch timer to use the HYP timer
In-Reply-To: <56AF60CA.6040709@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-3-git-send-email-marc.zyngier@arm.com>
 <20160201122907.GD1478@cbox> <56AF60CA.6040709@arm.com>
Message-ID: <20160201153703.GB1478@cbox>

On Mon, Feb 01, 2016 at 01:42:34PM +0000, Marc Zyngier wrote:
> On 01/02/16 12:29, Christoffer Dall wrote:
> > On Mon, Jan 25, 2016 at 03:53:36PM +0000, Marc Zyngier wrote:
> >> With the ARMv8.1 VHE, the kernel can run in HYP mode, and thus
> >> use the HYP timer instead of the normal guest timer in a mostly
> >> transparent way, except for the interrupt line.
> >>
> >> This patch reworks the arch timer code to allow the selection of
> >> the HYP PPI, possibly falling back to the guest timer if not
> >> available.
> >>
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >> ---
> >>  drivers/clocksource/arm_arch_timer.c | 96 ++++++++++++++++++++++--------------
> >>  1 file changed, 59 insertions(+), 37 deletions(-)
> >>
> >> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> >> index c64d543..ffe9d1c 100644
> >> --- a/drivers/clocksource/arm_arch_timer.c
> >> +++ b/drivers/clocksource/arm_arch_timer.c
> >> @@ -67,7 +67,7 @@ static int arch_timer_ppi[MAX_TIMER_PPI];
> >>  
> >>  static struct clock_event_device __percpu *arch_timer_evt;
> >>  
> >> -static bool arch_timer_use_virtual = true;
> >> +static enum ppi_nr arch_timer_uses_ppi = VIRT_PPI;
> >>  static bool arch_timer_c3stop;
> >>  static bool arch_timer_mem_use_virtual;
> >>  
> >> @@ -263,14 +263,20 @@ static void __arch_timer_setup(unsigned type,
> >>  		clk->name = "arch_sys_timer";
> >>  		clk->rating = 450;
> >>  		clk->cpumask = cpumask_of(smp_processor_id());
> >> -		if (arch_timer_use_virtual) {
> >> -			clk->irq = arch_timer_ppi[VIRT_PPI];
> >> +		clk->irq = arch_timer_ppi[arch_timer_uses_ppi];
> >> +		switch (arch_timer_uses_ppi) {
> >> +		case VIRT_PPI:
> >>  			clk->set_state_shutdown = arch_timer_shutdown_virt;
> >>  			clk->set_next_event = arch_timer_set_next_event_virt;
> >> -		} else {
> >> -			clk->irq = arch_timer_ppi[PHYS_SECURE_PPI];
> >> +			break;
> >> +		case PHYS_SECURE_PPI:
> >> +		case PHYS_NONSECURE_PPI:
> >> +		case HYP_PPI:
> >>  			clk->set_state_shutdown = arch_timer_shutdown_phys;
> >>  			clk->set_next_event = arch_timer_set_next_event_phys;
> >> +			break;
> >> +		default:
> >> +			BUG();
> >>  		}
> >>  	} else {
> >>  		clk->features |= CLOCK_EVT_FEAT_DYNIRQ;
> >> @@ -338,17 +344,20 @@ static void arch_counter_set_user_access(void)
> >>  	arch_timer_set_cntkctl(cntkctl);
> >>  }
> >>  
> >> +static bool arch_timer_has_nonsecure_ppi(void)
> >> +{
> >> +	return (arch_timer_uses_ppi == PHYS_SECURE_PPI &&
> >> +		arch_timer_ppi[PHYS_NONSECURE_PPI]);
> >> +}
> >> +
> >>  static int arch_timer_setup(struct clock_event_device *clk)
> >>  {
> >>  	__arch_timer_setup(ARCH_CP15_TIMER, clk);
> >>  
> >> -	if (arch_timer_use_virtual)
> >> -		enable_percpu_irq(arch_timer_ppi[VIRT_PPI], 0);
> >> -	else {
> >> -		enable_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI], 0);
> >> -		if (arch_timer_ppi[PHYS_NONSECURE_PPI])
> >> -			enable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI], 0);
> >> -	}
> >> +	enable_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi], 0);
> >> +
> >> +	if (arch_timer_has_nonsecure_ppi())
> >> +		enable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI], 0);
> >>  
> >>  	arch_counter_set_user_access();
> >>  	if (IS_ENABLED(CONFIG_ARM_ARCH_TIMER_EVTSTREAM))
> >> @@ -390,7 +399,7 @@ static void arch_timer_banner(unsigned type)
> >>  		     (unsigned long)arch_timer_rate / 1000000,
> >>  		     (unsigned long)(arch_timer_rate / 10000) % 100,
> >>  		     type & ARCH_CP15_TIMER ?
> >> -			arch_timer_use_virtual ? "virt" : "phys" :
> >> +		     (arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :
> >>  			"",
> >>  		     type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ?  "/" : "",
> >>  		     type & ARCH_MEM_TIMER ?
> >> @@ -460,7 +469,7 @@ static void __init arch_counter_register(unsigned type)
> >>  
> >>  	/* Register the CP15 based counter if we have one */
> >>  	if (type & ARCH_CP15_TIMER) {
> >> -		if (IS_ENABLED(CONFIG_ARM64) || arch_timer_use_virtual)
> >> +		if (IS_ENABLED(CONFIG_ARM64) || arch_timer_uses_ppi == VIRT_PPI)
> >>  			arch_timer_read_counter = arch_counter_get_cntvct;
> >>  		else
> >>  			arch_timer_read_counter = arch_counter_get_cntpct;
> >> @@ -490,13 +499,9 @@ static void arch_timer_stop(struct clock_event_device *clk)
> >>  	pr_debug("arch_timer_teardown disable IRQ%d cpu #%d\n",
> >>  		 clk->irq, smp_processor_id());
> >>  
> >> -	if (arch_timer_use_virtual)
> >> -		disable_percpu_irq(arch_timer_ppi[VIRT_PPI]);
> >> -	else {
> >> -		disable_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI]);
> >> -		if (arch_timer_ppi[PHYS_NONSECURE_PPI])
> >> -			disable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI]);
> >> -	}
> >> +	disable_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi]);
> >> +	if (arch_timer_has_nonsecure_ppi())
> >> +		disable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI]);
> >>  
> >>  	clk->set_state_shutdown(clk);
> >>  }
> >> @@ -562,12 +567,14 @@ static int __init arch_timer_register(void)
> >>  		goto out;
> >>  	}
> >>  
> >> -	if (arch_timer_use_virtual) {
> >> -		ppi = arch_timer_ppi[VIRT_PPI];
> >> +	ppi = arch_timer_ppi[arch_timer_uses_ppi];
> >> +	switch (arch_timer_uses_ppi) {
> >> +	case VIRT_PPI:
> >>  		err = request_percpu_irq(ppi, arch_timer_handler_virt,
> >>  					 "arch_timer", arch_timer_evt);
> >> -	} else {
> >> -		ppi = arch_timer_ppi[PHYS_SECURE_PPI];
> >> +		break;
> >> +	case PHYS_SECURE_PPI:
> >> +	case PHYS_NONSECURE_PPI:
> >>  		err = request_percpu_irq(ppi, arch_timer_handler_phys,
> >>  					 "arch_timer", arch_timer_evt);
> >>  		if (!err && arch_timer_ppi[PHYS_NONSECURE_PPI]) {
> >> @@ -578,6 +585,13 @@ static int __init arch_timer_register(void)
> >>  				free_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI],
> >>  						arch_timer_evt);
> >>  		}
> >> +		break;
> >> +	case HYP_PPI:
> >> +		err = request_percpu_irq(ppi, arch_timer_handler_phys,
> >> +					 "arch_timer", arch_timer_evt);
> >> +		break;
> >> +	default:
> >> +		BUG();
> >>  	}
> >>  
> >>  	if (err) {
> >> @@ -602,15 +616,10 @@ static int __init arch_timer_register(void)
> >>  out_unreg_notify:
> >>  	unregister_cpu_notifier(&arch_timer_cpu_nb);
> >>  out_free_irq:
> >> -	if (arch_timer_use_virtual)
> >> -		free_percpu_irq(arch_timer_ppi[VIRT_PPI], arch_timer_evt);
> >> -	else {
> >> -		free_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI],
> >> +	free_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi], arch_timer_evt);
> >> +	if (arch_timer_has_nonsecure_ppi())
> >> +		free_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI],
> >>  				arch_timer_evt);
> >> -		if (arch_timer_ppi[PHYS_NONSECURE_PPI])
> >> -			free_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI],
> >> -					arch_timer_evt);
> >> -	}
> >>  
> >>  out_free:
> >>  	free_percpu(arch_timer_evt);
> >> @@ -697,12 +706,25 @@ static void __init arch_timer_init(void)
> >>  	 *
> >>  	 * If no interrupt provided for virtual timer, we'll have to
> >>  	 * stick to the physical timer. It'd better be accessible...
> >> +	 *
> >> +	 * On ARMv8.1 with VH extensions, the kernel runs in HYP. VHE
> >> +	 * accesses to CNTP_*_EL1 registers are silently redirected to
> >> +	 * their CNTHP_*_EL2 counterparts, and use a different PPI
> >> +	 * number.
> >>  	 */
> >>  	if (is_hyp_mode_available() || !arch_timer_ppi[VIRT_PPI]) {
> >> -		arch_timer_use_virtual = false;
> >> +		bool has_ppi;
> >> +
> >> +		if (is_kernel_in_hyp_mode()) {
> >> +			arch_timer_uses_ppi = HYP_PPI;
> >> +			has_ppi = !!arch_timer_ppi[HYP_PPI];
> >> +		} else {
> >> +			arch_timer_uses_ppi = PHYS_SECURE_PPI;
> >> +			has_ppi = (!!arch_timer_ppi[PHYS_SECURE_PPI] ||
> >> +				   !!arch_timer_ppi[PHYS_NONSECURE_PPI]);
> > 
> > shouldn't this simply test the PHYS_SECURE_PPI since otherwise you could
> > potentially have the PHYS_NONSECURE_PPI but not PHYS_SECURE_PPI and
> > you'll try to request IRQ 0 for this later... ?
> 
> I don't really see how you could have the non-secure PPI, but not the
> secure one, as the binding doesn't give you opportunity to do so (the
> first interrupt is the secure one, then the non-secure one...).
> 
I didn't bring the DT-binding-by-heart part of my brain to work today.

You're right, thanks.

-Christoffer


From christoffer.dall at linaro.org  Mon Feb  1 07:38:14 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 16:38:14 +0100
Subject: [PATCH v2 05/21] arm64: KVM: VHE: Turn VTCR_EL2 setup into a
 reusable macro
In-Reply-To: <56AF6A05.5020501@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-6-git-send-email-marc.zyngier@arm.com>
 <20160201131300.GH1478@cbox> <56AF6A05.5020501@arm.com>
Message-ID: <20160201153814.GC1478@cbox>

On Mon, Feb 01, 2016 at 02:21:57PM +0000, Marc Zyngier wrote:
> On 01/02/16 13:13, Christoffer Dall wrote:
> > On Mon, Jan 25, 2016 at 03:53:39PM +0000, Marc Zyngier wrote:
> >> On a VHE-capable system, there is no point in setting VTCR_EL2
> >> at KVM init time. We can perfectly set it up when the kernel
> >> boots, removing the need for a more complicated configuration.
> > 
> > what's the complicated configuration which is avoided?
> 
> With VHE, there is no hyp-init at all, so what we avoid is a weird init
> sequence where we have to execute part of this hyp-init, but not all of it.
> 
> >>
> >> In order to allow this, turn VTCR_EL2 setup into a macro that
> >> we'll be able to reuse at boot time.
> >>
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >> ---
> >>  arch/arm64/include/asm/kvm_mmu.h | 23 +++++++++++++++++++++++
> >>  arch/arm64/kvm/hyp-init.S        | 18 +-----------------
> >>  2 files changed, 24 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> >> index 7364339..d3e6d7b 100644
> >> --- a/arch/arm64/include/asm/kvm_mmu.h
> >> +++ b/arch/arm64/include/asm/kvm_mmu.h
> >> @@ -56,6 +56,29 @@
> >>  
> >>  #ifdef __ASSEMBLY__
> >>  
> >> +#include <asm/kvm_arm.h>
> >> +
> >> +.macro setup_vtcr tmp1, tmp2
> >> +	mov	\tmp1, #(VTCR_EL2_FLAGS & 0xffff)
> >> +	movk	\tmp1, #(VTCR_EL2_FLAGS >> 16), lsl #16
> >> +	/*
> >> +	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
> >> +	 * VTCR_EL2.
> >> +	 */
> >> +	mrs	\tmp2, id_aa64mmfr0_el1
> >> +	bfi	\tmp1, \tmp2, #16, #3
> >> +	/*
> >> +	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS bit in
> >> +	 * VTCR_EL2.
> >> +	 */
> >> +	mrs	\tmp2, ID_AA64MMFR1_EL1
> >> +	ubfx	\tmp2, \tmp2, #5, #1
> >> +	lsl	\tmp2, \tmp2, #VTCR_EL2_VS
> >> +	orr	\tmp1, \tmp1, \tmp2
> >> +
> >> +	msr	vtcr_el2, \tmp1
> >> +	isb
> >> +.endm
> > 
> > this feels like an awful lot of code in a header file.
> 
> interrupt_head.S respectfully disagrees with you ;-).
> 
> > Is it crazy to imagine wanting to have different T0SZ for different VMs
> > in the future?  In that case, the T0SZ stuff should stay in KVM...
> 
> That's a rather compelling argument indeed. I'll see if I can turn the
> thing around in a slightly nicer way. How about moving it out of
> hyp-init.S altogether, and into C code?

That sounds better to me.

Thanks,
-Christoffer


From christoffer.dall at linaro.org  Mon Feb  1 07:39:12 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 16:39:12 +0100
Subject: [PATCH v2 06/21] arm64: KVM: VHE: Patch out use of HVC
In-Reply-To: <56AF5ED8.7010303@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-7-git-send-email-marc.zyngier@arm.com>
 <20160201131634.GI1478@cbox> <56AF5ED8.7010303@arm.com>
Message-ID: <20160201153912.GD1478@cbox>

On Mon, Feb 01, 2016 at 01:34:16PM +0000, Marc Zyngier wrote:
> On 01/02/16 13:16, Christoffer Dall wrote:
> > On Mon, Jan 25, 2016 at 03:53:40PM +0000, Marc Zyngier wrote:
> >> With VHE, the host never issues an HVC instruction to get into the
> >> KVM code, as we can simply branch there.
> >>
> >> Use runtime code patching to simplify things a bit.
> >>
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >> ---
> >>  arch/arm64/kvm/hyp.S           |  7 +++++++
> >>  arch/arm64/kvm/hyp/hyp-entry.S | 38 +++++++++++++++++++++++++++++---------
> >>  2 files changed, 36 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
> >> index 0ccdcbb..0689a74 100644
> >> --- a/arch/arm64/kvm/hyp.S
> >> +++ b/arch/arm64/kvm/hyp.S
> >> @@ -17,7 +17,9 @@
> >>  
> >>  #include <linux/linkage.h>
> >>  
> >> +#include <asm/alternative.h>
> >>  #include <asm/assembler.h>
> >> +#include <asm/cpufeature.h>
> >>  
> >>  /*
> >>   * u64 kvm_call_hyp(void *hypfn, ...);
> >> @@ -38,6 +40,11 @@
> >>   * arch/arm64/kernel/hyp_stub.S.
> >>   */
> >>  ENTRY(kvm_call_hyp)
> >> +alternative_if_not ARM64_HAS_VIRT_HOST_EXTN	
> >>  	hvc	#0
> >>  	ret
> >> +alternative_else
> >> +	b	__vhe_hyp_call
> >> +	nop
> >> +alternative_endif
> >>  ENDPROC(kvm_call_hyp)
> >> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
> >> index 93e8d983..9e0683f 100644
> >> --- a/arch/arm64/kvm/hyp/hyp-entry.S
> >> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
> >> @@ -38,6 +38,32 @@
> >>  	ldp	x0, x1, [sp], #16
> >>  .endm
> >>  
> >> +.macro do_el2_call
> >> +	/*
> >> +	 * Shuffle the parameters before calling the function
> >> +	 * pointed to in x0. Assumes parameters in x[1,2,3].
> >> +	 */
> >> +	stp	lr, xzr, [sp, #-16]!
> > 
> > remind me why this pair isn't just doing "str" instead of "stp" with the
> > xzr ?
> 
> Because SP has to be aligned on a 16 bytes boundary at all times.
> 

right, duh.

> > 
> >> +	mov	lr, x0
> >> +	mov	x0, x1
> >> +	mov	x1, x2
> >> +	mov	x2, x3
> >> +	blr	lr
> >> +	ldp	lr, xzr, [sp], #16
> >> +.endm
> >> +
> >> +ENTRY(__vhe_hyp_call)
> >> +	do_el2_call
> >> +	/*
> >> +	 * We used to rely on having an exception return to get
> >> +	 * an implicit isb. In the E2H case, we don't have it anymore.
> >> +	 * rather than changing all the leaf functions, just do it here
> >> +	 * before returning to the rest of the kernel.
> >> +	 */
> > 
> > why is this not the case with an ISB before do_el2_call then?
> 
> That's a good point. I guess the safest thing to do would be to add one,
> but looking at the various functions we call, I don't see any that could
> go wrong by not having a ISB in their prologue.
> 
> Or maybe you've identified such a case?
> 
I think I argued on Mario's VFP patches that we could rely on an ISB
before the hyp call, but they're not merged yet, so, hey...

-Christoffer


From christoffer.dall at linaro.org  Mon Feb  1 07:40:52 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 16:40:52 +0100
Subject: [PATCH v2 07/21] arm64: KVM: VHE: Patch out kern_hyp_va
In-Reply-To: <56AF5FF1.4010701@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-8-git-send-email-marc.zyngier@arm.com>
 <20160201132042.GJ1478@cbox> <56AF5FF1.4010701@arm.com>
Message-ID: <20160201154052.GE1478@cbox>

On Mon, Feb 01, 2016 at 01:38:57PM +0000, Marc Zyngier wrote:
> On 01/02/16 13:20, Christoffer Dall wrote:
> > On Mon, Jan 25, 2016 at 03:53:41PM +0000, Marc Zyngier wrote:
> >> The kern_hyp_va macro is pretty meaninless with VHE, as there is
> >> only one mapping - the kernel one.
> >>
> >> In order to keep the code readable and efficient, use runtime
> >> patching to replace the 'and' instruction used to compute the VA
> >> with a 'nop'.
> >>
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >> ---
> >>  arch/arm64/include/asm/kvm_mmu.h | 11 ++++++++++-
> >>  arch/arm64/kvm/hyp/hyp.h         | 25 ++++++++++++++++++++++---
> >>  2 files changed, 32 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> >> index d3e6d7b..62f0d14 100644
> >> --- a/arch/arm64/include/asm/kvm_mmu.h
> >> +++ b/arch/arm64/include/asm/kvm_mmu.h
> >> @@ -23,13 +23,16 @@
> >>  #include <asm/cpufeature.h>
> >>  
> >>  /*
> >> - * As we only have the TTBR0_EL2 register, we cannot express
> >> + * As ARMv8.0 only has the TTBR0_EL2 register, we cannot express
> >>   * "negative" addresses. This makes it impossible to directly share
> >>   * mappings with the kernel.
> >>   *
> >>   * Instead, give the HYP mode its own VA region at a fixed offset from
> >>   * the kernel by just masking the top bits (which are all ones for a
> >>   * kernel address).
> >> + *
> >> + * ARMv8.1 (using VHE) does have a TTBR1_EL2, and doesn't use these
> >> + * macros (the entire kernel runs at EL2).
> >>   */
> >>  #define HYP_PAGE_OFFSET_SHIFT	VA_BITS
> >>  #define HYP_PAGE_OFFSET_MASK	((UL(1) << HYP_PAGE_OFFSET_SHIFT) - 1)
> >> @@ -56,6 +59,8 @@
> >>  
> >>  #ifdef __ASSEMBLY__
> >>  
> >> +#include <asm/alternative.h>
> >> +#include <asm/cpufeature.h>
> >>  #include <asm/kvm_arm.h>
> >>  
> >>  .macro setup_vtcr tmp1, tmp2
> >> @@ -84,7 +89,11 @@
> >>   * reg: VA to be converted.
> >>   */
> >>  .macro kern_hyp_va	reg
> >> +alternative_if_not ARM64_HAS_VIRT_HOST_EXTN	
> >>  	and	\reg, \reg, #HYP_PAGE_OFFSET_MASK
> >> +alternative_else
> >> +	nop
> >> +alternative_endif
> >>  .endm
> >>  
> >>  #else
> >> diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
> >> index fb27517..fc502f3 100644
> >> --- a/arch/arm64/kvm/hyp/hyp.h
> >> +++ b/arch/arm64/kvm/hyp/hyp.h
> >> @@ -25,9 +25,28 @@
> >>  
> >>  #define __hyp_text __section(.hyp.text) notrace
> >>  
> >> -#define kern_hyp_va(v) (typeof(v))((unsigned long)(v) & HYP_PAGE_OFFSET_MASK)
> >> -#define hyp_kern_va(v) (typeof(v))((unsigned long)(v) - HYP_PAGE_OFFSET \
> >> -						      + PAGE_OFFSET)
> >> +static inline unsigned long __kern_hyp_va(unsigned long v)
> >> +{
> >> +	asm volatile(ALTERNATIVE("and %0, %0, %1",
> >> +				 "nop",
> >> +				 ARM64_HAS_VIRT_HOST_EXTN)
> >> +		     : "+r" (v) : "i" (HYP_PAGE_OFFSET_MASK));
> >> +	return v;
> >> +}
> >> +
> >> +#define kern_hyp_va(v) (typeof(v))(__kern_hyp_va((unsigned long)(v)))
> >> +
> >> +static inline unsigned long __hyp_kern_va(unsigned long v)
> >> +{
> >> +	u64 offset = PAGE_OFFSET - HYP_PAGE_OFFSET;
> >> +	asm volatile(ALTERNATIVE("add %0, %0, %1",
> >> +				 "nop",
> >> +				 ARM64_HAS_VIRT_HOST_EXTN)
> >> +		     : "+r" (v) : "r" (offset));
> >> +	return v;
> >> +}
> >> +
> >> +#define hyp_kern_va(v) (typeof(v))(__hyp_kern_va((unsigned long)(v)))
> > 
> > why do we need this casting of values instead of just defining these
> > inlines and calling them directly with proper typing?
> 
> We commonly pass both pointers and unsigned long to this helper. Do you
> really want a separate helper for each type instead of one that does it all?
> 

no, what I was suggesting was to always take a specific type and change
the callers that don't match to use a specific cast so you give the
compiler a chance to scream at you when writing new code.

But I don't feel strongly about it.

Thanks,
-Christoffer


From robh at kernel.org  Mon Feb  1 07:40:43 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 09:40:43 -0600
Subject: [PATCH V4 1/2] regulator: Add document for MT6323 regulator
In-Reply-To: <1453896059-44589-1-git-send-email-blogic@openwrt.org>
References: <1453896059-44589-1-git-send-email-blogic@openwrt.org>
Message-ID: <20160201154043.GA24185@rob-hp-laptop>

On Wed, Jan 27, 2016 at 01:00:58PM +0100, John Crispin wrote:
> Signed-off-by: John Crispin <blogic at openwrt.org>
> Cc: devicetree at vger.kernel.org
> 
> ---
> Changes in V4
> * regulator is a subnode and not a property
> 
> Changes in V3
> * fix the subject prefix
> 
>  .../bindings/regulator/mt6323-regulator.txt        |  244 ++++++++++++++++++++
>  1 file changed, 244 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/regulator/mt6323-regulator.txt

A few nits, otherwise:

Acked-by: Rob Herring <robh at kernel.org>

> 
> diff --git a/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
> new file mode 100644
> index 0000000..1ee3dd4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
> @@ -0,0 +1,244 @@
> +Mediatek MT6323 Regulator Driver
> +
> +Required properties:
> +- compatible: "mediatek,mt6323-regulator"
> +
> +All voltage regulators are defined as subnodes of the regulator drivers node.

s/drivers//

I believe the standard node name here is "regulators".

> +A list of regulators provided by this controller are defined as subnodes of
> +the drivers node. Each regulator is named according to its regulator type,
> +buck_<name> and ldo_<name>. The definition for each of these nodes is defined
> +using the standard binding for regulators at
> +Documentation/devicetree/bindings/regulator/regulator.txt.
> +
> +The valid names for regulators are::
> +BUCK:
> +  buck_vproc, buck_vsys, buck_vpa
> +LDO:
> +  ldo_vtcxo, ldo_vcn28, ldo_vcn33_bt, ldo_vcn33_wifi, ldo_va, ldo_vcama,
> +  ldo_vio28, ldo_vusb, ldo_vmc, ldo_vmch, ldo_vemc3v3, ldo_vgp1, ldo_vgp2,
> +  ldo_vgp3, ldo_vcn18, ldo_vsim1, ldo_vsim2, ldo_vrtc, ldo_vcamaf, ldo_vibr,
> +  ldo_vrf18, ldo_vm, ldo_vio18, ldo_vcamd, ldo_vcamio
> +
> +Example:
> +
> +	pmic: mt6323 {
> +		compatible = "mediatek,mt6323";
> +
> +		mt6323regulator: regulator{

regulators and a space (i.e. "regulators {")

> +			compatible = "mediatek,mt6323-regulator";
> +


From robh at kernel.org  Mon Feb  1 07:41:37 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 09:41:37 -0600
Subject: [PATCH V3 1/4] dt-bindings: mfd: Add bindings for the MediaTek
 MT6323 PMIC
In-Reply-To: <1453895258-44369-1-git-send-email-blogic@openwrt.org>
References: <1453895258-44369-1-git-send-email-blogic@openwrt.org>
Message-ID: <20160201154137.GA26331@rob-hp-laptop>

On Wed, Jan 27, 2016 at 12:47:35PM +0100, John Crispin wrote:
> Signed-off-by: John Crispin <blogic at openwrt.org>
> Cc: devicetree at vger.kernel.org
> ---
>  Documentation/devicetree/bindings/mfd/mt6397.txt |   10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)

Acked-by: Rob Herring <robh at kernel.org>


From eric.auger at linaro.org  Mon Feb  1 07:41:17 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Mon, 1 Feb 2016 16:41:17 +0100
Subject: [PATCH V13 10/10] vfio, platform: add QTI HIDMA reset driver
In-Reply-To: <1454106914-15857-11-git-send-email-okaya@codeaurora.org>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-11-git-send-email-okaya@codeaurora.org>
Message-ID: <56AF7C9D.4070600@linaro.org>

Hi Sinan,
On 01/29/2016 11:35 PM, Sinan Kaya wrote:
> In situations where the userspace driver is stopped abnormally and the
> VFIO platform device is released, the assigned HW device currently is
> left running. As a consequence the HW device might continue issuing IRQs
> and performing DMA accesses.
> 
> This patch is implementing a reset driver for HIDMA platform driver.
> This gets called by the VFIO platform reset interface.
> 
> Signed-off-by: Sinan Kaya <okaya at codeaurora.org>
> ---
>  drivers/vfio/platform/reset/Kconfig                |  9 ++
>  drivers/vfio/platform/reset/Makefile               |  2 +
>  .../vfio/platform/reset/vfio_platform_qcomhidma.c  | 99 ++++++++++++++++++++++
>  3 files changed, 110 insertions(+)
>  create mode 100644 drivers/vfio/platform/reset/vfio_platform_qcomhidma.c
> 
> diff --git a/drivers/vfio/platform/reset/Kconfig b/drivers/vfio/platform/reset/Kconfig
> index 70cccc5..d02b3b5 100644
> --- a/drivers/vfio/platform/reset/Kconfig
> +++ b/drivers/vfio/platform/reset/Kconfig
> @@ -13,3 +13,12 @@ config VFIO_PLATFORM_AMDXGBE_RESET
>  	  Enables the VFIO platform driver to handle reset for AMD XGBE
>  
>  	  If you don't know what to do here, say N.
> +
> +config VFIO_PLATFORM_QCOMHIDMA_RESET
> +	tristate "VFIO support for Qualcomm Technologies HIDMA reset"
> +	depends on VFIO_PLATFORM
> +	help
> +	  Enables the VFIO platform driver to handle reset for Qualcomm Technologies
> +	  HIDMA Channel.
> +
> +	  If you don't know what to do here, say N.
> diff --git a/drivers/vfio/platform/reset/Makefile b/drivers/vfio/platform/reset/Makefile
> index 93f4e23..ec7748a 100644
> --- a/drivers/vfio/platform/reset/Makefile
> +++ b/drivers/vfio/platform/reset/Makefile
> @@ -1,7 +1,9 @@
>  vfio-platform-calxedaxgmac-y := vfio_platform_calxedaxgmac.o
>  vfio-platform-amdxgbe-y := vfio_platform_amdxgbe.o
> +vfio-platform-qcomhidma-y := vfio_platform_qcomhidma.o
>  
>  ccflags-y += -Idrivers/vfio/platform
>  
>  obj-$(CONFIG_VFIO_PLATFORM_CALXEDAXGMAC_RESET) += vfio-platform-calxedaxgmac.o
> +obj-$(CONFIG_VFIO_PLATFORM_QCOMHIDMA_RESET) += vfio-platform-qcomhidma.o
>  obj-$(CONFIG_VFIO_PLATFORM_AMDXGBE_RESET) += vfio-platform-amdxgbe.o
> diff --git a/drivers/vfio/platform/reset/vfio_platform_qcomhidma.c b/drivers/vfio/platform/reset/vfio_platform_qcomhidma.c
> new file mode 100644
> index 0000000..4e7a59c
> --- /dev/null
> +++ b/drivers/vfio/platform/reset/vfio_platform_qcomhidma.c
> @@ -0,0 +1,99 @@
> +/*
> + * Qualcomm Technologies HIDMA VFIO Reset Driver
> + *
> + * Copyright (c) 2016, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/device.h>
> +#include <linux/iopoll.h>
> +
> +#include "vfio_platform_private.h"
> +
> +#define TRCA_CTRLSTS_OFFSET		0x000
> +#define EVCA_CTRLSTS_OFFSET		0x000
> +
> +#define CH_CONTROL_MASK		GENMASK(7, 0)
> +#define CH_STATE_MASK			GENMASK(7, 0)
> +#define CH_STATE_BIT_POS		0x8
> +
> +#define HIDMA_CH_STATE(val)	\
> +	((val >> CH_STATE_BIT_POS) & CH_STATE_MASK)
> +
> +#define EVCA_IRQ_EN_OFFSET		0x110
> +
> +#define CH_RESET			9
> +#define CH_DISABLED			0
> +
> +int vfio_platform_qcomhidma_reset(struct vfio_platform_device *vdev)
> +{
> +	struct vfio_platform_region trreg;
> +	struct vfio_platform_region evreg;
> +	u32 val;
> +	int ret;
> +
> +	if (vdev->num_regions != 2)
> +		return -ENODEV;
> +
> +	trreg = vdev->regions[0];
> +	if (!trreg.ioaddr) {
> +		trreg.ioaddr =
> +			ioremap_nocache(trreg.addr, trreg.size);
this is going to leak. See "vfio: platform: reset: calxedaxgmac: fix
ioaddr leak".
> +		if (!trreg.ioaddr)
> +			return -ENOMEM;
> +	}
> +
> +	evreg = vdev->regions[1];
> +	if (!evreg.ioaddr) {
> +		evreg.ioaddr =
> +			ioremap_nocache(evreg.addr, evreg.size);
same here
> +		if (!evreg.ioaddr)
> +			return -ENOMEM;
> +	}
> +
I understood the device is a kind of SR-IOV platform device. When the VF
gets reset are there any interactions with the management driver? Is it
handled by HW?

Best Regards

Eric
> +	/* disable IRQ */
> +	writel(0, evreg.ioaddr + EVCA_IRQ_EN_OFFSET);
> +
> +	/* reset both transfer and event channels */
> +	val = readl(trreg.ioaddr + TRCA_CTRLSTS_OFFSET);
> +	val &= ~(CH_CONTROL_MASK << 16);
> +	val |= CH_RESET << 16;
> +	writel(val, trreg.ioaddr + TRCA_CTRLSTS_OFFSET);
> +
> +	ret = readl_poll_timeout(trreg.ioaddr + TRCA_CTRLSTS_OFFSET, val,
> +				 HIDMA_CH_STATE(val) == CH_DISABLED, 1000,
> +				 10000);
> +	if (ret)
> +		return ret;
> +
> +	val = readl(evreg.ioaddr + EVCA_CTRLSTS_OFFSET);
> +	val &= ~(CH_CONTROL_MASK << 16);
> +	val |= CH_RESET << 16;
> +	writel(val, evreg.ioaddr + EVCA_CTRLSTS_OFFSET);
> +
> +	ret = readl_poll_timeout(evreg.ioaddr + EVCA_CTRLSTS_OFFSET, val,
> +				 HIDMA_CH_STATE(val) == CH_DISABLED, 1000,
> +				 10000);
> +	if (ret)
> +		return ret;
> +
> +	pr_info("HIDMA channel reset\n");
> +	return 0;
> +}
> +module_vfio_reset_handler("qcom,hidma", NULL,
> +			  vfio_platform_qcomhidma_reset);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("Reset support for Qualcomm Technologies HIDMA device");
> 



From christoffer.dall at linaro.org  Mon Feb  1 07:43:29 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 16:43:29 +0100
Subject: [PATCH v2 08/21] arm64: KVM: VHE: Introduce unified system
 register accessors
In-Reply-To: <56AF65F7.5000404@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-9-git-send-email-marc.zyngier@arm.com>
 <20160201134732.GK1478@cbox> <56AF65F7.5000404@arm.com>
Message-ID: <20160201154329.GF1478@cbox>

On Mon, Feb 01, 2016 at 02:04:39PM +0000, Marc Zyngier wrote:
> On 01/02/16 13:47, Christoffer Dall wrote:
> > On Mon, Jan 25, 2016 at 03:53:42PM +0000, Marc Zyngier wrote:
> >> VHE brings its own bag of new system registers, or rather system
> >> register accessors, as it define new ways to access both guest
> >> and host system registers. For example, from the host:
> >>
> >> - The host TCR_EL2 register is accessed using the TCR_EL1 accessor
> >> - The guest TCR_EL1 register is accessed using the TCR_EL12 accessor
> >>
> >> Obviously, this is confusing. A way to somehow reduce the complexity
> >> of writing code for both ARMv8 and ARMv8.1 is to use a set of unified
> >> accessors that will generate the right sysreg, depending on the mode
> >> the CPU is running in. For example:
> >>
> >> - read_sysreg_el1(tcr) will use TCR_EL1 on ARMv8, and TCR_EL12 on
> >>   ARMv8.1 with VHE.
> >> - read_sysreg_el2(tcr) will use TCR_EL2 on ARMv8, and TCR_EL1 on
> >>   ARMv8.1 with VHE.
> >>
> >> We end up with three sets of accessors ({read,write}_sysreg_el[012])
> >> that can be directly used from C code. We take this opportunity to
> >> also add the definition for the new VHE sysregs.(
> > 
> > weird closing parenthesis.
> > 
> >>
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >> ---
> >>  arch/arm64/kvm/hyp/hyp.h | 72 ++++++++++++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 72 insertions(+)
> >>
> >> diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
> >> index fc502f3..744c919 100644
> >> --- a/arch/arm64/kvm/hyp/hyp.h
> >> +++ b/arch/arm64/kvm/hyp/hyp.h
> >> @@ -48,6 +48,78 @@ static inline unsigned long __hyp_kern_va(unsigned long v)
> >>  
> >>  #define hyp_kern_va(v) (typeof(v))(__hyp_kern_va((unsigned long)(v)))
> >>  
> >> +#define read_sysreg_elx(r,nvh,vh)					\
> >> +	({								\
> >> +		u64 reg;						\
> >> +		asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##nvh),\
> >> +					 "mrs_s %0, " __stringify(r##vh),\
> >> +					 ARM64_HAS_VIRT_HOST_EXTN)	\
> >> +			     : "=r" (reg));				\
> >> +		reg;							\
> >> +	})
> >> +
> >> +#define write_sysreg_elx(v,r,nvh,vh)					\
> >> +	do {								\
> >> +		u64 __val = (u64)(v);					\
> >> +		asm volatile(ALTERNATIVE("msr " __stringify(r##nvh) ", %x0",\
> >> +					 "msr_s " __stringify(r##vh) ", %x0",\
> >> +					 ARM64_HAS_VIRT_HOST_EXTN)	\
> >> +					 : : "rZ" (__val));		\
> > 
> > what is rZ ?
> > (complete Google-fu failure misery)
> 
> This gives the assembler the opportunity to generate a XZR register
> access if the value is zero. See:
> 
> https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints
> 

I don't know why I didn't find this.

So "Integer constant zero " means, this may be zero.  Right.

> > 
> >> +	} while (0)
> >> +
> >> +/*
> >> + * Unified accessors for registers that have a different encoding
> >> + * between VHE and non-VHE. They must be specified without their "ELx"
> >> + * encoding.
> >> + */
> >> +#define read_sysreg_el2(r)						\
> >> +	({								\
> >> +		u64 reg;						\
> >> +		asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##_EL2),\
> >> +					 "mrs %0, " __stringify(r##_EL1),\
> >> +					 ARM64_HAS_VIRT_HOST_EXTN)	\
> >> +			     : "=r" (reg));				\
> >> +		reg;							\
> >> +	})
> >> +
> >> +#define write_sysreg_el2(v,r)						\
> >> +	do {								\
> >> +		u64 __val = (u64)(v);					\
> >> +		asm volatile(ALTERNATIVE("msr " __stringify(r##_EL2) ", %x0",\
> >> +					 "msr " __stringify(r##_EL1) ", %x0",\
> >> +					 ARM64_HAS_VIRT_HOST_EXTN)	\
> >> +					 : : "rZ" (__val));		\
> >> +	} while (0)
> >> +
> >> +#define read_sysreg_el0(r)	read_sysreg_elx(r, _EL0, _EL02)
> >> +#define write_sysreg_el0(v,r)	write_sysreg_elx(v, r, _EL0, _EL02)
> >> +#define read_sysreg_el1(r)	read_sysreg_elx(r, _EL1, _EL12)
> >> +#define write_sysreg_el1(v,r)	write_sysreg_elx(v, r, _EL1, _EL12)
> >> +
> >> +/* The VHE specific system registers and their encoding */
> >> +#define sctlr_EL12              sys_reg(3, 5, 1, 0, 0)
> >> +#define cpacr_EL12              sys_reg(3, 5, 1, 0, 2)
> >> +#define ttbr0_EL12              sys_reg(3, 5, 2, 0, 0)
> >> +#define ttbr1_EL12              sys_reg(3, 5, 2, 0, 1)
> >> +#define tcr_EL12                sys_reg(3, 5, 2, 0, 2)
> >> +#define afsr0_EL12              sys_reg(3, 5, 5, 1, 0)
> >> +#define afsr1_EL12              sys_reg(3, 5, 5, 1, 1)
> >> +#define esr_EL12                sys_reg(3, 5, 5, 2, 0)
> >> +#define far_EL12                sys_reg(3, 5, 6, 0, 0)
> >> +#define mair_EL12               sys_reg(3, 5, 10, 2, 0)
> >> +#define amair_EL12              sys_reg(3, 5, 10, 3, 0)
> >> +#define vbar_EL12               sys_reg(3, 5, 12, 0, 0)
> >> +#define contextidr_EL12         sys_reg(3, 5, 13, 0, 1)
> >> +#define cntkctl_EL12            sys_reg(3, 5, 14, 1, 0)
> >> +#define cntp_tval_EL02          sys_reg(3, 5, 14, 2, 0)
> >> +#define cntp_ctl_EL02           sys_reg(3, 5, 14, 2, 1)
> >> +#define cntp_cval_EL02          sys_reg(3, 5, 14, 2, 2)
> >> +#define cntv_tval_EL02          sys_reg(3, 5, 14, 3, 0)
> >> +#define cntv_ctl_EL02           sys_reg(3, 5, 14, 3, 1)
> >> +#define cntv_cval_EL02          sys_reg(3, 5, 14, 3, 2)
> > 
> > as always, fun stuff to review.
> 
> Well, short of having publicly available documentation, or force
> everyone to upgrade their binutils to deal be able to cope with the new
> sysregs, I don't know what else to do. I'm open to suggestions, though.
> 

I wasn't suggesting you do anything different, I just put the stupid
comment there so you knew that I actually checked the values and so that
I didn't forget that I did, and ended up doing it again if I look at
this later...

> > 
> >> +#define spsr_EL12               sys_reg(3, 5, 4, 0, 0)
> >> +#define elr_EL12                sys_reg(3, 5, 4, 0, 1)
> >> +
> > 
> > I couldn't quite decipher the spec as to how these are the right
> > instruction encodings, so I'm going to trust the testing that this is
> > done right.
> 
> If you have access to the spec, you have to play a substitution game
> between the canonical encoding of the register accessed, and the
> register used. For example:
> 
> SPSR_EL1 (3, 0, 4, 0, 0) -> SPSR_EL12 (3, 5, 4, 0, 0)
> 
> In practice, only Op1 changes.
> 
That's what I assumed, thanks for confirming.

-Christoffer


From okaya at codeaurora.org  Mon Feb  1 07:46:58 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Mon, 1 Feb 2016 10:46:58 -0500
Subject: [PATCH V13 08/10] dma: qcom_hidma: read the channel id from HW
In-Reply-To: <20160201153542.GA20396@leverpostej>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-9-git-send-email-okaya@codeaurora.org>
 <20160201153542.GA20396@leverpostej>
Message-ID: <56AF7DF2.9020202@codeaurora.org>

On 2/1/2016 10:35 AM, Mark Rutland wrote:
> Fold this in to the patches adding the binding and the driver.
> 
> There is no reason to add this then remove it within the same series.
> 
> Mark.

Will do. I was trying to keep changes to the minimum on the other patches to 
help the reviewers.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


From jeremy.linton at arm.com  Mon Feb  1 07:47:00 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Mon, 1 Feb 2016 09:47:00 -0600
Subject: [PATCH 0/3] UEFI stub pre-boot compat checks
In-Reply-To: <1454000549-9189-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454000549-9189-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <56AF7DF4.3050504@arm.com>

On 01/28/2016 11:02 AM, Ard Biesheuvel wrote:
> As discussed earlier today [1], and last year [2], it makes sense for the
> UEFI stub to perform some basic checks on the hardware for missing features
> that would prevent the kernel from booting to a state where it can even
> complain about this.
>
> So implements this for ARM, to check on LPAE builds whether the CPU supports
> it (patch #1), and for arm64, to check whether the build time granule is
> implemented by the CPU (patch #2). Patch #3 wires it up into the shared init
> code.

Ard,

This version looks good, and addresses all the reservations from the 16k 
page thread. Thanks!

Reviewed-by: Jeremy Linton <jeremy.linton at arm.com>




From okaya at codeaurora.org  Mon Feb  1 07:51:23 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Mon, 1 Feb 2016 10:51:23 -0500
Subject: [PATCH V13 10/10] vfio, platform: add QTI HIDMA reset driver
In-Reply-To: <56AF7C9D.4070600@linaro.org>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-11-git-send-email-okaya@codeaurora.org>
 <56AF7C9D.4070600@linaro.org>
Message-ID: <56AF7EFB.9040108@codeaurora.org>

On 2/1/2016 10:41 AM, Eric Auger wrote:
> Hi Sinan,

>> +
>> +	trreg = vdev->regions[0];
>> +	if (!trreg.ioaddr) {
>> +		trreg.ioaddr =
>> +			ioremap_nocache(trreg.addr, trreg.size);
> this is going to leak. See "vfio: platform: reset: calxedaxgmac: fix
> ioaddr leak".

Thanks, I was following what other drivers were doing and got hit by the same problem :)

>> +		if (!trreg.ioaddr)
>> +			return -ENOMEM;
>> +	}
>> +
>> +	evreg = vdev->regions[1];
>> +	if (!evreg.ioaddr) {
>> +		evreg.ioaddr =
>> +			ioremap_nocache(evreg.addr, evreg.size);
> same here
I'll take care of it.

>> +		if (!evreg.ioaddr)
>> +			return -ENOMEM;
>> +	}
>> +
> I understood the device is a kind of SR-IOV platform device. When the VF
> gets reset are there any interactions with the management driver? Is it
> handled by HW?

There is no communication between the management interface and the DMA channels. 
Management interface is just a runtime platform resource allocator. 

"if you pay more, you get more DMA bandwidth. Otherwise, you get to share the channel 
with other users"

The DMA channels can be reset independent of other DMA channels or the management HW. 
This is a HW feature.

> 
> Best Regards
> 
> Eric
>> +	/* disable IRQ */
>> +	writel(0, evreg.ioaddr + EVCA_IRQ_EN_OFFSET);
>> +
>> +	/* reset both transfer and event channels */
>> +	val = readl(trreg.ioaddr + TRCA_CTRLSTS_OFFSET);
>> +	val &= ~(CH_CONTROL_MASK << 16);
>> +	val |= CH_RESET << 16;
>> +	writel(val, trreg.ioaddr + TRCA_CTRLSTS_OFFSET);
>> +
>> +	ret = readl_poll_timeout(trreg.ioaddr + TRCA_CTRLSTS_OFFSET, val,
>> +				 HIDMA_CH_STATE(val) == CH_DISABLED, 1000,
>> +				 10000);
>> +	if (ret)
>> +		return ret;
>> +
>> +	val = readl(evreg.ioaddr + EVCA_CTRLSTS_OFFSET);
>> +	val &= ~(CH_CONTROL_MASK << 16);
>> +	val |= CH_RESET << 16;
>> +	writel(val, evreg.ioaddr + EVCA_CTRLSTS_OFFSET);
>> +
>> +	ret = readl_poll_timeout(evreg.ioaddr + EVCA_CTRLSTS_OFFSET, val,
>> +				 HIDMA_CH_STATE(val) == CH_DISABLED, 1000,
>> +				 10000);
>> +	if (ret)
>> +		return ret;
>> +
>> +	pr_info("HIDMA channel reset\n");
>> +	return 0;
>> +}
>> +module_vfio_reset_handler("qcom,hidma", NULL,
>> +			  vfio_platform_qcomhidma_reset);
>> +
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("Reset support for Qualcomm Technologies HIDMA device");
>>
> 


-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


From robh at kernel.org  Mon Feb  1 07:55:53 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 1 Feb 2016 09:55:53 -0600
Subject: [PATCH v4 2/6] dt-bindings: ARM: Mediatek: Document bindings for
 MT2701
In-Reply-To: <1453353537.5384.33.camel@mtksdaap41>
References: <1453271747-57397-1-git-send-email-jamesjj.liao@mediatek.com>
 <1453271747-57397-3-git-send-email-jamesjj.liao@mediatek.com>
 <20160120163236.GA21035@rob-hp-laptop> <1453353537.5384.33.camel@mtksdaap41>
Message-ID: <CAL_JsqLJVLDbPqynmD9-Yc=JVGH4iLPfb2keA5G7c2fjitAsSQ@mail.gmail.com>

On Wed, Jan 20, 2016 at 11:18 PM, James Liao <jamesjj.liao at mediatek.com> wrote:
> Hi Rob,
>
> On Wed, 2016-01-20 at 10:32 -0600, Rob Herring wrote:
>> On Wed, Jan 20, 2016 at 02:35:43PM +0800, James Liao wrote:
>> > This patch adds the binding documentation for apmixedsys, bdpsys,
>> > ethsys, hifsys, imgsys, infracfg, mmsys, pericfg, topckgen and
>> > vdecsys for Mediatek MT2701.
>> >
>> > Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
>> > Tested-by: John Crispin <blogic at openwrt.org>
>> > ---
>> >  .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |  1 +
>> >  .../bindings/arm/mediatek/mediatek,bdpsys.txt      | 22 ++++++++++++++++++++++
>> >  .../bindings/arm/mediatek/mediatek,ethsys.txt      | 22 ++++++++++++++++++++++
>> >  .../bindings/arm/mediatek/mediatek,hifsys.txt      | 22 ++++++++++++++++++++++
>> >  .../bindings/arm/mediatek/mediatek,imgsys.txt      |  1 +
>> >  .../bindings/arm/mediatek/mediatek,infracfg.txt    |  1 +
>> >  .../bindings/arm/mediatek/mediatek,mmsys.txt       |  1 +
>> >  .../bindings/arm/mediatek/mediatek,pericfg.txt     |  1 +
>> >  .../bindings/arm/mediatek/mediatek,topckgen.txt    |  1 +
>> >  .../bindings/arm/mediatek/mediatek,vdecsys.txt     |  1 +
>> >  10 files changed, 73 insertions(+)
>> >  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
>> >  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
>> >  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
>> > index 936166f..a701e19 100644
>> > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
>> > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
>> > @@ -6,6 +6,7 @@ The Mediatek apmixedsys controller provides the PLLs to the system.
>> >  Required Properties:
>> >
>> >  - compatible: Should be:
>> > +   - "mediatek,mt2701-apmixedsys"
>> >     - "mediatek,mt8135-apmixedsys"
>> >     - "mediatek,mt8173-apmixedsys"
>> >  - #clock-cells: Must be 1
>> > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
>> > new file mode 100644
>> > index 0000000..4137196
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
>> > @@ -0,0 +1,22 @@
>> > +Mediatek bdpsys controller
>> > +============================
>> > +
>> > +The Mediatek bdpsys controller provides various clocks to the system.
>>
>> As you clarified these blocks provide more that just clocks. Please list
>> all the functions here and on the others.
>
> Some blocks may provide clock and reset controller at the same time. But

Then say the block provides clocks and resets is all I'm asking for.

> most of them will not provide functions directly. Instead, some DT
> blocks which provide specific functions may refer to these controller
> nodes due to it need to access the same register space.
>
> For example, scpsys (the power domain provider) refers to infracfg
> because it need to control infracfg registers when power on/off domains:
>
>         scpsys: scpsys at 10006000 {
>                 compatible = "mediatek,mt2701-scpsys";
>                 #power-domain-cells = <1>;
>                 reg = <0 0x10006000 0 0x1000>;
>                 infracfg = <&infracfg>;
>         };
>
> So I think it should not need to list all functions for each blocks
> here.

Sorry, but you do need to describe what functions the blocks provide.

Also, if you are accessing the infracfg regs directly to modify clock
registers outside of the clock driver, that is very bad design. The
clock driver could assume that register values are not changing behind
its back and it bypasses any locks around register accesses. I can see
why it is needed though, but we really need a proper interface.

Rob


From eric.auger at linaro.org  Mon Feb  1 08:08:26 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Mon, 1 Feb 2016 17:08:26 +0100
Subject: [PATCH V13 09/10] vfio, platform: add support for ACPI while
 detecting the reset driver
In-Reply-To: <1454106914-15857-10-git-send-email-okaya@codeaurora.org>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-10-git-send-email-okaya@codeaurora.org>
Message-ID: <56AF82FA.7000303@linaro.org>

Hi Sinan,
On 01/29/2016 11:35 PM, Sinan Kaya wrote:
> The code is using the compatible DT string to associate a reset driver with
> the actual device itself. The compatible string does not exist on ACPI
> based systems. HID is the unique identifier for a device driver instead.
> The change allows a driver to register with DT compatible string or ACPI
> HID and then match the object with one of these conditions.
> 
> For ACPI systems, ACPI HID needs to match and compat in the registered
> reset
> driver needs to match for ACPI reset driver loading to work.

Don't really get the sentence. For ACPI systems, a registered reset
function is selected if its associated ACPI HID matches the device ACPI HID?
> 
> For OF based systems, DT compatible string needs to match and compat in the
> registered reset driver needs to match for DT reset driver loading to work.
same here

I added Baptiste who is vfio platform driver sub-system maintainer.

On my side I tested with of amd xgbe and I don't observe any regression.

Best Regards

Eric
> 
> Signed-off-by: Sinan Kaya <okaya at codeaurora.org>
> ---
>  .../vfio/platform/reset/vfio_platform_amdxgbe.c    |  3 +-
>  .../platform/reset/vfio_platform_calxedaxgmac.c    |  3 +-
>  drivers/vfio/platform/vfio_platform_common.c       | 80 +++++++++++++++++++---
>  drivers/vfio/platform/vfio_platform_private.h      | 41 ++++++-----
>  4 files changed, 96 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
> index d4030d0..cc5b4fa 100644
> --- a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
> +++ b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
> @@ -119,7 +119,8 @@ int vfio_platform_amdxgbe_reset(struct vfio_platform_device *vdev)
>  	return 0;
>  }
>  
> -module_vfio_reset_handler("amd,xgbe-seattle-v1a", vfio_platform_amdxgbe_reset);
> +module_vfio_reset_handler("amd,xgbe-seattle-v1a", NULL,
> +			  vfio_platform_amdxgbe_reset);
>  
>  MODULE_VERSION("0.1");
>  MODULE_LICENSE("GPL v2");
> diff --git a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
> index e3d3d94..0e57529 100644
> --- a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
> +++ b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
> @@ -77,7 +77,8 @@ int vfio_platform_calxedaxgmac_reset(struct vfio_platform_device *vdev)
>  	return 0;
>  }
>  
> -module_vfio_reset_handler("calxeda,hb-xgmac", vfio_platform_calxedaxgmac_reset);
> +module_vfio_reset_handler("calxeda,hb-xgmac", NULL,
> +			  vfio_platform_calxedaxgmac_reset);
>  
>  MODULE_VERSION(DRIVER_VERSION);
>  MODULE_LICENSE("GPL v2");
> diff --git a/drivers/vfio/platform/vfio_platform_common.c b/drivers/vfio/platform/vfio_platform_common.c
> index 418cdd9..6927e05 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -13,6 +13,7 @@
>   */
>  
>  #include <linux/device.h>
> +#include <linux/acpi.h>
>  #include <linux/iommu.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
> @@ -31,14 +32,22 @@ static LIST_HEAD(reset_list);
>  static DEFINE_MUTEX(driver_lock);
>  
>  static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char *compat,
> -					struct module **module)
> +				  const char *acpihid, struct module **module)
>  {
>  	struct vfio_platform_reset_node *iter;
>  	vfio_platform_reset_fn_t reset_fn = NULL;
>  
>  	mutex_lock(&driver_lock);
>  	list_for_each_entry(iter, &reset_list, link) {
> -		if (!strcmp(iter->compat, compat) &&
> +		if (acpihid && iter->acpihid &&
> +		    !strcmp(iter->acpihid, acpihid) &&
> +			try_module_get(iter->owner)) {
> +			*module = iter->owner;
> +			reset_fn = iter->reset;
> +			break;
> +		}
> +		if (compat && iter->compat &&
> +		    !strcmp(iter->compat, compat) &&
>  			try_module_get(iter->owner)) {
>  			*module = iter->owner;
>  			reset_fn = iter->reset;
> @@ -51,11 +60,12 @@ static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char *compat,
>  
>  static void vfio_platform_get_reset(struct vfio_platform_device *vdev)
>  {
> -	vdev->reset = vfio_platform_lookup_reset(vdev->compat,
> -						&vdev->reset_module);
> +	vdev->reset = vfio_platform_lookup_reset(vdev->compat, vdev->acpihid,
> +						 &vdev->reset_module);
>  	if (!vdev->reset) {
>  		request_module("vfio-reset:%s", vdev->compat);
>  		vdev->reset = vfio_platform_lookup_reset(vdev->compat,
> +							 vdev->acpihid,
>  							 &vdev->reset_module);
>  	}
>  }
> @@ -541,6 +551,46 @@ static const struct vfio_device_ops vfio_platform_ops = {
>  	.mmap		= vfio_platform_mmap,
>  };
>  
> +#ifdef CONFIG_ACPI
> +int vfio_platform_probe_acpi(struct vfio_platform_device *vdev,
> +			     struct device *dev)
> +{
> +	struct acpi_device adev = ACPI_COMPANION(dev);
> +
> +	if (!adev)
> +		return -EINVAL;
> +
> +	vdev->acpihid = acpi_device_hid(adev);
> +	if (!vdev->acpihid) {
> +		pr_err("VFIO: cannot find ACPI HID for %s\n",
> +		       vdev->name);
> +		return -EINVAL;
> +	}
> +	return 0;
> +}
> +#else
> +int vfio_platform_probe_acpi(struct vfio_platform_device *vdev,
> +			     struct device *dev)
> +{
> +	return -EINVAL;
> +}
> +#endif
> +
> +int vfio_platform_probe_of(struct vfio_platform_device *vdev,
> +			   struct device *dev)
> +{
> +	int ret;
> +
> +	ret = device_property_read_string(dev, "compatible",
> +					  &vdev->compat);
> +	if (ret) {
> +		pr_err("VFIO: cannot retrieve compat for %s\n",
> +			vdev->name);
> +		return -EINVAL;
> +	}
> +	return 0;
> +}
> +
>  int vfio_platform_probe_common(struct vfio_platform_device *vdev,
>  			       struct device *dev)
>  {
> @@ -550,14 +600,14 @@ int vfio_platform_probe_common(struct vfio_platform_device *vdev,
>  	if (!vdev)
>  		return -EINVAL;
>  
> -	ret = device_property_read_string(dev, "compatible", &vdev->compat);
> -	if (ret) {
> -		pr_err("VFIO: cannot retrieve compat for %s\n", vdev->name);
> -		return -EINVAL;
> -	}
> +	ret = vfio_platform_probe_acpi(vdev, dev);
> +	if (ret)
> +		ret = vfio_platform_probe_of(vdev, dev);
>  
> -	vdev->device = dev;
> +	if (ret)
> +		return ret;
>  
> +	vdev->device = dev;
>  	group = iommu_group_get(dev);
>  	if (!group) {
>  		pr_err("VFIO: No IOMMU group for device %s\n", vdev->name);
> @@ -602,13 +652,21 @@ void __vfio_platform_register_reset(struct vfio_platform_reset_node *node)
>  EXPORT_SYMBOL_GPL(__vfio_platform_register_reset);
>  
>  void vfio_platform_unregister_reset(const char *compat,
> +				    const char *acpihid,
>  				    vfio_platform_reset_fn_t fn)
>  {
>  	struct vfio_platform_reset_node *iter, *temp;
>  
>  	mutex_lock(&driver_lock);
>  	list_for_each_entry_safe(iter, temp, &reset_list, link) {
> -		if (!strcmp(iter->compat, compat) && (iter->reset == fn)) {
> +		if (acpihid && iter->acpihid &&
> +		    !strcmp(iter->acpihid, acpihid) && (iter->reset == fn)) {
> +			list_del(&iter->link);
> +			break;
> +		}
> +
> +		if (compat && iter->compat &&
> +		    !strcmp(iter->compat, compat) && (iter->reset == fn)) {
>  			list_del(&iter->link);
>  			break;
>  		}
> diff --git a/drivers/vfio/platform/vfio_platform_private.h b/drivers/vfio/platform/vfio_platform_private.h
> index 42816dd..32feba3 100644
> --- a/drivers/vfio/platform/vfio_platform_private.h
> +++ b/drivers/vfio/platform/vfio_platform_private.h
> @@ -58,6 +58,7 @@ struct vfio_platform_device {
>  	struct mutex			igate;
>  	struct module			*parent_module;
>  	const char			*compat;
> +	const char			*acpihid;
>  	struct module			*reset_module;
>  	struct device			*device;
>  
> @@ -79,6 +80,7 @@ typedef int (*vfio_platform_reset_fn_t)(struct vfio_platform_device *vdev);
>  struct vfio_platform_reset_node {
>  	struct list_head link;
>  	char *compat;
> +	char *acpihid;
>  	struct module *owner;
>  	vfio_platform_reset_fn_t reset;
>  };
> @@ -98,27 +100,30 @@ extern int vfio_platform_set_irqs_ioctl(struct vfio_platform_device *vdev,
>  
>  extern void __vfio_platform_register_reset(struct vfio_platform_reset_node *n);
>  extern void vfio_platform_unregister_reset(const char *compat,
> +					   const char *acpihid,
>  					   vfio_platform_reset_fn_t fn);
> -#define vfio_platform_register_reset(__compat, __reset)		\
> -static struct vfio_platform_reset_node __reset ## _node = {	\
> -	.owner = THIS_MODULE,					\
> -	.compat = __compat,					\
> -	.reset = __reset,					\
> -};								\
> +
> +#define vfio_platform_register_reset(__compat, __acpihid, __reset)	\
> +static struct vfio_platform_reset_node __reset ## _node = {		\
> +	.owner = THIS_MODULE,						\
> +	.compat = __compat,						\
> +	.acpihid = __acpihid,						\
> +	.reset = __reset,						\
> +};									\
>  __vfio_platform_register_reset(&__reset ## _node)
>  
> -#define module_vfio_reset_handler(compat, reset)		\
> -MODULE_ALIAS("vfio-reset:" compat);				\
> -static int __init reset ## _module_init(void)			\
> -{								\
> -	vfio_platform_register_reset(compat, reset);		\
> -	return 0;						\
> -};								\
> -static void __exit reset ## _module_exit(void)			\
> -{								\
> -	vfio_platform_unregister_reset(compat, reset);		\
> -};								\
> -module_init(reset ## _module_init);				\
> +#define module_vfio_reset_handler(compat, acpihid, reset)		\
> +MODULE_ALIAS("vfio-reset:" compat);					\
> +static int __init reset ## _module_init(void)				\
> +{									\
> +	vfio_platform_register_reset(compat, acpihid, reset);		\
> +	return 0;							\
> +};									\
> +static void __exit reset ## _module_exit(void)				\
> +{									\
> +	vfio_platform_unregister_reset(compat, acpihid, reset);		\
> +};									\
> +module_init(reset ## _module_init);					\
>  module_exit(reset ## _module_exit)
>  
>  #endif /* VFIO_PLATFORM_PRIVATE_H */
> 



From arnd at arndb.de  Mon Feb  1 08:13:44 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 01 Feb 2016 17:13:44 +0100
Subject: [PATCH] staging: goldfish: use div64_s64 instead of do_div
In-Reply-To: <20160201145457.7879d53f@lxorguk.ukuu.org.uk>
References: <1676170.0qik6mzm6D@wuerfel>
 <20160201145457.7879d53f@lxorguk.ukuu.org.uk>
Message-ID: <2123401.bK87U6BMYJ@wuerfel>

On Monday 01 February 2016 14:54:57 One Thousand Gnomes wrote:
> On Mon, 01 Feb 2016 11:33 +0100
> Arnd Bergmann <arnd at arndb.de> wrote:
> 
> > The goldfish nand driver divides a signed 64-bit number (loff_t)
> > in multiple places using the do_div() function. This has always
> > been unreliable but now produces a compiler warning (since 4.5-rc1):
> > 
> > goldfish/goldfish_nand.c: In function 'goldfish_nand_erase':
> > goldfish/goldfish_nand.c:107:91: error: comparison of distinct pointer types lacks a cast [-Werror]
> > goldfish/goldfish_nand.c: In function 'goldfish_nand_read_oob':
> > goldfish/goldfish_nand.c:145:91: error: comparison of distinct pointer types lacks a cast [-Werror]
> > 
> > This changes the code to the equivalent div_s64{,_rem} that
> > works correctly for negative numbers (which we should never
> > get here).
> 
> We can't get negatives as you say so surely the right fix is a cast or to
> fix mtd->writesize ?

A cast won't work because the first argument to the do_div() macro is
both input and output.

It's not the mtd->writesize argument that is the problem here, but the
'ofs' argument that comes from the loff_t argument in mtdchar_read()
and others (ultimately from the lseek/pread/pwrite/...)

We could change all the function prototypes in struct mtd_info to use
u64 instead of loff_t, but that involve change all MTD drivers and the
subsystem.

	Arnd


From holgerschurig at gmail.com  Mon Feb  1 08:14:09 2016
From: holgerschurig at gmail.com (Holger Schurig)
Date: Mon, 01 Feb 2016 17:14:09 +0100
Subject: [4.4, OOPS]: kernel oops around __wake_up_common / __sys_recvmsg
Message-ID: <87h9hsl86m.fsf@gmail.com>

Hi all,

I (still) have a problem with 4.4.0 having lookups and oopsing. This
happens not instantly: when I run some test program *) on 10 machines, at
the next morning 6-8 have this issue.

Via the serial port I catch the output of "journalctl -f" and get this:

...
06:35:01 CRON[27050]: pam_unix(cron:session): session closed for user root
Unable to handle kernel paging request at virtual address fffffffe
pgd = ee2f4000
[fffffffe] *pgd=3fffd861, *pte=00000000, *ppte=00000000
Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
Modules linked in: bnep smsc95xx usbnet mii btusb btrtl btbcm btintel bluetooth imx_sdma flexcan dlog(O)
CPU: 3 PID: 331 Comm: Xorg Tainted: G           O    4.4.0 #1
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: ee12e3c0 ti: ed996000 task.ti: ed996000
PC is at 0xfffffffe
LR is at __wake_up_common+0x50/0x7c
pc : [<fffffffe>]    lr : [<c0050258>]    psr: 200100b3
sp : ed997c68  ip : ffffffff  fp : ed997c8c
r10: 00000000  r9 : c0037a38  r8 : 00000001
r7 : 00000001  r6 : 00000001  r5 : ee09ad44  r4 : fffffff3
r3 : 00000304  r2 : 00000001  r1 : 00000001  r0 : ee15fd18
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA Thumb  Segment none
Control: 10c5387d  Table: 3e2f404a  DAC: 00000051
Process Xorg (pid: 331, stack limit = 0xed996210)
Stack: (0xed997c68 to 0xed998000)
7c60:                   ee09ad40 a0010013 00000001 00000001 00000304 00000010
7c80: ed997cbc ed997c90 c005084c c0050214 00000304 80150011 c00cfb18 eea1d900
7ca0: eea1d9ac eea1d5e4 ee0d2600 ed997df4 ed997cd4 ed997cc0 c03cd0dc c005080c
7cc0: c03cd05c eea1d900 ed997cec ed997cd8 c0344e08 c03cd068 ee0d2600 ffffffa1
7ce0: ed997d1c ed997cf0 c03cc9b8 c0344dc8 00000010 00000000 00000000 00000000
7d00: 00000000 00000000 c034c4a8 ee0d2600 ed997d34 ed997d20 c0345ed0 c03cc958
7d20: 00000001 ee0d2600 ed997d4c ed997d38 c0346004 c0345e6c 00000001 eea1d400
7d40: ed997d5c ed997d50 c0346174 c0345ffc ed997dec ed997d60 c03cdbc0 c0346128
7d60: ed997d8c ed997d70 c0042bc0 00000010 00000000 00000000 eea1d5bc ecda7b00
7d80: 00000000 eea1d464 00000001 00000000 00000ff0 00000010 00000000 00000000
7da0: 00000000 00000000 00000000 00000000 00000008 c00c06a4 00000008 ed997f54
7dc0: ed997e40 00000040 00001000 ed997f4c ecda7b00 bed92988 ed997e88 ecda7b00
7de0: ed997e2c ed997df0 c03cde00 c03cd60c ed997f54 c03cc7d8 ecda7b00 ed997f4c
7e00: 00000000 00001000 00000040 00000000 ecda7b00 ed997f4c bed9296c 00000040
7e20: ed997e3c ed997e30 c033ea58 c03cddbc ed997f34 ed997e40 c0340774 c033ea4c
7e40: 00000000 00000000 8013c508 00001000 ef7ceb54 ef7cebf8 ed997e94 ed997e68
7e60: c0072fd4 c0014e98 291b24af 0000e16e ed997ebc ef7d43c0 00000000 294a9002
7e80: 0000e16e ef7cebb8 ed997ebc ed997e98 c0074eb8 c0072eac 00000000 ffffffff
7ea0: ffffffff 7fffffff ef7ceb40 ef7cebd8 ed997f14 ed997ec0 c006801c c0074e40
7ec0: ef7cebf8 c0550b40 294a9002 0000e16e 291adbc5 0000e16e 00000003 00000000
7ee0: 294a9002 0000e16e 00000040 00000001 ef005c00 c0563600 ef01ecc0 00000010
7f00: ed997f1c ed997f10 c00d8ae0 ecda7b00 00000000 bed9296c 00000129 c000f2e4
7f20: ed996000 00000000 ed997f94 ed997f38 c03414f8 c03406e8 00000000 7f6d0348
7f40: 00000107 00000000 fffffff7 00000000 00000000 00000000 00000010 00000ff0
7f60: ed997e48 00000001 bed92988 0000020c 00000000 00000000 00000008 bed92988
7f80: 8013b3f0 b6f42f10 ed997fa4 ed997f98 c034152c c03414c0 00000000 ed997fa8
7fa0: c000f120 c0341528 bed92988 8013b3f0 0000000b bed9296c 00000000 cedd7c00
7fc0: bed92988 8013b3f0 b6f42f10 00000129 bed9296c 00001000 8013c508 00000000
7fe0: 00000000 bed92954 7f685a79 b6c2dbd6 60010030 0000000b 3fffd861 3fffdc61
Backtrace:
[<c0050208>] (__wake_up_common) from [<c005084c>] (__wake_up_sync_key+0x4c/0x60)
 r9:00000010 r8:00000304 r7:00000001 r6:00000001 r5:a0010013 r4:ee09ad40
[<c0050800>] (__wake_up_sync_key) from [<c03cd0dc>] (unix_write_space+0x80/0x88)
 r8:ed997df4 r7:ee0d2600 r6:eea1d5e4 r5:eea1d9ac r4:eea1d900
[<c03cd05c>] (unix_write_space) from [<c0344e08>] (sock_wfree+0x4c/0x84)
 r4:eea1d900 r3:c03cd05c
[<c0344dbc>] (sock_wfree) from [<c03cc9b8>] (unix_destruct_scm+0x6c/0x74)
 r5:ffffffa1 r4:ee0d2600
[<c03cc94c>] (unix_destruct_scm) from [<c0345ed0>] (skb_release_head_state+0x70/0xb0)
 r4:ee0d2600
[<c0345e60>] (skb_release_head_state) from [<c0346004>] (__kfree_skb+0x14/0xa8)
 r4:ee0d2600 r3:00000001
[<c0345ff0>] (__kfree_skb) from [<c0346174>] (consume_skb+0x58/0x5c)
 r4:eea1d400 r3:00000001
[<c034611c>] (consume_skb) from [<c03cdbc0>] (unix_stream_read_generic+0x5c0/0x720)
[<c03cd600>] (unix_stream_read_generic) from [<c03cde00>] (unix_stream_recvmsg+0x50/0x5c)
 r10:ecda7b00 r9:ed997e88 r8:bed92988 r7:ecda7b00 r6:ed997f4c r5:00001000
 r4:00000040
[<c03cddb0>] (unix_stream_recvmsg) from [<c033ea58>] (sock_recvmsg+0x18/0x1c)
 r7:00000040 r6:bed9296c r5:ed997f4c r4:ecda7b00
[<c033ea40>] (sock_recvmsg) from [<c0340774>] (___sys_recvmsg+0x98/0x16c)
[<c03406dc>] (___sys_recvmsg) from [<c03414f8>] (__sys_recvmsg+0x44/0x68)
 r10:00000000 r9:ed996000 r8:c000f2e4 r7:00000129 r6:bed9296c r5:00000000
 r4:ecda7b00
[<c03414b4>] (__sys_recvmsg) from [<c034152c>] (SyS_recvmsg+0x10/0x14)
 r6:b6f42f10 r5:8013b3f0 r4:bed92988
[<c034151c>] (SyS_recvmsg) from [<c000f120>] (ret_fast_syscall+0x0/0x3c)
Code: bad PC value
---[ end trace 2c00262b7dd79d60 ]---
note: Xorg[331] exited with preempt_count 1



And here another trace:



...
22:45:01 CRON[7728]: pam_unix(cron:session): session closed for user root
Unable to handle kernel paging request at virtual address fffffffe
pgd = ee230000
[fffffffe] *pgd=3fffd861, *pte=00000000, *ppte=00000000
Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
Modules linked in: bnep btusb btrtl btbcm btintel bluetooth smsc95xx usbnet mii imx_sdma flexcan dlog(O)
CPU: 3 PID: 331 Comm: Xorg Tainted: G           O    4.4.0 #1
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: ee951f80 ti: ee1a8000 task.ti: ee1a8000
PC is at 0xfffffffe
LR is at __wake_up_common+0x50/0x7c
pc : [<fffffffe>]    lr : [<c0050258>]    psr: 200300b3
sp : ee1a9c68  ip : ffffffff  fp : ee1a9c8c
r10: 00000000  r9 : c0037a38  r8 : 00000001
r7 : 00000001  r6 : 00000001  r5 : e6aa8004  r4 : fffffff3
r3 : 00000304  r2 : 00000001  r1 : 00000001  r0 : eea3fd18
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA Thumb  Segment none
Control: 10c5387d  Table: 3e23004a  DAC: 00000051
Process Xorg (pid: 331, stack limit = 0xee1a8210)
Stack: (0xee1a9c68 to 0xee1aa000)
9c60:                   e6aa8000 a0030013 00000001 00000001 00000304 0000004c
9c80: ee1a9cbc ee1a9c90 c005084c c0050214 00000304 ee1a9b8c c00cfb18 ee93b980
9ca0: ee93ba2c ee93a764 ee1ba6c0 ee1a9df4 ee1a9cd4 ee1a9cc0 c03cd0dc c005080c
9cc0: c03cd05c ee93b980 ee1a9cec ee1a9cd8 c0344e08 c03cd068 ee1ba6c0 ffffffa1
9ce0: ee1a9d1c ee1a9cf0 c03cc9b8 c0344dc8 0000004c 00000000 00000000 00000000
9d00: 00000000 00000000 c034c4a8 ee1ba6c0 ee1a9d34 ee1a9d20 c0345ed0 c03cc958
9d20: 00000001 ee1ba6c0 ee1a9d4c ee1a9d38 c0346004 c0345e6c 00000001 ee93a580
9d40: ee1a9d5c ee1a9d50 c0346174 c0345ffc ee1a9dec ee1a9d60 c03cdbc0 c0346128
9d60: c006c6a8 c0301f64 ee1a9d9c 0000004c 00000000 00000000 ee93a73c ecc51800
9d80: 00000000 ee93a5e4 00000001 00000000 00000fb4 0000004c 00000000 00000000
9da0: 00000000 00000000 00000000 00000000 00000008 c00c06a4 00000008 ee1a9f54
9dc0: ee1a9e40 00000040 00001000 ee1a9f4c ecc51800 be9f9988 ee1a9e88 ecc51800
9de0: ee1a9e2c ee1a9df0 c03cde00 c03cd60c ee1a9f54 c03cc7d8 ecc51800 ee1a9f4c
9e00: 00000000 00001000 00000040 00000000 ecc51800 ee1a9f4c be9f996c 00000040
9e20: ee1a9e3c ee1a9e30 c033ea58 c03cddbc ee1a9f34 ee1a9e40 c0340774 c033ea4c
9e40: 00000000 00000000 80cfa710 00001000 ee1a9e7c ee1a9e60 c0028328 c002778c
9e60: 00000000 ee1a8000 ee951f80 00000504 ee1a9e9c ee1a9e80 c002a3d0 c03e7790
9e80: 00002000 ee1a9ed0 00000000 ee1a9fb0 ee1a9eac ee1a9ea0 c002a3f4 c002a394
9ea0: ee1a9ecc ee1a9eb0 c002a4b4 c002a3e0 00002000 00000000 00000000 be9f95e8
9ec0: ee1a9f8c ee1a9ed0 c00120b0 c002a404 7f69dc39 04000000 b6c22ac1 00002000
9ee0: 00000000 0000000e 00000000 00000080 00000000 00000000 ee1a9f14 ee1a9f08
9f00: ee1a9f1c ee1a9f10 c00d8ae0 ecc51800 00000000 be9f996c 00000129 c000f2e4
9f20: ee1a8000 00000000 ee1a9f94 ee1a9f38 c03414f8 c03406e8 00000000 7f6eb348
9f40: 00000107 00000000 fffffff7 00000000 00000000 00000000 0000004c 00000fb4
9f60: ee1a9e48 00000001 be9f9988 0000020c 00000000 00000000 00000008 be9f9988
9f80: 80cf9d90 b6fa4f10 ee1a9fa4 ee1a9f98 c034152c c03414c0 00000000 ee1a9fa8
9fa0: c000f120 c0341528 be9f9988 80cf9d90 0000000b be9f996c 00000000 2555f400
9fc0: be9f9988 80cf9d90 b6fa4f10 00000129 be9f996c 00001000 80cfa710 00000000
9fe0: 00000000 be9f9954 7f6a0a79 b6c8fbd6 60030030 0000000b 00000000 00000000
Backtrace:
[<c0050208>] (__wake_up_common) from [<c005084c>] (__wake_up_sync_key+0x4c/0x60)
 r9:0000004c r8:00000304 r7:00000001 r6:00000001 r5:a0030013 r4:e6aa8000
[<c0050800>] (__wake_up_sync_key) from [<c03cd0dc>] (unix_write_space+0x80/0x88)
 r8:ee1a9df4 r7:ee1ba6c0 r6:ee93a764 r5:ee93ba2c r4:ee93b980
[<c03cd05c>] (unix_write_space) from [<c0344e08>] (sock_wfree+0x4c/0x84)
 r4:ee93b980 r3:c03cd05c
[<c0344dbc>] (sock_wfree) from [<c03cc9b8>] (unix_destruct_scm+0x6c/0x74)
 r5:ffffffa1 r4:ee1ba6c0
[<c03cc94c>] (unix_destruct_scm) from [<c0345ed0>] (skb_release_head_state+0x70/0xb0)
 r4:ee1ba6c0
[<c0345e60>] (skb_release_head_state) from [<c0346004>] (__kfree_skb+0x14/0xa8)
 r4:ee1ba6c0 r3:00000001
[<c0345ff0>] (__kfree_skb) from [<c0346174>] (consume_skb+0x58/0x5c)
 r4:ee93a580 r3:00000001
[<c034611c>] (consume_skb) from [<c03cdbc0>] (unix_stream_read_generic+0x5c0/0x720)
[<c03cd600>] (unix_stream_read_generic) from [<c03cde00>] (unix_stream_recvmsg+0x50/0x5c)
 r10:ecc51800 r9:ee1a9e88 r8:be9f9988 r7:ecc51800 r6:ee1a9f4c r5:00001000
 r4:00000040
[<c03cddb0>] (unix_stream_recvmsg) from [<c033ea58>] (sock_recvmsg+0x18/0x1c)
 r7:00000040 r6:be9f996c r5:ee1a9f4c r4:ecc51800
[<c033ea40>] (sock_recvmsg) from [<c0340774>] (___sys_recvmsg+0x98/0x16c)
[<c03406dc>] (___sys_recvmsg) from [<c03414f8>] (__sys_recvmsg+0x44/0x68)
 r10:00000000 r9:ee1a8000 r8:c000f2e4 r7:00000129 r6:be9f996c r5:00000000
 r4:ecc51800
[<c03414b4>] (__sys_recvmsg) from [<c034152c>] (SyS_recvmsg+0x10/0x14)
 r6:b6fa4f10 r5:80cf9d90 r4:be9f9988
[<c034151c>] (SyS_recvmsg) from [<c000f120>] (ret_fast_syscall+0x0/0x3c)
Code: bad PC value
---[ end trace 485ed1c9f6b0294a ]---



Here's the disassembly of __wake_up_common, but I can't really see
what's going on:

c0050208 <__wake_up_common>:
c0050208:       e1a0c00d        mov     ip, sp
c005020c:       e92ddbf0        push    {r4, r5, r6, r7, r8, r9, fp, ip, lr, pc}
c0050210:       e24cb004        sub     fp, ip, #4
c0050214:       e1a05000        mov     r5, r0
c0050218:       e1a07001        mov     r7, r1
c005021c:       e5b5c004        ldr     ip, [r5, #4]!
c0050220:       e1a06002        mov     r6, r2
c0050224:       e1a08003        mov     r8, r3
c0050228:       e24c000c        sub     r0, ip, #12
c005022c:       e59c4000        ldr     r4, [ip]
c0050230:       e244400c        sub     r4, r4, #12
c0050234:       e280c00c        add     ip, r0, #12
c0050238:       e15c0005        cmp     ip, r5
c005023c:       0a00000f        beq     c0050280 <__wake_up_common+0x78>
c0050240:       e590c008        ldr     ip, [r0, #8]
c0050244:       e1a01007        mov     r1, r7
c0050248:       e1a02008        mov     r2, r8
c005024c:       e59b3004        ldr     r3, [fp, #4]
c0050250:       e5909000        ldr     r9, [r0]
c0050254:       e12fff3c        blx     ip
c0050258:       e3500000        cmp     r0, #0
c005025c:       0a000003        beq     c0050270 <__wake_up_common+0x68>
c0050260:       e3190001        tst     r9, #1
c0050264:       0a000001        beq     c0050270 <__wake_up_common+0x68>
c0050268:       e2566001        subs    r6, r6, #1
c005026c:       089dabf0        ldmeq   sp, {r4, r5, r6, r7, r8, r9, fp, sp, pc}
c0050270:       e594300c        ldr     r3, [r4, #12]
c0050274:       e1a00004        mov     r0, r4
c0050278:       e243400c        sub     r4, r3, #12
c005027c:       eaffffec        b       c0050234 <__wake_up_common+0x2c>
c0050280:       e89dabf0        ldm     sp, {r4, r5, r6, r7, r8, r9, fp, sp, pc}



The work load is some Java program that sends and receives via Ethernet
(i.MX6 FEC driver), CAN (i.MX6Q flexcan driver) and does some other test
load, e.g. starting and killing user-space threads.





From jassisinghbrar at gmail.com  Mon Feb  1 08:16:39 2016
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Mon, 1 Feb 2016 21:46:39 +0530
Subject: [PATCH v5 1/4] dt-bindings: mailbox: Document Hi6220 mailbox
 driver
In-Reply-To: <20160201152333.GA22872@leoy-linaro>
References: <1454333687-20421-1-git-send-email-leo.yan@linaro.org>
 <1454333687-20421-2-git-send-email-leo.yan@linaro.org>
 <20160201140828.GA32412@rob-hp-laptop>
 <20160201152333.GA22872@leoy-linaro>
Message-ID: <CABb+yY0uY--40CJ6_U-AcbZ1cRUhs7MhiJZn_G-Suw=XKXdpjg@mail.gmail.com>

On Mon, Feb 1, 2016 at 8:53 PM, Leo Yan <leo.yan at linaro.org> wrote:
> Hi Rob,
>
> Thanks for reviewing, please see below inline comments.
>
> On Mon, Feb 01, 2016 at 08:08:28AM -0600, Rob Herring wrote:
>> On Mon, Feb 01, 2016 at 09:34:44PM +0800, Leo Yan wrote:
>> > Document DT binding for Hisilicon Hi6220 mailbox driver.
>> >
>> > Signed-off-by: Leo Yan <leo.yan at linaro.org>
>> > ---
>> >  .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  | 90 ++++++++++++++++++++++
>> >  1 file changed, 90 insertions(+)
>> >  create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
>> > new file mode 100644
>> > index 0000000..96e6acc
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
>> > @@ -0,0 +1,90 @@
>> > +Hisilicon Hi6220 Mailbox Driver
>> > +===============================
>> > +
>> > +Hisilicon Hi6220 mailbox supports up to 32 channels. Each channel
>> > +is unidirectional with a maximum message size of 8 words. I/O is
>> > +performed using register access (there is no DMA) and the cell
>> > +raises an interrupt when messages are received.
>> > +
>> > +Mailbox Device Node:
>> > +====================
>> > +
>> > +Required properties:
>> > +--------------------
>> > +- compatible:              Shall be "hisilicon,hi6220-mbox"
>> > +- reg:                     Contains the mailbox register address range (base
>> > +                   address and length); the first item is for IPC
>> > +                   registers, the second item is shared buffer for
>> > +                   slots.
>> > +- #mbox-cells              Common mailbox binding property to identify the number
>> > +                   of cells required for the mailbox specifier. Should be 1.
>> > +- interrupts:              Contains the interrupt information for the mailbox
>> > +                   device. The format is dependent on which interrupt
>> > +                   controller the SoCs use.
>> > +
>> > +Optional Properties:
>> > +--------------------
>> > +- hi6220,mbox-tx-noirq: Flag to allow the client user of this mailbox driver
>> > +                   to send messages without triggering a TX completion
>> > +                   interrupt.
>>
>> I don't think this belongs in DT. This should be a flag the client
>> driver sets when it sends messages.
>
> The client driver can set "tx_block = true" so use this flag indicates
> the client thread should be blocked until data is transmitted.
>
Yes, but the 'tx_block' feature is provided by the core. The
controller driver should not need to know how the client works.

> But low level mailbox driver can use two method to support "tx_block"
> mode:
>
No, as I said, provider shouldn't care about consumers..

> - One method is to avoid using interrupt and mailbox framework will
>   poll with mailbox's idle flag which is set by remote processor
>   automatically;
> - Another method is to use interrupt to notify data has been
>   transmitted and interrupt handler will call completion function to
>   wake up blocked client thread;
>
If it is possible to have either 'idle flag set' or irq generated (not
both) by the remote, then you may sell the hi6220,mbox-tx-noirq
property as a "f/w feature" ... but still not for the sake of
tx_block.


>> > +
>> > +Child Nodes:
>> > +============
>> > +A child node is used for representing the actual sub-mailbox device that is
>> > +used for the communication between the host processor and a remote processor.
>> > +Each child node should have a unique node name across all the different
>> > +mailbox device nodes.
>> > +
>> > +Required properties:
>> > +--------------------
>> > +- hi6220,mbox-tx:  sub-mailbox descriptor property defining Tx channel
>> > +- hi6220,mbox-rx:  sub-mailbox descriptor property defining Rx channel
>> > +
>> > +Sub-mailbox Descriptor Data
>> > +---------------------------
>> > +Each of the above hi6220,mbox-tx and hi6220,mbox-rx properties should have 3
>> > +cells of data that represent the following:
>> > +    Cell #1 (slot_id) - mailbox slot id used either for transmitting
>> > +                        (hi6220,mbox-tx) or for receiving (hi6220,mbox-rx)
>> > +    Cell #2 (dst_irq) - irq identifier index number which used by MCU.
>> > +    Cell #3 (ack_irq) - irq identifier index number with generating a tx/rx
>> > +                        interrupt to application processor, mailbox driver
>> > +                        used this id to acknowledge interrupt.
>> > +
>> > +Example:
>> > +--------
>> > +
>> > +   mailbox: mailbox at F7510000 {
>> > +           #mbox-cells = <1>;
>> > +           compatible = "hisilicon,hi6220-mbox";
>> > +           reg = <0x0 0xF7510000 0x0 0x1000>, /* IPC_S */
>> > +                 <0x0 0x06DFF800 0x0 0x0800>; /* Mailbox */
>> > +           interrupt-parent = <&gic>;
>> > +           interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
>> > +           mbox_stub_clock: mbox_stub_clock {
>> > +                   hi6220,mbox-rx = <0 1 10>;
>> > +                   hi6220,mbox-tx = <1 0 11>;
>
This looks like meant for the client node...
         mbox-names = "mbox-tx", "mbox-rx";
         mboxes = <&mailbox 1 0 11>, <&mailbox 0 1 10>;


From okaya at codeaurora.org  Mon Feb  1 08:16:52 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Mon, 1 Feb 2016 11:16:52 -0500
Subject: [PATCH V13 09/10] vfio, platform: add support for ACPI while
 detecting the reset driver
In-Reply-To: <56AF82FA.7000303@linaro.org>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-10-git-send-email-okaya@codeaurora.org>
 <56AF82FA.7000303@linaro.org>
Message-ID: <56AF84F4.2080809@codeaurora.org>

On 2/1/2016 11:08 AM, Eric Auger wrote:
>> For ACPI systems, ACPI HID needs to match and compat in the registered
>> > reset
>> > driver needs to match for ACPI reset driver loading to work.
> Don't really get the sentence. For ACPI systems, a registered reset
> function is selected if its associated ACPI HID matches the device ACPI HID?

Old commit message. I did an internal review before posting the patch. The first
version of the patch was a hack. I simplified the code but forgot to update the 
commit message.

Now, the rule is simple.

- ACPI HID needs match for ACPI systems
- DT compat needs to match for OF systems

as expected. I'll rephrase for the next version.

>> > 
>> > For OF based systems, DT compatible string needs to match and compat in the
>> > registered reset driver needs to match for DT reset driver loading to work.
> same here
> 
> I added Baptiste who is vfio platform driver sub-system maintainer.

Thanks, we should ask Baptiste to get his email into the Maintainer file list.

> 
> On my side I tested with of amd xgbe and I don't observe any regression.
> 
> Best Regards

Can I add your tested by?

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


From arnd at arndb.de  Mon Feb  1 08:18:41 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 01 Feb 2016 17:18:41 +0100
Subject: [PATCH] usb: xhci: fix build error for USB_SPEED_SUPER_PLUS
Message-ID: <1508874.HIZbDSzAVR@wuerfel>

A recent patch introduced support for superspeed plus (USB3.1), but that
caused a new gcc warning in the XHCI code:

usb/host/xhci.c: In function 'xhci_drop_ep_from_interval_table':
usb/host/xhci.c:2440:2: error: enumeration value 'USB_SPEED_SUPER_PLUS' not handled in switch [-Werror=switch]

This changes the XHCI driver to handle USB_SPEED_SUPER_PLUS the
same way as USB_SPEED_SUPER in the xhci_drop_ep_from_interval_table
and xhci_add_ep_to_interval_table functions, explicitly ignoring
it.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 8a1b2725a60d ("usb: define USB_SPEED_SUPER_PLUS speed for SuperSpeedPlus USB3.1 devices")
---
Found on ARM randconfig builds last week

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 26a44c0e969e..a74beec879b4 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2448,6 +2448,7 @@ void xhci_drop_ep_from_interval_table(struct xhci_hcd *xhci,
 		interval_bw->overhead[HS_OVERHEAD_TYPE] -= 1;
 		break;
 	case USB_SPEED_SUPER:
+	case USB_SPEED_SUPER_PLUS:
 	case USB_SPEED_UNKNOWN:
 	case USB_SPEED_WIRELESS:
 		/* Should never happen because only LS/FS/HS endpoints will get
@@ -2507,6 +2508,7 @@ static void xhci_add_ep_to_interval_table(struct xhci_hcd *xhci,
 		interval_bw->overhead[HS_OVERHEAD_TYPE] += 1;
 		break;
 	case USB_SPEED_SUPER:
+	case USB_SPEED_SUPER_PLUS:
 	case USB_SPEED_UNKNOWN:
 	case USB_SPEED_WIRELESS:
 		/* Should never happen because only LS/FS/HS endpoints will get



From holgerschurig at gmail.com  Mon Feb  1 08:19:16 2016
From: holgerschurig at gmail.com (Holger Schurig)
Date: Mon, 01 Feb 2016 17:19:16 +0100
Subject: weird RCU problem with 4.4.0
Message-ID: <87d1sgl7y3.fsf@gmail.com>

Hi,

in the dmesg log (actually "journalctl -f") of one of my machines I had this:

...
03:25:01 CRON[16607]: pam_unix(cron:session): session closed for user root
INFO: rcu_preempt detected stalls on CPUs/tasks:
    1-...: (1 GPs behind) idle=763/140000000000000/0 softirq=6109762/6109762 fqs=301
    2-...: (1 GPs behind) idle=2f3/140000000000000/0 softirq=5129036/5129037 fqs=301
    (detected by 0, t=303 jiffies, g=2533688, c=2533687, q=4860)
INFO: rcu_preempt detected stalls on CPUs/tasks:
    1-...: (1 GPs behind) idle=763/140000000000000/0 softirq=6109762/6109762 fqs=1204
    2-...: (1 GPs behind) idle=2f3/140000000000000/0 softirq=5129036/5129037 fqs=1205
    (detected by 0, t=1208 jiffies, g=2533688, c=2533687, q=19822)
INFO: rcu_preempt detected stalls on CPUs/tasks:
    1-...: (1 GPs behind) idle=763/140000000000000/0 softirq=6109762/6109762 fqs=2109
    2-...: (1 GPs behind) idle=2f3/140000000000000/0 softirq=5129036/5129037 fqs=2109
    (detected by 0, t=2113 jiffies, g=2533688, c=2533687, q=34248)
INFO: rcu_preempt detected stalls on CPUs/tasks:
    1-...: (1 GPs behind) idle=763/140000000000000/0 softirq=6109762/6109762 fqs=3011
    2-...: (1 GPs behind) idle=2f3/140000000000000/0 softirq=5129036/5129037 fqs=3011
    (detected by 0, t=3018 jiffies, g=2533688, c=2533687, q=48662)
INFO: rcu_preempt detected stalls on CPUs/tasks:
    1-...: (1 GPs behind) idle=763/140000000000000/0 softirq=6109762/6109762 fqs=3912
    2-...: (1 GPs behind) idle=2f3/140000000000000/0 softirq=5129036/5129037 fqs=3912
    (detected by 0, t=3923 jiffies, g=2533688, c=2533687, q=63080)
INFO: rcu_preempt detected stalls on CPUs/tasks:
    1-...: (1 GPs behind) idle=763/140000000000000/0 softirq=6109762/6109762 fqs=4815
    2-...: (1 GPs behind) idle=2f3/140000000000000/0 softirq=5129036/5129037 fqs=4815
    (detected by 0, t=4828 jiffies, g=2533688, c=2533687, q=68037)
...
and so on, and so forth ...
...
INFO: rcu_preempt detected stalls on CPUs/tasks:
    1-...: (1 GPs behind) idle=763/140000000000000/0 softirq=6109762/6109762 fqs=137745
    2-...: (1 GPs behind) idle=2f3/140000000000000/0 softirq=5129036/5129037 fqs=137746
    (detected by 0, t=137863 jiffies, g=2533688, c=2533687, q=68849)
INFO: rcu_preempt detected stalls on CPUs/tasks:
    1-...: (1 GPs behind) idle=763/140000000000000/0 softirq=6109762/6109762 fqs=138651
    2-...: (1 GPs behind) idle=2f3/140000000000000/0 softirq=5129036/5129037 fqs=138652


From marc.zyngier at arm.com  Mon Feb  1 08:20:40 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 1 Feb 2016 16:20:40 +0000
Subject: [PATCH v2 06/21] arm64: KVM: VHE: Patch out use of HVC
In-Reply-To: <20160201153635.GH15514@e104818-lin.cambridge.arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-7-git-send-email-marc.zyngier@arm.com>
 <20160201131634.GI1478@cbox> <56AF5ED8.7010303@arm.com>
 <20160201153635.GH15514@e104818-lin.cambridge.arm.com>
Message-ID: <56AF85D8.7080907@arm.com>

On 01/02/16 15:36, Catalin Marinas wrote:
> On Mon, Feb 01, 2016 at 01:34:16PM +0000, Marc Zyngier wrote:
>> On 01/02/16 13:16, Christoffer Dall wrote:
>>> On Mon, Jan 25, 2016 at 03:53:40PM +0000, Marc Zyngier wrote:
>>>> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
>>>> index 93e8d983..9e0683f 100644
>>>> --- a/arch/arm64/kvm/hyp/hyp-entry.S
>>>> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
>>>> @@ -38,6 +38,32 @@
>>>>  	ldp	x0, x1, [sp], #16
>>>>  .endm
>>>>  
>>>> +.macro do_el2_call
>>>> +	/*
>>>> +	 * Shuffle the parameters before calling the function
>>>> +	 * pointed to in x0. Assumes parameters in x[1,2,3].
>>>> +	 */
>>>> +	stp	lr, xzr, [sp, #-16]!
>>>
>>> remind me why this pair isn't just doing "str" instead of "stp" with the
>>> xzr ?
>>
>> Because SP has to be aligned on a 16 bytes boundary at all times.
> 
> You could do something like:
> 
> 	sub	sp, sp, #16
> 	str	lr, [sp]
> 

Ah, fair enough. I'll fold that in.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From arnd at arndb.de  Mon Feb  1 08:23:39 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 01 Feb 2016 17:23:39 +0100
Subject: [PATCH] ocfs2: remove unused label
Message-ID: <3477441.9K8aQAEjZq@wuerfel>

A recent cleanup modified the ocfs2_file_write_iter function, which
no longer uses its 'relock' label, as gcc warns:

fs/ocfs2/file.c: In function 'ocfs2_file_write_iter':
fs/ocfs2/file.c:2198:1: error: label 'relock' defined but not used [-Werror=unused-label]

This removes the label as well.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 1a46f12e5071 ("ocfs2: code clean up for direct io")
---
Found on ARM randconfig builds on linux-next last week.

diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
index 41c506e7814e..c18ab45f8d21 100644
--- a/fs/ocfs2/file.c
+++ b/fs/ocfs2/file.c
@@ -2195,7 +2195,6 @@ static ssize_t ocfs2_file_write_iter(struct kiocb *iocb,
 
 	inode_lock(inode);
 
-relock:
 	/*
 	 * Concurrent O_DIRECT writes are allowed with
 	 * mount_option "coherency=buffered".



From christoffer.dall at linaro.org  Mon Feb  1 08:25:23 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 1 Feb 2016 17:25:23 +0100
Subject: [PATCH v2 00/21] arm64: Virtualization Host Extension support
In-Reply-To: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160201162523.GA6190@cbox>

On Mon, Jan 25, 2016 at 03:53:34PM +0000, Marc Zyngier wrote:
> ARMv8.1 comes with the "Virtualization Host Extension" (VHE for
> short), which enables simpler support of Type-2 hypervisors.
> 
> This extension allows the kernel to directly run at EL2, and
> significantly reduces the number of system registers shared between
> host and guest, reducing the overhead of virtualization.
> 
> In order to have the same kernel binary running on all versions of the
> architecture, this series makes heavy use of runtime code patching.
> 
> The first 20 patches massage the KVM code to deal with VHE and enable
> Linux to run at EL2. The last patch catches an ugly case when VHE
> capable CPUs are paired with some of their less capable siblings. This
> should never happen, but hey...
> 
> I have deliberately left out some of the more "advanced"
> optimizations, as they are likely to distract the reviewer from the
> core infrastructure, which is what I care about at the moment.
> 
> A few things to note:
> 
> - Given that the code has been almost entierely rewritten, I've
>   dropped all Acks from the new patches
> 
> - GDB is currently busted on VHE systems, as it checks for version 6
>   on the debug architecture, while VHE is version 7. The binutils
>   people are on the case.
> 
> This has been tested on the FVP_Base_SLV-V8-A model, and based on
> v4.5-rc1. I've put a branch out on:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/vhe
> 
> * From v1:
>   - Full rewrite now that the World Switch is written in C code.
>   - Dropped the "early IRQ handling" for the moment.
> 
> Marc Zyngier (21):
>   arm/arm64: Add new is_kernel_in_hyp_mode predicate
>   arm64: Allow the arch timer to use the HYP timer
>   arm64: Add ARM64_HAS_VIRT_HOST_EXTN feature
>   arm64: KVM: Skip HYP setup when already running in HYP
>   arm64: KVM: VHE: Turn VTCR_EL2 setup into a reusable macro
>   arm64: KVM: VHE: Patch out use of HVC
>   arm64: KVM: VHE: Patch out kern_hyp_va
>   arm64: KVM: VHE: Introduce unified system register accessors
>   arm64: KVM: VHE: Differenciate host/guest sysreg save/restore
>   arm64: KVM: VHE: Split save/restore of sysregs shared between EL1 and
>     EL2
>   arm64: KVM: VHE: Use unified system register accessors
>   arm64: KVM: VHE: Enable minimal sysreg save/restore
>   arm64: KVM: VHE: Make __fpsimd_enabled VHE aware
>   arm64: KVM: VHE: Implement VHE activate/deactivate_traps
>   arm64: KVM: VHE: Use unified sysreg accessors for timer
>   arm64: KVM: VHE: Add fpsimd enabling on guest access
>   arm64: KVM: VHE: Add alternative panic handling
>   arm64: KVM: Introduce hyp_alternate_value helper
>   arm64: KVM: Move most of the fault decoding to C
>   arm64: VHE: Add support for running Linux in EL2 mode
>   arm64: Panic when VHE and non VHE CPUs coexist

These patches generally look awesome!

I found some trailing white space in patch 6 and 7 that you can fix up
if you care to.

Thanks,
-Christoffer


From wefu at redhat.com  Mon Feb  1 08:28:07 2016
From: wefu at redhat.com (Fu Wei)
Date: Tue, 2 Feb 2016 00:28:07 +0800
Subject: [PATCH v5sub1 8/8] arm64: allow kernel Image to be loaded
 anywhere in physical memory
In-Reply-To: <20160201145014.GK674@leverpostej>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-9-git-send-email-ard.biesheuvel@linaro.org>
 <20160201145014.GK674@leverpostej>
Message-ID: <56AF8797.5000908@redhat.com>

Hi Mark

On 02/01/2016 10:50 PM, Mark Rutland wrote:
> On Mon, Feb 01, 2016 at 11:54:53AM +0100, Ard Biesheuvel wrote:
>> This relaxes the kernel Image placement requirements, so that it
>> may be placed at any 2 MB aligned offset in physical memory.
>>
>> This is accomplished by ignoring PHYS_OFFSET when installing
>> memblocks, and accounting for the apparent virtual offset of
>> the kernel Image. As a result, virtual address references
>> below PAGE_OFFSET are correctly mapped onto physical references
>> into the kernel Image regardless of where it sits in memory.
>>
>> Note that limiting memory using mem= is not unambiguous anymore after
>> this change, considering that the kernel may be at the top of physical
>> memory, and clipping from the bottom rather than the top will discard
>> any 32-bit DMA addressable memory first. To deal with this, the handling
>> of mem= is reimplemented to clip top down, but take special care not to
>> clip memory that covers the kernel image.
>>
>> Since mem= should not be considered a production feature, a panic notifier
>> handler is installed that dumps the memory limit at panic time if one was
>> set.
>
> Good idea!
>
> It would be great if we could follow up with a sizes.h update for SZ_4G,
> though that's only a nice-to-have, and in no way should block this.
>
> Other than that, this looks good. Thanks for putting this together!
>
> Reviewed-by: Mark Rutland <mark.rutland at arm.com>
>
> For the Documentation/arm64 parts we'll need to ask Fu Wei to update the
> zh_CN/ translation to match.

Great thanks for your info
Yes, I will working on it

>
> Mark.
>
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> ---
>>   Documentation/arm64/booting.txt         |  20 ++--
>>   arch/arm64/include/asm/boot.h           |   6 ++
>>   arch/arm64/include/asm/kernel-pgtable.h |  12 +++
>>   arch/arm64/include/asm/kvm_asm.h        |   2 +-
>>   arch/arm64/include/asm/memory.h         |  15 +--
>>   arch/arm64/kernel/head.S                |   6 +-
>>   arch/arm64/kernel/image.h               |  13 ++-
>>   arch/arm64/mm/init.c                    | 100 +++++++++++++++++++-
>>   arch/arm64/mm/mmu.c                     |   3 +
>>   9 files changed, 155 insertions(+), 22 deletions(-)
>>
>> diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt
>> index 701d39d3171a..56d6d8b796db 100644
>> --- a/Documentation/arm64/booting.txt
>> +++ b/Documentation/arm64/booting.txt
>> @@ -109,7 +109,13 @@ Header notes:
>>   			1 - 4K
>>   			2 - 16K
>>   			3 - 64K
>> -  Bits 3-63:	Reserved.
>> +  Bit 3:	Kernel physical placement
>> +			0 - 2MB aligned base should be as close as possible
>> +			    to the base of DRAM, since memory below it is not
>> +			    accessible via the linear mapping
>> +			1 - 2MB aligned base may be anywhere in physical
>> +			    memory
>> +  Bits 4-63:	Reserved.
>>
>>   - When image_size is zero, a bootloader should attempt to keep as much
>>     memory as possible free for use by the kernel immediately after the
>> @@ -117,14 +123,14 @@ Header notes:
>>     depending on selected features, and is effectively unbound.
>>
>>   The Image must be placed text_offset bytes from a 2MB aligned base
>> -address near the start of usable system RAM and called there. Memory
>> -below that base address is currently unusable by Linux, and therefore it
>> -is strongly recommended that this location is the start of system RAM.
>> -The region between the 2 MB aligned base address and the start of the
>> -image has no special significance to the kernel, and may be used for
>> -other purposes.
>> +address anywhere in usable system RAM and called there. The region
>> +between the 2 MB aligned base address and the start of the image has no
>> +special significance to the kernel, and may be used for other purposes.
>>   At least image_size bytes from the start of the image must be free for
>>   use by the kernel.
>> +NOTE: versions prior to v4.6 cannot make use of memory below the
>> +physical offset of the Image so it is recommended that the Image be
>> +placed as close as possible to the start of system RAM.
>>
>>   Any memory described to the kernel (even that below the start of the
>>   image) which is not marked as reserved from the kernel (e.g., with a
>> diff --git a/arch/arm64/include/asm/boot.h b/arch/arm64/include/asm/boot.h
>> index 81151b67b26b..ebf2481889c3 100644
>> --- a/arch/arm64/include/asm/boot.h
>> +++ b/arch/arm64/include/asm/boot.h
>> @@ -11,4 +11,10 @@
>>   #define MIN_FDT_ALIGN		8
>>   #define MAX_FDT_SIZE		SZ_2M
>>
>> +/*
>> + * arm64 requires the kernel image to placed
>> + * TEXT_OFFSET bytes beyond a 2 MB aligned base
>> + */
>> +#define MIN_KIMG_ALIGN		SZ_2M
>> +
>>   #endif
>> diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
>> index a459714ee29e..5c6375d8528b 100644
>> --- a/arch/arm64/include/asm/kernel-pgtable.h
>> +++ b/arch/arm64/include/asm/kernel-pgtable.h
>> @@ -79,5 +79,17 @@
>>   #define SWAPPER_MM_MMUFLAGS	(PTE_ATTRINDX(MT_NORMAL) | SWAPPER_PTE_FLAGS)
>>   #endif
>>
>> +/*
>> + * To make optimal use of block mappings when laying out the linear
>> + * mapping, round down the base of physical memory to a size that can
>> + * be mapped efficiently, i.e., either PUD_SIZE (4k granule) or PMD_SIZE
>> + * (64k granule), or a multiple that can be mapped using contiguous bits
>> + * in the page tables: 32 * PMD_SIZE (16k granule)
>> + */
>> +#ifdef CONFIG_ARM64_64K_PAGES
>> +#define ARM64_MEMSTART_ALIGN	SZ_512M
>> +#else
>> +#define ARM64_MEMSTART_ALIGN	SZ_1G
>> +#endif
>>
>>   #endif	/* __ASM_KERNEL_PGTABLE_H */
>> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
>> index f5aee6e764e6..054ac25e7c2e 100644
>> --- a/arch/arm64/include/asm/kvm_asm.h
>> +++ b/arch/arm64/include/asm/kvm_asm.h
>> @@ -26,7 +26,7 @@
>>   #define KVM_ARM64_DEBUG_DIRTY_SHIFT	0
>>   #define KVM_ARM64_DEBUG_DIRTY		(1 << KVM_ARM64_DEBUG_DIRTY_SHIFT)
>>
>> -#define kvm_ksym_ref(sym)		((void *)&sym - KIMAGE_VADDR + PAGE_OFFSET)
>> +#define kvm_ksym_ref(sym)		phys_to_virt((u64)&sym - kimage_voffset)
>>
>>   #ifndef __ASSEMBLY__
>>   struct kvm;
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index 4388651d1f0d..61005e7dd6cb 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -88,10 +88,10 @@
>>   #define __virt_to_phys(x) ({						\
>>   	phys_addr_t __x = (phys_addr_t)(x);				\
>>   	__x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :	\
>> -			     (__x - KIMAGE_VADDR + PHYS_OFFSET); })
>> +			     (__x - kimage_voffset); })
>>
>>   #define __phys_to_virt(x)	((unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET))
>> -#define __phys_to_kimg(x)	((unsigned long)((x) - PHYS_OFFSET + KIMAGE_VADDR))
>> +#define __phys_to_kimg(x)	((unsigned long)((x) + kimage_voffset))
>>
>>   /*
>>    * Convert a page to/from a physical address
>> @@ -127,13 +127,14 @@ extern phys_addr_t		memstart_addr;
>>   /* PHYS_OFFSET - the physical address of the start of memory. */
>>   #define PHYS_OFFSET		({ memstart_addr; })
>>
>> +/* the offset between the kernel virtual and physical mappings */
>> +extern u64			kimage_voffset;
>> +
>>   /*
>> - * The maximum physical address that the linear direct mapping
>> - * of system RAM can cover. (PAGE_OFFSET can be interpreted as
>> - * a 2's complement signed quantity and negated to derive the
>> - * maximum size of the linear mapping.)
>> + * Allow all memory at the discovery stage. We will clip it later.
>>    */
>> -#define MAX_MEMBLOCK_ADDR	({ memstart_addr - PAGE_OFFSET - 1; })
>> +#define MIN_MEMBLOCK_ADDR	0
>> +#define MAX_MEMBLOCK_ADDR	U64_MAX
>>
>>   /*
>>    * PFNs are used to describe any physical page; this means
>> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
>> index 04d38a058b19..05b98289093e 100644
>> --- a/arch/arm64/kernel/head.S
>> +++ b/arch/arm64/kernel/head.S
>> @@ -428,7 +428,11 @@ __mmap_switched:
>>   	and	x4, x4, #~(THREAD_SIZE - 1)
>>   	msr	sp_el0, x4			// Save thread_info
>>   	str_l	x21, __fdt_pointer, x5		// Save FDT pointer
>> -	str_l	x24, memstart_addr, x6		// Save PHYS_OFFSET
>> +
>> +	ldr	x4, =KIMAGE_VADDR		// Save the offset between
>> +	sub	x4, x4, x24			// the kernel virtual and
>> +	str_l	x4, kimage_voffset, x5		// physical mappings
>> +
>>   	mov	x29, #0
>>   #ifdef CONFIG_KASAN
>>   	bl	kasan_early_init
>> diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
>> index 999633bd7294..c9c62cab25a4 100644
>> --- a/arch/arm64/kernel/image.h
>> +++ b/arch/arm64/kernel/image.h
>> @@ -42,15 +42,18 @@
>>   #endif
>>
>>   #ifdef CONFIG_CPU_BIG_ENDIAN
>> -#define __HEAD_FLAG_BE	1
>> +#define __HEAD_FLAG_BE		1
>>   #else
>> -#define __HEAD_FLAG_BE	0
>> +#define __HEAD_FLAG_BE		0
>>   #endif
>>
>> -#define __HEAD_FLAG_PAGE_SIZE ((PAGE_SHIFT - 10) / 2)
>> +#define __HEAD_FLAG_PAGE_SIZE	((PAGE_SHIFT - 10) / 2)
>>
>> -#define __HEAD_FLAGS	((__HEAD_FLAG_BE << 0) |	\
>> -			 (__HEAD_FLAG_PAGE_SIZE << 1))
>> +#define __HEAD_FLAG_PHYS_BASE	1
>> +
>> +#define __HEAD_FLAGS		((__HEAD_FLAG_BE << 0) |	\
>> +				 (__HEAD_FLAG_PAGE_SIZE << 1) |	\
>> +				 (__HEAD_FLAG_PHYS_BASE << 3))
>>
>>   /*
>>    * These will output as part of the Image header, which should be little-endian
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 1d627cd8121c..e8e853a1024c 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -35,8 +35,10 @@
>>   #include <linux/efi.h>
>>   #include <linux/swiotlb.h>
>>
>> +#include <asm/boot.h>
>>   #include <asm/fixmap.h>
>>   #include <asm/kasan.h>
>> +#include <asm/kernel-pgtable.h>
>>   #include <asm/memory.h>
>>   #include <asm/sections.h>
>>   #include <asm/setup.h>
>> @@ -158,9 +160,80 @@ static int __init early_mem(char *p)
>>   }
>>   early_param("mem", early_mem);
>>
>> +/*
>> + * clip_mem_range() - remove memblock memory between @min and @max until
>> + *                    we meet the limit in 'memory_limit'.
>> + */
>> +static void __init clip_mem_range(u64 min, u64 max)
>> +{
>> +	u64 mem_size, to_remove;
>> +	int i;
>> +
>> +again:
>> +	mem_size = memblock_phys_mem_size();
>> +	if (mem_size <= memory_limit || max <= min)
>> +		return;
>> +
>> +	to_remove = mem_size - memory_limit;
>> +
>> +	for (i = memblock.memory.cnt - 1; i >= 0; i--) {
>> +		struct memblock_region *r = memblock.memory.regions + i;
>> +		u64 start = max(min, r->base);
>> +		u64 end = min(max, r->base + r->size);
>> +
>> +		if (start >= max || end <= min)
>> +			continue;
>> +
>> +		if (end > min) {
>> +			u64 size = min(to_remove, end - max(start, min));
>> +
>> +			memblock_remove(end - size, size);
>> +		} else {
>> +			memblock_remove(start, min(max - start, to_remove));
>> +		}
>> +		goto again;
>> +	}
>> +}
>> +
>>   void __init arm64_memblock_init(void)
>>   {
>> -	memblock_enforce_memory_limit(memory_limit);
>> +	const s64 linear_region_size = -(s64)PAGE_OFFSET;
>> +
>> +	/*
>> +	 * Select a suitable value for the base of physical memory.
>> +	 */
>> +	memstart_addr = round_down(memblock_start_of_DRAM(),
>> +				   ARM64_MEMSTART_ALIGN);
>> +
>> +	/*
>> +	 * Remove the memory that we will not be able to cover with the
>> +	 * linear mapping. Take care not to clip the kernel which may be
>> +	 * high in memory.
>> +	 */
>> +	memblock_remove(max(memstart_addr + linear_region_size, __pa(_end)),
>> +			ULLONG_MAX);
>> +	if (memblock_end_of_DRAM() > linear_region_size)
>> +		memblock_remove(0, memblock_end_of_DRAM() - linear_region_size);
>> +
>> +	if (memory_limit != (phys_addr_t)ULLONG_MAX) {
>> +		u64 kbase = round_down(__pa(_text), MIN_KIMG_ALIGN);
>> +		u64 kend = PAGE_ALIGN(__pa(_end));
>> +		u64 const sz_4g = 0x100000000UL;
>> +
>> +		/*
>> +		 * Clip memory in order of preference:
>> +		 * - above the kernel and above 4 GB
>> +		 * - between 4 GB and the start of the kernel (if the kernel
>> +		 *   is loaded high in memory)
>> +		 * - between the kernel and 4 GB (if the kernel is loaded
>> +		 *   low in memory)
>> +		 * - below 4 GB
>> +		 */
>> +		clip_mem_range(max(sz_4g, kend), ULLONG_MAX);
>> +		clip_mem_range(sz_4g, kbase);
>> +		clip_mem_range(kend, sz_4g);
>> +		clip_mem_range(0, min(kbase, sz_4g));
>> +	}
>>
>>   	/*
>>   	 * Register the kernel text, kernel data, initrd, and initial
>> @@ -381,3 +454,28 @@ static int __init keepinitrd_setup(char *__unused)
>>
>>   __setup("keepinitrd", keepinitrd_setup);
>>   #endif
>> +
>> +/*
>> + * Dump out memory limit information on panic.
>> + */
>> +static int dump_mem_limit(struct notifier_block *self, unsigned long v, void *p)
>> +{
>> +	if (memory_limit != (phys_addr_t)ULLONG_MAX) {
>> +		pr_emerg("Memory Limit: %llu MB\n", memory_limit >> 20);
>> +	} else {
>> +		pr_emerg("Memory Limit: none\n");
>> +	}
>> +	return 0;
>> +}
>> +
>> +static struct notifier_block mem_limit_notifier = {
>> +	.notifier_call = dump_mem_limit,
>> +};
>> +
>> +static int __init register_mem_limit_dumper(void)
>> +{
>> +	atomic_notifier_chain_register(&panic_notifier_list,
>> +				       &mem_limit_notifier);
>> +	return 0;
>> +}
>> +__initcall(register_mem_limit_dumper);
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index 4c4b15932963..8dda38378959 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -46,6 +46,9 @@
>>
>>   u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
>>
>> +u64 kimage_voffset __read_mostly;
>> +EXPORT_SYMBOL(kimage_voffset);
>> +
>>   /*
>>    * Empty_zero_page is a special page that is used for zero-initialized data
>>    * and COW.
>> --
>> 2.5.0
>>


From eric.auger at linaro.org  Mon Feb  1 08:29:22 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Mon, 1 Feb 2016 17:29:22 +0100
Subject: [PATCH V13 09/10] vfio, platform: add support for ACPI while
 detecting the reset driver
In-Reply-To: <56AF84F4.2080809@codeaurora.org>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-10-git-send-email-okaya@codeaurora.org>
 <56AF82FA.7000303@linaro.org> <56AF84F4.2080809@codeaurora.org>
Message-ID: <56AF87E2.8040201@linaro.org>

On 02/01/2016 05:16 PM, Sinan Kaya wrote:
> On 2/1/2016 11:08 AM, Eric Auger wrote:
>>> For ACPI systems, ACPI HID needs to match and compat in the registered
>>>> reset
>>>> driver needs to match for ACPI reset driver loading to work.
>> Don't really get the sentence. For ACPI systems, a registered reset
>> function is selected if its associated ACPI HID matches the device ACPI HID?
> 
> Old commit message. I did an internal review before posting the patch. The first
> version of the patch was a hack. I simplified the code but forgot to update the 
> commit message.
> 
> Now, the rule is simple.
> 
> - ACPI HID needs match for ACPI systems
> - DT compat needs to match for OF systems
> 
> as expected. I'll rephrase for the next version.
> 
>>>>
>>>> For OF based systems, DT compatible string needs to match and compat in the
>>>> registered reset driver needs to match for DT reset driver loading to work.
>> same here
>>
>> I added Baptiste who is vfio platform driver sub-system maintainer.
> 
> Thanks, we should ask Baptiste to get his email into the Maintainer file list.
I think it is:
./scripts/get_maintainer.pl
0001-vfio-platform-add-support-for-ACPI-while-detecting-t.patch

Baptiste Reynal <b.reynal at virtualopensystems.com> (maintainer:VFIO
PLATFORM DRIVER,commit_signer:1/5=20%)
Alex Williamson <alex.williamson at redhat.com> (maintainer:VFIO
DRIVER,commit_signer:2/3=67%,commit_signer:4/5=80%)
../..
> 
>>
>> On my side I tested with of amd xgbe and I don't observe any regression.
>>
>> Best Regards
> 
> Can I add your tested by?
Well to make things clear I did not test the ACPI part. I just can tell
this does not bring any regression on the of part. But I am not against
if you don't find anybody else and you tested the ACPI part ;-)

Best Regards

Eric
> 



From arnd at arndb.de  Mon Feb  1 08:29:45 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 01 Feb 2016 17:29:45 +0100
Subject: [PATCH] target: fix cast from pointer to phys_addr_t
Message-ID: <3114027.BKdWsaRxO0@wuerfel>

The uio_mem structure has a member that is a phys_addr_t, but can
be a number of other types too. The target core driver attempts
to assign a pointer from vmalloc() to it, by casting it to
phys_addr_t, but that causes a warning when phys_addr_t is longer
than a pointer:

drivers/target/target_core_user.c: In function 'tcmu_configure_device':
drivers/target/target_core_user.c:906:22: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]

This adds another cast to uintptr_t to shut up the warning.
A nicer fix might be to have additional fields in uio_mem
for the different purposes, so we can assign a pointer directly.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
This has been around for a long while, but did not trigger in
my randconfig testing until now, don't know why.

diff --git a/drivers/target/target_core_user.c b/drivers/target/target_core_user.c
index dd600e5ead71..94f5154ac788 100644
--- a/drivers/target/target_core_user.c
+++ b/drivers/target/target_core_user.c
@@ -903,7 +903,7 @@ static int tcmu_configure_device(struct se_device *dev)
 	info->version = __stringify(TCMU_MAILBOX_VERSION);
 
 	info->mem[0].name = "tcm-user command & data buffer";
-	info->mem[0].addr = (phys_addr_t) udev->mb_addr;
+	info->mem[0].addr = (phys_addr_t)(uintptr_t)udev->mb_addr;
 	info->mem[0].size = TCMU_RING_SIZE;
 	info->mem[0].memtype = UIO_MEM_VIRTUAL;
 



From ard.biesheuvel at linaro.org  Mon Feb  1 08:31:11 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 1 Feb 2016 17:31:11 +0100
Subject: [PATCH v5sub1 8/8] arm64: allow kernel Image to be loaded
 anywhere in physical memory
In-Reply-To: <CAKv+Gu8rgkBWfJXfWzWSkxyKhLOnxirycu-wdcmvRovpDB5hKw@mail.gmail.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-9-git-send-email-ard.biesheuvel@linaro.org>
 <20160201150624.GG15514@e104818-lin.cambridge.arm.com>
 <CAKv+Gu8rgkBWfJXfWzWSkxyKhLOnxirycu-wdcmvRovpDB5hKw@mail.gmail.com>
Message-ID: <CAKv+Gu8+DdtGQmZtKsB8YOabH1NfzSJge=w0vQwFZPwbQkgYzA@mail.gmail.com>

On 1 February 2016 at 16:13, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 1 February 2016 at 16:06, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> On Mon, Feb 01, 2016 at 11:54:53AM +0100, Ard Biesheuvel wrote:
>>> Note that limiting memory using mem= is not unambiguous anymore after
>>> this change, considering that the kernel may be at the top of physical
>>> memory, and clipping from the bottom rather than the top will discard
>>> any 32-bit DMA addressable memory first. To deal with this, the handling
>>> of mem= is reimplemented to clip top down, but take special care not to
>>> clip memory that covers the kernel image.
>>
>> I may have forgotten the reason - why do we need to avoid clipping the
>> memory that covers the kernel image? It's already mapped in the vmalloc
>> area, so we wouldn't need it in the linear map as well.
>>
>
> Good question. Originally, I needed it for swapper_pg_dir, whose
> pud/pmd/pte levels were accessed via __va() translations of the values
> found in the higher-up table entries, but after Mark's patches, only
> the top level pgd of swapper_pg_dir is still used. Similarly, for
> idmap_pg_dir, we don't change any mappings at runtime so the same
> applies there I think.
>
> I will try dropping this, and see what happens.
>

I have given this a spin, and this chokes on
a) the fact that not all of the translation tables are accessible via
the linear mapping: the fixmap, due to its vicinity to PCI i/o and
other populated regions, will share its pud/pmd level tables with
other users, like ioremap, which traverses the translation tables in
the ordinary way, i.e., it expects that __va() applied on the phys
address in the table entry returns something that is mapped
b) free_initmem() now calls __free_pages() on a region that we never
mapped or registered as available.

So it may be feasible with some hackery, but I wonder if it is worth
it to complicate the common case for implementing mem= more
efficiently.

-- 
Ard.


From arnd at arndb.de  Mon Feb  1 08:34:52 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 01 Feb 2016 17:34:52 +0100
Subject: [PATCH] staging: amso1100: fix format string for 64-bit phys_addr
Message-ID: <2307631.X1DYNXxKPZ@wuerfel>

The amso1100 driver prints a phys_addr_t by casting it to a pointer,
which causes a warning when phys_addr_t is 64-bit and pointers
are 32-bit:

drivers/staging/rdma/amso1100/c2.c: In function 'c2_rx_error':
drivers/staging/rdma/amso1100/c2.c:430:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]

This changes the format string to print the address as a 64-bit
number all the time to avoids the warnings. Ideally we would use
the %pap format string for phys_addr_t, but that doesn't work
here easily as it requires passing a pointer to the address.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
Found on ARM randconfig testing. This must have been there forever but is
rather hard to trigger even with randconfig builds.

diff --git a/drivers/staging/rdma/amso1100/c2.c b/drivers/staging/rdma/amso1100/c2.c
index b46ebd1ae15a..170a42a60552 100644
--- a/drivers/staging/rdma/amso1100/c2.c
+++ b/drivers/staging/rdma/amso1100/c2.c
@@ -426,8 +426,8 @@ static void c2_rx_error(struct c2_port *c2_port, struct c2_element *elem)
 		pr_debug("    index : %Zu\n",
 			elem - c2_port->rx_ring.start);
 		pr_debug("    len   : %u\n", rx_desc->len);
-		pr_debug("  rxp_hdr : %p [PA %p]\n", rxp_hdr,
-			(void *) __pa((unsigned long) rxp_hdr));
+		pr_debug("  rxp_hdr : %p [PA %016llx\n", rxp_hdr,
+			(u64)__pa((unsigned long) rxp_hdr));
 		pr_debug("    flags : 0x%x\n", rxp_hdr->flags);
 		pr_debug("    status: 0x%x\n", rxp_hdr->status);
 		pr_debug("    len   : %u\n", rxp_hdr->len);



From arnd at arndb.de  Mon Feb  1 08:42:02 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 01 Feb 2016 17:42:02 +0100
Subject: [PATCH] infiniband: cxgb4: use %pR format string for printing
 resources
Message-ID: <2278867.O0SM8nbQp0@wuerfel>

The cxgb4 prints an MMIO resource using the "0x%x" and "%p" format
strings on the length and start, respective, but that
triggers a compiler warning when using a 64-bit resource_size_t
on a 32-bit architecture:

drivers/infiniband/hw/cxgb4/device.c: In function 'c4iw_rdev_open':
drivers/infiniband/hw/cxgb4/device.c:807:7: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
       (void *)pci_resource_start(rdev->lldi.pdev, 2),

This changes the format string to use %pR instead, which pretty-prints
the resource, avoids the warning and is shorter.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
This is an old warning I see rarely on ARM randconfig builds.

diff --git a/drivers/infiniband/hw/cxgb4/device.c b/drivers/infiniband/hw/cxgb4/device.c
index 8024ea4417b8..ebd60a20f148 100644
--- a/drivers/infiniband/hw/cxgb4/device.c
+++ b/drivers/infiniband/hw/cxgb4/device.c
@@ -801,10 +801,9 @@ static int c4iw_rdev_open(struct c4iw_rdev *rdev)
 	     rdev->lldi.vr->qp.size,
 	     rdev->lldi.vr->cq.start,
 	     rdev->lldi.vr->cq.size);
-	PDBG("udb len 0x%x udb base %p db_reg %p gts_reg %p "
+	PDBG("udb %pR db_reg %p gts_reg %p "
 	     "qpmask 0x%x cqmask 0x%x\n",
-	     (unsigned)pci_resource_len(rdev->lldi.pdev, 2),
-	     (void *)pci_resource_start(rdev->lldi.pdev, 2),
+		&rdev->lldi.pdev->resource[2],
 	     rdev->lldi.db_reg, rdev->lldi.gts_reg,
 	     rdev->qpmask, rdev->cqmask);
 



From dirk.behme at gmail.com  Mon Feb  1 08:43:23 2016
From: dirk.behme at gmail.com (Dirk Behme)
Date: Mon, 1 Feb 2016 17:43:23 +0100
Subject: [PATCH] drivers/perf: arm_pmu: make info messages more verbose
In-Reply-To: <1452586940-20137-1-git-send-email-dirk.behme@de.bosch.com>
References: <1452586940-20137-1-git-send-email-dirk.behme@de.bosch.com>
Message-ID: <56AF8B2B.6020705@gmail.com>

On 12.01.2016 09:22, Dirk Behme wrote:
> On a big.LITTLE system e.g. with Cortex A57 and A53 in case not all cores
> are online at PMU probe time we might get
>
> hw perfevents: failed to probe PMU!
> hw perfevents: failed to register PMU devices!
>
> making it unclear which cores failed, here.
>
> Add the name of the PMU which failed resulting in a more verbose and
> helpful message
>
> hw perfevents: armv8_cortex_a53: failed to probe PMU!
> hw perfevents: armv8_cortex_a53: failed to register PMU devices!
>
> Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
> ---
>   drivers/perf/arm_pmu.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index be3755c..fc1f06f 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -904,7 +904,7 @@ int arm_pmu_device_probe(struct platform_device *pdev,
>   	}
>
>   	if (ret) {
> -		pr_info("failed to probe PMU!\n");
> +		pr_info("%s: failed to probe PMU!\n", pmu->name);
>   		goto out_free;
>   	}
>
> @@ -921,7 +921,7 @@ int arm_pmu_device_probe(struct platform_device *pdev,
>   out_destroy:
>   	cpu_pmu_destroy(pmu);
>   out_free:
> -	pr_info("failed to register PMU devices!\n");
> +	pr_info("%s: failed to register PMU devices!\n", pmu->name);
>   	kfree(pmu);
>   	return ret;
>   }


Any comments on this?

If not, how to get this applied?

Best regards

Dirk



From ulf.hansson at linaro.org  Mon Feb  1 08:44:01 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Mon, 1 Feb 2016 17:44:01 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160128165810.GA19432@atomide.com>
References: <20160126224804.GB19432@atomide.com>
 <CAJZ5v0i79X5JjOZiu4cOZ0Esd5BxAvutF8d17asDzq9ECcML-g@mail.gmail.com>
 <20160126232212.GE19432@atomide.com>
 <CAJZ5v0gTRvyWHVmYNb8Q1QZzhVhokXo541+48mFyDRYv7Hi-Uw@mail.gmail.com>
 <20160126235222.GF19432@atomide.com>
 <CAPDyKFqD6Y6HcgVds_oWBZ8L7Kdh2VX_WZCGApf-1a_6GHCQ5g@mail.gmail.com>
 <20160128165810.GA19432@atomide.com>
Message-ID: <CAPDyKFoQHpqdCa4fzHycP0OT2KsNTxWm7JZSe8Mauh+rxqGtGg@mail.gmail.com>

On 28 January 2016 at 17:58, Tony Lindgren <tony at atomide.com> wrote:
> Hi,
>
> * Ulf Hansson <ulf.hansson at linaro.org> [160128 06:30]:
>> On 27 January 2016 at 00:52, Tony Lindgren <tony at atomide.com> wrote:
>> > * Rafael J. Wysocki <rafael at kernel.org> [160126 15:38]:
>> >> On Wed, Jan 27, 2016 at 12:22 AM, Tony Lindgren <tony at atomide.com> wrote:
>> >> > * Rafael J. Wysocki <rafael at kernel.org> [160126 15:15]:
>> >> >> On Tue, Jan 26, 2016 at 11:48 PM, Tony Lindgren <tony at atomide.com> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > Looks like commit 5de85b9d57ab ("PM / runtime: Re-init runtime
>> >> >> > PM states at probe error and driver unbind") broke PM on at least
>>
>> I need to understand the issue here in a bit more detail, could you
>> please try to fill out some of my gaps!?
>>
>> In *what way* did it break PM?
>
> The MMC hardware will not get idled properly any longer blocking any
> deeper idle states.
>
>> Did the driver not probe successfully the second try? If so, what happened.
>
> It probes fine after a -EPROBE_DEFER on the vmmc i2c regulator.
> But the PM runtime usecounts are wrong.

Okay. How did you verify this?

I think the easiest way would be to make sure the usage count is
*one*, just before the omap_hsmmc calls mmc_add_host() in its
->probe() function.

If it's *two*, that confirms this theory.

>
>> >> >> > omap3. It seems we now need to additionally also call
>> >> >> > pm_runtime_dont_use_autosuspend() to get things working again?
>> >> >> >
>> >> >> > The following fixes idling on omap3, but I'm wondering if we
>> >> >> > should do something in pm_runtime_reinit() instead?
>>
>> I understand this as the second (or third, forth, whatever) probing
>> attempt actually succeeds, right!?
>
> Right.
>
>> Is the issue you are seeing, that the device never becomes runtime
>> suspended due to commit 5de85b9d57ab ("PM / runtime: Re-init runtime
>> PM states at probe error and driver unbind")?
>
> Correct.
>
>> >> > Looks like we have RPM_ACTIVE set in pm_runtime_reinit() if that
>> >> > gives any clues.
>>
>> That's a good clue. Although, there could be several reasons to why.
>>
>> Rafael has pointed out one valid potential case, but I want to be sure
>> that's really what happening here.
>>
>> *If* the problem is that the device doesn't becomes runtime suspended,
>> that will anyway be prevented as long as the autosuspend_delay has
>> been set to a negative value. That's why I wonder whether this really
>> is the case here.
>
> That seems to be the case here. In device driver probe, commenting out
> pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY)
> also makes things work again.

Okay. Interesting. :-)

>
> So one of the failing cases seems to be:
>
> 1. Device driver probe sets pm_runtime_set_autosuspend_delay()

Only when "someone" in-before has set the autosuspend delay to a
negative value, this will affect the usage count.

I didn't find any in-kernel user that would set this for the
omap_hsmmc device, so it needs to be done from userspace via sysfs. It
would be really great if you could help to confirm this.

But more importantly, I fail to understand why commit 5de85b9d57ab
("PM / runtime: Re-init runtime PM states at probe error and driver
unbind"), is changing the behaviour in this regards.
Potentially we might have a different runtime PM status than we had
before when probing the second try, but how could that mess up the
usage count...?

>
> 2. Device driver probe initially fails with -EPROBE_DEFER

So that happened before as well.

Although, we now get a different runtime PM status (suspended) the
second probe time.

>
> 3. PM runtime usecounts get messed up

Perhaps, but let's try to validate that as it should be rather easy.

>
>> For omap3, I assume there's a PM domain (the so called hwmod) being
>> attached to the omap_hsmmc device at device registration point!?
>
> Correct. It uses the notifiers like bus code does in general.

Yes, there perfectly okay.

Although, I wondering whether it could be that it's the PM domain
that's preventing the omap_hsmmc device from becoming runtime
suspended.

Perhaps the PM domain returns an error code from its
->runtime_suspend() callback?

>
> FYI, most SoCs don't have hardware based autoidle signaling between
> the interconnect and the interconnect targets. So the hwmod code is
> still needed until we have converted it into a proper interconnect +
> module target drivers.
>
>> In that path depending on a specific hwmod flag, the device will be
>> given the an initial *active* runtime PM status, via invoking
>> pm_runtime_set_active().
>>
>> *If* that's the case, it affects the probing sequence, as the
>> pm_runtime_get_sync() won't trigger the ->runtime_resume() callbacks
>> to be invoked in the first probe attempt.
>
> It has worked since pm runtime. And it works with MMC as as a loadable
> module just fine when no -EPROBE_DEFER happens.

Okay, so we definitely seem to have an issue with the changed runtime
PM status (suspended) the second probe time.

That's indeed caused by 5de85b9d57ab ("PM / runtime: Re-init runtime
PM states at probe error and driver unbind").

>
>> Moreover, according to the data I received in this regression report
>> so far, it seems like probing the second time has *always* been done
>> with the device in runtime PM active state. Could that be the reason
>> to why it "happens" to work?
>
> Not correct. I think that speculation is not related to the $subject
> regression at all.

I think it's important in this context, as it could affect how the PM
domain may treat the device. As I mentioned earlier.

For example due to commit 5de85b9d57ab ("PM / runtime: Re-init runtime
PM states at probe error and driver unbind"), the ->runtime_resume()
callback seems now to be called twice in a row, without in-between
having the ->runtime_suspend() callback being invoked. Does really the
PM domain cope with that correctly?

>
> BTW, do you have some hardware to test with that has PM runtime
> implemnted and actually working with mainline kernel?

Oh, yes. Although I don't have an omap3, I wish I had.

Also, I have locally a "runtime PM test driver", which helps me to
test various runtime PM sequences.

Kind regards
Uffe


From okaya at codeaurora.org  Mon Feb  1 08:44:26 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Mon, 1 Feb 2016 11:44:26 -0500
Subject: [PATCH V13 09/10] vfio, platform: add support for ACPI while
 detecting the reset driver
In-Reply-To: <56AF87E2.8040201@linaro.org>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-10-git-send-email-okaya@codeaurora.org>
 <56AF82FA.7000303@linaro.org> <56AF84F4.2080809@codeaurora.org>
 <56AF87E2.8040201@linaro.org>
Message-ID: <56AF8B6A.8040504@codeaurora.org>

On 2/1/2016 11:29 AM, Eric Auger wrote:
>> hanks, we should ask Baptiste to get his email into the Maintainer file list.
> I think it is:
> ./scripts/get_maintainer.pl
> 0001-vfio-platform-add-support-for-ACPI-while-detecting-t.patch
> 
> Baptiste Reynal <b.reynal at virtualopensystems.com> (maintainer:VFIO
> PLATFORM DRIVER,commit_signer:1/5=20%)
> Alex Williamson <alex.williamson at redhat.com> (maintainer:VFIO
> DRIVER,commit_signer:2/3=67%,commit_signer:4/5=80%)
> ../..

Strange, I'll reset my tree. 

>> > 
>>> >>
>>> >> On my side I tested with of amd xgbe and I don't observe any regression.
>>> >>
>>> >> Best Regards
>> > 
>> > Can I add your tested by?
> Well to make things clear I did not test the ACPI part. I just can tell
> this does not bring any regression on the of part. But I am not against
> if you don't find anybody else and you tested the ACPI part ;-)
> 

How about?

of-tested-by: ...

Shanker and I tested ACPI before pushing the patches to the list and we also 
posted the corresponding QEMU patches as well to the qemu-devel maillist.

http://patchwork.ozlabs.org/patch/575878/

I'll ask him to add his acpi-tested-by for the ACPI part.

> Best Regards


-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


From swise at opengridcomputing.com  Mon Feb  1 08:45:04 2016
From: swise at opengridcomputing.com (Steve Wise)
Date: Mon, 1 Feb 2016 10:45:04 -0600
Subject: [PATCH] infiniband: cxgb4: use %pR format string for printing
 resources
In-Reply-To: <2278867.O0SM8nbQp0@wuerfel>
References: <2278867.O0SM8nbQp0@wuerfel>
Message-ID: <025701d15d0f$e67ed760$b37c8620$@opengridcomputing.com>


> Subject: [PATCH] infiniband: cxgb4: use %pR format string for printing resources
> 
> The cxgb4 prints an MMIO resource using the "0x%x" and "%p" format
> strings on the length and start, respective, but that
> triggers a compiler warning when using a 64-bit resource_size_t
> on a 32-bit architecture:
> 
> drivers/infiniband/hw/cxgb4/device.c: In function 'c4iw_rdev_open':
> drivers/infiniband/hw/cxgb4/device.c:807:7: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>        (void *)pci_resource_start(rdev->lldi.pdev, 2),
> 
> This changes the format string to use %pR instead, which pretty-prints
> the resource, avoids the warning and is shorter.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
> This is an old warning I see rarely on ARM randconfig builds.


Acked-by: Steve Wise <swise at opengridcomputing.com>



From arnd at arndb.de  Mon Feb  1 08:45:39 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 01 Feb 2016 17:45:39 +0100
Subject: [PATCH] [media] mx3_camera: use %pad format string for dma_ddr_t
Message-ID: <1527735.0V0q3NFh2C@wuerfel>

The mx3_camera driver prints DMA addresses using the "%x" format
string, which is wrong when using a 64-bit dma_addr_t definition:

media/platform/soc_camera/mx3_camera.c: In function 'mx3_cam_dma_done':
media/platform/soc_camera/mx3_camera.c:149:125: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=]
media/platform/soc_camera/mx3_camera.c: In function 'mx3_videobuf_queue':
media/platform/soc_camera/mx3_camera.c:317:119: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=]
media/platform/soc_camera/mx3_camera.c: In function 'mx3_videobuf_release':
media/platform/soc_camera/mx3_camera.c:346:119: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=]

This changes the code to use the special %pad format string, which
always does the right thing.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
Another old bug that only rarely shows up in ARM randconfigs.

diff --git a/drivers/media/platform/soc_camera/mx3_camera.c b/drivers/media/platform/soc_camera/mx3_camera.c
index 169ed1150226..aa39e9569b1a 100644
--- a/drivers/media/platform/soc_camera/mx3_camera.c
+++ b/drivers/media/platform/soc_camera/mx3_camera.c
@@ -146,8 +146,8 @@ static void mx3_cam_dma_done(void *arg)
 	struct idmac_channel *ichannel = to_idmac_chan(chan);
 	struct mx3_camera_dev *mx3_cam = ichannel->client;
 
-	dev_dbg(chan->device->dev, "callback cookie %d, active DMA 0x%08x\n",
-		desc->txd.cookie, mx3_cam->active ? sg_dma_address(&mx3_cam->active->sg) : 0);
+	dev_dbg(chan->device->dev, "callback cookie %d, active DMA %pad\n",
+		desc->txd.cookie, mx3_cam->active ? &sg_dma_address(&mx3_cam->active->sg) : NULL);
 
 	spin_lock(&mx3_cam->lock);
 	if (mx3_cam->active) {
@@ -314,8 +314,8 @@ static void mx3_videobuf_queue(struct vb2_buffer *vb)
 	spin_unlock_irq(&mx3_cam->lock);
 
 	cookie = txd->tx_submit(txd);
-	dev_dbg(icd->parent, "Submitted cookie %d DMA 0x%08x\n",
-		cookie, sg_dma_address(&buf->sg));
+	dev_dbg(icd->parent, "Submitted cookie %d DMA %pad\n",
+		cookie, &sg_dma_address(&buf->sg));
 
 	if (cookie >= 0)
 		return;
@@ -344,8 +344,8 @@ static void mx3_videobuf_release(struct vb2_buffer *vb)
 	unsigned long flags;
 
 	dev_dbg(icd->parent,
-		"Release%s DMA 0x%08x, queue %sempty\n",
-		mx3_cam->active == buf ? " active" : "", sg_dma_address(&buf->sg),
+		"Release%s DMA %pad, queue %sempty\n",
+		mx3_cam->active == buf ? " active" : "", &sg_dma_address(&buf->sg),
 		list_empty(&buf->queue) ? "" : "not ");
 
 	spin_lock_irqsave(&mx3_cam->lock, flags);



From timur at codeaurora.org  Mon Feb  1 08:49:47 2016
From: timur at codeaurora.org (Timur Tabi)
Date: Mon, 1 Feb 2016 10:49:47 -0600
Subject: [PATCH V13 09/10] vfio, platform: add support for ACPI while
 detecting the reset driver
In-Reply-To: <56AF8B6A.8040504@codeaurora.org>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-10-git-send-email-okaya@codeaurora.org>
 <56AF82FA.7000303@linaro.org> <56AF84F4.2080809@codeaurora.org>
 <56AF87E2.8040201@linaro.org> <56AF8B6A.8040504@codeaurora.org>
Message-ID: <56AF8CAB.3030908@codeaurora.org>

Sinan Kaya wrote:
> of-tested-by: ...
>
> Shanker and I tested ACPI before pushing the patches to the list and we also
> posted the corresponding QEMU patches as well to the qemu-devel maillist.
>
> http://patchwork.ozlabs.org/patch/575878/
>
> I'll ask him to add his acpi-tested-by for the ACPI part.

I would rather not see a tested-by variant, and instead add comments to 
the line, like this:

	Tested-by: Eric Auger <eric.auger at linaro.org> (device tree only)
	Tested-by: Shanker Donthineni <shankerd at codeaurora.org> (ACPI only)

That way, people can still grep for "^Tested-by:".

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.


From mark.rutland at arm.com  Mon Feb  1 08:49:49 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 1 Feb 2016 16:49:49 +0000
Subject: [PATCH] drivers/perf: arm_pmu: make info messages more verbose
In-Reply-To: <56AF8B2B.6020705@gmail.com>
References: <1452586940-20137-1-git-send-email-dirk.behme@de.bosch.com>
 <56AF8B2B.6020705@gmail.com>
Message-ID: <20160201164948.GC20396@leverpostej>

On Mon, Feb 01, 2016 at 05:43:23PM +0100, Dirk Behme wrote:
> On 12.01.2016 09:22, Dirk Behme wrote:
> >On a big.LITTLE system e.g. with Cortex A57 and A53 in case not all cores
> >are online at PMU probe time we might get
> >
> >hw perfevents: failed to probe PMU!
> >hw perfevents: failed to register PMU devices!
> >
> >making it unclear which cores failed, here.
> >
> >Add the name of the PMU which failed resulting in a more verbose and
> >helpful message
> >
> >hw perfevents: armv8_cortex_a53: failed to probe PMU!
> >hw perfevents: armv8_cortex_a53: failed to register PMU devices!
> >
> >Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
> >---
> >  drivers/perf/arm_pmu.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> >index be3755c..fc1f06f 100644
> >--- a/drivers/perf/arm_pmu.c
> >+++ b/drivers/perf/arm_pmu.c
> >@@ -904,7 +904,7 @@ int arm_pmu_device_probe(struct platform_device *pdev,
> >  	}
> >
> >  	if (ret) {
> >-		pr_info("failed to probe PMU!\n");
> >+		pr_info("%s: failed to probe PMU!\n", pmu->name);
> >  		goto out_free;
> >  	}
> >
> >@@ -921,7 +921,7 @@ int arm_pmu_device_probe(struct platform_device *pdev,
> >  out_destroy:
> >  	cpu_pmu_destroy(pmu);
> >  out_free:
> >-	pr_info("failed to register PMU devices!\n");
> >+	pr_info("%s: failed to register PMU devices!\n", pmu->name);
> >  	kfree(pmu);
> >  	return ret;
> >  }
> 
> 
> Any comments on this?

While this tells us that we didn't probe a particular PMU, it doesn't
tell us _why_.

We also shouldn't use pmu->name, as if we failed to find anything in the
match table, that'll be NULL. It would be better to use the full node
name from DT.

> If not, how to get this applied?

You'll need to Cc the maintainer (Will Deacon). I've added him to Cc.

Thanks,
Mark.


From mathieu.poirier at linaro.org  Mon Feb  1 08:53:09 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Mon, 1 Feb 2016 09:53:09 -0700
Subject: [PATCH 6/6] coresight-stm: adding driver for CoreSight STM
 component
In-Reply-To: <CAG2=9p_vBrgyzZohZ-LK2uoMRYEJFnyBQvUQJEgfTKCk+GvRwA@mail.gmail.com>
References: <1454313529-8860-7-git-send-email-zhang.chunyan@linaro.org>
 <201602011753.FpQPQQPf%fengguang.wu@intel.com>
 <CAG2=9p_vBrgyzZohZ-LK2uoMRYEJFnyBQvUQJEgfTKCk+GvRwA@mail.gmail.com>
Message-ID: <CANLsYkz5soN-DKYf5V8ucYEpF1VKdx2cdu2yyVsrWLHiZBqxhA@mail.gmail.com>

On 1 February 2016 at 05:44, Chunyan Zhang <zhang.chunyan at linaro.org> wrote:
> Hi Mathieu,
>
> So sorry that I forgot this patch depends on [1] which hasn't been upstreamed.
> How about adding the definition of coresight_simple_func() like [1]
> does in the STM driver for the time being? It can be simply removed
> once [1] is upstreamed. If you agree with this idea, I'll add the
> definition of coresight_simple_func() in the next version of patches.

I'm fine with proceeding this way - with the Perf integration work
there is simply too much churn in the Coresight subsystem to deal with
that immediately.

Mathieu

>
> Thanks,
> Chunyan
>
> [1] https://git.linaro.org/people/mathieu.poirier/coresight.git/blobdiff/59aadd3319527addcf8dbc6e6064b15f74b244fe..76dda3d0d313a4676d43adef52ad8faec0c61b61:/drivers/hwtracing/coresight/coresight-priv.h
>
> On Mon, Feb 1, 2016 at 6:01 PM, kbuild test robot <lkp at intel.com> wrote:
>> Hi Pratik,
>>
>> [auto build test ERROR on robh/for-next]
>> [also build test ERROR on v4.5-rc2 next-20160201]
>> [if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
>>
>> url:    https://github.com/0day-ci/linux/commits/Chunyan-Zhang/Introduce-CoreSight-STM-support/20160201-160437
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
>> config: arm-allmodconfig (attached as .config)
>> reproduce:
>>         wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>>         chmod +x ~/bin/make.cross
>>         # save the attached .config to linux build tree
>>         make.cross ARCH=arm
>>
>> All errors (new ones prefixed by >>):
>>
>>>> drivers/hwtracing/coresight/coresight-stm.c:671:27: error: unknown type name 'tcsr'
>>     coresight_stm_simple_func(tcsr, STMTCSR);
>>                               ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:57:20: error: expected declaration specifiers or '...' before numeric constant
>>     #define STMTCSR    0xe80
>>                        ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                      ^
>>    drivers/hwtracing/coresight/coresight-stm.c:671:33: note: in expansion of macro 'STMTCSR'
>>     coresight_stm_simple_func(tcsr, STMTCSR);
>>                                     ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:672:27: error: unknown type name 'tsfreqr'
>>     coresight_stm_simple_func(tsfreqr, STMTSFREQR);
>>                               ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                ^
>>    drivers/hwtracing/coresight/coresight-stm.c:59:22: error: expected declaration specifiers or '...' before numeric constant
>>     #define STMTSFREQR   0xe8c
>>                          ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                      ^
>>    drivers/hwtracing/coresight/coresight-stm.c:672:36: note: in expansion of macro 'STMTSFREQR'
>>     coresight_stm_simple_func(tsfreqr, STMTSFREQR);
>>                                        ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:673:27: error: unknown type name 'syncr'
>>     coresight_stm_simple_func(syncr, STMSYNCR);
>>                               ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                ^
>>    drivers/hwtracing/coresight/coresight-stm.c:60:20: error: expected declaration specifiers or '...' before numeric constant
>>     #define STMSYNCR   0xe90
>>                        ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                      ^
>>    drivers/hwtracing/coresight/coresight-stm.c:673:34: note: in expansion of macro 'STMSYNCR'
>>     coresight_stm_simple_func(syncr, STMSYNCR);
>>                                      ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:674:27: error: unknown type name 'sper'
>>     coresight_stm_simple_func(sper, STMSPER);
>>                               ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                ^
>>    drivers/hwtracing/coresight/coresight-stm.c:49:20: error: expected declaration specifiers or '...' before numeric constant
>>     #define STMSPER    0xe00
>>                        ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                      ^
>>    drivers/hwtracing/coresight/coresight-stm.c:674:33: note: in expansion of macro 'STMSPER'
>>     coresight_stm_simple_func(sper, STMSPER);
>>                                     ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:675:27: error: unknown type name 'spter'
>>     coresight_stm_simple_func(spter, STMSPTER);
>>                               ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                ^
>>    drivers/hwtracing/coresight/coresight-stm.c:50:20: error: expected declaration specifiers or '...' before numeric constant
>>     #define STMSPTER   0xe20
>>                        ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                      ^
>>    drivers/hwtracing/coresight/coresight-stm.c:675:34: note: in expansion of macro 'STMSPTER'
>>     coresight_stm_simple_func(spter, STMSPTER);
>>                                      ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:676:27: error: unknown type name 'privmaskr'
>>     coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
>>                               ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                ^
>>    drivers/hwtracing/coresight/coresight-stm.c:51:24: error: expected declaration specifiers or '...' before numeric constant
>>     #define STMPRIVMASKR   0xe40
>>                            ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                      ^
>>    drivers/hwtracing/coresight/coresight-stm.c:676:38: note: in expansion of macro 'STMPRIVMASKR'
>>     coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
>>                                          ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:677:27: error: unknown type name 'spscr'
>>     coresight_stm_simple_func(spscr, STMSPSCR);
>>                               ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                ^
>>    drivers/hwtracing/coresight/coresight-stm.c:52:20: error: expected declaration specifiers or '...' before numeric constant
>>     #define STMSPSCR   0xe60
>>                        ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                      ^
>>    drivers/hwtracing/coresight/coresight-stm.c:677:34: note: in expansion of macro 'STMSPSCR'
>>     coresight_stm_simple_func(spscr, STMSPSCR);
>>                                      ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:678:27: error: unknown type name 'spmscr'
>>     coresight_stm_simple_func(spmscr, STMSPMSCR);
>>                               ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                ^
>>    drivers/hwtracing/coresight/coresight-stm.c:53:21: error: expected declaration specifiers or '...' before numeric constant
>>     #define STMSPMSCR   0xe64
>>                         ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                      ^
>>    drivers/hwtracing/coresight/coresight-stm.c:678:35: note: in expansion of macro 'STMSPMSCR'
>>     coresight_stm_simple_func(spmscr, STMSPMSCR);
>>                                       ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:679:27: error: unknown type name 'spfeat1r'
>>     coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
>>                               ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                ^
>>    drivers/hwtracing/coresight/coresight-stm.c:62:23: error: expected declaration specifiers or '...' before numeric constant
>>     #define STMSPFEAT1R   0xea0
>>                           ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                      ^
>>    drivers/hwtracing/coresight/coresight-stm.c:679:37: note: in expansion of macro 'STMSPFEAT1R'
>>     coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
>>                                         ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:680:27: error: unknown type name 'spfeat2r'
>>     coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
>>                               ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                ^
>>    drivers/hwtracing/coresight/coresight-stm.c:63:23: error: expected declaration specifiers or '...' before numeric constant
>>     #define STMSPFEAT2R   0xea4
>>                           ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                      ^
>>    drivers/hwtracing/coresight/coresight-stm.c:680:37: note: in expansion of macro 'STMSPFEAT2R'
>>     coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
>>                                         ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:681:27: error: unknown type name 'spfeat3r'
>>     coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
>>                               ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                ^
>>    drivers/hwtracing/coresight/coresight-stm.c:64:23: error: expected declaration specifiers or '...' before numeric constant
>>     #define STMSPFEAT3R   0xea8
>>                           ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                      ^
>>    drivers/hwtracing/coresight/coresight-stm.c:681:37: note: in expansion of macro 'STMSPFEAT3R'
>>     coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
>>                                         ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:682:27: error: unknown type name 'devid'
>>     coresight_stm_simple_func(devid, CORESIGHT_DEVID);
>>                               ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:44: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                ^
>>    drivers/hwtracing/coresight/coresight-priv.h:31:26: error: expected declaration specifiers or '...' before numeric constant
>>     #define CORESIGHT_DEVID  0xfc8
>>                              ^
>>    drivers/hwtracing/coresight/coresight-stm.c:669:50: note: in definition of macro 'coresight_stm_simple_func'
>>      coresight_simple_func(struct stm_drvdata, name, offset)
>>                                                      ^
>>    drivers/hwtracing/coresight/coresight-stm.c:682:34: note: in expansion of macro 'CORESIGHT_DEVID'
>>     coresight_stm_simple_func(devid, CORESIGHT_DEVID);
>>                                      ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:694:3: error: 'dev_attr_tcsr' undeclared here (not in a function)
>>      &dev_attr_tcsr.attr,
>>       ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:695:3: error: 'dev_attr_tsfreqr' undeclared here (not in a function)
>>      &dev_attr_tsfreqr.attr,
>>       ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:696:3: error: 'dev_attr_syncr' undeclared here (not in a function)
>>      &dev_attr_syncr.attr,
>>       ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:697:3: error: 'dev_attr_sper' undeclared here (not in a function)
>>      &dev_attr_sper.attr,
>>       ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:698:3: error: 'dev_attr_spter' undeclared here (not in a function)
>>      &dev_attr_spter.attr,
>>       ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:699:3: error: 'dev_attr_privmaskr' undeclared here (not in a function)
>>      &dev_attr_privmaskr.attr,
>>       ^
>>>> drivers/hwtracing/coresight/coresight-stm.c:700:3: error: 'dev_attr_spscr' undeclared here (not in a function)
>>      &dev_attr_spscr.attr,
>>       ^
>>
>> vim +/tcsr +671 drivers/hwtracing/coresight/coresight-stm.c
>>
>>    663          drvdata->traceid = val & 0x7f;
>>    664          return size;
>>    665  }
>>    666  static DEVICE_ATTR_RW(traceid);
>>    667
>>    668  #define coresight_stm_simple_func(name, offset) \
>>  > 669          coresight_simple_func(struct stm_drvdata, name, offset)
>>    670
>>  > 671  coresight_stm_simple_func(tcsr, STMTCSR);
>>  > 672  coresight_stm_simple_func(tsfreqr, STMTSFREQR);
>>  > 673  coresight_stm_simple_func(syncr, STMSYNCR);
>>  > 674  coresight_stm_simple_func(sper, STMSPER);
>>  > 675  coresight_stm_simple_func(spter, STMSPTER);
>>  > 676  coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
>>  > 677  coresight_stm_simple_func(spscr, STMSPSCR);
>>  > 678  coresight_stm_simple_func(spmscr, STMSPMSCR);
>>  > 679  coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
>>  > 680  coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
>>  > 681  coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
>>  > 682  coresight_stm_simple_func(devid, CORESIGHT_DEVID);
>>    683
>>    684  static struct attribute *coresight_stm_attrs[] = {
>>    685          &dev_attr_hwevent_enable.attr,
>>    686          &dev_attr_hwevent_select.attr,
>>    687          &dev_attr_port_enable.attr,
>>    688          &dev_attr_port_select.attr,
>>    689          &dev_attr_traceid.attr,
>>    690          NULL,
>>    691  };
>>    692
>>    693  static struct attribute *coresight_stm_mgmt_attrs[] = {
>>  > 694          &dev_attr_tcsr.attr,
>>  > 695          &dev_attr_tsfreqr.attr,
>>  > 696          &dev_attr_syncr.attr,
>>  > 697          &dev_attr_sper.attr,
>>  > 698          &dev_attr_spter.attr,
>>  > 699          &dev_attr_privmaskr.attr,
>>  > 700          &dev_attr_spscr.attr,
>>  > 701          &dev_attr_spmscr.attr,
>>  > 702          &dev_attr_spfeat1r.attr,
>>  > 703          &dev_attr_spfeat2r.attr,
>>  > 704          &dev_attr_spfeat3r.attr,
>>  > 705          &dev_attr_devid.attr,
>>    706          NULL,
>>    707  };
>>    708
>>
>> ---
>> 0-DAY kernel test infrastructure                Open Source Technology Center
>> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation


From okaya at codeaurora.org  Mon Feb  1 08:56:44 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Mon, 1 Feb 2016 11:56:44 -0500
Subject: [PATCH V13 09/10] vfio, platform: add support for ACPI while
 detecting the reset driver
In-Reply-To: <56AF8CAB.3030908@codeaurora.org>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-10-git-send-email-okaya@codeaurora.org>
 <56AF82FA.7000303@linaro.org> <56AF84F4.2080809@codeaurora.org>
 <56AF87E2.8040201@linaro.org> <56AF8B6A.8040504@codeaurora.org>
 <56AF8CAB.3030908@codeaurora.org>
Message-ID: <56AF8E4C.10003@codeaurora.org>

On 2/1/2016 11:49 AM, Timur Tabi wrote:
> Sinan Kaya wrote:
>> of-tested-by: ...
>>
>> Shanker and I tested ACPI before pushing the patches to the list and we also
>> posted the corresponding QEMU patches as well to the qemu-devel maillist.
>>
>> http://patchwork.ozlabs.org/patch/575878/
>>
>> I'll ask him to add his acpi-tested-by for the ACPI part.
> 
> I would rather not see a tested-by variant, and instead add comments to the line, like this:
> 
>     Tested-by: Eric Auger <eric.auger at linaro.org> (device tree only)
>     Tested-by: Shanker Donthineni <shankerd at codeaurora.org> (ACPI only)
> 
> That way, people can still grep for "^Tested-by:".
> 

will do.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


From vitalya at ti.com  Mon Feb  1 09:01:08 2016
From: vitalya at ti.com (Vitaly Andrianov)
Date: Mon, 1 Feb 2016 12:01:08 -0500
Subject: [PATCH 1/2] ARM: make virt_to_idmap() return unsigned long
In-Reply-To: <20160201152015.GU10826@n2100.arm.linux.org.uk>
References: <E1aO8F2-00074N-E8@rmk-PC.arm.linux.org.uk>
 <56A84748.3040108@oracle.com> <20160201152015.GU10826@n2100.arm.linux.org.uk>
Message-ID: <56AF8F54.7030805@ti.com>



On 02/01/2016 10:20 AM, Russell King - ARM Linux wrote:
> On Tue, Jan 26, 2016 at 08:27:52PM -0800, santosh.shilimkar at oracle.com wrote:
>> On 1/26/16 10:21 AM, Russell King wrote:
>>> Make virt_to_idmap() return an unsigned long rather than phys_addr_t.
>>>
>>> Returning phys_addr_t here makes no sense, because the definition of
>>> virt_to_idmap() is that it shall return a physical address which maps
>>> identically with the virtual address.  Since virtual addresses are
>>> limited to 32-bit, identity mapped physical addresses are as well.
>>>
>>> Almost all users already had an implicit narrowing cast to unsigned long
>>> so let's make this official and part of this interface.
>>>
>>> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
>>> ---
>> Looks correct to me.
>>
>> Vitaly,
>> Could you please try out this patch and see everything continue to
>> work ?
>
> I haven't heard anything yet...  Vitaly?
>
Russel, Santosh,

I'm not working with the latest kernel, but with the stable v4.1.y. So I 
couldn't apply the patch to it. I checked out 4.5.0-rc1 and applied the 
patch to it. Tried to boot and it crashed. I'm not sure either because 
of the patch or because of the network driver.

Here is the log:

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.5.0-rc1-00001-g22a8511 
(a0794637 at uda0794637) (gcc version 4.9.3 20150413 (prerelease) (Linaro 
GCC 4.9-2015.05) ) #1 6
[    0.000000] CPU: ARMv7 Processor [412fc0f4] revision 4 (ARMv7), 
cr=30c5387d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction 
cache
[    0.000000] Machine model: Texas Instruments Keystone 2 
Kepler/Hawking EVM
[    0.000000] Switching physical address space to 0x800000000
[    0.000000] cma: Reserved 16 MiB at 0x000000085f000000
[    0.000000] Forcing write-allocate cache policy for SMP
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] PERCPU: Embedded 13 pages/cpu @ebf9e000 s21248 r8192 
d23808 u53248
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on. 
Total pages: 1964544
[    0.000000] Kernel command line: console=ttyS0,115200n8 rootwait=1 
rdinit=/sbin/init rw root=/dev/ram0 initrd=0x808080000,80M
[    0.000000] log_buf_len individual max cpu contribution: 4096 bytes
[    0.000000] log_buf_len total cpu_extra contributions: 12288 bytes
[    0.000000] log_buf_len min size: 16384 bytes
[    0.000000] log_buf_len: 32768 bytes
[    0.000000] early log buf free: 14624(89%)
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 
bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 
bytes)
[    0.000000] Memory: 7694704K/7864320K available (5725K kernel code, 
365K rwdata, 1944K rodata, 368K init, 202K bss, 153232K reserved, 16384K 
cma)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0785a14   (7671 kB)
[    0.000000]       .init : 0xc0786000 - 0xc07e2000   ( 368 kB)
[    0.000000]       .data : 0xc07e2000 - 0xc083d5e8   ( 366 kB)
[    0.000000]        .bss : 0xc0840000 - 0xc0872868   ( 203 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000]  Build-time adjustment of leaf fanout to 32.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] Architected cp15 timer(s) running at 200.00MHz (virt).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff 
max_cycles: 0x2e2049d3e8, max_idle_ns: 440795210634 ns
[    0.000003] sched_clock: 56 bits at 200MHz, resolution 5ns, wraps 
every 4398046511102ns
[    0.000012] Switching to timer-based delay loop, resolution 5ns
[    0.000159] keystone timer clock @200000000 Hz
[    0.000273] Console: colour dummy device 80x30
[    0.000290] Calibrating delay loop (skipped), value calculated using 
timer frequency.. 400.00 BogoMIPS (lpj=2000000)
[    0.000300] pid_max: default: 4096 minimum: 301
[    0.000359] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000367] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 
bytes)
[    0.000808] CPU: Testing write buffer coherency: ok
[    0.000974] /cpus/cpu at 0 missing clock-frequency property
[    0.000992] /cpus/cpu at 1 missing clock-frequency property
[    0.001010] /cpus/cpu at 2 missing clock-frequency property
[    0.001028] /cpus/cpu at 3 missing clock-frequency property
[    0.001037] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.001073] Setting up static identity map for 0x800082c0 - 0x800083cc
[    0.084949] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.114987] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[    0.145023] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[    0.145099] Brought up 4 CPUs
[    0.145115] SMP: Total of 4 processors activated (1600.00 BogoMIPS).
[    0.145120] CPU: All CPU(s) started in SVC mode.
[    0.145452] devtmpfs: initialized
[    0.151260] VFP support v0.3: implementor 41 architecture 4 part 30 
variant f rev 0
[    0.151575] clocksource: jiffies: mask: 0xffffffff max_cycles: 
0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.152177] NET: Registered protocol family 16
[    0.152958] DMA: preallocated 256 KiB pool for atomic coherent 
allocations
[    0.160094] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 
watchpoint registers.
[    0.160102] hw-breakpoint: maximum watchpoint size is 8 bytes.
[    0.200557] vgaarb: loaded
[    0.200755] SCSI subsystem initialized
[    0.200965] usbcore: registered new interface driver usbfs
[    0.201020] usbcore: registered new interface driver hub
[    0.201070] usbcore: registered new device driver usb
[    0.202436] clocksource: Switched to clocksource arch_sys_counter
[    0.229144] NET: Registered protocol family 2
[    0.229502] TCP established hash table entries: 8192 (order: 3, 32768 
bytes)
[    0.229555] TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
[    0.229658] TCP: Hash tables configured (established 8192 bind 8192)
[    0.229700] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    0.229726] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    0.229857] NET: Registered protocol family 1
[    0.230062] RPC: Registered named UNIX socket transport module.
[    0.230069] RPC: Registered udp transport module.
[    0.230074] RPC: Registered tcp transport module.
[    0.230079] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.230232] Unpacking initramfs...
[    1.229078] Freeing initrd memory: 81920K (c8080000 - cd080000)
[    1.229275] hw perfevents: enabled with armv7_cortex_a15 PMU driver, 
7 counters available
[    1.229816] platform alarmtimer: set dma_pfn_offset00780000
[    1.230252] futex hash table entries: 16 (order: -2, 1024 bytes)
[    1.239974] Installing knfsd (copyright (C) 1996 okir at monad.swb.de).
[    1.240074] ntfs: driver 2.1.32 [Flags: R/O].
[    1.240339] jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
[    1.242984] NET: Registered protocol family 38
[    1.243049] bounce: pool size: 64 pages
[    1.243206] Block layer SCSI generic (bsg) driver version 0.4 loaded 
(major 253)
[    1.243220] io scheduler noop registered
[    1.243231] io scheduler deadline registered
[    1.243260] io scheduler cfq registered (default)
[    1.243398] keystone_irq soc:keystone_irq at 26202a0: irqchip 
registered, nr_irqs 28
[    1.244639] keystone-navigator-qmss soc:qmss at 2a40000: qmgr start 
queue 0, number of queues 8192
[    1.244759] keystone-navigator-qmss soc:qmss at 2a40000: added qmgr 
start queue 0, num of queues 8192, reg_peek f09c0000, reg_status 
f09e2000, reg_0
[    1.244770] keystone-navigator-qmss soc:qmss at 2a40000: qmgr start 
queue 8192, number of queues 8192
[    1.244869] keystone-navigator-qmss soc:qmss at 2a40000: added qmgr 
start queue 8192, num of queues 8192, reg_peek f0a80000, reg_status 
f09e8400, r0
[    1.244994] keystone-navigator-qmss soc:qmss at 2a40000: failed to get 
firmware for pdsp
[    1.245739] keystone-navigator-qmss soc:qmss at 2a40000: pdsp id 0 not 
started for range acc-low-0
[    1.246359] keystone-navigator-dma soc:knav_dmas at 0: DMA dma_gbe 
registered 41 logical channels, flows 32, tx chans: 9, rx chans: 24
[    1.294877] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    1.294954] platform serial8250: set dma_pfn_offset00780000
[    1.296268] console [ttyS0] disabled
[    1.296302] 2530c00.serial: ttyS0 at MMIO 0x2530c00 (irq = 26, 
base_baud = 12500000) is a 16550A
[    2.002189] console [ttyS0] enabled
[    2.006331] 2531000.serial: ttyS1 at MMIO 0x2531000 (irq = 27, 
base_baud = 12500000) is a 16550A
[    2.020027] loop: module loaded
[    2.023349] at24 0-0050: 131072 byte 24c1024 EEPROM, writable, 1 
bytes/write
[    2.031653] m25p80 spi32766.0: n25q128a11 (16384 Kbytes)
[    2.037071] 2 ofpart partitions found on MTD device spi32766.0
[    2.042954] Creating 2 MTD partitions on "spi32766.0":
[    2.048111] 0x000000000000-0x000000080000 : "u-boot-spl"
[    2.054252] 0x000000080000-0x000001000000 : "misc"
[    2.059809] spi_davinci 21000400.spi: Controller at 0xf0a2a400
[    2.066120] spi_davinci 21000600.spi: Controller at 0xf0a2c600
[    2.072392] spi_davinci 21000800.spi: Controller at 0xf0a2e800
[    2.122448] davinci_mdio 2090300.mdio: davinci mdio revision 1.5
[    2.128476] libphy: 2090300.mdio: probed
[    2.138918] davinci_mdio 2090300.mdio: phy[0]: device 
2090300.mdio:00, driver Marvell 88E1111
[    2.147513] davinci_mdio 2090300.mdio: phy[1]: device 
2090300.mdio:01, driver Marvell 88E1111
[    3.161406] netcp-1.0 2620110.netcp: module(netcp-xgbe) not used for 
device
[    3.369570] platform xhci-hcd.0.auto: set dma_pfn_offset00780000
[    3.376121] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[    3.381764] xhci-hcd xhci-hcd.0.auto: new USB bus registered, 
assigned bus number 1
[    3.389696] xhci-hcd xhci-hcd.0.auto: hcc params 0x0298f06d hci 
version 0x100 quirks 0x00010010
[    3.398469] xhci-hcd xhci-hcd.0.auto: irq 34, io mem 0x02690000
[    3.404567] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    3.411381] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[    3.418659] usb usb1: Product: xHCI Host Controller
[    3.423582] usb usb1: Manufacturer: Linux 4.5.0-rc1-00001-g22a8511 
xhci-hcd
[    3.430566] usb usb1: SerialNumber: xhci-hcd.0.auto
[    3.435888] hub 1-0:1.0: USB hub found
[    3.439670] hub 1-0:1.0: 1 port detected
[    3.443900] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[    3.449540] xhci-hcd xhci-hcd.0.auto: new USB bus registered, 
assigned bus number 2
[    3.457310] usb usb2: We don't know the algorithms for LPM for this 
host, disabling LPM.
[    3.465555] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[    3.472367] usb usb2: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[    3.479642] usb usb2: Product: xHCI Host Controller
[    3.484560] usb usb2: Manufacturer: Linux 4.5.0-rc1-00001-g22a8511 
xhci-hcd
[    3.491544] usb usb2: SerialNumber: xhci-hcd.0.auto
[    3.496852] hub 2-0:1.0: USB hub found
[    3.500633] hub 2-0:1.0: 1 port detected
[    3.504979] usbcore: registered new interface driver usb-storage
[    3.511253] mousedev: PS/2 mouse device common for all mice
[    3.517058] i2c /dev entries driver
[    3.521106] davinci-wdt 22f0080.wdt: heartbeat 60 sec
[    3.527105] usbcore: registered new interface driver usbhid
[    3.532729] usbhid: USB HID core driver
[    3.537313] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xac
[    3.543798] nand: Micron MT29F4G08ABBDAHC
[    3.547821] nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, 
OOB size: 64
[    3.555751] Bad block table found at page 262080, version 0x01
[    3.562130] Bad block table found at page 262016, version 0x01
[    3.568339] 3 ofpart partitions found on MTD device 30000000.nand
[    3.574482] Creating 3 MTD partitions on "30000000.nand":
[    3.579898] 0x000000000000-0x000000100000 : "u-boot"
[    3.585670] 0x000000100000-0x000000180000 : "params"
[    3.591394] 0x000000180000-0x000020000000 : "ubifs"
[    3.597258] davinci_nand 30000000.nand: controller rev. 2.5
[    3.603148] platform oprofile-perf.0: set dma_pfn_offset00780000
[    3.609305] oprofile: using timer interrupt.
[    3.613671] Netfilter messages via NETLINK v0.30.
[    3.618402] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
[    3.625204] ctnetlink v0.93: registering with nfnetlink.
[    3.630769] ipip: IPv4 over IPv4 tunneling driver
[    3.635904] gre: GRE over IPv4 demultiplexor driver
[    3.640800] ip_gre: GRE over IPv4 tunneling driver
[    3.646523] ip_tables: (C) 2000-2006 Netfilter Core Team
[    3.651932] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
[    3.658400] arp_tables: arp_tables: (C) 2002 David S. Miller
[    3.664154] Initializing XFRM netlink socket
[    3.669212] NET: Registered protocol family 10
[    3.674461] NET: Registered protocol family 17
[    3.678934] NET: Registered protocol family 15
[    3.683431] 8021q: 802.1Q VLAN Support v1.8
[    3.688454] sctp: Hash tables configured (bind 65536)
[    3.693842] Registering SWP/SWPB emulation handler
[    3.714212] Freeing unused kernel memory: 368K (c0786000 - c07e2000)
INIT: version 2.88 booting
Starting udev
Starting Bootlog daemon: bootlogd.
Configuring network interfaces... [    4.743126] netcp-1.0 2620110.netcp 
eth0: Link is Down
[    4.750118] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    4.756002] 8021q: adding VLAN 0 to HW filter on device eth0
udhcpc (v1.20.2) started
Sending discover...
Sending discover...
[    8.742799] netcp-1.0 2620110.netcp eth0: Link is Up - 1Gbps/Full - 
flow control off
[    8.750578] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[    8.972474] Unable to handle kernel NULL pointer dereference at 
virtual address 00000000
[    8.980593] pgd = c0003000
[    8.983317] [00000000] *pgd=80000800004003, *pmd=00000000
[    8.988744] Internal error: Oops: a07 [#1] PREEMPT SMP ARM
[    8.994246] Modules linked in:
[    8.997314] CPU: 0 PID: 330 Comm: kworker/0:1 Not tainted 
4.5.0-rc1-00001-g22a8511 #1
[    9.005171] Hardware name: Keystone
[    9.008677] Workqueue: ipv6_addrconf addrconf_dad_work
[    9.013836] task: eba89500 ti: eba96000 task.ti: eba96000
[    9.019253] PC is at tasklet_action+0xac/0x13c
[    9.023714] LR is at _raw_spin_unlock_irqrestore+0x28/0x54
[    9.029216] pc : [<c0026c48>]    lr : [<c0574634>]    psr: 40000133
[    9.029216] sp : eba97d30  ip : eb400258  fp : c083aecc
[    9.040737] r10: 0000000c  r9 : eba97dc8  r8 : 00000100
[    9.045976] r7 : 00000008  r6 : eba96000  r5 : 00000003  r4 : c07e408c
[    9.052524] r3 : eba97d00  r2 : eba97d00  r1 : 60000113  r0 : 00000000
[    9.059073] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb 
Segment kernel
[    9.066580] Control: 30c5387d  Table: 2b9ba700  DAC: fffffffd
[    9.072344] Process kworker/0:1 (pid: 330, stack limit = 0xeba96210)
[    9.078717] Stack: (0xeba97d30 to 0xeba98000)
[    9.083087] 7d20:                                     000086dd 
ebbb9900 00000004 eba97d30
[    9.091294] 7d40: c07e4080 c08409c0 0000000a ffff8e53 c07e4100 
04208060 ebbb9900 c07dce84
[    9.099502] 7d60: 00000000 0000004e 00000000 00000001 eba97dc8 
eb838000 c082ad40 c0026778
[    9.107708] 7d80: c07dce84 c006754c c080f430 c07e5e84 f080400c 
eba97dc8 f0804000 f0805000
[    9.115915] 7da0: 00000001 c0009438 c04fc29c 20000013 ffffffff 
eba97dfc cc8da400 eaf54d00
[    9.124121] 7dc0: 00000001 c0574e40 00000000 c06cab20 00000000 
00000087 cc8a7600 eb0e4100
[    9.132326] 7de0: c082ad40 00000187 cc8da400 eaf54d00 00000001 
c082ad40 f0a02880 eba97e18
[    9.140533] 7e00: c0026618 c04fc29c 20000013 ffffffff 00000018 
c04fc3c8 66cdb48e 00000002
[    9.148739] 7e20: c07e5cec 00000087 00000002 00000000 00000000 
003a0000 00000000 00000000
[    9.156944] 7e40: 00000000 00000000 000002ff 00000000 01000000 
67a532ff 00000000 00000000
[    9.165150] 7e60: 00000000 00000000 00000000 00000087 cc80be38 
c05c7568 cc80be38 eba97ed8
[    9.173356] 7e80: cc8a7e40 cc8a7600 eba97ea8 00000000 c083af58 
c04fd040 eba97ebc 00000000
[    9.181563] 7ea0: cc8a7e78 00000004 000080fe 00000000 ff28000a 
67a532fe cc8a7e78 cc8a7e5c
[    9.189770] 7ec0: cc8a7e60 cc8a7e40 cc8da484 00000000 00000000 
c04eebc8 000002ff 00000000
[    9.197975] 7ee0: 01000000 67a532ff eba97efc cc8a7e78 ebb42700 
00000008 ebfa2300 ebfa9b00
[    9.206182] 7f00: 00000000 c0038180 ebfa2300 00000008 00000001 
ebfa2300 ebb42718 00000008
[    9.214388] 7f20: ebfa2318 c07e4100 eba96000 ebfa2300 ebb42700 
c00384c4 ebb41340 ebb42700
[    9.222593] 7f40: c003848c 00000000 ebb41340 ebb42700 c003848c 
00000000 00000000 00000000
[    9.230799] 7f60: 00000000 c003d66c 00000000 00000000 eba97f70 
ebb42700 00000000 00000000
[    9.239004] 7f80: eba97f80 eba97f80 00000000 00000000 eba97f90 
eba97f90 eba97fac ebb41340
[    9.247210] 7fa0: c003d590 00000000 00000000 c000f548 00000000 
00000000 00000000 00000000
[    9.255415] 7fc0: 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 00000000
[    9.263621] 7fe0: 00000000 00000000 00000000 00000000 00000013 
00000000 00000000 00000000
[    9.271834] [<c0026c48>] (tasklet_action) from [<c08409c0>] 
(irq_stat+0x0/0x100)
[    9.279257] Code: 4000 e256 0020 0a00 (5004) e1a0
[    9.284077] ---[ end trace e5db23259be8804d ]---
[    9.288707] Kernel panic - not syncing: Fatal exception in interrupt
[    9.295083] CPU2: stopping
[    9.297799] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G      D 
4.5.0-rc1-00001-g22a8511 #1
[    9.306528] Hardware name: Keystone
[    9.310036] [<c0016490>] (unwind_backtrace) from [<c0012d44>] 
(show_stack+0x10/0x14)
[    9.317812] [<c0012d44>] (show_stack) from [<c02b3ce4>] 
(dump_stack+0x84/0xc4)
[    9.325061] [<c02b3ce4>] (dump_stack) from [<c00155a4>] 
(handle_IPI+0x2e0/0x2f0)
[    9.332484] [<c00155a4>] (handle_IPI) from [<c0009474>] 
(gic_handle_irq+0x84/0x88)
[    9.340084] [<c0009474>] (gic_handle_irq) from [<c0574e40>] 
(__irq_svc+0x40/0x74)
[    9.347591] Exception stack(0xeb8c3f88 to 0xeb8c3fd0)
[    9.352659] 3f80:                   00000002 00000000 000016aa 
c001ee80 00000001 eb8c2000
[    9.360866] 3fa0: c07e5950 c0840308 c083b480 c07e58f0 c07db3a4 
eb8c3fe0 c07e4244 eb8c3fd8
[    9.369072] 3fc0: c000fddc c000fde0 600f0013 ffffffff
[    9.374144] [<c0574e40>] (__irq_svc) from [<c000fde0>] 
(arch_cpu_idle+0x38/0x3c)
[    9.381573] [<c000fde0>] (arch_cpu_idle) from [<c005bf14>] 
(cpu_startup_entry+0x158/0x2b4)
[    9.389869] [<c005bf14>] (cpu_startup_entry) from [<8000950c>] 
(0x8000950c)
[    9.396855] CPU3: stopping
[    9.399570] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G      D 
4.5.0-rc1-00001-g22a8511 #1
[    9.408299] Hardware name: Keystone
[    9.411805] [<c0016490>] (unwind_backtrace) from [<c0012d44>] 
(show_stack+0x10/0x14)
[    9.419581] [<c0012d44>] (show_stack) from [<c02b3ce4>] 
(dump_stack+0x84/0xc4)
[    9.426829] [<c02b3ce4>] (dump_stack) from [<c00155a4>] 
(handle_IPI+0x2e0/0x2f0)
[    9.434252] [<c00155a4>] (handle_IPI) from [<c0009474>] 
(gic_handle_irq+0x84/0x88)
[    9.441851] [<c0009474>] (gic_handle_irq) from [<c0574e40>] 
(__irq_svc+0x40/0x74)
[    9.449359] Exception stack(0xeb8c5e68 to 0xeb8c5eb0)
[    9.454427] 5e60:                   ebfc5400 00000000 ffff8e72 
000003aa 00000031 00000001
[    9.462633] 5e80: ebfc5400 00000000 c03231fc c0866620 eb8c4000 
c07e4100 ffff8e71 eb8c5eb8
[    9.470839] 5ea0: c0077e9c c0574680 a0000113 ffffffff
[    9.475909] [<c0574e40>] (__irq_svc) from [<c0574680>] 
(_raw_spin_unlock_irq+0x20/0x54)
[    9.483944] [<c0574680>] (_raw_spin_unlock_irq) from [<c0077e9c>] 
(run_timer_softirq+0x18c/0x27c)
[    9.492850] [<c0077e9c>] (run_timer_softirq) from [<c00262a0>] 
(__do_softirq+0xb8/0x330)
[    9.500970] [<c00262a0>] (__do_softirq) from [<c0026778>] 
(irq_exit+0x80/0xb4)
[    9.508221] [<c0026778>] (irq_exit) from [<c006754c>] 
(__handle_domain_irq+0x80/0xec)
[    9.516080] [<c006754c>] (__handle_domain_irq) from [<c0009438>] 
(gic_handle_irq+0x48/0x88)
[    9.524462] [<c0009438>] (gic_handle_irq) from [<c0574e40>] 
(__irq_svc+0x40/0x74)
[    9.531969] Exception stack(0xeb8c5f88 to 0xeb8c5fd0)
[    9.537037] 5f80:                   00000003 00000000 00001b88 
c001ee80 00000001 eb8c4000
[    9.545243] 5fa0: c07e5950 c0840308 c083b480 c07e58f0 c07db3a4 
eb8c5fe0 c07e4244 eb8c5fd8
[    9.553448] 5fc0: c000fddc c000fde0 60000013 ffffffff
[    9.558519] [<c0574e40>] (__irq_svc) from [<c000fde0>] 
(arch_cpu_idle+0x38/0x3c)
[    9.565944] [<c000fde0>] (arch_cpu_idle) from [<c005bf14>] 
(cpu_startup_entry+0x158/0x2b4)
[    9.574239] [<c005bf14>] (cpu_startup_entry) from [<8000950c>] 
(0x8000950c)
[    9.581224] CPU1: stopping
[    9.583940] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D 
4.5.0-rc1-00001-g22a8511 #1
[    9.592668] Hardware name: Keystone
[    9.596172] [<c0016490>] (unwind_backtrace) from [<c0012d44>] 
(show_stack+0x10/0x14)
[    9.603947] [<c0012d44>] (show_stack) from [<c02b3ce4>] 
(dump_stack+0x84/0xc4)
[    9.611196] [<c02b3ce4>] (dump_stack) from [<c00155a4>] 
(handle_IPI+0x2e0/0x2f0)
[    9.618619] [<c00155a4>] (handle_IPI) from [<c0009474>] 
(gic_handle_irq+0x84/0x88)
[    9.626217] [<c0009474>] (gic_handle_irq) from [<c0574e40>] 
(__irq_svc+0x40/0x74)
[    9.633725] Exception stack(0xeb8c1f88 to 0xeb8c1fd0)
[    9.638793] 1f80:                   00000001 00000000 00001ad6 
c001ee80 00000001 eb8c0000
[    9.647000] 1fa0: c07e5950 c0840308 c083b480 c07e58f0 c07db3a4 
eb8c1fe0 c07e4244 eb8c1fd8
[    9.655205] 1fc0: c000fddc c000fde0 60000013 ffffffff
[    9.660276] [<c0574e40>] (__irq_svc) from [<c000fde0>] 
(arch_cpu_idle+0x38/0x3c)
[    9.667701] [<c000fde0>] (arch_cpu_idle) from [<c005bf14>] 
(cpu_startup_entry+0x158/0x2b4)
[    9.675997] [<c005bf14>] (cpu_startup_entry) from [<8000950c>] 
(0x8000950c)
[    9.682986] ---[ end Kernel panic - not syncing: Fatal exception in 
interrupt


Regards,
-Vitaly


From ard.biesheuvel at linaro.org  Mon Feb  1 09:02:34 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 18:02:34 +0100
Subject: [PATCH] ARM: vmlinux.lds: assert that ROM and RAM don't overlap when
 XIP_KERNEL=y
Message-ID: <1454346154-12931-1-git-send-email-ard.biesheuvel@linaro.org>

When building an XIP kernel, the linker produces two disjoint VMA regions,
where the first is mapped onto ROM and the second onto RAM. For this reason,
the linker output pointer '.' is updated halfway through the linker script,
and set to a value that corresponds with the start of the RAM region.

However, in some cases, the ROM region exceeds the expected size, and the
assignment of the output pointer results in a decrement rather than an
increment, causing the virtual addresses of the .data region to clash with
the .text region. Such a kernel cannot boot normally, but it also confuses
the hell out of kallsyms, since .data symbols may appear inside the
[_stext, _etext] or [_sinittext, _einittext] intervals in the first pass,
but not in the second (or vice versa), resulting in inconsistent kallsyms
data.

So let's make sure that the output pointer only advances, and never jumps
back into the ROM region.

Cc: arnd at arndb.de
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm/kernel/vmlinux.lds.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 8b60fde5ce48..950114d533e1 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -229,6 +229,7 @@ SECTIONS
 
 #ifdef CONFIG_XIP_KERNEL
 	__data_loc = ALIGN(4);		/* location in binary */
+	ASSERT(. < PAGE_OFFSET + TEXT_OFFSET, "XIP_KERNEL: ROM and RAM overlap")
 	. = PAGE_OFFSET + TEXT_OFFSET;
 #else
 #ifdef CONFIG_ARM_KERNMEM_PERMS
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb  1 09:08:31 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 1 Feb 2016 18:08:31 +0100
Subject: [PATCH v2 06/21] arm64: KVM: VHE: Patch out use of HVC
In-Reply-To: <56AF85D8.7080907@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-7-git-send-email-marc.zyngier@arm.com>
 <20160201131634.GI1478@cbox> <56AF5ED8.7010303@arm.com>
 <20160201153635.GH15514@e104818-lin.cambridge.arm.com>
 <56AF85D8.7080907@arm.com>
Message-ID: <CAKv+Gu9_KG7Zss3g1OMzcnRKQFhCcYtbSDEk-gwwgqPP-R6DOA@mail.gmail.com>

On 1 February 2016 at 17:20, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 01/02/16 15:36, Catalin Marinas wrote:
>> On Mon, Feb 01, 2016 at 01:34:16PM +0000, Marc Zyngier wrote:
>>> On 01/02/16 13:16, Christoffer Dall wrote:
>>>> On Mon, Jan 25, 2016 at 03:53:40PM +0000, Marc Zyngier wrote:
>>>>> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
>>>>> index 93e8d983..9e0683f 100644
>>>>> --- a/arch/arm64/kvm/hyp/hyp-entry.S
>>>>> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
>>>>> @@ -38,6 +38,32 @@
>>>>>    ldp     x0, x1, [sp], #16
>>>>>  .endm
>>>>>
>>>>> +.macro do_el2_call
>>>>> +  /*
>>>>> +   * Shuffle the parameters before calling the function
>>>>> +   * pointed to in x0. Assumes parameters in x[1,2,3].
>>>>> +   */
>>>>> +  stp     lr, xzr, [sp, #-16]!
>>>>
>>>> remind me why this pair isn't just doing "str" instead of "stp" with the
>>>> xzr ?
>>>
>>> Because SP has to be aligned on a 16 bytes boundary at all times.
>>
>> You could do something like:
>>
>>       sub     sp, sp, #16
>>       str     lr, [sp]
>>
>
> Ah, fair enough. I'll fold that in.
>

Since we're micro-reviewing: what's wrong with

str lr, [sp, #-16]!

?


From santosh.shilimkar at oracle.com  Mon Feb  1 09:10:23 2016
From: santosh.shilimkar at oracle.com (santosh shilimkar)
Date: Mon, 1 Feb 2016 09:10:23 -0800
Subject: [PATCH 1/2] ARM: make virt_to_idmap() return unsigned long
In-Reply-To: <56AF8F54.7030805@ti.com>
References: <E1aO8F2-00074N-E8@rmk-PC.arm.linux.org.uk>
 <56A84748.3040108@oracle.com> <20160201152015.GU10826@n2100.arm.linux.org.uk>
 <56AF8F54.7030805@ti.com>
Message-ID: <56AF917F.9030505@oracle.com>

On 2/1/2016 9:01 AM, Vitaly Andrianov wrote:
>
>
> On 02/01/2016 10:20 AM, Russell King - ARM Linux wrote:
>> On Tue, Jan 26, 2016 at 08:27:52PM -0800, santosh.shilimkar at oracle.com
>> wrote:
>>> On 1/26/16 10:21 AM, Russell King wrote:
>>>> Make virt_to_idmap() return an unsigned long rather than phys_addr_t.
>>>>
>>>> Returning phys_addr_t here makes no sense, because the definition of
>>>> virt_to_idmap() is that it shall return a physical address which maps
>>>> identically with the virtual address.  Since virtual addresses are
>>>> limited to 32-bit, identity mapped physical addresses are as well.
>>>>
>>>> Almost all users already had an implicit narrowing cast to unsigned
>>>> long
>>>> so let's make this official and part of this interface.
>>>>
>>>> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
>>>> ---
>>> Looks correct to me.
>>>
>>> Vitaly,
>>> Could you please try out this patch and see everything continue to
>>> work ?
>>
>> I haven't heard anything yet...  Vitaly?
>>
> Russel, Santosh,
>
> I'm not working with the latest kernel, but with the stable v4.1.y. So I
> couldn't apply the patch to it. I checked out 4.5.0-rc1 and applied the
> patch to it. Tried to boot and it crashed. I'm not sure either because
> of the patch or because of the network driver.
>
Thanks for checking.

> Here is the log:
>
Based on the log, I think the patch seems to work fine since the boot
reached upto rootfs. The crash seems to be coming from mostky NetCP
related compents.

Regards,
Santosh


From heiko at sntech.de  Mon Feb  1 09:16:47 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Mon, 01 Feb 2016 18:16:47 +0100
Subject: [PATCH] ARM: dts: cros-ec-keyboard: Add LOCK key to keyboard
 matrix
In-Reply-To: <1454121504-12683-1-git-send-email-djkurtz@chromium.org>
References: <1454121504-12683-1-git-send-email-djkurtz@chromium.org>
Message-ID: <2283417.UbYyfQa1E3@diego>

Hi Daniel,

Am Samstag, 30. Januar 2016, 10:38:24 schrieb Daniel Kurtz:
> From: James Chao <james_chao at asus.com>
> 
> The LOCK key is at KSO9/KSI3 for Chromebook Flip and other devices
> that use the Chrome OS EC keyboard matrix.
> 
> Signed-off-by: James Chao <james_chao at asus.com>
> Signed-off-by: Daniel Kurtz <djkurtz at chromium.org>
> Signed-off-by: YH Huang <yh.huang at mediatek.com>

that should probably be a 
	Reviewed-by: YH Huang <yh.huang at mediatek.com>
As I don't see any actual patch handling step by him/her.

Also, you might've included Olof as the keeper of all things ChromeOS when 
sending.

@Olof: this seems to be pretty Veyron-specific for the moment, so I'm inclined 
to pick that up. Please holler if you disagree and want to pick it up yourself 
;-)


Thanks
Heiko

> ---
>  arch/arm/boot/dts/cros-ec-keyboard.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/cros-ec-keyboard.dtsi
> b/arch/arm/boot/dts/cros-ec-keyboard.dtsi index 4e42f30c..c045105 100644
> --- a/arch/arm/boot/dts/cros-ec-keyboard.dtsi
> +++ b/arch/arm/boot/dts/cros-ec-keyboard.dtsi
> @@ -55,6 +55,7 @@
>  			MATRIX_KEY(0x03, 0x04, KEY_F5)
>  			MATRIX_KEY(0x03, 0x06, KEY_6)
>  			MATRIX_KEY(0x03, 0x08, KEY_MINUS)
> +			MATRIX_KEY(0x03, 0x09, KEY_F13)
>  			MATRIX_KEY(0x03, 0x0b, KEY_BACKSLASH)
>  			MATRIX_KEY(0x03, 0x0c, KEY_MUHENKAN)



From dianders at chromium.org  Mon Feb  1 09:19:50 2016
From: dianders at chromium.org (Doug Anderson)
Date: Mon, 1 Feb 2016 09:19:50 -0800
Subject: [PATCH] ARM: dts: cros-ec-keyboard: Add LOCK key to keyboard
 matrix
In-Reply-To: <1454121504-12683-1-git-send-email-djkurtz@chromium.org>
References: <1454121504-12683-1-git-send-email-djkurtz@chromium.org>
Message-ID: <CAD=FV=WB274i3r+aYVG4kOtwPzWgmx2E-MfjPcdKfcd7pXUSPA@mail.gmail.com>

Dan,

On Fri, Jan 29, 2016 at 6:38 PM, Daniel Kurtz <djkurtz at chromium.org> wrote:
> From: James Chao <james_chao at asus.com>
>
> The LOCK key is at KSO9/KSI3 for Chromebook Flip and other devices
> that use the Chrome OS EC keyboard matrix.
>
> Signed-off-by: James Chao <james_chao at asus.com>
> Signed-off-by: Daniel Kurtz <djkurtz at chromium.org>
> Signed-off-by: YH Huang <yh.huang at mediatek.com>
> ---
>  arch/arm/boot/dts/cros-ec-keyboard.dtsi | 1 +
>  1 file changed, 1 insertion(+)

Feel free to add:

Reviewed-by: Douglas Anderson <dianders at chromium.org>


From eric.auger at linaro.org  Mon Feb  1 09:27:33 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Mon, 1 Feb 2016 18:27:33 +0100
Subject: [PATCH] vfio: pci: fix oops in case of vfio_msi_set_vector_signal
 failure
In-Reply-To: <1454103676.9301.3.camel@redhat.com>
References: <1454078586-5431-1-git-send-email-eric.auger@linaro.org>
 <1454103676.9301.3.camel@redhat.com>
Message-ID: <56AF9585.1000904@linaro.org>

Hi Alex,
On 01/29/2016 10:41 PM, Alex Williamson wrote:
> On Fri, 2016-01-29 at 14:43 +0000, Eric Auger wrote:
>> In case vfio_msi_set_vector_signal fails we tear down everything.
>> In the tear down loop we compare int j against unsigned start. Given
>> the arithmetic conversion I think it is converted into an unsigned and
>> becomes 0xffffffff, leading to the loop being entered again and things
>> turn bad when accessing vdev->msix[vector].vector. So let's use int
>> parameters instead.
>>  
>> Signed-off-by: Eric Auger <eric.auger at linaro.org>
>> ---
>>  drivers/vfio/pci/vfio_pci_intrs.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>  
>> diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c
>> index 3b3ba15..510c48d 100644
>> --- a/drivers/vfio/pci/vfio_pci_intrs.c
>> +++ b/drivers/vfio/pci/vfio_pci_intrs.c
>> @@ -374,8 +374,8 @@ static int vfio_msi_set_vector_signal(struct vfio_pci_device *vdev,
>>  	return 0;
>>  }
>>  
>> -static int vfio_msi_set_block(struct vfio_pci_device *vdev, unsigned start,
>> -			      unsigned count, int32_t *fds, bool msix)
>> +static int vfio_msi_set_block(struct vfio_pci_device *vdev, int start,
>> +			      int count, int32_t *fds, bool msix)
>>  {
>>  	int i, j, ret = 0;
>>  
> 
> Nice find, I don't think that's the only bug there though.  If @start is
> -1 (UINT32_MAX) and @count is 1, then @j gets set to -1 in the setup and
> we hit the same index dereference problem.  What if we did this instead:
> 
> diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c
> index 3b3ba15..2ae84ad 100644
> --- a/drivers/vfio/pci/vfio_pci_intrs.c
> +++ b/drivers/vfio/pci/vfio_pci_intrs.c
> @@ -309,14 +309,14 @@ static int vfio_msi_set_vector_signal(struct vfio_pci_device *vdev,
>  				      int vector, int fd, bool msix)
>  {
>  	struct pci_dev *pdev = vdev->pdev;
> -	int irq = msix ? vdev->msix[vector].vector : pdev->irq + vector;
> -	char *name = msix ? "vfio-msix" : "vfio-msi";
>  	struct eventfd_ctx *trigger;
> -	int ret;
> +	int irq, ret;
>  
> -	if (vector >= vdev->num_ctx)
> +	if (vector < 0 || vector >= vdev->num_ctx)
>  		return -EINVAL;
>  
> +	irq = msix ? vdev->msix[vector].vector : pdev->irq + vector;
> +
>  	if (vdev->ctx[vector].trigger) {
>  		free_irq(irq, vdev->ctx[vector].trigger);
>  		irq_bypass_unregister_producer(&vdev->ctx[vector].producer);
> @@ -328,8 +328,9 @@ static int vfio_msi_set_vector_signal(struct vfio_pci_device *vdev,
>  	if (fd < 0)
>  		return 0;
>  
> -	vdev->ctx[vector].name = kasprintf(GFP_KERNEL, "%s[%d](%s)",
> -					   name, vector, pci_name(pdev));
> +	vdev->ctx[vector].name = kasprintf(GFP_KERNEL, "vfio-msi%s[%d](%s)",
> +					   msix ? "x" : "", vector,
> +					   pci_name(pdev));
>  	if (!vdev->ctx[vector].name)
>  		return -ENOMEM;
>  
> @@ -379,7 +380,7 @@ static int vfio_msi_set_block(struct vfio_pci_device *vdev, unsigned start,
>  {
>  	int i, j, ret = 0;
>  
> -	if (start + count > vdev->num_ctx)
> +	if (start >= vdev->num_ctx || start + count > vdev->num_ctx)
>  		return -EINVAL;
>  
>  	for (i = 0, j = start; i < count && !ret; i++, j++) {
> @@ -388,7 +389,7 @@ static int vfio_msi_set_block(struct vfio_pci_device *vdev, unsigned start,
>  	}
>  
>  	if (ret) {
> -		for (--j; j >= start; j--)
> +		for (--j; j >= 0 && j >= start; j--)
>  			vfio_msi_set_vector_signal(vdev, j, -1, msix);
>  	}
>  
> 
> So we fix the problem with vfio_msi_set_vector_signal() dereferencing
> the array before it validates the index (even though it shouldn't be
> able to get there anymore), and then we do a better job of verifying
> start and count (comparing to num_ctx will use unsigned even though
> num_ctx itself is signed) and finally explicitly test the <0 case, which
> I suppose we could also do by casting start at that point (we know it's
> within the bounds of a signed integer given the previous tests).

Yes it looks OK to me.

I guess you submit? I will test it.

Best Regards

Eric
> Thanks,
> 
> Alex
> 



From marc.zyngier at arm.com  Mon Feb  1 09:28:32 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 1 Feb 2016 17:28:32 +0000
Subject: [PATCH v2 06/21] arm64: KVM: VHE: Patch out use of HVC
In-Reply-To: <CAKv+Gu9_KG7Zss3g1OMzcnRKQFhCcYtbSDEk-gwwgqPP-R6DOA@mail.gmail.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-7-git-send-email-marc.zyngier@arm.com>
 <20160201131634.GI1478@cbox> <56AF5ED8.7010303@arm.com>
 <20160201153635.GH15514@e104818-lin.cambridge.arm.com>
 <56AF85D8.7080907@arm.com>
 <CAKv+Gu9_KG7Zss3g1OMzcnRKQFhCcYtbSDEk-gwwgqPP-R6DOA@mail.gmail.com>
Message-ID: <56AF95C0.3080006@arm.com>

On 01/02/16 17:08, Ard Biesheuvel wrote:
> On 1 February 2016 at 17:20, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> On 01/02/16 15:36, Catalin Marinas wrote:
>>> On Mon, Feb 01, 2016 at 01:34:16PM +0000, Marc Zyngier wrote:
>>>> On 01/02/16 13:16, Christoffer Dall wrote:
>>>>> On Mon, Jan 25, 2016 at 03:53:40PM +0000, Marc Zyngier wrote:
>>>>>> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
>>>>>> index 93e8d983..9e0683f 100644
>>>>>> --- a/arch/arm64/kvm/hyp/hyp-entry.S
>>>>>> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
>>>>>> @@ -38,6 +38,32 @@
>>>>>>    ldp     x0, x1, [sp], #16
>>>>>>  .endm
>>>>>>
>>>>>> +.macro do_el2_call
>>>>>> +  /*
>>>>>> +   * Shuffle the parameters before calling the function
>>>>>> +   * pointed to in x0. Assumes parameters in x[1,2,3].
>>>>>> +   */
>>>>>> +  stp     lr, xzr, [sp, #-16]!
>>>>>
>>>>> remind me why this pair isn't just doing "str" instead of "stp" with the
>>>>> xzr ?
>>>>
>>>> Because SP has to be aligned on a 16 bytes boundary at all times.
>>>
>>> You could do something like:
>>>
>>>       sub     sp, sp, #16
>>>       str     lr, [sp]
>>>
>>
>> Ah, fair enough. I'll fold that in.
>>
> 
> Since we're micro-reviewing: what's wrong with
> 
> str lr, [sp, #-16]!
> 
> ?
> 

I suspect that on most micro-architectures, a register writeback is
going to be slower than doing the sub independently.

I may be wrong, though.

	M.
-- 
Jazz is not dead. It just smells funny...


From catalin.marinas at arm.com  Mon Feb  1 09:31:21 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 1 Feb 2016 17:31:21 +0000
Subject: [PATCH v5sub1 8/8] arm64: allow kernel Image to be loaded
 anywhere in physical memory
In-Reply-To: <CAKv+Gu8+DdtGQmZtKsB8YOabH1NfzSJge=w0vQwFZPwbQkgYzA@mail.gmail.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-9-git-send-email-ard.biesheuvel@linaro.org>
 <20160201150624.GG15514@e104818-lin.cambridge.arm.com>
 <CAKv+Gu8rgkBWfJXfWzWSkxyKhLOnxirycu-wdcmvRovpDB5hKw@mail.gmail.com>
 <CAKv+Gu8+DdtGQmZtKsB8YOabH1NfzSJge=w0vQwFZPwbQkgYzA@mail.gmail.com>
Message-ID: <20160201173120.GI15514@e104818-lin.cambridge.arm.com>

On Mon, Feb 01, 2016 at 05:31:11PM +0100, Ard Biesheuvel wrote:
> On 1 February 2016 at 16:13, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> > On 1 February 2016 at 16:06, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> On Mon, Feb 01, 2016 at 11:54:53AM +0100, Ard Biesheuvel wrote:
> >>> Note that limiting memory using mem= is not unambiguous anymore after
> >>> this change, considering that the kernel may be at the top of physical
> >>> memory, and clipping from the bottom rather than the top will discard
> >>> any 32-bit DMA addressable memory first. To deal with this, the handling
> >>> of mem= is reimplemented to clip top down, but take special care not to
> >>> clip memory that covers the kernel image.
> >>
> >> I may have forgotten the reason - why do we need to avoid clipping the
> >> memory that covers the kernel image? It's already mapped in the vmalloc
> >> area, so we wouldn't need it in the linear map as well.
> >
> > Good question. Originally, I needed it for swapper_pg_dir, whose
> > pud/pmd/pte levels were accessed via __va() translations of the values
> > found in the higher-up table entries, but after Mark's patches, only
> > the top level pgd of swapper_pg_dir is still used. Similarly, for
> > idmap_pg_dir, we don't change any mappings at runtime so the same
> > applies there I think.
> >
> > I will try dropping this, and see what happens.
> 
> I have given this a spin, and this chokes on
> a) the fact that not all of the translation tables are accessible via
> the linear mapping: the fixmap, due to its vicinity to PCI i/o and
> other populated regions, will share its pud/pmd level tables with
> other users, like ioremap, which traverses the translation tables in
> the ordinary way, i.e., it expects that __va() applied on the phys
> address in the table entry returns something that is mapped

Ah, __va(__pa(x)) is not an identity function and I don't think it's
worth fixing it (the __pa() case is much simpler). But it also means
that we won't be able to remove the kernel image alias in the linear
mapping. It shouldn't be a problem for KASLR as long as we randomise
both kernel image PA and VA.

> b) free_initmem() now calls __free_pages() on a region that we never
> mapped or registered as available.
> 
> So it may be feasible with some hackery, but I wonder if it is worth
> it to complicate the common case for implementing mem= more
> efficiently.

I don't care about efficiency, I was hoping to avoid the additional
arm64-specific memory clipping but it seems that it could easily get
more complicated. So let's leave as it is.

Consider this sub-series merged (I'll push it to -next around -rc3).

Thanks.

-- 
Catalin


From linux at arm.linux.org.uk  Mon Feb  1 09:31:37 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 1 Feb 2016 17:31:37 +0000
Subject: [PATCH 1/2] ARM: make virt_to_idmap() return unsigned long
In-Reply-To: <56AF917F.9030505@oracle.com>
References: <E1aO8F2-00074N-E8@rmk-PC.arm.linux.org.uk>
 <56A84748.3040108@oracle.com>
 <20160201152015.GU10826@n2100.arm.linux.org.uk>
 <56AF8F54.7030805@ti.com> <56AF917F.9030505@oracle.com>
Message-ID: <20160201173137.GV10826@n2100.arm.linux.org.uk>

On Mon, Feb 01, 2016 at 09:10:23AM -0800, santosh shilimkar wrote:
> Based on the log, I think the patch seems to work fine since the boot
> reached upto rootfs. The crash seems to be coming from mostky NetCP
> related compents.

I read the boot log slightly differently - I'm assuming that the
boot log is from the kernel which _will_ be kexec'd from, so we
don't yet know whether the patches work or not.

I looked at the oops, and it's in tasklet_action, but for some
reason the unwinder is unable to unwind and provide a backtrace,
so it's not very debuggable.

However, this is a useful backtrace for me in a different way:
to provide to people who want to deprecate the frame-pointer
based backtracing to prove why the unwinder based solution still
isn't up to the job.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From andre.przywara at arm.com  Mon Feb  1 09:39:20 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon,  1 Feb 2016 17:39:20 +0000
Subject: [PATCH 01/11] irqchip: sun4i: fix compilation outside of arch/arm
In-Reply-To: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1454348370-3816-2-git-send-email-andre.przywara@arm.com>

The Allwinner sunxi specific interrupt controller cannot be compiled
for any architecture except arm:

drivers/irqchip/irq-sun4i.c:25:26: fatal error: asm/mach/irq.h: No such file or directory
compilation terminated.

It turns out that this header is actually not needed for the driver,
so remove it and allow compilation for other architectures like
arm64.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/irqchip/irq-sun4i.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
index 0704362..376b280 100644
--- a/drivers/irqchip/irq-sun4i.c
+++ b/drivers/irqchip/irq-sun4i.c
@@ -22,7 +22,6 @@
 #include <linux/of_irq.h>
 
 #include <asm/exception.h>
-#include <asm/mach/irq.h>
 
 #define SUN4I_IRQ_VECTOR_REG		0x00
 #define SUN4I_IRQ_PROTECTION_REG	0x08
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb  1 09:39:21 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon,  1 Feb 2016 17:39:21 +0000
Subject: [PATCH 02/11] crypto: sunxi-ss: prevent compilation on 64-bit
In-Reply-To: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1454348370-3816-3-git-send-email-andre.przywara@arm.com>

The driver for the sunxi-ss crypto engine is not entirely 64-bit safe,
compilation on arm64 spits some warnings.
The proper fix was deemed to involved [1], so since 64-bit SoCs won't
have this IP block we just disable this driver for 64-bit.

[1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399988.html
     (and the reply)

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 drivers/crypto/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 07d4942..737200f 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -487,7 +487,7 @@ config CRYPTO_DEV_IMGTEC_HASH
 
 config CRYPTO_DEV_SUN4I_SS
 	tristate "Support for Allwinner Security System cryptographic accelerator"
-	depends on ARCH_SUNXI
+	depends on ARCH_SUNXI && !64BIT
 	select CRYPTO_MD5
 	select CRYPTO_SHA1
 	select CRYPTO_AES
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb  1 09:39:19 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon,  1 Feb 2016 17:39:19 +0000
Subject: [PATCH 00/11] arm64: Introduce Allwinner A64 and Pine64 support
Message-ID: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>

Hi,

this series provides initial support for the Allwinner A64 SoC,
which is based on four ARM Cortex-A53 cores implementing the ARMv8
64-bit architecture.
On top of this there is also initial support for the Pine64 board,
for which you can find more information and links in the linux-sunxi
Wiki [1].
The resulting kernel boots fine on my development samples I have
here, though the actual boot process is a bit involved at the moment.
You can find more information and a ready-to-flash image here [2].

The first three patches fix warnings that appear when compiling some
existing Allwinner drivers for arm64.
Patch 4/11 enables the Allwinner/sunxi platform for the arm64
architecture, so one can select the required drivers during
configuration.
Patch 5/11 adds the (currently) inevitable pinctrl driver, this
addresses the comments I got from an earlier post and also fixes
the IRQ banking which I got wrong before.
Patch 6-9 pimp the sunxi clocks drivers to deal with the A64. It adds
a new generic driver for the bus clock gates which relies on DT for
providing the parent relationship. That makes adding new SoCs much
easier, since there should be no more kernel code changes necessary.
Also the sunxi mux clocks learns about the critical-clocks property,
again this moves a previously hard-coded information into the DT.
The final two patches eventually add the A64 .dtsi and the actual
dts files for the two Pine64 board variants.

In the moment we support the basic peripherals like GIC, timer, clocks,
GPIO and UART. The MMC support seems to fail to find the regulator at
the moment, I will send a follow up patch once this is fixed.
Meanwhile you can use an initrd to get to a prompt.

Please have a look and comment on the patches. We might want to split
the series if some patches seem too controversial for being merged
soonish, please let me know if this is the case and I am happy to
rearrange the series.

The patches are based on mripard/sunxi/for-next[3] as of yesterday
and can be found in the repo over here[4].

Cheers,
Andre

[1] http://linux-sunxi.org/Pine64
[2] https://github.com/apritzel/pine64
[3] https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git/log/?h=sunxi/for-next
[4] https://github.com/apritzel/linux/commits/a64-v1

Andre Przywara (11):
  irqchip: sun4i: fix compilation outside of arch/arm
  crypto: sunxi-ss: prevent compilation on 64-bit
  drivers: rtc: allow compilation of sun6i RTC for all sunxi SoCs
  arm64: Introduce Allwinner SoC config option
  drivers: pinctrl: add driver for Allwinner A64 SoC
  clk: sunxi: add generic multi-parent bus clock gates driver
  clk: sunxi: add generic allwinner,sunxi name
  clk: sunxi: improve error reporting for the mux clock
  clk: sunxi: add critical-clocks property to mux clocks
  arm64: dts: add Allwinner A64 SoC .dtsi
  arm64: dts: add Pine64 support

 Documentation/devicetree/bindings/arm/sunxi.txt    |   5 +
 Documentation/devicetree/bindings/clock/sunxi.txt  |   1 +
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 arch/arm64/Kconfig.platforms                       |   7 +
 arch/arm64/boot/dts/Makefile                       |   1 +
 arch/arm64/boot/dts/allwinner/Makefile             |   5 +
 arch/arm64/boot/dts/allwinner/a64.dtsi             | 583 ++++++++++++++++++++
 arch/arm64/boot/dts/allwinner/pine64.dts           |  58 ++
 arch/arm64/boot/dts/allwinner/pine64_common.dtsi   |  76 +++
 arch/arm64/boot/dts/allwinner/pine64_plus.dts      |  59 ++
 drivers/clk/sunxi/Makefile                         |   1 +
 drivers/clk/sunxi/clk-multi-gates.c                | 105 ++++
 drivers/clk/sunxi/clk-sunxi.c                      |  43 +-
 drivers/crypto/Kconfig                             |   2 +-
 drivers/irqchip/irq-sun4i.c                        |   1 -
 drivers/pinctrl/sunxi/Kconfig                      |   4 +
 drivers/pinctrl/sunxi/Makefile                     |   1 +
 drivers/pinctrl/sunxi/pinctrl-a64.c                | 606 +++++++++++++++++++++
 drivers/rtc/Kconfig                                |   7 +-
 20 files changed, 1550 insertions(+), 17 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
 create mode 100644 arch/arm64/boot/dts/allwinner/a64.dtsi
 create mode 100644 arch/arm64/boot/dts/allwinner/pine64.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/pine64_common.dtsi
 create mode 100644 arch/arm64/boot/dts/allwinner/pine64_plus.dts
 create mode 100644 drivers/clk/sunxi/clk-multi-gates.c
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c

-- 
2.6.4



From andre.przywara at arm.com  Mon Feb  1 09:39:22 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon,  1 Feb 2016 17:39:22 +0000
Subject: [PATCH 03/11] drivers: rtc: allow compilation of sun6i RTC for all
 sunxi SoCs
In-Reply-To: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1454348370-3816-4-git-send-email-andre.przywara@arm.com>

At the moment the "sun6i" RTC drivers depends on having two specific
SoC families selected.
The Allwinner A64 SoC has the same RTC, so extend the Kconfig option
to allow inclusion of the driver for all Allwinner SoCs.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 drivers/rtc/Kconfig | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 376322f..526eaf4 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1360,10 +1360,11 @@ config RTC_DRV_SUN4V
 
 config RTC_DRV_SUN6I
 	tristate "Allwinner A31 RTC"
-	depends on MACH_SUN6I || MACH_SUN8I
+	default MACH_SUN6I || MACH_SUN8I
+	depends on ARCH_SUNXI
 	help
-	  If you say Y here you will get support for the RTC found on
-	  Allwinner A31.
+	  If you say Y here you will get support for the RTC found in
+	  some Allwinner SoCs like the A31 or the A64.
 
 config RTC_DRV_SUNXI
 	tristate "Allwinner sun4i/sun7i RTC"
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb  1 09:39:23 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon,  1 Feb 2016 17:39:23 +0000
Subject: [PATCH 04/11] arm64: Introduce Allwinner SoC config option
In-Reply-To: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1454348370-3816-5-git-send-email-andre.przywara@arm.com>

To prepare for the Allwinner A64 SoC support, introduce a config
option to allow compiling Allwinner (aka. sunxi) specific drivers
for the arm64 architecture as well.
This patch just defines the ARCH_SUNXI symbol to allow Allwinner
specific drivers to be selected during kernel configuration.
Since the MMC driver is quite essential for Linux to be useful, select
it by default.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 arch/arm64/Kconfig.platforms | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f6..fc7cf4b 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -1,5 +1,11 @@
 menu "Platform selection"
 
+config ARCH_SUNXI
+	bool "Allwinner sunxi 64-bit SoC Family"
+	select SUNXI_MMC
+	help
+	  This enables support for Allwinner sunxi based SoCs like the A64.
+
 config ARCH_BCM_IPROC
 	bool "Broadcom iProc SoC Family"
 	help
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb  1 09:39:27 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon,  1 Feb 2016 17:39:27 +0000
Subject: [PATCH 08/11] clk: sunxi: improve error reporting for the mux clock
In-Reply-To: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1454348370-3816-9-git-send-email-andre.przywara@arm.com>

clk_register_mux returns a pointer wrapped error value in case of
failure, so a simple NULL check is not sufficient to catch errors.
Fix that and elaborate on the failure reason on the way. The whole
function does not return any error value, so silently failing may
leave users scratching their heads because the kernel does not
provide any clues on what's wrong.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index efcce85..9416e0f3 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -627,17 +627,29 @@ static void __init sunxi_mux_clk_setup(struct device_node *node,
 	reg = of_iomap(node, 0);
 
 	i = of_clk_parent_fill(node, parents, SUNXI_MAX_PARENTS);
-	of_property_read_string(node, "clock-output-names", &clk_name);
+	if (of_property_read_string(node, "clock-output-names", &clk_name)) {
+		pr_warn("%s: could not read clock-output-names for \"%s\"\n",
+			__func__, clk_name);
+		goto out_unmap;
+	}
 
 	clk = clk_register_mux(NULL, clk_name, parents, i,
 			       CLK_SET_RATE_PARENT, reg,
 			       data->shift, SUNXI_MUX_GATE_WIDTH,
 			       0, &clk_lock);
 
-	if (clk) {
-		of_clk_add_provider(node, of_clk_src_simple_get, clk);
-		clk_register_clkdev(clk, clk_name, NULL);
+	if (IS_ERR(clk)) {
+		pr_warn("%s: failed to register mux clock %s: %ld\n", __func__,
+			clk_name, PTR_ERR(clk));
+		goto out_unmap;
 	}
+
+	of_clk_add_provider(node, of_clk_src_simple_get, clk);
+	clk_register_clkdev(clk, clk_name, NULL);
+	return;
+
+out_unmap:
+	iounmap(reg);
 }
 
 
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb  1 09:39:26 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon,  1 Feb 2016 17:39:26 +0000
Subject: [PATCH 07/11] clk: sunxi: add generic allwinner,sunxi name
In-Reply-To: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1454348370-3816-8-git-send-email-andre.przywara@arm.com>

The only difference between the different compatible matches at the
end of clk-sunxi.c are the critical clocks. Two SoCs get away so far
without any, so there is no reason to enumerate those SoCs in here
explicitly, though we have to keep them in for compatibility reasons.

Rename the init function to highlight this generic feature and add a
new, generic DT compatible string which can be used as a fallback value
in the future should a particular SoC don't need any special treatment.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 Documentation/devicetree/bindings/arm/sunxi.txt |  4 ++++
 drivers/clk/sunxi/clk-sunxi.c                   | 14 ++++++--------
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
index 7e79fcc..980e065 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,3 +14,7 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h3
   allwinner,sun9i-a80
+
+For Allwinner SoCs without any specific needs the generic fallback value of:
+  allwinner,sunxi
+can be used.
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index e460a6b..efcce85 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -1052,14 +1052,12 @@ CLK_OF_DECLARE(sun8i_a23_clk_init, "allwinner,sun8i-a23", sun6i_init_clocks);
 CLK_OF_DECLARE(sun8i_a33_clk_init, "allwinner,sun8i-a33", sun6i_init_clocks);
 CLK_OF_DECLARE(sun8i_h3_clk_init, "allwinner,sun8i-h3", sun6i_init_clocks);
 
-static void __init sun8i_a83t_init_clocks(struct device_node *node)
+static void __init sunxi_generic_init_clocks(struct device_node *node)
 {
 	sunxi_init_clocks(NULL, 0);
 }
-CLK_OF_DECLARE(sun8i_a83t_clk_init, "allwinner,sun8i-a83t", sun8i_a83t_init_clocks);
-
-static void __init sun9i_init_clocks(struct device_node *node)
-{
-	sunxi_init_clocks(NULL, 0);
-}
-CLK_OF_DECLARE(sun9i_a80_clk_init, "allwinner,sun9i-a80", sun9i_init_clocks);
+CLK_OF_DECLARE(sun8i_a83t_clk_init, "allwinner,sun8i-a83t",
+	       sunxi_generic_init_clocks);
+CLK_OF_DECLARE(sun9i_a80_clk_init, "allwinner,sun9i-a80",
+	       sunxi_generic_init_clocks);
+CLK_OF_DECLARE(sunxi_clk_init, "allwinner,sunxi", sunxi_generic_init_clocks);
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb  1 09:39:28 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon,  1 Feb 2016 17:39:28 +0000
Subject: [PATCH 09/11] clk: sunxi: add critical-clocks property to mux clocks
In-Reply-To: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1454348370-3816-10-git-send-email-andre.przywara@arm.com>

The only reason we match the different root compatible strings when
registering the different sunxi clock types is to provide a list of
critical clocks.
Tell the mux clock (for a start) to get this property from the
device tree, allowing new SoCs to refer to the generic fallback
compatible string when the DT provides the critical clock information.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 9416e0f3..e1e5a8f 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -644,6 +644,11 @@ static void __init sunxi_mux_clk_setup(struct device_node *node,
 		goto out_unmap;
 	}
 
+	if (of_property_read_bool(node, "critical-clocks")) {
+		pr_debug("marked clock %s as critical\n", clk_name);
+		clk_prepare_enable(clk);
+	}
+
 	of_clk_add_provider(node, of_clk_src_simple_get, clk);
 	clk_register_clkdev(clk, clk_name, NULL);
 	return;
@@ -1064,6 +1069,10 @@ CLK_OF_DECLARE(sun8i_a23_clk_init, "allwinner,sun8i-a23", sun6i_init_clocks);
 CLK_OF_DECLARE(sun8i_a33_clk_init, "allwinner,sun8i-a33", sun6i_init_clocks);
 CLK_OF_DECLARE(sun8i_h3_clk_init, "allwinner,sun8i-h3", sun6i_init_clocks);
 
+/*
+ * Those SoCs here either don't have a specific critical clock to
+ * protect or they mark the critical clocks as such in their DT.
+ */
 static void __init sunxi_generic_init_clocks(struct device_node *node)
 {
 	sunxi_init_clocks(NULL, 0);
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb  1 09:39:25 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon,  1 Feb 2016 17:39:25 +0000
Subject: [PATCH 06/11] clk: sunxi: add generic multi-parent bus clock gates
 driver
In-Reply-To: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1454348370-3816-7-git-send-email-andre.przywara@arm.com>

The Allwinner H3 SoC introduced bus clock gates with potentially
different parents per clock gate. The H3 driver chose to hardcode the
actual parent clock relation in the code.
Add a new driver (which has the potential to drive the H3 and also
the simple clock gates as well) which uses the power of DT to describe
this relationship in an elegant and flexible way.
Using one subnode for every parent clock we get away with a single
DT compatible match, which can be used as a fallback value in the
actual DTs without the need to add specific compatible strings to the
code.  This avoids adding a new driver or function for every new SoC.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
Changelog RFC .. v1:
- fix IRQ muxes to cover the three banks of the SoC
- amend naming of PCM pins

 drivers/clk/sunxi/Makefile          |   1 +
 drivers/clk/sunxi/clk-multi-gates.c | 105 ++++++++++++++++++++++++++++++++++++
 2 files changed, 106 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk-multi-gates.c

diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 3fd7901..3a9dc31 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -11,6 +11,7 @@ obj-y += clk-a10-ve.o
 obj-y += clk-a20-gmac.o
 obj-y += clk-mod0.o
 obj-y += clk-simple-gates.o
+obj-y += clk-multi-gates.o
 obj-y += clk-sun8i-bus-gates.o
 obj-y += clk-sun8i-mbus.o
 obj-y += clk-sun9i-core.o
diff --git a/drivers/clk/sunxi/clk-multi-gates.c b/drivers/clk/sunxi/clk-multi-gates.c
new file mode 100644
index 0000000..76e715a
--- /dev/null
+++ b/drivers/clk/sunxi/clk-multi-gates.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ *
+ * Based on clk-sun8i-bus-gates.c, which is:
+ *  Copyright (C) 2015 Jens Kuske <jenskuske at gmail.com>
+ * Based on clk-simple-gates.c, which is:
+ *  Copyright 2015 Maxime Ripard <maxime.ripard at free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+
+static DEFINE_SPINLOCK(gates_lock);
+
+static void __init sunxi_parse_parent(struct device_node *node,
+				      struct clk_onecell_data *clk_data,
+				      void __iomem *reg)
+{
+	const char *parent = of_clk_get_parent_name(node, 0);
+	const char *clk_name;
+	struct property *prop;
+	struct clk *clk;
+	const __be32 *p;
+	int index, i = 0;
+
+	of_property_for_each_u32(node, "clock-indices", prop, p, index) {
+		of_property_read_string_index(node, "clock-output-names",
+					      i, &clk_name);
+
+		clk = clk_register_gate(NULL, clk_name, parent, 0,
+					reg + 4 * (index / 32), index % 32,
+					0, &gates_lock);
+		i++;
+		if (IS_ERR(clk)) {
+			pr_warn("could not register gate clock \"%s\"\n",
+				clk_name);
+			continue;
+		}
+		if (clk_data->clks[index])
+			pr_warn("bus-gate clock %s: index #%d already registered as %s\n",
+				clk_name, index, "?");
+		else
+			clk_data->clks[index] = clk;
+	}
+}
+
+static void __init sunxi_multi_bus_gates_init(struct device_node *node)
+{
+	struct clk_onecell_data *clk_data;
+	struct device_node *child;
+	struct property *prop;
+	struct resource res;
+	void __iomem *reg;
+	const __be32 *p;
+	int number = 0;
+	int index;
+
+	reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+	if (IS_ERR(reg))
+		return;
+
+	clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
+	if (!clk_data)
+		goto err_unmap;
+
+	for_each_child_of_node(node, child)
+		of_property_for_each_u32(child, "clock-indices", prop, p, index)
+			number = max(number, index);
+
+	clk_data->clks = kcalloc(number + 1, sizeof(struct clk *), GFP_KERNEL);
+	if (!clk_data->clks)
+		goto err_free_data;
+
+	for_each_child_of_node(node, child)
+		sunxi_parse_parent(child, clk_data, reg);
+
+	clk_data->clk_num = number + 1;
+	if (of_clk_add_provider(node, of_clk_src_onecell_get, clk_data))
+		pr_err("registering bus-gate clock %s failed\n", node->name);
+
+	return;
+
+err_free_data:
+	kfree(clk_data);
+err_unmap:
+	iounmap(reg);
+	of_address_to_resource(node, 0, &res);
+	release_mem_region(res.start, resource_size(&res));
+}
+
+CLK_OF_DECLARE(sunxi_multi_bus_gates, "allwinner,sunxi-multi-bus-gates-clk",
+	       sunxi_multi_bus_gates_init);
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb  1 09:39:30 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon,  1 Feb 2016 17:39:30 +0000
Subject: [PATCH 11/11] arm64: dts: add Pine64 support
In-Reply-To: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1454348370-3816-12-git-send-email-andre.przywara@arm.com>

The Pine64 is a cost-efficient development board based on the
Allwinner A64 SoC.
There are three models: the basic version with Fast Ethernet and
512 MB of DRAM (Pine64) and two Pine64+ versions, which both
feature Gigabit Ethernet and additional connectors for touchscreens
and a camera. Or as my son put it: "Those are smaller and these are
missing." ;-)
The two Pine64+ models just differ in the amount of DRAM
(1GB vs. 2GB). Since U-Boot will figure out the right size for us and
patches the DT accordingly we just need to provide one DT for the
Pine64+.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 .../devicetree/bindings/vendor-prefixes.txt        |  1 +
 arch/arm64/boot/dts/Makefile                       |  1 +
 arch/arm64/boot/dts/allwinner/Makefile             |  5 ++
 arch/arm64/boot/dts/allwinner/pine64.dts           | 58 +++++++++++++++++
 arch/arm64/boot/dts/allwinner/pine64_common.dtsi   | 76 ++++++++++++++++++++++
 arch/arm64/boot/dts/allwinner/pine64_plus.dts      | 59 +++++++++++++++++
 6 files changed, 200 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
 create mode 100644 arch/arm64/boot/dts/allwinner/pine64.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/pine64_common.dtsi
 create mode 100644 arch/arm64/boot/dts/allwinner/pine64_plus.dts

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 72e2c5a..0c22fa9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -175,6 +175,7 @@ parade	Parade Technologies Inc.
 pericom	Pericom Technology Inc.
 phytec	PHYTEC Messtechnik GmbH
 picochip	Picochip Ltd
+pine64	Pine64
 plathome	Plat'Home Co., Ltd.
 plda	PLDA
 pixcir  PIXCIR MICROELECTRONICS Co., Ltd
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index f832b8a..3b7428a 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,3 +1,4 @@
+dts-dirs += allwinner
 dts-dirs += altera
 dts-dirs += amd
 dts-dirs += apm
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
new file mode 100644
index 0000000..65f4e24
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_SUNXI) += pine64_plus.dtb pine64.dtb
+
+always		:= $(dtb-y)
+subdir-y	:= $(dts-dirs)
+clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/allwinner/pine64.dts b/arch/arm64/boot/dts/allwinner/pine64.dts
new file mode 100644
index 0000000..ebea5dd
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/pine64.dts
@@ -0,0 +1,58 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "pine64_common.dtsi"
+
+/ {
+	model = "Pine64";
+	compatible = "pine64,pine64", "allwinner,a64", "allwinner,sunxi";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory {
+		reg = <0x40000000 0x20000000>;
+	};
+};
diff --git a/arch/arm64/boot/dts/allwinner/pine64_common.dtsi b/arch/arm64/boot/dts/allwinner/pine64_common.dtsi
new file mode 100644
index 0000000..d968d76
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/pine64_common.dtsi
@@ -0,0 +1,76 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "a64.dtsi"
+
+&mmc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc0_pins>, <&mmc0_default_cd_pin>;
+	vmmc-supply = <&reg_vcc3v3>;
+	cd-gpios = <&pio 5 6 0>;
+	cd-inverted;
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins_a>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart2_pins>;
+	status = "okay";
+};
+
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart3_pins_a>;
+	status = "okay";
+};
+
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart4_pins>;
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/allwinner/pine64_plus.dts b/arch/arm64/boot/dts/allwinner/pine64_plus.dts
new file mode 100644
index 0000000..344752e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/pine64_plus.dts
@@ -0,0 +1,59 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "pine64_common.dtsi"
+
+/ {
+	model = "Pine64+";
+	compatible = "pine64,pine64_plus", "allwinner,a64", "allwinner,sunxi";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	/* There is a model with 2GB of DRAM, but U-Boot fixes this for us. */
+	memory {
+		reg = <0x40000000 0x40000000>;
+	};
+};
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb  1 09:39:29 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon,  1 Feb 2016 17:39:29 +0000
Subject: [PATCH 10/11] arm64: dts: add Allwinner A64 SoC .dtsi
In-Reply-To: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1454348370-3816-11-git-send-email-andre.przywara@arm.com>

The Allwinner A64 SoC is low-cost SoC with 4 ARM Cortex-A53 cores
and the typical tablet / TV box peripherals.
The Soc is based on the (32-bit) Allwinner H3 chip, sharing most of
the peripherals and the memory map.
Although the cores are proper 64-bit ones, the whole SoC is actually
limited to 4GB (including all the supported DRAM), so we use 32-bit
address and size cells. This has the nice feature of us being able to
reuse the DT for 32-bit kernels as well.
This .dtsi lists the hardware that we support so far.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 Documentation/devicetree/bindings/arm/sunxi.txt   |   1 +
 Documentation/devicetree/bindings/clock/sunxi.txt |   1 +
 arch/arm64/boot/dts/allwinner/a64.dtsi            | 583 ++++++++++++++++++++++
 3 files changed, 585 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/a64.dtsi

diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
index 980e065..4a83853 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,6 +14,7 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h3
   allwinner,sun9i-a80
+  allwinner,a64
 
 For Allwinner SoCs without any specific needs the generic fallback value of:
   allwinner,sunxi
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index e59f57b..44b0c6c 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -77,6 +77,7 @@ Required properties:
 	"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
 	"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
 	"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
+	"allwinner,a64-bus-gates-clk" - for the A64 multi-parent bus gates clock
 
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
diff --git a/arch/arm64/boot/dts/allwinner/a64.dtsi b/arch/arm64/boot/dts/allwinner/a64.dtsi
new file mode 100644
index 0000000..8dce10f
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/a64.dtsi
@@ -0,0 +1,583 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ * based on the Allwinner H3 dtsi:
+ *    Copyright (C) 2015 Jens Kuske <jenskuske at gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+	compatible = "allwinner,a64", "allwinner,sunxi";
+	interrupt-parent = <&gic>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		serial4 = &uart4;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <0>;
+			enable-method = "psci";
+		};
+
+		cpu at 1 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <1>;
+			enable-method = "psci";
+		};
+
+		cpu at 2 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <2>;
+			enable-method = "psci";
+		};
+
+		cpu at 3 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <3>;
+			enable-method = "psci";
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2", "arm,psci";
+		method = "smc";
+		cpu_suspend = <0xc4000001>;
+		cpu_off = <0x84000002>;
+		cpu_on = <0xc4000003>;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x40000000 0>;
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		osc24M: osc24M_clk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <24000000>;
+			clock-output-names = "osc24M";
+		};
+
+		osc32k: osc32k_clk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <32768>;
+			clock-output-names = "osc32k";
+		};
+
+		pll1: clk at 01c20000 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun8i-a23-pll1-clk";
+			reg = <0x01c20000 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll1";
+		};
+
+		pll6: clk at 01c20028 {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun6i-a31-pll6-clk";
+			reg = <0x01c20028 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll6", "pll6x2";
+		};
+
+		pll6d2: pll6d2_clk {
+			#clock-cells = <0>;
+			compatible = "fixed-factor-clock";
+			clock-div = <2>;
+			clock-mult = <1>;
+			clocks = <&pll6 0>;
+			clock-output-names = "pll6d2";
+		};
+
+		/* dummy clock until pll6 can be reused */
+		pll8: pll8_clk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <1>;
+			clock-output-names = "pll8";
+		};
+
+		cpu: cpu_clk at 01c20050 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-cpu-clk";
+			reg = <0x01c20050 0x4>;
+			clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
+			clock-output-names = "cpu";
+			critical-clocks = <0>;
+		};
+
+		axi: axi_clk at 01c20050 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-axi-clk";
+			reg = <0x01c20050 0x4>;
+			clocks = <&cpu>;
+			clock-output-names = "axi";
+		};
+
+		ahb1: ahb1_clk at 01c20054 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun6i-a31-ahb1-clk";
+			reg = <0x01c20054 0x4>;
+			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
+			clock-output-names = "ahb1";
+		};
+
+		ahb2: ahb2_clk at 01c2005c {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun8i-h3-ahb2-clk";
+			reg = <0x01c2005c 0x4>;
+			clocks = <&ahb1>, <&pll6d2>;
+			clock-output-names = "ahb2";
+		};
+
+		apb1: apb1_clk at 01c20054 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-apb0-clk";
+			reg = <0x01c20054 0x4>;
+			clocks = <&ahb1>;
+			clock-output-names = "apb1";
+		};
+
+		apb2: apb2_clk at 01c20058 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-apb1-clk";
+			reg = <0x01c20058 0x4>;
+			clocks = <&osc32k>, <&osc24M>, <&pll6 1>, <&pll6 1>;
+			clock-output-names = "apb2";
+		};
+
+		bus_gates: clk at 01c20060 {
+			#clock-cells = <1>;
+			compatible = "allwinner,a64-bus-gates-clk",
+				     "allwinner,sunxi-multi-bus-gates-clk";
+			reg = <0x01c20060 0x14>;
+			ahb1_parent {
+				clocks = <&ahb1>;
+				clock-indices = <1>, <5>,
+						<6>, <8>,
+						<9>, <10>,
+						<13>, <14>,
+						<18>, <19>,
+						<20>, <21>,
+						<23>, <24>,
+						<25>, <28>,
+						<32>, <35>,
+						<36>, <37>,
+						<40>, <43>,
+						<44>, <52>,
+						<53>, <54>,
+						<135>;
+				clock-output-names = "bus_mipidsi", "bus_ce",
+						"bus_dma", "bus_mmc0",
+						"bus_mmc1", "bus_mmc2",
+						"bus_nand", "bus_sdram",
+						"bus_ts", "bus_hstimer",
+						"bus_spi0", "bus_spi1",
+						"bus_otg", "bus_otg_ehci0",
+						"bus_ehci0", "bus_otg_ohci0",
+						"bus_ve", "bus_lcd0",
+						"bus_lcd1", "bus_deint",
+						"bus_csi", "bus_hdmi",
+						"bus_de", "bus_gpu",
+						"bus_msgbox", "bus_spinlock",
+						"bus_dbg";
+			};
+			ahb2_parent {
+				clocks = <&ahb2>;
+				clock-indices = <17>, <29>;
+				clock-output-names = "bus_gmac", "bus_ohci0";
+			};
+			apb1_parent {
+				clocks = <&apb1>;
+				clock-indices = <64>, <65>,
+						<69>, <72>,
+						<76>, <77>,
+						<78>;
+				clock-output-names = "bus_codec", "bus_spdif",
+						"bus_pio", "bus_ths",
+						"bus_i2s0", "bus_i2s1",
+						"bus_i2s2";
+			};
+			abp2_parent {
+				clocks = <&apb2>;
+				clock-indices = <96>, <97>,
+						<98>, <101>,
+						<112>, <113>,
+						<114>, <115>,
+						<116>;
+				clock-output-names = "bus_i2c0", "bus_i2c1",
+						"bus_i2c2", "bus_scr",
+						"bus_uart0", "bus_uart1",
+						"bus_uart2", "bus_uart3",
+						"bus_uart4";
+			};
+		};
+
+		mmc0_clk: clk at 01c20088 {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun4i-a10-mmc-clk";
+			reg = <0x01c20088 0x4>;
+			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
+			clock-output-names = "mmc0",
+					     "mmc0_output",
+					     "mmc0_sample";
+		};
+
+		mmc1_clk: clk at 01c2008c {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun4i-a10-mmc-clk";
+			reg = <0x01c2008c 0x4>;
+			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
+			clock-output-names = "mmc1",
+					     "mmc1_output",
+					     "mmc1_sample";
+		};
+
+		mmc2_clk: clk at 01c20090 {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun4i-a10-mmc-clk";
+			reg = <0x01c20090 0x4>;
+			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
+			clock-output-names = "mmc2",
+					     "mmc2_output",
+					     "mmc2_sample";
+		};
+	};
+
+	regulators {
+		reg_vcc3v3: vcc3v3 {
+			compatible = "regulator-fixed";
+			regulator-name = "vcc3v3";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+		};
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		mmc0: mmc at 01c0f000 {
+			compatible = "allwinner,sun5i-a13-mmc";
+			reg = <0x01c0f000 0x1000>;
+			clocks = <&bus_gates 8>,
+				 <&mmc0_clk 0>,
+				 <&mmc0_clk 1>,
+				 <&mmc0_clk 2>;
+			clock-names = "ahb",
+				      "mmc",
+				      "output",
+				      "sample";
+			resets = <&ahb_rst 8>;
+			reset-names = "ahb";
+			interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mmc1: mmc at 01c10000 {
+			compatible = "allwinner,sun5i-a13-mmc";
+			reg = <0x01c10000 0x1000>;
+			clocks = <&bus_gates 9>,
+				 <&mmc1_clk 0>,
+				 <&mmc1_clk 1>,
+				 <&mmc1_clk 2>;
+			clock-names = "ahb",
+				      "mmc",
+				      "output",
+				      "sample";
+			resets = <&ahb_rst 9>;
+			reset-names = "ahb";
+			interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mmc2: mmc at 01c11000 {
+			compatible = "allwinner,sun5i-a13-mmc";
+			reg = <0x01c11000 0x1000>;
+			clocks = <&bus_gates 10>,
+				 <&mmc2_clk 0>,
+				 <&mmc2_clk 1>,
+				 <&mmc2_clk 2>;
+			clock-names = "ahb",
+				      "mmc",
+				      "output",
+				      "sample";
+			resets = <&ahb_rst 10>;
+			reset-names = "ahb";
+			interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		pio: pinctrl at 01c20800 {
+			compatible = "allwinner,a64-pinctrl";
+			reg = <0x01c20800 0x400>;
+			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&bus_gates 69>;
+			gpio-controller;
+			#gpio-cells = <3>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+
+			uart0_pins_a: uart0 at 0 {
+				allwinner,pins = "PB8", "PB9";
+				allwinner,function = "uart0";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart0_pins_b: uart0 at 1 {
+				allwinner,pins = "PF2", "PF3";
+				allwinner,function = "uart0";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart1_pins: uart1 at 0 {
+				allwinner,pins = "PG6", "PG7", "PG8", "PG9";
+				allwinner,function = "uart1";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart2_pins: uart2 at 0 {
+				allwinner,pins = "PB0", "PB1", "PB2", "PB3";
+				allwinner,function = "uart2";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart3_pins_a: uart3 at 0 {
+				allwinner,pins = "PD0", "PD1";
+				allwinner,function = "uart3";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart3_pins_b: uart3 at 1 {
+				allwinner,pins = "PH4", "PH5", "PH6", "PH7";
+				allwinner,function = "uart3";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart4_pins: uart4 at 0 {
+				allwinner,pins = "PD2", "PD3", "PD4", "PD5";
+				allwinner,function = "uart4";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			mmc0_pins: mmc0 at 0 {
+				allwinner,pins = "PF0", "PF1", "PF2", "PF3",
+						 "PF4", "PF5";
+				allwinner,function = "mmc0";
+				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			mmc0_default_cd_pin: mmc0_cd_pin at 0 {
+				allwinner,pins = "PF6";
+				allwinner,function = "gpio_in";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+			};
+
+			mmc1_pins: mmc1 at 0 {
+				allwinner,pins = "PG0", "PG1", "PG2", "PG3",
+						 "PG4", "PG5";
+				allwinner,function = "mmc1";
+				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			mmc2_pins: mmc2 at 0 {
+				allwinner,pins = "PC1", "PC5", "PC6", "PC8",
+						 "PC9", "PC10";
+				allwinner,function = "mmc2";
+				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+		};
+
+		ahb_rst: reset at 01c202c0 {
+			#reset-cells = <1>;
+			compatible = "allwinner,sun6i-a31-ahb1-reset";
+			reg = <0x01c202c0 0xc>;
+		};
+
+		apb1_rst: reset at 01c202d0 {
+			#reset-cells = <1>;
+			compatible = "allwinner,sun6i-a31-clock-reset";
+			reg = <0x01c202d0 0x4>;
+		};
+
+		apb2_rst: reset at 01c202d8 {
+			#reset-cells = <1>;
+			compatible = "allwinner,sun6i-a31-clock-reset";
+			reg = <0x01c202d8 0x4>;
+		};
+
+		uart0: serial at 01c28000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28000 0x400>;
+			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&bus_gates 112>;
+			resets = <&apb2_rst 16>;
+			reset-names = "apb2";
+			status = "disabled";
+		};
+
+		uart1: serial at 01c28400 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28400 0x400>;
+			interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&bus_gates 113>;
+			resets = <&apb2_rst 17>;
+			reset-names = "apb2";
+			status = "disabled";
+		};
+
+		uart2: serial at 01c28800 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28800 0x400>;
+			interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&bus_gates 114>;
+			resets = <&apb2_rst 18>;
+			reset-names = "apb2";
+			status = "disabled";
+		};
+
+		uart3: serial at 01c28c00 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28c00 0x400>;
+			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&bus_gates 115>;
+			resets = <&apb2_rst 19>;
+			reset-names = "apb2";
+			status = "disabled";
+		};
+
+		uart4: serial at 01c29000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c29000 0x400>;
+			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&bus_gates 116>;
+			resets = <&apb2_rst 20>;
+			reset-names = "apb2";
+			status = "disabled";
+		};
+
+		rtc: rtc at 01f00000 {
+			compatible = "allwinner,sun6i-a31-rtc";
+			reg = <0x01f00000 0x54>;
+			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+		};
+	};
+
+	gic: interrupt-controller@{
+		compatible = "arm,gic-400";
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+
+		reg = <0x01C81000 0x1000>,
+		      <0x01C82000 0x2000>,
+		      <0x01C84000 0x2000>,
+		      <0x01C86000 0x2000>;
+		interrupts = <GIC_PPI 9
+		      (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+};
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb  1 09:39:24 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon,  1 Feb 2016 17:39:24 +0000
Subject: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
In-Reply-To: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1454348370-3816-6-git-send-email-andre.przywara@arm.com>

Based on the Allwinner A64 user manual and on the previous sunxi
pinctrl drivers this introduces the pin multiplex assignments for
the ARMv8 Allwinner A64 SoC.
Port A is apparently used for the fixed function DRAM controller, so
the ports start at B here (the manual mentions "n from 1 to 7", so
not starting at 0).

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 arch/arm64/Kconfig.platforms                       |   1 +
 drivers/pinctrl/sunxi/Kconfig                      |   4 +
 drivers/pinctrl/sunxi/Makefile                     |   1 +
 drivers/pinctrl/sunxi/pinctrl-a64.c                | 606 +++++++++++++++++++++
 5 files changed, 613 insertions(+)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c

diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index 9213b27..9050002 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -21,6 +21,7 @@ Required properties:
   "allwinner,sun9i-a80-r-pinctrl"
   "allwinner,sun8i-a83t-pinctrl"
   "allwinner,sun8i-h3-pinctrl"
+  "allwinner,a64-pinctrl"
 
 - reg: Should contain the register physical address and length for the
   pin controller.
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index fc7cf4b..03f0f9d 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -2,6 +2,7 @@ menu "Platform selection"
 
 config ARCH_SUNXI
 	bool "Allwinner sunxi 64-bit SoC Family"
+	select PINCTRL_A64
 	select SUNXI_MMC
 	help
 	  This enables support for Allwinner sunxi based SoCs like the A64.
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index f8dbc8b..68873f2 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -64,4 +64,8 @@ config PINCTRL_SUN9I_A80_R
 	depends on RESET_CONTROLLER
 	select PINCTRL_SUNXI_COMMON
 
+config PINCTRL_A64
+	bool
+	select PINCTRL_SUNXI_COMMON
+
 endif
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index ef82f22..e00ccde 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_PINCTRL_SUN7I_A20)		+= pinctrl-sun7i-a20.o
 obj-$(CONFIG_PINCTRL_SUN8I_A23)		+= pinctrl-sun8i-a23.o
 obj-$(CONFIG_PINCTRL_SUN8I_A23_R)	+= pinctrl-sun8i-a23-r.o
 obj-$(CONFIG_PINCTRL_SUN8I_A33)		+= pinctrl-sun8i-a33.o
+obj-$(CONFIG_PINCTRL_A64)		+= pinctrl-a64.o
 obj-$(CONFIG_PINCTRL_SUN8I_A83T)	+= pinctrl-sun8i-a83t.o
 obj-$(CONFIG_PINCTRL_SUN8I_H3)		+= pinctrl-sun8i-h3.o
 obj-$(CONFIG_PINCTRL_SUN9I_A80)		+= pinctrl-sun9i-a80.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-a64.c b/drivers/pinctrl/sunxi/pinctrl-a64.c
new file mode 100644
index 0000000..e72b079
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-a64.c
@@ -0,0 +1,606 @@
+/*
+ * Allwinner A64 SoCs pinctrl driver.
+ *
+ * Copyright (C) 2016 - ARM Ltd.
+ * Author: Andre Przywara <andre.przywara at arm.com>
+ *
+ * Based on pinctrl-sun7i-a20.c, which is:
+ * Copyright (C) 2014 Maxime Ripard <maxime.ripard at free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/pinctrl.h>
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin a64_pins[] = {
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* TX */
+		  SUNXI_FUNCTION(0x4, "jtag"),		/* MS0 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),	/* EINT0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* RX */
+		  SUNXI_FUNCTION(0x4, "jtag"),		/* CK0 */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* VCCEN */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),		/* EINT1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* RTS */
+		  SUNXI_FUNCTION(0x4, "jtag"),		/* DO0 */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* VPPEN */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),		/* EINT2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* CTS */
+		  SUNXI_FUNCTION(0x3, "i2s0"),		/* MCLK */
+		  SUNXI_FUNCTION(0x4, "jtag"),		/* DI0 */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* VPPPP */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),		/* EINT3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif2"),		/* SYNC */
+		  SUNXI_FUNCTION(0x3, "i2s0"),		/* SYNC */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* CLK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),		/* EINT4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif2"),		/* BCLK */
+		  SUNXI_FUNCTION(0x3, "i2s0"),		/* BCLK */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* DATA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),		/* EINT5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif2"),		/* DOUT */
+		  SUNXI_FUNCTION(0x3, "i2s0"),		/* DOUT */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* RST */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),		/* EINT6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif2"),		/* DIN */
+		  SUNXI_FUNCTION(0x3, "i2s0"),		/* DIN */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* DET */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),		/* EINT7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x4, "uart0"),		/* TX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),		/* EINT8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x4, "uart0"),		/* RX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),		/* EINT9 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NWE */
+		  SUNXI_FUNCTION(0x4, "spi0")),		/* MOSI */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NALE */
+		  SUNXI_FUNCTION(0x3, "mmc2"),		/* DS */
+		  SUNXI_FUNCTION(0x4, "spi0")),		/* MISO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCLE */
+		  SUNXI_FUNCTION(0x4, "spi0")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE1 */
+		  SUNXI_FUNCTION(0x4, "spi0")),		/* CS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NCE0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NRE# */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NRB0 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* CMD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NRB1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ0 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ1 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ2 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ3 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ4 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ5 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ6 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ7 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 16),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQS */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* RST */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D2 */
+		  SUNXI_FUNCTION(0x3, "uart3"),		/* TX */
+		  SUNXI_FUNCTION(0x4, "spi1"),		/* CS */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D3 */
+		  SUNXI_FUNCTION(0x3, "uart3"),		/* RX */
+		  SUNXI_FUNCTION(0x4, "spi1"),		/* CLK */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* DE */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D4 */
+		  SUNXI_FUNCTION(0x3, "uart4"),		/* TX */
+		  SUNXI_FUNCTION(0x4, "spi1"),		/* MOSI */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* HSYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D5 */
+		  SUNXI_FUNCTION(0x3, "uart4"),		/* RX */
+		  SUNXI_FUNCTION(0x4, "spi1"),		/* MISO */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* VSYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D6 */
+		  SUNXI_FUNCTION(0x3, "uart4"),		/* RTS */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D7 */
+		  SUNXI_FUNCTION(0x3, "uart4"),		/* CTS */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D10 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D11 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D12 */
+		  SUNXI_FUNCTION(0x4, "emac"),		/* ERXD3 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D13 */
+		  SUNXI_FUNCTION(0x4, "emac"),		/* ERXD2 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D14 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ERXD1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D15 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ERXD0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D18 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VP0 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ERXCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D19 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VN0 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ERXCTL */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 14),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D20 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VP1 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ENULL */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 15),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D21 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VN1 */
+		  SUNXI_FUNCTION(0x4, "emac"),		/* ETXD3 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 16),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D22 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VP2 */
+		  SUNXI_FUNCTION(0x4, "emac"),		/* ETXD2 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 17),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D23 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VN2 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ETXD1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 18),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VPC */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ETXD0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 19),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* DE */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VNC */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ETXCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 20),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* HSYNC */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VP3 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ETXCTL */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 21),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* VSYNC */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VN3 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ECLKIN */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 22),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "pwm"),		/* PWM0 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* EMDC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 23),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x4, "emac")),		/* EMDIO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 24),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* PCK */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* CK */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* ERR */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* HSYNC */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* SYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* VSYNC */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* DVLD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D0 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D1 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D2 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D3 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D4 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D5 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D6 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D7 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 14),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "pll"),		/* LOCK_DBG */
+		  SUNXI_FUNCTION(0x3, "i2c2")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 15),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x3, "i2c2")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 16),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 17),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D1 */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* MSI */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D0 */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* DI1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "uart0")),	/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* CMD */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* DO1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D3 */
+		  SUNXI_FUNCTION(0x4, "uart0")),	/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D2 */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* CK1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* CLK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 0)),	/* EINT0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* CMD */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 1)),	/* EINT1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D0 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 2)),	/* EINT2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D1 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 3)),	/* EINT3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D2 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 4)),	/* EINT4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D3 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 5)),	/* EINT5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart1"),		/* TX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 6)),	/* EINT6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart1"),		/* RX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 7)),	/* EINT7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart1"),		/* RTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 8)),	/* EINT8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart1"),		/* CTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 9)),	/* EINT9 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif3"),		/* SYNC */
+		  SUNXI_FUNCTION(0x3, "i2s1"),		/* SYNC */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 10)),	/* EINT10 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif3"),		/* BCLK */
+		  SUNXI_FUNCTION(0x3, "i2s1"),		/* BCLK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 11)),	/* EINT11 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif3"),		/* DOUT */
+		  SUNXI_FUNCTION(0x3, "i2s1"),		/* DOUT */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 12)),	/* EINT12 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif3"),		/* DIN */
+		  SUNXI_FUNCTION(0x3, "i2s1"),		/* DIN */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 13)),	/* EINT13 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c0"),		/* SCK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 0)),	/* EINT0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c0"),		/* SDA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 1)),	/* EINT1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c1"),		/* SCK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 2)),	/* EINT2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c1"),		/* SDA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 3)),	/* EINT3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart3"),		/* TX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 4)),	/* EINT4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart3"),		/* RX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 5)),	/* EINT5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart3"),		/* RTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 6)),	/* EINT6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart3"),		/* CTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 7)),	/* EINT7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "owa"),		/* OUT */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 8)),	/* EINT8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 9)),	/* EINT9 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mic"),		/* CLK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 10)),	/* EINT10 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mic"),		/* DATA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 11)),	/* EINT11 */
+};
+
+static const struct sunxi_pinctrl_desc a64_pinctrl_data = {
+	.pins = a64_pins,
+	.npins = ARRAY_SIZE(a64_pins),
+	.irq_banks = 3,
+};
+
+static int a64_pinctrl_probe(struct platform_device *pdev)
+{
+	return sunxi_pinctrl_init(pdev,
+				  &a64_pinctrl_data);
+}
+
+static const struct of_device_id a64_pinctrl_match[] = {
+	{ .compatible = "allwinner,a64-pinctrl", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, a64_pinctrl_match);
+
+static struct platform_driver a64_pinctrl_driver = {
+	.probe	= a64_pinctrl_probe,
+	.driver	= {
+		.name		= "a64-pinctrl",
+		.of_match_table	= a64_pinctrl_match,
+	},
+};
+module_platform_driver(a64_pinctrl_driver);
+
+MODULE_AUTHOR("Andre Przywara <andre.przywara at arm.com>");
+MODULE_DESCRIPTION("Allwinner A64 pinctrl driver");
+MODULE_LICENSE("GPL");
-- 
2.6.4



From chris.brandt at renesas.com  Mon Feb  1 09:52:45 2016
From: chris.brandt at renesas.com (Chris Brandt)
Date: Mon,  1 Feb 2016 12:52:45 -0500
Subject: [PATCH v4] ARM: xip: Use correct symbol for end of ROM marker
In-Reply-To: <1447697140-4099-1-git-send-email-chris.brandt@renesas.com>
References: <1447697140-4099-1-git-send-email-chris.brandt@renesas.com>
Message-ID: <1454349165-12249-1-git-send-email-chris.brandt@renesas.com>

For an XIP build, __data_loc, not _etext, represents the end of the
binary image that needs to stay mapped into the MODULES_VADDR area.
Years ago, data came before text in the memory map. However,
now that the order is text/init/data, an XIP_KERNEL needs to map
up to the __data_loc symbol in order to keep from cutting off
parts of the kernel that are needed.
We only map up to the beginning of data because data has already been
copied, so there's no reason to keep it around anymore.

This fixes the bug where you might lose the end of your kernel area
after page table setup is complete.

Signed-off-by: Chris Brandt <chris.brandt at renesas.com>
---
v4:
* Switched from using _edata_loc __data_loc.
  Made commit text more accurate.
v3:
* Removed sections.h from Kbuild
v2:
* Added change for MODULES_VADDR
* Moved extern to new file asm/sections.h
---
 arch/arm/include/asm/Kbuild     | 1 -
 arch/arm/include/asm/sections.h | 8 ++++++++
 arch/arm/kernel/module.c        | 2 +-
 arch/arm/mm/mmu.c               | 8 ++++++--
 4 files changed, 15 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/include/asm/sections.h

diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
index 16da638..3f6616b 100644
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@ -23,7 +23,6 @@ generic-y += preempt.h
 generic-y += resource.h
 generic-y += rwsem.h
 generic-y += seccomp.h
-generic-y += sections.h
 generic-y += segment.h
 generic-y += sembuf.h
 generic-y += serial.h
diff --git a/arch/arm/include/asm/sections.h b/arch/arm/include/asm/sections.h
new file mode 100644
index 0000000..8d50cce
--- /dev/null
+++ b/arch/arm/include/asm/sections.h
@@ -0,0 +1,8 @@
+#ifndef _ASM_ARM_SECTIONS_H
+#define _ASM_ARM_SECTIONS_H
+
+#include <asm-generic/sections.h>
+
+extern char __data_loc[];
+
+#endif	/* _ASM_ARM_SECTIONS_H */
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index efdddcb..b48e3bc 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -34,7 +34,7 @@
  * recompiling the whole kernel when CONFIG_XIP_KERNEL is turned on/off.
  */
 #undef MODULES_VADDR
-#define MODULES_VADDR	(((unsigned long)_etext + ~PMD_MASK) & PMD_MASK)
+#define MODULES_VADDR	(((unsigned long)__data_loc + ~PMD_MASK) & PMD_MASK)
 #endif
 
 #ifdef CONFIG_MMU
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 434d76f..53d7a88 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1253,7 +1253,7 @@ static inline void prepare_page_table(void)
 
 #ifdef CONFIG_XIP_KERNEL
 	/* The XIP kernel is mapped in the module area -- skip over it */
-	addr = ((unsigned long)_etext + PMD_SIZE - 1) & PMD_MASK;
+	addr = ((unsigned long)__data_loc + PMD_SIZE - 1) & PMD_MASK;
 #endif
 	for ( ; addr < PAGE_OFFSET; addr += PMD_SIZE)
 		pmd_clear(pmd_off_k(addr));
@@ -1335,7 +1335,7 @@ static void __init devicemaps_init(const struct machine_desc *mdesc)
 #ifdef CONFIG_XIP_KERNEL
 	map.pfn = __phys_to_pfn(CONFIG_XIP_PHYS_ADDR & SECTION_MASK);
 	map.virtual = MODULES_VADDR;
-	map.length = ((unsigned long)_etext - map.virtual + ~SECTION_MASK) & SECTION_MASK;
+	map.length = ((unsigned long)__data_loc - map.virtual + ~SECTION_MASK) & SECTION_MASK;
 	map.type = MT_ROM;
 	create_mapping(&map);
 #endif
@@ -1426,7 +1426,11 @@ static void __init kmap_init(void)
 static void __init map_lowmem(void)
 {
 	struct memblock_region *reg;
+#ifdef CONFIG_XIP_KERNEL
+	phys_addr_t kernel_x_start = round_down(__pa(_sdata), SECTION_SIZE);
+#else
 	phys_addr_t kernel_x_start = round_down(__pa(_stext), SECTION_SIZE);
+#endif
 	phys_addr_t kernel_x_end = round_up(__pa(__init_end), SECTION_SIZE);
 
 	/* Map all the lowmem memory banks. */
-- 
1.9.1




From sergei.shtylyov at cogentembedded.com  Mon Feb  1 09:54:48 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 1 Feb 2016 20:54:48 +0300
Subject: [PATCH] ARM: dts: porter: add MAX3355 support
In-Reply-To: <SG2PR06MB0919361DC5805AE3F5B74041D8DE0@SG2PR06MB0919.apcprd06.prod.outlook.com>
References: <1674850.BZpGW9kEud@wasted.cogentembedded.com>
 <4506196.xOgpYRO52t@wasted.cogentembedded.com>
 <SG2PR06MB0919D09C1146EAC0681EE109D8DA0@SG2PR06MB0919.apcprd06.prod.outlook.com>
 <56ABCB69.1070800@cogentembedded.com> <56ABD066.7020804@cogentembedded.com>
 <SG2PR06MB0919361DC5805AE3F5B74041D8DE0@SG2PR06MB0919.apcprd06.prod.outlook.com>
Message-ID: <56AF9BE8.4020002@cogentembedded.com>

Hello.

On 02/01/2016 02:17 PM, Yoshihiro Shimoda wrote:

>>>>> From: linux-renesas-soc-owner at vger.kernel.org
>>>>> [mailto:linux-renesas-soc-owner at vger.kernel.org] On Behalf Of Sergei
>>>>> Shtylyov
>>>>> Sent: Wednesday, January 27, 2016 7:14 AM
>>>>>
>>>>> Now that Maxim Integrated MAX3355 'extcon' driver and device tree bindings
>>>>> are upstream along with the 'extcon' hook  in the Renesas USBHS driver, we
>>>>> can add  MAX3355 device node to  the Porter device tree and properly refer
>>>>> to it from the USBHS node instead of using  "renesas,enable-gpio" property
>>>>> which only allowed checking the USB ID pin  at the driver probe time;  now
>>>>> this  pin's  state can be monitored dynamically!
>>>>>
>>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>>>>
>>>> I tested this patch on Porter, but interrupt of "usb-otg" didn't happened
>>>> even if I connected/disconnected a usb convert cable (usb micro-ab to A).
>>>> Remarks: I confirmed that the usb convert cable worked correctly on other
>>>> board.
>>>
>>>      I guess I have the same cable
>>
>>      No, I have mini-AB connector here and hence my cable is mini-AB to A.
>
> I checked Porter specification and then I found 2 specifications exist...

    I've looked thru my schematics files and found 3: Rev. 1.1 Update Version 
2, "PORTER_2" Rev. 3.0 Preliminary, and "PORTER_C" Rev. 3.0 Release version!
I'm not sure which of the last 2 should be considered final...

>   Porter "B" : mini AB connecter and Max3355 is on the board.
>   Porter "C" : micro AB connect and Max3355 is not on the board. (Select host/peripheral by a jumper.)

    Yeah, seeing JP13 in the PORTER_C schematics.

> I guess that your current target is "B".

    If not earlier. It actually has "Henninger B REV2" printed on it and 
"Porter PCB 1 R3" on a pasted sticker.

> If so, I think this patch is acceptable.

    I'm not so sure now...

> Best regards,
> Yoshihiro Shimoda

MBR, Sergei



From santosh.shilimkar at oracle.com  Mon Feb  1 09:55:34 2016
From: santosh.shilimkar at oracle.com (santosh.shilimkar at oracle.com)
Date: Mon, 1 Feb 2016 09:55:34 -0800
Subject: [PATCH 1/2] ARM: make virt_to_idmap() return unsigned long
In-Reply-To: <20160201173137.GV10826@n2100.arm.linux.org.uk>
References: <E1aO8F2-00074N-E8@rmk-PC.arm.linux.org.uk>
 <56A84748.3040108@oracle.com> <20160201152015.GU10826@n2100.arm.linux.org.uk>
 <56AF8F54.7030805@ti.com> <56AF917F.9030505@oracle.com>
 <20160201173137.GV10826@n2100.arm.linux.org.uk>
Message-ID: <56AF9C16.3090703@oracle.com>

On 2/1/16 9:31 AM, Russell King - ARM Linux wrote:
> On Mon, Feb 01, 2016 at 09:10:23AM -0800, santosh shilimkar wrote:
>> Based on the log, I think the patch seems to work fine since the boot
>> reached upto rootfs. The crash seems to be coming from mostky NetCP
>> related compents.
>
> I read the boot log slightly differently - I'm assuming that the
> boot log is from the kernel which _will_ be kexec'd from, so we
> don't yet know whether the patches work or not.
>
I didn't see your [PATCH 2/2] which updates the kexec code with
idmap API. I see your point now but IIUC, this log isn't from
kexec kernel based on command line.

> I looked at the oops, and it's in tasklet_action, but for some
> reason the unwinder is unable to unwind and provide a backtrace,
> so it's not very debuggable.
>
> However, this is a useful backtrace for me in a different way:
> to provide to people who want to deprecate the frame-pointer
> based backtracing to prove why the unwinder based solution still
> isn't up to the job.
>
Indeed. Not having stack trace doesn't help.

Regards,
Santosh


From ard.biesheuvel at linaro.org  Mon Feb  1 09:57:05 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 1 Feb 2016 18:57:05 +0100
Subject: [PATCH v5sub1 8/8] arm64: allow kernel Image to be loaded
 anywhere in physical memory
In-Reply-To: <20160201173120.GI15514@e104818-lin.cambridge.arm.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-9-git-send-email-ard.biesheuvel@linaro.org>
 <20160201150624.GG15514@e104818-lin.cambridge.arm.com>
 <CAKv+Gu8rgkBWfJXfWzWSkxyKhLOnxirycu-wdcmvRovpDB5hKw@mail.gmail.com>
 <CAKv+Gu8+DdtGQmZtKsB8YOabH1NfzSJge=w0vQwFZPwbQkgYzA@mail.gmail.com>
 <20160201173120.GI15514@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu__yQUPyTKLBGeFYk2ehM8XkOXKXRisMyX1V-iAch5JNw@mail.gmail.com>

On 1 February 2016 at 18:31, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 01, 2016 at 05:31:11PM +0100, Ard Biesheuvel wrote:
>> On 1 February 2016 at 16:13, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>> > On 1 February 2016 at 16:06, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> >> On Mon, Feb 01, 2016 at 11:54:53AM +0100, Ard Biesheuvel wrote:
>> >>> Note that limiting memory using mem= is not unambiguous anymore after
>> >>> this change, considering that the kernel may be at the top of physical
>> >>> memory, and clipping from the bottom rather than the top will discard
>> >>> any 32-bit DMA addressable memory first. To deal with this, the handling
>> >>> of mem= is reimplemented to clip top down, but take special care not to
>> >>> clip memory that covers the kernel image.
>> >>
>> >> I may have forgotten the reason - why do we need to avoid clipping the
>> >> memory that covers the kernel image? It's already mapped in the vmalloc
>> >> area, so we wouldn't need it in the linear map as well.
>> >
>> > Good question. Originally, I needed it for swapper_pg_dir, whose
>> > pud/pmd/pte levels were accessed via __va() translations of the values
>> > found in the higher-up table entries, but after Mark's patches, only
>> > the top level pgd of swapper_pg_dir is still used. Similarly, for
>> > idmap_pg_dir, we don't change any mappings at runtime so the same
>> > applies there I think.
>> >
>> > I will try dropping this, and see what happens.
>>
>> I have given this a spin, and this chokes on
>> a) the fact that not all of the translation tables are accessible via
>> the linear mapping: the fixmap, due to its vicinity to PCI i/o and
>> other populated regions, will share its pud/pmd level tables with
>> other users, like ioremap, which traverses the translation tables in
>> the ordinary way, i.e., it expects that __va() applied on the phys
>> address in the table entry returns something that is mapped
>
> Ah, __va(__pa(x)) is not an identity function and I don't think it's
> worth fixing it (the __pa() case is much simpler). But it also means
> that we won't be able to remove the kernel image alias in the linear
> mapping. It shouldn't be a problem for KASLR as long as we randomise
> both kernel image PA and VA.
>

indeed.

>> b) free_initmem() now calls __free_pages() on a region that we never
>> mapped or registered as available.
>>
>> So it may be feasible with some hackery, but I wonder if it is worth
>> it to complicate the common case for implementing mem= more
>> efficiently.
>
> I don't care about efficiency, I was hoping to avoid the additional
> arm64-specific memory clipping but it seems that it could easily get
> more complicated. So let's leave as it is.
>

Alternatively, we could simply apply the memory limit as before, and
add back the [__init_begin, _end] interval right afterwards using
memblock_add()

> Consider this sub-series merged (I'll push it to -next around -rc3).
>
> Thanks.
>
> --
> Catalin


From linux at arm.linux.org.uk  Mon Feb  1 09:59:07 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 1 Feb 2016 17:59:07 +0000
Subject: [RFC PATCH 1/2] ARM: deprecate old APCS frame format
In-Reply-To: <1453741521-6878-2-git-send-email-jean-philippe.brucker@arm.com>
References: <1453741521-6878-1-git-send-email-jean-philippe.brucker@arm.com>
 <1453741521-6878-2-git-send-email-jean-philippe.brucker@arm.com>
Message-ID: <20160201175907.GW10826@n2100.arm.linux.org.uk>

On Mon, Jan 25, 2016 at 05:05:20PM +0000, Jean-Philippe Brucker wrote:
> GCC 5 deprecated option -mapcs-frame, which generated frames following
> the old ABI format. In preparation for a possible removal in future
> versions of GCC, deprecate use of this flag in Linux as well.
> 
> Instead of completely removing the bits that depend on APCS frame, we
> move them behind a DEPRECATED config option to smoothen the transition.
> 
> Neither AAPCS nor EABI guarantees any frame format, so only ARM_UNWIND
> should now be used for stack traces and introspection. It is already
> selected by most defconfigs.
> Furthermore, frames currently generated by GCC are different for leaf
> and non-leaf functions, which would make adaptation quite tricky.

As I mentioned on the call last week, I'm not happy with deprecating
APCS frames.  The unwinder does not always work, and each time the
unwinder fails to work, it creates more work.

The latest scenario can be found in the "[PATCH 1/2] ARM: make
virt_to_idmap() return unsigned long" thread, where we have a
failure to unwind the first oops - unwinding stops for apparently
no reason after the first frame.

So, we have no idea how tasket_action() got called.

My current idea on that oops is... I have no idea, and the only way
to get more of an idea would be to request a rebuild with thumb
disabled and frame pointers enabled, and for the problem to be
reproduced.

This is the issue: APCS frame pointer based backtracing works every
time.  The unwinder is and always has been unreliable.

GCC people need to think about this, because if they persue, we're
going to end up having to tell people to rebuild their kernels with
older GCC versions just to get debug information out of them, unless
the quality of the unwinder and unwind information can be improved.

However, having experienced the "quality" of gdb over the last five
years in userspace, I'm really not hopeful that there is a solution
that works using the unwind information: I suspect there's a great
number of cases where the unwind information is basically wrong or
otherwise broken.

The problem with unwind based solutions is the only time you know
that the unwinding information is broken is when the code goes wrong
and the unwind information has to be used.  The nice thing about the
frame-pointer based solution is that it's correctness is an inherent
requirement for the program to work, so any problem with a frame-
pointer based solution shows up as a program crash.

This is probably the root cause why the unwind based backtracing
tends to fail.

Here's the oops in question:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0003000
[00000000] *pgd=80000800004003, *pmd=00000000
Internal error: Oops: a07 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 330 Comm: kworker/0:1 Not tainted 4.5.0-rc1-00001-g22a8511 #1
Hardware name: Keystone
Workqueue: ipv6_addrconf addrconf_dad_work
task: eba89500 ti: eba96000 task.ti: eba96000
PC is at tasklet_action+0xac/0x13c
LR is at _raw_spin_unlock_irqrestore+0x28/0x54
pc : [<c0026c48>]    lr : [<c0574634>]    psr: 40000133
sp : eba97d30  ip : eb400258  fp : c083aecc
r10: 0000000c  r9 : eba97dc8  r8 : 00000100
r7 : 00000008  r6 : eba96000  r5 : 00000003  r4 : c07e408c
r3 : eba97d00  r2 : eba97d00  r1 : 60000113  r0 : 00000000
Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb Segment kernel
Control: 30c5387d  Table: 2b9ba700  DAC: fffffffd
Process kworker/0:1 (pid: 330, stack limit = 0xeba96210)
Stack: (0xeba97d30 to 0xeba98000)
7d20:                                     000086dd ebbb9900 00000004 eba97d30
7d40: c07e4080 c08409c0 0000000a ffff8e53 c07e4100 04208060 ebbb9900 c07dce84
7d60: 00000000 0000004e 00000000 00000001 eba97dc8 eb838000 c082ad40 c0026778
7d80: c07dce84 c006754c c080f430 c07e5e84 f080400c eba97dc8 f0804000 f0805000
7da0: 00000001 c0009438 c04fc29c 20000013 ffffffff eba97dfc cc8da400 eaf54d00
...
[<c0026c48>] (tasklet_action) from [<c08409c0>] (irq_stat+0x0/0x100)
Code: 4000 e256 0020 0a00 (5004) e1a0

Obviously, tasklet_action was _not_ called by the irq_stat array!

What we can see from the stack is there was an exception frame at
0xeba97d6c, with the parent context LR = c0009438 and PC = c04fc29c.
Much more than that is just guesswork - but the point is, the kernel
_should_ be capable of giving a good backtrace.

If we can't get a good backtrace, it limits those who can diagnose
the case of the failure, which really isn't good.

What we _might_ end up having to do is to walk every word on the
kernel stack, check whether it's in a module .text or kernel .text,
and print it as a "best guess" at a backtrace, but that will be
very misleading, as registers contain pointers to literal data,
which can be located not only at the end of a function, but also
the middle of a function, and that can end up on the stack too.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From matthias.bgg at gmail.com  Mon Feb  1 10:01:18 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 1 Feb 2016 19:01:18 +0100
Subject: [PATCH v4 2/6] dt-bindings: ARM: Mediatek: Document bindings for
 MT2701
In-Reply-To: <CAL_JsqLJVLDbPqynmD9-Yc=JVGH4iLPfb2keA5G7c2fjitAsSQ@mail.gmail.com>
References: <1453271747-57397-1-git-send-email-jamesjj.liao@mediatek.com>
 <1453271747-57397-3-git-send-email-jamesjj.liao@mediatek.com>
 <20160120163236.GA21035@rob-hp-laptop> <1453353537.5384.33.camel@mtksdaap41>
 <CAL_JsqLJVLDbPqynmD9-Yc=JVGH4iLPfb2keA5G7c2fjitAsSQ@mail.gmail.com>
Message-ID: <56AF9D6E.80305@gmail.com>



On 01/02/16 16:55, Rob Herring wrote:
> On Wed, Jan 20, 2016 at 11:18 PM, James Liao <jamesjj.liao at mediatek.com> wrote:
>> Hi Rob,
>>
>> On Wed, 2016-01-20 at 10:32 -0600, Rob Herring wrote:
>>> On Wed, Jan 20, 2016 at 02:35:43PM +0800, James Liao wrote:
>>>> This patch adds the binding documentation for apmixedsys, bdpsys,
>>>> ethsys, hifsys, imgsys, infracfg, mmsys, pericfg, topckgen and
>>>> vdecsys for Mediatek MT2701.
>>>>
>>>> Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
>>>> Tested-by: John Crispin <blogic at openwrt.org>
>>>> ---
>>>>   .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |  1 +
>>>>   .../bindings/arm/mediatek/mediatek,bdpsys.txt      | 22 ++++++++++++++++++++++
>>>>   .../bindings/arm/mediatek/mediatek,ethsys.txt      | 22 ++++++++++++++++++++++
>>>>   .../bindings/arm/mediatek/mediatek,hifsys.txt      | 22 ++++++++++++++++++++++
>>>>   .../bindings/arm/mediatek/mediatek,imgsys.txt      |  1 +
>>>>   .../bindings/arm/mediatek/mediatek,infracfg.txt    |  1 +
>>>>   .../bindings/arm/mediatek/mediatek,mmsys.txt       |  1 +
>>>>   .../bindings/arm/mediatek/mediatek,pericfg.txt     |  1 +
>>>>   .../bindings/arm/mediatek/mediatek,topckgen.txt    |  1 +
>>>>   .../bindings/arm/mediatek/mediatek,vdecsys.txt     |  1 +
>>>>   10 files changed, 73 insertions(+)
>>>>   create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
>>>>   create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
>>>>   create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
>>>> index 936166f..a701e19 100644
>>>> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
>>>> @@ -6,6 +6,7 @@ The Mediatek apmixedsys controller provides the PLLs to the system.
>>>>   Required Properties:
>>>>
>>>>   - compatible: Should be:
>>>> +   - "mediatek,mt2701-apmixedsys"
>>>>      - "mediatek,mt8135-apmixedsys"
>>>>      - "mediatek,mt8173-apmixedsys"
>>>>   - #clock-cells: Must be 1
>>>> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
>>>> new file mode 100644
>>>> index 0000000..4137196
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
>>>> @@ -0,0 +1,22 @@
>>>> +Mediatek bdpsys controller
>>>> +============================
>>>> +
>>>> +The Mediatek bdpsys controller provides various clocks to the system.
>>>
>>> As you clarified these blocks provide more that just clocks. Please list
>>> all the functions here and on the others.
>>
>> Some blocks may provide clock and reset controller at the same time. But
>
> Then say the block provides clocks and resets is all I'm asking for.
>
>> most of them will not provide functions directly. Instead, some DT
>> blocks which provide specific functions may refer to these controller
>> nodes due to it need to access the same register space.
>>
>> For example, scpsys (the power domain provider) refers to infracfg
>> because it need to control infracfg registers when power on/off domains:
>>
>>          scpsys: scpsys at 10006000 {
>>                  compatible = "mediatek,mt2701-scpsys";
>>                  #power-domain-cells = <1>;
>>                  reg = <0 0x10006000 0 0x1000>;
>>                  infracfg = <&infracfg>;
>>          };
>>
>> So I think it should not need to list all functions for each blocks
>> here.
>
> Sorry, but you do need to describe what functions the blocks provide.
>
> Also, if you are accessing the infracfg regs directly to modify clock
> registers outside of the clock driver, that is very bad design. The
> clock driver could assume that register values are not changing behind
> its back and it bypasses any locks around register accesses. I can see
> why it is needed though, but we really need a proper interface.
>

Some of the register blocks like infracfg is a potpourri of different 
functions. Clocks and power domains are some of them. In the drivers 
this is isolated, but there are many blocks which are not used at the 
moment and therefor are not documented in bindings description (e.g. 
debug control for the very same block, not sure if that will be 
implemented one day).

Would it be ok for you, if James just lists the blocks which already 
have an implementation and leaving apart the rest of it?

Regards,
Matthias


From catalin.marinas at arm.com  Mon Feb  1 10:02:56 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 1 Feb 2016 18:02:56 +0000
Subject: [PATCH v5sub1 8/8] arm64: allow kernel Image to be loaded
 anywhere in physical memory
In-Reply-To: <CAKv+Gu__yQUPyTKLBGeFYk2ehM8XkOXKXRisMyX1V-iAch5JNw@mail.gmail.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-9-git-send-email-ard.biesheuvel@linaro.org>
 <20160201150624.GG15514@e104818-lin.cambridge.arm.com>
 <CAKv+Gu8rgkBWfJXfWzWSkxyKhLOnxirycu-wdcmvRovpDB5hKw@mail.gmail.com>
 <CAKv+Gu8+DdtGQmZtKsB8YOabH1NfzSJge=w0vQwFZPwbQkgYzA@mail.gmail.com>
 <20160201173120.GI15514@e104818-lin.cambridge.arm.com>
 <CAKv+Gu__yQUPyTKLBGeFYk2ehM8XkOXKXRisMyX1V-iAch5JNw@mail.gmail.com>
Message-ID: <20160201180256.GJ15514@e104818-lin.cambridge.arm.com>

On Mon, Feb 01, 2016 at 06:57:05PM +0100, Ard Biesheuvel wrote:
> On 1 February 2016 at 18:31, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> >> On Mon, Feb 01, 2016 at 11:54:53AM +0100, Ard Biesheuvel wrote:
> >> >>> Note that limiting memory using mem= is not unambiguous anymore after
> >> >>> this change, considering that the kernel may be at the top of physical
> >> >>> memory, and clipping from the bottom rather than the top will discard
> >> >>> any 32-bit DMA addressable memory first. To deal with this, the handling
> >> >>> of mem= is reimplemented to clip top down, but take special care not to
> >> >>> clip memory that covers the kernel image.
> >> >>
> >> >> I may have forgotten the reason - why do we need to avoid clipping the
> >> >> memory that covers the kernel image? It's already mapped in the vmalloc
> >> >> area, so we wouldn't need it in the linear map as well.
[...]
> > I don't care about efficiency, I was hoping to avoid the additional
> > arm64-specific memory clipping but it seems that it could easily get
> > more complicated. So let's leave as it is.
> 
> Alternatively, we could simply apply the memory limit as before, and
> add back the [__init_begin, _end] interval right afterwards using
> memblock_add()

If the code ends up simpler, yes, I'm fine with it.

-- 
Catalin


From robert.richter at caviumnetworks.com  Mon Feb  1 10:09:44 2016
From: robert.richter at caviumnetworks.com (Robert Richter)
Date: Mon, 1 Feb 2016 19:09:44 +0100
Subject: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT
 and SLIT
In-Reply-To: <1453541967-3744-6-git-send-email-guohanjun@huawei.com>
References: <1453541967-3744-1-git-send-email-guohanjun@huawei.com>
 <1453541967-3744-6-git-send-email-guohanjun@huawei.com>
Message-ID: <20160201180944.GV24726@rric.localdomain>

On 23.01.16 17:39:20, Hanjun Guo wrote:

> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
>  {
>  	int ret = -ENODEV;
>  
> -#ifdef CONFIG_OF_NUMA
>  	if (!numa_off)
> -		ret = numa_init(arm64_of_numa_init);
> -#endif
> +		ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
>  
>  	if (ret)
>  		numa_init(dummy_numa_init);

Ok, this style is mostly flavor, some people want #ifdefs (my
preference), some not. In any case it must build with or without the
config option set. But first some words why I like #ifdefs:

 * Code is easier to understand as you don't need to look at any other
   location whether it is enabled or not.

 * You can't break the build if the options are not set. Thus, you
   also don't need to check if the function is implemented for the
   unset case (valid for the coder and also the reviewer). This makes
   things a lot easier.

 * Total number of lines of code that needs to be implement is
   smaller.

However, if we don't ifdef the code, we need empty functions stubs in
the header file for them.

Also, the conditional assignment does not reduce the complexity of the
paths. It just concentrates everything in a single line.

How about the following (similar to x86)?

----
	if (!numa_off) {
#ifdef CONFIG_ACPI_NUMA
		if (!numa_init(acpi_numa_init))
			return 0;
#endif
#ifdef CONFIG_OF_NUMA
		if (!numa_init(of_numa_init))
			return 0;
#endif
	}

	return numa_init(dummy_numa_init);
----

Pretty straight and nice.

Note: The !acpi_disabled check needs to be moved to the beginning of
acpi_numa_init(). Variable ret can be removed.

-Robert


From tony at atomide.com  Mon Feb  1 10:11:35 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Feb 2016 10:11:35 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFoQHpqdCa4fzHycP0OT2KsNTxWm7JZSe8Mauh+rxqGtGg@mail.gmail.com>
References: <20160126224804.GB19432@atomide.com>
 <CAJZ5v0i79X5JjOZiu4cOZ0Esd5BxAvutF8d17asDzq9ECcML-g@mail.gmail.com>
 <20160126232212.GE19432@atomide.com>
 <CAJZ5v0gTRvyWHVmYNb8Q1QZzhVhokXo541+48mFyDRYv7Hi-Uw@mail.gmail.com>
 <20160126235222.GF19432@atomide.com>
 <CAPDyKFqD6Y6HcgVds_oWBZ8L7Kdh2VX_WZCGApf-1a_6GHCQ5g@mail.gmail.com>
 <20160128165810.GA19432@atomide.com>
 <CAPDyKFoQHpqdCa4fzHycP0OT2KsNTxWm7JZSe8Mauh+rxqGtGg@mail.gmail.com>
Message-ID: <20160201181135.GL19432@atomide.com>

* Ulf Hansson <ulf.hansson at linaro.org> [160201 08:45]:
> On 28 January 2016 at 17:58, Tony Lindgren <tony at atomide.com> wrote:
> >
> > The MMC hardware will not get idled properly any longer blocking any
> > deeper idle states.
> >
> >> Did the driver not probe successfully the second try? If so, what happened.
> >
> > It probes fine after a -EPROBE_DEFER on the vmmc i2c regulator.
> > But the PM runtime usecounts are wrong.
> 
> Okay. How did you verify this?

Well that was just based on what I see in the dmesg:

omap_device: omap_device_enable() called from invalid state 1

> I think the easiest way would be to make sure the usage count is
> *one*, just before the omap_hsmmc calls mmc_add_host() in its
> ->probe() function.
> 
> If it's *two*, that confirms this theory.

Here's with use count dumped for one MMC:

omap_hsmmc 4809c000.mmc: GPIO lookup for consumer cd
omap_hsmmc 4809c000.mmc: using device tree for GPIO lookup
omap_hsmmc 4809c000.mmc: Got CD GPIO
omap_hsmmc 4809c000.mmc: GPIO lookup for consumer wp
omap_hsmmc 4809c000.mmc: using device tree for GPIO lookup
omap_hsmmc 4809c000.mmc: using lookup tables for GPIO lookup
omap_hsmmc 4809c000.mmc: lookup for GPIO wp failed
omap_hsmmc 4809c000.mmc: GPIO lookup for consumer cd
omap_hsmmc 4809c000.mmc: using device tree for GPIO lookup
omap_hsmmc 4809c000.mmc: Got CD GPIO
omap_hsmmc 4809c000.mmc: GPIO lookup for consumer wp
omap_hsmmc 4809c000.mmc: using device tree for GPIO lookup
omap_hsmmc 4809c000.mmc: using lookup tables for GPIO lookup
omap_hsmmc 4809c000.mmc: lookup for GPIO wp failed
omap_hsmmc 4809c000.mmc: omap_device: omap_device_enable() called from invalid state 1
omap_hsmmc 4809c000.mmc: PM runtime use count: 0

So it seems you're right, it's the state not the count.

> > So one of the failing cases seems to be:
> >
> > 1. Device driver probe sets pm_runtime_set_autosuspend_delay()
> 
> Only when "someone" in-before has set the autosuspend delay to a
> negative value, this will affect the usage count.
> 
> I didn't find any in-kernel user that would set this for the
> omap_hsmmc device, so it needs to be done from userspace via sysfs. It
> would be really great if you could help to confirm this.

No nothing is setting that from userspace.

> But more importantly, I fail to understand why commit 5de85b9d57ab
> ("PM / runtime: Re-init runtime PM states at probe error and driver
> unbind"), is changing the behaviour in this regards.
> Potentially we might have a different runtime PM status than we had
> before when probing the second try, but how could that mess up the
> usage count...?

Yes I think you're right here, it's the state, not the count.

> Although, I wondering whether it could be that it's the PM domain
> that's preventing the omap_hsmmc device from becoming runtime
> suspended.
> 
> Perhaps the PM domain returns an error code from its
> ->runtime_suspend() callback?

We certainly see a warning there.

> Okay, so we definitely seem to have an issue with the changed runtime
> PM status (suspended) the second probe time.
> 
> That's indeed caused by 5de85b9d57ab ("PM / runtime: Re-init runtime
> PM states at probe error and driver unbind").

Yup.

> For example due to commit 5de85b9d57ab ("PM / runtime: Re-init runtime
> PM states at probe error and driver unbind"), the ->runtime_resume()
> callback seems now to be called twice in a row, without in-between
> having the ->runtime_suspend() callback being invoked. Does really the
> PM domain cope with that correctly?

That might explain the warning above.

> > BTW, do you have some hardware to test with that has PM runtime
> > implemnted and actually working with mainline kernel?
> 
> Oh, yes. Although I don't have an omap3, I wish I had.

OK good to hear. Anyways, getting an omap3 should be in tens of
whatever units if you need one to test with.

> Also, I have locally a "runtime PM test driver", which helps me to
> test various runtime PM sequences.

Now that would be good to have in the mainline kernel. Of course it
still is a very limited test.

Regards,

Tony


From tony at atomide.com  Mon Feb  1 10:13:17 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Feb 2016 10:13:17 -0800
Subject: N900 sleep mode (in 4.5-rc0, if that matters)
In-Reply-To: <20160130221509.GA28644@amd>
References: <20160123121022.GB12497@amd> <20160125163332.GT19432@atomide.com>
 <20160126140010.GA29723@amd> <20160126172527.GY3500@atomide.com>
 <20160130200244.GA30429@amd> <20160130201452.GC30429@amd>
 <20160130221509.GA28644@amd>
Message-ID: <20160201181316.GM19432@atomide.com>

* Pavel Machek <pavel at ucw.cz> [160130 14:16]:
> Hi!
> 
> > > > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072
> > > > > 0000000d 48004a28 (fa004a28) cm_idlest3_core
> > > > > 
> > > > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems
> > > > > constant.
> > > > 
> > > > For cm_idlest1_core 42 is the answer.. Here you have bits 4 and 5
> > > > blocking which is for OTG and it's PHY. That's a known issue with
> > > > musb and setting pm_runtime_irq_safe() on the MUSB parent.
> > > > 
> > > > If you do rmmod omap2430 and phy-twl4030usb chances are the LEDs will
> > > > start going off assuming the McSPI bit goes low with WLAN idling.
> > > 
> > > Ok, so I tried to compile kernel without omap2430/phy-twl4030usb
> > > . That did not help. So I thought, ok, maybe rmmod is needed to
> > > trigger some powersaving? But that is not exactly easy to do:
> > > 
> > > pavel at n900:/my/tui/ofone$ sudo insmod /my/modules/omap2430.ko
> > > pavel at n900:/my/tui/ofone$ sudo insmod /my/modules/phy-twl4030-usb.ko
> > > pavel at n900:/my/tui/ofone$ sudo rmmod phy-twl4030-usb.ko
> > > Error: Module phy_twl4030_usb is in use
> > > pavel at n900:/my/tui/ofone$
> > > 
> > > Any ideas what jumps to use the modules? Charger code?
> > 
> > I tried a kernel without charger code, and no luck, rmmod fails the
> > same way. dmesg says:
> > [  111.093078] wlan0: authenticated
> > [  111.097442] wlan0: associate with 06:27:22:f9:10:6a (try 1/3)
> > [  111.104553] wlan0: RX AssocResp from 06:27:22:f9:10:6a (capab=0x421
> > status=0 aid=2)
> > [  111.104705] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 2),
> > will use 2
> > [  111.104736] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 3),
> > will use 2
> > [  111.256652] wlan0: associated
> > [  184.681427] HS USB OTG: no transceiver configured
> > [  184.681488] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
> > with status -517
> > [  184.681976] HS USB OTG: no transceiver configured
> > [  184.682006] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
> > with status -517
> > [  187.690338] twl4030_usb 48070000.i2c:twl at 48:twl4030-usb:
> > Initialized TWL4030 USB module
> > [  187.698303] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk
> > combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
> > [  187.698333] musb-hdrc: MHDRC RTL version 1.400
> > [  187.698333] musb-hdrc: setup fifo_mode 4
> > [  187.698394] musb-hdrc: 28/31 max ep, 16384/16384 memory
> > pavel at n900:/my/tui/ofone$
> 
> I added following hack to phy-twl4030-usb.c so that I could avoid
> modules and module unloading problem. But still could not get it to
> sleep :-(.

Are you sure you're using v4.5-rc? I recently patched away some
issues where rmmod of the musb related modules did not work.

Regards,

Tony


From drivshin.allworx at gmail.com  Mon Feb  1 10:22:28 2016
From: drivshin.allworx at gmail.com (David Rivshin (Allworx))
Date: Mon, 1 Feb 2016 13:22:28 -0500
Subject: [PATCH 4/4] pwm: omap-dmtimer: add dev_dbg() message for
 effective period and duty cycle
In-Reply-To: <CAA3gFWvSsctXtds6_SEtYY1yUdWJDR1XjznGS6qjdrGW5Dbw=A@mail.gmail.com>
References: <1454128014-22866-1-git-send-email-drivshin.allworx@gmail.com>
 <1454128014-22866-5-git-send-email-drivshin.allworx@gmail.com>
 <CAA3gFWvSsctXtds6_SEtYY1yUdWJDR1XjznGS6qjdrGW5Dbw=A@mail.gmail.com>
Message-ID: <20160201132228.2634b72e.drivshin.allworx@gmail.com>

On Sat, 30 Jan 2016 15:51:06 +0100
Neil Armstrong <narmstrong at baylibre.com> wrote:

> 2016-01-30 5:26 GMT+01:00 David Rivshin (Allworx)
> <drivshin.allworx at gmail.com>:
> > From: David Rivshin <drivshin at allworx.com>
> >
> > After going through the math and constraints checking to compute
> > load and match values, it is helpful to know what the resultant
> > period and duty cycle are.
> >
> > Signed-off-by: David Rivshin <drivshin at allworx.com>
> > ---
> >
> > I found this helpful while testing the other changes, so I included
> > it in case it may be of use to someone in the future. I would have
> > no issues with dropping this if it's not considered worthwhile.  
> 
> It's useful, but converting it as a sysfs attribute would be great !

Hrm, yes that is an interesting thought. I imagine that many PWM 
devices have similar constraints, so perhaps that would be best 
handled generically in the pwm core? Maybe as new optional get_*() 
ops, a modification to the config() op to add output params, or just 
updating new fields in the struct pwm directly?



From sudeep.holla at arm.com  Mon Feb  1 10:25:48 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon, 1 Feb 2016 18:25:48 +0000
Subject: [GIT PULL] vexpress fixes for v4.5
Message-ID: <56AFA32C.4000901@arm.com>

The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3:

   Linux 4.5-rc2 (2016-01-31 18:12:16 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git 
tags/vexpress-for-v4.5/fixes-rc2

for you to fetch changes up to aeb2ee5683e51305aff274d8b0a50af69b3ab310:

   arm64: dts: Add missing DMA Abort interrupt to Juno (2016-02-01 
09:59:59 +0000)

----------------------------------------------------------------
vexpress fixes for v4.5

Couple of minor fixes for vexpress platforms:
1. Add missing of_node_put in vexpress config bus
2. Add missing DMA-330 abort interrupt on Juno platforms

----------------------------------------------------------------
Amitoj Kaur Chawla (1):
       bus: vexpress-config: Add missing of_node_put

Robin Murphy (1):
       arm64: dts: Add missing DMA Abort interrupt to Juno

  arch/arm64/boot/dts/arm/juno-base.dtsi | 1 +
  drivers/bus/vexpress-config.c          | 4 +++-
  2 files changed, 4 insertions(+), 1 deletion(-)

-- 
Regards,
Sudeep


From sudeep.holla at arm.com  Mon Feb  1 10:28:17 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon,  1 Feb 2016 18:28:17 +0000
Subject: [PATCH 1/3] pinctrl: single: Use a separate lockdep class
In-Reply-To: <1454351299-27440-1-git-send-email-sudeep.holla@arm.com>
References: <1454351299-27440-1-git-send-email-sudeep.holla@arm.com>
Message-ID: <1454351299-27440-2-git-send-email-sudeep.holla@arm.com>

The single pinmux controller can be cascaded to the other interrupt
controllers. Hence when propagating wake-up settings to its parent
interrupt controller, there's possiblity of detecting possible recursive
locking and getting lockdep warning.

This patch avoids this false positive by using a separate lockdep class
for this single pinctrl interrupts.

Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: linux-gpio at vger.kernel.org
Suggested-by: Thomas Gleixner <tglx at linutronix.de>
Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
---
 drivers/pinctrl/pinctrl-single.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index d24e5f1d1525..fb126d56ad40 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -255,6 +255,13 @@ static enum pin_config_param pcs_bias[] = {
 };
 
 /*
+ * This lock class tells lockdep that irqchip core that this single
+ * pinctrl can be in a different category than its parents, so it won't
+ * report false recursion.
+ */
+static struct lock_class_key pcs_lock_class;
+
+/*
  * REVISIT: Reads and writes could eventually use regmap or something
  * generic. But at least on omaps, some mux registers are performance
  * critical as they may need to be remuxed every time before and after
@@ -1713,6 +1720,7 @@ static int pcs_irqdomain_map(struct irq_domain *d, unsigned int irq,
 	irq_set_chip_data(irq, pcs_soc);
 	irq_set_chip_and_handler(irq, &pcs->chip,
 				 handle_level_irq);
+	irq_set_lockdep_class(irq, &pcs_lock_class);
 	irq_set_noprobe(irq);
 
 	return 0;
-- 
1.9.1



From sudeep.holla at arm.com  Mon Feb  1 10:28:16 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon,  1 Feb 2016 18:28:16 +0000
Subject: [PATCH 0/3] OMAP/pinmux: remove misuse of IRQF_NO_SUSPEND flag
Message-ID: <1454351299-27440-1-git-send-email-sudeep.holla@arm.com>

Hi Tony/Grygorii,

Just revieving the old threads [1][2]. I have put all the necessary
patches together so that it can tested. Can you give it a go ?

Regards,
Sudeep

[1] https://www.spinics.net/lists/linux-gpio/msg09879.html
[2] http://lkml.iu.edu/hypermail/linux/kernel/1509.2/03937.html

Sudeep Holla (3):
  pinctrl: single: Use a separate lockdep class
  pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag
  ARM: OMAP2+: remove misuse of IRQF_NO_SUSPEND flag

 arch/arm/mach-omap2/mux.c        |  4 ++--
 arch/arm/mach-omap2/pm34xx.c     |  9 ++++-----
 arch/arm/mach-omap2/prm_common.c |  1 +
 drivers/pinctrl/pinctrl-single.c | 15 ++++++++++++---
 4 files changed, 19 insertions(+), 10 deletions(-)

-- 
1.9.1



From sudeep.holla at arm.com  Mon Feb  1 10:28:18 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon,  1 Feb 2016 18:28:18 +0000
Subject: [PATCH 2/3] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag
In-Reply-To: <1454351299-27440-1-git-send-email-sudeep.holla@arm.com>
References: <1454351299-27440-1-git-send-email-sudeep.holla@arm.com>
Message-ID: <1454351299-27440-3-git-send-email-sudeep.holla@arm.com>

From: Sudeep Holla <Sudeep.Holla at arm.com>

The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
be left enabled so as to allow them to work as expected during the
suspend-resume cycle, but doesn't guarantee that it will wake the system
from a suspended state, enable_irq_wake is recommended to be used for
the wakeup.

This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
irq_set_irq_wake instead.

Cc: Haojian Zhuang <haojian.zhuang at linaro.org>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: linux-gpio at vger.kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
---
 drivers/pinctrl/pinctrl-single.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index fb126d56ad40..03977a75a9e2 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1619,12 +1619,14 @@ static void pcs_irq_unmask(struct irq_data *d)
  */
 static int pcs_irq_set_wake(struct irq_data *d, unsigned int state)
 {
+	struct pcs_soc_data *pcs_soc = irq_data_get_irq_chip_data(d);
+
 	if (state)
 		pcs_irq_unmask(d);
 	else
 		pcs_irq_mask(d);
 
-	return 0;
+	return irq_set_irq_wake(pcs_soc->irq, state);
 }
 
 /**
@@ -1760,8 +1762,7 @@ static int pcs_irq_init_chained_handler(struct pcs_device *pcs,
 		int res;
 
 		res = request_irq(pcs_soc->irq, pcs_irq_handler,
-				  IRQF_SHARED | IRQF_NO_SUSPEND |
-				  IRQF_NO_THREAD,
+				  IRQF_SHARED | IRQF_NO_THREAD,
 				  name, pcs_soc);
 		if (res) {
 			pcs_soc->irq = -1;
-- 
1.9.1



From sudeep.holla at arm.com  Mon Feb  1 10:28:19 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon,  1 Feb 2016 18:28:19 +0000
Subject: [PATCH 3/3] ARM: OMAP2+: remove misuse of IRQF_NO_SUSPEND flag
In-Reply-To: <1454351299-27440-1-git-send-email-sudeep.holla@arm.com>
References: <1454351299-27440-1-git-send-email-sudeep.holla@arm.com>
Message-ID: <1454351299-27440-4-git-send-email-sudeep.holla@arm.com>

The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
be left enabled so as to allow them to work as expected during the
suspend-resume cycle, but doesn't guarantee that it will wake the system
from a suspended state, enable_irq_wake is recommended to be used for
the wakeup.

This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
enable_irq_wake instead.

Cc: Grygorii Strashko <grygorii.strashko at ti.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
---
 arch/arm/mach-omap2/mux.c        | 4 ++--
 arch/arm/mach-omap2/pm34xx.c     | 9 ++++-----
 arch/arm/mach-omap2/prm_common.c | 1 +
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 176eef6ef338..12012bef8e63 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -810,13 +810,13 @@ int __init omap_mux_late_init(void)
 		return 0;
 
 	ret = request_irq(omap_prcm_event_to_irq("io"),
-		omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
+		omap_hwmod_mux_handle_irq, IRQF_SHARED,
 			"hwmod_io", omap_mux_late_init);
 
 	if (ret)
 		pr_warn("mux: Failed to setup hwmod io irq %d\n", ret);
 
-	return 0;
+	return enable_irq_wake(omap_prcm_event_to_irq("io"));
 }
 
 static void __init omap_mux_package_fixup(struct omap_mux *p,
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 2dbd3785ee6f..49604e0023c4 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -472,23 +472,22 @@ int __init omap3_pm_init(void)
 	prcm_setup_regs();
 
 	ret = request_irq(omap_prcm_event_to_irq("wkup"),
-		_prcm_int_handle_wakeup, IRQF_NO_SUSPEND, "pm_wkup", NULL);
+		_prcm_int_handle_wakeup, 0, "pm_wkup", NULL);
 
 	if (ret) {
 		pr_err("pm: Failed to request pm_wkup irq\n");
 		goto err1;
 	}
+	enable_irq_wake(omap_prcm_event_to_irq("wkup"));
 
 	/* IO interrupt is shared with mux code */
 	ret = request_irq(omap_prcm_event_to_irq("io"),
-		_prcm_int_handle_io, IRQF_SHARED | IRQF_NO_SUSPEND, "pm_io",
-		omap3_pm_init);
-	enable_irq(omap_prcm_event_to_irq("io"));
-
+		_prcm_int_handle_io, IRQF_SHARED, "pm_io", omap3_pm_init);
 	if (ret) {
 		pr_err("pm: Failed to request pm_io irq\n");
 		goto err2;
 	}
+	enable_irq_wake(omap_prcm_event_to_irq("io"));
 
 	ret = pwrdm_for_each(pwrdms_setup, NULL);
 	if (ret) {
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 5b2f5138d938..7af688273e0d 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -338,6 +338,7 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
 		ct->chip.irq_ack = irq_gc_ack_set_bit;
 		ct->chip.irq_mask = irq_gc_mask_clr_bit;
 		ct->chip.irq_unmask = irq_gc_mask_set_bit;
+		ct->chip.flags = IRQCHIP_SKIP_SET_WAKE;
 
 		ct->regs.ack = irq_setup->ack + i * 4;
 		ct->regs.mask = irq_setup->mask + i * 4;
-- 
1.9.1



From ard.biesheuvel at linaro.org  Mon Feb  1 10:30:17 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  1 Feb 2016 19:30:17 +0100
Subject: [PATCH] arm64: move back to generic memblock_enforce_memory_limit()
In-Reply-To: <20160201180256.GJ15514@e104818-lin.cambridge.arm.com>
References: <20160201180256.GJ15514@e104818-lin.cambridge.arm.com>
Message-ID: <1454351417-23732-1-git-send-email-ard.biesheuvel@linaro.org>

Rather than implementing our own elaborate logic to clip the memory ranges
in order of preference, use the generic memblock_enforce_memory_limit() as
before, and explicitly add back that part of the kernel that needs to be
accessible via the linear mapping as well as via the kernel mapping.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/mm/init.c | 59 +++++++---------------------------------------------
 1 file changed, 7 insertions(+), 52 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index e8e853a1024c..361c91209031 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -160,41 +160,6 @@ static int __init early_mem(char *p)
 }
 early_param("mem", early_mem);
 
-/*
- * clip_mem_range() - remove memblock memory between @min and @max until
- *                    we meet the limit in 'memory_limit'.
- */
-static void __init clip_mem_range(u64 min, u64 max)
-{
-	u64 mem_size, to_remove;
-	int i;
-
-again:
-	mem_size = memblock_phys_mem_size();
-	if (mem_size <= memory_limit || max <= min)
-		return;
-
-	to_remove = mem_size - memory_limit;
-
-	for (i = memblock.memory.cnt - 1; i >= 0; i--) {
-		struct memblock_region *r = memblock.memory.regions + i;
-		u64 start = max(min, r->base);
-		u64 end = min(max, r->base + r->size);
-
-		if (start >= max || end <= min)
-			continue;
-
-		if (end > min) {
-			u64 size = min(to_remove, end - max(start, min));
-
-			memblock_remove(end - size, size);
-		} else {
-			memblock_remove(start, min(max - start, to_remove));
-		}
-		goto again;
-	}
-}
-
 void __init arm64_memblock_init(void)
 {
 	const s64 linear_region_size = -(s64)PAGE_OFFSET;
@@ -215,24 +180,14 @@ void __init arm64_memblock_init(void)
 	if (memblock_end_of_DRAM() > linear_region_size)
 		memblock_remove(0, memblock_end_of_DRAM() - linear_region_size);
 
+	/*
+	 * Apply the memory limit if it was set. Since the kernel may be loaded
+	 * high up in memory, add back the kernel region that must be accessible
+	 * via the linear mapping.
+	 */
 	if (memory_limit != (phys_addr_t)ULLONG_MAX) {
-		u64 kbase = round_down(__pa(_text), MIN_KIMG_ALIGN);
-		u64 kend = PAGE_ALIGN(__pa(_end));
-		u64 const sz_4g = 0x100000000UL;
-
-		/*
-		 * Clip memory in order of preference:
-		 * - above the kernel and above 4 GB
-		 * - between 4 GB and the start of the kernel (if the kernel
-		 *   is loaded high in memory)
-		 * - between the kernel and 4 GB (if the kernel is loaded
-		 *   low in memory)
-		 * - below 4 GB
-		 */
-		clip_mem_range(max(sz_4g, kend), ULLONG_MAX);
-		clip_mem_range(sz_4g, kbase);
-		clip_mem_range(kend, sz_4g);
-		clip_mem_range(0, min(kbase, sz_4g));
+		memblock_enforce_memory_limit(memory_limit);
+		memblock_add(__pa(__init_begin), (u64)(_end - __init_begin));
 	}
 
 	/*
-- 
2.5.0



From drivshin.allworx at gmail.com  Mon Feb  1 10:35:03 2016
From: drivshin.allworx at gmail.com (David Rivshin (Allworx))
Date: Mon, 1 Feb 2016 13:35:03 -0500
Subject: [PATCH 2/4] pwm: omap-dmtimer: add sanity checking for load and
 match values
In-Reply-To: <1454128014-22866-3-git-send-email-drivshin.allworx@gmail.com>
References: <1454128014-22866-1-git-send-email-drivshin.allworx@gmail.com>
 <1454128014-22866-3-git-send-email-drivshin.allworx@gmail.com>
Message-ID: <20160201133503.53599493.drivshin.allworx@gmail.com>

On Fri, 29 Jan 2016 23:26:52 -0500
"David Rivshin (Allworx)" <drivshin.allworx at gmail.com> wrote:

> From: David Rivshin <drivshin at allworx.com>
> 
> Add sanity checking to ensure that we do not program load or match
> values that are out of range if a user requests period or duty_cycle
> values which are not achievable. The match value cannot be less than
> the load value (but can be equal), and neither can be 0xffffffff.
> This means that there must be at least one fclk cycle between load
> and match, and another between match and overflow.
> 
> Fixes: 6604c6556db9 ("pwm: Add PWM driver for OMAP using dual-mode
> timers") Signed-off-by: David Rivshin <drivshin at allworx.com>
> ---
 [...]
> @@ -149,6 +149,24 @@ static int pwm_omap_dmtimer_config(struct pwm_chip *chip, 
> period_cycles = pwm_omap_dmtimer_get_clock_cycles(clk_rate, period_ns); 
> duty_cycles = pwm_omap_dmtimer_get_clock_cycles(clk_rate, duty_ns); 
>
> +	if (period_cycles < 2) {
> +		dev_info(chip->dev,
> +			"period %dns is too short for clock rate %luHz\n",
> +			period_ns, clk_rate);
> +		goto err_einval;
> +	}
 [...]

I had some second thoughts on this over the weekend:
1) Perhaps the return should be -ERANGE instead of -EINVAL for this case?
2) Is dev_info() too severe for this? Perhaps dev_dbg() would be better?
Any preferences?


From moinejf at free.fr  Mon Feb  1 10:40:00 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Mon, 1 Feb 2016 19:40:00 +0100
Subject: [PATCH 06/11] clk: sunxi: add generic multi-parent bus clock
 gates driver
In-Reply-To: <1454348370-3816-7-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-7-git-send-email-andre.przywara@arm.com>
Message-ID: <20160201194000.282a253b14a2ab35df8b8cc7@free.fr>

On Mon,  1 Feb 2016 17:39:25 +0000
Andre Przywara <andre.przywara at arm.com> wrote:

> The Allwinner H3 SoC introduced bus clock gates with potentially
> different parents per clock gate. The H3 driver chose to hardcode the
> actual parent clock relation in the code.
> Add a new driver (which has the potential to drive the H3 and also
> the simple clock gates as well) which uses the power of DT to describe
> this relationship in an elegant and flexible way.
> Using one subnode for every parent clock we get away with a single
> DT compatible match, which can be used as a fallback value in the
> actual DTs without the need to add specific compatible strings to the
> code.  This avoids adding a new driver or function for every new SoC.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
> Changelog RFC .. v1:
> - fix IRQ muxes to cover the three banks of the SoC
> - amend naming of PCM pins
> 
>  drivers/clk/sunxi/Makefile          |   1 +
>  drivers/clk/sunxi/clk-multi-gates.c | 105 ++++++++++++++++++++++++++++++++++++
>  2 files changed, 106 insertions(+)
>  create mode 100644 drivers/clk/sunxi/clk-multi-gates.c
	[snip]

Glad to see that things are moving to the right way. Thanks.

Acked-by: Jean-Francois Moine <moinejf at free.fr>

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/



From tony at atomide.com  Mon Feb  1 10:59:52 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Feb 2016 10:59:52 -0800
Subject: [PATCH 4/4] pwm: omap-dmtimer: add dev_dbg() message for
 effective period and duty cycle
In-Reply-To: <20160201132228.2634b72e.drivshin.allworx@gmail.com>
References: <1454128014-22866-1-git-send-email-drivshin.allworx@gmail.com>
 <1454128014-22866-5-git-send-email-drivshin.allworx@gmail.com>
 <CAA3gFWvSsctXtds6_SEtYY1yUdWJDR1XjznGS6qjdrGW5Dbw=A@mail.gmail.com>
 <20160201132228.2634b72e.drivshin.allworx@gmail.com>
Message-ID: <20160201185952.GN19432@atomide.com>

Hi,

* David Rivshin (Allworx) <drivshin.allworx at gmail.com> [160201 10:23]:
> On Sat, 30 Jan 2016 15:51:06 +0100
> Neil Armstrong <narmstrong at baylibre.com> wrote:
> 
> > 2016-01-30 5:26 GMT+01:00 David Rivshin (Allworx)
> > <drivshin.allworx at gmail.com>:
> > > From: David Rivshin <drivshin at allworx.com>
> > >
> > > After going through the math and constraints checking to compute
> > > load and match values, it is helpful to know what the resultant
> > > period and duty cycle are.
> > >
> > > Signed-off-by: David Rivshin <drivshin at allworx.com>
> > > ---
> > >
> > > I found this helpful while testing the other changes, so I included
> > > it in case it may be of use to someone in the future. I would have
> > > no issues with dropping this if it's not considered worthwhile.  
> > 
> > It's useful, but converting it as a sysfs attribute would be great !
> 
> Hrm, yes that is an interesting thought. I imagine that many PWM 
> devices have similar constraints, so perhaps that would be best 
> handled generically in the pwm core? Maybe as new optional get_*() 
> ops, a modification to the config() op to add output params, or just 
> updating new fields in the struct pwm directly?

Yeah for /sys entry it should be Linux generic. The other option
is to use debugfs for driver specific things.

Regards,

Tony


From sergei.shtylyov at cogentembedded.com  Mon Feb  1 11:00:55 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 1 Feb 2016 22:00:55 +0300
Subject: [PATCH] ARM: dts: porter: add MAX3355 support
In-Reply-To: <56AF9BE8.4020002@cogentembedded.com>
References: <1674850.BZpGW9kEud@wasted.cogentembedded.com>
 <4506196.xOgpYRO52t@wasted.cogentembedded.com>
 <SG2PR06MB0919D09C1146EAC0681EE109D8DA0@SG2PR06MB0919.apcprd06.prod.outlook.com>
 <56ABCB69.1070800@cogentembedded.com> <56ABD066.7020804@cogentembedded.com>
 <SG2PR06MB0919361DC5805AE3F5B74041D8DE0@SG2PR06MB0919.apcprd06.prod.outlook.com>
 <56AF9BE8.4020002@cogentembedded.com>
Message-ID: <56AFAB67.20404@cogentembedded.com>

On 02/01/2016 08:54 PM, Sergei Shtylyov wrote:

>>>>>> From: linux-renesas-soc-owner at vger.kernel.org
>>>>>> [mailto:linux-renesas-soc-owner at vger.kernel.org] On Behalf Of Sergei
>>>>>> Shtylyov
>>>>>> Sent: Wednesday, January 27, 2016 7:14 AM
>>>>>>
>>>>>> Now that Maxim Integrated MAX3355 'extcon' driver and device tree bindings
>>>>>> are upstream along with the 'extcon' hook  in the Renesas USBHS driver, we
>>>>>> can add  MAX3355 device node to  the Porter device tree and properly refer
>>>>>> to it from the USBHS node instead of using  "renesas,enable-gpio" property
>>>>>> which only allowed checking the USB ID pin  at the driver probe time;  now
>>>>>> this  pin's  state can be monitored dynamically!
>>>>>>
>>>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>>>>>
>>>>> I tested this patch on Porter, but interrupt of "usb-otg" didn't happened
>>>>> even if I connected/disconnected a usb convert cable (usb micro-ab to A).
>>>>> Remarks: I confirmed that the usb convert cable worked correctly on other
>>>>> board.
>>>>
>>>>      I guess I have the same cable
>>>
>>>      No, I have mini-AB connector here and hence my cable is mini-AB to A.
>>
>> I checked Porter specification and then I found 2 specifications exist...
>
>     I've looked thru my schematics files and found 3: Rev. 1.1 Update Version
> 2, "PORTER_2" Rev. 3.0 Preliminary, and "PORTER_C" Rev. 3.0 Release version!
> I'm not sure which of the last 2 should be considered final...

    Now I've found 5 versions of the Porter schematics... :-)

>>   Porter "B" : mini AB connecter and Max3355 is on the board.
>>   Porter "C" : micro AB connect and Max3355 is not on the board. (Select
>> host/peripheral by a jumper.)
>
>     Yeah, seeing JP13 in the PORTER_C schematics.
>
>> I guess that your current target is "B".
>
>     If not earlier. It actually has "Henninger B REV2" printed on it and
> "Porter PCB 1 R3" on a pasted sticker.
>
>> If so, I think this patch is acceptable.
>
>     I'm not so sure now...

    My boss told me PORTER_C is a final version, so this patch isn't needed. 
But then another patch is needed instead: to remove "renesas,enable-gpio" prop 
from the HS-USB device node...

>> Best regards,
>> Yoshihiro Shimoda

MBR, Sergei



From nico at fluxnic.net  Mon Feb  1 11:12:09 2016
From: nico at fluxnic.net (Nicolas Pitre)
Date: Mon, 01 Feb 2016 14:12:09 -0500 (EST)
Subject: [PATCH v4] ARM: xip: Use correct symbol for end of ROM marker
In-Reply-To: <1454349165-12249-1-git-send-email-chris.brandt@renesas.com>
References: <1447697140-4099-1-git-send-email-chris.brandt@renesas.com>
 <1454349165-12249-1-git-send-email-chris.brandt@renesas.com>
Message-ID: <alpine.LFD.2.20.1602011404420.32766@knanqh.ubzr>

On Mon, 1 Feb 2016, Chris Brandt wrote:

> For an XIP build, __data_loc, not _etext, represents the end of the
> binary image that needs to stay mapped into the MODULES_VADDR area.
> Years ago, data came before text in the memory map. However,
> now that the order is text/init/data, an XIP_KERNEL needs to map
> up to the __data_loc symbol in order to keep from cutting off
> parts of the kernel that are needed.
> We only map up to the beginning of data because data has already been
> copied, so there's no reason to keep it around anymore.
> 
> This fixes the bug where you might lose the end of your kernel area
> after page table setup is complete.
> 
> Signed-off-by: Chris Brandt <chris.brandt at renesas.com>

The __data_loc symbol doesn't convey much to say with regards to XIP 
mapping.  It would be better to dedicate another symbol with a proper 
name instead.  Something like xiprom_start and xiprom_end perhaps.  
This way, someone looking at the linker script won't be fooled by a 
hidden meaning tied to _etext or __data_loc.


> ---
> v4:
> * Switched from using _edata_loc __data_loc.
>   Made commit text more accurate.
> v3:
> * Removed sections.h from Kbuild
> v2:
> * Added change for MODULES_VADDR
> * Moved extern to new file asm/sections.h
> ---
>  arch/arm/include/asm/Kbuild     | 1 -
>  arch/arm/include/asm/sections.h | 8 ++++++++
>  arch/arm/kernel/module.c        | 2 +-
>  arch/arm/mm/mmu.c               | 8 ++++++--
>  4 files changed, 15 insertions(+), 4 deletions(-)
>  create mode 100644 arch/arm/include/asm/sections.h
> 
> diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
> index 16da638..3f6616b 100644
> --- a/arch/arm/include/asm/Kbuild
> +++ b/arch/arm/include/asm/Kbuild
> @@ -23,7 +23,6 @@ generic-y += preempt.h
>  generic-y += resource.h
>  generic-y += rwsem.h
>  generic-y += seccomp.h
> -generic-y += sections.h
>  generic-y += segment.h
>  generic-y += sembuf.h
>  generic-y += serial.h
> diff --git a/arch/arm/include/asm/sections.h b/arch/arm/include/asm/sections.h
> new file mode 100644
> index 0000000..8d50cce
> --- /dev/null
> +++ b/arch/arm/include/asm/sections.h
> @@ -0,0 +1,8 @@
> +#ifndef _ASM_ARM_SECTIONS_H
> +#define _ASM_ARM_SECTIONS_H
> +
> +#include <asm-generic/sections.h>
> +
> +extern char __data_loc[];
> +
> +#endif	/* _ASM_ARM_SECTIONS_H */
> diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
> index efdddcb..b48e3bc 100644
> --- a/arch/arm/kernel/module.c
> +++ b/arch/arm/kernel/module.c
> @@ -34,7 +34,7 @@
>   * recompiling the whole kernel when CONFIG_XIP_KERNEL is turned on/off.
>   */
>  #undef MODULES_VADDR
> -#define MODULES_VADDR	(((unsigned long)_etext + ~PMD_MASK) & PMD_MASK)
> +#define MODULES_VADDR	(((unsigned long)__data_loc + ~PMD_MASK) & PMD_MASK)
>  #endif
>  
>  #ifdef CONFIG_MMU
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 434d76f..53d7a88 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1253,7 +1253,7 @@ static inline void prepare_page_table(void)
>  
>  #ifdef CONFIG_XIP_KERNEL
>  	/* The XIP kernel is mapped in the module area -- skip over it */
> -	addr = ((unsigned long)_etext + PMD_SIZE - 1) & PMD_MASK;
> +	addr = ((unsigned long)__data_loc + PMD_SIZE - 1) & PMD_MASK;
>  #endif
>  	for ( ; addr < PAGE_OFFSET; addr += PMD_SIZE)
>  		pmd_clear(pmd_off_k(addr));
> @@ -1335,7 +1335,7 @@ static void __init devicemaps_init(const struct machine_desc *mdesc)
>  #ifdef CONFIG_XIP_KERNEL
>  	map.pfn = __phys_to_pfn(CONFIG_XIP_PHYS_ADDR & SECTION_MASK);
>  	map.virtual = MODULES_VADDR;
> -	map.length = ((unsigned long)_etext - map.virtual + ~SECTION_MASK) & SECTION_MASK;
> +	map.length = ((unsigned long)__data_loc - map.virtual + ~SECTION_MASK) & SECTION_MASK;
>  	map.type = MT_ROM;
>  	create_mapping(&map);
>  #endif
> @@ -1426,7 +1426,11 @@ static void __init kmap_init(void)
>  static void __init map_lowmem(void)
>  {
>  	struct memblock_region *reg;
> +#ifdef CONFIG_XIP_KERNEL
> +	phys_addr_t kernel_x_start = round_down(__pa(_sdata), SECTION_SIZE);
> +#else
>  	phys_addr_t kernel_x_start = round_down(__pa(_stext), SECTION_SIZE);
> +#endif
>  	phys_addr_t kernel_x_end = round_up(__pa(__init_end), SECTION_SIZE);
>  
>  	/* Map all the lowmem memory banks. */
> -- 
> 1.9.1
> 
> 
> 


From arnd at arndb.de  Mon Feb  1 11:22:43 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 01 Feb 2016 20:22:43 +0100
Subject: [PATCH] ARM: vmlinux.lds: assert that ROM and RAM don't overlap
 when XIP_KERNEL=y
In-Reply-To: <1454346154-12931-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454346154-12931-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <10106138.pyoAFMVxSu@wuerfel>

On Monday 01 February 2016 18:02:34 Ard Biesheuvel wrote:
> When building an XIP kernel, the linker produces two disjoint VMA regions,
> where the first is mapped onto ROM and the second onto RAM. For this reason,
> the linker output pointer '.' is updated halfway through the linker script,
> and set to a value that corresponds with the start of the RAM region.
> 
> However, in some cases, the ROM region exceeds the expected size, and the
> assignment of the output pointer results in a decrement rather than an
> increment, causing the virtual addresses of the .data region to clash with
> the .text region. Such a kernel cannot boot normally, but it also confuses
> the hell out of kallsyms, since .data symbols may appear inside the
> [_stext, _etext] or [_sinittext, _einittext] intervals in the first pass,
> but not in the second (or vice versa), resulting in inconsistent kallsyms
> data.
> 
> So let's make sure that the output pointer only advances, and never jumps
> back into the ROM region.
> 
> Cc: arnd at arndb.de
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> 

Acked-by: Arnd Bergmann <arnd at arndb.de>

I've tested this in multiple configurations, and it reliably prints
a useful error message in broken configurations, while it has no
effect on working configurations. This is more helpful than the
mysterious

   Inconsistent kallsyms data
   Try make KALLSYMS_EXTRA_PASS=1 as a workaround

message that we get without the patch.

	Arnd


From maxime.ripard at free-electrons.com  Mon Feb  1 11:32:32 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 1 Feb 2016 20:32:32 +0100
Subject: [PATCH 1/2] clk: sunxi: delay protected clocks until arch initcall
In-Reply-To: <56A91245.3090706@collabora.co.uk>
References: <1453385439-10154-1-git-send-email-emilio.lopez@collabora.co.uk>
 <1453385439-10154-2-git-send-email-emilio.lopez@collabora.co.uk>
 <20160127153722.GC4317@lukather> <56A91245.3090706@collabora.co.uk>
Message-ID: <20160201193232.GG4652@lukather>

Hi,

On Wed, Jan 27, 2016 at 03:53:57PM -0300, Emilio L?pez wrote:
> Hi Maxime,
> 
> El 27/01/16 a las 12:37, Maxime Ripard escribi?:
> >Hi Emilio,
> >
> >On Thu, Jan 21, 2016 at 11:10:38AM -0300, Emilio L?pez wrote:
> >>Clocks are registered early on, and unused clocks get disabled on
> >>late initcall, so we can delay protecting important clocks a bit.
> >>If we do this too early, it may happen that some clocks are orphans
> >>and therefore enabling them may not work as intended. If we do this
> >>too late, a driver may reparent some clock and cause another important
> >>clock to be disabled as a byproduct.
> >>
> >>arch_initcall should be a good spot to do this, as clock drivers using
> >>the OF mechanisms will be all registered by then, and drivers won't
> >>have started probing yet.
> >>
> >>Signed-off-by: Emilio L?pez <emilio.lopez at collabora.co.uk>
> >>---
> >>  drivers/clk/sunxi/clk-sunxi.c | 22 ++++++++++++++++++----
> >>  1 file changed, 18 insertions(+), 4 deletions(-)
> >>
> >>diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> >>index 5ba2188..285e8ee 100644
> >>--- a/drivers/clk/sunxi/clk-sunxi.c
> >>+++ b/drivers/clk/sunxi/clk-sunxi.c
> >>@@ -1153,10 +1153,12 @@ static void __init of_sunxi_table_clock_setup(const struct of_device_id *clk_mat
> >>  	}
> >>  }
> >>
> >>+/* By default, don't protect any clocks */
> >>+static const char **protected_clocks __initdata;
> >>+static int protected_clocks_nr __initdata;
> >>+
> >>  static void __init sunxi_init_clocks(const char *clocks[], int nclocks)
> >>  {
> >>-	unsigned int i;
> >>-
> >>  	/* Register divided output clocks */
> >>  	of_sunxi_table_clock_setup(clk_divs_match, sunxi_divs_clk_setup);
> >>
> >>@@ -1169,14 +1171,26 @@ static void __init sunxi_init_clocks(const char *clocks[], int nclocks)
> >>  	/* Register mux clocks */
> >>  	of_sunxi_table_clock_setup(clk_mux_match, sunxi_mux_clk_setup);
> >>
> >>+	/* We shall protect these clocks when everything is ready */
> >>+	protected_clocks = clocks;
> >>+	protected_clocks_nr = nclocks;
> >>+}
> >>+
> >>+static int __init sunxi_init_clock_protection(void)
> >>+{
> >>+	unsigned int i;
> >>+
> >>  	/* Protect the clocks that needs to stay on */
> >>-	for (i = 0; i < nclocks; i++) {
> >>-		struct clk *clk = clk_get(NULL, clocks[i]);
> >>+	for (i = 0; i < protected_clocks_nr; i++) {
> >>+		struct clk *clk = clk_get(NULL, protected_clocks[i]);
> >>
> >>  		if (!IS_ERR(clk))
> >>  			clk_prepare_enable(clk);
> >>  	}
> >>+
> >>+	return 0;
> >>  }
> >>+arch_initcall(sunxi_init_clock_protection);
> >
> >You also need to filter that by the machine compatible in case you're
> >running it on a !sunxi SoC.
> 
> protected_clocks_nr will be 0 on a !sunxi machine, so this is effectively a
> noop there.

Ah, yes, good point.

> >Overall, I'm a bit skeptical about the approach. It doesn't really fix
> >everything, just hides it behind a curtain, and I'm pretty sure the
> >clocks not registered by this code would still be broken (the mod0
> >clocks for example).
> 
> This is only meant to solve the problems observed when trying to grab
> critical clocks before letting all the basic/OF clock types register. The
> actual clock trees are complete once all the built-in clock compatibles are
> probed, so this just pushes the protection after that point in time. The
> plan on the long term should be to use the CCF-built-in clock protection,
> once it's finished and merged, but it's not here yet.
> 
> Regarding your example, I'm not aware of any critical mod0 clocks (not that
> it should matter, as they won't be orphans either).

My bad, the A13 mbus clock is one. The A23 is one too.

Both of these are probed through CLK_OF_DECLARE, and use directly
clk_prepare_enable on the clock given back by clk_register, which
won't work in your case.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160201/f9b58d28/attachment.sig>

From dhdang at apm.com  Mon Feb  1 11:38:08 2016
From: dhdang at apm.com (Duc Dang)
Date: Mon, 1 Feb 2016 11:38:08 -0800
Subject: [PATCH v4 1/3] mailbox: Add support for APM X-Gene platform
 mailbox driver
In-Reply-To: <abff73c051fd06a9dd3b04a1e7957ad5a9b69a18.1452912126.git.dhdang@apm.com>
References: <CABb+yY2zHycEmsVvp8OFwpJ1PZgrEPpV-oOe56wgFJ=EE0nTcg@mail.gmail.com>
 <cover.1452912126.git.dhdang@apm.com>
 <abff73c051fd06a9dd3b04a1e7957ad5a9b69a18.1452912126.git.dhdang@apm.com>
Message-ID: <CADaLNDmSiK27wYBSo8-DsafmG5jUumUR5WYgConeSFXGNjH6+w@mail.gmail.com>

Hi Jassi,

On Fri, Jan 15, 2016 at 6:57 PM, Duc Dang <dhdang at apm.com> wrote:
> X-Gene mailbox controller provides 8 mailbox channels, with
> each channel has a dedicated interrupt line.

Did you have a chance to look into this version 4 of my mail-box patch?

Regards,
Duc Dang.
>
> Signed-off-by: Feng Kan <fkan at apm.com>
> Signed-off-by: Duc Dang <dhdang at apm.com>
> ---
> Changes since v3:
>         - Rebase over v4.4
>         - Remove 'id' in slimpro_mbox_chan structure
>         - Remove small functions that are only called once
>         and fold them into the other callers
>         - Remove void* pointer type cast
>         - Relax the number of mailbox IRQs condition
>         - Use subsys_initcall to guarantee mailbox driver
>         will be registered before any other dependent driver
>         is loaded.
>
>  drivers/mailbox/Kconfig                 |   9 ++
>  drivers/mailbox/Makefile                |   2 +
>  drivers/mailbox/mailbox-xgene-slimpro.c | 265 ++++++++++++++++++++++++++++++++
>  3 files changed, 276 insertions(+)
>  create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c
>
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index 546d05f..678e434 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -85,4 +85,13 @@ config MAILBOX_TEST
>           Test client to help with testing new Controller driver
>           implementations.
>
> +config XGENE_SLIMPRO_MBOX
> +       tristate "APM SoC X-Gene SLIMpro Mailbox Controller"
> +       depends on ARCH_XGENE
> +       help
> +         An implementation of the APM X-Gene Interprocessor Communication
> +         Mailbox (IPCM) between the ARM 64-bit cores and SLIMpro controller.
> +         It is used to send short messages between ARM64-bit cores and
> +         the SLIMpro Management Engine, primarily for PM. Say Y here if you
> +         want to use the APM X-Gene SLIMpro IPCM support.
>  endif
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index 92435ef..b602ef8 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -17,3 +17,5 @@ obj-$(CONFIG_ALTERA_MBOX)     += mailbox-altera.o
>  obj-$(CONFIG_BCM2835_MBOX)     += bcm2835-mailbox.o
>
>  obj-$(CONFIG_STI_MBOX)         += mailbox-sti.o
> +
> +obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
> diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c b/drivers/mailbox/mailbox-xgene-slimpro.c
> new file mode 100644
> index 0000000..a7b0c9e
> --- /dev/null
> +++ b/drivers/mailbox/mailbox-xgene-slimpro.c
> @@ -0,0 +1,265 @@
> +/*
> + * APM X-Gene SLIMpro MailBox Driver
> + *
> + * Copyright (c) 2015, Applied Micro Circuits Corporation
> + * Author: Feng Kan fkan at apm.com
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * 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/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/mailbox_controller.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/spinlock.h>
> +
> +#define MBOX_CON_NAME                  "slimpro-mbox"
> +#define MBOX_REG_SET_OFFSET            0x1000
> +#define MBOX_CNT                       8
> +#define MBOX_STATUS_AVAIL_MASK         BIT(16)
> +#define MBOX_STATUS_ACK_MASK           BIT(0)
> +
> +/* Configuration and Status Registers */
> +#define REG_DB_IN              0x00
> +#define REG_DB_DIN0            0x04
> +#define REG_DB_DIN1            0x08
> +#define REG_DB_OUT             0x10
> +#define REG_DB_DOUT0           0x14
> +#define REG_DB_DOUT1           0x18
> +#define REG_DB_STAT            0x20
> +#define REG_DB_STATMASK                0x24
> +
> +struct slimpro_mbox_chan {
> +       struct device *dev;
> +       struct mbox_chan *chan;
> +       void __iomem *reg;
> +       int irq;
> +       u32 rx_msg[3];
> +};
> +
> +struct slimpro_mbox {
> +       struct mbox_controller mb_ctrl;
> +       struct slimpro_mbox_chan mc[MBOX_CNT];
> +       struct mbox_chan chans[MBOX_CNT];
> +};
> +
> +static void mb_chan_send_msg(struct slimpro_mbox_chan *mb_chan, u32 *msg)
> +{
> +       writel(msg[1], mb_chan->reg + REG_DB_DOUT0);
> +       writel(msg[2], mb_chan->reg + REG_DB_DOUT1);
> +       writel(msg[0], mb_chan->reg + REG_DB_OUT);
> +}
> +
> +static void mb_chan_recv_msg(struct slimpro_mbox_chan *mb_chan)
> +{
> +       mb_chan->rx_msg[1] = readl(mb_chan->reg + REG_DB_DIN0);
> +       mb_chan->rx_msg[2] = readl(mb_chan->reg + REG_DB_DIN1);
> +       mb_chan->rx_msg[0] = readl(mb_chan->reg + REG_DB_IN);
> +}
> +
> +static int mb_chan_status_ack(struct slimpro_mbox_chan *mb_chan)
> +{
> +       u32 val = readl(mb_chan->reg + REG_DB_STAT);
> +
> +       if (val & MBOX_STATUS_ACK_MASK) {
> +               writel(MBOX_STATUS_ACK_MASK, mb_chan->reg + REG_DB_STAT);
> +               return 1;
> +       }
> +       return 0;
> +}
> +
> +static int mb_chan_status_avail(struct slimpro_mbox_chan *mb_chan)
> +{
> +       u32 val = readl(mb_chan->reg + REG_DB_STAT);
> +
> +       if (val & MBOX_STATUS_AVAIL_MASK) {
> +               mb_chan_recv_msg(mb_chan);
> +               writel(MBOX_STATUS_AVAIL_MASK, mb_chan->reg + REG_DB_STAT);
> +               return 1;
> +       }
> +       return 0;
> +}
> +
> +static irqreturn_t slimpro_mbox_irq(int irq, void *id)
> +{
> +       struct slimpro_mbox_chan *mb_chan = id;
> +
> +       if (mb_chan_status_ack(mb_chan))
> +               mbox_chan_txdone(mb_chan->chan, 0);
> +
> +       if (mb_chan_status_avail(mb_chan))
> +               mbox_chan_received_data(mb_chan->chan, mb_chan->rx_msg);
> +
> +       return IRQ_HANDLED;
> +}
> +
> +static int slimpro_mbox_send_data(struct mbox_chan *chan, void *msg)
> +{
> +       struct slimpro_mbox_chan *mb_chan = chan->con_priv;
> +
> +       mb_chan_send_msg(mb_chan, msg);
> +       return 0;
> +}
> +
> +static int slimpro_mbox_startup(struct mbox_chan *chan)
> +{
> +       struct slimpro_mbox_chan *mb_chan = chan->con_priv;
> +       int rc;
> +       u32 val;
> +
> +       rc = devm_request_irq(mb_chan->dev, mb_chan->irq, slimpro_mbox_irq, 0,
> +                             MBOX_CON_NAME, mb_chan);
> +       if (unlikely(rc)) {
> +               dev_err(mb_chan->dev, "failed to register mailbox interrupt %d\n",
> +                       mb_chan->irq);
> +               return rc;
> +       }
> +
> +       /* Enable HW interrupt */
> +       writel(MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK,
> +              mb_chan->reg + REG_DB_STAT);
> +       /* Unmask doorbell status interrupt */
> +       val = readl(mb_chan->reg + REG_DB_STATMASK);
> +       val &= ~(MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK);
> +       writel(val, mb_chan->reg + REG_DB_STATMASK);
> +
> +       return 0;
> +}
> +
> +static void slimpro_mbox_shutdown(struct mbox_chan *chan)
> +{
> +       struct slimpro_mbox_chan *mb_chan = chan->con_priv;
> +       u32 val;
> +
> +       /* Mask doorbell status interrupt */
> +       val = readl(mb_chan->reg + REG_DB_STATMASK);
> +       val |= (MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK);
> +       writel(val, mb_chan->reg + REG_DB_STATMASK);
> +
> +       devm_free_irq(mb_chan->dev, mb_chan->irq, mb_chan);
> +}
> +
> +static struct mbox_chan_ops slimpro_mbox_ops = {
> +       .send_data = slimpro_mbox_send_data,
> +       .startup = slimpro_mbox_startup,
> +       .shutdown = slimpro_mbox_shutdown,
> +};
> +
> +static int __init slimpro_mbox_probe(struct platform_device *pdev)
> +{
> +       struct slimpro_mbox *ctx;
> +       struct resource *regs;
> +       void __iomem *mb_base;
> +       int rc;
> +       int i;
> +
> +       ctx = devm_kzalloc(&pdev->dev, sizeof(struct slimpro_mbox), GFP_KERNEL);
> +       if (IS_ERR(ctx))
> +               return PTR_ERR(ctx);
> +
> +       platform_set_drvdata(pdev, ctx);
> +
> +       regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       mb_base = devm_ioremap(&pdev->dev, regs->start, resource_size(regs));
> +       if (IS_ERR(mb_base))
> +               return PTR_ERR(mb_base);
> +
> +       /* Setup mailbox links */
> +       for (i = 0; i < MBOX_CNT; i++) {
> +               ctx->mc[i].irq = platform_get_irq(pdev, i);
> +               if (ctx->mc[i].irq < 0) {
> +                       if (i == 0) {
> +                               dev_err(&pdev->dev, "no available IRQ\n");
> +                               return -EINVAL;
> +                       }
> +                       dev_info(&pdev->dev, "no IRQ at index %d\n",
> +                               ctx->mc[i].irq);
> +                       break;
> +               }
> +
> +               ctx->mc[i].dev = &pdev->dev;
> +               ctx->mc[i].reg = mb_base + i * MBOX_REG_SET_OFFSET;
> +               ctx->mc[i].chan = &ctx->chans[i];
> +               ctx->chans[i].con_priv = &ctx->mc[i];
> +       }
> +
> +       /* Setup mailbox controller */
> +       ctx->mb_ctrl.dev = &pdev->dev;
> +       ctx->mb_ctrl.chans = ctx->chans;
> +       ctx->mb_ctrl.txdone_irq = true;
> +       ctx->mb_ctrl.ops = &slimpro_mbox_ops;
> +       ctx->mb_ctrl.num_chans = i;
> +
> +       rc = mbox_controller_register(&ctx->mb_ctrl);
> +       if (rc) {
> +               dev_err(&pdev->dev,
> +                       "APM X-Gene SLIMpro MailBox register failed:%d\n", rc);
> +               return rc;
> +       }
> +
> +       dev_info(&pdev->dev, "APM X-Gene SLIMpro MailBox registered\n");
> +       return 0;
> +}
> +
> +static int slimpro_mbox_remove(struct platform_device *pdev)
> +{
> +       struct slimpro_mbox *smb = platform_get_drvdata(pdev);
> +
> +       mbox_controller_unregister(&smb->mb_ctrl);
> +       return 0;
> +}
> +
> +static const struct of_device_id slimpro_of_match[] = {
> +       {.compatible = "apm,xgene-slimpro-mbox" },
> +       { },
> +};
> +MODULE_DEVICE_TABLE(of, slimpro_of_match);
> +
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id slimpro_acpi_ids[] = {
> +       {"APMC0D01", 0},
> +       {}
> +};
> +MODULE_DEVICE_TABLE(acpi, slimpro_acpi_ids);
> +#endif
> +
> +static struct platform_driver slimpro_mbox_driver = {
> +       .probe  = slimpro_mbox_probe,
> +       .remove = slimpro_mbox_remove,
> +       .driver = {
> +               .name = "xgene-slimpro-mbox",
> +               .of_match_table = of_match_ptr(slimpro_of_match),
> +               .acpi_match_table = ACPI_PTR(slimpro_acpi_ids)
> +       },
> +};
> +
> +static int __init slimpro_mbox_init(void)
> +{
> +       return platform_driver_register(&slimpro_mbox_driver);
> +}
> +
> +static void __exit slimpro_mbox_exit(void)
> +{
> +       platform_driver_unregister(&slimpro_mbox_driver);
> +}
> +
> +subsys_initcall(slimpro_mbox_init);
> +module_exit(slimpro_mbox_exit);
> +
> +MODULE_DESCRIPTION("APM X-Gene SLIMpro Mailbox Driver");
> +MODULE_LICENSE("GPL");
> --
> 1.9.1
>


From Chris.Brandt at renesas.com  Mon Feb  1 11:41:08 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Mon, 1 Feb 2016 19:41:08 +0000
Subject: [PATCH v4] ARM: xip: Use correct symbol for end of ROM marker
In-Reply-To: <alpine.LFD.2.20.1602011404420.32766@knanqh.ubzr>
References: <1447697140-4099-1-git-send-email-chris.brandt@renesas.com>
 <1454349165-12249-1-git-send-email-chris.brandt@renesas.com>
 <alpine.LFD.2.20.1602011404420.32766@knanqh.ubzr>
Message-ID: <SG2PR06MB0572F0EE79C00A530FA9CF398ADE0@SG2PR06MB0572.apcprd06.prod.outlook.com>

On Mon, 1 Feb 2016, Nicolas Pitre wrote:

> The __data_loc symbol doesn't convey much to say with regards to XIP
> mapping.  It would be better to dedicate another symbol with a proper
> name instead.  Something like xiprom_start and xiprom_end perhaps.  
> This way, someone looking at the linker script won't be fooled by a
> hidden meaning tied to _etext or __data_loc.

That's fine by me.


However, I just saw the email "[PATCH] ARM: vmlinux.lds: assert that ROM and RAM don't overlap when XIP_KERNEL=y" sent in a little while ago.

So, do we first want to reconsider splitting out the XIP stuff into a separate linker script? Hence my proposal form November "[PATCH v2] ARM: xip: Move XIP linking to a separate file".

Or, should we keep piling more stuff in vmlinux.lds.S?


Chris



From stripathi at apm.com  Mon Feb  1 11:43:56 2016
From: stripathi at apm.com (Suman Tripathi)
Date: Mon, 1 Feb 2016 11:43:56 -0800
Subject: [PATCH v2 2/3] libahci: Implement the capability to override the
 generic ahci interrupt handler.
In-Reply-To: <20160131113540.GX32380@htj.duckdns.org>
References: <1453888197-11368-1-git-send-email-stripathi@apm.com>
 <1453888197-11368-3-git-send-email-stripathi@apm.com>
 <20160131113540.GX32380@htj.duckdns.org>
Message-ID: <CAOHikRBmZ2Nk5knH7_4X+ieTYN9ubWrEwhTNAvQzq5cxWmLDJA@mail.gmail.com>

On Sun, Jan 31, 2016 at 3:35 AM, Tejun Heo <htejun at gmail.com> wrote:
> On Wed, Jan 27, 2016 at 03:19:56PM +0530, Suman Tripathi wrote:
>> @@ -2466,13 +2467,19 @@ int ahci_host_activate(struct ata_host *host, struct scsi_host_template *sht)
>>  {
>>       struct ahci_host_priv *hpriv = host->private_data;
>>       int irq = hpriv->irq;
>> +     irqreturn_t (*ahci_irq_handler)(int irq, void *dev_instance);
>>       int rc;
>>
>>       if (hpriv->flags & (AHCI_HFLAG_MULTI_MSI | AHCI_HFLAG_MULTI_MSIX))
>>               rc = ahci_host_activate_multi_irqs(host, sht);
>
> You need to add { } to the if body too.  Please read CodingStyle.
>
>> -     else
>> -             rc = ata_host_activate(host, irq, ahci_single_level_irq_intr,
>> +     else {
>> +             ahci_irq_handler = hpriv->ahci_irq_intr ? hpriv->ahci_irq_intr :
>> +                                ahci_single_level_irq_intr;
>> +
>> +             rc = ata_host_activate(host, irq, ahci_irq_handler,
>>                                      IRQF_SHARED, sht);
>> +     }
>
> Can you please make this handled the same way as ->start_engine?
> Also, maybe print out a warning message if a driver specifies both
> AHCI_HFLAG_MULTI_MSI[X] and the irq handler override?

Ok Sure
>
> Thanks.
>
> --
> tejun



-- 
Thanks,
with regards,
Suman Tripathi


From sboyd at codeaurora.org  Mon Feb  1 11:44:32 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 1 Feb 2016 11:44:32 -0800
Subject: [PATCH] recordmcount: arm: Implement make_nop
In-Reply-To: <20160130184005.GA29607@debian>
References: <1454116686-30190-1-git-send-email-sboyd@codeaurora.org>
 <20160130184005.GA29607@debian>
Message-ID: <20160201194432.GK4848@codeaurora.org>

On 01/30, Rabin Vincent wrote:
> On Fri, Jan 29, 2016 at 05:18:06PM -0800, Stephen Boyd wrote:
> > diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
> > index e167592793a7..0b16d14c54fb 100644
> > --- a/scripts/recordmcount.c
> > +++ b/scripts/recordmcount.c
> > @@ -206,6 +206,52 @@ static int make_nop_x86(void *map, size_t const offset)
> >  	return 0;
> >  }
> >  
> > +/*
> > + * Indicates if ARM is using __gnu_mcount_nc or mcount style and if
> > + * we should replace it with a pop or a nop respectively.
> > + */
> 
> For __gnu_mcount_nc, wouldn't it be better to replace both the push {lr}
> and the bl with nop instructions, instead of keeping a (useless) push +
> pop sequence?

Agreed. I was trying to do a 1-to-1 copy of the ftrace code on
ARM.  I was wondering the same thing in that code path while
doing this though. Can't we replace both instructions instead of
one instruction when we're patching in nops at runtime?

> 
> > +static int uses_altmcount;
> > +
> > +static unsigned char ideal_nop4_arm_arm[4] = { 0x00, 0x40, 0xbd, 0xe8 };
> > +static unsigned char ideal_nop4_arm_thumb[4] = { 0x5d, 0xf8, 0x04, 0xeb };
> > +static unsigned char ideal_nop4_arm_arm_be[4] = { 0xe8, 0xbd, 0x40, 0x00 };
> > +static unsigned char ideal_nop4_arm_thumb_be[4] = { 0xf8, 0x5d, 0xeb, 0x04 };
> > +static unsigned char ideal_nop4_arm_old[4] = { 0x00, 0x00, 0xa0, 0xe1 };
> > +static unsigned char ideal_nop4_arm_old_be[4] = { 0xe1, 0xa0, 0x00, 0x00 };
> > +
> > +static unsigned char bl_gnu_mcount_nc_arm[4] = { 0xfe, 0xff, 0xff, 0xeb };
> > +static unsigned char bl_gnu_mcount_nc_thumb[4] = { 0xff, 0xf7, 0xfe, 0xff };
> > +static unsigned char bl_gnu_mcount_nc_arm_be[4] = { 0xeb, 0xff, 0xff, 0xfe };
> > +static unsigned char bl_gnu_mcount_nc_thumb_be[4] = { 0xf7, 0xff, 0xff, 0xfe };
> 
> Comments showing what assembly instructions all these correspond to
> would be helpful.

Sure.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From stripathi at apm.com  Mon Feb  1 11:45:00 2016
From: stripathi at apm.com (Suman Tripathi)
Date: Mon, 1 Feb 2016 11:45:00 -0800
Subject: [PATCH v2 1/3] ata: Remove the AHCI_HFLAG_EDGE_IRQ support from
 libahci.
In-Reply-To: <20160131113249.GW32380@htj.duckdns.org>
References: <1453888197-11368-1-git-send-email-stripathi@apm.com>
 <1453888197-11368-2-git-send-email-stripathi@apm.com>
 <20160131113249.GW32380@htj.duckdns.org>
Message-ID: <CAOHikRBbTafF68qF9n+HNo4p6bwAShZtObw8sPDe45QmG0Xxiw@mail.gmail.com>

On Sun, Jan 31, 2016 at 3:32 AM, Tejun Heo <htejun at gmail.com> wrote:
> On Wed, Jan 27, 2016 at 03:19:55PM +0530, Suman Tripathi wrote:
>> This patch removes the AHCI_HFLAG_EDGE_IRQ support from libahci.
>> The upcoming patches will have the flexibility to override
>> irq handlers in the LLD's. Controller's implementing a EDGE trigger
>> latch can implement their own interrupt handler inside the driver.
>>
>> Signed-off-by: Suman Tripathi <stripathi at apm.com>
>
> Shouldn't this patch come after the irq override is in place?
>
> 1. introduce irq override.
>
> 2. remove AHCI_HFLAG_EDGE_IRQ by moving the edge triggered handler to
>    ahci_xgene.
>
> 3. Update xgene irq handler to address the erratum.

Thought of remove the AHCI_HFLAG_EDGE entirely first because we don't
require it . Then implement the irq override capability.
>
> Thanks.
>
> --
> tejun



-- 
Thanks,
with regards,
Suman Tripathi


From maxime.ripard at free-electrons.com  Mon Feb  1 11:46:26 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 1 Feb 2016 20:46:26 +0100
Subject: [PATCH v3 2/2] clk: sunxi: Refactor A31 PLL6 so that it can be
 reused
In-Reply-To: <CAGb2v67v6-BCPp2u7vieCGnCAsHFv4XjnRXvfT1vZNHc_Ok0UA@mail.gmail.com>
References: <1454008958-12655-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454008958-12655-2-git-send-email-maxime.ripard@free-electrons.com>
 <56AB38C6.2010909@gmail.com>
 <CAGb2v67v6-BCPp2u7vieCGnCAsHFv4XjnRXvfT1vZNHc_Ok0UA@mail.gmail.com>
Message-ID: <20160201194626.GH4652@lukather>

On Fri, Jan 29, 2016 at 06:14:48PM +0800, Chen-Yu Tsai wrote:
> >> @@ -173,7 +173,7 @@
> >>                       #clock-cells = <0>;
> >>                       compatible = "allwinner,sun8i-h3-ahb2-clk";
> >>                       reg = <0x01c2005c 0x4>;
> >> -                     clocks = <&ahb1>, <&pll6d2>;
> >> +                     clocks = <&ahb1>, <&pll6>;
> >
> > According to the datasheet AHB2 really has PLL6 / 2 as parent, not PLL6
> > directly.
> 
> Thanks for the save. So we should keep pll6d2_clk.

Indeed thanks for the review. Will fix for v4.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160201/48505a6b/attachment.sig>

From sboyd at codeaurora.org  Mon Feb  1 11:58:16 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 1 Feb 2016 11:58:16 -0800
Subject: [PATCH v2] clocksource/arm_arch_timer: Enable and verify MMIO
 access
In-Reply-To: <71bf617f4083b116b2aeab24f13fc5fed99a816f.1454327031.git.robin.murphy@arm.com>
References: <71bf617f4083b116b2aeab24f13fc5fed99a816f.1454327031.git.robin.murphy@arm.com>
Message-ID: <20160201195816.GL4848@codeaurora.org>

On 02/01, Robin Murphy wrote:
> So far, we have been blindly assuming that having access to a
> memory-mapped timer frame implies that the individual elements of that
> frame frame are already enabled. Whilst it's the firmware's job to give
> us non-secure access to frames in the first place, we should not rely
> on implementations always being generous enough to also configure CNTACR
> for those non-secure frames (e.g. [1]).
> 
> Explicitly enable feature-level access per-frame, and verify that the
> access we want is really implemented before trying to make use of it.
> 
> [1]:https://github.com/ARM-software/tf-issues/issues/170
> 
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---

Reviewed-by: Stephen Boyd <sboyd at codeaurora.org>
Tested-by: Stephen Boyd <sboyd at codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From dhdang at apm.com  Mon Feb  1 11:58:53 2016
From: dhdang at apm.com (Duc Dang)
Date: Mon, 1 Feb 2016 11:58:53 -0800
Subject: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI
 hostbridge init based on ACPI
In-Reply-To: <1452691267-32240-1-git-send-email-tn@semihalf.com>
References: <1452691267-32240-1-git-send-email-tn@semihalf.com>
Message-ID: <CADaLNDmwLCJhUdVgZRgZyOrwOD_RA1L=_hG+bAHKBoAYRKwCRQ@mail.gmail.com>

On Wed, Jan 13, 2016 at 5:20 AM, Tomasz Nowicki <tn at semihalf.com> wrote:
> From the functionality point of view this series might be split into the
> following logic parts:
> 1. Make MMCONFIG code arch-agnostic which allows all architectures to collect
>    PCI config regions and used when necessary.
> 2. Move non-arch specific bits to the core code.
> 3. Use MMCONFIG code and implement generic ACPI based PCI host controller driver.
> 4. Enable above driver on ARM64
>
> Patches has been built on top of 4.4 and can be found here:
> git at github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v3)
>
> NOTE, this patch set depends on Matthew's patches:
> http://www.spinics.net/lists/linux-pci/msg45950.html
> https://github.com/Vality/linux/tree/pci-fixes
>
> This has been tested on Cavium ThunderX server and QEMU.
> Any help in reviewing and testing is very appreciated.

Hi Tomasz,

I tested your tree with APM X-Gene v1 and X-Gene v2 platforms and PCIe
came up fine on both platforms (with X-Gene ECAM fixup patch that I
will post separately). Thanks for your work and please feel free to
add my Tested-by.

Regards,
Duc Dang.

>
> v2 -> v3
> - fix legacy IRQ assigning and IO ports registration
> - remove reference to arch specific companion device for ia64
> - move ACPI PCI host controller driver to pci_root.c
> - drop generic domain assignment for x86 and ia64 as I am not
>   able to run all necessary test variants
> - drop patch which cleaned legacy IRQ assignment since it belongs to
>   Mathew's series:
>   https://patchwork.ozlabs.org/patch/557504/
> - extend MCFG quirk code
> - rebased to 4.4
>
> v1 -> v2
> - moved non-arch specific piece of code to dirver/acpi/ directory
> - fixed IO resource handling
> - introduced PCI config accessors quirks matching
> - moved ACPI_COMPANION_SET to generic code
>
> Liu Jiang (1):
>   ACPI, PCI: Refine the way to handle translation_offset for ACPI
>     resources
>
> Tomasz Nowicki (20):
>   x86, pci: Reorder logic of pci_mmconfig_insert() function
>   x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code
>     out of arch/x86/ directory
>   pci, acpi, mcfg: Provide generic implementation of MCFG code
>     initialization.
>   x86, pci: mmconfig_{32,64}.c code refactoring - remove code
>     duplication.
>   x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM
>     driver.
>   XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y
>   pci, acpi, mcfg: Provide default RAW ACPI PCI config space accessors.
>   arm64, acpi: Use empty PCI config space accessors from mcfg.c file.
>   pci, acpi, ecam: Add flag to indicate whether ECAM region was hot
>     added or not.
>   x86, pci: Cleanup platform specific MCFG data using previously added
>     ECAM hot_added flag.
>   pci, acpi: Move ACPI host bridge device companion assignment to core
>     code.
>   x86, ia64, pci: Remove ACPI companion device from platform specific
>     data.
>   pci, acpi: Provide generic way to assign bus domain number.
>   x86, ia64: Include acpi_pci_{add|remove}_bus to the default
>     pcibios_{add|remove}_bus implementation.
>   acpi, mcfg: Implement two calls that might be used to inject/remove
>     MCFG region.
>   x86, acpi, pci: Use equivalent function introduced in previous patch.
>   acpi, mcfg: Add default PCI config accessors implementation and
>     initial support for related quirks.
>   pci, acpi: Support for ACPI based generic PCI host controller init
>   pci, acpi: Match PCI config space accessors against platfrom specific
>     quirks.
>   arm64, pci, acpi: Start using ACPI based PCI host bridge driver for
>     ARM64.
>
>  arch/arm64/Kconfig                 |   7 ++
>  arch/arm64/kernel/pci.c            |  25 ----
>  arch/ia64/hp/common/sba_iommu.c    |   2 +-
>  arch/ia64/include/asm/pci.h        |   1 -
>  arch/ia64/pci/pci.c                |  52 +++-----
>  arch/ia64/sn/kernel/io_acpi_init.c |   4 +-
>  arch/x86/Kconfig                   |   4 +
>  arch/x86/include/asm/pci.h         |   3 -
>  arch/x86/include/asm/pci_x86.h     |  28 +----
>  arch/x86/pci/acpi.c                |  41 ++----
>  arch/x86/pci/common.c              |  10 --
>  arch/x86/pci/irq.c                 |  10 --
>  arch/x86/pci/mmconfig-shared.c     | 250 ++++++-------------------------------
>  arch/x86/pci/mmconfig_32.c         |  11 +-
>  arch/x86/pci/mmconfig_64.c         |  67 +---------
>  arch/x86/pci/numachip.c            |   1 +
>  drivers/acpi/Kconfig               |   5 +
>  drivers/acpi/Makefile              |   1 +
>  drivers/acpi/mcfg.c                | 201 +++++++++++++++++++++++++++++
>  drivers/acpi/pci_root.c            | 136 +++++++++++++++++++-
>  drivers/acpi/resource.c            |  12 +-
>  drivers/pci/Kconfig                |  10 ++
>  drivers/pci/Makefile               |   5 +
>  drivers/pci/ecam.c                 | 234 ++++++++++++++++++++++++++++++++++
>  drivers/pci/pci.c                  |  29 ++++-
>  drivers/pci/probe.c                |   5 +
>  drivers/xen/pci.c                  |   7 +-
>  include/acpi/acpi_bus.h            |   1 +
>  include/asm-generic/vmlinux.lds.h  |   7 ++
>  include/linux/acpi.h               |   2 +
>  include/linux/ecam.h               |  62 +++++++++
>  include/linux/pci-acpi.h           |  17 +++
>  32 files changed, 802 insertions(+), 448 deletions(-)
>  create mode 100644 drivers/acpi/mcfg.c
>  create mode 100644 drivers/pci/ecam.c
>  create mode 100644 include/linux/ecam.h
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From drivshin.allworx at gmail.com  Mon Feb  1 12:14:09 2016
From: drivshin.allworx at gmail.com (David Rivshin (Allworx))
Date: Mon, 1 Feb 2016 15:14:09 -0500
Subject: [PATCH 0/4] pwm: omap-dmtimer: fix period/duty_cycle calculation
In-Reply-To: <CAA3gFWsc6YxEvaFW2MJ2D-xBZqEzLOJne9AHZ6zBK3h3THy0CA@mail.gmail.com>
References: <1454128014-22866-1-git-send-email-drivshin.allworx@gmail.com>
 <CAA3gFWsc6YxEvaFW2MJ2D-xBZqEzLOJne9AHZ6zBK3h3THy0CA@mail.gmail.com>
Message-ID: <20160201151409.24a5957e.drivshin.allworx@gmail.com>

On Sat, 30 Jan 2016 15:52:12 +0100
Neil Armstrong <narmstrong at baylibre.com> wrote:

> 2016-01-30 5:26 GMT+01:00 David Rivshin (Allworx)
> <drivshin.allworx at gmail.com>:
> > From: David Rivshin <drivshin at allworx.com>
> >
> > When using a short PWM period (approaching the min of 2/clk_rate),
> > pwm-omap-dmtimer does not produce accurate results. In the worst
> > case a requested period of 2/clk_rate would result in a real period
> > of 4/clk_rate instead. This is a series includes a fix for that
> > problem, as well as other related improvements, and is based on the
> > current linux-pwm/for-next tip.
> >
> > I have tested on a Sitara AM335x platform, using a scope to verify
> > the output with a variety of periods and duty cycles. This includes
> > a PWM rate up clk_rate/2 with 50% duty cycle (e.g. generating
> > fclk/2) with both 32768Hz and 24MHz fclks. I do not have an OMAP4
> > board to test with, although appropriate sections in the the
> > reference manuals appear substantially the same, so I believe the
> > changes are equally correct there.
> >
> > Note that the OMAP4 TRMs do effectively state that the maximum PWM
> > rate is clk_rate/4, so at very fast PWM rates the behavior may not
> > be as reliable as I observed with Sitara. Although I suspect that
> > it's the same module and will also work, at least under some
> > circumstances. If anyone with OMAP4 hardware and a scope is so
> > inclined, I would be curious to know the results.  
> 
> Hi David,
> 
> Thanks for the work, it seems all good, I'll test them on my side the
> next days, but this work needed to be done for sure !

Thanks to you (and everyone else involved) for doing the heavy lifting 
on the driver to begin with. It came just as I had a need for the PWM 
output of a dmtimer, and came to the conclusion that just such a
timer-to-PWM adapter was needed. 

> The only OMAP4 HW I have is a Pandaboard and it's very difficult to
> get the timer outputs...

For what its worth, I took a quick look at the Pandaboard Rev EA1 
schematic, and I can see how it doesn't make using a timer PWM output 
easy. Easiest option I found might be to change the pinmux for AG24 
(h_GPIO_121) to be DMTIMER11_PWM_EVT, and probe it at S2 or J13.



From maxime.ripard at free-electrons.com  Mon Feb  1 12:17:54 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 1 Feb 2016 21:17:54 +0100
Subject: [PATCH v3 2/2] clk: sunxi: Refactor A31 PLL6 so that it can be
 reused
In-Reply-To: <20160130185714.7abcf1de9ef8108c2f48c7fe@free.fr>
References: <1454008958-12655-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454008958-12655-2-git-send-email-maxime.ripard@free-electrons.com>
 <20160130185714.7abcf1de9ef8108c2f48c7fe@free.fr>
Message-ID: <20160201201754.GI4652@lukather>

Hi,

On Sat, Jan 30, 2016 at 06:57:14PM +0100, Jean-Francois Moine wrote:
> On Thu, 28 Jan 2016 20:22:38 +0100
> Maxime Ripard <maxime.ripard at free-electrons.com> wrote:
> 
> > Remove the fixed dividers from the PLL6 driver to be able to have a
> > reusable driver that can be used across several SoCs that share the same
> > controller, but don't have the same set of dividers for this clock, and to
> > also be reused multiple times in the same SoC, since we're droping the
> > clock name.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > ---
> > Changes from v2
> >   - Rebased and converted over to the new factors refactoring. Fixed the
> >     retrieved rate
> > 
> >  arch/arm/boot/dts/sun6i-a31.dtsi     | 36 ++++++++++++++++++------------------
> >  arch/arm/boot/dts/sun8i-a23-a33.dtsi | 25 +++++++++++++++++--------
> >  arch/arm/boot/dts/sun8i-a23.dtsi     |  2 +-
> >  arch/arm/boot/dts/sun8i-a33.dtsi     |  4 ++--
> >  arch/arm/boot/dts/sun8i-h3.dtsi      | 36 ++++++++++++++++++------------------
> >  drivers/clk/sunxi/clk-sunxi.c        | 32 ++++++++++++++++----------------
> >  6 files changed, 72 insertions(+), 63 deletions(-)
> 
> Hi Maxime,
> 
> Do you know that the DT definitions cannot be changed when they are in
> the mainline kernel?

AFAIK, the only ARM platform that ever had such a policy was mvebu,
and they finally gave up on it. So, as far as I'm concerned, the DT
ABI simply doesn't exist.

> Also, for the H3 PLL periph1 (aka PLL8), why didn't you create a
> 'pll8x2' clock with 'pll8' as a divider?

No one seems to use it. We can always add it later in a separate
patch when someone will.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160201/8832850c/attachment.sig>

From maxime.ripard at free-electrons.com  Mon Feb  1 12:20:00 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon,  1 Feb 2016 21:20:00 +0100
Subject: [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused
Message-ID: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>

Remove the fixed dividers from the PLL6 driver to be able to have a
reusable driver that can be used across several SoCs that share the same
controller, but don't have the same set of dividers for this clock, and to
also be reused multiple times in the same SoC, since we're droping the
clock name.

Acked-by: Chen-Yu Tsai <wens at csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---

Changes from v3:
  - Fixed the documentation
  - Added pll6d2 back

Changes from v2:
  - Rebased and converted over to the new factors refactoring. Fixed the
    retrieved rate

 Documentation/devicetree/bindings/clock/sunxi.txt |  2 +-
 arch/arm/boot/dts/sun6i-a31.dtsi                  | 36 +++++++++++-----------
 arch/arm/boot/dts/sun8i-a23-a33.dtsi              | 25 ++++++++++-----
 arch/arm/boot/dts/sun8i-a23.dtsi                  |  2 +-
 arch/arm/boot/dts/sun8i-a33.dtsi                  |  4 +--
 arch/arm/boot/dts/sun8i-h3.dtsi                   | 37 ++++++++++++++---------
 drivers/clk/sunxi/clk-sunxi.c                     | 32 ++++++++++----------
 7 files changed, 78 insertions(+), 60 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index e59f57b24777..f82850c0f6a5 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -86,7 +86,7 @@ Required properties for all clocks:
 - #clock-cells : from common clock binding; shall be set to 0 except for
 	the following compatibles where it shall be set to 1:
 	"allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk",
-	"allwinner,sun4i-pll6-clk", "allwinner,sun6i-a31-pll6-clk",
+	"allwinner,sun4i-pll6-clk",
 	"allwinner,*-usb-clk", "allwinner,*-mmc-clk",
 	"allwinner,*-mmc-config-clk"
 - clock-output-names : shall be the corresponding names of the outputs.
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index b6ad7850fac6..05fe3d1aa328 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -65,7 +65,7 @@
 			compatible = "allwinner,simple-framebuffer",
 				     "simple-framebuffer";
 			allwinner,pipeline = "de_be0-lcd0-hdmi";
-			clocks = <&pll6 0>;
+			clocks = <&pll6>;
 			status = "disabled";
 		};
 
@@ -73,7 +73,7 @@
 			compatible = "allwinner,simple-framebuffer",
 				     "simple-framebuffer";
 			allwinner,pipeline = "de_be0-lcd0";
-			clocks = <&pll6 0>;
+			clocks = <&pll6>;
 			status = "disabled";
 		};
 	};
@@ -201,11 +201,11 @@
 		};
 
 		pll6: clk at 01c20028 {
-			#clock-cells = <1>;
+			#clock-cells = <0>;
 			compatible = "allwinner,sun6i-a31-pll6-clk";
 			reg = <0x01c20028 0x4>;
 			clocks = <&osc24M>;
-			clock-output-names = "pll6", "pll6x2";
+			clock-output-names = "pll6";
 		};
 
 		cpu: cpu at 01c20050 {
@@ -235,7 +235,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun6i-a31-ahb1-clk";
 			reg = <0x01c20054 0x4>;
-			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
+			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
 			clock-output-names = "ahb1";
 
 			/*
@@ -244,7 +244,7 @@
 			 * controller requires AHB1 clocked from PLL6.
 			 */
 			assigned-clocks = <&ahb1>;
-			assigned-clock-parents = <&pll6 0>;
+			assigned-clock-parents = <&pll6>;
 		};
 
 		ahb1_gates: clk at 01c20060 {
@@ -307,7 +307,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-apb1-clk";
 			reg = <0x01c20058 0x4>;
-			clocks = <&osc32k>, <&osc24M>, <&pll6 0>, <&pll6 0>;
+			clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
 			clock-output-names = "apb2";
 		};
 
@@ -331,7 +331,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20088 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
+			clocks = <&osc24M>, <&pll6>;
 			clock-output-names = "mmc0",
 					     "mmc0_output",
 					     "mmc0_sample";
@@ -341,7 +341,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c2008c 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
+			clocks = <&osc24M>, <&pll6>;
 			clock-output-names = "mmc1",
 					     "mmc1_output",
 					     "mmc1_sample";
@@ -351,7 +351,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20090 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
+			clocks = <&osc24M>, <&pll6>;
 			clock-output-names = "mmc2",
 					     "mmc2_output",
 					     "mmc2_sample";
@@ -361,7 +361,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20094 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
+			clocks = <&osc24M>, <&pll6>;
 			clock-output-names = "mmc3",
 					     "mmc3_output",
 					     "mmc3_sample";
@@ -371,7 +371,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-mod0-clk";
 			reg = <0x01c2009c 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
+			clocks = <&osc24M>, <&pll6>;
 			clock-output-names = "ss";
 		};
 
@@ -379,7 +379,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-mod0-clk";
 			reg = <0x01c200a0 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
+			clocks = <&osc24M>, <&pll6>;
 			clock-output-names = "spi0";
 		};
 
@@ -387,7 +387,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-mod0-clk";
 			reg = <0x01c200a4 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
+			clocks = <&osc24M>, <&pll6>;
 			clock-output-names = "spi1";
 		};
 
@@ -395,7 +395,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-mod0-clk";
 			reg = <0x01c200a8 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
+			clocks = <&osc24M>, <&pll6>;
 			clock-output-names = "spi2";
 		};
 
@@ -403,7 +403,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-mod0-clk";
 			reg = <0x01c200ac 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
+			clocks = <&osc24M>, <&pll6>;
 			clock-output-names = "spi3";
 		};
 
@@ -1042,8 +1042,8 @@
 			ar100: ar100_clk {
 				compatible = "allwinner,sun6i-a31-ar100-clk";
 				#clock-cells = <0>;
-				clocks = <&osc32k>, <&osc24M>, <&pll6 0>,
-					 <&pll6 0>;
+				clocks = <&osc32k>, <&osc24M>, <&pll6>,
+					 <&pll6>;
 				clock-output-names = "ar100";
 			};
 
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 6f88fb0ddbc7..edc85eeaf365 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -60,7 +60,7 @@
 			compatible = "allwinner,simple-framebuffer",
 				     "simple-framebuffer";
 			allwinner,pipeline = "de_be0-lcd0";
-			clocks = <&pll6 0>;
+			clocks = <&pll6>;
 			status = "disabled";
 		};
 	};
@@ -129,11 +129,20 @@
 		};
 
 		pll6: clk at 01c20028 {
-			#clock-cells = <1>;
+			#clock-cells = <0>;
 			compatible = "allwinner,sun6i-a31-pll6-clk";
 			reg = <0x01c20028 0x4>;
 			clocks = <&osc24M>;
-			clock-output-names = "pll6", "pll6x2";
+			clock-output-names = "pll6";
+		};
+
+                pll6x2: pll6x2_clk {
+			compatible = "fixed-factor-clock";
+			#clock-cells = <0>;
+			clock-div = <1>;
+			clock-mult = <2>;
+			clocks = <&pll6>;
+			clock-output-names = "pll6-2x";
 		};
 
 		cpu: cpu_clk at 01c20050 {
@@ -163,7 +172,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun6i-a31-ahb1-clk";
 			reg = <0x01c20054 0x4>;
-			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
+			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
 			clock-output-names = "ahb1";
 		};
 
@@ -190,7 +199,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-apb1-clk";
 			reg = <0x01c20058 0x4>;
-			clocks = <&osc32k>, <&osc24M>, <&pll6 0>, <&pll6 0>;
+			clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
 			clock-output-names = "apb2";
 		};
 
@@ -213,7 +222,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20088 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
+			clocks = <&osc24M>, <&pll6>;
 			clock-output-names = "mmc0",
 					     "mmc0_output",
 					     "mmc0_sample";
@@ -223,7 +232,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c2008c 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
+			clocks = <&osc24M>, <&pll6>;
 			clock-output-names = "mmc1",
 					     "mmc1_output",
 					     "mmc1_sample";
@@ -233,7 +242,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20090 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
+			clocks = <&osc24M>, <&pll6>;
 			clock-output-names = "mmc2",
 					     "mmc2_output",
 					     "mmc2_sample";
diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/sun8i-a23.dtsi
index 92e6616979ea..5e589c1ddda9 100644
--- a/arch/arm/boot/dts/sun8i-a23.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23.dtsi
@@ -79,7 +79,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun8i-a23-mbus-clk";
 			reg = <0x01c2015c 0x4>;
-			clocks = <&osc24M>, <&pll6 1>, <&pll5>;
+			clocks = <&osc24M>, <&pll6x2>, <&pll5>;
 			clock-output-names = "mbus";
 		};
 	};
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 001d8402ca18..f3eb618bcfa7 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -103,7 +103,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-mod0-clk";
 			reg = <0x01c2009c 0x4>;
-			clocks = <&osc24M>, <&pll6 0>;
+			clocks = <&osc24M>, <&pll6>;
 			clock-output-names = "ss";
 		};
 
@@ -111,7 +111,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun8i-a23-mbus-clk";
 			reg = <0x01c2015c 0x4>;
-			clocks = <&osc24M>, <&pll6 1>, <&pll5>, <&pll11>;
+			clocks = <&osc24M>, <&pll6x2>, <&pll5>, <&pll11>;
 			clock-output-names = "mbus";
 		};
 	};
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 1524130e43c9..6f6b4e469ac9 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -121,11 +121,11 @@
 		};
 
 		pll6: clk at 01c20028 {
-			#clock-cells = <1>;
+			#clock-cells = <0>;
 			compatible = "allwinner,sun6i-a31-pll6-clk";
 			reg = <0x01c20028 0x4>;
 			clocks = <&osc24M>;
-			clock-output-names = "pll6", "pll6x2";
+			clock-output-names = "pll6";
 		};
 
 		pll6d2: pll6d2_clk {
@@ -133,15 +133,24 @@
 			compatible = "fixed-factor-clock";
 			clock-div = <2>;
 			clock-mult = <1>;
-			clocks = <&pll6 0>;
-			clock-output-names = "pll6d2";
+			clocks = <&pll6>;
+			clock-output-names = "pll6-d2";
 		};
 
-		/* dummy clock until pll6 can be reused */
-		pll8: pll8_clk {
+		pll6x2: pll6x2_clk {
 			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <1>;
+			compatible = "fixed-factor-clock";
+			clock-div = <1>;
+			clock-mult = <2>;
+			clocks = <&pll6>;
+			clock-output-names = "pll6-2x";
+		};
+
+		pll8: clk at 01c20044 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun6i-a31-pll6-clk";
+			reg = <0x01c20044 0x4>;
+			clocks = <&osc24M>;
 			clock-output-names = "pll8";
 		};
 
@@ -165,7 +174,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun6i-a31-ahb1-clk";
 			reg = <0x01c20054 0x4>;
-			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
+			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
 			clock-output-names = "ahb1";
 		};
 
@@ -189,7 +198,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-apb1-clk";
 			reg = <0x01c20058 0x4>;
-			clocks = <&osc32k>, <&osc24M>, <&pll6 0>, <&pll6 0>;
+			clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
 			clock-output-names = "apb2";
 		};
 
@@ -243,7 +252,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20088 0x4>;
-			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
+			clocks = <&osc24M>, <&pll6>, <&pll8>;
 			clock-output-names = "mmc0",
 					     "mmc0_output",
 					     "mmc0_sample";
@@ -253,7 +262,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c2008c 0x4>;
-			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
+			clocks = <&osc24M>, <&pll6>, <&pll8>;
 			clock-output-names = "mmc1",
 					     "mmc1_output",
 					     "mmc1_sample";
@@ -263,7 +272,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20090 0x4>;
-			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
+			clocks = <&osc24M>, <&pll6>, <&pll8>;
 			clock-output-names = "mmc2",
 					     "mmc2_output",
 					     "mmc2_sample";
@@ -273,7 +282,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun8i-a23-mbus-clk";
 			reg = <0x01c2015c 0x4>;
-			clocks = <&osc24M>, <&pll6 1>, <&pll5>;
+			clocks = <&osc24M>, <&pll6x2>, <&pll5>;
 			clock-output-names = "mbus";
 		};
 	};
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index da15f2b12ab2..4de800e379d3 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -227,9 +227,9 @@ static void sun4i_get_pll5_factors(struct factors_request *req)
 }
 
 /**
- * sun6i_a31_get_pll6_factors() - calculates n, k factors for A31 PLL6x2
- * PLL6x2 rate is calculated as follows
- * rate = parent_rate * (n + 1) * (k + 1)
+ * sun6i_a31_get_pll6_factors() - calculates n, k factors for A31 PLL6
+ * PLL6 rate is calculated as follows
+ * rate = parent_rate * (n + 1) * (k + 1) / 2
  * parent_rate is always 24Mhz
  */
 
@@ -238,8 +238,8 @@ static void sun6i_a31_get_pll6_factors(struct factors_request *req)
 	u8 div;
 
 	/* Normalize value to a parent_rate multiple (24M) */
-	div = req->rate / req->parent_rate;
-	req->rate = req->parent_rate * div;
+	div = req->rate / (req->parent_rate / 2);
+	req->rate = (req->parent_rate / 2) * div;
 
 	req->k = div / 32;
 	if (req->k > 3)
@@ -248,6 +248,15 @@ static void sun6i_a31_get_pll6_factors(struct factors_request *req)
 	req->n = DIV_ROUND_UP(div, (req->k + 1)) - 1;
 }
 
+static void sun6i_a31_pll6_recalc(struct factors_request *req)
+{
+	req->rate = req->parent_rate;
+
+	req->rate *= req->n + 1;
+	req->rate *= req->k + 1;
+	req->rate /= 2;
+}
+
 /**
  * sun5i_a13_get_ahb_factors() - calculates m, p factors for AHB
  * AHB rate is calculated as follows
@@ -537,7 +546,7 @@ static const struct factors_data sun6i_a31_pll6_data __initconst = {
 	.enable = 31,
 	.table = &sun6i_a31_pll6_config,
 	.getter = sun6i_a31_get_pll6_factors,
-	.name = "pll6x2",
+	.recalc = sun6i_a31_pll6_recalc,
 };
 
 static const struct factors_data sun5i_a13_ahb_data __initconst = {
@@ -788,15 +797,6 @@ static const struct divs_data pll6_divs_data __initconst = {
 	}
 };
 
-static const struct divs_data sun6i_a31_pll6_divs_data __initconst = {
-	.factors = &sun6i_a31_pll6_data,
-	.ndivs = 2,
-	.div = {
-		{ .fixed = 2 }, /* normal output */
-		{ .self = 1 }, /* base factor clock, 2x */
-	}
-};
-
 /**
  * sunxi_divs_clk_setup() - Setup function for leaf divisors on clocks
  *
@@ -938,6 +938,7 @@ free_clkdata:
 static const struct of_device_id clk_factors_match[] __initconst = {
 	{.compatible = "allwinner,sun4i-a10-pll1-clk", .data = &sun4i_pll1_data,},
 	{.compatible = "allwinner,sun6i-a31-pll1-clk", .data = &sun6i_a31_pll1_data,},
+	{.compatible = "allwinner,sun6i-a31-pll6-clk", .data = &sun6i_a31_pll6_data,},
 	{.compatible = "allwinner,sun8i-a23-pll1-clk", .data = &sun8i_a23_pll1_data,},
 	{.compatible = "allwinner,sun7i-a20-pll4-clk", .data = &sun7i_a20_pll4_data,},
 	{.compatible = "allwinner,sun5i-a13-ahb-clk", .data = &sun5i_a13_ahb_data,},
@@ -959,7 +960,6 @@ static const struct of_device_id clk_div_match[] __initconst = {
 static const struct of_device_id clk_divs_match[] __initconst = {
 	{.compatible = "allwinner,sun4i-a10-pll5-clk", .data = &pll5_divs_data,},
 	{.compatible = "allwinner,sun4i-a10-pll6-clk", .data = &pll6_divs_data,},
-	{.compatible = "allwinner,sun6i-a31-pll6-clk", .data = &sun6i_a31_pll6_divs_data,},
 	{}
 };
 
-- 
2.6.4



From nicolas.pitre at linaro.org  Mon Feb  1 12:23:34 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 1 Feb 2016 15:23:34 -0500 (EST)
Subject: [PATCH v4] ARM: xip: Use correct symbol for end of ROM marker
In-Reply-To: <SG2PR06MB0572F0EE79C00A530FA9CF398ADE0@SG2PR06MB0572.apcprd06.prod.outlook.com>
References: <1447697140-4099-1-git-send-email-chris.brandt@renesas.com>
 <1454349165-12249-1-git-send-email-chris.brandt@renesas.com>
 <alpine.LFD.2.20.1602011404420.32766@knanqh.ubzr> 
 <SG2PR06MB0572F0EE79C00A530FA9CF398ADE0@SG2PR06MB0572.apcprd06.prod.outlook.com>
Message-ID: <alpine.LFD.2.20.1602011522070.32766@knanqh.ubzr>

On Mon, 1 Feb 2016, Chris Brandt wrote:

> On Mon, 1 Feb 2016, Nicolas Pitre wrote:
> 
> > The __data_loc symbol doesn't convey much to say with regards to XIP
> > mapping.  It would be better to dedicate another symbol with a proper
> > name instead.  Something like xiprom_start and xiprom_end perhaps.  
> > This way, someone looking at the linker script won't be fooled by a
> > hidden meaning tied to _etext or __data_loc.
> 
> That's fine by me.
> 
> 
> However, I just saw the email "[PATCH] ARM: vmlinux.lds: assert that 
> ROM and RAM don't overlap when XIP_KERNEL=y" sent in a little while 
> ago.
> 
> So, do we first want to reconsider splitting out the XIP stuff into a 
> separate linker script? Hence my proposal form November "[PATCH v2] 
> ARM: xip: Move XIP linking to a separate file".
> 
> Or, should we keep piling more stuff in vmlinux.lds.S?

I still think the split linker file is the way to go.


Nicolas


From maxime.ripard at free-electrons.com  Mon Feb  1 12:24:58 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 1 Feb 2016 21:24:58 +0100
Subject: [PATCH RFC 11/11] clk: sunxi: rewrite sun8i-a23-mbus-clk using
 the simpler composite clk
In-Reply-To: <CAGb2v658SFy6SF87=obYLW1YAxvk0T4dRuBU-F1oLT3Yq=PgTQ@mail.gmail.com>
References: <1453727747-23307-1-git-send-email-wens@csie.org>
 <1453727747-23307-12-git-send-email-wens@csie.org>
 <20160127174932.GP4317@lukather>
 <CAGb2v658SFy6SF87=obYLW1YAxvk0T4dRuBU-F1oLT3Yq=PgTQ@mail.gmail.com>
Message-ID: <20160201202458.GJ4652@lukather>

Hi,

On Thu, Jan 28, 2016 at 10:41:33AM +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> On Thu, Jan 28, 2016 at 1:49 AM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > On Mon, Jan 25, 2016 at 09:15:47PM +0800, Chen-Yu Tsai wrote:
> >> sun8i-a23-mbus-clk used sunxi's factors clk, which is nice for very
> >> complicated clocks, but is not really needed here.
> >>
> >> Convert sun8i-a23-mbus-clk to use clk_composite, as it is a gate + mux
> >> + divider. This makes the code easier to understand.
> >>
> >> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
> >
> > Applied, thanks!
> > Maxime
> 
> Given your suggestion for extending and generalizing factors clk
> clock rate calculations, maybe we just leave this one out and use
> the new stuff later?

My suggestion was only about the core of the clk-factors, the
"external" API would not change, so I'm guessing it's still relevant.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160201/78d4db1a/attachment.sig>

From fu.wei at linaro.org  Mon Feb  1 12:26:52 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Tue,  2 Feb 2016 04:26:52 +0800
Subject: [PATCH v3 0/6] acpi, clocksource,
 kvm: add GTDT and ARM memory-mapped timer support
Message-ID: <1454358418-5157-1-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This patchset:
    (1)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c
    Parse all kinds of timer in GTDT table of ACPI:arch timer,
    memory-mapped timer and SBSA Generic Watchdog timer.
    This driver can help to simplify all the relevant timer drivers,
    and separate all the ACPI GTDT knowledge from them.

    (2)Simplify ACPI code for arch timer in arm_arch_timer.c

    (3)Add memory-mapped timer support in arm_arch_timer.c

    (4)Add arm_arch_timer get ppi from DT and GTDT support for kvm
    in virt/kvm/arm/arch_timer.c

Changelog:
v3: Improve GTDT driver code:
      (1)improve pr_* by defining pr_fmt(fmt)
      (2)simplify gtdt_sbsa_gwdt_init
      (3)improve gtdt_arch_timer_data_init, if table is NULL, it will try
      to get GTDT table.
    Move enum ppi_nr to arm_arch_timer.h, and add enum spi_nr.
    Add arm_arch_timer get ppi from DT and GTDT support for kvm.

v2: https://lkml.org/lkml/2015/12/2/10
    Rebase to latest kernel version(4.4-rc3).
    Fix the bug about the config problem,
    use CONFIG_ACPI_GTDT instead of CONFIG_ACPI in arm_arch_timer.c

v1: The first upstreaming version: https://lkml.org/lkml/2015/10/28/553

Fu Wei (5):
  ACPI: add GTDT table parse driver into ACPI driver
  clocksource: simplify ACPI code in arm_arch_timer.c
  clocksource: add memory-mapped timer support in arm_arch_timer.c
  clocksource: move some enums to arm_arch_timer.h
  kvm: arm64: Add ACPI support for virt arch timer

Wei Huang (1):
  kvm: arm64: wrapping DT support for virt arch timer

 drivers/acpi/Kconfig                 |   9 +
 drivers/acpi/Makefile                |   1 +
 drivers/acpi/gtdt.c                  | 375 +++++++++++++++++++++++++++++++++++
 drivers/clocksource/Kconfig          |   1 +
 drivers/clocksource/arm_arch_timer.c | 191 +++++++++++++-----
 include/clocksource/arm_arch_timer.h |  33 +++
 include/linux/acpi.h                 |  17 ++
 virt/kvm/arm/arch_timer.c            |  57 ++++--
 8 files changed, 620 insertions(+), 64 deletions(-)
 create mode 100644 drivers/acpi/gtdt.c

-- 
2.5.0



From fu.wei at linaro.org  Mon Feb  1 12:26:53 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Tue,  2 Feb 2016 04:26:53 +0800
Subject: [PATCH v3 1/6] ACPI: add GTDT table parse driver into ACPI driver
In-Reply-To: <1454358418-5157-1-git-send-email-fu.wei@linaro.org>
References: <1454358418-5157-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1454358418-5157-2-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This driver adds support for parsing all kinds of timer in GTDT:
(1)arch timer: provide a kernel API to parse all the PPIs and
always-on info in GTDT and export them by arch_timer_data struct.

(2)memory-mapped timer: provide several kernel APIs to parse
GT Block Structure in GTDT, export those info by return value
and arch_timer_mem_data struct.

(3)SBSA Generic Watchdog: parse all info in SBSA Generic Watchdog
Structure in GTDT, and creating a platform device with that
information. This allows the operating system to obtain device
data from the resource of platform device.
The platform device named "sbsa-gwdt" can be used by the ARM SBSA
Generic Watchdog driver.

By this driver, we can simplify all the relevant drivers, and
separate all the ACPI GTDT knowledge from them.

Signed-off-by: Fu Wei <fu.wei at linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
---
 drivers/acpi/Kconfig                 |   9 +
 drivers/acpi/Makefile                |   1 +
 drivers/acpi/gtdt.c                  | 375 +++++++++++++++++++++++++++++++++++
 drivers/clocksource/arm_arch_timer.c |   2 -
 include/clocksource/arm_arch_timer.h |  19 ++
 include/linux/acpi.h                 |  17 ++
 6 files changed, 421 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 5eef4cb..e2bfad1 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -510,4 +510,13 @@ config XPOWER_PMIC_OPREGION
 
 endif
 
+config ACPI_GTDT
+	bool "ACPI GTDT Support"
+	depends on ARM64
+	help
+	  GTDT (Generic Timer Description Table) provides information
+	  for per-processor timers and Platform (memory-mapped) timers
+	  for ARM platforms. Select this option to provide information
+	  needed for the timers init.
+
 endif	# ACPI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 675eaf3..ac42e31 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -96,5 +96,6 @@ obj-$(CONFIG_ACPI_EXTLOG)	+= acpi_extlog.o
 obj-$(CONFIG_PMIC_OPREGION)	+= pmic/intel_pmic.o
 obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
 obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
+obj-$(CONFIG_ACPI_GTDT)		+= gtdt.o
 
 video-objs			+= acpi_video.o video_detect.o
diff --git a/drivers/acpi/gtdt.c b/drivers/acpi/gtdt.c
new file mode 100644
index 0000000..047fea1
--- /dev/null
+++ b/drivers/acpi/gtdt.c
@@ -0,0 +1,375 @@
+/*
+ * ARM Specific GTDT table Support
+ *
+ * Copyright (C) 2015, Linaro Ltd.
+ * Author: Fu Wei <fu.wei at linaro.org>
+ *         Hanjun Guo <hanjun.guo at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/acpi.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#include <clocksource/arm_arch_timer.h>
+
+#undef pr_fmt
+#define pr_fmt(fmt) "GTDT: " fmt
+
+static u32 platform_timer_count __initdata;
+static int gtdt_timers_existence __initdata;
+
+/*
+ * Get some basic info from GTDT table, and init the global variables above
+ * for all timers initialization of Generic Timer.
+ * This function does some validation on GTDT table, and will be run only once.
+ */
+static void __init *platform_timer_info_init(struct acpi_table_header *table)
+{
+	void *gtdt_end, *platform_timer_struct, *platform_timer;
+	struct acpi_gtdt_header *header;
+	struct acpi_table_gtdt *gtdt;
+	u32 i;
+
+	gtdt = container_of(table, struct acpi_table_gtdt, header);
+	if (!gtdt) {
+		pr_err("table pointer error.\n");
+		return NULL;
+	}
+	gtdt_end = (void *)table + table->length;
+	gtdt_timers_existence |= ARCH_CP15_TIMER;
+
+	if (table->revision < 2) {
+		pr_info("Revision:%d doesn't support Platform Timers.\n",
+			table->revision);
+		return NULL;
+	}
+
+	platform_timer_count = gtdt->platform_timer_count;
+	if (!platform_timer_count) {
+		pr_info("No Platform Timer structures.\n");
+		return NULL;
+	}
+
+	platform_timer_struct = (void *)gtdt + gtdt->platform_timer_offset;
+	if (platform_timer_struct < (void *)table +
+				    sizeof(struct acpi_table_gtdt)) {
+		pr_err(FW_BUG "Platform Timer pointer error.\n");
+		return NULL;
+	}
+
+	platform_timer = platform_timer_struct;
+	for (i = 0; i < platform_timer_count; i++) {
+		if (platform_timer > gtdt_end) {
+			pr_err(FW_BUG "subtable pointer overflows.\n");
+			platform_timer_count = i;
+			break;
+		}
+		header = (struct acpi_gtdt_header *)platform_timer;
+		if (header->type == ACPI_GTDT_TYPE_TIMER_BLOCK)
+			gtdt_timers_existence |= ARCH_MEM_TIMER;
+		else if (header->type == ACPI_GTDT_TYPE_WATCHDOG)
+			gtdt_timers_existence |= ARCH_WD_TIMER;
+		platform_timer += header->length;
+	}
+
+	return platform_timer_struct;
+}
+
+static int __init map_generic_timer_interrupt(u32 interrupt, u32 flags)
+{
+	int trigger, polarity;
+
+	if (!interrupt)
+		return 0;
+
+	trigger = (flags & ACPI_GTDT_INTERRUPT_MODE) ? ACPI_EDGE_SENSITIVE
+			: ACPI_LEVEL_SENSITIVE;
+
+	polarity = (flags & ACPI_GTDT_INTERRUPT_POLARITY) ? ACPI_ACTIVE_LOW
+			: ACPI_ACTIVE_HIGH;
+
+	return acpi_register_gsi(NULL, interrupt, trigger, polarity);
+}
+
+/*
+ * Get the necessary info of arch_timer from GTDT table.
+ */
+int __init gtdt_arch_timer_data_init(struct acpi_table_header *table,
+				     struct arch_timer_data *data)
+{
+	struct acpi_table_gtdt *gtdt;
+
+	if (acpi_disabled || !data)
+		return -EINVAL;
+
+	if (!table) {
+		if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_GTDT, 0, &table)))
+			return -EINVAL;
+	}
+
+	if (!gtdt_timers_existence)
+		platform_timer_info_init(table);
+
+	gtdt = container_of(table, struct acpi_table_gtdt, header);
+
+	data->phys_secure_ppi =
+		map_generic_timer_interrupt(gtdt->secure_el1_interrupt,
+					    gtdt->secure_el1_flags);
+
+	data->phys_nonsecure_ppi =
+		map_generic_timer_interrupt(gtdt->non_secure_el1_interrupt,
+					    gtdt->non_secure_el1_flags);
+
+	data->virt_ppi =
+		map_generic_timer_interrupt(gtdt->virtual_timer_interrupt,
+					    gtdt->virtual_timer_flags);
+
+	data->hyp_ppi =
+		map_generic_timer_interrupt(gtdt->non_secure_el2_interrupt,
+					    gtdt->non_secure_el2_flags);
+
+	data->c3stop = !(gtdt->non_secure_el1_flags & ACPI_GTDT_ALWAYS_ON);
+
+	return 0;
+}
+
+bool __init gtdt_timer_is_available(int type)
+{
+	return gtdt_timers_existence | type;
+}
+
+/*
+ * Helper function for getting the pointer of platform_timer_struct.
+ */
+static void __init *get_platform_timer_struct(struct acpi_table_header *table)
+{
+	struct acpi_table_gtdt *gtdt;
+
+	if (!table) {
+		pr_err("table pointer error.\n");
+		return NULL;
+	}
+
+	gtdt = container_of(table, struct acpi_table_gtdt, header);
+
+	return (void *)gtdt + gtdt->platform_timer_offset;
+}
+
+ /*
+ * Get the pointer of GT Block Structure in GTDT table
+ */
+void __init *gtdt_gt_block(struct acpi_table_header *table, int index)
+{
+	struct acpi_gtdt_header *header;
+	void *platform_timer;
+	int i, j;
+
+	if (!gtdt_timers_existence)
+		platform_timer = platform_timer_info_init(table);
+	else
+		platform_timer = get_platform_timer_struct(table);
+
+	if (!gtdt_timer_is_available(ARCH_MEM_TIMER))
+		return NULL;
+
+	for (i = 0, j = 0; i < platform_timer_count; i++) {
+		header = (struct acpi_gtdt_header *)platform_timer;
+		if (header->type == ACPI_GTDT_TYPE_TIMER_BLOCK && j++ == index)
+			return platform_timer;
+		platform_timer += header->length;
+	}
+
+	return NULL;
+}
+
+/*
+ * Get the timer_count(the number of timer frame) of a GT Block in GTDT table
+ */
+u32 __init gtdt_gt_timer_count(struct acpi_gtdt_timer_block *gt_block)
+{
+	if (!gt_block) {
+		pr_err("invalid GT Block baseaddr.\n");
+		return 0;
+	}
+
+	return gt_block->timer_count;
+}
+
+/*
+ * Get the physical address of GT Block in GTDT table
+ */
+void __init *gtdt_gt_cntctlbase(struct acpi_gtdt_timer_block *gt_block)
+{
+	if (!gt_block) {
+		pr_err("invalid GT Block baseaddr.\n");
+		return NULL;
+	}
+
+	return (void *)gt_block->block_address;
+}
+
+/*
+ * Helper function for getting the pointer of a timer frame in GT block.
+ */
+static void __init *gtdt_gt_timer_frame(struct acpi_gtdt_timer_block *gt_block,
+					int index)
+{
+	void *timer_frame;
+
+	if (!(gt_block && gt_block->timer_count))
+		return NULL;
+
+	timer_frame = (void *)gt_block + gt_block->timer_offset +
+		      sizeof(struct acpi_gtdt_timer_entry) * index;
+
+	if (timer_frame <= (void *)gt_block + gt_block->header.length -
+			   sizeof(struct acpi_gtdt_timer_entry))
+		return timer_frame;
+
+	pr_err(FW_BUG "invalid GT Block timer frame entry addr.\n");
+
+	return NULL;
+}
+
+/*
+ * Get the GT timer Frame Number(ID) in a GT Block Timer Structure.
+ * The maximum Frame Number(ID) is (ARCH_TIMER_MEM_MAX_FRAME - 1),
+ * so returning ARCH_TIMER_MEM_MAX_FRAME means error.
+ */
+u32 __init gtdt_gt_frame_number(struct acpi_gtdt_timer_block *gt_block,
+				int index)
+{
+	struct acpi_gtdt_timer_entry *frame;
+
+	frame = (struct acpi_gtdt_timer_entry *)gtdt_gt_timer_frame(gt_block,
+								    index);
+	if (frame)
+		return frame->frame_number;
+
+	return ARCH_TIMER_MEM_MAX_FRAME;
+}
+
+/*
+ * Get the GT timer Frame data in a GT Block Timer Structure
+ */
+int __init gtdt_gt_timer_data(struct acpi_gtdt_timer_block *gt_block,
+			      int index, bool virt,
+			      struct arch_timer_mem_data *data)
+{
+	struct acpi_gtdt_timer_entry *frame;
+
+	frame = (struct acpi_gtdt_timer_entry *)gtdt_gt_timer_frame(gt_block,
+								    index);
+	if (!frame)
+		return -EINVAL;
+
+	data->cntbase_phy = (phys_addr_t)frame->base_address;
+	if (virt)
+		data->irq = map_generic_timer_interrupt(
+				frame->virtual_timer_interrupt,
+				frame->virtual_timer_flags);
+	else
+		data->irq = map_generic_timer_interrupt(frame->timer_interrupt,
+							frame->timer_flags);
+
+	return 0;
+}
+
+/*
+ * Initialize a SBSA generic Watchdog platform device info from GTDT
+ */
+static int __init gtdt_import_sbsa_gwdt(struct acpi_gtdt_watchdog *wd,
+					int index)
+{
+	struct platform_device *pdev;
+	int irq = map_generic_timer_interrupt(wd->timer_interrupt,
+					      wd->timer_flags);
+
+	/*
+	 * According to SBSA specification the size of refresh and control
+	 * frames of SBSA Generic Watchdog is SZ_4K(Offset 0x000 ? 0xFFF).
+	 */
+	struct resource res[] = {
+		DEFINE_RES_IRQ(irq),
+		DEFINE_RES_MEM(wd->control_frame_address, SZ_4K),
+		DEFINE_RES_MEM(wd->refresh_frame_address, SZ_4K),
+	};
+
+	pr_debug("a Watchdog GT(0x%llx/0x%llx gsi:%u flags:0x%x).\n",
+		 wd->refresh_frame_address, wd->control_frame_address,
+		 wd->timer_interrupt, wd->timer_flags);
+
+	if (!(wd->refresh_frame_address &&
+	      wd->control_frame_address &&
+	      wd->timer_interrupt)) {
+		pr_err(FW_BUG "failed geting the device info.\n");
+		return -EINVAL;
+	}
+
+	if (irq < 0) {
+		pr_err("failed to register GSI of the Watchdog GT.\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * Add a platform device named "sbsa-gwdt" to match the platform driver.
+	 * "sbsa-gwdt": SBSA(Server Base System Architecture) Generic Watchdog
+	 * The platform driver (like drivers/watchdog/sbsa_gwdt.c)can get device
+	 * info below by matching this name.
+	 */
+	pdev = platform_device_register_simple("sbsa-gwdt", index, res,
+					       ARRAY_SIZE(res));
+	if (IS_ERR(pdev)) {
+		acpi_unregister_gsi(wd->timer_interrupt);
+		return PTR_ERR(pdev);
+	}
+
+	return 0;
+}
+
+static int __init gtdt_sbsa_gwdt_init(void)
+{
+	struct acpi_table_header *table;
+	struct acpi_gtdt_header *header;
+	void *platform_timer;
+	int i, gwdt_index;
+	int ret = 0;
+
+	if (acpi_disabled)
+		return 0;
+
+	if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_GTDT, 0, &table)))
+		return -EINVAL;
+
+	/*
+	 * At this proint, we have got and validate some info about platform
+	 * timer in platform_timer_info_init.
+	 */
+	if (!gtdt_timer_is_available(ARCH_WD_TIMER))
+		return -EINVAL;
+
+	platform_timer = get_platform_timer_struct(table);
+
+	for (i = 0, gwdt_index = 0; i < platform_timer_count; i++) {
+		header = (struct acpi_gtdt_header *)platform_timer;
+		if (header->type == ACPI_GTDT_TYPE_WATCHDOG) {
+			ret = gtdt_import_sbsa_gwdt(platform_timer, gwdt_index);
+			if (ret)
+				pr_err("failed to import subtable %d.\n", i);
+			else
+				gwdt_index++;
+		}
+		platform_timer += header->length;
+	}
+
+	return ret;
+}
+
+device_initcall(gtdt_sbsa_gwdt_init);
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index c64d543..e16fdad 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -40,8 +40,6 @@
 #define CNTV_TVAL	0x38
 #define CNTV_CTL	0x3c
 
-#define ARCH_CP15_TIMER	BIT(0)
-#define ARCH_MEM_TIMER	BIT(1)
 static unsigned arch_timers_present __initdata;
 
 static void __iomem *arch_counter_base;
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index 9916d0e..7a6d6dc 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -19,6 +19,10 @@
 #include <linux/timecounter.h>
 #include <linux/types.h>
 
+#define ARCH_CP15_TIMER	BIT(0)
+#define ARCH_MEM_TIMER	BIT(1)
+#define ARCH_WD_TIMER	BIT(2)
+
 #define ARCH_TIMER_CTRL_ENABLE		(1 << 0)
 #define ARCH_TIMER_CTRL_IT_MASK		(1 << 1)
 #define ARCH_TIMER_CTRL_IT_STAT		(1 << 2)
@@ -33,6 +37,8 @@ enum arch_timer_reg {
 #define ARCH_TIMER_MEM_PHYS_ACCESS	2
 #define ARCH_TIMER_MEM_VIRT_ACCESS	3
 
+#define ARCH_TIMER_MEM_MAX_FRAME	8
+
 #define ARCH_TIMER_USR_PCT_ACCESS_EN	(1 << 0) /* physical counter */
 #define ARCH_TIMER_USR_VCT_ACCESS_EN	(1 << 1) /* virtual counter */
 #define ARCH_TIMER_VIRT_EVT_EN		(1 << 2)
@@ -43,6 +49,19 @@ enum arch_timer_reg {
 
 #define ARCH_TIMER_EVT_STREAM_FREQ	10000	/* 100us */
 
+struct arch_timer_data {
+	int phys_secure_ppi;
+	int phys_nonsecure_ppi;
+	int virt_ppi;
+	int hyp_ppi;
+	bool c3stop;
+};
+
+struct arch_timer_mem_data {
+	phys_addr_t cntbase_phy;
+	int irq;
+};
+
 #ifdef CONFIG_ARM_ARCH_TIMER
 
 extern u32 arch_timer_get_rate(void);
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 1991aea..2cec0c9 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -468,6 +468,23 @@ void acpi_walk_dep_device_list(acpi_handle handle);
 struct platform_device *acpi_create_platform_device(struct acpi_device *);
 #define ACPI_PTR(_ptr)	(_ptr)
 
+#ifdef CONFIG_ACPI_GTDT
+bool __init gtdt_timer_is_available(int type);
+
+struct arch_timer_data;
+int __init gtdt_arch_timer_data_init(struct acpi_table_header *table,
+				     struct arch_timer_data *data);
+struct arch_timer_mem_data;
+void __init *gtdt_gt_block(struct acpi_table_header *table, int index);
+u32 __init gtdt_gt_timer_count(struct acpi_gtdt_timer_block *gt_block);
+void __init *gtdt_gt_cntctlbase(struct acpi_gtdt_timer_block *gt_block);
+u32 __init gtdt_gt_frame_number(struct acpi_gtdt_timer_block *gt_block,
+				int index);
+int __init gtdt_gt_timer_data(struct acpi_gtdt_timer_block *gt_block,
+			      int index, bool virt,
+			      struct arch_timer_mem_data *data);
+#endif
+
 #else	/* !CONFIG_ACPI */
 
 #define acpi_disabled 1
-- 
2.5.0



From fu.wei at linaro.org  Mon Feb  1 12:26:54 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Tue,  2 Feb 2016 04:26:54 +0800
Subject: [PATCH v3 2/6] clocksource: simplify ACPI code in arm_arch_timer.c
In-Reply-To: <1454358418-5157-1-git-send-email-fu.wei@linaro.org>
References: <1454358418-5157-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1454358418-5157-3-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

The patch update arm_arch_timer driver to use the function
provided by the new GTDT driver of ACPI.
By this way, arm_arch_timer.c can be simplified, and separate
all the ACPI GTDT knowledge from this timer driver.

Signed-off-by: Fu Wei <fu.wei at linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
---
 drivers/clocksource/Kconfig          |  1 +
 drivers/clocksource/arm_arch_timer.c | 48 ++++++++----------------------------
 2 files changed, 11 insertions(+), 38 deletions(-)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 2eb5f0e..445c7cb 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -8,6 +8,7 @@ config CLKSRC_OF
 config CLKSRC_ACPI
 	bool
 	select CLKSRC_PROBE
+	select ACPI_GTDT
 
 config CLKSRC_PROBE
 	bool
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index e16fdad..87d6bae 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -806,60 +806,32 @@ static void __init arch_timer_mem_init(struct device_node *np)
 CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
 		       arch_timer_mem_init);
 
-#ifdef CONFIG_ACPI
-static int __init map_generic_timer_interrupt(u32 interrupt, u32 flags)
-{
-	int trigger, polarity;
-
-	if (!interrupt)
-		return 0;
-
-	trigger = (flags & ACPI_GTDT_INTERRUPT_MODE) ? ACPI_EDGE_SENSITIVE
-			: ACPI_LEVEL_SENSITIVE;
-
-	polarity = (flags & ACPI_GTDT_INTERRUPT_POLARITY) ? ACPI_ACTIVE_LOW
-			: ACPI_ACTIVE_HIGH;
-
-	return acpi_register_gsi(NULL, interrupt, trigger, polarity);
-}
-
+#ifdef CONFIG_ACPI_GTDT
 /* Initialize per-processor generic timer */
 static int __init arch_timer_acpi_init(struct acpi_table_header *table)
 {
-	struct acpi_table_gtdt *gtdt;
+	struct arch_timer_data data;
 
 	if (arch_timers_present & ARCH_CP15_TIMER) {
 		pr_warn("arch_timer: already initialized, skipping\n");
 		return -EINVAL;
 	}
 
-	gtdt = container_of(table, struct acpi_table_gtdt, header);
-
 	arch_timers_present |= ARCH_CP15_TIMER;
 
-	arch_timer_ppi[PHYS_SECURE_PPI] =
-		map_generic_timer_interrupt(gtdt->secure_el1_interrupt,
-		gtdt->secure_el1_flags);
-
-	arch_timer_ppi[PHYS_NONSECURE_PPI] =
-		map_generic_timer_interrupt(gtdt->non_secure_el1_interrupt,
-		gtdt->non_secure_el1_flags);
-
-	arch_timer_ppi[VIRT_PPI] =
-		map_generic_timer_interrupt(gtdt->virtual_timer_interrupt,
-		gtdt->virtual_timer_flags);
+	if (gtdt_arch_timer_data_init(table, &data))
+		return -EINVAL;
 
-	arch_timer_ppi[HYP_PPI] =
-		map_generic_timer_interrupt(gtdt->non_secure_el2_interrupt,
-		gtdt->non_secure_el2_flags);
+	arch_timer_ppi[PHYS_SECURE_PPI] = data.phys_secure_ppi;
+	arch_timer_ppi[PHYS_NONSECURE_PPI] = data.phys_nonsecure_ppi;
+	arch_timer_ppi[VIRT_PPI] = data.virt_ppi;
+	arch_timer_ppi[HYP_PPI] = data.hyp_ppi;
+	arch_timer_c3stop = data.c3stop; /* Always-on capability */
 
 	/* Get the frequency from CNTFRQ */
 	arch_timer_detect_rate(NULL, NULL);
-
-	/* Always-on capability */
-	arch_timer_c3stop = !(gtdt->non_secure_el1_flags & ACPI_GTDT_ALWAYS_ON);
-
 	arch_timer_init();
+
 	return 0;
 }
 CLOCKSOURCE_ACPI_DECLARE(arch_timer, ACPI_SIG_GTDT, arch_timer_acpi_init);
-- 
2.5.0



From fu.wei at linaro.org  Mon Feb  1 12:26:55 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Tue,  2 Feb 2016 04:26:55 +0800
Subject: [PATCH v3 3/6] clocksource: add memory-mapped timer support in
 arm_arch_timer.c
In-Reply-To: <1454358418-5157-1-git-send-email-fu.wei@linaro.org>
References: <1454358418-5157-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1454358418-5157-4-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

The patch add memory-mapped timer register support for arm_arch_timer driver
by using the information provided by the new GTDT driver of ACPI.

Signed-off-by: Fu Wei <fu.wei at linaro.org>
---
 drivers/clocksource/arm_arch_timer.c | 136 +++++++++++++++++++++++++++++++++++
 1 file changed, 136 insertions(+)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 87d6bae..3792fd6 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -666,6 +666,15 @@ arch_timer_needs_probing(int type, const struct of_device_id *matches)
 		needs_probing = true;
 	of_node_put(dn);
 
+#ifdef CONFIG_ACPI_GTDT
+	/*
+	 * Check if we have timer in GTDT table
+	 */
+	if (!acpi_disabled && gtdt_timer_is_available(type) &&
+	    !(arch_timers_present & type))
+		needs_probing = true;
+#endif
+
 	return needs_probing;
 }
 
@@ -835,4 +844,131 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *table)
 	return 0;
 }
 CLOCKSOURCE_ACPI_DECLARE(arch_timer, ACPI_SIG_GTDT, arch_timer_acpi_init);
+
+static u32 __init arch_timer_mem_cnttidr(struct acpi_gtdt_timer_block *gt_block)
+{
+	phys_addr_t cntctlbase_phy;
+	void __iomem *cntctlbase;
+	u32 cnttidr;
+
+	cntctlbase_phy = (phys_addr_t)gtdt_gt_cntctlbase(gt_block);
+	if (!cntctlbase_phy) {
+		pr_err("arch_timer: Can't find CNTCTLBase.\n");
+		return 0;
+	}
+
+	/*
+	 * According to ARMv8 Architecture Reference Manual(ARM),
+	 * the size of CNTCTLBase frame of memory-mapped timer
+	 * is SZ_4K(Offset 0x000 ? 0xFFF).
+	 */
+	cntctlbase = ioremap(cntctlbase_phy, SZ_4K);
+	if (!cntctlbase) {
+		pr_err("arch_timer: Can't map CNTCTLBase\n");
+		return 0;
+	}
+	cnttidr = readl_relaxed(cntctlbase + CNTTIDR);
+	iounmap(cntctlbase);
+
+	return cnttidr;
+}
+
+static int __init arch_timer_mem_best_frame(struct acpi_table_header *table,
+					    struct arch_timer_mem_data *data)
+{
+	struct acpi_gtdt_timer_block *gt_block;
+	u32 frame_number, timer_count, cnttidr;
+	int i;
+
+	gt_block = gtdt_gt_block(table, 0);
+	if (!gt_block) {
+		pr_err("arch_timer: Can't find GT Block.\n");
+		return -EINVAL;
+	}
+
+	timer_count = gtdt_gt_timer_count(gt_block);
+	if (!timer_count) {
+		pr_err("arch_timer: Can't find GT frame number.\n");
+		return -EINVAL;
+	}
+
+	if (gtdt_gt_timer_data(gt_block, 0, false, data)) {
+		pr_err("arch_timer: Can't get first phy timer.\n");
+		return -EINVAL;
+	}
+
+	/*
+	 * Get Generic Timer Counter-timer Timer ID Register
+	 * for Virtual Timer Capability info
+	 */
+	cnttidr = arch_timer_mem_cnttidr(gt_block);
+
+	/*
+	 * Try to find a virtual capable frame.
+	 * Otherwise fall back to the first physical capable frame.
+	 */
+	for (i = 0; i < timer_count; i++) {
+		frame_number = gtdt_gt_frame_number(gt_block, i);
+		if (frame_number < ARCH_TIMER_MEM_MAX_FRAME &&
+		    cnttidr & CNTTIDR_VIRT(frame_number)) {
+			if (!gtdt_gt_timer_data(gt_block, i, true, data)) {
+				arch_timer_mem_use_virtual = true;
+				return 0;
+			}
+			pr_warn("arch_timer: Can't get virt timer.\n");
+		}
+	}
+
+	return 0;
+}
+
+/* Initialize memory-mapped timer(wake-up timer) */
+static int __init arch_timer_mem_acpi_init(struct acpi_table_header *table)
+{
+	struct arch_timer_mem_data data;
+	void __iomem *cntbase;
+
+	if (arch_timers_present & ARCH_MEM_TIMER) {
+		pr_warn("arch_timer_mem: already initialized, skipping\n");
+		return -EINVAL;
+	}
+	arch_timers_present |= ARCH_MEM_TIMER;
+
+	if (arch_timer_mem_best_frame(table, &data))
+		return -EINVAL;
+
+	/*
+	 * According to ARMv8 Architecture Reference Manual(ARM),
+	 * the size of CNTBaseN frames of memory-mapped timer
+	 * is SZ_4K(Offset 0x000 ? 0xFFF).
+	 */
+	cntbase = ioremap(data.cntbase_phy, SZ_4K);
+	if (!cntbase) {
+		pr_err("arch_timer: Can't map CntBase.\n");
+		return -EINVAL;
+	}
+	arch_counter_base = cntbase;
+
+	if (!data.irq) {
+		pr_err("arch_timer: Frame missing %s irq",
+		       arch_timer_mem_use_virtual ? "virt" : "phys");
+		return -EINVAL;
+	}
+
+	/*
+	 * Because in a system that implements both Secure and
+	 * Non-secure states, CNTFRQ is only accessible in Secure state.
+	 * So we try to get the system counter frequency from cntfrq_el0
+	 * (system coprocessor register) here just like arch_timer.
+	 */
+	arch_timer_detect_rate(NULL, NULL);
+
+	arch_timer_mem_register(cntbase, data.irq);
+	arch_timer_common_init();
+
+	return 0;
+}
+
+CLOCKSOURCE_ACPI_DECLARE(arch_timer_mem, ACPI_SIG_GTDT,
+			 arch_timer_mem_acpi_init);
 #endif
-- 
2.5.0



From fu.wei at linaro.org  Mon Feb  1 12:26:56 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Tue,  2 Feb 2016 04:26:56 +0800
Subject: [PATCH v3 4/6] clocksource: move some enums to arm_arch_timer.h
In-Reply-To: <1454358418-5157-1-git-send-email-fu.wei@linaro.org>
References: <1454358418-5157-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1454358418-5157-5-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

The patch move enum ppi_nr from arm_arch_timer.c
to arm_arch_timer.h, and add enum spi_nr.

Signed-off-by: Fu Wei <fu.wei at linaro.org>
---
 drivers/clocksource/arm_arch_timer.c | 13 ++-----------
 include/clocksource/arm_arch_timer.h | 14 ++++++++++++++
 2 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 3792fd6..90d17ef 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -52,15 +52,6 @@ struct arch_timer {
 #define to_arch_timer(e) container_of(e, struct arch_timer, evt)
 
 static u32 arch_timer_rate;
-
-enum ppi_nr {
-	PHYS_SECURE_PPI,
-	PHYS_NONSECURE_PPI,
-	VIRT_PPI,
-	HYP_PPI,
-	MAX_TIMER_PPI
-};
-
 static int arch_timer_ppi[MAX_TIMER_PPI];
 
 static struct clock_event_device __percpu *arch_timer_evt;
@@ -798,9 +789,9 @@ static void __init arch_timer_mem_init(struct device_node *np)
 	}
 
 	if (arch_timer_mem_use_virtual)
-		irq = irq_of_parse_and_map(best_frame, 1);
+		irq = irq_of_parse_and_map(best_frame, VIRT_SPI);
 	else
-		irq = irq_of_parse_and_map(best_frame, 0);
+		irq = irq_of_parse_and_map(best_frame, PHYS_SPI);
 	of_node_put(best_frame);
 	if (!irq) {
 		pr_err("arch_timer: Frame missing %s irq",
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index 7a6d6dc..7bb5c1e 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -32,6 +32,20 @@ enum arch_timer_reg {
 	ARCH_TIMER_REG_TVAL,
 };
 
+enum ppi_nr {
+	PHYS_SECURE_PPI,
+	PHYS_NONSECURE_PPI,
+	VIRT_PPI,
+	HYP_PPI,
+	MAX_TIMER_PPI
+};
+
+enum spi_nr {
+	PHYS_SPI,
+	VIRT_SPI,
+	MAX_TIMER_SPI
+};
+
 #define ARCH_TIMER_PHYS_ACCESS		0
 #define ARCH_TIMER_VIRT_ACCESS		1
 #define ARCH_TIMER_MEM_PHYS_ACCESS	2
-- 
2.5.0



From fu.wei at linaro.org  Mon Feb  1 12:26:57 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Tue,  2 Feb 2016 04:26:57 +0800
Subject: [PATCH v3 5/6] kvm: arm64: wrapping DT support for virt arch timer
In-Reply-To: <1454358418-5157-1-git-send-email-fu.wei@linaro.org>
References: <1454358418-5157-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1454358418-5157-6-git-send-email-fu.wei@linaro.org>

From: Wei Huang <wei at redhat.com>

This patches wrapping DT support for virt arch timer into a function.

[Fu Wei: improve the DT support, and separate ACPI support]

Signed-off-by: Alexander Spyridaki <a.spyridakis at virtualopensystems.com>
Signed-off-by: Wei Huang <wei at redhat.com>
Signed-off-by: Graeme Gregory <graeme.gregory at linaro.org>
Signed-off-by: Fu Wei <fu.wei at linaro.org>
---
 virt/kvm/arm/arch_timer.c | 49 +++++++++++++++++++++++++++++++----------------
 1 file changed, 32 insertions(+), 17 deletions(-)

diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 69bca185..0a279d3 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -381,9 +381,30 @@ static const struct of_device_id arch_timer_of_match[] = {
 	{},
 };
 
-int kvm_timer_hyp_init(void)
+static int kvm_timer_get_ppi(unsigned int *ppi)
 {
 	struct device_node *np;
+	int ret = -EINVAL;
+
+	np = of_find_matching_node(NULL, arch_timer_of_match);
+	if (!np) {
+		ret = -ENODEV;
+		*ppi = 0;
+		goto skip_of;
+	}
+
+	*ppi = irq_of_parse_and_map(np, VIRT_PPI);
+	of_node_put(np);
+
+skip_of:
+	if (*ppi)
+		return 0;
+
+	return ret;
+}
+
+int kvm_timer_hyp_init(void)
+{
 	unsigned int ppi;
 	int err;
 
@@ -391,17 +412,11 @@ int kvm_timer_hyp_init(void)
 	if (!timecounter)
 		return -ENODEV;
 
-	np = of_find_matching_node(NULL, arch_timer_of_match);
-	if (!np) {
-		kvm_err("kvm_arch_timer: can't find DT node\n");
-		return -ENODEV;
-	}
-
-	ppi = irq_of_parse_and_map(np, 2);
-	if (!ppi) {
-		kvm_err("kvm_arch_timer: no virtual timer interrupt\n");
-		err = -EINVAL;
-		goto out;
+	err = kvm_timer_get_ppi(&ppi);
+	if (err) {
+		kvm_err("kvm_arch_timer: can't find virtual timer info or "
+			"config virtual timer interrupt.\n");
+		return err;
 	}
 
 	err = request_percpu_irq(ppi, kvm_arch_timer_handler,
@@ -409,7 +424,7 @@ int kvm_timer_hyp_init(void)
 	if (err) {
 		kvm_err("kvm_arch_timer: can't request interrupt %d (%d)\n",
 			ppi, err);
-		goto out;
+		return err;
 	}
 
 	host_vtimer_irq = ppi;
@@ -426,14 +441,14 @@ int kvm_timer_hyp_init(void)
 		goto out_free;
 	}
 
-	kvm_info("%s IRQ%d\n", np->name, ppi);
+	kvm_info("timer IRQ%d.\n", ppi);
 	on_each_cpu(kvm_timer_init_interrupt, NULL, 1);
 
-	goto out;
+	return 0;
+
 out_free:
 	free_percpu_irq(ppi, kvm_get_running_vcpus());
-out:
-	of_node_put(np);
+
 	return err;
 }
 
-- 
2.5.0



From olof at lixom.net  Mon Feb  1 12:17:45 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 1 Feb 2016 12:17:45 -0800
Subject: [PATCH] bus: uniphier-system-bus: revive tristate prompt
In-Reply-To: <1453557988-2874-1-git-send-email-yamada.masahiro@socionext.com>
References: <1453557988-2874-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <20160201201745.GA13508@localhost>

On Sat, Jan 23, 2016 at 11:06:28PM +0900, Masahiro Yamada wrote:
> At first, commit 4b7f48d395a7 ("bus: uniphier-system-bus: add UniPhier
> System Bus driver") introduced this driver as a tristate one.
> 
> Then, commit 326ea45aa827 ("bus: uniphier: allow only built-in
> driver") temporarily made it boolean in order to fix a link error
> in case it is compiled as a module.
> 
> The root cause was fixed by commit b80443c2211c ("of/platform: export
> of_default_bus_match_table").
> 
> Now this driver can really be a module.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>

Applied to fixes.


-Olof


From olof at lixom.net  Mon Feb  1 12:17:57 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 1 Feb 2016 12:17:57 -0800
Subject: [PATCH] ARM: realview: use const and __initconst for
 smp_operations
In-Reply-To: <1453721587-15363-1-git-send-email-yamada.masahiro@socionext.com>
References: <1453721587-15363-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <20160201201757.GB13508@localhost>

On Mon, Jan 25, 2016 at 08:33:07PM +0900, Masahiro Yamada wrote:
> This newly added code missed the global fixup by commit 75305275a721
> ("ARM: use const and __initconst for smp_operations").  So fix it now.
> 
> Also, add missing "static" qualifier.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>


Applied to fixes.


-Olof



From olof at lixom.net  Mon Feb  1 12:18:16 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 1 Feb 2016 12:18:16 -0800
Subject: [PATCH] ARM: tango: use const and __initconst for smp_operations
In-Reply-To: <1453721622-15437-1-git-send-email-yamada.masahiro@socionext.com>
References: <1453721622-15437-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <20160201201816.GC13508@localhost>

On Mon, Jan 25, 2016 at 08:33:42PM +0900, Masahiro Yamada wrote:
> This newly added code missed the global fixup by commit 75305275a721
> ("ARM: use const and __initconst for smp_operations").  So fix it now.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>

Applied to fixes, thanks.


-Olof
> ---
> 
>  arch/arm/mach-tango/platsmp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-tango/platsmp.c b/arch/arm/mach-tango/platsmp.c
> index a18d5a3..a21f55e 100644
> --- a/arch/arm/mach-tango/platsmp.c
> +++ b/arch/arm/mach-tango/platsmp.c
> @@ -9,7 +9,7 @@ static int tango_boot_secondary(unsigned int cpu, struct task_struct *idle)
>  	return 0;
>  }
>  
> -static struct smp_operations tango_smp_ops __initdata = {
> +static const struct smp_operations tango_smp_ops __initconst = {
>  	.smp_boot_secondary	= tango_boot_secondary,
>  };
>  
> -- 
> 1.9.1
> 


From olof at lixom.net  Mon Feb  1 12:19:04 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 1 Feb 2016 12:19:04 -0800
Subject: [PATCH] ARM: tango: use "depends on" instead of "if" after prompt
In-Reply-To: <1453722044-23005-1-git-send-email-yamada.masahiro@socionext.com>
References: <1453722044-23005-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <20160201201904.GD13508@localhost>

On Mon, Jan 25, 2016 at 08:40:44PM +0900, Masahiro Yamada wrote:
> This platform was recently added, so missed the global fixup by
> commit e32465429490 ("ARM: use "depends on" for SoC configs instead
> of "if" after prompt").  Fix it now.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>

Applied to fixes.


-Olof



From olof at lixom.net  Mon Feb  1 12:19:22 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 1 Feb 2016 12:19:22 -0800
Subject: [PATCH] ARM: realview: use "depends on" instead of "if" after
 prompt
In-Reply-To: <1453722164-23198-1-git-send-email-yamada.masahiro@socionext.com>
References: <1453722164-23198-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <20160201201922.GE13508@localhost>

On Mon, Jan 25, 2016 at 08:42:44PM +0900, Masahiro Yamada wrote:
> This platform recently moved to multi-platform, so missed the global
> fixup by commit e32465429490 ("ARM: use "depends on" for SoC configs
> instead of "if" after prompt").  Fix it now.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>

Applied to fixes.


-Olof


From olof at lixom.net  Mon Feb  1 12:24:01 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 1 Feb 2016 12:24:01 -0800
Subject: [GIT PULL] omap fixes against v4.5-rc1
In-Reply-To: <20160128175540.GG19432@atomide.com>
References: <20160128175540.GG19432@atomide.com>
Message-ID: <20160201202401.GH13508@localhost>

On Thu, Jan 28, 2016 at 09:55:41AM -0800, Tony Lindgren wrote:
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.5/fixes-rc1
> 
> for you to fetch changes up to ab342c77fa60a30fce4d4228f88fd1b7bf566055:
> 
>   ARM: dts: am57xx: sbc-am57x: correct Eth PHY settings (2016-01-27 09:19:31 -0800)


Thanks, merged.


-Olof


From olof at lixom.net  Mon Feb  1 12:22:35 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 1 Feb 2016 12:22:35 -0800
Subject: [GIT PULL] at91: fixes for 4.5 #1
In-Reply-To: <1453972115-25776-1-git-send-email-nicolas.ferre@atmel.com>
References: <1453972115-25776-1-git-send-email-nicolas.ferre@atmel.com>
Message-ID: <20160201202235.GG13508@localhost>

On Thu, Jan 28, 2016 at 10:08:35AM +0100, Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
> 
> First AT91 fixes pull-request for 4.5, all DT modifications. The bulk of the
> changes is about adding the phy specification to Ethernet nodes because of
> recent changes in phy drivers that tend to require a comprehensive description
> of the Ethernet hardware.
> It is based on 4.5-rc1 to prevent merging issues.
> 
> Thanks, best regards,
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git tags/at91-fixes
> 
> for you to fetch changes up to e873cc022ce5e2c04bbc53b5874494b657e29d3f:
> 
>   ARM: dts: at91: sama5d4 xplained: fix phy0 IRQ type (2016-01-27 11:14:25 +0100)

Thanks, merged.


-Olof


From olof at lixom.net  Mon Feb  1 12:20:23 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 1 Feb 2016 12:20:23 -0800
Subject: [RESEND PATCH V2] ARM64: tegra: Add chosen node for tegra132
 norrin
In-Reply-To: <1453753555-14634-1-git-send-email-jonathanh@nvidia.com>
References: <1453753555-14634-1-git-send-email-jonathanh@nvidia.com>
Message-ID: <20160201202023.GF13508@localhost>

On Mon, Jan 25, 2016 at 08:25:55PM +0000, Jon Hunter wrote:
> The NVIDIA bootloader, nvtboot, expects the "chosen" node to be present
> in the device-tree blob and if it is not then it fails to boot the kernel.
> Add the chosen node so we can boot the kernel on Tegra132 Norrin with the
> nvtboot bootloader.
> 
> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
> Acked-by: Thierry Reding <treding at nvidia.com>
> ---
> v1 -> v2 changes:
> - minor fixes to commit message
> 
> Ideally, we would like to get this into v4.5 as a fix for Tegra132 Norrin
> so that we can enable booting this board as part of our automated testing
> setup for Tegra [0][1]. Thierry suggested I send this directly as a fix
> to ARM-SOC. Let me know if this is ok. I have not included a "fixes" as it
> may not be needed for all bootloaders, but if you need this we could put:
> 
> Fixes: 0f279eb arm64: tegra: Add NVIDIA Tegra132 Norrin support
> 
> [0] http://nvtb.github.io/linux/
> [1] http://nvtb.github.io/linux-next/

Applied to fixes. Thanks.


-Olof


From olof at lixom.net  Mon Feb  1 12:24:51 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 1 Feb 2016 12:24:51 -0800
Subject: [GIT PULL] ARM: mvebu: fixes for v4.5 (#1)
In-Reply-To: <871t908do5.fsf@free-electrons.com>
References: <871t908do5.fsf@free-electrons.com>
Message-ID: <20160201202451.GI13508@localhost>

On Fri, Jan 29, 2016 at 07:04:58PM +0100, Gregory CLEMENT wrote:
> Hi,
> 
> Here is the first pull request for mvebu fixes for v4.5.
> 
> Gregory
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-4.5-1
> 
> for you to fetch changes up to ff61ee84e7aa5842d9e33c0b442f0b43a6a44eaf:
> 
>   ARM: dts: orion5x: gpio pin fixes for linkstation lswtgl (2016-01-25 16:22:59 +0100)
> 
> ----------------------------------------------------------------
> mvebu fixes for 4.5 (part 1)
> 
> - Fix dts on buffalo linksations machines (gpios and leds)
> - Fix dts partition node according to new binding introduced in v4.5

Thanks, merged.


-Olof


From fu.wei at linaro.org  Mon Feb  1 12:26:58 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Tue,  2 Feb 2016 04:26:58 +0800
Subject: [PATCH v3 6/6] kvm: arm64: Add ACPI support for virt arch timer
In-Reply-To: <1454358418-5157-1-git-send-email-fu.wei@linaro.org>
References: <1454358418-5157-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1454358418-5157-7-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This patch adds ACPI/GTDT support for virt arch timer
using the API in GTDT driver.

Signed-off-by: Fu Wei <fu.wei at linaro.org>
---
 virt/kvm/arm/arch_timer.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 0a279d3..4077347 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -385,6 +385,9 @@ static int kvm_timer_get_ppi(unsigned int *ppi)
 {
 	struct device_node *np;
 	int ret = -EINVAL;
+#ifdef CONFIG_ACPI_GTDT
+	struct arch_timer_data data;
+#endif
 
 	np = of_find_matching_node(NULL, arch_timer_of_match);
 	if (!np) {
@@ -397,6 +400,11 @@ static int kvm_timer_get_ppi(unsigned int *ppi)
 	of_node_put(np);
 
 skip_of:
+#ifdef CONFIG_ACPI_GTDT
+	if (!*ppi && !gtdt_arch_timer_data_init(NULL, &data))
+		*ppi = data.virt_ppi;
+#endif
+
 	if (*ppi)
 		return 0;
 
-- 
2.5.0



From olof at lixom.net  Mon Feb  1 12:27:33 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 1 Feb 2016 12:27:33 -0800
Subject: [GIT PULL] vexpress fixes for v4.5
In-Reply-To: <56AFA32C.4000901@arm.com>
References: <56AFA32C.4000901@arm.com>
Message-ID: <20160201202733.GA15279@localhost>

On Mon, Feb 01, 2016 at 06:25:48PM +0000, Sudeep Holla wrote:
> The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3:
> 
>   Linux 4.5-rc2 (2016-01-31 18:12:16 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git
> tags/vexpress-for-v4.5/fixes-rc2
> 
> for you to fetch changes up to aeb2ee5683e51305aff274d8b0a50af69b3ab310:
> 
>   arm64: dts: Add missing DMA Abort interrupt to Juno (2016-02-01 09:59:59
> +0000)

Merged, thanks.


-Olof


From arnd at arndb.de  Mon Feb  1 12:35:54 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  1 Feb 2016 21:35:54 +0100
Subject: [PATCH 0/4] ARM Davinci warning fixes
Message-ID: <1454358962-640598-1-git-send-email-arnd@arndb.de>

Hi Kevin and Sekhar,

Here are a couple of warning fixes for Davinci that I have
collected while testing randconfig kernels.

The first three are rather obvious, the last one might
need some discussion, maybe there is another way to do this.

Please apply for 4.6, or Ack

	Arnd

Arnd Bergmann (4):
  ARM: davinci: limit DT support to DA850
  ARM: davinci: avoid unused mityomapl138_pn_info variable
  ARM: davinci: DA8xx+DMx combined kernels need PATCH_PHYS_VIRT
  ARM: davinci: make I2C support optional

 arch/arm/Kconfig                           |  1 +
 arch/arm/mach-davinci/Kconfig              | 22 ++++------------------
 arch/arm/mach-davinci/board-dm644x-evm.c   |  8 ++++++--
 arch/arm/mach-davinci/board-dm646x-evm.c   |  7 +++++++
 arch/arm/mach-davinci/board-mityomapl138.c |  2 +-
 5 files changed, 19 insertions(+), 21 deletions(-)

-- 
2.7.0



From arnd at arndb.de  Mon Feb  1 12:35:55 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  1 Feb 2016 21:35:55 +0100
Subject: [PATCH 1/4] ARM: davinci: limit DT support to DA850
In-Reply-To: <1454358962-640598-1-git-send-email-arnd@arndb.de>
References: <1454358962-640598-1-git-send-email-arnd@arndb.de>
Message-ID: <1454358962-640598-2-git-send-email-arnd@arndb.de>

When da8xx-dt.c is built with onlu DA830 support but not DA850
support enabled, we get a compiler warning about unused symbols:

arch/arm/mach-davinci/da8xx-dt.c:28:20: warning: 'da8xx_init_irq' defined but not used [-Wunused-function]
 static void __init da8xx_init_irq(void)
arch/arm/mach-davinci/da8xx-dt.c:33:30: warning: 'da850_auxdata_lookup' defined but not used [-Wunused-variable]
 static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {

Obviously none of the file make sense for DA830, so we should not
even attempt this, so we can avoid the warning by ensuring it is
only built for 850, not 830.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-davinci/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 83e0f40f9ff1..6124c69154c3 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -68,7 +68,7 @@ comment "DaVinci Board Type"
 config MACH_DA8XX_DT
 	bool "Support DA8XX platforms using device tree"
 	default y
-	depends on ARCH_DAVINCI_DA8XX
+	depends on ARCH_DAVINCI_DA850
 	select PINCTRL
 	help
 	  Say y here to include support for TI DaVinci DA850 based using
-- 
2.7.0



From arnd at arndb.de  Mon Feb  1 12:35:56 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  1 Feb 2016 21:35:56 +0100
Subject: [PATCH 2/4] ARM: davinci: avoid unused mityomapl138_pn_info variable
In-Reply-To: <1454358962-640598-1-git-send-email-arnd@arndb.de>
References: <1454358962-640598-1-git-send-email-arnd@arndb.de>
Message-ID: <1454358962-640598-3-git-send-email-arnd@arndb.de>

The mityomapl138_pn_info structure belongs into the CPU_FREQ support
that is hidden behind an #ifdef, and causes a harmless warning when
that support is disabled:

mach-davinci/board-mityomapl138.c:59:28: error: 'mityomapl138_pn_info' defined but not used [-Werror=unused-variable]

This moves the variable definition where it belongs.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-davinci/board-mityomapl138.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index de1316bf643a..c1f4b34785db 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -51,6 +51,7 @@ struct factory_config {
 
 static struct factory_config factory_config;
 
+#ifdef CONFIG_CPU_FREQ
 struct part_no_info {
 	const char	*part_no;	/* part number string of interest */
 	int		max_freq;	/* khz */
@@ -87,7 +88,6 @@ static struct part_no_info mityomapl138_pn_info[] = {
 	},
 };
 
-#ifdef CONFIG_CPU_FREQ
 static void mityomapl138_cpufreq_init(const char *partnum)
 {
 	int i, ret;
-- 
2.7.0



From arnd at arndb.de  Mon Feb  1 12:35:58 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  1 Feb 2016 21:35:58 +0100
Subject: [PATCH 4/4] ARM: davinci: make I2C support optional
In-Reply-To: <1454358962-640598-1-git-send-email-arnd@arndb.de>
References: <1454358962-640598-1-git-send-email-arnd@arndb.de>
Message-ID: <1454358962-640598-5-git-send-email-arnd@arndb.de>

The davinci platform has tried to get support for the EEPROM right,
but failed to get a clean build so far. At the moment, we get
a warning whenever CONFIG_SYSFS is disabled, as that is needed by
EEPROM_AT24:

warning: (MACH_DAVINCI_EVM && MACH_SFFSDR && MACH_DAVINCI_DM6467_EVM && MACH_DAVINCI_DM365_EVM && MACH_DAVINCI_DA830_EVM && MACH_MITYOMAPL138 && MACH_MINI2440) selects EEPROM_AT24 which has unmet direct dependencies (I2C && SYSFS)

Kevin Hilman initially added the 'select' to ensure that EEPROM_AT24
is always enabled in machines that really want it for normal operation
(i.e. for reading the MAC address). This broke when I2C was disabled,
and Russell King followed up with another patch to select that as
well.

I now see that the SYSFS dependency is still missing, which leaves
us with three options:

a) add 'select SYSFS' in addition to the others
b) change AT24_EEPPROM to work without sysfs (should be possible)
c) remove all those selects again and get the files to build when
   I2C is disabled.

I would really hate to do a) because adding select statements that
hardwire user-selectable symbols is generally a bad idea. I first
tried b) but then ended up redoing the patch from scratch to approach
c), so we can also remove the other selects.

I checked that CONFIG_I2C is still enabled with davinci_all_defconfig,
so that does not have to change.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 45b146d746ea ("ARM: Davinci: Fix I2C build errors")
Fixes: 22ca466847ad ("davinci: kconfig: select at24 eeprom for selected boards")
---
 arch/arm/mach-davinci/Kconfig            | 14 +-------------
 arch/arm/mach-davinci/board-dm644x-evm.c |  8 ++++++--
 arch/arm/mach-davinci/board-dm646x-evm.c |  7 +++++++
 3 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 8f54be83ec15..c1d2cb4ec04f 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -76,8 +76,6 @@ config MACH_DAVINCI_EVM
 	bool "TI DM644x EVM"
 	default ARCH_DAVINCI_DM644x
 	depends on ARCH_DAVINCI_DM644x
-	select EEPROM_AT24
-	select I2C
 	help
 	  Configure this option to specify the whether the board used
 	  for development is a DM644x EVM
@@ -85,8 +83,6 @@ config MACH_DAVINCI_EVM
 config MACH_SFFSDR
 	bool "Lyrtech SFFSDR"
 	depends on ARCH_DAVINCI_DM644x
-	select EEPROM_AT24
-	select I2C
 	help
 	  Say Y here to select the Lyrtech Small Form Factor
 	  Software Defined Radio (SFFSDR) board.
@@ -117,8 +113,6 @@ config MACH_DAVINCI_DM6467_EVM
 	bool "TI DM6467 EVM"
 	default ARCH_DAVINCI_DM646x
 	depends on ARCH_DAVINCI_DM646x
-	select EEPROM_AT24
-	select I2C
 	select MACH_DAVINCI_DM6467TEVM
 	help
 	  Configure this option to specify the whether the board used
@@ -131,8 +125,6 @@ config MACH_DAVINCI_DM365_EVM
 	bool "TI DM365 EVM"
 	default ARCH_DAVINCI_DM365
 	depends on ARCH_DAVINCI_DM365
-	select EEPROM_AT24
-	select I2C
 	help
 	  Configure this option to specify whether the board used
 	  for development is a DM365 EVM
@@ -141,9 +133,7 @@ config MACH_DAVINCI_DA830_EVM
 	bool "TI DA830/OMAP-L137/AM17x Reference Platform"
 	default ARCH_DAVINCI_DA830
 	depends on ARCH_DAVINCI_DA830
-	select EEPROM_AT24
-	select GPIO_PCF857X
-	select I2C
+	select GPIO_PCF857X if I2C
 	help
 	  Say Y here to select the TI DA830/OMAP-L137/AM17x Evaluation Module.
 
@@ -212,8 +202,6 @@ endchoice
 config MACH_MITYOMAPL138
 	bool "Critical Link MityDSP-L138/MityARM-1808 SoM"
 	depends on ARCH_DAVINCI_DA850
-	select EEPROM_AT24
-	select I2C
 	help
 	  Say Y here to select the Critical Link MityDSP-L138/MityARM-1808
 	  System on Module.  Information on this SoM may be found at
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 7a20507a3eef..68cc09907828 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -267,7 +267,7 @@ static struct platform_device rtc_dev = {
 static struct snd_platform_data dm644x_evm_snd_data;
 
 /*----------------------------------------------------------------------*/
-
+#ifdef CONFIG_I2C
 /*
  * I2C GPIO expanders
  */
@@ -612,6 +612,7 @@ static void __init evm_init_i2c(void)
 	i2c_add_driver(&dm6446evm_msp_driver);
 	i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
 }
+#endif
 
 #define VENC_STD_ALL	(V4L2_STD_NTSC | V4L2_STD_PAL)
 
@@ -780,7 +781,9 @@ static __init void davinci_evm_init(void)
 				pr_warn("%s: Cannot configure AEMIF\n",
 					__func__);
 
+#ifdef CONFIG_I2C
 			evm_leds[7].default_trigger = "nand-disk";
+#endif
 			if (HAS_NOR)
 				pr_warn("WARNING: both NAND and NOR flash are enabled; disable one of them.\n");
 		} else if (HAS_NOR)
@@ -789,9 +792,10 @@ static __init void davinci_evm_init(void)
 
 	platform_add_devices(davinci_evm_devices,
 			     ARRAY_SIZE(davinci_evm_devices));
+#ifdef CONFIG_I2C
 	evm_init_i2c();
-
 	davinci_setup_mmc(0, &dm6446evm_mmc_config);
+#endif
 	dm644x_init_video(&dm644xevm_capture_cfg, &dm644xevm_display_cfg);
 
 	davinci_serial_init(dm644x_serial_device);
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index ee6ab7e8d3b0..f702d4fc8eb8 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -121,6 +121,7 @@ static struct platform_device davinci_nand_device = {
 
 #define HAS_ATA		IS_ENABLED(CONFIG_BLK_DEV_PALMCHIP_BK3710)
 
+#ifdef CONFIG_I2C
 /* CPLD Register 0 bits to control ATA */
 #define DM646X_EVM_ATA_RST		BIT(0)
 #define DM646X_EVM_ATA_PWD		BIT(1)
@@ -316,6 +317,7 @@ static struct at24_platform_data eeprom_info = {
 	.setup          = davinci_get_mac_addr,
 	.context	= (void *)0x7f00,
 };
+#endif
 
 static u8 dm646x_iis_serializer_direction[] = {
        TX_MODE, RX_MODE, INACTIVE_MODE, INACTIVE_MODE,
@@ -346,6 +348,7 @@ static struct snd_platform_data dm646x_evm_snd_data[] = {
 	},
 };
 
+#ifdef CONFIG_I2C
 static struct i2c_client *cpld_client;
 
 static int cpld_video_probe(struct i2c_client *client,
@@ -710,6 +713,7 @@ static void __init evm_init_i2c(void)
 	evm_init_cpld();
 	evm_init_video();
 }
+#endif
 
 #define DM6467T_EVM_REF_FREQ		33000000
 
@@ -764,7 +768,10 @@ static __init void evm_init(void)
 	if (ret)
 		pr_warn("%s: GPIO init failed: %d\n", __func__, ret);
 
+#ifdef CONFIG_I2C
 	evm_init_i2c();
+#endif
+
 	davinci_serial_init(dm646x_serial_device);
 	dm646x_init_mcasp0(&dm646x_evm_snd_data[0]);
 	dm646x_init_mcasp1(&dm646x_evm_snd_data[1]);
-- 
2.7.0



From arnd at arndb.de  Mon Feb  1 12:35:57 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  1 Feb 2016 21:35:57 +0100
Subject: [PATCH 3/4] ARM: davinci: DA8xx+DMx combined kernels need
 PATCH_PHYS_VIRT
In-Reply-To: <1454358962-640598-1-git-send-email-arnd@arndb.de>
References: <1454358962-640598-1-git-send-email-arnd@arndb.de>
Message-ID: <1454358962-640598-4-git-send-email-arnd@arndb.de>

We already forbid that combination when AUTO_ZRELADDR is disabled,
for the same reason that the two have their RAM at different
physical addresses as seen from the CPU.

This does the same change for PATCH_PHYS_VIRT: if you disable
either of the options, Kconfig now enforces that you have to
pick one or the other SoC family.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/Kconfig              | 1 +
 arch/arm/mach-davinci/Kconfig | 6 ++----
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 21d79b2531cc..8b10ccf4077e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -612,6 +612,7 @@ config ARCH_DAVINCI
 	select ARCH_HAS_HOLES_MEMORYMODEL
 	select ARCH_REQUIRE_GPIOLIB
 	select CLKDEV_LOOKUP
+	select CPU_ARM926T
 	select GENERIC_ALLOCATOR
 	select GENERIC_CLOCKEVENTS
 	select GENERIC_IRQ_CHIP
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 6124c69154c3..8f54be83ec15 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -9,7 +9,6 @@ config CP_INTC
 
 config ARCH_DAVINCI_DMx
 	bool
-	select CPU_ARM926T
 
 menu "TI DaVinci Implementations"
 
@@ -32,7 +31,7 @@ config ARCH_DAVINCI_DM646x
 
 config ARCH_DAVINCI_DA830
 	bool "DA830/OMAP-L137/AM17x based system"
-	depends on !ARCH_DAVINCI_DMx || AUTO_ZRELADDR
+	depends on !ARCH_DAVINCI_DMx || (AUTO_ZRELADDR && ARM_PATCH_PHYS_VIRT)
 	select ARCH_DAVINCI_DA8XX
 	# needed on silicon revs 1.0, 1.1:
 	select CPU_DCACHE_WRITETHROUGH if !CPU_DCACHE_DISABLE
@@ -40,13 +39,12 @@ config ARCH_DAVINCI_DA830
 
 config ARCH_DAVINCI_DA850
 	bool "DA850/OMAP-L138/AM18x based system"
-	depends on !ARCH_DAVINCI_DMx || AUTO_ZRELADDR
+	depends on !ARCH_DAVINCI_DMx || (AUTO_ZRELADDR && ARM_PATCH_PHYS_VIRT)
 	select ARCH_DAVINCI_DA8XX
 	select CP_INTC
 
 config ARCH_DAVINCI_DA8XX
 	bool
-	select CPU_ARM926T
 
 config ARCH_DAVINCI_DM365
 	bool "DaVinci 365 based system"
-- 
2.7.0



From gregkh at linuxfoundation.org  Mon Feb  1 13:06:45 2016
From: gregkh at linuxfoundation.org (Greg KH)
Date: Mon, 1 Feb 2016 13:06:45 -0800
Subject: [PATCH 0/4] nvmem: new drivers for v4.5
In-Reply-To: <56AF3468.2020806@linaro.org>
References: <1449485763-391-1-git-send-email-srinivas.kandagatla@linaro.org>
 <5693AC68.6040802@linaro.org> <20160111183018.GA10243@kroah.com>
 <56AF3468.2020806@linaro.org>
Message-ID: <20160201210645.GA10149@kroah.com>

On Mon, Feb 01, 2016 at 10:33:12AM +0000, Srinivas Kandagatla wrote:
> Hi Greg,
> 
> On 11/01/16 18:30, Greg KH wrote:
> >On Mon, Jan 11, 2016 at 01:21:44PM +0000, Srinivas Kandagatla wrote:
> >>
> >>
> >>On 07/12/15 10:56, Srinivas Kandagatla wrote:
> >>>Hi Greg,
> >>>
> >>>Here are 2 new nvmem drivers which are in the mailing list for long time
> >>>and are good to go for some testing and find its way to v4.5-rc*.
> >>>
> >>>Could you please take these patches via char-misc tree.
> >>Hi Greg,
> >>
> >>I have not seen these patches or https://lkml.org/lkml/2015/12/14/169 appear
> >>in your char-misc tree/linux-next.
> >>
> >>Just wanted to know whats your plan on these patches?
> >
> >To wait until after 4.5-rc1 is out, sorry, my patch backlog got huge
> >during Nov/Dec due to other external issues, I'll be digging out from
> >them after 4.5-rc1 is out.
> 
> Am not sure if this was forgotten, just wanted know if you still have plans
> to pick this series for any rc on 4.5?

They are in my queue...


From f.fainelli at gmail.com  Mon Feb  1 13:11:36 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Mon, 01 Feb 2016 13:11:36 -0800
Subject: [PATCH] ARM: bcm: use const and __initconst for smp_operations
In-Reply-To: <56A65841.1040100@broadcom.com>
References: <1453721475-15156-1-git-send-email-yamada.masahiro@socionext.com>
 <56A65841.1040100@broadcom.com>
Message-ID: <56AFCA08.60903@gmail.com>

On 25/01/16 09:15, Ray Jui wrote:
> Hi Masahiro,
> 
> On 1/25/2016 3:31 AM, Masahiro Yamada wrote:
>> This newly added code missed the global fixup by commit 75305275a721
>> ("ARM: use const and __initconst for smp_operations").  So fix it now.
>>
>> Also, add missing "static" qualifier.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>

Applied, thanks!
-- 
Florian


From nicolas.pitre at linaro.org  Mon Feb  1 13:15:38 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Mon, 1 Feb 2016 16:15:38 -0500 (EST)
Subject: [PATCH v2] ARM: proc-v7.S: Adjust stack address when
 XIP_KERNEL
In-Reply-To: <1454335736-10084-1-git-send-email-chris.brandt@renesas.com>
References: <1454105474-3009-1-git-send-email-chris.brandt@renesas.com>
 <1454335736-10084-1-git-send-email-chris.brandt@renesas.com>
Message-ID: <alpine.LFD.2.20.1602011613360.32766@knanqh.ubzr>

On Mon, 1 Feb 2016, Chris Brandt wrote:

> From: Nicolas Pitre <nico at linaro.org>
> 
> When XIP_KERNEL is enabled, the virt to phys address translation for RAM
> is not the same as the virt to phys address translation for .text.
> The only way to know where physical RAM is located is to use
> PLAT_PHYS_OFFSET.
> The MACRO will be useful for other places where there is a similar problem.
> 
> Signed-off-by: Nicolas Pitre <nico at linaro.org>
> Signed-off-by: Chris Brandt <chris.brandt at renesas.com>

Looks fine.  You may submit it here:

http://www.arm.linux.org.uk/developer/patches/


> ---
> v2:
> * Fixed Signed-off to show correct author
> ---
>  arch/arm/include/asm/memory.h | 8 ++++++++
>  arch/arm/mm/proc-v7.S         | 2 +-
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index c79b57b..7dd2ab5 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -134,6 +134,14 @@
>   */
>  #define PLAT_PHYS_OFFSET	UL(CONFIG_PHYS_OFFSET)
>  
> +#ifdef CONFIG_XIP_KERNEL
> +#define PHYS_OFFSET_FIXUP \
> +	( XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR) - PAGE_OFFSET + \
> +	  PLAT_PHYS_OFFSET - CONFIG_XIP_PHYS_ADDR )
> +#else
> +#define PHYS_OFFSET_FIXUP 0
> +#endif
> +
>  #ifndef __ASSEMBLY__
>  
>  /*
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index 0f92d57..1595fb2 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -487,7 +487,7 @@ __errata_finish:
>  
>  	.align	2
>  __v7_setup_stack_ptr:
> -	.word	__v7_setup_stack - .
> +	.word	__v7_setup_stack - . + PHYS_OFFSET_FIXUP
>  ENDPROC(__v7_setup)
>  
>  	.bss
> -- 
> 1.9.1
> 
> 
> 


From heiko at sntech.de  Mon Feb  1 13:17:22 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Mon, 01 Feb 2016 22:17:22 +0100
Subject: [PATCH] PM / AVS: rockchip-io: add GRF and PMUGRF types to
 distinguish
In-Reply-To: <56AF1D4E.40307@rock-chips.com>
References: <1454155305-55516-1-git-send-email-david.wu@rock-chips.com>
 <5387650.lAgTxexlF2@phil> <56AF1D4E.40307@rock-chips.com>
Message-ID: <5354361.hQXgJ7cEGx@diego>

Hi David,

Am Montag, 1. Februar 2016, 16:54:38 schrieb David.Wu:
> ? 2016/1/30 20:39, Heiko Stuebner ??:
> > Am Samstag, 30. Januar 2016, 20:01:45 schrieb David Wu:
> >> As rk3368 contained two separated iodomain areas, this was
> >> determined to use which regmap base address.
> >> 
> >> Signed-off-by: David Wu <david.wu at rock-chips.com>
> > 
> > I don't think we need to specify this on a driver level. Both GRF areas
> > are
> > "General register files" only located in two separate power-domains.
> > So the rockchip,grf property should work for both. Especially as nothing
> > keeps designers from introducing yet another GRF-area somewhere else ;-)
> > 
> > >From when I started working on the rk3368, I still have a preliminary
> > 
> > patches for that sitting here, so I've attached on how I envisoned that to
> > work.
> 
> Okay, i agree to you, but it make someone a little confused just from
> the drive code,
> not DT file,  about  pmugrf regmap base address.:-)
> 
> How do you feel about intergating GRF and PMU drivers in one driver?
> Thanks!

I will very strongly disagree here ;-) .
Similar to the power-domains being part of the pmu, the io-domains are
part of their individual GRFs. So if you want it really clean and tidy the way 
to go foward will be the attached patches. Compile-tested only.

Other things like the usbphy control should move there as well in the long 
run. But that's not immediate necessary.


Heiko
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-PM-AVS-rockchip-io-make-io-domains-a-child-of-the-GR.patch
Type: text/x-patch
Size: 2790 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160201/56da602b/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-arm64-dts-rockchip-add-rk3368-iodomains.patch
Type: text/x-patch
Size: 1174 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160201/56da602b/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-arm64-dts-rockchip-make-grf-syscons-simple-mfds.patch
Type: text/x-patch
Size: 1316 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160201/56da602b/attachment-0005.bin>

From pavel at ucw.cz  Mon Feb  1 13:17:36 2016
From: pavel at ucw.cz (Pavel Machek)
Date: Mon, 1 Feb 2016 22:17:36 +0100
Subject: N900 sleep mode (in 4.5-rc0, if that matters)
In-Reply-To: <20160201181316.GM19432@atomide.com>
References: <20160123121022.GB12497@amd> <20160125163332.GT19432@atomide.com>
 <20160126140010.GA29723@amd> <20160126172527.GY3500@atomide.com>
 <20160130200244.GA30429@amd> <20160130201452.GC30429@amd>
 <20160130221509.GA28644@amd> <20160201181316.GM19432@atomide.com>
Message-ID: <20160201211736.GA11283@amd>

Hi!

> > > > Any ideas what jumps to use the modules? Charger code?
> > > 
> > > I tried a kernel without charger code, and no luck, rmmod fails the
> > > same way. dmesg says:
> > > [  111.093078] wlan0: authenticated
> > > [  111.097442] wlan0: associate with 06:27:22:f9:10:6a (try 1/3)
> > > [  111.104553] wlan0: RX AssocResp from 06:27:22:f9:10:6a (capab=0x421
> > > status=0 aid=2)
> > > [  111.104705] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 2),
> > > will use 2
> > > [  111.104736] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 3),
> > > will use 2
> > > [  111.256652] wlan0: associated
> > > [  184.681427] HS USB OTG: no transceiver configured
> > > [  184.681488] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
> > > with status -517
> > > [  184.681976] HS USB OTG: no transceiver configured
> > > [  184.682006] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
> > > with status -517
> > > [  187.690338] twl4030_usb 48070000.i2c:twl at 48:twl4030-usb:
> > > Initialized TWL4030 USB module
> > > [  187.698303] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk
> > > combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
> > > [  187.698333] musb-hdrc: MHDRC RTL version 1.400
> > > [  187.698333] musb-hdrc: setup fifo_mode 4
> > > [  187.698394] musb-hdrc: 28/31 max ep, 16384/16384 memory
> > > pavel at n900:/my/tui/ofone$
> > 
> > I added following hack to phy-twl4030-usb.c so that I could avoid
> > modules and module unloading problem. But still could not get it to
> > sleep :-(.
> 
> Are you sure you're using v4.5-rc? I recently patched away some
> issues where rmmod of the musb related modules did not work.

No, sorry, that was with 4.4. As you hit "PM regression with commit
5de85b9d57ab PM runtime re-init in v4.5-rc1", I thought I'd avoid
v4.5-rc. 

(I assume I have to insmod and rmmod, right? Because powersave is not
entered if I simply compile-out usb).

Would you have commit ids for those rmmod fixes? It might be good to
push them into stable, and I should try again with them applied...

Thanks and best regards,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From labbott at redhat.com  Mon Feb  1 13:24:25 2016
From: labbott at redhat.com (Laura Abbott)
Date: Mon, 1 Feb 2016 13:24:25 -0800
Subject: [PATCHv2 2/3] arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
In-Reply-To: <20160201122911.GF674@leverpostej>
References: <1454111218-3461-1-git-send-email-labbott@fedoraproject.org>
 <1454111218-3461-3-git-send-email-labbott@fedoraproject.org>
 <20160201122911.GF674@leverpostej>
Message-ID: <56AFCD09.8000807@redhat.com>

On 02/01/2016 04:29 AM, Mark Rutland wrote:
> Hi,
>
> On Fri, Jan 29, 2016 at 03:46:57PM -0800, Laura Abbott wrote:
>>
>> ARCH_SUPPORTS_DEBUG_PAGEALLOC provides a hook to map and unmap
>> pages for debugging purposes. This requires memory be mapped
>> with PAGE_SIZE mappings since breaking down larger mappings
>> at runtime will lead to TLB conflicts. Check if debug_pagealloc
>> is enabled at runtime and if so, map everyting with PAGE_SIZE
>> pages. Implement the functions to actually map/unmap the
>> pages at runtime.
>>
>>
>> Signed-off-by: Laura Abbott <labbott at fedoraproject.org>
>
> I tried to apply atop of the arm64 for-next/pgtable branch, but git
> wasn't very happy about that -- which branch/patches is this based on?
>
> I'm not sure if I'm missing something, have something I shouldn't, or if
> my MTA is corrupting patches again...
>

Hmmm, I based it off of your arm64-pagetable-rework-20160125 tag and
Ard's patch for vmalloc and set_memory_* . The patches seem to apply
on the for-next/pgtable branch as well so I'm guessing you are missing
Ard's patch.

  
>> ---
>>   arch/arm64/Kconfig       |  3 +++
>>   arch/arm64/mm/mmu.c      | 10 +++++++---
>>   arch/arm64/mm/pageattr.c | 40 +++++++++++++++++++++++++++++++++-------
>>   3 files changed, 43 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 8cc6228..0f33218 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -537,6 +537,9 @@ config HOTPLUG_CPU
>>   source kernel/Kconfig.preempt
>>   source kernel/Kconfig.hz
>>
>> +config ARCH_SUPPORTS_DEBUG_PAGEALLOC
>> +	def_bool y
>> +
>>   config ARCH_HAS_HOLES_MEMORYMODEL
>>   	def_bool y if SPARSEMEM
>>
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index 103ebc0..5abbd30 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -181,7 +181,8 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
>>   	do {
>>   		next = pmd_addr_end(addr, end);
>>   		/* try section mapping first */
>> -		if (((addr | next | phys) & ~SECTION_MASK) == 0) {
>> +		if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
>> +		      (!debug_pagealloc_enabled() || !pgtable_alloc)) {
>>   			pmd_t old_pmd =*pmd;
>>   			set_pmd(pmd, __pmd(phys |
>>   					   pgprot_val(mk_sect_prot(prot))));
>> @@ -208,8 +209,11 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
>>   }
>>
>>   static inline bool use_1G_block(unsigned long addr, unsigned long next,
>> -			unsigned long phys)
>> +			unsigned long phys, phys_addr_t (*pgtable_alloc)(void))
>>   {
>> +	if (pgtable_alloc && debug_pagealloc_enabled())
>> +		return false;
>> +
>>   	if (PAGE_SHIFT != 12)
>>   		return false;
>>
>> @@ -241,7 +245,7 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
>>   		/*
>>   		 * For 4K granule only, attempt to put down a 1GB block
>>   		 */
>> -		if (use_1G_block(addr, next, phys)) {
>> +		if (use_1G_block(addr, next, phys, pgtable_alloc)) {
>>   			pud_t old_pud = *pud;
>>   			set_pud(pud, __pud(phys |
>>   					   pgprot_val(mk_sect_prot(prot))));
>
> The checks for pgtable_alloc is to allow create_mapping_noalloc to use
> sections regardless, right?
>
> I got a little confused by that initially, but that seems to make sense.
>

Yeah, that was what I was going for. I went for the implication with pgtable_alloc
over adding a bool variable to create_mapping. I'll see if I can put a comment
in somewhere to clarify the intentions.
  
>> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
>> index 1360a02..69a8a7d 100644
>> --- a/arch/arm64/mm/pageattr.c
>> +++ b/arch/arm64/mm/pageattr.c
>> @@ -38,7 +38,8 @@ static int change_page_range(pte_t *ptep, pgtable_t token, unsigned long addr,
>>   }
>>
>>   static int change_memory_common(unsigned long addr, int numpages,
>> -				pgprot_t set_mask, pgprot_t clear_mask)
>> +				pgprot_t set_mask, pgprot_t clear_mask,
>> +				bool ignore_vma_check)
>>   {
>>   	unsigned long start = addr;
>>   	unsigned long size = PAGE_SIZE*numpages;
>> @@ -65,11 +66,14 @@ static int change_memory_common(unsigned long addr, int numpages,
>>   	 *
>>   	 * So check whether the [addr, addr + size) interval is entirely
>>   	 * covered by precisely one VM area that has the VM_ALLOC flag set.
>> +	 *
>> +	 * The one exception to this is is we're forcing everything to be
>> +	 * page mapped with DEBUG_PAGEALLOC
>>   	 */
>>   	area = find_vm_area((void *)addr);
>> -	if (!area ||
>> +	if (!ignore_vma_check && (!area ||
>>   	    end > (unsigned long)area->addr + area->size ||
>> -	    !(area->flags & VM_ALLOC))
>> +	    !(area->flags & VM_ALLOC)))
>>   		return -EINVAL;
>
> Perhaps we could pull out everything but the VMA checks into a static
> __change_memory_common. Then we can call that directly in
> __kernel_map_pages, and don't need to pass a confusing boolean
> parameter.

Sounds fine.

>
> Otherwise, this looks good to me.
>  
> Mark.
>

Thanks,
Laura
  
>>
>>   	data.set_mask = set_mask;
>> @@ -86,21 +90,24 @@ int set_memory_ro(unsigned long addr, int numpages)
>>   {
>>   	return change_memory_common(addr, numpages,
>>   					__pgprot(PTE_RDONLY),
>> -					__pgprot(PTE_WRITE));
>> +					__pgprot(PTE_WRITE),
>> +					false);
>>   }
>>
>>   int set_memory_rw(unsigned long addr, int numpages)
>>   {
>>   	return change_memory_common(addr, numpages,
>>   					__pgprot(PTE_WRITE),
>> -					__pgprot(PTE_RDONLY));
>> +					__pgprot(PTE_RDONLY),
>> +					false);
>>   }
>>
>>   int set_memory_nx(unsigned long addr, int numpages)
>>   {
>>   	return change_memory_common(addr, numpages,
>>   					__pgprot(PTE_PXN),
>> -					__pgprot(0));
>> +					__pgprot(0),
>> +					false);
>>   }
>>   EXPORT_SYMBOL_GPL(set_memory_nx);
>>
>> @@ -108,6 +115,25 @@ int set_memory_x(unsigned long addr, int numpages)
>>   {
>>   	return change_memory_common(addr, numpages,
>>   					__pgprot(0),
>> -					__pgprot(PTE_PXN));
>> +					__pgprot(PTE_PXN),
>> +					false);
>>   }
>>   EXPORT_SYMBOL_GPL(set_memory_x);
>> +
>> +#ifdef CONFIG_DEBUG_PAGEALLOC
>> +void __kernel_map_pages(struct page *page, int numpages, int enable)
>> +{
>> +	unsigned long addr = (unsigned long) page_address(page);
>> +
>> +	if (enable)
>> +		change_memory_common(addr, numpages,
>> +					__pgprot(PTE_VALID),
>> +					__pgprot(0),
>> +					true);
>> +	else
>> +		change_memory_common(addr, numpages,
>> +					__pgprot(0),
>> +					__pgprot(PTE_VALID),
>> +					true);
>> +}
>> +#endif
>> --
>> 2.5.0
>>



From alex.williamson at redhat.com  Mon Feb  1 13:34:38 2016
From: alex.williamson at redhat.com (Alex Williamson)
Date: Mon, 01 Feb 2016 14:34:38 -0700
Subject: [PATCH] vfio: pci: fix oops in case of
 vfio_msi_set_vector_signal failure
In-Reply-To: <56AF9585.1000904@linaro.org>
References: <1454078586-5431-1-git-send-email-eric.auger@linaro.org>
 <1454103676.9301.3.camel@redhat.com> <56AF9585.1000904@linaro.org>
Message-ID: <1454362478.10542.8.camel@redhat.com>

On Mon, 2016-02-01 at 18:27 +0100, Eric Auger wrote:
> Hi Alex,
> On 01/29/2016 10:41 PM, Alex Williamson wrote:
> > On Fri, 2016-01-29 at 14:43 +0000, Eric Auger wrote:
> > > In case vfio_msi_set_vector_signal fails we tear down everything.
> > > In the tear down loop we compare int j against unsigned start. Given
> > > the arithmetic conversion I think it is converted into an unsigned and
> > > becomes 0xffffffff, leading to the loop being entered again and things
> > > turn bad when accessing vdev->msix[vector].vector. So let's use int
> > > parameters instead.
> > > ?
> > > Signed-off-by: Eric Auger <eric.auger at linaro.org>
> > > ---
> > > ?drivers/vfio/pci/vfio_pci_intrs.c | 4 ++--
> > > ?1 file changed, 2 insertions(+), 2 deletions(-)
> > > ?
> > > diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c
> > > index 3b3ba15..510c48d 100644
> > > --- a/drivers/vfio/pci/vfio_pci_intrs.c
> > > +++ b/drivers/vfio/pci/vfio_pci_intrs.c
> > > @@ -374,8 +374,8 @@ static int vfio_msi_set_vector_signal(struct vfio_pci_device *vdev,
> > > ?	return 0;
> > > ?}
> > > ?
> > > -static int vfio_msi_set_block(struct vfio_pci_device *vdev, unsigned start,
> > > -			??????unsigned count, int32_t *fds, bool msix)
> > > +static int vfio_msi_set_block(struct vfio_pci_device *vdev, int start,
> > > +			??????int count, int32_t *fds, bool msix)
> > > ?{
> > > ?	int i, j, ret = 0;
> > > ?
> >?
> > Nice find, I don't think that's the only bug there though.??If @start is
> > -1 (UINT32_MAX) and @count is 1, then @j gets set to -1 in the setup and
> > we hit the same index dereference problem.??What if we did this instead:
> >?
> > diff --git a/drivers/vfio/pci/vfio_pci_intrs.c b/drivers/vfio/pci/vfio_pci_intrs.c
> > index 3b3ba15..2ae84ad 100644
> > --- a/drivers/vfio/pci/vfio_pci_intrs.c
> > +++ b/drivers/vfio/pci/vfio_pci_intrs.c
> > @@ -309,14 +309,14 @@ static int vfio_msi_set_vector_signal(struct vfio_pci_device *vdev,
> > ?				??????int vector, int fd, bool msix)
> > ?{
> > ?	struct pci_dev *pdev = vdev->pdev;
> > -	int irq = msix ? vdev->msix[vector].vector : pdev->irq + vector;
> > -	char *name = msix ? "vfio-msix" : "vfio-msi";
> > ?	struct eventfd_ctx *trigger;
> > -	int ret;
> > +	int irq, ret;
> > ?
> > -	if (vector >= vdev->num_ctx)
> > +	if (vector < 0 || vector >= vdev->num_ctx)
> > ?		return -EINVAL;
> > ?
> > +	irq = msix ? vdev->msix[vector].vector : pdev->irq + vector;
> > +
> > ?	if (vdev->ctx[vector].trigger) {
> > ?		free_irq(irq, vdev->ctx[vector].trigger);
> > ?		irq_bypass_unregister_producer(&vdev->ctx[vector].producer);
> > @@ -328,8 +328,9 @@ static int vfio_msi_set_vector_signal(struct vfio_pci_device *vdev,
> > ?	if (fd < 0)
> > ?		return 0;
> > ?
> > -	vdev->ctx[vector].name = kasprintf(GFP_KERNEL, "%s[%d](%s)",
> > -					???name, vector, pci_name(pdev));
> > +	vdev->ctx[vector].name = kasprintf(GFP_KERNEL, "vfio-msi%s[%d](%s)",
> > +					???msix ? "x" : "", vector,
> > +					???pci_name(pdev));
> > ?	if (!vdev->ctx[vector].name)
> > ?		return -ENOMEM;
> > ?
> > @@ -379,7 +380,7 @@ static int vfio_msi_set_block(struct vfio_pci_device *vdev, unsigned start,
> > ?{
> > ?	int i, j, ret = 0;
> > ?
> > -	if (start + count > vdev->num_ctx)
> > +	if (start >= vdev->num_ctx || start + count > vdev->num_ctx)
> > ?		return -EINVAL;
> > ?
> > ?	for (i = 0, j = start; i < count && !ret; i++, j++) {
> > @@ -388,7 +389,7 @@ static int vfio_msi_set_block(struct vfio_pci_device *vdev, unsigned start,
> > ?	}
> > ?
> > ?	if (ret) {
> > -		for (--j; j >= start; j--)
> > +		for (--j; j >= 0 && j >= start; j--)
> > ?			vfio_msi_set_vector_signal(vdev, j, -1, msix);
> > ?	}
> > ?
> >?
> > So we fix the problem with vfio_msi_set_vector_signal() dereferencing
> > the array before it validates the index (even though it shouldn't be
> > able to get there anymore), and then we do a better job of verifying
> > start and count (comparing to num_ctx will use unsigned even though
> > num_ctx itself is signed) and finally explicitly test the <0 case, which
> > I suppose we could also do by casting start at that point (we know it's
> > within the bounds of a signed integer given the previous tests).
>?
> Yes it looks OK to me.
>?
> I guess you submit? I will test it.

Yep, I'll post a real patch.??Thanks,

Alex



From manabian at gmail.com  Mon Feb  1 13:55:32 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Mon, 1 Feb 2016 22:55:32 +0100
Subject: [PATCH 1/2] clocksource/drivers/lpc32xx: Support periodic mode
In-Reply-To: <CAAEAJfD8LUV=t97RN3U4uqgzCLP89AQtHqBccKGd6-EskP9DOQ@mail.gmail.com>
References: <1454136379-7517-1-git-send-email-ezequiel@vanguardiasur.com.ar>
 <CAGhQ9VxO7Rsus8Js_oZDBxWzEHuUHnRyoVTVmawbtXmK7tNMcw@mail.gmail.com>
 <CAAEAJfAVTJm-PzhjkRmkdNG39sH7eHyEXaSX4q0=TCQ0468Heg@mail.gmail.com>
 <CAAEAJfD8LUV=t97RN3U4uqgzCLP89AQtHqBccKGd6-EskP9DOQ@mail.gmail.com>
Message-ID: <CAGhQ9VxtqkW4PLrpQWsyZu9bgB_98mmO=WZ7gvaeN_DWQ5M3rg@mail.gmail.com>

On 1 February 2016 at 16:09, Ezequiel Garcia
<ezequiel at vanguardiasur.com.ar> wrote:
> On 31 January 2016 at 17:07, Ezequiel Garcia
> <ezequiel at vanguardiasur.com.ar> wrote:
>> On 30 January 2016 at 16:39, Joachim  Eastwood <manabian at gmail.com> wrote:
>>> Hi Ezequiel,
>>>
>>> On 30 January 2016 at 07:46, Ezequiel Garcia
>>> <ezequiel at vanguardiasur.com.ar> wrote:
>>>> This commit adds the support for periodic mode. This is done by not
>>>> setting the MR0S (Stop on TnMR0) bit on MCR, thus allowing
>>>> interrupts to be periodically generated on MR0 matches.
>>>>
>>>> In order to do this, move the initial configuration that is specific to
>>>> the one shot mode to clock_event_device.set_state_oneshot.
>>>>
> [...]
>>
>>>
>>> I will look more closely at the new timer setup later.
>>>
>>> btw, didn't I look through a version of this you sent me privately
>>> quite some time ago?
>>> I think I had a comment about using TIMER_PR instead of TIMER_MR0
>>> then. Unsure if that is still valid, though.
>>>
>>
>> Ah, right. It was ages ago, and forgot your previous review. Sorry about that.
>> Using TIMER_PR looks less invasive so I'll send a v2 using it instead.
>
> Actually, using the prescale counter and MR0 = 1 resulted in exactly
> half the number of interrupts that I expected (HZ / 2). Using this
> patch, with PR=0 and MR0=ticks_per_jiggies, I can see HZ no. of
> interrupts per sec.
>
> Why did you choose to use the prescale in your oneshot implementation?

The clockevent code was copied from arch/arm/mach-lpc32xx/timer.c so
it's really old code.
I think it is a strange way to use the timer, but the logic still
seems good to me.

> Did you test or measure the timer expire using the PR and MR0 = 1?

I really can't remember. I do remember going through the timer setup
and it seemed like a valid, albeit slightly strange, way to use the
timer.

> To be honest, I'm still trying to make some sense out of my results.

I'll see if can find the time to do some more testing over here as well.


regards,
Joachim Eastwood


From linus.walleij at linaro.org  Mon Feb  1 14:02:48 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  1 Feb 2016 23:02:48 +0100
Subject: [PATCH] mtd: map: fix .set_vpp() documentation
Message-ID: <1454364168-1342-1-git-send-email-linus.walleij@linaro.org>

As of commit 876fe76d793d03077eb61ba3afab4a383f46c554
"mtd: maps: physmap: Add reference counter to set_vpp()"
the comment in the header file is incorrect and misleading.
Fix it up.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Paul Parsons <lost.distance at yahoo.com>
Fixes: 876fe76d793d ("mtd: maps: physmap: Add reference counter to set_vpp()")
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 include/linux/mtd/map.h | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index 58f3ba709ade..5e0eb7ccabd4 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -240,8 +240,11 @@ struct map_info {
 	   If there is no cache to care about this can be set to NULL. */
 	void (*inval_cache)(struct map_info *, unsigned long, ssize_t);
 
-	/* set_vpp() must handle being reentered -- enable, enable, disable
-	   must leave it enabled. */
+	/* This will be called with 1 as parameter when the first map user
+	 * needs VPP, and called with 0 when the last user exits. The map
+	 * core maintains a reference counter, and assumes that VPP is a
+	 * global resource applying to all mapped flash chips on the system.
+	 */
 	void (*set_vpp)(struct map_info *, int);
 
 	unsigned long pfow_base;
-- 
2.4.3



From carlo at caione.org  Mon Feb  1 14:05:31 2016
From: carlo at caione.org (Carlo Caione)
Date: Mon, 1 Feb 2016 23:05:31 +0100
Subject: [PATCH v4] mmc: meson: Add driver for the SD/MMC host found on
 Amlogic MesonX SoCs
In-Reply-To: <CAPDyKFpcsKihuOiF5=RwoWrF0Jf7hRsXVSU5uV8qZf1mUsa-iQ@mail.gmail.com>
References: <1448988109-32630-1-git-send-email-carlo@caione.org>
 <CAPDyKFp=buvJ8Li3XC8XSUAUO7BsE+U6vEQH2xTrgcHAkdG8bQ@mail.gmail.com>
 <CAOQ7t2aJAPWd3Xmvu7n0EWL-KC8ZriM3KryfsYEh556uXhuR+g@mail.gmail.com>
 <CAPDyKFpcsKihuOiF5=RwoWrF0Jf7hRsXVSU5uV8qZf1mUsa-iQ@mail.gmail.com>
Message-ID: <CAOQ7t2afXxStCsj=M-FX7eMep1gLt4jkyXDiLas_SQ1UwHc0=Q@mail.gmail.com>

On Tue, Dec 8, 2015 at 9:35 PM, Ulf Hansson <ulf.hansson at linaro.org> wrote:

Hi Ulf,
(old thread, I know)

>> I have actually a problem and a question related to this value. On the
>> boards I'm currently using to test this driver I have no CD GPIO. In
>> this case do I have to specify the MMC as "non-removable"? Also if I
>
> "non-removable" is intended to be used for eMMC or other cards
> (SD/SDIO) that is not possible to remove/insert at runtime.
>
>> try to change an SD card at runtime I have to wait 3 times the timeout
>> before being able to do it successfully.
>
> I guess you are using the "broken-cd" binding, which will enable
> MMC_CAP_NEEDS_POLL and thus the mmc core will poll to detect cards
> being inserted or removed.

I still fail to see what the correct behaviour should be.
Using the v4 of this driver with a "broken-cd" binding and a timeout
of 10s my SD card takes 30s to be identified as removed after I take
it out from the SD slot.
Also, if I take it out and insert it again, I still have to wait 30s
to be able to access it again. Is this a limitation / bug of my driver
or is this the expected behaviour when we do not have a dedicated GPIO
for card detection?

Cheers,

-- 
Carlo Caione


From tony at atomide.com  Mon Feb  1 14:06:58 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Feb 2016 14:06:58 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160201181135.GL19432@atomide.com>
References: <20160126224804.GB19432@atomide.com>
 <CAJZ5v0i79X5JjOZiu4cOZ0Esd5BxAvutF8d17asDzq9ECcML-g@mail.gmail.com>
 <20160126232212.GE19432@atomide.com>
 <CAJZ5v0gTRvyWHVmYNb8Q1QZzhVhokXo541+48mFyDRYv7Hi-Uw@mail.gmail.com>
 <20160126235222.GF19432@atomide.com>
 <CAPDyKFqD6Y6HcgVds_oWBZ8L7Kdh2VX_WZCGApf-1a_6GHCQ5g@mail.gmail.com>
 <20160128165810.GA19432@atomide.com>
 <CAPDyKFoQHpqdCa4fzHycP0OT2KsNTxWm7JZSe8Mauh+rxqGtGg@mail.gmail.com>
 <20160201181135.GL19432@atomide.com>
Message-ID: <20160201220657.GO19432@atomide.com>

* Tony Lindgren <tony at atomide.com> [160201 10:12]:
> * Ulf Hansson <ulf.hansson at linaro.org> [160201 08:45]:
> > On 28 January 2016 at 17:58, Tony Lindgren <tony at atomide.com> wrote:
> > >
> > > The MMC hardware will not get idled properly any longer blocking any
> > > deeper idle states.
> > >
> > >> Did the driver not probe successfully the second try? If so, what happened.
> > >
> > > It probes fine after a -EPROBE_DEFER on the vmmc i2c regulator.
> > > But the PM runtime usecounts are wrong.
> > 
> > Okay. How did you verify this?
> 
> Well that was just based on what I see in the dmesg:
> 
> omap_device: omap_device_enable() called from invalid state 1

So we're now missing the idling of hardare after -EPROBE_DEFER..
Does the following patch work for you guys?

Regards,

Tony

8< -----------------------------
From: Tony Lindgren <tony at atomide.com>
Date: Mon, 1 Feb 2016 13:40:46 -0800
Subject: [PATCH] PM / runtime: Fix PM runtime reinit

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") added calls to reinit the PM runtime. This
however broke things for idling the hardware at least if the driver
probing has pm_runtime_set_autosuspend_delay() and -EPROBE_DEFER
happens.

Fix the problem by adding a check for configured autosuspend if
RPM_ACTIVE is set. Then reset the autosuspend, and suspend the
device to make sure the hardware gets idled.

Let's also cut down one level of nestedness and remove a negative
test by returning early if pm_runtime_enabled(dev) as there is
currently nothing for us to do in that case.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at
probe error and driver unbind")
Signed-off-by: Tony Lindgren <tony at atomide.com>

--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1419,17 +1419,25 @@ void pm_runtime_init(struct device *dev)
  */
 void pm_runtime_reinit(struct device *dev)
 {
-	if (!pm_runtime_enabled(dev)) {
-		if (dev->power.runtime_status == RPM_ACTIVE)
+	if (pm_runtime_enabled(dev))
+		return;
+
+	if (dev->power.runtime_status == RPM_ACTIVE) {
+		if (dev->power.use_autosuspend) {
+			__pm_runtime_use_autosuspend(dev, false);
+			pm_runtime_suspend(dev);
+		} else {
 			pm_runtime_set_suspended(dev);
-		if (dev->power.irq_safe) {
-			spin_lock_irq(&dev->power.lock);
-			dev->power.irq_safe = 0;
-			spin_unlock_irq(&dev->power.lock);
-			if (dev->parent)
-				pm_runtime_put(dev->parent);
 		}
 	}
+
+	if (dev->power.irq_safe) {
+		spin_lock_irq(&dev->power.lock);
+		dev->power.irq_safe = 0;
+		spin_unlock_irq(&dev->power.lock);
+		if (dev->parent)
+			pm_runtime_put(dev->parent);
+	}
 }
 
 /**


From tony at atomide.com  Mon Feb  1 14:11:12 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Feb 2016 14:11:12 -0800
Subject: N900 sleep mode (in 4.5-rc0, if that matters)
In-Reply-To: <20160201211736.GA11283@amd>
References: <20160123121022.GB12497@amd> <20160125163332.GT19432@atomide.com>
 <20160126140010.GA29723@amd> <20160126172527.GY3500@atomide.com>
 <20160130200244.GA30429@amd> <20160130201452.GC30429@amd>
 <20160130221509.GA28644@amd> <20160201181316.GM19432@atomide.com>
 <20160201211736.GA11283@amd>
Message-ID: <20160201221111.GP19432@atomide.com>

* Pavel Machek <pavel at ucw.cz> [160201 13:18]:
> 
> No, sorry, that was with 4.4. As you hit "PM regression with commit
> 5de85b9d57ab PM runtime re-init in v4.5-rc1", I thought I'd avoid
> v4.5-rc. 

OK

> (I assume I have to insmod and rmmod, right? Because powersave is not
> entered if I simply compile-out usb).

Depending on what the bootloader does and probably also if
USB was used during the booting.. So yeah you may need to modprobe
and then rmmod.

> Would you have commit ids for those rmmod fixes? It might be good to
> push them into stable, and I should try again with them applied...

055555fc459 ("usb: musb: core: Fix handling of the phy notifications")
03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable")

Regards,

Tony



From rafael at kernel.org  Mon Feb  1 14:17:54 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 1 Feb 2016 23:17:54 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160201220657.GO19432@atomide.com>
References: <20160126224804.GB19432@atomide.com>
 <CAJZ5v0i79X5JjOZiu4cOZ0Esd5BxAvutF8d17asDzq9ECcML-g@mail.gmail.com>
 <20160126232212.GE19432@atomide.com>
 <CAJZ5v0gTRvyWHVmYNb8Q1QZzhVhokXo541+48mFyDRYv7Hi-Uw@mail.gmail.com>
 <20160126235222.GF19432@atomide.com>
 <CAPDyKFqD6Y6HcgVds_oWBZ8L7Kdh2VX_WZCGApf-1a_6GHCQ5g@mail.gmail.com>
 <20160128165810.GA19432@atomide.com>
 <CAPDyKFoQHpqdCa4fzHycP0OT2KsNTxWm7JZSe8Mauh+rxqGtGg@mail.gmail.com>
 <20160201181135.GL19432@atomide.com>
 <20160201220657.GO19432@atomide.com>
Message-ID: <CAJZ5v0gOtJE24Hu8R9jx7kBktmd__qFUNF_KnsCDLwgidskUvw@mail.gmail.com>

On Mon, Feb 1, 2016 at 11:06 PM, Tony Lindgren <tony at atomide.com> wrote:
> * Tony Lindgren <tony at atomide.com> [160201 10:12]:
>> * Ulf Hansson <ulf.hansson at linaro.org> [160201 08:45]:
>> > On 28 January 2016 at 17:58, Tony Lindgren <tony at atomide.com> wrote:
>> > >
>> > > The MMC hardware will not get idled properly any longer blocking any
>> > > deeper idle states.
>> > >
>> > >> Did the driver not probe successfully the second try? If so, what happened.
>> > >
>> > > It probes fine after a -EPROBE_DEFER on the vmmc i2c regulator.
>> > > But the PM runtime usecounts are wrong.
>> >
>> > Okay. How did you verify this?
>>
>> Well that was just based on what I see in the dmesg:
>>
>> omap_device: omap_device_enable() called from invalid state 1
>
> So we're now missing the idling of hardare after -EPROBE_DEFER..
> Does the following patch work for you guys?
>
> Regards,
>
> Tony
>
> 8< -----------------------------
> From: Tony Lindgren <tony at atomide.com>
> Date: Mon, 1 Feb 2016 13:40:46 -0800
> Subject: [PATCH] PM / runtime: Fix PM runtime reinit
>
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") added calls to reinit the PM runtime. This
> however broke things for idling the hardware at least if the driver
> probing has pm_runtime_set_autosuspend_delay() and -EPROBE_DEFER
> happens.
>
> Fix the problem by adding a check for configured autosuspend if
> RPM_ACTIVE is set. Then reset the autosuspend, and suspend the
> device to make sure the hardware gets idled.
>
> Let's also cut down one level of nestedness and remove a negative
> test by returning early if pm_runtime_enabled(dev) as there is
> currently nothing for us to do in that case.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at
> probe error and driver unbind")
> Signed-off-by: Tony Lindgren <tony at atomide.com>
>
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -1419,17 +1419,25 @@ void pm_runtime_init(struct device *dev)
>   */
>  void pm_runtime_reinit(struct device *dev)
>  {
> -       if (!pm_runtime_enabled(dev)) {
> -               if (dev->power.runtime_status == RPM_ACTIVE)
> +       if (pm_runtime_enabled(dev))
> +               return;
> +
> +       if (dev->power.runtime_status == RPM_ACTIVE) {
> +               if (dev->power.use_autosuspend) {
> +                       __pm_runtime_use_autosuspend(dev, false);
> +                       pm_runtime_suspend(dev);

This won't work, because runtime PM is disabled at this point.

What about doing this instead:

               if (dev->power.use_autosuspend)
                       __pm_runtime_use_autosuspend(dev, false);

               pm_runtime_set_suspended(dev);


> +               } else {
>                         pm_runtime_set_suspended(dev);
> -               if (dev->power.irq_safe) {
> -                       spin_lock_irq(&dev->power.lock);
> -                       dev->power.irq_safe = 0;
> -                       spin_unlock_irq(&dev->power.lock);
> -                       if (dev->parent)
> -                               pm_runtime_put(dev->parent);
>                 }
>         }
> +
> +       if (dev->power.irq_safe) {
> +               spin_lock_irq(&dev->power.lock);
> +               dev->power.irq_safe = 0;
> +               spin_unlock_irq(&dev->power.lock);
> +               if (dev->parent)
> +                       pm_runtime_put(dev->parent);
> +       }
>  }
>
>  /**


From tony at atomide.com  Mon Feb  1 14:29:27 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Feb 2016 14:29:27 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAJZ5v0gOtJE24Hu8R9jx7kBktmd__qFUNF_KnsCDLwgidskUvw@mail.gmail.com>
References: <CAJZ5v0i79X5JjOZiu4cOZ0Esd5BxAvutF8d17asDzq9ECcML-g@mail.gmail.com>
 <20160126232212.GE19432@atomide.com>
 <CAJZ5v0gTRvyWHVmYNb8Q1QZzhVhokXo541+48mFyDRYv7Hi-Uw@mail.gmail.com>
 <20160126235222.GF19432@atomide.com>
 <CAPDyKFqD6Y6HcgVds_oWBZ8L7Kdh2VX_WZCGApf-1a_6GHCQ5g@mail.gmail.com>
 <20160128165810.GA19432@atomide.com>
 <CAPDyKFoQHpqdCa4fzHycP0OT2KsNTxWm7JZSe8Mauh+rxqGtGg@mail.gmail.com>
 <20160201181135.GL19432@atomide.com>
 <20160201220657.GO19432@atomide.com>
 <CAJZ5v0gOtJE24Hu8R9jx7kBktmd__qFUNF_KnsCDLwgidskUvw@mail.gmail.com>
Message-ID: <20160201222926.GQ19432@atomide.com>

* Rafael J. Wysocki <rafael at kernel.org> [160201 14:18]:
> On Mon, Feb 1, 2016 at 11:06 PM, Tony Lindgren <tony at atomide.com> wrote:
> > --- a/drivers/base/power/runtime.c
> > +++ b/drivers/base/power/runtime.c
> > @@ -1419,17 +1419,25 @@ void pm_runtime_init(struct device *dev)
> >   */
> >  void pm_runtime_reinit(struct device *dev)
> >  {
> > -       if (!pm_runtime_enabled(dev)) {
> > -               if (dev->power.runtime_status == RPM_ACTIVE)
> > +       if (pm_runtime_enabled(dev))
> > +               return;
> > +
> > +       if (dev->power.runtime_status == RPM_ACTIVE) {
> > +               if (dev->power.use_autosuspend) {
> > +                       __pm_runtime_use_autosuspend(dev, false);
> > +                       pm_runtime_suspend(dev);
> 
> This won't work, because runtime PM is disabled at this point.

Hmm right OK. It does work from idling the hardware point
of view though..

> What about doing this instead:
> 
>                if (dev->power.use_autosuspend)
>                        __pm_runtime_use_autosuspend(dev, false);
> 
>                pm_runtime_set_suspended(dev);

..while this does not work. The hardware is never idled
in this case.

What else does __pm_runtime_use_autosuspend() set initially
that changes things here?

Regards,

Tony


From sebastian.hesselbarth at gmail.com  Mon Feb  1 14:48:23 2016
From: sebastian.hesselbarth at gmail.com (Sebastian Hesselbarth)
Date: Mon,  1 Feb 2016 23:48:23 +0100
Subject: [PATCH v2] pinctrl: mvebu: fix num_settings in mpp group assignment
In-Reply-To: <1453844952-28292-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1453844952-28292-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <1454366903-7038-1-git-send-email-sebastian.hesselbarth@gmail.com>

When assigning mpp settings from static mpp modes to mpp groups,
we do not want any groups that have no supported setting for a
specific Kirkwood variant. However, when there is at least a
single supported setting, we need to assign the number of all
settings in this mode to grp->num_settings as we are reusing
the static modes table.

Fixes: 0581b16b1840 ("pinctrl: mvebu: complain about missing group after checking variant")
Reported-by: Aaro Koskinen <aaro.koskinen at iki.fi>
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
--
Changelog:
v1->v2:
- Chose a less intrusive fix by adding supp_settings variable
  instead of looping over the settings twice.

Aaro, Linus,

I prefer this less intrusive fix in favor of v1.

@Aaro: Can you please test again?

Cc: Aaro Koskinen <aaro.koskinen at iki.fi>
Cc: Linus Walleij <linus.walleij at linaro.org>
Cc: Gregory Clement <gregory.clement at free-electrons.com>
Cc: Andrew Lunn <andrew at lunn.ch>
Cc: linux-arm-kernel at lists.infradead.org
---
 drivers/pinctrl/mvebu/pinctrl-mvebu.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
index e4d473811bb3..3ef798fac81b 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -666,16 +666,19 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
 		struct mvebu_mpp_ctrl_setting *set = &mode->settings[0];
 		struct mvebu_pinctrl_group *grp;
 		unsigned num_settings;
+		unsigned supp_settings;
 
-		for (num_settings = 0; ; set++) {
+		for (num_settings = 0, supp_settings = 0; ; set++) {
 			if (!set->name)
 				break;
 
+			num_settings++;
+
 			/* skip unsupported settings for this variant */
 			if (pctl->variant && !(pctl->variant & set->variant))
 				continue;
 
-			num_settings++;
+			supp_settings++;
 
 			/* find gpio/gpo/gpi settings */
 			if (strcmp(set->name, "gpio") == 0)
@@ -688,7 +691,7 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
 		}
 
 		/* skip modes with no settings for this variant */
-		if (!num_settings)
+		if (!supp_settings)
 			continue;
 
 		grp = mvebu_pinctrl_find_group_by_pid(pctl, mode->pid);
-- 
2.1.4



From andre.przywara at arm.com  Mon Feb  1 14:49:16 2016
From: andre.przywara at arm.com (=?UTF-8?Q?Andr=c3=a9_Przywara?=)
Date: Mon, 1 Feb 2016 22:49:16 +0000
Subject: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
In-Reply-To: <20160201182754.GA14737@excalibur.cnev.de>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-6-git-send-email-andre.przywara@arm.com>
 <20160201182754.GA14737@excalibur.cnev.de>
Message-ID: <56AFE0EC.8080207@arm.com>

On 01/02/16 18:27, Karsten Merker wrote:

Hi Karsten,

thank you very much for your feedback!

> On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote:
>> Based on the Allwinner A64 user manual and on the previous sunxi
>> pinctrl drivers this introduces the pin multiplex assignments for
>> the ARMv8 Allwinner A64 SoC.
>> Port A is apparently used for the fixed function DRAM controller, so
>> the ports start at B here (the manual mentions "n from 1 to 7", so
>> not starting at 0).
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>> ---
>>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
>>  arch/arm64/Kconfig.platforms                       |   1 +
>>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
>>  drivers/pinctrl/sunxi/Makefile                     |   1 +
>>  drivers/pinctrl/sunxi/pinctrl-a64.c                | 606 +++++++++++++++++++++
>>  5 files changed, 613 insertions(+)
>>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c
>>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>> index 9213b27..9050002 100644
>> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>> @@ -21,6 +21,7 @@ Required properties:
>>    "allwinner,sun9i-a80-r-pinctrl"
>>    "allwinner,sun8i-a83t-pinctrl"
>>    "allwinner,sun8i-h3-pinctrl"
>> +  "allwinner,a64-pinctrl"
> 
> Hello,
> 
> on all other Allwinner SoCs we use the SoC family as part of the
> compatible, as well as in the names of the Kconfig options. To
> keep things consistent, I would like to propose doing the same on
> Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of
> allwinner,a64-pinctrl.

Yes, I have been told this already. However I don't like this idea so
much, for the following reasons:
a) It is mostly redundant. The actual SoC (marketing) name is unique,
there is no sun6i-a20 or sun7i-a23.
b) It is not even helpful. If I got Maxime correctly, then the newer
sunxi generation numbers depend on the ARM _cores_ used in the SoC,
which is frankly the least interesting part from a Linux support
perspective. I would see some sense if it would reflect the generation
of IP blocks used, but so it is even more confusing to see that
sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely
different beast. The Allwinner marketing name tells you that, but the
sunxi one does not.
c) It is very confusing for people not dealing with it everyday. Just
because I own a BananaPi I know that the A20 is sun7i, but I am totally
lost when it comes to all the other names. And even now it took me about
a minute to find the appropriate Wiki page which explains part of that
story.
d) Most importantly ;-): It kills TAB completion, unless you know the
sunxi number, which is mostly not true as pointed out in c)

So while I see that just a<somenumber> is not really very specific, I'd
rather do away with current naming scheme for the future. In this
particular case we have the vendor name as a name space identifier
already, so there is no possible confusion with ARM Cortex naming, for
instance.

Also as this is now moving into the arm64 world, I'd like to use the
opportunity to fix things that are not really optimal, the naming is one
of them.

>>  - reg: Should contain the register physical address and length for the
>>    pin controller.
>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>> index fc7cf4b..03f0f9d 100644
>> --- a/arch/arm64/Kconfig.platforms
>> +++ b/arch/arm64/Kconfig.platforms
>> @@ -2,6 +2,7 @@ menu "Platform selection"
>>  
>>  config ARCH_SUNXI
>>  	bool "Allwinner sunxi 64-bit SoC Family"
>> +	select PINCTRL_A64
> 
> Same as above, just with the name of the Kconfig option.
> s/PINCTRL_A64/PINCTRL_SUN50I_A64/ ?

I can see the reasoning behind this particular one, as A64 is not very
specific. And indeed I had planned to replace this, but forgot it over
merging all the stuff together. However I'd rather go with the generic
"sunxi" as a stub name (PINCTRL_SUNXI_A64), as the "50" in there is now
completely stupi^Wconfusing and also kills my favorite sun.i regexp ;-)
I can see that the term "sunxi" is a shorthand for Allwinner in Linux,
so it looks reasonable to me to use that.

>>  	select SUNXI_MMC
>>  	help
>>  	  This enables support for Allwinner sunxi based SoCs like the A64.
>> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
>> index f8dbc8b..68873f2 100644
>> --- a/drivers/pinctrl/sunxi/Kconfig
>> +++ b/drivers/pinctrl/sunxi/Kconfig
>> @@ -64,4 +64,8 @@ config PINCTRL_SUN9I_A80_R
>>  	depends on RESET_CONTROLLER
>>  	select PINCTRL_SUNXI_COMMON
>>  
>> +config PINCTRL_A64
> 
> see above
> 
>> +	bool
>> +	select PINCTRL_SUNXI_COMMON
>> +
>>  endif
>> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
>> index ef82f22..e00ccde 100644
>> --- a/drivers/pinctrl/sunxi/Makefile
>> +++ b/drivers/pinctrl/sunxi/Makefile
>> @@ -12,6 +12,7 @@ obj-$(CONFIG_PINCTRL_SUN7I_A20)		+= pinctrl-sun7i-a20.o
>>  obj-$(CONFIG_PINCTRL_SUN8I_A23)		+= pinctrl-sun8i-a23.o
>>  obj-$(CONFIG_PINCTRL_SUN8I_A23_R)	+= pinctrl-sun8i-a23-r.o
>>  obj-$(CONFIG_PINCTRL_SUN8I_A33)		+= pinctrl-sun8i-a33.o
>> +obj-$(CONFIG_PINCTRL_A64)		+= pinctrl-a64.o
> 
> see above

same as above, I'd like to go with pinctrl-sunxi-a64.o.

>>  obj-$(CONFIG_PINCTRL_SUN8I_A83T)	+= pinctrl-sun8i-a83t.o
>>  obj-$(CONFIG_PINCTRL_SUN8I_H3)		+= pinctrl-sun8i-h3.o
>>  obj-$(CONFIG_PINCTRL_SUN9I_A80)		+= pinctrl-sun9i-a80.o
>> diff --git a/drivers/pinctrl/sunxi/pinctrl-a64.c b/drivers/pinctrl/sunxi/pinctrl-a64.c
>> new file mode 100644
>> index 0000000..e72b079
>> --- /dev/null
>> +++ b/drivers/pinctrl/sunxi/pinctrl-a64.c
>> @@ -0,0 +1,606 @@
>> +/*
>> + * Allwinner A64 SoCs pinctrl driver.
>> + *
>> + * Copyright (C) 2016 - ARM Ltd.
>> + * Author: Andre Przywara <andre.przywara at arm.com>
>> + *
>> + * Based on pinctrl-sun7i-a20.c, which is:
>> + * Copyright (C) 2014 Maxime Ripard <maxime.ripard at free-electrons.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2.  This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/pinctrl/pinctrl.h>
>> +
>> +#include "pinctrl-sunxi.h"
>> +
>> +static const struct sunxi_desc_pin a64_pins[] = {
>> +	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 0),
>> +		  SUNXI_FUNCTION(0x0, "gpio_in"),
>> +		  SUNXI_FUNCTION(0x1, "gpio_out"),

....

>> +		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 11)),	/* EINT11 */
>> +};
>> +
>> +static const struct sunxi_pinctrl_desc a64_pinctrl_data = {
>> +	.pins = a64_pins,
>> +	.npins = ARRAY_SIZE(a64_pins),
>> +	.irq_banks = 3,
>> +};
>> +
>> +static int a64_pinctrl_probe(struct platform_device *pdev)
>> +{
>> +	return sunxi_pinctrl_init(pdev,
>> +				  &a64_pinctrl_data);
>> +}
>> +
>> +static const struct of_device_id a64_pinctrl_match[] = {
>> +	{ .compatible = "allwinner,a64-pinctrl", },
>> +	{}
>> +};
>> +MODULE_DEVICE_TABLE(of, a64_pinctrl_match);
>> +
>> +static struct platform_driver a64_pinctrl_driver = {
>> +	.probe	= a64_pinctrl_probe,
>> +	.driver	= {
>> +		.name		= "a64-pinctrl",
>> +		.of_match_table	= a64_pinctrl_match,
>> +	},
>> +};
>> +module_platform_driver(a64_pinctrl_driver);
>> +
>> +MODULE_AUTHOR("Andre Przywara <andre.przywara at arm.com>");
>> +MODULE_DESCRIPTION("Allwinner A64 pinctrl driver");
>> +MODULE_LICENSE("GPL");
> 
> For the above function names one could also think about using the
> existing naming scheme including the SoC family as we do in the
> other sunxi pinctrl drivers, but as they are only internal to the
> driver, that would really just be a matter of cosmetics :-).

Indeed ;-) And it is more to type and may potentially break 80 character
lines, so if you don't mind, I keep it that way (or could add a "sunxi_"
if that is really asked for).

Thanks for looking at this and your input!

Cheers,
Andre.



From andre.przywara at arm.com  Mon Feb  1 15:01:44 2016
From: andre.przywara at arm.com (=?UTF-8?Q?Andr=c3=a9_Przywara?=)
Date: Mon, 1 Feb 2016 23:01:44 +0000
Subject: [PATCH 06/11] clk: sunxi: add generic multi-parent bus clock
 gates driver
In-Reply-To: <20160201194000.282a253b14a2ab35df8b8cc7@free.fr>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-7-git-send-email-andre.przywara@arm.com>
 <20160201194000.282a253b14a2ab35df8b8cc7@free.fr>
Message-ID: <56AFE3D8.1000701@arm.com>

On 01/02/16 18:40, Jean-Francois Moine wrote:
> On Mon,  1 Feb 2016 17:39:25 +0000
> Andre Przywara <andre.przywara at arm.com> wrote:
> 
>> The Allwinner H3 SoC introduced bus clock gates with potentially
>> different parents per clock gate. The H3 driver chose to hardcode the
>> actual parent clock relation in the code.
>> Add a new driver (which has the potential to drive the H3 and also
>> the simple clock gates as well) which uses the power of DT to describe
>> this relationship in an elegant and flexible way.
>> Using one subnode for every parent clock we get away with a single
>> DT compatible match, which can be used as a fallback value in the
>> actual DTs without the need to add specific compatible strings to the
>> code.  This avoids adding a new driver or function for every new SoC.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>> ---
>> Changelog RFC .. v1:
>> - fix IRQ muxes to cover the three banks of the SoC
>> - amend naming of PCM pins

Just got embarrassed with seeing that this changelog here actually
belongs into the previous patch :$

>>
>>  drivers/clk/sunxi/Makefile          |   1 +
>>  drivers/clk/sunxi/clk-multi-gates.c | 105 ++++++++++++++++++++++++++++++++++++
>>  2 files changed, 106 insertions(+)
>>  create mode 100644 drivers/clk/sunxi/clk-multi-gates.c
> 	[snip]
> 
> Glad to see that things are moving to the right way. Thanks.

> Acked-by: Jean-Francois Moine <moinejf at free.fr>

Thanks! I am relived to hear that (and hope that others agree as well
;-) If people are Ok with that approach I can do patches to move all
existing clock gates into one driver, but I guess this would be part of
a later series.

Cheers,
Andre.



From andre.przywara at arm.com  Mon Feb  1 15:02:15 2016
From: andre.przywara at arm.com (=?UTF-8?Q?Andr=c3=a9_Przywara?=)
Date: Mon, 1 Feb 2016 23:02:15 +0000
Subject: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for
 Allwinner A64 SoC
In-Reply-To: <20160201184505.GB14737@excalibur.cnev.de>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-6-git-send-email-andre.przywara@arm.com>
 <20160201182754.GA14737@excalibur.cnev.de>
 <20160201184505.GB14737@excalibur.cnev.de>
Message-ID: <56AFE3F7.6050204@arm.com>

On 01/02/16 18:45, Karsten Merker wrote:
> Hello,
> 
> I by mistake pressed "send" on my previous mail when I intended
> to further edit it, so here comes a followup.
> I definitely need more coffee ;-).

Or less?  ;-)             vvvvvvvvvv Thinking of twitchy fingers...
> On Mon, Feb 01, 2016 at 07:27:54PM +0100, Karsten Merker wrote:
>> On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote:
> 
>>> +static const struct sunxi_pinctrl_desc a64_pinctrl_data = {
>>> +	.pins = a64_pins,
>>> +	.npins = ARRAY_SIZE(a64_pins),
>>> +	.irq_banks = 3,
>>> +};
>>> +
>>> +static int a64_pinctrl_probe(struct platform_device *pdev)
>>> +{
>>> +	return sunxi_pinctrl_init(pdev,
>>> +				  &a64_pinctrl_data);
>>> +}
>>> +
>>> +static const struct of_device_id a64_pinctrl_match[] = {
>>> +	{ .compatible = "allwinner,a64-pinctrl", },
> 
> s/allwinner,a64-pinctrl/allwinner,sun50i-a64-pinctrl/ ?

As mentioned in the other mail, allwinner should be enough to make the
naming unique. Especially as this is about DT namings, which should be
valid outside of the Linux world even.

Cheers,
Andre.

> 
>>> +	{}
>>> +};
>>> +MODULE_DEVICE_TABLE(of, a64_pinctrl_match);
>>> +
>>> +static struct platform_driver a64_pinctrl_driver = {
>>> +	.probe	= a64_pinctrl_probe,
>>> +	.driver	= {
>>> +		.name		= "a64-pinctrl",
>>> +		.of_match_table	= a64_pinctrl_match,
>>> +	},
>>> +};
>>> +module_platform_driver(a64_pinctrl_driver);
>>> +
>>> +MODULE_AUTHOR("Andre Przywara <andre.przywara at arm.com>");
>>> +MODULE_DESCRIPTION("Allwinner A64 pinctrl driver");
>>> +MODULE_LICENSE("GPL");
>>
>> For the above function names one could also think about using the
> 
> s/function names/variable definitions/
> 
>> existing naming scheme including the SoC family as we do in the
>> other sunxi pinctrl drivers, but as they are only internal to the
>> driver, that would really just be a matter of cosmetics :-).
> 
> Regards,
> Karsten
> 



From andre.przywara at arm.com  Mon Feb  1 15:03:45 2016
From: andre.przywara at arm.com (=?UTF-8?Q?Andr=c3=a9_Przywara?=)
Date: Mon, 1 Feb 2016 23:03:45 +0000
Subject: [linux-sunxi] [PATCH 10/11] arm64: dts: add Allwinner A64 SoC
 .dtsi
In-Reply-To: <20160201190521.GC14737@excalibur.cnev.de>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-11-git-send-email-andre.przywara@arm.com>
 <20160201190521.GC14737@excalibur.cnev.de>
Message-ID: <56AFE451.6080108@arm.com>

On 01/02/16 19:05, Karsten Merker wrote:
> Hello,
> 
> a few tiny spelling nitpicks in case you should do a V2:

Definitely! ;-)

> 
> On Mon, Feb 01, 2016 at 05:39:29PM +0000, Andre Przywara wrote:
> 
>> The Allwinner A64 SoC is low-cost SoC with 4 ARM Cortex-A53 cores
> 
> s/is low-cost SoC/is a low-cost SoC/
>                          
>> and the typical tablet / TV box peripherals.
>> The Soc is based on the (32-bit) Allwinner H3 chip, sharing most of
> 
> s/Soc/SoC/

Thanks for catching those!

>> the peripherals and the memory map.
>> Although the cores are proper 64-bit ones, the whole SoC is actually
>> limited to 4GB (including all the supported DRAM), so we use 32-bit
>> address and size cells. This has the nice feature of us being able to
>> reuse the DT for 32-bit kernels as well.
>> This .dtsi lists the hardware that we support so far.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>> ---
>>  Documentation/devicetree/bindings/arm/sunxi.txt   |   1 +
>>  Documentation/devicetree/bindings/clock/sunxi.txt |   1 +
>>  arch/arm64/boot/dts/allwinner/a64.dtsi            | 583 ++++++++++++++++++++++
>>  3 files changed, 585 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/allwinner/a64.dtsi
>>
>> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
>> index 980e065..4a83853 100644
>> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
>> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
>> @@ -14,6 +14,7 @@ using one of the following compatible strings:
>>    allwinner,sun8i-a83t
>>    allwinner,sun8i-h3
>>    allwinner,sun9i-a80
>> +  allwinner,a64
> 
> Please see my followup to patch No. 5 in this series.
> s/allwinner,a64/allwinner,sun50i-a64/ ?

As explained in the first email, rather not, especially if it is about
DT namings.

>>  
>>  For Allwinner SoCs without any specific needs the generic fallback value of:
>>    allwinner,sunxi
>> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
>> index e59f57b..44b0c6c 100644
>> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
>> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
>> @@ -77,6 +77,7 @@ Required properties:
>>  	"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
>>  	"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
>>  	"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
>> +	"allwinner,a64-bus-gates-clk" - for the A64 multi-parent bus gates clock
> 
> see above
> 
>>  
>>  Required properties for all clocks:
>>  - reg : shall be the control register address for the clock.
>> diff --git a/arch/arm64/boot/dts/allwinner/a64.dtsi b/arch/arm64/boot/dts/allwinner/a64.dtsi
> 
> see above - the dts and dtsi names for the other Allwinner SoCs contain
> the SoC family. 

... mostly because the arm DTs are all in one directory, and just some
a<xx>.dtsi is then indeed not very specific. But arm64 fortunately has
per-vendor directories, so things are pretty well separated. If a64.dtsi
is deemed too short, I could call it allwinner_a64.dtsi or maybe
sunxi_a64.dtsi, but I'd rather avoid sun50i-a64.dtsi.
Also looking at the other arm64 DTs I see a lot of short names, just
using the (marketing) chip name as the stub.

Similar reasoning for the other occurrences below.

Cheers,
Andre.

>> new file mode 100644
>> index 0000000..8dce10f
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/a64.dtsi
>> @@ -0,0 +1,583 @@
>> +/*
>> + * Copyright (C) 2016 ARM Ltd.
>> + * based on the Allwinner H3 dtsi:
>> + *    Copyright (C) 2015 Jens Kuske <jenskuske at gmail.com>
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This file is free software; you can redistribute it and/or
>> + *     modify it under the terms of the GNU General Public License as
>> + *     published by the Free Software Foundation; either version 2 of the
>> + *     License, or (at your option) any later version.
>> + *
>> + *     This file is distributed in the hope that it will be useful,
>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *     GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + *     obtaining a copy of this software and associated documentation
>> + *     files (the "Software"), to deal in the Software without
>> + *     restriction, including without limitation the rights to use,
>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>> + *     sell copies of the Software, and to permit persons to whom the
>> + *     Software is furnished to do so, subject to the following
>> + *     conditions:
>> + *
>> + *     The above copyright notice and this permission notice shall be
>> + *     included in all copies or substantial portions of the Software.
>> + *
>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + *     OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>> +
>> +/ {
>> +	compatible = "allwinner,a64", "allwinner,sunxi";
> 
> see above
> 
>> +	interrupt-parent = <&gic>;
>> +	#address-cells = <1>;
>> +	#size-cells = <1>;
>> +
>> +	aliases {
>> +		serial0 = &uart0;
>> +		serial1 = &uart1;
>> +		serial2 = &uart2;
>> +		serial3 = &uart3;
>> +		serial4 = &uart4;
>> +	};
>> +
>> +	cpus {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		cpu at 0 {
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			device_type = "cpu";
>> +			reg = <0>;
>> +			enable-method = "psci";
>> +		};
>> +
>> +		cpu at 1 {
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			device_type = "cpu";
>> +			reg = <1>;
>> +			enable-method = "psci";
>> +		};
>> +
>> +		cpu at 2 {
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			device_type = "cpu";
>> +			reg = <2>;
>> +			enable-method = "psci";
>> +		};
>> +
>> +		cpu at 3 {
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			device_type = "cpu";
>> +			reg = <3>;
>> +			enable-method = "psci";
>> +		};
>> +	};
>> +
>> +	psci {
>> +		compatible = "arm,psci-0.2", "arm,psci";
>> +		method = "smc";
>> +		cpu_suspend = <0xc4000001>;
>> +		cpu_off = <0x84000002>;
>> +		cpu_on = <0xc4000003>;
>> +	};
>> +
>> +	memory {
>> +		device_type = "memory";
>> +		reg = <0x40000000 0>;
>> +	};
>> +
>> +	timer {
>> +		compatible = "arm,armv8-timer";
>> +		interrupts = <GIC_PPI 13
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			     <GIC_PPI 14
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			     <GIC_PPI 11
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			     <GIC_PPI 10
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>> +	};
>> +
>> +	clocks {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		ranges;
>> +
>> +		osc24M: osc24M_clk {
>> +			#clock-cells = <0>;
>> +			compatible = "fixed-clock";
>> +			clock-frequency = <24000000>;
>> +			clock-output-names = "osc24M";
>> +		};
>> +
>> +		osc32k: osc32k_clk {
>> +			#clock-cells = <0>;
>> +			compatible = "fixed-clock";
>> +			clock-frequency = <32768>;
>> +			clock-output-names = "osc32k";
>> +		};
>> +
>> +		pll1: clk at 01c20000 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun8i-a23-pll1-clk";
>> +			reg = <0x01c20000 0x4>;
>> +			clocks = <&osc24M>;
>> +			clock-output-names = "pll1";
>> +		};
>> +
>> +		pll6: clk at 01c20028 {
>> +			#clock-cells = <1>;
>> +			compatible = "allwinner,sun6i-a31-pll6-clk";
>> +			reg = <0x01c20028 0x4>;
>> +			clocks = <&osc24M>;
>> +			clock-output-names = "pll6", "pll6x2";
>> +		};
>> +
>> +		pll6d2: pll6d2_clk {
>> +			#clock-cells = <0>;
>> +			compatible = "fixed-factor-clock";
>> +			clock-div = <2>;
>> +			clock-mult = <1>;
>> +			clocks = <&pll6 0>;
>> +			clock-output-names = "pll6d2";
>> +		};
>> +
>> +		/* dummy clock until pll6 can be reused */
>> +		pll8: pll8_clk {
>> +			#clock-cells = <0>;
>> +			compatible = "fixed-clock";
>> +			clock-frequency = <1>;
>> +			clock-output-names = "pll8";
>> +		};
>> +
>> +		cpu: cpu_clk at 01c20050 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun4i-a10-cpu-clk";
>> +			reg = <0x01c20050 0x4>;
>> +			clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
>> +			clock-output-names = "cpu";
>> +			critical-clocks = <0>;
>> +		};
>> +
>> +		axi: axi_clk at 01c20050 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun4i-a10-axi-clk";
>> +			reg = <0x01c20050 0x4>;
>> +			clocks = <&cpu>;
>> +			clock-output-names = "axi";
>> +		};
>> +
>> +		ahb1: ahb1_clk at 01c20054 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun6i-a31-ahb1-clk";
>> +			reg = <0x01c20054 0x4>;
>> +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
>> +			clock-output-names = "ahb1";
>> +		};
>> +
>> +		ahb2: ahb2_clk at 01c2005c {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun8i-h3-ahb2-clk";
>> +			reg = <0x01c2005c 0x4>;
>> +			clocks = <&ahb1>, <&pll6d2>;
>> +			clock-output-names = "ahb2";
>> +		};
>> +
>> +		apb1: apb1_clk at 01c20054 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun4i-a10-apb0-clk";
>> +			reg = <0x01c20054 0x4>;
>> +			clocks = <&ahb1>;
>> +			clock-output-names = "apb1";
>> +		};
>> +
>> +		apb2: apb2_clk at 01c20058 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun4i-a10-apb1-clk";
>> +			reg = <0x01c20058 0x4>;
>> +			clocks = <&osc32k>, <&osc24M>, <&pll6 1>, <&pll6 1>;
>> +			clock-output-names = "apb2";
>> +		};
>> +
>> +		bus_gates: clk at 01c20060 {
>> +			#clock-cells = <1>;
>> +			compatible = "allwinner,a64-bus-gates-clk",
> 
> see above
> 
>> +				     "allwinner,sunxi-multi-bus-gates-clk";
>> +			reg = <0x01c20060 0x14>;
>> +			ahb1_parent {
>> +				clocks = <&ahb1>;
>> +				clock-indices = <1>, <5>,
>> +						<6>, <8>,
>> +						<9>, <10>,
>> +						<13>, <14>,
>> +						<18>, <19>,
>> +						<20>, <21>,
>> +						<23>, <24>,
>> +						<25>, <28>,
>> +						<32>, <35>,
>> +						<36>, <37>,
>> +						<40>, <43>,
>> +						<44>, <52>,
>> +						<53>, <54>,
>> +						<135>;
>> +				clock-output-names = "bus_mipidsi", "bus_ce",
>> +						"bus_dma", "bus_mmc0",
>> +						"bus_mmc1", "bus_mmc2",
>> +						"bus_nand", "bus_sdram",
>> +						"bus_ts", "bus_hstimer",
>> +						"bus_spi0", "bus_spi1",
>> +						"bus_otg", "bus_otg_ehci0",
>> +						"bus_ehci0", "bus_otg_ohci0",
>> +						"bus_ve", "bus_lcd0",
>> +						"bus_lcd1", "bus_deint",
>> +						"bus_csi", "bus_hdmi",
>> +						"bus_de", "bus_gpu",
>> +						"bus_msgbox", "bus_spinlock",
>> +						"bus_dbg";
>> +			};
>> +			ahb2_parent {
>> +				clocks = <&ahb2>;
>> +				clock-indices = <17>, <29>;
>> +				clock-output-names = "bus_gmac", "bus_ohci0";
>> +			};
>> +			apb1_parent {
>> +				clocks = <&apb1>;
>> +				clock-indices = <64>, <65>,
>> +						<69>, <72>,
>> +						<76>, <77>,
>> +						<78>;
>> +				clock-output-names = "bus_codec", "bus_spdif",
>> +						"bus_pio", "bus_ths",
>> +						"bus_i2s0", "bus_i2s1",
>> +						"bus_i2s2";
>> +			};
>> +			abp2_parent {
>> +				clocks = <&apb2>;
>> +				clock-indices = <96>, <97>,
>> +						<98>, <101>,
>> +						<112>, <113>,
>> +						<114>, <115>,
>> +						<116>;
>> +				clock-output-names = "bus_i2c0", "bus_i2c1",
>> +						"bus_i2c2", "bus_scr",
>> +						"bus_uart0", "bus_uart1",
>> +						"bus_uart2", "bus_uart3",
>> +						"bus_uart4";
>> +			};
>> +		};
>> +
>> +		mmc0_clk: clk at 01c20088 {
>> +			#clock-cells = <1>;
>> +			compatible = "allwinner,sun4i-a10-mmc-clk";
>> +			reg = <0x01c20088 0x4>;
>> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>> +			clock-output-names = "mmc0",
>> +					     "mmc0_output",
>> +					     "mmc0_sample";
>> +		};
>> +
>> +		mmc1_clk: clk at 01c2008c {
>> +			#clock-cells = <1>;
>> +			compatible = "allwinner,sun4i-a10-mmc-clk";
>> +			reg = <0x01c2008c 0x4>;
>> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>> +			clock-output-names = "mmc1",
>> +					     "mmc1_output",
>> +					     "mmc1_sample";
>> +		};
>> +
>> +		mmc2_clk: clk at 01c20090 {
>> +			#clock-cells = <1>;
>> +			compatible = "allwinner,sun4i-a10-mmc-clk";
>> +			reg = <0x01c20090 0x4>;
>> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>> +			clock-output-names = "mmc2",
>> +					     "mmc2_output",
>> +					     "mmc2_sample";
>> +		};
>> +	};
>> +
>> +	regulators {
>> +		reg_vcc3v3: vcc3v3 {
>> +			compatible = "regulator-fixed";
>> +			regulator-name = "vcc3v3";
>> +			regulator-min-microvolt = <3300000>;
>> +			regulator-max-microvolt = <3300000>;
>> +		};
>> +	};
>> +
>> +	soc {
>> +		compatible = "simple-bus";
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		ranges;
>> +
>> +		mmc0: mmc at 01c0f000 {
>> +			compatible = "allwinner,sun5i-a13-mmc";
>> +			reg = <0x01c0f000 0x1000>;
>> +			clocks = <&bus_gates 8>,
>> +				 <&mmc0_clk 0>,
>> +				 <&mmc0_clk 1>,
>> +				 <&mmc0_clk 2>;
>> +			clock-names = "ahb",
>> +				      "mmc",
>> +				      "output",
>> +				      "sample";
>> +			resets = <&ahb_rst 8>;
>> +			reset-names = "ahb";
>> +			interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
>> +			status = "disabled";
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +		};
>> +
>> +		mmc1: mmc at 01c10000 {
>> +			compatible = "allwinner,sun5i-a13-mmc";
>> +			reg = <0x01c10000 0x1000>;
>> +			clocks = <&bus_gates 9>,
>> +				 <&mmc1_clk 0>,
>> +				 <&mmc1_clk 1>,
>> +				 <&mmc1_clk 2>;
>> +			clock-names = "ahb",
>> +				      "mmc",
>> +				      "output",
>> +				      "sample";
>> +			resets = <&ahb_rst 9>;
>> +			reset-names = "ahb";
>> +			interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
>> +			status = "disabled";
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +		};
>> +
>> +		mmc2: mmc at 01c11000 {
>> +			compatible = "allwinner,sun5i-a13-mmc";
>> +			reg = <0x01c11000 0x1000>;
>> +			clocks = <&bus_gates 10>,
>> +				 <&mmc2_clk 0>,
>> +				 <&mmc2_clk 1>,
>> +				 <&mmc2_clk 2>;
>> +			clock-names = "ahb",
>> +				      "mmc",
>> +				      "output",
>> +				      "sample";
>> +			resets = <&ahb_rst 10>;
>> +			reset-names = "ahb";
>> +			interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
>> +			status = "disabled";
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +		};
>> +
>> +		pio: pinctrl at 01c20800 {
>> +			compatible = "allwinner,a64-pinctrl";
> 
> see above
> 
>> +			reg = <0x01c20800 0x400>;
>> +			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
>> +			clocks = <&bus_gates 69>;
>> +			gpio-controller;
>> +			#gpio-cells = <3>;
>> +			interrupt-controller;
>> +			#interrupt-cells = <2>;
>> +
>> +			uart0_pins_a: uart0 at 0 {
>> +				allwinner,pins = "PB8", "PB9";
>> +				allwinner,function = "uart0";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart0_pins_b: uart0 at 1 {
>> +				allwinner,pins = "PF2", "PF3";
>> +				allwinner,function = "uart0";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart1_pins: uart1 at 0 {
>> +				allwinner,pins = "PG6", "PG7", "PG8", "PG9";
>> +				allwinner,function = "uart1";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart2_pins: uart2 at 0 {
>> +				allwinner,pins = "PB0", "PB1", "PB2", "PB3";
>> +				allwinner,function = "uart2";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart3_pins_a: uart3 at 0 {
>> +				allwinner,pins = "PD0", "PD1";
>> +				allwinner,function = "uart3";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart3_pins_b: uart3 at 1 {
>> +				allwinner,pins = "PH4", "PH5", "PH6", "PH7";
>> +				allwinner,function = "uart3";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart4_pins: uart4 at 0 {
>> +				allwinner,pins = "PD2", "PD3", "PD4", "PD5";
>> +				allwinner,function = "uart4";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			mmc0_pins: mmc0 at 0 {
>> +				allwinner,pins = "PF0", "PF1", "PF2", "PF3",
>> +						 "PF4", "PF5";
>> +				allwinner,function = "mmc0";
>> +				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			mmc0_default_cd_pin: mmc0_cd_pin at 0 {
>> +				allwinner,pins = "PF6";
>> +				allwinner,function = "gpio_in";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>> +			};
>> +
>> +			mmc1_pins: mmc1 at 0 {
>> +				allwinner,pins = "PG0", "PG1", "PG2", "PG3",
>> +						 "PG4", "PG5";
>> +				allwinner,function = "mmc1";
>> +				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			mmc2_pins: mmc2 at 0 {
>> +				allwinner,pins = "PC1", "PC5", "PC6", "PC8",
>> +						 "PC9", "PC10";
>> +				allwinner,function = "mmc2";
>> +				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +		};
>> +
>> +		ahb_rst: reset at 01c202c0 {
>> +			#reset-cells = <1>;
>> +			compatible = "allwinner,sun6i-a31-ahb1-reset";
>> +			reg = <0x01c202c0 0xc>;
>> +		};
>> +
>> +		apb1_rst: reset at 01c202d0 {
>> +			#reset-cells = <1>;
>> +			compatible = "allwinner,sun6i-a31-clock-reset";
>> +			reg = <0x01c202d0 0x4>;
>> +		};
>> +
>> +		apb2_rst: reset at 01c202d8 {
>> +			#reset-cells = <1>;
>> +			compatible = "allwinner,sun6i-a31-clock-reset";
>> +			reg = <0x01c202d8 0x4>;
>> +		};
>> +
>> +		uart0: serial at 01c28000 {
>> +			compatible = "snps,dw-apb-uart";
>> +			reg = <0x01c28000 0x400>;
>> +			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
>> +			reg-shift = <2>;
>> +			reg-io-width = <4>;
>> +			clocks = <&bus_gates 112>;
>> +			resets = <&apb2_rst 16>;
>> +			reset-names = "apb2";
>> +			status = "disabled";
>> +		};
>> +
>> +		uart1: serial at 01c28400 {
>> +			compatible = "snps,dw-apb-uart";
>> +			reg = <0x01c28400 0x400>;
>> +			interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
>> +			reg-shift = <2>;
>> +			reg-io-width = <4>;
>> +			clocks = <&bus_gates 113>;
>> +			resets = <&apb2_rst 17>;
>> +			reset-names = "apb2";
>> +			status = "disabled";
>> +		};
>> +
>> +		uart2: serial at 01c28800 {
>> +			compatible = "snps,dw-apb-uart";
>> +			reg = <0x01c28800 0x400>;
>> +			interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
>> +			reg-shift = <2>;
>> +			reg-io-width = <4>;
>> +			clocks = <&bus_gates 114>;
>> +			resets = <&apb2_rst 18>;
>> +			reset-names = "apb2";
>> +			status = "disabled";
>> +		};
>> +
>> +		uart3: serial at 01c28c00 {
>> +			compatible = "snps,dw-apb-uart";
>> +			reg = <0x01c28c00 0x400>;
>> +			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
>> +			reg-shift = <2>;
>> +			reg-io-width = <4>;
>> +			clocks = <&bus_gates 115>;
>> +			resets = <&apb2_rst 19>;
>> +			reset-names = "apb2";
>> +			status = "disabled";
>> +		};
>> +
>> +		uart4: serial at 01c29000 {
>> +			compatible = "snps,dw-apb-uart";
>> +			reg = <0x01c29000 0x400>;
>> +			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
>> +			reg-shift = <2>;
>> +			reg-io-width = <4>;
>> +			clocks = <&bus_gates 116>;
>> +			resets = <&apb2_rst 20>;
>> +			reset-names = "apb2";
>> +			status = "disabled";
>> +		};
>> +
>> +		rtc: rtc at 01f00000 {
>> +			compatible = "allwinner,sun6i-a31-rtc";
>> +			reg = <0x01f00000 0x54>;
>> +			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
>> +		};
>> +	};
>> +
>> +	gic: interrupt-controller@{
>> +		compatible = "arm,gic-400";
>> +		interrupt-controller;
>> +		#interrupt-cells = <3>;
>> +		#address-cells = <0>;
>> +
>> +		reg = <0x01C81000 0x1000>,
>> +		      <0x01C82000 0x2000>,
>> +		      <0x01C84000 0x2000>,
>> +		      <0x01C86000 0x2000>;
>> +		interrupts = <GIC_PPI 9
>> +		      (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>> +	};
>> +};
>> -- 
>> 2.6.4
> 
> Regards,
> Karsten
> 



From andre.przywara at arm.com  Mon Feb  1 15:04:50 2016
From: andre.przywara at arm.com (=?UTF-8?Q?Andr=c3=a9_Przywara?=)
Date: Mon, 1 Feb 2016 23:04:50 +0000
Subject: [linux-sunxi] [PATCH 11/11] arm64: dts: add Pine64 support
In-Reply-To: <20160201192257.GD14737@excalibur.cnev.de>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-12-git-send-email-andre.przywara@arm.com>
 <20160201192257.GD14737@excalibur.cnev.de>
Message-ID: <56AFE492.5010703@arm.com>

On 01/02/16 19:22, Karsten Merker wrote:

Hi,

> On Mon, Feb 01, 2016 at 05:39:30PM +0000, Andre Przywara wrote:
>> The Pine64 is a cost-efficient development board based on the
>> Allwinner A64 SoC.
>> There are three models: the basic version with Fast Ethernet and
>> 512 MB of DRAM (Pine64) and two Pine64+ versions, which both
>> feature Gigabit Ethernet and additional connectors for touchscreens
>> and a camera. Or as my son put it: "Those are smaller and these are
>> missing." ;-)
>> The two Pine64+ models just differ in the amount of DRAM
>> (1GB vs. 2GB). Since U-Boot will figure out the right size for us and
>> patches the DT accordingly we just need to provide one DT for the
>> Pine64+.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>> ---
>>  .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>>  arch/arm64/boot/dts/Makefile                       |  1 +
>>  arch/arm64/boot/dts/allwinner/Makefile             |  5 ++
>>  arch/arm64/boot/dts/allwinner/pine64.dts           | 58 +++++++++++++++++
>>  arch/arm64/boot/dts/allwinner/pine64_common.dtsi   | 76 ++++++++++++++++++++++
>>  arch/arm64/boot/dts/allwinner/pine64_plus.dts      | 59 +++++++++++++++++
>>  6 files changed, 200 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
>>  create mode 100644 arch/arm64/boot/dts/allwinner/pine64.dts
>>  create mode 100644 arch/arm64/boot/dts/allwinner/pine64_common.dtsi
>>  create mode 100644 arch/arm64/boot/dts/allwinner/pine64_plus.dts
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 72e2c5a..0c22fa9 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -175,6 +175,7 @@ parade	Parade Technologies Inc.
>>  pericom	Pericom Technology Inc.
>>  phytec	PHYTEC Messtechnik GmbH
>>  picochip	Picochip Ltd
>> +pine64	Pine64
>>  plathome	Plat'Home Co., Ltd.
>>  plda	PLDA
>>  pixcir  PIXCIR MICROELECTRONICS Co., Ltd
>> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
>> index f832b8a..3b7428a 100644
>> --- a/arch/arm64/boot/dts/Makefile
>> +++ b/arch/arm64/boot/dts/Makefile
>> @@ -1,3 +1,4 @@
>> +dts-dirs += allwinner
>>  dts-dirs += altera
>>  dts-dirs += amd
>>  dts-dirs += apm
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
>> new file mode 100644
>> index 0000000..65f4e24
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -0,0 +1,5 @@
>> +dtb-$(CONFIG_ARCH_SUNXI) += pine64_plus.dtb pine64.dtb
>> +
>> +always		:= $(dtb-y)
>> +subdir-y	:= $(dts-dirs)
>> +clean-files	:= *.dtb
>> diff --git a/arch/arm64/boot/dts/allwinner/pine64.dts b/arch/arm64/boot/dts/allwinner/pine64.dts
> 
> Please see my followups to patch No. 5 and patch No. 10 in this series.
> s/pine64.dts/sun50i-pine64.dts/ ?

Really? Actually this should be more like pine64-pine64.dts, but since
the company name is identical to their (first?) product, I found it
rather weird to have this double naming.
The ARM DTs for instance are also just "juno.dts" and "juno-r1.dts".

> 
>> new file mode 100644
>> index 0000000..ebea5dd
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/pine64.dts
>> @@ -0,0 +1,58 @@
>> +/*
>> + * Copyright (c) 2016 ARM Ltd.
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This library is free software; you can redistribute it and/or
>> + *     modify it under the terms of the GNU General Public License as
>> + *     published by the Free Software Foundation; either version 2 of the
>> + *     License, or (at your option) any later version.
>> + *
>> + *     This library is distributed in the hope that it will be useful,
>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *     GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + *     obtaining a copy of this software and associated documentation
>> + *     files (the "Software"), to deal in the Software without
>> + *     restriction, including without limitation the rights to use,
>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>> + *     sell copies of the Software, and to permit persons to whom the
>> + *     Software is furnished to do so, subject to the following
>> + *     conditions:
>> + *
>> + *     The above copyright notice and this permission notice shall be
>> + *     included in all copies or substantial portions of the Software.
>> + *
>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + *     OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "pine64_common.dtsi"
> 
> see above
> 
> Also a minor spelling nitpick: the other *common* dts/dtsi files
> use dashes instead of underscores, so with regard to naming
> consistency I would like to propose doing it the same way here.

Good point, will fix it!

Repeated rationale for the below comments.

Cheers,
Andre.

> 
>> +
>> +/ {
>> +	model = "Pine64";
>> +	compatible = "pine64,pine64", "allwinner,a64", "allwinner,sunxi";
> 
> see above
> 
>> +
>> +	chosen {
>> +		stdout-path = "serial0:115200n8";
>> +	};
>> +
>> +	memory {
>> +		reg = <0x40000000 0x20000000>;
>> +	};
>> +};
>> diff --git a/arch/arm64/boot/dts/allwinner/pine64_common.dtsi b/arch/arm64/boot/dts/allwinner/pine64_common.dtsi
> 
> see above
> 
>> new file mode 100644
>> index 0000000..d968d76
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/pine64_common.dtsi
>> @@ -0,0 +1,76 @@
>> +/*
>> + * Copyright (c) 2016 ARM Ltd.
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This library is free software; you can redistribute it and/or
>> + *     modify it under the terms of the GNU General Public License as
>> + *     published by the Free Software Foundation; either version 2 of the
>> + *     License, or (at your option) any later version.
>> + *
>> + *     This library is distributed in the hope that it will be useful,
>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *     GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + *     obtaining a copy of this software and associated documentation
>> + *     files (the "Software"), to deal in the Software without
>> + *     restriction, including without limitation the rights to use,
>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>> + *     sell copies of the Software, and to permit persons to whom the
>> + *     Software is furnished to do so, subject to the following
>> + *     conditions:
>> + *
>> + *     The above copyright notice and this permission notice shall be
>> + *     included in all copies or substantial portions of the Software.
>> + *
>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + *     OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +#include "a64.dtsi"
> 
> see above
> 
>> +
>> +&mmc0 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&mmc0_pins>, <&mmc0_default_cd_pin>;
>> +	vmmc-supply = <&reg_vcc3v3>;
>> +	cd-gpios = <&pio 5 6 0>;
>> +	cd-inverted;
>> +	status = "okay";
>> +};
>> +
>> +&uart0 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart0_pins_a>;
>> +	status = "okay";
>> +};
>> +
>> +&uart2 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart2_pins>;
>> +	status = "okay";
>> +};
>> +
>> +&uart3 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart3_pins_a>;
>> +	status = "okay";
>> +};
>> +
>> +&uart4 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart4_pins>;
>> +	status = "okay";
>> +};
>> diff --git a/arch/arm64/boot/dts/allwinner/pine64_plus.dts b/arch/arm64/boot/dts/allwinner/pine64_plus.dts
>> new file mode 100644
>> index 0000000..344752e
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/pine64_plus.dts
> 
> see above
> 
>> @@ -0,0 +1,59 @@
>> +/*
>> + * Copyright (c) 2016 ARM Ltd.
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This library is free software; you can redistribute it and/or
>> + *     modify it under the terms of the GNU General Public License as
>> + *     published by the Free Software Foundation; either version 2 of the
>> + *     License, or (at your option) any later version.
>> + *
>> + *     This library is distributed in the hope that it will be useful,
>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *     GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + *     obtaining a copy of this software and associated documentation
>> + *     files (the "Software"), to deal in the Software without
>> + *     restriction, including without limitation the rights to use,
>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>> + *     sell copies of the Software, and to permit persons to whom the
>> + *     Software is furnished to do so, subject to the following
>> + *     conditions:
>> + *
>> + *     The above copyright notice and this permission notice shall be
>> + *     included in all copies or substantial portions of the Software.
>> + *
>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + *     OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "pine64_common.dtsi"
> 
> see above
> 
>> +
>> +/ {
>> +	model = "Pine64+";
>> +	compatible = "pine64,pine64_plus", "allwinner,a64", "allwinner,sunxi";
> 
> see above
> 
>> +
>> +	chosen {
>> +		stdout-path = "serial0:115200n8";
>> +	};
>> +
>> +	/* There is a model with 2GB of DRAM, but U-Boot fixes this for us. */
>> +	memory {
>> +		reg = <0x40000000 0x40000000>;
>> +	};
>> +};
>> -- 
>> 2.6.4
> 
> Regards,
> Karsten
> 



From rafael at kernel.org  Mon Feb  1 15:10:43 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Tue, 2 Feb 2016 00:10:43 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160201222926.GQ19432@atomide.com>
References: <CAJZ5v0i79X5JjOZiu4cOZ0Esd5BxAvutF8d17asDzq9ECcML-g@mail.gmail.com>
 <20160126232212.GE19432@atomide.com>
 <CAJZ5v0gTRvyWHVmYNb8Q1QZzhVhokXo541+48mFyDRYv7Hi-Uw@mail.gmail.com>
 <20160126235222.GF19432@atomide.com>
 <CAPDyKFqD6Y6HcgVds_oWBZ8L7Kdh2VX_WZCGApf-1a_6GHCQ5g@mail.gmail.com>
 <20160128165810.GA19432@atomide.com>
 <CAPDyKFoQHpqdCa4fzHycP0OT2KsNTxWm7JZSe8Mauh+rxqGtGg@mail.gmail.com>
 <20160201181135.GL19432@atomide.com>
 <20160201220657.GO19432@atomide.com>
 <CAJZ5v0gOtJE24Hu8R9jx7kBktmd__qFUNF_KnsCDLwgidskUvw@mail.gmail.com>
 <20160201222926.GQ19432@atomide.com>
Message-ID: <CAJZ5v0jN3uK8q46N1Sp6xR2U=MpJZj=PX8uh9Kp+n75J4UZCZQ@mail.gmail.com>

On Mon, Feb 1, 2016 at 11:29 PM, Tony Lindgren <tony at atomide.com> wrote:
> * Rafael J. Wysocki <rafael at kernel.org> [160201 14:18]:
>> On Mon, Feb 1, 2016 at 11:06 PM, Tony Lindgren <tony at atomide.com> wrote:
>> > --- a/drivers/base/power/runtime.c
>> > +++ b/drivers/base/power/runtime.c
>> > @@ -1419,17 +1419,25 @@ void pm_runtime_init(struct device *dev)
>> >   */
>> >  void pm_runtime_reinit(struct device *dev)
>> >  {
>> > -       if (!pm_runtime_enabled(dev)) {
>> > -               if (dev->power.runtime_status == RPM_ACTIVE)
>> > +       if (pm_runtime_enabled(dev))
>> > +               return;
>> > +
>> > +       if (dev->power.runtime_status == RPM_ACTIVE) {
>> > +               if (dev->power.use_autosuspend) {
>> > +                       __pm_runtime_use_autosuspend(dev, false);
>> > +                       pm_runtime_suspend(dev);
>>
>> This won't work, because runtime PM is disabled at this point.
>
> Hmm right OK. It does work from idling the hardware point
> of view though..

pm_runtime_suspend() with runtime PM disabled is a NOP.  It will do
nothing and return -EACCES.

>> What about doing this instead:
>>
>>                if (dev->power.use_autosuspend)
>>                        __pm_runtime_use_autosuspend(dev, false);
>>
>>                pm_runtime_set_suspended(dev);
>
> ..while this does not work. The hardware is never idled
> in this case.

I'm not sure what you mean.  pm_runtime_set_suspended() sets the
status to RPM_SUSPENDED for devices with runtime PM disabled.  It has
nothing to do with "idling" in principle.

> What else does __pm_runtime_use_autosuspend() set initially
> that changes things here?

The usage counter, if the delay is negative.

I'll look at this in detail, but not right now, sorry.  I'm working on
something else ATM and I was hoping that Ulf would be able to figure
out what's going on here.

Thanks,
Rafael


From eric at anholt.net  Mon Feb  1 15:15:32 2016
From: eric at anholt.net (Eric Anholt)
Date: Mon, 01 Feb 2016 15:15:32 -0800
Subject: [PATCH V4 1/7] clk: bcm2835: the minimum clock divider is 2
In-Reply-To: <1452867667-2447-2-git-send-email-kernel@martin.sperl.org>
References: <1452867667-2447-1-git-send-email-kernel@martin.sperl.org>
 <1452867667-2447-2-git-send-email-kernel@martin.sperl.org>
Message-ID: <87oac03tuz.fsf@eliezer.anholt.net>

kernel at martin.sperl.org writes:

> From: Martin Sperl <kernel at martin.sperl.org>
>
> Testing with different clock divider values has shown
> that (at least for the PCM clock) the clock divider
> has to be at least 2, otherwise the clock will not
> output a signal.

For a MASH clock (PWM, PCM, SLIMBUS, but not the others), the minimum
integer component of the divider is:

mash 0: 1
mash 1: 2
mash 2: 3
mash 3: 5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160201/092ef864/attachment.sig>

From eric at anholt.net  Mon Feb  1 15:19:57 2016
From: eric at anholt.net (Eric Anholt)
Date: Mon, 01 Feb 2016 15:19:57 -0800
Subject: [PATCH V4 2/7] clk: bcm2835: clamp clock divider to highest
 integer only
In-Reply-To: <1452867667-2447-3-git-send-email-kernel@martin.sperl.org>
References: <1452867667-2447-1-git-send-email-kernel@martin.sperl.org>
 <1452867667-2447-3-git-send-email-kernel@martin.sperl.org>
Message-ID: <87k2mo3tnm.fsf@eliezer.anholt.net>

kernel at martin.sperl.org writes:

> From: Martin Sperl <kernel at martin.sperl.org>
>
> The clock divider calculation right now clamps the
> divider to the highest possible fractional divider.
> So typically (BIT(div_int_bits) - 1) + 4095 / 4096.
>
> As the fractional clock divider is alterating between
> (Fosc / div_int) and (Fosc / (div_int + 1))
> the divider will overflow for the (div_int + 1) case.
> As with the "underflow" case we have seen for (div < 2),
> we can assume that the same applies on the upper limit
> as well.
>
> So this patch will instead clamp to the divider to the
> max of (BIT(div_int_bits) - 1)

Looks like this restriction might be necessary, though it's not quite
spelled out in the docs.

This also needs to be conditional on it being a MASH clock, and the
limit on the divider changes in the same way based on the mash number as
for the minimum.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160201/318facdd/attachment-0001.sig>

From tony at atomide.com  Mon Feb  1 15:28:33 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Feb 2016 15:28:33 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAJZ5v0jN3uK8q46N1Sp6xR2U=MpJZj=PX8uh9Kp+n75J4UZCZQ@mail.gmail.com>
References: <CAJZ5v0gTRvyWHVmYNb8Q1QZzhVhokXo541+48mFyDRYv7Hi-Uw@mail.gmail.com>
 <20160126235222.GF19432@atomide.com>
 <CAPDyKFqD6Y6HcgVds_oWBZ8L7Kdh2VX_WZCGApf-1a_6GHCQ5g@mail.gmail.com>
 <20160128165810.GA19432@atomide.com>
 <CAPDyKFoQHpqdCa4fzHycP0OT2KsNTxWm7JZSe8Mauh+rxqGtGg@mail.gmail.com>
 <20160201181135.GL19432@atomide.com>
 <20160201220657.GO19432@atomide.com>
 <CAJZ5v0gOtJE24Hu8R9jx7kBktmd__qFUNF_KnsCDLwgidskUvw@mail.gmail.com>
 <20160201222926.GQ19432@atomide.com>
 <CAJZ5v0jN3uK8q46N1Sp6xR2U=MpJZj=PX8uh9Kp+n75J4UZCZQ@mail.gmail.com>
Message-ID: <20160201232833.GR19432@atomide.com>

* Rafael J. Wysocki <rafael at kernel.org> [160201 15:11]:
> On Mon, Feb 1, 2016 at 11:29 PM, Tony Lindgren <tony at atomide.com> wrote:
> > * Rafael J. Wysocki <rafael at kernel.org> [160201 14:18]:
> >> On Mon, Feb 1, 2016 at 11:06 PM, Tony Lindgren <tony at atomide.com> wrote:
> >> > --- a/drivers/base/power/runtime.c
> >> > +++ b/drivers/base/power/runtime.c
> >> > @@ -1419,17 +1419,25 @@ void pm_runtime_init(struct device *dev)
> >> >   */
> >> >  void pm_runtime_reinit(struct device *dev)
> >> >  {
> >> > -       if (!pm_runtime_enabled(dev)) {
> >> > -               if (dev->power.runtime_status == RPM_ACTIVE)
> >> > +       if (pm_runtime_enabled(dev))
> >> > +               return;
> >> > +
> >> > +       if (dev->power.runtime_status == RPM_ACTIVE) {
> >> > +               if (dev->power.use_autosuspend) {
> >> > +                       __pm_runtime_use_autosuspend(dev, false);
> >> > +                       pm_runtime_suspend(dev);
> >>
> >> This won't work, because runtime PM is disabled at this point.
> >
> > Hmm right OK. It does work from idling the hardware point
> > of view though..
> 
> pm_runtime_suspend() with runtime PM disabled is a NOP.  It will do
> nothing and return -EACCES.

Hmm it  makes a difference here for sure :)

> >> What about doing this instead:
> >>
> >>                if (dev->power.use_autosuspend)
> >>                        __pm_runtime_use_autosuspend(dev, false);
> >>
> >>                pm_runtime_set_suspended(dev);
> >
> > ..while this does not work. The hardware is never idled
> > in this case.
> 
> I'm not sure what you mean.  pm_runtime_set_suspended() sets the
> status to RPM_SUSPENDED for devices with runtime PM disabled.  It has
> nothing to do with "idling" in principle.

Well looking at the update_autosuspend(), it seems we're now missing
rpm_idle() call that now never happens.

Does the patch below make more sense to you where we call rpm_idle?
That seems to make things behave here also.

> > What else does __pm_runtime_use_autosuspend() set initially
> > that changes things here?
> 
> The usage counter, if the delay is negative.

Yeah I don't see any difference with those.

> I'll look at this in detail, but not right now, sorry.  I'm working on
> something else ATM and I was hoping that Ulf would be able to figure
> out what's going on here.

Yeah we need to understand what's going on here. Having the PM runtime
framework out of sync with the hardare is not good.. If we can't
figure this out we should probably revert the patch until we understand
it.

Regards,

Tony

8< ------------
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1419,17 +1419,28 @@ void pm_runtime_init(struct device *dev)
  */
 void pm_runtime_reinit(struct device *dev)
 {
-	if (!pm_runtime_enabled(dev)) {
-		if (dev->power.runtime_status == RPM_ACTIVE)
+	int (*callback)(struct device *);
+	int err;
+
+	if (pm_runtime_enabled(dev))
+		return;
+
+	if (dev->power.runtime_status == RPM_ACTIVE) {
+		if (dev->power.use_autosuspend) {
+			__pm_runtime_use_autosuspend(dev, false);
+			rpm_idle(dev, RPM_AUTO);
+		} else {
 			pm_runtime_set_suspended(dev);
-		if (dev->power.irq_safe) {
-			spin_lock_irq(&dev->power.lock);
-			dev->power.irq_safe = 0;
-			spin_unlock_irq(&dev->power.lock);
-			if (dev->parent)
-				pm_runtime_put(dev->parent);
 		}
 	}
+
+	if (dev->power.irq_safe) {
+		spin_lock_irq(&dev->power.lock);
+		dev->power.irq_safe = 0;
+		spin_unlock_irq(&dev->power.lock);
+		if (dev->parent)
+			pm_runtime_put(dev->parent);
+	}
 }
 
 /**


From tony at atomide.com  Mon Feb  1 15:44:05 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Feb 2016 15:44:05 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160201232833.GR19432@atomide.com>
References: <20160126235222.GF19432@atomide.com>
 <CAPDyKFqD6Y6HcgVds_oWBZ8L7Kdh2VX_WZCGApf-1a_6GHCQ5g@mail.gmail.com>
 <20160128165810.GA19432@atomide.com>
 <CAPDyKFoQHpqdCa4fzHycP0OT2KsNTxWm7JZSe8Mauh+rxqGtGg@mail.gmail.com>
 <20160201181135.GL19432@atomide.com>
 <20160201220657.GO19432@atomide.com>
 <CAJZ5v0gOtJE24Hu8R9jx7kBktmd__qFUNF_KnsCDLwgidskUvw@mail.gmail.com>
 <20160201222926.GQ19432@atomide.com>
 <CAJZ5v0jN3uK8q46N1Sp6xR2U=MpJZj=PX8uh9Kp+n75J4UZCZQ@mail.gmail.com>
 <20160201232833.GR19432@atomide.com>
Message-ID: <20160201234404.GS19432@atomide.com>

* Tony Lindgren <tony at atomide.com> [160201 15:29]:
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -1419,17 +1419,28 @@ void pm_runtime_init(struct device *dev)
>   */
>  void pm_runtime_reinit(struct device *dev)
>  {
> -	if (!pm_runtime_enabled(dev)) {
> -		if (dev->power.runtime_status == RPM_ACTIVE)
> +	int (*callback)(struct device *);
> +	int err;

The callback and err are not needed here FYI, forgot to remove
them..

Tony


From stern at rowland.harvard.edu  Mon Feb  1 15:49:47 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Mon, 1 Feb 2016 18:49:47 -0500 (EST)
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160201232833.GR19432@atomide.com>
Message-ID: <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>

On Mon, 1 Feb 2016, Tony Lindgren wrote:

> Does the patch below make more sense to you where we call rpm_idle?
> That seems to make things behave here also.
> 
> > > What else does __pm_runtime_use_autosuspend() set initially
> > > that changes things here?
> > 
> > The usage counter, if the delay is negative.
> 
> Yeah I don't see any difference with those.
> 
> > I'll look at this in detail, but not right now, sorry.  I'm working on
> > something else ATM and I was hoping that Ulf would be able to figure
> > out what's going on here.
> 
> Yeah we need to understand what's going on here. Having the PM runtime
> framework out of sync with the hardare is not good.. If we can't
> figure this out we should probably revert the patch until we understand
> it.
> 
> Regards,
> 
> Tony
> 
> 8< ------------
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -1419,17 +1419,28 @@ void pm_runtime_init(struct device *dev)
>   */
>  void pm_runtime_reinit(struct device *dev)
>  {
> -	if (!pm_runtime_enabled(dev)) {
> -		if (dev->power.runtime_status == RPM_ACTIVE)
> +	int (*callback)(struct device *);
> +	int err;
> +
> +	if (pm_runtime_enabled(dev))
> +		return;
> +
> +	if (dev->power.runtime_status == RPM_ACTIVE) {
> +		if (dev->power.use_autosuspend) {
> +			__pm_runtime_use_autosuspend(dev, false);
> +			rpm_idle(dev, RPM_AUTO);

You get here only if runtime PM is disabled, right?  So the rpm_idle 
call won't do anything -- "disabled" means don't make any callbacks.

Tony, exactly what are you trying to do here?  Do you want this to 
invoke a runtime-PM callback in the subsystem, power domain, or driver?  
(Is there even a driver bound to the device when this function runs?)

The function's name suggests that it merely resets the data stored in 
dev->power without actually touching the hardware.  Is that what you 
really want?

Alan Stern



From sboyd at codeaurora.org  Mon Feb  1 16:06:23 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  1 Feb 2016 16:06:23 -0800
Subject: [PATCH v2] recordmcount: arm: Implement make_nop
Message-ID: <1454371583-9064-1-git-send-email-sboyd@codeaurora.org>

In similar spirit to x86 and arm64 support, add a make_nop_arm()
to replace calls to mcount with nops in sections that aren't
traced.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Rabin Vincent <rabin at rab.in>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---

Changes from v1:
 * Replace with nops instead of pops
 * Check for BE or LE kernel with elf headers
 * Drop mcount style check because now we look at the previous
   instruction to determine if it's a push (__gnu_mcount_nc) or not (mcount).

 scripts/recordmcount.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)

diff --git a/scripts/recordmcount.c b/scripts/recordmcount.c
index e167592793a7..356527cb539e 100644
--- a/scripts/recordmcount.c
+++ b/scripts/recordmcount.c
@@ -206,6 +206,59 @@ static int make_nop_x86(void *map, size_t const offset)
 	return 0;
 }
 
+static unsigned char ideal_nop4_arm_le[4] = { 0x00, 0x00, 0xa0, 0xe1 }; /* mov r0, r0 */
+static unsigned char ideal_nop4_arm_be[4] = { 0xe1, 0xa0, 0x00, 0x00 }; /* mov r0, r0 */
+static unsigned char *ideal_nop4_arm;
+
+static unsigned char bl_mcount_arm_le[4] = { 0xfe, 0xff, 0xff, 0xeb }; /* bl */
+static unsigned char bl_mcount_arm_be[4] = { 0xeb, 0xff, 0xff, 0xfe }; /* bl */
+static unsigned char *bl_mcount_arm;
+
+static unsigned char push_arm_le[4] = { 0x04, 0xe0, 0x2d, 0xe5 }; /* push {lr} */
+static unsigned char push_arm_be[4] = { 0xe5, 0x2d, 0xe0, 0x04 }; /* push {lr} */
+static unsigned char *push_arm;
+
+static unsigned char ideal_nop2_thumb_le[2] = { 0x00, 0xbf }; /* nop */
+static unsigned char ideal_nop2_thumb_be[2] = { 0xbf, 0x00 }; /* nop */
+static unsigned char *ideal_nop2_thumb;
+
+static unsigned char push_bl_mcount_thumb_le[6] = { 0x00, 0xb5, 0xff, 0xf7, 0xfe, 0xff }; /* push {lr}, bl */
+static unsigned char push_bl_mcount_thumb_be[6] = { 0xb5, 0x00, 0xf7, 0xff, 0xff, 0xfe }; /* push {lr}, bl */
+static unsigned char *push_bl_mcount_thumb;
+
+static int make_nop_arm(void *map, size_t const offset)
+{
+	char *ptr;
+	int cnt = 1;
+	int nop_size;
+	size_t off = offset;
+
+	ptr = map + offset;
+	if (memcmp(ptr, bl_mcount_arm, 4) == 0) {
+		if (memcmp(ptr - 4, push_arm, 4) == 0) {
+			off -= 4;
+			cnt = 2;
+		}
+		ideal_nop = ideal_nop4_arm;
+		nop_size = 4;
+	} else if (memcmp(ptr - 2, push_bl_mcount_thumb, 6) == 0) {
+		cnt = 3;
+		nop_size = 2;
+		off -= 2;
+		ideal_nop = ideal_nop2_thumb;
+	} else
+		return -1;
+
+	/* Convert to nop */
+	ulseek(fd_map, off, SEEK_SET);
+
+	do {
+		uwrite(fd_map, ideal_nop, nop_size);
+	} while (--cnt > 0);
+
+	return 0;
+}
+
 static unsigned char ideal_nop4_arm64[4] = {0x1f, 0x20, 0x03, 0xd5};
 static int make_nop_arm64(void *map, size_t const offset)
 {
@@ -421,6 +474,11 @@ do_file(char const *const fname)
 			w2 = w2rev;
 			w8 = w8rev;
 		}
+		ideal_nop4_arm = ideal_nop4_arm_le;
+		bl_mcount_arm = bl_mcount_arm_le;
+		push_arm = push_arm_le;
+		ideal_nop2_thumb = ideal_nop2_thumb_le;
+		push_bl_mcount_thumb = push_bl_mcount_thumb_le;
 		break;
 	case ELFDATA2MSB:
 		if (*(unsigned char const *)&endian != 0) {
@@ -429,6 +487,11 @@ do_file(char const *const fname)
 			w2 = w2rev;
 			w8 = w8rev;
 		}
+		ideal_nop4_arm = ideal_nop4_arm_be;
+		bl_mcount_arm = bl_mcount_arm_be;
+		push_arm = push_arm_be;
+		ideal_nop2_thumb = ideal_nop2_thumb_be;
+		push_bl_mcount_thumb = push_bl_mcount_thumb_be;
 		break;
 	}  /* end switch */
 	if (memcmp(ELFMAG, ehdr->e_ident, SELFMAG) != 0
@@ -454,6 +517,8 @@ do_file(char const *const fname)
 		break;
 	case EM_ARM:	 reltype = R_ARM_ABS32;
 			 altmcount = "__gnu_mcount_nc";
+			 make_nop = make_nop_arm;
+			 rel_type_nop = R_ARM_NONE;
 			 break;
 	case EM_AARCH64:
 			reltype = R_AARCH64_ABS64;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From msalter at redhat.com  Mon Feb  1 16:30:31 2016
From: msalter at redhat.com (Mark Salter)
Date: Mon,  1 Feb 2016 19:30:31 -0500
Subject: [PATCH] arm64: handle unmapped pages in initrd relocation
Message-ID: <1454373031-24218-1-git-send-email-msalter@redhat.com>

Commit 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as
MEMBLOCK_NOMAP") causes a potential problem in arm64 initrd relocation
code. If the kernel uses a pagesize greater than the 4k pagesize used
by UEFI, pagesize rounding may lead to one or both ends of the initrd
image to be marked unmapped. This leads to a panic when the kernel goes
to unpack it. This patch looks for unmapped pages at beginning and end
of the initrd image and if seen, relocated the initrd to a new area
completely covered by the kernel linear map.

Signed-off-by: Mark Salter <msalter at redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/kernel/setup.c | 46 +++++++++++++++++++++++++++++++++++++---------
 1 file changed, 37 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index d22c5fc..849566e 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -235,24 +235,29 @@ static void __init relocate_initrd(void)
 	phys_addr_t ram_end = memblock_end_of_DRAM();
 	phys_addr_t new_start;
 	unsigned long size, to_free = 0;
+	unsigned long unmapped_start = 0, unmapped_end = 0;
 	void *dest;
 
-	if (orig_end <= ram_end)
+	size = orig_end - orig_start;
+	if (!size)
 		return;
 
 	/*
-	 * Any of the original initrd which overlaps the linear map should
-	 * be freed after relocating.
+	 * If kernel pagesize > 4K, pagesize rounding may have placed
+	 * part of either end of initrd in an unmapped page.
+	 *
+	 * Find any unmapped bytes at start or end of initrd.
 	 */
-	if (orig_start < ram_end)
-		to_free = ram_end - orig_start;
+	if (!memblock_is_map_memory(orig_start))
+		unmapped_start = PAGE_SIZE - (orig_start & (PAGE_SIZE - 1));
+	if (!memblock_is_map_memory(orig_end - 1))
+		unmapped_end = ((orig_end - 1) & (PAGE_SIZE - 1)) + 1;
 
-	size = orig_end - orig_start;
-	if (!size)
+	if (unmapped_start == 0 && unmapped_end == 0 && orig_end <= ram_end)
 		return;
 
 	/* initrd needs to be relocated completely inside linear mapping */
-	new_start = memblock_find_in_range(0, PFN_PHYS(max_pfn),
+	new_start = memblock_find_in_range(0, ram_end,
 					   size, PAGE_SIZE);
 	if (!new_start)
 		panic("Cannot relocate initrd of size %ld\n", size);
@@ -267,7 +272,30 @@ static void __init relocate_initrd(void)
 
 	dest = (void *)initrd_start;
 
-	if (to_free) {
+	if (unmapped_end) {
+		copy_from_early_mem(dest + size - unmapped_end,
+				    orig_start + size - unmapped_end,
+				    unmapped_end);
+		size -= unmapped_end;
+		if (size == 0)
+			return;
+	}
+
+	if (unmapped_start) {
+		copy_from_early_mem(dest, orig_start, unmapped_start);
+		dest += unmapped_start;
+		orig_start += unmapped_start;
+		size -= unmapped_start;
+		if (size == 0)
+			return;
+	}
+
+	/*
+	 * Any of the remaining original initrd which overlaps the linear map
+	 * should be freed after relocating.
+	 */
+	if (orig_start < ram_end) {
+		to_free = min(size, (unsigned long)(ram_end - orig_start));
 		memcpy(dest, (void *)__phys_to_virt(orig_start), to_free);
 		dest += to_free;
 	}
-- 
1.8.3.1



From olof at lixom.net  Mon Feb  1 16:52:37 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 1 Feb 2016 16:52:37 -0800
Subject: [PATCH] ARM: dts: cros-ec-keyboard: Add LOCK key to keyboard
 matrix
In-Reply-To: <2283417.UbYyfQa1E3@diego>
References: <1454121504-12683-1-git-send-email-djkurtz@chromium.org>
 <2283417.UbYyfQa1E3@diego>
Message-ID: <CAOesGMj496KKjoQ801WGbv1Z-63PnTz=24Gz8f3fBnuMSrfU3w@mail.gmail.com>

On Mon, Feb 1, 2016 at 9:16 AM, Heiko St?bner <heiko at sntech.de> wrote:
> Hi Daniel,
>
> Am Samstag, 30. Januar 2016, 10:38:24 schrieb Daniel Kurtz:
>> From: James Chao <james_chao at asus.com>
>>
>> The LOCK key is at KSO9/KSI3 for Chromebook Flip and other devices
>> that use the Chrome OS EC keyboard matrix.
>>
>> Signed-off-by: James Chao <james_chao at asus.com>
>> Signed-off-by: Daniel Kurtz <djkurtz at chromium.org>
>> Signed-off-by: YH Huang <yh.huang at mediatek.com>
>
> that should probably be a
>         Reviewed-by: YH Huang <yh.huang at mediatek.com>
> As I don't see any actual patch handling step by him/her.
>
> Also, you might've included Olof as the keeper of all things ChromeOS when
> sending.
>
> @Olof: this seems to be pretty Veyron-specific for the moment, so I'm inclined
> to pick that up. Please holler if you disagree and want to pick it up yourself
> ;-)

Go ahead, we can take it as a fix for 4.5 at this time if you want.


-Olof


From sboyd at codeaurora.org  Mon Feb  1 17:09:39 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 1 Feb 2016 17:09:39 -0800
Subject: [PATCH v2] clk: move the common clock's to_clk_*(_hw) macros to
 clk-provider.h
In-Reply-To: <704f6d5aa50acc4723f6756c217a865641d927fe.1452267334.git.geliangtang@163.com>
References: <568F9960.9040209@gmail.com>
 <704f6d5aa50acc4723f6756c217a865641d927fe.1452267334.git.geliangtang@163.com>
Message-ID: <20160202010939.GF4848@codeaurora.org>

On 01/08, Geliang Tang wrote:
> to_clk_*(_hw) macros have been repeatedly defined in many places.
> This patch moves all the to_clk_*(_hw) definitions in the common
> clock framework to public header clk-provider.h, and drop the local
> definitions.
> 
> Signed-off-by: Geliang Tang <geliangtang at 163.com>
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From sboyd at codeaurora.org  Mon Feb  1 17:15:45 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 1 Feb 2016 17:15:45 -0800
Subject: [PATCH] clk: vt8500: don't return possibly uninitialized data
In-Reply-To: <4790407.6zgSQCdsSB@wuerfel>
References: <4790407.6zgSQCdsSB@wuerfel>
Message-ID: <20160202011545.GG4848@codeaurora.org>

On 02/01, Arnd Bergmann wrote:
> The clk-vt8500.c driver would previously enter an endless loop
> when invalid settings got requested, this was now fixed. However,
> the driver will now return uninitialized data for a subset of those
> cases instead, as the gcc correctly warns:
> 
> clk/clk-vt8500.c: In function 'wm8650_find_pll_bits':
> clk/clk-vt8500.c:423:12: error: 'best_div2' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>   *divisor2 = best_div2;
>             ^
> clk/clk-vt8500.c:422:12: error: 'best_div1' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>   *divisor1 = best_div1;
>             ^
> clk/clk-vt8500.c:421:14: error: 'best_mul' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>   *multiplier = best_mul;
> 
> This reworks the error handling in the driver so we now return
> -EINVAL from clk_round_rate() and clk_set_rate() when we get
> impossible inputs.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 090341b0a95d ("clk: vt8500: fix sign of possible PLL values")

My compiler still gets warnings even after this patch is applied.

drivers/clk/clk-vt8500.c: In function ?wm8750_find_pll_bits?:
drivers/clk/clk-vt8500.c:509:12: warning: ?best_div2? may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/clk/clk-vt8500.c:508:12: warning: ?best_div1? may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/clk/clk-vt8500.c:507:14: warning: ?best_mul? may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/clk/clk-vt8500.c: In function ?wm8650_find_pll_bits?:
drivers/clk/clk-vt8500.c:430:12: warning: ?best_div2? may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/clk/clk-vt8500.c:429:12: warning: ?best_div1? may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/clk/clk-vt8500.c:428:14: warning: ?best_mul? may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/clk/clk-vt8500.c: In function ?wm8850_find_pll_bits?:
drivers/clk/clk-vt8500.c:560:12: warning: ?best_div2? may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/clk/clk-vt8500.c:559:12: warning: ?best_div1? may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/clk/clk-vt8500.c:558:14: warning: ?best_mul? may be used uninitialized in this function [-Wmaybe-uninitialized]

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From khilman at baylibre.com  Mon Feb  1 17:17:38 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Mon, 01 Feb 2016 17:17:38 -0800
Subject: MTK mt8173-evb: mainline unstable, and big-endian boot failures
In-Reply-To: <1454309376.11974.3.camel@mtksdaap41> (Eddie Huang's message of
 "Mon, 1 Feb 2016 14:49:36 +0800")
References: <CAOi56cVDbkAJEDWy3+DV63a=UuD7nqpUu8X7e-OjtWM-4dj_-w@mail.gmail.com>
 <7hsi1ilczm.fsf@baylibre.com>
 <CAF-23O3ps0Wt_UCmJbArpc5iJJryJKA0k_2qAyNb7op8O=UnAg@mail.gmail.com>
 <1453964180.26397.8.camel@mtksdaap41> <7hy4b8gc7q.fsf@baylibre.com>
 <1454309376.11974.3.camel@mtksdaap41>
Message-ID: <7hh9hrgbbh.fsf@baylibre.com>

Hi Eddie,

Eddie Huang <eddie.huang at mediatek.com> writes:

[...]

> Thanks your patience to provide detail steps, we can reproduce this
> problem now. It seems something wrong in ATF, we still investigate how
> to fix it. We will provide you new ATF firmware once we have solution

Great, I'm glad you can reproduce it.  I was starting to worry it was
only my hardware with the problem.

Please let me know if there are firmware updates you'd like me to test
and I'll be happy to.

Thanks,

Kevin


From liguo.zhang at mediatek.com  Mon Feb  1 09:19:03 2016
From: liguo.zhang at mediatek.com (Liguo Zhang)
Date: Tue, 2 Feb 2016 01:19:03 +0800
Subject: [PATCH v6] i2c: mt8173: add 4GB mode support in i2c driver.
Message-ID: <1454347143-31461-1-git-send-email-liguo.zhang@mediatek.com>

If 4GB mode is enable, we should add 4gb mode support in i2c driver.
Set 4GB mode register to support 4GB mode.

Signed-off-by: Liguo Zhang <liguo.zhang at mediatek.com>
---
change in v6:
Remove unnecessary init for reg_4g_mode.
change in v5:
Use BIT_ULL() to fix kernel building warning.
change in v4:
Use BIT_ULL() to fix kernel building warning.
change in v3:
Only inline the computation of reg_4g_mode in mtk_i2c_set_4g_mode().
change in v2:
Define a static inline function mtk_i2c_set_4g_mode() for support 4g mode.
---
 drivers/i2c/busses/i2c-mt65xx.c | 42 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index aec8e6c..453358b 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -60,6 +60,7 @@
 #define I2C_DMA_INT_FLAG_NONE		0x0000
 #define I2C_DMA_CLR_FLAG		0x0000
 #define I2C_DMA_HARD_RST		0x0002
+#define I2C_DMA_4G_MODE			0x0001
 
 #define I2C_DEFAULT_SPEED		100000	/* hz */
 #define MAX_FS_MODE_SPEED		400000
@@ -88,6 +89,8 @@ enum DMA_REGS_OFFSET {
 	OFFSET_RX_MEM_ADDR = 0x20,
 	OFFSET_TX_LEN = 0x24,
 	OFFSET_RX_LEN = 0x28,
+	OFFSET_TX_4G_MODE = 0x54,
+	OFFSET_RX_4G_MODE = 0x58,
 };
 
 enum i2c_trans_st_rs {
@@ -133,6 +136,7 @@ struct mtk_i2c_compatible {
 	unsigned char dcm: 1;
 	unsigned char auto_restart: 1;
 	unsigned char aux_len_reg: 1;
+	unsigned char support_33bits: 1;
 };
 
 struct mtk_i2c {
@@ -182,6 +186,7 @@ static const struct mtk_i2c_compatible mt6577_compat = {
 	.dcm = 1,
 	.auto_restart = 0,
 	.aux_len_reg = 0,
+	.support_33bits = 0,
 };
 
 static const struct mtk_i2c_compatible mt6589_compat = {
@@ -190,6 +195,7 @@ static const struct mtk_i2c_compatible mt6589_compat = {
 	.dcm = 0,
 	.auto_restart = 0,
 	.aux_len_reg = 0,
+	.support_33bits = 0,
 };
 
 static const struct mtk_i2c_compatible mt8173_compat = {
@@ -198,6 +204,7 @@ static const struct mtk_i2c_compatible mt8173_compat = {
 	.dcm = 1,
 	.auto_restart = 1,
 	.aux_len_reg = 1,
+	.support_33bits = 1,
 };
 
 static const struct of_device_id mtk_i2c_of_match[] = {
@@ -366,6 +373,11 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned int parent_clk,
 	return 0;
 }
 
+static inline u32 mtk_i2c_set_4g_mode(dma_addr_t addr)
+{
+	return (addr & BIT_ULL(32)) ? I2C_DMA_4G_MODE : I2C_DMA_CLR_FLAG;
+}
+
 static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 			       int num, int left_num)
 {
@@ -373,6 +385,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 	u16 start_reg;
 	u16 control_reg;
 	u16 restart_flag = 0;
+	u32 reg_4g_mode;
 	dma_addr_t rpaddr = 0;
 	dma_addr_t wpaddr = 0;
 	int ret;
@@ -439,6 +452,12 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 					msgs->len, DMA_FROM_DEVICE);
 		if (dma_mapping_error(i2c->dev, rpaddr))
 			return -ENOMEM;
+
+		if (i2c->dev_comp->support_33bits) {
+			reg_4g_mode = mtk_i2c_set_4g_mode(rpaddr);
+			writel(reg_4g_mode, i2c->pdmabase + OFFSET_RX_4G_MODE);
+		}
+
 		writel((u32)rpaddr, i2c->pdmabase + OFFSET_RX_MEM_ADDR);
 		writel(msgs->len, i2c->pdmabase + OFFSET_RX_LEN);
 	} else if (i2c->op == I2C_MASTER_WR) {
@@ -448,6 +467,12 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 					msgs->len, DMA_TO_DEVICE);
 		if (dma_mapping_error(i2c->dev, wpaddr))
 			return -ENOMEM;
+
+		if (i2c->dev_comp->support_33bits) {
+			reg_4g_mode = mtk_i2c_set_4g_mode(wpaddr);
+			writel(reg_4g_mode, i2c->pdmabase + OFFSET_TX_4G_MODE);
+		}
+
 		writel((u32)wpaddr, i2c->pdmabase + OFFSET_TX_MEM_ADDR);
 		writel(msgs->len, i2c->pdmabase + OFFSET_TX_LEN);
 	} else {
@@ -465,6 +490,15 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 					 msgs->len, DMA_TO_DEVICE);
 			return -ENOMEM;
 		}
+
+		if (i2c->dev_comp->support_33bits) {
+			reg_4g_mode = mtk_i2c_set_4g_mode(wpaddr);
+			writel(reg_4g_mode, i2c->pdmabase + OFFSET_TX_4G_MODE);
+
+			reg_4g_mode = mtk_i2c_set_4g_mode(rpaddr);
+			writel(reg_4g_mode, i2c->pdmabase + OFFSET_RX_4G_MODE);
+		}
+
 		writel((u32)wpaddr, i2c->pdmabase + OFFSET_TX_MEM_ADDR);
 		writel((u32)rpaddr, i2c->pdmabase + OFFSET_RX_MEM_ADDR);
 		writel(msgs->len, i2c->pdmabase + OFFSET_TX_LEN);
@@ -729,6 +763,14 @@ static int mtk_i2c_probe(struct platform_device *pdev)
 		return -EINVAL;
 	}
 
+	if (i2c->dev_comp->support_33bits) {
+		ret = dma_set_mask(&pdev->dev, DMA_BIT_MASK(33));
+		if (ret) {
+			dev_err(&pdev->dev, "dma_set_mask return error.\n");
+			return ret;
+		}
+	}
+
 	ret = mtk_i2c_clock_enable(i2c);
 	if (ret) {
 		dev_err(&pdev->dev, "clock enable failed!\n");
-- 
1.8.1.1.dirty



From qnguyen at apm.com  Mon Feb  1 17:46:25 2016
From: qnguyen at apm.com (Quan Nguyen)
Date: Tue, 2 Feb 2016 08:46:25 +0700
Subject: [PATCH v5 2/3] Documentation: gpio: Update description for X-Gene
 standby GPIO controller DTS binding
In-Reply-To: <20160201153502.GA19725@rob-hp-laptop>
References: <1454041735-8434-1-git-send-email-qnguyen@apm.com>
 <1454041735-8434-3-git-send-email-qnguyen@apm.com>
 <20160201153502.GA19725@rob-hp-laptop>
Message-ID: <CAFopSPQBjXQZwG-Phfc+xJ5Kn6dXPakT6Hg5qT-ByXG06p8wgg@mail.gmail.com>

On Mon, Feb 1, 2016 at 10:35 PM, Rob Herring <robh at kernel.org> wrote:
> On Fri, Jan 29, 2016 at 11:28:54AM +0700, Quan Nguyen wrote:
>> Update description for X-Gene standby GPIO controller DTS binding to
>> support GPIO line configuration as input, output or external IRQ pin.
>>
>> Signed-off-by: Y Vo <yvo at apm.com>
>> Signed-off-by: Quan Nguyen <qnguyen at apm.com>
>> ---
>>  .../devicetree/bindings/gpio/gpio-xgene-sb.txt     | 47 ++++++++++++++++++----
>>  1 file changed, 40 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
>> index dae1300..7b8b4cb 100644
>> --- a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
>> @@ -1,10 +1,20 @@
>>  APM X-Gene Standby GPIO controller bindings
>>
>> -This is a gpio controller in the standby domain.
>> -
>> -There are 20 GPIO pins from 0..21. There is no GPIO_DS14 or GPIO_DS15,
>> -only GPIO_DS8..GPIO_DS13 support interrupts. The IRQ mapping
>> -is currently 1-to-1 on interrupts 0x28 thru 0x2d.
>> +This is a gpio controller in the standby domain. It also supports interrupt in
>> +some particular pins which are sourced to its parent interrupt controller
>> +as diagram below:
>> +                           +-----------------+
>> +                           | X-Gene standby  |
>> +                           | GPIO controller +--------- GPIO_0
>> ++------------+             |                 | ...
>> +| Parent IRQ |             |                 +--------- GPIO_8/EXT_INT_0
>> +| controller |  EXT_INT_0  |                 | ...
>> +| (GICv2)    +-------------+                 +--------- GPIO_[N+8]/EXT_INT_N
>> +|            |  ...        |                 |
>> +|            |  EXT_INT_N  |                 +--------- GPIO_[N+9]
>> +|            +-------------+                 | ...
>> +|            |             |                 +--------- GPIO_MAX
>> ++------------+             +-----------------+
>>
>>  Required properties:
>>  - compatible: "apm,xgene-gpio-sb" for the X-Gene Standby GPIO controller
>> @@ -15,10 +25,18 @@ Required properties:
>>               0 = active high
>>               1 = active low
>>  - gpio-controller: Marks the device node as a GPIO controller.
>> -- interrupts: Shall contain exactly 6 interrupts.
>> +- interrupts: The EXT_INT_0 parent interrupt resource must be listed first.
>> +- interrupt-parent: Phandle of the parent interrupt controller.
>> +- interrupt-cells: Should be two.
>> +       - first cell is 0-N coresponding for EXT_INT_0 to EXT_INT_N.
>> +       - second cell is used to specify flags.
>> +- interrupt-controller: Marks the device node as an interrupt controller.
>> +- apm,nr-gpios: Optional, specify number of gpios pin.
>> +- apm,nr-irqs: Optional, specify number of interrupt pins.
>
> When is this not 6?
>
Hi Rob,  by default, this should be 6, but I think this property can
help in cases:
+ Used only 5(or less) first pin as interrupt.
+ For similar device which has different interrupt pins (8 for example).
My idea is to make it a bit more generic by using this optional property.

>> +- apm,irq-start: Optional, specify lowest gpio pin support interrupt.
>
> What determines this value? What value is assumed if not present?
>
This value will tell interrupt is support from which gpio pin, as in
this case interrupt support from pin 8 (ie: only pin 8, 9,10 ...
supports interrupt) as default.
If not specify the default (ie: 8) will be used.

Thanks,
-- Quan Nguyen


From eric at anholt.net  Mon Feb  1 17:51:17 2016
From: eric at anholt.net (Eric Anholt)
Date: Mon, 01 Feb 2016 17:51:17 -0800
Subject: [PATCH V4 5/7] clk: bcm2835: add missing 22 HW-clocks.
In-Reply-To: <1452867667-2447-6-git-send-email-kernel@martin.sperl.org>
References: <1452867667-2447-1-git-send-email-kernel@martin.sperl.org>
 <1452867667-2447-6-git-send-email-kernel@martin.sperl.org>
Message-ID: <87h9hr517u.fsf@eliezer.anholt.net>

kernel at martin.sperl.org writes:

> From: Martin Sperl <kernel at martin.sperl.org>
>
> There were 22 HW clocks missing from the clock driver.
>
> These have been included and int_bits and frac_bits
> have been set correctly based on information extracted
> from the broadcom videocore headers
> (http://www.broadcom.com/docs/support/videocore/Brcm_Android_ICS_Graphics_Stack.tar.gz)
>
> For an extracted view of the registers please see:
> https://github.com/msperl/rpi-registers/blob/master/md/Region_CM.md
>
> bcm2835_clock_per_parents has been assigned as the parent
> clock for all new clocks, but this may not be correct
> in all cases - documentation on this is not publicly
> available, so some modifications may be needed in the
> future.

We need the parents to be correct if we're going to land the patch.
I'll try to update them.

I'm not a fan of this "let's just shove everything we can find in some
header file into the .c and hope for the best."  Most of these clocks
were left out intentionally.

> There are a 3 more clocks that possibly could get implemented
> as gates instead of clocks:
>
>
> There are comments to indicate those.
>
> Signed-off-by: Martin Sperl <kernel at martin.sperl.org>
> ---
>  drivers/clk/bcm/clk-bcm2835.c       |  260 ++++++++++++++++++++++++++++++++++-
>  include/dt-bindings/clock/bcm2835.h |   22 +++
>  2 files changed, 276 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index 8bc0a76..1640288 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -92,8 +92,18 @@
>  #define CM_PCMDIV		0x09c
>  #define CM_PWMCTL		0x0a0
>  #define CM_PWMDIV		0x0a4
> +#define CM_SLIMCTL		0x0a8
> +#define CM_SLIMDIV		0x0ac
>  #define CM_SMICTL		0x0b0
>  #define CM_SMIDIV		0x0b4
> +#define CM_TCNTCTL		0x0c0
> +#define CM_TCNTDIV		0x0c4
> +#define CM_TECCTL		0x0c8
> +#define CM_TECDIV		0x0cc
> +#define CM_TD0CTL		0x0d0
> +#define CM_TD0DIV		0x0d4
> +#define CM_TD1CTL		0x0d8
> +#define CM_TD1DIV		0x0dc
>  #define CM_TSENSCTL		0x0e0
>  #define CM_TSENSDIV		0x0e4
>  #define CM_TIMERCTL		0x0e8
> @@ -107,6 +117,9 @@
>  #define CM_SDCCTL		0x1a8
>  #define CM_SDCDIV		0x1ac
>  #define CM_ARMCTL		0x1b0
> +#define CM_ARMDIV		0x1b4
> +#define CM_AVEOCTL		0x1b8
> +#define CM_AVEODIV		0x1bc
>  #define CM_EMMCCTL		0x1c0
>  #define CM_EMMCDIV		0x1c4
>
> @@ -829,6 +842,219 @@ static const struct bcm2835_clock_data bcm2835_clock_pcm_data = {
>  	.frac_bits = 12,
>  };
>
> +static const struct bcm2835_clock_data bcm2835_clock_aveo_data = {
> +	.name = "aveo",
> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
> +	.parents = bcm2835_clock_per_parents,
> +	.ctl_reg = CM_AVEOCTL,
> +	.div_reg = CM_AVEODIV,
> +	.int_bits = 4,
> +	.frac_bits = 12,
> +};

AVEO has 0 fractional bits

> +static const struct bcm2835_clock_data bcm2835_clock_ccp2_data = {
> +	/* this is possibly a gate */
> +	.name = "ccp2",
> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
> +	.parents = bcm2835_clock_per_parents,
> +	.ctl_reg = CM_CCP2CTL,
> +	.div_reg = CM_CCP2DIV,
> +	.int_bits = 1,
> +	.frac_bits = 0,
> +};

CCP2 is a gate from a different clock source, so this won't work.

> +static const struct bcm2835_clock_data bcm2835_clock_dsi0p_data = {
> +	/* this is possibly a gate */
> +	.name = "dsi0p",
> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
> +	.parents = bcm2835_clock_per_parents,
> +	.ctl_reg = CM_DSI0PCTL,
> +	.div_reg = CM_DSI0PDIV,
> +	.int_bits = 1,
> +	.frac_bits = 0,
> +};
> +
> +static const struct bcm2835_clock_data bcm2835_clock_dsi1p_data = {
> +	/* this is possibly a gate */
> +	.name = "dsi1p",
> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
> +	.parents = bcm2835_clock_per_parents,
> +	.ctl_reg = CM_DSI1PCTL,
> +	.div_reg = CM_DSI1PDIV,
> +	.int_bits = 1,
> +	.frac_bits = 0,
> +};

DSI0/1 pixel clocks take different clock sources and are gates off of
them, so these definitions don't work.

> +
> +static const struct bcm2835_clock_data bcm2835_clock_gnric_data = {
> +	.name = "gnric",
> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
> +	.parents = bcm2835_clock_per_parents,
> +	.ctl_reg = CM_GNRICCTL,
> +	.div_reg = CM_GNRICDIV,
> +	.int_bits = 12,
> +	.frac_bits = 12,
> +};

GNRIC isn't an actual clock, it's just what's used for describing the
overall structure of clocks.

> +static const struct bcm2835_clock_data bcm2835_clock_peria_data = {
> +	.name = "peria",
> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
> +	.parents = bcm2835_clock_per_parents,
> +	.ctl_reg = CM_PERIACTL,
> +	.div_reg = CM_PERIADIV,
> +	.int_bits = 12,
> +	.frac_bits = 12,
> +};

This register doesn't do anything, because the debug bit in the power
manager is not set.  We don't think we should expose a clock gate if it
doesn't work, I think.

> +static const struct bcm2835_clock_data bcm2835_clock_pulse_data = {
> +	.name = "pulse",
> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
> +	.parents = bcm2835_clock_per_parents,
> +	.ctl_reg = CM_PULSECTL,
> +	.div_reg = CM_PULSEDIV,
> +	.int_bits = 12,
> +	.frac_bits = 0,
> +};

There's some other divider involved in this clock, won't give correct results.

> +static const struct bcm2835_clock_data bcm2835_clock_td0_data = {
> +	.name = "td0",
> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
> +	.parents = bcm2835_clock_per_parents,
> +	.ctl_reg = CM_TD0CTL,
> +	.div_reg = CM_TD0DIV,
> +	.int_bits = 12,
> +	.frac_bits = 12,
> +};
> +
> +static const struct bcm2835_clock_data bcm2835_clock_td1_data = {
> +	.name = "td1",
> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
> +	.parents = bcm2835_clock_per_parents,
> +	.ctl_reg = CM_TD1CTL,
> +	.div_reg = CM_TD1DIV,
> +	.int_bits = 12,
> +	.frac_bits = 12,
> +};

These are some other clock generator, not the generic or mash ones used
elsewhere.  I wouldn't enable them without testing.

> +static const struct bcm2835_clock_data bcm2835_clock_tec_data = {
> +	.name = "tec",
> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
> +	.parents = bcm2835_clock_per_parents,
> +	.ctl_reg = CM_TECCTL,
> +	.div_reg = CM_TECDIV,
> +	.int_bits = 6,
> +	.frac_bits = 0,
> +};

TEC should be osc parents.

> -/*
> - * CM_PERIICTL (and CM_PERIACTL, CM_SYSCTL and CM_VPUCTL if
> - * you have the debug bit set in the power manager, which we
> - * don't bother exposing) are individual gates off of the
> - * non-stop vpu clock.
> - */
>  static const struct bcm2835_gate_data bcm2835_clock_peri_image_data = {
>  	.name = "peri_image",
>  	.parent = "vpu",
>  	.ctl_reg = CM_PERIICTL,
>  };
>
> +static const struct bcm2835_gate_data bcm2835_clock_sys_data = {
> +	.name = "sys",
> +	.parent = "vpu",
> +	.ctl_reg = CM_SYSCTL,
> +};

same concern as peria.

> +
>  struct bcm2835_pll {
>  	struct clk_hw hw;
>  	struct bcm2835_cprman *cprman;
> @@ -1591,9 +1817,31 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
>  	[BCM2835_CLOCK_EMMC]	= REGISTER_CLK(&bcm2835_clock_emmc_data),
>  	[BCM2835_CLOCK_PWM]	= REGISTER_CLK(&bcm2835_clock_pwm_data),
>  	[BCM2835_CLOCK_PCM]	= REGISTER_CLK(&bcm2835_clock_pcm_data),
> +	[BCM2835_CLOCK_AVEO]	= REGISTER_CLK(&bcm2835_clock_aveo_data),
> +	[BCM2835_CLOCK_CAM0]	= REGISTER_CLK(&bcm2835_clock_cam0_data),
> +	[BCM2835_CLOCK_CAM1]	= REGISTER_CLK(&bcm2835_clock_cam1_data),
> +	[BCM2835_CLOCK_CCP2]	= REGISTER_CLK(&bcm2835_clock_ccp2_data),
> +	[BCM2835_CLOCK_DFT]	= REGISTER_CLK(&bcm2835_clock_dft_data),
> +	[BCM2835_CLOCK_DPI]	= REGISTER_CLK(&bcm2835_clock_dpi_data),
> +	[BCM2835_CLOCK_DSI0E]	= REGISTER_CLK(&bcm2835_clock_dsi0e_data),
> +	[BCM2835_CLOCK_DSI0P]	= REGISTER_CLK(&bcm2835_clock_dsi0p_data),
> +	[BCM2835_CLOCK_DSI1E]	= REGISTER_CLK(&bcm2835_clock_dsi1e_data),
> +	[BCM2835_CLOCK_DSI1P]	= REGISTER_CLK(&bcm2835_clock_dsi1p_data),
> +	[BCM2835_CLOCK_GNRIC]	= REGISTER_CLK(&bcm2835_clock_gnric_data),
> +	[BCM2835_CLOCK_GP0]	= REGISTER_CLK(&bcm2835_clock_gp0_data),
> +	[BCM2835_CLOCK_GP1]	= REGISTER_CLK(&bcm2835_clock_gp1_data),
> +	[BCM2835_CLOCK_GP2]	= REGISTER_CLK(&bcm2835_clock_gp2_data),
> +	[BCM2835_CLOCK_PERIA]	= REGISTER_CLK(&bcm2835_clock_peria_data),
> +	[BCM2835_CLOCK_PULSE]	= REGISTER_CLK(&bcm2835_clock_pulse_data),
> +	[BCM2835_CLOCK_SLIM]	= REGISTER_CLK(&bcm2835_clock_slim_data),
> +	[BCM2835_CLOCK_SMI]	= REGISTER_CLK(&bcm2835_clock_smi_data),
> +	[BCM2835_CLOCK_TD0]	= REGISTER_CLK(&bcm2835_clock_td0_data),
> +	[BCM2835_CLOCK_TD1]	= REGISTER_CLK(&bcm2835_clock_td1_data),
> +	[BCM2835_CLOCK_TEC]	= REGISTER_CLK(&bcm2835_clock_tec_data),
>  	/* the gates */
>  	[BCM2835_CLOCK_PERI_IMAGE] = REGISTER_GATE(
>  		&bcm2835_clock_peri_image_data),
> +	[BCM2835_CLOCK_SYS]	= REGISTER_GATE(&bcm2835_clock_sys_data),
>  };
>
>  static int bcm2835_clk_probe(struct platform_device *pdev)
> diff --git a/include/dt-bindings/clock/bcm2835.h b/include/dt-bindings/clock/bcm2835.h
> index 9a7b4a5..d29f181 100644
> --- a/include/dt-bindings/clock/bcm2835.h
> +++ b/include/dt-bindings/clock/bcm2835.h
> @@ -45,3 +45,25 @@
>  #define BCM2835_CLOCK_PERI_IMAGE	29
>  #define BCM2835_CLOCK_PWM		30
>  #define BCM2835_CLOCK_PCM		31
> +#define BCM2835_CLOCK_AVEO		32
> +#define BCM2835_CLOCK_CAM0		33
> +#define BCM2835_CLOCK_CAM1		34
> +#define BCM2835_CLOCK_CCP2		35
> +#define BCM2835_CLOCK_DFT		36
> +#define BCM2835_CLOCK_DPI		37
> +#define BCM2835_CLOCK_DSI0E		38
> +#define BCM2835_CLOCK_DSI0P		39
> +#define BCM2835_CLOCK_DSI1E		40
> +#define BCM2835_CLOCK_DSI1P		41
> +#define BCM2835_CLOCK_GNRIC		42
> +#define BCM2835_CLOCK_GP0		43
> +#define BCM2835_CLOCK_GP1		44
> +#define BCM2835_CLOCK_GP2		45
> +#define BCM2835_CLOCK_PERIA		46
> +#define BCM2835_CLOCK_PULSE		47
> +#define BCM2835_CLOCK_SLIM		48
> +#define BCM2835_CLOCK_SMI		49
> +#define BCM2835_CLOCK_SYS		50
> +#define BCM2835_CLOCK_TD0		51
> +#define BCM2835_CLOCK_TD1		52
> +#define BCM2835_CLOCK_TEC		53
> --
> 1.7.10.4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160201/f5d1a9ff/attachment-0001.sig>

From eric at anholt.net  Mon Feb  1 17:52:56 2016
From: eric at anholt.net (Eric Anholt)
Date: Mon, 01 Feb 2016 17:52:56 -0800
Subject: [PATCH V4 1/7] clk: bcm2835: the minimum clock divider is 2
In-Reply-To: <87oac03tuz.fsf@eliezer.anholt.net>
References: <1452867667-2447-1-git-send-email-kernel@martin.sperl.org>
 <1452867667-2447-2-git-send-email-kernel@martin.sperl.org>
 <87oac03tuz.fsf@eliezer.anholt.net>
Message-ID: <87egcv5153.fsf@eliezer.anholt.net>

Eric Anholt <eric at anholt.net> writes:

> kernel at martin.sperl.org writes:
>
>> From: Martin Sperl <kernel at martin.sperl.org>
>>
>> Testing with different clock divider values has shown
>> that (at least for the PCM clock) the clock divider
>> has to be at least 2, otherwise the clock will not
>> output a signal.
>
> For a MASH clock (PWM, PCM, SLIMBUS, but not the others), the minimum
> integer component of the divider is:
>
> mash 0: 1
> mash 1: 2
> mash 2: 3
> mash 3: 5

More specific MASH list:

GP0
GP1
(*not* gp2)
PCM
PWM
SLIM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160201/4fc8280e/attachment.sig>

From siarhei.siamashka at gmail.com  Mon Feb  1 17:58:52 2016
From: siarhei.siamashka at gmail.com (Siarhei Siamashka)
Date: Tue, 2 Feb 2016 03:58:52 +0200
Subject: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver
 for Allwinner A64 SoC
In-Reply-To: <56AFE0EC.8080207@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-6-git-send-email-andre.przywara@arm.com>
 <20160201182754.GA14737@excalibur.cnev.de>
 <56AFE0EC.8080207@arm.com>
Message-ID: <20160202035852.6984db63@i7>

On Mon, 1 Feb 2016 22:49:16 +0000
Andr? Przywara <andre.przywara at arm.com> wrote:

> On 01/02/16 18:27, Karsten Merker wrote:
> 
> Hi Karsten,
> 
> thank you very much for your feedback!
> 
> > On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote:  
> >> Based on the Allwinner A64 user manual and on the previous sunxi
> >> pinctrl drivers this introduces the pin multiplex assignments for
> >> the ARMv8 Allwinner A64 SoC.
> >> Port A is apparently used for the fixed function DRAM controller, so
> >> the ports start at B here (the manual mentions "n from 1 to 7", so
> >> not starting at 0).
> >>
> >> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> >> ---
> >>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
> >>  arch/arm64/Kconfig.platforms                       |   1 +
> >>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
> >>  drivers/pinctrl/sunxi/Makefile                     |   1 +
> >>  drivers/pinctrl/sunxi/pinctrl-a64.c                | 606 +++++++++++++++++++++
> >>  5 files changed, 613 insertions(+)
> >>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c
> >>
> >> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> >> index 9213b27..9050002 100644
> >> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> >> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> >> @@ -21,6 +21,7 @@ Required properties:
> >>    "allwinner,sun9i-a80-r-pinctrl"
> >>    "allwinner,sun8i-a83t-pinctrl"
> >>    "allwinner,sun8i-h3-pinctrl"
> >> +  "allwinner,a64-pinctrl"  
> > 
> > Hello,
> > 
> > on all other Allwinner SoCs we use the SoC family as part of the
> > compatible, as well as in the names of the Kconfig options. To
> > keep things consistent, I would like to propose doing the same on
> > Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of
> > allwinner,a64-pinctrl.  
> 
> Yes, I have been told this already. However I don't like this idea so
> much, for the following reasons:
> a) It is mostly redundant. The actual SoC (marketing) name is unique,
> there is no sun6i-a20 or sun7i-a23.
> b) It is not even helpful. If I got Maxime correctly, then the newer
> sunxi generation numbers depend on the ARM _cores_ used in the SoC,
> which is frankly the least interesting part from a Linux support
> perspective. I would see some sense if it would reflect the generation
> of IP blocks used, but so it is even more confusing to see that
> sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely
> different beast. The Allwinner marketing name tells you that, but the
> sunxi one does not.
> c) It is very confusing for people not dealing with it everyday. Just
> because I own a BananaPi I know that the A20 is sun7i, but I am totally
> lost when it comes to all the other names. And even now it took me about
> a minute to find the appropriate Wiki page which explains part of that
> story.
> d) Most importantly ;-): It kills TAB completion, unless you know the
> sunxi number, which is mostly not true as pointed out in c)
> 
> So while I see that just a<somenumber> is not really very specific, I'd
> rather do away with current naming scheme for the future. In this
> particular case we have the vendor name as a name space identifier
> already, so there is no possible confusion with ARM Cortex naming, for
> instance.
> 
> Also as this is now moving into the arm64 world, I'd like to use the
> opportunity to fix things that are not really optimal, the naming is one
> of them.

One of the problems is that A64 name is not unique. We have reasons
to believe that there are also H64 and R18 out there using exactly
the same die, but possibly available in different packaging (a different
ball grid pitch? or maybe a different set of peripherals routed to the
outside?). Early prototypes of the Pine64 board were using Allwinner R18
and the Jide Remix Mini HTPC box is using Allwinner H64.

The bootloader sources from Allwinner are also referring to A64 as
AW1689, which makes some sense because it is the chip id number that
is accessible for runtime identification via reading the SRAM_VER_REG
hardware register:

    http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG

So would it be a good idea to use "aw1689" as a compatible property
in the DT instead of "a64"? Or maybe have "aw1689-a64" and
"aw1689-h64", which would be similar to the existing "sun5i-a13"
and "sun5i-a10s" naming convention?

-- 
Best regards,
Siarhei Siamashka


From fan.chen at mediatek.com  Mon Feb  1 18:17:42 2016
From: fan.chen at mediatek.com (Fan Chen)
Date: Tue, 2 Feb 2016 10:17:42 +0800
Subject: MTK mt8173-evb: mainline unstable, and big-endian boot failures
In-Reply-To: <7hh9hrgbbh.fsf@baylibre.com>
References: <CAOi56cVDbkAJEDWy3+DV63a=UuD7nqpUu8X7e-OjtWM-4dj_-w@mail.gmail.com>
 <7hsi1ilczm.fsf@baylibre.com>
 <CAF-23O3ps0Wt_UCmJbArpc5iJJryJKA0k_2qAyNb7op8O=UnAg@mail.gmail.com>
 <1453964180.26397.8.camel@mtksdaap41> <7hy4b8gc7q.fsf@baylibre.com>
 <1454309376.11974.3.camel@mtksdaap41> <7hh9hrgbbh.fsf@baylibre.com>
Message-ID: <1454379462.27798.11.camel@mtksdaap41>

Hi Kevin,

I just checked that the problem cannot be reproduced (tested 100 times
with your script) after flashing new firmware which we uploaded to
github[0] yesterday.
This latest firmware got many fixes and also supports cluster idle, so
we prefer testing with this new one
Would you please test in your side? Thanks for your great help!! 

[0] https://github.com/ibanezchen/evb-utils/tree/master


Best regards,
Fan

On Mon, 2016-02-01 at 17:17 -0800, Kevin Hilman wrote:
> Hi Eddie,
> 
> Eddie Huang <eddie.huang at mediatek.com> writes:
> 
> [...]
> 
> > Thanks your patience to provide detail steps, we can reproduce this
> > problem now. It seems something wrong in ATF, we still investigate how
> > to fix it. We will provide you new ATF firmware once we have solution
> 
> Great, I'm glad you can reproduce it.  I was starting to worry it was
> only my hardware with the problem.
> 
> Please let me know if there are firmware updates you'd like me to test
> and I'll be happy to.
> 
> Thanks,
> 
> Kevin




From shankerd at codeaurora.org  Mon Feb  1 18:19:44 2016
From: shankerd at codeaurora.org (Shanker Donthineni)
Date: Mon,  1 Feb 2016 20:19:44 -0600
Subject: [PATCH v3] irqchip: gicv3-its: Fix memory leak in its_free_tables()
Message-ID: <1454379584-21772-1-git-send-email-shankerd@codeaurora.org>

The current ITS driver has a memory leak in its_free_tables(). It
happens on tear down path of the driver when its_probe() call fails.
its_free_tables() should free the exact number of pages that have
been allocated, not just a single page as current code does.

This patch records the memory size for each ITS_BASERn at the time of
page allocation and uses the same size information when freeing pages
to fix the issue.

Signed-off-by: Shanker Donthineni <shankerd at codeaurora.org>
---
[v2]->[v3]:
    -use order instead of alloc_size as suggested by Thomas Gleixner in v2 comments.

[v1]->[v2]: 
    -rebase on tip of https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/its-fixes-4.5&id=25ffe003bdc24492204e099fca0a467641d0fe1a
    -refresh alloc_size value whenever page order changes. 

 drivers/irqchip/irq-gic-v3-its.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 3447549..0a73632 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -66,7 +66,10 @@ struct its_node {
 	unsigned long		phys_base;
 	struct its_cmd_block	*cmd_base;
 	struct its_cmd_block	*cmd_write;
-	void			*tables[GITS_BASER_NR_REGS];
+	struct {
+		void		*base;
+		u32		order;
+	} tables[GITS_BASER_NR_REGS];
 	struct its_collection	*collections;
 	struct list_head	its_device_list;
 	u64			flags;
@@ -807,9 +810,10 @@ static void its_free_tables(struct its_node *its)
 	int i;
 
 	for (i = 0; i < GITS_BASER_NR_REGS; i++) {
-		if (its->tables[i]) {
-			free_page((unsigned long)its->tables[i]);
-			its->tables[i] = NULL;
+		if (its->tables[i].base) {
+			free_pages((unsigned long)its->tables[i].base,
+				   its->tables[i].order);
+			its->tables[i].base = NULL;
 		}
 	}
 }
@@ -890,7 +894,8 @@ retry_alloc_baser:
 			goto out_free;
 		}
 
-		its->tables[i] = base;
+		its->tables[i].base = base;
+		its->tables[i].order = order;
 
 retry_baser:
 		val = (virt_to_phys(base) 				 |
@@ -940,7 +945,7 @@ retry_baser:
 			 * something is horribly wrong...
 			 */
 			free_pages((unsigned long)base, order);
-			its->tables[i] = NULL;
+			its->tables[i].base = NULL;
 
 			switch (psz) {
 			case SZ_16K:
-- 
Qualcomm Technologies, Inc. on behalf
of the Qualcomm Innovation Center, Inc.  The Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.



From andrew at lunn.ch  Mon Feb  1 18:20:35 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 2 Feb 2016 03:20:35 +0100
Subject: [PATCH] ARM: dts: orion5x: add mtd flash support to linkstation
 lswtgl
In-Reply-To: <CAEQ9gEmbw++Qkt0B+5-zN111pn9vFJCfqyBV00=mMTxdKD284A@mail.gmail.com>
References: <1453907405-30434-1-git-send-email-rogershimizu@gmail.com>
 <20160127173231.GI20194@lunn.ch>
 <CAEQ9gEmcss4sb6hE6-w0jVoYfHqnWNf23EVNMefvZ24TYfEk2g@mail.gmail.com>
 <CAEQ9gEkU8x80-S=n+e8NBfN7OTSxHLdBSN_3q6d0JxZDxfs_9g@mail.gmail.com>
 <CAEQ9gEmbw++Qkt0B+5-zN111pn9vFJCfqyBV00=mMTxdKD284A@mail.gmail.com>
Message-ID: <20160202022035.GC12673@lunn.ch>

> I find "Documentation/devicetree/bindings/mtd/partition.txt" is quite
> new and was just updated in kernel 4.4.
> So I tried "linux-image-4.4.0-trunk-orion5x" in Debian experimental
> repo, YES, with my updated dts, the MTD goes back to work as
> partitioned as before.
> 
> In this way, if I write dts for partition like this, user cannot
> simply take dtb from kernel 4.4/4.5 to their stable kernel (such as
> Debian Jessie's 3.16-ckt series).
> For some advanced functionality, this kind of non-backport capable
> change is deserved; but for partitions IMHO it doesn't deserve,
> especially for a device/platform existing for more than 5 years.
> 
> What do you think?

Since this might be used with older Debian kernel, skipping the
partitions subnode is O.K. for me.

	   Andrew


From Wenyou.Yang at atmel.com  Mon Feb  1 18:26:29 2016
From: Wenyou.Yang at atmel.com (Yang, Wenyou)
Date: Tue, 2 Feb 2016 02:26:29 +0000
Subject: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
 ACT8945A
In-Reply-To: <CABxcv=nJsWEv9KW-5iPpUnyN8ZVpx6CV07gBRaLNWqd644YOqQ@mail.gmail.com>
References: <1453863463-30515-1-git-send-email-wenyou.yang@atmel.com>
 <1453863463-30515-2-git-send-email-wenyou.yang@atmel.com>
 <20160129001603.GM4130@sirena.org.uk>
 <B256D81BAE5131468A838E5D7A243641D63FBF8B@penmbx01>
 <20160129113518.GQ4130@sirena.org.uk>
 <CABxcv=kNKmgRytxB5ppawrAvC-GDRhV4T_UUGvpHgKp9+BsUmQ@mail.gmail.com>
 <B256D81BAE5131468A838E5D7A243641D63FE2C7@penmbx01>
 <CABxcv=nJsWEv9KW-5iPpUnyN8ZVpx6CV07gBRaLNWqd644YOqQ@mail.gmail.com>
Message-ID: <B256D81BAE5131468A838E5D7A243641D6400956@penmbx01>

Hi Javier,

> -----Original Message-----
> From: Javier Martinez Canillas [mailto:javier at dowhile0.org]
> Sent: 2016?2?1? 21:15
> To: Yang, Wenyou <Wenyou.Yang at atmel.com>
> Cc: Mark Brown <broonie at kernel.org>; Liam Girdwood <lgirdwood at gmail.com>;
> Rob Herring <robh+dt at kernel.org>; Pawel Moll <pawel.moll at arm.com>; Ian
> Campbell <ijc+devicetree at hellion.org.uk>; Kumar Gala <galak at codeaurora.org>;
> Krzysztof Kozlowski <k.kozlowski at samsung.com>; Lee Jones
> <lee.jones at linaro.org>; Peter Korsgaard <jacmet at gmail.com>; Ferre, Nicolas
> <Nicolas.FERRE at atmel.com>; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; devicetree at vger.kernel.org
> Subject: Re: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
> ACT8945A
> 
> Hello Wenyou,
> 
> [snip]
> 
> >> >
> >> > If then device is not being loaded from the DT (and it shouldn't
> >> > be, the device looks like it should be instantiated directly by the
> >> > MFD as it can't exist separately to that MFD) an OF table will do nothing.
> >>
> >> Then he should remove the .of_compatible from the MFD cell definition.
> >
> > I tried it,
> >
> > But if removed this .of_compatible, and reserved the OF table.
> 
> What we said is that you should remove both the mfd cell .of_compatible field and
> the OF table. Of course removing one but leaving the other is not correct.

I am confused :)

> 
> > the &pdev->dev->of_node is NULL, the driver fails to get the
> > configuration value from DT,
> >
> 
> I see, you mean that you are not able to lookup the "active-semi,vsel-high"
> property.

No only this property,

The regulator init_datas are also not gotten from DT due to the &pdev->dev->of_node is NULL.

> 
> > It seems the OF table still doesn't work. Where is wrong?
> >
> 
> I think the problem is with your DT binding. You have a PMIC dev node with
> compatible "active-semi,act8945a" that has a child node with compatible "active-
> semi,act8945a-regulator" which in turn has the "regulators" node.
> 
> I believe what Mark says is that there shouldn't be a compatible and node for the
> regulators IC since is part of the PMIC. IOW, you can't have it as a standalone
> node in the DTS.
> 
> > Could you help give some suggestion?
> >
> 
> I would just remove the "active-semi,act8945a-regulator" node and make "active-
> semi,vsel-high" a property of the "active-semi,act8945a" node.
> That way you can remove the mfd cell .of_compatible and OF table in the
> regulator driver and read the "active-semi,vsel-high" using the platform device's
> parent of_node.
> 
> But it's better if you wait for Mark's opinions before re-spining your patches.

All right.

> 
> Best regards,
> Javier

Thanks 


Best Regards,
Wenyou Yang

From djkurtz at chromium.org  Mon Feb  1 19:02:47 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Tue, 2 Feb 2016 11:02:47 +0800
Subject: [PATCH v6] i2c: mt8173: add 4GB mode support in i2c driver.
In-Reply-To: <1454347143-31461-1-git-send-email-liguo.zhang@mediatek.com>
References: <1454347143-31461-1-git-send-email-liguo.zhang@mediatek.com>
Message-ID: <CAGS+omBzroag0W3GLDSvCXMo2nVOJS33aoHRRxHB60P2ET_z9A@mail.gmail.com>

On Tue, Feb 2, 2016 at 1:19 AM, Liguo Zhang <liguo.zhang at mediatek.com> wrote:
>
> If 4GB mode is enable, we should add 4gb mode support in i2c driver.
> Set 4GB mode register to support 4GB mode.
>
> Signed-off-by: Liguo Zhang <liguo.zhang at mediatek.com>

Reviewed-by: Daniel Kurtz <djkurtz at chromium.org>


>
> ---
> change in v6:
> Remove unnecessary init for reg_4g_mode.
> change in v5:
> Use BIT_ULL() to fix kernel building warning.
> change in v4:
> Use BIT_ULL() to fix kernel building warning.
> change in v3:
> Only inline the computation of reg_4g_mode in mtk_i2c_set_4g_mode().
> change in v2:
> Define a static inline function mtk_i2c_set_4g_mode() for support 4g mode.
> ---
>  drivers/i2c/busses/i2c-mt65xx.c | 42 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index aec8e6c..453358b 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -60,6 +60,7 @@
>  #define I2C_DMA_INT_FLAG_NONE          0x0000
>  #define I2C_DMA_CLR_FLAG               0x0000
>  #define I2C_DMA_HARD_RST               0x0002
> +#define I2C_DMA_4G_MODE                        0x0001
>
>  #define I2C_DEFAULT_SPEED              100000  /* hz */
>  #define MAX_FS_MODE_SPEED              400000
> @@ -88,6 +89,8 @@ enum DMA_REGS_OFFSET {
>         OFFSET_RX_MEM_ADDR = 0x20,
>         OFFSET_TX_LEN = 0x24,
>         OFFSET_RX_LEN = 0x28,
> +       OFFSET_TX_4G_MODE = 0x54,
> +       OFFSET_RX_4G_MODE = 0x58,
>  };
>
>  enum i2c_trans_st_rs {
> @@ -133,6 +136,7 @@ struct mtk_i2c_compatible {
>         unsigned char dcm: 1;
>         unsigned char auto_restart: 1;
>         unsigned char aux_len_reg: 1;
> +       unsigned char support_33bits: 1;
>  };
>
>  struct mtk_i2c {
> @@ -182,6 +186,7 @@ static const struct mtk_i2c_compatible mt6577_compat = {
>         .dcm = 1,
>         .auto_restart = 0,
>         .aux_len_reg = 0,
> +       .support_33bits = 0,
>  };
>
>  static const struct mtk_i2c_compatible mt6589_compat = {
> @@ -190,6 +195,7 @@ static const struct mtk_i2c_compatible mt6589_compat = {
>         .dcm = 0,
>         .auto_restart = 0,
>         .aux_len_reg = 0,
> +       .support_33bits = 0,
>  };
>
>  static const struct mtk_i2c_compatible mt8173_compat = {
> @@ -198,6 +204,7 @@ static const struct mtk_i2c_compatible mt8173_compat = {
>         .dcm = 1,
>         .auto_restart = 1,
>         .aux_len_reg = 1,
> +       .support_33bits = 1,
>  };
>
>  static const struct of_device_id mtk_i2c_of_match[] = {
> @@ -366,6 +373,11 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned int parent_clk,
>         return 0;
>  }
>
> +static inline u32 mtk_i2c_set_4g_mode(dma_addr_t addr)
> +{
> +       return (addr & BIT_ULL(32)) ? I2C_DMA_4G_MODE : I2C_DMA_CLR_FLAG;
> +}
> +
>  static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
>                                int num, int left_num)
>  {
> @@ -373,6 +385,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
>         u16 start_reg;
>         u16 control_reg;
>         u16 restart_flag = 0;
> +       u32 reg_4g_mode;
>         dma_addr_t rpaddr = 0;
>         dma_addr_t wpaddr = 0;
>         int ret;
> @@ -439,6 +452,12 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
>                                         msgs->len, DMA_FROM_DEVICE);
>                 if (dma_mapping_error(i2c->dev, rpaddr))
>                         return -ENOMEM;
> +
> +               if (i2c->dev_comp->support_33bits) {
> +                       reg_4g_mode = mtk_i2c_set_4g_mode(rpaddr);
> +                       writel(reg_4g_mode, i2c->pdmabase + OFFSET_RX_4G_MODE);
> +               }
> +
>                 writel((u32)rpaddr, i2c->pdmabase + OFFSET_RX_MEM_ADDR);
>                 writel(msgs->len, i2c->pdmabase + OFFSET_RX_LEN);
>         } else if (i2c->op == I2C_MASTER_WR) {
> @@ -448,6 +467,12 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
>                                         msgs->len, DMA_TO_DEVICE);
>                 if (dma_mapping_error(i2c->dev, wpaddr))
>                         return -ENOMEM;
> +
> +               if (i2c->dev_comp->support_33bits) {
> +                       reg_4g_mode = mtk_i2c_set_4g_mode(wpaddr);
> +                       writel(reg_4g_mode, i2c->pdmabase + OFFSET_TX_4G_MODE);
> +               }
> +
>                 writel((u32)wpaddr, i2c->pdmabase + OFFSET_TX_MEM_ADDR);
>                 writel(msgs->len, i2c->pdmabase + OFFSET_TX_LEN);
>         } else {
> @@ -465,6 +490,15 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
>                                          msgs->len, DMA_TO_DEVICE);
>                         return -ENOMEM;
>                 }
> +
> +               if (i2c->dev_comp->support_33bits) {
> +                       reg_4g_mode = mtk_i2c_set_4g_mode(wpaddr);
> +                       writel(reg_4g_mode, i2c->pdmabase + OFFSET_TX_4G_MODE);
> +
> +                       reg_4g_mode = mtk_i2c_set_4g_mode(rpaddr);
> +                       writel(reg_4g_mode, i2c->pdmabase + OFFSET_RX_4G_MODE);
> +               }
> +
>                 writel((u32)wpaddr, i2c->pdmabase + OFFSET_TX_MEM_ADDR);
>                 writel((u32)rpaddr, i2c->pdmabase + OFFSET_RX_MEM_ADDR);
>                 writel(msgs->len, i2c->pdmabase + OFFSET_TX_LEN);
> @@ -729,6 +763,14 @@ static int mtk_i2c_probe(struct platform_device *pdev)
>                 return -EINVAL;
>         }
>
> +       if (i2c->dev_comp->support_33bits) {
> +               ret = dma_set_mask(&pdev->dev, DMA_BIT_MASK(33));
> +               if (ret) {
> +                       dev_err(&pdev->dev, "dma_set_mask return error.\n");
> +                       return ret;
> +               }
> +       }
> +
>         ret = mtk_i2c_clock_enable(i2c);
>         if (ret) {
>                 dev_err(&pdev->dev, "clock enable failed!\n");
> --
> 1.8.1.1.dirty
>


From tony at atomide.com  Mon Feb  1 19:05:34 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 1 Feb 2016 19:05:34 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>
References: <20160201232833.GR19432@atomide.com>
 <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>
Message-ID: <20160202030533.GT19432@atomide.com>

Hi,

* Alan Stern <stern at rowland.harvard.edu> [160201 15:50]:
> 
> You get here only if runtime PM is disabled, right?  So the rpm_idle 
> call won't do anything -- "disabled" means don't make any callbacks.

Hmm sorry yes I'm confused again. Yeah it looks like calling rpm_idle
just has a side effect that makes a difference here.

> Tony, exactly what are you trying to do here?  Do you want this to 
> invoke a runtime-PM callback in the subsystem, power domain, or driver?  
> (Is there even a driver bound to the device when this function runs?)

I guess I need to add more printks to figure out what's going on here.
But yeah, I'm not seeing the callback happening at the interconnect
level so hardware and PM runtime states won't match on the following
probe after -EPROBE_DEFER.

> The function's name suggests that it merely resets the data stored in 
> dev->power without actually touching the hardware.  Is that what you 
> really want?

I guess you mean pm_runtime_set_suspended() above? I'm seeing a state
where we now set pm_runtime_set_suspended() between failed device
probes and the device is still active in hardware.

The patch below also helps with the problem and leaves out the
rpm_suspend() call from loop so it might give more hints.

The difference here from what Rafael suggested earlier is calling
__pm_runtime_use_autosuspend() and then not calling
pm_runtime_set_suspended().

However, it seems the below patch keeps hardware active in the
autoidle case though, so chances are there is more that needs to
be done here. Anyways, I'll try to debug it more tomorrow.

Regards,

Tony

8< ------------------
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1425,17 +1425,25 @@ void pm_runtime_init(struct device *dev)
  */
 void pm_runtime_reinit(struct device *dev)
 {
-	if (!pm_runtime_enabled(dev)) {
-		if (dev->power.runtime_status == RPM_ACTIVE)
+	if (pm_runtime_enabled(dev))
+		return;
+
+	if (dev->power.runtime_status == RPM_ACTIVE) {
+		if (dev->power.use_autosuspend) {
+			pm_runtime_set_autosuspend_delay(dev, 0);
+			__pm_runtime_use_autosuspend(dev, false);
+		} else {
 			pm_runtime_set_suspended(dev);
-		if (dev->power.irq_safe) {
-			spin_lock_irq(&dev->power.lock);
-			dev->power.irq_safe = 0;
-			spin_unlock_irq(&dev->power.lock);
-			if (dev->parent)
-				pm_runtime_put(dev->parent);
 		}
 	}
+
+	if (dev->power.irq_safe) {
+		spin_lock_irq(&dev->power.lock);
+		dev->power.irq_safe = 0;
+		spin_unlock_irq(&dev->power.lock);
+		if (dev->parent)
+			pm_runtime_put(dev->parent);
+	}
 }
 
 /**


From herbert at gondor.apana.org.au  Mon Feb  1 19:16:16 2016
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Tue, 2 Feb 2016 11:16:16 +0800
Subject: [PATCH 02/11] crypto: sunxi-ss: prevent compilation on 64-bit
In-Reply-To: <1454348370-3816-3-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-3-git-send-email-andre.przywara@arm.com>
Message-ID: <20160202031616.GA16987@gondor.apana.org.au>

On Mon, Feb 01, 2016 at 05:39:21PM +0000, Andre Przywara wrote:
> The driver for the sunxi-ss crypto engine is not entirely 64-bit safe,
> compilation on arm64 spits some warnings.
> The proper fix was deemed to involved [1], so since 64-bit SoCs won't
> have this IP block we just disable this driver for 64-bit.
> 
> [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399988.html
>      (and the reply)
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>

I still use COMPILE_TEST to test compile these drivers.  So while
I don't have a problem with this patch per se, please continue to
ensure that it doesn't generate warnings on 64-bit platforms.

Cheers,
-- 
Email: Herbert Xu <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From wxt at rock-chips.com  Mon Feb  1 19:33:52 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Tue,  2 Feb 2016 11:33:52 +0800
Subject: [PATCH v5 0/8] Add the family patches to support for kylin board
Message-ID: <1454384032-6794-1-git-send-email-wxt@rock-chips.com>

Hi all,

This series patches are based on kernel 4.5-rc1 version, also
is based on Heiko's branch.
(kernel/git/mmind/linux-rockchip.git -b for-next & v4.5-clk/fixes)

e.g: boot log..
Linux version 4.5.0-rc1+ (wxt at ubuntu) ....#60 SMP Thu Jan 28 12:54:50 CST 2016

1) The kylin history series patches:

V0:
https://lkml.org/lkml/2015/12/22/168
V1:
https://lkml.org/lkml/2015/12/17/319
V2:
https://lkml.org/lkml/2016/1/7/66
V3:
http://www.spinics.net/lists/arm-kernel/msg474796.html
V4:
https://lkml.org/lkml/2016/1/28/132

This series patches are verified on the following github:
https://github.com/Caesar-github/rockchip/tree/kylin/next

This series has 8 patches: (8--->1)
c455bf5 ARM: dts: rockchip: support the spi for rk3036
41bbd5d ASoC: rt5616: add the mclk for the codec driver
6ee2dc0 ASoC: rt5616: trivial: fix the typo
2775e41 ASoC: rt5616: add mclk property for rt5616 document
b4ec10b ARM: dts: rockchip: add mclk for rt5616 on kylin board
8d272a1 ARM: dts: rockchip: add support emac for RK3036
02e501f clk: rockchip: rk3036: fix and add node id for emac clock
b948f42 ARM: dts: rockchip: add hdmi/vop device node for rk3036
....

This series patches can apply into Heiko for-next branch.
(https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/log/?h=for-next)
Also, ths ASoC can apply into Mark branch.
---

2) This series patches have the following decriptions:

PATCH[1/8]: ====> add hdmi/vop display node for rk3036
ARM: dts: rockchip: add hdmi/vop device node for rk3036

This Patch is based on Ykk's Inno HDMI V7 patches. That's verified on
my github.

bd5ed3e ARM: dts: rockchip: add hdmi/vop device node for rk3036
438e7bd FROMLIST: dt-bindings: add document for Innosilicon HDMI on Rockchip platform
((am from https://patchwork.kernel.org/patch/8117611/))
ad0623b FROMLIST: drm/rockchip: hdmi: add Innosilicon HDMI support
((am https://patchwork.kernel.org/patch/8117571/))

PATCH[2/8-3/8]: Add the emac patch

The emac clock is depend APLL, That shoud be incorrect.
We should fix it on the DPLL.

df91ab ARM: dts: rockchip: add support emac for RK3036
d5c2781 clk: rockchip: rk3036: fix and add node id for emac clock

That's verified on kylin board with ubuntu os.

How to test and verify?

You can refer to the following wiki document.
http://rockchip.wikidot.com/linux-develop-guide

PATCH[4/8-7/8]: Make the codec work on kylin board

41bbd5d ASoC: rt5616: add the mclk for the codec driver
6ee2dc0 ASoC: rt5616: trivial: fix the typo
2775e41 ASoC: rt5616: add mclk property for rt5616 document
b4ec10b ARM: dts: rockchip: add mclk for rt5616 on kylin board

As the previous discussed on https://patchwork.kernel.org/patch/8041001/
Move the mclk into codec driver to enable and disable.

How to test and verify?

You can refer to the following wiki document.
http://rockchip.wikidot.com/linux-develop-guide

PATCH[8/8]: Make the codec work on kylin board

Add the spi node for rk3036 dts, that's seem not related to the kylin.
Maybe the future will support the spi on kylin board or connect the spi devices.

f0fff43 ARM: dts: rockchip: support the spi for rk3036
---

Thanks your reviewing! :)

-
Caesar


Changes in v5:
- remove unused commit content.
- Fix the wrong word, as the Rob comments on
  https://patchwork.kernel.org/patch/8147731/.
- Cc the related alsa experts.
-Cc releated alsa experts.
- Cc related alsa experts.
- Remove the unused, as Heiko comments on https://patchwork.kernel.org/patch/8147761/
- Modify the commit.

Changes in v4:
- solve the lastest conflict, picked up from
  https://patchwork.kernel.org/patch/8040961/.
- fix the commit, pick up from the
  https://patchwork.kernel.org/patch/7976631/.
- The emac parent shouldn't depend on the APLL. instead of DPLL.
- included in the kylin series patches.
- This patch picked up from https://patchwork.kernel.org/patch/7924971/
- Change to solve the conflict based on the Heiko's branch.
- Make the emac parent as the DPLL.
- AS the previous discussed by them, add the mclk for codec.
 (https://patchwork.kernel.org/patch/8041001/)
- Add this patch included in kylin series patches.
- Add this patch included in kylin series patches.
- AS the previous discussed by them, add the mclk for codec.
  (https://patchwork.kernel.org/patch/8041001/)
- Add this patch included in kylin series patches.

Caesar Wang (6):
  ARM: dts: rockchip: add hdmi/vop device node for rk3036
  ARM: dts: rockchip: add mclk for rt5616 on kylin board
  ASoC: rt5616: add mclk property for rt5616 document
  ASoC: rt5616: trivial: fix the typo
  ASoC: rt5616: add the mclk for the codec driver
  ARM: dts: rockchip: support the spi for rk3036

zhengxing (2):
  clk: rockchip: rk3036: fix and add node id for emac clock
  ARM: dts: rockchip: add support emac for RK3036

 Documentation/devicetree/bindings/sound/rt5616.txt |   6 +
 arch/arm/boot/dts/rk3036-evb.dts                   |  23 ++
 arch/arm/boot/dts/rk3036-kylin.dts                 |  35 ++
 arch/arm/boot/dts/rk3036.dtsi                      | 145 ++++++++
 drivers/clk/rockchip/clk-rk3036.c                  |   9 +-
 include/dt-bindings/clock/rk3036-cru.h             |   2 +
 sound/soc/codecs/rt5616.c                          | 410 +++++++++++----------
 7 files changed, 442 insertions(+), 188 deletions(-)

-- 
1.9.1



From wxt at rock-chips.com  Mon Feb  1 19:40:50 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Tue,  2 Feb 2016 11:40:50 +0800
Subject: [PATCH v5 1/8] ARM: dts: rockchip: add hdmi/vop device node for rk3036
In-Reply-To: <1454384032-6794-1-git-send-email-wxt@rock-chips.com>
References: <1454384032-6794-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1454384453-7127-1-git-send-email-wxt@rock-chips.com>

This patch adds the needed display info for rk3036 SOCs.

The rk3036 support two overlay plane and one hwc plane,
it supports IOMMU, and its IOMMU same as rk3288's.
Meanwhile, add the inno hdmi for HDMI display.

Signed-off-by: Caesar Wang <wxt at rock-chips.com>

---

Changes in v5: None
Changes in v4:
- solve the lastest conflict, picked up from
  https://patchwork.kernel.org/patch/8040961/.

 arch/arm/boot/dts/rk3036-kylin.dts | 12 +++++++
 arch/arm/boot/dts/rk3036.dtsi      | 66 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 78 insertions(+)

diff --git a/arch/arm/boot/dts/rk3036-kylin.dts b/arch/arm/boot/dts/rk3036-kylin.dts
index 3332a7f..1037ad6 100644
--- a/arch/arm/boot/dts/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rk3036-kylin.dts
@@ -116,6 +116,10 @@
 	status = "okay";
 };
 
+&hdmi {
+	status = "okay";
+};
+
 &i2c1 {
 	clock-frequency = <400000>;
 
@@ -369,6 +373,14 @@
 	status = "okay";
 };
 
+&vop {
+	status = "okay";
+};
+
+&vop_mmu {
+	status = "okay";
+};
+
 &pinctrl {
 	leds {
 		led_ctl: led-ctl {
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 7897449..7abe3e2 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -147,6 +147,42 @@
 		};
 	};
 
+	vop: vop at 10118000 {
+		compatible = "rockchip,rk3036-vop";
+		reg = <0x10118000 0x19c>;
+		interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru ACLK_LCDC>, <&cru SCLK_LCDC>, <&cru HCLK_LCDC>;
+		clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+		resets = <&cru SRST_LCDC1_A>, <&cru SRST_LCDC1_H>, <&cru SRST_LCDC1_D>;
+		reset-names = "axi", "ahb", "dclk";
+		iommus = <&vop_mmu>;
+
+		status = "disabled";
+
+		vop_out: port {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			vop_out_hdmi: endpoint at 0 {
+				reg = <1>;
+				remote-endpoint = <&hdmi_in_vop>;
+			};
+		};
+	};
+
+	display-subsystem {
+		compatible = "rockchip,display-subsystem";
+		ports = <&vop_out>;
+	};
+
+	vop_mmu: iommu at 10118300 {
+		compatible = "rockchip,iommu";
+		reg = <0x10118300 0x100>;
+		interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "vop_mmu";
+		#iommu-cells = <0>;
+		status = "disabled";
+	};
+
 	gic: interrupt-controller at 10139000 {
 		compatible = "arm,gic-400";
 		interrupt-controller;
@@ -274,6 +310,27 @@
 		status = "disabled";
 	};
 
+	hdmi: hdmi at 20034000 {
+		compatible = "rockchip,rk3036-inno-hdmi";
+		reg = <0x20034000 0x4000>;
+		interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru  PCLK_HDMI>;
+		clock-names = "pclk";
+		rockchip,grf = <&grf>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&hdmi_ctl>;
+		status = "disabled";
+
+		hdmi_in: port {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			hdmi_in_vop: endpoint at 0 {
+				reg = <0>;
+				remote-endpoint = <&vop_out_hdmi>;
+			};
+		};
+	};
+
 	timer: timer at 20044000 {
 		compatible = "rockchip,rk3036-timer", "rockchip,rk3288-timer";
 		reg = <0x20044000 0x20>;
@@ -588,6 +645,15 @@
 			};
 		};
 
+		hdmi {
+			hdmi_ctl: hdmi-ctl {
+				rockchip,pins = <1 8  RK_FUNC_1 &pcfg_pull_none>,
+						<1 9  RK_FUNC_1 &pcfg_pull_none>,
+						<1 10 RK_FUNC_1 &pcfg_pull_none>,
+						<1 11 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
 		uart0 {
 			uart0_xfer: uart0-xfer {
 				rockchip,pins = <0 16 RK_FUNC_1 &pcfg_pull_default>,
-- 
1.9.1



From wxt at rock-chips.com  Mon Feb  1 19:40:51 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Tue,  2 Feb 2016 11:40:51 +0800
Subject: [PATCH v5 3/8] ARM: dts: rockchip: add support emac for RK3036
In-Reply-To: <1454384453-7127-1-git-send-email-wxt@rock-chips.com>
References: <1454384032-6794-1-git-send-email-wxt@rock-chips.com>
 <1454384453-7127-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1454384453-7127-2-git-send-email-wxt@rock-chips.com>

From: zhengxing <zhengxing at rock-chips.com>

This patch adds the emac device node for rk3036.
We need to let mac clock under the DPLL which is able to provide
the accurate 50MHz what mac_ref need, since that will cause some
unstable things if the cpufreq is working.

Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
Signed-off-by: Caesar Wang <wxt at rock-chips.com>

---

Changes in v5:
- remove unused commit content.

Changes in v4:
- included in the kylin series patches.
- This patch picked up from https://patchwork.kernel.org/patch/7924971/
- Change to solve the conflict based on the Heiko's branch.
- Make the emac parent as the DPLL.

 arch/arm/boot/dts/rk3036-evb.dts   | 23 ++++++++++++++++++++++
 arch/arm/boot/dts/rk3036-kylin.dts | 21 ++++++++++++++++++++
 arch/arm/boot/dts/rk3036.dtsi      | 39 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 83 insertions(+)

diff --git a/arch/arm/boot/dts/rk3036-evb.dts b/arch/arm/boot/dts/rk3036-evb.dts
index 28a0336..d7d3719 100644
--- a/arch/arm/boot/dts/rk3036-evb.dts
+++ b/arch/arm/boot/dts/rk3036-evb.dts
@@ -47,6 +47,17 @@
 	compatible = "rockchip,rk3036-evb", "rockchip,rk3036";
 };
 
+&emac {
+	pinctrl-names = "default";
+	pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&rmii_rst>;
+	phy = <&phy0>;
+	status = "okay";
+
+	phy0: ethernet-phy at 0 {
+		reg = <0>;
+	};
+};
+
 &i2c1 {
 	status = "okay";
 
@@ -62,3 +73,15 @@
 &uart2 {
 	status = "okay";
 };
+
+&pinctrl {
+	pcfg_output_high: pcfg-output-high {
+		output-high;
+	};
+
+	emac {
+		rmii_rst: rmii-rst {
+			rockchip,pins = <2 22 RK_FUNC_GPIO &pcfg_output_high>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/rk3036-kylin.dts b/arch/arm/boot/dts/rk3036-kylin.dts
index 1037ad6..cd45434 100644
--- a/arch/arm/boot/dts/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rk3036-kylin.dts
@@ -112,6 +112,17 @@
 	status = "okay";
 };
 
+&emac {
+	pinctrl-names = "default";
+	pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&rmii_rst>;
+	phy = <&phy0>;
+	status = "okay";
+
+	phy0: ethernet-phy at 0 {
+		reg = <0>;
+	};
+};
+
 &emmc {
 	status = "okay";
 };
@@ -382,6 +393,16 @@
 };
 
 &pinctrl {
+	pcfg_output_high: pcfg-output-high {
+		output-high;
+	};
+
+	emac {
+		rmii_rst: rmii-rst {
+			rockchip,pins = <2 22 RK_FUNC_GPIO &pcfg_output_high>;
+		};
+	};
+
 	leds {
 		led_ctl: led-ctl {
 			rockchip,pins = <2 30 RK_FUNC_GPIO &pcfg_pull_none>;
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 7abe3e2..532f232 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -222,6 +222,27 @@
 		status = "disabled";
 	};
 
+	emac: ethernet at 10200000 {
+		compatible = "rockchip,rk3036-emac", "snps,arc-emac";
+		reg = <0x10200000 0x4000>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		rockchip,grf = <&grf>;
+		clocks = <&cru HCLK_MAC>, <&cru SCLK_MACREF>, <&cru SCLK_MAC>;
+		clock-names = "hclk", "macref", "macclk";
+		/*
+		 * Fix the emac parent clock is DPLL instead of APLL.
+		 * since that will cause some unstable things if the cpufreq
+		 * is working. (e.g: the accurate 50MHz what mac_ref need)
+		 */
+		assigned-clocks = <&cru SCLK_MACPLL>;
+		assigned-clock-parents = <&cru PLL_DPLL>;
+		max-speed = <100>;
+		phy-mode = "rmii";
+		status = "disabled";
+	};
+
 	sdmmc: dwmmc at 10214000 {
 		compatible = "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc";
 		reg = <0x10214000 0x4000>;
@@ -613,6 +634,24 @@
 			};
 		};
 
+		emac {
+			emac_xfer: emac-xfer {
+				rockchip,pins = <2 10 RK_FUNC_1 &pcfg_pull_default>, /* crs_dvalid */
+						<2 13 RK_FUNC_1 &pcfg_pull_default>, /* tx_en */
+						<2 14 RK_FUNC_1 &pcfg_pull_default>, /* mac_clk */
+						<2 15 RK_FUNC_1 &pcfg_pull_default>, /* rx_err */
+						<2 16 RK_FUNC_1 &pcfg_pull_default>, /* rxd1 */
+						<2 17 RK_FUNC_1 &pcfg_pull_default>, /* rxd0 */
+						<2 18 RK_FUNC_1 &pcfg_pull_default>, /* txd1 */
+						<2 19 RK_FUNC_1 &pcfg_pull_default>; /* txd0 */
+			};
+
+			emac_mdio: emac-mdio {
+				rockchip,pins = <2 12 RK_FUNC_1 &pcfg_pull_default>, /* mac_md */
+						<2 25 RK_FUNC_1 &pcfg_pull_default>; /* mac_mdclk */
+			};
+		};
+
 		i2c0 {
 			i2c0_xfer: i2c0-xfer {
 				rockchip,pins = <0 0 RK_FUNC_1 &pcfg_pull_none>,
-- 
1.9.1



From wxt at rock-chips.com  Mon Feb  1 19:40:52 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Tue,  2 Feb 2016 11:40:52 +0800
Subject: [PATCH v5 4/8] ARM: dts: rockchip: add mclk for rt5616 on kylin board
In-Reply-To: <1454384453-7127-1-git-send-email-wxt@rock-chips.com>
References: <1454384032-6794-1-git-send-email-wxt@rock-chips.com>
 <1454384453-7127-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1454384453-7127-3-git-send-email-wxt@rock-chips.com>

The I2S block that provide the output clock as the mclk for rt5616,
That will be the master clock  input.

Signed-off-by: Caesar Wang <wxt at rock-chips.com>

---

Changes in v5: None
Changes in v4:
- AS the previous discussed by them, add the mclk for codec.
 (https://patchwork.kernel.org/patch/8041001/)

 arch/arm/boot/dts/rk3036-kylin.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/rk3036-kylin.dts b/arch/arm/boot/dts/rk3036-kylin.dts
index cd45434..b0473bc 100644
--- a/arch/arm/boot/dts/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rk3036-kylin.dts
@@ -328,6 +328,8 @@
 	rt5616: rt5616 at 1b {
 		compatible = "rt5616";
 		reg = <0x1b>;
+		clocks = <&cru SCLK_I2S_OUT>;
+		clock-names = "mclk";
 		#sound-dai-cells = <0>;
 	};
 };
-- 
1.9.1



From wxt at rock-chips.com  Mon Feb  1 19:40:53 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Tue,  2 Feb 2016 11:40:53 +0800
Subject: [PATCH v5 8/8] ARM: dts: rockchip: support the spi for rk3036
In-Reply-To: <1454384453-7127-1-git-send-email-wxt@rock-chips.com>
References: <1454384032-6794-1-git-send-email-wxt@rock-chips.com>
 <1454384453-7127-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1454384453-7127-4-git-send-email-wxt@rock-chips.com>

This patch adds the needed spi node for rk3036 dts.

We have to use the 4 bus emmc to work if someone want to support
the spi devices, since the pins are re-used by emmc data[5-8] and spi.
In some caseswe need to support the spi devices, that will waste the
emmc performance.

Moment, the kylin/evb hasn't the spi devices to work, so maybe we need wait
the new required to enable in kylin/evb board.

Anyway, the spi should be needed land in rk3036 dts.

Signed-off-by: Caesar Wang <wxt at rock-chips.com>

---

Changes in v5:
- Remove the unused, as Heiko comments on https://patchwork.kernel.org/patch/8147761/
- Modify the commit.

Changes in v4:
- Add this patch included in kylin series patches.

 arch/arm/boot/dts/rk3036.dtsi | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 532f232..30bb316 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -60,6 +60,7 @@
 		serial0 = &uart0;
 		serial1 = &uart1;
 		serial2 = &uart2;
+		spi = &spi;
 	};
 
 	memory {
@@ -485,6 +486,21 @@
 		status = "disabled";
 	};
 
+	spi: spi at 20074000 {
+		compatible = "rockchip,rockchip-spi";
+		reg = <0x20074000 0x1000>;
+		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+		clocks =<&cru PCLK_SPI>, <&cru SCLK_SPI>;
+		clock-names = "apb-pclk","spi_pclk";
+		dmas = <&pdma 8>, <&pdma 9>;
+		dma-names = "tx", "rx";
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi_txd &spi_rxd &spi_clk &spi_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
 	pinctrl: pinctrl {
 		compatible = "rockchip,rk3036-pinctrl";
 		rockchip,grf = <&grf>;
@@ -723,5 +739,29 @@
 			};
 			/* no rts / cts for uart2 */
 		};
+
+		spi {
+			spi_txd:spi-txd {
+				rockchip,pins = <1 29 RK_FUNC_3 &pcfg_pull_default>;
+			};
+
+			spi_rxd:spi-rxd {
+				rockchip,pins = <1 28 RK_FUNC_3 &pcfg_pull_default>;
+			};
+
+			spi_clk:spi-clk {
+				rockchip,pins = <2 0 RK_FUNC_2 &pcfg_pull_default>;
+			};
+
+			spi_cs0:spi-cs0 {
+				rockchip,pins = <1 30 RK_FUNC_3 &pcfg_pull_default>;
+
+			};
+
+			spi_cs1:spi-cs1 {
+				rockchip,pins = <1 31 RK_FUNC_3 &pcfg_pull_default>;
+
+			};
+		};
 	};
 };
-- 
1.9.1



From jassisinghbrar at gmail.com  Mon Feb  1 21:14:00 2016
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Tue, 2 Feb 2016 10:44:00 +0530
Subject: [PATCH v4 1/3] mailbox: Add support for APM X-Gene platform
 mailbox driver
In-Reply-To: <CADaLNDmSiK27wYBSo8-DsafmG5jUumUR5WYgConeSFXGNjH6+w@mail.gmail.com>
References: <CABb+yY2zHycEmsVvp8OFwpJ1PZgrEPpV-oOe56wgFJ=EE0nTcg@mail.gmail.com>
 <cover.1452912126.git.dhdang@apm.com>
 <abff73c051fd06a9dd3b04a1e7957ad5a9b69a18.1452912126.git.dhdang@apm.com>
 <CADaLNDmSiK27wYBSo8-DsafmG5jUumUR5WYgConeSFXGNjH6+w@mail.gmail.com>
Message-ID: <CABb+yY1cE152ZdfK_aeB8ufG=WfoUVB6BN8kXPphYgMBnpH-GA@mail.gmail.com>

On Tue, Feb 2, 2016 at 1:08 AM, Duc Dang <dhdang at apm.com> wrote:
> Hi Jassi,
>
> On Fri, Jan 15, 2016 at 6:57 PM, Duc Dang <dhdang at apm.com> wrote:
>> X-Gene mailbox controller provides 8 mailbox channels, with
>> each channel has a dedicated interrupt line.
>
> Did you have a chance to look into this version 4 of my mail-box patch?
>
Seems ok, please just fix the "section mismatch" warnings reported by
the build-bot.

Thanks


From takahiro.akashi at linaro.org  Mon Feb  1 21:18:15 2016
From: takahiro.akashi at linaro.org (AKASHI Takahiro)
Date: Tue, 2 Feb 2016 14:18:15 +0900
Subject: [PATCH 18/19] arm64: kdump: update a kernel doc
In-Reply-To: <20160122111331.GA23620@leverpostej>
References: <20160119122848.GA2904@dhcp-128-65.nay.redhat.com>
 <20160119125114.GH25024@leverpostej>
 <20160119134553.GA2986@dhcp-128-65.nay.redhat.com>
 <20160119140139.GC26545@leverpostej>
 <20160120024946.GA2999@dhcp-128-65.nay.redhat.com>
 <569F2439.9000604@linaro.org> <20160120114929.GB25829@leverpostej>
 <56A08076.8060302@linaro.org> <20160121120210.GD2581@leverpostej>
 <56A1CAD2.70403@linaro.org> <20160122111331.GA23620@leverpostej>
Message-ID: <56B03C17.5090606@linaro.org>

Mark,

On 01/22/2016 08:13 PM, Mark Rutland wrote:
> On Fri, Jan 22, 2016 at 03:23:14PM +0900, AKASHI Takahiro wrote:
>> On 01/21/2016 09:02 PM, Mark Rutland wrote:
>>> On Thu, Jan 21, 2016 at 03:53:42PM +0900, AKASHI Takahiro wrote:
>>>> On 01/20/2016 08:49 PM, Mark Rutland wrote:
>>>>> On Wed, Jan 20, 2016 at 03:07:53PM +0900, AKASHI Takahiro wrote:
>>>>>> On 01/20/2016 11:49 AM, Dave Young wrote:
>>>>>>> Firmware do not know kernel endianniess, kernel should respect firmware
>>>>>>> maps and adapt to it, it sounds like a generic issue not specfic to kexec.
>>>>>>
>>>>>> On arm64, a kernel image header has a bit field to specify the image's endianness.
>>>>>> Anyway, our current implementation replies on a user-supplied dtb to start BE kernel.
>>>>>
>>>>> The firmware should _never_ care about the kernel's endianness. The
>>>>> bootlaoder or first kernel shouldn't care about the next kernel's
>>>>> endianness apart from in exceptional circumstances. The DTB for a LE
>>>>> kernel should look identical to that passed to a BE kernel.
>>>>
>>>> Please note that I didn't say anything different from your last two statements.
>>>> The current arm64 kexec implementation doesn't do anything specific to BE,
>>>> but as far as BE kernel doesn't support UEFI, users are responsible for
>>>> providing a proper dtb.
>>>
>>> I'm just confused as to what you mean by a "proper dtb" in that case.
>>>
>>> If you just mean one with memory nodes hacked in, then that would
>>> currently be a way to make that work, yes.
>>
>> One of useful cases that I have in my mind is kdump.
>> We may want to use a small sub-set of dtb, especially devices, to
>> make the reboot more reliable. Device drivers are likely to be vulnerable
>> at crash.
>
> I don't think that we can reliably have userspace carve out devices from
> the DTB or from ACPI tables in order to achieve that. That's going to
> end up complex and/or incomplete. We also can't do this in the
> kexec_load_file / Secure Boot case.
>
> That's not to say we cannot try, as it's possible when using kexec_load.
> However, it's only going to be possible on a subset of systems, and it
> would probably make sense to reserve this approach to those cases we
> cannot work around by other means (e.g. whitelisting "safe" devices in
> the kdump kernel, forcing explicit resets, etc).
>
>>> It seems like the better option is to fix the BE kernel to support a
>>> UEFI memory map, as that solves other issues.
>>
>> Why did Ard throw away his patch?
>
> In the absence of kexec it wasn't necessary, it only supported a subset
> of the runtime services (and no other features like DMI IIRC), and it
> looked like it would be painful to debug (if something went wrong while
> a CPU was in LE mode, we couldn't even panic()).
>
> Given BE kernels on UEFI were never supported until that point, there
> wasn't a compelling reason to support that case.
>
> Even if we support the UEFI memory map, I don't think it's worth the
> effort to support runtime services, ACPI, and related code that's only
> ever been tested on LE. So realistically this would only work on systems
> using UEFI && DT rather than UEFI && ACPI.
>
>> So, are you now suggesting that we put both "elfcorehdr=" and
>> "usable-memory=" under /chosen in dtb?
>
> Yes.
>
>> That's fair enough.  (as far as nobody cares about incompatibility
>> with other archs.)
>
> Glad to hear! :)

I'm preparing for a new version based on our discussions.
Do you think that UEFI memory map support on BE kernel is a prerequisite
for accepting my kdump?

-Takahiro AKASHI

> Thanks,
> Mark.
>


From shawnguo at kernel.org  Mon Feb  1 21:33:04 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 2 Feb 2016 13:33:04 +0800
Subject: [PATCH v2 2/2] arm/mach-imx: enable big endian mode
In-Reply-To: <1453913976-30619-3-git-send-email-johannes@sipsolutions.net>
References: <1453913976-30619-1-git-send-email-johannes@sipsolutions.net>
 <1453913976-30619-3-git-send-email-johannes@sipsolutions.net>
Message-ID: <20160202053304.GA8307@tiger>

On Wed, Jan 27, 2016 at 05:59:36PM +0100, Johannes Berg wrote:
> Enable ARM big-endian mode on mach-imx. This requires adding some
> byte swapping in the debug functions (which otherwise hang forever)
> and of course the secondary core bringup.
> 
> Tested (on top of 4.4) on i.MX6 HummingBoard quad-core (IMX6Q).
> 
> The patch is pretty much as suggested by Arnd Bergmann, thanks!
> 
> Signed-off-by: Johannes Berg <johannes at sipsolutions.net>

We conventionally use "ARM: imx: ..." as the subject for IMX platform
patches.

> ---
>  arch/arm/include/debug/imx.S | 3 +++
>  arch/arm/mach-imx/Kconfig    | 1 +
>  arch/arm/mach-imx/headsmp.S  | 2 ++
>  3 files changed, 6 insertions(+)
> 
> diff --git a/arch/arm/include/debug/imx.S b/arch/arm/include/debug/imx.S
> index 619d8cc1ac12..92c44760d656 100644
> --- a/arch/arm/include/debug/imx.S
> +++ b/arch/arm/include/debug/imx.S
> @@ -11,6 +11,7 @@
>   *
>   */
>  
> +#include <asm/assembler.h>
>  #include "imx-uart.h"
>  
>  /*
> @@ -34,6 +35,7 @@
>  		.endm
>  
>  		.macro	senduart,rd,rx
> +		ARM_BE8(rev \rd, \rd)
>  		str	\rd, [\rx, #0x40]	@ TXDATA
>  		.endm
>  
> @@ -42,6 +44,7 @@
>  
>  		.macro	busyuart,rd,rx
>  1002:		ldr	\rd, [\rx, #0x98]	@ SR2
> +		ARM_BE8(rev \rd, \rd)
>  		tst	\rd, #1 << 3		@ TXDC
>  		beq	1002b			@ wait until transmit done
>  		.endm
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 15df34fbdf44..607e0fedbf1c 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -9,6 +9,7 @@ menuconfig ARCH_MXC
>  	select PM_OPP if PM
>  	select SOC_BUS
>  	select SRAM
> +	select ARCH_SUPPORTS_BIG_ENDIAN

It should be added in alphabetical order.

I fixed these two minor things and applied both patches.

Shawn

>  	help
>  	  Support for Freescale MXC/iMX-based family of processors
>  
> diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
> index b5e976816b63..6c28d28b3c64 100644
> --- a/arch/arm/mach-imx/headsmp.S
> +++ b/arch/arm/mach-imx/headsmp.S
> @@ -12,6 +12,7 @@
>  
>  #include <linux/linkage.h>
>  #include <linux/init.h>
> +#include <asm/assembler.h>
>  
>  diag_reg_offset:
>  	.word	g_diag_reg - .
> @@ -25,6 +26,7 @@ diag_reg_offset:
>  	.endm
>  
>  ENTRY(v7_secondary_startup)
> +ARM_BE8(setend be)			@ go BE8 if entered LE
>  	set_diag_reg
>  	b	secondary_startup
>  ENDPROC(v7_secondary_startup)
> -- 
> 2.6.2
> 
> 


From soren.brinkmann at xilinx.com  Mon Feb  1 21:55:56 2016
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Mon, 1 Feb 2016 21:55:56 -0800
Subject: [PATCH LINUX 0/6] Second part of xuartps fixes
In-Reply-To: <1452562901-17848-1-git-send-email-soren.brinkmann@xilinx.com>
References: <1452562901-17848-1-git-send-email-soren.brinkmann@xilinx.com>
Message-ID: <20160202055556.GD4215@xsjsorenbubuntu>

ping? Any comments?

	Thanks,
	S?ren

On Mon, 2016-01-11 at 17:41:35 -0800, Soren Brinkmann wrote:
> Hi,
> 
> this is the second part of fixes for xuartps that evolved from this
> series: https://lkml.org/lkml/2015/12/26/26.
> 
> This series, obviously, depends on the patches mentioned above. It
> includes several minor improvements and refactoring and the refactoring
> of the IRQ management, which prevents lock ups that could happen when
> RX-related IRQs fired while the receiver was disabled.
> 
> 	Thanks,
> 	S?ren
> 
> S?ren Brinkmann (6):
>   tty: xuartps: Move request_irq to after setting up the HW
>   tty: xuartps: Refactor IRQ handling
>   tty: xuartps: Cleanup: Reformat if-else
>   tty: xuartps: Improve sysrq handling
>   tty: xuartps: Remove '_OFFSET' suffix from #defines
>   tty: xuartps: Consolidate TX handling
> 
>  drivers/tty/serial/xilinx_uartps.c | 460 +++++++++++++++++--------------------
>  1 file changed, 216 insertions(+), 244 deletions(-)
> 
> -- 
> 2.7.0.3.g497ea1e
> 


From shawnguo at kernel.org  Mon Feb  1 22:18:42 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 2 Feb 2016 14:18:42 +0800
Subject: [PATCH] ARM: dts: imx51: add support for Ka-Ro electronics TX51
 modules
In-Reply-To: <1453292619-3560-1-git-send-email-LW@KARO-electronics.de>
References: <1453292619-3560-1-git-send-email-LW@KARO-electronics.de>
Message-ID: <20160202061842.GB8307@tiger>

On Wed, Jan 20, 2016 at 01:23:39PM +0100, Lothar Wa?mann wrote:
> The TX51-8xxx module series is a System On Module manufactured by
>   Ka-Ro electronics GmbH with the following characteristics:
>   Processor    Freescale i.MX515
>                  up to 800 MHz (commercial)
>                  up to 600 MHz (industrial)
>   RAM          128/256MB mobile DDR-SDRAM
>   ROM          128MB NAND Flash
>   RTC          DS1339 Real Time Clock
>   Power supply Single 3.1V to 5.5V
>   Size         26mm SO-DIMM
>   Temp. Range  0?C..70?C (-40?C..85?C)
> 
> Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
> ---
>  arch/arm/boot/dts/Makefile       |   3 +-
>  arch/arm/boot/dts/imx51-tx51.dts | 749 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 751 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/imx51-tx51.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index a4a6d70..ea70f34 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -277,7 +277,8 @@ dtb-$(CONFIG_SOC_IMX51) += \
>  	imx51-babbage.dtb \
>  	imx51-digi-connectcore-jsk.dtb \
>  	imx51-eukrea-mbimxsd51-baseboard.dtb \
> -	imx51-ts4800.dtb
> +	imx51-ts4800.dtb \
> +	imx51-tx51.dtb
>  dtb-$(CONFIG_SOC_IMX53) += \
>  	imx53-ard.dtb \
>  	imx53-m53evk.dtb \
> diff --git a/arch/arm/boot/dts/imx51-tx51.dts b/arch/arm/boot/dts/imx51-tx51.dts
> new file mode 100644
> index 0000000..80c5d60
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx51-tx51.dts
> @@ -0,0 +1,749 @@
> +/*
> + * Copyright 2012-2014 Lothar Wa?mann <LW at KARO-electronics.de>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */

We generally suggest GPL/X11 dual license for new dts to consider
non-Linux device tree users.

> +
> +/dts-v1/;
> +#include "imx51.dtsi"
> +#include <dt-bindings/pwm/pwm.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/ {
> +	model = "Ka-Ro electronics TX51 module";
> +	compatible = "karo,tx51", "fsl,imx51";
> +
> +	aliases {
> +		backlight = &backlight;
> +		display = &display;
> +		i2c1 = &i2c_gpio;
> +		usbotg = &usbotg;
> +		wlan0 = &wlan0;
> +	};
> +
> +	chosen {
> +		stdout-path = &uart1;
> +	};
> +
> +	backlight: pwm-backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm1 0 500000 PWM_POLARITY_INVERTED>;
> +		power-supply = <&reg_3v3>;
> +		brightness-levels = <
> +			  0  1  2  3  4  5  6  7  8  9
> +			 10 11 12 13 14 15 16 17 18 19
> +			 20 21 22 23 24 25 26 27 28 29
> +			 30 31 32 33 34 35 36 37 38 39
> +			 40 41 42 43 44 45 46 47 48 49
> +			 50 51 52 53 54 55 56 57 58 59
> +			 60 61 62 63 64 65 66 67 68 69
> +			 70 71 72 73 74 75 76 77 78 79
> +			 80 81 82 83 84 85 86 87 88 89
> +			 90 91 92 93 94 95 96 97 98 99
> +			100
> +		>;
> +		default-brightness-level = <50>;
> +	};
> +
> +	clocks {
> +		ckih1 {
> +			clock-frequency = <0>;
> +		};
> +
> +		mclk: clock at 0 {

I would like to see these fixed rate clocks are named in a consistent
way, maybe just drop 'reg' property and use a unique clock name to align
with what imx51.dtsi does.

> +			compatible = "fixed-clock";
> +			reg = <0>;
> +			#clock-cells = <0>;
> +			clock-output-names = "mclk";
> +			clock-frequency = <26000000>;
> +		};
> +
> +		clk_26M: clock at 1 {
> +			compatible = "fixed-clock";
> +			reg = <1>;
> +			#clock-cells = <0>;
> +			clock-output-names = "clk_26M";
> +			clock-frequency = <26000000>;
> +			gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		wlan_ref_clk: wlan-ref-clk {
> +			compatible = "ti,wilink-clock";

I do not see this compatible string is documented anywhere.  And how is
this compatible string used by kernel?

> +			#clock-cells = <0>;
> +			clock-frequency = <38400000>;
> +		};
> +	};
> +
> +	display: display at di0 {
> +		compatible = "fsl,imx-parallel-display";
> +		interface-pix-fmt = "rgb24";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_ipu_disp0>;
> +
> +		display-timings {
> +			VGA {
> +				clock-frequency = <25200000>;
> +				hactive = <640>;
> +				vactive = <480>;
> +				hback-porch = <48>;
> +				hsync-len = <96>;
> +				hfront-porch = <16>;
> +				vback-porch = <31>;
> +				vsync-len = <2>;
> +				vfront-porch = <12>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			ETV570 {
> +				clock-frequency = <25200000>;
> +				hactive = <640>;
> +				vactive = <480>;
> +				hback-porch = <114>;
> +				hsync-len = <30>;
> +				hfront-porch = <16>;
> +				vback-porch = <32>;
> +				vsync-len = <3>;
> +				vfront-porch = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			ET0350 {
> +				clock-frequency = <6413760>;
> +				hactive = <320>;
> +				vactive = <240>;
> +				hback-porch = <34>;
> +				hsync-len = <34>;
> +				hfront-porch = <20>;
> +				vback-porch = <15>;
> +				vsync-len = <3>;
> +				vfront-porch = <4>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			ET0430 {
> +				clock-frequency = <9009000>;
> +				hactive = <480>;
> +				vactive = <272>;
> +				hback-porch = <2>;
> +				hsync-len = <41>;
> +				hfront-porch = <2>;
> +				vback-porch = <2>;
> +				vsync-len = <10>;
> +				vfront-porch = <2>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <1>;
> +			};
> +
> +			ET0500 {
> +				clock-frequency = <33264000>;
> +				hactive = <800>;
> +				vactive = <480>;
> +				hback-porch = <88>;
> +				hsync-len = <128>;
> +				hfront-porch = <40>;
> +				vback-porch = <33>;
> +				vsync-len = <2>;
> +				vfront-porch = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			ET0700 { /* same as ET0500 */
> +				clock-frequency = <33264000>;
> +				hactive = <800>;
> +				vactive = <480>;
> +				hback-porch = <88>;
> +				hsync-len = <128>;
> +				hfront-porch = <40>;
> +				vback-porch = <33>;
> +				vsync-len = <2>;
> +				vfront-porch = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			ETQ570 {
> +				clock-frequency = <6596040>;
> +				hactive = <320>;
> +				vactive = <240>;
> +				hback-porch = <38>;
> +				hsync-len = <30>;
> +				hfront-porch = <30>;
> +				vback-porch = <16>;
> +				vsync-len = <3>;
> +				vfront-porch = <4>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +		};
> +
> +		port {
> +			display0_in: endpoint {
> +				remote-endpoint = <&ipu_di0_disp0>;
> +			};
> +		};
> +	};
> +
> +	i2c_gpio: i2c-gpio {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		compatible = "i2c-gpio";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_i2c_gpio>;
> +		gpios = <&gpio4 17 0
> +			 &gpio4 16 0>;
> +		clock-frequency = <400000>;
> +
> +		rtc1: ds1339 at 68 {
> +			compatible = "dallas,ds1339";
> +			reg = <0x68>;
> +		};
> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_stk5led>;
> +
> +		user {
> +			label = "Heartbeat";
> +			gpios = <&gpio4 10 0 GPIO_ACTIVE_HIGH>;
> +			linux,default-trigger = "heartbeat";
> +		};
> +	};
> +
> +	regulators {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		reg_2v5: regulator at 0 {

Device tree maintainers do not like the fake simple-bus container node.
We are asked to put these fixed regulators directly under root node,
with a unique node name like:

	reg_xxx: regulator-xxx {
		...
	};

> +			compatible = "regulator-fixed";
> +			reg = <0>;
> +			regulator-name = "2V5";
> +			regulator-min-microvolt = <2500000>;
> +			regulator-max-microvolt = <2500000>;
> +			regulator-always-on;
> +		};
> +
> +		reg_3v3: regulator at 1 {
> +			compatible = "regulator-fixed";
> +			reg = <1>;
> +			regulator-name = "3V3";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +			regulator-always-on;
> +		};
> +
> +		reg_etn_phy: regulator at 2 {
> +			compatible = "regulator-fixed";
> +			reg = <2>;
> +			regulator-name = "ETN PHY Power";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +			gpio = <&gpio1 3 GPIO_ACTIVE_HIGH>;
> +			enable-active-high;
> +			regulator-boot-on;
> +			regulator-always-on;
> +		};
> +
> +		reg_lcd_pwr: regulator at 5 {
> +			compatible = "regulator-fixed";
> +			reg = <5>;
> +			regulator-name = "LCD POWER";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +			gpio = <&gpio4 14 GPIO_ACTIVE_HIGH>;
> +			enable-active-high;
> +			regulator-boot-on;
> +			regulator-always-on;
> +		};
> +
> +		reg_lcd_reset: regulator at 6 {
> +			compatible = "regulator-fixed";
> +			reg = <6>;
> +			regulator-name = "LCD RESET";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_lcd_reset>;
> +			gpio = <&gpio4 13 GPIO_ACTIVE_HIGH>;
> +			enable-active-high;
> +			regulator-boot-on;
> +			regulator-always-on;
> +		};
> +
> +		reg_wlan0: regulator at 9 {
> +			compatible = "regulator-fixed";
> +			reg = <8>;
> +			regulator-name = "wlan0";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +			gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
> +			enable-active-high;
> +		};
> +	};
> +
> +	sound {
> +		compatible = "karo,tx51-audio-sgtl5000", "fsl,imx-audio-sgtl5000";
> +		model = "tx51-audio-sgtl5000";
> +		ssi-controller = <&ssi1>;
> +		audio-codec = <&sgtl5000>;
> +		audio-routing =
> +			"MIC_IN", "Mic Jack",
> +			"Mic Jack", "Mic Bias",
> +			"Headphone Jack", "HP_OUT";
> +		/* '1' based port numbers according to datasheet names */
> +		mux-int-port = <1>;
> +		mux-ext-port = <3>;
> +	};
> +
> +	usbphy {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		compatible = "simple-bus";
> +
> +		usbh1phy: usbphy at 0 {
> +			compatible = "usb-nop-xceiv";
> +			reg = <0>;
> +			clocks = <&clk_26M>;
> +			clock-names = "main_clk";
> +		};

This should probably go with the same way as fixed regulators.

> +	};
> +
> +	wlan0: tiwi-ble {
> +		compatible = "ti,wilink6";

Undocumented compatible string.

> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_wlan0>;
> +		clocks = <&wlan_ref_clk>;
> +		clock-names = "refclock";
> +		interrupt-parent = <&gpio1>;
> +		interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
> +	};
> +};
> +
> +&audmux {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_ssi1>;
> +	status = "okay";
> +};
> +
> +&ecspi1 {
> +	fsl,spi-num-chipselects = <2>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_ecspi1>;
> +	cs-gpios = <&gpio4 24 GPIO_ACTIVE_LOW>,
> +		   <&gpio4 25 GPIO_ACTIVE_LOW>;
> +	status = "okay";
> +
> +	spidev0: spi at 0 {
> +		compatible = "spidev";
> +		reg = <0>;
> +		spi-max-frequency = <54000000>;
> +	};
> +
> +	spidev1: spi at 1 {
> +		compatible = "spidev";
> +		reg = <1>;
> +		spi-max-frequency = <54000000>;
> +	};
> +};
> +
> +&esdhc1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_esdhc1>;
> +	cd-gpios = <&gpio3 8 GPIO_ACTIVE_LOW>;
> +	fsl,wp-controller;
> +	status = "okay";
> +};
> +
> +&esdhc2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_esdhc2 &pinctrl_wlan0>;
> +	vmmc-supply = <&reg_wlan0>;
> +	bus-width = <4>;
> +	no-1-8-v;
> +	fsl,wp-controller;
> +	cap-sdio-irq;
> +	non-removable;
> +	//cd-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>;

Drop it.

> +	status = "okay";
> +};
> +
> +&fec {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_fec>;
> +	phy-mode = "mii";
> +//	phy-handle = <&phy0>;
> +	local-mac-address = [000000000000]; /* will be set by U-Boot */
> +	status = "okay";
> +
> +	phy0: ethernet-phy at 0 {
> +		interrupt-parent = <&gpio3>;
> +		interrupts = <18 0>;
> +		device_type = "ethernet-phy";
> +	};

This probably works, but I think we should follow the more standard
bindings to put it like the following?


	phy-handle = <&phy0>;

	mdio {
		#address-cells = <1>;
		#size-cells = <0>;

		phy0: ethernet-phy at 0 {
			interrupt-parent = <&gpio3>;
			interrupts = <18 0>;
			device_type = "ethernet-phy";
		};
	};


> +};
> +
> +&ipu {
> +	status = "okay";
> +};
> +
> +&i2c2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c2>;
> +	status = "okay";
> +
> +	sgtl5000: sgtl5000 at 0a {

Use generic name like 'codec' for node might comply to DT convention
better.

> +		compatible = "fsl,sgtl5000";
> +		reg = <0x0a>;
> +		clocks = <&mclk>;
> +		VDDA-supply = <&reg_2v5>;
> +		VDDIO-supply = <&reg_3v3>;
> +	};
> +
> +	polytouch: edt-ft5x06 at 38 {
> +		compatible = "edt,edt-ft5x06";
> +		reg = <0x38>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_edt_ft5x06>;
> +		interrupt-parent = <&gpio1>;
> +		interrupts = <5 0>;
> +		reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
> +		wake-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>;
> +	};
> +
> +	touchscreen: tsc2007 at 48 {

	tsc2007: touchscreen at 48 {

> +		compatible = "ti,tsc2007";
> +		reg = <0x48>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_tsc2007>;
> +		interrupt-parent = <&gpio3>;
> +		interrupts = <3 0>;
> +		gpios = <&gpio3 3 GPIO_ACTIVE_LOW>;
> +		ti,x-plate-ohms = <660>;
> +		linux,wakeup;

Use the new standard 'wakeup-source' please.

https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h=imx/dt&id=1c49ad21c2cae607193da4495489c751d7147df2

> +	};
> +};
> +
> +&iomuxc {

Please move the node to the bottom of the file to make the reset a bit
easier for reading.

> +	imx51-tx51 {

Since commit 5fcdf6a7ed95 (pinctrl: imx: Allow parsing DT without
function nodes), this additional function container node can be saved.

> +		pinctrl_hog: hoggrp {
> +			fsl,pins = <
> +				MX51_PAD_GPIO1_7__GPIO1_7		0x20e0	/* 26MHz osc enable */
> +			>;
> +		};
> +
> +		pinctrl_ecspi1: ecspi1grp {
> +			fsl,pins = <
> +				MX51_PAD_CSPI1_SS0__ECSPI1_SS0		0x4
> +				MX51_PAD_CSPI1_SS1__ECSPI1_SS1		0x4
> +				MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK	0x5
> +				MX51_PAD_CSPI1_MOSI__ECSPI1_MOSI	0x85
> +				MX51_PAD_CSPI1_MISO__ECSPI1_MISO	0x185
> +				MX51_PAD_CSPI1_RDY__ECSPI1_RDY		0x84
> +			>;
> +		};
> +
> +		pinctrl_edt_ft5x06: edt-ft5x056grp {

I would suggest to not use any hyphen in pinctrl group node name to make
the naming looks more consistent.

> +			fsl,pins = <
> +				MX51_PAD_GPIO1_5__GPIO1_5		0x20e0	/* Interrupt */
> +				MX51_PAD_CSI2_PIXCLK__GPIO4_15		0x20e0	/* Reset */
> +				MX51_PAD_CSI2_D12__GPIO4_9		0x20e0	/* Wake */
> +			>;
> +		};
> +
> +		pinctrl_esdhc1: esdhc1grp {
> +			fsl,pins = <
> +				MX51_PAD_DISPB2_SER_RS__GPIO3_8 	0x1c0 /* SD1 CD */
> +				MX51_PAD_SD1_DATA0__SD1_DATA0		0x20d4
> +				MX51_PAD_SD1_DATA1__SD1_DATA1		0x20d4
> +				MX51_PAD_SD1_DATA2__SD1_DATA2		0x20d4
> +				MX51_PAD_SD1_DATA3__SD1_DATA3		0x20d4
> +				MX51_PAD_SD1_CMD__SD1_CMD		0x400020d4
> +				MX51_PAD_SD1_CLK__SD1_CLK		0x2004
> +			>;
> +		};
> +
> +		pinctrl_esdhc2: esdhc2grp {
> +			fsl,pins = <
> +				MX51_PAD_DISPB2_SER_DIO__GPIO3_6	0x1c0 /* SD2 CD */
> +				MX51_PAD_SD2_DATA0__SD2_DATA0		0x20d4
> +				MX51_PAD_SD2_DATA1__SD2_DATA1		0x20d4
> +				MX51_PAD_SD2_DATA2__SD2_DATA2		0x20d4
> +				MX51_PAD_SD2_DATA3__SD2_DATA3		0x20d4
> +				MX51_PAD_SD2_CMD__SD2_CMD		0x400020d4
> +				MX51_PAD_SD2_CLK__SD2_CLK		0x2004
> +			>;
> +		};
> +
> +		pinctrl_fec: fecgrp {
> +			fsl,pins = <
> +				MX51_PAD_EIM_A20__GPIO2_14		0x20e4	/* PHY reset */
> +				MX51_PAD_GPIO1_3__GPIO1_3		0x20e4	/* PHY power */
> +				MX51_PAD_NANDF_CS3__FEC_MDC		0x2004
> +				MX51_PAD_EIM_EB2__FEC_MDIO		0x0005
> +				MX51_PAD_NANDF_RB3__FEC_RX_CLK		0x2000
> +				MX51_PAD_NANDF_D11__FEC_RX_DV		0x2000
> +				MX51_PAD_NANDF_D9__FEC_RDATA0		0x2000
> +				MX51_PAD_EIM_EB3__FEC_RDATA1		0x0001
> +				MX51_PAD_EIM_CS2__FEC_RDATA2		0x0001
> +				MX51_PAD_EIM_CS3__FEC_RDATA3		0x0001
> +				MX51_PAD_EIM_CS4__FEC_RX_ER		0x0001
> +				MX51_PAD_NANDF_RDY_INT__FEC_TX_CLK	0x2000
> +				MX51_PAD_NANDF_CS7__FEC_TX_EN		0x2004
> +				MX51_PAD_NANDF_D8__FEC_TDATA0		0x2004
> +				MX51_PAD_NANDF_CS4__FEC_TDATA1		0x2004
> +				MX51_PAD_NANDF_CS5__FEC_TDATA2		0x2004
> +				MX51_PAD_NANDF_CS6__FEC_TDATA3		0x2004
> +				MX51_PAD_NANDF_RB2__FEC_COL		0x2000
> +				MX51_PAD_EIM_CS5__FEC_CRS		0x0005
> +				MX51_PAD_NANDF_CS2__GPIO3_18		0x20e4
> +			>;
> +		};
> +
> +		pinctrl_i2c2: ipu-i2c2grp {
> +			fsl,pins = <
> +				 MX51_PAD_EIM_D27__I2C2_SCL		0x40000004
> +				 MX51_PAD_EIM_D24__I2C2_SDA		0x40000004
> +			>;
> +		};
> +
> +		pinctrl_i2c_gpio: ipu-i2c-gpiogrp {
> +			fsl,pins = <
> +				 MX51_PAD_I2C1_CLK__GPIO4_16		0x40000004
> +				 MX51_PAD_I2C1_DAT__GPIO4_17		0x40000004
> +			>;
> +		};
> +
> +		pinctrl_ipu_disp0: ipu-disp0grp {
> +			fsl,pins = <
> +				MX51_PAD_DISP1_DAT0__DISP1_DAT0		0x5
> +				MX51_PAD_DISP1_DAT1__DISP1_DAT1		0x5
> +				MX51_PAD_DISP1_DAT2__DISP1_DAT2		0x5
> +				MX51_PAD_DISP1_DAT3__DISP1_DAT3		0x5
> +				MX51_PAD_DISP1_DAT4__DISP1_DAT4		0x5
> +				MX51_PAD_DISP1_DAT5__DISP1_DAT5		0x5
> +				MX51_PAD_DISP1_DAT6__DISP1_DAT6		0x5
> +				MX51_PAD_DISP1_DAT7__DISP1_DAT7		0x5
> +				MX51_PAD_DISP1_DAT8__DISP1_DAT8		0x5
> +				MX51_PAD_DISP1_DAT9__DISP1_DAT9		0x5
> +				MX51_PAD_DISP1_DAT10__DISP1_DAT10	0x5
> +				MX51_PAD_DISP1_DAT11__DISP1_DAT11	0x5
> +				MX51_PAD_DISP1_DAT12__DISP1_DAT12	0x5
> +				MX51_PAD_DISP1_DAT13__DISP1_DAT13	0x5
> +				MX51_PAD_DISP1_DAT14__DISP1_DAT14	0x5
> +				MX51_PAD_DISP1_DAT15__DISP1_DAT15	0x5
> +				MX51_PAD_DISP1_DAT16__DISP1_DAT16	0x5
> +				MX51_PAD_DISP1_DAT17__DISP1_DAT17	0x5
> +				MX51_PAD_DISP1_DAT18__DISP1_DAT18	0x5
> +				MX51_PAD_DISP1_DAT19__DISP1_DAT19	0x5
> +				MX51_PAD_DISP1_DAT20__DISP1_DAT20	0x5
> +				MX51_PAD_DISP1_DAT21__DISP1_DAT21	0x5
> +				MX51_PAD_DISP1_DAT22__DISP1_DAT22	0x5
> +				MX51_PAD_DISP1_DAT23__DISP1_DAT23	0x5
> +				MX51_PAD_DI1_PIN2__DI1_PIN2		0x5 /* HSYNC */
> +				MX51_PAD_DI1_PIN3__DI1_PIN3		0x5 /* VSYNC */
> +			>;
> +		};
> +
> +		pinctrl_kpp: kppgrp-1 {

The '-1' suffix means nothing and can just be dropped.

> +			fsl,pins = <
> +				MX51_PAD_KEY_ROW0__KEY_ROW0		0xe0
> +				MX51_PAD_KEY_ROW1__KEY_ROW1		0xe0
> +				MX51_PAD_KEY_ROW2__KEY_ROW2		0xe0
> +				MX51_PAD_KEY_ROW3__KEY_ROW3		0xe0
> +				MX51_PAD_KEY_COL0__KEY_COL0		0xe8
> +				MX51_PAD_KEY_COL1__KEY_COL1		0xe8
> +				MX51_PAD_KEY_COL2__KEY_COL2		0xe8
> +				MX51_PAD_KEY_COL3__KEY_COL3		0xe8
> +				MX51_PAD_KEY_COL4__KEY_COL4		0xe8
> +				MX51_PAD_KEY_COL5__KEY_COL5		0xe8
> +			>;
> +		};
> +
> +		pinctrl_lcd_pwr: lcd-pwrgrp {
> +			fsl,pins = <
> +				MX51_PAD_CSI2_HSYNC__GPIO4_14		0x4
> +			>;
> +		};
> +
> +		pinctrl_lcd_reset: lcd-resetgrp {
> +			fsl,pins = <
> +				MX51_PAD_CSI2_VSYNC__GPIO4_13		0x4
> +			>;
> +		};
> +
> +		pinctrl_pwm1: pwm1grp {
> +			fsl,pins = <
> +				MX51_PAD_GPIO1_2__PWM1_PWMO		0xf4
> +			>;
> +		};
> +
> +		pinctrl_ssi1: ssi1grp {
> +			fsl,pins = <
> +				MX51_PAD_AUD3_BB_RXD__AUD3_RXD		0x5
> +				MX51_PAD_AUD3_BB_TXD__AUD3_TXD		0x5
> +				MX51_PAD_AUD3_BB_CK__AUD3_TXC		0x5
> +				MX51_PAD_AUD3_BB_FS__AUD3_TXFS		0x5
> +			>;
> +		};
> +
> +		pinctrl_ssi2: ssi2grp {
> +			fsl,pins = <
> +				MX51_PAD_EIM_D29__AUD6_RXD		0x5
> +				MX51_PAD_EIM_D28__AUD6_TXD		0x5
> +				MX51_PAD_EIM_D30__AUD6_TXC		0x5
> +				MX51_PAD_EIM_D31__AUD6_TXFS		0x5
> +			>;
> +		};
> +
> +		pinctrl_stk5led: stk5ledgrp {
> +			fsl,pins = <
> +				MX51_PAD_CSI2_D13__GPIO4_10		0x20e4
> +			>;
> +		};
> +
> +		pinctrl_tsc2007: tsc2007grp {
> +			fsl,pins = <
> +				MX51_PAD_DI1_D0_CS__GPIO3_3		0xc0	/* Pen-Down Interrupt */
> +			>;
> +		};
> +
> +		pinctrl_uart1: uart1grp {
> +			fsl,pins = <
> +				MX51_PAD_UART1_RXD__UART1_RXD		0xc1
> +				MX51_PAD_UART1_TXD__UART1_TXD		0xc5
> +				MX51_PAD_UART1_RTS__UART1_RTS		0xc1
> +				MX51_PAD_UART1_CTS__UART1_CTS		0xc5
> +			>;
> +		};
> +
> +		pinctrl_uart2: uart2grp {
> +			fsl,pins = <
> +				MX51_PAD_UART2_RXD__UART2_RXD		0xc1
> +				MX51_PAD_UART2_TXD__UART2_TXD		0xc5
> +				MX51_PAD_EIM_D26__UART2_RTS		0xc1
> +				MX51_PAD_EIM_D25__UART2_CTS		0xc5
> +			>;
> +		};
> +
> +		pinctrl_uart3: uart3grp {
> +			fsl,pins = <
> +				MX51_PAD_UART3_RXD__UART3_RXD		0xc1
> +				MX51_PAD_UART3_TXD__UART3_TXD		0xc5
> +				MX51_PAD_EIM_D18__UART3_RTS		0xc1
> +				MX51_PAD_EIM_D17__UART3_CTS		0xc5
> +			>;
> +		};
> +
> +		pinctrl_wlan0: wlan0grp {
> +			fsl,pins = <
> +				MX51_PAD_CSI2_PIXCLK__GPIO4_15		0x04 /* WL_EN */
> +				MX51_PAD_GPIO1_5__GPIO1_5		0xf0 /* WL_IRQ */
> +			>;
> +		};
> +	};
> +};
> +
> +&ipu_di0_disp0 {
> +	remote-endpoint = <&display0_in>;
> +};
> +
> +&kpp {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_kpp>;
> +	linux,keymap = <	/* sample keymap */
> +		MATRIX_KEY(0, 0, KEY_POWER)
> +		MATRIX_KEY(0, 1, KEY_KP0)
> +		MATRIX_KEY(0, 2, KEY_KP1)
> +		MATRIX_KEY(0, 3, KEY_KP2)
> +		MATRIX_KEY(1, 0, KEY_KP3)
> +		MATRIX_KEY(1, 1, KEY_KP4)
> +		MATRIX_KEY(1, 2, KEY_KP5)
> +		MATRIX_KEY(1, 3, KEY_KP6)
> +		MATRIX_KEY(2, 0, KEY_KP7)
> +		MATRIX_KEY(2, 1, KEY_KP8)
> +		MATRIX_KEY(2, 2, KEY_KP9)
> +	>;
> +	status = "okay";
> +};
> +
> +&nfc {
> +	nand-bus-width = <8>;
> +	nand-ecc-mode = "hw";
> +	nand-on-flash-bbt;
> +	status = "okay";
> +};
> +
> +&pwm1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_pwm1>;
> +};
> +
> +&ssi1 {
> +	fsl,mode = "i2s-slave";

The "i2s-slave" of fsl,mode is deprecated and can be dropped.

Shawn

> +	codec-handle = <&sgtl5000>;
> +	status = "okay";
> +};
> +
> +&ssi2 {
> +	status = "disabled";
> +};
> +
> +&uart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart1>;
> +	fsl,uart-has-rtscts;
> +	status = "okay";
> +};
> +
> +&uart2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart2>;
> +	fsl,uart-has-rtscts;
> +	status = "okay";
> +};
> +
> +&uart3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart3>;
> +	fsl,uart-has-rtscts;
> +	status = "okay";
> +};
> +
> +&usbh1 {
> +	phy_type = "ulpi";
> +	fsl,usphy = <&usbh1phy>;
> +	disable-over-current;
> +	status = "okay";
> +};
> +
> +&usbotg {
> +	dr_mode = "peripheral";
> +	phy_type = "utmi_wide";
> +	disable-over-current;
> +	status = "okay";
> +};
> -- 
> 2.1.4
> 
> 


From shawnguo at kernel.org  Mon Feb  1 22:20:57 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 2 Feb 2016 14:20:57 +0800
Subject: [PATCH] ARM: dts: imx28-tx28: use correct mclk frequency
In-Reply-To: <1453293015-15980-1-git-send-email-LW@KARO-electronics.de>
References: <1453293015-15980-1-git-send-email-LW@KARO-electronics.de>
Message-ID: <20160202062057.GC8307@tiger>

On Wed, Jan 20, 2016 at 01:30:15PM +0100, Lothar Wa?mann wrote:
> The reference clock for the SGTL5000 is generated by a 26MHz crystal
> oscillator on the Ka-Ro electronics STK5 eval kits. Use the correct
> frequency setting in DTB.
> 
> Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>

Applied, thanks.


From shawnguo at kernel.org  Mon Feb  1 22:23:16 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 2 Feb 2016 14:23:16 +0800
Subject: [PATCH 1/6] dma: enable mxs-dma for imx6ul
In-Reply-To: <20160125121043.GJ11130@localhost>
References: <1453294626-17608-1-git-send-email-LW@KARO-electronics.de>
 <1453294626-17608-2-git-send-email-LW@KARO-electronics.de>
 <20160125121043.GJ11130@localhost>
Message-ID: <20160202062314.GD8307@tiger>

On Mon, Jan 25, 2016 at 05:40:43PM +0530, Vinod Koul wrote:
> On Wed, Jan 20, 2016 at 01:57:01PM +0100, Lothar Wa?mann wrote:
> > The mxs-dma unit is also available on i.MX6UL. Make it possible to
> > select it in Kconfig.
> 
> It should be dmaengine:xxx
> 
> With that
> 
> Acked-by: Vinod Koul <vinod.koul at intel.com>

I think this can go separately via dma tree.

Shawn

> 
> > 
> > Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
> > ---
> >  drivers/dma/Kconfig | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> > index 79b1390..2516524 100644
> > --- a/drivers/dma/Kconfig
> > +++ b/drivers/dma/Kconfig
> > @@ -341,12 +341,13 @@ config MV_XOR
> >  
> >  config MXS_DMA
> >  	bool "MXS DMA support"
> > -	depends on SOC_IMX23 || SOC_IMX28 || SOC_IMX6Q
> > +	depends on SOC_IMX23 || SOC_IMX28 || SOC_IMX6Q || SOC_MX6UL
> >  	select STMP_DEVICE
> >  	select DMA_ENGINE
> >  	help
> >  	  Support the MXS DMA engine. This engine including APBH-DMA
> > -	  and APBX-DMA is integrated into Freescale i.MX23/28/MX6Q/MX6DL chips.
> > +	  and APBX-DMA is integrated into Freescale
> > +	  i.MX23/28/MX6Q/MX6DL/MX6UL chips.
> >  
> >  config MX3_IPU
> >  	bool "MX3x Image Processing Unit support"
> > -- 
> > 2.1.4
> > 
> 
> -- 
> ~Vinod
> 


From wens at csie.org  Mon Feb  1 22:25:18 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue, 2 Feb 2016 14:25:18 +0800
Subject: [PATCH] pinctrl: sunxi: Add H3 R_PIO controller support
In-Reply-To: <20160201101225.GA19687@box2.japko.eu>
References: <20160201101225.GA19687@box2.japko.eu>
Message-ID: <CAGb2v65-X2_MoRm1=wAub9Y8Vpt-f-roYUT73jDk5Fnj17zKTw@mail.gmail.com>

On Mon, Feb 1, 2016 at 6:12 PM, Krzysztof Adamski <k at japko.eu> wrote:
> H3 has additional PIO controller similar to what we can find on A23.
> It's a 12 pin port, described in H3 Datasheet rev 1.1, pages 345-350.
>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>
> ---
> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
> arch/arm/boot/dts/sun8i-h3.dtsi                    |  12 +++
> drivers/pinctrl/sunxi/Kconfig                      |   4 +
> drivers/pinctrl/sunxi/Makefile                     |   1 +
> drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c         | 105
> +++++++++++++++++++++
> 5 files changed, 123 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
>
> diff --git
> a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> index 9213b27..730a917 100644
> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> @@ -20,6 +20,7 @@ Required properties:
>   "allwinner,sun9i-a80-pinctrl"
>   "allwinner,sun9i-a80-r-pinctrl"
>   "allwinner,sun8i-a83t-pinctrl"
> +  "allwinner,sun8i-h3-r-pinctrl"
>   "allwinner,sun8i-h3-pinctrl"

h3-r-pinctrl comes after h3-pinctrl


>
> - reg: Should contain the register physical address and length for the
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
> b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 1524130e..745f64c 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -493,5 +493,17 @@
>                         interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
>                                      <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
>                 };
> +
> +               r_pio: pinctrl at 01f02c00 {
> +                       compatible = "allwinner,sun8i-h3-r-pinctrl";
> +                       reg = <0x01f02c00 0x400>;
> +                       interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
> +                       clocks = <&bus_gates 69>;

This is probably wrong. According to other SoCs all R_ block peripherals
have clock gates and reset controls in the PRCM.

> +                       gpio-controller;
> +                       #gpio-cells = <3>;
> +                       interrupt-controller;
> +                       #interrupt-cells = <2>;
> +               };
> +

Extra new line here.

Also please split this into a separate patch.

>         };
> };
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index f8dbc8b..75a26c9 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -55,6 +55,10 @@ config PINCTRL_SUN8I_H3
>         def_bool MACH_SUN8I
>         select PINCTRL_SUNXI_COMMON
>
> +config PINCTRL_SUN8I_H3_R
> +       def_bool MACH_SUN8I
> +       select PINCTRL_SUNXI_COMMON
> +
> config PINCTRL_SUN9I_A80
>         def_bool MACH_SUN9I
>         select PINCTRL_SUNXI_COMMON
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index ef82f22..a5d56f1 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -14,5 +14,6 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23_R)     +=
> pinctrl-sun8i-a23-r.o
> obj-$(CONFIG_PINCTRL_SUN8I_A33)         += pinctrl-sun8i-a33.o
> obj-$(CONFIG_PINCTRL_SUN8I_A83T)        += pinctrl-sun8i-a83t.o
> obj-$(CONFIG_PINCTRL_SUN8I_H3)          += pinctrl-sun8i-h3.o
> +obj-$(CONFIG_PINCTRL_SUN8I_H3_R)       += pinctrl-sun8i-h3-r.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80)         += pinctrl-sun9i-a80.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80_R)       += pinctrl-sun9i-a80-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
> b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
> new file mode 100644
> index 0000000..6271ceb
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
> @@ -0,0 +1,105 @@
> +/*
> + * Allwinner H3 SoCs pinctrl driver.
> + *
> + * Copyright (C) 2016 Krzysztof Adamski <k at japko.eu>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/pinctrl/pinctrl.h>
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin sun8i_h3_r_pins[] = {
> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION(0x2, "s_twi"),         /* SCK */
> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),  /* PL_EINT0 */
> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION(0x2, "s_twi"),         /* SDA */
> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),  /* PL_EINT1 */
> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION(0x2, "s_uart"),        /* TX */
> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),  /* PL_EINT2 */
> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION(0x2, "s_uart"),        /* RX */
> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),  /* PL_EINT3 */
> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION(0x2, "s_jtag"),        /* MS */
> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),  /* PL_EINT4 */
> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 5),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION(0x2, "s_jtag"),        /* CK */
> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),  /* PL_EINT5 */
> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 6),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION(0x2, "s_jtag"),        /* DO */
> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),  /* PL_EINT6 */
> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 7),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION(0x2, "s_jtag"),        /* DI */
> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),  /* PL_EINT7 */
> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 8),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),  /* PL_EINT8 */
> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 9),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),  /* PL_EINT9 */
> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 10),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION(0x2, "s_pwn"),

Typo: s_pwm

Regards
ChenYu

> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)), /* PL_EINT10 */
> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 11),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION(0x2, "s_cir_rx"),
> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 11)), /* PL_EINT11 */
> +};
> +
> +static const struct sunxi_pinctrl_desc sun8i_h3_r_pinctrl_data = {
> +       .pins = sun8i_h3_r_pins,
> +       .npins = ARRAY_SIZE(sun8i_h3_r_pins),
> +       .irq_banks = 1,
> +       .pin_base = PL_BASE,
> +};
> +
> +static int sun8i_h3_r_pinctrl_probe(struct platform_device *pdev)
> +{
> +       return sunxi_pinctrl_init(pdev,
> +                                 &sun8i_h3_r_pinctrl_data);
> +}
> +
> +static const struct of_device_id sun8i_h3_r_pinctrl_match[] = {
> +       { .compatible = "allwinner,sun8i-h3-r-pinctrl", },
> +       {}
> +};
> +
> +static struct platform_driver sun8i_h3_r_pinctrl_driver = {
> +       .probe  = sun8i_h3_r_pinctrl_probe,
> +       .driver = {
> +               .name           = "sun8i-h3-r-pinctrl",
> +               .of_match_table = sun8i_h3_r_pinctrl_match,
> +       },
> +};
> +builtin_platform_driver(sun8i_h3_r_pinctrl_driver);
> --
> 2.4.2
>


From shawnguo at kernel.org  Mon Feb  1 22:31:06 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 2 Feb 2016 14:31:06 +0800
Subject: [PATCH 2/6] ARM: dts: imx6: use correct mclk frequency for audio
 codec
In-Reply-To: <1453294626-17608-3-git-send-email-LW@KARO-electronics.de>
References: <1453294626-17608-1-git-send-email-LW@KARO-electronics.de>
 <1453294626-17608-3-git-send-email-LW@KARO-electronics.de>
Message-ID: <20160202063106.GE8307@tiger>

On Wed, Jan 20, 2016 at 01:57:02PM +0100, Lothar Wa?mann wrote:
> The reference clock for the SGTL5000 is generated by a 26MHz crystal
> oscillator on the Ka-Ro electronics STK5 eval kits. Use the correct
> frequency setting in DTB.
> 
> Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>

Applied, thanks.

> ---
>  arch/arm/boot/dts/imx6qdl-tx6.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-tx6.dtsi b/arch/arm/boot/dts/imx6qdl-tx6.dtsi
> index 13cb7cc..9404668 100644
> --- a/arch/arm/boot/dts/imx6qdl-tx6.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-tx6.dtsi
> @@ -41,7 +41,7 @@
>  			compatible = "fixed-clock";
>  			reg = <0>;
>  			#clock-cells = <0>;
> -			clock-frequency = <27000000>;
> +			clock-frequency = <26000000>;
>  		};
>  	};
>  
> -- 
> 2.1.4
> 
> 


From shawnguo at kernel.org  Mon Feb  1 22:31:47 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 2 Feb 2016 14:31:47 +0800
Subject: [PATCH 3/6] ARM: dts: imx6qdl-tx6: add ENET_OUT clock to fec node
In-Reply-To: <1453294626-17608-4-git-send-email-LW@KARO-electronics.de>
References: <1453294626-17608-1-git-send-email-LW@KARO-electronics.de>
 <1453294626-17608-4-git-send-email-LW@KARO-electronics.de>
Message-ID: <20160202063147.GF8307@tiger>

On Wed, Jan 20, 2016 at 01:57:03PM +0100, Lothar Wa?mann wrote:
> ENET_OUT is used as reference clock for the ethernet PHY on the Ka-Ro
> TX6 modules. Specify this clock in DTB to let it be managed correctly
> by the driver.
> 
> Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>

Applied, thanks.


From wens at csie.org  Mon Feb  1 22:35:36 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue, 2 Feb 2016 14:35:36 +0800
Subject: [PATCH 09/14] ARM: dts: sun8i-a83t: Add mmc controller nodes
In-Reply-To: <1454203266-4450-10-git-send-email-vishnupatekar0510@gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-10-git-send-email-vishnupatekar0510@gmail.com>
Message-ID: <CAGb2v66DGsccAUe4XwZYOadUZ7J2QH1J==-MWgBEsNBfWLjr6A@mail.gmail.com>

On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
<vishnupatekar0510 at gmail.com> wrote:
> A83T mmc is compatible with earliers sunxi socs.
> This adds mmc0, mmc1, and mmc2 controller nodes for A83T.
>
> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
> ---
>  arch/arm/boot/dts/sun8i-a83t.dtsi | 57 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 57 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index b8c8b60..ac96aa1 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -276,6 +276,63 @@
>                 #size-cells = <1>;
>                 ranges;
>
> +               mmc0: mmc at 01c0f000 {
> +                       compatible = "allwinner,sun5i-a13-mmc";
> +                       reg = <0x01c0f000 0x1000>;
> +                       clocks = <&bus_gates 8>,
> +                                <&mmc0_clk 0>,
> +                                <&mmc0_clk 1>,
> +                                <&mmc0_clk 2>;
> +                       clock-names = "ahb",
> +                                     "mmc",
> +                                     "output",
> +                                     "sample";
> +                       resets = <&ahb_reset0 8>;
> +                       reset-names = "ahb";
> +                       interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
> +                       status = "disabled";
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +               };
> +
> +               mmc1: mmc at 01c10000 {
> +                       compatible = "allwinner,sun5i-a13-mmc";
> +                       reg = <0x01c10000 0x1000>;
> +                       clocks = <&bus_gates 9>,
> +                                <&mmc1_clk 0>,
> +                                <&mmc1_clk 1>,
> +                                <&mmc1_clk 2>;
> +                       clock-names = "ahb",
> +                                     "mmc",
> +                                     "output",
> +                                     "sample";
> +                       resets = <&ahb_reset0 9>;
> +                       reset-names = "ahb";
> +                       interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
> +                       status = "disabled";
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +               };
> +
> +               mmc2: mmc at 01c11000 {
> +                       compatible = "allwinner,sun5i-a13-mmc";
> +                       reg = <0x01c11000 0x1000>;
> +                       clocks = <&bus_gates 10>,
> +                                <&mmc2_clk 0>,
> +                                <&mmc2_clk 1>,
> +                                <&mmc2_clk 2>;
> +                       clock-names = "ahb",
> +                                     "mmc",
> +                                     "output",
> +                                     "sample";
> +                       resets = <&ahb_reset0 10>;
> +                       reset-names = "ahb";
> +                       interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
> +                       status = "disabled";
> +                       #address-cells = <1>;
> +                       #size-cells = <0>;
> +               };
> +

This patch looks good, except for the reset control I pointed out in
the other patch.

Regards
ChenYu

>                 pio: pinctrl at 01c20800 {
>                         compatible = "allwinner,sun8i-a83t-pinctrl";
>                         interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
> --
> 1.9.1
>


From shawnguo at kernel.org  Mon Feb  1 22:36:48 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 2 Feb 2016 14:36:48 +0800
Subject: [PATCH 4/6] ARM: dts: imx6: change TX6 module names due to new
 HW revision
In-Reply-To: <1453294626-17608-5-git-send-email-LW@KARO-electronics.de>
References: <1453294626-17608-1-git-send-email-LW@KARO-electronics.de>
 <1453294626-17608-5-git-send-email-LW@KARO-electronics.de>
Message-ID: <20160202063648.GG8307@tiger>

On Wed, Jan 20, 2016 at 01:57:04PM +0100, Lothar Wa?mann wrote:
> The second last digit of the Ka-Ro electronics TX-module names denotes
> the HW revision of the module. HW rev 1 and 3 of the TX6 modules can
> use the same DTB. Change this digit to 'x' to indicate that the DTB
> file can be used for both HW revisions.

This is simply a unnecessary churn of the source tree.  I wouldn't take
it.

Shawn

> 
> Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
> ---
>  arch/arm/boot/dts/Makefile                   |  10 +-
>  arch/arm/boot/dts/imx6dl-tx6u-801x.dts       | 177 -------------------
>  arch/arm/boot/dts/imx6dl-tx6u-80xx.dts       | 185 ++++++++++++++++++++
>  arch/arm/boot/dts/imx6dl-tx6u-811x.dts       | 150 ----------------
>  arch/arm/boot/dts/imx6dl-tx6u-81xx.dts       | 156 +++++++++++++++++
>  arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts | 103 -----------
>  arch/arm/boot/dts/imx6q-tx6q-1010.dts        | 177 -------------------
>  arch/arm/boot/dts/imx6q-tx6q-10x0-comtft.dts | 119 +++++++++++++
>  arch/arm/boot/dts/imx6q-tx6q-10x0.dts        | 191 ++++++++++++++++++++
>  arch/arm/boot/dts/imx6q-tx6q-1110.dts        | 154 -----------------
>  arch/arm/boot/dts/imx6q-tx6q-11x0.dts        | 249 +++++++++++++++++++++++++++
>  11 files changed, 905 insertions(+), 766 deletions(-)
>  delete mode 100644 arch/arm/boot/dts/imx6dl-tx6u-801x.dts
>  create mode 100644 arch/arm/boot/dts/imx6dl-tx6u-80xx.dts
>  delete mode 100644 arch/arm/boot/dts/imx6dl-tx6u-811x.dts
>  create mode 100644 arch/arm/boot/dts/imx6dl-tx6u-81xx.dts
>  delete mode 100644 arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts
>  delete mode 100644 arch/arm/boot/dts/imx6q-tx6q-1010.dts
>  create mode 100644 arch/arm/boot/dts/imx6q-tx6q-10x0-comtft.dts
>  create mode 100644 arch/arm/boot/dts/imx6q-tx6q-10x0.dts
>  delete mode 100644 arch/arm/boot/dts/imx6q-tx6q-1110.dts
>  create mode 100644 arch/arm/boot/dts/imx6q-tx6q-11x0.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index a4a6d70..5759aac 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -312,8 +312,8 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>  	imx6dl-sabrelite.dtb \
>  	imx6dl-sabresd.dtb \
>  	imx6dl-tx6dl-comtft.dtb \
> -	imx6dl-tx6u-801x.dtb \
> -	imx6dl-tx6u-811x.dtb \
> +	imx6dl-tx6u-80xx.dtb \
> +	imx6dl-tx6u-81xx.dtb \
>  	imx6dl-udoo.dtb \
>  	imx6dl-wandboard.dtb \
>  	imx6dl-wandboard-revb1.dtb \
> @@ -342,11 +342,11 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>  	imx6q-sabresd.dtb \
>  	imx6q-sbc6x.dtb \
>  	imx6q-tbs2910.dtb \
> -	imx6q-tx6q-1010.dtb \
> -	imx6q-tx6q-1010-comtft.dtb \
>  	imx6q-tx6q-1020.dtb \
>  	imx6q-tx6q-1020-comtft.dtb \
> -	imx6q-tx6q-1110.dtb \
> +	imx6q-tx6q-10x0-comtft.dtb \
> +	imx6q-tx6q-10x0.dtb \
> +	imx6q-tx6q-11x0.dtb \
>  	imx6q-udoo.dtb \
>  	imx6q-wandboard.dtb \
>  	imx6q-wandboard-revb1.dtb
> diff --git a/arch/arm/boot/dts/imx6dl-tx6u-801x.dts b/arch/arm/boot/dts/imx6dl-tx6u-801x.dts
> deleted file mode 100644
> index 5fe465c..0000000
> --- a/arch/arm/boot/dts/imx6dl-tx6u-801x.dts
> +++ /dev/null
> @@ -1,177 +0,0 @@
> -/*
> - * Copyright 2014 Lothar Wa?mann <LW at KARO-electronics.de>
> - *
> - * The code contained herein is licensed under the GNU General Public
> - * License. You may obtain a copy of the GNU General Public License
> - * Version 2 at the following locations:
> - *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> - */
> -
> -/dts-v1/;
> -#include "imx6dl.dtsi"
> -#include "imx6qdl-tx6.dtsi"
> -
> -/ {
> -	model = "Ka-Ro electronics TX6U-801x Module";
> -	compatible = "karo,imx6dl-tx6dl", "fsl,imx6dl";
> -
> -	aliases {
> -		display = &display;
> -	};
> -
> -	backlight: backlight {
> -		compatible = "pwm-backlight";
> -		pwms = <&pwm2 0 500000 PWM_POLARITY_INVERTED>;
> -		power-supply = <&reg_3v3>;
> -		/*
> -		 * a poor man's way to create a 1:1 relationship between
> -		 * the PWM value and the actual duty cycle
> -		 */
> -		brightness-levels = < 0  1  2  3  4  5  6  7  8  9
> -				     10 11 12 13 14 15 16 17 18 19
> -				     20 21 22 23 24 25 26 27 28 29
> -				     30 31 32 33 34 35 36 37 38 39
> -				     40 41 42 43 44 45 46 47 48 49
> -				     50 51 52 53 54 55 56 57 58 59
> -				     60 61 62 63 64 65 66 67 68 69
> -				     70 71 72 73 74 75 76 77 78 79
> -				     80 81 82 83 84 85 86 87 88 89
> -				     90 91 92 93 94 95 96 97 98 99
> -				    100>;
> -		default-brightness-level = <50>;
> -	};
> -
> -	display: display at di0 {
> -		compatible = "fsl,imx-parallel-display";
> -		interface-pix-fmt = "rgb24";
> -		pinctrl-names = "default";
> -		pinctrl-0 = <&pinctrl_disp0_1>;
> -		status = "okay";
> -
> -		port {
> -			display0_in: endpoint {
> -				remote-endpoint = <&ipu1_di0_disp0>;
> -			};
> -		};
> -
> -		display-timings {
> -			VGA {
> -				clock-frequency = <25200000>;
> -				hactive = <640>;
> -				vactive = <480>;
> -				hback-porch = <48>;
> -				hsync-len = <96>;
> -				hfront-porch = <16>;
> -				vback-porch = <31>;
> -				vsync-len = <2>;
> -				vfront-porch = <12>;
> -				hsync-active = <0>;
> -				vsync-active = <0>;
> -				de-active = <1>;
> -				pixelclk-active = <0>;
> -			};
> -
> -			ETV570 {
> -				clock-frequency = <25200000>;
> -				hactive = <640>;
> -				vactive = <480>;
> -				hback-porch = <114>;
> -				hsync-len = <30>;
> -				hfront-porch = <16>;
> -				vback-porch = <32>;
> -				vsync-len = <3>;
> -				vfront-porch = <10>;
> -				hsync-active = <0>;
> -				vsync-active = <0>;
> -				de-active = <1>;
> -				pixelclk-active = <0>;
> -			};
> -
> -			ET0350 {
> -				clock-frequency = <6413760>;
> -				hactive = <320>;
> -				vactive = <240>;
> -				hback-porch = <34>;
> -				hsync-len = <34>;
> -				hfront-porch = <20>;
> -				vback-porch = <15>;
> -				vsync-len = <3>;
> -				vfront-porch = <4>;
> -				hsync-active = <0>;
> -				vsync-active = <0>;
> -				de-active = <1>;
> -				pixelclk-active = <0>;
> -			};
> -
> -			ET0430 {
> -				clock-frequency = <9009000>;
> -				hactive = <480>;
> -				vactive = <272>;
> -				hback-porch = <2>;
> -				hsync-len = <41>;
> -				hfront-porch = <2>;
> -				vback-porch = <2>;
> -				vsync-len = <10>;
> -				vfront-porch = <2>;
> -				hsync-active = <0>;
> -				vsync-active = <0>;
> -				de-active = <1>;
> -				pixelclk-active = <1>;
> -			};
> -
> -			ET0500 {
> -				clock-frequency = <33264000>;
> -				hactive = <800>;
> -				vactive = <480>;
> -				hback-porch = <88>;
> -				hsync-len = <128>;
> -				hfront-porch = <40>;
> -				vback-porch = <33>;
> -				vsync-len = <2>;
> -				vfront-porch = <10>;
> -				hsync-active = <0>;
> -				vsync-active = <0>;
> -				de-active = <1>;
> -				pixelclk-active = <0>;
> -			};
> -
> -			ET0700 { /* same as ET0500 */
> -				clock-frequency = <33264000>;
> -				hactive = <800>;
> -				vactive = <480>;
> -				hback-porch = <88>;
> -				hsync-len = <128>;
> -				hfront-porch = <40>;
> -				vback-porch = <33>;
> -				vsync-len = <2>;
> -				vfront-porch = <10>;
> -				hsync-active = <0>;
> -				vsync-active = <0>;
> -				de-active = <1>;
> -				pixelclk-active = <0>;
> -			};
> -
> -			ETQ570 {
> -				clock-frequency = <6596040>;
> -				hactive = <320>;
> -				vactive = <240>;
> -				hback-porch = <38>;
> -				hsync-len = <30>;
> -				hfront-porch = <30>;
> -				vback-porch = <16>;
> -				vsync-len = <3>;
> -				vfront-porch = <4>;
> -				hsync-active = <0>;
> -				vsync-active = <0>;
> -				de-active = <1>;
> -				pixelclk-active = <0>;
> -			};
> -		};
> -        };
> -};
> -
> -&ipu1_di0_disp0 {
> -	remote-endpoint = <&display0_in>;
> -};
> diff --git a/arch/arm/boot/dts/imx6dl-tx6u-80xx.dts b/arch/arm/boot/dts/imx6dl-tx6u-80xx.dts
> new file mode 100644
> index 0000000..f6621d6
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-tx6u-80xx.dts
> @@ -0,0 +1,185 @@
> +/*
> + * Copyright 2014 Lothar Wa?mann <LW at KARO-electronics.de>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/dts-v1/;
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-tx6.dtsi"
> +
> +/ {
> +	model = "Ka-Ro electronics TX6U-801x/-803x Module";
> +	compatible = "karo,imx6dl-tx6dl", "fsl,imx6dl";
> +
> +	aliases {
> +		display = &display;
> +	};
> +
> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm2 0 500000 PWM_POLARITY_INVERTED>;
> +		power-supply = <&reg_3v3>;
> +		/*
> +		 * a poor man's way to create a 1:1 relationship between
> +		 * the PWM value and the actual duty cycle
> +		 */
> +		brightness-levels = < 0  1  2  3  4  5  6  7  8  9
> +				     10 11 12 13 14 15 16 17 18 19
> +				     20 21 22 23 24 25 26 27 28 29
> +				     30 31 32 33 34 35 36 37 38 39
> +				     40 41 42 43 44 45 46 47 48 49
> +				     50 51 52 53 54 55 56 57 58 59
> +				     60 61 62 63 64 65 66 67 68 69
> +				     70 71 72 73 74 75 76 77 78 79
> +				     80 81 82 83 84 85 86 87 88 89
> +				     90 91 92 93 94 95 96 97 98 99
> +				    100>;
> +		default-brightness-level = <50>;
> +	};
> +
> +	display: display at di0 {
> +		compatible = "fsl,imx-parallel-display";
> +		interface-pix-fmt = "rgb24";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_disp0_1>;
> +		status = "okay";
> +
> +		port {
> +			display0_in: endpoint {
> +				remote-endpoint = <&ipu1_di0_disp0>;
> +			};
> +		};
> +
> +		display-timings {
> +			VGA {
> +				clock-frequency = <25200000>;
> +				hactive = <640>;
> +				vactive = <480>;
> +				hback-porch = <48>;
> +				hsync-len = <96>;
> +				hfront-porch = <16>;
> +				vback-porch = <31>;
> +				vsync-len = <2>;
> +				vfront-porch = <12>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			ETV570 {
> +				clock-frequency = <25200000>;
> +				hactive = <640>;
> +				vactive = <480>;
> +				hback-porch = <114>;
> +				hsync-len = <30>;
> +				hfront-porch = <16>;
> +				vback-porch = <32>;
> +				vsync-len = <3>;
> +				vfront-porch = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			ET0350 {
> +				clock-frequency = <6413760>;
> +				hactive = <320>;
> +				vactive = <240>;
> +				hback-porch = <34>;
> +				hsync-len = <34>;
> +				hfront-porch = <20>;
> +				vback-porch = <15>;
> +				vsync-len = <3>;
> +				vfront-porch = <4>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			ET0430 {
> +				clock-frequency = <9009000>;
> +				hactive = <480>;
> +				vactive = <272>;
> +				hback-porch = <2>;
> +				hsync-len = <41>;
> +				hfront-porch = <2>;
> +				vback-porch = <2>;
> +				vsync-len = <10>;
> +				vfront-porch = <2>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <1>;
> +			};
> +
> +			ET0500 {
> +				clock-frequency = <33264000>;
> +				hactive = <800>;
> +				vactive = <480>;
> +				hback-porch = <88>;
> +				hsync-len = <128>;
> +				hfront-porch = <40>;
> +				vback-porch = <33>;
> +				vsync-len = <2>;
> +				vfront-porch = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			ET0700 { /* same as ET0500 */
> +				clock-frequency = <33264000>;
> +				hactive = <800>;
> +				vactive = <480>;
> +				hback-porch = <88>;
> +				hsync-len = <128>;
> +				hfront-porch = <40>;
> +				vback-porch = <33>;
> +				vsync-len = <2>;
> +				vfront-porch = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			ETQ570 {
> +				clock-frequency = <6596040>;
> +				hactive = <320>;
> +				vactive = <240>;
> +				hback-porch = <38>;
> +				hsync-len = <30>;
> +				hfront-porch = <30>;
> +				vback-porch = <16>;
> +				vsync-len = <3>;
> +				vfront-porch = <4>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +		};
> +	};
> +};
> +
> +&ipu1_di0_disp0 {
> +	remote-endpoint = <&display0_in>;
> +};
> +
> +&reg_lcd0_pwr {
> +	status = "okay";
> +};
> +
> +&reg_lcd1_pwr {
> +	status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/imx6dl-tx6u-811x.dts b/arch/arm/boot/dts/imx6dl-tx6u-811x.dts
> deleted file mode 100644
> index c275eec..0000000
> --- a/arch/arm/boot/dts/imx6dl-tx6u-811x.dts
> +++ /dev/null
> @@ -1,150 +0,0 @@
> -/*
> - * Copyright 2014 Lothar Wa?mann <LW at KARO-electronics.de>
> - *
> - * The code contained herein is licensed under the GNU General Public
> - * License. You may obtain a copy of the GNU General Public License
> - * Version 2 at the following locations:
> - *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> - */
> -
> -/dts-v1/;
> -#include "imx6dl.dtsi"
> -#include "imx6qdl-tx6.dtsi"
> -
> -/ {
> -	model = "Ka-Ro electronics TX6U-811x Module";
> -	compatible = "karo,imx6dl-tx6dl", "fsl,imx6dl";
> -
> -	aliases {
> -		display = &lvds0;
> -		lvds0 = &lvds0;
> -		lvds1 = &lvds1;
> -	};
> -
> -	backlight0: backlight0 {
> -		compatible = "pwm-backlight";
> -		pwms = <&pwm2 0 500000 0>;
> -		power-supply = <&reg_lcd0_pwr>;
> -		/*
> -		 * a poor man's way to create a 1:1 relationship between
> -		 * the PWM value and the actual duty cycle
> -		 */
> -		brightness-levels = < 0  1  2  3  4  5  6  7  8  9
> -				     10 11 12 13 14 15 16 17 18 19
> -				     20 21 22 23 24 25 26 27 28 29
> -				     30 31 32 33 34 35 36 37 38 39
> -				     40 41 42 43 44 45 46 47 48 49
> -				     50 51 52 53 54 55 56 57 58 59
> -				     60 61 62 63 64 65 66 67 68 69
> -				     70 71 72 73 74 75 76 77 78 79
> -				     80 81 82 83 84 85 86 87 88 89
> -				     90 91 92 93 94 95 96 97 98 99
> -				    100>;
> -		default-brightness-level = <50>;
> -	};
> -
> -	backlight1: backlight1 {
> -		compatible = "pwm-backlight";
> -		pwms = <&pwm1 0 500000 0>;
> -		power-supply = <&reg_lcd1_pwr>;
> -		/*
> -		 * a poor man's way to create a 1:1 relationship between
> -		 * the PWM value and the actual duty cycle
> -		 */
> -		brightness-levels = < 0  1  2  3  4  5  6  7  8  9
> -				     10 11 12 13 14 15 16 17 18 19
> -				     20 21 22 23 24 25 26 27 28 29
> -				     30 31 32 33 34 35 36 37 38 39
> -				     40 41 42 43 44 45 46 47 48 49
> -				     50 51 52 53 54 55 56 57 58 59
> -				     60 61 62 63 64 65 66 67 68 69
> -				     70 71 72 73 74 75 76 77 78 79
> -				     80 81 82 83 84 85 86 87 88 89
> -				     90 91 92 93 94 95 96 97 98 99
> -				    100>;
> -		default-brightness-level = <50>;
> -	};
> -};
> -
> -&i2c3 {
> -	polytouch2: eeti at 04 {
> -		compatible = "eeti,egalax_ts";
> -		reg = <0x04>;
> -		pinctrl-names = "default";
> -		pinctrl-0 = <&pinctrl_eeti>;
> -		interrupt-parent = <&gpio3>;
> -		interrupts = <22 0>;
> -		wakeup-gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
> -		linux,wakeup;
> -	};
> -};
> -
> -&iomuxc {
> -	imx6dl-tx6u-811x {
> -		pinctrl_eeti: eetigrp {
> -			fsl,pins = <
> -				MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b1 /* Interrupt */
> -			>;
> -		};
> -	};
> -};
> -
> -&kpp {
> -	status = "disabled"; /* pad conflict with backlight1 PWM */
> -};
> -
> -&ldb {
> -	status = "okay";
> -
> -	lvds0: lvds-channel at 0 {
> -		fsl,data-mapping = "spwg";
> -		fsl,data-width = <18>;
> -		status = "okay";
> -
> -		display-timings {
> -			native-mode = <&lvds_timing0>;
> -			lvds_timing0: hsd100pxn1 {
> -				clock-frequency = <65000000>;
> -				hactive = <1024>;
> -				vactive = <768>;
> -				hback-porch = <220>;
> -				hfront-porch = <40>;
> -				vback-porch = <21>;
> -				vfront-porch = <7>;
> -				hsync-len = <60>;
> -				vsync-len = <10>;
> -				de-active = <1>;
> -				pixelclk-active = <1>;
> -			};
> -		};
> -	};
> -
> -	lvds1: lvds-channel at 1 {
> -		fsl,data-mapping = "spwg";
> -		fsl,data-width = <18>;
> -		status = "disabled";
> -
> -		display-timings {
> -			native-mode = <&lvds_timing1>;
> -			lvds_timing1: hsd100pxn1 {
> -				clock-frequency = <65000000>;
> -				hactive = <1024>;
> -				vactive = <768>;
> -				hback-porch = <220>;
> -				hfront-porch = <40>;
> -				vback-porch = <21>;
> -				vfront-porch = <7>;
> -				hsync-len = <60>;
> -				vsync-len = <10>;
> -				de-active = <1>;
> -				pixelclk-active = <1>;
> -			};
> -		};
> -	};
> -};
> -
> -&pwm1 {
> -	status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/imx6dl-tx6u-81xx.dts b/arch/arm/boot/dts/imx6dl-tx6u-81xx.dts
> new file mode 100644
> index 0000000..5ff8e13
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-tx6u-81xx.dts
> @@ -0,0 +1,156 @@
> +/*
> + * Copyright 2014 Lothar Wa?mann <LW at KARO-electronics.de>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/dts-v1/;
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-tx6.dtsi"
> +
> +/ {
> +	model = "Ka-Ro electronics TX6U-81xx Module";
> +	compatible = "karo,imx6dl-tx6dl", "fsl,imx6dl";
> +
> +	aliases {
> +		display = &lvds0;
> +		lvds0 = &lvds0;
> +		lvds1 = &lvds1;
> +	};
> +
> +	backlight0: backlight0 {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm2 0 500000 0>;
> +		power-supply = <&reg_3v3>;
> +		/*
> +		 * a poor man's way to create a 1:1 relationship between
> +		 * the PWM value and the actual duty cycle
> +		 */
> +		brightness-levels = < 0  1  2  3  4  5  6  7  8  9
> +				     10 11 12 13 14 15 16 17 18 19
> +				     20 21 22 23 24 25 26 27 28 29
> +				     30 31 32 33 34 35 36 37 38 39
> +				     40 41 42 43 44 45 46 47 48 49
> +				     50 51 52 53 54 55 56 57 58 59
> +				     60 61 62 63 64 65 66 67 68 69
> +				     70 71 72 73 74 75 76 77 78 79
> +				     80 81 82 83 84 85 86 87 88 89
> +				     90 91 92 93 94 95 96 97 98 99
> +				    100>;
> +		default-brightness-level = <50>;
> +	};
> +
> +	backlight1: backlight1 {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm1 0 500000 0>;
> +		power-supply = <&reg_3v3>;
> +		/*
> +		 * a poor man's way to create a 1:1 relationship between
> +		 * the PWM value and the actual duty cycle
> +		 */
> +		brightness-levels = < 0  1  2  3  4  5  6  7  8  9
> +				     10 11 12 13 14 15 16 17 18 19
> +				     20 21 22 23 24 25 26 27 28 29
> +				     30 31 32 33 34 35 36 37 38 39
> +				     40 41 42 43 44 45 46 47 48 49
> +				     50 51 52 53 54 55 56 57 58 59
> +				     60 61 62 63 64 65 66 67 68 69
> +				     70 71 72 73 74 75 76 77 78 79
> +				     80 81 82 83 84 85 86 87 88 89
> +				     90 91 92 93 94 95 96 97 98 99
> +				    100>;
> +		default-brightness-level = <50>;
> +	};
> +};
> +
> +&i2c3 {
> +	polytouch1: eeti at 04 {
> +		compatible = "eeti,egalax_ts";
> +		reg = <0x04>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_eeti>;
> +		interrupt-parent = <&gpio3>;
> +		interrupts = <22 0>;
> +		wakeup-gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
> +		linux,wakeup;
> +	};
> +};
> +
> +&iomuxc {
> +	imx6dl-tx6u-81xx {
> +		pinctrl_eeti: eetigrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b1 /* Interrupt */
> +			>;
> +		};
> +	};
> +};
> +
> +&kpp {
> +	status = "disabled"; /* pads partially clash with backlight1 PWM */
> +};
> +
> +&ldb {
> +	status = "okay";
> +
> +	lvds0: lvds-channel at 0 {
> +		fsl,data-mapping = "spwg";
> +		fsl,data-width = <18>;
> +		status = "okay";
> +
> +		display-timings {
> +			native-mode = <&lvds0_timing0>;
> +
> +			lvds0_timing0: hsd100pxn1 {
> +				clock-frequency = <65000000>;
> +				hactive = <1024>;
> +				vactive = <768>;
> +				hback-porch = <220>;
> +				hfront-porch = <40>;
> +				vback-porch = <21>;
> +				vfront-porch = <7>;
> +				hsync-len = <60>;
> +				vsync-len = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <1>;
> +			};
> +		};
> +	};
> +
> +	lvds1: lvds-channel at 1 {
> +		fsl,data-mapping = "spwg";
> +		fsl,data-width = <18>;
> +		status = "disabled";
> +
> +		display-timings {
> +			native-mode = <&lvds1_timing0>;
> +
> +			lvds1_timing0: hsd100pxn1 {
> +				clock-frequency = <65000000>;
> +				hactive = <1024>;
> +				vactive = <768>;
> +				hback-porch = <220>;
> +				hfront-porch = <40>;
> +				vback-porch = <21>;
> +				vfront-porch = <7>;
> +				hsync-len = <60>;
> +				vsync-len = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <1>;
> +			};
> +		};
> +	};
> +};
> +
> +&pwm1 {
> +	status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts b/arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts
> deleted file mode 100644
> index b18fae1..0000000
> --- a/arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts
> +++ /dev/null
> @@ -1,103 +0,0 @@
> -/*
> - * Copyright 2014 Lothar Wa?mann <LW at KARO-electronics.de>
> - *
> - * The code contained herein is licensed under the GNU General Public
> - * License. You may obtain a copy of the GNU General Public License
> - * Version 2 at the following locations:
> - *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> - */
> -
> -/dts-v1/;
> -#include "imx6q.dtsi"
> -#include "imx6qdl-tx6.dtsi"
> -
> -/ {
> -	model = "Ka-Ro electronics TX6Q-1010 Module on CoMpact TFT";
> -	compatible = "karo,imx6q-tx6q", "fsl,imx6q";
> -
> -	aliases {
> -		display = &display;
> -	};
> -
> -	backlight: backlight {
> -		compatible = "pwm-backlight";
> -		pwms = <&pwm2 0 500000 0>;
> -		power-supply = <&reg_3v3>;
> -		/*
> -		 * a poor man's way to create a 1:1 relationship between
> -		 * the PWM value and the actual duty cycle
> -		 */
> -		brightness-levels = < 0  1  2  3  4  5  6  7  8  9
> -				     10 11 12 13 14 15 16 17 18 19
> -				     20 21 22 23 24 25 26 27 28 29
> -				     30 31 32 33 34 35 36 37 38 39
> -				     40 41 42 43 44 45 46 47 48 49
> -				     50 51 52 53 54 55 56 57 58 59
> -				     60 61 62 63 64 65 66 67 68 69
> -				     70 71 72 73 74 75 76 77 78 79
> -				     80 81 82 83 84 85 86 87 88 89
> -				     90 91 92 93 94 95 96 97 98 99
> -				    100>;
> -		default-brightness-level = <50>;
> -	};
> -
> -	display: display at di0 {
> -		compatible = "fsl,imx-parallel-display";
> -		interface-pix-fmt = "rgb24";
> -		pinctrl-names = "default";
> -		pinctrl-0 = <&pinctrl_disp0_1>;
> -		status = "okay";
> -
> -		port {
> -			display0_in: endpoint {
> -				remote-endpoint = <&ipu1_di0_disp0>;
> -			};
> -		};
> -
> -		display-timings {
> -			native-mode = <&ET070001DM6>;
> -
> -			ET070001DM6: CoMTFT { /* same as ET0700 but with inverted pixel clock */
> -				clock-frequency = <33264000>;
> -				hactive = <800>;
> -				vactive = <480>;
> -				hback-porch = <88>;
> -				hsync-len = <128>;
> -				hfront-porch = <40>;
> -				vback-porch = <33>;
> -				vsync-len = <2>;
> -				vfront-porch = <10>;
> -				hsync-active = <0>;
> -				vsync-active = <0>;
> -				de-active = <1>;
> -				pixelclk-active = <1>;
> -			};
> -		};
> -        };
> -};
> -
> -&can1 {
> -	status = "disabled";
> -};
> -
> -&can2 {
> -	xceiver-supply = <&reg_3v3>;
> -};
> -
> -&ipu1_di0_disp0 {
> -	remote-endpoint = <&display0_in>;
> -};
> -
> -&kpp {
> -	status = "disabled";
> -};
> -
> -&reg_can_xcvr {
> -	status = "disabled";
> -};
> -
> -&touchscreen {
> -	status = "disabled";
> -};
> diff --git a/arch/arm/boot/dts/imx6q-tx6q-1010.dts b/arch/arm/boot/dts/imx6q-tx6q-1010.dts
> deleted file mode 100644
> index b58ec9c..0000000
> --- a/arch/arm/boot/dts/imx6q-tx6q-1010.dts
> +++ /dev/null
> @@ -1,177 +0,0 @@
> -/*
> - * Copyright 2014 Lothar Wa?mann <LW at KARO-electronics.de>
> - *
> - * The code contained herein is licensed under the GNU General Public
> - * License. You may obtain a copy of the GNU General Public License
> - * Version 2 at the following locations:
> - *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> - */
> -
> -/dts-v1/;
> -#include "imx6q.dtsi"
> -#include "imx6qdl-tx6.dtsi"
> -
> -/ {
> -	model = "Ka-Ro electronics TX6Q-1010 Module";
> -	compatible = "karo,imx6q-tx6q", "fsl,imx6q";
> -
> -	aliases {
> -		display = &display;
> -	};
> -
> -	backlight: backlight {
> -		compatible = "pwm-backlight";
> -		pwms = <&pwm2 0 500000 PWM_POLARITY_INVERTED>;
> -		power-supply = <&reg_3v3>;
> -		/*
> -		 * a poor man's way to create a 1:1 relationship between
> -		 * the PWM value and the actual duty cycle
> -		 */
> -		brightness-levels = < 0  1  2  3  4  5  6  7  8  9
> -				     10 11 12 13 14 15 16 17 18 19
> -				     20 21 22 23 24 25 26 27 28 29
> -				     30 31 32 33 34 35 36 37 38 39
> -				     40 41 42 43 44 45 46 47 48 49
> -				     50 51 52 53 54 55 56 57 58 59
> -				     60 61 62 63 64 65 66 67 68 69
> -				     70 71 72 73 74 75 76 77 78 79
> -				     80 81 82 83 84 85 86 87 88 89
> -				     90 91 92 93 94 95 96 97 98 99
> -				    100>;
> -		default-brightness-level = <50>;
> -	};
> -
> -	display: display at di0 {
> -		compatible = "fsl,imx-parallel-display";
> -		interface-pix-fmt = "rgb24";
> -		pinctrl-names = "default";
> -		pinctrl-0 = <&pinctrl_disp0_1>;
> -		status = "okay";
> -
> -		port {
> -			display0_in: endpoint {
> -				remote-endpoint = <&ipu1_di0_disp0>;
> -			};
> -		};
> -
> -		display-timings {
> -			VGA {
> -				clock-frequency = <25200000>;
> -				hactive = <640>;
> -				vactive = <480>;
> -				hback-porch = <48>;
> -				hsync-len = <96>;
> -				hfront-porch = <16>;
> -				vback-porch = <31>;
> -				vsync-len = <2>;
> -				vfront-porch = <12>;
> -				hsync-active = <0>;
> -				vsync-active = <0>;
> -				de-active = <1>;
> -				pixelclk-active = <0>;
> -			};
> -
> -			ETV570 {
> -				clock-frequency = <25200000>;
> -				hactive = <640>;
> -				vactive = <480>;
> -				hback-porch = <114>;
> -				hsync-len = <30>;
> -				hfront-porch = <16>;
> -				vback-porch = <32>;
> -				vsync-len = <3>;
> -				vfront-porch = <10>;
> -				hsync-active = <0>;
> -				vsync-active = <0>;
> -				de-active = <1>;
> -				pixelclk-active = <0>;
> -			};
> -
> -			ET0350 {
> -				clock-frequency = <6413760>;
> -				hactive = <320>;
> -				vactive = <240>;
> -				hback-porch = <34>;
> -				hsync-len = <34>;
> -				hfront-porch = <20>;
> -				vback-porch = <15>;
> -				vsync-len = <3>;
> -				vfront-porch = <4>;
> -				hsync-active = <0>;
> -				vsync-active = <0>;
> -				de-active = <1>;
> -				pixelclk-active = <0>;
> -			};
> -
> -			ET0430 {
> -				clock-frequency = <9009000>;
> -				hactive = <480>;
> -				vactive = <272>;
> -				hback-porch = <2>;
> -				hsync-len = <41>;
> -				hfront-porch = <2>;
> -				vback-porch = <2>;
> -				vsync-len = <10>;
> -				vfront-porch = <2>;
> -				hsync-active = <0>;
> -				vsync-active = <0>;
> -				de-active = <1>;
> -				pixelclk-active = <1>;
> -			};
> -
> -			ET0500 {
> -				clock-frequency = <33264000>;
> -				hactive = <800>;
> -				vactive = <480>;
> -				hback-porch = <88>;
> -				hsync-len = <128>;
> -				hfront-porch = <40>;
> -				vback-porch = <33>;
> -				vsync-len = <2>;
> -				vfront-porch = <10>;
> -				hsync-active = <0>;
> -				vsync-active = <0>;
> -				de-active = <1>;
> -				pixelclk-active = <0>;
> -			};
> -
> -			ET0700 { /* same as ET0500 */
> -				clock-frequency = <33264000>;
> -				hactive = <800>;
> -				vactive = <480>;
> -				hback-porch = <88>;
> -				hsync-len = <128>;
> -				hfront-porch = <40>;
> -				vback-porch = <33>;
> -				vsync-len = <2>;
> -				vfront-porch = <10>;
> -				hsync-active = <0>;
> -				vsync-active = <0>;
> -				de-active = <1>;
> -				pixelclk-active = <0>;
> -			};
> -
> -			ETQ570 {
> -				clock-frequency = <6596040>;
> -				hactive = <320>;
> -				vactive = <240>;
> -				hback-porch = <38>;
> -				hsync-len = <30>;
> -				hfront-porch = <30>;
> -				vback-porch = <16>;
> -				vsync-len = <3>;
> -				vfront-porch = <4>;
> -				hsync-active = <0>;
> -				vsync-active = <0>;
> -				de-active = <1>;
> -				pixelclk-active = <0>;
> -			};
> -		};
> -        };
> -};
> -
> -&ipu1_di0_disp0 {
> -	remote-endpoint = <&display0_in>;
> -};
> diff --git a/arch/arm/boot/dts/imx6q-tx6q-10x0-comtft.dts b/arch/arm/boot/dts/imx6q-tx6q-10x0-comtft.dts
> new file mode 100644
> index 0000000..8997553
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-tx6q-10x0-comtft.dts
> @@ -0,0 +1,119 @@
> +/*
> + * Copyright 2014 Lothar Wa?mann <LW at KARO-electronics.de>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/dts-v1/;
> +#include "imx6q.dtsi"
> +#include "imx6qdl-tx6.dtsi"
> +
> +/ {
> +	model = "Ka-Ro electronics TX6Q-1010/-1030 Module on CoMpact TFT";
> +	compatible = "karo,imx6q-tx6q", "fsl,imx6q";
> +
> +	aliases {
> +		display = &mxcfb0;
> +		mxcfb0 = &mxcfb0;
> +	};
> +
> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm2 0 500000 0>;
> +		power-supply = <&reg_3v3>;
> +		/*
> +		 * a poor man's way to create a 1:1 relationship between
> +		 * the PWM value and the actual duty cycle
> +		 */
> +		brightness-levels = < 0  1  2  3  4  5  6  7  8  9
> +				     10 11 12 13 14 15 16 17 18 19
> +				     20 21 22 23 24 25 26 27 28 29
> +				     30 31 32 33 34 35 36 37 38 39
> +				     40 41 42 43 44 45 46 47 48 49
> +				     50 51 52 53 54 55 56 57 58 59
> +				     60 61 62 63 64 65 66 67 68 69
> +				     70 71 72 73 74 75 76 77 78 79
> +				     80 81 82 83 84 85 86 87 88 89
> +				     90 91 92 93 94 95 96 97 98 99
> +				    100>;
> +		default-brightness-level = <50>;
> +	};
> +
> +	mxcfb0: fb at 2 {
> +		compatible = "fsl,mxc_sdc_fb";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_disp0_2>;
> +		disp_dev = "lcd";
> +		interface_pix_fmt = "RGB24";
> +		mode_str = "";
> +		default_bpp = <32>;
> +		int_clk = <1>;
> +		late_init = <0>;
> +		status = "okay";
> +
> +		display-timings {
> +			native-mode = <&ET070001DM6>;
> +
> +			ET070001DM6: CoMTFT { /* same as ET0700 but with inverted pixel clock */
> +				clock-frequency = <33264000>;
> +				hactive = <800>;
> +				vactive = <480>;
> +				hback-porch = <88>;
> +				hsync-len = <128>;
> +				hfront-porch = <40>;
> +				vback-porch = <33>;
> +				vsync-len = <2>;
> +				vfront-porch = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <1>;
> +			};
> +		};
> +	};
> +
> +	lcd: lcd at 0 {
> +		compatible = "fsl,lcd";
> +		ipu_id = <0>;
> +		disp_id = <0>;
> +		default_ifmt = "RGB24";
> +		status = "okay";
> +	};
> +};
> +
> +&can1 {
> +	status = "disabled";
> +};
> +
> +&can2 {
> +	xceiver-supply = <&reg_3v3>;
> +};
> +
> +&ipu2 {
> +	status = "disabled";
> +};
> +
> +&kpp {
> +	status = "disabled";
> +};
> +
> +&reg_can_xcvr {
> +	status = "disabled";
> +};
> +
> +&reg_lcd0_pwr {
> +	status = "okay";
> +};
> +
> +&reg_lcd1_pwr {
> +	status = "okay";
> +};
> +
> +&touchscreen {
> +	status = "disabled";
> +};
> diff --git a/arch/arm/boot/dts/imx6q-tx6q-10x0.dts b/arch/arm/boot/dts/imx6q-tx6q-10x0.dts
> new file mode 100644
> index 0000000..c3782af
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-tx6q-10x0.dts
> @@ -0,0 +1,191 @@
> +/*
> + * Copyright 2014 Lothar Wa?mann <LW at KARO-electronics.de>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/dts-v1/;
> +#include "imx6q.dtsi"
> +#include "imx6qdl-tx6.dtsi"
> +
> +/ {
> +	model = "Ka-Ro electronics TX6Q-1010/-1030 Module";
> +	compatible = "karo,imx6q-tx6q", "fsl,imx6q";
> +
> +	aliases {
> +		display = &display;
> +		ipu1 = &ipu1;
> +		ipu2 = &ipu2;
> +	};
> +
> +	backlight: backlight {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm2 0 500000 PWM_POLARITY_INVERTED>;
> +		power-supply = <&reg_3v3>;
> +		/*
> +		 * a poor man's way to create a 1:1 relationship between
> +		 * the PWM value and the actual duty cycle
> +		 */
> +		brightness-levels = < 0  1  2  3  4  5  6  7  8  9
> +				     10 11 12 13 14 15 16 17 18 19
> +				     20 21 22 23 24 25 26 27 28 29
> +				     30 31 32 33 34 35 36 37 38 39
> +				     40 41 42 43 44 45 46 47 48 49
> +				     50 51 52 53 54 55 56 57 58 59
> +				     60 61 62 63 64 65 66 67 68 69
> +				     70 71 72 73 74 75 76 77 78 79
> +				     80 81 82 83 84 85 86 87 88 89
> +				     90 91 92 93 94 95 96 97 98 99
> +				    100>;
> +		default-brightness-level = <50>;
> +	};
> +
> +	display: display at di0 {
> +		compatible = "fsl,imx-parallel-display";
> +		interface-pix-fmt = "rgb24";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_disp0_1>;
> +		status = "okay";
> +
> +		port {
> +			display0_in: endpoint {
> +				remote-endpoint = <&ipu1_di0_disp0>;
> +			};
> +		};
> +
> +		display-timings {
> +			VGA {
> +				clock-frequency = <25200000>;
> +				hactive = <640>;
> +				vactive = <480>;
> +				hback-porch = <48>;
> +				hsync-len = <96>;
> +				hfront-porch = <16>;
> +				vback-porch = <31>;
> +				vsync-len = <2>;
> +				vfront-porch = <12>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			ETV570 {
> +				clock-frequency = <25200000>;
> +				hactive = <640>;
> +				vactive = <480>;
> +				hback-porch = <114>;
> +				hsync-len = <30>;
> +				hfront-porch = <16>;
> +				vback-porch = <32>;
> +				vsync-len = <3>;
> +				vfront-porch = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			ET0350 {
> +				clock-frequency = <6413760>;
> +				hactive = <320>;
> +				vactive = <240>;
> +				hback-porch = <34>;
> +				hsync-len = <34>;
> +				hfront-porch = <20>;
> +				vback-porch = <15>;
> +				vsync-len = <3>;
> +				vfront-porch = <4>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			ET0430 {
> +				clock-frequency = <9009000>;
> +				hactive = <480>;
> +				vactive = <272>;
> +				hback-porch = <2>;
> +				hsync-len = <41>;
> +				hfront-porch = <2>;
> +				vback-porch = <2>;
> +				vsync-len = <10>;
> +				vfront-porch = <2>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <1>;
> +			};
> +
> +			ET0500 {
> +				clock-frequency = <33264000>;
> +				hactive = <800>;
> +				vactive = <480>;
> +				hback-porch = <88>;
> +				hsync-len = <128>;
> +				hfront-porch = <40>;
> +				vback-porch = <33>;
> +				vsync-len = <2>;
> +				vfront-porch = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			ET0700 { /* same as ET0500 */
> +				clock-frequency = <33264000>;
> +				hactive = <800>;
> +				vactive = <480>;
> +				hback-porch = <88>;
> +				hsync-len = <128>;
> +				hfront-porch = <40>;
> +				vback-porch = <33>;
> +				vsync-len = <2>;
> +				vfront-porch = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			ETQ570 {
> +				clock-frequency = <6596040>;
> +				hactive = <320>;
> +				vactive = <240>;
> +				hback-porch = <38>;
> +				hsync-len = <30>;
> +				hfront-porch = <30>;
> +				vback-porch = <16>;
> +				vsync-len = <3>;
> +				vfront-porch = <4>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +		};
> +	};
> +};
> +
> +&ipu1_di0_disp0 {
> +	remote-endpoint = <&display0_in>;
> +};
> +
> +&ipu2 {
> +	status = "disabled";
> +};
> +
> +&reg_lcd0_pwr {
> +	status = "okay";
> +};
> +
> +&reg_lcd1_pwr {
> +	status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/imx6q-tx6q-1110.dts b/arch/arm/boot/dts/imx6q-tx6q-1110.dts
> deleted file mode 100644
> index 88aa1e4..0000000
> --- a/arch/arm/boot/dts/imx6q-tx6q-1110.dts
> +++ /dev/null
> @@ -1,154 +0,0 @@
> -/*
> - * Copyright 2014 Lothar Wa?mann <LW at KARO-electronics.de>
> - *
> - * The code contained herein is licensed under the GNU General Public
> - * License. You may obtain a copy of the GNU General Public License
> - * Version 2 at the following locations:
> - *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> - */
> -
> -/dts-v1/;
> -#include "imx6q.dtsi"
> -#include "imx6qdl-tx6.dtsi"
> -
> -/ {
> -	model = "Ka-Ro electronics TX6Q-1110 Module";
> -	compatible = "karo,imx6q-tx6q", "fsl,imx6q";
> -
> -	aliases {
> -		display = &lvds0;
> -		lvds0 = &lvds0;
> -		lvds1 = &lvds1;
> -	};
> -
> -	backlight0: backlight0 {
> -		compatible = "pwm-backlight";
> -		pwms = <&pwm2 0 500000 0>;
> -		power-supply = <&reg_lcd0_pwr>;
> -		/*
> -		 * a poor man's way to create a 1:1 relationship between
> -		 * the PWM value and the actual duty cycle
> -		 */
> -		brightness-levels = < 0  1  2  3  4  5  6  7  8  9
> -				     10 11 12 13 14 15 16 17 18 19
> -				     20 21 22 23 24 25 26 27 28 29
> -				     30 31 32 33 34 35 36 37 38 39
> -				     40 41 42 43 44 45 46 47 48 49
> -				     50 51 52 53 54 55 56 57 58 59
> -				     60 61 62 63 64 65 66 67 68 69
> -				     70 71 72 73 74 75 76 77 78 79
> -				     80 81 82 83 84 85 86 87 88 89
> -				     90 91 92 93 94 95 96 97 98 99
> -				    100>;
> -		default-brightness-level = <50>;
> -	};
> -
> -	backlight1: backlight1 {
> -		compatible = "pwm-backlight";
> -		pwms = <&pwm1 0 500000 0>;
> -		power-supply = <&reg_lcd1_pwr>;
> -		/*
> -		 * a poor man's way to create a 1:1 relationship between
> -		 * the PWM value and the actual duty cycle
> -		 */
> -		brightness-levels = < 0  1  2  3  4  5  6  7  8  9
> -				     10 11 12 13 14 15 16 17 18 19
> -				     20 21 22 23 24 25 26 27 28 29
> -				     30 31 32 33 34 35 36 37 38 39
> -				     40 41 42 43 44 45 46 47 48 49
> -				     50 51 52 53 54 55 56 57 58 59
> -				     60 61 62 63 64 65 66 67 68 69
> -				     70 71 72 73 74 75 76 77 78 79
> -				     80 81 82 83 84 85 86 87 88 89
> -				     90 91 92 93 94 95 96 97 98 99
> -				    100>;
> -		default-brightness-level = <50>;
> -	};
> -};
> -
> -&i2c3 {
> -	polytouch1: eeti at 04 {
> -		compatible = "eeti,egalax_ts";
> -		reg = <0x04>;
> -		pinctrl-names = "default";
> -		pinctrl-0 = <&pinctrl_eeti>;
> -		interrupt-parent = <&gpio3>;
> -		interrupts = <22 0>;
> -		wakeup-gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
> -		linux,wakeup;
> -	};
> -};
> -
> -&iomuxc {
> -	imx6q-tx6q-1110 {
> -		pinctrl_eeti: eetigrp {
> -			fsl,pins = <
> -				MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b1 /* Interrupt */
> -			>;
> -		};
> -	};
> -};
> -
> -&kpp {
> -	status = "disabled"; /* pad conflict with backlight1 PWM */
> -};
> -
> -&ldb {
> -	status = "okay";
> -
> -	lvds0: lvds-channel at 0 {
> -		fsl,data-mapping = "spwg";
> -		fsl,data-width = <18>;
> -		status = "okay";
> -
> -		display-timings {
> -			native-mode = <&lvds_timing0>;
> -			lvds_timing0: hsd100pxn1 {
> -				clock-frequency = <65000000>;
> -				hactive = <1024>;
> -				vactive = <768>;
> -				hback-porch = <220>;
> -				hfront-porch = <40>;
> -				vback-porch = <21>;
> -				vfront-porch = <7>;
> -				hsync-len = <60>;
> -				vsync-len = <10>;
> -				de-active = <1>;
> -				pixelclk-active = <1>;
> -			};
> -		};
> -	};
> -
> -	lvds1: lvds-channel at 1 {
> -		fsl,data-mapping = "spwg";
> -		fsl,data-width = <18>;
> -		status = "disabled";
> -
> -		display-timings {
> -			native-mode = <&lvds_timing1>;
> -			lvds_timing1: hsd100pxn1 {
> -				clock-frequency = <65000000>;
> -				hactive = <1024>;
> -				vactive = <768>;
> -				hback-porch = <220>;
> -				hfront-porch = <40>;
> -				vback-porch = <21>;
> -				vfront-porch = <7>;
> -				hsync-len = <60>;
> -				vsync-len = <10>;
> -				de-active = <1>;
> -				pixelclk-active = <1>;
> -			};
> -		};
> -	};
> -};
> -
> -&pwm1 {
> -	status = "okay";
> -};
> -
> -&sata {
> -	status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/imx6q-tx6q-11x0.dts b/arch/arm/boot/dts/imx6q-tx6q-11x0.dts
> new file mode 100644
> index 0000000..c66524b
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-tx6q-11x0.dts
> @@ -0,0 +1,249 @@
> +/*
> + * Copyright 2014 Lothar Wa?mann <LW at KARO-electronics.de>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/dts-v1/;
> +#include "imx6q.dtsi"
> +#include "imx6qdl-tx6.dtsi"
> +
> +/ {
> +	model = "Ka-Ro electronics TX6Q-1110/-1130 Module";
> +	compatible = "karo,imx6q-tx6q", "fsl,imx6q";
> +
> +	aliases {
> +		display = &lvds0;
> +		ipu1 = &ipu2;
> +		lvds0 = &lvds0;
> +		lvds1 = &lvds1;
> +		mxcfb0 = &lvds0;
> +		mxcfb1 = &lvds1;
> +	};
> +
> +	backlight0: backlight0 {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm2 0 500000 0>;
> +		/*
> +		 * a poor man's way to create a 1:1 relationship between
> +		 * the PWM value and the actual duty cycle
> +		 */
> +		brightness-levels = < 0  1  2  3  4  5  6  7  8  9
> +				     10 11 12 13 14 15 16 17 18 19
> +				     20 21 22 23 24 25 26 27 28 29
> +				     30 31 32 33 34 35 36 37 38 39
> +				     40 41 42 43 44 45 46 47 48 49
> +				     50 51 52 53 54 55 56 57 58 59
> +				     60 61 62 63 64 65 66 67 68 69
> +				     70 71 72 73 74 75 76 77 78 79
> +				     80 81 82 83 84 85 86 87 88 89
> +				     90 91 92 93 94 95 96 97 98 99
> +				    100>;
> +		default-brightness-level = <50>;
> +	};
> +
> +	backlight1: backlight1 {
> +		compatible = "pwm-backlight";
> +		pwms = <&pwm1 0 500000 0>;
> +		/*
> +		 * a poor man's way to create a 1:1 relationship between
> +		 * the PWM value and the actual duty cycle
> +		 */
> +		brightness-levels = < 0  1  2  3  4  5  6  7  8  9
> +				     10 11 12 13 14 15 16 17 18 19
> +				     20 21 22 23 24 25 26 27 28 29
> +				     30 31 32 33 34 35 36 37 38 39
> +				     40 41 42 43 44 45 46 47 48 49
> +				     50 51 52 53 54 55 56 57 58 59
> +				     60 61 62 63 64 65 66 67 68 69
> +				     70 71 72 73 74 75 76 77 78 79
> +				     80 81 82 83 84 85 86 87 88 89
> +				     90 91 92 93 94 95 96 97 98 99
> +				    100>;
> +		default-brightness-level = <50>;
> +	};
> +
> +	lvds0: fb at 0 {
> +		compatible = "fsl,mxc_sdc_fb";
> +		disp_dev = "ldb";
> +		interface_pix_fmt = "RGB666";
> +		mode_str = "LDB-XGA";
> +		default_bpp = <32>;
> +		int_clk = <0>;
> +		late_init = <0>;
> +		fsl,data-mapping = "spwg";
> +		fsl,data-width = <18>;
> +		status = "okay";
> +
> +		display-timings {
> +			native-mode = <&lvds0_timing0>;
> +
> +			lvds0_timing0: hsd100pxn1 {
> +				clock-frequency = <65000000>;
> +				hactive = <1024>;
> +				vactive = <768>;
> +				hback-porch = <220>;
> +				hfront-porch = <40>;
> +				vback-porch = <21>;
> +				vfront-porch = <7>;
> +				hsync-len = <60>;
> +				vsync-len = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <1>;
> +			};
> +
> +			lvds0_timing1: VGA {
> +				clock-frequency = <25200000>;
> +				hactive = <640>;
> +				vactive = <480>;
> +				hback-porch = <48>;
> +				hfront-porch = <16>;
> +				vback-porch = <31>;
> +				vfront-porch = <12>;
> +				hsync-len = <96>;
> +				vsync-len = <2>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			lvds0_timing2: nl12880bc20 {
> +				clock-frequency = <71000000>;
> +				hactive = <1280>;
> +				vactive = <800>;
> +				hback-porch = <50>;
> +				hfront-porch = <50>;
> +				vback-porch = <5>;
> +				vfront-porch = <5>;
> +				hsync-len = <60>;
> +				vsync-len = <13>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +		};
> +	};
> +
> +	lvds1: fb at 1 {
> +		compatible = "fsl,mxc_sdc_fb";
> +		disp_dev = "ldb";
> +		interface_pix_fmt = "RGB666";
> +		mode_str = "LDB-XGA";
> +		default_bpp = <32>;
> +		int_clk = <0>;
> +		late_init = <0>;
> +		fsl,data-mapping = "spwg";
> +		fsl,data-width = <18>;
> +		status = "okay";
> +
> +		display-timings {
> +			native-mode = <&lvds1_timing0>;
> +
> +			lvds1_timing0: hsd100pxn1 {
> +				clock-frequency = <65000000>;
> +				hactive = <1024>;
> +				vactive = <768>;
> +				hback-porch = <220>;
> +				hfront-porch = <40>;
> +				vback-porch = <21>;
> +				vfront-porch = <7>;
> +				hsync-len = <60>;
> +				vsync-len = <10>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			lvds1_timing1: VGA {
> +				clock-frequency = <25200000>;
> +				hactive = <640>;
> +				vactive = <480>;
> +				hback-porch = <48>;
> +				hfront-porch = <16>;
> +				vback-porch = <31>;
> +				vfront-porch = <12>;
> +				hsync-len = <96>;
> +				vsync-len = <2>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +
> +			lvds1_timing2: nl12880bc20 {
> +				clock-frequency = <71000000>;
> +				hactive = <1280>;
> +				vactive = <800>;
> +				hback-porch = <50>;
> +				hfront-porch = <50>;
> +				vback-porch = <5>;
> +				vfront-porch = <5>;
> +				hsync-len = <60>;
> +				vsync-len = <13>;
> +				hsync-active = <0>;
> +				vsync-active = <0>;
> +				de-active = <1>;
> +				pixelclk-active = <0>;
> +			};
> +		};
> +	};
> +};
> +
> +&i2c3 {
> +	polytouch1: eeti at 04 {
> +		compatible = "eeti,egalax_ts";
> +		reg = <0x04>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_eeti>;
> +		interrupt-parent = <&gpio3>;
> +		interrupts = <22 0>;
> +		wakeup-gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
> +		linux,wakeup;
> +	};
> +};
> +
> +&iomuxc {
> +	imx6q-tx6q-11x0 {
> +		pinctrl_eeti: eetigrp {
> +			fsl,pins = <
> +				MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b1 /* Interrupt */
> +			>;
> +		};
> +	};
> +};
> +
> +&ipu2 {
> +	status = "disabled";
> +};
> +
> +&kpp {
> +	status = "disabled"; /* pads partially clash with backlight1 PWM */
> +};
> +
> +&ldb {
> +	ipu_id = <0>;
> +	disp_id = <0>;
> +	ext_ref = <0>;
> +	mode = "sep0";
> +	sec_ipu_id = <0>;
> +	sec_disp_id = <1>;
> +	status = "okay";
> +};
> +
> +&pwm1 {
> +	status = "okay";
> +};
> +
> +&sata {
> +	status = "okay";
> +};
> -- 
> 2.1.4
> 
> 


From wens at csie.org  Mon Feb  1 22:44:26 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue, 2 Feb 2016 14:44:26 +0800
Subject: [PATCH 10/14] ARM: dts: sun8i-a83t: Add PRCM related clocks and
 resets
In-Reply-To: <1454203266-4450-11-git-send-email-vishnupatekar0510@gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-11-git-send-email-vishnupatekar0510@gmail.com>
Message-ID: <CAGb2v67iO-816KaLttWRRPL2f7hpfgJ1--p69tD_oOrewmOjCA@mail.gmail.com>

On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
<vishnupatekar0510 at gmail.com> wrote:
> This adds A83T PRCM related clocks, clock resets.
>
> As a83t apb0 gates clock support is added earlier, this enables it.
> Apart from apb0 gates, other added clocks are compatible with
> earlier sun8i socs.
>
> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
> ---
>  arch/arm/boot/dts/sun8i-a83t.dtsi | 44 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index ac96aa1..5ea20ff 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -268,6 +268,44 @@
>                                              "mmc2_output",
>                                              "mmc2_sample";
>                 };
> +
> +               cpus_clk: clk at 01f01400 {
> +                       compatible = "allwinner,sun9i-a80-cpus-clk";
> +                       reg = <0x01f01400 0x4>;
> +                       #clock-cells = <0>;
> +                       clocks = <&osc16Md512>, <&osc24M>, <&pll6>, <&osc16M>;
> +                       clock-output-names = "cpus";
> +               };
> +
> +               ahb0: ahb0_clk {
> +                       compatible = "fixed-factor-clock";
> +                       #clock-cells = <0>;
> +                       clock-div = <1>;
> +                       clock-mult = <1>;
> +                       clocks = <&cpus_clk>;
> +                       clock-output-names = "ahb0";
> +               };
> +
> +               apb0: clk at 01f0140c {
> +                       compatible = "allwinner,sun8i-a23-apb0-clk";

This is actually wrong, as it is wrong in sun9i-a80.dtsi.
I've sent a patch series for it.

Also the drivers for "allwinner,sun9i-a80-cpus-clk" and
"allwinner,sun9i-a80-apbs-clk"
are only compiled for CONFIG_MACH_SUN9I. Please add a patch to address this.

Regards
ChenYu

> +                       reg = <0x01f0140c 0x4>;
> +                       #clock-cells = <0>;
> +                       clocks = <&ahb0>;
> +                       clock-output-names = "apb0";
> +               };
> +
> +               apb0_gates: clk at 01f01428 {
> +                       compatible = "allwinner,sun8i-a83t-apb0-gates-clk";
> +                       reg = <0x01f01428 0x4>;
> +                       #clock-cells = <1>;
> +                       clocks = <&apb0>;
> +                       clock-indices = <0>, <1>,
> +                                       <2>, <3>,
> +                                       <4>, <6>, <7>;
> +                       clock-output-names = "apb0_pio", "apb0_ir",
> +                                       "apb0_timer", "apb0_rsb",
> +                                       "apb0_uart", "apb0_i2c0", "apb0_twd";
> +               };
>         };
>
>         soc {
> @@ -434,5 +472,11 @@
>                         #interrupt-cells = <3>;
>                         interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
>                 };
> +
> +               apb0_reset: reset at 01f014b0 {
> +                       reg = <0x01f014b0 0x4>;
> +                       compatible = "allwinner,sun6i-a31-clock-reset";
> +                       #reset-cells = <1>;
> +               };
>         };
>  };
> --
> 1.9.1
>


From takahiro.akashi at linaro.org  Mon Feb  1 22:46:13 2016
From: takahiro.akashi at linaro.org (AKASHI Takahiro)
Date: Tue, 2 Feb 2016 15:46:13 +0900
Subject: [PATCH v4 05/13] arm64: kvm: allows kvm cpu hotplug
In-Reply-To: <1453977766-20907-6-git-send-email-james.morse@arm.com>
References: <1453977766-20907-1-git-send-email-james.morse@arm.com>
 <1453977766-20907-6-git-send-email-james.morse@arm.com>
Message-ID: <56B050B5.2070202@linaro.org>

On 01/28/2016 07:42 PM, James Morse wrote:
> From: AKASHI Takahiro <takahiro.akashi at linaro.org>
>
> The current kvm implementation on arm64 does cpu-specific initialization
> at system boot, and has no way to gracefully shutdown a core in terms of
> kvm. This prevents kexec from rebooting the system at EL2.
>
> This patch adds a cpu tear-down function and also puts an existing cpu-init
> code into a separate function, kvm_arch_hardware_disable() and
> kvm_arch_hardware_enable() respectively.
> We don't need the arm64 specific cpu hotplug hook any more.
>
> Since this patch modifies common code between arm and arm64, one stub
> definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
> compilation errors.
>
> Signed-off-by: AKASHI Takahiro <takahiro.akashi at linaro.org>
> [Moved __kvm_hyp_reset() to use kvm_call_hyp(), instead of having its own
>   dedicated entry point in el1_sync. Added some comments and a tlbi.]
> Signed-off-by: James Morse <james.morse at arm.com>
> ---
> This patch is from v13 of kexec, see my [changes] above.
>
>   arch/arm/include/asm/kvm_host.h   | 10 +++-
>   arch/arm/include/asm/kvm_mmu.h    |  1 +
>   arch/arm/kvm/arm.c                | 98 ++++++++++++++++++++++++---------------
>   arch/arm/kvm/mmu.c                |  5 ++
>   arch/arm64/include/asm/kvm_host.h |  1 -
>   arch/arm64/include/asm/kvm_mmu.h  | 19 ++++++++
>   arch/arm64/kvm/hyp-init.S         | 42 +++++++++++++++++
>   7 files changed, 136 insertions(+), 40 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index f9f27792d8ed..8af531d64771 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -220,6 +220,15 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
>   	kvm_call_hyp((void*)hyp_stack_ptr, vector_ptr, pgd_ptr);
>   }
>
> +static inline void __cpu_reset_hyp_mode(phys_addr_t boot_pgd_ptr,
> +					phys_addr_t phys_idmap_start)
> +{
> +	/*
> +	 * TODO
> +	 * kvm_call_reset(boot_pgd_ptr, phys_idmap_start);
> +	 */
> +}
> +
>   static inline int kvm_arch_dev_ioctl_check_extension(long ext)
>   {
>   	return 0;
> @@ -232,7 +241,6 @@ void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);
>
>   struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
>
> -static inline void kvm_arch_hardware_disable(void) {}
>   static inline void kvm_arch_hardware_unsetup(void) {}
>   static inline void kvm_arch_sync_events(struct kvm *kvm) {}
>   static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index a520b7987a29..4fd9ddb48c0f 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -66,6 +66,7 @@ void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
>   phys_addr_t kvm_mmu_get_httbr(void);
>   phys_addr_t kvm_mmu_get_boot_httbr(void);
>   phys_addr_t kvm_get_idmap_vector(void);
> +phys_addr_t kvm_get_idmap_start(void);
>   int kvm_mmu_init(void);
>   void kvm_clear_hyp_idmap(void);
>
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index dda1959f0dde..f060567e9c0a 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -16,7 +16,6 @@
>    * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
>    */
>
> -#include <linux/cpu.h>
>   #include <linux/cpu_pm.h>
>   #include <linux/errno.h>
>   #include <linux/err.h>
> @@ -65,6 +64,8 @@ static DEFINE_SPINLOCK(kvm_vmid_lock);
>
>   static bool vgic_present;
>
> +static DEFINE_PER_CPU(unsigned char, kvm_arm_hardware_enabled);
> +
>   static void kvm_arm_set_running_vcpu(struct kvm_vcpu *vcpu)
>   {
>   	BUG_ON(preemptible());
> @@ -89,11 +90,6 @@ struct kvm_vcpu * __percpu *kvm_get_running_vcpus(void)
>   	return &kvm_arm_running_vcpu;
>   }
>
> -int kvm_arch_hardware_enable(void)
> -{
> -	return 0;
> -}
> -
>   int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
>   {
>   	return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
> @@ -585,7 +581,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>   		/*
>   		 * Re-check atomic conditions
>   		 */
> -		if (signal_pending(current)) {
> +		if (unlikely(!__this_cpu_read(kvm_arm_hardware_enabled))) {
> +			/* cpu has been torn down */
> +			ret = 0;
> +			run->exit_reason = KVM_EXIT_FAIL_ENTRY;
> +			run->fail_entry.hardware_entry_failure_reason
> +					= (u64)-ENOEXEC;
> +		} else if (signal_pending(current)) {
>   			ret = -EINTR;
>   			run->exit_reason = KVM_EXIT_INTR;
>   		}
> @@ -967,7 +969,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
>   	}
>   }
>
> -static void cpu_init_hyp_mode(void *dummy)
> +static void cpu_init_hyp_mode(void)
>   {
>   	phys_addr_t boot_pgd_ptr;
>   	phys_addr_t pgd_ptr;
> @@ -989,36 +991,61 @@ static void cpu_init_hyp_mode(void *dummy)
>   	kvm_arm_init_debug();
>   }
>
> -static int hyp_init_cpu_notify(struct notifier_block *self,
> -			       unsigned long action, void *cpu)
> +static void cpu_reset_hyp_mode(void)
>   {
> -	switch (action) {
> -	case CPU_STARTING:
> -	case CPU_STARTING_FROZEN:
> -		if (__hyp_get_vectors() == hyp_default_vectors)
> -			cpu_init_hyp_mode(NULL);
> -		break;
> +	phys_addr_t boot_pgd_ptr;
> +	phys_addr_t phys_idmap_start;
> +
> +	boot_pgd_ptr = kvm_mmu_get_boot_httbr();
> +	phys_idmap_start = kvm_get_idmap_start();
> +
> +	__cpu_reset_hyp_mode(boot_pgd_ptr, phys_idmap_start);
> +}
> +
> +int kvm_arch_hardware_enable(void)
> +{
> +	if (!__this_cpu_read(kvm_arm_hardware_enabled)) {
> +		cpu_init_hyp_mode();
> +		__this_cpu_write(kvm_arm_hardware_enabled, 1);
>   	}
>
> -	return NOTIFY_OK;
> +	return 0;
>   }
>
> -static struct notifier_block hyp_init_cpu_nb = {
> -	.notifier_call = hyp_init_cpu_notify,
> -};
> +void kvm_arch_hardware_disable(void)
> +{
> +	if (!__this_cpu_read(kvm_arm_hardware_enabled))
> +		return;
> +
> +	cpu_reset_hyp_mode();
> +	__this_cpu_write(kvm_arm_hardware_enabled, 0);
> +}
>
>   #ifdef CONFIG_CPU_PM
>   static int hyp_init_cpu_pm_notifier(struct notifier_block *self,
>   				    unsigned long cmd,
>   				    void *v)
>   {
> -	if (cmd == CPU_PM_EXIT &&
> -	    __hyp_get_vectors() == hyp_default_vectors) {
> -		cpu_init_hyp_mode(NULL);
> +	/*
> +	 * kvm_arm_hardware_enabled is left with its old value over
> +	 * PM_ENTER->PM_EXIT. It is used to indicate PM_EXIT should
> +	 * re-enable hyp.
> +	 */
> +	switch (cmd) {
> +	case CPU_PM_ENTER:
> +		if (__this_cpu_read(kvm_arm_hardware_enabled))
> +			cpu_reset_hyp_mode();
> +
> +		return NOTIFY_OK;
> +	case CPU_PM_EXIT:
> +		if (__this_cpu_read(kvm_arm_hardware_enabled))
> +			cpu_init_hyp_mode();
> +
>   		return NOTIFY_OK;
> -	}
>
> -	return NOTIFY_DONE;
> +	default:
> +		return NOTIFY_DONE;
> +	}
>   }
>
>   static struct notifier_block hyp_init_cpu_pm_nb = {
> @@ -1122,14 +1149,20 @@ static int init_hyp_mode(void)
>   	}
>
>   	/*
> -	 * Execute the init code on each CPU.
> +	 * Init this CPU temporarily to execute kvm_hyp_call()
> +	 * during kvm_vgic_hyp_init().
>   	 */
> -	on_each_cpu(cpu_init_hyp_mode, NULL, 1);
> +	preempt_disable();
> +	cpu_init_hyp_mode();
>
>   	/*
>   	 * Init HYP view of VGIC
>   	 */
>   	err = kvm_vgic_hyp_init();
> +
> +	cpu_reset_hyp_mode();
> +	preempt_enable();
> +
>   	switch (err) {
>   	case 0:
>   		vgic_present = true;
> @@ -1213,26 +1246,15 @@ int kvm_arch_init(void *opaque)
>   		}
>   	}
>
> -	cpu_notifier_register_begin();
> -
>   	err = init_hyp_mode();
>   	if (err)
>   		goto out_err;
>
> -	err = __register_cpu_notifier(&hyp_init_cpu_nb);
> -	if (err) {
> -		kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
> -		goto out_err;
> -	}
> -
> -	cpu_notifier_register_done();
> -
>   	hyp_cpu_pm_init();
>
>   	kvm_coproc_table_init();
>   	return 0;
>   out_err:
> -	cpu_notifier_register_done();
>   	return err;
>   }
>
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index aba61fd3697a..7a3aed62499a 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -1643,6 +1643,11 @@ phys_addr_t kvm_get_idmap_vector(void)
>   	return hyp_idmap_vector;
>   }
>
> +phys_addr_t kvm_get_idmap_start(void)
> +{
> +	return hyp_idmap_start;
> +}
> +
>   int kvm_mmu_init(void)
>   {
>   	int err;
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 689d4c95e12f..7d6d75616fb5 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -332,7 +332,6 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
>   		     hyp_stack_ptr, vector_ptr);
>   }
>
> -static inline void kvm_arch_hardware_disable(void) {}
>   static inline void kvm_arch_hardware_unsetup(void) {}
>   static inline void kvm_arch_sync_events(struct kvm *kvm) {}
>   static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 736433912a1e..1d48208a904a 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -99,6 +99,7 @@ void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
>   phys_addr_t kvm_mmu_get_httbr(void);
>   phys_addr_t kvm_mmu_get_boot_httbr(void);
>   phys_addr_t kvm_get_idmap_vector(void);
> +phys_addr_t kvm_get_idmap_start(void);
>   int kvm_mmu_init(void);
>   void kvm_clear_hyp_idmap(void);
>
> @@ -310,5 +311,23 @@ static inline unsigned int kvm_get_vmid_bits(void)
>   	return (cpuid_feature_extract_field(reg, ID_AA64MMFR1_VMIDBITS_SHIFT) == 2) ? 16 : 8;
>   }
>
> +void __kvm_hyp_reset(phys_addr_t boot_pgd_ptr, phys_addr_t phys_idmap_start);
> +
> +/*
> + * Call reset code, and switch back to stub hyp vectors. We need to execute
> + * __kvm_hyp_reset() from the trampoline page, we calculate its address here.
> + */
> +static inline void __cpu_reset_hyp_mode(phys_addr_t boot_pgd_ptr,
> +					phys_addr_t phys_idmap_start)
> +{
> +	unsigned long trampoline_hyp_reset;
> +
> +	trampoline_hyp_reset = TRAMPOLINE_VA +
> +			       ((unsigned long)__kvm_hyp_reset & ~PAGE_MASK);
> +
> +	kvm_call_hyp((void *)trampoline_hyp_reset,
> +		     boot_pgd_ptr, phys_idmap_start);
> +}
> +

I want to place this definition in kvm_host.h as its counterpart, __cpu_init_hyp_mode().

-Takahiro AKASHI

>   #endif /* __ASSEMBLY__ */
>   #endif /* __ARM64_KVM_MMU_H__ */
> diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
> index dc6335a7353e..d20d86c7f9d8 100644
> --- a/arch/arm64/kvm/hyp-init.S
> +++ b/arch/arm64/kvm/hyp-init.S
> @@ -150,6 +150,48 @@ merged:
>   	eret
>   ENDPROC(__kvm_hyp_init)
>
> +	/*
> +	 * x0: HYP boot pgd
> +	 * x1: HYP phys_idmap_start
> +	 */
> +ENTRY(__kvm_hyp_reset)
> +	/*
> +	 * Retrieve lr from the stack (pushed by el1_sync()), so we can eret
> +	 * from here.
> +	 */
> +	ldp	lr, xzr, [sp], #16
> +
> +	/* We're in trampoline code in VA, switch back to boot page tables */
> +	msr	ttbr0_el2, x0
> +	isb
> +
> +	/* Ensure the PA branch doesn't find a stale tlb entry. */
> +	tlbi	alle2
> +	dsb	sy
> +
> +	/* Branch into PA space */
> +	adr	x0, 1f
> +	bfi	x1, x0, #0, #PAGE_SHIFT
> +	br	x1
> +
> +	/* We're now in idmap, disable MMU */
> +1:	mrs	x0, sctlr_el2
> +	ldr	x1, =SCTLR_ELx_FLAGS
> +	bic	x0, x0, x1		// Clear SCTL_M and etc
> +	msr	sctlr_el2, x0
> +	isb
> +
> +	/* Invalidate the old TLBs */
> +	tlbi	alle2
> +	dsb	sy
> +
> +	/* Install stub vectors */
> +	adr_l	x0, __hyp_stub_vectors
> +	msr	vbar_el2, x0
> +
> +	eret
> +ENDPROC(__kvm_hyp_reset)
> +
>   	.ltorg
>
>   	.popsection
>


From hs.liao at mediatek.com  Mon Feb  1 22:48:01 2016
From: hs.liao at mediatek.com (Horng-Shyang Liao)
Date: Tue, 2 Feb 2016 14:48:01 +0800
Subject: [RFC 3/3] CMDQ: Mediatek CMDQ driver
In-Reply-To: <CAGS+omB7d3Kq1DKNHxZJjLDmin0rpkDj1kEde3zCxTiT5-xZWw@mail.gmail.com>
References: <1453266881-16849-1-git-send-email-hs.liao@mediatek.com>
 <1453266881-16849-4-git-send-email-hs.liao@mediatek.com>
 <CAGS+omBjD1pXKY_6bFbiGxa5bttvqg5zEvKevzSfoiMOy7ys6Q@mail.gmail.com>
 <1454053150.32413.52.camel@mtksdaap41>
 <CAGS+omBrEE21Xxh8hjcf32qfHJE0jJYvxGP6L1ihS6jcNbLvLQ@mail.gmail.com>
 <1454070262.7401.21.camel@mtksdaap41>
 <CAGS+omBhs7Ks7MVDsxHBBUdgF+0fmAa465HwvNiCzEe97Knt3Q@mail.gmail.com>
 <1454292257.22270.3.camel@mtksdaap41>
 <CAGS+omCzDisk2TfbDnWiXufWgUsCbhF_JFafaUazhSymX-MT_Q@mail.gmail.com>
 <1454307624.22441.18.camel@mtksdaap41>
 <CAGS+omB7d3Kq1DKNHxZJjLDmin0rpkDj1kEde3zCxTiT5-xZWw@mail.gmail.com>
Message-ID: <1454395681.27603.13.camel@mtksdaap41>

On Mon, 2016-02-01 at 18:22 +0800, Daniel Kurtz wrote:
> On Mon, Feb 1, 2016 at 2:20 PM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
> > On Mon, 2016-02-01 at 12:15 +0800, Daniel Kurtz wrote:
> >> On Mon, Feb 1, 2016 at 10:04 AM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
> >> >
> >> > On Fri, 2016-01-29 at 21:15 +0800, Daniel Kurtz wrote:
> >> > > On Fri, Jan 29, 2016 at 8:24 PM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
> >> > > > On Fri, 2016-01-29 at 16:42 +0800, Daniel Kurtz wrote:
> >> > > >> On Fri, Jan 29, 2016 at 3:39 PM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
> >> > > >> > Hi Dan,
> >> > > >> >
> >> > > >> > Many thanks for your comments and time.
> >> > > >> > I reply my plan inline.
> >> > > >> >
> >> > > >> >
> >> > > >> > On Thu, 2016-01-28 at 12:49 +0800, Daniel Kurtz wrote:
> >> > > >> >> Hi HS,
> >> > > >> >>
> >> > > >> >> Sorry for the delay.  It is hard to find time to review a >3700 line
> >> > > >> >> driver :-o in detail....
> >> > > >> >>
> >> > > >> >> Some review comments inline, although I still do not completely
> >> > > >> >> understand how all that this driver does and how it works.
> >> > > >> >> I'll try to find time to go through this driver in detail again next
> >> > > >> >> time you post it for review.
> >> > > >> >>
> >> > > >> >> On Tue, Jan 19, 2016 at 9:14 PM,  <hs.liao at mediatek.com> wrote:
> >> > > >> >> > From: HS Liao <hs.liao at mediatek.com>
> >> > > >> >> >
> >> > > >> >> > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> >> > > >> >> > CMDQ is used to help read/write registers with critical time limitation,
> >> > > >> >> > such as updating display configuration during the vblank. It controls
> >> > > >> >> > Global Command Engine (GCE) hardware to achieve this requirement.
> >> > > >> >> > Currently, CMDQ only supports display related hardwares, but we expect
> >> > > >> >> > it can be extended to other hardwares for future requirements.
> >> > > >> >> >
> >> > > >> >> > Signed-off-by: HS Liao <hs.liao at mediatek.com>
> >> > > >> >>
> >> > > >> >> [snip]
> >> > > >> >>
> >> > > >> >> > diff --git a/drivers/soc/mediatek/mtk-cmdq.c b/drivers/soc/mediatek/mtk-cmdq.c
> >> > > >> >> > new file mode 100644
> >> > > >> >> > index 0000000..7570f00
> >> > > >> >> > --- /dev/null
> >> > > >> >> > +++ b/drivers/soc/mediatek/mtk-cmdq.c
> >> > > >
> >> > > > [snip]
> >> > > >
> >> > > >> >> > +static const struct cmdq_subsys g_subsys[] = {
> >> > > >> >> > +       {0x1400, 1, "MMSYS"},
> >> > > >> >> > +       {0x1401, 2, "DISP"},
> >> > > >> >> > +       {0x1402, 3, "DISP"},
> >> > > >> >>
> >> > > >> >> This isn't going to scale.  These addresses could be different on
> >> > > >> >> different chips.
> >> > > >> >> Instead of a static table like this, we probably need specify to the
> >> > > >> >> connection between gce and other devices via devicetree phandles, and
> >> > > >> >> then use the phandles to lookup the corresponding device address
> >> > > >> >> range.
> >> > > >> >
> >> > > >> > I will define them in device tree.
> >> > > >> > E.g.
> >> > > >> > cmdq {
> >> > > >> >   reg_domain = 0x14000000, 0x14010000, 0x14020000
> >> > > >> > }
> >> > > >>
> >> > > >> The devicetree should only model hardware relationships, not software
> >> > > >> considerations.
> >> > > >>
> >> > > >> Is the hardware constraint here for using gce with various other
> >> > > >> hardware blocks?  I think we already model this by only providing a
> >> > > >> gce phandle in the device tree nodes for those devices that can use
> >> > > >> gce.
> >> > > >>
> >> > > >> Looking at the driver closer, as far as I can tell, the whole subsys
> >> > > >> concept is a purely software abstraction, and only used to debug the
> >> > > >> CMDQ_CODE_WRITE command.  In fact, AFAICT, everything would work fine
> >> > > >> if we just completely removed the 'subsys' concept, and just passed
> >> > > >> through the raw address provided by the driver.
> >> > > >>
> >> > > >> So, I recommend just removing 'subsys' completely from the driver -
> >> > > >> from this array, and in the masks.
> >> > > >>
> >> > > >> Instead, if there is an error on the write command, just print the
> >> > > >> address that fails.  There are other ways to deduce the subsystem from
> >> > > >> a physical address.
> >> > > >>
> >> > > >> Thanks,
> >> > > >>
> >> > > >> -Dan
> >> > > >
> >> > > > Hi Dan,
> >> > > >
> >> > > > Subsys is not just for debug.
> >> > > > Its main purpose is to transfer CPU address to GCE address.
> >> > > > Let me explain it by "write" op,
> >> > > > I list a code segment from cmdq_rec_append_command().
> >> > > >
> >> > > >         case CMDQ_CODE_WRITE:
> >> > > >                 subsys = cmdq_subsys_from_phys_addr(cqctx, arg_a);
> >> > > >                 if (subsys < 0) {
> >> > > >                         dev_err(dev,
> >> > > >                                 "unsupported memory base address 0x%08x\n",
> >> > > >                                 arg_a);
> >> > > >                         return -EFAULT;
> >> > > >                 }
> >> > > >
> >> > > >                 *cmd_ptr++ = arg_b;
> >> > > >                 *cmd_ptr++ = (CMDQ_CODE_WRITE << CMDQ_OP_CODE_SHIFT) |
> >> > > >                              (arg_a & CMDQ_ARG_A_WRITE_MASK) |
> >> > > >                              ((subsys & CMDQ_SUBSYS_MASK) << CMDQ_SUBSYS_SHIFT);
> >> > > >                 break;
> >> > > >
> >> > > > Subsys is mapped from physical address via cmdq_subsys_from_phys_addr(),
> >> > > > and then it becomes part of GCE command via ((subsys & CMDQ_SUBSYS_MASK)
> >> > > > << CMDQ_SUBSYS_SHIFT) .
> >> > > > Only low bits of physical address are the same as GCE address.
> >> > > > We can get it by (arg_a & CMDQ_ARG_A_WRITE_MASK).
> >> > > > MASK is used to define how many bits are valid for this op.
> >> > > > So, GCE address = subsys + valid low bits.
> >> > >
> >> > > How are these upper bits of the "GCE address" defined?
> >> > > In other words, for a given SoC, how is the mapping between physical
> >> > > io addresses to GCE addresses defined?
> >> > > Is this mapping fixed by hardware?
> >>
> >> Please answer the detailed technical questions:
> >>
> >> How are these upper bits of the "GCE address" defined?
> >
> > A GCE command is arg_a + arg_b. Both of them have 32 bits length.
> > arg_a is op + subsys + addr, and arg_b is value.
> > subsys + addr is less than 32bits, so we need to map address range to
> > subsys.
> > The mapping rule is defined by hardware.
> >
> >> In other words, for a given SoC, how is the mapping between physical
> >> io addresses to GCE addresses defined?
> >
> > It is (b).
> >
> >>
> >> (a) Does the GCE remap a continuous device IO address range?
> >>
> >> AFAICT, the  defines an MT8173 specific mapping of:
> >>
> >> For example, the g_subsys table above seems to imply that the MT8173
> >> gce maps all of:
> >>   0x1400ffff:0x141fffff => 0x010000:0x1fffff
> >>
> >> (b) Or, are the upper 5 bits of the "gce address" significant, and via
> >> hardware it can map a disjoint groups of device addresses into the
> >> continuous GCE address space, and really there are 0x1f distinct 64k
> >> mappings:
> >>
> >> mmsys (1) : 0x14000000:0x1400ffff => 0x010000:0x01ffff
> >> disp  (2) : 0x14010000:0x1401ffff => 0x020000:0x02ffff
> >> disp  (3) : 0x14020000:0x1402ffff => 0x030000:0x03ffff
> >> ...
> >> ???? (1f) : 0x141fffff:0x141fffff => 0x1f0000:0x1fffff
> >>
> >> If the mapping is fixed and continuous (a), then I think all we need
> >> is a single dts entry for the gce node that describes how it performs
> >> this mapping.  And then, the gce consumers can just pass in their
> >> regular physical addresses, and the gce driver can remap them directly
> >> to gce addresses.
> >>
> >> WDYT?
> >
> > How about this?
> > hardware_module = <address_base subsys_id mask>;
> > So, the result is
> > mmsys_config_base = <0x14000000 1 0xffff0000>;
> > disp_rdma_config_base = <0x14010000 2 0xffff0000>;
> > disp_mutex_config_base = <0x14020000 3 0xffff0000>;
> 
> What uses ID 0 and 4 - 0x1f?

Subsys is defined by GCE hardware, and other IDs are reserved currently.

> According to mt8173.dtsi, here are the blocks in the address ranges above:
> 
> @1400:
>   mmsys: clock-controller at 14000000
>   ovl0: ovl at 1400c000
>   ovl1: ovl at 1400d000
>   rdma0: rdma at 1400e000
>   rdma1: rdma at 1400f000
> 
> @1401:
>   rdma2: rdma at 14010000
>   wdma0: wdma at 14011000
>   wdma1: wdma at 14012000
>   color0: color at 14013000
>   color1: color at 14014000
>   aal at 14015000
>   gamma at 14016000
>   merge at 14017000
>   split0: split at 14018000
>   split1: split at 14019000
>   ufoe at 1401a000
>   dsi0: dsi at 1401b000
>   dsi1: dsi at 1401c000
>   dpi0: dpi at 1401d000
>   pwm0: pwm at 1401e000
>   pwm1: pwm at 1401f000
> 
> @1402:
>   mutex: mutex at 14020000
>   od at 14023000
>   larb0: larb at 14021000
>   smi_common: smi at 14022000
>   hdmi0: hdmi at 14025000
>   larb4: larb at 14027000
> 
> I assume that the gce will work with any of the devices in those
> ranges, not just "mmsys", "rdma" and "mutex", right?   (Also, notice

That's right.

> there are two "rdma" in the @1400 range, so rdma is really not a good
> name for @1401)

I think we can just use index.
disp0_config_base = <0x14000000 1 0xffff0000>;
disp1_config_base = <0x14010000 2 0xffff0000>;
disp2_config_base = <0x14020000 3 0xffff0000>;

> Further, it looks like the gce just maps a large device address range
> starting at 0x14000000 to (21-bit) gce address 0x010000, rather than
> 31 individually addressable 64k "subsys" blocks.  Is there a counter
> example that I am missing?

>From GCE's point of view,
it's 32 (0x0~0x1f) individually addressable 64k "subsys" blocks.
Currently, we don't have a counter example since all display related
address are put together.

> -Dan

Thanks,
HS Liao

> >
> >> -Dan
> >>
> >> >
> >> > Yes, this mapping is fixed by hardware.
> >> >
> >> > > Does it vary for different SoCs?
> >> >
> >> > Yes, it varies for different SoCs.
> >> >
> >> > >
> >> > > -Dan
> >> > >
> >> > > > That's why we need to know the mapping between the range of physical
> >> > > > address and subsys.
> >> > > > Please guide us a better way to code such requirement.
> >> > > > Thanks for your help.
> >> > > >
> >> > > > Thanks,
> >> > > > HS Liao
> >> > > >
> >> >
> >> > Thanks,
> >> > HS Liao
> >> >
> >
> > Thanks,
> > HS Liao
> >




From moinejf at free.fr  Mon Feb  1 22:52:39 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Tue, 2 Feb 2016 07:52:39 +0100
Subject: [PATCH v3 2/2] clk: sunxi: Refactor A31 PLL6 so that it can be
 reused
In-Reply-To: <20160201201754.GI4652@lukather>
References: <1454008958-12655-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454008958-12655-2-git-send-email-maxime.ripard@free-electrons.com>
 <20160130185714.7abcf1de9ef8108c2f48c7fe@free.fr>
 <20160201201754.GI4652@lukather>
Message-ID: <20160202075239.e4318e9dced1eeed29c593f6@free.fr>

On Mon, 1 Feb 2016 21:17:54 +0100
Maxime Ripard <maxime.ripard at free-electrons.com> wrote:

> > Also, for the H3 PLL periph1 (aka PLL8), why didn't you create a
> > 'pll8x2' clock with 'pll8' as a divider?
> 
> No one seems to use it. We can always add it later in a separate
> patch when someone will.

Well, then, I don't understand. The pll periph/peripheral/periph0,
aka PLL6 works well for many SoCs and there is no need to change
its DT definition.

In the patch header, you wrote:

> Remove the fixed dividers from the PLL6 driver to be able to have a
> reusable driver that can be used across several SoCs that share the same
> controller, but don't have the same set of dividers for this clock, and to
> also be reused multiple times in the same SoC, since we're droping the
> clock name.

then, for the H3, you do
(the comment should be "until pll8 can be reused"),

> -		/* dummy clock until pll6 can be reused */
> -		pll8: pll8_clk {
> +		pll8: clk at 01c20044 {
>  			#clock-cells = <0>;
> -			compatible = "fixed-clock";
> -			clock-frequency = <1>;
> +			compatible = "allwinner,sun6i-a31-pll6-clk";
> +			reg = <0x01c20044 0x4>;
> +			clocks = <&osc24M>;
>  			clock-output-names = "pll8";
>  		};

that is, you add the PLL8, don't you?

And, further, you change the MMC clocks:

> @@ -243,7 +243,7 @@
>  			#clock-cells = <1>;
>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>  			reg = <0x01c20088 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
> +			clocks = <&osc24M>, <&pll6>, <&pll8>;
>  			clock-output-names = "mmc0",
>  					     "mmc0_output",
>  					     "mmc0_sample";

where the PLL8 is already used.

So, how can you say

> No one seems to use it. We can always add it later in a separate
> patch when someone will.

?

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/



From shawnguo at kernel.org  Mon Feb  1 22:53:07 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 2 Feb 2016 14:53:07 +0800
Subject: [PATCH 1/4] ARM: dts: imx53: add ethernet PHY supply regulator
In-Reply-To: <1453295362-18798-2-git-send-email-LW@KARO-electronics.de>
References: <1453295362-18798-1-git-send-email-LW@KARO-electronics.de>
 <1453295362-18798-2-git-send-email-LW@KARO-electronics.de>
Message-ID: <20160202065306.GH8307@tiger>

On Wed, Jan 20, 2016 at 02:09:19PM +0100, Lothar Wa?mann wrote:
> Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
> ---
>  arch/arm/boot/dts/imx53-tx53.dtsi | 40 ++++++++++++++++++++++++++++++---------
>  1 file changed, 31 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx53-tx53.dtsi b/arch/arm/boot/dts/imx53-tx53.dtsi
> index d3e50b2..8f08389 100644
> --- a/arch/arm/boot/dts/imx53-tx53.dtsi
> +++ b/arch/arm/boot/dts/imx53-tx53.dtsi
> @@ -87,9 +87,20 @@
>  			regulator-max-microvolt = <3300000>;
>  		};
>  
> -		reg_can_xcvr: regulator at 2 {
> +		reg_3v3_etn: regulator at 2 {

Why cannot this be added as regulator at 5 to avoid changing every node?

>  			compatible = "regulator-fixed";
>  			reg = <2>;
> +			regulator-name = "ETN 3V3";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_etn_phy>;
> +			gpio = <&gpio3 20 GPIO_ACTIVE_HIGH>;
> +		};
> +
> +		reg_can_xcvr: regulator at 3 {
> +			compatible = "regulator-fixed";
> +			reg = <3>;
>  			regulator-name = "CAN XCVR";
>  			regulator-min-microvolt = <3300000>;
>  			regulator-max-microvolt = <3300000>;
> @@ -98,9 +109,9 @@
>  			gpio = <&gpio4 21 GPIO_ACTIVE_HIGH>;
>  		};
>  
> -		reg_usbh1_vbus: regulator at 3 {
> +		reg_usbh1_vbus: regulator at 4 {
>  			compatible = "regulator-fixed";
> -			reg = <3>;
> +			reg = <4>;
>  			regulator-name = "usbh1_vbus";
>  			regulator-min-microvolt = <5000000>;
>  			regulator-max-microvolt = <5000000>;
> @@ -110,9 +121,9 @@
>  			enable-active-high;
>  		};
>  
> -		reg_usbotg_vbus: regulator at 4 {
> +		reg_usbotg_vbus: regulator at 5 {
>  			compatible = "regulator-fixed";
> -			reg = <4>;
> +			reg = <5>;
>  			regulator-name = "usbotg_vbus";
>  			regulator-min-microvolt = <5000000>;
>  			regulator-max-microvolt = <5000000>;
> @@ -204,13 +215,20 @@
>  	phy-mode = "rmii";
>  	phy-reset-gpios = <&gpio7 6 GPIO_ACTIVE_HIGH>;
>  	phy-handle = <&phy0>;
> +	phy-supply = <&reg_3v3_etn>;
>  	mac-address = [000000000000]; /* placeholder; will be overwritten by bootloader */
>  	status = "okay";
>  
> -	phy0: ethernet-phy at 0 {
> -		interrupt-parent = <&gpio2>;
> -		interrupts = <4>;
> -		device_type = "ethernet-phy";
> +	mdio {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		phy0: ethernet-phy at 0 {
> +			compatible = "ethernet-phy-id0007.c0f1", "ethernet-phy-ieee802.3-c22";
> +			reg = <0>;
> +			interrupt-parent = <&gpio2>;
> +			interrupts = <4>;
> +		};

This should be a separate change.

Shawn

>  	};
>  };
>  
> @@ -309,6 +327,10 @@
>  			fsl,pins = <MX53_PAD_DISP0_DAT0__GPIO4_21 0xe0>; /* Flexcan XCVR enable */
>  		};
>  
> +		pinctrl_etn_phy: etn-phygrp {
> +			fsl,pins = <MX53_PAD_EIM_D20__GPIO3_20 0xe0>; /* ETN PHY Power enable */
> +		};
> +
>  		pinctrl_ds1339: ds1339grp {
>  			fsl,pins = <MX53_PAD_DI0_PIN4__GPIO4_20 0xe0>;
>  		};
> -- 
> 2.1.4
> 
> 


From takahiro.akashi at linaro.org  Mon Feb  1 22:53:49 2016
From: takahiro.akashi at linaro.org (AKASHI Takahiro)
Date: Tue, 2 Feb 2016 15:53:49 +0900
Subject: [PATCH v4 04/13] arm64: Add new hcall HVC_CALL_FUNC
In-Reply-To: <1453977766-20907-5-git-send-email-james.morse@arm.com>
References: <1453977766-20907-1-git-send-email-james.morse@arm.com>
 <1453977766-20907-5-git-send-email-james.morse@arm.com>
Message-ID: <56B0527D.8060109@linaro.org>

On 01/28/2016 07:42 PM, James Morse wrote:
> From: Geoff Levand <geoff at infradead.org>
>
> Add the new hcall HVC_CALL_FUNC that allows execution of a function at EL2.
> During CPU reset the CPU must be brought to the exception level it had on
> entry to the kernel.  The HVC_CALL_FUNC hcall will provide the mechanism
> needed for this exception level switch.
>
> To allow the HVC_CALL_FUNC exception vector to work without a stack, which
> is needed to support an hcall at CPU reset, this implementation uses
> register x18 to store the link register across the caller provided
> function.  This dictates that the caller provided function must preserve
> the contents of register x18.
>
> Signed-off-by: Geoff Levand <geoff at infradead.org>
> Signed-off-by: James Morse <james.morse at arm.com>
> ---
> This patch is from v13 of kexec
>
>   arch/arm64/include/asm/virt.h | 13 +++++++++++++
>   arch/arm64/kernel/hyp-stub.S  | 13 ++++++++++++-
>   2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
> index eb10368c329e..30700961f28c 100644
> --- a/arch/arm64/include/asm/virt.h
> +++ b/arch/arm64/include/asm/virt.h
> @@ -45,6 +45,19 @@
>
>   #define HVC_SET_VECTORS 2
>
> +/*
> + * HVC_CALL_FUNC - Execute a function at EL2.
> + *
> + * @x0: Physical address of the function to be executed.
> + * @x1: Passed as the first argument to the function.
> + * @x2: Passed as the second argument to the function.
> + * @x3: Passed as the third argument to the function.
> + *
> + * The called function must preserve the contents of register x18.
> + */
> +
> +#define HVC_CALL_FUNC 3
> +
>   #define BOOT_CPU_MODE_EL1	(0xe11)
>   #define BOOT_CPU_MODE_EL2	(0xe12)
>
> diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
> index 017ab519aaf1..e8febe90c036 100644
> --- a/arch/arm64/kernel/hyp-stub.S
> +++ b/arch/arm64/kernel/hyp-stub.S
> @@ -67,8 +67,19 @@ el1_sync:
>   	b	2f
>
>   1:	cmp	x18, #HVC_SET_VECTORS
> -	b.ne	2f
> +	b.ne	1f
>   	msr	vbar_el2, x0
> +	b	2f
> +
> +1:	cmp	x18, #HVC_CALL_FUNC

I think we should avoid duplicated label names ("1") in a short distance.
(I know it's Geoff's code.)

-Takahiro AKASHI

> +	b.ne	2f
> +	mov	x18, lr
> +	mov	lr, x0
> +	mov	x0, x1
> +	mov	x1, x2
> +	mov	x2, x3
> +	blr	lr
> +	mov	lr, x18
>
>   2:	eret
>   ENDPROC(el1_sync)
>


From jamesjj.liao at mediatek.com  Mon Feb  1 22:56:52 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Tue, 2 Feb 2016 14:56:52 +0800
Subject: [PATCH v4 1/4] soc: mediatek: Refine scpsys to support multiple
 platform
In-Reply-To: <56ADF556.6070402@gmail.com>
References: <1453270097-53853-1-git-send-email-jamesjj.liao@mediatek.com>
 <1453270097-53853-2-git-send-email-jamesjj.liao@mediatek.com>
 <56ADF556.6070402@gmail.com>
Message-ID: <1454396212.2847.15.camel@mtksdaap41>

Hi Matthias,

On Sun, 2016-01-31 at 12:51 +0100, Matthias Brugger wrote:
> 
> On 20/01/16 07:08, James Liao wrote:
> > Refine scpsys driver common code to support multiple SoC / platform.
> >
> > Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
> > ---
> >   drivers/soc/mediatek/mtk-scpsys.c | 418 ++++++++++++++++++++------------------
> >   drivers/soc/mediatek/mtk-scpsys.h |  55 +++++
> >   2 files changed, 270 insertions(+), 203 deletions(-)
> >   create mode 100644 drivers/soc/mediatek/mtk-scpsys.h
> 
> In general this approach looks fine to me, comments below.
> 
> >
> > diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> > index 0221387..339adfc 100644
> > --- a/drivers/soc/mediatek/mtk-scpsys.c
> > +++ b/drivers/soc/mediatek/mtk-scpsys.c
> > @@ -11,29 +11,17 @@
> >    * GNU General Public License for more details.
> >    */
> >   #include <linux/clk.h>
> > -#include <linux/delay.h>
> > +#include <linux/init.h>
> >   #include <linux/io.h>
> > -#include <linux/kernel.h>
> >   #include <linux/mfd/syscon.h>
> 
> When at it, do we need this include?

syscon_regmap_lookup_by_phandle() is declared in this head file.

> > -#include <linux/init.h>
> >   #include <linux/of_device.h>
> >   #include <linux/platform_device.h>
> >   #include <linux/pm_domain.h>
> > -#include <linux/regmap.h>
> > -#include <linux/soc/mediatek/infracfg.h>
> >   #include <linux/regulator/consumer.h>
> > -#include <dt-bindings/power/mt8173-power.h>
> > +#include <linux/soc/mediatek/infracfg.h>
> > +
> > +#include "mtk-scpsys.h"
> >
> > -#define SPM_VDE_PWR_CON			0x0210
> > -#define SPM_MFG_PWR_CON			0x0214
> > -#define SPM_VEN_PWR_CON			0x0230
> > -#define SPM_ISP_PWR_CON			0x0238
> > -#define SPM_DIS_PWR_CON			0x023c
> > -#define SPM_VEN2_PWR_CON		0x0298
> > -#define SPM_AUDIO_PWR_CON		0x029c
> > -#define SPM_MFG_2D_PWR_CON		0x02c0
> > -#define SPM_MFG_ASYNC_PWR_CON		0x02c4
> > -#define SPM_USB_PWR_CON			0x02cc
> 
> I would prefer to keep this defines and declare SoC specific ones where 
> necessary. It makes the code more readable.

Some register address may be reused by other modules among SoCs, so it's
not easy to maintain the defines when we implement multiple SoC drivers
in the same file. For example, offset 0x0298 is VEN2_PWR_CON on MT8173,
but it is MJC_PWR_CON on other chips.

Furthermore, these register offsets are only used in scp_domain_data[],
and each element has its own power domain name. So I think it's enough
to know which power domain are using these registers and status bits.

> >   #define SPM_PWR_STATUS			0x060c
> >   #define SPM_PWR_STATUS_2ND		0x0610
> >
> > @@ -43,154 +31,6 @@
> >   #define PWR_ON_2ND_BIT			BIT(3)
> >   #define PWR_CLK_DIS_BIT			BIT(4)
> >
> > -#define PWR_STATUS_DISP			BIT(3)
> > -#define PWR_STATUS_MFG			BIT(4)
> > -#define PWR_STATUS_ISP			BIT(5)
> > -#define PWR_STATUS_VDEC			BIT(7)
> > -#define PWR_STATUS_VENC_LT		BIT(20)
> > -#define PWR_STATUS_VENC			BIT(21)
> > -#define PWR_STATUS_MFG_2D		BIT(22)
> > -#define PWR_STATUS_MFG_ASYNC		BIT(23)
> > -#define PWR_STATUS_AUDIO		BIT(24)
> > -#define PWR_STATUS_USB			BIT(25)
> > -
> 
> Same here.
> 
> > -enum clk_id {
> > -	MT8173_CLK_NONE,
> > -	MT8173_CLK_MM,
> > -	MT8173_CLK_MFG,
> > -	MT8173_CLK_VENC,
> > -	MT8173_CLK_VENC_LT,
> > -	MT8173_CLK_MAX,
> > -};
> > -
> > -#define MAX_CLKS	2
> > -
> > -struct scp_domain_data {
> > -	const char *name;
> > -	u32 sta_mask;
> > -	int ctl_offs;
> > -	u32 sram_pdn_bits;
> > -	u32 sram_pdn_ack_bits;
> > -	u32 bus_prot_mask;
> > -	enum clk_id clk_id[MAX_CLKS];
> > -	bool active_wakeup;
> > -};
> > -
> > -static const struct scp_domain_data scp_domain_data[] __initconst = {
> > -	[MT8173_POWER_DOMAIN_VDEC] = {
> > -		.name = "vdec",
> > -		.sta_mask = PWR_STATUS_VDEC,
> > -		.ctl_offs = SPM_VDE_PWR_CON,
> > -		.sram_pdn_bits = GENMASK(11, 8),
> > -		.sram_pdn_ack_bits = GENMASK(12, 12),
> > -		.clk_id = {MT8173_CLK_MM},
> > -	},
> > -	[MT8173_POWER_DOMAIN_VENC] = {
> > -		.name = "venc",
> > -		.sta_mask = PWR_STATUS_VENC,
> > -		.ctl_offs = SPM_VEN_PWR_CON,
> > -		.sram_pdn_bits = GENMASK(11, 8),
> > -		.sram_pdn_ack_bits = GENMASK(15, 12),
> > -		.clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC},
> > -	},
> > -	[MT8173_POWER_DOMAIN_ISP] = {
> > -		.name = "isp",
> > -		.sta_mask = PWR_STATUS_ISP,
> > -		.ctl_offs = SPM_ISP_PWR_CON,
> > -		.sram_pdn_bits = GENMASK(11, 8),
> > -		.sram_pdn_ack_bits = GENMASK(13, 12),
> > -		.clk_id = {MT8173_CLK_MM},
> > -	},
> > -	[MT8173_POWER_DOMAIN_MM] = {
> > -		.name = "mm",
> > -		.sta_mask = PWR_STATUS_DISP,
> > -		.ctl_offs = SPM_DIS_PWR_CON,
> > -		.sram_pdn_bits = GENMASK(11, 8),
> > -		.sram_pdn_ack_bits = GENMASK(12, 12),
> > -		.clk_id = {MT8173_CLK_MM},
> > -		.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
> > -			MT8173_TOP_AXI_PROT_EN_MM_M1,
> > -	},
> > -	[MT8173_POWER_DOMAIN_VENC_LT] = {
> > -		.name = "venc_lt",
> > -		.sta_mask = PWR_STATUS_VENC_LT,
> > -		.ctl_offs = SPM_VEN2_PWR_CON,
> > -		.sram_pdn_bits = GENMASK(11, 8),
> > -		.sram_pdn_ack_bits = GENMASK(15, 12),
> > -		.clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC_LT},
> > -	},
> > -	[MT8173_POWER_DOMAIN_AUDIO] = {
> > -		.name = "audio",
> > -		.sta_mask = PWR_STATUS_AUDIO,
> > -		.ctl_offs = SPM_AUDIO_PWR_CON,
> > -		.sram_pdn_bits = GENMASK(11, 8),
> > -		.sram_pdn_ack_bits = GENMASK(15, 12),
> > -		.clk_id = {MT8173_CLK_NONE},
> > -	},
> > -	[MT8173_POWER_DOMAIN_USB] = {
> > -		.name = "usb",
> > -		.sta_mask = PWR_STATUS_USB,
> > -		.ctl_offs = SPM_USB_PWR_CON,
> > -		.sram_pdn_bits = GENMASK(11, 8),
> > -		.sram_pdn_ack_bits = GENMASK(15, 12),
> > -		.clk_id = {MT8173_CLK_NONE},
> > -		.active_wakeup = true,
> > -	},
> > -	[MT8173_POWER_DOMAIN_MFG_ASYNC] = {
> > -		.name = "mfg_async",
> > -		.sta_mask = PWR_STATUS_MFG_ASYNC,
> > -		.ctl_offs = SPM_MFG_ASYNC_PWR_CON,
> > -		.sram_pdn_bits = GENMASK(11, 8),
> > -		.sram_pdn_ack_bits = 0,
> > -		.clk_id = {MT8173_CLK_MFG},
> > -	},
> > -	[MT8173_POWER_DOMAIN_MFG_2D] = {
> > -		.name = "mfg_2d",
> > -		.sta_mask = PWR_STATUS_MFG_2D,
> > -		.ctl_offs = SPM_MFG_2D_PWR_CON,
> > -		.sram_pdn_bits = GENMASK(11, 8),
> > -		.sram_pdn_ack_bits = GENMASK(13, 12),
> > -		.clk_id = {MT8173_CLK_NONE},
> > -	},
> > -	[MT8173_POWER_DOMAIN_MFG] = {
> > -		.name = "mfg",
> > -		.sta_mask = PWR_STATUS_MFG,
> > -		.ctl_offs = SPM_MFG_PWR_CON,
> > -		.sram_pdn_bits = GENMASK(13, 8),
> > -		.sram_pdn_ack_bits = GENMASK(21, 16),
> > -		.clk_id = {MT8173_CLK_NONE},
> > -		.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MFG_S |
> > -			MT8173_TOP_AXI_PROT_EN_MFG_M0 |
> > -			MT8173_TOP_AXI_PROT_EN_MFG_M1 |
> > -			MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT,
> > -	},
> > -};
> > -
> > -#define NUM_DOMAINS	ARRAY_SIZE(scp_domain_data)
> > -
> > -struct scp;
> > -
> > -struct scp_domain {
> > -	struct generic_pm_domain genpd;
> > -	struct scp *scp;
> > -	struct clk *clk[MAX_CLKS];
> > -	u32 sta_mask;
> > -	void __iomem *ctl_addr;
> > -	u32 sram_pdn_bits;
> > -	u32 sram_pdn_ack_bits;
> > -	u32 bus_prot_mask;
> > -	bool active_wakeup;
> > -	struct regulator *supply;
> > -};
> > -
> > -struct scp {
> > -	struct scp_domain domains[NUM_DOMAINS];
> > -	struct genpd_onecell_data pd_data;
> > -	struct device *dev;
> > -	void __iomem *base;
> > -	struct regmap *infracfg;
> > -};
> > -
> >   static int scpsys_domain_is_on(struct scp_domain *scpd)
> >   {
> >   	struct scp *scp = scpd->scp;
> > @@ -412,57 +252,69 @@ static bool scpsys_active_wakeup(struct device *dev)
> >   	return scpd->active_wakeup;
> >   }
> >
> > -static int __init scpsys_probe(struct platform_device *pdev)
> > +static void init_clks(struct platform_device *pdev, struct clk *clk[CLK_MAX])
> > +{
> > +	enum clk_id clk_ids[] = {
> > +		CLK_MM,
> > +		CLK_MFG,
> > +		CLK_VENC,
> > +		CLK_VENC_LT
> > +	};
> > +
> > +	static const char * const clk_names[] = {
> > +		"mm",
> > +		"mfg",
> > +		"venc",
> > +		"venc_lt",
> > +	};
> > +
> > +	int i;
> > +
> > +	for (i = 0; i < ARRAY_SIZE(clk_ids); i++)
> > +		clk[clk_ids[i]] = devm_clk_get(&pdev->dev, clk_names[i]);
> > +}
> > +
> > +struct scp *init_scp(struct platform_device *pdev,
> > +			const struct scp_domain_data *scp_domain_data, int num)
> >   {
> >   	struct genpd_onecell_data *pd_data;
> >   	struct resource *res;
> > -	int i, j, ret;
> > +	int i, j;
> >   	struct scp *scp;
> > -	struct clk *clk[MT8173_CLK_MAX];
> > +	struct clk *clk[CLK_MAX];
> >
> >   	scp = devm_kzalloc(&pdev->dev, sizeof(*scp), GFP_KERNEL);
> >   	if (!scp)
> > -		return -ENOMEM;
> > +		return ERR_PTR(-ENOMEM);
> >
> >   	scp->dev = &pdev->dev;
> >
> >   	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >   	scp->base = devm_ioremap_resource(&pdev->dev, res);
> >   	if (IS_ERR(scp->base))
> > -		return PTR_ERR(scp->base);
> > -
> > -	pd_data = &scp->pd_data;
> > -
> > -	pd_data->domains = devm_kzalloc(&pdev->dev,
> > -			sizeof(*pd_data->domains) * NUM_DOMAINS, GFP_KERNEL);
> > -	if (!pd_data->domains)
> > -		return -ENOMEM;
> > -
> > -	clk[MT8173_CLK_MM] = devm_clk_get(&pdev->dev, "mm");
> > -	if (IS_ERR(clk[MT8173_CLK_MM]))
> > -		return PTR_ERR(clk[MT8173_CLK_MM]);
> > -
> > -	clk[MT8173_CLK_MFG] = devm_clk_get(&pdev->dev, "mfg");
> > -	if (IS_ERR(clk[MT8173_CLK_MFG]))
> > -		return PTR_ERR(clk[MT8173_CLK_MFG]);
> > -
> > -	clk[MT8173_CLK_VENC] = devm_clk_get(&pdev->dev, "venc");
> > -	if (IS_ERR(clk[MT8173_CLK_VENC]))
> > -		return PTR_ERR(clk[MT8173_CLK_VENC]);
> > -
> > -	clk[MT8173_CLK_VENC_LT] = devm_clk_get(&pdev->dev, "venc_lt");
> > -	if (IS_ERR(clk[MT8173_CLK_VENC_LT]))
> > -		return PTR_ERR(clk[MT8173_CLK_VENC_LT]);
> > +		return ERR_CAST(scp->base);
> >
> >   	scp->infracfg = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
> >   			"infracfg");
> >   	if (IS_ERR(scp->infracfg)) {
> >   		dev_err(&pdev->dev, "Cannot find infracfg controller: %ld\n",
> >   				PTR_ERR(scp->infracfg));
> > -		return PTR_ERR(scp->infracfg);
> > +		return ERR_CAST(scp->infracfg);
> >   	}
> >
> > -	for (i = 0; i < NUM_DOMAINS; i++) {
> > +	scp->domains = devm_kzalloc(&pdev->dev,
> > +				sizeof(*scp->domains) * num, GFP_KERNEL);
> > +	if (!scp->domains)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	pd_data = &scp->pd_data;
> > +
> > +	pd_data->domains = devm_kzalloc(&pdev->dev,
> > +			sizeof(*pd_data->domains) * num, GFP_KERNEL);
> > +	if (!pd_data->domains)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	for (i = 0; i < num; i++) {
> >   		struct scp_domain *scpd = &scp->domains[i];
> >   		const struct scp_domain_data *data = &scp_domain_data[i];
> >
> > @@ -471,17 +323,31 @@ static int __init scpsys_probe(struct platform_device *pdev)
> >   			if (PTR_ERR(scpd->supply) == -ENODEV)
> >   				scpd->supply = NULL;
> >   			else
> > -				return PTR_ERR(scpd->supply);
> > +				return ERR_CAST(scpd->supply);
> >   		}
> >   	}
> >
> > -	pd_data->num_domains = NUM_DOMAINS;
> > +	pd_data->num_domains = num;
> >
> > -	for (i = 0; i < NUM_DOMAINS; i++) {
> > +	init_clks(pdev, clk);
> > +
> > +	for (i = 0; i < num; i++) {
> >   		struct scp_domain *scpd = &scp->domains[i];
> >   		struct generic_pm_domain *genpd = &scpd->genpd;
> >   		const struct scp_domain_data *data = &scp_domain_data[i];
> >
> > +		for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) {
> > +			struct clk *c = clk[data->clk_id[j]];
> > +
> > +			if (IS_ERR(c)) {
> > +				dev_err(&pdev->dev, "%s: clk unavailable\n",
> > +					data->name);
> > +				return ERR_CAST(c);
> > +			}
> > +
> > +			scpd->clk[j] = c;
> > +		}
> > +
> >   		pd_data->domains[i] = genpd;
> >   		scpd->scp = scp;
> >
> > @@ -491,13 +357,25 @@ static int __init scpsys_probe(struct platform_device *pdev)
> >   		scpd->sram_pdn_ack_bits = data->sram_pdn_ack_bits;
> >   		scpd->bus_prot_mask = data->bus_prot_mask;
> >   		scpd->active_wakeup = data->active_wakeup;
> > -		for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++)
> > -			scpd->clk[j] = clk[data->clk_id[j]];
> >
> >   		genpd->name = data->name;
> >   		genpd->power_off = scpsys_power_off;
> >   		genpd->power_on = scpsys_power_on;
> >   		genpd->dev_ops.active_wakeup = scpsys_active_wakeup;
> > +	}
> > +
> > +	return scp;
> > +}
> > +
> > +void mtk_register_power_domains(struct platform_device *pdev,
> > +				struct scp *scp, int num)
> > +{
> > +	struct genpd_onecell_data *pd_data;
> > +	int i, ret;
> > +
> > +	for (i = 0; i < num; i++) {
> > +		struct scp_domain *scpd = &scp->domains[i];
> > +		struct generic_pm_domain *genpd = &scpd->genpd;
> >
> >   		/*
> >   		 * Initially turn on all domains to make the domains usable
> > @@ -516,6 +394,125 @@ static int __init scpsys_probe(struct platform_device *pdev)
> >   	 * valid.
> >   	 */
> >
> > +	pd_data = &scp->pd_data;
> > +
> > +	ret = of_genpd_add_provider_onecell(pdev->dev.of_node, pd_data);
> > +	if (ret)
> > +		dev_err(&pdev->dev, "Failed to add OF provider: %d\n", ret);
> > +}
> > +
> > +/*
> > + * MT8173 power domain support
> > + */
> > +
> > +#include <dt-bindings/power/mt8173-power.h>
> 
> Please put the includes at the beginning of the file.
> Same for mt2701 of course.

OK, I'll change it in next patch.


Best regards,

James

> > +
> > +static const struct scp_domain_data scp_domain_data_mt8173[] __initconst = {
> > +	[MT8173_POWER_DOMAIN_VDEC] = {
> > +		.name = "vdec",
> > +		.sta_mask = BIT(7),
> > +		.ctl_offs = 0x0210,
> > +		.sram_pdn_bits = GENMASK(11, 8),
> > +		.sram_pdn_ack_bits = GENMASK(12, 12),
> > +		.clk_id = {CLK_MM},
> > +	},
> > +	[MT8173_POWER_DOMAIN_VENC] = {
> > +		.name = "venc",
> > +		.sta_mask = BIT(21),
> > +		.ctl_offs = 0x0230,
> > +		.sram_pdn_bits = GENMASK(11, 8),
> > +		.sram_pdn_ack_bits = GENMASK(15, 12),
> > +		.clk_id = {CLK_MM, CLK_VENC},
> > +	},
> > +	[MT8173_POWER_DOMAIN_ISP] = {
> > +		.name = "isp",
> > +		.sta_mask = BIT(5),
> > +		.ctl_offs = 0x0238,
> > +		.sram_pdn_bits = GENMASK(11, 8),
> > +		.sram_pdn_ack_bits = GENMASK(13, 12),
> > +		.clk_id = {CLK_MM},
> > +	},
> > +	[MT8173_POWER_DOMAIN_MM] = {
> > +		.name = "mm",
> > +		.sta_mask = BIT(3),
> > +		.ctl_offs = 0x023c,
> > +		.sram_pdn_bits = GENMASK(11, 8),
> > +		.sram_pdn_ack_bits = GENMASK(12, 12),
> > +		.clk_id = {CLK_MM},
> > +		.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
> > +			MT8173_TOP_AXI_PROT_EN_MM_M1,
> > +	},
> > +	[MT8173_POWER_DOMAIN_VENC_LT] = {
> > +		.name = "venc_lt",
> > +		.sta_mask = BIT(20),
> > +		.ctl_offs = 0x0298,
> > +		.sram_pdn_bits = GENMASK(11, 8),
> > +		.sram_pdn_ack_bits = GENMASK(15, 12),
> > +		.clk_id = {CLK_MM, CLK_VENC_LT},
> > +	},
> > +	[MT8173_POWER_DOMAIN_AUDIO] = {
> > +		.name = "audio",
> > +		.sta_mask = BIT(24),
> > +		.ctl_offs = 0x029c,
> > +		.sram_pdn_bits = GENMASK(11, 8),
> > +		.sram_pdn_ack_bits = GENMASK(15, 12),
> > +		.clk_id = {CLK_NONE},
> > +	},
> > +	[MT8173_POWER_DOMAIN_USB] = {
> > +		.name = "usb",
> > +		.sta_mask = BIT(25),
> > +		.ctl_offs = 0x02cc,
> > +		.sram_pdn_bits = GENMASK(11, 8),
> > +		.sram_pdn_ack_bits = GENMASK(15, 12),
> > +		.clk_id = {CLK_NONE},
> > +		.active_wakeup = true,
> > +	},
> > +	[MT8173_POWER_DOMAIN_MFG_ASYNC] = {
> > +		.name = "mfg_async",
> > +		.sta_mask = BIT(23),
> > +		.ctl_offs = 0x02c4,
> > +		.sram_pdn_bits = GENMASK(11, 8),
> > +		.sram_pdn_ack_bits = 0,
> > +		.clk_id = {CLK_MFG},
> > +	},
> > +	[MT8173_POWER_DOMAIN_MFG_2D] = {
> > +		.name = "mfg_2d",
> > +		.sta_mask = BIT(22),
> > +		.ctl_offs = 0x02c0,
> > +		.sram_pdn_bits = GENMASK(11, 8),
> > +		.sram_pdn_ack_bits = GENMASK(13, 12),
> > +		.clk_id = {CLK_NONE},
> > +	},
> > +	[MT8173_POWER_DOMAIN_MFG] = {
> > +		.name = "mfg",
> > +		.sta_mask = BIT(4),
> > +		.ctl_offs = 0x0214,
> > +		.sram_pdn_bits = GENMASK(13, 8),
> > +		.sram_pdn_ack_bits = GENMASK(21, 16),
> > +		.clk_id = {CLK_NONE},
> > +		.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MFG_S |
> > +			MT8173_TOP_AXI_PROT_EN_MFG_M0 |
> > +			MT8173_TOP_AXI_PROT_EN_MFG_M1 |
> > +			MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT,
> > +	},
> > +};
> > +
> > +#define NUM_DOMAINS_MT8173	ARRAY_SIZE(scp_domain_data_mt8173)
> > +
> > +static int __init scpsys_probe_mt8173(struct platform_device *pdev)
> > +{
> > +	struct scp *scp;
> > +	struct genpd_onecell_data *pd_data;
> > +	int ret;
> > +
> > +	scp = init_scp(pdev, scp_domain_data_mt8173, NUM_DOMAINS_MT8173);
> > +	if (IS_ERR(scp))
> > +		return PTR_ERR(scp);
> > +
> > +	mtk_register_power_domains(pdev, scp, NUM_DOMAINS_MT8173);
> > +
> > +	pd_data = &scp->pd_data;
> > +
> >   	ret = pm_genpd_add_subdomain(pd_data->domains[MT8173_POWER_DOMAIN_MFG_ASYNC],
> >   		pd_data->domains[MT8173_POWER_DOMAIN_MFG_2D]);
> >   	if (ret && IS_ENABLED(CONFIG_PM))
> > @@ -526,21 +523,36 @@ static int __init scpsys_probe(struct platform_device *pdev)
> >   	if (ret && IS_ENABLED(CONFIG_PM))
> >   		dev_err(&pdev->dev, "Failed to add subdomain: %d\n", ret);
> >
> > -	ret = of_genpd_add_provider_onecell(pdev->dev.of_node, pd_data);
> > -	if (ret)
> > -		dev_err(&pdev->dev, "Failed to add OF provider: %d\n", ret);
> > -
> >   	return 0;
> >   }
> >
> > +/*
> > + * scpsys driver init
> > + */
> > +
> >   static const struct of_device_id of_scpsys_match_tbl[] = {
> >   	{
> >   		.compatible = "mediatek,mt8173-scpsys",
> > +		.data = scpsys_probe_mt8173,
> >   	}, {
> >   		/* sentinel */
> >   	}
> >   };
> >
> > +static int __init scpsys_probe(struct platform_device *pdev)
> > +{
> > +	int (*probe)(struct platform_device *);
> > +	const struct of_device_id *of_id;
> > +
> > +	of_id = of_match_node(of_scpsys_match_tbl, pdev->dev.of_node);
> > +	if (!of_id || !of_id->data)
> > +		return -EINVAL;
> > +
> > +	probe = of_id->data;
> > +
> > +	return probe(pdev);
> > +}
> > +
> >   static struct platform_driver scpsys_drv = {
> >   	.driver = {
> >   		.name = "mtk-scpsys",
> > diff --git a/drivers/soc/mediatek/mtk-scpsys.h b/drivers/soc/mediatek/mtk-scpsys.h
> > new file mode 100644
> > index 0000000..e435bc3
> > --- /dev/null
> > +++ b/drivers/soc/mediatek/mtk-scpsys.h
> > @@ -0,0 +1,55 @@
> > +#ifndef __DRV_SOC_MTK_H
> > +#define __DRV_SOC_MTK_H
> > +
> > +enum clk_id {
> > +	CLK_NONE,
> > +	CLK_MM,
> > +	CLK_MFG,
> > +	CLK_VENC,
> > +	CLK_VENC_LT,
> > +	CLK_MAX,
> > +};
> > +
> > +#define MAX_CLKS	2
> > +
> > +struct scp_domain_data {
> > +	const char *name;
> > +	u32 sta_mask;
> > +	int ctl_offs;
> > +	u32 sram_pdn_bits;
> > +	u32 sram_pdn_ack_bits;
> > +	u32 bus_prot_mask;
> > +	enum clk_id clk_id[MAX_CLKS];
> > +	bool active_wakeup;
> > +};
> > +
> > +struct scp;
> > +
> > +struct scp_domain {
> > +	struct generic_pm_domain genpd;
> > +	struct scp *scp;
> > +	struct clk *clk[MAX_CLKS];
> > +	u32 sta_mask;
> > +	void __iomem *ctl_addr;
> > +	u32 sram_pdn_bits;
> > +	u32 sram_pdn_ack_bits;
> > +	u32 bus_prot_mask;
> > +	bool active_wakeup;
> > +	struct regulator *supply;
> > +};
> > +
> > +struct scp {
> > +	struct scp_domain *domains;
> > +	struct genpd_onecell_data pd_data;
> > +	struct device *dev;
> > +	void __iomem *base;
> > +	struct regmap *infracfg;
> > +};
> > +
> > +struct scp *init_scp(struct platform_device *pdev,
> > +			const struct scp_domain_data *scp_domain_data, int num);
> > +
> > +void mtk_register_power_domains(struct platform_device *pdev,
> > +				struct scp *scp, int num);
> > +
> > +#endif /* __DRV_SOC_MTK_H */
> >




From shawnguo at kernel.org  Mon Feb  1 23:01:33 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 2 Feb 2016 15:01:33 +0800
Subject: [PATCH 0/4] ARM: dts: imx53: update Ka-Ro electronics TX53
 module support
In-Reply-To: <1453295362-18798-1-git-send-email-LW@KARO-electronics.de>
References: <1453295362-18798-1-git-send-email-LW@KARO-electronics.de>
Message-ID: <20160202070133.GI8307@tiger>

On Wed, Jan 20, 2016 at 02:09:18PM +0100, Lothar Wa?mann wrote:
> ARM: dts: imx53: fix LVDS data-mapping and data-width
> ARM: dts: imx53: add display timing for NL12880BC20
> ARM: dts: imx53-tx53: set correct mclk frequency

Applied these 3, thanks.


From djkurtz at chromium.org  Mon Feb  1 23:04:56 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Tue, 2 Feb 2016 15:04:56 +0800
Subject: [PATCH] iommu/dma: Map scatterlists more parsimoniously
In-Reply-To: <CAGS+omBWFgpQQKV2=qL9G6qPbW_EL2bSjkLPq6KwQGAdHEDSHw@mail.gmail.com>
References: <104b4682056bc5b4aa0afadd39196c03fc06555d.1447249098.git.robin.murphy@arm.com>
 <1447307229.27650.5.camel@mhfsdcap03>
 <CAGS+omBWFgpQQKV2=qL9G6qPbW_EL2bSjkLPq6KwQGAdHEDSHw@mail.gmail.com>
Message-ID: <CAGS+omDhZPxQvyVE6DgcRXJach2euWsxPxUZPJMgyPYsyMwcfA@mail.gmail.com>

On Thu, Dec 10, 2015 at 8:49 PM, Daniel Kurtz <djkurtz at chromium.org> wrote:
> On Thu, Nov 12, 2015 at 1:47 PM, Yong Wu <yong.wu at mediatek.com> wrote:
>> On Wed, 2015-11-11 at 14:54 +0000, Robin Murphy wrote:
>>> Whilst blindly assuming the worst case for segment boundaries and
>>> aligning every segment individually is safe from the point of view
>>> of respecting the device's parameters, it is also undeniably a waste
>>> of IOVA space. Futhermore, the knock-on effects of more pages than
>
> "Furthermore" (checkpatch actually caught this, not me ;-) )
>
>>> necessary being exposed to device access, additional overhead in page
>>> table updates and TLB invalidations, etc., are even more undesirable.
>>>
>>> Improve matters by taking the actual boundary mask into account to
>>> actively detect the cases in which we really do need to adjust a
>>> segment, and avoid wasting space in the remainder.
>>>
>>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>>> ---
>>>
>>> Hi all,
>>>
>>> I've given this some brief testing on Juno with USB and (via magic
>>> PCI hacks) SATA to confirm that all the +1s and -1s at least seem to
>>> be in the right places, so I'm throwing it out now for a head-start on
>>> checking whether it also helps the media folks with the v4l portability
>>> issues they're up against (I'm confident it should). If all goes well I
>>> figure I'll repost next week based on rc1 instead of some random local
>>> development commit.
>>>
>>> Robin.
>>
>> It works well on MT8173. containing
>> VDA/VEA(VideoDecodeAccelerator/VideoEncodeAccelerator) unit test.
>>
>> Tested-by: Yong Wu <yong.wu at mediatek.com>
>
> Reviewed-by: Daniel Kurtz <djkurtz at chromium.org>


Did this patch get lost?
Can we pick it up as a fix for v4.5?


From k.kozlowski at samsung.com  Mon Feb  1 23:06:17 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 02 Feb 2016 16:06:17 +0900
Subject: [PATCH] drivers: soc: samsung: Enable COMPILE_TEST
Message-ID: <1454396777-20034-1-git-send-email-k.kozlowski@samsung.com>

Get some build coverage of Exynos SROM controller and PMU drivers. The
PMU driver depends on asm/cputype.h so its compilation is limited to ARM
architectures.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>

---
The SROM driver was compile-tested on x86, x86_64, ppc64, arm, arm64 and
mips. The PMU driver on arm and arm64.
---
 drivers/soc/samsung/Kconfig | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 895f16934b75..e5c11ac88a38 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -1,17 +1,17 @@
 #
 # SAMSUNG SoC drivers
 #
-menu "Samsung SOC driver support"
+menuconfig SOC_SAMSUNG
+	bool "Samsung SoC driver support" if COMPILE_TEST
 
-config SOC_SAMSUNG
-	bool
+if SOC_SAMSUNG
 
 config EXYNOS_SROM
-	bool
-	depends on ARM && ARCH_EXYNOS
+	bool "Exynos SROM controller driver" if COMPILE_TEST
+	depends on (ARM && ARCH_EXYNOS) || COMPILE_TEST
 
 config EXYNOS_PMU
-	bool
-	depends on ARM && ARCH_EXYNOS
+	bool "Exynos PMU controller driver" if COMPILE_TEST
+	depends on (ARM && ARCH_EXYNOS) || ((ARM || ARM64) && COMPILE_TEST)
 
-endmenu
+endif
-- 
1.9.1



From jamesjj.liao at mediatek.com  Mon Feb  1 23:24:41 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Tue, 2 Feb 2016 15:24:41 +0800
Subject: [PATCH v5 5/6] reset: mediatek: Add MT2701 reset controller
 dt-binding file
In-Reply-To: <1454317018.3447.3.camel@pengutronix.de>
References: <1453879264-37915-1-git-send-email-jamesjj.liao@mediatek.com>
 <1453879264-37915-6-git-send-email-jamesjj.liao@mediatek.com>
 <1454317018.3447.3.camel@pengutronix.de>
Message-ID: <1454397881.2847.16.camel@mtksdaap41>

Hi Philipp,

On Mon, 2016-02-01 at 09:56 +0100, Philipp Zabel wrote:
> Am Mittwoch, den 27.01.2016, 15:21 +0800 schrieb James Liao:
> > From: Shunli Wang <shunli.wang at mediatek.com>
> > 
> > Dt-binding file about reset controller is used to provide
> > kinds of definition, which is referenced by dts file and
> > IC-specified reset controller driver code.
> > 
> > Signed-off-by: Shunli Wang <shunli.wang at mediatek.com>
> > Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
> > Tested-by: John Crispin <blogic at openwrt.org>
> 
> In case you missed my Acked-by for patches 5 and 6, it still stands.

I'll add it in next version of patch, thanks.


Best regards,

James




From andy.yan at rock-chips.com  Mon Feb  1 23:31:17 2016
From: andy.yan at rock-chips.com (Andy Yan)
Date: Tue, 2 Feb 2016 15:31:17 +0800
Subject: [PATCH v2 2/4] power: reset: add reboot mode driver
In-Reply-To: <CAAtXAHd-m5GAUnvx9At9_UOoi1M4g25P0M-vwoC+Xc-PXtdwqw@mail.gmail.com>
References: <1452598029-8222-1-git-send-email-andy.yan@rock-chips.com>
 <1452598319-8324-1-git-send-email-andy.yan@rock-chips.com>
 <CAAtXAHd-m5GAUnvx9At9_UOoi1M4g25P0M-vwoC+Xc-PXtdwqw@mail.gmail.com>
Message-ID: <56B05B45.7040207@rock-chips.com>

Hi Moritz:

On 2016?01?27? 18:53, Moritz Fischer wrote:
> Hi Andy,
>
> On Tue, Jan 12, 2016 at 12:31 PM, Andy Yan <andy.yan at rock-chips.com> wrote:
>> This driver parse the reboot commands like "reboot loader"
>> and "reboot recovery" to get a boot mode described in the
>> device tree , then call the write interfae to store the boot
>> mode in some persistent storage  like special register or ram,
>> which can be read by the bootloader after system reboot, then
>> the bootloader can take different action according to the mode
>> stored.
>>
>> This is commonly used on Android based devices, which in order
>> to reboot the device into fastboot or recovery mode.
>>
>> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
>>
>> ---
>>
>> Changes in v2:
>> - move to dir drivers/power/reset/
>> - make syscon-reboot-mode a generic driver
>>
>> Changes in v1:
>> - fix the embarrassed compile warning
>> - correct the maskrom magic number
>> - check for the normal reboot
>>
>>   drivers/power/reset/Kconfig              |  16 +++++
>>   drivers/power/reset/Makefile             |   2 +
>>   drivers/power/reset/reboot-mode.c        | 100 +++++++++++++++++++++++++++++++
>>   drivers/power/reset/reboot-mode.h        |   6 ++
>>   drivers/power/reset/syscon-reboot-mode.c |  62 +++++++++++++++++++
>>   5 files changed, 186 insertions(+)
>>   create mode 100644 drivers/power/reset/reboot-mode.c
>>   create mode 100644 drivers/power/reset/reboot-mode.h
>>   create mode 100644 drivers/power/reset/syscon-reboot-mode.c
>>
>> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
>> index 1131cf7..2e6d873 100644
>> --- a/drivers/power/reset/Kconfig
>> +++ b/drivers/power/reset/Kconfig
>> @@ -173,5 +173,21 @@ config POWER_RESET_ZX
>>          help
>>            Reboot support for ZTE SoCs.
>>
>> +config REBOOT_MODE
>> +       tristate
>> +       depends on OF
>> +       help
>> +        This driver will help to pass the system reboot mode
>> +        to bootloader
>> +
>> +config SYSCON_REBOOT_MODE
>> +       bool "Generic SYSCON regmap reboot mode driver"
>> +       select REBOOT_MODE
>> +       help
>> +        Say y here will enable reboot mode driver. This will
>> +        get reboot mode arguments and store it in SYSCON mapped
>> +        register, then the bootloader can read it to take different
>> +        action according to the mode.
>> +
>>   endif
>>
>> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
>> index 096fa67..a63865b 100644
>> --- a/drivers/power/reset/Makefile
>> +++ b/drivers/power/reset/Makefile
>> @@ -20,3 +20,5 @@ obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
>>   obj-$(CONFIG_POWER_RESET_SYSCON_POWEROFF) += syscon-poweroff.o
>>   obj-$(CONFIG_POWER_RESET_RMOBILE) += rmobile-reset.o
>>   obj-$(CONFIG_POWER_RESET_ZX) += zx-reboot.o
>> +obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
>> +obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
>> diff --git a/drivers/power/reset/reboot-mode.c b/drivers/power/reset/reboot-mode.c
>> new file mode 100644
>> index 0000000..92b7b4d
>> --- /dev/null
>> +++ b/drivers/power/reset/reboot-mode.c
>> @@ -0,0 +1,100 @@
>> +/*
>> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +#include <linux/device.h>
>> +#include <linux/init.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/reboot.h>
>> +#include "reboot-mode.h"
>> +
>> +struct mode_info {
>> +       const char *mode;
>> +       int magic;
>> +       struct list_head list;
>> +};
>> +
>> +struct reboot_mode_driver {
>> +       struct list_head head;
>> +       int (*write)(int magic);
>> +       struct notifier_block reboot_notifier;
>> +};
>> +
>> +static int get_reboot_mode_magic(struct reboot_mode_driver *reboot,
>> +                                const char *cmd)
>> +{
>> +       const char *normal = "normal";
>> +       int magic = 0;
>> +       struct mode_info *info;
>> +
>> +       if (!cmd)
>> +               cmd = normal;
>> +
>> +       list_for_each_entry(info, &reboot->head, list) {
>> +               if (!strcmp(info->mode, cmd)) {
>> +                       magic = info->magic;
>> +                       break;
>> +               }
>> +       }
>> +
>> +       return magic;
>> +}
>> +
>> +static int reboot_mode_notify(struct notifier_block *this,
>> +                             unsigned long mode, void *cmd)
>> +{
>> +       struct reboot_mode_driver *reboot;
>> +       int magic;
>> +
>> +       reboot = container_of(this, struct reboot_mode_driver, reboot_notifier);
>> +       magic = get_reboot_mode_magic(reboot, cmd);
>> +       if (magic)
>> +               reboot->write(magic);
>> +
>> +       return NOTIFY_DONE;
>> +}
>> +
>> +int reboot_mode_register(struct device *dev, int (*write)(int))
>> +{
>> +       struct reboot_mode_driver *reboot;
>> +       struct mode_info *info;
>> +       struct device_node *child;
>> +       int ret;
>> +
>> +       reboot = devm_kzalloc(dev, sizeof(*reboot), GFP_KERNEL);
>> +       if (!reboot)
>> +               return -ENOMEM;
>> +
>> +       reboot->write = write;
>> +       INIT_LIST_HEAD(&reboot->head);
>> +       for_each_child_of_node(dev->of_node, child) {
>> +               info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
>> +               if (!info)
>> +                       return -ENOMEM;
>> +               info->mode = of_get_property(child, "linux,mode", NULL);
>> +               if (of_property_read_u32(child, "loader,magic", &info->magic)) {
>> +                       dev_err(dev, "reboot mode %s without magic number\n",
>> +                               info->mode);
>> +                       devm_kfree(dev, info);
>> +                       continue;
>> +               }
>> +               list_add_tail(&info->list, &reboot->head);
>> +       }
>> +       reboot->reboot_notifier.notifier_call = reboot_mode_notify;
>> +       ret = register_reboot_notifier(&reboot->reboot_notifier);
>> +       if (ret)
>> +               dev_err(dev, "can't register reboot notifier\n");
>> +
>> +       return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(reboot_mode_register);
>> +
>> +MODULE_AUTHOR("Andy Yan <andy.yan at rock-chips.com");
>> +MODULE_DESCRIPTION("System reboot mode driver");
>> +MODULE_LICENSE("GPL v2");
>> diff --git a/drivers/power/reset/reboot-mode.h b/drivers/power/reset/reboot-mode.h
>> new file mode 100644
>> index 0000000..76646e7
>> --- /dev/null
>> +++ b/drivers/power/reset/reboot-mode.h
>> @@ -0,0 +1,6 @@
>> +#ifndef __REBOOT_MODE_H__
>> +#define __REBOOT_MODE_H__
>> +
>> +extern int reboot_mode_register(struct device *dev, int (*write)(int));
>> +
>> +#endif
>> diff --git a/drivers/power/reset/syscon-reboot-mode.c b/drivers/power/reset/syscon-reboot-mode.c
>> new file mode 100644
>> index 0000000..b9370f3
>> --- /dev/null
>> +++ b/drivers/power/reset/syscon-reboot-mode.c
>> @@ -0,0 +1,62 @@
>> +/*
>> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +#include <linux/init.h>
>> +#include <linux/module.h>
>> +#include <linux/kernel.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/reboot.h>
>> +#include <linux/regmap.h>
>> +#include <linux/mfd/syscon.h>
>> +#include "reboot-mode.h"
>> +
>> +static struct regmap *map;
>> +static u32 offset;
>> +
>> +static int syscon_reboot_mode_write(int magic)
>> +{
>> +       regmap_write(map, offset, magic);
> See suggestion below. I think using regmap_update_bits() would be even
> more useful for cases where you have other stuff in that register, too.
>
>> +
>> +       return 0;
>> +}
>> +
>> +static int syscon_reboot_mode_probe(struct platform_device *pdev)
>> +{
>> +       int ret;
>> +
>> +       map = syscon_node_to_regmap(pdev->dev.parent->of_node);
>> +       if (IS_ERR(map))
>> +               return PTR_ERR(map);
>> +       if (of_property_read_u32(pdev->dev.of_node, "offset", &offset))
>> +               return -EINVAL;
> I think it would be worthwhile to have a mask value here, that you can use
> with regmap_update_bits()

     That sounds reasonable,  I already fond some drivers like tegra[0]
     only use some bits to store the mode value. So I will add it in V3.

    [0] drivers/soc/tegra/pmc.c
>
> +           if (of_property_read_u32(pdev->dev.of_node, "mask", &mask))
> +                   return -EINVAL;
>
>
> Cheers,
>
> Moritz
>
>
>




From wens at csie.org  Mon Feb  1 23:31:35 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue, 2 Feb 2016 15:31:35 +0800
Subject: [PATCH 13/14] ARM: dts: sun8i: enable mmc for H8Homlet Board.
In-Reply-To: <1454203266-4450-14-git-send-email-vishnupatekar0510@gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-14-git-send-email-vishnupatekar0510@gmail.com>
Message-ID: <CAGb2v66hgkxNVywB9n8UEcnhVB_=_rWUv4G8bw6k50hAUucZ4w@mail.gmail.com>

Hi,

On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
<vishnupatekar0510 at gmail.com> wrote:
> This enables mmc0.
>
> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
> Tested-by: LABBE Corentin <clabbe.montjoie at gmail.com>
> ---
>  .../boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts    | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts b/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
> index 342e1d3..6c1f598 100644
> --- a/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
> +++ b/arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts
> @@ -43,6 +43,7 @@
>
>  /dts-v1/;
>  #include "sun8i-a83t.dtsi"
> +#include "sunxi-common-regulators.dtsi"
>
>  / {
>         model = "Allwinner A83T H8Homlet Proto Dev Board v2.0";
> @@ -57,6 +58,25 @@
>         };
>  };
>
> +&pio {
> +       mmc0_cd_pin_h8homlet: mmc0_cd_pin at 0 {
> +               allwinner,pins = "PF6";
> +               allwinner,function = "gpio_in";
> +               allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +               allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> +       };
> +};
> +

Please keep them alphabetically sorted.

> +&mmc0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_h8homlet>;
> +       vmmc-supply = <&reg_vcc3v0>;

The board design says 3.3V, but stock firmware uses 3.0V. I guess both work.

> +       cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> +       bus-width = <4>;
> +       cd-inverted;
> +       status = "okay";
> +};
> +

There's also eMMC onboard. Have you tried that?


Thanks!
ChenYu


>  &uart0 {
>         pinctrl-names = "default";
>         pinctrl-0 = <&uart0_pins_b>;
> --
> 1.9.1
>


From shawnguo at kernel.org  Mon Feb  1 23:34:47 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 2 Feb 2016 15:34:47 +0800
Subject: [PATCH 3/3] ARM: dts: imx6*-hummingboard: fix pcie reset GPIO
 specification
In-Reply-To: <CAOMZO5Ciq-kq4xQm4TH+dF3cdYxFfWUmvuykvorZ-oaEoyBWFQ@mail.gmail.com>
References: <E1aOWdF-00058a-0X@rmk-PC.arm.linux.org.uk>
 <CAOMZO5Ciq-kq4xQm4TH+dF3cdYxFfWUmvuykvorZ-oaEoyBWFQ@mail.gmail.com>
Message-ID: <20160202073446.GJ8307@tiger>

On Wed, Jan 27, 2016 at 07:07:38PM -0200, Fabio Estevam wrote:
> On Wed, Jan 27, 2016 at 6:24 PM, Russell King
> <rmk+kernel at arm.linux.org.uk> wrote:
> > PCIe reset signals are active low, and our GPIO for this is directly
> > connected to the PCIe reset.  However, as the PCIe driver does not use
> > the flag, the specification of '0' flags (which means active high) has
> > not been noticed.  Correct this oversight, and switch to using the
> 
> Yes, the mx6 pci driver did not use the flag, but it does now since 5c5fb40de8f1
> ("PCI: imx6: Add support for active-low reset GPIO"), so it would be
> better to adjust the commit log.

I updated the commit log a bit and applied the series.

Shawn


From wens at csie.org  Mon Feb  1 23:37:22 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue, 2 Feb 2016 15:37:22 +0800
Subject: [PATCH 14/14] ARM: dts: sun8i: Add A83T based Sinovoip Bpi-M3
 Board
In-Reply-To: <1454203266-4450-15-git-send-email-vishnupatekar0510@gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-15-git-send-email-vishnupatekar0510@gmail.com>
Message-ID: <CAGb2v65BwAcT8920WXt7dBjNx4zjycw2Ea+sNZrm0aM_3JA8pA@mail.gmail.com>

On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
<vishnupatekar0510 at gmail.com> wrote:
> This patch adds support for Sinovoip BPI-M3 A83T based board.
>
> It has 2G LPDDR3, UART, ethernet, USB, HDMI, USB Sata, MIPI DSI,
> mic, AP6212 Wifi, etc on it.
> It is paired with AXP813 PMIC which is almost same as AXP818.
>
> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
> ---
>  arch/arm/boot/dts/Makefile                       |  1 +
>  arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts | 88 ++++++++++++++++++++++++
>  2 files changed, 89 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 58e461a..c0dd016 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -694,6 +694,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>         sun8i-a33-sinlinx-sina33.dtb \
>         sun8i-a83t-allwinner-h8homlet-v2.dtb \
>         sun8i-a83t-cubietruck-plus.dtb \
> +       sun8i-a83t-sinovoip-bpi-m3.dtb \
>         sun8i-h3-orangepi-plus.dtb
>  dtb-$(CONFIG_MACH_SUN9I) += \
>         sun9i-a80-optimus.dtb \
> diff --git a/arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts
> new file mode 100644
> index 0000000..fecc7dc
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts
> @@ -0,0 +1,88 @@
> +/*
> + * Copyright 2015 Vishnu Patekar

2016?

> + * Vishnu Patekar <vishnupatekar0510 at gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This file is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun8i-a83t.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +/ {
> +       model = "Sinovoip BananaPi M3 v1.2";
> +       compatible = "sinovoip,bpi-m3", "allwinner,sun8i-a83t";
> +
> +       aliases {
> +               serial0 = &uart0;
> +       };
> +
> +       chosen {
> +               stdout-path = "serial0:115200n8";
> +       };
> +};
> +
> +&pio {
> +       mmc0_cd_pin_bpi_m3: mmc0_cd_pin at 0 {
> +               allwinner,pins = "PF6";
> +               allwinner,function = "gpio_in";
> +               allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +               allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> +       };

Maybe we should just put this in the .dtsi and call it
"mmc0_cd_pin_reference_design"?

We have something similar for sun4i-a10.

> +};
> +
> +&mmc0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_bpi_m3>;
> +       vmmc-supply = <&reg_vcc3v0>;
> +       cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> +       bus-width = <4>;
> +       cd-inverted;
> +       status = "okay";
> +};
> +
> +&uart0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&uart0_pins_b>;
> +       status = "okay";
> +};
> +
> +&r_rsb {

This goes before uart0.

> +       status = "okay";
> +};

What about eMMC?


Thanks!
ChenYu


From heiko.carstens at de.ibm.com  Mon Feb  1 23:39:13 2016
From: heiko.carstens at de.ibm.com (Heiko Carstens)
Date: Tue, 2 Feb 2016 08:39:13 +0100
Subject: [PATCH 1/5] all: s390: move wrapper infrastructure to generic
 headers
In-Reply-To: <20160201114251.GB973@yury-N73SV>
References: <1453741047-5498-1-git-send-email-ynorov@caviumnetworks.com>
 <1453741047-5498-2-git-send-email-ynorov@caviumnetworks.com>
 <20160128121618.GB5418@osiris> <20160128163109.GA8529@yury-N73SV>
 <20160201114251.GB973@yury-N73SV>
Message-ID: <20160202073913.GB3990@osiris>

On Mon, Feb 01, 2016 at 02:42:51PM +0300, Yury Norov wrote:
> Hi Heiko,
> 
> I tried this idea, and I don't like what happened.
>  - Wrappers around safe syscalls does exist. We can remove it by
>    overcomplicating __SC_COMPAT_CAST, but I don't like it.
>  - We still need to declare numerous list of new compat syscalls.
>    And it becomes even bigger, as we need to declare all compat
>    syscall versions not declared in include/linux/compat.h already.
>    (Currently - only for unsafe syscalls.)
>  - 'Weak' trick doesn't work for the whole kernel, so we'd figure out
>    some new prefix for wrapped syscalls. Or declare all non-compat
>    syscalls explicitly with SYSCALL_COMPAT_DEFINE. So the list of
>    replacements grow. And for me, it's harder to explain why we are
>    wrapping safe syscalls. Or we introduce another bunch of useless
>    wrappers (with new prefix), and have to handle it in non-compat code.
>  - With all listed above, we move all wrapper logic to non-compat
>    'include/linux/syscalls.h' header. Which is not a good idea, if it
>    doesn't benefit us much in return.
> 
> > > No need to look up if a compat variant (or wrapper) exists or
> > > sys_<syscallname> should be used instead. Also no possibility for security
> > > bugs that could creep in because SYSCALL_DEFINE has been used instead of
> > > SYSCALL_DEFINE_WRAP.
> 
> I thought again about it. With current version, it's very easy to
> define whether we have wrapper or not - just by macro we use. Once
> reviewed, this list is hardly to be changed frequently. If someone is
> introducing new syscall, it will attract much attention, so security
> risk is minimal.
> 
> Maybe I missed some elegant implementation, and if so  I'll be happy
> if someone'll point me out. But with what I see, I'd vote for what we
> have now. (Plus description in docs, plus renaming new macro.)

Well, I'd like to have some proof by the compiler or linker that nothing
went wrong. Which seems hard if only selected system call defines will be
converted to the new defines.

How can you tell that nothing has been forgotten?

Also, what happens if the prototype of a system call get's changed shortly
after it was merged. We might miss such changes and have bugs.

Therefore, and to get to a solution, I think we should stick with your
first idea, which only moves the compat_wrapper.c file.

Before doing that I think you should actually revert this patch: my commit
7681df456f97 ("s390/compat: remove superfluous compat wrappers") probably
wasn't a very bright idea :)

This again allows me to use only compat system calls in s390's system call
table (execpt for system calls without parameters, but that can be easily
fixed).

What I still don't like is that you need to add all the protoypes. Why are
the system call tables actually written in C and not in asm?



From shawnguo at kernel.org  Mon Feb  1 23:49:07 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 2 Feb 2016 15:49:07 +0800
Subject: [PATCH] dts/ls1021a: add the DTS for QSPI support
In-Reply-To: <1453970006-46509-1-git-send-email-yao.yuan@freescale.com>
References: <1453970006-46509-1-git-send-email-yao.yuan@freescale.com>
Message-ID: <20160202074907.GK8307@tiger>

On Thu, Jan 28, 2016 at 04:33:26PM +0800, Yuan Yao wrote:
> From: Yuan Yao <yao.yuan at nxp.com>
> 
> Signed-off-by: Yuan Yao <yao.yuan at nxp.com>
> ---
> Add in v1:
> Can merge, but the function depend on the patch:
> https://patchwork.kernel.org/patch/8118251/

Please send me dts patch only after the driver part gets applied.

> 
> mtd: spi-nor: fsl-quadspi: add support for ls1021a
> 
> LS1021a also support Freescale Quad SPI controller.
> Add fsl-quadspi support for ls1021a chip and make SPI_FSL_QUADSPI
> selectable for LS1021A SOC hardwares.
> 
> ---
>  arch/arm/boot/dts/ls1021a.dtsi | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 9430a99..c764fa5 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -252,6 +252,21 @@
>  			status = "disabled";
>  		};
>  
> +		qspi: quadspi at 1550000 {
> +			compatible = "fsl,ls1021a-qspi";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x0 0x1550000 0x0 0x10000>,
> +				<0x0 0x40000000 0x0 0x4000000>;
> +			reg-names = "QuadSPI", "QuadSPI-memory";
> +			interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
> +			clock-names = "qspi_en", "qspi";
> +			clocks = <&platform_clk 1>, <&platform_clk 1>;
> +			big-endian;
> +			amba-base = <0x40000000>;

What is this property?  I cannot find it in any bindings doc.  Is it
added by your patches on driver code?

Shawn

> +			status = "disabled";
> +		};
> +
>  		i2c0: i2c at 2180000 {
>  			compatible = "fsl,vf610-i2c";
>  			#address-cells = <1>;
> -- 
> 2.1.0.27.g96db324
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From lists.nick.betteridge at gmail.com  Mon Feb  1 23:57:46 2016
From: lists.nick.betteridge at gmail.com (lists.nick.betteridge at gmail.com)
Date: Mon, 1 Feb 2016 23:57:46 -0800 (PST)
Subject: [PATCH 00/11] arm64: Introduce Allwinner A64 and Pine64 support
In-Reply-To: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
Message-ID: <b1250d48-a7a1-4f7f-893b-9abe3c91724e@googlegroups.com>

Just a quick question - will there be any support for enabling booting into virtualisation mode to run xen and the like?

Cheers
Nick

From mathias.nyman at linux.intel.com  Tue Feb  2 00:06:30 2016
From: mathias.nyman at linux.intel.com (Mathias Nyman)
Date: Tue, 02 Feb 2016 10:06:30 +0200
Subject: [PATCH] usb: xhci: fix build error for USB_SPEED_SUPER_PLUS
In-Reply-To: <1508874.HIZbDSzAVR@wuerfel>
References: <1508874.HIZbDSzAVR@wuerfel>
Message-ID: <56B06386.6030002@linux.intel.com>

On 01.02.2016 18:18, Arnd Bergmann wrote:
> A recent patch introduced support for superspeed plus (USB3.1), but that
> caused a new gcc warning in the XHCI code:
>
> usb/host/xhci.c: In function 'xhci_drop_ep_from_interval_table':
> usb/host/xhci.c:2440:2: error: enumeration value 'USB_SPEED_SUPER_PLUS' not handled in switch [-Werror=switch]
>
> This changes the XHCI driver to handle USB_SPEED_SUPER_PLUS the
> same way as USB_SPEED_SUPER in the xhci_drop_ep_from_interval_table
> and xhci_add_ep_to_interval_table functions, explicitly ignoring
> it.
>

The original series that added USB_SPEED_SUPER_PLUS to both core and xhci was only partly accepted.
The core part was applied, the rest was asked to  be resubmitted.

Second part is still waiting to be applied.

http://www.spinics.net/lists/linux-usb/msg135493.html

-Mathias



From shawnguo at kernel.org  Tue Feb  2 00:06:21 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 2 Feb 2016 16:06:21 +0800
Subject: [PATCH] ARM: dts: vf610: Add alias for ethernet controller
In-Reply-To: <1454112288-7490-1-git-send-email-stefan@agner.ch>
References: <1454112288-7490-1-git-send-email-stefan@agner.ch>
Message-ID: <20160202080621.GL8307@tiger>

On Fri, Jan 29, 2016 at 04:04:48PM -0800, Stefan Agner wrote:
> Add alias for FEC ethernet on Vybrid to allow bootloaders (like U-Boot)
> patch-in the MAC address using this alias.
> 
> Signed-off-by: Stefan Agner <stefan at agner.ch>

Applied, thanks.


From jamesjj.liao at mediatek.com  Tue Feb  2 00:07:07 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Tue, 2 Feb 2016 16:07:07 +0800
Subject: [PATCH v4 2/6] dt-bindings: ARM: Mediatek: Document bindings
 for MT2701
In-Reply-To: <CAL_JsqLJVLDbPqynmD9-Yc=JVGH4iLPfb2keA5G7c2fjitAsSQ@mail.gmail.com>
References: <1453271747-57397-1-git-send-email-jamesjj.liao@mediatek.com>
 <1453271747-57397-3-git-send-email-jamesjj.liao@mediatek.com>
 <20160120163236.GA21035@rob-hp-laptop>
 <1453353537.5384.33.camel@mtksdaap41>
 <CAL_JsqLJVLDbPqynmD9-Yc=JVGH4iLPfb2keA5G7c2fjitAsSQ@mail.gmail.com>
Message-ID: <1454400427.2847.41.camel@mtksdaap41>

Hi Rob,

On Mon, 2016-02-01 at 09:55 -0600, Rob Herring wrote:
> On Wed, Jan 20, 2016 at 11:18 PM, James Liao <jamesjj.liao at mediatek.com> wrote:
> > On Wed, 2016-01-20 at 10:32 -0600, Rob Herring wrote:
> >> On Wed, Jan 20, 2016 at 02:35:43PM +0800, James Liao wrote:
> >> > This patch adds the binding documentation for apmixedsys, bdpsys,
> >> > ethsys, hifsys, imgsys, infracfg, mmsys, pericfg, topckgen and
> >> > vdecsys for Mediatek MT2701.
> >> >
> >> > Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
> >> > Tested-by: John Crispin <blogic at openwrt.org>
> >> > ---
> >> >  .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |  1 +
> >> >  .../bindings/arm/mediatek/mediatek,bdpsys.txt      | 22 ++++++++++++++++++++++
> >> >  .../bindings/arm/mediatek/mediatek,ethsys.txt      | 22 ++++++++++++++++++++++
> >> >  .../bindings/arm/mediatek/mediatek,hifsys.txt      | 22 ++++++++++++++++++++++
> >> >  .../bindings/arm/mediatek/mediatek,imgsys.txt      |  1 +
> >> >  .../bindings/arm/mediatek/mediatek,infracfg.txt    |  1 +
> >> >  .../bindings/arm/mediatek/mediatek,mmsys.txt       |  1 +
> >> >  .../bindings/arm/mediatek/mediatek,pericfg.txt     |  1 +
> >> >  .../bindings/arm/mediatek/mediatek,topckgen.txt    |  1 +
> >> >  .../bindings/arm/mediatek/mediatek,vdecsys.txt     |  1 +
> >> >  10 files changed, 73 insertions(+)
> >> >  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
> >> >  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> >> >  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
> >> > index 936166f..a701e19 100644
> >> > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
> >> > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
> >> > @@ -6,6 +6,7 @@ The Mediatek apmixedsys controller provides the PLLs to the system.
> >> >  Required Properties:
> >> >
> >> >  - compatible: Should be:
> >> > +   - "mediatek,mt2701-apmixedsys"
> >> >     - "mediatek,mt8135-apmixedsys"
> >> >     - "mediatek,mt8173-apmixedsys"
> >> >  - #clock-cells: Must be 1
> >> > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
> >> > new file mode 100644
> >> > index 0000000..4137196
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
> >> > @@ -0,0 +1,22 @@
> >> > +Mediatek bdpsys controller
> >> > +============================
> >> > +
> >> > +The Mediatek bdpsys controller provides various clocks to the system.
> >>
> >> As you clarified these blocks provide more that just clocks. Please list
> >> all the functions here and on the others.
> >
> > Some blocks may provide clock and reset controller at the same time. But
> 
> Then say the block provides clocks and resets is all I'm asking for.

infracfg and pericfg had mentioned they would provide clock and reset
controllers. I'll add the same description into hifsys.

> > most of them will not provide functions directly. Instead, some DT
> > blocks which provide specific functions may refer to these controller
> > nodes due to it need to access the same register space.
> >
> > For example, scpsys (the power domain provider) refers to infracfg
> > because it need to control infracfg registers when power on/off domains:
> >
> >         scpsys: scpsys at 10006000 {
> >                 compatible = "mediatek,mt2701-scpsys";
> >                 #power-domain-cells = <1>;
> >                 reg = <0 0x10006000 0 0x1000>;
> >                 infracfg = <&infracfg>;
> >         };
> >
> > So I think it should not need to list all functions for each blocks
> > here.
> 
> Sorry, but you do need to describe what functions the blocks provide.

infracfg for example, this DT node provides only clock and reset
controllers.

	infracfg: power-controller at 10001000 {
		compatible = "mediatek,mt2701-infracfg", "syscon";
		reg = <0 0x10001000 0 0x1000>;
		#clock-cells = <1>;
		#reset-cells = <1>;
	};

It mapped register space 0x10001000 ~ 0x10001fff. The clock and reset
controllers only use partial registers in this space. Some other
functions, such as bus protection and DCM, use registers in 0x10001000 ~
0x10001fff. But these functions are not provided by this node. Instead,
these function may be implemented by other nodes, such as scpsys. That's
why we only list clock and reset controllers in infracfg document.

> Also, if you are accessing the infracfg regs directly to modify clock
> registers outside of the clock driver, that is very bad design. The
> clock driver could assume that register values are not changing behind
> its back and it bypasses any locks around register accesses. I can see
> why it is needed though, but we really need a proper interface.

No, we won't modify clock registers directly outside of clock driver.
All drivers that need to control clocks must use standard CCF APIs to
lookup and operate clocks.

Scpsys for example, it need to enable/disable clocks and bus protections
when power domain on/off. Scpsys will control clocks through CCF, and
control bus protections through regmap to access infracfg's registers.
Of course, the registers of clocks and bus protection are different.

	scpsys: scpsys at 10006000 {
		compatible = "mediatek,mt8173-scpsys";
		#power-domain-cells = <1>;
		reg = <0 0x10006000 0 0x1000>;
		clocks = <&clk26m>,
			 <&topckgen CLK_TOP_MM_SEL>,
			 <&topckgen CLK_TOP_VENC_SEL>,
			 <&topckgen CLK_TOP_VENC_LT_SEL>;
		clock-names = "mfg", "mm", "venc", "venc_lt";
		infracfg = <&infracfg>;
	};

Here is MT8173's scpsys DT node. And you can see it refers clocks
provided by topckeng, and infracfg register space.


Best regards,

James




From shawnguo at kernel.org  Tue Feb  2 00:11:33 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 2 Feb 2016 16:11:33 +0800
Subject: [PATCH] ARM: dts: imx6qdl-udoo: add sound support
In-Reply-To: <56AD4A6B.80409@maciej.szmigiero.name>
References: <56AD4A6B.80409@maciej.szmigiero.name>
Message-ID: <20160202081133.GM8307@tiger>

On Sun, Jan 31, 2016 at 12:42:35AM +0100, Maciej S. Szmigiero wrote:
> Add sound support in UDOO board DT file.
> 
> Signed-off-by: Maciej S. Szmigiero <mail at maciej.szmigiero.name>

Applied, thanks. 


From andre.przywara at arm.com  Tue Feb  2 00:12:50 2016
From: andre.przywara at arm.com (=?UTF-8?Q?Andr=c3=a9_Przywara?=)
Date: Tue, 2 Feb 2016 08:12:50 +0000
Subject: [PATCH 00/11] arm64: Introduce Allwinner A64 and Pine64 support
In-Reply-To: <b1250d48-a7a1-4f7f-893b-9abe3c91724e@googlegroups.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <b1250d48-a7a1-4f7f-893b-9abe3c91724e@googlegroups.com>
Message-ID: <56B06502.8030002@arm.com>

On 02/02/16 07:57, lists.nick.betteridge at gmail.com wrote:
> Just a quick question - will there be any support for enabling booting into virtualisation mode to run xen and the like?

This is a firmware issue. The SoC itself provides everything you need
and even Allwinner choosing ARM Trusted Firmware (ATF) to do PSCI
handling shows how to do it - but for whatever reason they hacked it to
_not_ enter the kernel (or Xen, for that matter) in EL2.

But this should be fixable - either by using U-Boot's PSCI support or by
doing a proper ATF port. I am tempted to look at the latter.

Rest assured that using KVM was the primary reason I backed the Pine64,
so this definitely will be supported some day. Booting Xen does not make
much difference in this respect then.

Cheers,
Andre



From shawnguo at kernel.org  Tue Feb  2 00:14:46 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Tue, 2 Feb 2016 16:14:46 +0800
Subject: [PATCH 1/2] ARM: imx_v6_v7_defconfig: Select
 CONFIG_NVMEM_IMX_OCOTP
In-Reply-To: <1454164508-10831-1-git-send-email-festevam@gmail.com>
References: <1454164508-10831-1-git-send-email-festevam@gmail.com>
Message-ID: <20160202081446.GN8307@tiger>

On Sat, Jan 30, 2016 at 12:35:07PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at nxp.com>
> 
> Select the i.mx ocotp driver.
> 
> Cc: Philipp Zabel <p.zabel at pengutronix.de>
> Signed-off-by: Fabio Estevam <fabio.estevam at nxp.com>

Applied both, thanks.


From johannes at sipsolutions.net  Tue Feb  2 00:16:48 2016
From: johannes at sipsolutions.net (Johannes Berg)
Date: Tue, 02 Feb 2016 09:16:48 +0100
Subject: [PATCH v2 2/2] arm/mach-imx: enable big endian mode
In-Reply-To: <20160202053304.GA8307@tiger>
References: <1453913976-30619-1-git-send-email-johannes@sipsolutions.net>
 <1453913976-30619-3-git-send-email-johannes@sipsolutions.net>
 <20160202053304.GA8307@tiger>
Message-ID: <1454401008.2926.0.camel@sipsolutions.net>

On Tue, 2016-02-02 at 13:33 +0800, Shawn Guo wrote:
>?
> We conventionally use "ARM: imx: ..." as the subject for IMX platform
> patches.

Fair enough. I thought I saw this style used in the git log, but I may
very well be mistaken :)

> > +++ b/arch/arm/mach-imx/Kconfig
> > @@ -9,6 +9,7 @@ menuconfig ARCH_MXC
> > ?	select PM_OPP if PM
> > ?	select SOC_BUS
> > ?	select SRAM
> > +	select ARCH_SUPPORTS_BIG_ENDIAN
> 
> It should be added in alphabetical order.

Heh, ok.

> I fixed these two minor things and applied both patches.

Great, thanks!

johannes


From Minghuan.Lian at nxp.com  Tue Feb  2 00:30:07 2016
From: Minghuan.Lian at nxp.com (Minghuan Lian)
Date: Tue, 2 Feb 2016 16:30:07 +0800
Subject: [PATCH 1/4] ARM: dts: ls1021a: add PCIe dts node
Message-ID: <1454401807-28751-1-git-send-email-Minghuan.Lian@nxp.com>

LS1021a contains two PCIe controllers. The patch adds their node to
dts file.

Signed-off-by: Minghuan Lian <Minghuan.Lian at nxp.com>
---
 arch/arm/boot/dts/ls1021a.dtsi | 44 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 2c84ca2..274d647 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -560,5 +560,49 @@
 			dr_mode = "host";
 			snps,quirk-frame-length-adjustment = <0x20>;
 		};
+
+		pcie at 3400000 {
+			compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
+			reg = <0x00 0x03400000 0x0 0x00010000   /* controller registers */
+			       0x40 0x00000000 0x0 0x00002000>; /* configuration space */
+			reg-names = "regs", "config";
+			interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
+			fsl,pcie-scfg = <&scfg 0>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			num-lanes = <4>;
+			bus-range = <0x0 0xff>;
+			ranges = <0x81000000 0x0 0x00000000 0x40 0x00010000 0x0 0x00010000   /* downstream I/O */
+				  0x82000000 0x0 0x40000000 0x40 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 7>;
+			interrupt-map = <0000 0 0 1 &gic GIC_SPI 91  IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 2 &gic GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 3 &gic GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 4 &gic GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		pcie at 3500000 {
+			compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
+			reg = <0x00 0x03500000 0x0 0x00010000   /* controller registers */
+			       0x48 0x00000000 0x0 0x00002000>; /* configuration space */
+			reg-names = "regs", "config";
+			interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
+			fsl,pcie-scfg = <&scfg 1>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			num-lanes = <4>;
+			bus-range = <0x0 0xff>;
+			ranges = <0x81000000 0x0 0x00000000 0x48 0x00010000 0x0 0x00010000   /* downstream I/O */
+				  0x82000000 0x0 0x40000000 0x48 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0 0 0 7>;
+			interrupt-map = <0000 0 0 1 &gic GIC_SPI 92  IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 2 &gic GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 3 &gic GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
+					<0000 0 0 4 &gic GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
+		};
 	};
 };
-- 
1.9.1



From arnd at arndb.de  Tue Feb  2 00:32:05 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 02 Feb 2016 09:32:05 +0100
Subject: [PATCH 1/4] ARM: dts: ls1021a: add PCIe dts node
In-Reply-To: <1454401807-28751-1-git-send-email-Minghuan.Lian@nxp.com>
References: <1454401807-28751-1-git-send-email-Minghuan.Lian@nxp.com>
Message-ID: <1640613.2DY3gpScUX@wuerfel>

On Tuesday 02 February 2016 16:30:07 Minghuan Lian wrote:
> LS1021a contains two PCIe controllers. The patch adds their node to
> dts file.
> 
> Signed-off-by: Minghuan Lian <Minghuan.Lian at nxp.com>
> ---
>  arch/arm/boot/dts/ls1021a.dtsi | 44 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
> 

Looks ok to me, please submit to the ARM imx maintainers for merging.

	Arnd


From clabbe.montjoie at gmail.com  Tue Feb  2 00:42:54 2016
From: clabbe.montjoie at gmail.com (LABBE Corentin)
Date: Tue, 2 Feb 2016 09:42:54 +0100
Subject: [linux-sunxi] [PATCH 02/11] crypto: sunxi-ss: prevent
 compilation on 64-bit
In-Reply-To: <1454348370-3816-3-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-3-git-send-email-andre.przywara@arm.com>
Message-ID: <20160202084254.GA22621@Red>

On Mon, Feb 01, 2016 at 05:39:21PM +0000, Andre Przywara wrote:
> The driver for the sunxi-ss crypto engine is not entirely 64-bit safe,
> compilation on arm64 spits some warnings.
> The proper fix was deemed to involved [1], so since 64-bit SoCs won't
> have this IP block we just disable this driver for 64-bit.
> 
> [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399988.html
>      (and the reply)
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>

Acked-by: Corentin LABBE <clabbe.montjoie at gmail.com>

> ---
>  drivers/crypto/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 07d4942..737200f 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -487,7 +487,7 @@ config CRYPTO_DEV_IMGTEC_HASH
>  
>  config CRYPTO_DEV_SUN4I_SS
>  	tristate "Support for Allwinner Security System cryptographic accelerator"
> -	depends on ARCH_SUNXI
> +	depends on ARCH_SUNXI && !64BIT
>  	select CRYPTO_MD5
>  	select CRYPTO_SHA1
>  	select CRYPTO_AES
> -- 
> 2.6.4
> 
> -- 


From maxime.ripard at free-electrons.com  Tue Feb  2 00:47:09 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue,  2 Feb 2016 09:47:09 +0100
Subject: [PATCH 0/5] clk: sunxi: Rework the clocks code to deal with orphans
Message-ID: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>

Hi everyone,

Here is an attempt at making the whole clk-sunxi code register the
clocks without creating any orphans by relying on CLK_OF_DECLARE.

This also has the net benefit of not having to add the SoC compatible
to the list of compatibles that trigger the clock registration, which
has started to be a pain.

I tested this on an A13 (R8 actually), everything seems to be working
just fine. I also tested it both with and without Heiko's patch to
defer clk_get if the clock is orphan, and previously broke everything.

Let me know what you think,
Maxime

Maxime Ripard (5):
  clk: sunxi: Make clocks setup functions return their clock
  clk: sunxi: Make clocks setup functions take const pointer
  clk: sunxi: convert current clocks registration to CLK_OF_DECLARE
  clk: sunxi: Remove old probe and protection code
  clk: sunxi: Remove clk_register_clkdev calls

 drivers/clk/sunxi/clk-a10-hosc.c         |   3 +-
 drivers/clk/sunxi/clk-a20-gmac.c         |   2 -
 drivers/clk/sunxi/clk-factors.c          |   7 -
 drivers/clk/sunxi/clk-factors.h          |   1 -
 drivers/clk/sunxi/clk-mod0.c             |   1 +
 drivers/clk/sunxi/clk-sun6i-apb0-gates.c |   2 -
 drivers/clk/sunxi/clk-sun9i-core.c       |   1 +
 drivers/clk/sunxi/clk-sunxi.c            | 263 ++++++++++++++++---------------
 8 files changed, 135 insertions(+), 145 deletions(-)

-- 
2.6.4



From maxime.ripard at free-electrons.com  Tue Feb  2 00:47:10 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue,  2 Feb 2016 09:47:10 +0100
Subject: [PATCH 1/5] clk: sunxi: Make clocks setup functions return their clock
In-Reply-To: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1454402834-6385-2-git-send-email-maxime.ripard@free-electrons.com>

The clocks registration code in clk-sunxi was most of the time not
returning the struct clk (or struct clk array) that was registered,
preventing the users of such functions to manipulate it, for example to
protect it.

Make them return it so that we can start using it.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index e460a6b0068c..67ef94948544 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -615,8 +615,8 @@ static const struct mux_data sun8i_h3_ahb2_mux_data __initconst = {
 	.shift = 0,
 };
 
-static void __init sunxi_mux_clk_setup(struct device_node *node,
-				       struct mux_data *data)
+static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
+					       struct mux_data *data)
 {
 	struct clk *clk;
 	const char *clk_name = node->name;
@@ -638,6 +638,8 @@ static void __init sunxi_mux_clk_setup(struct device_node *node,
 		of_clk_add_provider(node, of_clk_src_simple_get, clk);
 		clk_register_clkdev(clk, clk_name, NULL);
 	}
+
+	return clk;
 }
 
 
@@ -722,7 +724,6 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
 }
 
 
-
 /**
  * sunxi_gates_clk_setup() - Setup function for leaf gates on clocks
  */
@@ -808,8 +809,8 @@ static const struct divs_data sun6i_a31_pll6_divs_data __initconst = {
  *           |________________________|
  */
 
-static void __init sunxi_divs_clk_setup(struct device_node *node,
-					struct divs_data *data)
+static struct clk ** __init sunxi_divs_clk_setup(struct device_node *node,
+						 struct divs_data *data)
 {
 	struct clk_onecell_data *clk_data;
 	const char *parent;
@@ -836,7 +837,7 @@ static void __init sunxi_divs_clk_setup(struct device_node *node,
 
 	clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
 	if (!clk_data)
-		return;
+		return NULL;
 
 	clks = kcalloc(ndivs, sizeof(*clks), GFP_KERNEL);
 	if (!clks)
@@ -922,7 +923,7 @@ static void __init sunxi_divs_clk_setup(struct device_node *node,
 
 	of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
 
-	return;
+	return clks;
 
 free_gate:
 	kfree(gate);
@@ -930,6 +931,7 @@ free_clks:
 	kfree(clks);
 free_clkdata:
 	kfree(clk_data);
+	return NULL;
 }
 
 
-- 
2.6.4



From maxime.ripard at free-electrons.com  Tue Feb  2 00:47:11 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue,  2 Feb 2016 09:47:11 +0100
Subject: [PATCH 2/5] clk: sunxi: Make clocks setup functions take const pointer
In-Reply-To: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1454402834-6385-3-git-send-email-maxime.ripard@free-electrons.com>

All the data structure that we pass to the clocks setup functions are
declared const, while our setup functions expects a regular pointer. This
was hidden by the fact that we cast a void * pointer back to these
structures, which made it go unnoticed.

Fix the functions prototype.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 67ef94948544..a3d706f5b21c 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -616,7 +616,7 @@ static const struct mux_data sun8i_h3_ahb2_mux_data __initconst = {
 };
 
 static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
-					       struct mux_data *data)
+					       const struct mux_data *data)
 {
 	struct clk *clk;
 	const char *clk_name = node->name;
@@ -700,7 +700,7 @@ static const struct div_data sun4i_apb0_data __initconst = {
 };
 
 static void __init sunxi_divider_clk_setup(struct device_node *node,
-					   struct div_data *data)
+					   const struct div_data *data)
 {
 	struct clk *clk;
 	const char *clk_name = node->name;
@@ -810,7 +810,7 @@ static const struct divs_data sun6i_a31_pll6_divs_data __initconst = {
  */
 
 static struct clk ** __init sunxi_divs_clk_setup(struct device_node *node,
-						 struct divs_data *data)
+						 const struct divs_data *data)
 {
 	struct clk_onecell_data *clk_data;
 	const char *parent;
-- 
2.6.4



From maxime.ripard at free-electrons.com  Tue Feb  2 00:47:13 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue,  2 Feb 2016 09:47:13 +0100
Subject: [PATCH 4/5] clk: sunxi: Remove old probe and protection code
In-Reply-To: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1454402834-6385-5-git-send-email-maxime.ripard@free-electrons.com>

Now that we don't have any user left for the old registration code, we can
remove it.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 114 ------------------------------------------
 1 file changed, 114 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index da6c1bc763d1..5f2f3e0408bd 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -1067,117 +1067,3 @@ static void __init sun6i_pll6_clk_setup(struct device_node *node)
 }
 CLK_OF_DECLARE(sun6i_pll6, "allwinner,sun6i-a31-pll6-clk",
 	       sun6i_pll6_clk_setup);
-
-
-/* Matches for factors clocks */
-static const struct of_device_id clk_factors_match[] __initconst = {
-	{}
-};
-
-/* Matches for divider clocks */
-static const struct of_device_id clk_div_match[] __initconst = {
-	{}
-};
-
-/* Matches for divided outputs */
-static const struct of_device_id clk_divs_match[] __initconst = {
-	{}
-};
-
-/* Matches for mux clocks */
-static const struct of_device_id clk_mux_match[] __initconst = {
-	{}
-};
-
-
-static void __init of_sunxi_table_clock_setup(const struct of_device_id *clk_match,
-					      void *function)
-{
-	struct device_node *np;
-	const struct div_data *data;
-	const struct of_device_id *match;
-	void (*setup_function)(struct device_node *, const void *) = function;
-
-	for_each_matching_node_and_match(np, clk_match, &match) {
-		data = match->data;
-		setup_function(np, data);
-	}
-}
-
-static void __init sunxi_init_clocks(const char *clocks[], int nclocks)
-{
-	unsigned int i;
-
-	/* Register divided output clocks */
-	of_sunxi_table_clock_setup(clk_divs_match, sunxi_divs_clk_setup);
-
-	/* Register factor clocks */
-	of_sunxi_table_clock_setup(clk_factors_match, sunxi_factors_clk_setup);
-
-	/* Register divider clocks */
-	of_sunxi_table_clock_setup(clk_div_match, sunxi_divider_clk_setup);
-
-	/* Register mux clocks */
-	of_sunxi_table_clock_setup(clk_mux_match, sunxi_mux_clk_setup);
-
-	/* Protect the clocks that needs to stay on */
-	for (i = 0; i < nclocks; i++) {
-		struct clk *clk = clk_get(NULL, clocks[i]);
-
-		if (!IS_ERR(clk))
-			clk_prepare_enable(clk);
-	}
-}
-
-static const char *sun4i_a10_critical_clocks[] __initdata = {
-	"pll5_ddr",
-};
-
-static void __init sun4i_a10_init_clocks(struct device_node *node)
-{
-	sunxi_init_clocks(sun4i_a10_critical_clocks,
-			  ARRAY_SIZE(sun4i_a10_critical_clocks));
-}
-CLK_OF_DECLARE(sun4i_a10_clk_init, "allwinner,sun4i-a10", sun4i_a10_init_clocks);
-
-static const char *sun5i_critical_clocks[] __initdata = {
-	"cpu",
-	"pll5_ddr",
-};
-
-static void __init sun5i_init_clocks(struct device_node *node)
-{
-	sunxi_init_clocks(sun5i_critical_clocks,
-			  ARRAY_SIZE(sun5i_critical_clocks));
-}
-CLK_OF_DECLARE(sun5i_a10s_clk_init, "allwinner,sun5i-a10s", sun5i_init_clocks);
-CLK_OF_DECLARE(sun5i_a13_clk_init, "allwinner,sun5i-a13", sun5i_init_clocks);
-CLK_OF_DECLARE(sun5i_r8_clk_init, "allwinner,sun5i-r8", sun5i_init_clocks);
-CLK_OF_DECLARE(sun7i_a20_clk_init, "allwinner,sun7i-a20", sun5i_init_clocks);
-
-static const char *sun6i_critical_clocks[] __initdata = {
-	"cpu",
-};
-
-static void __init sun6i_init_clocks(struct device_node *node)
-{
-	sunxi_init_clocks(sun6i_critical_clocks,
-			  ARRAY_SIZE(sun6i_critical_clocks));
-}
-CLK_OF_DECLARE(sun6i_a31_clk_init, "allwinner,sun6i-a31", sun6i_init_clocks);
-CLK_OF_DECLARE(sun6i_a31s_clk_init, "allwinner,sun6i-a31s", sun6i_init_clocks);
-CLK_OF_DECLARE(sun8i_a23_clk_init, "allwinner,sun8i-a23", sun6i_init_clocks);
-CLK_OF_DECLARE(sun8i_a33_clk_init, "allwinner,sun8i-a33", sun6i_init_clocks);
-CLK_OF_DECLARE(sun8i_h3_clk_init, "allwinner,sun8i-h3", sun6i_init_clocks);
-
-static void __init sun8i_a83t_init_clocks(struct device_node *node)
-{
-	sunxi_init_clocks(NULL, 0);
-}
-CLK_OF_DECLARE(sun8i_a83t_clk_init, "allwinner,sun8i-a83t", sun8i_a83t_init_clocks);
-
-static void __init sun9i_init_clocks(struct device_node *node)
-{
-	sunxi_init_clocks(NULL, 0);
-}
-CLK_OF_DECLARE(sun9i_a80_clk_init, "allwinner,sun9i-a80", sun9i_init_clocks);
-- 
2.6.4



From maxime.ripard at free-electrons.com  Tue Feb  2 00:47:12 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue,  2 Feb 2016 09:47:12 +0100
Subject: [PATCH 3/5] clk: sunxi: convert current clocks registration to
 CLK_OF_DECLARE
In-Reply-To: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1454402834-6385-4-git-send-email-maxime.ripard@free-electrons.com>

The current clock registration and protection code has a few drawbacks, the
two main ones being that we create a lot of orphans clock in the
registration phase, which will be troublesome when we will start being less
relaxed about them.

The protection code also relies on clkdev, which we don't really use but
for this particular case.

Fix both at the same time by moving everyone to the CLK_OF_DECLARE that
will probe our clock tree in the right and thus avoid orphans, and by
protecting directly the clock returned by our registration function.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 150 +++++++++++++++++++++++++++++++++++++-----
 1 file changed, 133 insertions(+), 17 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index a3d706f5b21c..da6c1bc763d1 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -585,6 +585,41 @@ static struct clk * __init sunxi_factors_clk_setup(struct device_node *node,
 	return sunxi_factors_register(node, data, &clk_lock, reg);
 }
 
+static void __init sun4i_pll1_clk_setup(struct device_node *node)
+{
+	sunxi_factors_clk_setup(node, &sun4i_pll1_data);
+}
+CLK_OF_DECLARE(sun4i_pll1, "allwinner,sun4i-a10-pll1-clk",
+	       sun4i_pll1_clk_setup);
+
+static void __init sun6i_pll1_clk_setup(struct device_node *node)
+{
+	sunxi_factors_clk_setup(node, &sun6i_a31_pll1_data);
+}
+CLK_OF_DECLARE(sun6i_pll1, "allwinner,sun6i-a31-pll1-clk",
+	       sun6i_pll1_clk_setup);
+
+static void __init sun8i_pll1_clk_setup(struct device_node *node)
+{
+	sunxi_factors_clk_setup(node, &sun8i_a23_pll1_data);
+}
+CLK_OF_DECLARE(sun8i_pll1, "allwinner,sun8i-a23-pll1-clk",
+	       sun8i_pll1_clk_setup);
+
+static void __init sun7i_pll4_clk_setup(struct device_node *node)
+{
+	sunxi_factors_clk_setup(node, &sun7i_a20_pll4_data);
+}
+CLK_OF_DECLARE(sun7i_pll4, "allwinner,sun7i-a20-pll4-clk",
+	       sun7i_pll4_clk_setup);
+
+static void __init sun5i_ahb_clk_setup(struct device_node *node)
+{
+	sunxi_factors_clk_setup(node, &sun5i_a13_ahb_data);
+}
+CLK_OF_DECLARE(sun5i_ahb, "allwinner,sun5i-a13-ahb-clk",
+	       sun5i_ahb_clk_setup);
+
 static void __init sun6i_ahb1_clk_setup(struct device_node *node)
 {
 	sunxi_factors_clk_setup(node, &sun6i_ahb1_data);
@@ -592,6 +627,20 @@ static void __init sun6i_ahb1_clk_setup(struct device_node *node)
 CLK_OF_DECLARE(sun6i_a31_ahb1, "allwinner,sun6i-a31-ahb1-clk",
 	       sun6i_ahb1_clk_setup);
 
+static void __init sun4i_apb1_clk_setup(struct device_node *node)
+{
+	sunxi_factors_clk_setup(node, &sun4i_apb1_data);
+}
+CLK_OF_DECLARE(sun4i_apb1, "allwinner,sun4i-a10-apb1-clk",
+	       sun4i_apb1_clk_setup);
+
+static void __init sun7i_out_clk_setup(struct device_node *node)
+{
+	sunxi_factors_clk_setup(node, &sun7i_a20_out_data);
+}
+CLK_OF_DECLARE(sun7i_out, "allwinner,sun7i-a20-out-clk",
+	       sun7i_out_clk_setup);
+
 
 /**
  * sunxi_mux_clk_setup() - Setup function for muxes
@@ -642,6 +691,34 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
 	return clk;
 }
 
+static void __init sun4i_cpu_clk_setup(struct device_node *node)
+{
+	struct clk *clk;
+
+	clk = sunxi_mux_clk_setup(node, &sun4i_cpu_mux_data);
+	if (!clk)
+		return;
+
+	/* Protect CPU clock */
+	__clk_get(clk);
+	clk_prepare_enable(clk);
+}
+CLK_OF_DECLARE(sun4i_cpu, "allwinner,sun4i-a10-cpu-clk",
+	       sun4i_cpu_clk_setup);
+
+static void __init sun6i_ahb1_mux_clk_setup(struct device_node *node)
+{
+	sunxi_mux_clk_setup(node, &sun6i_a31_ahb1_mux_data);
+}
+CLK_OF_DECLARE(sun6i_ahb1_mux, "allwinner,sun6i-a31-ahb1-mux-clk",
+	       sun6i_ahb1_mux_clk_setup);
+
+static void __init sun8i_ahb2_clk_setup(struct device_node *node)
+{
+	sunxi_mux_clk_setup(node, &sun8i_h3_ahb2_mux_data);
+}
+CLK_OF_DECLARE(sun8i_ahb2, "allwinner,sun8i-a31-ahb2-clk",
+	       sun8i_ahb2_clk_setup);
 
 
 /**
@@ -723,6 +800,34 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
 	}
 }
 
+static void __init sun4i_ahb_clk_setup(struct device_node *node)
+{
+	sunxi_divider_clk_setup(node, &sun4i_ahb_data);
+}
+CLK_OF_DECLARE(sun4i_ahb, "allwinner,sun4i-a10-ahb-clk",
+	       sun4i_ahb_clk_setup);
+
+static void __init sun4i_apb0_clk_setup(struct device_node *node)
+{
+	sunxi_divider_clk_setup(node, &sun4i_apb0_data);
+}
+CLK_OF_DECLARE(sun4i_apb0, "allwinner,sun4i-a10-apb0-clk",
+	       sun4i_apb0_clk_setup);
+
+static void __init sun4i_axi_clk_setup(struct device_node *node)
+{
+	sunxi_divider_clk_setup(node, &sun4i_axi_data);
+}
+CLK_OF_DECLARE(sun4i_axi, "allwinner,sun4i-a10-axi-clk",
+	       sun4i_axi_clk_setup);
+
+static void __init sun8i_axi_clk_setup(struct device_node *node)
+{
+	sunxi_divider_clk_setup(node, &sun8i_a23_axi_data);
+}
+CLK_OF_DECLARE(sun8i_axi, "allwinner,sun8i-a23-axi-clk",
+	       sun8i_axi_clk_setup);
+
 
 /**
  * sunxi_gates_clk_setup() - Setup function for leaf gates on clocks
@@ -934,42 +1039,53 @@ free_clkdata:
 	return NULL;
 }
 
+static void __init sun4i_pll5_clk_setup(struct device_node *node)
+{
+	struct clk **clks;
+
+	clks = sunxi_divs_clk_setup(node, &pll5_divs_data);
+	if (!clks)
+		return;
+
+	/* Protect PLL5_DDR */
+	__clk_get(clks[0]);
+	clk_prepare_enable(clks[0]);
+}
+CLK_OF_DECLARE(sun4i_pll5, "allwinner,sun4i-a10-pll5-clk",
+	       sun4i_pll5_clk_setup);
+
+static void __init sun4i_pll6_clk_setup(struct device_node *node)
+{
+	sunxi_divs_clk_setup(node, &pll6_divs_data);
+}
+CLK_OF_DECLARE(sun4i_pll6, "allwinner,sun4i-a10-pll6-clk",
+	       sun4i_pll6_clk_setup);
+
+static void __init sun6i_pll6_clk_setup(struct device_node *node)
+{
+	sunxi_divs_clk_setup(node, &sun6i_a31_pll6_divs_data);
+}
+CLK_OF_DECLARE(sun6i_pll6, "allwinner,sun6i-a31-pll6-clk",
+	       sun6i_pll6_clk_setup);
 
 
 /* Matches for factors clocks */
 static const struct of_device_id clk_factors_match[] __initconst = {
-	{.compatible = "allwinner,sun4i-a10-pll1-clk", .data = &sun4i_pll1_data,},
-	{.compatible = "allwinner,sun6i-a31-pll1-clk", .data = &sun6i_a31_pll1_data,},
-	{.compatible = "allwinner,sun8i-a23-pll1-clk", .data = &sun8i_a23_pll1_data,},
-	{.compatible = "allwinner,sun7i-a20-pll4-clk", .data = &sun7i_a20_pll4_data,},
-	{.compatible = "allwinner,sun5i-a13-ahb-clk", .data = &sun5i_a13_ahb_data,},
-	{.compatible = "allwinner,sun4i-a10-apb1-clk", .data = &sun4i_apb1_data,},
-	{.compatible = "allwinner,sun7i-a20-out-clk", .data = &sun7i_a20_out_data,},
 	{}
 };
 
 /* Matches for divider clocks */
 static const struct of_device_id clk_div_match[] __initconst = {
-	{.compatible = "allwinner,sun4i-a10-axi-clk", .data = &sun4i_axi_data,},
-	{.compatible = "allwinner,sun8i-a23-axi-clk", .data = &sun8i_a23_axi_data,},
-	{.compatible = "allwinner,sun4i-a10-ahb-clk", .data = &sun4i_ahb_data,},
-	{.compatible = "allwinner,sun4i-a10-apb0-clk", .data = &sun4i_apb0_data,},
 	{}
 };
 
 /* Matches for divided outputs */
 static const struct of_device_id clk_divs_match[] __initconst = {
-	{.compatible = "allwinner,sun4i-a10-pll5-clk", .data = &pll5_divs_data,},
-	{.compatible = "allwinner,sun4i-a10-pll6-clk", .data = &pll6_divs_data,},
-	{.compatible = "allwinner,sun6i-a31-pll6-clk", .data = &sun6i_a31_pll6_divs_data,},
 	{}
 };
 
 /* Matches for mux clocks */
 static const struct of_device_id clk_mux_match[] __initconst = {
-	{.compatible = "allwinner,sun4i-a10-cpu-clk", .data = &sun4i_cpu_mux_data,},
-	{.compatible = "allwinner,sun6i-a31-ahb1-mux-clk", .data = &sun6i_a31_ahb1_mux_data,},
-	{.compatible = "allwinner,sun8i-h3-ahb2-clk", .data = &sun8i_h3_ahb2_mux_data,},
 	{}
 };
 
-- 
2.6.4



From maxime.ripard at free-electrons.com  Tue Feb  2 00:47:14 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue,  2 Feb 2016 09:47:14 +0100
Subject: [PATCH 5/5] clk: sunxi: Remove clk_register_clkdev calls
In-Reply-To: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1454402834-6385-6-git-send-email-maxime.ripard@free-electrons.com>

Now that our protection code doesn't use the global name lookup anymore, we
can remove the clkdev registrations.

Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/clk/sunxi/clk-a10-hosc.c         | 3 +--
 drivers/clk/sunxi/clk-a20-gmac.c         | 2 --
 drivers/clk/sunxi/clk-factors.c          | 7 -------
 drivers/clk/sunxi/clk-factors.h          | 1 -
 drivers/clk/sunxi/clk-mod0.c             | 1 +
 drivers/clk/sunxi/clk-sun6i-apb0-gates.c | 2 --
 drivers/clk/sunxi/clk-sun9i-core.c       | 1 +
 drivers/clk/sunxi/clk-sunxi.c            | 3 ---
 8 files changed, 3 insertions(+), 17 deletions(-)

diff --git a/drivers/clk/sunxi/clk-a10-hosc.c b/drivers/clk/sunxi/clk-a10-hosc.c
index 0481d5d673d6..6b598c6a0213 100644
--- a/drivers/clk/sunxi/clk-a10-hosc.c
+++ b/drivers/clk/sunxi/clk-a10-hosc.c
@@ -15,9 +15,9 @@
  */
 
 #include <linux/clk-provider.h>
-#include <linux/clkdev.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
+#include <linux/slab.h>
 
 #define SUNXI_OSC24M_GATE	0
 
@@ -61,7 +61,6 @@ static void __init sun4i_osc_clk_setup(struct device_node *node)
 		goto err_free_gate;
 
 	of_clk_add_provider(node, of_clk_src_simple_get, clk);
-	clk_register_clkdev(clk, clk_name, NULL);
 
 	return;
 
diff --git a/drivers/clk/sunxi/clk-a20-gmac.c b/drivers/clk/sunxi/clk-a20-gmac.c
index 1611b036421c..3437f734c9bf 100644
--- a/drivers/clk/sunxi/clk-a20-gmac.c
+++ b/drivers/clk/sunxi/clk-a20-gmac.c
@@ -17,7 +17,6 @@
  */
 
 #include <linux/clk-provider.h>
-#include <linux/clkdev.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/slab.h>
@@ -107,7 +106,6 @@ static void __init sun7i_a20_gmac_clk_setup(struct device_node *node)
 		goto iounmap_reg;
 
 	of_clk_add_provider(node, of_clk_src_simple_get, clk);
-	clk_register_clkdev(clk, clk_name, NULL);
 
 	return;
 
diff --git a/drivers/clk/sunxi/clk-factors.c b/drivers/clk/sunxi/clk-factors.c
index 6e97f46c0c37..ddefe9668863 100644
--- a/drivers/clk/sunxi/clk-factors.c
+++ b/drivers/clk/sunxi/clk-factors.c
@@ -258,14 +258,8 @@ struct clk *sunxi_factors_register(struct device_node *node,
 	if (ret)
 		goto err_provider;
 
-	ret = clk_register_clkdev(clk, clk_name, NULL);
-	if (ret)
-		goto err_clkdev;
-
 	return clk;
 
-err_clkdev:
-	of_clk_del_provider(node);
 err_provider:
 	/* TODO: The composite clock stuff will leak a bit here. */
 	clk_unregister(clk);
@@ -291,7 +285,6 @@ void sunxi_factors_unregister(struct device_node *node, struct clk *clk)
 	factors = to_clk_factors(hw);
 	name = clk_hw_get_name(hw);
 
-	/* No unregister call for clkdev_* */
 	of_clk_del_provider(node);
 	/* TODO: The composite clock stuff will leak a bit here. */
 	clk_unregister(clk);
diff --git a/drivers/clk/sunxi/clk-factors.h b/drivers/clk/sunxi/clk-factors.h
index a44a865a6b9e..1e63c5b2d5f4 100644
--- a/drivers/clk/sunxi/clk-factors.h
+++ b/drivers/clk/sunxi/clk-factors.h
@@ -2,7 +2,6 @@
 #define __MACH_SUNXI_CLK_FACTORS_H
 
 #include <linux/clk-provider.h>
-#include <linux/clkdev.h>
 #include <linux/spinlock.h>
 
 #define SUNXI_FACTORS_NOT_APPLICABLE	(0)
diff --git a/drivers/clk/sunxi/clk-mod0.c b/drivers/clk/sunxi/clk-mod0.c
index 578bff0dd251..b38d71cec74c 100644
--- a/drivers/clk/sunxi/clk-mod0.c
+++ b/drivers/clk/sunxi/clk-mod0.c
@@ -15,6 +15,7 @@
  */
 
 #include <linux/clk.h>
+#include <linux/clkdev.h>
 #include <linux/clk-provider.h>
 #include <linux/of_address.h>
 #include <linux/platform_device.h>
diff --git a/drivers/clk/sunxi/clk-sun6i-apb0-gates.c b/drivers/clk/sunxi/clk-sun6i-apb0-gates.c
index 23d042aabb4f..68021fa5ecd9 100644
--- a/drivers/clk/sunxi/clk-sun6i-apb0-gates.c
+++ b/drivers/clk/sunxi/clk-sun6i-apb0-gates.c
@@ -9,7 +9,6 @@
  */
 
 #include <linux/clk-provider.h>
-#include <linux/clkdev.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
@@ -87,7 +86,6 @@ static int sun6i_a31_apb0_gates_clk_probe(struct platform_device *pdev)
 						      clk_parent, 0, reg, i,
 						      0, NULL);
 		WARN_ON(IS_ERR(clk_data->clks[i]));
-		clk_register_clkdev(clk_data->clks[i], clk_name, NULL);
 
 		j++;
 	}
diff --git a/drivers/clk/sunxi/clk-sun9i-core.c b/drivers/clk/sunxi/clk-sun9i-core.c
index a81211062ecb..43f014f85803 100644
--- a/drivers/clk/sunxi/clk-sun9i-core.c
+++ b/drivers/clk/sunxi/clk-sun9i-core.c
@@ -15,6 +15,7 @@
  */
 
 #include <linux/clk.h>
+#include <linux/clkdev.h>
 #include <linux/clk-provider.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 5f2f3e0408bd..91f6d8ef81df 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -685,7 +685,6 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
 
 	if (clk) {
 		of_clk_add_provider(node, of_clk_src_simple_get, clk);
-		clk_register_clkdev(clk, clk_name, NULL);
 	}
 
 	return clk;
@@ -796,7 +795,6 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
 					 data->table, &clk_lock);
 	if (clk) {
 		of_clk_add_provider(node, of_clk_src_simple_get, clk);
-		clk_register_clkdev(clk, clk_name, NULL);
 	}
 }
 
@@ -1020,7 +1018,6 @@ static struct clk ** __init sunxi_divs_clk_setup(struct device_node *node,
 						 clkflags);
 
 		WARN_ON(IS_ERR(clk_data->clks[i]));
-		clk_register_clkdev(clks[i], clk_name, NULL);
 	}
 
 	/* Adjust to the real max */
-- 
2.6.4



From minghuan.lian at nxp.com  Tue Feb  2 00:48:36 2016
From: minghuan.lian at nxp.com (Minghuan Lian)
Date: Tue, 2 Feb 2016 08:48:36 +0000
Subject: [PATCH 1/4] ARM: dts: ls1021a: add PCIe dts node
In-Reply-To: <1454401807-28751-1-git-send-email-Minghuan.Lian@nxp.com>
References: <1454401807-28751-1-git-send-email-Minghuan.Lian@nxp.com>
Message-ID: <VI1PR04MB1615DCF54369ED2E01234E64E8DF0@VI1PR04MB1615.eurprd04.prod.outlook.com>

Hi Shawn,

Could you please help to review the patch?  Thank you very much.
There is only one patch not a set of patch, please ignore [1/4] :(

Arnd has given a ack.


Thanks,
Minghuan
 

> -----Original Message-----
> From: Minghuan Lian [mailto:Minghuan.Lian at nxp.com]
> Sent: Tuesday, February 02, 2016 4:30 PM
> To: linux-pci at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org; Roy Zang <roy.zang at nxp.com>;
> Mingkai Hu <mingkai.hu at nxp.com>; Stuart Yoder <stuart.yoder at nxp.com>;
> Yang-Leo Li <leoyang.li at nxp.com>; Arnd Bergmann <arnd at arndb.de>; Bjorn
> Helgaas <bhelgaas at google.com>; Minghuan Lian <minghuan.lian at nxp.com>
> Subject: [PATCH 1/4] ARM: dts: ls1021a: add PCIe dts node
> 
> LS1021a contains two PCIe controllers. The patch adds their node to dts file.
> 
> Signed-off-by: Minghuan Lian <Minghuan.Lian at nxp.com>
> ---
>  arch/arm/boot/dts/ls1021a.dtsi | 44
> ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 2c84ca2..274d647 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -560,5 +560,49 @@
>  			dr_mode = "host";
>  			snps,quirk-frame-length-adjustment = <0x20>;
>  		};
> +
> +		pcie at 3400000 {
> +			compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
> +			reg = <0x00 0x03400000 0x0 0x00010000   /* controller
> registers */
> +			       0x40 0x00000000 0x0 0x00002000>; /* configuration
> space */
> +			reg-names = "regs", "config";
> +			interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; /*
> controller interrupt */
> +			fsl,pcie-scfg = <&scfg 0>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +			device_type = "pci";
> +			num-lanes = <4>;
> +			bus-range = <0x0 0xff>;
> +			ranges = <0x81000000 0x0 0x00000000 0x40 0x00010000 0x0
> 0x00010000   /* downstream I/O */
> +				  0x82000000 0x0 0x40000000 0x40 0x40000000 0x0
> 0x40000000>; /* non-prefetchable memory */
> +			#interrupt-cells = <1>;
> +			interrupt-map-mask = <0 0 0 7>;
> +			interrupt-map = <0000 0 0 1 &gic GIC_SPI 91
> IRQ_TYPE_LEVEL_HIGH>,
> +					<0000 0 0 2 &gic GIC_SPI 188
> IRQ_TYPE_LEVEL_HIGH>,
> +					<0000 0 0 3 &gic GIC_SPI 190
> IRQ_TYPE_LEVEL_HIGH>,
> +					<0000 0 0 4 &gic GIC_SPI 192
> IRQ_TYPE_LEVEL_HIGH>;
> +		};
> +
> +		pcie at 3500000 {
> +			compatible = "fsl,ls1021a-pcie", "snps,dw-pcie";
> +			reg = <0x00 0x03500000 0x0 0x00010000   /* controller
> registers */
> +			       0x48 0x00000000 0x0 0x00002000>; /* configuration
> space */
> +			reg-names = "regs", "config";
> +			interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
> +			fsl,pcie-scfg = <&scfg 1>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +			device_type = "pci";
> +			num-lanes = <4>;
> +			bus-range = <0x0 0xff>;
> +			ranges = <0x81000000 0x0 0x00000000 0x48 0x00010000 0x0
> 0x00010000   /* downstream I/O */
> +				  0x82000000 0x0 0x40000000 0x48 0x40000000 0x0
> 0x40000000>; /* non-prefetchable memory */
> +			#interrupt-cells = <1>;
> +			interrupt-map-mask = <0 0 0 7>;
> +			interrupt-map = <0000 0 0 1 &gic GIC_SPI 92
> IRQ_TYPE_LEVEL_HIGH>,
> +					<0000 0 0 2 &gic GIC_SPI 189
> IRQ_TYPE_LEVEL_HIGH>,
> +					<0000 0 0 3 &gic GIC_SPI 191
> IRQ_TYPE_LEVEL_HIGH>,
> +					<0000 0 0 4 &gic GIC_SPI 193
> IRQ_TYPE_LEVEL_HIGH>;
> +		};
>  	};
>  };
> --
> 1.9.1


From ard.biesheuvel at linaro.org  Tue Feb  2 00:57:15 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 2 Feb 2016 09:57:15 +0100
Subject: [PATCHv2 2/3] arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
In-Reply-To: <56AFCD09.8000807@redhat.com>
References: <1454111218-3461-1-git-send-email-labbott@fedoraproject.org>
 <1454111218-3461-3-git-send-email-labbott@fedoraproject.org>
 <20160201122911.GF674@leverpostej> <56AFCD09.8000807@redhat.com>
Message-ID: <CAKv+Gu9hfBgK7WKMOUMWsgqSHMAKvnisqXje5tbNNKB+3Zo3KQ@mail.gmail.com>

On 1 February 2016 at 22:24, Laura Abbott <labbott at redhat.com> wrote:
> On 02/01/2016 04:29 AM, Mark Rutland wrote:
>>
>> Hi,
>>
>> On Fri, Jan 29, 2016 at 03:46:57PM -0800, Laura Abbott wrote:
>>>
>>>
>>> ARCH_SUPPORTS_DEBUG_PAGEALLOC provides a hook to map and unmap
>>> pages for debugging purposes. This requires memory be mapped
>>> with PAGE_SIZE mappings since breaking down larger mappings
>>> at runtime will lead to TLB conflicts. Check if debug_pagealloc
>>> is enabled at runtime and if so, map everyting with PAGE_SIZE
>>> pages. Implement the functions to actually map/unmap the
>>> pages at runtime.
>>>
>>>
>>> Signed-off-by: Laura Abbott <labbott at fedoraproject.org>
>>
>>
>> I tried to apply atop of the arm64 for-next/pgtable branch, but git
>> wasn't very happy about that -- which branch/patches is this based on?
>>
>> I'm not sure if I'm missing something, have something I shouldn't, or if
>> my MTA is corrupting patches again...
>>
>
> Hmmm, I based it off of your arm64-pagetable-rework-20160125 tag and
> Ard's patch for vmalloc and set_memory_* . The patches seem to apply
> on the for-next/pgtable branch as well so I'm guessing you are missing
> Ard's patch.
>
>
>
>>>
>>> ---
>>>   arch/arm64/Kconfig       |  3 +++
>>>   arch/arm64/mm/mmu.c      | 10 +++++++---
>>>   arch/arm64/mm/pageattr.c | 40 +++++++++++++++++++++++++++++++++-------
>>>   3 files changed, 43 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 8cc6228..0f33218 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -537,6 +537,9 @@ config HOTPLUG_CPU
>>>   source kernel/Kconfig.preempt
>>>   source kernel/Kconfig.hz
>>>
>>> +config ARCH_SUPPORTS_DEBUG_PAGEALLOC
>>> +       def_bool y
>>> +
>>>   config ARCH_HAS_HOLES_MEMORYMODEL
>>>         def_bool y if SPARSEMEM
>>>
>>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>>> index 103ebc0..5abbd30 100644
>>> --- a/arch/arm64/mm/mmu.c
>>> +++ b/arch/arm64/mm/mmu.c
>>> @@ -181,7 +181,8 @@ static void alloc_init_pmd(pud_t *pud, unsigned long
>>> addr, unsigned long end,
>>>         do {
>>>                 next = pmd_addr_end(addr, end);
>>>                 /* try section mapping first */
>>> -               if (((addr | next | phys) & ~SECTION_MASK) == 0) {
>>> +               if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
>>> +                     (!debug_pagealloc_enabled() || !pgtable_alloc)) {
>>>                         pmd_t old_pmd =*pmd;
>>>                         set_pmd(pmd, __pmd(phys |
>>>
>>> pgprot_val(mk_sect_prot(prot))));
>>> @@ -208,8 +209,11 @@ static void alloc_init_pmd(pud_t *pud, unsigned long
>>> addr, unsigned long end,
>>>   }
>>>
>>>   static inline bool use_1G_block(unsigned long addr, unsigned long next,
>>> -                       unsigned long phys)
>>> +                       unsigned long phys, phys_addr_t
>>> (*pgtable_alloc)(void))
>>>   {
>>> +       if (pgtable_alloc && debug_pagealloc_enabled())
>>> +               return false;
>>> +
>>>         if (PAGE_SHIFT != 12)
>>>                 return false;
>>>
>>> @@ -241,7 +245,7 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long
>>> addr, unsigned long end,
>>>                 /*
>>>                  * For 4K granule only, attempt to put down a 1GB block
>>>                  */
>>> -               if (use_1G_block(addr, next, phys)) {
>>> +               if (use_1G_block(addr, next, phys, pgtable_alloc)) {
>>>                         pud_t old_pud = *pud;
>>>                         set_pud(pud, __pud(phys |
>>>
>>> pgprot_val(mk_sect_prot(prot))));
>>
>>
>> The checks for pgtable_alloc is to allow create_mapping_noalloc to use
>> sections regardless, right?
>>
>> I got a little confused by that initially, but that seems to make sense.
>>
>
> Yeah, that was what I was going for. I went for the implication with
> pgtable_alloc
> over adding a bool variable to create_mapping. I'll see if I can put a
> comment
> in somewhere to clarify the intentions.
>

Yes, the logic becomes slightly fuzzy, so it would be good to document
this one way or the other.

-- 
Ard.

>
>>>
>>> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
>>> index 1360a02..69a8a7d 100644
>>> --- a/arch/arm64/mm/pageattr.c
>>> +++ b/arch/arm64/mm/pageattr.c
>>> @@ -38,7 +38,8 @@ static int change_page_range(pte_t *ptep, pgtable_t
>>> token, unsigned long addr,
>>>   }
>>>
>>>   static int change_memory_common(unsigned long addr, int numpages,
>>> -                               pgprot_t set_mask, pgprot_t clear_mask)
>>> +                               pgprot_t set_mask, pgprot_t clear_mask,
>>> +                               bool ignore_vma_check)
>>>   {
>>>         unsigned long start = addr;
>>>         unsigned long size = PAGE_SIZE*numpages;
>>> @@ -65,11 +66,14 @@ static int change_memory_common(unsigned long addr,
>>> int numpages,
>>>          *
>>>          * So check whether the [addr, addr + size) interval is entirely
>>>          * covered by precisely one VM area that has the VM_ALLOC flag
>>> set.
>>> +        *
>>> +        * The one exception to this is is we're forcing everything to be
>>> +        * page mapped with DEBUG_PAGEALLOC
>>>          */
>>>         area = find_vm_area((void *)addr);
>>> -       if (!area ||
>>> +       if (!ignore_vma_check && (!area ||
>>>             end > (unsigned long)area->addr + area->size ||
>>> -           !(area->flags & VM_ALLOC))
>>> +           !(area->flags & VM_ALLOC)))
>>>                 return -EINVAL;
>>
>>
>> Perhaps we could pull out everything but the VMA checks into a static
>> __change_memory_common. Then we can call that directly in
>> __kernel_map_pages, and don't need to pass a confusing boolean
>> parameter.
>
>
> Sounds fine.
>
>>
>> Otherwise, this looks good to me.
>>  Mark.
>>
>
> Thanks,
> Laura
>
>
>>>
>>>
>>>         data.set_mask = set_mask;
>>> @@ -86,21 +90,24 @@ int set_memory_ro(unsigned long addr, int numpages)
>>>   {
>>>         return change_memory_common(addr, numpages,
>>>                                         __pgprot(PTE_RDONLY),
>>> -                                       __pgprot(PTE_WRITE));
>>> +                                       __pgprot(PTE_WRITE),
>>> +                                       false);
>>>   }
>>>
>>>   int set_memory_rw(unsigned long addr, int numpages)
>>>   {
>>>         return change_memory_common(addr, numpages,
>>>                                         __pgprot(PTE_WRITE),
>>> -                                       __pgprot(PTE_RDONLY));
>>> +                                       __pgprot(PTE_RDONLY),
>>> +                                       false);
>>>   }
>>>
>>>   int set_memory_nx(unsigned long addr, int numpages)
>>>   {
>>>         return change_memory_common(addr, numpages,
>>>                                         __pgprot(PTE_PXN),
>>> -                                       __pgprot(0));
>>> +                                       __pgprot(0),
>>> +                                       false);
>>>   }
>>>   EXPORT_SYMBOL_GPL(set_memory_nx);
>>>
>>> @@ -108,6 +115,25 @@ int set_memory_x(unsigned long addr, int numpages)
>>>   {
>>>         return change_memory_common(addr, numpages,
>>>                                         __pgprot(0),
>>> -                                       __pgprot(PTE_PXN));
>>> +                                       __pgprot(PTE_PXN),
>>> +                                       false);
>>>   }
>>>   EXPORT_SYMBOL_GPL(set_memory_x);
>>> +
>>> +#ifdef CONFIG_DEBUG_PAGEALLOC
>>> +void __kernel_map_pages(struct page *page, int numpages, int enable)
>>> +{
>>> +       unsigned long addr = (unsigned long) page_address(page);
>>> +
>>> +       if (enable)
>>> +               change_memory_common(addr, numpages,
>>> +                                       __pgprot(PTE_VALID),
>>> +                                       __pgprot(0),
>>> +                                       true);
>>> +       else
>>> +               change_memory_common(addr, numpages,
>>> +                                       __pgprot(0),
>>> +                                       __pgprot(PTE_VALID),
>>> +                                       true);
>>> +}
>>> +#endif
>>> --
>>> 2.5.0
>>>
>


From Minghuan.Lian at nxp.com  Tue Feb  2 01:00:47 2016
From: Minghuan.Lian at nxp.com (Minghuan Lian)
Date: Tue, 2 Feb 2016 17:00:47 +0800
Subject: [PATCH 1/2 v3] dt/bindings: Add bindings for Layerscape SCFG MSI
Message-ID: <1454403648-5551-1-git-send-email-Minghuan.Lian@nxp.com>

Some Layerscape SoCs use a simple MSI controller implementation.
It contains only two SCFG register to trigger and describe a
group 32 MSI interrupts. The patch adds bindings to describe
the controller.

Signed-off-by: Minghuan Lian <Minghuan.Lian at nxp.com>
---
 .../interrupt-controller/fsl,ls-scfg-msi.txt       | 23 ++++++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt

diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt
new file mode 100644
index 0000000..0c41151
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt
@@ -0,0 +1,23 @@
+* Freescale Layerscape SCFG PCIe MSI controller
+
+Required properties:
+
+- compatible: should be "fsl,<soc-name>-msi" to identify
+	      Layerscape PCIe MSI controller block such as:
+              "fsl,1s1021a-msi"
+              "fsl,1s1043a-msi"
+- msi-controller: indicates that this is a PCIe MSI controller node
+- reg: physical base address of the controller and length of memory mapped.
+- interrupts: A interrupt of the controller.
+
+Each PCIe node needs to have property msi-parent that points to
+MSI controller node
+
+Examples:
+
+	msi1: msi-controller at 1571000 {
+		compatible = "fsl,1s1043a-msi";
+		reg = <0x0 0x1571000 0x0 0x8>,
+		msi-controller;
+		interrupts = <0 116 0x4>;
+	};
-- 
1.9.1



From Minghuan.Lian at nxp.com  Tue Feb  2 01:00:48 2016
From: Minghuan.Lian at nxp.com (Minghuan Lian)
Date: Tue, 2 Feb 2016 17:00:48 +0800
Subject: [PATCH 2/2 v3] irqchip/Layerscape: Add SCFG MSI controller support
In-Reply-To: <1454403648-5551-1-git-send-email-Minghuan.Lian@nxp.com>
References: <1454403648-5551-1-git-send-email-Minghuan.Lian@nxp.com>
Message-ID: <1454403648-5551-2-git-send-email-Minghuan.Lian@nxp.com>

Some kind of NXP Layerscape SoC provides a MSI
implementation which uses two SCFG registers MSIIR and
MSIR to support 32 MSI interrupts for each PCIe controller.
The patch is to support it.

Signed-off-by: Minghuan Lian <Minghuan.Lian at nxp.com>
---

Change log
v3:
1. call of_node_to_fwnode()
v2:
1. rename ls1-msi to ls-scfg-msi
2. remove reg-names MSIIR MSIR 
3. remove calling set_irq_flags()

 drivers/irqchip/Kconfig           |   5 +
 drivers/irqchip/Makefile          |   1 +
 drivers/irqchip/irq-ls-scfg-msi.c | 244 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 250 insertions(+)
 create mode 100644 drivers/irqchip/irq-ls-scfg-msi.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index fb50911..0f2a3c3 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -218,3 +218,8 @@ config IRQ_MXS
 	def_bool y if MACH_ASM9260 || ARCH_MXS
 	select IRQ_DOMAIN
 	select STMP_DEVICE
+
+config LS_SCFG_MSI
+	def_bool y if SOC_LS1021A || ARCH_LAYERSCAPE
+	depends on PCI && PCI_MSI
+	select PCI_MSI_IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 18caacb..37e12de 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -59,3 +59,4 @@ obj-$(CONFIG_ARCH_SA1100)		+= irq-sa11x0.o
 obj-$(CONFIG_INGENIC_IRQ)		+= irq-ingenic.o
 obj-$(CONFIG_IMX_GPCV2)			+= irq-imx-gpcv2.o
 obj-$(CONFIG_PIC32_EVIC)		+= irq-pic32-evic.o
+obj-$(CONFIG_LS_SCFG_MSI)		+= irq-ls-scfg-msi.o
diff --git a/drivers/irqchip/irq-ls-scfg-msi.c b/drivers/irqchip/irq-ls-scfg-msi.c
new file mode 100644
index 0000000..f57a72c
--- /dev/null
+++ b/drivers/irqchip/irq-ls-scfg-msi.c
@@ -0,0 +1,244 @@
+/*
+ * NXP SCFG MSI(-X) support
+ *
+ * Copyright (C) 2016 NXP Semiconductor.
+ *
+ * Author: Minghuan Lian <Minghuan.Lian at nxp.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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/msi.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/spinlock.h>
+
+#define MSI_MAX_IRQS	32
+#define MSI_IBS_SHIFT	3
+#define MSIR		4
+
+struct ls_scfg_msi {
+	spinlock_t		lock;
+	struct platform_device	*pdev;
+	struct irq_domain	*parent;
+	struct irq_domain	*msi_domain;
+	void __iomem		*regs;
+	phys_addr_t		msiir_addr;
+	u32			nr_irqs;
+	int			irq;
+	DECLARE_BITMAP(used, MSI_MAX_IRQS);
+};
+
+static struct irq_chip ls_scfg_msi_irq_chip = {
+	.name = "MSI",
+	.irq_enable	= pci_msi_unmask_irq,
+	.irq_disable	= pci_msi_mask_irq,
+	.irq_mask	= pci_msi_mask_irq,
+	.irq_unmask	= pci_msi_unmask_irq,
+};
+
+static struct msi_domain_info ls_scfg_msi_domain_info = {
+	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS |
+		   MSI_FLAG_USE_DEF_CHIP_OPS |
+		   MSI_FLAG_PCI_MSIX),
+	.chip	= &ls_scfg_msi_irq_chip,
+};
+
+static void ls_scfg_msi_compose_msg(struct irq_data *data, struct msi_msg *msg)
+{
+	struct ls_scfg_msi *msi_data = irq_data_get_irq_chip_data(data);
+
+	msg->address_hi = upper_32_bits(msi_data->msiir_addr);
+	msg->address_lo = lower_32_bits(msi_data->msiir_addr);
+	msg->data = data->hwirq << MSI_IBS_SHIFT;
+}
+
+static int ls_scfg_msi_set_affinity(struct irq_data *irq_data,
+				    const struct cpumask *mask, bool force)
+{
+	return -EINVAL;
+}
+
+static struct irq_chip ls_scfg_msi_parent_chip = {
+	.name			= "LS SCFG MSI",
+	.irq_compose_msi_msg	= ls_scfg_msi_compose_msg,
+	.irq_set_affinity	= ls_scfg_msi_set_affinity,
+};
+
+static int ls_scfg_msi_domain_irq_alloc(struct irq_domain *domain,
+					unsigned int virq,
+					unsigned int nr_irqs,
+					void *args)
+{
+	struct ls_scfg_msi *msi_data = domain->host_data;
+	int pos, err = 0;
+
+	WARN_ON(nr_irqs != 1);
+
+	spin_lock(&msi_data->lock);
+	pos = find_first_zero_bit(msi_data->used, msi_data->nr_irqs);
+	if (pos < msi_data->nr_irqs)
+		__set_bit(pos, msi_data->used);
+	else
+		err = -ENOSPC;
+	spin_unlock(&msi_data->lock);
+
+	if (err)
+		return err;
+
+	irq_domain_set_info(domain, virq, pos,
+			    &ls_scfg_msi_parent_chip, msi_data,
+			    handle_simple_irq, NULL, NULL);
+
+	return 0;
+}
+
+static void ls_scfg_msi_domain_irq_free(struct irq_domain *domain,
+				   unsigned int virq, unsigned int nr_irqs)
+{
+	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+	struct ls_scfg_msi *msi_data = irq_data_get_irq_chip_data(d);
+	int pos;
+
+	pos = d->hwirq;
+	if (pos < 0 || pos >= msi_data->nr_irqs) {
+		pr_err("failed to teardown msi. Invalid hwirq %d\n", pos);
+		return;
+	}
+
+	spin_lock(&msi_data->lock);
+	__clear_bit(pos, msi_data->used);
+	spin_unlock(&msi_data->lock);
+}
+
+static const struct irq_domain_ops ls_scfg_msi_domain_ops = {
+	.alloc	= ls_scfg_msi_domain_irq_alloc,
+	.free	= ls_scfg_msi_domain_irq_free,
+};
+
+static void ls_scfg_msi_irq_handler(struct irq_desc *desc)
+{
+	struct ls_scfg_msi *msi_data = irq_desc_get_handler_data(desc);
+	unsigned long val;
+	int pos, virq;
+
+	chained_irq_enter(irq_desc_get_chip(desc), desc);
+
+	val = ioread32be(msi_data->regs + MSIR);
+	for_each_set_bit(pos, &val, msi_data->nr_irqs) {
+		virq = irq_find_mapping(msi_data->parent, (31 - pos));
+		if (virq)
+			generic_handle_irq(virq);
+	}
+
+	chained_irq_exit(irq_desc_get_chip(desc), desc);
+}
+
+static int ls_scfg_msi_domains_init(struct ls_scfg_msi *msi_data)
+{
+	/* Initialize MSI domain parent */
+	msi_data->parent = irq_domain_add_linear(NULL,
+						 msi_data->nr_irqs,
+						 &ls_scfg_msi_domain_ops,
+						 msi_data);
+	if (!msi_data->parent) {
+		dev_err(&msi_data->pdev->dev, "failed to create IRQ domain\n");
+		return -ENOMEM;
+	}
+
+	msi_data->msi_domain = pci_msi_create_irq_domain(
+				of_node_to_fwnode(msi_data->pdev->dev.of_node),
+				&ls_scfg_msi_domain_info,
+				msi_data->parent);
+	if (!msi_data->msi_domain) {
+		dev_err(&msi_data->pdev->dev, "failed to create MSI domain\n");
+		irq_domain_remove(msi_data->parent);
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+static int ls_scfg_msi_probe(struct platform_device *pdev)
+{
+	struct ls_scfg_msi *msi_data;
+	struct resource *res;
+	int ret;
+
+	msi_data = devm_kzalloc(&pdev->dev, sizeof(*msi_data), GFP_KERNEL);
+	if (!msi_data)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	msi_data->regs = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(msi_data->regs)) {
+		dev_err(&pdev->dev, "failed to initialize 'regs'\n");
+		return PTR_ERR(msi_data->regs);
+	}
+	msi_data->msiir_addr = res->start;
+
+	msi_data->irq = platform_get_irq(pdev, 0);
+	if (msi_data->irq <= 0) {
+		dev_err(&pdev->dev, "failed to get MSI irq\n");
+		return -ENODEV;
+	}
+
+	msi_data->pdev = pdev;
+	msi_data->nr_irqs = MSI_MAX_IRQS;
+	spin_lock_init(&msi_data->lock);
+
+	ret = ls_scfg_msi_domains_init(msi_data);
+	if (ret)
+		return ret;
+
+	irq_set_chained_handler_and_data(msi_data->irq,
+					 ls_scfg_msi_irq_handler,
+					 msi_data);
+
+	platform_set_drvdata(pdev, msi_data);
+
+	return 0;
+}
+
+static int ls_scfg_msi_remove(struct platform_device *pdev)
+{
+	struct ls_scfg_msi *msi_data = platform_get_drvdata(pdev);
+
+	irq_set_chained_handler_and_data(msi_data->irq, NULL, NULL);
+
+	irq_domain_remove(msi_data->msi_domain);
+	irq_domain_remove(msi_data->parent);
+
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static const struct of_device_id ls_scfg_msi_id[] = {
+	{ .compatible = "fsl,1s1021a-msi", },
+	{ .compatible = "fsl,1s1043a-msi", },
+	{},
+};
+
+static struct platform_driver ls_scfg_msi_driver = {
+	.driver = {
+		.name = "ls-scfg-msi",
+		.of_match_table = ls_scfg_msi_id,
+	},
+	.probe = ls_scfg_msi_probe,
+	.remove = ls_scfg_msi_remove,
+};
+
+module_platform_driver(ls_scfg_msi_driver);
+
+MODULE_AUTHOR("Minghuan Lian <Minghuan.Lian at nxp.com>");
+MODULE_DESCRIPTION("NXP Layerscape SCFG MSI controller driver");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1



From maxime.ripard at free-electrons.com  Tue Feb  2 01:15:05 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 10:15:05 +0100
Subject: [PATCH] ARM: dts: sun9i: a80-optimus: Remove i2c3 and uart4
In-Reply-To: <1454338798-5929-1-git-send-email-wens@csie.org>
References: <1454338798-5929-1-git-send-email-wens@csie.org>
Message-ID: <20160202091505.GK4652@lukather>

On Mon, Feb 01, 2016 at 10:59:58PM +0800, Chen-Yu Tsai wrote:
> i2c3 and uart4 are available on the GPIO header. Though these pins only
> have this one special function, the user may choose to use them as GPIOs
> instead.
> 
> Since our policy is not to choose what function to present on the GPIO
> headers of development boards, remove them.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/1c2698e5/attachment-0001.sig>

From leo.yan at linaro.org  Tue Feb  2 01:22:32 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Tue, 2 Feb 2016 17:22:32 +0800
Subject: [PATCH v5 1/4] dt-bindings: mailbox: Document Hi6220 mailbox
 driver
In-Reply-To: <CABb+yY0uY--40CJ6_U-AcbZ1cRUhs7MhiJZn_G-Suw=XKXdpjg@mail.gmail.com>
References: <1454333687-20421-1-git-send-email-leo.yan@linaro.org>
 <1454333687-20421-2-git-send-email-leo.yan@linaro.org>
 <20160201140828.GA32412@rob-hp-laptop>
 <20160201152333.GA22872@leoy-linaro>
 <CABb+yY0uY--40CJ6_U-AcbZ1cRUhs7MhiJZn_G-Suw=XKXdpjg@mail.gmail.com>
Message-ID: <20160202092232.GB1915@leoy-linaro>

On Mon, Feb 01, 2016 at 09:46:39PM +0530, Jassi Brar wrote:
> On Mon, Feb 1, 2016 at 8:53 PM, Leo Yan <leo.yan at linaro.org> wrote:
> > On Mon, Feb 01, 2016 at 08:08:28AM -0600, Rob Herring wrote:
> >> On Mon, Feb 01, 2016 at 09:34:44PM +0800, Leo Yan wrote:

[...]

> >> > +Optional Properties:
> >> > +--------------------
> >> > +- hi6220,mbox-tx-noirq: Flag to allow the client user of this mailbox driver
> >> > +                   to send messages without triggering a TX completion
> >> > +                   interrupt.
> >>
> >> I don't think this belongs in DT. This should be a flag the client
> >> driver sets when it sends messages.
> >
> > The client driver can set "tx_block = true" so use this flag indicates
> > the client thread should be blocked until data is transmitted.
> >
> Yes, but the 'tx_block' feature is provided by the core. The
> controller driver should not need to know how the client works.
> 
> > But low level mailbox driver can use two method to support "tx_block"
> > mode:
> >
> No, as I said, provider shouldn't care about consumers..
> 
> > - One method is to avoid using interrupt and mailbox framework will
> >   poll with mailbox's idle flag which is set by remote processor
> >   automatically;
> > - Another method is to use interrupt to notify data has been
> >   transmitted and interrupt handler will call completion function to
> >   wake up blocked client thread;
> >
> If it is possible to have either 'idle flag set' or irq generated (not
> both) by the remote, then you may sell the hi6220,mbox-tx-noirq
> property as a "f/w feature" ... but still not for the sake of
> tx_block.

Indeed and totally agree. MCU can support two modes for "automatic idle
flag" or IRQ generated mode, so we can take "hi6220,mbox-tx-noirq" as a
firmware's property.

> >> > +
> >> > +Child Nodes:
> >> > +============
> >> > +A child node is used for representing the actual sub-mailbox device that is
> >> > +used for the communication between the host processor and a remote processor.
> >> > +Each child node should have a unique node name across all the different
> >> > +mailbox device nodes.
> >> > +
> >> > +Required properties:
> >> > +--------------------
> >> > +- hi6220,mbox-tx:  sub-mailbox descriptor property defining Tx channel
> >> > +- hi6220,mbox-rx:  sub-mailbox descriptor property defining Rx channel
> >> > +
> >> > +Sub-mailbox Descriptor Data
> >> > +---------------------------
> >> > +Each of the above hi6220,mbox-tx and hi6220,mbox-rx properties should have 3
> >> > +cells of data that represent the following:
> >> > +    Cell #1 (slot_id) - mailbox slot id used either for transmitting
> >> > +                        (hi6220,mbox-tx) or for receiving (hi6220,mbox-rx)
> >> > +    Cell #2 (dst_irq) - irq identifier index number which used by MCU.
> >> > +    Cell #3 (ack_irq) - irq identifier index number with generating a tx/rx
> >> > +                        interrupt to application processor, mailbox driver
> >> > +                        used this id to acknowledge interrupt.
> >> > +
> >> > +Example:
> >> > +--------
> >> > +
> >> > +   mailbox: mailbox at F7510000 {
> >> > +           #mbox-cells = <1>;
> >> > +           compatible = "hisilicon,hi6220-mbox";
> >> > +           reg = <0x0 0xF7510000 0x0 0x1000>, /* IPC_S */
> >> > +                 <0x0 0x06DFF800 0x0 0x0800>; /* Mailbox */
> >> > +           interrupt-parent = <&gic>;
> >> > +           interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
> >> > +           mbox_stub_clock: mbox_stub_clock {
> >> > +                   hi6220,mbox-rx = <0 1 10>;
> >> > +                   hi6220,mbox-tx = <1 0 11>;
> >
> This looks like meant for the client node...
>          mbox-names = "mbox-tx", "mbox-rx";
>          mboxes = <&mailbox 1 0 11>, <&mailbox 0 1 10>;

Good suggestion. Will refine with this way.

Thanks,
Leo Yan


From k at japko.eu  Tue Feb  2 01:24:52 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Tue, 2 Feb 2016 10:24:52 +0100
Subject: [PATCH] pinctrl: sunxi: Add H3 R_PIO controller support
In-Reply-To: <CAGb2v65-X2_MoRm1=wAub9Y8Vpt-f-roYUT73jDk5Fnj17zKTw@mail.gmail.com>
References: <20160201101225.GA19687@box2.japko.eu>
 <CAGb2v65-X2_MoRm1=wAub9Y8Vpt-f-roYUT73jDk5Fnj17zKTw@mail.gmail.com>
Message-ID: <20160202092451.GA26944@box2.japko.eu>

On Tue, Feb 02, 2016 at 02:25:18PM +0800, Chen-Yu Tsai wrote:
>On Mon, Feb 1, 2016 at 6:12 PM, Krzysztof Adamski <k at japko.eu> wrote:
>> - reg: Should contain the register physical address and length for 
>> the
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index 1524130e..745f64c 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -493,5 +493,17 @@
>>                         interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
>>                                      <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
>>                 };
>> +
>> +               r_pio: pinctrl at 01f02c00 {
>> +                       compatible = "allwinner,sun8i-h3-r-pinctrl";
>> +                       reg = <0x01f02c00 0x400>;
>> +                       interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
>> +                       clocks = <&bus_gates 69>;
>
>This is probably wrong. According to other SoCs all R_ block peripherals
>have clock gates and reset controls in the PRCM.

This is problematic. I can find information about reset and gates control for
this peripheral on other SoCs user manuals but there is nothing about it in H3
User Manual
(https://www.dropbox.com/s/nkr9slo1o9x6i1z/Allwinner_H3_Datasheet_V1.1.pdf?dl=0).

Similarly, while I think I can find r_pio clock setup for A33:
https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw5.c

I can't find it for H3, though:
https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw7.c

Well, apart from this strange snippet:

// binder r-pio CPUS_APB0_GATE to pio-clk's gate-reset-register
    clk = clk_get(NULL,"pio");
    if(!clk || IS_ERR(clk))
        printk("Error not get clk pio\n");
    else
    {
        struct clk_hw *hw = __clk_get_hw(clk);
        struct sunxi_clk_periph *periph = to_clk_periph(hw);
        struct sunxi_clk_periph_gate *gate = &periph->gate;
        gate->reset = sunxi_clk_cpus_base+CPUS_APB0_GATE ;
        gate->rst_shift = 0;
        clk_put(clk);
    }


Which I have to admit I don't fully understand. This seems to be setting reset
line for first pio, not for r_pio - something we don't have right now. Or am I
wrong here?

I'm new to Allwinner SoCs, any help from veterans?

Also, if that proves anything, I did test this code on OrangePi PC and PL ports
works so their clock is enabled, for sure.

Best regards,
Krzysztof Adamski


From arnd at arndb.de  Tue Feb  2 01:32:07 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 02 Feb 2016 10:32:07 +0100
Subject: [PATCH 1/4] ARM: dts: ls1021a: add PCIe dts node
In-Reply-To: <VI1PR04MB1615DCF54369ED2E01234E64E8DF0@VI1PR04MB1615.eurprd04.prod.outlook.com>
References: <1454401807-28751-1-git-send-email-Minghuan.Lian@nxp.com>
 <VI1PR04MB1615DCF54369ED2E01234E64E8DF0@VI1PR04MB1615.eurprd04.prod.outlook.com>
Message-ID: <6117401.iajrHOL4Mn@wuerfel>

On Tuesday 02 February 2016 08:48:36 Minghuan Lian wrote:
> Hi Shawn,
> 
> Could you please help to review the patch?  Thank you very much.
> There is only one patch not a set of patch, please ignore [1/4] 
> 
> Arnd has given a ack.

For some reason, I did not get the other three patches though,
I was going to look at them, but I can't tell if this was a series
of patches doing PCI support, or patches doing other dts changes.

If you have additional patches for the PCI driver, let's review
it all together first.

	Arnd


From ivo.g.dimitrov.75 at gmail.com  Tue Feb  2 01:33:08 2016
From: ivo.g.dimitrov.75 at gmail.com (Ivaylo Dimitrov)
Date: Tue, 2 Feb 2016 11:33:08 +0200
Subject: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
In-Reply-To: <20160121091437.GT7192@pali>
References: <20160106174713.GL12777@atomide.com> <568D5669.4040801@gmail.com>
 <20160106182650.GM12777@atomide.com> <568D5F54.7040900@gmail.com>
 <20160107180700.GN12777@atomide.com> <568EDC8D.7070205@gmail.com>
 <20160108022619.GS12777@atomide.com> <568F4596.8020206@gmail.com>
 <20160108075913.GN11364@pali> <569052FE.1040008@gmail.com>
 <20160121091437.GT7192@pali>
Message-ID: <56B077D4.3030902@gmail.com>


Hi,

On 21.01.2016 11:14, Pali Roh?r wrote:
> On Saturday 09 January 2016 02:23:26 Ivaylo Dimitrov wrote:
>> Hi,
>>
>> On  8.01.2016 09:59, Pali Roh?r wrote:
>>> On Friday 08 January 2016 07:13:58 Ivaylo Dimitrov wrote:
>>>> And it looks like the problems happens sometimes on oops too.
>>>
>>> In linux-n900 tree is enabled mtdoops driver which store oops to
>>> specified MTD device. So maybe this access cause it?
>>>
>>
>> The key word here is "sometimes". i.e sometimes it hapens on normal reboot,
>> sometimes it happens on oops.
>
> So where is problem? In omap-gpmc? mtd? onenand? or ubifs? Or in
> different component? Do we know at least this?
>

I think I made some progress on the issue, it seems I have to have 
*both* e7b11dc7b77bfce0a351230a5feeadc1d0bba997 
(e7b11dc7b77bfce0a351230a5feeadc1d0bba997) reverted *and* 
HWMOD_INIT_NO_RESET restored in omap3xxx_gpmc_hwmod flags to have 
working onenand.

Tony, shall I hardcode GPMC_CS_CONFIG4 OEONTIME to be the same as NOLO's 
or it does not make sense?

Regards,
Ivo


From wdc at rock-chips.com  Tue Feb  2 01:38:43 2016
From: wdc at rock-chips.com (David.Wu)
Date: Tue, 2 Feb 2016 17:38:43 +0800
Subject: [PATCH] PM / AVS: rockchip-io: add GRF and PMUGRF types to
 distinguish
In-Reply-To: <5354361.hQXgJ7cEGx@diego>
References: <1454155305-55516-1-git-send-email-david.wu@rock-chips.com>
 <5387650.lAgTxexlF2@phil> <56AF1D4E.40307@rock-chips.com>
 <5354361.hQXgJ7cEGx@diego>
Message-ID: <56B07923.9020900@rock-chips.com>

Hi Heiko,

? 2016/2/2 5:17, Heiko St?bner ??:
> Hi David,
>
> Am Montag, 1. Februar 2016, 16:54:38 schrieb David.Wu:
>> ? 2016/1/30 20:39, Heiko Stuebner ??:
>>> Am Samstag, 30. Januar 2016, 20:01:45 schrieb David Wu:
>>>> As rk3368 contained two separated iodomain areas, this was
>>>> determined to use which regmap base address.
>>>>
>>>> Signed-off-by: David Wu <david.wu at rock-chips.com>
>>> I don't think we need to specify this on a driver level. Both GRF areas
>>> are
>>> "General register files" only located in two separate power-domains.
>>> So the rockchip,grf property should work for both. Especially as nothing
>>> keeps designers from introducing yet another GRF-area somewhere else ;-)
>>>
>>> >From when I started working on the rk3368, I still have a preliminary
>>>
>>> patches for that sitting here, so I've attached on how I envisoned that to
>>> work.
>> Okay, i agree to you, but it make someone a little confused just from
>> the drive code,
>> not DT file,  about  pmugrf regmap base address.:-)
>>
>> How do you feel about intergating GRF and PMU drivers in one driver?
>> Thanks!
> I will very strongly disagree here ;-) .
> Similar to the power-domains being part of the pmu, the io-domains are
> part of their individual GRFs. So if you want it really clean and tidy the way
> to go foward will be the attached patches. Compile-tested only.

Thanks for your reply, the patchs look better than mine.
I have tested them on sdk board and i found something may be wrong.
"parent->of_node" instead of "parent", as the parent is not null if 
parent-node not used.
         if (parent->of_node) {
             iod->grf = syscon_node_to_regmap(parent->of_node);
         } else {
             dev_dbg(&pdev->dev, "falling back to old binding\n");
             iod->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
         }

> Other things like the usbphy control should move there as well in the long
> run. But that's not immediate necessary.
>
>
> Heiko




From maxime.ripard at free-electrons.com  Tue Feb  2 01:44:07 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 10:44:07 +0100
Subject: [PATCH 03/11] drivers: rtc: allow compilation of sun6i RTC for
 all sunxi SoCs
In-Reply-To: <1454348370-3816-4-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-4-git-send-email-andre.przywara@arm.com>
Message-ID: <20160202094407.GL4652@lukather>

On Mon, Feb 01, 2016 at 05:39:22PM +0000, Andre Przywara wrote:
> At the moment the "sun6i" RTC drivers depends on having two specific
> SoC families selected.
> The Allwinner A64 SoC has the same RTC, so extend the Kconfig option
> to allow inclusion of the driver for all Allwinner SoCs.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>

Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/52e72ac3/attachment-0001.sig>

From marc.zyngier at arm.com  Tue Feb  2 01:46:05 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 2 Feb 2016 09:46:05 +0000
Subject: [PATCH v2 10/21] arm64: KVM: VHE: Split save/restore of sysregs
 shared between EL1 and EL2
In-Reply-To: <20160201135438.GL1478@cbox>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-11-git-send-email-marc.zyngier@arm.com>
 <20160201135438.GL1478@cbox>
Message-ID: <56B07ADD.60300@arm.com>

On 01/02/16 13:54, Christoffer Dall wrote:
> On Mon, Jan 25, 2016 at 03:53:44PM +0000, Marc Zyngier wrote:
>> A handful of system registers are still shared between EL1 and EL2,
>> even while using VHE. These are tpidr*_el[01], actlr_el1, sp0, elr,
>> and spsr.
> 
> So by shared registers you mean registers that do both have an EL0/1
> version as well as an EL2 version, but where accesses aren't rewritten
> transparently?

No, I mean that these registers do *not* have a separate banked version.
There is only a single set of registers, which have to be save/restored
the old way.

> 
> also, by sp0 do you mean sp_el0, and by elr you mean elr_el1, and by
> spsr you mean spsr_el1 ?

sp0 -> sp_el0 indeed. elr and spsr really are the guest PC and PSTATE,
so I should really reword this commit message, it is utterly confusing.

> 
>>
>> In order to facilitate the introduction of a VHE-specific sysreg
>> save/restore, make move the access to these registers to their
>> own save/restore functions.
>>
>> No functionnal change.
> 
> Otherwise:
> 
> Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From andy.yan at rock-chips.com  Tue Feb  2 01:56:21 2016
From: andy.yan at rock-chips.com (Andy Yan)
Date: Tue,  2 Feb 2016 17:56:21 +0800
Subject: [PATCH v3 0/4] add reboot mode driver
Message-ID: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>


This driver parse the reboot commands like "reboot loader"
and "reboot recovery" to get a boot mode described in the
device tree , then call the corresponding  write interfae
to store the boot mode in some place like special register
or ram , which can be read by the bootloader after system
reboot.

This is commonly done on Android based devices, in order to
reboot the device into fastboot or recovery mode.

Changes in v3:
- descirbe all reboot mode as properity instead of subnode
- add mask value for some platform which only use some bits of the register
  to store boot mode magic value
- add rk3036 support

Changes in v2:
- move to dir drivers/power/reset/
- make syscon-reboot-mode a generic driver
- make this node as a subnode of PMU
- make this node as a subnode of pmugrf

Changes in v1:
- fix the embarrassed compile warning
- correct the maskrom magic number
- check for the normal reboot
- correct the maskrom magic number
- use macro defined in rockchip_boot-mode.h for reboot-mode DT node

Andy Yan (4):
  dt-bindings: power: reset: add document for reboot-mode driver
  power: reset: add reboot mode driver
  ARM: dts: rockchip: add syscon-reboot-mode node
  ARM64: dts: rockchip: add syscon-reboot-mode DT node

 .../bindings/power/reset/reboot-mode.txt           |  26 +++++
 .../bindings/power/reset/syscon-reboot-mode.txt    |  36 +++++++
 arch/arm/boot/dts/rk3036.dtsi                      |  10 +-
 arch/arm/boot/dts/rk3288.dtsi                      |  11 +++
 arch/arm/boot/dts/rk3xxx.dtsi                      |  13 ++-
 arch/arm64/boot/dts/rockchip/rk3368.dtsi           |  14 ++-
 drivers/power/reset/Kconfig                        |  16 ++++
 drivers/power/reset/Makefile                       |   2 +
 drivers/power/reset/reboot-mode.c                  | 105 +++++++++++++++++++++
 drivers/power/reset/reboot-mode.h                  |   6 ++
 drivers/power/reset/syscon-reboot-mode.c           |  64 +++++++++++++
 include/dt-bindings/soc/rockchip_boot-mode.h       |  30 ++++++
 12 files changed, 330 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/reset/reboot-mode.txt
 create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
 create mode 100644 drivers/power/reset/reboot-mode.c
 create mode 100644 drivers/power/reset/reboot-mode.h
 create mode 100644 drivers/power/reset/syscon-reboot-mode.c
 create mode 100644 include/dt-bindings/soc/rockchip_boot-mode.h

-- 
1.9.1




From horms at verge.net.au  Tue Feb  2 01:58:37 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Feb 2016 10:58:37 +0100
Subject: [PATCH v4 0/7] ARM: dts: R-Car: Add SCIF fallback compatibility
 strings
In-Reply-To: <1454059928-975-1-git-send-email-geert+renesas@glider.be>
References: <1454059928-975-1-git-send-email-geert+renesas@glider.be>
Message-ID: <20160202095836.GB15554@verge.net.au>

On Fri, Jan 29, 2016 at 10:32:01AM +0100, Geert Uytterhoeven wrote:
> 	Hi Simon, Magnus,
> 
> This patch series adds fallback compatibility strings for SCIF, HSCIF,
> SCIFA, and SCIFB to the dtsi files for R-Car Gen1, Gen2, and Gen3 SoCs.
> These fallback compatibility strings have been accepted in the DT
> bindings in v4.5-rc1.
> 
> This will allow the sh-sci driver to match on family-specific compatible
> values, to enable support for the Baud Rate Generator for External Clock
> (BRG) on (H)SCIF later.
> 
> Changes compared to v3:
>   - Changed one-line summary prefix to match current arm-soc practices,
>   - Rebased on top of renesas-devel-20160129-v4.5-rc1.
> 
> Thanks for applying!

Thanks, I have queue them up.


From maxime.ripard at free-electrons.com  Tue Feb  2 02:00:46 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 11:00:46 +0100
Subject: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
In-Reply-To: <56AFE0EC.8080207@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-6-git-send-email-andre.przywara@arm.com>
 <20160201182754.GA14737@excalibur.cnev.de>
 <56AFE0EC.8080207@arm.com>
Message-ID: <20160202100046.GM4652@lukather>

Hi Andre,

On Mon, Feb 01, 2016 at 10:49:16PM +0000, Andr? Przywara wrote:
> On 01/02/16 18:27, Karsten Merker wrote:
> 
> Hi Karsten,
> 
> thank you very much for your feedback!
> 
> > On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote:
> >> Based on the Allwinner A64 user manual and on the previous sunxi
> >> pinctrl drivers this introduces the pin multiplex assignments for
> >> the ARMv8 Allwinner A64 SoC.
> >> Port A is apparently used for the fixed function DRAM controller, so
> >> the ports start at B here (the manual mentions "n from 1 to 7", so
> >> not starting at 0).
> >>
> >> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> >> ---
> >>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
> >>  arch/arm64/Kconfig.platforms                       |   1 +
> >>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
> >>  drivers/pinctrl/sunxi/Makefile                     |   1 +
> >>  drivers/pinctrl/sunxi/pinctrl-a64.c                | 606 +++++++++++++++++++++
> >>  5 files changed, 613 insertions(+)
> >>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c
> >>
> >> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> >> index 9213b27..9050002 100644
> >> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> >> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> >> @@ -21,6 +21,7 @@ Required properties:
> >>    "allwinner,sun9i-a80-r-pinctrl"
> >>    "allwinner,sun8i-a83t-pinctrl"
> >>    "allwinner,sun8i-h3-pinctrl"
> >> +  "allwinner,a64-pinctrl"
> > 
> > Hello,
> > 
> > on all other Allwinner SoCs we use the SoC family as part of the
> > compatible, as well as in the names of the Kconfig options. To
> > keep things consistent, I would like to propose doing the same on
> > Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of
> > allwinner,a64-pinctrl.
> 
> Yes, I have been told this already. However I don't like this idea so
> much, for the following reasons:
> a) It is mostly redundant. The actual SoC (marketing) name is unique,
> there is no sun6i-a20 or sun7i-a23.

At the same time, the family name is mostly valid too.

We do share some DTSI across some SoCs already by their family name
(sun5i.dtsi for the A10s/A13/R8, sun8i-a23-a33.dtsi for the A23 and
A33, etc.)

> b) It is not even helpful. If I got Maxime correctly, then the newer
> sunxi generation numbers depend on the ARM _cores_ used in the SoC,
> which is frankly the least interesting part from a Linux support
> perspective. I would see some sense if it would reflect the generation
> of IP blocks used, but so it is even more confusing to see that
> sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely
> different beast. The Allwinner marketing name tells you that, but the
> sunxi one does not.

The opposite can be said too.

The A31 is quite different from the A33, while the A83 is much closer
to the H3 than it is to the A80. Their marketing scheme is messy. In
all aspects. We have a scheme that worked, I'd really like to stick
with it.

> c) It is very confusing for people not dealing with it everyday. Just
> because I own a BananaPi I know that the A20 is sun7i, but I am totally
> lost when it comes to all the other names. And even now it took me about
> a minute to find the appropriate Wiki page which explains part of that
> story.
> d) Most importantly ;-): It kills TAB completion, unless you know the
> sunxi number, which is mostly not true as pointed out in c)

Both of these are true, but are about the DT filenames, and not the
compatibles. I'd agree with you on this one now that we have
per-vendor subfolders in boot/dts, but it was not the case before, and
I'm pretty sure that to anyone that is not aware of the Allwinner SoCs
names, having an A<number>.dtsi in arch/arm/boot/dts, it would be
about a Cortex-A<number>, and definitely not an SoC from some random
vendor.

So, droping it in the filenames, why not. But I'd really like to keep
the same compatible scheme.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/c857ab32/attachment.sig>

From andy.yan at rock-chips.com  Tue Feb  2 01:59:11 2016
From: andy.yan at rock-chips.com (Andy Yan)
Date: Tue,  2 Feb 2016 17:59:11 +0800
Subject: [PATCH v3 1/4] dt-bindings: power: reset: add document for
 reboot-mode driver
In-Reply-To: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
References: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
Message-ID: <1454407151-4751-1-git-send-email-andy.yan@rock-chips.com>

add device tree bindings document for reboot-mode driver

Signed-off-by: Andy Yan <andy.yan at rock-chips.com>

---

Changes in v3:
- descirbe all reboot mode as properity instead of subnode

Changes in v2: None
Changes in v1: None

 .../bindings/power/reset/reboot-mode.txt           | 26 ++++++++++++++++
 .../bindings/power/reset/syscon-reboot-mode.txt    | 36 ++++++++++++++++++++++
 2 files changed, 62 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/reset/reboot-mode.txt
 create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt

diff --git a/Documentation/devicetree/bindings/power/reset/reboot-mode.txt b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
new file mode 100644
index 0000000..517080f
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
@@ -0,0 +1,26 @@
+Generic reboot mode core map driver
+
+This driver get reboot mode arguments and call the write
+interface to stores the magic value in special register
+or ram . Then the bootloader can read it and take different
+action according the argument stored.
+
+All mode properties are vendor specific, it is a indication to tell
+the bootloder what to do when the system reboot, and should be named
+as mode-xxx = <magic> (xxx is mode name).
+
+- mode-normal: Normal reboot mode, system reboot with command "reboot".
+- mode-recovery: Android Recovery mode, it is a mode to format the device or update a new image.
+- mode-fastboot: Android fastboot mode, it's a mode to  re-flash partitions on the device.
+- mode-loader: A bootloader mode, it's a mode used to download image on Rockchip platform,
+	       usually used in development.
+- mode-maskrom: It's a mode to download bootloader on Rockchip platform.
+
+Example:
+	reboot-mode {
+		mode-normal = <BOOT_NORMAL>;
+		mode-recovery = <BOOT_RECOVERY>;
+		mode-fastboot = <BOOT_FASTBOOT>;
+		mode-loader = <BOOT_LOADER>;
+		mode-maskrom = <BOOT_MASKROM>;
+	}
diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
new file mode 100644
index 0000000..923c82b
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
@@ -0,0 +1,36 @@
+SYSCON reboot mode driver
+
+This driver get reboot mode magic value form reboot-mode driver
+and stores it in a SYSCON mapped register. Then the bootloader
+can read it and take different action according to the magic
+value stored.
+
+This DT node should be represented as a sub-node of a "syscon", "simple-mfd"
+node.
+
+Required properties:
+- compatible: should be "syscon-reboot-mode"
+- offset: offset in the register map for the storage register (in bytes)
+
+Optional properity:
+- mask: the mask bits of the mode magic value, default set to 0xffffffff if missing.
+
+The rest of the properties should follow the generic reboot-mode discription
+found in reboot-mode.txt
+
+Example:
+	pmu: pmu at 20004000 {
+		compatible = "rockchip,rk3066-pmu", "syscon", "simple-mfd";
+		reg = <0x20004000 0x100>;
+
+		reboot-mode {
+			compatible = "syscon-reboot-mode";
+			offset = <0x40>;
+			mode-normal = <BOOT_NORMAL>;
+			mode-recovery = <BOOT_RECOVERY>;
+			mode-fastboot = <BOOT_FASTBOOT>;
+			mode-loader = <BOOT_LOADER>;
+			mode-maskrom = <BOOT_MASKROM>;
+
+		};
+	};
-- 
1.9.1




From ping.bai at nxp.com  Tue Feb  2 02:01:34 2016
From: ping.bai at nxp.com (Bai Ping)
Date: Tue, 2 Feb 2016 18:01:34 +0800
Subject: [PATCH V3 1/5] clk: imx: Add clock support for imx6qp
Message-ID: <1454407298-15545-1-git-send-email-ping.bai@nxp.com>

most of the clock tree structures on i.MX6 Quad Plus are
same as on i.MX6Q. there still some differences between
these two SOCs. compared to the i.XM6Q, the differents of
clocks on i.MX6QP is mainly on:

1. New clock gate added to support the PRE and PRG modules
2. 24MHz OSC clock option added to the UART, IPG, ECSPI, and
   CAN clock roots.
3. MMDC channel 1 clock gate is now controllable.
4. clock gating added to the LDB_DIx_IPU clocks on i.MX6QP
5. EMI clock root divider fix
6. other updates fo CSCMRx, CSCDRx and CS2CDR registers.

detailed infomation, please refer to the i.MX6QP RM.

Signed-off-by: Bai Ping <ping.bai at nxp.com>
---

change for V3:
-- move the 'imx6qdl-clock.h' changes into this patch


 drivers/clk/imx/clk-imx6q.c               | 132 ++++++++++++++++++++++++------
 include/dt-bindings/clock/imx6qdl-clock.h |  16 +++-
 2 files changed, 120 insertions(+), 28 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index f0efc6f..02e1818 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -34,7 +34,9 @@ static const char *periph2_sels[]	= { "periph2_pre", "periph2_clk2", };
 static const char *axi_sels[]		= { "periph", "pll2_pfd2_396m", "periph", "pll3_pfd1_540m", };
 static const char *audio_sels[]	= { "pll4_audio_div", "pll3_pfd2_508m", "pll3_pfd3_454m", "pll3_usb_otg", };
 static const char *gpu_axi_sels[]	= { "axi", "ahb", };
+static const char *pre_axi_sels[]	= { "axi", "ahb", };
 static const char *gpu2d_core_sels[]	= { "axi", "pll3_usb_otg", "pll2_pfd0_352m", "pll2_pfd2_396m", };
+static const char *gpu2d_core_sels_2[]	= { "mmdc_ch0_axi", "pll3_usb_otg", "pll2_pfd1_594m", "pll3_pfd0_720m",};
 static const char *gpu3d_core_sels[]	= { "mmdc_ch0_axi", "pll3_usb_otg", "pll2_pfd1_594m", "pll2_pfd2_396m", };
 static const char *gpu3d_shader_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg", "pll2_pfd1_594m", "pll3_pfd0_720m", };
 static const char *ipu_sels[]		= { "mmdc_ch0_axi", "pll2_pfd2_396m", "pll3_120m", "pll3_pfd1_540m", };
@@ -44,15 +46,24 @@ static const char *ipu1_di0_sels[]	= { "ipu1_di0_pre", "dummy", "dummy", "ldb_di
 static const char *ipu1_di1_sels[]	= { "ipu1_di1_pre", "dummy", "dummy", "ldb_di0", "ldb_di1", };
 static const char *ipu2_di0_sels[]	= { "ipu2_di0_pre", "dummy", "dummy", "ldb_di0", "ldb_di1", };
 static const char *ipu2_di1_sels[]	= { "ipu2_di1_pre", "dummy", "dummy", "ldb_di0", "ldb_di1", };
+static const char *ipu1_di0_sels_2[]	= { "ipu1_di0_pre", "dummy", "dummy", "ldb_di0_podf", "ldb_di1_podf", };
+static const char *ipu1_di1_sels_2[]	= { "ipu1_di1_pre", "dummy", "dummy", "ldb_di0_podf", "ldb_di1_podf", };
+static const char *ipu2_di0_sels_2[]	= { "ipu2_di0_pre", "dummy", "dummy", "ldb_di0_podf", "ldb_di1_podf", };
+static const char *ipu2_di1_sels_2[]	= { "ipu2_di1_pre", "dummy", "dummy", "ldb_di0_podf", "ldb_di1_podf", };
 static const char *hsi_tx_sels[]	= { "pll3_120m", "pll2_pfd2_396m", };
 static const char *pcie_axi_sels[]	= { "axi", "ahb", };
 static const char *ssi_sels[]		= { "pll3_pfd2_508m", "pll3_pfd3_454m", "pll4_audio_div", };
 static const char *usdhc_sels[]	= { "pll2_pfd2_396m", "pll2_pfd0_352m", };
 static const char *enfc_sels[]	= { "pll2_pfd0_352m", "pll2_bus", "pll3_usb_otg", "pll2_pfd2_396m", };
+static const char *enfc_sels_2[] = {"pll2_pfd0_352m", "pll2_bus", "pll3_usb_otg", "pll2_pfd2_396m", "pll3_pfd3_454m", "dummy", };
 static const char *eim_sels[]		= { "pll2_pfd2_396m", "pll3_usb_otg", "axi", "pll2_pfd0_352m", };
 static const char *eim_slow_sels[]      = { "axi", "pll3_usb_otg", "pll2_pfd2_396m", "pll2_pfd0_352m", };
 static const char *vdo_axi_sels[]	= { "axi", "ahb", };
 static const char *vpu_axi_sels[]	= { "axi", "pll2_pfd2_396m", "pll2_pfd0_352m", };
+static const char *uart_sels[] = { "pll3_80m", "osc", };
+static const char *ipg_per_sels[] = { "ipg", "osc", };
+static const char *ecspi_sels[] = { "pll3_60m", "osc", };
+static const char *can_sels[] = { "pll3_60m", "osc", "pll3_80m", };
 static const char *cko1_sels[]	= { "pll3_usb_otg", "pll2_bus", "pll1_sys", "pll5_video_div",
 				    "dummy", "axi", "enfc", "ipu1_di0", "ipu1_di1", "ipu2_di0",
 				    "ipu2_di1", "ahb", "ipg", "ipg_per", "ckil", "pll4_audio_div", };
@@ -121,12 +132,19 @@ static unsigned int share_count_ssi2;
 static unsigned int share_count_ssi3;
 static unsigned int share_count_mipi_core_cfg;
 static unsigned int share_count_spdif;
+static unsigned int share_count_prg0;
+static unsigned int share_count_prg1;
 
 static inline int clk_on_imx6q(void)
 {
 	return of_machine_is_compatible("fsl,imx6q");
 }
 
+static inline int clk_on_imx6qp(void)
+{
+	return of_machine_is_compatible("fsl,imx6qp");
+}
+
 static inline int clk_on_imx6dl(void)
 {
 	return of_machine_is_compatible("fsl,imx6dl");
@@ -265,7 +283,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[IMX6QDL_CLK_TWD]       = imx_clk_fixed_factor("twd",       "arm",            1, 2);
 	clk[IMX6QDL_CLK_GPT_3M]    = imx_clk_fixed_factor("gpt_3m",    "osc",            1, 8);
 	clk[IMX6QDL_CLK_VIDEO_27M] = imx_clk_fixed_factor("video_27m", "pll3_pfd1_540m", 1, 20);
-	if (clk_on_imx6dl()) {
+	if (clk_on_imx6dl() || clk_on_imx6qp()) {
 		clk[IMX6QDL_CLK_GPU2D_AXI] = imx_clk_fixed_factor("gpu2d_axi", "mmdc_ch0_axi_podf", 1, 1);
 		clk[IMX6QDL_CLK_GPU3D_AXI] = imx_clk_fixed_factor("gpu3d_axi", "mmdc_ch0_axi_podf", 1, 1);
 	}
@@ -294,7 +312,15 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 		clk[IMX6QDL_CLK_GPU2D_AXI]        = imx_clk_mux("gpu2d_axi",        base + 0x18, 0,  1, gpu_axi_sels,      ARRAY_SIZE(gpu_axi_sels));
 		clk[IMX6QDL_CLK_GPU3D_AXI]        = imx_clk_mux("gpu3d_axi",        base + 0x18, 1,  1, gpu_axi_sels,      ARRAY_SIZE(gpu_axi_sels));
 	}
-	clk[IMX6QDL_CLK_GPU2D_CORE_SEL]   = imx_clk_mux("gpu2d_core_sel",   base + 0x18, 16, 2, gpu2d_core_sels,   ARRAY_SIZE(gpu2d_core_sels));
+	if (clk_on_imx6qp()) {
+		clk[IMX6QDL_CLK_CAN_SEL]   = imx_clk_mux("can_sel",	base + 0x20, 8,  2, can_sels, ARRAY_SIZE(can_sels));
+		clk[IMX6QDL_CLK_ECSPI_SEL] = imx_clk_mux("ecspi_sel",	base + 0x38, 18, 1, ecspi_sels,  ARRAY_SIZE(ecspi_sels));
+		clk[IMX6QDL_CLK_IPG_PER_SEL] = imx_clk_mux("ipg_per_sel", base + 0x1c, 6, 1, ipg_per_sels, ARRAY_SIZE(ipg_per_sels));
+		clk[IMX6QDL_CLK_UART_SEL] = imx_clk_mux("uart_sel", base + 0x24, 6, 1, uart_sels, ARRAY_SIZE(uart_sels));
+		clk[IMX6QDL_CLK_GPU2D_CORE_SEL] = imx_clk_mux("gpu2d_core_sel", base + 0x18, 16, 2, gpu2d_core_sels_2, ARRAY_SIZE(gpu2d_core_sels_2));
+	} else {
+		clk[IMX6QDL_CLK_GPU2D_CORE_SEL] = imx_clk_mux("gpu2d_core_sel",   base + 0x18, 16, 2, gpu2d_core_sels,   ARRAY_SIZE(gpu2d_core_sels));
+	}
 	clk[IMX6QDL_CLK_GPU3D_CORE_SEL]   = imx_clk_mux("gpu3d_core_sel",   base + 0x18, 4,  2, gpu3d_core_sels,   ARRAY_SIZE(gpu3d_core_sels));
 	clk[IMX6QDL_CLK_GPU3D_SHADER_SEL] = imx_clk_mux("gpu3d_shader_sel", base + 0x18, 8,  2, gpu3d_shader_sels, ARRAY_SIZE(gpu3d_shader_sels));
 	clk[IMX6QDL_CLK_IPU1_SEL]         = imx_clk_mux("ipu1_sel",         base + 0x3c, 9,  2, ipu_sels,          ARRAY_SIZE(ipu_sels));
@@ -305,22 +331,40 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[IMX6QDL_CLK_IPU1_DI1_PRE_SEL] = imx_clk_mux_flags("ipu1_di1_pre_sel", base + 0x34, 15, 3, ipu_di_pre_sels,   ARRAY_SIZE(ipu_di_pre_sels), CLK_SET_RATE_PARENT);
 	clk[IMX6QDL_CLK_IPU2_DI0_PRE_SEL] = imx_clk_mux_flags("ipu2_di0_pre_sel", base + 0x38, 6,  3, ipu_di_pre_sels,   ARRAY_SIZE(ipu_di_pre_sels), CLK_SET_RATE_PARENT);
 	clk[IMX6QDL_CLK_IPU2_DI1_PRE_SEL] = imx_clk_mux_flags("ipu2_di1_pre_sel", base + 0x38, 15, 3, ipu_di_pre_sels,   ARRAY_SIZE(ipu_di_pre_sels), CLK_SET_RATE_PARENT);
-	clk[IMX6QDL_CLK_IPU1_DI0_SEL]     = imx_clk_mux_flags("ipu1_di0_sel",     base + 0x34, 0,  3, ipu1_di0_sels,     ARRAY_SIZE(ipu1_di0_sels), CLK_SET_RATE_PARENT);
-	clk[IMX6QDL_CLK_IPU1_DI1_SEL]     = imx_clk_mux_flags("ipu1_di1_sel",     base + 0x34, 9,  3, ipu1_di1_sels,     ARRAY_SIZE(ipu1_di1_sels), CLK_SET_RATE_PARENT);
-	clk[IMX6QDL_CLK_IPU2_DI0_SEL]     = imx_clk_mux_flags("ipu2_di0_sel",     base + 0x38, 0,  3, ipu2_di0_sels,     ARRAY_SIZE(ipu2_di0_sels), CLK_SET_RATE_PARENT);
-	clk[IMX6QDL_CLK_IPU2_DI1_SEL]     = imx_clk_mux_flags("ipu2_di1_sel",     base + 0x38, 9,  3, ipu2_di1_sels,     ARRAY_SIZE(ipu2_di1_sels), CLK_SET_RATE_PARENT);
 	clk[IMX6QDL_CLK_HSI_TX_SEL]       = imx_clk_mux("hsi_tx_sel",       base + 0x30, 28, 1, hsi_tx_sels,       ARRAY_SIZE(hsi_tx_sels));
 	clk[IMX6QDL_CLK_PCIE_AXI_SEL]     = imx_clk_mux("pcie_axi_sel",     base + 0x18, 10, 1, pcie_axi_sels,     ARRAY_SIZE(pcie_axi_sels));
-	clk[IMX6QDL_CLK_SSI1_SEL]         = imx_clk_fixup_mux("ssi1_sel",   base + 0x1c, 10, 2, ssi_sels,          ARRAY_SIZE(ssi_sels), imx_cscmr1_fixup);
-	clk[IMX6QDL_CLK_SSI2_SEL]         = imx_clk_fixup_mux("ssi2_sel",   base + 0x1c, 12, 2, ssi_sels,          ARRAY_SIZE(ssi_sels), imx_cscmr1_fixup);
-	clk[IMX6QDL_CLK_SSI3_SEL]         = imx_clk_fixup_mux("ssi3_sel",   base + 0x1c, 14, 2, ssi_sels,          ARRAY_SIZE(ssi_sels), imx_cscmr1_fixup);
-	clk[IMX6QDL_CLK_USDHC1_SEL]       = imx_clk_fixup_mux("usdhc1_sel", base + 0x1c, 16, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels), imx_cscmr1_fixup);
-	clk[IMX6QDL_CLK_USDHC2_SEL]       = imx_clk_fixup_mux("usdhc2_sel", base + 0x1c, 17, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels), imx_cscmr1_fixup);
-	clk[IMX6QDL_CLK_USDHC3_SEL]       = imx_clk_fixup_mux("usdhc3_sel", base + 0x1c, 18, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels), imx_cscmr1_fixup);
-	clk[IMX6QDL_CLK_USDHC4_SEL]       = imx_clk_fixup_mux("usdhc4_sel", base + 0x1c, 19, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels), imx_cscmr1_fixup);
-	clk[IMX6QDL_CLK_ENFC_SEL]         = imx_clk_mux("enfc_sel",         base + 0x2c, 16, 2, enfc_sels,         ARRAY_SIZE(enfc_sels));
-	clk[IMX6QDL_CLK_EIM_SEL]          = imx_clk_fixup_mux("eim_sel",      base + 0x1c, 27, 2, eim_sels,        ARRAY_SIZE(eim_sels), imx_cscmr1_fixup);
-	clk[IMX6QDL_CLK_EIM_SLOW_SEL]     = imx_clk_fixup_mux("eim_slow_sel", base + 0x1c, 29, 2, eim_slow_sels,   ARRAY_SIZE(eim_slow_sels), imx_cscmr1_fixup);
+	if (clk_on_imx6qp()) {
+		clk[IMX6QDL_CLK_IPU1_DI0_SEL]     = imx_clk_mux_flags("ipu1_di0_sel",     base + 0x34, 0,  3, ipu1_di0_sels_2,     ARRAY_SIZE(ipu1_di0_sels_2), CLK_SET_RATE_PARENT);
+		clk[IMX6QDL_CLK_IPU1_DI1_SEL]     = imx_clk_mux_flags("ipu1_di1_sel",     base + 0x34, 9,  3, ipu1_di1_sels_2,     ARRAY_SIZE(ipu1_di1_sels_2), CLK_SET_RATE_PARENT);
+		clk[IMX6QDL_CLK_IPU2_DI0_SEL]     = imx_clk_mux_flags("ipu2_di0_sel",     base + 0x38, 0,  3, ipu2_di0_sels_2,     ARRAY_SIZE(ipu2_di0_sels_2), CLK_SET_RATE_PARENT);
+		clk[IMX6QDL_CLK_IPU2_DI1_SEL]     = imx_clk_mux_flags("ipu2_di1_sel",     base + 0x38, 9,  3, ipu2_di1_sels_2,     ARRAY_SIZE(ipu2_di1_sels_2), CLK_SET_RATE_PARENT);
+		clk[IMX6QDL_CLK_SSI1_SEL]         = imx_clk_mux("ssi1_sel",   base + 0x1c, 10, 2, ssi_sels,          ARRAY_SIZE(ssi_sels));
+		clk[IMX6QDL_CLK_SSI2_SEL]         = imx_clk_mux("ssi2_sel",   base + 0x1c, 12, 2, ssi_sels,          ARRAY_SIZE(ssi_sels));
+		clk[IMX6QDL_CLK_SSI3_SEL]         = imx_clk_mux("ssi3_sel",   base + 0x1c, 14, 2, ssi_sels,          ARRAY_SIZE(ssi_sels));
+		clk[IMX6QDL_CLK_USDHC1_SEL]       = imx_clk_mux("usdhc1_sel", base + 0x1c, 16, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels));
+		clk[IMX6QDL_CLK_USDHC2_SEL]       = imx_clk_mux("usdhc2_sel", base + 0x1c, 17, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels));
+		clk[IMX6QDL_CLK_USDHC3_SEL]       = imx_clk_mux("usdhc3_sel", base + 0x1c, 18, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels));
+		clk[IMX6QDL_CLK_USDHC4_SEL]       = imx_clk_mux("usdhc4_sel", base + 0x1c, 19, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels));
+		clk[IMX6QDL_CLK_ENFC_SEL]         = imx_clk_mux("enfc_sel",         base + 0x2c, 15, 3, enfc_sels_2,         ARRAY_SIZE(enfc_sels_2));
+		clk[IMX6QDL_CLK_EIM_SEL]          = imx_clk_mux("eim_sel",      base + 0x1c, 27, 2, eim_sels,        ARRAY_SIZE(eim_sels));
+		clk[IMX6QDL_CLK_EIM_SLOW_SEL]     = imx_clk_mux("eim_slow_sel", base + 0x1c, 29, 2, eim_slow_sels,   ARRAY_SIZE(eim_slow_sels));
+		clk[IMX6QDL_CLK_PRE_AXI]	  = imx_clk_mux("pre_axi",	base + 0x18, 1,  1, pre_axi_sels,    ARRAY_SIZE(pre_axi_sels));
+	} else {
+		clk[IMX6QDL_CLK_IPU1_DI0_SEL]     = imx_clk_mux_flags("ipu1_di0_sel",     base + 0x34, 0,  3, ipu1_di0_sels,     ARRAY_SIZE(ipu1_di0_sels), CLK_SET_RATE_PARENT);
+		clk[IMX6QDL_CLK_IPU1_DI1_SEL]     = imx_clk_mux_flags("ipu1_di1_sel",     base + 0x34, 9,  3, ipu1_di1_sels,     ARRAY_SIZE(ipu1_di1_sels), CLK_SET_RATE_PARENT);
+		clk[IMX6QDL_CLK_IPU2_DI0_SEL]     = imx_clk_mux_flags("ipu2_di0_sel",     base + 0x38, 0,  3, ipu2_di0_sels,     ARRAY_SIZE(ipu2_di0_sels), CLK_SET_RATE_PARENT);
+		clk[IMX6QDL_CLK_IPU2_DI1_SEL]     = imx_clk_mux_flags("ipu2_di1_sel",     base + 0x38, 9,  3, ipu2_di1_sels,     ARRAY_SIZE(ipu2_di1_sels), CLK_SET_RATE_PARENT);
+		clk[IMX6QDL_CLK_SSI1_SEL]         = imx_clk_fixup_mux("ssi1_sel",   base + 0x1c, 10, 2, ssi_sels,          ARRAY_SIZE(ssi_sels), imx_cscmr1_fixup);
+		clk[IMX6QDL_CLK_SSI2_SEL]         = imx_clk_fixup_mux("ssi2_sel",   base + 0x1c, 12, 2, ssi_sels,          ARRAY_SIZE(ssi_sels), imx_cscmr1_fixup);
+		clk[IMX6QDL_CLK_SSI3_SEL]         = imx_clk_fixup_mux("ssi3_sel",   base + 0x1c, 14, 2, ssi_sels,          ARRAY_SIZE(ssi_sels), imx_cscmr1_fixup);
+		clk[IMX6QDL_CLK_USDHC1_SEL]       = imx_clk_fixup_mux("usdhc1_sel", base + 0x1c, 16, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels), imx_cscmr1_fixup);
+		clk[IMX6QDL_CLK_USDHC2_SEL]       = imx_clk_fixup_mux("usdhc2_sel", base + 0x1c, 17, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels), imx_cscmr1_fixup);
+		clk[IMX6QDL_CLK_USDHC3_SEL]       = imx_clk_fixup_mux("usdhc3_sel", base + 0x1c, 18, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels), imx_cscmr1_fixup);
+		clk[IMX6QDL_CLK_USDHC4_SEL]       = imx_clk_fixup_mux("usdhc4_sel", base + 0x1c, 19, 1, usdhc_sels,        ARRAY_SIZE(usdhc_sels), imx_cscmr1_fixup);
+		clk[IMX6QDL_CLK_ENFC_SEL]         = imx_clk_mux("enfc_sel",         base + 0x2c, 16, 2, enfc_sels,         ARRAY_SIZE(enfc_sels));
+		clk[IMX6QDL_CLK_EIM_SEL]          = imx_clk_fixup_mux("eim_sel",      base + 0x1c, 27, 2, eim_sels,        ARRAY_SIZE(eim_sels), imx_cscmr1_fixup);
+		clk[IMX6QDL_CLK_EIM_SLOW_SEL]     = imx_clk_fixup_mux("eim_slow_sel", base + 0x1c, 29, 2, eim_slow_sels,   ARRAY_SIZE(eim_slow_sels), imx_cscmr1_fixup);
+	}
 	clk[IMX6QDL_CLK_VDO_AXI_SEL]      = imx_clk_mux("vdo_axi_sel",      base + 0x18, 11, 1, vdo_axi_sels,      ARRAY_SIZE(vdo_axi_sels));
 	clk[IMX6QDL_CLK_VPU_AXI_SEL]      = imx_clk_mux("vpu_axi_sel",      base + 0x18, 14, 2, vpu_axi_sels,      ARRAY_SIZE(vpu_axi_sels));
 	clk[IMX6QDL_CLK_CKO1_SEL]         = imx_clk_mux("cko1_sel",         base + 0x60, 0,  4, cko1_sels,         ARRAY_SIZE(cko1_sels));
@@ -335,23 +379,33 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[IMX6QDL_CLK_PERIPH_CLK2]      = imx_clk_divider("periph_clk2",      "periph_clk2_sel",   base + 0x14, 27, 3);
 	clk[IMX6QDL_CLK_PERIPH2_CLK2]     = imx_clk_divider("periph2_clk2",     "periph2_clk2_sel",  base + 0x14, 0,  3);
 	clk[IMX6QDL_CLK_IPG]              = imx_clk_divider("ipg",              "ahb",               base + 0x14, 8,  2);
-	clk[IMX6QDL_CLK_IPG_PER]          = imx_clk_fixup_divider("ipg_per",    "ipg",               base + 0x1c, 0,  6, imx_cscmr1_fixup);
 	clk[IMX6QDL_CLK_ESAI_PRED]        = imx_clk_divider("esai_pred",        "esai_sel",          base + 0x28, 9,  3);
 	clk[IMX6QDL_CLK_ESAI_PODF]        = imx_clk_divider("esai_podf",        "esai_pred",         base + 0x28, 25, 3);
 	clk[IMX6QDL_CLK_ASRC_PRED]        = imx_clk_divider("asrc_pred",        "asrc_sel",          base + 0x30, 12, 3);
 	clk[IMX6QDL_CLK_ASRC_PODF]        = imx_clk_divider("asrc_podf",        "asrc_pred",         base + 0x30, 9,  3);
 	clk[IMX6QDL_CLK_SPDIF_PRED]       = imx_clk_divider("spdif_pred",       "spdif_sel",         base + 0x30, 25, 3);
 	clk[IMX6QDL_CLK_SPDIF_PODF]       = imx_clk_divider("spdif_podf",       "spdif_pred",        base + 0x30, 22, 3);
-	clk[IMX6QDL_CLK_CAN_ROOT]         = imx_clk_divider("can_root",         "pll3_60m",          base + 0x20, 2,  6);
-	clk[IMX6QDL_CLK_ECSPI_ROOT]       = imx_clk_divider("ecspi_root",       "pll3_60m",          base + 0x38, 19, 6);
+	if (clk_on_imx6qp()) {
+		clk[IMX6QDL_CLK_IPG_PER] = imx_clk_divider("ipg_per", "ipg_per_sel", base + 0x1c, 0, 6);
+		clk[IMX6QDL_CLK_ECSPI_ROOT] = imx_clk_divider("ecspi_root", "ecspi_sel", base + 0x38, 19, 6);
+		clk[IMX6QDL_CLK_CAN_ROOT] = imx_clk_divider("can_root", "can_sel", base + 0x20, 2, 6);
+		clk[IMX6QDL_CLK_UART_SERIAL_PODF] = imx_clk_divider("uart_serial_podf", "uart_sel", base + 0x24, 0, 6);
+		clk[IMX6QDL_CLK_LDB_DI0_DIV_3_5] = imx_clk_fixed_factor("ldb_di0_div_3_5", "ldb_di0", 2, 7);
+		clk[IMX6QDL_CLK_LDB_DI1_DIV_3_5] = imx_clk_fixed_factor("ldb_di1_div_3_5", "ldb_di1", 2, 7);
+	} else {
+		clk[IMX6QDL_CLK_ECSPI_ROOT] = imx_clk_divider("ecspi_root", "pll3_60m", base + 0x38, 19, 6);
+		clk[IMX6QDL_CLK_CAN_ROOT] = imx_clk_divider("can_root", "pll3_60", base + 0x20, 2, 6);
+		clk[IMX6QDL_CLK_IPG_PER] = imx_clk_fixup_divider("ipg_per", "ipg", base + 0x1c, 0, 6, imx_cscmr1_fixup);
+		clk[IMX6QDL_CLK_UART_SERIAL_PODF] = imx_clk_divider("uart_serial_podf", "pll3_80m",          base + 0x24, 0,  6);
+		clk[IMX6QDL_CLK_LDB_DI0_DIV_3_5] = imx_clk_fixed_factor("ldb_di0_div_3_5", "ldb_di0_sel", 2, 7);
+		clk[IMX6QDL_CLK_LDB_DI1_DIV_3_5] = imx_clk_fixed_factor("ldb_di1_div_3_5", "ldb_di1_sel", 2, 7);
+	}
 	clk[IMX6QDL_CLK_GPU2D_CORE_PODF]  = imx_clk_divider("gpu2d_core_podf",  "gpu2d_core_sel",    base + 0x18, 23, 3);
 	clk[IMX6QDL_CLK_GPU3D_CORE_PODF]  = imx_clk_divider("gpu3d_core_podf",  "gpu3d_core_sel",    base + 0x18, 26, 3);
 	clk[IMX6QDL_CLK_GPU3D_SHADER]     = imx_clk_divider("gpu3d_shader",     "gpu3d_shader_sel",  base + 0x18, 29, 3);
 	clk[IMX6QDL_CLK_IPU1_PODF]        = imx_clk_divider("ipu1_podf",        "ipu1_sel",          base + 0x3c, 11, 3);
 	clk[IMX6QDL_CLK_IPU2_PODF]        = imx_clk_divider("ipu2_podf",        "ipu2_sel",          base + 0x3c, 16, 3);
-	clk[IMX6QDL_CLK_LDB_DI0_DIV_3_5]  = imx_clk_fixed_factor("ldb_di0_div_3_5", "ldb_di0_sel", 2, 7);
 	clk[IMX6QDL_CLK_LDB_DI0_PODF]     = imx_clk_divider_flags("ldb_di0_podf", "ldb_di0_div_3_5", base + 0x20, 10, 1, 0);
-	clk[IMX6QDL_CLK_LDB_DI1_DIV_3_5]  = imx_clk_fixed_factor("ldb_di1_div_3_5", "ldb_di1_sel", 2, 7);
 	clk[IMX6QDL_CLK_LDB_DI1_PODF]     = imx_clk_divider_flags("ldb_di1_podf", "ldb_di1_div_3_5", base + 0x20, 11, 1, 0);
 	clk[IMX6QDL_CLK_IPU1_DI0_PRE]     = imx_clk_divider("ipu1_di0_pre",     "ipu1_di0_pre_sel",  base + 0x34, 3,  3);
 	clk[IMX6QDL_CLK_IPU1_DI1_PRE]     = imx_clk_divider("ipu1_di1_pre",     "ipu1_di1_pre_sel",  base + 0x34, 12, 3);
@@ -364,15 +418,19 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[IMX6QDL_CLK_SSI2_PODF]        = imx_clk_divider("ssi2_podf",        "ssi2_pred",         base + 0x2c, 0,  6);
 	clk[IMX6QDL_CLK_SSI3_PRED]        = imx_clk_divider("ssi3_pred",        "ssi3_sel",          base + 0x28, 22, 3);
 	clk[IMX6QDL_CLK_SSI3_PODF]        = imx_clk_divider("ssi3_podf",        "ssi3_pred",         base + 0x28, 16, 6);
-	clk[IMX6QDL_CLK_UART_SERIAL_PODF] = imx_clk_divider("uart_serial_podf", "pll3_80m",          base + 0x24, 0,  6);
 	clk[IMX6QDL_CLK_USDHC1_PODF]      = imx_clk_divider("usdhc1_podf",      "usdhc1_sel",        base + 0x24, 11, 3);
 	clk[IMX6QDL_CLK_USDHC2_PODF]      = imx_clk_divider("usdhc2_podf",      "usdhc2_sel",        base + 0x24, 16, 3);
 	clk[IMX6QDL_CLK_USDHC3_PODF]      = imx_clk_divider("usdhc3_podf",      "usdhc3_sel",        base + 0x24, 19, 3);
 	clk[IMX6QDL_CLK_USDHC4_PODF]      = imx_clk_divider("usdhc4_podf",      "usdhc4_sel",        base + 0x24, 22, 3);
 	clk[IMX6QDL_CLK_ENFC_PRED]        = imx_clk_divider("enfc_pred",        "enfc_sel",          base + 0x2c, 18, 3);
 	clk[IMX6QDL_CLK_ENFC_PODF]        = imx_clk_divider("enfc_podf",        "enfc_pred",         base + 0x2c, 21, 6);
-	clk[IMX6QDL_CLK_EIM_PODF]         = imx_clk_fixup_divider("eim_podf",   "eim_sel",           base + 0x1c, 20, 3, imx_cscmr1_fixup);
-	clk[IMX6QDL_CLK_EIM_SLOW_PODF]    = imx_clk_fixup_divider("eim_slow_podf", "eim_slow_sel",   base + 0x1c, 23, 3, imx_cscmr1_fixup);
+	if (clk_on_imx6qp()) {
+		clk[IMX6QDL_CLK_EIM_PODF]         = imx_clk_divider("eim_podf",   "eim_sel",           base + 0x1c, 20, 3);
+		clk[IMX6QDL_CLK_EIM_SLOW_PODF]    = imx_clk_divider("eim_slow_podf", "eim_slow_sel",   base + 0x1c, 23, 3);
+	} else {
+		clk[IMX6QDL_CLK_EIM_PODF]         = imx_clk_fixup_divider("eim_podf",   "eim_sel",           base + 0x1c, 20, 3, imx_cscmr1_fixup);
+		clk[IMX6QDL_CLK_EIM_SLOW_PODF]    = imx_clk_fixup_divider("eim_slow_podf", "eim_slow_sel",   base + 0x1c, 23, 3, imx_cscmr1_fixup);
+	}
 	clk[IMX6QDL_CLK_VPU_AXI_PODF]     = imx_clk_divider("vpu_axi_podf",     "vpu_axi_sel",       base + 0x24, 25, 3);
 	clk[IMX6QDL_CLK_CKO1_PODF]        = imx_clk_divider("cko1_podf",        "cko1_sel",          base + 0x60, 4,  3);
 	clk[IMX6QDL_CLK_CKO2_PODF]        = imx_clk_divider("cko2_podf",        "cko2_sel",          base + 0x60, 21, 3);
@@ -380,7 +438,12 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	/*                                                        name                 parent_name    reg        shift width busy: reg, shift */
 	clk[IMX6QDL_CLK_AXI]               = imx_clk_busy_divider("axi",               "axi_sel",     base + 0x14, 16,  3,   base + 0x48, 0);
 	clk[IMX6QDL_CLK_MMDC_CH0_AXI_PODF] = imx_clk_busy_divider("mmdc_ch0_axi_podf", "periph",      base + 0x14, 19,  3,   base + 0x48, 4);
-	clk[IMX6QDL_CLK_MMDC_CH1_AXI_PODF] = imx_clk_busy_divider("mmdc_ch1_axi_podf", "periph2",     base + 0x14, 3,   3,   base + 0x48, 2);
+	if (clk_on_imx6qp()) {
+		clk[IMX6QDL_CLK_MMDC_CH1_AXI_CG] = imx_clk_gate("mmdc_ch1_axi_cg", "periph2", base + 0x4, 18);
+		clk[IMX6QDL_CLK_MMDC_CH1_AXI_PODF] = imx_clk_busy_divider("mmdc_ch1_axi_podf", "mmdc_ch1_axi_cg", base + 0x14, 3, 3, base + 0x48, 2);
+	} else {
+		clk[IMX6QDL_CLK_MMDC_CH1_AXI_PODF] = imx_clk_busy_divider("mmdc_ch1_axi_podf", "periph2",     base + 0x14, 3,   3,   base + 0x48, 2);
+	}
 	clk[IMX6QDL_CLK_ARM]               = imx_clk_busy_divider("arm",               "pll1_sw",     base + 0x10, 0,   3,   base + 0x48, 16);
 	clk[IMX6QDL_CLK_AHB]               = imx_clk_busy_divider("ahb",               "periph",      base + 0x14, 10,  3,   base + 0x48, 1);
 
@@ -432,8 +495,13 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[IMX6QDL_CLK_IPU1_DI1]     = imx_clk_gate2("ipu1_di1",      "ipu1_di1_sel",      base + 0x74, 4);
 	clk[IMX6QDL_CLK_IPU2]         = imx_clk_gate2("ipu2",          "ipu2_podf",         base + 0x74, 6);
 	clk[IMX6QDL_CLK_IPU2_DI0]     = imx_clk_gate2("ipu2_di0",      "ipu2_di0_sel",      base + 0x74, 8);
-	clk[IMX6QDL_CLK_LDB_DI0]      = imx_clk_gate2("ldb_di0",       "ldb_di0_podf",      base + 0x74, 12);
-	clk[IMX6QDL_CLK_LDB_DI1]      = imx_clk_gate2("ldb_di1",       "ldb_di1_podf",      base + 0x74, 14);
+	if (clk_on_imx6qp()) {
+		clk[IMX6QDL_CLK_LDB_DI0]      = imx_clk_gate2("ldb_di0",       "ldb_di0_sel",      base + 0x74, 12);
+		clk[IMX6QDL_CLK_LDB_DI1]      = imx_clk_gate2("ldb_di1",       "ldb_di1_sel",      base + 0x74, 14);
+	} else {
+		clk[IMX6QDL_CLK_LDB_DI0]      = imx_clk_gate2("ldb_di0",       "ldb_di0_podf",      base + 0x74, 12);
+		clk[IMX6QDL_CLK_LDB_DI1]      = imx_clk_gate2("ldb_di1",       "ldb_di1_podf",      base + 0x74, 14);
+	}
 	clk[IMX6QDL_CLK_IPU2_DI1]     = imx_clk_gate2("ipu2_di1",      "ipu2_di1_sel",      base + 0x74, 10);
 	clk[IMX6QDL_CLK_HSI_TX]       = imx_clk_gate2_shared("hsi_tx", "hsi_tx_podf",       base + 0x74, 16, &share_count_mipi_core_cfg);
 	clk[IMX6QDL_CLK_MIPI_CORE_CFG] = imx_clk_gate2_shared("mipi_core_cfg", "video_27m", base + 0x74, 16, &share_count_mipi_core_cfg);
@@ -482,6 +550,16 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[IMX6QDL_CLK_EIM_SLOW]     = imx_clk_gate2("eim_slow",      "eim_slow_podf",     base + 0x80, 10);
 	clk[IMX6QDL_CLK_VDO_AXI]      = imx_clk_gate2("vdo_axi",       "vdo_axi_sel",       base + 0x80, 12);
 	clk[IMX6QDL_CLK_VPU_AXI]      = imx_clk_gate2("vpu_axi",       "vpu_axi_podf",      base + 0x80, 14);
+	if (clk_on_imx6qp()) {
+		clk[IMX6QDL_CLK_PRE0] = imx_clk_gate2("pre0",	       "pre_axi",	    base + 0x80, 16);
+		clk[IMX6QDL_CLK_PRE1] = imx_clk_gate2("pre1",	       "pre_axi",	    base + 0x80, 18);
+		clk[IMX6QDL_CLK_PRE2] = imx_clk_gate2("pre2",	       "pre_axi",         base + 0x80, 20);
+		clk[IMX6QDL_CLK_PRE3] = imx_clk_gate2("pre3",	       "pre_axi",	    base + 0x80, 22);
+		clk[IMX6QDL_CLK_PRG0_AXI] = imx_clk_gate2_shared("prg0_axi",  "ipu1_podf",  base + 0x80, 24, &share_count_prg0);
+		clk[IMX6QDL_CLK_PRG1_AXI] = imx_clk_gate2_shared("prg1_axi",  "ipu2_podf",  base + 0x80, 26, &share_count_prg1);
+		clk[IMX6QDL_CLK_PRG0_APB] = imx_clk_gate2_shared("prg0_apb",  "ipg",	    base + 0x80, 24, &share_count_prg0);
+		clk[IMX6QDL_CLK_PRG1_APB] = imx_clk_gate2_shared("prg1_apb",  "ipg",	    base + 0x80, 26, &share_count_prg1);
+	}
 	clk[IMX6QDL_CLK_CKO1]         = imx_clk_gate("cko1",           "cko1_podf",         base + 0x60, 7);
 	clk[IMX6QDL_CLK_CKO2]         = imx_clk_gate("cko2",           "cko2_podf",         base + 0x60, 24);
 
diff --git a/include/dt-bindings/clock/imx6qdl-clock.h b/include/dt-bindings/clock/imx6qdl-clock.h
index 77985cc..2905033 100644
--- a/include/dt-bindings/clock/imx6qdl-clock.h
+++ b/include/dt-bindings/clock/imx6qdl-clock.h
@@ -255,6 +255,20 @@
 #define IMX6QDL_CLK_CAAM_ACLK			242
 #define IMX6QDL_CLK_CAAM_IPG			243
 #define IMX6QDL_CLK_SPDIF_GCLK			244
-#define IMX6QDL_CLK_END				245
+#define IMX6QDL_CLK_UART_SEL			245
+#define IMX6QDL_CLK_IPG_PER_SEL			246
+#define IMX6QDL_CLK_ECSPI_SEL			247
+#define IMX6QDL_CLK_CAN_SEL			248
+#define IMX6QDL_CLK_MMDC_CH1_AXI_CG		249
+#define IMX6QDL_CLK_PRE0			250
+#define IMX6QDL_CLK_PRE1			251
+#define IMX6QDL_CLK_PRE2			252
+#define IMX6QDL_CLK_PRE3			253
+#define IMX6QDL_CLK_PRG0_AXI			254
+#define IMX6QDL_CLK_PRG1_AXI			255
+#define IMX6QDL_CLK_PRG0_APB			256
+#define IMX6QDL_CLK_PRG1_APB			257
+#define IMX6QDL_CLK_PRE_AXI			258
+#define IMX6QDL_CLK_END				259
 
 #endif /* __DT_BINDINGS_CLOCK_IMX6QDL_H */
-- 
1.9.1



From ping.bai at nxp.com  Tue Feb  2 02:01:35 2016
From: ping.bai at nxp.com (Bai Ping)
Date: Tue, 2 Feb 2016 18:01:35 +0800
Subject: [PATCH V3 2/5] ARM: dts: imx: Add basic dts support for imx6qp SOC
In-Reply-To: <1454407298-15545-1-git-send-email-ping.bai@nxp.com>
References: <1454407298-15545-1-git-send-email-ping.bai@nxp.com>
Message-ID: <1454407298-15545-2-git-send-email-ping.bai@nxp.com>

The i.MX6Quad Plus processor is an high performance SOC of i.MX6 family.
It has enhanced graphics performance and increased overall memory bandwidth
compared to i.MX6Q. Most of the design are same as i.MX6Quad/Dual, so code
for i.MX6Quad can be resued by this chip. The revision number is identied as
i.MX6Q Rev2.0, but actually it is a new chip, as we did many change to the
overall architecture.

This patch adds basic dtsi file support for the new i.MX6Quad Plus processor.

Signed-off-by: Bai Ping <ping.bai at nxp.com>
---

change for V3:
--remove some device node that the driver is not ready or stable in upstream
-- update the copyright header


 arch/arm/boot/dts/imx6q.dtsi           |  2 +-
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi |  1 +
 arch/arm/boot/dts/imx6qp.dtsi          | 86 ++++++++++++++++++++++++++++++++++
 3 files changed, 88 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/imx6qp.dtsi

diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 0d93c0e..ddcb37b 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -22,7 +22,7 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		cpu at 0 {
+		cpu0: cpu at 0 {
 			compatible = "arm,cortex-a9";
 			device_type = "cpu";
 			reg = <0>;
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index a6d445c..f65f57b 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -238,6 +238,7 @@
 				regulator-max-microvolt = <3300000>;
 				regulator-boot-on;
 				regulator-always-on;
+				regulator-ramp-delay = <6250>;
 			};
 
 			sw3a_reg: sw3a {
diff --git a/arch/arm/boot/dts/imx6qp.dtsi b/arch/arm/boot/dts/imx6qp.dtsi
new file mode 100644
index 0000000..1ada714
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qp.dtsi
@@ -0,0 +1,86 @@
+/*
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "imx6q.dtsi"
+
+/ {
+	soc {
+		ocram2: sram at 00940000 {
+			compatible = "mmio-sram";
+			reg = <0x00940000 0x20000>;
+			clocks = <&clks IMX6QDL_CLK_OCRAM>;
+		};
+
+		ocram3: sram at 00960000 {
+			compatible = "mmio-sram";
+			reg = <0x00960000 0x20000>;
+			clocks = <&clks IMX6QDL_CLK_OCRAM>;
+		};
+
+		ipu1: ipu at 02400000 {
+			compatible = "fsl,imx6qp-ipu", "fsl,imx6q-ipu";
+			clocks = <&clks IMX6QDL_CLK_IPU1>,
+				 <&clks IMX6QDL_CLK_IPU1_DI0>, <&clks IMX6QDL_CLK_IPU1_DI1>,
+				 <&clks IMX6QDL_CLK_IPU1_DI0_SEL>, <&clks IMX6QDL_CLK_IPU1_DI1_SEL>,
+				 <&clks IMX6QDL_CLK_LDB_DI0_PODF>, <&clks IMX6QDL_CLK_LDB_DI1_PODF>,
+				 <&clks IMX6QDL_CLK_PRG0_APB>;
+			clock-names = "bus",
+				      "di0", "di1",
+				      "di0_sel", "di1_sel",
+				      "ldb_di0", "ldb_di1", "prg";
+		};
+
+		ipu2: ipu at 02800000 {
+			compatible = "fsl,imx6qp-ipu", "fsl,imx6q-ipu";
+			clocks = <&clks IMX6QDL_CLK_IPU2>,
+				 <&clks IMX6QDL_CLK_IPU2_DI0>, <&clks IMX6QDL_CLK_IPU2_DI1>,
+				 <&clks IMX6QDL_CLK_IPU2_DI0_SEL>, <&clks IMX6QDL_CLK_IPU2_DI1_SEL>,
+				 <&clks IMX6QDL_CLK_LDB_DI0_PODF>, <&clks IMX6QDL_CLK_LDB_DI1_PODF>,
+				 <&clks IMX6QDL_CLK_PRG1_APB>;
+			clock-names = "bus",
+				      "di0", "di1",
+				      "di0_sel", "di1_sel",
+				      "ldb_di0", "ldb_di1", "prg";
+		};
+
+	};
+};
-- 
1.9.1



From ping.bai at nxp.com  Tue Feb  2 02:01:36 2016
From: ping.bai at nxp.com (Bai Ping)
Date: Tue, 2 Feb 2016 18:01:36 +0800
Subject: [PATCH V3 3/5] ARM: dts: imx: Add basic dts support for
 imx6qp-sabreauto
In-Reply-To: <1454407298-15545-1-git-send-email-ping.bai@nxp.com>
References: <1454407298-15545-1-git-send-email-ping.bai@nxp.com>
Message-ID: <1454407298-15545-3-git-send-email-ping.bai@nxp.com>

This patch adds basic dts file for i.MX6QP-Sbreauto board.

Signed-off-by: Bai Ping <ping.bai at nxp.com>
---

change for V3:
-- correct the dts list in alphabet order
-- update the copyright header for double license

 arch/arm/boot/dts/Makefile             |  3 +-
 arch/arm/boot/dts/imx6qp-sabreauto.dts | 93 ++++++++++++++++++++++++++++++++++
 2 files changed, 95 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/imx6qp-sabreauto.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c4f42a78..3801cbd 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -352,7 +352,8 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
 	imx6q-tx6q-1110.dtb \
 	imx6q-udoo.dtb \
 	imx6q-wandboard.dtb \
-	imx6q-wandboard-revb1.dtb
+	imx6q-wandboard-revb1.dtb \
+	imx6qp-sabreauto.dtb
 dtb-$(CONFIG_SOC_IMX6SL) += \
 	imx6sl-evk.dtb \
 	imx6sl-warp.dtb
diff --git a/arch/arm/boot/dts/imx6qp-sabreauto.dts b/arch/arm/boot/dts/imx6qp-sabreauto.dts
new file mode 100644
index 0000000..5ce3840
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qp-sabreauto.dts
@@ -0,0 +1,93 @@
+/*
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6qp.dtsi"
+#include "imx6qdl-sabreauto.dtsi"
+
+/ {
+	model = "Freescale i.MX6 Quad Plus SABRE Automotive Board";
+	compatible = "fsl,imx6qp-sabreauto", "fsl,imx6qp";
+};
+
+&i2c2 {
+	max7322: gpio at 68 {
+		compatible = "maxim,max7322";
+		reg = <0x68>;
+		gpio-controller;
+		#gpio-cells = <2>;
+	};
+};
+
+&iomuxc {
+	imx6qdl-sabreauto {
+		pinctrl_enet: enetgrp {
+			fsl,pins = <
+				MX6QDL_PAD_KEY_COL1__ENET_MDIO          0x1b0b0
+				MX6QDL_PAD_KEY_COL2__ENET_MDC           0x1b0b0
+				MX6QDL_PAD_RGMII_TXC__RGMII_TXC         0x1b018
+				MX6QDL_PAD_RGMII_TD0__RGMII_TD0         0x1b018
+				MX6QDL_PAD_RGMII_TD1__RGMII_TD1         0x1b018
+				MX6QDL_PAD_RGMII_TD2__RGMII_TD2         0x1b018
+				MX6QDL_PAD_RGMII_TD3__RGMII_TD3         0x1b018
+				MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL   0x1b018
+				MX6QDL_PAD_RGMII_RXC__RGMII_RXC         0x1b018
+				MX6QDL_PAD_RGMII_RD0__RGMII_RD0         0x1b018
+				MX6QDL_PAD_RGMII_RD1__RGMII_RD1         0x1b018
+				MX6QDL_PAD_RGMII_RD2__RGMII_RD2         0x1b018
+				MX6QDL_PAD_RGMII_RD3__RGMII_RD3         0x1b018
+				MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL   0x1b018
+				MX6QDL_PAD_GPIO_16__ENET_REF_CLK        0x4001b0a8
+				MX6QDL_PAD_GPIO_6__ENET_IRQ		0x000b1
+			>;
+		};
+	};
+};
+
+&pcie {
+	status = "disabled";
+};
+
+&vgen3_reg {
+	regulator-always-on;
+};
-- 
1.9.1



From ping.bai at nxp.com  Tue Feb  2 02:01:37 2016
From: ping.bai at nxp.com (Bai Ping)
Date: Tue, 2 Feb 2016 18:01:37 +0800
Subject: [PATCH V3 4/5] ARM: dts: imx: Add basic dts support for imx6qp-sabresd
In-Reply-To: <1454407298-15545-1-git-send-email-ping.bai@nxp.com>
References: <1454407298-15545-1-git-send-email-ping.bai@nxp.com>
Message-ID: <1454407298-15545-4-git-send-email-ping.bai@nxp.com>

This patch adds dts file for imx6qp-sabresd board.

Signed-off-by: Bai Ping <ping.bai at nxp.com>
---

change for V3:
-- update the copyright header
-- add the dtb in alphabet order

 arch/arm/boot/dts/Makefile           |  3 +-
 arch/arm/boot/dts/imx6qp-sabresd.dts | 93 ++++++++++++++++++++++++++++++++++++
 2 files changed, 95 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/imx6qp-sabresd.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3801cbd..0ad5061 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -353,7 +353,8 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
 	imx6q-udoo.dtb \
 	imx6q-wandboard.dtb \
 	imx6q-wandboard-revb1.dtb \
-	imx6qp-sabreauto.dtb
+	imx6qp-sabreauto.dtb \
+	imx6qp-sabresd.dtb
 dtb-$(CONFIG_SOC_IMX6SL) += \
 	imx6sl-evk.dtb \
 	imx6sl-warp.dtb
diff --git a/arch/arm/boot/dts/imx6qp-sabresd.dts b/arch/arm/boot/dts/imx6qp-sabresd.dts
new file mode 100644
index 0000000..b234580
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qp-sabresd.dts
@@ -0,0 +1,93 @@
+/*
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6qp.dtsi"
+#include "imx6qdl-sabresd.dtsi"
+
+/ {
+	model = "Freescale i.MX6 Quad Plus SABRE Smart Device Board";
+	compatible = "fsl,imx6qp-sabresd", "fsl,imx6qp";
+};
+
+&cpu0 {
+	arm-supply = <&sw2_reg>;
+};
+
+&iomuxc {
+	imx6qdl-sabresd {
+		pinctrl_usdhc2: usdhc2grp {
+			fsl,pins = <
+				MX6QDL_PAD_SD2_CMD__SD2_CMD		0x17059
+				MX6QDL_PAD_SD2_CLK__SD2_CLK		0x10071
+				MX6QDL_PAD_SD2_DAT0__SD2_DATA0		0x17059
+				MX6QDL_PAD_SD2_DAT1__SD2_DATA1		0x17059
+				MX6QDL_PAD_SD2_DAT2__SD2_DATA2		0x17059
+				MX6QDL_PAD_SD2_DAT3__SD2_DATA3		0x17059
+				MX6QDL_PAD_NANDF_D4__SD2_DATA4		0x17059
+				MX6QDL_PAD_NANDF_D5__SD2_DATA5		0x17059
+				MX6QDL_PAD_NANDF_D6__SD2_DATA6		0x17059
+				MX6QDL_PAD_NANDF_D7__SD2_DATA7		0x17059
+			>;
+		};
+
+		pinctrl_usdhc3: usdhc3grp {
+			fsl,pins = <
+				MX6QDL_PAD_SD3_CMD__SD3_CMD		0x17059
+				MX6QDL_PAD_SD3_CLK__SD3_CLK		0x10071
+				MX6QDL_PAD_SD3_DAT0__SD3_DATA0		0x17059
+				MX6QDL_PAD_SD3_DAT1__SD3_DATA1		0x17059
+				MX6QDL_PAD_SD3_DAT2__SD3_DATA2		0x17059
+				MX6QDL_PAD_SD3_DAT3__SD3_DATA3		0x17059
+				MX6QDL_PAD_SD3_DAT4__SD3_DATA4		0x17059
+				MX6QDL_PAD_SD3_DAT5__SD3_DATA5		0x17059
+				MX6QDL_PAD_SD3_DAT6__SD3_DATA6		0x17059
+				MX6QDL_PAD_SD3_DAT7__SD3_DATA7		0x17059
+			>;
+		};
+	};
+};
+
+&pcie {
+	status = "disabled";
+};
-- 
1.9.1



From ping.bai at nxp.com  Tue Feb  2 02:01:38 2016
From: ping.bai at nxp.com (Bai Ping)
Date: Tue, 2 Feb 2016 18:01:38 +0800
Subject: [PATCH V3 5/5] ARM: imx: Add msl code support for imx6qp
In-Reply-To: <1454407298-15545-1-git-send-email-ping.bai@nxp.com>
References: <1454407298-15545-1-git-send-email-ping.bai@nxp.com>
Message-ID: <1454407298-15545-5-git-send-email-ping.bai@nxp.com>

The i.MX6QP is a different SOC, but internally we treate it as i.MX6Q
Rev_2.0 to maximum the code reusability. The chip silicon number we
read from the ANADIG_DIGPROG is 0x630100. This patch add code to
identify it as i.MX6QP Rev_1.0 when print out the silicon version.

Signed-off-by: Bai Ping <ping.bai at nxp.com>
---

change for V3:
-- add comment for the revision trick code

 arch/arm/mach-imx/anatop.c     | 9 ++++++++-
 arch/arm/mach-imx/mach-imx6q.c | 8 ++++++--
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-imx/anatop.c b/arch/arm/mach-imx/anatop.c
index 231bb25..0f624d1 100644
--- a/arch/arm/mach-imx/anatop.c
+++ b/arch/arm/mach-imx/anatop.c
@@ -129,7 +129,14 @@ void __init imx_init_revision_from_anatop(void)
 
 	switch (digprog & 0xff) {
 	case 0:
-		revision = IMX_CHIP_REVISION_1_0;
+		/*
+		 * For i.MX6QP, most of the code for i.MX6Q can be resued,
+		 * so internally, we identify it as i.MX6Q Rev 2.0
+		 */
+		if (digprog >> 8 & 0x01)
+			revision = IMX_CHIP_REVISION_2_0;
+		else
+			revision = IMX_CHIP_REVISION_1_0;
 		break;
 	case 1:
 		revision = IMX_CHIP_REVISION_1_1;
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 3878494b..cb27d56 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -266,8 +266,11 @@ static void __init imx6q_init_machine(void)
 {
 	struct device *parent;
 
-	imx_print_silicon_rev(cpu_is_imx6dl() ? "i.MX6DL" : "i.MX6Q",
-			      imx_get_soc_revision());
+	if (cpu_is_imx6q() && imx_get_soc_revision() == IMX_CHIP_REVISION_2_0)
+		imx_print_silicon_rev("i.MX6QP", IMX_CHIP_REVISION_1_0);
+	else
+		imx_print_silicon_rev(cpu_is_imx6dl() ? "i.MX6DL" : "i.MX6Q",
+				imx_get_soc_revision());
 
 	parent = imx_soc_device_init();
 	if (parent == NULL)
@@ -399,6 +402,7 @@ static void __init imx6q_init_irq(void)
 static const char * const imx6q_dt_compat[] __initconst = {
 	"fsl,imx6dl",
 	"fsl,imx6q",
+	"fsl,imx6qp",
 	NULL,
 };
 
-- 
1.9.1



From andy.yan at rock-chips.com  Tue Feb  2 02:02:05 2016
From: andy.yan at rock-chips.com (Andy Yan)
Date: Tue,  2 Feb 2016 18:02:05 +0800
Subject: [PATCH v3 2/4] power: reset: add reboot mode driver
In-Reply-To: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
References: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
Message-ID: <1454407325-4804-1-git-send-email-andy.yan@rock-chips.com>

This driver parse the reboot commands like "reboot loader"
and "reboot recovery" to get a boot mode described in the
device tree , then call the write interfae to store the boot
mode in some place like special register or sram , which can
be read by the bootloader after system reboot, then the bootloader
can take different action according to the mode stored.

This is commonly used on Android based devices, in order to
reboot the device into fastboot or recovery mode.

Reviewed-by: Matthias Brugger <matthias.bgg at gmail.com>
Signed-off-by: Andy Yan <andy.yan at rock-chips.com>

---

Changes in v3:
- scan multi properities
- add mask value for some platform which only use some bits of the register
  to store boot mode magic value

Changes in v2:
- move to dir drivers/power/reset/
- make syscon-reboot-mode a generic driver

Changes in v1:
- fix the embarrassed compile warning
- correct the maskrom magic number
- check for the normal reboot

 drivers/power/reset/Kconfig              |  16 +++++
 drivers/power/reset/Makefile             |   2 +
 drivers/power/reset/reboot-mode.c        | 105 +++++++++++++++++++++++++++++++
 drivers/power/reset/reboot-mode.h        |   6 ++
 drivers/power/reset/syscon-reboot-mode.c |  64 +++++++++++++++++++
 5 files changed, 193 insertions(+)
 create mode 100644 drivers/power/reset/reboot-mode.c
 create mode 100644 drivers/power/reset/reboot-mode.h
 create mode 100644 drivers/power/reset/syscon-reboot-mode.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 1131cf7..2e6d873 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -173,5 +173,21 @@ config POWER_RESET_ZX
 	help
 	  Reboot support for ZTE SoCs.
 
+config REBOOT_MODE
+	tristate
+	depends on OF
+	help
+	 This driver will help to pass the system reboot mode
+	 to bootloader
+
+config SYSCON_REBOOT_MODE
+	bool "Generic SYSCON regmap reboot mode driver"
+	select REBOOT_MODE
+	help
+	 Say y here will enable reboot mode driver. This will
+	 get reboot mode arguments and store it in SYSCON mapped
+	 register, then the bootloader can read it to take different
+	 action according to the mode.
+
 endif
 
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 096fa67..a63865b 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -20,3 +20,5 @@ obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
 obj-$(CONFIG_POWER_RESET_SYSCON_POWEROFF) += syscon-poweroff.o
 obj-$(CONFIG_POWER_RESET_RMOBILE) += rmobile-reset.o
 obj-$(CONFIG_POWER_RESET_ZX) += zx-reboot.o
+obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
+obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
diff --git a/drivers/power/reset/reboot-mode.c b/drivers/power/reset/reboot-mode.c
new file mode 100644
index 0000000..69ba640
--- /dev/null
+++ b/drivers/power/reset/reboot-mode.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/reboot.h>
+#include "reboot-mode.h"
+
+#define PREFIX "mode-"
+
+struct mode_info {
+	char mode[32];
+	int magic;
+	struct list_head list;
+};
+
+struct reboot_mode_driver {
+	struct list_head head;
+	int (*write)(int magic);
+	struct notifier_block reboot_notifier;
+};
+
+static int get_reboot_mode_magic(struct reboot_mode_driver *reboot,
+				 const char *cmd)
+{
+	const char *normal = "normal";
+	int magic = 0;
+	struct mode_info *info;
+
+	if (!cmd)
+		cmd = normal;
+
+	list_for_each_entry(info, &reboot->head, list) {
+		if (!strcmp(info->mode, cmd)) {
+			magic = info->magic;
+			break;
+		}
+	}
+
+	return magic;
+}
+
+static int reboot_mode_notify(struct notifier_block *this,
+			      unsigned long mode, void *cmd)
+{
+	struct reboot_mode_driver *reboot;
+	int magic;
+
+	reboot = container_of(this, struct reboot_mode_driver, reboot_notifier);
+	magic = get_reboot_mode_magic(reboot, cmd);
+	if (magic)
+		reboot->write(magic);
+
+	return NOTIFY_DONE;
+}
+
+int reboot_mode_register(struct device *dev, int (*write)(int))
+{
+	struct reboot_mode_driver *reboot;
+	struct mode_info *info;
+	struct property *prop;
+	size_t len = strlen(PREFIX);
+	int ret;
+
+	reboot = devm_kzalloc(dev, sizeof(*reboot), GFP_KERNEL);
+	if (!reboot)
+		return -ENOMEM;
+
+	reboot->write = write;
+	INIT_LIST_HEAD(&reboot->head);
+	for_each_property_of_node(dev->of_node, prop) {
+		if (len > strlen(prop->name) || strncmp(prop->name, PREFIX, len))
+			continue;
+		info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
+		if (!info)
+			return -ENOMEM;
+		strcpy(info->mode, prop->name + len);
+		if (of_property_read_u32(dev->of_node, prop->name, &info->magic)) {
+			dev_err(dev, "reboot mode %s without magic number\n",
+				info->mode);
+			devm_kfree(dev, info);
+			continue;
+		}
+		list_add_tail(&info->list, &reboot->head);
+	}
+	reboot->reboot_notifier.notifier_call = reboot_mode_notify;
+	ret = register_reboot_notifier(&reboot->reboot_notifier);
+	if (ret)
+		dev_err(dev, "can't register reboot notifier\n");
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(reboot_mode_register);
+
+MODULE_AUTHOR("Andy Yan <andy.yan at rock-chips.com");
+MODULE_DESCRIPTION("System reboot mode driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/power/reset/reboot-mode.h b/drivers/power/reset/reboot-mode.h
new file mode 100644
index 0000000..44ed34f
--- /dev/null
+++ b/drivers/power/reset/reboot-mode.h
@@ -0,0 +1,6 @@
+#ifndef __REBOOT_MODE_H__
+#define __REBOOT_MODE_H__
+
+int reboot_mode_register(struct device *dev, int (*write)(int));
+
+#endif
diff --git a/drivers/power/reset/syscon-reboot-mode.c b/drivers/power/reset/syscon-reboot-mode.c
new file mode 100644
index 0000000..8571df3
--- /dev/null
+++ b/drivers/power/reset/syscon-reboot-mode.c
@@ -0,0 +1,64 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/reboot.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+#include "reboot-mode.h"
+
+static struct regmap *map;
+static u32 offset;
+static u32 mask = 0xffffffff;
+
+static int syscon_reboot_mode_write(int magic)
+{
+	regmap_update_bits(map, offset, mask, magic);
+
+	return 0;
+}
+
+static int syscon_reboot_mode_probe(struct platform_device *pdev)
+{
+	int ret;
+
+	map = syscon_node_to_regmap(pdev->dev.parent->of_node);
+	if (IS_ERR(map))
+		return PTR_ERR(map);
+	if (of_property_read_u32(pdev->dev.of_node, "offset", &offset))
+		return -EINVAL;
+	of_property_read_u32(pdev->dev.of_node, "mask", &mask);
+	ret = reboot_mode_register(&pdev->dev, syscon_reboot_mode_write);
+	if (ret)
+		dev_err(&pdev->dev, "can't register reboot mode\n");
+
+	return ret;
+}
+
+static const struct of_device_id syscon_reboot_mode_of_match[] = {
+	{ .compatible = "syscon-reboot-mode" },
+	{}
+};
+
+static struct platform_driver syscon_reboot_mode_driver = {
+	.probe = syscon_reboot_mode_probe,
+	.driver = {
+		.name = "syscon-reboot-mode",
+		.of_match_table = syscon_reboot_mode_of_match,
+	},
+};
+module_platform_driver(syscon_reboot_mode_driver);
+
+MODULE_AUTHOR("Andy Yan <andy.yan at rock-chips.com");
+MODULE_DESCRIPTION("SYSCON reboot mode driver");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1




From krzysztof.adamski at sonymobile.com  Tue Feb  2 02:03:03 2016
From: krzysztof.adamski at sonymobile.com (Krzysztof Adamski)
Date: Tue, 2 Feb 2016 11:03:03 +0100
Subject: [PATCH] pinctrl: sunxi: H3 requires irq_read_needs_mux
Message-ID: <20160202100217.GA7483@box2.japko.eu>

It seems that on H3, just like on A10, when GPIOs are configured as
external interrupt data registers does not contain their value.  When
value is read, GPIO function must be temporary switched to input for
reads.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
index 77d4cf0..11760bb 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
@@ -492,6 +492,7 @@ static const struct sunxi_pinctrl_desc sun8i_h3_pinctrl_data = {
 	.pins = sun8i_h3_pins,
 	.npins = ARRAY_SIZE(sun8i_h3_pins),
 	.irq_banks = 2,
+	.irq_read_needs_mux = true
 };
 
 static int sun8i_h3_pinctrl_probe(struct platform_device *pdev)
-- 
2.4.2



From ulf.hansson at linaro.org  Tue Feb  2 02:07:00 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 2 Feb 2016 11:07:00 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160202030533.GT19432@atomide.com>
References: <20160201232833.GR19432@atomide.com>
 <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>
 <20160202030533.GT19432@atomide.com>
Message-ID: <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>

On 2 February 2016 at 04:05, Tony Lindgren <tony at atomide.com> wrote:
> Hi,
>
> * Alan Stern <stern at rowland.harvard.edu> [160201 15:50]:
>>
>> You get here only if runtime PM is disabled, right?  So the rpm_idle
>> call won't do anything -- "disabled" means don't make any callbacks.
>
> Hmm sorry yes I'm confused again. Yeah it looks like calling rpm_idle
> just has a side effect that makes a difference here.
>
>> Tony, exactly what are you trying to do here?  Do you want this to
>> invoke a runtime-PM callback in the subsystem, power domain, or driver?
>> (Is there even a driver bound to the device when this function runs?)
>
> I guess I need to add more printks to figure out what's going on here.
> But yeah, I'm not seeing the callback happening at the interconnect
> level so hardware and PM runtime states won't match on the following
> probe after -EPROBE_DEFER.
>
>> The function's name suggests that it merely resets the data stored in
>> dev->power without actually touching the hardware.  Is that what you
>> really want?
>
> I guess you mean pm_runtime_set_suspended() above? I'm seeing a state
> where we now set pm_runtime_set_suspended() between failed device
> probes and the device is still active in hardware.
>
> The patch below also helps with the problem and leaves out the
> rpm_suspend() call from loop so it might give more hints.
>
> The difference here from what Rafael suggested earlier is calling
> __pm_runtime_use_autosuspend() and then not calling
> pm_runtime_set_suspended().
>
> However, it seems the below patch keeps hardware active in the
> autoidle case though, so chances are there is more that needs to
> be done here. Anyways, I'll try to debug it more tomorrow.
>

Your observations is correct. The hardware will be kept active
in-between the probe attempts (and thus also if probing fails).
Although, that's not a regression as that's the behaviour you get from
runtime PM, when drivers are implemented like omap_hsmmc.

Instead of the suggested approaches, I think the regression should be
fixed at the PM domain level (omap hwmod). I have attached a patch
below, please give it try as it's untested.

To solve the other problem (allowing devices to become inactive
in-between at probe failures), I see two options (not treated as
regressions).
1)
Change the behaviour of pm_runtime_put_sync(), to *not* respect the
autosuspend mode.
I think I prefer this option, as it seems like autosuspend should be
respected only via the asynchronous runtime PM APIs.

2)
Change the failing drivers, to before calling pm_runtime_put_sync()
also invoke pm_runtime_dont_use_autosusend(). Or other similar
approach.

Kind regards
Uffe

[...]

From: Ulf Hansson <ulf.hansson at linaro.org>
Date: Tue, 2 Feb 2016 10:05:39 +0100
Subject: [PATCH] ARM: OMAP2+: omap-device: Allow devices to be pre-enabled

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") may re-initialize the runtime PM status of the
device to RPM_SUSPENDED at driver probe failures.

For the omap_hsmmc and likely also other omap drivers, which needs more
than one attempt to ->probe() (returning -EPROBE_DEFER), this commit
causes a regression at the PM domain level (omap hwmod).

The reason is that the drivers don't put back the device into low power
state while bailing out in ->probe to return -EPROBE_DEFER. This leads to
that pm_runtime_reinit() in driver core, is re-initializing the runtime PM
status from RPM_ACTIVE to RPM_SUSPENDED.

The next ->probe() attempt then triggers the ->runtime_resume() callback
to be invoked, which means this happens two times in a row. At the PM
domain level (omap hwmod) this is being treated as an error and thus the
runtime PM status of the device isn't correctly synchronized with the
runtime PM core.

In the end, ->probe() anyway succeeds (as the driver don't checks the
error code from the runtime PM APIs), but results in that the PM domain
always stays powered on. This because of the runtime PM core believes the
device is RPM_SUSPENDED.

Fix this regression by allowing devices to be pre-enabled when the PM
domain's (omap hwmod) ->runtime_resume() callback is requested to enable
the device. In such cases, return zero to synchronize the runtime PM
status with the runtime PM core.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
---
 arch/arm/mach-omap2/omap_device.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 0437537..851767f 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -717,7 +717,7 @@ int omap_device_register(struct platform_device *pdev)
  * to be accessible and ready to operate.  This generally involves
  * enabling clocks, setting SYSCONFIG registers; and in the future may
  * involve remuxing pins.  Device drivers should call this function
- * indirectly via pm_runtime_get*().  Returns -EINVAL if called when
+ * indirectly via pm_runtime_get*().  Returns zero if called when
  * the omap_device is already enabled, or passes along the return
  * value of _omap_device_enable_hwmods().
  */
@@ -728,12 +728,13 @@ int omap_device_enable(struct platform_device *pdev)

        od = to_omap_device(pdev);

-       if (od->_state == OMAP_DEVICE_STATE_ENABLED) {
-               dev_warn(&pdev->dev,
-                        "omap_device: %s() called from invalid state %d\n",
-                        __func__, od->_state);
-               return -EINVAL;
-       }
+       /*
+        * From the PM domain perspective the device may already be enabled.
+        * In such case, let's return zero to synchronize the state with the
+        * runtime PM core.
+       */
+       if (od->_state == OMAP_DEVICE_STATE_ENABLED)
+               return 0;

        ret = _omap_device_enable_hwmods(od);

-- 
1.9.1


From gkulkarni at caviumnetworks.com  Tue Feb  2 02:09:15 2016
From: gkulkarni at caviumnetworks.com (Ganapatrao Kulkarni)
Date: Tue, 2 Feb 2016 15:39:15 +0530
Subject: [PATCH v10 0/8] arm64, numa: Add numa support for arm64 platforms
Message-ID: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>

v10:
	- Incorporated review comments from Rob Herring.
	- Moved numa binding and implementation to devicetree core.
	- Added cleanup patch to remove redundant NODE_DATA macro from asm header files
	- Include numa balancing support for arm64 patch in this series.
	- Fix tile build issue reported by the kbuild robot(patch 7)

v9:	- Added cleanup patch to reuse and avoid redefinition of cpumask_of_pcibus
	  as suggested from Will Deacon and Bjorn Helgaas.
	- Including patch to Make pci-host-generic driver numa aware.
	- Incorporated comment from Shannon Zhao.

v8:
	- Incorporated review comments of Mark Rutland and Will Deacon.
	- Added pci helper function and macro for numa.

v7:
	- managing numa memory mapping using memblock.
	- Incorporated review comments of Mark Rutland.

v6:
	- defined and implemented the numa dt binding using
	node property proximity and device node distance-map.
	- renamed dt_numa to of_numa

v5:
        - created base verion of numa.c which creates dummy numa without using dt
          on single socket platforms. Then added patches for dt support.
        - Incorporated review comments from Hanjun Guo.

v4:
done changes as per Arnd review comments.

v3:
Added changes to support numa on arm64 based platforms.
Tested these patches on cavium's multinode(2 node topology) platform.
In this patchset, defined and implemented dt bindings for numa mapping
for core and memory using device node property arm,associativity.

v2:
Defined and implemented numa map for memory, cores to node and
proximity distance matrix of nodes.

v1:
Initial patchset to support numa on arm64 platforms.

Note:
        1. This patchset is tested for numa with dt on
           thunderx single socket and dual socket boards.
        2. Numa DT booting needs the dt memory nodes, which are deleted in current efi-stub,
        hence to try numa with dt, you need to rebase with ard's patchset.
        http://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-uefi-early-fdt-handling
	3. PATCH[7,8] are not tested for other architectures.

Ganapatrao Kulkarni (8):
  arm64, numa: adding numa support for arm64 platforms.
  Documentation, dt, numa: dt bindings for numa.
  dt, numa: adding numa dt binding implementation.
  arm64, numa : Enable numa dt for arm64 platforms.
  arm64, dt, thunderx: Add initial dts for Cavium Thunderx in 2 node
    topology.
  arm64, mm, numa: Adding numa balancing support for arm64.
  topology, cleanup: Avoid redefinition of cpumask_of_pcibus in asm
    header files.
  numa, mm, cleanup: remove redundant NODE_DATA macro from asm header
    files.

 Documentation/devicetree/bindings/numa.txt      | 272 ++++++++
 arch/arm64/Kconfig                              |  26 +
 arch/arm64/boot/dts/cavium/Makefile             |   2 +-
 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts  |  83 +++
 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi | 806 ++++++++++++++++++++++++
 arch/arm64/include/asm/mmzone.h                 |  10 +
 arch/arm64/include/asm/numa.h                   |  45 ++
 arch/arm64/include/asm/pgtable.h                |  18 +
 arch/arm64/include/asm/topology.h               |   7 +
 arch/arm64/kernel/pci.c                         |  10 +
 arch/arm64/kernel/setup.c                       |   4 +
 arch/arm64/kernel/smp.c                         |   4 +
 arch/arm64/mm/Makefile                          |   1 +
 arch/arm64/mm/init.c                            |  34 +-
 arch/arm64/mm/mmu.c                             |   1 +
 arch/arm64/mm/numa.c                            | 404 ++++++++++++
 arch/ia64/include/asm/topology.h                |   4 -
 arch/m32r/include/asm/mmzone.h                  |   4 +-
 arch/metag/include/asm/mmzone.h                 |   4 +-
 arch/metag/include/asm/topology.h               |   3 -
 arch/powerpc/include/asm/mmzone.h               |   8 +-
 arch/powerpc/include/asm/topology.h             |   4 -
 arch/s390/include/asm/mmzone.h                  |   6 +-
 arch/s390/include/asm/pci.h                     |   2 +-
 arch/s390/include/asm/topology.h                |   1 +
 arch/sh/include/asm/mmzone.h                    |   4 +-
 arch/sh/include/asm/topology.h                  |   3 -
 arch/sparc/include/asm/mmzone.h                 |   6 +-
 arch/tile/include/asm/pci.h                     |   2 -
 arch/tile/include/asm/topology.h                |   3 +
 arch/x86/include/asm/mmzone.h                   |   3 +-
 arch/x86/include/asm/mmzone_32.h                |   5 -
 arch/x86/include/asm/mmzone_64.h                |  17 -
 arch/x86/include/asm/pci.h                      |   2 +-
 arch/x86/include/asm/topology.h                 |   1 +
 drivers/of/Kconfig                              |  11 +
 drivers/of/Makefile                             |   1 +
 drivers/of/of_numa.c                            | 207 ++++++
 include/asm-generic/mmzone.h                    |  24 +
 include/asm-generic/topology.h                  |   4 +-
 include/linux/of.h                              |   4 +
 41 files changed, 1986 insertions(+), 74 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/numa.txt
 create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts
 create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi
 create mode 100644 arch/arm64/include/asm/mmzone.h
 create mode 100644 arch/arm64/include/asm/numa.h
 create mode 100644 arch/arm64/mm/numa.c
 delete mode 100644 arch/x86/include/asm/mmzone_64.h
 create mode 100644 drivers/of/of_numa.c
 create mode 100644 include/asm-generic/mmzone.h

-- 
1.8.1.4



From gkulkarni at caviumnetworks.com  Tue Feb  2 02:09:16 2016
From: gkulkarni at caviumnetworks.com (Ganapatrao Kulkarni)
Date: Tue, 2 Feb 2016 15:39:16 +0530
Subject: [PATCH v10 1/8] arm64, numa: adding numa support for arm64 platforms.
In-Reply-To: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
References: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
Message-ID: <1454407763-1017-2-git-send-email-gkulkarni@caviumnetworks.com>

Adding numa support for arm64 based platforms.
This patch adds by default the dummy numa node and
maps all memory and cpus to node 0.
using this patch, numa can be simulated on single node arm64 platforms.

Tested-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
---
 arch/arm64/Kconfig                |  25 +++
 arch/arm64/include/asm/mmzone.h   |  12 ++
 arch/arm64/include/asm/numa.h     |  43 +++++
 arch/arm64/include/asm/topology.h |  10 +
 arch/arm64/kernel/pci.c           |  10 +
 arch/arm64/kernel/setup.c         |   4 +
 arch/arm64/kernel/smp.c           |   2 +
 arch/arm64/mm/Makefile            |   1 +
 arch/arm64/mm/init.c              |  34 +++-
 arch/arm64/mm/mmu.c               |   1 +
 arch/arm64/mm/numa.c              | 387 ++++++++++++++++++++++++++++++++++++++
 11 files changed, 524 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm64/include/asm/mmzone.h
 create mode 100644 arch/arm64/include/asm/numa.h
 create mode 100644 arch/arm64/mm/numa.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc6228..fcf3950 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -74,6 +74,7 @@ config ARM64
 	select HAVE_HW_BREAKPOINT if PERF_EVENTS
 	select HAVE_IRQ_TIME_ACCOUNTING
 	select HAVE_MEMBLOCK
+	select HAVE_MEMBLOCK_NODE_MAP if NUMA
 	select HAVE_PATA_PLATFORM
 	select HAVE_PERF_EVENTS
 	select HAVE_PERF_REGS
@@ -534,6 +535,30 @@ config HOTPLUG_CPU
 	  Say Y here to experiment with turning CPUs off and on.  CPUs
 	  can be controlled through /sys/devices/system/cpu.
 
+# Common NUMA Features
+config NUMA
+	bool "Numa Memory Allocation and Scheduler Support"
+	depends on SMP
+	help
+	  Enable NUMA (Non Uniform Memory Access) support.
+
+	  The kernel will try to allocate memory used by a CPU on the
+	  local memory of the CPU and add some more
+	  NUMA awareness to the kernel.
+
+config NODES_SHIFT
+	int "Maximum NUMA Nodes (as a power of 2)"
+	range 1 10
+	default "2"
+	depends on NEED_MULTIPLE_NODES
+	help
+	  Specify the maximum number of NUMA Nodes available on the target
+	  system.  Increases memory reserved to accommodate various tables.
+
+config USE_PERCPU_NUMA_NODE_ID
+	def_bool y
+	depends on NUMA
+
 source kernel/Kconfig.preempt
 source kernel/Kconfig.hz
 
diff --git a/arch/arm64/include/asm/mmzone.h b/arch/arm64/include/asm/mmzone.h
new file mode 100644
index 0000000..a0de9e6
--- /dev/null
+++ b/arch/arm64/include/asm/mmzone.h
@@ -0,0 +1,12 @@
+#ifndef __ASM_MMZONE_H
+#define __ASM_MMZONE_H
+
+#ifdef CONFIG_NUMA
+
+#include <asm/numa.h>
+
+extern struct pglist_data *node_data[];
+#define NODE_DATA(nid)		(node_data[(nid)])
+
+#endif /* CONFIG_NUMA */
+#endif /* __ASM_MMZONE_H */
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
new file mode 100644
index 0000000..574267f
--- /dev/null
+++ b/arch/arm64/include/asm/numa.h
@@ -0,0 +1,43 @@
+#ifndef __ASM_NUMA_H
+#define __ASM_NUMA_H
+
+#include <asm/topology.h>
+
+#ifdef CONFIG_NUMA
+
+/* currently, arm64 implements flat NUMA topology */
+#define parent_node(node)	(node)
+
+int __node_distance(int from, int to);
+#define node_distance(a, b) __node_distance(a, b)
+
+extern nodemask_t numa_nodes_parsed __initdata;
+
+/* Mappings between node number and cpus on that node. */
+extern cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
+void numa_clear_node(unsigned int cpu);
+
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+const struct cpumask *cpumask_of_node(int node);
+#else
+/* Returns a pointer to the cpumask of CPUs on Node 'node'. */
+static inline const struct cpumask *cpumask_of_node(int node)
+{
+	return node_to_cpumask_map[node];
+}
+#endif
+
+void __init arm64_numa_init(void);
+int __init numa_add_memblk(int nodeid, u64 start, u64 end);
+void __init numa_set_distance(int from, int to, int distance);
+void __init numa_free_distance(void);
+void numa_store_cpu_info(unsigned int cpu);
+
+#else	/* CONFIG_NUMA */
+
+static inline void numa_store_cpu_info(unsigned int cpu) { }
+static inline void arm64_numa_init(void) { }
+
+#endif	/* CONFIG_NUMA */
+
+#endif	/* __ASM_NUMA_H */
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index a3e9d6f..8b57339 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -22,6 +22,16 @@ void init_cpu_topology(void);
 void store_cpu_topology(unsigned int cpuid);
 const struct cpumask *cpu_coregroup_mask(int cpu);
 
+#ifdef CONFIG_NUMA
+
+struct pci_bus;
+int pcibus_to_node(struct pci_bus *bus);
+#define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ?		\
+				 cpu_all_mask :				\
+				 cpumask_of_node(pcibus_to_node(bus)))
+
+#endif /* CONFIG_NUMA */
+
 #include <asm-generic/topology.h>
 
 #endif /* _ASM_ARM_TOPOLOGY_H */
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index b3d098b..65e6b7d 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -76,6 +76,16 @@ int raw_pci_write(unsigned int domain, unsigned int bus,
 	return -ENXIO;
 }
 
+#ifdef CONFIG_NUMA
+
+int pcibus_to_node(struct pci_bus *bus)
+{
+	return dev_to_node(&bus->dev);
+}
+EXPORT_SYMBOL(pcibus_to_node);
+
+#endif
+
 #ifdef CONFIG_ACPI
 /* Root bridge scanning */
 struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479..d9b9761 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -53,6 +53,7 @@
 #include <asm/cpufeature.h>
 #include <asm/cpu_ops.h>
 #include <asm/kasan.h>
+#include <asm/numa.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
 #include <asm/smp_plat.h>
@@ -372,6 +373,9 @@ static int __init topology_init(void)
 {
 	int i;
 
+	for_each_online_node(i)
+		register_one_node(i);
+
 	for_each_possible_cpu(i) {
 		struct cpu *cpu = &per_cpu(cpu_data.cpu, i);
 		cpu->hotpluggable = 1;
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index b1adc51..d6e7d6a 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -45,6 +45,7 @@
 #include <asm/cputype.h>
 #include <asm/cpu_ops.h>
 #include <asm/mmu_context.h>
+#include <asm/numa.h>
 #include <asm/pgtable.h>
 #include <asm/pgalloc.h>
 #include <asm/processor.h>
@@ -125,6 +126,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
 static void smp_store_cpu_info(unsigned int cpuid)
 {
 	store_cpu_topology(cpuid);
+	numa_store_cpu_info(cpuid);
 }
 
 /*
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index 57f57fd..54bb209 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -4,6 +4,7 @@ obj-y				:= dma-mapping.o extable.o fault.o init.o \
 				   context.o proc.o pageattr.o
 obj-$(CONFIG_HUGETLB_PAGE)	+= hugetlbpage.o
 obj-$(CONFIG_ARM64_PTDUMP)	+= dump.o
+obj-$(CONFIG_NUMA)		+= numa.o
 
 obj-$(CONFIG_KASAN)		+= kasan_init.o
 KASAN_SANITIZE_kasan_init.o	:= n
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3b061e..c39c670 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -37,6 +37,7 @@
 
 #include <asm/fixmap.h>
 #include <asm/memory.h>
+#include <asm/numa.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
 #include <asm/sizes.h>
@@ -77,6 +78,21 @@ static phys_addr_t __init max_zone_dma_phys(void)
 	return min(offset + (1ULL << 32), memblock_end_of_DRAM());
 }
 
+#ifdef CONFIG_NUMA
+
+static void __init zone_sizes_init(unsigned long min, unsigned long max)
+{
+	unsigned long max_zone_pfns[MAX_NR_ZONES]  = {0};
+
+	if (IS_ENABLED(CONFIG_ZONE_DMA))
+		max_zone_pfns[ZONE_DMA] = PFN_DOWN(max_zone_dma_phys());
+	max_zone_pfns[ZONE_NORMAL] = max;
+
+	free_area_init_nodes(max_zone_pfns);
+}
+
+#else
+
 static void __init zone_sizes_init(unsigned long min, unsigned long max)
 {
 	struct memblock_region *reg;
@@ -117,6 +133,8 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
 	free_area_init_node(0, zone_size, min, zhole_size);
 }
 
+#endif /* CONFIG_NUMA */
+
 #ifdef CONFIG_HAVE_ARCH_PFN_VALID
 int pfn_valid(unsigned long pfn)
 {
@@ -133,10 +151,15 @@ static void __init arm64_memory_present(void)
 static void __init arm64_memory_present(void)
 {
 	struct memblock_region *reg;
+	int nid = 0;
 
-	for_each_memblock(memory, reg)
-		memory_present(0, memblock_region_memory_base_pfn(reg),
-			       memblock_region_memory_end_pfn(reg));
+	for_each_memblock(memory, reg) {
+#ifdef CONFIG_NUMA
+		nid = reg->nid;
+#endif
+		memory_present(nid, memblock_region_memory_base_pfn(reg),
+				memblock_region_memory_end_pfn(reg));
+	}
 }
 #endif
 
@@ -181,7 +204,6 @@ void __init arm64_memblock_init(void)
 	dma_contiguous_reserve(arm64_dma_phys_limit);
 
 	memblock_allow_resize();
-	memblock_dump_all();
 }
 
 void __init bootmem_init(void)
@@ -193,6 +215,9 @@ void __init bootmem_init(void)
 
 	early_memtest(min << PAGE_SHIFT, max << PAGE_SHIFT);
 
+	max_pfn = max_low_pfn = max;
+
+	arm64_numa_init();
 	/*
 	 * Sparsemem tries to allocate bootmem in memory_present(), so must be
 	 * done after the fixed reservations.
@@ -203,7 +228,6 @@ void __init bootmem_init(void)
 	zone_sizes_init(min, max);
 
 	high_memory = __va((max << PAGE_SHIFT) - 1) + 1;
-	max_pfn = max_low_pfn = max;
 }
 
 #ifndef CONFIG_SPARSEMEM_VMEMMAP
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 58faeaa..44e3854 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -463,6 +463,7 @@ void __init paging_init(void)
 	zero_page = early_alloc(PAGE_SIZE);
 
 	bootmem_init();
+	memblock_dump_all();
 
 	empty_zero_page = virt_to_page(zero_page);
 
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
new file mode 100644
index 0000000..60f19a2
--- /dev/null
+++ b/arch/arm64/mm/numa.c
@@ -0,0 +1,387 @@
+/*
+ * NUMA support, based on the x86 implementation.
+ *
+ * Copyright (C) 2015 Cavium Inc.
+ * Author: Ganapatrao Kulkarni <gkulkarni at 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/bootmem.h>
+#include <linux/memblock.h>
+#include <linux/module.h>
+
+struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
+EXPORT_SYMBOL(node_data);
+nodemask_t numa_nodes_parsed __initdata;
+static int cpu_to_node_map[NR_CPUS] = { [0 ... NR_CPUS-1] = NUMA_NO_NODE };
+
+static int numa_off;
+static int numa_distance_cnt;
+static u8 *numa_distance;
+
+static __init int numa_parse_early_param(char *opt)
+{
+	if (!opt)
+		return -EINVAL;
+	if (!strncmp(opt, "off", 3)) {
+		pr_info("%s\n", "NUMA turned off");
+		numa_off = 1;
+	}
+	return 0;
+}
+early_param("numa", numa_parse_early_param);
+
+cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
+EXPORT_SYMBOL(node_to_cpumask_map);
+
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+
+/*
+ * Returns a pointer to the bitmask of CPUs on Node 'node'.
+ */
+const struct cpumask *cpumask_of_node(int node)
+{
+	if (WARN_ON(node >= nr_node_ids))
+		return cpu_none_mask;
+
+	if (WARN_ON(node_to_cpumask_map[node] == NULL))
+		return cpu_online_mask;
+
+	return node_to_cpumask_map[node];
+}
+EXPORT_SYMBOL(cpumask_of_node);
+
+#endif
+
+static void map_cpu_to_node(unsigned int cpu, int nid)
+{
+	set_cpu_numa_node(cpu, nid);
+	if (nid >= 0)
+		cpumask_set_cpu(cpu, node_to_cpumask_map[nid]);
+}
+
+static void unmap_cpu_to_node(unsigned int cpu)
+{
+	int nid = cpu_to_node(cpu);
+
+	if (nid >= 0)
+		cpumask_clear_cpu(cpu, node_to_cpumask_map[nid]);
+	set_cpu_numa_node(cpu, NUMA_NO_NODE);
+}
+
+void numa_clear_node(unsigned int cpu)
+{
+	unmap_cpu_to_node(cpu);
+}
+
+/*
+ * Allocate node_to_cpumask_map based on number of available nodes
+ * Requires node_possible_map to be valid.
+ *
+ * Note: cpumask_of_node() is not valid until after this is done.
+ * (Use CONFIG_DEBUG_PER_CPU_MAPS to check this.)
+ */
+static void __init setup_node_to_cpumask_map(void)
+{
+	unsigned int cpu;
+	int node;
+
+	/* setup nr_node_ids if not done yet */
+	if (nr_node_ids == MAX_NUMNODES)
+		setup_nr_node_ids();
+
+	/* allocate and clear the mapping */
+	for (node = 0; node < nr_node_ids; node++) {
+		alloc_bootmem_cpumask_var(&node_to_cpumask_map[node]);
+		cpumask_clear(node_to_cpumask_map[node]);
+	}
+
+	for_each_possible_cpu(cpu)
+		set_cpu_numa_node(cpu, NUMA_NO_NODE);
+
+	/* cpumask_of_node() will now work */
+	pr_debug("NUMA: Node to cpumask map for %d nodes\n", nr_node_ids);
+}
+
+/*
+ *  Set the cpu to node and mem mapping
+ */
+void numa_store_cpu_info(unsigned int cpu)
+{
+	map_cpu_to_node(cpu, numa_off ? 0 : cpu_to_node_map[cpu]);
+}
+
+/**
+ * numa_add_memblk - Set node id to memblk
+ * @nid: NUMA node ID of the new memblk
+ * @start: Start address of the new memblk
+ * @size:  Size of the new memblk
+ *
+ * RETURNS:
+ * 0 on success, -errno on failure.
+ */
+int __init numa_add_memblk(int nid, u64 start, u64 size)
+{
+	int ret;
+
+	ret = memblock_set_node(start, size, &memblock.memory, nid);
+	if (ret < 0) {
+		pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node %d\n",
+			start, (start + size - 1), nid);
+		return ret;
+	}
+
+	node_set(nid, numa_nodes_parsed);
+	pr_info("NUMA: Adding memblock [0x%llx - 0x%llx] on node %d\n",
+			start, (start + size - 1), nid);
+	return ret;
+}
+EXPORT_SYMBOL(numa_add_memblk);
+
+/**
+ * Initialize NODE_DATA for a node on the local memory
+ */
+static void __init setup_node_data(int nid, u64 start_pfn, u64 end_pfn)
+{
+	const size_t nd_size = roundup(sizeof(pg_data_t), SMP_CACHE_BYTES);
+	u64 nd_pa;
+	void *nd;
+	int tnid;
+
+	pr_info("NUMA: Initmem setup node %d [mem %#010Lx-%#010Lx]\n",
+			nid, start_pfn << PAGE_SHIFT,
+			(end_pfn << PAGE_SHIFT) - 1);
+
+	nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
+	nd = __va(nd_pa);
+
+	/* report and initialize */
+	pr_info("NUMA: NODE_DATA [mem %#010Lx-%#010Lx]\n",
+		nd_pa, nd_pa + nd_size - 1);
+	tnid = early_pfn_to_nid(nd_pa >> PAGE_SHIFT);
+	if (tnid != nid)
+		pr_info("NUMA: NODE_DATA(%d) on node %d\n", nid, tnid);
+
+	node_data[nid] = nd;
+	memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
+	NODE_DATA(nid)->node_id = nid;
+	NODE_DATA(nid)->node_start_pfn = start_pfn;
+	NODE_DATA(nid)->node_spanned_pages = end_pfn - start_pfn;
+}
+
+/**
+ * numa_free_distance
+ *
+ * The current table is freed.
+ */
+void __init numa_free_distance(void)
+{
+	size_t size;
+
+	if (!numa_distance)
+		return;
+
+	size = numa_distance_cnt * numa_distance_cnt *
+		sizeof(numa_distance[0]);
+
+	memblock_free(__pa(numa_distance), size);
+	numa_distance_cnt = 0;
+	numa_distance = NULL;
+}
+
+/**
+ *
+ * Create a new NUMA distance table.
+ *
+ */
+static int __init numa_alloc_distance(void)
+{
+	size_t size;
+	u64 phys;
+	int i, j;
+
+	size = nr_node_ids * nr_node_ids * sizeof(numa_distance[0]);
+	phys = memblock_find_in_range(0, PFN_PHYS(max_pfn),
+				      size, PAGE_SIZE);
+	if (WARN_ON(!phys))
+		return -ENOMEM;
+
+	memblock_reserve(phys, size);
+
+	numa_distance = __va(phys);
+	numa_distance_cnt = nr_node_ids;
+
+	/* fill with the default distances */
+	for (i = 0; i < numa_distance_cnt; i++)
+		for (j = 0; j < numa_distance_cnt; j++)
+			numa_distance[i * numa_distance_cnt + j] = i == j ?
+				LOCAL_DISTANCE : REMOTE_DISTANCE;
+
+	pr_debug("NUMA: Initialized distance table, cnt=%d\n",
+			numa_distance_cnt);
+
+	return 0;
+}
+
+/**
+ * numa_set_distance - Set inter node NUMA distance from node to node.
+ * @from: the 'from' node to set distance
+ * @to: the 'to'  node to set distance
+ * @distance: NUMA distance
+ *
+ * Set the distance from node @from to @to to @distance.
+ * If distance table doesn't exist, a warning is printed.
+ *
+ * If @from or @to is higher than the highest known node or lower than zero
+ * or @distance doesn't make sense, the call is ignored.
+ *
+ */
+void __init numa_set_distance(int from, int to, int distance)
+{
+	if (!numa_distance) {
+		pr_warn_once("NUMA: Warning: distance table not allocated yet\n");
+		return;
+	}
+
+	if (from >= numa_distance_cnt || to >= numa_distance_cnt ||
+			from < 0 || to < 0) {
+		pr_warn_once("NUMA: Warning: node ids are out of bound, from=%d to=%d distance=%d\n",
+			    from, to, distance);
+		return;
+	}
+
+	if ((u8)distance != distance ||
+	    (from == to && distance != LOCAL_DISTANCE)) {
+		pr_warn_once("NUMA: Warning: invalid distance parameter, from=%d to=%d distance=%d\n",
+			     from, to, distance);
+		return;
+	}
+
+	numa_distance[from * numa_distance_cnt + to] = distance;
+}
+EXPORT_SYMBOL(numa_set_distance);
+
+/**
+ * Return NUMA distance @from to @to
+ */
+int __node_distance(int from, int to)
+{
+	if (from >= numa_distance_cnt || to >= numa_distance_cnt)
+		return from == to ? LOCAL_DISTANCE : REMOTE_DISTANCE;
+	return numa_distance[from * numa_distance_cnt + to];
+}
+EXPORT_SYMBOL(__node_distance);
+
+static int __init numa_register_nodes(void)
+{
+	int nid;
+	struct memblock_region *mblk;
+
+	/* Check that valid nid is set to memblks */
+	for_each_memblock(memory, mblk)
+		if (mblk->nid == NUMA_NO_NODE || mblk->nid >= MAX_NUMNODES) {
+			pr_warn("NUMA: Warning: invalid memblk node %d [mem %#010Lx-%#010Lx]\n",
+				mblk->nid, mblk->base, mblk->base + mblk->size - 1);
+			return -EINVAL;
+		}
+
+	/* Finally register nodes. */
+	for_each_node_mask(nid, numa_nodes_parsed) {
+		unsigned long start_pfn, end_pfn;
+
+		get_pfn_range_for_nid(nid, &start_pfn, &end_pfn);
+		setup_node_data(nid, start_pfn, end_pfn);
+		node_set_online(nid);
+	}
+
+	/* Setup online nodes to actual nodes*/
+	node_possible_map = numa_nodes_parsed;
+
+	return 0;
+}
+
+static int __init numa_init(int (*init_func)(void))
+{
+	int ret;
+
+	nodes_clear(numa_nodes_parsed);
+	nodes_clear(node_possible_map);
+	nodes_clear(node_online_map);
+	numa_free_distance();
+
+	ret = init_func();
+	if (ret < 0)
+		return ret;
+
+	if (nodes_empty(numa_nodes_parsed))
+		return -EINVAL;
+
+	ret = numa_register_nodes();
+	if (ret < 0)
+		return ret;
+
+	ret = numa_alloc_distance();
+	if (ret < 0)
+		return ret;
+
+	setup_node_to_cpumask_map();
+
+	/* init boot processor */
+	cpu_to_node_map[0] = 0;
+	map_cpu_to_node(0, 0);
+
+	return 0;
+}
+
+/**
+ * dummy_numa_init - Fallback dummy NUMA init
+ *
+ * Used if there's no underlying NUMA architecture, NUMA initialization
+ * fails, or NUMA is disabled on the command line.
+ *
+ * Must online at least one node (node 0) and add memory blocks that cover all
+ * allowed memory. It is unlikely that this function fails.
+ */
+static int __init dummy_numa_init(void)
+{
+	int ret;
+	struct memblock_region *mblk;
+
+	pr_info("%s\n", "No NUMA configuration found");
+	pr_info("NUMA: Faking a node at [mem %#018Lx-%#018Lx]\n",
+	       0LLU, PFN_PHYS(max_pfn) - 1);
+
+	for_each_memblock(memory, mblk) {
+		ret = numa_add_memblk(0, mblk->base, mblk->size);
+		if (!ret)
+			continue;
+
+		pr_err("NUMA init failed\n");
+		return ret;
+	}
+
+	numa_off = 1;
+	return 0;
+}
+
+/**
+ * arm64_numa_init - Initialize NUMA
+ *
+ * Try each configured NUMA initialization method until one succeeds.  The
+ * last fallback is dummy single node config encomapssing whole memory.
+ */
+void __init arm64_numa_init(void)
+{
+	numa_init(dummy_numa_init);
+}
-- 
1.8.1.4



From leo.yan at linaro.org  Tue Feb  2 02:09:38 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Tue,  2 Feb 2016 18:09:38 +0800
Subject: [PATCH v6 0/4] mailbox: hisilicon: add Hi6220 mailbox driver
Message-ID: <1454407782-24674-1-git-send-email-leo.yan@linaro.org>

Hi6220 mailbox supports up to 32 channels. Each channel is unidirectional
with a maximum message size of 8 words. I/O is performed using register
access (there is no DMA) and the cell raises an interrupt when messages
are received.

This patch series is to implement Hi6220 mailbox driver. It registers
two channels into framework for communication with MCU, one is tx channel
and another is rx channel. Now mailbox driver is used to send message to
MCU to control dynamic voltage and frequency scaling for CPU, GPU and DDR.

Changes from v5:
* Refine to use mailbox three specifiers for client driver, so add xlate
  callback function in mailbox driver to support these specifiers
* Refine document for property "hi6220,mbox-tx-noirq"

Changes from v4:
* According to Jassi's suggestion, using DT binding to register channels
* Change to use operating-points-v2 to register operating points

Changes from v3:
* The patch series for enabling idle state for Hi6220 has reserved memory
  regions, so this series will not include it anymore
* Refined mailbox driver according to Jassi's suggestion;
  Removed kfifo from mailbox driver;
  Removed spinlock for ipc registers accessing, due every channel has its
  own dedicated bit in ipc register and readl/writel will introduce memory
  barrier, so don't need spinlock to protect ipc registers accessing
* After mailbox driver is ready, can use patch 4 to enable CPU's OPPs and
  stub clock driver; finally can enable CPUFreq driver for CPU frequency
  scaling

Changes from v2:
* Get rid of unused memory regions from memory node in DT, and don't use
  reserved-memory node according to Mark and Leif's suggestion; Haojian also
  has updated UEFI for efi memory info

Changes from v1:
* Correct lock usage for SMP scenario

Changes from RFC:
* According to Jassi's review, totally remove the abstract common driver
  layer and only commit driver dedicated for Hi6220
* According to Paul Bolle's review, fix typo issue for Kconfig and remove
  unnecessary dependency with OF and fix minor for mailbox driver
* Refine a little for dts nodes


Leo Yan (4):
  dt-bindings: mailbox: Document Hi6220 mailbox driver
  mailbox: Hi6220: add mailbox driver
  arm64: dts: add mailbox node for Hi6220
  arm64: dts: add Hi6220's stub clock node

 .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  |  74 ++++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi          |  64 ++++
 drivers/mailbox/Kconfig                            |   8 +
 drivers/mailbox/Makefile                           |   2 +
 drivers/mailbox/hi6220-mailbox.c                   | 395 +++++++++++++++++++++
 5 files changed, 543 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
 create mode 100644 drivers/mailbox/hi6220-mailbox.c

-- 
1.9.1



From gkulkarni at caviumnetworks.com  Tue Feb  2 02:09:17 2016
From: gkulkarni at caviumnetworks.com (Ganapatrao Kulkarni)
Date: Tue, 2 Feb 2016 15:39:17 +0530
Subject: [PATCH v10 2/8] Documentation, dt, numa: dt bindings for numa.
In-Reply-To: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
References: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
Message-ID: <1454407763-1017-3-git-send-email-gkulkarni@caviumnetworks.com>

DT bindings for numa mapping of memory, cores and IOs.

Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
---
 Documentation/devicetree/bindings/numa.txt | 272 +++++++++++++++++++++++++++++
 1 file changed, 272 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/numa.txt

diff --git a/Documentation/devicetree/bindings/numa.txt b/Documentation/devicetree/bindings/numa.txt
new file mode 100644
index 0000000..ec5ed7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/numa.txt
@@ -0,0 +1,272 @@
+==============================================================================
+NUMA binding description.
+==============================================================================
+
+==============================================================================
+1 - Introduction
+==============================================================================
+
+Systems employing a Non Uniform Memory Access (NUMA) architecture contain
+collections of hardware resources including processors, memory, and I/O buses,
+that comprise what is commonly known as a NUMA node.
+Processor accesses to memory within the local NUMA node is generally faster
+than processor accesses to memory outside of the local NUMA node.
+DT defines interfaces that allow the platform to convey NUMA node
+topology information to OS.
+
+==============================================================================
+2 - numa-node-id
+==============================================================================
+
+For the purpose of identification, each NUMA node is associated with a unique
+token known as a node id. For the purpose of this binding
+a node id is a 32-bit integer.
+
+A device node is associated with a NUMA node by the presence of a
+numa-node-id property which contains the node id of the device.
+
+Example:
+	/* numa node 0 */
+	numa-node-id = <0>;
+
+	/* numa node 1 */
+	numa-node-id = <1>;
+
+==============================================================================
+3 - distance-map
+==============================================================================
+
+The device tree node distance-map describes the relative
+distance (memory latency) between all numa nodes.
+
+- compatible : Should at least contain "numa-distance-map-v1".
+
+- distance-matrix
+  This property defines a matrix to describe the relative distances
+  between all numa nodes.
+  It is represented as a list of node pairs and their relative distance.
+
+  Note:
+	1. Each entry represents distance from first node to second node.
+	The distances are equal in either direction.
+	2. The distance from a node to self (local distance) is represented
+	with value 10 and all internode distance should be represented with
+	a value greater than 10.
+	3. distance-matrix should have entries in lexicographical ascending
+	order of nodes.
+	4. There must be only one device node distance-map which must reside in the root node.
+
+Example:
+	4 nodes connected in mesh/ring topology as below,
+
+		0_______20______1
+		|               |
+		|               |
+		20             20
+		|               |
+		|               |
+		|_______________|
+		3       20      2
+
+	if relative distance for each hop is 20,
+	then internode distance would be,
+	      0 -> 1 = 20
+	      1 -> 2 = 20
+	      2 -> 3 = 20
+	      3 -> 0 = 20
+	      0 -> 2 = 40
+	      1 -> 3 = 40
+
+     and dt presentation for this distance matrix is,
+
+		distance-map {
+			 compatible = "numa-distance-map-v1";
+			 distance-matrix = <0 0  10>,
+					   <0 1  20>,
+					   <0 2  40>,
+					   <0 3  20>,
+					   <1 0  20>,
+					   <1 1  10>,
+					   <1 2  20>,
+					   <1 3  40>,
+					   <2 0  40>,
+					   <2 1  20>,
+					   <2 2  10>,
+					   <2 3  20>,
+					   <3 0  20>,
+					   <3 1  40>,
+					   <3 2  20>,
+					   <3 3  10>;
+		};
+
+==============================================================================
+4 - Example dts
+==============================================================================
+
+Dual socket system consists of 2 boards connected through ccn bus and
+each board having one socket/soc of 8 cpus, memory and pci bus.
+
+	memory at c00000 {
+		device_type = "memory";
+		reg = <0x0 0xc00000 0x0 0x80000000>;
+		/* node 0 */
+		numa-node-id = <0>;
+	};
+
+	memory at 10000000000 {
+		device_type = "memory";
+		reg = <0x100 0x0 0x0 0x80000000>;
+		/* node 1 */
+		numa-node-id = <1>;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x0>;
+			enable-method = "psci";
+			/* node 0 */
+			numa-node-id = <0>;
+		};
+		cpu at 1 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x1>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 2 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x2>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 3 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x3>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 4 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x4>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 5 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x5>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 6 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x6>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 7 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x7>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 8 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x8>;
+			enable-method = "psci";
+			/* node 1 */
+			numa-node-id = <1>;
+		};
+		cpu at 9 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x9>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at a {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xa>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at b {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xb>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at c {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xc>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at d {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xd>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at e {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xe>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at f {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xf>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+	};
+
+	pcie0: pcie0 at 848000000000 {
+		compatible = "arm,armv8";
+		device_type = "pci";
+		bus-range = <0 255>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		reg = <0x8480 0x00000000 0 0x10000000>;  /* Configuration space */
+		ranges = <0x03000000 0x8010 0x00000000 0x8010 0x00000000 0x70 0x00000000>;
+		/* node 0 */
+		numa-node-id = <0>;
+        };
+
+	pcie1: pcie1 at 948000000000 {
+		compatible = "arm,armv8";
+		device_type = "pci";
+		bus-range = <0 255>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		reg = <0x9480 0x00000000 0 0x10000000>;  /* Configuration space */
+		ranges = <0x03000000 0x9010 0x00000000 0x9010 0x00000000 0x70 0x00000000>;
+		/* node 1 */
+		numa-node-id = <1>;
+        };
+
+	distance-map {
+		compatible = "numa-distance-map-v1";
+		distance-matrix = <0 0 10>,
+				  <0 1 20>,
+				  <1 1 10>;
+	};
-- 
1.8.1.4



From wens at csie.org  Tue Feb  2 02:09:59 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue, 2 Feb 2016 18:09:59 +0800
Subject: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
In-Reply-To: <20160202100046.GM4652@lukather>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-6-git-send-email-andre.przywara@arm.com>
 <20160201182754.GA14737@excalibur.cnev.de>
 <56AFE0EC.8080207@arm.com> <20160202100046.GM4652@lukather>
Message-ID: <CAGb2v66JGbuQJUh5k6guhKrN4GqMmomyBFtqgcH09Zm-pVGxPw@mail.gmail.com>

On Tue, Feb 2, 2016 at 6:00 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> Hi Andre,
>
> On Mon, Feb 01, 2016 at 10:49:16PM +0000, Andr? Przywara wrote:
>> On 01/02/16 18:27, Karsten Merker wrote:
>>
>> Hi Karsten,
>>
>> thank you very much for your feedback!
>>
>> > On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote:
>> >> Based on the Allwinner A64 user manual and on the previous sunxi
>> >> pinctrl drivers this introduces the pin multiplex assignments for
>> >> the ARMv8 Allwinner A64 SoC.
>> >> Port A is apparently used for the fixed function DRAM controller, so
>> >> the ports start at B here (the manual mentions "n from 1 to 7", so
>> >> not starting at 0).
>> >>
>> >> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>> >> ---
>> >>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
>> >>  arch/arm64/Kconfig.platforms                       |   1 +
>> >>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
>> >>  drivers/pinctrl/sunxi/Makefile                     |   1 +
>> >>  drivers/pinctrl/sunxi/pinctrl-a64.c                | 606 +++++++++++++++++++++
>> >>  5 files changed, 613 insertions(+)
>> >>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>> >> index 9213b27..9050002 100644
>> >> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>> >> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>> >> @@ -21,6 +21,7 @@ Required properties:
>> >>    "allwinner,sun9i-a80-r-pinctrl"
>> >>    "allwinner,sun8i-a83t-pinctrl"
>> >>    "allwinner,sun8i-h3-pinctrl"
>> >> +  "allwinner,a64-pinctrl"
>> >
>> > Hello,
>> >
>> > on all other Allwinner SoCs we use the SoC family as part of the
>> > compatible, as well as in the names of the Kconfig options. To
>> > keep things consistent, I would like to propose doing the same on
>> > Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of
>> > allwinner,a64-pinctrl.
>>
>> Yes, I have been told this already. However I don't like this idea so
>> much, for the following reasons:
>> a) It is mostly redundant. The actual SoC (marketing) name is unique,
>> there is no sun6i-a20 or sun7i-a23.
>
> At the same time, the family name is mostly valid too.
>
> We do share some DTSI across some SoCs already by their family name
> (sun5i.dtsi for the A10s/A13/R8, sun8i-a23-a33.dtsi for the A23 and
> A33, etc.)
>
>> b) It is not even helpful. If I got Maxime correctly, then the newer
>> sunxi generation numbers depend on the ARM _cores_ used in the SoC,
>> which is frankly the least interesting part from a Linux support
>> perspective. I would see some sense if it would reflect the generation
>> of IP blocks used, but so it is even more confusing to see that
>> sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely
>> different beast. The Allwinner marketing name tells you that, but the
>> sunxi one does not.
>
> The opposite can be said too.
>
> The A31 is quite different from the A33, while the A83 is much closer
> to the H3 than it is to the A80. Their marketing scheme is messy. In
> all aspects. We have a scheme that worked, I'd really like to stick
> with it.
>
>> c) It is very confusing for people not dealing with it everyday. Just
>> because I own a BananaPi I know that the A20 is sun7i, but I am totally
>> lost when it comes to all the other names. And even now it took me about
>> a minute to find the appropriate Wiki page which explains part of that
>> story.
>> d) Most importantly ;-): It kills TAB completion, unless you know the
>> sunxi number, which is mostly not true as pointed out in c)
>
> Both of these are true, but are about the DT filenames, and not the
> compatibles. I'd agree with you on this one now that we have
> per-vendor subfolders in boot/dts, but it was not the case before, and
> I'm pretty sure that to anyone that is not aware of the Allwinner SoCs
> names, having an A<number>.dtsi in arch/arm/boot/dts, it would be
> about a Cortex-A<number>, and definitely not an SoC from some random
> vendor.
>
> So, droping it in the filenames, why not. But I'd really like to keep
> the same compatible scheme.

If we do end up dropping it from the filenames, can you (Andr?) update
MAINTAINERS to add "arch/arm64/boot/dts/sunxi/" to the sunxi entry?

Thanks.
ChenYu


From leo.yan at linaro.org  Tue Feb  2 02:09:39 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Tue,  2 Feb 2016 18:09:39 +0800
Subject: [PATCH v6 1/4] dt-bindings: mailbox: Document Hi6220 mailbox driver
In-Reply-To: <1454407782-24674-1-git-send-email-leo.yan@linaro.org>
References: <1454407782-24674-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1454407782-24674-2-git-send-email-leo.yan@linaro.org>

Document DT binding for Hisilicon Hi6220 mailbox driver.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  | 74 ++++++++++++++++++++++
 1 file changed, 74 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt

diff --git a/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
new file mode 100644
index 0000000..8508c8a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
@@ -0,0 +1,74 @@
+Hisilicon Hi6220 Mailbox Driver
+===============================
+
+Hisilicon Hi6220 mailbox supports up to 32 channels. Each channel
+is unidirectional with a maximum message size of 8 words. I/O is
+performed using register access (there is no DMA) and the cell
+raises an interrupt when messages are received.
+
+Mailbox Device Node:
+====================
+
+Required properties:
+--------------------
+- compatible:		Shall be "hisilicon,hi6220-mbox"
+- reg:			Contains the mailbox register address range (base
+			address and length); the first item is for IPC
+			registers, the second item is shared buffer for
+			slots.
+- #mbox-cells:		Common mailbox binding property to identify the number
+			of cells required for the mailbox specifier. Must be 3.
+			<&phandle slot_id dst_irq ack_irq>
+			  phandle: Label name of mailbox controller
+			  slot_id: Slot id used either for TX or RX
+			  dst_irq: IRQ identifier index number which used by MCU
+			  ack_irq: IRQ identifier index number with generating a
+			           TX/RX interrupt to application processor,
+				   mailbox driver uses it to acknowledge interrupt
+- interrupts:		Contains the interrupt information for the mailbox
+			device. The format is dependent on which interrupt
+			controller the SoCs use.
+
+Optional Properties:
+--------------------
+- hi6220,mbox-tx-noirq: Property of MCU firmware's feature, so mailbox driver
+			use this flag to ask MCU to enable "automatic idle
+			flag" mode or IRQ generated mode to acknowledge a TX
+			completion.
+
+Example:
+--------
+
+	mailbox: mailbox at F7510000 {
+		compatible = "hisilicon,hi6220-mbox";
+		reg = <0x0 0xF7510000 0x0 0x1000>, /* IPC_S */
+		      <0x0 0x06DFF800 0x0 0x0800>; /* Mailbox */
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+		#mbox-cells = <3>;
+	};
+
+
+Mailbox client
+===============
+
+Required properties:
+--------------------
+- compatible:		Many (See the client docs).
+- mboxes:		Standard property to specify a Mailbox (See ./mailbox.txt)
+			Cells must match 'mbox-cells' (See Mailbox Device Node above).
+
+Optional Properties:
+--------------------
+- mbox-names:		Name given to channels seen in the 'mboxes' property.
+
+Example:
+--------
+
+	stub_clock: stub_clock {
+		compatible = "hisilicon,hi6220-stub-clk";
+		hisilicon,hi6220-clk-sram = <&sram>;
+		#clock-cells = <1>;
+		mbox-names = "mbox-tx", "mbox-rx";
+		mboxes = <&mailbox 1 0 11>, <&mailbox 0 1 10>;
+	};
-- 
1.9.1



From leo.yan at linaro.org  Tue Feb  2 02:09:40 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Tue,  2 Feb 2016 18:09:40 +0800
Subject: [PATCH v6 2/4] mailbox: Hi6220: add mailbox driver
In-Reply-To: <1454407782-24674-1-git-send-email-leo.yan@linaro.org>
References: <1454407782-24674-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1454407782-24674-3-git-send-email-leo.yan@linaro.org>

Add driver for Hi6220 mailbox, the mailbox communicates with MCU; for
sending data, it can support two methods for low level implementation:
one is to use interrupt as acknowledge, another is automatic mode which
without any acknowledge. These two methods have been supported in the
driver. For receiving data, it will depend on the interrupt to notify
the channel has incoming message.

Now mailbox driver is used to send message to MCU to control dynamic
voltage and frequency scaling for CPU, GPU and DDR.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 drivers/mailbox/Kconfig          |   8 +
 drivers/mailbox/Makefile         |   2 +
 drivers/mailbox/hi6220-mailbox.c | 395 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 405 insertions(+)
 create mode 100644 drivers/mailbox/hi6220-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 546d05f..b8bbeb0 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -78,6 +78,14 @@ config STI_MBOX
 	  Mailbox implementation for STMicroelectonics family chips with
 	  hardware for interprocessor communication.
 
+config HI6220_MBOX
+	tristate "Hi6220 Mailbox"
+	depends on ARCH_HISI
+	help
+	  An implementation of the hi6220 mailbox. It is used to send message
+	  between application processors and MCU. Say Y here if you want to
+	  build Hi6220 mailbox controller driver.
+
 config MAILBOX_TEST
 	tristate "Mailbox Test Client"
 	depends on OF
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 92435ef..565adda 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -17,3 +17,5 @@ obj-$(CONFIG_ALTERA_MBOX)	+= mailbox-altera.o
 obj-$(CONFIG_BCM2835_MBOX)	+= bcm2835-mailbox.o
 
 obj-$(CONFIG_STI_MBOX)		+= mailbox-sti.o
+
+obj-$(CONFIG_HI6220_MBOX)	+= hi6220-mailbox.o
diff --git a/drivers/mailbox/hi6220-mailbox.c b/drivers/mailbox/hi6220-mailbox.c
new file mode 100644
index 0000000..613722d
--- /dev/null
+++ b/drivers/mailbox/hi6220-mailbox.c
@@ -0,0 +1,395 @@
+/*
+ * Hisilicon's Hi6220 mailbox driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ * Copyright (c) 2015 Linaro Limited.
+ *
+ * Author: Leo Yan <leo.yan at linaro.org>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kfifo.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#define MBOX_CHAN_MAX			32
+
+#define MBOX_TX				0x1
+
+/* Mailbox message length: 8 words */
+#define MBOX_MSG_LEN			8
+
+/* Mailbox Registers */
+#define MBOX_OFF(m)			(0x40 * (m))
+#define MBOX_MODE_REG(m)		(MBOX_OFF(m) + 0x0)
+#define MBOX_DATA_REG(m)		(MBOX_OFF(m) + 0x4)
+
+#define MBOX_STATE_MASK			(0xF << 4)
+#define MBOX_STATE_IDLE			(0x1 << 4)
+#define MBOX_STATE_TX			(0x2 << 4)
+#define MBOX_STATE_RX			(0x4 << 4)
+#define MBOX_STATE_ACK			(0x8 << 4)
+#define MBOX_ACK_CONFIG_MASK		(0x1 << 0)
+#define MBOX_ACK_AUTOMATIC		(0x1 << 0)
+#define MBOX_ACK_IRQ			(0x0 << 0)
+
+/* IPC registers */
+#define ACK_INT_RAW_REG(i)		((i) + 0x400)
+#define ACK_INT_MSK_REG(i)		((i) + 0x404)
+#define ACK_INT_STAT_REG(i)		((i) + 0x408)
+#define ACK_INT_CLR_REG(i)		((i) + 0x40c)
+#define ACK_INT_ENA_REG(i)		((i) + 0x500)
+#define ACK_INT_DIS_REG(i)		((i) + 0x504)
+#define DST_INT_RAW_REG(i)		((i) + 0x420)
+
+
+struct hi6220_mbox_chan {
+
+	/*
+	 * Description for channel's hardware info:
+	 *  - direction: tx or rx
+	 *  - dst irq: peer core's irq number
+	 *  - ack irq: local irq number
+	 *  - slot number
+	 */
+	unsigned int dir, dst_irq, ack_irq;
+	unsigned int slot;
+
+	struct hi6220_mbox *parent;
+};
+
+struct hi6220_mbox {
+	struct device *dev;
+
+	int irq;
+
+	/* flag of enabling tx's irq mode */
+	bool tx_irq_mode;
+
+	/* region for ipc event */
+	void __iomem *ipc;
+
+	/* region for mailbox */
+	void __iomem *base;
+
+	unsigned int chan_num;
+	struct hi6220_mbox_chan *mchan;
+
+	void *irq_map_chan[MBOX_CHAN_MAX];
+	struct mbox_chan *chan;
+	struct mbox_controller controller;
+};
+
+static void mbox_set_state(struct hi6220_mbox *mbox,
+			   unsigned int slot, u32 val)
+{
+	u32 status;
+
+	status = readl(mbox->base + MBOX_MODE_REG(slot));
+	status = (status & ~MBOX_STATE_MASK) | val;
+	writel(status, mbox->base + MBOX_MODE_REG(slot));
+}
+
+static void mbox_set_mode(struct hi6220_mbox *mbox,
+			  unsigned int slot, u32 val)
+{
+	u32 mode;
+
+	mode = readl(mbox->base + MBOX_MODE_REG(slot));
+	mode = (mode & ~MBOX_ACK_CONFIG_MASK) | val;
+	writel(mode, mbox->base + MBOX_MODE_REG(slot));
+}
+
+static bool hi6220_mbox_last_tx_done(struct mbox_chan *chan)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+	u32 state;
+
+	/* Only set idle state for polling mode */
+	BUG_ON(mbox->tx_irq_mode);
+
+	state = readl(mbox->base + MBOX_MODE_REG(mchan->slot));
+	return ((state & MBOX_STATE_MASK) == MBOX_STATE_IDLE);
+}
+
+static int hi6220_mbox_send_data(struct mbox_chan *chan, void *msg)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+	unsigned int slot = mchan->slot;
+	u32 *buf = msg;
+	int i;
+
+	/* indicate as a TX channel */
+	mchan->dir = MBOX_TX;
+
+	mbox_set_state(mbox, slot, MBOX_STATE_TX);
+
+	if (mbox->tx_irq_mode)
+		mbox_set_mode(mbox, slot, MBOX_ACK_IRQ);
+	else
+		mbox_set_mode(mbox, slot, MBOX_ACK_AUTOMATIC);
+
+	for (i = 0; i < MBOX_MSG_LEN; i++)
+		writel(buf[i], mbox->base + MBOX_DATA_REG(slot) + i * 4);
+
+	/* trigger remote request */
+	writel(BIT(mchan->dst_irq), DST_INT_RAW_REG(mbox->ipc));
+	return 0;
+}
+
+static irqreturn_t hi6220_mbox_interrupt(int irq, void *p)
+{
+	struct hi6220_mbox *mbox = p;
+	struct hi6220_mbox_chan *mchan;
+	struct mbox_chan *chan;
+	unsigned int state, intr_bit, i;
+	u32 msg[MBOX_MSG_LEN];
+
+	state = readl(ACK_INT_STAT_REG(mbox->ipc));
+	if (!state) {
+		dev_warn(mbox->dev, "%s: spurious interrupt\n",
+			 __func__);
+		return IRQ_HANDLED;
+	}
+
+	while (state) {
+		intr_bit = __ffs(state);
+		state &= (state - 1);
+
+		chan = mbox->irq_map_chan[intr_bit];
+		if (!chan) {
+			dev_warn(mbox->dev, "%s: unexpected irq vector %d\n",
+				 __func__, intr_bit);
+			continue;
+		}
+
+		mchan = chan->con_priv;
+		if (mchan->dir == MBOX_TX)
+			mbox_chan_txdone(chan, 0);
+		else {
+			for (i = 0; i < MBOX_MSG_LEN; i++)
+				msg[i] = readl(mbox->base +
+					MBOX_DATA_REG(mchan->slot) + i * 4);
+
+			mbox_chan_received_data(chan, (void *)msg);
+		}
+
+		/* clear IRQ source */
+		writel(BIT(mchan->ack_irq), ACK_INT_CLR_REG(mbox->ipc));
+		mbox_set_state(mbox, mchan->slot, MBOX_STATE_IDLE);
+	}
+
+	return IRQ_HANDLED;
+}
+
+static int hi6220_mbox_startup(struct mbox_chan *chan)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+
+	mchan->dir = 0;
+
+	/* enable interrupt */
+	writel(BIT(mchan->ack_irq), ACK_INT_ENA_REG(mbox->ipc));
+	return 0;
+}
+
+static void hi6220_mbox_shutdown(struct mbox_chan *chan)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+
+	/* disable interrupt */
+	writel(BIT(mchan->ack_irq), ACK_INT_DIS_REG(mbox->ipc));
+	mbox->irq_map_chan[mchan->ack_irq] = NULL;
+}
+
+static struct mbox_chan_ops hi6220_mbox_ops = {
+	.send_data    = hi6220_mbox_send_data,
+	.startup      = hi6220_mbox_startup,
+	.shutdown     = hi6220_mbox_shutdown,
+	.last_tx_done = hi6220_mbox_last_tx_done,
+};
+
+static struct mbox_chan *hi6220_mbox_xlate(struct mbox_controller *controller,
+					   const struct of_phandle_args *spec)
+{
+	struct hi6220_mbox *mbox = dev_get_drvdata(controller->dev);
+	struct hi6220_mbox_chan *mchan;
+	struct mbox_chan *chan;
+	unsigned int i = spec->args[0];
+	unsigned int dst_irq = spec->args[1];
+	unsigned int ack_irq = spec->args[2];
+
+	/* Bounds checking */
+	if (i >= mbox->chan_num || dst_irq >= mbox->chan_num ||
+	    ack_irq >= mbox->chan_num) {
+		dev_err(mbox->dev,
+			"Invalid channel idx %d dst_irq %d ack_irq %d\n",
+			i, dst_irq, ack_irq);
+		return ERR_PTR(-EINVAL);
+	}
+
+	/* Is requested channel free? */
+	chan = &mbox->chan[i];
+	if (mbox->irq_map_chan[ack_irq] == (void *)chan) {
+		dev_err(mbox->dev, "Channel in use\n");
+		return ERR_PTR(-EBUSY);
+	}
+
+	mchan = chan->con_priv;
+	mchan->dst_irq = dst_irq;
+	mchan->ack_irq = ack_irq;
+
+	mbox->irq_map_chan[ack_irq] = (void *)chan;
+	return chan;
+}
+
+static const struct of_device_id hi6220_mbox_of_match[] = {
+	{ .compatible = "hisilicon,hi6220-mbox", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, hi6220_mbox_of_match);
+
+static int hi6220_mbox_probe(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	struct device *dev = &pdev->dev;
+	struct hi6220_mbox *mbox;
+	struct resource *res;
+	int i, err;
+
+	mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+	if (!mbox)
+		return -ENOMEM;
+
+	mbox->dev = dev;
+	mbox->chan_num = MBOX_CHAN_MAX;
+	mbox->mchan = devm_kzalloc(dev,
+		mbox->chan_num * sizeof(*mbox->mchan), GFP_KERNEL);
+	if (!mbox->mchan)
+		return -ENOMEM;
+
+	mbox->chan = devm_kzalloc(dev,
+		mbox->chan_num * sizeof(*mbox->chan), GFP_KERNEL);
+	if (!mbox->chan)
+		return -ENOMEM;
+
+	mbox->irq = platform_get_irq(pdev, 0);
+	if (mbox->irq < 0)
+		return mbox->irq;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mbox->ipc = devm_ioremap_resource(dev, res);
+	if (IS_ERR(mbox->ipc)) {
+		dev_err(dev, "ioremap ipc failed\n");
+		return PTR_ERR(mbox->ipc);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	mbox->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(mbox->base)) {
+		dev_err(dev, "ioremap buffer failed\n");
+		return PTR_ERR(mbox->base);
+	}
+
+	err = devm_request_irq(dev, mbox->irq, hi6220_mbox_interrupt, 0,
+			dev_name(dev), mbox);
+	if (err) {
+		dev_err(dev, "Failed to register a mailbox IRQ handler: %d\n",
+			err);
+		return -ENODEV;
+	}
+
+	mbox->controller.dev = dev;
+	mbox->controller.chans = &mbox->chan[0];
+	mbox->controller.num_chans = mbox->chan_num;
+	mbox->controller.ops = &hi6220_mbox_ops;
+	mbox->controller.of_xlate = hi6220_mbox_xlate;
+
+	for (i = 0; i < mbox->chan_num; i++) {
+		mbox->chan[i].con_priv = &mbox->mchan[i];
+		mbox->irq_map_chan[i] = NULL;
+
+		mbox->mchan[i].parent = mbox;
+		mbox->mchan[i].slot   = i;
+	}
+
+	/* mask and clear all interrupt vectors */
+	writel(0x0,  ACK_INT_MSK_REG(mbox->ipc));
+	writel(~0x0, ACK_INT_CLR_REG(mbox->ipc));
+
+	/* use interrupt for tx's ack */
+	if (of_find_property(node, "hi6220,mbox-tx-noirq", NULL))
+		mbox->tx_irq_mode = false;
+	else
+		mbox->tx_irq_mode = true;
+
+	if (mbox->tx_irq_mode)
+		mbox->controller.txdone_irq = true;
+	else {
+		mbox->controller.txdone_poll = true;
+		mbox->controller.txpoll_period = 5;
+	}
+
+	err = mbox_controller_register(&mbox->controller);
+	if (err) {
+		dev_err(dev, "Failed to register mailbox %d\n", err);
+		return err;
+	}
+
+	platform_set_drvdata(pdev, mbox);
+	dev_info(dev, "Mailbox enabled\n");
+	return 0;
+}
+
+static int hi6220_mbox_remove(struct platform_device *pdev)
+{
+	struct hi6220_mbox *mbox = platform_get_drvdata(pdev);
+
+	mbox_controller_unregister(&mbox->controller);
+	return 0;
+}
+
+static struct platform_driver hi6220_mbox_driver = {
+	.driver = {
+		.name = "hi6220-mbox",
+		.owner = THIS_MODULE,
+		.of_match_table = hi6220_mbox_of_match,
+	},
+	.probe	= hi6220_mbox_probe,
+	.remove	= hi6220_mbox_remove,
+};
+
+static int __init hi6220_mbox_init(void)
+{
+	return platform_driver_register(&hi6220_mbox_driver);
+}
+core_initcall(hi6220_mbox_init);
+
+static void __exit hi6220_mbox_exit(void)
+{
+	platform_driver_unregister(&hi6220_mbox_driver);
+}
+module_exit(hi6220_mbox_exit);
+
+MODULE_AUTHOR("Leo Yan <leo.yan at linaro.org>");
+MODULE_DESCRIPTION("Hi6220 mailbox driver");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1



From gkulkarni at caviumnetworks.com  Tue Feb  2 02:09:18 2016
From: gkulkarni at caviumnetworks.com (Ganapatrao Kulkarni)
Date: Tue, 2 Feb 2016 15:39:18 +0530
Subject: [PATCH v10 3/8] dt, numa: adding numa dt binding implementation.
In-Reply-To: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
References: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
Message-ID: <1454407763-1017-4-git-send-email-gkulkarni@caviumnetworks.com>

dt node parsing for numa topology is done using device property
numa-node-id and device node distance-map.

Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
---
 drivers/of/Kconfig   |  11 +++
 drivers/of/Makefile  |   1 +
 drivers/of/of_numa.c | 207 +++++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of.h   |   4 +
 4 files changed, 223 insertions(+)
 create mode 100644 drivers/of/of_numa.c

diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index e2a4841..8f9cc3a 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -112,4 +112,15 @@ config OF_OVERLAY
 	  While this option is selected automatically when needed, you can
 	  enable it manually to improve device tree unit test coverage.
 
+config OF_NUMA
+	bool "Device Tree NUMA support"
+	depends on NUMA
+	depends on OF
+	depends on ARM64
+	default y
+	help
+	  Enable Device Tree NUMA support.
+	  This enables the numa mapping of cpu, memory, io and
+	  inter node distances using dt bindings.
+
 endif # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 156c072..bee3fa9 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -14,5 +14,6 @@ obj-$(CONFIG_OF_MTD)	+= of_mtd.o
 obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
 obj-$(CONFIG_OF_RESOLVE)  += resolver.o
 obj-$(CONFIG_OF_OVERLAY) += overlay.o
+obj-$(CONFIG_OF_NUMA) += of_numa.o
 
 obj-$(CONFIG_OF_UNITTEST) += unittest-data/
diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
new file mode 100644
index 0000000..1142cdb
--- /dev/null
+++ b/drivers/of/of_numa.c
@@ -0,0 +1,207 @@
+/*
+ * OF NUMA Parsing support.
+ *
+ * Copyright (C) 2015 Cavium Inc.
+ * Author: Ganapatrao Kulkarni <gkulkarni at 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/of.h>
+#include <linux/of_fdt.h>
+
+/* define default numa node to 0 */
+#define DEFAULT_NODE 0
+
+/* Returns nid in the range [0..MAX_NUMNODES-1],
+ * or NUMA_NO_NODE if no valid numa-node-id entry found
+ * or DEFAULT_NODE if no numa-node-id entry exists
+ */
+static int of_numa_prop_to_nid(const __be32 *of_numa_prop, int length)
+{
+	int nid;
+
+	if (!of_numa_prop)
+		return DEFAULT_NODE;
+
+	if (length != sizeof(*of_numa_prop)) {
+		pr_warn("NUMA: Invalid of_numa_prop length %d found.\n",
+				length);
+		return NUMA_NO_NODE;
+	}
+
+	nid = of_read_number(of_numa_prop, 1);
+	if (nid >= MAX_NUMNODES) {
+		pr_warn("NUMA: Invalid numa node %d found.\n", nid);
+		return NUMA_NO_NODE;
+	}
+
+	return nid;
+}
+
+static int __init early_init_of_node_to_nid(unsigned long node)
+{
+	int length;
+	const __be32 *of_numa_prop;
+
+	of_numa_prop = of_get_flat_dt_prop(node, "numa-node-id", &length);
+
+	return of_numa_prop_to_nid(of_numa_prop, length);
+}
+
+/*
+ * Even though we connect cpus to numa domains later in SMP
+ * init, we need to know the node ids now for all cpus.
+*/
+static int __init early_init_parse_cpu_node(unsigned long node)
+{
+	int nid;
+	const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
+
+	if (type == NULL)
+		return 0;
+
+	if (strcmp(type, "cpu") != 0)
+		return 0;
+
+	nid = early_init_of_node_to_nid(node);
+	if (nid == NUMA_NO_NODE)
+		return -EINVAL;
+
+	node_set(nid, numa_nodes_parsed);
+	return 0;
+}
+
+static int __init early_init_parse_memory_node(unsigned long node)
+{
+	const __be32 *reg, *endp;
+	int length;
+	int nid;
+	const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
+
+	if (type == NULL)
+		return 0;
+
+	if (strcmp(type, "memory") != 0)
+		return 0;
+
+	nid = early_init_of_node_to_nid(node);
+	if (nid == NUMA_NO_NODE)
+		return -EINVAL;
+
+	reg = of_get_flat_dt_prop(node, "reg", &length);
+	endp = reg + (length / sizeof(__be32));
+
+	while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
+		u64 base, size;
+
+		base = dt_mem_next_cell(dt_root_addr_cells, &reg);
+		size = dt_mem_next_cell(dt_root_size_cells, &reg);
+		pr_debug("NUMA:  base = %llx , node = %u\n",
+				base, nid);
+
+		if (numa_add_memblk(nid, base, size) < 0)
+			return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int __init early_init_parse_distance_map_v1(unsigned long node,
+		const char *uname)
+{
+	const __be32 *prop_dist_matrix;
+	int length = 0, i, matrix_count;
+	int nr_size_cells = OF_ROOT_NODE_SIZE_CELLS_DEFAULT;
+
+	pr_info("NUMA: parsing numa-distance-map-v1\n");
+
+	prop_dist_matrix =
+		of_get_flat_dt_prop(node, "distance-matrix", &length);
+
+	if (!length) {
+		pr_err("NUMA: failed to parse distance-matrix\n");
+		return -ENODEV;
+	}
+
+	matrix_count = ((length / sizeof(__be32)) / (3 * nr_size_cells));
+
+	if ((matrix_count * sizeof(__be32) * 3 * nr_size_cells) !=  length) {
+		pr_warn("NUMA: invalid distance-matrix length %d\n", length);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < matrix_count; i++) {
+		u32 nodea, nodeb, distance;
+
+		nodea = dt_mem_next_cell(nr_size_cells, &prop_dist_matrix);
+		nodeb = dt_mem_next_cell(nr_size_cells, &prop_dist_matrix);
+		distance = dt_mem_next_cell(nr_size_cells, &prop_dist_matrix);
+		numa_set_distance(nodea, nodeb, distance);
+		pr_debug("NUMA:  distance[node%d -> node%d] = %d\n",
+				nodea, nodeb, distance);
+
+		/* Set default distance of node B->A same as A->B */
+		if (nodeb > nodea)
+			numa_set_distance(nodeb, nodea, distance);
+	}
+
+	return 0;
+}
+
+static int __init early_init_parse_distance_map(unsigned long node,
+		const char *uname)
+{
+	if (strcmp(uname, "distance-map") != 0)
+		return 0;
+
+	if (of_flat_dt_is_compatible(node, "numa-distance-map-v1"))
+		return early_init_parse_distance_map_v1(node, uname);
+
+	pr_err("NUMA: invalid distance-map device node\n");
+	return -EINVAL;
+}
+
+static int __init early_init_of_scan_numa_map(unsigned long node, const char *uname,
+				     int depth, void *data)
+{
+	int ret;
+
+	ret = early_init_parse_cpu_node(node);
+	if (ret)
+		return ret;
+
+	ret = early_init_parse_memory_node(node);
+	if (ret)
+		return ret;
+
+	return early_init_parse_distance_map(node, uname);
+}
+
+int of_node_to_nid(struct device_node *device)
+{
+	const __be32 *of_numa_prop;
+	int length;
+
+	of_numa_prop = of_get_property(device, "numa-node-id", &length);
+	if (of_numa_prop)
+		return of_numa_prop_to_nid(of_numa_prop, length);
+
+	return NUMA_NO_NODE;
+}
+
+/* DT node mapping is done already early_init_of_scan_memory */
+int __init of_numa_init(void)
+{
+	return of_scan_flat_dt(early_init_of_scan_numa_map, NULL);
+}
diff --git a/include/linux/of.h b/include/linux/of.h
index dd10626..23e5bad 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -685,6 +685,10 @@ static inline int of_node_to_nid(struct device_node *device)
 }
 #endif
 
+#ifdef CONFIG_OF_NUMA
+extern int __init of_numa_init(void);
+#endif
+
 static inline struct device_node *of_find_matching_node(
 	struct device_node *from,
 	const struct of_device_id *matches)
-- 
1.8.1.4



From leo.yan at linaro.org  Tue Feb  2 02:09:41 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Tue,  2 Feb 2016 18:09:41 +0800
Subject: [PATCH v6 3/4] arm64: dts: add mailbox node for Hi6220
In-Reply-To: <1454407782-24674-1-git-send-email-leo.yan@linaro.org>
References: <1454407782-24674-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1454407782-24674-4-git-send-email-leo.yan@linaro.org>

This patch add device mailbox node for Hi6220 in DT.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 2585236..23c79e1 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -249,5 +249,13 @@
 			clocks = <&ao_ctrl 27>;
 			clock-names = "apb_pclk";
 		};
+
+		mailbox: mailbox at f7510000 {
+			compatible = "hisilicon,hi6220-mbox";
+			reg = <0x0 0xf7510000 0x0 0x1000>, /* IPC_S */
+			      <0x0 0x06dff800 0x0 0x0800>; /* Mailbox buffer */
+			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+			#mbox-cells = <3>;
+		};
 	};
 };
-- 
1.9.1



From gkulkarni at caviumnetworks.com  Tue Feb  2 02:09:19 2016
From: gkulkarni at caviumnetworks.com (Ganapatrao Kulkarni)
Date: Tue, 2 Feb 2016 15:39:19 +0530
Subject: [PATCH v10 4/8] arm64, numa : Enable numa dt for arm64 platforms.
In-Reply-To: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
References: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
Message-ID: <1454407763-1017-5-git-send-email-gkulkarni@caviumnetworks.com>

Adding numa dt binding support for arm64 based platforms.

Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
---
 arch/arm64/include/asm/numa.h |  2 ++
 arch/arm64/kernel/smp.c       |  2 ++
 arch/arm64/mm/numa.c          | 17 +++++++++++++++++
 3 files changed, 21 insertions(+)

diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 574267f..e9b4f29 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -31,12 +31,14 @@ void __init arm64_numa_init(void);
 int __init numa_add_memblk(int nodeid, u64 start, u64 end);
 void __init numa_set_distance(int from, int to, int distance);
 void __init numa_free_distance(void);
+void __init early_map_cpu_to_node(unsigned int cpu, int nid);
 void numa_store_cpu_info(unsigned int cpu);
 
 #else	/* CONFIG_NUMA */
 
 static inline void numa_store_cpu_info(unsigned int cpu) { }
 static inline void arm64_numa_init(void) { }
+static inline void early_map_cpu_to_node(unsigned int cpu, int nid) { }
 
 #endif	/* CONFIG_NUMA */
 
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index d6e7d6a..46c45c8 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -520,6 +520,8 @@ static void __init of_parse_and_init_cpus(void)
 
 		pr_debug("cpu logical map 0x%llx\n", hwid);
 		cpu_logical_map(cpu_count) = hwid;
+
+		early_map_cpu_to_node(cpu_count, of_node_to_nid(dn));
 next:
 		cpu_count++;
 	}
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 60f19a2..7aad5d4 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -20,6 +20,7 @@
 #include <linux/bootmem.h>
 #include <linux/memblock.h>
 #include <linux/module.h>
+#include <linux/of.h>
 
 struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
 EXPORT_SYMBOL(node_data);
@@ -122,6 +123,15 @@ void numa_store_cpu_info(unsigned int cpu)
 	map_cpu_to_node(cpu, numa_off ? 0 : cpu_to_node_map[cpu]);
 }
 
+void __init early_map_cpu_to_node(unsigned int cpu, int nid)
+{
+	/* fallback to node 0 */
+	if (nid < 0 || nid >= MAX_NUMNODES)
+		nid = 0;
+
+	cpu_to_node_map[cpu] = nid;
+}
+
 /**
  * numa_add_memblk - Set node id to memblk
  * @nid: NUMA node ID of the new memblk
@@ -383,5 +393,12 @@ static int __init dummy_numa_init(void)
  */
 void __init arm64_numa_init(void)
 {
+	if (!numa_off) {
+#ifdef CONFIG_OF_NUMA
+		if (!numa_init(of_numa_init))
+			return;
+#endif
+	}
+
 	numa_init(dummy_numa_init);
 }
-- 
1.8.1.4



From leo.yan at linaro.org  Tue Feb  2 02:09:42 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Tue,  2 Feb 2016 18:09:42 +0800
Subject: [PATCH v6 4/4] arm64: dts: add Hi6220's stub clock node
In-Reply-To: <1454407782-24674-1-git-send-email-leo.yan@linaro.org>
References: <1454407782-24674-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1454407782-24674-5-git-send-email-leo.yan@linaro.org>

Enable SRAM node and stub clock node for Hi6220, which uses mailbox
channel 1 for CPU's frequency change.

Furthermore, add the CPU clock phandle in CPU's node and using
operating-points-v2 to register operating points. So can be used by
cpufreq-dt driver.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 56 +++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 23c79e1..f588be9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -81,6 +81,11 @@
 			device_type = "cpu";
 			reg = <0x0 0x0>;
 			enable-method = "psci";
+			clocks = <&stub_clock 0>;
+			operating-points-v2 = <&cpu_opp_table>;
+			cooling-min-level = <4>;
+			cooling-max-level = <0>;
+			#cooling-cells = <2>; /* min followed by max */
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -89,6 +94,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x1>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -97,6 +103,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x2>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -105,6 +112,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x3>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -113,6 +121,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x100>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -121,6 +130,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x101>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -129,6 +139,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x102>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -137,10 +148,42 @@
 			device_type = "cpu";
 			reg = <0x0 0x103>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 	};
 
+	cpu_opp_table: cpu_opp_table {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp00 {
+			opp-hz = /bits/ 64 <208000000>;
+			opp-microvolt = <1040000>;
+			clock-latency-ns = <500000>;
+		};
+		opp01 {
+			opp-hz = /bits/ 64 <432000000>;
+			opp-microvolt = <1040000>;
+			clock-latency-ns = <500000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <729000000>;
+			opp-microvolt = <1090000>;
+			clock-latency-ns = <500000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <960000000>;
+			opp-microvolt = <1180000>;
+			clock-latency-ns = <500000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt = <1330000>;
+			clock-latency-ns = <500000>;
+		};
+	};
+
 	gic: interrupt-controller at f6801000 {
 		compatible = "arm,gic-400";
 		reg = <0x0 0xf6801000 0 0x1000>, /* GICD */
@@ -168,6 +211,11 @@
 		#size-cells = <2>;
 		ranges;
 
+		sram: sram at fff80000 {
+			compatible = "hisilicon,hi6220-sramctrl", "syscon";
+			reg = <0x0 0xfff80000 0x0 0x12000>;
+		};
+
 		ao_ctrl: ao_ctrl at f7800000 {
 			compatible = "hisilicon,hi6220-aoctrl", "syscon";
 			reg = <0x0 0xf7800000 0x0 0x2000>;
@@ -193,6 +241,14 @@
 			#clock-cells = <1>;
 		};
 
+		stub_clock: stub_clock {
+			compatible = "hisilicon,hi6220-stub-clk";
+			hisilicon,hi6220-clk-sram = <&sram>;
+			#clock-cells = <1>;
+			mbox-names = "mbox-tx";
+			mboxes = <&mailbox 1 0 11>;
+		};
+
 		uart0: uart at f8015000 {	/* console */
 			compatible = "arm,pl011", "arm,primecell";
 			reg = <0x0 0xf8015000 0x0 0x1000>;
-- 
1.9.1



From gkulkarni at caviumnetworks.com  Tue Feb  2 02:09:20 2016
From: gkulkarni at caviumnetworks.com (Ganapatrao Kulkarni)
Date: Tue, 2 Feb 2016 15:39:20 +0530
Subject: [PATCH v10 5/8] arm64, dt,
 thunderx: Add initial dts for Cavium Thunderx in 2 node topology.
In-Reply-To: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
References: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
Message-ID: <1454407763-1017-6-git-send-email-gkulkarni@caviumnetworks.com>

Adding dt file for Cavium's Thunderx dual socket platform.

Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
---
 arch/arm64/boot/dts/cavium/Makefile             |   2 +-
 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts  |  83 +++
 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi | 806 ++++++++++++++++++++++++
 3 files changed, 890 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts
 create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi

diff --git a/arch/arm64/boot/dts/cavium/Makefile b/arch/arm64/boot/dts/cavium/Makefile
index e34f89d..7fe7067 100644
--- a/arch/arm64/boot/dts/cavium/Makefile
+++ b/arch/arm64/boot/dts/cavium/Makefile
@@ -1,4 +1,4 @@
-dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
+dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb thunder-88xx-2n.dtb
 
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
diff --git a/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts b/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts
new file mode 100644
index 0000000..5601e87
--- /dev/null
+++ b/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts
@@ -0,0 +1,83 @@
+/*
+ * Cavium Thunder DTS file - Thunder board description
+ *
+ * Copyright (C) 2014, Cavium Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library 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 library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+/include/ "thunder-88xx-2n.dtsi"
+
+/ {
+	model = "Cavium ThunderX CN88XX board";
+	compatible = "cavium,thunder-88xx";
+
+	aliases {
+		serial0 = &uaa0;
+		serial1 = &uaa1;
+	};
+
+	memory at 00000000 {
+		device_type = "memory";
+		reg = <0x0 0x01400000 0x3 0xFEC00000>;
+		/* socket 0 */
+		numa-node-id = <0>;
+	};
+
+	memory at 10000000000 {
+		device_type = "memory";
+		reg = <0x100 0x00400000 0x3 0xFFC00000>;
+		 /* socket 1 */
+		numa-node-id = <1>;
+	};
+
+	distance-map {
+		compatible = "numa-distance-map-v1";
+		distance-matrix = <0 0  10>,
+				  <0 1  20>,
+				  <1 1  10>;
+	};
+};
diff --git a/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi b/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi
new file mode 100644
index 0000000..b58e5c7
--- /dev/null
+++ b/arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi
@@ -0,0 +1,806 @@
+/*
+ * Cavium Thunder DTS file - Thunder SoC description
+ *
+ * Copyright (C) 2014, Cavium Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library 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 library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/ {
+	compatible = "cavium,thunder-88xx";
+	interrupt-parent = <&gic0>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu at 000 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x000>;
+			enable-method = "psci";
+			/* socket 0 */
+			numa-node-id = <0>;
+		};
+		cpu at 001 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x001>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 002 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x002>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 003 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x003>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 004 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x004>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 005 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x005>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 006 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x006>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 007 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x007>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 008 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x008>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 009 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x009>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 00a {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x00a>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 00b {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x00b>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 00c {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x00c>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 00d {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x00d>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 00e {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x00e>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 00f {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x00f>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 100 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x100>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 101 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x101>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 102 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x102>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 103 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x103>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 104 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x104>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 105 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x105>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 106 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x106>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 107 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x107>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 108 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x108>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 109 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x109>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 10a {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10a>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 10b {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10b>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 10c {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10c>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 10d {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10d>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 10e {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10e>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 10f {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10f>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 200 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x200>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 201 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x201>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 202 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x202>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 203 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x203>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 204 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x204>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 205 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x205>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 206 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x206>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 207 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x207>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 208 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x208>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 209 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x209>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 20a {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x20a>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 20b {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x20b>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 20c {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x20c>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 20d {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x20d>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 20e {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x20e>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 20f {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x20f>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 10000 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10000>;
+			enable-method = "psci";
+			/* socket 1 */
+			numa-node-id = <1>;
+		};
+		cpu at 10001 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10001>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10002 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10002>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10003 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10003>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10004 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10004>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10005 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10005>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10006 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10006>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10007 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10007>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10008 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10008>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10009 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10009>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1000a {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1000a>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1000b {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1000b>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1000c {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1000c>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1000d {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1000d>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1000e {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1000e>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1000f {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1000f>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10100 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10100>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10101 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10101>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10102 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10102>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10103 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10103>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10104 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10104>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10105 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10105>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10106 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10106>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10107 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10107>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10108 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10108>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10109 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10109>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1010a {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1010a>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1010b {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1010b>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1010c {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1010c>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1010d {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1010d>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1010e {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1010e>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1010f {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1010f>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10200 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10200>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10201 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10201>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10202 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10202>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10203 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10203>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10204 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10204>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10205 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10205>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10206 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10206>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10207 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10207>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10208 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10208>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 10209 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10209>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1020a {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1020a>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1020b {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1020b>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1020c {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1020c>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1020d {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1020d>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1020e {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1020e>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at 1020f {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x1020f>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <1 13 0xff01>,
+		             <1 14 0xff01>,
+		             <1 11 0xff01>,
+		             <1 10 0xff01>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		refclk50mhz: refclk50mhz {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <50000000>;
+			clock-output-names = "refclk50mhz";
+		};
+
+		gic0: interrupt-controller at 8010,00000000 {
+			compatible = "arm,gic-v3";
+			#interrupt-cells = <3>;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			#redistributor-regions = <2>;
+			ranges;
+			interrupt-controller;
+			reg = <0x8010 0x00000000 0x0 0x010000>, /* GICD */
+			      <0x8010 0x80000000 0x0 0x600000>, /* GICR Node 0 */
+			      <0x9010 0x80000000 0x0 0x600000>; /* GICR Node 1 */
+			interrupts = <1 9 0xf04>;
+
+			its: gic-its at 8010,00020000 {
+				compatible = "arm,gic-v3-its";
+				msi-controller;
+				reg = <0x8010 0x20000 0x0 0x200000>;
+				numa-node-id = <0>;
+			};
+
+			its1: gic-its at 9010,00020000 {
+				compatible = "arm,gic-v3-its";
+				msi-controller;
+				reg = <0x9010 0x20000 0x0 0x200000>;
+				numa-node-id = <1>;
+			};
+		};
+
+		uaa0: serial at 87e0,24000000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x87e0 0x24000000 0x0 0x1000>;
+			interrupts = <1 21 4>;
+			clocks = <&refclk50mhz>;
+			clock-names = "apb_pclk";
+		};
+
+		uaa1: serial at 87e0,25000000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x87e0 0x25000000 0x0 0x1000>;
+			interrupts = <1 22 4>;
+			clocks = <&refclk50mhz>;
+			clock-names = "apb_pclk";
+		};
+	};
+};
-- 
1.8.1.4



From gkulkarni at caviumnetworks.com  Tue Feb  2 02:09:21 2016
From: gkulkarni at caviumnetworks.com (Ganapatrao Kulkarni)
Date: Tue, 2 Feb 2016 15:39:21 +0530
Subject: [PATCH v10 6/8] arm64, mm,
 numa: Adding numa balancing support for arm64.
In-Reply-To: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
References: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
Message-ID: <1454407763-1017-7-git-send-email-gkulkarni@caviumnetworks.com>

enabled numa balancing for arm64 platforms.
added pte, pmd protnone helpers for use by automatic NUMA balancing.

Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
---
 arch/arm64/Kconfig               |  1 +
 arch/arm64/include/asm/pgtable.h | 18 ++++++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fcf3950..8a7c02a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -11,6 +11,7 @@ config ARM64
 	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
 	select ARCH_USE_CMPXCHG_LOCKREF
 	select ARCH_SUPPORTS_ATOMIC_RMW
+	select ARCH_SUPPORTS_NUMA_BALANCING if NUMA
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
 	select ARCH_WANT_FRAME_POINTERS
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 2d545d7a..24ce546 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -347,6 +347,24 @@ static inline pgprot_t mk_sect_prot(pgprot_t prot)
 	return __pgprot(pgprot_val(prot) & ~PTE_TABLE_BIT);
 }
 
+#ifdef CONFIG_NUMA_BALANCING
+
+/*
+ * These work without NUMA balancing but the kernel does not care. See the
+ * comment in include/asm-generic/pgtable.h
+ */
+static inline int pte_protnone(pte_t pte)
+{
+	return ((pte_val(pte) & (PTE_VALID | PTE_PROT_NONE)) == PTE_PROT_NONE);
+}
+
+static inline int pmd_protnone(pmd_t pmd)
+{
+	return pte_protnone(pmd_pte(pmd));
+}
+
+#endif /* CONFIG_NUMA_BALANCING */
+
 /*
  * THP definitions.
  */
-- 
1.8.1.4



From gkulkarni at caviumnetworks.com  Tue Feb  2 02:09:22 2016
From: gkulkarni at caviumnetworks.com (Ganapatrao Kulkarni)
Date: Tue, 2 Feb 2016 15:39:22 +0530
Subject: [PATCH v10 7/8] topology,
 cleanup: Avoid redefinition of cpumask_of_pcibus in asm header files.
In-Reply-To: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
References: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
Message-ID: <1454407763-1017-8-git-send-email-gkulkarni@caviumnetworks.com>

At present cpumask_of_pcibus is defined for !CONFIG_NUMA and moving out
to common will allow to use for numa too. This also avoids
redefinition of this macro in respective architecture header files.

Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
---
 arch/arm64/include/asm/topology.h   | 3 ---
 arch/ia64/include/asm/topology.h    | 4 ----
 arch/metag/include/asm/topology.h   | 3 ---
 arch/powerpc/include/asm/topology.h | 4 ----
 arch/s390/include/asm/pci.h         | 2 +-
 arch/s390/include/asm/topology.h    | 1 +
 arch/sh/include/asm/topology.h      | 3 ---
 arch/tile/include/asm/pci.h         | 2 --
 arch/tile/include/asm/topology.h    | 3 +++
 arch/x86/include/asm/pci.h          | 2 +-
 arch/x86/include/asm/topology.h     | 1 +
 include/asm-generic/topology.h      | 4 ++--
 12 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index 8b57339..6e1f62c 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -26,9 +26,6 @@ const struct cpumask *cpu_coregroup_mask(int cpu);
 
 struct pci_bus;
 int pcibus_to_node(struct pci_bus *bus);
-#define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ?		\
-				 cpu_all_mask :				\
-				 cpumask_of_node(pcibus_to_node(bus)))
 
 #endif /* CONFIG_NUMA */
 
diff --git a/arch/ia64/include/asm/topology.h b/arch/ia64/include/asm/topology.h
index 3ad8f69..2778eb6 100644
--- a/arch/ia64/include/asm/topology.h
+++ b/arch/ia64/include/asm/topology.h
@@ -58,10 +58,6 @@ void build_cpu_to_node_map(void);
 
 extern void arch_fix_phys_package_id(int num, u32 slot);
 
-#define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ?		\
-				 cpu_all_mask :				\
-				 cpumask_of_node(pcibus_to_node(bus)))
-
 #include <asm-generic/topology.h>
 
 #endif /* _ASM_IA64_TOPOLOGY_H */
diff --git a/arch/metag/include/asm/topology.h b/arch/metag/include/asm/topology.h
index e95f874..b285196 100644
--- a/arch/metag/include/asm/topology.h
+++ b/arch/metag/include/asm/topology.h
@@ -9,9 +9,6 @@
 #define cpumask_of_node(node)	((void)node, cpu_online_mask)
 
 #define pcibus_to_node(bus)	((void)(bus), -1)
-#define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ? \
-					cpu_all_mask : \
-					cpumask_of_node(pcibus_to_node(bus)))
 
 #endif
 
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index 8b3b46b..eee025d 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -32,10 +32,6 @@ static inline int pcibus_to_node(struct pci_bus *bus)
 }
 #endif
 
-#define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ?		\
-				 cpu_all_mask :				\
-				 cpumask_of_node(pcibus_to_node(bus)))
-
 extern int __node_distance(int, int);
 #define node_distance(a, b) __node_distance(a, b)
 
diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
index c873e68..539fb2d 100644
--- a/arch/s390/include/asm/pci.h
+++ b/arch/s390/include/asm/pci.h
@@ -205,7 +205,7 @@ static inline int __pcibus_to_node(const struct pci_bus *bus)
 }
 
 static inline const struct cpumask *
-cpumask_of_pcibus(const struct pci_bus *bus)
+__cpumask_of_pcibus(const struct pci_bus *bus)
 {
 	return cpu_online_mask;
 }
diff --git a/arch/s390/include/asm/topology.h b/arch/s390/include/asm/topology.h
index 6b53962..ac2f88f 100644
--- a/arch/s390/include/asm/topology.h
+++ b/arch/s390/include/asm/topology.h
@@ -78,6 +78,7 @@ static inline const struct cpumask *cpumask_of_node(int node)
 #define parent_node(node) (node)
 
 #define pcibus_to_node(bus) __pcibus_to_node(bus)
+#define cpumask_of_pcibus(bus) __cpumask_of_pcibus(bus)
 
 #define node_distance(a, b) __node_distance(a, b)
 
diff --git a/arch/sh/include/asm/topology.h b/arch/sh/include/asm/topology.h
index b0a282d..357983d 100644
--- a/arch/sh/include/asm/topology.h
+++ b/arch/sh/include/asm/topology.h
@@ -9,9 +9,6 @@
 #define cpumask_of_node(node)	((void)node, cpu_online_mask)
 
 #define pcibus_to_node(bus)	((void)(bus), -1)
-#define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ? \
-					cpu_all_mask : \
-					cpumask_of_node(pcibus_to_node(bus)))
 
 #endif
 
diff --git a/arch/tile/include/asm/pci.h b/arch/tile/include/asm/pci.h
index dfedd7a..473ed46 100644
--- a/arch/tile/include/asm/pci.h
+++ b/arch/tile/include/asm/pci.h
@@ -223,8 +223,6 @@ static inline int pcibios_assign_all_busses(void)
 /* Minimum PCI I/O address, starting at the page boundary. */
 #define PCIBIOS_MIN_IO		PAGE_SIZE
 
-/* Use any cpu for PCI. */
-#define cpumask_of_pcibus(bus) cpu_online_mask
 
 /* implement the pci_ DMA API in terms of the generic device dma_ one */
 #include <asm-generic/pci-dma-compat.h>
diff --git a/arch/tile/include/asm/topology.h b/arch/tile/include/asm/topology.h
index b11d5fc..9770b86 100644
--- a/arch/tile/include/asm/topology.h
+++ b/arch/tile/include/asm/topology.h
@@ -46,6 +46,9 @@ static inline const struct cpumask *cpumask_of_node(int node)
 
 #endif /* CONFIG_NUMA */
 
+/* Use any cpu for PCI. */
+#define cpumask_of_pcibus(bus) cpu_online_mask
+
 #include <asm-generic/topology.h>
 
 #ifdef CONFIG_SMP
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 4625943..4a6f358 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -121,7 +121,7 @@ static inline int __pcibus_to_node(const struct pci_bus *bus)
 }
 
 static inline const struct cpumask *
-cpumask_of_pcibus(const struct pci_bus *bus)
+__cpumask_of_pcibus(const struct pci_bus *bus)
 {
 	int node;
 
diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
index 0fb4648..980f6ee 100644
--- a/arch/x86/include/asm/topology.h
+++ b/arch/x86/include/asm/topology.h
@@ -91,6 +91,7 @@ extern void setup_node_to_cpumask_map(void);
 #define parent_node(node) (node)
 
 #define pcibus_to_node(bus) __pcibus_to_node(bus)
+#define cpumask_of_pcibus(bus) __cpumask_of_pcibus(bus)
 
 extern int __node_distance(int, int);
 #define node_distance(a, b) __node_distance(a, b)
diff --git a/include/asm-generic/topology.h b/include/asm-generic/topology.h
index fc824e2..ee305f1 100644
--- a/include/asm-generic/topology.h
+++ b/include/asm-generic/topology.h
@@ -54,14 +54,14 @@
 #define pcibus_to_node(bus)	((void)(bus), -1)
 #endif
 
+#endif	/* !CONFIG_NUMA */
+
 #ifndef cpumask_of_pcibus
 #define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ?		\
 				 cpu_all_mask :				\
 				 cpumask_of_node(pcibus_to_node(bus)))
 #endif
 
-#endif	/* CONFIG_NUMA */
-
 #if !defined(CONFIG_NUMA) || !defined(CONFIG_HAVE_MEMORYLESS_NODES)
 
 #ifndef set_numa_mem
-- 
1.8.1.4



From gkulkarni at caviumnetworks.com  Tue Feb  2 02:09:23 2016
From: gkulkarni at caviumnetworks.com (Ganapatrao Kulkarni)
Date: Tue, 2 Feb 2016 15:39:23 +0530
Subject: [PATCH v10 8/8] numa, mm,
 cleanup: remove redundant NODE_DATA macro from asm header files.
In-Reply-To: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
References: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
Message-ID: <1454407763-1017-9-git-send-email-gkulkarni@caviumnetworks.com>

NODE_DATA is defined across multiple asm header files.
Moving generic definition to asm-generic/mmzone.h to
remove redundant definitions.

Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
---
 arch/arm64/include/asm/mmzone.h   |  4 +---
 arch/m32r/include/asm/mmzone.h    |  4 +---
 arch/metag/include/asm/mmzone.h   |  4 +---
 arch/powerpc/include/asm/mmzone.h |  8 ++------
 arch/s390/include/asm/mmzone.h    |  6 +-----
 arch/sh/include/asm/mmzone.h      |  4 +---
 arch/sparc/include/asm/mmzone.h   |  6 ++----
 arch/x86/include/asm/mmzone.h     |  3 +--
 arch/x86/include/asm/mmzone_32.h  |  5 -----
 arch/x86/include/asm/mmzone_64.h  | 17 -----------------
 include/asm-generic/mmzone.h      | 24 ++++++++++++++++++++++++
 11 files changed, 34 insertions(+), 51 deletions(-)
 delete mode 100644 arch/x86/include/asm/mmzone_64.h
 create mode 100644 include/asm-generic/mmzone.h

diff --git a/arch/arm64/include/asm/mmzone.h b/arch/arm64/include/asm/mmzone.h
index a0de9e6..611a1cf 100644
--- a/arch/arm64/include/asm/mmzone.h
+++ b/arch/arm64/include/asm/mmzone.h
@@ -4,9 +4,7 @@
 #ifdef CONFIG_NUMA
 
 #include <asm/numa.h>
-
-extern struct pglist_data *node_data[];
-#define NODE_DATA(nid)		(node_data[(nid)])
+#include  <asm-generic/mmzone.h>
 
 #endif /* CONFIG_NUMA */
 #endif /* __ASM_MMZONE_H */
diff --git a/arch/m32r/include/asm/mmzone.h b/arch/m32r/include/asm/mmzone.h
index 115ced3..e3d66a0 100644
--- a/arch/m32r/include/asm/mmzone.h
+++ b/arch/m32r/include/asm/mmzone.h
@@ -7,12 +7,10 @@
 #define _ASM_MMZONE_H_
 
 #include <asm/smp.h>
+#include  <asm-generic/mmzone.h>
 
 #ifdef CONFIG_DISCONTIGMEM
 
-extern struct pglist_data *node_data[];
-#define NODE_DATA(nid)		(node_data[nid])
-
 #define node_localnr(pfn, nid)	((pfn) - NODE_DATA(nid)->node_start_pfn)
 
 #define pmd_page(pmd)		(pfn_to_page(pmd_val(pmd) >> PAGE_SHIFT))
diff --git a/arch/metag/include/asm/mmzone.h b/arch/metag/include/asm/mmzone.h
index 9c88a9c..b1e95b3 100644
--- a/arch/metag/include/asm/mmzone.h
+++ b/arch/metag/include/asm/mmzone.h
@@ -3,9 +3,7 @@
 
 #ifdef CONFIG_NEED_MULTIPLE_NODES
 #include <linux/numa.h>
-
-extern struct pglist_data *node_data[];
-#define NODE_DATA(nid)		(node_data[nid])
+#include  <asm-generic/mmzone.h>
 
 static inline int pfn_to_nid(unsigned long pfn)
 {
diff --git a/arch/powerpc/include/asm/mmzone.h b/arch/powerpc/include/asm/mmzone.h
index 7b58917..da0c5ba 100644
--- a/arch/powerpc/include/asm/mmzone.h
+++ b/arch/powerpc/include/asm/mmzone.h
@@ -19,12 +19,6 @@
 
 #ifdef CONFIG_NEED_MULTIPLE_NODES
 
-extern struct pglist_data *node_data[];
-/*
- * Return a pointer to the node data for node n.
- */
-#define NODE_DATA(nid)		(node_data[nid])
-
 /*
  * Following are specific to this numa platform.
  */
@@ -42,5 +36,7 @@ u64 memory_hotplug_max(void);
 #define memory_hotplug_max() memblock_end_of_DRAM()
 #endif /* CONFIG_NEED_MULTIPLE_NODES */
 
+#include  <asm-generic/mmzone.h>
+
 #endif /* __KERNEL__ */
 #endif /* _ASM_MMZONE_H_ */
diff --git a/arch/s390/include/asm/mmzone.h b/arch/s390/include/asm/mmzone.h
index a9e834e..91f1fcc 100644
--- a/arch/s390/include/asm/mmzone.h
+++ b/arch/s390/include/asm/mmzone.h
@@ -7,10 +7,6 @@
 #ifndef _ASM_S390_MMZONE_H
 #define _ASM_S390_MMZONE_H
 
-#ifdef CONFIG_NUMA
+#include  <asm-generic/mmzone.h>
 
-extern struct pglist_data *node_data[];
-#define NODE_DATA(nid) (node_data[nid])
-
-#endif /* CONFIG_NUMA */
 #endif /* _ASM_S390_MMZONE_H */
diff --git a/arch/sh/include/asm/mmzone.h b/arch/sh/include/asm/mmzone.h
index 15a8496..c070d00 100644
--- a/arch/sh/include/asm/mmzone.h
+++ b/arch/sh/include/asm/mmzone.h
@@ -5,9 +5,7 @@
 
 #ifdef CONFIG_NEED_MULTIPLE_NODES
 #include <linux/numa.h>
-
-extern struct pglist_data *node_data[];
-#define NODE_DATA(nid)		(node_data[nid])
+#include  <asm-generic/mmzone.h>
 
 static inline int pfn_to_nid(unsigned long pfn)
 {
diff --git a/arch/sparc/include/asm/mmzone.h b/arch/sparc/include/asm/mmzone.h
index 99d9b9f..ef1365b 100644
--- a/arch/sparc/include/asm/mmzone.h
+++ b/arch/sparc/include/asm/mmzone.h
@@ -5,13 +5,11 @@
 
 #include <linux/cpumask.h>
 
-extern struct pglist_data *node_data[];
-
-#define NODE_DATA(nid)		(node_data[nid])
-
 extern int numa_cpu_lookup_table[];
 extern cpumask_t numa_cpumask_lookup_table[];
 
 #endif /* CONFIG_NEED_MULTIPLE_NODES */
 
+#include  <asm-generic/mmzone.h>
+
 #endif /* _SPARC64_MMZONE_H */
diff --git a/arch/x86/include/asm/mmzone.h b/arch/x86/include/asm/mmzone.h
index d497bc4..5a52815 100644
--- a/arch/x86/include/asm/mmzone.h
+++ b/arch/x86/include/asm/mmzone.h
@@ -1,5 +1,4 @@
 #ifdef CONFIG_X86_32
 # include <asm/mmzone_32.h>
-#else
-# include <asm/mmzone_64.h>
 #endif
+#include  <asm-generic/mmzone.h>
diff --git a/arch/x86/include/asm/mmzone_32.h b/arch/x86/include/asm/mmzone_32.h
index 1ec990b..09f7cfb 100644
--- a/arch/x86/include/asm/mmzone_32.h
+++ b/arch/x86/include/asm/mmzone_32.h
@@ -8,11 +8,6 @@
 
 #include <asm/smp.h>
 
-#ifdef CONFIG_NUMA
-extern struct pglist_data *node_data[];
-#define NODE_DATA(nid)	(node_data[nid])
-#endif /* CONFIG_NUMA */
-
 #ifdef CONFIG_DISCONTIGMEM
 
 /*
diff --git a/arch/x86/include/asm/mmzone_64.h b/arch/x86/include/asm/mmzone_64.h
deleted file mode 100644
index 129d9aa..0000000
--- a/arch/x86/include/asm/mmzone_64.h
+++ /dev/null
@@ -1,17 +0,0 @@
-/* K8 NUMA support */
-/* Copyright 2002,2003 by Andi Kleen, SuSE Labs */
-/* 2.5 Version loosely based on the NUMAQ Code by Pat Gaughen. */
-#ifndef _ASM_X86_MMZONE_64_H
-#define _ASM_X86_MMZONE_64_H
-
-#ifdef CONFIG_NUMA
-
-#include <linux/mmdebug.h>
-#include <asm/smp.h>
-
-extern struct pglist_data *node_data[];
-
-#define NODE_DATA(nid)		(node_data[nid])
-
-#endif
-#endif /* _ASM_X86_MMZONE_64_H */
diff --git a/include/asm-generic/mmzone.h b/include/asm-generic/mmzone.h
new file mode 100644
index 0000000..ec0fc4c
--- /dev/null
+++ b/include/asm-generic/mmzone.h
@@ -0,0 +1,24 @@
+/*
+ * linux/include/asm-generic/mmzone.h
+ *
+ * Author: Ganapatrao Kulkarni <gkulkarni at cavium.com>
+ * Copyright (C) 2016 Cavium Inc.
+ *
+ * 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.
+ *
+ */
+
+#ifndef _ASM_GENERIC_MMZONE_H
+#define _ASM_GENERIC_MMZONE_H
+
+#if defined(CONFIG_NUMA) || defined(CONFIG_NEED_MULTIPLE_NODES)
+
+#ifndef NODE_DATA
+extern struct pglist_data *node_data[];
+#define NODE_DATA(nid)          (node_data[(nid)])
+#endif
+
+#endif
+#endif /* _ASM_GENERIC_MMZONE_H */
-- 
1.8.1.4



From horms at verge.net.au  Tue Feb  2 02:12:35 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Feb 2016 11:12:35 +0100
Subject: [PATCH v4 00/11] ARM: dts: shmobile: Rename the serial port
 clock to fck
In-Reply-To: <1454060861-2375-1-git-send-email-geert+renesas@glider.be>
References: <1454060861-2375-1-git-send-email-geert+renesas@glider.be>
Message-ID: <20160202101234.GC15554@verge.net.au>

On Fri, Jan 29, 2016 at 10:47:30AM +0100, Geert Uytterhoeven wrote:
> 	Hi Simon, Magnus,
> 
> This patch series renames the serial port clock to fck, as accepted in
> the DT bindings in v4.5-rc1.

Thanks, I have queued this up.


From andy.yan at rock-chips.com  Tue Feb  2 02:10:37 2016
From: andy.yan at rock-chips.com (Andy Yan)
Date: Tue,  2 Feb 2016 18:10:37 +0800
Subject: [PATCH v3 3/4] ARM: dts: rockchip: add syscon-reboot-mode DT node
In-Reply-To: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
References: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
Message-ID: <1454407837-5421-1-git-send-email-andy.yan@rock-chips.com>

Rockchip platform use a SYSCON mapped register store
the reboot mode magic value for bootloader to use when
system reboot. So add syscon-reboot-mode driver DT node
for rk3xxx,rk3036, rk3288 platform

Reviewed-by: Matthias Brugger <matthias.bgg at gmail.com>
Signed-off-by: Andy Yan <andy.yan at rock-chips.com>

---

Changes in v3:
- descirbe all reboot mode as property instead of subnode
- add rk3036 support

Changes in v2:
- make this node as a subnode of PMU

Changes in v1:
- correct the maskrom magic number
- use macro defined in rockchip_boot-mode.h for reboot-mode DT node

 arch/arm/boot/dts/rk3036.dtsi                | 11 +++++++++-
 arch/arm/boot/dts/rk3288.dtsi                | 11 ++++++++++
 arch/arm/boot/dts/rk3xxx.dtsi                | 13 +++++++++++-
 include/dt-bindings/soc/rockchip_boot-mode.h | 30 ++++++++++++++++++++++++++++
 4 files changed, 63 insertions(+), 2 deletions(-)
 create mode 100644 include/dt-bindings/soc/rockchip_boot-mode.h

diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index b9567c1..64527c6 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -43,6 +43,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/pinctrl/rockchip.h>
 #include <dt-bindings/clock/rk3036-cru.h>
+#include <dt-bindings/soc/rockchip_boot-mode.h>
 #include "skeleton.dtsi"
 
 / {
@@ -261,8 +262,16 @@
 	};
 
 	grf: syscon at 20008000 {
-		compatible = "rockchip,rk3036-grf", "syscon";
+		compatible = "rockchip,rk3036-grf", "syscon", "simple-mfd";
 		reg = <0x20008000 0x1000>;
+		reboot-mode {
+			compatible = "syscon-reboot-mode";
+			offset = <0x1d8>;
+			mode-normal = <BOOT_NORMAL>;
+			mode-recovery = <BOOT_RECOVERY>;
+			mode-fastboot = <BOOT_FASTBOOT>;
+			mode-loader = <BOOT_LOADER>;
+		};
 	};
 
 	acodec: acodec-ana at 20030000 {
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 8ac49f3..4d06d84 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -45,6 +45,7 @@
 #include <dt-bindings/clock/rk3288-cru.h>
 #include <dt-bindings/thermal/thermal.h>
 #include <dt-bindings/power/rk3288-power.h>
+#include <dt-bindings/soc/rockchip_boot-mode.h>
 #include "skeleton.dtsi"
 
 / {
@@ -713,6 +714,16 @@
 				clocks = <&cru ACLK_GPU>;
 			};
 		};
+
+		reboot-mode {
+			compatible = "syscon-reboot-mode";
+			offset = <0x94>;
+			mode-normal = <BOOT_NORMAL>;
+			mode-recovery = <BOOT_RECOVERY>;
+			mode-fastboot = <BOOT_FASTBOOT>;
+			mode-loader = <BOOT_LOADER>;
+			mode-maskrom = <BOOT_MASKROM>;
+		};
 	};
 
 	sgrf: syscon at ff740000 {
diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi
index 99eeea7..d21ed43 100644
--- a/arch/arm/boot/dts/rk3xxx.dtsi
+++ b/arch/arm/boot/dts/rk3xxx.dtsi
@@ -43,6 +43,7 @@
 
 #include <dt-bindings/interrupt-controller/irq.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/soc/rockchip_boot-mode.h>
 #include "skeleton.dtsi"
 
 / {
@@ -243,8 +244,18 @@
 	};
 
 	pmu: pmu at 20004000 {
-		compatible = "rockchip,rk3066-pmu", "syscon";
+		compatible = "rockchip,rk3066-pmu", "syscon", "simple-mfd";
 		reg = <0x20004000 0x100>;
+
+		reboot-mode {
+			compatible = "syscon-reboot-mode";
+			offset = <0x40>;
+			mode-normal = <BOOT_NORMAL>;
+			mode-recovery = <BOOT_RECOVERY>;
+			mode-fastboot = <BOOT_FASTBOOT>;
+			mode-loader = <BOOT_LOADER>;
+			mode-maskrom = <BOOT_MASKROM>;
+		};
 	};
 
 	grf: grf at 20008000 {
diff --git a/include/dt-bindings/soc/rockchip_boot-mode.h b/include/dt-bindings/soc/rockchip_boot-mode.h
new file mode 100644
index 0000000..eedf113
--- /dev/null
+++ b/include/dt-bindings/soc/rockchip_boot-mode.h
@@ -0,0 +1,30 @@
+#ifndef __ROCKCHIP_BOOT_MODE_H
+#define __ROCKCHIP_BOOT_MODE_H
+
+/*high 24 bits is tag, low 8 bits is type*/
+#define	REBOOT_FLAG		0x5242C300
+/* normal boot */
+#define	BOOT_NORMAL		(REBOOT_FLAG + 0)
+/* enter loader rockusb mode */
+#define	BOOT_LOADER		(REBOOT_FLAG + 1)
+/* enter maskrom rockusb mode */
+#define	BOOT_MASKROM		(0xEF08A53C)
+/* enter recovery */
+#define	BOOT_RECOVERY		(REBOOT_FLAG + 3)
+/* do not enter recover */
+#define	BOOT_NORECOVER		(REBOOT_FLAG + 4)
+/* boot second OS*/
+#define	BOOT_SECONDOS		(REBOOT_FLAG + 5)
+/* enter recover and wipe data. */
+#define	BOOT_WIPEDATA		(REBOOT_FLAG + 6)
+/* enter recover and wipe all data. */
+#define	BOOT_WIPEALL		(REBOOT_FLAG + 7)
+/* check firmware img with backup part*/
+#define	BOOT_CHECKIMG		(REBOOT_FLAG + 8)
+ /* enter fast boot mode */
+#define	BOOT_FASTBOOT		(REBOOT_FLAG + 9)
+#define	BOOT_SECUREBOOT_DISABLE	(REBOOT_FLAG + 10)
+/* enter charge mode */
+#define	BOOT_CHARGING		(REBOOT_FLAG + 11)
+
+#endif
-- 
1.9.1




From andy.yan at rock-chips.com  Tue Feb  2 02:13:19 2016
From: andy.yan at rock-chips.com (Andy Yan)
Date: Tue,  2 Feb 2016 18:13:19 +0800
Subject: [PATCH v3 4/4] ARM64: dts: rockchip: add syscon-reboot-mode DT node
In-Reply-To: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
References: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
Message-ID: <1454407999-5476-1-git-send-email-andy.yan@rock-chips.com>

Add syscon-reboot-mode driver DT node for rk3368 platform

Signed-off-by: Andy Yan <andy.yan at rock-chips.com>

---

Changes in v3:
- descirbe all reboot mode as property instead of subnode

Changes in v2:
- make this node as a subnode of pmugrf

Changes in v1: None

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 122777b..5213713 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -45,6 +45,7 @@
 #include <dt-bindings/interrupt-controller/irq.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/pinctrl/rockchip.h>
+#include <dt-bindings/soc/rockchip_boot-mode.h>
 #include <dt-bindings/thermal/thermal.h>
 
 / {
@@ -554,8 +555,19 @@
 	};
 
 	pmugrf: syscon at ff738000 {
-		compatible = "rockchip,rk3368-pmugrf", "syscon";
+		compatible = "rockchip,rk3368-pmugrf", "syscon", "simple-mfd";
 		reg = <0x0 0xff738000 0x0 0x1000>;
+
+		reboot-mode {
+			compatible = "syscon-reboot-mode";
+			offset = <0x200>;
+			mode-normal = <BOOT_NORMAL>;
+			mode-recovery = <BOOT_RECOVERY>;
+			mode-fastboot = <BOOT_FASTBOOT>;
+			mode-loader = <BOOT_LOADER>;
+			mode-maskrom = <BOOT_MASKROM>;
+
+		};
 	};
 
 	cru: clock-controller at ff760000 {
-- 
1.9.1




From catalin.marinas at arm.com  Tue Feb  2 02:19:45 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 2 Feb 2016 10:19:45 +0000
Subject: [PATCH] arm64: move back to generic
 memblock_enforce_memory_limit()
In-Reply-To: <1454351417-23732-1-git-send-email-ard.biesheuvel@linaro.org>
References: <20160201180256.GJ15514@e104818-lin.cambridge.arm.com>
 <1454351417-23732-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160202101945.GA22042@localhost.localdomain>

On Mon, Feb 01, 2016 at 07:30:17PM +0100, Ard Biesheuvel wrote:
>  void __init arm64_memblock_init(void)
>  {
>  	const s64 linear_region_size = -(s64)PAGE_OFFSET;
> @@ -215,24 +180,14 @@ void __init arm64_memblock_init(void)
>  	if (memblock_end_of_DRAM() > linear_region_size)
>  		memblock_remove(0, memblock_end_of_DRAM() - linear_region_size);
>  
> +	/*
> +	 * Apply the memory limit if it was set. Since the kernel may be loaded
> +	 * high up in memory, add back the kernel region that must be accessible
> +	 * via the linear mapping.
> +	 */
>  	if (memory_limit != (phys_addr_t)ULLONG_MAX) {
> -		u64 kbase = round_down(__pa(_text), MIN_KIMG_ALIGN);
> -		u64 kend = PAGE_ALIGN(__pa(_end));
> -		u64 const sz_4g = 0x100000000UL;
> -
> -		/*
> -		 * Clip memory in order of preference:
> -		 * - above the kernel and above 4 GB
> -		 * - between 4 GB and the start of the kernel (if the kernel
> -		 *   is loaded high in memory)
> -		 * - between the kernel and 4 GB (if the kernel is loaded
> -		 *   low in memory)
> -		 * - below 4 GB
> -		 */
> -		clip_mem_range(max(sz_4g, kend), ULLONG_MAX);
> -		clip_mem_range(sz_4g, kbase);
> -		clip_mem_range(kend, sz_4g);
> -		clip_mem_range(0, min(kbase, sz_4g));
> +		memblock_enforce_memory_limit(memory_limit);
> +		memblock_add(__pa(__init_begin), (u64)(_end - __init_begin));

Thanks, it looks much simpler now. However, loading the kernel 1GB
higher with mem=1G fails somewhere during the KVM hyp initialisation. It
works if I change the last line below to:

	memblock_add(__pa(_text), (u64)(_end - _text));

I can fold the change in.

-- 
Catalin


From horms at verge.net.au  Tue Feb  2 02:20:32 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Feb 2016 11:20:32 +0100
Subject: [PATCH v4 0/7] ARM: dts: r-car: Add BRG support for (H)SCIF
In-Reply-To: <1454061883-4043-1-git-send-email-geert+renesas@glider.be>
References: <1454061883-4043-1-git-send-email-geert+renesas@glider.be>
Message-ID: <20160202102031.GD15554@verge.net.au>

On Fri, Jan 29, 2016 at 11:04:36AM +0100, Geert Uytterhoeven wrote:
> 	Hi Simon, Magnus,
> 
> This patch series adds support for the Baud Rate Generator for External
> Clock (BRG), as found on SCIF and HSCIF, to the DTS files for all R-Car
> Gen1, Gen2, and Gen3 SoCs. This increases the range and accuracy of
> supported baud rates on (H)SCIF.
> 
> Support for the extra clocks in the DT bindings and in the driver has
> been accepted in v4.5-rc1.  
> 
> Changes compared to v3:
>   - Change one-line summary prefix to match current arm-soc practices,
>   - Rebased,
> 
> Changes compared to v2:
>   - Rename "int_clk" to "brg_int",
>   - Add support for R-Car M1A (r8a7778) and R-Car H1 (r8a7779),
>   - Add support for R-Car H2 (r8a7790), R-Car M2-N (r8a7793), and R-Car
>     E2 (r8a7794),
>   - Correct internal clock source ZS_CLK to S3D1 in patch description
>     for r8a7795, 
> 
> This has been tested on r8a7778/bockw, r8a7779/marzen, r8a7791/koelsch,
> r8a7794/alt, and r8a7795/salvator-x.
> 
> Dependencies:
>   - renesas-devel-20160129-v4.5-rc1,
>   - series "[PATCH v4 0/7] ARM: dts: R-Car: Add SCIF fallback
>     compatibility strings",
>   - series "[PATCH v4 00/11] ARM: dts: shmobile: Rename the serial port
>     clock to fck",
> 
> Thanks for applying!

Is it safe to apply this in the light of the dependency on
renesas-devel-20160129-v4.5-rc1?

> Geert Uytterhoeven (7):
>   ARM: dts: r8a7778: Add BRG support for SCIF
>   ARM: dts: r8a7779: Add BRG support for SCIF
>   ARM: dts: r8a7790: Add BRG support for (H)SCIF
>   ARM: dts: r8a7791: Add BRG support for (H)SCIF
>   ARM: dts: r8a7793: Add BRG support for SCIF
>   ARM: dts: r8a7794: Add BRG support for (H)SCIF
>   arm64: dts: r8a7795: Add BRG support for (H)SCIF
> 
>  arch/arm/boot/dts/r8a7778.dtsi           | 39 +++++++++++------
>  arch/arm/boot/dts/r8a7779.dtsi           | 39 +++++++++++------
>  arch/arm/boot/dts/r8a7790.dtsi           | 29 +++++++++----
>  arch/arm/boot/dts/r8a7791.dtsi           | 54 +++++++++++++++--------
>  arch/arm/boot/dts/r8a7793.dtsi           | 54 +++++++++++++++--------
>  arch/arm/boot/dts/r8a7794.dtsi           | 54 +++++++++++++++--------
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 74 ++++++++++++++++++++++----------
>  7 files changed, 235 insertions(+), 108 deletions(-)


From horms at verge.net.au  Tue Feb  2 02:21:33 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Feb 2016 11:21:33 +0100
Subject: [PATCH v4 0/9] ARM/arm64: dts: rcar: Enable SCIF_CLK frequency
 and pins
In-Reply-To: <1454062646-4826-1-git-send-email-geert+renesas@glider.be>
References: <1454062646-4826-1-git-send-email-geert+renesas@glider.be>
Message-ID: <20160202102132.GE15554@verge.net.au>

On Fri, Jan 29, 2016 at 11:17:17AM +0100, Geert Uytterhoeven wrote:
> 	Hi Simon, Magnus,
> 
> This patch series adds support for the external crystal feeding SCIF_CLK
> to (H)SCIF on the various Renesas R-Car Gen1, Gen2, and Gen3 development
> boards.  This increases the range and accuracy of supported baud rates.
> Support for this has been accepted in the driver in v4.5-rc1.
> 
> Changes compared to v3:
>   - Change one-line summary prefix to match current arm-soc practices,
>   - Tested on r8a7794/alt,
>   - Rebased,
> 
> Changes compared to v2:
>   - Add support for r8a7778/bockw, r8a7779/marzen, r8a7790/lager,
>     r8a7791/porter, r8a7793/gose, r8a7794/alt, and r8a7794/silk,
>   - Add Reviewed-by.
> 
> Testing:
>   - This was tested locally on r8a7791/koelsch and r8a7795/salvator-x,
>   - This was tested remotely on r8a7778/bockw, r8a7779/marzen, and
>     r8a7794/alt,
>   - This has been in renesas-drivers for a while, so I assume it has
>     received basic testing on other boards,
>   - Hints for various levels of testing:
>       - Change the "dev_dbg" after "done:" in
> 	drivers/tty/serial/sh-sci.c to "dev_info" to print clock and bit
> 	rate,
>       - "yes U | tr -d '\n' > /dev/ttySCx" outputs a square wave with a
>         frequency of half the bit rate on TXD,
>       - Modifying the frequency of SCIF_CLK causes garbage on the serial
>         console, unless you compensate by changing the bit rate in
>         /chosen/stdout-path,
>       - If you disable the SCIF_CLK, the brg_int clock will be used. If
>         you change that clock, you'll get garbage again.
> 
> Dependencies:
>   - renesas-devel-20160129-v4.5-rc1,
>   - series "[PATCH v4 0/7] ARM: dts: R-Car: Add SCIF fallback
>     compatibility strings",
>   - series "[PATCH v4 00/11] ARM: dts: shmobile: Rename the serial port
>     clock to fck",
>   - series "[PATCH v4 0/7] ARM: dts: r-car: Add BRG support for
>     (H)SCIF".
> 
> Thanks for applying!

Is this safe to queue up in the light of the dependency on
renesas-devel-20160129-v4.5-rc1?


From horms at verge.net.au  Tue Feb  2 02:22:21 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Feb 2016 11:22:21 +0100
Subject: [PATCH 2/2] ARM: dts: r8a7794: use GIC_*defines
In-Reply-To: <CAMuHMdWEjdeYi7QN49tSOskV8h9yAMqMqh3p7wMUqm7VCH-RAQ@mail.gmail.com>
References: <1453094324-22404-1-git-send-email-horms+renesas@verge.net.au>
 <1453094324-22404-3-git-send-email-horms+renesas@verge.net.au>
 <CAMuHMdWPU0tmMbMw+ygaVd=LpVtNqyFov_7QvVgUA2U4BeTjaA@mail.gmail.com>
 <20160129003457.GC26068@verge.net.au>
 <CAMuHMdWEjdeYi7QN49tSOskV8h9yAMqMqh3p7wMUqm7VCH-RAQ@mail.gmail.com>
Message-ID: <20160202102221.GF15554@verge.net.au>

On Fri, Jan 29, 2016 at 09:34:20AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Fri, Jan 29, 2016 at 1:34 AM, Simon Horman <horms at verge.net.au> wrote:
> > Your grep shows up some matches in arch/arm64/boot/dts/renesas/.
> 
> That's correct.
> 
> > For some reason that was not on my mental todo list. Should I add it?
> 
> IIRC, I reported those a while ago, and you said you were going to tackle
> them? Or perhaps I just assumed that ;-)

Thanks, I will tackle them.


From u.kleine-koenig at pengutronix.de  Tue Feb  2 02:24:35 2016
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue,  2 Feb 2016 11:24:35 +0100
Subject: [PATCH v2 0/3] Input: rotary-encoder - use more than two gpios
Message-ID: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>

Hello,

Some time ago I sent a v1 of this, now after testing the changes more
deeply patch 3 changed a bit. The old series started with

	Date: Wed,  2 Dec 2015 11:07:11 +0100                                                                                               
	From: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>                                                                             
	Subject: [PATCH RFC 0/3] input: rotary_encoder: use more than two gpios as input                                                    
	Message-Id: <1449050834-31779-1-git-send-email-u.kleine-koenig at pengutronix.de>                                                      

The two first patches are just preparation for the third patch.

There is an obvious improvement that allows detection of quick changes
more reliably with >2 gpios, but I didn't implement this yet. (With 4
GPIOs you can distinguish a counter clockwise movement of three states
from a clock wise movement of a single state. Still the patch is useful
as it makes these devices work at all.

My test device looks as follows:

        rotary at 0 {
                compatible = "rotary-encoder";
                gpios = <&gpio4 12 GPIO_ACTIVE_HIGH>, <&gpio4 11 GPIO_ACTIVE_HIGH>, <&gpio4 10 GPIO_ACTIVE_HIGH>, <&gpio4 9 GPIO_ACTIVE_HIGH>;

                rotary-encoder,steps = <16>;
		rotary-encoder,steps-per-period = <16>;
        };

While Daniel Mack and Rojhalat Ibrahim agreed that this device is an
absolute encoder and should be supported by a simpler logic, I still
consider it worthwhile to get these patches in as a first step. Also the
binding looks right, so IMHO the comments shouldn't stop this series
from going in.

Best regards
Uwe

Uwe Kleine-K?nig (3):
  Input: rotary-encoder - make use of devm_* to simplify .probe and
    .remove
  Input: rotary-encoder - move configuration data to driver data
  Input: rotary-encoder - support more than 2 gpios as input

 .../devicetree/bindings/input/rotary-encoder.txt   |   2 +-
 arch/arm/mach-pxa/raumfeld.c                       |  25 +-
 drivers/input/misc/rotary_encoder.c                | 327 +++++++++------------
 include/linux/rotary_encoder.h                     |   4 -
 4 files changed, 158 insertions(+), 200 deletions(-)

-- 
2.7.0.rc3



From u.kleine-koenig at pengutronix.de  Tue Feb  2 02:24:36 2016
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue,  2 Feb 2016 11:24:36 +0100
Subject: [PATCH v2 1/3] Input: rotary-encoder - make use of devm_* to simplify
 .probe and .remove
In-Reply-To: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <1454408678-6011-2-git-send-email-u.kleine-koenig@pengutronix.de>

For all operations called in .probe there are devm_* variants.
(input_register_device is clever enough to be devm aware on its own.)
This allows to get rid of the error unwind code paths in .probe and the
complete .remove function.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/input/misc/rotary_encoder.c | 74 +++++++++++--------------------------
 1 file changed, 22 insertions(+), 52 deletions(-)

diff --git a/drivers/input/misc/rotary_encoder.c b/drivers/input/misc/rotary_encoder.c
index 8aee71986430..386bdb5314e6 100644
--- a/drivers/input/misc/rotary_encoder.c
+++ b/drivers/input/misc/rotary_encoder.c
@@ -211,8 +211,8 @@ static struct rotary_encoder_platform_data *rotary_encoder_parse_dt(struct devic
 	if (!of_id || !np)
 		return NULL;
 
-	pdata = kzalloc(sizeof(struct rotary_encoder_platform_data),
-			GFP_KERNEL);
+	pdata = devm_kzalloc(dev, sizeof(struct rotary_encoder_platform_data),
+			     GFP_KERNEL);
 	if (!pdata)
 		return ERR_PTR(-ENOMEM);
 
@@ -277,11 +277,11 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 		}
 	}
 
-	encoder = kzalloc(sizeof(struct rotary_encoder), GFP_KERNEL);
-	input = input_allocate_device();
+	encoder = devm_kzalloc(dev, sizeof(struct rotary_encoder), GFP_KERNEL);
+	input = devm_input_allocate_device(&pdev->dev);
 	if (!encoder || !input) {
-		err = -ENOMEM;
-		goto exit_free_mem;
+		dev_err(dev, "unable to allocate memory\n");
+		return -ENOMEM;
 	}
 
 	encoder->input = input;
@@ -301,16 +301,18 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 	}
 
 	/* request the GPIOs */
-	err = gpio_request_one(pdata->gpio_a, GPIOF_IN, dev_name(dev));
+	err = devm_gpio_request_one(dev, pdata->gpio_a,
+				    GPIOF_IN, dev_name(dev));
 	if (err) {
 		dev_err(dev, "unable to request GPIO %d\n", pdata->gpio_a);
-		goto exit_free_mem;
+		return err;
 	}
 
-	err = gpio_request_one(pdata->gpio_b, GPIOF_IN, dev_name(dev));
+	err = devm_gpio_request_one(dev, pdata->gpio_b,
+				    GPIOF_IN, dev_name(dev));
 	if (err) {
 		dev_err(dev, "unable to request GPIO %d\n", pdata->gpio_b);
-		goto exit_free_gpio_a;
+		return err;
 	}
 
 	encoder->irq_a = gpio_to_irq(pdata->gpio_a);
@@ -331,30 +333,29 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 	default:
 		dev_err(dev, "'%d' is not a valid steps-per-period value\n",
 			pdata->steps_per_period);
-		err = -EINVAL;
-		goto exit_free_gpio_b;
+		return -EINVAL;
 	}
 
-	err = request_irq(encoder->irq_a, handler,
-			  IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
-			  DRV_NAME, encoder);
+	err = devm_request_irq(dev, encoder->irq_a, handler,
+			       IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
+			       DRV_NAME, encoder);
 	if (err) {
 		dev_err(dev, "unable to request IRQ %d\n", encoder->irq_a);
-		goto exit_free_gpio_b;
+		return err;
 	}
 
-	err = request_irq(encoder->irq_b, handler,
-			  IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
-			  DRV_NAME, encoder);
+	err = devm_request_irq(dev, encoder->irq_b, handler,
+			       IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
+			       DRV_NAME, encoder);
 	if (err) {
 		dev_err(dev, "unable to request IRQ %d\n", encoder->irq_b);
-		goto exit_free_irq_a;
+		return err;
 	}
 
 	err = input_register_device(input);
 	if (err) {
 		dev_err(dev, "failed to register input device\n");
-		goto exit_free_irq_b;
+		return err;
 	}
 
 	device_init_wakeup(&pdev->dev, pdata->wakeup_source);
@@ -362,42 +363,11 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, encoder);
 
 	return 0;
-
-exit_free_irq_b:
-	free_irq(encoder->irq_b, encoder);
-exit_free_irq_a:
-	free_irq(encoder->irq_a, encoder);
-exit_free_gpio_b:
-	gpio_free(pdata->gpio_b);
-exit_free_gpio_a:
-	gpio_free(pdata->gpio_a);
-exit_free_mem:
-	input_free_device(input);
-	kfree(encoder);
-	if (!dev_get_platdata(&pdev->dev))
-		kfree(pdata);
-
-	return err;
 }
 
 static int rotary_encoder_remove(struct platform_device *pdev)
 {
-	struct rotary_encoder *encoder = platform_get_drvdata(pdev);
-	const struct rotary_encoder_platform_data *pdata = encoder->pdata;
-
 	device_init_wakeup(&pdev->dev, false);
-
-	free_irq(encoder->irq_a, encoder);
-	free_irq(encoder->irq_b, encoder);
-	gpio_free(pdata->gpio_a);
-	gpio_free(pdata->gpio_b);
-
-	input_unregister_device(encoder->input);
-	kfree(encoder);
-
-	if (!dev_get_platdata(&pdev->dev))
-		kfree(pdata);
-
 	return 0;
 }
 
-- 
2.7.0.rc3



From u.kleine-koenig at pengutronix.de  Tue Feb  2 02:24:37 2016
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue,  2 Feb 2016 11:24:37 +0100
Subject: [PATCH v2 2/3] Input: rotary-encoder - move configuration data to
 driver data
In-Reply-To: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <1454408678-6011-3-git-send-email-u.kleine-koenig@pengutronix.de>

This is a preparation for the next patche. There is no change in
behaviour intended.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/input/misc/rotary_encoder.c | 166 ++++++++++++++++++++----------------
 1 file changed, 94 insertions(+), 72 deletions(-)

diff --git a/drivers/input/misc/rotary_encoder.c b/drivers/input/misc/rotary_encoder.c
index 386bdb5314e6..0582e851993f 100644
--- a/drivers/input/misc/rotary_encoder.c
+++ b/drivers/input/misc/rotary_encoder.c
@@ -32,58 +32,65 @@
 
 struct rotary_encoder {
 	struct input_dev *input;
-	const struct rotary_encoder_platform_data *pdata;
 
+	/* configuration */
+	unsigned int steps;
 	unsigned int axis;
-	unsigned int pos;
+	unsigned int gpio_a;
+	unsigned int gpio_b;
+	unsigned int inverted_a;
+	unsigned int inverted_b;
+	unsigned int steps_per_period;
+	bool relative_axis;
+	bool rollover;
+	bool wakeup_source;
 
 	unsigned int irq_a;
 	unsigned int irq_b;
 
+	/* state */
+	unsigned int pos;
 	bool armed;
 	unsigned char dir;	/* 0 - clockwise, 1 - CCW */
-
 	char last_stable;
 };
 
-static int rotary_encoder_get_state(const struct rotary_encoder_platform_data *pdata)
+static int rotary_encoder_get_state(const struct rotary_encoder *encoder)
 {
-	int a = !!gpio_get_value(pdata->gpio_a);
-	int b = !!gpio_get_value(pdata->gpio_b);
+	int a = !!gpio_get_value(encoder->gpio_a);
+	int b = !!gpio_get_value(encoder->gpio_b);
 
-	a ^= pdata->inverted_a;
-	b ^= pdata->inverted_b;
+	a ^= encoder->inverted_a;
+	b ^= encoder->inverted_b;
 
 	return ((a << 1) | b);
 }
 
 static void rotary_encoder_report_event(struct rotary_encoder *encoder)
 {
-	const struct rotary_encoder_platform_data *pdata = encoder->pdata;
-
-	if (pdata->relative_axis) {
+	if (encoder->relative_axis) {
 		input_report_rel(encoder->input,
-				 pdata->axis, encoder->dir ? -1 : 1);
+				 encoder->axis, encoder->dir ? -1 : 1);
 	} else {
 		unsigned int pos = encoder->pos;
 
 		if (encoder->dir) {
 			/* turning counter-clockwise */
-			if (pdata->rollover)
-				pos += pdata->steps;
+			if (encoder->rollover)
+				pos += encoder->steps;
 			if (pos)
 				pos--;
 		} else {
 			/* turning clockwise */
-			if (pdata->rollover || pos < pdata->steps)
+			if (encoder->rollover || pos < encoder->steps)
 				pos++;
 		}
 
-		if (pdata->rollover)
-			pos %= pdata->steps;
+		if (encoder->rollover)
+			pos %= encoder->steps;
 
 		encoder->pos = pos;
-		input_report_abs(encoder->input, pdata->axis, encoder->pos);
+		input_report_abs(encoder->input, encoder->axis, encoder->pos);
 	}
 
 	input_sync(encoder->input);
@@ -94,7 +101,7 @@ static irqreturn_t rotary_encoder_irq(int irq, void *dev_id)
 	struct rotary_encoder *encoder = dev_id;
 	int state;
 
-	state = rotary_encoder_get_state(encoder->pdata);
+	state = rotary_encoder_get_state(encoder);
 
 	switch (state) {
 	case 0x0:
@@ -123,7 +130,7 @@ static irqreturn_t rotary_encoder_half_period_irq(int irq, void *dev_id)
 	struct rotary_encoder *encoder = dev_id;
 	int state;
 
-	state = rotary_encoder_get_state(encoder->pdata);
+	state = rotary_encoder_get_state(encoder);
 
 	switch (state) {
 	case 0x00:
@@ -149,7 +156,7 @@ static irqreturn_t rotary_encoder_quarter_period_irq(int irq, void *dev_id)
 	unsigned char sum;
 	int state;
 
-	state = rotary_encoder_get_state(encoder->pdata);
+	state = rotary_encoder_get_state(encoder);
 
 	/*
 	 * We encode the previous and the current state using a byte.
@@ -199,38 +206,34 @@ static const struct of_device_id rotary_encoder_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, rotary_encoder_of_match);
 
-static struct rotary_encoder_platform_data *rotary_encoder_parse_dt(struct device *dev)
+static int rotary_encoder_parse_dt(struct device *dev,
+				   struct rotary_encoder *encoder)
 {
 	const struct of_device_id *of_id =
 				of_match_device(rotary_encoder_of_match, dev);
 	struct device_node *np = dev->of_node;
-	struct rotary_encoder_platform_data *pdata;
 	enum of_gpio_flags flags;
 	int error;
 
 	if (!of_id || !np)
-		return NULL;
-
-	pdata = devm_kzalloc(dev, sizeof(struct rotary_encoder_platform_data),
-			     GFP_KERNEL);
-	if (!pdata)
-		return ERR_PTR(-ENOMEM);
+		return 1;
 
-	of_property_read_u32(np, "rotary-encoder,steps", &pdata->steps);
-	of_property_read_u32(np, "linux,axis", &pdata->axis);
+	of_property_read_u32(np, "rotary-encoder,steps", &encoder->steps);
+	of_property_read_u32(np, "linux,axis", &encoder->axis);
 
-	pdata->gpio_a = of_get_gpio_flags(np, 0, &flags);
-	pdata->inverted_a = flags & OF_GPIO_ACTIVE_LOW;
+	encoder->gpio_a = of_get_gpio_flags(np, 0, &flags);
+	encoder->inverted_a = flags & OF_GPIO_ACTIVE_LOW;
 
-	pdata->gpio_b = of_get_gpio_flags(np, 1, &flags);
-	pdata->inverted_b = flags & OF_GPIO_ACTIVE_LOW;
+	encoder->gpio_b = of_get_gpio_flags(np, 1, &flags);
+	encoder->inverted_b = flags & OF_GPIO_ACTIVE_LOW;
 
-	pdata->relative_axis =
+	encoder->relative_axis =
 		of_property_read_bool(np, "rotary-encoder,relative-axis");
-	pdata->rollover = of_property_read_bool(np, "rotary-encoder,rollover");
+	encoder->rollover =
+		of_property_read_bool(np, "rotary-encoder,rollover");
 
 	error = of_property_read_u32(np, "rotary-encoder,steps-per-period",
-				     &pdata->steps_per_period);
+				     &encoder->steps_per_period);
 	if (error) {
 		/*
 		 * The 'half-period' property has been deprecated, you must use
@@ -238,45 +241,57 @@ static struct rotary_encoder_platform_data *rotary_encoder_parse_dt(struct devic
 		 * need to parse it to maintain compatibility.
 		 */
 		if (of_property_read_bool(np, "rotary-encoder,half-period")) {
-			pdata->steps_per_period = 2;
+			encoder->steps_per_period = 2;
 		} else {
 			/* Fallback to one step per period behavior */
-			pdata->steps_per_period = 1;
+			encoder->steps_per_period = 1;
 		}
 	}
 
-	pdata->wakeup_source = of_property_read_bool(np, "wakeup-source");
+	encoder->wakeup_source = of_property_read_bool(np, "wakeup-source");
 
-	return pdata;
+	return 0;
 }
 #else
-static inline struct rotary_encoder_platform_data *
-rotary_encoder_parse_dt(struct device *dev)
+static inline int rotary_encoder_parse_dt(struct device *dev,
+					  struct rotary_encoder *encoder)
 {
-	return NULL;
+	return 1;
 }
 #endif
 
+static int rotary_encoder_parse_pdata(struct device *dev,
+				      struct rotary_encoder *encoder)
+{
+	const struct rotary_encoder_platform_data *pdata;
+
+	pdata = dev_get_platdata(dev);
+	if (!pdata) {
+		dev_err(dev, "missing platform data\n");
+		return -EINVAL;
+	}
+
+	encoder->steps = pdata->steps;
+	encoder->axis = pdata->axis;
+	encoder->gpio_a = pdata->gpio_a;
+	encoder->gpio_b = pdata->gpio_b;
+	encoder->inverted_a = pdata->inverted_a;
+	encoder->inverted_b = pdata->inverted_b;
+	encoder->steps_per_period = pdata->steps_per_period;
+	encoder->relative_axis = pdata->relative_axis;
+	encoder->rollover = pdata->rollover;
+
+	return 0;
+}
+
 static int rotary_encoder_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
-	const struct rotary_encoder_platform_data *pdata = dev_get_platdata(dev);
 	struct rotary_encoder *encoder;
 	struct input_dev *input;
 	irq_handler_t handler;
 	int err;
 
-	if (!pdata) {
-		pdata = rotary_encoder_parse_dt(dev);
-		if (IS_ERR(pdata))
-			return PTR_ERR(pdata);
-
-		if (!pdata) {
-			dev_err(dev, "missing platform data\n");
-			return -EINVAL;
-		}
-	}
-
 	encoder = devm_kzalloc(dev, sizeof(struct rotary_encoder), GFP_KERNEL);
 	input = devm_input_allocate_device(&pdev->dev);
 	if (!encoder || !input) {
@@ -284,55 +299,62 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
+	err = rotary_encoder_parse_dt(dev, encoder);
+	if (err > 0)
+		/* not instatiated by dt */
+		err = rotary_encoder_parse_pdata(dev, encoder);
+
+	if (err < 0)
+		return err;
+
 	encoder->input = input;
-	encoder->pdata = pdata;
 
 	input->name = pdev->name;
 	input->id.bustype = BUS_HOST;
 	input->dev.parent = dev;
 
-	if (pdata->relative_axis) {
+	if (encoder->relative_axis) {
 		input->evbit[0] = BIT_MASK(EV_REL);
-		input->relbit[0] = BIT_MASK(pdata->axis);
+		input->relbit[0] = BIT_MASK(encoder->axis);
 	} else {
 		input->evbit[0] = BIT_MASK(EV_ABS);
 		input_set_abs_params(encoder->input,
-				     pdata->axis, 0, pdata->steps, 0, 1);
+				     encoder->axis, 0, encoder->steps, 0, 1);
 	}
 
 	/* request the GPIOs */
-	err = devm_gpio_request_one(dev, pdata->gpio_a,
+	err = devm_gpio_request_one(dev, encoder->gpio_a,
 				    GPIOF_IN, dev_name(dev));
 	if (err) {
-		dev_err(dev, "unable to request GPIO %d\n", pdata->gpio_a);
+		dev_err(dev, "unable to request GPIO %d\n", encoder->gpio_a);
 		return err;
 	}
 
-	err = devm_gpio_request_one(dev, pdata->gpio_b,
+	err = devm_gpio_request_one(dev, encoder->gpio_b,
 				    GPIOF_IN, dev_name(dev));
 	if (err) {
-		dev_err(dev, "unable to request GPIO %d\n", pdata->gpio_b);
+		dev_err(dev, "unable to request GPIO %d\n", encoder->gpio_b);
 		return err;
 	}
 
-	encoder->irq_a = gpio_to_irq(pdata->gpio_a);
-	encoder->irq_b = gpio_to_irq(pdata->gpio_b);
+	encoder->irq_a = gpio_to_irq(encoder->gpio_a);
+	encoder->irq_b = gpio_to_irq(encoder->gpio_b);
 
-	switch (pdata->steps_per_period) {
+	switch (encoder->steps_per_period) {
 	case 4:
 		handler = &rotary_encoder_quarter_period_irq;
-		encoder->last_stable = rotary_encoder_get_state(pdata);
+		encoder->last_stable = rotary_encoder_get_state(encoder);
 		break;
 	case 2:
 		handler = &rotary_encoder_half_period_irq;
-		encoder->last_stable = rotary_encoder_get_state(pdata);
+		encoder->last_stable = rotary_encoder_get_state(encoder);
 		break;
 	case 1:
 		handler = &rotary_encoder_irq;
 		break;
 	default:
 		dev_err(dev, "'%d' is not a valid steps-per-period value\n",
-			pdata->steps_per_period);
+			encoder->steps_per_period);
 		return -EINVAL;
 	}
 
@@ -358,7 +380,7 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 		return err;
 	}
 
-	device_init_wakeup(&pdev->dev, pdata->wakeup_source);
+	device_init_wakeup(&pdev->dev, encoder->wakeup_source);
 
 	platform_set_drvdata(pdev, encoder);
 
-- 
2.7.0.rc3



From u.kleine-koenig at pengutronix.de  Tue Feb  2 02:24:38 2016
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Tue,  2 Feb 2016 11:24:38 +0100
Subject: [PATCH v2 3/3] Input: rotary-encoder - support more than 2 gpios as
 input
In-Reply-To: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <1454408678-6011-4-git-send-email-u.kleine-koenig@pengutronix.de>

Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 .../devicetree/bindings/input/rotary-encoder.txt   |   2 +-
 arch/arm/mach-pxa/raumfeld.c                       |  25 ++-
 drivers/input/misc/rotary_encoder.c                | 171 ++++++++-------------
 include/linux/rotary_encoder.h                     |   4 -
 4 files changed, 84 insertions(+), 118 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt
index de99cbbbf6da..6c9f0c8a846c 100644
--- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
+++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
@@ -1,7 +1,7 @@
 Rotary encoder DT bindings
 
 Required properties:
-- gpios: a spec for two GPIOs to be used
+- gpios: a spec for at least two GPIOs to be used, most significant first
 
 Optional properties:
 - linux,axis: the input subsystem axis to map to this rotary encoder.
diff --git a/arch/arm/mach-pxa/raumfeld.c b/arch/arm/mach-pxa/raumfeld.c
index 8347d87a713d..87988d717465 100644
--- a/arch/arm/mach-pxa/raumfeld.c
+++ b/arch/arm/mach-pxa/raumfeld.c
@@ -21,6 +21,7 @@
 #include <linux/platform_device.h>
 #include <linux/interrupt.h>
 #include <linux/gpio.h>
+#include <linux/gpio/machine.h>
 #include <linux/smsc911x.h>
 #include <linux/input.h>
 #include <linux/rotary_encoder.h>
@@ -370,10 +371,25 @@ static struct rotary_encoder_platform_data raumfeld_rotary_encoder_info = {
 	.steps		= 24,
 	.axis		= REL_X,
 	.relative_axis	= 1,
-	.gpio_a		= GPIO_VOLENC_A,
-	.gpio_b		= GPIO_VOLENC_B,
-	.inverted_a	= 1,
-	.inverted_b	= 0,
+};
+
+static struct gpiod_lookup_table raumfeld_rotary_encoder_gpio_lookup = {
+	.dev_id = "rotary_encoder.0",
+	.table = {
+		{
+			.chip_label = "gpio-0",
+			.chip_hwnum = GPIO_VOLENC_A,
+			.idx = 0,
+			.flags = GPIO_ACTIVE_LOW,
+		},
+		{
+			.chip_label = "gpio-0",
+			.chip_hwnum = GPIO_VOLENC_B,
+			.idx = 1,
+			.flags = GPIO_ACTIVE_HIGH,
+		},
+		{ /* sentinel */ }
+	},
 };
 
 static struct platform_device rotary_encoder_device = {
@@ -1051,6 +1067,7 @@ static void __init __maybe_unused raumfeld_controller_init(void)
 	int ret;
 
 	pxa3xx_mfp_config(ARRAY_AND_SIZE(raumfeld_controller_pin_config));
+	gpiod_add_lookup_table(&raumfeld_rotary_encoder_gpio_lookup);
 	platform_device_register(&rotary_encoder_device);
 	spi_register_board_info(ARRAY_AND_SIZE(controller_spi_devices));
 	i2c_register_board_info(0, &raumfeld_controller_i2c_board_info, 1);
diff --git a/drivers/input/misc/rotary_encoder.c b/drivers/input/misc/rotary_encoder.c
index 0582e851993f..256fe232a26b 100644
--- a/drivers/input/misc/rotary_encoder.c
+++ b/drivers/input/misc/rotary_encoder.c
@@ -25,7 +25,6 @@
 #include <linux/slab.h>
 #include <linux/of.h>
 #include <linux/of_platform.h>
-#include <linux/of_gpio.h>
 #include <linux/pm.h>
 
 #define DRV_NAME "rotary-encoder"
@@ -36,45 +35,47 @@ struct rotary_encoder {
 	/* configuration */
 	unsigned int steps;
 	unsigned int axis;
-	unsigned int gpio_a;
-	unsigned int gpio_b;
-	unsigned int inverted_a;
-	unsigned int inverted_b;
 	unsigned int steps_per_period;
 	bool relative_axis;
 	bool rollover;
 	bool wakeup_source;
 
-	unsigned int irq_a;
-	unsigned int irq_b;
+	struct gpio_descs *gpios;
+	unsigned int *irq;
 
 	/* state */
 	unsigned int pos;
 	bool armed;
-	unsigned char dir;	/* 0 - clockwise, 1 - CCW */
+	signed char dir;	/* 1 - clockwise, -1 - CCW */
 	char last_stable;
 };
 
-static int rotary_encoder_get_state(const struct rotary_encoder *encoder)
+static unsigned rotary_encoder_get_state(const struct rotary_encoder *encoder)
 {
-	int a = !!gpio_get_value(encoder->gpio_a);
-	int b = !!gpio_get_value(encoder->gpio_b);
+	int i;
+	unsigned ret = 0;
 
-	a ^= encoder->inverted_a;
-	b ^= encoder->inverted_b;
+	for (i = 0; i < encoder->gpios->ndescs; ++i) {
+		int val = gpiod_get_value(encoder->gpios->desc[i]);
+		/* convert from gray encoding to normal */
+		if (ret & 1)
+			val = !val;
 
-	return ((a << 1) | b);
+		ret = ret << 1 | val;
+	}
+
+	return ret & 3;
 }
 
 static void rotary_encoder_report_event(struct rotary_encoder *encoder)
 {
 	if (encoder->relative_axis) {
 		input_report_rel(encoder->input,
-				 encoder->axis, encoder->dir ? -1 : 1);
+				 encoder->axis, encoder->dir);
 	} else {
 		unsigned int pos = encoder->pos;
 
-		if (encoder->dir) {
+		if (encoder->dir < 0) {
 			/* turning counter-clockwise */
 			if (encoder->rollover)
 				pos += encoder->steps;
@@ -112,12 +113,12 @@ static irqreturn_t rotary_encoder_irq(int irq, void *dev_id)
 		break;
 
 	case 0x1:
-	case 0x2:
+	case 0x3:
 		if (encoder->armed)
-			encoder->dir = state - 1;
+			encoder->dir = 2 - state;
 		break;
 
-	case 0x3:
+	case 0x2:
 		encoder->armed = true;
 		break;
 	}
@@ -132,19 +133,13 @@ static irqreturn_t rotary_encoder_half_period_irq(int irq, void *dev_id)
 
 	state = rotary_encoder_get_state(encoder);
 
-	switch (state) {
-	case 0x00:
-	case 0x03:
+	if (state & 1) {
+		encoder->dir = ((encoder->last_stable - state + 1) % 4) - 1;
+	} else {
 		if (state != encoder->last_stable) {
 			rotary_encoder_report_event(encoder);
 			encoder->last_stable = state;
 		}
-		break;
-
-	case 0x01:
-	case 0x02:
-		encoder->dir = (encoder->last_stable + state) & 0x01;
-		break;
 	}
 
 	return IRQ_HANDLED;
@@ -153,44 +148,16 @@ static irqreturn_t rotary_encoder_half_period_irq(int irq, void *dev_id)
 static irqreturn_t rotary_encoder_quarter_period_irq(int irq, void *dev_id)
 {
 	struct rotary_encoder *encoder = dev_id;
-	unsigned char sum;
 	int state;
 
 	state = rotary_encoder_get_state(encoder);
 
-	/*
-	 * We encode the previous and the current state using a byte.
-	 * The previous state in the MSB nibble, the current state in the LSB
-	 * nibble. Then use a table to decide the direction of the turn.
-	 */
-	sum = (encoder->last_stable << 4) + state;
-	switch (sum) {
-	case 0x31:
-	case 0x10:
-	case 0x02:
-	case 0x23:
-		encoder->dir = 0; /* clockwise */
-		break;
-
-	case 0x13:
-	case 0x01:
-	case 0x20:
-	case 0x32:
-		encoder->dir = 1; /* counter-clockwise */
-		break;
-
-	default:
-		/*
-		 * Ignore all other values. This covers the case when the
-		 * state didn't change (a spurious interrupt) and the
-		 * cases where the state changed by two steps, making it
-		 * impossible to tell the direction.
-		 *
-		 * In either case, don't report any event and save the
-		 * state for later.
-		 */
+	if ((encoder->last_stable + 1) % 4 == state)
+		encoder->dir = 1;
+	else if (encoder->last_stable == (state + 1) % 4)
+		encoder->dir = -1;
+	else
 		goto out;
-	}
 
 	rotary_encoder_report_event(encoder);
 
@@ -212,7 +179,6 @@ static int rotary_encoder_parse_dt(struct device *dev,
 	const struct of_device_id *of_id =
 				of_match_device(rotary_encoder_of_match, dev);
 	struct device_node *np = dev->of_node;
-	enum of_gpio_flags flags;
 	int error;
 
 	if (!of_id || !np)
@@ -221,12 +187,6 @@ static int rotary_encoder_parse_dt(struct device *dev,
 	of_property_read_u32(np, "rotary-encoder,steps", &encoder->steps);
 	of_property_read_u32(np, "linux,axis", &encoder->axis);
 
-	encoder->gpio_a = of_get_gpio_flags(np, 0, &flags);
-	encoder->inverted_a = flags & OF_GPIO_ACTIVE_LOW;
-
-	encoder->gpio_b = of_get_gpio_flags(np, 1, &flags);
-	encoder->inverted_b = flags & OF_GPIO_ACTIVE_LOW;
-
 	encoder->relative_axis =
 		of_property_read_bool(np, "rotary-encoder,relative-axis");
 	encoder->rollover =
@@ -273,11 +233,6 @@ static int rotary_encoder_parse_pdata(struct device *dev,
 
 	encoder->steps = pdata->steps;
 	encoder->axis = pdata->axis;
-	encoder->gpio_a = pdata->gpio_a;
-	encoder->gpio_b = pdata->gpio_b;
-	encoder->inverted_a = pdata->inverted_a;
-	encoder->inverted_b = pdata->inverted_b;
-	encoder->steps_per_period = pdata->steps_per_period;
 	encoder->relative_axis = pdata->relative_axis;
 	encoder->rollover = pdata->rollover;
 
@@ -291,6 +246,7 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 	struct input_dev *input;
 	irq_handler_t handler;
 	int err;
+	unsigned int i;
 
 	encoder = devm_kzalloc(dev, sizeof(struct rotary_encoder), GFP_KERNEL);
 	input = devm_input_allocate_device(&pdev->dev);
@@ -307,6 +263,16 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 	if (err < 0)
 		return err;
 
+	encoder->gpios = devm_gpiod_get_array(dev, NULL, GPIOD_IN);
+	if (IS_ERR(encoder->gpios)) {
+		dev_err(dev, "unable to get gpios\n");
+		return PTR_ERR(encoder->gpios);
+	}
+	if (encoder->gpios->ndescs < 2) {
+		dev_err(dev, "not enough gpios found\n");
+		return -EINVAL;
+	}
+
 	encoder->input = input;
 
 	input->name = pdev->name;
@@ -322,25 +288,7 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 				     encoder->axis, 0, encoder->steps, 0, 1);
 	}
 
-	/* request the GPIOs */
-	err = devm_gpio_request_one(dev, encoder->gpio_a,
-				    GPIOF_IN, dev_name(dev));
-	if (err) {
-		dev_err(dev, "unable to request GPIO %d\n", encoder->gpio_a);
-		return err;
-	}
-
-	err = devm_gpio_request_one(dev, encoder->gpio_b,
-				    GPIOF_IN, dev_name(dev));
-	if (err) {
-		dev_err(dev, "unable to request GPIO %d\n", encoder->gpio_b);
-		return err;
-	}
-
-	encoder->irq_a = gpio_to_irq(encoder->gpio_a);
-	encoder->irq_b = gpio_to_irq(encoder->gpio_b);
-
-	switch (encoder->steps_per_period) {
+	switch (encoder->steps_per_period >> (encoder->gpios->ndescs - 2)) {
 	case 4:
 		handler = &rotary_encoder_quarter_period_irq;
 		encoder->last_stable = rotary_encoder_get_state(encoder);
@@ -358,20 +306,23 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 		return -EINVAL;
 	}
 
-	err = devm_request_irq(dev, encoder->irq_a, handler,
-			       IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
-			       DRV_NAME, encoder);
-	if (err) {
-		dev_err(dev, "unable to request IRQ %d\n", encoder->irq_a);
-		return err;
-	}
+	encoder->irq =
+		devm_kzalloc(dev,
+			     sizeof(*encoder->irq) * encoder->gpios->ndescs,
+			     GFP_KERNEL);
+	if (!encoder->irq)
+		return -ENOMEM;
 
-	err = devm_request_irq(dev, encoder->irq_b, handler,
-			       IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
-			       DRV_NAME, encoder);
-	if (err) {
-		dev_err(dev, "unable to request IRQ %d\n", encoder->irq_b);
-		return err;
+	for (i = 0; i < encoder->gpios->ndescs; ++i) {
+		encoder->irq[i] = gpiod_to_irq(encoder->gpios->desc[i]);
+		err = devm_request_irq(dev, encoder->irq[i], handler,
+				       IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
+				       DRV_NAME, encoder);
+		if (err) {
+			dev_err(dev, "unable to request IRQ %d (gpio#%d)\n",
+				encoder->irq[i], i);
+			return err;
+		}
 	}
 
 	err = input_register_device(input);
@@ -399,8 +350,9 @@ static int rotary_encoder_suspend(struct device *dev)
 	struct rotary_encoder *encoder = dev_get_drvdata(dev);
 
 	if (device_may_wakeup(dev)) {
-		enable_irq_wake(encoder->irq_a);
-		enable_irq_wake(encoder->irq_b);
+		unsigned int i;
+		for (i = 0; i < encoder->gpios->ndescs; ++i)
+			enable_irq_wake(encoder->irq[i]);
 	}
 
 	return 0;
@@ -411,8 +363,9 @@ static int rotary_encoder_resume(struct device *dev)
 	struct rotary_encoder *encoder = dev_get_drvdata(dev);
 
 	if (device_may_wakeup(dev)) {
-		disable_irq_wake(encoder->irq_a);
-		disable_irq_wake(encoder->irq_b);
+		unsigned int i;
+		for (i = 0; i < encoder->gpios->ndescs; ++i)
+			disable_irq_wake(encoder->irq[i]);
 	}
 
 	return 0;
diff --git a/include/linux/rotary_encoder.h b/include/linux/rotary_encoder.h
index fe3dc64e5aeb..4536c813a1e9 100644
--- a/include/linux/rotary_encoder.h
+++ b/include/linux/rotary_encoder.h
@@ -4,10 +4,6 @@
 struct rotary_encoder_platform_data {
 	unsigned int steps;
 	unsigned int axis;
-	unsigned int gpio_a;
-	unsigned int gpio_b;
-	unsigned int inverted_a;
-	unsigned int inverted_b;
 	unsigned int steps_per_period;
 	bool relative_axis;
 	bool rollover;
-- 
2.7.0.rc3



From moinejf at free.fr  Tue Feb  2 02:26:04 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Tue, 2 Feb 2016 11:26:04 +0100
Subject: [PATCH 5/5] clk: sunxi: Remove clk_register_clkdev calls
In-Reply-To: <1454402834-6385-6-git-send-email-maxime.ripard@free-electrons.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454402834-6385-6-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20160202112604.447baec98bf89a79542fd240@free.fr>

On Tue,  2 Feb 2016 09:47:14 +0100
Maxime Ripard <maxime.ripard at free-electrons.com> wrote:

> diff --git a/drivers/clk/sunxi/clk-mod0.c b/drivers/clk/sunxi/clk-mod0.c
> index 578bff0dd251..b38d71cec74c 100644
> --- a/drivers/clk/sunxi/clk-mod0.c
> +++ b/drivers/clk/sunxi/clk-mod0.c
> @@ -15,6 +15,7 @@
>   */
>  
>  #include <linux/clk.h>
> +#include <linux/clkdev.h>

Why?

>  #include <linux/clk-provider.h>
>  #include <linux/of_address.h>
>  #include <linux/platform_device.h>


-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/



From wens at csie.org  Tue Feb  2 02:27:34 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue,  2 Feb 2016 18:27:34 +0800
Subject: [PATCH 01/11] MAINTAINERS: Add entry for X-Powers AXP family PMIC
 drivers
In-Reply-To: <1454408864-24112-1-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
Message-ID: <1454408864-24112-2-git-send-email-wens@csie.org>

Add an entry for X-Powers AXP family PMIC drivers and list myself
as maintainer.

Cc: Carlo Caione <carlo at caione.org>
Cc: Maxime Ripard <maxime.ripard at free-electrons.com>
Cc: Ramakrishna Pallala <ramakrishna.pallala at intel.com>
Cc: Todd Brandt <todd.e.brandt at linux.intel.com>
Cc: Jacob Pan <jacob.jun.pan at linux.intel.com>
Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f678c37107f5..7ea4e54f566a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11941,6 +11941,12 @@ F:	include/linux/workqueue.h
 F:	kernel/workqueue.c
 F:	Documentation/workqueue.txt
 
+X-POWERS MULTIFUNCTION PMIC DEVICE DRIVERS
+M:	Chen-Yu Tsai <wens at csie.org>
+L:	linux-kernel at vger.kernel.org
+S:	Maintained
+N:	axp[128]
+
 X.25 NETWORK LAYER
 M:	Andrew Hendry <andrew.hendry at gmail.com>
 L:	linux-x25 at vger.kernel.org
-- 
2.7.0



From wens at csie.org  Tue Feb  2 02:27:33 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue,  2 Feb 2016 18:27:33 +0800
Subject: [PATCH 00/11] mfd: axp20x: Add support for AXP809 PMIC
Message-ID: <1454408864-24112-1-git-send-email-wens@csie.org>

Hi everyone,

This series adds support for X-Powers' AXP809 PMIC. This is the primary
PMIC accompanying Allwinner's A80 SoC. For now, only the power button
(PEK) and regulators are supported. These are supported using existing
axp20x drivers. This is based on the AXP223 series v7.

Patch 1 adds a MAINTAINERS entry for the X-Powers AXP PMICs. I list
myself as the maintainer.

Patch 2 adds AXP809 to the axp20x bindings.

Patch 3 adds AXP809 support to the axp20x mfd driver.

Patch 4 removes voltage readout for switch outputs.

Patch 5 converts AXP20X LDO4 from using voltage tables to linear voltage
ranges. Either one works, but regulators found on later PMICs match up
with linear ranges better.

Patch 6 adds AXP809 support to the axp20x regulator driver. This patch
depends on the previous 3 patches. It's probably easier to apply them
together.

Patch 7 adds a dtsi file for AXP809.

Patch 8 enables AXP809 support on the A80 Optimus board.

Patch 9 enables AXP809 support on the Cubieboard 4.

Patch 10 disables the dummy regulators from sunxi-common-regulators.dtsi
on the A80 Optimus board. These aren't used in the board DTS anymore.

Patch 11 disables the dummy regulators from sunxi-common-regulators.dtsi,
on the Cubieboard4. These aren't used in the board DTS anymore.


Regards
ChenYu


Chen-Yu Tsai (11):
  MAINTAINERS: Add entry for X-Powers AXP family PMIC drivers
  mfd: axp20x: Add bindings for AXP809 PMIC
  mfd: axp20x: Add support for AXP809 PMIC
  regulator: axp20x: Remove voltage readout support for switch
    regulators
  regulator: axp20x: Use linear voltage ranges for AXP20X LDO4
  regulator: axp20x: support AXP809 variant
  ARM: dts: sunxi: Add dtsi file for AXP809 PMIC
  ARM: dts: sun9i: a80-optimus: Add AXP809 PMIC device node and
    regulators
  ARM: dts: sun9i: cubieboard4: Add AXP809 PMIC device node and
    regulators
  ARM: dts: sun9i: a80-optimus: Disable dummy regulators vcc3v0, vcc3v3,
    vcc5v0
  ARM: dts: sun9i: cubieboard4: Disable dummy regulators vcc3v0, vcc3v3,
    vcc5v0

 Documentation/devicetree/bindings/mfd/axp20x.txt   |  31 +++-
 MAINTAINERS                                        |   6 +
 .../dts/{sun9i-a80-cubieboard4.dts => axp809.dtsi} | 151 ++++++++++---------
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts        | 133 ++++++++++++++++-
 arch/arm/boot/dts/sun9i-a80-optimus.dts            | 133 ++++++++++++++++-
 drivers/mfd/axp20x-rsb.c                           |   1 +
 drivers/mfd/axp20x.c                               |  79 ++++++++++
 drivers/regulator/axp20x-regulator.c               | 165 ++++++++++++++-------
 include/linux/mfd/axp20x.h                         |  59 ++++++++
 9 files changed, 623 insertions(+), 135 deletions(-)
 copy arch/arm/boot/dts/{sun9i-a80-cubieboard4.dts => axp809.dtsi} (53%)

-- 
2.7.0



From wens at csie.org  Tue Feb  2 02:27:37 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue,  2 Feb 2016 18:27:37 +0800
Subject: [PATCH 04/11] regulator: axp20x: Remove voltage readout support for
 switch regulators
In-Reply-To: <1454408864-24112-1-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
Message-ID: <1454408864-24112-5-git-send-email-wens@csie.org>

Switch-type regulators, such as DC1SW on AXP22X, are a secondary output
from DCDC1. They are just an on/off switch, and the driver should not
try to read its voltage directly from the DCDC1 control registers.

Instead, the core will pass down the voltage from the regulator supply
chain.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 drivers/regulator/axp20x-regulator.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index e86d1fc2d80b..f31d238e85e8 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -78,8 +78,7 @@
 		.ops		= &axp20x_ops,					\
 	}
 
-#define AXP_DESC_SW(_family, _id, _match, _supply, _min, _max, _step, _vreg,	\
-		    _vmask, _ereg, _emask) 					\
+#define AXP_DESC_SW(_family, _id, _match, _supply, _ereg, _emask)		\
 	[_family##_##_id] = {							\
 		.name		= #_id,						\
 		.supply_name	= (_supply),					\
@@ -87,12 +86,7 @@
 		.regulators_node = of_match_ptr("regulators"),			\
 		.type		= REGULATOR_VOLTAGE,				\
 		.id		= _family##_##_id,				\
-		.n_voltages	= (((_max) - (_min)) / (_step) + 1),		\
 		.owner		= THIS_MODULE,					\
-		.min_uV		= (_min) * 1000,				\
-		.uV_step	= (_step) * 1000,				\
-		.vsel_reg	= (_vreg),					\
-		.vsel_mask	= (_vmask),					\
 		.enable_reg	= (_ereg),					\
 		.enable_mask	= (_emask),					\
 		.ops		= &axp20x_ops_sw,				\
@@ -160,8 +154,6 @@ static struct regulator_ops axp20x_ops = {
 };
 
 static struct regulator_ops axp20x_ops_sw = {
-	.get_voltage_sel	= regulator_get_voltage_sel_regmap,
-	.list_voltage		= regulator_list_voltage_linear,
 	.enable			= regulator_enable_regmap,
 	.disable		= regulator_disable_regmap,
 	.is_enabled		= regulator_is_enabled_regmap,
@@ -196,8 +188,8 @@ static const struct regulator_desc axp22x_regulators[] = {
 	AXP_DESC(AXP22X, DCDC5, "dcdc5", "vin5", 1000, 2550, 50,
 		 AXP22X_DCDC5_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(5)),
 	/* secondary switchable output of DCDC1 */
-	AXP_DESC_SW(AXP22X, DC1SW, "dc1sw", NULL, 1600, 3400, 100,
-		    AXP22X_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(7)),
+	AXP_DESC_SW(AXP22X, DC1SW, "dc1sw", NULL, AXP22X_PWR_OUT_CTRL2,
+		    BIT(7)),
 	/* LDO regulator internally chained to DCDC5 */
 	AXP_DESC(AXP22X, DC5LDO, "dc5ldo", NULL, 700, 1400, 100,
 		 AXP22X_DC5LDO_V_OUT, 0x7, AXP22X_PWR_OUT_CTRL1, BIT(0)),
-- 
2.7.0



From wens at csie.org  Tue Feb  2 02:27:35 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue,  2 Feb 2016 18:27:35 +0800
Subject: [PATCH 02/11] mfd: axp20x: Add bindings for AXP809 PMIC
In-Reply-To: <1454408864-24112-1-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
Message-ID: <1454408864-24112-3-git-send-email-wens@csie.org>

This patch adds the basic and regulator bindings for the X-Powers AXP809
PMIC.

Also update the DC-DC converter operating frequency for AXP22X/AXP80X.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 31 ++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
index fd39fa54571b..d20b1034e967 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -6,10 +6,11 @@ axp202 (X-Powers)
 axp209 (X-Powers)
 axp221 (X-Powers)
 axp223 (X-Powers)
+axp809 (X-Powers)
 
 Required properties:
 - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
-	      "x-powers,axp221", "x-powers,axp223"
+	      "x-powers,axp221", "x-powers,axp223", "x-powers,axp809"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
@@ -18,7 +19,9 @@ Required properties:
 
 Optional properties:
 - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
-		      (range: 750-1875). Default: 1.5MHz
+		      AXP152/20X: range:  750-1875, Default: 1.5 MHz
+		      AXP22X/80X: range: 1800-4050, Default: 3   MHz
+
 - <input>-supply: a phandle to the regulator supply node. May be omitted if
 		  inputs are unregulated, such as using the IPSOUT output
 		  from the PMIC.
@@ -77,6 +80,30 @@ LDO_IO0		: LDO		: ips-supply		: GPIO 0
 LDO_IO1		: LDO		: ips-supply		: GPIO 1
 RTC_LDO		: LDO		: ips-supply		: always on
 
+AXP809 regulators, type, and corresponding input supply names:
+
+Regulator	  Type		  Supply Name		  Notes
+---------	  ----		  -----------		  -----
+DCDC1		: DC-DC buck	: vin1-supply
+DCDC2		: DC-DC buck	: vin2-supply
+DCDC3		: DC-DC	buck	: vin3-supply
+DCDC4		: DC-DC	buck	: vin4-supply
+DCDC5		: DC-DC	buck	: vin5-supply
+DC1SW		: On/Off Switch	:			: DCDC1 secondary output
+DC5LDO		: LDO		:			: input from DCDC5
+ALDO1		: LDO		: aldoin-supply		: shared supply
+ALDO2		: LDO		: aldoin-supply		: shared supply
+ALDO3		: LDO		: aldoin-supply		: shared supply
+DLDO1		: LDO		: dldoin-supply		: shared supply
+DLDO2		: LDO		: dldoin-supply		: shared supply
+ELDO1		: LDO		: eldoin-supply		: shared supply
+ELDO2		: LDO		: eldoin-supply		: shared supply
+ELDO3		: LDO		: eldoin-supply		: shared supply
+LDO_IO0		: LDO		: ips-supply		: GPIO 0
+LDO_IO1		: LDO		: ips-supply		: GPIO 1
+RTC_LDO		: LDO		: ips-supply		: always on
+SW		: On/Off Switch : swin-supply
+
 Example:
 
 axp209: pmic at 34 {
-- 
2.7.0



From wens at csie.org  Tue Feb  2 02:27:36 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue,  2 Feb 2016 18:27:36 +0800
Subject: [PATCH 03/11] mfd: axp20x: Add support for AXP809 PMIC
In-Reply-To: <1454408864-24112-1-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
Message-ID: <1454408864-24112-4-git-send-email-wens@csie.org>

The X-Powers AXP809 is a new PMIC that is paired with Allwinner's A80
SoC, along with a slave AXP806 PMIC.

This PMIC is quite similar to the earlier AXP223, though the interrupts
and regulator have changed a bit.

This patch adds support for the interrupts and power button of the PMIC.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 drivers/mfd/axp20x-rsb.c   |  1 +
 drivers/mfd/axp20x.c       | 79 ++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mfd/axp20x.h | 59 ++++++++++++++++++++++++++++++++++
 3 files changed, 139 insertions(+)

diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
index 28c20247c112..a407527bcd09 100644
--- a/drivers/mfd/axp20x-rsb.c
+++ b/drivers/mfd/axp20x-rsb.c
@@ -61,6 +61,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
 
 static const struct of_device_id axp20x_rsb_of_match[] = {
 	{ .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
+	{ .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, axp20x_rsb_of_match);
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index a57d6e940610..1ce923277cc8 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -37,6 +37,7 @@ static const char * const axp20x_model_names[] = {
 	"AXP221",
 	"AXP223",
 	"AXP288",
+	"AXP809",
 };
 
 static const struct regmap_range axp152_writeable_ranges[] = {
@@ -85,6 +86,7 @@ static const struct regmap_access_table axp20x_volatile_table = {
 	.n_yes_ranges	= ARRAY_SIZE(axp20x_volatile_ranges),
 };
 
+/* AXP22x ranges are shared with the AXP809, as they cover the same range */
 static const struct regmap_range axp22x_writeable_ranges[] = {
 	regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
 	regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
@@ -211,6 +213,20 @@ static struct resource axp288_fuel_gauge_resources[] = {
 	},
 };
 
+static struct resource axp809_pek_resources[] = {
+	{
+		.name   = "PEK_DBR",
+		.start  = AXP809_IRQ_PEK_RIS_EDGE,
+		.end    = AXP809_IRQ_PEK_RIS_EDGE,
+		.flags  = IORESOURCE_IRQ,
+	}, {
+		.name   = "PEK_DBF",
+		.start  = AXP809_IRQ_PEK_FAL_EDGE,
+		.end    = AXP809_IRQ_PEK_FAL_EDGE,
+		.flags  = IORESOURCE_IRQ,
+	},
+};
+
 static const struct regmap_config axp152_regmap_config = {
 	.reg_bits	= 8,
 	.val_bits	= 8,
@@ -378,6 +394,41 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
 	INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG,            5, 1),
 };
 
+static const struct regmap_irq axp809_regmap_irqs[] = {
+	INIT_REGMAP_IRQ(AXP809, ACIN_OVER_V,		0, 7),
+	INIT_REGMAP_IRQ(AXP809, ACIN_PLUGIN,		0, 6),
+	INIT_REGMAP_IRQ(AXP809, ACIN_REMOVAL,	        0, 5),
+	INIT_REGMAP_IRQ(AXP809, VBUS_OVER_V,		0, 4),
+	INIT_REGMAP_IRQ(AXP809, VBUS_PLUGIN,		0, 3),
+	INIT_REGMAP_IRQ(AXP809, VBUS_REMOVAL,	        0, 2),
+	INIT_REGMAP_IRQ(AXP809, VBUS_V_LOW,		0, 1),
+	INIT_REGMAP_IRQ(AXP809, BATT_PLUGIN,		1, 7),
+	INIT_REGMAP_IRQ(AXP809, BATT_REMOVAL,	        1, 6),
+	INIT_REGMAP_IRQ(AXP809, BATT_ENT_ACT_MODE,	1, 5),
+	INIT_REGMAP_IRQ(AXP809, BATT_EXIT_ACT_MODE,	1, 4),
+	INIT_REGMAP_IRQ(AXP809, CHARG,		        1, 3),
+	INIT_REGMAP_IRQ(AXP809, CHARG_DONE,		1, 2),
+	INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_HIGH,	2, 7),
+	INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_HIGH_END,	2, 6),
+	INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_LOW,	2, 5),
+	INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_LOW_END,	2, 4),
+	INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_HIGH,	2, 3),
+	INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_HIGH_END,	2, 2),
+	INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_LOW,	2, 1),
+	INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_LOW_END,	2, 0),
+	INIT_REGMAP_IRQ(AXP809, DIE_TEMP_HIGH,	        3, 7),
+	INIT_REGMAP_IRQ(AXP809, LOW_PWR_LVL1,	        3, 1),
+	INIT_REGMAP_IRQ(AXP809, LOW_PWR_LVL2,	        3, 0),
+	INIT_REGMAP_IRQ(AXP809, TIMER,		        4, 7),
+	INIT_REGMAP_IRQ(AXP809, PEK_RIS_EDGE,	        4, 6),
+	INIT_REGMAP_IRQ(AXP809, PEK_FAL_EDGE,	        4, 5),
+	INIT_REGMAP_IRQ(AXP809, PEK_SHORT,		4, 4),
+	INIT_REGMAP_IRQ(AXP809, PEK_LONG,		4, 3),
+	INIT_REGMAP_IRQ(AXP809, PEK_OVER_OFF,		4, 2),
+	INIT_REGMAP_IRQ(AXP809, GPIO1_INPUT,		4, 1),
+	INIT_REGMAP_IRQ(AXP809, GPIO0_INPUT,		4, 0),
+};
+
 static const struct regmap_irq_chip axp152_regmap_irq_chip = {
 	.name			= "axp152_irq_chip",
 	.status_base		= AXP152_IRQ1_STATE,
@@ -428,6 +479,18 @@ static const struct regmap_irq_chip axp288_regmap_irq_chip = {
 
 };
 
+static const struct regmap_irq_chip axp809_regmap_irq_chip = {
+	.name			= "axp809",
+	.status_base		= AXP20X_IRQ1_STATE,
+	.ack_base		= AXP20X_IRQ1_STATE,
+	.mask_base		= AXP20X_IRQ1_EN,
+	.mask_invert		= true,
+	.init_ack_masked	= true,
+	.irqs			= axp809_regmap_irqs,
+	.num_irqs		= ARRAY_SIZE(axp809_regmap_irqs),
+	.num_regs		= 5,
+};
+
 static struct mfd_cell axp20x_cells[] = {
 	{
 		.name		= "axp20x-pek",
@@ -572,6 +635,16 @@ static struct mfd_cell axp288_cells[] = {
 	},
 };
 
+static struct mfd_cell axp809_cells[] = {
+	{
+		.name			= "axp20x-pek",
+		.num_resources		= ARRAY_SIZE(axp809_pek_resources),
+		.resources		= axp809_pek_resources,
+	}, {
+		.name			= "axp20x-regulator",
+	},
+};
+
 static struct axp20x_dev *axp20x_pm_power_off;
 static void axp20x_power_off(void)
 {
@@ -631,6 +704,12 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
 		axp20x->regmap_cfg = &axp288_regmap_config;
 		axp20x->regmap_irq_chip = &axp288_regmap_irq_chip;
 		break;
+	case AXP809_ID:
+		axp20x->nr_cells = ARRAY_SIZE(axp809_cells);
+		axp20x->cells = axp809_cells;
+		axp20x->regmap_cfg = &axp22x_regmap_config;
+		axp20x->regmap_irq_chip = &axp809_regmap_irq_chip;
+		break;
 	default:
 		dev_err(dev, "unsupported AXP20X ID %lu\n", axp20x->variant);
 		return -EINVAL;
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index d82e7d51372b..0be4982f08fe 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -20,6 +20,7 @@ enum {
 	AXP221_ID,
 	AXP223_ID,
 	AXP288_ID,
+	AXP809_ID,
 	NR_AXP20X_VARIANTS,
 };
 
@@ -264,6 +265,29 @@ enum {
 	AXP22X_REG_ID_MAX,
 };
 
+enum {
+	AXP809_DCDC1 = 0,
+	AXP809_DCDC2,
+	AXP809_DCDC3,
+	AXP809_DCDC4,
+	AXP809_DCDC5,
+	AXP809_DC1SW,
+	AXP809_DC5LDO,
+	AXP809_ALDO1,
+	AXP809_ALDO2,
+	AXP809_ALDO3,
+	AXP809_ELDO1,
+	AXP809_ELDO2,
+	AXP809_ELDO3,
+	AXP809_DLDO1,
+	AXP809_DLDO2,
+	AXP809_RTC_LDO,
+	AXP809_LDO_IO0,
+	AXP809_LDO_IO1,
+	AXP809_SW,
+	AXP809_REG_ID_MAX,
+};
+
 /* IRQs */
 enum {
 	AXP152_IRQ_LDO0IN_CONNECT = 1,
@@ -390,6 +414,41 @@ enum axp288_irqs {
 	AXP288_IRQ_BC_USB_CHNG,
 };
 
+enum axp809_irqs {
+	AXP809_IRQ_ACIN_OVER_V = 1,
+	AXP809_IRQ_ACIN_PLUGIN,
+	AXP809_IRQ_ACIN_REMOVAL,
+	AXP809_IRQ_VBUS_OVER_V,
+	AXP809_IRQ_VBUS_PLUGIN,
+	AXP809_IRQ_VBUS_REMOVAL,
+	AXP809_IRQ_VBUS_V_LOW,
+	AXP809_IRQ_BATT_PLUGIN,
+	AXP809_IRQ_BATT_REMOVAL,
+	AXP809_IRQ_BATT_ENT_ACT_MODE,
+	AXP809_IRQ_BATT_EXIT_ACT_MODE,
+	AXP809_IRQ_CHARG,
+	AXP809_IRQ_CHARG_DONE,
+	AXP809_IRQ_BATT_CHG_TEMP_HIGH,
+	AXP809_IRQ_BATT_CHG_TEMP_HIGH_END,
+	AXP809_IRQ_BATT_CHG_TEMP_LOW,
+	AXP809_IRQ_BATT_CHG_TEMP_LOW_END,
+	AXP809_IRQ_BATT_ACT_TEMP_HIGH,
+	AXP809_IRQ_BATT_ACT_TEMP_HIGH_END,
+	AXP809_IRQ_BATT_ACT_TEMP_LOW,
+	AXP809_IRQ_BATT_ACT_TEMP_LOW_END,
+	AXP809_IRQ_DIE_TEMP_HIGH,
+	AXP809_IRQ_LOW_PWR_LVL1,
+	AXP809_IRQ_LOW_PWR_LVL2,
+	AXP809_IRQ_TIMER,
+	AXP809_IRQ_PEK_RIS_EDGE,
+	AXP809_IRQ_PEK_FAL_EDGE,
+	AXP809_IRQ_PEK_SHORT,
+	AXP809_IRQ_PEK_LONG,
+	AXP809_IRQ_PEK_OVER_OFF,
+	AXP809_IRQ_GPIO1_INPUT,
+	AXP809_IRQ_GPIO0_INPUT,
+};
+
 #define AXP288_TS_ADC_H		0x58
 #define AXP288_TS_ADC_L		0x59
 #define AXP288_GP_ADC_H		0x5a
-- 
2.7.0



From wens at csie.org  Tue Feb  2 02:27:43 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue,  2 Feb 2016 18:27:43 +0800
Subject: [PATCH 10/11] ARM: dts: sun9i: a80-optimus: Disable dummy regulators
 vcc3v0, vcc3v3, vcc5v0
In-Reply-To: <1454408864-24112-1-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
Message-ID: <1454408864-24112-11-git-send-email-wens@csie.org>

These 3 regulators are provided in sunxi-common-regulators.dtsi.
3.0V/3.3V and 5.0V are commonly used voltages in Allwinner devices.
These dummy regulators provide a stand-in when bindings that require
one, but the real regulator is not supported yet.

Since these are no longer needed, we can disable them.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/boot/dts/sun9i-a80-optimus.dts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index 7f6bf6138966..b447360d93e8 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -323,6 +323,18 @@
 	regulator-name = "vcc-rtc-vdd1v8-io";
 };
 
+&reg_vcc3v0 {
+	status = "disabled";
+};
+
+&reg_vcc3v3 {
+	status = "disabled";
+};
+
+&reg_vcc5v0 {
+	status = "disabled";
+};
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pins_a>;
-- 
2.7.0



From wens at csie.org  Tue Feb  2 02:27:44 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue,  2 Feb 2016 18:27:44 +0800
Subject: [PATCH 11/11] ARM: dts: sun9i: cubieboard4: Disable dummy regulators
 vcc3v0, vcc3v3, vcc5v0
In-Reply-To: <1454408864-24112-1-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
Message-ID: <1454408864-24112-12-git-send-email-wens@csie.org>

These 3 regulators are provided in sunxi-common-regulators.dtsi.
3.0V/3.3V and 5.0V are commonly used voltages in Allwinner devices.
These dummy regulators provide a stand-in when bindings that require
one, but the real regulator is not supported yet.

Since these are no longer needed, we can disable them.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index 4d56dc69713c..98d9dc2d5259 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -245,6 +245,18 @@
 	regulator-name = "vcc-rtc-vdd1v8-io";
 };
 
+&reg_vcc3v0 {
+	status = "disabled";
+};
+
+&reg_vcc3v3 {
+	status = "disabled";
+};
+
+&reg_vcc5v0 {
+	status = "disabled";
+};
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pins_a>;
-- 
2.7.0



From wens at csie.org  Tue Feb  2 02:27:38 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue,  2 Feb 2016 18:27:38 +0800
Subject: [PATCH 05/11] regulator: axp20x: Use linear voltage ranges for AXP20X
 LDO4
In-Reply-To: <1454408864-24112-1-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
Message-ID: <1454408864-24112-6-git-send-email-wens@csie.org>

AXP20X datasheet lists the possible voltage settings for LDO4, so
it was implemented using a voltage table. Upon closer examination,
the valid voltages can be mapped into 3 linear ranges.

Move AXP20X LDO4 to use linear ranges. The supporting code can be
reused with later AXP8xx PMICs, which have a number of regulators
that have 2 linear ranges.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 drivers/regulator/axp20x-regulator.c | 32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index f31d238e85e8..81f25383f2d5 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -106,8 +106,8 @@
 		.ops		= &axp20x_ops_fixed				\
 	}
 
-#define AXP_DESC_TABLE(_family, _id, _match, _supply, _table, _vreg, _vmask,	\
-		       _ereg, _emask)						\
+#define AXP_DESC_RANGES(_family, _id, _match, _supply, _ranges, _n_voltages,	\
+			_vreg, _vmask, _ereg, _emask)				\
 	[_family##_##_id] = {							\
 		.name		= #_id,						\
 		.supply_name	= (_supply),					\
@@ -115,30 +115,25 @@
 		.regulators_node = of_match_ptr("regulators"),			\
 		.type		= REGULATOR_VOLTAGE,				\
 		.id		= _family##_##_id,				\
-		.n_voltages	= ARRAY_SIZE(_table),				\
+		.n_voltages	= (_n_voltages),				\
 		.owner		= THIS_MODULE,					\
 		.vsel_reg	= (_vreg),					\
 		.vsel_mask	= (_vmask),					\
 		.enable_reg	= (_ereg),					\
 		.enable_mask	= (_emask),					\
-		.volt_table	= (_table),					\
-		.ops		= &axp20x_ops_table,				\
+		.linear_ranges	= (_ranges),					\
+		.n_linear_ranges = ARRAY_SIZE(_ranges),				\
+		.ops		= &axp20x_ops_range,				\
 	}
 
-static const int axp20x_ldo4_data[] = { 1250000, 1300000, 1400000, 1500000, 1600000,
-					1700000, 1800000, 1900000, 2000000, 2500000,
-					2700000, 2800000, 3000000, 3100000, 3200000,
-					3300000 };
-
 static struct regulator_ops axp20x_ops_fixed = {
 	.list_voltage		= regulator_list_voltage_linear,
 };
 
-static struct regulator_ops axp20x_ops_table = {
+static struct regulator_ops axp20x_ops_range = {
 	.set_voltage_sel	= regulator_set_voltage_sel_regmap,
 	.get_voltage_sel	= regulator_get_voltage_sel_regmap,
-	.list_voltage		= regulator_list_voltage_table,
-	.map_voltage		= regulator_map_voltage_ascend,
+	.list_voltage		= regulator_list_voltage_linear_range,
 	.enable			= regulator_enable_regmap,
 	.disable		= regulator_disable_regmap,
 	.is_enabled		= regulator_is_enabled_regmap,
@@ -159,6 +154,12 @@ static struct regulator_ops axp20x_ops_sw = {
 	.is_enabled		= regulator_is_enabled_regmap,
 };
 
+static const struct regulator_linear_range axp20x_ldo4_ranges[] = {
+	REGULATOR_LINEAR_RANGE(1250000, 0x0, 0x0, 0),
+	REGULATOR_LINEAR_RANGE(1300000, 0x1, 0x8, 100000),
+	REGULATOR_LINEAR_RANGE(2500000, 0x9, 0xf, 100000),
+};
+
 static const struct regulator_desc axp20x_regulators[] = {
 	AXP_DESC(AXP20X, DCDC2, "dcdc2", "vin2", 700, 2275, 25,
 		 AXP20X_DCDC2_V_OUT, 0x3f, AXP20X_PWR_OUT_CTRL, 0x10),
@@ -169,8 +170,9 @@ static const struct regulator_desc axp20x_regulators[] = {
 		 AXP20X_LDO24_V_OUT, 0xf0, AXP20X_PWR_OUT_CTRL, 0x04),
 	AXP_DESC(AXP20X, LDO3, "ldo3", "ldo3in", 700, 3500, 25,
 		 AXP20X_LDO3_V_OUT, 0x7f, AXP20X_PWR_OUT_CTRL, 0x40),
-	AXP_DESC_TABLE(AXP20X, LDO4, "ldo4", "ldo24in", axp20x_ldo4_data,
-		       AXP20X_LDO24_V_OUT, 0x0f, AXP20X_PWR_OUT_CTRL, 0x08),
+	AXP_DESC_RANGES(AXP20X, LDO4, "ldo4", "ldo24in", axp20x_ldo4_ranges,
+			16, AXP20X_LDO24_V_OUT, 0x0f, AXP20X_PWR_OUT_CTRL,
+			0x08),
 	AXP_DESC_IO(AXP20X, LDO5, "ldo5", "ldo5in", 1800, 3300, 100,
 		    AXP20X_LDO5_V_OUT, 0xf0, AXP20X_GPIO0_CTRL, 0x07,
 		    AXP20X_IO_ENABLED, AXP20X_IO_DISABLED),
-- 
2.7.0



From wens at csie.org  Tue Feb  2 02:27:41 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue,  2 Feb 2016 18:27:41 +0800
Subject: [PATCH 08/11] ARM: dts: sun9i: a80-optimus: Add AXP809 PMIC device
 node and regulators
In-Reply-To: <1454408864-24112-1-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
Message-ID: <1454408864-24112-9-git-send-email-wens@csie.org>

The AXP809 PMIC is the primary PMIC. It provides various supply voltages
for the SoC and other peripherals. The PMIC's interrupt line is
connected to NMI pin of the SoC.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/boot/dts/sun9i-a80-optimus.dts | 121 +++++++++++++++++++++++++++++++-
 1 file changed, 119 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index 958160e40fd0..7f6bf6138966 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -161,7 +161,7 @@
 &mmc0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins>, <&mmc0_cd_pin_optimus>;
-	vmmc-supply = <&reg_vcc3v0>;
+	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
 	cd-gpios = <&pio 7 18 GPIO_ACTIVE_HIGH>; /* PH8 */
 	cd-inverted;
@@ -171,7 +171,7 @@
 &mmc2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc2_8bit_pins>;
-	vmmc-supply = <&reg_vcc3v0>;
+	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <8>;
 	non-removable;
 	cap-mmc-hw-reset;
@@ -204,6 +204,123 @@
 
 &r_rsb {
 	status = "okay";
+
+	axp809: pmic at 3a3 {
+		reg = <0x3a3>;
+		interrupt-parent = <&nmi_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+#include "axp809.dtsi"
+
+&reg_aldo1 {
+	/* TODO: This should be handled by the USB PHY driver */
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc33-usbh";
+};
+
+&reg_aldo2 {
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "vcc-pb-io-cam";
+};
+
+&reg_dc5ldo {
+	regulator-always-on;
+	regulator-min-microvolt = <800000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-cpus-09-usbh";
+};
+
+&reg_dcdc1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-3v";
+};
+
+&reg_dcdc2 {
+	regulator-min-microvolt = <800000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-gpu";
+};
+
+&reg_dcdc3 {
+	regulator-always-on;
+	regulator-min-microvolt = <800000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-cpua";
+};
+
+&reg_dcdc4 {
+	regulator-always-on;
+	regulator-min-microvolt = <800000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-sys-usb0-hdmi";
+};
+
+&reg_dcdc5 {
+	regulator-always-on;
+	regulator-min-microvolt = <1425000>;
+	regulator-max-microvolt = <1575000>;
+	regulator-name = "vcc-dram";
+};
+
+&reg_dldo1 {
+	/*
+	 * The WiFi chip supports a wide range (3.0 ~ 4.8V) of voltages,
+	 * and so does this regulator (3.0 ~ 4.2V), but Allwinner SDK
+	 * always sets it to 3.3V.
+	 */
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-wifi";
+};
+
+&reg_dldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-pl";
+};
+
+&reg_eldo1 {
+	regulator-min-microvolt = <1200000>;
+	regulator-max-microvolt = <1200000>;
+	regulator-name = "vcc-dvdd-cam";
+};
+
+&reg_eldo2 {
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "vcc-pe";
+};
+
+&reg_eldo3 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-pm-codec-io1";
+};
+
+&reg_ldo_io0 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-pg";
+};
+
+&reg_ldo_io1 {
+	regulator-min-microvolt = <2500000>;
+	regulator-max-microvolt = <2500000>;
+	regulator-name = "vcc-pa-gmac-2v5";
+};
+
+&reg_rtc_ldo {
+	regulator-name = "vcc-rtc-vdd1v8-io";
 };
 
 &uart0 {
-- 
2.7.0



From wens at csie.org  Tue Feb  2 02:27:40 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue,  2 Feb 2016 18:27:40 +0800
Subject: [PATCH 07/11] ARM: dts: sunxi: Add dtsi file for AXP809 PMIC
In-Reply-To: <1454408864-24112-1-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
Message-ID: <1454408864-24112-8-git-send-email-wens@csie.org>

The AXP809 PMIC is used with the Allwinner A80 SoC, along with
an AXP806 PMIC as a slave.

This patch adds a dtsi file for all the common bindings and default
values unrelated to board design. Currently this is just listing all
the regulator nodes. The regulators are initialized based on their
device node names.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/boot/dts/axp809.dtsi | 138 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 138 insertions(+)
 create mode 100644 arch/arm/boot/dts/axp809.dtsi

diff --git a/arch/arm/boot/dts/axp809.dtsi b/arch/arm/boot/dts/axp809.dtsi
new file mode 100644
index 000000000000..17769923f9c3
--- /dev/null
+++ b/arch/arm/boot/dts/axp809.dtsi
@@ -0,0 +1,138 @@
+/*
+ * Copyright 2015 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai <wens at csie.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * AXP809 Integrated Power Management Chip
+ */
+
+&axp809 {
+	compatible = "x-powers,axp809";
+	interrupt-controller;
+	#interrupt-cells = <1>;
+
+	regulators {
+		/* Default work frequency for buck regulators */
+		x-powers,dcdc-freq = <3000>;
+
+		reg_dcdc1: dcdc1 {
+			regulator-name = "dcdc1";
+		};
+
+		reg_dcdc2: dcdc2 {
+			regulator-name = "dcdc2";
+		};
+
+		reg_dcdc3: dcdc3 {
+			regulator-name = "dcdc3";
+		};
+
+		reg_dcdc4: dcdc4 {
+			regulator-name = "dcdc4";
+		};
+
+		reg_dcdc5: dcdc5 {
+			regulator-name = "dcdc5";
+		};
+
+		reg_dc1sw: dc1sw {
+			regulator-name = "dc1sw";
+		};
+
+		reg_dc5ldo: dc5ldo {
+			regulator-name = "dc5ldo";
+		};
+
+		reg_aldo1: aldo1 {
+			regulator-name = "aldo1";
+		};
+
+		reg_aldo2: aldo2 {
+			regulator-name = "aldo2";
+		};
+
+		reg_aldo3: aldo3 {
+			regulator-name = "aldo3";
+		};
+
+		reg_dldo1: dldo1 {
+			regulator-name = "dldo1";
+		};
+
+		reg_dldo2: dldo2 {
+			regulator-name = "dldo2";
+		};
+
+		reg_eldo1: eldo1 {
+			regulator-name = "eldo1";
+		};
+
+		reg_eldo2: eldo2 {
+			regulator-name = "eldo2";
+		};
+
+		reg_eldo3: eldo3 {
+			regulator-name = "eldo3";
+		};
+
+		reg_ldo_io0: ldo_io0 {
+			regulator-name = "ldo_io0";
+		};
+
+		reg_ldo_io1: ldo_io1 {
+			regulator-name = "ldo_io1";
+		};
+
+		reg_rtc_ldo: rtc_ldo {
+			/* RTC_LDO is a fixed, always-on regulator */
+			regulator-always-on;
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-name = "rtc_ldo";
+		};
+
+		reg_sw: sw {
+			regulator-name = "sw";
+		};
+	};
+};
-- 
2.7.0



From wens at csie.org  Tue Feb  2 02:27:42 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue,  2 Feb 2016 18:27:42 +0800
Subject: [PATCH 09/11] ARM: dts: sun9i: cubieboard4: Add AXP809 PMIC device
 node and regulators
In-Reply-To: <1454408864-24112-1-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
Message-ID: <1454408864-24112-10-git-send-email-wens@csie.org>

The AXP809 PMIC is the primary PMIC. It provides various supply voltages
for the SoC and other peripherals. The PMIC's interrupt line is connected
to NMI pin of the SoC.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 121 +++++++++++++++++++++++++++-
 1 file changed, 119 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index eb2ccd0a3bd5..4d56dc69713c 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -98,7 +98,7 @@
 &mmc0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins>, <&mmc0_cd_pin_cubieboard4>;
-	vmmc-supply = <&reg_vcc3v0>;
+	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
 	cd-gpios = <&pio 7 18 GPIO_ACTIVE_HIGH>; /* PH18 */
 	cd-inverted;
@@ -108,7 +108,7 @@
 &mmc2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc2_8bit_pins>;
-	vmmc-supply = <&reg_vcc3v0>;
+	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <8>;
 	non-removable;
 	cap-mmc-hw-reset;
@@ -126,6 +126,123 @@
 
 &r_rsb {
 	status = "okay";
+
+	axp809: pmic at 3a3 {
+		reg = <0x3a3>;
+		interrupt-parent = <&nmi_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+#include "axp809.dtsi"
+
+&reg_aldo1 {
+	/* TODO: This should be handled by the USB PHY driver */
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc33-usbh";
+};
+
+&reg_aldo2 {
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "vcc-pb-io-cam";
+};
+
+&reg_dc5ldo {
+	regulator-always-on;
+	regulator-min-microvolt = <800000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-cpus-09-usbh";
+};
+
+&reg_dcdc1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-3v";
+};
+
+&reg_dcdc2 {
+	regulator-min-microvolt = <800000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-gpu";
+};
+
+&reg_dcdc3 {
+	regulator-always-on;
+	regulator-min-microvolt = <800000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-cpua";
+};
+
+&reg_dcdc4 {
+	regulator-always-on;
+	regulator-min-microvolt = <800000>;
+	regulator-max-microvolt = <1100000>;
+	regulator-name = "vdd-sys-usb0-hdmi";
+};
+
+&reg_dcdc5 {
+	regulator-always-on;
+	regulator-min-microvolt = <1425000>;
+	regulator-max-microvolt = <1575000>;
+	regulator-name = "vcc-dram";
+};
+
+&reg_dldo1 {
+	/*
+	 * The WiFi chip supports a wide range (3.0 ~ 4.8V) of voltages,
+	 * and so does this regulator (3.0 ~ 4.2V), but Allwinner SDK
+	 * always sets it to 3.3V.
+	 */
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-wifi";
+};
+
+&reg_dldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-pl";
+};
+
+&reg_eldo1 {
+	regulator-min-microvolt = <1200000>;
+	regulator-max-microvolt = <1200000>;
+	regulator-name = "vcc-dvdd-cam";
+};
+
+&reg_eldo2 {
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-name = "vcc-pe";
+};
+
+&reg_eldo3 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-pm-codec-io1";
+};
+
+&reg_ldo_io0 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-pg";
+};
+
+&reg_ldo_io1 {
+	regulator-min-microvolt = <2500000>;
+	regulator-max-microvolt = <2500000>;
+	regulator-name = "vcc-pa-gmac-2v5";
+};
+
+&reg_rtc_ldo {
+	regulator-name = "vcc-rtc-vdd1v8-io";
 };
 
 &uart0 {
-- 
2.7.0



From wens at csie.org  Tue Feb  2 02:27:39 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue,  2 Feb 2016 18:27:39 +0800
Subject: [PATCH 06/11] regulator: axp20x: support AXP809 variant
In-Reply-To: <1454408864-24112-1-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
Message-ID: <1454408864-24112-7-git-send-email-wens@csie.org>

The X-Powers AXP809 PMIC has a similar set of regulators as the AXP221,
though a few LDOs were removed, and a new switch output added. Like the
AXP221, AXP809 also has DC1SW and DC5LDO, which are internally chained
to DCDC1 and DCDC5, respectively.

Add support for this new variant. Also remove the "axp22x_" prefix from
DC1SW/DC5LDO supply handling code, as the AXP809 uses it as well.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 drivers/regulator/axp20x-regulator.c | 119 ++++++++++++++++++++++++++---------
 1 file changed, 90 insertions(+), 29 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 81f25383f2d5..c9f2084659e4 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -224,6 +224,61 @@ static const struct regulator_desc axp22x_regulators[] = {
 	AXP_DESC_FIXED(AXP22X, RTC_LDO, "rtc_ldo", "ips", 3000),
 };
 
+static const struct regulator_linear_range axp809_dcdc4_ranges[] = {
+	REGULATOR_LINEAR_RANGE(600000, 0x0, 0x2f, 20000),
+	REGULATOR_LINEAR_RANGE(1800000, 0x30, 0x38, 100000),
+};
+
+static const struct regulator_linear_range axp809_dldo1_ranges[] = {
+	REGULATOR_LINEAR_RANGE(700000, 0x0, 0x1a, 100000),
+	REGULATOR_LINEAR_RANGE(3400000, 0x1b, 0x1f, 200000),
+};
+
+static const struct regulator_desc axp809_regulators[] = {
+	AXP_DESC(AXP809, DCDC1, "dcdc1", "vin1", 1600, 3400, 100,
+		 AXP22X_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(1)),
+	AXP_DESC(AXP809, DCDC2, "dcdc2", "vin2", 600, 1540, 20,
+		 AXP22X_DCDC2_V_OUT, 0x3f, AXP22X_PWR_OUT_CTRL1, BIT(2)),
+	AXP_DESC(AXP809, DCDC3, "dcdc3", "vin3", 600, 1860, 20,
+		 AXP22X_DCDC3_V_OUT, 0x3f, AXP22X_PWR_OUT_CTRL1, BIT(3)),
+	AXP_DESC_RANGES(AXP809, DCDC4, "dcdc4", "vin4", axp809_dcdc4_ranges,
+			57, AXP22X_DCDC4_V_OUT, 0x3f, AXP22X_PWR_OUT_CTRL1,
+			BIT(4)),
+	AXP_DESC(AXP809, DCDC5, "dcdc5", "vin5", 1000, 2550, 50,
+		 AXP22X_DCDC5_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(5)),
+	/* secondary switchable output of DCDC1 */
+	AXP_DESC_SW(AXP809, DC1SW, "dc1sw", NULL, AXP22X_PWR_OUT_CTRL2,
+		    BIT(7)),
+	/* LDO regulator internally chained to DCDC5 */
+	AXP_DESC(AXP809, DC5LDO, "dc5ldo", NULL, 700, 1400, 100,
+		 AXP22X_DC5LDO_V_OUT, 0x7, AXP22X_PWR_OUT_CTRL1, BIT(0)),
+	AXP_DESC(AXP809, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
+		 AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(6)),
+	AXP_DESC(AXP809, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
+		 AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(7)),
+	AXP_DESC(AXP809, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
+		 AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
+	AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp809_dldo1_ranges,
+			32, AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
+			BIT(3)),
+	AXP_DESC(AXP809, DLDO2, "dldo2", "dldoin", 700, 3300, 100,
+		 AXP22X_DLDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(4)),
+	AXP_DESC(AXP809, ELDO1, "eldo1", "eldoin", 700, 3300, 100,
+		 AXP22X_ELDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(0)),
+	AXP_DESC(AXP809, ELDO2, "eldo2", "eldoin", 700, 3300, 100,
+		 AXP22X_ELDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(1)),
+	AXP_DESC(AXP809, ELDO3, "eldo3", "eldoin", 700, 3300, 100,
+		 AXP22X_ELDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(2)),
+	AXP_DESC_IO(AXP809, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100,
+		    AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
+		    AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+	AXP_DESC_IO(AXP809, LDO_IO1, "ldo_io1", "ips", 700, 3300, 100,
+		    AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
+		    AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+	AXP_DESC_FIXED(AXP809, RTC_LDO, "rtc_ldo", "ips", 1800),
+	AXP_DESC_SW(AXP809, SW, "sw", "swin", AXP22X_PWR_OUT_CTRL2, BIT(6)),
+};
+
 static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
 {
 	struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
@@ -239,6 +294,7 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
 		break;
 	case AXP221_ID:
 	case AXP223_ID:
+	case AXP809_ID:
 		min = 1800;
 		max = 4050;
 		def = 3000;
@@ -318,6 +374,7 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev *rdev, int id, u32 work
 
 	case AXP221_ID:
 	case AXP223_ID:
+	case AXP809_ID:
 		if (id < AXP22X_DCDC1 || id > AXP22X_DCDC5)
 			return -EINVAL;
 
@@ -346,8 +403,8 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 	};
 	int ret, i, nregulators;
 	u32 workmode;
-	const char *axp22x_dc1_name = axp22x_regulators[AXP22X_DCDC1].name;
-	const char *axp22x_dc5_name = axp22x_regulators[AXP22X_DCDC5].name;
+	const char *dcdc1_name = axp22x_regulators[AXP22X_DCDC1].name;
+	const char *dcdc5_name = axp22x_regulators[AXP22X_DCDC5].name;
 
 	switch (axp20x->variant) {
 	case AXP202_ID:
@@ -360,6 +417,10 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		regulators = axp22x_regulators;
 		nregulators = AXP22X_REG_ID_MAX;
 		break;
+	case AXP809_ID:
+		regulators = axp809_regulators;
+		nregulators = AXP809_REG_ID_MAX;
+		break;
 	default:
 		dev_err(&pdev->dev, "Unsupported AXP variant: %ld\n",
 			axp20x->variant);
@@ -382,22 +443,22 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		 * part of this loop to see where we save the DT defined
 		 * name.
 		 */
-		if (regulators == axp22x_regulators) {
-			if (i == AXP22X_DC1SW) {
-				new_desc = devm_kzalloc(&pdev->dev,
-							sizeof(*desc),
-							GFP_KERNEL);
-				*new_desc = regulators[i];
-				new_desc->supply_name = axp22x_dc1_name;
-				desc = new_desc;
-			} else if (i == AXP22X_DC5LDO) {
-				new_desc = devm_kzalloc(&pdev->dev,
-							sizeof(*desc),
-							GFP_KERNEL);
-				*new_desc = regulators[i];
-				new_desc->supply_name = axp22x_dc5_name;
-				desc = new_desc;
-			}
+		if ((regulators == axp22x_regulators && i == AXP22X_DC1SW) ||
+		    (regulators == axp809_regulators && i == AXP809_DC1SW)) {
+			new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
+						GFP_KERNEL);
+			*new_desc = regulators[i];
+			new_desc->supply_name = dcdc1_name;
+			desc = new_desc;
+		}
+
+		if ((regulators == axp22x_regulators && i == AXP22X_DC5LDO) ||
+		    (regulators == axp809_regulators && i == AXP809_DC5LDO)) {
+			new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
+						GFP_KERNEL);
+			*new_desc = regulators[i];
+			new_desc->supply_name = dcdc5_name;
+			desc = new_desc;
 		}
 
 		rdev = devm_regulator_register(&pdev->dev, desc, &config);
@@ -420,17 +481,17 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		/*
 		 * Save AXP22X DCDC1 / DCDC5 regulator names for later.
 		 */
-		if (regulators == axp22x_regulators) {
-			/* Can we use rdev->constraints->name instead? */
-			if (i == AXP22X_DCDC1)
-				of_property_read_string(rdev->dev.of_node,
-							"regulator-name",
-							&axp22x_dc1_name);
-			else if (i == AXP22X_DCDC5)
-				of_property_read_string(rdev->dev.of_node,
-							"regulator-name",
-							&axp22x_dc5_name);
-		}
+		if ((regulators == axp22x_regulators && i == AXP22X_DCDC1) ||
+		    (regulators == axp809_regulators && i == AXP809_DCDC1))
+			of_property_read_string(rdev->dev.of_node,
+						"regulator-name",
+						&dcdc1_name);
+
+		if ((regulators == axp22x_regulators && i == AXP22X_DCDC5) ||
+		    (regulators == axp809_regulators && i == AXP809_DCDC5))
+			of_property_read_string(rdev->dev.of_node,
+						"regulator-name",
+						&dcdc5_name);
 	}
 
 	return 0;
-- 
2.7.0



From ard.biesheuvel at linaro.org  Tue Feb  2 02:28:41 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 2 Feb 2016 11:28:41 +0100
Subject: [PATCH] arm64: move back to generic
 memblock_enforce_memory_limit()
In-Reply-To: <20160202101945.GA22042@localhost.localdomain>
References: <20160201180256.GJ15514@e104818-lin.cambridge.arm.com>
 <1454351417-23732-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160202101945.GA22042@localhost.localdomain>
Message-ID: <CAKv+Gu_2JmVGpE4zvgkrX5W1nFeMLgO8C8tCLmZ9cPGrR=7Tiw@mail.gmail.com>

On 2 February 2016 at 11:19, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 01, 2016 at 07:30:17PM +0100, Ard Biesheuvel wrote:
>>  void __init arm64_memblock_init(void)
>>  {
>>       const s64 linear_region_size = -(s64)PAGE_OFFSET;
>> @@ -215,24 +180,14 @@ void __init arm64_memblock_init(void)
>>       if (memblock_end_of_DRAM() > linear_region_size)
>>               memblock_remove(0, memblock_end_of_DRAM() - linear_region_size);
>>
>> +     /*
>> +      * Apply the memory limit if it was set. Since the kernel may be loaded
>> +      * high up in memory, add back the kernel region that must be accessible
>> +      * via the linear mapping.
>> +      */
>>       if (memory_limit != (phys_addr_t)ULLONG_MAX) {
>> -             u64 kbase = round_down(__pa(_text), MIN_KIMG_ALIGN);
>> -             u64 kend = PAGE_ALIGN(__pa(_end));
>> -             u64 const sz_4g = 0x100000000UL;
>> -
>> -             /*
>> -              * Clip memory in order of preference:
>> -              * - above the kernel and above 4 GB
>> -              * - between 4 GB and the start of the kernel (if the kernel
>> -              *   is loaded high in memory)
>> -              * - between the kernel and 4 GB (if the kernel is loaded
>> -              *   low in memory)
>> -              * - below 4 GB
>> -              */
>> -             clip_mem_range(max(sz_4g, kend), ULLONG_MAX);
>> -             clip_mem_range(sz_4g, kbase);
>> -             clip_mem_range(kend, sz_4g);
>> -             clip_mem_range(0, min(kbase, sz_4g));
>> +             memblock_enforce_memory_limit(memory_limit);
>> +             memblock_add(__pa(__init_begin), (u64)(_end - __init_begin));
>
> Thanks, it looks much simpler now. However, loading the kernel 1GB
> higher with mem=1G fails somewhere during the KVM hyp initialisation. It
> works if I change the last line below to:
>
>         memblock_add(__pa(_text), (u64)(_end - _text));
>

OK, that should work as well.

I suppose the fact that mem= loses some of its accuracy is not an
issue? If you need it to be exact, you should simply not load your
kernel outside your mem= range ...

> I can fold the change in.
>

OK


From wens at csie.org  Tue Feb  2 02:35:29 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue, 2 Feb 2016 18:35:29 +0800
Subject: [PATCH 1/5] clk: sunxi: Make clocks setup functions return their
 clock
In-Reply-To: <1454402834-6385-2-git-send-email-maxime.ripard@free-electrons.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454402834-6385-2-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <CAGb2v66CyhkM0vabbede43eAaf7WVg0Lm8w_OUKwqHnFO182uw@mail.gmail.com>

On Tue, Feb 2, 2016 at 4:47 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> The clocks registration code in clk-sunxi was most of the time not
> returning the struct clk (or struct clk array) that was registered,
> preventing the users of such functions to manipulate it, for example to
> protect it.
>
> Make them return it so that we can start using it.

Should they return error codes as well? So the CLK_OF_DECLARE setup functions
can report errors. Or make these helper functions report errors directly?

ChenYu

> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>  drivers/clk/sunxi/clk-sunxi.c | 16 +++++++++-------
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index e460a6b0068c..67ef94948544 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -615,8 +615,8 @@ static const struct mux_data sun8i_h3_ahb2_mux_data __initconst = {
>         .shift = 0,
>  };
>
> -static void __init sunxi_mux_clk_setup(struct device_node *node,
> -                                      struct mux_data *data)
> +static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
> +                                              struct mux_data *data)
>  {
>         struct clk *clk;
>         const char *clk_name = node->name;
> @@ -638,6 +638,8 @@ static void __init sunxi_mux_clk_setup(struct device_node *node,
>                 of_clk_add_provider(node, of_clk_src_simple_get, clk);
>                 clk_register_clkdev(clk, clk_name, NULL);
>         }
> +
> +       return clk;
>  }
>
>
> @@ -722,7 +724,6 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
>  }
>
>
> -
>  /**
>   * sunxi_gates_clk_setup() - Setup function for leaf gates on clocks
>   */
> @@ -808,8 +809,8 @@ static const struct divs_data sun6i_a31_pll6_divs_data __initconst = {
>   *           |________________________|
>   */
>
> -static void __init sunxi_divs_clk_setup(struct device_node *node,
> -                                       struct divs_data *data)
> +static struct clk ** __init sunxi_divs_clk_setup(struct device_node *node,
> +                                                struct divs_data *data)
>  {
>         struct clk_onecell_data *clk_data;
>         const char *parent;
> @@ -836,7 +837,7 @@ static void __init sunxi_divs_clk_setup(struct device_node *node,
>
>         clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
>         if (!clk_data)
> -               return;
> +               return NULL;
>
>         clks = kcalloc(ndivs, sizeof(*clks), GFP_KERNEL);
>         if (!clks)
> @@ -922,7 +923,7 @@ static void __init sunxi_divs_clk_setup(struct device_node *node,
>
>         of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
>
> -       return;
> +       return clks;
>
>  free_gate:
>         kfree(gate);
> @@ -930,6 +931,7 @@ free_clks:
>         kfree(clks);
>  free_clkdata:
>         kfree(clk_data);
> +       return NULL;
>  }
>
>
> --
> 2.6.4
>


From geert at linux-m68k.org  Tue Feb  2 02:38:05 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 2 Feb 2016 11:38:05 +0100
Subject: [PATCH v4 0/7] ARM: dts: r-car: Add BRG support for (H)SCIF
In-Reply-To: <20160202102031.GD15554@verge.net.au>
References: <1454061883-4043-1-git-send-email-geert+renesas@glider.be>
 <20160202102031.GD15554@verge.net.au>
Message-ID: <CAMuHMdWjEn6RSLPOYq=zhY_gk6Lx9xTD1x1G+1igoDr=3h1R5w@mail.gmail.com>

Hi Simon,

On Tue, Feb 2, 2016 at 11:20 AM, Simon Horman <horms at verge.net.au> wrote:
> On Fri, Jan 29, 2016 at 11:04:36AM +0100, Geert Uytterhoeven wrote:
>> This patch series adds support for the Baud Rate Generator for External
>> Clock (BRG), as found on SCIF and HSCIF, to the DTS files for all R-Car
>> Gen1, Gen2, and Gen3 SoCs. This increases the range and accuracy of
>> supported baud rates on (H)SCIF.
>>
>> Support for the extra clocks in the DT bindings and in the driver has
>> been accepted in v4.5-rc1.
>>
>> Changes compared to v3:
>>   - Change one-line summary prefix to match current arm-soc practices,
>>   - Rebased,
>>
>> Changes compared to v2:
>>   - Rename "int_clk" to "brg_int",
>>   - Add support for R-Car M1A (r8a7778) and R-Car H1 (r8a7779),
>>   - Add support for R-Car H2 (r8a7790), R-Car M2-N (r8a7793), and R-Car
>>     E2 (r8a7794),
>>   - Correct internal clock source ZS_CLK to S3D1 in patch description
>>     for r8a7795,
>>
>> This has been tested on r8a7778/bockw, r8a7779/marzen, r8a7791/koelsch,
>> r8a7794/alt, and r8a7795/salvator-x.
>>
>> Dependencies:
>>   - renesas-devel-20160129-v4.5-rc1,
>>   - series "[PATCH v4 0/7] ARM: dts: R-Car: Add SCIF fallback
>>     compatibility strings",
>>   - series "[PATCH v4 00/11] ARM: dts: shmobile: Rename the serial port
>>     clock to fck",
>>
>> Thanks for applying!
>
> Is it safe to apply this in the light of the dependency on
> renesas-devel-20160129-v4.5-rc1?

The dependency here (also for the other series) just means I rebased the
series on top of renesas-devel-20160129-v4.5-rc1 + the mentioned
series.

Do you have any DT changes there that are not queued for v4.6?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From wens at csie.org  Tue Feb  2 02:38:13 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue, 2 Feb 2016 18:38:13 +0800
Subject: [PATCH 2/5] clk: sunxi: Make clocks setup functions take const
 pointer
In-Reply-To: <1454402834-6385-3-git-send-email-maxime.ripard@free-electrons.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454402834-6385-3-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <CAGb2v65O--xpjknS01QLDqDU6EWWj4pFoTmKrDjhmq0U7W5FJw@mail.gmail.com>

On Tue, Feb 2, 2016 at 4:47 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> All the data structure that we pass to the clocks setup functions are
> declared const, while our setup functions expects a regular pointer. This
> was hidden by the fact that we cast a void * pointer back to these
> structures, which made it go unnoticed.
>
> Fix the functions prototype.
>
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Acked-by: Chen-Yu Tsai <wens at csie.org>

> ---
>  drivers/clk/sunxi/clk-sunxi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 67ef94948544..a3d706f5b21c 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -616,7 +616,7 @@ static const struct mux_data sun8i_h3_ahb2_mux_data __initconst = {
>  };
>
>  static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
> -                                              struct mux_data *data)
> +                                              const struct mux_data *data)
>  {
>         struct clk *clk;
>         const char *clk_name = node->name;
> @@ -700,7 +700,7 @@ static const struct div_data sun4i_apb0_data __initconst = {
>  };
>
>  static void __init sunxi_divider_clk_setup(struct device_node *node,
> -                                          struct div_data *data)
> +                                          const struct div_data *data)
>  {
>         struct clk *clk;
>         const char *clk_name = node->name;
> @@ -810,7 +810,7 @@ static const struct divs_data sun6i_a31_pll6_divs_data __initconst = {
>   */
>
>  static struct clk ** __init sunxi_divs_clk_setup(struct device_node *node,
> -                                                struct divs_data *data)
> +                                                const struct divs_data *data)
>  {
>         struct clk_onecell_data *clk_data;
>         const char *parent;
> --
> 2.6.4
>


From kishon at ti.com  Tue Feb  2 02:40:45 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 2 Feb 2016 16:10:45 +0530
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <20160128183156.GH19432@atomide.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com>
Message-ID: <56B087AD.4000505@ti.com>

Hi,

On Friday 29 January 2016 12:01 AM, Tony Lindgren wrote:
> * Suman Anna <s-anna at ti.com> [160127 15:17]:
>> On 01/27/2016 12:56 PM, Tony Lindgren wrote:
>>> * Suman Anna <s-anna at ti.com> [160127 10:17]:
>>>> On 01/27/2016 11:31 AM, Tony Lindgren wrote:
>>>>> Why do you need another reset here? Can't you just implement PM runtime
>>>>> in the driver and do the usual pm_runtime_put_sync followed by
>>>>> pm_runtime_disable?
>>>>
>>>> The omap_hwmod_enable/disable code does not deal with hardresets (PRCM
>>>> reset lines) and so the pm_runtime_get_sync/put_sync only end up dealing
>>>> with clocks, and we need to invoke the reset functions separately.
>>>> Modules with softresets in SYSCONFIG are ok, as they are dealt with
>>>> properly.
>>>
>>> Hmm _reset() in omap_hwmod.c has this to call _assert_hardreset:
>>>
>>> 	if (oh->class->reset) {
>>> 		r = oh->class->reset(oh);
>>> 	} else {
>>> 		if (oh->rst_lines_cnt > 0) {
>>> 			for (i = 0; i < oh->rst_lines_cnt; i++)
>>> 				_assert_hardreset(oh, oh->rst_lines[i].name);
>>> 			return 0;
>>> 		} else {
>>> 			r = _ocp_softreset(oh);
>>> 			if (r == -ENOENT)
>>> 				r = 0;
>>> 		}
>>> 	}
>>
>> Right, hwmod code does the initial reset.
>>
>>> Care to explain what exactly the problem with the hwmod code not doing
>>> the reset on init?
>>
>> And we only need to deassert the reset in probe. Technically, we don't
>> need to assert first and deassert in probe, and that was a design choice
>> made by Kishon.
> 
> OK so if hwmod code has already done the reset, then why would you need
> to deassert reset in the device driver probe?

The hwmod code only asserts the reset lines and that is not enough to access
the PCI registers. The reset lines must be de-asserted before accessing the
PCIe registers.
> 
>>> And why do you need to do another reset in dra7xx_pcie_remove()?
>>
>> Primarily to restore the reset state back to what it was after the
>> driver remove gets called. We cannot call deassert twice without calling
>> a assert in between. Kishon had originally added the assert and deassert
>> only in probe, but nothing in remove, they ought to be deassert in probe
>> and assert in remove to match initial hardware state, and to also make
>> it work across multiple probe/remove.

right. I thought if some program like the bootloader requires the reset lines
to be in initial hw state, then it might break on 'reboot'. So restored it back
to the initial hw state.
> 
> I don't understand this part either.. Usually you just power up and init
> the registers to a sane state in a device driver probe and on exit just
> power down the device.
> 
>>>>> Basically I'm wondering how come we need these platform data callbacks
>>>>> at all.
>>>>
>>>> The hardresets are controlled through the
>>>> omap_device_assert(deassert)_hardreset functions, and since these are
>>>> limited to mach-omap2, we are invoking them through platform data callbacks.
>>>
>>> Right.. But I'm wondering about the why you need to do this in the
>>> driver at all part :)
>>
>> The initial reset at init time is okay, but hwmod _enable() bails out if
>> the resets lines are asserted. This was a change made long time back, I
>> believe to deal with the problems around the DSP enabling sequences. As
>> such, pm_runtime_get_sync() and put_sync() do not deassert and assert
>> the resets.
> 
> OK if the hwmod code does not deassert reset lines properly on enable,
> then that sounds like a bug that should be fixed instead of adding
> device specific work arounds.

I think some devices require the reset lines to be asserted and some devices
require it to be de-asserted and hwmod was designed when there was only the
first type of devices. I'm not sure though.
> 
> Sorry to keep dragging this on a bit longer, but I think we need to
> hear Paul's comments on this one.

I agree.
Paul, what do you think is the best way forward to perform reset?

Thanks
Kishon


From majun258 at huawei.com  Tue Feb  2 02:25:53 2016
From: majun258 at huawei.com (majun (F))
Date: Tue, 2 Feb 2016 18:25:53 +0800
Subject: [RFC PATCH] irq/mbigen:Fix the problem of IO remap for duplicated
 physical address in mbigen driver
In-Reply-To: <20160201132557.GG674@leverpostej>
References: <1454327094-7848-1-git-send-email-majun258@huawei.com>
 <20160201115717.GD674@leverpostej> <56AF585E.6050005@huawei.com>
 <20160201132557.GG674@leverpostej>
Message-ID: <56B08431.3000200@huawei.com>

Hi Mark:

? 2016/2/1 21:25, Mark Rutland ??:
> On Mon, Feb 01, 2016 at 09:06:38PM +0800, majun (F) wrote:
>>
>>
>> ? 2016/2/1 19:57, Mark Rutland ??:
>>> On Mon, Feb 01, 2016 at 07:44:54PM +0800, MaJun wrote:
>>>> From: Ma Jun <majun258 at huawei.com>
>>>>
>>>> For mbigen module, there is a special case that more than one mbigen 
>>>> device nodes use the same reg definition in DTS when these devices
>>>> exist in the same mbigen hardware module. 
>>>>
>>>> mbigen_dev1:intc_dev1 {
>>>> 	...
>>>> 	reg = <0x0 0xc0080000 0x0 0x10000>;
>>>> 	...
>>>> };
>>>>
>>>> mbigen_dev2:intc_dev2 {
>>>> 	...
>>>> 	reg = <0x0 0xc0080000 0x0 0x10000>;
>>>> 	...
>>>> };
>>>
>>> This doesn't sound right. If they exist in the same place, and have the
>>> same reg, they _are_ the same device.
>>>
>>> You'll need to explain this better.
>>>
>>
>> For a mbigen hardware module which connecte with several devices,
>> because these devices has different device ID,
>> I need to define a device node for each device in DTS file.
>>
>> 	mbigen
>> 	|
>> ------------------
>> | 	| 	|
>> dev1 	dev2 	dev3
>>
>> Because of register layout,the registers related with these devices
>> are put together, I can't split them clearly.
>> So, I only make these devices which connect with
>> same mbigen hardware module usethe same address.
> 
> This sounds like we've either mis-described the mbigen in the binding,
> or we're mis-describing the relationship with the devices.
> 

Sorry, I didn't express myself clearly.

For example, a mbigen hardware module can support several peripheral devices
with different device ID.

|-----------------------|-
|	mbigen		|
|-----------------------|-
 |       |        |
dev1    dev2     dev3

To simplify the mbigen drvier,
I didn't use the whole mbigen module as a mbgien device, but use
the register collections(vector, trigger type,status etc.) corresponding
to a peripheral device as a mbigen device.
So, mbigen device is a logical conception or logical device.

Now, a mbigen hardware module contains several logical mbigen device.

-------------------------------
|mgn_dev1  mgn_dev2  mgn_dev3 |
|-----------------------------|
   |          |        |
dev1	    dev2      dev3

So,mgn_dev1, mgn_dev2 and mgn_dev3 exist in same mbigen hardware module,
and,they use the same reg address region,that is adress of mbigen hardware module.

For this case, I think the question is can we map an reg address
region more than one time?

Thanks!

> It should not be necessary to describe the same set of registers
> repeatedly.
> 
>>>>  	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>> -	mgn_chip->base = devm_ioremap_resource(&pdev->dev, res);
>>>> +	mgn_chip->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
>>>
>>> These two behaving differently doesn't seem correct either...
>>
>> The problem is caused by memory region check fail because of
>> duplicated address in devm_ioremap_resource().
> 
> The check is sensible. Using devm_ioremap rather than
> devm_ioremap_resource to avoid the check is not the correct solution.
> 
>> For mbigen special case, there is no necessary to do this check.
> 
> I'm not sure I fully agree.
> 
> Regardless, this is not the right solution; it is fragile at best.
> 
> Thanks,
> Mark.
> 
> .
> 



From ulf.hansson at linaro.org  Tue Feb  2 02:42:51 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 2 Feb 2016 11:42:51 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
References: <20160201232833.GR19432@atomide.com>
 <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>
 <20160202030533.GT19432@atomide.com>
 <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
Message-ID: <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>

>
> Instead of the suggested approaches, I think the regression should be
> fixed at the PM domain level (omap hwmod). I have attached a patch
> below, please give it try as it's untested.

Realized that version 1 would actually *only* make the PM domain code
to deal with pre-enabled devices. It would still invoke the driver's
->runtime_resume() callbacks (via pm_generic_runtime_resume())  for
these scenarios.

That's not what we want. So I moved the checks to the actual
->runtime_resume() callback in the PM domain, instead of in the
omap_device_enable() function. A version 2 is attached. Please give it
at try.

[...]

From: Ulf Hansson <ulf.hansson at linaro.org>
Date: Tue, 2 Feb 2016 10:05:39 +0100
Subject: [PATCH V2] ARM: OMAP2+: omap-device: Allow devices to be pre-enabled

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") may re-initialize the runtime PM status of the
device to RPM_SUSPENDED at driver probe failures.

For the omap_hsmmc and likely also other omap drivers, which needs more
than one attempt to ->probe() (returning -EPROBE_DEFER), this commit
causes a regression at the PM domain level (omap hwmod).

The reason is that the drivers don't put back the device into low power
state while bailing out in ->probe to return -EPROBE_DEFER. This leads to
that pm_runtime_reinit() in driver core, is re-initializing the runtime PM
status from RPM_ACTIVE to RPM_SUSPENDED.

The next ->probe() attempt then triggers the ->runtime_resume() callback
to be invoked, which means this happens two times in a row. At the PM
domain level (omap hwmod) this is being treated as an error and thus the
runtime PM status of the device isn't correctly synchronized with the
runtime PM core.

In the end, ->probe() anyway succeeds (as the driver don't checks the
error code from the runtime PM APIs), but results in that the PM domain
always stays powered on. This because of the runtime PM core believes the
device is RPM_SUSPENDED.

Fix this regression by allowing devices to be pre-enabled when the PM
domain's (omap hwmod) ->runtime_resume() callback is requested to enable
the device. In such cases, return zero to synchronize the runtime PM
status with the runtime PM core.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
---

Changes in v2:
        -Prevent a driver's ->runtime_resume() callbacks from being invoked for
        a pre-enabled device.

---
 arch/arm/mach-omap2/omap_device.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 0437537..1ad390b 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -599,8 +599,17 @@ static int _od_runtime_suspend(struct device *dev)
 static int _od_runtime_resume(struct device *dev)
 {
        struct platform_device *pdev = to_platform_device(dev);
+       struct omap_device *od = to_omap_device(pdev);
        int ret;

+       /*
+        * From the PM domain perspective the device may already be enabled.
+        * In such case, let's return zero to synchronize the state with the
+        * runtime PM core.
+       */
+       if (od->_state == OMAP_DEVICE_STATE_ENABLED)
+               return 0;
+
        ret = omap_device_enable(pdev);
        if (ret)
                return ret;
-- 
1.9.1


From catalin.marinas at arm.com  Tue Feb  2 02:44:38 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 2 Feb 2016 10:44:38 +0000
Subject: [PATCH] arm64: move back to generic
 memblock_enforce_memory_limit()
In-Reply-To: <CAKv+Gu_2JmVGpE4zvgkrX5W1nFeMLgO8C8tCLmZ9cPGrR=7Tiw@mail.gmail.com>
References: <20160201180256.GJ15514@e104818-lin.cambridge.arm.com>
 <1454351417-23732-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160202101945.GA22042@localhost.localdomain>
 <CAKv+Gu_2JmVGpE4zvgkrX5W1nFeMLgO8C8tCLmZ9cPGrR=7Tiw@mail.gmail.com>
Message-ID: <20160202104438.GB22042@localhost.localdomain>

On Tue, Feb 02, 2016 at 11:28:41AM +0100, Ard Biesheuvel wrote:
> On 2 February 2016 at 11:19, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Mon, Feb 01, 2016 at 07:30:17PM +0100, Ard Biesheuvel wrote:
> >>  void __init arm64_memblock_init(void)
> >>  {
> >>       const s64 linear_region_size = -(s64)PAGE_OFFSET;
> >> @@ -215,24 +180,14 @@ void __init arm64_memblock_init(void)
> >>       if (memblock_end_of_DRAM() > linear_region_size)
> >>               memblock_remove(0, memblock_end_of_DRAM() - linear_region_size);
> >>
> >> +     /*
> >> +      * Apply the memory limit if it was set. Since the kernel may be loaded
> >> +      * high up in memory, add back the kernel region that must be accessible
> >> +      * via the linear mapping.
> >> +      */
> >>       if (memory_limit != (phys_addr_t)ULLONG_MAX) {
> >> -             u64 kbase = round_down(__pa(_text), MIN_KIMG_ALIGN);
> >> -             u64 kend = PAGE_ALIGN(__pa(_end));
> >> -             u64 const sz_4g = 0x100000000UL;
> >> -
> >> -             /*
> >> -              * Clip memory in order of preference:
> >> -              * - above the kernel and above 4 GB
> >> -              * - between 4 GB and the start of the kernel (if the kernel
> >> -              *   is loaded high in memory)
> >> -              * - between the kernel and 4 GB (if the kernel is loaded
> >> -              *   low in memory)
> >> -              * - below 4 GB
> >> -              */
> >> -             clip_mem_range(max(sz_4g, kend), ULLONG_MAX);
> >> -             clip_mem_range(sz_4g, kbase);
> >> -             clip_mem_range(kend, sz_4g);
> >> -             clip_mem_range(0, min(kbase, sz_4g));
> >> +             memblock_enforce_memory_limit(memory_limit);
> >> +             memblock_add(__pa(__init_begin), (u64)(_end - __init_begin));
> >
> > Thanks, it looks much simpler now. However, loading the kernel 1GB
> > higher with mem=1G fails somewhere during the KVM hyp initialisation. It
> > works if I change the last line below to:
> >
> >         memblock_add(__pa(_text), (u64)(_end - _text));
> 
> OK, that should work as well.
> 
> I suppose the fact that mem= loses some of its accuracy is not an
> issue? If you need it to be exact, you should simply not load your
> kernel outside your mem= range ...

I'm not worried about accuracy. We could avoid freeing the init mem if
the kernel is outside the memory_limit range but I don't really think
it's worth.

-- 
Catalin


From matthias.bgg at gmail.com  Tue Feb  2 02:44:42 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 2 Feb 2016 11:44:42 +0100
Subject: [PATCH v4 1/4] soc: mediatek: Refine scpsys to support multiple
 platform
In-Reply-To: <1454396212.2847.15.camel@mtksdaap41>
References: <1453270097-53853-1-git-send-email-jamesjj.liao@mediatek.com>
 <1453270097-53853-2-git-send-email-jamesjj.liao@mediatek.com>
 <56ADF556.6070402@gmail.com> <1454396212.2847.15.camel@mtksdaap41>
Message-ID: <56B0889A.1010305@gmail.com>



On 02/02/16 07:56, James Liao wrote:
> Hi Matthias,
>
> On Sun, 2016-01-31 at 12:51 +0100, Matthias Brugger wrote:
>> >
>> >On 20/01/16 07:08, James Liao wrote:
>>> > >Refine scpsys driver common code to support multiple SoC / platform.
>>> > >
>>> > >Signed-off-by: James Liao<jamesjj.liao at mediatek.com>
>>> > >---
>>> > >   drivers/soc/mediatek/mtk-scpsys.c | 418 ++++++++++++++++++++------------------
>>> > >   drivers/soc/mediatek/mtk-scpsys.h |  55 +++++
>>> > >   2 files changed, 270 insertions(+), 203 deletions(-)
>>> > >   create mode 100644 drivers/soc/mediatek/mtk-scpsys.h
>> >
>> >In general this approach looks fine to me, comments below.
>> >
>>> > >
>>> > >diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
>>> > >index 0221387..339adfc 100644
>>> > >--- a/drivers/soc/mediatek/mtk-scpsys.c
>>> > >+++ b/drivers/soc/mediatek/mtk-scpsys.c
>>> > >@@ -11,29 +11,17 @@
>>> > >    * GNU General Public License for more details.
>>> > >    */
>>> > >   #include <linux/clk.h>
>>> > >-#include <linux/delay.h>
>>> > >+#include <linux/init.h>
>>> > >   #include <linux/io.h>
>>> > >-#include <linux/kernel.h>
>>> > >   #include <linux/mfd/syscon.h>
>> >
>> >When at it, do we need this include?
> syscon_regmap_lookup_by_phandle() is declared in this head file.
>
>>> > >-#include <linux/init.h>
>>> > >   #include <linux/of_device.h>
>>> > >   #include <linux/platform_device.h>
>>> > >   #include <linux/pm_domain.h>
>>> > >-#include <linux/regmap.h>
>>> > >-#include <linux/soc/mediatek/infracfg.h>
>>> > >   #include <linux/regulator/consumer.h>
>>> > >-#include <dt-bindings/power/mt8173-power.h>
>>> > >+#include <linux/soc/mediatek/infracfg.h>
>>> > >+
>>> > >+#include "mtk-scpsys.h"
>>> > >
>>> > >-#define SPM_VDE_PWR_CON			0x0210
>>> > >-#define SPM_MFG_PWR_CON			0x0214
>>> > >-#define SPM_VEN_PWR_CON			0x0230
>>> > >-#define SPM_ISP_PWR_CON			0x0238
>>> > >-#define SPM_DIS_PWR_CON			0x023c
>>> > >-#define SPM_VEN2_PWR_CON		0x0298
>>> > >-#define SPM_AUDIO_PWR_CON		0x029c
>>> > >-#define SPM_MFG_2D_PWR_CON		0x02c0
>>> > >-#define SPM_MFG_ASYNC_PWR_CON		0x02c4
>>> > >-#define SPM_USB_PWR_CON			0x02cc
>> >
>> >I would prefer to keep this defines and declare SoC specific ones where
>> >necessary. It makes the code more readable.
> Some register address may be reused by other modules among SoCs, so it's
> not easy to maintain the defines when we implement multiple SoC drivers
> in the same file. For example, offset 0x0298 is VEN2_PWR_CON on MT8173,
> but it is MJC_PWR_CON on other chips.
>

So that sounds as if 0x0298 offset is MT8173 specific.
I checked [VDE, MFG, VEN, IFR, ISP, DIS, DPY]_PWR_CON on mt8173, mt8135 
and mt6589 and they all have the same offset. So it doesn't seem as if 
the offset randomly changes for every SoC.

> Furthermore, these register offsets are only used in scp_domain_data[],
> and each element has its own power domain name. So I think it's enough
> to know which power domain are using these registers and status bits.
>

Yes that's true, but it will make it easier for another person to 
understand the driver, especially if he want's to implement the driver 
for a new SoC.

Regards,
Matthias


From matthias.bgg at gmail.com  Tue Feb  2 02:50:03 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 2 Feb 2016 11:50:03 +0100
Subject: [PATCH 1/2] Document: i2c: Add a dt binding for mediatek MT2701
 soc
In-Reply-To: <20160108074523.GA1523@katana>
References: <1451888138-11471-1-git-send-email-liguo.zhang@mediatek.com>
 <20160104095511.GB1524@katana> <1452215573.2088.1.camel@mhfsdcap03>
 <20160108074523.GA1523@katana>
Message-ID: <56B089DB.5060806@gmail.com>



On 08/01/16 08:45, Wolfram Sang wrote:
> On Fri, Jan 08, 2016 at 09:12:53AM +0800, liguo zhang wrote:
>> On Mon, 2016-01-04 at 10:55 +0100, Wolfram Sang wrote:
>>> On Mon, Jan 04, 2016 at 02:15:37PM +0800, Liguo Zhang wrote:
>>>> Add a dt binding for the MT2701 soc.
>>>>
>>>> Signed-off-by: Liguo Zhang <liguo.zhang at mediatek.com>
>>>
>>> This should probably go with the other patch via arm-soc, or?
>>
>> The patch about i2c dts info for MT2701 depends on the MT2701 clock
>> patch. After the MT2701 clock patch is accepted, the i2c patch for
>> MT2701 may be accepted.
>
> OK. Still, dts changes go via arm-soc 99% of the cases if there is no
> specific need to go via i2c.
>

No specific need here. I will take it through my branch as soon as the 
clock driver is accepted.

Liguo, please poke me on this, when this has happened and you have the 
feeling, I forgot about.


From matthias.bgg at gmail.com  Tue Feb  2 03:06:12 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 2 Feb 2016 12:06:12 +0100
Subject: [PATCH v2 3/3] ARM64: dts: mt8173: Add CPU OPP, clock and
 regulator supply properties
In-Reply-To: <20160105102455.GA30120@ubuntu>
References: <1451197318-12418-1-git-send-email-pi-cheng.chen@linaro.org>
 <1451197318-12418-4-git-send-email-pi-cheng.chen@linaro.org>
 <20151228031340.GD3598@ubuntu> <3310024.mO5K6yH9vU@wuerfel>
 <20160105102455.GA30120@ubuntu>
Message-ID: <56B08DA4.8070207@gmail.com>



On 05/01/16 11:24, Viresh Kumar wrote:
> On 05-01-16, 11:21, Arnd Bergmann wrote:
>> On Monday 28 December 2015 08:43:40 Viresh Kumar wrote:
>>> On 27-12-15, 14:21, Pi-Cheng Chen wrote:
>>>> Add operating-points-v2, clock, and regulator supply properties
>>>> required by mt8173-cpufreq driver to enable it.
>>>>
>>>> Signed-off-by: Pi-Cheng Chen <pi-cheng.chen at linaro.org>
>>>> ---
>>>> This patch is based on the patch[1] that adds underlying clock MUX for
>>>> MT8173 which is needed by mt8173-cpufreq driver but not yet picked.
>>>>
>>>> [1] http://article.gmane.org/gmane.linux.kernel.clk/325
>>>> ---
>>>>   arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 ++++++
>>>>   arch/arm64/boot/dts/mediatek/mt8173.dtsi    | 90 +++++++++++++++++++++++++++++
>>>>   2 files changed, 108 insertions(+)
>>>
>>> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
>>>
>>
>> This patch is now in linux-next through Rafael's pm tree, and it breaks the
>> arm64 build:
>>
>>          arm64-defconfig
>> Error: ../arch/arm64/boot/dts/mediatek/mt8173.dtsi:132.24-25 syntax error
>>
>>
>> Please revert.
>>
>> In the future, please send all dts changes through the proper maintainer
>> channels (-> Mattias -> arm-soc), and make sure they actually build.
>
> Rafael has already reverted that, AFAIK, after Mark Brown reported the
> build issue.
>

Applied to v4.5-next/dts

Thanks.


From matt at codeblueprint.co.uk  Tue Feb  2 03:08:21 2016
From: matt at codeblueprint.co.uk (Matt Fleming)
Date: Tue, 2 Feb 2016 11:08:21 +0000
Subject: [PATCH 1/3] arm64: efistub: drop __init annotation from
 handle_kernel_image()
In-Reply-To: <CAKv+Gu96tdf8ZrGHDi_YKacsRF_b336Nu4Anh61j4u3Lg18BHg@mail.gmail.com>
References: <1453979254-25374-1-git-send-email-ard.biesheuvel@linaro.org>
 <1453979254-25374-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160128225809.GF2571@codeblueprint.co.uk>
 <CAKv+Gu9sE4oJrFmSK8sEjTrU8A7k53Hj1S1pTyCqyA5Gsba2Kw@mail.gmail.com>
 <20160129160006.GD2611@codeblueprint.co.uk>
 <CAKv+Gu96tdf8ZrGHDi_YKacsRF_b336Nu4Anh61j4u3Lg18BHg@mail.gmail.com>
Message-ID: <20160202110821.GB2642@codeblueprint.co.uk>

On Fri, 29 Jan, at 05:03:16PM, Ard Biesheuvel wrote:
> On 29 January 2016 at 17:00, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> > On Fri, 29 Jan, at 10:36:03AM, Ard Biesheuvel wrote:
> >> On 28 January 2016 at 23:58, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> >> >
> >> > Would it make more sense to #undef __init in one of the arm64 efistub
> >> > header files? I'm thinking of the case where some poor unsuspecting
> >> > developer writes a new function and marks it as __init, and we miss it
> >> > during review.
> >> >
> >>
> >> Yes, I can add it to efistub.h, and make sure it gets included in all the files
> >>
> >> Should we #undef it and #define it to a string that is easily grep'ed
> >> for, so it is easy to find the explanatory comment that goes along
> >> with it?
> >> E.g.,
> >>
> >> #define __init __init_not_supported_in_efi_stub
> >
> > This would produce a compilation failure if someone tags something as
> > __init right? Looks fine to me.
> 
> Yes, but it makes the error message difficult to decipher, since
> __init is printed and not what it resolves to. Locally, I tried this,
> which seems to work:
> 
> #undef __init
> #define __init __attribute__((__init_not_supported_in_efi_stub))
> #pragma GCC diagnostic error "-Wattributes"
> 
> which produces
> 
>   CC      drivers/firmware/efi/libstub/arm-stub.o
> /home/ard/linux-2.6/drivers/firmware/efi/libstub/arm-stub.c:24:1:
> error: ?__init_not_supported_in_efi_stub? attribute directive ignored
> [-Werror=attributes]
>  {
>  ^
> cc1: some warnings being treated as errors
> 
> which is slightly dodgy, but at least puts the string right in the error message

What about,

#define __init __compiletime_error("__init not supported in EFI boot stub")

?


From ard.biesheuvel at linaro.org  Tue Feb  2 03:09:41 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 2 Feb 2016 12:09:41 +0100
Subject: [PATCH 1/3] arm64: efistub: drop __init annotation from
 handle_kernel_image()
In-Reply-To: <20160202110821.GB2642@codeblueprint.co.uk>
References: <1453979254-25374-1-git-send-email-ard.biesheuvel@linaro.org>
 <1453979254-25374-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160128225809.GF2571@codeblueprint.co.uk>
 <CAKv+Gu9sE4oJrFmSK8sEjTrU8A7k53Hj1S1pTyCqyA5Gsba2Kw@mail.gmail.com>
 <20160129160006.GD2611@codeblueprint.co.uk>
 <CAKv+Gu96tdf8ZrGHDi_YKacsRF_b336Nu4Anh61j4u3Lg18BHg@mail.gmail.com>
 <20160202110821.GB2642@codeblueprint.co.uk>
Message-ID: <CAKv+Gu_rvLMFF9ssdY4GCWpdcOwaXVsaCvBTYG30NS0zw5xBWw@mail.gmail.com>

On 2 February 2016 at 12:08, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> On Fri, 29 Jan, at 05:03:16PM, Ard Biesheuvel wrote:
>> On 29 January 2016 at 17:00, Matt Fleming <matt at codeblueprint.co.uk> wrote:
>> > On Fri, 29 Jan, at 10:36:03AM, Ard Biesheuvel wrote:
>> >> On 28 January 2016 at 23:58, Matt Fleming <matt at codeblueprint.co.uk> wrote:
>> >> >
>> >> > Would it make more sense to #undef __init in one of the arm64 efistub
>> >> > header files? I'm thinking of the case where some poor unsuspecting
>> >> > developer writes a new function and marks it as __init, and we miss it
>> >> > during review.
>> >> >
>> >>
>> >> Yes, I can add it to efistub.h, and make sure it gets included in all the files
>> >>
>> >> Should we #undef it and #define it to a string that is easily grep'ed
>> >> for, so it is easy to find the explanatory comment that goes along
>> >> with it?
>> >> E.g.,
>> >>
>> >> #define __init __init_not_supported_in_efi_stub
>> >
>> > This would produce a compilation failure if someone tags something as
>> > __init right? Looks fine to me.
>>
>> Yes, but it makes the error message difficult to decipher, since
>> __init is printed and not what it resolves to. Locally, I tried this,
>> which seems to work:
>>
>> #undef __init
>> #define __init __attribute__((__init_not_supported_in_efi_stub))
>> #pragma GCC diagnostic error "-Wattributes"
>>
>> which produces
>>
>>   CC      drivers/firmware/efi/libstub/arm-stub.o
>> /home/ard/linux-2.6/drivers/firmware/efi/libstub/arm-stub.c:24:1:
>> error: ?__init_not_supported_in_efi_stub? attribute directive ignored
>> [-Werror=attributes]
>>  {
>>  ^
>> cc1: some warnings being treated as errors
>>
>> which is slightly dodgy, but at least puts the string right in the error message
>
> What about,
>
> #define __init __compiletime_error("__init not supported in EFI boot stub")
>

That only works for invocations, i.e., it needs to be used in header
files, and will trigger the error if a call to the function remains
after optimization. We want it at function definition time instead.


From yao.yuan at nxp.com  Tue Feb  2 03:10:41 2016
From: yao.yuan at nxp.com (Yao Yuan)
Date: Tue, 2 Feb 2016 11:10:41 +0000
Subject: [PATCH] dts/ls1021a: add the DTS for QSPI support
In-Reply-To: <20160202074907.GK8307@tiger>
References: <1453970006-46509-1-git-send-email-yao.yuan@freescale.com>
 <20160202074907.GK8307@tiger>
Message-ID: <AM2PR04MB07222EF8C4A2B70D383D621789DF0@AM2PR04MB0722.eurprd04.prod.outlook.com>

On Tue, Feb 02, 2016 at 03:49PM, Shawn Guo wrote:
> On Thu, Jan 28, 2016 at 04:33:26PM +0800, Yuan Yao wrote:
> > From: Yuan Yao <yao.yuan at nxp.com>
> >
> > Signed-off-by: Yuan Yao <yao.yuan at nxp.com>
> > ---
> > Add in v1:
> > Can merge, but the function depend on the patch:
> > https://patchwork.kernel.org/patch/8118251/
> 
> Please send me dts patch only after the driver part gets applied.

Ok, I will resend the patch after the driver part gets applied.
I just only want to speed up my upstream.

> 
> >
> > mtd: spi-nor: fsl-quadspi: add support for ls1021a
> >
> > LS1021a also support Freescale Quad SPI controller.
> > Add fsl-quadspi support for ls1021a chip and make SPI_FSL_QUADSPI
> > selectable for LS1021A SOC hardwares.
> >
> > ---
> >  arch/arm/boot/dts/ls1021a.dtsi | 15 +++++++++++++++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/ls1021a.dtsi
> > b/arch/arm/boot/dts/ls1021a.dtsi index 9430a99..c764fa5 100644
> > --- a/arch/arm/boot/dts/ls1021a.dtsi
> > +++ b/arch/arm/boot/dts/ls1021a.dtsi
> > @@ -252,6 +252,21 @@
> >  			status = "disabled";
> >  		};
> >
> > +		qspi: quadspi at 1550000 {
> > +			compatible = "fsl,ls1021a-qspi";
> > +			#address-cells = <1>;
> > +			#size-cells = <0>;
> > +			reg = <0x0 0x1550000 0x0 0x10000>,
> > +				<0x0 0x40000000 0x0 0x4000000>;
> > +			reg-names = "QuadSPI", "QuadSPI-memory";
> > +			interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
> > +			clock-names = "qspi_en", "qspi";
> > +			clocks = <&platform_clk 1>, <&platform_clk 1>;
> > +			big-endian;
> > +			amba-base = <0x40000000>;
> 
> What is this property?  I cannot find it in any bindings doc.  Is it added by your
> patches on driver code?

Sorry, it's the legacy property, after the latest discussion we will remove this property.
So I will remove it in the next version.
Thanks for your review.

Yuan Yao.


From maxime.ripard at free-electrons.com  Tue Feb  2 03:15:41 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 12:15:41 +0100
Subject: [PATCH 1/2] clk: sunxi: Add support for A80 APBS clock
In-Reply-To: <1454337769-4130-2-git-send-email-wens@csie.org>
References: <1454337769-4130-1-git-send-email-wens@csie.org>
 <1454337769-4130-2-git-send-email-wens@csie.org>
Message-ID: <20160202111541.GN4652@lukather>

Hi Chen-Yu

On Mon, Feb 01, 2016 at 10:42:48PM +0800, Chen-Yu Tsai wrote:
> A80's APBS clock is not the same as the APB0 clock on A23. The A80's
> is a zero-based divider, while the A23's is a power-of-two divider.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
>  drivers/clk/sunxi/Makefile                        |  2 +-
>  drivers/clk/sunxi/clk-sun9i-apbs.c                | 64 +++++++++++++++++++++++
>  3 files changed, 66 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/clk/sunxi/clk-sun9i-apbs.c
> 
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index e59f57b24777..fad81157798c 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -58,6 +58,7 @@ Required properties:
>  	"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
>  	"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
>  	"allwinner,sun8i-h3-bus-gates-clk" - for the bus gates on H3
> +	"allwinner,sun9i-a80-apbs-clk" - for the APBS clock on A80
>  	"allwinner,sun9i-a80-apbs-gates-clk" - for the APBS gates on A80
>  	"allwinner,sun4i-a10-dram-gates-clk" - for the DRAM gates on A10
>  	"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> index 3fd7901d48e4..df433b3f789d 100644
> --- a/drivers/clk/sunxi/Makefile
> +++ b/drivers/clk/sunxi/Makefile
> @@ -17,7 +17,7 @@ obj-y += clk-sun9i-core.o
>  obj-y += clk-sun9i-mmc.o
>  obj-y += clk-usb.o
>  
> -obj-$(CONFIG_MACH_SUN9I) += clk-sun8i-apb0.o
> +obj-$(CONFIG_MACH_SUN9I) += clk-sun9i-apbs.o
>  obj-$(CONFIG_MACH_SUN9I) += clk-sun9i-cpus.o
>  
>  obj-$(CONFIG_MFD_SUN6I_PRCM) += \
> diff --git a/drivers/clk/sunxi/clk-sun9i-apbs.c b/drivers/clk/sunxi/clk-sun9i-apbs.c
> new file mode 100644
> index 000000000000..aacb92873621
> --- /dev/null
> +++ b/drivers/clk/sunxi/clk-sun9i-apbs.c
> @@ -0,0 +1,64 @@
> +/*
> + * Copyright (C) 2016 Chen-Yu Tsai
> + * Author: Chen-Yu Tsai <wens at csie.org>
> + *
> + * Allwinner A80 APBS clock driver
> + *
> + * License Terms: GNU General Public License v2
> + *
> + * Based on clk-sun6i-apbs.c
> + * Allwinner A31 APB0 clock driver
> + *
> + * Copyright (C) 2014 Free Electrons
> + * Author: Boris BREZILLON <boris.brezillon at free-electrons.com>
> + *
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +
> +static void sun9i_apbs_setup(struct device_node *node)
> +{
> +	const char *name = node->name;
> +	const char *parent;
> +	struct resource res;
> +	struct clk *clk;
> +	void __iomem *reg;
> +	int ret;
> +
> +	reg = of_io_request_and_map(node, 0, of_node_full_name(node));
> +	if (IS_ERR(reg)) {
> +		pr_err("Could not get registers for a80-apbs-clk\n");
> +		return;
> +	}
> +
> +	parent = of_clk_get_parent_name(node, 0);
> +	if (!parent)
> +		return;
> +
> +	of_property_read_string(node, "clock-output-names", &name);
> +
> +	/* The A80 APBS clock is a standard 2 bit wide divider clock */
> +	clk = clk_register_divider(NULL, name, parent, 0, reg, 0, 2, 0, NULL);
> +	if (IS_ERR(clk)) {
> +		pr_err("failed to register a80-apbs-clk: %ld\n", PTR_ERR(clk));
> +		goto err_unmap;
> +	}
> +
> +	ret = of_clk_add_provider(node, of_clk_src_simple_get, clk);
> +	if (ret)
> +		goto err_unregister;
> +
> +	return;
> +
> +err_unregister:
> +	clk_unregister_divider(clk);
> +err_unmap:
> +	iounmap(reg);
> +	of_address_to_resource(node, 0, &res);
> +	release_mem_region(res.start, resource_size(&res));
> +}
> +CLK_OF_DECLARE(sun9i_apbs, "allwinner,sun9i-a80-apbs-clk", sun9i_apbs_setup);

So it's just a different set of flags? Maybe we can simply reuse the
same driver.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/449cde76/attachment.sig>

From ulf.hansson at linaro.org  Tue Feb  2 03:21:32 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 2 Feb 2016 12:21:32 +0100
Subject: [PATCH v4] mmc: meson: Add driver for the SD/MMC host found on
 Amlogic MesonX SoCs
In-Reply-To: <CAOQ7t2afXxStCsj=M-FX7eMep1gLt4jkyXDiLas_SQ1UwHc0=Q@mail.gmail.com>
References: <1448988109-32630-1-git-send-email-carlo@caione.org>
 <CAPDyKFp=buvJ8Li3XC8XSUAUO7BsE+U6vEQH2xTrgcHAkdG8bQ@mail.gmail.com>
 <CAOQ7t2aJAPWd3Xmvu7n0EWL-KC8ZriM3KryfsYEh556uXhuR+g@mail.gmail.com>
 <CAPDyKFpcsKihuOiF5=RwoWrF0Jf7hRsXVSU5uV8qZf1mUsa-iQ@mail.gmail.com>
 <CAOQ7t2afXxStCsj=M-FX7eMep1gLt4jkyXDiLas_SQ1UwHc0=Q@mail.gmail.com>
Message-ID: <CAPDyKFpX+_fHvv_bJUKZmSufKKnuONC582E7u3b20a+Rbbggng@mail.gmail.com>

On 1 February 2016 at 23:05, Carlo Caione <carlo at caione.org> wrote:
> On Tue, Dec 8, 2015 at 9:35 PM, Ulf Hansson <ulf.hansson at linaro.org> wrote:
>
> Hi Ulf,
> (old thread, I know)
>
>>> I have actually a problem and a question related to this value. On the
>>> boards I'm currently using to test this driver I have no CD GPIO. In
>>> this case do I have to specify the MMC as "non-removable"? Also if I
>>
>> "non-removable" is intended to be used for eMMC or other cards
>> (SD/SDIO) that is not possible to remove/insert at runtime.
>>
>>> try to change an SD card at runtime I have to wait 3 times the timeout
>>> before being able to do it successfully.
>>
>> I guess you are using the "broken-cd" binding, which will enable
>> MMC_CAP_NEEDS_POLL and thus the mmc core will poll to detect cards
>> being inserted or removed.
>
> I still fail to see what the correct behaviour should be.
> Using the v4 of this driver with a "broken-cd" binding and a timeout
> of 10s my SD card takes 30s to be identified as removed after I take
> it out from the SD slot.
> Also, if I take it out and insert it again, I still have to wait 30s
> to be able to access it again. Is this a limitation / bug of my driver
> or is this the expected behaviour when we do not have a dedicated GPIO
> for card detection?

It's *not* an expected a behaviour.

Using MMC_CAP_NEEDS_POLL, means that the mmc core will send CMD13
commands in a polling manner to find out whether a card has been
removed.

It seems like when the card is removed, the host driver doesn't get an
IRQ which indicates a command timeout. Instead it waits for the 10 s
timeout to expire.

My question is then; why don't the driver get an IRQ for the command
timeout? Is that because of non-correct setup of the IRQ masks or
because the controller HW doesn't support this?

Kind regards
Uffe


From horms+renesas at verge.net.au  Tue Feb  2 03:24:14 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Feb 2016 12:24:14 +0100
Subject: [PATCH] ARM: dts: r8a7795: use GIC_* defines
Message-ID: <1454412254-11911-1-git-send-email-horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7795 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
* Based on renesas-devel-20160129-v4.5-rc1
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 108 +++++++++++++++----------------
 1 file changed, 54 insertions(+), 54 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 119549e6502d..d351f2c4b40e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -266,23 +266,23 @@
 		audma0: dma-controller at ec700000 {
 			compatible = "renesas,rcar-dmac";
 			reg = <0 0xec700000 0 0x10000>;
-			interrupts =	<0 350 IRQ_TYPE_LEVEL_HIGH
-					 0 320 IRQ_TYPE_LEVEL_HIGH
-					 0 321 IRQ_TYPE_LEVEL_HIGH
-					 0 322 IRQ_TYPE_LEVEL_HIGH
-					 0 323 IRQ_TYPE_LEVEL_HIGH
-					 0 324 IRQ_TYPE_LEVEL_HIGH
-					 0 325 IRQ_TYPE_LEVEL_HIGH
-					 0 326 IRQ_TYPE_LEVEL_HIGH
-					 0 327 IRQ_TYPE_LEVEL_HIGH
-					 0 328 IRQ_TYPE_LEVEL_HIGH
-					 0 329 IRQ_TYPE_LEVEL_HIGH
-					 0 330 IRQ_TYPE_LEVEL_HIGH
-					 0 331 IRQ_TYPE_LEVEL_HIGH
-					 0 332 IRQ_TYPE_LEVEL_HIGH
-					 0 333 IRQ_TYPE_LEVEL_HIGH
-					 0 334 IRQ_TYPE_LEVEL_HIGH
-					 0 335 IRQ_TYPE_LEVEL_HIGH>;
+			interrupts = <GIC_SPI 350 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "error",
 					"ch0", "ch1", "ch2", "ch3",
 					"ch4", "ch5", "ch6", "ch7",
@@ -298,23 +298,23 @@
 		audma1: dma-controller at ec720000 {
 			compatible = "renesas,rcar-dmac";
 			reg = <0 0xec720000 0 0x10000>;
-			interrupts =	<0 351 IRQ_TYPE_LEVEL_HIGH
-					 0 336 IRQ_TYPE_LEVEL_HIGH
-					 0 337 IRQ_TYPE_LEVEL_HIGH
-					 0 338 IRQ_TYPE_LEVEL_HIGH
-					 0 339 IRQ_TYPE_LEVEL_HIGH
-					 0 340 IRQ_TYPE_LEVEL_HIGH
-					 0 341 IRQ_TYPE_LEVEL_HIGH
-					 0 342 IRQ_TYPE_LEVEL_HIGH
-					 0 343 IRQ_TYPE_LEVEL_HIGH
-					 0 344 IRQ_TYPE_LEVEL_HIGH
-					 0 345 IRQ_TYPE_LEVEL_HIGH
-					 0 346 IRQ_TYPE_LEVEL_HIGH
-					 0 347 IRQ_TYPE_LEVEL_HIGH
-					 0 348 IRQ_TYPE_LEVEL_HIGH
-					 0 349 IRQ_TYPE_LEVEL_HIGH
-					 0 382 IRQ_TYPE_LEVEL_HIGH
-					 0 383 IRQ_TYPE_LEVEL_HIGH>;
+			interrupts = <GIC_SPI 351 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 348 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 349 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 382 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 383 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "error",
 					"ch0", "ch1", "ch2", "ch3",
 					"ch4", "ch5", "ch6", "ch7",
@@ -750,52 +750,52 @@
 
 			rcar_sound,src {
 				src0: src at 0 {
-					interrupts = <0 352 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x85>, <&audma1 0x9a>;
 					dma-names = "rx", "tx";
 				};
 				src1: src at 1 {
-					interrupts = <0 353 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x87>, <&audma1 0x9c>;
 					dma-names = "rx", "tx";
 				};
 				src2: src at 2 {
-					interrupts = <0 354 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x89>, <&audma1 0x9e>;
 					dma-names = "rx", "tx";
 				};
 				src3: src at 3 {
-					interrupts = <0 355 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x8b>, <&audma1 0xa0>;
 					dma-names = "rx", "tx";
 				};
 				src4: src at 4 {
-					interrupts = <0 356 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x8d>, <&audma1 0xb0>;
 					dma-names = "rx", "tx";
 				};
 				src5: src at 5 {
-					interrupts = <0 357 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x8f>, <&audma1 0xb2>;
 					dma-names = "rx", "tx";
 				};
 				src6: src at 6 {
-					interrupts = <0 358 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x91>, <&audma1 0xb4>;
 					dma-names = "rx", "tx";
 				};
 				src7: src at 7 {
-					interrupts = <0 359 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x93>, <&audma1 0xb6>;
 					dma-names = "rx", "tx";
 				};
 				src8: src at 8 {
-					interrupts = <0 360 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x95>, <&audma1 0xb8>;
 					dma-names = "rx", "tx";
 				};
 				src9: src at 9 {
-					interrupts = <0 361 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x97>, <&audma1 0xba>;
 					dma-names = "rx", "tx";
 				};
@@ -803,52 +803,52 @@
 
 			rcar_sound,ssi {
 				ssi0: ssi at 0 {
-					interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x01>, <&audma1 0x02>, <&audma0 0x15>, <&audma1 0x16>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi1: ssi at 1 {
-					 interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>;
+					 interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x03>, <&audma1 0x04>, <&audma0 0x49>, <&audma1 0x4a>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi2: ssi at 2 {
-					interrupts = <0 372 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x05>, <&audma1 0x06>, <&audma0 0x63>, <&audma1 0x64>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi3: ssi at 3 {
-					interrupts = <0 373 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x07>, <&audma1 0x08>, <&audma0 0x6f>, <&audma1 0x70>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi4: ssi at 4 {
-					interrupts = <0 374 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x09>, <&audma1 0x0a>, <&audma0 0x71>, <&audma1 0x72>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi5: ssi at 5 {
-					interrupts = <0 375 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x0b>, <&audma1 0x0c>, <&audma0 0x73>, <&audma1 0x74>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi6: ssi at 6 {
-					interrupts = <0 376 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x0d>, <&audma1 0x0e>, <&audma0 0x75>, <&audma1 0x76>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi7: ssi at 7 {
-					interrupts = <0 377 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x0f>, <&audma1 0x10>, <&audma0 0x79>, <&audma1 0x7a>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi8: ssi at 8 {
-					interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x11>, <&audma1 0x12>, <&audma0 0x7b>, <&audma1 0x7c>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi9: ssi at 9 {
-					interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x13>, <&audma1 0x14>, <&audma0 0x7d>, <&audma1 0x7e>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
-- 
2.7.0.rc3.207.g0ac5344



From robert.richter at caviumnetworks.com  Tue Feb  2 03:26:42 2016
From: robert.richter at caviumnetworks.com (Robert Richter)
Date: Tue, 2 Feb 2016 12:26:42 +0100
Subject: [PATCH v10 0/8] arm64, numa: Add numa support for arm64 platforms
In-Reply-To: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
References: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
Message-ID: <20160202112642.GE24726@rric.localdomain>

On 02.02.16 15:39:15, Ganapatrao Kulkarni wrote:

> Ganapatrao Kulkarni (8):
>   arm64, numa: adding numa support for arm64 platforms.
>   Documentation, dt, numa: dt bindings for numa.
>   dt, numa: adding numa dt binding implementation.
>   arm64, numa : Enable numa dt for arm64 platforms.
>   arm64, dt, thunderx: Add initial dts for Cavium Thunderx in 2 node
>     topology.
>   arm64, mm, numa: Adding numa balancing support for arm64.
>   topology, cleanup: Avoid redefinition of cpumask_of_pcibus in asm
>     header files.
>   numa, mm, cleanup: remove redundant NODE_DATA macro from asm header
>     files.

I have tested the whole series on single and dual node systems for
devicetree and acpi (with Hanjun's acpi numa v3 patches ported on
top).

Tested-by: Robert Richter <rrichter at cavium.com>

-Robert

> 
>  Documentation/devicetree/bindings/numa.txt      | 272 ++++++++
>  arch/arm64/Kconfig                              |  26 +
>  arch/arm64/boot/dts/cavium/Makefile             |   2 +-
>  arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts  |  83 +++
>  arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi | 806 ++++++++++++++++++++++++
>  arch/arm64/include/asm/mmzone.h                 |  10 +
>  arch/arm64/include/asm/numa.h                   |  45 ++
>  arch/arm64/include/asm/pgtable.h                |  18 +
>  arch/arm64/include/asm/topology.h               |   7 +
>  arch/arm64/kernel/pci.c                         |  10 +
>  arch/arm64/kernel/setup.c                       |   4 +
>  arch/arm64/kernel/smp.c                         |   4 +
>  arch/arm64/mm/Makefile                          |   1 +
>  arch/arm64/mm/init.c                            |  34 +-
>  arch/arm64/mm/mmu.c                             |   1 +
>  arch/arm64/mm/numa.c                            | 404 ++++++++++++
>  arch/ia64/include/asm/topology.h                |   4 -
>  arch/m32r/include/asm/mmzone.h                  |   4 +-
>  arch/metag/include/asm/mmzone.h                 |   4 +-
>  arch/metag/include/asm/topology.h               |   3 -
>  arch/powerpc/include/asm/mmzone.h               |   8 +-
>  arch/powerpc/include/asm/topology.h             |   4 -
>  arch/s390/include/asm/mmzone.h                  |   6 +-
>  arch/s390/include/asm/pci.h                     |   2 +-
>  arch/s390/include/asm/topology.h                |   1 +
>  arch/sh/include/asm/mmzone.h                    |   4 +-
>  arch/sh/include/asm/topology.h                  |   3 -
>  arch/sparc/include/asm/mmzone.h                 |   6 +-
>  arch/tile/include/asm/pci.h                     |   2 -
>  arch/tile/include/asm/topology.h                |   3 +
>  arch/x86/include/asm/mmzone.h                   |   3 +-
>  arch/x86/include/asm/mmzone_32.h                |   5 -
>  arch/x86/include/asm/mmzone_64.h                |  17 -
>  arch/x86/include/asm/pci.h                      |   2 +-
>  arch/x86/include/asm/topology.h                 |   1 +
>  drivers/of/Kconfig                              |  11 +
>  drivers/of/Makefile                             |   1 +
>  drivers/of/of_numa.c                            | 207 ++++++
>  include/asm-generic/mmzone.h                    |  24 +
>  include/asm-generic/topology.h                  |   4 +-
>  include/linux/of.h                              |   4 +
>  41 files changed, 1986 insertions(+), 74 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/numa.txt
>  create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dts
>  create mode 100644 arch/arm64/boot/dts/cavium/thunder-88xx-2n.dtsi
>  create mode 100644 arch/arm64/include/asm/mmzone.h
>  create mode 100644 arch/arm64/include/asm/numa.h
>  create mode 100644 arch/arm64/mm/numa.c
>  delete mode 100644 arch/x86/include/asm/mmzone_64.h
>  create mode 100644 drivers/of/of_numa.c
>  create mode 100644 include/asm-generic/mmzone.h
> 
> -- 
> 1.8.1.4
> 


From marc.zyngier at arm.com  Tue Feb  2 03:27:09 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 2 Feb 2016 11:27:09 +0000
Subject: [PATCH v2 14/21] arm64: KVM: VHE: Implement VHE
 activate/deactivate_traps
In-Reply-To: <20160201142045.GT1478@cbox>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-15-git-send-email-marc.zyngier@arm.com>
 <20160201142045.GT1478@cbox>
Message-ID: <56B0928D.8020003@arm.com>

On 01/02/16 14:20, Christoffer Dall wrote:
> On Mon, Jan 25, 2016 at 03:53:48PM +0000, Marc Zyngier wrote:
>> Running the kernel in HYP mode requires the HCR_E2H bit to be set
>> at all times, and the HCR_TGE bit to be set when running as a host
>> (and cleared when running as a guest). At the same time, the vector
>>  must be set to the current role of the kernel (either host or
>> hypervisor), and a couple of system registers differ between VHE
>> and non-VHE.
>>
>> We implement these by using another set of alternate functions
>> that get dynamically patched.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/include/asm/kvm_arm.h     |  1 +
>>  arch/arm64/include/asm/kvm_emulate.h |  3 +++
>>  arch/arm64/kvm/hyp/switch.c          | 52 +++++++++++++++++++++++++++++++++---
>>  3 files changed, 53 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
>> index 738a95f..73d3826 100644
>> --- a/arch/arm64/include/asm/kvm_arm.h
>> +++ b/arch/arm64/include/asm/kvm_arm.h
>> @@ -23,6 +23,7 @@
>>  #include <asm/types.h>
>>  
>>  /* Hyp Configuration Register (HCR) bits */
>> +#define HCR_E2H		(UL(1) << 34)
>>  #define HCR_ID		(UL(1) << 33)
>>  #define HCR_CD		(UL(1) << 32)
>>  #define HCR_RW_SHIFT	31
>> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
>> index 3066328..5ae0c69 100644
>> --- a/arch/arm64/include/asm/kvm_emulate.h
>> +++ b/arch/arm64/include/asm/kvm_emulate.h
>> @@ -29,6 +29,7 @@
>>  #include <asm/kvm_mmio.h>
>>  #include <asm/ptrace.h>
>>  #include <asm/cputype.h>
>> +#include <asm/virt.h>
>>  
>>  unsigned long *vcpu_reg32(const struct kvm_vcpu *vcpu, u8 reg_num);
>>  unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu);
>> @@ -43,6 +44,8 @@ void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
>>  static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu)
>>  {
>>  	vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
>> +	if (is_kernel_in_hyp_mode())
>> +		vcpu->arch.hcr_el2 |= HCR_E2H;
>>  	if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features))
>>  		vcpu->arch.hcr_el2 &= ~HCR_RW;
>>  }
>> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
>> index 6f264dc..77f7c94 100644
>> --- a/arch/arm64/kvm/hyp/switch.c
>> +++ b/arch/arm64/kvm/hyp/switch.c
>> @@ -15,6 +15,8 @@
>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>   */
>>  
>> +#include <asm/kvm_asm.h>
>> +
>>  #include "hyp.h"
>>  
>>  static bool __hyp_text __fpsimd_enabled_nvhe(void)
>> @@ -36,6 +38,27 @@ bool __hyp_text __fpsimd_enabled(void)
>>  	return __fpsimd_is_enabled()();
>>  }
>>  
>> +static void __hyp_text __activate_traps_vhe(void)
>> +{
>> +	u64 val;
>> +
>> +	val = read_sysreg(cpacr_el1);
>> +	val |= 1 << 28;
>> +	val &= ~(3 << 20);
> 
> could you define these bitfields as well?

Sure.

> 
>> +	write_sysreg(val, cpacr_el1);
>> +
>> +	write_sysreg(__kvm_hyp_vector, vbar_el1);
>> +}
>> +
>> +static void __hyp_text __activate_traps_nvhe(void)
>> +{
>> +	write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
>> +}
>> +
>> +static hyp_alternate_select(__activate_traps_arch,
>> +			    __activate_traps_nvhe, __activate_traps_vhe,
>> +			    ARM64_HAS_VIRT_HOST_EXTN);
>> +
>>  static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
>>  {
>>  	u64 val;
>> @@ -55,16 +78,39 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
>>  	write_sysreg(val, hcr_el2);
>>  	/* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
>>  	write_sysreg(1 << 15, hstr_el2);
>> -	write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
>>  	write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
>> +	__activate_traps_arch()();
>>  }
>>  
>> -static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
>> +static void __hyp_text __deactivate_traps_vhe(void)
>> +{
>> +	extern char vectors[];	/* kernel exception vectors */
>> +	u64 val;
>> +
>> +	write_sysreg(HCR_RW | HCR_TGE | HCR_E2H, hcr_el2);
> 
> perhaps we should define the EL2_HOST_HCR bit settings somewhere
> globally and reuse that here?

I'm going for HCR_HOST_VHE_FLAGS, as a pendant to HCR_GUEST_FLAGS.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From hanjun.guo at linaro.org  Tue Feb  2 03:30:12 2016
From: hanjun.guo at linaro.org (Hanjun Guo)
Date: Tue, 2 Feb 2016 19:30:12 +0800
Subject: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT
 and SLIT
In-Reply-To: <20160201180944.GV24726@rric.localdomain>
References: <1453541967-3744-1-git-send-email-guohanjun@huawei.com>
 <1453541967-3744-6-git-send-email-guohanjun@huawei.com>
 <20160201180944.GV24726@rric.localdomain>
Message-ID: <56B09344.4000100@linaro.org>

On 2016/2/2 2:09, Robert Richter wrote:
> On 23.01.16 17:39:20, Hanjun Guo wrote:
>
>> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
>>   {
>>   	int ret = -ENODEV;
>>
>> -#ifdef CONFIG_OF_NUMA
>>   	if (!numa_off)
>> -		ret = numa_init(arm64_of_numa_init);
>> -#endif
>> +		ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
>>
>>   	if (ret)
>>   		numa_init(dummy_numa_init);
>
> Ok, this style is mostly flavor, some people want #ifdefs (my
> preference), some not. In any case it must build with or without the
> config option set. But first some words why I like #ifdefs:
>
>   * Code is easier to understand as you don't need to look at any other
>     location whether it is enabled or not.
>
>   * You can't break the build if the options are not set. Thus, you
>     also don't need to check if the function is implemented for the
>     unset case (valid for the coder and also the reviewer). This makes
>     things a lot easier.
>
>   * Total number of lines of code that needs to be implement is
>     smaller.
>
> However, if we don't ifdef the code, we need empty functions stubs in
> the header file for them.
>
> Also, the conditional assignment does not reduce the complexity of the
> paths. It just concentrates everything in a single line.
>
> How about the following (similar to x86)?
>
> ----
> 	if (!numa_off) {
> #ifdef CONFIG_ACPI_NUMA
> 		if (!numa_init(acpi_numa_init))
> 			return 0;
> #endif
> #ifdef CONFIG_OF_NUMA
> 		if (!numa_init(of_numa_init))
> 			return 0;
> #endif
> 	}
>
> 	return numa_init(dummy_numa_init);
> ----
>
> Pretty straight and nice.
>
> Note: The !acpi_disabled check needs to be moved to the beginning of
> acpi_numa_init(). Variable ret can be removed.

Lorenzo suggested to remove it, Lorenzo, what's your opinion here?

Thanks
Hanjun


From ulf.hansson at linaro.org  Tue Feb  2 03:32:29 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 2 Feb 2016 12:32:29 +0100
Subject: [PATCH] mmc: sdhci-of-at91: fix pm runtime unbalanced issue in
 error path
In-Reply-To: <1453804954-3490-1-git-send-email-jszhang@marvell.com>
References: <1453804954-3490-1-git-send-email-jszhang@marvell.com>
Message-ID: <CAPDyKFoAHPVHybhZG4BRcWHe8rm4MF0env0LfOuV2V5KZ9OaYQ@mail.gmail.com>

On 26 January 2016 at 11:42, Jisheng Zhang <jszhang at marvell.com> wrote:
> The device power usage counter is increased by pm_runtime_get_noresume
> but isn't decreased in err_add_host error path.
>
> Fix this issue by calling pm_runtime_put_noidle() in the error path to
> restore the device's power usage counter.
>
> Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
> Fixes: f5f17813ae9b ("mmc: sdhci-of-at91: add PM support)
> ---
>  drivers/mmc/host/sdhci-of-at91.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-at91.c b/drivers/mmc/host/sdhci-of-at91.c
> index 7db7163..3bf6f31 100644
> --- a/drivers/mmc/host/sdhci-of-at91.c
> +++ b/drivers/mmc/host/sdhci-of-at91.c
> @@ -210,7 +210,7 @@ static int sdhci_at91_probe(struct platform_device *pdev)
>
>  pm_runtime_disable:
>         pm_runtime_disable(&pdev->dev);
> -       pm_runtime_set_suspended(&pdev->dev);

What's the reason you want to remove the call to
pm_runtime_set_suspended()? I think it could stay.

> +       pm_runtime_put_noidle(&pdev->dev);
>  clocks_disable_unprepare:
>         clk_disable_unprepare(priv->gck);
>         clk_disable_unprepare(priv->mainck);
> --
> 2.7.0
>

Kind regards
Uffe


From andre.przywara at arm.com  Tue Feb  2 03:32:29 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 2 Feb 2016 11:32:29 +0000
Subject: [PATCH 1/5] clk: sunxi: Make clocks setup functions return their
 clock
In-Reply-To: <CAGb2v66CyhkM0vabbede43eAaf7WVg0Lm8w_OUKwqHnFO182uw@mail.gmail.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454402834-6385-2-git-send-email-maxime.ripard@free-electrons.com>
 <CAGb2v66CyhkM0vabbede43eAaf7WVg0Lm8w_OUKwqHnFO182uw@mail.gmail.com>
Message-ID: <56B093CD.6000806@arm.com>

Hi Maxime,

On 02/02/16 10:35, Chen-Yu Tsai wrote:
> On Tue, Feb 2, 2016 at 4:47 PM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
>> The clocks registration code in clk-sunxi was most of the time not
>> returning the struct clk (or struct clk array) that was registered,
>> preventing the users of such functions to manipulate it, for example to
>> protect it.
>>
>> Make them return it so that we can start using it.
> 
> Should they return error codes as well? So the CLK_OF_DECLARE setup functions
> can report errors. Or make these helper functions report errors directly?

Yeah, I was about the reply the same.
It looks like we can use the ERR_PTR facility to achieve this, as it's
already used in other parts of the clk framework.

For instance ...

> ChenYu
> 
>> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
>> ---
>>  drivers/clk/sunxi/clk-sunxi.c | 16 +++++++++-------
>>  1 file changed, 9 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>> index e460a6b0068c..67ef94948544 100644
>> --- a/drivers/clk/sunxi/clk-sunxi.c
>> +++ b/drivers/clk/sunxi/clk-sunxi.c
>> @@ -615,8 +615,8 @@ static const struct mux_data sun8i_h3_ahb2_mux_data __initconst = {
>>         .shift = 0,
>>  };
>>
>> -static void __init sunxi_mux_clk_setup(struct device_node *node,
>> -                                      struct mux_data *data)
>> +static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
>> +                                              struct mux_data *data)
>>  {
>>         struct clk *clk;
>>         const char *clk_name = node->name;
>> @@ -638,6 +638,8 @@ static void __init sunxi_mux_clk_setup(struct device_node *node,
>>                 of_clk_add_provider(node, of_clk_src_simple_get, clk);
>>                 clk_register_clkdev(clk, clk_name, NULL);

... here we have two functions that could fail and actually return an
error code.
This whole clock tree is quite complex already, so having clock
initialisations fail without any error message is not really helping.
Doing: "if (ret) {pr_warn(...); return ERR_PTR(ret);}" should be doable,
I think. Or we do it in the upper layers, when we have the error reason.

Otherwise I like the approach!

Cheers,
Andre.

>>         }
>> +
>> +       return clk;
>>  }
>>
>>
>> @@ -722,7 +724,6 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
>>  }
>>
>>
>> -
>>  /**
>>   * sunxi_gates_clk_setup() - Setup function for leaf gates on clocks
>>   */
>> @@ -808,8 +809,8 @@ static const struct divs_data sun6i_a31_pll6_divs_data __initconst = {
>>   *           |________________________|
>>   */
>>
>> -static void __init sunxi_divs_clk_setup(struct device_node *node,
>> -                                       struct divs_data *data)
>> +static struct clk ** __init sunxi_divs_clk_setup(struct device_node *node,
>> +                                                struct divs_data *data)
>>  {
>>         struct clk_onecell_data *clk_data;
>>         const char *parent;
>> @@ -836,7 +837,7 @@ static void __init sunxi_divs_clk_setup(struct device_node *node,
>>
>>         clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
>>         if (!clk_data)
>> -               return;
>> +               return NULL;
>>
>>         clks = kcalloc(ndivs, sizeof(*clks), GFP_KERNEL);
>>         if (!clks)
>> @@ -922,7 +923,7 @@ static void __init sunxi_divs_clk_setup(struct device_node *node,
>>
>>         of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
>>
>> -       return;
>> +       return clks;
>>
>>  free_gate:
>>         kfree(gate);
>> @@ -930,6 +931,7 @@ free_clks:
>>         kfree(clks);
>>  free_clkdata:
>>         kfree(clk_data);
>> +       return NULL;
>>  }
>>
>>
>> --
>> 2.6.4
>>
> 


From vladimir.murzin at arm.com  Tue Feb  2 03:39:49 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue,  2 Feb 2016 11:39:49 +0000
Subject: [PATCH v2 00/10] Support for Cortex-M Prototyping System
Message-ID: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>

Hi,

This patch series provide the basic support for running ucLinux on V2M-MPS2
platform.

With these patches applied ucLinux can be run on both HW and FVP models
with Cortex-M3/M4/M7 configurations.

Board description:

http://infocenter.arm.com/help/topic/com.arm.doc.100112_0100_03_en/arm_versatile_express_cortex_m_prototyping_system_(v2m_mps2)_technical_reference_manual_100112_0100_03_en.pdf

Application notes (cover Cortex-M3/M4/M7):

http://infocenter.arm.com/help/topic/com.arm.doc.dai0385a/DAI0385A_cortex_m3_on_v2m_mps2.pdf
http://infocenter.arm.com/help/topic/com.arm.doc.dai0386a/DAI0386A_cortex_m4_on_v2m_mps2.pdf
http://infocenter.arm.com/help/topic/com.arm.doc.dai0399a/DAI0399A_cortex_m7_on_v2m_mps2.pdf
http://infocenter.arm.com/help/topic/com.arm.doc.dai0400a/DAI0400A_cortex_m7_on_v2m_mps2.pdf

Cortex-M System Design Kit (referenced as CMDK from documents above):

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0479c/DDI0479C_cortex_m_system_design_kit_r1p0_trm.pdf

I'd be happy to hear any feedback/comments on this series!

Changelog:
  v1  -> v2:
      - rebased on 4.5-rc2
      - fixes for mps2-timer per Daniel and Rob (added Ack from Daniel)
      - fixes for mps2-uart per Greg and Andy

  RFC -> v1:
      - dropped RFC tag
      - rebased on 4.4-rc3
      - added Acks from Rob
      - updated mps2-timer per Daniel
      - fixed build failures reported by 0-DAY kernel test infrastructure

Thanks!

Vladimir Murzin (10):
  dt-bindings: document the MPS2 timer bindings
  clockevents/drivers: add MPS2 Timer driver
  dt-bindings: document the MPS2 UART bindings
  serial: mps2-uart: add MPS2 UART driver
  serial: mps2-uart: add support for early console
  ARM: mps2: introduce MPS2 platform
  ARM: mps2: add low-level debug support
  ARM: configs: add MPS2 defconfig
  ARM: dts: introduce MPS2 AN385/AN386
  ARM: dts: introduce MPS2 AN399/AN400

 .../devicetree/bindings/serial/arm,mps2-uart.txt   |   22 +
 .../devicetree/bindings/timer/arm,mps2-timer.txt   |   28 +
 arch/arm/Kconfig                                   |    8 +
 arch/arm/Kconfig.debug                             |   12 +-
 arch/arm/Makefile                                  |    1 +
 arch/arm/boot/dts/Makefile                         |    3 +
 arch/arm/boot/dts/mps2-an385.dts                   |   90 +++
 arch/arm/boot/dts/mps2-an399.dts                   |   92 +++
 arch/arm/boot/dts/mps2.dtsi                        |  227 ++++++++
 arch/arm/configs/mps2_defconfig                    |  112 ++++
 arch/arm/include/debug/mps2.S                      |   27 +
 arch/arm/mach-mps2/Makefile                        |    1 +
 arch/arm/mach-mps2/Makefile.boot                   |    3 +
 arch/arm/mach-mps2/dtmachine.c                     |   21 +
 drivers/clocksource/Kconfig                        |    6 +
 drivers/clocksource/Makefile                       |    1 +
 drivers/clocksource/mps2-timer.c                   |  276 +++++++++
 drivers/tty/serial/Kconfig                         |   13 +
 drivers/tty/serial/Makefile                        |    1 +
 drivers/tty/serial/mps2-uart.c                     |  614 ++++++++++++++++++++
 include/uapi/linux/serial_core.h                   |    3 +
 21 files changed, 1560 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/serial/arm,mps2-uart.txt
 create mode 100644 Documentation/devicetree/bindings/timer/arm,mps2-timer.txt
 create mode 100644 arch/arm/boot/dts/mps2-an385.dts
 create mode 100644 arch/arm/boot/dts/mps2-an399.dts
 create mode 100644 arch/arm/boot/dts/mps2.dtsi
 create mode 100644 arch/arm/configs/mps2_defconfig
 create mode 100644 arch/arm/include/debug/mps2.S
 create mode 100644 arch/arm/mach-mps2/Makefile
 create mode 100644 arch/arm/mach-mps2/Makefile.boot
 create mode 100644 arch/arm/mach-mps2/dtmachine.c
 create mode 100644 drivers/clocksource/mps2-timer.c
 create mode 100644 drivers/tty/serial/mps2-uart.c

-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb  2 03:39:50 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue,  2 Feb 2016 11:39:50 +0000
Subject: [PATCH v2 01/10] dt-bindings: document the MPS2 timer bindings
In-Reply-To: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1454413199-26573-2-git-send-email-vladimir.murzin@arm.com>

This adds documentation of device tree bindings for the
timers found on ARM MPS2 platform.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/timer/arm,mps2-timer.txt   |   28 ++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/arm,mps2-timer.txt

diff --git a/Documentation/devicetree/bindings/timer/arm,mps2-timer.txt b/Documentation/devicetree/bindings/timer/arm,mps2-timer.txt
new file mode 100644
index 0000000..48f84d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/arm,mps2-timer.txt
@@ -0,0 +1,28 @@
+ARM MPS2 timer
+
+The MPS2 platform has simple general-purpose 32 bits timers.
+
+Required properties:
+- compatible	: Should be "arm,mps2-timer"
+- reg		: Address and length of the register set
+- interrupts	: Reference to the timer interrupt
+
+Required clocking property, have to be one of:
+- clocks	  : The input clock of the timer
+- clock-frequency : The rate in HZ in input of the ARM MPS2 timer
+
+Examples:
+
+timer1: mps2-timer at 40000000 {
+	compatible = "arm,mps2-timer";
+	reg = <0x40000000 0x1000>;
+	interrupts = <8>;
+	clocks = <&sysclk>;
+};
+
+timer2: mps2-timer at 40001000 {
+	compatible = "arm,mps2-timer";
+	reg = <0x40001000 0x1000>;
+	interrupts = <9>;
+	clock-frequency = <25000000>;
+};
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb  2 03:39:52 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue,  2 Feb 2016 11:39:52 +0000
Subject: [PATCH v2 03/10] dt-bindings: document the MPS2 UART bindings
In-Reply-To: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1454413199-26573-4-git-send-email-vladimir.murzin@arm.com>

This adds documentation of device tree bindings for the
UART found on ARM MPS2 platform

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
Acked-by: Rob Herring <robh at kernel.org
---
 .../devicetree/bindings/serial/arm,mps2-uart.txt   |   22 ++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/arm,mps2-uart.txt

diff --git a/Documentation/devicetree/bindings/serial/arm,mps2-uart.txt b/Documentation/devicetree/bindings/serial/arm,mps2-uart.txt
new file mode 100644
index 0000000..b3f7cb1
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/arm,mps2-uart.txt
@@ -0,0 +1,22 @@
+ARM MPS2 UART
+
+Required properties:
+- compatible	: Should be "arm,mps2-uart"
+- reg		: Address and length of the register set
+- interrupts	: Reference to the UART RX, TX and overrun interrupts
+
+Required clocking property:
+- clocks	  : The input clock of the UART
+
+
+Examples:
+
+uart0: serial at 40004000 {
+	compatible = "arm,mps2-uart";
+	reg = <0x40004000 0x1000>;
+	interrupts = <0 1 12>;
+	clocks = <&sysclk>;
+};
+
+
+
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb  2 03:39:51 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue,  2 Feb 2016 11:39:51 +0000
Subject: [PATCH v2 02/10] clockevents/drivers: add MPS2 Timer driver
In-Reply-To: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1454413199-26573-3-git-send-email-vladimir.murzin@arm.com>

MPS2 platform has simple 32 bits general purpose countdown timers.

The driver uses the first detected timer as a clocksource and the rest
of the timers as a clockevent

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
Acked-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 drivers/clocksource/Kconfig      |    6 +
 drivers/clocksource/Makefile     |    1 +
 drivers/clocksource/mps2-timer.c |  276 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 283 insertions(+)
 create mode 100644 drivers/clocksource/mps2-timer.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 33db740..7ce3892 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -185,6 +185,12 @@ config CLKSRC_STM32
 	depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
 	select CLKSRC_MMIO
 
+config CLKSRC_MPS2
+	bool "Clocksource for MPS2 SoCs" if COMPILE_TEST
+	depends on GENERIC_SCHED_CLOCK
+	select CLKSRC_MMIO
+	select CLKSRC_OF
+
 config ARM_ARCH_TIMER
 	bool
 	select CLKSRC_OF if OF
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index dc2b899..b0a3c96 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_CLKSRC_EFM32)	+= time-efm32.o
 obj-$(CONFIG_CLKSRC_STM32)	+= timer-stm32.o
 obj-$(CONFIG_CLKSRC_EXYNOS_MCT)	+= exynos_mct.o
 obj-$(CONFIG_CLKSRC_LPC32XX)	+= time-lpc32xx.o
+obj-$(CONFIG_CLKSRC_MPS2)	+= mps2-timer.o
 obj-$(CONFIG_CLKSRC_SAMSUNG_PWM)	+= samsung_pwm_timer.o
 obj-$(CONFIG_FSL_FTM_TIMER)	+= fsl_ftm_timer.o
 obj-$(CONFIG_VF_PIT_TIMER)	+= vf_pit_timer.o
diff --git a/drivers/clocksource/mps2-timer.c b/drivers/clocksource/mps2-timer.c
new file mode 100644
index 0000000..0f529e9f
--- /dev/null
+++ b/drivers/clocksource/mps2-timer.c
@@ -0,0 +1,276 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.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.
+ *
+ */
+
+#define pr_fmt(fmt)	KBUILD_MODNAME ": " fmt
+
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/clocksource.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/of_address.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/sched_clock.h>
+#include <linux/slab.h>
+
+#define TIMER_CTRL		0x0
+#define TIMER_CTRL_ENABLE	BIT(0)
+#define TIMER_CTRL_IE		BIT(3)
+
+#define TIMER_VALUE		0x4
+#define TIMER_RELOAD		0x8
+#define TIMER_INT		0xc
+
+struct clockevent_mps2 {
+	void __iomem *reg;
+	u32 clock_count_per_tick;
+	struct clock_event_device clkevt;
+};
+
+static void __iomem *sched_clock_base;
+
+static u64 notrace mps2_sched_read(void)
+{
+        return ~readl_relaxed(sched_clock_base + TIMER_VALUE);
+}
+
+static inline struct clockevent_mps2 *to_mps2_clkevt(struct clock_event_device *c)
+{
+	return container_of(c, struct clockevent_mps2, clkevt);
+}
+
+static void clockevent_mps2_writel(u32 val, struct clock_event_device *c, u32 offset)
+{
+	writel_relaxed(val, to_mps2_clkevt(c)->reg + offset);
+}
+
+static int mps2_timer_shutdown(struct clock_event_device *ce)
+{
+	clockevent_mps2_writel(0, ce, TIMER_RELOAD);
+	clockevent_mps2_writel(0, ce, TIMER_CTRL);
+
+	return 0;
+}
+
+static int mps2_timer_set_next_event(unsigned long next, struct clock_event_device *ce)
+{
+	clockevent_mps2_writel(next, ce, TIMER_VALUE);
+	clockevent_mps2_writel(TIMER_CTRL_IE | TIMER_CTRL_ENABLE, ce, TIMER_CTRL);
+
+	return 0;
+}
+
+static int mps2_timer_set_periodic(struct clock_event_device *ce)
+{
+	u32 clock_count_per_tick = to_mps2_clkevt(ce)->clock_count_per_tick;
+
+	clockevent_mps2_writel(clock_count_per_tick, ce, TIMER_RELOAD);
+	clockevent_mps2_writel(clock_count_per_tick, ce, TIMER_VALUE);
+	clockevent_mps2_writel(TIMER_CTRL_IE | TIMER_CTRL_ENABLE, ce, TIMER_CTRL);
+
+	return 0;
+}
+
+static irqreturn_t mps2_timer_interrupt(int irq, void *dev_id)
+{
+	struct clockevent_mps2 *ce = dev_id;
+	u32 status = readl_relaxed(ce->reg + TIMER_INT);
+
+	if (!status) {
+		pr_warn("spurious interrupt\n");
+		return IRQ_NONE;
+	}
+
+	writel_relaxed(1, ce->reg + TIMER_INT);
+
+	ce->clkevt.event_handler(&ce->clkevt);
+
+	return IRQ_HANDLED;
+}
+
+static int __init mps2_clockevent_init(struct device_node *np)
+{
+	void __iomem *base;
+	struct clk *clk;
+	struct clockevent_mps2 *ce;
+	u32 rate;
+	int irq, ret;
+	const char *name = "mps2-clkevt";
+
+	ret = of_property_read_u32(np, "clock-frequency", &rate);
+	if (ret) {
+		clk = of_clk_get(np, 0);
+		if (IS_ERR(clk)) {
+			ret = PTR_ERR(clk);
+			pr_err("failed to get clock for clockevent: %d\n", ret);
+			goto err_clk_get;
+		}
+
+		ret = clk_prepare_enable(clk);
+		if (ret) {
+			pr_err("failed to enable clock for clockevent: %d\n", ret);
+			clk_put(clk);
+			goto err_clk_enable;
+		}
+
+		rate = clk_get_rate(clk);
+	}
+
+	base = of_iomap(np, 0);
+	if (!base) {
+		ret = -EADDRNOTAVAIL;
+		pr_err("failed to map register for clockevent: %d\n", ret);
+		goto err_iomap;
+	}
+
+	irq = irq_of_parse_and_map(np, 0);
+	if (!irq) {
+		ret = -ENOENT;
+		pr_err("failed to get irq for clockevent: %d\n", ret);
+		goto err_get_irq;
+	}
+
+	ce = kzalloc(sizeof(struct clockevent_mps2), GFP_KERNEL);
+	if (!ce) {
+		ret = -ENOMEM;
+		goto err_ce_alloc;
+	}
+
+	ce->reg = base;
+	ce->clock_count_per_tick = DIV_ROUND_CLOSEST(rate, HZ);
+	ce->clkevt.irq = irq;
+	ce->clkevt.name = name;
+	ce->clkevt.rating = 200;
+	ce->clkevt.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
+	ce->clkevt.cpumask = cpu_possible_mask;
+	ce->clkevt.set_state_shutdown	= mps2_timer_shutdown,
+	ce->clkevt.set_state_periodic	= mps2_timer_set_periodic,
+	ce->clkevt.set_state_oneshot	= mps2_timer_shutdown,
+	ce->clkevt.set_next_event	= mps2_timer_set_next_event;
+
+	/* Ensure timer is disabled */
+	writel_relaxed(0, base + TIMER_CTRL);
+
+	ret = request_irq(irq, mps2_timer_interrupt, IRQF_TIMER, name, ce);
+	if (ret) {
+		pr_err("failed to request irq: %d\n", ret);
+		goto err_ia_alloc;
+	}
+
+	clockevents_config_and_register(&ce->clkevt, rate, 0xf, 0xffffffff);
+
+	return 0;
+
+err_ia_alloc:
+	kfree(ce);
+err_ce_alloc:
+err_get_irq:
+	iounmap(base);
+err_iomap:
+	clk_disable_unprepare(clk);
+err_clk_enable:
+	clk_put(clk);
+err_clk_get:
+	return ret;
+}
+
+static int __init mps2_clocksource_init(struct device_node *np)
+{
+	void __iomem *base;
+	struct clk *clk;
+	u32 rate;
+	int ret;
+	const char *name = "mps2-clksrc";
+
+	ret = of_property_read_u32(np, "clock-frequency", &rate);
+	if (ret) {
+		clk = of_clk_get(np, 0);
+		if (IS_ERR(clk)) {
+			ret = PTR_ERR(clk);
+			pr_err("failed to get clock for clocksource: %d\n", ret);
+			goto err_clk_get;
+		}
+
+		ret = clk_prepare_enable(clk);
+		if (ret) {
+			pr_err("failed to enable clock for clocksource: %d\n", ret);
+			clk_put(clk);
+			goto err_clk_enable;
+		}
+
+		rate = clk_get_rate(clk);
+	}
+
+	base = of_iomap(np, 0);
+	if (!base) {
+		ret = -EADDRNOTAVAIL;
+		pr_err("failed to map register for clocksource: %d\n", ret);
+		goto err_iomap;
+	}
+
+	/* Ensure timer is disabled */
+	writel_relaxed(0, base + TIMER_CTRL);
+
+	/* ... and set it up as free-running clocksource */
+	writel_relaxed(0xffffffff, base + TIMER_VALUE);
+	writel_relaxed(0xffffffff, base + TIMER_RELOAD);
+
+	writel_relaxed(TIMER_CTRL_ENABLE, base + TIMER_CTRL);
+
+	ret = clocksource_mmio_init(base + TIMER_VALUE, name,
+				    rate, 200, 32,
+				    clocksource_mmio_readl_down);
+	if (ret) {
+		pr_err("failed to init clocksource: %d\n", ret);
+		goto err_clocksource_init;
+	}
+
+	sched_clock_base = base;
+	sched_clock_register(mps2_sched_read, 32, rate);
+
+	return 0;
+
+err_clocksource_init:
+	iounmap(base);
+err_iomap:
+	clk_disable_unprepare(clk);
+err_clk_enable:
+	clk_put(clk);
+err_clk_get:
+	return ret;
+}
+
+static void __init mps2_timer_init(struct device_node *np)
+{
+	static int has_clocksource, has_clockevent;
+	int ret;
+
+	if (!has_clocksource) {
+		ret = mps2_clocksource_init(np);
+		if (!ret) {
+			has_clocksource = 1;
+			return;
+		}
+	}
+
+	if (!has_clockevent) {
+		ret = mps2_clockevent_init(np);
+		if (!ret) {
+			has_clockevent = 1;
+			return;
+		}
+	}
+}
+
+CLOCKSOURCE_OF_DECLARE(mps2_timer, "arm,mps2-timer", mps2_timer_init);
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb  2 03:39:53 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue,  2 Feb 2016 11:39:53 +0000
Subject: [PATCH v2 04/10] serial: mps2-uart: add MPS2 UART driver
In-Reply-To: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1454413199-26573-5-git-send-email-vladimir.murzin@arm.com>

This driver adds support to the UART controller found on ARM MPS2
platform.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 drivers/tty/serial/Kconfig       |   12 +
 drivers/tty/serial/Makefile      |    1 +
 drivers/tty/serial/mps2-uart.c   |  584 ++++++++++++++++++++++++++++++++++++++
 include/uapi/linux/serial_core.h |    3 +
 4 files changed, 600 insertions(+)
 create mode 100644 drivers/tty/serial/mps2-uart.c

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 39721ec..3a248be 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1450,6 +1450,18 @@ config SERIAL_EFM32_UART
 	  This driver support the USART and UART ports on
 	  Energy Micro's efm32 SoCs.
 
+config SERIAL_MPS2_UART_CONSOLE
+	bool "MPS2 UART console support"
+	depends on SERIAL_MPS2_UART
+	select SERIAL_CORE_CONSOLE
+
+config SERIAL_MPS2_UART
+	bool "MPS2 UART port"
+	depends on ARM || COMPILE_TEST
+	select SERIAL_CORE
+	help
+	  This driver support the UART ports on ARM MPS2.
+
 config SERIAL_EFM32_UART_CONSOLE
 	bool "EFM32 UART/USART console support"
 	depends on SERIAL_EFM32_UART=y
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index b391c9b..1062503 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
 obj-$(CONFIG_SERIAL_MEN_Z135)	+= men_z135_uart.o
 obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
 obj-$(CONFIG_SERIAL_STM32)	+= stm32-usart.o
+obj-$(CONFIG_SERIAL_MPS2_UART)	+= mps2-uart.o
 
 # GPIOLIB helpers for modem control lines
 obj-$(CONFIG_SERIAL_MCTRL_GPIO)	+= serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
new file mode 100644
index 0000000..4d113ec
--- /dev/null
+++ b/drivers/tty/serial/mps2-uart.c
@@ -0,0 +1,584 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.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.
+ *
+ * TODO: support for SysRq
+ */
+
+#define pr_fmt(fmt)	KBUILD_MODNAME ": " fmt
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/console.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/serial_core.h>
+#include <linux/tty_flip.h>
+#include <linux/types.h>
+
+#define SERIAL_NAME "ttyS"
+#define DRIVER_NAME "mps2-uart"
+#define MAKE_NAME(x) (DRIVER_NAME # x)
+
+#define UARTn_DATA				0x00
+
+#define UARTn_STATE				0x04
+#define UARTn_STATE_TX_FULL			BIT(0)
+#define UARTn_STATE_RX_FULL			BIT(1)
+#define UARTn_STATE_TX_OVERRUN			BIT(2)
+#define UARTn_STATE_RX_OVERRUN			BIT(3)
+
+#define UARTn_CTRL				0x08
+#define UARTn_CTRL_TX_ENABLE			BIT(0)
+#define UARTn_CTRL_RX_ENABLE			BIT(1)
+#define UARTn_CTRL_TX_INT_ENABLE		BIT(2)
+#define UARTn_CTRL_RX_INT_ENABLE		BIT(3)
+#define UARTn_CTRL_TX_OVERRUN_INT_ENABLE	BIT(4)
+#define UARTn_CTRL_RX_OVERRUN_INT_ENABLE	BIT(5)
+
+#define UARTn_INT				0x0c
+#define UARTn_INT_TX				BIT(0)
+#define UARTn_INT_RX				BIT(1)
+#define UARTn_INT_TX_OVERRUN			BIT(2)
+#define UARTn_INT_RX_OVERRUN			BIT(3)
+
+#define UARTn_BAUDDIV				0x10
+#define UARTn_BAUDDIV_MASK			GENMASK(20, 0)
+
+/*
+ * Helpers to make typical enable/disable operations more readable.
+ */
+#define UARTn_CTRL_TX_GRP 			(UARTn_CTRL_TX_ENABLE		 |\
+						 UARTn_CTRL_TX_INT_ENABLE	 |\
+						 UARTn_CTRL_TX_OVERRUN_INT_ENABLE)
+
+#define UARTn_CTRL_RX_GRP 			(UARTn_CTRL_RX_ENABLE		 |\
+						 UARTn_CTRL_RX_INT_ENABLE	 |\
+						 UARTn_CTRL_RX_OVERRUN_INT_ENABLE)
+
+#define MPS2_MAX_PORTS				3
+
+struct mps2_uart_port {
+	struct uart_port port;
+	struct clk *clk;
+	unsigned int tx_irq;
+	unsigned int rx_irq;
+};
+
+static inline struct mps2_uart_port *to_mps2_port(struct uart_port *port)
+{
+	return container_of(port, struct mps2_uart_port, port);
+}
+
+static void mps2_uart_write8(struct uart_port *port, u8 val, unsigned off)
+{
+	struct mps2_uart_port *mps_port = to_mps2_port(port);
+
+	writeb(val, mps_port->port.membase + off);
+}
+
+static u8 mps2_uart_read8(struct uart_port *port, unsigned off)
+{
+	struct mps2_uart_port *mps_port = to_mps2_port(port);
+
+	return readb(mps_port->port.membase + off);
+}
+
+static void mps2_uart_write32(struct uart_port *port, u32 val, unsigned off)
+{
+	struct mps2_uart_port *mps_port = to_mps2_port(port);
+
+	writel_relaxed(val, mps_port->port.membase + off);
+}
+
+static unsigned int mps2_uart_tx_empty(struct uart_port *port)
+{
+	u8 status = mps2_uart_read8(port, UARTn_STATE);
+
+	return (status & UARTn_STATE_TX_FULL) ? 0 : TIOCSER_TEMT;
+}
+
+static void mps2_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+}
+
+static unsigned int mps2_uart_get_mctrl(struct uart_port *port)
+{
+	return TIOCM_CAR | TIOCM_CTS | TIOCM_DSR;
+}
+
+static void mps2_uart_stop_tx(struct uart_port *port)
+{
+	u8 control = mps2_uart_read8(port, UARTn_CTRL);
+
+	control &= ~UARTn_CTRL_TX_GRP;
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+}
+
+static void mps2_uart_tx_chars(struct uart_port *port)
+{
+	struct circ_buf *xmit = &port->state->xmit;
+
+	while (!(mps2_uart_read8(port, UARTn_STATE) & UARTn_STATE_TX_FULL)) {
+		if (port->x_char) {
+			mps2_uart_write8(port, port->x_char, UARTn_DATA);
+			port->x_char = 0;
+			port->icount.tx++;
+			continue;
+		}
+
+		if (uart_circ_empty(xmit) || uart_tx_stopped(port))
+			break;
+
+		mps2_uart_write8(port, xmit->buf[xmit->tail], UARTn_DATA);
+		xmit->tail = (xmit->tail + 1) % UART_XMIT_SIZE;
+		port->icount.tx++;
+	}
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+
+	if (uart_circ_empty(xmit))
+		mps2_uart_stop_tx(port);
+}
+
+static void mps2_uart_start_tx(struct uart_port *port)
+{
+	u8 control = mps2_uart_read8(port, UARTn_CTRL);
+
+	control |= UARTn_CTRL_TX_GRP;
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+	mps2_uart_tx_chars(port);
+}
+
+static void mps2_uart_stop_rx(struct uart_port *port)
+{
+	u8 control = mps2_uart_read8(port, UARTn_CTRL);
+
+	control &= ~UARTn_CTRL_RX_GRP;
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+}
+
+static void mps2_uart_break_ctl(struct uart_port *port, int ctl)
+{
+}
+
+static void mps2_uart_rx_chars(struct uart_port *port)
+{
+	struct tty_port *tport = &port->state->port;
+
+	while (mps2_uart_read8(port, UARTn_STATE) & UARTn_STATE_RX_FULL) {
+		u8 rxdata = mps2_uart_read8(port, UARTn_DATA);
+
+		port->icount.rx++;
+		tty_insert_flip_char(&port->state->port, rxdata, TTY_NORMAL);
+	}
+
+	spin_unlock(&port->lock);
+	tty_flip_buffer_push(tport);
+	spin_lock(&port->lock);
+}
+
+static irqreturn_t mps2_uart_rxirq(int irq, void *data)
+{
+
+	struct uart_port *port = data;
+	u8 irqflag = mps2_uart_read8(port, UARTn_INT);
+
+	if (unlikely(!(irqflag & UARTn_INT_RX)))
+		return IRQ_NONE;
+
+	spin_lock(&port->lock);
+
+	mps2_uart_write8(port, UARTn_INT_RX, UARTn_INT);
+	mps2_uart_rx_chars(port);
+
+	spin_unlock(&port->lock);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t mps2_uart_txirq(int irq, void *data)
+{
+	struct uart_port *port = data;
+	u8 irqflag = mps2_uart_read8(port, UARTn_INT);
+
+	if (unlikely(!(irqflag & UARTn_INT_TX)))
+		return IRQ_NONE;
+
+	mps2_uart_write8(port, UARTn_INT_TX, UARTn_INT);
+	mps2_uart_tx_chars(port);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t mps2_uart_oerrirq(int irq, void *data)
+{
+	irqreturn_t handled = IRQ_NONE;
+	struct uart_port *port = data;
+	u8 irqflag = mps2_uart_read8(port, UARTn_INT);
+
+	spin_lock(&port->lock);
+
+	if (irqflag & UARTn_INT_RX_OVERRUN) {
+		struct tty_port *tport = &port->state->port;
+
+		mps2_uart_write8(port, UARTn_INT_RX_OVERRUN, UARTn_INT);
+		tty_insert_flip_char(tport, 0, TTY_OVERRUN);
+		port->icount.overrun++;
+		handled = IRQ_HANDLED;
+	}
+
+	/*
+	 * It's never been seen in practice and it never *should* happen since
+	 * we check if there is enough room in TX buffer before sending data.
+	 * So we keep this check in case something suspicious has happened.
+	 */
+	if (irqflag & UARTn_INT_TX_OVERRUN) {
+		mps2_uart_write8(port, UARTn_INT_TX_OVERRUN, UARTn_INT);
+		dev_warn(port->dev, "unexpected overrun interrupt\n");
+		handled = IRQ_HANDLED;
+	}
+
+	spin_unlock(&port->lock);
+
+	return handled;
+}
+
+static int mps2_uart_startup(struct uart_port *port)
+{
+	struct mps2_uart_port *mps_port = to_mps2_port(port);
+	u8 control = mps2_uart_read8(port, UARTn_CTRL);
+	int ret;
+
+	control &= ~(UARTn_CTRL_RX_GRP | UARTn_CTRL_TX_GRP);
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+
+	ret = request_irq(mps_port->rx_irq, mps2_uart_rxirq, 0,
+			  MAKE_NAME(-rx), mps_port);
+	if (ret) {
+		dev_err(port->dev, "failed to register rxirq (%d)\n", ret);
+		goto err_no_rxirq;
+	}
+
+	ret = request_irq(mps_port->tx_irq, mps2_uart_txirq, 0,
+			  MAKE_NAME(-tx), mps_port);
+	if (ret) {
+		dev_err(port->dev, "failed to register txirq (%d)\n", ret);
+		goto err_no_txirq;
+	}
+
+	ret = request_irq(port->irq, mps2_uart_oerrirq, IRQF_SHARED,
+			  MAKE_NAME(-overrun), mps_port);
+
+	if (ret) {
+		dev_err(port->dev, "failed to register oerrirq (%d)\n", ret);
+	} else {
+		control |= UARTn_CTRL_RX_GRP | UARTn_CTRL_TX_GRP;
+
+		mps2_uart_write8(port, control, UARTn_CTRL);
+
+		return 0;
+	}
+
+	free_irq(mps_port->tx_irq, mps_port);
+err_no_txirq:
+	free_irq(mps_port->rx_irq, mps_port);
+err_no_rxirq:
+	return ret;
+}
+
+static void mps2_uart_shutdown(struct uart_port *port)
+{
+	struct mps2_uart_port *mps_port = to_mps2_port(port);
+	u8 control = mps2_uart_read8(port, UARTn_CTRL);
+
+	control &= ~(UARTn_CTRL_RX_GRP| UARTn_CTRL_TX_GRP);
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+
+	free_irq(mps_port->rx_irq, mps_port);
+	free_irq(mps_port->tx_irq, mps_port);
+	free_irq(port->irq, mps_port);
+}
+
+static void mps2_uart_set_termios(struct uart_port *port,
+	struct ktermios *new, struct ktermios *old)
+{
+	unsigned long flags;
+	unsigned int baud, bauddiv;
+
+	new->c_cflag &= ~(CRTSCTS | CMSPAR);
+	new->c_cflag &= ~CSIZE;
+	new->c_cflag |= CS8;
+	new->c_cflag &= ~PARENB;
+	new->c_cflag &= ~CSTOPB;
+
+	baud = uart_get_baud_rate(port, new, old,
+			DIV_ROUND_CLOSEST(port->uartclk, UARTn_BAUDDIV_MASK),
+			DIV_ROUND_CLOSEST(port->uartclk, 16));
+
+	bauddiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	uart_update_timeout(port, new->c_cflag, baud);
+	mps2_uart_write32(port, bauddiv, UARTn_BAUDDIV);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *mps2_uart_type(struct uart_port *port)
+{
+	return (port->type == PORT_MPS2UART) ? DRIVER_NAME : NULL;
+}
+
+static void mps2_uart_release_port(struct uart_port *port)
+{
+}
+
+static int mps2_uart_request_port(struct uart_port *port)
+{
+	return 0;
+}
+
+static void mps2_uart_config_port(struct uart_port *port, int type)
+{
+	if (type & UART_CONFIG_TYPE && !mps2_uart_request_port(port))
+		port->type = PORT_MPS2UART;
+}
+
+static int mps2_uart_verify_port(struct uart_port *port, struct serial_struct *serinfo)
+{
+	return -EINVAL;
+}
+
+static const struct uart_ops mps2_uart_pops = {
+	.tx_empty = mps2_uart_tx_empty,
+	.set_mctrl = mps2_uart_set_mctrl,
+	.get_mctrl = mps2_uart_get_mctrl,
+	.stop_tx = mps2_uart_stop_tx,
+	.start_tx = mps2_uart_start_tx,
+	.stop_rx = mps2_uart_stop_rx,
+	.break_ctl = mps2_uart_break_ctl,
+	.startup = mps2_uart_startup,
+	.shutdown = mps2_uart_shutdown,
+	.set_termios = mps2_uart_set_termios,
+	.type = mps2_uart_type,
+	.release_port = mps2_uart_release_port,
+	.request_port = mps2_uart_request_port,
+	.config_port = mps2_uart_config_port,
+	.verify_port = mps2_uart_verify_port,
+};
+
+static struct mps2_uart_port mps2_uart_ports[MPS2_MAX_PORTS];
+
+#ifdef CONFIG_SERIAL_MPS2_UART_CONSOLE
+static void mps2_uart_console_putchar(struct uart_port *port, int ch)
+{
+	while (mps2_uart_read8(port, UARTn_STATE) & UARTn_STATE_TX_FULL)
+		cpu_relax();
+
+	mps2_uart_write8(port, ch, UARTn_DATA);
+}
+
+static void mps2_uart_console_write(struct console *co, const char *s, unsigned int cnt)
+{
+	struct uart_port *port = &mps2_uart_ports[co->index].port;
+
+	uart_console_write(port, s, cnt, mps2_uart_console_putchar);
+}
+
+static int mps2_uart_console_setup(struct console *co, char *options)
+{
+	struct mps2_uart_port *mps_port;
+	int baud = 9600;
+	int bits = 8;
+	int parity = 'n';
+	int flow = 'n';
+
+	if (co->index < 0 || co->index >= MPS2_MAX_PORTS)
+		return -ENODEV;
+
+	mps_port = &mps2_uart_ports[co->index];
+
+	if (options)
+		uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+	return uart_set_options(&mps_port->port, co, baud, parity, bits, flow);
+}
+
+static struct uart_driver mps2_uart_driver;
+
+static struct console mps2_uart_console = {
+	.name = SERIAL_NAME,
+	.device = uart_console_device,
+	.write = mps2_uart_console_write,
+	.setup = mps2_uart_console_setup,
+	.flags = CON_PRINTBUFFER,
+	.index = -1,
+	.data = &mps2_uart_driver,
+};
+
+#define MPS2_SERIAL_CONSOLE (&mps2_uart_console)
+
+#else
+#define MPS2_SERIAL_CONSOLE NULL
+#endif
+
+static struct uart_driver mps2_uart_driver = {
+	.driver_name = DRIVER_NAME,
+	.dev_name = SERIAL_NAME,
+	.nr = MPS2_MAX_PORTS,
+	.cons = MPS2_SERIAL_CONSOLE,
+};
+
+static struct mps2_uart_port *mps2_of_get_port(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int id;
+
+	if (!np)
+		return NULL;
+
+	id = of_alias_get_id(np, "serial");
+	if (id < 0)
+		id = 0;
+
+	if (WARN_ON(id >= MPS2_MAX_PORTS))
+		return NULL;
+
+	mps2_uart_ports[id].port.line = id;
+	return &mps2_uart_ports[id];
+}
+
+static int mps2_init_port(struct mps2_uart_port *mps_port,
+			struct platform_device *pdev)
+{
+	int ret;
+	struct resource *res;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mps_port->port.membase = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(mps_port->port.membase))
+		return PTR_ERR(mps_port->port.membase);
+
+	mps_port->port.mapbase = res->start;
+	mps_port->port.mapsize = resource_size(res);
+
+	mps_port->rx_irq = platform_get_irq(pdev, 0);
+	mps_port->tx_irq = platform_get_irq(pdev, 1);
+	mps_port->port.irq = platform_get_irq(pdev, 2);
+
+	mps_port->port.iotype = UPIO_MEM;
+	mps_port->port.flags = UPF_BOOT_AUTOCONF;
+	mps_port->port.fifosize = 1;
+	mps_port->port.ops = &mps2_uart_pops;
+	mps_port->port.dev = &pdev->dev;
+
+	mps_port->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(mps_port->clk))
+		return PTR_ERR(mps_port->clk);
+
+	ret = clk_prepare_enable(mps_port->clk);
+	if (ret)
+		return ret;
+
+	mps_port->port.uartclk = clk_get_rate(mps_port->clk);
+
+	clk_disable_unprepare(mps_port->clk);
+
+	return ret;
+}
+
+static int mps2_serial_probe(struct platform_device *pdev)
+{
+	struct mps2_uart_port *mps_port;
+	int ret;
+
+	mps_port = mps2_of_get_port(pdev);
+	if (!mps_port)
+		return -ENODEV;
+
+	ret = mps2_init_port(mps_port, pdev);
+	if (ret)
+		return ret;
+
+	ret = uart_add_one_port(&mps2_uart_driver, &mps_port->port);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, mps_port);
+
+	return 0;
+}
+
+static int mps2_serial_remove(struct platform_device *pdev)
+{
+	struct mps2_uart_port *mps_port = platform_get_drvdata(pdev);
+
+	uart_remove_one_port(&mps2_uart_driver, &mps_port->port);
+
+	return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id mps2_match[] = {
+	{ .compatible = "arm,mps2-uart", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mps2_match);
+#endif
+
+static struct platform_driver mps2_serial_driver = {
+	.probe = mps2_serial_probe,
+	.remove = mps2_serial_remove,
+
+	.driver = {
+		.name = DRIVER_NAME,
+		.of_match_table = of_match_ptr(mps2_match),
+	},
+};
+
+static int __init mps2_uart_init(void)
+{
+	int ret;
+
+	ret = uart_register_driver(&mps2_uart_driver);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&mps2_serial_driver);
+	if (ret)
+		uart_unregister_driver(&mps2_uart_driver);
+
+	pr_info("MPS2 UART driver initialized\n");
+
+	return ret;
+}
+module_init(mps2_uart_init);
+
+static void __exit mps2_uart_exit(void)
+{
+	platform_driver_unregister(&mps2_serial_driver);
+	uart_unregister_driver(&mps2_uart_driver);
+}
+module_exit(mps2_uart_exit);
+
+MODULE_AUTHOR("Vladimir Murzin <vladimir.murzin at arm.com>");
+MODULE_DESCRIPTION("MPS2 UART driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:" DRIVER_NAME);
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 3e5d757..1fa57bb 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -261,4 +261,7 @@
 /* STM32 USART */
 #define PORT_STM32	113
 
+/* MPS2 UART */
+#define PORT_MPS2UART	114
+
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb  2 03:39:57 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue,  2 Feb 2016 11:39:57 +0000
Subject: [PATCH v2 08/10] ARM: configs: add MPS2 defconfig
In-Reply-To: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1454413199-26573-9-git-send-email-vladimir.murzin@arm.com>

This patch adds a new config for MPS2 platform.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 arch/arm/configs/mps2_defconfig |  112 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 112 insertions(+)
 create mode 100644 arch/arm/configs/mps2_defconfig

diff --git a/arch/arm/configs/mps2_defconfig b/arch/arm/configs/mps2_defconfig
new file mode 100644
index 0000000..c36c519
--- /dev/null
+++ b/arch/arm/configs/mps2_defconfig
@@ -0,0 +1,112 @@
+# CONFIG_USELIB is not set
+CONFIG_NO_HZ_IDLE=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_LOG_BUF_SHIFT=16
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+# CONFIG_UID16 is not set
+# CONFIG_BASE_FULL is not set
+# CONFIG_FUTEX is not set
+# CONFIG_EPOLL is not set
+# CONFIG_SIGNALFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+CONFIG_EMBEDDED=y
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_BLOCK is not set
+# CONFIG_MMU is not set
+CONFIG_ARM_SINGLE_ARMV7M=y
+CONFIG_ARCH_MPS2=y
+CONFIG_SET_MEM_PARAM=y
+CONFIG_DRAM_BASE=0x21000000
+CONFIG_DRAM_SIZE=0x1000000
+CONFIG_PREEMPT_VOLUNTARY=y
+# CONFIG_ATAGS is not set
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_BINFMT_FLAT=y
+CONFIG_BINFMT_SHARED_FLAT=y
+# CONFIG_COREDUMP is not set
+# CONFIG_SUSPEND is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_WIRELESS is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_FW_LOADER is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NET_CORE is not set
+# 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_EZCHIP is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_HISILICON 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_NET_VENDOR_QUALCOMM is not set
+# CONFIG_NET_VENDOR_RENESAS is not set
+# CONFIG_NET_VENDOR_ROCKER is not set
+# CONFIG_NET_VENDOR_SAMSUNG is not set
+# 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_WLAN is not set
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_NONSTANDARD=y
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_MPS2_UART_CONSOLE=y
+CONFIG_SERIAL_MPS2_UART=y
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HWMON is not set
+CONFIG_WATCHDOG=y
+CONFIG_ARM_SP805_WATCHDOG=y
+CONFIG_MFD_SYSCON=y
+# CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_SYSCON=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_ONESHOT=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_BACKLIGHT=y
+CONFIG_LEDS_TRIGGER_CPU=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_ARM_TIMER_SP804=y
+# CONFIG_DNOTIFY is not set
+# CONFIG_INOTIFY_USER is not set
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_NFS_FS=y
+CONFIG_NFS_V4=y
+CONFIG_NFS_V4_1=y
+CONFIG_NFS_V4_2=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_INFO=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+CONFIG_DEBUG_FS=y
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+CONFIG_MEMTEST=y
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb  2 03:39:54 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue,  2 Feb 2016 11:39:54 +0000
Subject: [PATCH v2 05/10] serial: mps2-uart: add support for early console
In-Reply-To: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1454413199-26573-6-git-send-email-vladimir.murzin@arm.com>

This adds support early console for MPS2 UART which can be enabled via
earlycon=mps2,0x40004000

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 drivers/tty/serial/Kconfig     |    1 +
 drivers/tty/serial/mps2-uart.c |   30 ++++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 3a248be..4ed6e51 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1454,6 +1454,7 @@ config SERIAL_MPS2_UART_CONSOLE
 	bool "MPS2 UART console support"
 	depends on SERIAL_MPS2_UART
 	select SERIAL_CORE_CONSOLE
+	select SERIAL_EARLYCON
 
 config SERIAL_MPS2_UART
 	bool "MPS2 UART port"
diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
index 4d113ec..530dcab 100644
--- a/drivers/tty/serial/mps2-uart.c
+++ b/drivers/tty/serial/mps2-uart.c
@@ -435,6 +435,36 @@ static struct console mps2_uart_console = {
 
 #define MPS2_SERIAL_CONSOLE (&mps2_uart_console)
 
+static void mps2_early_putchar(struct uart_port *port, int ch)
+{
+
+	while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
+		cpu_relax();
+
+	writeb((unsigned char)ch, port->membase + UARTn_DATA);
+}
+
+
+static void mps2_early_write(struct console *con, const char *s, unsigned n)
+{
+	struct earlycon_device *dev = con->data;
+
+	uart_console_write(&dev->port, s, n, mps2_early_putchar);
+}
+
+static int __init mps2_early_console_setup(struct earlycon_device *device,
+					   const char *opt)
+{
+	if (!device->port.membase)
+		return -ENODEV;
+
+	device->con->write = mps2_early_write;
+
+	return 0;
+}
+EARLYCON_DECLARE(mps2, mps2_early_console_setup);
+OF_EARLYCON_DECLARE(mps2, "arm,mps2-uart", mps2_early_console_setup);
+
 #else
 #define MPS2_SERIAL_CONSOLE NULL
 #endif
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb  2 03:39:55 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue,  2 Feb 2016 11:39:55 +0000
Subject: [PATCH v2 06/10] ARM: mps2: introduce MPS2 platform
In-Reply-To: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1454413199-26573-7-git-send-email-vladimir.murzin@arm.com>

The Cortex-M Prototyping System (or V2M-MPS2) is designed for
prototyping and evaluation Cortex-M family of processors including the
latest Cortex-M7

It comes with a range of useful peripherals including 8MB single cycle
SRAM, 16MB PSRAM, Ethernet, QSVGA touch screen panel, 4bit RGB VGA
connector, Audio, SPI and GPIO.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 arch/arm/Kconfig                 |    8 ++++++++
 arch/arm/Makefile                |    1 +
 arch/arm/mach-mps2/Makefile      |    1 +
 arch/arm/mach-mps2/Makefile.boot |    3 +++
 arch/arm/mach-mps2/dtmachine.c   |   21 +++++++++++++++++++++
 5 files changed, 34 insertions(+)
 create mode 100644 arch/arm/mach-mps2/Makefile
 create mode 100644 arch/arm/mach-mps2/Makefile.boot
 create mode 100644 arch/arm/mach-mps2/dtmachine.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4f799e5..48fa6c4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -883,6 +883,14 @@ config ARCH_STM32
 	help
 	  Support for STMicroelectronics STM32 processors.
 
+config ARCH_MPS2
+	bool "ARM MPS2 paltform"
+	depends on ARM_SINGLE_ARMV7M
+	select ARM_AMBA
+	select CLKSRC_MPS2
+	help
+	  Support for ARM MPS2 Cortex-M platform.
+
 # Definitions to make life easier
 config ARCH_ACORN
 	bool
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index fe25410..8cd9ec1 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -182,6 +182,7 @@ machine-$(CONFIG_ARCH_LPC18XX)		+= lpc18xx
 machine-$(CONFIG_ARCH_LPC32XX)		+= lpc32xx
 machine-$(CONFIG_ARCH_MESON)		+= meson
 machine-$(CONFIG_ARCH_MMP)		+= mmp
+machine-$(CONFIG_ARCH_MPS2)		+= mps2
 machine-$(CONFIG_ARCH_MOXART)		+= moxart
 machine-$(CONFIG_ARCH_MV78XX0)		+= mv78xx0
 machine-$(CONFIG_ARCH_MVEBU)		+= mvebu
diff --git a/arch/arm/mach-mps2/Makefile b/arch/arm/mach-mps2/Makefile
new file mode 100644
index 0000000..3a74af7
--- /dev/null
+++ b/arch/arm/mach-mps2/Makefile
@@ -0,0 +1 @@
+obj-y += dtmachine.o
diff --git a/arch/arm/mach-mps2/Makefile.boot b/arch/arm/mach-mps2/Makefile.boot
new file mode 100644
index 0000000..eacfc3f
--- /dev/null
+++ b/arch/arm/mach-mps2/Makefile.boot
@@ -0,0 +1,3 @@
+# Empty file waiting for deletion once Makefile.boot isn't needed any more.
+# Patch waits for application at
+# http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7889/1 .
diff --git a/arch/arm/mach-mps2/dtmachine.c b/arch/arm/mach-mps2/dtmachine.c
new file mode 100644
index 0000000..e7ad9c2
--- /dev/null
+++ b/arch/arm/mach-mps2/dtmachine.c
@@ -0,0 +1,21 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.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.
+ *
+ */
+
+#include <asm/mach/arch.h>
+
+static const char *const mps2_compat[] __initconst = {
+	"arm,mps2",
+	NULL
+};
+
+DT_MACHINE_START(MPS2DT, "MPS2 (Device Tree Support)")
+	.dt_compat = mps2_compat,
+MACHINE_END
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb  2 03:39:56 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue,  2 Feb 2016 11:39:56 +0000
Subject: [PATCH v2 07/10] ARM: mps2: add low-level debug support
In-Reply-To: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1454413199-26573-8-git-send-email-vladimir.murzin@arm.com>

Add low-level debug support for MPS2, so that earlyprintk can be enabled
for debugging early boot issues.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 arch/arm/Kconfig.debug        |   12 +++++++++++-
 arch/arm/include/debug/mps2.S |   27 +++++++++++++++++++++++++++
 2 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/debug/mps2.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index c6b6175..fcd2e15 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -485,6 +485,13 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on MMP UART3.
 
+	config DEBUG_MPS2_UART
+		bool "Kernel low-level debugging message via MPS2 UART0"
+		depends on ARCH_MPS2
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on MPS2 based platforms.
+
 	config DEBUG_MVEBU_UART0
 		bool "Kernel low-level debugging messages via MVEBU UART0 (old bootloaders)"
 		depends on ARCH_MVEBU
@@ -1415,6 +1422,7 @@ config DEBUG_LL_INCLUDE
 	default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1
 	default "debug/bcm63xx.S" if DEBUG_BCM63XX_UART
 	default "debug/digicolor.S" if DEBUG_DIGICOLOR_UA0
+	default "debug/mps2.S" if DEBUG_MPS2_UART
 	default "mach/debug-macro.S"
 
 # Compatibility options for PL01x
@@ -1463,6 +1471,7 @@ config DEBUG_UART_PHYS
 	default 0x20201000 if DEBUG_BCM2835
 	default 0x3f201000 if DEBUG_BCM2836
 	default 0x3e000000 if DEBUG_BCM_KONA_UART
+	default 0x40004000 if DEBUG_MPS2_UART
 	default 0x4000e400 if DEBUG_LL_UART_EFM32
 	default 0x40081000 if DEBUG_LPC18XX_UART0
 	default 0x40090000 if DEBUG_LPC32XX
@@ -1539,7 +1548,8 @@ config DEBUG_UART_PHYS
 		DEBUG_S3C64XX_UART || \
 		DEBUG_BCM63XX_UART || DEBUG_ASM9260_UART || \
 		DEBUG_SIRFSOC_UART || DEBUG_DIGICOLOR_UA0 || \
-		DEBUG_AT91_UART
+		DEBUG_AT91_UART || \
+		DEBUG_MPS2_UART
 
 config DEBUG_UART_VIRT
 	hex "Virtual base address of debug UART"
diff --git a/arch/arm/include/debug/mps2.S b/arch/arm/include/debug/mps2.S
new file mode 100644
index 0000000..0ced0ce
--- /dev/null
+++ b/arch/arm/include/debug/mps2.S
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.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.
+ *
+ */
+
+	.macro	addruart, rp, tmp1, tmp2
+	ldr	\rp, =CONFIG_DEBUG_UART_PHYS
+	.endm
+
+	.macro	senduart, rd, rx
+	strb	\rd, [\rx]		@ Data Register
+	.endm
+
+	.macro	busyuart, rd, rx
+1001:	ldrb	\rd, [\rx, #0x4]	@ State Register
+	tst	\rd, #1			@ busy
+	bne	1001b			@ wait until transmit done
+	.endm
+
+	.macro	waituart,rd,rx
+	.endm
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb  2 03:39:58 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue,  2 Feb 2016 11:39:58 +0000
Subject: [PATCH v2 09/10] ARM: dts: introduce MPS2 AN385/AN386
In-Reply-To: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1454413199-26573-10-git-send-email-vladimir.murzin@arm.com>

Application Notes 385 and 386 shares the same memory map and features
except the CPU is used. AN385 is supplied with Cortex-M3 CPU and AN386
is supplied with Cortex-M4.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 arch/arm/boot/dts/Makefile       |    1 +
 arch/arm/boot/dts/mps2-an385.dts |   90 +++++++++++++++
 arch/arm/boot/dts/mps2.dtsi      |  227 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 318 insertions(+)
 create mode 100644 arch/arm/boot/dts/mps2-an385.dts
 create mode 100644 arch/arm/boot/dts/mps2.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..96418d2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -245,6 +245,7 @@ dtb-$(CONFIG_ARCH_MMP) += \
 dtb-$(CONFIG_MACH_MESON8B) += \
 	meson8b-mxq.dtb \
 	meson8b-odroidc1.dtb
+dtb-$(CONFIG_ARCH_MPS2) += mps2-an385.dtb
 dtb-$(CONFIG_ARCH_MOXART) += \
 	moxart-uc7112lx.dtb
 dtb-$(CONFIG_SOC_IMX1) += \
diff --git a/arch/arm/boot/dts/mps2-an385.dts b/arch/arm/boot/dts/mps2-an385.dts
new file mode 100644
index 0000000..ddb03d3
--- /dev/null
+++ b/arch/arm/boot/dts/mps2-an385.dts
@@ -0,0 +1,90 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "mps2.dtsi"
+
+/ {
+	model = "ARM MPS2 Application Note 385/386";
+	compatible = "arm,mps2";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		bootargs = "init=/sbin/init earlycon";
+		stdout-path = "serial0:9600n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x21000000 0x1000000>;
+	};
+
+	ethernet at 40200000 {
+		compatible = "smsc,lan9220", "smsc,lan9115";
+		reg = <0x40200000 0x10000>;
+		interrupts = <13>;
+		interrupt-parent = <&nvic>;
+		smsc,irq-active-high;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&timer0 {
+	status = "okay";
+};
+
+&timer1 {
+	status = "okay";
+};
+
+&wdt {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/mps2.dtsi b/arch/arm/boot/dts/mps2.dtsi
new file mode 100644
index 0000000..5d2c539
--- /dev/null
+++ b/arch/arm/boot/dts/mps2.dtsi
@@ -0,0 +1,227 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "armv7-m.dtsi"
+
+/ {
+	oscclk0: clk-osc0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <50000000>;
+	};
+
+	oscclk1: clk-osc1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24576000>;
+	};
+
+	oscclk2: clk-osc2 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <25000000>;
+	};
+
+	cfgclk: clk-cfg {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <5000000>;
+	};
+
+	spicfgclk: clk-spicfg {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <75000000>;
+	};
+
+	sysclk: clk-sys {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk0>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	audmclk: clk-audm {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk1>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	audsclk: clk-auds {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk1>;
+		#clock-cells = <0>;
+		clock-div = <8>;
+		clock-mult = <1>;
+	};
+
+	spiclcd: clk-cpiclcd {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk0>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	spicon: clk-spicon {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk0>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	i2cclcd: clk-i2cclcd {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk0>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	i2caud: clk-i2caud {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk0>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		ranges;
+
+		apb {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 0x40000000 0x10000>;
+
+			timer0: mps2-timer0 at 0 {
+				compatible = "arm,mps2-timer";
+				reg = <0x0 0x1000>;
+				interrupts = <8>;
+				clocks = <&sysclk>;
+				status = "disabled";
+			};
+
+			timer1: mps2-timer1 at 1000 {
+				compatible = "arm,mps2-timer";
+				reg = <0x1000 0x1000>;
+				interrupts = <9>;
+				clocks = <&sysclk>;
+				status = "disabled";
+			};
+
+			timer2: dual-timer at 2000 {
+				compatible = "arm,sp804";
+				reg = <0x2000 0x1000>;
+				clocks = <&sysclk>;
+				interrupts = <10>;
+				status = "disabled";
+			};
+
+
+			uart0: serial at 4000 {
+				compatible = "arm,mps2-uart";
+				reg = <0x4000 0x1000>;
+				interrupts = <0 1 12>;
+				clocks = <&sysclk>;
+				status = "disabled";
+			};
+
+			uart1: serial at 5000 {
+				compatible = "arm,mps2-uart";
+				reg = <0x5000 0x1000>;
+				interrupts = <2 3 12>;
+				clocks = <&sysclk>;
+				status = "disabled";
+			};
+
+			uart2: serial at 6000 {
+				compatible = "arm,mps2-uart";
+				reg = <0x6000 0x1000>;
+				interrupts = <4 5 12>;
+				clocks = <&sysclk>;
+				status = "disabled";
+			};
+
+			wdt: watchdog at 8000 {
+				compatible = "arm,sp805", "arm,primecell";
+				arm,primecell-periphid = <0x00141805>;
+				reg = <0x8000 0x1000>;
+				interrupts = <0>;
+				clocks = <&sysclk>;
+				clock-names = "apb_pclk";
+				status = "disabled";
+			};
+		};
+
+		fpgaio {
+			compatible = "syscon", "simple-mfd";
+			reg = <0x40028000 0x10>;
+
+			led at 0 {
+				compatible = "register-bit-led";
+				offset = <0x0>;
+				mask = <0x01>;
+				label = "userled:0";
+				linux,default-trigger = "heartbeat";
+				default-state = "on";
+			};
+
+			led at 1 {
+				compatible = "register-bit-led";
+				offset = <0x0>;
+				mask = <0x02>;
+				label = "userled:1";
+				linux,default-trigger = "usr";
+				default-state = "off";
+			};
+		};
+	};
+};
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb  2 03:39:59 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue,  2 Feb 2016 11:39:59 +0000
Subject: [PATCH v2 10/10] ARM: dts: introduce MPS2 AN399/AN400
In-Reply-To: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1454413199-26573-11-git-send-email-vladimir.murzin@arm.com>

Application Notes 399 and 400 shares the same memory map and
features. Both are shipped with Cortex-M7 and have the same  peripheral
as AN385/AN386, but with different location of PSRAM and Ethernet
controller.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 arch/arm/boot/dts/Makefile       |    4 +-
 arch/arm/boot/dts/mps2-an399.dts |   92 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 95 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/mps2-an399.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 96418d2..ad5622b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -245,7 +245,9 @@ dtb-$(CONFIG_ARCH_MMP) += \
 dtb-$(CONFIG_MACH_MESON8B) += \
 	meson8b-mxq.dtb \
 	meson8b-odroidc1.dtb
-dtb-$(CONFIG_ARCH_MPS2) += mps2-an385.dtb
+dtb-$(CONFIG_ARCH_MPS2) += \
+	mps2-an385.dtb \
+	mps2-an399.dtb
 dtb-$(CONFIG_ARCH_MOXART) += \
 	moxart-uc7112lx.dtb
 dtb-$(CONFIG_SOC_IMX1) += \
diff --git a/arch/arm/boot/dts/mps2-an399.dts b/arch/arm/boot/dts/mps2-an399.dts
new file mode 100644
index 0000000..e591d75
--- /dev/null
+++ b/arch/arm/boot/dts/mps2-an399.dts
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "mps2.dtsi"
+
+/ {
+	model = "ARM MPS2 Application Note 399/400";
+	compatible = "arm,mps2";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		bootargs = "rdinit=/sbin/init earlycon";
+		stdout-path = "serial0:9600n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x60000000 0x1000000>;
+	};
+
+
+	ethernet at a0000000 {
+		compatible = "smsc,lan9220", "smsc,lan9115";
+		reg = <0xa0000000 0x10000>;
+		interrupts = <13>;
+		interrupt-parent = <&nvic>;
+		smsc,irq-active-high;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+
+&timer0 {
+	status = "okay";
+};
+
+&timer1 {
+	status = "okay";
+};
+
+&wdt {
+	status = "okay";
+};
-- 
1.7.9.5



From mpa at pengutronix.de  Tue Feb  2 03:41:40 2016
From: mpa at pengutronix.de (Markus Pargmann)
Date: Tue, 02 Feb 2016 12:41:40 +0100
Subject: [PATCH v10 4/8] mfd: fsl imx25 Touchscreen ADC driver
In-Reply-To: <20160111065441.GW3331@x1>
References: <1450101234-2191-1-git-send-email-mpa@pengutronix.de>
 <1450101234-2191-5-git-send-email-mpa@pengutronix.de>
 <20160111065441.GW3331@x1>
Message-ID: <6151166.y0HMDdqtvF@adelgunde>

Hi,

On Monday, January 11, 2016 06:54:41 AM Lee Jones wrote:
> On Mon, 14 Dec 2015, Markus Pargmann wrote:
> 
> > This is the core driver for imx25 touchscreen/adc driver. The module
> > has one shared ADC and two different conversion queues which use the
> > ADC. The two queues are identical. Both can be used for general purpose
> > ADC but one is meant to be used for touchscreens.
> > 
> > This driver is the core which manages the central components and
> > registers of the TSC/ADC unit. It manages the IRQs and forwards them to
> > the correct components.
> > 
> > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > Signed-off-by: Denis Carikli <denis at eukrea.com>
> > 
> > [ensure correct ADC clock depending on the IPG clock]
> > Signed-off-by: Juergen Borleis <jbe at pengutronix.de>
> > Acked-by: Jonathan Cameron <jic23 at kernel.org>
> > ---
> > 
> > Notes:
> >     Changes in v7:
> >      - Cleanup bit defines in header files to be more readable
> >      - Fix irq check to return with an error for irq <= 0
> >      - Add COMPILE_TEST in Kconfig file
> >     
> >     Changes in v5:
> >      - Remove ifdef CONFIG_OF as this driver is only for DT usage
> >      - Remove module owner
> >      - Add Kconfig dependencies ARCH_MX25 and OF
> > 
> >  drivers/mfd/Kconfig             |   9 ++
> >  drivers/mfd/Makefile            |   2 +
> >  drivers/mfd/fsl-imx25-tsadc.c   | 203 ++++++++++++++++++++++++++++++++++++++++
> >  include/linux/mfd/imx25-tsadc.h | 140 +++++++++++++++++++++++++++
> >  4 files changed, 354 insertions(+)
> >  create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
> >  create mode 100644 include/linux/mfd/imx25-tsadc.h
> 
> For my own reference:
>   Acked-by: Lee Jones <lee.jones at linaro.org>
> 
> I will apply this and sent out pull-requests to the relevant
> maintainers once -rc1 is out.

Thanks. Do you mean just this patch or the whole series?

Shall I resend the whole series to fix the commit title of the first
patch?

Best Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/7ec6e01c/attachment.sig>

From jszhang at marvell.com  Tue Feb  2 03:39:42 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 2 Feb 2016 19:39:42 +0800
Subject: [PATCH] mmc: sdhci-of-at91: fix pm runtime unbalanced issue in
 error path
In-Reply-To: <CAPDyKFoAHPVHybhZG4BRcWHe8rm4MF0env0LfOuV2V5KZ9OaYQ@mail.gmail.com>
References: <1453804954-3490-1-git-send-email-jszhang@marvell.com>
 <CAPDyKFoAHPVHybhZG4BRcWHe8rm4MF0env0LfOuV2V5KZ9OaYQ@mail.gmail.com>
Message-ID: <20160202193942.3525cd5d@xhacker>

On Tue, 2 Feb 2016 12:32:29 +0100 Ulf Hansson wrote:

> On 26 January 2016 at 11:42, Jisheng Zhang <jszhang at marvell.com> wrote:
> > The device power usage counter is increased by pm_runtime_get_noresume
> > but isn't decreased in err_add_host error path.
> >
> > Fix this issue by calling pm_runtime_put_noidle() in the error path to
> > restore the device's power usage counter.
> >
> > Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
> > Fixes: f5f17813ae9b ("mmc: sdhci-of-at91: add PM support)
> > ---
> >  drivers/mmc/host/sdhci-of-at91.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-of-at91.c b/drivers/mmc/host/sdhci-of-at91.c
> > index 7db7163..3bf6f31 100644
> > --- a/drivers/mmc/host/sdhci-of-at91.c
> > +++ b/drivers/mmc/host/sdhci-of-at91.c
> > @@ -210,7 +210,7 @@ static int sdhci_at91_probe(struct platform_device *pdev)
> >
> >  pm_runtime_disable:
> >         pm_runtime_disable(&pdev->dev);
> > -       pm_runtime_set_suspended(&pdev->dev);  
> 
> What's the reason you want to remove the call to
> pm_runtime_set_suspended()? I think it could stay.

Indeed, thanks for pointing out. Will send a v2.

Thank you,
Jisheng

> 
> > +       pm_runtime_put_noidle(&pdev->dev);
> >  clocks_disable_unprepare:
> >         clk_disable_unprepare(priv->gck);
> >         clk_disable_unprepare(priv->mainck);
> > --
> > 2.7.0
> >  
> 
> Kind regards
> Uffe



From mark.rutland at arm.com  Tue Feb  2 03:43:41 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 2 Feb 2016 11:43:41 +0000
Subject: [RFC PATCH] irq/mbigen:Fix the problem of IO remap for
 duplicated physical address in mbigen driver
In-Reply-To: <56B08431.3000200@huawei.com>
References: <1454327094-7848-1-git-send-email-majun258@huawei.com>
 <20160201115717.GD674@leverpostej> <56AF585E.6050005@huawei.com>
 <20160201132557.GG674@leverpostej> <56B08431.3000200@huawei.com>
Message-ID: <20160202114340.GA28839@leverpostej>

On Tue, Feb 02, 2016 at 06:25:53PM +0800, majun (F) wrote:
> Hi Mark:
> 
> ? 2016/2/1 21:25, Mark Rutland ??:
> > On Mon, Feb 01, 2016 at 09:06:38PM +0800, majun (F) wrote:
> >>
> >>
> >> ? 2016/2/1 19:57, Mark Rutland ??:
> >>> On Mon, Feb 01, 2016 at 07:44:54PM +0800, MaJun wrote:
> >>>> From: Ma Jun <majun258 at huawei.com>
> >>>>
> >>>> For mbigen module, there is a special case that more than one mbigen 
> >>>> device nodes use the same reg definition in DTS when these devices
> >>>> exist in the same mbigen hardware module. 
> >>>>
> >>>> mbigen_dev1:intc_dev1 {
> >>>> 	...
> >>>> 	reg = <0x0 0xc0080000 0x0 0x10000>;
> >>>> 	...
> >>>> };
> >>>>
> >>>> mbigen_dev2:intc_dev2 {
> >>>> 	...
> >>>> 	reg = <0x0 0xc0080000 0x0 0x10000>;
> >>>> 	...
> >>>> };
> >>>
> >>> This doesn't sound right. If they exist in the same place, and have the
> >>> same reg, they _are_ the same device.
> >>>
> >>> You'll need to explain this better.
> >>>
> >>
> >> For a mbigen hardware module which connecte with several devices,
> >> because these devices has different device ID,
> >> I need to define a device node for each device in DTS file.
> >>
> >> 	mbigen
> >> 	|
> >> ------------------
> >> | 	| 	|
> >> dev1 	dev2 	dev3
> >>
> >> Because of register layout,the registers related with these devices
> >> are put together, I can't split them clearly.
> >> So, I only make these devices which connect with
> >> same mbigen hardware module usethe same address.
> > 
> > This sounds like we've either mis-described the mbigen in the binding,
> > or we're mis-describing the relationship with the devices.
> > 
> 
> Sorry, I didn't express myself clearly.
> 
> For example, a mbigen hardware module can support several peripheral devices
> with different device ID.
> 
> |-----------------------|-
> |	mbigen		|
> |-----------------------|-
>  |       |        |
> dev1    dev2     dev3
> 
> To simplify the mbigen drvier,
> I didn't use the whole mbigen module as a mbgien device, but use
> the register collections(vector, trigger type,status etc.) corresponding
> to a peripheral device as a mbigen device.
> So, mbigen device is a logical conception or logical device.

>From the above, it sounds like the DT representation is not an accurate
representation of the hardware. We should describe the _whole_ mbigen,
not portions thereof. Trying to describe it piecemeal leads to problems
like this one.

I don't understand the rationale for describing the mbigen as separate
nodes. Above you mention that we "need to define a device node for each
device", but I don't see why that's necessary. Why do you believe we
need an mbigen node per client device?

As far as I can tell, we should be able to map an arbitrary
interrupt-specifier to a particular MSI (complete with device id) within
the mbigen driver. We just need to define the full set of MSIs the
mbigen owns.

> Now, a mbigen hardware module contains several logical mbigen device.
> 
> -------------------------------
> |mgn_dev1  mgn_dev2  mgn_dev3 |
> |-----------------------------|
>    |          |        |
> dev1	    dev2      dev3
> 
> So,mgn_dev1, mgn_dev2 and mgn_dev3 exist in same mbigen hardware module,
> and,they use the same reg address region,that is adress of mbigen hardware module.
> 
> For this case, I think the question is can we map an reg address
> region more than one time?

As above, I think we've mis-described the hardware. Rather than making
things simpler, this has resulted in problems like this one.

We should not map a reg region more than once. Even if it's technically
possible to do so, I do not believe that would be the right solution
here. Implicitly sharing resources (e.g. portions of the mbigen control
registers) is inevitably going to lead to more problems later on.

Mark.


From daniel at zonque.org  Tue Feb  2 03:56:24 2016
From: daniel at zonque.org (Daniel Mack)
Date: Tue, 2 Feb 2016 12:56:24 +0100
Subject: [PATCH v2 1/3] Input: rotary-encoder - make use of devm_* to
 simplify .probe and .remove
In-Reply-To: <1454408678-6011-2-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <1454408678-6011-2-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <56B09968.9050705@zonque.org>

On 02/02/2016 11:24 AM, Uwe Kleine-K?nig wrote:
> For all operations called in .probe there are devm_* variants.
> (input_register_device is clever enough to be devm aware on its own.)
> This allows to get rid of the error unwind code paths in .probe and the
> complete .remove function.

While at it, could you also convert this over to the gpiod_* API?


Thanks,
Daniel



> 
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> ---
>  drivers/input/misc/rotary_encoder.c | 74 +++++++++++--------------------------
>  1 file changed, 22 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/input/misc/rotary_encoder.c b/drivers/input/misc/rotary_encoder.c
> index 8aee71986430..386bdb5314e6 100644
> --- a/drivers/input/misc/rotary_encoder.c
> +++ b/drivers/input/misc/rotary_encoder.c
> @@ -211,8 +211,8 @@ static struct rotary_encoder_platform_data *rotary_encoder_parse_dt(struct devic
>  	if (!of_id || !np)
>  		return NULL;
>  
> -	pdata = kzalloc(sizeof(struct rotary_encoder_platform_data),
> -			GFP_KERNEL);
> +	pdata = devm_kzalloc(dev, sizeof(struct rotary_encoder_platform_data),
> +			     GFP_KERNEL);
>  	if (!pdata)
>  		return ERR_PTR(-ENOMEM);
>  
> @@ -277,11 +277,11 @@ static int rotary_encoder_probe(struct platform_device *pdev)
>  		}
>  	}
>  
> -	encoder = kzalloc(sizeof(struct rotary_encoder), GFP_KERNEL);
> -	input = input_allocate_device();
> +	encoder = devm_kzalloc(dev, sizeof(struct rotary_encoder), GFP_KERNEL);
> +	input = devm_input_allocate_device(&pdev->dev);
>  	if (!encoder || !input) {
> -		err = -ENOMEM;
> -		goto exit_free_mem;
> +		dev_err(dev, "unable to allocate memory\n");
> +		return -ENOMEM;
>  	}
>  
>  	encoder->input = input;
> @@ -301,16 +301,18 @@ static int rotary_encoder_probe(struct platform_device *pdev)
>  	}
>  
>  	/* request the GPIOs */
> -	err = gpio_request_one(pdata->gpio_a, GPIOF_IN, dev_name(dev));
> +	err = devm_gpio_request_one(dev, pdata->gpio_a,
> +				    GPIOF_IN, dev_name(dev));
>  	if (err) {
>  		dev_err(dev, "unable to request GPIO %d\n", pdata->gpio_a);
> -		goto exit_free_mem;
> +		return err;
>  	}
>  
> -	err = gpio_request_one(pdata->gpio_b, GPIOF_IN, dev_name(dev));
> +	err = devm_gpio_request_one(dev, pdata->gpio_b,
> +				    GPIOF_IN, dev_name(dev));
>  	if (err) {
>  		dev_err(dev, "unable to request GPIO %d\n", pdata->gpio_b);
> -		goto exit_free_gpio_a;
> +		return err;
>  	}
>  
>  	encoder->irq_a = gpio_to_irq(pdata->gpio_a);
> @@ -331,30 +333,29 @@ static int rotary_encoder_probe(struct platform_device *pdev)
>  	default:
>  		dev_err(dev, "'%d' is not a valid steps-per-period value\n",
>  			pdata->steps_per_period);
> -		err = -EINVAL;
> -		goto exit_free_gpio_b;
> +		return -EINVAL;
>  	}
>  
> -	err = request_irq(encoder->irq_a, handler,
> -			  IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
> -			  DRV_NAME, encoder);
> +	err = devm_request_irq(dev, encoder->irq_a, handler,
> +			       IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
> +			       DRV_NAME, encoder);
>  	if (err) {
>  		dev_err(dev, "unable to request IRQ %d\n", encoder->irq_a);
> -		goto exit_free_gpio_b;
> +		return err;
>  	}
>  
> -	err = request_irq(encoder->irq_b, handler,
> -			  IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
> -			  DRV_NAME, encoder);
> +	err = devm_request_irq(dev, encoder->irq_b, handler,
> +			       IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
> +			       DRV_NAME, encoder);
>  	if (err) {
>  		dev_err(dev, "unable to request IRQ %d\n", encoder->irq_b);
> -		goto exit_free_irq_a;
> +		return err;
>  	}
>  
>  	err = input_register_device(input);
>  	if (err) {
>  		dev_err(dev, "failed to register input device\n");
> -		goto exit_free_irq_b;
> +		return err;
>  	}
>  
>  	device_init_wakeup(&pdev->dev, pdata->wakeup_source);
> @@ -362,42 +363,11 @@ static int rotary_encoder_probe(struct platform_device *pdev)
>  	platform_set_drvdata(pdev, encoder);
>  
>  	return 0;
> -
> -exit_free_irq_b:
> -	free_irq(encoder->irq_b, encoder);
> -exit_free_irq_a:
> -	free_irq(encoder->irq_a, encoder);
> -exit_free_gpio_b:
> -	gpio_free(pdata->gpio_b);
> -exit_free_gpio_a:
> -	gpio_free(pdata->gpio_a);
> -exit_free_mem:
> -	input_free_device(input);
> -	kfree(encoder);
> -	if (!dev_get_platdata(&pdev->dev))
> -		kfree(pdata);
> -
> -	return err;
>  }
>  
>  static int rotary_encoder_remove(struct platform_device *pdev)
>  {
> -	struct rotary_encoder *encoder = platform_get_drvdata(pdev);
> -	const struct rotary_encoder_platform_data *pdata = encoder->pdata;
> -
>  	device_init_wakeup(&pdev->dev, false);
> -
> -	free_irq(encoder->irq_a, encoder);
> -	free_irq(encoder->irq_b, encoder);
> -	gpio_free(pdata->gpio_a);
> -	gpio_free(pdata->gpio_b);
> -
> -	input_unregister_device(encoder->input);
> -	kfree(encoder);
> -
> -	if (!dev_get_platdata(&pdev->dev))
> -		kfree(pdata);
> -
>  	return 0;
>  }
>  
> 



From jszhang at marvell.com  Tue Feb  2 03:55:06 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 2 Feb 2016 19:55:06 +0800
Subject: [PATCH v2] mmc: sdhci-of-at91: fix pm runtime unbalanced issue in
 error path
Message-ID: <1454414106-4441-1-git-send-email-jszhang@marvell.com>

The device power usage counter is increased by pm_runtime_get_noresume
but isn't decreased in err_add_host error path.

Fix this issue by calling pm_runtime_put_noidle() in the error path to
restore the device's power usage counter.

Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
Acked-by: Ludovic Desroches <ludovic.desroches at atmel.com>
Fixes: f5f17813ae9b ("mmc: sdhci-of-at91: add PM support)
---
Since v1:
 - Add Ludovic ack
 - address Ulf's comment

 drivers/mmc/host/sdhci-of-at91.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/sdhci-of-at91.c b/drivers/mmc/host/sdhci-of-at91.c
index 7db7163..35c02fc 100644
--- a/drivers/mmc/host/sdhci-of-at91.c
+++ b/drivers/mmc/host/sdhci-of-at91.c
@@ -211,6 +211,7 @@ static int sdhci_at91_probe(struct platform_device *pdev)
 pm_runtime_disable:
 	pm_runtime_disable(&pdev->dev);
 	pm_runtime_set_suspended(&pdev->dev);
+	pm_runtime_put_noidle(&pdev->dev);
 clocks_disable_unprepare:
 	clk_disable_unprepare(priv->gck);
 	clk_disable_unprepare(priv->mainck);
-- 
1.9.1



From daniel at zonque.org  Tue Feb  2 04:08:07 2016
From: daniel at zonque.org (Daniel Mack)
Date: Tue, 2 Feb 2016 13:08:07 +0100
Subject: [PATCH v2 0/3] Input: rotary-encoder - use more than two gpios
In-Reply-To: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <56B09C27.8070009@zonque.org>

Hi Uwe,

Thanks for the update.

On 02/02/2016 11:24 AM, Uwe Kleine-K?nig wrote:
> Some time ago I sent a v1 of this, now after testing the changes more
> deeply patch 3 changed a bit. The old series started with
> 
> 	Date: Wed,  2 Dec 2015 11:07:11 +0100                                                                                               
> 	From: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>                                                                             
> 	Subject: [PATCH RFC 0/3] input: rotary_encoder: use more than two gpios as input                                                    
> 	Message-Id: <1449050834-31779-1-git-send-email-u.kleine-koenig at pengutronix.de>                                                      
> 
> The two first patches are just preparation for the third patch.
> 
> There is an obvious improvement that allows detection of quick changes
> more reliably with >2 gpios, but I didn't implement this yet. (With 4
> GPIOs you can distinguish a counter clockwise movement of three states
> from a clock wise movement of a single state. Still the patch is useful
> as it makes these devices work at all.
> 
> My test device looks as follows:
> 
>         rotary at 0 {
>                 compatible = "rotary-encoder";
>                 gpios = <&gpio4 12 GPIO_ACTIVE_HIGH>, <&gpio4 11 GPIO_ACTIVE_HIGH>, <&gpio4 10 GPIO_ACTIVE_HIGH>, <&gpio4 9 GPIO_ACTIVE_HIGH>;
> 
>                 rotary-encoder,steps = <16>;
> 		rotary-encoder,steps-per-period = <16>;
>         };
> 
> While Daniel Mack and Rojhalat Ibrahim agreed that this device is an
> absolute encoder and should be supported by a simpler logic, I still
> consider it worthwhile to get these patches in as a first step. Also the
> binding looks right, so IMHO the comments shouldn't stop this series
> from going in.

I still don't understand why this is implemented that way, rather than
going for a much simpler logic of interpretation that also allows users
to read out the absolute position.

The code to read the value would be really just as simple as reading all
GPIOs and or-ing their values into the result, and skip the state
machine completely. This code would be active if a new attribute
(something like 'rotary-encoder,hardware-absolute') is set, or even
implicitly, when more than 2 GPIOs are specified.

Is there any reason for not doing that?


Thanks,
Daniel



From daniel at zonque.org  Tue Feb  2 04:10:19 2016
From: daniel at zonque.org (Daniel Mack)
Date: Tue, 2 Feb 2016 13:10:19 +0100
Subject: [PATCH v2 2/3] Input: rotary-encoder - move configuration data to
 driver data
In-Reply-To: <1454408678-6011-3-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <1454408678-6011-3-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <56B09CAB.5020600@zonque.org>

On 02/02/2016 11:24 AM, Uwe Kleine-K?nig wrote:
> This is a preparation for the next patche. There is no change in
> behaviour intended.

This one looks good to me, but it clashes with Dmitry's latest patch
sets (which I haven't found the time to test yet, sorry!).

> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>

 Acked-by: Daniel Mack <daniel at zonque.org>




Thanks,
Daniel


> ---
>  drivers/input/misc/rotary_encoder.c | 166 ++++++++++++++++++++----------------
>  1 file changed, 94 insertions(+), 72 deletions(-)
> 
> diff --git a/drivers/input/misc/rotary_encoder.c b/drivers/input/misc/rotary_encoder.c
> index 386bdb5314e6..0582e851993f 100644
> --- a/drivers/input/misc/rotary_encoder.c
> +++ b/drivers/input/misc/rotary_encoder.c
> @@ -32,58 +32,65 @@
>  
>  struct rotary_encoder {
>  	struct input_dev *input;
> -	const struct rotary_encoder_platform_data *pdata;
>  
> +	/* configuration */
> +	unsigned int steps;
>  	unsigned int axis;
> -	unsigned int pos;
> +	unsigned int gpio_a;
> +	unsigned int gpio_b;
> +	unsigned int inverted_a;
> +	unsigned int inverted_b;
> +	unsigned int steps_per_period;
> +	bool relative_axis;
> +	bool rollover;
> +	bool wakeup_source;
>  
>  	unsigned int irq_a;
>  	unsigned int irq_b;
>  
> +	/* state */
> +	unsigned int pos;
>  	bool armed;
>  	unsigned char dir;	/* 0 - clockwise, 1 - CCW */
> -
>  	char last_stable;
>  };
>  
> -static int rotary_encoder_get_state(const struct rotary_encoder_platform_data *pdata)
> +static int rotary_encoder_get_state(const struct rotary_encoder *encoder)
>  {
> -	int a = !!gpio_get_value(pdata->gpio_a);
> -	int b = !!gpio_get_value(pdata->gpio_b);
> +	int a = !!gpio_get_value(encoder->gpio_a);
> +	int b = !!gpio_get_value(encoder->gpio_b);
>  
> -	a ^= pdata->inverted_a;
> -	b ^= pdata->inverted_b;
> +	a ^= encoder->inverted_a;
> +	b ^= encoder->inverted_b;
>  
>  	return ((a << 1) | b);
>  }
>  
>  static void rotary_encoder_report_event(struct rotary_encoder *encoder)
>  {
> -	const struct rotary_encoder_platform_data *pdata = encoder->pdata;
> -
> -	if (pdata->relative_axis) {
> +	if (encoder->relative_axis) {
>  		input_report_rel(encoder->input,
> -				 pdata->axis, encoder->dir ? -1 : 1);
> +				 encoder->axis, encoder->dir ? -1 : 1);
>  	} else {
>  		unsigned int pos = encoder->pos;
>  
>  		if (encoder->dir) {
>  			/* turning counter-clockwise */
> -			if (pdata->rollover)
> -				pos += pdata->steps;
> +			if (encoder->rollover)
> +				pos += encoder->steps;
>  			if (pos)
>  				pos--;
>  		} else {
>  			/* turning clockwise */
> -			if (pdata->rollover || pos < pdata->steps)
> +			if (encoder->rollover || pos < encoder->steps)
>  				pos++;
>  		}
>  
> -		if (pdata->rollover)
> -			pos %= pdata->steps;
> +		if (encoder->rollover)
> +			pos %= encoder->steps;
>  
>  		encoder->pos = pos;
> -		input_report_abs(encoder->input, pdata->axis, encoder->pos);
> +		input_report_abs(encoder->input, encoder->axis, encoder->pos);
>  	}
>  
>  	input_sync(encoder->input);
> @@ -94,7 +101,7 @@ static irqreturn_t rotary_encoder_irq(int irq, void *dev_id)
>  	struct rotary_encoder *encoder = dev_id;
>  	int state;
>  
> -	state = rotary_encoder_get_state(encoder->pdata);
> +	state = rotary_encoder_get_state(encoder);
>  
>  	switch (state) {
>  	case 0x0:
> @@ -123,7 +130,7 @@ static irqreturn_t rotary_encoder_half_period_irq(int irq, void *dev_id)
>  	struct rotary_encoder *encoder = dev_id;
>  	int state;
>  
> -	state = rotary_encoder_get_state(encoder->pdata);
> +	state = rotary_encoder_get_state(encoder);
>  
>  	switch (state) {
>  	case 0x00:
> @@ -149,7 +156,7 @@ static irqreturn_t rotary_encoder_quarter_period_irq(int irq, void *dev_id)
>  	unsigned char sum;
>  	int state;
>  
> -	state = rotary_encoder_get_state(encoder->pdata);
> +	state = rotary_encoder_get_state(encoder);
>  
>  	/*
>  	 * We encode the previous and the current state using a byte.
> @@ -199,38 +206,34 @@ static const struct of_device_id rotary_encoder_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, rotary_encoder_of_match);
>  
> -static struct rotary_encoder_platform_data *rotary_encoder_parse_dt(struct device *dev)
> +static int rotary_encoder_parse_dt(struct device *dev,
> +				   struct rotary_encoder *encoder)
>  {
>  	const struct of_device_id *of_id =
>  				of_match_device(rotary_encoder_of_match, dev);
>  	struct device_node *np = dev->of_node;
> -	struct rotary_encoder_platform_data *pdata;
>  	enum of_gpio_flags flags;
>  	int error;
>  
>  	if (!of_id || !np)
> -		return NULL;
> -
> -	pdata = devm_kzalloc(dev, sizeof(struct rotary_encoder_platform_data),
> -			     GFP_KERNEL);
> -	if (!pdata)
> -		return ERR_PTR(-ENOMEM);
> +		return 1;
>  
> -	of_property_read_u32(np, "rotary-encoder,steps", &pdata->steps);
> -	of_property_read_u32(np, "linux,axis", &pdata->axis);
> +	of_property_read_u32(np, "rotary-encoder,steps", &encoder->steps);
> +	of_property_read_u32(np, "linux,axis", &encoder->axis);
>  
> -	pdata->gpio_a = of_get_gpio_flags(np, 0, &flags);
> -	pdata->inverted_a = flags & OF_GPIO_ACTIVE_LOW;
> +	encoder->gpio_a = of_get_gpio_flags(np, 0, &flags);
> +	encoder->inverted_a = flags & OF_GPIO_ACTIVE_LOW;
>  
> -	pdata->gpio_b = of_get_gpio_flags(np, 1, &flags);
> -	pdata->inverted_b = flags & OF_GPIO_ACTIVE_LOW;
> +	encoder->gpio_b = of_get_gpio_flags(np, 1, &flags);
> +	encoder->inverted_b = flags & OF_GPIO_ACTIVE_LOW;
>  
> -	pdata->relative_axis =
> +	encoder->relative_axis =
>  		of_property_read_bool(np, "rotary-encoder,relative-axis");
> -	pdata->rollover = of_property_read_bool(np, "rotary-encoder,rollover");
> +	encoder->rollover =
> +		of_property_read_bool(np, "rotary-encoder,rollover");
>  
>  	error = of_property_read_u32(np, "rotary-encoder,steps-per-period",
> -				     &pdata->steps_per_period);
> +				     &encoder->steps_per_period);
>  	if (error) {
>  		/*
>  		 * The 'half-period' property has been deprecated, you must use
> @@ -238,45 +241,57 @@ static struct rotary_encoder_platform_data *rotary_encoder_parse_dt(struct devic
>  		 * need to parse it to maintain compatibility.
>  		 */
>  		if (of_property_read_bool(np, "rotary-encoder,half-period")) {
> -			pdata->steps_per_period = 2;
> +			encoder->steps_per_period = 2;
>  		} else {
>  			/* Fallback to one step per period behavior */
> -			pdata->steps_per_period = 1;
> +			encoder->steps_per_period = 1;
>  		}
>  	}
>  
> -	pdata->wakeup_source = of_property_read_bool(np, "wakeup-source");
> +	encoder->wakeup_source = of_property_read_bool(np, "wakeup-source");
>  
> -	return pdata;
> +	return 0;
>  }
>  #else
> -static inline struct rotary_encoder_platform_data *
> -rotary_encoder_parse_dt(struct device *dev)
> +static inline int rotary_encoder_parse_dt(struct device *dev,
> +					  struct rotary_encoder *encoder)
>  {
> -	return NULL;
> +	return 1;
>  }
>  #endif
>  
> +static int rotary_encoder_parse_pdata(struct device *dev,
> +				      struct rotary_encoder *encoder)
> +{
> +	const struct rotary_encoder_platform_data *pdata;
> +
> +	pdata = dev_get_platdata(dev);
> +	if (!pdata) {
> +		dev_err(dev, "missing platform data\n");
> +		return -EINVAL;
> +	}
> +
> +	encoder->steps = pdata->steps;
> +	encoder->axis = pdata->axis;
> +	encoder->gpio_a = pdata->gpio_a;
> +	encoder->gpio_b = pdata->gpio_b;
> +	encoder->inverted_a = pdata->inverted_a;
> +	encoder->inverted_b = pdata->inverted_b;
> +	encoder->steps_per_period = pdata->steps_per_period;
> +	encoder->relative_axis = pdata->relative_axis;
> +	encoder->rollover = pdata->rollover;
> +
> +	return 0;
> +}
> +
>  static int rotary_encoder_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> -	const struct rotary_encoder_platform_data *pdata = dev_get_platdata(dev);
>  	struct rotary_encoder *encoder;
>  	struct input_dev *input;
>  	irq_handler_t handler;
>  	int err;
>  
> -	if (!pdata) {
> -		pdata = rotary_encoder_parse_dt(dev);
> -		if (IS_ERR(pdata))
> -			return PTR_ERR(pdata);
> -
> -		if (!pdata) {
> -			dev_err(dev, "missing platform data\n");
> -			return -EINVAL;
> -		}
> -	}
> -
>  	encoder = devm_kzalloc(dev, sizeof(struct rotary_encoder), GFP_KERNEL);
>  	input = devm_input_allocate_device(&pdev->dev);
>  	if (!encoder || !input) {
> @@ -284,55 +299,62 @@ static int rotary_encoder_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  	}
>  
> +	err = rotary_encoder_parse_dt(dev, encoder);
> +	if (err > 0)
> +		/* not instatiated by dt */
> +		err = rotary_encoder_parse_pdata(dev, encoder);
> +
> +	if (err < 0)
> +		return err;
> +
>  	encoder->input = input;
> -	encoder->pdata = pdata;
>  
>  	input->name = pdev->name;
>  	input->id.bustype = BUS_HOST;
>  	input->dev.parent = dev;
>  
> -	if (pdata->relative_axis) {
> +	if (encoder->relative_axis) {
>  		input->evbit[0] = BIT_MASK(EV_REL);
> -		input->relbit[0] = BIT_MASK(pdata->axis);
> +		input->relbit[0] = BIT_MASK(encoder->axis);
>  	} else {
>  		input->evbit[0] = BIT_MASK(EV_ABS);
>  		input_set_abs_params(encoder->input,
> -				     pdata->axis, 0, pdata->steps, 0, 1);
> +				     encoder->axis, 0, encoder->steps, 0, 1);
>  	}
>  
>  	/* request the GPIOs */
> -	err = devm_gpio_request_one(dev, pdata->gpio_a,
> +	err = devm_gpio_request_one(dev, encoder->gpio_a,
>  				    GPIOF_IN, dev_name(dev));
>  	if (err) {
> -		dev_err(dev, "unable to request GPIO %d\n", pdata->gpio_a);
> +		dev_err(dev, "unable to request GPIO %d\n", encoder->gpio_a);
>  		return err;
>  	}
>  
> -	err = devm_gpio_request_one(dev, pdata->gpio_b,
> +	err = devm_gpio_request_one(dev, encoder->gpio_b,
>  				    GPIOF_IN, dev_name(dev));
>  	if (err) {
> -		dev_err(dev, "unable to request GPIO %d\n", pdata->gpio_b);
> +		dev_err(dev, "unable to request GPIO %d\n", encoder->gpio_b);
>  		return err;
>  	}
>  
> -	encoder->irq_a = gpio_to_irq(pdata->gpio_a);
> -	encoder->irq_b = gpio_to_irq(pdata->gpio_b);
> +	encoder->irq_a = gpio_to_irq(encoder->gpio_a);
> +	encoder->irq_b = gpio_to_irq(encoder->gpio_b);
>  
> -	switch (pdata->steps_per_period) {
> +	switch (encoder->steps_per_period) {
>  	case 4:
>  		handler = &rotary_encoder_quarter_period_irq;
> -		encoder->last_stable = rotary_encoder_get_state(pdata);
> +		encoder->last_stable = rotary_encoder_get_state(encoder);
>  		break;
>  	case 2:
>  		handler = &rotary_encoder_half_period_irq;
> -		encoder->last_stable = rotary_encoder_get_state(pdata);
> +		encoder->last_stable = rotary_encoder_get_state(encoder);
>  		break;
>  	case 1:
>  		handler = &rotary_encoder_irq;
>  		break;
>  	default:
>  		dev_err(dev, "'%d' is not a valid steps-per-period value\n",
> -			pdata->steps_per_period);
> +			encoder->steps_per_period);
>  		return -EINVAL;
>  	}
>  
> @@ -358,7 +380,7 @@ static int rotary_encoder_probe(struct platform_device *pdev)
>  		return err;
>  	}
>  
> -	device_init_wakeup(&pdev->dev, pdata->wakeup_source);
> +	device_init_wakeup(&pdev->dev, encoder->wakeup_source);
>  
>  	platform_set_drvdata(pdev, encoder);
>  
> 



From k at japko.eu  Tue Feb  2 04:10:31 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Tue, 2 Feb 2016 13:10:31 +0100
Subject: [PATCH] pinctrl: sunxi: Add H3 R_PIO controller support
In-Reply-To: <20160202092451.GA26944@box2.japko.eu>
References: <20160201101225.GA19687@box2.japko.eu>
 <CAGb2v65-X2_MoRm1=wAub9Y8Vpt-f-roYUT73jDk5Fnj17zKTw@mail.gmail.com>
 <20160202092451.GA26944@box2.japko.eu>
Message-ID: <20160202121030.GA8309@box2.japko.eu>

On Tue, Feb 02, 2016 at 10:24:51AM +0100, Krzysztof Adamski wrote:
>On Tue, Feb 02, 2016 at 02:25:18PM +0800, Chen-Yu Tsai wrote:
>>On Mon, Feb 1, 2016 at 6:12 PM, Krzysztof Adamski <k at japko.eu> wrote:
>>>- reg: Should contain the register physical address and length for 
>>>the
>>>diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>index 1524130e..745f64c 100644
>>>--- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>@@ -493,5 +493,17 @@
>>>                        interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
>>>                                     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
>>>                };
>>>+
>>>+               r_pio: pinctrl at 01f02c00 {
>>>+                       compatible = "allwinner,sun8i-h3-r-pinctrl";
>>>+                       reg = <0x01f02c00 0x400>;
>>>+                       interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
>>>+                       clocks = <&bus_gates 69>;
>>
>>This is probably wrong. According to other SoCs all R_ block peripherals
>>have clock gates and reset controls in the PRCM.
>
>This is problematic. I can find information about reset and gates control for
>this peripheral on other SoCs user manuals but there is nothing about it in H3
>User Manual
>(https://www.dropbox.com/s/nkr9slo1o9x6i1z/Allwinner_H3_Datasheet_V1.1.pdf?dl=0).
>
>Similarly, while I think I can find r_pio clock setup for A33:
>https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw5.c
>
>I can't find it for H3, though:
>https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw7.c
>
>Well, apart from this strange snippet:
>
>// binder r-pio CPUS_APB0_GATE to pio-clk's gate-reset-register
>   clk = clk_get(NULL,"pio");
>   if(!clk || IS_ERR(clk))
>       printk("Error not get clk pio\n");
>   else
>   {
>       struct clk_hw *hw = __clk_get_hw(clk);
>       struct sunxi_clk_periph *periph = to_clk_periph(hw);
>       struct sunxi_clk_periph_gate *gate = &periph->gate;
>       gate->reset = sunxi_clk_cpus_base+CPUS_APB0_GATE ;
>       gate->rst_shift = 0;
>       clk_put(clk);
>   }
>
>
>Which I have to admit I don't fully understand. This seems to be setting reset
>line for first pio, not for r_pio - something we don't have right now. Or am I
>wrong here?
>
>I'm new to Allwinner SoCs, any help from veterans?
>
>Also, if that proves anything, I did test this code on OrangePi PC and PL ports
>works so their clock is enabled, for sure.

I did some tests and indeed, when I disabled PIO clock (bus_gates 69), 
R_PIO was still working while PIO did not. So I tryied to take the same 
address other SoCs are using (0x01f01468 - CPUS_APB0 register) and 
clearing 1st bit (which is enabled by default) disables R_PIO. So, well, 
it seems that this works the same as on other sunxi SoCs. I'll try doing 
proper change.

Best regards,
Krzysztof Adamski


From andre.przywara at arm.com  Tue Feb  2 04:11:36 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 2 Feb 2016 12:11:36 +0000
Subject: [PATCH 2/5] clk: sunxi: Make clocks setup functions take const
 pointer
In-Reply-To: <1454402834-6385-3-git-send-email-maxime.ripard@free-electrons.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454402834-6385-3-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <56B09CF8.2020801@arm.com>

On 02/02/16 08:47, Maxime Ripard wrote:
> All the data structure that we pass to the clocks setup functions are
> declared const, while our setup functions expects a regular pointer. This
> was hidden by the fact that we cast a void * pointer back to these
> structures, which made it go unnoticed.
> 
> Fix the functions prototype.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Reviewed-by: Andre Przywara <andre.przywara at arm.com>

Cheers,
Andre.

> ---
>  drivers/clk/sunxi/clk-sunxi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 67ef94948544..a3d706f5b21c 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -616,7 +616,7 @@ static const struct mux_data sun8i_h3_ahb2_mux_data __initconst = {
>  };
>  
>  static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
> -					       struct mux_data *data)
> +					       const struct mux_data *data)
>  {
>  	struct clk *clk;
>  	const char *clk_name = node->name;
> @@ -700,7 +700,7 @@ static const struct div_data sun4i_apb0_data __initconst = {
>  };
>  
>  static void __init sunxi_divider_clk_setup(struct device_node *node,
> -					   struct div_data *data)
> +					   const struct div_data *data)
>  {
>  	struct clk *clk;
>  	const char *clk_name = node->name;
> @@ -810,7 +810,7 @@ static const struct divs_data sun6i_a31_pll6_divs_data __initconst = {
>   */
>  
>  static struct clk ** __init sunxi_divs_clk_setup(struct device_node *node,
> -						 struct divs_data *data)
> +						 const struct divs_data *data)
>  {
>  	struct clk_onecell_data *clk_data;
>  	const char *parent;
> 


From broonie at kernel.org  Tue Feb  2 04:17:34 2016
From: broonie at kernel.org (Mark Brown)
Date: Tue, 2 Feb 2016 12:17:34 +0000
Subject: [PATCH 07/11] ARM: dts: sunxi: Add dtsi file for AXP809 PMIC
In-Reply-To: <1454408864-24112-8-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-8-git-send-email-wens@csie.org>
Message-ID: <20160202121733.GO4455@sirena.org.uk>

On Tue, Feb 02, 2016 at 06:27:40PM +0800, Chen-Yu Tsai wrote:

> +		reg_dcdc1: dcdc1 {
> +			regulator-name = "dcdc1";
> +		};

Why is this generic DTS include specifying regulator names?

> +		reg_rtc_ldo: rtc_ldo {
> +			/* RTC_LDO is a fixed, always-on regulator */
> +			regulator-always-on;
> +			regulator-min-microvolt = <1800000>;
> +			regulator-max-microvolt = <1800000>;

If the regulator itself is limited in this way there is no need to
specify this in the DTS.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/f280ae6e/attachment.sig>

From mark.rutland at arm.com  Tue Feb  2 04:23:18 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 2 Feb 2016 12:23:18 +0000
Subject: [PATCHv2 2/3] arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
In-Reply-To: <56AFCD09.8000807@redhat.com>
References: <1454111218-3461-1-git-send-email-labbott@fedoraproject.org>
 <1454111218-3461-3-git-send-email-labbott@fedoraproject.org>
 <20160201122911.GF674@leverpostej> <56AFCD09.8000807@redhat.com>
Message-ID: <20160202122317.GA32305@leverpostej>

On Mon, Feb 01, 2016 at 01:24:25PM -0800, Laura Abbott wrote:
> On 02/01/2016 04:29 AM, Mark Rutland wrote:
> >Hi,
> >
> >On Fri, Jan 29, 2016 at 03:46:57PM -0800, Laura Abbott wrote:
> >>
> >>ARCH_SUPPORTS_DEBUG_PAGEALLOC provides a hook to map and unmap
> >>pages for debugging purposes. This requires memory be mapped
> >>with PAGE_SIZE mappings since breaking down larger mappings
> >>at runtime will lead to TLB conflicts. Check if debug_pagealloc
> >>is enabled at runtime and if so, map everyting with PAGE_SIZE
> >>pages. Implement the functions to actually map/unmap the
> >>pages at runtime.
> >>
> >>
> >>Signed-off-by: Laura Abbott <labbott at fedoraproject.org>
> >
> >I tried to apply atop of the arm64 for-next/pgtable branch, but git
> >wasn't very happy about that -- which branch/patches is this based on?
> >
> >I'm not sure if I'm missing something, have something I shouldn't, or if
> >my MTA is corrupting patches again...
> >
> 
> Hmmm, I based it off of your arm64-pagetable-rework-20160125 tag and
> Ard's patch for vmalloc and set_memory_* . The patches seem to apply
> on the for-next/pgtable branch as well so I'm guessing you are missing
> Ard's patch.

Yup, that was it. I evidently was paying far too little attention as I'd
also missed the mm/ patch for the !CONFIG_DEBUG_PAGEALLOC case.

Is there anything else in mm/ that I've potentially missed? I'm seeing a
hang on Juno just after reaching userspace (splat below) with
debug_pagealloc=on.

It looks like something's gone wrong around find_vmap_area -- at least
one CPU is forever awaiting vmap_area_lock, and presumably some other
CPU has held it and gone into the weeds, leading to the RCU stalls and
NMI lockup warnings.

[   31.037054] INFO: rcu_preempt detected stalls on CPUs/tasks:
[   31.042684]  0-...: (1 ticks this GP) idle=999/140000000000001/0 softirq=738/738 fqs=418 
[   31.050795]  (detected by 1, t=5255 jiffies, g=340, c=339, q=50)
[   31.056935] rcu_preempt kthread starved for 4838 jiffies! g340 c339 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
[   36.509055] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [kworker/2:2H:995]
[   36.521059] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 23s! [systemd-udevd:1048]
[   36.533056] NMI watchdog: BUG: soft lockup - CPU#4 stuck for 23s! [systemd-udevd:1037]
[   36.545055] NMI watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [systemd-udevd:1036]
[   56.497055] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [upstart-file-br:1012]
[   94.057052] INFO: rcu_preempt detected stalls on CPUs/tasks:
[   94.062671]  0-...: (1 ticks this GP) idle=999/140000000000001/0 softirq=738/738 fqs=418 
[   94.070780]  (detected by 1, t=21010 jiffies, g=340, c=339, q=50)
[   94.076981] rcu_preempt kthread starved for 20593 jiffies! g340 c339 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x0
[  157.077052] INFO: rcu_preempt detected stalls on CPUs/tasks:
[  157.082673]  0-...: (1 ticks this GP) idle=999/140000000000001/0 softirq=738/738 fqs=418 
[  157.090782]  (detected by 2, t=36765 jiffies, g=340, c=339, q=50)
[  157.096986] rcu_preempt kthread starved for 36348 jiffies! g340 c339 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x0
[  220.097052] INFO: rcu_preempt detected stalls on CPUs/tasks:
[  220.102670]  0-...: (1 ticks this GP) idle=999/140000000000001/0 softirq=738/738 fqs=418 
[  220.110779]  (detected by 2, t=52520 jiffies, g=340, c=339, q=50)
[  220.116971] rcu_preempt kthread starved for 52103 jiffies! g340 c339 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x0
[  283.117052] INFO: rcu_preempt detected stalls on CPUs/tasks:
[  283.122670]  0-...: (1 ticks this GP) idle=999/140000000000001/0 softirq=738/738 fqs=418 
[  283.130779]  (detected by 1, t=68275 jiffies, g=340, c=339, q=50)
[  283.136973] rcu_preempt kthread starved for 67858 jiffies! g340 c339 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x0

Typically show-backtrace-all-active-cpus(l) gives me something like:

[  183.282835] CPU: 0 PID: 998 Comm: systemd-udevd Tainted: G             L  4.5.0-rc1+ #7
[  183.290783] Hardware name: ARM Juno development board (r0) (DT)
[  183.296659] task: ffffffc97437a400 ti: ffffffc973ec8000 task.ti: ffffffc973ec8000
[  183.304095] PC is at _raw_spin_lock+0x34/0x48
[  183.308421] LR is at find_vmap_area+0x24/0xa0
[  183.312746] pc : [<ffffffc00065faf4>] lr : [<ffffffc000185bc4>] pstate: 60000145
[  183.320092] sp : ffffffc973ecb6c0
[  183.323382] x29: ffffffc973ecb6c0 x28: ffffffbde7d50300 
[  183.328662] x27: ffffffffffffffff x26: ffffffbde7d50300 
[  183.333941] x25: 000000097e513000 x24: 0000000000000001 
[  183.339219] x23: 0000000000000000 x22: 0000000000000001 
[  183.344498] x21: ffffffc000a6dd90 x20: ffffffc000a6d000 
[  183.349778] x19: ffffffc97540c000 x18: 0000007fc4e8b960 
[  183.355057] x17: 0000007fac3088d4 x16: ffffffc0001be448 
[  183.360336] x15: 003b9aca00000000 x14: 0032aa26d4000000 
[  183.365614] x13: ffffffffa94f64df x12: 0000000000000018 
[  183.370894] x11: ffffffc97eecd730 x10: 0000000000000030 
[  183.376173] x9 : ffffffbde7d50340 x8 : ffffffc0008556a0 
[  183.381451] x7 : ffffffc0008556b8 x6 : ffffffc0008556d0 
[  183.386729] x5 : ffffffc0009d2000 x4 : 0000000000000001 
[  183.392008] x3 : 000000000000d033 x2 : 000000000000000b 
[  183.397286] x1 : 00000000d038d033 x0 : ffffffc000a6dd90 
[  183.402563] 

I'll have a go with lock debugging. Otherwise do you have any ideas?

Thanks,
Mark.


From mark.rutland at arm.com  Tue Feb  2 04:31:56 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 2 Feb 2016 12:31:56 +0000
Subject: [PATCHv2 2/3] arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
In-Reply-To: <20160202122317.GA32305@leverpostej>
References: <1454111218-3461-1-git-send-email-labbott@fedoraproject.org>
 <1454111218-3461-3-git-send-email-labbott@fedoraproject.org>
 <20160201122911.GF674@leverpostej> <56AFCD09.8000807@redhat.com>
 <20160202122317.GA32305@leverpostej>
Message-ID: <20160202123155.GB32305@leverpostej>

On Tue, Feb 02, 2016 at 12:23:18PM +0000, Mark Rutland wrote:
 Is there anything else in mm/ that I've potentially missed?
> I'm seeing a hang on Juno just after reaching userspace (splat below)
> with debug_pagealloc=on.
> 
> It looks like something's gone wrong around find_vmap_area -- at least
> one CPU is forever awaiting vmap_area_lock, and presumably some other
> CPU has held it and gone into the weeds, leading to the RCU stalls and
> NMI lockup warnings.

[...]

> I'll have a go with lock debugging.

FWIW, with lock debugging I get the below splat before reaching userspace.

[    0.145869] =================================
[    0.145901] [ INFO: inconsistent lock state ]
[    0.145935] 4.5.0-rc1+ #8 Not tainted
[    0.145964] ---------------------------------
[    0.145996] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[    0.146036] swapper/5/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[    0.146070]  (vmap_area_lock){+.?...}, at: [<ffffffc0001a749c>] find_vmap_area+0x1c/0x98
[    0.146151] {SOFTIRQ-ON-W} state was registered at:
[    0.146184]   [<ffffffc0000fc2ac>] mark_lock+0x1bc/0x708
[    0.146229]   [<ffffffc0000feb18>] __lock_acquire+0x928/0x1d90
[    0.146274]   [<ffffffc00010032c>] lock_acquire+0x9c/0xe0
[    0.146318]   [<ffffffc0006c8cd8>] _raw_spin_lock+0x40/0x58
[    0.146362]   [<ffffffc0001a749c>] find_vmap_area+0x1c/0x98
[    0.146406]   [<ffffffc0001a9c6c>] find_vm_area+0xc/0x38
[    0.146447]   [<ffffffc000096420>] change_memory_common+0x38/0x120
[    0.146495]   [<ffffffc0000965dc>] __kernel_map_pages+0x54/0x60
[    0.146537]   [<ffffffc000176744>] get_page_from_freelist+0x86c/0x9a0
[    0.146584]   [<ffffffc000176b98>] __alloc_pages_nodemask+0xf0/0x8a0
[    0.146629]   [<ffffffc0009dd46c>] alloc_pages_exact_nid+0x48/0x90
[    0.146675]   [<ffffffc0009b8004>] page_ext_init+0x94/0x124
[    0.146718]   [<ffffffc0009a390c>] start_kernel+0x350/0x3d4
[    0.146761]   [<ffffffc0000811b4>] 0xffffffc0000811b4
[    0.146802] irq event stamp: 402
[    0.146830] hardirqs last  enabled at (402): [<ffffffc000172c58>] free_pages_prepare+0x270/0x330
[    0.146894] hardirqs last disabled at (401): [<ffffffc000172c58>] free_pages_prepare+0x270/0x330
[    0.146956] softirqs last  enabled at (368): [<ffffffc0000bc070>] _local_bh_enable+0x20/0x48
[    0.147022] softirqs last disabled at (369): [<ffffffc0000bca10>] irq_exit+0xa0/0xd8
[    0.147081] 
[    0.147081] other info that might help us debug this:
[    0.147130]  Possible unsafe locking scenario:
[    0.147130] 
[    0.147177]        CPU0
[    0.147201]        ----
[    0.147225]   lock(vmap_area_lock);
[    0.147260]   <Interrupt>
[    0.147285]     lock(vmap_area_lock);
[    0.147321] 
[    0.147321]  *** DEADLOCK ***
[    0.147321] 
[    0.147381] 1 lock held by swapper/5/0:
[    0.147410]  #0:  (rcu_callback){......}, at: [<ffffffc0001193f0>] rcu_process_callbacks+0x2b8/0x5f8
[    0.147492] 
[    0.147492] stack backtrace:
[    0.147538] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.5.0-rc1+ #8
[    0.147577] Hardware name: ARM Juno development board (r0) (DT)
[    0.147613] Call trace:
[    0.147644] [<ffffffc000089a38>] dump_backtrace+0x0/0x180
[    0.147684] [<ffffffc000089bcc>] show_stack+0x14/0x20
[    0.147724] [<ffffffc000373bb8>] dump_stack+0x90/0xc8
[    0.147764] [<ffffffc00016bb3c>] print_usage_bug.part.21+0x260/0x278
[    0.147807] [<ffffffc0000fc238>] mark_lock+0x148/0x708
[    0.147846] [<ffffffc0000feadc>] __lock_acquire+0x8ec/0x1d90
[    0.147887] [<ffffffc00010032c>] lock_acquire+0x9c/0xe0
[    0.147925] [<ffffffc0006c8cd8>] _raw_spin_lock+0x40/0x58
[    0.147965] [<ffffffc0001a749c>] find_vmap_area+0x1c/0x98
[    0.148003] [<ffffffc0001a9c6c>] find_vm_area+0xc/0x38
[    0.148044] [<ffffffc000096420>] change_memory_common+0x38/0x120
[    0.148084] [<ffffffc0000965c8>] __kernel_map_pages+0x40/0x60
[    0.148123] [<ffffffc000172cb8>] free_pages_prepare+0x2d0/0x330
[    0.148164] [<ffffffc000174660>] __free_pages_ok+0x20/0x108
[    0.148203] [<ffffffc0001750e0>] __free_pages+0x30/0x50
[    0.148241] [<ffffffc0001753ac>] __free_kmem_pages+0x24/0x50
[    0.148280] [<ffffffc000175410>] free_kmem_pages+0x38/0x40
[    0.148320] [<ffffffc0000b5908>] free_task+0x30/0x60
[    0.148359] [<ffffffc0000b59f8>] __put_task_struct+0xc0/0x110
[    0.148400] [<ffffffc0000b91bc>] delayed_put_task_struct+0x44/0x50
[    0.148442] [<ffffffc000119430>] rcu_process_callbacks+0x2f8/0x5f8
[    0.148482] [<ffffffc0000bc594>] __do_softirq+0x13c/0x278
[    0.148520] [<ffffffc0000bca10>] irq_exit+0xa0/0xd8
[    0.148559] [<ffffffc00010ad90>] __handle_domain_irq+0x60/0xb8
[    0.148599] [<ffffffc0000824f0>] gic_handle_irq+0x58/0xa8
[    0.148636] Exception stack(0xffffffc97594be30 to 0xffffffc97594bf50)
[    0.148678] be20:                                   ffffffc975933f00 0000000000000243
[    0.148734] be40: 000000097e4a7000 0000000000000000 0000000000000000 0000000000000008
[    0.148791] be60: 00000007de290000 00000000000270f0 0000000000000001 ffffffc975948000
[    0.148848] be80: ffffffc00179e000 0000000000000000 ffffffc001507000 ffffffc001507f00
[    0.148903] bea0: 000000000000000e 0000000000000007 0000000000000001 0000000000000007
[    0.148960] bec0: 000000000000000e ffffffc000a5a000 ffffffc975948000 ffffffc000a5a000
[    0.149017] bee0: ffffffc000a38c40 ffffffc000a3c460 ffffffc975948000 ffffffc000a5a000
[    0.149073] bf00: ffffffc000af6000 0000000000000000 0000000000000000 ffffffc97594bf50
[    0.149130] bf20: ffffffc0000867e0 ffffffc97594bf50 ffffffc0000867e4 0000000060000045
[    0.149185] bf40: ffffffc97594bf50 ffffffc0000867e0
[    0.149222] [<ffffffc0000855e4>] el1_irq+0xa4/0x114
[    0.149260] [<ffffffc0000867e4>] arch_cpu_idle+0x14/0x20
[    0.149299] [<ffffffc0000f7878>] default_idle_call+0x18/0x30
[    0.149339] [<ffffffc0000f7a78>] cpu_startup_entry+0x1e8/0x240
[    0.149380] [<ffffffc00008f064>] secondary_start_kernel+0x16c/0x198
[    0.149419] [<00000000800827fc>] 0x800827fc

The kernel then happily ran userspace for a while, but running hackbench
was sufficient to lock it up:

[  132.624028] BUG: spinlock lockup suspected on CPU#4, hackbench/5589
[  132.624600] BUG: spinlock lockup suspected on CPU#5, hackbench/5270
[  132.624619]  lock: vmap_area_lock+0x0/0x38, .magic: dead4ead, .owner: hackbench/7089, .owner_cpu: 1
[  132.626651] BUG: spinlock lockup suspected on CPU#3, hackbench/5280
[  132.626663]  lock: vmap_area_lock+0x0/0x38, .magic: dead4ead, .owner: hackbench/7089, .owner_cpu: 1
[  132.628358] BUG: spinlock lockup suspected on CPU#0, init/1
[  132.628370]  lock: vmap_area_lock+0x0/0x38, .magic: dead4ead, .owner: hackbench/7089, .owner_cpu: 1
[  132.675602]  lock: vmap_area_lock+0x0/0x38, .magic: dead4ead, .owner: hackbench/7089, .owner_cpu: 1
[  136.619403] BUG: spinlock lockup suspected on CPU#2, hackbench/6768
[  136.625640]  lock: vmap_area_lock+0x0/0x38, .magic: dead4ead, .owner: hackbench/7089, .owner_cpu: 1
[  136.675626] BUG: spinlock lockup suspected on CPU#1, hackbench/7089
[  136.681860]  lock: vmap_area_lock+0x0/0x38, .magic: dead4ead, .owner: hackbench/7089, .owner_cpu: 1
[  152.689601] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [hackbench:7089]
[  155.149604] INFO: rcu_preempt self-detected stall on CPU
[  155.149609] INFO: rcu_preempt self-detected stall on CPU
[  155.149611] INFO: rcu_preempt self-detected stall on CPU
[  155.149625]  1-...: (6496 ticks this GP) idle=fef/140000000000002/0 softirq=1935/1935 fqs=1 
[  155.149639]  
[  155.149640]  4-...: (6493 ticks this GP) idle=305/140000000000002/0 softirq=1961/1961 fqs=1 
[  155.149650]  
[  155.149651] rcu_preempt kthread starved for 6499 jiffies! g1204 c1203 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
[  155.149665] rcu_preempt kthread starved for 6499 jiffies! g1204 c1203 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
[  155.205127]  0-...: (6498 ticks this GP) idle=a2d/140000000000002/0 softirq=2595/2595 fqs=1 
[  155.213526]   (t=6516 jiffies g=1204 c=1203 q=422)
[  155.218307] rcu_preempt kthread starved for 6516 jiffies! g1204 c1203 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
[  156.677602] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [init:1]
[  156.701602] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [hackbench:6768]
[  156.713603] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [hackbench:5280]
[  156.725602] NMI watchdog: BUG: soft lockup - CPU#4 stuck for 22s! [hackbench:5589]
[  156.737603] NMI watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [hackbench:5270]

Thanks,
Mark.


From jonathanh at nvidia.com  Tue Feb  2 04:36:15 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Tue, 2 Feb 2016 12:36:15 +0000
Subject: Tegra baseline test results for v4.5-rc2
Message-ID: <56B0A2BF.5050301@nvidia.com>

Here are some basic Tegra test results for Linux v4.5-rc2.
Logs and other details at:

    https://nvtb.github.io//linux/test_v4.5-rc2/20160131183102/


Test summary
------------

Build: zImage:
    Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig

Build: Image:
    Pass: ( 1/ 1): defconfig

Boot to userspace: defconfig:
    Pass: ( 2/ 2): qemu-vexpress64, tegra210-p2371-0000

Boot to userspace: multi_v7_defconfig:
    Pass: ( 4/ 4): tegra114-dalmore-a04, tegra124-jetson-tk1,
		   tegra20-trimslice, tegra30-beaver

Boot to userspace: tegra_defconfig:
    Pass: ( 4/ 4): tegra114-dalmore-a04, tegra124-jetson-tk1,
		   tegra20-trimslice, tegra30-beaver

PM: System suspend: multi_v7_defconfig:
    Pass: ( 4/ 4): tegra114-dalmore-a04, tegra124-jetson-tk1,
		   tegra20-trimslice, tegra30-beaver

PM: System suspend: tegra_defconfig:
    Pass: ( 4/ 4): tegra114-dalmore-a04, tegra124-jetson-tk1,
		   tegra20-trimslice, tegra30-beaver


vmlinux object size
(delta in bytes from test_v4.5-rc1 (92e963f50fc74041b5e9e744c330dca48e04f08d)):
   text     data      bss    total  kernel
+750723   +22368   +19968  +793059  defconfig
   +640     +128        0     +768  multi_v7_defconfig
   +475     +120        0     +595  tegra_defconfig


Boot-time memory difference
(delta in bytes from test_v4.5-rc1 (92e963f50fc74041b5e9e744c330dca48e04f08d))
    avail    rsrvd     high    freed                board              kconfig                  dtb
        .        .        .        .      qemu-vexpress64            defconfig           __internal
        .        .        .        . tegra114-dalmore-a04   multi_v7_defconfig     tegra114-dalmore
        .        .        .        . tegra114-dalmore-a04      tegra_defconfig     tegra114-dalmore
        .        .        .        .  tegra124-jetson-tk1   multi_v7_defconfig  tegra124-jetson-tk1
        .        .        .        .  tegra124-jetson-tk1      tegra_defconfig  tegra124-jetson-tk1
        .        .        .        .    tegra20-trimslice   multi_v7_defconfig    tegra20-trimslice
        .        .        .        .    tegra20-trimslice      tegra_defconfig    tegra20-trimslice
        .        .        .        .  tegra210-p2371-0000            defconfig  tegra210-p2371-0000
        .        .        .        .       tegra30-beaver   multi_v7_defconfig       tegra30-beaver
        .        .        .        .       tegra30-beaver      tegra_defconfig       tegra30-beaver


From peter.ujfalusi at ti.com  Tue Feb  2 04:43:12 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 2 Feb 2016 14:43:12 +0200
Subject: [PATCH 0/5] ARM: davinci: Add dma_slave_map to board files
Message-ID: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>

Hi,

The following series adds the dma_slave map to the edma driver. The
dma_slave_map is needed later when we convert drivers to use the new dmaengine
API for requesting slave channels.

Regards,
Peter
---
Peter Ujfalusi (5):
  ARM: davinci: devices-da8xx: Add dma_slave_map to edma
  ARM: davinci: dm355: Add dma_slave_map to edma
  ARM: davinci: dm365: Add dma_slave_map to edma
  ARM: davinci: dm644x: Add dma_slave_map to edma
  ARM: davinci: dm646x: Add dma_slave_map to edma

 arch/arm/mach-davinci/devices-da8xx.c | 46 +++++++++++++++++++++++++++++++++++
 arch/arm/mach-davinci/dm355.c         | 20 +++++++++++++++
 arch/arm/mach-davinci/dm365.c         | 22 +++++++++++++++++
 arch/arm/mach-davinci/dm644x.c        | 12 +++++++++
 arch/arm/mach-davinci/dm646x.c        | 11 +++++++++
 5 files changed, 111 insertions(+)

-- 
2.7.0



From peter.ujfalusi at ti.com  Tue Feb  2 04:43:14 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 2 Feb 2016 14:43:14 +0200
Subject: [PATCH 2/5] ARM: davinci: dm355: Add dma_slave_map to edma
In-Reply-To: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>
References: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1454416997-14230-3-git-send-email-peter.ujfalusi@ti.com>

Provide the dma_slave_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>

FIX: dm355
---
 arch/arm/mach-davinci/dm355.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index c7c1458df23c..092ca1e30e98 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -13,6 +13,7 @@
 #include <linux/serial_8250.h>
 #include <linux/platform_device.h>
 #include <linux/dma-mapping.h>
+#include <linux/dmaengine.h>
 #include <linux/spi/spi.h>
 #include <linux/platform_data/edma.h>
 #include <linux/platform_data/gpio-davinci.h>
@@ -576,9 +577,28 @@ static s8 queue_priority_mapping[][2] = {
 	{-1, -1},
 };
 
+static const struct dma_slave_map da355_edma_map[] = {
+	{ "davinci-mcbsp.0", "tx", EDMA_FILTER_PARAM(0, 2) },
+	{ "davinci-mcbsp.0", "rx", EDMA_FILTER_PARAM(0, 3) },
+	{ "davinci-mcbsp.1", "tx", EDMA_FILTER_PARAM(0, 8) },
+	{ "davinci-mcbsp.1", "rx", EDMA_FILTER_PARAM(0, 9) },
+	{ "spi_davinci.2", "tx", EDMA_FILTER_PARAM(0, 10) },
+	{ "spi_davinci.2", "rx", EDMA_FILTER_PARAM(0, 11) },
+	{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 14) },
+	{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 15) },
+	{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 16) },
+	{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 17) },
+	{ "dm6441-mmc.0", "rx", EDMA_FILTER_PARAM(0, 26) },
+	{ "dm6441-mmc.0", "tx", EDMA_FILTER_PARAM(0, 27) },
+	{ "dm6441-mmc.1", "rx", EDMA_FILTER_PARAM(0, 30) },
+	{ "dm6441-mmc.1", "tx", EDMA_FILTER_PARAM(0, 31) },
+};
+
 static struct edma_soc_info dm355_edma_pdata = {
 	.queue_priority_mapping	= queue_priority_mapping,
 	.default_queue		= EVENTQ_1,
+	.slave_map		= da355_edma_map,
+	.slavecnt		= ARRAY_SIZE(da355_edma_map),
 };
 
 static struct resource edma_resources[] = {
-- 
2.7.0



From peter.ujfalusi at ti.com  Tue Feb  2 04:43:13 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 2 Feb 2016 14:43:13 +0200
Subject: [PATCH 1/5] ARM: davinci: devices-da8xx: Add dma_slave_map to edma
In-Reply-To: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>
References: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1454416997-14230-2-git-send-email-peter.ujfalusi@ti.com>

Provide the dma_slave_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/mach-davinci/devices-da8xx.c | 46 +++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index e88b7a5cde99..07b8c97466d1 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -17,6 +17,7 @@
 #include <linux/ahci_platform.h>
 #include <linux/clk.h>
 #include <linux/reboot.h>
+#include <linux/dmaengine.h>
 
 #include <mach/cputype.h>
 #include <mach/common.h>
@@ -233,16 +234,54 @@ static const struct platform_device_info da850_edma1_device __initconst = {
 	.size_data	= sizeof(da850_edma1_pdata),
 };
 
+static const struct dma_slave_map da830_edma_map[] = {
+	{ "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
+	{ "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
+	{ "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
+	{ "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
+	{ "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
+	{ "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
+	{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
+	{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
+	{ "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
+	{ "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
+	{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
+	{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
+};
+
 int __init da830_register_edma(struct edma_rsv_info *rsv)
 {
 	struct platform_device *edma_pdev;
 
 	da8xx_edma0_pdata.rsv = rsv;
 
+	da8xx_edma0_pdata.slave_map = da830_edma_map;
+	da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);
+
 	edma_pdev = platform_device_register_full(&da8xx_edma0_device);
 	return IS_ERR(edma_pdev) ? PTR_ERR(edma_pdev) : 0;
 }
 
+static const struct dma_slave_map da850_edma0_map[] = {
+	{ "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
+	{ "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
+	{ "davinci-mcbsp.0", "rx", EDMA_FILTER_PARAM(0, 2) },
+	{ "davinci-mcbsp.0", "tx", EDMA_FILTER_PARAM(0, 3) },
+	{ "davinci-mcbsp.1", "rx", EDMA_FILTER_PARAM(0, 4) },
+	{ "davinci-mcbsp.1", "tx", EDMA_FILTER_PARAM(0, 5) },
+	{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
+	{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
+	{ "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
+	{ "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
+	{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
+	{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
+};
+
+static const struct dma_slave_map da850_edma1_map[] = {
+	{ "da830-mmc.1", "rx", EDMA_FILTER_PARAM(0, 28) },
+	{ "da830-mmc.1", "tx", EDMA_FILTER_PARAM(0, 29) },
+};
+
 int __init da850_register_edma(struct edma_rsv_info *rsv[2])
 {
 	struct platform_device *edma_pdev;
@@ -252,11 +291,18 @@ int __init da850_register_edma(struct edma_rsv_info *rsv[2])
 		da850_edma1_pdata.rsv = rsv[1];
 	}
 
+	da8xx_edma0_pdata.slave_map = da850_edma0_map;
+	da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da850_edma0_map);
+
 	edma_pdev = platform_device_register_full(&da8xx_edma0_device);
 	if (IS_ERR(edma_pdev)) {
 		pr_warn("%s: Failed to register eDMA0\n", __func__);
 		return PTR_ERR(edma_pdev);
 	}
+
+	da850_edma1_pdata.slave_map = da850_edma1_map;
+	da850_edma1_pdata.slavecnt = ARRAY_SIZE(da850_edma1_map);
+
 	edma_pdev = platform_device_register_full(&da850_edma1_device);
 	return IS_ERR(edma_pdev) ? PTR_ERR(edma_pdev) : 0;
 }
-- 
2.7.0



From peter.ujfalusi at ti.com  Tue Feb  2 04:43:16 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 2 Feb 2016 14:43:16 +0200
Subject: [PATCH 4/5] ARM: davinci: dm644x: Add dma_slave_map to edma
In-Reply-To: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>
References: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1454416997-14230-5-git-send-email-peter.ujfalusi@ti.com>

Provide the dma_slave_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>

FIX: dm646x
---
 arch/arm/mach-davinci/dm644x.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index b28071ae3a57..5ccd8bda96aa 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -11,6 +11,7 @@
 #include <linux/init.h>
 #include <linux/clk.h>
 #include <linux/serial_8250.h>
+#include <linux/dmaengine.h>
 #include <linux/platform_device.h>
 #include <linux/platform_data/edma.h>
 #include <linux/platform_data/gpio-davinci.h>
@@ -505,9 +506,20 @@ static s8 queue_priority_mapping[][2] = {
 	{-1, -1},
 };
 
+static const struct dma_slave_map da644x_edma_map[] = {
+	{ "davinci-mcbsp", "tx", EDMA_FILTER_PARAM(0, 2) },
+	{ "davinci-mcbsp", "rx", EDMA_FILTER_PARAM(0, 3) },
+	{ "spi_davinci", "tx", EDMA_FILTER_PARAM(0, 16) },
+	{ "spi_davinci", "rx", EDMA_FILTER_PARAM(0, 17) },
+	{ "dm6441-mmc.0", "rx", EDMA_FILTER_PARAM(0, 26) },
+	{ "dm6441-mmc.0", "tx", EDMA_FILTER_PARAM(0, 27) },
+};
+
 static struct edma_soc_info dm644x_edma_pdata = {
 	.queue_priority_mapping	= queue_priority_mapping,
 	.default_queue		= EVENTQ_1,
+	.slave_map		= da644x_edma_map,
+	.slavecnt		= ARRAY_SIZE(da644x_edma_map),
 };
 
 static struct resource edma_resources[] = {
-- 
2.7.0



From peter.ujfalusi at ti.com  Tue Feb  2 04:43:17 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 2 Feb 2016 14:43:17 +0200
Subject: [PATCH 5/5] ARM: davinci: dm646x: Add dma_slave_map to edma
In-Reply-To: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>
References: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1454416997-14230-6-git-send-email-peter.ujfalusi@ti.com>

Provide the dma_slave_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>

FIX: dm646x
---
 arch/arm/mach-davinci/dm646x.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index cf80786e2471..93395f28caaa 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -9,6 +9,7 @@
  * or implied.
  */
 #include <linux/dma-mapping.h>
+#include <linux/dmaengine.h>
 #include <linux/init.h>
 #include <linux/clk.h>
 #include <linux/serial_8250.h>
@@ -540,9 +541,19 @@ static s8 dm646x_queue_priority_mapping[][2] = {
 	{-1, -1},
 };
 
+static const struct dma_slave_map da646x_edma_map[] = {
+	{ "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 6) },
+	{ "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 9) },
+	{ "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 12) },
+	{ "spi_davinci", "tx", EDMA_FILTER_PARAM(0, 16) },
+	{ "spi_davinci", "rx", EDMA_FILTER_PARAM(0, 17) },
+};
+
 static struct edma_soc_info dm646x_edma_pdata = {
 	.queue_priority_mapping	= dm646x_queue_priority_mapping,
 	.default_queue		= EVENTQ_1,
+	.slave_map		= da646x_edma_map,
+	.slavecnt		= ARRAY_SIZE(da646x_edma_map),
 };
 
 static struct resource edma_resources[] = {
-- 
2.7.0



From peter.ujfalusi at ti.com  Tue Feb  2 04:43:15 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 2 Feb 2016 14:43:15 +0200
Subject: [PATCH 3/5] ARM: davinci: dm365: Add dma_slave_map to edma
In-Reply-To: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>
References: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1454416997-14230-4-git-send-email-peter.ujfalusi@ti.com>

Provide the dma_slave_map to edma which will allow us to move the drivers
to the new, simpler dmaengine API and we can remove the DMA resources also
for the devices.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>

FIX: dm365
---
 arch/arm/mach-davinci/dm365.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 01843fbcc9ea..d26dc2b4339a 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -17,6 +17,7 @@
 #include <linux/serial_8250.h>
 #include <linux/platform_device.h>
 #include <linux/dma-mapping.h>
+#include <linux/dmaengine.h>
 #include <linux/spi/spi.h>
 #include <linux/platform_data/edma.h>
 #include <linux/platform_data/gpio-davinci.h>
@@ -862,9 +863,30 @@ static s8 dm365_queue_priority_mapping[][2] = {
 	{-1, -1},
 };
 
+static const struct dma_slave_map da365_edma_map[] = {
+	{ "davinci-mcbsp.0", "tx", EDMA_FILTER_PARAM(0, 2) },
+	{ "davinci-mcbsp.0", "rx", EDMA_FILTER_PARAM(0, 3) },
+	{ "davinci_voicecodec", "tx", EDMA_FILTER_PARAM(0, 2) },
+	{ "davinci_voicecodec", "rx", EDMA_FILTER_PARAM(0, 3) },
+	{ "spi_davinci.2", "tx", EDMA_FILTER_PARAM(0, 10) },
+	{ "spi_davinci.2", "rx", EDMA_FILTER_PARAM(0, 11) },
+	{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 14) },
+	{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 15) },
+	{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 16) },
+	{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 17) },
+	{ "spi_davinci.3", "tx", EDMA_FILTER_PARAM(0, 18) },
+	{ "spi_davinci.3", "rx", EDMA_FILTER_PARAM(0, 19) },
+	{ "dm6441-mmc.0", "rx", EDMA_FILTER_PARAM(0, 26) },
+	{ "dm6441-mmc.0", "tx", EDMA_FILTER_PARAM(0, 27) },
+	{ "dm6441-mmc.1", "rx", EDMA_FILTER_PARAM(0, 30) },
+	{ "dm6441-mmc.1", "tx", EDMA_FILTER_PARAM(0, 31) },
+};
+
 static struct edma_soc_info dm365_edma_pdata = {
 	.queue_priority_mapping	= dm365_queue_priority_mapping,
 	.default_queue		= EVENTQ_3,
+	.slave_map		= da365_edma_map,
+	.slavecnt		= ARRAY_SIZE(da365_edma_map),
 };
 
 static struct resource edma_resources[] = {
-- 
2.7.0



From will.deacon at arm.com  Tue Feb  2 04:46:24 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue,  2 Feb 2016 12:46:24 +0000
Subject: [PATCH 2/4] arm64: prefetch: add alternative pattern for CPUs without
 a prefetcher
In-Reply-To: <1454417186-21828-1-git-send-email-will.deacon@arm.com>
References: <1454417186-21828-1-git-send-email-will.deacon@arm.com>
Message-ID: <1454417186-21828-3-git-send-email-will.deacon@arm.com>

Most CPUs have a hardware prefetcher which generally performs better
without explicit prefetch instructions issued by software, however
some CPUs (e.g. Cavium ThunderX) rely solely on explicit prefetch
instructions.

This patch adds an alternative pattern (ARM64_HAS_NO_HW_PREFETCH) to
allow our library code to make use of explicit prefetch instructions
during things like copy routines only when the CPU does not have the
capability to perform the prefetching itself.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm64/include/asm/cpufeature.h |  3 ++-
 arch/arm64/include/asm/cputype.h    | 17 ++++++++++++++++-
 arch/arm64/kernel/cpu_errata.c      | 18 +++---------------
 arch/arm64/kernel/cpufeature.c      | 17 +++++++++++++++++
 4 files changed, 38 insertions(+), 17 deletions(-)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 8f271b83f910..8d56bd8550dc 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -30,8 +30,9 @@
 #define ARM64_HAS_LSE_ATOMICS			5
 #define ARM64_WORKAROUND_CAVIUM_23154		6
 #define ARM64_WORKAROUND_834220			7
+#define ARM64_HAS_NO_HW_PREFETCH		8
 
-#define ARM64_NCAPS				8
+#define ARM64_NCAPS				9
 
 #ifndef __ASSEMBLY__
 
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 1a5949364ed0..7540284a17fe 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -57,11 +57,22 @@
 #define MIDR_IMPLEMENTOR(midr)	\
 	(((midr) & MIDR_IMPLEMENTOR_MASK) >> MIDR_IMPLEMENTOR_SHIFT)
 
-#define MIDR_CPU_PART(imp, partnum) \
+#define MIDR_CPU_MODEL(imp, partnum) \
 	(((imp)			<< MIDR_IMPLEMENTOR_SHIFT) | \
 	(0xf			<< MIDR_ARCHITECTURE_SHIFT) | \
 	((partnum)		<< MIDR_PARTNUM_SHIFT))
 
+#define MIDR_CPU_MODEL_MASK (MIDR_IMPLEMENTOR_MASK | MIDR_PARTNUM_MASK | \
+			     MIDR_ARCHITECTURE_MASK)
+
+#define MIDR_IS_CPU_MODEL_RANGE(midr, model, rv_min, rv_max)		\
+({									\
+	u32 _model = (midr) & MIDR_CPU_MODEL_MASK;			\
+	u32 rv = (midr) & (MIDR_REVISION_MASK | MIDR_VARIANT_MASK);	\
+									\
+	_model == (model) && rv >= (rv_min) && rv <= (rv_max);		\
+ })
+
 #define ARM_CPU_IMP_ARM			0x41
 #define ARM_CPU_IMP_APM			0x50
 #define ARM_CPU_IMP_CAVIUM		0x43
@@ -75,6 +86,10 @@
 
 #define CAVIUM_CPU_PART_THUNDERX	0x0A1
 
+#define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
+#define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
+#define MIDR_THUNDERX	MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
+
 #ifndef __ASSEMBLY__
 
 /*
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index feb6b4efa641..e6bc988e8dbf 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -21,24 +21,12 @@
 #include <asm/cputype.h>
 #include <asm/cpufeature.h>
 
-#define MIDR_CORTEX_A53 MIDR_CPU_PART(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
-#define MIDR_CORTEX_A57 MIDR_CPU_PART(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
-#define MIDR_THUNDERX	MIDR_CPU_PART(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
-
-#define CPU_MODEL_MASK (MIDR_IMPLEMENTOR_MASK | MIDR_PARTNUM_MASK | \
-			MIDR_ARCHITECTURE_MASK)
-
 static bool __maybe_unused
 is_affected_midr_range(const struct arm64_cpu_capabilities *entry)
 {
-	u32 midr = read_cpuid_id();
-
-	if ((midr & CPU_MODEL_MASK) != entry->midr_model)
-		return false;
-
-	midr &= MIDR_REVISION_MASK | MIDR_VARIANT_MASK;
-
-	return (midr >= entry->midr_range_min && midr <= entry->midr_range_max);
+	return MIDR_IS_CPU_MODEL_RANGE(read_cpuid_id(), entry->midr_model,
+				       entry->midr_range_min,
+				       entry->midr_range_max);
 }
 
 #define MIDR_RANGE(model, min, max) \
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 5c90aa490a2b..3615d7d7c9af 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -621,6 +621,18 @@ static bool has_useable_gicv3_cpuif(const struct arm64_cpu_capabilities *entry)
 	return has_sre;
 }
 
+static bool has_no_hw_prefetch(const struct arm64_cpu_capabilities *entry)
+{
+	u32 midr = read_cpuid_id();
+	u32 rv_min, rv_max;
+
+	/* Cavium ThunderX pass 1.x and 2.x */
+	rv_min = 0;
+	rv_max = (1 << MIDR_VARIANT_SHIFT) | MIDR_REVISION_MASK;
+
+	return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX, rv_min, rv_max);
+}
+
 static const struct arm64_cpu_capabilities arm64_features[] = {
 	{
 		.desc = "GIC system register CPU interface",
@@ -651,6 +663,11 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.min_field_value = 2,
 	},
 #endif /* CONFIG_AS_LSE && CONFIG_ARM64_LSE_ATOMICS */
+	{
+		.desc = "Software prefetching using PRFM",
+		.capability = ARM64_HAS_NO_HW_PREFETCH,
+		.matches = has_no_hw_prefetch,
+	},
 	{},
 };
 
-- 
2.1.4



From will.deacon at arm.com  Tue Feb  2 04:46:22 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue,  2 Feb 2016 12:46:22 +0000
Subject: [PATCH 0/4] copy_page improvements
Message-ID: <1454417186-21828-1-git-send-email-will.deacon@arm.com>

Hi all,

This patch series aims to improve our copy_page implementation on both
CPUs with and without hardware prefetchers. It is inspired by a previous
patch series from Andrew, and one of the patches is lifted directly from
there:

  http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399132.html

Changes from that series:

  * Applies on top of mainline
  * Inverted the capability to the more generic ARM64_HAS_NO_HW_PREFETCH
  * Re-jigged the MIDR detection to try to keep it simple

I've left copy_template alone for now, since the template really deals
with 64 bytes per iteration, which would need changing.

Andrew -- it would be helpful if you could take this for a spin on
ThunderX to make sure it didn't screw anything up.

Cheers,

Will

--->8

Andrew Pinski (1):
  arm64: lib: patch in prfm for copy_page if requested

Will Deacon (3):
  arm64: prefetch: don't provide spin_lock_prefetch with LSE
  arm64: prefetch: add alternative pattern for CPUs without a prefetcher
  arm64: lib: improve copy_page to deal with 128 bytes at a time

 arch/arm64/include/asm/cpufeature.h |  3 +-
 arch/arm64/include/asm/cputype.h    | 17 +++++++++-
 arch/arm64/include/asm/processor.h  |  7 +++--
 arch/arm64/kernel/cpu_errata.c      | 18 ++---------
 arch/arm64/kernel/cpufeature.c      | 17 ++++++++++
 arch/arm64/lib/copy_page.S          | 63 ++++++++++++++++++++++++++++++++-----
 6 files changed, 98 insertions(+), 27 deletions(-)

-- 
2.1.4



From will.deacon at arm.com  Tue Feb  2 04:46:23 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue,  2 Feb 2016 12:46:23 +0000
Subject: [PATCH 1/4] arm64: prefetch: don't provide spin_lock_prefetch with LSE
In-Reply-To: <1454417186-21828-1-git-send-email-will.deacon@arm.com>
References: <1454417186-21828-1-git-send-email-will.deacon@arm.com>
Message-ID: <1454417186-21828-2-git-send-email-will.deacon@arm.com>

The LSE atomics rely on us not dirtying data at L1 if we can avoid it,
otherwise many of the potential scalability benefits are lost.

This patch replaces spin_lock_prefetch with a nop when the LSE atomics
are in use, so that users don't shoot themselves in the foot by causing
needless coherence traffic at L1.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm64/include/asm/processor.h | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 4acb7ca94fcd..31b76fce4477 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -29,6 +29,7 @@
 
 #include <linux/string.h>
 
+#include <asm/alternative.h>
 #include <asm/fpsimd.h>
 #include <asm/hw_breakpoint.h>
 #include <asm/pgtable-hwdef.h>
@@ -177,9 +178,11 @@ static inline void prefetchw(const void *ptr)
 }
 
 #define ARCH_HAS_SPINLOCK_PREFETCH
-static inline void spin_lock_prefetch(const void *x)
+static inline void spin_lock_prefetch(const void *ptr)
 {
-	prefetchw(x);
+	asm volatile(ARM64_LSE_ATOMIC_INSN(
+		     "prfm pstl1strm, %a0",
+		     "nop") : : "p" (ptr));
 }
 
 #define HAVE_ARCH_PICK_MMAP_LAYOUT
-- 
2.1.4



From will.deacon at arm.com  Tue Feb  2 04:46:26 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue,  2 Feb 2016 12:46:26 +0000
Subject: [PATCH 4/4] arm64: lib: patch in prfm for copy_page if requested
In-Reply-To: <1454417186-21828-1-git-send-email-will.deacon@arm.com>
References: <1454417186-21828-1-git-send-email-will.deacon@arm.com>
Message-ID: <1454417186-21828-5-git-send-email-will.deacon@arm.com>

From: Andrew Pinski <apinski at cavium.com>

On ThunderX T88 pass 1 and pass 2, there is no hardware prefetching so
we need to patch in explicit software prefetching instructions

Prefetching improves this code by 60% over the original code and 2x
over the code without prefetching for the affected hardware using the
benchmark code at https://github.com/apinski-cavium/copy_page_benchmark

Signed-off-by: Andrew Pinski <apinski at cavium.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm64/lib/copy_page.S | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/lib/copy_page.S b/arch/arm64/lib/copy_page.S
index 2534533ceb1d..4c1e700840b6 100644
--- a/arch/arm64/lib/copy_page.S
+++ b/arch/arm64/lib/copy_page.S
@@ -18,6 +18,8 @@
 #include <linux/const.h>
 #include <asm/assembler.h>
 #include <asm/page.h>
+#include <asm/cpufeature.h>
+#include <asm/alternative.h>
 
 /*
  * Copy a page from src to dest (both are page aligned)
@@ -27,6 +29,15 @@
  *	x1 - src
  */
 ENTRY(copy_page)
+alternative_if_not ARM64_HAS_NO_HW_PREFETCH
+	nop
+	nop
+alternative_else
+	# Prefetch two cache lines ahead.
+	prfm    pldl1strm, [x1, #128]
+	prfm    pldl1strm, [x1, #256]
+alternative_endif
+
 	ldp	x2, x3, [x1]
 	ldp	x4, x5, [x1, #16]
 	ldp	x6, x7, [x1, #32]
@@ -41,6 +52,12 @@ ENTRY(copy_page)
 1:
 	subs	x18, x18, #128
 
+alternative_if_not ARM64_HAS_NO_HW_PREFETCH
+	nop
+alternative_else
+	prfm    pldl1strm, [x1, #384]
+alternative_endif
+
 	stnp	x2, x3, [x0]
 	ldp	x2, x3, [x1]
 	stnp	x4, x5, [x0, #16]
-- 
2.1.4



From will.deacon at arm.com  Tue Feb  2 04:46:25 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue,  2 Feb 2016 12:46:25 +0000
Subject: [PATCH 3/4] arm64: lib: improve copy_page to deal with 128 bytes at a
 time
In-Reply-To: <1454417186-21828-1-git-send-email-will.deacon@arm.com>
References: <1454417186-21828-1-git-send-email-will.deacon@arm.com>
Message-ID: <1454417186-21828-4-git-send-email-will.deacon@arm.com>

We want to avoid lots of different copy_page implementations, settling
for something that is "good enough" everywhere and hopefully easy to
understand and maintain whilst we're at it.

This patch reworks our copy_page implementation based on discussions
with Cavium on the list and benchmarking on Cortex-A processors so that:

  - The loop is unrolled to copy 128 bytes per iteration

  - The reads are offset so that we read from the next 128-byte block
    in the same iteration that we store the previous block

  - Explicit prefetch instructions are removed for now, since they hurt
    performance on CPUs with hardware prefetching

  - The loop exit condition is calculated at the start of the loop

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm64/lib/copy_page.S | 46 ++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 38 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/lib/copy_page.S b/arch/arm64/lib/copy_page.S
index 512b9a7b980e..2534533ceb1d 100644
--- a/arch/arm64/lib/copy_page.S
+++ b/arch/arm64/lib/copy_page.S
@@ -27,20 +27,50 @@
  *	x1 - src
  */
 ENTRY(copy_page)
-	/* Assume cache line size is 64 bytes. */
-	prfm	pldl1strm, [x1, #64]
-1:	ldp	x2, x3, [x1]
+	ldp	x2, x3, [x1]
 	ldp	x4, x5, [x1, #16]
 	ldp	x6, x7, [x1, #32]
 	ldp	x8, x9, [x1, #48]
-	add	x1, x1, #64
-	prfm	pldl1strm, [x1, #64]
+	ldp	x10, x11, [x1, #64]
+	ldp	x12, x13, [x1, #80]
+	ldp	x14, x15, [x1, #96]
+	ldp	x16, x17, [x1, #112]
+
+	mov	x18, #(PAGE_SIZE - 128)
+	add	x1, x1, #128
+1:
+	subs	x18, x18, #128
+
 	stnp	x2, x3, [x0]
+	ldp	x2, x3, [x1]
 	stnp	x4, x5, [x0, #16]
+	ldp	x4, x5, [x1, #16]
 	stnp	x6, x7, [x0, #32]
+	ldp	x6, x7, [x1, #32]
 	stnp	x8, x9, [x0, #48]
-	add	x0, x0, #64
-	tst	x1, #(PAGE_SIZE - 1)
-	b.ne	1b
+	ldp	x8, x9, [x1, #48]
+	stnp	x10, x11, [x0, #64]
+	ldp	x10, x11, [x1, #64]
+	stnp	x12, x13, [x0, #80]
+	ldp	x12, x13, [x1, #80]
+	stnp	x14, x15, [x0, #96]
+	ldp	x14, x15, [x1, #96]
+	stnp	x16, x17, [x0, #112]
+	ldp	x16, x17, [x1, #112]
+
+	add	x0, x0, #128
+	add	x1, x1, #128
+
+	b.gt	1b
+
+	stnp	x2, x3, [x0]
+	stnp	x4, x5, [x0, #16]
+	stnp	x6, x7, [x0, #32]
+	stnp	x8, x9, [x0, #48]
+	stnp	x10, x11, [x0, #64]
+	stnp	x12, x13, [x0, #80]
+	stnp	x14, x15, [x0, #96]
+	stnp	x16, x17, [x0, #112]
+
 	ret
 ENDPROC(copy_page)
-- 
2.1.4



From arnd at arndb.de  Tue Feb  2 04:49:56 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 02 Feb 2016 13:49:56 +0100
Subject: [PATCH] clk: vt8500: don't return possibly uninitialized data
In-Reply-To: <20160202011545.GG4848@codeaurora.org>
References: <4790407.6zgSQCdsSB@wuerfel> <20160202011545.GG4848@codeaurora.org>
Message-ID: <2210116.QsPesySkh0@wuerfel>

On Monday 01 February 2016 17:15:45 Stephen Boyd wrote:
> My compiler still gets warnings even after this patch is applied.
> 
> drivers/clk/clk-vt8500.c: In function ?wm8750_find_pll_bits?:
> drivers/clk/clk-vt8500.c:509:12: warning: ?best_div2? may be used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/clk/clk-vt8500.c:508:12: warning: ?best_div1? may be used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/clk/clk-vt8500.c:507:14: warning: ?best_mul? may be used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/clk/clk-vt8500.c: In function ?wm8650_find_pll_bits?:
> drivers/clk/clk-vt8500.c:430:12: warning: ?best_div2? may be used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/clk/clk-vt8500.c:429:12: warning: ?best_div1? may be used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/clk/clk-vt8500.c:428:14: warning: ?best_mul? may be used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/clk/clk-vt8500.c: In function ?wm8850_find_pll_bits?:
> drivers/clk/clk-vt8500.c:560:12: warning: ?best_div2? may be used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/clk/clk-vt8500.c:559:12: warning: ?best_div1? may be used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/clk/clk-vt8500.c:558:14: warning: ?best_mul? may be used uninitialized in this function [-Wmaybe-uninitialized]
> 

I see what you mean now. I checked different gcc versions, and with my patch I get
the warnings for 4.6 through 4.9, but not for 5.x.

In general, I tried to only address warnings I still see with newer gcc version,
as they are better about false positives. Do you think it's ok to take the
patch as is then? Otherwise we probably have to add fake initializations which
would shut up the warnings but not help with the code quality.

	Arnd


From horms at verge.net.au  Tue Feb  2 04:52:19 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Feb 2016 13:52:19 +0100
Subject: [PATCH v4 0/7] ARM: dts: r-car: Add BRG support for (H)SCIF
In-Reply-To: <CAMuHMdWjEn6RSLPOYq=zhY_gk6Lx9xTD1x1G+1igoDr=3h1R5w@mail.gmail.com>
References: <1454061883-4043-1-git-send-email-geert+renesas@glider.be>
 <20160202102031.GD15554@verge.net.au>
 <CAMuHMdWjEn6RSLPOYq=zhY_gk6Lx9xTD1x1G+1igoDr=3h1R5w@mail.gmail.com>
Message-ID: <20160202125213.GH15554@verge.net.au>

On Tue, Feb 02, 2016 at 11:38:05AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Tue, Feb 2, 2016 at 11:20 AM, Simon Horman <horms at verge.net.au> wrote:
> > On Fri, Jan 29, 2016 at 11:04:36AM +0100, Geert Uytterhoeven wrote:
> >> This patch series adds support for the Baud Rate Generator for External
> >> Clock (BRG), as found on SCIF and HSCIF, to the DTS files for all R-Car
> >> Gen1, Gen2, and Gen3 SoCs. This increases the range and accuracy of
> >> supported baud rates on (H)SCIF.
> >>
> >> Support for the extra clocks in the DT bindings and in the driver has
> >> been accepted in v4.5-rc1.
> >>
> >> Changes compared to v3:
> >>   - Change one-line summary prefix to match current arm-soc practices,
> >>   - Rebased,
> >>
> >> Changes compared to v2:
> >>   - Rename "int_clk" to "brg_int",
> >>   - Add support for R-Car M1A (r8a7778) and R-Car H1 (r8a7779),
> >>   - Add support for R-Car H2 (r8a7790), R-Car M2-N (r8a7793), and R-Car
> >>     E2 (r8a7794),
> >>   - Correct internal clock source ZS_CLK to S3D1 in patch description
> >>     for r8a7795,
> >>
> >> This has been tested on r8a7778/bockw, r8a7779/marzen, r8a7791/koelsch,
> >> r8a7794/alt, and r8a7795/salvator-x.
> >>
> >> Dependencies:
> >>   - renesas-devel-20160129-v4.5-rc1,
> >>   - series "[PATCH v4 0/7] ARM: dts: R-Car: Add SCIF fallback
> >>     compatibility strings",
> >>   - series "[PATCH v4 00/11] ARM: dts: shmobile: Rename the serial port
> >>     clock to fck",
> >>
> >> Thanks for applying!
> >
> > Is it safe to apply this in the light of the dependency on
> > renesas-devel-20160129-v4.5-rc1?
> 
> The dependency here (also for the other series) just means I rebased the
> series on top of renesas-devel-20160129-v4.5-rc1 + the mentioned
> series.
> 
> Do you have any DT changes there that are not queued for v4.6?

No, I don't think so.


From u.kleine-koenig at pengutronix.de  Tue Feb  2 04:56:02 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Tue, 2 Feb 2016 13:56:02 +0100
Subject: [PATCH v2 0/3] Input: rotary-encoder - use more than two gpios
In-Reply-To: <56B09C27.8070009@zonque.org>
References: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <56B09C27.8070009@zonque.org>
Message-ID: <20160202125602.GW13664@pengutronix.de>

Hello Daniel,

On Tue, Feb 02, 2016 at 01:08:07PM +0100, Daniel Mack wrote:
> On 02/02/2016 11:24 AM, Uwe Kleine-K?nig wrote:
> > Some time ago I sent a v1 of this, now after testing the changes more
> > deeply patch 3 changed a bit. The old series started with
> > 
> > 	Date: Wed,  2 Dec 2015 11:07:11 +0100
> > 	From: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> > 	Subject: [PATCH RFC 0/3] input: rotary_encoder: use more than two gpios as input
> > 	Message-Id: <1449050834-31779-1-git-send-email-u.kleine-koenig at pengutronix.de>
> > 
> > The two first patches are just preparation for the third patch.
> > 
> > There is an obvious improvement that allows detection of quick changes
> > more reliably with >2 gpios, but I didn't implement this yet. (With 4
> > GPIOs you can distinguish a counter clockwise movement of three states
> > from a clock wise movement of a single state. Still the patch is useful
> > as it makes these devices work at all.
> > 
> > My test device looks as follows:
> > 
> >         rotary at 0 {
> >                 compatible = "rotary-encoder";
> >                 gpios = <&gpio4 12 GPIO_ACTIVE_HIGH>, <&gpio4 11 GPIO_ACTIVE_HIGH>, <&gpio4 10 GPIO_ACTIVE_HIGH>, <&gpio4 9 GPIO_ACTIVE_HIGH>;
> > 
> >                 rotary-encoder,steps = <16>;
> > 		rotary-encoder,steps-per-period = <16>;
> >         };
> > 
> > While Daniel Mack and Rojhalat Ibrahim agreed that this device is an
> > absolute encoder and should be supported by a simpler logic, I still
> > consider it worthwhile to get these patches in as a first step. Also the
> > binding looks right, so IMHO the comments shouldn't stop this series
> > from going in.
> 
> I still don't understand why this is implemented that way, rather than
> going for a much simpler logic of interpretation that also allows users
> to read out the absolute position.
> 
> The code to read the value would be really just as simple as reading all
> GPIOs and or-ing their values into the result, and skip the state
> machine completely. This code would be active if a new attribute
> (something like 'rotary-encoder,hardware-absolute') is set, or even
> implicitly, when more than 2 GPIOs are specified.
> 
> Is there any reason for not doing that?

Currently the reason is lack of time. And when implementing
rotary-encoder,hardware-absolute something similar would be the result
for the relative reporting anyhow. So the problem is only that I don't
have absolute support yet, but the patches as is would be the base for
that anyhow.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From horms at verge.net.au  Tue Feb  2 04:57:50 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Feb 2016 13:57:50 +0100
Subject: [PATCH v4 0/7] ARM: dts: r-car: Add BRG support for (H)SCIF
In-Reply-To: <CAMuHMdWjEn6RSLPOYq=zhY_gk6Lx9xTD1x1G+1igoDr=3h1R5w@mail.gmail.com>
References: <1454061883-4043-1-git-send-email-geert+renesas@glider.be>
 <20160202102031.GD15554@verge.net.au>
 <CAMuHMdWjEn6RSLPOYq=zhY_gk6Lx9xTD1x1G+1igoDr=3h1R5w@mail.gmail.com>
Message-ID: <20160202125749.GI15554@verge.net.au>

On Tue, Feb 02, 2016 at 11:38:05AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Tue, Feb 2, 2016 at 11:20 AM, Simon Horman <horms at verge.net.au> wrote:
> > On Fri, Jan 29, 2016 at 11:04:36AM +0100, Geert Uytterhoeven wrote:
> >> This patch series adds support for the Baud Rate Generator for External
> >> Clock (BRG), as found on SCIF and HSCIF, to the DTS files for all R-Car
> >> Gen1, Gen2, and Gen3 SoCs. This increases the range and accuracy of
> >> supported baud rates on (H)SCIF.
> >>
> >> Support for the extra clocks in the DT bindings and in the driver has
> >> been accepted in v4.5-rc1.
> >>
> >> Changes compared to v3:
> >>   - Change one-line summary prefix to match current arm-soc practices,
> >>   - Rebased,
> >>
> >> Changes compared to v2:
> >>   - Rename "int_clk" to "brg_int",
> >>   - Add support for R-Car M1A (r8a7778) and R-Car H1 (r8a7779),
> >>   - Add support for R-Car H2 (r8a7790), R-Car M2-N (r8a7793), and R-Car
> >>     E2 (r8a7794),
> >>   - Correct internal clock source ZS_CLK to S3D1 in patch description
> >>     for r8a7795,
> >>
> >> This has been tested on r8a7778/bockw, r8a7779/marzen, r8a7791/koelsch,
> >> r8a7794/alt, and r8a7795/salvator-x.
> >>
> >> Dependencies:
> >>   - renesas-devel-20160129-v4.5-rc1,
> >>   - series "[PATCH v4 0/7] ARM: dts: R-Car: Add SCIF fallback
> >>     compatibility strings",
> >>   - series "[PATCH v4 00/11] ARM: dts: shmobile: Rename the serial port
> >>     clock to fck",
> >>
> >> Thanks for applying!
> >
> > Is it safe to apply this in the light of the dependency on
> > renesas-devel-20160129-v4.5-rc1?
> 
> The dependency here (also for the other series) just means I rebased the
> series on top of renesas-devel-20160129-v4.5-rc1 + the mentioned
> series.

Thanks, I have queued these up.

> Do you have any DT changes there that are not queued for v4.6?
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds


From u.kleine-koenig at pengutronix.de  Tue Feb  2 05:00:22 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Tue, 2 Feb 2016 14:00:22 +0100
Subject: [PATCH v2 1/3] Input: rotary-encoder - make use of devm_* to
 simplify .probe and .remove
In-Reply-To: <56B09968.9050705@zonque.org>
References: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <1454408678-6011-2-git-send-email-u.kleine-koenig@pengutronix.de>
 <56B09968.9050705@zonque.org>
Message-ID: <20160202130022.GX13664@pengutronix.de>

On Tue, Feb 02, 2016 at 12:56:24PM +0100, Daniel Mack wrote:
> On 02/02/2016 11:24 AM, Uwe Kleine-K?nig wrote:
> > For all operations called in .probe there are devm_* variants.
> > (input_register_device is clever enough to be devm aware on its own.)
> > This allows to get rid of the error unwind code paths in .probe and the
> > complete .remove function.
> 
> While at it, could you also convert this over to the gpiod_* API?

This is done in patch 3.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From festevam at gmail.com  Tue Feb  2 05:00:33 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 2 Feb 2016 11:00:33 -0200
Subject: noise issues when recording sound on i.MX28
In-Reply-To: <20160127144340.GD13664@pengutronix.de>
References: <20160127105613.GC13664@pengutronix.de>
 <CAOMZO5BpLen517q2heramSta-R6pdESkjM6w=7FRMZebY6ue-Q@mail.gmail.com>
 <20160127144340.GD13664@pengutronix.de>
Message-ID: <CAOMZO5AE6HwBYz7kOFORt0HTojJLSb0MYUbkb_HCshDHy=d27g@mail.gmail.com>

Hi Uwe,

On Wed, Jan 27, 2016 at 12:43 PM, Uwe Kleine-K?nig
<u.kleine-koenig at pengutronix.de> wrote:

> So you didn't hit the problem that resetting a saif didn't work, right?

No, we haven't seen this reset issue.

> Do you have a few more technical details here? A usecase of my machine

Let me find out as it has been several years I worked on this problem.
Will let you know.

Regards,

Fabio Estevam


From tglx at linutronix.de  Tue Feb  2 05:04:29 2016
From: tglx at linutronix.de (Thomas Gleixner)
Date: Tue, 2 Feb 2016 14:04:29 +0100 (CET)
Subject: [PATCH v2 02/10] clockevents/drivers: add MPS2 Timer driver
In-Reply-To: <1454413199-26573-3-git-send-email-vladimir.murzin@arm.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
 <1454413199-26573-3-git-send-email-vladimir.murzin@arm.com>
Message-ID: <alpine.DEB.2.11.1602021351440.25254@nanos>

On Tue, 2 Feb 2016, Vladimir Murzin wrote:
> +static int __init mps2_clockevent_init(struct device_node *np)
> +{
> +	void __iomem *base;
> +	struct clk *clk;
> +	struct clockevent_mps2 *ce;
> +	u32 rate;
> +	int irq, ret;
> +	const char *name = "mps2-clkevt";
> +
> +	ret = of_property_read_u32(np, "clock-frequency", &rate);
> +	if (ret) {
> +		clk = of_clk_get(np, 0);
> +		if (IS_ERR(clk)) {
> +			ret = PTR_ERR(clk);
> +			pr_err("failed to get clock for clockevent: %d\n", ret);
> +			goto err_clk_get;
> +		}
> +
> +		ret = clk_prepare_enable(clk);
> +		if (ret) {
> +			pr_err("failed to enable clock for clockevent: %d\n", ret);
> +			clk_put(clk);
> +			goto err_clk_enable;
> +		}
> +
> +		rate = clk_get_rate(clk);
> +	}

So in case that "clock-frequency" is available in DT, what enables and
configures the clock?

> +err_ia_alloc:
> +	kfree(ce);
> +err_ce_alloc:
> +err_get_irq:
> +	iounmap(base);
> +err_iomap:
> +	clk_disable_unprepare(clk);

clk is not initialized when "clock-frequency" is available in DT. The compiler
should have told you ....

> +err_clk_enable:
> +	clk_put(clk);

Put without get ....

> +static int __init mps2_clocksource_init(struct device_node *np)
> +{
> +	void __iomem *base;
> +	struct clk *clk;
> +	u32 rate;
> +	int ret;
> +	const char *name = "mps2-clksrc";
> +
> +	ret = of_property_read_u32(np, "clock-frequency", &rate);
> +	if (ret) {
> +		clk = of_clk_get(np, 0);
> +		if (IS_ERR(clk)) {
> +			ret = PTR_ERR(clk);
> +			pr_err("failed to get clock for clocksource: %d\n", ret);
> +			goto err_clk_get;
> +		}
> +
> +		ret = clk_prepare_enable(clk);
> +		if (ret) {
> +			pr_err("failed to enable clock for clocksource: %d\n", ret);
> +			clk_put(clk);
> +			goto err_clk_enable;
> +		}
> +
> +		rate = clk_get_rate(clk);
> +	}

Same problem as above.

> +err_clocksource_init:
> +	iounmap(base);
> +err_iomap:
> +	clk_disable_unprepare(clk);

Ditto.

> +err_clk_enable:
> +	clk_put(clk);

Ditto.

> +err_clk_get:
> +	return ret;
> +}
> +
> +static void __init mps2_timer_init(struct device_node *np)
> +{
> +	static int has_clocksource, has_clockevent;
> +	int ret;
> +
> +	if (!has_clocksource) {
> +		ret = mps2_clocksource_init(np);
> +		if (!ret) {
> +			has_clocksource = 1;
> +			return;
> +		}
> +	}
> +
> +	if (!has_clockevent) {
> +		ret = mps2_clockevent_init(np);
> +		if (!ret) {
> +			has_clockevent = 1;
> +			return;
> +		}
> +	}

You take randomly the first timer as clocksource and the second one as
clockevent. If clocksource init fails, you try to install it as clockevent.

Sorry, but I really cannot follow the logic here.

Thanks,

	tglx


From ulf.hansson at linaro.org  Tue Feb  2 05:11:07 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 2 Feb 2016 14:11:07 +0100
Subject: [PATCH] mmc: sdhci-iproc: use sdhci_pltfm_unregister directly
In-Reply-To: <1453803963-6385-1-git-send-email-jszhang@marvell.com>
References: <1453803963-6385-1-git-send-email-jszhang@marvell.com>
Message-ID: <CAPDyKFoo4xWSwb5QCX4QS=NWTTZMFo80WevNkwDMwKgKjJWEUQ@mail.gmail.com>

On 26 January 2016 at 11:26, Jisheng Zhang <jszhang at marvell.com> wrote:
> The sdhci_iproc_remove() is jsut a wrapper to sdhci_pltfm_unregister.
> So use the sdhci_pltfm_unregister() for the .remove hook directly.
>
> Signed-off-by: Jisheng Zhang <jszhang at marvell.com>

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/sdhci-iproc.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
> index 3b423b0..24c5546 100644
> --- a/drivers/mmc/host/sdhci-iproc.c
> +++ b/drivers/mmc/host/sdhci-iproc.c
> @@ -220,11 +220,6 @@ err:
>         return ret;
>  }
>
> -static int sdhci_iproc_remove(struct platform_device *pdev)
> -{
> -       return sdhci_pltfm_unregister(pdev);
> -}
> -
>  static struct platform_driver sdhci_iproc_driver = {
>         .driver = {
>                 .name = "sdhci-iproc",
> @@ -232,7 +227,7 @@ static struct platform_driver sdhci_iproc_driver = {
>                 .pm = SDHCI_PLTFM_PMOPS,
>         },
>         .probe = sdhci_iproc_probe,
> -       .remove = sdhci_iproc_remove,
> +       .remove = sdhci_pltfm_unregister,
>  };
>  module_platform_driver(sdhci_iproc_driver);
>
> --
> 2.7.0
>


From ulf.hansson at linaro.org  Tue Feb  2 05:11:25 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 2 Feb 2016 14:11:25 +0100
Subject: [PATCH 0/3] mmc: sunxi: Support eMMC DDR modes
In-Reply-To: <1454088108-2332-1-git-send-email-wens@csie.org>
References: <1454088108-2332-1-git-send-email-wens@csie.org>
Message-ID: <CAPDyKFrH80eb3dC=AuxXHBHhk-P7puGtModHEmfywRXskVmWQQ@mail.gmail.com>

On 29 January 2016 at 18:21, Chen-Yu Tsai <wens at csie.org> wrote:
> Hi everyone,
>
> This was "mmc: sunxi: Support vqmmc regulator and eMMC DDR modes". vqmmc
> support and DT patches were merged even though it was an RFC series, to
> my suprise.
>
> These are the remaining patches that add eMMC HS-DDR support to sunxi.
>
> Patch 1 adds timing delays for MMC_DDR52 mode.
>
> Patch 2 adds support for 8 bit eMMC DDR52 mode. Under this mode, the
> controller must run at twice the card clock, and different timing delays
> are needed.
>
> Patch 3 enables eMMC HS-DDR for sunxi-mmc.
>
>
> Changes since RFC:
>
>   - Dropped patches that are merged
>
>   - Dropped "mmc: sunxi: Block signal voltage switching (CMD11)".
>     According to Ulf, the mmc core won't send this command unless the UHS
>     capabilities are set. We don't.
>
>   - Increased f_max to 52 MHz. Clock rate range for 50 MHz timing delay
>     also increased to match. See patch 1.
>
>
> Regards
> ChenYu
>
>
> Chen-Yu Tsai (3):
>   mmc: sunxi: Support MMC_DDR52 timing modes
>   mmc: sunxi: Support 8 bit eMMC DDR transfer modes
>   mmc: sunxi: Enable eMMC HS-DDR (MMC_CAP_1_8V_DDR) support
>
>  drivers/mmc/host/sunxi-mmc.c | 42 ++++++++++++++++++++++++++++++++----------
>  1 file changed, 32 insertions(+), 10 deletions(-)
>
> --
> 2.7.0
>

Thanks, applied for next!

Kind regards
Uffe


From ulf.hansson at linaro.org  Tue Feb  2 05:11:34 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 2 Feb 2016 14:11:34 +0100
Subject: [PATCH v2] mmc: sdhci-of-at91: fix pm runtime unbalanced issue in
 error path
In-Reply-To: <1454414106-4441-1-git-send-email-jszhang@marvell.com>
References: <1454414106-4441-1-git-send-email-jszhang@marvell.com>
Message-ID: <CAPDyKFoMo5q_93Rofh+_HAcg+vhGqVM7WeVLbSTCxRLwbgEpqA@mail.gmail.com>

On 2 February 2016 at 12:55, Jisheng Zhang <jszhang at marvell.com> wrote:
> The device power usage counter is increased by pm_runtime_get_noresume
> but isn't decreased in err_add_host error path.
>
> Fix this issue by calling pm_runtime_put_noidle() in the error path to
> restore the device's power usage counter.
>
> Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
> Acked-by: Ludovic Desroches <ludovic.desroches at atmel.com>
> Fixes: f5f17813ae9b ("mmc: sdhci-of-at91: add PM support)

Thanks, applied for fixes!

Kind regards
Uffe

> ---
> Since v1:
>  - Add Ludovic ack
>  - address Ulf's comment
>
>  drivers/mmc/host/sdhci-of-at91.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-at91.c b/drivers/mmc/host/sdhci-of-at91.c
> index 7db7163..35c02fc 100644
> --- a/drivers/mmc/host/sdhci-of-at91.c
> +++ b/drivers/mmc/host/sdhci-of-at91.c
> @@ -211,6 +211,7 @@ static int sdhci_at91_probe(struct platform_device *pdev)
>  pm_runtime_disable:
>         pm_runtime_disable(&pdev->dev);
>         pm_runtime_set_suspended(&pdev->dev);
> +       pm_runtime_put_noidle(&pdev->dev);
>  clocks_disable_unprepare:
>         clk_disable_unprepare(priv->gck);
>         clk_disable_unprepare(priv->mainck);
> --
> 1.9.1
>


From maxime.ripard at free-electrons.com  Tue Feb  2 05:12:26 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 14:12:26 +0100
Subject: [PATCH 02/14] clk: sunxi: Add apb0 gates for A83T
In-Reply-To: <1454203266-4450-3-git-send-email-vishnupatekar0510@gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-3-git-send-email-vishnupatekar0510@gmail.com>
Message-ID: <20160202131226.GO4652@lukather>

On Sun, Jan 31, 2016 at 09:20:54AM +0800, Vishnu Patekar wrote:
> APB0 is part of PRCM, and is compatible with earlier SOCs.
> apb0 gates controls R_PIO, R_UART, R_RSB, etc clocks.
> This patch adds support for APB0 gates for A83T.
> 
> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/008ae378/attachment.sig>

From maxime.ripard at free-electrons.com  Tue Feb  2 05:13:47 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 14:13:47 +0100
Subject: [PATCH 03/14] clk: sunxi: add bus gates for A83T
In-Reply-To: <1454203266-4450-4-git-send-email-vishnupatekar0510@gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-4-git-send-email-vishnupatekar0510@gmail.com>
Message-ID: <20160202131347.GP4652@lukather>

On Sun, Jan 31, 2016 at 09:20:55AM +0800, Vishnu Patekar wrote:
> A83T has similar bus gates that of H3, including single gating register has
> different clock parent.
> 
> As per H3 and A83T datasheet, usbhost is under AHB2.
> 
> However,below shows allwinner source code assignment:
> bits: 26 (ehci0), 27 (ehci1), 29 (ohci0) => AHB1 for A83T.
> bits: 26 (ehci0), 27 (ehci1) => AHB1 for H3
> bits  29, 30, 31(ohci0,1,2) => AHB2 for H3.
> 
> until, this confusion is cleared keep it H3 way.
> 
> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
>  drivers/clk/sunxi/clk-sun8i-bus-gates.c           | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index 7f19ef5..4514d77 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -59,6 +59,7 @@ Required properties:
>  	"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
>  	"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
>  	"allwinner,sun8i-h3-bus-gates-clk" - for the bus gates on H3
> +	"allwinner,sun8i-a83t-bus-gates-clk" - for the bus gates on A83T

Please order them alphabetically next time.

Applied with the fix, and the Acked-bys

thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/8a695ffe/attachment.sig>

From daniel at zonque.org  Tue Feb  2 05:14:49 2016
From: daniel at zonque.org (Daniel Mack)
Date: Tue, 2 Feb 2016 14:14:49 +0100
Subject: [PATCH v2 0/3] Input: rotary-encoder - use more than two gpios
In-Reply-To: <20160202125602.GW13664@pengutronix.de>
References: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <56B09C27.8070009@zonque.org> <20160202125602.GW13664@pengutronix.de>
Message-ID: <56B0ABC9.10107@zonque.org>

On 02/02/2016 01:56 PM, Uwe Kleine-K?nig wrote:
> Hello Daniel,
> 
> On Tue, Feb 02, 2016 at 01:08:07PM +0100, Daniel Mack wrote:
>> On 02/02/2016 11:24 AM, Uwe Kleine-K?nig wrote:
>>> Some time ago I sent a v1 of this, now after testing the changes more
>>> deeply patch 3 changed a bit. The old series started with
>>>
>>> 	Date: Wed,  2 Dec 2015 11:07:11 +0100
>>> 	From: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
>>> 	Subject: [PATCH RFC 0/3] input: rotary_encoder: use more than two gpios as input
>>> 	Message-Id: <1449050834-31779-1-git-send-email-u.kleine-koenig at pengutronix.de>
>>>
>>> The two first patches are just preparation for the third patch.
>>>
>>> There is an obvious improvement that allows detection of quick changes
>>> more reliably with >2 gpios, but I didn't implement this yet. (With 4
>>> GPIOs you can distinguish a counter clockwise movement of three states
>>> from a clock wise movement of a single state. Still the patch is useful
>>> as it makes these devices work at all.
>>>
>>> My test device looks as follows:
>>>
>>>         rotary at 0 {
>>>                 compatible = "rotary-encoder";
>>>                 gpios = <&gpio4 12 GPIO_ACTIVE_HIGH>, <&gpio4 11 GPIO_ACTIVE_HIGH>, <&gpio4 10 GPIO_ACTIVE_HIGH>, <&gpio4 9 GPIO_ACTIVE_HIGH>;
>>>
>>>                 rotary-encoder,steps = <16>;
>>> 		rotary-encoder,steps-per-period = <16>;
>>>         };
>>>
>>> While Daniel Mack and Rojhalat Ibrahim agreed that this device is an
>>> absolute encoder and should be supported by a simpler logic, I still
>>> consider it worthwhile to get these patches in as a first step. Also the
>>> binding looks right, so IMHO the comments shouldn't stop this series
>>> from going in.
>>
>> I still don't understand why this is implemented that way, rather than
>> going for a much simpler logic of interpretation that also allows users
>> to read out the absolute position.
>>
>> The code to read the value would be really just as simple as reading all
>> GPIOs and or-ing their values into the result, and skip the state
>> machine completely. This code would be active if a new attribute
>> (something like 'rotary-encoder,hardware-absolute') is set, or even
>> implicitly, when more than 2 GPIOs are specified.
>>
>> Is there any reason for not doing that?
> 
> Currently the reason is lack of time. And when implementing
> rotary-encoder,hardware-absolute something similar would be the result
> for the relative reporting anyhow. So the problem is only that I don't
> have absolute support yet, but the patches as is would be the base for
> that anyhow.

Because you would support relative support for such 4-pin encoders as
well? I would have thought that absolute encoders would report absolute
values only, but I guess you have a point here. Just to make sure we're
on the same page: For more than 2 GPIOs, and an absent
"rotary-encoder,relative-axis", the driver would switch to a mode in
which it bypasses the state machine, right?

If you're planning to implement that eventually, I'm fine with the
patches for now :)

Dmitry, if you are apply them, feel free to add my

  Acked-by: Daniel Mack <daniel at zonque.org>

to all 3 of them.


Thanks,
Daniel



From daniel at zonque.org  Tue Feb  2 05:15:28 2016
From: daniel at zonque.org (Daniel Mack)
Date: Tue, 2 Feb 2016 14:15:28 +0100
Subject: [PATCH v2 1/3] Input: rotary-encoder - make use of devm_* to
 simplify .probe and .remove
In-Reply-To: <20160202130022.GX13664@pengutronix.de>
References: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <1454408678-6011-2-git-send-email-u.kleine-koenig@pengutronix.de>
 <56B09968.9050705@zonque.org> <20160202130022.GX13664@pengutronix.de>
Message-ID: <56B0ABF0.8010904@zonque.org>

On 02/02/2016 02:00 PM, Uwe Kleine-K?nig wrote:
> On Tue, Feb 02, 2016 at 12:56:24PM +0100, Daniel Mack wrote:
>> On 02/02/2016 11:24 AM, Uwe Kleine-K?nig wrote:
>>> For all operations called in .probe there are devm_* variants.
>>> (input_register_device is clever enough to be devm aware on its own.)
>>> This allows to get rid of the error unwind code paths in .probe and the
>>> complete .remove function.
>>
>> While at it, could you also convert this over to the gpiod_* API?
> 
> This is done in patch 3.

Ah, right. Missed that detail, sorry.


Daniel



From horms at verge.net.au  Tue Feb  2 05:16:47 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Feb 2016 14:16:47 +0100
Subject: [PATCH v4 0/9] ARM/arm64: dts: rcar: Enable SCIF_CLK frequency
 and pins
In-Reply-To: <20160202102132.GE15554@verge.net.au>
References: <1454062646-4826-1-git-send-email-geert+renesas@glider.be>
 <20160202102132.GE15554@verge.net.au>
Message-ID: <20160202131647.GJ15554@verge.net.au>

On Tue, Feb 02, 2016 at 11:21:33AM +0100, Simon Horman wrote:
> On Fri, Jan 29, 2016 at 11:17:17AM +0100, Geert Uytterhoeven wrote:
> > 	Hi Simon, Magnus,
> > 
> > This patch series adds support for the external crystal feeding SCIF_CLK
> > to (H)SCIF on the various Renesas R-Car Gen1, Gen2, and Gen3 development
> > boards.  This increases the range and accuracy of supported baud rates.
> > Support for this has been accepted in the driver in v4.5-rc1.
> > 
> > Changes compared to v3:
> >   - Change one-line summary prefix to match current arm-soc practices,
> >   - Tested on r8a7794/alt,
> >   - Rebased,
> > 
> > Changes compared to v2:
> >   - Add support for r8a7778/bockw, r8a7779/marzen, r8a7790/lager,
> >     r8a7791/porter, r8a7793/gose, r8a7794/alt, and r8a7794/silk,
> >   - Add Reviewed-by.
> > 
> > Testing:
> >   - This was tested locally on r8a7791/koelsch and r8a7795/salvator-x,
> >   - This was tested remotely on r8a7778/bockw, r8a7779/marzen, and
> >     r8a7794/alt,
> >   - This has been in renesas-drivers for a while, so I assume it has
> >     received basic testing on other boards,
> >   - Hints for various levels of testing:
> >       - Change the "dev_dbg" after "done:" in
> > 	drivers/tty/serial/sh-sci.c to "dev_info" to print clock and bit
> > 	rate,
> >       - "yes U | tr -d '\n' > /dev/ttySCx" outputs a square wave with a
> >         frequency of half the bit rate on TXD,
> >       - Modifying the frequency of SCIF_CLK causes garbage on the serial
> >         console, unless you compensate by changing the bit rate in
> >         /chosen/stdout-path,
> >       - If you disable the SCIF_CLK, the brg_int clock will be used. If
> >         you change that clock, you'll get garbage again.
> > 
> > Dependencies:
> >   - renesas-devel-20160129-v4.5-rc1,
> >   - series "[PATCH v4 0/7] ARM: dts: R-Car: Add SCIF fallback
> >     compatibility strings",
> >   - series "[PATCH v4 00/11] ARM: dts: shmobile: Rename the serial port
> >     clock to fck",
> >   - series "[PATCH v4 0/7] ARM: dts: r-car: Add BRG support for
> >     (H)SCIF".
> > 
> > Thanks for applying!
> 
> Is this safe to queue up in the light of the dependency on
> renesas-devel-20160129-v4.5-rc1?

Discussed elsewhere; I have queued this up.


From maxime.ripard at free-electrons.com  Tue Feb  2 05:17:25 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 14:17:25 +0100
Subject: [PATCH 04/14] clk: sunxi: add ahb1 clock for A83T
In-Reply-To: <1454203266-4450-5-git-send-email-vishnupatekar0510@gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-5-git-send-email-vishnupatekar0510@gmail.com>
Message-ID: <20160202131725.GQ4652@lukather>

Hi,

On Sun, Jan 31, 2016 at 09:20:56AM +0800, Vishnu Patekar wrote:
> AHB1 on A83T is similar to ahb1 on A31, except parents are different.
> clock index 0b1x is PLL6.
> 
> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>

If the clock is the same but the parents are different, then we don't
need to duplicate all the logic. Simply add the number of parents to
mux_data, and you're all set.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/170676f2/attachment.sig>

From maxime.ripard at free-electrons.com  Tue Feb  2 05:18:51 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 14:18:51 +0100
Subject: [PATCH 06/14] ARM: dts: sun8i-a83t: Correct low speed oscillator
 clocks
In-Reply-To: <1454203266-4450-7-git-send-email-vishnupatekar0510@gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-7-git-send-email-vishnupatekar0510@gmail.com>
Message-ID: <20160202131851.GR4652@lukather>

1;4002;0c
On Sun, Jan 31, 2016 at 09:20:58AM +0800, Vishnu Patekar wrote:
> From: Chen-Yu Tsai <wens at csie.org>
> 
> The A83T does not have a 32.768 kHz low speed oscillator, either as
> an external crystal or input. It has a 16 MHz RC-based (inaccurate)
> internal oscillator, which is then divided by 512 for a clock close
> to 32 kHz.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
> ---
>  arch/arm/boot/dts/sun8i-a83t.dtsi | 21 ++++++++++++++++++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index 8d27b63..45b725c 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -118,6 +118,7 @@
>  		#size-cells = <1>;
>  		ranges;
>  
> +		/* TODO: PRCM block has a mux for this. */
>  		osc24M: osc24M_clk {
>  			#clock-cells = <0>;
>  			compatible = "fixed-clock";
> @@ -125,11 +126,25 @@
>  			clock-output-names = "osc24M";
>  		};
>  
> -		osc32k: osc32k_clk {
> +		/*
> +		 * This is called "internal OSC" in some places.
> +		 * It is an internal RC-based oscillator.
> +		 * TODO: Its controls are in the PRCM block.
> +		 */
> +		osc16M: osc16M_clk {
>  			#clock-cells = <0>;
>  			compatible = "fixed-clock";
> -			clock-frequency = <32768>;
> -			clock-output-names = "osc32k";
> +			clock-frequency = <16000000>;
> +			clock-output-names = "osc16M";
> +		};
> +
> +		osc16Md512: osc16Md512_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-factor-clock";
> +			clock-div = <512>;
> +			clock-mult = <1>;
> +			clocks = <&osc16M>;
> +			clock-output-names = "osc16Md512";

We've been using a dash to separate between the clock and its divider
on other SoCs.

I changed that and applied the patch.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/63535d6e/attachment.sig>

From maxime.ripard at free-electrons.com  Tue Feb  2 05:19:47 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 14:19:47 +0100
Subject: [PATCH 06/14] ARM: dts: sun8i-a83t: Correct low speed oscillator
 clocks
In-Reply-To: <1454203266-4450-7-git-send-email-vishnupatekar0510@gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-7-git-send-email-vishnupatekar0510@gmail.com>
Message-ID: <20160202131947.GS4652@lukather>

On Sun, Jan 31, 2016 at 09:20:58AM +0800, Vishnu Patekar wrote:
> From: Chen-Yu Tsai <wens at csie.org>
> 
> The A83T does not have a 32.768 kHz low speed oscillator, either as
> an external crystal or input. It has a 16 MHz RC-based (inaccurate)
> internal oscillator, which is then divided by 512 for a clock close
> to 32 kHz.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>

You should have your SoB here.

Is it ok to add it?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/7ce85e61/attachment.sig>

From ard.biesheuvel at linaro.org  Tue Feb  2 05:19:31 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  2 Feb 2016 14:19:31 +0100
Subject: [PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM
Message-ID: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>

This series applies on top of today's -next, and addresses an issue with
the new kallsyms code that is queued there, that enables base relative
kallsyms tables for all architectures (except IA-64)

Two issues have surfaced on ARM with the new kallsyms code:
a) CONFIG_HAVE_TCM creates a virtual region that is too far away for the
   relative kallsyms code to reach it;
b) CONFIG_XIP_KERNEL=y kernel symbols are not filtered against PAGE_OFFSET,
   as is the case for kernels that execute from RAM, resulting in symbols
   that are out of range.

Since the way kallsyms deals with XIP kernels on ARM leaves some room for
improvement regardless of the base relative changes, this series proposes
a fix that allows the special case to be removed from the kallsyms handling
entirely.

Patch #1 moves the .stubs and .vectors section back into the kernel VMA, while
preserving the guaranteed virtual offset of 4 KB. This results in all symbols
that kallsyms sees to be in a reasonable interval.

Patch #2 removes the special case for CONFIG_ARM && !CONFIG_XIP_KERNEL in the
invocation of scripts/kallsyms

Patch #3 removes the now unused --page-offset command line argument handling
from scripts/kallsyms.c

Note that we may still need to remove ARM from the list of architectures that
support base relative kallsyms tables if we cannot fix issue a) above, but
removing this special case seemed like an obvious improvement to me.

Ard Biesheuvel (3):
  ARM: move .vectors and .stubs sections back into the kernel VMA
  kallsyms: remove special lower address limit for CONFIG_ARM
  kallsyms: remove --page-offset command line option

 arch/arm/kernel/entry-armv.S  |  7 +++--
 arch/arm/kernel/vmlinux.lds.S | 15 ++++++-----
 scripts/kallsyms.c            | 27 ++++----------------
 scripts/link-vmlinux.sh       |  4 ---
 4 files changed, 16 insertions(+), 37 deletions(-)

-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb  2 05:19:34 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  2 Feb 2016 14:19:34 +0100
Subject: [PATCH 3/3] kallsyms: remove --page-offset command line option
In-Reply-To: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454419174-21290-4-git-send-email-ard.biesheuvel@linaro.org>

The --page-offset command line option was only used for ARM, to filter
symbol addresses below CONFIG_PAGE_OFFSET. This is no longer needed, so
remove the functionality altogether.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 scripts/kallsyms.c | 27 ++++----------------
 1 file changed, 5 insertions(+), 22 deletions(-)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 02473b71643b..ce36fc02fe8c 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -63,7 +63,6 @@ static unsigned int table_size, table_cnt;
 static int all_symbols = 0;
 static int absolute_percpu = 0;
 static char symbol_prefix_char = '\0';
-static unsigned long long kernel_start_addr = 0;
 static int base_relative = 0;
 
 int token_profit[0x10000];
@@ -229,9 +228,6 @@ static int symbol_valid(struct sym_entry *s)
 	char *sym_name = (char *)s->sym + 1;
 
 
-	if (s->addr < kernel_start_addr)
-		return 0;
-
 	/* skip prefix char */
 	if (symbol_prefix_char && *sym_name == symbol_prefix_char)
 		sym_name++;
@@ -742,21 +738,11 @@ static void record_relative_base(void)
 {
 	unsigned int i;
 
-	if (kernel_start_addr > 0) {
-		/*
-		 * If the kernel start address was specified, use that as
-		 * the relative base rather than going through the table,
-		 * since it should be a reasonable default, and values below
-		 * it will be ignored anyway.
-		 */
-		relative_base = kernel_start_addr;
-	} else {
-		relative_base = -1ULL;
-		for (i = 0; i < table_cnt; i++)
-			if (!symbol_absolute(&table[i]) &&
-			    table[i].addr < relative_base)
-				relative_base = table[i].addr;
-	}
+	relative_base = -1ULL;
+	for (i = 0; i < table_cnt; i++)
+		if (!symbol_absolute(&table[i]) &&
+		    table[i].addr < relative_base)
+			relative_base = table[i].addr;
 }
 
 int main(int argc, char **argv)
@@ -774,9 +760,6 @@ int main(int argc, char **argv)
 				if ((*p == '"' && *(p+2) == '"') || (*p == '\'' && *(p+2) == '\''))
 					p++;
 				symbol_prefix_char = *p;
-			} else if (strncmp(argv[i], "--page-offset=", 14) == 0) {
-				const char *p = &argv[i][14];
-				kernel_start_addr = strtoull(p, NULL, 16);
 			} else if (strcmp(argv[i], "--base-relative") == 0)
 				base_relative = 1;
 			else
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb  2 05:19:32 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  2 Feb 2016 14:19:32 +0100
Subject: [PATCH 1/3] ARM: move .vectors and .stubs sections back into the
 kernel VMA
In-Reply-To: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454419174-21290-2-git-send-email-ard.biesheuvel@linaro.org>

Commit b9b32bf70f2f ("ARM: use linker magic for vectors and vector stubs")
updated the linker script to emit the .vectors and .stubs sections into a
VMA range that is zero based and disjoint from the normal static kernel
region. The reason for that was that this way, the sections can be placed
exactly 4 KB apart, while the payload of the .vectors section is only 32
bytes.

Since the symbols that are part of the .stubs section are emitted into the
kallsyms table, they appear with zero based addresses as well, e.g.,

  00000000 t __vectors_start
  00001000 t __stubs_start
  00001004 t vector_rst
  00001020 t vector_irq
  000010a0 t vector_dabt
  00001120 t vector_pabt
  000011a0 t vector_und
  00001220 t vector_addrexcptn
  00001240 t vector_fiq
  00001240 T vector_fiq_offset

As this confuses perf when it accesses the kallsyms tables, commit
7122c3e9154b ("scripts/link-vmlinux.sh: only filter kernel symbols for
arm") implemented a somewhat ugly special case for ARM, where the value
of CONFIG_PAGE_OFFSET is passed to scripts/kallsyms, and symbols whose
address is below it are filtered out. Note that this special case only
applies to CONFIG_XIP_KERNEL=n, not because the issue the patch addresses
exists only in that case, but because finding a limit below which to apply
the filtering is too difficult.

Since the constraint we are trying to meet here is that the .vectors
section lives exactly 4 KB before the .stubs section, regardless of the
absolute addresses of either (since relative branches are used to jump from
the vector table to the stubs), we can simply emit the .stubs section as
part of the kernel VMA, and place the .vectors section 4 KB before it using
an explicit VMA override. By doing that, and renaming the __vectors_start
symbol that is local to arch/arm/kernel/entry-armv.S (not the one in the
linker script), the kallsyms table looks somewhat sane, regardless of
whether CONFIG_XIP_KERNEL is set, and we can drop the special case in
scripts/kallsyms entirely. E.g.,

  00001240 A vector_fiq_offset
  ...
  c0c35000 T __init_begin
  c0c35000 t __stubs_start
  c0c35000 T __stubs_start
  c0c35004 t vector_rst
  c0c35020 t vector_irq
  c0c350a0 t vector_dabt
  c0c35120 t vector_pabt
  c0c351a0 t vector_und
  c0c35220 t vector_addrexcptn
  c0c35240 T vector_fiq
  c0c352c0 T __stubs_end
  c0c352c0 T __vectors_start
  c0c352e0 t __mmap_switched
  c0c352e0 T _sinittext
  c0c352e0 T __vectors_end

(Note that vector_fiq_offset is now an absolute symbol, which kallsyms
already ignores by default)

The sections themselves are emitted 4 KB apart, as required:
  ...
  [16] .stubs       PROGBITS   c0c35000 a35000 0002c0 00  AX  0   0 32
  [17] .vectors     PROGBITS   c0c34000 a44000 000020 00  AX  0   0  2
  ...

and the relative branches in the .vectors section still point to the
right place:

  c0c34000 <.vectors>:
  c0c34000:       f001 b800       b.w     c0c35004 <vector_rst>
  c0c34004:       f001 b8cc       b.w     c0c351a0 <vector_und>
  c0c34008:       f8df fff4       ldr.w   pc, [pc, #4084] ; c0c35000
  c0c3400c:       f001 b888       b.w     c0c35120 <vector_pabt>
  c0c34010:       f001 b846       b.w     c0c350a0 <vector_dabt>
  c0c34014:       f001 b904       b.w     c0c35220 <vector_addrexcptn>
  c0c34018:       f001 b802       b.w     c0c35020 <vector_irq>
  c0c3401c:       f001 b910       b.w     c0c35240 <vector_fiq>

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm/kernel/entry-armv.S  |  7 +++----
 arch/arm/kernel/vmlinux.lds.S | 15 ++++++++-------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 3ce377f7251f..8575ff42c0d4 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -1202,14 +1202,13 @@ vector_addrexcptn:
 	.long	__fiq_svc			@  e
 	.long	__fiq_svc			@  f
 
-	.globl	vector_fiq_offset
-	.equ	vector_fiq_offset, vector_fiq
+	.globl	vector_fiq
 
 	.section .vectors, "ax", %progbits
-__vectors_start:
+.L__vectors_start:
 	W(b)	vector_rst
 	W(b)	vector_und
-	W(ldr)	pc, __vectors_start + 0x1000
+	W(ldr)	pc, .L__vectors_start + 0x1000
 	W(b)	vector_pabt
 	W(b)	vector_dabt
 	W(b)	vector_addrexcptn
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 8b60fde5ce48..7160658fd5d4 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -164,19 +164,20 @@ SECTIONS
 	 * The vectors and stubs are relocatable code, and the
 	 * only thing that matters is their relative offsets
 	 */
+	__stubs_start = .;
+	.stubs : {
+		*(.stubs)
+	}
+	__stubs_end = .;
+
 	__vectors_start = .;
-	.vectors 0 : AT(__vectors_start) {
+	.vectors ADDR(.stubs) - 0x1000 : AT(__vectors_start) {
 		*(.vectors)
 	}
 	. = __vectors_start + SIZEOF(.vectors);
 	__vectors_end = .;
 
-	__stubs_start = .;
-	.stubs 0x1000 : AT(__stubs_start) {
-		*(.stubs)
-	}
-	. = __stubs_start + SIZEOF(.stubs);
-	__stubs_end = .;
+	vector_fiq_offset = vector_fiq - ADDR(.vectors);
 
 	INIT_TEXT_SECTION(8)
 	.exit.text : {
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb  2 05:19:33 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  2 Feb 2016 14:19:33 +0100
Subject: [PATCH 2/3] kallsyms: remove special lower address limit for
 CONFIG_ARM
In-Reply-To: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454419174-21290-3-git-send-email-ard.biesheuvel@linaro.org>

Now that we no longer emit .stubs symbols into a section VMA loaded
at absolute address 0x1000, we can drop the ARM-specific override that
sets a lower limit based on CONFIG_PAGE_OFFSET, below which symbols are
filtered from the kallsyms output.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 scripts/link-vmlinux.sh | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index aae2473301ea..b83f918c7830 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -82,10 +82,6 @@ kallsyms()
 		kallsymopt="${kallsymopt} --all-symbols"
 	fi
 
-	if [ -n "${CONFIG_ARM}" ] && [ -z "${CONFIG_XIP_KERNEL}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
-		kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
-	fi
-
 	if [ -n "${CONFIG_X86_64}" ] && [ -n "${CONFIG_SMP}" ]; then
 		kallsymopt="${kallsymopt} --absolute-percpu"
 	fi
-- 
2.5.0



From maxime.ripard at free-electrons.com  Tue Feb  2 05:24:21 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 14:24:21 +0100
Subject: [PATCH] pinctrl: sunxi: H3 requires irq_read_needs_mux
In-Reply-To: <20160202100217.GA7483@box2.japko.eu>
References: <20160202100217.GA7483@box2.japko.eu>
Message-ID: <20160202132421.GT4652@lukather>

On Tue, Feb 02, 2016 at 11:03:03AM +0100, Krzysztof Adamski wrote:
> It seems that on H3, just like on A10, when GPIOs are configured as
> external interrupt data registers does not contain their value.  When
> value is read, GPIO function must be temporary switched to input for
> reads.
> 
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/d89e8160/attachment.sig>

From u.kleine-koenig at pengutronix.de  Tue Feb  2 05:27:03 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Tue, 2 Feb 2016 14:27:03 +0100
Subject: [PATCH v2 0/3] Input: rotary-encoder - use more than two gpios
In-Reply-To: <56B0ABC9.10107@zonque.org>
References: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <56B09C27.8070009@zonque.org>
 <20160202125602.GW13664@pengutronix.de> <56B0ABC9.10107@zonque.org>
Message-ID: <20160202132703.GY13664@pengutronix.de>

Hello Daniel,

On Tue, Feb 02, 2016 at 02:14:49PM +0100, Daniel Mack wrote:
> On 02/02/2016 01:56 PM, Uwe Kleine-K?nig wrote:
> > Hello Daniel,
> > 
> > On Tue, Feb 02, 2016 at 01:08:07PM +0100, Daniel Mack wrote:
> >> On 02/02/2016 11:24 AM, Uwe Kleine-K?nig wrote:
> >>> Some time ago I sent a v1 of this, now after testing the changes more
> >>> deeply patch 3 changed a bit. The old series started with
> >>>
> >>> 	Date: Wed,  2 Dec 2015 11:07:11 +0100
> >>> 	From: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> >>> 	Subject: [PATCH RFC 0/3] input: rotary_encoder: use more than two gpios as input
> >>> 	Message-Id: <1449050834-31779-1-git-send-email-u.kleine-koenig at pengutronix.de>
> >>>
> >>> The two first patches are just preparation for the third patch.
> >>>
> >>> There is an obvious improvement that allows detection of quick changes
> >>> more reliably with >2 gpios, but I didn't implement this yet. (With 4
> >>> GPIOs you can distinguish a counter clockwise movement of three states
> >>> from a clock wise movement of a single state. Still the patch is useful
> >>> as it makes these devices work at all.
> >>>
> >>> My test device looks as follows:
> >>>
> >>>         rotary at 0 {
> >>>                 compatible = "rotary-encoder";
> >>>                 gpios = <&gpio4 12 GPIO_ACTIVE_HIGH>, <&gpio4 11 GPIO_ACTIVE_HIGH>, <&gpio4 10 GPIO_ACTIVE_HIGH>, <&gpio4 9 GPIO_ACTIVE_HIGH>;
> >>>
> >>>                 rotary-encoder,steps = <16>;
> >>> 		rotary-encoder,steps-per-period = <16>;
> >>>         };
> >>>
> >>> While Daniel Mack and Rojhalat Ibrahim agreed that this device is an
> >>> absolute encoder and should be supported by a simpler logic, I still
> >>> consider it worthwhile to get these patches in as a first step. Also the
> >>> binding looks right, so IMHO the comments shouldn't stop this series
> >>> from going in.
> >>
> >> I still don't understand why this is implemented that way, rather than
> >> going for a much simpler logic of interpretation that also allows users
> >> to read out the absolute position.
> >>
> >> The code to read the value would be really just as simple as reading all
> >> GPIOs and or-ing their values into the result, and skip the state
> >> machine completely. This code would be active if a new attribute
> >> (something like 'rotary-encoder,hardware-absolute') is set, or even
> >> implicitly, when more than 2 GPIOs are specified.
> >>
> >> Is there any reason for not doing that?
> > 
> > Currently the reason is lack of time. And when implementing
> > rotary-encoder,hardware-absolute something similar would be the result
> > for the relative reporting anyhow. So the problem is only that I don't
> > have absolute support yet, but the patches as is would be the base for
> > that anyhow.
> 
> Because you would support relative support for such 4-pin encoders as
> well? I would have thought that absolute encoders would report absolute
> values only, but I guess you have a point here. Just to make sure we're
> on the same page: For more than 2 GPIOs, and an absent
> "rotary-encoder,relative-axis", the driver would switch to a mode in
> which it bypasses the state machine, right?

Not sure about how this will be represented in the device tree, but yes,
that's more or less how I imagine to implement this. (And in the end
having support for a 4-line relative device is just a side effect of
having support for relative devices and for 4-line devices.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From maxime.ripard at free-electrons.com  Tue Feb  2 05:27:18 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 14:27:18 +0100
Subject: [PATCH 1/5] clk: sunxi: Make clocks setup functions return their
 clock
In-Reply-To: <CAGb2v66CyhkM0vabbede43eAaf7WVg0Lm8w_OUKwqHnFO182uw@mail.gmail.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454402834-6385-2-git-send-email-maxime.ripard@free-electrons.com>
 <CAGb2v66CyhkM0vabbede43eAaf7WVg0Lm8w_OUKwqHnFO182uw@mail.gmail.com>
Message-ID: <20160202132718.GU4652@lukather>

Hi,

On Tue, Feb 02, 2016 at 06:35:29PM +0800, Chen-Yu Tsai wrote:
> On Tue, Feb 2, 2016 at 4:47 PM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > The clocks registration code in clk-sunxi was most of the time not
> > returning the struct clk (or struct clk array) that was registered,
> > preventing the users of such functions to manipulate it, for example to
> > protect it.
> >
> > Make them return it so that we can start using it.
> 
> Should they return error codes as well? So the CLK_OF_DECLARE setup functions
> can report errors. Or make these helper functions report errors directly?

CLK_OF_DECLARE doesn't handle any kind of error, as the setup function
must return void, and the error printing should rather be in the
common functions in order to avoid duplicating it everywhere, so I'm
not sure. Or did you had something else in mind?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/9af172d6/attachment.sig>

From maxime.ripard at free-electrons.com  Tue Feb  2 05:27:54 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 14:27:54 +0100
Subject: [PATCH 01/11] MAINTAINERS: Add entry for X-Powers AXP family
 PMIC drivers
In-Reply-To: <1454408864-24112-2-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-2-git-send-email-wens@csie.org>
Message-ID: <20160202132754.GV4652@lukather>

On Tue, Feb 02, 2016 at 06:27:34PM +0800, Chen-Yu Tsai wrote:
> Add an entry for X-Powers AXP family PMIC drivers and list myself
> as maintainer.
> 
> Cc: Carlo Caione <carlo at caione.org>
> Cc: Maxime Ripard <maxime.ripard at free-electrons.com>
> Cc: Ramakrishna Pallala <ramakrishna.pallala at intel.com>
> Cc: Todd Brandt <todd.e.brandt at linux.intel.com>
> Cc: Jacob Pan <jacob.jun.pan at linux.intel.com>
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>

Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/c6320ec4/attachment.sig>

From horms+renesas at verge.net.au  Tue Feb  2 05:31:03 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 2 Feb 2016 14:31:03 +0100
Subject: [PATCH v2] arm64: dts: r8a7795: use GIC_* defines
Message-ID: <20160202133103.GK15554@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7795 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
* Based on renesas-devel-20160129-v4.5-rc1

v2
* Updated prefix to arm64
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 108 +++++++++++++++----------------
 1 file changed, 54 insertions(+), 54 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 119549e6502d..d351f2c4b40e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -266,23 +266,23 @@
 		audma0: dma-controller at ec700000 {
 			compatible = "renesas,rcar-dmac";
 			reg = <0 0xec700000 0 0x10000>;
-			interrupts =	<0 350 IRQ_TYPE_LEVEL_HIGH
-					 0 320 IRQ_TYPE_LEVEL_HIGH
-					 0 321 IRQ_TYPE_LEVEL_HIGH
-					 0 322 IRQ_TYPE_LEVEL_HIGH
-					 0 323 IRQ_TYPE_LEVEL_HIGH
-					 0 324 IRQ_TYPE_LEVEL_HIGH
-					 0 325 IRQ_TYPE_LEVEL_HIGH
-					 0 326 IRQ_TYPE_LEVEL_HIGH
-					 0 327 IRQ_TYPE_LEVEL_HIGH
-					 0 328 IRQ_TYPE_LEVEL_HIGH
-					 0 329 IRQ_TYPE_LEVEL_HIGH
-					 0 330 IRQ_TYPE_LEVEL_HIGH
-					 0 331 IRQ_TYPE_LEVEL_HIGH
-					 0 332 IRQ_TYPE_LEVEL_HIGH
-					 0 333 IRQ_TYPE_LEVEL_HIGH
-					 0 334 IRQ_TYPE_LEVEL_HIGH
-					 0 335 IRQ_TYPE_LEVEL_HIGH>;
+			interrupts = <GIC_SPI 350 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "error",
 					"ch0", "ch1", "ch2", "ch3",
 					"ch4", "ch5", "ch6", "ch7",
@@ -298,23 +298,23 @@
 		audma1: dma-controller at ec720000 {
 			compatible = "renesas,rcar-dmac";
 			reg = <0 0xec720000 0 0x10000>;
-			interrupts =	<0 351 IRQ_TYPE_LEVEL_HIGH
-					 0 336 IRQ_TYPE_LEVEL_HIGH
-					 0 337 IRQ_TYPE_LEVEL_HIGH
-					 0 338 IRQ_TYPE_LEVEL_HIGH
-					 0 339 IRQ_TYPE_LEVEL_HIGH
-					 0 340 IRQ_TYPE_LEVEL_HIGH
-					 0 341 IRQ_TYPE_LEVEL_HIGH
-					 0 342 IRQ_TYPE_LEVEL_HIGH
-					 0 343 IRQ_TYPE_LEVEL_HIGH
-					 0 344 IRQ_TYPE_LEVEL_HIGH
-					 0 345 IRQ_TYPE_LEVEL_HIGH
-					 0 346 IRQ_TYPE_LEVEL_HIGH
-					 0 347 IRQ_TYPE_LEVEL_HIGH
-					 0 348 IRQ_TYPE_LEVEL_HIGH
-					 0 349 IRQ_TYPE_LEVEL_HIGH
-					 0 382 IRQ_TYPE_LEVEL_HIGH
-					 0 383 IRQ_TYPE_LEVEL_HIGH>;
+			interrupts = <GIC_SPI 351 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 348 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 349 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 382 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 383 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "error",
 					"ch0", "ch1", "ch2", "ch3",
 					"ch4", "ch5", "ch6", "ch7",
@@ -750,52 +750,52 @@
 
 			rcar_sound,src {
 				src0: src at 0 {
-					interrupts = <0 352 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x85>, <&audma1 0x9a>;
 					dma-names = "rx", "tx";
 				};
 				src1: src at 1 {
-					interrupts = <0 353 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x87>, <&audma1 0x9c>;
 					dma-names = "rx", "tx";
 				};
 				src2: src at 2 {
-					interrupts = <0 354 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x89>, <&audma1 0x9e>;
 					dma-names = "rx", "tx";
 				};
 				src3: src at 3 {
-					interrupts = <0 355 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x8b>, <&audma1 0xa0>;
 					dma-names = "rx", "tx";
 				};
 				src4: src at 4 {
-					interrupts = <0 356 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x8d>, <&audma1 0xb0>;
 					dma-names = "rx", "tx";
 				};
 				src5: src at 5 {
-					interrupts = <0 357 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x8f>, <&audma1 0xb2>;
 					dma-names = "rx", "tx";
 				};
 				src6: src at 6 {
-					interrupts = <0 358 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x91>, <&audma1 0xb4>;
 					dma-names = "rx", "tx";
 				};
 				src7: src at 7 {
-					interrupts = <0 359 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x93>, <&audma1 0xb6>;
 					dma-names = "rx", "tx";
 				};
 				src8: src at 8 {
-					interrupts = <0 360 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x95>, <&audma1 0xb8>;
 					dma-names = "rx", "tx";
 				};
 				src9: src at 9 {
-					interrupts = <0 361 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x97>, <&audma1 0xba>;
 					dma-names = "rx", "tx";
 				};
@@ -803,52 +803,52 @@
 
 			rcar_sound,ssi {
 				ssi0: ssi at 0 {
-					interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x01>, <&audma1 0x02>, <&audma0 0x15>, <&audma1 0x16>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi1: ssi at 1 {
-					 interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>;
+					 interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x03>, <&audma1 0x04>, <&audma0 0x49>, <&audma1 0x4a>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi2: ssi at 2 {
-					interrupts = <0 372 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x05>, <&audma1 0x06>, <&audma0 0x63>, <&audma1 0x64>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi3: ssi at 3 {
-					interrupts = <0 373 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x07>, <&audma1 0x08>, <&audma0 0x6f>, <&audma1 0x70>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi4: ssi at 4 {
-					interrupts = <0 374 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x09>, <&audma1 0x0a>, <&audma0 0x71>, <&audma1 0x72>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi5: ssi at 5 {
-					interrupts = <0 375 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x0b>, <&audma1 0x0c>, <&audma0 0x73>, <&audma1 0x74>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi6: ssi at 6 {
-					interrupts = <0 376 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x0d>, <&audma1 0x0e>, <&audma0 0x75>, <&audma1 0x76>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi7: ssi at 7 {
-					interrupts = <0 377 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x0f>, <&audma1 0x10>, <&audma0 0x79>, <&audma1 0x7a>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi8: ssi at 8 {
-					interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x11>, <&audma1 0x12>, <&audma0 0x7b>, <&audma1 0x7c>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi9: ssi at 9 {
-					interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x13>, <&audma1 0x14>, <&audma0 0x7d>, <&audma1 0x7e>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
-- 
2.7.0.rc3.207.g0ac5344


From andre.przywara at arm.com  Tue Feb  2 05:39:58 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 2 Feb 2016 13:39:58 +0000
Subject: [PATCH 3/3] clk: Provide OF helper to mark clocks as CRITICAL
In-Reply-To: <20160201063256.GE32462@lukather>
References: <1453127331-20616-1-git-send-email-lee.jones@linaro.org>
 <1453127331-20616-4-git-send-email-lee.jones@linaro.org>
 <56A95811.8010200@arm.com> <20160201063256.GE32462@lukather>
Message-ID: <56B0B1AE.2060502@arm.com>

Hi Maxime,

On 01/02/16 06:32, Maxime Ripard wrote:
> Hi Andre,
> 
> On Wed, Jan 27, 2016 at 11:51:45PM +0000, Andr? Przywara wrote:
>> Hi,
>>
>> On 18/01/16 14:28, Lee Jones wrote:
>>> This call matches clocks which have been marked as critical in DT
>>> and sets the appropriate flag.  These flags can then be used to
>>> mark the clock core flags appropriately prior to registration.
>>
>> I like the idea of having a generic property very much. Also this solves
>> a problem I have in a very elegant way.
> 
> Not really. It has a significant set of drawbacks that we already
> detailed in the initial thread, which are mostly related to the fact
> that the clocks are to be left on is something that totally depends on
> the software support in the kernel. Some clocks should be reported as
> critical because they are simply missing a driver for it, some should
> be because the driver for it as not been compiled, some should because
> we don't have the proper clocks drivers yet for one of their
> downstream clocks.
> 
> Basically, it all boils down to this: some clocks should never ever be
> shutdown because <hardware reason>, and I believe it's the case Lee is
> in. But most of the current code that would use it might, and might
> even need at some point to shut down such a clock.

I was bascically interested in pushing the critical-clock property into
DT to solve that cumbersome clk-sunxi init scheme - which you have fixed
now in a much better way (thanks for that, btw.)
For that particular case the CPU clock really looks like being actually
critical in the hardware sense - no-one maybe except the mgmt core
should turn the one single CPU clock source off.

So I wonder if we should document this "for hardware reasons only" and
still have that property in DT?
At the weekend I coded something into the generic DT clock code to let
it parse for basically every clock node - without a particular driver
needing to ask for it.
If this sounds useful to you I can post that one.

Cheers,
Andre.
> 
> Mike's solution with the flags + handover was solving all this, I'm
> not sure why he's not pushed it forward.
> 
> Maxime
> 


From marc.zyngier at arm.com  Tue Feb  2 05:42:08 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 2 Feb 2016 13:42:08 +0000
Subject: [PATCH v2 18/21] arm64: KVM: Introduce hyp_alternate_value helper
In-Reply-To: <20160201144103.GX1478@cbox>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-19-git-send-email-marc.zyngier@arm.com>
 <20160201144103.GX1478@cbox>
Message-ID: <56B0B230.6070600@arm.com>

On 01/02/16 14:41, Christoffer Dall wrote:
> On Mon, Jan 25, 2016 at 03:53:52PM +0000, Marc Zyngier wrote:
>> We already have hyp_alternate_select() to define a function pointer
>> that gets changed by a kernel feature or workaround.
>>
>> It would be useful to have a similar feature that resolves in a
>> direct value, without requiring a function call. For this purpose,
>> introduce hyp_alternate_value(), which returns one of two values
>> depending on the state of the alternative.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kvm/hyp/hyp.h | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
>> index 44eaff7..dc75fdb 100644
>> --- a/arch/arm64/kvm/hyp/hyp.h
>> +++ b/arch/arm64/kvm/hyp/hyp.h
>> @@ -144,6 +144,17 @@ typeof(orig) * __hyp_text fname(void)					\
>>  	return val;							\
>>  }
>>  
>> +#define hyp_alternate_value(fname, orig, alt, cond)			\
>> +typeof(orig) __hyp_text fname(void)					\
>> +{									\
>> +	typeof(alt) val = orig;						\
>> +	asm volatile(ALTERNATIVE("nop		\n",			\
>> +				 "mov	%0, %1	\n",			\
>> +				 cond)					\
>> +		     : "+r" (val) : "r" ((typeof(orig))alt));		\
>> +	return val;							\
>> +}
>> +
>>  void __vgic_v2_save_state(struct kvm_vcpu *vcpu);
>>  void __vgic_v2_restore_state(struct kvm_vcpu *vcpu);
>>  
>> -- 
>> 2.1.4
>>
> I'm really not convinced that this is more readable than simply defining
> a function where needed.  Perhaps the thing that needs a definition is
> the "asm volatile(ALTERNATIVE(...))" part?  I also don't see why any of
> this is specific to KVM or Hyp ?

I can easily factor out the whole asm volatile part. What I'm trying to
avoid is an additional function call, but maybe we shouldn't need to
worry about the overhead on page faults altogether?

I'll drop it for now, and we can reconsider it later.

	M.
-- 
Jazz is not dead. It just smells funny...


From LW at KARO-electronics.de  Tue Feb  2 06:02:53 2016
From: LW at KARO-electronics.de (Lothar =?UTF-8?B?V2HDn21hbm4=?=)
Date: Tue, 2 Feb 2016 15:02:53 +0100
Subject: [PATCH] ARM: dts: imx51: add support for Ka-Ro electronics TX51
 modules
In-Reply-To: <20160202061842.GB8307@tiger>
References: <1453292619-3560-1-git-send-email-LW@KARO-electronics.de>
 <20160202061842.GB8307@tiger>
Message-ID: <20160202150253.340d8e86@ipc1.ka-ro>

Hi,

On Tue, 2 Feb 2016 14:18:42 +0800 Shawn Guo wrote:
> On Wed, Jan 20, 2016 at 01:23:39PM +0100, Lothar Wa?mann wrote:
> > The TX51-8xxx module series is a System On Module manufactured by
> >   Ka-Ro electronics GmbH with the following characteristics:
> >   Processor    Freescale i.MX515
> >                  up to 800 MHz (commercial)
> >                  up to 600 MHz (industrial)
> >   RAM          128/256MB mobile DDR-SDRAM
> >   ROM          128MB NAND Flash
> >   RTC          DS1339 Real Time Clock
> >   Power supply Single 3.1V to 5.5V
> >   Size         26mm SO-DIMM
> >   Temp. Range  0?C..70?C (-40?C..85?C)
> > 
> > Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
> > ---
> >  arch/arm/boot/dts/Makefile       |   3 +-
> >  arch/arm/boot/dts/imx51-tx51.dts | 749 +++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 751 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/boot/dts/imx51-tx51.dts
> > 
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index a4a6d70..ea70f34 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -277,7 +277,8 @@ dtb-$(CONFIG_SOC_IMX51) += \
> >  	imx51-babbage.dtb \
> >  	imx51-digi-connectcore-jsk.dtb \
> >  	imx51-eukrea-mbimxsd51-baseboard.dtb \
> > -	imx51-ts4800.dtb
> > +	imx51-ts4800.dtb \
> > +	imx51-tx51.dtb
> >  dtb-$(CONFIG_SOC_IMX53) += \
> >  	imx53-ard.dtb \
> >  	imx53-m53evk.dtb \
> > diff --git a/arch/arm/boot/dts/imx51-tx51.dts b/arch/arm/boot/dts/imx51-tx51.dts
> > new file mode 100644
> > index 0000000..80c5d60
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx51-tx51.dts
> > @@ -0,0 +1,749 @@
> > +/*
> > + * Copyright 2012-2014 Lothar Wa?mann <LW at KARO-electronics.de>
> > + *
> > + * The code contained herein is licensed under the GNU General Public
> > + * License. You may obtain a copy of the GNU General Public License
> > + * Version 2 at the following locations:
> > + *
> > + * http://www.opensource.org/licenses/gpl-license.html
> > + * http://www.gnu.org/copyleft/gpl.html
> > + */
> 
> We generally suggest GPL/X11 dual license for new dts to consider
> non-Linux device tree users.
> 
OK.

> > +
> > +/dts-v1/;
> > +#include "imx51.dtsi"
> > +#include <dt-bindings/pwm/pwm.h>
> > +#include <dt-bindings/interrupt-controller/irq.h>
> > +
> > +/ {
> > +	model = "Ka-Ro electronics TX51 module";
> > +	compatible = "karo,tx51", "fsl,imx51";
> > +
> > +	aliases {
> > +		backlight = &backlight;
> > +		display = &display;
> > +		i2c1 = &i2c_gpio;
> > +		usbotg = &usbotg;
> > +		wlan0 = &wlan0;
> > +	};
> > +
> > +	chosen {
> > +		stdout-path = &uart1;
> > +	};
> > +
> > +	backlight: pwm-backlight {
> > +		compatible = "pwm-backlight";
> > +		pwms = <&pwm1 0 500000 PWM_POLARITY_INVERTED>;
> > +		power-supply = <&reg_3v3>;
> > +		brightness-levels = <
> > +			  0  1  2  3  4  5  6  7  8  9
> > +			 10 11 12 13 14 15 16 17 18 19
> > +			 20 21 22 23 24 25 26 27 28 29
> > +			 30 31 32 33 34 35 36 37 38 39
> > +			 40 41 42 43 44 45 46 47 48 49
> > +			 50 51 52 53 54 55 56 57 58 59
> > +			 60 61 62 63 64 65 66 67 68 69
> > +			 70 71 72 73 74 75 76 77 78 79
> > +			 80 81 82 83 84 85 86 87 88 89
> > +			 90 91 92 93 94 95 96 97 98 99
> > +			100
> > +		>;
> > +		default-brightness-level = <50>;
> > +	};
> > +
> > +	clocks {
> > +		ckih1 {
> > +			clock-frequency = <0>;
> > +		};
> > +
> > +		mclk: clock at 0 {
> 
> I would like to see these fixed rate clocks are named in a consistent
> way, maybe just drop 'reg' property and use a unique clock name to align
> with what imx51.dtsi does.
> 
OK.

> > +			compatible = "fixed-clock";
> > +			reg = <0>;
> > +			#clock-cells = <0>;
> > +			clock-output-names = "mclk";
> > +			clock-frequency = <26000000>;
> > +		};
> > +
> > +		clk_26M: clock at 1 {
> > +			compatible = "fixed-clock";
> > +			reg = <1>;
> > +			#clock-cells = <0>;
> > +			clock-output-names = "clk_26M";
> > +			clock-frequency = <26000000>;
> > +			gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
> > +		};
> > +
> > +		wlan_ref_clk: wlan-ref-clk {
> > +			compatible = "ti,wilink-clock";
> 
> I do not see this compatible string is documented anywhere.  And how is
> this compatible string used by kernel?
> 
This is a relic from a Test of a TI Wifi adapter.
Will be removed.

[...]
> > +	regulators {
> > +		compatible = "simple-bus";
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		reg_2v5: regulator at 0 {
> 
> Device tree maintainers do not like the fake simple-bus container node.
> We are asked to put these fixed regulators directly under root node,
> with a unique node name like:
> 
> 	reg_xxx: regulator-xxx {
> 		...
> 	};
> 
OK.

> > +	usbphy {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +		compatible = "simple-bus";
> > +
> > +		usbh1phy: usbphy at 0 {
> > +			compatible = "usb-nop-xceiv";
> > +			reg = <0>;
> > +			clocks = <&clk_26M>;
> > +			clock-names = "main_clk";
> > +		};
> 
> This should probably go with the same way as fixed regulators.
> 
This is modeled exactly after the code in imx51.dtsi:
|	usbphy {
|		#address-cells = <1>;
|		#size-cells = <0>;
|		compatible = "simple-bus";
|
|		usbphy0: usbphy at 0 {
|			compatible = "usb-nop-xceiv";
|			reg = <0>;
|			clocks = <&clks IMX5_CLK_USB_PHY_GATE>;
|			clock-names = "main_clk";
|		};
|	};

> > +	};
> > +
> > +	wlan0: tiwi-ble {
> > +		compatible = "ti,wilink6";
> 
> Undocumented compatible string.
>
See above.
 
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_wlan0>;
> > +		clocks = <&wlan_ref_clk>;
> > +		clock-names = "refclock";
> > +		interrupt-parent = <&gpio1>;
> > +		interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
> > +	};
> > +};
> > +
> > +&audmux {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_ssi1>;
> > +	status = "okay";
> > +};
> > +
> > +&ecspi1 {
> > +	fsl,spi-num-chipselects = <2>;
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_ecspi1>;
> > +	cs-gpios = <&gpio4 24 GPIO_ACTIVE_LOW>,
> > +		   <&gpio4 25 GPIO_ACTIVE_LOW>;
> > +	status = "okay";
> > +
> > +	spidev0: spi at 0 {
> > +		compatible = "spidev";
> > +		reg = <0>;
> > +		spi-max-frequency = <54000000>;
> > +	};
> > +
> > +	spidev1: spi at 1 {
> > +		compatible = "spidev";
> > +		reg = <1>;
> > +		spi-max-frequency = <54000000>;
> > +	};
> > +};
> > +
> > +&esdhc1 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_esdhc1>;
> > +	cd-gpios = <&gpio3 8 GPIO_ACTIVE_LOW>;
> > +	fsl,wp-controller;
> > +	status = "okay";
> > +};
> > +
> > +&esdhc2 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_esdhc2 &pinctrl_wlan0>;
> > +	vmmc-supply = <&reg_wlan0>;
> > +	bus-width = <4>;
> > +	no-1-8-v;
> > +	fsl,wp-controller;
> > +	cap-sdio-irq;
> > +	non-removable;
> > +	//cd-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>;
> 
> Drop it.
> 
This also stems from the Wifi adapter test...

> > +	status = "okay";
> > +};
> > +
> > +&fec {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_fec>;
> > +	phy-mode = "mii";
> > +//	phy-handle = <&phy0>;
> > +	local-mac-address = [000000000000]; /* will be set by U-Boot */
> > +	status = "okay";
> > +
> > +	phy0: ethernet-phy at 0 {
> > +		interrupt-parent = <&gpio3>;
> > +		interrupts = <18 0>;
> > +		device_type = "ethernet-phy";
> > +	};
> 
> This probably works, but I think we should follow the more standard
> bindings to put it like the following?
> 
> 
> 	phy-handle = <&phy0>;
> 
> 	mdio {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 
> 		phy0: ethernet-phy at 0 {
> 			interrupt-parent = <&gpio3>;
> 			interrupts = <18 0>;
> 			device_type = "ethernet-phy";
> 		};
> 	};
> 
OK.
 
> > +};
> > +
> > +&ipu {
> > +	status = "okay";
> > +};
> > +
> > +&i2c2 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_i2c2>;
> > +	status = "okay";
> > +
> > +	sgtl5000: sgtl5000 at 0a {
> 
> Use generic name like 'codec' for node might comply to DT convention
> better.
> 
OK.

> > +		compatible = "fsl,sgtl5000";
> > +		reg = <0x0a>;
> > +		clocks = <&mclk>;
> > +		VDDA-supply = <&reg_2v5>;
> > +		VDDIO-supply = <&reg_3v3>;
> > +	};
> > +
> > +	polytouch: edt-ft5x06 at 38 {
> > +		compatible = "edt,edt-ft5x06";
> > +		reg = <0x38>;
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_edt_ft5x06>;
> > +		interrupt-parent = <&gpio1>;
> > +		interrupts = <5 0>;
> > +		reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
> > +		wake-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>;
> > +	};
> > +
> > +	touchscreen: tsc2007 at 48 {
> 
> 	tsc2007: touchscreen at 48 {
> 
> > +		compatible = "ti,tsc2007";
> > +		reg = <0x48>;
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_tsc2007>;
> > +		interrupt-parent = <&gpio3>;
> > +		interrupts = <3 0>;
> > +		gpios = <&gpio3 3 GPIO_ACTIVE_LOW>;
> > +		ti,x-plate-ohms = <660>;
> > +		linux,wakeup;
> 
> Use the new standard 'wakeup-source' please.
> 
> https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/commit/?h=imx/dt&id=1c49ad21c2cae607193da4495489c751d7147df2
> 
OK.

> > +	};
> > +};
> > +
> > +&iomuxc {
> 
> Please move the node to the bottom of the file to make the reset a bit
> easier for reading.
> 
> > +	imx51-tx51 {
> 
> Since commit 5fcdf6a7ed95 (pinctrl: imx: Allow parsing DT without
> function nodes), this additional function container node can be saved.
> 
OK.

> > +		pinctrl_hog: hoggrp {
> > +			fsl,pins = <
> > +				MX51_PAD_GPIO1_7__GPIO1_7		0x20e0	/* 26MHz osc enable */
> > +			>;
> > +		};
> > +
> > +		pinctrl_ecspi1: ecspi1grp {
> > +			fsl,pins = <
> > +				MX51_PAD_CSPI1_SS0__ECSPI1_SS0		0x4
> > +				MX51_PAD_CSPI1_SS1__ECSPI1_SS1		0x4
> > +				MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK	0x5
> > +				MX51_PAD_CSPI1_MOSI__ECSPI1_MOSI	0x85
> > +				MX51_PAD_CSPI1_MISO__ECSPI1_MISO	0x185
> > +				MX51_PAD_CSPI1_RDY__ECSPI1_RDY		0x84
> > +			>;
> > +		};
> > +
> > +		pinctrl_edt_ft5x06: edt-ft5x056grp {
> 
> I would suggest to not use any hyphen in pinctrl group node name to make
> the naming looks more consistent.
> 
OK.

[...]
> > +
> > +		pinctrl_kpp: kppgrp-1 {
> 
> The '-1' suffix means nothing and can just be dropped.
> 
OK.

[...]
> > +&ssi1 {
> > +	fsl,mode = "i2s-slave";
> 
> The "i2s-slave" of fsl,mode is deprecated and can be dropped.
> 
OK.


Lothar Wa?mann


From horms at verge.net.au  Tue Feb  2 06:05:50 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Feb 2016 15:05:50 +0100
Subject: [PATCH 0/3] ARM: shmobile: SCU cleanup and consolidation
In-Reply-To: <1453994012-12696-1-git-send-email-geert+renesas@glider.be>
References: <1453994012-12696-1-git-send-email-geert+renesas@glider.be>
Message-ID: <20160202140550.GB4304@verge.net.au>

On Thu, Jan 28, 2016 at 04:13:29PM +0100, Geert Uytterhoeven wrote:
> 	Hi Magnus, Simon,
> 
> This patch series contains cleanups and consolidations of the SCU code
> for shmobile SoCs with Cortex-A9 CPU cores.
> 
> This has been tested on emev2/kzm9d, r8a7779/marzen, and sh73a0/kzm9g.
> 
> Thanks!

Thanks, I have queued these up.


From vladimir.murzin at arm.com  Tue Feb  2 06:06:59 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 02 Feb 2016 14:06:59 +0000
Subject: [PATCH v2 02/10] clockevents/drivers: add MPS2 Timer driver
In-Reply-To: <alpine.DEB.2.11.1602021351440.25254@nanos>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
 <1454413199-26573-3-git-send-email-vladimir.murzin@arm.com>
 <alpine.DEB.2.11.1602021351440.25254@nanos>
Message-ID: <56B0B803.8010003@arm.com>

On 02/02/16 13:04, Thomas Gleixner wrote:
> On Tue, 2 Feb 2016, Vladimir Murzin wrote:
>> +static int __init mps2_clockevent_init(struct device_node *np)
>> +{
>> +	void __iomem *base;
>> +	struct clk *clk;
>> +	struct clockevent_mps2 *ce;
>> +	u32 rate;
>> +	int irq, ret;
>> +	const char *name = "mps2-clkevt";
>> +
>> +	ret = of_property_read_u32(np, "clock-frequency", &rate);
>> +	if (ret) {
>> +		clk = of_clk_get(np, 0);
>> +		if (IS_ERR(clk)) {
>> +			ret = PTR_ERR(clk);
>> +			pr_err("failed to get clock for clockevent: %d\n", ret);
>> +			goto err_clk_get;
>> +		}
>> +
>> +		ret = clk_prepare_enable(clk);
>> +		if (ret) {
>> +			pr_err("failed to enable clock for clockevent: %d\n", ret);
>> +			clk_put(clk);
>> +			goto err_clk_enable;
>> +		}
>> +
>> +		rate = clk_get_rate(clk);
>> +	}
> 
> So in case that "clock-frequency" is available in DT, what enables and
> configures the clock?

They are fixed-clock, so I ended up this *cough* mess *cough* shortcut.
I'd be glad if you share your thoughts what is preferred way to cope
with it (is it worth to do at all?)

> 
>> +err_ia_alloc:
>> +	kfree(ce);
>> +err_ce_alloc:
>> +err_get_irq:
>> +	iounmap(base);
>> +err_iomap:
>> +	clk_disable_unprepare(clk);
> 
> clk is not initialized when "clock-frequency" is available in DT. The compiler
> should have told you ....

Shame on me, I've completely messed it up :( Thanks for pointing at it,
I'll fix this an other places you pointed at...

> 
>> +err_clk_enable:
>> +	clk_put(clk);
> 
> Put without get ....

or double clk_put() if clk_prepare_enable() failed... shame, shame, shame

> 
>> +static int __init mps2_clocksource_init(struct device_node *np)
>> +{
>> +	void __iomem *base;
>> +	struct clk *clk;
>> +	u32 rate;
>> +	int ret;
>> +	const char *name = "mps2-clksrc";
>> +
>> +	ret = of_property_read_u32(np, "clock-frequency", &rate);
>> +	if (ret) {
>> +		clk = of_clk_get(np, 0);
>> +		if (IS_ERR(clk)) {
>> +			ret = PTR_ERR(clk);
>> +			pr_err("failed to get clock for clocksource: %d\n", ret);
>> +			goto err_clk_get;
>> +		}
>> +
>> +		ret = clk_prepare_enable(clk);
>> +		if (ret) {
>> +			pr_err("failed to enable clock for clocksource: %d\n", ret);
>> +			clk_put(clk);
>> +			goto err_clk_enable;
>> +		}
>> +
>> +		rate = clk_get_rate(clk);
>> +	}
> 
> Same problem as above.
> 
>> +err_clocksource_init:
>> +	iounmap(base);
>> +err_iomap:
>> +	clk_disable_unprepare(clk);
> 
> Ditto.
> 
>> +err_clk_enable:
>> +	clk_put(clk);
> 
> Ditto.
> 
>> +err_clk_get:
>> +	return ret;
>> +}
>> +
>> +static void __init mps2_timer_init(struct device_node *np)
>> +{
>> +	static int has_clocksource, has_clockevent;
>> +	int ret;
>> +
>> +	if (!has_clocksource) {
>> +		ret = mps2_clocksource_init(np);
>> +		if (!ret) {
>> +			has_clocksource = 1;
>> +			return;
>> +		}
>> +	}
>> +
>> +	if (!has_clockevent) {
>> +		ret = mps2_clockevent_init(np);
>> +		if (!ret) {
>> +			has_clockevent = 1;
>> +			return;
>> +		}
>> +	}
> 
> You take randomly the first timer as clocksource and the second one as
> clockevent. If clocksource init fails, you try to install it as clockevent.
> 
> Sorry, but I really cannot follow the logic here.
> 

It has been done as a response on Daniel's comment [1]. I'm quite happy
to get known what init sequence is expected here.

[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/388223.html

Thanks for your time, Thomas!

Vladimir

> Thanks,
> 
> 	tglx
> 
> 
> 



From horms at verge.net.au  Tue Feb  2 06:07:38 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 2 Feb 2016 15:07:38 +0100
Subject: [PATCH 0/2] ARM: shmobile: Remove legacy machine_desc.map_io()
 callbacks
In-Reply-To: <1453994246-12886-1-git-send-email-geert+renesas@glider.be>
References: <1453994246-12886-1-git-send-email-geert+renesas@glider.be>
Message-ID: <20160202140738.GC4304@verge.net.au>

On Thu, Jan 28, 2016 at 04:17:24PM +0100, Geert Uytterhoeven wrote:
> 	Hi Simon, Magnus,
> 
> This patch series removes the legacy machine_desc.map_io() callback for
> SoCs that no longer rely on it, but use ioremap() instead.
> 
> The patch for emev2 depends on "ARM: shmobile: Consolidate SCU mapping
> code" ("FIXME" commit ID reference to be updated).
> 
> Thanks!

Thanks, I have queued these up.


From matthias.bgg at gmail.com  Tue Feb  2 06:09:24 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 2 Feb 2016 15:09:24 +0100
Subject: [PATCH v2 3/3] ARM64: dts: mt8173: Add CPU OPP, clock and
 regulator supply properties
In-Reply-To: <56B08DA4.8070207@gmail.com>
References: <1451197318-12418-1-git-send-email-pi-cheng.chen@linaro.org>
 <1451197318-12418-4-git-send-email-pi-cheng.chen@linaro.org>
 <20151228031340.GD3598@ubuntu> <3310024.mO5K6yH9vU@wuerfel>
 <20160105102455.GA30120@ubuntu> <56B08DA4.8070207@gmail.com>
Message-ID: <56B0B894.9040706@gmail.com>



On 02/02/16 12:06, Matthias Brugger wrote:
>
>
> On 05/01/16 11:24, Viresh Kumar wrote:
>> On 05-01-16, 11:21, Arnd Bergmann wrote:
>>> On Monday 28 December 2015 08:43:40 Viresh Kumar wrote:
>>>> On 27-12-15, 14:21, Pi-Cheng Chen wrote:
>>>>> Add operating-points-v2, clock, and regulator supply properties
>>>>> required by mt8173-cpufreq driver to enable it.
>>>>>
>>>>> Signed-off-by: Pi-Cheng Chen <pi-cheng.chen at linaro.org>
>>>>> ---
>>>>> This patch is based on the patch[1] that adds underlying clock MUX for
>>>>> MT8173 which is needed by mt8173-cpufreq driver but not yet picked.
>>>>>
>>>>> [1] http://article.gmane.org/gmane.linux.kernel.clk/325
>>>>> ---
>>>>>   arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 ++++++
>>>>>   arch/arm64/boot/dts/mediatek/mt8173.dtsi    | 90
>>>>> +++++++++++++++++++++++++++++
>>>>>   2 files changed, 108 insertions(+)
>>>>
>>>> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
>>>>
>>>
>>> This patch is now in linux-next through Rafael's pm tree, and it
>>> breaks the
>>> arm64 build:
>>>
>>>          arm64-defconfig
>>> Error: ../arch/arm64/boot/dts/mediatek/mt8173.dtsi:132.24-25 syntax
>>> error
>>>
>>>
>>> Please revert.
>>>
>>> In the future, please send all dts changes through the proper maintainer
>>> channels (-> Mattias -> arm-soc), and make sure they actually build.
>>
>> Rafael has already reverted that, AFAIK, after Mark Brown reported the
>> build issue.
>>
>
> Applied to v4.5-next/dts
>

I oversaw that this needs a clock patch, which is not yet mainlined.
I deleted this patch from my tree.


From andre.przywara at arm.com  Tue Feb  2 06:16:54 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 2 Feb 2016 14:16:54 +0000
Subject: [PATCH 3/5] clk: sunxi: convert current clocks registration to
 CLK_OF_DECLARE
In-Reply-To: <1454402834-6385-4-git-send-email-maxime.ripard@free-electrons.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454402834-6385-4-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <56B0BA56.10500@arm.com>

Hi Maxime,

On 02/02/16 08:47, Maxime Ripard wrote:
> The current clock registration and protection code has a few drawbacks, the
> two main ones being that we create a lot of orphans clock in the
> registration phase, which will be troublesome when we will start being less
> relaxed about them.
> 
> The protection code also relies on clkdev, which we don't really use but
> for this particular case.
> 
> Fix both at the same time by moving everyone to the CLK_OF_DECLARE that
> will probe our clock tree in the right and thus avoid orphans, and by
> protecting directly the clock returned by our registration function.

I very much appreciate this cleanup and like the idea. Any chance we can
have this rather quickly, so that I can rebase the A64 support series on it?

One issue below, though:

...

> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
>  drivers/clk/sunxi/clk-sunxi.c | 150 +++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 133 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index a3d706f5b21c..da6c1bc763d1 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -585,6 +585,41 @@ static struct clk * __init sunxi_factors_clk_setup(struct device_node *node,
>  	return sunxi_factors_register(node, data, &clk_lock, reg);
>  }
>  
> +static void __init sun4i_pll1_clk_setup(struct device_node *node)
> +{
> +	sunxi_factors_clk_setup(node, &sun4i_pll1_data);
> +}
> +CLK_OF_DECLARE(sun4i_pll1, "allwinner,sun4i-a10-pll1-clk",
> +	       sun4i_pll1_clk_setup);
> +
> +static void __init sun6i_pll1_clk_setup(struct device_node *node)
> +{
> +	sunxi_factors_clk_setup(node, &sun6i_a31_pll1_data);
> +}
> +CLK_OF_DECLARE(sun6i_pll1, "allwinner,sun6i-a31-pll1-clk",
> +	       sun6i_pll1_clk_setup);
> +
> +static void __init sun8i_pll1_clk_setup(struct device_node *node)
> +{
> +	sunxi_factors_clk_setup(node, &sun8i_a23_pll1_data);
> +}
> +CLK_OF_DECLARE(sun8i_pll1, "allwinner,sun8i-a23-pll1-clk",
> +	       sun8i_pll1_clk_setup);
> +
> +static void __init sun7i_pll4_clk_setup(struct device_node *node)
> +{
> +	sunxi_factors_clk_setup(node, &sun7i_a20_pll4_data);
> +}
> +CLK_OF_DECLARE(sun7i_pll4, "allwinner,sun7i-a20-pll4-clk",
> +	       sun7i_pll4_clk_setup);
> +
> +static void __init sun5i_ahb_clk_setup(struct device_node *node)
> +{
> +	sunxi_factors_clk_setup(node, &sun5i_a13_ahb_data);
> +}
> +CLK_OF_DECLARE(sun5i_ahb, "allwinner,sun5i-a13-ahb-clk",
> +	       sun5i_ahb_clk_setup);
> +
>  static void __init sun6i_ahb1_clk_setup(struct device_node *node)
>  {
>  	sunxi_factors_clk_setup(node, &sun6i_ahb1_data);
> @@ -592,6 +627,20 @@ static void __init sun6i_ahb1_clk_setup(struct device_node *node)
>  CLK_OF_DECLARE(sun6i_a31_ahb1, "allwinner,sun6i-a31-ahb1-clk",
>  	       sun6i_ahb1_clk_setup);
>  
> +static void __init sun4i_apb1_clk_setup(struct device_node *node)
> +{
> +	sunxi_factors_clk_setup(node, &sun4i_apb1_data);
> +}
> +CLK_OF_DECLARE(sun4i_apb1, "allwinner,sun4i-a10-apb1-clk",
> +	       sun4i_apb1_clk_setup);
> +
> +static void __init sun7i_out_clk_setup(struct device_node *node)
> +{
> +	sunxi_factors_clk_setup(node, &sun7i_a20_out_data);
> +}
> +CLK_OF_DECLARE(sun7i_out, "allwinner,sun7i-a20-out-clk",
> +	       sun7i_out_clk_setup);
> +
>  
>  /**
>   * sunxi_mux_clk_setup() - Setup function for muxes
> @@ -642,6 +691,34 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
>  	return clk;
>  }
>  
> +static void __init sun4i_cpu_clk_setup(struct device_node *node)
> +{
> +	struct clk *clk;
> +
> +	clk = sunxi_mux_clk_setup(node, &sun4i_cpu_mux_data);
> +	if (!clk)
> +		return;
> +
> +	/* Protect CPU clock */
> +	__clk_get(clk);
> +	clk_prepare_enable(clk);
> +}
> +CLK_OF_DECLARE(sun4i_cpu, "allwinner,sun4i-a10-cpu-clk",
> +	       sun4i_cpu_clk_setup);
> +
> +static void __init sun6i_ahb1_mux_clk_setup(struct device_node *node)
> +{
> +	sunxi_mux_clk_setup(node, &sun6i_a31_ahb1_mux_data);
> +}
> +CLK_OF_DECLARE(sun6i_ahb1_mux, "allwinner,sun6i-a31-ahb1-mux-clk",
> +	       sun6i_ahb1_mux_clk_setup);
> +
> +static void __init sun8i_ahb2_clk_setup(struct device_node *node)
> +{
> +	sunxi_mux_clk_setup(node, &sun8i_h3_ahb2_mux_data);
> +}
> +CLK_OF_DECLARE(sun8i_ahb2, "allwinner,sun8i-a31-ahb2-clk",
> +	       sun8i_ahb2_clk_setup);

I don't find this clock in my tree (which is mripard/sunxi/for-next).
Instead I only have "allwinner,sun8i-h3-ahb2-clk", as mentioned below.
But as you remove this clock below from the old code and instead
instantiate this new clock here, this looks somehow wrong to me. Can you
confirm this or am I utterly confused?

Apart from that I checked each and every clock mentioned in this patch
and can confirm that the transformation is correct. So if you fix this,
I can send a Reviewed-by.

Cheers,
Andre.

>  
>  
>  /**
> @@ -723,6 +800,34 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
>  	}
>  }
>  
> +static void __init sun4i_ahb_clk_setup(struct device_node *node)
> +{
> +	sunxi_divider_clk_setup(node, &sun4i_ahb_data);
> +}
> +CLK_OF_DECLARE(sun4i_ahb, "allwinner,sun4i-a10-ahb-clk",
> +	       sun4i_ahb_clk_setup);
> +
> +static void __init sun4i_apb0_clk_setup(struct device_node *node)
> +{
> +	sunxi_divider_clk_setup(node, &sun4i_apb0_data);
> +}
> +CLK_OF_DECLARE(sun4i_apb0, "allwinner,sun4i-a10-apb0-clk",
> +	       sun4i_apb0_clk_setup);
> +
> +static void __init sun4i_axi_clk_setup(struct device_node *node)
> +{
> +	sunxi_divider_clk_setup(node, &sun4i_axi_data);
> +}
> +CLK_OF_DECLARE(sun4i_axi, "allwinner,sun4i-a10-axi-clk",
> +	       sun4i_axi_clk_setup);
> +
> +static void __init sun8i_axi_clk_setup(struct device_node *node)
> +{
> +	sunxi_divider_clk_setup(node, &sun8i_a23_axi_data);
> +}
> +CLK_OF_DECLARE(sun8i_axi, "allwinner,sun8i-a23-axi-clk",
> +	       sun8i_axi_clk_setup);
> +
>  
>  /**
>   * sunxi_gates_clk_setup() - Setup function for leaf gates on clocks
> @@ -934,42 +1039,53 @@ free_clkdata:
>  	return NULL;
>  }
>  
> +static void __init sun4i_pll5_clk_setup(struct device_node *node)
> +{
> +	struct clk **clks;
> +
> +	clks = sunxi_divs_clk_setup(node, &pll5_divs_data);
> +	if (!clks)
> +		return;
> +
> +	/* Protect PLL5_DDR */
> +	__clk_get(clks[0]);
> +	clk_prepare_enable(clks[0]);
> +}
> +CLK_OF_DECLARE(sun4i_pll5, "allwinner,sun4i-a10-pll5-clk",
> +	       sun4i_pll5_clk_setup);
> +
> +static void __init sun4i_pll6_clk_setup(struct device_node *node)
> +{
> +	sunxi_divs_clk_setup(node, &pll6_divs_data);
> +}
> +CLK_OF_DECLARE(sun4i_pll6, "allwinner,sun4i-a10-pll6-clk",
> +	       sun4i_pll6_clk_setup);
> +
> +static void __init sun6i_pll6_clk_setup(struct device_node *node)
> +{
> +	sunxi_divs_clk_setup(node, &sun6i_a31_pll6_divs_data);
> +}
> +CLK_OF_DECLARE(sun6i_pll6, "allwinner,sun6i-a31-pll6-clk",
> +	       sun6i_pll6_clk_setup);
>  
>  
>  /* Matches for factors clocks */
>  static const struct of_device_id clk_factors_match[] __initconst = {
> -	{.compatible = "allwinner,sun4i-a10-pll1-clk", .data = &sun4i_pll1_data,},
> -	{.compatible = "allwinner,sun6i-a31-pll1-clk", .data = &sun6i_a31_pll1_data,},
> -	{.compatible = "allwinner,sun8i-a23-pll1-clk", .data = &sun8i_a23_pll1_data,},
> -	{.compatible = "allwinner,sun7i-a20-pll4-clk", .data = &sun7i_a20_pll4_data,},
> -	{.compatible = "allwinner,sun5i-a13-ahb-clk", .data = &sun5i_a13_ahb_data,},
> -	{.compatible = "allwinner,sun4i-a10-apb1-clk", .data = &sun4i_apb1_data,},
> -	{.compatible = "allwinner,sun7i-a20-out-clk", .data = &sun7i_a20_out_data,},
>  	{}
>  };
>  
>  /* Matches for divider clocks */
>  static const struct of_device_id clk_div_match[] __initconst = {
> -	{.compatible = "allwinner,sun4i-a10-axi-clk", .data = &sun4i_axi_data,},
> -	{.compatible = "allwinner,sun8i-a23-axi-clk", .data = &sun8i_a23_axi_data,},
> -	{.compatible = "allwinner,sun4i-a10-ahb-clk", .data = &sun4i_ahb_data,},
> -	{.compatible = "allwinner,sun4i-a10-apb0-clk", .data = &sun4i_apb0_data,},
>  	{}
>  };
>  
>  /* Matches for divided outputs */
>  static const struct of_device_id clk_divs_match[] __initconst = {
> -	{.compatible = "allwinner,sun4i-a10-pll5-clk", .data = &pll5_divs_data,},
> -	{.compatible = "allwinner,sun4i-a10-pll6-clk", .data = &pll6_divs_data,},
> -	{.compatible = "allwinner,sun6i-a31-pll6-clk", .data = &sun6i_a31_pll6_divs_data,},
>  	{}
>  };
>  
>  /* Matches for mux clocks */
>  static const struct of_device_id clk_mux_match[] __initconst = {
> -	{.compatible = "allwinner,sun4i-a10-cpu-clk", .data = &sun4i_cpu_mux_data,},
> -	{.compatible = "allwinner,sun6i-a31-ahb1-mux-clk", .data = &sun6i_a31_ahb1_mux_data,},
> -	{.compatible = "allwinner,sun8i-h3-ahb2-clk", .data = &sun8i_h3_ahb2_mux_data,},
>  	{}
>  };
>  
> 


From marc.zyngier at arm.com  Tue Feb  2 06:24:16 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 2 Feb 2016 14:24:16 +0000
Subject: [PATCH v2 19/21] arm64: KVM: Move most of the fault decoding to C
In-Reply-To: <20160201152122.GY1478@cbox>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-20-git-send-email-marc.zyngier@arm.com>
 <20160201152122.GY1478@cbox>
Message-ID: <56B0BC10.40309@arm.com>

On 01/02/16 15:21, Christoffer Dall wrote:
> On Mon, Jan 25, 2016 at 03:53:53PM +0000, Marc Zyngier wrote:
>> The fault decoding process (including computing the IPA in the case
>> of a permission fault) would be much better done in C code, as we
>> have a reasonable infrastructure to deal with the VHE/non-VHE
>> differences.
>>
>> Let's move the whole thing to C, including the workaround for
>> erratum 834220, and just patch the odd ESR_EL2 access remaining
>> in hyp-entry.S.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kernel/asm-offsets.c |  3 --
>>  arch/arm64/kvm/hyp/hyp-entry.S  | 69 +++--------------------------------------
>>  arch/arm64/kvm/hyp/switch.c     | 54 ++++++++++++++++++++++++++++++++
>>  3 files changed, 59 insertions(+), 67 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
>> index fffa4ac6..b0ab4e9 100644
>> --- a/arch/arm64/kernel/asm-offsets.c
>> +++ b/arch/arm64/kernel/asm-offsets.c
>> @@ -110,9 +110,6 @@ int main(void)
>>    DEFINE(CPU_USER_PT_REGS,	offsetof(struct kvm_regs, regs));
>>    DEFINE(CPU_FP_REGS,		offsetof(struct kvm_regs, fp_regs));
>>    DEFINE(VCPU_FPEXC32_EL2,	offsetof(struct kvm_vcpu, arch.ctxt.sys_regs[FPEXC32_EL2]));
>> -  DEFINE(VCPU_ESR_EL2,		offsetof(struct kvm_vcpu, arch.fault.esr_el2));
>> -  DEFINE(VCPU_FAR_EL2,		offsetof(struct kvm_vcpu, arch.fault.far_el2));
>> -  DEFINE(VCPU_HPFAR_EL2,	offsetof(struct kvm_vcpu, arch.fault.hpfar_el2));
>>    DEFINE(VCPU_HOST_CONTEXT,	offsetof(struct kvm_vcpu, arch.host_cpu_context));
>>  #endif
>>  #ifdef CONFIG_CPU_PM
>> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
>> index 9e0683f..213de52 100644
>> --- a/arch/arm64/kvm/hyp/hyp-entry.S
>> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
>> @@ -19,7 +19,6 @@
>>  
>>  #include <asm/alternative.h>
>>  #include <asm/assembler.h>
>> -#include <asm/asm-offsets.h>
>>  #include <asm/cpufeature.h>
>>  #include <asm/kvm_arm.h>
>>  #include <asm/kvm_asm.h>
>> @@ -67,7 +66,11 @@ ENDPROC(__vhe_hyp_call)
>>  el1_sync:				// Guest trapped into EL2
>>  	save_x0_to_x3
>>  
>> +alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
>>  	mrs	x1, esr_el2
>> +alternative_else
>> +	mrs	x1, esr_el1
>> +alternative_endif
> 
> I suppose this is not technically part of what the patch description
> says it does, but ok...

That's what the "... and just patch the odd ESR_EL2 access remaining in
hyp-entry.S." meant. Would you prefer this as a separate patch?

> 
>>  	lsr	x2, x1, #ESR_ELx_EC_SHIFT
>>  
>>  	cmp	x2, #ESR_ELx_EC_HVC64
>> @@ -103,72 +106,10 @@ el1_trap:
>>  	cmp	x2, #ESR_ELx_EC_FP_ASIMD
>>  	b.eq	__fpsimd_guest_restore
>>  
>> -	cmp	x2, #ESR_ELx_EC_DABT_LOW
>> -	mov	x0, #ESR_ELx_EC_IABT_LOW
>> -	ccmp	x2, x0, #4, ne
>> -	b.ne	1f		// Not an abort we care about
>> -
>> -	/* This is an abort. Check for permission fault */
>> -alternative_if_not ARM64_WORKAROUND_834220
>> -	and	x2, x1, #ESR_ELx_FSC_TYPE
>> -	cmp	x2, #FSC_PERM
>> -	b.ne	1f		// Not a permission fault
>> -alternative_else
>> -	nop			// Use the permission fault path to
>> -	nop			// check for a valid S1 translation,
>> -	nop			// regardless of the ESR value.
>> -alternative_endif
>> -
>> -	/*
>> -	 * Check for Stage-1 page table walk, which is guaranteed
>> -	 * to give a valid HPFAR_EL2.
>> -	 */
>> -	tbnz	x1, #7, 1f	// S1PTW is set
>> -
>> -	/* Preserve PAR_EL1 */
>> -	mrs	x3, par_el1
>> -	stp	x3, xzr, [sp, #-16]!
>> -
>> -	/*
>> -	 * Permission fault, HPFAR_EL2 is invalid.
>> -	 * Resolve the IPA the hard way using the guest VA.
>> -	 * Stage-1 translation already validated the memory access rights.
>> -	 * As such, we can use the EL1 translation regime, and don't have
>> -	 * to distinguish between EL0 and EL1 access.
>> -	 */
>> -	mrs	x2, far_el2
>> -	at	s1e1r, x2
>> -	isb
>> -
>> -	/* Read result */
>> -	mrs	x3, par_el1
>> -	ldp	x0, xzr, [sp], #16	// Restore PAR_EL1 from the stack
>> -	msr	par_el1, x0
>> -	tbnz	x3, #0, 3f		// Bail out if we failed the translation
>> -	ubfx	x3, x3, #12, #36	// Extract IPA
>> -	lsl	x3, x3, #4		// and present it like HPFAR
>> -	b	2f
>> -
>> -1:	mrs	x3, hpfar_el2
>> -	mrs	x2, far_el2
>> -
>> -2:	mrs	x0, tpidr_el2
>> -	str	w1, [x0, #VCPU_ESR_EL2]
>> -	str	x2, [x0, #VCPU_FAR_EL2]
>> -	str	x3, [x0, #VCPU_HPFAR_EL2]
>> -
>> +	mrs	x0, tpidr_el2
>>  	mov	x1, #ARM_EXCEPTION_TRAP
>>  	b	__guest_exit
>>  
>> -	/*
>> -	 * Translation failed. Just return to the guest and
>> -	 * let it fault again. Another CPU is probably playing
>> -	 * behind our back.
>> -	 */
>> -3:	restore_x0_to_x3
>> -
>> -	eret
>> -
>>  el1_irq:
>>  	save_x0_to_x3
>>  	mrs	x0, tpidr_el2
>> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
>> index 0cadb7f..df2cce9 100644
>> --- a/arch/arm64/kvm/hyp/switch.c
>> +++ b/arch/arm64/kvm/hyp/switch.c
>> @@ -15,6 +15,7 @@
>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>   */
>>  
>> +#include <linux/types.h>
>>  #include <asm/kvm_asm.h>
>>  
>>  #include "hyp.h"
>> @@ -150,6 +151,55 @@ static void __hyp_text __vgic_restore_state(struct kvm_vcpu *vcpu)
>>  	__vgic_call_restore_state()(vcpu);
>>  }
>>  
>> +static hyp_alternate_value(__check_arm_834220,
>> +			   false, true,
>> +			   ARM64_WORKAROUND_834220);
>> +
>> +static bool __hyp_text __populate_fault_info(struct kvm_vcpu *vcpu)
>> +{
>> +	u64 esr = read_sysreg_el2(esr);
>> +	u8 ec = esr >> ESR_ELx_EC_SHIFT;
>> +	u64 hpfar, far;
>> +
>> +	vcpu->arch.fault.esr_el2 = esr;
>> +
>> +	if (ec != ESR_ELx_EC_DABT_LOW && ec != ESR_ELx_EC_IABT_LOW)
>> +		return true;
>> +
>> +	far = read_sysreg_el2(far);
>> +
>> +	if (!(esr & ESR_ELx_S1PTW) &&
>> +	    (__check_arm_834220() || (esr & ESR_ELx_FSC_TYPE) == FSC_PERM)) {
> 
> this is really hard to read.  How do you feel about putting the below
> block into its own function and changing to something like this:
> 
> /*
>  * The HPFAR can be invalid if the stage 2 fault did not happen during a
>  * stage 1 page table walk (the ESR_EL2.S1PTW bit is clear) and one of
>  * the two following cases are true:
>  *   1. The fault was due to a permission fault
>  *   2. The processor carries errata 834220
>  *
>  * Therefore, for all non S1PTW faults where we either have a permission
>  * fault or the errata workaround is enabled, we resolve the IPA using
>  * the AT instruction.
>  */
> if (!(esr & ESR_ELx_S1PTW) &&
>     (__check_arm_834220() || (esr & ESR_ELx_FSC_TYPE) == FSC_PERM)) {
>     	if (!__translate_far_to_ipa(&hpfar))
> 		return false; /* Translation failed, back to guest */
> } else {
> 	hpfar = read_sysreg(hpfar_el2);
> }
> 
> not sure if it helps that much, perhaps it's just complicated by nature.
> 
>> +		u64 par, tmp;
>> +
>> +		/*
>> +		 * Permission fault, HPFAR_EL2 is invalid. Resolve the
>> +		 * IPA the hard way using the guest VA.
>> +		 * Stage-1 translation already validated the memory
>> +		 * access rights. As such, we can use the EL1
>> +		 * translation regime, and don't have to distinguish
>> +		 * between EL0 and EL1 access.
>> +		 */
>> +		par = read_sysreg(par_el1);
> 
> in any cas I think we also need the comment about preserving par_el1
> here, which is only something we do because we may return early, IIUC.

Not only. At that point, we still haven't saved the vcpu sysregs, so we
most save/restore it in order to save it later for good. Not the fastest
thing, but I guess that everything sucks so much when we take a page
fault that it really doesn't matter.

> 
>> +		asm volatile("at s1e1r, %0" : : "r" (far));
>> +		isb();
>> +
>> +		tmp = read_sysreg(par_el1);
>> +		write_sysreg(par, par_el1);
>> +
>> +		if (unlikely(tmp & 1))
>> +			return false; /* Translation failed, back to guest */
>> +
> 
> nit: add comment /* Convert PAR to HPFAR format */
> 
>> +		hpfar = ((tmp >> 12) & ((1UL << 36) - 1)) << 4;
>> +	} else {
>> +		hpfar = read_sysreg(hpfar_el2);
>> +	}
>> +
>> +	vcpu->arch.fault.far_el2 = far;
>> +	vcpu->arch.fault.hpfar_el2 = hpfar;
>> +	return true;
>> +}
>> +
>>  static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
>>  {
>>  	struct kvm_cpu_context *host_ctxt;
>> @@ -181,9 +231,13 @@ static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
>>  	__debug_restore_state(vcpu, kern_hyp_va(vcpu->arch.debug_ptr), guest_ctxt);
>>  
>>  	/* Jump in the fire! */
>> +again:
>>  	exit_code = __guest_enter(vcpu, host_ctxt);
>>  	/* And we're baaack! */
>>  
>> +	if (exit_code == ARM_EXCEPTION_TRAP && !__populate_fault_info(vcpu))
>> +		goto again;
>> +
>>  	fp_enabled = __fpsimd_enabled();
>>  
>>  	__sysreg_save_guest_state(guest_ctxt);
>> -- 
>> 2.1.4
>>
> The good news are that I couldn't find any bugs in the code.

Right. So I've applied most of your comments directly, because they
definitely made sense. let's see how it looks on round 3.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From andre.przywara at arm.com  Tue Feb  2 06:24:20 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 2 Feb 2016 14:24:20 +0000
Subject: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for
 Allwinner A64 SoC
In-Reply-To: <20160202035852.6984db63@i7>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-6-git-send-email-andre.przywara@arm.com>
 <20160201182754.GA14737@excalibur.cnev.de> <56AFE0EC.8080207@arm.com>
 <20160202035852.6984db63@i7>
Message-ID: <56B0BC14.8060007@arm.com>

Hi,

On 02/02/16 01:58, Siarhei Siamashka wrote:
> On Mon, 1 Feb 2016 22:49:16 +0000
> Andr? Przywara <andre.przywara at arm.com> wrote:
> 
>> On 01/02/16 18:27, Karsten Merker wrote:
>>
>> Hi Karsten,
>>
>> thank you very much for your feedback!
>>
>>> On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote:  
>>>> Based on the Allwinner A64 user manual and on the previous sunxi
>>>> pinctrl drivers this introduces the pin multiplex assignments for
>>>> the ARMv8 Allwinner A64 SoC.
>>>> Port A is apparently used for the fixed function DRAM controller, so
>>>> the ports start at B here (the manual mentions "n from 1 to 7", so
>>>> not starting at 0).
>>>>
>>>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>>>> ---
>>>>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
>>>>  arch/arm64/Kconfig.platforms                       |   1 +
>>>>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
>>>>  drivers/pinctrl/sunxi/Makefile                     |   1 +
>>>>  drivers/pinctrl/sunxi/pinctrl-a64.c                | 606 +++++++++++++++++++++
>>>>  5 files changed, 613 insertions(+)
>>>>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>>>> index 9213b27..9050002 100644
>>>> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>>>> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>>>> @@ -21,6 +21,7 @@ Required properties:
>>>>    "allwinner,sun9i-a80-r-pinctrl"
>>>>    "allwinner,sun8i-a83t-pinctrl"
>>>>    "allwinner,sun8i-h3-pinctrl"
>>>> +  "allwinner,a64-pinctrl"  
>>>
>>> Hello,
>>>
>>> on all other Allwinner SoCs we use the SoC family as part of the
>>> compatible, as well as in the names of the Kconfig options. To
>>> keep things consistent, I would like to propose doing the same on
>>> Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of
>>> allwinner,a64-pinctrl.  
>>
>> Yes, I have been told this already. However I don't like this idea so
>> much, for the following reasons:
>> a) It is mostly redundant. The actual SoC (marketing) name is unique,
>> there is no sun6i-a20 or sun7i-a23.
>> b) It is not even helpful. If I got Maxime correctly, then the newer
>> sunxi generation numbers depend on the ARM _cores_ used in the SoC,
>> which is frankly the least interesting part from a Linux support
>> perspective. I would see some sense if it would reflect the generation
>> of IP blocks used, but so it is even more confusing to see that
>> sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely
>> different beast. The Allwinner marketing name tells you that, but the
>> sunxi one does not.
>> c) It is very confusing for people not dealing with it everyday. Just
>> because I own a BananaPi I know that the A20 is sun7i, but I am totally
>> lost when it comes to all the other names. And even now it took me about
>> a minute to find the appropriate Wiki page which explains part of that
>> story.
>> d) Most importantly ;-): It kills TAB completion, unless you know the
>> sunxi number, which is mostly not true as pointed out in c)
>>
>> So while I see that just a<somenumber> is not really very specific, I'd
>> rather do away with current naming scheme for the future. In this
>> particular case we have the vendor name as a name space identifier
>> already, so there is no possible confusion with ARM Cortex naming, for
>> instance.
>>
>> Also as this is now moving into the arm64 world, I'd like to use the
>> opportunity to fix things that are not really optimal, the naming is one
>> of them.
> 
> One of the problems is that A64 name is not unique. We have reasons
> to believe that there are also H64 and R18 out there using exactly
> the same die, but possibly available in different packaging (a different
> ball grid pitch? or maybe a different set of peripherals routed to the
> outside?). Early prototypes of the Pine64 board were using Allwinner R18
> and the Jide Remix Mini HTPC box is using Allwinner H64.

So if the differences are actually hidden from software, why would we
care? See below for an example on using DT to cover this.

> The bootloader sources from Allwinner are also referring to A64 as
> AW1689, which makes some sense because it is the chip id number that
> is accessible for runtime identification via reading the SRAM_VER_REG
> hardware register:
> 
>     http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG
> 
> So would it be a good idea to use "aw1689" as a compatible property
> in the DT instead of "a64"? Or maybe have "aw1689-a64" and
> "aw1689-h64", which would be similar to the existing "sun5i-a13"
> and "sun5i-a10s" naming convention?

I would be fine with that if it really reflects something in the
hardware. And I like it more than the rather arbitrary sun50i name. But
on the other hand it seems to be completely unknown so far (Google just
turns up this email and your sunxi-fel setup, basically). So I am not
sure we should introduce yet another naming scheme.

So looking at the compatible definition in the DT, this looks like a
perfect example of a fall-back name to me:
For the Pine64 we use "allwinner,a64", any other board could use say a:
"allwinner,h64", "allwinner,a64" compatible naming.
So as long as we don't need any h64 specifics, going with the A64
support code is fine. Should later the need arise to fix something for
the H64 only, we can add this easily and be covered automatically.

FWIW, I just have received this Remix Mini PC thing, which I ordered to
see what's with the H64 and to make sure the SoC/board abstraction is
right. So let me see what this version register looks like there and how
it behaves with the proposed kernel patches (should I be able to hack it).

Cheers,
Andre.


From peter.ujfalusi at ti.com  Tue Feb  2 06:27:06 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 2 Feb 2016 16:27:06 +0200
Subject: [PATCH 1/2] ARM: OMAP1: DMA: Provide dma_slave_map to omap-dma
In-Reply-To: <1454423227-31830-1-git-send-email-peter.ujfalusi@ti.com>
References: <1454423227-31830-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1454423227-31830-2-git-send-email-peter.ujfalusi@ti.com>

OMAP1 can not boot in DT mode and to be able to clean up the driver
regarding to the dmaengine API use (switching to the new API) the
device/slave -> filter mapping needs to be provided to the omap-dma driver.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/mach-omap1/dma.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index 7b02ed218a42..f6ba589cd312 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -25,6 +25,7 @@
 #include <linux/device.h>
 #include <linux/io.h>
 #include <linux/dma-mapping.h>
+#include <linux/dmaengine.h>
 #include <linux/omap-dma.h>
 #include <mach/tc.h>
 
@@ -265,6 +266,42 @@ static const struct platform_device_info omap_dma_dev_info = {
 	.num_res = 1,
 };
 
+/* OMAP730, OMAP850 */
+static const struct dma_slave_map omap7xx_sdma_map[] = {
+	{ "omap-mcbsp.1", "tx", SDMA_FILTER_PARAM(8) },
+	{ "omap-mcbsp.1", "rx", SDMA_FILTER_PARAM(9) },
+	{ "omap-mcbsp.2", "tx", SDMA_FILTER_PARAM(10) },
+	{ "omap-mcbsp.2", "rx", SDMA_FILTER_PARAM(11) },
+	{ "mmci-omap.0", "tx", SDMA_FILTER_PARAM(21) },
+	{ "mmci-omap.0", "rx", SDMA_FILTER_PARAM(22) },
+	{ "omap_udc", "rx0", SDMA_FILTER_PARAM(26) },
+	{ "omap_udc", "rx1", SDMA_FILTER_PARAM(27) },
+	{ "omap_udc", "rx2", SDMA_FILTER_PARAM(28) },
+	{ "omap_udc", "tx0", SDMA_FILTER_PARAM(29) },
+	{ "omap_udc", "tx1", SDMA_FILTER_PARAM(30) },
+	{ "omap_udc", "tx2", SDMA_FILTER_PARAM(31) },
+};
+
+/* OMAP1510, OMAP1610*/
+static const struct dma_slave_map omap1xxx_sdma_map[] = {
+	{ "omap-mcbsp.1", "tx", SDMA_FILTER_PARAM(8) },
+	{ "omap-mcbsp.1", "rx", SDMA_FILTER_PARAM(9) },
+	{ "omap-mcbsp.3", "tx", SDMA_FILTER_PARAM(10) },
+	{ "omap-mcbsp.3", "rx", SDMA_FILTER_PARAM(11) },
+	{ "omap-mcbsp.2", "tx", SDMA_FILTER_PARAM(16) },
+	{ "omap-mcbsp.2", "rx", SDMA_FILTER_PARAM(17) },
+	{ "mmci-omap.0", "tx", SDMA_FILTER_PARAM(21) },
+	{ "mmci-omap.0", "rx", SDMA_FILTER_PARAM(22) },
+	{ "omap_udc", "rx0", SDMA_FILTER_PARAM(26) },
+	{ "omap_udc", "rx1", SDMA_FILTER_PARAM(27) },
+	{ "omap_udc", "rx2", SDMA_FILTER_PARAM(28) },
+	{ "omap_udc", "tx0", SDMA_FILTER_PARAM(29) },
+	{ "omap_udc", "tx1", SDMA_FILTER_PARAM(30) },
+	{ "omap_udc", "tx2", SDMA_FILTER_PARAM(31) },
+	{ "mmci-omap.1", "tx", SDMA_FILTER_PARAM(54) },
+	{ "mmci-omap.1", "rx", SDMA_FILTER_PARAM(55) },
+};
+
 static struct omap_system_dma_plat_info dma_plat_info __initdata = {
 	.reg_map	= reg_map,
 	.channel_stride	= 0x40,
@@ -342,6 +379,14 @@ static int __init omap1_system_dma_init(void)
 	p.dma_attr = d;
 	p.errata = configure_dma_errata();
 
+	if (cpu_is_omap7xx()) {
+		p.slave_map = omap7xx_sdma_map;
+		p.slavecnt = ARRAY_SIZE(omap7xx_sdma_map);
+	} else {
+		p.slave_map = omap1xxx_sdma_map;
+		p.slavecnt = ARRAY_SIZE(omap1xxx_sdma_map);
+	}
+
 	ret = platform_device_add_data(pdev, &p, sizeof(p));
 	if (ret) {
 		dev_err(&pdev->dev, "%s: Unable to add resources for %s%d\n",
-- 
2.7.0



From peter.ujfalusi at ti.com  Tue Feb  2 06:27:05 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 2 Feb 2016 16:27:05 +0200
Subject: [PATCH 0/2] ARM: OMAP1/OMAP2+: Add dma_slave_map to board files
Message-ID: <1454423227-31830-1-git-send-email-peter.ujfalusi@ti.com>

Hi,

The following series adds the dma_slave map to the sDMA (omap-dma) driver. The
dma_slave_map is needed later when we convert drivers to use the new dmaengine
API for requesting slave channels.

Regards,
Peter
---
Peter Ujfalusi (2):
  ARM: OMAP1: DMA: Provide dma_slave_map to omap-dma
  ARM: OMAP2+: DMA: Provide dma_slave_map to omap-dma for legacy boot

 arch/arm/mach-omap1/dma.c |  45 ++++++++++++++++++
 arch/arm/mach-omap2/dma.c | 117 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 162 insertions(+)

-- 
2.7.0



From peter.ujfalusi at ti.com  Tue Feb  2 06:27:07 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 2 Feb 2016 16:27:07 +0200
Subject: [PATCH 2/2] ARM: OMAP2+: DMA: Provide dma_slave_map to omap-dma for
 legacy boot
In-Reply-To: <1454423227-31830-1-git-send-email-peter.ujfalusi@ti.com>
References: <1454423227-31830-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1454423227-31830-3-git-send-email-peter.ujfalusi@ti.com>

We still have some boards booting in legacy mode and they will need to have
the device/slave -> filter_fn mapping so we can convert the OMAP drivers
to use the new dmaengine API for requesting channels.
Only some OMAP24xx and OMAP3xxx boards can boot in legacy mode which means
we only need to provide the map for these SoCs.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/mach-omap2/dma.c | 117 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 117 insertions(+)

diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index 1ed4be184a29..e58c13a9bea5 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -28,6 +28,7 @@
 #include <linux/init.h>
 #include <linux/device.h>
 #include <linux/dma-mapping.h>
+#include <linux/dmaengine.h>
 #include <linux/of.h>
 #include <linux/omap-dma.h>
 
@@ -203,6 +204,108 @@ static unsigned configure_dma_errata(void)
 	return errata;
 }
 
+static const struct dma_slave_map omap24xx_sdma_map[] = {
+	{ "omap-gpmc", "rxtx", SDMA_FILTER_PARAM(4) },
+	{ "omap-aes", "tx", SDMA_FILTER_PARAM(9) },
+	{ "omap-aes", "rx", SDMA_FILTER_PARAM(10) },
+	{ "omap-sham", "rx", SDMA_FILTER_PARAM(13) },
+	{ "omap2_mcspi.2", "tx0", SDMA_FILTER_PARAM(15) },
+	{ "omap2_mcspi.2", "rx0", SDMA_FILTER_PARAM(16) },
+	{ "omap-mcbsp.3", "tx", SDMA_FILTER_PARAM(17) },
+	{ "omap-mcbsp.3", "rx", SDMA_FILTER_PARAM(18) },
+	{ "omap-mcbsp.4", "tx", SDMA_FILTER_PARAM(19) },
+	{ "omap-mcbsp.4", "rx", SDMA_FILTER_PARAM(20) },
+	{ "omap-mcbsp.5", "tx", SDMA_FILTER_PARAM(21) },
+	{ "omap-mcbsp.5", "rx", SDMA_FILTER_PARAM(22) },
+	{ "omap2_mcspi.2", "tx1", SDMA_FILTER_PARAM(23) },
+	{ "omap2_mcspi.2", "rx1", SDMA_FILTER_PARAM(24) },
+	{ "omap_i2c.1", "tx", SDMA_FILTER_PARAM(27) },
+	{ "omap_i2c.1", "rx", SDMA_FILTER_PARAM(28) },
+	{ "omap_i2c.2", "tx", SDMA_FILTER_PARAM(29) },
+	{ "omap_i2c.2", "rx", SDMA_FILTER_PARAM(30) },
+	{ "omap-mcbsp.1", "tx", SDMA_FILTER_PARAM(31) },
+	{ "omap-mcbsp.1", "rx", SDMA_FILTER_PARAM(32) },
+	{ "omap-mcbsp.2", "tx", SDMA_FILTER_PARAM(33) },
+	{ "omap-mcbsp.2", "rx", SDMA_FILTER_PARAM(34) },
+	{ "omap2_mcspi.0", "tx0", SDMA_FILTER_PARAM(35) },
+	{ "omap2_mcspi.0", "rx0", SDMA_FILTER_PARAM(36) },
+	{ "omap2_mcspi.0", "tx1", SDMA_FILTER_PARAM(37) },
+	{ "omap2_mcspi.0", "rx1", SDMA_FILTER_PARAM(38) },
+	{ "omap2_mcspi.0", "tx2", SDMA_FILTER_PARAM(39) },
+	{ "omap2_mcspi.0", "rx2", SDMA_FILTER_PARAM(40) },
+	{ "omap2_mcspi.0", "tx3", SDMA_FILTER_PARAM(41) },
+	{ "omap2_mcspi.0", "rx3", SDMA_FILTER_PARAM(42) },
+	{ "omap2_mcspi.1", "tx0", SDMA_FILTER_PARAM(43) },
+	{ "omap2_mcspi.1", "rx0", SDMA_FILTER_PARAM(44) },
+	{ "omap2_mcspi.1", "tx1", SDMA_FILTER_PARAM(45) },
+	{ "omap2_mcspi.1", "rx1", SDMA_FILTER_PARAM(46) },
+	{ "omap_hsmmc.1", "tx", SDMA_FILTER_PARAM(47) },
+	{ "omap_hsmmc.1", "rx", SDMA_FILTER_PARAM(48) },
+	{ "omap_uart.0", "tx", SDMA_FILTER_PARAM(49) },
+	{ "omap_uart.0", "rx", SDMA_FILTER_PARAM(50) },
+	{ "omap_uart.1", "tx", SDMA_FILTER_PARAM(51) },
+	{ "omap_uart.1", "rx", SDMA_FILTER_PARAM(52) },
+	{ "omap_uart.2", "tx", SDMA_FILTER_PARAM(53) },
+	{ "omap_uart.2", "rx", SDMA_FILTER_PARAM(54) },
+	{ "omap_hsmmc.0", "tx", SDMA_FILTER_PARAM(61) },
+	{ "omap_hsmmc.0", "rx", SDMA_FILTER_PARAM(62) },
+};
+
+static const struct dma_slave_map omap3xxx_sdma_map[] = {
+	{ "omap-gpmc", "rxtx", SDMA_FILTER_PARAM(4) },
+	{ "omap2_mcspi.2", "tx0", SDMA_FILTER_PARAM(15) },
+	{ "omap2_mcspi.2", "rx0", SDMA_FILTER_PARAM(16) },
+	{ "omap-mcbsp.3", "tx", SDMA_FILTER_PARAM(17) },
+	{ "omap-mcbsp.3", "rx", SDMA_FILTER_PARAM(18) },
+	{ "omap-mcbsp.4", "tx", SDMA_FILTER_PARAM(19) },
+	{ "omap-mcbsp.4", "rx", SDMA_FILTER_PARAM(20) },
+	{ "omap-mcbsp.5", "tx", SDMA_FILTER_PARAM(21) },
+	{ "omap-mcbsp.5", "rx", SDMA_FILTER_PARAM(22) },
+	{ "omap2_mcspi.2", "tx1", SDMA_FILTER_PARAM(23) },
+	{ "omap2_mcspi.2", "rx1", SDMA_FILTER_PARAM(24) },
+	{ "omap_i2c.3", "tx", SDMA_FILTER_PARAM(25) },
+	{ "omap_i2c.3", "rx", SDMA_FILTER_PARAM(26) },
+	{ "omap_i2c.1", "tx", SDMA_FILTER_PARAM(27) },
+	{ "omap_i2c.1", "rx", SDMA_FILTER_PARAM(28) },
+	{ "omap_i2c.2", "tx", SDMA_FILTER_PARAM(29) },
+	{ "omap_i2c.2", "rx", SDMA_FILTER_PARAM(30) },
+	{ "omap-mcbsp.1", "tx", SDMA_FILTER_PARAM(31) },
+	{ "omap-mcbsp.1", "rx", SDMA_FILTER_PARAM(32) },
+	{ "omap-mcbsp.2", "tx", SDMA_FILTER_PARAM(33) },
+	{ "omap-mcbsp.2", "rx", SDMA_FILTER_PARAM(34) },
+	{ "omap2_mcspi.0", "tx0", SDMA_FILTER_PARAM(35) },
+	{ "omap2_mcspi.0", "rx0", SDMA_FILTER_PARAM(36) },
+	{ "omap2_mcspi.0", "tx1", SDMA_FILTER_PARAM(37) },
+	{ "omap2_mcspi.0", "rx1", SDMA_FILTER_PARAM(38) },
+	{ "omap2_mcspi.0", "tx2", SDMA_FILTER_PARAM(39) },
+	{ "omap2_mcspi.0", "rx2", SDMA_FILTER_PARAM(40) },
+	{ "omap2_mcspi.0", "tx3", SDMA_FILTER_PARAM(41) },
+	{ "omap2_mcspi.0", "rx3", SDMA_FILTER_PARAM(42) },
+	{ "omap2_mcspi.1", "tx0", SDMA_FILTER_PARAM(43) },
+	{ "omap2_mcspi.1", "rx0", SDMA_FILTER_PARAM(44) },
+	{ "omap2_mcspi.1", "tx1", SDMA_FILTER_PARAM(45) },
+	{ "omap2_mcspi.1", "rx1", SDMA_FILTER_PARAM(46) },
+	{ "omap_hsmmc.1", "tx", SDMA_FILTER_PARAM(47) },
+	{ "omap_hsmmc.1", "rx", SDMA_FILTER_PARAM(48) },
+	{ "omap_uart.0", "tx", SDMA_FILTER_PARAM(49) },
+	{ "omap_uart.0", "rx", SDMA_FILTER_PARAM(50) },
+	{ "omap_uart.1", "tx", SDMA_FILTER_PARAM(51) },
+	{ "omap_uart.1", "rx", SDMA_FILTER_PARAM(52) },
+	{ "omap_uart.2", "tx", SDMA_FILTER_PARAM(53) },
+	{ "omap_uart.2", "rx", SDMA_FILTER_PARAM(54) },
+	{ "omap_hsmmc.0", "tx", SDMA_FILTER_PARAM(61) },
+	{ "omap_hsmmc.0", "rx", SDMA_FILTER_PARAM(62) },
+	{ "omap-aes", "tx", SDMA_FILTER_PARAM(65) },
+	{ "omap-aes", "rx", SDMA_FILTER_PARAM(66) },
+	{ "omap-sham", "rx", SDMA_FILTER_PARAM(69) },
+	{ "omap2_mcspi.3", "tx0", SDMA_FILTER_PARAM(70) },
+	{ "omap2_mcspi.3", "rx0", SDMA_FILTER_PARAM(71) },
+	{ "omap_hsmmc.2", "tx", SDMA_FILTER_PARAM(77) },
+	{ "omap_hsmmc.2", "rx", SDMA_FILTER_PARAM(78) },
+	{ "omap_uart.3", "tx", SDMA_FILTER_PARAM(81) },
+	{ "omap_uart.3", "rx", SDMA_FILTER_PARAM(82) },
+};
+
 static struct omap_system_dma_plat_info dma_plat_info __initdata = {
 	.reg_map	= reg_map,
 	.channel_stride	= 0x60,
@@ -231,6 +334,20 @@ static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void *unused)
 	p.dma_attr = (struct omap_dma_dev_attr *)oh->dev_attr;
 	p.errata = configure_dma_errata();
 
+	if (!of_have_populated_dt()) {
+		if (soc_is_omap24xx()) {
+			p.slave_map = omap24xx_sdma_map;
+			p.slavecnt = ARRAY_SIZE(omap24xx_sdma_map);
+		} else if (soc_is_omap34xx() || soc_is_omap3630()) {
+			p.slave_map = omap3xxx_sdma_map;
+			p.slavecnt = ARRAY_SIZE(omap3xxx_sdma_map);
+		} else {
+			pr_err("%s: The legacy DMA map is not provided!\n",
+			       __func__);
+			return -ENODEV;
+		}
+	}
+
 	pdev = omap_device_build(name, 0, oh, &p, sizeof(p));
 	if (IS_ERR(pdev)) {
 		pr_err("%s: Can't build omap_device for %s:%s.\n",
-- 
2.7.0



From arnd at arndb.de  Tue Feb  2 06:36:39 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 02 Feb 2016 15:36:39 +0100
Subject: [PATCH] iio: chemical: select IRQ_WORK for ATLAS ph sensor
Message-ID: <5127664.OXcBoKUPQO@wuerfel>

The newly added atlas-ph-sensor driver uses irq_work_queue, which
may not always be enabled:

ERROR: "irq_work_queue" [drivers/iio/chemical/atlas-ph-sensor.ko] undefined!

This adds a 'select' statement to Kconfig to ensure it's there
when we need it.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 27dec00ecf2d ("iio: chemical: add Atlas pH-SM sensor support")

diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
index ce7cd1370f74..f73290f84c90 100644
--- a/drivers/iio/chemical/Kconfig
+++ b/drivers/iio/chemical/Kconfig
@@ -10,6 +10,7 @@ config ATLAS_PH_SENSOR
 	select REGMAP_I2C
 	select IIO_BUFFER
 	select IIO_TRIGGERED_BUFFER
+	select IRQ_WORK
 	help
 	 Say Y here to build I2C interface support for the Atlas
 	 Scientific OEM pH-SM sensor.



From thierry.reding at gmail.com  Tue Feb  2 06:37:02 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 2 Feb 2016 15:37:02 +0100
Subject: [PATCH V5 12/14] clk: tegra210: Add the APB2APE audio clock
In-Reply-To: <1453998832-27383-13-git-send-email-jonathanh@nvidia.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-13-git-send-email-jonathanh@nvidia.com>
Message-ID: <20160202143702.GA10098@ulmo.nvidia.com>

On Thu, Jan 28, 2016 at 04:33:50PM +0000, Jon Hunter wrote:
> The APB2APE clock for the audio subsystem is required for powering up the
> audio power domain and accessing the various modules in this subsystem on
> the tegra210 device. Add this clock for tegra210.
> 
> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
> ---
>  drivers/clk/tegra/clk-id.h               | 1 +
>  drivers/clk/tegra/clk-tegra-periph.c     | 1 +
>  drivers/clk/tegra/clk-tegra210.c         | 1 +
>  include/dt-bindings/clock/tegra210-car.h | 2 +-
>  4 files changed, 4 insertions(+), 1 deletion(-)

Applied, thanks.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/7edb760a/attachment.sig>

From codekipper at gmail.com  Tue Feb  2 06:49:52 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Tue,  2 Feb 2016 15:49:52 +0100
Subject: [PATCH v3 0/2] Add SPDIF support for Allwinner SoCs 
Message-ID: <1454424594-25208-1-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

This patch set adds support for the Allwinner SPDIF transceiver.

For now just the SPDIF transmitter has been tested on a Mele A2000(A10)
and a Itead Ibox(A20).

In order for this patch set to be functional we require an audio clock patch
which will be delivered separately. For those that are interested I've pushed
the patches here with all the required changes to get SPDIF audio out of the
device.

https://github.com/codekipper/linux-sunxi/commits/spdif_delivery

This is version 3 of the patch series. It's been quite a while since v2 and I'm
hoping now that all the previous comments have been acted on.

Thanks in advance,
CK

---
Changes since v2:
- removed sunxi-machine-spdif and replaced with simple audio card
- removed untested compatibilities from device tree documentation
- added pm_runtime and remove shutdown
- removed pll2 as it's the parent of the spdif clock
- rename clk to spdif_clk
- removed enabling of mclk output
- removed interrupts status being cleared as it's not being used
- use default fifo settings for now
- fixed alignments for wrapped lines

Changes since v1:
- Moved sunxi-machine-spdif.c to separate patch
- replaced sunxi in naming scheme with sun4i in the sun4i-spdif driver.
- split tx controller into separate enable/disable functions
- moved setclk and setfmt functionality into hw params
- added support for mono signals.
- cleaned up probe clock set up.
- removed all writes to transmit status registers.
- removed of_id
- removed power management code.
- Added support for more rates.

Marcus Cooper (2):
  dt-bindings: add sun4i SPDIF transceiver bindings
  ASOC: sunxi: Add support for the SPDIF block

 .../devicetree/bindings/sound/sun4i,spdif.txt      |  46 ++
 sound/soc/sunxi/Kconfig                            |   8 +
 sound/soc/sunxi/Makefile                           |   1 +
 sound/soc/sunxi/sun4i-spdif.c                      | 586 +++++++++++++++++++++
 4 files changed, 641 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/sun4i,spdif.txt
 create mode 100644 sound/soc/sunxi/sun4i-spdif.c

-- 
2.7.0



From codekipper at gmail.com  Tue Feb  2 06:49:53 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Tue,  2 Feb 2016 15:49:53 +0100
Subject: [PATCH v3 1/2] dt-bindings: add sun4i SPDIF transceiver bindings
In-Reply-To: <1454424594-25208-1-git-send-email-codekipper@gmail.com>
References: <1454424594-25208-1-git-send-email-codekipper@gmail.com>
Message-ID: <1454424594-25208-2-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

Add devicetree bindings for the SPDIF transceiver found on
found on Allwinners A10 and A20 SoCs.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
 .../devicetree/bindings/sound/sun4i,spdif.txt      | 46 ++++++++++++++++++++++
 1 file changed, 46 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/sun4i,spdif.txt

diff --git a/Documentation/devicetree/bindings/sound/sun4i,spdif.txt b/Documentation/devicetree/bindings/sound/sun4i,spdif.txt
new file mode 100644
index 0000000..55ed2f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sun4i,spdif.txt
@@ -0,0 +1,46 @@
+Allwinner Sony/Philips Digital Interface Format (S/PDIF) Controller
+
+The Allwinner S/PDIF audio block is a transceiver that allows the
+processor to receive and transmit digital audio via an coaxial cable or
+a fibre cable.
+
+Required properties:
+
+  - compatible		: should be one of the following:
+    - "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC
+
+  - reg			: Offset and length of the register set for the device.
+
+  - interrupts		: Contains the spdif interrupt.
+
+  - dmas		: Generic dma devicetree binding as described in
+			  Documentation/devicetree/bindings/dma/dma.txt.
+
+  - dma-names		: Two dmas have to be defined, "tx" and "rx".
+
+  - clocks		: Contains an entry for each entry in clock-names.
+
+  - clock-names		: Includes the following entries:
+	"apb"		  clock for the spdif bus.
+	"spdif"		  clock for spdif controller.
+
+Optional:
+
+  - spdif-in		: Enable block for capturing an SPDIF signal.
+
+  - spdif-out		: Enable block for transmitting an SPDIF signal.
+
+Example:
+
+spdif: spdif at 01c21000 {
+	compatible = "allwinner,sun4i-a10-spdif";
+	reg = <0x01c21000 0x40>;
+	interrupts = <13>;
+	clocks = <&apb0_gates 1>, <&spdif_clk>;
+	clock-names = "apb", "spdif";
+	dmas = <&dma 0 2>, <&dma 0 2>;
+	dma-names = "rx", "tx";
+	spdif-in = "disabled";
+	spdif-out = "okay";
+	status = "okay";
+};
-- 
2.7.0



From codekipper at gmail.com  Tue Feb  2 06:49:54 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Tue,  2 Feb 2016 15:49:54 +0100
Subject: [PATCH v3 2/2] ASOC: sunxi: Add support for the SPDIF block
In-Reply-To: <1454424594-25208-1-git-send-email-codekipper@gmail.com>
References: <1454424594-25208-1-git-send-email-codekipper@gmail.com>
Message-ID: <1454424594-25208-3-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

The sun4i, sun5i and sun7i SoC families have an SPDIF
block which is capable of playback and capture.

This patch enables the playback of this block for
the sun4i families.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
 sound/soc/sunxi/Kconfig       |   8 +
 sound/soc/sunxi/Makefile      |   1 +
 sound/soc/sunxi/sun4i-spdif.c | 586 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 595 insertions(+)
 create mode 100644 sound/soc/sunxi/sun4i-spdif.c

diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
index 84c72ec..6af7224 100644
--- a/sound/soc/sunxi/Kconfig
+++ b/sound/soc/sunxi/Kconfig
@@ -8,4 +8,12 @@ config SND_SUN4I_CODEC
 	  Select Y or M to add support for the Codec embedded in the Allwinner
 	  A10 and affiliated SoCs.
 
+config SND_SUN4I_SPDIF
+        tristate "Allwinner A10 SPDIF Support"
+	depends on OF
+        select SND_SOC_GENERIC_DMAENGINE_PCM
+        select REGMAP_MMIO
+        help
+          Say Y or M to add support for the S/PDIF audio block in the Allwinner
+	  A10 and affiliated SoCs.
 endmenu
diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
index ea8a08c..8f5e889 100644
--- a/sound/soc/sunxi/Makefile
+++ b/sound/soc/sunxi/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
 
+obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o
diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
new file mode 100644
index 0000000..16265b3
--- /dev/null
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -0,0 +1,586 @@
+/*
+ * ALSA SoC SPDIF Audio Layer
+ *
+ * Copyright 2015 Andrea Venturi <be17068 at iperbole.bo.it>
+ * Copyright 2015 Marcus Cooper <codekipper at gmail.com>
+ *
+ * Based on the Allwinner SDK driver, released under the GPL.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/regmap.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/ioport.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <sound/dmaengine_pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+
+#define	SUN4I_SPDIF_CTL		(0x00)
+	#define SUN4I_SPDIF_CTL_MCLKDIV(v)		((v) << 4) /* v even */
+	#define SUN4I_SPDIF_CTL_MCLKOUTEN		BIT(2)
+	#define SUN4I_SPDIF_CTL_GEN			BIT(1)
+	#define SUN4I_SPDIF_CTL_RESET			BIT(0)
+
+#define SUN4I_SPDIF_TXCFG	(0x04)
+	#define SUN4I_SPDIF_TXCFG_SINGLEMOD		BIT(31)
+	#define SUN4I_SPDIF_TXCFG_ASS			BIT(17)
+	#define SUN4I_SPDIF_TXCFG_NONAUDIO		BIT(16)
+	#define SUN4I_SPDIF_TXCFG_TXRATIO(v)		((v) << 4)
+	#define SUN4I_SPDIF_TXCFG_TXRATIO_MASK		GENMASK(8, 4)
+	#define SUN4I_SPDIF_TXCFG_FMTRVD		GENMASK(3, 2)
+	#define SUN4I_SPDIF_TXCFG_FMT16BIT		(0 << 2)
+	#define SUN4I_SPDIF_TXCFG_FMT20BIT		(1 << 2)
+	#define SUN4I_SPDIF_TXCFG_FMT24BIT		(2 << 2)
+	#define SUN4I_SPDIF_TXCFG_CHSTMODE		BIT(1)
+	#define SUN4I_SPDIF_TXCFG_TXEN			BIT(0)
+
+#define SUN4I_SPDIF_RXCFG	(0x08)
+	#define SUN4I_SPDIF_RXCFG_LOCKFLAG		BIT(4)
+	#define SUN4I_SPDIF_RXCFG_CHSTSRC		BIT(3)
+	#define SUN4I_SPDIF_RXCFG_CHSTCP		BIT(1)
+	#define SUN4I_SPDIF_RXCFG_RXEN			BIT(0)
+
+#define SUN4I_SPDIF_TXFIFO	(0x0C)
+
+#define SUN4I_SPDIF_RXFIFO	(0x10)
+
+#define SUN4I_SPDIF_FCTL	(0x14)
+	#define SUN4I_SPDIF_FCTL_FIFOSRC		BIT(31)
+	#define SUN4I_SPDIF_FCTL_FTX			BIT(17)
+	#define SUN4I_SPDIF_FCTL_FRX			BIT(16)
+	#define SUN4I_SPDIF_FCTL_TXTL(v)		((v) << 8)
+	#define SUN4I_SPDIF_FCTL_TXTL_MASK		GENMASK(12, 8)
+	#define SUN4I_SPDIF_FCTL_RXTL(v)		((v) << 3)
+	#define SUN4I_SPDIF_FCTL_RXTL_MASK		GENMASK(7, 3)
+	#define SUN4I_SPDIF_FCTL_TXIM			BIT(2)
+	#define SUN4I_SPDIF_FCTL_RXOM(v)		((v) << 0)
+	#define SUN4I_SPDIF_FCTL_RXOM_MASK		GENMASK(1, 0)
+
+#define SUN4I_SPDIF_FSTA	(0x18)
+	#define SUN4I_SPDIF_FSTA_TXE			BIT(14)
+	#define SUN4I_SPDIF_FSTA_TXECNTSHT		(8)
+	#define SUN4I_SPDIF_FSTA_RXA			BIT(6)
+	#define SUN4I_SPDIF_FSTA_RXACNTSHT		(0)
+
+#define SUN4I_SPDIF_INT		(0x1C)
+	#define SUN4I_SPDIF_INT_RXLOCKEN		BIT(18)
+	#define SUN4I_SPDIF_INT_RXUNLOCKEN		BIT(17)
+	#define SUN4I_SPDIF_INT_RXPARERREN		BIT(16)
+	#define SUN4I_SPDIF_INT_TXDRQEN			BIT(7)
+	#define SUN4I_SPDIF_INT_TXUIEN			BIT(6)
+	#define SUN4I_SPDIF_INT_TXOIEN			BIT(5)
+	#define SUN4I_SPDIF_INT_TXEIEN			BIT(4)
+	#define SUN4I_SPDIF_INT_RXDRQEN			BIT(2)
+	#define SUN4I_SPDIF_INT_RXOIEN			BIT(1)
+	#define SUN4I_SPDIF_INT_RXAIEN			BIT(0)
+
+#define SUN4I_SPDIF_ISTA	(0x20)
+	#define SUN4I_SPDIF_ISTA_RXLOCKSTA		BIT(18)
+	#define SUN4I_SPDIF_ISTA_RXUNLOCKSTA		BIT(17)
+	#define SUN4I_SPDIF_ISTA_RXPARERRSTA		BIT(16)
+	#define SUN4I_SPDIF_ISTA_TXUSTA			BIT(6)
+	#define SUN4I_SPDIF_ISTA_TXOSTA			BIT(5)
+	#define SUN4I_SPDIF_ISTA_TXESTA			BIT(4)
+	#define SUN4I_SPDIF_ISTA_RXOSTA			BIT(1)
+	#define SUN4I_SPDIF_ISTA_RXASTA			BIT(0)
+
+#define SUN4I_SPDIF_TXCNT	(0x24)
+
+#define SUN4I_SPDIF_RXCNT	(0x28)
+
+#define SUN4I_SPDIF_TXCHSTA0	(0x2C)
+	#define SUN4I_SPDIF_TXCHSTA0_CLK(v)		((v) << 28)
+	#define SUN4I_SPDIF_TXCHSTA0_SAMFREQ(v)		((v) << 24)
+	#define SUN4I_SPDIF_TXCHSTA0_SAMFREQ_MASK	GENMASK(27, 24)
+	#define SUN4I_SPDIF_TXCHSTA0_CHNUM(v)		((v) << 20)
+	#define SUN4I_SPDIF_TXCHSTA0_CHNUM_MASK		GENMASK(23, 20)
+	#define SUN4I_SPDIF_TXCHSTA0_SRCNUM(v)		((v) << 16)
+	#define SUN4I_SPDIF_TXCHSTA0_CATACOD(v)		((v) << 8)
+	#define SUN4I_SPDIF_TXCHSTA0_MODE(v)		((v) << 6)
+	#define SUN4I_SPDIF_TXCHSTA0_EMPHASIS(v)	((v) << 3)
+	#define SUN4I_SPDIF_TXCHSTA0_CP			BIT(2)
+	#define SUN4I_SPDIF_TXCHSTA0_AUDIO		BIT(1)
+	#define SUN4I_SPDIF_TXCHSTA0_PRO		BIT(0)
+
+#define SUN4I_SPDIF_TXCHSTA1	(0x30)
+	#define SUN4I_SPDIF_TXCHSTA1_CGMSA(v)		((v) << 8)
+	#define SUN4I_SPDIF_TXCHSTA1_ORISAMFREQ(v)	((v) << 4)
+	#define SUN4I_SPDIF_TXCHSTA1_ORISAMFREQ_MASK	GENMASK(7, 4)
+	#define SUN4I_SPDIF_TXCHSTA1_SAMWORDLEN(v)	((v) << 1)
+	#define SUN4I_SPDIF_TXCHSTA1_MAXWORDLEN		BIT(0)
+
+#define SUN4I_SPDIF_RXCHSTA0	(0x34)
+	#define SUN4I_SPDIF_RXCHSTA0_CLK(v)		((v) << 28)
+	#define SUN4I_SPDIF_RXCHSTA0_SAMFREQ(v)		((v) << 24)
+	#define SUN4I_SPDIF_RXCHSTA0_CHNUM(v)		((v) << 20)
+	#define SUN4I_SPDIF_RXCHSTA0_SRCNUM(v)		((v) << 16)
+	#define SUN4I_SPDIF_RXCHSTA0_CATACOD(v)		((v) << 8)
+	#define SUN4I_SPDIF_RXCHSTA0_MODE(v)		((v) << 6)
+	#define SUN4I_SPDIF_RXCHSTA0_EMPHASIS(v)	((v) << 3)
+	#define SUN4I_SPDIF_RXCHSTA0_CP			BIT(2)
+	#define SUN4I_SPDIF_RXCHSTA0_AUDIO		BIT(1)
+	#define SUN4I_SPDIF_RXCHSTA0_PRO		BIT(0)
+
+#define SUN4I_SPDIF_RXCHSTA1	(0x38)
+	#define SUN4I_SPDIF_RXCHSTA1_CGMSA(v)		((v) << 8)
+	#define SUN4I_SPDIF_RXCHSTA1_ORISAMFREQ(v)	((v) << 4)
+	#define SUN4I_SPDIF_RXCHSTA1_SAMWORDLEN(v)	((v) << 1)
+	#define SUN4I_SPDIF_RXCHSTA1_MAXWORDLEN		BIT(0)
+
+/* Defines for Sampling Frequency */
+#define SUN4I_SPDIF_SAMFREQ_44_1KHZ		0x0
+#define SUN4I_SPDIF_SAMFREQ_NOT_INDICATED	0x1
+#define SUN4I_SPDIF_SAMFREQ_48KHZ		0x2
+#define SUN4I_SPDIF_SAMFREQ_32KHZ		0x3
+#define SUN4I_SPDIF_SAMFREQ_22_05KHZ		0x4
+#define SUN4I_SPDIF_SAMFREQ_24KHZ		0x6
+#define SUN4I_SPDIF_SAMFREQ_88_2KHZ		0x8
+#define SUN4I_SPDIF_SAMFREQ_76_8KHZ		0x9
+#define SUN4I_SPDIF_SAMFREQ_96KHZ		0xa
+#define SUN4I_SPDIF_SAMFREQ_176_4KHZ		0xc
+#define SUN4I_SPDIF_SAMFREQ_192KHZ		0xe
+
+/*
+ * Original sampling frequency can be represented by inverting the value of the
+ * sampling frequency.
+ */
+#define ORIGINAL(v) ((~v) & 0xf)
+
+struct sun4i_spdif_dev {
+	struct platform_device *pdev;
+	struct clk *spdif_clk;
+	struct clk *apb_clk;
+	struct snd_soc_dai_driver cpu_dai_drv;
+	struct regmap *regmap;
+	struct snd_dmaengine_dai_dma_data dma_params_tx;
+	struct snd_dmaengine_dai_dma_data dma_params_rx;
+	bool playback_supported;
+	bool capture_supported;
+};
+
+static void sun4i_spdif_configure(struct sun4i_spdif_dev *host)
+{
+	/* soft reset SPDIF */
+	regmap_write(host->regmap, SUN4I_SPDIF_CTL, SUN4I_SPDIF_CTL_RESET);
+
+	/* flush TX FIFO */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_FCTL,
+			   SUN4I_SPDIF_FCTL_FTX, SUN4I_SPDIF_FCTL_FTX);
+
+	/* clear TX counter */
+	regmap_write(host->regmap, SUN4I_SPDIF_TXCNT, 0);
+}
+
+static void sun4i_snd_txctrl_on(struct snd_pcm_substream *substream,
+				struct sun4i_spdif_dev *host)
+{
+	if (substream->runtime->channels == 1)
+		regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+				   SUN4I_SPDIF_TXCFG_SINGLEMOD,
+				   SUN4I_SPDIF_TXCFG_SINGLEMOD);
+
+	/* SPDIF TX ENABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+			   SUN4I_SPDIF_TXCFG_TXEN, SUN4I_SPDIF_TXCFG_TXEN);
+
+	/* DRQ ENABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_INT,
+			   SUN4I_SPDIF_INT_TXDRQEN, SUN4I_SPDIF_INT_TXDRQEN);
+
+	/* Global enable */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_CTL,
+			   SUN4I_SPDIF_CTL_GEN, SUN4I_SPDIF_CTL_GEN);
+}
+
+static void sun4i_snd_txctrl_off(struct snd_pcm_substream *substream,
+				 struct sun4i_spdif_dev *host)
+{
+	/* SPDIF TX DISABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+			   SUN4I_SPDIF_TXCFG_TXEN, 0);
+
+	/* DRQ DISABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_INT,
+			   SUN4I_SPDIF_INT_TXDRQEN, 0);
+
+	/* Global disable */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_CTL,
+			   SUN4I_SPDIF_CTL_GEN, 0);
+}
+
+static int sun4i_spdif_startup(struct snd_pcm_substream *substream,
+			       struct snd_soc_dai *cpu_dai)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(rtd->cpu_dai);
+
+	if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK)
+		return -EINVAL;
+
+	sun4i_spdif_configure(host);
+
+	return 0;
+}
+
+static int sun4i_spdif_hw_params(struct snd_pcm_substream *substream,
+				 struct snd_pcm_hw_params *params,
+				 struct snd_soc_dai *cpu_dai)
+{
+	int ret = 0;
+	int fmt;
+	unsigned long rate = params_rate(params);
+	u32 mclk_div = 0;
+	unsigned int mclk = 0;
+	u32 reg_val;
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
+	struct platform_device *pdev = host->pdev;
+
+	/* Add the PCM and raw data select interface */
+	switch (params_channels(params)) {
+	case 1: /* PCM mode */
+	case 2:
+		fmt = 0;
+		break;
+	case 4: /* raw data mode */
+		fmt = SUN4I_SPDIF_TXCFG_NONAUDIO;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	switch (params_format(params)) {
+	case SNDRV_PCM_FORMAT_S16_LE:
+		fmt |= SUN4I_SPDIF_TXCFG_FMT16BIT;
+		break;
+	case SNDRV_PCM_FORMAT_S20_3LE:
+		fmt |= SUN4I_SPDIF_TXCFG_FMT20BIT;
+		break;
+	case SNDRV_PCM_FORMAT_S24_LE:
+		fmt |= SUN4I_SPDIF_TXCFG_FMT24BIT;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	switch (rate) {
+	case 22050:
+	case 44100:
+	case 88200:
+	case 176400:
+		mclk = 22579200;
+		break;
+	case 24000:
+	case 32000:
+	case 48000:
+	case 96000:
+	case 192000:
+		mclk = 24576000;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	ret = clk_set_rate(host->spdif_clk, mclk);
+	if (ret < 0) {
+		dev_err(&pdev->dev,
+			"Setting SPDIF clock rate for %d Hz failed!\n", mclk);
+		return ret;
+	}
+
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_FCTL,
+			   SUN4I_SPDIF_FCTL_TXIM, SUN4I_SPDIF_FCTL_TXIM);
+
+	switch (rate) {
+	case 22050:
+	case 24000:
+		mclk_div = 8;
+		break;
+	case 32000:
+		mclk_div = 6;
+		break;
+	case 44100:
+	case 48000:
+		mclk_div = 4;
+		break;
+	case 88200:
+	case 96000:
+		mclk_div = 2;
+		break;
+	case 176400:
+	case 192000:
+		mclk_div = 1;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	reg_val = 0;
+	reg_val |= SUN4I_SPDIF_TXCFG_ASS;
+	reg_val |= fmt; /* set non audio and bit depth */
+	reg_val |= SUN4I_SPDIF_TXCFG_CHSTMODE;
+	reg_val |= SUN4I_SPDIF_TXCFG_TXRATIO(mclk_div - 1);
+	regmap_write(host->regmap, SUN4I_SPDIF_TXCFG, reg_val);
+
+	return 0;
+}
+
+static int sun4i_spdif_trigger(struct snd_pcm_substream *substream, int cmd,
+			       struct snd_soc_dai *dai)
+{
+	int ret = 0;
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(dai);
+
+	if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK)
+		return -EINVAL;
+
+	switch (cmd) {
+	case SNDRV_PCM_TRIGGER_START:
+	case SNDRV_PCM_TRIGGER_RESUME:
+	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+		sun4i_snd_txctrl_on(substream, host);
+		break;
+
+	case SNDRV_PCM_TRIGGER_STOP:
+	case SNDRV_PCM_TRIGGER_SUSPEND:
+	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+		sun4i_snd_txctrl_off(substream, host);
+		break;
+
+	default:
+		ret = -EINVAL;
+		break;
+	}
+	return ret;
+}
+
+static int sun4i_spdif_soc_dai_probe(struct snd_soc_dai *dai)
+{
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(dai);
+
+	snd_soc_dai_init_dma_data(dai, &host->dma_params_tx,
+						&host->dma_params_rx);
+	return 0;
+}
+
+static const struct snd_soc_dai_ops sun4i_spdif_dai_ops = {
+	.startup	= sun4i_spdif_startup,
+	.trigger	= sun4i_spdif_trigger,
+	.hw_params	= sun4i_spdif_hw_params,
+};
+
+static const struct regmap_config sun4i_spdif_regmap_config = {
+	.reg_bits = 32,
+	.reg_stride = 4,
+	.val_bits = 32,
+	.max_register = SUN4I_SPDIF_RXCHSTA1,
+};
+
+#define SUN4I_RATES	SNDRV_PCM_RATE_8000_192000
+
+#define SUN4I_FORMATS	(SNDRV_PCM_FORMAT_S16_LE | \
+				SNDRV_PCM_FORMAT_S20_3LE | \
+				SNDRV_PCM_FORMAT_S24_LE)
+
+static struct snd_soc_dai_driver sun4i_spdif_dai = {
+	.playback = {
+		.channels_min = 1,
+		.channels_max = 2,
+		.rates = SUN4I_RATES,
+		.formats = SUN4I_FORMATS,
+	},
+	.probe = sun4i_spdif_soc_dai_probe,
+	.ops = &sun4i_spdif_dai_ops,
+	.name = "spdif",
+};
+
+static const struct snd_soc_dapm_widget dit_widgets[] = {
+	SND_SOC_DAPM_OUTPUT("spdif-out"),
+};
+
+static const struct snd_soc_dapm_route dit_routes[] = {
+	{ "spdif-out", NULL, "Playback" },
+};
+
+static const struct of_device_id sun4i_spdif_of_match[] = {
+	{ .compatible = "allwinner,sun4i-a10-spdif", },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sun4i_spdif_of_match);
+
+static const struct snd_soc_component_driver sun4i_spdif_component = {
+	.name		= "sun4i-spdif",
+};
+
+#ifdef CONFIG_PM
+static int sun4i_spdif_runtime_suspend(struct device *dev)
+{
+	struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
+
+	clk_disable_unprepare(host->spdif_clk);
+
+	return 0;
+}
+
+static int sun4i_spdif_runtime_resume(struct device *dev)
+{
+	struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
+
+	clk_prepare_enable(host->spdif_clk);
+
+	return 0;
+}
+#endif /* CONFIG_PM */
+
+static int sun4i_spdif_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct sun4i_spdif_dev *host;
+	struct resource *res;
+	int ret;
+	void __iomem *base;
+
+	dev_dbg(&pdev->dev, "Entered %s\n", __func__);
+
+	if (!np)
+		return -ENODEV;
+
+	if (!of_match_device(sun4i_spdif_of_match, &pdev->dev)) {
+		dev_err(&pdev->dev, "No matched devices found.\n");
+		return -EINVAL;
+	}
+
+	host = devm_kzalloc(&pdev->dev, sizeof(*host), GFP_KERNEL);
+	if (!host)
+		return -ENOMEM;
+
+	host->pdev = pdev;
+
+	/* Initialize this copy of the CPU DAI driver structure */
+	memcpy(&host->cpu_dai_drv, &sun4i_spdif_dai, sizeof(sun4i_spdif_dai));
+	host->cpu_dai_drv.name = dev_name(&pdev->dev);
+
+	/* Get the addresses */
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	host->regmap = devm_regmap_init_mmio(&pdev->dev, base,
+						&sun4i_spdif_regmap_config);
+
+	/* Clocks */
+	host->apb_clk = devm_clk_get(&pdev->dev, "apb");
+	if (IS_ERR(host->apb_clk)) {
+		dev_err(&pdev->dev, "failed to get a apb clock.\n");
+		return PTR_ERR(host->apb_clk);
+	}
+
+	ret = clk_prepare_enable(host->apb_clk);
+	if (ret) {
+		dev_err(&pdev->dev, "try to enable apb_spdif_clk failed\n");
+		return ret;
+	}
+
+	host->spdif_clk = devm_clk_get(&pdev->dev, "spdif");
+	if (IS_ERR(host->spdif_clk)) {
+		dev_err(&pdev->dev, "failed to get a spdif clock.\n");
+		goto exit_clkdisable_apb_clk;
+	}
+
+	host->playback_supported = false;
+	host->capture_supported = false;
+
+	if (of_property_read_bool(np, "spdif-out"))
+		host->playback_supported = true;
+
+	if (!host->playback_supported) {
+		dev_err(&pdev->dev, "no enabled S/PDIF DAI link\n");
+		goto exit_clkdisable_clk;
+	}
+
+	host->dma_params_tx.addr = res->start + SUN4I_SPDIF_TXFIFO;
+	host->dma_params_tx.maxburst = 4;
+	host->dma_params_tx.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
+	host->dma_params_rx.addr = res->start + SUN4I_SPDIF_RXFIFO;
+	host->dma_params_rx.maxburst = 4;
+	host->dma_params_rx.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
+
+	platform_set_drvdata(pdev, host);
+
+	ret = devm_snd_soc_register_component(&pdev->dev,
+				&sun4i_spdif_component, &sun4i_spdif_dai, 1);
+	if (ret)
+		goto exit_clkdisable_clk;
+
+	pm_runtime_enable(&pdev->dev);
+
+	ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
+	if (ret)
+		goto exit_clkdisable_clk;
+	return 0;
+
+exit_clkdisable_clk:
+	clk_disable_unprepare(host->spdif_clk);
+exit_clkdisable_apb_clk:
+	clk_disable_unprepare(host->apb_clk);
+	return ret;
+}
+
+static int sun4i_spdif_remove(struct platform_device *pdev)
+{
+	struct sun4i_spdif_dev *host = dev_get_drvdata(&pdev->dev);
+
+	snd_soc_unregister_platform(&pdev->dev);
+	snd_soc_unregister_component(&pdev->dev);
+
+	pm_runtime_disable(&pdev->dev);
+
+	if (!IS_ERR(host->spdif_clk)) {
+		clk_disable_unprepare(host->spdif_clk);
+		clk_disable_unprepare(host->apb_clk);
+	}
+
+	return 0;
+}
+
+static const struct dev_pm_ops sun4i_spdif_pm = {
+	SET_RUNTIME_PM_OPS(sun4i_spdif_runtime_suspend,
+			   sun4i_spdif_runtime_resume, NULL)
+};
+
+static struct platform_driver sun4i_spdif_driver = {
+	.driver		= {
+		.name	= "sun4i-spdif",
+		.owner	= THIS_MODULE,
+		.of_match_table = of_match_ptr(sun4i_spdif_of_match),
+		.pm	= &sun4i_spdif_pm,
+	},
+	.probe		= sun4i_spdif_probe,
+	.remove		= sun4i_spdif_remove,
+};
+
+module_platform_driver(sun4i_spdif_driver);
+
+MODULE_AUTHOR("Marcus Cooper <codekipper at gmail.com>");
+MODULE_AUTHOR("Andrea Venturi <be17068 at iperbole.bo.it>");
+MODULE_DESCRIPTION("Allwinner sun4i SPDIF SoC Interface");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:sun4i-spdif");
-- 
2.7.0



From xerofoify at gmail.com  Tue Feb  2 06:56:32 2016
From: xerofoify at gmail.com (Nicholas Krause)
Date: Tue,  2 Feb 2016 09:56:32 -0500
Subject: [PATCH RESEND RFC] mach:-s3c64xx:Output trace information with
 WARN_ON if calls for setting up gpio board configuration fail in
 s3c64xx_i2s_cfg_gpio
Message-ID: <1454424992-14619-1-git-send-email-xerofoify@gmail.com>

This fixes the function s3c64xx_i2c_cfg_gpio to log output to the
kernel log buff with WARN_ON if any of the calls to either
s3c_gpio_cfgpin_range or s3c_gpio_cfgpin fail as we cannot exit
from s3c64xx_i2s_cfg_gpio if any of these calls fail due to
other intended function work being required to complete. Further more
if a failure occurs allow the other users/devolopers of this driver
to properly check the kernel log buffers for a kernel trace for
when these calls failing to execute successfully arise.

Signed-off-by: Nicholas Krause <xerofoify at gmail.com>
---
v3:Fix more wording issues and uncaught build failure with
previous build test
v2:Fix Patch Wording as it was clearly confusing and incorrect
 arch/arm/mach-s3c64xx/dev-audio.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/dev-audio.c b/arch/arm/mach-s3c64xx/dev-audio.c
index ff780a8..796ac75 100644
--- a/arch/arm/mach-s3c64xx/dev-audio.c
+++ b/arch/arm/mach-s3c64xx/dev-audio.c
@@ -36,10 +36,10 @@ static int s3c64xx_i2s_cfg_gpio(struct platform_device *pdev)
 		base = S3C64XX_GPE(0);
 		break;
 	case 2:
-		s3c_gpio_cfgpin(S3C64XX_GPC(4), S3C_GPIO_SFN(5));
-		s3c_gpio_cfgpin(S3C64XX_GPC(5), S3C_GPIO_SFN(5));
-		s3c_gpio_cfgpin(S3C64XX_GPC(7), S3C_GPIO_SFN(5));
-		s3c_gpio_cfgpin_range(S3C64XX_GPH(6), 4, S3C_GPIO_SFN(5));
+		WARN_ON(s3c_gpio_cfgpin(S3C64XX_GPC(4), S3C_GPIO_SFN(5)));
+		WARN_ON(s3c_gpio_cfgpin(S3C64XX_GPC(5), S3C_GPIO_SFN(5)));
+		WARN_ON(s3c_gpio_cfgpin(S3C64XX_GPC(7), S3C_GPIO_SFN(5)));
+		WARN_ON(s3c_gpio_cfgpin_range(S3C64XX_GPH(6), 4, S3C_GPIO_SFN(5)));
 		return 0;
 	default:
 		printk(KERN_DEBUG "Invalid I2S Controller number: %d\n",
@@ -47,7 +47,7 @@ static int s3c64xx_i2s_cfg_gpio(struct platform_device *pdev)
 		return -EINVAL;
 	}
 
-	s3c_gpio_cfgpin_range(base, 5, S3C_GPIO_SFN(3));
+	WARN_ON(s3c_gpio_cfgpin_range(base, 5, S3C_GPIO_SFN(3)));
 
 	return 0;
 }
-- 
2.1.4



From lee.jones at linaro.org  Tue Feb  2 07:02:55 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 2 Feb 2016 15:02:55 +0000
Subject: [PATCH 3/3] clk: Provide OF helper to mark clocks as CRITICAL
In-Reply-To: <56B0B1AE.2060502@arm.com>
References: <1453127331-20616-1-git-send-email-lee.jones@linaro.org>
 <1453127331-20616-4-git-send-email-lee.jones@linaro.org>
 <56A95811.8010200@arm.com> <20160201063256.GE32462@lukather>
 <56B0B1AE.2060502@arm.com>
Message-ID: <20160202150255.GA9906@x1>

On Tue, 02 Feb 2016, Andre Przywara wrote:

> Hi Maxime,
> 
> On 01/02/16 06:32, Maxime Ripard wrote:
> > Hi Andre,
> > 
> > On Wed, Jan 27, 2016 at 11:51:45PM +0000, Andr? Przywara wrote:
> >> Hi,
> >>
> >> On 18/01/16 14:28, Lee Jones wrote:
> >>> This call matches clocks which have been marked as critical in DT
> >>> and sets the appropriate flag.  These flags can then be used to
> >>> mark the clock core flags appropriately prior to registration.
> >>
> >> I like the idea of having a generic property very much. Also this solves
> >> a problem I have in a very elegant way.
> > 
> > Not really. It has a significant set of drawbacks that we already
> > detailed in the initial thread, which are mostly related to the fact
> > that the clocks are to be left on is something that totally depends on
> > the software support in the kernel. Some clocks should be reported as
> > critical because they are simply missing a driver for it, some should
> > be because the driver for it as not been compiled, some should because
> > we don't have the proper clocks drivers yet for one of their
> > downstream clocks.
> > 
> > Basically, it all boils down to this: some clocks should never ever be
> > shutdown because <hardware reason>, and I believe it's the case Lee is
> > in. But most of the current code that would use it might, and might
> > even need at some point to shut down such a clock.
> 
> I was bascically interested in pushing the critical-clock property into
> DT to solve that cumbersome clk-sunxi init scheme - which you have fixed
> now in a much better way (thanks for that, btw.)
> For that particular case the CPU clock really looks like being actually
> critical in the hardware sense - no-one maybe except the mgmt core
> should turn the one single CPU clock source off.
> 
> So I wonder if we should document this "for hardware reasons only" and
> still have that property in DT?
> At the weekend I coded something into the generic DT clock code to let
> it parse for basically every clock node - without a particular driver
> needing to ask for it.
> If this sounds useful to you I can post that one.

It sounds very useful.  Very useful indeed.  But then I would say
that, because that's how this all started in the first place: ;)

  https://lkml.org/lkml/2015/7/22/299

I still think it's a pretty elegant method, but it was NACKed by Mike.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From matthias.bgg at gmail.com  Tue Feb  2 07:12:40 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 2 Feb 2016 16:12:40 +0100
Subject: [PATCH 01/11] irqchip: sun4i: fix compilation outside of arch/arm
In-Reply-To: <1454348370-3816-2-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-2-git-send-email-andre.przywara@arm.com>
Message-ID: <56B0C768.3020805@gmail.com>

On 01/02/16 18:39, Andre Przywara wrote:
> The Allwinner sunxi specific interrupt controller cannot be compiled
> for any architecture except arm:

s/arm/arm64


From matthias.bgg at gmail.com  Tue Feb  2 07:20:59 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 2 Feb 2016 16:20:59 +0100
Subject: [PATCH 04/11] arm64: Introduce Allwinner SoC config option
In-Reply-To: <1454348370-3816-5-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-5-git-send-email-andre.przywara@arm.com>
Message-ID: <56B0C95B.4040500@gmail.com>



On 01/02/16 18:39, Andre Przywara wrote:
> To prepare for the Allwinner A64 SoC support, introduce a config
> option to allow compiling Allwinner (aka. sunxi) specific drivers
> for the arm64 architecture as well.
> This patch just defines the ARCH_SUNXI symbol to allow Allwinner
> specific drivers to be selected during kernel configuration.
> Since the MMC driver is quite essential for Linux to be useful, select
> it by default.
>

This mostly depends on the board you have. The rootfs could be on the 
flash, on nfs or even on a usb stick.

I don't see why MMC support should be essential for A64 SoC.

Regards,
Matthias


From horms+renesas at verge.net.au  Tue Feb  2 07:22:47 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Feb 2016 16:22:47 +0100
Subject: [GIT PULL] Renesas ARM Based SoC Defconfig Updates for v4.6
Message-ID: <cover.1454409855.git.horms+renesas@verge.net.au>

Hi Olof, Hi Kevin, Hi Arnd,

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


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

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

for you to fetch changes up to 20cc7dd4d03d912d28a642701f08c7dba8622436:

  ARM: multi_v7_defconfig: Enable XHCI_RCAR (2016-01-27 18:23:03 +0900)

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

* Enable XHCI_RCAR
* Do not enable CONFIG_CPU_BPREDICT_DISABLE

----------------------------------------------------------------
Geert Uytterhoeven (1):
      ARM: shmobile: defconfig: Do not enable CONFIG_CPU_BPREDICT_DISABLE

Simon Horman (2):
      ARM: shmobile: enable XHCI_RCAR in defconfig
      ARM: multi_v7_defconfig: Enable XHCI_RCAR

 arch/arm/configs/multi_v7_defconfig | 1 +
 arch/arm/configs/shmobile_defconfig | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)


From horms+renesas at verge.net.au  Tue Feb  2 07:23:02 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Feb 2016 16:23:02 +0100
Subject: [PATCH 1/3] ARM: shmobile: defconfig: Do not enable
 CONFIG_CPU_BPREDICT_DISABLE
In-Reply-To: <cover.1454409855.git.horms+renesas@verge.net.au>
References: <cover.1454409855.git.horms+renesas@verge.net.au>
Message-ID: <406663ed61c8ad2b792824af1c1bc0e4faa711c6.1454409855.git.horms+renesas@verge.net.au>

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

Do not disable branch prediction, as this has a big performance impact.

After re-enabling branch prediction, __loop_delay() runs 16 (Cortex A15)
or 11 (Cortex A9) times faster than before.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at 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 969738324a5d..5208b5caacd1 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -20,7 +20,6 @@ CONFIG_ARCH_R8A7791=y
 CONFIG_ARCH_R8A7793=y
 CONFIG_ARCH_R8A7794=y
 CONFIG_ARCH_SH73A0=y
-CONFIG_CPU_BPREDICT_DISABLE=y
 CONFIG_PL310_ERRATA_588369=y
 CONFIG_ARM_ERRATA_754322=y
 CONFIG_PCI=y
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Tue Feb  2 07:23:04 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Feb 2016 16:23:04 +0100
Subject: [PATCH 3/3] ARM: multi_v7_defconfig: Enable XHCI_RCAR
In-Reply-To: <cover.1454409855.git.horms+renesas@verge.net.au>
References: <cover.1454409855.git.horms+renesas@verge.net.au>
Message-ID: <20cc7dd4d03d912d28a642701f08c7dba8622436.1454409855.git.horms+renesas@verge.net.au>

This is used by Renesas R-Car SoCs.

Signed-off-by: Simon Horman <horms+renesas at 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 314f6be2dca2..69d6a6d358cb 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -577,6 +577,7 @@ CONFIG_SND_SOC_WM8978=m
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_MVEBU=y
+CONFIG_USB_XHCI_RCAR=m
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_MSM=m
 CONFIG_USB_EHCI_EXYNOS=y
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Tue Feb  2 07:23:03 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue,  2 Feb 2016 16:23:03 +0100
Subject: [PATCH 2/3] ARM: shmobile: enable XHCI_RCAR in defconfig
In-Reply-To: <cover.1454409855.git.horms+renesas@verge.net.au>
References: <cover.1454409855.git.horms+renesas@verge.net.au>
Message-ID: <ae6b99bc6928d13856172f287ee21be2eac39673.1454409855.git.horms+renesas@verge.net.au>

Signed-off-by: Simon Horman <horms+renesas at 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 5208b5caacd1..b7b714c3958c 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -162,6 +162,8 @@ CONFIG_SND_SOC_RSRC_CARD=y
 CONFIG_SND_SOC_AK4642=y
 CONFIG_SND_SOC_WM8978=y
 CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_RCAR=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_R8A66597_HCD=y
-- 
2.7.0.rc3.207.g0ac5344



From andre.przywara at arm.com  Tue Feb  2 07:30:48 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 2 Feb 2016 15:30:48 +0000
Subject: [PATCH 04/11] arm64: Introduce Allwinner SoC config option
In-Reply-To: <56B0C95B.4040500@gmail.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-5-git-send-email-andre.przywara@arm.com>
 <56B0C95B.4040500@gmail.com>
Message-ID: <56B0CBA8.3020804@arm.com>

Hi,

On 02/02/16 15:20, Matthias Brugger wrote:
> 
> 
> On 01/02/16 18:39, Andre Przywara wrote:
>> To prepare for the Allwinner A64 SoC support, introduce a config
>> option to allow compiling Allwinner (aka. sunxi) specific drivers
>> for the arm64 architecture as well.
>> This patch just defines the ARCH_SUNXI symbol to allow Allwinner
>> specific drivers to be selected during kernel configuration.
>> Since the MMC driver is quite essential for Linux to be useful, select
>> it by default.
>>
> 
> This mostly depends on the board you have. The rootfs could be on the
> flash, on nfs or even on a usb stick.

Yeah, could be. It's just that all boards I know of so far have either
SD card or eMMC.
Maybe it's better put in defconfig. I just want to avoid people getting
disappointed when enabling Allwinner support and not being able to use
it properly. You know that arm64 has only _one_ defconfig to rule them
all, so compiling a special kernel with magic config options is not the
usual drill for arm64 - for good reasons.

> I don't see why MMC support should be essential for A64 SoC.

So I guess I put it in defconfig then, together with the patch to
actually enable Allwinner support by default, which I forgot in this series.

Cheers,
Andre.


From marc.zyngier at arm.com  Tue Feb  2 07:32:04 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 2 Feb 2016 15:32:04 +0000
Subject: [PATCH v2 21/21] arm64: Panic when VHE and non VHE CPUs coexist
In-Reply-To: <20160201153605.GA1478@cbox>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-22-git-send-email-marc.zyngier@arm.com>
 <20160201153605.GA1478@cbox>
Message-ID: <56B0CBF4.9030507@arm.com>

On 01/02/16 15:36, Christoffer Dall wrote:
> On Mon, Jan 25, 2016 at 03:53:55PM +0000, Marc Zyngier wrote:
>> Having both VHE and non-VHE capable CPUs in the same system
>> is likely to be a recipe for disaster.
>>
>> If the boot CPU has VHE, but a secondary is not, we won't be
>> able to downgrade and run the kernel at EL1. Add CPU hotplug
>> to the mix, and this produces a terrifying mess.
>>
>> Let's solve the problem once and for all. If you mix VHE and
>> non-VHE CPUs in the same system, you deserve to loose, and this
>> patch makes sure you don't get a chance.
>>
>> This is implemented by storing the kernel execution level in
>> a global variable. Secondaries will park themselves in a
>> WFI loop if they observe a mismatch. Also, the primary CPU
>> will detect that the secondary CPU has died on a mismatched
>> execution level. Panic will follow.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/include/asm/virt.h | 17 +++++++++++++++++
>>  arch/arm64/kernel/head.S      | 19 +++++++++++++++++++
>>  arch/arm64/kernel/smp.c       |  3 +++
>>  3 files changed, 39 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
>> index 9f22dd6..f81a345 100644
>> --- a/arch/arm64/include/asm/virt.h
>> +++ b/arch/arm64/include/asm/virt.h
>> @@ -36,6 +36,11 @@
>>   */
>>  extern u32 __boot_cpu_mode[2];
>>  
>> +/*
>> + * __run_cpu_mode records the mode the boot CPU uses for the kernel.
>> + */
>> +extern u32 __run_cpu_mode[2];
>> +
>>  void __hyp_set_vectors(phys_addr_t phys_vector_base);
>>  phys_addr_t __hyp_get_vectors(void);
>>  
>> @@ -60,6 +65,18 @@ static inline bool is_kernel_in_hyp_mode(void)
>>  	return el == CurrentEL_EL2;
>>  }
>>  
>> +static inline bool is_kernel_mode_mismatched(void)
>> +{
>> +	/*
>> +	 * A mismatched CPU will have written its own CurrentEL in
>> +	 * __run_cpu_mode[1] (initially set to zero) after failing to
>> +	 * match the value in __run_cpu_mode[0]. Thus, a non-zero
>> +	 * value in __run_cpu_mode[1] is enough to detect the
>> +	 * pathological case.
>> +	 */
>> +	return !!ACCESS_ONCE(__run_cpu_mode[1]);
>> +}
>> +
>>  /* The section containing the hypervisor text */
>>  extern char __hyp_text_start[];
>>  extern char __hyp_text_end[];
>> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
>> index 2a7134c..bc44cf8 100644
>> --- a/arch/arm64/kernel/head.S
>> +++ b/arch/arm64/kernel/head.S
>> @@ -577,7 +577,23 @@ ENTRY(set_cpu_boot_mode_flag)
>>  1:	str	w20, [x1]			// This CPU has booted in EL1
>>  	dmb	sy
>>  	dc	ivac, x1			// Invalidate potentially stale cache line
>> +	adr_l	x1, __run_cpu_mode
>> +	ldr	w0, [x1]
>> +	mrs	x20, CurrentEL
>> +	cbz	x0, skip_el_check
>> +	cmp	x0, x20
>> +	bne	mismatched_el
> 
> can't you do a ret here instead of writing the same value and flushing
> caches etc.?

Yes, good point.

> 
>> +skip_el_check:			// Only the first CPU gets to set the rule
>> +	str	w20, [x1]
>> +	dmb	sy
>> +	dc	ivac, x1	// Invalidate potentially stale cache line
>>  	ret
>> +mismatched_el:
>> +	str	w20, [x1, #4]
>> +	dmb	sy
>> +	dc	ivac, x1	// Invalidate potentially stale cache line
>> +1:	wfi
> 
> I'm no expert on SMP bringup, but doesn't this prevent the CPU from
> signaling completion and thus you'll never actually reach the checking
> code in __cpu_up?

Indeed, and that's the whole point. The primary CPU will notice that the
secondary CPU has failed to boot (timeout), and will find the reason in
__run_cpu_mode.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From andre.przywara at arm.com  Tue Feb  2 07:32:57 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 2 Feb 2016 15:32:57 +0000
Subject: [PATCH 01/11] irqchip: sun4i: fix compilation outside of arch/arm
In-Reply-To: <56B0C768.3020805@gmail.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-2-git-send-email-andre.przywara@arm.com>
 <56B0C768.3020805@gmail.com>
Message-ID: <56B0CC29.4060703@arm.com>

Hi,

On 02/02/16 15:12, Matthias Brugger wrote:
> On 01/02/16 18:39, Andre Przywara wrote:
>> The Allwinner sunxi specific interrupt controller cannot be compiled
>> for any architecture except arm:
> 
> s/arm/arm64

???

As it stands it only compiles for arm, and not arm64, so "cannot be
compile for any architecture except arm" is the right thing to say, no?

Or did I get confused by my own double negation?

Cheers,
Andre.


From ulf.hansson at linaro.org  Tue Feb  2 07:35:37 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 2 Feb 2016 16:35:37 +0100
Subject: [PATCH V5 08/14] PM / Domains: Add function to remove a pm-domain
In-Reply-To: <1453998832-27383-9-git-send-email-jonathanh@nvidia.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-9-git-send-email-jonathanh@nvidia.com>
Message-ID: <CAPDyKFqJLdoee4a9819XukXTmYyd3pue452K_zbiV6XhfA=fTw@mail.gmail.com>

On 28 January 2016 at 17:33, Jon Hunter <jonathanh at nvidia.com> wrote:
> The genpd framework allows users to add power-domains via the
> pm_genpd_init() function, however, there is no corresponding function
> to remove a power-domain. For most devices this may be fine as the power
> domains are never removed, however, for devices that wish to populate
> the power-domains from within a driver, having the ability to remove a
> power domain if the probing of the device fails or the driver is unloaded
> is necessary. Therefore, add a function to remove a power-domain. Please
> note that the power domain can only be removed if there are no devices
> using the power-domain and it is not linked to another domain.
>
> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
> ---
>  drivers/base/power/domain.c | 26 ++++++++++++++++++++++++++
>  include/linux/pm_domain.h   |  5 +++++
>  2 files changed, 31 insertions(+)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 45e3641b427d..b4120121bcac 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -1529,6 +1529,32 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
>  }
>  EXPORT_SYMBOL_GPL(pm_genpd_init);
>
> +/**
> + * pm_genpd_remove - Remove a generic I/O PM domain object.
> + * @genpd: PM domain object to remove.
> + */
> +int pm_genpd_remove(struct generic_pm_domain *genpd)
> +{
> +       if (IS_ERR_OR_NULL(genpd))
> +               return -EINVAL;
> +
> +       mutex_lock(&genpd->lock);

pm_genpd_summary_show() first locks the gpd_list_lock, then the genpd lock.

Please preserve that order here as well, to prevent potential deadlocks.

> +
> +       if (!list_empty(&genpd->master_links)
> +           || !list_empty(&genpd->slave_links) || genpd->device_count) {
> +               mutex_unlock(&genpd->lock);
> +               return -EBUSY;
> +       }
> +
> +       mutex_lock_nested(&gpd_list_lock, SINGLE_DEPTH_NESTING);

Why the nesting, can this really cause lockdep warnings?

> +       list_del(&genpd->gpd_list_node);
> +       mutex_unlock(&gpd_list_lock);
> +       mutex_unlock(&genpd->lock);

Before returning, you need to make sure there isn't a scheduled work
for powering off the genpd.
That might happen for example happen via genpd_poweroff_unused().

Otherwise, the caller of pm_genpd_remove() might free the memory while
the genpd struct is still in use...

I assume a cancel_delayed_work_sync() should do the trick here.

> +
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(pm_genpd_remove);
> +
>  #ifdef CONFIG_PM_GENERIC_DOMAINS_OF
>  /*
>   * Device Tree based PM domain providers.
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index db21d3995f7e..0d661998fa74 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -123,6 +123,7 @@ extern int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
>                                      struct generic_pm_domain *target);
>  extern void pm_genpd_init(struct generic_pm_domain *genpd,
>                           struct dev_power_governor *gov, bool is_off);
> +extern int pm_genpd_remove(struct generic_pm_domain *genpd);
>
>  extern struct dev_power_governor simple_qos_governor;
>  extern struct dev_power_governor pm_domain_always_on_gov;
> @@ -161,6 +162,10 @@ static inline void pm_genpd_init(struct generic_pm_domain *genpd,
>                                  struct dev_power_governor *gov, bool is_off)
>  {
>  }
> +static inline int pm_genpd_remove(struct generic_pm_domain *genpd)
> +{
> +       return -ENOTSUPP;
> +}
>  #endif
>
>  static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,
> --
> 2.1.4
>

Kind regards
Uffe


From christoffer.dall at linaro.org  Tue Feb  2 07:42:12 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 2 Feb 2016 16:42:12 +0100
Subject: [PATCH v2 06/21] arm64: KVM: VHE: Patch out use of HVC
In-Reply-To: <56AF95C0.3080006@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-7-git-send-email-marc.zyngier@arm.com>
 <20160201131634.GI1478@cbox> <56AF5ED8.7010303@arm.com>
 <20160201153635.GH15514@e104818-lin.cambridge.arm.com>
 <56AF85D8.7080907@arm.com>
 <CAKv+Gu9_KG7Zss3g1OMzcnRKQFhCcYtbSDEk-gwwgqPP-R6DOA@mail.gmail.com>
 <56AF95C0.3080006@arm.com>
Message-ID: <20160202154212.GD6190@cbox>

On Mon, Feb 01, 2016 at 05:28:32PM +0000, Marc Zyngier wrote:
> On 01/02/16 17:08, Ard Biesheuvel wrote:
> > On 1 February 2016 at 17:20, Marc Zyngier <marc.zyngier at arm.com> wrote:
> >> On 01/02/16 15:36, Catalin Marinas wrote:
> >>> On Mon, Feb 01, 2016 at 01:34:16PM +0000, Marc Zyngier wrote:
> >>>> On 01/02/16 13:16, Christoffer Dall wrote:
> >>>>> On Mon, Jan 25, 2016 at 03:53:40PM +0000, Marc Zyngier wrote:
> >>>>>> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
> >>>>>> index 93e8d983..9e0683f 100644
> >>>>>> --- a/arch/arm64/kvm/hyp/hyp-entry.S
> >>>>>> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
> >>>>>> @@ -38,6 +38,32 @@
> >>>>>>    ldp     x0, x1, [sp], #16
> >>>>>>  .endm
> >>>>>>
> >>>>>> +.macro do_el2_call
> >>>>>> +  /*
> >>>>>> +   * Shuffle the parameters before calling the function
> >>>>>> +   * pointed to in x0. Assumes parameters in x[1,2,3].
> >>>>>> +   */
> >>>>>> +  stp     lr, xzr, [sp, #-16]!
> >>>>>
> >>>>> remind me why this pair isn't just doing "str" instead of "stp" with the
> >>>>> xzr ?
> >>>>
> >>>> Because SP has to be aligned on a 16 bytes boundary at all times.
> >>>
> >>> You could do something like:
> >>>
> >>>       sub     sp, sp, #16
> >>>       str     lr, [sp]
> >>>
> >>
> >> Ah, fair enough. I'll fold that in.
> >>
> > 
> > Since we're micro-reviewing: what's wrong with
> > 
> > str lr, [sp, #-16]!
> > 
> > ?
> > 
> 
> I suspect that on most micro-architectures, a register writeback is
> going to be slower than doing the sub independently.
> 
> I may be wrong, though.
> 
For the record, I don't mind it the way it was in the original patch
either, I was just curious about the store of xzr and had forgottten the
stack alignment thing.

-Christoffer


From ynorov at caviumnetworks.com  Tue Feb  2 07:43:31 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Tue, 2 Feb 2016 18:43:31 +0300
Subject: [PATCH 1/5] all: s390: move wrapper infrastructure to generic
 headers
In-Reply-To: <20160202073913.GB3990@osiris>
References: <1453741047-5498-1-git-send-email-ynorov@caviumnetworks.com>
 <1453741047-5498-2-git-send-email-ynorov@caviumnetworks.com>
 <20160128121618.GB5418@osiris> <20160128163109.GA8529@yury-N73SV>
 <20160201114251.GB973@yury-N73SV> <20160202073913.GB3990@osiris>
Message-ID: <20160202154331.GA3003@yury-N73SV>

On Tue, Feb 02, 2016 at 08:39:13AM +0100, Heiko Carstens wrote:
> On Mon, Feb 01, 2016 at 02:42:51PM +0300, Yury Norov wrote:
> > Hi Heiko,
> > 
> > I tried this idea, and I don't like what happened.
> >  - Wrappers around safe syscalls does exist. We can remove it by
> >    overcomplicating __SC_COMPAT_CAST, but I don't like it.
> >  - We still need to declare numerous list of new compat syscalls.
> >    And it becomes even bigger, as we need to declare all compat
> >    syscall versions not declared in include/linux/compat.h already.
> >    (Currently - only for unsafe syscalls.)
> >  - 'Weak' trick doesn't work for the whole kernel, so we'd figure out
> >    some new prefix for wrapped syscalls. Or declare all non-compat
> >    syscalls explicitly with SYSCALL_COMPAT_DEFINE. So the list of
> >    replacements grow. And for me, it's harder to explain why we are
> >    wrapping safe syscalls. Or we introduce another bunch of useless
> >    wrappers (with new prefix), and have to handle it in non-compat code.
> >  - With all listed above, we move all wrapper logic to non-compat
> >    'include/linux/syscalls.h' header. Which is not a good idea, if it
> >    doesn't benefit us much in return.
> > 
> > > > No need to look up if a compat variant (or wrapper) exists or
> > > > sys_<syscallname> should be used instead. Also no possibility for security
> > > > bugs that could creep in because SYSCALL_DEFINE has been used instead of
> > > > SYSCALL_DEFINE_WRAP.
> > 
> > I thought again about it. With current version, it's very easy to
> > define whether we have wrapper or not - just by macro we use. Once
> > reviewed, this list is hardly to be changed frequently. If someone is
> > introducing new syscall, it will attract much attention, so security
> > risk is minimal.
> > 
> > Maybe I missed some elegant implementation, and if so  I'll be happy
> > if someone'll point me out. But with what I see, I'd vote for what we
> > have now. (Plus description in docs, plus renaming new macro.)
> 
> Well, I'd like to have some proof by the compiler or linker that nothing
> went wrong. Which seems hard if only selected system call defines will be
> converted to the new defines.
> 
> How can you tell that nothing has been forgotten?
> 
> Also, what happens if the prototype of a system call get's changed shortly
> after it was merged. We might miss such changes and have bugs.
> 

As for now, there's no such proof, and everything is OK. Syscall ABI
is extremely conservative, and Greg KH, and other people spent a lot
of efforts to keep it that way. This is the only reason for me to not
worry much about it. Modification of syscall ABI is virtually
impossible now, because it breaks binary compatibility. Even addition
of new syscall is very difficult procedure.
(Documentation/adding-syscalls.txt begins with section "System Call
Alternatives".)

We can invent some protection, but it will cost us in complexity and/or
runtime delays. Because syscall ABI is so stable, I think it's OK to
review wrappers carefully once, and they will be fine for long time.

> Therefore, and to get to a solution, I think we should stick with your
> first idea, which only moves the compat_wrapper.c file.
> 
> Before doing that I think you should actually revert this patch: my commit
> 7681df456f97 ("s390/compat: remove superfluous compat wrappers") probably
> wasn't a very bright idea :)
> 

This patch is OK for me. pid_t, uid_t, gid_t, unsigned and signed int
types are all 32-bit both on LP64 and ILP32. Normally, compiler should
care about top halves... Did I miss something?

> This again allows me to use only compat system calls in s390's system call
> table (execpt for system calls without parameters, but that can be easily
> fixed).
> 
> What I still don't like is that you need to add all the protoypes. Why are
> the system call tables actually written in C and not in asm?

Because generic unistd code is multi-platform by intention.

I don't know much about s390 specifics. Maybe because of that I do not
understand completely your worries. I'm OK with both 1st and 2nd
version, but I'd choose 2nd one because it allows inlines, and we
don't need the compat_wrapper.c. 


From christoffer.dall at linaro.org  Tue Feb  2 07:46:45 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 2 Feb 2016 16:46:45 +0100
Subject: [PATCH v2 10/21] arm64: KVM: VHE: Split save/restore of sysregs
 shared between EL1 and EL2
In-Reply-To: <56B07ADD.60300@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-11-git-send-email-marc.zyngier@arm.com>
 <20160201135438.GL1478@cbox> <56B07ADD.60300@arm.com>
Message-ID: <20160202154645.GE6190@cbox>

On Tue, Feb 02, 2016 at 09:46:05AM +0000, Marc Zyngier wrote:
> On 01/02/16 13:54, Christoffer Dall wrote:
> > On Mon, Jan 25, 2016 at 03:53:44PM +0000, Marc Zyngier wrote:
> >> A handful of system registers are still shared between EL1 and EL2,
> >> even while using VHE. These are tpidr*_el[01], actlr_el1, sp0, elr,
> >> and spsr.
> > 
> > So by shared registers you mean registers that do both have an EL0/1
> > version as well as an EL2 version, but where accesses aren't rewritten
> > transparently?
> 
> No, I mean that these registers do *not* have a separate banked version.
> There is only a single set of registers, which have to be save/restored
> the old way.

huh, ARMv8 clearly specifies the existence of TPIDR_EL0, TPIDR_EL1, and
TPIDR_EL2, for example.

I cannot seem to find anywhere in the VHE spec that says that the
TPIDR_EL2 goes away.  I'm confused now.

> 
> > 
> > also, by sp0 do you mean sp_el0, and by elr you mean elr_el1, and by
> > spsr you mean spsr_el1 ?
> 
> sp0 -> sp_el0 indeed. elr and spsr really are the guest PC and PSTATE,
> so I should really reword this commit message, it is utterly confusing.
> 
I guess I don't understand the definition of a 'shared' register given
your comments here...

Thanks,
-Christoffer


From christoffer.dall at linaro.org  Tue Feb  2 07:47:42 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 2 Feb 2016 16:47:42 +0100
Subject: [PATCH v2 18/21] arm64: KVM: Introduce hyp_alternate_value helper
In-Reply-To: <56B0B230.6070600@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-19-git-send-email-marc.zyngier@arm.com>
 <20160201144103.GX1478@cbox> <56B0B230.6070600@arm.com>
Message-ID: <20160202154742.GF6190@cbox>

On Tue, Feb 02, 2016 at 01:42:08PM +0000, Marc Zyngier wrote:
> On 01/02/16 14:41, Christoffer Dall wrote:
> > On Mon, Jan 25, 2016 at 03:53:52PM +0000, Marc Zyngier wrote:
> >> We already have hyp_alternate_select() to define a function pointer
> >> that gets changed by a kernel feature or workaround.
> >>
> >> It would be useful to have a similar feature that resolves in a
> >> direct value, without requiring a function call. For this purpose,
> >> introduce hyp_alternate_value(), which returns one of two values
> >> depending on the state of the alternative.
> >>
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >> ---
> >>  arch/arm64/kvm/hyp/hyp.h | 11 +++++++++++
> >>  1 file changed, 11 insertions(+)
> >>
> >> diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
> >> index 44eaff7..dc75fdb 100644
> >> --- a/arch/arm64/kvm/hyp/hyp.h
> >> +++ b/arch/arm64/kvm/hyp/hyp.h
> >> @@ -144,6 +144,17 @@ typeof(orig) * __hyp_text fname(void)					\
> >>  	return val;							\
> >>  }
> >>  
> >> +#define hyp_alternate_value(fname, orig, alt, cond)			\
> >> +typeof(orig) __hyp_text fname(void)					\
> >> +{									\
> >> +	typeof(alt) val = orig;						\
> >> +	asm volatile(ALTERNATIVE("nop		\n",			\
> >> +				 "mov	%0, %1	\n",			\
> >> +				 cond)					\
> >> +		     : "+r" (val) : "r" ((typeof(orig))alt));		\
> >> +	return val;							\
> >> +}
> >> +
> >>  void __vgic_v2_save_state(struct kvm_vcpu *vcpu);
> >>  void __vgic_v2_restore_state(struct kvm_vcpu *vcpu);
> >>  
> >> -- 
> >> 2.1.4
> >>
> > I'm really not convinced that this is more readable than simply defining
> > a function where needed.  Perhaps the thing that needs a definition is
> > the "asm volatile(ALTERNATIVE(...))" part?  I also don't see why any of
> > this is specific to KVM or Hyp ?
> 
> I can easily factor out the whole asm volatile part. What I'm trying to
> avoid is an additional function call, but maybe we shouldn't need to
> worry about the overhead on page faults altogether?
> 
> I'll drop it for now, and we can reconsider it later.
> 
Sounds good to me.

Thanks,
-Christoffer


From arnd at arndb.de  Tue Feb  2 07:47:58 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue,  2 Feb 2016 16:47:58 +0100
Subject: [PATCH] [media] msp3400: use IS_ENABLED check instead of #if
Message-ID: <1454428087-3852112-1-git-send-email-arnd@arndb.de>

A recent patch broke the msp3400 driver when CONFIG_MEDIA_CONTROLLER
is not set:

drivers/media/i2c/msp3400-driver.h:107:5: error: "CONFIG_MEDIA_CONTROLLER" is not defined [-Werror=undef]

It was clearly a typo, and this patch changes the
"#if CONFIG_MEDIA_CONTROLLER" to a working IS_ENABLED() check.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: fb4932821731 ("[media] msp3400: initialize MC data")
---
 drivers/media/i2c/msp3400-driver.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/msp3400-driver.h b/drivers/media/i2c/msp3400-driver.h
index f0bb37dc9013..a8702aca187a 100644
--- a/drivers/media/i2c/msp3400-driver.h
+++ b/drivers/media/i2c/msp3400-driver.h
@@ -104,7 +104,7 @@ struct msp_state {
 	unsigned int         restart:1;
 	unsigned int         watch_stereo:1;
 
-#if CONFIG_MEDIA_CONTROLLER
+#if IS_ENABLED(CONFIG_MEDIA_CONTROLLER)
 	struct media_pad pads[IF_AUD_DEC_PAD_NUM_PADS];
 #endif
 };
-- 
2.7.0



From christoffer.dall at linaro.org  Tue Feb  2 07:50:16 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 2 Feb 2016 16:50:16 +0100
Subject: [PATCH v2 19/21] arm64: KVM: Move most of the fault decoding to C
In-Reply-To: <56B0BC10.40309@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-20-git-send-email-marc.zyngier@arm.com>
 <20160201152122.GY1478@cbox> <56B0BC10.40309@arm.com>
Message-ID: <20160202155016.GG6190@cbox>

On Tue, Feb 02, 2016 at 02:24:16PM +0000, Marc Zyngier wrote:
> On 01/02/16 15:21, Christoffer Dall wrote:
> > On Mon, Jan 25, 2016 at 03:53:53PM +0000, Marc Zyngier wrote:
> >> The fault decoding process (including computing the IPA in the case
> >> of a permission fault) would be much better done in C code, as we
> >> have a reasonable infrastructure to deal with the VHE/non-VHE
> >> differences.
> >>
> >> Let's move the whole thing to C, including the workaround for
> >> erratum 834220, and just patch the odd ESR_EL2 access remaining
> >> in hyp-entry.S.
> >>
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >> ---
> >>  arch/arm64/kernel/asm-offsets.c |  3 --
> >>  arch/arm64/kvm/hyp/hyp-entry.S  | 69 +++--------------------------------------
> >>  arch/arm64/kvm/hyp/switch.c     | 54 ++++++++++++++++++++++++++++++++
> >>  3 files changed, 59 insertions(+), 67 deletions(-)
> >>
> >> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> >> index fffa4ac6..b0ab4e9 100644
> >> --- a/arch/arm64/kernel/asm-offsets.c
> >> +++ b/arch/arm64/kernel/asm-offsets.c
> >> @@ -110,9 +110,6 @@ int main(void)
> >>    DEFINE(CPU_USER_PT_REGS,	offsetof(struct kvm_regs, regs));
> >>    DEFINE(CPU_FP_REGS,		offsetof(struct kvm_regs, fp_regs));
> >>    DEFINE(VCPU_FPEXC32_EL2,	offsetof(struct kvm_vcpu, arch.ctxt.sys_regs[FPEXC32_EL2]));
> >> -  DEFINE(VCPU_ESR_EL2,		offsetof(struct kvm_vcpu, arch.fault.esr_el2));
> >> -  DEFINE(VCPU_FAR_EL2,		offsetof(struct kvm_vcpu, arch.fault.far_el2));
> >> -  DEFINE(VCPU_HPFAR_EL2,	offsetof(struct kvm_vcpu, arch.fault.hpfar_el2));
> >>    DEFINE(VCPU_HOST_CONTEXT,	offsetof(struct kvm_vcpu, arch.host_cpu_context));
> >>  #endif
> >>  #ifdef CONFIG_CPU_PM
> >> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
> >> index 9e0683f..213de52 100644
> >> --- a/arch/arm64/kvm/hyp/hyp-entry.S
> >> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
> >> @@ -19,7 +19,6 @@
> >>  
> >>  #include <asm/alternative.h>
> >>  #include <asm/assembler.h>
> >> -#include <asm/asm-offsets.h>
> >>  #include <asm/cpufeature.h>
> >>  #include <asm/kvm_arm.h>
> >>  #include <asm/kvm_asm.h>
> >> @@ -67,7 +66,11 @@ ENDPROC(__vhe_hyp_call)
> >>  el1_sync:				// Guest trapped into EL2
> >>  	save_x0_to_x3
> >>  
> >> +alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
> >>  	mrs	x1, esr_el2
> >> +alternative_else
> >> +	mrs	x1, esr_el1
> >> +alternative_endif
> > 
> > I suppose this is not technically part of what the patch description
> > says it does, but ok...
> 
> That's what the "... and just patch the odd ESR_EL2 access remaining in
> hyp-entry.S." meant. Would you prefer this as a separate patch?
> 

I guess I stopped reading at ", and" for some reason, sorry.

It's fine to keep it in this patch.

> > 
> >>  	lsr	x2, x1, #ESR_ELx_EC_SHIFT
> >>  
> >>  	cmp	x2, #ESR_ELx_EC_HVC64
> >> @@ -103,72 +106,10 @@ el1_trap:
> >>  	cmp	x2, #ESR_ELx_EC_FP_ASIMD
> >>  	b.eq	__fpsimd_guest_restore
> >>  
> >> -	cmp	x2, #ESR_ELx_EC_DABT_LOW
> >> -	mov	x0, #ESR_ELx_EC_IABT_LOW
> >> -	ccmp	x2, x0, #4, ne
> >> -	b.ne	1f		// Not an abort we care about
> >> -
> >> -	/* This is an abort. Check for permission fault */
> >> -alternative_if_not ARM64_WORKAROUND_834220
> >> -	and	x2, x1, #ESR_ELx_FSC_TYPE
> >> -	cmp	x2, #FSC_PERM
> >> -	b.ne	1f		// Not a permission fault
> >> -alternative_else
> >> -	nop			// Use the permission fault path to
> >> -	nop			// check for a valid S1 translation,
> >> -	nop			// regardless of the ESR value.
> >> -alternative_endif
> >> -
> >> -	/*
> >> -	 * Check for Stage-1 page table walk, which is guaranteed
> >> -	 * to give a valid HPFAR_EL2.
> >> -	 */
> >> -	tbnz	x1, #7, 1f	// S1PTW is set
> >> -
> >> -	/* Preserve PAR_EL1 */
> >> -	mrs	x3, par_el1
> >> -	stp	x3, xzr, [sp, #-16]!
> >> -
> >> -	/*
> >> -	 * Permission fault, HPFAR_EL2 is invalid.
> >> -	 * Resolve the IPA the hard way using the guest VA.
> >> -	 * Stage-1 translation already validated the memory access rights.
> >> -	 * As such, we can use the EL1 translation regime, and don't have
> >> -	 * to distinguish between EL0 and EL1 access.
> >> -	 */
> >> -	mrs	x2, far_el2
> >> -	at	s1e1r, x2
> >> -	isb
> >> -
> >> -	/* Read result */
> >> -	mrs	x3, par_el1
> >> -	ldp	x0, xzr, [sp], #16	// Restore PAR_EL1 from the stack
> >> -	msr	par_el1, x0
> >> -	tbnz	x3, #0, 3f		// Bail out if we failed the translation
> >> -	ubfx	x3, x3, #12, #36	// Extract IPA
> >> -	lsl	x3, x3, #4		// and present it like HPFAR
> >> -	b	2f
> >> -
> >> -1:	mrs	x3, hpfar_el2
> >> -	mrs	x2, far_el2
> >> -
> >> -2:	mrs	x0, tpidr_el2
> >> -	str	w1, [x0, #VCPU_ESR_EL2]
> >> -	str	x2, [x0, #VCPU_FAR_EL2]
> >> -	str	x3, [x0, #VCPU_HPFAR_EL2]
> >> -
> >> +	mrs	x0, tpidr_el2
> >>  	mov	x1, #ARM_EXCEPTION_TRAP
> >>  	b	__guest_exit
> >>  
> >> -	/*
> >> -	 * Translation failed. Just return to the guest and
> >> -	 * let it fault again. Another CPU is probably playing
> >> -	 * behind our back.
> >> -	 */
> >> -3:	restore_x0_to_x3
> >> -
> >> -	eret
> >> -
> >>  el1_irq:
> >>  	save_x0_to_x3
> >>  	mrs	x0, tpidr_el2
> >> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> >> index 0cadb7f..df2cce9 100644
> >> --- a/arch/arm64/kvm/hyp/switch.c
> >> +++ b/arch/arm64/kvm/hyp/switch.c
> >> @@ -15,6 +15,7 @@
> >>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >>   */
> >>  
> >> +#include <linux/types.h>
> >>  #include <asm/kvm_asm.h>
> >>  
> >>  #include "hyp.h"
> >> @@ -150,6 +151,55 @@ static void __hyp_text __vgic_restore_state(struct kvm_vcpu *vcpu)
> >>  	__vgic_call_restore_state()(vcpu);
> >>  }
> >>  
> >> +static hyp_alternate_value(__check_arm_834220,
> >> +			   false, true,
> >> +			   ARM64_WORKAROUND_834220);
> >> +
> >> +static bool __hyp_text __populate_fault_info(struct kvm_vcpu *vcpu)
> >> +{
> >> +	u64 esr = read_sysreg_el2(esr);
> >> +	u8 ec = esr >> ESR_ELx_EC_SHIFT;
> >> +	u64 hpfar, far;
> >> +
> >> +	vcpu->arch.fault.esr_el2 = esr;
> >> +
> >> +	if (ec != ESR_ELx_EC_DABT_LOW && ec != ESR_ELx_EC_IABT_LOW)
> >> +		return true;
> >> +
> >> +	far = read_sysreg_el2(far);
> >> +
> >> +	if (!(esr & ESR_ELx_S1PTW) &&
> >> +	    (__check_arm_834220() || (esr & ESR_ELx_FSC_TYPE) == FSC_PERM)) {
> > 
> > this is really hard to read.  How do you feel about putting the below
> > block into its own function and changing to something like this:
> > 
> > /*
> >  * The HPFAR can be invalid if the stage 2 fault did not happen during a
> >  * stage 1 page table walk (the ESR_EL2.S1PTW bit is clear) and one of
> >  * the two following cases are true:
> >  *   1. The fault was due to a permission fault
> >  *   2. The processor carries errata 834220
> >  *
> >  * Therefore, for all non S1PTW faults where we either have a permission
> >  * fault or the errata workaround is enabled, we resolve the IPA using
> >  * the AT instruction.
> >  */
> > if (!(esr & ESR_ELx_S1PTW) &&
> >     (__check_arm_834220() || (esr & ESR_ELx_FSC_TYPE) == FSC_PERM)) {
> >     	if (!__translate_far_to_ipa(&hpfar))
> > 		return false; /* Translation failed, back to guest */
> > } else {
> > 	hpfar = read_sysreg(hpfar_el2);
> > }
> > 
> > not sure if it helps that much, perhaps it's just complicated by nature.
> > 
> >> +		u64 par, tmp;
> >> +
> >> +		/*
> >> +		 * Permission fault, HPFAR_EL2 is invalid. Resolve the
> >> +		 * IPA the hard way using the guest VA.
> >> +		 * Stage-1 translation already validated the memory
> >> +		 * access rights. As such, we can use the EL1
> >> +		 * translation regime, and don't have to distinguish
> >> +		 * between EL0 and EL1 access.
> >> +		 */
> >> +		par = read_sysreg(par_el1);
> > 
> > in any cas I think we also need the comment about preserving par_el1
> > here, which is only something we do because we may return early, IIUC.
> 
> Not only. At that point, we still haven't saved the vcpu sysregs, so we
> most save/restore it in order to save it later for good. Not the fastest
> thing, but I guess that everything sucks so much when we take a page
> fault that it really doesn't matter.
> 

right.  I was a bit confued by reading this code in the C version, but
on the other hand, this code is the kind of code you shouldn't try to
think you can easily understand, but you really have to know what you're
doing here, so perhaps I'm creating too much fuss for nothing.

> > 
> >> +		asm volatile("at s1e1r, %0" : : "r" (far));
> >> +		isb();
> >> +
> >> +		tmp = read_sysreg(par_el1);
> >> +		write_sysreg(par, par_el1);
> >> +
> >> +		if (unlikely(tmp & 1))
> >> +			return false; /* Translation failed, back to guest */
> >> +
> > 
> > nit: add comment /* Convert PAR to HPFAR format */
> > 
> >> +		hpfar = ((tmp >> 12) & ((1UL << 36) - 1)) << 4;
> >> +	} else {
> >> +		hpfar = read_sysreg(hpfar_el2);
> >> +	}
> >> +
> >> +	vcpu->arch.fault.far_el2 = far;
> >> +	vcpu->arch.fault.hpfar_el2 = hpfar;
> >> +	return true;
> >> +}
> >> +
> >>  static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
> >>  {
> >>  	struct kvm_cpu_context *host_ctxt;
> >> @@ -181,9 +231,13 @@ static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
> >>  	__debug_restore_state(vcpu, kern_hyp_va(vcpu->arch.debug_ptr), guest_ctxt);
> >>  
> >>  	/* Jump in the fire! */
> >> +again:
> >>  	exit_code = __guest_enter(vcpu, host_ctxt);
> >>  	/* And we're baaack! */
> >>  
> >> +	if (exit_code == ARM_EXCEPTION_TRAP && !__populate_fault_info(vcpu))
> >> +		goto again;
> >> +
> >>  	fp_enabled = __fpsimd_enabled();
> >>  
> >>  	__sysreg_save_guest_state(guest_ctxt);
> >> -- 
> >> 2.1.4
> >>
> > The good news are that I couldn't find any bugs in the code.
> 
> Right. So I've applied most of your comments directly, because they
> definitely made sense. let's see how it looks on round 3.
> 
ok, sounds great.

Thanks,
-Christoffer


From james.morse at arm.com  Tue Feb  2 07:53:59 2016
From: james.morse at arm.com (James Morse)
Date: Tue,  2 Feb 2016 15:53:59 +0000
Subject: [PATCH] arm64: futex.h: Add missing PAN toggling
Message-ID: <1454428439-10942-1-git-send-email-james.morse@arm.com>

futex.h's futex_atomic_cmpxchg_inatomic() does not use the
__futex_atomic_op() macro and needs its own PAN toggling. This was missed
when the feature was implemented.

Fixes: 338d4f49d6f ("arm64: kernel: Add support for Privileged Access Never")
Signed-off-by: James Morse <james.morse at arm.com>
---
 arch/arm64/include/asm/futex.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/futex.h b/arch/arm64/include/asm/futex.h
index 007a69fc4f40..5f3ab8c1db55 100644
--- a/arch/arm64/include/asm/futex.h
+++ b/arch/arm64/include/asm/futex.h
@@ -121,6 +121,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
 		return -EFAULT;
 
 	asm volatile("// futex_atomic_cmpxchg_inatomic\n"
+ALTERNATIVE("nop", SET_PSTATE_PAN(0), ARM64_HAS_PAN, CONFIG_ARM64_PAN)
 "	prfm	pstl1strm, %2\n"
 "1:	ldxr	%w1, %2\n"
 "	sub	%w3, %w1, %w4\n"
@@ -137,6 +138,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
 "	.align	3\n"
 "	.quad	1b, 4b, 2b, 4b\n"
 "	.popsection\n"
+ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN, CONFIG_ARM64_PAN)
 	: "+r" (ret), "=&r" (val), "+Q" (*uaddr), "=&r" (tmp)
 	: "r" (oldval), "r" (newval), "Ir" (-EFAULT)
 	: "memory");
-- 
2.6.2



From arnd at arndb.de  Tue Feb  2 07:55:30 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue,  2 Feb 2016 16:55:30 +0100
Subject: [PATCH] clk: sunxi: don't mark sun6i_ar100_data __initconst
In-Reply-To: <1453727747-23307-11-git-send-email-wens@csie.org>
References: <1453727747-23307-11-git-send-email-wens@csie.org>
Message-ID: <1454428571-4040607-1-git-send-email-arnd@arndb.de>

The clk-sun6i-ar100 clk driver is a platform driver that may use
deferred probing, so its probe function must not access
__init symbols. Kbuild warns about this:

WARNING: drivers/clk/sunxi/built-in.o(.text+0x15f0): Section mismatch in reference from the function sun6i_a31_ar100_clk_probe() to the (unknown reference) .init.rodata:(unknown)
The function sun6i_a31_ar100_clk_probe() references
the (unknown reference) __initconst (unknown).
This is often because sun6i_a31_ar100_clk_probe lacks a __initconst
annotation or the annotation of (unknown) is wrong.

Removing the __initconst annotation avoids the warning and makes
deferred probing work.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 3ca2377b6fed ("clk: sunxi: rewrite sun6i-ar100 using factors clk")
---
 drivers/clk/sunxi/clk-sun6i-ar100.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi/clk-sun6i-ar100.c b/drivers/clk/sunxi/clk-sun6i-ar100.c
index a7f5777834eb..84a187e55360 100644
--- a/drivers/clk/sunxi/clk-sun6i-ar100.c
+++ b/drivers/clk/sunxi/clk-sun6i-ar100.c
@@ -60,7 +60,7 @@ static const struct clk_factors_config sun6i_ar100_config = {
 	.pshift = 4,
 };
 
-static const struct factors_data sun6i_ar100_data __initconst = {
+static const struct factors_data sun6i_ar100_data = {
 	.mux = 16,
 	.muxmask = GENMASK(1, 0),
 	.table = &sun6i_ar100_config,
-- 
2.7.0



From lkp at intel.com  Tue Feb  2 08:01:14 2016
From: lkp at intel.com (kbuild test robot)
Date: Wed, 3 Feb 2016 00:01:14 +0800
Subject: [PATCH v3 2/2] ASOC: sunxi: Add support for the SPDIF block
In-Reply-To: <1454424594-25208-3-git-send-email-codekipper@gmail.com>
Message-ID: <201602022350.vGAUirEB%fengguang.wu@intel.com>

Hi Marcus,

[auto build test WARNING on asoc/for-next]
[also build test WARNING on v4.5-rc2 next-20160201]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/codekipper-gmail-com/Add-SPDIF-support-for-Allwinner-SoCs/20160202-225229
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next


coccinelle warnings: (new ones prefixed by >>)

>> sound/soc/sunxi/sun4i-spdif.c:572:3-8: No need to set .owner here. The core will do it.

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation


From lkp at intel.com  Tue Feb  2 08:01:15 2016
From: lkp at intel.com (kbuild test robot)
Date: Wed, 3 Feb 2016 00:01:15 +0800
Subject: [PATCH] ASOC: sunxi: fix platform_no_drv_owner.cocci warnings
In-Reply-To: <1454424594-25208-3-git-send-email-codekipper@gmail.com>
References: <201602022350.vGAUirEB%fengguang.wu@intel.com>
Message-ID: <20160202160114.GA234379@ivytown2>

sound/soc/sunxi/sun4i-spdif.c:572:3-8: No need to set .owner here. The core will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Marcus Cooper <codekipper at gmail.com>
Signed-off-by: Fengguang Wu <fengguang.wu at intel.com>
---

 sun4i-spdif.c |    1 -
 1 file changed, 1 deletion(-)

--- a/sound/soc/sunxi/sun4i-spdif.c
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -569,7 +569,6 @@ static const struct dev_pm_ops sun4i_spd
 static struct platform_driver sun4i_spdif_driver = {
 	.driver		= {
 		.name	= "sun4i-spdif",
-		.owner	= THIS_MODULE,
 		.of_match_table = of_match_ptr(sun4i_spdif_of_match),
 		.pm	= &sun4i_spdif_pm,
 	},


From ryabinin.a.a at gmail.com  Tue Feb  2 08:02:49 2016
From: ryabinin.a.a at gmail.com (Andrey Ryabinin)
Date: Tue, 2 Feb 2016 19:02:49 +0300
Subject: [PATCH v6] kernel: add kcov code coverage
In-Reply-To: <1453726850-49137-1-git-send-email-dvyukov@google.com>
References: <1453726850-49137-1-git-send-email-dvyukov@google.com>
Message-ID: <CAPAsAGz6vVGfAPSimwqkneUmzMmrwX_WxdCoQ1xg3UyNn4+-eQ@mail.gmail.com>

2016-01-25 16:00 GMT+03:00 Dmitry Vyukov <dvyukov at google.com>:

> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index ecb9e75..cde6bd1 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -678,6 +678,26 @@ config DEBUG_STACKOVERFLOW
>
>           If in doubt, say "N".
>
> +config ARCH_HAS_KCOV
> +       bool
> +       help
> +         KCOV does not have any arch-specific code, but currently it is enabled
> +         only for x86_64. KCOV requires testing on other archs, and most likely
> +         disabling of instrumentation for some early boot code.
> +
> +config KCOV
> +       bool "Code coverage for fuzzing"
> +       depends on ARCH_HAS_KCOV

I think we should select DEBUG_FS here, since this useless without it.
Also you placed this into 'Memory Debugging' submenu which seems wrong.

> +       help
> +         KCOV exposes kernel code coverage information in a form suitable
> +         for coverage-guided fuzzing (randomized testing).
> +
> +         If RANDOMIZE_BASE is enabled, PC values will not be stable across
> +         different machines and across reboots. If you need stable PC values,
> +         disable RANDOMIZE_BASE.
> +
> +         For more details, see Documentation/kcov.txt.
> +
>  source "lib/Kconfig.kmemcheck"
>


From arnd at arndb.de  Tue Feb  2 08:04:56 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 02 Feb 2016 17:04:56 +0100
Subject: [PATCH 04/11] arm64: Introduce Allwinner SoC config option
In-Reply-To: <56B0CBA8.3020804@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <56B0C95B.4040500@gmail.com> <56B0CBA8.3020804@arm.com>
Message-ID: <6587581.Opm4UCG8SA@wuerfel>

On Tuesday 02 February 2016 15:30:48 Andre Przywara wrote:
> Hi,
> 
> On 02/02/16 15:20, Matthias Brugger wrote:
> > 
> > 
> > On 01/02/16 18:39, Andre Przywara wrote:
> >> To prepare for the Allwinner A64 SoC support, introduce a config
> >> option to allow compiling Allwinner (aka. sunxi) specific drivers
> >> for the arm64 architecture as well.
> >> This patch just defines the ARCH_SUNXI symbol to allow Allwinner
> >> specific drivers to be selected during kernel configuration.
> >> Since the MMC driver is quite essential for Linux to be useful, select
> >> it by default.
> >>
> > 
> > This mostly depends on the board you have. The rootfs could be on the
> > flash, on nfs or even on a usb stick.
> 
> Yeah, could be. It's just that all boards I know of so far have either
> SD card or eMMC.
> Maybe it's better put in defconfig.

Yes, definitely. The current patch also causes a Kconfig warning when
a user disables CONFIG_MMC, as that a dependency for MMC_SUNXI.

There are tons of other options that users need to select to have
a usable system, no need to treat this one special.

	Arnd


From labbott at redhat.com  Tue Feb  2 08:08:04 2016
From: labbott at redhat.com (Laura Abbott)
Date: Tue, 2 Feb 2016 08:08:04 -0800
Subject: [PATCHv2 2/3] arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
In-Reply-To: <20160202123155.GB32305@leverpostej>
References: <1454111218-3461-1-git-send-email-labbott@fedoraproject.org>
 <1454111218-3461-3-git-send-email-labbott@fedoraproject.org>
 <20160201122911.GF674@leverpostej> <56AFCD09.8000807@redhat.com>
 <20160202122317.GA32305@leverpostej> <20160202123155.GB32305@leverpostej>
Message-ID: <56B0D464.9050102@redhat.com>

On 02/02/2016 04:31 AM, Mark Rutland wrote:
> On Tue, Feb 02, 2016 at 12:23:18PM +0000, Mark Rutland wrote:
>   Is there anything else in mm/ that I've potentially missed?
>> I'm seeing a hang on Juno just after reaching userspace (splat below)
>> with debug_pagealloc=on.
>>
>> It looks like something's gone wrong around find_vmap_area -- at least
>> one CPU is forever awaiting vmap_area_lock, and presumably some other
>> CPU has held it and gone into the weeds, leading to the RCU stalls and
>> NMI lockup warnings.
>
> [...]
>
>> I'll have a go with lock debugging.
>
> FWIW, with lock debugging I get the below splat before reaching userspace.
>
> [    0.145869] =================================
> [    0.145901] [ INFO: inconsistent lock state ]
> [    0.145935] 4.5.0-rc1+ #8 Not tainted
> [    0.145964] ---------------------------------
> [    0.145996] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
> [    0.146036] swapper/5/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
> [    0.146070]  (vmap_area_lock){+.?...}, at: [<ffffffc0001a749c>] find_vmap_area+0x1c/0x98
> [    0.146151] {SOFTIRQ-ON-W} state was registered at:
> [    0.146184]   [<ffffffc0000fc2ac>] mark_lock+0x1bc/0x708
> [    0.146229]   [<ffffffc0000feb18>] __lock_acquire+0x928/0x1d90
> [    0.146274]   [<ffffffc00010032c>] lock_acquire+0x9c/0xe0
> [    0.146318]   [<ffffffc0006c8cd8>] _raw_spin_lock+0x40/0x58
> [    0.146362]   [<ffffffc0001a749c>] find_vmap_area+0x1c/0x98
> [    0.146406]   [<ffffffc0001a9c6c>] find_vm_area+0xc/0x38
> [    0.146447]   [<ffffffc000096420>] change_memory_common+0x38/0x120
> [    0.146495]   [<ffffffc0000965dc>] __kernel_map_pages+0x54/0x60
> [    0.146537]   [<ffffffc000176744>] get_page_from_freelist+0x86c/0x9a0
> [    0.146584]   [<ffffffc000176b98>] __alloc_pages_nodemask+0xf0/0x8a0
> [    0.146629]   [<ffffffc0009dd46c>] alloc_pages_exact_nid+0x48/0x90
> [    0.146675]   [<ffffffc0009b8004>] page_ext_init+0x94/0x124
> [    0.146718]   [<ffffffc0009a390c>] start_kernel+0x350/0x3d4
> [    0.146761]   [<ffffffc0000811b4>] 0xffffffc0000811b4
> [    0.146802] irq event stamp: 402
> [    0.146830] hardirqs last  enabled at (402): [<ffffffc000172c58>] free_pages_prepare+0x270/0x330
> [    0.146894] hardirqs last disabled at (401): [<ffffffc000172c58>] free_pages_prepare+0x270/0x330
> [    0.146956] softirqs last  enabled at (368): [<ffffffc0000bc070>] _local_bh_enable+0x20/0x48
> [    0.147022] softirqs last disabled at (369): [<ffffffc0000bca10>] irq_exit+0xa0/0xd8
> [    0.147081]
> [    0.147081] other info that might help us debug this:
> [    0.147130]  Possible unsafe locking scenario:
> [    0.147130]
> [    0.147177]        CPU0
> [    0.147201]        ----
> [    0.147225]   lock(vmap_area_lock);
> [    0.147260]   <Interrupt>
> [    0.147285]     lock(vmap_area_lock);
> [    0.147321]
> [    0.147321]  *** DEADLOCK ***
> [    0.147321]
> [    0.147381] 1 lock held by swapper/5/0:
> [    0.147410]  #0:  (rcu_callback){......}, at: [<ffffffc0001193f0>] rcu_process_callbacks+0x2b8/0x5f8
> [    0.147492]
> [    0.147492] stack backtrace:
> [    0.147538] CPU: 5 PID: 0 Comm: swapper/5 Not tainted 4.5.0-rc1+ #8
> [    0.147577] Hardware name: ARM Juno development board (r0) (DT)
> [    0.147613] Call trace:
> [    0.147644] [<ffffffc000089a38>] dump_backtrace+0x0/0x180
> [    0.147684] [<ffffffc000089bcc>] show_stack+0x14/0x20
> [    0.147724] [<ffffffc000373bb8>] dump_stack+0x90/0xc8
> [    0.147764] [<ffffffc00016bb3c>] print_usage_bug.part.21+0x260/0x278
> [    0.147807] [<ffffffc0000fc238>] mark_lock+0x148/0x708
> [    0.147846] [<ffffffc0000feadc>] __lock_acquire+0x8ec/0x1d90
> [    0.147887] [<ffffffc00010032c>] lock_acquire+0x9c/0xe0
> [    0.147925] [<ffffffc0006c8cd8>] _raw_spin_lock+0x40/0x58
> [    0.147965] [<ffffffc0001a749c>] find_vmap_area+0x1c/0x98
> [    0.148003] [<ffffffc0001a9c6c>] find_vm_area+0xc/0x38
> [    0.148044] [<ffffffc000096420>] change_memory_common+0x38/0x120
> [    0.148084] [<ffffffc0000965c8>] __kernel_map_pages+0x40/0x60
> [    0.148123] [<ffffffc000172cb8>] free_pages_prepare+0x2d0/0x330
> [    0.148164] [<ffffffc000174660>] __free_pages_ok+0x20/0x108
> [    0.148203] [<ffffffc0001750e0>] __free_pages+0x30/0x50
> [    0.148241] [<ffffffc0001753ac>] __free_kmem_pages+0x24/0x50
> [    0.148280] [<ffffffc000175410>] free_kmem_pages+0x38/0x40
> [    0.148320] [<ffffffc0000b5908>] free_task+0x30/0x60
> [    0.148359] [<ffffffc0000b59f8>] __put_task_struct+0xc0/0x110
> [    0.148400] [<ffffffc0000b91bc>] delayed_put_task_struct+0x44/0x50
> [    0.148442] [<ffffffc000119430>] rcu_process_callbacks+0x2f8/0x5f8
> [    0.148482] [<ffffffc0000bc594>] __do_softirq+0x13c/0x278
> [    0.148520] [<ffffffc0000bca10>] irq_exit+0xa0/0xd8
> [    0.148559] [<ffffffc00010ad90>] __handle_domain_irq+0x60/0xb8
> [    0.148599] [<ffffffc0000824f0>] gic_handle_irq+0x58/0xa8
> [    0.148636] Exception stack(0xffffffc97594be30 to 0xffffffc97594bf50)
> [    0.148678] be20:                                   ffffffc975933f00 0000000000000243
> [    0.148734] be40: 000000097e4a7000 0000000000000000 0000000000000000 0000000000000008
> [    0.148791] be60: 00000007de290000 00000000000270f0 0000000000000001 ffffffc975948000
> [    0.148848] be80: ffffffc00179e000 0000000000000000 ffffffc001507000 ffffffc001507f00
> [    0.148903] bea0: 000000000000000e 0000000000000007 0000000000000001 0000000000000007
> [    0.148960] bec0: 000000000000000e ffffffc000a5a000 ffffffc975948000 ffffffc000a5a000
> [    0.149017] bee0: ffffffc000a38c40 ffffffc000a3c460 ffffffc975948000 ffffffc000a5a000
> [    0.149073] bf00: ffffffc000af6000 0000000000000000 0000000000000000 ffffffc97594bf50
> [    0.149130] bf20: ffffffc0000867e0 ffffffc97594bf50 ffffffc0000867e4 0000000060000045
> [    0.149185] bf40: ffffffc97594bf50 ffffffc0000867e0
> [    0.149222] [<ffffffc0000855e4>] el1_irq+0xa4/0x114
> [    0.149260] [<ffffffc0000867e4>] arch_cpu_idle+0x14/0x20
> [    0.149299] [<ffffffc0000f7878>] default_idle_call+0x18/0x30
> [    0.149339] [<ffffffc0000f7a78>] cpu_startup_entry+0x1e8/0x240
> [    0.149380] [<ffffffc00008f064>] secondary_start_kernel+0x16c/0x198
> [    0.149419] [<00000000800827fc>] 0x800827fc
>
> The kernel then happily ran userspace for a while, but running hackbench
> was sufficient to lock it up:
>
> [  132.624028] BUG: spinlock lockup suspected on CPU#4, hackbench/5589
> [  132.624600] BUG: spinlock lockup suspected on CPU#5, hackbench/5270
> [  132.624619]  lock: vmap_area_lock+0x0/0x38, .magic: dead4ead, .owner: hackbench/7089, .owner_cpu: 1
> [  132.626651] BUG: spinlock lockup suspected on CPU#3, hackbench/5280
> [  132.626663]  lock: vmap_area_lock+0x0/0x38, .magic: dead4ead, .owner: hackbench/7089, .owner_cpu: 1
> [  132.628358] BUG: spinlock lockup suspected on CPU#0, init/1
> [  132.628370]  lock: vmap_area_lock+0x0/0x38, .magic: dead4ead, .owner: hackbench/7089, .owner_cpu: 1
> [  132.675602]  lock: vmap_area_lock+0x0/0x38, .magic: dead4ead, .owner: hackbench/7089, .owner_cpu: 1
> [  136.619403] BUG: spinlock lockup suspected on CPU#2, hackbench/6768
> [  136.625640]  lock: vmap_area_lock+0x0/0x38, .magic: dead4ead, .owner: hackbench/7089, .owner_cpu: 1
> [  136.675626] BUG: spinlock lockup suspected on CPU#1, hackbench/7089
> [  136.681860]  lock: vmap_area_lock+0x0/0x38, .magic: dead4ead, .owner: hackbench/7089, .owner_cpu: 1
> [  152.689601] NMI watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [hackbench:7089]
> [  155.149604] INFO: rcu_preempt self-detected stall on CPU
> [  155.149609] INFO: rcu_preempt self-detected stall on CPU
> [  155.149611] INFO: rcu_preempt self-detected stall on CPU
> [  155.149625]  1-...: (6496 ticks this GP) idle=fef/140000000000002/0 softirq=1935/1935 fqs=1
> [  155.149639]
> [  155.149640]  4-...: (6493 ticks this GP) idle=305/140000000000002/0 softirq=1961/1961 fqs=1
> [  155.149650]
> [  155.149651] rcu_preempt kthread starved for 6499 jiffies! g1204 c1203 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
> [  155.149665] rcu_preempt kthread starved for 6499 jiffies! g1204 c1203 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
> [  155.205127]  0-...: (6498 ticks this GP) idle=a2d/140000000000002/0 softirq=2595/2595 fqs=1
> [  155.213526]   (t=6516 jiffies g=1204 c=1203 q=422)
> [  155.218307] rcu_preempt kthread starved for 6516 jiffies! g1204 c1203 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x0
> [  156.677602] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [init:1]
> [  156.701602] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [hackbench:6768]
> [  156.713603] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [hackbench:5280]
> [  156.725602] NMI watchdog: BUG: soft lockup - CPU#4 stuck for 22s! [hackbench:5589]
> [  156.737603] NMI watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [hackbench:5270]
>
> Thanks,
> Mark.
>

Yes, this is absolutely a deadlock with the vmap_lock. Your suggestion to pull it out so
we don't have the extra check should fix it I suspect.

Thanks,
Laura


From heiko.carstens at de.ibm.com  Tue Feb  2 08:08:26 2016
From: heiko.carstens at de.ibm.com (Heiko Carstens)
Date: Tue, 2 Feb 2016 17:08:26 +0100
Subject: [PATCH 1/5] all: s390: move wrapper infrastructure to generic
 headers
In-Reply-To: <20160202154331.GA3003@yury-N73SV>
References: <1453741047-5498-1-git-send-email-ynorov@caviumnetworks.com>
 <1453741047-5498-2-git-send-email-ynorov@caviumnetworks.com>
 <20160128121618.GB5418@osiris> <20160128163109.GA8529@yury-N73SV>
 <20160201114251.GB973@yury-N73SV> <20160202073913.GB3990@osiris>
 <20160202154331.GA3003@yury-N73SV>
Message-ID: <20160202160826.GF3990@osiris>

On Tue, Feb 02, 2016 at 06:43:31PM +0300, Yury Norov wrote:
> > Well, I'd like to have some proof by the compiler or linker that nothing
> > went wrong. Which seems hard if only selected system call defines will be
> > converted to the new defines.
> > 
> > How can you tell that nothing has been forgotten?
> > 
> > Also, what happens if the prototype of a system call get's changed shortly
> > after it was merged. We might miss such changes and have bugs.
> > 
> 
> As for now, there's no such proof, and everything is OK. Syscall ABI
> is extremely conservative, and Greg KH, and other people spent a lot
> of efforts to keep it that way. This is the only reason for me to not
> worry much about it. Modification of syscall ABI is virtually
> impossible now, because it breaks binary compatibility. Even addition
> of new syscall is very difficult procedure.
> (Documentation/adding-syscalls.txt begins with section "System Call
> Alternatives".)

Well... during the years a lot of system calls have been added. And we've
also seen last-minute changes or reverts. So I don't share your optimistic
view here :)

See e.g. 485d52768685 ("sys_personality: change sys_personality() to accept
"unsigned int" instead of u_long") would have been a candidate which could
silently break architectures which need compat wrappers.

> We can invent some protection, but it will cost us in complexity and/or
> runtime delays. Because syscall ABI is so stable, I think it's OK to
> review wrappers carefully once, and they will be fine for long time.

Here I don't agree with you. These interfaces are so important that I'd
like to have a waterproof method that these don't break.  If this involves
a couple of superfluous instructions then that's what I'm willing to pay
for it.

> > Before doing that I think you should actually revert this patch: my commit
> > 7681df456f97 ("s390/compat: remove superfluous compat wrappers") probably
> > wasn't a very bright idea :)
> This patch is OK for me. pid_t, uid_t, gid_t, unsigned and signed int
> types are all 32-bit both on LP64 and ILP32. Normally, compiler should
> care about top halves... Did I miss something?

The patch was correct when writing it, but e.g. a patch like named above
would introduce a possible bug which would go in unnoticed.
The only thing we save is a _single_ unconditional branch here. I'd say
that's well worth it if you get a (hopefully) always bug free sign and zero
extension infrastructure in return.

> I don't know much about s390 specifics. Maybe because of that I do not
> understand completely your worries. I'm OK with both 1st and 2nd
> version, but I'd choose 2nd one because it allows inlines, and we
> don't need the compat_wrapper.c.

It would be only nicer if we can guarentee correctness all the time. That
being said I'm about to revert my own commit :)

So if you want to go without compat_wrapper.c then we should have a
solution which will do the right thing all the time without that a system
call author has to know about the sign and zero extension issue some
architectures face. It _will_ go wrong.



From stern at rowland.harvard.edu  Tue Feb  2 08:15:55 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 2 Feb 2016 11:15:55 -0500 (EST)
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
Message-ID: <Pine.LNX.4.44L0.1602021112320.1653-100000@iolanthe.rowland.org>

On Tue, 2 Feb 2016, Ulf Hansson wrote:

> On 2 February 2016 at 04:05, Tony Lindgren <tony at atomide.com> wrote:
> > Hi,
> >
> > * Alan Stern <stern at rowland.harvard.edu> [160201 15:50]:
> >>
> >> You get here only if runtime PM is disabled, right?  So the rpm_idle
> >> call won't do anything -- "disabled" means don't make any callbacks.
> >
> > Hmm sorry yes I'm confused again. Yeah it looks like calling rpm_idle
> > just has a side effect that makes a difference here.
> >
> >> Tony, exactly what are you trying to do here?  Do you want this to
> >> invoke a runtime-PM callback in the subsystem, power domain, or driver?
> >> (Is there even a driver bound to the device when this function runs?)
> >
> > I guess I need to add more printks to figure out what's going on here.
> > But yeah, I'm not seeing the callback happening at the interconnect
> > level so hardware and PM runtime states won't match on the following
> > probe after -EPROBE_DEFER.
> >
> >> The function's name suggests that it merely resets the data stored in
> >> dev->power without actually touching the hardware.  Is that what you
> >> really want?
> >
> > I guess you mean pm_runtime_set_suspended() above? I'm seeing a state
> > where we now set pm_runtime_set_suspended() between failed device
> > probes and the device is still active in hardware.
> >
> > The patch below also helps with the problem and leaves out the
> > rpm_suspend() call from loop so it might give more hints.
> >
> > The difference here from what Rafael suggested earlier is calling
> > __pm_runtime_use_autosuspend() and then not calling
> > pm_runtime_set_suspended().
> >
> > However, it seems the below patch keeps hardware active in the
> > autoidle case though, so chances are there is more that needs to
> > be done here. Anyways, I'll try to debug it more tomorrow.
> >
> 
> Your observations is correct. The hardware will be kept active
> in-between the probe attempts (and thus also if probing fails).
> Although, that's not a regression as that's the behaviour you get from
> runtime PM, when drivers are implemented like omap_hsmmc.

Perhaps this is what we should do.  If probing gets deferred a few 
times, doing runtime suspends and resumes in between will be a waste of 
time.

> Instead of the suggested approaches, I think the regression should be
> fixed at the PM domain level (omap hwmod). I have attached a patch
> below, please give it try as it's untested.
> 
> To solve the other problem (allowing devices to become inactive
> in-between at probe failures), I see two options (not treated as
> regressions).
> 1)
> Change the behaviour of pm_runtime_put_sync(), to *not* respect the
> autosuspend mode.
> I think I prefer this option, as it seems like autosuspend should be
> respected only via the asynchronous runtime PM APIs.

?  pm_runtime_put_sync() _already_ does not respect the autosuspend 
mode.  If you want to respect it, you have to call 
pm_runtime_put_sync_autosuspend() instead.

> 2)
> Change the failing drivers, to before calling pm_runtime_put_sync()
> also invoke pm_runtime_dont_use_autosusend(). Or other similar
> approach.

Given the above, this seems unnecessary.

Alan Stern



From marc.zyngier at arm.com  Tue Feb  2 08:19:44 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 2 Feb 2016 16:19:44 +0000
Subject: [PATCH v2 10/21] arm64: KVM: VHE: Split save/restore of sysregs
 shared between EL1 and EL2
In-Reply-To: <20160202154645.GE6190@cbox>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-11-git-send-email-marc.zyngier@arm.com>
 <20160201135438.GL1478@cbox> <56B07ADD.60300@arm.com>
 <20160202154645.GE6190@cbox>
Message-ID: <56B0D720.9000901@arm.com>

On 02/02/16 15:46, Christoffer Dall wrote:
> On Tue, Feb 02, 2016 at 09:46:05AM +0000, Marc Zyngier wrote:
>> On 01/02/16 13:54, Christoffer Dall wrote:
>>> On Mon, Jan 25, 2016 at 03:53:44PM +0000, Marc Zyngier wrote:
>>>> A handful of system registers are still shared between EL1 and EL2,
>>>> even while using VHE. These are tpidr*_el[01], actlr_el1, sp0, elr,
>>>> and spsr.
>>>
>>> So by shared registers you mean registers that do both have an EL0/1
>>> version as well as an EL2 version, but where accesses aren't rewritten
>>> transparently?
>>
>> No, I mean that these registers do *not* have a separate banked version.
>> There is only a single set of registers, which have to be save/restored
>> the old way.
> 
> huh, ARMv8 clearly specifies the existence of TPIDR_EL0, TPIDR_EL1, and
> TPIDR_EL2, for example.
> 
> I cannot seem to find anywhere in the VHE spec that says that the
> TPIDR_EL2 goes away.  I'm confused now.

Nothing goes away, but these registers do not get renamed either. For
example, TPIDR_EL1 doesn't magically access TPIDR_EL2 when running at
EL2+VHE, and there is no TPIDR_EL12 accessor either.

So TPIDR_EL1 is effectively "shared" between host and guest, and must be
save/restored (note that the host kernel still uses TIPDR_EL1 even when
running with VHE, and that KVM still uses TPIDR_EL2 to cache the current
vcpu).

>>
>>>
>>> also, by sp0 do you mean sp_el0, and by elr you mean elr_el1, and by
>>> spsr you mean spsr_el1 ?
>>
>> sp0 -> sp_el0 indeed. elr and spsr really are the guest PC and PSTATE,
>> so I should really reword this commit message, it is utterly confusing.
>>
> I guess I don't understand the definition of a 'shared' register given
> your comments here...

Does this make it clearer?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From mathieu.poirier at linaro.org  Tue Feb  2 08:20:51 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 2 Feb 2016 09:20:51 -0700
Subject: [PATCH V8 23/23] perf tools: adding coresight etm PMU record
 capabilities
In-Reply-To: <CANLsYkxwtqHyoQ7+Z4a+qJfTV_ZWc72_mJh12FHxVEhNYKsgjw@mail.gmail.com>
References: <1452807977-8069-1-git-send-email-mathieu.poirier@linaro.org>
 <1452807977-8069-24-git-send-email-mathieu.poirier@linaro.org>
 <CANLsYkyBCFyu3Q-3jet-6rNfa3vGzWWQ3_m+PNf4Z+n6OxsscA@mail.gmail.com>
 <20160125211048.GE22501@kernel.org> <56AB4027.2070208@intel.com>
 <CANLsYkyFSjLmT_i7ANE2VL21Y+Nud13SvjOd1akV-e9hQcTcHA@mail.gmail.com>
 <20160129211208.GB32225@kernel.org>
 <CANLsYkxwtqHyoQ7+Z4a+qJfTV_ZWc72_mJh12FHxVEhNYKsgjw@mail.gmail.com>
Message-ID: <CANLsYkysvVKoaxKJu9TYLAGJaZj9=9gMN+O6NpcDLztJNrgy+w@mail.gmail.com>

[...]

>>> >
>>> > Looks OK, apart from adding linux/coresight-pmu.h to the manifest, but I
>>> > mentioned that on another patch.
>>> >
>>> > However there is no decoder, which begs the question, is there anything you
>>> > can actually do with the perf.data file?  Might be a bit confusing for users
>>> > if they can capture traces but not use perf tools on the resulting perf.data
>>> > file?
>>>
>>> We are working on a decoding library in parallel to this work.
>>
>> Would be nice to be able to get both in the same patch kit, no? So that
>> one can both record and process the traces, verifying it all works.
>
> We are still a few weeks away from being in a position where the
> community can start playing with the decoding library.  I can hold off
> on the "perf tools" patches when I queue the kernel side of the work
> for 4.6 but since you and Adrian have already reviewed the work it
> would be nice to have that part included as well.
>
> We've been playing with the perf.data files for a couple of months now
> and things look at the right place.  This isn't surprising since we
> are using the same framework as X86.
>
> I think the generation of the perf.data file should be coupled with
> the submission of the kernel driver but would also respect a diverging
> point of view.  Simply let me know what you prefer and I will adjust
> V9 accordingly.

Arnaldo,

I'm preparing V9 at this time - what's your view on the above?

Thanks,
Mathieu


From maxime.ripard at free-electrons.com  Tue Feb  2 08:21:36 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 17:21:36 +0100
Subject: [PATCH 10/11] ARM: dts: sun9i: a80-optimus: Disable dummy
 regulators vcc3v0, vcc3v3, vcc5v0
In-Reply-To: <1454408864-24112-11-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-11-git-send-email-wens@csie.org>
Message-ID: <20160202162136.GX4652@lukather>

Hi,

On Tue, Feb 02, 2016 at 06:27:43PM +0800, Chen-Yu Tsai wrote:
> These 3 regulators are provided in sunxi-common-regulators.dtsi.
> 3.0V/3.3V and 5.0V are commonly used voltages in Allwinner devices.
> These dummy regulators provide a stand-in when bindings that require
> one, but the real regulator is not supported yet.
> 
> Since these are no longer needed, we can disable them.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>

Why not remove the include entirely then?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/9e51616f/attachment.sig>

From djkurtz at chromium.org  Tue Feb  2 08:21:54 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Wed, 3 Feb 2016 00:21:54 +0800
Subject: [RFC 3/3] CMDQ: Mediatek CMDQ driver
In-Reply-To: <1454395681.27603.13.camel@mtksdaap41>
References: <1453266881-16849-1-git-send-email-hs.liao@mediatek.com>
 <1453266881-16849-4-git-send-email-hs.liao@mediatek.com>
 <CAGS+omBjD1pXKY_6bFbiGxa5bttvqg5zEvKevzSfoiMOy7ys6Q@mail.gmail.com>
 <1454053150.32413.52.camel@mtksdaap41>
 <CAGS+omBrEE21Xxh8hjcf32qfHJE0jJYvxGP6L1ihS6jcNbLvLQ@mail.gmail.com>
 <1454070262.7401.21.camel@mtksdaap41>
 <CAGS+omBhs7Ks7MVDsxHBBUdgF+0fmAa465HwvNiCzEe97Knt3Q@mail.gmail.com>
 <1454292257.22270.3.camel@mtksdaap41>
 <CAGS+omCzDisk2TfbDnWiXufWgUsCbhF_JFafaUazhSymX-MT_Q@mail.gmail.com>
 <1454307624.22441.18.camel@mtksdaap41>
 <CAGS+omB7d3Kq1DKNHxZJjLDmin0rpkDj1kEde3zCxTiT5-xZWw@mail.gmail.com>
 <1454395681.27603.13.camel@mtksdaap41>
Message-ID: <CAGS+omB=Pe9s=hoBLmPBiQXJ7mkQZX-+pzum0hasmf5Kki3iOQ@mail.gmail.com>

On Tue, Feb 2, 2016 at 2:48 PM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
> On Mon, 2016-02-01 at 18:22 +0800, Daniel Kurtz wrote:
>> On Mon, Feb 1, 2016 at 2:20 PM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
>> > On Mon, 2016-02-01 at 12:15 +0800, Daniel Kurtz wrote:
>> >> On Mon, Feb 1, 2016 at 10:04 AM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
>> >> >
>> >> > On Fri, 2016-01-29 at 21:15 +0800, Daniel Kurtz wrote:
>> >> > > On Fri, Jan 29, 2016 at 8:24 PM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
>> >> > > > On Fri, 2016-01-29 at 16:42 +0800, Daniel Kurtz wrote:
>> >> > > >> On Fri, Jan 29, 2016 at 3:39 PM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
>> >> > > >> > Hi Dan,
>> >> > > >> >
>> >> > > >> > Many thanks for your comments and time.
>> >> > > >> > I reply my plan inline.
>> >> > > >> >
>> >> > > >> >
>> >> > > >> > On Thu, 2016-01-28 at 12:49 +0800, Daniel Kurtz wrote:
>> >> > > >> >> Hi HS,
>> >> > > >> >>
>> >> > > >> >> Sorry for the delay.  It is hard to find time to review a >3700 line
>> >> > > >> >> driver :-o in detail....
>> >> > > >> >>
>> >> > > >> >> Some review comments inline, although I still do not completely
>> >> > > >> >> understand how all that this driver does and how it works.
>> >> > > >> >> I'll try to find time to go through this driver in detail again next
>> >> > > >> >> time you post it for review.
>> >> > > >> >>
>> >> > > >> >> On Tue, Jan 19, 2016 at 9:14 PM,  <hs.liao at mediatek.com> wrote:
>> >> > > >> >> > From: HS Liao <hs.liao at mediatek.com>
>> >> > > >> >> >
>> >> > > >> >> > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
>> >> > > >> >> > CMDQ is used to help read/write registers with critical time limitation,
>> >> > > >> >> > such as updating display configuration during the vblank. It controls
>> >> > > >> >> > Global Command Engine (GCE) hardware to achieve this requirement.
>> >> > > >> >> > Currently, CMDQ only supports display related hardwares, but we expect
>> >> > > >> >> > it can be extended to other hardwares for future requirements.
>> >> > > >> >> >
>> >> > > >> >> > Signed-off-by: HS Liao <hs.liao at mediatek.com>
>> >> > > >> >>
>> >> > > >> >> [snip]
>> >> > > >> >>
>> >> > > >> >> > diff --git a/drivers/soc/mediatek/mtk-cmdq.c b/drivers/soc/mediatek/mtk-cmdq.c
>> >> > > >> >> > new file mode 100644
>> >> > > >> >> > index 0000000..7570f00
>> >> > > >> >> > --- /dev/null
>> >> > > >> >> > +++ b/drivers/soc/mediatek/mtk-cmdq.c
>> >> > > >
>> >> > > > [snip]
>> >> > > >
>> >> > > >> >> > +static const struct cmdq_subsys g_subsys[] = {
>> >> > > >> >> > +       {0x1400, 1, "MMSYS"},
>> >> > > >> >> > +       {0x1401, 2, "DISP"},
>> >> > > >> >> > +       {0x1402, 3, "DISP"},
>> >> > > >> >>
>> >> > > >> >> This isn't going to scale.  These addresses could be different on
>> >> > > >> >> different chips.
>> >> > > >> >> Instead of a static table like this, we probably need specify to the
>> >> > > >> >> connection between gce and other devices via devicetree phandles, and
>> >> > > >> >> then use the phandles to lookup the corresponding device address
>> >> > > >> >> range.
>> >> > > >> >
>> >> > > >> > I will define them in device tree.
>> >> > > >> > E.g.
>> >> > > >> > cmdq {
>> >> > > >> >   reg_domain = 0x14000000, 0x14010000, 0x14020000
>> >> > > >> > }
>> >> > > >>
>> >> > > >> The devicetree should only model hardware relationships, not software
>> >> > > >> considerations.
>> >> > > >>
>> >> > > >> Is the hardware constraint here for using gce with various other
>> >> > > >> hardware blocks?  I think we already model this by only providing a
>> >> > > >> gce phandle in the device tree nodes for those devices that can use
>> >> > > >> gce.
>> >> > > >>
>> >> > > >> Looking at the driver closer, as far as I can tell, the whole subsys
>> >> > > >> concept is a purely software abstraction, and only used to debug the
>> >> > > >> CMDQ_CODE_WRITE command.  In fact, AFAICT, everything would work fine
>> >> > > >> if we just completely removed the 'subsys' concept, and just passed
>> >> > > >> through the raw address provided by the driver.
>> >> > > >>
>> >> > > >> So, I recommend just removing 'subsys' completely from the driver -
>> >> > > >> from this array, and in the masks.
>> >> > > >>
>> >> > > >> Instead, if there is an error on the write command, just print the
>> >> > > >> address that fails.  There are other ways to deduce the subsystem from
>> >> > > >> a physical address.
>> >> > > >>
>> >> > > >> Thanks,
>> >> > > >>
>> >> > > >> -Dan
>> >> > > >
>> >> > > > Hi Dan,
>> >> > > >
>> >> > > > Subsys is not just for debug.
>> >> > > > Its main purpose is to transfer CPU address to GCE address.
>> >> > > > Let me explain it by "write" op,
>> >> > > > I list a code segment from cmdq_rec_append_command().
>> >> > > >
>> >> > > >         case CMDQ_CODE_WRITE:
>> >> > > >                 subsys = cmdq_subsys_from_phys_addr(cqctx, arg_a);
>> >> > > >                 if (subsys < 0) {
>> >> > > >                         dev_err(dev,
>> >> > > >                                 "unsupported memory base address 0x%08x\n",
>> >> > > >                                 arg_a);
>> >> > > >                         return -EFAULT;
>> >> > > >                 }
>> >> > > >
>> >> > > >                 *cmd_ptr++ = arg_b;
>> >> > > >                 *cmd_ptr++ = (CMDQ_CODE_WRITE << CMDQ_OP_CODE_SHIFT) |
>> >> > > >                              (arg_a & CMDQ_ARG_A_WRITE_MASK) |
>> >> > > >                              ((subsys & CMDQ_SUBSYS_MASK) << CMDQ_SUBSYS_SHIFT);
>> >> > > >                 break;
>> >> > > >
>> >> > > > Subsys is mapped from physical address via cmdq_subsys_from_phys_addr(),
>> >> > > > and then it becomes part of GCE command via ((subsys & CMDQ_SUBSYS_MASK)
>> >> > > > << CMDQ_SUBSYS_SHIFT) .
>> >> > > > Only low bits of physical address are the same as GCE address.
>> >> > > > We can get it by (arg_a & CMDQ_ARG_A_WRITE_MASK).
>> >> > > > MASK is used to define how many bits are valid for this op.
>> >> > > > So, GCE address = subsys + valid low bits.
>> >> > >
>> >> > > How are these upper bits of the "GCE address" defined?
>> >> > > In other words, for a given SoC, how is the mapping between physical
>> >> > > io addresses to GCE addresses defined?
>> >> > > Is this mapping fixed by hardware?
>> >>
>> >> Please answer the detailed technical questions:
>> >>
>> >> How are these upper bits of the "GCE address" defined?
>> >
>> > A GCE command is arg_a + arg_b. Both of them have 32 bits length.
>> > arg_a is op + subsys + addr, and arg_b is value.
>> > subsys + addr is less than 32bits, so we need to map address range to
>> > subsys.
>> > The mapping rule is defined by hardware.
>> >
>> >> In other words, for a given SoC, how is the mapping between physical
>> >> io addresses to GCE addresses defined?
>> >
>> > It is (b).
>> >
>> >>
>> >> (a) Does the GCE remap a continuous device IO address range?
>> >>
>> >> AFAICT, the  defines an MT8173 specific mapping of:
>> >>
>> >> For example, the g_subsys table above seems to imply that the MT8173
>> >> gce maps all of:
>> >>   0x1400ffff:0x141fffff => 0x010000:0x1fffff
>> >>
>> >> (b) Or, are the upper 5 bits of the "gce address" significant, and via
>> >> hardware it can map a disjoint groups of device addresses into the
>> >> continuous GCE address space, and really there are 0x1f distinct 64k
>> >> mappings:
>> >>
>> >> mmsys (1) : 0x14000000:0x1400ffff => 0x010000:0x01ffff
>> >> disp  (2) : 0x14010000:0x1401ffff => 0x020000:0x02ffff
>> >> disp  (3) : 0x14020000:0x1402ffff => 0x030000:0x03ffff
>> >> ...
>> >> ???? (1f) : 0x141fffff:0x141fffff => 0x1f0000:0x1fffff
>> >>
>> >> If the mapping is fixed and continuous (a), then I think all we need
>> >> is a single dts entry for the gce node that describes how it performs
>> >> this mapping.  And then, the gce consumers can just pass in their
>> >> regular physical addresses, and the gce driver can remap them directly
>> >> to gce addresses.
>> >>
>> >> WDYT?
>> >
>> > How about this?
>> > hardware_module = <address_base subsys_id mask>;
>> > So, the result is
>> > mmsys_config_base = <0x14000000 1 0xffff0000>;
>> > disp_rdma_config_base = <0x14010000 2 0xffff0000>;
>> > disp_mutex_config_base = <0x14020000 3 0xffff0000>;
>>
>> What uses ID 0 and 4 - 0x1f?
>
> Subsys is defined by GCE hardware, and other IDs are reserved currently.
>
>> According to mt8173.dtsi, here are the blocks in the address ranges above:
>>
>> @1400:
>>   mmsys: clock-controller at 14000000
>>   ovl0: ovl at 1400c000
>>   ovl1: ovl at 1400d000
>>   rdma0: rdma at 1400e000
>>   rdma1: rdma at 1400f000
>>
>> @1401:
>>   rdma2: rdma at 14010000
>>   wdma0: wdma at 14011000
>>   wdma1: wdma at 14012000
>>   color0: color at 14013000
>>   color1: color at 14014000
>>   aal at 14015000
>>   gamma at 14016000
>>   merge at 14017000
>>   split0: split at 14018000
>>   split1: split at 14019000
>>   ufoe at 1401a000
>>   dsi0: dsi at 1401b000
>>   dsi1: dsi at 1401c000
>>   dpi0: dpi at 1401d000
>>   pwm0: pwm at 1401e000
>>   pwm1: pwm at 1401f000
>>
>> @1402:
>>   mutex: mutex at 14020000
>>   od at 14023000
>>   larb0: larb at 14021000
>>   smi_common: smi at 14022000
>>   hdmi0: hdmi at 14025000
>>   larb4: larb at 14027000
>>
>> I assume that the gce will work with any of the devices in those
>> ranges, not just "mmsys", "rdma" and "mutex", right?   (Also, notice
>
> That's right.
>
>> there are two "rdma" in the @1400 range, so rdma is really not a good
>> name for @1401)
>
> I think we can just use index.
> disp0_config_base = <0x14000000 1 0xffff0000>;
> disp1_config_base = <0x14010000 2 0xffff0000>;
> disp2_config_base = <0x14020000 3 0xffff0000>;
>
>> Further, it looks like the gce just maps a large device address range
>> starting at 0x14000000 to (21-bit) gce address 0x010000, rather than
>> 31 individually addressable 64k "subsys" blocks.  Is there a counter
>> example that I am missing?
>
> From GCE's point of view,
> it's 32 (0x0~0x1f) individually addressable 64k "subsys" blocks.
> Currently, we don't have a counter example since all display related
> address are put together.

Ok, in this case, perhaps we should treat the GCE like an IOMMU, and
have its binding define 32 slots or channels.
Then, any device that wishes to send the GCE commands for its address
range should register a phandle to the gce, including the
corresponding slot.

For example:

include/.../gce.h
include/dt-bindings/../mediatek-gce.h
#define GCE_SLOT_1  1
...

arch/arm64/boot/dts/mediatek/mt8173.dtsi:

&ovl0: {
  mediatek,gce = <&gce GCE_SLOT_1>;
};

&ovl1: {
  mediatek,gce = <&gce GCE_SLOT_1>;
};

&rdma2: {
  mediatek,gce = <&gce GCE_SLOT_2>;
};

&mutex: {
  mediatek,gce = <&gce GCE_SLOT_3>;
};

&od: {
  mediatek,gce = <&gce GCE_SLOT_3>;
};

Then, as each platform driver is probed, it can use the phandle to
look up its corresponding gce slot instance, retrieving an (opaque)
pointer to a struct gce_slot.
The gce driver can have a set of constant tables matching the slots to
address ranges for particular per-soc compatibles, one of which is
loaded on probe.
Later, when the device (gce consumer) wants to send a gce write
command, it passes in the gce_slot as an argument, and the gce driver
can do the corresponding lookup of subsys value and mask out the
provided *device virtual* address.  In this way, you also no longer
need to convert the devices iomap'ed addresses into physical addresses
before passing them to the gce.

WDYT?

-Dan


From thierry.reding at gmail.com  Tue Feb  2 08:23:30 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 2 Feb 2016 17:23:30 +0100
Subject: [PATCH 4/4] pwm: omap-dmtimer: add dev_dbg() message for
 effective period and duty cycle
In-Reply-To: <20160201185952.GN19432@atomide.com>
References: <1454128014-22866-1-git-send-email-drivshin.allworx@gmail.com>
 <1454128014-22866-5-git-send-email-drivshin.allworx@gmail.com>
 <CAA3gFWvSsctXtds6_SEtYY1yUdWJDR1XjznGS6qjdrGW5Dbw=A@mail.gmail.com>
 <20160201132228.2634b72e.drivshin.allworx@gmail.com>
 <20160201185952.GN19432@atomide.com>
Message-ID: <20160202162330.GA4918@ulmo>

On Mon, Feb 01, 2016 at 10:59:52AM -0800, Tony Lindgren wrote:
> Hi,
> 
> * David Rivshin (Allworx) <drivshin.allworx at gmail.com> [160201 10:23]:
> > On Sat, 30 Jan 2016 15:51:06 +0100
> > Neil Armstrong <narmstrong at baylibre.com> wrote:
> > 
> > > 2016-01-30 5:26 GMT+01:00 David Rivshin (Allworx)
> > > <drivshin.allworx at gmail.com>:
> > > > From: David Rivshin <drivshin at allworx.com>
> > > >
> > > > After going through the math and constraints checking to compute
> > > > load and match values, it is helpful to know what the resultant
> > > > period and duty cycle are.
> > > >
> > > > Signed-off-by: David Rivshin <drivshin at allworx.com>
> > > > ---
> > > >
> > > > I found this helpful while testing the other changes, so I included
> > > > it in case it may be of use to someone in the future. I would have
> > > > no issues with dropping this if it's not considered worthwhile.  
> > > 
> > > It's useful, but converting it as a sysfs attribute would be great !
> > 
> > Hrm, yes that is an interesting thought. I imagine that many PWM 
> > devices have similar constraints, so perhaps that would be best 
> > handled generically in the pwm core? Maybe as new optional get_*() 
> > ops, a modification to the config() op to add output params, or just 
> > updating new fields in the struct pwm directly?
> 
> Yeah for /sys entry it should be Linux generic. The other option
> is to use debugfs for driver specific things.

Let's go with debugfs for this one. This is used for diagnostic purposes
and not typically needed when configuring a PWM. While other drivers may
compute similar hardware-specific values, there's nothing generic to
them. The period and duty cycle are the generic input values and those
are already exposed via sysfs.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/9e212df5/attachment.sig>

From stern at rowland.harvard.edu  Tue Feb  2 08:23:48 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 2 Feb 2016 11:23:48 -0500 (EST)
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>
Message-ID: <Pine.LNX.4.44L0.1602021116510.1653-100000@iolanthe.rowland.org>

On Tue, 2 Feb 2016, Ulf Hansson wrote:

> That's not what we want. So I moved the checks to the actual
> ->runtime_resume() callback in the PM domain, instead of in the
> omap_device_enable() function. A version 2 is attached. Please give it
> at try.
> 
> [...]
> 
> From: Ulf Hansson <ulf.hansson at linaro.org>
> Date: Tue, 2 Feb 2016 10:05:39 +0100
> Subject: [PATCH V2] ARM: OMAP2+: omap-device: Allow devices to be pre-enabled
> 
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") may re-initialize the runtime PM status of the
> device to RPM_SUSPENDED at driver probe failures.
> 
> For the omap_hsmmc and likely also other omap drivers, which needs more
> than one attempt to ->probe() (returning -EPROBE_DEFER), this commit
> causes a regression at the PM domain level (omap hwmod).
> 
> The reason is that the drivers don't put back the device into low power
> state while bailing out in ->probe to return -EPROBE_DEFER. This leads to
> that pm_runtime_reinit() in driver core, is re-initializing the runtime PM
> status from RPM_ACTIVE to RPM_SUSPENDED.

But isn't that okay?  When the system starts up, the PM core doesn't 
know the actual state of any device.  It just marks each device as 
RPM_SUSPENDED and disabled as it is registered.  It's the job of 
subsystems and drivers to make sure the stored state agrees with the 
actual physical state.

So why shouldn't pm_runtime_reinit() leave the structure the same as it 
would be if the device had just been registered?

> The next ->probe() attempt then triggers the ->runtime_resume() callback
> to be invoked, which means this happens two times in a row. At the PM
> domain level (omap hwmod) this is being treated as an error and thus the
> runtime PM status of the device isn't correctly synchronized with the
> runtime PM core.

Why doesn't the same problem arise the first time the device is probed?  
Or to put it another, why should a re-probe be any different from the 
initial probe?

> In the end, ->probe() anyway succeeds (as the driver don't checks the
> error code from the runtime PM APIs), but results in that the PM domain
> always stays powered on. This because of the runtime PM core believes the
> device is RPM_SUSPENDED.
> 
> Fix this regression by allowing devices to be pre-enabled when the PM
> domain's (omap hwmod) ->runtime_resume() callback is requested to enable
> the device. In such cases, return zero to synchronize the runtime PM
> status with the runtime PM core.

Is this really the right way to fix the problem?

Alan Stern



From jenskuske at gmail.com  Tue Feb  2 08:24:30 2016
From: jenskuske at gmail.com (Jens Kuske)
Date: Tue, 2 Feb 2016 17:24:30 +0100
Subject: [linux-sunxi] [PATCH 10/11] arm64: dts: add Allwinner A64 SoC
 .dtsi
In-Reply-To: <1454348370-3816-11-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-11-git-send-email-andre.przywara@arm.com>
Message-ID: <56B0D83E.5090604@gmail.com>

Hi,

On 01/02/16 18:39, Andre Przywara wrote:
> The Allwinner A64 SoC is low-cost SoC with 4 ARM Cortex-A53 cores
> and the typical tablet / TV box peripherals.
> The Soc is based on the (32-bit) Allwinner H3 chip, sharing most of
> the peripherals and the memory map.
> Although the cores are proper 64-bit ones, the whole SoC is actually
> limited to 4GB (including all the supported DRAM), so we use 32-bit
> address and size cells. This has the nice feature of us being able to
> reuse the DT for 32-bit kernels as well.
> This .dtsi lists the hardware that we support so far.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  Documentation/devicetree/bindings/arm/sunxi.txt   |   1 +
>  Documentation/devicetree/bindings/clock/sunxi.txt |   1 +
>  arch/arm64/boot/dts/allwinner/a64.dtsi            | 583 ++++++++++++++++++++++
>  3 files changed, 585 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/a64.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
> index 980e065..4a83853 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -14,6 +14,7 @@ using one of the following compatible strings:
>    allwinner,sun8i-a83t
>    allwinner,sun8i-h3
>    allwinner,sun9i-a80
> +  allwinner,a64
>  
>  For Allwinner SoCs without any specific needs the generic fallback value of:
>    allwinner,sunxi
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index e59f57b..44b0c6c 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -77,6 +77,7 @@ Required properties:
>  	"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
>  	"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
>  	"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
> +	"allwinner,a64-bus-gates-clk" - for the A64 multi-parent bus gates clock
>  
>  Required properties for all clocks:
>  - reg : shall be the control register address for the clock.
> diff --git a/arch/arm64/boot/dts/allwinner/a64.dtsi b/arch/arm64/boot/dts/allwinner/a64.dtsi
> new file mode 100644
> index 0000000..8dce10f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/a64.dtsi
> @@ -0,0 +1,583 @@
> +/*
> + * Copyright (C) 2016 ARM Ltd.
> + * based on the Allwinner H3 dtsi:
> + *    Copyright (C) 2015 Jens Kuske <jenskuske at gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This file is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +
> +/ {
> +	compatible = "allwinner,a64", "allwinner,sunxi";
> +	interrupt-parent = <&gic>;
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +
> +	aliases {
> +		serial0 = &uart0;
> +		serial1 = &uart1;
> +		serial2 = &uart2;
> +		serial3 = &uart3;
> +		serial4 = &uart4;
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu at 0 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <0>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu at 1 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <1>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu at 2 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <2>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu at 3 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <3>;
> +			enable-method = "psci";
> +		};
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-0.2", "arm,psci";
> +		method = "smc";
> +		cpu_suspend = <0xc4000001>;
> +		cpu_off = <0x84000002>;
> +		cpu_on = <0xc4000003>;
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x40000000 0>;
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts = <GIC_PPI 13
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 14
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 11
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 10
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> +	};
> +
> +	clocks {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		osc24M: osc24M_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-clock";
> +			clock-frequency = <24000000>;
> +			clock-output-names = "osc24M";
> +		};
> +
> +		osc32k: osc32k_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-clock";
> +			clock-frequency = <32768>;
> +			clock-output-names = "osc32k";
> +		};
> +
> +		pll1: clk at 01c20000 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun8i-a23-pll1-clk";
> +			reg = <0x01c20000 0x4>;
> +			clocks = <&osc24M>;
> +			clock-output-names = "pll1";
> +		};
> +
> +		pll6: clk at 01c20028 {
> +			#clock-cells = <1>;
> +			compatible = "allwinner,sun6i-a31-pll6-clk";
> +			reg = <0x01c20028 0x4>;
> +			clocks = <&osc24M>;
> +			clock-output-names = "pll6", "pll6x2";
> +		};
> +
> +		pll6d2: pll6d2_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-factor-clock";
> +			clock-div = <2>;
> +			clock-mult = <1>;
> +			clocks = <&pll6 0>;
> +			clock-output-names = "pll6d2";
> +		};
> +
> +		/* dummy clock until pll6 can be reused */
> +		pll8: pll8_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-clock";
> +			clock-frequency = <1>;
> +			clock-output-names = "pll8";
> +		};
> +
> +		cpu: cpu_clk at 01c20050 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-a10-cpu-clk";
> +			reg = <0x01c20050 0x4>;
> +			clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
> +			clock-output-names = "cpu";
> +			critical-clocks = <0>;
> +		};
> +
> +		axi: axi_clk at 01c20050 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-a10-axi-clk";
> +			reg = <0x01c20050 0x4>;
> +			clocks = <&cpu>;
> +			clock-output-names = "axi";
> +		};
> +
> +		ahb1: ahb1_clk at 01c20054 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun6i-a31-ahb1-clk";
> +			reg = <0x01c20054 0x4>;
> +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
> +			clock-output-names = "ahb1";
> +		};
> +
> +		ahb2: ahb2_clk at 01c2005c {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun8i-h3-ahb2-clk";
> +			reg = <0x01c2005c 0x4>;
> +			clocks = <&ahb1>, <&pll6d2>;
> +			clock-output-names = "ahb2";
> +		};
> +
> +		apb1: apb1_clk at 01c20054 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-a10-apb0-clk";
> +			reg = <0x01c20054 0x4>;
> +			clocks = <&ahb1>;
> +			clock-output-names = "apb1";
> +		};
> +
> +		apb2: apb2_clk at 01c20058 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-a10-apb1-clk";
> +			reg = <0x01c20058 0x4>;
> +			clocks = <&osc32k>, <&osc24M>, <&pll6 1>, <&pll6 1>;
> +			clock-output-names = "apb2";
> +		};
> +
> +		bus_gates: clk at 01c20060 {
> +			#clock-cells = <1>;
> +			compatible = "allwinner,a64-bus-gates-clk",
> +				     "allwinner,sunxi-multi-bus-gates-clk";
> +			reg = <0x01c20060 0x14>;
> +			ahb1_parent {
> +				clocks = <&ahb1>;
> +				clock-indices = <1>, <5>,
> +						<6>, <8>,
> +						<9>, <10>,
> +						<13>, <14>,
> +						<18>, <19>,
> +						<20>, <21>,
> +						<23>, <24>,
> +						<25>, <28>,
> +						<32>, <35>,
> +						<36>, <37>,
> +						<40>, <43>,
> +						<44>, <52>,
> +						<53>, <54>,
> +						<135>;
> +				clock-output-names = "bus_mipidsi", "bus_ce",
> +						"bus_dma", "bus_mmc0",
> +						"bus_mmc1", "bus_mmc2",
> +						"bus_nand", "bus_sdram",
> +						"bus_ts", "bus_hstimer",
> +						"bus_spi0", "bus_spi1",
> +						"bus_otg", "bus_otg_ehci0",
> +						"bus_ehci0", "bus_otg_ohci0",
> +						"bus_ve", "bus_lcd0",
> +						"bus_lcd1", "bus_deint",
> +						"bus_csi", "bus_hdmi",
> +						"bus_de", "bus_gpu",
> +						"bus_msgbox", "bus_spinlock",
> +						"bus_dbg";
> +			};
> +			ahb2_parent {
> +				clocks = <&ahb2>;
> +				clock-indices = <17>, <29>;
> +				clock-output-names = "bus_gmac", "bus_ohci0";
> +			};
> +			apb1_parent {
> +				clocks = <&apb1>;
> +				clock-indices = <64>, <65>,
> +						<69>, <72>,
> +						<76>, <77>,
> +						<78>;
> +				clock-output-names = "bus_codec", "bus_spdif",
> +						"bus_pio", "bus_ths",
> +						"bus_i2s0", "bus_i2s1",
> +						"bus_i2s2";
> +			};
> +			abp2_parent {
> +				clocks = <&apb2>;
> +				clock-indices = <96>, <97>,
> +						<98>, <101>,
> +						<112>, <113>,
> +						<114>, <115>,
> +						<116>;
> +				clock-output-names = "bus_i2c0", "bus_i2c1",
> +						"bus_i2c2", "bus_scr",
> +						"bus_uart0", "bus_uart1",
> +						"bus_uart2", "bus_uart3",
> +						"bus_uart4";
> +			};
> +		};
> +
> +		mmc0_clk: clk at 01c20088 {
> +			#clock-cells = <1>;
> +			compatible = "allwinner,sun4i-a10-mmc-clk";

The A64 MMC clocks don't seem to be fully compatible to A10. The output
and sample phase control has been moved to the MMC module itself.
The dividers are the same, but the additional special "outputs" are gone.

> +			reg = <0x01c20088 0x4>;
> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;

Parents are PLL6(2x) and PLL8(2x) according to manual.

> +			clock-output-names = "mmc0",
> +					     "mmc0_output",
> +					     "mmc0_sample";
> +		};
> +
> +		mmc1_clk: clk at 01c2008c {
> +			#clock-cells = <1>;
> +			compatible = "allwinner,sun4i-a10-mmc-clk";
> +			reg = <0x01c2008c 0x4>;
> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
> +			clock-output-names = "mmc1",
> +					     "mmc1_output",
> +					     "mmc1_sample";
> +		};
> +
> +		mmc2_clk: clk at 01c20090 {
> +			#clock-cells = <1>;
> +			compatible = "allwinner,sun4i-a10-mmc-clk";
> +			reg = <0x01c20090 0x4>;
> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
> +			clock-output-names = "mmc2",
> +					     "mmc2_output",
> +					     "mmc2_sample";
> +		};
> +	};
> +
> +	regulators {
> +		reg_vcc3v3: vcc3v3 {
> +			compatible = "regulator-fixed";
> +			regulator-name = "vcc3v3";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +		};
> +	};
> +
> +	soc {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		mmc0: mmc at 01c0f000 {
> +			compatible = "allwinner,sun5i-a13-mmc";
> +			reg = <0x01c0f000 0x1000>;
> +			clocks = <&bus_gates 8>,
> +				 <&mmc0_clk 0>,

Consequently, the MMC driver now has to control the output/sample phase
with registers 0x140-0x148 instead of
> +				 <&mmc0_clk 1>,
> +				 <&mmc0_clk 2>;

And there seems to be some new clock divider somewhere which I haven't
found in the manual yet. The clock measured at the CLK pin is always
half the expected rate (even with 24MHz as MMC clock parent, so no
PLL6*2 problem).

> +			clock-names = "ahb",
> +				      "mmc",
> +				      "output",
> +				      "sample";
> +			resets = <&ahb_rst 8>;
> +			reset-names = "ahb";
> +			interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		mmc1: mmc at 01c10000 {
> +			compatible = "allwinner,sun5i-a13-mmc";
> +			reg = <0x01c10000 0x1000>;
> +			clocks = <&bus_gates 9>,
> +				 <&mmc1_clk 0>,
> +				 <&mmc1_clk 1>,
> +				 <&mmc1_clk 2>;
> +			clock-names = "ahb",
> +				      "mmc",
> +				      "output",
> +				      "sample";
> +			resets = <&ahb_rst 9>;
> +			reset-names = "ahb";
> +			interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		mmc2: mmc at 01c11000 {
> +			compatible = "allwinner,sun5i-a13-mmc";
> +			reg = <0x01c11000 0x1000>;
> +			clocks = <&bus_gates 10>,
> +				 <&mmc2_clk 0>,
> +				 <&mmc2_clk 1>,
> +				 <&mmc2_clk 2>;
> +			clock-names = "ahb",
> +				      "mmc",
> +				      "output",
> +				      "sample";
> +			resets = <&ahb_rst 10>;
> +			reset-names = "ahb";
> +			interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		pio: pinctrl at 01c20800 {
> +			compatible = "allwinner,a64-pinctrl";
> +			reg = <0x01c20800 0x400>;
> +			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&bus_gates 69>;
> +			gpio-controller;
> +			#gpio-cells = <3>;
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +
> +			uart0_pins_a: uart0 at 0 {
> +				allwinner,pins = "PB8", "PB9";
> +				allwinner,function = "uart0";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart0_pins_b: uart0 at 1 {
> +				allwinner,pins = "PF2", "PF3";
> +				allwinner,function = "uart0";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart1_pins: uart1 at 0 {
> +				allwinner,pins = "PG6", "PG7", "PG8", "PG9";
> +				allwinner,function = "uart1";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart2_pins: uart2 at 0 {
> +				allwinner,pins = "PB0", "PB1", "PB2", "PB3";
> +				allwinner,function = "uart2";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart3_pins_a: uart3 at 0 {
> +				allwinner,pins = "PD0", "PD1";
> +				allwinner,function = "uart3";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart3_pins_b: uart3 at 1 {
> +				allwinner,pins = "PH4", "PH5", "PH6", "PH7";
> +				allwinner,function = "uart3";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart4_pins: uart4 at 0 {
> +				allwinner,pins = "PD2", "PD3", "PD4", "PD5";
> +				allwinner,function = "uart4";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			mmc0_pins: mmc0 at 0 {
> +				allwinner,pins = "PF0", "PF1", "PF2", "PF3",
> +						 "PF4", "PF5";
> +				allwinner,function = "mmc0";
> +				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			mmc0_default_cd_pin: mmc0_cd_pin at 0 {
> +				allwinner,pins = "PF6";
> +				allwinner,function = "gpio_in";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> +			};
> +
> +			mmc1_pins: mmc1 at 0 {
> +				allwinner,pins = "PG0", "PG1", "PG2", "PG3",
> +						 "PG4", "PG5";
> +				allwinner,function = "mmc1";
> +				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			mmc2_pins: mmc2 at 0 {
> +				allwinner,pins = "PC1", "PC5", "PC6", "PC8",
> +						 "PC9", "PC10";
> +				allwinner,function = "mmc2";
> +				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +		};
> +
> +		ahb_rst: reset at 01c202c0 {
> +			#reset-cells = <1>;
> +			compatible = "allwinner,sun6i-a31-ahb1-reset";
> +			reg = <0x01c202c0 0xc>;
> +		};
> +
> +		apb1_rst: reset at 01c202d0 {
> +			#reset-cells = <1>;
> +			compatible = "allwinner,sun6i-a31-clock-reset";
> +			reg = <0x01c202d0 0x4>;
> +		};
> +
> +		apb2_rst: reset at 01c202d8 {
> +			#reset-cells = <1>;
> +			compatible = "allwinner,sun6i-a31-clock-reset";
> +			reg = <0x01c202d8 0x4>;
> +		};
> +
> +		uart0: serial at 01c28000 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x01c28000 0x400>;
> +			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clocks = <&bus_gates 112>;
> +			resets = <&apb2_rst 16>;
> +			reset-names = "apb2";

Do we need reset-names here (and below)?

> +			status = "disabled";
> +		};
> +
> +		uart1: serial at 01c28400 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x01c28400 0x400>;
> +			interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clocks = <&bus_gates 113>;
> +			resets = <&apb2_rst 17>;
> +			reset-names = "apb2";
> +			status = "disabled";
> +		};
> +
> +		uart2: serial at 01c28800 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x01c28800 0x400>;
> +			interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clocks = <&bus_gates 114>;
> +			resets = <&apb2_rst 18>;
> +			reset-names = "apb2";
> +			status = "disabled";
> +		};
> +
> +		uart3: serial at 01c28c00 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x01c28c00 0x400>;
> +			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clocks = <&bus_gates 115>;
> +			resets = <&apb2_rst 19>;
> +			reset-names = "apb2";
> +			status = "disabled";
> +		};
> +
> +		uart4: serial at 01c29000 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x01c29000 0x400>;
> +			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clocks = <&bus_gates 116>;
> +			resets = <&apb2_rst 20>;
> +			reset-names = "apb2";
> +			status = "disabled";
> +		};
> +
> +		rtc: rtc at 01f00000 {
> +			compatible = "allwinner,sun6i-a31-rtc";
> +			reg = <0x01f00000 0x54>;
> +			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
> +		};
> +	};
> +
> +	gic: interrupt-controller@{
> +		compatible = "arm,gic-400";
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +		#address-cells = <0>;
> +
> +		reg = <0x01C81000 0x1000>,
> +		      <0x01C82000 0x2000>,
> +		      <0x01C84000 0x2000>,
> +		      <0x01C86000 0x2000>;

Maybe lowercase hex here too.

> +		interrupts = <GIC_PPI 9
> +		      (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> +	};
> +};
> 

Regards,
Jens


From thierry.reding at gmail.com  Tue Feb  2 08:28:33 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 2 Feb 2016 17:28:33 +0100
Subject: [PATCH 2/2] dt-bindings: Add TPO TPG110 binding
In-Reply-To: <1454316643-3931-1-git-send-email-linus.walleij@linaro.org>
References: <1454316643-3931-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <20160202162833.GB4918@ulmo>

On Mon, Feb 01, 2016 at 09:50:43AM +0100, Linus Walleij wrote:
> This adds device tree bindings for the TPO TPG110 panel found
> mounted in the Nomadik NHK8815.
> 
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
>  .../bindings/display/panel/tpo,tpg110.txt          | 47 ++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
> new file mode 100644
> index 000000000000..acbc6bef3593
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
> @@ -0,0 +1,47 @@
> +TPO TPG110 Panel
> +================
> +
> +This binding builds on the DPI bindings, adding a few properties
> +as a superset of a DPI. See panel-dpi.txt for the required DPI
> +bindings.

It is unfortunate that we have these two types of bindings, one used by
some of the legacy fbdev drivers and the other by DRM/KMS drivers. There
isn't really much we can do about it, though, as far as I can see.

This panel is used with an fbdev driver, right?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/6af19370/attachment.sig>

From gnomes at lxorguk.ukuu.org.uk  Tue Feb  2 08:34:44 2016
From: gnomes at lxorguk.ukuu.org.uk (One Thousand Gnomes)
Date: Tue, 2 Feb 2016 16:34:44 +0000
Subject: [PATCH] staging: goldfish: use div64_s64 instead of do_div
In-Reply-To: <1676170.0qik6mzm6D@wuerfel>
References: <1676170.0qik6mzm6D@wuerfel>
Message-ID: <20160202163444.25b73816@lxorguk.ukuu.org.uk>

On Mon, 01 Feb 2016 11:33 +0100
Arnd Bergmann <arnd at arndb.de> wrote:

> The goldfish nand driver divides a signed 64-bit number (loff_t)
> in multiple places using the do_div() function. This has always
> been unreliable but now produces a compiler warning (since 4.5-rc1):
> 
> goldfish/goldfish_nand.c: In function 'goldfish_nand_erase':
> goldfish/goldfish_nand.c:107:91: error: comparison of distinct pointer types lacks a cast [-Werror]
> goldfish/goldfish_nand.c: In function 'goldfish_nand_read_oob':
> goldfish/goldfish_nand.c:145:91: error: comparison of distinct pointer types lacks a cast [-Werror]
> 
> This changes the code to the equivalent div_s64{,_rem} that
> works correctly for negative numbers (which we should never
> get here).
> 
> The warning has shown up on ARM allmodconfig builds after the goldfish
> bus driver has become visible on ARM.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: bd2f348db503 ("goldfish: refactor goldfish platform configs")

Acked-by: Alan Cox <alan at linux.intel.com>

Now agree with Arnd's patch.


From tony at atomide.com  Tue Feb  2 08:35:36 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 2 Feb 2016 08:35:36 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>
References: <20160201232833.GR19432@atomide.com>
 <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>
 <20160202030533.GT19432@atomide.com>
 <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>
Message-ID: <20160202163536.GU19432@atomide.com>

Hi,

* Ulf Hansson <ulf.hansson at linaro.org> [160202 02:43]:
> 
> For the omap_hsmmc and likely also other omap drivers, which needs more
> than one attempt to ->probe() (returning -EPROBE_DEFER), this commit
> causes a regression at the PM domain level (omap hwmod).
> 
> The reason is that the drivers don't put back the device into low power
> state while bailing out in ->probe to return -EPROBE_DEFER. This leads to
> that pm_runtime_reinit() in driver core, is re-initializing the runtime PM
> status from RPM_ACTIVE to RPM_SUSPENDED.

Yup, that's the bug here. It seems that we never call the runtime_suspend
callback at the end of a first failed device driver probe if the driver
has set pm_runtime_use_autosuspend. Only rpm_idle runtime_idle callback
gets called. So the device stays on.

This does not happen if pm_runtime_dont_use_autosuspend() is added to
the end of the device driver probe before pm_runtime_put_sync().

> The next ->probe() attempt then triggers the ->runtime_resume() callback
> to be invoked, which means this happens two times in a row. At the PM
> domain level (omap hwmod) this is being treated as an error and thus the
> runtime PM status of the device isn't correctly synchronized with the
> runtime PM core.

That's a valid error though, let's not remove it. The reason why we
call runtime_resume() twice is because runtime_suspend callback never
gets called like I explain above.

> In the end, ->probe() anyway succeeds (as the driver don't checks the
> error code from the runtime PM APIs), but results in that the PM domain
> always stays powered on. This because of the runtime PM core believes the
> device is RPM_SUSPENDED.

FYI, the following allows runtime_suspend callback to get called at the
end of a failed driver probe so the hardware state matches the PM runtime
state. Need to debug more.

Regards,

Tony

8< ------------
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2232,6 +2232,7 @@ err_irq:
 		dma_release_channel(host->tx_chan);
 	if (host->rx_chan)
 		dma_release_channel(host->rx_chan);
+	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);
 	if (host->dbclk)


From acme at kernel.org  Tue Feb  2 08:41:29 2016
From: acme at kernel.org (Arnaldo Carvalho de Melo)
Date: Tue, 2 Feb 2016 13:41:29 -0300
Subject: [PATCH V8 23/23] perf tools: adding coresight etm PMU record
 capabilities
In-Reply-To: <CANLsYkysvVKoaxKJu9TYLAGJaZj9=9gMN+O6NpcDLztJNrgy+w@mail.gmail.com>
References: <1452807977-8069-1-git-send-email-mathieu.poirier@linaro.org>
 <1452807977-8069-24-git-send-email-mathieu.poirier@linaro.org>
 <CANLsYkyBCFyu3Q-3jet-6rNfa3vGzWWQ3_m+PNf4Z+n6OxsscA@mail.gmail.com>
 <20160125211048.GE22501@kernel.org> <56AB4027.2070208@intel.com>
 <CANLsYkyFSjLmT_i7ANE2VL21Y+Nud13SvjOd1akV-e9hQcTcHA@mail.gmail.com>
 <20160129211208.GB32225@kernel.org>
 <CANLsYkxwtqHyoQ7+Z4a+qJfTV_ZWc72_mJh12FHxVEhNYKsgjw@mail.gmail.com>
 <CANLsYkysvVKoaxKJu9TYLAGJaZj9=9gMN+O6NpcDLztJNrgy+w@mail.gmail.com>
Message-ID: <20160202164129.GE32488@kernel.org>

Em Tue, Feb 02, 2016 at 09:20:51AM -0700, Mathieu Poirier escreveu:
> [...]
> 
> >>> >
> >>> > Looks OK, apart from adding linux/coresight-pmu.h to the manifest, but I
> >>> > mentioned that on another patch.
> >>> >
> >>> > However there is no decoder, which begs the question, is there anything you
> >>> > can actually do with the perf.data file?  Might be a bit confusing for users
> >>> > if they can capture traces but not use perf tools on the resulting perf.data
> >>> > file?
> >>>
> >>> We are working on a decoding library in parallel to this work.
> >>
> >> Would be nice to be able to get both in the same patch kit, no? So that
> >> one can both record and process the traces, verifying it all works.
> >
> > We are still a few weeks away from being in a position where the
> > community can start playing with the decoding library.  I can hold off
> > on the "perf tools" patches when I queue the kernel side of the work
> > for 4.6 but since you and Adrian have already reviewed the work it
> > would be nice to have that part included as well.
> >
> > We've been playing with the perf.data files for a couple of months now
> > and things look at the right place.  This isn't surprising since we
> > are using the same framework as X86.
> >
> > I think the generation of the perf.data file should be coupled with
> > the submission of the kernel driver but would also respect a diverging
> > point of view.  Simply let me know what you prefer and I will adjust
> > V9 accordingly.
> 
> Arnaldo,
> 
> I'm preparing V9 at this time - what's your view on the above?

I'd say go with something we can test, i.e. if we generate a perf.data
file we can't then process to figure out if what was inserted is right,
how can we decide if it is ok?

Otherwise please describe how you test it, preferably by having this in
the commit log, i.e. if you decide that using plain 'perf report -D' is
enough, state that and show the output, etc.

- Arnaldo


From wens at csie.org  Tue Feb  2 08:41:37 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Wed, 3 Feb 2016 00:41:37 +0800
Subject: [PATCH 10/11] ARM: dts: sun9i: a80-optimus: Disable dummy
 regulators vcc3v0, vcc3v3, vcc5v0
In-Reply-To: <20160202162136.GX4652@lukather>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-11-git-send-email-wens@csie.org>
 <20160202162136.GX4652@lukather>
Message-ID: <CAGb2v66xjgsoVEBocUfDk6DDx4QcH-4pP94v+4FHLTJ=rii09Q@mail.gmail.com>

On Wed, Feb 3, 2016 at 12:21 AM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> Hi,
>
> On Tue, Feb 02, 2016 at 06:27:43PM +0800, Chen-Yu Tsai wrote:
>> These 3 regulators are provided in sunxi-common-regulators.dtsi.
>> 3.0V/3.3V and 5.0V are commonly used voltages in Allwinner devices.
>> These dummy regulators provide a stand-in when bindings that require
>> one, but the real regulator is not supported yet.
>>
>> Since these are no longer needed, we can disable them.
>>
>> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
>
> Why not remove the include entirely then?

reg_vbus* are still used. Or should we move them as well?

ChenYu


From marc.zyngier at arm.com  Tue Feb  2 08:46:18 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 2 Feb 2016 16:46:18 +0000
Subject: [PATCH v3] irqchip: gicv3-its: Fix memory leak in
 its_free_tables()
In-Reply-To: <1454379584-21772-1-git-send-email-shankerd@codeaurora.org>
References: <1454379584-21772-1-git-send-email-shankerd@codeaurora.org>
Message-ID: <56B0DD5A.3080500@arm.com>

On 02/02/16 02:19, Shanker Donthineni wrote:
> The current ITS driver has a memory leak in its_free_tables(). It
> happens on tear down path of the driver when its_probe() call fails.
> its_free_tables() should free the exact number of pages that have
> been allocated, not just a single page as current code does.
> 
> This patch records the memory size for each ITS_BASERn at the time of
> page allocation and uses the same size information when freeing pages
> to fix the issue.
> 
> Signed-off-by: Shanker Donthineni <shankerd at codeaurora.org>

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

	M.
-- 
Jazz is not dead. It just smells funny...


From andre.przywara at arm.com  Tue Feb  2 08:46:31 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 2 Feb 2016 16:46:31 +0000
Subject: [linux-sunxi] [PATCH 10/11] arm64: dts: add Allwinner A64 SoC
 .dtsi
In-Reply-To: <56B0D83E.5090604@gmail.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-11-git-send-email-andre.przywara@arm.com>
 <56B0D83E.5090604@gmail.com>
Message-ID: <56B0DD67.3060802@arm.com>

Hi Jens,

thanks for having such an elaborate look!

On 02/02/16 16:24, Jens Kuske wrote:
> Hi,
> 
> On 01/02/16 18:39, Andre Przywara wrote:
>> The Allwinner A64 SoC is low-cost SoC with 4 ARM Cortex-A53 cores
>> and the typical tablet / TV box peripherals.
>> The Soc is based on the (32-bit) Allwinner H3 chip, sharing most of
>> the peripherals and the memory map.
>> Although the cores are proper 64-bit ones, the whole SoC is actually
>> limited to 4GB (including all the supported DRAM), so we use 32-bit
>> address and size cells. This has the nice feature of us being able to
>> reuse the DT for 32-bit kernels as well.
>> This .dtsi lists the hardware that we support so far.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>> ---
>>  Documentation/devicetree/bindings/arm/sunxi.txt   |   1 +
>>  Documentation/devicetree/bindings/clock/sunxi.txt |   1 +
>>  arch/arm64/boot/dts/allwinner/a64.dtsi            | 583 ++++++++++++++++++++++
>>  3 files changed, 585 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/allwinner/a64.dtsi
>>
>> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
>> index 980e065..4a83853 100644
>> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
>> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
>> @@ -14,6 +14,7 @@ using one of the following compatible strings:
>>    allwinner,sun8i-a83t
>>    allwinner,sun8i-h3
>>    allwinner,sun9i-a80
>> +  allwinner,a64
>>  
>>  For Allwinner SoCs without any specific needs the generic fallback value of:
>>    allwinner,sunxi
>> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
>> index e59f57b..44b0c6c 100644
>> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
>> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
>> @@ -77,6 +77,7 @@ Required properties:
>>  	"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
>>  	"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
>>  	"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
>> +	"allwinner,a64-bus-gates-clk" - for the A64 multi-parent bus gates clock
>>  
>>  Required properties for all clocks:
>>  - reg : shall be the control register address for the clock.
>> diff --git a/arch/arm64/boot/dts/allwinner/a64.dtsi b/arch/arm64/boot/dts/allwinner/a64.dtsi
>> new file mode 100644
>> index 0000000..8dce10f
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/a64.dtsi
>> @@ -0,0 +1,583 @@
>> +/*
>> + * Copyright (C) 2016 ARM Ltd.
>> + * based on the Allwinner H3 dtsi:
>> + *    Copyright (C) 2015 Jens Kuske <jenskuske at gmail.com>
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This file is free software; you can redistribute it and/or
>> + *     modify it under the terms of the GNU General Public License as
>> + *     published by the Free Software Foundation; either version 2 of the
>> + *     License, or (at your option) any later version.
>> + *
>> + *     This file is distributed in the hope that it will be useful,
>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *     GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + *     obtaining a copy of this software and associated documentation
>> + *     files (the "Software"), to deal in the Software without
>> + *     restriction, including without limitation the rights to use,
>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>> + *     sell copies of the Software, and to permit persons to whom the
>> + *     Software is furnished to do so, subject to the following
>> + *     conditions:
>> + *
>> + *     The above copyright notice and this permission notice shall be
>> + *     included in all copies or substantial portions of the Software.
>> + *
>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + *     OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>> +
>> +/ {
>> +	compatible = "allwinner,a64", "allwinner,sunxi";
>> +	interrupt-parent = <&gic>;
>> +	#address-cells = <1>;
>> +	#size-cells = <1>;
>> +
>> +	aliases {
>> +		serial0 = &uart0;
>> +		serial1 = &uart1;
>> +		serial2 = &uart2;
>> +		serial3 = &uart3;
>> +		serial4 = &uart4;
>> +	};
>> +
>> +	cpus {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		cpu at 0 {
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			device_type = "cpu";
>> +			reg = <0>;
>> +			enable-method = "psci";
>> +		};
>> +
>> +		cpu at 1 {
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			device_type = "cpu";
>> +			reg = <1>;
>> +			enable-method = "psci";
>> +		};
>> +
>> +		cpu at 2 {
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			device_type = "cpu";
>> +			reg = <2>;
>> +			enable-method = "psci";
>> +		};
>> +
>> +		cpu at 3 {
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			device_type = "cpu";
>> +			reg = <3>;
>> +			enable-method = "psci";
>> +		};
>> +	};
>> +
>> +	psci {
>> +		compatible = "arm,psci-0.2", "arm,psci";
>> +		method = "smc";
>> +		cpu_suspend = <0xc4000001>;
>> +		cpu_off = <0x84000002>;
>> +		cpu_on = <0xc4000003>;
>> +	};
>> +
>> +	memory {
>> +		device_type = "memory";
>> +		reg = <0x40000000 0>;
>> +	};
>> +
>> +	timer {
>> +		compatible = "arm,armv8-timer";
>> +		interrupts = <GIC_PPI 13
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			     <GIC_PPI 14
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			     <GIC_PPI 11
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			     <GIC_PPI 10
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>> +	};
>> +
>> +	clocks {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		ranges;
>> +
>> +		osc24M: osc24M_clk {
>> +			#clock-cells = <0>;
>> +			compatible = "fixed-clock";
>> +			clock-frequency = <24000000>;
>> +			clock-output-names = "osc24M";
>> +		};
>> +
>> +		osc32k: osc32k_clk {
>> +			#clock-cells = <0>;
>> +			compatible = "fixed-clock";
>> +			clock-frequency = <32768>;
>> +			clock-output-names = "osc32k";
>> +		};
>> +
>> +		pll1: clk at 01c20000 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun8i-a23-pll1-clk";
>> +			reg = <0x01c20000 0x4>;
>> +			clocks = <&osc24M>;
>> +			clock-output-names = "pll1";
>> +		};
>> +
>> +		pll6: clk at 01c20028 {
>> +			#clock-cells = <1>;
>> +			compatible = "allwinner,sun6i-a31-pll6-clk";
>> +			reg = <0x01c20028 0x4>;
>> +			clocks = <&osc24M>;
>> +			clock-output-names = "pll6", "pll6x2";
>> +		};
>> +
>> +		pll6d2: pll6d2_clk {
>> +			#clock-cells = <0>;
>> +			compatible = "fixed-factor-clock";
>> +			clock-div = <2>;
>> +			clock-mult = <1>;
>> +			clocks = <&pll6 0>;
>> +			clock-output-names = "pll6d2";
>> +		};
>> +
>> +		/* dummy clock until pll6 can be reused */
>> +		pll8: pll8_clk {
>> +			#clock-cells = <0>;
>> +			compatible = "fixed-clock";
>> +			clock-frequency = <1>;
>> +			clock-output-names = "pll8";
>> +		};

Since I have you (as the original author ;-) in the loop: What was again
the reason for this dummy clock? Can't it be modelled with the existing
clock drivers in Linux?

>> +
>> +		cpu: cpu_clk at 01c20050 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun4i-a10-cpu-clk";
>> +			reg = <0x01c20050 0x4>;
>> +			clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
>> +			clock-output-names = "cpu";
>> +			critical-clocks = <0>;
>> +		};
>> +
>> +		axi: axi_clk at 01c20050 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun4i-a10-axi-clk";
>> +			reg = <0x01c20050 0x4>;
>> +			clocks = <&cpu>;
>> +			clock-output-names = "axi";
>> +		};
>> +
>> +		ahb1: ahb1_clk at 01c20054 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun6i-a31-ahb1-clk";
>> +			reg = <0x01c20054 0x4>;
>> +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
>> +			clock-output-names = "ahb1";
>> +		};
>> +
>> +		ahb2: ahb2_clk at 01c2005c {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun8i-h3-ahb2-clk";
>> +			reg = <0x01c2005c 0x4>;
>> +			clocks = <&ahb1>, <&pll6d2>;
>> +			clock-output-names = "ahb2";
>> +		};
>> +
>> +		apb1: apb1_clk at 01c20054 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun4i-a10-apb0-clk";
>> +			reg = <0x01c20054 0x4>;
>> +			clocks = <&ahb1>;
>> +			clock-output-names = "apb1";
>> +		};
>> +
>> +		apb2: apb2_clk at 01c20058 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun4i-a10-apb1-clk";
>> +			reg = <0x01c20058 0x4>;
>> +			clocks = <&osc32k>, <&osc24M>, <&pll6 1>, <&pll6 1>;
>> +			clock-output-names = "apb2";
>> +		};
>> +
>> +		bus_gates: clk at 01c20060 {
>> +			#clock-cells = <1>;
>> +			compatible = "allwinner,a64-bus-gates-clk",
>> +				     "allwinner,sunxi-multi-bus-gates-clk";
>> +			reg = <0x01c20060 0x14>;
>> +			ahb1_parent {
>> +				clocks = <&ahb1>;
>> +				clock-indices = <1>, <5>,
>> +						<6>, <8>,
>> +						<9>, <10>,
>> +						<13>, <14>,
>> +						<18>, <19>,
>> +						<20>, <21>,
>> +						<23>, <24>,
>> +						<25>, <28>,
>> +						<32>, <35>,
>> +						<36>, <37>,
>> +						<40>, <43>,
>> +						<44>, <52>,
>> +						<53>, <54>,
>> +						<135>;
>> +				clock-output-names = "bus_mipidsi", "bus_ce",
>> +						"bus_dma", "bus_mmc0",
>> +						"bus_mmc1", "bus_mmc2",
>> +						"bus_nand", "bus_sdram",
>> +						"bus_ts", "bus_hstimer",
>> +						"bus_spi0", "bus_spi1",
>> +						"bus_otg", "bus_otg_ehci0",
>> +						"bus_ehci0", "bus_otg_ohci0",
>> +						"bus_ve", "bus_lcd0",
>> +						"bus_lcd1", "bus_deint",
>> +						"bus_csi", "bus_hdmi",
>> +						"bus_de", "bus_gpu",
>> +						"bus_msgbox", "bus_spinlock",
>> +						"bus_dbg";
>> +			};
>> +			ahb2_parent {
>> +				clocks = <&ahb2>;
>> +				clock-indices = <17>, <29>;
>> +				clock-output-names = "bus_gmac", "bus_ohci0";
>> +			};
>> +			apb1_parent {
>> +				clocks = <&apb1>;
>> +				clock-indices = <64>, <65>,
>> +						<69>, <72>,
>> +						<76>, <77>,
>> +						<78>;
>> +				clock-output-names = "bus_codec", "bus_spdif",
>> +						"bus_pio", "bus_ths",
>> +						"bus_i2s0", "bus_i2s1",
>> +						"bus_i2s2";
>> +			};
>> +			abp2_parent {
>> +				clocks = <&apb2>;
>> +				clock-indices = <96>, <97>,
>> +						<98>, <101>,
>> +						<112>, <113>,
>> +						<114>, <115>,
>> +						<116>;
>> +				clock-output-names = "bus_i2c0", "bus_i2c1",
>> +						"bus_i2c2", "bus_scr",
>> +						"bus_uart0", "bus_uart1",
>> +						"bus_uart2", "bus_uart3",
>> +						"bus_uart4";
>> +			};
>> +		};
>> +
>> +		mmc0_clk: clk at 01c20088 {
>> +			#clock-cells = <1>;
>> +			compatible = "allwinner,sun4i-a10-mmc-clk";
> 
> The A64 MMC clocks don't seem to be fully compatible to A10. The output
> and sample phase control has been moved to the MMC module itself.
> The dividers are the same, but the additional special "outputs" are gone.

So from comparing the H3 and the A64 datasheet I see that this is one of
the rare deviations of the A64 from the H3?

>> +			reg = <0x01c20088 0x4>;
>> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
> 
> Parents are PLL6(2x) and PLL8(2x) according to manual.

Indeed, thanks for pointing this out! So do we need a proper pll8 clock?

> 
>> +			clock-output-names = "mmc0",
>> +					     "mmc0_output",
>> +					     "mmc0_sample";
>> +		};
>> +
>> +		mmc1_clk: clk at 01c2008c {
>> +			#clock-cells = <1>;
>> +			compatible = "allwinner,sun4i-a10-mmc-clk";
>> +			reg = <0x01c2008c 0x4>;
>> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>> +			clock-output-names = "mmc1",
>> +					     "mmc1_output",
>> +					     "mmc1_sample";
>> +		};
>> +
>> +		mmc2_clk: clk at 01c20090 {
>> +			#clock-cells = <1>;
>> +			compatible = "allwinner,sun4i-a10-mmc-clk";
>> +			reg = <0x01c20090 0x4>;
>> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>> +			clock-output-names = "mmc2",
>> +					     "mmc2_output",
>> +					     "mmc2_sample";
>> +		};
>> +	};
>> +
>> +	regulators {
>> +		reg_vcc3v3: vcc3v3 {
>> +			compatible = "regulator-fixed";
>> +			regulator-name = "vcc3v3";
>> +			regulator-min-microvolt = <3300000>;
>> +			regulator-max-microvolt = <3300000>;
>> +		};
>> +	};
>> +
>> +	soc {
>> +		compatible = "simple-bus";
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		ranges;
>> +
>> +		mmc0: mmc at 01c0f000 {
>> +			compatible = "allwinner,sun5i-a13-mmc";
>> +			reg = <0x01c0f000 0x1000>;
>> +			clocks = <&bus_gates 8>,
>> +				 <&mmc0_clk 0>,
> 
> Consequently, the MMC driver now has to control the output/sample phase
> with registers 0x140-0x148 instead of
>> +				 <&mmc0_clk 1>,
>> +				 <&mmc0_clk 2>;

OK, good point. I was just briefly browsing over the register
descriptions and missed that.
So it looks like I need to change the driver. Interestingly it seems to
work anyways ...

> And there seems to be some new clock divider somewhere which I haven't
> found in the manual yet. The clock measured at the CLK pin is always
> half the expected rate (even with 24MHz as MMC clock parent, so no
> PLL6*2 problem).

Mmh, I heard about that mysterious clock doubling / halving already. Was
that actually causing any issues?

> 
>> +			clock-names = "ahb",
>> +				      "mmc",
>> +				      "output",
>> +				      "sample";
>> +			resets = <&ahb_rst 8>;
>> +			reset-names = "ahb";
>> +			interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
>> +			status = "disabled";
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +		};
>> +
>> +		mmc1: mmc at 01c10000 {
>> +			compatible = "allwinner,sun5i-a13-mmc";
>> +			reg = <0x01c10000 0x1000>;
>> +			clocks = <&bus_gates 9>,
>> +				 <&mmc1_clk 0>,
>> +				 <&mmc1_clk 1>,
>> +				 <&mmc1_clk 2>;
>> +			clock-names = "ahb",
>> +				      "mmc",
>> +				      "output",
>> +				      "sample";
>> +			resets = <&ahb_rst 9>;
>> +			reset-names = "ahb";
>> +			interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
>> +			status = "disabled";
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +		};
>> +
>> +		mmc2: mmc at 01c11000 {
>> +			compatible = "allwinner,sun5i-a13-mmc";
>> +			reg = <0x01c11000 0x1000>;
>> +			clocks = <&bus_gates 10>,
>> +				 <&mmc2_clk 0>,
>> +				 <&mmc2_clk 1>,
>> +				 <&mmc2_clk 2>;
>> +			clock-names = "ahb",
>> +				      "mmc",
>> +				      "output",
>> +				      "sample";
>> +			resets = <&ahb_rst 10>;
>> +			reset-names = "ahb";
>> +			interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
>> +			status = "disabled";
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +		};
>> +
>> +		pio: pinctrl at 01c20800 {
>> +			compatible = "allwinner,a64-pinctrl";
>> +			reg = <0x01c20800 0x400>;
>> +			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
>> +			clocks = <&bus_gates 69>;
>> +			gpio-controller;
>> +			#gpio-cells = <3>;
>> +			interrupt-controller;
>> +			#interrupt-cells = <2>;
>> +
>> +			uart0_pins_a: uart0 at 0 {
>> +				allwinner,pins = "PB8", "PB9";
>> +				allwinner,function = "uart0";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart0_pins_b: uart0 at 1 {
>> +				allwinner,pins = "PF2", "PF3";
>> +				allwinner,function = "uart0";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart1_pins: uart1 at 0 {
>> +				allwinner,pins = "PG6", "PG7", "PG8", "PG9";
>> +				allwinner,function = "uart1";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart2_pins: uart2 at 0 {
>> +				allwinner,pins = "PB0", "PB1", "PB2", "PB3";
>> +				allwinner,function = "uart2";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart3_pins_a: uart3 at 0 {
>> +				allwinner,pins = "PD0", "PD1";
>> +				allwinner,function = "uart3";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart3_pins_b: uart3 at 1 {
>> +				allwinner,pins = "PH4", "PH5", "PH6", "PH7";
>> +				allwinner,function = "uart3";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart4_pins: uart4 at 0 {
>> +				allwinner,pins = "PD2", "PD3", "PD4", "PD5";
>> +				allwinner,function = "uart4";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			mmc0_pins: mmc0 at 0 {
>> +				allwinner,pins = "PF0", "PF1", "PF2", "PF3",
>> +						 "PF4", "PF5";
>> +				allwinner,function = "mmc0";
>> +				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			mmc0_default_cd_pin: mmc0_cd_pin at 0 {
>> +				allwinner,pins = "PF6";
>> +				allwinner,function = "gpio_in";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>> +			};
>> +
>> +			mmc1_pins: mmc1 at 0 {
>> +				allwinner,pins = "PG0", "PG1", "PG2", "PG3",
>> +						 "PG4", "PG5";
>> +				allwinner,function = "mmc1";
>> +				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			mmc2_pins: mmc2 at 0 {
>> +				allwinner,pins = "PC1", "PC5", "PC6", "PC8",
>> +						 "PC9", "PC10";
>> +				allwinner,function = "mmc2";
>> +				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +		};
>> +
>> +		ahb_rst: reset at 01c202c0 {
>> +			#reset-cells = <1>;
>> +			compatible = "allwinner,sun6i-a31-ahb1-reset";
>> +			reg = <0x01c202c0 0xc>;
>> +		};
>> +
>> +		apb1_rst: reset at 01c202d0 {
>> +			#reset-cells = <1>;
>> +			compatible = "allwinner,sun6i-a31-clock-reset";
>> +			reg = <0x01c202d0 0x4>;
>> +		};
>> +
>> +		apb2_rst: reset at 01c202d8 {
>> +			#reset-cells = <1>;
>> +			compatible = "allwinner,sun6i-a31-clock-reset";
>> +			reg = <0x01c202d8 0x4>;
>> +		};
>> +
>> +		uart0: serial at 01c28000 {
>> +			compatible = "snps,dw-apb-uart";
>> +			reg = <0x01c28000 0x400>;
>> +			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
>> +			reg-shift = <2>;
>> +			reg-io-width = <4>;
>> +			clocks = <&bus_gates 112>;
>> +			resets = <&apb2_rst 16>;
>> +			reset-names = "apb2";
> 
> Do we need reset-names here (and below)?

Probably not, in fact I was wondering about that already. Actually I
just copied them from some other DT ;-)

>> +			status = "disabled";
>> +		};
>> +
>> +		uart1: serial at 01c28400 {
>> +			compatible = "snps,dw-apb-uart";
>> +			reg = <0x01c28400 0x400>;
>> +			interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
>> +			reg-shift = <2>;
>> +			reg-io-width = <4>;
>> +			clocks = <&bus_gates 113>;
>> +			resets = <&apb2_rst 17>;
>> +			reset-names = "apb2";
>> +			status = "disabled";
>> +		};
>> +
>> +		uart2: serial at 01c28800 {
>> +			compatible = "snps,dw-apb-uart";
>> +			reg = <0x01c28800 0x400>;
>> +			interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
>> +			reg-shift = <2>;
>> +			reg-io-width = <4>;
>> +			clocks = <&bus_gates 114>;
>> +			resets = <&apb2_rst 18>;
>> +			reset-names = "apb2";
>> +			status = "disabled";
>> +		};
>> +
>> +		uart3: serial at 01c28c00 {
>> +			compatible = "snps,dw-apb-uart";
>> +			reg = <0x01c28c00 0x400>;
>> +			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
>> +			reg-shift = <2>;
>> +			reg-io-width = <4>;
>> +			clocks = <&bus_gates 115>;
>> +			resets = <&apb2_rst 19>;
>> +			reset-names = "apb2";
>> +			status = "disabled";
>> +		};
>> +
>> +		uart4: serial at 01c29000 {
>> +			compatible = "snps,dw-apb-uart";
>> +			reg = <0x01c29000 0x400>;
>> +			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
>> +			reg-shift = <2>;
>> +			reg-io-width = <4>;
>> +			clocks = <&bus_gates 116>;
>> +			resets = <&apb2_rst 20>;
>> +			reset-names = "apb2";
>> +			status = "disabled";
>> +		};
>> +
>> +		rtc: rtc at 01f00000 {
>> +			compatible = "allwinner,sun6i-a31-rtc";
>> +			reg = <0x01f00000 0x54>;
>> +			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
>> +		};
>> +	};
>> +
>> +	gic: interrupt-controller@{
>> +		compatible = "arm,gic-400";
>> +		interrupt-controller;
>> +		#interrupt-cells = <3>;
>> +		#address-cells = <0>;
>> +
>> +		reg = <0x01C81000 0x1000>,
>> +		      <0x01C82000 0x2000>,
>> +		      <0x01C84000 0x2000>,
>> +		      <0x01C86000 0x2000>;
> 
> Maybe lowercase hex here too.

Yes.


Thanks for actually going through this!

Cheers,
Andre.

>> +		interrupts = <GIC_PPI 9
>> +		      (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>> +	};
>> +};
>>
> 
> Regards,
> Jens
> 


From will.deacon at arm.com  Tue Feb  2 08:48:18 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 2 Feb 2016 16:48:18 +0000
Subject: [PATCH] arm64: asm: Explicitly include linux/personality.h in
 asm/page.h
In-Reply-To: <20160128144610.GA2380@ulmo>
References: <1453983508-20410-1-git-send-email-broonie@kernel.org>
 <20160128124417.GE6078@sirena.org.uk>
 <20160128141425.GA20099@e104818-lin.cambridge.arm.com>
 <20160128144610.GA2380@ulmo>
Message-ID: <20160202164817.GM10166@arm.com>

On Thu, Jan 28, 2016 at 03:46:10PM +0100, Thierry Reding wrote:
> On Thu, Jan 28, 2016 at 02:14:26PM +0000, Catalin Marinas wrote:
> > On Thu, Jan 28, 2016 at 12:44:17PM +0000, Mark Brown wrote:
> > > On Thu, Jan 28, 2016 at 12:18:28PM +0000, Mark Brown wrote:
> > > > asm/page.h uses READ_IMPLIES_EXEC from linux/personality.h but does not
> > > > explicitly include it causing build failures in -next where whatever was
> > > > causing it to be implicitly included has changed to remove that
> > > > inclusion.  Add an explicit inclusion to fix this.
> > > 
> > > Argh, sorry - this causes problems further down the line with linking
> > > vdso.lds due to enums getting into the linker script and upsetting the
> > > linker (there are several compile errors today so it was masked).
> > 
> > You can move the include further down after the #ifndef __ASSEMBLY__
> 
> Indeed, here's what I've been using to successfully complete ARM64 test
> builds:
> 
> --- >8 ---
> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> index 9b2f5a9d019d..ae615b9d9a55 100644
> --- a/arch/arm64/include/asm/page.h
> +++ b/arch/arm64/include/asm/page.h
> @@ -39,6 +39,7 @@
>  
>  #ifndef __ASSEMBLY__
>  
> +#include <linux/personality.h> /* for READ_IMPLIES_EXEC */
>  #include <asm/pgtable-types.h>
>  
>  extern void __cpu_clear_user_page(void *p, unsigned long user);

I see this has ended up in linux-next, but I'm not sure whether or not
it's actually queued someplace for 4.6. Any ideas?

If not, I can take it (or some derivative) through arm64 as a fix for
-rc3.

Will


From moinejf at free.fr  Tue Feb  2 07:33:43 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Tue, 2 Feb 2016 16:33:43 +0100
Subject: [PATCH v3 0/2] Add a DRM display driver to the Allwinner H3
Message-ID: <cover.1454427223.git.moinejf@free.fr>

The proposed DRM driver works on a Orange PI 2 with a kernel 4.5.0-rc1
and some H3 patches found in Hans de Goede's GIT repository.

As there is no documentation about the HDMI of the H3,
the associated encoder/connector driver has not been included
in this patch series.
For test purpose, it may be built as a out-of-tree driver
from the tarball:
	http://moinejf.free.fr/opi2/h3-hdmi.tar.gz
and the DT files:
	http://moinejf.free.fr/opi2/sun8i-h3.dtsi
	http://moinejf.free.fr/opi2/sun8i-h3-orangepi-plus.dts

Jean-Francois Moine (2):
  clk: sunxi: Add sun6i/8i video support
  drm: sunxi: Add a basic DRM driver for Allwinner DE2

 Documentation/devicetree/bindings/clock/sunxi.txt  |   2 +
 .../devicetree/bindings/display/sunxi.txt          |  81 ++++
 drivers/clk/sunxi/clk-sun6i-display.c              | 106 +++++
 drivers/clk/sunxi/clk-sun6i-pll3.c                 | 174 +++++++
 drivers/gpu/drm/Kconfig                            |   2 +
 drivers/gpu/drm/Makefile                           |   1 +
 drivers/gpu/drm/sunxi/Kconfig                      |  20 +
 drivers/gpu/drm/sunxi/Makefile                     |   7 +
 drivers/gpu/drm/sunxi/de2_crtc.c                   | 421 +++++++++++++++++
 drivers/gpu/drm/sunxi/de2_crtc.h                   |  61 +++
 drivers/gpu/drm/sunxi/de2_de.c                     | 505 +++++++++++++++++++++
 drivers/gpu/drm/sunxi/de2_drm.h                    |  40 ++
 drivers/gpu/drm/sunxi/de2_drv.c                    | 377 +++++++++++++++
 drivers/gpu/drm/sunxi/de2_plane.c                  |  91 ++++
 14 files changed, 1888 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/sunxi.txt
 create mode 100644 drivers/clk/sunxi/clk-sun6i-display.c
 create mode 100644 drivers/clk/sunxi/clk-sun6i-pll3.c
 create mode 100644 drivers/gpu/drm/sunxi/Kconfig
 create mode 100644 drivers/gpu/drm/sunxi/Makefile
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c

-- 
2.7.0



From tony at atomide.com  Tue Feb  2 08:49:10 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 2 Feb 2016 08:49:10 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <Pine.LNX.4.44L0.1602021112320.1653-100000@iolanthe.rowland.org>
References: <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602021112320.1653-100000@iolanthe.rowland.org>
Message-ID: <20160202164910.GV19432@atomide.com>

* Alan Stern <stern at rowland.harvard.edu> [160202 08:17]:
> On Tue, 2 Feb 2016, Ulf Hansson wrote:
> > 
> > Your observations is correct. The hardware will be kept active
> > in-between the probe attempts (and thus also if probing fails).
> > Although, that's not a regression as that's the behaviour you get from
> > runtime PM, when drivers are implemented like omap_hsmmc.
> 
> Perhaps this is what we should do.  If probing gets deferred a few 
> times, doing runtime suspends and resumes in between will be a waste of 
> time.

That sounds like an optimization though. We'd still have to disable
the deviec somehow after deferred probe gives up.

> ?  pm_runtime_put_sync() _already_ does not respect the autosuspend 
> mode.  If you want to respect it, you have to call 
> pm_runtime_put_sync_autosuspend() instead.

I think you found the real bug there. So the right fix is to
call pm_runtime_put_sync_autosuspend() at the end of failed
probe in omap_hsmmc. Let me give that a try here.

Can we add some warning to pm_runtime_put_sync() about that?

Regards,

Tony


From moinejf at free.fr  Tue Feb  2 07:25:51 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Tue, 2 Feb 2016 16:25:51 +0100
Subject: [PATCH v3 2/2] drm: sunxi: Add a basic DRM driver for Allwinner DE2
In-Reply-To: <cover.1454427223.git.moinejf@free.fr>
References: <cover.1454427223.git.moinejf@free.fr>
Message-ID: <c5a9bc3fd3df1063ee938aa59ba9c70efca6754d.1454427224.git.moinejf@free.fr>

In recent SoCs, as the H3, Allwinner uses a new display interface, DE2.
This patch adds a DRM video driver for this interface.

Signed-off-by: Jean-Francois Moine <moinejf at free.fr>
---
v3:
	- add the hardware cursor
	- simplify and fix the DE2 init sequences
	- generation for all SUNXI SoCs (Andre Przywara)
v2:
	- remarks from Russell King
	- DT documentation added
	- working resolution change with xrandr
	- removal of the HDMI driver
---
 .../devicetree/bindings/display/sunxi.txt          |  81 ++++
 drivers/gpu/drm/Kconfig                            |   2 +
 drivers/gpu/drm/Makefile                           |   1 +
 drivers/gpu/drm/sunxi/Kconfig                      |  20 +
 drivers/gpu/drm/sunxi/Makefile                     |   7 +
 drivers/gpu/drm/sunxi/de2_crtc.c                   | 421 +++++++++++++++++
 drivers/gpu/drm/sunxi/de2_crtc.h                   |  61 +++
 drivers/gpu/drm/sunxi/de2_de.c                     | 505 +++++++++++++++++++++
 drivers/gpu/drm/sunxi/de2_drm.h                    |  40 ++
 drivers/gpu/drm/sunxi/de2_drv.c                    | 377 +++++++++++++++
 drivers/gpu/drm/sunxi/de2_plane.c                  |  91 ++++
 11 files changed, 1606 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/sunxi.txt
 create mode 100644 drivers/gpu/drm/sunxi/Kconfig
 create mode 100644 drivers/gpu/drm/sunxi/Makefile
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c

diff --git a/Documentation/devicetree/bindings/display/sunxi.txt b/Documentation/devicetree/bindings/display/sunxi.txt
new file mode 100644
index 0000000..35f9763
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sunxi.txt
@@ -0,0 +1,81 @@
+Allwinner sunxi display subsystem
+=================================
+
+The sunxi display subsystems contain a display controller (DE),
+one or two LCD controllers (TCON) and their external interfaces.
+
+Display controller
+==================
+
+Required properties:
+
+- compatible: value should be one of the following
+		"allwinner,sun8i-h3-display-engine"
+
+- clocks: must include clock specifiers corresponding to entries in the
+		clock-names property.
+
+- clock-names: must contain
+		gate: for DE activation
+		clock: DE clock
+
+- resets: phandle to the reset of the device
+
+- ports: phandle's to the LCD ports
+
+LCD controller
+==============
+
+Required properties:
+
+- compatible: value should be one of the following
+		"allwinner,sun8i-h3-lcd"
+
+- clocks: must include clock specifiers corresponding to entries in the
+		clock-names property.
+
+- clock-names: must contain
+		gate: for LCD activation
+		clock: pixel clock
+
+- resets: phandle to the reset of the device
+
+- port: port node with endpoint definitions as defined in
+	Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+	de: de-controller at 01000000 {
+		compatible = "allwinner,sun8i-h3-display-engine";
+		...
+		clocks = <&bus_gates 44>, <&de_clk>;
+		clock-names = "gate", "clock";
+		resets = <&ahb_rst 44>;
+		ports = <&lcd0_p>;
+	};
+
+	lcd0: lcd-controller at 01c0c000 {
+		compatible = "allwinner,sun8i-h3-lcd";
+		...
+		clocks = <&bus_gates 35>, <&tcon0_clk>;
+		clock-names = "gate", "clock";
+		resets = <&ahb_rst 35>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		lcd0_p: port {
+			lcd0_ep: endpoint {
+				remote-endpoint = <&hdmi_ep>;
+			};
+		};
+	};
+
+	hdmi: hdmi at 01ee0000 {
+		...
+		#address-cells = <1>;
+		#size-cells = <0>;
+		port {
+			hdmi_ep: endpoint {
+				remote-endpoint = <&lcd0_ep>;
+			};
+		};
+	};
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 8ae7ab6..0cec9a1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -269,3 +269,5 @@ source "drivers/gpu/drm/imx/Kconfig"
 source "drivers/gpu/drm/vc4/Kconfig"
 
 source "drivers/gpu/drm/etnaviv/Kconfig"
+
+source "drivers/gpu/drm/sunxi/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 61766de..eef53f2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -74,3 +74,4 @@ obj-y			+= panel/
 obj-y			+= bridge/
 obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
+obj-$(CONFIG_DRM_SUNXI) += sunxi/
diff --git a/drivers/gpu/drm/sunxi/Kconfig b/drivers/gpu/drm/sunxi/Kconfig
new file mode 100644
index 0000000..e452930
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/Kconfig
@@ -0,0 +1,20 @@
+#
+# Allwinner Video configuration
+#
+
+config DRM_SUNXI
+	tristate "DRM Support for Allwinner Video"
+	depends on DRM && ARCH_SUNXI
+	depends on OF
+	select DRM_KMS_HELPER
+	select DRM_KMS_CMA_HELPER
+	select DRM_GEM_CMA_HELPER
+	help
+	  Choose this option if you have a Allwinner chipset.
+
+config DRM_SUNXI_DE2
+	tristate "Support for Allwinner Video with DE2 interface"
+	depends on DRM_SUNXI
+	help
+	  Choose this option if your Allwinner chipset has the DE2 interface
+	  as the H3.
diff --git a/drivers/gpu/drm/sunxi/Makefile b/drivers/gpu/drm/sunxi/Makefile
new file mode 100644
index 0000000..3778877
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for Allwinner's DRM device driver
+#
+
+sunxi-de2-drm-objs := de2_drv.o de2_de.o de2_crtc.o de2_plane.o
+
+obj-$(CONFIG_DRM_SUNXI_DE2) += sunxi-de2-drm.o
diff --git a/drivers/gpu/drm/sunxi/de2_crtc.c b/drivers/gpu/drm/sunxi/de2_crtc.c
new file mode 100644
index 0000000..b5a093e
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/de2_crtc.c
@@ -0,0 +1,421 @@
+/*
+ * Allwinner DRM driver - DE2 CRTC
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moinejf at free.fr>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <linux/component.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_atomic_helper.h>
+#include <asm/io.h>
+
+#include "de2_drm.h"
+#include "de2_crtc.h"
+
+/* I/O map */
+
+struct tcon {
+	u32 gctl;
+#define		TCON_GCTL_TCON_En BIT(31)
+	u32 gint0;
+#define		TCON_GINT0_TCON1_Vb_Int_En BIT(30)
+#define		TCON_GINT0_TCON1_Vb_Int_Flag BIT(12)
+	u32 gint1;
+	u32 dum0[13];
+	u32 tcon0_ctl;
+#define		TCON0_CTL_TCON_En BIT(31)
+	u32 dum1[19];
+	u32 tcon1_ctl;
+#define		TCON1_CTL_TCON_En BIT(31)
+#define		TCON1_CTL_Interlace_En BIT(20)
+#define		TCON1_CTL_Start_Delay_SHIFT 4
+#define		TCON1_CTL_Start_Delay_MASK GENMASK(8, 4)
+	u32 basic0;			/* XI/YI */
+	u32 basic1;			/* LS_XO/LS_YO */
+	u32 basic2;			/* XO/YO */
+	u32 basic3;			/* HT/HBP */
+	u32 basic4;			/* VT/VBP */
+	u32 basic5;			/* HSPW/VSPW */
+	u32 dum2;
+	u32 ps_sync;
+	u32 dum3[15];
+	u32 io_pol;
+#define		TCON1_IO_POL_IO0_inv BIT(24)
+#define		TCON1_IO_POL_IO1_inv BIT(25)
+#define		TCON1_IO_POL_IO2_inv BIT(26)
+	u32 io_tri;
+	u32 dum4[2];
+
+	u32 ceu_ctl;			/* 100 */
+#define     TCON_CEU_CTL_ceu_en BIT(31)
+	u32 dum5[3];
+	u32 ceu_rr;
+	u32 ceu_rg;
+	u32 ceu_rb;
+	u32 ceu_rc;
+	u32 ceu_gr;
+	u32 ceu_gg;
+	u32 ceu_gb;
+	u32 ceu_gc;
+	u32 ceu_br;
+	u32 ceu_bg;
+	u32 ceu_bb;
+	u32 ceu_bc;
+	u32 ceu_rv;
+	u32 ceu_gv;
+	u32 ceu_bv;
+	u32 dum6[45];
+
+	u32 mux_ctl;			/* 200 */
+#define		TCON_MUX_CTL_HDMI_SRC_SHIFT 8
+#define		TCON_MUX_CTL_HDMI_SRC_MASK GENMASK(9, 8)
+	u32 dum7[63];
+
+	u32 fill_ctl;			/* 300 */
+	u32 fill_start0;
+	u32 fill_end0;
+	u32 fill_data0;
+};
+
+#define XY(x, y) (((x) << 16) | (y))
+
+#define tcon_read(base, member) \
+	readl_relaxed(base + offsetof(struct tcon, member))
+#define tcon_write(base, member, data) \
+	writel_relaxed(data, base + offsetof(struct tcon, member))
+
+/*
+ * vertical blank functions
+ */
+int de2_enable_vblank(struct drm_device *drm, unsigned crtc)
+{
+	return 0;
+}
+
+void de2_disable_vblank(struct drm_device *drm, unsigned crtc)
+{
+}
+
+static void de2_set_frame_timings(struct lcd *lcd)
+{
+	struct drm_crtc *crtc = &lcd->crtc;
+	const struct drm_display_mode *mode = &crtc->mode;
+	int interlace = mode->flags & DRM_MODE_FLAG_INTERLACE ? 2 : 1;
+	int start_delay;
+	u32 data;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	data = XY(mode->hdisplay - 1, mode->vdisplay / interlace - 1);
+	tcon_write(lcd->mmio, basic0, data);
+	tcon_write(lcd->mmio, basic1, data);
+	tcon_write(lcd->mmio, basic2, data);
+	tcon_write(lcd->mmio, basic3,
+			XY(mode->htotal - 1,
+				mode->htotal - mode->hsync_start - 1));
+	tcon_write(lcd->mmio, basic4,
+			XY(mode->vtotal * (3 - interlace),
+				mode->vtotal - mode->vsync_start - 1));
+	tcon_write(lcd->mmio, basic5,
+			 XY(mode->hsync_end - mode->hsync_start - 1,
+				mode->vsync_end - mode->vsync_start - 1));
+
+	tcon_write(lcd->mmio, ps_sync, XY(1, 1));
+
+	data = TCON1_IO_POL_IO2_inv;
+	if (mode->flags & DRM_MODE_FLAG_PVSYNC)
+		data |= TCON1_IO_POL_IO0_inv;
+	if (mode->flags & DRM_MODE_FLAG_PHSYNC)
+		data |= TCON1_IO_POL_IO1_inv;
+	tcon_write(lcd->mmio, io_pol, data);
+
+	tcon_write(lcd->mmio, ceu_ctl,
+		tcon_read(lcd->mmio, ceu_ctl) & ~TCON_CEU_CTL_ceu_en);
+
+	data = tcon_read(lcd->mmio, tcon1_ctl);
+	if (interlace == 2)
+		data |= TCON1_CTL_Interlace_En;
+	else
+		data &= ~TCON1_CTL_Interlace_En;
+	tcon_write(lcd->mmio, tcon1_ctl, data);
+
+	tcon_write(lcd->mmio, fill_ctl, 0);
+	tcon_write(lcd->mmio, fill_start0, mode->vtotal + 1);
+	tcon_write(lcd->mmio, fill_end0, mode->vtotal);
+	tcon_write(lcd->mmio, fill_data0, 0);
+
+	start_delay = (mode->vtotal - mode->vdisplay) / interlace - 5;
+	if (start_delay > 31)
+		start_delay = 31;
+	data = tcon_read(lcd->mmio, tcon1_ctl);
+	data &= ~TCON1_CTL_Start_Delay_MASK;
+	data |= start_delay << TCON1_CTL_Start_Delay_SHIFT;
+	tcon_write(lcd->mmio, tcon1_ctl, data);
+
+	tcon_write(lcd->mmio, io_tri, 0x0fffffff);
+}
+
+static void de2_crtc_enable(struct drm_crtc *crtc)
+{
+	struct lcd *lcd = crtc_to_lcd(crtc);
+	struct drm_display_mode *mode = &crtc->mode;
+	u32 data;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	de2_set_frame_timings(lcd);
+
+	clk_set_rate(lcd->clk, mode->clock * 1000);
+
+	if (lcd->num == 0) {				/* HDMI */
+		data = tcon_read(lcd->mmio, mux_ctl);
+		data &= ~TCON_MUX_CTL_HDMI_SRC_MASK;
+		data |= lcd->num << TCON_MUX_CTL_HDMI_SRC_SHIFT;
+		tcon_write(lcd->mmio, mux_ctl, data);
+	}
+
+	tcon_write(lcd->mmio, tcon1_ctl,
+		tcon_read(lcd->mmio, tcon1_ctl) | TCON1_CTL_TCON_En);
+
+	de2_de_panel_init(lcd->priv, lcd->num, mode);
+
+	drm_mode_debug_printmodeline(mode);
+}
+
+static void de2_crtc_disable(struct drm_crtc *crtc)
+{
+	struct lcd *lcd = crtc_to_lcd(crtc);
+
+	DRM_DEBUG_DRIVER("\n");
+
+	tcon_write(lcd->mmio, tcon1_ctl,
+		tcon_read(lcd->mmio, tcon1_ctl) & ~TCON1_CTL_TCON_En);
+}
+
+static const struct drm_crtc_funcs de2_crtc_funcs = {
+	.destroy	= drm_crtc_cleanup,
+	.set_config	= drm_atomic_helper_set_config,
+	.page_flip	= drm_atomic_helper_page_flip,
+	.reset		= drm_atomic_helper_crtc_reset,
+	.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+};
+
+static const struct drm_crtc_helper_funcs de2_crtc_helper_funcs = {
+	.enable		= de2_crtc_enable,
+	.disable	= de2_crtc_disable,
+};
+
+static void de2_tcon_enable(struct lcd *lcd)
+{
+	DRM_DEBUG_DRIVER("\n");
+
+	tcon_write(lcd->mmio, tcon0_ctl,
+		tcon_read(lcd->mmio, tcon0_ctl) & ~TCON0_CTL_TCON_En);
+	tcon_write(lcd->mmio, tcon1_ctl,
+		tcon_read(lcd->mmio, tcon1_ctl) & ~TCON1_CTL_TCON_En);
+	tcon_write(lcd->mmio, gctl,
+		tcon_read(lcd->mmio, gctl) & ~TCON_GCTL_TCON_En);
+
+	tcon_write(lcd->mmio, gint0,
+		tcon_read(lcd->mmio, gint0) & ~(TCON_GINT0_TCON1_Vb_Int_En |
+						TCON_GINT0_TCON1_Vb_Int_Flag));
+
+	tcon_write(lcd->mmio, gctl,
+		tcon_read(lcd->mmio, gctl) | TCON_GCTL_TCON_En);
+}
+
+static int de2_crtc_init(struct drm_device *drm, struct lcd *lcd)
+{
+	struct drm_crtc *crtc = &lcd->crtc;
+	int ret;
+
+	ret = de2_plane_init(drm, lcd);
+	if (ret < 0)
+		return ret;
+
+	ret = drm_crtc_init_with_planes(drm, crtc,
+					&lcd->planes[DE2_PRIMARY_PLANE],
+					&lcd->planes[DE2_CURSOR_PLANE],
+					&de2_crtc_funcs, NULL);
+	if (ret < 0)
+		return ret;
+
+	de2_tcon_enable(lcd);
+
+	de2_de_enable(lcd->priv, lcd->num);
+
+	drm_crtc_helper_add(crtc, &de2_crtc_helper_funcs);
+
+	return 0;
+}
+
+/*
+ * device init
+ */
+static int de2_lcd_bind(struct device *dev, struct device *master,
+			void *data)
+{
+	struct drm_device *drm = data;
+	struct priv *priv = drm->dev_private;
+	struct lcd *lcd = dev_get_drvdata(dev);
+	int ret;
+
+	lcd->priv = priv;
+
+	ret = de2_crtc_init(drm, lcd);
+	if (ret < 0) {
+		dev_err(dev, "failed to init the crtc\n");
+		return ret;
+	}
+
+	priv->lcds[lcd->num] = lcd;
+
+	return 0;
+}
+
+static void de2_lcd_unbind(struct device *dev, struct device *master,
+			void *data)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct lcd *lcd = platform_get_drvdata(pdev);
+
+	if (lcd->mmio) {
+		if (lcd->priv)
+			de2_de_disable(lcd->priv, lcd->num);
+		tcon_write(lcd->mmio, gctl,
+			tcon_read(lcd->mmio, gctl) & ~TCON_GCTL_TCON_En);
+	}
+}
+
+static const struct component_ops de2_lcd_ops = {
+	.bind = de2_lcd_bind,
+	.unbind = de2_lcd_unbind,
+};
+
+static int de2_lcd_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node, *tmp, *parent, *port;
+	struct lcd *lcd;
+	struct resource *res;
+	int id, ret;
+
+	id = of_alias_get_id(np, "lcd");
+	if (id < 0) {
+		dev_err(dev, "no alias for lcd\n");
+		id = 0;
+	}
x+	lcd = devm_kzalloc(dev, sizeof *lcd, GFP_KERNEL);
+	if (!lcd) {
+		dev_err(dev, "failed to allocate private data\n");
+		return -ENOMEM;
+	}
+	dev_set_drvdata(dev, lcd);
+	lcd->dev = dev;
+	lcd->num = id;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(dev, "failed to get memory resource\n");
+		return -EINVAL;
+	}
+
+	lcd->mmio = devm_ioremap_resource(dev, res);
+	if (IS_ERR(lcd->mmio)) {
+		dev_err(dev, "failed to map registers\n");
+		return PTR_ERR(lcd->mmio);
+	}
+
+	snprintf(lcd->name, sizeof(lcd->name), "sunxi-lcd%d", id);
+
+	/* possible CRTCs */
+	parent = np;
+	tmp = of_get_child_by_name(np, "ports");
+	if (tmp)
+		parent = tmp;
+	port = of_get_child_by_name(parent, "port");
+	of_node_put(tmp);
+	if (!port) {
+		dev_err(dev, "no port node\n");
+		return -ENXIO;
+	}
+	lcd->crtc.port = port;
+
+	lcd->gate = devm_clk_get(dev, "gate");
+	if (IS_ERR(lcd->gate)) {
+		dev_err(dev, "gate clock err %d\n", (int) PTR_ERR(lcd->gate));
+		ret = PTR_ERR(lcd->gate);
+		goto err;
+	}
+
+	lcd->clk = devm_clk_get(dev, "clock");
+	if (IS_ERR(lcd->clk)) {
+		dev_err(dev, "video clock err %d\n", (int) PTR_ERR(lcd->clk));
+		ret = PTR_ERR(lcd->clk);
+		goto err;
+	}
+
+	lcd->rstc = devm_reset_control_get(dev, NULL);
+	if (IS_ERR(lcd->rstc)) {
+		dev_err(dev, "reset controller err %d\n",
+				(int) PTR_ERR(lcd->rstc));
+		ret = PTR_ERR(lcd->rstc);
+		goto err;
+	}
+
+	ret = clk_prepare_enable(lcd->clk);
+	if (ret)
+		goto err;
+	ret = clk_prepare_enable(lcd->gate);
+	if (ret)
+		goto err;
+
+	ret = reset_control_deassert(lcd->rstc);
+	if (ret) {
+		dev_err(dev, "reset deassert err %d\n", ret);
+		goto err;
+	}
+
+	return component_add(&pdev->dev, &de2_lcd_ops);
+
+err:
+	clk_disable_unprepare(lcd->gate);
+	clk_disable_unprepare(lcd->clk);
+	of_node_put(lcd->crtc.port);
+	return ret;
+}
+
+static int de2_lcd_remove(struct platform_device *pdev)
+{
+	struct lcd *lcd = platform_get_drvdata(pdev);
+
+	component_del(&pdev->dev, &de2_lcd_ops);
+
+	if (!IS_ERR_OR_NULL(lcd->rstc))
+		reset_control_assert(lcd->rstc);
+	clk_disable_unprepare(lcd->gate);
+	clk_disable_unprepare(lcd->clk);
+	of_node_put(lcd->crtc.port);
+
+	return 0;
+}
+
+static const struct of_device_id de2_lcd_ids[] = {
+	{ .compatible = "allwinner,sun8i-h3-lcd", },
+	{ }
+};
+
+struct platform_driver de2_lcd_platform_driver = {
+	.probe = de2_lcd_probe,
+	.remove = de2_lcd_remove,
+	.driver = {
+		.name = "sun8i-h3-lcd",
+		.of_match_table = of_match_ptr(de2_lcd_ids),
+	},
+};
diff --git a/drivers/gpu/drm/sunxi/de2_crtc.h b/drivers/gpu/drm/sunxi/de2_crtc.h
new file mode 100644
index 0000000..789bd6e
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/de2_crtc.h
@@ -0,0 +1,61 @@
+#ifndef __DE2_CRTC_H__
+#define __DE2_CRTC_H__
+/*
+ * Copyright (C) 2016 Jean-Fran??ois Moine
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <linux/clk.h>
+#include <linux/reset.h>
+#include <drm/drm_plane_helper.h>
+
+struct priv;
+
+enum de2_plane2 {
+	DE2_PRIMARY_PLANE,
+	DE2_CURSOR_PLANE,
+	DE2_N_PLANES,
+};
+struct lcd {
+	void __iomem *mmio;
+
+	struct device *dev;
+	struct drm_crtc crtc;
+	struct priv *priv;	/* DRM/DE private data */
+
+	int num;		/* LCD index 0/1 */
+
+	struct clk *clk;
+	struct clk *gate;
+	struct reset_control *rstc;
+
+	char name[16];
+
+	struct drm_pending_vblank_event *event;
+
+	struct drm_plane planes[DE2_N_PLANES];
+};
+
+#define crtc_to_lcd(x) container_of(x, struct lcd, crtc)
+
+/* in de2_de.c */
+void de2_de_enable(struct priv *priv, int lcd_num);
+void de2_de_disable(struct priv *priv, int lcd_num);
+void de2_de_hw_init(struct priv *priv, int lcd_num);
+void de2_de_panel_init(struct priv *priv, int lcd_num,
+			struct drm_display_mode *mode);
+void de2_de_plane_disable(struct priv *priv,
+			int lcd_num, int plane_ix);
+void de2_de_plane_update(struct priv *priv,
+			int lcd_num, int plane_ix,
+			struct drm_plane_state *state,
+			struct drm_plane_state *old_state);
+
+/* in de2_plane.c */
+int de2_plane_init(struct drm_device *drm, struct lcd *lcd);
+
+#endif /* __DE2_CRTC_H__ */
diff --git a/drivers/gpu/drm/sunxi/de2_de.c b/drivers/gpu/drm/sunxi/de2_de.c
new file mode 100644
index 0000000..17fac25
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/de2_de.c
@@ -0,0 +1,505 @@
+/*
+ * ALLWINNER DRM driver - Display Engine 2
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moinejf at free.fr>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <asm/io.h>
+#include <drm/drm_gem_cma_helper.h>
+
+#include "de2_drm.h"
+#include "de2_crtc.h"
+
+static DEFINE_SPINLOCK(de_lock);
+
+/* I/O map */
+
+#define DE_MOD_REG 0x0000	/* 1 bit per LCD */
+#define DE_GATE_REG 0x0004
+#define DE_RESET_REG 0x0008
+#define DE_DIV_REG 0x000c	/* 4 bits per LCD */
+#define DE_SEL_REG 0x0010
+
+#define DE_MUX0_BASE 0x00100000
+#define DE_MUX1_BASE 0x00200000
+
+/* MUX registers (addr / MUX base) */
+#define DE_MUX_GLB_REGS 0x00000		/* global control */
+#define DE_MUX_BLD_REGS 0x01000		/* alpha blending */
+#define DE_MUX_CHAN_REGS 0x02000	/* VI/UI overlay channels */
+#define		DE_MUX_CHAN_SZ 0x1000	/* size of a channel */
+#define DE_MUX_VSU_REGS 0x20000		/* VSU */
+#define DE_MUX_GSU1_REGS 0x40000	/* GSUs */
+#define DE_MUX_GSU2_REGS 0x60000
+#define DE_MUX_GSU3_REGS 0x80000
+#define DE_MUX_FCE_REGS 0xa0000		/* FCE */
+#define DE_MUX_BWS_REGS 0xa2000		/* BWS */
+#define DE_MUX_LTI_REGS 0xa4000		/* LTI */
+#define DE_MUX_PEAK_REGS 0xa6000	/* PEAK */
+#define DE_MUX_ASE_REGS 0xa8000		/* ASE */
+#define DE_MUX_FCC_REGS 0xaa000		/* FCC */
+#define DE_MUX_DCSC_REGS 0xb0000	/* DCSC */
+
+/* global control */
+struct de_glb {
+	u32 ctl;
+#define		DE_MUX_GLB_CTL_rt_en BIT(0)
+#define		DE_MUX_GLB_CTL_finish_irq_en BIT(4)
+#define		DE_MUX_GLB_CTL_rtwb_port BIT(12)
+	u32 status;
+	u32 dbuff;
+	u32 size;
+};
+
+/* alpha blending */
+struct de_bld {
+	u32 fcolor_ctl;			/* 00 */
+	struct {
+		u32 fcolor;
+		u32 insize;
+		u32 offset;
+		u32 dum;
+	} attr[4];
+	u32 dum0[15];			/* (end of clear offset) */
+	u32 route;			/* 80 */
+	u32 premultiply;
+	u32 bkcolor;
+	u32 output_size;
+	u32 bld_mode[4];
+	u32 dum1[4];
+	u32 ck_ctl;			/* b0 */
+	u32 ck_cfg;
+	u32 dum2[2];
+	u32 ck_max[4];
+	u32 dum3[4];
+	u32 ck_min[4];
+	u32 dum4[3];
+	u32 out_ctl;			/* fc */
+};
+
+/* VI channel */
+struct de_vi {
+	struct {
+		u32 attr;
+#define			VI_CFG_ATTR_en BIT(0)
+#define			VI_CFG_ATTR_fcolor_en BIT(4)
+#define			VI_CFG_ATTR_fmt_SHIFT 8
+#define			VI_CFG_ATTR_fmt_MASK GENMASK(12, 8)
+#define			VI_CFG_ATTR_ui_sel BIT(15)
+#define			VI_CFG_ATTR_top_down BIT(23)
+		u32 size;
+		u32 coord;
+		u32 pitch[3];
+		u32 top_laddr[3];
+		u32 bot_laddr[3];
+	} cfg[4];
+	u32 fcolor[4];			/* c0 */
+	u32 top_haddr[3];		/* d0 */
+	u32 bot_haddr[3];		/* dc */
+	u32 ovl_size[2];		/* e8 */
+	u32 hori[2];			/* f0 */
+	u32 vert[2];			/* f8 */
+};
+
+/* UI channel */
+struct de_ui {
+	struct {
+		u32 attr;
+#define			UI_CFG_ATTR_en BIT(0)
+#define			UI_CFG_ATTR_alpmod_SHIFT 1
+#define			UI_CFG_ATTR_alpmod_MASK GENMASK(2, 1)
+#define			UI_CFG_ATTR_fcolor_en BIT(4)
+#define			UI_CFG_ATTR_fmt_SHIFT 8
+#define			UI_CFG_ATTR_fmt_MASK GENMASK(12, 8)
+#define			UI_CFG_ATTR_top_down BIT(23)
+#define			UI_CFG_ATTR_alpha_SHIFT 24
+#define			UI_CFG_ATTR_alpha_MASK GENMASK(31, 24)
+		u32 size;
+		u32 coord;
+		u32 pitch;
+		u32 top_laddr;
+		u32 bot_laddr;
+		u32 fcolor;
+		u32 dum;
+	} cfg[4];			/* 00 */
+	u32 top_haddr;			/* 80 */
+	u32 bot_haddr;
+	u32 ovl_size;			/* 88 */
+};
+
+#define DE_CORE_CLK_RATE 432000000
+
+/* coordinates and sizes */
+#define XY(x, y) (((y) << 16) | (x))
+#define WH(w, h) (((h - 1) << 16) | (w - 1))
+
+/* UI video formats */
+#define DE2_FORMAT_ARGB_8888 0
+#define DE2_FORMAT_XRGB_8888 4
+#define DE2_FORMAT_RGB_888 8
+#define DE2_FORMAT_BGR_888 9
+
+#define glb_read(base, member) \
+	readl_relaxed(base + offsetof(struct de_glb, member))
+#define glb_write(base, member, data) \
+	writel_relaxed(data, base + offsetof(struct de_glb, member))
+#define bld_read(base, member) \
+	readl_relaxed(base + offsetof(struct de_bld, member))
+#define bld_write(base, member, data) \
+	writel_relaxed(data, base + offsetof(struct de_bld, member))
+#define ui_read(base, member) \
+	readl_relaxed(base + offsetof(struct de_ui, member))
+#define ui_write(base, member, data) \
+	writel_relaxed(data, base + offsetof(struct de_ui, member))
+#define vi_read(base, member) \
+	readl_relaxed(base + offsetof(struct de_vi, member))
+#define vi_write(base, member, data) \
+	writel_relaxed(data, base + offsetof(struct de_vi, member))
+
+static const struct {
+	char chan;
+	char layer;
+} plane2layer[DE2_N_PLANES] = {
+	[DE2_PRIMARY_PLANE] = {.chan = 1, .layer = 0,},
+	[DE2_CURSOR_PLANE] = {.chan = 2, .layer = 0,},
+};
+
+static inline void de_write(struct priv *priv, int reg, u32 data)
+{
+	writel_relaxed(data, priv->mmio + reg);
+}
+
+static inline u32 de_read(struct priv *priv, int reg)
+{
+	return readl_relaxed(priv->mmio + reg);
+}
+
+static void de_lcd_select(struct priv *priv,
+			int lcd_num,
+			void __iomem *mux_o)
+{
+	u32 data;
+
+	/* select the LCD */
+	data = de_read(priv, DE_SEL_REG);
+	if (lcd_num == 0)
+		data &= ~1;
+	else
+		data |= 1;
+	de_write(priv, DE_SEL_REG, data);
+
+	/* double register switch */
+	glb_write(mux_o + DE_MUX_GLB_REGS, dbuff, 1);
+}
+
+void de2_de_plane_update(struct priv *priv,
+			int lcd_num, int plane_ix,
+			struct drm_plane_state *state,
+			struct drm_plane_state *old_state)
+{
+	struct drm_framebuffer *fb = state->fb;
+	struct drm_gem_cma_object *gem;
+	void __iomem *mux_o = priv->mmio;
+	void __iomem *chan_o;
+	u32 size = WH(state->crtc_w, state->crtc_h);
+	u32 coord = XY(state->crtc_x, state->crtc_y);
+	u32 screen_size;
+	u32 data;
+	int chan, layer;
+	unsigned fmt, alpha_glob;
+	unsigned long flags;
+
+	mux_o += (lcd_num == 0) ? DE_MUX0_BASE : DE_MUX1_BASE;
+
+	chan = plane2layer[plane_ix].chan;
+	layer = plane2layer[plane_ix].layer;
+
+	chan_o = mux_o;
+	chan_o += DE_MUX_CHAN_REGS + DE_MUX_CHAN_SZ * chan;
+
+	if (fb == old_state->fb
+	 && ui_read(chan_o, cfg[layer].attr) != 0) {
+		spin_lock_irqsave(&de_lock, flags);
+		de_lcd_select(priv, lcd_num, mux_o);
+		ui_write(chan_o, cfg[layer].coord, coord);
+		spin_unlock_irqrestore(&de_lock, flags);
+		return;
+	}
+
+	gem = drm_fb_cma_get_gem_obj(fb, 0);
+
+	alpha_glob = 0;
+	switch (fb->pixel_format) {
+	case DRM_FORMAT_ARGB8888:
+		fmt = DE2_FORMAT_ARGB_8888;
+		break;
+	case DRM_FORMAT_XRGB8888:
+		fmt = DE2_FORMAT_XRGB_8888;
+		alpha_glob = 1;
+		break;
+	case DRM_FORMAT_RGB888:
+		fmt = DE2_FORMAT_RGB_888;
+		break;
+	case DRM_FORMAT_BGR888:
+		fmt = DE2_FORMAT_BGR_888;
+		break;
+	default:
+		pr_err("format %.4s not yet treated\n",
+			(char *) &fb->pixel_format);
+		return;
+	}
+	
+	spin_lock_irqsave(&de_lock, flags);
+
+	if (plane_ix == DE2_PRIMARY_PLANE)
+		screen_size = size;
+	else
+		screen_size = glb_read(mux_o + DE_MUX_GLB_REGS, size);
+
+	de_lcd_select(priv, lcd_num, mux_o);
+
+	data = UI_CFG_ATTR_en |
+			(fmt << UI_CFG_ATTR_fmt_SHIFT);
+	if (alpha_glob)
+		data |= (1 << UI_CFG_ATTR_alpmod_SHIFT) |
+			(0xff << UI_CFG_ATTR_alpha_SHIFT);
+	ui_write(chan_o, cfg[layer].attr, data);
+	ui_write(chan_o, cfg[layer].size, size);
+	ui_write(chan_o, cfg[layer].coord, coord);
+	ui_write(chan_o, cfg[layer].pitch, fb->pitches[0]);
+	ui_write(chan_o, cfg[layer].top_laddr,
+			gem->paddr + fb->offsets[0]);
+	ui_write(chan_o, ovl_size, screen_size);
+
+	if (plane_ix == DE2_PRIMARY_PLANE)
+		bld_write(mux_o + DE_MUX_BLD_REGS,
+					fcolor_ctl, 0x0101);
+	else
+		bld_write(mux_o + DE_MUX_BLD_REGS,
+					fcolor_ctl, 0x0301);
+
+	spin_unlock_irqrestore(&de_lock, flags);
+}
+
+void de2_de_plane_disable(struct priv *priv,
+			int lcd_num, int plane_ix)
+{
+	void __iomem *mux_o = priv->mmio;
+	void __iomem *chan_o;
+	int chan, layer;
+	unsigned long flags;
+
+	chan = plane2layer[plane_ix].chan;
+	layer = plane2layer[plane_ix].layer;
+
+	mux_o += (lcd_num == 0) ? DE_MUX0_BASE : DE_MUX1_BASE;
+	chan_o = mux_o + DE_MUX_CHAN_REGS + DE_MUX_CHAN_SZ * chan;
+
+	spin_lock_irqsave(&de_lock, flags);
+
+	de_lcd_select(priv, lcd_num, mux_o);
+
+	ui_write(chan_o, cfg[layer].attr, 0);
+	bld_write(mux_o + DE_MUX_BLD_REGS, fcolor_ctl, 0x0101);
+
+	spin_unlock_irqrestore(&de_lock, flags);
+}
+
+void de2_de_panel_init(struct priv *priv, int lcd_num,
+			struct drm_display_mode *mode)
+{
+	void __iomem *mux_o = priv->mmio;
+	u32 size = WH(mode->hdisplay, mode->vdisplay);
+	unsigned i;
+	unsigned long flags;
+
+	mux_o += (lcd_num == 0) ? DE_MUX0_BASE : DE_MUX1_BASE;
+
+	DRM_DEBUG_DRIVER("%dx%d\n", mode->hdisplay, mode->vdisplay);
+
+	spin_lock_irqsave(&de_lock, flags);
+
+	de_lcd_select(priv, lcd_num, mux_o);
+
+	glb_write(mux_o + DE_MUX_GLB_REGS, size, size);
+
+	/* set alpha blending */
+	for (i = 0; i < 4; i++)
+		bld_write(mux_o + DE_MUX_BLD_REGS, attr[i].insize, size);
+	bld_write(mux_o + DE_MUX_BLD_REGS, output_size, size);
+	bld_write(mux_o + DE_MUX_BLD_REGS, out_ctl,
+			mode->flags & DRM_MODE_FLAG_INTERLACE ? 2 : 0);
+
+	spin_unlock_irqrestore(&de_lock, flags);
+}
+
+void de2_de_enable(struct priv *priv, int lcd_num)
+{
+	void __iomem *mux_o = priv->mmio;
+	unsigned chan;
+	u32 size = WH(1920, 1080);
+	u32 data;
+	unsigned long flags;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	data = 1 << lcd_num;			/* 1 bit / lcd */
+	de_write(priv, DE_RESET_REG,
+			de_read(priv, DE_RESET_REG) | data);
+	de_write(priv, DE_GATE_REG,
+			de_read(priv, DE_GATE_REG) | data);
+	de_write(priv, DE_MOD_REG,
+			de_read(priv, DE_MOD_REG) | data);
+
+	mux_o += (lcd_num == 0) ? DE_MUX0_BASE : DE_MUX1_BASE;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	spin_lock_irqsave(&de_lock, flags);
+
+	/* select the LCD */
+	data = de_read(priv, DE_SEL_REG);
+	if (lcd_num == 0)
+		data &= ~1;
+	else
+		data |= 1;
+	de_write(priv, DE_SEL_REG, data);
+
+	/* start init */
+	glb_write(mux_o + DE_MUX_GLB_REGS, ctl,
+		DE_MUX_GLB_CTL_rt_en | DE_MUX_GLB_CTL_rtwb_port);
+	glb_write(mux_o + DE_MUX_GLB_REGS, status, 0);
+	glb_write(mux_o + DE_MUX_GLB_REGS, dbuff, 1);	/* dble reg switch */
+	glb_write(mux_o + DE_MUX_GLB_REGS, size, size);
+
+	/* clear the VI/UI channels */
+	for (chan = 0; chan < 4; chan++) {
+		void __iomem *chan_o = mux_o + DE_MUX_CHAN_REGS +
+				DE_MUX_CHAN_SZ * chan;
+
+		if (chan == 0)
+			memset_io(chan_o, 0, sizeof(struct de_vi));
+		else
+			memset_io(chan_o, 0, sizeof(struct de_ui));
+		if (chan == 2 && lcd_num != 0)
+			break;		/* lcd1 only 1 VI and 1 UI */
+	}
+
+	/* clear and set alpha blending */
+	memset_io(mux_o + DE_MUX_BLD_REGS, 0, offsetof(struct de_bld, dum0));
+	bld_write(mux_o + DE_MUX_BLD_REGS, fcolor_ctl, 0x00000101);
+						/* fcolor for primary */
+	bld_write(mux_o + DE_MUX_BLD_REGS, route, 0x0021);
+					/* prepare route primary and cursor */
+	bld_write(mux_o + DE_MUX_BLD_REGS, premultiply, 0);
+	bld_write(mux_o + DE_MUX_BLD_REGS, bkcolor, 0xff000000);
+	bld_write(mux_o + DE_MUX_BLD_REGS, bld_mode[0], 0x03010301);
+								/* SRCOVER */
+	bld_write(mux_o + DE_MUX_BLD_REGS, bld_mode[1], 0x03010301);
+	bld_write(mux_o + DE_MUX_BLD_REGS, bld_mode[2], 0x03010301);
+	bld_write(mux_o + DE_MUX_BLD_REGS, out_ctl, 0);
+
+	/* disable the enhancements */
+	writel_relaxed(0, mux_o + DE_MUX_VSU_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_GSU1_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_GSU2_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_GSU3_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_FCE_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_BWS_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_LTI_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_PEAK_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_ASE_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_FCC_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_DCSC_REGS);
+
+	spin_unlock_irqrestore(&de_lock, flags);
+}
+
+void de2_de_disable(struct priv *priv, int lcd_num)
+{
+	u32 data;
+
+	data = ~(1 << lcd_num);
+	de_write(priv, DE_MOD_REG,
+			de_read(priv, DE_MOD_REG) & data);
+	de_write(priv, DE_GATE_REG,
+			de_read(priv, DE_GATE_REG) & data);
+	de_write(priv, DE_RESET_REG,
+			de_read(priv, DE_RESET_REG) & data);
+}
+
+int de2_de_init(struct priv *priv, struct device *dev)
+{
+	struct resource *res;
+	int ret;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	res = platform_get_resource(to_platform_device(dev),
+				IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(dev, "failed to get memory resource\n");
+		return -EINVAL;
+	}
+
+	priv->mmio = devm_ioremap_resource(dev, res);
+	if (IS_ERR(priv->mmio)) {
+		dev_err(dev, "failed to map registers\n");
+		return PTR_ERR(priv->mmio);
+	}
+
+	priv->gate = devm_clk_get(dev, "gate");
+	if (IS_ERR(priv->gate)) {
+		dev_err(dev, "gate clock err %d\n", (int) PTR_ERR(priv->gate));
+		return PTR_ERR(priv->gate);
+	}
+
+	priv->clk = devm_clk_get(dev, "clock");
+	if (IS_ERR(priv->clk)) {
+		dev_err(dev, "video clock err %d\n", (int) PTR_ERR(priv->clk));
+		return PTR_ERR(priv->clk);
+	}
+
+	priv->rstc = devm_reset_control_get(dev, NULL);
+	if (IS_ERR(priv->rstc)) {
+		dev_err(dev, "reset controller err %d\n",
+				(int) PTR_ERR(priv->rstc));
+		return PTR_ERR(priv->rstc);
+	}
+
+	ret = clk_prepare_enable(priv->clk);
+	if (ret)
+		return ret;
+	ret = clk_prepare_enable(priv->gate);
+	if (ret)
+		goto err_gate;
+
+	/* the DE has a fixed clock rate */
+	clk_set_rate(priv->clk, DE_CORE_CLK_RATE);
+
+	ret = reset_control_deassert(priv->rstc);
+	if (ret) {
+		dev_err(dev, "reset deassert err %d\n", ret);
+		goto err_reset;
+	}
+
+	return 0;
+
+err_reset:
+	clk_disable_unprepare(priv->gate);
+err_gate:
+	clk_disable_unprepare(priv->clk);
+	return ret;
+}
+
+void de2_de_cleanup(struct priv *priv)
+{
+	reset_control_assert(priv->rstc);
+	clk_disable_unprepare(priv->gate);
+	clk_disable_unprepare(priv->clk);
+}
diff --git a/drivers/gpu/drm/sunxi/de2_drm.h b/drivers/gpu/drm/sunxi/de2_drm.h
new file mode 100644
index 0000000..1e6cf6d
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/de2_drm.h
@@ -0,0 +1,40 @@
+#ifndef __DE2_DRM_H__
+#define __DE2_DRM_H__
+/*
+ * Copyright (C) 2016 Jean-Fran??ois Moine
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <linux/clk.h>
+#include <linux/reset.h>
+#include <drm/drmP.h>
+#include <drm/drm_fb_cma_helper.h>
+
+struct lcd;
+
+#define N_LCDS 2
+struct priv {
+	void __iomem *mmio;
+	struct clk *clk;
+	struct clk *gate;
+	struct reset_control *rstc;
+
+	struct drm_fbdev_cma *fbdev;
+
+	struct lcd *lcds[N_LCDS];
+};
+
+/* in de2_crtc.c */
+int de2_enable_vblank(struct drm_device *drm, unsigned crtc);
+void de2_disable_vblank(struct drm_device *drm, unsigned crtc);
+extern struct platform_driver de2_lcd_platform_driver;
+
+/* in de2_de.c */
+int de2_de_init(struct priv *priv, struct device *dev);
+void de2_de_cleanup(struct priv *priv);
+
+#endif /* __DE2_DRM_H__ */
diff --git a/drivers/gpu/drm/sunxi/de2_drv.c b/drivers/gpu/drm/sunxi/de2_drv.c
new file mode 100644
index 0000000..bfb9100
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/de2_drv.c
@@ -0,0 +1,377 @@
+/*
+ * Allwinner DRM driver - DE2 DRM driver
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moinejf at free.fr>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/pm.h>
+#include <linux/pm_runtime.h>
+#include <linux/of_graph.h>
+#include <linux/component.h>
+#include <drm/drm_of.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_gem_cma_helper.h>
+
+#include "de2_drm.h"
+
+#define DRIVER_NAME	"sunxi-de2"
+#define DRIVER_DESC	"Allwinner DRM DE2"
+#define DRIVER_DATE	"20160201"
+#define DRIVER_MAJOR	1
+#define DRIVER_MINOR	0
+
+static void de2_fb_output_poll_changed(struct drm_device *drm)
+{
+	struct priv *priv = drm->dev_private;
+
+	if (priv->fbdev)
+		drm_fbdev_cma_hotplug_event(priv->fbdev);
+}
+
+static const struct drm_mode_config_funcs de2_mode_config_funcs = {
+	.fb_create = drm_fb_cma_create,
+	.output_poll_changed = de2_fb_output_poll_changed,
+	.atomic_check = drm_atomic_helper_check,
+	.atomic_commit = drm_atomic_helper_commit,
+};
+
+/*
+ * DRM operations:
+ */
+static void de2_lastclose(struct drm_device *drm)
+{
+	struct priv *priv = drm->dev_private;
+
+	if (priv->fbdev)
+		drm_fbdev_cma_restore_mode(priv->fbdev);
+}
+
+static const struct file_operations de2_fops = {
+	.owner		= THIS_MODULE,
+	.open		= drm_open,
+	.release	= drm_release,
+	.unlocked_ioctl	= drm_ioctl,
+	.poll		= drm_poll,
+	.read		= drm_read,
+	.llseek		= no_llseek,
+	.mmap		= drm_gem_cma_mmap,
+};
+
+static struct drm_driver de2_drm_driver = {
+	.driver_features	= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
+					DRIVER_ATOMIC,
+	.lastclose		= de2_lastclose,
+	.get_vblank_counter	= drm_vblank_no_hw_counter,
+	.enable_vblank		= de2_enable_vblank,
+	.disable_vblank		= de2_disable_vblank,
+	.gem_free_object	= drm_gem_cma_free_object,
+	.gem_vm_ops		= &drm_gem_cma_vm_ops,
+	.prime_handle_to_fd	= drm_gem_prime_handle_to_fd,
+	.prime_fd_to_handle	= drm_gem_prime_fd_to_handle,
+	.gem_prime_import	= drm_gem_prime_import,
+	.gem_prime_export	= drm_gem_prime_export,
+	.gem_prime_get_sg_table	= drm_gem_cma_prime_get_sg_table,
+	.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
+	.gem_prime_vmap		= drm_gem_cma_prime_vmap,
+	.gem_prime_vunmap	= drm_gem_cma_prime_vunmap,
+	.gem_prime_mmap		= drm_gem_cma_prime_mmap,
+	.dumb_create		= drm_gem_cma_dumb_create,
+	.dumb_map_offset	= drm_gem_cma_dumb_map_offset,
+	.dumb_destroy		= drm_gem_dumb_destroy,
+	.fops			= &de2_fops,
+	.name			= DRIVER_NAME,
+	.desc			= DRIVER_DESC,
+	.date			= DRIVER_DATE,
+	.major			= DRIVER_MAJOR,
+	.minor			= DRIVER_MINOR,
+};
+
+#ifdef CONFIG_PM_SLEEP
+/*
+ * Power management
+ */
+static int de2_pm_suspend(struct device *dev)
+{
+	struct drm_device *drm = dev_get_drvdata(dev);
+
+	drm_kms_helper_poll_disable(drm);
+	return 0;
+}
+
+static int de2_pm_resume(struct device *dev)
+{
+	struct drm_device *drm = dev_get_drvdata(dev);
+
+	drm_kms_helper_poll_enable(drm);
+	return 0;
+}
+#endif
+
+static const struct dev_pm_ops de2_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(de2_pm_suspend, de2_pm_resume)
+};
+
+/*
+ * Platform driver
+ */
+
+static int de2_drm_bind(struct device *dev)
+{
+	struct drm_device *drm;
+	struct priv *priv;
+	int ret;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	drm = drm_dev_alloc(&de2_drm_driver, dev);
+	if (!drm)
+		return -ENOMEM;
+
+	ret = drm_dev_set_unique(drm, dev_name(dev));
+	if (ret < 0)
+		goto out1;
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv) {
+		dev_err(dev, "failed to allocate private area\n");
+		ret = -ENOMEM;
+		goto out1;
+	}
+
+	dev_set_drvdata(dev, drm);
+	drm->dev_private = priv;
+
+	drm_mode_config_init(drm);
+	drm->mode_config.min_width = 32;	/* needed for cursor */
+	drm->mode_config.min_height = 32;
+	drm->mode_config.max_width = 1920;
+	drm->mode_config.max_height = 1080;
+	drm->mode_config.funcs = &de2_mode_config_funcs;
+
+	ret = drm_dev_register(drm, 0);
+	if (ret < 0)
+		goto out2;
+
+	/* initialize the display engine */
+	ret = de2_de_init(priv, dev);
+	if (ret)
+		goto out3;
+
+	/* start the subdevices */
+	ret = component_bind_all(dev, drm);
+	if (ret < 0)
+		goto out3;
+
+	DRM_DEBUG_DRIVER("%d crtcs %d connectors\n",
+			 drm->mode_config.num_crtc,
+			 drm->mode_config.num_connector);
+
+	ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
+	if (ret < 0)
+		dev_warn(dev, "failed to initialize vblank\n");
+
+	drm_mode_config_reset(drm);
+
+	priv->fbdev = drm_fbdev_cma_init(drm,
+					32,	/* bpp */
+					drm->mode_config.num_crtc,
+					drm->mode_config.num_connector);
+	if (IS_ERR(priv->fbdev)) {
+		ret = PTR_ERR(priv->fbdev);
+		priv->fbdev = NULL;
+		goto out4;
+	}
+
+	drm_kms_helper_poll_init(drm);
+
+	return 0;
+
+out4:
+	component_unbind_all(dev, drm);
+out3:
+	drm_dev_unregister(drm);
+out2:
+	kfree(priv);
+out1:
+	drm_dev_unref(drm);
+	return ret;
+}
+
+static void de2_drm_unbind(struct device *dev)
+{
+	struct drm_device *drm = dev_get_drvdata(dev);
+	struct priv *priv = drm->dev_private;
+
+	if (priv)
+		drm_fbdev_cma_fini(priv->fbdev);
+
+	drm_kms_helper_poll_fini(drm);
+
+	component_unbind_all(dev, drm);
+
+	drm_dev_unregister(drm);
+
+	drm_mode_config_cleanup(drm);
+
+	if (priv) {
+		de2_de_cleanup(priv);
+		kfree(priv);
+	}
+
+	drm_dev_unref(drm);
+}
+
+static const struct component_master_ops de2_drm_comp_ops = {
+	.bind = de2_drm_bind,
+	.unbind = de2_drm_unbind,
+};
+
+static int compare_of(struct device *dev, void *data)
+{
+	return dev->of_node == data;
+}
+
+static int de2_drm_add_components(struct device *dev,
+				  int (*compare_of)(struct device *, void *),
+				  const struct component_master_ops *m_ops)
+{
+	struct device_node *ep, *port, *remote;
+	struct component_match *match = NULL;
+	int i;
+
+	if (!dev->of_node)
+		return -EINVAL;
+
+	/* bind the CRTCs */
+	for (i = 0; ; i++) {
+		port = of_parse_phandle(dev->of_node, "ports", i);
+		if (!port)
+			break;
+
+		if (!of_device_is_available(port->parent)) {
+			of_node_put(port);
+			continue;
+		}
+
+		component_match_add(dev, &match, compare_of, port->parent);
+		of_node_put(port);
+	}
+
+	if (i == 0) {
+		dev_err(dev, "missing 'ports' property\n");
+		return -ENODEV;
+	}
+	if (!match) {
+		dev_err(dev, "no available port\n");
+		return -ENODEV;
+	}
+
+	/* bind the encoders/connectors */
+	for (i = 0; ; i++) {
+		port = of_parse_phandle(dev->of_node, "ports", i);
+		if (!port)
+			break;
+
+		if (!of_device_is_available(port->parent)) {
+			of_node_put(port);
+			continue;
+		}
+
+		for_each_child_of_node(port, ep) {
+			remote = of_graph_get_remote_port_parent(ep);
+			if (!remote || !of_device_is_available(remote)) {
+				of_node_put(remote);
+				continue;
+			}
+			if (!of_device_is_available(remote->parent)) {
+				dev_warn(dev,
+					 "parent device of %s is not available\n",
+					 remote->full_name);
+				of_node_put(remote);
+				continue;
+			}
+
+			component_match_add(dev, &match, compare_of, remote);
+			of_node_put(remote);
+		}
+		of_node_put(port);
+	}
+
+	return component_master_add_with_match(dev, m_ops, match);
+}
+
+static int de2_drm_probe(struct platform_device *pdev)
+{
+	int ret;
+
+	ret = de2_drm_add_components(&pdev->dev,
+				     compare_of,
+				     &de2_drm_comp_ops);
+	if (ret == -EINVAL)
+		ret = -ENXIO;
+	return ret;
+}
+
+static int de2_drm_remove(struct platform_device *pdev)
+{
+	component_master_del(&pdev->dev, &de2_drm_comp_ops);
+
+	return 0;
+}
+
+static struct of_device_id de2_drm_of_match[] = {
+	{ .compatible = "allwinner,sun8i-h3-display-engine" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, de2_drm_of_match);
+
+static struct platform_driver de2_drm_platform_driver = {
+	.probe      = de2_drm_probe,
+	.remove     = de2_drm_remove,
+	.driver     = {
+		.name = "sun8i-h3-display-engine",
+		.pm = &de2_pm_ops,
+		.of_match_table = de2_drm_of_match,
+	},
+};
+
+static int __init de2_drm_init(void)
+{
+	int ret;
+
+/* uncomment to activate the drm traces at startup time */
+/*	drm_debug = DRM_UT_CORE | DRM_UT_DRIVER | DRM_UT_KMS |
+			DRM_UT_PRIME | DRM_UT_ATOMIC; */
+
+	DRM_DEBUG_DRIVER("\n");
+
+	ret = platform_driver_register(&de2_lcd_platform_driver);
+	if (ret < 0)
+		return ret;
+
+	ret = platform_driver_register(&de2_drm_platform_driver);
+	if (ret < 0)
+		platform_driver_unregister(&de2_lcd_platform_driver);
+
+	return ret;
+}
+
+static void __exit de2_drm_fini(void)
+{
+	platform_driver_unregister(&de2_lcd_platform_driver);
+	platform_driver_unregister(&de2_drm_platform_driver);
+}
+
+module_init(de2_drm_init);
+module_exit(de2_drm_fini);
+
+MODULE_AUTHOR("Jean-Francois Moine <moinejf at free.fr>");
+MODULE_DESCRIPTION("Allwinner DE2 DRM Driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/sunxi/de2_plane.c b/drivers/gpu/drm/sunxi/de2_plane.c
new file mode 100644
index 0000000..ae3e13f
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/de2_plane.c
@@ -0,0 +1,91 @@
+/*
+ * Allwinner DRM driver - DE2 planes
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moinejf at free.fr>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_plane_helper.h>
+#include <drm/drm_crtc_helper.h>
+
+#include "de2_drm.h"
+#include "de2_crtc.h"
+
+/* plane formats */
+static const uint32_t ui_formats[] = {
+	DRM_FORMAT_ARGB8888,
+	DRM_FORMAT_XRGB8888,
+	DRM_FORMAT_RGB888,
+	DRM_FORMAT_BGR888,
+};
+
+static void de2_plane_disable(struct drm_plane *plane,
+				struct drm_plane_state *old_state)
+{
+	struct drm_crtc *crtc = old_state->crtc;
+	struct lcd *lcd = crtc_to_lcd(crtc);
+	int plane_num = plane - lcd->planes;
+
+	de2_de_plane_disable(lcd->priv, lcd->num, plane_num);
+}
+
+static void de2_plane_update(struct drm_plane *plane,
+				struct drm_plane_state *old_state)
+{
+	struct drm_plane_state *state = plane->state;
+	struct drm_crtc *crtc = state->crtc;
+	struct lcd *lcd = crtc_to_lcd(crtc);
+	struct drm_framebuffer *fb = state->fb;
+	int plane_num = plane - lcd->planes;
+
+	if (!crtc || !fb) {
+		DRM_DEBUG_DRIVER("no crtc/fb\n");
+		return;
+	}
+
+	de2_de_plane_update(lcd->priv, lcd->num, plane_num,
+			    state, old_state);
+}
+
+static const struct drm_plane_helper_funcs plane_helper_funcs = {
+	.atomic_disable = de2_plane_disable,
+	.atomic_update = de2_plane_update,
+};
+
+static const struct drm_plane_funcs plane_funcs = {
+	.update_plane = drm_atomic_helper_update_plane,
+	.disable_plane = drm_atomic_helper_disable_plane,
+	.destroy = drm_plane_cleanup,
+	.reset = drm_atomic_helper_plane_reset,
+	.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
+};
+
+int de2_plane_init(struct drm_device *drm, struct lcd *lcd)
+{
+	int ret, i;
+
+	for (i = 0; i < ARRAY_SIZE(lcd->planes); i++) {
+		ret = drm_universal_plane_init(drm, &lcd->planes[i], 0,
+					&plane_funcs,
+					ui_formats, ARRAY_SIZE(ui_formats),
+					i == DE2_PRIMARY_PLANE ?
+						DRM_PLANE_TYPE_PRIMARY :
+						DRM_PLANE_TYPE_CURSOR,
+					NULL);
+		if (ret < 0) {
+			dev_err(lcd->dev,
+				"Couldn't initialize plane err %d\n", ret);
+			return ret;
+		}
+		drm_plane_helper_add(&lcd->planes[i],
+				     &plane_helper_funcs);
+	}
+
+	return 0;
+}
-- 
2.7.0



From matthias.bgg at gmail.com  Tue Feb  2 08:50:19 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 2 Feb 2016 17:50:19 +0100
Subject: [PATCH 01/11] irqchip: sun4i: fix compilation outside of arch/arm
In-Reply-To: <56B0CC29.4060703@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-2-git-send-email-andre.przywara@arm.com>
 <56B0C768.3020805@gmail.com> <56B0CC29.4060703@arm.com>
Message-ID: <56B0DE4B.3090604@gmail.com>



On 02/02/16 16:32, Andre Przywara wrote:
> Hi,
>
> On 02/02/16 15:12, Matthias Brugger wrote:
>> On 01/02/16 18:39, Andre Przywara wrote:
>>> The Allwinner sunxi specific interrupt controller cannot be compiled
>>> for any architecture except arm:
>>
>> s/arm/arm64
>
> ???
>
> As it stands it only compiles for arm, and not arm64, so "cannot be
> compile for any architecture except arm" is the right thing to say, no?
>
> Or did I get confused by my own double negation?
>

No, it's just me who get confused. ;)
Sorry for the noise.


From andre.przywara at arm.com  Tue Feb  2 08:53:58 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 2 Feb 2016 16:53:58 +0000
Subject: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
In-Reply-To: <20160202100046.GM4652@lukather>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-6-git-send-email-andre.przywara@arm.com>
 <20160201182754.GA14737@excalibur.cnev.de> <56AFE0EC.8080207@arm.com>
 <20160202100046.GM4652@lukather>
Message-ID: <56B0DF26.10203@arm.com>

Hi,

On 02/02/16 10:00, Maxime Ripard wrote:
> Hi Andre,
> 
> On Mon, Feb 01, 2016 at 10:49:16PM +0000, Andr? Przywara wrote:
>> On 01/02/16 18:27, Karsten Merker wrote:
>>
>> Hi Karsten,
>>
>> thank you very much for your feedback!
>>
>>> On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote:
>>>> Based on the Allwinner A64 user manual and on the previous sunxi
>>>> pinctrl drivers this introduces the pin multiplex assignments for
>>>> the ARMv8 Allwinner A64 SoC.
>>>> Port A is apparently used for the fixed function DRAM controller, so
>>>> the ports start at B here (the manual mentions "n from 1 to 7", so
>>>> not starting at 0).
>>>>
>>>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>>>> ---
>>>>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
>>>>  arch/arm64/Kconfig.platforms                       |   1 +
>>>>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
>>>>  drivers/pinctrl/sunxi/Makefile                     |   1 +
>>>>  drivers/pinctrl/sunxi/pinctrl-a64.c                | 606 +++++++++++++++++++++
>>>>  5 files changed, 613 insertions(+)
>>>>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>>>> index 9213b27..9050002 100644
>>>> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>>>> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
>>>> @@ -21,6 +21,7 @@ Required properties:
>>>>    "allwinner,sun9i-a80-r-pinctrl"
>>>>    "allwinner,sun8i-a83t-pinctrl"
>>>>    "allwinner,sun8i-h3-pinctrl"
>>>> +  "allwinner,a64-pinctrl"
>>>
>>> Hello,
>>>
>>> on all other Allwinner SoCs we use the SoC family as part of the
>>> compatible, as well as in the names of the Kconfig options. To
>>> keep things consistent, I would like to propose doing the same on
>>> Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of
>>> allwinner,a64-pinctrl.
>>
>> Yes, I have been told this already. However I don't like this idea so
>> much, for the following reasons:
>> a) It is mostly redundant. The actual SoC (marketing) name is unique,
>> there is no sun6i-a20 or sun7i-a23.
> 
> At the same time, the family name is mostly valid too.
> 
> We do share some DTSI across some SoCs already by their family name
> (sun5i.dtsi for the A10s/A13/R8, sun8i-a23-a33.dtsi for the A23 and
> A33, etc.)
> 
>> b) It is not even helpful. If I got Maxime correctly, then the newer
>> sunxi generation numbers depend on the ARM _cores_ used in the SoC,
>> which is frankly the least interesting part from a Linux support
>> perspective. I would see some sense if it would reflect the generation
>> of IP blocks used, but so it is even more confusing to see that
>> sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely
>> different beast. The Allwinner marketing name tells you that, but the
>> sunxi one does not.
> 
> The opposite can be said too.
> 
> The A31 is quite different from the A33, while the A83 is much closer
> to the H3 than it is to the A80. Their marketing scheme is messy. In
> all aspects. We have a scheme that worked, I'd really like to stick
> with it.

But also H3 and A64 are closely related, still having a totally
different sunxi name.
I guess we could give examples and counter-examples for hours, and just
making it possible to have two contradicting rationales lets me think
this whole naming scheme is inconsistent ;-)
I see that it may have fulfilled a purpose in the past (sun3i-sun7i,
maybe sun8i), but I am not very happy with proliferating this into the
(arm64) future.
Allwinner A<something> is a perfectly google-able and well understood
naming, also unique. So why add some mysterious sun{4,5,6,7,8,9,50}i to it?
So I will amend identifiers/filenames where the name was just A64,
without any Allwinner reference (like in the pinctrl driver). I am in
for using sunxi as a shorthand for Allwinner, since this is a) shorter,
b) is already all over the kernel and c) doesn't give direct credit to a
company that apparently doesn't care ;-)

>> c) It is very confusing for people not dealing with it everyday. Just
>> because I own a BananaPi I know that the A20 is sun7i, but I am totally
>> lost when it comes to all the other names. And even now it took me about
>> a minute to find the appropriate Wiki page which explains part of that
>> story.
>> d) Most importantly ;-): It kills TAB completion, unless you know the
>> sunxi number, which is mostly not true as pointed out in c)
> 
> Both of these are true, but are about the DT filenames, and not the
> compatibles. I'd agree with you on this one now that we have
> per-vendor subfolders in boot/dts, but it was not the case before, and
> I'm pretty sure that to anyone that is not aware of the Allwinner SoCs
> names, having an A<number>.dtsi in arch/arm/boot/dts, it would be
> about a Cortex-A<number>, and definitely not an SoC from some random
> vendor.

I completely agree on that, but this is in
arch/arm64/boot/dts/allwinner, so it's pretty unique. Other vendors in
there seem to think the same. I also see that just an "a" as a prefix is
pretty short, so should we go with "aw" instead?
But actually I would just leave it as it is.

> So, droping it in the filenames, why not. But I'd really like to keep
> the same compatible scheme.

And I still don't get this: in the DT compatible scheme we always have a
vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. core
or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So
why should we add an arbitrary and confusing sun50i naming to it (when
it actually should be more like "sun8i-a64").

Cheers,
Andre.


From lorenzo.pieralisi at arm.com  Tue Feb  2 09:00:43 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 2 Feb 2016 17:00:43 +0000
Subject: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT
 and SLIT
In-Reply-To: <56B09344.4000100@linaro.org>
References: <1453541967-3744-1-git-send-email-guohanjun@huawei.com>
 <1453541967-3744-6-git-send-email-guohanjun@huawei.com>
 <20160201180944.GV24726@rric.localdomain>
 <56B09344.4000100@linaro.org>
Message-ID: <20160202170043.GA30358@red-moon>

On Tue, Feb 02, 2016 at 07:30:12PM +0800, Hanjun Guo wrote:

[...]

> >How about the following (similar to x86)?
> >
> >----
> >	if (!numa_off) {
> >#ifdef CONFIG_ACPI_NUMA
> >		if (!numa_init(acpi_numa_init))
> >			return 0;
> >#endif
> >#ifdef CONFIG_OF_NUMA
> >		if (!numa_init(of_numa_init))
> >			return 0;
> >#endif
> >	}
> >
> >	return numa_init(dummy_numa_init);
> >----
> >
> >Pretty straight and nice.
> >
> >Note: The !acpi_disabled check needs to be moved to the beginning of
> >acpi_numa_init(). Variable ret can be removed.
> 
> Lorenzo suggested to remove it, Lorenzo, what's your opinion here?

I do not think it is a big deal. OF is not a fall-back for ACPI,
which is what the code above may make us think, either you parse
ACPI or you parse DT.

I will have a look at the complete code to check if we can rewrite
it differently but I would not be too worried about it.

Lorenzo


From maxime.ripard at free-electrons.com  Tue Feb  2 08:58:33 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 17:58:33 +0100
Subject: [PATCH RFC 0/2] Add a display driver to the Allwinner H3
In-Reply-To: <20160119094907.2cc56f1ac6b120472df29aa1@free.fr>
References: <cover.1452021349.git.moinejf@free.fr>
 <20160106212046.GD9631@lukather>
 <20160108181306.4a5a7370f0e3f3daa7c9e285@free.fr>
 <20160118101827.GO4581@lukather>
 <20160119094907.2cc56f1ac6b120472df29aa1@free.fr>
Message-ID: <20160202165833.GY4652@lukather>

On Tue, Jan 19, 2016 at 09:49:07AM +0100, Jean-Francois Moine wrote:
> On Mon, 18 Jan 2016 11:18:27 +0100
> Maxime Ripard <maxime.ripard at free-electrons.com> wrote:
> 
> > > Then, the DE2 sources contain only:
> > > 
> > > 	All Winner Tech, All Right Reserved. 2014-2015 Copyright (c)
> > > 
> > > Eventually, there is no copyright/author/history in the HDMI sources.
> > 
> > That one is nasty though :/
> > 
> > It seems to be a GPL violation though, so we have two solutions:
> > 
> > A) have a clean room implementation
> > B) Ask allwinner to comply with the license
> > 
> > The former doesn't look likely to happen soon... Can you open an issue
> > on this on their linux github repo?
> 
> Do you really think that I could have more luck than people of the
> linux-sunxi or pine64 teams?

It did work for a few issues in the past...

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/549266c0/attachment.sig>

From maxime.ripard at free-electrons.com  Tue Feb  2 09:00:37 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 18:00:37 +0100
Subject: [PATCH 3/5] clk: sunxi: convert current clocks registration to
 CLK_OF_DECLARE
In-Reply-To: <56B0BA56.10500@arm.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454402834-6385-4-git-send-email-maxime.ripard@free-electrons.com>
 <56B0BA56.10500@arm.com>
Message-ID: <20160202170037.GZ4652@lukather>

Hi,

On Tue, Feb 02, 2016 at 02:16:54PM +0000, Andre Przywara wrote:
> Hi Maxime,
> 
> On 02/02/16 08:47, Maxime Ripard wrote:
> > The current clock registration and protection code has a few drawbacks, the
> > two main ones being that we create a lot of orphans clock in the
> > registration phase, which will be troublesome when we will start being less
> > relaxed about them.
> > 
> > The protection code also relies on clkdev, which we don't really use but
> > for this particular case.
> > 
> > Fix both at the same time by moving everyone to the CLK_OF_DECLARE that
> > will probe our clock tree in the right and thus avoid orphans, and by
> > protecting directly the clock returned by our registration function.
> 
> I very much appreciate this cleanup and like the idea. Any chance we can
> have this rather quickly, so that I can rebase the A64 support series on it?

I actually count on that :)

I wasn't really happy about your allwinner,sunxi compatible, so I just
gave you an easier way out ;)

> > +static void __init sun8i_ahb2_clk_setup(struct device_node *node)
> > +{
> > +	sunxi_mux_clk_setup(node, &sun8i_h3_ahb2_mux_data);
> > +}
> > +CLK_OF_DECLARE(sun8i_ahb2, "allwinner,sun8i-a31-ahb2-clk",
> > +	       sun8i_ahb2_clk_setup);
> 
> I don't find this clock in my tree (which is mripard/sunxi/for-next).
> Instead I only have "allwinner,sun8i-h3-ahb2-clk", as mentioned below.
> But as you remove this clock below from the old code and instead
> instantiate this new clock here, this looks somehow wrong to me. Can you
> confirm this or am I utterly confused?

Damn, you're right, it's just a silly copy-paste issue, I'll fix it.

> Apart from that I checked each and every clock mentioned in this patch
> and can confirm that the transformation is correct. So if you fix this,
> I can send a Reviewed-by.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/b628781e/attachment.sig>

From andre.przywara at arm.com  Tue Feb  2 09:04:02 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 2 Feb 2016 17:04:02 +0000
Subject: [PATCH 3/5] clk: sunxi: convert current clocks registration to
 CLK_OF_DECLARE
In-Reply-To: <20160202170037.GZ4652@lukather>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454402834-6385-4-git-send-email-maxime.ripard@free-electrons.com>
 <56B0BA56.10500@arm.com> <20160202170037.GZ4652@lukather>
Message-ID: <56B0E182.9000207@arm.com>

Hi,

On 02/02/16 17:00, Maxime Ripard wrote:
> Hi,
> 
> On Tue, Feb 02, 2016 at 02:16:54PM +0000, Andre Przywara wrote:
>> Hi Maxime,
>>
>> On 02/02/16 08:47, Maxime Ripard wrote:
>>> The current clock registration and protection code has a few drawbacks, the
>>> two main ones being that we create a lot of orphans clock in the
>>> registration phase, which will be troublesome when we will start being less
>>> relaxed about them.
>>>
>>> The protection code also relies on clkdev, which we don't really use but
>>> for this particular case.
>>>
>>> Fix both at the same time by moving everyone to the CLK_OF_DECLARE that
>>> will probe our clock tree in the right and thus avoid orphans, and by
>>> protecting directly the clock returned by our registration function.
>>
>> I very much appreciate this cleanup and like the idea. Any chance we can
>> have this rather quickly, so that I can rebase the A64 support series on it?
> 
> I actually count on that :)

Great!

> I wasn't really happy about your allwinner,sunxi compatible,

Me neither, honestly, but I didn't dare to touch clk-sunxi.c even more ;-)

> so I just
> gave you an easier way out ;)

Appreciated!

> 
>>> +static void __init sun8i_ahb2_clk_setup(struct device_node *node)
>>> +{
>>> +	sunxi_mux_clk_setup(node, &sun8i_h3_ahb2_mux_data);
>>> +}
>>> +CLK_OF_DECLARE(sun8i_ahb2, "allwinner,sun8i-a31-ahb2-clk",
>>> +	       sun8i_ahb2_clk_setup);
>>
>> I don't find this clock in my tree (which is mripard/sunxi/for-next).
>> Instead I only have "allwinner,sun8i-h3-ahb2-clk", as mentioned below.
>> But as you remove this clock below from the old code and instead
>> instantiate this new clock here, this looks somehow wrong to me. Can you
>> confirm this or am I utterly confused?
> 
> Damn, you're right, it's just a silly copy-paste issue, I'll fix it.

I am sure you left it in to see if somebody actually checks it ;-)

Merci!
Andre

>> Apart from that I checked each and every clock mentioned in this patch
>> and can confirm that the transformation is correct. So if you fix this,
>> I can send a Reviewed-by.
> 
> Thanks,
> Maxime
> 


From Chris.Brandt at renesas.com  Tue Feb  2 09:05:07 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Tue, 2 Feb 2016 17:05:07 +0000
Subject: [PATCH v4] ARM: xip: Use correct symbol for end of ROM marker
In-Reply-To: <alpine.LFD.2.20.1602011522070.32766@knanqh.ubzr>
References: <1447697140-4099-1-git-send-email-chris.brandt@renesas.com>
 <1454349165-12249-1-git-send-email-chris.brandt@renesas.com>
 <alpine.LFD.2.20.1602011404420.32766@knanqh.ubzr>
 <SG2PR06MB0572F0EE79C00A530FA9CF398ADE0@SG2PR06MB0572.apcprd06.prod.outlook.com>
 <alpine.LFD.2.20.1602011522070.32766@knanqh.ubzr>
Message-ID: <HKXPR06MB0565EEA0ED5BB19E5CFC992B8ADF0@HKXPR06MB0565.apcprd06.prod.outlook.com>

On Mon, 1 Feb 2016, Nicolas Pitre wrote:
> The __data_loc symbol doesn't convey much to say with regards to XIP 
> mapping.  It would be better to dedicate another symbol with a 
> proper name instead.  Something like xiprom_start and xiprom_end perhaps.
> This way, someone looking at the linker script won't be fooled by a 
> hidden meaning tied to _etext or __data_loc.

In keeping with the convention that's already in the vmlinux.lds, I'm going to go with "_xiprom" and "_exiprom"


> > Or, should we keep piling more stuff in vmlinux.lds.S?
>
> I still think the split linker file is the way to go.

So...since I didn't hear any clapping and cheering, first I'd like to fix what I know is broken and get that in. Then go back to the splitting linker script idea.


Chris



From james.morse at arm.com  Tue Feb  2 09:03:26 2016
From: james.morse at arm.com (James Morse)
Date: Tue,  2 Feb 2016 17:03:26 +0000
Subject: [PATCH v1 0/5] arm64: kernel: Add support for User Access Override
Message-ID: <1454432611-21333-1-git-send-email-james.morse@arm.com>

This series adds support for User Access Override (UAO; part of the ARMv8.2
Extensions[0]). When enabled, this causes the get_user() accessors to use
the unprivileged load/store instructions. When addr_limit is set to
KERNEL_DS, we set the override bit allowing privileged access.

Because the unprivileged instructions don't trip PAN, the last patch changes
which 'alternative' values are swapped in, allowing PAN to be left enabled
during get_user() and friends.

This series can be retrieved from:
git://linux-arm.org/linux-jm.git -b uao/v1

Comments welcome,

James

[0] https://community.arm.com/groups/processors/blog/2016/01/05/armv8-a-architecture-evolution

James Morse (5):
  kernel: cpufeature: Change read_cpuid() to use sysreg's mrs_s macro
  arm64: add ARMv8.2 id_aa64mmfr2 boiler plate
  arm64: kernel: Add support for User Access Override
  arm64: cpufeature: Test 'matches' pointer to find the end of the list
  arm64: kernel: Don't toggle PAN on systems with UAO

 arch/arm64/Kconfig                   |  21 ++++++
 arch/arm64/include/asm/alternative.h |  72 +++++++++++++++++++++
 arch/arm64/include/asm/cpu.h         |   1 +
 arch/arm64/include/asm/cpufeature.h  |   6 +-
 arch/arm64/include/asm/cputype.h     |  20 +++---
 arch/arm64/include/asm/processor.h   |   1 +
 arch/arm64/include/asm/sysreg.h      |   7 ++
 arch/arm64/include/asm/thread_info.h |   6 ++
 arch/arm64/include/asm/uaccess.h     |  52 ++++++++++-----
 arch/arm64/include/uapi/asm/ptrace.h |   1 +
 arch/arm64/kernel/cpufeature.c       | 120 +++++++++++++++++++++++++----------
 arch/arm64/kernel/cpuinfo.c          |  55 ++++++++--------
 arch/arm64/kernel/process.c          |  20 ++++++
 arch/arm64/lib/clear_user.S          |  12 ++--
 arch/arm64/lib/copy_from_user.S      |  12 ++--
 arch/arm64/lib/copy_in_user.S        |  20 +++---
 arch/arm64/lib/copy_to_user.S        |  12 ++--
 arch/arm64/mm/context.c              |   2 +-
 arch/arm64/mm/fault.c                |  21 ++++--
 19 files changed, 337 insertions(+), 124 deletions(-)

-- 
2.6.2



From james.morse at arm.com  Tue Feb  2 09:03:28 2016
From: james.morse at arm.com (James Morse)
Date: Tue,  2 Feb 2016 17:03:28 +0000
Subject: [PATCH v1 2/5] arm64: add ARMv8.2 id_aa64mmfr2 boiler plate
In-Reply-To: <1454432611-21333-1-git-send-email-james.morse@arm.com>
References: <1454432611-21333-1-git-send-email-james.morse@arm.com>
Message-ID: <1454432611-21333-3-git-send-email-james.morse@arm.com>

ARMv8.2 adds a new feature register id_aa64mmfr2. This patch adds the
cpu feature boiler plate used by the actual features in later patches.

Signed-off-by: James Morse <james.morse at arm.com>
---
 arch/arm64/include/asm/cpu.h    | 1 +
 arch/arm64/include/asm/sysreg.h | 1 +
 arch/arm64/kernel/cpufeature.c  | 9 +++++++++
 arch/arm64/kernel/cpuinfo.c     | 1 +
 4 files changed, 12 insertions(+)

diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
index b5e9cee4b5f8..13a6103130cd 100644
--- a/arch/arm64/include/asm/cpu.h
+++ b/arch/arm64/include/asm/cpu.h
@@ -36,6 +36,7 @@ struct cpuinfo_arm64 {
 	u64		reg_id_aa64isar1;
 	u64		reg_id_aa64mmfr0;
 	u64		reg_id_aa64mmfr1;
+	u64		reg_id_aa64mmfr2;
 	u64		reg_id_aa64pfr0;
 	u64		reg_id_aa64pfr1;
 
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 4aeebec3d882..6d2cec2fcfd5 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -72,6 +72,7 @@
 
 #define SYS_ID_AA64MMFR0_EL1		sys_reg(3, 0, 0, 7, 0)
 #define SYS_ID_AA64MMFR1_EL1		sys_reg(3, 0, 0, 7, 1)
+#define SYS_ID_AA64MMFR2_EL1		sys_reg(3, 0, 0, 7, 2)
 
 #define SYS_CNTFRQ_EL0			sys_reg(3, 3, 14, 0, 0)
 #define SYS_CTR_EL0			sys_reg(3, 3, 0, 0, 1)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index a84febc40db2..a4f665f95f9f 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -123,6 +123,10 @@ static struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
 	ARM64_FTR_END,
 };
 
+static struct arm64_ftr_bits ftr_id_aa64mmfr2[] = {
+	ARM64_FTR_END,
+};
+
 static struct arm64_ftr_bits ftr_ctr[] = {
 	U_ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 31, 1, 1),	/* RAO */
 	ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 28, 3, 0),
@@ -284,6 +288,7 @@ static struct arm64_ftr_reg arm64_ftr_regs[] = {
 	/* Op1 = 0, CRn = 0, CRm = 7 */
 	ARM64_FTR_REG(SYS_ID_AA64MMFR0_EL1, ftr_id_aa64mmfr0),
 	ARM64_FTR_REG(SYS_ID_AA64MMFR1_EL1, ftr_id_aa64mmfr1),
+	ARM64_FTR_REG(SYS_ID_AA64MMFR2_EL1, ftr_id_aa64mmfr2),
 
 	/* Op1 = 3, CRn = 0, CRm = 0 */
 	ARM64_FTR_REG(SYS_CTR_EL0, ftr_ctr),
@@ -408,6 +413,7 @@ void __init init_cpu_features(struct cpuinfo_arm64 *info)
 	init_cpu_ftr_reg(SYS_ID_AA64ISAR1_EL1, info->reg_id_aa64isar1);
 	init_cpu_ftr_reg(SYS_ID_AA64MMFR0_EL1, info->reg_id_aa64mmfr0);
 	init_cpu_ftr_reg(SYS_ID_AA64MMFR1_EL1, info->reg_id_aa64mmfr1);
+	init_cpu_ftr_reg(SYS_ID_AA64MMFR2_EL1, info->reg_id_aa64mmfr2);
 	init_cpu_ftr_reg(SYS_ID_AA64PFR0_EL1, info->reg_id_aa64pfr0);
 	init_cpu_ftr_reg(SYS_ID_AA64PFR1_EL1, info->reg_id_aa64pfr1);
 	init_cpu_ftr_reg(SYS_ID_DFR0_EL1, info->reg_id_dfr0);
@@ -517,6 +523,8 @@ void update_cpu_features(int cpu,
 				      info->reg_id_aa64mmfr0, boot->reg_id_aa64mmfr0);
 	taint |= check_update_ftr_reg(SYS_ID_AA64MMFR1_EL1, cpu,
 				      info->reg_id_aa64mmfr1, boot->reg_id_aa64mmfr1);
+	taint |= check_update_ftr_reg(SYS_ID_AA64MMFR2_EL1, cpu,
+				      info->reg_id_aa64mmfr2, boot->reg_id_aa64mmfr2);
 
 	/*
 	 * EL3 is not our concern.
@@ -814,6 +822,7 @@ static u64 __raw_read_system_reg(u32 sys_id)
 	case SYS_ID_AA64DFR1_EL1:	return read_cpuid(SYS_ID_AA64DFR0_EL1);
 	case SYS_ID_AA64MMFR0_EL1:	return read_cpuid(SYS_ID_AA64MMFR0_EL1);
 	case SYS_ID_AA64MMFR1_EL1:	return read_cpuid(SYS_ID_AA64MMFR1_EL1);
+	case SYS_ID_AA64MMFR2_EL1:	return read_cpuid(SYS_ID_AA64MMFR2_EL1);
 	case SYS_ID_AA64ISAR0_EL1:	return read_cpuid(SYS_ID_AA64ISAR0_EL1);
 	case SYS_ID_AA64ISAR1_EL1:	return read_cpuid(SYS_ID_AA64ISAR1_EL1);
 
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 76df22272804..966fbd52550b 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -210,6 +210,7 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
 	info->reg_id_aa64isar1 = read_cpuid(SYS_ID_AA64ISAR1_EL1);
 	info->reg_id_aa64mmfr0 = read_cpuid(SYS_ID_AA64MMFR0_EL1);
 	info->reg_id_aa64mmfr1 = read_cpuid(SYS_ID_AA64MMFR1_EL1);
+	info->reg_id_aa64mmfr2 = read_cpuid(SYS_ID_AA64MMFR2_EL1);
 	info->reg_id_aa64pfr0 = read_cpuid(SYS_ID_AA64PFR0_EL1);
 	info->reg_id_aa64pfr1 = read_cpuid(SYS_ID_AA64PFR1_EL1);
 
-- 
2.6.2



From james.morse at arm.com  Tue Feb  2 09:03:27 2016
From: james.morse at arm.com (James Morse)
Date: Tue,  2 Feb 2016 17:03:27 +0000
Subject: [PATCH v1 1/5] arm64: cpufeature: Change read_cpuid() to use sysreg's
 mrs_s macro
In-Reply-To: <1454432611-21333-1-git-send-email-james.morse@arm.com>
References: <1454432611-21333-1-git-send-email-james.morse@arm.com>
Message-ID: <1454432611-21333-2-git-send-email-james.morse@arm.com>

Older assemblers may not have support for newer feature registers. To get
round this, sysreg.h provides a 'mrs_s' macro that takes a register
encoding and generates the raw instruction.

Change read_cpuid() to use mrs_s in all cases so that new registers
don't have to be a special case. Including sysreg.h means we need to move
the include and definition of read_cpuid() after the #ifndef __ASSEMBLY__
to avoid syntax errors in vmlinux.lds.

Signed-off-by: James Morse <james.morse at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>

---
 arch/arm64/include/asm/cpufeature.h |  2 +-
 arch/arm64/include/asm/cputype.h    | 20 +++++++------
 arch/arm64/kernel/cpufeature.c      | 58 ++++++++++++++++++-------------------
 arch/arm64/kernel/cpuinfo.c         | 54 +++++++++++++++++-----------------
 arch/arm64/mm/context.c             |  2 +-
 5 files changed, 69 insertions(+), 67 deletions(-)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 8f271b83f910..d28e8b27ee59 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -176,7 +176,7 @@ u64 read_system_reg(u32 id);
 
 static inline bool cpu_supports_mixed_endian_el0(void)
 {
-	return id_aa64mmfr0_mixed_endian_el0(read_cpuid(ID_AA64MMFR0_EL1));
+	return id_aa64mmfr0_mixed_endian_el0(read_cpuid(SYS_ID_AA64MMFR0_EL1));
 }
 
 static inline bool system_supports_mixed_endian_el0(void)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 1a5949364ed0..71eecd3c5b4e 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -32,12 +32,6 @@
 #define MPIDR_AFFINITY_LEVEL(mpidr, level) \
 	((mpidr >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
 
-#define read_cpuid(reg) ({						\
-	u64 __val;							\
-	asm("mrs	%0, " #reg : "=r" (__val));			\
-	__val;								\
-})
-
 #define MIDR_REVISION_MASK	0xf
 #define MIDR_REVISION(midr)	((midr) & MIDR_REVISION_MASK)
 #define MIDR_PARTNUM_SHIFT	4
@@ -77,6 +71,14 @@
 
 #ifndef __ASSEMBLY__
 
+#include <asm/sysreg.h>
+
+#define read_cpuid(reg) ({						\
+	u64 __val;							\
+	asm("mrs_s	%0, " __stringify(reg) : "=r" (__val));		\
+	__val;								\
+})
+
 /*
  * The CPU ID never changes at run time, so we might as well tell the
  * compiler that it's constant.  Use this function to read the CPU ID
@@ -84,12 +86,12 @@
  */
 static inline u32 __attribute_const__ read_cpuid_id(void)
 {
-	return read_cpuid(MIDR_EL1);
+	return read_cpuid(SYS_MIDR_EL1);
 }
 
 static inline u64 __attribute_const__ read_cpuid_mpidr(void)
 {
-	return read_cpuid(MPIDR_EL1);
+	return read_cpuid(SYS_MPIDR_EL1);
 }
 
 static inline unsigned int __attribute_const__ read_cpuid_implementor(void)
@@ -104,7 +106,7 @@ static inline unsigned int __attribute_const__ read_cpuid_part_number(void)
 
 static inline u32 __attribute_const__ read_cpuid_cachetype(void)
 {
-	return read_cpuid(CTR_EL0);
+	return read_cpuid(SYS_CTR_EL0);
 }
 #endif /* __ASSEMBLY__ */
 
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 5c90aa490a2b..a84febc40db2 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -791,35 +791,35 @@ static inline void set_sys_caps_initialised(void)
 static u64 __raw_read_system_reg(u32 sys_id)
 {
 	switch (sys_id) {
-	case SYS_ID_PFR0_EL1:		return (u64)read_cpuid(ID_PFR0_EL1);
-	case SYS_ID_PFR1_EL1:		return (u64)read_cpuid(ID_PFR1_EL1);
-	case SYS_ID_DFR0_EL1:		return (u64)read_cpuid(ID_DFR0_EL1);
-	case SYS_ID_MMFR0_EL1:		return (u64)read_cpuid(ID_MMFR0_EL1);
-	case SYS_ID_MMFR1_EL1:		return (u64)read_cpuid(ID_MMFR1_EL1);
-	case SYS_ID_MMFR2_EL1:		return (u64)read_cpuid(ID_MMFR2_EL1);
-	case SYS_ID_MMFR3_EL1:		return (u64)read_cpuid(ID_MMFR3_EL1);
-	case SYS_ID_ISAR0_EL1:		return (u64)read_cpuid(ID_ISAR0_EL1);
-	case SYS_ID_ISAR1_EL1:		return (u64)read_cpuid(ID_ISAR1_EL1);
-	case SYS_ID_ISAR2_EL1:		return (u64)read_cpuid(ID_ISAR2_EL1);
-	case SYS_ID_ISAR3_EL1:		return (u64)read_cpuid(ID_ISAR3_EL1);
-	case SYS_ID_ISAR4_EL1:		return (u64)read_cpuid(ID_ISAR4_EL1);
-	case SYS_ID_ISAR5_EL1:		return (u64)read_cpuid(ID_ISAR4_EL1);
-	case SYS_MVFR0_EL1:		return (u64)read_cpuid(MVFR0_EL1);
-	case SYS_MVFR1_EL1:		return (u64)read_cpuid(MVFR1_EL1);
-	case SYS_MVFR2_EL1:		return (u64)read_cpuid(MVFR2_EL1);
-
-	case SYS_ID_AA64PFR0_EL1:	return (u64)read_cpuid(ID_AA64PFR0_EL1);
-	case SYS_ID_AA64PFR1_EL1:	return (u64)read_cpuid(ID_AA64PFR0_EL1);
-	case SYS_ID_AA64DFR0_EL1:	return (u64)read_cpuid(ID_AA64DFR0_EL1);
-	case SYS_ID_AA64DFR1_EL1:	return (u64)read_cpuid(ID_AA64DFR0_EL1);
-	case SYS_ID_AA64MMFR0_EL1:	return (u64)read_cpuid(ID_AA64MMFR0_EL1);
-	case SYS_ID_AA64MMFR1_EL1:	return (u64)read_cpuid(ID_AA64MMFR1_EL1);
-	case SYS_ID_AA64ISAR0_EL1:	return (u64)read_cpuid(ID_AA64ISAR0_EL1);
-	case SYS_ID_AA64ISAR1_EL1:	return (u64)read_cpuid(ID_AA64ISAR1_EL1);
-
-	case SYS_CNTFRQ_EL0:		return (u64)read_cpuid(CNTFRQ_EL0);
-	case SYS_CTR_EL0:		return (u64)read_cpuid(CTR_EL0);
-	case SYS_DCZID_EL0:		return (u64)read_cpuid(DCZID_EL0);
+	case SYS_ID_PFR0_EL1:		return read_cpuid(SYS_ID_PFR0_EL1);
+	case SYS_ID_PFR1_EL1:		return read_cpuid(SYS_ID_PFR1_EL1);
+	case SYS_ID_DFR0_EL1:		return read_cpuid(SYS_ID_DFR0_EL1);
+	case SYS_ID_MMFR0_EL1:		return read_cpuid(SYS_ID_MMFR0_EL1);
+	case SYS_ID_MMFR1_EL1:		return read_cpuid(SYS_ID_MMFR1_EL1);
+	case SYS_ID_MMFR2_EL1:		return read_cpuid(SYS_ID_MMFR2_EL1);
+	case SYS_ID_MMFR3_EL1:		return read_cpuid(SYS_ID_MMFR3_EL1);
+	case SYS_ID_ISAR0_EL1:		return read_cpuid(SYS_ID_ISAR0_EL1);
+	case SYS_ID_ISAR1_EL1:		return read_cpuid(SYS_ID_ISAR1_EL1);
+	case SYS_ID_ISAR2_EL1:		return read_cpuid(SYS_ID_ISAR2_EL1);
+	case SYS_ID_ISAR3_EL1:		return read_cpuid(SYS_ID_ISAR3_EL1);
+	case SYS_ID_ISAR4_EL1:		return read_cpuid(SYS_ID_ISAR4_EL1);
+	case SYS_ID_ISAR5_EL1:		return read_cpuid(SYS_ID_ISAR4_EL1);
+	case SYS_MVFR0_EL1:		return read_cpuid(SYS_MVFR0_EL1);
+	case SYS_MVFR1_EL1:		return read_cpuid(SYS_MVFR1_EL1);
+	case SYS_MVFR2_EL1:		return read_cpuid(SYS_MVFR2_EL1);
+
+	case SYS_ID_AA64PFR0_EL1:	return read_cpuid(SYS_ID_AA64PFR0_EL1);
+	case SYS_ID_AA64PFR1_EL1:	return read_cpuid(SYS_ID_AA64PFR0_EL1);
+	case SYS_ID_AA64DFR0_EL1:	return read_cpuid(SYS_ID_AA64DFR0_EL1);
+	case SYS_ID_AA64DFR1_EL1:	return read_cpuid(SYS_ID_AA64DFR0_EL1);
+	case SYS_ID_AA64MMFR0_EL1:	return read_cpuid(SYS_ID_AA64MMFR0_EL1);
+	case SYS_ID_AA64MMFR1_EL1:	return read_cpuid(SYS_ID_AA64MMFR1_EL1);
+	case SYS_ID_AA64ISAR0_EL1:	return read_cpuid(SYS_ID_AA64ISAR0_EL1);
+	case SYS_ID_AA64ISAR1_EL1:	return read_cpuid(SYS_ID_AA64ISAR1_EL1);
+
+	case SYS_CNTFRQ_EL0:		return read_cpuid(SYS_CNTFRQ_EL0);
+	case SYS_CTR_EL0:		return read_cpuid(SYS_CTR_EL0);
+	case SYS_DCZID_EL0:		return read_cpuid(SYS_DCZID_EL0);
 	default:
 		BUG();
 		return 0;
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 212ae6361d8b..76df22272804 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -201,35 +201,35 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
 {
 	info->reg_cntfrq = arch_timer_get_cntfrq();
 	info->reg_ctr = read_cpuid_cachetype();
-	info->reg_dczid = read_cpuid(DCZID_EL0);
+	info->reg_dczid = read_cpuid(SYS_DCZID_EL0);
 	info->reg_midr = read_cpuid_id();
 
-	info->reg_id_aa64dfr0 = read_cpuid(ID_AA64DFR0_EL1);
-	info->reg_id_aa64dfr1 = read_cpuid(ID_AA64DFR1_EL1);
-	info->reg_id_aa64isar0 = read_cpuid(ID_AA64ISAR0_EL1);
-	info->reg_id_aa64isar1 = read_cpuid(ID_AA64ISAR1_EL1);
-	info->reg_id_aa64mmfr0 = read_cpuid(ID_AA64MMFR0_EL1);
-	info->reg_id_aa64mmfr1 = read_cpuid(ID_AA64MMFR1_EL1);
-	info->reg_id_aa64pfr0 = read_cpuid(ID_AA64PFR0_EL1);
-	info->reg_id_aa64pfr1 = read_cpuid(ID_AA64PFR1_EL1);
-
-	info->reg_id_dfr0 = read_cpuid(ID_DFR0_EL1);
-	info->reg_id_isar0 = read_cpuid(ID_ISAR0_EL1);
-	info->reg_id_isar1 = read_cpuid(ID_ISAR1_EL1);
-	info->reg_id_isar2 = read_cpuid(ID_ISAR2_EL1);
-	info->reg_id_isar3 = read_cpuid(ID_ISAR3_EL1);
-	info->reg_id_isar4 = read_cpuid(ID_ISAR4_EL1);
-	info->reg_id_isar5 = read_cpuid(ID_ISAR5_EL1);
-	info->reg_id_mmfr0 = read_cpuid(ID_MMFR0_EL1);
-	info->reg_id_mmfr1 = read_cpuid(ID_MMFR1_EL1);
-	info->reg_id_mmfr2 = read_cpuid(ID_MMFR2_EL1);
-	info->reg_id_mmfr3 = read_cpuid(ID_MMFR3_EL1);
-	info->reg_id_pfr0 = read_cpuid(ID_PFR0_EL1);
-	info->reg_id_pfr1 = read_cpuid(ID_PFR1_EL1);
-
-	info->reg_mvfr0 = read_cpuid(MVFR0_EL1);
-	info->reg_mvfr1 = read_cpuid(MVFR1_EL1);
-	info->reg_mvfr2 = read_cpuid(MVFR2_EL1);
+	info->reg_id_aa64dfr0 = read_cpuid(SYS_ID_AA64DFR0_EL1);
+	info->reg_id_aa64dfr1 = read_cpuid(SYS_ID_AA64DFR1_EL1);
+	info->reg_id_aa64isar0 = read_cpuid(SYS_ID_AA64ISAR0_EL1);
+	info->reg_id_aa64isar1 = read_cpuid(SYS_ID_AA64ISAR1_EL1);
+	info->reg_id_aa64mmfr0 = read_cpuid(SYS_ID_AA64MMFR0_EL1);
+	info->reg_id_aa64mmfr1 = read_cpuid(SYS_ID_AA64MMFR1_EL1);
+	info->reg_id_aa64pfr0 = read_cpuid(SYS_ID_AA64PFR0_EL1);
+	info->reg_id_aa64pfr1 = read_cpuid(SYS_ID_AA64PFR1_EL1);
+
+	info->reg_id_dfr0 = read_cpuid(SYS_ID_DFR0_EL1);
+	info->reg_id_isar0 = read_cpuid(SYS_ID_ISAR0_EL1);
+	info->reg_id_isar1 = read_cpuid(SYS_ID_ISAR1_EL1);
+	info->reg_id_isar2 = read_cpuid(SYS_ID_ISAR2_EL1);
+	info->reg_id_isar3 = read_cpuid(SYS_ID_ISAR3_EL1);
+	info->reg_id_isar4 = read_cpuid(SYS_ID_ISAR4_EL1);
+	info->reg_id_isar5 = read_cpuid(SYS_ID_ISAR5_EL1);
+	info->reg_id_mmfr0 = read_cpuid(SYS_ID_MMFR0_EL1);
+	info->reg_id_mmfr1 = read_cpuid(SYS_ID_MMFR1_EL1);
+	info->reg_id_mmfr2 = read_cpuid(SYS_ID_MMFR2_EL1);
+	info->reg_id_mmfr3 = read_cpuid(SYS_ID_MMFR3_EL1);
+	info->reg_id_pfr0 = read_cpuid(SYS_ID_PFR0_EL1);
+	info->reg_id_pfr1 = read_cpuid(SYS_ID_PFR1_EL1);
+
+	info->reg_mvfr0 = read_cpuid(SYS_MVFR0_EL1);
+	info->reg_mvfr1 = read_cpuid(SYS_MVFR1_EL1);
+	info->reg_mvfr2 = read_cpuid(SYS_MVFR2_EL1);
 
 	cpuinfo_detect_icache_policy(info);
 
diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index e87f53ff5f58..7275628ba59f 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -187,7 +187,7 @@ switch_mm_fastpath:
 
 static int asids_init(void)
 {
-	int fld = cpuid_feature_extract_field(read_cpuid(ID_AA64MMFR0_EL1), 4);
+	int fld = cpuid_feature_extract_field(read_cpuid(SYS_ID_AA64MMFR0_EL1), 4);
 
 	switch (fld) {
 	default:
-- 
2.6.2



From james.morse at arm.com  Tue Feb  2 09:03:30 2016
From: james.morse at arm.com (James Morse)
Date: Tue,  2 Feb 2016 17:03:30 +0000
Subject: [PATCH v1 4/5] arm64: cpufeature: Test 'matches' pointer to find the
 end of the list
In-Reply-To: <1454432611-21333-1-git-send-email-james.morse@arm.com>
References: <1454432611-21333-1-git-send-email-james.morse@arm.com>
Message-ID: <1454432611-21333-5-git-send-email-james.morse@arm.com>

CPU feature code uses the desc field as a test to find the end of the list,
this means every entry must have a description. This generates noise for
entries in the list that aren't really features, but combinations of them.
e.g.
> CPU features: detected feature: Privileged Access Never
> CPU features: detected feature: PAN and not UAO

These combination features are needed for corner cases with alternatives,
where cpu features interact.

Change all walkers of the arm64_features[] and arm64_hwcaps[] lists to test
'matches' not 'desc', and only print 'desc' if it is non-NULL.

Signed-Off-By: James Morse <james.morse at arm.com>
---
 arch/arm64/kernel/cpufeature.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index b25c6a2c5e0f..caecc9a81b82 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -754,7 +754,7 @@ static void __init setup_cpu_hwcaps(void)
 	int i;
 	const struct arm64_cpu_capabilities *hwcaps = arm64_hwcaps;
 
-	for (i = 0; hwcaps[i].desc; i++)
+	for (i = 0; hwcaps[i].matches; i++)
 		if (hwcaps[i].matches(&hwcaps[i]))
 			cap_set_hwcap(&hwcaps[i]);
 }
@@ -764,11 +764,11 @@ void update_cpu_capabilities(const struct arm64_cpu_capabilities *caps,
 {
 	int i;
 
-	for (i = 0; caps[i].desc; i++) {
+	for (i = 0; caps[i].matches; i++) {
 		if (!caps[i].matches(&caps[i]))
 			continue;
 
-		if (!cpus_have_cap(caps[i].capability))
+		if (!cpus_have_cap(caps[i].capability) && caps[i].desc)
 			pr_info("%s %s\n", info, caps[i].desc);
 		cpus_set_cap(caps[i].capability);
 	}
@@ -783,7 +783,7 @@ enable_cpu_capabilities(const struct arm64_cpu_capabilities *caps)
 {
 	int i;
 
-	for (i = 0; caps[i].desc; i++)
+	for (i = 0; caps[i].matches; i++)
 		if (caps[i].enable && cpus_have_cap(caps[i].capability))
 			on_each_cpu(caps[i].enable, NULL, true);
 }
@@ -890,7 +890,7 @@ void verify_local_cpu_capabilities(void)
 		return;
 
 	caps = arm64_features;
-	for (i = 0; caps[i].desc; i++) {
+	for (i = 0; caps[i].matches; i++) {
 		if (!cpus_have_cap(caps[i].capability) || !caps[i].sys_reg)
 			continue;
 		/*
@@ -903,7 +903,7 @@ void verify_local_cpu_capabilities(void)
 			caps[i].enable(NULL);
 	}
 
-	for (i = 0, caps = arm64_hwcaps; caps[i].desc; i++) {
+	for (i = 0, caps = arm64_hwcaps; caps[i].matches; i++) {
 		if (!cpus_have_hwcap(&caps[i]))
 			continue;
 		if (!feature_matches(__raw_read_system_reg(caps[i].sys_reg), &caps[i]))
-- 
2.6.2



From james.morse at arm.com  Tue Feb  2 09:03:29 2016
From: james.morse at arm.com (James Morse)
Date: Tue,  2 Feb 2016 17:03:29 +0000
Subject: [PATCH v1 3/5] arm64: kernel: Add support for User Access Override
In-Reply-To: <1454432611-21333-1-git-send-email-james.morse@arm.com>
References: <1454432611-21333-1-git-send-email-james.morse@arm.com>
Message-ID: <1454432611-21333-4-git-send-email-james.morse@arm.com>

'User Access Override' is a new ARMv8.2 feature which allows the
unprivileged load and store instructions to be overridden to behave in
the normal way.

This patch converts {get,put}_user() and friends to use ldtr*/sttr*
instructions - so that they can only access EL0 memory, then enables
UAO when fs==KERNEL_DS so that these functions can access kernel memory.

This allows user space's read/write permissions to be checked against the
page tables, instead of testing addr<USER_DS, then using the kernel's
read/write permissions.

Signed-off-by: James Morse <james.morse at arm.com>
---
 arch/arm64/Kconfig                   | 21 +++++++++++
 arch/arm64/include/asm/alternative.h | 72 ++++++++++++++++++++++++++++++++++++
 arch/arm64/include/asm/cpufeature.h  |  3 +-
 arch/arm64/include/asm/processor.h   |  1 +
 arch/arm64/include/asm/sysreg.h      |  6 +++
 arch/arm64/include/asm/thread_info.h |  6 +++
 arch/arm64/include/asm/uaccess.h     | 44 ++++++++++++++++------
 arch/arm64/include/uapi/asm/ptrace.h |  1 +
 arch/arm64/kernel/cpufeature.c       | 25 +++++++++++++
 arch/arm64/kernel/process.c          | 20 ++++++++++
 arch/arm64/lib/clear_user.S          |  8 ++--
 arch/arm64/lib/copy_from_user.S      |  8 ++--
 arch/arm64/lib/copy_in_user.S        | 16 ++++----
 arch/arm64/lib/copy_to_user.S        |  8 ++--
 arch/arm64/mm/fault.c                | 18 ++++++---
 15 files changed, 218 insertions(+), 39 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc62289a63e..63f2cca9e0ea 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -752,6 +752,27 @@ config ARM64_LSE_ATOMICS
 
 endmenu
 
+config ARM64_UAO
+	bool "Enable support for User Access Override (UAO)"
+	default y
+	help
+	 User Access Override (UAO; part of the ARMv8.2 Extensions)
+	 causes the 'unprivileged' variant of the load/store instructions to
+	 be overriden to be privileged.
+
+	 This option changes get_user() and friends to use the 'unprivileged'
+	 variant of the load/store instructions. This ensures that user-space
+	 really did have access to the supplied memory. When addr_limit is
+	 set to kernel memory the UAO bit will be set, allowing privileged
+	 access to kernel memory.
+
+	 Choosing this option will cause copy_to_user() et al to use user-space
+	 memory permissions.
+
+	 The feature is detected at runtime, the kernel will use the
+	 regular load/store instructions if the cpu does not implement the
+	 feature.
+
 endmenu
 
 menu "Boot options"
diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h
index e4962f04201e..a9fc24ec1aa9 100644
--- a/arch/arm64/include/asm/alternative.h
+++ b/arch/arm64/include/asm/alternative.h
@@ -1,6 +1,8 @@
 #ifndef __ASM_ALTERNATIVE_H
 #define __ASM_ALTERNATIVE_H
 
+#include <asm/cpufeature.h>
+
 #ifndef __ASSEMBLY__
 
 #include <linux/init.h>
@@ -63,6 +65,8 @@ void apply_alternatives(void *start, size_t length);
 
 #else
 
+#include <asm/assembler.h>
+
 .macro altinstruction_entry orig_offset alt_offset feature orig_len alt_len
 	.word \orig_offset - .
 	.word \alt_offset - .
@@ -136,6 +140,74 @@ void apply_alternatives(void *start, size_t length);
 	alternative_insn insn1, insn2, cap, IS_ENABLED(cfg)
 
 
+/*
+ * Generate the assembly for UAO alternatives with exception table entries.
+ * This is complicated as there is no post-increment or pair versions of the
+ * unprivileged instructions, and USER() only works for single instructions.
+ */
+#ifdef CONFIG_ARM64_UAO
+	.macro uao_ldp l, reg1, reg2, addr, post_inc
+		alternative_if_not ARM64_HAS_UAO
+8888:			ldp	\reg1, \reg2, [\addr], \post_inc;
+8889:			nop;
+			nop;
+		alternative_else
+			ldtr	\reg1, [\addr];
+			ldtr	\reg2, [\addr, #8];
+			add	\addr, \addr, \post_inc;
+		alternative_endif
+
+		.section __ex_table,"a";
+		.align	3;
+		.quad	8888b,\l;
+		.quad	8889b,\l;
+		.previous;
+	.endm
+
+	.macro uao_stp l, reg1, reg2, addr, post_inc
+		alternative_if_not ARM64_HAS_UAO
+8888:			stp	\reg1, \reg2, [\addr], \post_inc;
+8889:			nop;
+			nop;
+		alternative_else
+			sttr	\reg1, [\addr];
+			sttr	\reg2, [\addr, #8];
+			add	\addr, \addr, \post_inc;
+		alternative_endif
+
+		.section __ex_table,"a";
+		.align	3;
+		.quad	8888b,\l;
+		.quad	8889b,\l;
+		.previous
+	.endm
+
+	.macro uao_user_alternative l, inst, alt_inst, reg, addr, post_inc
+		alternative_if_not ARM64_HAS_UAO
+8888:			\inst	\reg, [\addr], \post_inc;
+			nop;
+		alternative_else
+			\alt_inst	\reg, [\addr];
+			add		\addr, \addr, \post_inc;
+		alternative_endif
+
+		.section __ex_table,"a";
+		.align	3;
+		.quad	8888b,\l;
+		.previous
+	.endm
+#else
+	.macro uao_ldp l, reg1, reg2, addr, post_inc
+		USER(\l, ldp \reg1, \reg2, [\addr], \post_inc)
+	.endm
+	.macro uao_stp l, reg1, reg2, addr, post_inc
+		USER(\l, stp \reg1, \reg2, [\addr], \post_inc)
+	.endm
+	.macro uao_user_alternative l, inst, alt_inst, reg, addr, post_inc
+		USER(\l, \inst \reg, [\addr], \post_inc)
+	.endm
+#endif
+
 #endif  /*  __ASSEMBLY__  */
 
 /*
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index d28e8b27ee59..349e8203d16e 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -30,8 +30,9 @@
 #define ARM64_HAS_LSE_ATOMICS			5
 #define ARM64_WORKAROUND_CAVIUM_23154		6
 #define ARM64_WORKAROUND_834220			7
+#define ARM64_HAS_UAO				8
 
-#define ARM64_NCAPS				8
+#define ARM64_NCAPS				9
 
 #ifndef __ASSEMBLY__
 
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 4acb7ca94fcd..611ee4e5c89d 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -187,5 +187,6 @@ static inline void spin_lock_prefetch(const void *x)
 #endif
 
 void cpu_enable_pan(void *__unused);
+void cpu_enable_uao(void *__unused);
 
 #endif /* __ASM_PROCESSOR_H */
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 6d2cec2fcfd5..11378a92e50b 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -79,9 +79,12 @@
 #define SYS_DCZID_EL0			sys_reg(3, 3, 0, 0, 7)
 
 #define REG_PSTATE_PAN_IMM		sys_reg(0, 0, 4, 0, 4)
+#define REG_PSTATE_UAO_IMM		sys_reg(0, 0, 4, 0, 3)
 
 #define SET_PSTATE_PAN(x) __inst_arm(0xd5000000 | REG_PSTATE_PAN_IMM |\
 				     (!!x)<<8 | 0x1f)
+#define SET_PSTATE_UAO(x) __inst_arm(0xd5000000 | REG_PSTATE_UAO_IMM |\
+				     (!!x)<<8 | 0x1f)
 
 /* SCTLR_EL1 */
 #define SCTLR_EL1_CP15BEN	(0x1 << 5)
@@ -138,6 +141,9 @@
 #define ID_AA64MMFR1_VMIDBITS_SHIFT	4
 #define ID_AA64MMFR1_HADBS_SHIFT	0
 
+/* id_aa64mmfr2 */
+#define ID_AA64MMFR2_UAO_SHIFT		4
+
 /* id_aa64dfr0 */
 #define ID_AA64DFR0_CTX_CMPS_SHIFT	28
 #define ID_AA64DFR0_WRPS_SHIFT		20
diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
index abd64bd1f6d9..eba8db6838af 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -85,6 +85,12 @@ static inline struct thread_info *current_thread_info(void)
 	return (struct thread_info *)sp_el0;
 }
 
+/* Access struct thread_info of another thread */
+static inline struct thread_info *get_thread_info(unsigned long thread_stack)
+{
+	return (struct thread_info *)(thread_stack & ~(THREAD_SIZE - 1));
+}
+
 #define thread_saved_pc(tsk)	\
 	((unsigned long)(tsk->thread.cpu_context.pc))
 #define thread_saved_sp(tsk)	\
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index b2ede967fe7d..f973bdce8410 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -64,6 +64,16 @@ extern int fixup_exception(struct pt_regs *regs);
 static inline void set_fs(mm_segment_t fs)
 {
 	current_thread_info()->addr_limit = fs;
+
+	/*
+	 * Enable/disable UAO so that copy_to_user() etc can access
+	 * kernel memory with the unprivileged instructions.
+	 */
+	if (IS_ENABLED(CONFIG_ARM64_UAO) && fs == KERNEL_DS)
+		asm(ALTERNATIVE("nop", SET_PSTATE_UAO(1), ARM64_HAS_UAO));
+	else
+		asm(ALTERNATIVE("nop", SET_PSTATE_UAO(0), ARM64_HAS_UAO,
+				CONFIG_ARM64_UAO));
 }
 
 #define segment_eq(a, b)	((a) == (b))
@@ -113,9 +123,10 @@ static inline void set_fs(mm_segment_t fs)
  * The "__xxx_error" versions set the third argument to -EFAULT if an error
  * occurs, and leave it unchanged on success.
  */
-#define __get_user_asm(instr, reg, x, addr, err)			\
+#define __get_user_asm(instr, alt_instr, reg, x, addr, err, feature)	\
 	asm volatile(							\
-	"1:	" instr "	" reg "1, [%2]\n"			\
+	"1:"ALTERNATIVE(instr "     " reg "1, [%2]\n",			\
+			alt_instr " " reg "1, [%2]\n", feature)		\
 	"2:\n"								\
 	"	.section .fixup, \"ax\"\n"				\
 	"	.align	2\n"						\
@@ -138,16 +149,20 @@ do {									\
 			CONFIG_ARM64_PAN));				\
 	switch (sizeof(*(ptr))) {					\
 	case 1:								\
-		__get_user_asm("ldrb", "%w", __gu_val, (ptr), (err));	\
+		__get_user_asm("ldrb", "ldtrb", "%w", __gu_val, (ptr),  \
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	case 2:								\
-		__get_user_asm("ldrh", "%w", __gu_val, (ptr), (err));	\
+		__get_user_asm("ldrh", "ldtrh", "%w", __gu_val, (ptr),  \
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	case 4:								\
-		__get_user_asm("ldr", "%w", __gu_val, (ptr), (err));	\
+		__get_user_asm("ldr", "ldtr", "%w", __gu_val, (ptr),	\
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	case 8:								\
-		__get_user_asm("ldr", "%",  __gu_val, (ptr), (err));	\
+		__get_user_asm("ldr", "ldtr", "%",  __gu_val, (ptr),	\
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	default:							\
 		BUILD_BUG();						\
@@ -181,9 +196,10 @@ do {									\
 		((x) = 0, -EFAULT);					\
 })
 
-#define __put_user_asm(instr, reg, x, addr, err)			\
+#define __put_user_asm(instr, alt_instr, reg, x, addr, err, feature)	\
 	asm volatile(							\
-	"1:	" instr "	" reg "1, [%2]\n"			\
+	"1:"ALTERNATIVE(instr "     " reg "1, [%2]\n",			\
+			alt_instr " " reg "1, [%2]\n", feature)		\
 	"2:\n"								\
 	"	.section .fixup,\"ax\"\n"				\
 	"	.align	2\n"						\
@@ -205,16 +221,20 @@ do {									\
 			CONFIG_ARM64_PAN));				\
 	switch (sizeof(*(ptr))) {					\
 	case 1:								\
-		__put_user_asm("strb", "%w", __pu_val, (ptr), (err));	\
+		__put_user_asm("strb", "sttrb", "%w", __pu_val, (ptr),	\
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	case 2:								\
-		__put_user_asm("strh", "%w", __pu_val, (ptr), (err));	\
+		__put_user_asm("strh", "sttrh", "%w", __pu_val, (ptr),	\
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	case 4:								\
-		__put_user_asm("str",  "%w", __pu_val, (ptr), (err));	\
+		__put_user_asm("str", "sttr", "%w", __pu_val, (ptr),	\
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	case 8:								\
-		__put_user_asm("str",  "%", __pu_val, (ptr), (err));	\
+		__put_user_asm("str", "sttr", "%", __pu_val, (ptr),	\
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	default:							\
 		BUILD_BUG();						\
diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
index 208db3df135a..b5c3933ed441 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -45,6 +45,7 @@
 #define PSR_A_BIT	0x00000100
 #define PSR_D_BIT	0x00000200
 #define PSR_PAN_BIT	0x00400000
+#define PSR_UAO_BIT	0x00800000
 #define PSR_Q_BIT	0x08000000
 #define PSR_V_BIT	0x10000000
 #define PSR_C_BIT	0x20000000
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index a4f665f95f9f..b25c6a2c5e0f 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -124,6 +124,7 @@ static struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
 };
 
 static struct arm64_ftr_bits ftr_id_aa64mmfr2[] = {
+	ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR2_UAO_SHIFT, 4, 0),
 	ARM64_FTR_END,
 };
 
@@ -659,6 +660,17 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.min_field_value = 2,
 	},
 #endif /* CONFIG_AS_LSE && CONFIG_ARM64_LSE_ATOMICS */
+#ifdef CONFIG_ARM64_UAO
+	{
+		.desc = "User Access Override",
+		.capability = ARM64_HAS_UAO,
+		.matches = has_cpuid_feature,
+		.sys_reg = SYS_ID_AA64MMFR2_EL1,
+		.field_pos = ID_AA64MMFR2_UAO_SHIFT,
+		.min_field_value = 1,
+		.enable = cpu_enable_uao,
+	},
+#endif /* CONFIG_ARM64_UAO */
 	{},
 };
 
@@ -937,3 +949,16 @@ void __init setup_cpu_features(void)
 		pr_warn("L1_CACHE_BYTES smaller than the Cache Writeback Granule (%d < %d)\n",
 			L1_CACHE_BYTES, cls);
 }
+
+#ifdef CONFIG_ARM64_UAO
+/*
+ * Kernel threads have fs=KERNEL_DS by default, and don't need to call
+ * set_fs(), devtmpfs in particular relies on this behaviour.
+ * We need to enable the feature at runtime (instead of adding it to
+ * PSR_MODE_EL1h) as the feature may not be implemented by the cpu.
+ */
+void cpu_enable_uao(void *__unused)
+{
+	asm(SET_PSTATE_UAO(1));
+}
+#endif /* CONFIG_ARM64_UAO */
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 88d742ba19d5..8fcf582c18d7 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -46,6 +46,7 @@
 #include <linux/notifier.h>
 #include <trace/events/power.h>
 
+#include <asm/alternative.h>
 #include <asm/compat.h>
 #include <asm/cacheflush.h>
 #include <asm/fpsimd.h>
@@ -280,6 +281,9 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
 	} else {
 		memset(childregs, 0, sizeof(struct pt_regs));
 		childregs->pstate = PSR_MODE_EL1h;
+		if (IS_ENABLED(CONFIG_ARM64_UAO) &&
+		    cpus_have_cap(ARM64_HAS_UAO))
+			childregs->pstate |= PSR_UAO_BIT;
 		p->thread.cpu_context.x19 = stack_start;
 		p->thread.cpu_context.x20 = stk_sz;
 	}
@@ -308,6 +312,20 @@ static void tls_thread_switch(struct task_struct *next)
 	: : "r" (tpidr), "r" (tpidrro));
 }
 
+/* Restore the UAO state depending on next's addr_limit */
+static void uao_thread_switch(struct task_struct *next)
+{
+	unsigned long next_sp = next->thread.cpu_context.sp;
+
+	if (IS_ENABLED(CONFIG_ARM64_UAO) &&
+	    get_thread_info(next_sp)->addr_limit == KERNEL_DS)
+		asm(ALTERNATIVE("nop", SET_PSTATE_UAO(1), ARM64_HAS_UAO,
+			        CONFIG_ARM64_UAO));
+	else
+		asm(ALTERNATIVE("nop", SET_PSTATE_UAO(0), ARM64_HAS_UAO,
+				CONFIG_ARM64_UAO));
+}
+
 /*
  * Thread switching.
  */
@@ -327,6 +345,8 @@ struct task_struct *__switch_to(struct task_struct *prev,
 	 */
 	dsb(ish);
 
+	uao_thread_switch(next);
+
 	/* the actual thread switch */
 	last = cpu_switch_to(prev, next);
 
diff --git a/arch/arm64/lib/clear_user.S b/arch/arm64/lib/clear_user.S
index a9723c71c52b..3f950b677c07 100644
--- a/arch/arm64/lib/clear_user.S
+++ b/arch/arm64/lib/clear_user.S
@@ -39,20 +39,20 @@ ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
 	subs	x1, x1, #8
 	b.mi	2f
 1:
-USER(9f, str	xzr, [x0], #8	)
+uao_user_alternative 9f, str, sttr, xzr, x0, 8
 	subs	x1, x1, #8
 	b.pl	1b
 2:	adds	x1, x1, #4
 	b.mi	3f
-USER(9f, str	wzr, [x0], #4	)
+uao_user_alternative 9f, str, sttr, wzr, x0, 4
 	sub	x1, x1, #4
 3:	adds	x1, x1, #2
 	b.mi	4f
-USER(9f, strh	wzr, [x0], #2	)
+uao_user_alternative 9f, strh, sttrh, wzr, x0, 2
 	sub	x1, x1, #2
 4:	adds	x1, x1, #1
 	b.mi	5f
-USER(9f, strb	wzr, [x0]	)
+uao_user_alternative 9f, strb, sttrb, wzr, x0, 0
 5:	mov	x0, #0
 ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
 	    CONFIG_ARM64_PAN)
diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
index 4699cd74f87e..1d982d64f1a7 100644
--- a/arch/arm64/lib/copy_from_user.S
+++ b/arch/arm64/lib/copy_from_user.S
@@ -34,7 +34,7 @@
  */
 
 	.macro ldrb1 ptr, regB, val
-	USER(9998f, ldrb  \ptr, [\regB], \val)
+	uao_user_alternative 9998f, ldrb, ldtrb, \ptr, \regB, \val
 	.endm
 
 	.macro strb1 ptr, regB, val
@@ -42,7 +42,7 @@
 	.endm
 
 	.macro ldrh1 ptr, regB, val
-	USER(9998f, ldrh  \ptr, [\regB], \val)
+	uao_user_alternative 9998f, ldrh, ldtrh, \ptr, \regB, \val
 	.endm
 
 	.macro strh1 ptr, regB, val
@@ -50,7 +50,7 @@
 	.endm
 
 	.macro ldr1 ptr, regB, val
-	USER(9998f, ldr \ptr, [\regB], \val)
+	uao_user_alternative 9998f, ldr, ldtr, \ptr, \regB, \val
 	.endm
 
 	.macro str1 ptr, regB, val
@@ -58,7 +58,7 @@
 	.endm
 
 	.macro ldp1 ptr, regB, regC, val
-	USER(9998f, ldp \ptr, \regB, [\regC], \val)
+	uao_ldp 9998f, \ptr, \regB, \regC, \val
 	.endm
 
 	.macro stp1 ptr, regB, regC, val
diff --git a/arch/arm64/lib/copy_in_user.S b/arch/arm64/lib/copy_in_user.S
index 81c8fc93c100..feaad1520dc1 100644
--- a/arch/arm64/lib/copy_in_user.S
+++ b/arch/arm64/lib/copy_in_user.S
@@ -35,35 +35,35 @@
  *	x0 - bytes not copied
  */
 	.macro ldrb1 ptr, regB, val
-	USER(9998f, ldrb  \ptr, [\regB], \val)
+	uao_user_alternative 9998f, ldrb, ldtrb, \ptr, \regB, \val
 	.endm
 
 	.macro strb1 ptr, regB, val
-	USER(9998f, strb \ptr, [\regB], \val)
+	uao_user_alternative 9998f, strb, sttrb, \ptr, \regB, \val
 	.endm
 
 	.macro ldrh1 ptr, regB, val
-	USER(9998f, ldrh  \ptr, [\regB], \val)
+	uao_user_alternative 9998f, ldrh, ldtrh, \ptr, \regB, \val
 	.endm
 
 	.macro strh1 ptr, regB, val
-	USER(9998f, strh \ptr, [\regB], \val)
+	uao_user_alternative 9998f, strh, sttrh, \ptr, \regB, \val
 	.endm
 
 	.macro ldr1 ptr, regB, val
-	USER(9998f, ldr \ptr, [\regB], \val)
+	uao_user_alternative 9998f, ldr, ldtr, \ptr, \regB, \val
 	.endm
 
 	.macro str1 ptr, regB, val
-	USER(9998f, str \ptr, [\regB], \val)
+	uao_user_alternative 9998f, str, sttr, \ptr, \regB, \val
 	.endm
 
 	.macro ldp1 ptr, regB, regC, val
-	USER(9998f, ldp \ptr, \regB, [\regC], \val)
+	uao_ldp 9998f, \ptr, \regB, \regC, \val
 	.endm
 
 	.macro stp1 ptr, regB, regC, val
-	USER(9998f, stp \ptr, \regB, [\regC], \val)
+	uao_stp 9998f, \ptr, \regB, \regC, \val
 	.endm
 
 end	.req	x5
diff --git a/arch/arm64/lib/copy_to_user.S b/arch/arm64/lib/copy_to_user.S
index 7512bbbc07ac..2dae2cd2c481 100644
--- a/arch/arm64/lib/copy_to_user.S
+++ b/arch/arm64/lib/copy_to_user.S
@@ -37,7 +37,7 @@
 	.endm
 
 	.macro strb1 ptr, regB, val
-	USER(9998f, strb \ptr, [\regB], \val)
+	uao_user_alternative 9998f, strb, sttrb, \ptr, \regB, \val
 	.endm
 
 	.macro ldrh1 ptr, regB, val
@@ -45,7 +45,7 @@
 	.endm
 
 	.macro strh1 ptr, regB, val
-	USER(9998f, strh \ptr, [\regB], \val)
+	uao_user_alternative 9998f, strh, sttrh, \ptr, \regB, \val
 	.endm
 
 	.macro ldr1 ptr, regB, val
@@ -53,7 +53,7 @@
 	.endm
 
 	.macro str1 ptr, regB, val
-	USER(9998f, str \ptr, [\regB], \val)
+	uao_user_alternative 9998f, str, sttr, \ptr, \regB, \val
 	.endm
 
 	.macro ldp1 ptr, regB, regC, val
@@ -61,7 +61,7 @@
 	.endm
 
 	.macro stp1 ptr, regB, regC, val
-	USER(9998f, stp \ptr, \regB, [\regC], \val)
+	uao_stp 9998f, \ptr, \regB, \regC, \val
 	.endm
 
 end	.req	x5
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 92ddac1e8ca2..5ce2656b04df 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -192,6 +192,14 @@ out:
 	return fault;
 }
 
+static inline int permission_fault(unsigned int esr)
+{
+	unsigned int ec       = (esr & ESR_ELx_EC_MASK)>>ESR_ELx_EC_SHIFT;
+	unsigned int fsc_type = esr & ESR_ELx_FSC_TYPE;
+
+	return (ec == ESR_ELx_EC_DABT_CUR && fsc_type == ESR_ELx_FSC_PERM);
+}
+
 static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
 				   struct pt_regs *regs)
 {
@@ -225,12 +233,10 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
 		mm_flags |= FAULT_FLAG_WRITE;
 	}
 
-	/*
-	 * PAN bit set implies the fault happened in kernel space, but not
-	 * in the arch's user access functions.
-	 */
-	if (IS_ENABLED(CONFIG_ARM64_PAN) && (regs->pstate & PSR_PAN_BIT))
-		goto no_context;
+	if (permission_fault(esr) && (addr < USER_DS)) {
+		if (!search_exception_tables(regs->pc))
+			panic("Accessing user space memory outside uaccess.h routines");
+	}
 
 	/*
 	 * As per x86, we may deadlock here. However, since the kernel only
-- 
2.6.2



From james.morse at arm.com  Tue Feb  2 09:03:31 2016
From: james.morse at arm.com (James Morse)
Date: Tue,  2 Feb 2016 17:03:31 +0000
Subject: [PATCH v1 5/5] arm64: kernel: Don't toggle PAN on systems with UAO
In-Reply-To: <1454432611-21333-1-git-send-email-james.morse@arm.com>
References: <1454432611-21333-1-git-send-email-james.morse@arm.com>
Message-ID: <1454432611-21333-6-git-send-email-james.morse@arm.com>

If a CPU supports both Privileged Access Never (PAN) and User Access
Override (UAO), we don't need to disable/re-enable PAN round all
copy_to_user() like calls.

UAO alternatives cause these calls to use the 'unprivileged' load/store
instructions, which are overridden to be the privileged kind when
fs==KERNEL_DS.

This patch changes the copy_to_user() calls to have their PAN toggling
depend on a new composite 'feature' ARM64_ALT_PAN_NOT_UAO.

If both features are detected, PAN will be enabled, but the copy_to_user()
alternatives will not be applied. This means PAN will be enabled all the
time for these functions. If only PAN is detected, the toggling will be
enabled as normal.

This will save the time taken to disable/re-enable PAN, and allow us to
catch copy_to_user() accesses that occur with fs==KERNEL_DS.

Futex and swp-emulation code continue to hang their PAN toggling code on
ARM64_HAS_PAN.

Signed-off-by: James Morse <james.morse at arm.com>
---
 arch/arm64/include/asm/cpufeature.h |  3 ++-
 arch/arm64/include/asm/uaccess.h    |  8 ++++----
 arch/arm64/kernel/cpufeature.c      | 16 ++++++++++++++++
 arch/arm64/lib/clear_user.S         |  4 ++--
 arch/arm64/lib/copy_from_user.S     |  4 ++--
 arch/arm64/lib/copy_in_user.S       |  4 ++--
 arch/arm64/lib/copy_to_user.S       |  4 ++--
 arch/arm64/mm/fault.c               |  3 +++
 8 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 349e8203d16e..7ae0d90a21ed 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -31,8 +31,9 @@
 #define ARM64_WORKAROUND_CAVIUM_23154		6
 #define ARM64_WORKAROUND_834220			7
 #define ARM64_HAS_UAO				8
+#define ARM64_ALT_PAN_NOT_UAO			9
 
-#define ARM64_NCAPS				9
+#define ARM64_NCAPS				10
 
 #ifndef __ASSEMBLY__
 
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index f973bdce8410..16ba0d5c9740 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -145,7 +145,7 @@ static inline void set_fs(mm_segment_t fs)
 do {									\
 	unsigned long __gu_val;						\
 	__chk_user_ptr(ptr);						\
-	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), ARM64_HAS_PAN,	\
+	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), ARM64_ALT_PAN_NOT_UAO,\
 			CONFIG_ARM64_PAN));				\
 	switch (sizeof(*(ptr))) {					\
 	case 1:								\
@@ -168,7 +168,7 @@ do {									\
 		BUILD_BUG();						\
 	}								\
 	(x) = (__force __typeof__(*(ptr)))__gu_val;			\
-	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN,	\
+	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_ALT_PAN_NOT_UAO,\
 			CONFIG_ARM64_PAN));				\
 } while (0)
 
@@ -217,7 +217,7 @@ do {									\
 do {									\
 	__typeof__(*(ptr)) __pu_val = (x);				\
 	__chk_user_ptr(ptr);						\
-	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), ARM64_HAS_PAN,	\
+	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), ARM64_ALT_PAN_NOT_UAO,\
 			CONFIG_ARM64_PAN));				\
 	switch (sizeof(*(ptr))) {					\
 	case 1:								\
@@ -239,7 +239,7 @@ do {									\
 	default:							\
 		BUILD_BUG();						\
 	}								\
-	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN,	\
+	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_ALT_PAN_NOT_UAO,\
 			CONFIG_ARM64_PAN));				\
 } while (0)
 
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index caecc9a81b82..3456f0847a3c 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -67,6 +67,10 @@ DECLARE_BITMAP(cpu_hwcaps, ARM64_NCAPS);
 		.width = 0,				\
 	}
 
+/* meta feature for alternatives */
+static bool __maybe_unused
+cpufeature_pan_not_uao(const struct arm64_cpu_capabilities *entry);
+
 static struct arm64_ftr_bits ftr_id_aa64isar0[] = {
 	ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 32, 32, 0),
 	ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64ISAR0_RDM_SHIFT, 4, 0),
@@ -671,6 +675,12 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.enable = cpu_enable_uao,
 	},
 #endif /* CONFIG_ARM64_UAO */
+#ifdef CONFIG_ARM64_PAN
+	{
+		.capability = ARM64_ALT_PAN_NOT_UAO,
+		.matches = cpufeature_pan_not_uao,
+	},
+#endif /* CONFIG_ARM64_PAN */
 	{},
 };
 
@@ -962,3 +972,9 @@ void cpu_enable_uao(void *__unused)
 	asm(SET_PSTATE_UAO(1));
 }
 #endif /* CONFIG_ARM64_UAO */
+
+static bool __maybe_unused
+cpufeature_pan_not_uao(const struct arm64_cpu_capabilities *entry)
+{
+	return (cpus_have_cap(ARM64_HAS_PAN) && !cpus_have_cap(ARM64_HAS_UAO));
+}
diff --git a/arch/arm64/lib/clear_user.S b/arch/arm64/lib/clear_user.S
index 3f950b677c07..5d1cad3ce6d6 100644
--- a/arch/arm64/lib/clear_user.S
+++ b/arch/arm64/lib/clear_user.S
@@ -33,7 +33,7 @@
  * Alignment fixed up by hardware.
  */
 ENTRY(__clear_user)
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	mov	x2, x1			// save the size for fixup return
 	subs	x1, x1, #8
@@ -54,7 +54,7 @@ uao_user_alternative 9f, strh, sttrh, wzr, x0, 2
 	b.mi	5f
 uao_user_alternative 9f, strb, sttrb, wzr, x0, 0
 5:	mov	x0, #0
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	ret
 ENDPROC(__clear_user)
diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
index 1d982d64f1a7..17e8306dca29 100644
--- a/arch/arm64/lib/copy_from_user.S
+++ b/arch/arm64/lib/copy_from_user.S
@@ -67,11 +67,11 @@
 
 end	.req	x5
 ENTRY(__copy_from_user)
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	add	end, x0, x2
 #include "copy_template.S"
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	mov	x0, #0				// Nothing to copy
 	ret
diff --git a/arch/arm64/lib/copy_in_user.S b/arch/arm64/lib/copy_in_user.S
index feaad1520dc1..f7292dd08c84 100644
--- a/arch/arm64/lib/copy_in_user.S
+++ b/arch/arm64/lib/copy_in_user.S
@@ -68,11 +68,11 @@
 
 end	.req	x5
 ENTRY(__copy_in_user)
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	add	end, x0, x2
 #include "copy_template.S"
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	mov	x0, #0
 	ret
diff --git a/arch/arm64/lib/copy_to_user.S b/arch/arm64/lib/copy_to_user.S
index 2dae2cd2c481..21faae60f988 100644
--- a/arch/arm64/lib/copy_to_user.S
+++ b/arch/arm64/lib/copy_to_user.S
@@ -66,11 +66,11 @@
 
 end	.req	x5
 ENTRY(__copy_to_user)
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	add	end, x0, x2
 #include "copy_template.S"
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	mov	x0, #0
 	ret
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 5ce2656b04df..5dd40909cbce 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -234,6 +234,9 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
 	}
 
 	if (permission_fault(esr) && (addr < USER_DS)) {
+		if (get_thread_info(regs->sp)->addr_limit == KERNEL_DS)
+			panic("Accessing user space memory with fs=KERNEL_DS");
+
 		if (!search_exception_tables(regs->pc))
 			panic("Accessing user space memory outside uaccess.h routines");
 	}
-- 
2.6.2



From paul at pwsan.com  Tue Feb  2 09:15:15 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 2 Feb 2016 17:15:15 +0000 (UTC)
Subject: OMAP baseline test results for v4.5-rc2
Message-ID: <alpine.DEB.2.02.1602021713541.20554@utopia.booyaka.com>


Here are some basic OMAP test results for Linux v4.5-rc2.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v4.5-rc2/20160131225233/


Test summary
------------

Build: uImage:
    Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only,
		  omap1_defconfig_5912osk_only

Build: uImage+dtb:
    Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone,
		  omap2plus_defconfig/omap4-panda,
		  omap2plus_defconfig/omap4-panda-es,
		  omap2plus_defconfig/omap4-var-stk-om44,
		  omap2plus_defconfig/omap3-evm-37xx,
		  omap2plus_defconfig_n800_only_a/omap2420-n800,
		  omap2plus_defconfig/omap2430-sdp,
		  omap2plus_defconfig/am3517-evm,
		  omap2plus_defconfig/omap3-beagle,
		  omap2plus_defconfig/omap3-beagle-xm,
		  omap2plus_defconfig/omap3-sbc-t3517,
		  omap2plus_defconfig/omap5-uevm,
		  omap2plus_defconfig/omap5-sbc-t54

Build: zImage:
    Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
		  omap2plus_defconfig_n800_only_a,
		  omap2plus_defconfig_n800_multi_omap2xxx,
		  omap2plus_defconfig_2430sdp_only,
		  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
		  omap2plus_defconfig_omap2_4_only,
		  omap2plus_defconfig_omap3_4_only,
		  omap2plus_defconfig_omap5_only,
		  omap2plus_defconfig_dra7xx_only,
		  omap2plus_defconfig_am43xx_only,
		  rmk_omap3430_ldp_oldconfig,
		  rmk_omap3430_ldp_allnoconfig,
		  rmk_omap4430_sdp_oldconfig,
		  rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig

Build warnings from toolchain: uImage:
    (none)

Build warnings from toolchain: uImage+dtb:
    (none)

Build warnings from toolchain: zImage:
    FAIL ( 1/17): multi_v7_defconfig

Boot to userspace:
    FAIL ( 1/18): 2430sdp
    skip ( 3/18): 5912osk, 3517evm, 5430es2sbct54
    Pass (14/18): am335xbonelt, am437xsk, am335xbone, 4430es2panda,
		  4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle,
		  3530es31beagle, 3730beaglexm, 3730es12beaglexm,
		  cmt3517, 5430es2uevm, 2420n800

Kernel warnings during boot to userspace:
    FAIL ( 1/18): cmt3517

PM: chip retention via suspend:
    FAIL ( 7/11): am335xbonelt, 4430es2panda, 4460pandaes,
		  4460varsomom, 37xxevm, 2430sdp, 5430es2uevm
    Pass ( 4/11): 3530es3beagle, 3530es31beagle, 3730beaglexm,
		  3730es12beaglexm

PM: chip retention via dynamic idle:
    FAIL ( 9/11): am335xbonelt, 4430es2panda, 4460pandaes,
		  4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle,
		  2430sdp, 5430es2uevm
    Pass ( 2/11): 3730beaglexm, 3730es12beaglexm

PM: chip off (except CORE, due to errata) via suspend:
    Pass ( 1/ 1): 3730beaglexm

PM: chip off (except CORE, due to errata) via dynamic idle:
    Pass ( 1/ 1): 3730beaglexm

PM: chip off via suspend:
    FAIL ( 2/ 4): 37xxevm, 3530es3beagle
    Pass ( 2/ 4): 3530es31beagle, 3730es12beaglexm

PM: chip off via dynamic idle:
    FAIL ( 3/ 4): 37xxevm, 3530es3beagle, 3530es31beagle
    Pass ( 1/ 4): 3730es12beaglexm

Kernel warnings during PM test:
    (none)

Obsolete Kconfig symbols:
    FAIL ( 3/20): omap1_defconfig, omap2plus_defconfig,
		  multi_v7_defconfig


vmlinux object size
(delta in bytes from test_v4.5-rc1 (92e963f50fc74041b5e9e744c330dca48e04f08d)):
   text     data      bss    total  kernel
   +473       -8      -32     +433  omap1_defconfig
   +473        0      -32     +441  omap1_defconfig_1510innovator_only
   +557       -8      -32     +517  omap1_defconfig_5912osk_only
   +660     +128        0     +788  multi_v7_defconfig
   +133      +32        0     +165  omap2plus_defconfig
   +109      +24      -32     +101  omap2plus_defconfig_2430sdp_only
    +41      +32        0      +73  omap2plus_defconfig_am33xx_only
    +45      +32        0      +77  omap2plus_defconfig_am43xx_only
    +69      +32        0     +101  omap2plus_defconfig_cpupm
    -19      +24        0       +5  omap2plus_defconfig_dra7xx_only
    +21       -8      -32      -19  omap2plus_defconfig_n800_multi_omap2xxx
   +441      +24      -32     +433  omap2plus_defconfig_n800_only_a
   +129      +24        0     +153  omap2plus_defconfig_no_pm
   +133      +32        0     +165  omap2plus_defconfig_omap2_4_only
    -19      +32        0      +13  omap2plus_defconfig_omap3_4_only
    -19      +32        0      +13  omap2plus_defconfig_omap5_only
   +376        0        0     +376  rmk_omap3430_ldp_allnoconfig
   +257        0        0     +257  rmk_omap3430_ldp_oldconfig
   +376        0        0     +376  rmk_omap4430_sdp_allnoconfig
   +281        0        0     +281  rmk_omap4430_sdp_oldconfig

Boot-time memory difference
(delta in bytes from test_v4.5-rc1 (92e963f50fc74041b5e9e744c330dca48e04f08d))
  avail  rsrvd   high  freed  board          kconfig
  (no differences)



From emil.l.velikov at gmail.com  Tue Feb  2 09:19:15 2016
From: emil.l.velikov at gmail.com (Emil Velikov)
Date: Tue, 2 Feb 2016 17:19:15 +0000
Subject: [PATCH v3 1/2] clk: sunxi: Add sun6i/8i video support
In-Reply-To: <8fdfe5fe7715f19416d654964e55721b30237b38.1454427224.git.moinejf@free.fr>
References: <cover.1454427223.git.moinejf@free.fr>
 <8fdfe5fe7715f19416d654964e55721b30237b38.1454427224.git.moinejf@free.fr>
Message-ID: <CACvgo53f8Sr_dEAx_mcvjXciK01mY7TUDguOJ-HzNur-PpmMZw@mail.gmail.com>

Hi Jean-Francois,

On 1 February 2016 at 07:43, Jean-Francois Moine <moinejf at free.fr> wrote:
> Add the clock types which are used by the sun6i/8i families for video.
>
> Signed-off-by: Jean-Francois Moine <moinejf at free.fr>
> ---
> v3: (no change)
> v2:
>         - remarks from Chen-Yu Tsai
>         - DT documentation added
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt |   2 +
>  drivers/clk/sunxi/clk-sun6i-display.c             | 106 +++++++++++++
>  drivers/clk/sunxi/clk-sun6i-pll3.c                | 174 ++++++++++++++++++++++
>  3 files changed, 282 insertions(+)
>  create mode 100644 drivers/clk/sunxi/clk-sun6i-display.c
>  create mode 100644 drivers/clk/sunxi/clk-sun6i-pll3.c
>
Something is missing here - namely the changes to the Makefile. Does
this series work or did you simply forget git add ?

Regards,
Emil


From chris.brandt at renesas.com  Tue Feb  2 09:19:00 2016
From: chris.brandt at renesas.com (Chris Brandt)
Date: Tue,  2 Feb 2016 12:19:00 -0500
Subject: [PATCH v5] ARM: xip: Use correct symbol for end of ROM marker
In-Reply-To: <1454349165-12249-1-git-send-email-chris.brandt@renesas.com>
References: <1454349165-12249-1-git-send-email-chris.brandt@renesas.com>
Message-ID: <1454433540-25948-1-git-send-email-chris.brandt@renesas.com>

For an XIP build, _etext does not represent the end of the
binary image that needs to stay mapped into the MODULES_VADDR area.
Years ago, data came before text in the memory map. However,
now that the order is text/init/data, an XIP_KERNEL needs to map
up to the data location in order to keep from cutting off
parts of the kernel that are needed.
We only map up to the beginning of data because data has already been
copied, so there's no reason to keep it around anymore.

This fixes the bug where you might lose the end of your kernel area
after page table setup is complete.

Signed-off-by: Chris Brandt <chris.brandt at renesas.com>
---
v5:
* Switched from using __data_loc to _exiprom (new symbol)
v4:
* Switched from using _edata_loc __data_loc.
* Made commit text more accurate.
v3:
* Removed sections.h from Kbuild
v2:
* Added change for MODULES_VADDR
* Moved extern to new file asm/sections.h
---
 arch/arm/include/asm/Kbuild     | 1 -
 arch/arm/include/asm/sections.h | 8 ++++++++
 arch/arm/kernel/module.c        | 2 +-
 arch/arm/kernel/vmlinux.lds.S   | 2 ++
 arch/arm/mm/mmu.c               | 8 ++++++--
 5 files changed, 17 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/include/asm/sections.h

diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
index 16da638..3f6616b 100644
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@ -23,7 +23,6 @@ generic-y += preempt.h
 generic-y += resource.h
 generic-y += rwsem.h
 generic-y += seccomp.h
-generic-y += sections.h
 generic-y += segment.h
 generic-y += sembuf.h
 generic-y += serial.h
diff --git a/arch/arm/include/asm/sections.h b/arch/arm/include/asm/sections.h
new file mode 100644
index 0000000..803bbf2
--- /dev/null
+++ b/arch/arm/include/asm/sections.h
@@ -0,0 +1,8 @@
+#ifndef _ASM_ARM_SECTIONS_H
+#define _ASM_ARM_SECTIONS_H
+
+#include <asm-generic/sections.h>
+
+extern char _exiprom[];
+
+#endif	/* _ASM_ARM_SECTIONS_H */
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index efdddcb..4f14b5c 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -34,7 +34,7 @@
  * recompiling the whole kernel when CONFIG_XIP_KERNEL is turned on/off.
  */
 #undef MODULES_VADDR
-#define MODULES_VADDR	(((unsigned long)_etext + ~PMD_MASK) & PMD_MASK)
+#define MODULES_VADDR	(((unsigned long)_exiprom + ~PMD_MASK) & PMD_MASK)
 #endif
 
 #ifdef CONFIG_MMU
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 8b60fde..d18e4e5 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -86,6 +86,7 @@ SECTIONS
 
 #ifdef CONFIG_XIP_KERNEL
 	. = XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR);
+	_xiprom = .;			/* XIP ROM area to be mapped */
 #else
 	. = PAGE_OFFSET + TEXT_OFFSET;
 #endif
@@ -228,6 +229,7 @@ SECTIONS
 #endif
 
 #ifdef CONFIG_XIP_KERNEL
+	_exiprom = .;			/* End of XIP ROM area */
 	__data_loc = ALIGN(4);		/* location in binary */
 	. = PAGE_OFFSET + TEXT_OFFSET;
 #else
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 434d76f..e4b681a 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1253,7 +1253,7 @@ static inline void prepare_page_table(void)
 
 #ifdef CONFIG_XIP_KERNEL
 	/* The XIP kernel is mapped in the module area -- skip over it */
-	addr = ((unsigned long)_etext + PMD_SIZE - 1) & PMD_MASK;
+	addr = ((unsigned long)_exiprom + PMD_SIZE - 1) & PMD_MASK;
 #endif
 	for ( ; addr < PAGE_OFFSET; addr += PMD_SIZE)
 		pmd_clear(pmd_off_k(addr));
@@ -1335,7 +1335,7 @@ static void __init devicemaps_init(const struct machine_desc *mdesc)
 #ifdef CONFIG_XIP_KERNEL
 	map.pfn = __phys_to_pfn(CONFIG_XIP_PHYS_ADDR & SECTION_MASK);
 	map.virtual = MODULES_VADDR;
-	map.length = ((unsigned long)_etext - map.virtual + ~SECTION_MASK) & SECTION_MASK;
+	map.length = ((unsigned long)_exiprom - map.virtual + ~SECTION_MASK) & SECTION_MASK;
 	map.type = MT_ROM;
 	create_mapping(&map);
 #endif
@@ -1426,7 +1426,11 @@ static void __init kmap_init(void)
 static void __init map_lowmem(void)
 {
 	struct memblock_region *reg;
+#ifdef CONFIG_XIP_KERNEL
+	phys_addr_t kernel_x_start = round_down(__pa(_sdata), SECTION_SIZE);
+#else
 	phys_addr_t kernel_x_start = round_down(__pa(_stext), SECTION_SIZE);
+#endif
 	phys_addr_t kernel_x_end = round_up(__pa(__init_end), SECTION_SIZE);
 
 	/* Map all the lowmem memory banks. */
-- 
1.9.1




From jslaby at suse.cz  Tue Feb  2 09:19:44 2016
From: jslaby at suse.cz (Jiri Slaby)
Date: Tue, 2 Feb 2016 18:19:44 +0100
Subject: [PATCH v6] kernel: add kcov code coverage
In-Reply-To: <1453726850-49137-1-git-send-email-dvyukov@google.com>
References: <1453726850-49137-1-git-send-email-dvyukov@google.com>
Message-ID: <56B0E530.8090908@suse.cz>

On 01/25/2016, 02:00 PM, Dmitry Vyukov wrote:
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -136,6 +136,12 @@ _c_flags += $(if $(patsubst n%,, \
>  		$(CFLAGS_UBSAN))
>  endif
>  
> +ifeq ($(CONFIG_KCOV),y)
> +_c_flags += $(if $(patsubst n%,, \
> +	$(KCOV_INSTRUMENT_$(basetarget).o)$(KCOV_INSTRUMENT)y), \
> +	$(CFLAGS_KCOV))

Now that KCOV does not inherit KASAN's "n"s, I see link errors in efi
lib with EFI_STUB:
drivers/firmware/efi/libstub/lib.a(efi-stub-helper.o): In function
`efi_printk':
efi-stub-helper.c:(.text+0x13): undefined reference to
`__sanitizer_cov_trace_pc'
efi-stub-helper.c:(.text+0x31): undefined reference to
`__sanitizer_cov_trace_pc'
...

I fixed it by adding "KCOV_INSTRUMENT := n" to
  drivers/firmware/efi/libstub/Makefile

thanks,
-- 
js
suse labs


From moinejf at free.fr  Tue Feb  2 09:19:49 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Tue, 2 Feb 2016 18:19:49 +0100
Subject: [PATCH v2 2/2] drm: sunxi: Add a basic DRM driver for Allwinner
 DE2
In-Reply-To: <569F6C1E.8000006@arm.com>
References: <cover.1452876522.git.moinejf@free.fr>
 <4c40052b27f74df1342e631cb0f9ed5993861a54.1452876522.git.moinejf@free.fr>
 <569F6C1E.8000006@arm.com>
Message-ID: <20160202181949.d59e84a040a980abcdd69d32@free.fr>

On Wed, 20 Jan 2016 11:14:38 +0000
Andre Przywara <andre.przywara at arm.com> wrote:

> I haven't looked at it in detail yet, I just tried to compile it for
> ARM64 to prepare for a test on the Allwinner A64.
> 
> So just two things I spotted below:

Hi Andr?,

I fixed them in the v3 patch request.
Have you succeeded to get video on the A64?

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/



From rabin at rab.in  Tue Feb  2 09:25:31 2016
From: rabin at rab.in (Rabin Vincent)
Date: Tue, 2 Feb 2016 18:25:31 +0100
Subject: [PATCH v2] recordmcount: arm: Implement make_nop
In-Reply-To: <1454371583-9064-1-git-send-email-sboyd@codeaurora.org>
References: <1454371583-9064-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <20160202172531.GA9044@debian>

On Mon, Feb 01, 2016 at 04:06:23PM -0800, Stephen Boyd wrote:
> In similar spirit to x86 and arm64 support, add a make_nop_arm()
> to replace calls to mcount with nops in sections that aren't
> traced.
> 
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Rabin Vincent <rabin at rab.in>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
> 
> Changes from v1:
>  * Replace with nops instead of pops
>  * Check for BE or LE kernel with elf headers
>  * Drop mcount style check because now we look at the previous
>    instruction to determine if it's a push (__gnu_mcount_nc) or not (mcount).

Acked-by: Rabin Vincent <rabin at rab.in>


From andre.przywara at arm.com  Tue Feb  2 09:26:13 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 2 Feb 2016 17:26:13 +0000
Subject: [PATCH v2 2/2] drm: sunxi: Add a basic DRM driver for Allwinner
 DE2
In-Reply-To: <20160202181949.d59e84a040a980abcdd69d32@free.fr>
References: <cover.1452876522.git.moinejf@free.fr>
 <4c40052b27f74df1342e631cb0f9ed5993861a54.1452876522.git.moinejf@free.fr>
 <569F6C1E.8000006@arm.com> <20160202181949.d59e84a040a980abcdd69d32@free.fr>
Message-ID: <56B0E6B5.5040708@arm.com>

Hi,

On 02/02/16 17:19, Jean-Francois Moine wrote:
> On Wed, 20 Jan 2016 11:14:38 +0000
> Andre Przywara <andre.przywara at arm.com> wrote:
> 
>> I haven't looked at it in detail yet, I just tried to compile it for
>> ARM64 to prepare for a test on the Allwinner A64.
>>
>> So just two things I spotted below:
> 
> Hi Andr?,
> 
> I fixed them in the v3 patch request.

Thanks for that.

> Have you succeeded to get video on the A64?

No, but I haven't tried yet. I am tempted to give it a go, though. I
guess this "headless Linux" term has scared some backers, who had more
associations with Sleepy Hollow than with a serial terminal ;-)

Can you sketch (or point me to) what I need to do? Just a
simple-framebuffer DT node?
I take it that the driver does not depend on any kind of U-Boot
initialisation, but instead takes care of this itself?

And would this pave the way for fbturbo also?

Please excuse my probably silly questions, I am more of a headless
horseman ;-)

Cheers,
Andre.


From rabin at rab.in  Tue Feb  2 09:31:41 2016
From: rabin at rab.in (Rabin Vincent)
Date: Tue, 2 Feb 2016 18:31:41 +0100
Subject: [PATCH] recordmcount: arm: Implement make_nop
In-Reply-To: <20160201194432.GK4848@codeaurora.org>
References: <1454116686-30190-1-git-send-email-sboyd@codeaurora.org>
 <20160130184005.GA29607@debian>
 <20160201194432.GK4848@codeaurora.org>
Message-ID: <20160202173141.GB9044@debian>

On Mon, Feb 01, 2016 at 11:44:32AM -0800, Stephen Boyd wrote:
> On 01/30, Rabin Vincent wrote:
> > For __gnu_mcount_nc, wouldn't it be better to replace both the push {lr}
> > and the bl with nop instructions, instead of keeping a (useless) push +
> > pop sequence?
> 
> Agreed. I was trying to do a 1-to-1 copy of the ftrace code on
> ARM.  I was wondering the same thing in that code path while
> doing this though. Can't we replace both instructions instead of
> one instruction when we're patching in nops at runtime?

As Steven pointed out the last time this came up, we can't do it safely
at runtime:

https://marc.info/?l=linux-arm-kernel&m=132517584531389&w=2


From maxime.ripard at free-electrons.com  Tue Feb  2 09:33:40 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 18:33:40 +0100
Subject: [PATCH] clk: sunxi: don't mark sun6i_ar100_data __initconst
In-Reply-To: <1454428571-4040607-1-git-send-email-arnd@arndb.de>
References: <1453727747-23307-11-git-send-email-wens@csie.org>
 <1454428571-4040607-1-git-send-email-arnd@arndb.de>
Message-ID: <20160202173340.GA4652@lukather>

On Tue, Feb 02, 2016 at 04:55:30PM +0100, Arnd Bergmann wrote:
> The clk-sun6i-ar100 clk driver is a platform driver that may use
> deferred probing, so its probe function must not access
> __init symbols. Kbuild warns about this:
> 
> WARNING: drivers/clk/sunxi/built-in.o(.text+0x15f0): Section mismatch in reference from the function sun6i_a31_ar100_clk_probe() to the (unknown reference) .init.rodata:(unknown)
> The function sun6i_a31_ar100_clk_probe() references
> the (unknown reference) __initconst (unknown).
> This is often because sun6i_a31_ar100_clk_probe lacks a __initconst
> annotation or the annotation of (unknown) is wrong.
> 
> Removing the __initconst annotation avoids the warning and makes
> deferred probing work.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 3ca2377b6fed ("clk: sunxi: rewrite sun6i-ar100 using factors clk")

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/a3ac1a8e/attachment.sig>

From szabolcs.nagy at arm.com  Tue Feb  2 09:31:22 2016
From: szabolcs.nagy at arm.com (Szabolcs Nagy)
Date: Tue, 2 Feb 2016 17:31:22 +0000
Subject: [PATCH] arm64: Add support for Half precision floating point
In-Reply-To: <56AA470E.1020606@linaro.org>
References: <1453823566-26742-1-git-send-email-suzuki.poulose@arm.com>
 <20160126160257.GB28238@arm.com> <56A79D17.2000009@arm.com>
 <20160126165538.GC22776@devel.intra.reserved-bit.com>
 <20160128160747.GN775@arm.com> <56AA470E.1020606@linaro.org>
Message-ID: <56B0E7EA.9050601@arm.com>

On 28/01/16 16:51, Adhemerval Zanella wrote:
> On 28-01-2016 14:07, Will Deacon wrote:
>> On Tue, Jan 26, 2016 at 10:25:38PM +0530, Siddhesh Poyarekar wrote:
>>> Adding Adhemerval to cc since he had volunteered to follow up on this,
>>> mainly because he had a couple of additional ideas on the kernel
>>> front.
>>>
>>> On Tue, Jan 26, 2016 at 04:21:43PM +0000, Suzuki K. Poulose wrote:
>>>> On 26/01/16 16:02, Will Deacon wrote:
>>>>> Hi Suzuki,
>>>>>
>>>>> On Tue, Jan 26, 2016 at 03:52:46PM +0000, Suzuki K Poulose wrote:
>>>>>> ARMv8.2 extensions [1] include an optional feature, which supports
>>>>>> half precision(16bit) floating point/asimd data processing
>>>>>> instructions. This patch adds support for detecting and exposing
>>>>>> the same to the userspace via HWCAPs
>>>>
>>>>
>>>>>> +#define HWCAP_FPHP		(1 << 9)
>>>>>> +#define HWCAP_ASIMDHP		(1 << 10)
>>>>>
>>>>> Where did we get to with the mrs trapping you proposed here?
>>>>>
>>>>>   http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374609.html
>>>>
>>>> We are yet to get some feedback from glibc/gcc folks. Siddhesh was looking
>>>> to make use of it [2]. But haven't heard anything back. Ramana mentioned
>>>> (in private) that they had some plans to take a look at it.
>>>
>>> I believe one of Adhemerval's ideas was similar to what I had
>>> mentioned back then, which was to provide all of the CPU information
>>> in a single file instead of having to traverse a directory structure.
>>
>> My understanding was that libc needed this information extremely early
>> on (i.e. before it could even issue system calls), and therefore such
>> an approach would be in addition to the proposal here. Am I mistaken?
> 
> If the idea is to use these instruction for function implementation selection
> (iFUNC) the idea is to have on PLT resolution either by accessing it directly
> or using a caching mechanism. x86_64 does something similar with cacheline
> information: it issues a single cpuid and create processor information table
> based on its information (it is also what the __builtin_supports() also
> does).
> 

__builtin_supports is not a single cpuid on x86, it is
a cpuid per dso with one cache per dso.

(gcc-5 used a single cache in libgcc_s.so.1 and that
turned out to be broken because ifunc in other dsos
could not reliably access it.)

>>> The other idea was to add a vDSO function that returns this data so as
>>> to avoid (or at least reduce) the context switch latency.
>>
>> I'm not at all keen on adding a data ABI to the vDSO. I think people tried
>> similar things in the past (something on PPC?) and have horror stories
>> from that.
> 
> In fact ppc still exports it in vDSO (include/asm/vdso_datapage.h), with
> information like the LPAR cfg, platform, processor, {d,i}cache, etc.
> I recall that I have see some code back at IBM that tried to use these
> fields directly, but indeed it is not recommended.
> 
> What I have in mind is something what ppc does with __kernel_get_syscall_map.
> It is vDSO function that returns a vDSO internal data related to which
> syscalls are implemented in the running kernel (through a bitmap field).
> 

fs access or vdso does not work for ifunc based dispatch
(assuming the current ifunc implementation in glibc).

(for vdso you need the AT_SYSINFO_EHDR auxval somehow and
then implement elf symbol lookup in the ifunc resolver
without calling any libc function. passing auxvals to the
ifunc resolver can be done by changing the ifunc abi, but
doing symbol lookups there is unrealistic.)

in the libc (e.g. for memcpy) ifunc is a bit easier to use,
but in user code (function-multi-versioning) ifunc is very
limited.

i wrote about the ifunc limitations here:
https://sourceware.org/ml/libc-alpha/2015-11/msg00108.html
see point (4) and (5).



From nicolas.pitre at linaro.org  Tue Feb  2 09:35:46 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 2 Feb 2016 12:35:46 -0500 (EST)
Subject: [PATCH v5] ARM: xip: Use correct symbol for end of ROM marker
In-Reply-To: <1454433540-25948-1-git-send-email-chris.brandt@renesas.com>
References: <1454349165-12249-1-git-send-email-chris.brandt@renesas.com>
 <1454433540-25948-1-git-send-email-chris.brandt@renesas.com>
Message-ID: <alpine.LFD.2.20.1602021235120.32766@knanqh.ubzr>

On Tue, 2 Feb 2016, Chris Brandt wrote:

> For an XIP build, _etext does not represent the end of the
> binary image that needs to stay mapped into the MODULES_VADDR area.
> Years ago, data came before text in the memory map. However,
> now that the order is text/init/data, an XIP_KERNEL needs to map
> up to the data location in order to keep from cutting off
> parts of the kernel that are needed.
> We only map up to the beginning of data because data has already been
> copied, so there's no reason to keep it around anymore.
> 
> This fixes the bug where you might lose the end of your kernel area
> after page table setup is complete.
> 
> Signed-off-by: Chris Brandt <chris.brandt at renesas.com>

Acked-by: Nicolas Pitre <nico at linaro.org>


> ---
> v5:
> * Switched from using __data_loc to _exiprom (new symbol)
> v4:
> * Switched from using _edata_loc __data_loc.
> * Made commit text more accurate.
> v3:
> * Removed sections.h from Kbuild
> v2:
> * Added change for MODULES_VADDR
> * Moved extern to new file asm/sections.h
> ---
>  arch/arm/include/asm/Kbuild     | 1 -
>  arch/arm/include/asm/sections.h | 8 ++++++++
>  arch/arm/kernel/module.c        | 2 +-
>  arch/arm/kernel/vmlinux.lds.S   | 2 ++
>  arch/arm/mm/mmu.c               | 8 ++++++--
>  5 files changed, 17 insertions(+), 4 deletions(-)
>  create mode 100644 arch/arm/include/asm/sections.h
> 
> diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
> index 16da638..3f6616b 100644
> --- a/arch/arm/include/asm/Kbuild
> +++ b/arch/arm/include/asm/Kbuild
> @@ -23,7 +23,6 @@ generic-y += preempt.h
>  generic-y += resource.h
>  generic-y += rwsem.h
>  generic-y += seccomp.h
> -generic-y += sections.h
>  generic-y += segment.h
>  generic-y += sembuf.h
>  generic-y += serial.h
> diff --git a/arch/arm/include/asm/sections.h b/arch/arm/include/asm/sections.h
> new file mode 100644
> index 0000000..803bbf2
> --- /dev/null
> +++ b/arch/arm/include/asm/sections.h
> @@ -0,0 +1,8 @@
> +#ifndef _ASM_ARM_SECTIONS_H
> +#define _ASM_ARM_SECTIONS_H
> +
> +#include <asm-generic/sections.h>
> +
> +extern char _exiprom[];
> +
> +#endif	/* _ASM_ARM_SECTIONS_H */
> diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
> index efdddcb..4f14b5c 100644
> --- a/arch/arm/kernel/module.c
> +++ b/arch/arm/kernel/module.c
> @@ -34,7 +34,7 @@
>   * recompiling the whole kernel when CONFIG_XIP_KERNEL is turned on/off.
>   */
>  #undef MODULES_VADDR
> -#define MODULES_VADDR	(((unsigned long)_etext + ~PMD_MASK) & PMD_MASK)
> +#define MODULES_VADDR	(((unsigned long)_exiprom + ~PMD_MASK) & PMD_MASK)
>  #endif
>  
>  #ifdef CONFIG_MMU
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index 8b60fde..d18e4e5 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -86,6 +86,7 @@ SECTIONS
>  
>  #ifdef CONFIG_XIP_KERNEL
>  	. = XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR);
> +	_xiprom = .;			/* XIP ROM area to be mapped */
>  #else
>  	. = PAGE_OFFSET + TEXT_OFFSET;
>  #endif
> @@ -228,6 +229,7 @@ SECTIONS
>  #endif
>  
>  #ifdef CONFIG_XIP_KERNEL
> +	_exiprom = .;			/* End of XIP ROM area */
>  	__data_loc = ALIGN(4);		/* location in binary */
>  	. = PAGE_OFFSET + TEXT_OFFSET;
>  #else
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 434d76f..e4b681a 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1253,7 +1253,7 @@ static inline void prepare_page_table(void)
>  
>  #ifdef CONFIG_XIP_KERNEL
>  	/* The XIP kernel is mapped in the module area -- skip over it */
> -	addr = ((unsigned long)_etext + PMD_SIZE - 1) & PMD_MASK;
> +	addr = ((unsigned long)_exiprom + PMD_SIZE - 1) & PMD_MASK;
>  #endif
>  	for ( ; addr < PAGE_OFFSET; addr += PMD_SIZE)
>  		pmd_clear(pmd_off_k(addr));
> @@ -1335,7 +1335,7 @@ static void __init devicemaps_init(const struct machine_desc *mdesc)
>  #ifdef CONFIG_XIP_KERNEL
>  	map.pfn = __phys_to_pfn(CONFIG_XIP_PHYS_ADDR & SECTION_MASK);
>  	map.virtual = MODULES_VADDR;
> -	map.length = ((unsigned long)_etext - map.virtual + ~SECTION_MASK) & SECTION_MASK;
> +	map.length = ((unsigned long)_exiprom - map.virtual + ~SECTION_MASK) & SECTION_MASK;
>  	map.type = MT_ROM;
>  	create_mapping(&map);
>  #endif
> @@ -1426,7 +1426,11 @@ static void __init kmap_init(void)
>  static void __init map_lowmem(void)
>  {
>  	struct memblock_region *reg;
> +#ifdef CONFIG_XIP_KERNEL
> +	phys_addr_t kernel_x_start = round_down(__pa(_sdata), SECTION_SIZE);
> +#else
>  	phys_addr_t kernel_x_start = round_down(__pa(_stext), SECTION_SIZE);
> +#endif
>  	phys_addr_t kernel_x_end = round_up(__pa(__init_end), SECTION_SIZE);
>  
>  	/* Map all the lowmem memory banks. */
> -- 
> 1.9.1
> 
> 
> 


From maxime.ripard at free-electrons.com  Tue Feb  2 09:37:44 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 18:37:44 +0100
Subject: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for
 Allwinner A64 SoC
In-Reply-To: <20160202035852.6984db63@i7>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-6-git-send-email-andre.przywara@arm.com>
 <20160201182754.GA14737@excalibur.cnev.de>
 <56AFE0EC.8080207@arm.com> <20160202035852.6984db63@i7>
Message-ID: <20160202173744.GB4652@lukather>

Hi,

On Tue, Feb 02, 2016 at 03:58:52AM +0200, Siarhei Siamashka wrote:
> > > On Mon, Feb 01, 2016 at 05:39:24PM +0000, Andre Przywara wrote:  
> > >> Based on the Allwinner A64 user manual and on the previous sunxi
> > >> pinctrl drivers this introduces the pin multiplex assignments for
> > >> the ARMv8 Allwinner A64 SoC.
> > >> Port A is apparently used for the fixed function DRAM controller, so
> > >> the ports start at B here (the manual mentions "n from 1 to 7", so
> > >> not starting at 0).
> > >>
> > >> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> > >> ---
> > >>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
> > >>  arch/arm64/Kconfig.platforms                       |   1 +
> > >>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
> > >>  drivers/pinctrl/sunxi/Makefile                     |   1 +
> > >>  drivers/pinctrl/sunxi/pinctrl-a64.c                | 606 +++++++++++++++++++++
> > >>  5 files changed, 613 insertions(+)
> > >>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c
> > >>
> > >> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> > >> index 9213b27..9050002 100644
> > >> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> > >> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> > >> @@ -21,6 +21,7 @@ Required properties:
> > >>    "allwinner,sun9i-a80-r-pinctrl"
> > >>    "allwinner,sun8i-a83t-pinctrl"
> > >>    "allwinner,sun8i-h3-pinctrl"
> > >> +  "allwinner,a64-pinctrl"  
> > > 
> > > Hello,
> > > 
> > > on all other Allwinner SoCs we use the SoC family as part of the
> > > compatible, as well as in the names of the Kconfig options. To
> > > keep things consistent, I would like to propose doing the same on
> > > Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of
> > > allwinner,a64-pinctrl.  
> > 
> > Yes, I have been told this already. However I don't like this idea so
> > much, for the following reasons:
> > a) It is mostly redundant. The actual SoC (marketing) name is unique,
> > there is no sun6i-a20 or sun7i-a23.
> > b) It is not even helpful. If I got Maxime correctly, then the newer
> > sunxi generation numbers depend on the ARM _cores_ used in the SoC,
> > which is frankly the least interesting part from a Linux support
> > perspective. I would see some sense if it would reflect the generation
> > of IP blocks used, but so it is even more confusing to see that
> > sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely
> > different beast. The Allwinner marketing name tells you that, but the
> > sunxi one does not.
> > c) It is very confusing for people not dealing with it everyday. Just
> > because I own a BananaPi I know that the A20 is sun7i, but I am totally
> > lost when it comes to all the other names. And even now it took me about
> > a minute to find the appropriate Wiki page which explains part of that
> > story.
> > d) Most importantly ;-): It kills TAB completion, unless you know the
> > sunxi number, which is mostly not true as pointed out in c)
> > 
> > So while I see that just a<somenumber> is not really very specific, I'd
> > rather do away with current naming scheme for the future. In this
> > particular case we have the vendor name as a name space identifier
> > already, so there is no possible confusion with ARM Cortex naming, for
> > instance.
> > 
> > Also as this is now moving into the arm64 world, I'd like to use the
> > opportunity to fix things that are not really optimal, the naming is one
> > of them.
> 
> One of the problems is that A64 name is not unique. We have reasons
> to believe that there are also H64 and R18 out there using exactly
> the same die, but possibly available in different packaging (a different
> ball grid pitch? or maybe a different set of peripherals routed to the
> outside?). Early prototypes of the Pine64 board were using Allwinner R18
> and the Jide Remix Mini HTPC box is using Allwinner H64.
> 
> The bootloader sources from Allwinner are also referring to A64 as
> AW1689, which makes some sense because it is the chip id number that
> is accessible for runtime identification via reading the SRAM_VER_REG
> hardware register:
> 
>     http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG
> 
> So would it be a good idea to use "aw1689" as a compatible property
> in the DT instead of "a64"? Or maybe have "aw1689-a64" and
> "aw1689-h64", which would be similar to the existing "sun5i-a13"
> and "sun5i-a10s" naming convention?

If someone cannot find out the family name that is documented on
several places, I'm not sure he'll find the obscure, internal code
name.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/70c844c1/attachment.sig>

From jenskuske at gmail.com  Tue Feb  2 09:40:25 2016
From: jenskuske at gmail.com (Jens Kuske)
Date: Tue, 2 Feb 2016 18:40:25 +0100
Subject: [linux-sunxi] [PATCH 10/11] arm64: dts: add Allwinner A64 SoC
 .dtsi
In-Reply-To: <56B0DD67.3060802@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-11-git-send-email-andre.przywara@arm.com>
 <56B0D83E.5090604@gmail.com> <56B0DD67.3060802@arm.com>
Message-ID: <56B0EA09.9030107@gmail.com>

Hi,

On 02/02/16 17:46, Andre Przywara wrote:
> Hi Jens,
> 
> thanks for having such an elaborate look!
> 
> On 02/02/16 16:24, Jens Kuske wrote:
>> Hi,
>>
>> On 01/02/16 18:39, Andre Przywara wrote:
[..]
>>> +
>>> +		/* dummy clock until pll6 can be reused */
>>> +		pll8: pll8_clk {
>>> +			#clock-cells = <0>;
>>> +			compatible = "fixed-clock";
>>> +			clock-frequency = <1>;
>>> +			clock-output-names = "pll8";
>>> +		};
> 
> Since I have you (as the original author ;-) in the loop: What was again
> the reason for this dummy clock? Can't it be modelled with the existing
> clock drivers in Linux?

PLL6 driver had the output name "pll6" hardcoded, so we couldn't reuse
it for "pll8". Maxime has reworked the pll6 code in the meantime, now
pll8 can use compatible = "allwinner,sun6i-a31-pll6-clk" too:
http://www.spinics.net/lists/linux-clk/msg06242.html

>
>>> +
>>> +		cpu: cpu_clk at 01c20050 {
>>> +			#clock-cells = <0>;
>>> +			compatible = "allwinner,sun4i-a10-cpu-clk";
>>> +			reg = <0x01c20050 0x4>;
>>> +			clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
>>> +			clock-output-names = "cpu";
>>> +			critical-clocks = <0>;
>>> +		};
>>> +
>>> +		axi: axi_clk at 01c20050 {
>>> +			#clock-cells = <0>;
>>> +			compatible = "allwinner,sun4i-a10-axi-clk";
>>> +			reg = <0x01c20050 0x4>;
>>> +			clocks = <&cpu>;
>>> +			clock-output-names = "axi";
>>> +		};
>>> +
>>> +		ahb1: ahb1_clk at 01c20054 {
>>> +			#clock-cells = <0>;
>>> +			compatible = "allwinner,sun6i-a31-ahb1-clk";
>>> +			reg = <0x01c20054 0x4>;
>>> +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
>>> +			clock-output-names = "ahb1";
>>> +		};
>>> +
>>> +		ahb2: ahb2_clk at 01c2005c {
>>> +			#clock-cells = <0>;
>>> +			compatible = "allwinner,sun8i-h3-ahb2-clk";
>>> +			reg = <0x01c2005c 0x4>;
>>> +			clocks = <&ahb1>, <&pll6d2>;
>>> +			clock-output-names = "ahb2";
>>> +		};
>>> +
>>> +		apb1: apb1_clk at 01c20054 {
>>> +			#clock-cells = <0>;
>>> +			compatible = "allwinner,sun4i-a10-apb0-clk";
>>> +			reg = <0x01c20054 0x4>;
>>> +			clocks = <&ahb1>;
>>> +			clock-output-names = "apb1";
>>> +		};
>>> +
>>> +		apb2: apb2_clk at 01c20058 {
>>> +			#clock-cells = <0>;
>>> +			compatible = "allwinner,sun4i-a10-apb1-clk";
>>> +			reg = <0x01c20058 0x4>;
>>> +			clocks = <&osc32k>, <&osc24M>, <&pll6 1>, <&pll6 1>;
>>> +			clock-output-names = "apb2";
>>> +		};
>>> +
>>> +		bus_gates: clk at 01c20060 {
>>> +			#clock-cells = <1>;
>>> +			compatible = "allwinner,a64-bus-gates-clk",
>>> +				     "allwinner,sunxi-multi-bus-gates-clk";
>>> +			reg = <0x01c20060 0x14>;
>>> +			ahb1_parent {
>>> +				clocks = <&ahb1>;
>>> +				clock-indices = <1>, <5>,
>>> +						<6>, <8>,
>>> +						<9>, <10>,
>>> +						<13>, <14>,
>>> +						<18>, <19>,
>>> +						<20>, <21>,
>>> +						<23>, <24>,
>>> +						<25>, <28>,
>>> +						<32>, <35>,
>>> +						<36>, <37>,
>>> +						<40>, <43>,
>>> +						<44>, <52>,
>>> +						<53>, <54>,
>>> +						<135>;
>>> +				clock-output-names = "bus_mipidsi", "bus_ce",
>>> +						"bus_dma", "bus_mmc0",
>>> +						"bus_mmc1", "bus_mmc2",
>>> +						"bus_nand", "bus_sdram",
>>> +						"bus_ts", "bus_hstimer",
>>> +						"bus_spi0", "bus_spi1",
>>> +						"bus_otg", "bus_otg_ehci0",
>>> +						"bus_ehci0", "bus_otg_ohci0",
>>> +						"bus_ve", "bus_lcd0",
>>> +						"bus_lcd1", "bus_deint",
>>> +						"bus_csi", "bus_hdmi",
>>> +						"bus_de", "bus_gpu",
>>> +						"bus_msgbox", "bus_spinlock",
>>> +						"bus_dbg";
>>> +			};
>>> +			ahb2_parent {
>>> +				clocks = <&ahb2>;
>>> +				clock-indices = <17>, <29>;
>>> +				clock-output-names = "bus_gmac", "bus_ohci0";
>>> +			};
>>> +			apb1_parent {
>>> +				clocks = <&apb1>;
>>> +				clock-indices = <64>, <65>,
>>> +						<69>, <72>,
>>> +						<76>, <77>,
>>> +						<78>;
>>> +				clock-output-names = "bus_codec", "bus_spdif",
>>> +						"bus_pio", "bus_ths",
>>> +						"bus_i2s0", "bus_i2s1",
>>> +						"bus_i2s2";
>>> +			};
>>> +			abp2_parent {
>>> +				clocks = <&apb2>;
>>> +				clock-indices = <96>, <97>,
>>> +						<98>, <101>,
>>> +						<112>, <113>,
>>> +						<114>, <115>,
>>> +						<116>;
>>> +				clock-output-names = "bus_i2c0", "bus_i2c1",
>>> +						"bus_i2c2", "bus_scr",
>>> +						"bus_uart0", "bus_uart1",
>>> +						"bus_uart2", "bus_uart3",
>>> +						"bus_uart4";
>>> +			};
>>> +		};
>>> +
>>> +		mmc0_clk: clk at 01c20088 {
>>> +			#clock-cells = <1>;
>>> +			compatible = "allwinner,sun4i-a10-mmc-clk";
>>
>> The A64 MMC clocks don't seem to be fully compatible to A10. The output
>> and sample phase control has been moved to the MMC module itself.
>> The dividers are the same, but the additional special "outputs" are gone.
> 
> So from comparing the H3 and the A64 datasheet I see that this is one of
> the rare deviations of the A64 from the H3?

Yeah, looks like this is new in A64, probably because it supports even
higher card speeds now.

> 
>>> +			reg = <0x01c20088 0x4>;
>>> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>>
>> Parents are PLL6(2x) and PLL8(2x) according to manual.
> 
> Indeed, thanks for pointing this out! So do we need a proper pll8 clock?

The dummy would still work, but it is easy to add a real pll8 now with
Maximes work.

> 
>>
>>> +			clock-output-names = "mmc0",
>>> +					     "mmc0_output",
>>> +					     "mmc0_sample";
>>> +		};
>>> +
>>> +		mmc1_clk: clk at 01c2008c {
>>> +			#clock-cells = <1>;
>>> +			compatible = "allwinner,sun4i-a10-mmc-clk";
>>> +			reg = <0x01c2008c 0x4>;
>>> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>>> +			clock-output-names = "mmc1",
>>> +					     "mmc1_output",
>>> +					     "mmc1_sample";
>>> +		};
>>> +
>>> +		mmc2_clk: clk at 01c20090 {
>>> +			#clock-cells = <1>;
>>> +			compatible = "allwinner,sun4i-a10-mmc-clk";
>>> +			reg = <0x01c20090 0x4>;
>>> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>>> +			clock-output-names = "mmc2",
>>> +					     "mmc2_output",
>>> +					     "mmc2_sample";
>>> +		};
>>> +	};
>>> +
>>> +	regulators {
>>> +		reg_vcc3v3: vcc3v3 {
>>> +			compatible = "regulator-fixed";
>>> +			regulator-name = "vcc3v3";
>>> +			regulator-min-microvolt = <3300000>;
>>> +			regulator-max-microvolt = <3300000>;
>>> +		};
>>> +	};
>>> +
>>> +	soc {
>>> +		compatible = "simple-bus";
>>> +		#address-cells = <1>;
>>> +		#size-cells = <1>;
>>> +		ranges;
>>> +
>>> +		mmc0: mmc at 01c0f000 {
>>> +			compatible = "allwinner,sun5i-a13-mmc";
>>> +			reg = <0x01c0f000 0x1000>;
>>> +			clocks = <&bus_gates 8>,
>>> +				 <&mmc0_clk 0>,
>>
>> Consequently, the MMC driver now has to control the output/sample phase
>> with registers 0x140-0x148 instead of
>>> +				 <&mmc0_clk 1>,
>>> +				 <&mmc0_clk 2>;
> 
> OK, good point. I was just briefly browsing over the register
> descriptions and missed that.
> So it looks like I need to change the driver. Interestingly it seems to
> work anyways ...

I don't know, maybe it has sane defaults or is only relevant at higher
clock speeds. Or Allwinners u-boot already set it.

> 
>> And there seems to be some new clock divider somewhere which I haven't
>> found in the manual yet. The clock measured at the CLK pin is always
>> half the expected rate (even with 24MHz as MMC clock parent, so no
>> PLL6*2 problem).
> 
> Mmh, I heard about that mysterious clock doubling / halving already. Was
> that actually causing any issues?

Since it uses PLL6 * 2 now and seems to divide that by 2 somewhere
nothing has changed in the end. One could argue that pll6 * 2 is wrong,
but by testing with osc24MHz parent (in u-boot) it can be seen that the
clockrate is only half of what is expected.

Disclaimer: I don't know much about mmc, so maybe I've missed something
obvious. I only did some frequency measurements on H3 vs A64 hardware
when Siarhei asked about that in irc and now I wonder about the results.

Jens


From peter at korsgaard.com  Tue Feb  2 09:42:09 2016
From: peter at korsgaard.com (Peter Korsgaard)
Date: Tue, 02 Feb 2016 18:42:09 +0100
Subject: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
 ACT8945A
In-Reply-To: <20160129113518.GQ4130@sirena.org.uk> (Mark Brown's message of
 "Fri, 29 Jan 2016 12:35:18 +0100")
References: <1453863463-30515-1-git-send-email-wenyou.yang@atmel.com>
 <1453863463-30515-2-git-send-email-wenyou.yang@atmel.com>
 <20160129001603.GM4130@sirena.org.uk>
 <B256D81BAE5131468A838E5D7A243641D63FBF8B@penmbx01>
 <20160129113518.GQ4130@sirena.org.uk>
Message-ID: <87wpqn3t72.fsf@dell.be.48ers.dk>

>>>>> "Mark" == Mark Brown <broonie at kernel.org> writes:

 > On Fri, Jan 29, 2016 at 01:20:08AM +0000, Yang, Wenyou wrote:
 >> > > +static const struct of_device_id act8945a_pmic_of_match[] = {
 >> > > +	{ .compatible = "active-semi,act8945a-regulator" },
 >> > > +	{ },
 >> > > +};
 >> > > +MODULE_DEVICE_TABLE(of, act8945a_pmic_of_match);

 >> > This seems mostly OK but why do we have a compatible string here - shouldn't
 >> > the MFD be able to instantiate the regulator function without needing this?

 >> Because I got feedback from Javier for the act8945a-charger patches of this MFD series,
 >> He said missing the OF match table will cause the module autoloading broken. 

 >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/398113.html

 >> What do you think about it?

 > If then device is not being loaded from the DT (and it shouldn't be, the
 > device looks like it should be instantiated directly by the MFD as it
 > can't exist separately to that MFD) an OF table will do nothing.  

To add to the confusion, the regulator part of the chip is actually
identical to act8865, so it could use the existing regulator driver /
compatible, except that it binds to the platform bus instead of i2c.

-- 
Bye, Peter Korsgaard


From nicolas.pitre at linaro.org  Tue Feb  2 09:51:16 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 2 Feb 2016 12:51:16 -0500 (EST)
Subject: [PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM
In-Reply-To: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <alpine.LFD.2.20.1602021250200.32766@knanqh.ubzr>

On Tue, 2 Feb 2016, Ard Biesheuvel wrote:

> This series applies on top of today's -next, and addresses an issue with
> the new kallsyms code that is queued there, that enables base relative
> kallsyms tables for all architectures (except IA-64)
> 
> Two issues have surfaced on ARM with the new kallsyms code:
> a) CONFIG_HAVE_TCM creates a virtual region that is too far away for the
>    relative kallsyms code to reach it;
> b) CONFIG_XIP_KERNEL=y kernel symbols are not filtered against PAGE_OFFSET,
>    as is the case for kernels that execute from RAM, resulting in symbols
>    that are out of range.
> 
> Since the way kallsyms deals with XIP kernels on ARM leaves some room for
> improvement regardless of the base relative changes, this series proposes
> a fix that allows the special case to be removed from the kallsyms handling
> entirely.
> 
> Patch #1 moves the .stubs and .vectors section back into the kernel VMA, while
> preserving the guaranteed virtual offset of 4 KB. This results in all symbols
> that kallsyms sees to be in a reasonable interval.
> 
> Patch #2 removes the special case for CONFIG_ARM && !CONFIG_XIP_KERNEL in the
> invocation of scripts/kallsyms
> 
> Patch #3 removes the now unused --page-offset command line argument handling
> from scripts/kallsyms.c
> 
> Note that we may still need to remove ARM from the list of architectures that
> support base relative kallsyms tables if we cannot fix issue a) above, but
> removing this special case seemed like an obvious improvement to me.

For those 3 patches:

Acked-by: Nicolas Pitre <nico at linaro.org>



> 
> Ard Biesheuvel (3):
>   ARM: move .vectors and .stubs sections back into the kernel VMA
>   kallsyms: remove special lower address limit for CONFIG_ARM
>   kallsyms: remove --page-offset command line option
> 
>  arch/arm/kernel/entry-armv.S  |  7 +++--
>  arch/arm/kernel/vmlinux.lds.S | 15 ++++++-----
>  scripts/kallsyms.c            | 27 ++++----------------
>  scripts/link-vmlinux.sh       |  4 ---
>  4 files changed, 16 insertions(+), 37 deletions(-)
> 
> -- 
> 2.5.0
> 
> 


From rostedt at goodmis.org  Tue Feb  2 09:51:38 2016
From: rostedt at goodmis.org (Steven Rostedt)
Date: Tue, 2 Feb 2016 12:51:38 -0500
Subject: [PATCH] recordmcount: arm: Implement make_nop
In-Reply-To: <20160202173141.GB9044@debian>
References: <1454116686-30190-1-git-send-email-sboyd@codeaurora.org>
 <20160130184005.GA29607@debian>
 <20160201194432.GK4848@codeaurora.org>
 <20160202173141.GB9044@debian>
Message-ID: <20160202125138.71606201@gandalf.local.home>

On Tue, 2 Feb 2016 18:31:41 +0100
Rabin Vincent <rabin at rab.in> wrote:

> On Mon, Feb 01, 2016 at 11:44:32AM -0800, Stephen Boyd wrote:
> > On 01/30, Rabin Vincent wrote:  
> > > For __gnu_mcount_nc, wouldn't it be better to replace both the push {lr}
> > > and the bl with nop instructions, instead of keeping a (useless) push +
> > > pop sequence?  
> > 
> > Agreed. I was trying to do a 1-to-1 copy of the ftrace code on
> > ARM.  I was wondering the same thing in that code path while
> > doing this though. Can't we replace both instructions instead of
> > one instruction when we're patching in nops at runtime?  
> 
> As Steven pointed out the last time this came up, we can't do it safely
> at runtime:
> 
> https://marc.info/?l=linux-arm-kernel&m=132517584531389&w=2

There is actually a way to do it, but it requires break points.

	push lr
	call mcount

Now add a break point:

	brk
	call mcount

Anything that hits the breakpoint, have it return after the call to
mcount.

Sync all CPUs where tasks have either hit the breakpoint and is
skipping the mcount regardless, or has already done the push lr and
is calling mcount. To be even more paranoid, you could add a step to:

	brk
	brk

and if the second brkpoint is hit, then call mcount to make sure it
does the necessary step with lr. Again sync the CPUS (which is simply
just sending an IPI to all of them).

Once the breakpoints are in place, you can convert them over to nops.

	brk
	nop

and then to

	nop
	nop

-- Steve


From ard.biesheuvel at linaro.org  Tue Feb  2 09:56:39 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  2 Feb 2016 18:56:39 +0100
Subject: [RFC PATCH 0/3] arm64 initrd mapping/relocation
Message-ID: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>

After discussing in linux-efi with Mark, and on #armlinux with Will, this is
a proposal for dealing with initrd memory that is potentially not covered by
the linear region.

Note that this will look slightly differently when some of the KASLR work gets
merged, but this should only affect the way we deal with the initrd if it sits
outside of the linear region.

Mostly intended for discussion, not tested at all.

Ard Biesheuvel (3):
  memblock: add routine to clear the MEMBLOCK_NOMAP flag for a region
  arm64: add the initrd region to the linear mapping explicitly
  arm64: remove the now unneeded relocate_initrd()

 arch/arm64/kernel/setup.c | 64 --------------------
 arch/arm64/mm/init.c      | 16 ++++-
 include/linux/memblock.h  |  1 +
 mm/memblock.c             | 12 ++++
 4 files changed, 27 insertions(+), 66 deletions(-)

-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb  2 09:56:40 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  2 Feb 2016 18:56:40 +0100
Subject: [RFC PATCH 1/3] memblock: add routine to clear the MEMBLOCK_NOMAP
 flag for a region
In-Reply-To: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454435802-7604-2-git-send-email-ard.biesheuvel@linaro.org>

In addition to the existing memblock_mark_nomap(), this implements
memblock_clear_nomap() to do the converse.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 include/linux/memblock.h |  1 +
 mm/memblock.c            | 12 ++++++++++++
 2 files changed, 13 insertions(+)

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 3106ac1c895e..f7d2c8dc2f0d 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -92,6 +92,7 @@ int memblock_mark_hotplug(phys_addr_t base, phys_addr_t size);
 int memblock_clear_hotplug(phys_addr_t base, phys_addr_t size);
 int memblock_mark_mirror(phys_addr_t base, phys_addr_t size);
 int memblock_mark_nomap(phys_addr_t base, phys_addr_t size);
+int memblock_clear_nomap(phys_addr_t base, phys_addr_t size);
 ulong choose_memblock_flags(void);
 
 /* Low level functions */
diff --git a/mm/memblock.c b/mm/memblock.c
index 335a145b75cd..ffa7ab127641 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -835,6 +835,18 @@ int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size)
 }
 
 /**
+ * memblock_clear_nomap - Clear flag MEMBLOCK_NOMAP for a specified region.
+ * @base: the base phys addr of the region
+ * @size: the size of the region
+ *
+ * Return 0 on success, -errno on failure.
+ */
+int __init_memblock memblock_clear_nomap(phys_addr_t base, phys_addr_t size)
+{
+	return memblock_setclr_flag(base, size, 0, MEMBLOCK_NOMAP);
+}
+
+/**
  * __next_reserved_mem_region - next function for for_each_reserved_region()
  * @idx: pointer to u64 loop variable
  * @out_start: ptr to phys_addr_t for start address of the region, can be %NULL
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb  2 09:56:41 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  2 Feb 2016 18:56:41 +0100
Subject: [RFC PATCH 2/3] arm64: add the initrd region to the linear mapping
 explicitly
In-Reply-To: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454435802-7604-3-git-send-email-ard.biesheuvel@linaro.org>

Instead of going out of our way to relocate the initrd if it turns out
to occupy memory that is not covered by the linear mapping, just add the
initrd to the linear mapping. This puts the burden on the bootloader to
pass initrd= and mem= options that are mutually consistent.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/mm/init.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3b061e67bfe..5dd083161810 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -167,8 +167,20 @@ void __init arm64_memblock_init(void)
 	 */
 	memblock_reserve(__pa(_text), _end - _text);
 #ifdef CONFIG_BLK_DEV_INITRD
-	if (initrd_start)
-		memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
+	if (initrd_start) {
+		u64 base = __virt_to_phys(initrd_start);
+		u64 size = initrd_end - initrd_start;
+
+		/*
+		 * The initrd needs to be accessible via the linear mapping. So
+		 * add the memory covered by the initrd explicitly, since it may
+		 * have been clipped or otherwise left out when we traversed the
+		 * DT memory nodes or the UEFI memory map.
+		 */
+		memblock_add(base, size);
+		memblock_clear_nomap(base, size);
+		memblock_reserve(base, size);
+	}
 #endif
 
 	early_init_fdt_scan_reserved_mem();
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb  2 09:56:42 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  2 Feb 2016 18:56:42 +0100
Subject: [RFC PATCH 3/3] arm64: remove the now unneeded relocate_initrd()
In-Reply-To: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454435802-7604-4-git-send-email-ard.biesheuvel@linaro.org>

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/kernel/setup.c | 64 --------------------
 1 file changed, 64 deletions(-)

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479147db..1a8ef35b03d4 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -223,69 +223,6 @@ static void __init request_standard_resources(void)
 	}
 }
 
-#ifdef CONFIG_BLK_DEV_INITRD
-/*
- * Relocate initrd if it is not completely within the linear mapping.
- * This would be the case if mem= cuts out all or part of it.
- */
-static void __init relocate_initrd(void)
-{
-	phys_addr_t orig_start = __virt_to_phys(initrd_start);
-	phys_addr_t orig_end = __virt_to_phys(initrd_end);
-	phys_addr_t ram_end = memblock_end_of_DRAM();
-	phys_addr_t new_start;
-	unsigned long size, to_free = 0;
-	void *dest;
-
-	if (orig_end <= ram_end)
-		return;
-
-	/*
-	 * Any of the original initrd which overlaps the linear map should
-	 * be freed after relocating.
-	 */
-	if (orig_start < ram_end)
-		to_free = ram_end - orig_start;
-
-	size = orig_end - orig_start;
-	if (!size)
-		return;
-
-	/* initrd needs to be relocated completely inside linear mapping */
-	new_start = memblock_find_in_range(0, PFN_PHYS(max_pfn),
-					   size, PAGE_SIZE);
-	if (!new_start)
-		panic("Cannot relocate initrd of size %ld\n", size);
-	memblock_reserve(new_start, size);
-
-	initrd_start = __phys_to_virt(new_start);
-	initrd_end   = initrd_start + size;
-
-	pr_info("Moving initrd from [%llx-%llx] to [%llx-%llx]\n",
-		orig_start, orig_start + size - 1,
-		new_start, new_start + size - 1);
-
-	dest = (void *)initrd_start;
-
-	if (to_free) {
-		memcpy(dest, (void *)__phys_to_virt(orig_start), to_free);
-		dest += to_free;
-	}
-
-	copy_from_early_mem(dest, orig_start + to_free, size - to_free);
-
-	if (to_free) {
-		pr_info("Freeing original RAMDISK from [%llx-%llx]\n",
-			orig_start, orig_start + to_free - 1);
-		memblock_free(orig_start, to_free);
-	}
-}
-#else
-static inline void __init relocate_initrd(void)
-{
-}
-#endif
-
 u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
 
 void __init setup_arch(char **cmdline_p)
@@ -320,7 +257,6 @@ void __init setup_arch(char **cmdline_p)
 	acpi_boot_table_init();
 
 	paging_init();
-	relocate_initrd();
 
 	kasan_init();
 
-- 
2.5.0



From maxime.ripard at free-electrons.com  Tue Feb  2 10:02:27 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 19:02:27 +0100
Subject: [PATCH 08/11] clk: sunxi: improve error reporting for the mux
 clock
In-Reply-To: <1454348370-3816-9-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-9-git-send-email-andre.przywara@arm.com>
Message-ID: <20160202180227.GC4652@lukather>

On Mon, Feb 01, 2016 at 05:39:27PM +0000, Andre Przywara wrote:
> clk_register_mux returns a pointer wrapped error value in case of
> failure, so a simple NULL check is not sufficient to catch errors.
> Fix that and elaborate on the failure reason on the way. The whole
> function does not return any error value, so silently failing may
> leave users scratching their heads because the kernel does not
> provide any clues on what's wrong.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>

Applied, thanks.

Any chance you do that for the other functions? :)

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/d0225674/attachment-0001.sig>

From tony at atomide.com  Tue Feb  2 10:05:56 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 2 Feb 2016 10:05:56 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160202164910.GV19432@atomide.com>
References: <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602021112320.1653-100000@iolanthe.rowland.org>
 <20160202164910.GV19432@atomide.com>
Message-ID: <20160202180555.GW19432@atomide.com>

* Tony Lindgren <tony at atomide.com> [160202 08:50]:
> * Alan Stern <stern at rowland.harvard.edu> [160202 08:17]:
> 
> > ?  pm_runtime_put_sync() _already_ does not respect the autosuspend 
> > mode.  If you want to respect it, you have to call 
> > pm_runtime_put_sync_autosuspend() instead.
> 
> I think you found the real bug there. So the right fix is to
> call pm_runtime_put_sync_autosuspend() at the end of failed
> probe in omap_hsmmc. Let me give that a try here.

Nope that's not it but getting closer.

The following seems to make things behave for me. Now the
question is.. Does it have some undesired side effects?

> Can we add some warning to pm_runtime_put_sync() about that?

Probably no need for that, I misunderstood the meaning of
pm_runtime_put_sync_autosuspend().

Regards,

Tony

8< --------------
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -435,7 +435,7 @@ static int rpm_suspend(struct device *dev, int rpmflags)
 		goto out;
 
 	/* If the autosuspend_delay time hasn't expired yet, reschedule. */
-	if ((rpmflags & RPM_AUTO)
+	if (((rpmflags & (RPM_ASYNC | RPM_AUTO)) == ((RPM_ASYNC | RPM_AUTO)))
 	    && dev->power.runtime_status != RPM_SUSPENDING) {
 		unsigned long expires = pm_runtime_autosuspend_expiration(dev);
 


From andre.przywara at arm.com  Tue Feb  2 10:05:49 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 2 Feb 2016 18:05:49 +0000
Subject: [PATCH 08/11] clk: sunxi: improve error reporting for the mux
 clock
In-Reply-To: <20160202180227.GC4652@lukather>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-9-git-send-email-andre.przywara@arm.com>
 <20160202180227.GC4652@lukather>
Message-ID: <56B0EFFD.8070900@arm.com>

Salut,

On 02/02/16 18:02, Maxime Ripard wrote:
> On Mon, Feb 01, 2016 at 05:39:27PM +0000, Andre Przywara wrote:
>> clk_register_mux returns a pointer wrapped error value in case of
>> failure, so a simple NULL check is not sufficient to catch errors.
>> Fix that and elaborate on the failure reason on the way. The whole
>> function does not return any error value, so silently failing may
>> leave users scratching their heads because the kernel does not
>> provide any clues on what's wrong.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> 
> Applied, thanks.
> 
> Any chance you do that for the other functions? :)

Sure, that was actually a test balloon ;-)

Cheers,
Andre


From will.deacon at arm.com  Tue Feb  2 10:06:22 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 2 Feb 2016 18:06:22 +0000
Subject: [RFC PATCH 0/3] arm64 initrd mapping/relocation
In-Reply-To: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160202180622.GP10166@arm.com>

On Tue, Feb 02, 2016 at 06:56:39PM +0100, Ard Biesheuvel wrote:
> After discussing in linux-efi with Mark, and on #armlinux with Will, this is
> a proposal for dealing with initrd memory that is potentially not covered by
> the linear region.
> 
> Note that this will look slightly differently when some of the KASLR work gets
> merged, but this should only affect the way we deal with the initrd if it sits
> outside of the linear region.
> 
> Mostly intended for discussion, not tested at all.

Thanks Ard, this looks like a much better approach to me. Mark -- does
the general idea work for you too?

Will


From moinejf at free.fr  Tue Feb  2 09:59:04 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Tue, 2 Feb 2016 18:59:04 +0100
Subject: [PATCH v4 0/2] Add a DRM display driver to the Allwinner H3
Message-ID: <cover.1454435944.git.moinejf@free.fr>

The proposed DRM driver works on a Orange PI 2 with a kernel 4.5.0-rc1
and some H3 patches found in Hans de Goede's GIT repository.

As there is no documentation about the HDMI of the H3,
the associated encoder/connector driver has not been included
in this patch series.
For test purpose, it may be built as a out-of-tree driver
from the tarball:
	http://moinejf.free.fr/opi2/h3-hdmi.tar.gz
and the DT files:
	http://moinejf.free.fr/opi2/sun8i-h3.dtsi
	http://moinejf.free.fr/opi2/sun8i-h3-orangepi-plus.dts

Jean-Francois Moine (2):
  clk: sunxi: Add sun6i/8i video support
  drm: sunxi: Add a basic DRM driver for Allwinner DE2

---
v4: 
	- drivers/clk/sunxi/Makefile was missing (Emil Velikov)
v3:
	- add the hardware cursor
	- simplify and fix the DE2 init sequences
	- generation for all SUNXI SoCs (Andre Przywara)
v2:
	- remarks from Chen-Yu Tsai and Russell King
	- DT documentation added
---

 Documentation/devicetree/bindings/clock/sunxi.txt  |   2 +
 .../devicetree/bindings/display/sunxi.txt          |  81 ++++
 drivers/clk/sunxi/Makefile                         |   2 +
 drivers/clk/sunxi/clk-sun6i-display.c              | 106 +++++
 drivers/clk/sunxi/clk-sun6i-pll3.c                 | 174 +++++++
 drivers/gpu/drm/Kconfig                            |   2 +
 drivers/gpu/drm/Makefile                           |   1 +
 drivers/gpu/drm/sunxi/Kconfig                      |  20 +
 drivers/gpu/drm/sunxi/Makefile                     |   7 +
 drivers/gpu/drm/sunxi/de2_crtc.c                   | 421 +++++++++++++++++
 drivers/gpu/drm/sunxi/de2_crtc.h                   |  61 +++
 drivers/gpu/drm/sunxi/de2_de.c                     | 505 +++++++++++++++++++++
 drivers/gpu/drm/sunxi/de2_drm.h                    |  40 ++
 drivers/gpu/drm/sunxi/de2_drv.c                    | 377 +++++++++++++++
 drivers/gpu/drm/sunxi/de2_plane.c                  |  91 ++++
 15 files changed, 1890 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/sunxi.txt
 create mode 100644 drivers/clk/sunxi/clk-sun6i-display.c
 create mode 100644 drivers/clk/sunxi/clk-sun6i-pll3.c
 create mode 100644 drivers/gpu/drm/sunxi/Kconfig
 create mode 100644 drivers/gpu/drm/sunxi/Makefile
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c

-- 
2.7.0



From moinejf at free.fr  Tue Feb  2 09:35:10 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Tue, 2 Feb 2016 18:35:10 +0100
Subject: [PATCH v4 1/2] clk: sunxi: Add sun6i/8i video support
In-Reply-To: <cover.1454435944.git.moinejf@free.fr>
References: <cover.1454435944.git.moinejf@free.fr>
Message-ID: <3c0e2cdea659e9e682f80ecf42b252c740095f15.1454435944.git.moinejf@free.fr>

Add the clock types which are used by the sun6i/8i families for video.

Signed-off-by: Jean-Francois Moine <moinejf at free.fr>
---
v4:
	- drivers/clk/sunxi/Makefile was missing (Emil Velikov)
v3: (no change)
v2:
	- remarks from Chen-Yu Tsai
	- DT documentation added
---
 Documentation/devicetree/bindings/clock/sunxi.txt |   2 +
 drivers/clk/sunxi/Makefile                        |   2 +
 drivers/clk/sunxi/clk-sun6i-display.c             | 106 +++++++++++++
 drivers/clk/sunxi/clk-sun6i-pll3.c                | 174 ++++++++++++++++++++++
 4 files changed, 284 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk-sun6i-display.c
 create mode 100644 drivers/clk/sunxi/clk-sun6i-pll3.c

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index e59f57b..a22b92f 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -11,6 +11,7 @@ Required properties:
 	"allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
 	"allwinner,sun8i-a23-pll1-clk" - for the main PLL clock on A23
 	"allwinner,sun9i-a80-pll4-clk" - for the peripheral PLLs on A80
+	"allwinner,sun6i-pll3-clk" - for the video PLLs clock
 	"allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock
 	"allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock
 	"allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
@@ -77,6 +78,7 @@ Required properties:
 	"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
 	"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
 	"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
+	"allwinner,sun6i-display-clk" - for the display clocks
 
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 3fd7901..6fe336f 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -11,6 +11,8 @@ obj-y += clk-a10-ve.o
 obj-y += clk-a20-gmac.o
 obj-y += clk-mod0.o
 obj-y += clk-simple-gates.o
+obj-y += clk-sun6i-display.o
+obj-y += clk-sun6i-pll3.o
 obj-y += clk-sun8i-bus-gates.o
 obj-y += clk-sun8i-mbus.o
 obj-y += clk-sun9i-core.o
diff --git a/drivers/clk/sunxi/clk-sun6i-display.c b/drivers/clk/sunxi/clk-sun6i-display.c
new file mode 100644
index 0000000..48356e3
--- /dev/null
+++ b/drivers/clk/sunxi/clk-sun6i-display.c
@@ -0,0 +1,106 @@
+/*
+ * Copyright 2016 Jean-Francois Moine <moinejf at free.fr>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/rational.h>
+#include <linux/delay.h>
+
+static DEFINE_SPINLOCK(sun6i_display_lock);
+
+#define SUN6I_DISPLAY_GATE_BIT	31
+#define SUN6I_DISPLAY_SEL_SHIFT	24
+#define SUN6I_DISPLAY_SEL_MASK	GENMASK(2, 0)
+#define SUN6I_DISPLAY_MSHIFT	0
+#define SUN6I_DISPLAY_MWIDTH	4
+
+static void __init sun6i_display_setup(struct device_node *node)
+{
+	const char *clk_name = node->name;
+	const char *parents[8];
+	struct clk_mux *mux = NULL;
+	struct clk_divider *div;
+	struct clk_gate *gate;
+	struct resource res;
+	void __iomem *mmio;
+	struct clk *clk;
+	int n;
+
+	of_property_read_string(node, "clock-output-names", &clk_name);
+
+	mmio = of_io_request_and_map(node, 0, of_node_full_name(node));
+	if (IS_ERR(mmio)) {
+		pr_err("%s: Could not map the clock registers\n", clk_name);
+		return;
+	}
+
+	n = of_clk_parent_fill(node, parents, ARRAY_SIZE(parents));
+
+	if (n > 1) {				/* many possible sources */
+		mux = kzalloc(sizeof(*mux), GFP_KERNEL);
+		if (!mux)
+			goto free_io;
+		mux->reg = mmio;
+		mux->shift = SUN6I_DISPLAY_SEL_SHIFT;
+		mux->mask = SUN6I_DISPLAY_SEL_MASK;
+		mux->lock = &sun6i_display_lock;
+	}
+
+	gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+	if (!gate)
+		goto free_mux;
+
+	gate->reg = mmio;
+	gate->bit_idx = SUN6I_DISPLAY_GATE_BIT;
+	gate->lock = &sun6i_display_lock;
+
+	div = kzalloc(sizeof(*div), GFP_KERNEL);
+	if (!div)
+		goto free_gate;
+
+	div->reg = mmio;
+	div->shift = SUN6I_DISPLAY_MSHIFT;
+	div->width = SUN6I_DISPLAY_MWIDTH;
+	div->lock = &sun6i_display_lock;
+
+	clk = clk_register_composite(NULL, clk_name,
+				     parents, n,
+				     mux ? &mux->hw : NULL, &clk_mux_ops,
+				     &div->hw, &clk_divider_ops,
+				     &gate->hw, &clk_gate_ops,
+				     0);
+	if (IS_ERR(clk)) {
+		pr_err("%s: Couldn't register the clock\n", clk_name);
+		goto free_div;
+	}
+
+	of_clk_add_provider(node, of_clk_src_simple_get, clk);
+
+	return;
+
+free_div:
+	kfree(div);
+free_gate:
+	kfree(gate);
+free_mux:
+	kfree(mux);
+free_io:
+	iounmap(mmio);
+	of_address_to_resource(node, 0, &res);
+	release_mem_region(res.start, resource_size(&res));
+}
+
+CLK_OF_DECLARE(sun6i_display, "allwinner,sun6i-display-clk", sun6i_display_setup);
diff --git a/drivers/clk/sunxi/clk-sun6i-pll3.c b/drivers/clk/sunxi/clk-sun6i-pll3.c
new file mode 100644
index 0000000..3c128a4
--- /dev/null
+++ b/drivers/clk/sunxi/clk-sun6i-pll3.c
@@ -0,0 +1,174 @@
+/*
+ * Allwinner video PLL clocks
+ *
+ * Copyright 2016 Jean-Francois Moine <moinejf at free.fr>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/rational.h>
+#include <linux/iopoll.h>
+
+static DEFINE_SPINLOCK(sun6i_pll3_lock);
+
+struct clk_fact {
+	struct clk_hw hw;
+	void __iomem *reg;
+};
+#define to_clk_fact(_hw) container_of(_hw, struct clk_fact, hw)
+
+#define SUN6I_PLL3_MSHIFT	0
+#define SUN6I_PLL3_MMASK	GENMASK(3, 0)
+#define SUN6I_PLL3_NSHIFT	8
+#define SUN6I_PLL3_NMASK	GENMASK(7, 0)
+#define SUN6I_PLL3_MODE_SEL	BIT(24)
+#define SUN6I_PLL3_FRAC_CLK	BIT(25)
+#define SUN6I_PLL3_LOCK_BIT	28
+#define SUN6I_PLL3_GATE_BIT	31
+
+static u32 sun6i_pll3_get_fact(unsigned long rate,
+			unsigned long parent_rate,
+			unsigned long *n, unsigned long *m)
+{
+	if (rate == 297000000)
+		return SUN6I_PLL3_FRAC_CLK;
+	if (rate == 270000000)
+		return 0;
+	rational_best_approximation(rate, parent_rate,
+				SUN6I_PLL3_NMASK + 1, SUN6I_PLL3_MMASK + 1,
+				n, m);
+	return SUN6I_PLL3_MODE_SEL;
+}
+
+static unsigned long sun6i_pll3_recalc_rate(struct clk_hw *hw,
+					unsigned long parent_rate)
+{
+	struct clk_fact *fact = to_clk_fact(hw);
+	u32 reg;
+	u32 n, m;
+
+	reg = readl(fact->reg);
+	if (reg & SUN6I_PLL3_MODE_SEL) {
+		n = (reg >> SUN6I_PLL3_NSHIFT) & SUN6I_PLL3_NMASK;
+		m = (reg >> SUN6I_PLL3_MSHIFT) & SUN6I_PLL3_MMASK;
+		return parent_rate / (m + 1) * (n + 1);
+	}
+	if (reg & SUN6I_PLL3_FRAC_CLK)
+		return 297000000;
+	return 270000000;
+}
+
+static long sun6i_pll3_round_rate(struct clk_hw *hw, unsigned long rate,
+				unsigned long *parent_rate)
+{
+	u32 frac;
+	unsigned long n, m;
+
+	frac = sun6i_pll3_get_fact(rate, *parent_rate, &n, &m);
+	if (frac & SUN6I_PLL3_MODE_SEL)
+		return *parent_rate / m * n;
+	if (frac & SUN6I_PLL3_FRAC_CLK)
+		return 297000000;
+	return 270000000;
+}
+
+static int sun6i_pll3_set_rate(struct clk_hw *hw, unsigned long rate,
+			unsigned long parent_rate)
+{
+	struct clk_fact *fact = to_clk_fact(hw);
+	u32 reg;
+	unsigned long n, m;
+
+	reg = readl(fact->reg) &
+			~(SUN6I_PLL3_MODE_SEL |
+			  SUN6I_PLL3_FRAC_CLK |
+			  (SUN6I_PLL3_NMASK << SUN6I_PLL3_NSHIFT) |
+			  (SUN6I_PLL3_MMASK << SUN6I_PLL3_MSHIFT));
+
+	reg |= sun6i_pll3_get_fact(rate, parent_rate, &n, &m);
+	if (reg & SUN6I_PLL3_MODE_SEL)
+		reg |= ((n - 1) << SUN6I_PLL3_NSHIFT) |
+			((m - 1) << SUN6I_PLL3_MSHIFT);
+
+	writel(reg, fact->reg);
+
+	readl_poll_timeout(fact->reg, reg, reg & SUN6I_PLL3_LOCK_BIT, 10, 500);
+
+	return 0;
+}
+
+static const struct clk_ops clk_sun6i_pll3_fact_ops = {
+	.recalc_rate = sun6i_pll3_recalc_rate,
+	.round_rate = sun6i_pll3_round_rate,
+	.set_rate = sun6i_pll3_set_rate,
+};
+
+static void __init sun6i_pll3_setup(struct device_node *node)
+{
+	const char *clk_name, *parent;
+	void __iomem *mmio;
+	struct clk_fact *fact;
+	struct clk_gate *gate;
+	struct resource res;
+	struct clk *clk;
+
+	mmio = of_io_request_and_map(node, 0, of_node_full_name(node));
+	if (IS_ERR(mmio)) {
+		pr_err("%s: Could not map the clock registers\n", clk_name);
+		return;
+	}
+
+	gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+	if (!gate)
+		goto free_mmio;
+	gate->reg = mmio;
+	gate->bit_idx = SUN6I_PLL3_GATE_BIT;
+	gate->lock = &sun6i_pll3_lock;
+
+	fact = kzalloc(sizeof(*fact), GFP_KERNEL);
+	if (!fact)
+		goto free_gate;
+	fact->reg = mmio;
+
+	parent = of_clk_get_parent_name(node, 0);
+
+	of_property_read_string(node, "clock-output-names", &clk_name);
+
+	clk = clk_register_composite(NULL, clk_name,
+				     &parent, 1,
+				     NULL, NULL,
+				     &fact->hw, &clk_sun6i_pll3_fact_ops,
+				     &gate->hw, &clk_gate_ops,
+				     0);
+	if (IS_ERR(clk)) {
+		pr_err("%s: Couldn't register the clock\n", clk_name);
+		goto free_fact;
+	}
+
+	of_clk_add_provider(node, of_clk_src_simple_get, clk);
+
+	return;
+
+free_fact:
+	kfree(fact);
+free_gate:
+	kfree(gate);
+free_mmio:
+	iounmap(mmio);
+	of_address_to_resource(node, 0, &res);
+	release_mem_region(res.start, resource_size(&res));
+}
+
+CLK_OF_DECLARE(sun6i_pll3, "allwinner,sun6i-pll3-clk", sun6i_pll3_setup);
-- 
2.7.0



From moinejf at free.fr  Tue Feb  2 07:25:51 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Tue, 2 Feb 2016 16:25:51 +0100
Subject: [PATCH v4 2/2] drm: sunxi: Add a basic DRM driver for Allwinner DE2
In-Reply-To: <cover.1454435944.git.moinejf@free.fr>
References: <cover.1454435944.git.moinejf@free.fr>
Message-ID: <76ae5b406ad64b2717c0b1c62c3005a62b2715b8.1454435944.git.moinejf@free.fr>

In recent SoCs, as the H3, Allwinner uses a new display interface, DE2.
This patch adds a DRM video driver for this interface.

Signed-off-by: Jean-Francois Moine <moinejf at free.fr>
---
v4: (no change)
v3:
	- add the hardware cursor
	- simplify and fix the DE2 init sequences
	- generation for all SUNXI SoCs (Andre Przywara)
v2:
	- remarks from Russell King
	- DT documentation added
	- working resolution change with xrandr
	- removal of the HDMI driver
---
 .../devicetree/bindings/display/sunxi.txt          |  81 ++++
 drivers/gpu/drm/Kconfig                            |   2 +
 drivers/gpu/drm/Makefile                           |   1 +
 drivers/gpu/drm/sunxi/Kconfig                      |  20 +
 drivers/gpu/drm/sunxi/Makefile                     |   7 +
 drivers/gpu/drm/sunxi/de2_crtc.c                   | 421 +++++++++++++++++
 drivers/gpu/drm/sunxi/de2_crtc.h                   |  61 +++
 drivers/gpu/drm/sunxi/de2_de.c                     | 505 +++++++++++++++++++++
 drivers/gpu/drm/sunxi/de2_drm.h                    |  40 ++
 drivers/gpu/drm/sunxi/de2_drv.c                    | 377 +++++++++++++++
 drivers/gpu/drm/sunxi/de2_plane.c                  |  91 ++++
 11 files changed, 1606 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/sunxi.txt
 create mode 100644 drivers/gpu/drm/sunxi/Kconfig
 create mode 100644 drivers/gpu/drm/sunxi/Makefile
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c

diff --git a/Documentation/devicetree/bindings/display/sunxi.txt b/Documentation/devicetree/bindings/display/sunxi.txt
new file mode 100644
index 0000000..35f9763
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sunxi.txt
@@ -0,0 +1,81 @@
+Allwinner sunxi display subsystem
+=================================
+
+The sunxi display subsystems contain a display controller (DE),
+one or two LCD controllers (TCON) and their external interfaces.
+
+Display controller
+==================
+
+Required properties:
+
+- compatible: value should be one of the following
+		"allwinner,sun8i-h3-display-engine"
+
+- clocks: must include clock specifiers corresponding to entries in the
+		clock-names property.
+
+- clock-names: must contain
+		gate: for DE activation
+		clock: DE clock
+
+- resets: phandle to the reset of the device
+
+- ports: phandle's to the LCD ports
+
+LCD controller
+==============
+
+Required properties:
+
+- compatible: value should be one of the following
+		"allwinner,sun8i-h3-lcd"
+
+- clocks: must include clock specifiers corresponding to entries in the
+		clock-names property.
+
+- clock-names: must contain
+		gate: for LCD activation
+		clock: pixel clock
+
+- resets: phandle to the reset of the device
+
+- port: port node with endpoint definitions as defined in
+	Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+	de: de-controller at 01000000 {
+		compatible = "allwinner,sun8i-h3-display-engine";
+		...
+		clocks = <&bus_gates 44>, <&de_clk>;
+		clock-names = "gate", "clock";
+		resets = <&ahb_rst 44>;
+		ports = <&lcd0_p>;
+	};
+
+	lcd0: lcd-controller at 01c0c000 {
+		compatible = "allwinner,sun8i-h3-lcd";
+		...
+		clocks = <&bus_gates 35>, <&tcon0_clk>;
+		clock-names = "gate", "clock";
+		resets = <&ahb_rst 35>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		lcd0_p: port {
+			lcd0_ep: endpoint {
+				remote-endpoint = <&hdmi_ep>;
+			};
+		};
+	};
+
+	hdmi: hdmi at 01ee0000 {
+		...
+		#address-cells = <1>;
+		#size-cells = <0>;
+		port {
+			hdmi_ep: endpoint {
+				remote-endpoint = <&lcd0_ep>;
+			};
+		};
+	};
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 8ae7ab6..0cec9a1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -269,3 +269,5 @@ source "drivers/gpu/drm/imx/Kconfig"
 source "drivers/gpu/drm/vc4/Kconfig"
 
 source "drivers/gpu/drm/etnaviv/Kconfig"
+
+source "drivers/gpu/drm/sunxi/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 61766de..eef53f2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -74,3 +74,4 @@ obj-y			+= panel/
 obj-y			+= bridge/
 obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
+obj-$(CONFIG_DRM_SUNXI) += sunxi/
diff --git a/drivers/gpu/drm/sunxi/Kconfig b/drivers/gpu/drm/sunxi/Kconfig
new file mode 100644
index 0000000..e452930
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/Kconfig
@@ -0,0 +1,20 @@
+#
+# Allwinner Video configuration
+#
+
+config DRM_SUNXI
+	tristate "DRM Support for Allwinner Video"
+	depends on DRM && ARCH_SUNXI
+	depends on OF
+	select DRM_KMS_HELPER
+	select DRM_KMS_CMA_HELPER
+	select DRM_GEM_CMA_HELPER
+	help
+	  Choose this option if you have a Allwinner chipset.
+
+config DRM_SUNXI_DE2
+	tristate "Support for Allwinner Video with DE2 interface"
+	depends on DRM_SUNXI
+	help
+	  Choose this option if your Allwinner chipset has the DE2 interface
+	  as the H3.
diff --git a/drivers/gpu/drm/sunxi/Makefile b/drivers/gpu/drm/sunxi/Makefile
new file mode 100644
index 0000000..3778877
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/Makefile
@@ -0,0 +1,7 @@
+#
+# Makefile for Allwinner's DRM device driver
+#
+
+sunxi-de2-drm-objs := de2_drv.o de2_de.o de2_crtc.o de2_plane.o
+
+obj-$(CONFIG_DRM_SUNXI_DE2) += sunxi-de2-drm.o
diff --git a/drivers/gpu/drm/sunxi/de2_crtc.c b/drivers/gpu/drm/sunxi/de2_crtc.c
new file mode 100644
index 0000000..b5a093e
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/de2_crtc.c
@@ -0,0 +1,421 @@
+/*
+ * Allwinner DRM driver - DE2 CRTC
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moinejf at free.fr>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <linux/component.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_atomic_helper.h>
+#include <asm/io.h>
+
+#include "de2_drm.h"
+#include "de2_crtc.h"
+
+/* I/O map */
+
+struct tcon {
+	u32 gctl;
+#define		TCON_GCTL_TCON_En BIT(31)
+	u32 gint0;
+#define		TCON_GINT0_TCON1_Vb_Int_En BIT(30)
+#define		TCON_GINT0_TCON1_Vb_Int_Flag BIT(12)
+	u32 gint1;
+	u32 dum0[13];
+	u32 tcon0_ctl;
+#define		TCON0_CTL_TCON_En BIT(31)
+	u32 dum1[19];
+	u32 tcon1_ctl;
+#define		TCON1_CTL_TCON_En BIT(31)
+#define		TCON1_CTL_Interlace_En BIT(20)
+#define		TCON1_CTL_Start_Delay_SHIFT 4
+#define		TCON1_CTL_Start_Delay_MASK GENMASK(8, 4)
+	u32 basic0;			/* XI/YI */
+	u32 basic1;			/* LS_XO/LS_YO */
+	u32 basic2;			/* XO/YO */
+	u32 basic3;			/* HT/HBP */
+	u32 basic4;			/* VT/VBP */
+	u32 basic5;			/* HSPW/VSPW */
+	u32 dum2;
+	u32 ps_sync;
+	u32 dum3[15];
+	u32 io_pol;
+#define		TCON1_IO_POL_IO0_inv BIT(24)
+#define		TCON1_IO_POL_IO1_inv BIT(25)
+#define		TCON1_IO_POL_IO2_inv BIT(26)
+	u32 io_tri;
+	u32 dum4[2];
+
+	u32 ceu_ctl;			/* 100 */
+#define     TCON_CEU_CTL_ceu_en BIT(31)
+	u32 dum5[3];
+	u32 ceu_rr;
+	u32 ceu_rg;
+	u32 ceu_rb;
+	u32 ceu_rc;
+	u32 ceu_gr;
+	u32 ceu_gg;
+	u32 ceu_gb;
+	u32 ceu_gc;
+	u32 ceu_br;
+	u32 ceu_bg;
+	u32 ceu_bb;
+	u32 ceu_bc;
+	u32 ceu_rv;
+	u32 ceu_gv;
+	u32 ceu_bv;
+	u32 dum6[45];
+
+	u32 mux_ctl;			/* 200 */
+#define		TCON_MUX_CTL_HDMI_SRC_SHIFT 8
+#define		TCON_MUX_CTL_HDMI_SRC_MASK GENMASK(9, 8)
+	u32 dum7[63];
+
+	u32 fill_ctl;			/* 300 */
+	u32 fill_start0;
+	u32 fill_end0;
+	u32 fill_data0;
+};
+
+#define XY(x, y) (((x) << 16) | (y))
+
+#define tcon_read(base, member) \
+	readl_relaxed(base + offsetof(struct tcon, member))
+#define tcon_write(base, member, data) \
+	writel_relaxed(data, base + offsetof(struct tcon, member))
+
+/*
+ * vertical blank functions
+ */
+int de2_enable_vblank(struct drm_device *drm, unsigned crtc)
+{
+	return 0;
+}
+
+void de2_disable_vblank(struct drm_device *drm, unsigned crtc)
+{
+}
+
+static void de2_set_frame_timings(struct lcd *lcd)
+{
+	struct drm_crtc *crtc = &lcd->crtc;
+	const struct drm_display_mode *mode = &crtc->mode;
+	int interlace = mode->flags & DRM_MODE_FLAG_INTERLACE ? 2 : 1;
+	int start_delay;
+	u32 data;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	data = XY(mode->hdisplay - 1, mode->vdisplay / interlace - 1);
+	tcon_write(lcd->mmio, basic0, data);
+	tcon_write(lcd->mmio, basic1, data);
+	tcon_write(lcd->mmio, basic2, data);
+	tcon_write(lcd->mmio, basic3,
+			XY(mode->htotal - 1,
+				mode->htotal - mode->hsync_start - 1));
+	tcon_write(lcd->mmio, basic4,
+			XY(mode->vtotal * (3 - interlace),
+				mode->vtotal - mode->vsync_start - 1));
+	tcon_write(lcd->mmio, basic5,
+			 XY(mode->hsync_end - mode->hsync_start - 1,
+				mode->vsync_end - mode->vsync_start - 1));
+
+	tcon_write(lcd->mmio, ps_sync, XY(1, 1));
+
+	data = TCON1_IO_POL_IO2_inv;
+	if (mode->flags & DRM_MODE_FLAG_PVSYNC)
+		data |= TCON1_IO_POL_IO0_inv;
+	if (mode->flags & DRM_MODE_FLAG_PHSYNC)
+		data |= TCON1_IO_POL_IO1_inv;
+	tcon_write(lcd->mmio, io_pol, data);
+
+	tcon_write(lcd->mmio, ceu_ctl,
+		tcon_read(lcd->mmio, ceu_ctl) & ~TCON_CEU_CTL_ceu_en);
+
+	data = tcon_read(lcd->mmio, tcon1_ctl);
+	if (interlace == 2)
+		data |= TCON1_CTL_Interlace_En;
+	else
+		data &= ~TCON1_CTL_Interlace_En;
+	tcon_write(lcd->mmio, tcon1_ctl, data);
+
+	tcon_write(lcd->mmio, fill_ctl, 0);
+	tcon_write(lcd->mmio, fill_start0, mode->vtotal + 1);
+	tcon_write(lcd->mmio, fill_end0, mode->vtotal);
+	tcon_write(lcd->mmio, fill_data0, 0);
+
+	start_delay = (mode->vtotal - mode->vdisplay) / interlace - 5;
+	if (start_delay > 31)
+		start_delay = 31;
+	data = tcon_read(lcd->mmio, tcon1_ctl);
+	data &= ~TCON1_CTL_Start_Delay_MASK;
+	data |= start_delay << TCON1_CTL_Start_Delay_SHIFT;
+	tcon_write(lcd->mmio, tcon1_ctl, data);
+
+	tcon_write(lcd->mmio, io_tri, 0x0fffffff);
+}
+
+static void de2_crtc_enable(struct drm_crtc *crtc)
+{
+	struct lcd *lcd = crtc_to_lcd(crtc);
+	struct drm_display_mode *mode = &crtc->mode;
+	u32 data;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	de2_set_frame_timings(lcd);
+
+	clk_set_rate(lcd->clk, mode->clock * 1000);
+
+	if (lcd->num == 0) {				/* HDMI */
+		data = tcon_read(lcd->mmio, mux_ctl);
+		data &= ~TCON_MUX_CTL_HDMI_SRC_MASK;
+		data |= lcd->num << TCON_MUX_CTL_HDMI_SRC_SHIFT;
+		tcon_write(lcd->mmio, mux_ctl, data);
+	}
+
+	tcon_write(lcd->mmio, tcon1_ctl,
+		tcon_read(lcd->mmio, tcon1_ctl) | TCON1_CTL_TCON_En);
+
+	de2_de_panel_init(lcd->priv, lcd->num, mode);
+
+	drm_mode_debug_printmodeline(mode);
+}
+
+static void de2_crtc_disable(struct drm_crtc *crtc)
+{
+	struct lcd *lcd = crtc_to_lcd(crtc);
+
+	DRM_DEBUG_DRIVER("\n");
+
+	tcon_write(lcd->mmio, tcon1_ctl,
+		tcon_read(lcd->mmio, tcon1_ctl) & ~TCON1_CTL_TCON_En);
+}
+
+static const struct drm_crtc_funcs de2_crtc_funcs = {
+	.destroy	= drm_crtc_cleanup,
+	.set_config	= drm_atomic_helper_set_config,
+	.page_flip	= drm_atomic_helper_page_flip,
+	.reset		= drm_atomic_helper_crtc_reset,
+	.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+};
+
+static const struct drm_crtc_helper_funcs de2_crtc_helper_funcs = {
+	.enable		= de2_crtc_enable,
+	.disable	= de2_crtc_disable,
+};
+
+static void de2_tcon_enable(struct lcd *lcd)
+{
+	DRM_DEBUG_DRIVER("\n");
+
+	tcon_write(lcd->mmio, tcon0_ctl,
+		tcon_read(lcd->mmio, tcon0_ctl) & ~TCON0_CTL_TCON_En);
+	tcon_write(lcd->mmio, tcon1_ctl,
+		tcon_read(lcd->mmio, tcon1_ctl) & ~TCON1_CTL_TCON_En);
+	tcon_write(lcd->mmio, gctl,
+		tcon_read(lcd->mmio, gctl) & ~TCON_GCTL_TCON_En);
+
+	tcon_write(lcd->mmio, gint0,
+		tcon_read(lcd->mmio, gint0) & ~(TCON_GINT0_TCON1_Vb_Int_En |
+						TCON_GINT0_TCON1_Vb_Int_Flag));
+
+	tcon_write(lcd->mmio, gctl,
+		tcon_read(lcd->mmio, gctl) | TCON_GCTL_TCON_En);
+}
+
+static int de2_crtc_init(struct drm_device *drm, struct lcd *lcd)
+{
+	struct drm_crtc *crtc = &lcd->crtc;
+	int ret;
+
+	ret = de2_plane_init(drm, lcd);
+	if (ret < 0)
+		return ret;
+
+	ret = drm_crtc_init_with_planes(drm, crtc,
+					&lcd->planes[DE2_PRIMARY_PLANE],
+					&lcd->planes[DE2_CURSOR_PLANE],
+					&de2_crtc_funcs, NULL);
+	if (ret < 0)
+		return ret;
+
+	de2_tcon_enable(lcd);
+
+	de2_de_enable(lcd->priv, lcd->num);
+
+	drm_crtc_helper_add(crtc, &de2_crtc_helper_funcs);
+
+	return 0;
+}
+
+/*
+ * device init
+ */
+static int de2_lcd_bind(struct device *dev, struct device *master,
+			void *data)
+{
+	struct drm_device *drm = data;
+	struct priv *priv = drm->dev_private;
+	struct lcd *lcd = dev_get_drvdata(dev);
+	int ret;
+
+	lcd->priv = priv;
+
+	ret = de2_crtc_init(drm, lcd);
+	if (ret < 0) {
+		dev_err(dev, "failed to init the crtc\n");
+		return ret;
+	}
+
+	priv->lcds[lcd->num] = lcd;
+
+	return 0;
+}
+
+static void de2_lcd_unbind(struct device *dev, struct device *master,
+			void *data)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct lcd *lcd = platform_get_drvdata(pdev);
+
+	if (lcd->mmio) {
+		if (lcd->priv)
+			de2_de_disable(lcd->priv, lcd->num);
+		tcon_write(lcd->mmio, gctl,
+			tcon_read(lcd->mmio, gctl) & ~TCON_GCTL_TCON_En);
+	}
+}
+
+static const struct component_ops de2_lcd_ops = {
+	.bind = de2_lcd_bind,
+	.unbind = de2_lcd_unbind,
+};
+
+static int de2_lcd_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node, *tmp, *parent, *port;
+	struct lcd *lcd;
+	struct resource *res;
+	int id, ret;
+
+	id = of_alias_get_id(np, "lcd");
+	if (id < 0) {
+		dev_err(dev, "no alias for lcd\n");
+		id = 0;
+	}
+	lcd = devm_kzalloc(dev, sizeof *lcd, GFP_KERNEL);
+	if (!lcd) {
+		dev_err(dev, "failed to allocate private data\n");
+		return -ENOMEM;
+	}
+	dev_set_drvdata(dev, lcd);
+	lcd->dev = dev;
+	lcd->num = id;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(dev, "failed to get memory resource\n");
+		return -EINVAL;
+	}
+
+	lcd->mmio = devm_ioremap_resource(dev, res);
+	if (IS_ERR(lcd->mmio)) {
+		dev_err(dev, "failed to map registers\n");
+		return PTR_ERR(lcd->mmio);
+	}
+
+	snprintf(lcd->name, sizeof(lcd->name), "sunxi-lcd%d", id);
+
+	/* possible CRTCs */
+	parent = np;
+	tmp = of_get_child_by_name(np, "ports");
+	if (tmp)
+		parent = tmp;
+	port = of_get_child_by_name(parent, "port");
+	of_node_put(tmp);
+	if (!port) {
+		dev_err(dev, "no port node\n");
+		return -ENXIO;
+	}
+	lcd->crtc.port = port;
+
+	lcd->gate = devm_clk_get(dev, "gate");
+	if (IS_ERR(lcd->gate)) {
+		dev_err(dev, "gate clock err %d\n", (int) PTR_ERR(lcd->gate));
+		ret = PTR_ERR(lcd->gate);
+		goto err;
+	}
+
+	lcd->clk = devm_clk_get(dev, "clock");
+	if (IS_ERR(lcd->clk)) {
+		dev_err(dev, "video clock err %d\n", (int) PTR_ERR(lcd->clk));
+		ret = PTR_ERR(lcd->clk);
+		goto err;
+	}
+
+	lcd->rstc = devm_reset_control_get(dev, NULL);
+	if (IS_ERR(lcd->rstc)) {
+		dev_err(dev, "reset controller err %d\n",
+				(int) PTR_ERR(lcd->rstc));
+		ret = PTR_ERR(lcd->rstc);
+		goto err;
+	}
+
+	ret = clk_prepare_enable(lcd->clk);
+	if (ret)
+		goto err;
+	ret = clk_prepare_enable(lcd->gate);
+	if (ret)
+		goto err;
+
+	ret = reset_control_deassert(lcd->rstc);
+	if (ret) {
+		dev_err(dev, "reset deassert err %d\n", ret);
+		goto err;
+	}
+
+	return component_add(&pdev->dev, &de2_lcd_ops);
+
+err:
+	clk_disable_unprepare(lcd->gate);
+	clk_disable_unprepare(lcd->clk);
+	of_node_put(lcd->crtc.port);
+	return ret;
+}
+
+static int de2_lcd_remove(struct platform_device *pdev)
+{
+	struct lcd *lcd = platform_get_drvdata(pdev);
+
+	component_del(&pdev->dev, &de2_lcd_ops);
+
+	if (!IS_ERR_OR_NULL(lcd->rstc))
+		reset_control_assert(lcd->rstc);
+	clk_disable_unprepare(lcd->gate);
+	clk_disable_unprepare(lcd->clk);
+	of_node_put(lcd->crtc.port);
+
+	return 0;
+}
+
+static const struct of_device_id de2_lcd_ids[] = {
+	{ .compatible = "allwinner,sun8i-h3-lcd", },
+	{ }
+};
+
+struct platform_driver de2_lcd_platform_driver = {
+	.probe = de2_lcd_probe,
+	.remove = de2_lcd_remove,
+	.driver = {
+		.name = "sun8i-h3-lcd",
+		.of_match_table = of_match_ptr(de2_lcd_ids),
+	},
+};
diff --git a/drivers/gpu/drm/sunxi/de2_crtc.h b/drivers/gpu/drm/sunxi/de2_crtc.h
new file mode 100644
index 0000000..789bd6e
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/de2_crtc.h
@@ -0,0 +1,61 @@
+#ifndef __DE2_CRTC_H__
+#define __DE2_CRTC_H__
+/*
+ * Copyright (C) 2016 Jean-Fran??ois Moine
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <linux/clk.h>
+#include <linux/reset.h>
+#include <drm/drm_plane_helper.h>
+
+struct priv;
+
+enum de2_plane2 {
+	DE2_PRIMARY_PLANE,
+	DE2_CURSOR_PLANE,
+	DE2_N_PLANES,
+};
+struct lcd {
+	void __iomem *mmio;
+
+	struct device *dev;
+	struct drm_crtc crtc;
+	struct priv *priv;	/* DRM/DE private data */
+
+	int num;		/* LCD index 0/1 */
+
+	struct clk *clk;
+	struct clk *gate;
+	struct reset_control *rstc;
+
+	char name[16];
+
+	struct drm_pending_vblank_event *event;
+
+	struct drm_plane planes[DE2_N_PLANES];
+};
+
+#define crtc_to_lcd(x) container_of(x, struct lcd, crtc)
+
+/* in de2_de.c */
+void de2_de_enable(struct priv *priv, int lcd_num);
+void de2_de_disable(struct priv *priv, int lcd_num);
+void de2_de_hw_init(struct priv *priv, int lcd_num);
+void de2_de_panel_init(struct priv *priv, int lcd_num,
+			struct drm_display_mode *mode);
+void de2_de_plane_disable(struct priv *priv,
+			int lcd_num, int plane_ix);
+void de2_de_plane_update(struct priv *priv,
+			int lcd_num, int plane_ix,
+			struct drm_plane_state *state,
+			struct drm_plane_state *old_state);
+
+/* in de2_plane.c */
+int de2_plane_init(struct drm_device *drm, struct lcd *lcd);
+
+#endif /* __DE2_CRTC_H__ */
diff --git a/drivers/gpu/drm/sunxi/de2_de.c b/drivers/gpu/drm/sunxi/de2_de.c
new file mode 100644
index 0000000..9469b11
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/de2_de.c
@@ -0,0 +1,505 @@
+/*
+ * ALLWINNER DRM driver - Display Engine 2
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moinejf at free.fr>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <asm/io.h>
+#include <drm/drm_gem_cma_helper.h>
+
+#include "de2_drm.h"
+#include "de2_crtc.h"
+
+static DEFINE_SPINLOCK(de_lock);
+
+/* I/O map */
+
+#define DE_MOD_REG 0x0000	/* 1 bit per LCD */
+#define DE_GATE_REG 0x0004
+#define DE_RESET_REG 0x0008
+#define DE_DIV_REG 0x000c	/* 4 bits per LCD */
+#define DE_SEL_REG 0x0010
+
+#define DE_MUX0_BASE 0x00100000
+#define DE_MUX1_BASE 0x00200000
+
+/* MUX registers (addr / MUX base) */
+#define DE_MUX_GLB_REGS 0x00000		/* global control */
+#define DE_MUX_BLD_REGS 0x01000		/* alpha blending */
+#define DE_MUX_CHAN_REGS 0x02000	/* VI/UI overlay channels */
+#define		DE_MUX_CHAN_SZ 0x1000	/* size of a channel */
+#define DE_MUX_VSU_REGS 0x20000		/* VSU */
+#define DE_MUX_GSU1_REGS 0x40000	/* GSUs */
+#define DE_MUX_GSU2_REGS 0x60000
+#define DE_MUX_GSU3_REGS 0x80000
+#define DE_MUX_FCE_REGS 0xa0000		/* FCE */
+#define DE_MUX_BWS_REGS 0xa2000		/* BWS */
+#define DE_MUX_LTI_REGS 0xa4000		/* LTI */
+#define DE_MUX_PEAK_REGS 0xa6000	/* PEAK */
+#define DE_MUX_ASE_REGS 0xa8000		/* ASE */
+#define DE_MUX_FCC_REGS 0xaa000		/* FCC */
+#define DE_MUX_DCSC_REGS 0xb0000	/* DCSC */
+
+/* global control */
+struct de_glb {
+	u32 ctl;
+#define		DE_MUX_GLB_CTL_rt_en BIT(0)
+#define		DE_MUX_GLB_CTL_finish_irq_en BIT(4)
+#define		DE_MUX_GLB_CTL_rtwb_port BIT(12)
+	u32 status;
+	u32 dbuff;
+	u32 size;
+};
+
+/* alpha blending */
+struct de_bld {
+	u32 fcolor_ctl;			/* 00 */
+	struct {
+		u32 fcolor;
+		u32 insize;
+		u32 offset;
+		u32 dum;
+	} attr[4];
+	u32 dum0[15];			/* (end of clear offset) */
+	u32 route;			/* 80 */
+	u32 premultiply;
+	u32 bkcolor;
+	u32 output_size;
+	u32 bld_mode[4];
+	u32 dum1[4];
+	u32 ck_ctl;			/* b0 */
+	u32 ck_cfg;
+	u32 dum2[2];
+	u32 ck_max[4];
+	u32 dum3[4];
+	u32 ck_min[4];
+	u32 dum4[3];
+	u32 out_ctl;			/* fc */
+};
+
+/* VI channel */
+struct de_vi {
+	struct {
+		u32 attr;
+#define			VI_CFG_ATTR_en BIT(0)
+#define			VI_CFG_ATTR_fcolor_en BIT(4)
+#define			VI_CFG_ATTR_fmt_SHIFT 8
+#define			VI_CFG_ATTR_fmt_MASK GENMASK(12, 8)
+#define			VI_CFG_ATTR_ui_sel BIT(15)
+#define			VI_CFG_ATTR_top_down BIT(23)
+		u32 size;
+		u32 coord;
+		u32 pitch[3];
+		u32 top_laddr[3];
+		u32 bot_laddr[3];
+	} cfg[4];
+	u32 fcolor[4];			/* c0 */
+	u32 top_haddr[3];		/* d0 */
+	u32 bot_haddr[3];		/* dc */
+	u32 ovl_size[2];		/* e8 */
+	u32 hori[2];			/* f0 */
+	u32 vert[2];			/* f8 */
+};
+
+/* UI channel */
+struct de_ui {
+	struct {
+		u32 attr;
+#define			UI_CFG_ATTR_en BIT(0)
+#define			UI_CFG_ATTR_alpmod_SHIFT 1
+#define			UI_CFG_ATTR_alpmod_MASK GENMASK(2, 1)
+#define			UI_CFG_ATTR_fcolor_en BIT(4)
+#define			UI_CFG_ATTR_fmt_SHIFT 8
+#define			UI_CFG_ATTR_fmt_MASK GENMASK(12, 8)
+#define			UI_CFG_ATTR_top_down BIT(23)
+#define			UI_CFG_ATTR_alpha_SHIFT 24
+#define			UI_CFG_ATTR_alpha_MASK GENMASK(31, 24)
+		u32 size;
+		u32 coord;
+		u32 pitch;
+		u32 top_laddr;
+		u32 bot_laddr;
+		u32 fcolor;
+		u32 dum;
+	} cfg[4];			/* 00 */
+	u32 top_haddr;			/* 80 */
+	u32 bot_haddr;
+	u32 ovl_size;			/* 88 */
+};
+
+#define DE_CORE_CLK_RATE 432000000
+
+/* coordinates and sizes */
+#define XY(x, y) (((y) << 16) | (x))
+#define WH(w, h) (((h - 1) << 16) | (w - 1))
+
+/* UI video formats */
+#define DE2_FORMAT_ARGB_8888 0
+#define DE2_FORMAT_XRGB_8888 4
+#define DE2_FORMAT_RGB_888 8
+#define DE2_FORMAT_BGR_888 9
+
+#define glb_read(base, member) \
+	readl_relaxed(base + offsetof(struct de_glb, member))
+#define glb_write(base, member, data) \
+	writel_relaxed(data, base + offsetof(struct de_glb, member))
+#define bld_read(base, member) \
+	readl_relaxed(base + offsetof(struct de_bld, member))
+#define bld_write(base, member, data) \
+	writel_relaxed(data, base + offsetof(struct de_bld, member))
+#define ui_read(base, member) \
+	readl_relaxed(base + offsetof(struct de_ui, member))
+#define ui_write(base, member, data) \
+	writel_relaxed(data, base + offsetof(struct de_ui, member))
+#define vi_read(base, member) \
+	readl_relaxed(base + offsetof(struct de_vi, member))
+#define vi_write(base, member, data) \
+	writel_relaxed(data, base + offsetof(struct de_vi, member))
+
+static const struct {
+	char chan;
+	char layer;
+} plane2layer[DE2_N_PLANES] = {
+	[DE2_PRIMARY_PLANE] = {.chan = 1, .layer = 0,},
+	[DE2_CURSOR_PLANE] = {.chan = 2, .layer = 0,},
+};
+
+static inline void de_write(struct priv *priv, int reg, u32 data)
+{
+	writel_relaxed(data, priv->mmio + reg);
+}
+
+static inline u32 de_read(struct priv *priv, int reg)
+{
+	return readl_relaxed(priv->mmio + reg);
+}
+
+static void de_lcd_select(struct priv *priv,
+			int lcd_num,
+			void __iomem *mux_o)
+{
+	u32 data;
+
+	/* select the LCD */
+	data = de_read(priv, DE_SEL_REG);
+	if (lcd_num == 0)
+		data &= ~1;
+	else
+		data |= 1;
+	de_write(priv, DE_SEL_REG, data);
+
+	/* double register switch */
+	glb_write(mux_o + DE_MUX_GLB_REGS, dbuff, 1);
+}
+
+void de2_de_plane_update(struct priv *priv,
+			int lcd_num, int plane_ix,
+			struct drm_plane_state *state,
+			struct drm_plane_state *old_state)
+{
+	struct drm_framebuffer *fb = state->fb;
+	struct drm_gem_cma_object *gem;
+	void __iomem *mux_o = priv->mmio;
+	void __iomem *chan_o;
+	u32 size = WH(state->crtc_w, state->crtc_h);
+	u32 coord = XY(state->crtc_x, state->crtc_y);
+	u32 screen_size;
+	u32 data;
+	int chan, layer;
+	unsigned fmt, alpha_glob;
+	unsigned long flags;
+
+	mux_o += (lcd_num == 0) ? DE_MUX0_BASE : DE_MUX1_BASE;
+
+	chan = plane2layer[plane_ix].chan;
+	layer = plane2layer[plane_ix].layer;
+
+	chan_o = mux_o;
+	chan_o += DE_MUX_CHAN_REGS + DE_MUX_CHAN_SZ * chan;
+
+	if (fb == old_state->fb
+	 && ui_read(chan_o, cfg[layer].attr) != 0) {
+		spin_lock_irqsave(&de_lock, flags);
+		de_lcd_select(priv, lcd_num, mux_o);
+		ui_write(chan_o, cfg[layer].coord, coord);
+		spin_unlock_irqrestore(&de_lock, flags);
+		return;
+	}
+
+	gem = drm_fb_cma_get_gem_obj(fb, 0);
+
+	alpha_glob = 0;
+	switch (fb->pixel_format) {
+	case DRM_FORMAT_ARGB8888:
+		fmt = DE2_FORMAT_ARGB_8888;
+		break;
+	case DRM_FORMAT_XRGB8888:
+		fmt = DE2_FORMAT_XRGB_8888;
+		alpha_glob = 1;
+		break;
+	case DRM_FORMAT_RGB888:
+		fmt = DE2_FORMAT_RGB_888;
+		break;
+	case DRM_FORMAT_BGR888:
+		fmt = DE2_FORMAT_BGR_888;
+		break;
+	default:
+		pr_err("format %.4s not yet treated\n",
+			(char *) &fb->pixel_format);
+		return;
+	}
+
+	spin_lock_irqsave(&de_lock, flags);
+
+	if (plane_ix == DE2_PRIMARY_PLANE)
+		screen_size = size;
+	else
+		screen_size = glb_read(mux_o + DE_MUX_GLB_REGS, size);
+
+	de_lcd_select(priv, lcd_num, mux_o);
+
+	data = UI_CFG_ATTR_en |
+			(fmt << UI_CFG_ATTR_fmt_SHIFT);
+	if (alpha_glob)
+		data |= (1 << UI_CFG_ATTR_alpmod_SHIFT) |
+			(0xff << UI_CFG_ATTR_alpha_SHIFT);
+	ui_write(chan_o, cfg[layer].attr, data);
+	ui_write(chan_o, cfg[layer].size, size);
+	ui_write(chan_o, cfg[layer].coord, coord);
+	ui_write(chan_o, cfg[layer].pitch, fb->pitches[0]);
+	ui_write(chan_o, cfg[layer].top_laddr,
+			gem->paddr + fb->offsets[0]);
+	ui_write(chan_o, ovl_size, screen_size);
+
+	if (plane_ix == DE2_PRIMARY_PLANE)
+		bld_write(mux_o + DE_MUX_BLD_REGS,
+					fcolor_ctl, 0x0101);
+	else
+		bld_write(mux_o + DE_MUX_BLD_REGS,
+					fcolor_ctl, 0x0301);
+
+	spin_unlock_irqrestore(&de_lock, flags);
+}
+
+void de2_de_plane_disable(struct priv *priv,
+			int lcd_num, int plane_ix)
+{
+	void __iomem *mux_o = priv->mmio;
+	void __iomem *chan_o;
+	int chan, layer;
+	unsigned long flags;
+
+	chan = plane2layer[plane_ix].chan;
+	layer = plane2layer[plane_ix].layer;
+
+	mux_o += (lcd_num == 0) ? DE_MUX0_BASE : DE_MUX1_BASE;
+	chan_o = mux_o + DE_MUX_CHAN_REGS + DE_MUX_CHAN_SZ * chan;
+
+	spin_lock_irqsave(&de_lock, flags);
+
+	de_lcd_select(priv, lcd_num, mux_o);
+
+	ui_write(chan_o, cfg[layer].attr, 0);
+	bld_write(mux_o + DE_MUX_BLD_REGS, fcolor_ctl, 0x0101);
+
+	spin_unlock_irqrestore(&de_lock, flags);
+}
+
+void de2_de_panel_init(struct priv *priv, int lcd_num,
+			struct drm_display_mode *mode)
+{
+	void __iomem *mux_o = priv->mmio;
+	u32 size = WH(mode->hdisplay, mode->vdisplay);
+	unsigned i;
+	unsigned long flags;
+
+	mux_o += (lcd_num == 0) ? DE_MUX0_BASE : DE_MUX1_BASE;
+
+	DRM_DEBUG_DRIVER("%dx%d\n", mode->hdisplay, mode->vdisplay);
+
+	spin_lock_irqsave(&de_lock, flags);
+
+	de_lcd_select(priv, lcd_num, mux_o);
+
+	glb_write(mux_o + DE_MUX_GLB_REGS, size, size);
+
+	/* set alpha blending */
+	for (i = 0; i < 4; i++)
+		bld_write(mux_o + DE_MUX_BLD_REGS, attr[i].insize, size);
+	bld_write(mux_o + DE_MUX_BLD_REGS, output_size, size);
+	bld_write(mux_o + DE_MUX_BLD_REGS, out_ctl,
+			mode->flags & DRM_MODE_FLAG_INTERLACE ? 2 : 0);
+
+	spin_unlock_irqrestore(&de_lock, flags);
+}
+
+void de2_de_enable(struct priv *priv, int lcd_num)
+{
+	void __iomem *mux_o = priv->mmio;
+	unsigned chan;
+	u32 size = WH(1920, 1080);
+	u32 data;
+	unsigned long flags;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	data = 1 << lcd_num;			/* 1 bit / lcd */
+	de_write(priv, DE_RESET_REG,
+			de_read(priv, DE_RESET_REG) | data);
+	de_write(priv, DE_GATE_REG,
+			de_read(priv, DE_GATE_REG) | data);
+	de_write(priv, DE_MOD_REG,
+			de_read(priv, DE_MOD_REG) | data);
+
+	mux_o += (lcd_num == 0) ? DE_MUX0_BASE : DE_MUX1_BASE;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	spin_lock_irqsave(&de_lock, flags);
+
+	/* select the LCD */
+	data = de_read(priv, DE_SEL_REG);
+	if (lcd_num == 0)
+		data &= ~1;
+	else
+		data |= 1;
+	de_write(priv, DE_SEL_REG, data);
+
+	/* start init */
+	glb_write(mux_o + DE_MUX_GLB_REGS, ctl,
+		DE_MUX_GLB_CTL_rt_en | DE_MUX_GLB_CTL_rtwb_port);
+	glb_write(mux_o + DE_MUX_GLB_REGS, status, 0);
+	glb_write(mux_o + DE_MUX_GLB_REGS, dbuff, 1);	/* dble reg switch */
+	glb_write(mux_o + DE_MUX_GLB_REGS, size, size);
+
+	/* clear the VI/UI channels */
+	for (chan = 0; chan < 4; chan++) {
+		void __iomem *chan_o = mux_o + DE_MUX_CHAN_REGS +
+				DE_MUX_CHAN_SZ * chan;
+
+		if (chan == 0)
+			memset_io(chan_o, 0, sizeof(struct de_vi));
+		else
+			memset_io(chan_o, 0, sizeof(struct de_ui));
+		if (chan == 2 && lcd_num != 0)
+			break;		/* lcd1 only 1 VI and 1 UI */
+	}
+
+	/* clear and set alpha blending */
+	memset_io(mux_o + DE_MUX_BLD_REGS, 0, offsetof(struct de_bld, dum0));
+	bld_write(mux_o + DE_MUX_BLD_REGS, fcolor_ctl, 0x00000101);
+						/* fcolor for primary */
+	bld_write(mux_o + DE_MUX_BLD_REGS, route, 0x0021);
+					/* prepare route primary and cursor */
+	bld_write(mux_o + DE_MUX_BLD_REGS, premultiply, 0);
+	bld_write(mux_o + DE_MUX_BLD_REGS, bkcolor, 0xff000000);
+	bld_write(mux_o + DE_MUX_BLD_REGS, bld_mode[0], 0x03010301);
+								/* SRCOVER */
+	bld_write(mux_o + DE_MUX_BLD_REGS, bld_mode[1], 0x03010301);
+	bld_write(mux_o + DE_MUX_BLD_REGS, bld_mode[2], 0x03010301);
+	bld_write(mux_o + DE_MUX_BLD_REGS, out_ctl, 0);
+
+	/* disable the enhancements */
+	writel_relaxed(0, mux_o + DE_MUX_VSU_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_GSU1_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_GSU2_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_GSU3_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_FCE_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_BWS_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_LTI_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_PEAK_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_ASE_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_FCC_REGS);
+	writel_relaxed(0, mux_o + DE_MUX_DCSC_REGS);
+
+	spin_unlock_irqrestore(&de_lock, flags);
+}
+
+void de2_de_disable(struct priv *priv, int lcd_num)
+{
+	u32 data;
+
+	data = ~(1 << lcd_num);
+	de_write(priv, DE_MOD_REG,
+			de_read(priv, DE_MOD_REG) & data);
+	de_write(priv, DE_GATE_REG,
+			de_read(priv, DE_GATE_REG) & data);
+	de_write(priv, DE_RESET_REG,
+			de_read(priv, DE_RESET_REG) & data);
+}
+
+int de2_de_init(struct priv *priv, struct device *dev)
+{
+	struct resource *res;
+	int ret;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	res = platform_get_resource(to_platform_device(dev),
+				IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(dev, "failed to get memory resource\n");
+		return -EINVAL;
+	}
+
+	priv->mmio = devm_ioremap_resource(dev, res);
+	if (IS_ERR(priv->mmio)) {
+		dev_err(dev, "failed to map registers\n");
+		return PTR_ERR(priv->mmio);
+	}
+
+	priv->gate = devm_clk_get(dev, "gate");
+	if (IS_ERR(priv->gate)) {
+		dev_err(dev, "gate clock err %d\n", (int) PTR_ERR(priv->gate));
+		return PTR_ERR(priv->gate);
+	}
+
+	priv->clk = devm_clk_get(dev, "clock");
+	if (IS_ERR(priv->clk)) {
+		dev_err(dev, "video clock err %d\n", (int) PTR_ERR(priv->clk));
+		return PTR_ERR(priv->clk);
+	}
+
+	priv->rstc = devm_reset_control_get(dev, NULL);
+	if (IS_ERR(priv->rstc)) {
+		dev_err(dev, "reset controller err %d\n",
+				(int) PTR_ERR(priv->rstc));
+		return PTR_ERR(priv->rstc);
+	}
+
+	ret = clk_prepare_enable(priv->clk);
+	if (ret)
+		return ret;
+	ret = clk_prepare_enable(priv->gate);
+	if (ret)
+		goto err_gate;
+
+	/* the DE has a fixed clock rate */
+	clk_set_rate(priv->clk, DE_CORE_CLK_RATE);
+
+	ret = reset_control_deassert(priv->rstc);
+	if (ret) {
+		dev_err(dev, "reset deassert err %d\n", ret);
+		goto err_reset;
+	}
+
+	return 0;
+
+err_reset:
+	clk_disable_unprepare(priv->gate);
+err_gate:
+	clk_disable_unprepare(priv->clk);
+	return ret;
+}
+
+void de2_de_cleanup(struct priv *priv)
+{
+	reset_control_assert(priv->rstc);
+	clk_disable_unprepare(priv->gate);
+	clk_disable_unprepare(priv->clk);
+}
diff --git a/drivers/gpu/drm/sunxi/de2_drm.h b/drivers/gpu/drm/sunxi/de2_drm.h
new file mode 100644
index 0000000..1e6cf6d
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/de2_drm.h
@@ -0,0 +1,40 @@
+#ifndef __DE2_DRM_H__
+#define __DE2_DRM_H__
+/*
+ * Copyright (C) 2016 Jean-Fran??ois Moine
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <linux/clk.h>
+#include <linux/reset.h>
+#include <drm/drmP.h>
+#include <drm/drm_fb_cma_helper.h>
+
+struct lcd;
+
+#define N_LCDS 2
+struct priv {
+	void __iomem *mmio;
+	struct clk *clk;
+	struct clk *gate;
+	struct reset_control *rstc;
+
+	struct drm_fbdev_cma *fbdev;
+
+	struct lcd *lcds[N_LCDS];
+};
+
+/* in de2_crtc.c */
+int de2_enable_vblank(struct drm_device *drm, unsigned crtc);
+void de2_disable_vblank(struct drm_device *drm, unsigned crtc);
+extern struct platform_driver de2_lcd_platform_driver;
+
+/* in de2_de.c */
+int de2_de_init(struct priv *priv, struct device *dev);
+void de2_de_cleanup(struct priv *priv);
+
+#endif /* __DE2_DRM_H__ */
diff --git a/drivers/gpu/drm/sunxi/de2_drv.c b/drivers/gpu/drm/sunxi/de2_drv.c
new file mode 100644
index 0000000..bfb9100
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/de2_drv.c
@@ -0,0 +1,377 @@
+/*
+ * Allwinner DRM driver - DE2 DRM driver
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moinejf at free.fr>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/pm.h>
+#include <linux/pm_runtime.h>
+#include <linux/of_graph.h>
+#include <linux/component.h>
+#include <drm/drm_of.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_gem_cma_helper.h>
+
+#include "de2_drm.h"
+
+#define DRIVER_NAME	"sunxi-de2"
+#define DRIVER_DESC	"Allwinner DRM DE2"
+#define DRIVER_DATE	"20160201"
+#define DRIVER_MAJOR	1
+#define DRIVER_MINOR	0
+
+static void de2_fb_output_poll_changed(struct drm_device *drm)
+{
+	struct priv *priv = drm->dev_private;
+
+	if (priv->fbdev)
+		drm_fbdev_cma_hotplug_event(priv->fbdev);
+}
+
+static const struct drm_mode_config_funcs de2_mode_config_funcs = {
+	.fb_create = drm_fb_cma_create,
+	.output_poll_changed = de2_fb_output_poll_changed,
+	.atomic_check = drm_atomic_helper_check,
+	.atomic_commit = drm_atomic_helper_commit,
+};
+
+/*
+ * DRM operations:
+ */
+static void de2_lastclose(struct drm_device *drm)
+{
+	struct priv *priv = drm->dev_private;
+
+	if (priv->fbdev)
+		drm_fbdev_cma_restore_mode(priv->fbdev);
+}
+
+static const struct file_operations de2_fops = {
+	.owner		= THIS_MODULE,
+	.open		= drm_open,
+	.release	= drm_release,
+	.unlocked_ioctl	= drm_ioctl,
+	.poll		= drm_poll,
+	.read		= drm_read,
+	.llseek		= no_llseek,
+	.mmap		= drm_gem_cma_mmap,
+};
+
+static struct drm_driver de2_drm_driver = {
+	.driver_features	= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
+					DRIVER_ATOMIC,
+	.lastclose		= de2_lastclose,
+	.get_vblank_counter	= drm_vblank_no_hw_counter,
+	.enable_vblank		= de2_enable_vblank,
+	.disable_vblank		= de2_disable_vblank,
+	.gem_free_object	= drm_gem_cma_free_object,
+	.gem_vm_ops		= &drm_gem_cma_vm_ops,
+	.prime_handle_to_fd	= drm_gem_prime_handle_to_fd,
+	.prime_fd_to_handle	= drm_gem_prime_fd_to_handle,
+	.gem_prime_import	= drm_gem_prime_import,
+	.gem_prime_export	= drm_gem_prime_export,
+	.gem_prime_get_sg_table	= drm_gem_cma_prime_get_sg_table,
+	.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
+	.gem_prime_vmap		= drm_gem_cma_prime_vmap,
+	.gem_prime_vunmap	= drm_gem_cma_prime_vunmap,
+	.gem_prime_mmap		= drm_gem_cma_prime_mmap,
+	.dumb_create		= drm_gem_cma_dumb_create,
+	.dumb_map_offset	= drm_gem_cma_dumb_map_offset,
+	.dumb_destroy		= drm_gem_dumb_destroy,
+	.fops			= &de2_fops,
+	.name			= DRIVER_NAME,
+	.desc			= DRIVER_DESC,
+	.date			= DRIVER_DATE,
+	.major			= DRIVER_MAJOR,
+	.minor			= DRIVER_MINOR,
+};
+
+#ifdef CONFIG_PM_SLEEP
+/*
+ * Power management
+ */
+static int de2_pm_suspend(struct device *dev)
+{
+	struct drm_device *drm = dev_get_drvdata(dev);
+
+	drm_kms_helper_poll_disable(drm);
+	return 0;
+}
+
+static int de2_pm_resume(struct device *dev)
+{
+	struct drm_device *drm = dev_get_drvdata(dev);
+
+	drm_kms_helper_poll_enable(drm);
+	return 0;
+}
+#endif
+
+static const struct dev_pm_ops de2_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(de2_pm_suspend, de2_pm_resume)
+};
+
+/*
+ * Platform driver
+ */
+
+static int de2_drm_bind(struct device *dev)
+{
+	struct drm_device *drm;
+	struct priv *priv;
+	int ret;
+
+	DRM_DEBUG_DRIVER("\n");
+
+	drm = drm_dev_alloc(&de2_drm_driver, dev);
+	if (!drm)
+		return -ENOMEM;
+
+	ret = drm_dev_set_unique(drm, dev_name(dev));
+	if (ret < 0)
+		goto out1;
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv) {
+		dev_err(dev, "failed to allocate private area\n");
+		ret = -ENOMEM;
+		goto out1;
+	}
+
+	dev_set_drvdata(dev, drm);
+	drm->dev_private = priv;
+
+	drm_mode_config_init(drm);
+	drm->mode_config.min_width = 32;	/* needed for cursor */
+	drm->mode_config.min_height = 32;
+	drm->mode_config.max_width = 1920;
+	drm->mode_config.max_height = 1080;
+	drm->mode_config.funcs = &de2_mode_config_funcs;
+
+	ret = drm_dev_register(drm, 0);
+	if (ret < 0)
+		goto out2;
+
+	/* initialize the display engine */
+	ret = de2_de_init(priv, dev);
+	if (ret)
+		goto out3;
+
+	/* start the subdevices */
+	ret = component_bind_all(dev, drm);
+	if (ret < 0)
+		goto out3;
+
+	DRM_DEBUG_DRIVER("%d crtcs %d connectors\n",
+			 drm->mode_config.num_crtc,
+			 drm->mode_config.num_connector);
+
+	ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
+	if (ret < 0)
+		dev_warn(dev, "failed to initialize vblank\n");
+
+	drm_mode_config_reset(drm);
+
+	priv->fbdev = drm_fbdev_cma_init(drm,
+					32,	/* bpp */
+					drm->mode_config.num_crtc,
+					drm->mode_config.num_connector);
+	if (IS_ERR(priv->fbdev)) {
+		ret = PTR_ERR(priv->fbdev);
+		priv->fbdev = NULL;
+		goto out4;
+	}
+
+	drm_kms_helper_poll_init(drm);
+
+	return 0;
+
+out4:
+	component_unbind_all(dev, drm);
+out3:
+	drm_dev_unregister(drm);
+out2:
+	kfree(priv);
+out1:
+	drm_dev_unref(drm);
+	return ret;
+}
+
+static void de2_drm_unbind(struct device *dev)
+{
+	struct drm_device *drm = dev_get_drvdata(dev);
+	struct priv *priv = drm->dev_private;
+
+	if (priv)
+		drm_fbdev_cma_fini(priv->fbdev);
+
+	drm_kms_helper_poll_fini(drm);
+
+	component_unbind_all(dev, drm);
+
+	drm_dev_unregister(drm);
+
+	drm_mode_config_cleanup(drm);
+
+	if (priv) {
+		de2_de_cleanup(priv);
+		kfree(priv);
+	}
+
+	drm_dev_unref(drm);
+}
+
+static const struct component_master_ops de2_drm_comp_ops = {
+	.bind = de2_drm_bind,
+	.unbind = de2_drm_unbind,
+};
+
+static int compare_of(struct device *dev, void *data)
+{
+	return dev->of_node == data;
+}
+
+static int de2_drm_add_components(struct device *dev,
+				  int (*compare_of)(struct device *, void *),
+				  const struct component_master_ops *m_ops)
+{
+	struct device_node *ep, *port, *remote;
+	struct component_match *match = NULL;
+	int i;
+
+	if (!dev->of_node)
+		return -EINVAL;
+
+	/* bind the CRTCs */
+	for (i = 0; ; i++) {
+		port = of_parse_phandle(dev->of_node, "ports", i);
+		if (!port)
+			break;
+
+		if (!of_device_is_available(port->parent)) {
+			of_node_put(port);
+			continue;
+		}
+
+		component_match_add(dev, &match, compare_of, port->parent);
+		of_node_put(port);
+	}
+
+	if (i == 0) {
+		dev_err(dev, "missing 'ports' property\n");
+		return -ENODEV;
+	}
+	if (!match) {
+		dev_err(dev, "no available port\n");
+		return -ENODEV;
+	}
+
+	/* bind the encoders/connectors */
+	for (i = 0; ; i++) {
+		port = of_parse_phandle(dev->of_node, "ports", i);
+		if (!port)
+			break;
+
+		if (!of_device_is_available(port->parent)) {
+			of_node_put(port);
+			continue;
+		}
+
+		for_each_child_of_node(port, ep) {
+			remote = of_graph_get_remote_port_parent(ep);
+			if (!remote || !of_device_is_available(remote)) {
+				of_node_put(remote);
+				continue;
+			}
+			if (!of_device_is_available(remote->parent)) {
+				dev_warn(dev,
+					 "parent device of %s is not available\n",
+					 remote->full_name);
+				of_node_put(remote);
+				continue;
+			}
+
+			component_match_add(dev, &match, compare_of, remote);
+			of_node_put(remote);
+		}
+		of_node_put(port);
+	}
+
+	return component_master_add_with_match(dev, m_ops, match);
+}
+
+static int de2_drm_probe(struct platform_device *pdev)
+{
+	int ret;
+
+	ret = de2_drm_add_components(&pdev->dev,
+				     compare_of,
+				     &de2_drm_comp_ops);
+	if (ret == -EINVAL)
+		ret = -ENXIO;
+	return ret;
+}
+
+static int de2_drm_remove(struct platform_device *pdev)
+{
+	component_master_del(&pdev->dev, &de2_drm_comp_ops);
+
+	return 0;
+}
+
+static struct of_device_id de2_drm_of_match[] = {
+	{ .compatible = "allwinner,sun8i-h3-display-engine" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, de2_drm_of_match);
+
+static struct platform_driver de2_drm_platform_driver = {
+	.probe      = de2_drm_probe,
+	.remove     = de2_drm_remove,
+	.driver     = {
+		.name = "sun8i-h3-display-engine",
+		.pm = &de2_pm_ops,
+		.of_match_table = de2_drm_of_match,
+	},
+};
+
+static int __init de2_drm_init(void)
+{
+	int ret;
+
+/* uncomment to activate the drm traces at startup time */
+/*	drm_debug = DRM_UT_CORE | DRM_UT_DRIVER | DRM_UT_KMS |
+			DRM_UT_PRIME | DRM_UT_ATOMIC; */
+
+	DRM_DEBUG_DRIVER("\n");
+
+	ret = platform_driver_register(&de2_lcd_platform_driver);
+	if (ret < 0)
+		return ret;
+
+	ret = platform_driver_register(&de2_drm_platform_driver);
+	if (ret < 0)
+		platform_driver_unregister(&de2_lcd_platform_driver);
+
+	return ret;
+}
+
+static void __exit de2_drm_fini(void)
+{
+	platform_driver_unregister(&de2_lcd_platform_driver);
+	platform_driver_unregister(&de2_drm_platform_driver);
+}
+
+module_init(de2_drm_init);
+module_exit(de2_drm_fini);
+
+MODULE_AUTHOR("Jean-Francois Moine <moinejf at free.fr>");
+MODULE_DESCRIPTION("Allwinner DE2 DRM Driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/sunxi/de2_plane.c b/drivers/gpu/drm/sunxi/de2_plane.c
new file mode 100644
index 0000000..ae3e13f
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/de2_plane.c
@@ -0,0 +1,91 @@
+/*
+ * Allwinner DRM driver - DE2 planes
+ *
+ * Copyright (C) 2016 Jean-Francois Moine <moinejf at free.fr>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_plane_helper.h>
+#include <drm/drm_crtc_helper.h>
+
+#include "de2_drm.h"
+#include "de2_crtc.h"
+
+/* plane formats */
+static const uint32_t ui_formats[] = {
+	DRM_FORMAT_ARGB8888,
+	DRM_FORMAT_XRGB8888,
+	DRM_FORMAT_RGB888,
+	DRM_FORMAT_BGR888,
+};
+
+static void de2_plane_disable(struct drm_plane *plane,
+				struct drm_plane_state *old_state)
+{
+	struct drm_crtc *crtc = old_state->crtc;
+	struct lcd *lcd = crtc_to_lcd(crtc);
+	int plane_num = plane - lcd->planes;
+
+	de2_de_plane_disable(lcd->priv, lcd->num, plane_num);
+}
+
+static void de2_plane_update(struct drm_plane *plane,
+				struct drm_plane_state *old_state)
+{
+	struct drm_plane_state *state = plane->state;
+	struct drm_crtc *crtc = state->crtc;
+	struct lcd *lcd = crtc_to_lcd(crtc);
+	struct drm_framebuffer *fb = state->fb;
+	int plane_num = plane - lcd->planes;
+
+	if (!crtc || !fb) {
+		DRM_DEBUG_DRIVER("no crtc/fb\n");
+		return;
+	}
+
+	de2_de_plane_update(lcd->priv, lcd->num, plane_num,
+			    state, old_state);
+}
+
+static const struct drm_plane_helper_funcs plane_helper_funcs = {
+	.atomic_disable = de2_plane_disable,
+	.atomic_update = de2_plane_update,
+};
+
+static const struct drm_plane_funcs plane_funcs = {
+	.update_plane = drm_atomic_helper_update_plane,
+	.disable_plane = drm_atomic_helper_disable_plane,
+	.destroy = drm_plane_cleanup,
+	.reset = drm_atomic_helper_plane_reset,
+	.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
+};
+
+int de2_plane_init(struct drm_device *drm, struct lcd *lcd)
+{
+	int ret, i;
+
+	for (i = 0; i < ARRAY_SIZE(lcd->planes); i++) {
+		ret = drm_universal_plane_init(drm, &lcd->planes[i], 0,
+					&plane_funcs,
+					ui_formats, ARRAY_SIZE(ui_formats),
+					i == DE2_PRIMARY_PLANE ?
+						DRM_PLANE_TYPE_PRIMARY :
+						DRM_PLANE_TYPE_CURSOR,
+					NULL);
+		if (ret < 0) {
+			dev_err(lcd->dev,
+				"Couldn't initialize plane err %d\n", ret);
+			return ret;
+		}
+		drm_plane_helper_add(&lcd->planes[i],
+				     &plane_helper_funcs);
+	}
+
+	return 0;
+}
-- 
2.7.0



From gregory.clement at free-electrons.com  Tue Feb  2 10:07:38 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  2 Feb 2016 19:07:38 +0100
Subject: [PATCH 00/10] Add support for the Armada 3700 SoC an mvebu ARM64 based
Message-ID: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>

Hi,

This series introduce the support of the Armada 3700 family: it is the
first ARM64 SoC of the mvebu family submitted to the mainline!

Currently there are two members of the Armada 3700 family, the only
difference is the number of core: the Armada 3710 comes with one
Cortex-A53 whereas the Armada 3720 comes with 2 Cortex-A53. In this
series we enabled only the minimum to boot, pinctrl and clock tree
will come soon.

Besides this the patches are pretty usual:

The first patch introduces a new serial driver for the uart used on
this SoC. The driver remains simple even if the hardware is capable of
doing more.

The second one adapts the ahci driver to support the Armada 3700 SoC.
The forth patch updates the binding documentation with the new
compatible string.

The third patch adds a new entry Kconfig entry for this SoC family.

I took the opportunity of this series to tidy up the Marvell related
files in the binding documentation with the fifth patch.

The sixth patch introduces the compatible string for the SoCs of the
Armada 3700 family.

The seventh patch could be considered as the bulk of this series: it
adds the device tree files for the Armada 3700 SoCs and for the
reference board.

With the introduction of this new family the MAINTAINERS file, the
Marvell README and the ARM64 defconfig files have to be updated: it is
the purpose of the last 3 patches.

The first two patches could be taken directly by the maintainer of
their respective subsystem as there is no dependency at all with the
rest of the series. I think that the rest of the series should go
through the arm-soc maintainer but in doubt I also added the ARM64
maintainer as suggested by get_maintainer.pl. Actually all the patches
are independents.

Thanks,

Gregory

Gregory CLEMENT (8):
  arm64: add Armada 3700 architecture entry
  Documentation: dt-bindings: Add a new compatible for the Armada 3700
  Documentation: dt: Tidy up the Marvell related files
  devicetree: bindings: add DT binding for the Marvell Armada 3700 SoC
    family
  arm64: dts: add the Marvell Armada 3700 family and a development board
  MAINTAINERS: Extend dts entry for ARM64 mvebu files
  Documentation: arm: update supported Marvell EBU processors
  arm64: defconfig: enable Armada 3700 related config

Lior Amsalem (1):
  ata: ahci_mvebu: add support for Armada 3700 variant

Wilson Ding (1):
  serial: mvebu-uart: initial support for Armada-3700 serial port

 Documentation/arm/Marvell/README                   |  13 +
 .../arm/{ => marvell}/armada-370-xp-pmsu.txt       |   0
 .../bindings/arm/{ => marvell}/armada-370-xp.txt   |   0
 .../bindings/arm/{ => marvell}/armada-375.txt      |   0
 .../bindings/arm/marvell/armada-37xx.txt           |  17 +
 .../{ => marvell}/armada-380-mpcore-soc-ctrl.txt   |   0
 .../bindings/arm/{ => marvell}/armada-38x.txt      |   0
 .../bindings/arm/{ => marvell}/armada-39x.txt      |   0
 .../arm/{ => marvell}/armada-cpu-reset.txt         |   0
 .../arm/{ => marvell}/coherency-fabric.txt         |   0
 .../bindings/arm/{ => marvell}/kirkwood.txt        |   0
 .../bindings/arm/{ => marvell}/marvell,berlin.txt  |   0
 .../bindings/arm/{ => marvell}/marvell,dove.txt    |   0
 .../arm/{ => marvell}/marvell,kirkwood.txt         |   0
 .../arm/{ => marvell}/mvebu-cpu-config.txt         |   0
 .../arm/{ => marvell}/mvebu-system-controller.txt  |   0
 .../devicetree/bindings/ata/ahci-platform.txt      |   1 +
 .../devicetree/bindings/tty/serial/mvebu-uart.txt  |  13 +
 Documentation/kernel-parameters.txt                |   6 +
 MAINTAINERS                                        |   1 +
 arch/arm64/Kconfig.platforms                       |   6 +
 arch/arm64/boot/dts/marvell/Makefile               |   4 +
 arch/arm64/boot/dts/marvell/armada-371x.dtsi       |  53 ++
 arch/arm64/boot/dts/marvell/armada-3720-db.dts     |  87 +++
 arch/arm64/boot/dts/marvell/armada-372x.dtsi       |  63 ++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi       | 131 +++++
 arch/arm64/configs/defconfig                       |   5 +
 drivers/ata/Kconfig                                |   2 +-
 drivers/ata/ahci_mvebu.c                           |  14 +-
 drivers/tty/serial/Kconfig                         |  22 +
 drivers/tty/serial/Makefile                        |   1 +
 drivers/tty/serial/mvebu-uart.c                    | 649 +++++++++++++++++++++
 include/uapi/linux/serial_core.h                   |   3 +
 33 files changed, 1085 insertions(+), 6 deletions(-)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp-pmsu.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-375.txt (100%)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-380-mpcore-soc-ctrl.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-38x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-39x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-cpu-reset.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/coherency-fabric.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,berlin.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,dove.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-cpu-config.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-system-controller.txt (100%)
 create mode 100644 Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
 create mode 100644 arch/arm64/boot/dts/marvell/armada-371x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-db.dts
 create mode 100644 arch/arm64/boot/dts/marvell/armada-372x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-37xx.dtsi
 create mode 100644 drivers/tty/serial/mvebu-uart.c

-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb  2 10:07:41 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  2 Feb 2016 19:07:41 +0100
Subject: [PATCH 03/10] arm64: add Armada 3700 architecture entry
In-Reply-To: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454436468-4241-4-git-send-email-gregory.clement@free-electrons.com>

The Armada 3700 is an mvebu ARM64 SoC using one or two Cortex-A53 cores
depending of the variant.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm64/Kconfig.platforms | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f674bde..7da341f7b90d 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -1,5 +1,11 @@
 menu "Platform selection"
 
+config ARCH_ARMADA_3700
+	bool "Armada 3700 SoC Family"
+	help
+	  This enables support for Armada 3700 SoC Family. It is is an
+	  ARMv8 based chipset belonging to the mvebu family.
+
 config ARCH_BCM_IPROC
 	bool "Broadcom iProc SoC Family"
 	help
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb  2 10:07:42 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  2 Feb 2016 19:07:42 +0100
Subject: [PATCH 04/10] Documentation: dt-bindings: Add a new compatible for
 the Armada 3700
In-Reply-To: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454436468-4241-5-git-send-email-gregory.clement@free-electrons.com>

The AHCI interfaces used in the Armada 3700 has a few differences with
the one used in the Armada 38x, so it deserves its own compatible string.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 Documentation/devicetree/bindings/ata/ahci-platform.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index c2340eeeb97f..796e2c23e5df 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -13,6 +13,7 @@ Required properties:
   - "hisilicon,hisi-ahci"
   - "ibm,476gtr-ahci"
   - "marvell,armada-380-ahci"
+  - "marvell,armada-3700-ahci"
   - "snps,dwc-ahci"
   - "snps,exynos5440-ahci"
   - "snps,spear-ahci"
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb  2 10:07:40 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  2 Feb 2016 19:07:40 +0100
Subject: [PATCH 02/10] ata: ahci_mvebu: add support for Armada 3700 variant
In-Reply-To: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454436468-4241-3-git-send-email-gregory.clement@free-electrons.com>

From: Lior Amsalem <alior at marvell.com>

The main difference in the new Armada 3700 is that no address
decoding needs to take place in the driver probe.

[gregory.clement at free-electrons.com: reformulate the commit log]

Signed-off-by: Lior Amsalem <alior at marvell.com>
Reviewed-by: Nadav Haklai <nadavh at marvell.com>
Tested-by: Nadav Haklai <nadavh at marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/ata/Kconfig      |  2 +-
 drivers/ata/ahci_mvebu.c | 14 +++++++++-----
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 861643ea91b5..1cc0c966ff88 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -144,7 +144,7 @@ config AHCI_CEVA
 
 config AHCI_MVEBU
 	tristate "Marvell EBU AHCI SATA support"
-	depends on ARCH_MVEBU
+	depends on ARCH_MVEBU || ARCH_ARMADA_3700
 	help
 	  This option enables support for the Marvebu EBU SoC's
 	  onboard AHCI SATA.
diff --git a/drivers/ata/ahci_mvebu.c b/drivers/ata/ahci_mvebu.c
index f7a7fa81740e..de7128d81e9c 100644
--- a/drivers/ata/ahci_mvebu.c
+++ b/drivers/ata/ahci_mvebu.c
@@ -112,12 +112,15 @@ static int ahci_mvebu_probe(struct platform_device *pdev)
 	if (rc)
 		return rc;
 
-	dram = mv_mbus_dram_info();
-	if (!dram)
-		return -ENODEV;
+	if (of_device_is_compatible(pdev->dev.of_node,
+				    "marvell,armada-380-ahci")) {
+		dram = mv_mbus_dram_info();
+		if (!dram)
+			return -ENODEV;
 
-	ahci_mvebu_mbus_config(hpriv, dram);
-	ahci_mvebu_regret_option(hpriv);
+		ahci_mvebu_mbus_config(hpriv, dram);
+		ahci_mvebu_regret_option(hpriv);
+	}
 
 	rc = ahci_platform_init_host(pdev, hpriv, &ahci_mvebu_port_info,
 				     &ahci_platform_sht);
@@ -133,6 +136,7 @@ disable_resources:
 
 static const struct of_device_id ahci_mvebu_of_match[] = {
 	{ .compatible = "marvell,armada-380-ahci", },
+	{ .compatible = "marvell,armada-3700-ahci", },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, ahci_mvebu_of_match);
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb  2 10:07:44 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  2 Feb 2016 19:07:44 +0100
Subject: [PATCH 06/10] devicetree: bindings: add DT binding for the Marvell
 Armada 3700 SoC family
In-Reply-To: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454436468-4241-7-git-send-email-gregory.clement@free-electrons.com>

The Marvell Armada 3700 is a family of ARMv8 CA53 SoCs. This commit
introduces the Device Tree binding that documents the top-level
compatible strings for Armada 3700 based platforms.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 .../devicetree/bindings/arm/marvell/armada-37xx.txt     | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
new file mode 100644
index 000000000000..5db9f1a90da2
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
@@ -0,0 +1,17 @@
+Marvell Armada 37xx Platforms Device Tree Bindings
+--------------------------------------------------
+
+Boards using a SoC of the Marvell Armada 37xx family must carry the
+following root node property:
+
+ - compatible: must contain "marvell,armada3700"
+
+In addition, depending on whether the Armada 3710 or Armada 3720 SoCs
+are being used, the following root node property must be added:
+
+ - compatible: must contain either "marvell,armada3710" or
+   "marvell,armada3720"
+
+Example:
+
+compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3700";
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb  2 10:07:43 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  2 Feb 2016 19:07:43 +0100
Subject: [PATCH 05/10] Documentation: dt: Tidy up the Marvell related files
In-Reply-To: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454436468-4241-6-git-send-email-gregory.clement@free-electrons.com>

Over the last releases we have added more and more Marvell related binding
directly in the arm directory. It's time to have our proper directory
inside it, and move all the files in it.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../devicetree/bindings/arm/{ => marvell}/armada-370-xp-pmsu.txt          | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp.txt     | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-375.txt        | 0
 .../devicetree/bindings/arm/{ => marvell}/armada-380-mpcore-soc-ctrl.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-38x.txt        | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-39x.txt        | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-cpu-reset.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/coherency-fabric.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/kirkwood.txt          | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/marvell,berlin.txt    | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/marvell,dove.txt      | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/marvell,kirkwood.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-cpu-config.txt  | 0
 .../devicetree/bindings/arm/{ => marvell}/mvebu-system-controller.txt     | 0
 14 files changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp-pmsu.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-375.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-380-mpcore-soc-ctrl.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-38x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-39x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-cpu-reset.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/coherency-fabric.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,berlin.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,dove.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-cpu-config.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-system-controller.txt (100%)

diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt b/Documentation/devicetree/bindings/arm/marvell/armada-370-xp-pmsu.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-370-xp-pmsu.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp.txt b/Documentation/devicetree/bindings/arm/marvell/armada-370-xp.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-370-xp.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-370-xp.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-375.txt b/Documentation/devicetree/bindings/arm/marvell/armada-375.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-375.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-375.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-38x.txt b/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-38x.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-39x.txt b/Documentation/devicetree/bindings/arm/marvell/armada-39x.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-39x.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-39x.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-cpu-reset.txt b/Documentation/devicetree/bindings/arm/marvell/armada-cpu-reset.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-cpu-reset.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-cpu-reset.txt
diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/marvell/coherency-fabric.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/coherency-fabric.txt
rename to Documentation/devicetree/bindings/arm/marvell/coherency-fabric.txt
diff --git a/Documentation/devicetree/bindings/arm/kirkwood.txt b/Documentation/devicetree/bindings/arm/marvell/kirkwood.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/kirkwood.txt
rename to Documentation/devicetree/bindings/arm/marvell/kirkwood.txt
diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,berlin.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/marvell,berlin.txt
rename to Documentation/devicetree/bindings/arm/marvell/marvell,berlin.txt
diff --git a/Documentation/devicetree/bindings/arm/marvell,dove.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,dove.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/marvell,dove.txt
rename to Documentation/devicetree/bindings/arm/marvell/marvell,dove.txt
diff --git a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
rename to Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.txt
diff --git a/Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt b/Documentation/devicetree/bindings/arm/marvell/mvebu-cpu-config.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt
rename to Documentation/devicetree/bindings/arm/marvell/mvebu-cpu-config.txt
diff --git a/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/mvebu-system-controller.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/mvebu-system-controller.txt
rename to Documentation/devicetree/bindings/arm/marvell/mvebu-system-controller.txt
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb  2 10:07:39 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  2 Feb 2016 19:07:39 +0100
Subject: [PATCH 01/10] serial: mvebu-uart: initial support for Armada-3700
 serial port
In-Reply-To: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>

From: Wilson Ding <dingwei at marvell.com>

Armada-3700's uart is a simple serial port, which doesn't
support. Configuring the modem control lines. The uart port has a 32
bytes Tx FIFO and a 64 bytes Rx FIFO

The uart driver implements the uart core operations. It also support the
system (early) console based on Armada-3700's serial port.

Known Issue:

The uart driver currently doesn't support clock programming, which means
the baud-rate stays with the default value configured by the bootloader
at boot time

[gregory.clement at free-electrons.com: Rewrite many part which are too long
to enumerate]

Signed-off-by: Wilson Ding <dingwei at marvell.com>
Signed-off-by: Nadav Haklai <nadavh at marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 .../devicetree/bindings/tty/serial/mvebu-uart.txt  |  13 +
 Documentation/kernel-parameters.txt                |   6 +
 drivers/tty/serial/Kconfig                         |  22 +
 drivers/tty/serial/Makefile                        |   1 +
 drivers/tty/serial/mvebu-uart.c                    | 649 +++++++++++++++++++++
 include/uapi/linux/serial_core.h                   |   3 +
 6 files changed, 694 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
 create mode 100644 drivers/tty/serial/mvebu-uart.c

diff --git a/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
new file mode 100644
index 000000000000..6087defd9f93
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
@@ -0,0 +1,13 @@
+* Marvell UART : Non standard UART used in some of Marvell EBU SoCs (e.g., Armada-3700)
+
+Required properties:
+- compatible: "marvell,armada-3700-uart"
+- reg: offset and length of the register set for the device.
+- interrupts: device interrupt
+
+Example:
+	serial at 12000 {
+		compatible = "marvell,armada-3700-uart";
+		reg = <0x12000 0x400>;
+		interrupts = <43>;
+	};
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 87d40a72f6a1..198f6bd56e84 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1058,6 +1058,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			A valid base address must be provided, and the serial
 			port must already be setup and configured.
 
+		mvebu_uart,<addr>
+			Start an early, polled-mode console on an some mvebu
+			SoC (as the Armada-3700) serial port at the specified
+			address. The serial port must already be setup and
+			configured. Options are not yet supported.
+
 	earlyprintk=	[X86,SH,BLACKFIN,ARM,M68k]
 			earlyprintk=vga
 			earlyprintk=efi
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 39721ec4f415..b291f934d51b 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1606,6 +1606,28 @@ config SERIAL_STM32_CONSOLE
 	depends on SERIAL_STM32=y
 	select SERIAL_CORE_CONSOLE
 
+config SERIAL_MVEBU_UART
+	bool "Marvell EBU serial port support"
+	select SERIAL_CORE
+	help
+	  This driver is for Marvell EBU SoC's UART. If you have a machine
+	  based on the Armada-3700 SoC and wish to use the on-board serial
+	  port,
+	  say 'Y' here.
+	  Otherwise, say 'N'.
+
+config SERIAL_MVEBU_CONSOLE
+	bool "Console on Marvell EBU serial port"
+	depends on SERIAL_MVEBU_UART
+	select SERIAL_CORE_CONSOLE
+	select SERIAL_EARLYCON
+	default y
+	help
+	  Say 'Y' here if you wish to use Armada-3700 UART as the system console.
+	  (the system console is the device which receives all kernel messages
+	  and warnings and which allows logins in single user mode)
+	  Otherwise, say 'N'.
+
 endmenu
 
 config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index b391c9b31960..988167595330 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
 obj-$(CONFIG_SERIAL_MEN_Z135)	+= men_z135_uart.o
 obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
 obj-$(CONFIG_SERIAL_STM32)	+= stm32-usart.o
+obj-$(CONFIG_SERIAL_MVEBU_UART)	+= mvebu-uart.o
 
 # GPIOLIB helpers for modem control lines
 obj-$(CONFIG_SERIAL_MCTRL_GPIO)	+= serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
new file mode 100644
index 000000000000..9624070d6058
--- /dev/null
+++ b/drivers/tty/serial/mvebu-uart.c
@@ -0,0 +1,649 @@
+/*
+* ***************************************************************************
+* Copyright (C) 2015 Marvell International Ltd.
+* ***************************************************************************
+* This program is free software: you can redistribute it and/or modify it
+* under the terms of the GNU General Public License as published by the Free
+* Software Foundation, either version 2 of the License, or any later version.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+* GNU General Public License for more details.
+*
+* 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/clk.h>
+#include <linux/console.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/slab.h>
+#include <linux/tty.h>
+#include <linux/tty_flip.h>
+
+/* Register Map */
+#define UART_RBR		0x00
+#define  RBR_BRK_DET		BIT(15)
+#define  RBR_FRM_ERR_DET	BIT(14)
+#define  RBR_PAR_ERR_DET	BIT(13)
+#define  RBR_OVR_ERR_DET	BIT(12)
+
+#define UART_TSH		0x04
+
+#define UART_CTRL		0x08
+#define  CTRL_SOFT_RST		BIT(31)
+#define  CTRL_TXFIFO_RST	BIT(15)
+#define  CTRL_RXFIFO_RST	BIT(14)
+#define  CTRL_ST_MIRR_EN	BIT(13)
+#define  CTRL_LPBK_EN		BIT(12)
+#define  CTRL_SND_BRK_SEQ	BIT(11)
+#define  CTRL_PAR_EN		BIT(10)
+#define  CTRL_TWO_STOP		BIT(9)
+#define  CTRL_TX_HFL_INT	BIT(8)
+#define  CTRL_RX_HFL_INT	BIT(7)
+#define  CTRL_TX_EMP_INT	BIT(6)
+#define  CTRL_TX_RDY_INT	BIT(5)
+#define  CTRL_RX_RDY_INT	BIT(4)
+#define  CTRL_BRK_DET_INT	BIT(3)
+#define  CTRL_FRM_ERR_INT	BIT(2)
+#define  CTRL_PAR_ERR_INT	BIT(1)
+#define  CTRL_OVR_ERR_INT	BIT(0)
+#define  CTRL_RX_INT			(CTRL_RX_RDY_INT | CTRL_BRK_DET_INT |\
+	CTRL_FRM_ERR_INT | CTRL_PAR_ERR_INT | CTRL_OVR_ERR_INT)
+
+#define UART_STAT		0x0c
+#define  STAT_TX_FIFO_EMP	BIT(13)
+#define  STAT_RX_FIFO_EMP	BIT(12)
+#define  STAT_TX_FIFO_FUL	BIT(11)
+#define  STAT_TX_FIFO_HFL	BIT(10)
+#define  STAT_RX_TOGL		BIT(9)
+#define  STAT_RX_FIFO_FUL	BIT(8)
+#define  STAT_RX_FIFO_HFL	BIT(7)
+#define  STAT_TX_EMP		BIT(6)
+#define  STAT_TX_RDY		BIT(5)
+#define  STAT_RX_RDY		BIT(4)
+#define  STAT_BRK_DET		BIT(3)
+#define  STAT_FRM_ERR		BIT(2)
+#define  STAT_PAR_ERR		BIT(1)
+#define  STAT_OVR_ERR		BIT(0)
+#define  STAT_BRK_ERR		(STAT_BRK_DET | STAT_FRM_ERR | STAT_FRM_ERR\
+				 | STAT_PAR_ERR | STAT_OVR_ERR)
+
+#define UART_BRDV		0x10
+
+#define MVEBU_NR_UARTS		1
+
+#define MVEBU_UART_TYPE		"mvebu-uart"
+
+static struct uart_port mvebu_uart_ports[MVEBU_NR_UARTS];
+
+struct mvebu_uart_data {
+	struct uart_port *port;
+	struct clk       *clk;
+};
+
+/* Core UART Driver Operations */
+static unsigned int mvebu_uart_tx_empty(struct uart_port *port)
+{
+	unsigned long flags;
+	unsigned int st;
+
+	spin_lock_irqsave(&port->lock, flags);
+	st = readl(port->membase + UART_STAT);
+	spin_unlock_irqrestore(&port->lock, flags);
+
+	return (st & STAT_TX_FIFO_EMP) ? TIOCSER_TEMT : 0;
+}
+
+static unsigned int mvebu_uart_get_mctrl(struct uart_port *port)
+{
+	return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
+}
+
+static void mvebu_uart_set_mctrl(struct uart_port *port,
+				 unsigned int mctrl)
+{
+/*
+ * Even if we do not support configuring the modem control lines, this
+ * function must be proided to the serial core
+ */
+}
+
+static void mvebu_uart_stop_tx(struct uart_port *port)
+{
+	unsigned int ctl = readl(port->membase + UART_CTRL);
+
+	ctl &= ~CTRL_TX_RDY_INT;
+	writel(ctl, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_start_tx(struct uart_port *port)
+{
+	unsigned int ctl = readl(port->membase + UART_CTRL);
+
+	ctl |= CTRL_TX_RDY_INT;
+	writel(ctl, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_stop_rx(struct uart_port *port)
+{
+	unsigned int ctl = readl(port->membase + UART_CTRL);
+
+	ctl &= ~CTRL_RX_INT;
+	writel(ctl, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_break_ctl(struct uart_port *port, int brk)
+{
+	unsigned int ctl;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port->lock, flags);
+	ctl = readl(port->membase + UART_CTRL);
+	if (brk == -1)
+		ctl |= CTRL_SND_BRK_SEQ;
+	else
+		ctl &= ~CTRL_SND_BRK_SEQ;
+	writel(ctl, port->membase + UART_CTRL);
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static void mvebu_uart_rx_chars(struct uart_port *port, unsigned int status)
+{
+	struct tty_port *tport = &port->state->port;
+	unsigned char ch = 0;
+	char flag = 0;
+
+	do {
+		if (status & STAT_RX_RDY) {
+			ch = readl(port->membase + UART_RBR);
+			ch &= 0xff;
+			flag = TTY_NORMAL;
+			port->icount.rx++;
+
+			if (status & STAT_PAR_ERR)
+				port->icount.parity++;
+		}
+
+		if (status & STAT_BRK_DET) {
+			port->icount.brk++;
+			status &= ~(STAT_FRM_ERR | STAT_PAR_ERR);
+			if (uart_handle_break(port))
+				goto ignore_char;
+		}
+
+		if (status & STAT_OVR_ERR)
+			port->icount.overrun++;
+
+		if (status & STAT_FRM_ERR)
+			port->icount.frame++;
+
+		if (uart_handle_sysrq_char(port, ch))
+			goto ignore_char;
+
+		if (status & port->ignore_status_mask & STAT_PAR_ERR)
+			status &= ~STAT_RX_RDY;
+
+		status &= port->read_status_mask;
+
+		if (status & STAT_PAR_ERR)
+			flag = TTY_PARITY;
+
+		status &= ~port->ignore_status_mask;
+
+		if (status & STAT_RX_RDY)
+			tty_insert_flip_char(tport, ch, flag);
+
+		if (status & STAT_BRK_DET)
+			tty_insert_flip_char(tport, 0, TTY_BREAK);
+
+		if (status & STAT_FRM_ERR)
+			tty_insert_flip_char(tport, 0, TTY_FRAME);
+
+		if (status & STAT_OVR_ERR)
+			tty_insert_flip_char(tport, 0, TTY_OVERRUN);
+
+ignore_char:
+		status = readl(port->membase + UART_STAT);
+	} while (status & (STAT_RX_RDY | STAT_BRK_DET));
+
+	tty_flip_buffer_push(tport);
+}
+
+static void mvebu_uart_tx_chars(struct uart_port *port, unsigned int status)
+{
+	struct circ_buf *xmit = &port->state->xmit;
+	unsigned int count;
+	unsigned int st;
+
+	if (port->x_char) {
+		writel(port->x_char, port->membase + UART_TSH);
+		port->icount.tx++;
+		port->x_char = 0;
+		return;
+	}
+
+	if (uart_circ_empty(xmit) || uart_tx_stopped(port)) {
+		mvebu_uart_stop_tx(port);
+		return;
+	}
+
+	for (count = 0; count < port->fifosize; count++) {
+		writel(xmit->buf[xmit->tail], port->membase + UART_TSH);
+		xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+		port->icount.tx++;
+
+		if (uart_circ_empty(xmit))
+			break;
+
+		st = readl(port->membase + UART_STAT);
+		if (st & STAT_TX_FIFO_FUL)
+			break;
+	}
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+
+	if (uart_circ_empty(xmit))
+		mvebu_uart_stop_tx(port);
+}
+
+static irqreturn_t mvebu_uart_isr(int irq, void *dev_id)
+{
+	struct uart_port *port = (struct uart_port *)dev_id;
+	unsigned int st = readl(port->membase + UART_STAT);
+
+	if (st & (STAT_RX_RDY | STAT_OVR_ERR | STAT_FRM_ERR | STAT_BRK_DET))
+		mvebu_uart_rx_chars(port, st);
+
+	if (st & STAT_TX_RDY)
+		mvebu_uart_tx_chars(port, st);
+
+	return IRQ_HANDLED;
+}
+
+static int mvebu_uart_startup(struct uart_port *port)
+{
+	int ret;
+
+	writel(CTRL_TXFIFO_RST | CTRL_RXFIFO_RST,
+	       port->membase + UART_CTRL);
+	udelay(1);
+	writel(CTRL_RX_INT, port->membase + UART_CTRL);
+
+	ret = request_irq(port->irq, mvebu_uart_isr, port->irqflags, "serial",
+			  port);
+	if (ret) {
+		dev_err(port->dev, "failed to request irq\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static void mvebu_uart_shutdown(struct uart_port *port)
+{
+	writel(0, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_set_termios(struct uart_port *port,
+				   struct ktermios *termios,
+				   struct ktermios *old)
+{
+	unsigned long flags;
+	unsigned int baud;
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	port->read_status_mask = STAT_RX_RDY | STAT_OVR_ERR |
+		STAT_TX_RDY | STAT_TX_FIFO_FUL;
+
+	if (termios->c_iflag & INPCK)
+		port->read_status_mask |= STAT_FRM_ERR | STAT_PAR_ERR;
+
+	port->ignore_status_mask = 0;
+	if (termios->c_iflag & IGNPAR)
+		port->ignore_status_mask |=
+			STAT_FRM_ERR | STAT_PAR_ERR | STAT_OVR_ERR;
+
+	if ((termios->c_cflag & CREAD) == 0)
+		port->ignore_status_mask |= STAT_RX_RDY | STAT_BRK_ERR;
+
+	baud = uart_get_baud_rate(port, termios, old, 0, 460800);
+	uart_update_timeout(port, termios->c_cflag, baud);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *mvebu_uart_type(struct uart_port *port)
+{
+	return MVEBU_UART_TYPE;
+}
+
+static void mvebu_uart_release_port(struct uart_port *port)
+{
+	/* Nothing to do here */
+}
+
+static int mvebu_uart_request_port(struct uart_port *port)
+{
+	return 0;
+}
+
+#ifdef CONFIG_CONSOLE_POLL
+static int mvebu_uart_get_poll_char(struct uart_port *port)
+{
+	unsigned int st = readl(port->membase + UART_STAT);
+
+	if (!(st & STAT_RX_RDY))
+		return NO_POLL_CHAR;
+
+	return readl(port->membase + UART_RBR);
+}
+
+static void mvebu_uart_put_poll_char(struct uart_port *port, unsigned char c)
+{
+	unsigned int st;
+
+	for (;;) {
+		st = readl(port->membase + UART_STAT);
+
+		if (!(st & STAT_TX_FIFO_FUL))
+			break;
+
+		udelay(1);
+	}
+
+	writel(c, port->membase + UART_TSH);
+}
+#endif
+
+static const struct uart_ops mvebu_uart_ops = {
+	.tx_empty	= mvebu_uart_tx_empty,
+	.set_mctrl	= mvebu_uart_set_mctrl,
+	.get_mctrl	= mvebu_uart_get_mctrl,
+	.stop_tx	= mvebu_uart_stop_tx,
+	.start_tx	= mvebu_uart_start_tx,
+	.stop_rx	= mvebu_uart_stop_rx,
+	.break_ctl	= mvebu_uart_break_ctl,
+	.startup	= mvebu_uart_startup,
+	.shutdown	= mvebu_uart_shutdown,
+	.set_termios	= mvebu_uart_set_termios,
+	.type		= mvebu_uart_type,
+	.release_port	= mvebu_uart_release_port,
+	.request_port	= mvebu_uart_request_port,
+#ifdef CONFIG_CONSOLE_POLL
+	.poll_get_char	= mvebu_uart_get_poll_char,
+	.poll_put_char	= mvebu_uart_put_poll_char,
+#endif
+};
+
+/* Console Driver Operations  */
+
+#ifdef CONFIG_SERIAL_MVEBU_CONSOLE
+/* Early Console */
+static void mvebu_uart_putc(struct uart_port *port, int c)
+{
+	unsigned int st;
+
+	for (;;) {
+		st = readl(port->membase + UART_STAT);
+		if (!(st & STAT_TX_FIFO_FUL))
+			break;
+	}
+
+	writel(c, port->membase + UART_TSH);
+
+	for (;;) {
+		st = readl(port->membase + UART_STAT);
+		if (st & STAT_TX_FIFO_EMP)
+			break;
+	}
+}
+
+static void mvebu_uart_putc_early_write(struct console *con,
+					const char *s,
+					unsigned n)
+{
+	struct earlycon_device *dev = con->data;
+
+	uart_console_write(&dev->port, s, n, mvebu_uart_putc);
+}
+
+static int __init
+mvebu_uart_early_console_setup(struct earlycon_device *device,
+			       const char *opt)
+{
+	if (!device->port.membase)
+		return -ENODEV;
+
+	device->con->write = mvebu_uart_putc_early_write;
+
+	return 0;
+}
+
+EARLYCON_DECLARE(ar3700_uart, mvebu_uart_early_console_setup);
+OF_EARLYCON_DECLARE(ar3700_uart, "marvell,armada-3700-uart",
+		    mvebu_uart_early_console_setup);
+
+static void wait_for_xmitr(struct uart_port *port)
+{
+	u32 val;
+
+	readl_poll_timeout_atomic(port->membase + UART_STAT, val,
+				  (val & STAT_TX_EMP), 1, 10000);
+}
+
+static void mvebu_uart_console_putchar(struct uart_port *port, int ch)
+{
+	wait_for_xmitr(port);
+	writel(ch, port->membase + UART_TSH);
+}
+
+static void mvebu_uart_console_write(struct console *co, const char *s,
+				     unsigned int count)
+{
+	struct uart_port *port = &mvebu_uart_ports[co->index];
+	unsigned long flags;
+	unsigned int ier;
+	int locked = 1;
+
+	if (oops_in_progress)
+		locked = spin_trylock_irqsave(&port->lock, flags);
+	else
+		spin_lock_irqsave(&port->lock, flags);
+
+	ier = readl(port->membase + UART_CTRL) &
+		(CTRL_RX_INT | CTRL_TX_RDY_INT);
+	writel(0, port->membase + UART_CTRL);
+
+	uart_console_write(port, s, count, mvebu_uart_console_putchar);
+
+	wait_for_xmitr(port);
+
+	if (ier)
+		writel(ier, port->membase + UART_CTRL);
+
+	if (locked)
+		spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static int mvebu_uart_console_setup(struct console *co, char *options)
+{
+	struct uart_port *port;
+	int baud = 9600;
+	int bits = 8;
+	int parity = 'n';
+	int flow = 'n';
+
+	if (co->index < 0 || co->index >= MVEBU_NR_UARTS)
+		return -EINVAL;
+
+	port = &mvebu_uart_ports[co->index];
+
+	if (!port->mapbase || !port->membase) {
+		pr_debug("console on ttyS%i not present\n", co->index);
+		return -ENODEV;
+	}
+
+	if (options)
+		uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+	return uart_set_options(port, co, baud, parity, bits, flow);
+}
+
+static struct uart_driver mvebu_uart_driver;
+
+static struct console mvebu_uart_console = {
+	.name	= "ttyS",
+	.write	= mvebu_uart_console_write,
+	.device	= uart_console_device,
+	.setup	= mvebu_uart_console_setup,
+	.flags	= CON_PRINTBUFFER,
+	.index	= -1,
+	.data	= &mvebu_uart_driver,
+};
+
+static int __init mvebu_uart_console_init(void)
+{
+	register_console(&mvebu_uart_console);
+	return 0;
+}
+
+console_initcall(mvebu_uart_console_init);
+
+
+#endif /* CONFIG_SERIAL_MVEBU_CONSOLE */
+
+static struct uart_driver mvebu_uart_driver = {
+	.owner			= THIS_MODULE,
+	.driver_name		= "serial",
+	.dev_name		= "ttyS",
+	.major			= TTY_MAJOR,
+	.minor			= 64,
+	.nr			= MVEBU_NR_UARTS,
+#ifdef CONFIG_SERIAL_MVEBU_CONSOLE
+	.cons			= &mvebu_uart_console,
+#endif
+};
+
+static int mvebu_uart_probe(struct platform_device *pdev)
+{
+	struct resource *reg = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	struct resource *irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+	struct uart_port *port;
+	struct mvebu_uart_data *data;
+	int ret;
+
+	if (!reg || !irq) {
+		dev_err(&pdev->dev, "no registers/irq defined\n");
+		return -EINVAL;
+	}
+
+	port = &mvebu_uart_ports[0];
+
+	spin_lock_init(&port->lock);
+
+	port->dev        = &pdev->dev;
+	port->type       = PORT_MVEBU;
+	port->ops        = &mvebu_uart_ops;
+	port->regshift   = 0;
+
+	port->fifosize   = 32;
+	port->iotype     = UPIO_MEM32;
+	port->flags      = UPF_FIXED_PORT;
+	port->line       = 0; /* single port: force line number to  0 */
+
+	port->irq        = irq->start;
+	port->irqflags   = 0;
+	port->mapbase    = reg->start;
+
+	port->membase = devm_ioremap_resource(&pdev->dev, reg);
+	if (IS_ERR(port->membase))
+		return -PTR_ERR(port->membase);
+
+	data = devm_kzalloc(&pdev->dev, sizeof(struct mvebu_uart_data),
+			    GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->port = port;
+
+	port->private_data = data;
+	platform_set_drvdata(pdev, data);
+
+	ret = uart_add_one_port(&mvebu_uart_driver, port);
+	if (ret)
+		return ret;
+	return 0;
+}
+
+static int mvebu_uart_remove(struct platform_device *pdev)
+{
+	struct mvebu_uart_data *data = platform_get_drvdata(pdev);
+
+	uart_remove_one_port(&mvebu_uart_driver, data->port);
+	data->port->private_data = NULL;
+	data->port->mapbase      = 0;
+	return 0;
+}
+
+/* Match table for of_platform binding */
+static const struct of_device_id mvebu_uart_of_match[] = {
+	{ .compatible = "marvell,armada-3700-uart", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, mvebu_uart_of_match);
+
+static struct platform_driver mvebu_uart_platform_driver = {
+	.probe	= mvebu_uart_probe,
+	.remove	= mvebu_uart_remove,
+	.driver	= {
+		.owner	= THIS_MODULE,
+		.name  = "mvebu-uart",
+		.of_match_table = of_match_ptr(mvebu_uart_of_match),
+	},
+};
+
+static int __init mvebu_uart_init(void)
+{
+	int ret;
+
+	ret = uart_register_driver(&mvebu_uart_driver);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&mvebu_uart_platform_driver);
+	if (ret)
+		uart_unregister_driver(&mvebu_uart_driver);
+
+	return ret;
+}
+
+static void __exit mvebu_uart_exit(void)
+{
+	platform_driver_unregister(&mvebu_uart_platform_driver);
+	uart_unregister_driver(&mvebu_uart_driver);
+}
+
+arch_initcall(mvebu_uart_init);
+module_exit(mvebu_uart_exit);
+
+MODULE_AUTHOR("Wilson Ding <dingwei at marvell.com>");
+MODULE_DESCRIPTION("Marvell Armada-3700 Serial Driver");
+MODULE_LICENSE("GPL");
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 3e5d757407fb..e513a4ee369b 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -261,4 +261,7 @@
 /* STM32 USART */
 #define PORT_STM32	113
 
+/* MVEBU UART */
+#define PORT_MVEBU	114
+
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb  2 10:07:48 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  2 Feb 2016 19:07:48 +0100
Subject: [PATCH 10/10] arm64: defconfig: enable Armada 3700 related config
In-Reply-To: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454436468-4241-11-git-send-email-gregory.clement@free-electrons.com>

This patch enables the configuration for the Armada 3700 family and for
the related driver it uses.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm64/configs/defconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 18ca9fb9e65f..f7f3ce09ead0 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -31,6 +31,7 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_ARCH_ARMADA_3700=y
 CONFIG_ARCH_BCM_IPROC=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_ARCH_EXYNOS7=y
@@ -93,6 +94,7 @@ CONFIG_ATA=y
 CONFIG_SATA_AHCI=y
 CONFIG_SATA_AHCI_PLATFORM=y
 CONFIG_AHCI_CEVA=y
+CONFIG_AHCI_MVEBU=y
 CONFIG_AHCI_XGENE=y
 CONFIG_SATA_RCAR=y
 CONFIG_PATA_PLATFORM=y
@@ -132,6 +134,7 @@ CONFIG_SERIAL_MSM_CONSOLE=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SERIAL_XILINX_PS_UART=y
 CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
+CONFIG_SERIAL_MVEBU_UART=y
 CONFIG_VIRTIO_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 CONFIG_I2C=y
@@ -162,6 +165,8 @@ CONFIG_SND_SOC=y
 CONFIG_SND_SOC_RCAR=y
 CONFIG_SND_SOC_AK4613=y
 CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_PLATFORM=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
 CONFIG_USB_OHCI_HCD=y
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb  2 10:07:47 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  2 Feb 2016 19:07:47 +0100
Subject: [PATCH 09/10] Documentation: arm: update supported Marvell EBU
 processors
In-Reply-To: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454436468-4241-10-git-send-email-gregory.clement@free-electrons.com>

Now that we support Armada 37xx, let's add this family of SoC to the
Marvell documentation, and a reference to a link with more details about
those processors. As for Armda 39x, no datasheet is publicly
available at this time.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 Documentation/arm/Marvell/README | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index ae89b67d8e23..ddbc048bb467 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -118,6 +118,19 @@ EBU Armada family
   Linux kernel mach directory: arch/arm/mach-mvebu
   Linux kernel plat directory: none
 
+EBU Armada family ARMv8
+-----------------------
+
+  Armada 3710/3720 Flavors:
+	88F3710
+	88F3720
+
+  Core: ARM Cortex A53 (ARMv8)
+
+  Homepage     : http://www.marvell.com/embedded-processors/armada-3700/
+
+  Device tree descritpion located in arch/arm64/boot/dts/marvell/armada-37*
+
 Avanta family
 -------------
 
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb  2 10:07:46 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  2 Feb 2016 19:07:46 +0100
Subject: [PATCH 08/10] MAINTAINERS: Extend dts entry for ARM64 mvebu files
In-Reply-To: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454436468-4241-9-git-send-email-gregory.clement@free-electrons.com>

Extend the mvebu entry to ARM64 device tree sources.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 30aca4aa5467..ad49b62c5abc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1279,6 +1279,7 @@ F:	arch/arm/mach-mvebu/
 F:	drivers/rtc/rtc-armada38x.c
 F:	arch/arm/boot/dts/armada*
 F:	arch/arm/boot/dts/kirkwood*
+F:	arch/arm64/boot/dts/marvell/armada*
 
 
 ARM/Marvell Berlin SoC support
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb  2 10:07:45 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue,  2 Feb 2016 19:07:45 +0100
Subject: [PATCH 07/10] arm64: dts: add the Marvell Armada 3700 family and a
 development board
In-Reply-To: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454436468-4241-8-git-send-email-gregory.clement@free-electrons.com>

Add initial dtsi files to support Marvell Armada 3700 SoC with Cortex-A53
CPUs. There are two members in this family: the Armada 3710 (Single CPU)
and the Armada 3720 (Dual CPUs).

It also adds a dts file for the Marvell Armada 3720 DB board.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm64/boot/dts/marvell/Makefile           |   4 +
 arch/arm64/boot/dts/marvell/armada-371x.dtsi   |  53 ++++++++++
 arch/arm64/boot/dts/marvell/armada-3720-db.dts |  87 ++++++++++++++++
 arch/arm64/boot/dts/marvell/armada-372x.dtsi   |  63 ++++++++++++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   | 131 +++++++++++++++++++++++++
 5 files changed, 338 insertions(+)
 create mode 100644 arch/arm64/boot/dts/marvell/armada-371x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-db.dts
 create mode 100644 arch/arm64/boot/dts/marvell/armada-372x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-37xx.dtsi

diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index 348f4db4f313..bc2eabe1cab1 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -1,6 +1,10 @@
+# Berlin SoC Family
 dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-dmp.dtb
 dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
 
+# Mvebu SoC Family
+dtb-$(CONFIG_ARCH_ARMADA_3700) += armada-3720-db.dtb
+
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
 clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/marvell/armada-371x.dtsi b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
new file mode 100644
index 000000000000..c9e5325b8ac3
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
@@ -0,0 +1,53 @@
+/*
+ * Device Tree Include file for Marvell Armada 371x family of SoCs
+ * (also named 88F3710)
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "armada-37xx.dtsi"
+
+/ {
+	model = "Marvell Armada 3710 SoC";
+	compatible = "marvell,armada3710", "marvell,armada3700";
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
new file mode 100644
index 000000000000..76cae6ba2bd6
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -0,0 +1,87 @@
+/*
+ * Device Tree file for Marvell Armada 3720 development board
+ * (DB-88F3720-DDR3)
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "armada-372x.dtsi"
+
+/ {
+	model = "Marvell Armada 3720 Development Board DB-88F3720-DDR3";
+	compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3700";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory {
+		device_type = "memory";
+		/* use only 256 MB on the 512 MB available */
+		reg = <0x00000000 0x00000000 0x00000000 0x10000000>;
+	};
+
+	soc {
+		internal-regs {
+			/*
+			* Exported on the micro USB connector CON32
+			* through an FTDI
+			*/
+			uart0: serial at 12000 {
+				status = "okay";
+			};
+
+			/* CON31 */
+			usb3 at 58000 {
+				status = "okay";
+			};
+
+			/* CON3 */
+			sata at e0000 {
+			       status = "okay";
+			};
+		};
+	};
+};
+
diff --git a/arch/arm64/boot/dts/marvell/armada-372x.dtsi b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
new file mode 100644
index 000000000000..f57f41c20ddf
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
@@ -0,0 +1,63 @@
+/*
+ * Device Tree Include file for Marvell Armada 372x family of SoCs
+ * (also named 88F3720)
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "armada-37xx.dtsi"
+
+/ {
+	model = "Marvell Armada 3720 SoC";
+	compatible = "marvell,armada3720", "marvell,armada3700";
+
+	cpus {
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53","arm,armv8";
+			reg = <0x1>;
+			enable-method = "psci";
+		};
+	};
+
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
new file mode 100644
index 000000000000..ba9df7ff2a72
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -0,0 +1,131 @@
+/*
+ * Device Tree Include file for Marvell Armada 37xx family of SoCs.
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	model = "Marvell Armada 37xx SoC";
+	compatible = "marvell,armada3700";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0>;
+			enable-method = "psci";
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		internal-regs {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "simple-bus";
+			/* 32M internal register @ 0xd000_0000 */
+			ranges = <0x0 0x0 0xd0000000 0x2000000>;
+
+			uart0: serial at 12000 {
+				compatible = "marvell,armada-3700-uart";
+				reg = <0x12000 0x400>;
+				interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+				status = "disabled";
+			};
+
+			usb3 at 58000 {
+				compatible = "generic-xhci";
+				reg = <0x58000 0x4000>;
+				interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+				status = "disabled";
+			};
+
+			sata at e0000 {
+				compatible = "marvell,armada-3700-ahci";
+				reg = <0xe0000 0x2000>;
+				interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+				status = "disabled";
+			};
+
+			gic: interrupt-controller at 1d00000 {
+				compatible = "arm,gic-v3";
+				#interrupt-cells = <3>;
+				interrupt-controller;
+				reg = <0x1d00000 0x10000>, /* GICD */
+				      <0x1d40000 0x40000>; /* GICR */
+			};
+		};
+	};
+};
-- 
2.5.0



From adhemerval.zanella at linaro.org  Tue Feb  2 10:12:44 2016
From: adhemerval.zanella at linaro.org (Adhemerval Zanella)
Date: Tue, 2 Feb 2016 16:12:44 -0200
Subject: [PATCH] arm64: Add support for Half precision floating point
In-Reply-To: <56B0E7EA.9050601@arm.com>
References: <1453823566-26742-1-git-send-email-suzuki.poulose@arm.com>
 <20160126160257.GB28238@arm.com> <56A79D17.2000009@arm.com>
 <20160126165538.GC22776@devel.intra.reserved-bit.com>
 <20160128160747.GN775@arm.com> <56AA470E.1020606@linaro.org>
 <56B0E7EA.9050601@arm.com>
Message-ID: <56B0F19C.5090007@linaro.org>



On 02-02-2016 15:31, Szabolcs Nagy wrote:
> On 28/01/16 16:51, Adhemerval Zanella wrote:
>> On 28-01-2016 14:07, Will Deacon wrote:
>>> On Tue, Jan 26, 2016 at 10:25:38PM +0530, Siddhesh Poyarekar wrote:
>>>> Adding Adhemerval to cc since he had volunteered to follow up on this,
>>>> mainly because he had a couple of additional ideas on the kernel
>>>> front.
>>>>
>>>> On Tue, Jan 26, 2016 at 04:21:43PM +0000, Suzuki K. Poulose wrote:
>>>>> On 26/01/16 16:02, Will Deacon wrote:
>>>>>> Hi Suzuki,
>>>>>>
>>>>>> On Tue, Jan 26, 2016 at 03:52:46PM +0000, Suzuki K Poulose wrote:
>>>>>>> ARMv8.2 extensions [1] include an optional feature, which supports
>>>>>>> half precision(16bit) floating point/asimd data processing
>>>>>>> instructions. This patch adds support for detecting and exposing
>>>>>>> the same to the userspace via HWCAPs
>>>>>
>>>>>
>>>>>>> +#define HWCAP_FPHP		(1 << 9)
>>>>>>> +#define HWCAP_ASIMDHP		(1 << 10)
>>>>>>
>>>>>> Where did we get to with the mrs trapping you proposed here?
>>>>>>
>>>>>>   http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374609.html
>>>>>
>>>>> We are yet to get some feedback from glibc/gcc folks. Siddhesh was looking
>>>>> to make use of it [2]. But haven't heard anything back. Ramana mentioned
>>>>> (in private) that they had some plans to take a look at it.
>>>>
>>>> I believe one of Adhemerval's ideas was similar to what I had
>>>> mentioned back then, which was to provide all of the CPU information
>>>> in a single file instead of having to traverse a directory structure.
>>>
>>> My understanding was that libc needed this information extremely early
>>> on (i.e. before it could even issue system calls), and therefore such
>>> an approach would be in addition to the proposal here. Am I mistaken?
>>
>> If the idea is to use these instruction for function implementation selection
>> (iFUNC) the idea is to have on PLT resolution either by accessing it directly
>> or using a caching mechanism. x86_64 does something similar with cacheline
>> information: it issues a single cpuid and create processor information table
>> based on its information (it is also what the __builtin_supports() also
>> does).
>>
> 
> __builtin_supports is not a single cpuid on x86, it is
> a cpuid per dso with one cache per dso.
> 
> (gcc-5 used a single cache in libgcc_s.so.1 and that
> turned out to be broken because ifunc in other dsos
> could not reliably access it.)

It is with static libgcc (default), but if you use -shared-gcc only one
__cpu_model (used by __builtin_cpu_supports) will be linked.  But since
static libgcc is default it will be indeed one per DSO.

> 
>>>> The other idea was to add a vDSO function that returns this data so as
>>>> to avoid (or at least reduce) the context switch latency.
>>>
>>> I'm not at all keen on adding a data ABI to the vDSO. I think people tried
>>> similar things in the past (something on PPC?) and have horror stories
>>> from that.
>>
>> In fact ppc still exports it in vDSO (include/asm/vdso_datapage.h), with
>> information like the LPAR cfg, platform, processor, {d,i}cache, etc.
>> I recall that I have see some code back at IBM that tried to use these
>> fields directly, but indeed it is not recommended.
>>
>> What I have in mind is something what ppc does with __kernel_get_syscall_map.
>> It is vDSO function that returns a vDSO internal data related to which
>> syscalls are implemented in the running kernel (through a bitmap field).
>>
> 
> fs access or vdso does not work for ifunc based dispatch
> (assuming the current ifunc implementation in glibc).
> 
> (for vdso you need the AT_SYSINFO_EHDR auxval somehow and
> then implement elf symbol lookup in the ifunc resolver
> without calling any libc function. passing auxvals to the
> ifunc resolver can be done by changing the ifunc abi, but
> doing symbol lookups there is unrealistic.)
> 
> in the libc (e.g. for memcpy) ifunc is a bit easier to use,
> but in user code (function-multi-versioning) ifunc is very
> limited.
> 
> i wrote about the ifunc limitations here:
> https://sourceware.org/ml/libc-alpha/2015-11/msg00108.html
> see point (4) and (5).
> 

I recall this thread and indeed iFUNC have a set of limitations.  Although for
use within libc itself it might be safe with the constraints you have described.

Now for vDSO usage I think it might be safe to use within GLIBC
with correct vDSO pointers initialization order. At least it is done
on GLIBC for gettimeofday for x86_64 and powerpc (the iFUNC returns
the vDSO function pointer).


From moinejf at free.fr  Tue Feb  2 10:13:52 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Tue, 2 Feb 2016 19:13:52 +0100
Subject: [PATCH v3 1/2] clk: sunxi: Add sun6i/8i video support
In-Reply-To: <CACvgo53f8Sr_dEAx_mcvjXciK01mY7TUDguOJ-HzNur-PpmMZw@mail.gmail.com>
References: <cover.1454427223.git.moinejf@free.fr>
 <8fdfe5fe7715f19416d654964e55721b30237b38.1454427224.git.moinejf@free.fr>
 <CACvgo53f8Sr_dEAx_mcvjXciK01mY7TUDguOJ-HzNur-PpmMZw@mail.gmail.com>
Message-ID: <20160202191352.2b21ae1c5de288e008841b1f@free.fr>

On Tue, 2 Feb 2016 17:19:15 +0000
Emil Velikov <emil.l.velikov at gmail.com> wrote:

> > ---
> >  Documentation/devicetree/bindings/clock/sunxi.txt |   2 +
> >  drivers/clk/sunxi/clk-sun6i-display.c             | 106 +++++++++++++
> >  drivers/clk/sunxi/clk-sun6i-pll3.c                | 174 ++++++++++++++++++++++
> >  3 files changed, 282 insertions(+)
> >  create mode 100644 drivers/clk/sunxi/clk-sun6i-display.c
> >  create mode 100644 drivers/clk/sunxi/clk-sun6i-pll3.c
> >
> Something is missing here - namely the changes to the Makefile. Does
> this series work or did you simply forget git add ?

Yes, the series works. I just forgot the Makefile which contains other
changes for my kernel (thermal clock).

Thanks. I sent an new request.

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/



From moritz.fischer at ettus.com  Tue Feb  2 10:16:33 2016
From: moritz.fischer at ettus.com (Moritz Fischer)
Date: Tue, 2 Feb 2016 10:16:33 -0800
Subject: [PATCH v3 2/4] power: reset: add reboot mode driver
In-Reply-To: <1454407325-4804-1-git-send-email-andy.yan@rock-chips.com>
References: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
 <1454407325-4804-1-git-send-email-andy.yan@rock-chips.com>
Message-ID: <CAAtXAHeg3hmKy1YAfGaNaPnXYxJAkA4zV2J4ELyPStQUeBrZ3w@mail.gmail.com>

Hi Andy,

looks good to me. Feel free to add my Reviewed-by

On Tue, Feb 2, 2016 at 2:02 AM, Andy Yan <andy.yan at rock-chips.com> wrote:

> This is commonly used on Android based devices, in order to
> reboot the device into fastboot or recovery mode.
>
Reviewed-by: Moritz Fischer <moritz.fischer at ettus.com>
> Reviewed-by: Matthias Brugger <matthias.bgg at gmail.com>
> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>

Cheers,

Moritz


From gnomes at lxorguk.ukuu.org.uk  Tue Feb  2 10:19:35 2016
From: gnomes at lxorguk.ukuu.org.uk (One Thousand Gnomes)
Date: Tue, 2 Feb 2016 18:19:35 +0000
Subject: [PATCH 01/10] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160202181935.19b4ab7e@lxorguk.ukuu.org.uk>


> +static void mvebu_uart_set_termios(struct uart_port *port,
> +				   struct ktermios *termios,
> +				   struct ktermios *old)
> +{
> +	unsigned long flags;
> +	unsigned int baud;
> +
> +	spin_lock_irqsave(&port->lock, flags);
> +
> +	port->read_status_mask = STAT_RX_RDY | STAT_OVR_ERR |
> +		STAT_TX_RDY | STAT_TX_FIFO_FUL;
> +
> +	if (termios->c_iflag & INPCK)
> +		port->read_status_mask |= STAT_FRM_ERR | STAT_PAR_ERR;
> +
> +	port->ignore_status_mask = 0;
> +	if (termios->c_iflag & IGNPAR)
> +		port->ignore_status_mask |=
> +			STAT_FRM_ERR | STAT_PAR_ERR | STAT_OVR_ERR;
> +
> +	if ((termios->c_cflag & CREAD) == 0)
> +		port->ignore_status_mask |= STAT_RX_RDY | STAT_BRK_ERR;

If you don't support parity or charactive size then you should be forcing
those bits in the tty->termios so that the caller sees what settings they
get. tty_termios_copy_hw is close to what you need except that you can
support IGNPAR.

You also want to provide the actual baud rate chosen (see how 8250.c does
it using tty_termios_encode_baud_rate().


> +static struct uart_driver mvebu_uart_driver = {
> +	.owner			= THIS_MODULE,
> +	.driver_name		= "serial",
> +	.dev_name		= "ttyS",
> +	.major			= TTY_MAJOR,
> +	.minor			= 64,

NAK

TTY_MAJOR 64+ is the 8250 driver and ttyS is the 8250 driver name. You
should be using a dynamic major (0) for all new drivers and you need to
pick a different and unused ttyXXX format name.

Alan


From mark.rutland at arm.com  Tue Feb  2 10:19:29 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 2 Feb 2016 18:19:29 +0000
Subject: [PATCH 01/10] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160202181929.GB29778@leverpostej>

On Tue, Feb 02, 2016 at 07:07:39PM +0100, Gregory CLEMENT wrote:
> From: Wilson Ding <dingwei at marvell.com>
> 
> Armada-3700's uart is a simple serial port, which doesn't
> support. Configuring the modem control lines. The uart port has a 32
> bytes Tx FIFO and a 64 bytes Rx FIFO
> 
> The uart driver implements the uart core operations. It also support the
> system (early) console based on Armada-3700's serial port.
>
> Known Issue:
> 
> The uart driver currently doesn't support clock programming, which means
> the baud-rate stays with the default value configured by the bootloader
> at boot time

This looks like any other early console.

Why does this not use the earlycon infrastructure?

See {OF_,}EARLYCON_DECLARE (e.g. in drivers/tty/serial/amba-pl011.c).

Mark.

> [gregory.clement at free-electrons.com: Rewrite many part which are too long
> to enumerate]
> 
> Signed-off-by: Wilson Ding <dingwei at marvell.com>
> Signed-off-by: Nadav Haklai <nadavh at marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  .../devicetree/bindings/tty/serial/mvebu-uart.txt  |  13 +
>  Documentation/kernel-parameters.txt                |   6 +
>  drivers/tty/serial/Kconfig                         |  22 +
>  drivers/tty/serial/Makefile                        |   1 +
>  drivers/tty/serial/mvebu-uart.c                    | 649 +++++++++++++++++++++
>  include/uapi/linux/serial_core.h                   |   3 +
>  6 files changed, 694 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
>  create mode 100644 drivers/tty/serial/mvebu-uart.c
> 
> diff --git a/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
> new file mode 100644
> index 000000000000..6087defd9f93
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
> @@ -0,0 +1,13 @@
> +* Marvell UART : Non standard UART used in some of Marvell EBU SoCs (e.g., Armada-3700)
> +
> +Required properties:
> +- compatible: "marvell,armada-3700-uart"
> +- reg: offset and length of the register set for the device.
> +- interrupts: device interrupt
> +
> +Example:
> +	serial at 12000 {
> +		compatible = "marvell,armada-3700-uart";
> +		reg = <0x12000 0x400>;
> +		interrupts = <43>;
> +	};
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 87d40a72f6a1..198f6bd56e84 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1058,6 +1058,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>  			A valid base address must be provided, and the serial
>  			port must already be setup and configured.
>  
> +		mvebu_uart,<addr>
> +			Start an early, polled-mode console on an some mvebu
> +			SoC (as the Armada-3700) serial port at the specified
> +			address. The serial port must already be setup and
> +			configured. Options are not yet supported.
> +
>  	earlyprintk=	[X86,SH,BLACKFIN,ARM,M68k]
>  			earlyprintk=vga
>  			earlyprintk=efi
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 39721ec4f415..b291f934d51b 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1606,6 +1606,28 @@ config SERIAL_STM32_CONSOLE
>  	depends on SERIAL_STM32=y
>  	select SERIAL_CORE_CONSOLE
>  
> +config SERIAL_MVEBU_UART
> +	bool "Marvell EBU serial port support"
> +	select SERIAL_CORE
> +	help
> +	  This driver is for Marvell EBU SoC's UART. If you have a machine
> +	  based on the Armada-3700 SoC and wish to use the on-board serial
> +	  port,
> +	  say 'Y' here.
> +	  Otherwise, say 'N'.
> +
> +config SERIAL_MVEBU_CONSOLE
> +	bool "Console on Marvell EBU serial port"
> +	depends on SERIAL_MVEBU_UART
> +	select SERIAL_CORE_CONSOLE
> +	select SERIAL_EARLYCON
> +	default y
> +	help
> +	  Say 'Y' here if you wish to use Armada-3700 UART as the system console.
> +	  (the system console is the device which receives all kernel messages
> +	  and warnings and which allows logins in single user mode)
> +	  Otherwise, say 'N'.
> +
>  endmenu
>  
>  config SERIAL_MCTRL_GPIO
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index b391c9b31960..988167595330 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -91,6 +91,7 @@ obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
>  obj-$(CONFIG_SERIAL_MEN_Z135)	+= men_z135_uart.o
>  obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
>  obj-$(CONFIG_SERIAL_STM32)	+= stm32-usart.o
> +obj-$(CONFIG_SERIAL_MVEBU_UART)	+= mvebu-uart.o
>  
>  # GPIOLIB helpers for modem control lines
>  obj-$(CONFIG_SERIAL_MCTRL_GPIO)	+= serial_mctrl_gpio.o
> diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
> new file mode 100644
> index 000000000000..9624070d6058
> --- /dev/null
> +++ b/drivers/tty/serial/mvebu-uart.c
> @@ -0,0 +1,649 @@
> +/*
> +* ***************************************************************************
> +* Copyright (C) 2015 Marvell International Ltd.
> +* ***************************************************************************
> +* This program is free software: you can redistribute it and/or modify it
> +* under the terms of the GNU General Public License as published by the Free
> +* Software Foundation, either version 2 of the License, or any later version.
> +*
> +* This program is distributed in the hope that it will be useful,
> +* but WITHOUT ANY WARRANTY; without even the implied warranty of
> +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +* GNU General Public License for more details.
> +*
> +* 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/clk.h>
> +#include <linux/console.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/serial.h>
> +#include <linux/serial_core.h>
> +#include <linux/slab.h>
> +#include <linux/tty.h>
> +#include <linux/tty_flip.h>
> +
> +/* Register Map */
> +#define UART_RBR		0x00
> +#define  RBR_BRK_DET		BIT(15)
> +#define  RBR_FRM_ERR_DET	BIT(14)
> +#define  RBR_PAR_ERR_DET	BIT(13)
> +#define  RBR_OVR_ERR_DET	BIT(12)
> +
> +#define UART_TSH		0x04
> +
> +#define UART_CTRL		0x08
> +#define  CTRL_SOFT_RST		BIT(31)
> +#define  CTRL_TXFIFO_RST	BIT(15)
> +#define  CTRL_RXFIFO_RST	BIT(14)
> +#define  CTRL_ST_MIRR_EN	BIT(13)
> +#define  CTRL_LPBK_EN		BIT(12)
> +#define  CTRL_SND_BRK_SEQ	BIT(11)
> +#define  CTRL_PAR_EN		BIT(10)
> +#define  CTRL_TWO_STOP		BIT(9)
> +#define  CTRL_TX_HFL_INT	BIT(8)
> +#define  CTRL_RX_HFL_INT	BIT(7)
> +#define  CTRL_TX_EMP_INT	BIT(6)
> +#define  CTRL_TX_RDY_INT	BIT(5)
> +#define  CTRL_RX_RDY_INT	BIT(4)
> +#define  CTRL_BRK_DET_INT	BIT(3)
> +#define  CTRL_FRM_ERR_INT	BIT(2)
> +#define  CTRL_PAR_ERR_INT	BIT(1)
> +#define  CTRL_OVR_ERR_INT	BIT(0)
> +#define  CTRL_RX_INT			(CTRL_RX_RDY_INT | CTRL_BRK_DET_INT |\
> +	CTRL_FRM_ERR_INT | CTRL_PAR_ERR_INT | CTRL_OVR_ERR_INT)
> +
> +#define UART_STAT		0x0c
> +#define  STAT_TX_FIFO_EMP	BIT(13)
> +#define  STAT_RX_FIFO_EMP	BIT(12)
> +#define  STAT_TX_FIFO_FUL	BIT(11)
> +#define  STAT_TX_FIFO_HFL	BIT(10)
> +#define  STAT_RX_TOGL		BIT(9)
> +#define  STAT_RX_FIFO_FUL	BIT(8)
> +#define  STAT_RX_FIFO_HFL	BIT(7)
> +#define  STAT_TX_EMP		BIT(6)
> +#define  STAT_TX_RDY		BIT(5)
> +#define  STAT_RX_RDY		BIT(4)
> +#define  STAT_BRK_DET		BIT(3)
> +#define  STAT_FRM_ERR		BIT(2)
> +#define  STAT_PAR_ERR		BIT(1)
> +#define  STAT_OVR_ERR		BIT(0)
> +#define  STAT_BRK_ERR		(STAT_BRK_DET | STAT_FRM_ERR | STAT_FRM_ERR\
> +				 | STAT_PAR_ERR | STAT_OVR_ERR)
> +
> +#define UART_BRDV		0x10
> +
> +#define MVEBU_NR_UARTS		1
> +
> +#define MVEBU_UART_TYPE		"mvebu-uart"
> +
> +static struct uart_port mvebu_uart_ports[MVEBU_NR_UARTS];
> +
> +struct mvebu_uart_data {
> +	struct uart_port *port;
> +	struct clk       *clk;
> +};
> +
> +/* Core UART Driver Operations */
> +static unsigned int mvebu_uart_tx_empty(struct uart_port *port)
> +{
> +	unsigned long flags;
> +	unsigned int st;
> +
> +	spin_lock_irqsave(&port->lock, flags);
> +	st = readl(port->membase + UART_STAT);
> +	spin_unlock_irqrestore(&port->lock, flags);
> +
> +	return (st & STAT_TX_FIFO_EMP) ? TIOCSER_TEMT : 0;
> +}
> +
> +static unsigned int mvebu_uart_get_mctrl(struct uart_port *port)
> +{
> +	return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
> +}
> +
> +static void mvebu_uart_set_mctrl(struct uart_port *port,
> +				 unsigned int mctrl)
> +{
> +/*
> + * Even if we do not support configuring the modem control lines, this
> + * function must be proided to the serial core
> + */
> +}
> +
> +static void mvebu_uart_stop_tx(struct uart_port *port)
> +{
> +	unsigned int ctl = readl(port->membase + UART_CTRL);
> +
> +	ctl &= ~CTRL_TX_RDY_INT;
> +	writel(ctl, port->membase + UART_CTRL);
> +}
> +
> +static void mvebu_uart_start_tx(struct uart_port *port)
> +{
> +	unsigned int ctl = readl(port->membase + UART_CTRL);
> +
> +	ctl |= CTRL_TX_RDY_INT;
> +	writel(ctl, port->membase + UART_CTRL);
> +}
> +
> +static void mvebu_uart_stop_rx(struct uart_port *port)
> +{
> +	unsigned int ctl = readl(port->membase + UART_CTRL);
> +
> +	ctl &= ~CTRL_RX_INT;
> +	writel(ctl, port->membase + UART_CTRL);
> +}
> +
> +static void mvebu_uart_break_ctl(struct uart_port *port, int brk)
> +{
> +	unsigned int ctl;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&port->lock, flags);
> +	ctl = readl(port->membase + UART_CTRL);
> +	if (brk == -1)
> +		ctl |= CTRL_SND_BRK_SEQ;
> +	else
> +		ctl &= ~CTRL_SND_BRK_SEQ;
> +	writel(ctl, port->membase + UART_CTRL);
> +	spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +static void mvebu_uart_rx_chars(struct uart_port *port, unsigned int status)
> +{
> +	struct tty_port *tport = &port->state->port;
> +	unsigned char ch = 0;
> +	char flag = 0;
> +
> +	do {
> +		if (status & STAT_RX_RDY) {
> +			ch = readl(port->membase + UART_RBR);
> +			ch &= 0xff;
> +			flag = TTY_NORMAL;
> +			port->icount.rx++;
> +
> +			if (status & STAT_PAR_ERR)
> +				port->icount.parity++;
> +		}
> +
> +		if (status & STAT_BRK_DET) {
> +			port->icount.brk++;
> +			status &= ~(STAT_FRM_ERR | STAT_PAR_ERR);
> +			if (uart_handle_break(port))
> +				goto ignore_char;
> +		}
> +
> +		if (status & STAT_OVR_ERR)
> +			port->icount.overrun++;
> +
> +		if (status & STAT_FRM_ERR)
> +			port->icount.frame++;
> +
> +		if (uart_handle_sysrq_char(port, ch))
> +			goto ignore_char;
> +
> +		if (status & port->ignore_status_mask & STAT_PAR_ERR)
> +			status &= ~STAT_RX_RDY;
> +
> +		status &= port->read_status_mask;
> +
> +		if (status & STAT_PAR_ERR)
> +			flag = TTY_PARITY;
> +
> +		status &= ~port->ignore_status_mask;
> +
> +		if (status & STAT_RX_RDY)
> +			tty_insert_flip_char(tport, ch, flag);
> +
> +		if (status & STAT_BRK_DET)
> +			tty_insert_flip_char(tport, 0, TTY_BREAK);
> +
> +		if (status & STAT_FRM_ERR)
> +			tty_insert_flip_char(tport, 0, TTY_FRAME);
> +
> +		if (status & STAT_OVR_ERR)
> +			tty_insert_flip_char(tport, 0, TTY_OVERRUN);
> +
> +ignore_char:
> +		status = readl(port->membase + UART_STAT);
> +	} while (status & (STAT_RX_RDY | STAT_BRK_DET));
> +
> +	tty_flip_buffer_push(tport);
> +}
> +
> +static void mvebu_uart_tx_chars(struct uart_port *port, unsigned int status)
> +{
> +	struct circ_buf *xmit = &port->state->xmit;
> +	unsigned int count;
> +	unsigned int st;
> +
> +	if (port->x_char) {
> +		writel(port->x_char, port->membase + UART_TSH);
> +		port->icount.tx++;
> +		port->x_char = 0;
> +		return;
> +	}
> +
> +	if (uart_circ_empty(xmit) || uart_tx_stopped(port)) {
> +		mvebu_uart_stop_tx(port);
> +		return;
> +	}
> +
> +	for (count = 0; count < port->fifosize; count++) {
> +		writel(xmit->buf[xmit->tail], port->membase + UART_TSH);
> +		xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
> +		port->icount.tx++;
> +
> +		if (uart_circ_empty(xmit))
> +			break;
> +
> +		st = readl(port->membase + UART_STAT);
> +		if (st & STAT_TX_FIFO_FUL)
> +			break;
> +	}
> +
> +	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
> +		uart_write_wakeup(port);
> +
> +	if (uart_circ_empty(xmit))
> +		mvebu_uart_stop_tx(port);
> +}
> +
> +static irqreturn_t mvebu_uart_isr(int irq, void *dev_id)
> +{
> +	struct uart_port *port = (struct uart_port *)dev_id;
> +	unsigned int st = readl(port->membase + UART_STAT);
> +
> +	if (st & (STAT_RX_RDY | STAT_OVR_ERR | STAT_FRM_ERR | STAT_BRK_DET))
> +		mvebu_uart_rx_chars(port, st);
> +
> +	if (st & STAT_TX_RDY)
> +		mvebu_uart_tx_chars(port, st);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int mvebu_uart_startup(struct uart_port *port)
> +{
> +	int ret;
> +
> +	writel(CTRL_TXFIFO_RST | CTRL_RXFIFO_RST,
> +	       port->membase + UART_CTRL);
> +	udelay(1);
> +	writel(CTRL_RX_INT, port->membase + UART_CTRL);
> +
> +	ret = request_irq(port->irq, mvebu_uart_isr, port->irqflags, "serial",
> +			  port);
> +	if (ret) {
> +		dev_err(port->dev, "failed to request irq\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static void mvebu_uart_shutdown(struct uart_port *port)
> +{
> +	writel(0, port->membase + UART_CTRL);
> +}
> +
> +static void mvebu_uart_set_termios(struct uart_port *port,
> +				   struct ktermios *termios,
> +				   struct ktermios *old)
> +{
> +	unsigned long flags;
> +	unsigned int baud;
> +
> +	spin_lock_irqsave(&port->lock, flags);
> +
> +	port->read_status_mask = STAT_RX_RDY | STAT_OVR_ERR |
> +		STAT_TX_RDY | STAT_TX_FIFO_FUL;
> +
> +	if (termios->c_iflag & INPCK)
> +		port->read_status_mask |= STAT_FRM_ERR | STAT_PAR_ERR;
> +
> +	port->ignore_status_mask = 0;
> +	if (termios->c_iflag & IGNPAR)
> +		port->ignore_status_mask |=
> +			STAT_FRM_ERR | STAT_PAR_ERR | STAT_OVR_ERR;
> +
> +	if ((termios->c_cflag & CREAD) == 0)
> +		port->ignore_status_mask |= STAT_RX_RDY | STAT_BRK_ERR;
> +
> +	baud = uart_get_baud_rate(port, termios, old, 0, 460800);
> +	uart_update_timeout(port, termios->c_cflag, baud);
> +
> +	spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +static const char *mvebu_uart_type(struct uart_port *port)
> +{
> +	return MVEBU_UART_TYPE;
> +}
> +
> +static void mvebu_uart_release_port(struct uart_port *port)
> +{
> +	/* Nothing to do here */
> +}
> +
> +static int mvebu_uart_request_port(struct uart_port *port)
> +{
> +	return 0;
> +}
> +
> +#ifdef CONFIG_CONSOLE_POLL
> +static int mvebu_uart_get_poll_char(struct uart_port *port)
> +{
> +	unsigned int st = readl(port->membase + UART_STAT);
> +
> +	if (!(st & STAT_RX_RDY))
> +		return NO_POLL_CHAR;
> +
> +	return readl(port->membase + UART_RBR);
> +}
> +
> +static void mvebu_uart_put_poll_char(struct uart_port *port, unsigned char c)
> +{
> +	unsigned int st;
> +
> +	for (;;) {
> +		st = readl(port->membase + UART_STAT);
> +
> +		if (!(st & STAT_TX_FIFO_FUL))
> +			break;
> +
> +		udelay(1);
> +	}
> +
> +	writel(c, port->membase + UART_TSH);
> +}
> +#endif
> +
> +static const struct uart_ops mvebu_uart_ops = {
> +	.tx_empty	= mvebu_uart_tx_empty,
> +	.set_mctrl	= mvebu_uart_set_mctrl,
> +	.get_mctrl	= mvebu_uart_get_mctrl,
> +	.stop_tx	= mvebu_uart_stop_tx,
> +	.start_tx	= mvebu_uart_start_tx,
> +	.stop_rx	= mvebu_uart_stop_rx,
> +	.break_ctl	= mvebu_uart_break_ctl,
> +	.startup	= mvebu_uart_startup,
> +	.shutdown	= mvebu_uart_shutdown,
> +	.set_termios	= mvebu_uart_set_termios,
> +	.type		= mvebu_uart_type,
> +	.release_port	= mvebu_uart_release_port,
> +	.request_port	= mvebu_uart_request_port,
> +#ifdef CONFIG_CONSOLE_POLL
> +	.poll_get_char	= mvebu_uart_get_poll_char,
> +	.poll_put_char	= mvebu_uart_put_poll_char,
> +#endif
> +};
> +
> +/* Console Driver Operations  */
> +
> +#ifdef CONFIG_SERIAL_MVEBU_CONSOLE
> +/* Early Console */
> +static void mvebu_uart_putc(struct uart_port *port, int c)
> +{
> +	unsigned int st;
> +
> +	for (;;) {
> +		st = readl(port->membase + UART_STAT);
> +		if (!(st & STAT_TX_FIFO_FUL))
> +			break;
> +	}
> +
> +	writel(c, port->membase + UART_TSH);
> +
> +	for (;;) {
> +		st = readl(port->membase + UART_STAT);
> +		if (st & STAT_TX_FIFO_EMP)
> +			break;
> +	}
> +}
> +
> +static void mvebu_uart_putc_early_write(struct console *con,
> +					const char *s,
> +					unsigned n)
> +{
> +	struct earlycon_device *dev = con->data;
> +
> +	uart_console_write(&dev->port, s, n, mvebu_uart_putc);
> +}
> +
> +static int __init
> +mvebu_uart_early_console_setup(struct earlycon_device *device,
> +			       const char *opt)
> +{
> +	if (!device->port.membase)
> +		return -ENODEV;
> +
> +	device->con->write = mvebu_uart_putc_early_write;
> +
> +	return 0;
> +}
> +
> +EARLYCON_DECLARE(ar3700_uart, mvebu_uart_early_console_setup);
> +OF_EARLYCON_DECLARE(ar3700_uart, "marvell,armada-3700-uart",
> +		    mvebu_uart_early_console_setup);
> +
> +static void wait_for_xmitr(struct uart_port *port)
> +{
> +	u32 val;
> +
> +	readl_poll_timeout_atomic(port->membase + UART_STAT, val,
> +				  (val & STAT_TX_EMP), 1, 10000);
> +}
> +
> +static void mvebu_uart_console_putchar(struct uart_port *port, int ch)
> +{
> +	wait_for_xmitr(port);
> +	writel(ch, port->membase + UART_TSH);
> +}
> +
> +static void mvebu_uart_console_write(struct console *co, const char *s,
> +				     unsigned int count)
> +{
> +	struct uart_port *port = &mvebu_uart_ports[co->index];
> +	unsigned long flags;
> +	unsigned int ier;
> +	int locked = 1;
> +
> +	if (oops_in_progress)
> +		locked = spin_trylock_irqsave(&port->lock, flags);
> +	else
> +		spin_lock_irqsave(&port->lock, flags);
> +
> +	ier = readl(port->membase + UART_CTRL) &
> +		(CTRL_RX_INT | CTRL_TX_RDY_INT);
> +	writel(0, port->membase + UART_CTRL);
> +
> +	uart_console_write(port, s, count, mvebu_uart_console_putchar);
> +
> +	wait_for_xmitr(port);
> +
> +	if (ier)
> +		writel(ier, port->membase + UART_CTRL);
> +
> +	if (locked)
> +		spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +static int mvebu_uart_console_setup(struct console *co, char *options)
> +{
> +	struct uart_port *port;
> +	int baud = 9600;
> +	int bits = 8;
> +	int parity = 'n';
> +	int flow = 'n';
> +
> +	if (co->index < 0 || co->index >= MVEBU_NR_UARTS)
> +		return -EINVAL;
> +
> +	port = &mvebu_uart_ports[co->index];
> +
> +	if (!port->mapbase || !port->membase) {
> +		pr_debug("console on ttyS%i not present\n", co->index);
> +		return -ENODEV;
> +	}
> +
> +	if (options)
> +		uart_parse_options(options, &baud, &parity, &bits, &flow);
> +
> +	return uart_set_options(port, co, baud, parity, bits, flow);
> +}
> +
> +static struct uart_driver mvebu_uart_driver;
> +
> +static struct console mvebu_uart_console = {
> +	.name	= "ttyS",
> +	.write	= mvebu_uart_console_write,
> +	.device	= uart_console_device,
> +	.setup	= mvebu_uart_console_setup,
> +	.flags	= CON_PRINTBUFFER,
> +	.index	= -1,
> +	.data	= &mvebu_uart_driver,
> +};
> +
> +static int __init mvebu_uart_console_init(void)
> +{
> +	register_console(&mvebu_uart_console);
> +	return 0;
> +}
> +
> +console_initcall(mvebu_uart_console_init);
> +
> +
> +#endif /* CONFIG_SERIAL_MVEBU_CONSOLE */
> +
> +static struct uart_driver mvebu_uart_driver = {
> +	.owner			= THIS_MODULE,
> +	.driver_name		= "serial",
> +	.dev_name		= "ttyS",
> +	.major			= TTY_MAJOR,
> +	.minor			= 64,
> +	.nr			= MVEBU_NR_UARTS,
> +#ifdef CONFIG_SERIAL_MVEBU_CONSOLE
> +	.cons			= &mvebu_uart_console,
> +#endif
> +};
> +
> +static int mvebu_uart_probe(struct platform_device *pdev)
> +{
> +	struct resource *reg = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	struct resource *irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> +	struct uart_port *port;
> +	struct mvebu_uart_data *data;
> +	int ret;
> +
> +	if (!reg || !irq) {
> +		dev_err(&pdev->dev, "no registers/irq defined\n");
> +		return -EINVAL;
> +	}
> +
> +	port = &mvebu_uart_ports[0];
> +
> +	spin_lock_init(&port->lock);
> +
> +	port->dev        = &pdev->dev;
> +	port->type       = PORT_MVEBU;
> +	port->ops        = &mvebu_uart_ops;
> +	port->regshift   = 0;
> +
> +	port->fifosize   = 32;
> +	port->iotype     = UPIO_MEM32;
> +	port->flags      = UPF_FIXED_PORT;
> +	port->line       = 0; /* single port: force line number to  0 */
> +
> +	port->irq        = irq->start;
> +	port->irqflags   = 0;
> +	port->mapbase    = reg->start;
> +
> +	port->membase = devm_ioremap_resource(&pdev->dev, reg);
> +	if (IS_ERR(port->membase))
> +		return -PTR_ERR(port->membase);
> +
> +	data = devm_kzalloc(&pdev->dev, sizeof(struct mvebu_uart_data),
> +			    GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	data->port = port;
> +
> +	port->private_data = data;
> +	platform_set_drvdata(pdev, data);
> +
> +	ret = uart_add_one_port(&mvebu_uart_driver, port);
> +	if (ret)
> +		return ret;
> +	return 0;
> +}
> +
> +static int mvebu_uart_remove(struct platform_device *pdev)
> +{
> +	struct mvebu_uart_data *data = platform_get_drvdata(pdev);
> +
> +	uart_remove_one_port(&mvebu_uart_driver, data->port);
> +	data->port->private_data = NULL;
> +	data->port->mapbase      = 0;
> +	return 0;
> +}
> +
> +/* Match table for of_platform binding */
> +static const struct of_device_id mvebu_uart_of_match[] = {
> +	{ .compatible = "marvell,armada-3700-uart", },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, mvebu_uart_of_match);
> +
> +static struct platform_driver mvebu_uart_platform_driver = {
> +	.probe	= mvebu_uart_probe,
> +	.remove	= mvebu_uart_remove,
> +	.driver	= {
> +		.owner	= THIS_MODULE,
> +		.name  = "mvebu-uart",
> +		.of_match_table = of_match_ptr(mvebu_uart_of_match),
> +	},
> +};
> +
> +static int __init mvebu_uart_init(void)
> +{
> +	int ret;
> +
> +	ret = uart_register_driver(&mvebu_uart_driver);
> +	if (ret)
> +		return ret;
> +
> +	ret = platform_driver_register(&mvebu_uart_platform_driver);
> +	if (ret)
> +		uart_unregister_driver(&mvebu_uart_driver);
> +
> +	return ret;
> +}
> +
> +static void __exit mvebu_uart_exit(void)
> +{
> +	platform_driver_unregister(&mvebu_uart_platform_driver);
> +	uart_unregister_driver(&mvebu_uart_driver);
> +}
> +
> +arch_initcall(mvebu_uart_init);
> +module_exit(mvebu_uart_exit);
> +
> +MODULE_AUTHOR("Wilson Ding <dingwei at marvell.com>");
> +MODULE_DESCRIPTION("Marvell Armada-3700 Serial Driver");
> +MODULE_LICENSE("GPL");
> diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
> index 3e5d757407fb..e513a4ee369b 100644
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -261,4 +261,7 @@
>  /* STM32 USART */
>  #define PORT_STM32	113
>  
> +/* MVEBU UART */
> +#define PORT_MVEBU	114
> +
>  #endif /* _UAPILINUX_SERIAL_CORE_H */
> -- 
> 2.5.0
> 


From mark.rutland at arm.com  Tue Feb  2 10:21:10 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 2 Feb 2016 18:21:10 +0000
Subject: [PATCH 01/10] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <20160202181929.GB29778@leverpostej>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
 <20160202181929.GB29778@leverpostej>
Message-ID: <20160202182109.GC29778@leverpostej>

On Tue, Feb 02, 2016 at 06:19:29PM +0000, Mark Rutland wrote:
> On Tue, Feb 02, 2016 at 07:07:39PM +0100, Gregory CLEMENT wrote:
> > From: Wilson Ding <dingwei at marvell.com>
> > 
> > Armada-3700's uart is a simple serial port, which doesn't
> > support. Configuring the modem control lines. The uart port has a 32
> > bytes Tx FIFO and a 64 bytes Rx FIFO
> > 
> > The uart driver implements the uart core operations. It also support the
> > system (early) console based on Armada-3700's serial port.
> >
> > Known Issue:
> > 
> > The uart driver currently doesn't support clock programming, which means
> > the baud-rate stays with the default value configured by the bootloader
> > at boot time
> 
> This looks like any other early console.
> 
> Why does this not use the earlycon infrastructure?

Ah, it does, and I misread the diff quite badly.

Apologies for the noise.

Mark.


From szabolcs.nagy at arm.com  Tue Feb  2 10:25:00 2016
From: szabolcs.nagy at arm.com (Szabolcs Nagy)
Date: Tue, 2 Feb 2016 18:25:00 +0000
Subject: [PATCH] arm64: Add support for Half precision floating point
In-Reply-To: <56B0F19C.5090007@linaro.org>
References: <1453823566-26742-1-git-send-email-suzuki.poulose@arm.com>
 <20160126160257.GB28238@arm.com> <56A79D17.2000009@arm.com>
 <20160126165538.GC22776@devel.intra.reserved-bit.com>
 <20160128160747.GN775@arm.com> <56AA470E.1020606@linaro.org>
 <56B0E7EA.9050601@arm.com> <56B0F19C.5090007@linaro.org>
Message-ID: <56B0F47C.7060004@arm.com>

On 02/02/16 18:12, Adhemerval Zanella wrote:
> On 02-02-2016 15:31, Szabolcs Nagy wrote:
>> On 28/01/16 16:51, Adhemerval Zanella wrote:
>>> On 28-01-2016 14:07, Will Deacon wrote:
>>>> On Tue, Jan 26, 2016 at 10:25:38PM +0530, Siddhesh Poyarekar wrote:
>>>>> Adding Adhemerval to cc since he had volunteered to follow up on this,
>>>>> mainly because he had a couple of additional ideas on the kernel
>>>>> front.
>>>>>
>>>>> On Tue, Jan 26, 2016 at 04:21:43PM +0000, Suzuki K. Poulose wrote:
>>>>>> On 26/01/16 16:02, Will Deacon wrote:
>>>>>>> Hi Suzuki,
>>>>>>>
>>>>>>> On Tue, Jan 26, 2016 at 03:52:46PM +0000, Suzuki K Poulose wrote:
>>>>>>>> ARMv8.2 extensions [1] include an optional feature, which supports
>>>>>>>> half precision(16bit) floating point/asimd data processing
>>>>>>>> instructions. This patch adds support for detecting and exposing
>>>>>>>> the same to the userspace via HWCAPs
>>>>>>
>>>>>>
>>>>>>>> +#define HWCAP_FPHP		(1 << 9)
>>>>>>>> +#define HWCAP_ASIMDHP		(1 << 10)
>>>>>>>
>>>>>>> Where did we get to with the mrs trapping you proposed here?
>>>>>>>
>>>>>>>   http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374609.html
>>>>>>
>>>>>> We are yet to get some feedback from glibc/gcc folks. Siddhesh was looking
>>>>>> to make use of it [2]. But haven't heard anything back. Ramana mentioned
>>>>>> (in private) that they had some plans to take a look at it.
>>>>>
>>>>> I believe one of Adhemerval's ideas was similar to what I had
>>>>> mentioned back then, which was to provide all of the CPU information
>>>>> in a single file instead of having to traverse a directory structure.
>>>>
>>>> My understanding was that libc needed this information extremely early
>>>> on (i.e. before it could even issue system calls), and therefore such
>>>> an approach would be in addition to the proposal here. Am I mistaken?
>>>
>>> If the idea is to use these instruction for function implementation selection
>>> (iFUNC) the idea is to have on PLT resolution either by accessing it directly
>>> or using a caching mechanism. x86_64 does something similar with cacheline
>>> information: it issues a single cpuid and create processor information table
>>> based on its information (it is also what the __builtin_supports() also
>>> does).
>>>
>>
>> __builtin_supports is not a single cpuid on x86, it is
>> a cpuid per dso with one cache per dso.
>>
>> (gcc-5 used a single cache in libgcc_s.so.1 and that
>> turned out to be broken because ifunc in other dsos
>> could not reliably access it.)
> 
> It is with static libgcc (default), but if you use -shared-gcc only one
> __cpu_model (used by __builtin_cpu_supports) will be linked.  But since
> static libgcc is default it will be indeed one per DSO.

with shared libgcc x86 fmv is broken, the ifunc
resolver may run before libgcc gets relocated.

fwiw shared libgcc is also broken on arm with old kernels.
(because it aborts if 64bit atomics is not supported,
the check assumes it only gets linked in if user code
uses 64bit atomics, but with shared libgcc the check
is always done.)

so i dont think shared libgcc is well supported..

>>>>> The other idea was to add a vDSO function that returns this data so as
>>>>> to avoid (or at least reduce) the context switch latency.
>>>>
>>>> I'm not at all keen on adding a data ABI to the vDSO. I think people tried
>>>> similar things in the past (something on PPC?) and have horror stories
>>>> from that.
>>>
>>> In fact ppc still exports it in vDSO (include/asm/vdso_datapage.h), with
>>> information like the LPAR cfg, platform, processor, {d,i}cache, etc.
>>> I recall that I have see some code back at IBM that tried to use these
>>> fields directly, but indeed it is not recommended.
>>>
>>> What I have in mind is something what ppc does with __kernel_get_syscall_map.
>>> It is vDSO function that returns a vDSO internal data related to which
>>> syscalls are implemented in the running kernel (through a bitmap field).
>>>
>>
>> fs access or vdso does not work for ifunc based dispatch
>> (assuming the current ifunc implementation in glibc).
>>
>> (for vdso you need the AT_SYSINFO_EHDR auxval somehow and
>> then implement elf symbol lookup in the ifunc resolver
>> without calling any libc function. passing auxvals to the
>> ifunc resolver can be done by changing the ifunc abi, but
>> doing symbol lookups there is unrealistic.)
>>
>> in the libc (e.g. for memcpy) ifunc is a bit easier to use,
>> but in user code (function-multi-versioning) ifunc is very
>> limited.
>>
>> i wrote about the ifunc limitations here:
>> https://sourceware.org/ml/libc-alpha/2015-11/msg00108.html
>> see point (4) and (5).
>>
> 
> I recall this thread and indeed iFUNC have a set of limitations.  Although for
> use within libc itself it might be safe with the constraints you have described.
> 
> Now for vDSO usage I think it might be safe to use within GLIBC
> with correct vDSO pointers initialization order. At least it is done
> on GLIBC for gettimeofday for x86_64 and powerpc (the iFUNC returns
> the vDSO function pointer).
> 

i don't see how that can work with static linking.
(vdso setup happens after ifunc resolvers are run)




From catalin.marinas at arm.com  Tue Feb  2 10:26:58 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 2 Feb 2016 18:26:58 +0000
Subject: [PATCH v3] ARM64: kernel: implement ACPI parking protocol
In-Reply-To: <1453806638-23167-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1453806638-23167-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <20160202182657.GC15706@e104818-lin.cambridge.arm.com>

On Tue, Jan 26, 2016 at 11:10:38AM +0000, Lorenzo Pieralisi wrote:
> The SBBR and ACPI specifications allow ACPI based systems that do not
> implement PSCI (eg systems with no EL3) to boot through the ACPI parking
> protocol specification[1].
> 
> This patch implements the ACPI parking protocol CPU operations, and adds
> code that eases parsing the parking protocol data structures to the
> ARM64 SMP initializion carried out at the same time as cpus enumeration.
> 
> To wake-up the CPUs from the parked state, this patch implements a
> wakeup IPI for ARM64 (ie arch_send_wakeup_ipi_mask()) that mirrors the
> ARM one, so that a specific IPI is sent for wake-up purpose in order
> to distinguish it from other IPI sources.
> 
> Given the current ACPI MADT parsing API, the patch implements a glue
> layer that helps passing MADT GICC data structure from SMP initialization
> code to the parking protocol implementation somewhat overriding the CPU
> operations interfaces. This to avoid creating a completely trasparent
> DT/ACPI CPU operations layer that would require creating opaque
> structure handling for CPUs data (DT represents CPU through DT nodes, ACPI
> through static MADT table entries), which seems overkill given that ACPI
> on ARM64 mandates only two booting protocols (PSCI and parking protocol),
> so there is no need for further protocol additions.
> 
> Based on the original work by Mark Salter <msalter at redhat.com>
> 
> [1] https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.docx
> 
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Hanjun Guo <hanjun.guo at linaro.org>
> Cc: Loc Ho <lho at apm.com>
> Cc: Sudeep Holla <sudeep.holla at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Mark Rutland <mark.rutland at arm.com>
> Cc: Mark Salter <msalter at redhat.com>
> Cc: Al Stone <ahs3 at redhat.com>

Applied, with a minor addition just to warn people from not using it in
other configurations (#ifdef still needed otherwise the
acpi_parking_protocol_valid symbol is not available; but I prefer uglier
code than people starting to use this IPI in their firmware):

--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -767,6 +767,12 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
                break;
 #endif
+
+#ifdef CONFIG_ARM64_ACPI_PARKING_PROTOCOL
        case IPI_WAKEUP:
+               WARN_ONCE(!acpi_parking_protocol_valid(cpu),
+                         "CPU%u: Wake-up IPI outside the ACPI parking protocol\n",
+                         cpu);
                break;
+#endif
 
        default:

Thanks.

-- 
Catalin


From adhemerval.zanella at linaro.org  Tue Feb  2 10:28:02 2016
From: adhemerval.zanella at linaro.org (Adhemerval Zanella)
Date: Tue, 2 Feb 2016 16:28:02 -0200
Subject: [PATCH] arm64: Add support for Half precision floating point
In-Reply-To: <56B0F47C.7060004@arm.com>
References: <1453823566-26742-1-git-send-email-suzuki.poulose@arm.com>
 <20160126160257.GB28238@arm.com> <56A79D17.2000009@arm.com>
 <20160126165538.GC22776@devel.intra.reserved-bit.com>
 <20160128160747.GN775@arm.com> <56AA470E.1020606@linaro.org>
 <56B0E7EA.9050601@arm.com> <56B0F19C.5090007@linaro.org>
 <56B0F47C.7060004@arm.com>
Message-ID: <56B0F532.2070600@linaro.org>



On 02-02-2016 16:25, Szabolcs Nagy wrote:
> On 02/02/16 18:12, Adhemerval Zanella wrote:
>> On 02-02-2016 15:31, Szabolcs Nagy wrote:
>>> On 28/01/16 16:51, Adhemerval Zanella wrote:
>>>> On 28-01-2016 14:07, Will Deacon wrote:
>>>>> On Tue, Jan 26, 2016 at 10:25:38PM +0530, Siddhesh Poyarekar wrote:
>>>>>> Adding Adhemerval to cc since he had volunteered to follow up on this,
>>>>>> mainly because he had a couple of additional ideas on the kernel
>>>>>> front.
>>>>>>
>>>>>> On Tue, Jan 26, 2016 at 04:21:43PM +0000, Suzuki K. Poulose wrote:
>>>>>>> On 26/01/16 16:02, Will Deacon wrote:
>>>>>>>> Hi Suzuki,
>>>>>>>>
>>>>>>>> On Tue, Jan 26, 2016 at 03:52:46PM +0000, Suzuki K Poulose wrote:
>>>>>>>>> ARMv8.2 extensions [1] include an optional feature, which supports
>>>>>>>>> half precision(16bit) floating point/asimd data processing
>>>>>>>>> instructions. This patch adds support for detecting and exposing
>>>>>>>>> the same to the userspace via HWCAPs
>>>>>>>
>>>>>>>
>>>>>>>>> +#define HWCAP_FPHP		(1 << 9)
>>>>>>>>> +#define HWCAP_ASIMDHP		(1 << 10)
>>>>>>>>
>>>>>>>> Where did we get to with the mrs trapping you proposed here?
>>>>>>>>
>>>>>>>>   http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374609.html
>>>>>>>
>>>>>>> We are yet to get some feedback from glibc/gcc folks. Siddhesh was looking
>>>>>>> to make use of it [2]. But haven't heard anything back. Ramana mentioned
>>>>>>> (in private) that they had some plans to take a look at it.
>>>>>>
>>>>>> I believe one of Adhemerval's ideas was similar to what I had
>>>>>> mentioned back then, which was to provide all of the CPU information
>>>>>> in a single file instead of having to traverse a directory structure.
>>>>>
>>>>> My understanding was that libc needed this information extremely early
>>>>> on (i.e. before it could even issue system calls), and therefore such
>>>>> an approach would be in addition to the proposal here. Am I mistaken?
>>>>
>>>> If the idea is to use these instruction for function implementation selection
>>>> (iFUNC) the idea is to have on PLT resolution either by accessing it directly
>>>> or using a caching mechanism. x86_64 does something similar with cacheline
>>>> information: it issues a single cpuid and create processor information table
>>>> based on its information (it is also what the __builtin_supports() also
>>>> does).
>>>>
>>>
>>> __builtin_supports is not a single cpuid on x86, it is
>>> a cpuid per dso with one cache per dso.
>>>
>>> (gcc-5 used a single cache in libgcc_s.so.1 and that
>>> turned out to be broken because ifunc in other dsos
>>> could not reliably access it.)
>>
>> It is with static libgcc (default), but if you use -shared-gcc only one
>> __cpu_model (used by __builtin_cpu_supports) will be linked.  But since
>> static libgcc is default it will be indeed one per DSO.
> 
> with shared libgcc x86 fmv is broken, the ifunc
> resolver may run before libgcc gets relocated.
> 
> fwiw shared libgcc is also broken on arm with old kernels.
> (because it aborts if 64bit atomics is not supported,
> the check assumes it only gets linked in if user code
> uses 64bit atomics, but with shared libgcc the check
> is always done.)
> 
> so i dont think shared libgcc is well supported..
> 
>>>>>> The other idea was to add a vDSO function that returns this data so as
>>>>>> to avoid (or at least reduce) the context switch latency.
>>>>>
>>>>> I'm not at all keen on adding a data ABI to the vDSO. I think people tried
>>>>> similar things in the past (something on PPC?) and have horror stories
>>>>> from that.
>>>>
>>>> In fact ppc still exports it in vDSO (include/asm/vdso_datapage.h), with
>>>> information like the LPAR cfg, platform, processor, {d,i}cache, etc.
>>>> I recall that I have see some code back at IBM that tried to use these
>>>> fields directly, but indeed it is not recommended.
>>>>
>>>> What I have in mind is something what ppc does with __kernel_get_syscall_map.
>>>> It is vDSO function that returns a vDSO internal data related to which
>>>> syscalls are implemented in the running kernel (through a bitmap field).
>>>>
>>>
>>> fs access or vdso does not work for ifunc based dispatch
>>> (assuming the current ifunc implementation in glibc).
>>>
>>> (for vdso you need the AT_SYSINFO_EHDR auxval somehow and
>>> then implement elf symbol lookup in the ifunc resolver
>>> without calling any libc function. passing auxvals to the
>>> ifunc resolver can be done by changing the ifunc abi, but
>>> doing symbol lookups there is unrealistic.)
>>>
>>> in the libc (e.g. for memcpy) ifunc is a bit easier to use,
>>> but in user code (function-multi-versioning) ifunc is very
>>> limited.
>>>
>>> i wrote about the ifunc limitations here:
>>> https://sourceware.org/ml/libc-alpha/2015-11/msg00108.html
>>> see point (4) and (5).
>>>
>>
>> I recall this thread and indeed iFUNC have a set of limitations.  Although for
>> use within libc itself it might be safe with the constraints you have described.
>>
>> Now for vDSO usage I think it might be safe to use within GLIBC
>> with correct vDSO pointers initialization order. At least it is done
>> on GLIBC for gettimeofday for x86_64 and powerpc (the iFUNC returns
>> the vDSO function pointer).
>>
> 
> i don't see how that can work with static linking.
> (vdso setup happens after ifunc resolvers are run)

Direct syscalls are used for static case. I didn't yet dig into why exactly
vDSO setup happens after ifunc and if it is possible to change it to
enable this for static linking as well.


From mark.rutland at arm.com  Tue Feb  2 10:28:42 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 2 Feb 2016 18:28:42 +0000
Subject: [PATCH 01/10] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160202182842.GD29778@leverpostej>

On Tue, Feb 02, 2016 at 07:07:39PM +0100, Gregory CLEMENT wrote:
> From: Wilson Ding <dingwei at marvell.com>
> 
> Armada-3700's uart is a simple serial port, which doesn't
> support. Configuring the modem control lines. The uart port has a 32
> bytes Tx FIFO and a 64 bytes Rx FIFO
> 
> The uart driver implements the uart core operations. It also support the
> system (early) console based on Armada-3700's serial port.
> 
> Known Issue:
> 
> The uart driver currently doesn't support clock programming, which means
> the baud-rate stays with the default value configured by the bootloader
> at boot time

To ensure that the bootloader and kernel match, it's best to place the
rate in the stdout-path property (as in
Documentation/devicetree/bindings/chosen.txt).

Presumably that is what you want?

Is it difficutl to add clock programming?

> 
> [gregory.clement at free-electrons.com: Rewrite many part which are too long
> to enumerate]
> 
> Signed-off-by: Wilson Ding <dingwei at marvell.com>
> Signed-off-by: Nadav Haklai <nadavh at marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  .../devicetree/bindings/tty/serial/mvebu-uart.txt  |  13 +
>  Documentation/kernel-parameters.txt                |   6 +
>  drivers/tty/serial/Kconfig                         |  22 +
>  drivers/tty/serial/Makefile                        |   1 +
>  drivers/tty/serial/mvebu-uart.c                    | 649 +++++++++++++++++++++
>  include/uapi/linux/serial_core.h                   |   3 +
>  6 files changed, 694 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
>  create mode 100644 drivers/tty/serial/mvebu-uart.c
> 
> diff --git a/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
> new file mode 100644
> index 000000000000..6087defd9f93
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
> @@ -0,0 +1,13 @@
> +* Marvell UART : Non standard UART used in some of Marvell EBU SoCs (e.g., Armada-3700)
> +
> +Required properties:
> +- compatible: "marvell,armada-3700-uart"
> +- reg: offset and length of the register set for the device.
> +- interrupts: device interrupt
> +
> +Example:
> +	serial at 12000 {
> +		compatible = "marvell,armada-3700-uart";
> +		reg = <0x12000 0x400>;
> +		interrupts = <43>;
> +	};

There are no external clock inputs?

> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 87d40a72f6a1..198f6bd56e84 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1058,6 +1058,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>  			A valid base address must be provided, and the serial
>  			port must already be setup and configured.
>  
> +		mvebu_uart,<addr>
> +			Start an early, polled-mode console on an some mvebu
> +			SoC (as the Armada-3700) serial port at the specified
> +			address. The serial port must already be setup and
> +			configured. Options are not yet supported.
> +

Does the the mvebu UART vary between platforms at all?

Thanks,
Mark.


From john.stultz at linaro.org  Tue Feb  2 10:29:32 2016
From: john.stultz at linaro.org (John Stultz)
Date: Tue, 2 Feb 2016 10:29:32 -0800
Subject: [PATCH v3 1/4] dt-bindings: power: reset: add document for
 reboot-mode driver
In-Reply-To: <1454407151-4751-1-git-send-email-andy.yan@rock-chips.com>
References: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
 <1454407151-4751-1-git-send-email-andy.yan@rock-chips.com>
Message-ID: <CALAqxLXBMOicSm41jnD2pqmYEGCA9cy9RfrdXFPNM1m_iH53WA@mail.gmail.com>

On Tue, Feb 2, 2016 at 1:59 AM, Andy Yan <andy.yan at rock-chips.com> wrote:
> add device tree bindings document for reboot-mode driver
>
> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
>
> ---
>
> Changes in v3:
> - descirbe all reboot mode as properity instead of subnode
>
> Changes in v2: None
> Changes in v1: None
>
>  .../bindings/power/reset/reboot-mode.txt           | 26 ++++++++++++++++
>  .../bindings/power/reset/syscon-reboot-mode.txt    | 36 ++++++++++++++++++++++
>  2 files changed, 62 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/reset/reboot-mode.txt
>  create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
>
> diff --git a/Documentation/devicetree/bindings/power/reset/reboot-mode.txt b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
> new file mode 100644
> index 0000000..517080f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
> @@ -0,0 +1,26 @@
> +Generic reboot mode core map driver
> +
> +This driver get reboot mode arguments and call the write
> +interface to stores the magic value in special register
> +or ram . Then the bootloader can read it and take different
> +action according the argument stored.
> +
> +All mode properties are vendor specific, it is a indication to tell
> +the bootloder what to do when the system reboot, and should be named
> +as mode-xxx = <magic> (xxx is mode name).
> +
> +- mode-normal: Normal reboot mode, system reboot with command "reboot".
> +- mode-recovery: Android Recovery mode, it is a mode to format the device or update a new image.
> +- mode-fastboot: Android fastboot mode, it's a mode to  re-flash partitions on the device.

One minor tweak here, on most Android devices (atleast most Nexus
devices) getting to fastboot is done via "reboot bootloader" not
"reboot fastboot".

If we are going to document the commands here to establish a standard,
I'd prefer we use use what existing userspace expects:

So across nexus devices, there's really two consistent commands:
"bootloader", and "recovery"

Nexus 6p:  https://android.googlesource.com/kernel/msm.git/+/android-msm-bullhead-3.10-marshmallow-mr1/drivers/power/reset/msm-poweroff.c#230
Nexus 9: https://android.googlesource.com/kernel/tegra.git/+/android-tegra-flounder-3.10-marshmallow-mr1/drivers/htc_debug/stability/reboot_params.c#86
Nexus 7: https://android.googlesource.com/kernel/msm.git/+/android-msm-flo-3.4-marshmallow-mr1/arch/arm/mach-msm/restart.c#273
Nexus 10: https://android.googlesource.com/kernel/exynos.git/+/android-exynos-manta-3.4-lollipop-mr1/arch/arm/mach-exynos/board-manta-power.c#422

While I don't object to having a duplicative mode-fastboot (it is more
clear as to what the command does), or the other oem specific modes, I
think we should make it clear that the Android userspace expects the
"bootloader" and "recovery" commands and document them here.

thanks
-john


From mark.rutland at arm.com  Tue Feb  2 10:34:36 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 2 Feb 2016 18:34:36 +0000
Subject: [PATCH 07/10] arm64: dts: add the Marvell Armada 3700 family and
 a development board
In-Reply-To: <1454436468-4241-8-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-8-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160202183436.GE29778@leverpostej>

> +	memory {
> +		device_type = "memory";
> +		/* use only 256 MB on the 512 MB available */
> +		reg = <0x00000000 0x00000000 0x00000000 0x10000000>;
> +	};

It would be good to comment as to why we can't use 256M of the memory.

Otherwise this looks fine.

Mark.


From stern at rowland.harvard.edu  Tue Feb  2 10:43:10 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 2 Feb 2016 13:43:10 -0500 (EST)
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160202180555.GW19432@atomide.com>
Message-ID: <Pine.LNX.4.44L0.1602021335170.1653-100000@iolanthe.rowland.org>

On Tue, 2 Feb 2016, Tony Lindgren wrote:

> * Tony Lindgren <tony at atomide.com> [160202 08:50]:
> > * Alan Stern <stern at rowland.harvard.edu> [160202 08:17]:
> > 
> > > ?  pm_runtime_put_sync() _already_ does not respect the autosuspend 
> > > mode.  If you want to respect it, you have to call 
> > > pm_runtime_put_sync_autosuspend() instead.
> > 
> > I think you found the real bug there. So the right fix is to
> > call pm_runtime_put_sync_autosuspend() at the end of failed
> > probe in omap_hsmmc. Let me give that a try here.
> 
> Nope that's not it but getting closer.
> 
> The following seems to make things behave for me. Now the
> question is.. Does it have some undesired side effects?

Yes, it does.

I'm still not clear on what you want to accomplish.  It sounds like you 
want to perform a runtime suspend following the last probe (if the 
probe fails), and in between probes you don't really care (although it 
would be preferable to avoid suspending).

Does pm_runtime_use_autosuspend() get called by the probe routine?  If 
it does, then perhaps you can get what you want by having the probe 
routine call pm_runtime_dont_use_autosuspend() whenever it's about to 
return an error -- particularly -EDEFER.

> > Can we add some warning to pm_runtime_put_sync() about that?
> 
> Probably no need for that, I misunderstood the meaning of
> pm_runtime_put_sync_autosuspend().
> 
> Regards,
> 
> Tony
> 
> 8< --------------
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -435,7 +435,7 @@ static int rpm_suspend(struct device *dev, int rpmflags)
>  		goto out;
>  
>  	/* If the autosuspend_delay time hasn't expired yet, reschedule. */
> -	if ((rpmflags & RPM_AUTO)
> +	if (((rpmflags & (RPM_ASYNC | RPM_AUTO)) == ((RPM_ASYNC | RPM_AUTO)))
>  	    && dev->power.runtime_status != RPM_SUSPENDING) {
>  		unsigned long expires = pm_runtime_autosuspend_expiration(dev);

This would prevent pm_runtime_autosuspend() from working correctly.

Alan Stern



From khilman at baylibre.com  Tue Feb  2 10:46:29 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Tue, 02 Feb 2016 10:46:29 -0800
Subject: MTK mt8173-evb: mainline unstable, and big-endian boot failures
In-Reply-To: <1454379462.27798.11.camel@mtksdaap41> (Fan Chen's message of
 "Tue, 2 Feb 2016 10:17:42 +0800")
References: <CAOi56cVDbkAJEDWy3+DV63a=UuD7nqpUu8X7e-OjtWM-4dj_-w@mail.gmail.com>
 <7hsi1ilczm.fsf@baylibre.com>
 <CAF-23O3ps0Wt_UCmJbArpc5iJJryJKA0k_2qAyNb7op8O=UnAg@mail.gmail.com>
 <1453964180.26397.8.camel@mtksdaap41> <7hy4b8gc7q.fsf@baylibre.com>
 <1454309376.11974.3.camel@mtksdaap41> <7hh9hrgbbh.fsf@baylibre.com>
 <1454379462.27798.11.camel@mtksdaap41>
Message-ID: <7h37tbdk6y.fsf@baylibre.com>

Hi Fan,

Fan Chen <fan.chen at mediatek.com> writes:

> I just checked that the problem cannot be reproduced (tested 100 times
> with your script) after flashing new firmware which we uploaded to
> github[0] yesterday.

Great news!

> This latest firmware got many fixes and also supports cluster idle, so
> we prefer testing with this new one Would you please test in your
> side? Thanks for your great help!!

I tested the latest firmware and it's booted 20+ times in a row without
failure, which is better than it ever did in the past, so it seems to
have fixed the idle problem.

I will keep an eye on the failures in kernelci.org and let you know if I
notice any other failures.

Thanks again for the updated firmware!

Speaking of updated firmware, is there any chance to make the default
version of the firmware significantly less noisy.  There is a TON of
output from the firmware before fastboot starts which makes the logs for
this board very noisy (same complaint on the mt8135.)

Kevin

>
>
> Best regards,
> Fan
>
> On Mon, 2016-02-01 at 17:17 -0800, Kevin Hilman wrote:
>> Hi Eddie,
>> 
>> Eddie Huang <eddie.huang at mediatek.com> writes:
>> 
>> [...]
>> 
>> > Thanks your patience to provide detail steps, we can reproduce this
>> > problem now. It seems something wrong in ATF, we still investigate how
>> > to fix it. We will provide you new ATF firmware once we have solution
>> 
>> Great, I'm glad you can reproduce it.  I was starting to worry it was
>> only my hardware with the problem.
>> 
>> Please let me know if there are firmware updates you'd like me to test
>> and I'll be happy to.
>> 
>> Thanks,
>> 
>> Kevin


From tony at atomide.com  Tue Feb  2 10:47:34 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 2 Feb 2016 10:47:34 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160202180555.GW19432@atomide.com>
References: <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602021112320.1653-100000@iolanthe.rowland.org>
 <20160202164910.GV19432@atomide.com>
 <20160202180555.GW19432@atomide.com>
Message-ID: <20160202184733.GX19432@atomide.com>

* Tony Lindgren <tony at atomide.com> [160202 10:07]:
> 
> The following seems to make things behave for me. Now the
> question is.. Does it have some undesired side effects?

The side effect is that it breaks PM runtime for devices
during runtime..

Regards,

Tony


From f.fainelli at gmail.com  Tue Feb  2 10:46:59 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 02 Feb 2016 10:46:59 -0800
Subject: [PATCH] ARM: BCM63xx: Remove unused pmb_dn variable
In-Reply-To: <1454286768-20736-1-git-send-email-f.fainelli@gmail.com>
References: <1454286768-20736-1-git-send-email-f.fainelli@gmail.com>
Message-ID: <56B0F9A3.7050306@gmail.com>

On 31/01/16 16:32, Florian Fainelli wrote:
> Introduced in commit 3f2a43c98d72b ("ARM: BCM63xx: Add secondary CPU PMB
> initialization sequence"), but not used by the code.
> 
> Reported-by: David Binderman <dcb314 at hotmail.com>
> Signed-off-by: Florian Fainelli <f.fainelli at gmail.com>

Applied to soc/next.
-- 
Florian


From f.fainelli at gmail.com  Tue Feb  2 10:48:55 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 02 Feb 2016 10:48:55 -0800
Subject: [PATCH] MAINTAINERS: ARM: BCM63xx: Update git and mailing-lists
In-Reply-To: <1454290873-29931-1-git-send-email-f.fainelli@gmail.com>
References: <1454290873-29931-1-git-send-email-f.fainelli@gmail.com>
Message-ID: <56B0FA17.1060405@gmail.com>

On 31/01/16 17:41, Florian Fainelli wrote:
> arm-bcm63xx.git has not been used for development, instead, all patches
> have been added to stblinux.git, so reflect that. While at it, add
> bcm-kernel-feedback-list at broadcom.com as a secondary list to include
> submissions, and finally update LAKML to reflect that it is moderated.
> 
> Signed-off-by: Florian Fainelli <f.fainelli at gmail.com>

Applied to maintainers/next.
-- 
Florian


From tony at atomide.com  Tue Feb  2 10:54:51 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 2 Feb 2016 10:54:51 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <Pine.LNX.4.44L0.1602021335170.1653-100000@iolanthe.rowland.org>
References: <20160202180555.GW19432@atomide.com>
 <Pine.LNX.4.44L0.1602021335170.1653-100000@iolanthe.rowland.org>
Message-ID: <20160202185450.GY19432@atomide.com>

* Alan Stern <stern at rowland.harvard.edu> [160202 10:44]:
> On Tue, 2 Feb 2016, Tony Lindgren wrote:
> 
> > * Tony Lindgren <tony at atomide.com> [160202 08:50]:
> > > * Alan Stern <stern at rowland.harvard.edu> [160202 08:17]:
> > > 
> > > > ?  pm_runtime_put_sync() _already_ does not respect the autosuspend 
> > > > mode.  If you want to respect it, you have to call 
> > > > pm_runtime_put_sync_autosuspend() instead.
> > > 
> > > I think you found the real bug there. So the right fix is to
> > > call pm_runtime_put_sync_autosuspend() at the end of failed
> > > probe in omap_hsmmc. Let me give that a try here.
> > 
> > Nope that's not it but getting closer.
> > 
> > The following seems to make things behave for me. Now the
> > question is.. Does it have some undesired side effects?
> 
> Yes, it does.

Yeah noticed..

> I'm still not clear on what you want to accomplish.  It sounds like you 
> want to perform a runtime suspend following the last probe (if the 
> probe fails), and in between probes you don't really care (although it 
> would be preferable to avoid suspending).

I'd like to have pm_runtime_put_sync() disable the hardware after
the initial failed probe. Currently that does not happen unless
pm_runtime_dont_use_autosuspend() is called before pm_runtime_put_sync().

> Does pm_runtime_use_autosuspend() get called by the probe routine?  If 
> it does, then perhaps you can get what you want by having the probe 
> routine call pm_runtime_dont_use_autosuspend() whenever it's about to 
> return an error -- particularly -EDEFER.

Yes so far that's the only fix that seems to work like I posted
earlier. But is that the right fix though?

If we wanted to have some generic fix, it seems we would have to pass
a new flag in pm_runtime_put_sync() to ignore any autosuspend
configuration. But I don't know if that's what we want to or should
do though?

Regards,

Tony


From javier at osg.samsung.com  Tue Feb  2 10:56:09 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Tue, 2 Feb 2016 15:56:09 -0300
Subject: [PATCH] drivers: soc: samsung: Enable COMPILE_TEST
In-Reply-To: <1454396777-20034-1-git-send-email-k.kozlowski@samsung.com>
References: <1454396777-20034-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <56B0FBC9.1020308@osg.samsung.com>

Hello Krzysztof,

On 02/02/2016 04:06 AM, Krzysztof Kozlowski wrote:
> Get some build coverage of Exynos SROM controller and PMU drivers. The
> PMU driver depends on asm/cputype.h so its compilation is limited to ARM
> architectures.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
>

Patch looks good to me.

Reviewed-by: Javier Martinez Canillas <javier at osg.samsung.com>

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America


From Chris.Brandt at renesas.com  Tue Feb  2 10:59:22 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Tue, 2 Feb 2016 18:59:22 +0000
Subject: [PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM
In-Reply-To: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <HKXPR06MB0565A2CFF95AD7C000F43E6A8ADF0@HKXPR06MB0565.apcprd06.prod.outlook.com>

On Tue, 2 Feb 2016, Ard Biesheuvel wrote:

> This series applies on top of today's -next, and addresses an issue 
> with the new kallsyms code that is queued there, that enables base 
> relative kallsyms tables for all architectures (except IA-64)
> 
> Two issues have surfaced on ARM with the new kallsyms code:
> a) CONFIG_HAVE_TCM creates a virtual region that is too far away for the
>    relative kallsyms code to reach it;
> b) CONFIG_XIP_KERNEL=y kernel symbols are not filtered against PAGE_OFFSET,
>    as is the case for kernels that execute from RAM, resulting in symbols
>    that are out of range.


For whatever it's worth:


I applied my XIP_KERNEL fixes (for ARMv7) on top of -next and attempted to boot which resulted in a flood of these:

  "Unable to handle kernel NULL pointer dereference at virtual address 00000000"

and of course it dies.


I then applied the 3 patches and tried again and this time it booted up....almost.
It looks like it makes it all the way up to when it is going to mount my rootfs, but then dies.

My kernel (.text) starts at 0xbf000000 (MODULES_VADDR), so the "LR is at 0xb6f87e88" is obviously bad.


Chris



================ boot log ======================


VFS: Mounted root (squashfs filesystem) readonly on device 31:0.
devtmpfs: mounted
Freeing unused kernel memory: 36K (c000a000 - c0013000)
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c05f0000
[00000000] *pgd=205f5831, *pte=00000000, *ppte=00000000
Internal error: Oops: 80000007 [#1] ARM
Modules linked in:
CPU: 0 PID: 1 Comm: init Not tainted 4.5.0-rc2-next-20160202-dirty #3
Hardware name: Generic R7S72100 (Flattened Device Tree)
task: c0613000 ti: c0614000 task.ti: c0614000
PC is at 0x0
LR is at 0xb6f87e88
pc : [<00000000>]    lr : [<b6f87e88>]    psr: 80000093
sp : c0615ff8  ip : 00000054  fp : beca8ba4
r10: b6f8b9ab  r9 : 00000000  r8 : 00000014
r7 : 000000c0  r6 : b6f93f74  r5 : 00000000  r4 : ffffffff
r3 : 04000022  r2 : 00000003  r1 : 00001000  r0 : 00000000
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 18c5347d  Table: 205f0059  DAC: 00000055
Process init (pid: 1, stack limit = 0xc0614208)
Stack: (0xc0615ff8 to 0xc0616000)
5fe0:                                                       fde4be6f 89031a8e
Backtrace: invalid frame pointer 0xbeca8ba4
Code: bad PC value
---[ end trace ed7071b866b0f003 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b




From ard.biesheuvel at linaro.org  Tue Feb  2 11:00:48 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 2 Feb 2016 20:00:48 +0100
Subject: [PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM
In-Reply-To: <HKXPR06MB0565A2CFF95AD7C000F43E6A8ADF0@HKXPR06MB0565.apcprd06.prod.outlook.com>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <HKXPR06MB0565A2CFF95AD7C000F43E6A8ADF0@HKXPR06MB0565.apcprd06.prod.outlook.com>
Message-ID: <CAKv+Gu9VvskQ34w0niS+6AtF9hNcycfYDt_3Kp4T+WK8Vxf_dA@mail.gmail.com>

On 2 February 2016 at 19:59, Chris Brandt <Chris.Brandt at renesas.com> wrote:
> On Tue, 2 Feb 2016, Ard Biesheuvel wrote:
>
>> This series applies on top of today's -next, and addresses an issue
>> with the new kallsyms code that is queued there, that enables base
>> relative kallsyms tables for all architectures (except IA-64)
>>
>> Two issues have surfaced on ARM with the new kallsyms code:
>> a) CONFIG_HAVE_TCM creates a virtual region that is too far away for the
>>    relative kallsyms code to reach it;
>> b) CONFIG_XIP_KERNEL=y kernel symbols are not filtered against PAGE_OFFSET,
>>    as is the case for kernels that execute from RAM, resulting in symbols
>>    that are out of range.
>
>
> For whatever it's worth:
>
>
> I applied my XIP_KERNEL fixes (for ARMv7) on top of -next and attempted to boot which resulted in a flood of these:
>
>   "Unable to handle kernel NULL pointer dereference at virtual address 00000000"
>
> and of course it dies.
>
>
> I then applied the 3 patches and tried again and this time it booted up....almost.
> It looks like it makes it all the way up to when it is going to mount my rootfs, but then dies.
>
> My kernel (.text) starts at 0xbf000000 (MODULES_VADDR), so the "LR is at 0xb6f87e88" is obviously bad.
>
>
> ================ boot log ======================
>
>
> VFS: Mounted root (squashfs filesystem) readonly on device 31:0.
> devtmpfs: mounted
> Freeing unused kernel memory: 36K (c000a000 - c0013000)
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = c05f0000
> [00000000] *pgd=205f5831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 80000007 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: init Not tainted 4.5.0-rc2-next-20160202-dirty #3
> Hardware name: Generic R7S72100 (Flattened Device Tree)
> task: c0613000 ti: c0614000 task.ti: c0614000
> PC is at 0x0
> LR is at 0xb6f87e88
> pc : [<00000000>]    lr : [<b6f87e88>]    psr: 80000093
> sp : c0615ff8  ip : 00000054  fp : beca8ba4
> r10: b6f8b9ab  r9 : 00000000  r8 : 00000014
> r7 : 000000c0  r6 : b6f93f74  r5 : 00000000  r4 : ffffffff
> r3 : 04000022  r2 : 00000003  r1 : 00001000  r0 : 00000000
> Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 18c5347d  Table: 205f0059  DAC: 00000055
> Process init (pid: 1, stack limit = 0xc0614208)
> Stack: (0xc0615ff8 to 0xc0616000)
> 5fe0:                                                       fde4be6f 89031a8e
> Backtrace: invalid frame pointer 0xbeca8ba4
> Code: bad PC value
> ---[ end trace ed7071b866b0f003 ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
>

Are you getting any warnings/errors during the build?


From moinejf at free.fr  Tue Feb  2 11:02:21 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Tue, 2 Feb 2016 20:02:21 +0100
Subject: [PATCH v2 2/2] drm: sunxi: Add a basic DRM driver for Allwinner
 DE2
In-Reply-To: <56B0E6B5.5040708@arm.com>
References: <cover.1452876522.git.moinejf@free.fr>
 <4c40052b27f74df1342e631cb0f9ed5993861a54.1452876522.git.moinejf@free.fr>
 <569F6C1E.8000006@arm.com>
 <20160202181949.d59e84a040a980abcdd69d32@free.fr>
 <56B0E6B5.5040708@arm.com>
Message-ID: <20160202200221.514518980dcd1a75c262355f@free.fr>

On Tue, 2 Feb 2016 17:26:13 +0000
Andre Przywara <andre.przywara at arm.com> wrote:

> Can you sketch (or point me to) what I need to do? Just a
> simple-framebuffer DT node?
> I take it that the driver does not depend on any kind of U-Boot
> initialisation, but instead takes care of this itself?
> 
> And would this pave the way for fbturbo also?

In my site (http://moinejf.free.fr/opi2/), you may find:
- the HDMI driver - to be built out of tree
- the DT files (sun8i-h3.dtsi and sun8i-h3-orangepi-plus.dts)
  which should be close enough to the A64
- my .config (config-4.5.txt)

The driver has no video overlay and no acceleration.
The frame buffer (console) works (with a blinking cursor!).
X11 works fine with the standard modesetting driver (default).

There is just a problem with the HDMI driver.
For unknown reason, sometimes, the EDID cannot be read (timeout -
this problem also exists with the kernel 3.4).
The remedy is power off / power on (of the board, not of the screen!).

I am using the u-boot from Allwinner. This one activates the video
engine, but everything is reset at kernel start time.

About the GPU/VPU, I have no need of them, so I will let this job to
specialists and, instead, have a look at audio...

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/



From Chris.Brandt at renesas.com  Tue Feb  2 11:13:43 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Tue, 2 Feb 2016 19:13:43 +0000
Subject: [PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM
In-Reply-To: <CAKv+Gu9VvskQ34w0niS+6AtF9hNcycfYDt_3Kp4T+WK8Vxf_dA@mail.gmail.com>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <HKXPR06MB0565A2CFF95AD7C000F43E6A8ADF0@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu9VvskQ34w0niS+6AtF9hNcycfYDt_3Kp4T+WK8Vxf_dA@mail.gmail.com>
Message-ID: <HKXPR06MB056547567A1B02C73A13EEFE8ADF0@HKXPR06MB0565.apcprd06.prod.outlook.com>

> Are you getting any warnings/errors during the build?

Nothing. The build was clean.


And just to be safe, I did make clean, then make xipImage and re-flashed again.
Same result.


I'll see if I can step through and see exactly where it's dying.
I realize that no one really care about or tests XIP_KERNEL with ARMv7 at the moment, so I'll have to figure it out that some point. I just thought I'd let you know.


Chris


From stern at rowland.harvard.edu  Tue Feb  2 11:16:30 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 2 Feb 2016 14:16:30 -0500 (EST)
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160202185450.GY19432@atomide.com>
Message-ID: <Pine.LNX.4.44L0.1602021402250.1653-100000@iolanthe.rowland.org>

On Tue, 2 Feb 2016, Tony Lindgren wrote:

> > I'm still not clear on what you want to accomplish.  It sounds like you 
> > want to perform a runtime suspend following the last probe (if the 
> > probe fails), and in between probes you don't really care (although it 
> > would be preferable to avoid suspending).
> 
> I'd like to have pm_runtime_put_sync() disable the hardware after
> the initial failed probe. Currently that does not happen unless
> pm_runtime_dont_use_autosuspend() is called before pm_runtime_put_sync().

pm_runtime_put_sync() doesn't do anything to the hardware if the usage
count was > 1, because after the decrement it's still nonzero.  Where
is the particular call of pm_runtime_put_sync() that you're interested
in, and what is the usage count when it runs?  It's not at all unusual
for the usage count to be > 1 during a probe.

Also, what is autosuspend_delay set to for your device?  And is 
runtime_auto set?

> > Does pm_runtime_use_autosuspend() get called by the probe routine?  If 
> > it does, then perhaps you can get what you want by having the probe 
> > routine call pm_runtime_dont_use_autosuspend() whenever it's about to 
> > return an error -- particularly -EDEFER.
> 
> Yes so far that's the only fix that seems to work like I posted
> earlier. But is that the right fix though?

No, not really.  Ideally you would leave autosuspend turned on.  The 
delay would be long enough to that after -EDEFER, another probe would 
start before the delay expired.  But shortly after the last probe 
attempt, the delay would expire and the device would then be put in low 
power.

> If we wanted to have some generic fix, it seems we would have to pass
> a new flag in pm_runtime_put_sync() to ignore any autosuspend
> configuration. But I don't know if that's what we want to or should
> do though?

I don't think so.

Alan Stern



From broonie at kernel.org  Tue Feb  2 11:17:55 2016
From: broonie at kernel.org (Mark Brown)
Date: Tue, 2 Feb 2016 19:17:55 +0000
Subject: [PATCH v3 0/2] Add SPDIF support for Allwinner SoCs
In-Reply-To: <1454424594-25208-1-git-send-email-codekipper@gmail.com>
References: <1454424594-25208-1-git-send-email-codekipper@gmail.com>
Message-ID: <20160202191755.GT4455@sirena.org.uk>

On Tue, Feb 02, 2016 at 03:49:52PM +0100, codekipper at gmail.com wrote:

> Marcus Cooper (2):
>   dt-bindings: add sun4i SPDIF transceiver bindings
>   ASOC: sunxi: Add support for the SPDIF block

Please do try to use subject lines matching the style for the subsystem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/6b85c431/attachment.sig>

From bhelgaas at google.com  Tue Feb  2 11:38:26 2016
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Tue, 02 Feb 2016 13:38:26 -0600
Subject: [PATCH 0/5] Clean up warnings (part 2, asm/pci-bridge.h)
Message-ID: <20160202193026.9258.7573.stgit@bhelgaas-glaptop2.roam.corp.google.com>

We've had some non-arch-specific stuff (pci_has_flag() and associated
definitions like PCI_PROBE_ONLY) in asm/pci-bridge.h.  This leads to
warnings like:

  drivers/pci/host/pcie-designware.c:562:20: error: 'PCI_PROBE_ONLY' undeclared (first use in this function)
  drivers/pci/host/pcie-designware.c:562:7: error: implicit declaration of function 'pci_has_flag' [-Werror=implicit-function-declaration]

because arches don't consistently supply asm/pci-bridge.h, and several
drivers include it when they shouldn't.

This series moves the generic stuff to linux/pci.h, so it's the same for
everybody, and removes the now-empty asm-generic/pci-bridge.h.

There still a few arches that provide asm/pci-bridge.h (microblaze,
powerpc, and xtensa), but now they contain truly arch-dependent things like
struct pci_controller definitions, and they're only included by
arch-specific files.

---

Bjorn Helgaas (5):
      PCI: Move pci_set_flags() from asm-generic/pci-bridge.h to linux/pci.h
      PCI: Remove includes of empty asm-generic/pci-bridge.h
      ARM64: PCI: Remove generated include of asm-generic/pci-bridge.h
      PCI: Remove empty asm-generic/pci-bridge.h
      PCI: Remove includes of asm/pci-bridge.h


 arch/alpha/include/asm/pci.h               |    1 
 arch/arm/include/asm/pci.h                 |    3 -
 arch/arm64/include/asm/Kbuild              |    3 -
 arch/arm64/include/asm/pci.h               |    1 
 arch/arm64/kernel/pci.c                    |    2 -
 arch/mips/include/asm/pci.h                |    1 
 arch/powerpc/include/asm/pci-bridge.h      |    1 
 arch/unicore32/include/asm/pci.h           |    2 -
 arch/x86/pci/common.c                      |    1 
 drivers/ata/pata_macio.c                   |    2 -
 drivers/char/agp/uninorth-agp.c            |    1 
 drivers/gpu/drm/radeon/radeon_combios.c    |    1 
 drivers/ide/pdc202xx_new.c                 |    1 
 drivers/ide/pmac.c                         |    1 
 drivers/macintosh/macio_asic.c             |    1 
 drivers/misc/cxl/pci.c                     |    1 
 drivers/net/ethernet/sun/sungem.c          |    1 
 drivers/net/ethernet/toshiba/spider_net.c  |    1 
 drivers/of/of_pci.c                        |    1 
 drivers/pci/pci.c                          |    1 
 drivers/pci/probe.c                        |    8 +++
 drivers/pci/setup-bus.c                    |    1 
 drivers/scsi/mac53c94.c                    |    2 -
 drivers/scsi/mesh.c                        |    2 -
 drivers/usb/core/hcd-pci.c                 |    1 
 drivers/video/fbdev/aty/aty128fb.c         |    1 
 drivers/video/fbdev/aty/radeon_base.c      |    1 
 drivers/video/fbdev/imsttfb.c              |    1 
 drivers/video/fbdev/matrox/matroxfb_base.h |    1 
 drivers/video/fbdev/offb.c                 |    4 --
 include/asm-generic/pci-bridge.h           |   74 ----------------------------
 include/linux/pci.h                        |   22 ++++++++
 sound/ppc/pmac.c                           |    1 
 33 files changed, 32 insertions(+), 114 deletions(-)
 delete mode 100644 include/asm-generic/pci-bridge.h


From bhelgaas at google.com  Tue Feb  2 11:38:34 2016
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Tue, 02 Feb 2016 13:38:34 -0600
Subject: [PATCH 1/5] PCI: Move pci_set_flags() from asm-generic/pci-bridge.h
 to linux/pci.h
In-Reply-To: <20160202193026.9258.7573.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20160202193026.9258.7573.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <20160202193834.9258.64377.stgit@bhelgaas-glaptop2.roam.corp.google.com>

The PCI flag management constants and functions were previously declared in
include/asm-generic/pci-bridge.h.  But they are not specific to bridges,
and arches did not include pci-bridge.h consistently.

Move the following interfaces and related constants to include/linux/pci.h
and remove pci-bridge.h:

  pci_set_flags()
  pci_add_flags()
  pci_clear_flags()
  pci_has_flag()

This fixes these warnings when building for some arches:

  drivers/pci/host/pcie-designware.c:562:20: error: 'PCI_PROBE_ONLY' undeclared (first use in this function)
  drivers/pci/host/pcie-designware.c:562:7: error: implicit declaration of function 'pci_has_flag' [-Werror=implicit-function-declaration]

Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
---
 drivers/pci/probe.c              |    7 ++++
 include/asm-generic/pci-bridge.h |   65 --------------------------------------
 include/linux/pci.h              |   22 +++++++++++++
 3 files changed, 29 insertions(+), 65 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 6d7ab9b..ead1ac1 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1803,6 +1803,13 @@ static int only_one_child(struct pci_bus *bus)
 		return 0;
 	if (pci_pcie_type(parent) == PCI_EXP_TYPE_ROOT_PORT)
 		return 1;
+
+	/*
+	 * PCIe downstream ports are bridges that normally lead to only a
+	 * device 0, but if PCI_SCAN_ALL_PCIE_DEVS is set, scan all
+	 * possible devices, not just device 0.  See PCIe spec r3.0,
+	 * sec 7.3.1.
+	 */
 	if (parent->has_secondary_link &&
 	    !pci_has_flag(PCI_SCAN_ALL_PCIE_DEVS))
 		return 1;
diff --git a/include/asm-generic/pci-bridge.h b/include/asm-generic/pci-bridge.h
index 20db2e5..1b1d82f 100644
--- a/include/asm-generic/pci-bridge.h
+++ b/include/asm-generic/pci-bridge.h
@@ -6,69 +6,4 @@
  */
 #ifndef _ASM_GENERIC_PCI_BRIDGE_H
 #define _ASM_GENERIC_PCI_BRIDGE_H
-
-#ifdef __KERNEL__
-
-enum {
-	/* Force re-assigning all resources (ignore firmware
-	 * setup completely)
-	 */
-	PCI_REASSIGN_ALL_RSRC	= 0x00000001,
-
-	/* Re-assign all bus numbers */
-	PCI_REASSIGN_ALL_BUS	= 0x00000002,
-
-	/* Do not try to assign, just use existing setup */
-	PCI_PROBE_ONLY		= 0x00000004,
-
-	/* Don't bother with ISA alignment unless the bridge has
-	 * ISA forwarding enabled
-	 */
-	PCI_CAN_SKIP_ISA_ALIGN	= 0x00000008,
-
-	/* Enable domain numbers in /proc */
-	PCI_ENABLE_PROC_DOMAINS	= 0x00000010,
-	/* ... except for domain 0 */
-	PCI_COMPAT_DOMAIN_0	= 0x00000020,
-
-	/* PCIe downstream ports are bridges that normally lead to only a
-	 * device 0, but if this is set, we scan all possible devices, not
-	 * just device 0.
-	 */
-	PCI_SCAN_ALL_PCIE_DEVS	= 0x00000040,
-};
-
-#ifdef CONFIG_PCI
-extern unsigned int pci_flags;
-
-static inline void pci_set_flags(int flags)
-{
-	pci_flags = flags;
-}
-
-static inline void pci_add_flags(int flags)
-{
-	pci_flags |= flags;
-}
-
-static inline void pci_clear_flags(int flags)
-{
-	pci_flags &= ~flags;
-}
-
-static inline int pci_has_flag(int flag)
-{
-	return pci_flags & flag;
-}
-#else
-static inline void pci_set_flags(int flags) { }
-static inline void pci_add_flags(int flags) { }
-static inline void pci_clear_flags(int flags) { }
-static inline int pci_has_flag(int flag)
-{
-	return 0;
-}
-#endif	/* CONFIG_PCI */
-
-#endif	/* __KERNEL__ */
 #endif	/* _ASM_GENERIC_PCI_BRIDGE_H */
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 27df4a6..3d371c1 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -746,9 +746,26 @@ struct pci_driver {
 	.vendor = PCI_VENDOR_ID_##vend, .device = (dev), \
 	.subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, 0, 0
 
+enum {
+	PCI_REASSIGN_ALL_RSRC	= 0x00000001,	/* ignore firmware setup */
+	PCI_REASSIGN_ALL_BUS	= 0x00000002,	/* reassign all bus numbers */
+	PCI_PROBE_ONLY		= 0x00000004,	/* use existing setup */
+	PCI_CAN_SKIP_ISA_ALIGN	= 0x00000008,	/* don't do ISA alignment */
+	PCI_ENABLE_PROC_DOMAINS	= 0x00000010,	/* enable domains in /proc */
+	PCI_COMPAT_DOMAIN_0	= 0x00000020,	/* ... except domain 0 */
+	PCI_SCAN_ALL_PCIE_DEVS	= 0x00000040,	/* scan all, not just dev 0 */
+};
+
 /* these external functions are only available when PCI support is enabled */
 #ifdef CONFIG_PCI
 
+extern unsigned int pci_flags;
+
+static inline void pci_set_flags(int flags) { pci_flags = flags; }
+static inline void pci_add_flags(int flags) { pci_flags |= flags; }
+static inline void pci_clear_flags(int flags) { pci_flags &= ~flags; }
+static inline int pci_has_flag(int flag) { return pci_flags & flag; }
+
 void pcie_bus_configure_settings(struct pci_bus *bus);
 
 enum pcie_bus_config_types {
@@ -1405,6 +1422,11 @@ void pci_register_set_vga_state(arch_set_vga_state_t func);
 
 #else /* CONFIG_PCI is not enabled */
 
+static inline void pci_set_flags(int flags) { }
+static inline void pci_add_flags(int flags) { }
+static inline void pci_clear_flags(int flags) { }
+static inline int pci_has_flag(int flag) { return 0; }
+
 /*
  *  If the system does not have PCI, clearly these return errors.  Define
  *  these as simple inline functions to avoid hair in drivers.



From bhelgaas at google.com  Tue Feb  2 11:38:42 2016
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Tue, 02 Feb 2016 13:38:42 -0600
Subject: [PATCH 2/5] PCI: Remove includes of empty asm-generic/pci-bridge.h
In-Reply-To: <20160202193026.9258.7573.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20160202193026.9258.7573.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <20160202193841.9258.9882.stgit@bhelgaas-glaptop2.roam.corp.google.com>

include/asm-generic/pci-bridge.h is now empty, so remove every #include of
it.

Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
---
 arch/alpha/include/asm/pci.h          |    1 -
 arch/arm/include/asm/pci.h            |    3 ---
 arch/arm64/include/asm/pci.h          |    1 -
 arch/mips/include/asm/pci.h           |    1 -
 arch/powerpc/include/asm/pci-bridge.h |    1 -
 arch/unicore32/include/asm/pci.h      |    2 --
 arch/x86/pci/common.c                 |    1 -
 drivers/of/of_pci.c                   |    1 -
 drivers/pci/pci.c                     |    1 -
 drivers/pci/probe.c                   |    1 -
 drivers/pci/setup-bus.c               |    1 -
 11 files changed, 14 deletions(-)

diff --git a/arch/alpha/include/asm/pci.h b/arch/alpha/include/asm/pci.h
index 98f2eee..75d8865 100644
--- a/arch/alpha/include/asm/pci.h
+++ b/arch/alpha/include/asm/pci.h
@@ -7,7 +7,6 @@
 #include <linux/dma-mapping.h>
 #include <linux/scatterlist.h>
 #include <asm/machvec.h>
-#include <asm-generic/pci-bridge.h>
 
 /*
  * The following structure is used to manage multiple PCI busses.
diff --git a/arch/arm/include/asm/pci.h b/arch/arm/include/asm/pci.h
index a563544..d7de19a 100644
--- a/arch/arm/include/asm/pci.h
+++ b/arch/arm/include/asm/pci.h
@@ -3,8 +3,6 @@
 
 #ifdef __KERNEL__
 #include <asm-generic/pci-dma-compat.h>
-#include <asm-generic/pci-bridge.h>
-
 #include <asm/mach/pci.h> /* for pci_sys_data */
 
 extern unsigned long pcibios_min_io;
@@ -41,5 +39,4 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
 }
 
 #endif /* __KERNEL__ */
- 
 #endif
diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
index b008a72..f75b04e 100644
--- a/arch/arm64/include/asm/pci.h
+++ b/arch/arm64/include/asm/pci.h
@@ -7,7 +7,6 @@
 #include <linux/dma-mapping.h>
 
 #include <asm/io.h>
-#include <asm-generic/pci-bridge.h>
 #include <asm-generic/pci-dma-compat.h>
 
 #define PCIBIOS_MIN_IO		0x1000
diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/asm/pci.h
index 98c31e5..108d193 100644
--- a/arch/mips/include/asm/pci.h
+++ b/arch/mips/include/asm/pci.h
@@ -102,7 +102,6 @@ static inline void pci_resource_to_user(const struct pci_dev *dev, int bar,
 #include <linux/scatterlist.h>
 #include <linux/string.h>
 #include <asm/io.h>
-#include <asm-generic/pci-bridge.h>
 
 struct pci_dev;
 
diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index 54843ca..78968c1 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -10,7 +10,6 @@
 #include <linux/pci.h>
 #include <linux/list.h>
 #include <linux/ioport.h>
-#include <asm-generic/pci-bridge.h>
 
 struct device_node;
 
diff --git a/arch/unicore32/include/asm/pci.h b/arch/unicore32/include/asm/pci.h
index 38b3f37..eb9dcce 100644
--- a/arch/unicore32/include/asm/pci.h
+++ b/arch/unicore32/include/asm/pci.h
@@ -14,7 +14,6 @@
 
 #ifdef __KERNEL__
 #include <asm-generic/pci-dma-compat.h>
-#include <asm-generic/pci-bridge.h>
 #include <asm-generic/pci.h>
 #include <mach/hardware.h> /* for PCIBIOS_MIN_* */
 
@@ -23,5 +22,4 @@ extern int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma,
 	enum pci_mmap_state mmap_state, int write_combine);
 
 #endif /* __KERNEL__ */
-
 #endif
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 2879efc..b4a9f23 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -12,7 +12,6 @@
 #include <linux/dmi.h>
 #include <linux/slab.h>
 
-#include <asm-generic/pci-bridge.h>
 #include <asm/acpi.h>
 #include <asm/segment.h>
 #include <asm/io.h>
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index b1449f7..13f4fed 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -5,7 +5,6 @@
 #include <linux/of_device.h>
 #include <linux/of_pci.h>
 #include <linux/slab.h>
-#include <asm-generic/pci-bridge.h>
 
 static inline int __of_pci_pci_compare(struct device_node *node,
 				       unsigned int data)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 602eb42..64c0a12 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -25,7 +25,6 @@
 #include <linux/device.h>
 #include <linux/pm_runtime.h>
 #include <linux/pci_hotplug.h>
-#include <asm-generic/pci-bridge.h>
 #include <asm/setup.h>
 #include <linux/aer.h>
 #include "pci.h"
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ead1ac1..5eb378f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -15,7 +15,6 @@
 #include <linux/pci-aspm.h>
 #include <linux/aer.h>
 #include <linux/acpi.h>
-#include <asm-generic/pci-bridge.h>
 #include "pci.h"
 
 #define CARDBUS_LATENCY_TIMER	176	/* secondary latency timer */
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 7796d0a..55641a3 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -25,7 +25,6 @@
 #include <linux/ioport.h>
 #include <linux/cache.h>
 #include <linux/slab.h>
-#include <asm-generic/pci-bridge.h>
 #include "pci.h"
 
 unsigned int pci_flags;



From bhelgaas at google.com  Tue Feb  2 11:38:49 2016
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Tue, 02 Feb 2016 13:38:49 -0600
Subject: [PATCH 3/5] ARM64: PCI: Remove generated include of
 asm-generic/pci-bridge.h
In-Reply-To: <20160202193026.9258.7573.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20160202193026.9258.7573.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <20160202193849.9258.63617.stgit@bhelgaas-glaptop2.roam.corp.google.com>

arm64 generates asm/pci-bridge.h, which merely includes the now-empty
asm-generic/pci-bridge.h.  Stop generating asm/pci-bridge.h, and stop
including it.

Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
---
 arch/arm64/include/asm/Kbuild |    3 ---
 arch/arm64/kernel/pci.c       |    2 --
 2 files changed, 5 deletions(-)

diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index 70fd9ff..cff532a 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -1,5 +1,3 @@
-
-
 generic-y += bug.h
 generic-y += bugs.h
 generic-y += checksum.h
@@ -31,7 +29,6 @@ generic-y += msgbuf.h
 generic-y += msi.h
 generic-y += mutex.h
 generic-y += pci.h
-generic-y += pci-bridge.h
 generic-y += poll.h
 generic-y += preempt.h
 generic-y += resource.h
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index b3d098b..c72de66 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -19,8 +19,6 @@
 #include <linux/of_platform.h>
 #include <linux/slab.h>
 
-#include <asm/pci-bridge.h>
-
 /*
  * Called after each bus is probed, but before its children are examined
  */



From broonie at kernel.org  Tue Feb  2 11:38:39 2016
From: broonie at kernel.org (Mark Brown)
Date: Tue, 2 Feb 2016 19:38:39 +0000
Subject: [PATCH V4 2/2] regulator: mt6323: Add support for MT6323 regulator
In-Reply-To: <1454069479.10861.30.camel@mtksdaap41>
References: <1453896059-44589-1-git-send-email-blogic@openwrt.org>
 <1453896059-44589-2-git-send-email-blogic@openwrt.org>
 <20160127144105.GQ6042@sirena.org.uk>
 <56AA5A5C.9080402@openwrt.org>
 <20160128231306.GD4130@sirena.org.uk>
 <1454061134.10861.14.camel@mtksdaap41>
 <20160129112717.GP4130@sirena.org.uk>
 <1454069479.10861.30.camel@mtksdaap41>
Message-ID: <20160202193839.GX4455@sirena.org.uk>

On Fri, Jan 29, 2016 at 08:11:19PM +0800, menghui lin wrote:
> On Fri, 2016-01-29 at 12:27 +0100, Mark Brown wrote:

> > None of this is answering my question - I know what the current API is,
> > describing it doesn't tell me about actual users or how they are able to
> > sensibly use the interface.  Bear in mind that the definitions of the
> > various modes are all relative and what one device thinks is high usage
> > may be low usage for another device.

> Assuming valid_modes_mask and initial_mode are specified, a possible
> way to modify regulator_set_mode() is to allow mode change only if the
> regulator is controlled exclusively by a certain consumer or the
> requested mode provides stronger power capability than current mode.
> Here I assume that power capability fast > normal > idle > standby.

How does the driver know if it needs to change the mode (ie, how can it
tell if the current mode is inadequate) and surely if we can only change
in one direction this isn't terribly useful?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/ef0615f7/attachment.sig>

From bhelgaas at google.com  Tue Feb  2 11:38:56 2016
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Tue, 02 Feb 2016 13:38:56 -0600
Subject: [PATCH 4/5] PCI: Remove empty asm-generic/pci-bridge.h
In-Reply-To: <20160202193026.9258.7573.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20160202193026.9258.7573.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <20160202193855.9258.11522.stgit@bhelgaas-glaptop2.roam.corp.google.com>

include/asm-generic/pci-bridge.h is empty, and nobody includes it, so
remove it.

Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
---
 include/asm-generic/pci-bridge.h |    9 ---------
 1 file changed, 9 deletions(-)
 delete mode 100644 include/asm-generic/pci-bridge.h

diff --git a/include/asm-generic/pci-bridge.h b/include/asm-generic/pci-bridge.h
deleted file mode 100644
index 1b1d82f..0000000
--- a/include/asm-generic/pci-bridge.h
+++ /dev/null
@@ -1,9 +0,0 @@
-/*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-#ifndef _ASM_GENERIC_PCI_BRIDGE_H
-#define _ASM_GENERIC_PCI_BRIDGE_H
-#endif	/* _ASM_GENERIC_PCI_BRIDGE_H */



From bhelgaas at google.com  Tue Feb  2 11:39:02 2016
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Tue, 02 Feb 2016 13:39:02 -0600
Subject: [PATCH 5/5] PCI: Remove includes of asm/pci-bridge.h
In-Reply-To: <20160202193026.9258.7573.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20160202193026.9258.7573.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <20160202193902.9258.7816.stgit@bhelgaas-glaptop2.roam.corp.google.com>

Drivers should include asm/pci-bridge.h only when they need the arch-
specific things provided there.  Outside of the arch/ directories, the only
drivers that actually need things provided by asm/pci-bridge.h are the
powerpc RPA hotplug drivers in drivers/pci/hotplug/rpa*.

Remove the includes of asm/pci-bridge.h from the other drivers, adding an
include of linux/pci.h if necessary.

Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
---
 drivers/ata/pata_macio.c                   |    2 +-
 drivers/char/agp/uninorth-agp.c            |    1 -
 drivers/gpu/drm/radeon/radeon_combios.c    |    1 -
 drivers/ide/pdc202xx_new.c                 |    1 -
 drivers/ide/pmac.c                         |    1 -
 drivers/macintosh/macio_asic.c             |    1 -
 drivers/misc/cxl/pci.c                     |    1 -
 drivers/net/ethernet/sun/sungem.c          |    1 -
 drivers/net/ethernet/toshiba/spider_net.c  |    1 -
 drivers/scsi/mac53c94.c                    |    2 +-
 drivers/scsi/mesh.c                        |    2 +-
 drivers/usb/core/hcd-pci.c                 |    1 -
 drivers/video/fbdev/aty/aty128fb.c         |    1 -
 drivers/video/fbdev/aty/radeon_base.c      |    1 -
 drivers/video/fbdev/imsttfb.c              |    1 -
 drivers/video/fbdev/matrox/matroxfb_base.h |    1 -
 drivers/video/fbdev/offb.c                 |    4 ----
 sound/ppc/pmac.c                           |    1 -
 18 files changed, 3 insertions(+), 21 deletions(-)

diff --git a/drivers/ata/pata_macio.c b/drivers/ata/pata_macio.c
index e3d4b05..e347e7a 100644
--- a/drivers/ata/pata_macio.c
+++ b/drivers/ata/pata_macio.c
@@ -22,6 +22,7 @@
 #include <linux/scatterlist.h>
 #include <linux/of.h>
 #include <linux/gfp.h>
+#include <linux/pci.h>
 
 #include <scsi/scsi.h>
 #include <scsi/scsi_host.h>
@@ -30,7 +31,6 @@
 #include <asm/macio.h>
 #include <asm/io.h>
 #include <asm/dbdma.h>
-#include <asm/pci-bridge.h>
 #include <asm/machdep.h>
 #include <asm/pmac_feature.h>
 #include <asm/mediabay.h>
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index 0575544..fdced54 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -10,7 +10,6 @@
 #include <linux/delay.h>
 #include <linux/vmalloc.h>
 #include <asm/uninorth.h>
-#include <asm/pci-bridge.h>
 #include <asm/prom.h>
 #include <asm/pmac_feature.h>
 #include "agp.h"
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c b/drivers/gpu/drm/radeon/radeon_combios.c
index a9b01bc..432480f 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -34,7 +34,6 @@
 #include <asm/machdep.h>
 #include <asm/pmac_feature.h>
 #include <asm/prom.h>
-#include <asm/pci-bridge.h>
 #endif /* CONFIG_PPC_PMAC */
 
 /* from radeon_legacy_encoder.c */
diff --git a/drivers/ide/pdc202xx_new.c b/drivers/ide/pdc202xx_new.c
index 9ad014a..b33646b 100644
--- a/drivers/ide/pdc202xx_new.c
+++ b/drivers/ide/pdc202xx_new.c
@@ -28,7 +28,6 @@
 
 #ifdef CONFIG_PPC_PMAC
 #include <asm/prom.h>
-#include <asm/pci-bridge.h>
 #endif
 
 #define DRV_NAME "pdc202xx_new"
diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
index 96a3452..7f0434f 100644
--- a/drivers/ide/pmac.c
+++ b/drivers/ide/pmac.c
@@ -40,7 +40,6 @@
 #include <asm/io.h>
 #include <asm/dbdma.h>
 #include <asm/ide.h>
-#include <asm/pci-bridge.h>
 #include <asm/machdep.h>
 #include <asm/pmac_feature.h>
 #include <asm/sections.h>
diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
index 4f12c6f..b6819f0 100644
--- a/drivers/macintosh/macio_asic.c
+++ b/drivers/macintosh/macio_asic.c
@@ -31,7 +31,6 @@
 #include <asm/macio.h>
 #include <asm/pmac_feature.h>
 #include <asm/prom.h>
-#include <asm/pci-bridge.h>
 
 #undef DEBUG
 
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 4c1903f..a214032 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -19,7 +19,6 @@
 #include <linux/delay.h>
 #include <asm/opal.h>
 #include <asm/msi_bitmap.h>
-#include <asm/pci-bridge.h> /* for struct pci_controller */
 #include <asm/pnv-pci.h>
 #include <asm/io.h>
 
diff --git a/drivers/net/ethernet/sun/sungem.c b/drivers/net/ethernet/sun/sungem.c
index e23a642..2437227 100644
--- a/drivers/net/ethernet/sun/sungem.c
+++ b/drivers/net/ethernet/sun/sungem.c
@@ -51,7 +51,6 @@
 #endif
 
 #ifdef CONFIG_PPC_PMAC
-#include <asm/pci-bridge.h>
 #include <asm/prom.h>
 #include <asm/machdep.h>
 #include <asm/pmac_feature.h>
diff --git a/drivers/net/ethernet/toshiba/spider_net.c b/drivers/net/ethernet/toshiba/spider_net.c
index 3c54a2c..6761027 100644
--- a/drivers/net/ethernet/toshiba/spider_net.c
+++ b/drivers/net/ethernet/toshiba/spider_net.c
@@ -48,7 +48,6 @@
 #include <linux/wait.h>
 #include <linux/workqueue.h>
 #include <linux/bitops.h>
-#include <asm/pci-bridge.h>
 #include <net/checksum.h>
 
 #include "spider_net.h"
diff --git a/drivers/scsi/mac53c94.c b/drivers/scsi/mac53c94.c
index 1412266..a6682c5 100644
--- a/drivers/scsi/mac53c94.c
+++ b/drivers/scsi/mac53c94.c
@@ -18,11 +18,11 @@
 #include <linux/spinlock.h>
 #include <linux/interrupt.h>
 #include <linux/module.h>
+#include <linux/pci.h>
 #include <asm/dbdma.h>
 #include <asm/io.h>
 #include <asm/pgtable.h>
 #include <asm/prom.h>
-#include <asm/pci-bridge.h>
 #include <asm/macio.h>
 
 #include <scsi/scsi.h>
diff --git a/drivers/scsi/mesh.c b/drivers/scsi/mesh.c
index 555367f..1753e42 100644
--- a/drivers/scsi/mesh.c
+++ b/drivers/scsi/mesh.c
@@ -29,6 +29,7 @@
 #include <linux/interrupt.h>
 #include <linux/reboot.h>
 #include <linux/spinlock.h>
+#include <linux/pci.h>
 #include <asm/dbdma.h>
 #include <asm/io.h>
 #include <asm/pgtable.h>
@@ -38,7 +39,6 @@
 #include <asm/processor.h>
 #include <asm/machdep.h>
 #include <asm/pmac_feature.h>
-#include <asm/pci-bridge.h>
 #include <asm/macio.h>
 
 #include <scsi/scsi.h>
diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index 9eb1cff..c3640f8 100644
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -28,7 +28,6 @@
 #ifdef CONFIG_PPC_PMAC
 #include <asm/machdep.h>
 #include <asm/pmac_feature.h>
-#include <asm/pci-bridge.h>
 #include <asm/prom.h>
 #endif
 
diff --git a/drivers/video/fbdev/aty/aty128fb.c b/drivers/video/fbdev/aty/aty128fb.c
index c42ce2f..0a46268 100644
--- a/drivers/video/fbdev/aty/aty128fb.c
+++ b/drivers/video/fbdev/aty/aty128fb.c
@@ -68,7 +68,6 @@
 #include <asm/machdep.h>
 #include <asm/pmac_feature.h>
 #include <asm/prom.h>
-#include <asm/pci-bridge.h>
 #include "../macmodes.h"
 #endif
 
diff --git a/drivers/video/fbdev/aty/radeon_base.c b/drivers/video/fbdev/aty/radeon_base.c
index ce0b1d0..218339a 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -76,7 +76,6 @@
 
 #ifdef CONFIG_PPC
 
-#include <asm/pci-bridge.h>
 #include "../macmodes.h"
 
 #ifdef CONFIG_BOOTX_TEXT
diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c
index 9b167f7..4363c64 100644
--- a/drivers/video/fbdev/imsttfb.c
+++ b/drivers/video/fbdev/imsttfb.c
@@ -33,7 +33,6 @@
 #if defined(CONFIG_PPC)
 #include <linux/nvram.h>
 #include <asm/prom.h>
-#include <asm/pci-bridge.h>
 #include "macmodes.h"
 #endif
 
diff --git a/drivers/video/fbdev/matrox/matroxfb_base.h b/drivers/video/fbdev/matrox/matroxfb_base.h
index 09b02cd..7a90ea2 100644
--- a/drivers/video/fbdev/matrox/matroxfb_base.h
+++ b/drivers/video/fbdev/matrox/matroxfb_base.h
@@ -47,7 +47,6 @@
 
 #if defined(CONFIG_PPC_PMAC)
 #include <asm/prom.h>
-#include <asm/pci-bridge.h>
 #include "../macmodes.h"
 #endif
 
diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index 43a0a52..fb60a8f 100644
--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -28,10 +28,6 @@
 #include <linux/pci.h>
 #include <asm/io.h>
 
-#ifdef CONFIG_PPC64
-#include <asm/pci-bridge.h>
-#endif
-
 #ifdef CONFIG_PPC32
 #include <asm/bootx.h>
 #endif
diff --git a/sound/ppc/pmac.c b/sound/ppc/pmac.c
index 0095a80..a5843fc 100644
--- a/sound/ppc/pmac.c
+++ b/sound/ppc/pmac.c
@@ -34,7 +34,6 @@
 #include "pmac.h"
 #include <sound/pcm_params.h>
 #include <asm/pmac_feature.h>
-#include <asm/pci-bridge.h>
 
 
 /* fixed frequency table for awacs, screamer, burgundy, DACA (44100 max) */



From akpm at linux-foundation.org  Tue Feb  2 11:39:08 2016
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 2 Feb 2016 11:39:08 -0800
Subject: [PATCH] arm64: asm: Explicitly include linux/personality.h in
 asm/page.h
In-Reply-To: <20160202164817.GM10166@arm.com>
References: <1453983508-20410-1-git-send-email-broonie@kernel.org>
 <20160128124417.GE6078@sirena.org.uk>
 <20160128141425.GA20099@e104818-lin.cambridge.arm.com>
 <20160128144610.GA2380@ulmo> <20160202164817.GM10166@arm.com>
Message-ID: <20160202113908.d699440a0617006c3b987129@linux-foundation.org>

On Tue, 2 Feb 2016 16:48:18 +0000 Will Deacon <will.deacon at arm.com> wrote:

> On Thu, Jan 28, 2016 at 03:46:10PM +0100, Thierry Reding wrote:
> > On Thu, Jan 28, 2016 at 02:14:26PM +0000, Catalin Marinas wrote:
> > > On Thu, Jan 28, 2016 at 12:44:17PM +0000, Mark Brown wrote:
> > > > On Thu, Jan 28, 2016 at 12:18:28PM +0000, Mark Brown wrote:
> > > > > asm/page.h uses READ_IMPLIES_EXEC from linux/personality.h but does not
> > > > > explicitly include it causing build failures in -next where whatever was
> > > > > causing it to be implicitly included has changed to remove that
> > > > > inclusion.  Add an explicit inclusion to fix this.
> > > > 
> > > > Argh, sorry - this causes problems further down the line with linking
> > > > vdso.lds due to enums getting into the linker script and upsetting the
> > > > linker (there are several compile errors today so it was masked).
> > > 
> > > You can move the include further down after the #ifndef __ASSEMBLY__
> > 
> > Indeed, here's what I've been using to successfully complete ARM64 test
> > builds:
> > 
> > --- >8 ---
> > diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> > index 9b2f5a9d019d..ae615b9d9a55 100644
> > --- a/arch/arm64/include/asm/page.h
> > +++ b/arch/arm64/include/asm/page.h
> > @@ -39,6 +39,7 @@
> >  
> >  #ifndef __ASSEMBLY__
> >  
> > +#include <linux/personality.h> /* for READ_IMPLIES_EXEC */
> >  #include <asm/pgtable-types.h>
> >  
> >  extern void __cpu_clear_user_page(void *p, unsigned long user);
> 
> I see this has ended up in linux-next, but I'm not sure whether or not
> it's actually queued someplace for 4.6. Any ideas?
> 
> If not, I can take it (or some derivative) through arm64 as a fix for
> -rc3.

It's not actually needed any more because Kirill has tweaked the patch
which triggered this build error.

However I think the change still makes sense as a standalone thing -
your call.


From: Andrew Morton <akpm at linux-foundation.org>
Subject: arm: arch/arm/include/asm/page.h needs personality.h

VM_DATA_DEFAULT_FLAGS uses READ_IMPLIES_EXEC, so page.h should include
personality.h to provide this.

This was needed for "mm: warn about VmData over RLIMIT_DATA".

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Konstantin Khlebnikov <koct9i at gmail.com>
Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
---

 arch/arm/include/asm/page.h |    2 ++
 1 file changed, 2 insertions(+)

diff -puN arch/arm/include/asm/page.h~arm-arch-arm-include-asm-pageh-needs-personalityh arch/arm/include/asm/page.h
--- a/arch/arm/include/asm/page.h~arm-arch-arm-include-asm-pageh-needs-personalityh
+++ a/arch/arm/include/asm/page.h
@@ -17,6 +17,8 @@
 
 #ifndef __ASSEMBLY__
 
+#include <linux/personality.h>	/* For READ_IMPLIES_EXEC */
+
 #ifndef CONFIG_MMU
 
 #include <asm/page-nommu.h>
_



From broonie at kernel.org  Tue Feb  2 11:39:13 2016
From: broonie at kernel.org (Mark Brown)
Date: Tue, 2 Feb 2016 19:39:13 +0000
Subject: [PATCH V4 2/2] regulator: mt6323: Add support for MT6323 regulator
In-Reply-To: <1454069479.10861.30.camel@mtksdaap41>
References: <1453896059-44589-1-git-send-email-blogic@openwrt.org>
 <1453896059-44589-2-git-send-email-blogic@openwrt.org>
 <20160127144105.GQ6042@sirena.org.uk>
 <56AA5A5C.9080402@openwrt.org>
 <20160128231306.GD4130@sirena.org.uk>
 <1454061134.10861.14.camel@mtksdaap41>
 <20160129112717.GP4130@sirena.org.uk>
 <1454069479.10861.30.camel@mtksdaap41>
Message-ID: <20160202193913.GY4455@sirena.org.uk>

On Fri, Jan 29, 2016 at 08:11:19PM +0800, menghui lin wrote:
> On Fri, 2016-01-29 at 12:27 +0100, Mark Brown wrote:

> > None of this is answering my question - I know what the current API is,
> > describing it doesn't tell me about actual users or how they are able to
> > sensibly use the interface.  Bear in mind that the definitions of the
> > various modes are all relative and what one device thinks is high usage
> > may be low usage for another device.

> Assuming valid_modes_mask and initial_mode are specified, a possible
> way to modify regulator_set_mode() is to allow mode change only if the
> regulator is controlled exclusively by a certain consumer or the
> requested mode provides stronger power capability than current mode.
> Here I assume that power capability fast > normal > idle > standby.

...and I also note that the above *still* doesn't answer my questions
above.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/89866e4e/attachment.sig>

From sboyd at codeaurora.org  Tue Feb  2 11:47:13 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 2 Feb 2016 11:47:13 -0800
Subject: [PATCH] clk: vt8500: don't return possibly uninitialized data
In-Reply-To: <2210116.QsPesySkh0@wuerfel>
References: <4790407.6zgSQCdsSB@wuerfel> <20160202011545.GG4848@codeaurora.org>
 <2210116.QsPesySkh0@wuerfel>
Message-ID: <20160202194713.GN4848@codeaurora.org>

On 02/02, Arnd Bergmann wrote:
> On Monday 01 February 2016 17:15:45 Stephen Boyd wrote:
> 
> I see what you mean now. I checked different gcc versions, and with my patch I get
> the warnings for 4.6 through 4.9, but not for 5.x.
> 
> In general, I tried to only address warnings I still see with newer gcc version,
> as they are better about false positives. Do you think it's ok to take the
> patch as is then? Otherwise we probably have to add fake initializations which
> would shut up the warnings but not help with the code quality.
> 

Sure. I was hoping something could be done to restructure the
code to make it easier for the compiler to figure out the
variables would be initialized. But you're the one who's sending
the patch to silence them so if you're satisfied I'm not going to
spend too much time on this.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From heiko.carstens at de.ibm.com  Tue Feb  2 11:54:34 2016
From: heiko.carstens at de.ibm.com (Heiko Carstens)
Date: Tue, 2 Feb 2016 20:54:34 +0100
Subject: [PATCH 1/5] all: s390: move wrapper infrastructure to generic
 headers
In-Reply-To: <20160202160826.GF3990@osiris>
References: <1453741047-5498-1-git-send-email-ynorov@caviumnetworks.com>
 <1453741047-5498-2-git-send-email-ynorov@caviumnetworks.com>
 <20160128121618.GB5418@osiris> <20160128163109.GA8529@yury-N73SV>
 <20160201114251.GB973@yury-N73SV> <20160202073913.GB3990@osiris>
 <20160202154331.GA3003@yury-N73SV> <20160202160826.GF3990@osiris>
Message-ID: <20160202195434.GA3397@osiris>

Hi Yury,

On Tue, Feb 02, 2016 at 05:08:26PM +0100, Heiko Carstens wrote:
> See e.g. 485d52768685 ("sys_personality: change sys_personality() to accept
> "unsigned int" instead of u_long") would have been a candidate which could
> silently break architectures which need compat wrappers.

Ok, this example is of course wrong. But now I can claim that also somebody
who should know better makes these mistakes.. :)

> > I don't know much about s390 specifics. Maybe because of that I do not
> > understand completely your worries. I'm OK with both 1st and 2nd
> > version, but I'd choose 2nd one because it allows inlines, and we
> > don't need the compat_wrapper.c.
> 
> It would be only nicer if we can guarentee correctness all the time. That
> being said I'm about to revert my own commit :)
> 
> So if you want to go without compat_wrapper.c then we should have a
> solution which will do the right thing all the time without that a system
> call author has to know about the sign and zero extension issue some
> architectures face. It _will_ go wrong.

So I think I can summarize my point to: if you can enforce correctness, why
shouldn't you do it if the performance impact is only a single instruction.

However I'll try to write an addon patch to your patch series. Maybe we can
still get rid of compat_wrapper.c in a way which makes both of us happy.
Also.. the idea with the alias names for compat wrappers does seem to have
the disadvantage that it will pollute /proc/kallsyms for example.

Anyway, I'm not sure if I will be able to come up with something this week
though.



From arnd at arndb.de  Tue Feb  2 12:00:29 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 02 Feb 2016 21:00:29 +0100
Subject: [PATCH] clk: vt8500: don't return possibly uninitialized data
In-Reply-To: <20160202194713.GN4848@codeaurora.org>
References: <4790407.6zgSQCdsSB@wuerfel> <2210116.QsPesySkh0@wuerfel>
 <20160202194713.GN4848@codeaurora.org>
Message-ID: <2326140.nrZ9Ej2PSt@wuerfel>

On Tuesday 02 February 2016 11:47:13 Stephen Boyd wrote:
> On 02/02, Arnd Bergmann wrote:
> > On Monday 01 February 2016 17:15:45 Stephen Boyd wrote:
> > 
> > I see what you mean now. I checked different gcc versions, and with my patch I get
> > the warnings for 4.6 through 4.9, but not for 5.x.
> > 
> > In general, I tried to only address warnings I still see with newer gcc version,
> > as they are better about false positives. Do you think it's ok to take the
> > patch as is then? Otherwise we probably have to add fake initializations which
> > would shut up the warnings but not help with the code quality.
> > 
> 
> Sure. I was hoping something could be done to restructure the
> code to make it easier for the compiler to figure out the
> variables would be initialized. But you're the one who's sending
> the patch to silence them so if you're satisfied I'm not going to
> spend too much time on this.
> 

Ok, thanks!

Note that this one patch was for a real bug involving undefined
behavior that is now fixed.

	Arnd


From christoffer.dall at linaro.org  Tue Feb  2 12:07:20 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 2 Feb 2016 21:07:20 +0100
Subject: [PATCH v2 10/21] arm64: KVM: VHE: Split save/restore of sysregs
 shared between EL1 and EL2
In-Reply-To: <56B0D720.9000901@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-11-git-send-email-marc.zyngier@arm.com>
 <20160201135438.GL1478@cbox> <56B07ADD.60300@arm.com>
 <20160202154645.GE6190@cbox> <56B0D720.9000901@arm.com>
Message-ID: <20160202200720.GH6190@cbox>

On Tue, Feb 02, 2016 at 04:19:44PM +0000, Marc Zyngier wrote:
> On 02/02/16 15:46, Christoffer Dall wrote:
> > On Tue, Feb 02, 2016 at 09:46:05AM +0000, Marc Zyngier wrote:
> >> On 01/02/16 13:54, Christoffer Dall wrote:
> >>> On Mon, Jan 25, 2016 at 03:53:44PM +0000, Marc Zyngier wrote:
> >>>> A handful of system registers are still shared between EL1 and EL2,
> >>>> even while using VHE. These are tpidr*_el[01], actlr_el1, sp0, elr,
> >>>> and spsr.
> >>>
> >>> So by shared registers you mean registers that do both have an EL0/1
> >>> version as well as an EL2 version, but where accesses aren't rewritten
> >>> transparently?
> >>
> >> No, I mean that these registers do *not* have a separate banked version.
> >> There is only a single set of registers, which have to be save/restored
> >> the old way.
> > 
> > huh, ARMv8 clearly specifies the existence of TPIDR_EL0, TPIDR_EL1, and
> > TPIDR_EL2, for example.
> > 
> > I cannot seem to find anywhere in the VHE spec that says that the
> > TPIDR_EL2 goes away.  I'm confused now.
> 
> Nothing goes away, but these registers do not get renamed either. For
> example, TPIDR_EL1 doesn't magically access TPIDR_EL2 when running at
> EL2+VHE, and there is no TPIDR_EL12 accessor either.
> 
> So TPIDR_EL1 is effectively "shared" between host and guest, and must be
> save/restored (note that the host kernel still uses TIPDR_EL1 even when
> running with VHE, and that KVM still uses TPIDR_EL2 to cache the current
> vcpu).
> 

ok, I can understand as long as we're saying a register is shared
between the host and the guest, but it was the "registers are shared
between EL1 and EL2" that threw me off.

> >>
> >>>
> >>> also, by sp0 do you mean sp_el0, and by elr you mean elr_el1, and by
> >>> spsr you mean spsr_el1 ?
> >>
> >> sp0 -> sp_el0 indeed. elr and spsr really are the guest PC and PSTATE,
> >> so I should really reword this commit message, it is utterly confusing.
> >>
> > I guess I don't understand the definition of a 'shared' register given
> > your comments here...
> 
> Does this make it clearer?
> 
yes.  You could change the host to path it when using VHE to use
TPIDR_EL2 if you wanted and store the vcpu pointer on the stack while
running the guest, but there's probably no real benefit of doing so.

I'll be shutting up now...

Thanks,
-Christoffer


From aaro.koskinen at iki.fi  Tue Feb  2 12:19:00 2016
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Tue, 2 Feb 2016 22:19:00 +0200
Subject: [PATCH v2] pinctrl: mvebu: fix num_settings in mpp group
 assignment
In-Reply-To: <1454366903-7038-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1453844952-28292-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1454366903-7038-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <20160202201900.GA1620@darkstar.musicnaut.iki.fi>

Hi,

On Mon, Feb 01, 2016 at 11:48:23PM +0100, Sebastian Hesselbarth wrote:
> When assigning mpp settings from static mpp modes to mpp groups,
> we do not want any groups that have no supported setting for a
> specific Kirkwood variant. However, when there is at least a
> single supported setting, we need to assign the number of all
> settings in this mode to grp->num_settings as we are reusing
> the static modes table.
> 
> Fixes: 0581b16b1840 ("pinctrl: mvebu: complain about missing group after checking variant")
> Reported-by: Aaro Koskinen <aaro.koskinen at iki.fi>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> --
> Changelog:
> v1->v2:
> - Chose a less intrusive fix by adding supp_settings variable
>   instead of looping over the settings twice.
> 
> Aaro, Linus,
> 
> I prefer this less intrusive fix in favor of v1.
> 
> @Aaro: Can you please test again?

Tested-by: Aaro Koskinen <aaro.koskinen at iki.fi>

A.

> 
> Cc: Aaro Koskinen <aaro.koskinen at iki.fi>
> Cc: Linus Walleij <linus.walleij at linaro.org>
> Cc: Gregory Clement <gregory.clement at free-electrons.com>
> Cc: Andrew Lunn <andrew at lunn.ch>
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>  drivers/pinctrl/mvebu/pinctrl-mvebu.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
> index e4d473811bb3..3ef798fac81b 100644
> --- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
> +++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
> @@ -666,16 +666,19 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
>  		struct mvebu_mpp_ctrl_setting *set = &mode->settings[0];
>  		struct mvebu_pinctrl_group *grp;
>  		unsigned num_settings;
> +		unsigned supp_settings;
>  
> -		for (num_settings = 0; ; set++) {
> +		for (num_settings = 0, supp_settings = 0; ; set++) {
>  			if (!set->name)
>  				break;
>  
> +			num_settings++;
> +
>  			/* skip unsupported settings for this variant */
>  			if (pctl->variant && !(pctl->variant & set->variant))
>  				continue;
>  
> -			num_settings++;
> +			supp_settings++;
>  
>  			/* find gpio/gpo/gpi settings */
>  			if (strcmp(set->name, "gpio") == 0)
> @@ -688,7 +691,7 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
>  		}
>  
>  		/* skip modes with no settings for this variant */
> -		if (!num_settings)
> +		if (!supp_settings)
>  			continue;
>  
>  		grp = mvebu_pinctrl_find_group_by_pid(pctl, mode->pid);
> -- 
> 2.1.4
> 


From ulf.hansson at linaro.org  Tue Feb  2 12:24:41 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 2 Feb 2016 21:24:41 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <Pine.LNX.4.44L0.1602021112320.1653-100000@iolanthe.rowland.org>
References: <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602021112320.1653-100000@iolanthe.rowland.org>
Message-ID: <CAPDyKFokWcLSCAh_TX-j-df_M1hN8Qw1gbQt--SyWccGCPiN5Q@mail.gmail.com>

[...]

>>
>> Your observations is correct. The hardware will be kept active
>> in-between the probe attempts (and thus also if probing fails).
>> Although, that's not a regression as that's the behaviour you get from
>> runtime PM, when drivers are implemented like omap_hsmmc.
>
> Perhaps this is what we should do.  If probing gets deferred a few
> times, doing runtime suspends and resumes in between will be a waste of
> time.

Then you will have to distinguish between -EPROBE_DEFER and other
errors, as I think leaving the device fully powered from a permanent
failed probe isn't very good.

Anyway, for sure it's doable by the driver, but let's try to focus on
the regression here for now.

>
>> Instead of the suggested approaches, I think the regression should be
>> fixed at the PM domain level (omap hwmod). I have attached a patch
>> below, please give it try as it's untested.
>>
>> To solve the other problem (allowing devices to become inactive
>> in-between at probe failures), I see two options (not treated as
>> regressions).
>> 1)
>> Change the behaviour of pm_runtime_put_sync(), to *not* respect the
>> autosuspend mode.
>> I think I prefer this option, as it seems like autosuspend should be
>> respected only via the asynchronous runtime PM APIs.
>
> ?  pm_runtime_put_sync() _already_ does not respect the autosuspend
> mode.  If you want to respect it, you have to call
> pm_runtime_put_sync_autosuspend() instead.

Then there's a bug in the runtime PM core.

>From Tony's regression report and from mine own local runtime PM test
driver, I can see that the device doesn't get RPM_SUSPENDED (the
->runtime_suspend() callback isn't called), even when the usage count
is zero - when pm_runtime_put_sync() is called.

To find the sequence of runtime PM commands, go ahead an have look in
the omap_hsmmc driver. The problem occurs when the driver bails out in
probe, when it receives -EPROBE_DEFER when fetching regulators.

I have some more data to share on this problem from my runtime PM test
driver. I will try my best to share it tomorrow.

>
>> 2)
>> Change the failing drivers, to before calling pm_runtime_put_sync()
>> also invoke pm_runtime_dont_use_autosusend(). Or other similar
>> approach.
>
> Given the above, this seems unnecessary.

Okay, so you are saying that the pm_runtime_put_sync() should idle the
device even if autosuspend is in use. That seems reasonable, I will
look into this problem.

Kind regards
Uffe


From ynorov at caviumnetworks.com  Tue Feb  2 12:41:56 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Tue, 2 Feb 2016 23:41:56 +0300
Subject: [PATCH 1/5] all: s390: move wrapper infrastructure to generic
 headers
In-Reply-To: <20160202195434.GA3397@osiris>
References: <1453741047-5498-1-git-send-email-ynorov@caviumnetworks.com>
 <1453741047-5498-2-git-send-email-ynorov@caviumnetworks.com>
 <20160128121618.GB5418@osiris> <20160128163109.GA8529@yury-N73SV>
 <20160201114251.GB973@yury-N73SV> <20160202073913.GB3990@osiris>
 <20160202154331.GA3003@yury-N73SV> <20160202160826.GF3990@osiris>
 <20160202195434.GA3397@osiris>
Message-ID: <20160202204156.GA27290@yury-N73SV>

On Tue, Feb 02, 2016 at 08:54:34PM +0100, Heiko Carstens wrote:
> Hi Yury,
> 
> On Tue, Feb 02, 2016 at 05:08:26PM +0100, Heiko Carstens wrote:
> > See e.g. 485d52768685 ("sys_personality: change sys_personality() to accept
> > "unsigned int" instead of u_long") would have been a candidate which could
> > silently break architectures which need compat wrappers.
> 
> Ok, this example is of course wrong. But now I can claim that also somebody
> who should know better makes these mistakes.. :)
> 

Yep, this is a bad example. :) Moreover, this patch is coming from year 2010,
and it shows how stable the syscall ABI is.

> > > I don't know much about s390 specifics. Maybe because of that I do not
> > > understand completely your worries. I'm OK with both 1st and 2nd
> > > version, but I'd choose 2nd one because it allows inlines, and we
> > > don't need the compat_wrapper.c.
> > 
> > It would be only nicer if we can guarentee correctness all the time. That
> > being said I'm about to revert my own commit :)
> > 
> > So if you want to go without compat_wrapper.c then we should have a
> > solution which will do the right thing all the time without that a system
> > call author has to know about the sign and zero extension issue some
> > architectures face. It _will_ go wrong.
> 
> So I think I can summarize my point to: if you can enforce correctness, why
> shouldn't you do it if the performance impact is only a single instruction.

For aarch64 it's 5 instructions. But what's more important (if ever),
another wrapper takes another i-cache line...
        <compat_SyS_ftruncate>:
        stp     x29, x30, [sp,#-16]!
        mov     x29, sp
        bl      d40 <do_sys_ftruncate.constprop.3>
        ldp     x29, x30, [sp],#16
        ret

> 
> However I'll try to write an addon patch to your patch series. Maybe we can
> still get rid of compat_wrapper.c in a way which makes both of us happy.
> Also.. the idea with the alias names for compat wrappers does seem to have
> the disadvantage that it will pollute /proc/kallsyms for example.
> 
> Anyway, I'm not sure if I will be able to come up with something this week
> though.

Great, I'm looking forward...

My point is. Syscall ABI is so stable and so important that too much
people are involved in development and testing of it. So automatic
checks are almost useless, as all bugs will be found during
development and review. I think, community is able to pay enough
attention to review a couple of such patches per decade.
But I'm OK with some automatic checker, if it will be :
 - not too complicated, as complex code makes bugs by itself;
 - not too expensive;
 - not too ugly (my one is definitely ugly).


From ulf.hansson at linaro.org  Tue Feb  2 12:47:20 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 2 Feb 2016 21:47:20 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160202163536.GU19432@atomide.com>
References: <20160201232833.GR19432@atomide.com>
 <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>
 <20160202030533.GT19432@atomide.com>
 <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>
 <20160202163536.GU19432@atomide.com>
Message-ID: <CAPDyKFosQjkHDVSvy67+hstjjFseXQP5WYXrJE19GgVFYJ099w@mail.gmail.com>

On 2 February 2016 at 17:35, Tony Lindgren <tony at atomide.com> wrote:
> Hi,
>
> * Ulf Hansson <ulf.hansson at linaro.org> [160202 02:43]:
>>
>> For the omap_hsmmc and likely also other omap drivers, which needs more
>> than one attempt to ->probe() (returning -EPROBE_DEFER), this commit
>> causes a regression at the PM domain level (omap hwmod).
>>
>> The reason is that the drivers don't put back the device into low power
>> state while bailing out in ->probe to return -EPROBE_DEFER. This leads to
>> that pm_runtime_reinit() in driver core, is re-initializing the runtime PM
>> status from RPM_ACTIVE to RPM_SUSPENDED.
>
> Yup, that's the bug here. It seems that we never call the runtime_suspend
> callback at the end of a first failed device driver probe if the driver
> has set pm_runtime_use_autosuspend. Only rpm_idle runtime_idle callback
> gets called. So the device stays on.
>
> This does not happen if pm_runtime_dont_use_autosuspend() is added to
> the end of the device driver probe before pm_runtime_put_sync().

Thanks! It then confirms the second option I proposed.

>
>> The next ->probe() attempt then triggers the ->runtime_resume() callback
>> to be invoked, which means this happens two times in a row. At the PM
>> domain level (omap hwmod) this is being treated as an error and thus the
>> runtime PM status of the device isn't correctly synchronized with the
>> runtime PM core.
>
> That's a valid error though, let's not remove it. The reason why we
> call runtime_resume() twice is because runtime_suspend callback never
> gets called like I explain above.

This isn't an error, it's just a hickup in the synchronization of the
runtime PM status.

Very similar what happens at the first probe, when the driver core has
initialized the runtime PM status to RPM_SUSPENDED at the device
registration.

To me, it's the responsible of the PM domain to *help* with the
synchronization, not prevent it as it currently does.

>
>> In the end, ->probe() anyway succeeds (as the driver don't checks the
>> error code from the runtime PM APIs), but results in that the PM domain
>> always stays powered on. This because of the runtime PM core believes the
>> device is RPM_SUSPENDED.
>
> FYI, the following allows runtime_suspend callback to get called at the
> end of a failed driver probe so the hardware state matches the PM runtime
> state. Need to debug more.
>
> Regards,
>
> Tony
>
> 8< ------------
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2232,6 +2232,7 @@ err_irq:
>                 dma_release_channel(host->tx_chan);
>         if (host->rx_chan)
>                 dma_release_channel(host->rx_chan);
> +       pm_runtime_dont_use_autosuspend(host->dev);

It's good know this works, although do you intend to fix this sequence
for all omap drivers/devices that's part of the hwmod PM domain?

I haven't checked the number of drivers this would affect, but I
imagine there could be quite many with similar behaviour and thus may
suffer from the same issue.

Of course the regression is only noticed for those returning
-EPROBE_DEFER, which might not be that many, but it seems fragile to
rely on this when going forward. All related drivers then needs to be
fixed.

>         pm_runtime_put_sync(host->dev);
>         pm_runtime_disable(host->dev);
>         if (host->dbclk)

Could you please test my version 2 of the patch I attached earlier. I
still believe it's the best way to solve the regression, if it works
of course. :-)

Kind regards
Uffe


From linus.walleij at linaro.org  Tue Feb  2 12:47:39 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue,  2 Feb 2016 21:47:39 +0100
Subject: [PATCH] video: ARM CLCD: runtime check for Versatile
Message-ID: <1454446059-30526-1-git-send-email-linus.walleij@linaro.org>

The current compile-time check for inversed IENB/CNTL does not
work in multiplatform boots: as soon as versatile is included
in the build, the IENB/CNTL is switched and breaks graphics.
Convert this to a runtime switch.

Cc: stable at vger.kernel.org
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Fixes: a29da136de34 ("ARM: versatile: convert to multi-platform")
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/video/fbdev/amba-clcd.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 9362424c2340..f9ef06d0cd48 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -440,13 +440,14 @@ static int clcdfb_register(struct clcd_fb *fb)
 		fb->off_ienb = CLCD_PL111_IENB;
 		fb->off_cntl = CLCD_PL111_CNTL;
 	} else {
-#ifdef CONFIG_ARCH_VERSATILE
-		fb->off_ienb = CLCD_PL111_IENB;
-		fb->off_cntl = CLCD_PL111_CNTL;
-#else
-		fb->off_ienb = CLCD_PL110_IENB;
-		fb->off_cntl = CLCD_PL110_CNTL;
-#endif
+		if (of_machine_is_compatible("arm,versatile-ab") ||
+		    of_machine_is_compatible("arm,versatile-pb")) {
+			fb->off_ienb = CLCD_PL111_IENB;
+			fb->off_cntl = CLCD_PL111_CNTL;
+		} else {
+			fb->off_ienb = CLCD_PL110_IENB;
+			fb->off_cntl = CLCD_PL110_CNTL;
+		}
 	}
 
 	fb->clk = clk_get(&fb->dev->dev, NULL);
-- 
2.4.3



From tony at atomide.com  Tue Feb  2 13:03:46 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 2 Feb 2016 13:03:46 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <Pine.LNX.4.44L0.1602021402250.1653-100000@iolanthe.rowland.org>
References: <20160202185450.GY19432@atomide.com>
 <Pine.LNX.4.44L0.1602021402250.1653-100000@iolanthe.rowland.org>
Message-ID: <20160202210345.GZ19432@atomide.com>

* Alan Stern <stern at rowland.harvard.edu> [160202 11:17]:
> On Tue, 2 Feb 2016, Tony Lindgren wrote:
> > I'd like to have pm_runtime_put_sync() disable the hardware after
> > the initial failed probe. Currently that does not happen unless
> > pm_runtime_dont_use_autosuspend() is called before pm_runtime_put_sync().
> 
> pm_runtime_put_sync() doesn't do anything to the hardware if the usage
> count was > 1, because after the decrement it's still nonzero.  Where
> is the particular call of pm_runtime_put_sync() that you're interested
> in, and what is the usage count when it runs?  It's not at all unusual
> for the usage count to be > 1 during a probe.

The usage count is 0 at that point, it seems the be the RPM_AUTO
causing the issues that we set at the end of rpm_idle().

> Also, what is autosuspend_delay set to for your device?  And is 
> runtime_auto set?

It's 100 at that point, see the commented snippet below from
omap_hsmmc_probe():

	pm_runtime_enable(host->dev);
	pm_runtime_get_sync(host->dev);
	pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY);
	/* NOTE: pm_runtime_dont_use_autosuspend(host->dev) needed here? */
	pm_runtime_use_autosuspend(host->dev);
	...
	/* gets -EPROBE_DEFER */
err_irq:
	...
	pm_runtime_put_sync(host->dev);
        pm_runtime_disable(host->dev);
	/* NOTE: suspend callback never gets called unless
	 * pm_runtime_dont_use_autosuspend() is called
	 * before pm_runtime_put_sync() above.
	 */
	 ...

> > > Does pm_runtime_use_autosuspend() get called by the probe routine?  If 
> > > it does, then perhaps you can get what you want by having the probe 
> > > routine call pm_runtime_dont_use_autosuspend() whenever it's about to 
> > > return an error -- particularly -EDEFER.
> > 
> > Yes so far that's the only fix that seems to work like I posted
> > earlier. But is that the right fix though?
> 
> No, not really.  Ideally you would leave autosuspend turned on.  The 
> delay would be long enough to that after -EDEFER, another probe would 
> start before the delay expired.  But shortly after the last probe 
> attempt, the delay would expire and the device would then be put in low 
> power.

But then what about the new reinit function? To me it seems that
we should not attempt to maintain a state from the earlier failed
probe. Or are you thinking we just skip the reinit if autosuspend
is set?

> > If we wanted to have some generic fix, it seems we would have to pass
> > a new flag in pm_runtime_put_sync() to ignore any autosuspend
> > configuration. But I don't know if that's what we want to or should
> > do though?
> 
> I don't think so.

So should we just establish a policy that pm_runtime_use_autosuspend()
needs to be paired with pm_runtime_dont_use_autosuspend() for
pm_runtime_put_sync() to work?

Regards,

Tony


From arnd at arndb.de  Tue Feb  2 13:07:17 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 02 Feb 2016 22:07:17 +0100
Subject: [PATCH 01/10] serial: mvebu-uart: initial support for Armada-3700
 serial port
In-Reply-To: <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <5687888.WDl8xbENFR@wuerfel>

On Tuesday 02 February 2016 19:07:39 Gregory CLEMENT wrote:

> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 39721ec4f415..b291f934d51b 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1606,6 +1606,28 @@ config SERIAL_STM32_CONSOLE
>  	depends on SERIAL_STM32=y
>  	select SERIAL_CORE_CONSOLE
>  
> +config SERIAL_MVEBU_UART
> +	bool "Marvell EBU serial port support"

Could this be a loadable module?

> +config SERIAL_MVEBU_CONSOLE
> +	bool "Console on Marvell EBU serial port"
> +	depends on SERIAL_MVEBU_UART

If yes, this would become 

	depends on SERIAL_MVEBU_UART=y

	Arnd



From slash.tmp at free.fr  Tue Feb  2 13:11:03 2016
From: slash.tmp at free.fr (Mason)
Date: Tue, 2 Feb 2016 22:11:03 +0100
Subject: Plain DFS (no voltage scaling)
Message-ID: <56B11B67.3090600@free.fr>

Hello,

I plan to enable the on-demand governor on the tango platform:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi

I found the cpufreq-dt binding doc:

https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt

Something is not clear to me:

If my platform cannot scale the voltage, what information
should I put in the voltage part of the DT?

Regards.


From arnd at arndb.de  Tue Feb  2 13:10:49 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 02 Feb 2016 22:10:49 +0100
Subject: [PATCH] video: ARM CLCD: runtime check for Versatile
In-Reply-To: <1454446059-30526-1-git-send-email-linus.walleij@linaro.org>
References: <1454446059-30526-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <25978729.oSoMp4ZgxA@wuerfel>

On Tuesday 02 February 2016 21:47:39 Linus Walleij wrote:
>         } else {
> -#ifdef CONFIG_ARCH_VERSATILE
> -               fb->off_ienb = CLCD_PL111_IENB;
> -               fb->off_cntl = CLCD_PL111_CNTL;
> -#else
> -               fb->off_ienb = CLCD_PL110_IENB;
> -               fb->off_cntl = CLCD_PL110_CNTL;
> -#endif
> +               if (of_machine_is_compatible("arm,versatile-ab") ||
> +                   of_machine_is_compatible("arm,versatile-pb")) {
> +                       fb->off_ienb = CLCD_PL111_IENB;
> +                       fb->off_cntl = CLCD_PL111_CNTL;
> +               } else {
> +                       fb->off_ienb = CLCD_PL110_IENB;
> +                       fb->off_cntl = CLCD_PL110_CNTL;
> +               }
>         }
> 

Could that be done based on the AMBA device ID instead?

	Arnd


From mathieu.poirier at linaro.org  Tue Feb  2 13:13:54 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue,  2 Feb 2016 14:13:54 -0700
Subject: [PATCH 0/7] coresight: next v4.5-rc2 
Message-ID: <1454447641-29153-1-git-send-email-mathieu.poirier@linaro.org>

Hi Greg,

I would like to queue the following patches for 4.6, more will likely come later.

Thanks,
Mathieu

Mathieu Poirier (7):
  coresight: fixing indentation problem
  coresight: fixing lockdep error
  coresight: coresight_unregister() function cleanup
  coresight: release reference taken by 'bus_find_device()'
  coresight: remove csdev's link from topology
  coresight: removing bind/unbind options from sysfs
  coresight: implementing 'cpu_id()' API

 drivers/hwtracing/coresight/coresight-etb10.c      | 11 +----
 drivers/hwtracing/coresight/coresight-etm3x.c      | 21 ++++----
 drivers/hwtracing/coresight/coresight-etm4x.c      | 21 ++++----
 drivers/hwtracing/coresight/coresight-funnel.c     | 10 +---
 .../coresight/coresight-replicator-qcom.c          | 11 +----
 drivers/hwtracing/coresight/coresight-replicator.c | 16 +-----
 drivers/hwtracing/coresight/coresight-tmc.c        | 15 +-----
 drivers/hwtracing/coresight/coresight-tpiu.c       | 10 +---
 drivers/hwtracing/coresight/coresight.c            | 57 +++++++++++++++++++---
 include/linux/coresight.h                          |  3 ++
 10 files changed, 78 insertions(+), 97 deletions(-)

-- 
2.1.4



From mathieu.poirier at linaro.org  Tue Feb  2 13:13:55 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue,  2 Feb 2016 14:13:55 -0700
Subject: [PATCH 1/7] coresight: fixing indentation problem
In-Reply-To: <1454447641-29153-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454447641-29153-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454447641-29153-2-git-send-email-mathieu.poirier@linaro.org>

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 93738dfbf631..4236a02cdab2 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -536,7 +536,7 @@ static void coresight_fixup_orphan_conns(struct coresight_device *csdev)
 	 * are hooked-up with each newly added component.
 	 */
 	bus_for_each_dev(&coresight_bustype, NULL,
-				 csdev, coresight_orphan_match);
+			 csdev, coresight_orphan_match);
 }
 
 
-- 
2.1.4



From mathieu.poirier at linaro.org  Tue Feb  2 13:13:59 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue,  2 Feb 2016 14:13:59 -0700
Subject: [PATCH 5/7] coresight: remove csdev's link from topology
In-Reply-To: <1454447641-29153-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454447641-29153-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454447641-29153-6-git-send-email-mathieu.poirier@linaro.org>

In function 'coresight_unregister()', all references to the csdev that
is being taken away need to be removed from the topology.  Otherwise
building the next coresight path from source to sink may use memory
that has been released.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight.c | 46 +++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index a35ca54a76c9..7e6e9ff27dd1 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -579,6 +579,50 @@ static void coresight_fixup_device_conns(struct coresight_device *csdev)
 	}
 }
 
+static int coresight_remove_match(struct device *dev, void *data)
+{
+	int i;
+	struct coresight_device *csdev, *iterator;
+	struct coresight_connection *conn;
+
+	csdev = data;
+	iterator = to_coresight_device(dev);
+
+	/* No need to check oneself */
+	if (csdev == iterator)
+		return 0;
+
+	/*
+	 * Circle throuch all the connection of that component.  If we find
+	 * a connection whose name matches @csdev, remove it.
+	 */
+	for (i = 0; i < iterator->nr_outport; i++) {
+		conn = &iterator->conns[i];
+
+		if (conn->child_dev == NULL)
+			continue;
+
+		if (!strcmp(dev_name(&csdev->dev), conn->child_name)) {
+			iterator->orphan = true;
+			conn->child_dev = NULL;
+			/* No need to continue */
+			break;
+		}
+	}
+
+	/*
+	 * Returning '0' ensures that all known component on the
+	 * bus will be checked.
+	 */
+	return 0;
+}
+
+static void coresight_remove_conns(struct coresight_device *csdev)
+{
+	bus_for_each_dev(&coresight_bustype, NULL,
+			 csdev, coresight_remove_match);
+}
+
 /**
  * coresight_timeout - loop until a bit has changed to a specific state.
  * @addr: base address of the area of interest.
@@ -717,6 +761,8 @@ EXPORT_SYMBOL_GPL(coresight_register);
 
 void coresight_unregister(struct coresight_device *csdev)
 {
+	/* Remove references of that device in the topology */
+	coresight_remove_conns(csdev);
 	device_unregister(&csdev->dev);
 }
 EXPORT_SYMBOL_GPL(coresight_unregister);
-- 
2.1.4



From mathieu.poirier at linaro.org  Tue Feb  2 13:13:56 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue,  2 Feb 2016 14:13:56 -0700
Subject: [PATCH 2/7] coresight: fixing lockdep error
In-Reply-To: <1454447641-29153-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454447641-29153-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454447641-29153-3-git-send-email-mathieu.poirier@linaro.org>

On some platform the following lockdep error occurs when doing simple
manipulations:

    [   23.197021]
    [   23.198608] ======================================================
    [   23.205078] [ INFO: possible circular locking dependency detected ]
    [   23.211639] 4.4.0-rc8-00025-gbbf360b #172 Not tainted
    [   23.216918] -------------------------------------------------------
    [   23.223480] sh/858 is trying to acquire lock:
    [   23.228057]  (coresight_mutex){+.+.+.}, at: [<c0415d40>] coresight_enable+0x1c/0x1b4
    [   23.236206]
    [   23.236206] but task is already holding lock:
    [   23.242309]  (s_active#52){++++.+}, at: [<c01d4b40>] kernfs_fop_write+0x5c/0x1c0
    [   23.250122]
    [   23.250122] which lock already depends on the new lock.
    [   23.250122]
    [   23.258697]
    [   23.258697] the existing dependency chain (in reverse order) is:
    [   23.266510]
    -> #1 (s_active#52){++++.+}:
    [   23.270843]        [<c01d30ec>] __kernfs_remove+0x294/0x35c
    [   23.276672]        [<c01d3e44>] kernfs_remove_by_name_ns+0x44/0x8c
    [   23.283172]        [<c01d6318>] remove_files+0x3c/0x84
    [   23.288543]        [<c01d66b4>] sysfs_remove_group+0x48/0x9c
    [   23.294494]        [<c01d6734>] sysfs_remove_groups+0x2c/0x3c
    [   23.300506]        [<c030b658>] device_remove_attrs+0x5c/0x74
    [   23.306549]        [<c030c290>] device_del+0x110/0x218
    [   23.311950]        [<c030c3c4>] device_unregister+0x2c/0x6c
    [   23.317779]        [<c04156d8>] coresight_unregister+0x30/0x40
    [   23.323883]        [<c041a290>] etm_probe+0x228/0x2e8
    [   23.329193]        [<c02bc760>] amba_probe+0xe4/0x160
    [   23.334503]        [<c0310540>] driver_probe_device+0x23c/0x480
    [   23.340728]        [<c0310820>] __driver_attach+0x9c/0xa0
    [   23.346374]        [<c030e400>] bus_for_each_dev+0x70/0xa4
    [   23.352142]        [<c030fcf4>] driver_attach+0x24/0x28
    [   23.357604]        [<c030f86c>] bus_add_driver+0x1e0/0x278
    [   23.363372]        [<c0310d48>] driver_register+0x80/0x100
    [   23.369110]        [<c02bc508>] amba_driver_register+0x58/0x5c
    [   23.375244]        [<c0749514>] etm_driver_init+0x18/0x1c
    [   23.380889]        [<c0009918>] do_one_initcall+0xc4/0x20c
    [   23.386657]        [<c0715e7c>] kernel_init_freeable+0x160/0x208
    [   23.392974]        [<c052d7fc>] kernel_init+0x18/0xf0
    [   23.398254]        [<c0010850>] ret_from_fork+0x14/0x24
    [   23.403747]
    -> #0 (coresight_mutex){+.+.+.}:
    [   23.408447]        [<c008ed60>] lock_acquire+0xe4/0x210
    [   23.413909]        [<c0530a30>] mutex_lock_nested+0x74/0x450
    [   23.419860]        [<c0415d40>] coresight_enable+0x1c/0x1b4
    [   23.425689]        [<c0416030>] enable_source_store+0x58/0x68
    [   23.431732]        [<c030b358>] dev_attr_store+0x20/0x2c
    [   23.437286]        [<c01d55e8>] sysfs_kf_write+0x50/0x54
    [   23.442871]        [<c01d4ba8>] kernfs_fop_write+0xc4/0x1c0
    [   23.448699]        [<c015b60c>] __vfs_write+0x34/0xe4
    [   23.454040]        [<c015bf38>] vfs_write+0x98/0x174
    [   23.459228]        [<c015c7a8>] SyS_write+0x4c/0xa8
    [   23.464355]        [<c00107c0>] ret_fast_syscall+0x0/0x1c
    [   23.470031]
    [   23.470031] other info that might help us debug this:
    [   23.470031]
    [   23.478393]  Possible unsafe locking scenario:
    [   23.478393]
    [   23.484619]        CPU0                    CPU1
    [   23.489349]        ----                    ----
    [   23.494079]   lock(s_active#52);
    [   23.497497]                                lock(coresight_mutex);
    [   23.503906]                                lock(s_active#52);
    [   23.509918]   lock(coresight_mutex);
    [   23.513702]
    [   23.513702]  *** DEADLOCK ***
    [   23.513702]
    [   23.519897] 3 locks held by sh/858:
    [   23.523529]  #0:  (sb_writers#7){.+.+.+}, at: [<c015ec38>] __sb_start_write+0xa8/0xd4
    [   23.531799]  #1:  (&of->mutex){+.+...}, at: [<c01d4b38>] kernfs_fop_write+0x54/0x1c0
    [   23.539916]  #2:  (s_active#52){++++.+}, at: [<c01d4b40>] kernfs_fop_write+0x5c/0x1c0
    [   23.548156]
    [   23.548156] stack backtrace:
    [   23.552734] CPU: 0 PID: 858 Comm: sh Not tainted 4.4.0-rc8-00025-gbbf360b #172
    [   23.560302] Hardware name: Generic OMAP4 (Flattened Device Tree)
    [   23.566589] Backtrace:
    [   23.569152] [<c00154d4>] (dump_backtrace) from [<c00156d0>] (show_stack+0x18/0x1c)
    [   23.577087]  r7:ed4b8570 r6:c0936400 r5:c07ae71c r4:00000000
    [   23.583038] [<c00156b8>] (show_stack) from [<c027e69c>] (dump_stack+0x98/0xc0)
    [   23.590606] [<c027e604>] (dump_stack) from [<c008a750>] (print_circular_bug+0x21c/0x33c)
    [   23.599090]  r5:c0939d60 r4:c0936400
    [   23.602874] [<c008a534>] (print_circular_bug) from [<c008e370>] (__lock_acquire+0x1c98/0x1d88)
    [   23.611877]  r10:00000003 r9:c0fd7a5c r8:ed4b8550 r7:ed4b8570 r6:ed4b8000 r5:c0ff69e4
    [   23.620117]  r4:c0936400 r3:ed4b8550
    [   23.623901] [<c008c6d8>] (__lock_acquire) from [<c008ed60>] (lock_acquire+0xe4/0x210)
    [   23.632080]  r10:00000000 r9:00000000 r8:60000013 r7:c07cb7b4 r6:00000001 r5:00000000
    [   23.640350]  r4:00000000
    [   23.643005] [<c008ec7c>] (lock_acquire) from [<c0530a30>] (mutex_lock_nested+0x74/0x450)
    [   23.651458]  r10:ecc0bf80 r9:edbe7dcc r8:ed4b8000 r7:c0fd7a5c r6:c0415d40 r5:00000000
    [   23.659729]  r4:c07cb780
    [   23.662384] [<c05309bc>] (mutex_lock_nested) from [<c0415d40>] (coresight_enable+0x1c/0x1b4)
    [   23.671234]  r10:ecc0bf80 r9:edbe7dcc r8:ed733c00 r7:00000000 r6:ed733c00 r5:00000002
    [   23.679473]  r4:ed762140
    [   23.682128] [<c0415d24>] (coresight_enable) from [<c0416030>] (enable_source_store+0x58/0x68)
    [   23.691070]  r7:00000000 r6:ed733c00 r5:00000002 r4:ed762160
    [   23.697052] [<c0415fd8>] (enable_source_store) from [<c030b358>] (dev_attr_store+0x20/0x2c)
    [   23.705780]  r5:edbe7dc0 r4:c0415fd8
    [   23.709533] [<c030b338>] (dev_attr_store) from [<c01d55e8>] (sysfs_kf_write+0x50/0x54)
    [   23.717834]  r5:edbe7dc0 r4:c030b338
    [   23.721618] [<c01d5598>] (sysfs_kf_write) from [<c01d4ba8>] (kernfs_fop_write+0xc4/0x1c0)
    [   23.730163]  r7:00000000 r6:00000000 r5:00000002 r4:edbe7dc0
    [   23.736145] [<c01d4ae4>] (kernfs_fop_write) from [<c015b60c>] (__vfs_write+0x34/0xe4)
    [   23.744323]  r10:00000000 r9:ecc0a000 r8:c0010964 r7:ecc0bf80 r6:00000002 r5:c01d4ae4
    [   23.752593]  r4:ee385a40
    [   23.755249] [<c015b5d8>] (__vfs_write) from [<c015bf38>] (vfs_write+0x98/0x174)
    [   23.762908]  r9:ecc0a000 r8:c0010964 r7:ecc0bf80 r6:000ab0d8 r5:00000002 r4:ee385a40
    [   23.771057] [<c015bea0>] (vfs_write) from [<c015c7a8>] (SyS_write+0x4c/0xa8)
    [   23.778442]  r8:c0010964 r7:00000002 r6:000ab0d8 r5:ee385a40 r4:ee385a40
    [   23.785522] [<c015c75c>] (SyS_write) from [<c00107c0>] (ret_fast_syscall+0x0/0x1c)
    [   23.793457]  r7:00000004 r6:00000001 r5:000ab0d8 r4:00000002
    [   23.799652] coresight-etb10 54162000.etb: ETB enabled
    [   23.805084] coresight-funnel 54164000.funnel: FUNNEL inport 0 enabled
    [   23.811859] coresight-replicator 44000000.ocp:replicator: REPLICATOR enabled
    [   23.819335] coresight-funnel 54158000.funnel: FUNNEL inport 0 enabled
    [   23.826110] coresight-etm3x 5414c000.ptm: ETM tracing enabled

The locking in coresight_unregister() is not required as the only customers of
the function are drivers themselves when an initialisation failure has been
encoutered.

Reported-by: Rabin Vincent <rabin at rab.in>
Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 4236a02cdab2..41b42018b660 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -713,12 +713,8 @@ EXPORT_SYMBOL_GPL(coresight_register);
 
 void coresight_unregister(struct coresight_device *csdev)
 {
-	mutex_lock(&coresight_mutex);
-
 	kfree(csdev->conns);
 	device_unregister(&csdev->dev);
-
-	mutex_unlock(&coresight_mutex);
 }
 EXPORT_SYMBOL_GPL(coresight_unregister);
 
-- 
2.1.4



From mathieu.poirier at linaro.org  Tue Feb  2 13:13:57 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue,  2 Feb 2016 14:13:57 -0700
Subject: [PATCH 3/7] coresight: coresight_unregister() function cleanup
In-Reply-To: <1454447641-29153-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454447641-29153-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454447641-29153-4-git-send-email-mathieu.poirier@linaro.org>

In its current form the code never frees csdev->refcnt allocated
in coresight_register().  There is also a problem with csdev->conns
that is freed before device_unregister() rather than in the device
release function.

This patch addresses both issues by moving kfree(csdev->conns) to
coresight_device_release() and freeing csdev->refcnt, also in
the same function.

Reported-by: Rabin Vincent <rabin at rab.in>
Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 41b42018b660..8872db4410eb 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -481,6 +481,8 @@ static void coresight_device_release(struct device *dev)
 {
 	struct coresight_device *csdev = to_coresight_device(dev);
 
+	kfree(csdev->conns);
+	kfree(csdev->refcnt);
 	kfree(csdev);
 }
 
@@ -713,7 +715,6 @@ EXPORT_SYMBOL_GPL(coresight_register);
 
 void coresight_unregister(struct coresight_device *csdev)
 {
-	kfree(csdev->conns);
 	device_unregister(&csdev->dev);
 }
 EXPORT_SYMBOL_GPL(coresight_unregister);
-- 
2.1.4



From mathieu.poirier at linaro.org  Tue Feb  2 13:13:58 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue,  2 Feb 2016 14:13:58 -0700
Subject: [PATCH 4/7] coresight: release reference taken by 'bus_find_device()'
In-Reply-To: <1454447641-29153-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454447641-29153-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454447641-29153-5-git-send-email-mathieu.poirier@linaro.org>

The reference count taken by function bus_find_device() needs
to be released if a child device is found, something this patch
is adding.

Reported-by: Rabin Vincent <rabin at rab.in>
Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 8872db4410eb..a35ca54a76c9 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -570,6 +570,8 @@ static void coresight_fixup_device_conns(struct coresight_device *csdev)
 
 		if (dev) {
 			conn->child_dev = to_coresight_device(dev);
+			/* and put reference from 'bus_find_device()' */
+			put_device(dev);
 		} else {
 			csdev->orphan = true;
 			conn->child_dev = NULL;
-- 
2.1.4



From mathieu.poirier at linaro.org  Tue Feb  2 13:14:00 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue,  2 Feb 2016 14:14:00 -0700
Subject: [PATCH 6/7] coresight: removing bind/unbind options from sysfs
In-Reply-To: <1454447641-29153-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454447641-29153-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454447641-29153-7-git-send-email-mathieu.poirier@linaro.org>

The coresight drivers have absolutely no control over bind and unbind
operations triggered from sysfs. The operations simply can't be
cancelled or denied event when one or several tracing sessions are
under way.  Since the memory associated to individual device is
invariably freed, the end result is a kernel crash when the path from
source to sink is travelled again as demonstrated here[1].

One solution could be to keep track of all the path (i.e tracing
session) that get created and iterate through the elements of those path
looking for the coresight device that is being removed.  This proposition
doesn't scale well since there is no upper bound on the amount of
concurrent trace session that can be created.

With the above in mind, this patch prevent devices from being unbounded
from their driver by using the driver->suppress_bind_attr option.  That way
trace sessions can be managed without fearing to loose devices.

Since device can't be removed anymore the xyz_remove() functions found in
each driver is also removed.

[1]. http://www.spinics.net/lists/arm-kernel/msg474952.html

Reported-by: Rabin Vincent <rabin at rab.in>
Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etb10.c           | 11 +----------
 drivers/hwtracing/coresight/coresight-etm3x.c           | 13 +------------
 drivers/hwtracing/coresight/coresight-etm4x.c           | 13 +------------
 drivers/hwtracing/coresight/coresight-funnel.c          | 10 +---------
 drivers/hwtracing/coresight/coresight-replicator-qcom.c | 11 +----------
 drivers/hwtracing/coresight/coresight-replicator.c      | 16 +---------------
 drivers/hwtracing/coresight/coresight-tmc.c             | 15 +--------------
 drivers/hwtracing/coresight/coresight-tpiu.c            | 10 +---------
 8 files changed, 8 insertions(+), 91 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 77d0f9c1118d..92969dae739d 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -489,15 +489,6 @@ err_misc_register:
 	return ret;
 }
 
-static int etb_remove(struct amba_device *adev)
-{
-	struct etb_drvdata *drvdata = amba_get_drvdata(adev);
-
-	misc_deregister(&drvdata->miscdev);
-	coresight_unregister(drvdata->csdev);
-	return 0;
-}
-
 #ifdef CONFIG_PM
 static int etb_runtime_suspend(struct device *dev)
 {
@@ -537,10 +528,10 @@ static struct amba_driver etb_driver = {
 		.name	= "coresight-etb10",
 		.owner	= THIS_MODULE,
 		.pm	= &etb_dev_pm_ops,
+		.suppress_bind_attrs = true,
 
 	},
 	.probe		= etb_probe,
-	.remove		= etb_remove,
 	.id_table	= etb_ids,
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index d630b7ece735..5981fcc69960 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -1877,17 +1877,6 @@ err_arch_supported:
 	return ret;
 }
 
-static int etm_remove(struct amba_device *adev)
-{
-	struct etm_drvdata *drvdata = amba_get_drvdata(adev);
-
-	coresight_unregister(drvdata->csdev);
-	if (--etm_count == 0)
-		unregister_hotcpu_notifier(&etm_cpu_notifier);
-
-	return 0;
-}
-
 #ifdef CONFIG_PM
 static int etm_runtime_suspend(struct device *dev)
 {
@@ -1948,9 +1937,9 @@ static struct amba_driver etm_driver = {
 		.name	= "coresight-etm3x",
 		.owner	= THIS_MODULE,
 		.pm	= &etm_dev_pm_ops,
+		.suppress_bind_attrs = true,
 	},
 	.probe		= etm_probe,
-	.remove		= etm_remove,
 	.id_table	= etm_ids,
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index 1ec6798b21e8..0edc10b44004 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -2684,17 +2684,6 @@ err_coresight_register:
 	return ret;
 }
 
-static int etm4_remove(struct amba_device *adev)
-{
-	struct etmv4_drvdata *drvdata = amba_get_drvdata(adev);
-
-	coresight_unregister(drvdata->csdev);
-	if (--etm4_count == 0)
-		unregister_hotcpu_notifier(&etm4_cpu_notifier);
-
-	return 0;
-}
-
 static struct amba_id etm4_ids[] = {
 	{       /* ETM 4.0 - Qualcomm */
 		.id	= 0x0003b95d,
@@ -2712,9 +2701,9 @@ static struct amba_id etm4_ids[] = {
 static struct amba_driver etm4x_driver = {
 	.drv = {
 		.name   = "coresight-etm4x",
+		.suppress_bind_attrs = true,
 	},
 	.probe		= etm4_probe,
-	.remove		= etm4_remove,
 	.id_table	= etm4_ids,
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c
index 2e36bde7fcb4..25e8ea140a09 100644
--- a/drivers/hwtracing/coresight/coresight-funnel.c
+++ b/drivers/hwtracing/coresight/coresight-funnel.c
@@ -226,14 +226,6 @@ static int funnel_probe(struct amba_device *adev, const struct amba_id *id)
 	return 0;
 }
 
-static int funnel_remove(struct amba_device *adev)
-{
-	struct funnel_drvdata *drvdata = amba_get_drvdata(adev);
-
-	coresight_unregister(drvdata->csdev);
-	return 0;
-}
-
 #ifdef CONFIG_PM
 static int funnel_runtime_suspend(struct device *dev)
 {
@@ -273,9 +265,9 @@ static struct amba_driver funnel_driver = {
 		.name	= "coresight-funnel",
 		.owner	= THIS_MODULE,
 		.pm	= &funnel_dev_pm_ops,
+		.suppress_bind_attrs = true,
 	},
 	.probe		= funnel_probe,
-	.remove		= funnel_remove,
 	.id_table	= funnel_ids,
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-replicator-qcom.c b/drivers/hwtracing/coresight/coresight-replicator-qcom.c
index 584059e9e866..444815179460 100644
--- a/drivers/hwtracing/coresight/coresight-replicator-qcom.c
+++ b/drivers/hwtracing/coresight/coresight-replicator-qcom.c
@@ -156,15 +156,6 @@ static int replicator_probe(struct amba_device *adev, const struct amba_id *id)
 	return 0;
 }
 
-static int replicator_remove(struct amba_device *adev)
-{
-	struct replicator_state *drvdata = amba_get_drvdata(adev);
-
-	pm_runtime_disable(&adev->dev);
-	coresight_unregister(drvdata->csdev);
-	return 0;
-}
-
 #ifdef CONFIG_PM
 static int replicator_runtime_suspend(struct device *dev)
 {
@@ -206,9 +197,9 @@ static struct amba_driver replicator_driver = {
 	.drv = {
 		.name	= "coresight-replicator-qcom",
 		.pm	= &replicator_dev_pm_ops,
+		.suppress_bind_attrs = true,
 	},
 	.probe		= replicator_probe,
-	.remove		= replicator_remove,
 	.id_table	= replicator_ids,
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
index 963ac197c253..b77d700a3f0e 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -127,20 +127,6 @@ out_disable_pm:
 	return ret;
 }
 
-static int replicator_remove(struct platform_device *pdev)
-{
-	struct replicator_drvdata *drvdata = platform_get_drvdata(pdev);
-
-	coresight_unregister(drvdata->csdev);
-	pm_runtime_get_sync(&pdev->dev);
-	if (!IS_ERR(drvdata->atclk))
-		clk_disable_unprepare(drvdata->atclk);
-	pm_runtime_put_noidle(&pdev->dev);
-	pm_runtime_disable(&pdev->dev);
-
-	return 0;
-}
-
 #ifdef CONFIG_PM
 static int replicator_runtime_suspend(struct device *dev)
 {
@@ -175,11 +161,11 @@ static const struct of_device_id replicator_match[] = {
 
 static struct platform_driver replicator_driver = {
 	.probe          = replicator_probe,
-	.remove         = replicator_remove,
 	.driver         = {
 		.name   = "coresight-replicator",
 		.of_match_table = replicator_match,
 		.pm	= &replicator_dev_pm_ops,
+		.suppress_bind_attrs = true,
 	},
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
index 5b052d1e0bc6..c4fa70ed14ce 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -770,19 +770,6 @@ err_devm_kzalloc:
 	return ret;
 }
 
-static int tmc_remove(struct amba_device *adev)
-{
-	struct tmc_drvdata *drvdata = amba_get_drvdata(adev);
-
-	misc_deregister(&drvdata->miscdev);
-	coresight_unregister(drvdata->csdev);
-	if (drvdata->config_type == TMC_CONFIG_TYPE_ETR)
-		dma_free_coherent(drvdata->dev, drvdata->size,
-				  drvdata->vaddr, drvdata->paddr);
-
-	return 0;
-}
-
 static struct amba_id tmc_ids[] = {
 	{
 		.id     = 0x0003b961,
@@ -795,9 +782,9 @@ static struct amba_driver tmc_driver = {
 	.drv = {
 		.name   = "coresight-tmc",
 		.owner  = THIS_MODULE,
+		.suppress_bind_attrs = true,
 	},
 	.probe		= tmc_probe,
-	.remove		= tmc_remove,
 	.id_table	= tmc_ids,
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
index 7214efd10db5..ca50e73d9df7 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -172,14 +172,6 @@ static int tpiu_probe(struct amba_device *adev, const struct amba_id *id)
 	return 0;
 }
 
-static int tpiu_remove(struct amba_device *adev)
-{
-	struct tpiu_drvdata *drvdata = amba_get_drvdata(adev);
-
-	coresight_unregister(drvdata->csdev);
-	return 0;
-}
-
 #ifdef CONFIG_PM
 static int tpiu_runtime_suspend(struct device *dev)
 {
@@ -223,9 +215,9 @@ static struct amba_driver tpiu_driver = {
 		.name	= "coresight-tpiu",
 		.owner	= THIS_MODULE,
 		.pm	= &tpiu_dev_pm_ops,
+		.suppress_bind_attrs = true,
 	},
 	.probe		= tpiu_probe,
-	.remove		= tpiu_remove,
 	.id_table	= tpiu_ids,
 };
 
-- 
2.1.4



From mathieu.poirier at linaro.org  Tue Feb  2 13:14:01 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue,  2 Feb 2016 14:14:01 -0700
Subject: [PATCH 7/7] coresight: implementing 'cpu_id()' API
In-Reply-To: <1454447641-29153-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454447641-29153-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454447641-29153-8-git-send-email-mathieu.poirier@linaro.org>

Other than plainly parsing the device tree there is no way to
know which CPU a tracer is affined to.  As such adding an
interface to lookup the CPU field enclosed in the etm_drvdata
structure that was initialised at boot time.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm3x.c | 8 ++++++++
 drivers/hwtracing/coresight/coresight-etm4x.c | 8 ++++++++
 include/linux/coresight.h                     | 3 +++
 3 files changed, 19 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 5981fcc69960..aae80e14508d 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -315,6 +315,13 @@ static void etm_enable_hw(void *info)
 	dev_dbg(drvdata->dev, "cpu: %d enable smp call done\n", drvdata->cpu);
 }
 
+static int etm_cpu_id(struct coresight_device *csdev)
+{
+	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	return drvdata->cpu;
+}
+
 static int etm_trace_id(struct coresight_device *csdev)
 {
 	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
@@ -421,6 +428,7 @@ static void etm_disable(struct coresight_device *csdev)
 }
 
 static const struct coresight_ops_source etm_source_ops = {
+	.cpu_id		= etm_cpu_id,
 	.trace_id	= etm_trace_id,
 	.enable		= etm_enable,
 	.disable	= etm_disable,
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index 0edc10b44004..d6a92c6d3a66 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -63,6 +63,13 @@ static bool etm4_arch_supported(u8 arch)
 	return true;
 }
 
+static int etm4_cpu_id(struct coresight_device *csdev)
+{
+	struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	return drvdata->cpu;
+}
+
 static int etm4_trace_id(struct coresight_device *csdev)
 {
 	struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
@@ -262,6 +269,7 @@ static void etm4_disable(struct coresight_device *csdev)
 }
 
 static const struct coresight_ops_source etm4_source_ops = {
+	.cpu_id		= etm4_cpu_id,
 	.trace_id	= etm4_trace_id,
 	.enable		= etm4_enable,
 	.disable	= etm4_disable,
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index a7cabfa23b55..bf62b265bf52 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -205,12 +205,15 @@ struct coresight_ops_link {
 /**
  * struct coresight_ops_source - basic operations for a source
  * Operations available for sources.
+ * @cpu_id:	returns the value of the CPU number this component
+ *		is associated to.
  * @trace_id:	returns the value of the component's trace ID as known
 		to the HW.
  * @enable:	enables tracing for a source.
  * @disable:	disables tracing for a source.
  */
 struct coresight_ops_source {
+	int (*cpu_id)(struct coresight_device *csdev);
 	int (*trace_id)(struct coresight_device *csdev);
 	int (*enable)(struct coresight_device *csdev);
 	void (*disable)(struct coresight_device *csdev);
-- 
2.1.4



From maxime.ripard at free-electrons.com  Tue Feb  2 13:17:43 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 22:17:43 +0100
Subject: [PATCH v3 2/2] ASOC: sunxi: Add support for the SPDIF block
In-Reply-To: <1454424594-25208-3-git-send-email-codekipper@gmail.com>
References: <1454424594-25208-1-git-send-email-codekipper@gmail.com>
 <1454424594-25208-3-git-send-email-codekipper@gmail.com>
Message-ID: <20160202211743.GD4652@lukather>

Hi,

It looks mostly good on my side, a few comments though.

On Tue, Feb 02, 2016 at 03:49:54PM +0100, codekipper at gmail.com wrote:
> +#ifdef CONFIG_PM
> +static int sun4i_spdif_runtime_suspend(struct device *dev)
> +{
> +	struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
> +
> +	clk_disable_unprepare(host->spdif_clk);
> +
> +	return 0;
> +}
> +
> +static int sun4i_spdif_runtime_resume(struct device *dev)
> +{
> +	struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
> +
> +	clk_prepare_enable(host->spdif_clk);
> +
> +	return 0;
> +}
> +#endif /* CONFIG_PM */

You can also shut down the bus clock here. That will reset the device,
so you'll have to reinit it in your resume, but since you won't be
suspended while you play something, and that you set up most of your
controller any way when you start streaming, it shouldn't be a big
deal.

> +
> +static int sun4i_spdif_probe(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct sun4i_spdif_dev *host;
> +	struct resource *res;
> +	int ret;
> +	void __iomem *base;
> +
> +	dev_dbg(&pdev->dev, "Entered %s\n", __func__);
> +
> +	if (!np)
> +		return -ENODEV;

You won't probe without DT.

> +
> +	if (!of_match_device(sun4i_spdif_of_match, &pdev->dev)) {
> +		dev_err(&pdev->dev, "No matched devices found.\n");
> +		return -EINVAL;
> +	}

And you won't probe if the compatibles don't match.

> +	host = devm_kzalloc(&pdev->dev, sizeof(*host), GFP_KERNEL);
> +	if (!host)
> +		return -ENOMEM;
> +
> +	host->pdev = pdev;
> +
> +	/* Initialize this copy of the CPU DAI driver structure */
> +	memcpy(&host->cpu_dai_drv, &sun4i_spdif_dai, sizeof(sun4i_spdif_dai));
> +	host->cpu_dai_drv.name = dev_name(&pdev->dev);
> +
> +	/* Get the addresses */
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	base = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(base))
> +		return PTR_ERR(base);
> +
> +	host->regmap = devm_regmap_init_mmio(&pdev->dev, base,
> +						&sun4i_spdif_regmap_config);
> +
> +	/* Clocks */
> +	host->apb_clk = devm_clk_get(&pdev->dev, "apb");
> +	if (IS_ERR(host->apb_clk)) {
> +		dev_err(&pdev->dev, "failed to get a apb clock.\n");
> +		return PTR_ERR(host->apb_clk);
> +	}
> +
> +	ret = clk_prepare_enable(host->apb_clk);
> +	if (ret) {
> +		dev_err(&pdev->dev, "try to enable apb_spdif_clk failed\n");
> +		return ret;
> +	}
> +
> +	host->spdif_clk = devm_clk_get(&pdev->dev, "spdif");
> +	if (IS_ERR(host->spdif_clk)) {
> +		dev_err(&pdev->dev, "failed to get a spdif clock.\n");
> +		goto exit_clkdisable_apb_clk;
> +	}
> +
> +	host->playback_supported = false;
> +	host->capture_supported = false;
> +
> +	if (of_property_read_bool(np, "spdif-out"))
> +		host->playback_supported = true;
> +
> +	if (!host->playback_supported) {
> +		dev_err(&pdev->dev, "no enabled S/PDIF DAI link\n");
> +		goto exit_clkdisable_clk;
> +	}
> +
> +	host->dma_params_tx.addr = res->start + SUN4I_SPDIF_TXFIFO;
> +	host->dma_params_tx.maxburst = 4;
> +	host->dma_params_tx.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
> +	host->dma_params_rx.addr = res->start + SUN4I_SPDIF_RXFIFO;
> +	host->dma_params_rx.maxburst = 4;
> +	host->dma_params_rx.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
> +
> +	platform_set_drvdata(pdev, host);
> +
> +	ret = devm_snd_soc_register_component(&pdev->dev,
> +				&sun4i_spdif_component, &sun4i_spdif_dai, 1);
> +	if (ret)
> +		goto exit_clkdisable_clk;
> +
> +	pm_runtime_enable(&pdev->dev);
> +
> +	ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
> +	if (ret)
> +		goto exit_clkdisable_clk;
> +	return 0;
> +
> +exit_clkdisable_clk:
> +	clk_disable_unprepare(host->spdif_clk);

You disabled a clock that you didn't enable.

> +exit_clkdisable_apb_clk:
> +	clk_disable_unprepare(host->apb_clk);
> +	return ret;
> +}
> +
> +static int sun4i_spdif_remove(struct platform_device *pdev)
> +{
> +	struct sun4i_spdif_dev *host = dev_get_drvdata(&pdev->dev);
> +
> +	snd_soc_unregister_platform(&pdev->dev);
> +	snd_soc_unregister_component(&pdev->dev);
> +
> +	pm_runtime_disable(&pdev->dev);
> +
> +	if (!IS_ERR(host->spdif_clk)) {

Probe will fail on this condition. If probe failed, remove won't be
called.

> +		clk_disable_unprepare(host->spdif_clk);

And here as well.

> +		clk_disable_unprepare(host->apb_clk);
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct dev_pm_ops sun4i_spdif_pm = {
> +	SET_RUNTIME_PM_OPS(sun4i_spdif_runtime_suspend,
> +			   sun4i_spdif_runtime_resume, NULL)
> +};
> +
> +static struct platform_driver sun4i_spdif_driver = {
> +	.driver		= {
> +		.name	= "sun4i-spdif",
> +		.owner	= THIS_MODULE,

This is not needed.

> +		.of_match_table = of_match_ptr(sun4i_spdif_of_match),
> +		.pm	= &sun4i_spdif_pm,

IIRC, the pm field is not defined if PM is not set.

Have you tested your driver without PM?

> +	},
> +	.probe		= sun4i_spdif_probe,
> +	.remove		= sun4i_spdif_remove,
> +};
> +
> +module_platform_driver(sun4i_spdif_driver);
> +
> +MODULE_AUTHOR("Marcus Cooper <codekipper at gmail.com>");
> +MODULE_AUTHOR("Andrea Venturi <be17068 at iperbole.bo.it>");
> +MODULE_DESCRIPTION("Allwinner sun4i SPDIF SoC Interface");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:sun4i-spdif");

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/a3f0df25/attachment-0001.sig>

From festevam at gmail.com  Tue Feb  2 13:18:06 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Tue,  2 Feb 2016 19:18:06 -0200
Subject: [PATCH] ARM: mx25: Add basic suspend/resume support
Message-ID: <1454447886-4045-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at nxp.com>

Tested basic suspend/resume on a mx25pdk:

$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
$ echo mem > /sys/power/state

Then press any key in the serial console and the system wakes up.

Signed-off-by: Fabio Estevam <fabio.estevam at nxp.com>
---
 arch/arm/mach-imx/Makefile     |  2 +-
 arch/arm/mach-imx/common.h     |  1 +
 arch/arm/mach-imx/mach-imx25.c |  1 +
 arch/arm/mach-imx/pm-imx25.c   | 41 +++++++++++++++++++++++++++++++++++++++++
 4 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-imx/pm-imx25.c

diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index fb689d8..9fbe624 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -3,7 +3,7 @@ obj-y := cpu.o system.o irq-common.o
 obj-$(CONFIG_SOC_IMX1) += mm-imx1.o
 obj-$(CONFIG_SOC_IMX21) += mm-imx21.o
 
-obj-$(CONFIG_SOC_IMX25) += cpu-imx25.o mach-imx25.o
+obj-$(CONFIG_SOC_IMX25) += cpu-imx25.o mach-imx25.o pm-imx25.o
 
 obj-$(CONFIG_SOC_IMX27) += cpu-imx27.o pm-imx27.o
 obj-$(CONFIG_SOC_IMX27) += mm-imx27.o ehci-imx27.o
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 32b83f0..58a3846 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -66,6 +66,7 @@ void imx_gpc_check_dt(void);
 void imx_gpc_set_arm_power_in_lpm(bool power_off);
 void imx_gpc_set_arm_power_up_timing(u32 sw2iso, u32 sw);
 void imx_gpc_set_arm_power_down_timing(u32 sw2iso, u32 sw);
+void imx25_pm_init(void);
 
 enum mxc_cpu_pwr_mode {
 	WAIT_CLOCKED,		/* wfi only */
diff --git a/arch/arm/mach-imx/mach-imx25.c b/arch/arm/mach-imx/mach-imx25.c
index 9379fd0..32dcb5e 100644
--- a/arch/arm/mach-imx/mach-imx25.c
+++ b/arch/arm/mach-imx/mach-imx25.c
@@ -41,6 +41,7 @@ static const char * const imx25_dt_board_compat[] __initconst = {
 
 DT_MACHINE_START(IMX25_DT, "Freescale i.MX25 (Device Tree Support)")
 	.init_early	= imx25_init_early,
+	.init_late      = imx25_pm_init,
 	.init_irq	= mx25_init_irq,
 	.dt_compat	= imx25_dt_board_compat,
 MACHINE_END
diff --git a/arch/arm/mach-imx/pm-imx25.c b/arch/arm/mach-imx/pm-imx25.c
new file mode 100644
index 0000000..cd27c4c
--- /dev/null
+++ b/arch/arm/mach-imx/pm-imx25.c
@@ -0,0 +1,41 @@
+/*
+ * Copyright 2016 NXP Semiconductors
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/suspend.h>
+#include <linux/io.h>
+
+#ifdef CONFIG_PM
+static int imx25_suspend_enter(suspend_state_t state)
+{
+	switch (state) {
+	case PM_SUSPEND_MEM:
+		cpu_do_idle();
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+#else
+static inline int imx25_suspend_enter(suspend_state_t state)
+{
+	return 0;
+}
+#endif
+
+static const struct platform_suspend_ops imx25_suspend_ops = {
+	.enter = imx25_suspend_enter,
+	.valid = suspend_valid_only_mem,
+};
+
+void __init imx25_pm_init(void)
+{
+	suspend_set_ops(&imx25_suspend_ops);
+}
-- 
1.9.1



From heiko at sntech.de  Tue Feb  2 13:19:38 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 02 Feb 2016 22:19:38 +0100
Subject: [PATCH] soc: rockchip: power-domain: fix err handle while probing
In-Reply-To: <1454314720-6391-1-git-send-email-shawn.lin@rock-chips.com>
References: <1454314720-6391-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <50160822.GDSasZvf15@diego>

Am Montag, 1. Februar 2016, 16:18:40 schrieb Shawn Lin:
> If we fail to probe the driver, we should not directly break
> from the for_each_available_child_of_node since it calls of_node_get
> while iterating. This patch add of_node_put to fix the unbalanced
> call pair.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

applied to my drivers-branch for 4.6


Thanks
Heiko


From robh at kernel.org  Tue Feb  2 13:19:43 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 2 Feb 2016 15:19:43 -0600
Subject: [PATCH 01/10] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160202211943.GA18698@rob-hp-laptop>

On Tue, Feb 02, 2016 at 07:07:39PM +0100, Gregory CLEMENT wrote:
> From: Wilson Ding <dingwei at marvell.com>
> 
> Armada-3700's uart is a simple serial port, which doesn't
> support. Configuring the modem control lines. The uart port has a 32
> bytes Tx FIFO and a 64 bytes Rx FIFO
> 
> The uart driver implements the uart core operations. It also support the
> system (early) console based on Armada-3700's serial port.
> 
> Known Issue:
> 
> The uart driver currently doesn't support clock programming, which means
> the baud-rate stays with the default value configured by the bootloader
> at boot time
> 
> [gregory.clement at free-electrons.com: Rewrite many part which are too long
> to enumerate]
> 
> Signed-off-by: Wilson Ding <dingwei at marvell.com>
> Signed-off-by: Nadav Haklai <nadavh at marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  .../devicetree/bindings/tty/serial/mvebu-uart.txt  |  13 +

Acked-by: Rob Herring <robh at kernel.org>

>  Documentation/kernel-parameters.txt                |   6 +
>  drivers/tty/serial/Kconfig                         |  22 +
>  drivers/tty/serial/Makefile                        |   1 +
>  drivers/tty/serial/mvebu-uart.c                    | 649 +++++++++++++++++++++
>  include/uapi/linux/serial_core.h                   |   3 +
>  6 files changed, 694 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
>  create mode 100644 drivers/tty/serial/mvebu-uart.c


From robh at kernel.org  Tue Feb  2 13:20:15 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 2 Feb 2016 15:20:15 -0600
Subject: [PATCH 04/10] Documentation: dt-bindings: Add a new compatible
 for the Armada 3700
In-Reply-To: <1454436468-4241-5-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-5-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160202212015.GA21364@rob-hp-laptop>

On Tue, Feb 02, 2016 at 07:07:42PM +0100, Gregory CLEMENT wrote:
> The AHCI interfaces used in the Armada 3700 has a few differences with
> the one used in the Armada 38x, so it deserves its own compatible string.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  Documentation/devicetree/bindings/ata/ahci-platform.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <robh at kernel.org>


From stillcompiling at gmail.com  Tue Feb  2 13:21:20 2016
From: stillcompiling at gmail.com (Joshua Clayton)
Date: Tue, 2 Feb 2016 13:21:20 -0800
Subject: [PATCH 2/2] ARM: dts: Add dts for Uniwest evi
In-Reply-To: <20160201121145.GE10671@tiger>
References: <b11bf2208fe30b96c4d82e634e8abe04343754de.1452717014.git.stillcompiling@gmail.com>
 <66c87b9536b674bdedfdbe2306def8e9bf6a585c.1452717014.git.stillcompiling@gmail.com>
 <20160201121145.GE10671@tiger>
Message-ID: <20160202132120.6c8e86b9@jclayton-pc>

Shawn,
thanks for the review.
I've tried to address your concerns.
I have a new dts which I will send once I've booted it.

On Mon, 1 Feb 2016 20:11:45 +0800
Shawn Guo <shawnguo at kernel.org> wrote:

...
> > +	regulators {
> > +		compatible = "simple-bus";
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		reg_usbh1_vbus: regulator at 0 {
> > +			compatible = "regulator-fixed";
> > +			reg = <0>;
> > +			regulator-name = "usbh1_vbus";
> > +			regulator-min-microvolt = <5000000>;
> > +			regulator-max-microvolt = <5000000>;
> > +			enable-active-high;
> > +			startup-delay-us = <2>;
> > +			pinctrl-names = "default";
> > +			pinctrl-0 = <&pinctrl_usbh1_hubreset>;
> > +			gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
> > +		};
> 
> Device tree maintainers do not like the fake simple-bus container for
> these fixed regulators.  We are asked to put them directly under root
> node.  In that case, we do not need the artificial 'reg' property, and
> we can name node in schema like:
> 
> 	reg_xxx: regulator-xxx {
> 		...
> 	}
>
OK. will do.  
> > +
> > +		reg_usb_otg_vbus: regulator at 1 {
> > +			compatible = "regulator-fixed";
> > +			reg = <1>;
> > +			regulator-name = "usb_otg_vbus";
> > +			regulator-min-microvolt = <5000000>;
> > +			regulator-max-microvolt = <5000000>;
> > +			pinctrl-names = "default";
> > +			pinctrl-0 = <&pinctrl_usbotg_vbus>;
> > +			gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
> > +			enable-active-high;
> > +			regulator-always-on;
> > +		};
> > +	};
> 
> Have a new line between nodes.
OK.
> 
> > +	chosen {
> > +		bootargs = "sbs-battery.force_load=1";
> > +	};
> 
> We generally put 'chosen' node at the beginning along with 'memory'
> node.  And do we really need this as the default bootargs?

It is needed because if the battery is not installed at boot time,
the device fails to probe as the dts is being parsed, and there is
no way for the kernel to be made aware later.

I guess I could put this into uboot kernel args instead...
I'll remove it for now.

> > +
> > +	panel {
> > +		compatible = "sharp,lq101k1ly04";
> 
> Undocumented compatible string.

This is making its way through the drm list. Its a simple-panel
compatible set of timings. 

> 
> > +
> > +		port {
> > +			panel_in: endpoint {
> > +				remote-endpoint = <&lvds0_out>;
> > +			};
> > +		};
> > +	};
> > +};
> > +
> > +&ecspi1 {
> > +	fsl,spi-num-chipselects = <1>;
> > +	cs-gpios = <&gpio4 10 GPIO_ACTIVE_LOW>;
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_ecspi1_extra>;
> 
> You use only one GPIO in cs-gpios.  Why do you need to set up 3 in
> pinctrl_ecspi1_extra?  And why do you name the pinctrl group in the
> same way as ecspi3 and ecspi5, i.e. pinctrl_ecspi1_cs?

There is only 1 chip select for this spi node.
The extra pins are related to a not-yet-upstreamed driver.
I'll remove them and call it pinctrl_ecspi1_cs

> 
> > +	status = "okay";
> > +};
> > +
> > +&ecspi3 {
> > +	fsl,spi-num-chipselects = <3>;
> > +	cs-gpios = <&gpio4 24 GPIO_ACTIVE_LOW>,
> > +		<&gpio4 25 GPIO_ACTIVE_LOW>,
> > +		<&gpio4 26 GPIO_ACTIVE_LOW>;
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs>;
> > +	status = "okay";
> > +};
> > +
> > +&ecspi5 {
> > +	fsl,spi-num-chipselects = <4>;
> > +	cs-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>,
> > +		<&gpio1 13 GPIO_ACTIVE_LOW>,
> > +		<&gpio1 12 GPIO_ACTIVE_LOW>,
> > +		<&gpio2 9 GPIO_ACTIVE_HIGH>;
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_ecspi5 &pinctrl_ecspi5_cs>;
> > +	status = "okay";
> 
> Have a new line between properties and sub-node.

Will do. Thanks.

> 
> > +	eeprom: m95m02 at 1 {
> > +		compatible = "st,m95m02", "atmel,at25";
> > +		size = <262144>;
> > +		pagesize = <256>;
> > +		address-width = <24>;
> > +		spi-max-frequency = <5000000>;
> > +		reg = <1>;
> > +	};
> 
> Have a new line between nodes.

OK.

> 
> > +	pb_rtc: rtc at 3 {
> > +		compatible = "nxp,rtc-pcf2123";
> > +		spi-max-frequency = <2450000>;
> > +		spi-cs-high;
> > +		reg = <3>;
> > +	};
> > +};
> > +
> > +&fec {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_enet>;
> > +	phy-mode = "rgmii";
> > +	phy-reset-gpios = <&gpio1 25 0>;
> > +	status = "okay";
> > +};
> > +
> > +&gpmi {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_gpmi_nand>;
> > +	status = "okay";
> > +};
> > +
> > +&i2c2 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_i2c2>;
> > +	clock-frequency = <100000>;
> > +	status = "okay";
> > +};
> > +
> > +&i2c3 {
> > +	pinctrl-names = "default", "gpio";
> > +	pinctrl-0 = <&pinctrl_i2c3>;
> > +	pinctrl-1 = <&pinctrl_i2c3_gpio>;
> > +	clock-frequency = <100000>;
> > +	status = "okay";
> 
> We generally put 'status' at the bottom of the property list.

Will move it.

> 
> > +	scl-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
> > +	sda-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>;
> > +
> > +	battery: sbs-battery at b {
> > +		compatible = "sbs,sbs-battery";
> > +		reg = <0x0b>;
> > +		sbs,poll-retry-count = <100>;
> > +		sbs,i2c-retry-count = <100>;
> > +	};
> > +};
> > +
> > +&ldb {
> > +	status = "okay";
> > +
> > +	lvds0: lvds-channel at 0 {
> > +		fsl,data-mapping = "jeida";
> > +		fsl,data-width = <24>;
> > +		status = "okay";
> > +
> > +		port at 4 {
> > +			reg = <4>;
> > +
> > +			lvds0_out: endpoint {
> > +				remote-endpoint = <&panel_in>;
> > +			};
> > +		};
> > +	};
> > +};
> > +
> > +&ssi1 {
> > +	fsl,mode = "i2s-slave";
> 
> "i2s-slave" is deprecated for fsl,mode, and can be just dropped.

OK.

> 
> > +	status = "okay";
> > +};
> > +
> > +&uart1 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_uart1>;
> > +	status = "okay";
> > +};
> > +
> > +&uart2 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_uart2>;
> > +	status = "okay";
> > +};
> > +
> > +&usbh1 {
> > +	vbus-supply = <&reg_usbh1_vbus>;
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_usbh1>;
> > +	dr_mode = "host";
> > +	disable-over-current;
> > +	status = "okay";
> > +};
> > +
> > +&usbotg {
> > +	vbus-supply = <&reg_usb_otg_vbus>;
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_usbotg>;
> > +	disable-over-current;
> > +	dr_mode = "otg";
> > +	status = "okay";
> > +};
> > +
> > +&usdhc1 {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_usdhc1>;
> > +	non-removable;
> > +	status = "okay";
> > +};
> > +
> > +&weim {
> > +	#address-cells = <2>;
> > +	#size-cells = <1>;
> > +	ranges = <0 0 0x08000000 0x08000000>;
> > +	fsl,weim-cs-gpr = <&gpr>;
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_weim_fpga &pinctrl_weim_cs>;
> > +	status = "okay";
> > +};
> > +
> > +&iomuxc {
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_hog>;
> > +
> > +	imx6q-evi {
> 
> Since commit 5fcdf6a7ed95 (pinctrl: imx: Allow parsing DT without
> function nodes), this additional container node can just be saved.

So these should be directly under iomux... ok. Will do 
> 
> > +		pinctrl_hog: hoggrp {
> > +			fsl,pins = <
> > +				/* CPLD Reset */
> > +				MX6QDL_PAD_GPIO_19__GPIO4_IO05
> > 0x1b0b0
> > +				/* pwr mcu alert irq */
> > +				MX6QDL_PAD_SD4_DAT2__GPIO2_IO10
> > 0x1b0b0
> > +				/* remainder ???? */
> > +				MX6QDL_PAD_CSI0_MCLK__GPIO5_IO19
> > 0x1b0b0
> > +			>;
> > +		};
> 
> Have a new line between nodes.

OK.

> 
> > +		pinctrl_ecspi1: ecspi1grp {
> > +			fsl,pins = <
> > +				MX6QDL_PAD_KEY_COL1__ECSPI1_MISO
> > 0x100b1
> > +				MX6QDL_PAD_KEY_ROW0__ECSPI1_MOSI
> > 0x100b1
> > +				MX6QDL_PAD_KEY_COL0__ECSPI1_SCLK
> > 0x100b1
> > +			>;
> > +		};
> > +		pinctrl_ecspi1_extra: ecspi1extragrp {
> > +			fsl,pins = <
> > +				MX6QDL_PAD_KEY_COL2__GPIO4_IO10
> > 0x1b0b0
> > +				MX6QDL_PAD_KEY_ROW1__GPIO4_IO09
> > 0x1b0b0
> > +				MX6QDL_PAD_KEY_ROW2__GPIO4_IO11
> > 0x1b0b0
> > +			>;
> > +		};
> > +		pinctrl_ecspi3: ecspi3grp {
> > +			fsl,pins = <
> > +				MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK
> > 0x10068
> > +				MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI
> > 0x10068
> > +				MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO
> > 0x1f068
> > +			>;
> > +		};
> > +		pinctrl_ecspi3_cs: ecspi3cs {
> 
> Please name the node consistently, like xxxgrp.

OK.

> 
> > +			fsl,pins = <
> > +				MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24
> > 0x1b0b0
> > +				MX6QDL_PAD_DISP0_DAT4__GPIO4_IO25
> > 0x1b0b0
> > +				MX6QDL_PAD_DISP0_DAT5__GPIO4_IO26
> > 0x1b0b0
> > +				MX6QDL_PAD_DISP0_DAT6__GPIO4_IO27
> > 0x1b0b0
> > +			>;
> > +		};
> > +		pinctrl_ecspi5: ecspi5grp {
> > +			fsl,pins = <
> > +				MX6QDL_PAD_SD2_CLK__ECSPI5_SCLK
> > 0x100b1
> > +				MX6QDL_PAD_SD2_CMD__ECSPI5_MOSI
> > 0x100b1
> > +				MX6QDL_PAD_SD2_DAT0__ECSPI5_MISO
> > 0x100b1
> > +			>;
> > +		};
> > +		pinctrl_ecspi5_cs: ecspi5cs {
> > +			fsl,pins = <
> > +				MX6QDL_PAD_SD2_DAT1__GPIO1_IO14
> > 0x1b0b0
> > +				MX6QDL_PAD_SD2_DAT2__GPIO1_IO13
> > 0x1b0b0
> > +				MX6QDL_PAD_SD2_DAT3__GPIO1_IO12
> > 0x1b0b0
> > +				MX6QDL_PAD_SD4_DAT1__GPIO2_IO09
> > 0x1b0b0
> > +			>;
> > +		};
> > +		pinctrl_enet: enetgrp {
> > +			fsl,pins = <
> > +				MX6QDL_PAD_ENET_MDIO__ENET_MDIO
> > 0x1b0b0
> > +				MX6QDL_PAD_ENET_MDC__ENET_MDC
> > 0x1b0b0
> > +				MX6QDL_PAD_RGMII_TXC__RGMII_TXC
> > 0x1b0b0
> > +				MX6QDL_PAD_RGMII_TD0__RGMII_TD0
> > 0x1b0b0
> > +				MX6QDL_PAD_RGMII_TD1__RGMII_TD1
> > 0x1b0b0
> > +				MX6QDL_PAD_RGMII_TD2__RGMII_TD2
> > 0x1b0b0
> > +				MX6QDL_PAD_RGMII_TD3__RGMII_TD3
> > 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
> > +
> > MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
> > +				MX6QDL_PAD_RGMII_RXC__RGMII_RXC
> > 0x1b0b0
> > +				MX6QDL_PAD_RGMII_RD0__RGMII_RD0
> > 0x1b0b0
> > +				MX6QDL_PAD_RGMII_RD1__RGMII_RD1
> > 0x1b0b0
> > +				MX6QDL_PAD_RGMII_RD2__RGMII_RD2
> > 0x1b0b0
> > +				MX6QDL_PAD_RGMII_RD3__RGMII_RD3
> > 0x1b0b0
> > +
> > MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
> > +				MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN
> > 0x4001b0a8
> > +				MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25
> > 0x1b0b0
> > +			>;
> > +		};
> > +		pinctrl_gpmi_nand: gpminandgrp {
> > +			fsl,pins = <
> > +				MX6QDL_PAD_NANDF_CLE__NAND_CLE
> > 0xb0b1
> > +				MX6QDL_PAD_NANDF_ALE__NAND_ALE
> > 0xb0b1
> > +				MX6QDL_PAD_NANDF_WP_B__NAND_WP_B
> > 0xb0b1
> > +				MX6QDL_PAD_NANDF_RB0__NAND_READY_B
> > 0xb000
> > +				MX6QDL_PAD_NANDF_CS0__NAND_CE0_B
> > 0xb0b1
> > +				MX6QDL_PAD_NANDF_CS1__NAND_CE1_B
> > 0xb0b1
> > +				MX6QDL_PAD_SD4_CMD__NAND_RE_B
> > 0xb0b1
> > +				MX6QDL_PAD_SD4_CLK__NAND_WE_B
> > 0xb0b1
> > +				MX6QDL_PAD_NANDF_D0__NAND_DATA00
> > 0xb0b1
> > +				MX6QDL_PAD_NANDF_D1__NAND_DATA01
> > 0xb0b1
> > +				MX6QDL_PAD_NANDF_D2__NAND_DATA02
> > 0xb0b1
> > +				MX6QDL_PAD_NANDF_D3__NAND_DATA03
> > 0xb0b1
> > +				MX6QDL_PAD_NANDF_D4__NAND_DATA04
> > 0xb0b1
> > +				MX6QDL_PAD_NANDF_D5__NAND_DATA05
> > 0xb0b1
> > +				MX6QDL_PAD_NANDF_D6__NAND_DATA06
> > 0xb0b1
> > +				MX6QDL_PAD_NANDF_D7__NAND_DATA07
> > 0xb0b1
> > +				MX6QDL_PAD_SD4_DAT0__NAND_DQS
> > 0x00b1
> > +			>;
> > +		};
> > +		pinctrl_i2c2: i2c2grp {
> > +			fsl,pins = <
> > +				MX6QDL_PAD_KEY_ROW3__I2C2_SDA
> > 0x4001b8b1
> > +				MX6QDL_PAD_KEY_COL3__I2C2_SCL
> > 0x4001b8b1
> > +			>;
> > +		};
> > +		pinctrl_i2c3: i2c3grp {
> > +			fsl,pins = <
> > +				MX6QDL_PAD_GPIO_5__I2C3_SCL
> > 0x4001b8b1
> > +				MX6QDL_PAD_GPIO_16__I2C3_SDA
> > 0x4001b8b1
> > +			>;
> > +		};
> > +		pinctrl_i2c3_gpio: i2c3gpiogrp {
> > +			fsl,pins = <
> > +				MX6QDL_PAD_GPIO_5__GPIO1_IO05
> > 0x4001b8b1
> > +				MX6QDL_PAD_GPIO_16__GPIO7_IO11
> > 0x4001b8b1
> > +			>;
> > +		};
> > +		pinctrl_weim_cs: weim_csgrp {
> 
> weimcsgrp
No underscore. OK.
> 
> > +			fsl,pins = <
> > +				MX6QDL_PAD_EIM_CS0__EIM_CS0_B
> > 0xb0b1
> > +				MX6QDL_PAD_EIM_CS1__EIM_CS1_B
> > 0xb0b1
> > +			>;
> > +		};
> > +		pinctrl_weim_fpga: weim_fpgagrp {
> 
> weimfpgagrp

No underscore. OK.

...

Thanks,


From k at japko.eu  Tue Feb  2 13:21:48 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Tue,  2 Feb 2016 22:21:48 +0100
Subject: [PATCH v2 0/5] pinctrl: sunxi: Add H3 R_PIO controller support
Message-ID: <1454448113-18810-1-git-send-email-k@japko.eu>

This patch series is extension of my original single patch with the
same subject. It adds support for R_PIO so that GPIO port L can be
used in H3 based devices. It was tested on OrangePi PC where PL is
connected amount others to an onboard led, a switch and IR receiver and
some VCC controllers.

Patchset was based on next-20160129.

--- 

Changes since v1:
- splited patch to two separate - dtsi and c files
- added APB0 clocks a parent for R_PIO
- added fix in sunxi_pinctrl_gpio_get for getting pin value when in irq
  mode and on 2nd pinctrl
- fixed a "pwn" > "pwm" typo
- fixed order in allwinner,sunxi-pinctrl.txt


Krzysztof Adamski (5):
  clk: sunxi: Add apb0 gates for H3
  dts: sun8i-h3: Add APB0 related clocks and resets
  pinctrl: sunxi: Add H3 R_PIO controller support
  ARM: dts: sun8i-h3: Add R_PIO controller node to the dtsi
  pinctrl: sunxi: Use pin number when calling sunxi_pmx_set

 Documentation/devicetree/bindings/clock/sunxi.txt  |   1 +
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 arch/arm/boot/dts/sun8i-h3.dtsi                    |  44 +++++++++
 drivers/clk/sunxi/clk-simple-gates.c               |   2 +
 drivers/pinctrl/sunxi/Kconfig                      |   4 +
 drivers/pinctrl/sunxi/Makefile                     |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c         | 106 +++++++++++++++++++++
 drivers/pinctrl/sunxi/pinctrl-sunxi.c              |   9 +-
 8 files changed, 165 insertions(+), 3 deletions(-)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c

-- 
2.1.4



From k at japko.eu  Tue Feb  2 13:21:50 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Tue,  2 Feb 2016 22:21:50 +0100
Subject: [PATCH v2 2/5] dts: sun8i-h3: Add APB0 related clocks and resets
In-Reply-To: <1454448113-18810-1-git-send-email-k@japko.eu>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
Message-ID: <1454448113-18810-3-git-send-email-k@japko.eu>

APB0 is bearly mentioned in H3 User Manual and it is only setup in the
Allwinners kernel dump for CIR. I have verified experimentally that the
gate for R_PIO exists and works, though. There are probably other gates
there but I don't know their order right now and I don't have access to
their peripherals on my board to test them.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 1524130e..ce35e93 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -276,6 +276,32 @@
 			clocks = <&osc24M>, <&pll6 1>, <&pll5>;
 			clock-output-names = "mbus";
 		};
+
+		ahb0: ahb0_clk {
+			compatible = "fixed-factor-clock";
+			#clock-cells = <0>;
+			clock-div = <1>;
+			clock-mult = <1>;
+			clocks = <&osc24M>, <&osc32k>;
+			clock-output-names = "ahb0";
+		};
+
+		apb0: clk at 01f0140c {
+			compatible = "allwinner,sun8i-a23-apb0-clk";
+			reg = <0x01f0140c 0x4>;
+			#clock-cells = <0>;
+			clocks = <&ahb0>;
+			clock-output-names = "apb0";
+		};
+
+		apb0_gates: clk at 01f01428 {
+			compatible = "allwinner,sun8i-h3-abp0-gates-clk";
+			reg = <0x01f01428 0x4>;
+			#clock-cells = <1>;
+			clocks = <&apb0>;
+			clock-indices = <0>, <1>;
+			clock-output-names = "apb0_pio", "apb0_ir";
+		};
 	};
 
 	soc {
@@ -493,5 +519,11 @@
 			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
 		};
+
+		apb0_reset: reset at 01f014b0 {
+			reg = <0x01f014b0 0x4>;
+			compatible = "allwinner,sun6i-a31-clock-reset";
+			#reset-cells = <1>;
+		};
 	};
 };
-- 
2.1.4



From k at japko.eu  Tue Feb  2 13:21:49 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Tue,  2 Feb 2016 22:21:49 +0100
Subject: [PATCH v2 1/5] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <1454448113-18810-1-git-send-email-k@japko.eu>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
Message-ID: <1454448113-18810-2-git-send-email-k@japko.eu>

This patch adds support for APB0 in H3. It seems to be compatible with
earlier SOCs. apb0 gates controls R_ block peripherals (R_PIO, R_IR,
etc).

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
 drivers/clk/sunxi/clk-simple-gates.c              | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index e59f57b..6ee6875 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -32,6 +32,7 @@ Required properties:
 	"allwinner,sun8i-h3-ahb2-clk" - for the AHB2 clock on H3
 	"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
 	"allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
+	"allwinner,sun8i-h3-abp0-gates-clk" - for the APB0 gates on H3
 	"allwinner,sun9i-a80-ahb0-gates-clk" - for the AHB0 gates on A80
 	"allwinner,sun9i-a80-ahb1-gates-clk" - for the AHB1 gates on A80
 	"allwinner,sun9i-a80-ahb2-gates-clk" - for the AHB2 gates on A80
diff --git a/drivers/clk/sunxi/clk-simple-gates.c b/drivers/clk/sunxi/clk-simple-gates.c
index f4da52b..8a1fa3e 100644
--- a/drivers/clk/sunxi/clk-simple-gates.c
+++ b/drivers/clk/sunxi/clk-simple-gates.c
@@ -130,6 +130,8 @@ CLK_OF_DECLARE(sun8i_a23_apb2, "allwinner,sun8i-a23-apb2-gates-clk",
 	       sunxi_simple_gates_init);
 CLK_OF_DECLARE(sun8i_a33_ahb1, "allwinner,sun8i-a33-ahb1-gates-clk",
 	       sunxi_simple_gates_init);
+CLK_OF_DECLARE(sun8i_h3_abp0, "allwinner,sun8i-h3-abp0-gates-clk",
+	       sunxi_simple_gates_init);
 CLK_OF_DECLARE(sun9i_a80_ahb0, "allwinner,sun9i-a80-ahb0-gates-clk",
 	       sunxi_simple_gates_init);
 CLK_OF_DECLARE(sun9i_a80_ahb1, "allwinner,sun9i-a80-ahb1-gates-clk",
-- 
2.1.4



From k at japko.eu  Tue Feb  2 13:21:51 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Tue,  2 Feb 2016 22:21:51 +0100
Subject: [PATCH v2 3/5] pinctrl: sunxi: Add H3 R_PIO controller support
In-Reply-To: <1454448113-18810-1-git-send-email-k@japko.eu>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
Message-ID: <1454448113-18810-4-git-send-email-k@japko.eu>

H3 has additional PIO controller similar to what we can find on A23.
It's a 12 pin port, described in H3 Datasheet rev 1.1, pages 345-350.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 drivers/pinctrl/sunxi/Kconfig              |   4 ++
 drivers/pinctrl/sunxi/Makefile             |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c | 106 +++++++++++++++++++++++++++++
 3 files changed, 111 insertions(+)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c

diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index f8dbc8b..75a26c9 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -55,6 +55,10 @@ config PINCTRL_SUN8I_H3
 	def_bool MACH_SUN8I
 	select PINCTRL_SUNXI_COMMON
 
+config PINCTRL_SUN8I_H3_R
+	def_bool MACH_SUN8I
+	select PINCTRL_SUNXI_COMMON
+
 config PINCTRL_SUN9I_A80
 	def_bool MACH_SUN9I
 	select PINCTRL_SUNXI_COMMON
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index ef82f22..a5d56f1 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -14,5 +14,6 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23_R)	+= pinctrl-sun8i-a23-r.o
 obj-$(CONFIG_PINCTRL_SUN8I_A33)		+= pinctrl-sun8i-a33.o
 obj-$(CONFIG_PINCTRL_SUN8I_A83T)	+= pinctrl-sun8i-a83t.o
 obj-$(CONFIG_PINCTRL_SUN8I_H3)		+= pinctrl-sun8i-h3.o
+obj-$(CONFIG_PINCTRL_SUN8I_H3_R)	+= pinctrl-sun8i-h3-r.o
 obj-$(CONFIG_PINCTRL_SUN9I_A80)		+= pinctrl-sun9i-a80.o
 obj-$(CONFIG_PINCTRL_SUN9I_A80_R)	+= pinctrl-sun9i-a80-r.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
new file mode 100644
index 0000000..686ec21
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
@@ -0,0 +1,106 @@
+/*
+ * Allwinner H3 SoCs pinctrl driver.
+ *
+ * Copyright (C) 2016 Krzysztof Adamski <k at japko.eu>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/pinctrl.h>
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin sun8i_h3_r_pins[] = {
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_twi"),         /* SCK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),	/* PL_EINT0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_twi"),         /* SDA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),	/* PL_EINT1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_uart"),        /* TX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),	/* PL_EINT2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_uart"),        /* RX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),	/* PL_EINT3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* MS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),	/* PL_EINT4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* CK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),	/* PL_EINT5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* DO */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),	/* PL_EINT6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* DI */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),	/* PL_EINT7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),	/* PL_EINT8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),	/* PL_EINT9 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_pwm"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)),	/* PL_EINT10 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_cir_rx"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 11)),	/* PL_EINT11 */
+};
+
+static const struct sunxi_pinctrl_desc sun8i_h3_r_pinctrl_data = {
+	.pins = sun8i_h3_r_pins,
+	.npins = ARRAY_SIZE(sun8i_h3_r_pins),
+	.irq_banks = 1,
+	.pin_base = PL_BASE,
+	.irq_read_needs_mux = true
+};
+
+static int sun8i_h3_r_pinctrl_probe(struct platform_device *pdev)
+{
+	return sunxi_pinctrl_init(pdev,
+				  &sun8i_h3_r_pinctrl_data);
+}
+
+static const struct of_device_id sun8i_h3_r_pinctrl_match[] = {
+	{ .compatible = "allwinner,sun8i-h3-r-pinctrl", },
+	{}
+};
+
+static struct platform_driver sun8i_h3_r_pinctrl_driver = {
+	.probe	= sun8i_h3_r_pinctrl_probe,
+	.driver	= {
+		.name		= "sun8i-h3-r-pinctrl",
+		.of_match_table	= sun8i_h3_r_pinctrl_match,
+	},
+};
+builtin_platform_driver(sun8i_h3_r_pinctrl_driver);
-- 
2.1.4



From k at japko.eu  Tue Feb  2 13:21:52 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Tue,  2 Feb 2016 22:21:52 +0100
Subject: [PATCH v2 4/5] ARM: dts: sun8i-h3: Add R_PIO controller node to the
 dtsi
In-Reply-To: <1454448113-18810-1-git-send-email-k@japko.eu>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
Message-ID: <1454448113-18810-5-git-send-email-k@japko.eu>

Add the corresponding device node for R_PIO on H3 to the dtsi. Support
for the controller was added in earlier commit.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 .../devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt  |  1 +
 arch/arm/boot/dts/sun8i-h3.dtsi                              | 12 ++++++++++++
 2 files changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index 9213b27..3e56b16 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -21,6 +21,7 @@ Required properties:
   "allwinner,sun9i-a80-r-pinctrl"
   "allwinner,sun8i-a83t-pinctrl"
   "allwinner,sun8i-h3-pinctrl"
+  "allwinner,sun8i-h3-r-pinctrl"
 
 - reg: Should contain the register physical address and length for the
   pin controller.
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index ce35e93..1593e2d 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -525,5 +525,17 @@
 			compatible = "allwinner,sun6i-a31-clock-reset";
 			#reset-cells = <1>;
 		};
+
+		r_pio: pinctrl at 01f02c00 {
+			compatible = "allwinner,sun8i-h3-r-pinctrl";
+			reg = <0x01f02c00 0x400>;
+			interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&apb0_gates 0>;
+			resets = <&apb0_reset 0>;
+			gpio-controller;
+			#gpio-cells = <3>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
 	};
 };
-- 
2.1.4



From k at japko.eu  Tue Feb  2 13:21:53 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Tue,  2 Feb 2016 22:21:53 +0100
Subject: [PATCH v2 5/5] pinctrl: sunxi: Use pin number when calling
 sunxi_pmx_set
In-Reply-To: <1454448113-18810-1-git-send-email-k@japko.eu>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
Message-ID: <1454448113-18810-6-git-send-email-k@japko.eu>

sunxi_pmx_set accepts pin number and then calculates offset by
subtracting pin_base from it. sunxi_pinctrl_gpio_get, on the other hand,
gets offset so we have to convert it to pin number so we won't get
negative value in sunxi_pmx_set.

This was only used on A10 so far, where there is only one GPIO chip with
pin_base set to 0 so it didn't matter. However H3 also requires this
workaround but have two pinmux sections, triggering problem for PL port.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 drivers/pinctrl/sunxi/pinctrl-sunxi.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 7a2465f..9e5bac9 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -460,14 +460,17 @@ static int sunxi_pinctrl_gpio_get(struct gpio_chip *chip, unsigned offset)
 	u32 set_mux = pctl->desc->irq_read_needs_mux &&
 			test_bit(FLAG_USED_AS_IRQ, &chip->desc[offset].flags);
 	u32 val;
+	u32 pin;
 
-	if (set_mux)
-		sunxi_pmx_set(pctl->pctl_dev, offset, SUN4I_FUNC_INPUT);
+	if (set_mux) {
+		pin = offset + pctl->desc->pin_base;
+		sunxi_pmx_set(pctl->pctl_dev, pin, SUN4I_FUNC_INPUT);
+	}
 
 	val = (readl(pctl->membase + reg) >> index) & DATA_PINS_MASK;
 
 	if (set_mux)
-		sunxi_pmx_set(pctl->pctl_dev, offset, SUN4I_FUNC_IRQ);
+		sunxi_pmx_set(pctl->pctl_dev, pin, SUN4I_FUNC_IRQ);
 
 	return !!val;
 }
-- 
2.1.4



From stern at rowland.harvard.edu  Tue Feb  2 13:24:55 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 2 Feb 2016 16:24:55 -0500 (EST)
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFokWcLSCAh_TX-j-df_M1hN8Qw1gbQt--SyWccGCPiN5Q@mail.gmail.com>
Message-ID: <Pine.LNX.4.44L0.1602021614430.1653-100000@iolanthe.rowland.org>

On Tue, 2 Feb 2016, Ulf Hansson wrote:

> > ?  pm_runtime_put_sync() _already_ does not respect the autosuspend
> > mode.  If you want to respect it, you have to call
> > pm_runtime_put_sync_autosuspend() instead.
> 
> Then there's a bug in the runtime PM core.
> 
> From Tony's regression report and from mine own local runtime PM test
> driver, I can see that the device doesn't get RPM_SUSPENDED (the
> ->runtime_suspend() callback isn't called), even when the usage count
> is zero - when pm_runtime_put_sync() is called.

Ah, yes -- I see what's going on.  pm_runtime_put_sync() calls 
__pm_runtime_idle(), rather than __pm_runtime_suspend().  And the idle 
routine always forces RPM_AUTO on.

So what I said was wrong.  pm_runtime_put_sync() respects the driver's 
settings for autosuspend, whereas pm_runtime_put_sync_suspend() and 
pm_runtime_put_sync_autosuspend() override the settings.

> To find the sequence of runtime PM commands, go ahead an have look in
> the omap_hsmmc driver. The problem occurs when the driver bails out in
> probe, when it receives -EPROBE_DEFER when fetching regulators.
> 
> I have some more data to share on this problem from my runtime PM test
> driver. I will try my best to share it tomorrow.

> >> 2)
> >> Change the failing drivers, to before calling pm_runtime_put_sync()
> >> also invoke pm_runtime_dont_use_autosusend(). Or other similar
> >> approach.
> >
> > Given the above, this seems unnecessary.
> 
> Okay, so you are saying that the pm_runtime_put_sync() should idle the
> device even if autosuspend is in use. That seems reasonable, I will
> look into this problem.

Heh -- you are the person who did it.  :-)  See commit d66e6db28df3 
("PM / Runtime: Respect autosuspend when idle triggers suspend").

I guess the intention was that if the driver wants to specify whether 
autosuspend should be respected, it should implement an rpm_idle 
callback routine.

Alan Stern



From robh at kernel.org  Tue Feb  2 13:24:54 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 2 Feb 2016 15:24:54 -0600
Subject: [PATCH 06/10] devicetree: bindings: add DT binding for the
 Marvell Armada 3700 SoC family
In-Reply-To: <1454436468-4241-7-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-7-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160202212454.GA21678@rob-hp-laptop>

On Tue, Feb 02, 2016 at 07:07:44PM +0100, Gregory CLEMENT wrote:
> The Marvell Armada 3700 is a family of ARMv8 CA53 SoCs. This commit
> introduces the Device Tree binding that documents the top-level
> compatible strings for Armada 3700 based platforms.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  .../devicetree/bindings/arm/marvell/armada-37xx.txt     | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
> new file mode 100644
> index 000000000000..5db9f1a90da2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
> @@ -0,0 +1,17 @@
> +Marvell Armada 37xx Platforms Device Tree Bindings
> +--------------------------------------------------
> +
> +Boards using a SoC of the Marvell Armada 37xx family must carry the
> +following root node property:
> +
> + - compatible: must contain "marvell,armada3700"

Is 3700 an actual chip? If not, please drop this. 

> +
> +In addition, depending on whether the Armada 3710 or Armada 3720 SoCs
> +are being used, the following root node property must be added:
> +
> + - compatible: must contain either "marvell,armada3710" or
> +   "marvell,armada3720"
> +
> +Example:
> +
> +compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3700";
> -- 
> 2.5.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From robh at kernel.org  Tue Feb  2 13:26:37 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 2 Feb 2016 15:26:37 -0600
Subject: [PATCH 05/10] Documentation: dt: Tidy up the Marvell related files
In-Reply-To: <1454436468-4241-6-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-6-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160202212637.GA24562@rob-hp-laptop>

On Tue, Feb 02, 2016 at 07:07:43PM +0100, Gregory CLEMENT wrote:
> Over the last releases we have added more and more Marvell related binding
> directly in the arm directory. It's time to have our proper directory
> inside it, and move all the files in it.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  .../devicetree/bindings/arm/{ => marvell}/armada-370-xp-pmsu.txt          | 0
>  Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp.txt     | 0
>  Documentation/devicetree/bindings/arm/{ => marvell}/armada-375.txt        | 0
>  .../devicetree/bindings/arm/{ => marvell}/armada-380-mpcore-soc-ctrl.txt  | 0
>  Documentation/devicetree/bindings/arm/{ => marvell}/armada-38x.txt        | 0
>  Documentation/devicetree/bindings/arm/{ => marvell}/armada-39x.txt        | 0
>  Documentation/devicetree/bindings/arm/{ => marvell}/armada-cpu-reset.txt  | 0
>  Documentation/devicetree/bindings/arm/{ => marvell}/coherency-fabric.txt  | 0
>  Documentation/devicetree/bindings/arm/{ => marvell}/kirkwood.txt          | 0
>  Documentation/devicetree/bindings/arm/{ => marvell}/marvell,berlin.txt    | 0
>  Documentation/devicetree/bindings/arm/{ => marvell}/marvell,dove.txt      | 0
>  Documentation/devicetree/bindings/arm/{ => marvell}/marvell,kirkwood.txt  | 0
>  Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-cpu-config.txt  | 0
>  .../devicetree/bindings/arm/{ => marvell}/mvebu-system-controller.txt     | 0
>  14 files changed, 0 insertions(+), 0 deletions(-)
>  rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp-pmsu.txt (100%)
>  rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp.txt (100%)
>  rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-375.txt (100%)
>  rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-380-mpcore-soc-ctrl.txt (100%)
>  rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-38x.txt (100%)
>  rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-39x.txt (100%)
>  rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-cpu-reset.txt (100%)
>  rename Documentation/devicetree/bindings/arm/{ => marvell}/coherency-fabric.txt (100%)
>  rename Documentation/devicetree/bindings/arm/{ => marvell}/kirkwood.txt (100%)
>  rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,berlin.txt (100%)
>  rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,dove.txt (100%)
>  rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,kirkwood.txt (100%)
>  rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-cpu-config.txt (100%)
>  rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-system-controller.txt (100%)

Acked-by: Rob Herring <robh at kernel.org>


From arnd at arndb.de  Tue Feb  2 13:34:22 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 02 Feb 2016 22:34:22 +0100
Subject: [PATCH] ARM: mx25: Add basic suspend/resume support
In-Reply-To: <1454447886-4045-1-git-send-email-festevam@gmail.com>
References: <1454447886-4045-1-git-send-email-festevam@gmail.com>
Message-ID: <4987443.OL55qNe4Wb@wuerfel>

On Tuesday 02 February 2016 19:18:06 Fabio Estevam wrote:
> +#ifdef CONFIG_PM
> +static int imx25_suspend_enter(suspend_state_t state)
> +{
> +       switch (state) {
> +       case PM_SUSPEND_MEM:
> +               cpu_do_idle();
> +               break;
> +       default:
> +               return -EINVAL;
> +       }
> +
> +       return 0;
> +}
> +#else
> +static inline int imx25_suspend_enter(suspend_state_t state)
> +{
> +       return 0;
> +}
> +#endif
> 

Better remove the #ifdef by doing

void __init imx25_pm_init(void)
{
	if (IS_ENABLED(CONFIG_PM))
		suspend_set_ops(&imx25_suspend_ops);
}

or put the IS_ENABLED() check inside of imx25_suspend_enter().

	Arnd


From heiko at sntech.de  Tue Feb  2 13:37:52 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 02 Feb 2016 22:37:52 +0100
Subject: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver
In-Reply-To: <1454049768-30872-1-git-send-email-ykk@rock-chips.com>
References: <1454049768-30872-1-git-send-email-ykk@rock-chips.com>
Message-ID: <33063104.hTo1MPWOYh@diego>

Hi Mark,

Am Freitag, 29. Januar 2016, 14:42:48 schrieb Yakir Yang:
> Here are a brief introduction to Innosilicon HDMI IP:
>   - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter
>   - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec
>   - Digital video interface supports a pixel size of 24, 30, 36, 48bits
> color depth in RGB - S/PDIF output supports PCM, Dolby Digital, DTS digital
> audio transmission (32-192kHz Fs) using IEC60958 and IEC 61937
>   - The EDID and CEC function are also supported by Innosilicon HDMI
> Transmitter Controlle

do you plan on picking up this two patches soon? It seems there were no 
further objections.

Caesar submitted the dts parts but I need to hold off on them until you took 
the driver part :-) .


Thanks
Heiko


From heiko at sntech.de  Tue Feb  2 13:29:28 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 02 Feb 2016 22:29:28 +0100
Subject: [PATCH v5 8/8] ARM: dts: rockchip: support the spi for rk3036
In-Reply-To: <1454384453-7127-4-git-send-email-wxt@rock-chips.com>
References: <1454384032-6794-1-git-send-email-wxt@rock-chips.com>
 <1454384453-7127-1-git-send-email-wxt@rock-chips.com>
 <1454384453-7127-4-git-send-email-wxt@rock-chips.com>
Message-ID: <8822283.9IqfJnsVut@diego>

Am Dienstag, 2. Februar 2016, 11:40:53 schrieb Caesar Wang:
> This patch adds the needed spi node for rk3036 dts.
> 
> We have to use the 4 bus emmc to work if someone want to support
> the spi devices, since the pins are re-used by emmc data[5-8] and spi.
> In some caseswe need to support the spi devices, that will waste the
> emmc performance.
> 
> Moment, the kylin/evb hasn't the spi devices to work, so maybe we need wait
> the new required to enable in kylin/evb board.
> 
> Anyway, the spi should be needed land in rk3036 dts.
> 
> Signed-off-by: Caesar Wang <wxt at rock-chips.com>

applied to my dts32 branch for 4.6


Thanks
Heiko


From mlangsdo at redhat.com  Tue Feb  2 13:39:11 2016
From: mlangsdo at redhat.com (Mark Langsdorf)
Date: Tue, 2 Feb 2016 15:39:11 -0600
Subject: [RFC PATCH 0/3] arm64 initrd mapping/relocation
In-Reply-To: <20160202180622.GP10166@arm.com>
References: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160202180622.GP10166@arm.com>
Message-ID: <56B121FF.8040707@redhat.com>

On 02/02/2016 12:06 PM, Will Deacon wrote:
> On Tue, Feb 02, 2016 at 06:56:39PM +0100, Ard Biesheuvel wrote:
>> After discussing in linux-efi with Mark, and on #armlinux with Will, this is
>> a proposal for dealing with initrd memory that is potentially not covered by
>> the linear region.
>>
>> Note that this will look slightly differently when some of the KASLR work gets
>> merged, but this should only affect the way we deal with the initrd if it sits
>> outside of the linear region.
>>
>> Mostly intended for discussion, not tested at all.
>
> Thanks Ard, this looks like a much better approach to me. Mark -- does
> the general idea work for you too?

I'm not quite the right Mark but Mark Salter is on vacation
and I was the one who discovered this bug. These patches
do fix the problem and it looks like they tidy up some
code. Will they be in v4.5-rc3?

--Mark Langsdorf



From tony at atomide.com  Tue Feb  2 13:39:17 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 2 Feb 2016 13:39:17 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFokWcLSCAh_TX-j-df_M1hN8Qw1gbQt--SyWccGCPiN5Q@mail.gmail.com>
References: <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602021112320.1653-100000@iolanthe.rowland.org>
 <CAPDyKFokWcLSCAh_TX-j-df_M1hN8Qw1gbQt--SyWccGCPiN5Q@mail.gmail.com>
Message-ID: <20160202213916.GA19432@atomide.com>

* Ulf Hansson <ulf.hansson at linaro.org> [160202 12:25]:
> >
> > ?  pm_runtime_put_sync() _already_ does not respect the autosuspend
> > mode.  If you want to respect it, you have to call
> > pm_runtime_put_sync_autosuspend() instead.
> 
> Then there's a bug in the runtime PM core.
> 
> From Tony's regression report and from mine own local runtime PM test
> driver, I can see that the device doesn't get RPM_SUSPENDED (the
> ->runtime_suspend() callback isn't called), even when the usage count
> is zero - when pm_runtime_put_sync() is called.
...
> Okay, so you are saying that the pm_runtime_put_sync() should idle the
> device even if autosuspend is in use. That seems reasonable, I will
> look into this problem.

The patch below fixes pm_runtime_put_sync() to not respect the
autosuspend mode to match what Alan is saying above. Seems to also
fixes the $subject issue for me. And seems to behave for PM runtime
for other devices during runtime too based on light testing here.

Regards,

Tony

8< ---------------
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -353,7 +353,9 @@ static int rpm_idle(struct device *dev, int rpmflags)
 
  out:
 	trace_rpm_return_int(dev, _THIS_IP_, retval);
-	return retval ? retval : rpm_suspend(dev, rpmflags | RPM_AUTO);
+	if (!(rpmflags & RPM_IGNORE_AUTO))
+		rpmflags |= RPM_AUTO;
+	return retval ? retval : rpm_suspend(dev, rpmflags);
 }
 
 /**
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -23,6 +23,8 @@
 					    usage_count */
 #define RPM_AUTO		0x08	/* Use autosuspend_delay */
 
+#define RPM_IGNORE_AUTO		0x10	/* Ignore autosuspend */
+
 #ifdef CONFIG_PM
 extern struct workqueue_struct *pm_wq;
 
@@ -241,7 +243,7 @@ static inline int pm_runtime_put_autosuspend(struct device *dev)
 
 static inline int pm_runtime_put_sync(struct device *dev)
 {
-	return __pm_runtime_idle(dev, RPM_GET_PUT);
+	return __pm_runtime_idle(dev, RPM_GET_PUT | RPM_IGNORE_AUTO);
 }
 
 static inline int pm_runtime_put_sync_suspend(struct device *dev)


From mlangsdo at redhat.com  Tue Feb  2 13:39:57 2016
From: mlangsdo at redhat.com (Mark Langsdorf)
Date: Tue, 2 Feb 2016 15:39:57 -0600
Subject: [RFC PATCH 0/3] arm64 initrd mapping/relocation
In-Reply-To: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <56B1222D.3000604@redhat.com>

On 02/02/2016 11:56 AM, Ard Biesheuvel wrote:
> After discussing in linux-efi with Mark, and on #armlinux with Will, this is
> a proposal for dealing with initrd memory that is potentially not covered by
> the linear region.
>
> Note that this will look slightly differently when some of the KASLR work gets
> merged, but this should only affect the way we deal with the initrd if it sits
> outside of the linear region.
>
> Mostly intended for discussion, not tested at all.
>
> Ard Biesheuvel (3):
>    memblock: add routine to clear the MEMBLOCK_NOMAP flag for a region
>    arm64: add the initrd region to the linear mapping explicitly
>    arm64: remove the now unneeded relocate_initrd()

I discovered the original problem on AMD Seattle and these patches
fixed it for me.

Tested-by: Mark Langsdorf <mlangsdo at redhat.com>



From heiko at sntech.de  Tue Feb  2 13:43:36 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 02 Feb 2016 22:43:36 +0100
Subject: [RFC PATCH] ARM: dts: rockchip: increase the mclk_fs to 512 for
 kylin board
In-Reply-To: <1454057361-22923-1-git-send-email-zhengxing@rock-chips.com>
References: <1454057361-22923-1-git-send-email-zhengxing@rock-chips.com>
Message-ID: <5872159.rO8vOly5eX@diego>

Am Freitag, 29. Januar 2016, 16:49:21 schrieb Xing Zheng:
> If we playback the 8KHz FS audio with the 256 mclk_fs, we need the
> mclk = 256 * 8000 = 2.048MHz, the frac div is 594 / 2.048 = 290,
> the frac div value 0x00809015 set to the CRU_CLKSEL7_CON will cause
> to hang.
> 
> We increase the mclk_fs to 512, will get the mclk = 512 * 8000 =
> 4.096MHz, use 0x01009015 instead of 0x00809015 to work around this
> issue. We will keep tracking it.
> 
> Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>

applied to my dts32 branch for 4.6


Thanks
Heiko


From heiko at sntech.de  Tue Feb  2 13:45:13 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 02 Feb 2016 22:45:13 +0100
Subject: [PATCH] Documentation: rockchip-dw-mshc: add RK3036 dw-mshc
 description
In-Reply-To: <1453775654-16105-1-git-send-email-shawn.lin@rock-chips.com>
References: <1453775654-16105-1-git-send-email-shawn.lin@rock-chips.com>
Message-ID: <5825242.FVApG7pqmR@diego>

Am Dienstag, 26. Januar 2016, 10:34:14 schrieb Shawn Lin:
> rk3036 dtsi file add dw-mshc compatible "rockchip,rk3036-dw-mshc"
> but didn't add it into rockchip-dw-mshc.txt.
> 
> Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>

applied to my dts32 branch for 4.6 with Rob's Ack


Thanks
Heiko


From stern at rowland.harvard.edu  Tue Feb  2 13:45:22 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Tue, 2 Feb 2016 16:45:22 -0500 (EST)
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160202210345.GZ19432@atomide.com>
Message-ID: <Pine.LNX.4.44L0.1602021626540.1653-100000@iolanthe.rowland.org>

On Tue, 2 Feb 2016, Tony Lindgren wrote:

> > Also, what is autosuspend_delay set to for your device?  And is 
> > runtime_auto set?
> 
> It's 100 at that point, see the commented snippet below from
> omap_hsmmc_probe():
> 
> 	pm_runtime_enable(host->dev);
> 	pm_runtime_get_sync(host->dev);
> 	pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY);
> 	/* NOTE: pm_runtime_dont_use_autosuspend(host->dev) needed here? */
> 	pm_runtime_use_autosuspend(host->dev);
> 	...
> 	/* gets -EPROBE_DEFER */
> err_irq:
> 	...
> 	pm_runtime_put_sync(host->dev);

You could try changing this to pm_runtime_put_sync_suspend().  But
putting pm_runtime_dont_use_autosuspend() before the put_sync seems
like a perfectly reasonable thing to do, especially if you feel you
should reverse all the changes you made at the start.

>         pm_runtime_disable(host->dev);
> 	/* NOTE: suspend callback never gets called unless
> 	 * pm_runtime_dont_use_autosuspend() is called
> 	 * before pm_runtime_put_sync() above.
> 	 */
> 	 ...
> 
> > > > Does pm_runtime_use_autosuspend() get called by the probe routine?  If 
> > > > it does, then perhaps you can get what you want by having the probe 
> > > > routine call pm_runtime_dont_use_autosuspend() whenever it's about to 
> > > > return an error -- particularly -EDEFER.
> > > 
> > > Yes so far that's the only fix that seems to work like I posted
> > > earlier. But is that the right fix though?
> > 
> > No, not really.  Ideally you would leave autosuspend turned on.  The 
> > delay would be long enough to that after -EDEFER, another probe would 
> > start before the delay expired.  But shortly after the last probe 
> > attempt, the delay would expire and the device would then be put in low 
> > power.
> 
> But then what about the new reinit function? To me it seems that
> we should not attempt to maintain a state from the earlier failed
> probe. Or are you thinking we just skip the reinit if autosuspend
> is set?

The reinit function gets called too late to do what you want -- namely, 
put the hardware in a low-power state.

That _is_ what you want, isn't it?  The alternative is to leave
dev->power.rpm_status set to RPM_ACTIVE, to match the hardware's actual 
state.

Given that the reinit function is supposed to restore the initial 
settings, it probably ought to call pm_runtime_dont_use_autosuspend().  
But that won't be enough to fix your problem.

> > > If we wanted to have some generic fix, it seems we would have to pass
> > > a new flag in pm_runtime_put_sync() to ignore any autosuspend
> > > configuration. But I don't know if that's what we want to or should
> > > do though?
> > 
> > I don't think so.
> 
> So should we just establish a policy that pm_runtime_use_autosuspend()
> needs to be paired with pm_runtime_dont_use_autosuspend() for
> pm_runtime_put_sync() to work?

Your understanding is slightly wrong.  pm_runtime_put_sync() _does_
work -- that is, it does what it's supposed to do.  The difficulty is
that what it's supposed to do doesn't match what you think.

pm_runtime_put_sync() is supposed to follow the driver's wishes.  It
invokes the driver's runtime_idle callback if there is one, and the
callback routine can start a suspend or an autosuspend.  If there is no
callback, it will use whatever autosuspend setting the driver has set
up.  If you want to override the autosuspend setting, use
pm_runtime_put_sync_suspend() instead.

Alan Stern



From festevam at gmail.com  Tue Feb  2 13:45:38 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Tue,  2 Feb 2016 19:45:38 -0200
Subject: [PATCH v2] ARM: mx25: Add basic suspend/resume support
Message-ID: <1454449538-7620-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at nxp.com>

Tested basic suspend/resume on a mx25pdk:

$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
$ echo mem > /sys/power/state

Then press any key in the serial console and the system wakes up.

Signed-off-by: Fabio Estevam <fabio.estevam at nxp.com>
---
Changes since v1:
- Use IS_ENABLED() instead of ifdef (Arnd).

 arch/arm/mach-imx/Makefile     |  2 +-
 arch/arm/mach-imx/common.h     |  1 +
 arch/arm/mach-imx/mach-imx25.c |  1 +
 arch/arm/mach-imx/pm-imx25.c   | 37 +++++++++++++++++++++++++++++++++++++
 4 files changed, 40 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-imx/pm-imx25.c

diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index fb689d8..9fbe624 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -3,7 +3,7 @@ obj-y := cpu.o system.o irq-common.o
 obj-$(CONFIG_SOC_IMX1) += mm-imx1.o
 obj-$(CONFIG_SOC_IMX21) += mm-imx21.o
 
-obj-$(CONFIG_SOC_IMX25) += cpu-imx25.o mach-imx25.o
+obj-$(CONFIG_SOC_IMX25) += cpu-imx25.o mach-imx25.o pm-imx25.o
 
 obj-$(CONFIG_SOC_IMX27) += cpu-imx27.o pm-imx27.o
 obj-$(CONFIG_SOC_IMX27) += mm-imx27.o ehci-imx27.o
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 32b83f0..58a3846 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -66,6 +66,7 @@ void imx_gpc_check_dt(void);
 void imx_gpc_set_arm_power_in_lpm(bool power_off);
 void imx_gpc_set_arm_power_up_timing(u32 sw2iso, u32 sw);
 void imx_gpc_set_arm_power_down_timing(u32 sw2iso, u32 sw);
+void imx25_pm_init(void);
 
 enum mxc_cpu_pwr_mode {
 	WAIT_CLOCKED,		/* wfi only */
diff --git a/arch/arm/mach-imx/mach-imx25.c b/arch/arm/mach-imx/mach-imx25.c
index 9379fd0..32dcb5e 100644
--- a/arch/arm/mach-imx/mach-imx25.c
+++ b/arch/arm/mach-imx/mach-imx25.c
@@ -41,6 +41,7 @@ static const char * const imx25_dt_board_compat[] __initconst = {
 
 DT_MACHINE_START(IMX25_DT, "Freescale i.MX25 (Device Tree Support)")
 	.init_early	= imx25_init_early,
+	.init_late      = imx25_pm_init,
 	.init_irq	= mx25_init_irq,
 	.dt_compat	= imx25_dt_board_compat,
 MACHINE_END
diff --git a/arch/arm/mach-imx/pm-imx25.c b/arch/arm/mach-imx/pm-imx25.c
new file mode 100644
index 0000000..8bba9fc
--- /dev/null
+++ b/arch/arm/mach-imx/pm-imx25.c
@@ -0,0 +1,37 @@
+/*
+ * Copyright 2016 NXP Semiconductors
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/suspend.h>
+#include <linux/io.h>
+
+static int imx25_suspend_enter(suspend_state_t state)
+{
+	if (!IS_ENABLED(CONFIG_PM))
+		return 0;
+
+	switch (state) {
+	case PM_SUSPEND_MEM:
+		cpu_do_idle();
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static const struct platform_suspend_ops imx25_suspend_ops = {
+	.enter = imx25_suspend_enter,
+	.valid = suspend_valid_only_mem,
+};
+
+void __init imx25_pm_init(void)
+{
+	suspend_set_ops(&imx25_suspend_ops);
+}
-- 
1.9.1



From robh at kernel.org  Tue Feb  2 13:50:36 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 2 Feb 2016 15:50:36 -0600
Subject: [PATCH v4 2/2] drm: sunxi: Add a basic DRM driver for Allwinner
 DE2
In-Reply-To: <76ae5b406ad64b2717c0b1c62c3005a62b2715b8.1454435944.git.moinejf@free.fr>
References: <cover.1454435944.git.moinejf@free.fr>
 <76ae5b406ad64b2717c0b1c62c3005a62b2715b8.1454435944.git.moinejf@free.fr>
Message-ID: <20160202215036.GA25521@rob-hp-laptop>

On Tue, Feb 02, 2016 at 04:25:51PM +0100, Jean-Francois Moine wrote:
> In recent SoCs, as the H3, Allwinner uses a new display interface, DE2.
> This patch adds a DRM video driver for this interface.
> 
> Signed-off-by: Jean-Francois Moine <moinejf at free.fr>
> ---
> v4: (no change)
> v3:
> 	- add the hardware cursor
> 	- simplify and fix the DE2 init sequences
> 	- generation for all SUNXI SoCs (Andre Przywara)
> v2:
> 	- remarks from Russell King
> 	- DT documentation added
> 	- working resolution change with xrandr
> 	- removal of the HDMI driver
> ---
>  .../devicetree/bindings/display/sunxi.txt          |  81 ++++
>  drivers/gpu/drm/Kconfig                            |   2 +
>  drivers/gpu/drm/Makefile                           |   1 +
>  drivers/gpu/drm/sunxi/Kconfig                      |  20 +
>  drivers/gpu/drm/sunxi/Makefile                     |   7 +
>  drivers/gpu/drm/sunxi/de2_crtc.c                   | 421 +++++++++++++++++
>  drivers/gpu/drm/sunxi/de2_crtc.h                   |  61 +++
>  drivers/gpu/drm/sunxi/de2_de.c                     | 505 +++++++++++++++++++++
>  drivers/gpu/drm/sunxi/de2_drm.h                    |  40 ++
>  drivers/gpu/drm/sunxi/de2_drv.c                    | 377 +++++++++++++++
>  drivers/gpu/drm/sunxi/de2_plane.c                  |  91 ++++
>  11 files changed, 1606 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/sunxi.txt
>  create mode 100644 drivers/gpu/drm/sunxi/Kconfig
>  create mode 100644 drivers/gpu/drm/sunxi/Makefile
>  create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
>  create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
>  create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
>  create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
>  create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
>  create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c
> 
> diff --git a/Documentation/devicetree/bindings/display/sunxi.txt b/Documentation/devicetree/bindings/display/sunxi.txt
> new file mode 100644
> index 0000000..35f9763
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sunxi.txt
> @@ -0,0 +1,81 @@
> +Allwinner sunxi display subsystem
> +=================================
> +
> +The sunxi display subsystems contain a display controller (DE),
> +one or two LCD controllers (TCON) and their external interfaces.
> +
> +Display controller
> +==================
> +
> +Required properties:
> +
> +- compatible: value should be one of the following
> +		"allwinner,sun8i-h3-display-engine"
> +
> +- clocks: must include clock specifiers corresponding to entries in the
> +		clock-names property.
> +
> +- clock-names: must contain
> +		gate: for DE activation
> +		clock: DE clock
> +
> +- resets: phandle to the reset of the device
> +
> +- ports: phandle's to the LCD ports
> +
> +LCD controller
> +==============
> +
> +Required properties:
> +
> +- compatible: value should be one of the following
> +		"allwinner,sun8i-h3-lcd"
> +
> +- clocks: must include clock specifiers corresponding to entries in the
> +		clock-names property.
> +
> +- clock-names: must contain
> +		gate: for LCD activation
> +		clock: pixel clock
> +
> +- resets: phandle to the reset of the device
> +
> +- port: port node with endpoint definitions as defined in
> +	Documentation/devicetree/bindings/media/video-interfaces.txt

Define how many ports and endpoints.

> +
> +Example:
> +
> +	de: de-controller at 01000000 {
> +		compatible = "allwinner,sun8i-h3-display-engine";
> +		...
> +		clocks = <&bus_gates 44>, <&de_clk>;
> +		clock-names = "gate", "clock";
> +		resets = <&ahb_rst 44>;
> +		ports = <&lcd0_p>;

This is pointless if you only have one item in ports. Is this really a 
separate h/w block? Can't you move all this into the node below?

> +	};
> +
> +	lcd0: lcd-controller at 01c0c000 {
> +		compatible = "allwinner,sun8i-h3-lcd";
> +		...
> +		clocks = <&bus_gates 35>, <&tcon0_clk>;
> +		clock-names = "gate", "clock";
> +		resets = <&ahb_rst 35>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		lcd0_p: port {
> +			lcd0_ep: endpoint {
> +				remote-endpoint = <&hdmi_ep>;
> +			};
> +		};
> +	};
> +
> +	hdmi: hdmi at 01ee0000 {
> +		...
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		port {
> +			hdmi_ep: endpoint {
> +				remote-endpoint = <&lcd0_ep>;
> +			};
> +		};
> +	};


From robh at kernel.org  Tue Feb  2 13:52:14 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 2 Feb 2016 15:52:14 -0600
Subject: [PATCH v4 1/2] clk: sunxi: Add sun6i/8i video support
In-Reply-To: <3c0e2cdea659e9e682f80ecf42b252c740095f15.1454435944.git.moinejf@free.fr>
References: <cover.1454435944.git.moinejf@free.fr>
 <3c0e2cdea659e9e682f80ecf42b252c740095f15.1454435944.git.moinejf@free.fr>
Message-ID: <20160202215214.GA6738@rob-hp-laptop>

On Tue, Feb 02, 2016 at 06:35:10PM +0100, Jean-Francois Moine wrote:
> Add the clock types which are used by the sun6i/8i families for video.
> 
> Signed-off-by: Jean-Francois Moine <moinejf at free.fr>
> ---
> v4:
> 	- drivers/clk/sunxi/Makefile was missing (Emil Velikov)
> v3: (no change)
> v2:
> 	- remarks from Chen-Yu Tsai
> 	- DT documentation added
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt |   2 +

Acked-by: Rob Herring <robh at kernel.org>

>  drivers/clk/sunxi/Makefile                        |   2 +
>  drivers/clk/sunxi/clk-sun6i-display.c             | 106 +++++++++++++
>  drivers/clk/sunxi/clk-sun6i-pll3.c                | 174 ++++++++++++++++++++++
>  4 files changed, 284 insertions(+)
>  create mode 100644 drivers/clk/sunxi/clk-sun6i-display.c
>  create mode 100644 drivers/clk/sunxi/clk-sun6i-pll3.c



From carlo at caione.org  Tue Feb  2 13:54:08 2016
From: carlo at caione.org (Carlo Caione)
Date: Tue, 2 Feb 2016 22:54:08 +0100
Subject: [PATCH v4] mmc: meson: Add driver for the SD/MMC host found on
 Amlogic MesonX SoCs
In-Reply-To: <CAPDyKFpX+_fHvv_bJUKZmSufKKnuONC582E7u3b20a+Rbbggng@mail.gmail.com>
References: <1448988109-32630-1-git-send-email-carlo@caione.org>
 <CAPDyKFp=buvJ8Li3XC8XSUAUO7BsE+U6vEQH2xTrgcHAkdG8bQ@mail.gmail.com>
 <CAOQ7t2aJAPWd3Xmvu7n0EWL-KC8ZriM3KryfsYEh556uXhuR+g@mail.gmail.com>
 <CAPDyKFpcsKihuOiF5=RwoWrF0Jf7hRsXVSU5uV8qZf1mUsa-iQ@mail.gmail.com>
 <CAOQ7t2afXxStCsj=M-FX7eMep1gLt4jkyXDiLas_SQ1UwHc0=Q@mail.gmail.com>
 <CAPDyKFpX+_fHvv_bJUKZmSufKKnuONC582E7u3b20a+Rbbggng@mail.gmail.com>
Message-ID: <CAOQ7t2aS0yRDhM3+8wW5xrycG371uthDJy6U_oDAZip4jHRiRA@mail.gmail.com>

On Tue, Feb 2, 2016 at 12:21 PM, Ulf Hansson <ulf.hansson at linaro.org> wrote:
> On 1 February 2016 at 23:05, Carlo Caione <carlo at caione.org> wrote:
>> On Tue, Dec 8, 2015 at 9:35 PM, Ulf Hansson <ulf.hansson at linaro.org> wrote:

[cut]

>> I still fail to see what the correct behaviour should be.
>> Using the v4 of this driver with a "broken-cd" binding and a timeout
>> of 10s my SD card takes 30s to be identified as removed after I take
>> it out from the SD slot.
>> Also, if I take it out and insert it again, I still have to wait 30s
>> to be able to access it again. Is this a limitation / bug of my driver
>> or is this the expected behaviour when we do not have a dedicated GPIO
>> for card detection?
>
> It's *not* an expected a behaviour.
>
> Using MMC_CAP_NEEDS_POLL, means that the mmc core will send CMD13
> commands in a polling manner to find out whether a card has been
> removed.
>
> It seems like when the card is removed, the host driver doesn't get an
> IRQ which indicates a command timeout. Instead it waits for the 10 s
> timeout to expire.
>
> My question is then; why don't the driver get an IRQ for the command
> timeout? Is that because of non-correct setup of the IRQ masks or
> because the controller HW doesn't support this?

I just verified that apparently the HW doesn't support this (no
register for commands timeout and no IRQ generated).
Anything wrong with implementing this in software with a timer on
mrq->data->timeout_ns?

-- 
Carlo Caione


From heiko at sntech.de  Tue Feb  2 13:23:09 2016
From: heiko at sntech.de (Heiko =?ISO-8859-1?Q?St=FCbner?=)
Date: Tue, 02 Feb 2016 22:23:09 +0100
Subject: [PATCH v5 4/8] ARM: dts: rockchip: add mclk for rt5616 on kylin
 board
In-Reply-To: <1454384453-7127-3-git-send-email-wxt@rock-chips.com>
References: <1454384032-6794-1-git-send-email-wxt@rock-chips.com>
 <1454384453-7127-1-git-send-email-wxt@rock-chips.com>
 <1454384453-7127-3-git-send-email-wxt@rock-chips.com>
Message-ID: <13229700.1YLSBs01uG@diego>

Am Dienstag, 2. Februar 2016, 11:40:52 schrieb Caesar Wang:
> The I2S block that provide the output clock as the mclk for rt5616,
> That will be the master clock  input.
> 
> Signed-off-by: Caesar Wang <wxt at rock-chips.com>

applied to my dts32- branch for 4.6


Thanks
Heiko


From nab at linux-iscsi.org  Tue Feb  2 14:08:49 2016
From: nab at linux-iscsi.org (Nicholas A. Bellinger)
Date: Tue, 02 Feb 2016 14:08:49 -0800
Subject: [PATCH] target: fix cast from pointer to phys_addr_t
In-Reply-To: <3114027.BKdWsaRxO0@wuerfel>
References: <3114027.BKdWsaRxO0@wuerfel>
Message-ID: <1454450929.25549.1.camel@haakon3.risingtidesystems.com>

(Adding Andy CC')

On Mon, 2016-02-01 at 17:29 +0100, Arnd Bergmann wrote:
> The uio_mem structure has a member that is a phys_addr_t, but can
> be a number of other types too. The target core driver attempts
> to assign a pointer from vmalloc() to it, by casting it to
> phys_addr_t, but that causes a warning when phys_addr_t is longer
> than a pointer:
> 
> drivers/target/target_core_user.c: In function 'tcmu_configure_device':
> drivers/target/target_core_user.c:906:22: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
> 
> This adds another cast to uintptr_t to shut up the warning.
> A nicer fix might be to have additional fields in uio_mem
> for the different purposes, so we can assign a pointer directly.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
> This has been around for a long while, but did not trigger in
> my randconfig testing until now, don't know why.
> 
> diff --git a/drivers/target/target_core_user.c b/drivers/target/target_core_user.c
> index dd600e5ead71..94f5154ac788 100644
> --- a/drivers/target/target_core_user.c
> +++ b/drivers/target/target_core_user.c
> @@ -903,7 +903,7 @@ static int tcmu_configure_device(struct se_device *dev)
>  	info->version = __stringify(TCMU_MAILBOX_VERSION);
>  
>  	info->mem[0].name = "tcm-user command & data buffer";
> -	info->mem[0].addr = (phys_addr_t) udev->mb_addr;
> +	info->mem[0].addr = (phys_addr_t)(uintptr_t)udev->mb_addr;
>  	info->mem[0].size = TCMU_RING_SIZE;
>  	info->mem[0].memtype = UIO_MEM_VIRTUAL;
>  
> 

Applied to target-pending/master.

Thanks Arnd.




From stillcompiling at gmail.com  Tue Feb  2 14:13:22 2016
From: stillcompiling at gmail.com (Joshua Clayton)
Date: Tue,  2 Feb 2016 14:13:22 -0800
Subject: [PATCH v2] ARM: dts: Add dts for Uniwest evi
In-Reply-To: <patches/evidts/35215>
References: <patches/evidts/35215>
Message-ID: <1454451202-1687-1-git-send-email-stillcompiling@gmail.com>

Uniwest evi is a portable electrical eddy current non-destructive
testing device.

Signed-off-by: Joshua Clayton <stillcompiling at gmail.com>
---
 arch/arm/boot/dts/Makefile      |   1 +
 arch/arm/boot/dts/imx6q-evi.dts | 506 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 507 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-evi.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c4f42a78..4a4ef29 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -326,6 +326,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
 	imx6q-cubox-i.dtb \
 	imx6q-dfi-fs700-m60.dtb \
 	imx6q-dmo-edmqmx6.dtb \
+	imx6q-evi.dtb \
 	imx6q-gk802.dtb \
 	imx6q-gw51xx.dtb \
 	imx6q-gw52xx.dtb \
diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
new file mode 100644
index 0000000..10f566e
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-evi.dts
@@ -0,0 +1,506 @@
+/*
+ * Copyright 2016 United Western Technologies.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	model = "Uniwest Evi";
+	compatible = "uniwest,imx6q-evi", "fsl,imx6q";
+
+	memory {
+		reg = <0x10000000 0x40000000>;
+	};
+
+	reg_usbh1_vbus: regulator-usbhubreset {
+		compatible = "regulator-fixed";
+		regulator-name = "usbh1_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		startup-delay-us = <2>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbh1_hubreset>;
+		gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
+	};
+
+	reg_usb_otg_vbus: regulator-usbotgvbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_otg_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbotgvbus>;
+		gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		regulator-always-on;
+	};
+
+	panel {
+		compatible = "sharp,lq101k1ly04";
+
+		port {
+			panel_in: endpoint {
+				remote-endpoint = <&lvds0_out>;
+			};
+		};
+	};
+};
+
+&ecspi1 {
+	fsl,spi-num-chipselects = <1>;
+	cs-gpios = <&gpio4 10 GPIO_ACTIVE_LOW>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_ecspi1cs>;
+	status = "okay";
+};
+
+&ecspi3 {
+	fsl,spi-num-chipselects = <3>;
+	cs-gpios = <&gpio4 24 GPIO_ACTIVE_LOW>,
+		<&gpio4 25 GPIO_ACTIVE_LOW>,
+		<&gpio4 26 GPIO_ACTIVE_LOW>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3cs>;
+	status = "okay";
+};
+
+&ecspi5 {
+	fsl,spi-num-chipselects = <4>;
+	cs-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>,
+		<&gpio1 13 GPIO_ACTIVE_LOW>,
+		<&gpio1 12 GPIO_ACTIVE_LOW>,
+		<&gpio2 9 GPIO_ACTIVE_HIGH>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi5 &pinctrl_ecspi5cs>;
+	status = "okay";
+
+	eeprom: m95m02 at 1 {
+		compatible = "st,m95m02", "atmel,at25";
+		size = <262144>;
+		pagesize = <256>;
+		address-width = <24>;
+		spi-max-frequency = <5000000>;
+		reg = <1>;
+	};
+
+	pb_rtc: rtc at 3 {
+		compatible = "nxp,rtc-pcf2123";
+		spi-max-frequency = <2450000>;
+		spi-cs-high;
+		reg = <3>;
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet>;
+	phy-mode = "rgmii";
+	phy-reset-gpios = <&gpio1 25 0>;
+	status = "okay";
+};
+
+&gpmi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_gpminand>;
+	status = "okay";
+};
+
+&i2c2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	clock-frequency = <100000>;
+	status = "okay";
+};
+
+&i2c3 {
+	pinctrl-names = "default", "gpio";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	pinctrl-1 = <&pinctrl_i2c3_gpio>;
+	clock-frequency = <100000>;
+	scl-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+	sda-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+
+	battery: sbs-battery at b {
+		compatible = "sbs,sbs-battery";
+		reg = <0x0b>;
+		sbs,poll-retry-count = <100>;
+		sbs,i2c-retry-count = <100>;
+	};
+};
+
+&ldb {
+	status = "okay";
+
+	lvds0: lvds-channel at 0 {
+		fsl,data-mapping = "jeida";
+		fsl,data-width = <24>;
+		status = "okay";
+
+		port at 4 {
+			reg = <4>;
+			lvds0_out: endpoint {
+				remote-endpoint = <&panel_in>;
+			};
+		};
+	};
+};
+
+&ssi1 {
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2>;
+	status = "okay";
+};
+
+&usbh1 {
+	vbus-supply = <&reg_usbh1_vbus>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbh1>;
+	dr_mode = "host";
+	disable-over-current;
+	status = "okay";
+};
+
+&usbotg {
+	vbus-supply = <&reg_usb_otg_vbus>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbotg>;
+	disable-over-current;
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	non-removable;
+	status = "okay";
+};
+
+&weim {
+	#address-cells = <2>;
+	#size-cells = <1>;
+	ranges = <0 0 0x08000000 0x08000000>;
+	fsl,weim-cs-gpr = <&gpr>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_weimfpga &pinctrl_weimcs>;
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	pinctrl_hog: hoggrp {
+		fsl,pins = <
+			/* CPLD Reset */
+			MX6QDL_PAD_GPIO_19__GPIO4_IO05 0x1b0b0
+			/* pwr mcu alert irq */
+			MX6QDL_PAD_SD4_DAT2__GPIO2_IO10 0x1b0b0
+			/* remainder ???? */
+			MX6QDL_PAD_CSI0_MCLK__GPIO5_IO19 0x1b0b0
+		>;
+	};
+
+	pinctrl_ecspi1: ecspi1grp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL1__ECSPI1_MISO 0x100b1
+			MX6QDL_PAD_KEY_ROW0__ECSPI1_MOSI 0x100b1
+			MX6QDL_PAD_KEY_COL0__ECSPI1_SCLK 0x100b1
+		>;
+	};
+
+	pinctrl_ecspi1cs: ecspi1csgrp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
+		>;
+	};
+
+	pinctrl_ecspi3: ecspi3grp {
+		fsl,pins = <
+			MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x10068
+			MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x10068
+			MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x1f068
+		>;
+	};
+
+	pinctrl_ecspi3cs: ecspi3csgrp {
+		fsl,pins = <
+			MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x1b0b0
+			MX6QDL_PAD_DISP0_DAT4__GPIO4_IO25 0x1b0b0
+			MX6QDL_PAD_DISP0_DAT5__GPIO4_IO26 0x1b0b0
+			MX6QDL_PAD_DISP0_DAT6__GPIO4_IO27 0x1b0b0
+		>;
+	};
+
+	pinctrl_ecspi5: ecspi5grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD2_CLK__ECSPI5_SCLK 0x100b1
+			MX6QDL_PAD_SD2_CMD__ECSPI5_MOSI 0x100b1
+			MX6QDL_PAD_SD2_DAT0__ECSPI5_MISO 0x100b1
+		>;
+	};
+
+	pinctrl_ecspi5cs: ecspi5csgrp {
+		fsl,pins = <
+			MX6QDL_PAD_SD2_DAT1__GPIO1_IO14 0x1b0b0
+			MX6QDL_PAD_SD2_DAT2__GPIO1_IO13 0x1b0b0
+			MX6QDL_PAD_SD2_DAT3__GPIO1_IO12 0x1b0b0
+			MX6QDL_PAD_SD4_DAT1__GPIO2_IO09 0x1b0b0
+		>;
+	};
+
+	pinctrl_enet: enetgrp {
+		fsl,pins = <
+			MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+			MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+			MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b0b0
+			MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b0b0
+			MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b0b0
+			MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b0b0
+			MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b0b0
+			MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
+			MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
+			MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b0b0
+			MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b0b0
+			MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b0b0
+			MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0
+			MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0
+			MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
+			MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x4001b0a8
+			MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x1b0b0
+		>;
+	};
+
+	pinctrl_gpminand: gpminandgrp {
+		fsl,pins = <
+			MX6QDL_PAD_NANDF_CLE__NAND_CLE 0xb0b1
+			MX6QDL_PAD_NANDF_ALE__NAND_ALE 0xb0b1
+			MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0xb0b1
+			MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0xb000
+			MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0xb0b1
+			MX6QDL_PAD_NANDF_CS1__NAND_CE1_B 0xb0b1
+			MX6QDL_PAD_SD4_CMD__NAND_RE_B 0xb0b1
+			MX6QDL_PAD_SD4_CLK__NAND_WE_B 0xb0b1
+			MX6QDL_PAD_NANDF_D0__NAND_DATA00 0xb0b1
+			MX6QDL_PAD_NANDF_D1__NAND_DATA01 0xb0b1
+			MX6QDL_PAD_NANDF_D2__NAND_DATA02 0xb0b1
+			MX6QDL_PAD_NANDF_D3__NAND_DATA03 0xb0b1
+			MX6QDL_PAD_NANDF_D4__NAND_DATA04 0xb0b1
+			MX6QDL_PAD_NANDF_D5__NAND_DATA05 0xb0b1
+			MX6QDL_PAD_NANDF_D6__NAND_DATA06 0xb0b1
+			MX6QDL_PAD_NANDF_D7__NAND_DATA07 0xb0b1
+			MX6QDL_PAD_SD4_DAT0__NAND_DQS 0x00b1
+		>;
+	};
+
+	pinctrl_i2c2: i2c2grp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+			MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+		>;
+	};
+
+	pinctrl_i2c3: i2c3grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
+			MX6QDL_PAD_GPIO_16__I2C3_SDA 0x4001b8b1
+		>;
+	};
+
+	pinctrl_i2c3_gpio: i2c3gpiogrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_5__GPIO1_IO05 0x4001b8b1
+			MX6QDL_PAD_GPIO_16__GPIO7_IO11 0x4001b8b1
+		>;
+	};
+
+	pinctrl_weimcs: weimcsgrp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_CS0__EIM_CS0_B 0xb0b1
+			MX6QDL_PAD_EIM_CS1__EIM_CS1_B 0xb0b1
+		>;
+	};
+
+	pinctrl_weimfpga: weimfpgagrp {
+		fsl,pins = <
+			/* weim misc */
+			MX6QDL_PAD_EIM_OE__EIM_OE_B 0xb0b1
+			MX6QDL_PAD_EIM_RW__EIM_RW 0xb0b1
+			MX6QDL_PAD_EIM_WAIT__EIM_WAIT_B 0xb060
+			MX6QDL_PAD_EIM_BCLK__EIM_BCLK 0xb0b1
+			MX6QDL_PAD_EIM_LBA__EIM_LBA_B 0xb0b1
+			MX6QDL_PAD_EIM_EB0__EIM_EB0_B 0xb0b1
+			MX6QDL_PAD_EIM_EB1__EIM_EB1_B 0xb0b1
+			MX6QDL_PAD_EIM_EB2__EIM_EB2_B 0xb0b1
+			MX6QDL_PAD_EIM_EB3__EIM_EB3_B 0xb0b1
+			/* weim data */
+			MX6QDL_PAD_CSI0_DATA_EN__EIM_DATA00 0x1b0b0
+			MX6QDL_PAD_CSI0_VSYNC__EIM_DATA01 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT4__EIM_DATA02 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT5__EIM_DATA03 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT6__EIM_DATA04 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT7__EIM_DATA05 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT8__EIM_DATA06 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT9__EIM_DATA07 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT12__EIM_DATA08 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT13__EIM_DATA09 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT14__EIM_DATA10 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT15__EIM_DATA11 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT16__EIM_DATA12 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT17__EIM_DATA13 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT18__EIM_DATA14 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT19__EIM_DATA15 0x1b0b0
+			MX6QDL_PAD_EIM_D16__EIM_DATA16 0x1b0b0
+			MX6QDL_PAD_EIM_D17__EIM_DATA17 0x1b0b0
+			MX6QDL_PAD_EIM_D18__EIM_DATA18 0x1b0b0
+			MX6QDL_PAD_EIM_D19__EIM_DATA19 0x1b0b0
+			MX6QDL_PAD_EIM_D20__EIM_DATA20 0x1b0b0
+			MX6QDL_PAD_EIM_D21__EIM_DATA21 0x1b0b0
+			MX6QDL_PAD_EIM_D22__EIM_DATA22 0x1b0b0
+			MX6QDL_PAD_EIM_D23__EIM_DATA23 0x1b0b0
+			MX6QDL_PAD_EIM_D24__EIM_DATA24 0x1b0b0
+			MX6QDL_PAD_EIM_D25__EIM_DATA25 0x1b0b0
+			MX6QDL_PAD_EIM_D26__EIM_DATA26 0x1b0b0
+			MX6QDL_PAD_EIM_D27__EIM_DATA27 0x1b0b0
+			MX6QDL_PAD_EIM_D28__EIM_DATA28 0x1b0b0
+			MX6QDL_PAD_EIM_D29__EIM_DATA29 0x1b0b0
+			MX6QDL_PAD_EIM_D30__EIM_DATA30 0x1b0b0
+			MX6QDL_PAD_EIM_D31__EIM_DATA31 0x1b0b0
+			/* weim address */
+			MX6QDL_PAD_EIM_A25__EIM_ADDR25 0xb0b1
+			MX6QDL_PAD_EIM_A24__EIM_ADDR24 0xb0b1
+			MX6QDL_PAD_EIM_A23__EIM_ADDR23 0xb0b1
+			MX6QDL_PAD_EIM_A22__EIM_ADDR22 0xb0b1
+			MX6QDL_PAD_EIM_A21__EIM_ADDR21 0xb0b1
+			MX6QDL_PAD_EIM_A20__EIM_ADDR20 0xb0b1
+			MX6QDL_PAD_EIM_A19__EIM_ADDR19 0xb0b1
+			MX6QDL_PAD_EIM_A18__EIM_ADDR18 0xb0b1
+			MX6QDL_PAD_EIM_A17__EIM_ADDR17 0xb0b1
+			MX6QDL_PAD_EIM_A16__EIM_ADDR16 0xb0b1
+			MX6QDL_PAD_EIM_DA15__EIM_AD15 0xb0b1
+			MX6QDL_PAD_EIM_DA14__EIM_AD14 0xb0b1
+			MX6QDL_PAD_EIM_DA13__EIM_AD13 0xb0b1
+			MX6QDL_PAD_EIM_DA12__EIM_AD12 0xb0b1
+			MX6QDL_PAD_EIM_DA11__EIM_AD11 0xb0b1
+			MX6QDL_PAD_EIM_DA10__EIM_AD10 0xb0b1
+			MX6QDL_PAD_EIM_DA9__EIM_AD09 0xb0b1
+			MX6QDL_PAD_EIM_DA8__EIM_AD08 0xb0b1
+			MX6QDL_PAD_EIM_DA7__EIM_AD07 0xb0b1
+			MX6QDL_PAD_EIM_DA6__EIM_AD06 0xb0b1
+			MX6QDL_PAD_EIM_DA5__EIM_AD05 0xb0b1
+			MX6QDL_PAD_EIM_DA4__EIM_AD04 0xb0b1
+			MX6QDL_PAD_EIM_DA3__EIM_AD03 0xb0b1
+			MX6QDL_PAD_EIM_DA2__EIM_AD02 0xb0b1
+			MX6QDL_PAD_EIM_DA1__EIM_AD01 0xb0b1
+			MX6QDL_PAD_EIM_DA0__EIM_AD00 0xb0b1
+		>;
+	};
+
+	pinctrl_uart1: uart1grp {
+		fsl,pins = <
+			MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
+			MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
+		>;
+	};
+
+	pinctrl_uart2: uart2grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD3_DAT5__UART2_TX_DATA 0x1b0b1
+			MX6QDL_PAD_SD3_DAT4__UART2_RX_DATA 0x1b0b1
+			MX6QDL_PAD_SD3_CLK__UART2_RTS_B 0x1b0b1
+			MX6QDL_PAD_SD3_CMD__UART2_CTS_B 0x1b0b1
+		>;
+	};
+
+	pinctrl_usbh1: usbh1grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_3__USB_H1_OC 0x1b0b0
+			/* usbh1_b OC */
+			MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
+		>;
+	};
+
+	pinctrl_usbh1_hubreset: usbh1hubresetgrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
+		>;
+	};
+
+	pinctrl_usbotg: usbotggrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
+			MX6QDL_PAD_KEY_COL4__USB_OTG_OC 0x1b0b0
+		>;
+	};
+
+	pinctrl_usbotgvbus: usbotgvbusgrp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x000b0
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17059
+			MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10059
+			MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17059
+			MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17059
+			MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17059
+			MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17059
+		>;
+	};
+};
-- 
2.5.0



From julian.calaby at gmail.com  Tue Feb  2 14:19:28 2016
From: julian.calaby at gmail.com (Julian Calaby)
Date: Wed, 3 Feb 2016 09:19:28 +1100
Subject: [linux-sunxi] [PATCH v2 4/5] ARM: dts: sun8i-h3: Add R_PIO
 controller node to the dtsi
In-Reply-To: <1454448113-18810-5-git-send-email-k@japko.eu>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
 <1454448113-18810-5-git-send-email-k@japko.eu>
Message-ID: <CAGRGNgXZ2jVEFFP-Cf0ZtAa6-JbaGQwFX-+VBQe2M5f_K1mhKg@mail.gmail.com>

Hi Krzysztof,

On Wed, Feb 3, 2016 at 8:21 AM, Krzysztof Adamski <k at japko.eu> wrote:
> Add the corresponding device node for R_PIO on H3 to the dtsi. Support
> for the controller was added in earlier commit.
>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>
> ---
>  .../devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt  |  1 +
>  arch/arm/boot/dts/sun8i-h3.dtsi                              | 12 ++++++++++++
>  2 files changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> index 9213b27..3e56b16 100644
> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> @@ -21,6 +21,7 @@ Required properties:
>    "allwinner,sun9i-a80-r-pinctrl"
>    "allwinner,sun8i-a83t-pinctrl"
>    "allwinner,sun8i-h3-pinctrl"
> +  "allwinner,sun8i-h3-r-pinctrl"

Shouldn't this change go in the patch that introduces the driver for
this pinctl?

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


From maxime.ripard at free-electrons.com  Tue Feb  2 14:31:15 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 2 Feb 2016 23:31:15 +0100
Subject: [PATCH v3 1/2] dt-bindings: add sun4i SPDIF transceiver bindings
In-Reply-To: <1454424594-25208-2-git-send-email-codekipper@gmail.com>
References: <1454424594-25208-1-git-send-email-codekipper@gmail.com>
 <1454424594-25208-2-git-send-email-codekipper@gmail.com>
Message-ID: <20160202223115.GE4652@lukather>

Hi,

On Tue, Feb 02, 2016 at 03:49:53PM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
> 
> Add devicetree bindings for the SPDIF transceiver found on
> found on Allwinners A10 and A20 SoCs.
> 
> Signed-off-by: Marcus Cooper <codekipper at gmail.com>
> ---
>  .../devicetree/bindings/sound/sun4i,spdif.txt      | 46 ++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/sun4i,spdif.txt
> 
> diff --git a/Documentation/devicetree/bindings/sound/sun4i,spdif.txt b/Documentation/devicetree/bindings/sound/sun4i,spdif.txt
> new file mode 100644
> index 0000000..55ed2f6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/sun4i,spdif.txt
> @@ -0,0 +1,46 @@
> +Allwinner Sony/Philips Digital Interface Format (S/PDIF) Controller
> +
> +The Allwinner S/PDIF audio block is a transceiver that allows the
> +processor to receive and transmit digital audio via an coaxial cable or
> +a fibre cable.
> +
> +Required properties:
> +
> +  - compatible		: should be one of the following:
> +    - "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC
> +
> +  - reg			: Offset and length of the register set for the device.
> +
> +  - interrupts		: Contains the spdif interrupt.
> +
> +  - dmas		: Generic dma devicetree binding as described in
> +			  Documentation/devicetree/bindings/dma/dma.txt.
> +
> +  - dma-names		: Two dmas have to be defined, "tx" and "rx".
> +
> +  - clocks		: Contains an entry for each entry in clock-names.
> +
> +  - clock-names		: Includes the following entries:
> +	"apb"		  clock for the spdif bus.
> +	"spdif"		  clock for spdif controller.
> +
> +Optional:
> +
> +  - spdif-in		: Enable block for capturing an SPDIF signal.
> +
> +  - spdif-out		: Enable block for transmitting an SPDIF signal.

Is that a generic property? What values can it hold?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/b55261c4/attachment.sig>

From robh at kernel.org  Tue Feb  2 14:43:48 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 2 Feb 2016 16:43:48 -0600
Subject: [PATCH 02/11] mfd: axp20x: Add bindings for AXP809 PMIC
In-Reply-To: <1454408864-24112-3-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-3-git-send-email-wens@csie.org>
Message-ID: <20160202224348.GA15250@rob-hp-laptop>

On Tue, Feb 02, 2016 at 06:27:35PM +0800, Chen-Yu Tsai wrote:
> This patch adds the basic and regulator bindings for the X-Powers AXP809
> PMIC.
> 
> Also update the DC-DC converter operating frequency for AXP22X/AXP80X.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
> ---
>  Documentation/devicetree/bindings/mfd/axp20x.txt | 31 ++++++++++++++++++++++--
>  1 file changed, 29 insertions(+), 2 deletions(-)

Acked-by: Rob Herring <robh at kernel.org>


From fcooper at ti.com  Tue Feb  2 15:25:14 2016
From: fcooper at ti.com (Franklin S Cooper Jr)
Date: Tue,  2 Feb 2016 17:25:14 -0600
Subject: [PATCH 0/3] Add initial support for TI's K2G SOC
Message-ID: <1454455517-7360-1-git-send-email-fcooper@ti.com>

This patchset provides initial support for K2G the latest addition to Texas
Instruments Keystone 2 product family. These patches are built on top of
the latest 4.5-rc2 commit.

K2G is a A15 + C66x DSP processor built to address the needs of industrial
communication and control, automotive and performance audio applications.

Supported peripherals include MMC,USB2.0,DCAN,DSS,McASP and PCIe SS.

The technical reference manual for K2G can be found here:
http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf

This patchset provides the ability to boot K2G's general purpose evm using
a ramfs filesystem.

Additional patches will follow this series that will add support for new
drivers that will enable additional peripherals and features

K2G Bootlog on 4.5-rc2:
http://pastebin.ubuntu.com/14861580/

To show no regressions:
K2E Bootlog: http://pastebin.ubuntu.com/14861523/
Other Keystone 2 devices need this partial revert discussed in the below
thread.
http://marc.info/?l=linux-netdev&m=145444838030865&w=2

This is an issue seen on the netcp driver and has nothing to do with this
patch set.

Nishanth Menon (1):
  ARM: keystone: Create new binding for K2G SoC

Vitaly Andrianov (2):
  ARM: dts: keystone: Add Initial DT support for TI K2G SoC family
  ARM: dts: keystone: Add minimum support for K2G evm

 .../devicetree/bindings/arm/keystone/keystone.txt  |  5 ++
 arch/arm/boot/dts/Makefile                         |  3 +-
 arch/arm/boot/dts/k2g-evm.dts                      | 32 ++++++++
 arch/arm/boot/dts/k2g.dtsi                         | 89 ++++++++++++++++++++++
 arch/arm/mach-keystone/keystone.c                  |  1 +
 5 files changed, 129 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/k2g-evm.dts
 create mode 100644 arch/arm/boot/dts/k2g.dtsi

-- 
2.7.0



From fcooper at ti.com  Tue Feb  2 15:25:15 2016
From: fcooper at ti.com (Franklin S Cooper Jr)
Date: Tue,  2 Feb 2016 17:25:15 -0600
Subject: [PATCH 1/3] ARM: keystone: Create new binding for K2G SoC
In-Reply-To: <1454455517-7360-1-git-send-email-fcooper@ti.com>
References: <1454455517-7360-1-git-send-email-fcooper@ti.com>
Message-ID: <1454455517-7360-2-git-send-email-fcooper@ti.com>

From: Nishanth Menon <nm at ti.com>

K2G SoC family is the newest version of the Keystone family of processors.

The technical reference manual for K2G can be found here:
http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf

Add new bindings for K2G and the K2G evm. Also document these new bindings.

Signed-off-by: Nishanth Menon <nm at ti.com>
Signed-off-by: Franklin S Cooper Jr <fcooper at ti.com>
---
 Documentation/devicetree/bindings/arm/keystone/keystone.txt | 5 +++++
 arch/arm/mach-keystone/keystone.c                           | 1 +
 2 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/keystone/keystone.txt b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
index 3090a8a..48f6703 100644
--- a/Documentation/devicetree/bindings/arm/keystone/keystone.txt
+++ b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
@@ -22,6 +22,8 @@ SoCs:
    compatible = "ti,k2l", "ti,keystone"
 - Keystone 2 Edison
    compatible = "ti,k2e", "ti,keystone"
+- K2G
+   compatible = "ti,k2g", "ti,keystone"
 
 Boards:
 -  Keystone 2 Hawking/Kepler EVM
@@ -32,3 +34,6 @@ Boards:
 
 -  Keystone 2 Edison EVM
    compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone"
+
+-  K2G EVM
+   compatible = "ti,k2g-evm", "ti,k2g", "ti-keystone"
diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index c279293..55cb199 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -100,6 +100,7 @@ static const char *const keystone_match[] __initconst = {
 	"ti,k2hk",
 	"ti,k2e",
 	"ti,k2l",
+	"ti,k2g",
 	"ti,keystone",
 	NULL,
 };
-- 
2.7.0



From fcooper at ti.com  Tue Feb  2 15:25:17 2016
From: fcooper at ti.com (Franklin S Cooper Jr)
Date: Tue,  2 Feb 2016 17:25:17 -0600
Subject: [PATCH 3/3] ARM: dts: keystone: Add minimum support for K2G evm
In-Reply-To: <1454455517-7360-1-git-send-email-fcooper@ti.com>
References: <1454455517-7360-1-git-send-email-fcooper@ti.com>
Message-ID: <1454455517-7360-4-git-send-email-fcooper@ti.com>

From: Vitaly Andrianov <vitalya at ti.com>

Add barebones K2G evm dts. This DTS allows the board to boot using a
ram based filesystem.

The technical reference manual for K2G can be found here:
http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf

Signed-off-by: Vitaly Andrianov <vitalya at ti.com>
Signed-off-by: Franklin S Cooper Jr <fcooper at ti.com>
---
 arch/arm/boot/dts/Makefile    |  3 ++-
 arch/arm/boot/dts/k2g-evm.dts | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/k2g-evm.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..8343f66 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -156,7 +156,8 @@ dtb-$(CONFIG_ARCH_INTEGRATOR) += \
 dtb-$(CONFIG_ARCH_KEYSTONE) += \
 	k2hk-evm.dtb \
 	k2l-evm.dtb \
-	k2e-evm.dtb
+	k2e-evm.dtb \
+	k2g-evm.dtb
 dtb-$(CONFIG_MACH_KIRKWOOD) += \
 	kirkwood-b3.dtb \
 	kirkwood-blackarmor-nas220.dtb \
diff --git a/arch/arm/boot/dts/k2g-evm.dts b/arch/arm/boot/dts/k2g-evm.dts
new file mode 100644
index 0000000..99663b3
--- /dev/null
+++ b/arch/arm/boot/dts/k2g-evm.dts
@@ -0,0 +1,32 @@
+/*
+ * Device Tree Source for K2G EVM
+ *
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+/dts-v1/;
+
+#include "k2g.dtsi"
+
+/ {
+	compatible =  "ti,k2g-evm", "ti,k2g", "ti,keystone";
+	model = "Texas Instruments K2G General Purpose EVM";
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000008 0x00000000 0x00000000 0x80000000>;
+	};
+
+};
+
+&uart0 {
+	status = "okay";
+};
-- 
2.7.0



From fcooper at ti.com  Tue Feb  2 15:25:16 2016
From: fcooper at ti.com (Franklin S Cooper Jr)
Date: Tue,  2 Feb 2016 17:25:16 -0600
Subject: [PATCH 2/3] ARM: dts: keystone: Add Initial DT support for TI K2G SoC
 family
In-Reply-To: <1454455517-7360-1-git-send-email-fcooper@ti.com>
References: <1454455517-7360-1-git-send-email-fcooper@ti.com>
Message-ID: <1454455517-7360-3-git-send-email-fcooper@ti.com>

From: Vitaly Andrianov <vitalya at ti.com>

K2G is the newest addition of TI's Keystone 2 product family. It is a
single core Cortex A15 and a C66x DSP.

K2G supports standard peripherals such as SPI, UART, MMC and USB 2.0.

Includes two dual-core Programmable Real-time Unit and Industrial
Communication Subsystems (PRU-ICSS).

The technical reference manual for K2G can be found here:
http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf

This device is targeted for a variety of applications which include, but
are not limited to:

Home audio
Professional audio
Industrial Programmable Logic Control

The peripheral nodes that have been included in this patch have been
tested during bring-up. Since all peripherals will not necessarily be
used on all boards, disable all peripherals by default. This allow
the board dts to selectively choose which peripherals it wants to
enable.

This SoC now uses the next generation of power management architecture
with the PM functionality located in a microcontroller embedded in the SOC.

Support for this new PM architecture along with other peripherals will be
added in future patches.

Signed-off-by: Vitaly Andrianov <vitalya at ti.com>
Signed-off-by: Franklin S Cooper Jr <fcooper at ti.com>
---
 arch/arm/boot/dts/k2g.dtsi | 89 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 arch/arm/boot/dts/k2g.dtsi

diff --git a/arch/arm/boot/dts/k2g.dtsi b/arch/arm/boot/dts/k2g.dtsi
new file mode 100644
index 0000000..7ff2796
--- /dev/null
+++ b/arch/arm/boot/dts/k2g.dtsi
@@ -0,0 +1,89 @@
+/*
+ * Device Tree Source for K2G SOC
+ *
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "skeleton.dtsi"
+
+/ {
+	compatible = "ti,k2g","ti,keystone";
+	model = "Texas Instruments K2G SoC";
+	#address-cells = <2>;
+	#size-cells = <2>;
+	interrupt-parent = <&gic>;
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			compatible = "arm,cortex-a15";
+			device_type = "cpu";
+			reg = <0>;
+		};
+	};
+
+	gic: interrupt-controller at 02561000 {
+		compatible = "arm,cortex-a15-gic";
+		#interrupt-cells = <3>;
+		interrupt-controller;
+		reg = <0x0 0x02561000 0x0 0x1000>,
+		      <0x0 0x02562000 0x0 0x2000>,
+		      <0x0 0x02564000 0x0 0x1000>,
+		      <0x0 0x02566000 0x0 0x2000>;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) |
+				IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts =
+			<GIC_PPI 13
+				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			<GIC_PPI 14
+				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			<GIC_PPI 11
+				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			<GIC_PPI 10
+				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+	};
+
+	pmu {
+		compatible = "arm,cortex-a15-pmu";
+		interrupts = <GIC_SPI 4 IRQ_TYPE_EDGE_RISING>;
+	};
+
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "ti,keystone","simple-bus";
+		ranges = <0x0 0x0 0x0 0xc0000000>;
+		dma-ranges = <0x80000000 0x8 0x00000000 0x80000000>;
+
+		uart0: serial at 02530c00 {
+			compatible = "ns16550a";
+			current-speed = <115200>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			reg = <0x02530c00 0x100>;
+			interrupts = <GIC_SPI 164 IRQ_TYPE_EDGE_RISING>;
+			clock-frequency = <200000000>;
+			status = "disabled";
+		};
+	};
+};
-- 
2.7.0



From robh at kernel.org  Tue Feb  2 15:34:17 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 2 Feb 2016 17:34:17 -0600
Subject: [PATCH v10 3/8] dt, numa: adding numa dt binding implementation.
In-Reply-To: <1454407763-1017-4-git-send-email-gkulkarni@caviumnetworks.com>
References: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
 <1454407763-1017-4-git-send-email-gkulkarni@caviumnetworks.com>
Message-ID: <20160202233417.GA4739@rob-hp-laptop>

On Tue, Feb 02, 2016 at 03:39:18PM +0530, Ganapatrao Kulkarni wrote:
> dt node parsing for numa topology is done using device property
> numa-node-id and device node distance-map.
> 
> Reviewed-by: Robert Richter <rrichter at cavium.com>
> Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
> ---
>  drivers/of/Kconfig   |  11 +++
>  drivers/of/Makefile  |   1 +
>  drivers/of/of_numa.c | 207 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of.h   |   4 +
>  4 files changed, 223 insertions(+)
>  create mode 100644 drivers/of/of_numa.c
> 
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index e2a4841..8f9cc3a 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -112,4 +112,15 @@ config OF_OVERLAY
>  	  While this option is selected automatically when needed, you can
>  	  enable it manually to improve device tree unit test coverage.
>  
> +config OF_NUMA
> +	bool "Device Tree NUMA support"

Does this need to be user visible?

> +	depends on NUMA
> +	depends on OF
> +	depends on ARM64

drop this (and make sure it compiles on other arches). It will fail 
because you also have a dependency on FDT.

> +	default y
> +	help
> +	  Enable Device Tree NUMA support.
> +	  This enables the numa mapping of cpu, memory, io and
> +	  inter node distances using dt bindings.
> +
>  endif # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index 156c072..bee3fa9 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -14,5 +14,6 @@ obj-$(CONFIG_OF_MTD)	+= of_mtd.o
>  obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
>  obj-$(CONFIG_OF_RESOLVE)  += resolver.o
>  obj-$(CONFIG_OF_OVERLAY) += overlay.o
> +obj-$(CONFIG_OF_NUMA) += of_numa.o
>  
>  obj-$(CONFIG_OF_UNITTEST) += unittest-data/
> diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
> new file mode 100644
> index 0000000..1142cdb
> --- /dev/null
> +++ b/drivers/of/of_numa.c
> @@ -0,0 +1,207 @@
> +/*
> + * OF NUMA Parsing support.
> + *
> + * Copyright (C) 2015 Cavium Inc.
> + * Author: Ganapatrao Kulkarni <gkulkarni at 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/of.h>
> +#include <linux/of_fdt.h>

Surely you need some numa related includes.

> +
> +/* define default numa node to 0 */
> +#define DEFAULT_NODE 0
> +
> +/* Returns nid in the range [0..MAX_NUMNODES-1],
> + * or NUMA_NO_NODE if no valid numa-node-id entry found
> + * or DEFAULT_NODE if no numa-node-id entry exists
> + */
> +static int of_numa_prop_to_nid(const __be32 *of_numa_prop, int length)
> +{
> +	int nid;
> +
> +	if (!of_numa_prop)
> +		return DEFAULT_NODE;
> +
> +	if (length != sizeof(*of_numa_prop)) {
> +		pr_warn("NUMA: Invalid of_numa_prop length %d found.\n",
> +				length);
> +		return NUMA_NO_NODE;
> +	}
> +
> +	nid = of_read_number(of_numa_prop, 1);
> +	if (nid >= MAX_NUMNODES) {
> +		pr_warn("NUMA: Invalid numa node %d found.\n", nid);
> +		return NUMA_NO_NODE;
> +	}
> +
> +	return nid;
> +}
> +
> +static int __init early_init_of_node_to_nid(unsigned long node)
> +{
> +	int length;
> +	const __be32 *of_numa_prop;
> +
> +	of_numa_prop = of_get_flat_dt_prop(node, "numa-node-id", &length);
> +
> +	return of_numa_prop_to_nid(of_numa_prop, length);
> +}
> +
> +/*
> + * Even though we connect cpus to numa domains later in SMP
> + * init, we need to know the node ids now for all cpus.
> +*/
> +static int __init early_init_parse_cpu_node(unsigned long node)
> +{
> +	int nid;
> +	const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
> +
> +	if (type == NULL)
> +		return 0;
> +
> +	if (strcmp(type, "cpu") != 0)
> +		return 0;
> +
> +	nid = early_init_of_node_to_nid(node);
> +	if (nid == NUMA_NO_NODE)
> +		return -EINVAL;
> +
> +	node_set(nid, numa_nodes_parsed);
> +	return 0;
> +}
> +
> +static int __init early_init_parse_memory_node(unsigned long node)
> +{
> +	const __be32 *reg, *endp;
> +	int length;
> +	int nid;
> +	const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
> +
> +	if (type == NULL)
> +		return 0;
> +
> +	if (strcmp(type, "memory") != 0)
> +		return 0;
> +
> +	nid = early_init_of_node_to_nid(node);
> +	if (nid == NUMA_NO_NODE)
> +		return -EINVAL;
> +
> +	reg = of_get_flat_dt_prop(node, "reg", &length);
> +	endp = reg + (length / sizeof(__be32));
> +
> +	while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
> +		u64 base, size;
> +
> +		base = dt_mem_next_cell(dt_root_addr_cells, &reg);
> +		size = dt_mem_next_cell(dt_root_size_cells, &reg);
> +		pr_debug("NUMA:  base = %llx , node = %u\n",
> +				base, nid);
> +

We already have code to parse memory nodes. Can the NUMA part be 
combined somehow.

> +		if (numa_add_memblk(nid, base, size) < 0)
> +			return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int __init early_init_parse_distance_map_v1(unsigned long node,
> +		const char *uname)
> +{
> +	const __be32 *prop_dist_matrix;
> +	int length = 0, i, matrix_count;
> +	int nr_size_cells = OF_ROOT_NODE_SIZE_CELLS_DEFAULT;
> +
> +	pr_info("NUMA: parsing numa-distance-map-v1\n");
> +
> +	prop_dist_matrix =
> +		of_get_flat_dt_prop(node, "distance-matrix", &length);
> +
> +	if (!length) {
> +		pr_err("NUMA: failed to parse distance-matrix\n");
> +		return -ENODEV;
> +	}
> +
> +	matrix_count = ((length / sizeof(__be32)) / (3 * nr_size_cells));
> +
> +	if ((matrix_count * sizeof(__be32) * 3 * nr_size_cells) !=  length) {
> +		pr_warn("NUMA: invalid distance-matrix length %d\n", length);
> +		return -EINVAL;
> +	}
> +
> +	for (i = 0; i < matrix_count; i++) {
> +		u32 nodea, nodeb, distance;
> +
> +		nodea = dt_mem_next_cell(nr_size_cells, &prop_dist_matrix);
> +		nodeb = dt_mem_next_cell(nr_size_cells, &prop_dist_matrix);
> +		distance = dt_mem_next_cell(nr_size_cells, &prop_dist_matrix);
> +		numa_set_distance(nodea, nodeb, distance);
> +		pr_debug("NUMA:  distance[node%d -> node%d] = %d\n",
> +				nodea, nodeb, distance);
> +
> +		/* Set default distance of node B->A same as A->B */
> +		if (nodeb > nodea)
> +			numa_set_distance(nodeb, nodea, distance);
> +	}
> +
> +	return 0;
> +}
> +
> +static int __init early_init_parse_distance_map(unsigned long node,
> +		const char *uname)
> +{
> +	if (strcmp(uname, "distance-map") != 0)
> +		return 0;
> +
> +	if (of_flat_dt_is_compatible(node, "numa-distance-map-v1"))
> +		return early_init_parse_distance_map_v1(node, uname);
> +
> +	pr_err("NUMA: invalid distance-map device node\n");
> +	return -EINVAL;
> +}
> +
> +static int __init early_init_of_scan_numa_map(unsigned long node, const char *uname,
> +				     int depth, void *data)
> +{
> +	int ret;
> +
> +	ret = early_init_parse_cpu_node(node);
> +	if (ret)
> +		return ret;
> +
> +	ret = early_init_parse_memory_node(node);
> +	if (ret)
> +		return ret;
> +
> +	return early_init_parse_distance_map(node, uname);
> +}
> +
> +int of_node_to_nid(struct device_node *device)
> +{
> +	const __be32 *of_numa_prop;
> +	int length;
> +
> +	of_numa_prop = of_get_property(device, "numa-node-id", &length);
> +	if (of_numa_prop)
> +		return of_numa_prop_to_nid(of_numa_prop, length);
> +
> +	return NUMA_NO_NODE;
> +}
> +
> +/* DT node mapping is done already early_init_of_scan_memory */
> +int __init of_numa_init(void)
> +{
> +	return of_scan_flat_dt(early_init_of_scan_numa_map, NULL);
> +}
> diff --git a/include/linux/of.h b/include/linux/of.h
> index dd10626..23e5bad 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -685,6 +685,10 @@ static inline int of_node_to_nid(struct device_node *device)
>  }
>  #endif
>  
> +#ifdef CONFIG_OF_NUMA
> +extern int __init of_numa_init(void);
> +#endif

You don't need an ifdef here unless you need an empty function.

Can this be called internally by the DT code when it does the all 
the other flat scanning instead of adding another call from arch code to 
DT code. Ideally, the arch code would call DT code once and it would do 
all the parsing it needs to.

Rob


From tony at atomide.com  Tue Feb  2 15:39:12 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 2 Feb 2016 15:39:12 -0800
Subject: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
In-Reply-To: <56B077D4.3030902@gmail.com>
References: <20160106182650.GM12777@atomide.com> <568D5F54.7040900@gmail.com>
 <20160107180700.GN12777@atomide.com> <568EDC8D.7070205@gmail.com>
 <20160108022619.GS12777@atomide.com> <568F4596.8020206@gmail.com>
 <20160108075913.GN11364@pali> <569052FE.1040008@gmail.com>
 <20160121091437.GT7192@pali> <56B077D4.3030902@gmail.com>
Message-ID: <20160202233911.GB19432@atomide.com>

* Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com> [160202 01:34]:
> On 21.01.2016 11:14, Pali Roh?r wrote:
> >On Saturday 09 January 2016 02:23:26 Ivaylo Dimitrov wrote:
> >>The key word here is "sometimes". i.e sometimes it hapens on normal reboot,
> >>sometimes it happens on oops.
> >
> >So where is problem? In omap-gpmc? mtd? onenand? or ubifs? Or in
> >different component? Do we know at least this?
> >
> 
> I think I made some progress on the issue, it seems I have to have *both*
> e7b11dc7b77bfce0a351230a5feeadc1d0bba997
> (e7b11dc7b77bfce0a351230a5feeadc1d0bba997) reverted *and*
> HWMOD_INIT_NO_RESET restored in omap3xxx_gpmc_hwmod flags to have working
> onenand.

That is strange. This is what I get with omap2plus_defconfig and
omap-for-v4.5/fixes-rc1 after flashing the rootfs and booting kernel
like you suggested on irc:

# dmesg | grep -i -e ubi -e onenand
[    2.502899] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x01000000, virtual base d0940000, freq 83 MHz
[    2.514373] OneNAND Manufacturer: Numonyx (0x20)
[    2.519287] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
[    2.524444] OneNAND version = 0x0031
[    2.671966] 6 ofpart partitions found on MTD device omap2-onenand
[    2.678436] Creating 6 MTD partitions on "omap2-onenand":
[    3.414764] ubi0: attaching mtd5
[    3.668212] ubi0: scanning is finished
[    3.716552] ubi0: attached mtd5 (name "rootfs", size 251 MiB)
[    3.722839] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
[    3.730194] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
[    3.737304] ubi0: VID header offset: 512 (aligned 512), data offset: 2048
[    3.744537] ubi0: good PEBs: 2010, bad PEBs: 0, corrupted PEBs: 0
[    3.751037] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
[    3.758697] ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 0
[    3.767578] ubi0: available PEBs: 0, total reserved PEBs: 2010, PEBs reserved for bad PEB handling: 40
[    3.923980] ubi0: background thread "ubi_bgt0d" started, PID 85
[    3.980529] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 87
[    3.996337] UBIFS (ubi0:0): recovery needed
[    4.079925] UBIFS (ubi0:0): recovery completed
[    4.085876] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[    4.093780] UBIFS (ubi0:0): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[    4.104339] UBIFS (ubi0:0): FS size: 252241920 bytes (240 MiB, 1955 LEBs), journal size 9033728 bytes (8 MiB, 71 LEBs)
[    4.115722] UBIFS (ubi0:0): reserved for root: 4190434 bytes (4092 KiB)
[    4.122772] UBIFS (ubi0:0): media format: w4/r0 (latest is w4/r0), UUID 8F30A88A-F605-4291-9927-00CF3A2AE119, small LPT model
[    4.136077] VFS: Mounted root (ubifs filesystem) on device 0:15.

I copied over the modules to this rootfs too :) But in general onenand
seems to behave for me.

> Tony, shall I hardcode GPMC_CS_CONFIG4 OEONTIME to be the same as NOLO's or
> it does not make sense?

Not sure what is still wrong. But yeah some borderline GPMC timing
differences could affect it.

Regards,

Tony


From tony at atomide.com  Tue Feb  2 15:41:45 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 2 Feb 2016 15:41:45 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFosQjkHDVSvy67+hstjjFseXQP5WYXrJE19GgVFYJ099w@mail.gmail.com>
References: <20160201232833.GR19432@atomide.com>
 <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>
 <20160202030533.GT19432@atomide.com>
 <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>
 <20160202163536.GU19432@atomide.com>
 <CAPDyKFosQjkHDVSvy67+hstjjFseXQP5WYXrJE19GgVFYJ099w@mail.gmail.com>
Message-ID: <20160202234145.GC19432@atomide.com>

* Ulf Hansson <ulf.hansson at linaro.org> [160202 12:48]:
> On 2 February 2016 at 17:35, Tony Lindgren <tony at atomide.com> wrote:
> > That's a valid error though, let's not remove it. The reason why we
> > call runtime_resume() twice is because runtime_suspend callback never
> > gets called like I explain above.
> 
> This isn't an error, it's just a hickup in the synchronization of the
> runtime PM status.

I'd rather not get the hardware state out of sync with PM runtime..

> Very similar what happens at the first probe, when the driver core has
> initialized the runtime PM status to RPM_SUSPENDED at the device
> registration.

Well we actually pretty much have devices in that state to start
with.

> To me, it's the responsible of the PM domain to *help* with the
> synchronization, not prevent it as it currently does.

The problem is that the hardware state gets out of sync with
PM runtime. And that's going to be a pain to debug later on.

> > --- a/drivers/mmc/host/omap_hsmmc.c
> > +++ b/drivers/mmc/host/omap_hsmmc.c
> > @@ -2232,6 +2232,7 @@ err_irq:
> >                 dma_release_channel(host->tx_chan);
> >         if (host->rx_chan)
> >                 dma_release_channel(host->rx_chan);
> > +       pm_runtime_dont_use_autosuspend(host->dev);
> 
> It's good know this works, although do you intend to fix this sequence
> for all omap drivers/devices that's part of the hwmod PM domain?
> 
> I haven't checked the number of drivers this would affect, but I
> imagine there could be quite many with similar behaviour and thus may
> suffer from the same issue.

Yeah not sure what the right fix is. But I'd rather patch the
few drivers using autosuspend if we come to the conclusion
that there is no bug in PM runtime.

> Could you please test my version 2 of the patch I attached earlier. I
> still believe it's the best way to solve the regression, if it works
> of course. :-)

And I don't like it because of the reasons above :) But yeah
gave it a quick try and that too works as expected.

Regards,

Tony


From drivshin.allworx at gmail.com  Tue Feb  2 15:44:43 2016
From: drivshin.allworx at gmail.com (David Rivshin (Allworx))
Date: Tue, 2 Feb 2016 18:44:43 -0500
Subject: [PATCH 4/4] pwm: omap-dmtimer: add dev_dbg() message for
 effective period and duty cycle
In-Reply-To: <20160202162330.GA4918@ulmo>
References: <1454128014-22866-1-git-send-email-drivshin.allworx@gmail.com>
 <1454128014-22866-5-git-send-email-drivshin.allworx@gmail.com>
 <CAA3gFWvSsctXtds6_SEtYY1yUdWJDR1XjznGS6qjdrGW5Dbw=A@mail.gmail.com>
 <20160201132228.2634b72e.drivshin.allworx@gmail.com>
 <20160201185952.GN19432@atomide.com> <20160202162330.GA4918@ulmo>
Message-ID: <20160202184443.1e1b0bf5.drivshin.allworx@gmail.com>

On Tue, 2 Feb 2016 17:23:30 +0100
Thierry Reding <thierry.reding at gmail.com> wrote:

> On Mon, Feb 01, 2016 at 10:59:52AM -0800, Tony Lindgren wrote:
> > Hi,
> > 
> > * David Rivshin (Allworx) <drivshin.allworx at gmail.com> [160201
> > 10:23]:  
> > > On Sat, 30 Jan 2016 15:51:06 +0100
> > > Neil Armstrong <narmstrong at baylibre.com> wrote:
> > >   
> > > > 2016-01-30 5:26 GMT+01:00 David Rivshin (Allworx)
> > > > <drivshin.allworx at gmail.com>:  
> > > > > From: David Rivshin <drivshin at allworx.com>
> > > > >
> > > > > After going through the math and constraints checking to
> > > > > compute load and match values, it is helpful to know what the
> > > > > resultant period and duty cycle are.
> > > > >
> > > > > Signed-off-by: David Rivshin <drivshin at allworx.com>
> > > > > ---
> > > > >
> > > > > I found this helpful while testing the other changes, so I
> > > > > included it in case it may be of use to someone in the
> > > > > future. I would have no issues with dropping this if it's not
> > > > > considered worthwhile.    
> > > > 
> > > > It's useful, but converting it as a sysfs attribute would be
> > > > great !  
> > > 
> > > Hrm, yes that is an interesting thought. I imagine that many PWM 
> > > devices have similar constraints, so perhaps that would be best 
> > > handled generically in the pwm core? Maybe as new optional
> > > get_*() ops, a modification to the config() op to add output
> > > params, or just updating new fields in the struct pwm directly?  
> > 
> > Yeah for /sys entry it should be Linux generic. The other option
> > is to use debugfs for driver specific things.  
> 
> Let's go with debugfs for this one. This is used for diagnostic

I had looked at using the dbg_show() op to add some additional data. 
One thing that discouraged me from going down that path was that 
it replaced the call to pwm_dbg_show() for that chip. I wouldn't 
want to loose the existing output, as it is useful, but also didn't
like the thought of duplicating the logic/formatting. I think some 
way to have both the standard output and add extra output somewhere
(e.g. same line, line after each pwm_device, block after all 
pwm_devices on the chip) would make that path more attractive.

Or were you thinking of a separate (per-chip) debugfs file for this 
type of information? 

> purposes and not typically needed when configuring a PWM. While other
> drivers may compute similar hardware-specific values, there's nothing
> generic to them. The period and duty cycle are the generic input
> values and those are already exposed via sysfs.

Just to clarify, what I was thinking of as generic was the concept
that "period/duty I asked for" and "period/duty I got" may be
different, sometimes to a substantial degree. I could imagine 
userspace wanting to know the latter, which is what I think Neil 
was suggesting.

For the sake of an example, the input clock for a dmtimer is sometimes
(often?) 32768Hz, which means that the real period and duty_cycle output
are limited to being a multiple of ~61035.2ns (16384Hz). So an attempt 
to set a period of 100000ns (10KHz) would result in either 61035.2ns, or 
122070.4ns (8192Hz), depending on the implementation of the driver (and 
patch 2 changes behavior from the former to the latter). You can also 
have cases where you desired a 33% duty cycle, but got a 25% duty cycle 
instead.

In a quick look, I see substantially similar calculations (i.e. 
clk_rate*period_ns/10^9) in most of the other pwm drivers, which makes 
sense for any that are programmed in terms of some input clock. This 
type of calculation almost guarantees that requested and actual period/
duty_cycle are going to be different to some degree. Some drivers look 
like they have even more complicated behavior, apparently due to other 
hardware constraints. For instance, fsl-ftm (among others) looks to be 
using a power-of-2 prescaler to fit the period_cycles into a 16bit field.

Of course if the input clock rate for these types of devices is 
sufficiently high (enough that the desired period is many input clock 
cycles), then the difference between "desired" and "actual" is probably 
small enough that noone cares. I'm not sure how common it is that
  a) there is a substantial difference, and
  b) userspace cares about it, and
  c) userspace didn't carefully select an achievable value already
If noone has brought it up before, then I'd guess the answer is "not very".


From tony at atomide.com  Tue Feb  2 15:46:27 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 2 Feb 2016 15:46:27 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <Pine.LNX.4.44L0.1602021626540.1653-100000@iolanthe.rowland.org>
References: <20160202210345.GZ19432@atomide.com>
 <Pine.LNX.4.44L0.1602021626540.1653-100000@iolanthe.rowland.org>
Message-ID: <20160202234626.GD19432@atomide.com>

* Alan Stern <stern at rowland.harvard.edu> [160202 13:46]:
> On Tue, 2 Feb 2016, Tony Lindgren wrote:
> 
> > > Also, what is autosuspend_delay set to for your device?  And is 
> > > runtime_auto set?
> > 
> > It's 100 at that point, see the commented snippet below from
> > omap_hsmmc_probe():
> > 
> > 	pm_runtime_enable(host->dev);
> > 	pm_runtime_get_sync(host->dev);
> > 	pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY);
> > 	/* NOTE: pm_runtime_dont_use_autosuspend(host->dev) needed here? */
> > 	pm_runtime_use_autosuspend(host->dev);
> > 	...
> > 	/* gets -EPROBE_DEFER */
> > err_irq:
> > 	...
> > 	pm_runtime_put_sync(host->dev);
> 
> You could try changing this to pm_runtime_put_sync_suspend().  But
> putting pm_runtime_dont_use_autosuspend() before the put_sync seems
> like a perfectly reasonable thing to do, especially if you feel you
> should reverse all the changes you made at the start.

They both seem to fix the problem.

> >         pm_runtime_disable(host->dev);
> > 	/* NOTE: suspend callback never gets called unless
> > 	 * pm_runtime_dont_use_autosuspend() is called
> > 	 * before pm_runtime_put_sync() above.
> > 	 */
> > 	 ...
> > 
> > > > > Does pm_runtime_use_autosuspend() get called by the probe routine?  If 
> > > > > it does, then perhaps you can get what you want by having the probe 
> > > > > routine call pm_runtime_dont_use_autosuspend() whenever it's about to 
> > > > > return an error -- particularly -EDEFER.
> > > > 
> > > > Yes so far that's the only fix that seems to work like I posted
> > > > earlier. But is that the right fix though?
> > > 
> > > No, not really.  Ideally you would leave autosuspend turned on.  The 
> > > delay would be long enough to that after -EDEFER, another probe would 
> > > start before the delay expired.  But shortly after the last probe 
> > > attempt, the delay would expire and the device would then be put in low 
> > > power.
> > 
> > But then what about the new reinit function? To me it seems that
> > we should not attempt to maintain a state from the earlier failed
> > probe. Or are you thinking we just skip the reinit if autosuspend
> > is set?
> 
> The reinit function gets called too late to do what you want -- namely, 
> put the hardware in a low-power state.

Right, the problem is the lack of suspend on the first probe. But
for having autosuspend timeout long enough for the next probe
would mean that we can't reset the PM runtime state in between.

> That _is_ what you want, isn't it?  The alternative is to leave
> dev->power.rpm_status set to RPM_ACTIVE, to match the hardware's actual 
> state.

As far as I can tell things work just fine if the failed probe
suspend the device at the end of the failed probe.

> Given that the reinit function is supposed to restore the initial 
> settings, it probably ought to call pm_runtime_dont_use_autosuspend().  
> But that won't be enough to fix your problem.
> 
> > > > If we wanted to have some generic fix, it seems we would have to pass
> > > > a new flag in pm_runtime_put_sync() to ignore any autosuspend
> > > > configuration. But I don't know if that's what we want to or should
> > > > do though?
> > > 
> > > I don't think so.
> > 
> > So should we just establish a policy that pm_runtime_use_autosuspend()
> > needs to be paired with pm_runtime_dont_use_autosuspend() for
> > pm_runtime_put_sync() to work?
> 
> Your understanding is slightly wrong.  pm_runtime_put_sync() _does_
> work -- that is, it does what it's supposed to do.  The difficulty is
> that what it's supposed to do doesn't match what you think.
> 
> pm_runtime_put_sync() is supposed to follow the driver's wishes.  It
> invokes the driver's runtime_idle callback if there is one, and the
> callback routine can start a suspend or an autosuspend.  If there is no
> callback, it will use whatever autosuspend setting the driver has set
> up.  If you want to override the autosuspend setting, use
> pm_runtime_put_sync_suspend() instead.

Yes.. That works too. I guess the thing to consider is if we should
make pm_runtime_put_sync() always sync along the lines of a patch
I posted earlier today. That could avoid quite a bit of confusion
as already seen in this thread :)

Regards,

Tony


From santosh.shilimkar at oracle.com  Tue Feb  2 15:59:36 2016
From: santosh.shilimkar at oracle.com (santosh shilimkar)
Date: Tue, 2 Feb 2016 15:59:36 -0800
Subject: [PATCH 0/3] Add initial support for TI's K2G SOC
In-Reply-To: <1454455517-7360-1-git-send-email-fcooper@ti.com>
References: <1454455517-7360-1-git-send-email-fcooper@ti.com>
Message-ID: <56B142E8.4090301@oracle.com>

On 2/2/2016 3:25 PM, Franklin S Cooper Jr wrote:
> This patchset provides initial support for K2G the latest addition to Texas
> Instruments Keystone 2 product family. These patches are built on top of
> the latest 4.5-rc2 commit.
>
> K2G is a A15 + C66x DSP processor built to address the needs of industrial
> communication and control, automotive and performance audio applications.
>
> Supported peripherals include MMC,USB2.0,DCAN,DSS,McASP and PCIe SS.
>
> The technical reference manual for K2G can be found here:
> http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf
>
> This patchset provides the ability to boot K2G's general purpose evm using
> a ramfs filesystem.
>
> Additional patches will follow this series that will add support for new
> drivers that will enable additional peripherals and features
>
> K2G Bootlog on 4.5-rc2:
> http://pastebin.ubuntu.com/14861580/
>
Quick scan of the series looks fine to me. I will wait for others to
come back for a week or so and then add to 4.6 queue.

Thanks for the series !!

Reagrds,
Santosh


From tony at atomide.com  Tue Feb  2 16:00:45 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 2 Feb 2016 16:00:45 -0800
Subject: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
In-Reply-To: <20160202233911.GB19432@atomide.com>
References: <568D5F54.7040900@gmail.com> <20160107180700.GN12777@atomide.com>
 <568EDC8D.7070205@gmail.com> <20160108022619.GS12777@atomide.com>
 <568F4596.8020206@gmail.com> <20160108075913.GN11364@pali>
 <569052FE.1040008@gmail.com> <20160121091437.GT7192@pali>
 <56B077D4.3030902@gmail.com> <20160202233911.GB19432@atomide.com>
Message-ID: <20160203000045.GE19432@atomide.com>

* Tony Lindgren <tony at atomide.com> [160202 15:40]:
> * Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com> [160202 01:34]:
> > On 21.01.2016 11:14, Pali Roh?r wrote:
> > >On Saturday 09 January 2016 02:23:26 Ivaylo Dimitrov wrote:
> > >>The key word here is "sometimes". i.e sometimes it hapens on normal reboot,
> > >>sometimes it happens on oops.
> > >
> > >So where is problem? In omap-gpmc? mtd? onenand? or ubifs? Or in
> > >different component? Do we know at least this?
> > >
> > 
> > I think I made some progress on the issue, it seems I have to have *both*
> > e7b11dc7b77bfce0a351230a5feeadc1d0bba997
> > (e7b11dc7b77bfce0a351230a5feeadc1d0bba997) reverted *and*
> > HWMOD_INIT_NO_RESET restored in omap3xxx_gpmc_hwmod flags to have working
> > onenand.
> 
> That is strange. This is what I get with omap2plus_defconfig and
> omap-for-v4.5/fixes-rc1 after flashing the rootfs and booting kernel
> like you suggested on irc:
> 
> # dmesg | grep -i -e ubi -e onenand
> [    2.502899] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x01000000, virtual base d0940000, freq 83 MHz
> [    2.514373] OneNAND Manufacturer: Numonyx (0x20)
> [    2.519287] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
> [    2.524444] OneNAND version = 0x0031
> [    2.671966] 6 ofpart partitions found on MTD device omap2-onenand
> [    2.678436] Creating 6 MTD partitions on "omap2-onenand":
> [    3.414764] ubi0: attaching mtd5
> [    3.668212] ubi0: scanning is finished
> [    3.716552] ubi0: attached mtd5 (name "rootfs", size 251 MiB)
> [    3.722839] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
> [    3.730194] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
> [    3.737304] ubi0: VID header offset: 512 (aligned 512), data offset: 2048
> [    3.744537] ubi0: good PEBs: 2010, bad PEBs: 0, corrupted PEBs: 0
> [    3.751037] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
> [    3.758697] ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 0
> [    3.767578] ubi0: available PEBs: 0, total reserved PEBs: 2010, PEBs reserved for bad PEB handling: 40
> [    3.923980] ubi0: background thread "ubi_bgt0d" started, PID 85
> [    3.980529] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 87
> [    3.996337] UBIFS (ubi0:0): recovery needed
> [    4.079925] UBIFS (ubi0:0): recovery completed
> [    4.085876] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs"
> [    4.093780] UBIFS (ubi0:0): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
> [    4.104339] UBIFS (ubi0:0): FS size: 252241920 bytes (240 MiB, 1955 LEBs), journal size 9033728 bytes (8 MiB, 71 LEBs)
> [    4.115722] UBIFS (ubi0:0): reserved for root: 4190434 bytes (4092 KiB)
> [    4.122772] UBIFS (ubi0:0): media format: w4/r0 (latest is w4/r0), UUID 8F30A88A-F605-4291-9927-00CF3A2AE119, small LPT model
> [    4.136077] VFS: Mounted root (ubifs filesystem) on device 0:15.
> 
> I copied over the modules to this rootfs too :) But in general onenand
> seems to behave for me.

And ere are my GPCM timings when booted with GPMC_DEBUG
in case they are different somehow for your device.

Regards,

Tony

omap-gpmc 6e000000.gpmc: GPMC revision 5.0
GPMC CS0: cs_on            :   0 ticks,   0 ns (was   0 ticks)   0 ns
GPMC CS0: cs_rd_off        :  14 ticks,  84 ns (was  16 ticks)  84 ns
GPMC CS0: cs_wr_off        :  19 ticks, 114 ns (was  16 ticks) 114 ns
GPMC CS0: adv_on           :   0 ticks,   0 ns (was   0 ticks)   0 ns
GPMC CS0: adv_rd_off       :   3 ticks,  18 ns (was   2 ticks)  18 ns
GPMC CS0: adv_wr_off       :   3 ticks,  18 ns (was   2 ticks)  18 ns
GPMC CS0: oe_on            :   5 ticks,  30 ns (was   2 ticks)  30 ns
GPMC CS0: oe_off           :  14 ticks,  84 ns (was  16 ticks)  84 ns
GPMC CS0: we_on            :   0 ticks,   0 ns (was   0 ticks)   0 ns
GPMC CS0: we_off           :  14 ticks,  84 ns (was  16 ticks)  84 ns
GPMC CS0: rd_cycle         :  18 ticks, 108 ns (was  19 ticks) 108 ns
GPMC CS0: wr_cycle         :  17 ticks, 102 ns (was  19 ticks) 102 ns
GPMC CS0: access           :  13 ticks,  78 ns (was  15 ticks)  78 ns
GPMC CS0: page_burst_access:   0 ticks,   0 ns (was   2 ticks)   0 ns
GPMC CS0: bus_turnaround   :   0 ticks,   0 ns (was   0 ticks)   0 ns
GPMC CS0: cycle2cycle_delay:   0 ticks,   0 ns (was   0 ticks)   0 ns
GPMC CS0: wr_data_mux_bus  :   5 ticks,  30 ns (was   5 ticks)  30 ns
GPMC CS0: wr_access        :  13 ticks,  78 ns (was  15 ticks)  78 ns
GPMC CS0: wait_monitoring  :   0 ticks,   0 ns (was   0 ticks)   0 ns
GPMC CS0: clk_activation   :   0 ticks,   0 ns (was   0 ticks)   0 ns
GPMC CS0 CLK period is 6 ns (div 1)
gpmc cs0 after gpmc_cs_set_timings:
cs0 GPMC_CS_CONFIG1: 0xd9001200
cs0 GPMC_CS_CONFIG2: 0x00130e00
cs0 GPMC_CS_CONFIG3: 0x00030300
cs0 GPMC_CS_CONFIG4: 0x0e000e05
cs0 GPMC_CS_CONFIG5: 0x000d1112
cs0 GPMC_CS_CONFIG6: 0x8d050000
gpmc cs0 access configuration:
gpmc,mux-add-data = <2>
gpmc,device-width = <1>
gpmc,wait-pin = <0>
gpmc,burst-length = <16>
gpmc,sync-write = <1>
gpmc,burst-write = <1>
gpmc,burst-read = <1>
gpmc,burst-wrap = <1>
gpmc cs0 timings configuration:
gpmc,cs-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,cs-rd-off-ns = <84> /* 79 ns - 84 ns; 14 ticks */
gpmc,cs-wr-off-ns = <114> /* 109 ns - 114 ns; 19 ticks */
gpmc,adv-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,adv-rd-off-ns = <18> /* 13 ns - 18 ns; 3 ticks */
gpmc,adv-wr-off-ns = <18> /* 13 ns - 18 ns; 3 ticks */
gpmc,oe-on-ns = <30> /* 25 ns - 30 ns; 5 ticks */
gpmc,oe-off-ns = <84> /* 79 ns - 84 ns; 14 ticks */
gpmc,we-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,we-off-ns = <84> /* 79 ns - 84 ns; 14 ticks */
gpmc,rd-cycle-ns = <108> /* 103 ns - 108 ns; 18 ticks */
gpmc,wr-cycle-ns = <102> /* 97 ns - 102 ns; 17 ticks */
gpmc,access-ns = <78> /* 73 ns - 78 ns; 13 ticks */
gpmc,page-burst-access-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,bus-turnaround-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,cycle2cycle-delay-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,wait-monitoring-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,clk-activation-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,wr-data-mux-bus-ns = <30> /* 25 ns - 30 ns; 5 ticks */
gpmc,wr-access-ns = <78> /* 73 ns - 78 ns; 13 ticks */
GPMC CS0: cs_on            :   0 ticks,   0 ns (was   0 ticks)   0 ns
GPMC CS0: cs_rd_off        :  16 ticks,  96 ns (was  14 ticks)  96 ns
GPMC CS0: cs_wr_off        :  16 ticks,  96 ns (was  19 ticks)  96 ns
GPMC CS0: adv_on           :   0 ticks,   0 ns (was   0 ticks)   0 ns
GPMC CS0: adv_rd_off       :   2 ticks,  12 ns (was   3 ticks)  12 ns
GPMC CS0: adv_wr_off       :   2 ticks,  12 ns (was   3 ticks)  12 ns
GPMC CS0: oe_on            :   3 ticks,  18 ns (was   5 ticks)  18 ns
GPMC CS0: oe_off           :  16 ticks,  96 ns (was  14 ticks)  96 ns
GPMC CS0: we_on            :   0 ticks,   0 ns (was   0 ticks)   0 ns
GPMC CS0: we_off           :  16 ticks,  96 ns (was  14 ticks)  96 ns
GPMC CS0: rd_cycle         :  19 ticks, 114 ns (was  18 ticks) 114 ns
GPMC CS0: wr_cycle         :  19 ticks, 114 ns (was  17 ticks) 114 ns
GPMC CS0: access           :  15 ticks,  90 ns (was  13 ticks)  90 ns
GPMC CS0: page_burst_access:   2 ticks,  12 ns (was   0 ticks)  12 ns
GPMC CS0: bus_turnaround   :   0 ticks,   0 ns (was   0 ticks)   0 ns
GPMC CS0: cycle2cycle_delay:   0 ticks,   0 ns (was   0 ticks)   0 ns
GPMC CS0: wr_data_mux_bus  :   5 ticks,  30 ns (was   5 ticks)  30 ns
GPMC CS0: wr_access        :  15 ticks,  90 ns (was  13 ticks)  90 ns
GPMC CS0: wait_monitoring  :   0 ticks,   0 ns (was   0 ticks)   0 ns
GPMC CS0: clk_activation   :   1 ticks,   6 ns (was   0 ticks)   6 ns
GPMC CS0 CLK period is 12 ns (div 2)
gpmc cs0 after gpmc_cs_set_timings:
cs0 GPMC_CS_CONFIG1: 0xfb001201
cs0 GPMC_CS_CONFIG2: 0x00101000
cs0 GPMC_CS_CONFIG3: 0x00020200
cs0 GPMC_CS_CONFIG4: 0x10001003
cs0 GPMC_CS_CONFIG5: 0x020f1313
cs0 GPMC_CS_CONFIG6: 0x8f050000
gpmc cs0 access configuration:
gpmc,mux-add-data = <2>
gpmc,device-width = <1>
gpmc,wait-pin = <0>
gpmc,burst-length = <16>
gpmc,sync-write = <1>
gpmc,burst-write = <1>
gpmc,gpmc,sync-read = <1>
gpmc,burst-read = <1>
gpmc,burst-wrap = <1>
gpmc cs0 timings configuration:
gpmc,cs-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,cs-rd-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */
gpmc,cs-wr-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */
gpmc,adv-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,adv-rd-off-ns = <12> /* 7 ns - 12 ns; 2 ticks */
gpmc,adv-wr-off-ns = <12> /* 7 ns - 12 ns; 2 ticks */
gpmc,oe-on-ns = <18> /* 13 ns - 18 ns; 3 ticks */
gpmc,oe-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */
gpmc,we-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,we-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */
gpmc,rd-cycle-ns = <114> /* 109 ns - 114 ns; 19 ticks */
gpmc,wr-cycle-ns = <114> /* 109 ns - 114 ns; 19 ticks */
gpmc,access-ns = <90> /* 85 ns - 90 ns; 15 ticks */
gpmc,page-burst-access-ns = <12> /* 7 ns - 12 ns; 2 ticks */
gpmc,bus-turnaround-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,cycle2cycle-delay-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,wait-monitoring-ns = <0> /* 0 ns - 0 ns; 0 ticks */
gpmc,clk-activation-ns = <6> /* 1 ns - 6 ns; 1 ticks */
gpmc,wr-data-mux-bus-ns = <30> /* 25 ns - 30 ns; 5 ticks */
gpmc,wr-access-ns = <90> /* 85 ns - 90 ns; 15 ticks */
omap2-onenand omap2-onenand: initializing on CS0, phys base 0x04000000, virtual base d0940000, freq 83 MHz
OneNAND Manufacturer: Numonyx (0x20)
Muxed OneNAND 256MB 1.8V 16-bit (0x40)
OneNAND version = 0x0031
Chip support all block unlock
Chip has 2 plane
Scanning device for bad blocks
6 ofpart partitions found on MTD device omap2-onenand
Creating 6 MTD partitions on "omap2-onenand":
0x000000000000-0x000000020000 : "bootloader"
0x000000020000-0x000000080000 : "config"
0x000000080000-0x0000000c0000 : "log"
mtdoops: ready 43, 6188 (no erase)
mtdoops: Attached to MTD device 2
0x0000000c0000-0x0000002c0000 : "kernel"
0x0000002c0000-0x0000004c0000 : "initfs"
0x0000004c0000-0x000010000000 : "rootfs"


From linux at arm.linux.org.uk  Tue Feb  2 16:03:51 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 3 Feb 2016 00:03:51 +0000
Subject: [PATCH 1/3] ARM: move .vectors and .stubs sections back into the
 kernel VMA
In-Reply-To: <1454419174-21290-2-git-send-email-ard.biesheuvel@linaro.org>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454419174-21290-2-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160203000351.GX10826@n2100.arm.linux.org.uk>

On Tue, Feb 02, 2016 at 02:19:32PM +0100, Ard Biesheuvel wrote:
> The sections themselves are emitted 4 KB apart, as required:
>   ...
>   [16] .stubs       PROGBITS   c0c35000 a35000 0002c0 00  AX  0   0 32
>   [17] .vectors     PROGBITS   c0c34000 a44000 000020 00  AX  0   0  2
>   ...

... which means we end up wasting most of a page for absolutely no
purpose what so ever.  Sorry, I'm really not happy about this
gratuitous wastage.

We changed to the existing solution to get rid of the VMA offset
to make the code easier to read, but if we're going to get rid of
that improvement, just revert the change.  (Check the kernel history.)

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From linux at arm.linux.org.uk  Tue Feb  2 16:05:06 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 3 Feb 2016 00:05:06 +0000
Subject: [PATCH 3/3] kallsyms: remove --page-offset command line option
In-Reply-To: <1454419174-21290-4-git-send-email-ard.biesheuvel@linaro.org>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454419174-21290-4-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160203000504.GY10826@n2100.arm.linux.org.uk>

On Tue, Feb 02, 2016 at 02:19:34PM +0100, Ard Biesheuvel wrote:
> The --page-offset command line option was only used for ARM, to filter
> symbol addresses below CONFIG_PAGE_OFFSET. This is no longer needed, so
> remove the functionality altogether.

>From what I remember, this option has nothing to do with MMU-ful ARM,
but noMMU ARM, where the .text segment can be significantly different
from the .data segment.

I think you need to talk to noMMU people about this patch.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From santosh.shilimkar at oracle.com  Tue Feb  2 16:09:42 2016
From: santosh.shilimkar at oracle.com (santosh shilimkar)
Date: Tue, 2 Feb 2016 16:09:42 -0800
Subject: [PATCH 1/2] ARM: make virt_to_idmap() return unsigned long
In-Reply-To: <56AF917F.9030505@oracle.com>
References: <E1aO8F2-00074N-E8@rmk-PC.arm.linux.org.uk>
 <56A84748.3040108@oracle.com> <20160201152015.GU10826@n2100.arm.linux.org.uk>
 <56AF8F54.7030805@ti.com> <56AF917F.9030505@oracle.com>
Message-ID: <56B14546.4070808@oracle.com>

Vitaly,

On 2/1/2016 9:10 AM, santosh shilimkar wrote:
> On 2/1/2016 9:01 AM, Vitaly Andrianov wrote:
>>
>>
>> On 02/01/2016 10:20 AM, Russell King - ARM Linux wrote:
>>> On Tue, Jan 26, 2016 at 08:27:52PM -0800, santosh.shilimkar at oracle.com
>>> wrote:
>>>> On 1/26/16 10:21 AM, Russell King wrote:
>>>>> Make virt_to_idmap() return an unsigned long rather than phys_addr_t.
>>>>>
>>>>> Returning phys_addr_t here makes no sense, because the definition of
>>>>> virt_to_idmap() is that it shall return a physical address which maps
>>>>> identically with the virtual address.  Since virtual addresses are
>>>>> limited to 32-bit, identity mapped physical addresses are as well.
>>>>>
>>>>> Almost all users already had an implicit narrowing cast to unsigned
>>>>> long
>>>>> so let's make this official and part of this interface.
>>>>>
>>>>> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
>>>>> ---
>>>> Looks correct to me.
>>>>
>>>> Vitaly,
>>>> Could you please try out this patch and see everything continue to
>>>> work ?
>>>
>>> I haven't heard anything yet...  Vitaly?
>>>
>> Russel, Santosh,
>>
>> I'm not working with the latest kernel, but with the stable v4.1.y. So I
>> couldn't apply the patch to it. I checked out 4.5.0-rc1 and applied the
>> patch to it. Tried to boot and it crashed. I'm not sure either because
>> of the patch or because of the network driver.
>>
> Thanks for checking.
>
>> Here is the log:
>>
> Based on the log, I think the patch seems to work fine since the boot
> reached upto rootfs. The crash seems to be coming from mostky NetCP
> related compents.
>
The NETCP crash you saw could be the same one others stumbled as
mentioned in below thread. You can try the fix and see if the
crash goes away.

http://marc.info/?l=linux-netdev&m=145445399232540&w=2





From julian.calaby at gmail.com  Tue Feb  2 16:19:52 2016
From: julian.calaby at gmail.com (Julian Calaby)
Date: Wed, 3 Feb 2016 11:19:52 +1100
Subject: [linux-sunxi] [PATCH 01/11] MAINTAINERS: Add entry for X-Powers
 AXP family PMIC drivers
In-Reply-To: <1454408864-24112-2-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-2-git-send-email-wens@csie.org>
Message-ID: <CAGRGNgVxan9RCsLFW9hHWcdW+Rd_SgVG95H-yQg213g-YeE6Ug@mail.gmail.com>

Hi Chen-Yu,

On Tue, Feb 2, 2016 at 9:27 PM, Chen-Yu Tsai <wens at csie.org> wrote:
> Add an entry for X-Powers AXP family PMIC drivers and list myself
> as maintainer.
>
> Cc: Carlo Caione <carlo at caione.org>
> Cc: Maxime Ripard <maxime.ripard at free-electrons.com>
> Cc: Ramakrishna Pallala <ramakrishna.pallala at intel.com>
> Cc: Todd Brandt <todd.e.brandt at linux.intel.com>
> Cc: Jacob Pan <jacob.jun.pan at linux.intel.com>
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
> ---
>  MAINTAINERS | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f678c37107f5..7ea4e54f566a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11941,6 +11941,12 @@ F:     include/linux/workqueue.h
>  F:     kernel/workqueue.c
>  F:     Documentation/workqueue.txt
>
> +X-POWERS MULTIFUNCTION PMIC DEVICE DRIVERS
> +M:     Chen-Yu Tsai <wens at csie.org>
> +L:     linux-kernel at vger.kernel.org
> +S:     Maintained
> +N:     axp[128]

Should you list the files maintained and this list also?

> +
>  X.25 NETWORK LAYER
>  M:     Andrew Hendry <andrew.hendry at gmail.com>
>  L:     linux-x25 at vger.kernel.org

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


From nicolas.pitre at linaro.org  Tue Feb  2 16:20:58 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 2 Feb 2016 19:20:58 -0500 (EST)
Subject: [PATCH 1/3] ARM: move .vectors and .stubs sections back into
 the kernel VMA
In-Reply-To: <20160203000351.GX10826@n2100.arm.linux.org.uk>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454419174-21290-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160203000351.GX10826@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.20.1602021918050.32766@knanqh.ubzr>

On Wed, 3 Feb 2016, Russell King - ARM Linux wrote:

> On Tue, Feb 02, 2016 at 02:19:32PM +0100, Ard Biesheuvel wrote:
> > The sections themselves are emitted 4 KB apart, as required:
> >   ...
> >   [16] .stubs       PROGBITS   c0c35000 a35000 0002c0 00  AX  0   0 32
> >   [17] .vectors     PROGBITS   c0c34000 a44000 000020 00  AX  0   0  2
> >   ...
> 
> ... which means we end up wasting most of a page for absolutely no
> purpose what so ever.  Sorry, I'm really not happy about this
> gratuitous wastage.

In practice this shouldn't make much of a difference given zImage is 
compressed and large zero filled areas compress very well.

But this is not nice for XIP though.


Nicolas


From linux at arm.linux.org.uk  Tue Feb  2 16:31:58 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 3 Feb 2016 00:31:58 +0000
Subject: [PATCH] ARM: vmlinux.lds: assert that ROM and RAM don't overlap
 when XIP_KERNEL=y
In-Reply-To: <1454346154-12931-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454346154-12931-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160203003158.GZ10826@n2100.arm.linux.org.uk>

On Mon, Feb 01, 2016 at 06:02:34PM +0100, Ard Biesheuvel wrote:
> When building an XIP kernel, the linker produces two disjoint VMA regions,
> where the first is mapped onto ROM and the second onto RAM. For this reason,
> the linker output pointer '.' is updated halfway through the linker script,
> and set to a value that corresponds with the start of the RAM region.
> 
> However, in some cases, the ROM region exceeds the expected size, and the
> assignment of the output pointer results in a decrement rather than an
> increment, causing the virtual addresses of the .data region to clash with
> the .text region. Such a kernel cannot boot normally, but it also confuses
> the hell out of kallsyms, since .data symbols may appear inside the
> [_stext, _etext] or [_sinittext, _einittext] intervals in the first pass,
> but not in the second (or vice versa), resulting in inconsistent kallsyms
> data.
> 
> So let's make sure that the output pointer only advances, and never jumps
> back into the ROM region.

The long term goal is to move the XIP stuff out of this file, so
I think it's better to avoid touching this until the split has
happened.

I'd _much_ rather see the split happen first, and then fixes
applied, rather than trying to fix the existing unmaintainable
mess.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From linux at arm.linux.org.uk  Tue Feb  2 16:41:54 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 3 Feb 2016 00:41:54 +0000
Subject: [PATCH] video: ARM CLCD: runtime check for Versatile
In-Reply-To: <25978729.oSoMp4ZgxA@wuerfel>
References: <1454446059-30526-1-git-send-email-linus.walleij@linaro.org>
 <25978729.oSoMp4ZgxA@wuerfel>
Message-ID: <20160203004154.GA10826@n2100.arm.linux.org.uk>

On Tue, Feb 02, 2016 at 10:10:49PM +0100, Arnd Bergmann wrote:
> On Tuesday 02 February 2016 21:47:39 Linus Walleij wrote:
> >         } else {
> > -#ifdef CONFIG_ARCH_VERSATILE
> > -               fb->off_ienb = CLCD_PL111_IENB;
> > -               fb->off_cntl = CLCD_PL111_CNTL;
> > -#else
> > -               fb->off_ienb = CLCD_PL110_IENB;
> > -               fb->off_cntl = CLCD_PL110_CNTL;
> > -#endif
> > +               if (of_machine_is_compatible("arm,versatile-ab") ||
> > +                   of_machine_is_compatible("arm,versatile-pb")) {
> > +                       fb->off_ienb = CLCD_PL111_IENB;
> > +                       fb->off_cntl = CLCD_PL111_CNTL;
> > +               } else {
> > +                       fb->off_ienb = CLCD_PL110_IENB;
> > +                       fb->off_cntl = CLCD_PL110_CNTL;
> > +               }
> >         }
> > 
> 
> Could that be done based on the AMBA device ID instead?

Unfortunately not.  It's a mistake made on one Versatile board
which reverses the registers.  There's nothing to distinguish it
in the primecell itself.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From khilman at baylibre.com  Tue Feb  2 16:42:20 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Tue, 02 Feb 2016 16:42:20 -0800
Subject: [PATCH v4 00/13] arm64: kernel: Add support for
 hibernate/suspend-to-disk
In-Reply-To: <56AF1D07.3000604@arm.com> (James Morse's message of "Mon, 01 Feb
 2016 08:53:27 +0000")
References: <1453977766-20907-1-git-send-email-james.morse@arm.com>
 <7hvb6chv5e.fsf@baylibre.com> <56AF1D07.3000604@arm.com>
Message-ID: <7hmvrid3pv.fsf@baylibre.com>

James Morse <james.morse at arm.com> writes:

> On 29/01/16 22:34, Kevin Hilman wrote:
>> James Morse <james.morse at arm.com> writes:
>> I'd like to help in testing this so I'm just curious which platforms
>> you've been testing this on.  I'm assuming a Juno (r2?), anything else?
>
> That would be great - thanks!
>
> I've done most of the testing on a Juno r1, but also gave it a spin on a
> stray Seattle.

OK, I'm using a very recently arrived Juno R2, and I did get it
working.  I have a few other arm64 boards around that ar part of
kernelci.org and will try those as well.

>> Are you testing the resume from cold boot, or just from kexec?
>
> From cold boot. I haven't tried with kexec, but I doubt that's a use-case anyone
> wants as you would resume immediately. (might be interesting for testing though)
>
>
>> For cold boot on Juno, I'm assuming there would be some
>> booloader/firmware changes needed to find and boot from the hibernation
>> image?
>
> Not at all! Your firmware only needs to support some mechanism to
> turning CPUs off.
>
> If you add 'resume=/dev/sda2' (or wherever your swap partition is located), the
> kernel will check this partition for the hibernate-image signature, if found, it
> will resume from that partition. Otherwise booting is as normal. (there is one
> hoop to jump through to ensure your rootfs hasn't been mounted before the kernel
> starts resume, as you could corrupt it - an initramfs in the kernel is the best
> fix for this).
>
> No firmware changes needed.
>
>> Is that being worked on?  If not Juno, are you aware of any
>> other platforms that could be tested with resume from cold boot?
>
> Any arm64 platform with persistent storage should work. I've been using a swap
> partition on a usb drive.

>> Not knowing the answers to the above, I tested your branch using arm64
>> defconfig + CONFIG_HIBERNATION=y on my Juno and noticed that it didn't
>> stay suspended (full suspend log below) so I'm looking for
>> ideas/recommenations on how to test this.
>
> That trace looks quite normal, (one of mine below[0] for comparison). Any
> failure would have happened after the point you stopped ... did you have a swap
> partition 'on'?

I think I must have not setup swap correctly since after testing again
it's working fine.  Maybe I forgot the 'swapon'?  In any case, being a
little more careful, testing again and things are working fine on Juno.

I'm also using swap on USB storage for now.

> 'syscore' will freeze all processes and stop all devices, then create a
> copy of the minimum amount of memory it needs to save. Then it starts
> all the devices again, as it needs to write this image out to swap. This is what
> you are seeing.
>
> Once it has done this it calls poweroff or reboot.

Yeah, I wasn't seeing the call to poweroff, but most likely because it
was failing to fully write the image due to my missing/incorrect swap
setup.

Thanks for the help,

Kevin


From stefan at agner.ch  Tue Feb  2 17:00:23 2016
From: stefan at agner.ch (Stefan Agner)
Date: Tue, 02 Feb 2016 17:00:23 -0800
Subject: [PATCH v2 0/4] ARM: dts: vf610: relicense the device trees under
 GPLv2/X11
In-Reply-To: <1449525076-23569-1-git-send-email-stefan@agner.ch>
References: <1449525076-23569-1-git-send-email-stefan@agner.ch>
Message-ID: <5311c9f5234f774dc34118a564f48a4c@agner.ch>

Hi Shawn,

For patches 1, 2 and 4 I think we have enough Acks to consider it safe
to change the license.

For Patch 3, the Cosmic board, I can not get an Ack nor a Nack from Matt
Porter, unfortunately... But IMHO it should not hold us back from
merging the rest, what do you think?

--
Stefan

On 2015-12-07 13:51, Stefan Agner wrote:
> I collected the Acks I received so far and removed them from the list
> below. Several Freescale addresses are no longer valid (the once
> starting with --)... I would interprete the Ack from Yuan Yao as an
> Ack from Freescale.
> 
> Matt, you introduced the vf610-cosmic.dts board, is it possible to
> get an ack for this too? I think you did not receive v1 of this patch
> due to an old email address, sorry about that.
> 
> vf???.dtsi:
>   --Chao Fu <B44548 at freescale.com>
>   Cosmin Stoica <cosminstefan.stoica at freescale.com>
>   Frank Li <Frank.Li at freescale.com>
>   --Fugang Duan <B38611 at freescale.com>
>   --Huang Shijie <b32955 at freescale.com>
>   --Jingchang Lu <jingchang.lu at freescale.com>
>   --Xiubo Li <Li.Xiubo at freescale.com>
> 
> vf610-colibri:
>   <all done>
> 
> vf610-cosmic:
>   Matt Porter <mporter at kernel.crashing.org>
> 
> vf610-twr:
>   --Chao Fu <B44548 at freescale.com>
>   Cosmin Stoica <cosminstefan.stoica at freescale.com>
>   --Fugang Duan <B38611 at freescale.com>
>   --Jingchang Lu <b35083 at freescale.com>
>   --Xiubo Li <Li.Xiubo at freescale.com>
> 
> CC: Bhuvanchandra DV <bhuvanchandra.dv at toradex.com>
> CC: Bill Pringlemeir <bpringle at sympatico.ca>
> --CC: Chao Fu <B44548 at freescale.com>
> CC: Cory Tusar <cory.tusar at pid1solutions.com>
> CC: Cosmin Stoica <cosminstefan.stoica at freescale.com>
> CC: Frank Li <Frank.Li at freescale.com>
> --CC: Fugang Duan <B38611 at freescale.com>
> --CC: Huang Shijie <b32955 at freescale.com>
> --CC: Jingchang Lu <jingchang.lu at freescale.com>
> CC: Lucas Stach <l.stach at pengutronix.de>
> CC: Matt Porter <mporter at kernel.crashing.org>
> CC: Olof Johansson <olof at lixom.net>
> CC: Sanchayan Maity <maitysanchayan at gmail.com>
> CC: Shawn Guo <shawnguo at kernel.org>
> CC: Stephen Warren <swarren at wwwdotorg.org>
> --CC: Xiubo Li <Li.Xiubo at freescale.com>
> CC: Yuan Yao <yao.yuan at freescale.com>
> 
> Stefan Agner (4):
>   ARM: dts: vf610: relicense vf???.dtsi under GPLv2/X11
>   ARM: dts: vf610-colibri: relicense vf*colibri* under GPLv2/X11
>   ARM: dts: vf610-cosmic: relicense vf610-cosmic.dts under GPLv2/X11
>   ARM: dts: vf610-twr: relicense vf610-twr.dts under GPLv2/X11
> 
>  arch/arm/boot/dts/vf-colibri-eval-v3.dtsi   | 40 ++++++++++++++++++++++++---
>  arch/arm/boot/dts/vf-colibri.dtsi           | 40 ++++++++++++++++++++++++---
>  arch/arm/boot/dts/vf500-colibri-eval-v3.dts | 40 ++++++++++++++++++++++++---
>  arch/arm/boot/dts/vf500-colibri.dtsi        | 40 ++++++++++++++++++++++++---
>  arch/arm/boot/dts/vf500.dtsi                | 40 ++++++++++++++++++++++++---
>  arch/arm/boot/dts/vf610-colibri-eval-v3.dts | 42 +++++++++++++++++++++++++----
>  arch/arm/boot/dts/vf610-colibri.dtsi        | 40 ++++++++++++++++++++++++---
>  arch/arm/boot/dts/vf610-cosmic.dts          | 40 ++++++++++++++++++++++++---
>  arch/arm/boot/dts/vf610-twr.dts             | 40 ++++++++++++++++++++++++---
>  arch/arm/boot/dts/vf610.dtsi                | 40 ++++++++++++++++++++++++---
>  arch/arm/boot/dts/vfxxx.dtsi                | 40 ++++++++++++++++++++++++---
>  11 files changed, 397 insertions(+), 45 deletions(-)


From sboyd at codeaurora.org  Tue Feb  2 17:22:00 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue,  2 Feb 2016 17:22:00 -0800
Subject: [PATCH] clk: gpio: Make into a platform driver
Message-ID: <1454462520-20787-1-git-send-email-sboyd@codeaurora.org>

clk_get() for DT based clks already returns EPROBE_DEFER when the
OF clk provider is not present. So having all this code in the
clk provider to return EPROBE_DEFER when the gpio isn't ready yet
can be replaced with a platform driver that doesn't add the clk
provider until the gpio can be requested. Get rid of the
OF_CLK_DECLARE and convert this to a platform driver instead.

Cc: Jyri Sarha <jsarha at ti.com>
Cc: Sergej Sawazki <ce3a at gmx.de>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
Cc: Fabio Estevam <fabio.estevam at freescale.com>
Cc: Jon Nettleton <jon at solid-run.com>
Cc: Shawn Guo <shawn.guo at linaro.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clk-gpio.c | 168 ++++++++++++++++---------------------------------
 1 file changed, 54 insertions(+), 114 deletions(-)

diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index cbbea2985cc9..7252ea7dfe0d 100644
--- a/drivers/clk/clk-gpio.c
+++ b/drivers/clk/clk-gpio.c
@@ -20,6 +20,8 @@
 #include <linux/of_gpio.h>
 #include <linux/err.h>
 #include <linux/device.h>
+#include <linux/platform_device.h>
+#include <linux/of_device.h>
 
 /**
  * DOC: basic gpio gated clock which can be enabled and disabled
@@ -199,134 +201,72 @@ struct clk *clk_register_gpio_mux(struct device *dev, const char *name,
 }
 EXPORT_SYMBOL_GPL(clk_register_gpio_mux);
 
-#ifdef CONFIG_OF
-/**
- * clk_register_get() has to be delayed, because -EPROBE_DEFER
- * can not be handled properly at of_clk_init() call time.
- */
-
-struct clk_gpio_delayed_register_data {
-	const char *gpio_name;
-	int num_parents;
-	const char **parent_names;
-	struct device_node *node;
-	struct mutex lock;
-	struct clk *clk;
-	struct clk *(*clk_register_get)(const char *name,
-			const char * const *parent_names, u8 num_parents,
-			unsigned gpio, bool active_low);
-};
-
-static struct clk *of_clk_gpio_delayed_register_get(
-		struct of_phandle_args *clkspec, void *_data)
+static int gpio_clk_driver_probe(struct platform_device *pdev)
 {
-	struct clk_gpio_delayed_register_data *data = _data;
-	struct clk *clk;
-	int gpio;
+	struct device_node *node = pdev->dev.of_node;
+	const char **parent_names, *gpio_name;
+	int num_parents, gpio;
 	enum of_gpio_flags of_flags;
+	struct clk *clk;
+	bool active_low, is_mux;
+
+	num_parents = of_clk_get_parent_count(node);
+	if (num_parents < 0)
+		return -EINVAL;
 
-	mutex_lock(&data->lock);
+	if (num_parents) {
+		parent_names = devm_kcalloc(&pdev->dev, num_parents,
+					    sizeof(char *), GFP_KERNEL);
+		if (!parent_names)
+			return -ENOMEM;
 
-	if (data->clk) {
-		mutex_unlock(&data->lock);
-		return data->clk;
+		of_clk_parent_fill(node, parent_names, num_parents);
+	} else {
+		parent_names = NULL;
 	}
 
-	gpio = of_get_named_gpio_flags(data->node, data->gpio_name, 0,
-			&of_flags);
+	is_mux = of_device_is_compatible(node, "gpio-mux-clock");
+
+	gpio_name = is_mux ? "select-gpios" : "enable-gpios";
+	gpio = of_get_named_gpio_flags(node, gpio_name, 0, &of_flags);
 	if (gpio < 0) {
-		mutex_unlock(&data->lock);
 		if (gpio == -EPROBE_DEFER)
 			pr_debug("%s: %s: GPIOs not yet available, retry later\n",
-					data->node->name, __func__);
+					node->name, __func__);
 		else
 			pr_err("%s: %s: Can't get '%s' DT property\n",
-					data->node->name, __func__,
-					data->gpio_name);
-		return ERR_PTR(gpio);
+					node->name, __func__,
+					gpio_name);
+		return gpio;
 	}
 
-	clk = data->clk_register_get(data->node->name, data->parent_names,
-			data->num_parents, gpio, of_flags & OF_GPIO_ACTIVE_LOW);
-	if (IS_ERR(clk))
-		goto out;
-
-	data->clk = clk;
-out:
-	mutex_unlock(&data->lock);
-
-	return clk;
-}
-
-static struct clk *of_clk_gpio_gate_delayed_register_get(const char *name,
-		const char * const *parent_names, u8 num_parents,
-		unsigned gpio, bool active_low)
-{
-	return clk_register_gpio_gate(NULL, name, parent_names ?
-			parent_names[0] : NULL, gpio, active_low, 0);
-}
+	active_low = of_flags & OF_GPIO_ACTIVE_LOW;
 
-static struct clk *of_clk_gpio_mux_delayed_register_get(const char *name,
-		const char * const *parent_names, u8 num_parents, unsigned gpio,
-		bool active_low)
-{
-	return clk_register_gpio_mux(NULL, name, parent_names, num_parents,
-			gpio, active_low, 0);
-}
-
-static void __init of_gpio_clk_setup(struct device_node *node,
-		const char *gpio_name,
-		struct clk *(*clk_register_get)(const char *name,
-				const char * const *parent_names,
-				u8 num_parents,
-				unsigned gpio, bool active_low))
-{
-	struct clk_gpio_delayed_register_data *data;
-	const char **parent_names;
-	int i, num_parents;
-
-	num_parents = of_clk_get_parent_count(node);
-	if (num_parents < 0)
-		return;
-
-	data = kzalloc(sizeof(*data), GFP_KERNEL);
-	if (!data)
-		return;
-
-	if (num_parents) {
-		parent_names = kcalloc(num_parents, sizeof(char *), GFP_KERNEL);
-		if (!parent_names) {
-			kfree(data);
-			return;
-		}
-
-		for (i = 0; i < num_parents; i++)
-			parent_names[i] = of_clk_get_parent_name(node, i);
-	} else {
-		parent_names = NULL;
-	}
-
-	data->num_parents = num_parents;
-	data->parent_names = parent_names;
-	data->node = node;
-	data->gpio_name = gpio_name;
-	data->clk_register_get = clk_register_get;
-	mutex_init(&data->lock);
+	if (is_mux)
+		clk = clk_register_gpio_mux(&pdev->dev, node->name,
+				parent_names, num_parents, gpio, active_low, 0);
+	else
+		clk = clk_register_gpio_gate(&pdev->dev, node->name,
+				parent_names ?  parent_names[0] : NULL, gpio,
+				active_low, 0);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
 
-	of_clk_add_provider(node, of_clk_gpio_delayed_register_get, data);
+	return of_clk_add_provider(node, of_clk_src_simple_get, clk);
 }
 
-static void __init of_gpio_gate_clk_setup(struct device_node *node)
-{
-	of_gpio_clk_setup(node, "enable-gpios",
-		of_clk_gpio_gate_delayed_register_get);
-}
-CLK_OF_DECLARE(gpio_gate_clk, "gpio-gate-clock", of_gpio_gate_clk_setup);
-
-void __init of_gpio_mux_clk_setup(struct device_node *node)
-{
-	of_gpio_clk_setup(node, "select-gpios",
-		of_clk_gpio_mux_delayed_register_get);
-}
-CLK_OF_DECLARE(gpio_mux_clk, "gpio-mux-clock", of_gpio_mux_clk_setup);
-#endif
+static const struct of_device_id gpio_clk_match_table[] = {
+	{ .compatible = "gpio-mux-clock" },
+	{ .compatible = "gpio-gate-clock" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, gpio_clk_match_table);
+
+static struct platform_driver gpio_clk_driver = {
+	.probe		= gpio_clk_driver_probe,
+	.driver		= {
+		.name	= "gpio-clk",
+		.of_match_table = gpio_clk_match_table,
+	},
+};
+builtin_platform_driver(gpio_clk_driver);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From joe at perches.com  Tue Feb  2 17:28:30 2016
From: joe at perches.com (Joe Perches)
Date: Tue, 02 Feb 2016 17:28:30 -0800
Subject: [linux-sunxi] [PATCH 01/11] MAINTAINERS: Add entry for X-Powers
 AXP family PMIC drivers
In-Reply-To: <CAGRGNgVxan9RCsLFW9hHWcdW+Rd_SgVG95H-yQg213g-YeE6Ug@mail.gmail.com>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-2-git-send-email-wens@csie.org>
 <CAGRGNgVxan9RCsLFW9hHWcdW+Rd_SgVG95H-yQg213g-YeE6Ug@mail.gmail.com>
Message-ID: <1454462910.7291.53.camel@perches.com>

On Wed, 2016-02-03 at 11:19 +1100, Julian Calaby wrote:
> On Tue, Feb 2, 2016 at 9:27 PM, Chen-Yu Tsai <wens at csie.org> wrote:
> > Add an entry for X-Powers AXP family PMIC drivers and list myself
> > as maintainer.
[]
> > diff --git a/MAINTAINERS b/MAINTAINERS
[]
> > @@ -11941,6 +11941,12 @@ F:?????include/linux/workqueue.h
> > ?F:?????kernel/workqueue.c
> > ?F:?????Documentation/workqueue.txt
> > 
> > +X-POWERS MULTIFUNCTION PMIC DEVICE DRIVERS
> > +M:?????Chen-Yu Tsai <wens at csie.org>
> > +L:?????linux-kernel at vger.kernel.org
> > +S:?????Maintained
> > +N:?????axp[128]
> 
> Should you list the files maintained and this list also?

This "N:" pattern is kind of a wildcard.

The difference between F: and N: is that git history
is also used by default for files that match.

There are no files in -next today that match "*axp8*"
Dunno if this patchset added any.

This matches:

    $ git ls-files | grep "axp[128]"
    Documentation/devicetree/bindings/mfd/axp20x.txt
    Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt
    arch/arm/boot/dts/axp152.dtsi
    arch/arm/boot/dts/axp209.dtsi
    arch/arm/boot/dts/axp22x.dtsi
    drivers/extcon/extcon-axp288.c
    drivers/iio/adc/axp288_adc.c
    drivers/input/misc/axp20x-pek.c
    drivers/mfd/axp20x.c
    drivers/power/axp20x_usb_power.c
    drivers/power/axp288_charger.c
    drivers/power/axp288_fuel_gauge.c
    drivers/regulator/axp20x-regulator.c
    include/linux/mfd/axp20x.h

Are all these files appropriate?



From julian.calaby at gmail.com  Tue Feb  2 17:30:36 2016
From: julian.calaby at gmail.com (Julian Calaby)
Date: Wed, 3 Feb 2016 12:30:36 +1100
Subject: [linux-sunxi] [PATCH 01/11] MAINTAINERS: Add entry for X-Powers
 AXP family PMIC drivers
In-Reply-To: <1454462910.7291.53.camel@perches.com>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-2-git-send-email-wens@csie.org>
 <CAGRGNgVxan9RCsLFW9hHWcdW+Rd_SgVG95H-yQg213g-YeE6Ug@mail.gmail.com>
 <1454462910.7291.53.camel@perches.com>
Message-ID: <CAGRGNgXf-dvWWmyRMjgbVdnprg+fzDhbMeX7-6nZ-+LQ1J+ghA@mail.gmail.com>

Hi Joe,

On Wed, Feb 3, 2016 at 12:28 PM, Joe Perches <joe at perches.com> wrote:
> On Wed, 2016-02-03 at 11:19 +1100, Julian Calaby wrote:
>> On Tue, Feb 2, 2016 at 9:27 PM, Chen-Yu Tsai <wens at csie.org> wrote:
>> > Add an entry for X-Powers AXP family PMIC drivers and list myself
>> > as maintainer.
> []
>> > diff --git a/MAINTAINERS b/MAINTAINERS
> []
>> > @@ -11941,6 +11941,12 @@ F:     include/linux/workqueue.h
>> >  F:     kernel/workqueue.c
>> >  F:     Documentation/workqueue.txt
>> >
>> > +X-POWERS MULTIFUNCTION PMIC DEVICE DRIVERS
>> > +M:     Chen-Yu Tsai <wens at csie.org>
>> > +L:     linux-kernel at vger.kernel.org
>> > +S:     Maintained
>> > +N:     axp[128]
>>
>> Should you list the files maintained and this list also?
>
> This "N:" pattern is kind of a wildcard.
>
> The difference between F: and N: is that git history
> is also used by default for files that match.
>
> There are no files in -next today that match "*axp8*"
> Dunno if this patchset added any.
>
> This matches:
>
>     $ git ls-files | grep "axp[128]"
>     Documentation/devicetree/bindings/mfd/axp20x.txt
>     Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt
>     arch/arm/boot/dts/axp152.dtsi
>     arch/arm/boot/dts/axp209.dtsi
>     arch/arm/boot/dts/axp22x.dtsi
>     drivers/extcon/extcon-axp288.c
>     drivers/iio/adc/axp288_adc.c
>     drivers/input/misc/axp20x-pek.c
>     drivers/mfd/axp20x.c
>     drivers/power/axp20x_usb_power.c
>     drivers/power/axp288_charger.c
>     drivers/power/axp288_fuel_gauge.c
>     drivers/regulator/axp20x-regulator.c
>     include/linux/mfd/axp20x.h
>
> Are all these files appropriate?
>

I didn't know about the "N:" tag, and consequently I retract my comment.

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


From k.kozlowski at samsung.com  Tue Feb  2 17:33:33 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 03 Feb 2016 10:33:33 +0900
Subject: [PATCH RESEND RFC] mach:-s3c64xx:Output trace information with
 WARN_ON if calls for setting up gpio board configuration fail in
 s3c64xx_i2s_cfg_gpio
In-Reply-To: <1454424992-14619-1-git-send-email-xerofoify@gmail.com>
References: <1454424992-14619-1-git-send-email-xerofoify@gmail.com>
Message-ID: <56B158ED.8090109@samsung.com>

On 02.02.2016 23:56, Nicholas Krause wrote:
> This fixes the function s3c64xx_i2c_cfg_gpio to log output to the
> kernel log buff with WARN_ON if any of the calls to either
> s3c_gpio_cfgpin_range or s3c_gpio_cfgpin fail as we cannot exit
> from s3c64xx_i2s_cfg_gpio if any of these calls fail due to
> other intended function work being required to complete. Further more
> if a failure occurs allow the other users/devolopers of this driver
> to properly check the kernel log buffers for a kernel trace for
> when these calls failing to execute successfully arise.

Quite complicated sentences, very difficult to understand. The commit
message should describe the logic behind the change (e.g. answer to
why?) and user-visible impact in a brief and understandable way.

Commit subject does not match subsystem and it is over complicated on
its own. It is also too long. Your editor should point this already (70
chars at most).

Anyway I don't feel the patch is needed and description fails to
convince me. Knowing your history, you did not encounter any errors here
but instead you are just spreading random "fixes" which compile or not...

Since this was not tested:
If it ain't broken, don't fix it.

Best regards,
Krzysztof

> 
> Signed-off-by: Nicholas Krause <xerofoify at gmail.com>
> ---
> v3:Fix more wording issues and uncaught build failure with
> previous build test
> v2:Fix Patch Wording as it was clearly confusing and incorrect
>  arch/arm/mach-s3c64xx/dev-audio.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-s3c64xx/dev-audio.c b/arch/arm/mach-s3c64xx/dev-audio.c
> index ff780a8..796ac75 100644
> --- a/arch/arm/mach-s3c64xx/dev-audio.c
> +++ b/arch/arm/mach-s3c64xx/dev-audio.c
> @@ -36,10 +36,10 @@ static int s3c64xx_i2s_cfg_gpio(struct platform_device *pdev)
>  		base = S3C64XX_GPE(0);
>  		break;
>  	case 2:
> -		s3c_gpio_cfgpin(S3C64XX_GPC(4), S3C_GPIO_SFN(5));
> -		s3c_gpio_cfgpin(S3C64XX_GPC(5), S3C_GPIO_SFN(5));
> -		s3c_gpio_cfgpin(S3C64XX_GPC(7), S3C_GPIO_SFN(5));
> -		s3c_gpio_cfgpin_range(S3C64XX_GPH(6), 4, S3C_GPIO_SFN(5));
> +		WARN_ON(s3c_gpio_cfgpin(S3C64XX_GPC(4), S3C_GPIO_SFN(5)));
> +		WARN_ON(s3c_gpio_cfgpin(S3C64XX_GPC(5), S3C_GPIO_SFN(5)));
> +		WARN_ON(s3c_gpio_cfgpin(S3C64XX_GPC(7), S3C_GPIO_SFN(5)));
> +		WARN_ON(s3c_gpio_cfgpin_range(S3C64XX_GPH(6), 4, S3C_GPIO_SFN(5)));
>  		return 0;
>  	default:
>  		printk(KERN_DEBUG "Invalid I2S Controller number: %d\n",
> @@ -47,7 +47,7 @@ static int s3c64xx_i2s_cfg_gpio(struct platform_device *pdev)
>  		return -EINVAL;
>  	}
>  
> -	s3c_gpio_cfgpin_range(base, 5, S3C_GPIO_SFN(3));
> +	WARN_ON(s3c_gpio_cfgpin_range(base, 5, S3C_GPIO_SFN(3)));
>  
>  	return 0;
>  }
> 



From eric at anholt.net  Tue Feb  2 17:34:19 2016
From: eric at anholt.net (Eric Anholt)
Date: Tue, 02 Feb 2016 17:34:19 -0800
Subject: [PATCH V3 1/4] ARM: bcm2835: follow dt uart node-naming convention
In-Reply-To: <1453032932-2512-2-git-send-email-kernel@martin.sperl.org>
References: <1453032932-2512-1-git-send-email-kernel@martin.sperl.org>
 <1453032932-2512-2-git-send-email-kernel@martin.sperl.org>
Message-ID: <871t8ur2zo.fsf@eliezer.anholt.net>

kernel at martin.sperl.org writes:

> From: Martin Sperl <kernel at martin.sperl.org>
>
> This patch fixes the naming of the device tree node: uart at 7e201000
> to conform to the standard of: serial at 7e201000
>
> Signed-off-by: Martin Sperl <kernel at martin.sperl.org>

Did the rebase and merged this one to bcm2835-dt-next.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160202/210a2996/attachment.sig>

From fan.chen at mediatek.com  Tue Feb  2 17:38:18 2016
From: fan.chen at mediatek.com (Fan Chen)
Date: Wed, 3 Feb 2016 09:38:18 +0800
Subject: MTK mt8173-evb: mainline unstable, and big-endian boot failures
In-Reply-To: <7h37tbdk6y.fsf@baylibre.com>
References: <CAOi56cVDbkAJEDWy3+DV63a=UuD7nqpUu8X7e-OjtWM-4dj_-w@mail.gmail.com>
 <7hsi1ilczm.fsf@baylibre.com>
 <CAF-23O3ps0Wt_UCmJbArpc5iJJryJKA0k_2qAyNb7op8O=UnAg@mail.gmail.com>
 <1453964180.26397.8.camel@mtksdaap41> <7hy4b8gc7q.fsf@baylibre.com>
 <1454309376.11974.3.camel@mtksdaap41> <7hh9hrgbbh.fsf@baylibre.com>
 <1454379462.27798.11.camel@mtksdaap41> <7h37tbdk6y.fsf@baylibre.com>
Message-ID: <1454463498.27798.24.camel@mtksdaap41>

Hi Kevin,

On Tue, 2016-02-02 at 10:46 -0800, Kevin Hilman wrote:
> Hi Fan,
> 
> Fan Chen <fan.chen at mediatek.com> writes:
> 
> > I just checked that the problem cannot be reproduced (tested 100 times
> > with your script) after flashing new firmware which we uploaded to
> > github[0] yesterday.
> 
> Great news!
> 
> > This latest firmware got many fixes and also supports cluster idle, so
> > we prefer testing with this new one Would you please test in your
> > side? Thanks for your great help!!
> 
> I tested the latest firmware and it's booted 20+ times in a row without
> failure, which is better than it ever did in the past, so it seems to
> have fixed the idle problem.
> 
> I will keep an eye on the failures in kernelci.org and let you know if I
> notice any other failures.
> 
> Thanks again for the updated firmware!
> 
Thanks to keep notice us failures as well.

> Speaking of updated firmware, is there any chance to make the default
> version of the firmware significantly less noisy.  There is a TON of
> output from the firmware before fastboot starts which makes the logs for
> this board very noisy (same complaint on the mt8135.)
> 
I will discuss with Eddie if it's possible to release a version with
light logs, but I'm afraid the answer could be given after our Chinese
New Year vacation. :P
 

> Kevin
> 

Fan



From sboyd at codeaurora.org  Tue Feb  2 17:42:13 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue,  2 Feb 2016 17:42:13 -0800
Subject: [PATCH] clk: Deprecate CLK_IS_ROOT
Message-ID: <1454463733-25281-1-git-send-email-sboyd@codeaurora.org>

We don't use CLK_IS_ROOT but in a few places in the common clk
framework core. Let's replace those checks with a check for the
number of parents a clk has instead of the flag, freeing up one
flag for something else. We don't remove the flag yet so that
things keep building, but we'll remove it once all drivers have
removed their flag usage.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---

A bunch of patches to remove CLK_IS_ROOT are coming...

 drivers/clk/clk.c            | 6 +++---
 include/linux/clk-provider.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index bb01ed6cc63e..cd8382c83f48 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -385,7 +385,7 @@ static unsigned long clk_core_get_rate_nolock(struct clk_core *core)
 
 	ret = core->rate;
 
-	if (core->flags & CLK_IS_ROOT)
+	if (!core->num_parents)
 		goto out;
 
 	if (!core->parent)
@@ -2351,7 +2351,7 @@ static int __clk_core_init(struct clk_core *core)
 	/*
 	 * Populate core->parent if parent has already been __clk_init'd.  If
 	 * parent has not yet been __clk_init'd then place clk in the orphan
-	 * list.  If clk has set the CLK_IS_ROOT flag then place it in the root
+	 * list.  If clk doesn't have any parents then place it in the root
 	 * clk list.
 	 *
 	 * Every time a new clk is clk_init'd then we walk the list of orphan
@@ -2362,7 +2362,7 @@ static int __clk_core_init(struct clk_core *core)
 		hlist_add_head(&core->child_node,
 				&core->parent->children);
 		core->orphan = core->parent->orphan;
-	} else if (core->flags & CLK_IS_ROOT) {
+	} else if (!core->num_parents) {
 		hlist_add_head(&core->child_node, &clk_root_list);
 		core->orphan = false;
 	} else {
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index fabe5bedbba6..9c3a18c1a984 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -25,7 +25,7 @@
 #define CLK_SET_PARENT_GATE	BIT(1) /* must be gated across re-parent */
 #define CLK_SET_RATE_PARENT	BIT(2) /* propagate rate change up one level */
 #define CLK_IGNORE_UNUSED	BIT(3) /* do not gate even if unused */
-#define CLK_IS_ROOT		BIT(4) /* root clk, has no parent */
+#define CLK_IS_ROOT		BIT(4) /* Deprecated: Don't use */
 #define CLK_IS_BASIC		BIT(5) /* Basic clk, can't do a to_clk_foo() */
 #define CLK_GET_RATE_NOCACHE	BIT(6) /* do not use the cached clk rate */
 #define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate change */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From pi-cheng.chen at linaro.org  Tue Feb  2 17:46:25 2016
From: pi-cheng.chen at linaro.org (Pi-Cheng Chen)
Date: Wed, 3 Feb 2016 09:46:25 +0800
Subject: [PATCH v2 3/3] ARM64: dts: mt8173: Add CPU OPP, clock and
 regulator supply properties
In-Reply-To: <56B0B894.9040706@gmail.com>
References: <1451197318-12418-1-git-send-email-pi-cheng.chen@linaro.org>
 <1451197318-12418-4-git-send-email-pi-cheng.chen@linaro.org>
 <20151228031340.GD3598@ubuntu> <3310024.mO5K6yH9vU@wuerfel>
 <20160105102455.GA30120@ubuntu> <56B08DA4.8070207@gmail.com>
 <56B0B894.9040706@gmail.com>
Message-ID: <CALx668UB+o_RYUWSR86nUL7YpiK9fWPzZeOSaOmYTGtdnRKx=Q@mail.gmail.com>

On Tue, Feb 2, 2016 at 10:09 PM, Matthias Brugger
<matthias.bgg at gmail.com> wrote:
>
>
> On 02/02/16 12:06, Matthias Brugger wrote:
>>
>>
>>
>> On 05/01/16 11:24, Viresh Kumar wrote:
>>>
>>> On 05-01-16, 11:21, Arnd Bergmann wrote:
>>>>
>>>> On Monday 28 December 2015 08:43:40 Viresh Kumar wrote:
>>>>>
>>>>> On 27-12-15, 14:21, Pi-Cheng Chen wrote:
>>>>>>
>>>>>> Add operating-points-v2, clock, and regulator supply properties
>>>>>> required by mt8173-cpufreq driver to enable it.
>>>>>>
>>>>>> Signed-off-by: Pi-Cheng Chen <pi-cheng.chen at linaro.org>
>>>>>> ---
>>>>>> This patch is based on the patch[1] that adds underlying clock MUX for
>>>>>> MT8173 which is needed by mt8173-cpufreq driver but not yet picked.
>>>>>>
>>>>>> [1] http://article.gmane.org/gmane.linux.kernel.clk/325
>>>>>> ---
>>>>>>   arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 ++++++
>>>>>>   arch/arm64/boot/dts/mediatek/mt8173.dtsi    | 90
>>>>>> +++++++++++++++++++++++++++++
>>>>>>   2 files changed, 108 insertions(+)
>>>>>
>>>>>
>>>>> Acked-by: Viresh Kumar <viresh.kumar at linaro.org>
>>>>>
>>>>
>>>> This patch is now in linux-next through Rafael's pm tree, and it
>>>> breaks the
>>>> arm64 build:
>>>>
>>>>          arm64-defconfig
>>>> Error: ../arch/arm64/boot/dts/mediatek/mt8173.dtsi:132.24-25 syntax
>>>> error
>>>>
>>>>
>>>> Please revert.
>>>>
>>>> In the future, please send all dts changes through the proper maintainer
>>>> channels (-> Mattias -> arm-soc), and make sure they actually build.
>>>
>>>
>>> Rafael has already reverted that, AFAIK, after Mark Brown reported the
>>> build issue.
>>>
>>
>> Applied to v4.5-next/dts
>>
>
> I oversaw that this needs a clock patch, which is not yet mainlined.
> I deleted this patch from my tree.

I should mention that explicitly.
Sorry for the inconvenience.

Pi-Cheng


From shawn.lin at rock-chips.com  Tue Feb  2 18:07:50 2016
From: shawn.lin at rock-chips.com (Shawn Lin)
Date: Wed, 3 Feb 2016 10:07:50 +0800
Subject: [PATCH v3 4/4] ARM64: dts: rockchip: add syscon-reboot-mode DT
 node
In-Reply-To: <1454407999-5476-1-git-send-email-andy.yan@rock-chips.com>
References: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
 <1454407999-5476-1-git-send-email-andy.yan@rock-chips.com>
Message-ID: <56B160F6.20308@rock-chips.com>

On 2016/2/2 18:13, Andy Yan wrote:
> Add syscon-reboot-mode driver DT node for rk3368 platform
>
> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
>

Work fine with my rk3368-sheep board :)

Tested-by: Shawn Lin <shawn.lin at rock-chips.com>

> ---
>
> Changes in v3:
> - descirbe all reboot mode as property instead of subnode
>
> Changes in v2:
> - make this node as a subnode of pmugrf
>
> Changes in v1: None
>
>   arch/arm64/boot/dts/rockchip/rk3368.dtsi | 14 +++++++++++++-
>   1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> index 122777b..5213713 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> @@ -45,6 +45,7 @@
>   #include <dt-bindings/interrupt-controller/irq.h>
>   #include <dt-bindings/interrupt-controller/arm-gic.h>
>   #include <dt-bindings/pinctrl/rockchip.h>
> +#include <dt-bindings/soc/rockchip_boot-mode.h>
>   #include <dt-bindings/thermal/thermal.h>
>
>   / {
> @@ -554,8 +555,19 @@
>   	};
>
>   	pmugrf: syscon at ff738000 {
> -		compatible = "rockchip,rk3368-pmugrf", "syscon";
> +		compatible = "rockchip,rk3368-pmugrf", "syscon", "simple-mfd";
>   		reg = <0x0 0xff738000 0x0 0x1000>;
> +
> +		reboot-mode {
> +			compatible = "syscon-reboot-mode";
> +			offset = <0x200>;
> +			mode-normal = <BOOT_NORMAL>;
> +			mode-recovery = <BOOT_RECOVERY>;
> +			mode-fastboot = <BOOT_FASTBOOT>;
> +			mode-loader = <BOOT_LOADER>;
> +			mode-maskrom = <BOOT_MASKROM>;
> +
> +		};
>   	};
>
>   	cru: clock-controller at ff760000 {
>


-- 
Best Regards
Shawn Lin



From viresh.kumar at linaro.org  Tue Feb  2 18:10:52 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Wed, 3 Feb 2016 07:40:52 +0530
Subject: Plain DFS (no voltage scaling)
In-Reply-To: <56B11B67.3090600@free.fr>
References: <56B11B67.3090600@free.fr>
Message-ID: <20160203021052.GK31828@vireshk>

On 02-02-16, 22:11, Mason wrote:
> Hello,
> 
> I plan to enable the on-demand governor on the tango platform:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
> 
> I found the cpufreq-dt binding doc:
> 
> https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
> 
> Something is not clear to me:
> 
> If my platform cannot scale the voltage, what information
> should I put in the voltage part of the DT?

Wouldn't matter if there is no regulator. i.e. you should keep 0, but
even if they have something non-zero, core code will ignore it. But
yeah, it makes sense to keep it zero.

-- 
viresh


From minghuan.lian at nxp.com  Tue Feb  2 18:11:06 2016
From: minghuan.lian at nxp.com (Minghuan Lian)
Date: Wed, 3 Feb 2016 02:11:06 +0000
Subject: [PATCH 1/4] ARM: dts: ls1021a: add PCIe dts node
In-Reply-To: <6117401.iajrHOL4Mn@wuerfel>
References: <1454401807-28751-1-git-send-email-Minghuan.Lian@nxp.com>
 <VI1PR04MB1615DCF54369ED2E01234E64E8DF0@VI1PR04MB1615.eurprd04.prod.outlook.com>
 <6117401.iajrHOL4Mn@wuerfel>
Message-ID: <VI1PR04MB16159CDCE9C134363846F4CAE8D00@VI1PR04MB1615.eurprd04.prod.outlook.com>

Hi Arnd,

I am sorry.
Other patches are for MSI test, and not need to be summited.
There is only one patch, should be [1/1] not [1/4].  I forgot to remove "1/4" :(
Should I re-summit to fix it?

Thanks,
Minghuan


> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Tuesday, February 02, 2016 5:32 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: Minghuan Lian <minghuan.lian at nxp.com>; linux-pci at vger.kernel.org;
> Shawn Guo <shawnguo at kernel.org>; Sascha Hauer <kernel at pengutronix.de>;
> Roy Zang <roy.zang at nxp.com>; Stuart Yoder <stuart.yoder at nxp.com>;
> Yang-Leo Li <leoyang.li at nxp.com>; Bjorn Helgaas <bhelgaas at google.com>;
> Mingkai Hu <mingkai.hu at nxp.com>
> Subject: Re: [PATCH 1/4] ARM: dts: ls1021a: add PCIe dts node
> 
> On Tuesday 02 February 2016 08:48:36 Minghuan Lian wrote:
> > Hi Shawn,
> >
> > Could you please help to review the patch?  Thank you very much.
> > There is only one patch not a set of patch, please ignore [1/4]
> >
> > Arnd has given a ack.
> 
> For some reason, I did not get the other three patches though, I was going to
> look at them, but I can't tell if this was a series of patches doing PCI support, or
> patches doing other dts changes.
> 
> If you have additional patches for the PCI driver, let's review it all together first.
> 
> 	Arnd

From lkp at intel.com  Tue Feb  2 18:23:42 2016
From: lkp at intel.com (kbuild test robot)
Date: Wed, 3 Feb 2016 10:23:42 +0800
Subject: [PATCH] clk: gpio: Make into a platform driver
In-Reply-To: <1454462520-20787-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <201602031053.Tb6b0qXh%fengguang.wu@intel.com>

Hi Stephen,

[auto build test ERROR on clk/clk-next]
[also build test ERROR on v4.5-rc2 next-20160202]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Stephen-Boyd/clk-gpio-Make-into-a-platform-driver/20160203-092337
base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: mips-maltaaprp_defconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=mips 

All error/warnings (new ones prefixed by >>):

>> drivers/clk/clk-gpio.c:263:1: warning: data definition has no type or storage class
    MODULE_DEVICE_TABLE(of, gpio_clk_match_table);
    ^
>> drivers/clk/clk-gpio.c:263:1: error: type defaults to 'int' in declaration of 'MODULE_DEVICE_TABLE' [-Werror=implicit-int]
>> drivers/clk/clk-gpio.c:263:1: warning: parameter names (without types) in function declaration
   cc1: some warnings being treated as errors

vim +263 drivers/clk/clk-gpio.c

   257	
   258	static const struct of_device_id gpio_clk_match_table[] = {
   259		{ .compatible = "gpio-mux-clock" },
   260		{ .compatible = "gpio-gate-clock" },
   261		{ }
   262	};
 > 263	MODULE_DEVICE_TABLE(of, gpio_clk_match_table);
   264	
   265	static struct platform_driver gpio_clk_driver = {
   266		.probe		= gpio_clk_driver_probe,

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 13851 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/719b8853/attachment-0001.obj>

From Wenyou.Yang at atmel.com  Tue Feb  2 18:29:12 2016
From: Wenyou.Yang at atmel.com (Yang, Wenyou)
Date: Wed, 3 Feb 2016 02:29:12 +0000
Subject: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
 ACT8945A
In-Reply-To: <87wpqn3t72.fsf@dell.be.48ers.dk>
References: <1453863463-30515-1-git-send-email-wenyou.yang@atmel.com>
 <1453863463-30515-2-git-send-email-wenyou.yang@atmel.com>
 <20160129001603.GM4130@sirena.org.uk>
 <B256D81BAE5131468A838E5D7A243641D63FBF8B@penmbx01>
 <20160129113518.GQ4130@sirena.org.uk> <87wpqn3t72.fsf@dell.be.48ers.dk>
Message-ID: <B256D81BAE5131468A838E5D7A243641D64026A0@penmbx01>

Hi Peter,

> -----Original Message-----
> From: Peter Korsgaard [mailto:jacmet at gmail.com] On Behalf Of Peter Korsgaard
> Sent: 2016?2?3? 1:42
> To: Mark Brown <broonie at kernel.org>
> Cc: Yang, Wenyou <Wenyou.Yang at atmel.com>; Liam Girdwood
> <lgirdwood at gmail.com>; Rob Herring <robh+dt at kernel.org>; Pawel Moll
> <pawel.moll at arm.com>; Ian Campbell <ijc+devicetree at hellion.org.uk>; Kumar
> Gala <galak at codeaurora.org>; Krzysztof Kozlowski
> <k.kozlowski at samsung.com>; Javier Martinez Canillas <javier at dowhile0.org>;
> Lee Jones <lee.jones at linaro.org>; Peter Korsgaard <jacmet at gmail.com>; Ferre,
> Nicolas <Nicolas.FERRE at atmel.com>; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org; devicetree at vger.kernel.org
> Subject: Re: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
> ACT8945A
> 
> >>>>> "Mark" == Mark Brown <broonie at kernel.org> writes:
> 
>  > On Fri, Jan 29, 2016 at 01:20:08AM +0000, Yang, Wenyou wrote:
>  >> > > +static const struct of_device_id act8945a_pmic_of_match[] = {
>  >> > > +	{ .compatible = "active-semi,act8945a-regulator" },
>  >> > > +	{ },
>  >> > > +};
>  >> > > +MODULE_DEVICE_TABLE(of, act8945a_pmic_of_match);
> 
>  >> > This seems mostly OK but why do we have a compatible string here -
> shouldn't  >> > the MFD be able to instantiate the regulator function without
> needing this?
> 
>  >> Because I got feedback from Javier for the act8945a-charger patches of this
> MFD series,  >> He said missing the OF match table will cause the module
> autoloading broken.
> 
>  >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/398113.html
> 
>  >> What do you think about it?
> 
>  > If then device is not being loaded from the DT (and it shouldn't be, the  > device
> looks like it should be instantiated directly by the MFD as it  > can't exist
> separately to that MFD) an OF table will do nothing.
> 
> To add to the confusion, the regulator part of the chip is actually identical to
> act8865, so it could use the existing regulator driver / compatible, except that it
> binds to the platform bus instead of i2c.

Thank you for your opinion.

But I think It is better to make it a separate driver, the driver is simpler. 

> 
> --
> Bye, Peter Korsgaard


Best Regards,
Wenyou Yang

From joshc at ni.com  Tue Feb  2 18:30:48 2016
From: joshc at ni.com (Josh Cartwright)
Date: Tue, 2 Feb 2016 20:30:48 -0600
Subject: [PATCH 1/2] ARM: zynq: initialize slcr mapping earlier
In-Reply-To: <cover.1454465714.git.joshc@ni.com>
References: <cover.1454465714.git.joshc@ni.com>
Message-ID: <7ae1c16ab8807d797cf6a742f33cae571c879c6f.1454465714.git.joshc@ni.com>

In preparation for performing additional configuration prior to bringing
up L2, move the slcr initialization earlier in the boot process.

Signed-off-by: Josh Cartwright <joshc at ni.com>
---
 arch/arm/mach-zynq/common.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 6f39d03..860ffb6 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -150,8 +150,6 @@ out:
 
 static void __init zynq_timer_init(void)
 {
-	zynq_early_slcr_init();
-
 	zynq_clock_init();
 	of_clk_init(NULL);
 	clocksource_probe();
@@ -186,6 +184,7 @@ static void __init zynq_map_io(void)
 
 static void __init zynq_irq_init(void)
 {
+	zynq_early_slcr_init();
 	irqchip_init();
 }
 
-- 
2.7.0



From joshc at ni.com  Tue Feb  2 18:30:47 2016
From: joshc at ni.com (Josh Cartwright)
Date: Tue, 2 Feb 2016 20:30:47 -0600
Subject: [PATCH 0/2] ARM: zynq: address silent L2 cache corruption
Message-ID: <cover.1454465714.git.joshc@ni.com>

The Zynq has a bug where the L2 cache will return invalid data in some
circumstances unless the L2C_RAM register is set to 0x20202 before the first
enabling of the L2 cache.

The Xilinx-recommended solution to this problem is to ensure that early one of
the earlier bootstages correctly initialize L2C_RAM, however, this issue wasn't
discovered and fixed until after their EDK/SDK 14.4 release.  For systems built
prior to that, and which lack field-upgradable bootloaders, this issue still
exists and silent data corruption can be seen in the wild.

Fix these systems by ensuring L2C_RAM is properly initialized at the
earliest convenient moment prior to the L2 being brought up, which is
when the SLCR is first mapped.

Unfortunately, there isn't much public documentation on exactly what the
L2C_RAM register is for, or how it is used, only that software is responsible
for initializing it to the proper value prior to bringing up L2.

You can find more information about this bug in AR#54190[1].

1: http://www.xilinx.com/support/answers/54190.html

Josh Cartwright (2):
  ARM: zynq: initialize slcr mapping earlier
  ARM: zynq: address L2 cache data corruption

 arch/arm/mach-zynq/common.c | 3 +--
 arch/arm/mach-zynq/slcr.c   | 4 ++++
 2 files changed, 5 insertions(+), 2 deletions(-)

-- 
2.7.0



From joshc at ni.com  Tue Feb  2 18:30:49 2016
From: joshc at ni.com (Josh Cartwright)
Date: Tue, 2 Feb 2016 20:30:49 -0600
Subject: [PATCH 2/2] ARM: zynq: address L2 cache data corruption
In-Reply-To: <cover.1454465714.git.joshc@ni.com>
References: <cover.1454465714.git.joshc@ni.com>
Message-ID: <9d2012ea9f91ff27f7289fcb9208c10791e4d3a0.1454465714.git.joshc@ni.com>

The Zynq has a bug where the L2 cache will return invalid data in some
circumstances unless the L2C_RAM register is set to 0x00020202 before the first
enabling of the L2 cache.

The Xilinx-recommended solution to this problem is to ensure that early one of
the earlier bootstages correctly initialize L2C_RAM, however, this issue wasn't
discovered and fixed until after their EDK/SDK 14.4 release.  For systems built
prior to that, and which lack field-upgradable bootloaders, this issue still
exists and silent data corruption can be seen in the wild.

Fix these systems by ensuring L2C_RAM is properly initialized at the
earliest convenient moment prior to the L2 being brought up, which is
when the SLCR is first mapped.

The Zynq bug is described in more detail by Xilinx AR# 54190 as quoted
below.

Xilinx AR# 54190
http://www.xilinx.com/support/answers/54190.htm
Captured on 2014-09-24 14:43 -0500

  = Description =
  For proper L2 cache operation, the user code must program the
  slcr.L2C_RAM register (address 0xF800_0A1C) to the value of
  0x0002_0202 before enabling the L2 cache. The reset value
  (0x0001_0101) might cause, very infrequently, the L2 cache to return
  invalid data.

  = Solution =
  It is up to the user code (FSBL or other user code) to set the
  slcr.L2C_RAM register to the value 0x0002_0202 before enabling the L2
  cache.

  Note: The L2 cache is disabled after reset and is not enabled by the
  BootROM.

  Note: The slcr.l2C_RAM register was previously reserved. It is added
  in the Zynq-7000 AP SoC Technical Reference Manual (TRM) v1.5 as
  "Reserved".

Thanks to Jaeden Amero for initial debugging and triage efforts.

Signed-off-by: Josh Cartwright <joshc at ni.com>
---
 arch/arm/mach-zynq/slcr.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-zynq/slcr.c b/arch/arm/mach-zynq/slcr.c
index 26320eb..f0292a3 100644
--- a/arch/arm/mach-zynq/slcr.c
+++ b/arch/arm/mach-zynq/slcr.c
@@ -28,6 +28,7 @@
 #define SLCR_A9_CPU_RST_CTRL_OFFSET	0x244 /* CPU Software Reset Control */
 #define SLCR_REBOOT_STATUS_OFFSET	0x258 /* PS Reboot Status */
 #define SLCR_PSS_IDCODE			0x530 /* PS IDCODE */
+#define SLCR_L2C_RAM			0xA1C /* L2C_RAM in AR#54190 */
 
 #define SLCR_UNLOCK_MAGIC		0xDF0D
 #define SLCR_A9_CPU_CLKSTOP		0x10
@@ -227,6 +228,9 @@ int __init zynq_early_slcr_init(void)
 	/* unlock the SLCR so that registers can be changed */
 	zynq_slcr_unlock();
 
+	/* See AR#54190 design advisory */
+	regmap_update_bits(zynq_slcr_regmap, SLCR_L2C_RAM, 0x70707, 0x20202);
+
 	register_restart_handler(&zynq_slcr_restart_nb);
 
 	pr_info("%s mapped to %p\n", np->name, zynq_slcr_base);
-- 
2.7.0



From majun258 at huawei.com  Tue Feb  2 18:31:52 2016
From: majun258 at huawei.com (majun (F))
Date: Wed, 3 Feb 2016 10:31:52 +0800
Subject: [RFC PATCH] irq/mbigen:Fix the problem of IO remap for duplicated
 physical address in mbigen driver
In-Reply-To: <20160202114340.GA28839@leverpostej>
References: <1454327094-7848-1-git-send-email-majun258@huawei.com>
 <20160201115717.GD674@leverpostej> <56AF585E.6050005@huawei.com>
 <20160201132557.GG674@leverpostej> <56B08431.3000200@huawei.com>
 <20160202114340.GA28839@leverpostej>
Message-ID: <56B16698.6050509@huawei.com>



? 2016/2/2 19:43, Mark Rutland ??:
> On Tue, Feb 02, 2016 at 06:25:53PM +0800, majun (F) wrote:
>> Hi Mark:
>>
>> ? 2016/2/1 21:25, Mark Rutland ??:
>>> On Mon, Feb 01, 2016 at 09:06:38PM +0800, majun (F) wrote:
>>>>
>>>>
>>>> ? 2016/2/1 19:57, Mark Rutland ??:
>>>>> On Mon, Feb 01, 2016 at 07:44:54PM +0800, MaJun wrote:
>>>>>> From: Ma Jun <majun258 at huawei.com>
>>>>>>
>>>>>> For mbigen module, there is a special case that more than one mbigen 
>>>>>> device nodes use the same reg definition in DTS when these devices
>>>>>> exist in the same mbigen hardware module. 
>>>>>>
>>>>>> mbigen_dev1:intc_dev1 {
>>>>>> 	...
>>>>>> 	reg = <0x0 0xc0080000 0x0 0x10000>;
>>>>>> 	...
>>>>>> };
>>>>>>
>>>>>> mbigen_dev2:intc_dev2 {
>>>>>> 	...
>>>>>> 	reg = <0x0 0xc0080000 0x0 0x10000>;
>>>>>> 	...
>>>>>> };
>>>>>
>>>>> This doesn't sound right. If they exist in the same place, and have the
>>>>> same reg, they _are_ the same device.
>>>>>
>>>>> You'll need to explain this better.
>>>>>
>>>>
>>>> For a mbigen hardware module which connecte with several devices,
>>>> because these devices has different device ID,
>>>> I need to define a device node for each device in DTS file.
>>>>
>>>> 	mbigen
>>>> 	|
>>>> ------------------
>>>> | 	| 	|
>>>> dev1 	dev2 	dev3
>>>>
>>>> Because of register layout,the registers related with these devices
>>>> are put together, I can't split them clearly.
>>>> So, I only make these devices which connect with
>>>> same mbigen hardware module usethe same address.
>>>
>>> This sounds like we've either mis-described the mbigen in the binding,
>>> or we're mis-describing the relationship with the devices.
>>>
>>
>> Sorry, I didn't express myself clearly.
>>
>> For example, a mbigen hardware module can support several peripheral devices
>> with different device ID.
>>
>> |-----------------------|-
>> |	mbigen		|
>> |-----------------------|-
>>  |       |        |
>> dev1    dev2     dev3
>>
>> To simplify the mbigen drvier,
>> I didn't use the whole mbigen module as a mbgien device, but use
>> the register collections(vector, trigger type,status etc.) corresponding
>> to a peripheral device as a mbigen device.
>> So, mbigen device is a logical conception or logical device.
> 
>>From the above, it sounds like the DT representation is not an accurate
> representation of the hardware. We should describe the _whole_ mbigen,
> not portions thereof. Trying to describe it piecemeal leads to problems
> like this one.
> 
> I don't understand the rationale for describing the mbigen as separate
> nodes. Above you mention that we "need to define a device node for each
> device", but I don't see why that's necessary. Why do you believe we
> need an mbigen node per client device?
> 
> As far as I can tell, we should be able to map an arbitrary
> interrupt-specifier to a particular MSI (complete with device id) within
> the mbigen driver. We just need to define the full set of MSIs the
> mbigen owns.
> 

mbigen device is a interrupt controller, it is also a ITS device for ITS module.
So, we need to register the each mbigen device to ITS with a unique ID.
Based on the current MSI/ITS driver, I can't register whole mbigen module which
contains several mbigen devices at one time. Because they have different device ID.

I don't know whether this explanation is clear or not.
I think Marc can explain this well.

Marc, would you please help me explain this?  or, do you have any opinion about this ?

>> Now, a mbigen hardware module contains several logical mbigen device.
>>
>> -------------------------------
>> |mgn_dev1  mgn_dev2  mgn_dev3 |
>> |-----------------------------|
>>    |          |        |
>> dev1	    dev2      dev3
>>
>> So,mgn_dev1, mgn_dev2 and mgn_dev3 exist in same mbigen hardware module,
>> and,they use the same reg address region,that is adress of mbigen hardware module.
>>
>> For this case, I think the question is can we map an reg address
>> region more than one time?
> 
> As above, I think we've mis-described the hardware. Rather than making
> things simpler, this has resulted in problems like this one.
> 
> We should not map a reg region more than once. Even if it's technically
> possible to do so, I do not believe that would be the right solution
> here. Implicitly sharing resources (e.g. portions of the mbigen control
> registers) is inevitably going to lead to more problems later on.

Because we only need to write 1 into corresponding bit of status
register to clear interrupt status during runtime,I think we don't
need to worry about this.

Thanks!
Ma Jun


> 
> Mark.
> 
> .
> 



From Wenyou.Yang at atmel.com  Tue Feb  2 18:33:11 2016
From: Wenyou.Yang at atmel.com (Yang, Wenyou)
Date: Wed, 3 Feb 2016 02:33:11 +0000
Subject: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
 ACT8945A
In-Reply-To: <CABxcv=nJsWEv9KW-5iPpUnyN8ZVpx6CV07gBRaLNWqd644YOqQ@mail.gmail.com>
References: <1453863463-30515-1-git-send-email-wenyou.yang@atmel.com>
 <1453863463-30515-2-git-send-email-wenyou.yang@atmel.com>
 <20160129001603.GM4130@sirena.org.uk>
 <B256D81BAE5131468A838E5D7A243641D63FBF8B@penmbx01>
 <20160129113518.GQ4130@sirena.org.uk>
 <CABxcv=kNKmgRytxB5ppawrAvC-GDRhV4T_UUGvpHgKp9+BsUmQ@mail.gmail.com>
 <B256D81BAE5131468A838E5D7A243641D63FE2C7@penmbx01>
 <CABxcv=nJsWEv9KW-5iPpUnyN8ZVpx6CV07gBRaLNWqd644YOqQ@mail.gmail.com>
Message-ID: <B256D81BAE5131468A838E5D7A243641D64026CB@penmbx01>

> -----Original Message-----
> From: Javier Martinez Canillas [mailto:javier at dowhile0.org]
> Sent: 2016?2?1? 21:15
> To: Yang, Wenyou <Wenyou.Yang at atmel.com>
> Cc: Mark Brown <broonie at kernel.org>; Liam Girdwood <lgirdwood at gmail.com>;
> Rob Herring <robh+dt at kernel.org>; Pawel Moll <pawel.moll at arm.com>; Ian
> Campbell <ijc+devicetree at hellion.org.uk>; Kumar Gala <galak at codeaurora.org>;
> Krzysztof Kozlowski <k.kozlowski at samsung.com>; Lee Jones
> <lee.jones at linaro.org>; Peter Korsgaard <jacmet at gmail.com>; Ferre, Nicolas
> <Nicolas.FERRE at atmel.com>; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; devicetree at vger.kernel.org
> Subject: Re: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
> ACT8945A
> 
> Hello Wenyou,
> 
> [snip]
> 
> >> >
> >> > If then device is not being loaded from the DT (and it shouldn't
> >> > be, the device looks like it should be instantiated directly by the
> >> > MFD as it can't exist separately to that MFD) an OF table will do nothing.
> >>
> >> Then he should remove the .of_compatible from the MFD cell definition.
> >
> > I tried it,
> >
> > But if removed this .of_compatible, and reserved the OF table.
> 
> What we said is that you should remove both the mfd cell .of_compatible field and
> the OF table. Of course removing one but leaving the other is not correct.
> 
> > the &pdev->dev->of_node is NULL, the driver fails to get the
> > configuration value from DT,
> >
> 
> I see, you mean that you are not able to lookup the "active-semi,vsel-high"
> property.
> 
> > It seems the OF table still doesn't work. Where is wrong?
> >
> 
> I think the problem is with your DT binding. You have a PMIC dev node with
> compatible "active-semi,act8945a" that has a child node with compatible "active-
> semi,act8945a-regulator" which in turn has the "regulators" node.
> 
> I believe what Mark says is that there shouldn't be a compatible and node for the
> regulators IC since is part of the PMIC. IOW, you can't have it as a standalone
> node in the DTS.
> 
> > Could you help give some suggestion?
> >
> 
> I would just remove the "active-semi,act8945a-regulator" node and make "active-
> semi,vsel-high" a property of the "active-semi,act8945a" node.
> That way you can remove the mfd cell .of_compatible and OF table in the
> regulator driver and read the "active-semi,vsel-high" using the platform device's
> parent of_node.
> 
> But it's better if you wait for Mark's opinions before re-spining your patches.

Hi Mark, what is your opinions?

> 
> Best regards,
> Javier


Best Regards,
Wenyou Yang

From k.kozlowski at samsung.com  Tue Feb  2 18:45:56 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 03 Feb 2016 11:45:56 +0900
Subject: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
 ACT8945A
In-Reply-To: <B256D81BAE5131468A838E5D7A243641D64026A0@penmbx01>
References: <1453863463-30515-1-git-send-email-wenyou.yang@atmel.com>
 <1453863463-30515-2-git-send-email-wenyou.yang@atmel.com>
 <20160129001603.GM4130@sirena.org.uk>
 <B256D81BAE5131468A838E5D7A243641D63FBF8B@penmbx01>
 <20160129113518.GQ4130@sirena.org.uk> <87wpqn3t72.fsf@dell.be.48ers.dk>
 <B256D81BAE5131468A838E5D7A243641D64026A0@penmbx01>
Message-ID: <56B169E4.9030801@samsung.com>

On 03.02.2016 11:29, Yang, Wenyou wrote:
> Hi Peter,
> 
>> -----Original Message-----
>> From: Peter Korsgaard [mailto:jacmet at gmail.com] On Behalf Of Peter Korsgaard
>> Sent: 2016?2?3? 1:42
>> To: Mark Brown <broonie at kernel.org>
>> Cc: Yang, Wenyou <Wenyou.Yang at atmel.com>; Liam Girdwood
>> <lgirdwood at gmail.com>; Rob Herring <robh+dt at kernel.org>; Pawel Moll
>> <pawel.moll at arm.com>; Ian Campbell <ijc+devicetree at hellion.org.uk>; Kumar
>> Gala <galak at codeaurora.org>; Krzysztof Kozlowski
>> <k.kozlowski at samsung.com>; Javier Martinez Canillas <javier at dowhile0.org>;
>> Lee Jones <lee.jones at linaro.org>; Peter Korsgaard <jacmet at gmail.com>; Ferre,
>> Nicolas <Nicolas.FERRE at atmel.com>; linux-arm-kernel at lists.infradead.org;
>> linux-kernel at vger.kernel.org; devicetree at vger.kernel.org
>> Subject: Re: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
>> ACT8945A
>>
>>>>>>> "Mark" == Mark Brown <broonie at kernel.org> writes:
>>
>>  > On Fri, Jan 29, 2016 at 01:20:08AM +0000, Yang, Wenyou wrote:
>>  >> > > +static const struct of_device_id act8945a_pmic_of_match[] = {
>>  >> > > +	{ .compatible = "active-semi,act8945a-regulator" },
>>  >> > > +	{ },
>>  >> > > +};
>>  >> > > +MODULE_DEVICE_TABLE(of, act8945a_pmic_of_match);
>>
>>  >> > This seems mostly OK but why do we have a compatible string here -
>> shouldn't  >> > the MFD be able to instantiate the regulator function without
>> needing this?
>>
>>  >> Because I got feedback from Javier for the act8945a-charger patches of this
>> MFD series,  >> He said missing the OF match table will cause the module
>> autoloading broken.
>>
>>  >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/398113.html
>>
>>  >> What do you think about it?
>>
>>  > If then device is not being loaded from the DT (and it shouldn't be, the  > device
>> looks like it should be instantiated directly by the MFD as it  > can't exist
>> separately to that MFD) an OF table will do nothing.
>>
>> To add to the confusion, the regulator part of the chip is actually identical to
>> act8865, so it could use the existing regulator driver / compatible, except that it
>> binds to the platform bus instead of i2c.
> 
> Thank you for your opinion.
> 
> But I think It is better to make it a separate driver, the driver is simpler. 

Do I understand correctly that you are creating a new device driver for
the same logical device (regulator block)?

By duplicating the code you are not making kernel simpler. Maybe your
new driver will be simple but still this adds a NEW driver instead of
re-using existing code.

Best regards,
Krzysztof



From jaredeh at gmail.com  Tue Feb  2 19:06:06 2016
From: jaredeh at gmail.com (Jared Hulbert)
Date: Tue, 2 Feb 2016 19:06:06 -0800
Subject: [PATCH] ARM: vmlinux.lds: assert that ROM and RAM don't overlap
 when XIP_KERNEL=y
In-Reply-To: <20160203003158.GZ10826@n2100.arm.linux.org.uk>
References: <1454346154-12931-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160203003158.GZ10826@n2100.arm.linux.org.uk>
Message-ID: <CA+ZsKJ5hCSY39D5UBpie5u7XmrJfb0xXBA11hc3z2t8_niKw9g@mail.gmail.com>

On Tue, Feb 2, 2016 at 4:31 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Mon, Feb 01, 2016 at 06:02:34PM +0100, Ard Biesheuvel wrote:
>> When building an XIP kernel, the linker produces two disjoint VMA regions,
>> where the first is mapped onto ROM and the second onto RAM. For this reason,
>> the linker output pointer '.' is updated halfway through the linker script,
>> and set to a value that corresponds with the start of the RAM region.
>>
>> However, in some cases, the ROM region exceeds the expected size, and the
>> assignment of the output pointer results in a decrement rather than an
>> increment, causing the virtual addresses of the .data region to clash with
>> the .text region. Such a kernel cannot boot normally, but it also confuses
>> the hell out of kallsyms, since .data symbols may appear inside the
>> [_stext, _etext] or [_sinittext, _einittext] intervals in the first pass,
>> but not in the second (or vice versa), resulting in inconsistent kallsyms
>> data.
>>
>> So let's make sure that the output pointer only advances, and never jumps
>> back into the ROM region.
>
> The long term goal is to move the XIP stuff out of this file, so
> I think it's better to avoid touching this until the split has
> happened.
>
> I'd _much_ rather see the split happen first, and then fixes
> applied, rather than trying to fix the existing unmaintainable
> mess.

Is that split being actively worked on?  If so by whom?


From djkurtz at chromium.org  Tue Feb  2 19:29:29 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Wed, 3 Feb 2016 11:29:29 +0800
Subject: [PATCH v8 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
In-Reply-To: <1454300012-32552-2-git-send-email-jitao.shi@mediatek.com>
References: <1454300012-32552-1-git-send-email-jitao.shi@mediatek.com>
 <1454300012-32552-2-git-send-email-jitao.shi@mediatek.com>
Message-ID: <CAGS+omAhExDg1H96nFY1EEKwTPVsnS6vNnxJCPYL4QwMt+hAcw@mail.gmail.com>

Hi Jitao,

One more comment, inline...

On Mon, Feb 1, 2016 at 12:13 PM, Jitao Shi <jitao.shi at mediatek.com> wrote:
> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
>
> Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>

[snip]

> +static int ps8640_probe(struct i2c_client *client,
> +                       const struct i2c_device_id *id)
> +{
> +       struct device *dev = &client->dev;
> +       struct ps8640 *ps_bridge;
> +       struct device_node *np = dev->of_node;
> +       struct device_node *port, *out_ep;
> +       struct device_node *panel_node = NULL;
> +       int i, ret;
> +
> +       ps_bridge = devm_kzalloc(dev, sizeof(*ps_bridge), GFP_KERNEL);
> +       ps_bridge->dsi = devm_kzalloc(dev, sizeof(struct mipi_dsi_device),
> +                                     GFP_KERNEL);
> +       if (!ps_bridge) {
> +               ret = -ENOMEM;
> +               goto exit;
> +       }
> +       /* port at 1 is ps8640 output port */
> +       port = of_graph_get_port_by_id(np, 1);
> +       if (port) {
> +               out_ep = of_get_child_by_name(port, "endpoint");
> +               of_node_put(port);
> +               if (out_ep) {
> +                       panel_node = of_graph_get_remote_port_parent(out_ep);
> +                       of_node_put(out_ep);
> +               }
> +       }
> +       if (panel_node) {
> +               ps_bridge->panel = of_drm_find_panel(panel_node);
> +               of_node_put(panel_node);
> +               if (!ps_bridge->panel) {
> +                       ret = -EPROBE_DEFER;
> +                       goto exit;
> +               }
> +       }
> +
> +       ps_bridge->pwr_3v3_supply = devm_regulator_get(dev, "vdd33");
> +       if (IS_ERR(ps_bridge->pwr_3v3_supply)) {
> +               ret = PTR_ERR(ps_bridge->pwr_3v3_supply);
> +               dev_err(dev, "cannot get vdd33 supply: %d\n", ret);
> +               goto exit;
> +       }
> +
> +       ps_bridge->pwr_1v2_supply = devm_regulator_get(dev, "vdd12");

Since we have two regulators, and they must always be enabled &
disabled together, we can just use the 'bulk regulator' APIs:

  devm_regulator_bulk_get()
  regulator_bulk_enable()
  regulator_bulk_disable()


From Chris.Brandt at renesas.com  Tue Feb  2 19:54:59 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Wed, 3 Feb 2016 03:54:59 +0000
Subject: [PATCH] ARM: vmlinux.lds: assert that ROM and RAM don't overlap
 when XIP_KERNEL=y
In-Reply-To: <CA+ZsKJ5hCSY39D5UBpie5u7XmrJfb0xXBA11hc3z2t8_niKw9g@mail.gmail.com>
References: <1454346154-12931-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160203003158.GZ10826@n2100.arm.linux.org.uk>
 <CA+ZsKJ5hCSY39D5UBpie5u7XmrJfb0xXBA11hc3z2t8_niKw9g@mail.gmail.com>
Message-ID: <HKXPR06MB0565FC1048E3851BA9A58B108AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>

> > The long term goal is to move the XIP stuff out of this file, so I 
> > think it's better to avoid touching this until the split has happened.
> >
> > I'd _much_ rather see the split happen first, and then fixes applied, 
> > rather than trying to fix the existing unmaintainable mess.
>
> Is that split being actively worked on?  If so by whom?

I submitted "[PATCH v2] ARM: xip: Move XIP linking to a separate file" back in November which seemed pretty straight forward.

Although, it didn't make it too far (other than Nicolas acking it)

Chris


From nicolas.pitre at linaro.org  Tue Feb  2 20:08:39 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 2 Feb 2016 23:08:39 -0500 (EST)
Subject: [PATCH] ARM: vmlinux.lds: assert that ROM and RAM don't overlap
 when XIP_KERNEL=y
In-Reply-To: <HKXPR06MB0565FC1048E3851BA9A58B108AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>
References: <1454346154-12931-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160203003158.GZ10826@n2100.arm.linux.org.uk>
 <CA+ZsKJ5hCSY39D5UBpie5u7XmrJfb0xXBA11hc3z2t8_niKw9g@mail.gmail.com>
 <HKXPR06MB0565FC1048E3851BA9A58B108AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>
Message-ID: <alpine.LFD.2.20.1602022305200.32766@knanqh.ubzr>

On Wed, 3 Feb 2016, Chris Brandt wrote:

> > > The long term goal is to move the XIP stuff out of this file, so I 
> > > think it's better to avoid touching this until the split has happened.
> > >
> > > I'd _much_ rather see the split happen first, and then fixes applied, 
> > > rather than trying to fix the existing unmaintainable mess.
> >
> > Is that split being actively worked on?  If so by whom?
> 
> I submitted "[PATCH v2] ARM: xip: Move XIP linking to a separate file" back in November which seemed pretty straight forward.
> 
> Although, it didn't make it too far (other than Nicolas acking it)

For your ARM patches to be merged upstream, once you feel they've 
received sufficient review on the list, you then have to submit them 
here:

http://www.arm.linux.org.uk/developer/patches/


Nicolas


From wxt at rock-chips.com  Tue Feb  2 20:12:39 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Wed,  3 Feb 2016 12:12:39 +0800
Subject: [PATCH 0/8] Support and fixes the rk3228 SoCS for thermal
Message-ID: <1454472767-5767-1-git-send-email-wxt@rock-chips.com>

Hello Eduardo, Heiko, Michael & Stephen:

This series pacthes to support the rk3228 SoCs thermal.

They have the following patches to work on rk3228 SoCs.

bdc79c0 ARM: dts: rockchip: add the thermal main info found on rk3228
22ea3c3 ARM: dts: rockchip: enable the tsadc for rk3228 evb
b907b75 thermal: rockchip: fix the tsadc sequence output on rk3228/rk3399
fb11fbd thermal: rockchip: the rename compatibles for rockchip SoCs
df9c1bd thermal: rockchip: fix calculation error for code_to_temp
bd2720c thermal: rockchip: fix a impossible condition caused by the warning
8cf2d1b clk: rockchip: add the tsadc clocks found on rk3228 SoCs
1a6f334 clk: rockchip: add id of the tsadc clock found on rk3228 SoCs

Verified on https://github.com/Caesar-github/rockchip/tree/rk3228-thermal-tests.
This series patches are based on
Linux version 4.5.0-rc1+ (wxt at ubuntu) (...) #186 SMP Tue Feb 2 17:11:48 CST 2016

---

Hi Michael,Stephen
PATCH[1/8-2/8]:
Add the tsadc needed clocks for rk3228 SoCs

Hi Eduardo,
PATCH[3/8]:
To fix a build warning came from Dan Carpenter report smatch check,
Thanks.
As the patch exists in https://patchwork.kernel.org/patch/7757311/

PATCH[4/8]:
fix calculation error for code_to_temp
That's a error since the copy causes.

PATCH[5/8]:
the rename compatibles for rockchip SoCs
As the more and more rockchip SOCs are supported in thermal driver. this pacth
supposed to be compatible for better.

PATCH[6/8]:
fix the tsadc sequence output on rk3228/rk3399
Fixes the tsadc sequence output since the rk3228/rk3399 SoCs design.

Hi Heiko,
PATCH[7/8-8/8]: thermal DTS
1) add the thermal main info found on rk3228
2) enable the tsadc for rk3228 evb

I'd appreciate if someone have free time to review that. :)



Caesar Wang (7):
  clk: rockchip: add id of the tsadc clock found on rk3228 SoCs
  clk: rockchip: add the tsadc clocks found on rk3228 SoCs
  thermal: rockchip: fix a impossible condition caused by the warning
  thermal: rockchip: the rename compatibles for rockchip SoCs
  thermal: rockchip: fix the tsadc sequence output on rk3228/rk3399
  ARM: dts: rockchip: enable the tsadc for rk3228 evb
  ARM: dts: rockchip: add the thermal main info found on rk3228

Elaine Zhang (1):
  thermal: rockchip: fix calculation error for code_to_temp

 arch/arm/boot/dts/rk3228-evb.dts       |   7 +
 arch/arm/boot/dts/rk3228.dtsi          |  69 ++++++++++
 drivers/clk/rockchip/clk-rk3228.c      |   4 +-
 drivers/thermal/rockchip_thermal.c     | 239 +++++++++++++++++++--------------
 include/dt-bindings/clock/rk3228-cru.h |   2 +
 5 files changed, 216 insertions(+), 105 deletions(-)

-- 
1.9.1



From wxt at rock-chips.com  Tue Feb  2 20:12:41 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Wed,  3 Feb 2016 12:12:41 +0800
Subject: [PATCH 2/8] clk: rockchip: add the tsadc clocks found on rk3228 SoCs
In-Reply-To: <1454472767-5767-1-git-send-email-wxt@rock-chips.com>
References: <1454472767-5767-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1454472767-5767-3-git-send-email-wxt@rock-chips.com>

This patch adds the needed clocks for rk3228 tsadc.

Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

 drivers/clk/rockchip/clk-rk3228.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3228.c b/drivers/clk/rockchip/clk-rk3228.c
index 981a502..6374fef 100644
--- a/drivers/clk/rockchip/clk-rk3228.c
+++ b/drivers/clk/rockchip/clk-rk3228.c
@@ -422,7 +422,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[] __initdata = {
 	GATE(0, "sclk_otgphy1", "xin24m", 0,
 			RK2928_CLKGATE_CON(1), 6, GFLAGS),
 
-	COMPOSITE_NOMUX(0, "sclk_tsadc", "xin24m", 0,
+	COMPOSITE_NOMUX(SCLK_TSADC, "sclk_tsadc", "xin24m", 0,
 			RK2928_CLKSEL_CON(24), 6, 10, DFLAGS,
 			RK2928_CLKGATE_CON(2), 8, GFLAGS),
 
@@ -582,7 +582,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[] __initdata = {
 	GATE(PCLK_UART0, "pclk_uart0", "pclk_cpu", 0, RK2928_CLKGATE_CON(9), 12, GFLAGS),
 	GATE(PCLK_UART1, "pclk_uart1", "pclk_cpu", 0, RK2928_CLKGATE_CON(9), 13, GFLAGS),
 	GATE(PCLK_UART2, "pclk_uart2", "pclk_cpu", 0, RK2928_CLKGATE_CON(9), 14, GFLAGS),
-	GATE(0, "pclk_tsadc", "pclk_cpu", 0, RK2928_CLKGATE_CON(9), 15, GFLAGS),
+	GATE(PCLK_TSADC, "pclk_tsadc", "pclk_cpu", 0, RK2928_CLKGATE_CON(9), 15, GFLAGS),
 	GATE(PCLK_GRF, "pclk_grf", "pclk_cpu", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(10), 0, GFLAGS),
 	GATE(0, "pclk_cru", "pclk_cpu", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(10), 1, GFLAGS),
 	GATE(0, "pclk_sgrf", "pclk_cpu", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(10), 2, GFLAGS),
-- 
1.9.1



From wxt at rock-chips.com  Tue Feb  2 20:12:42 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Wed,  3 Feb 2016 12:12:42 +0800
Subject: [PATCH 3/8] thermal: rockchip: fix a impossible condition caused by
 the warning
In-Reply-To: <1454472767-5767-1-git-send-email-wxt@rock-chips.com>
References: <1454472767-5767-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1454472767-5767-4-git-send-email-wxt@rock-chips.com>

As the Dan report the smatch check the thermal driver warning:
drivers/thermal/rockchip_thermal.c:551 rockchip_configure_from_dt()
warn: impossible condition '(thermal->tshut_temp > ((~0 >> 1))) =>
(s32min-s32max > s32max)'

Although The shut_temp read from DT is u32,the temperature is currently
represented as int not long in the thermal driver.
Let's change to make shut_temp instead of the thermal->tshut_temp for
the condition.

Fixes: commit 437df2172e8d
("thermal: rockchip: consistently use int for temperatures")

Reported-by: Dan Carpenter <dan.carpenter at oracle.com>
Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

 drivers/thermal/rockchip_thermal.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c
index b58e3fb..433085a 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -693,15 +693,14 @@ static int rockchip_configure_from_dt(struct device *dev,
 			 thermal->chip->tshut_temp);
 		thermal->tshut_temp = thermal->chip->tshut_temp;
 	} else {
+		if (shut_temp > INT_MAX) {
+			dev_err(dev, "Invalid tshut temperature specified: %d\n",
+				shut_temp);
+			return -ERANGE;
+		}
 		thermal->tshut_temp = shut_temp;
 	}
 
-	if (thermal->tshut_temp > INT_MAX) {
-		dev_err(dev, "Invalid tshut temperature specified: %d\n",
-			thermal->tshut_temp);
-		return -ERANGE;
-	}
-
 	if (of_property_read_u32(np, "rockchip,hw-tshut-mode", &tshut_mode)) {
 		dev_warn(dev,
 			 "Missing tshut mode property, using default (%s)\n",
-- 
1.9.1



From wxt at rock-chips.com  Tue Feb  2 20:12:43 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Wed,  3 Feb 2016 12:12:43 +0800
Subject: [PATCH 4/8] thermal: rockchip: fix calculation error for code_to_temp
In-Reply-To: <1454472767-5767-1-git-send-email-wxt@rock-chips.com>
References: <1454472767-5767-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1454472767-5767-5-git-send-email-wxt@rock-chips.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

the calculation use a global table, not their own table.
so adapt the table to the correct one.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

 drivers/thermal/rockchip_thermal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c
index 433085a..5c58d48 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -411,7 +411,7 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code,
 	 * temperature between 2 table entries is linear and interpolate
 	 * to produce less granular result.
 	 */
-	num = table.id[mid].temp - v2_code_table[mid - 1].temp;
+	num = table.id[mid].temp - table.id[mid - 1].temp;
 	num *= abs(table.id[mid - 1].code - code);
 	denom = abs(table.id[mid - 1].code - table.id[mid].code);
 	*temp = table.id[mid - 1].temp + (num / denom);
-- 
1.9.1



From wxt at rock-chips.com  Tue Feb  2 20:12:44 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Wed,  3 Feb 2016 12:12:44 +0800
Subject: [PATCH 5/8] thermal: rockchip: the rename compatibles for rockchip
 SoCs
In-Reply-To: <1454472767-5767-1-git-send-email-wxt@rock-chips.com>
References: <1454472767-5767-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1454472767-5767-6-git-send-email-wxt@rock-chips.com>

This patch renames to be more adapter compatibles since more and more
SoCs are supported in thermal driver.

Reported-by: Huang,Tao <huangtao at rock-chips.com>
Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

 drivers/thermal/rockchip_thermal.c | 50 +++++++++++++++++++++-----------------
 1 file changed, 28 insertions(+), 22 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c
index 5c58d48..9cdef62 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -58,8 +58,8 @@ enum sensor_id {
 
 /**
  * The conversion table has the adc value and temperature.
- * ADC_DECREMENT: the adc value is of diminishing.(e.g. v2_code_table)
- * ADC_INCREMENT: the adc value is incremental.(e.g. v3_code_table)
+ * ADC_DECREMENT: the adc value is of diminishing.(e.g. rk3288_code_table)
+ * ADC_INCREMENT: the adc value is incremental.(e.g. rk3368_code_table)
  */
 enum adc_sort_mode {
 	ADC_DECREMENT = 0,
@@ -135,7 +135,13 @@ struct rockchip_thermal_data {
 	enum tshut_polarity tshut_polarity;
 };
 
-/* TSADC Sensor info define: */
+/**
+ * TSADC Sensor Register description:
+ *
+ * TSADCV2_* are used for RK3288 SoCs, the other chips can reuse it.
+ * TSADCV3_* are used for newer SoCs than RK3288. (e.g: RK3228, RK3399)
+ *
+ */
 #define TSADCV2_AUTO_CON			0x04
 #define TSADCV2_INT_EN				0x08
 #define TSADCV2_INT_PD				0x0c
@@ -154,8 +160,8 @@ struct rockchip_thermal_data {
 #define TSADCV2_SHUT_2GPIO_SRC_EN(chn)		BIT(4 + (chn))
 #define TSADCV2_SHUT_2CRU_SRC_EN(chn)		BIT(8 + (chn))
 
-#define TSADCV1_INT_PD_CLEAR_MASK		~BIT(16)
 #define TSADCV2_INT_PD_CLEAR_MASK		~BIT(8)
+#define TSADCV3_INT_PD_CLEAR_MASK		~BIT(16)
 
 #define TSADCV2_DATA_MASK			0xfff
 #define TSADCV3_DATA_MASK			0x3ff
@@ -177,7 +183,7 @@ struct tsadc_table {
  * linearly interpolated.
  * Code to Temperature mapping should be updated based on sillcon results.
  */
-static const struct tsadc_table v1_code_table[] = {
+static const struct tsadc_table rk3228_code_table[] = {
 	{TSADCV3_DATA_MASK, -40000},
 	{436, -40000},
 	{431, -35000},
@@ -215,7 +221,7 @@ static const struct tsadc_table v1_code_table[] = {
 	{264, 125000},
 };
 
-static const struct tsadc_table v2_code_table[] = {
+static const struct tsadc_table rk3288_code_table[] = {
 	{TSADCV2_DATA_MASK, -40000},
 	{3800, -40000},
 	{3792, -35000},
@@ -253,7 +259,7 @@ static const struct tsadc_table v2_code_table[] = {
 	{3421, 125000},
 };
 
-static const struct tsadc_table v3_code_table[] = {
+static const struct tsadc_table rk3368_code_table[] = {
 	{0, -40000},
 	{106, -40000},
 	{108, -35000},
@@ -292,7 +298,7 @@ static const struct tsadc_table v3_code_table[] = {
 	{TSADCV3_DATA_MASK, 125000},
 };
 
-static const struct tsadc_table v4_code_table[] = {
+static const struct tsadc_table rk3399_code_table[] = {
 	{TSADCV3_DATA_MASK, -40000},
 	{431, -40000},
 	{426, -35000},
@@ -453,20 +459,20 @@ static void rk_tsadcv2_initialize(void __iomem *regs,
 		       regs + TSADCV2_HIGHT_TSHUT_DEBOUNCE);
 }
 
-static void rk_tsadcv1_irq_ack(void __iomem *regs)
+static void rk_tsadcv2_irq_ack(void __iomem *regs)
 {
 	u32 val;
 
 	val = readl_relaxed(regs + TSADCV2_INT_PD);
-	writel_relaxed(val & TSADCV1_INT_PD_CLEAR_MASK, regs + TSADCV2_INT_PD);
+	writel_relaxed(val & TSADCV2_INT_PD_CLEAR_MASK, regs + TSADCV2_INT_PD);
 }
 
-static void rk_tsadcv2_irq_ack(void __iomem *regs)
+static void rk_tsadcv3_irq_ack(void __iomem *regs)
 {
 	u32 val;
 
 	val = readl_relaxed(regs + TSADCV2_INT_PD);
-	writel_relaxed(val & TSADCV2_INT_PD_CLEAR_MASK, regs + TSADCV2_INT_PD);
+	writel_relaxed(val & TSADCV3_INT_PD_CLEAR_MASK, regs + TSADCV2_INT_PD);
 }
 
 static void rk_tsadcv2_control(void __iomem *regs, bool enable)
@@ -531,15 +537,15 @@ static const struct rockchip_tsadc_chip rk3228_tsadc_data = {
 	.tshut_temp = 95000,
 
 	.initialize = rk_tsadcv2_initialize,
-	.irq_ack = rk_tsadcv1_irq_ack,
+	.irq_ack = rk_tsadcv3_irq_ack,
 	.control = rk_tsadcv2_control,
 	.get_temp = rk_tsadcv2_get_temp,
 	.set_tshut_temp = rk_tsadcv2_tshut_temp,
 	.set_tshut_mode = rk_tsadcv2_tshut_mode,
 
 	.table = {
-		.id = v1_code_table,
-		.length = ARRAY_SIZE(v1_code_table),
+		.id = rk3228_code_table,
+		.length = ARRAY_SIZE(rk3228_code_table),
 		.data_mask = TSADCV3_DATA_MASK,
 		.mode = ADC_DECREMENT,
 	},
@@ -562,8 +568,8 @@ static const struct rockchip_tsadc_chip rk3288_tsadc_data = {
 	.set_tshut_mode = rk_tsadcv2_tshut_mode,
 
 	.table = {
-		.id = v2_code_table,
-		.length = ARRAY_SIZE(v2_code_table),
+		.id = rk3288_code_table,
+		.length = ARRAY_SIZE(rk3288_code_table),
 		.data_mask = TSADCV2_DATA_MASK,
 		.mode = ADC_DECREMENT,
 	},
@@ -586,8 +592,8 @@ static const struct rockchip_tsadc_chip rk3368_tsadc_data = {
 	.set_tshut_mode = rk_tsadcv2_tshut_mode,
 
 	.table = {
-		.id = v3_code_table,
-		.length = ARRAY_SIZE(v3_code_table),
+		.id = rk3368_code_table,
+		.length = ARRAY_SIZE(rk3368_code_table),
 		.data_mask = TSADCV3_DATA_MASK,
 		.mode = ADC_INCREMENT,
 	},
@@ -603,15 +609,15 @@ static const struct rockchip_tsadc_chip rk3399_tsadc_data = {
 	.tshut_temp = 95000,
 
 	.initialize = rk_tsadcv2_initialize,
-	.irq_ack = rk_tsadcv1_irq_ack,
+	.irq_ack = rk_tsadcv3_irq_ack,
 	.control = rk_tsadcv2_control,
 	.get_temp = rk_tsadcv2_get_temp,
 	.set_tshut_temp = rk_tsadcv2_tshut_temp,
 	.set_tshut_mode = rk_tsadcv2_tshut_mode,
 
 	.table = {
-		.id = v4_code_table,
-		.length = ARRAY_SIZE(v4_code_table),
+		.id = rk3399_code_table,
+		.length = ARRAY_SIZE(rk3399_code_table),
 		.data_mask = TSADCV3_DATA_MASK,
 		.mode = ADC_DECREMENT,
 	},
-- 
1.9.1



From wxt at rock-chips.com  Tue Feb  2 20:12:45 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Wed,  3 Feb 2016 12:12:45 +0800
Subject: [PATCH 6/8] thermal: rockchip: fix the tsadc sequence output on
 rk3228/rk3399
In-Reply-To: <1454472767-5767-1-git-send-email-wxt@rock-chips.com>
References: <1454472767-5767-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1454472767-5767-7-git-send-email-wxt@rock-chips.com>

As the TRM says, add the tsadc_q_sel to control the temperature-code
sequence since the rk3228/rk3399 need set this bit (1024 - tsadc_q)
as output.

Fixes: commit
b0d7033 "thermal: rockchip: Support the RK3399 SoCs in thermal driver"
7b02a5e "thermal: rockchip: Support the RK3228 SoCs in thermal driver"

Reported-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

 drivers/thermal/rockchip_thermal.c | 176 +++++++++++++++++++++----------------
 1 file changed, 102 insertions(+), 74 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c
index 9cdef62..233a564 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -155,6 +155,13 @@ struct rockchip_thermal_data {
 #define TSADCV2_AUTO_EN				BIT(0)
 #define TSADCV2_AUTO_SRC_EN(chn)		BIT(4 + (chn))
 #define TSADCV2_AUTO_TSHUT_POLARITY_HIGH	BIT(8)
+/**
+ * TSADCV1_AUTO_Q_SEL_EN:
+ * whether select (1024 - tsadc_q) as output
+ * 1'b0:use tsadc_q as output(temperature-code is rising sequence)
+ * 1'b1:use(1024 - tsadc_q) as output (temperature-code is falling sequence)
+ */
+#define TSADCV3_AUTO_Q_SEL_EN			BIT(1)
 
 #define TSADCV2_INT_SRC_EN(chn)			BIT(chn)
 #define TSADCV2_SHUT_2GPIO_SRC_EN(chn)		BIT(4 + (chn))
@@ -184,41 +191,42 @@ struct tsadc_table {
  * Code to Temperature mapping should be updated based on sillcon results.
  */
 static const struct tsadc_table rk3228_code_table[] = {
-	{TSADCV3_DATA_MASK, -40000},
-	{436, -40000},
-	{431, -35000},
-	{426, -30000},
-	{421, -25000},
-	{416, -20000},
-	{411, -15000},
-	{406, -10000},
-	{401, -5000},
-	{395, 0},
-	{390, 5000},
-	{385, 10000},
-	{380, 15000},
-	{375, 20000},
-	{370, 25000},
-	{364, 30000},
-	{359, 35000},
-	{354, 40000},
-	{349, 45000},
-	{343, 50000},
-	{338, 55000},
-	{333, 60000},
-	{328, 65000},
-	{322, 70000},
-	{317, 75000},
-	{312, 80000},
-	{307, 85000},
-	{301, 90000},
-	{296, 95000},
-	{291, 100000},
-	{286, 105000},
-	{280, 110000},
-	{275, 115000},
-	{270, 120000},
-	{264, 125000},
+	{0, -40000},
+	{588, -40000},
+	{593, -35000},
+	{598, -30000},
+	{603, -25000},
+	{608, -20000},
+	{613, -15000},
+	{618, -10000},
+	{623, -5000},
+	{629, 0},
+	{634, 5000},
+	{639, 10000},
+	{644, 15000},
+	{649, 20000},
+	{654, 25000},
+	{660, 30000},
+	{665, 35000},
+	{670, 40000},
+	{675, 45000},
+	{681, 50000},
+	{686, 55000},
+	{691, 60000},
+	{696, 65000},
+	{702, 70000},
+	{707, 75000},
+	{712, 80000},
+	{717, 85000},
+	{723, 90000},
+	{728, 95000},
+	{733, 100000},
+	{738, 105000},
+	{744, 110000},
+	{749, 115000},
+	{754, 120000},
+	{760, 125000},
+	{TSADCV2_DATA_MASK, 125000},
 };
 
 static const struct tsadc_table rk3288_code_table[] = {
@@ -299,41 +307,42 @@ static const struct tsadc_table rk3368_code_table[] = {
 };
 
 static const struct tsadc_table rk3399_code_table[] = {
-	{TSADCV3_DATA_MASK, -40000},
-	{431, -40000},
-	{426, -35000},
-	{421, -30000},
-	{415, -25000},
-	{410, -20000},
-	{405, -15000},
-	{399, -10000},
-	{394, -5000},
-	{389, 0},
-	{383, 5000},
-	{378, 10000},
-	{373, 15000},
-	{367, 20000},
-	{362, 25000},
-	{357, 30000},
-	{351, 35000},
-	{346, 40000},
-	{340, 45000},
-	{335, 50000},
-	{330, 55000},
-	{324, 60000},
-	{319, 65000},
-	{313, 70000},
-	{308, 75000},
-	{302, 80000},
-	{297, 85000},
-	{291, 90000},
-	{286, 95000},
-	{281, 100000},
-	{275, 105000},
-	{270, 110000},
-	{264, 115000},
-	{259, 120000},
-	{253, 125000},
+	{0, -40000},
+	{593, -40000},
+	{598, -35000},
+	{603, -30000},
+	{609, -25000},
+	{614, -20000},
+	{619, -15000},
+	{625, -10000},
+	{630, -5000},
+	{635, 0},
+	{641, 5000},
+	{646, 10000},
+	{651, 15000},
+	{657, 20000},
+	{662, 25000},
+	{667, 30000},
+	{673, 35000},
+	{678, 40000},
+	{684, 45000},
+	{689, 50000},
+	{694, 55000},
+	{700, 60000},
+	{705, 65000},
+	{711, 70000},
+	{716, 75000},
+	{722, 80000},
+	{727, 85000},
+	{733, 90000},
+	{738, 95000},
+	{743, 100000},
+	{749, 105000},
+	{754, 110000},
+	{760, 115000},
+	{765, 120000},
+	{771, 125000},
+	{TSADCV3_DATA_MASK, 125000},
 };
 
 static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table,
@@ -488,6 +497,25 @@ static void rk_tsadcv2_control(void __iomem *regs, bool enable)
 	writel_relaxed(val, regs + TSADCV2_AUTO_CON);
 }
 
+/**
+ * @rk_tsadcv3_control:
+ * TSADC controller works at auto mode, and some SoCs need set the tsadc_q_sel
+ * bit on TSADCV2_AUTO_CON[1]. The (1024 - tsadc_q) as output adc value if
+ * setting this bit to enable.
+ */
+static void rk_tsadcv3_control(void __iomem *regs, bool enable)
+{
+	u32 val;
+
+	val = readl_relaxed(regs + TSADCV2_AUTO_CON);
+	if (enable)
+		val |= TSADCV2_AUTO_EN | TSADCV3_AUTO_Q_SEL_EN;
+	else
+		val &= ~TSADCV2_AUTO_EN;
+
+	writel_relaxed(val, regs + TSADCV2_AUTO_CON);
+}
+
 static int rk_tsadcv2_get_temp(struct chip_tsadc_table table,
 			       int chn, void __iomem *regs, int *temp)
 {
@@ -538,7 +566,7 @@ static const struct rockchip_tsadc_chip rk3228_tsadc_data = {
 
 	.initialize = rk_tsadcv2_initialize,
 	.irq_ack = rk_tsadcv3_irq_ack,
-	.control = rk_tsadcv2_control,
+	.control = rk_tsadcv3_control,
 	.get_temp = rk_tsadcv2_get_temp,
 	.set_tshut_temp = rk_tsadcv2_tshut_temp,
 	.set_tshut_mode = rk_tsadcv2_tshut_mode,
@@ -547,7 +575,7 @@ static const struct rockchip_tsadc_chip rk3228_tsadc_data = {
 		.id = rk3228_code_table,
 		.length = ARRAY_SIZE(rk3228_code_table),
 		.data_mask = TSADCV3_DATA_MASK,
-		.mode = ADC_DECREMENT,
+		.mode = ADC_INCREMENT,
 	},
 };
 
@@ -610,7 +638,7 @@ static const struct rockchip_tsadc_chip rk3399_tsadc_data = {
 
 	.initialize = rk_tsadcv2_initialize,
 	.irq_ack = rk_tsadcv3_irq_ack,
-	.control = rk_tsadcv2_control,
+	.control = rk_tsadcv3_control,
 	.get_temp = rk_tsadcv2_get_temp,
 	.set_tshut_temp = rk_tsadcv2_tshut_temp,
 	.set_tshut_mode = rk_tsadcv2_tshut_mode,
@@ -619,7 +647,7 @@ static const struct rockchip_tsadc_chip rk3399_tsadc_data = {
 		.id = rk3399_code_table,
 		.length = ARRAY_SIZE(rk3399_code_table),
 		.data_mask = TSADCV3_DATA_MASK,
-		.mode = ADC_DECREMENT,
+		.mode = ADC_INCREMENT,
 	},
 };
 
-- 
1.9.1



From wxt at rock-chips.com  Tue Feb  2 20:12:46 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Wed,  3 Feb 2016 12:12:46 +0800
Subject: [PATCH 7/8] ARM: dts: rockchip: enable the tsadc for rk3228 evb
In-Reply-To: <1454472767-5767-1-git-send-email-wxt@rock-chips.com>
References: <1454472767-5767-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1454472767-5767-8-git-send-email-wxt@rock-chips.com>

This patch enables the tsadc for rk3228 evb board.

The rk3228 evb board uses the CRU to reset the chip since it hasn't the
PMIC to connect it, and TSHUT is low active on evb board.

Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

 arch/arm/boot/dts/rk3228-evb.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/rk3228-evb.dts b/arch/arm/boot/dts/rk3228-evb.dts
index e3898b8..c75cc41 100644
--- a/arch/arm/boot/dts/rk3228-evb.dts
+++ b/arch/arm/boot/dts/rk3228-evb.dts
@@ -61,6 +61,13 @@
 	status = "okay";
 };
 
+&tsadc {
+	status = "okay";
+
+	rockchip,hw-tshut-mode = <0>; /* tshut mode 0:CRU 1:GPIO */
+	rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
+};
+
 &uart2 {
 	status = "okay";
 };
-- 
1.9.1



From wxt at rock-chips.com  Tue Feb  2 20:12:47 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Wed,  3 Feb 2016 12:12:47 +0800
Subject: [PATCH 8/8] ARM: dts: rockchip: add the thermal main info found on
 rk3228
In-Reply-To: <1454472767-5767-1-git-send-email-wxt@rock-chips.com>
References: <1454472767-5767-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1454472767-5767-9-git-send-email-wxt@rock-chips.com>

This patch adds the thermal needed main information for rk3228 SoCS.

Basically has the following content:

1) TSADC controller:
Add the needed attributes for rk3036 TSADC controller.

Especially for the TSHUT, in some cases if we are unable to shut it down
in orderly fashion (says: kernel is stuck holding a lock or similar), then
hardware TSHUT will reset it.
If the temperature is over 95C over a period of time the thermal shutdown
of the tsadc is invoked with can either reset the entire chip via the CRU,
or notify the PMIC via a GPIO. This should be set in the specific board.

2) Thermal zones:
Add the needed device mode for thermal generic framework.
Detail in Documentation/devicetree/bindings/thermal/thermal.txt.

Signed-off-by: Caesar Wang <wxt at rock-chips.com>

---

 arch/arm/boot/dts/rk3228.dtsi | 69 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/arch/arm/boot/dts/rk3228.dtsi b/arch/arm/boot/dts/rk3228.dtsi
index 119ff12..afce7fd 100644
--- a/arch/arm/boot/dts/rk3228.dtsi
+++ b/arch/arm/boot/dts/rk3228.dtsi
@@ -43,6 +43,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/pinctrl/rockchip.h>
 #include <dt-bindings/clock/rk3228-cru.h>
+#include <dt-bindings/thermal/thermal.h>
 #include "skeleton.dtsi"
 
 / {
@@ -69,6 +70,7 @@
 				/* KHz    uV */
 				 816000 1000000
 			>;
+			#cooling-cells = <2>; /* min followed by max */
 			clock-latency = <40000>;
 			clocks = <&cru ARMCLK>;
 		};
@@ -247,6 +249,63 @@
 		assigned-clock-rates = <594000000>;
 	};
 
+	thermal-zones {
+		cpu_thermal: cpu-thermal {
+			polling-delay-passive = <100>; /* milliseconds */
+			polling-delay = <5000>; /* milliseconds */
+
+			thermal-sensors = <&tsadc 0>;
+
+			trips {
+				cpu_alert0: cpu_alert0 {
+					temperature = <70000>; /* millicelsius */
+					hysteresis = <2000>; /* millicelsius */
+					type = "passive";
+				};
+				cpu_alert1: cpu_alert1 {
+					temperature = <75000>; /* millicelsius */
+					hysteresis = <2000>; /* millicelsius */
+					type = "passive";
+				};
+				cpu_crit: cpu_crit {
+					temperature = <90000>; /* millicelsius */
+					hysteresis = <2000>; /* millicelsius */
+					type = "critical";
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_alert0>;
+					cooling-device =
+						<&cpu0 THERMAL_NO_LIMIT 6>;
+				};
+				map1 {
+					trip = <&cpu_alert1>;
+					cooling-device =
+						<&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
+		};
+	};
+
+	tsadc: tsadc at 11150000 {
+		compatible = "rockchip,rk3228-tsadc";
+		reg = <0x11150000 0x100>;
+		interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_TSADC>, <&cru PCLK_TSADC>;
+		clock-names = "tsadc", "apb_pclk";
+		resets = <&cru SRST_TSADC>;
+		reset-names = "tsadc-apb";
+		pinctrl-names = "init", "default", "sleep";
+		pinctrl-0 = <&otp_gpio>;
+		pinctrl-1 = <&otp_out>;
+		pinctrl-2 = <&otp_gpio>;
+		#thermal-sensor-cells = <0>;
+		rockchip,hw-tshut-temp = <95000>;
+		status = "disabled";
+	};
+
 	emmc: dwmmc at 30020000 {
 		compatible = "rockchip,rk3288-dw-mshc";
 		reg = <0x30020000 0x4000>;
@@ -394,6 +453,16 @@
 			};
 		};
 
+		tsadc {
+			otp_gpio: otp-gpio {
+				rockchip,pins = <0 24 RK_FUNC_GPIO &pcfg_pull_none>;
+			};
+
+			otp_out: otp-out {
+				rockchip,pins = <0 24 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
 		uart0 {
 			uart0_xfer: uart0-xfer {
 				rockchip,pins = <2 26 RK_FUNC_1 &pcfg_pull_none>,
-- 
1.9.1



From jamesjj.liao at mediatek.com  Tue Feb  2 21:22:48 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Wed, 3 Feb 2016 13:22:48 +0800
Subject: [PATCH v4 1/4] soc: mediatek: Refine scpsys to support multiple
 platform
In-Reply-To: <56B0889A.1010305@gmail.com>
References: <1453270097-53853-1-git-send-email-jamesjj.liao@mediatek.com>
 <1453270097-53853-2-git-send-email-jamesjj.liao@mediatek.com>
 <56ADF556.6070402@gmail.com> <1454396212.2847.15.camel@mtksdaap41>
 <56B0889A.1010305@gmail.com>
Message-ID: <1454476968.2847.59.camel@mtksdaap41>

Hi Matthias,

On Tue, 2016-02-02 at 11:44 +0100, Matthias Brugger wrote:
> On 02/02/16 07:56, James Liao wrote:
> > On Sun, 2016-01-31 at 12:51 +0100, Matthias Brugger wrote:
> >> >On 20/01/16 07:08, James Liao wrote:
> >>> > >Refine scpsys driver common code to support multiple SoC / platform.
> >>> > >
> >>> > >Signed-off-by: James Liao<jamesjj.liao at mediatek.com>
> >>> > >---
> >>> > >   drivers/soc/mediatek/mtk-scpsys.c | 418 ++++++++++++++++++++------------------
> >>> > >   drivers/soc/mediatek/mtk-scpsys.h |  55 +++++
> >>> > >   2 files changed, 270 insertions(+), 203 deletions(-)
> >>> > >   create mode 100644 drivers/soc/mediatek/mtk-scpsys.h
> >> >
> >> >In general this approach looks fine to me, comments below.
> >> >
> >>> > >
> >>> > >diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> >>> > >index 0221387..339adfc 100644
> >>> > >--- a/drivers/soc/mediatek/mtk-scpsys.c
> >>> > >+++ b/drivers/soc/mediatek/mtk-scpsys.c
> >>> > >@@ -11,29 +11,17 @@
> >>> > >    * GNU General Public License for more details.
> >>> > >    */
> >>> > >   #include <linux/clk.h>
> >>> > >-#include <linux/delay.h>
> >>> > >+#include <linux/init.h>
> >>> > >   #include <linux/io.h>
> >>> > >-#include <linux/kernel.h>
> >>> > >   #include <linux/mfd/syscon.h>
> >> >
> >> >When at it, do we need this include?
> > syscon_regmap_lookup_by_phandle() is declared in this head file.
> >
> >>> > >-#include <linux/init.h>
> >>> > >   #include <linux/of_device.h>
> >>> > >   #include <linux/platform_device.h>
> >>> > >   #include <linux/pm_domain.h>
> >>> > >-#include <linux/regmap.h>
> >>> > >-#include <linux/soc/mediatek/infracfg.h>
> >>> > >   #include <linux/regulator/consumer.h>
> >>> > >-#include <dt-bindings/power/mt8173-power.h>
> >>> > >+#include <linux/soc/mediatek/infracfg.h>
> >>> > >+
> >>> > >+#include "mtk-scpsys.h"
> >>> > >
> >>> > >-#define SPM_VDE_PWR_CON			0x0210
> >>> > >-#define SPM_MFG_PWR_CON			0x0214
> >>> > >-#define SPM_VEN_PWR_CON			0x0230
> >>> > >-#define SPM_ISP_PWR_CON			0x0238
> >>> > >-#define SPM_DIS_PWR_CON			0x023c
> >>> > >-#define SPM_VEN2_PWR_CON		0x0298
> >>> > >-#define SPM_AUDIO_PWR_CON		0x029c
> >>> > >-#define SPM_MFG_2D_PWR_CON		0x02c0
> >>> > >-#define SPM_MFG_ASYNC_PWR_CON		0x02c4
> >>> > >-#define SPM_USB_PWR_CON			0x02cc
> >> >
> >> >I would prefer to keep this defines and declare SoC specific ones where
> >> >necessary. It makes the code more readable.
> > Some register address may be reused by other modules among SoCs, so it's
> > not easy to maintain the defines when we implement multiple SoC drivers
> > in the same file. For example, offset 0x0298 is VEN2_PWR_CON on MT8173,
> > but it is MJC_PWR_CON on other chips.
> >
> 
> So that sounds as if 0x0298 offset is MT8173 specific.
> I checked [VDE, MFG, VEN, IFR, ISP, DIS, DPY]_PWR_CON on mt8173, mt8135 
> and mt6589 and they all have the same offset. So it doesn't seem as if 
> the offset randomly changes for every SoC.
> 
> > Furthermore, these register offsets are only used in scp_domain_data[],
> > and each element has its own power domain name. So I think it's enough
> > to know which power domain are using these registers and status bits.
> >
> 
> Yes that's true, but it will make it easier for another person to 
> understand the driver, especially if he want's to implement the driver 
> for a new SoC.

There are two kinds of conflicts may happen:

1. Different modules use the same register address.
2. Different register addresses are used by the same module (on
different IC).

Type 1. for example:

	#define SPM_BDP_PWR_CON			0x029c /* 2701 */
	#define SPM_AUDIO_PWR_CON		0x029c /* 8173 */

We can resolve this conflict easily, such as define these two register
name to the same register address.

Type 2. for example:

	#define SPM_VDE_PWR_CON			0x0300 /* 6755 */
	#define SPM_VDE_PWR_CON			0x0210 /* 8173 */

We can not reuse the register defines in this case. We may need to name
the registers with its IC name, such as MT8173_SPM_VDE_PWR_CON and
MT6755_VDE_PWR_CON. But it will increase the maintain effort. That's why
I prefer to remove register defines if we implement multiple SoC's
scpsys in a single file.


Best regards,

James




From menghui.lin at mediatek.com  Tue Feb  2 21:39:02 2016
From: menghui.lin at mediatek.com (menghui lin)
Date: Wed, 3 Feb 2016 13:39:02 +0800
Subject: [PATCH V4 2/2] regulator: mt6323: Add support for MT6323 regulator
In-Reply-To: <20160202193839.GX4455@sirena.org.uk>
References: <1453896059-44589-1-git-send-email-blogic@openwrt.org>
 <1453896059-44589-2-git-send-email-blogic@openwrt.org>
 <20160127144105.GQ6042@sirena.org.uk> <56AA5A5C.9080402@openwrt.org>
 <20160128231306.GD4130@sirena.org.uk>
 <1454061134.10861.14.camel@mtksdaap41>
 <20160129112717.GP4130@sirena.org.uk>
 <1454069479.10861.30.camel@mtksdaap41>
 <20160202193839.GX4455@sirena.org.uk>
Message-ID: <1454477942.31375.32.camel@mtksdaap41>

On Tue, 2016-02-02 at 19:38 +0000, Mark Brown wrote:
> On Fri, Jan 29, 2016 at 08:11:19PM +0800, menghui lin wrote:
> > On Fri, 2016-01-29 at 12:27 +0100, Mark Brown wrote:
> 
> > > None of this is answering my question - I know what the current API is,
> > > describing it doesn't tell me about actual users or how they are able to
> > > sensibly use the interface.  Bear in mind that the definitions of the
> > > various modes are all relative and what one device thinks is high usage
> > > may be low usage for another device.
> 
> > Assuming valid_modes_mask and initial_mode are specified, a possible
> > way to modify regulator_set_mode() is to allow mode change only if the
> > regulator is controlled exclusively by a certain consumer or the
> > requested mode provides stronger power capability than current mode.
> > Here I assume that power capability fast > normal > idle > standby.
> 
> How does the driver know if it needs to change the mode (ie, how can it
> tell if the current mode is inadequate) and surely if we can only change
> in one direction this isn't terribly useful?

Hi Mark,

I think the datasheet of buck/ldo could provide information about power
capability of each mode. The driver should adjust regulator mode per its
device's power requirement.

Below are some actual scenarios we have now. I provide them for your
reference. If unfortunately below cases are not the actual users you
ask, please kindly let me know more about your suggestion.
Thank you. :)

case 1:

We have a USB typeC micro-controller, which has two modes - standby and
normal. It requires 1.8V and 3.3V to operate (both powers are always
on). The device stays in standby mode when there is no cable in. When
cable in, we got an interrupt and change device into normal mode.

The standby mode power consumption is quite small, so we would like the
change mode of regulator into STANDBY to save more power. And we change
into NORMAL when we receive cable-in interrupt.

case 2:

About buck regulator for CPU, it usually provides PWM mode, PWM/PFM Auto
mode, PFM mode. I think it could map to FAST, NORMAL, IDLE mode
respectively. Most of time we would use just normal mode. However, we
would change regulator into PWM mode time to time to test buck output
performance on the tested board.





From hs.liao at mediatek.com  Tue Feb  2 22:02:13 2016
From: hs.liao at mediatek.com (Horng-Shyang Liao)
Date: Wed, 3 Feb 2016 14:02:13 +0800
Subject: FW: [RFC 3/3] CMDQ: Mediatek CMDQ driver
In-Reply-To: <8A0FDEEF9DBBD140A3857422D81DA20F867B19FD@mtkmbs01n1>
References: <8A0FDEEF9DBBD140A3857422D81DA20F867B19FD@mtkmbs01n1>
Message-ID: <1454479333.11967.12.camel@mtksdaap41>

On Wed, 2016-02-03 at 09:40 +0800, Cawa Cheng (???) wrote:
> 
> -----Original Message-----
> From: djkurtz at google.com [mailto:djkurtz at google.com] On Behalf Of Daniel Kurtz
> Sent: Wednesday, February 03, 2016 12:22 AM
> To: Hs Liao (???)
> Cc: Rob Herring; Matthias Brugger; Sascha Hauer; open list:OPEN FIRMWARE AND...; linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; moderated list:ARM/Mediatek SoC support; srv_heupstream; Sascha Hauer; Philipp Zabel; Nicolas Boichat; CK Hu (???); Cawa Cheng (???); Bibby Hsieh (???); YT Shen (???); Daoyuan Huang (???); Damon Chu (???); Josh-YC Liu (???); Glory Hung (???); Yong Wu (??)
> Subject: Re: [RFC 3/3] CMDQ: Mediatek CMDQ driver
> 
> On Tue, Feb 2, 2016 at 2:48 PM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
> > On Mon, 2016-02-01 at 18:22 +0800, Daniel Kurtz wrote:
> >> On Mon, Feb 1, 2016 at 2:20 PM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
> >> > On Mon, 2016-02-01 at 12:15 +0800, Daniel Kurtz wrote:
> >> >> On Mon, Feb 1, 2016 at 10:04 AM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
> >> >> >
> >> >> > On Fri, 2016-01-29 at 21:15 +0800, Daniel Kurtz wrote:
> >> >> > > On Fri, Jan 29, 2016 at 8:24 PM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
> >> >> > > > On Fri, 2016-01-29 at 16:42 +0800, Daniel Kurtz wrote:
> >> >> > > >> On Fri, Jan 29, 2016 at 3:39 PM, Horng-Shyang Liao <hs.liao at mediatek.com> wrote:
> >> >> > > >> > Hi Dan,
> >> >> > > >> >
> >> >> > > >> > Many thanks for your comments and time.
> >> >> > > >> > I reply my plan inline.
> >> >> > > >> >
> >> >> > > >> >
> >> >> > > >> > On Thu, 2016-01-28 at 12:49 +0800, Daniel Kurtz wrote:
> >> >> > > >> >> Hi HS,
> >> >> > > >> >>
> >> >> > > >> >> Sorry for the delay.  It is hard to find time to review 
> >> >> > > >> >> a >3700 line driver :-o in detail....
> >> >> > > >> >>
> >> >> > > >> >> Some review comments inline, although I still do not 
> >> >> > > >> >> completely understand how all that this driver does and how it works.
> >> >> > > >> >> I'll try to find time to go through this driver in 
> >> >> > > >> >> detail again next time you post it for review.
> >> >> > > >> >>
> >> >> > > >> >> On Tue, Jan 19, 2016 at 9:14 PM,  <hs.liao at mediatek.com> wrote:
> >> >> > > >> >> > From: HS Liao <hs.liao at mediatek.com>
> >> >> > > >> >> >
> >> >> > > >> >> > This patch is first version of Mediatek Command 
> >> >> > > >> >> > Queue(CMDQ) driver. The CMDQ is used to help 
> >> >> > > >> >> > read/write registers with critical time limitation, 
> >> >> > > >> >> > such as updating display configuration during the vblank. It controls Global Command Engine (GCE) hardware to achieve this requirement.
> >> >> > > >> >> > Currently, CMDQ only supports display related 
> >> >> > > >> >> > hardwares, but we expect it can be extended to other hardwares for future requirements.
> >> >> > > >> >> >
> >> >> > > >> >> > Signed-off-by: HS Liao <hs.liao at mediatek.com>
> >> >> > > >> >>
> >> >> > > >> >> [snip]
> >> >> > > >> >>
> >> >> > > >> >> > diff --git a/drivers/soc/mediatek/mtk-cmdq.c 
> >> >> > > >> >> > b/drivers/soc/mediatek/mtk-cmdq.c new file mode 100644 
> >> >> > > >> >> > index 0000000..7570f00
> >> >> > > >> >> > --- /dev/null
> >> >> > > >> >> > +++ b/drivers/soc/mediatek/mtk-cmdq.c
> >> >> > > >
> >> >> > > > [snip]
> >> >> > > >
> >> >> > > >> >> > +static const struct cmdq_subsys g_subsys[] = {
> >> >> > > >> >> > +       {0x1400, 1, "MMSYS"},
> >> >> > > >> >> > +       {0x1401, 2, "DISP"},
> >> >> > > >> >> > +       {0x1402, 3, "DISP"},
> >> >> > > >> >>
> >> >> > > >> >> This isn't going to scale.  These addresses could be 
> >> >> > > >> >> different on different chips.
> >> >> > > >> >> Instead of a static table like this, we probably need 
> >> >> > > >> >> specify to the connection between gce and other devices 
> >> >> > > >> >> via devicetree phandles, and then use the phandles to 
> >> >> > > >> >> lookup the corresponding device address range.
> >> >> > > >> >
> >> >> > > >> > I will define them in device tree.
> >> >> > > >> > E.g.
> >> >> > > >> > cmdq {
> >> >> > > >> >   reg_domain = 0x14000000, 0x14010000, 0x14020000 }
> >> >> > > >>
> >> >> > > >> The devicetree should only model hardware relationships, 
> >> >> > > >> not software considerations.
> >> >> > > >>
> >> >> > > >> Is the hardware constraint here for using gce with various 
> >> >> > > >> other hardware blocks?  I think we already model this by 
> >> >> > > >> only providing a gce phandle in the device tree nodes for 
> >> >> > > >> those devices that can use gce.
> >> >> > > >>
> >> >> > > >> Looking at the driver closer, as far as I can tell, the 
> >> >> > > >> whole subsys concept is a purely software abstraction, and 
> >> >> > > >> only used to debug the CMDQ_CODE_WRITE command.  In fact, 
> >> >> > > >> AFAICT, everything would work fine if we just completely 
> >> >> > > >> removed the 'subsys' concept, and just passed through the raw address provided by the driver.
> >> >> > > >>
> >> >> > > >> So, I recommend just removing 'subsys' completely from the 
> >> >> > > >> driver - from this array, and in the masks.
> >> >> > > >>
> >> >> > > >> Instead, if there is an error on the write command, just 
> >> >> > > >> print the address that fails.  There are other ways to 
> >> >> > > >> deduce the subsystem from a physical address.
> >> >> > > >>
> >> >> > > >> Thanks,
> >> >> > > >>
> >> >> > > >> -Dan
> >> >> > > >
> >> >> > > > Hi Dan,
> >> >> > > >
> >> >> > > > Subsys is not just for debug.
> >> >> > > > Its main purpose is to transfer CPU address to GCE address.
> >> >> > > > Let me explain it by "write" op, I list a code segment from 
> >> >> > > > cmdq_rec_append_command().
> >> >> > > >
> >> >> > > >         case CMDQ_CODE_WRITE:
> >> >> > > >                 subsys = cmdq_subsys_from_phys_addr(cqctx, arg_a);
> >> >> > > >                 if (subsys < 0) {
> >> >> > > >                         dev_err(dev,
> >> >> > > >                                 "unsupported memory base address 0x%08x\n",
> >> >> > > >                                 arg_a);
> >> >> > > >                         return -EFAULT;
> >> >> > > >                 }
> >> >> > > >
> >> >> > > >                 *cmd_ptr++ = arg_b;
> >> >> > > >                 *cmd_ptr++ = (CMDQ_CODE_WRITE << CMDQ_OP_CODE_SHIFT) |
> >> >> > > >                              (arg_a & CMDQ_ARG_A_WRITE_MASK) |
> >> >> > > >                              ((subsys & CMDQ_SUBSYS_MASK) << CMDQ_SUBSYS_SHIFT);
> >> >> > > >                 break;
> >> >> > > >
> >> >> > > > Subsys is mapped from physical address via 
> >> >> > > > cmdq_subsys_from_phys_addr(), and then it becomes part of 
> >> >> > > > GCE command via ((subsys & CMDQ_SUBSYS_MASK) << CMDQ_SUBSYS_SHIFT) .
> >> >> > > > Only low bits of physical address are the same as GCE address.
> >> >> > > > We can get it by (arg_a & CMDQ_ARG_A_WRITE_MASK).
> >> >> > > > MASK is used to define how many bits are valid for this op.
> >> >> > > > So, GCE address = subsys + valid low bits.
> >> >> > >
> >> >> > > How are these upper bits of the "GCE address" defined?
> >> >> > > In other words, for a given SoC, how is the mapping between 
> >> >> > > physical io addresses to GCE addresses defined?
> >> >> > > Is this mapping fixed by hardware?
> >> >>
> >> >> Please answer the detailed technical questions:
> >> >>
> >> >> How are these upper bits of the "GCE address" defined?
> >> >
> >> > A GCE command is arg_a + arg_b. Both of them have 32 bits length.
> >> > arg_a is op + subsys + addr, and arg_b is value.
> >> > subsys + addr is less than 32bits, so we need to map address range 
> >> > to subsys.
> >> > The mapping rule is defined by hardware.
> >> >
> >> >> In other words, for a given SoC, how is the mapping between 
> >> >> physical io addresses to GCE addresses defined?
> >> >
> >> > It is (b).
> >> >
> >> >>
> >> >> (a) Does the GCE remap a continuous device IO address range?
> >> >>
> >> >> AFAICT, the  defines an MT8173 specific mapping of:
> >> >>
> >> >> For example, the g_subsys table above seems to imply that the 
> >> >> MT8173 gce maps all of:
> >> >>   0x1400ffff:0x141fffff => 0x010000:0x1fffff
> >> >>
> >> >> (b) Or, are the upper 5 bits of the "gce address" significant, and 
> >> >> via hardware it can map a disjoint groups of device addresses into 
> >> >> the continuous GCE address space, and really there are 0x1f 
> >> >> distinct 64k
> >> >> mappings:
> >> >>
> >> >> mmsys (1) : 0x14000000:0x1400ffff => 0x010000:0x01ffff disp  (2) : 
> >> >> 0x14010000:0x1401ffff => 0x020000:0x02ffff disp  (3) : 
> >> >> 0x14020000:0x1402ffff => 0x030000:0x03ffff ...
> >> >> ???? (1f) : 0x141fffff:0x141fffff => 0x1f0000:0x1fffff
> >> >>
> >> >> If the mapping is fixed and continuous (a), then I think all we 
> >> >> need is a single dts entry for the gce node that describes how it 
> >> >> performs this mapping.  And then, the gce consumers can just pass 
> >> >> in their regular physical addresses, and the gce driver can remap 
> >> >> them directly to gce addresses.
> >> >>
> >> >> WDYT?
> >> >
> >> > How about this?
> >> > hardware_module = <address_base subsys_id mask>; So, the result is 
> >> > mmsys_config_base = <0x14000000 1 0xffff0000>; 
> >> > disp_rdma_config_base = <0x14010000 2 0xffff0000>; 
> >> > disp_mutex_config_base = <0x14020000 3 0xffff0000>;
> >>
> >> What uses ID 0 and 4 - 0x1f?
> >
> > Subsys is defined by GCE hardware, and other IDs are reserved currently.
> >
> >> According to mt8173.dtsi, here are the blocks in the address ranges above:
> >>
> >> @1400:
> >>   mmsys: clock-controller at 14000000
> >>   ovl0: ovl at 1400c000
> >>   ovl1: ovl at 1400d000
> >>   rdma0: rdma at 1400e000
> >>   rdma1: rdma at 1400f000
> >>
> >> @1401:
> >>   rdma2: rdma at 14010000
> >>   wdma0: wdma at 14011000
> >>   wdma1: wdma at 14012000
> >>   color0: color at 14013000
> >>   color1: color at 14014000
> >>   aal at 14015000
> >>   gamma at 14016000
> >>   merge at 14017000
> >>   split0: split at 14018000
> >>   split1: split at 14019000
> >>   ufoe at 1401a000
> >>   dsi0: dsi at 1401b000
> >>   dsi1: dsi at 1401c000
> >>   dpi0: dpi at 1401d000
> >>   pwm0: pwm at 1401e000
> >>   pwm1: pwm at 1401f000
> >>
> >> @1402:
> >>   mutex: mutex at 14020000
> >>   od at 14023000
> >>   larb0: larb at 14021000
> >>   smi_common: smi at 14022000
> >>   hdmi0: hdmi at 14025000
> >>   larb4: larb at 14027000
> >>
> >> I assume that the gce will work with any of the devices in those
> >> ranges, not just "mmsys", "rdma" and "mutex", right?   (Also, notice
> >
> > That's right.
> >
> >> there are two "rdma" in the @1400 range, so rdma is really not a good 
> >> name for @1401)
> >
> > I think we can just use index.
> > disp0_config_base = <0x14000000 1 0xffff0000>; disp1_config_base = 
> > <0x14010000 2 0xffff0000>; disp2_config_base = <0x14020000 3 
> > 0xffff0000>;
> >
> >> Further, it looks like the gce just maps a large device address range 
> >> starting at 0x14000000 to (21-bit) gce address 0x010000, rather than
> >> 31 individually addressable 64k "subsys" blocks.  Is there a counter 
> >> example that I am missing?
> >
> > From GCE's point of view,
> > it's 32 (0x0~0x1f) individually addressable 64k "subsys" blocks.
> > Currently, we don't have a counter example since all display related 
> > address are put together.
> 
> Ok, in this case, perhaps we should treat the GCE like an IOMMU, and have its binding define 32 slots or channels.
> Then, any device that wishes to send the GCE commands for its address range should register a phandle to the gce, including the corresponding slot.
> 
> For example:
> 
> include/.../gce.h
> include/dt-bindings/../mediatek-gce.h
> #define GCE_SLOT_1  1
> ...
> 
> arch/arm64/boot/dts/mediatek/mt8173.dtsi:
> 
> &ovl0: {
>   mediatek,gce = <&gce GCE_SLOT_1>;
> };
> 
> &ovl1: {
>   mediatek,gce = <&gce GCE_SLOT_1>;
> };
> 
> &rdma2: {
>   mediatek,gce = <&gce GCE_SLOT_2>;
> };
> 
> &mutex: {
>   mediatek,gce = <&gce GCE_SLOT_3>;
> };
> 
> &od: {
>   mediatek,gce = <&gce GCE_SLOT_3>;
> };
> 
> Then, as each platform driver is probed, it can use the phandle to look up its corresponding gce slot instance, retrieving an (opaque) pointer to a struct gce_slot.
> The gce driver can have a set of constant tables matching the slots to address ranges for particular per-soc compatibles, one of which is loaded on probe.
> Later, when the device (gce consumer) wants to send a gce write command, it passes in the gce_slot as an argument, and the gce driver can do the corresponding lookup of subsys value and mask out the provided *device virtual* address.  In this way, you also no longer need to convert the devices iomap'ed addresses into physical addresses before passing them to the gce.
> 
> WDYT?
> 
> -Dan

Hi Dan,

Thanks for your comment.
This solution looks good to me.
I will change it as your suggestion.

But, I have a question about 'mask out the provided *device virtual*
address'.
Are lower 16-bits (or 24-bits for JUMP op) of device virtual address the
same as device physical address?
If not, we still need to pass in physical address into CMDQ driver.

Thanks,
HS Liao



From jszhang at marvell.com  Tue Feb  2 22:24:51 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Wed, 3 Feb 2016 14:24:51 +0800
Subject: [PATCH 03/10] arm64: add Armada 3700 architecture entry
In-Reply-To: <1454436468-4241-4-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-4-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160203142451.41381ff6@xhacker>

On Tue, 2 Feb 2016 19:07:41 +0100 Gregory CLEMENT wrote:

> The Armada 3700 is an mvebu ARM64 SoC using one or two Cortex-A53 cores
> depending of the variant.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  arch/arm64/Kconfig.platforms | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 21074f674bde..7da341f7b90d 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -1,5 +1,11 @@
>  menu "Platform selection"
>  
> +config ARCH_ARMADA_3700

Would it be better to use ARCH_MVEBU? IMHO, there will be more ARMv8 SoCs
from our EBU, do we plan to add one CONFIG_ARMADA_yyzz for each SoC?

> +	bool "Armada 3700 SoC Family"
> +	help
> +	  This enables support for Armada 3700 SoC Family. It is is an
> +	  ARMv8 based chipset belonging to the mvebu family.
> +
>  config ARCH_BCM_IPROC
>  	bool "Broadcom iProc SoC Family"
>  	help



From jszhang at marvell.com  Tue Feb  2 22:37:11 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Wed, 3 Feb 2016 14:37:11 +0800
Subject: [PATCH 07/10] arm64: dts: add the Marvell Armada 3700 family
 and a development board
In-Reply-To: <1454436468-4241-8-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-8-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160203143711.1eee3243@xhacker>

On Tue, 2 Feb 2016 19:07:45 +0100 Gregory CLEMENT wrote:

> Add initial dtsi files to support Marvell Armada 3700 SoC with Cortex-A53
> CPUs. There are two members in this family: the Armada 3710 (Single CPU)
> and the Armada 3720 (Dual CPUs).
> 
> It also adds a dts file for the Marvell Armada 3720 DB board.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  arch/arm64/boot/dts/marvell/Makefile           |   4 +
>  arch/arm64/boot/dts/marvell/armada-371x.dtsi   |  53 ++++++++++
>  arch/arm64/boot/dts/marvell/armada-3720-db.dts |  87 ++++++++++++++++
>  arch/arm64/boot/dts/marvell/armada-372x.dtsi   |  63 ++++++++++++
>  arch/arm64/boot/dts/marvell/armada-37xx.dtsi   | 131 +++++++++++++++++++++++++
>  5 files changed, 338 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-371x.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-db.dts
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-372x.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> 
> diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
> index 348f4db4f313..bc2eabe1cab1 100644
> --- a/arch/arm64/boot/dts/marvell/Makefile
> +++ b/arch/arm64/boot/dts/marvell/Makefile
> @@ -1,6 +1,10 @@
> +# Berlin SoC Family
>  dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-dmp.dtb
>  dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
>  
> +# Mvebu SoC Family
> +dtb-$(CONFIG_ARCH_ARMADA_3700) += armada-3720-db.dtb
> +
>  always		:= $(dtb-y)
>  subdir-y	:= $(dts-dirs)
>  clean-files	:= *.dtb
> diff --git a/arch/arm64/boot/dts/marvell/armada-371x.dtsi b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
> new file mode 100644
> index 000000000000..c9e5325b8ac3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
> @@ -0,0 +1,53 @@
> +/*
> + * Device Tree Include file for Marvell Armada 371x family of SoCs
> + * (also named 88F3710)
> + *
> + * Copyright (C) 2016 Marvell

Is it better to Add full Marvell company name, eg. Marvell Technology Group Ltd.

> + *
> + * Gregory CLEMENT <gregory.clement at free-electrons.com>

Do we need to put "Author: " at the head?

> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This file is distributed in the hope that it will be useful
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "armada-37xx.dtsi"
> +
> +/ {
> +	model = "Marvell Armada 3710 SoC";
> +	compatible = "marvell,armada3710", "marvell,armada3700";
> +};
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
> new file mode 100644
> index 000000000000..76cae6ba2bd6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
> @@ -0,0 +1,87 @@
> +/*
> + * Device Tree file for Marvell Armada 3720 development board
> + * (DB-88F3720-DDR3)
> + * Copyright (C) 2016 Marvell
> + *
> + * Gregory CLEMENT <gregory.clement at free-electrons.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This file is distributed in the hope that it will be useful
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "armada-372x.dtsi"
> +
> +/ {
> +	model = "Marvell Armada 3720 Development Board DB-88F3720-DDR3";
> +	compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3700";
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		/* use only 256 MB on the 512 MB available */
> +		reg = <0x00000000 0x00000000 0x00000000 0x10000000>;
> +	};
> +
> +	soc {
> +		internal-regs {
> +			/*
> +			* Exported on the micro USB connector CON32
> +			* through an FTDI
> +			*/
> +			uart0: serial at 12000 {
> +				status = "okay";
> +			};
> +
> +			/* CON31 */
> +			usb3 at 58000 {
> +				status = "okay";
> +			};
> +
> +			/* CON3 */
> +			sata at e0000 {
> +			       status = "okay";
> +			};
> +		};
> +	};
> +};
> +
> diff --git a/arch/arm64/boot/dts/marvell/armada-372x.dtsi b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
> new file mode 100644
> index 000000000000..f57f41c20ddf
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
> @@ -0,0 +1,63 @@
> +/*
> + * Device Tree Include file for Marvell Armada 372x family of SoCs
> + * (also named 88F3720)
> + *
> + * Copyright (C) 2016 Marvell
> + *
> + * Gregory CLEMENT <gregory.clement at free-electrons.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This file is distributed in the hope that it will be useful
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "armada-37xx.dtsi"
> +
> +/ {
> +	model = "Marvell Armada 3720 SoC";
> +	compatible = "marvell,armada3720", "marvell,armada3700";
> +
> +	cpus {
> +		cpu at 1 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a53","arm,armv8";
> +			reg = <0x1>;
> +			enable-method = "psci";
> +		};
> +	};
> +
> +};
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> new file mode 100644
> index 000000000000..ba9df7ff2a72
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -0,0 +1,131 @@
> +/*
> + * Device Tree Include file for Marvell Armada 37xx family of SoCs.
> + *
> + * Copyright (C) 2016 Marvell
> + *
> + * Gregory CLEMENT <gregory.clement at free-electrons.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This file is distributed in the hope that it will be useful
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> +	model = "Marvell Armada 37xx SoC";
> +	compatible = "marvell,armada3700";
> +	interrupt-parent = <&gic>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	aliases {
> +		serial0 = &uart0;
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			reg = <0>;
> +			enable-method = "psci";
> +		};
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-0.2";
> +		method = "smc";
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts = <GIC_PPI 13
> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 14
> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 11
> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 10
> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
> +	};
> +
> +	soc {
> +		compatible = "simple-bus";
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		internal-regs {
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			compatible = "simple-bus";
> +			/* 32M internal register @ 0xd000_0000 */
> +			ranges = <0x0 0x0 0xd0000000 0x2000000>;
> +
> +			uart0: serial at 12000 {
> +				compatible = "marvell,armada-3700-uart";
> +				reg = <0x12000 0x400>;
> +				interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
> +				status = "disabled";
> +			};
> +
> +			usb3 at 58000 {
> +				compatible = "generic-xhci";
> +				reg = <0x58000 0x4000>;
> +				interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
> +				status = "disabled";
> +			};
> +
> +			sata at e0000 {
> +				compatible = "marvell,armada-3700-ahci";
> +				reg = <0xe0000 0x2000>;
> +				interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
> +				status = "disabled";
> +			};
> +
> +			gic: interrupt-controller at 1d00000 {
> +				compatible = "arm,gic-v3";
> +				#interrupt-cells = <3>;
> +				interrupt-controller;
> +				reg = <0x1d00000 0x10000>, /* GICD */
> +				      <0x1d40000 0x40000>; /* GICR */

There's no GICC, GICV, GICH?

Thanks,
Jisheng

> +			};
> +		};
> +	};
> +};



From djkurtz at chromium.org  Tue Feb  2 22:40:47 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Wed, 3 Feb 2016 14:40:47 +0800
Subject: FW: [RFC 3/3] CMDQ: Mediatek CMDQ driver
In-Reply-To: <1454479333.11967.12.camel@mtksdaap41>
References: <8A0FDEEF9DBBD140A3857422D81DA20F867B19FD@mtkmbs01n1>
 <1454479333.11967.12.camel@mtksdaap41>
Message-ID: <CAGS+omABD93f3X0pfiFgaxa9Lob2txkJfUUomUvs+hiRkxSuHw@mail.gmail.com>

> Hi Dan,
>
> Thanks for your comment.
> This solution looks good to me.
> I will change it as your suggestion.
>
> But, I have a question about 'mask out the provided *device virtual*
> address'.
> Are lower 16-bits (or 24-bits for JUMP op) of device virtual address the
> same as device physical address?

I'm not sure.  But I doubt it we can rely on this.
My guess would be that the ioremap only preserves the lower 12 bits
(4k page size).

> If not, we still need to pass in physical address into CMDQ driver.

Or, instead of the iommu/slot approach, we can just provide a
registration function for the gce driver.
Each gce consumer could then have a simple gce node, with no slot/address:

  mediatek,gce = <&gce>;

Then on probe, the gce consumer could pass in its (struct device *) to
gce_register_device().  gce_register_device() could then access the
device's of_node to extract its physical address range, and look up
its physical address in its table of per-soc of
"device_address:gce_subsys_address" entries.  If the physical address
is in a valid subsys ranges, the gce_register_device would cache the
subsys address, and an offset in a (struct gce_consumer).
gce_register_device() could then add this struct to a struct list_head
of gce_consumers, and finally return a pointer to it back to the
caller.

Later, the gce consumer could pass in ths (struct gce_consumer *) when
make gce calls, along with the *offset* (not the physical address or
virtual address) for the register that it wishes to access.  Then the
gce driver can simply use the gce_consumer->subsys entry to create a
gce address from the passed in offset.

This will keep the binding very simple, and would remove the need to
convert from device virtual to physical addresses by the gce consumer,
but require a little more per-gce-consumer setup.

-Dan


From khilman at baylibre.com  Tue Feb  2 22:44:23 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Tue, 2 Feb 2016 22:44:23 -0800
Subject: MTK mt8173-evb: mainline unstable, and big-endian boot failures
In-Reply-To: <1454463498.27798.24.camel@mtksdaap41>
References: <CAOi56cVDbkAJEDWy3+DV63a=UuD7nqpUu8X7e-OjtWM-4dj_-w@mail.gmail.com>
 <7hsi1ilczm.fsf@baylibre.com>
 <CAF-23O3ps0Wt_UCmJbArpc5iJJryJKA0k_2qAyNb7op8O=UnAg@mail.gmail.com>
 <1453964180.26397.8.camel@mtksdaap41> <7hy4b8gc7q.fsf@baylibre.com>
 <1454309376.11974.3.camel@mtksdaap41> <7hh9hrgbbh.fsf@baylibre.com>
 <1454379462.27798.11.camel@mtksdaap41>
 <7h37tbdk6y.fsf@baylibre.com>
 <1454463498.27798.24.camel@mtksdaap41>
Message-ID: <CAOi56cUjbdRwd8qw+UFJGG_F0-a8yx12Uo0Ta_XF_wEZf8OgpQ@mail.gmail.com>

Hi Fan,

On Tue, Feb 2, 2016 at 5:38 PM, Fan Chen <fan.chen at mediatek.com> wrote:

>> Speaking of updated firmware, is there any chance to make the default
>> version of the firmware significantly less noisy.  There is a TON of
>> output from the firmware before fastboot starts which makes the logs for
>> this board very noisy (same complaint on the mt8135.)
>>
> I will discuss with Eddie if it's possible to release a version with
> light logs, but I'm afraid the answer could be given after our Chinese
> New Year vacation. :P

Thank you, it's not a big rush on that feature request, but it will be
helpful whenever you can get to it.  Thanks for looking into it.  I
hope you enjoy your  vacation.

Gu?ni?n h?o  :)

Kevin


From wens at csie.org  Tue Feb  2 22:49:49 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Wed, 3 Feb 2016 14:49:49 +0800
Subject: [linux-sunxi] [PATCH 01/11] MAINTAINERS: Add entry for X-Powers
 AXP family PMIC drivers
In-Reply-To: <1454462910.7291.53.camel@perches.com>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-2-git-send-email-wens@csie.org>
 <CAGRGNgVxan9RCsLFW9hHWcdW+Rd_SgVG95H-yQg213g-YeE6Ug@mail.gmail.com>
 <1454462910.7291.53.camel@perches.com>
Message-ID: <CAGb2v64JfVdSN7VfgDdi2b0ZRKfJsHim=RiGmuvk853LFprF9Q@mail.gmail.com>

On Wed, Feb 3, 2016 at 9:28 AM, Joe Perches <joe at perches.com> wrote:
> On Wed, 2016-02-03 at 11:19 +1100, Julian Calaby wrote:
>> On Tue, Feb 2, 2016 at 9:27 PM, Chen-Yu Tsai <wens at csie.org> wrote:
>> > Add an entry for X-Powers AXP family PMIC drivers and list myself
>> > as maintainer.
> []
>> > diff --git a/MAINTAINERS b/MAINTAINERS
> []
>> > @@ -11941,6 +11941,12 @@ F:     include/linux/workqueue.h
>> >  F:     kernel/workqueue.c
>> >  F:     Documentation/workqueue.txt
>> >
>> > +X-POWERS MULTIFUNCTION PMIC DEVICE DRIVERS
>> > +M:     Chen-Yu Tsai <wens at csie.org>
>> > +L:     linux-kernel at vger.kernel.org
>> > +S:     Maintained
>> > +N:     axp[128]
>>
>> Should you list the files maintained and this list also?
>
> This "N:" pattern is kind of a wildcard.
>
> The difference between F: and N: is that git history
> is also used by default for files that match.
>
> There are no files in -next today that match "*axp8*"
> Dunno if this patchset added any.

This set adds a "axp809.dtsi". A subsequent set will add "axp806.dtsi".

> This matches:
>
>     $ git ls-files | grep "axp[128]"
>     Documentation/devicetree/bindings/mfd/axp20x.txt
>     Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt
>     arch/arm/boot/dts/axp152.dtsi
>     arch/arm/boot/dts/axp209.dtsi
>     arch/arm/boot/dts/axp22x.dtsi
>     drivers/extcon/extcon-axp288.c
>     drivers/iio/adc/axp288_adc.c
>     drivers/input/misc/axp20x-pek.c
>     drivers/mfd/axp20x.c
>     drivers/power/axp20x_usb_power.c
>     drivers/power/axp288_charger.c
>     drivers/power/axp288_fuel_gauge.c
>     drivers/regulator/axp20x-regulator.c
>     include/linux/mfd/axp20x.h
>
> Are all these files appropriate?
>

Yes.

ChenYu


From wens at csie.org  Tue Feb  2 23:02:03 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Wed, 3 Feb 2016 15:02:03 +0800
Subject: [PATCH v2 5/5] pinctrl: sunxi: Use pin number when calling
 sunxi_pmx_set
In-Reply-To: <1454448113-18810-6-git-send-email-k@japko.eu>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
 <1454448113-18810-6-git-send-email-k@japko.eu>
Message-ID: <CAGb2v66+cmHv-NBHCnYcZ_K42qxM=5+kvhazHSy2AykL8cF8tw@mail.gmail.com>

Hi,

On Wed, Feb 3, 2016 at 5:21 AM, Krzysztof Adamski <k at japko.eu> wrote:
> sunxi_pmx_set accepts pin number and then calculates offset by
> subtracting pin_base from it. sunxi_pinctrl_gpio_get, on the other hand,
> gets offset so we have to convert it to pin number so we won't get
> negative value in sunxi_pmx_set.
>
> This was only used on A10 so far, where there is only one GPIO chip with
> pin_base set to 0 so it didn't matter. However H3 also requires this
> workaround but have two pinmux sections, triggering problem for PL port.
>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>
> ---
>  drivers/pinctrl/sunxi/pinctrl-sunxi.c | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> index 7a2465f..9e5bac9 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -460,14 +460,17 @@ static int sunxi_pinctrl_gpio_get(struct gpio_chip *chip, unsigned offset)
>         u32 set_mux = pctl->desc->irq_read_needs_mux &&
>                         test_bit(FLAG_USED_AS_IRQ, &chip->desc[offset].flags);
>         u32 val;
> +       u32 pin;
>
> -       if (set_mux)
> -               sunxi_pmx_set(pctl->pctl_dev, offset, SUN4I_FUNC_INPUT);
> +       if (set_mux) {
> +               pin = offset + pctl->desc->pin_base;

You can use chip->base directly. It's value is set to pin_base in the
init function.
You could also move this out of the if block, and not add the braces.

Otherwise this looks good.

ChenYu

> +               sunxi_pmx_set(pctl->pctl_dev, pin, SUN4I_FUNC_INPUT);
> +       }
>
>         val = (readl(pctl->membase + reg) >> index) & DATA_PINS_MASK;
>
>         if (set_mux)
> -               sunxi_pmx_set(pctl->pctl_dev, offset, SUN4I_FUNC_IRQ);
> +               sunxi_pmx_set(pctl->pctl_dev, pin, SUN4I_FUNC_IRQ);
>
>         return !!val;
>  }
> --
> 2.1.4
>


From ivo.g.dimitrov.75 at gmail.com  Tue Feb  2 23:03:48 2016
From: ivo.g.dimitrov.75 at gmail.com (Ivaylo Dimitrov)
Date: Wed, 3 Feb 2016 09:03:48 +0200
Subject: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
In-Reply-To: <20160203000045.GE19432@atomide.com>
References: <568D5F54.7040900@gmail.com> <20160107180700.GN12777@atomide.com>
 <568EDC8D.7070205@gmail.com> <20160108022619.GS12777@atomide.com>
 <568F4596.8020206@gmail.com> <20160108075913.GN11364@pali>
 <569052FE.1040008@gmail.com> <20160121091437.GT7192@pali>
 <56B077D4.3030902@gmail.com> <20160202233911.GB19432@atomide.com>
 <20160203000045.GE19432@atomide.com>
Message-ID: <56B1A654.1060905@gmail.com>



On  3.02.2016 02:00, Tony Lindgren wrote:
> * Tony Lindgren <tony at atomide.com> [160202 15:40]:
>> * Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com> [160202 01:34]:
>>> On 21.01.2016 11:14, Pali Roh?r wrote:
>>>> On Saturday 09 January 2016 02:23:26 Ivaylo Dimitrov wrote:
>>>>> The key word here is "sometimes". i.e sometimes it hapens on normal reboot,
>>>>> sometimes it happens on oops.
>>>>
>>>> So where is problem? In omap-gpmc? mtd? onenand? or ubifs? Or in
>>>> different component? Do we know at least this?
>>>>
>>>
>>> I think I made some progress on the issue, it seems I have to have *both*
>>> e7b11dc7b77bfce0a351230a5feeadc1d0bba997
>>> (e7b11dc7b77bfce0a351230a5feeadc1d0bba997) reverted *and*
>>> HWMOD_INIT_NO_RESET restored in omap3xxx_gpmc_hwmod flags to have working
>>> onenand.
>>
>> That is strange. This is what I get with omap2plus_defconfig and
>> omap-for-v4.5/fixes-rc1 after flashing the rootfs and booting kernel
>> like you suggested on irc:

What I forgot to tell on IRC is that you should try to boot stock kernel 
after booting mainline. Here it spits a lot of ECC errors (I have 
framebuffer console enabled to see those) and refuses to mount rootfs.

>>
>> # dmesg | grep -i -e ubi -e onenand
>> [    2.502899] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x01000000, virtual base d0940000, freq 83 MHz
>> [    2.514373] OneNAND Manufacturer: Numonyx (0x20)
>> [    2.519287] Muxed OneNAND 256MB 1.8V 16-bit (0x40)
>> [    2.524444] OneNAND version = 0x0031

Exactly the same chip here.

>> [    2.671966] 6 ofpart partitions found on MTD device omap2-onenand
>> [    2.678436] Creating 6 MTD partitions on "omap2-onenand":
>> [    3.414764] ubi0: attaching mtd5
>> [    3.668212] ubi0: scanning is finished
>> [    3.716552] ubi0: attached mtd5 (name "rootfs", size 251 MiB)
>> [    3.722839] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
>> [    3.730194] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
>> [    3.737304] ubi0: VID header offset: 512 (aligned 512), data offset: 2048
>> [    3.744537] ubi0: good PEBs: 2010, bad PEBs: 0, corrupted PEBs: 0
>> [    3.751037] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
>> [    3.758697] ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 0
>> [    3.767578] ubi0: available PEBs: 0, total reserved PEBs: 2010, PEBs reserved for bad PEB handling: 40
>> [    3.923980] ubi0: background thread "ubi_bgt0d" started, PID 85
>> [    3.980529] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 87
>> [    3.996337] UBIFS (ubi0:0): recovery needed
>> [    4.079925] UBIFS (ubi0:0): recovery completed
>> [    4.085876] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs"
>> [    4.093780] UBIFS (ubi0:0): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
>> [    4.104339] UBIFS (ubi0:0): FS size: 252241920 bytes (240 MiB, 1955 LEBs), journal size 9033728 bytes (8 MiB, 71 LEBs)
>> [    4.115722] UBIFS (ubi0:0): reserved for root: 4190434 bytes (4092 KiB)
>> [    4.122772] UBIFS (ubi0:0): media format: w4/r0 (latest is w4/r0), UUID 8F30A88A-F605-4291-9927-00CF3A2AE119, small LPT model
>> [    4.136077] VFS: Mounted root (ubifs filesystem) on device 0:15.
>>
>> I copied over the modules to this rootfs too :) But in general onenand
>> seems to behave for me.
>

Yes, initially it works, but is corrupted after a reboot or two here.

> And ere are my GPCM timings when booted with GPMC_DEBUG
> in case they are different somehow for your device.
>
> Regards,
>
> Tony
>
> omap-gpmc 6e000000.gpmc: GPMC revision 5.0
> GPMC CS0: cs_on            :   0 ticks,   0 ns (was   0 ticks)   0 ns
> GPMC CS0: cs_rd_off        :  14 ticks,  84 ns (was  16 ticks)  84 ns
> GPMC CS0: cs_wr_off        :  19 ticks, 114 ns (was  16 ticks) 114 ns
> GPMC CS0: adv_on           :   0 ticks,   0 ns (was   0 ticks)   0 ns
> GPMC CS0: adv_rd_off       :   3 ticks,  18 ns (was   2 ticks)  18 ns
> GPMC CS0: adv_wr_off       :   3 ticks,  18 ns (was   2 ticks)  18 ns
> GPMC CS0: oe_on            :   5 ticks,  30 ns (was   2 ticks)  30 ns
> GPMC CS0: oe_off           :  14 ticks,  84 ns (was  16 ticks)  84 ns
> GPMC CS0: we_on            :   0 ticks,   0 ns (was   0 ticks)   0 ns
> GPMC CS0: we_off           :  14 ticks,  84 ns (was  16 ticks)  84 ns
> GPMC CS0: rd_cycle         :  18 ticks, 108 ns (was  19 ticks) 108 ns
> GPMC CS0: wr_cycle         :  17 ticks, 102 ns (was  19 ticks) 102 ns
> GPMC CS0: access           :  13 ticks,  78 ns (was  15 ticks)  78 ns
> GPMC CS0: page_burst_access:   0 ticks,   0 ns (was   2 ticks)   0 ns
> GPMC CS0: bus_turnaround   :   0 ticks,   0 ns (was   0 ticks)   0 ns
> GPMC CS0: cycle2cycle_delay:   0 ticks,   0 ns (was   0 ticks)   0 ns
> GPMC CS0: wr_data_mux_bus  :   5 ticks,  30 ns (was   5 ticks)  30 ns
> GPMC CS0: wr_access        :  13 ticks,  78 ns (was  15 ticks)  78 ns
> GPMC CS0: wait_monitoring  :   0 ticks,   0 ns (was   0 ticks)   0 ns
> GPMC CS0: clk_activation   :   0 ticks,   0 ns (was   0 ticks)   0 ns
> GPMC CS0 CLK period is 6 ns (div 1)
> gpmc cs0 after gpmc_cs_set_timings:
> cs0 GPMC_CS_CONFIG1: 0xd9001200
> cs0 GPMC_CS_CONFIG2: 0x00130e00
> cs0 GPMC_CS_CONFIG3: 0x00030300
> cs0 GPMC_CS_CONFIG4: 0x0e000e05
> cs0 GPMC_CS_CONFIG5: 0x000d1112
> cs0 GPMC_CS_CONFIG6: 0x8d050000
> gpmc cs0 access configuration:
> gpmc,mux-add-data = <2>
> gpmc,device-width = <1>
> gpmc,wait-pin = <0>
> gpmc,burst-length = <16>
> gpmc,sync-write = <1>
> gpmc,burst-write = <1>
> gpmc,burst-read = <1>
> gpmc,burst-wrap = <1>
> gpmc cs0 timings configuration:
> gpmc,cs-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
> gpmc,cs-rd-off-ns = <84> /* 79 ns - 84 ns; 14 ticks */
> gpmc,cs-wr-off-ns = <114> /* 109 ns - 114 ns; 19 ticks */
> gpmc,adv-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
> gpmc,adv-rd-off-ns = <18> /* 13 ns - 18 ns; 3 ticks */
> gpmc,adv-wr-off-ns = <18> /* 13 ns - 18 ns; 3 ticks */
> gpmc,oe-on-ns = <30> /* 25 ns - 30 ns; 5 ticks */
> gpmc,oe-off-ns = <84> /* 79 ns - 84 ns; 14 ticks */
> gpmc,we-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
> gpmc,we-off-ns = <84> /* 79 ns - 84 ns; 14 ticks */
> gpmc,rd-cycle-ns = <108> /* 103 ns - 108 ns; 18 ticks */
> gpmc,wr-cycle-ns = <102> /* 97 ns - 102 ns; 17 ticks */
> gpmc,access-ns = <78> /* 73 ns - 78 ns; 13 ticks */
> gpmc,page-burst-access-ns = <0> /* 0 ns - 0 ns; 0 ticks */
> gpmc,bus-turnaround-ns = <0> /* 0 ns - 0 ns; 0 ticks */
> gpmc,cycle2cycle-delay-ns = <0> /* 0 ns - 0 ns; 0 ticks */
> gpmc,wait-monitoring-ns = <0> /* 0 ns - 0 ns; 0 ticks */
> gpmc,clk-activation-ns = <0> /* 0 ns - 0 ns; 0 ticks */
> gpmc,wr-data-mux-bus-ns = <30> /* 25 ns - 30 ns; 5 ticks */
> gpmc,wr-access-ns = <78> /* 73 ns - 78 ns; 13 ticks */
> GPMC CS0: cs_on            :   0 ticks,   0 ns (was   0 ticks)   0 ns
> GPMC CS0: cs_rd_off        :  16 ticks,  96 ns (was  14 ticks)  96 ns
> GPMC CS0: cs_wr_off        :  16 ticks,  96 ns (was  19 ticks)  96 ns
> GPMC CS0: adv_on           :   0 ticks,   0 ns (was   0 ticks)   0 ns
> GPMC CS0: adv_rd_off       :   2 ticks,  12 ns (was   3 ticks)  12 ns
> GPMC CS0: adv_wr_off       :   2 ticks,  12 ns (was   3 ticks)  12 ns
> GPMC CS0: oe_on            :   3 ticks,  18 ns (was   5 ticks)  18 ns
> GPMC CS0: oe_off           :  16 ticks,  96 ns (was  14 ticks)  96 ns
> GPMC CS0: we_on            :   0 ticks,   0 ns (was   0 ticks)   0 ns
> GPMC CS0: we_off           :  16 ticks,  96 ns (was  14 ticks)  96 ns
> GPMC CS0: rd_cycle         :  19 ticks, 114 ns (was  18 ticks) 114 ns
> GPMC CS0: wr_cycle         :  19 ticks, 114 ns (was  17 ticks) 114 ns
> GPMC CS0: access           :  15 ticks,  90 ns (was  13 ticks)  90 ns
> GPMC CS0: page_burst_access:   2 ticks,  12 ns (was   0 ticks)  12 ns
> GPMC CS0: bus_turnaround   :   0 ticks,   0 ns (was   0 ticks)   0 ns
> GPMC CS0: cycle2cycle_delay:   0 ticks,   0 ns (was   0 ticks)   0 ns
> GPMC CS0: wr_data_mux_bus  :   5 ticks,  30 ns (was   5 ticks)  30 ns
> GPMC CS0: wr_access        :  15 ticks,  90 ns (was  13 ticks)  90 ns
> GPMC CS0: wait_monitoring  :   0 ticks,   0 ns (was   0 ticks)   0 ns
> GPMC CS0: clk_activation   :   1 ticks,   6 ns (was   0 ticks)   6 ns
> GPMC CS0 CLK period is 12 ns (div 2)
> gpmc cs0 after gpmc_cs_set_timings:
> cs0 GPMC_CS_CONFIG1: 0xfb001201
> cs0 GPMC_CS_CONFIG2: 0x00101000
> cs0 GPMC_CS_CONFIG3: 0x00020200
> cs0 GPMC_CS_CONFIG4: 0x10001003
> cs0 GPMC_CS_CONFIG5: 0x020f1313
> cs0 GPMC_CS_CONFIG6: 0x8f050000
> gpmc cs0 access configuration:
> gpmc,mux-add-data = <2>
> gpmc,device-width = <1>
> gpmc,wait-pin = <0>
> gpmc,burst-length = <16>
> gpmc,sync-write = <1>
> gpmc,burst-write = <1>
> gpmc,gpmc,sync-read = <1>
> gpmc,burst-read = <1>
> gpmc,burst-wrap = <1>
> gpmc cs0 timings configuration:
> gpmc,cs-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
> gpmc,cs-rd-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */
> gpmc,cs-wr-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */
> gpmc,adv-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
> gpmc,adv-rd-off-ns = <12> /* 7 ns - 12 ns; 2 ticks */
> gpmc,adv-wr-off-ns = <12> /* 7 ns - 12 ns; 2 ticks */
> gpmc,oe-on-ns = <18> /* 13 ns - 18 ns; 3 ticks */
> gpmc,oe-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */
> gpmc,we-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */
> gpmc,we-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */
> gpmc,rd-cycle-ns = <114> /* 109 ns - 114 ns; 19 ticks */
> gpmc,wr-cycle-ns = <114> /* 109 ns - 114 ns; 19 ticks */
> gpmc,access-ns = <90> /* 85 ns - 90 ns; 15 ticks */
> gpmc,page-burst-access-ns = <12> /* 7 ns - 12 ns; 2 ticks */
> gpmc,bus-turnaround-ns = <0> /* 0 ns - 0 ns; 0 ticks */
> gpmc,cycle2cycle-delay-ns = <0> /* 0 ns - 0 ns; 0 ticks */
> gpmc,wait-monitoring-ns = <0> /* 0 ns - 0 ns; 0 ticks */
> gpmc,clk-activation-ns = <6> /* 1 ns - 6 ns; 1 ticks */
> gpmc,wr-data-mux-bus-ns = <30> /* 25 ns - 30 ns; 5 ticks */
> gpmc,wr-access-ns = <90> /* 85 ns - 90 ns; 15 ticks */
> omap2-onenand omap2-onenand: initializing on CS0, phys base 0x04000000, virtual base d0940000, freq 83 MHz
> OneNAND Manufacturer: Numonyx (0x20)
> Muxed OneNAND 256MB 1.8V 16-bit (0x40)
> OneNAND version = 0x0031
> Chip support all block unlock
> Chip has 2 plane
> Scanning device for bad blocks
> 6 ofpart partitions found on MTD device omap2-onenand
> Creating 6 MTD partitions on "omap2-onenand":
> 0x000000000000-0x000000020000 : "bootloader"
> 0x000000020000-0x000000080000 : "config"
> 0x000000080000-0x0000000c0000 : "log"
> mtdoops: ready 43, 6188 (no erase)
> mtdoops: Attached to MTD device 2
> 0x0000000c0000-0x0000002c0000 : "kernel"
> 0x0000002c0000-0x0000004c0000 : "initfs"
> 0x0000004c0000-0x000010000000 : "rootfs"
>

Exactly the same log here, besides "mtdoops: ready 36, 959521164 (no 
erase)", no idea what that "959521164" is supposed to mean.

May I ask you to send me the full boot log with omap2plus_defconfig 
kernel booting mtd5 maemo rootfs, until it restarts and the next boot 
log with the stock kernel. It could be there is some other driver acting 
here (g_nokia for example) you don't have enabled in your config.

I will play a bit more with omap2plus_defconfig here in attempt to make 
it boot, to see if I can recreate the issue.

Also, I looked at the TRM and GPMC has more stuff than timings, like 
PRFETCH and ECC. Will dump those with and without HWMOD_INIT_NO_RESET to 
see if there is any difference.

Thanks,
Ivo


From wens at csie.org  Tue Feb  2 23:04:25 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Wed, 3 Feb 2016 15:04:25 +0800
Subject: [PATCH v2 1/5] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <1454448113-18810-2-git-send-email-k@japko.eu>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
 <1454448113-18810-2-git-send-email-k@japko.eu>
Message-ID: <CAGb2v65pKkXXsFg6Yki_OPBb7C0us5DDGBMtbOwb1tVR7oi9Uw@mail.gmail.com>

On Wed, Feb 3, 2016 at 5:21 AM, Krzysztof Adamski <k at japko.eu> wrote:
> This patch adds support for APB0 in H3. It seems to be compatible with
> earlier SOCs. apb0 gates controls R_ block peripherals (R_PIO, R_IR,
> etc).
>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
>  drivers/clk/sunxi/clk-simple-gates.c              | 2 ++
>  2 files changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index e59f57b..6ee6875 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -32,6 +32,7 @@ Required properties:
>         "allwinner,sun8i-h3-ahb2-clk" - for the AHB2 clock on H3
>         "allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
>         "allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
> +       "allwinner,sun8i-h3-abp0-gates-clk" - for the APB0 gates on H3

The list is grouped by clock type (AHB/APB/...) then family then SoC.
Please put this in the apb0 section below.

ChenYu

>         "allwinner,sun9i-a80-ahb0-gates-clk" - for the AHB0 gates on A80
>         "allwinner,sun9i-a80-ahb1-gates-clk" - for the AHB1 gates on A80
>         "allwinner,sun9i-a80-ahb2-gates-clk" - for the AHB2 gates on A80
> diff --git a/drivers/clk/sunxi/clk-simple-gates.c b/drivers/clk/sunxi/clk-simple-gates.c
> index f4da52b..8a1fa3e 100644
> --- a/drivers/clk/sunxi/clk-simple-gates.c
> +++ b/drivers/clk/sunxi/clk-simple-gates.c
> @@ -130,6 +130,8 @@ CLK_OF_DECLARE(sun8i_a23_apb2, "allwinner,sun8i-a23-apb2-gates-clk",
>                sunxi_simple_gates_init);
>  CLK_OF_DECLARE(sun8i_a33_ahb1, "allwinner,sun8i-a33-ahb1-gates-clk",
>                sunxi_simple_gates_init);
> +CLK_OF_DECLARE(sun8i_h3_abp0, "allwinner,sun8i-h3-abp0-gates-clk",
> +              sunxi_simple_gates_init);
>  CLK_OF_DECLARE(sun9i_a80_ahb0, "allwinner,sun9i-a80-ahb0-gates-clk",
>                sunxi_simple_gates_init);
>  CLK_OF_DECLARE(sun9i_a80_ahb1, "allwinner,sun9i-a80-ahb1-gates-clk",
> --
> 2.1.4
>


From codekipper at gmail.com  Tue Feb  2 23:26:34 2016
From: codekipper at gmail.com (Code Kipper)
Date: Wed, 3 Feb 2016 08:26:34 +0100
Subject: [PATCH v3 1/2] dt-bindings: add sun4i SPDIF transceiver bindings
In-Reply-To: <20160202223115.GE4652@lukather>
References: <1454424594-25208-1-git-send-email-codekipper@gmail.com>
 <1454424594-25208-2-git-send-email-codekipper@gmail.com>
 <20160202223115.GE4652@lukather>
Message-ID: <CAEKpxBnSAocmQX=x2mtzL2YtNziSZYRkNxsdaqW_mMsGcG=Z9w@mail.gmail.com>

On 2 February 2016 at 23:31, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> Hi,
>
> On Tue, Feb 02, 2016 at 03:49:53PM +0100, codekipper at gmail.com wrote:
>> From: Marcus Cooper <codekipper at gmail.com>
>>
>> Add devicetree bindings for the SPDIF transceiver found on
>> found on Allwinners A10 and A20 SoCs.
>>
>> Signed-off-by: Marcus Cooper <codekipper at gmail.com>
>> ---
>>  .../devicetree/bindings/sound/sun4i,spdif.txt      | 46 ++++++++++++++++++++++
>>  1 file changed, 46 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/sound/sun4i,spdif.txt
>>
>> diff --git a/Documentation/devicetree/bindings/sound/sun4i,spdif.txt b/Documentation/devicetree/bindings/sound/sun4i,spdif.txt
>> new file mode 100644
>> index 0000000..55ed2f6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/sound/sun4i,spdif.txt
>> @@ -0,0 +1,46 @@
>> +Allwinner Sony/Philips Digital Interface Format (S/PDIF) Controller
>> +
>> +The Allwinner S/PDIF audio block is a transceiver that allows the
>> +processor to receive and transmit digital audio via an coaxial cable or
>> +a fibre cable.
>> +
>> +Required properties:
>> +
>> +  - compatible               : should be one of the following:
>> +    - "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC
>> +
>> +  - reg                      : Offset and length of the register set for the device.
>> +
>> +  - interrupts               : Contains the spdif interrupt.
>> +
>> +  - dmas             : Generic dma devicetree binding as described in
>> +                       Documentation/devicetree/bindings/dma/dma.txt.
>> +
>> +  - dma-names                : Two dmas have to be defined, "tx" and "rx".
>> +
>> +  - clocks           : Contains an entry for each entry in clock-names.
>> +
>> +  - clock-names              : Includes the following entries:
>> +     "apb"             clock for the spdif bus.
>> +     "spdif"           clock for spdif controller.
>> +
>> +Optional:
>> +
>> +  - spdif-in         : Enable block for capturing an SPDIF signal.
>> +
>> +  - spdif-out                : Enable block for transmitting an SPDIF signal.
>
> Is that a generic property? What values can it hold?
Hi Maxime,

thanks for the review. I'm starting to prep a v4 patch series and I'm
here wondering if I should drop the spdif-in/out for now and just rely
on the status property to enable playback. It would simplify the
driver even more and it could be added back when someone gets around
to delivering spdif capture. I think that's going to be pretty low on
my list of things to do as I've only got one dev board where it's
possible.
BR,
Lazy Lazy CK
>
> Thanks,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com


From isubramanian at apm.com  Tue Feb  2 23:55:12 2016
From: isubramanian at apm.com (Iyappan Subramanian)
Date: Tue,  2 Feb 2016 23:55:12 -0800
Subject: [PATCH net-next 0/4] Add support for Classifier and RSS
Message-ID: <1454486116-23783-1-git-send-email-isubramanian@apm.com>

This patch series enables 

(i) Classifier engine that is used for parsing
through the packet and extracting a search string that is then used
to search a database to find associative data.

(ii) Receive Side Scaling (RSS) that does dynamic load
balancing of the CPUs by controlling the number of messages enqueued
per CPU though the help of Toeplitz Hash function of 4-tuple of
source TCP/UDP port, destination TCP/UDP port, source IPV4 address and
destination IPV4 address.

(iii) Multi queue, to make advantage of RSS

---
Iyappan Subramanian (4):
  drivers: net: xgene: Add support for Classifier engine
  drivers: net: xgene: Add support for RSS
  drivers: net: xgene: Add support for multiple queues
  dtb: xgene: Add irqs to support multi queue

 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi       |   8 +-
 arch/arm64/boot/dts/apm/apm-storm.dtsi           |   8 +-
 drivers/net/ethernet/apm/xgene/Makefile          |   3 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c  | 734 +++++++++++++++++++++++
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.h  | 316 ++++++++++
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h   |   1 +
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 481 +++++++++------
 drivers/net/ethernet/apm/xgene/xgene_enet_main.h |  34 +-
 8 files changed, 1385 insertions(+), 200 deletions(-)
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_cle.h

-- 
1.9.1



From isubramanian at apm.com  Tue Feb  2 23:55:14 2016
From: isubramanian at apm.com (Iyappan Subramanian)
Date: Tue,  2 Feb 2016 23:55:14 -0800
Subject: [PATCH net-next 2/4] drivers: net: xgene: Add support for RSS
In-Reply-To: <1454486116-23783-1-git-send-email-isubramanian@apm.com>
References: <1454486116-23783-1-git-send-email-isubramanian@apm.com>
Message-ID: <1454486116-23783-3-git-send-email-isubramanian@apm.com>

Signed-off-by: Iyappan Subramanian <isubramanian at apm.com>
Signed-off-by: Khuong Dinh <kdinh at apm.com>
Signed-off-by: Tanmay Inamdar <tinamdar at apm.com>
Tested-by: Toan Le <toanle at apm.com>
---
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c | 386 +++++++++++++++++++++++-
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.h |  52 ++++
 2 files changed, 433 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
index 7eea982..d51268f 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
@@ -21,6 +21,25 @@
 
 #include "xgene_enet_main.h"
 
+/* interfaces to convert structures to HW recognized bit formats */
+static void xgene_cle_sband_to_hw(u8 frag, enum xgene_cle_prot_version ver,
+				  enum xgene_cle_prot_type type, u32 len,
+				  u32 *reg)
+{
+	*reg =  XGENE_CLE_RSS_WR(SB_IPFRAG, frag) |
+		XGENE_CLE_RSS_WR(SB_IPPROT, type) |
+		XGENE_CLE_RSS_WR(SB_IPVER, ver) |
+		XGENE_CLE_RSS_WR(SB_HDRLEN, len);
+}
+
+static void xgene_cle_idt_to_hw(u32 dstqid, u32 fpsel,
+				u32 nfpsel, u32 *idt_reg)
+{
+	*idt_reg =  XGENE_CLE_RSS_WR(IDT_DSTQID, dstqid) |
+		    XGENE_CLE_RSS_WR(IDT_FPSEL, fpsel) |
+		    XGENE_CLE_RSS_WR(IDT_NFPSEL, nfpsel);
+}
+
 static void xgene_cle_dbptr_to_hw(struct xgene_enet_pdata *pdata,
 				  struct xgene_cle_dbptr *dbptr, u32 *buf)
 {
@@ -258,29 +277,372 @@ static void xgene_cle_setup_def_dbptr(struct xgene_enet_pdata *pdata,
 	}
 }
 
+static int xgene_cle_set_rss_sband(struct xgene_enet_cle *cle)
+{
+	u32 sband, reg = 0;
+	u32 idx = CLE_PKTRAM_SIZE / sizeof(u32);
+	u32 mac_hdr_len = 14;
+	u32 ipv4_ihl = 5;
+	u32 hdr_len;
+	int ret;
+
+	/* Sideband: IPV4/TCP packets */
+	hdr_len = (mac_hdr_len << 5) | ipv4_ihl;
+	xgene_cle_sband_to_hw(0, XGENE_CLE_IPV4, XGENE_CLE_TCP, hdr_len, &reg);
+	sband = reg;
+
+	/* Sideband: IPv4/UDP packets */
+	hdr_len = (mac_hdr_len << 5) | ipv4_ihl;
+	xgene_cle_sband_to_hw(1, XGENE_CLE_IPV4, XGENE_CLE_UDP, hdr_len, &reg);
+	sband |= (reg << 16);
+
+	ret = xgene_cle_dram_wr(cle, &sband, 1, idx, PKT_RAM, CLE_CMD_WR);
+	if (ret)
+		return ret;
+
+	/* Sideband: IPv4/RAW packets */
+	hdr_len = (mac_hdr_len << 5) | ipv4_ihl;
+	xgene_cle_sband_to_hw(0, XGENE_CLE_IPV4, XGENE_CLE_OTHER,
+			      hdr_len, &reg);
+	sband = reg;
+
+	/* Sideband: Ethernet II/RAW packets */
+	hdr_len = (mac_hdr_len << 5);
+	xgene_cle_sband_to_hw(0, XGENE_CLE_IPV4, XGENE_CLE_OTHER,
+			      hdr_len, &reg);
+	sband |= (reg << 16);
+
+	ret = xgene_cle_dram_wr(cle, &sband, 1, idx + 1, PKT_RAM, CLE_CMD_WR);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int xgene_cle_set_rss_skeys(struct xgene_enet_cle *cle)
+{
+	int ret = 0;
+	u32 secret_key_ipv4[4];  /* 16 Bytes*/
+
+	get_random_bytes(secret_key_ipv4, 16);
+	ret = xgene_cle_dram_wr(cle, secret_key_ipv4, 4, 0,
+				RSS_IPV4_HASH_SKEY, CLE_CMD_WR);
+	return ret;
+}
+
+static int xgene_cle_set_rss_idt(struct xgene_enet_pdata *pdata)
+{
+	int i, ret = 0;
+	u32 fpsel, dstqid, nfpsel, idt_reg;
+	u16 pool_id;
+
+	for (i = 0; i < XGENE_CLE_IDT_ENTRIES; i++) {
+		pool_id = pdata->rx_ring->buf_pool->id;
+		fpsel = xgene_enet_ring_bufnum(pool_id) - 0x20;
+		dstqid = xgene_enet_dst_ring_num(pdata->rx_ring);
+		nfpsel = 0;
+		idt_reg = 0;
+
+		xgene_cle_idt_to_hw(dstqid, fpsel, nfpsel, &idt_reg);
+		ret = xgene_cle_dram_wr(&pdata->cle, &idt_reg, 1, i,
+					RSS_IDT, CLE_CMD_WR);
+		if (ret)
+			return ret;
+	}
+
+	ret = xgene_cle_set_rss_skeys(&pdata->cle);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int xgene_cle_setup_rss(struct xgene_enet_pdata *pdata)
+{
+	struct xgene_enet_cle *cle = &pdata->cle;
+	void __iomem *base = cle->base;
+	u32 offset, val = 0;
+	int i, ret = 0;
+
+	offset = CLE_PORT_OFFSET;
+	for (i = 0; i < cle->parsers; i++) {
+		if (cle->active_parser != PARSER_ALL)
+			offset = cle->active_parser * CLE_PORT_OFFSET;
+		else
+			offset = i * CLE_PORT_OFFSET;
+
+		/* enable RSS */
+		val = (RSS_IPV4_12B << 1) | 0x1;
+		writel(val, base + RSS_CTRL0 + offset);
+	}
+
+	/* setup sideband data */
+	ret = xgene_cle_set_rss_sband(cle);
+	if (ret)
+		return ret;
+
+	/* setup indirection table */
+	ret = xgene_cle_set_rss_idt(pdata);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
 static int xgene_enet_cle_init(struct xgene_enet_pdata *pdata)
 {
 	struct xgene_enet_cle *enet_cle = &pdata->cle;
 	struct xgene_cle_ptree *ptree = &enet_cle->ptree;
 	struct xgene_cle_dbptr dbptr[DB_MAX_PTRS];
 	struct xgene_cle_ptree_kn kn;
+	struct xgene_cle_ptree_branch *br;
 	u32 def_qid, def_fpsel, pool_id;
+	int ret;
 	struct xgene_cle_ptree_ewdn ptree_dn[] = {
 		{
 			/* PKT_TYPE_NODE */
 			.node_type = EWDN,
 			.last_node = 0,
-			.hdr_len_store = 0,
+			.hdr_len_store = 1,
 			.hdr_extn = NO_BYTE,
 			.byte_store = NO_BYTE,
 			.search_byte_store = NO_BYTE,
 			.result_pointer = DB_RES_DROP,
-			.num_branches = 1,
+			.num_branches = 2,
 			.branch = {
 				{
-					/* Allow all packet type */
+					/* IPV4 */
 					.valid = 0,
-					.next_packet_pointer = 0,
+					.next_packet_pointer = 22,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = PKT_PROT_NODE,
+					.next_branch = 0,
+					.data = 0x8,
+					.mask = 0xffff
+				},
+				{
+					.valid = 0,
+					.next_packet_pointer = 262,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = LAST_NODE,
+					.next_branch = 0,
+					.data = 0x0,
+					.mask = 0xffff
+				}
+			},
+		},
+		{
+			/* PKT_PROT_NODE */
+			.node_type = EWDN,
+			.last_node = 0,
+			.hdr_len_store = 1,
+			.hdr_extn = NO_BYTE,
+			.byte_store = NO_BYTE,
+			.search_byte_store = NO_BYTE,
+			.result_pointer = DB_RES_DROP,
+			.num_branches = 3,
+			.branch = {
+				{
+					/* TCP */
+					.valid = 1,
+					.next_packet_pointer = 26,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 0,
+					.data = 0x0600,
+					.mask = 0xffff
+				},
+				{
+					/* UDP */
+					.valid = 1,
+					.next_packet_pointer = 26,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 0,
+					.data = 0x1100,
+					.mask = 0xffff
+				},
+				{
+					.valid = 0,
+					.next_packet_pointer = 260,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = LAST_NODE,
+					.next_branch = 0,
+					.data = 0x0,
+					.mask = 0xffff
+				}
+			}
+		},
+		{
+			/* RSS_IPV4_TCP_NODE */
+			.node_type = EWDN,
+			.last_node = 0,
+			.hdr_len_store = 1,
+			.hdr_extn = NO_BYTE,
+			.byte_store = NO_BYTE,
+			.search_byte_store = BOTH_BYTES,
+			.result_pointer = DB_RES_DROP,
+			.num_branches = 6,
+			.branch = {
+				{
+					/* SRC IPV4 B01 */
+					.valid = 0,
+					.next_packet_pointer = 28,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 1,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* SRC IPV4 B23 */
+					.valid = 0,
+					.next_packet_pointer = 30,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 2,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* DST IPV4 B01 */
+					.valid = 0,
+					.next_packet_pointer = 32,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 3,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* DST IPV4 B23 */
+					.valid = 0,
+					.next_packet_pointer = 34,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 4,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* TCP SRC Port */
+					.valid = 0,
+					.next_packet_pointer = 36,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 5,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* TCP DST Port */
+					.valid = 0,
+					.next_packet_pointer = 256,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = LAST_NODE,
+					.next_branch = 0,
+					.data = 0x0,
+					.mask = 0xffff
+				}
+			}
+		},
+		{
+			/* RSS_IPV4_UDP_NODE */
+			.node_type = EWDN,
+			.last_node = 0,
+			.hdr_len_store = 1,
+			.hdr_extn = NO_BYTE,
+			.byte_store = NO_BYTE,
+			.search_byte_store = BOTH_BYTES,
+			.result_pointer = DB_RES_DROP,
+			.num_branches = 6,
+			.branch = {
+				{
+					/* SRC IPV4 B01 */
+					.valid = 0,
+					.next_packet_pointer = 28,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 1,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* SRC IPV4 B23 */
+					.valid = 0,
+					.next_packet_pointer = 30,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 2,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* DST IPV4 B01 */
+					.valid = 0,
+					.next_packet_pointer = 32,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 3,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* DST IPV4 B23 */
+					.valid = 0,
+					.next_packet_pointer = 34,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 4,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* TCP SRC Port */
+					.valid = 0,
+					.next_packet_pointer = 36,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 5,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* TCP DST Port */
+					.valid = 0,
+					.next_packet_pointer = 256,
 					.jump_bw = JMP_FW,
 					.jump_rel = JMP_ABS,
 					.operation = EQT,
@@ -295,7 +657,7 @@ static int xgene_enet_cle_init(struct xgene_enet_pdata *pdata)
 			/* LAST NODE */
 			.node_type = EWDN,
 			.last_node = 1,
-			.hdr_len_store = 0,
+			.hdr_len_store = 1,
 			.hdr_extn = NO_BYTE,
 			.byte_store = NO_BYTE,
 			.search_byte_store = NO_BYTE,
@@ -318,6 +680,20 @@ static int xgene_enet_cle_init(struct xgene_enet_pdata *pdata)
 	};
 
 	ptree->start_pkt = 12; /* Ethertype */
+	if (pdata->phy_mode == PHY_INTERFACE_MODE_XGMII) {
+		ret = xgene_cle_setup_rss(pdata);
+		if (ret) {
+			netdev_err(pdata->ndev, "RSS initialization failed\n");
+			return ret;
+		}
+	} else {
+		br = &ptree_dn[PKT_PROT_NODE].branch[0];
+		br->valid = 0;
+		br->next_packet_pointer = 260;
+		br->next_node = NEXT_NODE(LAST_NODE);
+		br->data = 0x0000;
+		br->mask = 0xffff;
+	}
 
 	def_qid = xgene_enet_dst_ring_num(pdata->rx_ring);
 	pool_id = pdata->rx_ring->buf_pool->id;
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h
index 9696a57..a12ac8c 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h
@@ -34,6 +34,7 @@
 #define SPPTR0			0x0104
 #define DFCLSRESDBPTR0		0x0108
 #define DFCLSRESDB00		0x010c
+#define RSS_CTRL0		0x0000013c
 
 #define CLE_CMD_TO		10	/* ms */
 #define CLE_PKTRAM_SIZE		256	/* bytes */
@@ -108,6 +109,9 @@
 
 enum xgene_cle_ptree_nodes {
 	PKT_TYPE_NODE,
+	PKT_PROT_NODE,
+	RSS_IPV4_TCP_NODE,
+	RSS_IPV4_UDP_NODE,
 	LAST_NODE,
 	MAX_NODES
 };
@@ -147,6 +151,8 @@ enum xgene_cle_parser {
 #define XGENE_CLE_DRAM(type)	(((type) & 0xf) << 28)
 enum xgene_cle_dram_type {
 	PKT_RAM,
+	RSS_IDT,
+	RSS_IPV4_HASH_SKEY,
 	PTREE_RAM = 0xc,
 	AVL_RAM,
 	DB_RAM
@@ -160,6 +166,22 @@ enum xgene_cle_cmd_type {
 	CLE_CMD_AVL_SRCH = 32
 };
 
+enum xgene_cle_ipv4_rss_hashtype {
+	RSS_IPV4_8B,
+	RSS_IPV4_12B,
+};
+
+enum xgene_cle_prot_type {
+	XGENE_CLE_TCP,
+	XGENE_CLE_UDP,
+	XGENE_CLE_ESP,
+	XGENE_CLE_OTHER
+};
+
+enum xgene_cle_prot_version {
+	XGENE_CLE_IPV4,
+};
+
 enum xgene_cle_ptree_dbptrs {
 	DB_RES_DROP,
 	DB_RES_DEF,
@@ -167,6 +189,36 @@ enum xgene_cle_ptree_dbptrs {
 	DB_MAX_PTRS
 };
 
+/* RSS sideband signal info */
+#define XGENE_CLE_SB_IPFRAG_WIDTH	1
+#define XGENE_CLE_SB_IPFRAG_SHIFT	0
+#define XGENE_CLE_SB_IPPROT_WIDTH	2
+#define XGENE_CLE_SB_IPPROT_SHIFT	1
+#define XGENE_CLE_SB_IPVER_WIDTH	1
+#define XGENE_CLE_SB_IPVER_SHIFT	3
+#define XGENE_CLE_SB_HDRLEN_WIDTH	12
+#define XGENE_CLE_SB_HDRLEN_SHIFT	4
+
+/* RSS indirection table */
+#define XGENE_CLE_IDT_ENTRIES		128
+#define XGENE_CLE_IDT_DSTQID_WIDTH	12
+#define XGENE_CLE_IDT_DSTQID_SHIFT	0
+#define XGENE_CLE_IDT_FPSEL_WIDTH	4
+#define XGENE_CLE_IDT_FPSEL_SHIFT	12
+#define XGENE_CLE_IDT_NFPSEL_WIDTH	4
+#define XGENE_CLE_IDT_NFPSEL_SHIFT	16
+
+/* RSS access macros */
+#define XGENE_CLE_RSS_MASK(field)	(((2 << \
+					(XGENE_CLE_##field##_WIDTH - 1)) - 1) \
+					<< XGENE_CLE_##field##_SHIFT)
+#define XGENE_CLE_RSS_RD(field, word)	(((word) & \
+					XGENE_CLE_RSS_MASK(field)) >> \
+					XGENE_CLE_##field##_SHIFT)
+#define XGENE_CLE_RSS_WR(field, word)	(((word) << \
+					XGENE_CLE_##field##_SHIFT) & \
+					XGENE_CLE_RSS_MASK(field))
+
 struct xgene_cle_ptree_branch {
 	bool valid;
 	u16 next_packet_pointer;
-- 
1.9.1



From isubramanian at apm.com  Tue Feb  2 23:55:16 2016
From: isubramanian at apm.com (Iyappan Subramanian)
Date: Tue,  2 Feb 2016 23:55:16 -0800
Subject: [PATCH net-next 4/4] dtb: xgene: Add irqs to support multi queue
In-Reply-To: <1454486116-23783-1-git-send-email-isubramanian@apm.com>
References: <1454486116-23783-1-git-send-email-isubramanian@apm.com>
Message-ID: <1454486116-23783-5-git-send-email-isubramanian@apm.com>

Signed-off-by: Iyappan Subramanian <isubramanian at apm.com>
Signed-off-by: Khuong Dinh <kdinh at apm.com>
Signed-off-by: Tanmay Inamdar <tinamdar at apm.com>
Tested-by: Toan Le <toanle at apm.com>
---
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 8 +++++++-
 arch/arm64/boot/dts/apm/apm-storm.dtsi     | 8 +++++++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index 5d87a3d..278f106 100644
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -621,7 +621,13 @@
 			      <0x0 0x1f600000 0x0 0Xd100>,
 			      <0x0 0x20000000 0x0 0X220000>;
 			interrupts = <0 108 4>,
-				     <0 109 4>;
+				     <0 109 4>,
+				     <0 110 4>,
+				     <0 111 4>,
+				     <0 112 4>,
+				     <0 113 4>,
+				     <0 114 4>,
+				     <0 115 4>;
 			port-id = <1>;
 			dma-coherent;
 			clocks = <&xge1clk 0>;
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index fe30f76..cafb2c2 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -958,7 +958,13 @@
 			      <0x0 0x18000000 0x0 0X200>;
 			reg-names = "enet_csr", "ring_csr", "ring_cmd";
 			interrupts = <0x0 0x60 0x4>,
-				     <0x0 0x61 0x4>;
+				     <0x0 0x61 0x4>,
+				     <0x0 0x62 0x4>,
+				     <0x0 0x63 0x4>,
+				     <0x0 0x64 0x4>,
+				     <0x0 0x65 0x4>,
+				     <0x0 0x66 0x4>,
+				     <0x0 0x67 0x4>;
 			dma-coherent;
 			clocks = <&xge0clk 0>;
 			/* mac address will be overwritten by the bootloader */
-- 
1.9.1



From isubramanian at apm.com  Tue Feb  2 23:55:13 2016
From: isubramanian at apm.com (Iyappan Subramanian)
Date: Tue,  2 Feb 2016 23:55:13 -0800
Subject: [PATCH net-next 1/4] drivers: net: xgene: Add support for Classifier
 engine
In-Reply-To: <1454486116-23783-1-git-send-email-isubramanian@apm.com>
References: <1454486116-23783-1-git-send-email-isubramanian@apm.com>
Message-ID: <1454486116-23783-2-git-send-email-isubramanian@apm.com>

Signed-off-by: Iyappan Subramanian <isubramanian at apm.com>
Signed-off-by: Khuong Dinh <kdinh at apm.com>
Signed-off-by: Tanmay Inamdar <tinamdar at apm.com>
Tested-by: Toan Le <toanle at apm.com>
---
 drivers/net/ethernet/apm/xgene/Makefile          |   3 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c  | 357 +++++++++++++++++++++++
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.h  | 264 +++++++++++++++++
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h   |   1 +
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c |  29 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_main.h |  14 +
 6 files changed, 659 insertions(+), 9 deletions(-)
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_cle.h

diff --git a/drivers/net/ethernet/apm/xgene/Makefile b/drivers/net/ethernet/apm/xgene/Makefile
index 700b5ab..f46321f 100644
--- a/drivers/net/ethernet/apm/xgene/Makefile
+++ b/drivers/net/ethernet/apm/xgene/Makefile
@@ -3,5 +3,6 @@
 #
 
 xgene-enet-objs := xgene_enet_hw.o xgene_enet_sgmac.o xgene_enet_xgmac.o \
-		   xgene_enet_main.o xgene_enet_ring2.o xgene_enet_ethtool.o
+		   xgene_enet_main.o xgene_enet_ring2.o xgene_enet_ethtool.o \
+		   xgene_enet_cle.o
 obj-$(CONFIG_NET_XGENE) += xgene-enet.o
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
new file mode 100644
index 0000000..7eea982
--- /dev/null
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
@@ -0,0 +1,357 @@
+/* Applied Micro X-Gene SoC Ethernet Classifier structures
+ *
+ * Copyright (c) 2016, Applied Micro Circuits Corporation
+ * Authors: Khuong Dinh <kdinh at apm.com>
+ *          Tanmay Inamdar <tinamdar at apm.com>
+ *          Iyappan Subramanian <isubramanian at apm.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * 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 "xgene_enet_main.h"
+
+static void xgene_cle_dbptr_to_hw(struct xgene_enet_pdata *pdata,
+				  struct xgene_cle_dbptr *dbptr, u32 *buf)
+{
+	buf[4] = SET_VAL(CLE_FPSEL, dbptr->fpsel) |
+		 SET_VAL(CLE_DSTQIDL, dbptr->dstqid);
+
+	buf[5] = SET_VAL(CLE_DSTQIDH, (u32)dbptr->dstqid >> CLE_DSTQIDL_LEN) |
+		 SET_VAL(CLE_PRIORITY, dbptr->cle_priority);
+}
+
+static void xgene_cle_kn_to_hw(struct xgene_cle_ptree_kn *kn, u32 *buf)
+{
+	u32 i, j = 0;
+	u32 data;
+
+	buf[j++] = SET_VAL(CLE_TYPE, kn->node_type);
+	for (i = 0; i < kn->num_keys; i++) {
+		struct xgene_cle_ptree_key *key = &kn->key[i];
+
+		if (!(i % 2)) {
+			buf[j] = SET_VAL(CLE_KN_PRIO, key->priority) |
+				 SET_VAL(CLE_KN_RPTR, key->result_pointer);
+		} else {
+			data = SET_VAL(CLE_KN_PRIO, key->priority) |
+			       SET_VAL(CLE_KN_RPTR, key->result_pointer);
+			buf[j++] |= (data << 16);
+		}
+	}
+}
+
+static void xgene_cle_dn_to_hw(struct xgene_cle_ptree_ewdn *dn,
+			       u32 *buf, u32 jb)
+{
+	u32 i, j = 0;
+	u32 npp;
+	struct xgene_cle_ptree_branch *br;
+
+	buf[j++] = SET_VAL(CLE_DN_TYPE, dn->node_type) |
+		   SET_VAL(CLE_DN_LASTN, dn->last_node) |
+		   SET_VAL(CLE_DN_HLS, dn->hdr_len_store) |
+		   SET_VAL(CLE_DN_EXT, dn->hdr_extn) |
+		   SET_VAL(CLE_DN_BSTOR, dn->byte_store) |
+		   SET_VAL(CLE_DN_SBSTOR, dn->search_byte_store) |
+		   SET_VAL(CLE_DN_RPTR, dn->result_pointer);
+
+	for (i = 0; i < dn->num_branches; i++) {
+		br = &dn->branch[i];
+		npp = br->next_packet_pointer;
+
+		if ((br->jump_rel == JMP_ABS) && (npp < CLE_PKTRAM_SIZE))
+			npp += jb;
+
+		buf[j++] = SET_VAL(CLE_BR_VALID, br->valid) |
+			   SET_VAL(CLE_BR_NPPTR, npp) |
+			   SET_VAL(CLE_BR_JB, br->jump_bw) |
+			   SET_VAL(CLE_BR_JR, br->jump_rel) |
+			   SET_VAL(CLE_BR_OP, br->operation) |
+			   SET_VAL(CLE_BR_NNODE, br->next_node) |
+			   SET_VAL(CLE_BR_NBR, br->next_branch);
+
+		buf[j++] = SET_VAL(CLE_BR_DATA, br->data) |
+			   SET_VAL(CLE_BR_MASK, br->mask);
+	}
+}
+
+static int xgene_cle_poll_cmd_done(void __iomem *base,
+				   enum xgene_cle_cmd_type cmd)
+{
+	u32 status, loop = 10;
+	int ret = -EBUSY;
+
+	while (loop--) {
+		status = ioread32(base + INDCMD_STATUS);
+		if (status & cmd) {
+			ret = 0;
+			break;
+		}
+		usleep_range(1000, 2000);
+	}
+
+	return ret;
+}
+
+static int xgene_cle_dram_wr(struct xgene_enet_cle *cle, u32 *data, u8 nregs,
+			     u32 index, enum xgene_cle_dram_type type,
+			     enum xgene_cle_cmd_type cmd)
+{
+	void __iomem *base = cle->base;
+	enum xgene_cle_parser parser = cle->active_parser;
+	u32 i, j, ind_addr;
+	u8 port, nparsers;
+	int ret = 0;
+
+	/* PTREE_RAM onwards, DRAM regions are common for all parsers */
+	nparsers = (type >= PTREE_RAM) ? 1 : cle->parsers;
+
+	for (i = 0; i < nparsers; i++) {
+		port = i;
+		if ((type < PTREE_RAM) && (parser != PARSER_ALL))
+			port = parser;
+
+		ind_addr = XGENE_CLE_DRAM(type + (port * 4)) | index;
+		iowrite32(ind_addr, base + INDADDR);
+		for (j = 0; j < nregs; j++)
+			iowrite32(data[j], base + DATA_RAM0 + (j * 4));
+		iowrite32(cmd, base + INDCMD);
+
+		ret = xgene_cle_poll_cmd_done(base, cmd);
+		if (ret)
+			break;
+	}
+
+	return ret;
+}
+
+static void xgene_cle_enable_ptree(struct xgene_enet_pdata *pdata,
+				   struct xgene_enet_cle *cle)
+{
+	struct xgene_cle_ptree *ptree = &cle->ptree;
+	void __iomem *addr, *base = cle->base;
+	u32 offset = CLE_PORT_OFFSET;
+	u32 i;
+
+	/* 1G port has to advance 4 bytes and 10G has to advance 8 bytes */
+	ptree->start_pkt += cle->jump_bytes;
+	for (i = 0; i < cle->parsers; i++) {
+		if (cle->active_parser != PARSER_ALL)
+			addr = base + cle->active_parser * offset;
+		else
+			addr = base + (i * offset);
+
+		iowrite32(ptree->start_node & 0x3fff, addr + SNPTR0);
+		iowrite32(ptree->start_pkt & 0x1ff, addr + SPPTR0);
+	}
+}
+
+static int xgene_cle_setup_dbptr(struct xgene_enet_pdata *pdata,
+				 struct xgene_enet_cle *cle)
+{
+	struct xgene_cle_ptree *ptree = &cle->ptree;
+	struct xgene_cle_dbptr *dbptr = ptree->dbptr;
+	u32 buf[CLE_DRAM_REGS];
+	u32 i;
+	int ret;
+
+	memset(buf, 0, sizeof(buf));
+	for (i = 0; i < ptree->num_dbptr; i++) {
+		xgene_cle_dbptr_to_hw(pdata, &dbptr[i], buf);
+		ret = xgene_cle_dram_wr(cle, buf, 6, i + ptree->start_dbptr,
+					DB_RAM,	CLE_CMD_WR);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int xgene_cle_setup_node(struct xgene_enet_pdata *pdata,
+				struct xgene_enet_cle *cle)
+{
+	struct xgene_cle_ptree *ptree = &cle->ptree;
+	struct xgene_cle_ptree_ewdn *dn = ptree->dn;
+	struct xgene_cle_ptree_kn *kn = ptree->kn;
+	u32 buf[CLE_DRAM_REGS];
+	int i, j, ret;
+
+	memset(buf, 0, sizeof(buf));
+	for (i = 0; i < ptree->num_dn; i++) {
+		xgene_cle_dn_to_hw(&dn[i], buf, cle->jump_bytes);
+		ret = xgene_cle_dram_wr(cle, buf, 17, i + ptree->start_node,
+					PTREE_RAM, CLE_CMD_WR);
+		if (ret)
+			return ret;
+	}
+
+	/* continue node index for key node */
+	memset(buf, 0, sizeof(buf));
+	for (j = i; j < (ptree->num_kn + ptree->num_dn); j++) {
+		xgene_cle_kn_to_hw(&kn[j - ptree->num_dn], buf);
+		ret = xgene_cle_dram_wr(cle, buf, 17, j + ptree->start_node,
+					PTREE_RAM, CLE_CMD_WR);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int xgene_cle_setup_ptree(struct xgene_enet_pdata *pdata,
+				 struct xgene_enet_cle *cle)
+{
+	int ret;
+
+	ret = xgene_cle_setup_node(pdata, cle);
+	if (ret)
+		return ret;
+
+	ret = xgene_cle_setup_dbptr(pdata, cle);
+	if (ret)
+		return ret;
+
+	xgene_cle_enable_ptree(pdata, cle);
+
+	return 0;
+}
+
+static void xgene_cle_setup_def_dbptr(struct xgene_enet_pdata *pdata,
+				      struct xgene_enet_cle *enet_cle,
+				      struct xgene_cle_dbptr *dbptr,
+				      u32 index, u8 priority)
+{
+	void __iomem *base = enet_cle->base;
+	void __iomem *base_addr;
+	u32 buf[CLE_DRAM_REGS];
+	u32 def_cls, offset;
+	u32 i, j;
+
+	memset(buf, 0, sizeof(buf));
+	xgene_cle_dbptr_to_hw(pdata, dbptr, buf);
+
+	for (i = 0; i < enet_cle->parsers; i++) {
+		if (enet_cle->active_parser != PARSER_ALL) {
+			offset = enet_cle->active_parser *
+				CLE_PORT_OFFSET;
+		} else {
+			offset = i * CLE_PORT_OFFSET;
+		}
+
+		base_addr = base + DFCLSRESDB00 + offset;
+		for (j = 0; j < 6; j++)
+			iowrite32(buf[j], base_addr + (j * 4));
+
+		def_cls = ((priority & 0x7) << 10) | (index & 0x3ff);
+		iowrite32(def_cls, base + DFCLSRESDBPTR0 + offset);
+	}
+}
+
+static int xgene_enet_cle_init(struct xgene_enet_pdata *pdata)
+{
+	struct xgene_enet_cle *enet_cle = &pdata->cle;
+	struct xgene_cle_ptree *ptree = &enet_cle->ptree;
+	struct xgene_cle_dbptr dbptr[DB_MAX_PTRS];
+	struct xgene_cle_ptree_kn kn;
+	u32 def_qid, def_fpsel, pool_id;
+	struct xgene_cle_ptree_ewdn ptree_dn[] = {
+		{
+			/* PKT_TYPE_NODE */
+			.node_type = EWDN,
+			.last_node = 0,
+			.hdr_len_store = 0,
+			.hdr_extn = NO_BYTE,
+			.byte_store = NO_BYTE,
+			.search_byte_store = NO_BYTE,
+			.result_pointer = DB_RES_DROP,
+			.num_branches = 1,
+			.branch = {
+				{
+					/* Allow all packet type */
+					.valid = 0,
+					.next_packet_pointer = 0,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = LAST_NODE,
+					.next_branch = 0,
+					.data = 0x0,
+					.mask = 0xffff
+				}
+			}
+		},
+		{
+			/* LAST NODE */
+			.node_type = EWDN,
+			.last_node = 1,
+			.hdr_len_store = 0,
+			.hdr_extn = NO_BYTE,
+			.byte_store = NO_BYTE,
+			.search_byte_store = NO_BYTE,
+			.result_pointer = DB_RES_DROP,
+			.num_branches = 1,
+			.branch = {
+				{
+					.valid = 0,
+					.next_packet_pointer = 0,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = MAX_NODES,
+					.next_branch = 0,
+					.data = 0,
+					.mask = 0xffff
+				}
+			}
+		}
+	};
+
+	ptree->start_pkt = 12; /* Ethertype */
+
+	def_qid = xgene_enet_dst_ring_num(pdata->rx_ring);
+	pool_id = pdata->rx_ring->buf_pool->id;
+	def_fpsel = xgene_enet_ring_bufnum(pool_id) - 0x20;
+
+	memset(dbptr, 0, sizeof(struct xgene_cle_dbptr) * DB_MAX_PTRS);
+	dbptr[DB_RES_ACCEPT].fpsel =  def_fpsel;
+	dbptr[DB_RES_ACCEPT].dstqid = def_qid;
+	dbptr[DB_RES_ACCEPT].cle_priority = 1;
+
+	dbptr[DB_RES_DEF].fpsel = def_fpsel;
+	dbptr[DB_RES_DEF].dstqid = def_qid;
+	dbptr[DB_RES_DEF].cle_priority = 7;
+	xgene_cle_setup_def_dbptr(pdata, enet_cle, &dbptr[DB_RES_DEF],
+				  DB_RES_ACCEPT, 7);
+
+	dbptr[DB_RES_DROP].drop = 1;
+
+	memset(&kn, 0, sizeof(kn));
+	kn.node_type = KN;
+	kn.num_keys = 1;
+	kn.key[0].priority = 0;
+	kn.key[0].result_pointer = DB_RES_ACCEPT;
+
+	ptree->dn = ptree_dn;
+	ptree->kn = &kn;
+	ptree->dbptr = dbptr;
+	ptree->num_dn = MAX_NODES;
+	ptree->num_kn = 1;
+	ptree->num_dbptr = DB_MAX_PTRS;
+
+	return xgene_cle_setup_ptree(pdata, enet_cle);
+}
+
+struct xgene_cle_ops xgene_cle3in_ops = {
+	.cle_init = xgene_enet_cle_init,
+};
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h
new file mode 100644
index 0000000..9696a57
--- /dev/null
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h
@@ -0,0 +1,264 @@
+/* Applied Micro X-Gene SoC Ethernet Classifier structures
+ *
+ * Copyright (c) 2016, Applied Micro Circuits Corporation
+ * Authors: Khuong Dinh <kdinh at apm.com>
+ *          Tanmay Inamdar <tinamdar at apm.com>
+ *          Iyappan Subramanian <isubramanian at apm.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __XGENE_ENET_CLE_H__
+#define __XGENE_ENET_CLE_H__
+
+#include <linux/io.h>
+#include <linux/random.h>
+
+/* Register offsets */
+#define INDADDR			0x04
+#define INDCMD			0x08
+#define INDCMD_STATUS		0x0c
+#define DATA_RAM0		0x10
+#define SNPTR0			0x0100
+#define SPPTR0			0x0104
+#define DFCLSRESDBPTR0		0x0108
+#define DFCLSRESDB00		0x010c
+
+#define CLE_CMD_TO		10	/* ms */
+#define CLE_PKTRAM_SIZE		256	/* bytes */
+#define CLE_PORT_OFFSET		0x200
+#define CLE_DRAM_REGS		17
+
+#define CLE_DN_TYPE_LEN		2
+#define CLE_DN_TYPE_POS		0
+#define CLE_DN_LASTN_LEN	1
+#define CLE_DN_LASTN_POS	2
+#define CLE_DN_HLS_LEN		1
+#define CLE_DN_HLS_POS		3
+#define CLE_DN_EXT_LEN		2
+#define	CLE_DN_EXT_POS		4
+#define CLE_DN_BSTOR_LEN	2
+#define CLE_DN_BSTOR_POS	6
+#define CLE_DN_SBSTOR_LEN	2
+#define CLE_DN_SBSTOR_POS	8
+#define CLE_DN_RPTR_LEN		12
+#define CLE_DN_RPTR_POS		12
+
+#define CLE_BR_VALID_LEN	1
+#define CLE_BR_VALID_POS	0
+#define CLE_BR_NPPTR_LEN	9
+#define CLE_BR_NPPTR_POS	1
+#define CLE_BR_JB_LEN		1
+#define CLE_BR_JB_POS		10
+#define CLE_BR_JR_LEN		1
+#define CLE_BR_JR_POS		11
+#define CLE_BR_OP_LEN		3
+#define CLE_BR_OP_POS		12
+#define CLE_BR_NNODE_LEN	9
+#define CLE_BR_NNODE_POS	15
+#define CLE_BR_NBR_LEN		5
+#define CLE_BR_NBR_POS		24
+
+#define CLE_BR_DATA_LEN		16
+#define CLE_BR_DATA_POS		0
+#define CLE_BR_MASK_LEN		16
+#define CLE_BR_MASK_POS		16
+
+#define CLE_KN_PRIO_POS		0
+#define CLE_KN_PRIO_LEN		3
+#define CLE_KN_RPTR_POS		3
+#define CLE_KN_RPTR_LEN		10
+#define CLE_TYPE_POS		0
+#define CLE_TYPE_LEN		2
+
+#define CLE_DSTQIDL_POS		25
+#define CLE_DSTQIDL_LEN		7
+#define CLE_DSTQIDH_POS		0
+#define CLE_DSTQIDH_LEN		5
+#define CLE_FPSEL_POS		21
+#define CLE_FPSEL_LEN		4
+#define CLE_PRIORITY_POS	5
+#define CLE_PRIORITY_LEN	3
+
+/* Patricia tree node configuration */
+#define JMP_ABS			0
+#define JMP_REL			1
+#define JMP_FW			0
+#define JMP_BW			1
+#define SEARCH_STORE(b)		b
+#define BYTE_STORE(b)		b
+#define HDR_EXT(b)		b
+#define HLS(b)			b
+#define LN(b)			b
+#define VALID(b)		b
+#define NEXT_NODE(b)		b
+#define NEXT_BRANCH(b)		b
+#define KEY_INDEX(b)		b
+
+enum xgene_cle_ptree_nodes {
+	PKT_TYPE_NODE,
+	LAST_NODE,
+	MAX_NODES
+};
+
+enum xgene_cle_byte_store {
+	NO_BYTE,
+	FIRST_BYTE,
+	SECOND_BYTE,
+	BOTH_BYTES
+};
+
+/* Preclassification operation types */
+enum xgene_cle_node_type {
+	INV,
+	KN,
+	EWDN,
+	RES_NODE
+};
+
+/* Preclassification operation types */
+enum xgene_cle_op_type {
+	EQT,
+	NEQT,
+	LTEQT,
+	GTEQT,
+	AND,
+	NAND
+};
+
+enum xgene_cle_parser {
+	PARSER0,
+	PARSER1,
+	PARSER2,
+	PARSER_ALL
+};
+
+#define XGENE_CLE_DRAM(type)	(((type) & 0xf) << 28)
+enum xgene_cle_dram_type {
+	PKT_RAM,
+	PTREE_RAM = 0xc,
+	AVL_RAM,
+	DB_RAM
+};
+
+enum xgene_cle_cmd_type {
+	CLE_CMD_WR = 1,
+	CLE_CMD_RD = 2,
+	CLE_CMD_AVL_ADD = 8,
+	CLE_CMD_AVL_DEL = 16,
+	CLE_CMD_AVL_SRCH = 32
+};
+
+enum xgene_cle_ptree_dbptrs {
+	DB_RES_DROP,
+	DB_RES_DEF,
+	DB_RES_ACCEPT,
+	DB_MAX_PTRS
+};
+
+struct xgene_cle_ptree_branch {
+	bool valid;
+	u16 next_packet_pointer;
+	bool jump_bw;
+	bool jump_rel;
+	u8 operation;
+	u16 next_node;
+	u8 next_branch;
+	u16 data;
+	u16 mask;
+};
+
+struct xgene_cle_ptree_ewdn {
+	u8 node_type;
+	bool last_node;
+	bool hdr_len_store;
+	u8 hdr_extn;
+	u8 byte_store;
+	u8 search_byte_store;
+	u16 result_pointer;
+	u8 num_branches;
+	struct xgene_cle_ptree_branch branch[8];
+};
+
+struct xgene_cle_ptree_key {
+	u8 priority;
+	u16 result_pointer;
+};
+
+struct xgene_cle_ptree_kn {
+	u8 node_type;
+	u8 num_keys;
+	struct xgene_cle_ptree_key key[32];
+};
+
+struct xgene_cle_dbptr {
+	u8 split_boundary;
+	u8 mirror_nxtfpsel;
+	u8 mirror_fpsel;
+	u16 mirror_dstqid;
+	u8 drop;
+	u8 mirror;
+	u8 hdr_data_split;
+	u64 hopinfomsbs;
+	u8 DR;
+	u8 HR;
+	u64 hopinfomlsbs;
+	u16 h0enq_num;
+	u8 h0fpsel;
+	u8 nxtfpsel;
+	u8 fpsel;
+	u16 dstqid;
+	u8 cle_priority;
+	u8 cle_flowgroup;
+	u8 cle_perflow;
+	u8 cle_insert_timestamp;
+	u8 stash;
+	u8 in;
+	u8 perprioen;
+	u8 perflowgroupen;
+	u8 perflowen;
+	u8 selhash;
+	u8 selhdrext;
+	u8 mirror_nxtfpsel_msb;
+	u8 mirror_fpsel_msb;
+	u8 hfpsel_msb;
+	u8 nxtfpsel_msb;
+	u8 fpsel_msb;
+};
+
+struct xgene_cle_ptree {
+	struct xgene_cle_ptree_ewdn *dn;
+	struct xgene_cle_ptree_kn *kn;
+	struct xgene_cle_dbptr *dbptr;
+	u32 num_dn;
+	u32 num_kn;
+	u32 num_dbptr;
+	u32 start_node;
+	u32 start_pkt;
+	u32 start_dbptr;
+};
+
+struct xgene_enet_cle {
+	void __iomem *base;
+	struct xgene_cle_ptree ptree;
+	enum xgene_cle_parser active_parser;
+	u32 parsers;
+	u32 max_nodes;
+	u32 max_dbptrs;
+	u32 jump_bytes;
+};
+
+extern struct xgene_cle_ops xgene_cle3in_ops;
+
+#endif /* __XGENE_ENET_CLE_H__ */
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
index 8a90910..45725ec 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
@@ -101,6 +101,7 @@ enum xgene_enet_rm {
 #define MAC_OFFSET			0x30
 
 #define BLOCK_ETH_CSR_OFFSET		0x2000
+#define BLOCK_ETH_CLE_CSR_OFFSET	0x6000
 #define BLOCK_ETH_RING_IF_OFFSET	0x9000
 #define BLOCK_ETH_CLKRST_CSR_OFFSET	0xc000
 #define BLOCK_ETH_DIAG_CSR_OFFSET	0xD000
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 5eb9b20..2716d45 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -93,13 +93,6 @@ static int xgene_enet_refill_bufpool(struct xgene_enet_desc_ring *buf_pool,
 	return 0;
 }
 
-static u16 xgene_enet_dst_ring_num(struct xgene_enet_desc_ring *ring)
-{
-	struct xgene_enet_pdata *pdata = netdev_priv(ring->ndev);
-
-	return ((u16)pdata->rm << 10) | ring->num;
-}
-
 static u8 xgene_enet_hdr_len(const void *data)
 {
 	const struct ethhdr *eth = data;
@@ -1278,6 +1271,7 @@ static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
 	else
 		base_addr = pdata->base_addr;
 	pdata->eth_csr_addr = base_addr + BLOCK_ETH_CSR_OFFSET;
+	pdata->cle.base = base_addr + BLOCK_ETH_CLE_CSR_OFFSET;
 	pdata->eth_ring_if_addr = base_addr + BLOCK_ETH_RING_IF_OFFSET;
 	pdata->eth_diag_csr_addr = base_addr + BLOCK_ETH_DIAG_CSR_OFFSET;
 	if (pdata->phy_mode == PHY_INTERFACE_MODE_RGMII ||
@@ -1300,6 +1294,7 @@ static int xgene_enet_init_hw(struct xgene_enet_pdata *pdata)
 {
 	struct net_device *ndev = pdata->ndev;
 	struct xgene_enet_desc_ring *buf_pool;
+	struct xgene_enet_cle *enet_cle = &pdata->cle;
 	u16 dst_ring_num;
 	int ret;
 
@@ -1323,7 +1318,24 @@ static int xgene_enet_init_hw(struct xgene_enet_pdata *pdata)
 	}
 
 	dst_ring_num = xgene_enet_dst_ring_num(pdata->rx_ring);
-	pdata->port_ops->cle_bypass(pdata, dst_ring_num, buf_pool->id);
+	if (pdata->phy_mode == PHY_INTERFACE_MODE_XGMII) {
+		/* Initialize and Enable  PreClassifier Tree */
+		enet_cle->max_nodes = 512;
+		enet_cle->max_dbptrs = 1024;
+		enet_cle->parsers = 3;
+		enet_cle->active_parser = PARSER_ALL;
+		enet_cle->ptree.start_node = 0;
+		enet_cle->ptree.start_dbptr = 0;
+		enet_cle->jump_bytes = 8;
+		ret = pdata->cle_ops->cle_init(pdata);
+		if (ret) {
+			netdev_err(ndev, "Preclass Tree init error\n");
+			return ret;
+		}
+	} else {
+		pdata->port_ops->cle_bypass(pdata, dst_ring_num, buf_pool->id);
+	}
+
 	pdata->mac_ops->init(pdata);
 
 	return ret;
@@ -1345,6 +1357,7 @@ static void xgene_enet_setup_ops(struct xgene_enet_pdata *pdata)
 	default:
 		pdata->mac_ops = &xgene_xgmac_ops;
 		pdata->port_ops = &xgene_xgport_ops;
+		pdata->cle_ops = &xgene_cle3in_ops;
 		pdata->rm = RM0;
 		break;
 	}
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
index 248dfc4..05365c1 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
@@ -36,6 +36,7 @@
 #include <linux/if_vlan.h>
 #include <linux/phy.h>
 #include "xgene_enet_hw.h"
+#include "xgene_enet_cle.h"
 #include "xgene_enet_ring2.h"
 
 #define XGENE_DRV_VERSION	"v1.0"
@@ -145,6 +146,10 @@ struct xgene_ring_ops {
 	u32 (*len)(struct xgene_enet_desc_ring *);
 };
 
+struct xgene_cle_ops {
+	int (*cle_init)(struct xgene_enet_pdata *pdata);
+};
+
 /* ethernet private data */
 struct xgene_enet_pdata {
 	struct net_device *ndev;
@@ -174,10 +179,12 @@ struct xgene_enet_pdata {
 	void __iomem *ring_cmd_addr;
 	int phy_mode;
 	enum xgene_enet_rm rm;
+	struct xgene_enet_cle cle;
 	struct rtnl_link_stats64 stats;
 	const struct xgene_mac_ops *mac_ops;
 	const struct xgene_port_ops *port_ops;
 	struct xgene_ring_ops *ring_ops;
+	struct xgene_cle_ops *cle_ops;
 	struct delayed_work link_work;
 	u32 port_id;
 	u8 cpu_bufnum;
@@ -229,6 +236,13 @@ static inline struct device *ndev_to_dev(struct net_device *ndev)
 	return ndev->dev.parent;
 }
 
+static inline u16 xgene_enet_dst_ring_num(struct xgene_enet_desc_ring *ring)
+{
+	struct xgene_enet_pdata *pdata = netdev_priv(ring->ndev);
+
+	return ((u16)pdata->rm << 10) | ring->num;
+}
+
 void xgene_enet_set_ethtool_ops(struct net_device *netdev);
 
 #endif /* __XGENE_ENET_MAIN_H__ */
-- 
1.9.1



From isubramanian at apm.com  Tue Feb  2 23:55:15 2016
From: isubramanian at apm.com (Iyappan Subramanian)
Date: Tue,  2 Feb 2016 23:55:15 -0800
Subject: [PATCH net-next 3/4] drivers: net: xgene: Add support for multiple
 queues
In-Reply-To: <1454486116-23783-1-git-send-email-isubramanian@apm.com>
References: <1454486116-23783-1-git-send-email-isubramanian@apm.com>
Message-ID: <1454486116-23783-4-git-send-email-isubramanian@apm.com>

Signed-off-by: Iyappan Subramanian <isubramanian at apm.com>
Signed-off-by: Khuong Dinh <kdinh at apm.com>
Signed-off-by: Tanmay Inamdar <tinamdar at apm.com>
Tested-by: Toan Le <toanle at apm.com>
---
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c  |  11 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 452 ++++++++++++++---------
 drivers/net/ethernet/apm/xgene/xgene_enet_main.h |  20 +-
 3 files changed, 289 insertions(+), 194 deletions(-)

diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
index d51268f..ae0c93c 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
@@ -333,13 +333,14 @@ static int xgene_cle_set_rss_skeys(struct xgene_enet_cle *cle)
 static int xgene_cle_set_rss_idt(struct xgene_enet_pdata *pdata)
 {
 	int i, ret = 0;
-	u32 fpsel, dstqid, nfpsel, idt_reg;
+	u32 fpsel, dstqid, nfpsel, idt_reg, idx;
 	u16 pool_id;
 
 	for (i = 0; i < XGENE_CLE_IDT_ENTRIES; i++) {
-		pool_id = pdata->rx_ring->buf_pool->id;
+		idx = i % pdata->rxq_cnt;
+		pool_id = pdata->rx_ring[idx]->buf_pool->id;
 		fpsel = xgene_enet_ring_bufnum(pool_id) - 0x20;
-		dstqid = xgene_enet_dst_ring_num(pdata->rx_ring);
+		dstqid = xgene_enet_dst_ring_num(pdata->rx_ring[idx]);
 		nfpsel = 0;
 		idt_reg = 0;
 
@@ -695,8 +696,8 @@ static int xgene_enet_cle_init(struct xgene_enet_pdata *pdata)
 		br->mask = 0xffff;
 	}
 
-	def_qid = xgene_enet_dst_ring_num(pdata->rx_ring);
-	pool_id = pdata->rx_ring->buf_pool->id;
+	def_qid = xgene_enet_dst_ring_num(pdata->rx_ring[0]);
+	pool_id = pdata->rx_ring[0]->buf_pool->id;
 	def_fpsel = xgene_enet_ring_bufnum(pool_id) - 0x20;
 
 	memset(dbptr, 0, sizeof(struct xgene_cle_dbptr) * DB_MAX_PTRS);
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 2716d45..1653345 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -182,7 +182,6 @@ static int xgene_enet_tx_completion(struct xgene_enet_desc_ring *cp_ring,
 static u64 xgene_enet_work_msg(struct sk_buff *skb)
 {
 	struct net_device *ndev = skb->dev;
-	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 	struct iphdr *iph;
 	u8 l3hlen = 0, l4hlen = 0;
 	u8 ethhdr, proto = 0, csum_enable = 0;
@@ -228,10 +227,6 @@ static u64 xgene_enet_work_msg(struct sk_buff *skb)
 			if (!mss || ((skb->len - hdr_len) <= mss))
 				goto out;
 
-			if (mss != pdata->mss) {
-				pdata->mss = mss;
-				pdata->mac_ops->set_mss(pdata);
-			}
 			hopinfo |= SET_BIT(ET);
 		}
 	} else if (iph->protocol == IPPROTO_UDP) {
@@ -413,7 +408,7 @@ out:
 	raw_desc->m0 = cpu_to_le64(SET_VAL(LL, ll) | SET_VAL(NV, nv) |
 				   SET_VAL(USERINFO, tx_ring->tail));
 	tx_ring->cp_ring->cp_skb[tx_ring->tail] = skb;
-	pdata->tx_level += count;
+	pdata->tx_level[tx_ring->cp_ring->index] += count;
 	tx_ring->tail = tail;
 
 	return count;
@@ -423,15 +418,17 @@ static netdev_tx_t xgene_enet_start_xmit(struct sk_buff *skb,
 					 struct net_device *ndev)
 {
 	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
-	struct xgene_enet_desc_ring *tx_ring = pdata->tx_ring;
-	u32 tx_level = pdata->tx_level;
+	struct xgene_enet_desc_ring *tx_ring;
+	int index = skb->queue_mapping;
+	u32 tx_level = pdata->tx_level[index];
 	int count;
 
-	if (tx_level < pdata->txc_level)
-		tx_level += ((typeof(pdata->tx_level))~0U);
+	tx_ring = pdata->tx_ring[index];
+	if (tx_level < pdata->txc_level[index])
+		tx_level += ((typeof(pdata->tx_level[index]))~0U);
 
-	if ((tx_level - pdata->txc_level) > pdata->tx_qcnt_hi) {
-		netif_stop_queue(ndev);
+	if ((tx_level - pdata->txc_level[index]) > pdata->tx_qcnt_hi) {
+		netif_stop_subqueue(ndev, index);
 		return NETDEV_TX_BUSY;
 	}
 
@@ -529,7 +526,8 @@ static bool is_rx_desc(struct xgene_enet_raw_desc *raw_desc)
 static int xgene_enet_process_ring(struct xgene_enet_desc_ring *ring,
 				   int budget)
 {
-	struct xgene_enet_pdata *pdata = netdev_priv(ring->ndev);
+	struct net_device *ndev = ring->ndev;
+	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 	struct xgene_enet_raw_desc *raw_desc, *exp_desc;
 	u16 head = ring->head;
 	u16 slots = ring->slots - 1;
@@ -573,7 +571,7 @@ static int xgene_enet_process_ring(struct xgene_enet_desc_ring *ring,
 		desc_count++;
 		processed++;
 		if (is_completion)
-			pdata->txc_level += desc_count;
+			pdata->txc_level[ring->index] += desc_count;
 
 		if (ret)
 			break;
@@ -583,8 +581,8 @@ static int xgene_enet_process_ring(struct xgene_enet_desc_ring *ring,
 		pdata->ring_ops->wr_cmd(ring, -count);
 		ring->head = head;
 
-		if (netif_queue_stopped(ring->ndev))
-			netif_start_queue(ring->ndev);
+		if (__netif_subqueue_stopped(ndev, ring->index))
+			netif_start_subqueue(ndev, ring->index);
 	}
 
 	return processed;
@@ -609,8 +607,16 @@ static int xgene_enet_napi(struct napi_struct *napi, const int budget)
 static void xgene_enet_timeout(struct net_device *ndev)
 {
 	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
+	struct netdev_queue *txq;
+	int i;
 
 	pdata->mac_ops->reset(pdata);
+
+	for (i = 0; i < pdata->txq_cnt; i++) {
+		txq = netdev_get_tx_queue(ndev, i);
+		txq->trans_start = jiffies;
+		netif_tx_start_queue(txq);
+	}
 }
 
 static int xgene_enet_register_irq(struct net_device *ndev)
@@ -618,17 +624,21 @@ static int xgene_enet_register_irq(struct net_device *ndev)
 	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 	struct device *dev = ndev_to_dev(ndev);
 	struct xgene_enet_desc_ring *ring;
-	int ret;
+	int ret = 0, i;
 
-	ring = pdata->rx_ring;
-	irq_set_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
-	ret = devm_request_irq(dev, ring->irq, xgene_enet_rx_irq,
-			       IRQF_SHARED, ring->irq_name, ring);
-	if (ret)
-		netdev_err(ndev, "Failed to request irq %s\n", ring->irq_name);
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		ring = pdata->rx_ring[i];
+		irq_set_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
+		ret = devm_request_irq(dev, ring->irq, xgene_enet_rx_irq,
+				       IRQF_SHARED, ring->irq_name, ring);
+		if (ret) {
+			netdev_err(ndev, "Failed to request irq %s\n",
+				   ring->irq_name);
+		}
+	}
 
-	if (pdata->cq_cnt) {
-		ring = pdata->tx_ring->cp_ring;
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		ring = pdata->tx_ring[i]->cp_ring;
 		irq_set_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
 		ret = devm_request_irq(dev, ring->irq, xgene_enet_rx_irq,
 				       IRQF_SHARED, ring->irq_name, ring);
@@ -646,15 +656,19 @@ static void xgene_enet_free_irq(struct net_device *ndev)
 	struct xgene_enet_pdata *pdata;
 	struct xgene_enet_desc_ring *ring;
 	struct device *dev;
+	int i;
 
 	pdata = netdev_priv(ndev);
 	dev = ndev_to_dev(ndev);
-	ring = pdata->rx_ring;
-	irq_clear_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
-	devm_free_irq(dev, ring->irq, ring);
 
-	if (pdata->cq_cnt) {
-		ring = pdata->tx_ring->cp_ring;
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		ring = pdata->rx_ring[i];
+		irq_clear_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
+		devm_free_irq(dev, ring->irq, ring);
+	}
+
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		ring = pdata->tx_ring[i]->cp_ring;
 		irq_clear_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
 		devm_free_irq(dev, ring->irq, ring);
 	}
@@ -663,12 +677,15 @@ static void xgene_enet_free_irq(struct net_device *ndev)
 static void xgene_enet_napi_enable(struct xgene_enet_pdata *pdata)
 {
 	struct napi_struct *napi;
+	int i;
 
-	napi = &pdata->rx_ring->napi;
-	napi_enable(napi);
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		napi = &pdata->rx_ring[i]->napi;
+		napi_enable(napi);
+	}
 
-	if (pdata->cq_cnt) {
-		napi = &pdata->tx_ring->cp_ring->napi;
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		napi = &pdata->tx_ring[i]->cp_ring->napi;
 		napi_enable(napi);
 	}
 }
@@ -676,12 +693,15 @@ static void xgene_enet_napi_enable(struct xgene_enet_pdata *pdata)
 static void xgene_enet_napi_disable(struct xgene_enet_pdata *pdata)
 {
 	struct napi_struct *napi;
+	int i;
 
-	napi = &pdata->rx_ring->napi;
-	napi_disable(napi);
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		napi = &pdata->rx_ring[i]->napi;
+		napi_disable(napi);
+	}
 
-	if (pdata->cq_cnt) {
-		napi = &pdata->tx_ring->cp_ring->napi;
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		napi = &pdata->tx_ring[i]->cp_ring->napi;
 		napi_disable(napi);
 	}
 }
@@ -692,6 +712,14 @@ static int xgene_enet_open(struct net_device *ndev)
 	const struct xgene_mac_ops *mac_ops = pdata->mac_ops;
 	int ret;
 
+	ret = netif_set_real_num_tx_queues(ndev, pdata->txq_cnt);
+	if (ret)
+		return ret;
+
+	ret = netif_set_real_num_rx_queues(ndev, pdata->rxq_cnt);
+	if (ret)
+		return ret;
+
 	mac_ops->tx_enable(pdata);
 	mac_ops->rx_enable(pdata);
 
@@ -714,6 +742,7 @@ static int xgene_enet_close(struct net_device *ndev)
 {
 	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 	const struct xgene_mac_ops *mac_ops = pdata->mac_ops;
+	int i;
 
 	netif_stop_queue(ndev);
 
@@ -727,7 +756,8 @@ static int xgene_enet_close(struct net_device *ndev)
 
 	xgene_enet_free_irq(ndev);
 	xgene_enet_napi_disable(pdata);
-	xgene_enet_process_ring(pdata->rx_ring, -1);
+	for (i = 0; i < pdata->rxq_cnt; i++)
+		xgene_enet_process_ring(pdata->rx_ring[i], -1);
 
 	return 0;
 }
@@ -747,18 +777,26 @@ static void xgene_enet_delete_ring(struct xgene_enet_desc_ring *ring)
 static void xgene_enet_delete_desc_rings(struct xgene_enet_pdata *pdata)
 {
 	struct xgene_enet_desc_ring *buf_pool;
+	struct xgene_enet_desc_ring *ring;
+	int i;
 
-	if (pdata->tx_ring) {
-		xgene_enet_delete_ring(pdata->tx_ring);
-		pdata->tx_ring = NULL;
+	for (i = 0; i < pdata->txq_cnt; i++) {
+		ring = pdata->tx_ring[i];
+		if (ring) {
+			xgene_enet_delete_ring(ring);
+			pdata->tx_ring[i] = NULL;
+		}
 	}
 
-	if (pdata->rx_ring) {
-		buf_pool = pdata->rx_ring->buf_pool;
-		xgene_enet_delete_bufpool(buf_pool);
-		xgene_enet_delete_ring(buf_pool);
-		xgene_enet_delete_ring(pdata->rx_ring);
-		pdata->rx_ring = NULL;
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		ring = pdata->rx_ring[i];
+		if (ring) {
+			buf_pool = ring->buf_pool;
+			xgene_enet_delete_bufpool(buf_pool);
+			xgene_enet_delete_ring(buf_pool);
+			xgene_enet_delete_ring(ring);
+			pdata->rx_ring[i] = NULL;
+		}
 	}
 }
 
@@ -813,24 +851,29 @@ static void xgene_enet_free_desc_rings(struct xgene_enet_pdata *pdata)
 {
 	struct device *dev = &pdata->pdev->dev;
 	struct xgene_enet_desc_ring *ring;
+	int i;
 
-	ring = pdata->tx_ring;
-	if (ring) {
-		if (ring->cp_ring && ring->cp_ring->cp_skb)
-			devm_kfree(dev, ring->cp_ring->cp_skb);
-		if (ring->cp_ring && pdata->cq_cnt)
-			xgene_enet_free_desc_ring(ring->cp_ring);
-		xgene_enet_free_desc_ring(ring);
-	}
-
-	ring = pdata->rx_ring;
-	if (ring) {
-		if (ring->buf_pool) {
-			if (ring->buf_pool->rx_skb)
-				devm_kfree(dev, ring->buf_pool->rx_skb);
-			xgene_enet_free_desc_ring(ring->buf_pool);
+	for (i = 0; i < pdata->txq_cnt; i++) {
+		ring = pdata->tx_ring[i];
+		if (ring) {
+			if (ring->cp_ring && ring->cp_ring->cp_skb)
+				devm_kfree(dev, ring->cp_ring->cp_skb);
+			if (ring->cp_ring && pdata->cq_cnt)
+				xgene_enet_free_desc_ring(ring->cp_ring);
+			xgene_enet_free_desc_ring(ring);
+		}
+	}
+
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		ring = pdata->rx_ring[i];
+		if (ring) {
+			if (ring->buf_pool) {
+				if (ring->buf_pool->rx_skb)
+					devm_kfree(dev, ring->buf_pool->rx_skb);
+				xgene_enet_free_desc_ring(ring->buf_pool);
+			}
+			xgene_enet_free_desc_ring(ring);
 		}
-		xgene_enet_free_desc_ring(ring);
 	}
 }
 
@@ -943,104 +986,119 @@ static int xgene_enet_create_desc_rings(struct net_device *ndev)
 	u8 bp_bufnum = pdata->bp_bufnum;
 	u16 ring_num = pdata->ring_num;
 	u16 ring_id;
-	int ret, size;
-
-	/* allocate rx descriptor ring */
-	owner = xgene_derive_ring_owner(pdata);
-	ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU, cpu_bufnum++);
-	rx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
-					      RING_CFGSIZE_16KB, ring_id);
-	if (!rx_ring) {
-		ret = -ENOMEM;
-		goto err;
-	}
-
-	/* allocate buffer pool for receiving packets */
-	owner = xgene_derive_ring_owner(pdata);
-	ring_id = xgene_enet_get_ring_id(owner, bp_bufnum++);
-	buf_pool = xgene_enet_create_desc_ring(ndev, ring_num++,
-					       RING_CFGSIZE_2KB, ring_id);
-	if (!buf_pool) {
-		ret = -ENOMEM;
-		goto err;
-	}
+	int i, ret, size;
 
-	rx_ring->nbufpool = NUM_BUFPOOL;
-	rx_ring->buf_pool = buf_pool;
-	rx_ring->irq = pdata->rx_irq;
-	if (!pdata->cq_cnt) {
-		snprintf(rx_ring->irq_name, IRQ_ID_SIZE, "%s-rx-txc",
-			 ndev->name);
-	} else {
-		snprintf(rx_ring->irq_name, IRQ_ID_SIZE, "%s-rx", ndev->name);
-	}
-	buf_pool->rx_skb = devm_kcalloc(dev, buf_pool->slots,
-					sizeof(struct sk_buff *), GFP_KERNEL);
-	if (!buf_pool->rx_skb) {
-		ret = -ENOMEM;
-		goto err;
-	}
-
-	buf_pool->dst_ring_num = xgene_enet_dst_ring_num(buf_pool);
-	rx_ring->buf_pool = buf_pool;
-	pdata->rx_ring = rx_ring;
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		/* allocate rx descriptor ring */
+		owner = xgene_derive_ring_owner(pdata);
+		ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU, cpu_bufnum++);
+		rx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
+						      RING_CFGSIZE_16KB,
+						      ring_id);
+		if (!rx_ring) {
+			ret = -ENOMEM;
+			goto err;
+		}
 
-	/* allocate tx descriptor ring */
-	owner = xgene_derive_ring_owner(pdata);
-	ring_id = xgene_enet_get_ring_id(owner, eth_bufnum++);
-	tx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
-					      RING_CFGSIZE_16KB, ring_id);
-	if (!tx_ring) {
-		ret = -ENOMEM;
-		goto err;
-	}
+		/* allocate buffer pool for receiving packets */
+		owner = xgene_derive_ring_owner(pdata);
+		ring_id = xgene_enet_get_ring_id(owner, bp_bufnum++);
+		buf_pool = xgene_enet_create_desc_ring(ndev, ring_num++,
+						       RING_CFGSIZE_2KB,
+						       ring_id);
+		if (!buf_pool) {
+			ret = -ENOMEM;
+			goto err;
+		}
 
-	size = (tx_ring->slots / 2) * sizeof(__le64) * MAX_EXP_BUFFS;
-	tx_ring->exp_bufs = dma_zalloc_coherent(dev, size, &dma_exp_bufs,
+		rx_ring->nbufpool = NUM_BUFPOOL;
+		rx_ring->buf_pool = buf_pool;
+		rx_ring->irq = pdata->irqs[i];
+		if (!pdata->cq_cnt) {
+			snprintf(rx_ring->irq_name, IRQ_ID_SIZE, "%s-rx-txc",
+				 ndev->name);
+		} else {
+			snprintf(rx_ring->irq_name, IRQ_ID_SIZE, "%s-rx%d",
+				 ndev->name, i);
+		}
+		buf_pool->rx_skb = devm_kcalloc(dev, buf_pool->slots,
+						sizeof(struct sk_buff *),
 						GFP_KERNEL);
-	if (!tx_ring->exp_bufs) {
-		ret = -ENOMEM;
-		goto err;
-	}
+		if (!buf_pool->rx_skb) {
+			ret = -ENOMEM;
+			goto err;
+		}
 
-	pdata->tx_ring = tx_ring;
+		buf_pool->dst_ring_num = xgene_enet_dst_ring_num(buf_pool);
+		rx_ring->buf_pool = buf_pool;
+		pdata->rx_ring[i] = rx_ring;
+	}
 
-	if (!pdata->cq_cnt) {
-		cp_ring = pdata->rx_ring;
-	} else {
-		/* allocate tx completion descriptor ring */
-		ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU, cpu_bufnum++);
-		cp_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
+	for (i = 0; i < pdata->txq_cnt; i++) {
+		/* allocate tx descriptor ring */
+		owner = xgene_derive_ring_owner(pdata);
+		ring_id = xgene_enet_get_ring_id(owner, eth_bufnum++);
+		tx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
 						      RING_CFGSIZE_16KB,
 						      ring_id);
-		if (!cp_ring) {
+		if (!tx_ring) {
 			ret = -ENOMEM;
 			goto err;
 		}
-		cp_ring->irq = pdata->txc_irq;
-		snprintf(cp_ring->irq_name, IRQ_ID_SIZE, "%s-txc", ndev->name);
-	}
 
-	cp_ring->cp_skb = devm_kcalloc(dev, tx_ring->slots,
-				       sizeof(struct sk_buff *), GFP_KERNEL);
-	if (!cp_ring->cp_skb) {
-		ret = -ENOMEM;
-		goto err;
-	}
+		size = (tx_ring->slots / 2) * sizeof(__le64) * MAX_EXP_BUFFS;
+		tx_ring->exp_bufs = dma_zalloc_coherent(dev, size,
+							&dma_exp_bufs,
+							GFP_KERNEL);
+		if (!tx_ring->exp_bufs) {
+			ret = -ENOMEM;
+			goto err;
+		}
 
-	size = sizeof(dma_addr_t) * MAX_SKB_FRAGS;
-	cp_ring->frag_dma_addr = devm_kcalloc(dev, tx_ring->slots,
-					      size, GFP_KERNEL);
-	if (!cp_ring->frag_dma_addr) {
-		devm_kfree(dev, cp_ring->cp_skb);
-		ret = -ENOMEM;
-		goto err;
-	}
+		pdata->tx_ring[i] = tx_ring;
 
-	pdata->tx_ring->cp_ring = cp_ring;
-	pdata->tx_ring->dst_ring_num = xgene_enet_dst_ring_num(cp_ring);
+		if (!pdata->cq_cnt) {
+			cp_ring = pdata->rx_ring[i];
+		} else {
+			/* allocate tx completion descriptor ring */
+			ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU,
+							 cpu_bufnum++);
+			cp_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
+							      RING_CFGSIZE_16KB,
+							      ring_id);
+			if (!cp_ring) {
+				ret = -ENOMEM;
+				goto err;
+			}
+
+			cp_ring->irq = pdata->irqs[pdata->rxq_cnt + i];
+			cp_ring->index = i;
+			snprintf(cp_ring->irq_name, IRQ_ID_SIZE, "%s-txc%d",
+				 ndev->name, i);
+		}
+
+		cp_ring->cp_skb = devm_kcalloc(dev, tx_ring->slots,
+					       sizeof(struct sk_buff *),
+					       GFP_KERNEL);
+		if (!cp_ring->cp_skb) {
+			ret = -ENOMEM;
+			goto err;
+		}
 
-	pdata->tx_qcnt_hi = pdata->tx_ring->slots - 128;
+		size = sizeof(dma_addr_t) * MAX_SKB_FRAGS;
+		cp_ring->frag_dma_addr = devm_kcalloc(dev, tx_ring->slots,
+						      size, GFP_KERNEL);
+		if (!cp_ring->frag_dma_addr) {
+			devm_kfree(dev, cp_ring->cp_skb);
+			ret = -ENOMEM;
+			goto err;
+		}
+
+		tx_ring->cp_ring = cp_ring;
+		tx_ring->dst_ring_num = xgene_enet_dst_ring_num(cp_ring);
+	}
+
+	pdata->tx_qcnt_hi = pdata->tx_ring[0]->slots - 128;
 
 	return 0;
 
@@ -1159,6 +1217,32 @@ static int xgene_get_rx_delay(struct xgene_enet_pdata *pdata)
 	return 0;
 }
 
+static int xgene_enet_get_irqs(struct xgene_enet_pdata *pdata)
+{
+	struct platform_device *pdev = pdata->pdev;
+	struct device *dev = &pdev->dev;
+	int i, ret, max_irqs;
+
+	if (pdata->phy_mode == PHY_INTERFACE_MODE_RGMII)
+		max_irqs = 1;
+	else if (pdata->phy_mode == PHY_INTERFACE_MODE_SGMII)
+		max_irqs = 2;
+	else
+		max_irqs = XGENE_MAX_ENET_IRQ;
+
+	for (i = 0; i < max_irqs; i++) {
+		ret = platform_get_irq(pdev, i);
+		if (ret <= 0) {
+			dev_err(dev, "Unable to get ENET IRQ\n");
+			ret = ret ? : -ENXIO;
+			return ret;
+		}
+		pdata->irqs[i] = ret;
+	}
+
+	return 0;
+}
+
 static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
 {
 	struct platform_device *pdev;
@@ -1240,25 +1324,9 @@ static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
 	if (ret)
 		return ret;
 
-	ret = platform_get_irq(pdev, 0);
-	if (ret <= 0) {
-		dev_err(dev, "Unable to get ENET Rx IRQ\n");
-		ret = ret ? : -ENXIO;
+	ret = xgene_enet_get_irqs(pdata);
+	if (ret)
 		return ret;
-	}
-	pdata->rx_irq = ret;
-
-	if (pdata->phy_mode != PHY_INTERFACE_MODE_RGMII) {
-		ret = platform_get_irq(pdev, 1);
-		if (ret <= 0) {
-			pdata->cq_cnt = 0;
-			dev_info(dev, "Unable to get Tx completion IRQ,"
-				 "using Rx IRQ instead\n");
-		} else {
-			pdata->cq_cnt = XGENE_MAX_TXC_RINGS;
-			pdata->txc_irq = ret;
-		}
-	}
 
 	pdata->clk = devm_clk_get(&pdev->dev, NULL);
 	if (IS_ERR(pdata->clk)) {
@@ -1296,7 +1364,7 @@ static int xgene_enet_init_hw(struct xgene_enet_pdata *pdata)
 	struct xgene_enet_desc_ring *buf_pool;
 	struct xgene_enet_cle *enet_cle = &pdata->cle;
 	u16 dst_ring_num;
-	int ret;
+	int i, ret;
 
 	ret = pdata->port_ops->reset(pdata);
 	if (ret)
@@ -1309,15 +1377,18 @@ static int xgene_enet_init_hw(struct xgene_enet_pdata *pdata)
 	}
 
 	/* setup buffer pool */
-	buf_pool = pdata->rx_ring->buf_pool;
-	xgene_enet_init_bufpool(buf_pool);
-	ret = xgene_enet_refill_bufpool(buf_pool, pdata->rx_buff_cnt);
-	if (ret) {
-		xgene_enet_delete_desc_rings(pdata);
-		return ret;
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		buf_pool = pdata->rx_ring[i]->buf_pool;
+		xgene_enet_init_bufpool(buf_pool);
+		ret = xgene_enet_refill_bufpool(buf_pool, pdata->rx_buff_cnt);
+		if (ret) {
+			xgene_enet_delete_desc_rings(pdata);
+			return ret;
+		}
 	}
 
-	dst_ring_num = xgene_enet_dst_ring_num(pdata->rx_ring);
+	dst_ring_num = xgene_enet_dst_ring_num(pdata->rx_ring[0]);
+	buf_pool = pdata->rx_ring[0]->buf_pool;
 	if (pdata->phy_mode == PHY_INTERFACE_MODE_XGMII) {
 		/* Initialize and Enable  PreClassifier Tree */
 		enet_cle->max_nodes = 512;
@@ -1348,17 +1419,26 @@ static void xgene_enet_setup_ops(struct xgene_enet_pdata *pdata)
 		pdata->mac_ops = &xgene_gmac_ops;
 		pdata->port_ops = &xgene_gport_ops;
 		pdata->rm = RM3;
+		pdata->rxq_cnt = 1;
+		pdata->txq_cnt = 1;
+		pdata->cq_cnt = 0;
 		break;
 	case PHY_INTERFACE_MODE_SGMII:
 		pdata->mac_ops = &xgene_sgmac_ops;
 		pdata->port_ops = &xgene_sgport_ops;
 		pdata->rm = RM1;
+		pdata->rxq_cnt = 1;
+		pdata->txq_cnt = 1;
+		pdata->cq_cnt = 1;
 		break;
 	default:
 		pdata->mac_ops = &xgene_xgmac_ops;
 		pdata->port_ops = &xgene_xgport_ops;
 		pdata->cle_ops = &xgene_cle3in_ops;
 		pdata->rm = RM0;
+		pdata->rxq_cnt = XGENE_NUM_RX_RING;
+		pdata->txq_cnt = XGENE_NUM_TX_RING;
+		pdata->cq_cnt = XGENE_NUM_TXC_RING;
 		break;
 	}
 
@@ -1412,12 +1492,16 @@ static void xgene_enet_setup_ops(struct xgene_enet_pdata *pdata)
 static void xgene_enet_napi_add(struct xgene_enet_pdata *pdata)
 {
 	struct napi_struct *napi;
+	int i;
 
-	napi = &pdata->rx_ring->napi;
-	netif_napi_add(pdata->ndev, napi, xgene_enet_napi, NAPI_POLL_WEIGHT);
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		napi = &pdata->rx_ring[i]->napi;
+		netif_napi_add(pdata->ndev, napi, xgene_enet_napi,
+			       NAPI_POLL_WEIGHT);
+	}
 
-	if (pdata->cq_cnt) {
-		napi = &pdata->tx_ring->cp_ring->napi;
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		napi = &pdata->tx_ring[i]->cp_ring->napi;
 		netif_napi_add(pdata->ndev, napi, xgene_enet_napi,
 			       NAPI_POLL_WEIGHT);
 	}
@@ -1426,12 +1510,15 @@ static void xgene_enet_napi_add(struct xgene_enet_pdata *pdata)
 static void xgene_enet_napi_del(struct xgene_enet_pdata *pdata)
 {
 	struct napi_struct *napi;
+	int i;
 
-	napi = &pdata->rx_ring->napi;
-	netif_napi_del(napi);
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		napi = &pdata->rx_ring[i]->napi;
+		netif_napi_del(napi);
+	}
 
-	if (pdata->cq_cnt) {
-		napi = &pdata->tx_ring->cp_ring->napi;
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		napi = &pdata->tx_ring[i]->cp_ring->napi;
 		netif_napi_del(napi);
 	}
 }
@@ -1445,7 +1532,8 @@ static int xgene_enet_probe(struct platform_device *pdev)
 	const struct of_device_id *of_id;
 	int ret;
 
-	ndev = alloc_etherdev(sizeof(struct xgene_enet_pdata));
+	ndev = alloc_etherdev_mqs(sizeof(struct xgene_enet_pdata),
+				  XGENE_NUM_RX_RING, XGENE_NUM_TX_RING);
 	if (!ndev)
 		return -ENOMEM;
 
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
index 05365c1..bf2f301 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
@@ -49,6 +49,11 @@
 #define XGENE_ENET_MSS	1448
 #define XGENE_MIN_ENET_FRAME_SIZE	60
 
+#define XGENE_MAX_ENET_IRQ	8
+#define XGENE_NUM_RX_RING	4
+#define XGENE_NUM_TX_RING	4
+#define XGENE_NUM_TXC_RING	4
+
 #define START_CPU_BUFNUM_0	0
 #define START_ETH_BUFNUM_0	2
 #define START_BP_BUFNUM_0	0x22
@@ -73,7 +78,6 @@
 #define X2_START_RING_NUM_1	256
 
 #define IRQ_ID_SIZE		16
-#define XGENE_MAX_TXC_RINGS	1
 
 #define PHY_POLL_LINK_ON	(10 * HZ)
 #define PHY_POLL_LINK_OFF	(PHY_POLL_LINK_ON / 5)
@@ -103,6 +107,7 @@ struct xgene_enet_desc_ring {
 	void *irq_mbox_addr;
 	u16 dst_ring_num;
 	u8 nbufpool;
+	u8 index;
 	struct sk_buff *(*rx_skb);
 	struct sk_buff *(*cp_skb);
 	dma_addr_t *frag_dma_addr;
@@ -159,15 +164,16 @@ struct xgene_enet_pdata {
 	struct clk *clk;
 	struct platform_device *pdev;
 	enum xgene_enet_id enet_id;
-	struct xgene_enet_desc_ring *tx_ring;
-	struct xgene_enet_desc_ring *rx_ring;
-	u16 tx_level;
-	u16 txc_level;
+	struct xgene_enet_desc_ring *tx_ring[XGENE_NUM_TX_RING];
+	struct xgene_enet_desc_ring *rx_ring[XGENE_NUM_RX_RING];
+	u16 tx_level[XGENE_NUM_TX_RING];
+	u16 txc_level[XGENE_NUM_TX_RING];
 	char *dev_name;
 	u32 rx_buff_cnt;
 	u32 tx_qcnt_hi;
-	u32 rx_irq;
-	u32 txc_irq;
+	u32 irqs[XGENE_MAX_ENET_IRQ];
+	u8 rxq_cnt;
+	u8 txq_cnt;
 	u8 cq_cnt;
 	void __iomem *eth_csr_addr;
 	void __iomem *eth_ring_if_addr;
-- 
1.9.1



From gregory.clement at free-electrons.com  Tue Feb  2 23:55:22 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed, 03 Feb 2016 08:55:22 +0100
Subject: [PATCH 03/10] arm64: add Armada 3700 architecture entry
In-Reply-To: <20160203142451.41381ff6@xhacker> (Jisheng Zhang's message of
 "Wed, 3 Feb 2016 14:24:51 +0800")
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-4-git-send-email-gregory.clement@free-electrons.com>
 <20160203142451.41381ff6@xhacker>
Message-ID: <87k2mm5itx.fsf@free-electrons.com>

Hi Jisheng,
 
 On mer., f?vr. 03 2016, Jisheng Zhang <jszhang at marvell.com> wrote:

> On Tue, 2 Feb 2016 19:07:41 +0100 Gregory CLEMENT wrote:
>
>> The Armada 3700 is an mvebu ARM64 SoC using one or two Cortex-A53 cores
>> depending of the variant.
>> 
>> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
>> Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>> ---
>>  arch/arm64/Kconfig.platforms | 6 ++++++
>>  1 file changed, 6 insertions(+)
>> 
>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>> index 21074f674bde..7da341f7b90d 100644
>> --- a/arch/arm64/Kconfig.platforms
>> +++ b/arch/arm64/Kconfig.platforms
>> @@ -1,5 +1,11 @@
>>  menu "Platform selection"
>>  
>> +config ARCH_ARMADA_3700
>
> Would it be better to use ARCH_MVEBU? IMHO, there will be more ARMv8 SoCs
> from our EBU, do we plan to add one CONFIG_ARMADA_yyzz for each SoC?

Not for each SoC but for each family, yes. As we did for the other mvebu
SoC families.

Gregory

>
>> +	bool "Armada 3700 SoC Family"
>> +	help
>> +	  This enables support for Armada 3700 SoC Family. It is is an
>> +	  ARMv8 based chipset belonging to the mvebu family.
>> +
>>  config ARCH_BCM_IPROC
>>  	bool "Broadcom iProc SoC Family"
>>  	help
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From ard.biesheuvel at linaro.org  Tue Feb  2 23:56:35 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 3 Feb 2016 08:56:35 +0100
Subject: [PATCH 1/3] ARM: move .vectors and .stubs sections back into the
 kernel VMA
In-Reply-To: <20160203000351.GX10826@n2100.arm.linux.org.uk>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454419174-21290-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160203000351.GX10826@n2100.arm.linux.org.uk>
Message-ID: <CAKv+Gu_kYWczCazqgRC3y-n7s3WRTDhJXLO1RM1FE-6h1BhSUw@mail.gmail.com>

On 3 February 2016 at 01:03, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Tue, Feb 02, 2016 at 02:19:32PM +0100, Ard Biesheuvel wrote:
>> The sections themselves are emitted 4 KB apart, as required:
>>   ...
>>   [16] .stubs       PROGBITS   c0c35000 a35000 0002c0 00  AX  0   0 32
>>   [17] .vectors     PROGBITS   c0c34000 a44000 000020 00  AX  0   0  2
>>   ...
>
> ... which means we end up wasting most of a page for absolutely no
> purpose what so ever.  Sorry, I'm really not happy about this
> gratuitous wastage.
>

No, we don't. Here's some more context:

Before:
  [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
  [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
  [16] .vectors          PROGBITS        00000000 a40000 000020 00  AX  0   0  2
  [17] .stubs            PROGBITS        00001000 a41000 0002c0 00  AX  0   0 32
  [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32

After
  [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
  [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
  [16] .stubs            PROGBITS        c0c35000 a35000 0002c0 00  AX  0   0 32
  [17] .vectors          PROGBITS        c0c34000 a44000 000020 00  AX  0   0  2
  [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32

As you can see, the LMA footprint has not increased, only .stubs and
.vectors have been reordered. The apparent rounding after the .notes
section occurs in both cases, and is due to the fact that __init_begin
is rounded to page size, and has nothing to do with the VMAs chosen
for the .stubs and .vectors section.

> We changed to the existing solution to get rid of the VMA offset
> to make the code easier to read, but if we're going to get rid of
> that improvement, just revert the change.  (Check the kernel history.)
>

I think that change was an improvement. It makes the code itself more
readable, but also results in correct references in the object files
rather than opaque expressions, i.e.,

  c0c34000 <.vectors>:
  c0c34000:       f001 b800       b.w     c0c35004 <vector_rst>
  c0c34004:       f001 b8cc       b.w     c0c351a0 <vector_und>
  c0c34008:       f8df fff4       ldr.w   pc, [pc, #4084] ; c0c35000
  c0c3400c:       f001 b888       b.w     c0c35120 <vector_pabt>
  c0c34010:       f001 b846       b.w     c0c350a0 <vector_dabt>
  c0c34014:       f001 b904       b.w     c0c35220 <vector_addrexcptn>
  c0c34018:       f001 b802       b.w     c0c35020 <vector_irq>
  c0c3401c:       f001 b910       b.w     c0c35240 <vector_fiq>

-- 
Ard.


From mranostay at gmail.com  Tue Feb  2 23:55:58 2016
From: mranostay at gmail.com (Matt Ranostay)
Date: Tue, 2 Feb 2016 23:55:58 -0800
Subject: [PATCH] iio: chemical: select IRQ_WORK for ATLAS ph sensor
In-Reply-To: <5127664.OXcBoKUPQO@wuerfel>
References: <5127664.OXcBoKUPQO@wuerfel>
Message-ID: <CAKzfze8b7Q4ZHyXW=wq4K2ETFoMrfERpTci2dSAzSgCCrWpnzg@mail.gmail.com>

Reviewed-by: Matt Ranostay <mranostay at gmail.com>

On Tue, Feb 2, 2016 at 6:36 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> The newly added atlas-ph-sensor driver uses irq_work_queue, which
> may not always be enabled:
>
> ERROR: "irq_work_queue" [drivers/iio/chemical/atlas-ph-sensor.ko] undefined!
>
> This adds a 'select' statement to Kconfig to ensure it's there
> when we need it.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 27dec00ecf2d ("iio: chemical: add Atlas pH-SM sensor support")
>
> diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
> index ce7cd1370f74..f73290f84c90 100644
> --- a/drivers/iio/chemical/Kconfig
> +++ b/drivers/iio/chemical/Kconfig
> @@ -10,6 +10,7 @@ config ATLAS_PH_SENSOR
>         select REGMAP_I2C
>         select IIO_BUFFER
>         select IIO_TRIGGERED_BUFFER
> +       select IRQ_WORK
>         help
>          Say Y here to build I2C interface support for the Atlas
>          Scientific OEM pH-SM sensor.
>


From k at japko.eu  Tue Feb  2 23:57:14 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Wed, 3 Feb 2016 08:57:14 +0100
Subject: [PATCH v2] pinctrl: sunxi: H3 requires irq_read_needs_mux
Message-ID: <20160203075713.GA23312@box2.japko.eu>

It seems that on H3, just like on A10, when GPIOs are configured as
external interrupt data registers does not contain their value.  When
value is read, GPIO function must be temporary switched to input for
reads.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---

Changes compared to v1:
- None, but the patch was sent with wrong "From:", if you want to apply 
  it, please apply this one. Sorry for confusion.


 drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
index 77d4cf0..11760bb 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c
@@ -492,6 +492,7 @@ static const struct sunxi_pinctrl_desc sun8i_h3_pinctrl_data = {
 	.pins = sun8i_h3_pins,
 	.npins = ARRAY_SIZE(sun8i_h3_pins),
 	.irq_banks = 2,
+	.irq_read_needs_mux = true
 };
 
 static int sun8i_h3_pinctrl_probe(struct platform_device *pdev)
-- 
2.4.2



From heiko.carstens at de.ibm.com  Wed Feb  3 00:01:59 2016
From: heiko.carstens at de.ibm.com (Heiko Carstens)
Date: Wed, 3 Feb 2016 09:01:59 +0100
Subject: [PATCH 1/5] all: s390: move wrapper infrastructure to generic
 headers
In-Reply-To: <20160202204156.GA27290@yury-N73SV>
References: <1453741047-5498-1-git-send-email-ynorov@caviumnetworks.com>
 <1453741047-5498-2-git-send-email-ynorov@caviumnetworks.com>
 <20160128121618.GB5418@osiris> <20160128163109.GA8529@yury-N73SV>
 <20160201114251.GB973@yury-N73SV> <20160202073913.GB3990@osiris>
 <20160202154331.GA3003@yury-N73SV> <20160202160826.GF3990@osiris>
 <20160202195434.GA3397@osiris> <20160202204156.GA27290@yury-N73SV>
Message-ID: <20160203080159.GA3369@osiris>

On Tue, Feb 02, 2016 at 11:41:56PM +0300, Yury Norov wrote:
> On Tue, Feb 02, 2016 at 08:54:34PM +0100, Heiko Carstens wrote:
> > So I think I can summarize my point to: if you can enforce correctness, why
> > shouldn't you do it if the performance impact is only a single instruction.
> 
> For aarch64 it's 5 instructions. But what's more important (if ever),
> another wrapper takes another i-cache line...
>         <compat_SyS_ftruncate>:
>         stp     x29, x30, [sp,#-16]!
>         mov     x29, sp
>         bl      d40 <do_sys_ftruncate.constprop.3>
>         ldp     x29, x30, [sp],#16
>         ret

Why does gcc allocate a stackframe here? Don't you have tail call
optimization?



From gregory.clement at free-electrons.com  Wed Feb  3 00:02:44 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed, 03 Feb 2016 09:02:44 +0100
Subject: [PATCH 06/10] devicetree: bindings: add DT binding for the
 Marvell Armada 3700 SoC family
In-Reply-To: <20160202212454.GA21678@rob-hp-laptop> (Rob Herring's message of
 "Tue, 2 Feb 2016 15:24:54 -0600")
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-7-git-send-email-gregory.clement@free-electrons.com>
 <20160202212454.GA21678@rob-hp-laptop>
Message-ID: <87fuxa5ihn.fsf@free-electrons.com>

Hi Rob,
 
 On mar., f?vr. 02 2016, Rob Herring <robh at kernel.org> wrote:

> On Tue, Feb 02, 2016 at 07:07:44PM +0100, Gregory CLEMENT wrote:
>> The Marvell Armada 3700 is a family of ARMv8 CA53 SoCs. This commit
>> introduces the Device Tree binding that documents the top-level
>> compatible strings for Armada 3700 based platforms.
>> 
>> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
>> ---
>>  .../devicetree/bindings/arm/marvell/armada-37xx.txt     | 17 +++++++++++++++++
>>  1 file changed, 17 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
>> new file mode 100644
>> index 000000000000..5db9f1a90da2
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
>> @@ -0,0 +1,17 @@
>> +Marvell Armada 37xx Platforms Device Tree Bindings
>> +--------------------------------------------------
>> +
>> +Boards using a SoC of the Marvell Armada 37xx family must carry the
>> +following root node property:
>> +
>> + - compatible: must contain "marvell,armada3700"
>
> Is 3700 an actual chip? If not, please drop this.

As for I know, it is not an actual chip, so I will remove it.

Thanks,

Gregory

>
>> +
>> +In addition, depending on whether the Armada 3710 or Armada 3720 SoCs
>> +are being used, the following root node property must be added:
>> +
>> + - compatible: must contain either "marvell,armada3710" or
>> +   "marvell,armada3720"
>> +
>> +Example:
>> +
>> +compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3700";
>> -- 
>> 2.5.0
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From hs.liao at mediatek.com  Wed Feb  3 00:04:03 2016
From: hs.liao at mediatek.com (Horng-Shyang Liao)
Date: Wed, 3 Feb 2016 16:04:03 +0800
Subject: FW: [RFC 3/3] CMDQ: Mediatek CMDQ driver
In-Reply-To: <CAGS+omABD93f3X0pfiFgaxa9Lob2txkJfUUomUvs+hiRkxSuHw@mail.gmail.com>
References: <8A0FDEEF9DBBD140A3857422D81DA20F867B19FD@mtkmbs01n1>
 <1454479333.11967.12.camel@mtksdaap41>
 <CAGS+omABD93f3X0pfiFgaxa9Lob2txkJfUUomUvs+hiRkxSuHw@mail.gmail.com>
Message-ID: <1454486643.29722.2.camel@mtksdaap41>

On Wed, 2016-02-03 at 14:40 +0800, Daniel Kurtz wrote:
> > Hi Dan,
> >
> > Thanks for your comment.
> > This solution looks good to me.
> > I will change it as your suggestion.
> >
> > But, I have a question about 'mask out the provided *device virtual*
> > address'.
> > Are lower 16-bits (or 24-bits for JUMP op) of device virtual address the
> > same as device physical address?
> 
> I'm not sure.  But I doubt it we can rely on this.
> My guess would be that the ioremap only preserves the lower 12 bits
> (4k page size).
> 
> > If not, we still need to pass in physical address into CMDQ driver.
> 
> Or, instead of the iommu/slot approach, we can just provide a
> registration function for the gce driver.
> Each gce consumer could then have a simple gce node, with no slot/address:
> 
>   mediatek,gce = <&gce>;
> 
> Then on probe, the gce consumer could pass in its (struct device *) to
> gce_register_device().  gce_register_device() could then access the
> device's of_node to extract its physical address range, and look up
> its physical address in its table of per-soc of
> "device_address:gce_subsys_address" entries.  If the physical address
> is in a valid subsys ranges, the gce_register_device would cache the
> subsys address, and an offset in a (struct gce_consumer).
> gce_register_device() could then add this struct to a struct list_head
> of gce_consumers, and finally return a pointer to it back to the
> caller.
> 
> Later, the gce consumer could pass in ths (struct gce_consumer *) when
> make gce calls, along with the *offset* (not the physical address or
> virtual address) for the register that it wishes to access.  Then the
> gce driver can simply use the gce_consumer->subsys entry to create a
> gce address from the passed in offset.
> 
> This will keep the binding very simple, and would remove the need to
> convert from device virtual to physical addresses by the gce consumer,
> but require a little more per-gce-consumer setup.
> 
> -Dan

Hi Dan,

This solution is better.
I will use it.
Thanks for your suggestion.

Thanks,
HS Liao



From mw at semihalf.com  Wed Feb  3 00:05:55 2016
From: mw at semihalf.com (Marcin Wojtas)
Date: Wed, 3 Feb 2016 09:05:55 +0100
Subject: [PATCH 01/10] serial: mvebu-uart: initial support for Armada-3700
 serial port
In-Reply-To: <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <CAPv3WKfGX2dVDu2zWG4gdEMf0vO-X+NMerh9PzNDjzLBDSQcUA@mail.gmail.com>

Hi Gregory

> +
> +static int mvebu_uart_startup(struct uart_port *port)
> +{
> +       int ret;
> +
> +       writel(CTRL_TXFIFO_RST | CTRL_RXFIFO_RST,
> +              port->membase + UART_CTRL);
> +       udelay(1);
> +       writel(CTRL_RX_INT, port->membase + UART_CTRL);
> +
> +       ret = request_irq(port->irq, mvebu_uart_isr, port->irqflags, "serial",
> +                         port);
> +       if (ret) {
> +               dev_err(port->dev, "failed to request irq\n");
> +               return ret;
> +       }
> +
> +       return 0;
> +}
> +

> +static int mvebu_uart_probe(struct platform_device *pdev)
> +{
> +       struct resource *reg = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       struct resource *irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> +       struct uart_port *port;
> +       struct mvebu_uart_data *data;
> +       int ret;
> +
> +       if (!reg || !irq) {
> +               dev_err(&pdev->dev, "no registers/irq defined\n");
> +               return -EINVAL;
> +       }
> +
> +       port = &mvebu_uart_ports[0];
> +
> +       spin_lock_init(&port->lock);
> +
> +       port->dev        = &pdev->dev;
> +       port->type       = PORT_MVEBU;
> +       port->ops        = &mvebu_uart_ops;
> +       port->regshift   = 0;
> +
> +       port->fifosize   = 32;
> +       port->iotype     = UPIO_MEM32;
> +       port->flags      = UPF_FIXED_PORT;
> +       port->line       = 0; /* single port: force line number to  0 */
> +
> +       port->irq        = irq->start;
> +       port->irqflags   = 0;

Please use port->irqflags = IRQF_SHARED;
As ubuntu opens multiple consoles A3700 can't boot to it (only to
buildroot with single console).

Best regards,
Marcin


From jszhang at marvell.com  Wed Feb  3 00:01:43 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Wed, 3 Feb 2016 16:01:43 +0800
Subject: [PATCH v2 net 6/6] net: mvneta: Fix race condition during stopping
In-Reply-To: <1454332067-16378-7-git-send-email-gregory.clement@free-electrons.com>
References: <1454332067-16378-1-git-send-email-gregory.clement@free-electrons.com>
 <1454332067-16378-7-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160203160143.59225a51@xhacker>

On Mon, 1 Feb 2016 14:07:47 +0100 Gregory CLEMENT wrote:

> When stopping the port, the CPU notifier are still there whereas the
> mvneta_stop_dev function calls mvneta_percpu_disable() on each CPUs.
> It was possible to have a new CPU coming at this point which could be
> racy.
> 
> This patch adds a flag preventing executing the code notifier for a new CPU
> when the port is stopping.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  drivers/net/ethernet/marvell/mvneta.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index 4d40d2fde7ca..2f53975aa6ec 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -374,6 +374,7 @@ struct mvneta_port {
>  	 * ensuring that the configuration remains coherent.
>  	 */
>  	spinlock_t lock;
> +	bool is_stopping;
>  
>  	/* Core clock */
>  	struct clk *clk;
> @@ -2916,6 +2917,11 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
>  	switch (action) {
>  	case CPU_ONLINE:
>  	case CPU_ONLINE_FROZEN:
> +		/* Configuring the driver for a new CPU while the
> +		 * driver is stopping is racy, so just avoid it.
> +		 */
> +		if (pp->is_stopping)
> +			break;

I still see race. What about another cpu set is_stopping at this point?

Thanks


>  		netif_tx_stop_all_queues(pp->dev);
>  
>  		/* We have to synchronise on tha napi of each CPU
> @@ -3054,9 +3060,17 @@ static int mvneta_stop(struct net_device *dev)
>  {
>  	struct mvneta_port *pp = netdev_priv(dev);
>  
> +	/* Inform that we are stopping so we don't want to setup the
> +	 * driver for new CPUs in the notifiers
> +	 */
> +	pp->is_stopping = true;
>  	mvneta_stop_dev(pp);
>  	mvneta_mdio_remove(pp);
>  	unregister_cpu_notifier(&pp->cpu_notifier);
> +	/* Now that the notifier are unregistered, we can clear the
> +	 * flag
> +	 */
> +	pp->is_stopping = false;
>  	on_each_cpu(mvneta_percpu_disable, pp, true);
>  	free_percpu_irq(dev->irq, pp->ports);
>  	mvneta_cleanup_rxqs(pp);



From zhang.chunyan at linaro.org  Wed Feb  3 00:10:24 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Wed,  3 Feb 2016 16:10:24 +0800
Subject: [PATCH V2 0/6] Introduce CoreSight STM support
Message-ID: <1454487030-30053-1-git-send-email-zhang.chunyan@linaro.org>

This patchset adds support for CoreSight STM IP block. It also makes
a little modification to the generic STM framework to cover the
CoreSight STM requirements. Full description follows the changelog.

Changes from v1:
 - Added a definition of coresight_simple_func() in CS-STM driver to
   avoid the kbuild test robot error for the time being.  This
   modification will be removed when merging the code in which the
   coresight_simple_func() has been moved to the header file.


Thanks,
Chunyan

Chunyan Zhang (3):
  stm class: Add ioctl get_options interface
  stm class: adds a loop to extract the first valid STM device name
  Documentations: Add explanations of the case for non-configurable
    masters

Mathieu Poirier (2):
  stm class: provision for statically assigned masterIDs
  coresight-stm: Bindings for System Trace Macrocell

Pratik Patel (1):
  coresight-stm: adding driver for CoreSight STM component

 .../ABI/testing/sysfs-bus-coresight-devices-stm    |  53 ++
 .../devicetree/bindings/arm/coresight.txt          |  28 +
 Documentation/trace/coresight.txt                  |  37 +-
 Documentation/trace/stm.txt                        |   6 +
 drivers/hwtracing/coresight/Kconfig                |  11 +
 drivers/hwtracing/coresight/Makefile               |   1 +
 drivers/hwtracing/coresight/coresight-stm.c        | 972 +++++++++++++++++++++
 drivers/hwtracing/stm/core.c                       |  29 +-
 drivers/hwtracing/stm/policy.c                     |  46 +-
 include/linux/coresight-stm.h                      |   6 +
 include/linux/stm.h                                |  11 +
 include/uapi/linux/coresight-stm.h                 |  12 +
 include/uapi/linux/stm.h                           |   1 +
 13 files changed, 1196 insertions(+), 17 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
 create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
 create mode 100644 include/linux/coresight-stm.h
 create mode 100644 include/uapi/linux/coresight-stm.h

-- 
1.9.1



From zhang.chunyan at linaro.org  Wed Feb  3 00:15:31 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Wed,  3 Feb 2016 16:15:31 +0800
Subject: [PATCH V2 0/6] Introduce CoreSight STM support
Message-ID: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>

This patchset adds support for CoreSight STM IP block. It also makes
a little modification to the generic STM framework to cover the
CoreSight STM requirements. Full description follows the changelog.

Changes from v1:
 - Added a definition of coresight_simple_func() in CS-STM driver to
   avoid the kbuild test robot error for the time being.  This
   modification will be removed when merging the code in which the
   coresight_simple_func() has been moved to the header file.
 - Calculate the channel number according to the channel memory space size.

Thanks,
Chunyan

Chunyan Zhang (3):
  stm class: Add ioctl get_options interface
  stm class: adds a loop to extract the first valid STM device name
  Documentations: Add explanations of the case for non-configurable
    masters

Mathieu Poirier (2):
  stm class: provision for statically assigned masterIDs
  coresight-stm: Bindings for System Trace Macrocell

Pratik Patel (1):
  coresight-stm: adding driver for CoreSight STM component

 .../ABI/testing/sysfs-bus-coresight-devices-stm    |  53 ++
 .../devicetree/bindings/arm/coresight.txt          |  28 +
 Documentation/trace/coresight.txt                  |  37 +-
 Documentation/trace/stm.txt                        |   6 +
 drivers/hwtracing/coresight/Kconfig                |  11 +
 drivers/hwtracing/coresight/Makefile               |   1 +
 drivers/hwtracing/coresight/coresight-stm.c        | 972 +++++++++++++++++++++
 drivers/hwtracing/stm/core.c                       |  29 +-
 drivers/hwtracing/stm/policy.c                     |  46 +-
 include/linux/coresight-stm.h                      |   6 +
 include/linux/stm.h                                |  11 +
 include/uapi/linux/coresight-stm.h                 |  12 +
 include/uapi/linux/stm.h                           |   1 +
 13 files changed, 1196 insertions(+), 17 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
 create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
 create mode 100644 include/linux/coresight-stm.h
 create mode 100644 include/uapi/linux/coresight-stm.h

-- 
1.9.1



From zhang.chunyan at linaro.org  Wed Feb  3 00:15:32 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Wed,  3 Feb 2016 16:15:32 +0800
Subject: [PATCH V2 1/6] stm class: Add ioctl get_options interface
In-Reply-To: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454487337-30184-2-git-send-email-zhang.chunyan@linaro.org>

There is already an interface of set_options, but no get_options yet.
Before setting any options, one would may want to see the current
status of that option by means of get_options interface. This
interface has been used in CoreSight STM driver.

Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 drivers/hwtracing/stm/core.c | 11 +++++++++++
 include/linux/stm.h          |  3 +++
 include/uapi/linux/stm.h     |  1 +
 3 files changed, 15 insertions(+)

diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index b6445d9..86bb4e3 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -571,6 +571,17 @@ stm_char_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 						    options);
 
 		break;
+
+	case STP_GET_OPTIONS:
+		if (stm_data->get_options)
+			err = stm_data->get_options(stm_data,
+						    stmf->output.master,
+						    stmf->output.channel,
+						    stmf->output.nr_chans,
+						    &options);
+
+		return copy_to_user((void __user *)arg, &options, sizeof(u64));
+
 	default:
 		break;
 	}
diff --git a/include/linux/stm.h b/include/linux/stm.h
index 9d0083d..f351d62 100644
--- a/include/linux/stm.h
+++ b/include/linux/stm.h
@@ -88,6 +88,9 @@ struct stm_data {
 	long			(*set_options)(struct stm_data *, unsigned int,
 					       unsigned int, unsigned int,
 					       unsigned long);
+	long			(*get_options)(struct stm_data *, unsigned int,
+					       unsigned int, unsigned int,
+					       u64 *);
 };
 
 int stm_register_device(struct device *parent, struct stm_data *stm_data,
diff --git a/include/uapi/linux/stm.h b/include/uapi/linux/stm.h
index 626a8d3..0dab16e 100644
--- a/include/uapi/linux/stm.h
+++ b/include/uapi/linux/stm.h
@@ -46,5 +46,6 @@ struct stp_policy_id {
 #define STP_POLICY_ID_SET	_IOWR('%', 0, struct stp_policy_id)
 #define STP_POLICY_ID_GET	_IOR('%', 1, struct stp_policy_id)
 #define STP_SET_OPTIONS		_IOW('%', 2, __u64)
+#define STP_GET_OPTIONS		_IOR('%', 3, __u64)
 
 #endif /* _UAPI_LINUX_STM_H */
-- 
1.9.1



From zhang.chunyan at linaro.org  Wed Feb  3 00:15:33 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Wed,  3 Feb 2016 16:15:33 +0800
Subject: [PATCH V2 2/6] stm class: adds a loop to extract the first valid STM
 device name
In-Reply-To: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454487337-30184-3-git-send-email-zhang.chunyan@linaro.org>

The node name of STM master management policy is a concatenation of an
STM device name to which this policy applies and following an arbitrary
string, these two strings are concatenated with a dot.

This patch adds a loop for extracting the STM device name when an
arbitrary number of dot(s) are found in this STM device name.

Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 drivers/hwtracing/stm/policy.c | 27 ++++++++++++++++-----------
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
index 11ab6d0..691686e 100644
--- a/drivers/hwtracing/stm/policy.c
+++ b/drivers/hwtracing/stm/policy.c
@@ -321,21 +321,26 @@ stp_policies_make(struct config_group *group, const char *name)
 	/*
 	 * node must look like <device_name>.<policy_name>, where
 	 * <device_name> is the name of an existing stm device and
-	 * <policy_name> is an arbitrary string
+	 * <policy_name> is an arbitrary string, when an arbitrary
+	 * number of dot(s) are found in the <device_name>, the
+	 * first matched STM device name would be extracted.
 	 */
-	p = strchr(devname, '.');
-	if (!p) {
-		kfree(devname);
-		return ERR_PTR(-EINVAL);
-	}
+	for (p = devname; ; p++) {
+		p = strchr(p, '.');
+		if (!p) {
+			kfree(devname);
+			return ERR_PTR(-EINVAL);
+		}
 
-	*p++ = '\0';
+		*p = '\0';
 
-	stm = stm_find_device(devname);
-	kfree(devname);
+		stm = stm_find_device(devname);
+		if (stm)
+			break;
+		*p = '.';
+	};
 
-	if (!stm)
-		return ERR_PTR(-ENODEV);
+	kfree(devname);
 
 	mutex_lock(&stm->policy_mutex);
 	if (stm->policy) {
-- 
1.9.1



From zhang.chunyan at linaro.org  Wed Feb  3 00:15:34 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Wed,  3 Feb 2016 16:15:34 +0800
Subject: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs
In-Reply-To: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org>

From: Mathieu Poirier <mathieu.poirier at linaro.org>

Some architecture like ARM assign masterIDs statically at the HW design
phase, making masterID manipulation in the generic STM core irrelevant.

This patch adds a new 'mstatic' flag to struct stm_data that tells the
core that this specific STM device doesn't need explicit masterID
management.  In the core sw_start/end of masterID are set to '1',
i.e there is only one masterID to deal with.

Also this patch depends on [1], so that the number of masterID
is '1' too.

Finally the lower and upper bound for masterIDs as presented
in ($SYSFS)/class/stm/XYZ.stm/masters and
($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
are set to '-1'.  That way users can't confuse them with
architecture where masterID management is required (where any
other value would be valid).

[1] https://lkml.org/lkml/2015/12/22/348

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 drivers/hwtracing/stm/core.c   | 18 ++++++++++++++++--
 drivers/hwtracing/stm/policy.c | 19 +++++++++++++++++--
 include/linux/stm.h            |  8 ++++++++
 3 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 86bb4e3..cd3dc19 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -44,9 +44,15 @@ static ssize_t masters_show(struct device *dev,
 			    char *buf)
 {
 	struct stm_device *stm = to_stm_device(dev);
-	int ret;
+	int ret, sw_start, sw_end;
+
+	sw_start = stm->data->sw_start;
+	sw_end = stm->data->sw_end;
 
-	ret = sprintf(buf, "%u %u\n", stm->data->sw_start, stm->data->sw_end);
+	if (stm->data->mstatic)
+		sw_start = sw_end = STM_STATIC_MASTERID;
+
+	ret = sprintf(buf, "%d %d\n", sw_start, sw_end);
 
 	return ret;
 }
@@ -629,7 +635,15 @@ int stm_register_device(struct device *parent, struct stm_data *stm_data,
 	if (!stm_data->packet || !stm_data->sw_nchannels)
 		return -EINVAL;
 
+	/*
+	 * MasterIDs are statically set in HW. As such the core is
+	 * using a single master for interaction with this device.
+	 */
+	if (stm_data->mstatic)
+		stm_data->sw_start = stm_data->sw_end = 1;
+
 	nmasters = stm_data->sw_end - stm_data->sw_start;
+
 	stm = kzalloc(sizeof(*stm) + nmasters * sizeof(void *), GFP_KERNEL);
 	if (!stm)
 		return -ENOMEM;
diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
index 691686e..7e70ca2 100644
--- a/drivers/hwtracing/stm/policy.c
+++ b/drivers/hwtracing/stm/policy.c
@@ -80,10 +80,17 @@ static ssize_t
 stp_policy_node_masters_show(struct config_item *item, char *page)
 {
 	struct stp_policy_node *policy_node = to_stp_policy_node(item);
+	struct stm_device *stm = policy_node->policy->stm;
+	int first_master, last_master;
 	ssize_t count;
 
-	count = sprintf(page, "%u %u\n", policy_node->first_master,
-			policy_node->last_master);
+	first_master = policy_node->first_master;
+	last_master = policy_node->last_master;
+
+	if (stm && stm->data->mstatic)
+		first_master = last_master = STM_STATIC_MASTERID;
+
+	count = sprintf(page, "%d %d\n", first_master, last_master);
 
 	return count;
 }
@@ -106,6 +113,13 @@ stp_policy_node_masters_store(struct config_item *item, const char *page,
 	if (!stm)
 		goto unlock;
 
+	/*
+	 * masterIDs are statically allocated in HW, no point in trying to
+	 * change their values.
+	 */
+	if (stm->data->mstatic)
+		goto unlock;
+
 	/* must be within [sw_start..sw_end], which is an inclusive range */
 	if (first > INT_MAX || last > INT_MAX || first > last ||
 	    first < stm->data->sw_start ||
@@ -325,6 +339,7 @@ stp_policies_make(struct config_group *group, const char *name)
 	 * number of dot(s) are found in the <device_name>, the
 	 * first matched STM device name would be extracted.
 	 */
+
 	for (p = devname; ; p++) {
 		p = strchr(p, '.');
 		if (!p) {
diff --git a/include/linux/stm.h b/include/linux/stm.h
index f351d62..c9712a7 100644
--- a/include/linux/stm.h
+++ b/include/linux/stm.h
@@ -18,6 +18,11 @@
 #include <linux/device.h>
 
 /**
+ * The masterIDs are statically set in hardware and can't be queried
+ */
+#define STM_STATIC_MASTERID -1
+
+/**
  * enum stp_packet_type - STP packets that an STM driver sends
  */
 enum stp_packet_type {
@@ -46,6 +51,8 @@ struct stm_device;
  * struct stm_data - STM device description and callbacks
  * @name:		device name
  * @stm:		internal structure, only used by stm class code
+ * @mstatic:		true if masterIDs are assigned in HW.  If so @sw_start
+ *			and @sw_end are set to '1' by the core.
  * @sw_start:		first STP master available to software
  * @sw_end:		last STP master available to software
  * @sw_nchannels:	number of STP channels per master
@@ -71,6 +78,7 @@ struct stm_device;
 struct stm_data {
 	const char		*name;
 	struct stm_device	*stm;
+	bool			mstatic;
 	unsigned int		sw_start;
 	unsigned int		sw_end;
 	unsigned int		sw_nchannels;
-- 
1.9.1



From zhang.chunyan at linaro.org  Wed Feb  3 00:15:35 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Wed,  3 Feb 2016 16:15:35 +0800
Subject: [PATCH V2 4/6] Documentations: Add explanations of the case for
 non-configurable masters
In-Reply-To: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454487337-30184-5-git-send-email-zhang.chunyan@linaro.org>

For some STM hardware (e.g. ARM CoreSight STM), the masterID associated
to a source is set at the hardware level and not user configurable.
Since the masterID information isn't available to SW, introducing
a new value of -1 to reflect this reality.

Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 Documentation/trace/stm.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/trace/stm.txt b/Documentation/trace/stm.txt
index ea035f9..f03bc2b 100644
--- a/Documentation/trace/stm.txt
+++ b/Documentation/trace/stm.txt
@@ -47,6 +47,12 @@ through 127 in it. Now, any producer (trace source) identifying itself
 with "user" identification string will be allocated a master and
 channel from within these ranges.
 
+$ cat /config/stp-policy/dummy_stm.my-policy/user/masters
+-1 -1
+
+Would indicate the masters for this rule are set in hardware and
+not configurable in user space.
+
 These rules can be nested, for example, one can define a rule "dummy"
 under "user" directory from the example above and this new rule will
 be used for trace sources with the id string of "user/dummy".
-- 
1.9.1



From zhang.chunyan at linaro.org  Wed Feb  3 00:15:36 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Wed,  3 Feb 2016 16:15:36 +0800
Subject: [PATCH V2 5/6] coresight-stm: Bindings for System Trace Macrocell
In-Reply-To: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454487337-30184-6-git-send-email-zhang.chunyan@linaro.org>

From: Mathieu Poirier <mathieu.poirier at linaro.org>

The System Trace Macrocell (STM) is an IP block falling under the
CoreSight umbrella.  It's main purpose it so expose stimulus channels
to any system component for the purpose of information logging.

Bindings for this IP block adds a couple of items to the current
mandatory definition for CoreSight components.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 .../devicetree/bindings/arm/coresight.txt          | 28 ++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
index 62938eb..93147c0c 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -19,6 +19,7 @@ its hardware characteristcs.
 		- "arm,coresight-etm3x", "arm,primecell";
 		- "arm,coresight-etm4x", "arm,primecell";
 		- "qcom,coresight-replicator1x", "arm,primecell";
+		- "arm,coresight-stm", "arm,primecell"; [1]
 
 	* reg: physical base address and length of the register
 	  set(s) of the component.
@@ -36,6 +37,14 @@ its hardware characteristcs.
 	  layout using the generic DT graph presentation found in
 	  "bindings/graph.txt".
 
+* Additional required properties for System Trace Macrocells (STM):
+	* reg: along with the physical base address and length of the register
+	  set as described above, another entry is required to describe the
+	  mapping of the extended stimulus port area.
+
+	* reg-names: the only acceptable values are "stm-base" and
+	  "stm-stimulus-base", each corresponding to the areas defined in "reg".
+
 * Required properties for devices that don't show up on the AMBA bus, such as
   non-configurable replicators:
 
@@ -202,3 +211,22 @@ Example:
 			};
 		};
 	};
+
+4. STM
+	stm at 20100000 {
+		compatible = "arm,coresight-stm", "arm,primecell";
+		reg = <0 0x20100000 0 0x1000>,
+		      <0 0x28000000 0 0x180000>;
+		reg-names = "stm-base", "stm-stimulus-base";
+
+		clocks = <&soc_smc50mhz>;
+		clock-names = "apb_pclk";
+		port {
+			stm_out_port: endpoint {
+				remote-endpoint = <&main_funnel_in_port2>;
+			};
+		};
+	};
+
+[1]. There is currently two version of STM: STM32 and STM500.  Both
+have the same HW interface and as such don't need an explicit binding name.
-- 
1.9.1



From ard.biesheuvel at linaro.org  Wed Feb  3 00:16:51 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 3 Feb 2016 09:16:51 +0100
Subject: [PATCH 3/3] kallsyms: remove --page-offset command line option
In-Reply-To: <20160203000504.GY10826@n2100.arm.linux.org.uk>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454419174-21290-4-git-send-email-ard.biesheuvel@linaro.org>
 <20160203000504.GY10826@n2100.arm.linux.org.uk>
Message-ID: <CAKv+Gu8vzvX-6=+SgPwm2CUy_1Qpt-GHvzv=brQTs50i2Z=v9w@mail.gmail.com>

(+ Uwe, Maxime)

Complete thread here:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/474400

On 3 February 2016 at 01:05, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Tue, Feb 02, 2016 at 02:19:34PM +0100, Ard Biesheuvel wrote:
>> The --page-offset command line option was only used for ARM, to filter
>> symbol addresses below CONFIG_PAGE_OFFSET. This is no longer needed, so
>> remove the functionality altogether.
>
> From what I remember, this option has nothing to do with MMU-ful ARM,
> but noMMU ARM, where the .text segment can be significantly different
> from the .data segment.
>
> I think you need to talk to noMMU people about this patch.
>

We have

commit f6537f2f0eba4eba3354e48dbe3047db6d8b6254
Author: Ming Lei <tom.leiming at gmail.com>
Date:   Sat Nov 2 09:11:33 2013 +1030

    scripts/kallsyms: filter symbols not in kernel address space

    This patch uses CONFIG_PAGE_OFFSET to filter symbols which
    are not in kernel address space because these symbols are
    generally for generating code purpose and can't be run at
    kernel mode, so we needn't keep them in /proc/kallsyms.

    For example, on ARM there are some symbols which may be
    linked in relocatable code section, then perf can't parse
    symbols any more from /proc/kallsyms, this patch fixes the
    problem (introduced b9b32bf70f2fb710b07c94e13afbc729afe221da)

which introduces the --page-offset option to kallsyms, in response to
your patch that moves .vectors and .stubs to VMA 0x0. Then we have

commit 7122c3e9154b5d9a7422f68f02d8acf050fad2b0
Author: Ming Lei <tom.leiming at gmail.com>
Date:   Tue Dec 10 16:46:29 2013 +1030

    scripts/link-vmlinux.sh: only filter kernel symbols for arm

    Actually CONFIG_PAGE_OFFSET isn't same with PAGE_OFFSET, so
    it isn't easy to figue out PAGE_OFFSET defined in header
    file from scripts.

    Because CONFIG_PAGE_OFFSET may not be defined in some ARCHs(
    64bit ARCH), or defined as bogus value in !MMU case, so
    this patch only applys the filter on ARM when CONFIG_PAGE_OFFSET
    is defined as the original problem is only on ARM.

which restricts the use of --page-offset to CONFIG_ARM, and

commit cc8475305203ddfd117b81e2e732194b67d8f310
Author: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
Date:   Thu May 21 19:17:44 2015 +0800

    scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

    When Kernel is executed in place from ROM, the symbol addresses can be
    lower than the page offset.

which restricts the use of --page-offset to CONFIG_ARM && !CONFIG_XIP_KERNEL

So it looks like the Dec 10 patch fixes some fallout related to !MMU
that was caused by the Nov 2 patch, but the original patch has nothing
to do with !MMU. Furthermore, 3 out of 4 !MMU configs we have in the
tree (efm32, stm32 and vf610m4) are also XIP kernel, for which
--page-offset isn't even used to begin with after Maxime's patch.
Hopefully Uwe and/or Maxime can confirm, but removing the PAGE_OFFSET
lower limit should not affect those platforms at all afaict,
especially since, after patch 1/3, there are no symbols left to filter
below that limit in the first place.

Thanks,
Ard.


From zhang.chunyan at linaro.org  Wed Feb  3 00:15:37 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Wed,  3 Feb 2016 16:15:37 +0800
Subject: [PATCH V2 6/6] coresight-stm: adding driver for CoreSight STM
 component
In-Reply-To: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454487337-30184-7-git-send-email-zhang.chunyan@linaro.org>

From: Pratik Patel <pratikp at codeaurora.org>

This driver adds support for the STM CoreSight IP block, allowing any
system compoment (HW or SW) to log and aggregate messages via a
single entity.

The CoreSight STM exposes an application defined number of channels
called stimulus port. Configuration is done using entries in sysfs
and channels made available to userspace via configfs.

Signed-off-by: Pratik Patel <pratikp at codeaurora.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 .../ABI/testing/sysfs-bus-coresight-devices-stm    |  53 ++
 Documentation/trace/coresight.txt                  |  37 +-
 drivers/hwtracing/coresight/Kconfig                |  11 +
 drivers/hwtracing/coresight/Makefile               |   1 +
 drivers/hwtracing/coresight/coresight-stm.c        | 972 +++++++++++++++++++++
 include/linux/coresight-stm.h                      |   6 +
 include/uapi/linux/coresight-stm.h                 |  12 +
 7 files changed, 1090 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
 create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
 create mode 100644 include/linux/coresight-stm.h
 create mode 100644 include/uapi/linux/coresight-stm.h

diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
new file mode 100644
index 0000000..a1d7022
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
@@ -0,0 +1,53 @@
+What:		/sys/bus/coresight/devices/<memory_map>.stm/enable_source
+Date:		February 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Enable/disable tracing on this specific trace macrocell.
+		Enabling the trace macrocell implies it has been configured
+		properly and a sink has been identidifed for it.  The path
+		of coresight components linking the source to the sink is
+		configured and managed automatically by the coresight framework.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/hwevent_enable
+Date:		February 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Provides access to the HW event enable register, used in
+		conjunction with HW event bank select register.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/hwevent_select
+Date:		February 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Gives access to the HW event block select register
+		(STMHEBSR) in order to configure up to 256 channels.  Used in
+		conjunction with "hwevent_enable" register as described above.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/port_enable
+Date:		February 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Provides access to the stimlus port enable register
+		(STMSPER).  Used in conjunction with "port_select" described
+		below.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/port_select
+Date:		February 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Used to determine which bank of stimulus port bit in
+		register STMSPER (see above) apply to.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/status
+Date:		February 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(R) List various control and status registers.  The specific
+		layout and content is driver specific.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/traceid
+Date:		February 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Holds the trace ID that will appear in the trace stream
+		coming from this trace entity.
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
index 0a5c329..a33c88c 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -190,8 +190,8 @@ expected to be accessed and controlled using those entries.
 Last but not least, "struct module *owner" is expected to be set to reflect
 the information carried in "THIS_MODULE".
 
-How to use
-----------
+How to use the tracer modules
+-----------------------------
 
 Before trace collection can start, a coresight sink needs to be identify.
 There is no limit on the amount of sinks (nor sources) that can be enabled at
@@ -297,3 +297,36 @@ Info                                    Tracing enabled
 Instruction     13570831        0x8026B584      E28DD00C        false   ADD      sp,sp,#0xc
 Instruction     0       0x8026B588      E8BD8000        true    LDM      sp!,{pc}
 Timestamp                                       Timestamp: 17107041535
+
+How to use the STM module
+-------------------------
+
+Using the System Trace Macrocell module is the same as the tracers - the only
+difference is that clients are driving the trace capture rather
+than the program flow through the code.
+
+As with any other CoreSight component, specifics about the STM tracer can be
+found in sysfs with more information on each entry being found in [1]:
+
+root at genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
+enable_source   hwevent_select  port_enable     subsystem       uevent
+hwevent_enable  mgmt            port_select     traceid
+root at genericarmv8:~#
+
+Like any other source a sink needs to be identified and the STM enabled before
+being used:
+
+root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
+root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
+
+From there user space applications can request and use channels using the devfs
+interface provided for that purpose by the generic STM API:
+
+root at genericarmv8:~# ls -l /dev/20100000.stm
+crw-------    1 root     root       10,  61 Jan  3 18:11 /dev/20100000.stm
+root at genericarmv8:~#
+
+Details on how to use the generic STM API can be found here [2].
+
+[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
+[2]. Documentation/trace/stm.txt
diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
index c85935f..f4a8bfa 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -77,4 +77,15 @@ config CORESIGHT_QCOM_REPLICATOR
 	  programmable ATB replicator sends the ATB trace stream from the
 	  ETB/ETF to the TPIUi and ETR.
 
+config CORESIGHT_STM
+	bool "CoreSight System Trace Macrocell driver"
+	depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) || ARM64
+	select CORESIGHT_LINKS_AND_SINKS
+	select STM
+	help
+	  This driver provides support for hardware assisted software
+	  instrumentation based tracing. This is primarily used for
+	  logging useful software events or data coming from various entities
+	  in the system, possibly running different OSs
+
 endif
diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 99f8e5f..1f6eaec 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_CORESIGHT_LINKS_AND_SINKS) += coresight-funnel.o \
 obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o coresight-etm-cp14.o
 obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
 obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
+obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
new file mode 100644
index 0000000..c84f57a
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -0,0 +1,972 @@
+/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Initial implementation by Pratik Patel
+ * (C) 2014-2015 Pratik Patel <pratikp at codeaurora.org>
+ *
+ * Serious refactoring, code cleanup and upgrading to the Coresight upstream
+ * framework by Mathieu Poirier
+ * (C) 2015-2016 Mathieu Poirier <mathieu.poirier at linaro.org>
+ *
+ * Guaranteed timing and support for various packet type coming from the
+ * generic STM API by Chunyan Zhang
+ * (C) 2015-2016 Chunyan Zhang <zhang.chunyan at linaro.org>
+ */
+#include <linux/amba/bus.h>
+#include <linux/bitmap.h>
+#include <linux/clk.h>
+#include <linux/coresight.h>
+#include <linux/coresight-stm.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/pm_runtime.h>
+#include <linux/stm.h>
+
+#include "coresight-priv.h"
+
+#define STMDMASTARTR			0xc04
+#define STMDMASTOPR			0xc08
+#define STMDMASTATR			0xc0c
+#define STMDMACTLR			0xc10
+#define STMDMAIDR			0xcfc
+#define STMHEER				0xd00
+#define STMHETER			0xd20
+#define STMHEBSR			0xd60
+#define STMHEMCR			0xd64
+#define STMHEMASTR			0xdf4
+#define STMHEFEAT1R			0xdf8
+#define STMHEIDR			0xdfc
+#define STMSPER				0xe00
+#define STMSPTER			0xe20
+#define STMPRIVMASKR			0xe40
+#define STMSPSCR			0xe60
+#define STMSPMSCR			0xe64
+#define STMSPOVERRIDER			0xe68
+#define STMSPMOVERRIDER			0xe6c
+#define STMSPTRIGCSR			0xe70
+#define STMTCSR				0xe80
+#define STMTSSTIMR			0xe84
+#define STMTSFREQR			0xe8c
+#define STMSYNCR			0xe90
+#define STMAUXCR			0xe94
+#define STMSPFEAT1R			0xea0
+#define STMSPFEAT2R			0xea4
+#define STMSPFEAT3R			0xea8
+#define STMITTRIGGER			0xee8
+#define STMITATBDATA0			0xeec
+#define STMITATBCTR2			0xef0
+#define STMITATBID			0xef4
+#define STMITATBCTR0			0xef8
+
+#define STM_32_CHANNEL			32
+#define BYTES_PER_CHANNEL		256
+#define STM_TRACE_BUF_SIZE		4096
+#define STM_SW_MASTER_END		127
+
+/* Register bit definition */
+#define STMTCSR_BUSY_BIT		23
+/* Reserve the first 10 channels for kernel usage */
+#define STM_CHANNEL_OFFSET		0
+
+enum stm_pkt_type {
+	STM_PKT_TYPE_DATA	= 0x98,
+	STM_PKT_TYPE_FLAG	= 0xE8,
+	STM_PKT_TYPE_TRIG	= 0xF8,
+};
+
+#define stm_channel_addr(drvdata, ch)	(drvdata->chs.base +	\
+					(ch * BYTES_PER_CHANNEL))
+#define stm_channel_off(type, opts)	(type & ~opts)
+
+#ifndef CONFIG_64BIT
+static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
+{
+	asm volatile("strd %1, %0"
+		     : "+Qo" (*(volatile u64 __force *)addr)
+		     : "r" (val));
+}
+#undef writeq_relaxed
+#define writeq_relaxed(v, c)	__raw_writeq((__force u64) cpu_to_le64(v), c)
+#endif
+
+static int boot_nr_channel;
+
+module_param_named(
+	boot_nr_channel, boot_nr_channel, int, S_IRUGO
+);
+
+/**
+ * struct channel_space - central management entity for extended ports
+ * @base:		memory mapped base address where channels start.
+ * @guaraneed:		is the channel delivery guaranteed.
+ */
+struct channel_space {
+	void __iomem		*base;
+	unsigned long		*guaranteed;
+};
+
+/**
+ * struct stm_drvdata - specifics associated to an STM component
+ * @base:		memory mapped base address for this component.
+ * @dev:		the device entity associated to this component.
+ * @atclk:		optional clock for the core parts of the STM.
+ * @csdev:		component vitals needed by the framework.
+ * @spinlock:		only one at a time pls.
+ * @chs:		the channels accociated to this STM.
+ * @stm:		structure associated to the generic STM interface.
+ * @enable:		this STM is being used.
+ * @traceid:		value of the current ID for this component.
+ * @write_64bit:	whether this STM supports 64 bit access.
+ * @stmsper:		settings for register STMSPER.
+ * @stmspscr:		settings for register STMSPSCR.
+ * @numsp:		the total number of stimulus port support by this STM.
+ * @stmheer:		settings for register STMHEER.
+ * @stmheter:		settings for register STMHETER.
+ * @stmhebsr:		settings for register STMHEBSR.
+ */
+struct stm_drvdata {
+	void __iomem		*base;
+	struct device		*dev;
+	struct clk		*atclk;
+	struct coresight_device	*csdev;
+	spinlock_t		spinlock;
+	struct channel_space	chs;
+	struct stm_data		stm;
+	bool			enable;
+	u8			traceid;
+	u32			write_64bit;
+	u32			stmsper;
+	u32			stmspscr;
+	u32			numsp;
+	u32			stmheer;
+	u32			stmheter;
+	u32			stmhebsr;
+};
+
+static void stm_hwevent_enable_hw(struct stm_drvdata *drvdata)
+{
+	CS_UNLOCK(drvdata->base);
+
+	writel_relaxed(drvdata->stmhebsr, drvdata->base + STMHEBSR);
+	writel_relaxed(drvdata->stmheter, drvdata->base + STMHETER);
+	writel_relaxed(drvdata->stmheer, drvdata->base + STMHEER);
+	writel_relaxed(0x01 |	/* Enable HW event tracing */
+		       0x04,	/* Error detection on event tracing */
+		       drvdata->base + STMHEMCR);
+
+	CS_LOCK(drvdata->base);
+}
+
+static void stm_port_enable_hw(struct stm_drvdata *drvdata)
+{
+	CS_UNLOCK(drvdata->base);
+	/* ATB trigger enable on direct writes to TRIG locations */
+	writel_relaxed(0x10,
+		       drvdata->base + STMSPTRIGCSR);
+	writel_relaxed(drvdata->stmspscr, drvdata->base + STMSPSCR);
+	writel_relaxed(drvdata->stmsper, drvdata->base + STMSPER);
+
+	CS_LOCK(drvdata->base);
+}
+
+static void stm_enable_hw(struct stm_drvdata *drvdata)
+{
+	if (drvdata->stmheer)
+		stm_hwevent_enable_hw(drvdata);
+
+	stm_port_enable_hw(drvdata);
+
+	CS_UNLOCK(drvdata->base);
+
+	/* 4096 byte between synchronisation packets */
+	writel_relaxed(0xFFF, drvdata->base + STMSYNCR);
+	writel_relaxed((drvdata->traceid << 16 | /* trace id */
+			0x02 |			 /* timestamp enable */
+			0x01),			 /* global STM enable */
+			drvdata->base + STMTCSR);
+
+	CS_LOCK(drvdata->base);
+}
+
+static int stm_enable(struct coresight_device *csdev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	pm_runtime_get_sync(drvdata->dev);
+
+	spin_lock(&drvdata->spinlock);
+	stm_enable_hw(drvdata);
+	drvdata->enable = true;
+	spin_unlock(&drvdata->spinlock);
+
+	dev_info(drvdata->dev, "STM tracing enabled\n");
+	return 0;
+}
+
+static void stm_hwevent_disable_hw(struct stm_drvdata *drvdata)
+{
+	CS_UNLOCK(drvdata->base);
+
+	writel_relaxed(0x0, drvdata->base + STMHEMCR);
+	writel_relaxed(0x0, drvdata->base + STMHEER);
+	writel_relaxed(0x0, drvdata->base + STMHETER);
+
+	CS_LOCK(drvdata->base);
+}
+
+static void stm_port_disable_hw(struct stm_drvdata *drvdata)
+{
+	CS_UNLOCK(drvdata->base);
+
+	writel_relaxed(0x0, drvdata->base + STMSPER);
+	writel_relaxed(0x0, drvdata->base + STMSPTRIGCSR);
+
+	CS_LOCK(drvdata->base);
+}
+
+static void stm_disable_hw(struct stm_drvdata *drvdata)
+{
+	u32 val;
+
+	CS_UNLOCK(drvdata->base);
+
+	val = readl_relaxed(drvdata->base + STMTCSR);
+	val &= ~0x1; /* clear global STM enable [0] */
+	writel_relaxed(val, drvdata->base + STMTCSR);
+
+	CS_LOCK(drvdata->base);
+
+	stm_port_disable_hw(drvdata);
+	if (drvdata->stmheer)
+		stm_hwevent_disable_hw(drvdata);
+}
+
+static void stm_disable(struct coresight_device *csdev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	spin_lock(&drvdata->spinlock);
+	stm_disable_hw(drvdata);
+	drvdata->enable = false;
+	spin_unlock(&drvdata->spinlock);
+
+	/* Wait until the engine has completely stopped */
+	coresight_timeout(drvdata, STMTCSR, STMTCSR_BUSY_BIT, 0);
+
+	pm_runtime_put(drvdata->dev);
+
+	dev_info(drvdata->dev, "STM tracing disabled\n");
+}
+
+static int stm_trace_id(struct coresight_device *csdev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	return drvdata->traceid;
+}
+
+static const struct coresight_ops_source stm_source_ops = {
+	.trace_id	= stm_trace_id,
+	.enable		= stm_enable,
+	.disable	= stm_disable,
+};
+
+static const struct coresight_ops stm_cs_ops = {
+	.source_ops	= &stm_source_ops,
+};
+
+static int stm_send_64bit(void *addr, const void *data, u32 size)
+{
+	u64 prepad = 0;
+	u64 postpad = 0;
+	char *pad;
+	u8 off, endoff;
+	u32 len = size;
+
+	off = (unsigned long)data & 0x7;
+
+	if (off) {
+		endoff = 8 - off;
+		pad = (char *)&prepad;
+		pad += off;
+
+		while (endoff && size) {
+			*pad++ = *(char *)data++;
+			endoff--;
+			size--;
+		}
+		writeq_relaxed(prepad, addr);
+	}
+
+	/* now we are 64bit aligned */
+	while (size >= 8) {
+		writeq_relaxed(*(u64 *)data, addr);
+		data += 8;
+		size -= 8;
+	}
+
+	endoff = 0;
+
+	if (size) {
+		endoff = 8 - (u8)size;
+		pad = (char *)&postpad;
+
+		while (size) {
+			*pad++ = *(char *)data++;
+			size--;
+		}
+		writeq_relaxed(postpad, addr);
+	}
+
+	return len + off + endoff;
+}
+
+static int stm_send(void *addr, const void *data, u32 size)
+{
+	u32 len = size;
+
+	if (((unsigned long)data & 0x1) && (size >= 1)) {
+		writeb_relaxed(*(u8 *)data, addr);
+		data++;
+		size--;
+	}
+	if (((unsigned long)data & 0x2) && (size >= 2)) {
+		writew_relaxed(*(u16 *)data, addr);
+		data += 2;
+		size -= 2;
+	}
+
+	/* now we are 32bit aligned */
+	while (size >= 4) {
+		writel_relaxed(*(u32 *)data, addr);
+		data += 4;
+		size -= 4;
+	}
+
+	if (size >= 2) {
+		writew_relaxed(*(u16 *)data, addr);
+		data += 2;
+		size -= 2;
+	}
+	if (size >= 1) {
+		writeb_relaxed(*(u8 *)data, addr);
+		data++;
+		size--;
+	}
+
+	return len;
+}
+
+static int stm_generic_link(struct stm_data *stm_data,
+			    unsigned int master,  unsigned int channel)
+{
+	struct stm_drvdata *drvdata = container_of(stm_data,
+						   struct stm_drvdata, stm);
+	if (!drvdata || !drvdata->csdev)
+		return -EINVAL;
+
+	return coresight_enable(drvdata->csdev);
+}
+
+static void stm_generic_unlink(struct stm_data *stm_data,
+			       unsigned int master,  unsigned int channel)
+{
+	struct stm_drvdata *drvdata = container_of(stm_data,
+						   struct stm_drvdata, stm);
+	if (!drvdata || !drvdata->csdev)
+		return;
+
+	stm_disable(drvdata->csdev);
+}
+
+static long stm_generic_set_options(struct stm_data *stm_data,
+				    unsigned int master,
+				    unsigned int channel,
+				    unsigned int nr_chans,
+				    unsigned long options)
+{
+	struct stm_drvdata *drvdata = container_of(stm_data,
+						   struct stm_drvdata, stm);
+	if (!(drvdata && drvdata->enable))
+		return -EINVAL;
+
+	if (channel >= drvdata->numsp)
+		return -EINVAL;
+
+	switch (options) {
+	case STM_OPTION_GUARANTEED:
+		set_bit(channel, drvdata->chs.guaranteed);
+		break;
+
+	case STM_OPTION_INVARIANT:
+		clear_bit(channel, drvdata->chs.guaranteed);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static long stm_generic_get_options(struct stm_data *stm_data,
+				    unsigned int master,
+				    unsigned int channel,
+				    unsigned int nr_chans,
+				    u64 *options)
+{
+	struct stm_drvdata *drvdata = container_of(stm_data,
+						   struct stm_drvdata, stm);
+	if (!(drvdata && drvdata->enable))
+		return -EINVAL;
+
+	if (channel >= drvdata->numsp)
+		return -EINVAL;
+
+	switch (*options) {
+	case STM_OPTION_GUARANTEED:
+		*options = test_bit(channel, drvdata->chs.guaranteed);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static ssize_t stm_generic_packet(struct stm_data *stm_data,
+				  unsigned int master,
+				  unsigned int channel,
+				  unsigned int packet,
+				  unsigned int flags,
+				  unsigned int size,
+				  const unsigned char *payload)
+{
+	unsigned int len = size;
+	unsigned long ch_addr;
+	struct stm_drvdata *drvdata = container_of(stm_data,
+						   struct stm_drvdata, stm);
+	if (!(drvdata && drvdata->enable))
+		return 0;
+
+	if (channel >= drvdata->numsp)
+		return 0;
+
+	ch_addr = (unsigned long)stm_channel_addr(drvdata, channel);
+
+	flags = (flags == STP_PACKET_TIMESTAMPED) ? STM_FLAG_TIMESTAMPED : 0;
+	flags |= test_bit(channel, drvdata->chs.guaranteed) ?
+			   STM_FLAG_GUARANTEED : 0;
+
+	switch (packet) {
+	case STP_PACKET_FLAG:
+		ch_addr |= stm_channel_off(STM_PKT_TYPE_FLAG, flags);
+
+		/* the generic STM API set a size of zero on flag packets. */
+		len = 1;
+		break;
+
+	case STP_PACKET_DATA:
+		ch_addr |= stm_channel_off(STM_PKT_TYPE_DATA, flags);
+		break;
+
+	default:
+		return 0;
+	}
+
+	if (drvdata->write_64bit)
+		return stm_send_64bit((void *)ch_addr, payload, len);
+
+	return stm_send((void *)ch_addr, payload, len);
+}
+
+static ssize_t hwevent_enable_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val = drvdata->stmheer;
+
+	return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
+}
+
+static ssize_t hwevent_enable_store(struct device *dev,
+				    struct device_attribute *attr,
+				    const char *buf, size_t size)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val;
+	int ret = 0;
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return -EINVAL;
+
+	drvdata->stmheer = val;
+	/* HW event enable and trigger go hand in hand */
+	drvdata->stmheter = val;
+
+	return size;
+}
+static DEVICE_ATTR_RW(hwevent_enable);
+
+static ssize_t hwevent_select_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val = drvdata->stmhebsr;
+
+	return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
+}
+
+static ssize_t hwevent_select_store(struct device *dev,
+				    struct device_attribute *attr,
+				    const char *buf, size_t size)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val;
+	int ret = 0;
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return -EINVAL;
+
+	drvdata->stmhebsr = val;
+
+	return size;
+}
+static DEVICE_ATTR_RW(hwevent_select);
+
+static ssize_t port_select_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val;
+
+	if (!drvdata->enable) {
+		val = drvdata->stmspscr;
+	} else {
+		spin_lock(&drvdata->spinlock);
+		val = readl_relaxed(drvdata->base + STMSPSCR);
+		spin_unlock(&drvdata->spinlock);
+	}
+
+	return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
+}
+
+static ssize_t port_select_store(struct device *dev,
+				 struct device_attribute *attr,
+				 const char *buf, size_t size)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val, stmsper;
+	int ret = 0;
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->stmspscr = val;
+
+	if (drvdata->enable) {
+		CS_UNLOCK(drvdata->base);
+		/* Process as per ARM's TRM recommendation */
+		stmsper = readl_relaxed(drvdata->base + STMSPER);
+		writel_relaxed(0x0, drvdata->base + STMSPER);
+		writel_relaxed(drvdata->stmspscr, drvdata->base + STMSPSCR);
+		writel_relaxed(stmsper, drvdata->base + STMSPER);
+		CS_LOCK(drvdata->base);
+	}
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(port_select);
+
+static ssize_t port_enable_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val;
+
+	if (!drvdata->enable) {
+		val = drvdata->stmsper;
+	} else {
+		spin_lock(&drvdata->spinlock);
+		val = readl_relaxed(drvdata->base + STMSPER);
+		spin_unlock(&drvdata->spinlock);
+	}
+
+	return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
+}
+
+static ssize_t port_enable_store(struct device *dev,
+				 struct device_attribute *attr,
+				 const char *buf, size_t size)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val;
+	int ret = 0;
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->stmsper = val;
+
+	if (drvdata->enable) {
+		CS_UNLOCK(drvdata->base);
+		writel_relaxed(drvdata->stmsper, drvdata->base + STMSPER);
+		CS_LOCK(drvdata->base);
+	}
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(port_enable);
+
+static ssize_t traceid_show(struct device *dev,
+			    struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->traceid;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t traceid_store(struct device *dev,
+			     struct device_attribute *attr,
+			     const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	/* traceid field is 7bit wide on STM32 */
+	drvdata->traceid = val & 0x7f;
+	return size;
+}
+static DEVICE_ATTR_RW(traceid);
+
+#define coresight_simple_func(type, name, offset)			\
+static ssize_t name##_show(struct device *_dev,				\
+			   struct device_attribute *attr, char *buf)	\
+{									\
+	type *drvdata = dev_get_drvdata(_dev->parent);			\
+	return scnprintf(buf, PAGE_SIZE, "0x%08x\n",			\
+			 readl_relaxed(drvdata->base + offset));	\
+}									\
+DEVICE_ATTR_RO(name)
+
+#define coresight_stm_simple_func(name, offset)	\
+	coresight_simple_func(struct stm_drvdata, name, offset)
+
+coresight_stm_simple_func(tcsr, STMTCSR);
+coresight_stm_simple_func(tsfreqr, STMTSFREQR);
+coresight_stm_simple_func(syncr, STMSYNCR);
+coresight_stm_simple_func(sper, STMSPER);
+coresight_stm_simple_func(spter, STMSPTER);
+coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
+coresight_stm_simple_func(spscr, STMSPSCR);
+coresight_stm_simple_func(spmscr, STMSPMSCR);
+coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
+coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
+coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
+coresight_stm_simple_func(devid, CORESIGHT_DEVID);
+
+static struct attribute *coresight_stm_attrs[] = {
+	&dev_attr_hwevent_enable.attr,
+	&dev_attr_hwevent_select.attr,
+	&dev_attr_port_enable.attr,
+	&dev_attr_port_select.attr,
+	&dev_attr_traceid.attr,
+	NULL,
+};
+
+static struct attribute *coresight_stm_mgmt_attrs[] = {
+	&dev_attr_tcsr.attr,
+	&dev_attr_tsfreqr.attr,
+	&dev_attr_syncr.attr,
+	&dev_attr_sper.attr,
+	&dev_attr_spter.attr,
+	&dev_attr_privmaskr.attr,
+	&dev_attr_spscr.attr,
+	&dev_attr_spmscr.attr,
+	&dev_attr_spfeat1r.attr,
+	&dev_attr_spfeat2r.attr,
+	&dev_attr_spfeat3r.attr,
+	&dev_attr_devid.attr,
+	NULL,
+};
+
+static const struct attribute_group coresight_stm_group = {
+	.attrs = coresight_stm_attrs,
+};
+
+static const struct attribute_group coresight_stm_mgmt_group = {
+	.attrs = coresight_stm_mgmt_attrs,
+	.name = "mgmt",
+};
+
+static const struct attribute_group *coresight_stm_groups[] = {
+	&coresight_stm_group,
+	&coresight_stm_mgmt_group,
+	NULL,
+};
+
+static int stm_get_resource_byname(struct device_node *np,
+				   char *ch_base, struct resource *res)
+{
+	const char *name = NULL;
+	int index = 0, found = 0;
+
+	while (!of_property_read_string_index(np, "reg-names", index, &name)) {
+		if (strcmp(ch_base, name)) {
+			index++;
+			continue;
+		}
+
+		/* We have a match and @index is where it's at */
+		found = 1;
+		break;
+	}
+
+	if (!found)
+		return -EINVAL;
+
+	return of_address_to_resource(np, index, res);
+}
+
+static u32 stm_fundamental_data_size(struct stm_drvdata *drvdata)
+{
+	u32 stmspfeat2r;
+
+	stmspfeat2r = readl_relaxed(drvdata->base + STMSPFEAT2R);
+	return BMVAL(stmspfeat2r, 12, 15);
+}
+
+static u32 stm_num_stimulus_port(struct stm_drvdata *drvdata)
+{
+	u32 numsp;
+
+	numsp = readl_relaxed(drvdata->base + CORESIGHT_DEVID);
+	/*
+	 * NUMPS in STMDEVID is 17 bit long and if equal to 0x0,
+	 * 32 stimulus ports are supported.
+	 */
+	numsp &= 0x1ffff;
+	if (!numsp)
+		numsp = STM_32_CHANNEL;
+	return numsp;
+}
+
+static void stm_init_default_data(struct stm_drvdata *drvdata)
+{
+	/* Don't use port selection */
+	drvdata->stmspscr = 0x0;
+	/*
+	 * Enable all channel regardless of their number.  When port
+	 * selection isn't used (see above) STMSPER applies to all
+	 * 32 channel group available, hence setting all 32 bits to 1
+	 */
+	drvdata->stmsper = ~0x0;
+
+	/*
+	 * Select arbitrary value to start with.  If there is a conflict
+	 * with other tracers the framework will deal with it.
+	 */
+	drvdata->traceid = 0x20;
+
+	/* Set invariant transaction timing on all channels */
+	bitmap_clear(drvdata->chs.guaranteed, 0, drvdata->numsp);
+}
+
+static void stm_init_generic_data(struct stm_drvdata *drvdata)
+{
+	drvdata->stm.name = dev_name(drvdata->dev);
+	drvdata->stm.mstatic = true;
+	drvdata->stm.sw_nchannels = drvdata->numsp;
+	drvdata->stm.packet = stm_generic_packet;
+	drvdata->stm.link = stm_generic_link;
+	drvdata->stm.unlink = stm_generic_unlink;
+	drvdata->stm.set_options = stm_generic_set_options;
+	drvdata->stm.get_options = stm_generic_get_options;
+}
+
+static int stm_probe(struct amba_device *adev, const struct amba_id *id)
+{
+	int ret;
+	void __iomem *base;
+	unsigned long *guaranteed;
+	struct device *dev = &adev->dev;
+	struct coresight_platform_data *pdata = NULL;
+	struct stm_drvdata *drvdata;
+	struct resource *res = &adev->res;
+	struct resource ch_res;
+	size_t res_size, bitmap_size;
+	struct coresight_desc *desc;
+	struct device_node *np = adev->dev.of_node;
+
+	if (np) {
+		pdata = of_get_coresight_platform_data(dev, np);
+		if (IS_ERR(pdata))
+			return PTR_ERR(pdata);
+		adev->dev.platform_data = pdata;
+	}
+	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+
+	drvdata->dev = &adev->dev;
+	drvdata->atclk = devm_clk_get(&adev->dev, "atclk"); /* optional */
+	if (!IS_ERR(drvdata->atclk)) {
+		ret = clk_prepare_enable(drvdata->atclk);
+		if (ret)
+			return ret;
+	}
+	dev_set_drvdata(dev, drvdata);
+
+	base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+	drvdata->base = base;
+
+	ret = stm_get_resource_byname(np, "stm-stimulus-base", &ch_res);
+	if (ret)
+		return ret;
+
+	base = devm_ioremap_resource(dev, &ch_res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+	drvdata->chs.base = base;
+
+	drvdata->write_64bit = stm_fundamental_data_size(drvdata);
+
+	if (boot_nr_channel)
+		drvdata->numsp = boot_nr_channel;
+	else
+		drvdata->numsp = stm_num_stimulus_port(drvdata);
+	res_size = min((resource_size_t)(drvdata->numsp *
+			BYTES_PER_CHANNEL), resource_size(&ch_res));
+	drvdata->numsp = res_size / BYTES_PER_CHANNEL;
+
+	bitmap_size = BITS_TO_LONGS(drvdata->numsp) * sizeof(long);
+	guaranteed = devm_kzalloc(dev, bitmap_size, GFP_KERNEL);
+	if (!guaranteed)
+		return -ENOMEM;
+	drvdata->chs.guaranteed = guaranteed;
+
+	spin_lock_init(&drvdata->spinlock);
+
+	stm_init_default_data(drvdata);
+	stm_init_generic_data(drvdata);
+
+	if (stm_register_device(dev, &drvdata->stm, THIS_MODULE)) {
+		dev_info(dev, "stm_register_device failed, probing deffered\n");
+		return -EPROBE_DEFER;
+	}
+
+	desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
+	if (!desc) {
+		ret = -ENOMEM;
+		goto stm_unregister;
+	}
+
+	desc->type = CORESIGHT_DEV_TYPE_SOURCE;
+	desc->subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE;
+	desc->ops = &stm_cs_ops;
+	desc->pdata = pdata;
+	desc->dev = dev;
+	desc->groups = coresight_stm_groups;
+	drvdata->csdev = coresight_register(desc);
+	if (IS_ERR(drvdata->csdev)) {
+		ret = PTR_ERR(drvdata->csdev);
+		goto stm_unregister;
+	}
+
+	pm_runtime_put(&adev->dev);
+
+	dev_info(dev, "%s initialized\n", (char *)id->data);
+	return 0;
+
+stm_unregister:
+	stm_unregister_device(&drvdata->stm);
+	return ret;
+}
+
+static int stm_remove(struct amba_device *adev)
+{
+	struct stm_drvdata *drvdata = amba_get_drvdata(adev);
+
+	stm_unregister_device(&drvdata->stm);
+	coresight_unregister(drvdata->csdev);
+	return 0;
+}
+
+#ifdef CONFIG_PM
+static int stm_runtime_suspend(struct device *dev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev);
+
+	if (drvdata && !IS_ERR(drvdata->atclk))
+		clk_disable_unprepare(drvdata->atclk);
+
+	return 0;
+}
+
+static int stm_runtime_resume(struct device *dev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev);
+
+	if (drvdata && !IS_ERR(drvdata->atclk))
+		clk_prepare_enable(drvdata->atclk);
+
+	return 0;
+}
+#endif
+
+static const struct dev_pm_ops stm_dev_pm_ops = {
+	SET_RUNTIME_PM_OPS(stm_runtime_suspend, stm_runtime_resume, NULL)
+};
+
+static struct amba_id stm_ids[] = {
+	{
+		.id     = 0x0003b962,
+		.mask   = 0x0003ffff,
+		.data	= "STM32",
+	},
+	{ 0, 0},
+};
+
+static struct amba_driver stm_driver = {
+	.drv = {
+		.name   = "coresight-stm",
+		.owner	= THIS_MODULE,
+		.pm	= &stm_dev_pm_ops,
+	},
+	.probe          = stm_probe,
+	.remove         = stm_remove,
+	.id_table	= stm_ids,
+};
+
+module_amba_driver(stm_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("CoreSight System Trace Macrocell driver");
diff --git a/include/linux/coresight-stm.h b/include/linux/coresight-stm.h
new file mode 100644
index 0000000..a978bb8
--- /dev/null
+++ b/include/linux/coresight-stm.h
@@ -0,0 +1,6 @@
+#ifndef __LINUX_CORESIGHT_STM_H_
+#define __LINUX_CORESIGHT_STM_H_
+
+#include <uapi/linux/coresight-stm.h>
+
+#endif
diff --git a/include/uapi/linux/coresight-stm.h b/include/uapi/linux/coresight-stm.h
new file mode 100644
index 0000000..fa35f0b
--- /dev/null
+++ b/include/uapi/linux/coresight-stm.h
@@ -0,0 +1,12 @@
+#ifndef __UAPI_CORESIGHT_STM_H_
+#define __UAPI_CORESIGHT_STM_H_
+
+#define STM_FLAG_TIMESTAMPED   BIT(3)
+#define STM_FLAG_GUARANTEED    BIT(7)
+
+enum {
+	STM_OPTION_GUARANTEED = 0,
+	STM_OPTION_INVARIANT,
+};
+
+#endif
-- 
1.9.1



From b18965 at freescale.com  Wed Feb  3 00:16:44 2016
From: b18965 at freescale.com (Alison Wang)
Date: Wed, 3 Feb 2016 16:16:44 +0800
Subject: [PATCH] dts: ls102xa: ifc: Add the partition for NOR flash
Message-ID: <1454487404-330-1-git-send-email-b18965@freescale.com>

According to the new mapping table, the partition for NOR flash
is added.

Signed-off-by: Alison Wang <alison.wang at nxp.com>
---
 arch/arm/boot/dts/ls1021a-qds.dts | 60 +++++++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/ls1021a-twr.dts | 60 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 120 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a-qds.dts b/arch/arm/boot/dts/ls1021a-qds.dts
index 9408753..904ee09 100644
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -237,6 +237,66 @@
 		reg = <0x0 0x0 0x8000000>;
 		bank-width = <2>;
 		device-width = <1>;
+
+		partition at 0 {
+			/* 128KB for bank0 RCW */
+			reg = <0x00000000 0x00020000>;
+			label = "NOR bank0 RCW Image";
+		};
+
+		partition at 100000 {
+			/* 1MB for bank0 u-boot Image */
+			reg = <0x00100000 0x00100000>;
+			label = "NOR bank0 u-boot Image";
+		};
+
+		partition at 200000 {
+			/* 1MB for bank0 DTB */
+			reg = <0x00200000 0x00100000>;
+			label = "NOR bank0 DTB Image";
+		};
+
+		partition at 300000 {
+			/* 7MB for bank0 Linux Kernel */
+			reg = <0x00300000 0x00700000>;
+			label = "NOR bank0 Linux Kernel Image";
+		};
+
+		partition at a00000 {
+			/* 54MB for bank0 Ramdisk Root File System */
+			reg = <0x00a00000 0x03600000>;
+			label = "NOR bank0 Ramdisk Root File System Image";
+		};
+
+		partition at 4000000 {
+			/* 128KB for bank4 RCW */
+			reg = <0x04000000 0x00020000>;
+			label = "NOR bank4 RCW Image";
+		};
+
+		partition at 4100000 {
+			/* 1MB for bank4 u-boot Image */
+			reg = <0x04100000 0x00100000>;
+			label = "NOR bank4 u-boot Image";
+		};
+
+		partition at 4200000 {
+			/* 1MB for bank4 DTB */
+			reg = <0x04200000 0x00100000>;
+			label = "NOR bank4 DTB Image";
+		};
+
+		partition at 4300000 {
+			/* 7MB for bank4 Linux Kernel */
+			reg = <0x04300000 0x00700000>;
+			label = "NOR bank4 Linux Kernel Image";
+		};
+
+		partition at 4a00000 {
+			/* 54MB for bank4 Ramdisk Root File System */
+			reg = <0x04a00000 0x03600000>;
+			label = "NOR bank4 Ramdisk Root File System Image";
+		};
 	};
 
 	fpga: board-control at 3,0 {
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts b/arch/arm/boot/dts/ls1021a-twr.dts
index 75ecaed..f5e9616 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -194,6 +194,66 @@
 		reg = <0x0 0x0 0x8000000>;
 		bank-width = <2>;
 		device-width = <1>;
+
+		partition at 0 {
+			/* 128KB for bank0 RCW */
+			reg = <0x00000000 0x00020000>;
+			label = "NOR bank0 RCW Image";
+		};
+
+		partition at 100000 {
+			/* 1MB for bank0 u-boot Image */
+			reg = <0x00100000 0x00100000>;
+			label = "NOR bank0 u-boot Image";
+		};
+
+		partition at 200000 {
+			/* 1MB for bank0 DTB */
+			reg = <0x00200000 0x00100000>;
+			label = "NOR bank0 DTB Image";
+		};
+
+		partition at 300000 {
+			/* 7MB for bank0 Linux Kernel */
+			reg = <0x00300000 0x00700000>;
+			label = "NOR bank0 Linux Kernel Image";
+		};
+
+		partition at a00000 {
+			/* 54MB for bank0 Ramdisk Root File System */
+			reg = <0x00a00000 0x03600000>;
+			label = "NOR bank0 Ramdisk Root File System Image";
+		};
+
+		partition at 4000000 {
+			/* 128KB for bank4 RCW */
+			reg = <0x04000000 0x00020000>;
+			label = "NOR bank4 RCW Image";
+		};
+
+		partition at 4100000 {
+			/* 1MB for bank4 u-boot Image */
+			reg = <0x04100000 0x00100000>;
+			label = "NOR bank4 u-boot Image";
+		};
+
+		partition at 4200000 {
+			/* 1MB for bank4 DTB */
+			reg = <0x04200000 0x00100000>;
+			label = "NOR bank4 DTB Image";
+		};
+
+		partition at 4300000 {
+			/* 7MB for bank4 Linux Kernel */
+			reg = <0x04300000 0x00700000>;
+			label = "NOR bank4 Linux Kernel Image";
+		};
+
+		partition at 4a00000 {
+			/* 54MB for bank4 Ramdisk Root File System */
+			reg = <0x04a00000 0x03600000>;
+			label = "NOR bank4 Ramdisk Root File System Image";
+		};
 	};
 };
 
-- 
2.1.0.27.g96db324



From xinliang.liu at linaro.org  Wed Feb  3 00:32:09 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Wed, 3 Feb 2016 16:32:09 +0800
Subject: [PATCH v3 01/10] drm/hisilicon: Add device tree binding for
 hi6220 display subsystem
In-Reply-To: <20160201151027.GA5888@rob-hp-laptop>
References: <1454144075-74361-1-git-send-email-xinliang.liu@linaro.org>
 <1454144075-74361-2-git-send-email-xinliang.liu@linaro.org>
 <20160201151027.GA5888@rob-hp-laptop>
Message-ID: <CAGd==05D5XJP6+N8Qo97BomNVhWmML9XH--vgyf0OtKsr0apRg@mail.gmail.com>

On 1 February 2016 at 23:10, Rob Herring <robh at kernel.org> wrote:
> On Sat, Jan 30, 2016 at 04:54:26PM +0800, Xinliang Liu wrote:
>> Add ADE display controller binding doc.
>> Add DesignWare DSI Host Controller v1.20a binding doc.
>>
>> Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
>>
>> v3:
>> - Make ade as the drm master node.
>> - Use assigned-clocks to set clock rate.
>> - Use ports to connect display relavant nodes.
>> v2:
>> - Move dt binding docs to bindings/display/hisilicon directory.
>
> Looks pretty good, just a few minor things.
>

Thanks for all your help.

>> ---
>>  .../bindings/display/hisilicon/dw-dsi.txt          | 60 ++++++++++++++++++++++
>>  .../bindings/display/hisilicon/hisi-ade.txt        | 56 ++++++++++++++++++++
>>  2 files changed, 116 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>>  create mode 100644 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>>
>> diff --git a/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>> new file mode 100644
>> index 000000000000..44b945a54f3f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>> @@ -0,0 +1,60 @@
>> +Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
>> +
>> +A DSI Host Controller resides in the middle of display controller and external
>> +HDMI converter.
>> +
>> +Required properties:
>> +- compatible: value should be "hisilicon,hi6220-dsi".
>> +- reg: physical base address and length of the controller's registers.
>> +- clocks: the clocks needed.
>> +- clock-names: the name of the clocks.
>> +- ports: contains DSI controller input and output sub port. The input port
>> +  connects to ADE output port, and output port connected to external HDMI
>
> or panel or any other bridge.

Right, I plan to support panel soon.
will change to:
s/output port connected to external HDMI/output port connected to
panel or any other bridge/

>
>> +  endpoint. See Documentation/devicetree/bindings/graph.txt for more device
>> +  graph info.
>> +
>> +A example of HiKey board hi6220 SoC and board specific DT entry:
>> +Example:
>> +
>> +SoC specific:
>> +     dsi: dsi at 0xf4107800 {
>
> Drop the '0x'

OK, will change to:
dsi: dsi at f4107800

>
>> +             compatible = "hisilicon,hi6220-dsi";
>> +             reg = <0x0 0xf4107800 0x0 0x100>;
>> +             clocks = <&media_ctrl  HI6220_DSI_PCLK>;
>> +             clock-names = "pclk_dsi";
>> +
>> +             ports {
>> +                     #address-cells = <1>;
>> +                     #size-cells = <0>;
>> +
>> +                     port at 0 {
>> +                             reg = <0>;
>> +                             dsi_in: endpoint {
>> +                                             remote-endpoint = <&ade_out>;
>
> Indentation is wrong.
>
>> +                             };
>> +                     };
>> +
>> +                     port at 1 {
>> +                             reg = <1>; /* 1 for output port */
>> +                             dsi_out: endpoint {
>> +                                              remote-endpoint = <&adv7533_in>;
>
> ditto.

All the indentation will be fixed in v4.

>
>> +                             };
>> +                     };
>> +             };
>> +     };
>> +
>> +Board specific:
>> +     i2c2: i2c at f7102000 {
>> +             ...
>> +
>> +             adv7533: adv7533 at 39 {
>> +                     ...
>> +
>> +                     port {
>> +                             adv7533_in: endpoint {
>> +                                     remote-endpoint = <&dsi_out>;
>> +                             };
>> +                     };
>> +             };
>> +     };
>> +
>> diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>> new file mode 100644
>> index 000000000000..47925826536c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>> @@ -0,0 +1,56 @@
>> +Device-Tree bindings for hisilicon ADE display controller driver
>> +
>> +ADE (Advanced Display Engine) is the display controller which grab image
>> +data from memory, do composition, do post image processing, generate RGB
>> +timing stream and transfer to DSI.
>> +
>> +Required properties:
>> +- compatible: value should be "hisilicon,hi6220-ade".
>> +- reg: physical base address and length of the controller's registers.
>
> I see 3 ranges in the example. Please specify what each one is here.

will change to:

- reg: physical base address and length of the controller's registers.
Three reg ranges are used in ADE driver:
ADE reg range, value should be <0x0 0xf4100000 0x0 0x7800>;
media subsystem reg range, value should be <0x0 0xf4410000 0x0 0x1000>;
media subsystem NOC QoS reg range, value should be <0x0 0xf4520000 0x0 0x1000>;

>
>> +- reg-names: name of physical base.
>> +- interrupt: the interrupt number.
>> +- clocks: the clocks needed.
>
> Same here. Specify what the clocks are.
>

will change to:

- clocks: the clocks needed.
Three clocks are used in ADE driver:
ADE core clock, value should be  <&media_ctrl HI6220_ADE_CORE>;
ADE pixel clok, value should be <&media_ctrl HI6220_ADE_PIX_SRC>;
media NOC QoS clock, value should be <&media_ctrl HI6220_CODEC_JPEG>;

- assigned-clock-rates: clock rates which are assigned to assigned-clocks.
The rate of <&media_ctrl HI6220_ADE_CORE> could be 360000000 or 180000000.
The rate of <&media_ctrl HI6220_CODEC_JPEG> could be less than 1440000000.

>> +- clock-names: the name of the clocks.
>> +- assigned-clocks: clocks to be assigned rate.
>> +- assigned-clock-rates: clock rates which are assigned to assigned-clocks.
>> +- port: the output port. This contains one endpoint subnode, with its
>> +  remote-endpoint set to the phandle of the connected DSI endpoint.
>> +  See Documentation/devicetree/bindings/graph.txt for more device graph info.
>> +
>> +Optional properties:
>> +- dma-coherent: Present if dma operations are coherent.
>> +
>> +
>> +A example of HiKey board hi6220 SoC specific DT entry:
>> +Example:
>> +
>> +     ade: ade at f4100000 {
>> +             compatible = "hisilicon,hi6220-ade";
>> +             reg = <0x0 0xf4100000 0x0 0x7800>,
>> +                   <0x0 0xf4410000 0x0 0x1000>,
>> +                   <0x0 0xf4520000 0x0 0x1000>;
>> +             reg-names = "ade_base",
>> +                         "media_base",
>> +                         "media_noc_base";
>> +
>> +             interrupts = <0 115 4>; /* ldi interrupt */
>> +
>> +             clocks = <&media_ctrl HI6220_ADE_CORE>,
>> +                      <&media_ctrl HI6220_CODEC_JPEG>,
>> +                      <&media_ctrl HI6220_ADE_PIX_SRC>;
>> +             /*clock name*/
>> +             clock-names  = "clk_ade_core",
>> +                            "clk_codec_jpeg",
>> +                            "clk_ade_pix";
>> +
>> +             assigned-clocks = <&media_ctrl HI6220_ADE_CORE>,
>> +                     <&media_ctrl HI6220_CODEC_JPEG>;
>> +             assigned-clock-rates = <360000000>, <288000000>;
>> +             dma-coherent;
>> +
>> +             port {
>> +                     ade_out: endpoint {
>> +                             remote-endpoint = <&dsi_in>;
>> +                     };
>> +             };
>> +     };
>> --
>> 1.9.1
>>


From v1ron at mail.ru  Wed Feb  3 00:36:26 2016
From: v1ron at mail.ru (Roman Volkov)
Date: Wed, 3 Feb 2016 11:36:26 +0300
Subject: [PATCH] clk: vt8500: don't return possibly uninitialized data
In-Reply-To: <2326140.nrZ9Ej2PSt@wuerfel>
References: <4790407.6zgSQCdsSB@wuerfel> <2210116.QsPesySkh0@wuerfel>
 <20160202194713.GN4848@codeaurora.org> <2326140.nrZ9Ej2PSt@wuerfel>
Message-ID: <20160203113626.4a3f4f8a@v1ron-s7>

? Tue, 02 Feb 2016 21:00:29 +0100
Arnd Bergmann <arnd at arndb.de> ?????:

> On Tuesday 02 February 2016 11:47:13 Stephen Boyd wrote:
> > On 02/02, Arnd Bergmann wrote:  
> > > On Monday 01 February 2016 17:15:45 Stephen Boyd wrote:
> > > 
> > > I see what you mean now. I checked different gcc versions, and
> > > with my patch I get the warnings for 4.6 through 4.9, but not for
> > > 5.x.
> > > 
> > > In general, I tried to only address warnings I still see with
> > > newer gcc version, as they are better about false positives. Do
> > > you think it's ok to take the patch as is then? Otherwise we
> > > probably have to add fake initializations which would shut up the
> > > warnings but not help with the code quality. 
> > 
> > Sure. I was hoping something could be done to restructure the
> > code to make it easier for the compiler to figure out the
> > variables would be initialized. But you're the one who's sending
> > the patch to silence them so if you're satisfied I'm not going to
> > spend too much time on this.
> >   
> 
> Ok, thanks!
> 
> Note that this one patch was for a real bug involving undefined
> behavior that is now fixed.
> 
> 	Arnd

Hi Arnd,

Thanks for fixing this code! Did someone reproduce this bug, or this
is something theoretical, based on the code analysis? I just never
heard about the issue. I can look into the code on the weekends too, I
have WM8505\WM8650 machines to test.

Is it enough to run the regular kernel build for WM8650 to see the
warnings, or there are special options in the kernel to run the compiler
test?

Regards
Roman


From codekipper at gmail.com  Wed Feb  3 00:41:42 2016
From: codekipper at gmail.com (Code Kipper)
Date: Wed, 3 Feb 2016 09:41:42 +0100
Subject: [PATCH v3 2/2] ASOC: sunxi: Add support for the SPDIF block
In-Reply-To: <20160202211743.GD4652@lukather>
References: <1454424594-25208-1-git-send-email-codekipper@gmail.com>
 <1454424594-25208-3-git-send-email-codekipper@gmail.com>
 <20160202211743.GD4652@lukather>
Message-ID: <CAEKpxBk3kFM-Qqn50P9VYuOgz5uJ_p__rVLZhQKDmf7GkVkzOg@mail.gmail.com>

On 2 February 2016 at 22:17, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> Hi,
>
> It looks mostly good on my side, a few comments though.
>
> On Tue, Feb 02, 2016 at 03:49:54PM +0100, codekipper at gmail.com wrote:
>> +#ifdef CONFIG_PM
>> +static int sun4i_spdif_runtime_suspend(struct device *dev)
>> +{
>> +     struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
>> +
>> +     clk_disable_unprepare(host->spdif_clk);
>> +
>> +     return 0;
>> +}
>> +
>> +static int sun4i_spdif_runtime_resume(struct device *dev)
>> +{
>> +     struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
>> +
>> +     clk_prepare_enable(host->spdif_clk);
>> +
>> +     return 0;
>> +}
>> +#endif /* CONFIG_PM */
>
> You can also shut down the bus clock here. That will reset the device,
> so you'll have to reinit it in your resume, but since you won't be
> suspended while you play something, and that you set up most of your
> controller any way when you start streaming, it shouldn't be a big
> deal.
ACK
>
>> +
>> +static int sun4i_spdif_probe(struct platform_device *pdev)
>> +{
>> +     struct device_node *np = pdev->dev.of_node;
>> +     struct sun4i_spdif_dev *host;
>> +     struct resource *res;
>> +     int ret;
>> +     void __iomem *base;
>> +
>> +     dev_dbg(&pdev->dev, "Entered %s\n", __func__);
>> +
>> +     if (!np)
>> +             return -ENODEV;
>
> You won't probe without DT.
ACK
>
>> +
>> +     if (!of_match_device(sun4i_spdif_of_match, &pdev->dev)) {
>> +             dev_err(&pdev->dev, "No matched devices found.\n");
>> +             return -EINVAL;
>> +     }
>
> And you won't probe if the compatibles don't match.
ACK
>
>> +     host = devm_kzalloc(&pdev->dev, sizeof(*host), GFP_KERNEL);
>> +     if (!host)
>> +             return -ENOMEM;
>> +
>> +     host->pdev = pdev;
>> +
>> +     /* Initialize this copy of the CPU DAI driver structure */
>> +     memcpy(&host->cpu_dai_drv, &sun4i_spdif_dai, sizeof(sun4i_spdif_dai));
>> +     host->cpu_dai_drv.name = dev_name(&pdev->dev);
>> +
>> +     /* Get the addresses */
>> +     res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +     base = devm_ioremap_resource(&pdev->dev, res);
>> +     if (IS_ERR(base))
>> +             return PTR_ERR(base);
>> +
>> +     host->regmap = devm_regmap_init_mmio(&pdev->dev, base,
>> +                                             &sun4i_spdif_regmap_config);
>> +
>> +     /* Clocks */
>> +     host->apb_clk = devm_clk_get(&pdev->dev, "apb");
>> +     if (IS_ERR(host->apb_clk)) {
>> +             dev_err(&pdev->dev, "failed to get a apb clock.\n");
>> +             return PTR_ERR(host->apb_clk);
>> +     }
>> +
>> +     ret = clk_prepare_enable(host->apb_clk);
>> +     if (ret) {
>> +             dev_err(&pdev->dev, "try to enable apb_spdif_clk failed\n");
>> +             return ret;
>> +     }
>> +
>> +     host->spdif_clk = devm_clk_get(&pdev->dev, "spdif");
>> +     if (IS_ERR(host->spdif_clk)) {
>> +             dev_err(&pdev->dev, "failed to get a spdif clock.\n");
>> +             goto exit_clkdisable_apb_clk;
>> +     }
>> +
>> +     host->playback_supported = false;
>> +     host->capture_supported = false;
>> +
>> +     if (of_property_read_bool(np, "spdif-out"))
>> +             host->playback_supported = true;
>> +
>> +     if (!host->playback_supported) {
>> +             dev_err(&pdev->dev, "no enabled S/PDIF DAI link\n");
>> +             goto exit_clkdisable_clk;
>> +     }
>> +
>> +     host->dma_params_tx.addr = res->start + SUN4I_SPDIF_TXFIFO;
>> +     host->dma_params_tx.maxburst = 4;
>> +     host->dma_params_tx.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
>> +     host->dma_params_rx.addr = res->start + SUN4I_SPDIF_RXFIFO;
>> +     host->dma_params_rx.maxburst = 4;
>> +     host->dma_params_rx.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
>> +
>> +     platform_set_drvdata(pdev, host);
>> +
>> +     ret = devm_snd_soc_register_component(&pdev->dev,
>> +                             &sun4i_spdif_component, &sun4i_spdif_dai, 1);
>> +     if (ret)
>> +             goto exit_clkdisable_clk;
>> +
>> +     pm_runtime_enable(&pdev->dev);
>> +
>> +     ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
>> +     if (ret)
>> +             goto exit_clkdisable_clk;
>> +     return 0;
>> +
>> +exit_clkdisable_clk:
>> +     clk_disable_unprepare(host->spdif_clk);
>
> You disabled a clock that you didn't enable.
ACK
>
>> +exit_clkdisable_apb_clk:
>> +     clk_disable_unprepare(host->apb_clk);
>> +     return ret;
>> +}
>> +
>> +static int sun4i_spdif_remove(struct platform_device *pdev)
>> +{
>> +     struct sun4i_spdif_dev *host = dev_get_drvdata(&pdev->dev);
>> +
>> +     snd_soc_unregister_platform(&pdev->dev);
>> +     snd_soc_unregister_component(&pdev->dev);
>> +
>> +     pm_runtime_disable(&pdev->dev);
>> +
>> +     if (!IS_ERR(host->spdif_clk)) {
>
> Probe will fail on this condition. If probe failed, remove won't be
> called.
>
>> +             clk_disable_unprepare(host->spdif_clk);
>
> And here as well.
>
>> +             clk_disable_unprepare(host->apb_clk);
>> +     }
>> +
>> +     return 0;
>> +}
>> +
>> +static const struct dev_pm_ops sun4i_spdif_pm = {
>> +     SET_RUNTIME_PM_OPS(sun4i_spdif_runtime_suspend,
>> +                        sun4i_spdif_runtime_resume, NULL)
>> +};
>> +
>> +static struct platform_driver sun4i_spdif_driver = {
>> +     .driver         = {
>> +             .name   = "sun4i-spdif",
>> +             .owner  = THIS_MODULE,
>
> This is not needed.
ACK
>
>> +             .of_match_table = of_match_ptr(sun4i_spdif_of_match),
>> +             .pm     = &sun4i_spdif_pm,
>
> IIRC, the pm field is not defined if PM is not set.
>
> Have you tested your driver without PM?
No but I'll have a go!

>
>> +     },
>> +     .probe          = sun4i_spdif_probe,
>> +     .remove         = sun4i_spdif_remove,
>> +};
>> +
>> +module_platform_driver(sun4i_spdif_driver);
>> +
>> +MODULE_AUTHOR("Marcus Cooper <codekipper at gmail.com>");
>> +MODULE_AUTHOR("Andrea Venturi <be17068 at iperbole.bo.it>");
>> +MODULE_DESCRIPTION("Allwinner sun4i SPDIF SoC Interface");
>> +MODULE_LICENSE("GPL");
>> +MODULE_ALIAS("platform:sun4i-spdif");
>
> Thanks!
> Maxime
Thanks,
CK
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com


From ard.biesheuvel at linaro.org  Wed Feb  3 00:42:30 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 3 Feb 2016 09:42:30 +0100
Subject: [RFC PATCH 0/3] arm64 initrd mapping/relocation
In-Reply-To: <56B1222D.3000604@redhat.com>
References: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>
 <56B1222D.3000604@redhat.com>
Message-ID: <CAKv+Gu_K69O4c-500mxxYd=2Se+S=+fjXHkqdLdZ0QUtC4Lbbw@mail.gmail.com>

On 2 February 2016 at 22:39, Mark Langsdorf <mlangsdo at redhat.com> wrote:
> On 02/02/2016 11:56 AM, Ard Biesheuvel wrote:
>>
>> After discussing in linux-efi with Mark, and on #armlinux with Will, this
>> is
>> a proposal for dealing with initrd memory that is potentially not covered
>> by
>> the linear region.
>>
>> Note that this will look slightly differently when some of the KASLR work
>> gets
>> merged, but this should only affect the way we deal with the initrd if it
>> sits
>> outside of the linear region.
>>
>> Mostly intended for discussion, not tested at all.
>>
>> Ard Biesheuvel (3):
>>    memblock: add routine to clear the MEMBLOCK_NOMAP flag for a region
>>    arm64: add the initrd region to the linear mapping explicitly
>>    arm64: remove the now unneeded relocate_initrd()
>
>
> I discovered the original problem on AMD Seattle and these patches
> fixed it for me.
>
> Tested-by: Mark Langsdorf <mlangsdo at redhat.com>
>

Thanks Mark.

I will let Will confirm when and how these patches will be merged.

-- 
Ard.


From jitao.shi at mediatek.com  Wed Feb  3 00:48:07 2016
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Wed, 3 Feb 2016 16:48:07 +0800
Subject: [PATCH v9 1/2] Documentation: bridge: Add documentation for ps8640 DT
 properties
Message-ID: <1454489288-31951-1-git-send-email-jitao.shi@mediatek.com>

Add documentation for DT properties supported by
ps8640 DSI-eDP converter.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
Acked-by: Rob Herring <robh at kernel.org>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
---
Changes since v8:
 - No change
---
 .../devicetree/bindings/display/bridge/ps8640.txt  |   43 ++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.txt b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
new file mode 100644
index 0000000..a3e0971
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
@@ -0,0 +1,43 @@
+ps8640-bridge bindings
+
+Required properties:
+	- compatible: "parade,ps8640"
+	- reg: first page address of the bridge.
+	- sleep-gpios: OF device-tree gpio specification for PD_ pin.
+	- reset-gpios: OF device-tree gpio specification for reset pin.
+	- mode-sel-gpios: OF device-tree gpio specification for mode-sel pin.
+	- vdd12-supply: OF device-tree regulator specification for 1.2V power.
+	- vdd33-supply: OF device-tree regulator specification for 3.3V power.
+	- ports: The device node can contain video interface port nodes per
+		 the video-interfaces bind[1]. For port at 0,set the reg = <0> as
+		 ps8640 dsi in and port at 1,set the reg = <1> as ps8640 eDP out.
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+	edp-bridge at 18 {
+		compatible = "parade,ps8640";
+		reg = <0x18>;
+		sleep-gpios = <&pio 116 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&pio 115 GPIO_ACTIVE_HIGH>;
+		mode-sel-gpios = <&pio 92 GPIO_ACTIVE_HIGH>;
+		vdd12-supply = <&ps8640_fixed_1v2>;
+		vdd33-supply = <&mt6397_vgp2_reg>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			port at 0 {
+				reg = <0>;
+				ps8640_in: endpoint {
+					remote-endpoint = <&dsi0_out>;
+				};
+			};
+			port at 1 {
+				reg = <1>;
+				ps8640_out: endpoint {
+					remote-endpoint = <&panel_in>;
+				};
+			};
+		};
+	};
-- 
1.7.9.5



From jitao.shi at mediatek.com  Wed Feb  3 00:48:08 2016
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Wed, 3 Feb 2016 16:48:08 +0800
Subject: [PATCH v9 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
In-Reply-To: <1454489288-31951-1-git-send-email-jitao.shi@mediatek.com>
References: <1454489288-31951-1-git-send-email-jitao.shi@mediatek.com>
Message-ID: <1454489288-31951-2-git-send-email-jitao.shi@mediatek.com>

This patch adds drm_bridge driver for parade DSI to eDP bridge chip.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
---
Changes since v8:
 - Change ps8640_regw to ps8640_write_bytes
 - Fine tune ps8640 power squence
 - Cache the panel edid avoid power on ps8640 every ps8640_get_modes
 - Replace devm_regulator_* api with devm_regulator_bulk_*
 - define spi cmd constant

The following patches are needed to support dsi host through none dsi bus:

https://patchwork.kernel.org/patch/7818431/ ("drm/dsi: check for CONFIG_OF when defining of_mipi_dsi_device_add")
https://patchwork.kernel.org/patch/7818471/ ("drm/dsi: Refactor device creation")
https://patchwork.kernel.org/patch/7818501/ ("drm/dsi: Try to match non-DT dsi devices")
https://patchwork.kernel.org/patch/7818531/ ("drm/dsi: Check for used channels")
https://patchwork.kernel.org/patch/7818561/ ("drm/dsi: Add routine to unregister dsi device")
https://patchwork.kernel.org/patch/7818541/ ("drm/dsi: Get DSI host by DT device node")
---
 drivers/gpu/drm/bridge/Kconfig         |   11 +
 drivers/gpu/drm/bridge/Makefile        |    1 +
 drivers/gpu/drm/bridge/parade-ps8640.c | 1060 ++++++++++++++++++++++++++++++++
 3 files changed, 1072 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 27e2022..b4edd8c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,4 +40,15 @@ config DRM_PARADE_PS8622
 	---help---
 	  Parade eDP-LVDS bridge chip driver.
 
+config DRM_PARADE_PS8640
+	tristate "Parade PS8640 MIPI DSI to eDP Converter"
+	depends on OF && I2C
+	select DRM_KMS_HELPER
+	select DRM_MIPI_DSI
+	select DRM_PANEL
+	---help---
+	  Choose this option if you have PS8640 for display
+	  The PS8640 is a high-performance and low-power
+	  MIPI DSI to eDP converter
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f13c33d..fbe38dc 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c
new file mode 100644
index 0000000..b622910
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -0,0 +1,1060 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/firmware.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/of_graph.h>
+#include <linux/regulator/consumer.h>
+#include <asm/unaligned.h>
+#include <drm/drm_panel.h>
+
+#include <drmP.h>
+#include <drm_atomic_helper.h>
+#include <drm_crtc_helper.h>
+#include <drm_crtc.h>
+#include <drm_edid.h>
+#include <drm_mipi_dsi.h>
+
+#define PAGE2_SPI_CFG3		0x82
+#define I2C_TO_SPI_RESET	0x20
+#define PAGE2_ROMADD_BYTE1	0x8e
+#define PAGE2_ROMADD_BYTE2	0x8f
+#define PAGE2_SWSPI_WDATA	0x90
+#define PAGE2_SWSPI_RDATA	0x91
+#define PAGE2_SWSPI_LEN		0x92
+#define PAGE2_SWSPI_CTL		0x93
+#define TRIGGER_NO_READBACK	0x05
+#define TRIGGER_READBACK	0x01
+#define PAGE2_SPI_STATUS	0x9e
+#define PAGE2_GPIO_L		0xa6
+#define PAGE2_GPIO_H		0xa7
+#define PS_GPIO9		BIT(1)
+#define PAGE2_IROM_CTRL		0xb0
+#define IROM_ENABLE		0xc0
+#define IROM_DISABLE		0x80
+#define PAGE2_SW_REST		0xbc
+#define SPI_SW_RESET		BIT(7)
+#define MPU_SW_RESET		BIT(6)
+#define PAGE2_ENCTLSPI_WR	0xda
+#define PAGE2_I2C_BYPASS	0xea
+#define I2C_BYPASS_EN		0xd0
+#define PAGE3_SET_ADD		0xfe
+#define PAGE3_SET_VAL		0xff
+#define VDO_CTL_ADD		0x13
+#define VDO_DIS			0x18
+#define VDO_EN			0x1c
+#define PAGE4_REV_L		0xf0
+#define PAGE4_REV_H		0xf1
+#define PAGE4_CHIP_L		0xf2
+#define PAGE4_CHIP_H		0xf3
+
+/* Firmware */
+#define SPI_MAX_RETRY_CNT	8
+#define PS_FW_NAME		"ps864x_fw.bin"
+
+#define FW_CHIP_ID_OFFSET	0
+#define FW_VERSION_OFFSET	2
+#define EDID_I2C_ADDR		0x50
+
+#define WRITE_STATUS_REG_CMD	0x01
+#define READ_STATUS_REG_CMD	0x05
+#define CLEAR_ALL_PROTECT	0x00
+#define BLK_PROTECT_BITS	0x0c
+#define STATUS_REG_PROTECT	BIT(7)
+#define WRITE_ENABLE_CMD	0x06
+#define CHIP_ERASE_CMD		0xc7
+
+#define bridge_to_ps8640(e)	container_of(e, struct ps8640, bridge)
+#define connector_to_ps8640(e)	container_of(e, struct ps8640, connector)
+
+struct ps8640_info {
+	u8 family_id;
+	u8 variant_id;
+	u16 version;
+};
+
+struct ps8640 {
+	struct drm_connector connector;
+	struct drm_bridge bridge;
+	struct edid *edid;
+	struct mipi_dsi_device *dsi;
+	struct i2c_client *page[8];
+	struct i2c_client *ddc_i2c;
+	struct regulator_bulk_data supplies[2];
+	struct drm_panel *panel;
+	struct gpio_desc *gpio_rst_n;
+	struct gpio_desc *gpio_slp_n;
+	struct gpio_desc *gpio_mode_sel_n;
+	bool enabled;
+
+	/* firmware file info */
+	bool in_fw_update;
+	struct ps8640_info info;
+};
+
+static const u8 enc_ctrl_code[6] = {0xaa, 0x55, 0x50, 0x41, 0x52, 0x44};
+
+static int ps8640_read(struct i2c_client *client, u8 reg, u8 *data,
+		       u16 data_len)
+{
+	int ret;
+	struct i2c_msg msgs[] = {
+		{
+		 .addr = client->addr,
+		 .flags = 0,
+		 .len = 1,
+		 .buf = &reg,
+		 },
+		{
+		 .addr = client->addr,
+		 .flags = I2C_M_RD,
+		 .len = data_len,
+		 .buf = data,
+		 }
+	};
+
+	ret = i2c_transfer(client->adapter, msgs, 2);
+
+	if (ret == 2)
+		return 0;
+	if (ret < 0)
+		return ret;
+	else
+		return -EIO;
+}
+
+static int ps8640_write_bytes(struct i2c_client *client, u8 *data,
+			      u16 data_len)
+{
+	int ret;
+	struct i2c_msg msg;
+
+	msg.addr = client->addr;
+	msg.flags = 0;
+	msg.len = data_len;
+	msg.buf = data;
+
+	ret = i2c_transfer(client->adapter, &msg, 1);
+	if (ret == 1)
+		return 0;
+	if (ret < 0)
+		return ret;
+	else
+		return -EIO;
+}
+
+static int ps8640_write_byte(struct i2c_client *client, u8 reg,  u8 data)
+{
+	int ret;
+	struct i2c_msg msg;
+	u8 buf[] = {reg, data};
+
+	msg.addr = client->addr;
+	msg.flags = 0;
+	msg.len = sizeof(buf);
+	msg.buf = buf;
+
+	ret = i2c_transfer(client->adapter, &msg, 1);
+	if (ret == 1)
+		return 0;
+	if (ret < 0)
+		return ret;
+	else
+		return -EIO;
+}
+
+static void ps8640_get_mcu_fw_version(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[5];
+	u8 fw_ver[2];
+
+	ps8640_read(client, 0x4, fw_ver, 2);
+	ps_bridge->info.version = (fw_ver[0] << 8) | fw_ver[1];
+
+	DRM_INFO_ONCE("ps8640 rom fw version %d.%d\n", fw_ver[0], fw_ver[1]);
+}
+
+static int ps8640_bridge_enable(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[3];
+	u8 vdo_ctrl_buf[3] = {PAGE3_SET_ADD, VDO_CTL_ADD, VDO_EN};
+
+	return ps8640_write_bytes(client, vdo_ctrl_buf, 3);
+}
+
+static int ps8640_bridge_disable(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[3];
+	u8 vdo_ctrl_buf[3] = {PAGE3_SET_ADD, VDO_CTL_ADD, VDO_DIS};
+
+	return ps8640_write_bytes(client, vdo_ctrl_buf, 3);
+}
+
+static void ps8640_pre_enable(struct drm_bridge *bridge)
+{
+	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+	struct i2c_client *client = ps_bridge->page[2];
+	int err, retry_cnt = 0;
+	u8 set_vdo_done;
+
+	if (ps_bridge->in_fw_update)
+		return;
+
+	if (ps_bridge->enabled)
+		return;
+
+	err = drm_panel_prepare(ps_bridge->panel);
+	if (err < 0) {
+		DRM_ERROR("failed to prepare panel: %d\n", err);
+		return;
+	}
+
+	gpiod_set_value(ps_bridge->gpio_slp_n, 1);
+	gpiod_set_value(ps_bridge->gpio_rst_n, 0);
+
+	err = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
+				    ps_bridge->supplies);
+	if (err < 0) {
+		DRM_ERROR("cannot enable regulators %d\n", err);
+		goto err_panel_unprepare;
+	}
+
+	usleep_range(500, 700);
+	gpiod_set_value(ps_bridge->gpio_rst_n, 1);
+
+	/*
+	 * Wait for the ps8640 embed mcu ready
+	 * First wait 200ms and then check the mcu ready flag every 20ms
+	 */
+	msleep(200);
+	do {
+		err = ps8640_read(client, PAGE2_GPIO_H, &set_vdo_done, 1);
+		if (err < 0) {
+			DRM_ERROR("failed read PAGE2_GPIO_H: %d\n", err);
+			goto err_regulators_disable;
+		}
+		msleep(20);
+	} while ((retry_cnt++ < 10) && ((set_vdo_done & PS_GPIO9) != PS_GPIO9));
+
+	if (ps_bridge->info.version == 0)
+		ps8640_get_mcu_fw_version(ps_bridge);
+	/* Switch access edp panel's edid through i2c */
+	ps8640_write_byte(client, PAGE2_I2C_BYPASS, I2C_BYPASS_EN);
+	ps_bridge->enabled = true;
+
+	return;
+
+err_regulators_disable:
+	regulator_bulk_disable(ARRAY_SIZE(ps_bridge->supplies),
+			       ps_bridge->supplies);
+err_panel_unprepare:
+	drm_panel_unprepare(ps_bridge->panel);
+}
+
+static void ps8640_enable(struct drm_bridge *bridge)
+{
+	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+	int err;
+
+	err = ps8640_bridge_enable(ps_bridge);
+	if (err)
+		DRM_ERROR("failed to enable unmutevideo: %d\n", err);
+
+	err = drm_panel_enable(ps_bridge->panel);
+	if (err < 0)
+		DRM_ERROR("failed to enable panel: %d\n", err);
+}
+
+static void ps8640_disable(struct drm_bridge *bridge)
+{
+	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+	int err;
+
+	err = drm_panel_disable(ps_bridge->panel);
+	if (err < 0)
+		DRM_ERROR("failed to disable panel: %d\n", err);
+
+	err = ps8640_bridge_disable(ps_bridge);
+	if (err < 0)
+		DRM_ERROR("failed to disable bridge: %d\n", err);
+}
+
+static void ps8640_post_disable(struct drm_bridge *bridge)
+{
+	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+	int err;
+
+	if (ps_bridge->in_fw_update)
+		return;
+
+	if (!ps_bridge->enabled)
+		return;
+
+	ps_bridge->enabled = false;
+
+	gpiod_set_value(ps_bridge->gpio_rst_n, 0);
+	gpiod_set_value(ps_bridge->gpio_slp_n, 0);
+	err = regulator_bulk_disable(ARRAY_SIZE(ps_bridge->supplies),
+				     ps_bridge->supplies);
+	if (err < 0)
+		DRM_ERROR("cannot disable regulators %d\n", err);
+
+	err = drm_panel_unprepare(ps_bridge->panel);
+	if (err)
+		DRM_ERROR("failed to unprepare panel: %d\n", err);
+}
+
+static int ps8640_get_modes(struct drm_connector *connector)
+{
+	struct ps8640 *ps_bridge = connector_to_ps8640(connector);
+	u8 *edid;
+	int ret, num_modes = 0;
+	bool power_off;
+
+	if (ps_bridge->edid)
+		return drm_add_edid_modes(connector, ps_bridge->edid);
+
+	power_off = !ps_bridge->enabled;
+	ps8640_pre_enable(&ps_bridge->bridge);
+
+	edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
+	if (!edid) {
+		DRM_ERROR("Failed to allocate EDID\n");
+		return 0;
+	}
+
+	ret = ps8640_read(ps_bridge->ddc_i2c, 0, edid, EDID_LENGTH);
+	if (ret) {
+		kfree(edid);
+		goto out;
+	}
+
+	ps_bridge->edid = (struct edid *)edid;
+	drm_mode_connector_update_edid_property(connector, ps_bridge->edid);
+
+	num_modes = drm_add_edid_modes(connector, ps_bridge->edid);
+
+out:
+	if (power_off)
+		ps8640_post_disable(&ps_bridge->bridge);
+
+	return num_modes;
+}
+
+static struct drm_encoder *ps8640_best_encoder(struct drm_connector *connector)
+{
+	struct ps8640 *ps_bridge;
+
+	ps_bridge = connector_to_ps8640(connector);
+	return ps_bridge->bridge.encoder;
+}
+
+static const struct drm_connector_helper_funcs ps8640_connector_helper_funcs = {
+	.get_modes = ps8640_get_modes,
+	.best_encoder = ps8640_best_encoder,
+};
+
+static enum drm_connector_status ps8640_detect(struct drm_connector *connector,
+					       bool force)
+{
+	return connector_status_connected;
+}
+
+static void ps8640_connector_destroy(struct drm_connector *connector)
+{
+	drm_connector_unregister(connector);
+	drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs ps8640_connector_funcs = {
+	.dpms = drm_atomic_helper_connector_dpms,
+	.fill_modes = drm_helper_probe_single_connector_modes,
+	.detect = ps8640_detect,
+	.destroy = ps8640_connector_destroy,
+	.reset = drm_atomic_helper_connector_reset,
+	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+int ps8640_bridge_attach(struct drm_bridge *bridge)
+{
+	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+	struct device *dev = &ps_bridge->page[0]->dev;
+	struct device_node *np = dev->of_node;
+	struct device_node *port, *in_ep;
+	struct device_node *dsi_node = NULL;
+	struct mipi_dsi_host *host = ps_bridge->dsi->host;
+	int ret;
+
+	ret = drm_connector_init(bridge->dev, &ps_bridge->connector,
+				 &ps8640_connector_funcs,
+				 DRM_MODE_CONNECTOR_eDP);
+
+	if (ret) {
+		DRM_ERROR("Failed to initialize connector with drm: %d\n", ret);
+		return ret;
+	}
+
+	drm_connector_helper_add(&ps_bridge->connector,
+				 &ps8640_connector_helper_funcs);
+	drm_connector_register(&ps_bridge->connector);
+
+	ps_bridge->connector.dpms = DRM_MODE_DPMS_ON;
+	drm_mode_connector_attach_encoder(&ps_bridge->connector,
+					  bridge->encoder);
+
+	if (ps_bridge->panel)
+		drm_panel_attach(ps_bridge->panel, &ps_bridge->connector);
+
+	/* port at 0 is ps8640 dsi input port */
+	port = of_graph_get_port_by_id(np, 0);
+	if (port) {
+		in_ep = of_get_child_by_name(port, "endpoint");
+		of_node_put(port);
+		if (in_ep) {
+			dsi_node = of_graph_get_remote_port_parent(in_ep);
+			of_node_put(in_ep);
+		}
+	}
+	if (dsi_node) {
+		host = of_find_mipi_dsi_host_by_node(dsi_node);
+		of_node_put(dsi_node);
+		if (!host)
+			return -ENODEV;
+	}
+
+	ps_bridge->dsi->host = host;
+	ps_bridge->dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
+				     MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
+	ps_bridge->dsi->format = MIPI_DSI_FMT_RGB888;
+	ps_bridge->dsi->lanes = 4;
+	ret = mipi_dsi_attach(ps_bridge->dsi);
+	if (ret) {
+		drm_panel_detach(ps_bridge->panel);
+		return ret;
+	}
+
+	return ret;
+}
+
+static const struct drm_bridge_funcs ps8640_bridge_funcs = {
+	.attach = ps8640_bridge_attach,
+	.disable = ps8640_disable,
+	.post_disable = ps8640_post_disable,
+	.pre_enable = ps8640_pre_enable,
+	.enable = ps8640_enable,
+};
+
+/* Firmware Version is returned as Major.Minor.Build */
+static ssize_t ps8640_fw_version_show(struct device *dev,
+				      struct device_attribute *attr, char *buf)
+{
+	struct ps8640 *ps_bridge = dev_get_drvdata(dev);
+	struct ps8640_info *info = &ps_bridge->info;
+
+	return scnprintf(buf, PAGE_SIZE, "%u.%u\n", info->version >> 8,
+			 info->version & 0xff);
+}
+
+/* Hardware Version is returned as FamilyID.VariantID */
+static ssize_t ps8640_hw_version_show(struct device *dev,
+				      struct device_attribute *attr, char *buf)
+{
+	struct ps8640 *ps_bridge = dev_get_drvdata(dev);
+	struct ps8640_info *info = &ps_bridge->info;
+
+	return scnprintf(buf, PAGE_SIZE, "ps%u.%u\n", info->family_id,
+			 info->variant_id);
+}
+
+static int ps8640_spi_send_cmd(struct ps8640 *ps_bridge, u8 *cmd, u8 cmd_len)
+{
+	struct i2c_client *client = ps_bridge->page[2];
+	u8 i, buf[3];
+	int ret;
+
+	ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_ENABLE);
+	if (ret)
+		goto err;
+
+	/* write command in write port */
+	for (i = 0; i < cmd_len; i++) {
+		ret = ps8640_write_byte(client, PAGE2_SWSPI_WDATA, cmd[i]);
+		if (ret)
+			goto err;
+	}
+
+	buf[0] = PAGE2_SWSPI_LEN;
+	buf[1] = cmd_len - 1;
+	buf[2] = TRIGGER_NO_READBACK;
+	ret = ps8640_write_bytes(client, buf, 3);
+	if (ret)
+		goto err;
+
+	ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
+	if (ret)
+		goto err;
+
+	return 0;
+
+err:
+	dev_err(&client->dev, "send command err: %d\n", ret);
+	return ret;
+}
+
+static int ps8640_wait_spi_ready(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[2];
+	u8 spi_rdy_st, retry_cnt = 0;
+
+	do {
+		ps8640_read(client, PAGE2_SPI_STATUS, &spi_rdy_st, 1);
+		msleep(20);
+		if ((retry_cnt == SPI_MAX_RETRY_CNT) &&
+		    ((spi_rdy_st & 0x0c) != 0x0c)) {
+			dev_err(&client->dev, "wait spi ready timeout\n");
+			return -EBUSY;
+		}
+	} while ((retry_cnt++ < SPI_MAX_RETRY_CNT) &&
+		 (spi_rdy_st & 0x0c) == 0x0c);
+
+	return 0;
+}
+
+static int ps8640_wait_spi_nobusy(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[2];
+	u8 spi_status, buf[3], retry_cnt = 0;
+	int ret;
+
+	do {
+		/* 0x05 RDSR; Read-Status-Register */
+		ret = ps8640_write_byte(client, PAGE2_SWSPI_WDATA,
+					READ_STATUS_REG_CMD);
+		if (ret)
+			goto err_send_cmd_exit;
+
+		buf[0] = PAGE2_SWSPI_LEN;
+		buf[1] = 0;
+		buf[2] = TRIGGER_READBACK;
+		ret = ps8640_write_bytes(client, buf, 3);
+		if (ret)
+			goto err_send_cmd_exit;
+
+		/* delay for cmd send */
+		usleep_range(100, 300);
+		/* wait for SPI ROM until not busy */
+		ret = ps8640_read(client, PAGE2_SWSPI_RDATA, &spi_status, 1);
+		if (ret)
+			goto err_send_cmd_exit;
+	} while ((retry_cnt++ < SPI_MAX_RETRY_CNT) &&
+		 (spi_status & BLK_PROTECT_BITS) == BLK_PROTECT_BITS);
+
+	if ((retry_cnt > SPI_MAX_RETRY_CNT) &&
+	    (spi_status & BLK_PROTECT_BITS) != BLK_PROTECT_BITS) {
+		ret = -EBUSY;
+		dev_err(&client->dev, "wait spi no busy timeout: %d\n", ret);
+		goto err_timeout;
+	}
+
+	return 0;
+
+err_send_cmd_exit:
+	dev_err(&client->dev, "send command err: %d\n", ret);
+
+err_timeout:
+	return ret;
+}
+
+static int ps8640_wait_rom_idle(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[0];
+	int ret;
+
+	ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_ENABLE);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_wait_spi_ready(ps_bridge);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_wait_spi_nobusy(ps_bridge);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
+	if (ret)
+		goto exit;
+
+exit:
+	if (ret)
+		dev_err(&client->dev, "wait ps8640 rom idle fail: %d\n", ret);
+
+	return ret;
+}
+
+static int ps8640_spi_dl_mode(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[2];
+	int ret;
+
+	/* switch ps8640 mode to spi dl mode */
+	gpiod_set_value(ps_bridge->gpio_mode_sel_n, 0);
+
+	/* reset spi interface */
+	ret = ps8640_write_byte(client, PAGE2_SW_REST,
+				SPI_SW_RESET | MPU_SW_RESET);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_write_byte(client, PAGE2_SW_REST, MPU_SW_RESET);
+	if (ret)
+		goto exit;
+
+exit:
+	if (ret)
+		dev_err(&client->dev, "fail reset spi interface: %d\n", ret);
+
+	return ret;
+}
+
+static int ps8640_rom_prepare(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[2];
+	struct device *dev = &client->dev;
+	u8 i, cmd[2];
+	int ret;
+
+	cmd[0] = WRITE_ENABLE_CMD;
+	ret = ps8640_spi_send_cmd(ps_bridge, cmd, 1);
+	if (ret) {
+		dev_err(dev, "failed enable-write-status-register: %d\n", ret);
+		return ret;
+	}
+
+	cmd[0] = WRITE_STATUS_REG_CMD;
+	cmd[1] = CLEAR_ALL_PROTECT;
+	ret = ps8640_spi_send_cmd(ps_bridge, cmd, 2);
+	if (ret) {
+		dev_err(dev, "fail disable all protection: %d\n", ret);
+		return ret;
+	}
+
+	/* wait for SPI module ready */
+	ret = ps8640_wait_rom_idle(ps_bridge);
+	if (ret) {
+		dev_err(dev, "fail wait rom idle: %d\n", ret);
+		return ret;
+	}
+
+	ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_ENABLE);
+	for (i = 0; i < 6; i++)
+		ps8640_write_byte(client, PAGE2_ENCTLSPI_WR, enc_ctrl_code[i]);
+	ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
+
+	/* Enable-Write-Status-Register */
+	cmd[0] = WRITE_ENABLE_CMD;
+	ret = ps8640_spi_send_cmd(ps_bridge, cmd, 1);
+	if (ret) {
+		dev_err(dev, "fail enable-write-status-register: %d\n", ret);
+		return ret;
+	}
+
+	/* chip erase command */
+	cmd[0] = CHIP_ERASE_CMD;
+	ret = ps8640_spi_send_cmd(ps_bridge, cmd, 1);
+	if (ret) {
+		dev_err(dev, "fail disable all protection: %d\n", ret);
+		return ret;
+	}
+
+	ret = ps8640_wait_rom_idle(ps_bridge);
+	if (ret) {
+		dev_err(dev, "fail wait rom idle: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int ps8640_validate_firmware(struct ps8640 *ps_bridge,
+				    const struct firmware *fw)
+{
+	struct i2c_client *client = ps_bridge->page[0];
+	struct ps8640_info *info = &ps_bridge->info;
+	u16 fw_chip_id, fw_version_id;
+
+	/*
+	 * Get the chip_id from the firmware. Make sure that it is the
+	 * right controller to do the firmware and config update.
+	 */
+	fw_chip_id = get_unaligned_le16(fw->data + FW_CHIP_ID_OFFSET);
+
+	if (fw_chip_id != 0x8640) {
+		dev_err(&client->dev,
+			"chip id mismatch: fw 0x%x vs. chip 0x8640\n",
+			fw_chip_id);
+		return -ENODEV;
+	}
+
+	fw_version_id = get_unaligned_le16(fw->data + FW_VERSION_OFFSET);
+
+	if (fw_chip_id == info->version) {
+		dev_err(&client->dev,
+			"no need update fw version same: fw %d.%d vs. chip %d.%d\n",
+			fw_version_id >> 8, fw_version_id & 0xff,
+			info->version >> 8, info->version & 0xff);
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+static int ps8640_write_rom(struct ps8640 *ps_bridge, const struct firmware *fw)
+{
+	struct i2c_client *client = ps_bridge->page[0];
+	struct device *dev = &client->dev;
+	struct i2c_client *client2 = ps_bridge->page[2];
+	struct i2c_client *client7 = ps_bridge->page[7];
+	unsigned int pos = 0;
+	u8 buf[257], rom_page_id_buf[3];
+	int ret;
+	u16 cpy_len;
+
+	ps8640_write_byte(client2, PAGE2_SPI_CFG3, I2C_TO_SPI_RESET);
+	msleep(100);
+	ps8640_write_byte(client2, PAGE2_SPI_CFG3, 0x00);
+
+	while (pos < fw->size) {
+		rom_page_id_buf[0] = PAGE2_ROMADD_BYTE1;
+		rom_page_id_buf[1] = (pos >> 8) & 0xff;
+		rom_page_id_buf[2] = (pos >> 16) & 0xff;
+		ret = ps8640_write_bytes(client2, rom_page_id_buf, 3);
+		if (ret)
+			goto error;
+		cpy_len = fw->size >= 256 + pos ? 256 : fw->size - pos;
+		buf[0] = 0;
+		memcpy(buf + 1, fw->data + pos, cpy_len);
+		ret = ps8640_write_bytes(client7, buf, cpy_len + 1);
+		if (ret)
+			goto error;
+
+		pos += cpy_len;
+
+		dev_dbg(dev, "fw update completed %u / %zu bytes\n", pos,
+			fw->size);
+	}
+	return 0;
+
+error:
+	dev_err(dev, "failed write extenal flash, %d\n", ret);
+	return ret;
+}
+
+static int ps8640_spi_normal_mode(struct ps8640 *ps_bridge)
+{
+	u8 cmd[2];
+	struct i2c_client *client = ps_bridge->page[2];
+
+	/* Enable-Write-Status-Register */
+	cmd[0] = WRITE_ENABLE_CMD;
+	ps8640_spi_send_cmd(ps_bridge, cmd, 1);
+
+	/* protect BPL/BP0/BP1 */
+	cmd[0] = WRITE_STATUS_REG_CMD;
+	cmd[1] = BLK_PROTECT_BITS | STATUS_REG_PROTECT;
+	ps8640_spi_send_cmd(ps_bridge, cmd, 2);
+
+	/* wait for SPI rom ready */
+	ps8640_wait_rom_idle(ps_bridge);
+
+	/* disable PS8640 mapping function */
+	ps8640_write_byte(client, PAGE2_ENCTLSPI_WR, 0x00);
+
+	gpiod_set_value(ps_bridge->gpio_mode_sel_n, 1);
+	return 0;
+}
+
+static int ps8640_enter_bl(struct ps8640 *ps_bridge)
+{
+	ps_bridge->in_fw_update = true;
+	return ps8640_spi_dl_mode(ps_bridge);
+}
+
+static void ps8640_exit_bl(struct ps8640 *ps_bridge, const struct firmware *fw)
+{
+	ps8640_spi_normal_mode(ps_bridge);
+	ps_bridge->in_fw_update = false;
+}
+
+static int ps8640_load_fw(struct ps8640 *ps_bridge, const struct firmware *fw)
+{
+	struct i2c_client *client = ps_bridge->page[0];
+	struct device *dev = &client->dev;
+	int ret;
+	bool ps8640_status_backup = ps_bridge->enabled;
+
+	if (!ps_bridge->in_fw_update) {
+		if (!ps8640_status_backup)
+			ps8640_pre_enable(&ps_bridge->bridge);
+
+		ret = ps8640_enter_bl(ps_bridge);
+		if (ret)
+			goto exit;
+	}
+
+	ret = ps8640_validate_firmware(ps_bridge, fw);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_rom_prepare(ps_bridge);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_write_rom(ps_bridge, fw);
+
+exit:
+	if (ret)
+		dev_err(dev, "Failed to load firmware, %d\n", ret);
+
+	ps8640_exit_bl(ps_bridge, fw);
+	if (!ps8640_status_backup)
+		ps8640_post_disable(&ps_bridge->bridge);
+	return ret;
+}
+
+static ssize_t ps8640_update_fw_store(struct device *dev,
+				      struct device_attribute *attr,
+				      const char *buf, size_t count)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct ps8640 *ps_bridge = i2c_get_clientdata(client);
+	const struct firmware *fw;
+	int error;
+
+	error = request_firmware(&fw, PS_FW_NAME, dev);
+	if (error) {
+		dev_err(dev, "Unable to open firmware %s: %d\n",
+			PS_FW_NAME, error);
+		return error;
+	}
+
+	error = ps8640_load_fw(ps_bridge, fw);
+	if (error)
+		dev_err(dev, "The firmware update failed(%d)\n", error);
+	else
+		dev_info(dev, "The firmware update succeeded\n");
+
+	release_firmware(fw);
+	return error ? error : count;
+}
+
+static DEVICE_ATTR(fw_version, S_IRUGO, ps8640_fw_version_show, NULL);
+static DEVICE_ATTR(hw_version, S_IRUGO, ps8640_hw_version_show, NULL);
+static DEVICE_ATTR(update_fw, S_IWUSR, NULL, ps8640_update_fw_store);
+
+static struct attribute *ps8640_attrs[] = {
+	&dev_attr_fw_version.attr,
+	&dev_attr_hw_version.attr,
+	&dev_attr_update_fw.attr,
+	NULL
+};
+
+static const struct attribute_group ps8640_attr_group = {
+	.attrs = ps8640_attrs,
+};
+
+static void ps8640_remove_sysfs_group(void *data)
+{
+	struct ps8640 *ps_bridge = data;
+
+	sysfs_remove_group(&ps_bridge->page[0]->dev.kobj, &ps8640_attr_group);
+}
+
+static int ps8640_probe(struct i2c_client *client,
+			const struct i2c_device_id *id)
+{
+	struct device *dev = &client->dev;
+	struct ps8640 *ps_bridge;
+	struct device_node *np = dev->of_node;
+	struct device_node *port, *out_ep;
+	struct device_node *panel_node = NULL;
+	int i, ret;
+
+	ps_bridge = devm_kzalloc(dev, sizeof(*ps_bridge), GFP_KERNEL);
+	ps_bridge->dsi = devm_kzalloc(dev, sizeof(struct mipi_dsi_device),
+				      GFP_KERNEL);
+	if (!ps_bridge)
+		return -ENOMEM;
+
+	/* port at 1 is ps8640 output port */
+	port = of_graph_get_port_by_id(np, 1);
+	if (port) {
+		out_ep = of_get_child_by_name(port, "endpoint");
+		of_node_put(port);
+		if (out_ep) {
+			panel_node = of_graph_get_remote_port_parent(out_ep);
+			of_node_put(out_ep);
+		}
+	}
+	if (panel_node) {
+		ps_bridge->panel = of_drm_find_panel(panel_node);
+		of_node_put(panel_node);
+		if (!ps_bridge->panel)
+			return -EPROBE_DEFER;
+	}
+
+	ps_bridge->supplies[0].supply = "vdd33";
+	ps_bridge->supplies[1].supply = "vdd12";
+	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ps_bridge->supplies),
+				      ps_bridge->supplies);
+	if (ret) {
+		dev_info(dev, "failed to get regulators: %d\n", ret);
+		return -EPROBE_DEFER;
+	}
+
+	ps_bridge->gpio_mode_sel_n = devm_gpiod_get(&client->dev, "mode-sel",
+						    GPIOD_OUT_HIGH);
+	if (IS_ERR(ps_bridge->gpio_mode_sel_n)) {
+		ret = PTR_ERR(ps_bridge->gpio_mode_sel_n);
+		dev_err(dev, "cannot get mode-sel %d\n", ret);
+		return ret;
+	}
+
+	ps_bridge->gpio_slp_n = devm_gpiod_get(&client->dev, "sleep",
+					       GPIOD_OUT_HIGH);
+	if (IS_ERR(ps_bridge->gpio_slp_n)) {
+		ret = PTR_ERR(ps_bridge->gpio_slp_n);
+		dev_err(dev, "cannot get sleep: %d\n", ret);
+		return ret;
+	}
+
+	ps_bridge->gpio_rst_n = devm_gpiod_get(&client->dev, "reset",
+					       GPIOD_OUT_HIGH);
+	if (IS_ERR(ps_bridge->gpio_rst_n)) {
+		ret = PTR_ERR(ps_bridge->gpio_rst_n);
+		dev_err(dev, "cannot get reset: %d\n", ret);
+		return ret;
+	}
+
+	ps_bridge->bridge.funcs = &ps8640_bridge_funcs;
+	ps_bridge->bridge.of_node = dev->of_node;
+	ret = drm_bridge_add(&ps_bridge->bridge);
+	if (ret) {
+		dev_err(dev, "Failed to add bridge: %d\n", ret);
+		return ret;
+	}
+
+	ps_bridge->page[0] = client;
+	ps_bridge->ddc_i2c = i2c_new_dummy(client->adapter, EDID_I2C_ADDR);
+	if (!ps_bridge->ddc_i2c) {
+		dev_err(dev, "failed ddc_i2c dummy device, address%02x\n",
+			EDID_I2C_ADDR);
+		ret = -EBUSY;
+		goto exit_ddc_i2c_dummy;
+	}
+	/*
+	 * ps8640 uses multiple addresses, use dummy devices for them
+	 * page[0]: for DP control
+	 * page[1]: for VIDEO Bridge
+	 * page[2]: for control top
+	 * page[3]: for DSI Link Control1
+	 * page[4]: for MIPI Phy
+	 * page[5]: for VPLL
+	 * page[6]: for DSI Link Control2
+	 * page[7]: for spi rom mapping
+	 */
+	for (i = 1; i < 8; i++) {
+		ps_bridge->page[i] = i2c_new_dummy(client->adapter,
+						   client->addr + i);
+		if (!ps_bridge->page[i]) {
+			dev_err(dev, "failed i2c dummy device, address%02x\n",
+				client->addr + i);
+			ret = -EBUSY;
+			goto exit_dummy;
+		}
+	}
+	i2c_set_clientdata(client, ps_bridge);
+
+	ret = sysfs_create_group(&client->dev.kobj, &ps8640_attr_group);
+	if (ret) {
+		dev_err(dev, "failed to create sysfs entries: %d\n", ret);
+		goto exit_dummy;
+	}
+
+	ret = devm_add_action(dev, ps8640_remove_sysfs_group, ps_bridge);
+	if (ret) {
+		dev_err(dev, "failed to add sysfs cleanup action: %d\n", ret);
+		goto exit_remove_sysfs;
+	}
+	return 0;
+
+exit_remove_sysfs:
+	sysfs_remove_group(&ps_bridge->page[0]->dev.kobj, &ps8640_attr_group);
+exit_dummy:
+	for (i = 1; i < 8; i++)
+		if (ps_bridge->page[i])
+			i2c_unregister_device(ps_bridge->page[i]);
+exit_ddc_i2c_dummy:
+	drm_bridge_remove(&ps_bridge->bridge);
+	return ret;
+}
+
+static int ps8640_remove(struct i2c_client *client)
+{
+	struct ps8640 *ps_bridge = i2c_get_clientdata(client);
+	int i;
+
+	for (i = 1; i < 8; i++)
+		i2c_unregister_device(ps_bridge->page[i]);
+
+	drm_bridge_remove(&ps_bridge->bridge);
+
+	return 0;
+}
+
+static const struct i2c_device_id ps8640_i2c_table[] = {
+	{"parade,ps8640", 0},
+	{},
+};
+MODULE_DEVICE_TABLE(i2c, ps8640_i2c_table);
+
+static const struct of_device_id ps8640_match[] = {
+	{ .compatible = "parade,ps8640" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, ps8640_match);
+
+static struct i2c_driver ps8640_driver = {
+	.id_table = ps8640_i2c_table,
+	.probe = ps8640_probe,
+	.remove = ps8640_remove,
+	.driver = {
+		.name = "parade,ps8640",
+		.of_match_table = ps8640_match,
+	},
+};
+module_i2c_driver(ps8640_driver);
+
+MODULE_AUTHOR("Jitao Shi <jitao.shi at mediatek.com>");
+MODULE_AUTHOR("CK Hu <ck.hu at mediatek.com>");
+MODULE_DESCRIPTION("PARADE ps8640 DSI-eDP converter driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5



From christoffer.dall at linaro.org  Wed Feb  3 00:49:13 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 3 Feb 2016 09:49:13 +0100
Subject: [PATCH v2 21/21] arm64: Panic when VHE and non VHE CPUs coexist
In-Reply-To: <56B0CBF4.9030507@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-22-git-send-email-marc.zyngier@arm.com>
 <20160201153605.GA1478@cbox> <56B0CBF4.9030507@arm.com>
Message-ID: <20160203084913.GA13974@cbox>

On Tue, Feb 02, 2016 at 03:32:04PM +0000, Marc Zyngier wrote:
> On 01/02/16 15:36, Christoffer Dall wrote:
> > On Mon, Jan 25, 2016 at 03:53:55PM +0000, Marc Zyngier wrote:
> >> Having both VHE and non-VHE capable CPUs in the same system
> >> is likely to be a recipe for disaster.
> >>
> >> If the boot CPU has VHE, but a secondary is not, we won't be
> >> able to downgrade and run the kernel at EL1. Add CPU hotplug
> >> to the mix, and this produces a terrifying mess.
> >>
> >> Let's solve the problem once and for all. If you mix VHE and
> >> non-VHE CPUs in the same system, you deserve to loose, and this
> >> patch makes sure you don't get a chance.
> >>
> >> This is implemented by storing the kernel execution level in
> >> a global variable. Secondaries will park themselves in a
> >> WFI loop if they observe a mismatch. Also, the primary CPU
> >> will detect that the secondary CPU has died on a mismatched
> >> execution level. Panic will follow.
> >>
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >> ---
> >>  arch/arm64/include/asm/virt.h | 17 +++++++++++++++++
> >>  arch/arm64/kernel/head.S      | 19 +++++++++++++++++++
> >>  arch/arm64/kernel/smp.c       |  3 +++
> >>  3 files changed, 39 insertions(+)
> >>
> >> diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
> >> index 9f22dd6..f81a345 100644
> >> --- a/arch/arm64/include/asm/virt.h
> >> +++ b/arch/arm64/include/asm/virt.h
> >> @@ -36,6 +36,11 @@
> >>   */
> >>  extern u32 __boot_cpu_mode[2];
> >>  
> >> +/*
> >> + * __run_cpu_mode records the mode the boot CPU uses for the kernel.
> >> + */
> >> +extern u32 __run_cpu_mode[2];
> >> +
> >>  void __hyp_set_vectors(phys_addr_t phys_vector_base);
> >>  phys_addr_t __hyp_get_vectors(void);
> >>  
> >> @@ -60,6 +65,18 @@ static inline bool is_kernel_in_hyp_mode(void)
> >>  	return el == CurrentEL_EL2;
> >>  }
> >>  
> >> +static inline bool is_kernel_mode_mismatched(void)
> >> +{
> >> +	/*
> >> +	 * A mismatched CPU will have written its own CurrentEL in
> >> +	 * __run_cpu_mode[1] (initially set to zero) after failing to
> >> +	 * match the value in __run_cpu_mode[0]. Thus, a non-zero
> >> +	 * value in __run_cpu_mode[1] is enough to detect the
> >> +	 * pathological case.
> >> +	 */
> >> +	return !!ACCESS_ONCE(__run_cpu_mode[1]);
> >> +}
> >> +
> >>  /* The section containing the hypervisor text */
> >>  extern char __hyp_text_start[];
> >>  extern char __hyp_text_end[];
> >> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> >> index 2a7134c..bc44cf8 100644
> >> --- a/arch/arm64/kernel/head.S
> >> +++ b/arch/arm64/kernel/head.S
> >> @@ -577,7 +577,23 @@ ENTRY(set_cpu_boot_mode_flag)
> >>  1:	str	w20, [x1]			// This CPU has booted in EL1
> >>  	dmb	sy
> >>  	dc	ivac, x1			// Invalidate potentially stale cache line
> >> +	adr_l	x1, __run_cpu_mode
> >> +	ldr	w0, [x1]
> >> +	mrs	x20, CurrentEL
> >> +	cbz	x0, skip_el_check
> >> +	cmp	x0, x20
> >> +	bne	mismatched_el
> > 
> > can't you do a ret here instead of writing the same value and flushing
> > caches etc.?
> 
> Yes, good point.
> 
> > 
> >> +skip_el_check:			// Only the first CPU gets to set the rule
> >> +	str	w20, [x1]
> >> +	dmb	sy
> >> +	dc	ivac, x1	// Invalidate potentially stale cache line
> >>  	ret
> >> +mismatched_el:
> >> +	str	w20, [x1, #4]
> >> +	dmb	sy
> >> +	dc	ivac, x1	// Invalidate potentially stale cache line
> >> +1:	wfi
> > 
> > I'm no expert on SMP bringup, but doesn't this prevent the CPU from
> > signaling completion and thus you'll never actually reach the checking
> > code in __cpu_up?
> 
> Indeed, and that's the whole point. The primary CPU will notice that the
> secondary CPU has failed to boot (timeout), and will find the reason in
> __run_cpu_mode.
> 
That wasn't exactly my point.  If I understand correctly and __cpu_up is
the primary CPU executing a function to bring up a secondary core, then
it will wait for the cpu_running completion which should be signalled by
the secondary core, but because the secondary core never makes any
progress it will timeout the wait for completion and you will see that
error "..failed to come online" instead of the "incompatible execution
level".

(This is based on my reading of the code as the completion is signalled
in secondary_start_kernl which happens after this stuff above in
head.S).

-Christoffer


From matthias.bgg at gmail.com  Wed Feb  3 01:00:15 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Wed, 3 Feb 2016 10:00:15 +0100
Subject: [PATCH v4 1/4] soc: mediatek: Refine scpsys to support multiple
 platform
In-Reply-To: <1454476968.2847.59.camel@mtksdaap41>
References: <1453270097-53853-1-git-send-email-jamesjj.liao@mediatek.com>
 <1453270097-53853-2-git-send-email-jamesjj.liao@mediatek.com>
 <56ADF556.6070402@gmail.com> <1454396212.2847.15.camel@mtksdaap41>
 <56B0889A.1010305@gmail.com> <1454476968.2847.59.camel@mtksdaap41>
Message-ID: <56B1C19F.9070300@gmail.com>



On 03/02/16 06:22, James Liao wrote:
> Hi Matthias,
>
> On Tue, 2016-02-02 at 11:44 +0100, Matthias Brugger wrote:
>> On 02/02/16 07:56, James Liao wrote:
>>> On Sun, 2016-01-31 at 12:51 +0100, Matthias Brugger wrote:
>>>>> On 20/01/16 07:08, James Liao wrote:
>>>>>>> Refine scpsys driver common code to support multiple SoC / platform.
>>>>>>>
>>>>>>> Signed-off-by: James Liao<jamesjj.liao at mediatek.com>
>>>>>>> ---
>>>>>>>    drivers/soc/mediatek/mtk-scpsys.c | 418 ++++++++++++++++++++------------------
>>>>>>>    drivers/soc/mediatek/mtk-scpsys.h |  55 +++++
>>>>>>>    2 files changed, 270 insertions(+), 203 deletions(-)
>>>>>>>    create mode 100644 drivers/soc/mediatek/mtk-scpsys.h
>>>>>
>>>>> In general this approach looks fine to me, comments below.
>>>>>
>>>>>>>
>>>>>>> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
>>>>>>> index 0221387..339adfc 100644
>>>>>>> --- a/drivers/soc/mediatek/mtk-scpsys.c
>>>>>>> +++ b/drivers/soc/mediatek/mtk-scpsys.c
>>>>>>> @@ -11,29 +11,17 @@
>>>>>>>     * GNU General Public License for more details.
>>>>>>>     */
>>>>>>>    #include <linux/clk.h>
>>>>>>> -#include <linux/delay.h>
>>>>>>> +#include <linux/init.h>
>>>>>>>    #include <linux/io.h>
>>>>>>> -#include <linux/kernel.h>
>>>>>>>    #include <linux/mfd/syscon.h>
>>>>>
>>>>> When at it, do we need this include?
>>> syscon_regmap_lookup_by_phandle() is declared in this head file.
>>>
>>>>>>> -#include <linux/init.h>
>>>>>>>    #include <linux/of_device.h>
>>>>>>>    #include <linux/platform_device.h>
>>>>>>>    #include <linux/pm_domain.h>
>>>>>>> -#include <linux/regmap.h>
>>>>>>> -#include <linux/soc/mediatek/infracfg.h>
>>>>>>>    #include <linux/regulator/consumer.h>
>>>>>>> -#include <dt-bindings/power/mt8173-power.h>
>>>>>>> +#include <linux/soc/mediatek/infracfg.h>
>>>>>>> +
>>>>>>> +#include "mtk-scpsys.h"
>>>>>>>
>>>>>>> -#define SPM_VDE_PWR_CON			0x0210
>>>>>>> -#define SPM_MFG_PWR_CON			0x0214
>>>>>>> -#define SPM_VEN_PWR_CON			0x0230
>>>>>>> -#define SPM_ISP_PWR_CON			0x0238
>>>>>>> -#define SPM_DIS_PWR_CON			0x023c
>>>>>>> -#define SPM_VEN2_PWR_CON		0x0298
>>>>>>> -#define SPM_AUDIO_PWR_CON		0x029c
>>>>>>> -#define SPM_MFG_2D_PWR_CON		0x02c0
>>>>>>> -#define SPM_MFG_ASYNC_PWR_CON		0x02c4
>>>>>>> -#define SPM_USB_PWR_CON			0x02cc
>>>>>
>>>>> I would prefer to keep this defines and declare SoC specific ones where
>>>>> necessary. It makes the code more readable.
>>> Some register address may be reused by other modules among SoCs, so it's
>>> not easy to maintain the defines when we implement multiple SoC drivers
>>> in the same file. For example, offset 0x0298 is VEN2_PWR_CON on MT8173,
>>> but it is MJC_PWR_CON on other chips.
>>>
>>
>> So that sounds as if 0x0298 offset is MT8173 specific.
>> I checked [VDE, MFG, VEN, IFR, ISP, DIS, DPY]_PWR_CON on mt8173, mt8135
>> and mt6589 and they all have the same offset. So it doesn't seem as if
>> the offset randomly changes for every SoC.
>>
>>> Furthermore, these register offsets are only used in scp_domain_data[],
>>> and each element has its own power domain name. So I think it's enough
>>> to know which power domain are using these registers and status bits.
>>>
>>
>> Yes that's true, but it will make it easier for another person to
>> understand the driver, especially if he want's to implement the driver
>> for a new SoC.
>
> There are two kinds of conflicts may happen:
>
> 1. Different modules use the same register address.
> 2. Different register addresses are used by the same module (on
> different IC).
>
> Type 1. for example:
>
> 	#define SPM_BDP_PWR_CON			0x029c /* 2701 */
> 	#define SPM_AUDIO_PWR_CON		0x029c /* 8173 */
>
> We can resolve this conflict easily, such as define these two register
> name to the same register address.
>
> Type 2. for example:
>
> 	#define SPM_VDE_PWR_CON			0x0300 /* 6755 */
> 	#define SPM_VDE_PWR_CON			0x0210 /* 8173 */
>
> We can not reuse the register defines in this case. We may need to name
> the registers with its IC name, such as MT8173_SPM_VDE_PWR_CON and
> MT6755_VDE_PWR_CON. But it will increase the maintain effort. That's why
> I prefer to remove register defines if we implement multiple SoC's
> scpsys in a single file.
>
>

Well type 2 for me is no problem at all. As stated in my last mail, 
mt6755 would get the SoC name in the define (as a postfix preferably).
I don't think that this will make a lot of pain regarding maintaining 
it. Even less if we have the defines in alphabetic order.

I we see in the future that this converts to a mess, we always can get 
rid of the defines quite easily.

Regards,
Matthias


From arnd at arndb.de  Wed Feb  3 01:07:33 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 03 Feb 2016 10:07:33 +0100
Subject: [PATCH 1/4] ARM: dts: ls1021a: add PCIe dts node
In-Reply-To: <VI1PR04MB16159CDCE9C134363846F4CAE8D00@VI1PR04MB1615.eurprd04.prod.outlook.com>
References: <1454401807-28751-1-git-send-email-Minghuan.Lian@nxp.com>
 <6117401.iajrHOL4Mn@wuerfel>
 <VI1PR04MB16159CDCE9C134363846F4CAE8D00@VI1PR04MB1615.eurprd04.prod.outlook.com>
Message-ID: <12992975.EIGaY2MJJY@wuerfel>

On Wednesday 03 February 2016 02:11:06 Minghuan Lian wrote:
> Hi Arnd,
> 
> I am sorry.
> Other patches are for MSI test, and not need to be summited.
> There is only one patch, should be [1/1] not [1/4].  I forgot to remove "1/4" 
> Should I re-summit to fix it?
> 

Ok, I see. It's up to Shawn then, I guess he can pick it up from
this submission if he's ok with the patch.

	Arnd


From arnd at arndb.de  Wed Feb  3 01:05:22 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 03 Feb 2016 10:05:22 +0100
Subject: [PATCH] video: ARM CLCD: runtime check for Versatile
In-Reply-To: <20160203004154.GA10826@n2100.arm.linux.org.uk>
References: <1454446059-30526-1-git-send-email-linus.walleij@linaro.org>
 <25978729.oSoMp4ZgxA@wuerfel> <20160203004154.GA10826@n2100.arm.linux.org.uk>
Message-ID: <5665949.mZpbM5Nbon@wuerfel>

On Wednesday 03 February 2016 00:41:54 Russell King - ARM Linux wrote:
> On Tue, Feb 02, 2016 at 10:10:49PM +0100, Arnd Bergmann wrote:
> > On Tuesday 02 February 2016 21:47:39 Linus Walleij wrote:
> > >         } else {
> > > -#ifdef CONFIG_ARCH_VERSATILE
> > > -               fb->off_ienb = CLCD_PL111_IENB;
> > > -               fb->off_cntl = CLCD_PL111_CNTL;
> > > -#else
> > > -               fb->off_ienb = CLCD_PL110_IENB;
> > > -               fb->off_cntl = CLCD_PL110_CNTL;
> > > -#endif
> > > +               if (of_machine_is_compatible("arm,versatile-ab") ||
> > > +                   of_machine_is_compatible("arm,versatile-pb")) {
> > > +                       fb->off_ienb = CLCD_PL111_IENB;
> > > +                       fb->off_cntl = CLCD_PL111_CNTL;
> > > +               } else {
> > > +                       fb->off_ienb = CLCD_PL110_IENB;
> > > +                       fb->off_cntl = CLCD_PL110_CNTL;
> > > +               }
> > >         }
> > > 
> > 
> > Could that be done based on the AMBA device ID instead?
> 
> Unfortunately not.  It's a mistake made on one Versatile board
> which reverses the registers.  There's nothing to distinguish it
> in the primecell itself.

Ok, I see. It would be nice to have this knowledge locally in
the driver, e.g. through a special compatible string for the
variant on the versatile, or a bool property, but this way seems
good enough as we can be reasonably sure that nobody else made the
same mistake.

	Arnd


From lkp at intel.com  Wed Feb  3 01:11:54 2016
From: lkp at intel.com (kbuild test robot)
Date: Wed, 3 Feb 2016 17:11:54 +0800
Subject: [PATCH net-next 2/4] drivers: net: xgene: Add support for RSS
In-Reply-To: <1454486116-23783-3-git-send-email-isubramanian@apm.com>
Message-ID: <201602031717.9mguWR0W%fengguang.wu@intel.com>

Hi Iyappan,

[auto build test WARNING on net-next/master]

url:    https://github.com/0day-ci/linux/commits/Iyappan-Subramanian/Add-support-for-Classifier-and-RSS/20160203-155838
config: i386-allmodconfig (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/net/ethernet/apm/xgene/xgene_enet_cle.c: In function 'xgene_enet_cle_init':
>> drivers/net/ethernet/apm/xgene/xgene_enet_cle.c:729:1: warning: the frame size of 1096 bytes is larger than 1024 bytes [-Wframe-larger-than=]
    }
    ^

vim +729 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c

bdc3a65f Iyappan Subramanian 2016-02-02  713  	dbptr[DB_RES_DROP].drop = 1;
bdc3a65f Iyappan Subramanian 2016-02-02  714  
bdc3a65f Iyappan Subramanian 2016-02-02  715  	memset(&kn, 0, sizeof(kn));
bdc3a65f Iyappan Subramanian 2016-02-02  716  	kn.node_type = KN;
bdc3a65f Iyappan Subramanian 2016-02-02  717  	kn.num_keys = 1;
bdc3a65f Iyappan Subramanian 2016-02-02  718  	kn.key[0].priority = 0;
bdc3a65f Iyappan Subramanian 2016-02-02  719  	kn.key[0].result_pointer = DB_RES_ACCEPT;
bdc3a65f Iyappan Subramanian 2016-02-02  720  
bdc3a65f Iyappan Subramanian 2016-02-02  721  	ptree->dn = ptree_dn;
bdc3a65f Iyappan Subramanian 2016-02-02  722  	ptree->kn = &kn;
bdc3a65f Iyappan Subramanian 2016-02-02  723  	ptree->dbptr = dbptr;
bdc3a65f Iyappan Subramanian 2016-02-02  724  	ptree->num_dn = MAX_NODES;
bdc3a65f Iyappan Subramanian 2016-02-02  725  	ptree->num_kn = 1;
bdc3a65f Iyappan Subramanian 2016-02-02  726  	ptree->num_dbptr = DB_MAX_PTRS;
bdc3a65f Iyappan Subramanian 2016-02-02  727  
bdc3a65f Iyappan Subramanian 2016-02-02  728  	return xgene_cle_setup_ptree(pdata, enet_cle);
bdc3a65f Iyappan Subramanian 2016-02-02 @729  }
bdc3a65f Iyappan Subramanian 2016-02-02  730  
bdc3a65f Iyappan Subramanian 2016-02-02  731  struct xgene_cle_ops xgene_cle3in_ops = {
bdc3a65f Iyappan Subramanian 2016-02-02  732  	.cle_init = xgene_enet_cle_init,
bdc3a65f Iyappan Subramanian 2016-02-02  733  };

:::::: The code at line 729 was first introduced by commit
:::::: bdc3a65fd7d47cc058cc913cfbd8f2934ef7f7a2 drivers: net: xgene: Add support for Classifier engine

:::::: TO: Iyappan Subramanian <isubramanian at apm.com>
:::::: CC: 0day robot <fengguang.wu at intel.com>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 53455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/5ee89788/attachment-0001.obj>

From arnd at arndb.de  Wed Feb  3 01:11:18 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 03 Feb 2016 10:11:18 +0100
Subject: [PATCH 03/10] arm64: add Armada 3700 architecture entry
In-Reply-To: <87k2mm5itx.fsf@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <20160203142451.41381ff6@xhacker> <87k2mm5itx.fsf@free-electrons.com>
Message-ID: <4284367.sAeqrVzAbo@wuerfel>

On Wednesday 03 February 2016 08:55:22 Gregory CLEMENT wrote:
> >> 
> >> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> >> index 21074f674bde..7da341f7b90d 100644
> >> --- a/arch/arm64/Kconfig.platforms
> >> +++ b/arch/arm64/Kconfig.platforms
> >> @@ -1,5 +1,11 @@
> >>  menu "Platform selection"
> >>  
> >> +config ARCH_ARMADA_3700
> >
> > Would it be better to use ARCH_MVEBU? IMHO, there will be more ARMv8 SoCs
> > from our EBU, do we plan to add one CONFIG_ARMADA_yyzz for each SoC?
> 
> Not for each SoC but for each family, yes. As we did for the other mvebu
> SoC families.
> 

We tend to use a little more general config strings for arm64 than we have
for arm32. I think just using ARCH_MVEBU is fine here, no need to list
the 3700 series separately.

	Arnd


From linux at arm.linux.org.uk  Wed Feb  3 01:13:31 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 3 Feb 2016 09:13:31 +0000
Subject: [PATCH 1/3] ARM: move .vectors and .stubs sections back into the
 kernel VMA
In-Reply-To: <CAKv+Gu_kYWczCazqgRC3y-n7s3WRTDhJXLO1RM1FE-6h1BhSUw@mail.gmail.com>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454419174-21290-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160203000351.GX10826@n2100.arm.linux.org.uk>
 <CAKv+Gu_kYWczCazqgRC3y-n7s3WRTDhJXLO1RM1FE-6h1BhSUw@mail.gmail.com>
Message-ID: <20160203091331.GB10826@n2100.arm.linux.org.uk>

On Wed, Feb 03, 2016 at 08:56:35AM +0100, Ard Biesheuvel wrote:
> On 3 February 2016 at 01:03, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Tue, Feb 02, 2016 at 02:19:32PM +0100, Ard Biesheuvel wrote:
> >> The sections themselves are emitted 4 KB apart, as required:
> >>   ...
> >>   [16] .stubs       PROGBITS   c0c35000 a35000 0002c0 00  AX  0   0 32
> >>   [17] .vectors     PROGBITS   c0c34000 a44000 000020 00  AX  0   0  2
> >>   ...
> >
> > ... which means we end up wasting most of a page for absolutely no
> > purpose what so ever.  Sorry, I'm really not happy about this
> > gratuitous wastage.
> >
> 
> No, we don't. Here's some more context:
> 
> Before:
>   [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>   [16] .vectors          PROGBITS        00000000 a40000 000020 00  AX  0   0  2
>   [17] .stubs            PROGBITS        00001000 a41000 0002c0 00  AX  0   0 32
>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
> 
> After
>   [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>   [16] .stubs            PROGBITS        c0c35000 a35000 0002c0 00  AX  0   0 32
>   [17] .vectors          PROGBITS        c0c34000 a44000 000020 00  AX  0   0  2
>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32

Meaningless numbers... Do you think you can quote with the header
please?  I don't tend to carry around the objdump headers in my head.
Thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From arnd at arndb.de  Wed Feb  3 01:15:34 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 03 Feb 2016 10:15:34 +0100
Subject: [PATCH] clk: vt8500: don't return possibly uninitialized data
In-Reply-To: <20160203113626.4a3f4f8a@v1ron-s7>
References: <4790407.6zgSQCdsSB@wuerfel> <2326140.nrZ9Ej2PSt@wuerfel>
 <20160203113626.4a3f4f8a@v1ron-s7>
Message-ID: <1624352.DBIo65mLZO@wuerfel>

On Wednesday 03 February 2016 11:36:26 Roman Volkov wrote:
> 
> Hi Arnd,
> 
> Thanks for fixing this code! Did someone reproduce this bug, or this
> is something theoretical, based on the code analysis? I just never
> heard about the issue. I can look into the code on the weekends too, I
> have WM8505\WM8650 machines to test.

I only fixed it after analysing the gcc warnings I got after Andrzej Hajda's
patch, and he also did it to fix the initial problem he found using
coccinelle, so I don't think anyone has run into the problem on live
hardware.

As long as all drivers ask for clock rates that are valid, you won't
see either problem.
 
> Is it enough to run the regular kernel build for WM8650 to see the
> warnings, or there are special options in the kernel to run the compiler
> test?

The warning is hidden if you build with -Os (CONFIG_CC_OPTIMIZE_FOR_SIZE),
and it may not happen with all gcc versions. I was using gcc-5.2.

	Arnd


From ard.biesheuvel at linaro.org  Wed Feb  3 01:16:46 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 3 Feb 2016 10:16:46 +0100
Subject: [PATCH 1/3] ARM: move .vectors and .stubs sections back into the
 kernel VMA
In-Reply-To: <20160203091331.GB10826@n2100.arm.linux.org.uk>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454419174-21290-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160203000351.GX10826@n2100.arm.linux.org.uk>
 <CAKv+Gu_kYWczCazqgRC3y-n7s3WRTDhJXLO1RM1FE-6h1BhSUw@mail.gmail.com>
 <20160203091331.GB10826@n2100.arm.linux.org.uk>
Message-ID: <CAKv+Gu8jbfs6HuzoFTQV2z-0LLiEZ9p0ZHO6eF3itE8p1LMwBA@mail.gmail.com>

On 3 February 2016 at 10:13, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Wed, Feb 03, 2016 at 08:56:35AM +0100, Ard Biesheuvel wrote:
>> On 3 February 2016 at 01:03, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>> > On Tue, Feb 02, 2016 at 02:19:32PM +0100, Ard Biesheuvel wrote:
>> >> The sections themselves are emitted 4 KB apart, as required:
>> >>   ...
>> >>   [16] .stubs       PROGBITS   c0c35000 a35000 0002c0 00  AX  0   0 32
>> >>   [17] .vectors     PROGBITS   c0c34000 a44000 000020 00  AX  0   0  2
>> >>   ...
>> >
>> > ... which means we end up wasting most of a page for absolutely no
>> > purpose what so ever.  Sorry, I'm really not happy about this
>> > gratuitous wastage.
>> >
>>
>> No, we don't. Here's some more context:
>>
>> Before:
>>   [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
>>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>>   [16] .vectors          PROGBITS        00000000 a40000 000020 00  AX  0   0  2
>>   [17] .stubs            PROGBITS        00001000 a41000 0002c0 00  AX  0   0 32
>>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
>>
>> After
>>   [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
>>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>>   [16] .stubs            PROGBITS        c0c35000 a35000 0002c0 00  AX  0   0 32
>>   [17] .vectors          PROGBITS        c0c34000 a44000 000020 00  AX  0   0  2
>>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
>
> Meaningless numbers... Do you think you can quote with the header
> please?  I don't tend to carry around the objdump headers in my head.
> Thanks.
>

BEFORE

$ readelf -S vmlinux
There are 34 section headers, starting at offset 0x10a6e60:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .head.text        PROGBITS        c0208000 008000 000268 00  AX  0   0  4
  [ 2] .text             PROGBITS        c0209000 009000 5d6e7c 00  AX
 0   0 4096
  [ 3] .fixup            PROGBITS        c07dfe7c 5dfe7c 000024 00  AX  0   0  4
  [ 4] .rodata           PROGBITS        c07e0000 5e0000 3ca310 00   A  0   0 64
  [ 5] __bug_table       PROGBITS        c0baa310 9aa310 0082c8 00   A  0   0  4
  [ 6] .pci_fixup        PROGBITS        c0bb25d8 9b25d8 001910 00   A  0   0  4
  [ 7] __ksymtab         PROGBITS        c0bb3ee8 9b3ee8 008a70 00   A  0   0  4
  [ 8] __ksymtab_gpl     PROGBITS        c0bbc958 9bc958 007d60 00   A  0   0  4
  [ 9] __ksymtab_strings PROGBITS        c0bc46b8 9c46b8 027c07 00   A  0   0  1
  [10] __param           PROGBITS        c0bec2c0 9ec2c0 0015b8 00   A  0   0  4
  [11] __modver          PROGBITS        c0bed878 9ed878 000788 00   A  0   0  4
  [12] __ex_table        PROGBITS        c0bee000 9ee000 001068 00   A  0   0  8
  [13] .ARM.unwind_idx   ARM_EXIDX       c0bef068 9ef068 03ff30 00  AL 18   0  4
  [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
  [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
  [16] .vectors          PROGBITS        00000000 a40000 000020 00  AX  0   0  2
  [17] .stubs            PROGBITS        00001000 a41000 0002c0 00  AX  0   0 32
  [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
  [19] .exit.text        PROGBITS        c0ca0498 ab0498 002f40 00  AX  0   0  4
  [20] .init.arch.info   PROGBITS        c0ca33d8 ab33d8 0026e8 00   A  0   0  8
  [21] .init.tagtable    PROGBITS        c0ca5ac0 ab5ac0 000048 00   A  0   0  4
  [22] .init.smpalt      PROGBITS        c0ca5b08 ab5b08 00dff8 00   A  0   0  4
  [23] .init.pv_table    PROGBITS        c0cb3b00 ac3b00 000a20 00   A  0   0  1
  [24] .init.data        PROGBITS        c0cb5000 ac5000 06de0c 00  WA
 0   0 4096
  [25] .data..percpu     PROGBITS        c0d23000 b33000 0049c0 00  WA  0   0 64
  [26] .data             PROGBITS        c0d28000 b38000 107d00 00  WA  0   0 64
  [27] .data..page_align PROGBITS        c0e30000 c40000 002000 00  WA
 0   0 4096
  [28] .bss              NOBITS          c0e32000 c42000 056ec8 00  WA  0   0 64
  [29] .comment          PROGBITS        00000000 c42000 00002d 01  MS  0   0  1
  [30] .ARM.attributes   ARM_ATTRIBUTES  00000000 c4202d 000033 00      0   0  1
  [31] .shstrtab         STRTAB          00000000 c42060 000165 00      0   0  1
  [32] .symtab           SYMTAB          00000000 c421c8 28f340 10
33 140990  4
  [33] .strtab           STRTAB          00000000 ed1508 1d5956 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

AFTER

$ readelf -S vmlinux
There are 34 section headers, starting at offset 0x10a6e50:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .head.text        PROGBITS        c0208000 008000 000268 00  AX  0   0  4
  [ 2] .text             PROGBITS        c0209000 009000 5d6e7c 00  AX
 0   0 4096
  [ 3] .fixup            PROGBITS        c07dfe7c 5dfe7c 000024 00  AX  0   0  4
  [ 4] .rodata           PROGBITS        c07e0000 5e0000 3ca310 00   A  0   0 64
  [ 5] __bug_table       PROGBITS        c0baa310 9aa310 0082c8 00   A  0   0  4
  [ 6] .pci_fixup        PROGBITS        c0bb25d8 9b25d8 001910 00   A  0   0  4
  [ 7] __ksymtab         PROGBITS        c0bb3ee8 9b3ee8 008a70 00   A  0   0  4
  [ 8] __ksymtab_gpl     PROGBITS        c0bbc958 9bc958 007d60 00   A  0   0  4
  [ 9] __ksymtab_strings PROGBITS        c0bc46b8 9c46b8 027c07 00   A  0   0  1
  [10] __param           PROGBITS        c0bec2c0 9ec2c0 0015b8 00   A  0   0  4
  [11] __modver          PROGBITS        c0bed878 9ed878 000788 00   A  0   0  4
  [12] __ex_table        PROGBITS        c0bee000 9ee000 001068 00   A  0   0  8
  [13] .ARM.unwind_idx   ARM_EXIDX       c0bef068 9ef068 03ff30 00  AL 18   0  4
  [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
  [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
  [16] .stubs            PROGBITS        c0c35000 a35000 0002c0 00  AX  0   0 32
  [17] .vectors          PROGBITS        c0c34000 a44000 000020 00  AX  0   0  2
  [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
  [19] .exit.text        PROGBITS        c0ca0498 ab0498 002f40 00  AX  0   0  4
  [20] .init.arch.info   PROGBITS        c0ca33d8 ab33d8 0026e8 00   A  0   0  8
  [21] .init.tagtable    PROGBITS        c0ca5ac0 ab5ac0 000048 00   A  0   0  4
  [22] .init.smpalt      PROGBITS        c0ca5b08 ab5b08 00dff8 00   A  0   0  4
  [23] .init.pv_table    PROGBITS        c0cb3b00 ac3b00 000a20 00   A  0   0  1
  [24] .init.data        PROGBITS        c0cb5000 ac5000 06de0c 00  WA
 0   0 4096
  [25] .data..percpu     PROGBITS        c0d23000 b33000 0049c0 00  WA  0   0 64
  [26] .data             PROGBITS        c0d28000 b38000 107d00 00  WA  0   0 64
  [27] .data..page_align PROGBITS        c0e30000 c40000 002000 00  WA
 0   0 4096
  [28] .bss              NOBITS          c0e32000 c42000 056ec8 00  WA  0   0 64
  [29] .comment          PROGBITS        00000000 c42000 00002d 01  MS  0   0  1
  [30] .ARM.attributes   ARM_ATTRIBUTES  00000000 c4202d 000033 00      0   0  1
  [31] .shstrtab         STRTAB          00000000 c42060 000165 00      0   0  1
  [32] .symtab           SYMTAB          00000000 c421c8 28f330 10
33 140988  4
  [33] .strtab           STRTAB          00000000 ed14f8 1d5956 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)


From jonathanh at nvidia.com  Wed Feb  3 01:20:07 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Wed, 3 Feb 2016 09:20:07 +0000
Subject: [PATCH V5 05/14] soc: tegra: pmc: Wait for powergate state to
 change
In-Reply-To: <56AF613A.1000909@nvidia.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-6-git-send-email-jonathanh@nvidia.com>
 <CANLsYkycbEo+wyMX8RJ9H-S5kDTjQR4nnDZc5gvf2kShOZAv9w@mail.gmail.com>
 <56AF613A.1000909@nvidia.com>
Message-ID: <56B1C647.4060504@nvidia.com>


On 01/02/16 13:44, Jon Hunter wrote:
> 
> On 29/01/16 16:58, Mathieu Poirier wrote:
>> On 28 January 2016 at 09:33, Jon Hunter <jonathanh at nvidia.com> wrote:
>>> Currently, the function tegra_powergate_set() simply sets the desired
>>> powergate state but does not wait for the state to change. In most cases
>>> we should wait for the state to change before proceeding. Currently, there
>>> is a case for tegra114 and tegra124 devices where we do not wait when
>>> starting the secondary CPU as this is not necessary. However, this is only
>>> done at boot time and so waiting here will only have a small impact on
>>> boot time. Therefore, update tegra_powergate_set() to wait when setting
>>> the powergate.
>>>
>>> By adding this feature, we can also eliminate the polling loop from
>>> tegra30_boot_secondary().
>>>
>>> A function has been added for checking the status of the powergate and
>>> so update the tegra_powergate_is_powered() to use this macro as well.
>>>
>>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
>>> ---
>>>  arch/arm/mach-tegra/platsmp.c | 16 +++-------------
>>>  drivers/soc/tegra/pmc.c       |  9 ++++++++-
>>>  2 files changed, 11 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
>>> index f3f61dbbda97..75620ae73913 100644
>>> --- a/arch/arm/mach-tegra/platsmp.c
>>> +++ b/arch/arm/mach-tegra/platsmp.c
>>> @@ -108,19 +108,9 @@ static int tegra30_boot_secondary(unsigned int cpu, struct task_struct *idle)
>>>          * be un-gated by un-toggling the power gate register
>>>          * manually.
>>>          */
>>> -       if (!tegra_pmc_cpu_is_powered(cpu)) {
>>> -               ret = tegra_pmc_cpu_power_on(cpu);
>>> -               if (ret)
>>> -                       return ret;
>>> -
>>> -               /* Wait for the power to come up. */
>>> -               timeout = jiffies + msecs_to_jiffies(100);
>>> -               while (!tegra_pmc_cpu_is_powered(cpu)) {
>>> -                       if (time_after(jiffies, timeout))
>>> -                               return -ETIMEDOUT;
>>> -                       udelay(10);
>>> -               }
>>> -       }
>>> +       ret = tegra_pmc_cpu_power_on(cpu);
>>> +       if (ret)
>>> +               return ret;
>>>
>>>  remove_clamps:
>>>         /* CPU partition is powered. Enable the CPU clock. */
>>> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
>>> index 99cb2fdd29e1..35ee60fd17be 100644
>>> --- a/drivers/soc/tegra/pmc.c
>>> +++ b/drivers/soc/tegra/pmc.c
>>> @@ -28,6 +28,7 @@
>>>  #include <linux/export.h>
>>>  #include <linux/init.h>
>>>  #include <linux/io.h>
>>> +#include <linux/iopoll.h>
>>>  #include <linux/of.h>
>>>  #include <linux/of_address.h>
>>>  #include <linux/platform_device.h>
>>> @@ -186,6 +187,9 @@ static inline bool tegra_powergate_state(int id)
>>>   */
>>>  static int tegra_powergate_set(unsigned int id, bool new_state)
>>>  {
>>> +       bool status;
>>> +       int err;
>>> +
>>>         mutex_lock(&pmc->powergates_lock);
>>>
>>>         if (tegra_powergate_state(id) == new_state) {
>>> @@ -195,9 +199,12 @@ static int tegra_powergate_set(unsigned int id, bool new_state)
>>>
>>>         tegra_pmc_writel(PWRGATE_TOGGLE_START | id, PWRGATE_TOGGLE);
>>>
>>> +       err = readx_poll_timeout(tegra_powergate_state, id, status,
>>> +                                status == new_state, 10, 100000);
>>> +
>>
>> I understand (and agree) with the goal of this patch but I wonder (and
>> I don't know much about the system/context) if holding a mutex while
>> sleeping won't incur adverse effect on other parts of the system that
>> weren't use to see this wait.  One way to fix this might be to use
>> "mutex_trylock()" and let callers retry as they see fit if an
>> operation is already in progress.
> 
> I could unlock the mutex after writing the TOGGLE_START register. I
> don't believe that we need to waiting for a powergate to change before
> writing again.

I was not thinking clearly here, the whole reason for the locking is to
protect the base address as we swap it during the probe.

In general, I prefer to keep it the way we have it in this patch. By
using mutex_trylock() would mean that now clients would have to handle
retrying if they cannot get the lock and make it more complex.
Powergates should not be turned on and off that frequently and so
hopefully a delay here should be tolerable. For CPUs, this should only
be used on cold boot and not during CPU hotplug events.

Cheers
Jon


From p.zabel at pengutronix.de  Wed Feb  3 01:24:19 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Wed, 03 Feb 2016 10:24:19 +0100
Subject: [PATCH v2] ARM: dts: Add dts for Uniwest evi
In-Reply-To: <1454451202-1687-1-git-send-email-stillcompiling@gmail.com>
References: <patches/evidts/35215>
 <1454451202-1687-1-git-send-email-stillcompiling@gmail.com>
Message-ID: <1454491459.3415.6.camel@pengutronix.de>

Hi Joshua,

Am Dienstag, den 02.02.2016, 14:13 -0800 schrieb Joshua Clayton:
> Uniwest evi is a portable electrical eddy current non-destructive
> testing device.
> 
> Signed-off-by: Joshua Clayton <stillcompiling at gmail.com>
> ---
>  arch/arm/boot/dts/Makefile      |   1 +
>  arch/arm/boot/dts/imx6q-evi.dts | 506 ++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 507 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6q-evi.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index c4f42a78..4a4ef29 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -326,6 +326,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>  	imx6q-cubox-i.dtb \
>  	imx6q-dfi-fs700-m60.dtb \
>  	imx6q-dmo-edmqmx6.dtb \
> +	imx6q-evi.dtb \
>  	imx6q-gk802.dtb \
>  	imx6q-gw51xx.dtb \
>  	imx6q-gw52xx.dtb \
> diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
> new file mode 100644
> index 0000000..10f566e
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-evi.dts
> @@ -0,0 +1,506 @@
[...]
> +/dts-v1/;
> +#include "imx6q.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/ {
> +	model = "Uniwest Evi";
> +	compatible = "uniwest,imx6q-evi", "fsl,imx6q";
[...]
> +	panel {
> +		compatible = "sharp,lq101k1ly04";
> +
> +		port {
> +			panel_in: endpoint {
> +				remote-endpoint = <&lvds0_out>;
> +			};
> +		};
> +	};
> +};
[...]
> +&ldb {
> +	status = "okay";
> +
> +	lvds0: lvds-channel at 0 {
> +		fsl,data-mapping = "jeida";
> +		fsl,data-width = <24>;

The "sharp,lq101k1ly04" panel compatible already specifies the bus
format (it is set to MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA in the
simple-panel entry), these two properties can be removed.

> +		status = "okay";
> +
> +		port at 4 {
> +			reg = <4>;
> +			lvds0_out: endpoint {
> +				remote-endpoint = <&panel_in>;
> +			};
> +		};
> +	};
> +};
[...]

regards
Philipp



From will.deacon at arm.com  Wed Feb  3 01:25:02 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 3 Feb 2016 09:25:02 +0000
Subject: [PATCH 0/5] Clean up warnings (part 2, asm/pci-bridge.h)
In-Reply-To: <20160202193026.9258.7573.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20160202193026.9258.7573.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <20160203092502.GA11376@arm.com>

On Tue, Feb 02, 2016 at 01:38:26PM -0600, Bjorn Helgaas wrote:
> We've had some non-arch-specific stuff (pci_has_flag() and associated
> definitions like PCI_PROBE_ONLY) in asm/pci-bridge.h.  This leads to
> warnings like:
> 
>   drivers/pci/host/pcie-designware.c:562:20: error: 'PCI_PROBE_ONLY' undeclared (first use in this function)
>   drivers/pci/host/pcie-designware.c:562:7: error: implicit declaration of function 'pci_has_flag' [-Werror=implicit-function-declaration]
> 
> because arches don't consistently supply asm/pci-bridge.h, and several
> drivers include it when they shouldn't.
> 
> This series moves the generic stuff to linux/pci.h, so it's the same for
> everybody, and removes the now-empty asm-generic/pci-bridge.h.
> 
> There still a few arches that provide asm/pci-bridge.h (microblaze,
> powerpc, and xtensa), but now they contain truly arch-dependent things like
> struct pci_controller definitions, and they're only included by
> arch-specific files.

For the arm64 bits:

Acked-by: Will Deacon <will.deacon at arm.com>

Will


From biao.huang at mediatek.com  Tue Feb  2 17:24:44 2016
From: biao.huang at mediatek.com (Biao Huang)
Date: Wed, 3 Feb 2016 09:24:44 +0800
Subject: [PATCH 0/2] pinctrl: mediatek: Add direction control and
 gpio_request_enable Support
Message-ID: <1454462686-770-1-git-send-email-biao.huang@mediatek.com>

1. Set direction to input when do input-enable/disable and input-schmitt-enable/disable properties.
2. Add gpio_request_enable support to set pin to gpio function.

Biao Huang (2):
  pinctrl: mediatek: fix direction control issue
  pinctrl: mediatek: Add gpio_request_enable support

 drivers/pinctrl/mediatek/pinctrl-mtk-common.c |   38 +++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

-- 
1.7.9.5



From biao.huang at mediatek.com  Tue Feb  2 17:24:45 2016
From: biao.huang at mediatek.com (Biao Huang)
Date: Wed, 3 Feb 2016 09:24:45 +0800
Subject: [PATCH 1/2] pinctrl: mediatek: fix direction control issue
In-Reply-To: <1454462686-770-1-git-send-email-biao.huang@mediatek.com>
References: <1454462686-770-1-git-send-email-biao.huang@mediatek.com>
Message-ID: <1454462686-770-2-git-send-email-biao.huang@mediatek.com>

Since input-enable/disable and input-schmitt-enable/disable are
workable when gpio direction is input, so add direction setting
when do input-enable/disable and input-schmitt-enable/disable
properties.

Signed-off-by: Biao Huang <biao.huang at mediatek.com>
---
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 8cac73d..6eb01c9 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -352,6 +352,7 @@ static int mtk_pconf_parse_conf(struct pinctrl_dev *pctldev,
 		ret = mtk_pconf_set_pull_select(pctl, pin, true, false, arg);
 		break;
 	case PIN_CONFIG_INPUT_ENABLE:
+		mtk_pmx_gpio_set_direction(pctldev, NULL, pin, true);
 		ret = mtk_pconf_set_ies_smt(pctl, pin, arg, param);
 		break;
 	case PIN_CONFIG_OUTPUT:
@@ -359,6 +360,7 @@ static int mtk_pconf_parse_conf(struct pinctrl_dev *pctldev,
 		ret = mtk_pmx_gpio_set_direction(pctldev, NULL, pin, false);
 		break;
 	case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
+		mtk_pmx_gpio_set_direction(pctldev, NULL, pin, true);
 		ret = mtk_pconf_set_ies_smt(pctl, pin, arg, param);
 		break;
 	case PIN_CONFIG_DRIVE_STRENGTH:
-- 
1.7.9.5



From biao.huang at mediatek.com  Tue Feb  2 17:24:46 2016
From: biao.huang at mediatek.com (Biao Huang)
Date: Wed, 3 Feb 2016 09:24:46 +0800
Subject: [PATCH 2/2] pinctrl: mediatek: Add gpio_request_enable support
In-Reply-To: <1454462686-770-1-git-send-email-biao.huang@mediatek.com>
References: <1454462686-770-1-git-send-email-biao.huang@mediatek.com>
Message-ID: <1454462686-770-3-git-send-email-biao.huang@mediatek.com>

Implement the .gpio_request_enable() callbacks in struct pinmux_ops
in mediatek pinctrl driver. Make sure that when gpio_request is called,
GPIO on the pin is enabled.

Signed-off-by: Biao Huang <biao.huang at mediatek.com>
---
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c |   36 +++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 6eb01c9..cbc2204 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -43,6 +43,7 @@
 
 #define MAX_GPIO_MODE_PER_REG 5
 #define GPIO_MODE_BITS        3
+#define GPIO_MODE_PREFIX "GPIO"
 
 static const char * const mtk_gpio_functions[] = {
 	"func0", "func1", "func2", "func3",
@@ -735,12 +736,47 @@ static int mtk_pmx_set_mux(struct pinctrl_dev *pctldev,
 	return 0;
 }
 
+static int mtk_pmx_find_gpio_mode(struct mtk_pinctrl *pctl,
+				unsigned offset)
+{
+	const struct mtk_desc_pin *pin = pctl->devdata->pins + offset;
+	const struct mtk_desc_function *func = pin->functions;
+
+	while (func && func->name) {
+		if (!strncmp(func->name, GPIO_MODE_PREFIX,
+			sizeof(GPIO_MODE_PREFIX)-1))
+			return func->muxval;
+		func++;
+	}
+	return -EINVAL;
+}
+
+static int mtk_pmx_gpio_request_enable(struct pinctrl_dev *pctldev,
+				    struct pinctrl_gpio_range *range,
+				    unsigned offset)
+{
+	unsigned long muxval;
+	struct mtk_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
+
+	muxval = mtk_pmx_find_gpio_mode(pctl, offset);
+
+	if (muxval < 0) {
+		dev_err(pctl->dev, "invalid gpio pin %d.\n", offset);
+		return -EINVAL;
+	}
+
+	mtk_pmx_set_mode(pctldev, offset, muxval);
+
+	return 0;
+}
+
 static const struct pinmux_ops mtk_pmx_ops = {
 	.get_functions_count	= mtk_pmx_get_funcs_cnt,
 	.get_function_name	= mtk_pmx_get_func_name,
 	.get_function_groups	= mtk_pmx_get_func_groups,
 	.set_mux		= mtk_pmx_set_mux,
 	.gpio_set_direction	= mtk_pmx_gpio_set_direction,
+	.gpio_request_enable	= mtk_pmx_gpio_request_enable,
 };
 
 static int mtk_gpio_direction_input(struct gpio_chip *chip,
-- 
1.7.9.5



From ykk at rock-chips.com  Wed Feb  3 01:34:40 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Wed, 3 Feb 2016 17:34:40 +0800
Subject: [PATCH v8 1/2] drm/rockchip: hdmi: add Innosilicon HDMI support
In-Reply-To: <20160129082000.b25fd19cea94c4f3ec45e17f@free.fr>
References: <1454049768-30872-1-git-send-email-ykk@rock-chips.com>
 <1454050059-31196-1-git-send-email-ykk@rock-chips.com>
 <20160129082000.b25fd19cea94c4f3ec45e17f@free.fr>
Message-ID: <56B1C9B0.3030806@rock-chips.com>

Hi Jean,

Sorry about miss your comments  :)

On 01/29/2016 03:20 PM, Jean-Francois Moine wrote:
> On Fri, 29 Jan 2016 14:47:39 +0800
> Yakir Yang <ykk at rock-chips.com> wrote:
>
>> The Innosilicon HDMI is a low power HDMI 1.4 transmitter
>> IP, and it have been integrated on some rockchip CPUs
>> (like RK3036, RK312x).
>>
>> Signed-off-by: Yakir Yang <ykk at rock-chips.com>
>> ---
>> Changes in v8:
>> - Don't check whether encoder output format is RGB colorspace, cause driver
>>    default configure the output colorspace to RGB. (ZhengYang)
>> - Correct the check condition in inno_hdmi_config_video_csc() (ZhengYang)
>>      - if (data->enc_out_format == data->enc_out_format) {
>>      + if (data->enc_in_format == data->enc_out_format) {
>>
>> Changes in v7:
>> - Correct the module licnese statement (Paul)
>>       - MODULE_LICENSE("GPL");
>>       + MODULE_LICENSE("GPLv2");
>> - Start indentation with tabs and fix the misspell in Kconfig (Paul)
>> - Carry the lost device-binding document (Heiko)
>>
>> Changes in v6:
>> - Rebase the Makefile/Kconfig files which add by Chris's rockchip-mipi driver (Caeser)
>>
>> Changes in v5:
>> - Use hdmi_infoframe helper functions to packed the infoframe (Russell)
>> - Remove the unused double wait_for_completion_timeout for ddc transfer (Russell)
>> - Remove the unused local variable in "inno_hdmi_i2c_write()" function (Russell)
>>
>> Changes in v4:
>> - Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
>> - Correct the "DKMS" to "DPMS" (Mark)
>> - Fix over 80 characters problems (Mark)
>> - Remove encoder .prepare/.commit helper functions, and move the vop mode
>> configure function into encoder .enable helper functions. (Mark)
>>
>> Changes in v3:
>> - Use encoder enable/disable function, and remove the encoder DPMS function
>> - Keep HDMI PLL power on in standby mode
>>
>> Changes in v2:
>> - Using DRM atomic helper functions for connector init (Mark)
>> - Remove "hdmi->connector.encoder = encoder;" (Mark)
>>
>>   drivers/gpu/drm/rockchip/Kconfig     |   8 +
>>   drivers/gpu/drm/rockchip/Makefile    |   1 +
>>   drivers/gpu/drm/rockchip/inno_hdmi.c | 939 +++++++++++++++++++++++++++++++++++
>>   drivers/gpu/drm/rockchip/inno_hdmi.h | 362 ++++++++++++++
>>   4 files changed, 1310 insertions(+)
>>   create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
>>   create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h
>>
>> diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
>> index 8573985..76b3362 100644
>> --- a/drivers/gpu/drm/rockchip/Kconfig
>> +++ b/drivers/gpu/drm/rockchip/Kconfig
>> @@ -35,3 +35,11 @@ config ROCKCHIP_DW_MIPI_DSI
>>   	 for the Synopsys DesignWare HDMI driver. If you want to
>>   	 enable MIPI DSI on RK3288 based SoC, you should selet this
>>   	 option.
>> +
>> +config ROCKCHIP_INNO_HDMI
>> +	tristate "Rockchip specific extensions for Innosilicon HDMI"
>> +	depends on DRM_ROCKCHIP
>> +	help
>> +	  This selects support for Rockchip SoC specific extensions
>> +	  for the Innosilicon HDMI driver. If you want to enable
>> +	  HDMI on RK3036 based SoC, you should select this option.
>> diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile
>> index f6a809a..df8fbef 100644
>> --- a/drivers/gpu/drm/rockchip/Makefile
>> +++ b/drivers/gpu/drm/rockchip/Makefile
>> @@ -8,5 +8,6 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>>   
>>   obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>>   obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
>> +obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
>>   
>>   obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
>> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
>> new file mode 100644
>> index 0000000..c99d88d
>> --- /dev/null
>> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
>> @@ -0,0 +1,939 @@
>> +/*
>> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
>> + *    Zheng Yang <zhengyang at rock-chips.com>
>> + *    Yakir Yang <ykk at rock-chips.com>
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/irq.h>
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/err.h>
>> +#include <linux/hdmi.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/of_device.h>
>> +
>> +#include <drm/drm_of.h>
>> +#include <drm/drmP.h>
>> +#include <drm/drm_atomic_helper.h>
>> +#include <drm/drm_crtc_helper.h>
>> +#include <drm/drm_edid.h>
>> +#include <drm/drm_encoder_slave.h>
> This is not needed.

Do you mean the "drm_encoder_slave.h" file ?

Yep, seems I haven't called ant encoder slave helper functions, thanks.


>
>> +
>> +#include "rockchip_drm_drv.h"
>> +#include "rockchip_drm_vop.h"
>> +
>> +#include "inno_hdmi.h"
> 	[snip]
>




From u.kleine-koenig at pengutronix.de  Wed Feb  3 01:35:27 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Wed, 3 Feb 2016 10:35:27 +0100
Subject: [PATCH v2 2/3] Input: rotary-encoder - move configuration data
 to driver data
In-Reply-To: <56B09CAB.5020600@zonque.org>
References: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <1454408678-6011-3-git-send-email-u.kleine-koenig@pengutronix.de>
 <56B09CAB.5020600@zonque.org>
Message-ID: <20160203093527.GD13664@pengutronix.de>

Hello,

On Tue, Feb 02, 2016 at 01:10:19PM +0100, Daniel Mack wrote:
> On 02/02/2016 11:24 AM, Uwe Kleine-K?nig wrote:
> > This is a preparation for the next patche. There is no change in
> > behaviour intended.
> 
> This one looks good to me, but it clashes with Dmitry's latest patch
> sets (which I haven't found the time to test yet, sorry!).

There is nothing in next-20160203, so I assume Dmitry either fixes this
up when applying my patches or tells me when I should rebase.

> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
> 
>  Acked-by: Daniel Mack <daniel at zonque.org>

Thanks
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From ykk at rock-chips.com  Wed Feb  3 01:44:57 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Wed,  3 Feb 2016 17:44:57 +0800
Subject: [PATCH v8.1 1/2] drm/rockchip: hdmi: add Innosilicon HDMI support
In-Reply-To: <1454049768-30872-1-git-send-email-ykk@rock-chips.com>
References: <1454049768-30872-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1454492697-7837-1-git-send-email-ykk@rock-chips.com>

The Innosilicon HDMI is a low power HDMI 1.4 transmitter
IP, and it have been integrated on some rockchip CPUs
(like RK3036, RK312x).

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
---
Changes in v8.1:
- Removed the unused "drm_encoder_slave.h" head file. (Jean)

Changes in v8:
- Don't check whether encoder output format is RGB colorspace, cause driver
  default configure the output colorspace to RGB. (ZhengYang)
- Correct the check condition in inno_hdmi_config_video_csc() (ZhengYang)
    - if (data->enc_out_format == data->enc_out_format) {
    + if (data->enc_in_format == data->enc_out_format) {

Changes in v7:
- Correct the module licnese statement (Paul)
     - MODULE_LICENSE("GPL");
     + MODULE_LICENSE("GPLv2");
- Start indentation with tabs and fix the misspell in Kconfig (Paul)
- Carry the lost device-binding document (Heiko)

Changes in v6:
- Rebase the Makefile/Kconfig files which add by Chris's rockchip-mipi driver (Caeser)

Changes in v5:
- Use hdmi_infoframe helper functions to packed the infoframe (Russell)
- Remove the unused double wait_for_completion_timeout for ddc transfer (Russell)
- Remove the unused local variable in "inno_hdmi_i2c_write()" function (Russell)

Changes in v4:
- Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
- Correct the "DKMS" to "DPMS" (Mark)
- Fix over 80 characters problems (Mark)
- Remove encoder .prepare/.commit helper functions, and move the vop mode
configure function into encoder .enable helper functions. (Mark)

Changes in v3:
- Use encoder enable/disable function, and remove the encoder DPMS function
- Keep HDMI PLL power on in standby mode

Changes in v2:
- Using DRM atomic helper functions for connector init (Mark)
- Remove "hdmi->connector.encoder = encoder;" (Mark)

 drivers/gpu/drm/rockchip/Kconfig     |   8 +
 drivers/gpu/drm/rockchip/Makefile    |   1 +
 drivers/gpu/drm/rockchip/inno_hdmi.c | 938 +++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/rockchip/inno_hdmi.h | 362 ++++++++++++++
 4 files changed, 1309 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
 create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 8573985..76b3362 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -35,3 +35,11 @@ config ROCKCHIP_DW_MIPI_DSI
 	 for the Synopsys DesignWare HDMI driver. If you want to
 	 enable MIPI DSI on RK3288 based SoC, you should selet this
 	 option.
+
+config ROCKCHIP_INNO_HDMI
+	tristate "Rockchip specific extensions for Innosilicon HDMI"
+	depends on DRM_ROCKCHIP
+	help
+	  This selects support for Rockchip SoC specific extensions
+	  for the Innosilicon HDMI driver. If you want to enable
+	  HDMI on RK3036 based SoC, you should select this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile
index f6a809a..df8fbef 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -8,5 +8,6 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
 
 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
+obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
new file mode 100644
index 0000000..10d62ff
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -0,0 +1,938 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ *    Zheng Yang <zhengyang at rock-chips.com>
+ *    Yakir Yang <ykk at rock-chips.com>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/irq.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/hdmi.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of_device.h>
+
+#include <drm/drm_of.h>
+#include <drm/drmP.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_edid.h>
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#include "inno_hdmi.h"
+
+#define to_inno_hdmi(x)	container_of(x, struct inno_hdmi, x)
+
+struct hdmi_data_info {
+	int vic;
+	bool sink_is_hdmi;
+	bool sink_has_audio;
+	unsigned int enc_in_format;
+	unsigned int enc_out_format;
+	unsigned int colorimetry;
+};
+
+struct inno_hdmi_i2c {
+	struct i2c_adapter adap;
+
+	u8 ddc_addr;
+	u8 segment_addr;
+
+	struct mutex lock;
+	struct completion cmp;
+};
+
+struct inno_hdmi {
+	struct device *dev;
+	struct drm_device *drm_dev;
+
+	int irq;
+	struct clk *pclk;
+	void __iomem *regs;
+
+	struct drm_connector	connector;
+	struct drm_encoder	encoder;
+
+	struct inno_hdmi_i2c *i2c;
+	struct i2c_adapter *ddc;
+
+	unsigned int tmds_rate;
+
+	struct hdmi_data_info	hdmi_data;
+	struct drm_display_mode previous_mode;
+};
+
+enum {
+	CSC_ITU601_16_235_TO_RGB_0_255_8BIT,
+	CSC_ITU601_0_255_TO_RGB_0_255_8BIT,
+	CSC_ITU709_16_235_TO_RGB_0_255_8BIT,
+	CSC_RGB_0_255_TO_ITU601_16_235_8BIT,
+	CSC_RGB_0_255_TO_ITU709_16_235_8BIT,
+	CSC_RGB_0_255_TO_RGB_16_235_8BIT,
+};
+
+static const char coeff_csc[][24] = {
+	/*
+	 * YUV2RGB:601 SD mode(Y[16:235], UV[16:240], RGB[0:255]):
+	 *   R = 1.164*Y + 1.596*V - 204
+	 *   G = 1.164*Y - 0.391*U - 0.813*V + 154
+	 *   B = 1.164*Y + 2.018*U - 258
+	 */
+	{
+		0x04, 0xa7, 0x00, 0x00, 0x06, 0x62, 0x02, 0xcc,
+		0x04, 0xa7, 0x11, 0x90, 0x13, 0x40, 0x00, 0x9a,
+		0x04, 0xa7, 0x08, 0x12, 0x00, 0x00, 0x03, 0x02
+	},
+	/*
+	 * YUV2RGB:601 SD mode(YUV[0:255],RGB[0:255]):
+	 *   R = Y + 1.402*V - 248
+	 *   G = Y - 0.344*U - 0.714*V + 135
+	 *   B = Y + 1.772*U - 227
+	 */
+	{
+		0x04, 0x00, 0x00, 0x00, 0x05, 0x9b, 0x02, 0xf8,
+		0x04, 0x00, 0x11, 0x60, 0x12, 0xdb, 0x00, 0x87,
+		0x04, 0x00, 0x07, 0x16, 0x00, 0x00, 0x02, 0xe3
+	},
+	/*
+	 * YUV2RGB:709 HD mode(Y[16:235],UV[16:240],RGB[0:255]):
+	 *   R = 1.164*Y + 1.793*V - 248
+	 *   G = 1.164*Y - 0.213*U - 0.534*V + 77
+	 *   B = 1.164*Y + 2.115*U - 289
+	 */
+	{
+		0x04, 0xa7, 0x00, 0x00, 0x07, 0x2c, 0x02, 0xf8,
+		0x04, 0xa7, 0x10, 0xda, 0x12, 0x22, 0x00, 0x4d,
+		0x04, 0xa7, 0x08, 0x74, 0x00, 0x00, 0x03, 0x21
+	},
+
+	/*
+	 * RGB2YUV:601 SD mode:
+	 *   Cb = -0.291G - 0.148R + 0.439B + 128
+	 *   Y  = 0.504G  + 0.257R + 0.098B + 16
+	 *   Cr = -0.368G + 0.439R - 0.071B + 128
+	 */
+	{
+		0x11, 0x5f, 0x01, 0x82, 0x10, 0x23, 0x00, 0x80,
+		0x02, 0x1c, 0x00, 0xa1, 0x00, 0x36, 0x00, 0x1e,
+		0x11, 0x29, 0x10, 0x59, 0x01, 0x82, 0x00, 0x80
+	},
+	/*
+	 * RGB2YUV:709 HD mode:
+	 *   Cb = - 0.338G - 0.101R + 0.439B + 128
+	 *   Y  = 0.614G   + 0.183R + 0.062B + 16
+	 *   Cr = - 0.399G + 0.439R - 0.040B + 128
+	 */
+	{
+		0x11, 0x98, 0x01, 0xc1, 0x10, 0x28, 0x00, 0x80,
+		0x02, 0x74, 0x00, 0xbb, 0x00, 0x3f, 0x00, 0x10,
+		0x11, 0x5a, 0x10, 0x67, 0x01, 0xc1, 0x00, 0x80
+	},
+	/*
+	 * RGB[0:255]2RGB[16:235]:
+	 *   R' = R x (235-16)/255 + 16;
+	 *   G' = G x (235-16)/255 + 16;
+	 *   B' = B x (235-16)/255 + 16;
+	 */
+	{
+		0x00, 0x00, 0x03, 0x6F, 0x00, 0x00, 0x00, 0x10,
+		0x03, 0x6F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10,
+		0x00, 0x00, 0x00, 0x00, 0x03, 0x6F, 0x00, 0x10
+	},
+};
+
+static inline u8 hdmi_readb(struct inno_hdmi *hdmi, u16 offset)
+{
+	return readl_relaxed(hdmi->regs + (offset) * 0x04);
+}
+
+static inline void hdmi_writeb(struct inno_hdmi *hdmi, u16 offset, u32 val)
+{
+	writel_relaxed(val, hdmi->regs + (offset) * 0x04);
+}
+
+static inline void hdmi_modb(struct inno_hdmi *hdmi, u16 offset,
+			     u32 msk, u32 val)
+{
+	u8 temp = hdmi_readb(hdmi, offset) & ~msk;
+
+	temp |= val & msk;
+	hdmi_writeb(hdmi, offset, temp);
+}
+
+static void inno_hdmi_i2c_init(struct inno_hdmi *hdmi)
+{
+	int ddc_bus_freq;
+
+	ddc_bus_freq = (hdmi->tmds_rate >> 2) / HDMI_SCL_RATE;
+
+	hdmi_writeb(hdmi, DDC_BUS_FREQ_L, ddc_bus_freq & 0xFF);
+	hdmi_writeb(hdmi, DDC_BUS_FREQ_H, (ddc_bus_freq >> 8) & 0xFF);
+
+	/* Clear the EDID interrupt flag and mute the interrupt */
+	hdmi_writeb(hdmi, HDMI_INTERRUPT_MASK1, 0);
+	hdmi_writeb(hdmi, HDMI_INTERRUPT_STATUS1, m_INT_EDID_READY);
+}
+
+static void inno_hdmi_sys_power(struct inno_hdmi *hdmi, bool enable)
+{
+	if (enable)
+		hdmi_modb(hdmi, HDMI_SYS_CTRL, m_POWER, v_PWR_ON);
+	else
+		hdmi_modb(hdmi, HDMI_SYS_CTRL, m_POWER, v_PWR_OFF);
+}
+
+static void inno_hdmi_set_pwr_mode(struct inno_hdmi *hdmi, int mode)
+{
+	switch (mode) {
+	case NORMAL:
+		inno_hdmi_sys_power(hdmi, false);
+
+		hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x6f);
+		hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0xbb);
+
+		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
+		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x14);
+		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x10);
+		hdmi_writeb(hdmi, HDMI_PHY_CHG_PWR, 0x0f);
+		hdmi_writeb(hdmi, HDMI_PHY_SYNC, 0x00);
+		hdmi_writeb(hdmi, HDMI_PHY_SYNC, 0x01);
+
+		inno_hdmi_sys_power(hdmi, true);
+		break;
+
+	case LOWER_PWR:
+		inno_hdmi_sys_power(hdmi, false);
+		hdmi_writeb(hdmi, HDMI_PHY_DRIVER, 0x00);
+		hdmi_writeb(hdmi, HDMI_PHY_PRE_EMPHASIS, 0x00);
+		hdmi_writeb(hdmi, HDMI_PHY_CHG_PWR, 0x00);
+		hdmi_writeb(hdmi, HDMI_PHY_SYS_CTL, 0x15);
+
+		break;
+
+	default:
+		dev_err(hdmi->dev, "Unknown power mode %d\n", mode);
+	}
+}
+
+static void inno_hdmi_reset(struct inno_hdmi *hdmi)
+{
+	u32 val;
+	u32 msk;
+
+	hdmi_modb(hdmi, HDMI_SYS_CTRL, m_RST_DIGITAL, v_NOT_RST_DIGITAL);
+	udelay(100);
+
+	hdmi_modb(hdmi, HDMI_SYS_CTRL, m_RST_ANALOG, v_NOT_RST_ANALOG);
+	udelay(100);
+
+	msk = m_REG_CLK_INV | m_REG_CLK_SOURCE | m_POWER | m_INT_POL;
+	val = v_REG_CLK_INV | v_REG_CLK_SOURCE_SYS | v_PWR_ON | v_INT_POL_HIGH;
+	hdmi_modb(hdmi, HDMI_SYS_CTRL, msk, val);
+
+	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
+}
+
+static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
+				  union hdmi_infoframe *frame, u32 frame_index,
+				  u32 mask, u32 disable, u32 enable)
+{
+	if (mask)
+		hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, disable);
+
+	hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, frame_index);
+
+	if (setup_rc >= 0) {
+		u8 packed_frame[HDMI_MAXIMUM_INFO_FRAME_SIZE];
+		ssize_t rc, i;
+
+		rc = hdmi_infoframe_pack(frame, packed_frame,
+					 sizeof(packed_frame));
+		if (rc < 0)
+			return rc;
+
+		for (i = 0; i < rc; i++)
+			hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i,
+				    packed_frame[i]);
+
+		if (mask)
+			hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, enable);
+	}
+
+	return setup_rc;
+}
+
+static int inno_hdmi_config_video_vsi(struct inno_hdmi *hdmi,
+				      struct drm_display_mode *mode)
+{
+	union hdmi_infoframe frame;
+	int rc;
+
+	rc = drm_hdmi_vendor_infoframe_from_display_mode(&frame.vendor.hdmi,
+							 mode);
+
+	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_VSI,
+		m_PACKET_VSI_EN, v_PACKET_VSI_EN(0), v_PACKET_VSI_EN(1));
+}
+
+static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi,
+				      struct drm_display_mode *mode)
+{
+	union hdmi_infoframe frame;
+	int rc;
+
+	rc = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi, mode);
+
+	if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
+		frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
+	else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422)
+		frame.avi.colorspace = HDMI_COLORSPACE_YUV422;
+	else
+		frame.avi.colorspace = HDMI_COLORSPACE_RGB;
+
+	return inno_hdmi_upload_frame(hdmi, rc, &frame, INFOFRAME_AVI, 0, 0, 0);
+}
+
+static int inno_hdmi_config_video_csc(struct inno_hdmi *hdmi)
+{
+	struct hdmi_data_info *data = &hdmi->hdmi_data;
+	int c0_c2_change = 0;
+	int csc_enable = 0;
+	int csc_mode = 0;
+	int auto_csc = 0;
+	int value;
+	int i;
+
+	/* Input video mode is SDR RGB24bit, data enable signal from external */
+	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL1, v_DE_EXTERNAL |
+		    v_VIDEO_INPUT_FORMAT(VIDEO_INPUT_SDR_RGB444));
+
+	/* Input color hardcode to RGB, and output color hardcode to RGB888 */
+	value = v_VIDEO_INPUT_BITS(VIDEO_INPUT_8BITS) |
+		v_VIDEO_OUTPUT_COLOR(0) |
+		v_VIDEO_INPUT_CSP(0);
+	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL2, value);
+
+	if (data->enc_in_format == data->enc_out_format) {
+		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) ||
+		    (data->enc_in_format >= HDMI_COLORSPACE_YUV444)) {
+			value = v_SOF_DISABLE | v_COLOR_DEPTH_NOT_INDICATED(1);
+			hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
+
+			hdmi_modb(hdmi, HDMI_VIDEO_CONTRL,
+				  m_VIDEO_AUTO_CSC | m_VIDEO_C0_C2_SWAP,
+				  v_VIDEO_AUTO_CSC(AUTO_CSC_DISABLE) |
+				  v_VIDEO_C0_C2_SWAP(C0_C2_CHANGE_DISABLE));
+			return 0;
+		}
+	}
+
+	if (data->colorimetry == HDMI_COLORIMETRY_ITU_601) {
+		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) &&
+		    (data->enc_out_format == HDMI_COLORSPACE_YUV444)) {
+			csc_mode = CSC_RGB_0_255_TO_ITU601_16_235_8BIT;
+			auto_csc = AUTO_CSC_DISABLE;
+			c0_c2_change = C0_C2_CHANGE_DISABLE;
+			csc_enable = v_CSC_ENABLE;
+		} else if ((data->enc_in_format == HDMI_COLORSPACE_YUV444) &&
+			   (data->enc_out_format == HDMI_COLORSPACE_RGB)) {
+			csc_mode = CSC_ITU601_16_235_TO_RGB_0_255_8BIT;
+			auto_csc = AUTO_CSC_ENABLE;
+			c0_c2_change = C0_C2_CHANGE_DISABLE;
+			csc_enable = v_CSC_DISABLE;
+		}
+	} else {
+		if ((data->enc_in_format == HDMI_COLORSPACE_RGB) &&
+		    (data->enc_out_format == HDMI_COLORSPACE_YUV444)) {
+			csc_mode = CSC_RGB_0_255_TO_ITU709_16_235_8BIT;
+			auto_csc = AUTO_CSC_DISABLE;
+			c0_c2_change = C0_C2_CHANGE_DISABLE;
+			csc_enable = v_CSC_ENABLE;
+		} else if ((data->enc_in_format == HDMI_COLORSPACE_YUV444) &&
+			   (data->enc_out_format == HDMI_COLORSPACE_RGB)) {
+			csc_mode = CSC_ITU709_16_235_TO_RGB_0_255_8BIT;
+			auto_csc = AUTO_CSC_ENABLE;
+			c0_c2_change = C0_C2_CHANGE_DISABLE;
+			csc_enable = v_CSC_DISABLE;
+		}
+	}
+
+	for (i = 0; i < 24; i++)
+		hdmi_writeb(hdmi, HDMI_VIDEO_CSC_COEF + i,
+			    coeff_csc[csc_mode][i]);
+
+	value = v_SOF_DISABLE | csc_enable | v_COLOR_DEPTH_NOT_INDICATED(1);
+	hdmi_writeb(hdmi, HDMI_VIDEO_CONTRL3, value);
+	hdmi_modb(hdmi, HDMI_VIDEO_CONTRL, m_VIDEO_AUTO_CSC |
+		  m_VIDEO_C0_C2_SWAP, v_VIDEO_AUTO_CSC(auto_csc) |
+		  v_VIDEO_C0_C2_SWAP(c0_c2_change));
+
+	return 0;
+}
+
+static int inno_hdmi_config_video_timing(struct inno_hdmi *hdmi,
+					 struct drm_display_mode *mode)
+{
+	int value;
+
+	/* Set detail external video timing polarity and interlace mode */
+	value = v_EXTERANL_VIDEO(1);
+	value |= mode->flags & DRM_MODE_FLAG_PHSYNC ?
+		 v_HSYNC_POLARITY(1) : v_HSYNC_POLARITY(0);
+	value |= mode->flags & DRM_MODE_FLAG_PVSYNC ?
+		 v_VSYNC_POLARITY(1) : v_VSYNC_POLARITY(0);
+	value |= mode->flags & DRM_MODE_FLAG_INTERLACE ?
+		 v_INETLACE(1) : v_INETLACE(0);
+	hdmi_writeb(hdmi, HDMI_VIDEO_TIMING_CTL, value);
+
+	/* Set detail external video timing */
+	value = mode->htotal;
+	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HTOTAL_L, value & 0xFF);
+	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HTOTAL_H, (value >> 8) & 0xFF);
+
+	value = mode->htotal - mode->hdisplay;
+	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HBLANK_L, value & 0xFF);
+	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HBLANK_H, (value >> 8) & 0xFF);
+
+	value = mode->hsync_start - mode->hdisplay;
+	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDELAY_L, value & 0xFF);
+	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDELAY_H, (value >> 8) & 0xFF);
+
+	value = mode->hsync_end - mode->hsync_start;
+	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDURATION_L, value & 0xFF);
+	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDURATION_H, (value >> 8) & 0xFF);
+
+	value = mode->vtotal;
+	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VTOTAL_L, value & 0xFF);
+	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VTOTAL_H, (value >> 8) & 0xFF);
+
+	value = mode->vtotal - mode->vdisplay;
+	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VBLANK, value & 0xFF);
+
+	value = mode->vsync_start - mode->vdisplay;
+	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VDELAY, value & 0xFF);
+
+	value = mode->vsync_end - mode->vsync_start;
+	hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VDURATION, value & 0xFF);
+
+	hdmi_writeb(hdmi, HDMI_PHY_PRE_DIV_RATIO, 0x1e);
+	hdmi_writeb(hdmi, HDMI_PHY_FEEDBACK_DIV_RATIO_LOW, 0x2c);
+	hdmi_writeb(hdmi, HDMI_PHY_FEEDBACK_DIV_RATIO_HIGH, 0x01);
+
+	return 0;
+}
+
+static int inno_hdmi_setup(struct inno_hdmi *hdmi,
+			   struct drm_display_mode *mode)
+{
+	hdmi->hdmi_data.vic = drm_match_cea_mode(mode);
+
+	hdmi->hdmi_data.enc_in_format = HDMI_COLORSPACE_RGB;
+	hdmi->hdmi_data.enc_out_format = HDMI_COLORSPACE_RGB;
+
+	if ((hdmi->hdmi_data.vic == 6) || (hdmi->hdmi_data.vic == 7) ||
+	    (hdmi->hdmi_data.vic == 21) || (hdmi->hdmi_data.vic == 22) ||
+	    (hdmi->hdmi_data.vic == 2) || (hdmi->hdmi_data.vic == 3) ||
+	    (hdmi->hdmi_data.vic == 17) || (hdmi->hdmi_data.vic == 18))
+		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_601;
+	else
+		hdmi->hdmi_data.colorimetry = HDMI_COLORIMETRY_ITU_709;
+
+	/* Mute video and audio output */
+	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
+		  v_AUDIO_MUTE(1) | v_VIDEO_MUTE(1));
+
+	/* Set HDMI Mode */
+	hdmi_writeb(hdmi, HDMI_HDCP_CTRL,
+		    v_HDMI_DVI(hdmi->hdmi_data.sink_is_hdmi));
+
+	inno_hdmi_config_video_timing(hdmi, mode);
+
+	inno_hdmi_config_video_csc(hdmi);
+
+	if (hdmi->hdmi_data.sink_is_hdmi) {
+		inno_hdmi_config_video_avi(hdmi, mode);
+		inno_hdmi_config_video_vsi(hdmi, mode);
+	}
+
+	/*
+	 * When IP controller have configured to an accurate video
+	 * timing, then the TMDS clock source would be switched to
+	 * DCLK_LCDC, so we need to init the TMDS rate to mode pixel
+	 * clock rate, and reconfigure the DDC clock.
+	 */
+	hdmi->tmds_rate = mode->clock * 1000;
+	inno_hdmi_i2c_init(hdmi);
+
+	/* Unmute video and audio output */
+	hdmi_modb(hdmi, HDMI_AV_MUTE, m_AUDIO_MUTE | m_VIDEO_BLACK,
+		  v_AUDIO_MUTE(0) | v_VIDEO_MUTE(0));
+
+	return 0;
+}
+
+static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
+				       struct drm_display_mode *mode,
+				       struct drm_display_mode *adj_mode)
+{
+	struct inno_hdmi *hdmi = to_inno_hdmi(encoder);
+
+	inno_hdmi_setup(hdmi, adj_mode);
+
+	/* Store the display mode for plugin/DPMS poweron events */
+	memcpy(&hdmi->previous_mode, adj_mode, sizeof(hdmi->previous_mode));
+}
+
+static void inno_hdmi_encoder_enable(struct drm_encoder *encoder)
+{
+	struct inno_hdmi *hdmi = to_inno_hdmi(encoder);
+
+	rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
+				      ROCKCHIP_OUT_MODE_P888);
+
+	inno_hdmi_set_pwr_mode(hdmi, NORMAL);
+}
+
+static void inno_hdmi_encoder_disable(struct drm_encoder *encoder)
+{
+	struct inno_hdmi *hdmi = to_inno_hdmi(encoder);
+
+	inno_hdmi_set_pwr_mode(hdmi, LOWER_PWR);
+}
+
+static bool inno_hdmi_encoder_mode_fixup(struct drm_encoder *encoder,
+					 const struct drm_display_mode *mode,
+					 struct drm_display_mode *adj_mode)
+{
+	return true;
+}
+
+static struct drm_encoder_helper_funcs inno_hdmi_encoder_helper_funcs = {
+	.enable     = inno_hdmi_encoder_enable,
+	.disable    = inno_hdmi_encoder_disable,
+	.mode_fixup = inno_hdmi_encoder_mode_fixup,
+	.mode_set   = inno_hdmi_encoder_mode_set,
+};
+
+static struct drm_encoder_funcs inno_hdmi_encoder_funcs = {
+	.destroy = drm_encoder_cleanup,
+};
+
+static enum drm_connector_status
+inno_hdmi_connector_detect(struct drm_connector *connector, bool force)
+{
+	struct inno_hdmi *hdmi = to_inno_hdmi(connector);
+
+	return (hdmi_readb(hdmi, HDMI_STATUS) & m_HOTPLUG) ?
+		connector_status_connected : connector_status_disconnected;
+}
+
+static int inno_hdmi_connector_get_modes(struct drm_connector *connector)
+{
+	struct inno_hdmi *hdmi = to_inno_hdmi(connector);
+	struct edid *edid;
+	int ret = 0;
+
+	if (!hdmi->ddc)
+		return 0;
+
+	edid = drm_get_edid(connector, hdmi->ddc);
+	if (edid) {
+		hdmi->hdmi_data.sink_is_hdmi = drm_detect_hdmi_monitor(edid);
+		hdmi->hdmi_data.sink_has_audio = drm_detect_monitor_audio(edid);
+		drm_mode_connector_update_edid_property(connector, edid);
+		ret = drm_add_edid_modes(connector, edid);
+		kfree(edid);
+	}
+
+	return ret;
+}
+
+static enum drm_mode_status
+inno_hdmi_connector_mode_valid(struct drm_connector *connector,
+			       struct drm_display_mode *mode)
+{
+	return MODE_OK;
+}
+
+static struct drm_encoder *
+inno_hdmi_connector_best_encoder(struct drm_connector *connector)
+{
+	struct inno_hdmi *hdmi = to_inno_hdmi(connector);
+
+	return &hdmi->encoder;
+}
+
+static int
+inno_hdmi_probe_single_connector_modes(struct drm_connector *connector,
+				       uint32_t maxX, uint32_t maxY)
+{
+	return drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+}
+
+static void inno_hdmi_connector_destroy(struct drm_connector *connector)
+{
+	drm_connector_unregister(connector);
+	drm_connector_cleanup(connector);
+}
+
+static struct drm_connector_funcs inno_hdmi_connector_funcs = {
+	.dpms = drm_atomic_helper_connector_dpms,
+	.fill_modes = inno_hdmi_probe_single_connector_modes,
+	.detect = inno_hdmi_connector_detect,
+	.destroy = inno_hdmi_connector_destroy,
+	.reset = drm_atomic_helper_connector_reset,
+	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static struct drm_connector_helper_funcs inno_hdmi_connector_helper_funcs = {
+	.get_modes = inno_hdmi_connector_get_modes,
+	.mode_valid = inno_hdmi_connector_mode_valid,
+	.best_encoder = inno_hdmi_connector_best_encoder,
+};
+
+static int inno_hdmi_register(struct drm_device *drm, struct inno_hdmi *hdmi)
+{
+	struct drm_encoder *encoder = &hdmi->encoder;
+	struct device *dev = hdmi->dev;
+
+	encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
+
+	/*
+	 * If we failed to find the CRTC(s) which this encoder is
+	 * supposed to be connected to, it's because the CRTC has
+	 * not been registered yet.  Defer probing, and hope that
+	 * the required CRTC is added later.
+	 */
+	if (encoder->possible_crtcs == 0)
+		return -EPROBE_DEFER;
+
+	drm_encoder_helper_add(encoder, &inno_hdmi_encoder_helper_funcs);
+	drm_encoder_init(drm, encoder, &inno_hdmi_encoder_funcs,
+			 DRM_MODE_ENCODER_TMDS, NULL);
+
+	hdmi->connector.polled = DRM_CONNECTOR_POLL_HPD;
+
+	drm_connector_helper_add(&hdmi->connector,
+				 &inno_hdmi_connector_helper_funcs);
+	drm_connector_init(drm, &hdmi->connector, &inno_hdmi_connector_funcs,
+			   DRM_MODE_CONNECTOR_HDMIA);
+
+	drm_mode_connector_attach_encoder(&hdmi->connector, encoder);
+
+	return 0;
+}
+
+static irqreturn_t inno_hdmi_i2c_irq(struct inno_hdmi *hdmi)
+{
+	struct inno_hdmi_i2c *i2c = hdmi->i2c;
+	u8 stat;
+
+	stat = hdmi_readb(hdmi, HDMI_INTERRUPT_STATUS1);
+	if (!(stat & m_INT_EDID_READY))
+		return IRQ_NONE;
+
+	/* Clear HDMI EDID interrupt flag */
+	hdmi_writeb(hdmi, HDMI_INTERRUPT_STATUS1, m_INT_EDID_READY);
+
+	complete(&i2c->cmp);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t inno_hdmi_hardirq(int irq, void *dev_id)
+{
+	struct inno_hdmi *hdmi = dev_id;
+	irqreturn_t ret = IRQ_NONE;
+	u8 interrupt;
+
+	if (hdmi->i2c)
+		ret = inno_hdmi_i2c_irq(hdmi);
+
+	interrupt = hdmi_readb(hdmi, HDMI_STATUS);
+	if (interrupt & m_INT_HOTPLUG) {
+		hdmi_modb(hdmi, HDMI_STATUS, m_INT_HOTPLUG, m_INT_HOTPLUG);
+		ret = IRQ_WAKE_THREAD;
+	}
+
+	return ret;
+}
+
+static irqreturn_t inno_hdmi_irq(int irq, void *dev_id)
+{
+	struct inno_hdmi *hdmi = dev_id;
+
+	drm_helper_hpd_irq_event(hdmi->connector.dev);
+
+	return IRQ_HANDLED;
+}
+
+static int inno_hdmi_i2c_read(struct inno_hdmi *hdmi, struct i2c_msg *msgs)
+{
+	int length = msgs->len;
+	u8 *buf = msgs->buf;
+	int ret;
+
+	ret = wait_for_completion_timeout(&hdmi->i2c->cmp, HZ / 10);
+	if (!ret)
+		return -EAGAIN;
+
+	while (length--)
+		*buf++ = hdmi_readb(hdmi, HDMI_EDID_FIFO_ADDR);
+
+	return 0;
+}
+
+static int inno_hdmi_i2c_write(struct inno_hdmi *hdmi, struct i2c_msg *msgs)
+{
+	/*
+	 * The DDC module only support read EDID message, so
+	 * we assume that each word write to this i2c adapter
+	 * should be the offset of EDID word address.
+	 */
+	if ((msgs->len != 1) ||
+	    ((msgs->addr != DDC_ADDR) && (msgs->addr != DDC_SEGMENT_ADDR)))
+		return -EINVAL;
+
+	reinit_completion(&hdmi->i2c->cmp);
+
+	if (msgs->addr == DDC_SEGMENT_ADDR)
+		hdmi->i2c->segment_addr = msgs->buf[0];
+	if (msgs->addr == DDC_ADDR)
+		hdmi->i2c->ddc_addr = msgs->buf[0];
+
+	/* Set edid fifo first addr */
+	hdmi_writeb(hdmi, HDMI_EDID_FIFO_OFFSET, 0x00);
+
+	/* Set edid word address 0x00/0x80 */
+	hdmi_writeb(hdmi, HDMI_EDID_WORD_ADDR, hdmi->i2c->ddc_addr);
+
+	/* Set edid segment pointer */
+	hdmi_writeb(hdmi, HDMI_EDID_SEGMENT_POINTER, hdmi->i2c->segment_addr);
+
+	return 0;
+}
+
+static int inno_hdmi_i2c_xfer(struct i2c_adapter *adap,
+			      struct i2c_msg *msgs, int num)
+{
+	struct inno_hdmi *hdmi = i2c_get_adapdata(adap);
+	struct inno_hdmi_i2c *i2c = hdmi->i2c;
+	int i, ret = 0;
+
+	mutex_lock(&i2c->lock);
+
+	/* Clear the EDID interrupt flag and unmute the interrupt */
+	hdmi_writeb(hdmi, HDMI_INTERRUPT_MASK1, m_INT_EDID_READY);
+	hdmi_writeb(hdmi, HDMI_INTERRUPT_STATUS1, m_INT_EDID_READY);
+
+	for (i = 0; i < num; i++) {
+		dev_dbg(hdmi->dev, "xfer: num: %d/%d, len: %d, flags: %#x\n",
+			i + 1, num, msgs[i].len, msgs[i].flags);
+
+		if (msgs[i].flags & I2C_M_RD)
+			ret = inno_hdmi_i2c_read(hdmi, &msgs[i]);
+		else
+			ret = inno_hdmi_i2c_write(hdmi, &msgs[i]);
+
+		if (ret < 0)
+			break;
+	}
+
+	if (!ret)
+		ret = num;
+
+	/* Mute HDMI EDID interrupt */
+	hdmi_writeb(hdmi, HDMI_INTERRUPT_MASK1, 0);
+
+	mutex_unlock(&i2c->lock);
+
+	return ret;
+}
+
+static u32 inno_hdmi_i2c_func(struct i2c_adapter *adapter)
+{
+	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+}
+
+static const struct i2c_algorithm inno_hdmi_algorithm = {
+	.master_xfer	= inno_hdmi_i2c_xfer,
+	.functionality	= inno_hdmi_i2c_func,
+};
+
+static struct i2c_adapter *inno_hdmi_i2c_adapter(struct inno_hdmi *hdmi)
+{
+	struct i2c_adapter *adap;
+	struct inno_hdmi_i2c *i2c;
+	int ret;
+
+	i2c = devm_kzalloc(hdmi->dev, sizeof(*i2c), GFP_KERNEL);
+	if (!i2c)
+		return ERR_PTR(-ENOMEM);
+
+	mutex_init(&i2c->lock);
+	init_completion(&i2c->cmp);
+
+	adap = &i2c->adap;
+	adap->class = I2C_CLASS_DDC;
+	adap->owner = THIS_MODULE;
+	adap->dev.parent = hdmi->dev;
+	adap->dev.of_node = hdmi->dev->of_node;
+	adap->algo = &inno_hdmi_algorithm;
+	strlcpy(adap->name, "Inno HDMI", sizeof(adap->name));
+	i2c_set_adapdata(adap, hdmi);
+
+	ret = i2c_add_adapter(adap);
+	if (ret) {
+		dev_warn(hdmi->dev, "cannot add %s I2C adapter\n", adap->name);
+		devm_kfree(hdmi->dev, i2c);
+		return ERR_PTR(ret);
+	}
+
+	hdmi->i2c = i2c;
+
+	dev_info(hdmi->dev, "registered %s I2C bus driver\n", adap->name);
+
+	return adap;
+}
+
+static int inno_hdmi_bind(struct device *dev, struct device *master,
+				 void *data)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct drm_device *drm = data;
+	struct inno_hdmi *hdmi;
+	struct resource *iores;
+	int irq;
+	int ret;
+
+	hdmi = devm_kzalloc(dev, sizeof(*hdmi), GFP_KERNEL);
+	if (!hdmi)
+		return -ENOMEM;
+
+	hdmi->dev = dev;
+	hdmi->drm_dev = drm;
+
+	iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!iores)
+		return -ENXIO;
+
+	hdmi->regs = devm_ioremap_resource(dev, iores);
+	if (IS_ERR(hdmi->regs))
+		return PTR_ERR(hdmi->regs);
+
+	hdmi->pclk = devm_clk_get(hdmi->dev, "pclk");
+	if (IS_ERR(hdmi->pclk)) {
+		dev_err(hdmi->dev, "Unable to get HDMI pclk clk\n");
+		return PTR_ERR(hdmi->pclk);
+	}
+
+	ret = clk_prepare_enable(hdmi->pclk);
+	if (ret) {
+		dev_err(hdmi->dev, "Cannot enable HDMI pclk clock: %d\n", ret);
+		return ret;
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0)
+		return irq;
+
+	inno_hdmi_reset(hdmi);
+
+	hdmi->ddc = inno_hdmi_i2c_adapter(hdmi);
+	if (IS_ERR(hdmi->ddc)) {
+		hdmi->ddc = NULL;
+		return PTR_ERR(hdmi->ddc);
+	}
+
+	/*
+	 * When IP controller haven't configured to an accurate video
+	 * timing, then the TMDS clock source would be switched to
+	 * PCLK_HDMI, so we need to init the TMDS rate to PCLK rate,
+	 * and reconfigure the DDC clock.
+	 */
+	hdmi->tmds_rate = clk_get_rate(hdmi->pclk);
+	inno_hdmi_i2c_init(hdmi);
+
+	ret = inno_hdmi_register(drm, hdmi);
+	if (ret)
+		return ret;
+
+	dev_set_drvdata(dev, hdmi);
+
+	/* Unmute hotplug interrupt */
+	hdmi_modb(hdmi, HDMI_STATUS, m_MASK_INT_HOTPLUG, v_MASK_INT_HOTPLUG(1));
+
+	ret = devm_request_threaded_irq(dev, irq, inno_hdmi_hardirq,
+					inno_hdmi_irq, IRQF_SHARED,
+					dev_name(dev), hdmi);
+
+	return ret;
+}
+
+static void inno_hdmi_unbind(struct device *dev, struct device *master,
+			     void *data)
+{
+	struct inno_hdmi *hdmi = dev_get_drvdata(dev);
+
+	hdmi->connector.funcs->destroy(&hdmi->connector);
+	hdmi->encoder.funcs->destroy(&hdmi->encoder);
+
+	clk_disable_unprepare(hdmi->pclk);
+	i2c_put_adapter(hdmi->ddc);
+}
+
+static const struct component_ops inno_hdmi_ops = {
+	.bind	= inno_hdmi_bind,
+	.unbind	= inno_hdmi_unbind,
+};
+
+static int inno_hdmi_probe(struct platform_device *pdev)
+{
+	return component_add(&pdev->dev, &inno_hdmi_ops);
+}
+
+static int inno_hdmi_remove(struct platform_device *pdev)
+{
+	component_del(&pdev->dev, &inno_hdmi_ops);
+
+	return 0;
+}
+
+static const struct of_device_id inno_hdmi_dt_ids[] = {
+	{ .compatible = "rockchip,rk3036-inno-hdmi",
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, inno_hdmi_dt_ids);
+
+static struct platform_driver inno_hdmi_driver = {
+	.probe  = inno_hdmi_probe,
+	.remove = inno_hdmi_remove,
+	.driver = {
+		.name = "innohdmi-rockchip",
+		.of_match_table = inno_hdmi_dt_ids,
+	},
+};
+
+module_platform_driver(inno_hdmi_driver);
+
+MODULE_AUTHOR("Zheng Yang <zhengyang at rock-chips.com>");
+MODULE_AUTHOR("Yakir Yang <ykk at rock-chips.com>");
+MODULE_DESCRIPTION("Rockchip Specific INNO-HDMI Driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:innohdmi-rockchip");
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.h b/drivers/gpu/drm/rockchip/inno_hdmi.h
new file mode 100644
index 0000000..aa7c415
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.h
@@ -0,0 +1,362 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ *    Zheng Yang <zhengyang at rock-chips.com>
+ *    Yakir Yang <ykk at rock-chips.com>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __INNO_HDMI_H__
+#define __INNO_HDMI_H__
+
+#define DDC_SEGMENT_ADDR		0x30
+
+enum PWR_MODE {
+	NORMAL,
+	LOWER_PWR,
+};
+
+#define HDMI_SCL_RATE			(100*1000)
+#define DDC_BUS_FREQ_L			0x4b
+#define DDC_BUS_FREQ_H			0x4c
+
+#define HDMI_SYS_CTRL			0x00
+#define m_RST_ANALOG			(1 << 6)
+#define v_RST_ANALOG			(0 << 6)
+#define v_NOT_RST_ANALOG		(1 << 6)
+#define m_RST_DIGITAL			(1 << 5)
+#define v_RST_DIGITAL			(0 << 5)
+#define v_NOT_RST_DIGITAL		(1 << 5)
+#define m_REG_CLK_INV			(1 << 4)
+#define v_REG_CLK_NOT_INV		(0 << 4)
+#define v_REG_CLK_INV			(1 << 4)
+#define m_VCLK_INV			(1 << 3)
+#define v_VCLK_NOT_INV			(0 << 3)
+#define v_VCLK_INV			(1 << 3)
+#define m_REG_CLK_SOURCE		(1 << 2)
+#define v_REG_CLK_SOURCE_TMDS		(0 << 2)
+#define v_REG_CLK_SOURCE_SYS		(1 << 2)
+#define m_POWER				(1 << 1)
+#define v_PWR_ON			(0 << 1)
+#define v_PWR_OFF			(1 << 1)
+#define m_INT_POL			(1 << 0)
+#define v_INT_POL_HIGH			1
+#define v_INT_POL_LOW			0
+
+#define HDMI_VIDEO_CONTRL1		0x01
+#define m_VIDEO_INPUT_FORMAT		(7 << 1)
+#define m_DE_SOURCE			(1 << 0)
+#define v_VIDEO_INPUT_FORMAT(n)		(n << 1)
+#define v_DE_EXTERNAL			1
+#define v_DE_INTERNAL			0
+enum {
+	VIDEO_INPUT_SDR_RGB444 = 0,
+	VIDEO_INPUT_DDR_RGB444 = 5,
+	VIDEO_INPUT_DDR_YCBCR422 = 6
+};
+
+#define HDMI_VIDEO_CONTRL2		0x02
+#define m_VIDEO_OUTPUT_COLOR		(3 << 6)
+#define m_VIDEO_INPUT_BITS		(3 << 4)
+#define m_VIDEO_INPUT_CSP		(1 << 0)
+#define v_VIDEO_OUTPUT_COLOR(n)		(((n) & 0x3) << 6)
+#define v_VIDEO_INPUT_BITS(n)		(n << 4)
+#define v_VIDEO_INPUT_CSP(n)		(n << 0)
+enum {
+	VIDEO_INPUT_12BITS = 0,
+	VIDEO_INPUT_10BITS = 1,
+	VIDEO_INPUT_REVERT = 2,
+	VIDEO_INPUT_8BITS = 3,
+};
+
+#define HDMI_VIDEO_CONTRL		0x03
+#define m_VIDEO_AUTO_CSC		(1 << 7)
+#define v_VIDEO_AUTO_CSC(n)		(n << 7)
+#define m_VIDEO_C0_C2_SWAP		(1 << 0)
+#define v_VIDEO_C0_C2_SWAP(n)		(n << 0)
+enum {
+	C0_C2_CHANGE_ENABLE = 0,
+	C0_C2_CHANGE_DISABLE = 1,
+	AUTO_CSC_DISABLE = 0,
+	AUTO_CSC_ENABLE = 1,
+};
+
+#define HDMI_VIDEO_CONTRL3		0x04
+#define m_COLOR_DEPTH_NOT_INDICATED	(1 << 4)
+#define m_SOF				(1 << 3)
+#define m_COLOR_RANGE			(1 << 2)
+#define m_CSC				(1 << 0)
+#define v_COLOR_DEPTH_NOT_INDICATED(n)	((n) << 4)
+#define v_SOF_ENABLE			(0 << 3)
+#define v_SOF_DISABLE			(1 << 3)
+#define v_COLOR_RANGE_FULL		(1 << 2)
+#define v_COLOR_RANGE_LIMITED		(0 << 2)
+#define v_CSC_ENABLE			1
+#define v_CSC_DISABLE			0
+
+#define HDMI_AV_MUTE			0x05
+#define m_AVMUTE_CLEAR			(1 << 7)
+#define m_AVMUTE_ENABLE			(1 << 6)
+#define m_AUDIO_MUTE			(1 << 1)
+#define m_VIDEO_BLACK			(1 << 0)
+#define v_AVMUTE_CLEAR(n)		(n << 7)
+#define v_AVMUTE_ENABLE(n)		(n << 6)
+#define v_AUDIO_MUTE(n)			(n << 1)
+#define v_VIDEO_MUTE(n)			(n << 0)
+
+#define HDMI_VIDEO_TIMING_CTL		0x08
+#define v_HSYNC_POLARITY(n)		(n << 3)
+#define v_VSYNC_POLARITY(n)		(n << 2)
+#define v_INETLACE(n)			(n << 1)
+#define v_EXTERANL_VIDEO(n)		(n << 0)
+
+#define HDMI_VIDEO_EXT_HTOTAL_L		0x09
+#define HDMI_VIDEO_EXT_HTOTAL_H		0x0a
+#define HDMI_VIDEO_EXT_HBLANK_L		0x0b
+#define HDMI_VIDEO_EXT_HBLANK_H		0x0c
+#define HDMI_VIDEO_EXT_HDELAY_L		0x0d
+#define HDMI_VIDEO_EXT_HDELAY_H		0x0e
+#define HDMI_VIDEO_EXT_HDURATION_L	0x0f
+#define HDMI_VIDEO_EXT_HDURATION_H	0x10
+#define HDMI_VIDEO_EXT_VTOTAL_L		0x11
+#define HDMI_VIDEO_EXT_VTOTAL_H		0x12
+#define HDMI_VIDEO_EXT_VBLANK		0x13
+#define HDMI_VIDEO_EXT_VDELAY		0x14
+#define HDMI_VIDEO_EXT_VDURATION	0x15
+
+#define HDMI_VIDEO_CSC_COEF		0x18
+
+#define HDMI_AUDIO_CTRL1		0x35
+enum {
+	CTS_SOURCE_INTERNAL = 0,
+	CTS_SOURCE_EXTERNAL = 1,
+};
+#define v_CTS_SOURCE(n)			(n << 7)
+
+enum {
+	DOWNSAMPLE_DISABLE = 0,
+	DOWNSAMPLE_1_2 = 1,
+	DOWNSAMPLE_1_4 = 2,
+};
+#define v_DOWN_SAMPLE(n)		(n << 5)
+
+enum {
+	AUDIO_SOURCE_IIS = 0,
+	AUDIO_SOURCE_SPDIF = 1,
+};
+#define v_AUDIO_SOURCE(n)		(n << 3)
+
+#define v_MCLK_ENABLE(n)		(n << 2)
+enum {
+	MCLK_128FS = 0,
+	MCLK_256FS = 1,
+	MCLK_384FS = 2,
+	MCLK_512FS = 3,
+};
+#define v_MCLK_RATIO(n)			(n)
+
+#define AUDIO_SAMPLE_RATE		0x37
+enum {
+	AUDIO_32K = 0x3,
+	AUDIO_441K = 0x0,
+	AUDIO_48K = 0x2,
+	AUDIO_882K = 0x8,
+	AUDIO_96K = 0xa,
+	AUDIO_1764K = 0xc,
+	AUDIO_192K = 0xe,
+};
+
+#define AUDIO_I2S_MODE			0x38
+enum {
+	I2S_CHANNEL_1_2 = 1,
+	I2S_CHANNEL_3_4 = 3,
+	I2S_CHANNEL_5_6 = 7,
+	I2S_CHANNEL_7_8 = 0xf
+};
+#define v_I2S_CHANNEL(n)		((n) << 2)
+enum {
+	I2S_STANDARD = 0,
+	I2S_LEFT_JUSTIFIED = 1,
+	I2S_RIGHT_JUSTIFIED = 2,
+};
+#define v_I2S_MODE(n)			(n)
+
+#define AUDIO_I2S_MAP			0x39
+#define AUDIO_I2S_SWAPS_SPDIF		0x3a
+#define v_SPIDF_FREQ(n)			(n)
+
+#define N_32K				0x1000
+#define N_441K				0x1880
+#define N_882K				0x3100
+#define N_1764K				0x6200
+#define N_48K				0x1800
+#define N_96K				0x3000
+#define N_192K				0x6000
+
+#define HDMI_AUDIO_CHANNEL_STATUS	0x3e
+#define m_AUDIO_STATUS_NLPCM		(1 << 7)
+#define m_AUDIO_STATUS_USE		(1 << 6)
+#define m_AUDIO_STATUS_COPYRIGHT	(1 << 5)
+#define m_AUDIO_STATUS_ADDITION		(3 << 2)
+#define m_AUDIO_STATUS_CLK_ACCURACY	(2 << 0)
+#define v_AUDIO_STATUS_NLPCM(n)		((n & 1) << 7)
+#define AUDIO_N_H			0x3f
+#define AUDIO_N_M			0x40
+#define AUDIO_N_L			0x41
+
+#define HDMI_AUDIO_CTS_H		0x45
+#define HDMI_AUDIO_CTS_M		0x46
+#define HDMI_AUDIO_CTS_L		0x47
+
+#define HDMI_DDC_CLK_L			0x4b
+#define HDMI_DDC_CLK_H			0x4c
+
+#define HDMI_EDID_SEGMENT_POINTER	0x4d
+#define HDMI_EDID_WORD_ADDR		0x4e
+#define HDMI_EDID_FIFO_OFFSET		0x4f
+#define HDMI_EDID_FIFO_ADDR		0x50
+
+#define HDMI_PACKET_SEND_MANUAL		0x9c
+#define HDMI_PACKET_SEND_AUTO		0x9d
+#define m_PACKET_GCP_EN			(1 << 7)
+#define m_PACKET_MSI_EN			(1 << 6)
+#define m_PACKET_SDI_EN			(1 << 5)
+#define m_PACKET_VSI_EN			(1 << 4)
+#define v_PACKET_GCP_EN(n)		((n & 1) << 7)
+#define v_PACKET_MSI_EN(n)		((n & 1) << 6)
+#define v_PACKET_SDI_EN(n)		((n & 1) << 5)
+#define v_PACKET_VSI_EN(n)		((n & 1) << 4)
+
+#define HDMI_CONTROL_PACKET_BUF_INDEX	0x9f
+enum {
+	INFOFRAME_VSI = 0x05,
+	INFOFRAME_AVI = 0x06,
+	INFOFRAME_AAI = 0x08,
+};
+
+#define HDMI_CONTROL_PACKET_ADDR	0xa0
+#define HDMI_MAXIMUM_INFO_FRAME_SIZE	0x11
+enum {
+	AVI_COLOR_MODE_RGB = 0,
+	AVI_COLOR_MODE_YCBCR422 = 1,
+	AVI_COLOR_MODE_YCBCR444 = 2,
+	AVI_COLORIMETRY_NO_DATA = 0,
+
+	AVI_COLORIMETRY_SMPTE_170M = 1,
+	AVI_COLORIMETRY_ITU709 = 2,
+	AVI_COLORIMETRY_EXTENDED = 3,
+
+	AVI_CODED_FRAME_ASPECT_NO_DATA = 0,
+	AVI_CODED_FRAME_ASPECT_4_3 = 1,
+	AVI_CODED_FRAME_ASPECT_16_9 = 2,
+
+	ACTIVE_ASPECT_RATE_SAME_AS_CODED_FRAME = 0x08,
+	ACTIVE_ASPECT_RATE_4_3 = 0x09,
+	ACTIVE_ASPECT_RATE_16_9 = 0x0A,
+	ACTIVE_ASPECT_RATE_14_9 = 0x0B,
+};
+
+#define HDMI_HDCP_CTRL			0x52
+#define m_HDMI_DVI			(1 << 1)
+#define v_HDMI_DVI(n)			(n << 1)
+
+#define HDMI_INTERRUPT_MASK1		0xc0
+#define HDMI_INTERRUPT_STATUS1		0xc1
+#define	m_INT_ACTIVE_VSYNC		(1 << 5)
+#define m_INT_EDID_READY		(1 << 2)
+
+#define HDMI_INTERRUPT_MASK2		0xc2
+#define HDMI_INTERRUPT_STATUS2		0xc3
+#define m_INT_HDCP_ERR			(1 << 7)
+#define m_INT_BKSV_FLAG			(1 << 6)
+#define m_INT_HDCP_OK			(1 << 4)
+
+#define HDMI_STATUS			0xc8
+#define m_HOTPLUG			(1 << 7)
+#define m_MASK_INT_HOTPLUG		(1 << 5)
+#define m_INT_HOTPLUG			(1 << 1)
+#define v_MASK_INT_HOTPLUG(n)		((n & 0x1) << 5)
+
+#define HDMI_COLORBAR                   0xc9
+
+#define HDMI_PHY_SYNC			0xce
+#define HDMI_PHY_SYS_CTL		0xe0
+#define m_TMDS_CLK_SOURCE		(1 << 5)
+#define v_TMDS_FROM_PLL			(0 << 5)
+#define v_TMDS_FROM_GEN			(1 << 5)
+#define m_PHASE_CLK			(1 << 4)
+#define v_DEFAULT_PHASE			(0 << 4)
+#define v_SYNC_PHASE			(1 << 4)
+#define m_TMDS_CURRENT_PWR		(1 << 3)
+#define v_TURN_ON_CURRENT		(0 << 3)
+#define v_CAT_OFF_CURRENT		(1 << 3)
+#define m_BANDGAP_PWR			(1 << 2)
+#define v_BANDGAP_PWR_UP		(0 << 2)
+#define v_BANDGAP_PWR_DOWN		(1 << 2)
+#define m_PLL_PWR			(1 << 1)
+#define v_PLL_PWR_UP			(0 << 1)
+#define v_PLL_PWR_DOWN			(1 << 1)
+#define m_TMDS_CHG_PWR			(1 << 0)
+#define v_TMDS_CHG_PWR_UP		(0 << 0)
+#define v_TMDS_CHG_PWR_DOWN		(1 << 0)
+
+#define HDMI_PHY_CHG_PWR		0xe1
+#define v_CLK_CHG_PWR(n)		((n & 1) << 3)
+#define v_DATA_CHG_PWR(n)		((n & 7) << 0)
+
+#define HDMI_PHY_DRIVER			0xe2
+#define v_CLK_MAIN_DRIVER(n)		(n << 4)
+#define v_DATA_MAIN_DRIVER(n)		(n << 0)
+
+#define HDMI_PHY_PRE_EMPHASIS		0xe3
+#define v_PRE_EMPHASIS(n)		((n & 7) << 4)
+#define v_CLK_PRE_DRIVER(n)		((n & 3) << 2)
+#define v_DATA_PRE_DRIVER(n)		((n & 3) << 0)
+
+#define HDMI_PHY_FEEDBACK_DIV_RATIO_LOW		0xe7
+#define v_FEEDBACK_DIV_LOW(n)			(n & 0xff)
+#define HDMI_PHY_FEEDBACK_DIV_RATIO_HIGH	0xe8
+#define v_FEEDBACK_DIV_HIGH(n)			(n & 1)
+
+#define HDMI_PHY_PRE_DIV_RATIO		0xed
+#define v_PRE_DIV_RATIO(n)		(n & 0x1f)
+
+#define HDMI_CEC_CTRL			0xd0
+#define m_ADJUST_FOR_HISENSE		(1 << 6)
+#define m_REJECT_RX_BROADCAST		(1 << 5)
+#define m_BUSFREETIME_ENABLE		(1 << 2)
+#define m_REJECT_RX			(1 << 1)
+#define m_START_TX			(1 << 0)
+
+#define HDMI_CEC_DATA			0xd1
+#define HDMI_CEC_TX_OFFSET		0xd2
+#define HDMI_CEC_RX_OFFSET		0xd3
+#define HDMI_CEC_CLK_H			0xd4
+#define HDMI_CEC_CLK_L			0xd5
+#define HDMI_CEC_TX_LENGTH		0xd6
+#define HDMI_CEC_RX_LENGTH		0xd7
+#define HDMI_CEC_TX_INT_MASK		0xd8
+#define m_TX_DONE			(1 << 3)
+#define m_TX_NOACK			(1 << 2)
+#define m_TX_BROADCAST_REJ		(1 << 1)
+#define m_TX_BUSNOTFREE			(1 << 0)
+
+#define HDMI_CEC_RX_INT_MASK		0xd9
+#define m_RX_LA_ERR			(1 << 4)
+#define m_RX_GLITCH			(1 << 3)
+#define m_RX_DONE			(1 << 0)
+
+#define HDMI_CEC_TX_INT			0xda
+#define HDMI_CEC_RX_INT			0xdb
+#define HDMI_CEC_BUSFREETIME_L		0xdc
+#define HDMI_CEC_BUSFREETIME_H		0xdd
+#define HDMI_CEC_LOGICADDR		0xde
+
+#endif /* __INNO_HDMI_H__ */
-- 
1.9.1




From mcoquelin.stm32 at gmail.com  Wed Feb  3 01:53:31 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Wed, 3 Feb 2016 10:53:31 +0100
Subject: [PATCH 3/3] kallsyms: remove --page-offset command line option
In-Reply-To: <CAKv+Gu8vzvX-6=+SgPwm2CUy_1Qpt-GHvzv=brQTs50i2Z=v9w@mail.gmail.com>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454419174-21290-4-git-send-email-ard.biesheuvel@linaro.org>
 <20160203000504.GY10826@n2100.arm.linux.org.uk>
 <CAKv+Gu8vzvX-6=+SgPwm2CUy_1Qpt-GHvzv=brQTs50i2Z=v9w@mail.gmail.com>
Message-ID: <CALszF6B5B7=KxDLXZktpF-FYxW4fHCrQ_Xp1fyN513aBUmee_A@mail.gmail.com>

2016-02-03 9:16 GMT+01:00 Ard Biesheuvel <ard.biesheuvel at linaro.org>:
> (+ Uwe, Maxime)
>
> Complete thread here:
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/474400
>
> On 3 February 2016 at 01:05, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
>> On Tue, Feb 02, 2016 at 02:19:34PM +0100, Ard Biesheuvel wrote:
>>> The --page-offset command line option was only used for ARM, to filter
>>> symbol addresses below CONFIG_PAGE_OFFSET. This is no longer needed, so
>>> remove the functionality altogether.
>>
>> From what I remember, this option has nothing to do with MMU-ful ARM,
>> but noMMU ARM, where the .text segment can be significantly different
>> from the .data segment.
>>
>> I think you need to talk to noMMU people about this patch.
>>
>
> We have
>
> commit f6537f2f0eba4eba3354e48dbe3047db6d8b6254
> Author: Ming Lei <tom.leiming at gmail.com>
> Date:   Sat Nov 2 09:11:33 2013 +1030
>
>     scripts/kallsyms: filter symbols not in kernel address space
>
>     This patch uses CONFIG_PAGE_OFFSET to filter symbols which
>     are not in kernel address space because these symbols are
>     generally for generating code purpose and can't be run at
>     kernel mode, so we needn't keep them in /proc/kallsyms.
>
>     For example, on ARM there are some symbols which may be
>     linked in relocatable code section, then perf can't parse
>     symbols any more from /proc/kallsyms, this patch fixes the
>     problem (introduced b9b32bf70f2fb710b07c94e13afbc729afe221da)
>
> which introduces the --page-offset option to kallsyms, in response to
> your patch that moves .vectors and .stubs to VMA 0x0. Then we have
>
> commit 7122c3e9154b5d9a7422f68f02d8acf050fad2b0
> Author: Ming Lei <tom.leiming at gmail.com>
> Date:   Tue Dec 10 16:46:29 2013 +1030
>
>     scripts/link-vmlinux.sh: only filter kernel symbols for arm
>
>     Actually CONFIG_PAGE_OFFSET isn't same with PAGE_OFFSET, so
>     it isn't easy to figue out PAGE_OFFSET defined in header
>     file from scripts.
>
>     Because CONFIG_PAGE_OFFSET may not be defined in some ARCHs(
>     64bit ARCH), or defined as bogus value in !MMU case, so
>     this patch only applys the filter on ARM when CONFIG_PAGE_OFFSET
>     is defined as the original problem is only on ARM.
>
> which restricts the use of --page-offset to CONFIG_ARM, and
>
> commit cc8475305203ddfd117b81e2e732194b67d8f310
> Author: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> Date:   Thu May 21 19:17:44 2015 +0800
>
>     scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel
>
>     When Kernel is executed in place from ROM, the symbol addresses can be
>     lower than the page offset.
>
> which restricts the use of --page-offset to CONFIG_ARM && !CONFIG_XIP_KERNEL
>
> So it looks like the Dec 10 patch fixes some fallout related to !MMU
> that was caused by the Nov 2 patch, but the original patch has nothing
> to do with !MMU. Furthermore, 3 out of 4 !MMU configs we have in the
> tree (efm32, stm32 and vf610m4) are also XIP kernel, for which
> --page-offset isn't even used to begin with after Maxime's patch.
> Hopefully Uwe and/or Maxime can confirm, but removing the PAGE_OFFSET
> lower limit should not affect those platforms at all afaict,
> especially since, after patch 1/3, there are no symbols left to filter
> below that limit in the first place.

I agree with you, removing the PAGE_OFFSET lower limit should not
affect our platforms.

Regards,
Maxime


From mingo at kernel.org  Wed Feb  3 02:02:01 2016
From: mingo at kernel.org (Ingo Molnar)
Date: Wed, 3 Feb 2016 11:02:01 +0100
Subject: [GIT PULL 00/16] perf/core improvements and fixes
In-Reply-To: <1454102273-16431-1-git-send-email-acme@kernel.org>
References: <1454102273-16431-1-git-send-email-acme@kernel.org>
Message-ID: <20160203100201.GC17305@gmail.com>


* Arnaldo Carvalho de Melo <acme at kernel.org> wrote:

> Hi Ingo,
> 
> 	This is on top of the previously submitted perf-core-for-mingo tag,
> please consider applying,
> 
> - Arnaldo
> 
> The following changes since commit 5ac76283b32b116c58e362e99542182ddcfc8262:
> 
>   perf cpumap: Auto initialize cpu__max_{node,cpu} (2016-01-26 16:08:36 -0300)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-2
> 
> for you to fetch changes up to 814568db641f6587c1e98a3a85f214cb6a30fe10:
> 
>   perf build: Align the names of the build tests: (2016-01-29 17:51:04 -0300)
> 
> ----------------------------------------------------------------
> New features:
> 
> - Port 'perf kvm stat' to PowerPC (Hemant Kumar)
> 
> Infrastructure:
> 
> - Use the 'feature-dump' target to do the feature checks just once and then
>   add code to reuse that in the tests/make makefile, speeding up the
>   'make -C tools/perf build-test' target (Wang Nan)
> 
> - Reduce the number of tests the 'build-test' target do to those that don't
>   pollute the source tree (Arnaldo Carvalho de Melo)
> 
> - Improve the output of the build tests a bit by aligning the name of the
>   tests, more can be done to filter out uninteresting info in the output
>   (Arnaldo Carvalho de Melo)
> 
> - Add perf_evlist pointer to *info_priv_size(), more prep work for
>   supporting the coresight architecture (Mathieu Poirier)
> 
> - Improve the 'perf test bp_signal' test (Wang Nan)
> 
> - Check environment before starting the BPF 'perf test', so that we can just
>   'Skip' older kernels instead of 'FAIL'ing them (Wang Nan)
> 
> - Fix cpumode of synthesized buildid event (Wang Nan)
> 
> Signed-off-by: Arnaldo Carvalho de Melo <acme at redhat.com>
> 
> ----------------------------------------------------------------
> Arnaldo Carvalho de Melo (2):
>       perf tools: Speed up build-tests by reducing the number of builds tested
>       perf build: Align the names of the build tests:
> 
> Hemant Kumar (4):
>       perf kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h
>       perf kvm/{x86,s390}: Remove const from kvm_events_tp
>       perf kvm/powerpc: Port perf kvm stat to powerpc
>       perf kvm/powerpc: Add support for HCALL reasons
> 
> Jiri Olsa (1):
>       perf build: Fix feature-dump checks, we need to test all features
> 
> Mathieu Poirier (1):
>       perf auxtrace: Add perf_evlist pointer to *info_priv_size()
> 
> Wang Nan (8):
>       tools build: Check basic headers for test-compile feature checker
>       perf build: Remove all condition feature check {C,LD}FLAGS
>       perf build: Use feature dump file for build-test
>       perf buildid: Fix cpumode of buildid event
>       perf test: Check environment before start real BPF test
>       perf test: Improve bp_signal
>       perf tools: Move timestamp creation to util
>       perf record: Use OPT_BOOLEAN_SET for buildid cache related options
> 
>  tools/build/Makefile.feature                   |   8 ++
>  tools/build/feature/test-compile.c             |   2 +
>  tools/perf/Makefile                            |  11 +-
>  tools/perf/arch/powerpc/Makefile               |   2 +
>  tools/perf/arch/powerpc/util/Build             |   1 +
>  tools/perf/arch/powerpc/util/book3s_hcalls.h   | 123 ++++++++++++++++++
>  tools/perf/arch/powerpc/util/book3s_hv_exits.h |  33 +++++
>  tools/perf/arch/powerpc/util/kvm-stat.c        | 170 +++++++++++++++++++++++++
>  tools/perf/arch/s390/util/kvm-stat.c           |  10 +-
>  tools/perf/arch/x86/util/intel-bts.c           |   4 +-
>  tools/perf/arch/x86/util/intel-pt.c            |   4 +-
>  tools/perf/arch/x86/util/kvm-stat.c            |  16 ++-
>  tools/perf/builtin-buildid-cache.c             |  14 +-
>  tools/perf/builtin-kvm.c                       |  38 ++++--
>  tools/perf/builtin-record.c                    |  12 +-
>  tools/perf/config/Makefile                     | 101 +++++++--------
>  tools/perf/tests/bp_signal.c                   | 140 ++++++++++++++++----
>  tools/perf/tests/bpf.c                         |  37 ++++++
>  tools/perf/tests/make                          |  39 +++++-
>  tools/perf/util/auxtrace.c                     |   7 +-
>  tools/perf/util/auxtrace.h                     |   6 +-
>  tools/perf/util/build-id.c                     |   6 +-
>  tools/perf/util/kvm-stat.h                     |   8 +-
>  tools/perf/util/util.c                         |  17 +++
>  tools/perf/util/util.h                         |   1 +
>  25 files changed, 688 insertions(+), 122 deletions(-)
>  create mode 100644 tools/perf/arch/powerpc/util/book3s_hcalls.h
>  create mode 100644 tools/perf/arch/powerpc/util/book3s_hv_exits.h
>  create mode 100644 tools/perf/arch/powerpc/util/kvm-stat.c

Pulled, thanks a lot Arnaldo!

	Ingo


From lkp at intel.com  Wed Feb  3 02:05:22 2016
From: lkp at intel.com (kbuild test robot)
Date: Wed, 3 Feb 2016 18:05:22 +0800
Subject: [PATCH V2 2/6] stm class: adds a loop to extract the first valid
 STM device name
In-Reply-To: <1454487337-30184-3-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <201602031758.BtqxFNRd%fengguang.wu@intel.com>

Hi Chunyan,

[auto build test WARNING on robh/for-next]
[also build test WARNING on v4.5-rc2 next-20160203]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Chunyan-Zhang/Introduce-CoreSight-STM-support/20160203-161836
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next


coccinelle warnings: (new ones prefixed by >>)

>> drivers/hwtracing/stm/policy.c:341:2-3: Unneeded semicolon

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation


From lkp at intel.com  Wed Feb  3 02:05:22 2016
From: lkp at intel.com (kbuild test robot)
Date: Wed, 3 Feb 2016 18:05:22 +0800
Subject: [PATCH] stm class: fix semicolon.cocci warnings
In-Reply-To: <1454487337-30184-3-git-send-email-zhang.chunyan@linaro.org>
References: <201602031758.BtqxFNRd%fengguang.wu@intel.com>
Message-ID: <20160203100522.GA104810@ivytown2>

drivers/hwtracing/stm/policy.c:341:2-3: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Chunyan Zhang <zhang.chunyan at linaro.org>
Signed-off-by: Fengguang Wu <fengguang.wu at intel.com>
---

 policy.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/hwtracing/stm/policy.c
+++ b/drivers/hwtracing/stm/policy.c
@@ -338,7 +338,7 @@ stp_policies_make(struct config_group *g
 		if (stm)
 			break;
 		*p = '.';
-	};
+	}
 
 	kfree(devname);
 


From ulf.hansson at linaro.org  Wed Feb  3 02:23:23 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Wed, 3 Feb 2016 11:23:23 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160202234145.GC19432@atomide.com>
References: <20160201232833.GR19432@atomide.com>
 <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>
 <20160202030533.GT19432@atomide.com>
 <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>
 <20160202163536.GU19432@atomide.com>
 <CAPDyKFosQjkHDVSvy67+hstjjFseXQP5WYXrJE19GgVFYJ099w@mail.gmail.com>
 <20160202234145.GC19432@atomide.com>
Message-ID: <CAPDyKFqLi8xOUeoxUTAmif5QrOjVpV_2CDLv4hjO_C9iOnv+5Q@mail.gmail.com>

On 3 February 2016 at 00:41, Tony Lindgren <tony at atomide.com> wrote:
> * Ulf Hansson <ulf.hansson at linaro.org> [160202 12:48]:
>> On 2 February 2016 at 17:35, Tony Lindgren <tony at atomide.com> wrote:
>> > That's a valid error though, let's not remove it. The reason why we
>> > call runtime_resume() twice is because runtime_suspend callback never
>> > gets called like I explain above.
>>
>> This isn't an error, it's just a hickup in the synchronization of the
>> runtime PM status.
>
> I'd rather not get the hardware state out of sync with PM runtime..
>
>> Very similar what happens at the first probe, when the driver core has
>> initialized the runtime PM status to RPM_SUSPENDED at the device
>> registration.
>
> Well we actually pretty much have devices in that state to start
> with.

That's not true, not even for omap.

There are definitely devices which HW state is reflected by RPM_ACTIVE
at boot. It's the responsible of the subsystem/driver (including PM
domains) to make sure the runtime PM status is updated accordingly, to
reflect the real HW state.

For omap hwmod, at device registration in omap_device_build_from_dt()
it may actually invoke pm_runtime_set_active() if the device is
enabled. To my understanding, that's done to synchronize the real HW
state with the runtime PM status, right?

>
>> To me, it's the responsible of the PM domain to *help* with the
>> synchronization, not prevent it as it currently does.
>
> The problem is that the hardware state gets out of sync with
> PM runtime. And that's going to be a pain to debug later on.

I don't see the problem, but of course you know omap for better than I do.

So if you are concerned about this, perhaps adding a dev_dbg print
when the omap hwmod's ->runtime_suspend() callback returns zero could
be a way forward?

>
>> > --- a/drivers/mmc/host/omap_hsmmc.c
>> > +++ b/drivers/mmc/host/omap_hsmmc.c
>> > @@ -2232,6 +2232,7 @@ err_irq:
>> >                 dma_release_channel(host->tx_chan);
>> >         if (host->rx_chan)
>> >                 dma_release_channel(host->rx_chan);
>> > +       pm_runtime_dont_use_autosuspend(host->dev);
>>
>> It's good know this works, although do you intend to fix this sequence
>> for all omap drivers/devices that's part of the hwmod PM domain?
>>
>> I haven't checked the number of drivers this would affect, but I
>> imagine there could be quite many with similar behaviour and thus may
>> suffer from the same issue.
>
> Yeah not sure what the right fix is. But I'd rather patch the
> few drivers using autosuspend if we come to the conclusion
> that there is no bug in PM runtime.
>
>> Could you please test my version 2 of the patch I attached earlier. I
>> still believe it's the best way to solve the regression, if it works
>> of course. :-)
>
> And I don't like it because of the reasons above :) But yeah
> gave it a quick try and that too works as expected.

Okay, thanks for testing!

Kind regards
Uffe


From narmstrong at baylibre.com  Wed Feb  3 02:23:43 2016
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Wed, 3 Feb 2016 11:23:43 +0100
Subject: [PATCH 1/4] pwm: omap-dmtimer: fix inaccurate period/duty_cycle
 calculation
In-Reply-To: <1454128014-22866-2-git-send-email-drivshin.allworx@gmail.com>
References: <1454128014-22866-1-git-send-email-drivshin.allworx@gmail.com>
 <1454128014-22866-2-git-send-email-drivshin.allworx@gmail.com>
Message-ID: <56B1D52F.70907@baylibre.com>

On 01/30/2016 05:26 AM, David Rivshin (Allworx) wrote:
> From: David Rivshin <drivshin at allworx.com>
> 
> Fix the calculation of load_value and match_value. Currently they
> are slightly too low, which produces a noticeably wrong PWM rate with
> sufficiently short periods (i.e. when 1/period approaches clk_rate/2).
> 
> Example:
>  clk_rate=32768Hz, period=122070ns, duty_cycle=61035ns (8192Hz/50% PWM)
>  Correct values: load = 0xfffffffc, match = 0xfffffffd
>  Current values: load = 0xfffffffa, match = 0xfffffffc
>  effective PWM: period=183105ns, duty_cycle=91553ns (5461Hz/50% PWM)
> 
> Fixes: 6604c6556db9 ("pwm: Add PWM driver for OMAP using dual-mode timers")
> Signed-off-by: David Rivshin <drivshin at allworx.com>

OK for me.

Acked-by: Neil Armstrong <narmstrong at baylibre.com>

Thanks !

> ---
>  drivers/pwm/pwm-omap-dmtimer.c | 27 ++++++++++++++++++++-------
>  1 file changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
> index 826634e..0083e75 100644
> --- a/drivers/pwm/pwm-omap-dmtimer.c
> +++ b/drivers/pwm/pwm-omap-dmtimer.c
> @@ -31,6 +31,7 @@
>  #include <linux/time.h>
>  
>  #define DM_TIMER_LOAD_MIN 0xfffffffe
> +#define DM_TIMER_MAX      0xffffffff
>  
>  struct pwm_omap_dmtimer_chip {
>  	struct pwm_chip chip;
> @@ -46,13 +47,13 @@ to_pwm_omap_dmtimer_chip(struct pwm_chip *chip)
>  	return container_of(chip, struct pwm_omap_dmtimer_chip, chip);
>  }
>  
> -static int pwm_omap_dmtimer_calc_value(unsigned long clk_rate, int ns)
> +static u32 pwm_omap_dmtimer_get_clock_cycles(unsigned long clk_rate, int ns)
>  {
>  	u64 c = (u64)clk_rate * ns;
>  
>  	do_div(c, NSEC_PER_SEC);
>  
> -	return DM_TIMER_LOAD_MIN - c;
> +	return c;
>  }
>  
>  static void pwm_omap_dmtimer_start(struct pwm_omap_dmtimer_chip *omap)
> @@ -99,7 +100,8 @@ static int pwm_omap_dmtimer_config(struct pwm_chip *chip,
>  				   int duty_ns, int period_ns)
>  {
>  	struct pwm_omap_dmtimer_chip *omap = to_pwm_omap_dmtimer_chip(chip);
> -	int load_value, match_value;
> +	u32 period_cycles, duty_cycles;
> +	u32 load_value, match_value;
>  	struct clk *fclk;
>  	unsigned long clk_rate;
>  	bool timer_active;
> @@ -133,11 +135,22 @@ static int pwm_omap_dmtimer_config(struct pwm_chip *chip,
>  	/*
>  	 * Calculate the appropriate load and match values based on the
>  	 * specified period and duty cycle. The load value determines the
> -	 * cycle time and the match value determines the duty cycle.
> +	 * period time and the match value determines the duty time.
> +	 *
> +	 * The period lasts for (DM_TIMER_MAX-load_value+1) clock cycles.
> +	 * Similarly, the active time lasts (match_value-load_value+1) cycles.
> +	 * The non-active time is the remainder: (DM_TIMER_MAX-match_value)
> +	 * clock cycles.
> +	 *
> +	 * References:
> +	 *   OMAP4430/60/70 TRM sections 22.2.4.10 and 22.2.4.11
> +	 *   AM335x Sitara TRM sections 20.1.3.5 and 20.1.3.6
>  	 */
> -	load_value = pwm_omap_dmtimer_calc_value(clk_rate, period_ns);
> -	match_value = pwm_omap_dmtimer_calc_value(clk_rate,
> -						  period_ns - duty_ns);
> +	period_cycles = pwm_omap_dmtimer_get_clock_cycles(clk_rate, period_ns);
> +	duty_cycles = pwm_omap_dmtimer_get_clock_cycles(clk_rate, duty_ns);
> +
> +	load_value = (DM_TIMER_MAX - period_cycles) + 1;
> +	match_value = load_value + duty_cycles - 1;
>  
>  	/*
>  	 * We MUST stop the associated dual-mode timer before attempting to
> 



From narmstrong at baylibre.com  Wed Feb  3 02:24:23 2016
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Wed, 3 Feb 2016 11:24:23 +0100
Subject: [PATCH 2/4] pwm: omap-dmtimer: add sanity checking for load and
 match values
In-Reply-To: <20160201133503.53599493.drivshin.allworx@gmail.com>
References: <1454128014-22866-1-git-send-email-drivshin.allworx@gmail.com>
 <1454128014-22866-3-git-send-email-drivshin.allworx@gmail.com>
 <20160201133503.53599493.drivshin.allworx@gmail.com>
Message-ID: <56B1D557.6040108@baylibre.com>

On 02/01/2016 07:35 PM, David Rivshin (Allworx) wrote:
> On Fri, 29 Jan 2016 23:26:52 -0500
> "David Rivshin (Allworx)" <drivshin.allworx at gmail.com> wrote:
> 
>> From: David Rivshin <drivshin at allworx.com>
>>
>> Add sanity checking to ensure that we do not program load or match
>> values that are out of range if a user requests period or duty_cycle
>> values which are not achievable. The match value cannot be less than
>> the load value (but can be equal), and neither can be 0xffffffff.
>> This means that there must be at least one fclk cycle between load
>> and match, and another between match and overflow.
>>
>> Fixes: 6604c6556db9 ("pwm: Add PWM driver for OMAP using dual-mode
>> timers") Signed-off-by: David Rivshin <drivshin at allworx.com>
>> ---
>  [...]
>> @@ -149,6 +149,24 @@ static int pwm_omap_dmtimer_config(struct pwm_chip *chip, 
>> period_cycles = pwm_omap_dmtimer_get_clock_cycles(clk_rate, period_ns); 
>> duty_cycles = pwm_omap_dmtimer_get_clock_cycles(clk_rate, duty_ns); 
>>
>> +	if (period_cycles < 2) {
>> +		dev_info(chip->dev,
>> +			"period %dns is too short for clock rate %luHz\n",
>> +			period_ns, clk_rate);
>> +		goto err_einval;
>> +	}
>  [...]
> 
> I had some second thoughts on this over the weekend:
> 1) Perhaps the return should be -ERANGE instead of -EINVAL for this case?
> 2) Is dev_info() too severe for this? Perhaps dev_dbg() would be better?
> Any preferences?
> 
The current management is OK for me.

Acked-by: Neil Armstrong <narmstrong at baylibre.com>

Thanks !


From narmstrong at baylibre.com  Wed Feb  3 02:24:55 2016
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Wed, 3 Feb 2016 11:24:55 +0100
Subject: [PATCH 3/4] pwm: omap-dmtimer: round load and match values rather
 than truncate
In-Reply-To: <1454128014-22866-4-git-send-email-drivshin.allworx@gmail.com>
References: <1454128014-22866-1-git-send-email-drivshin.allworx@gmail.com>
 <1454128014-22866-4-git-send-email-drivshin.allworx@gmail.com>
Message-ID: <56B1D577.6070808@baylibre.com>

On 01/30/2016 05:26 AM, David Rivshin (Allworx) wrote:
> From: David Rivshin <drivshin at allworx.com>
> 
> When converting period and duty_cycle from nanoseconds to fclk cycles,
> the error introduced by the integer division can be appreciable, especially
> in the case of slow fclk or short period. Use DIV_ROUND_CLOSEST_ULL() so
> that the error is kept to +/- 0.5 clock cycles.
> 
> Fixes: 6604c6556db9 ("pwm: Add PWM driver for OMAP using dual-mode timers")
> Signed-off-by: David Rivshin <drivshin at allworx.com>

OK for me.

Acked-by: Neil Armstrong <narmstrong at baylibre.com>

Thanks !

> ---
>  drivers/pwm/pwm-omap-dmtimer.c | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
> index 103d729..8c9953c 100644
> --- a/drivers/pwm/pwm-omap-dmtimer.c
> +++ b/drivers/pwm/pwm-omap-dmtimer.c
> @@ -49,11 +49,7 @@ to_pwm_omap_dmtimer_chip(struct pwm_chip *chip)
>  
>  static u32 pwm_omap_dmtimer_get_clock_cycles(unsigned long clk_rate, int ns)
>  {
> -	u64 c = (u64)clk_rate * ns;
> -
> -	do_div(c, NSEC_PER_SEC);
> -
> -	return c;
> +	return DIV_ROUND_CLOSEST_ULL((u64)clk_rate * ns, NSEC_PER_SEC);
>  }
>  
>  static void pwm_omap_dmtimer_start(struct pwm_omap_dmtimer_chip *omap)
> 



From ulf.hansson at linaro.org  Wed Feb  3 02:25:23 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Wed, 3 Feb 2016 11:25:23 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFqLi8xOUeoxUTAmif5QrOjVpV_2CDLv4hjO_C9iOnv+5Q@mail.gmail.com>
References: <20160201232833.GR19432@atomide.com>
 <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>
 <20160202030533.GT19432@atomide.com>
 <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>
 <20160202163536.GU19432@atomide.com>
 <CAPDyKFosQjkHDVSvy67+hstjjFseXQP5WYXrJE19GgVFYJ099w@mail.gmail.com>
 <20160202234145.GC19432@atomide.com>
 <CAPDyKFqLi8xOUeoxUTAmif5QrOjVpV_2CDLv4hjO_C9iOnv+5Q@mail.gmail.com>
Message-ID: <CAPDyKFqSVZffQ7WNZqn9qSRibsCgG2rY26z_97agL+LhQRVGcg@mail.gmail.com>

>
> I don't see the problem, but of course you know omap for better than I do.
>
> So if you are concerned about this, perhaps adding a dev_dbg print
> when the omap hwmod's ->runtime_suspend() callback returns zero could

/s/runtime_suspend/runtime_resume

Kind regards
Uffe


From djkurtz at chromium.org  Wed Feb  3 02:37:10 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Wed, 3 Feb 2016 18:37:10 +0800
Subject: [PATCH v9 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
In-Reply-To: <1454489288-31951-2-git-send-email-jitao.shi@mediatek.com>
References: <1454489288-31951-1-git-send-email-jitao.shi@mediatek.com>
 <1454489288-31951-2-git-send-email-jitao.shi@mediatek.com>
Message-ID: <CAGS+omAZpgPhxJVBXtXDNppotdMLcSydK9=CG5TWOeAAVGRcWw@mail.gmail.com>

Hi Jitao,

Looks really good.

Just a couple of tiny things...



On Wed, Feb 3, 2016 at 4:48 PM, Jitao Shi <jitao.shi at mediatek.com> wrote:
>
> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
>
> Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> ---

[snip]

> +static int ps8640_get_modes(struct drm_connector *connector)
> +{
> +       struct ps8640 *ps_bridge = connector_to_ps8640(connector);
> +       u8 *edid;
> +       int ret, num_modes = 0;
> +       bool power_off;
> +
> +       if (ps_bridge->edid)
> +               return drm_add_edid_modes(connector, ps_bridge->edid);
> +
> +       power_off = !ps_bridge->enabled;
> +       ps8640_pre_enable(&ps_bridge->bridge);
> +
> +       edid = kmalloc(EDID_LENGTH, GFP_KERNEL);

devm_kmalloc() if you can.  Or at least kfree() in ps8640_remove


> +       if (!edid) {
> +               DRM_ERROR("Failed to allocate EDID\n");
> +               return 0;
> +       }
> +
> +       ret = ps8640_read(ps_bridge->ddc_i2c, 0, edid, EDID_LENGTH);
> +       if (ret) {
> +               kfree(edid);
> +               goto out;
> +       }
> +
> +       ps_bridge->edid = (struct edid *)edid;
> +       drm_mode_connector_update_edid_property(connector, ps_bridge->edid);
> +
> +       num_modes = drm_add_edid_modes(connector, ps_bridge->edid);
> +
> +out:
> +       if (power_off)
> +               ps8640_post_disable(&ps_bridge->bridge);
> +
> +       return num_modes;
> +}

[snip]

> +static int ps8640_spi_normal_mode(struct ps8640 *ps_bridge)
> +{
> +       u8 cmd[2];
> +       struct i2c_client *client = ps_bridge->page[2];
> +
> +       /* Enable-Write-Status-Register */
> +       cmd[0] = WRITE_ENABLE_CMD;
> +       ps8640_spi_send_cmd(ps_bridge, cmd, 1);
> +
> +       /* protect BPL/BP0/BP1 */
> +       cmd[0] = WRITE_STATUS_REG_CMD;
> +       cmd[1] = BLK_PROTECT_BITS | STATUS_REG_PROTECT;
> +       ps8640_spi_send_cmd(ps_bridge, cmd, 2);
> +
> +       /* wait for SPI rom ready */
> +       ps8640_wait_rom_idle(ps_bridge);
> +
> +       /* disable PS8640 mapping function */
> +       ps8640_write_byte(client, PAGE2_ENCTLSPI_WR, 0x00);
> +
> +       gpiod_set_value(ps_bridge->gpio_mode_sel_n, 1);
> +       return 0;
> +}
> +
> +static int ps8640_enter_bl(struct ps8640 *ps_bridge)
> +{
> +       ps_bridge->in_fw_update = true;
> +       return ps8640_spi_dl_mode(ps_bridge);


On error:
 ps_bridge->in_fw_update = false;

Thanks,
-Dan


From gregory.clement at free-electrons.com  Wed Feb  3 02:44:38 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed, 03 Feb 2016 11:44:38 +0100
Subject: [PATCH 07/10] arm64: dts: add the Marvell Armada 3700 family and
 a development board
In-Reply-To: <20160202183436.GE29778@leverpostej> (Mark Rutland's message of
 "Tue, 2 Feb 2016 18:34:36 +0000")
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-8-git-send-email-gregory.clement@free-electrons.com>
 <20160202183436.GE29778@leverpostej>
Message-ID: <877fim5azt.fsf@free-electrons.com>

Hi Mark,
 
 On mar., f?vr. 02 2016, Mark Rutland <mark.rutland at arm.com> wrote:

>> +	memory {
>> +		device_type = "memory";
>> +		/* use only 256 MB on the 512 MB available */
>> +		reg = <0x00000000 0x00000000 0x00000000 0x10000000>;
>> +	};
>
> It would be good to comment as to why we can't use 256M of the memory.

Actually the comment is wrong and the size too, we do use the 512MB.

I will fix it

Thanks,

Gregory

>
> Otherwise this looks fine.
>
> Mark.

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From ulf.hansson at linaro.org  Wed Feb  3 02:46:06 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Wed, 3 Feb 2016 11:46:06 +0100
Subject: [PATCH v4] mmc: meson: Add driver for the SD/MMC host found on
 Amlogic MesonX SoCs
In-Reply-To: <CAOQ7t2aS0yRDhM3+8wW5xrycG371uthDJy6U_oDAZip4jHRiRA@mail.gmail.com>
References: <1448988109-32630-1-git-send-email-carlo@caione.org>
 <CAPDyKFp=buvJ8Li3XC8XSUAUO7BsE+U6vEQH2xTrgcHAkdG8bQ@mail.gmail.com>
 <CAOQ7t2aJAPWd3Xmvu7n0EWL-KC8ZriM3KryfsYEh556uXhuR+g@mail.gmail.com>
 <CAPDyKFpcsKihuOiF5=RwoWrF0Jf7hRsXVSU5uV8qZf1mUsa-iQ@mail.gmail.com>
 <CAOQ7t2afXxStCsj=M-FX7eMep1gLt4jkyXDiLas_SQ1UwHc0=Q@mail.gmail.com>
 <CAPDyKFpX+_fHvv_bJUKZmSufKKnuONC582E7u3b20a+Rbbggng@mail.gmail.com>
 <CAOQ7t2aS0yRDhM3+8wW5xrycG371uthDJy6U_oDAZip4jHRiRA@mail.gmail.com>
Message-ID: <CAPDyKFo=LdzFsELZJKXj_CDcNYj96J4Q9-KqS63041d3BVUEDQ@mail.gmail.com>

On 2 February 2016 at 22:54, Carlo Caione <carlo at caione.org> wrote:
> On Tue, Feb 2, 2016 at 12:21 PM, Ulf Hansson <ulf.hansson at linaro.org> wrote:
>> On 1 February 2016 at 23:05, Carlo Caione <carlo at caione.org> wrote:
>>> On Tue, Dec 8, 2015 at 9:35 PM, Ulf Hansson <ulf.hansson at linaro.org> wrote:
>
> [cut]
>
>>> I still fail to see what the correct behaviour should be.
>>> Using the v4 of this driver with a "broken-cd" binding and a timeout
>>> of 10s my SD card takes 30s to be identified as removed after I take
>>> it out from the SD slot.
>>> Also, if I take it out and insert it again, I still have to wait 30s
>>> to be able to access it again. Is this a limitation / bug of my driver
>>> or is this the expected behaviour when we do not have a dedicated GPIO
>>> for card detection?
>>
>> It's *not* an expected a behaviour.
>>
>> Using MMC_CAP_NEEDS_POLL, means that the mmc core will send CMD13
>> commands in a polling manner to find out whether a card has been
>> removed.
>>
>> It seems like when the card is removed, the host driver doesn't get an
>> IRQ which indicates a command timeout. Instead it waits for the 10 s
>> timeout to expire.
>>
>> My question is then; why don't the driver get an IRQ for the command
>> timeout? Is that because of non-correct setup of the IRQ masks or
>> because the controller HW doesn't support this?
>
> I just verified that apparently the HW doesn't support this (no
> register for commands timeout and no IRQ generated).
> Anything wrong with implementing this in software with a timer on
> mrq->data->timeout_ns?

Huh, another broken MMC controller. :-)

In some cases there are no data in the request, it's just a command
being sent. So to deal with this issue, you will have to adjust the
timer depending on the request we send to the controller.

Is there anyway you can find out if there is a card inserted? I
understand you didn't have GPIO, but perhaps you have some internal
mechanism in the controller to for example poll a register to know
this?

Kind regards
Uffe


From jonathanh at nvidia.com  Wed Feb  3 02:51:40 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Wed, 3 Feb 2016 10:51:40 +0000
Subject: [PATCH V5 08/14] PM / Domains: Add function to remove a pm-domain
In-Reply-To: <CAPDyKFqJLdoee4a9819XukXTmYyd3pue452K_zbiV6XhfA=fTw@mail.gmail.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-9-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFqJLdoee4a9819XukXTmYyd3pue452K_zbiV6XhfA=fTw@mail.gmail.com>
Message-ID: <56B1DBBC.5020509@nvidia.com>


On 02/02/16 15:35, Ulf Hansson wrote:
> On 28 January 2016 at 17:33, Jon Hunter <jonathanh at nvidia.com> wrote:
>> The genpd framework allows users to add power-domains via the
>> pm_genpd_init() function, however, there is no corresponding function
>> to remove a power-domain. For most devices this may be fine as the power
>> domains are never removed, however, for devices that wish to populate
>> the power-domains from within a driver, having the ability to remove a
>> power domain if the probing of the device fails or the driver is unloaded
>> is necessary. Therefore, add a function to remove a power-domain. Please
>> note that the power domain can only be removed if there are no devices
>> using the power-domain and it is not linked to another domain.
>>
>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
>> ---
>>  drivers/base/power/domain.c | 26 ++++++++++++++++++++++++++
>>  include/linux/pm_domain.h   |  5 +++++
>>  2 files changed, 31 insertions(+)
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index 45e3641b427d..b4120121bcac 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -1529,6 +1529,32 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
>>  }
>>  EXPORT_SYMBOL_GPL(pm_genpd_init);
>>
>> +/**
>> + * pm_genpd_remove - Remove a generic I/O PM domain object.
>> + * @genpd: PM domain object to remove.
>> + */
>> +int pm_genpd_remove(struct generic_pm_domain *genpd)
>> +{
>> +       if (IS_ERR_OR_NULL(genpd))
>> +               return -EINVAL;
>> +
>> +       mutex_lock(&genpd->lock);
> 
> pm_genpd_summary_show() first locks the gpd_list_lock, then the genpd lock.
> 
> Please preserve that order here as well, to prevent potential deadlocks.

Ok, yes good point.

>> +
>> +       if (!list_empty(&genpd->master_links)
>> +           || !list_empty(&genpd->slave_links) || genpd->device_count) {
>> +               mutex_unlock(&genpd->lock);
>> +               return -EBUSY;
>> +       }
>> +
>> +       mutex_lock_nested(&gpd_list_lock, SINGLE_DEPTH_NESTING);
> 
> Why the nesting, can this really cause lockdep warnings?

Hmmm, yes I don't believe that is needed here as it should be a
different class. Will fix.

>> +       list_del(&genpd->gpd_list_node);
>> +       mutex_unlock(&gpd_list_lock);
>> +       mutex_unlock(&genpd->lock);
> 
> Before returning, you need to make sure there isn't a scheduled work
> for powering off the genpd.
> That might happen for example happen via genpd_poweroff_unused().
> 
> Otherwise, the caller of pm_genpd_remove() might free the memory while
> the genpd struct is still in use...
> 
> I assume a cancel_delayed_work_sync() should do the trick here.

Good point. I will address that too.

Jon


From jonathanh at nvidia.com  Wed Feb  3 03:02:24 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Wed, 3 Feb 2016 11:02:24 +0000
Subject: [PATCH V5 10/14] Documentation: DT: bindings: Add power domain
 info for NVIDIA PMC
In-Reply-To: <20160129160625.GA21918@rob-hp-laptop>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-11-git-send-email-jonathanh@nvidia.com>
 <20160129160625.GA21918@rob-hp-laptop>
Message-ID: <56B1DE40.7080403@nvidia.com>


On 29/01/16 16:06, Rob Herring wrote:
> On Thu, Jan 28, 2016 at 04:33:48PM +0000, Jon Hunter wrote:
>> Add power-domain binding documentation for the NVIDIA PMC driver in
>> order to support generic power-domains.
>>
>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
>> ---
>>  .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      | 55 ++++++++++++++++++++++
>>  1 file changed, 55 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>> index 53aa5496c5cf..3c77373aa826 100644
>> --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>> +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>> @@ -1,5 +1,7 @@
>>  NVIDIA Tegra Power Management Controller (PMC)
>>  
>> +== Power Management Controller Node ==
>> +
>>  The PMC block interacts with an external Power Management Unit. The PMC
>>  mostly controls the entry and exit of the system from different sleep
>>  modes. It provides power-gating controllers for SoC and CPU power-islands.
>> @@ -70,6 +72,10 @@ Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'
>>                       Defaults to 0. Valid values are described in section 12.5.2
>>                       "Pinmux Support" of the Tegra4 Technical Reference Manual.
>>  
>> +Optional nodes:
>> +- powergates : This node contains a hierarchy of power domain nodes, which
>> +	       should match the powergates on the Tegra SoC.
>> +
>>  Example:
>>  
>>  / SoC dts including file
>> @@ -115,3 +121,52 @@ pmc at 7000f400 {
>>  	};
>>  	...
>>  };
>> +
>> +
>> +== PM Domain Nodes ==
>> +
>> +Each of the PM domain nodes represents a power-domain on the Tegra SoC
>> +that can be power-gated by the PMC and should be named appropriately.
>> +
>> +Required properties:
>> +  - clocks: Must contain an entry for each clock required by the PMC for
>> +    controlling a power-gate. See ../clocks/clock-bindings.txt for details.
>> +  - resets: Must contain an entry for each reset required by the PMC for
>> +    controlling a power-gate. See ../reset/reset.txt for details.
>> +  - nvidia,powergate: Integer cell that contains an identifier for the PMC
>> +    power-gate that is associated with the power-domain. Please refer to
>> +    the Tegra TRM for more details.
> 
> Why not make this value be the power-domain cell for consumers and the 
> pmc be the phandle.

Is there anything wrong with using a label for the consumers? Seems
simpler, if you can just say ...

	adma: adma at 702e2000 {
		...
		power-domains = <&pd_audio>;
		...
	};

> Then use reg property for the subnodes. That avoids a custom property.

That is fine with me.

Jon


From mcoquelin.stm32 at gmail.com  Wed Feb  3 03:04:37 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Wed,  3 Feb 2016 12:04:37 +0100
Subject: [PATCH v5 1/9] ARM: Kconfig: Introduce MACH_STM32F429 flag
In-Reply-To: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
References: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
Message-ID: <1454497485-464-2-git-send-email-mcoquelin.stm32@gmail.com>

This patch introduces the MACH_STM32F429 to make possible to only select
STM32F429 pinctrl driver.

By default, all the MACH_STM32Fxxx flags will be set with STM32 defconfig.

Acked-by: Patrice Chotard <patrice.chotard at st.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
---
 arch/arm/Kconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4f799e5..ca16120 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -883,6 +883,11 @@ config ARCH_STM32
 	help
 	  Support for STMicroelectronics STM32 processors.
 
+config MACH_STM32F429
+	bool "STMicrolectronics STM32F429"
+	depends on ARCH_STM32
+	default y
+
 # Definitions to make life easier
 config ARCH_ACORN
 	bool
-- 
1.9.1



From mcoquelin.stm32 at gmail.com  Wed Feb  3 03:04:36 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Wed,  3 Feb 2016 12:04:36 +0100
Subject: [PATCH v5 0/9] Add STM32 pinctrl/GPIO driver
Message-ID: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>

Hi Linus,

This is the fifth round of STM32 pinctrl series, which is rebased on top of
v4.5-rc1 and removes no more needed dependency between DT and driver.

Also, it fixes the Makefile so that it is really built when COMPILE_TEST is
set and not ARCH_STM32.

The STM32 family has 16 pins per GPIO bank, and the number of bank varies
depending on the model.

Pins can be multiplexed either in GPIO mode, alternate function (up to 15
functions per pin) or analog (for ADC/DAC).

Changes since v4:
-----------------
 - Rebase on v4.5-rc1
 - Fix compilation breakage due to gpio_chip struct .dev field renaming
 - Move the macros from includes/dt-bindings to STM32 pinctrl driver directory
to avoid uneeded dependency between DT and driver.
 - Fix Makefile so that driver is built with COMPILE_TEST set

Changes since v3:
-----------------
 - Rebase on v4.4
 - Fix error paths in stm32_pctrl_dt_subnode_to_map() (Patrice)
 - Remove useless stm32_pctrl_find_function_by_pin function (Patrice)

Changes since v2:
-----------------
 - Rebase on v4.4-rc1
 - Declare leds also for Eval board
 - Set green led as heartbeat
 - Collect some acks

Changes since v1:
-----------------
 - Add GPIO LEDs support in DT and defconfig
 - Changes pinmux DT bindings from macros to raw values (Daniel)
 - Improve DT bindings documentation (Daniel)
 - Fix some commit fixup and rebase issues.

Kind regards,
Maxime

Maxime Coquelin (9):
  ARM: Kconfig: Introduce MACH_STM32F429 flag
  Documentation: dt-bindings: Document STM32 pinctrl driver DT bindings
  includes: dt-bindings: Add STM32F429 pinctrl DT bindings
  pinctrl: Add STM32 MCUs support
  ARM: mach-stm32: Select pinctrl
  ARM: dts: Add pinctrl node to STM32F429
  ARM: dts: Add USART1 pin config to STM32F429 boards
  ARM: dts: Add leds support to STM32F429 boards
  ARM: config: Enable GPIO Led driver in stm32_defconfig

 .../bindings/pinctrl/st,stm32-pinctrl.txt          |  126 ++
 arch/arm/Kconfig                                   |    6 +
 arch/arm/boot/dts/stm32429i-eval.dts               |   19 +
 arch/arm/boot/dts/stm32f429-disco.dts              |   13 +
 arch/arm/boot/dts/stm32f429.dtsi                   |  110 ++
 arch/arm/configs/stm32_defconfig                   |    1 +
 drivers/pinctrl/Kconfig                            |    1 +
 drivers/pinctrl/Makefile                           |    1 +
 drivers/pinctrl/stm32/Kconfig                      |   16 +
 drivers/pinctrl/stm32/Makefile                     |    5 +
 drivers/pinctrl/stm32/pinctrl-stm32.c              |  832 ++++++++++
 drivers/pinctrl/stm32/pinctrl-stm32.h              |   51 +
 drivers/pinctrl/stm32/pinctrl-stm32f429.c          | 1598 ++++++++++++++++++++
 include/dt-bindings/pinctrl/stm32f429-pinfunc.h    | 1239 +++++++++++++++
 14 files changed, 4018 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
 create mode 100644 drivers/pinctrl/stm32/Kconfig
 create mode 100644 drivers/pinctrl/stm32/Makefile
 create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.c
 create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.h
 create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32f429.c
 create mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.h

-- 
1.9.1



From mcoquelin.stm32 at gmail.com  Wed Feb  3 03:04:38 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Wed,  3 Feb 2016 12:04:38 +0100
Subject: [PATCH v5 2/9] Documentation: dt-bindings: Document STM32 pinctrl
 driver DT bindings
In-Reply-To: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
References: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
Message-ID: <1454497485-464-3-git-send-email-mcoquelin.stm32@gmail.com>

Acked-by: Patrice Chotard <patrice.chotard at st.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
---
 .../bindings/pinctrl/st,stm32-pinctrl.txt          | 126 +++++++++++++++++++++
 1 file changed, 126 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
new file mode 100644
index 0000000..7b4800c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
@@ -0,0 +1,126 @@
+* STM32 GPIO and Pin Mux/Config controller
+
+STMicroelectronics's STM32 MCUs intregrate a GPIO and Pin mux/config hardware
+controller. It controls the input/output settings on the available pins and
+also provides ability to multiplex and configure the output of various on-chip
+controllers onto these pads.
+
+Pin controller node:
+Required properies:
+ - compatible: value should be one of the following:
+   (a) "st,stm32f429-pinctrl"
+ - #address-cells: The value of this property must be 1
+ - #size-cells	: The value of this property must be 1
+ - ranges	: defines mapping between pin controller node (parent) to
+   gpio-bank node (children).
+ - pins-are-numbered: Specify the subnodes are using numbered pinmux to
+   specify pins.
+
+GPIO controller/bank node:
+Required properties:
+ - gpio-controller : Indicates this device is a GPIO controller
+ - #gpio-cells	  : Should be two.
+			The first cell is the pin number
+			The second one is the polarity:
+				- 0 for active high
+				- 1 for active low
+ - reg		  : The gpio address range, relative to the pinctrl range
+ - clocks	  : clock that drives this bank
+ - st,bank-name	  : Should be a name string for this bank as specified in
+   the datasheet
+
+Optional properties:
+ - reset:	  : Reference to the reset controller
+
+Example:
+#include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
+...
+
+	pin-controller {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "st,stm32f429-pinctrl";
+		ranges = <0 0x40020000 0x3000>;
+		pins-are-numbered;
+
+		gpioa: gpio at 40020000 {
+			gpio-controller;
+			#gpio-cells = <2>;
+			reg = <0x0 0x400>;
+			resets = <&reset_ahb1 0>;
+			st,bank-name = "GPIOA";
+		};
+		...
+		pin-functions nodes follow...
+	};
+
+Contents of function subnode node:
+----------------------------------
+Subnode format
+A pinctrl node should contain at least one subnode representing the
+pinctrl group available on the machine. Each subnode will list the
+pins it needs, and how they should be configured, with regard to muxer
+configuration, pullups, drive, output high/low and output speed.
+
+    node {
+	pinmux = <PIN_NUMBER_PINMUX>;
+	GENERIC_PINCONFIG;
+    };
+
+Required properties:
+- pinmux: integer array, represents gpio pin number and mux setting.
+  Supported pin number and mux varies for different SoCs, and are defined in
+  dt-bindings/pinctrl/<soc>-pinfunc.h directly.
+  These defines are calculated as:
+    ((port * 16 + line) << 8) | function
+  With:
+    - port: The gpio port index (PA = 0, PB = 1, ..., PK = 11)
+    - line: The line offset within the port (PA0 = 0, PA1 = 1, ..., PA15 = 15)
+    - function: The function number, can be:
+      * 0 : GPIO
+      * 1 : Alternate Function 0
+      * 2 : Alternate Function 1
+      * 3 : Alternate Function 2
+      * ...
+      * 16 : Alternate Function 15
+      * 17 : Analog
+
+Optional properties:
+- GENERIC_PINCONFIG: is the generic pinconfig options to use.
+  Available options are:
+   - bias-disable,
+   - bias-pull-down,
+   - bias-pull-up,
+   - drive-push-pull,
+   - drive-open-drain,
+   - output-low
+   - output-high
+   - slew-rate = <x>, with x being:
+       < 0 > : Low speed
+       < 1 > : Medium speed
+       < 2 > : Fast speed
+       < 3 > : High speed
+
+Example:
+
+pin-controller {
+...
+	usart1_pins_a: usart1 at 0 {
+		pins1 {
+			pinmux = <STM32F429_PA9_FUNC_USART1_TX>;
+			bias-disable;
+			drive-push-pull;
+			slew-rate = <0>;
+		};
+		pins2 {
+			pinmux = <STM32F429_PA10_FUNC_USART1_RX>;
+			bias-disable;
+		};
+	};
+};
+
+&usart1 {
+	pinctrl-0 = <&usart1_pins_a>;
+	pinctrl-names = "default";
+	status = "okay";
+};
-- 
1.9.1



From mcoquelin.stm32 at gmail.com  Wed Feb  3 03:04:41 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Wed,  3 Feb 2016 12:04:41 +0100
Subject: [PATCH v5 5/9] ARM: mach-stm32: Select pinctrl
In-Reply-To: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
References: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
Message-ID: <1454497485-464-6-git-send-email-mcoquelin.stm32@gmail.com>

Acked-by: Linus Walleij <linus.walleij at linaro.org>
Acked-by: Patrice Chotard <patrice.chotard at st.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ca16120..84b7291 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -879,6 +879,7 @@ config ARCH_STM32
 	select ARCH_HAS_RESET_CONTROLLER
 	select ARMV7M_SYSTICK
 	select CLKSRC_STM32
+	select PINCTRL
 	select RESET_CONTROLLER
 	help
 	  Support for STMicroelectronics STM32 processors.
-- 
1.9.1



From mcoquelin.stm32 at gmail.com  Wed Feb  3 03:04:42 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Wed,  3 Feb 2016 12:04:42 +0100
Subject: [PATCH v5 6/9] ARM: dts: Add pinctrl node to STM32F429
In-Reply-To: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
References: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
Message-ID: <1454497485-464-7-git-send-email-mcoquelin.stm32@gmail.com>

The STM32F429 MCU has 11 GPIO banks, with 16 pins per bank.

Acked-by: Patrice Chotard <patrice.chotard at st.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
---
 arch/arm/boot/dts/stm32f429.dtsi | 97 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 97 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 5e1e234..62d2b3d 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -46,6 +46,7 @@
  */
 
 #include "armv7-m.dtsi"
+#include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
 
 / {
 	clocks {
@@ -168,6 +169,102 @@
 			status = "disabled";
 		};
 
+		pin-controller {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "st,stm32f429-pinctrl";
+			ranges = <0 0x40020000 0x3000>;
+			pins-are-numbered;
+
+			gpioa: gpio at 40020000 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x0 0x400>;
+				clocks = <&rcc 0 256>;
+				st,bank-name = "GPIOA";
+			};
+
+			gpiob: gpio at 40020400 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x400 0x400>;
+				clocks = <&rcc 0 257>;
+				st,bank-name = "GPIOB";
+			};
+
+			gpioc: gpio at 40020800 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x800 0x400>;
+				clocks = <&rcc 0 258>;
+				st,bank-name = "GPIOC";
+			};
+
+			gpiod: gpio at 40020c00 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0xc00 0x400>;
+				clocks = <&rcc 0 259>;
+				st,bank-name = "GPIOD";
+			};
+
+			gpioe: gpio at 40021000 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x1000 0x400>;
+				clocks = <&rcc 0 260>;
+				st,bank-name = "GPIOE";
+			};
+
+			gpiof: gpio at 40021400 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x1400 0x400>;
+				clocks = <&rcc 0 261>;
+				st,bank-name = "GPIOF";
+			};
+
+			gpiog: gpio at 40021800 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x1800 0x400>;
+				clocks = <&rcc 0 262>;
+				st,bank-name = "GPIOG";
+			};
+
+			gpioh: gpio at 40021c00 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x1c00 0x400>;
+				clocks = <&rcc 0 263>;
+				st,bank-name = "GPIOH";
+			};
+
+			gpioi: gpio at 40022000 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x2000 0x400>;
+				clocks = <&rcc 0 264>;
+				st,bank-name = "GPIOI";
+			};
+
+			gpioj: gpio at 40022400 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x2400 0x400>;
+				clocks = <&rcc 0 265>;
+				st,bank-name = "GPIOJ";
+			};
+
+			gpiok: gpio at 40022800 {
+				gpio-controller;
+				#gpio-cells = <2>;
+				reg = <0x2800 0x400>;
+				clocks = <&rcc 0 266>;
+				st,bank-name = "GPIOK";
+			};
+		};
+
 		rcc: rcc at 40023810 {
 			#clock-cells = <2>;
 			compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
-- 
1.9.1



From mcoquelin.stm32 at gmail.com  Wed Feb  3 03:04:44 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Wed,  3 Feb 2016 12:04:44 +0100
Subject: [PATCH v5 8/9] ARM: dts: Add leds support to STM32F429 boards
In-Reply-To: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
References: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
Message-ID: <1454497485-464-9-git-send-email-mcoquelin.stm32@gmail.com>

Acked-by: Patrice Chotard <patrice.chotard at st.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
---
 arch/arm/boot/dts/stm32429i-eval.dts  | 17 +++++++++++++++++
 arch/arm/boot/dts/stm32f429-disco.dts | 11 +++++++++++
 2 files changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
index 71fe17a..e3921d9 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -64,6 +64,23 @@
 	aliases {
 		serial0 = &usart1;
 	};
+
+	leds {
+		compatible = "gpio-leds";
+		green {
+			gpios = <&gpiog 6 1>;
+			linux,default-trigger = "heartbeat";
+		};
+		orange {
+			gpios = <&gpiog 7 1>;
+		};
+		red {
+			gpios = <&gpiog 10 1>;
+		};
+		blue {
+			gpios = <&gpiog 12 1>;
+		};
+	};
 };
 
 &clk_hse {
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
index e3ce796..0140807 100644
--- a/arch/arm/boot/dts/stm32f429-disco.dts
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -64,6 +64,17 @@
 	aliases {
 		serial0 = &usart1;
 	};
+
+	leds {
+		compatible = "gpio-leds";
+		red {
+			gpios = <&gpiog 14 0>;
+		};
+		green {
+			gpios = <&gpiog 13 0>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
 };
 
 &clk_hse {
-- 
1.9.1



From mcoquelin.stm32 at gmail.com  Wed Feb  3 03:04:45 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Wed,  3 Feb 2016 12:04:45 +0100
Subject: [PATCH v5 9/9] ARM: config: Enable GPIO Led driver in stm32_defconfig
In-Reply-To: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
References: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
Message-ID: <1454497485-464-10-git-send-email-mcoquelin.stm32@gmail.com>

Acked-by: Linus Walleij <linus.walleij at linaro.org>
Acked-by: Patrice Chotard <patrice.chotard at st.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
---
 arch/arm/configs/stm32_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index ec52505..1e5ec2a 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -52,6 +52,7 @@ CONFIG_SERIAL_STM32_CONSOLE=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
 CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_DMADEVICES=y
-- 
1.9.1



From mcoquelin.stm32 at gmail.com  Wed Feb  3 03:04:43 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Wed,  3 Feb 2016 12:04:43 +0100
Subject: [PATCH v5 7/9] ARM: dts: Add USART1 pin config to STM32F429 boards
In-Reply-To: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
References: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
Message-ID: <1454497485-464-8-git-send-email-mcoquelin.stm32@gmail.com>

This patch selects USART1 pin configuration on PA9/PA10 pins
for both Eval and Disco boards.

Acked-by: Linus Walleij <linus.walleij at linaro.org>
Acked-by: Patrice Chotard <patrice.chotard at st.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
---
 arch/arm/boot/dts/stm32429i-eval.dts  |  2 ++
 arch/arm/boot/dts/stm32f429-disco.dts |  2 ++
 arch/arm/boot/dts/stm32f429.dtsi      | 13 +++++++++++++
 3 files changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
index 6964fc9..71fe17a 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -71,5 +71,7 @@
 };
 
 &usart1 {
+	pinctrl-0 = <&usart1_pins_a>;
+	pinctrl-names = "default";
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
index f0b731d..e3ce796 100644
--- a/arch/arm/boot/dts/stm32f429-disco.dts
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -71,5 +71,7 @@
 };
 
 &usart1 {
+	pinctrl-0 = <&usart1_pins_a>;
+	pinctrl-names = "default";
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 62d2b3d..1cf713e 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -263,6 +263,19 @@
 				clocks = <&rcc 0 266>;
 				st,bank-name = "GPIOK";
 			};
+
+			usart1_pins_a: usart1 at 0 {
+				pins1 {
+					pinmux = <STM32F429_PA9_FUNC_USART1_TX>;
+					bias-disable;
+					drive-push-pull;
+					slew-rate = <0>;
+				};
+				pins2 {
+					pinmux = <STM32F429_PA10_FUNC_USART1_RX>;
+					bias-disable;
+				};
+			};
 		};
 
 		rcc: rcc at 40023810 {
-- 
1.9.1



From mcoquelin.stm32 at gmail.com  Wed Feb  3 03:04:39 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Wed,  3 Feb 2016 12:04:39 +0100
Subject: [PATCH v5 3/9] includes: dt-bindings: Add STM32F429 pinctrl DT
 bindings
In-Reply-To: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
References: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
Message-ID: <1454497485-464-4-git-send-email-mcoquelin.stm32@gmail.com>

Acked-by: Patrice Chotard <patrice.chotard at st.com>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
---
 include/dt-bindings/pinctrl/stm32f429-pinfunc.h | 1239 +++++++++++++++++++++++
 1 file changed, 1239 insertions(+)
 create mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.h

diff --git a/include/dt-bindings/pinctrl/stm32f429-pinfunc.h b/include/dt-bindings/pinctrl/stm32f429-pinfunc.h
new file mode 100644
index 0000000..26f1879
--- /dev/null
+++ b/include/dt-bindings/pinctrl/stm32f429-pinfunc.h
@@ -0,0 +1,1239 @@
+#ifndef _DT_BINDINGS_STM32F429_PINFUNC_H
+#define _DT_BINDINGS_STM32F429_PINFUNC_H
+
+#define STM32F429_PA0_FUNC_GPIO 0x0
+#define STM32F429_PA0_FUNC_TIM2_CH1_TIM2_ETR 0x2
+#define STM32F429_PA0_FUNC_TIM5_CH1 0x3
+#define STM32F429_PA0_FUNC_TIM8_ETR 0x4
+#define STM32F429_PA0_FUNC_USART2_CTS 0x8
+#define STM32F429_PA0_FUNC_UART4_TX 0x9
+#define STM32F429_PA0_FUNC_ETH_MII_CRS 0xc
+#define STM32F429_PA0_FUNC_EVENTOUT 0x10
+#define STM32F429_PA0_FUNC_ANALOG 0x11
+
+#define STM32F429_PA1_FUNC_GPIO 0x100
+#define STM32F429_PA1_FUNC_TIM2_CH2 0x102
+#define STM32F429_PA1_FUNC_TIM5_CH2 0x103
+#define STM32F429_PA1_FUNC_USART2_RTS 0x108
+#define STM32F429_PA1_FUNC_UART4_RX 0x109
+#define STM32F429_PA1_FUNC_ETH_MII_RX_CLK_ETH_RMII_REF_CLK 0x10c
+#define STM32F429_PA1_FUNC_EVENTOUT 0x110
+#define STM32F429_PA1_FUNC_ANALOG 0x111
+
+#define STM32F429_PA2_FUNC_GPIO 0x200
+#define STM32F429_PA2_FUNC_TIM2_CH3 0x202
+#define STM32F429_PA2_FUNC_TIM5_CH3 0x203
+#define STM32F429_PA2_FUNC_TIM9_CH1 0x204
+#define STM32F429_PA2_FUNC_USART2_TX 0x208
+#define STM32F429_PA2_FUNC_ETH_MDIO 0x20c
+#define STM32F429_PA2_FUNC_EVENTOUT 0x210
+#define STM32F429_PA2_FUNC_ANALOG 0x211
+
+#define STM32F429_PA3_FUNC_GPIO 0x300
+#define STM32F429_PA3_FUNC_TIM2_CH4 0x302
+#define STM32F429_PA3_FUNC_TIM5_CH4 0x303
+#define STM32F429_PA3_FUNC_TIM9_CH2 0x304
+#define STM32F429_PA3_FUNC_USART2_RX 0x308
+#define STM32F429_PA3_FUNC_OTG_HS_ULPI_D0 0x30b
+#define STM32F429_PA3_FUNC_ETH_MII_COL 0x30c
+#define STM32F429_PA3_FUNC_LCD_B5 0x30f
+#define STM32F429_PA3_FUNC_EVENTOUT 0x310
+#define STM32F429_PA3_FUNC_ANALOG 0x311
+
+#define STM32F429_PA4_FUNC_GPIO 0x400
+#define STM32F429_PA4_FUNC_SPI1_NSS 0x406
+#define STM32F429_PA4_FUNC_SPI3_NSS_I2S3_WS 0x407
+#define STM32F429_PA4_FUNC_USART2_CK 0x408
+#define STM32F429_PA4_FUNC_OTG_HS_SOF 0x40d
+#define STM32F429_PA4_FUNC_DCMI_HSYNC 0x40e
+#define STM32F429_PA4_FUNC_LCD_VSYNC 0x40f
+#define STM32F429_PA4_FUNC_EVENTOUT 0x410
+#define STM32F429_PA4_FUNC_ANALOG 0x411
+
+#define STM32F429_PA5_FUNC_GPIO 0x500
+#define STM32F429_PA5_FUNC_TIM2_CH1_TIM2_ETR 0x502
+#define STM32F429_PA5_FUNC_TIM8_CH1N 0x504
+#define STM32F429_PA5_FUNC_SPI1_SCK 0x506
+#define STM32F429_PA5_FUNC_OTG_HS_ULPI_CK 0x50b
+#define STM32F429_PA5_FUNC_EVENTOUT 0x510
+#define STM32F429_PA5_FUNC_ANALOG 0x511
+
+#define STM32F429_PA6_FUNC_GPIO 0x600
+#define STM32F429_PA6_FUNC_TIM1_BKIN 0x602
+#define STM32F429_PA6_FUNC_TIM3_CH1 0x603
+#define STM32F429_PA6_FUNC_TIM8_BKIN 0x604
+#define STM32F429_PA6_FUNC_SPI1_MISO 0x606
+#define STM32F429_PA6_FUNC_TIM13_CH1 0x60a
+#define STM32F429_PA6_FUNC_DCMI_PIXCLK 0x60e
+#define STM32F429_PA6_FUNC_LCD_G2 0x60f
+#define STM32F429_PA6_FUNC_EVENTOUT 0x610
+#define STM32F429_PA6_FUNC_ANALOG 0x611
+
+#define STM32F429_PA7_FUNC_GPIO 0x700
+#define STM32F429_PA7_FUNC_TIM1_CH1N 0x702
+#define STM32F429_PA7_FUNC_TIM3_CH2 0x703
+#define STM32F429_PA7_FUNC_TIM8_CH1N 0x704
+#define STM32F429_PA7_FUNC_SPI1_MOSI 0x706
+#define STM32F429_PA7_FUNC_TIM14_CH1 0x70a
+#define STM32F429_PA7_FUNC_ETH_MII_RX_DV_ETH_RMII_CRS_DV 0x70c
+#define STM32F429_PA7_FUNC_EVENTOUT 0x710
+#define STM32F429_PA7_FUNC_ANALOG 0x711
+
+#define STM32F429_PA8_FUNC_GPIO 0x800
+#define STM32F429_PA8_FUNC_MCO1 0x801
+#define STM32F429_PA8_FUNC_TIM1_CH1 0x802
+#define STM32F429_PA8_FUNC_I2C3_SCL 0x805
+#define STM32F429_PA8_FUNC_USART1_CK 0x808
+#define STM32F429_PA8_FUNC_OTG_FS_SOF 0x80b
+#define STM32F429_PA8_FUNC_LCD_R6 0x80f
+#define STM32F429_PA8_FUNC_EVENTOUT 0x810
+#define STM32F429_PA8_FUNC_ANALOG 0x811
+
+#define STM32F429_PA9_FUNC_GPIO 0x900
+#define STM32F429_PA9_FUNC_TIM1_CH2 0x902
+#define STM32F429_PA9_FUNC_I2C3_SMBA 0x905
+#define STM32F429_PA9_FUNC_USART1_TX 0x908
+#define STM32F429_PA9_FUNC_DCMI_D0 0x90e
+#define STM32F429_PA9_FUNC_EVENTOUT 0x910
+#define STM32F429_PA9_FUNC_ANALOG 0x911
+
+#define STM32F429_PA10_FUNC_GPIO 0xa00
+#define STM32F429_PA10_FUNC_TIM1_CH3 0xa02
+#define STM32F429_PA10_FUNC_USART1_RX 0xa08
+#define STM32F429_PA10_FUNC_OTG_FS_ID 0xa0b
+#define STM32F429_PA10_FUNC_DCMI_D1 0xa0e
+#define STM32F429_PA10_FUNC_EVENTOUT 0xa10
+#define STM32F429_PA10_FUNC_ANALOG 0xa11
+
+#define STM32F429_PA11_FUNC_GPIO 0xb00
+#define STM32F429_PA11_FUNC_TIM1_CH4 0xb02
+#define STM32F429_PA11_FUNC_USART1_CTS 0xb08
+#define STM32F429_PA11_FUNC_CAN1_RX 0xb0a
+#define STM32F429_PA11_FUNC_OTG_FS_DM 0xb0b
+#define STM32F429_PA11_FUNC_LCD_R4 0xb0f
+#define STM32F429_PA11_FUNC_EVENTOUT 0xb10
+#define STM32F429_PA11_FUNC_ANALOG 0xb11
+
+#define STM32F429_PA12_FUNC_GPIO 0xc00
+#define STM32F429_PA12_FUNC_TIM1_ETR 0xc02
+#define STM32F429_PA12_FUNC_USART1_RTS 0xc08
+#define STM32F429_PA12_FUNC_CAN1_TX 0xc0a
+#define STM32F429_PA12_FUNC_OTG_FS_DP 0xc0b
+#define STM32F429_PA12_FUNC_LCD_R5 0xc0f
+#define STM32F429_PA12_FUNC_EVENTOUT 0xc10
+#define STM32F429_PA12_FUNC_ANALOG 0xc11
+
+#define STM32F429_PA13_FUNC_GPIO 0xd00
+#define STM32F429_PA13_FUNC_JTMS_SWDIO 0xd01
+#define STM32F429_PA13_FUNC_EVENTOUT 0xd10
+#define STM32F429_PA13_FUNC_ANALOG 0xd11
+
+#define STM32F429_PA14_FUNC_GPIO 0xe00
+#define STM32F429_PA14_FUNC_JTCK_SWCLK 0xe01
+#define STM32F429_PA14_FUNC_EVENTOUT 0xe10
+#define STM32F429_PA14_FUNC_ANALOG 0xe11
+
+#define STM32F429_PA15_FUNC_GPIO 0xf00
+#define STM32F429_PA15_FUNC_JTDI 0xf01
+#define STM32F429_PA15_FUNC_TIM2_CH1_TIM2_ETR 0xf02
+#define STM32F429_PA15_FUNC_SPI1_NSS 0xf06
+#define STM32F429_PA15_FUNC_SPI3_NSS_I2S3_WS 0xf07
+#define STM32F429_PA15_FUNC_EVENTOUT 0xf10
+#define STM32F429_PA15_FUNC_ANALOG 0xf11
+
+
+
+#define STM32F429_PB0_FUNC_GPIO 0x1000
+#define STM32F429_PB0_FUNC_TIM1_CH2N 0x1002
+#define STM32F429_PB0_FUNC_TIM3_CH3 0x1003
+#define STM32F429_PB0_FUNC_TIM8_CH2N 0x1004
+#define STM32F429_PB0_FUNC_LCD_R3 0x100a
+#define STM32F429_PB0_FUNC_OTG_HS_ULPI_D1 0x100b
+#define STM32F429_PB0_FUNC_ETH_MII_RXD2 0x100c
+#define STM32F429_PB0_FUNC_EVENTOUT 0x1010
+#define STM32F429_PB0_FUNC_ANALOG 0x1011
+
+#define STM32F429_PB1_FUNC_GPIO 0x1100
+#define STM32F429_PB1_FUNC_TIM1_CH3N 0x1102
+#define STM32F429_PB1_FUNC_TIM3_CH4 0x1103
+#define STM32F429_PB1_FUNC_TIM8_CH3N 0x1104
+#define STM32F429_PB1_FUNC_LCD_R6 0x110a
+#define STM32F429_PB1_FUNC_OTG_HS_ULPI_D2 0x110b
+#define STM32F429_PB1_FUNC_ETH_MII_RXD3 0x110c
+#define STM32F429_PB1_FUNC_EVENTOUT 0x1110
+#define STM32F429_PB1_FUNC_ANALOG 0x1111
+
+#define STM32F429_PB2_FUNC_GPIO 0x1200
+#define STM32F429_PB2_FUNC_EVENTOUT 0x1210
+#define STM32F429_PB2_FUNC_ANALOG 0x1211
+
+#define STM32F429_PB3_FUNC_GPIO 0x1300
+#define STM32F429_PB3_FUNC_JTDO_TRACESWO 0x1301
+#define STM32F429_PB3_FUNC_TIM2_CH2 0x1302
+#define STM32F429_PB3_FUNC_SPI1_SCK 0x1306
+#define STM32F429_PB3_FUNC_SPI3_SCK_I2S3_CK 0x1307
+#define STM32F429_PB3_FUNC_EVENTOUT 0x1310
+#define STM32F429_PB3_FUNC_ANALOG 0x1311
+
+#define STM32F429_PB4_FUNC_GPIO 0x1400
+#define STM32F429_PB4_FUNC_NJTRST 0x1401
+#define STM32F429_PB4_FUNC_TIM3_CH1 0x1403
+#define STM32F429_PB4_FUNC_SPI1_MISO 0x1406
+#define STM32F429_PB4_FUNC_SPI3_MISO 0x1407
+#define STM32F429_PB4_FUNC_I2S3EXT_SD 0x1408
+#define STM32F429_PB4_FUNC_EVENTOUT 0x1410
+#define STM32F429_PB4_FUNC_ANALOG 0x1411
+
+#define STM32F429_PB5_FUNC_GPIO 0x1500
+#define STM32F429_PB5_FUNC_TIM3_CH2 0x1503
+#define STM32F429_PB5_FUNC_I2C1_SMBA 0x1505
+#define STM32F429_PB5_FUNC_SPI1_MOSI 0x1506
+#define STM32F429_PB5_FUNC_SPI3_MOSI_I2S3_SD 0x1507
+#define STM32F429_PB5_FUNC_CAN2_RX 0x150a
+#define STM32F429_PB5_FUNC_OTG_HS_ULPI_D7 0x150b
+#define STM32F429_PB5_FUNC_ETH_PPS_OUT 0x150c
+#define STM32F429_PB5_FUNC_FMC_SDCKE1 0x150d
+#define STM32F429_PB5_FUNC_DCMI_D10 0x150e
+#define STM32F429_PB5_FUNC_EVENTOUT 0x1510
+#define STM32F429_PB5_FUNC_ANALOG 0x1511
+
+#define STM32F429_PB6_FUNC_GPIO 0x1600
+#define STM32F429_PB6_FUNC_TIM4_CH1 0x1603
+#define STM32F429_PB6_FUNC_I2C1_SCL 0x1605
+#define STM32F429_PB6_FUNC_USART1_TX 0x1608
+#define STM32F429_PB6_FUNC_CAN2_TX 0x160a
+#define STM32F429_PB6_FUNC_FMC_SDNE1 0x160d
+#define STM32F429_PB6_FUNC_DCMI_D5 0x160e
+#define STM32F429_PB6_FUNC_EVENTOUT 0x1610
+#define STM32F429_PB6_FUNC_ANALOG 0x1611
+
+#define STM32F429_PB7_FUNC_GPIO 0x1700
+#define STM32F429_PB7_FUNC_TIM4_CH2 0x1703
+#define STM32F429_PB7_FUNC_I2C1_SDA 0x1705
+#define STM32F429_PB7_FUNC_USART1_RX 0x1708
+#define STM32F429_PB7_FUNC_FMC_NL 0x170d
+#define STM32F429_PB7_FUNC_DCMI_VSYNC 0x170e
+#define STM32F429_PB7_FUNC_EVENTOUT 0x1710
+#define STM32F429_PB7_FUNC_ANALOG 0x1711
+
+#define STM32F429_PB8_FUNC_GPIO 0x1800
+#define STM32F429_PB8_FUNC_TIM4_CH3 0x1803
+#define STM32F429_PB8_FUNC_TIM10_CH1 0x1804
+#define STM32F429_PB8_FUNC_I2C1_SCL 0x1805
+#define STM32F429_PB8_FUNC_CAN1_RX 0x180a
+#define STM32F429_PB8_FUNC_ETH_MII_TXD3 0x180c
+#define STM32F429_PB8_FUNC_SDIO_D4 0x180d
+#define STM32F429_PB8_FUNC_DCMI_D6 0x180e
+#define STM32F429_PB8_FUNC_LCD_B6 0x180f
+#define STM32F429_PB8_FUNC_EVENTOUT 0x1810
+#define STM32F429_PB8_FUNC_ANALOG 0x1811
+
+#define STM32F429_PB9_FUNC_GPIO 0x1900
+#define STM32F429_PB9_FUNC_TIM4_CH4 0x1903
+#define STM32F429_PB9_FUNC_TIM11_CH1 0x1904
+#define STM32F429_PB9_FUNC_I2C1_SDA 0x1905
+#define STM32F429_PB9_FUNC_SPI2_NSS_I2S2_WS 0x1906
+#define STM32F429_PB9_FUNC_CAN1_TX 0x190a
+#define STM32F429_PB9_FUNC_SDIO_D5 0x190d
+#define STM32F429_PB9_FUNC_DCMI_D7 0x190e
+#define STM32F429_PB9_FUNC_LCD_B7 0x190f
+#define STM32F429_PB9_FUNC_EVENTOUT 0x1910
+#define STM32F429_PB9_FUNC_ANALOG 0x1911
+
+#define STM32F429_PB10_FUNC_GPIO 0x1a00
+#define STM32F429_PB10_FUNC_TIM2_CH3 0x1a02
+#define STM32F429_PB10_FUNC_I2C2_SCL 0x1a05
+#define STM32F429_PB10_FUNC_SPI2_SCK_I2S2_CK 0x1a06
+#define STM32F429_PB10_FUNC_USART3_TX 0x1a08
+#define STM32F429_PB10_FUNC_OTG_HS_ULPI_D3 0x1a0b
+#define STM32F429_PB10_FUNC_ETH_MII_RX_ER 0x1a0c
+#define STM32F429_PB10_FUNC_LCD_G4 0x1a0f
+#define STM32F429_PB10_FUNC_EVENTOUT 0x1a10
+#define STM32F429_PB10_FUNC_ANALOG 0x1a11
+
+#define STM32F429_PB11_FUNC_GPIO 0x1b00
+#define STM32F429_PB11_FUNC_TIM2_CH4 0x1b02
+#define STM32F429_PB11_FUNC_I2C2_SDA 0x1b05
+#define STM32F429_PB11_FUNC_USART3_RX 0x1b08
+#define STM32F429_PB11_FUNC_OTG_HS_ULPI_D4 0x1b0b
+#define STM32F429_PB11_FUNC_ETH_MII_TX_EN_ETH_RMII_TX_EN 0x1b0c
+#define STM32F429_PB11_FUNC_LCD_G5 0x1b0f
+#define STM32F429_PB11_FUNC_EVENTOUT 0x1b10
+#define STM32F429_PB11_FUNC_ANALOG 0x1b11
+
+#define STM32F429_PB12_FUNC_GPIO 0x1c00
+#define STM32F429_PB12_FUNC_TIM1_BKIN 0x1c02
+#define STM32F429_PB12_FUNC_I2C2_SMBA 0x1c05
+#define STM32F429_PB12_FUNC_SPI2_NSS_I2S2_WS 0x1c06
+#define STM32F429_PB12_FUNC_USART3_CK 0x1c08
+#define STM32F429_PB12_FUNC_CAN2_RX 0x1c0a
+#define STM32F429_PB12_FUNC_OTG_HS_ULPI_D5 0x1c0b
+#define STM32F429_PB12_FUNC_ETH_MII_TXD0_ETH_RMII_TXD0 0x1c0c
+#define STM32F429_PB12_FUNC_OTG_HS_ID 0x1c0d
+#define STM32F429_PB12_FUNC_EVENTOUT 0x1c10
+#define STM32F429_PB12_FUNC_ANALOG 0x1c11
+
+#define STM32F429_PB13_FUNC_GPIO 0x1d00
+#define STM32F429_PB13_FUNC_TIM1_CH1N 0x1d02
+#define STM32F429_PB13_FUNC_SPI2_SCK_I2S2_CK 0x1d06
+#define STM32F429_PB13_FUNC_USART3_CTS 0x1d08
+#define STM32F429_PB13_FUNC_CAN2_TX 0x1d0a
+#define STM32F429_PB13_FUNC_OTG_HS_ULPI_D6 0x1d0b
+#define STM32F429_PB13_FUNC_ETH_MII_TXD1_ETH_RMII_TXD1 0x1d0c
+#define STM32F429_PB13_FUNC_EVENTOUT 0x1d10
+#define STM32F429_PB13_FUNC_ANALOG 0x1d11
+
+#define STM32F429_PB14_FUNC_GPIO 0x1e00
+#define STM32F429_PB14_FUNC_TIM1_CH2N 0x1e02
+#define STM32F429_PB14_FUNC_TIM8_CH2N 0x1e04
+#define STM32F429_PB14_FUNC_SPI2_MISO 0x1e06
+#define STM32F429_PB14_FUNC_I2S2EXT_SD 0x1e07
+#define STM32F429_PB14_FUNC_USART3_RTS 0x1e08
+#define STM32F429_PB14_FUNC_TIM12_CH1 0x1e0a
+#define STM32F429_PB14_FUNC_OTG_HS_DM 0x1e0d
+#define STM32F429_PB14_FUNC_EVENTOUT 0x1e10
+#define STM32F429_PB14_FUNC_ANALOG 0x1e11
+
+#define STM32F429_PB15_FUNC_GPIO 0x1f00
+#define STM32F429_PB15_FUNC_RTC_REFIN 0x1f01
+#define STM32F429_PB15_FUNC_TIM1_CH3N 0x1f02
+#define STM32F429_PB15_FUNC_TIM8_CH3N 0x1f04
+#define STM32F429_PB15_FUNC_SPI2_MOSI_I2S2_SD 0x1f06
+#define STM32F429_PB15_FUNC_TIM12_CH2 0x1f0a
+#define STM32F429_PB15_FUNC_OTG_HS_DP 0x1f0d
+#define STM32F429_PB15_FUNC_EVENTOUT 0x1f10
+#define STM32F429_PB15_FUNC_ANALOG 0x1f11
+
+
+
+#define STM32F429_PC0_FUNC_GPIO 0x2000
+#define STM32F429_PC0_FUNC_OTG_HS_ULPI_STP 0x200b
+#define STM32F429_PC0_FUNC_FMC_SDNWE 0x200d
+#define STM32F429_PC0_FUNC_EVENTOUT 0x2010
+#define STM32F429_PC0_FUNC_ANALOG 0x2011
+
+#define STM32F429_PC1_FUNC_GPIO 0x2100
+#define STM32F429_PC1_FUNC_ETH_MDC 0x210c
+#define STM32F429_PC1_FUNC_EVENTOUT 0x2110
+#define STM32F429_PC1_FUNC_ANALOG 0x2111
+
+#define STM32F429_PC2_FUNC_GPIO 0x2200
+#define STM32F429_PC2_FUNC_SPI2_MISO 0x2206
+#define STM32F429_PC2_FUNC_I2S2EXT_SD 0x2207
+#define STM32F429_PC2_FUNC_OTG_HS_ULPI_DIR 0x220b
+#define STM32F429_PC2_FUNC_ETH_MII_TXD2 0x220c
+#define STM32F429_PC2_FUNC_FMC_SDNE0 0x220d
+#define STM32F429_PC2_FUNC_EVENTOUT 0x2210
+#define STM32F429_PC2_FUNC_ANALOG 0x2211
+
+#define STM32F429_PC3_FUNC_GPIO 0x2300
+#define STM32F429_PC3_FUNC_SPI2_MOSI_I2S2_SD 0x2306
+#define STM32F429_PC3_FUNC_OTG_HS_ULPI_NXT 0x230b
+#define STM32F429_PC3_FUNC_ETH_MII_TX_CLK 0x230c
+#define STM32F429_PC3_FUNC_FMC_SDCKE0 0x230d
+#define STM32F429_PC3_FUNC_EVENTOUT 0x2310
+#define STM32F429_PC3_FUNC_ANALOG 0x2311
+
+#define STM32F429_PC4_FUNC_GPIO 0x2400
+#define STM32F429_PC4_FUNC_ETH_MII_RXD0_ETH_RMII_RXD0 0x240c
+#define STM32F429_PC4_FUNC_EVENTOUT 0x2410
+#define STM32F429_PC4_FUNC_ANALOG 0x2411
+
+#define STM32F429_PC5_FUNC_GPIO 0x2500
+#define STM32F429_PC5_FUNC_ETH_MII_RXD1_ETH_RMII_RXD1 0x250c
+#define STM32F429_PC5_FUNC_EVENTOUT 0x2510
+#define STM32F429_PC5_FUNC_ANALOG 0x2511
+
+#define STM32F429_PC6_FUNC_GPIO 0x2600
+#define STM32F429_PC6_FUNC_TIM3_CH1 0x2603
+#define STM32F429_PC6_FUNC_TIM8_CH1 0x2604
+#define STM32F429_PC6_FUNC_I2S2_MCK 0x2606
+#define STM32F429_PC6_FUNC_USART6_TX 0x2609
+#define STM32F429_PC6_FUNC_SDIO_D6 0x260d
+#define STM32F429_PC6_FUNC_DCMI_D0 0x260e
+#define STM32F429_PC6_FUNC_LCD_HSYNC 0x260f
+#define STM32F429_PC6_FUNC_EVENTOUT 0x2610
+#define STM32F429_PC6_FUNC_ANALOG 0x2611
+
+#define STM32F429_PC7_FUNC_GPIO 0x2700
+#define STM32F429_PC7_FUNC_TIM3_CH2 0x2703
+#define STM32F429_PC7_FUNC_TIM8_CH2 0x2704
+#define STM32F429_PC7_FUNC_I2S3_MCK 0x2707
+#define STM32F429_PC7_FUNC_USART6_RX 0x2709
+#define STM32F429_PC7_FUNC_SDIO_D7 0x270d
+#define STM32F429_PC7_FUNC_DCMI_D1 0x270e
+#define STM32F429_PC7_FUNC_LCD_G6 0x270f
+#define STM32F429_PC7_FUNC_EVENTOUT 0x2710
+#define STM32F429_PC7_FUNC_ANALOG 0x2711
+
+#define STM32F429_PC8_FUNC_GPIO 0x2800
+#define STM32F429_PC8_FUNC_TIM3_CH3 0x2803
+#define STM32F429_PC8_FUNC_TIM8_CH3 0x2804
+#define STM32F429_PC8_FUNC_USART6_CK 0x2809
+#define STM32F429_PC8_FUNC_SDIO_D0 0x280d
+#define STM32F429_PC8_FUNC_DCMI_D2 0x280e
+#define STM32F429_PC8_FUNC_EVENTOUT 0x2810
+#define STM32F429_PC8_FUNC_ANALOG 0x2811
+
+#define STM32F429_PC9_FUNC_GPIO 0x2900
+#define STM32F429_PC9_FUNC_MCO2 0x2901
+#define STM32F429_PC9_FUNC_TIM3_CH4 0x2903
+#define STM32F429_PC9_FUNC_TIM8_CH4 0x2904
+#define STM32F429_PC9_FUNC_I2C3_SDA 0x2905
+#define STM32F429_PC9_FUNC_I2S_CKIN 0x2906
+#define STM32F429_PC9_FUNC_SDIO_D1 0x290d
+#define STM32F429_PC9_FUNC_DCMI_D3 0x290e
+#define STM32F429_PC9_FUNC_EVENTOUT 0x2910
+#define STM32F429_PC9_FUNC_ANALOG 0x2911
+
+#define STM32F429_PC10_FUNC_GPIO 0x2a00
+#define STM32F429_PC10_FUNC_SPI3_SCK_I2S3_CK 0x2a07
+#define STM32F429_PC10_FUNC_USART3_TX 0x2a08
+#define STM32F429_PC10_FUNC_UART4_TX 0x2a09
+#define STM32F429_PC10_FUNC_SDIO_D2 0x2a0d
+#define STM32F429_PC10_FUNC_DCMI_D8 0x2a0e
+#define STM32F429_PC10_FUNC_LCD_R2 0x2a0f
+#define STM32F429_PC10_FUNC_EVENTOUT 0x2a10
+#define STM32F429_PC10_FUNC_ANALOG 0x2a11
+
+#define STM32F429_PC11_FUNC_GPIO 0x2b00
+#define STM32F429_PC11_FUNC_I2S3EXT_SD 0x2b06
+#define STM32F429_PC11_FUNC_SPI3_MISO 0x2b07
+#define STM32F429_PC11_FUNC_USART3_RX 0x2b08
+#define STM32F429_PC11_FUNC_UART4_RX 0x2b09
+#define STM32F429_PC11_FUNC_SDIO_D3 0x2b0d
+#define STM32F429_PC11_FUNC_DCMI_D4 0x2b0e
+#define STM32F429_PC11_FUNC_EVENTOUT 0x2b10
+#define STM32F429_PC11_FUNC_ANALOG 0x2b11
+
+#define STM32F429_PC12_FUNC_GPIO 0x2c00
+#define STM32F429_PC12_FUNC_SPI3_MOSI_I2S3_SD 0x2c07
+#define STM32F429_PC12_FUNC_USART3_CK 0x2c08
+#define STM32F429_PC12_FUNC_UART5_TX 0x2c09
+#define STM32F429_PC12_FUNC_SDIO_CK 0x2c0d
+#define STM32F429_PC12_FUNC_DCMI_D9 0x2c0e
+#define STM32F429_PC12_FUNC_EVENTOUT 0x2c10
+#define STM32F429_PC12_FUNC_ANALOG 0x2c11
+
+#define STM32F429_PC13_FUNC_GPIO 0x2d00
+#define STM32F429_PC13_FUNC_EVENTOUT 0x2d10
+#define STM32F429_PC13_FUNC_ANALOG 0x2d11
+
+#define STM32F429_PC14_FUNC_GPIO 0x2e00
+#define STM32F429_PC14_FUNC_EVENTOUT 0x2e10
+#define STM32F429_PC14_FUNC_ANALOG 0x2e11
+
+#define STM32F429_PC15_FUNC_GPIO 0x2f00
+#define STM32F429_PC15_FUNC_EVENTOUT 0x2f10
+#define STM32F429_PC15_FUNC_ANALOG 0x2f11
+
+
+
+#define STM32F429_PD0_FUNC_GPIO 0x3000
+#define STM32F429_PD0_FUNC_CAN1_RX 0x300a
+#define STM32F429_PD0_FUNC_FMC_D2 0x300d
+#define STM32F429_PD0_FUNC_EVENTOUT 0x3010
+#define STM32F429_PD0_FUNC_ANALOG 0x3011
+
+#define STM32F429_PD1_FUNC_GPIO 0x3100
+#define STM32F429_PD1_FUNC_CAN1_TX 0x310a
+#define STM32F429_PD1_FUNC_FMC_D3 0x310d
+#define STM32F429_PD1_FUNC_EVENTOUT 0x3110
+#define STM32F429_PD1_FUNC_ANALOG 0x3111
+
+#define STM32F429_PD2_FUNC_GPIO 0x3200
+#define STM32F429_PD2_FUNC_TIM3_ETR 0x3203
+#define STM32F429_PD2_FUNC_UART5_RX 0x3209
+#define STM32F429_PD2_FUNC_SDIO_CMD 0x320d
+#define STM32F429_PD2_FUNC_DCMI_D11 0x320e
+#define STM32F429_PD2_FUNC_EVENTOUT 0x3210
+#define STM32F429_PD2_FUNC_ANALOG 0x3211
+
+#define STM32F429_PD3_FUNC_GPIO 0x3300
+#define STM32F429_PD3_FUNC_SPI2_SCK_I2S2_CK 0x3306
+#define STM32F429_PD3_FUNC_USART2_CTS 0x3308
+#define STM32F429_PD3_FUNC_FMC_CLK 0x330d
+#define STM32F429_PD3_FUNC_DCMI_D5 0x330e
+#define STM32F429_PD3_FUNC_LCD_G7 0x330f
+#define STM32F429_PD3_FUNC_EVENTOUT 0x3310
+#define STM32F429_PD3_FUNC_ANALOG 0x3311
+
+#define STM32F429_PD4_FUNC_GPIO 0x3400
+#define STM32F429_PD4_FUNC_USART2_RTS 0x3408
+#define STM32F429_PD4_FUNC_FMC_NOE 0x340d
+#define STM32F429_PD4_FUNC_EVENTOUT 0x3410
+#define STM32F429_PD4_FUNC_ANALOG 0x3411
+
+#define STM32F429_PD5_FUNC_GPIO 0x3500
+#define STM32F429_PD5_FUNC_USART2_TX 0x3508
+#define STM32F429_PD5_FUNC_FMC_NWE 0x350d
+#define STM32F429_PD5_FUNC_EVENTOUT 0x3510
+#define STM32F429_PD5_FUNC_ANALOG 0x3511
+
+#define STM32F429_PD6_FUNC_GPIO 0x3600
+#define STM32F429_PD6_FUNC_SPI3_MOSI_I2S3_SD 0x3606
+#define STM32F429_PD6_FUNC_SAI1_SD_A 0x3607
+#define STM32F429_PD6_FUNC_USART2_RX 0x3608
+#define STM32F429_PD6_FUNC_FMC_NWAIT 0x360d
+#define STM32F429_PD6_FUNC_DCMI_D10 0x360e
+#define STM32F429_PD6_FUNC_LCD_B2 0x360f
+#define STM32F429_PD6_FUNC_EVENTOUT 0x3610
+#define STM32F429_PD6_FUNC_ANALOG 0x3611
+
+#define STM32F429_PD7_FUNC_GPIO 0x3700
+#define STM32F429_PD7_FUNC_USART2_CK 0x3708
+#define STM32F429_PD7_FUNC_FMC_NE1_FMC_NCE2 0x370d
+#define STM32F429_PD7_FUNC_EVENTOUT 0x3710
+#define STM32F429_PD7_FUNC_ANALOG 0x3711
+
+#define STM32F429_PD8_FUNC_GPIO 0x3800
+#define STM32F429_PD8_FUNC_USART3_TX 0x3808
+#define STM32F429_PD8_FUNC_FMC_D13 0x380d
+#define STM32F429_PD8_FUNC_EVENTOUT 0x3810
+#define STM32F429_PD8_FUNC_ANALOG 0x3811
+
+#define STM32F429_PD9_FUNC_GPIO 0x3900
+#define STM32F429_PD9_FUNC_USART3_RX 0x3908
+#define STM32F429_PD9_FUNC_FMC_D14 0x390d
+#define STM32F429_PD9_FUNC_EVENTOUT 0x3910
+#define STM32F429_PD9_FUNC_ANALOG 0x3911
+
+#define STM32F429_PD10_FUNC_GPIO 0x3a00
+#define STM32F429_PD10_FUNC_USART3_CK 0x3a08
+#define STM32F429_PD10_FUNC_FMC_D15 0x3a0d
+#define STM32F429_PD10_FUNC_LCD_B3 0x3a0f
+#define STM32F429_PD10_FUNC_EVENTOUT 0x3a10
+#define STM32F429_PD10_FUNC_ANALOG 0x3a11
+
+#define STM32F429_PD11_FUNC_GPIO 0x3b00
+#define STM32F429_PD11_FUNC_USART3_CTS 0x3b08
+#define STM32F429_PD11_FUNC_FMC_A16 0x3b0d
+#define STM32F429_PD11_FUNC_EVENTOUT 0x3b10
+#define STM32F429_PD11_FUNC_ANALOG 0x3b11
+
+#define STM32F429_PD12_FUNC_GPIO 0x3c00
+#define STM32F429_PD12_FUNC_TIM4_CH1 0x3c03
+#define STM32F429_PD12_FUNC_USART3_RTS 0x3c08
+#define STM32F429_PD12_FUNC_FMC_A17 0x3c0d
+#define STM32F429_PD12_FUNC_EVENTOUT 0x3c10
+#define STM32F429_PD12_FUNC_ANALOG 0x3c11
+
+#define STM32F429_PD13_FUNC_GPIO 0x3d00
+#define STM32F429_PD13_FUNC_TIM4_CH2 0x3d03
+#define STM32F429_PD13_FUNC_FMC_A18 0x3d0d
+#define STM32F429_PD13_FUNC_EVENTOUT 0x3d10
+#define STM32F429_PD13_FUNC_ANALOG 0x3d11
+
+#define STM32F429_PD14_FUNC_GPIO 0x3e00
+#define STM32F429_PD14_FUNC_TIM4_CH3 0x3e03
+#define STM32F429_PD14_FUNC_FMC_D0 0x3e0d
+#define STM32F429_PD14_FUNC_EVENTOUT 0x3e10
+#define STM32F429_PD14_FUNC_ANALOG 0x3e11
+
+#define STM32F429_PD15_FUNC_GPIO 0x3f00
+#define STM32F429_PD15_FUNC_TIM4_CH4 0x3f03
+#define STM32F429_PD15_FUNC_FMC_D1 0x3f0d
+#define STM32F429_PD15_FUNC_EVENTOUT 0x3f10
+#define STM32F429_PD15_FUNC_ANALOG 0x3f11
+
+
+
+#define STM32F429_PE0_FUNC_GPIO 0x4000
+#define STM32F429_PE0_FUNC_TIM4_ETR 0x4003
+#define STM32F429_PE0_FUNC_UART8_RX 0x4009
+#define STM32F429_PE0_FUNC_FMC_NBL0 0x400d
+#define STM32F429_PE0_FUNC_DCMI_D2 0x400e
+#define STM32F429_PE0_FUNC_EVENTOUT 0x4010
+#define STM32F429_PE0_FUNC_ANALOG 0x4011
+
+#define STM32F429_PE1_FUNC_GPIO 0x4100
+#define STM32F429_PE1_FUNC_UART8_TX 0x4109
+#define STM32F429_PE1_FUNC_FMC_NBL1 0x410d
+#define STM32F429_PE1_FUNC_DCMI_D3 0x410e
+#define STM32F429_PE1_FUNC_EVENTOUT 0x4110
+#define STM32F429_PE1_FUNC_ANALOG 0x4111
+
+#define STM32F429_PE2_FUNC_GPIO 0x4200
+#define STM32F429_PE2_FUNC_TRACECLK 0x4201
+#define STM32F429_PE2_FUNC_SPI4_SCK 0x4206
+#define STM32F429_PE2_FUNC_SAI1_MCLK_A 0x4207
+#define STM32F429_PE2_FUNC_ETH_MII_TXD3 0x420c
+#define STM32F429_PE2_FUNC_FMC_A23 0x420d
+#define STM32F429_PE2_FUNC_EVENTOUT 0x4210
+#define STM32F429_PE2_FUNC_ANALOG 0x4211
+
+#define STM32F429_PE3_FUNC_GPIO 0x4300
+#define STM32F429_PE3_FUNC_TRACED0 0x4301
+#define STM32F429_PE3_FUNC_SAI1_SD_B 0x4307
+#define STM32F429_PE3_FUNC_FMC_A19 0x430d
+#define STM32F429_PE3_FUNC_EVENTOUT 0x4310
+#define STM32F429_PE3_FUNC_ANALOG 0x4311
+
+#define STM32F429_PE4_FUNC_GPIO 0x4400
+#define STM32F429_PE4_FUNC_TRACED1 0x4401
+#define STM32F429_PE4_FUNC_SPI4_NSS 0x4406
+#define STM32F429_PE4_FUNC_SAI1_FS_A 0x4407
+#define STM32F429_PE4_FUNC_FMC_A20 0x440d
+#define STM32F429_PE4_FUNC_DCMI_D4 0x440e
+#define STM32F429_PE4_FUNC_LCD_B0 0x440f
+#define STM32F429_PE4_FUNC_EVENTOUT 0x4410
+#define STM32F429_PE4_FUNC_ANALOG 0x4411
+
+#define STM32F429_PE5_FUNC_GPIO 0x4500
+#define STM32F429_PE5_FUNC_TRACED2 0x4501
+#define STM32F429_PE5_FUNC_TIM9_CH1 0x4504
+#define STM32F429_PE5_FUNC_SPI4_MISO 0x4506
+#define STM32F429_PE5_FUNC_SAI1_SCK_A 0x4507
+#define STM32F429_PE5_FUNC_FMC_A21 0x450d
+#define STM32F429_PE5_FUNC_DCMI_D6 0x450e
+#define STM32F429_PE5_FUNC_LCD_G0 0x450f
+#define STM32F429_PE5_FUNC_EVENTOUT 0x4510
+#define STM32F429_PE5_FUNC_ANALOG 0x4511
+
+#define STM32F429_PE6_FUNC_GPIO 0x4600
+#define STM32F429_PE6_FUNC_TRACED3 0x4601
+#define STM32F429_PE6_FUNC_TIM9_CH2 0x4604
+#define STM32F429_PE6_FUNC_SPI4_MOSI 0x4606
+#define STM32F429_PE6_FUNC_SAI1_SD_A 0x4607
+#define STM32F429_PE6_FUNC_FMC_A22 0x460d
+#define STM32F429_PE6_FUNC_DCMI_D7 0x460e
+#define STM32F429_PE6_FUNC_LCD_G1 0x460f
+#define STM32F429_PE6_FUNC_EVENTOUT 0x4610
+#define STM32F429_PE6_FUNC_ANALOG 0x4611
+
+#define STM32F429_PE7_FUNC_GPIO 0x4700
+#define STM32F429_PE7_FUNC_TIM1_ETR 0x4702
+#define STM32F429_PE7_FUNC_UART7_RX 0x4709
+#define STM32F429_PE7_FUNC_FMC_D4 0x470d
+#define STM32F429_PE7_FUNC_EVENTOUT 0x4710
+#define STM32F429_PE7_FUNC_ANALOG 0x4711
+
+#define STM32F429_PE8_FUNC_GPIO 0x4800
+#define STM32F429_PE8_FUNC_TIM1_CH1N 0x4802
+#define STM32F429_PE8_FUNC_UART7_TX 0x4809
+#define STM32F429_PE8_FUNC_FMC_D5 0x480d
+#define STM32F429_PE8_FUNC_EVENTOUT 0x4810
+#define STM32F429_PE8_FUNC_ANALOG 0x4811
+
+#define STM32F429_PE9_FUNC_GPIO 0x4900
+#define STM32F429_PE9_FUNC_TIM1_CH1 0x4902
+#define STM32F429_PE9_FUNC_FMC_D6 0x490d
+#define STM32F429_PE9_FUNC_EVENTOUT 0x4910
+#define STM32F429_PE9_FUNC_ANALOG 0x4911
+
+#define STM32F429_PE10_FUNC_GPIO 0x4a00
+#define STM32F429_PE10_FUNC_TIM1_CH2N 0x4a02
+#define STM32F429_PE10_FUNC_FMC_D7 0x4a0d
+#define STM32F429_PE10_FUNC_EVENTOUT 0x4a10
+#define STM32F429_PE10_FUNC_ANALOG 0x4a11
+
+#define STM32F429_PE11_FUNC_GPIO 0x4b00
+#define STM32F429_PE11_FUNC_TIM1_CH2 0x4b02
+#define STM32F429_PE11_FUNC_SPI4_NSS 0x4b06
+#define STM32F429_PE11_FUNC_FMC_D8 0x4b0d
+#define STM32F429_PE11_FUNC_LCD_G3 0x4b0f
+#define STM32F429_PE11_FUNC_EVENTOUT 0x4b10
+#define STM32F429_PE11_FUNC_ANALOG 0x4b11
+
+#define STM32F429_PE12_FUNC_GPIO 0x4c00
+#define STM32F429_PE12_FUNC_TIM1_CH3N 0x4c02
+#define STM32F429_PE12_FUNC_SPI4_SCK 0x4c06
+#define STM32F429_PE12_FUNC_FMC_D9 0x4c0d
+#define STM32F429_PE12_FUNC_LCD_B4 0x4c0f
+#define STM32F429_PE12_FUNC_EVENTOUT 0x4c10
+#define STM32F429_PE12_FUNC_ANALOG 0x4c11
+
+#define STM32F429_PE13_FUNC_GPIO 0x4d00
+#define STM32F429_PE13_FUNC_TIM1_CH3 0x4d02
+#define STM32F429_PE13_FUNC_SPI4_MISO 0x4d06
+#define STM32F429_PE13_FUNC_FMC_D10 0x4d0d
+#define STM32F429_PE13_FUNC_LCD_DE 0x4d0f
+#define STM32F429_PE13_FUNC_EVENTOUT 0x4d10
+#define STM32F429_PE13_FUNC_ANALOG 0x4d11
+
+#define STM32F429_PE14_FUNC_GPIO 0x4e00
+#define STM32F429_PE14_FUNC_TIM1_CH4 0x4e02
+#define STM32F429_PE14_FUNC_SPI4_MOSI 0x4e06
+#define STM32F429_PE14_FUNC_FMC_D11 0x4e0d
+#define STM32F429_PE14_FUNC_LCD_CLK 0x4e0f
+#define STM32F429_PE14_FUNC_EVENTOUT 0x4e10
+#define STM32F429_PE14_FUNC_ANALOG 0x4e11
+
+#define STM32F429_PE15_FUNC_GPIO 0x4f00
+#define STM32F429_PE15_FUNC_TIM1_BKIN 0x4f02
+#define STM32F429_PE15_FUNC_FMC_D12 0x4f0d
+#define STM32F429_PE15_FUNC_LCD_R7 0x4f0f
+#define STM32F429_PE15_FUNC_EVENTOUT 0x4f10
+#define STM32F429_PE15_FUNC_ANALOG 0x4f11
+
+
+
+#define STM32F429_PF0_FUNC_GPIO 0x5000
+#define STM32F429_PF0_FUNC_I2C2_SDA 0x5005
+#define STM32F429_PF0_FUNC_FMC_A0 0x500d
+#define STM32F429_PF0_FUNC_EVENTOUT 0x5010
+#define STM32F429_PF0_FUNC_ANALOG 0x5011
+
+#define STM32F429_PF1_FUNC_GPIO 0x5100
+#define STM32F429_PF1_FUNC_I2C2_SCL 0x5105
+#define STM32F429_PF1_FUNC_FMC_A1 0x510d
+#define STM32F429_PF1_FUNC_EVENTOUT 0x5110
+#define STM32F429_PF1_FUNC_ANALOG 0x5111
+
+#define STM32F429_PF2_FUNC_GPIO 0x5200
+#define STM32F429_PF2_FUNC_I2C2_SMBA 0x5205
+#define STM32F429_PF2_FUNC_FMC_A2 0x520d
+#define STM32F429_PF2_FUNC_EVENTOUT 0x5210
+#define STM32F429_PF2_FUNC_ANALOG 0x5211
+
+#define STM32F429_PF3_FUNC_GPIO 0x5300
+#define STM32F429_PF3_FUNC_FMC_A3 0x530d
+#define STM32F429_PF3_FUNC_EVENTOUT 0x5310
+#define STM32F429_PF3_FUNC_ANALOG 0x5311
+
+#define STM32F429_PF4_FUNC_GPIO 0x5400
+#define STM32F429_PF4_FUNC_FMC_A4 0x540d
+#define STM32F429_PF4_FUNC_EVENTOUT 0x5410
+#define STM32F429_PF4_FUNC_ANALOG 0x5411
+
+#define STM32F429_PF5_FUNC_GPIO 0x5500
+#define STM32F429_PF5_FUNC_FMC_A5 0x550d
+#define STM32F429_PF5_FUNC_EVENTOUT 0x5510
+#define STM32F429_PF5_FUNC_ANALOG 0x5511
+
+#define STM32F429_PF6_FUNC_GPIO 0x5600
+#define STM32F429_PF6_FUNC_TIM10_CH1 0x5604
+#define STM32F429_PF6_FUNC_SPI5_NSS 0x5606
+#define STM32F429_PF6_FUNC_SAI1_SD_B 0x5607
+#define STM32F429_PF6_FUNC_UART7_RX 0x5609
+#define STM32F429_PF6_FUNC_FMC_NIORD 0x560d
+#define STM32F429_PF6_FUNC_EVENTOUT 0x5610
+#define STM32F429_PF6_FUNC_ANALOG 0x5611
+
+#define STM32F429_PF7_FUNC_GPIO 0x5700
+#define STM32F429_PF7_FUNC_TIM11_CH1 0x5704
+#define STM32F429_PF7_FUNC_SPI5_SCK 0x5706
+#define STM32F429_PF7_FUNC_SAI1_MCLK_B 0x5707
+#define STM32F429_PF7_FUNC_UART7_TX 0x5709
+#define STM32F429_PF7_FUNC_FMC_NREG 0x570d
+#define STM32F429_PF7_FUNC_EVENTOUT 0x5710
+#define STM32F429_PF7_FUNC_ANALOG 0x5711
+
+#define STM32F429_PF8_FUNC_GPIO 0x5800
+#define STM32F429_PF8_FUNC_SPI5_MISO 0x5806
+#define STM32F429_PF8_FUNC_SAI1_SCK_B 0x5807
+#define STM32F429_PF8_FUNC_TIM13_CH1 0x580a
+#define STM32F429_PF8_FUNC_FMC_NIOWR 0x580d
+#define STM32F429_PF8_FUNC_EVENTOUT 0x5810
+#define STM32F429_PF8_FUNC_ANALOG 0x5811
+
+#define STM32F429_PF9_FUNC_GPIO 0x5900
+#define STM32F429_PF9_FUNC_SPI5_MOSI 0x5906
+#define STM32F429_PF9_FUNC_SAI1_FS_B 0x5907
+#define STM32F429_PF9_FUNC_TIM14_CH1 0x590a
+#define STM32F429_PF9_FUNC_FMC_CD 0x590d
+#define STM32F429_PF9_FUNC_EVENTOUT 0x5910
+#define STM32F429_PF9_FUNC_ANALOG 0x5911
+
+#define STM32F429_PF10_FUNC_GPIO 0x5a00
+#define STM32F429_PF10_FUNC_FMC_INTR 0x5a0d
+#define STM32F429_PF10_FUNC_DCMI_D11 0x5a0e
+#define STM32F429_PF10_FUNC_LCD_DE 0x5a0f
+#define STM32F429_PF10_FUNC_EVENTOUT 0x5a10
+#define STM32F429_PF10_FUNC_ANALOG 0x5a11
+
+#define STM32F429_PF11_FUNC_GPIO 0x5b00
+#define STM32F429_PF11_FUNC_SPI5_MOSI 0x5b06
+#define STM32F429_PF11_FUNC_FMC_SDNRAS 0x5b0d
+#define STM32F429_PF11_FUNC_DCMI_D12 0x5b0e
+#define STM32F429_PF11_FUNC_EVENTOUT 0x5b10
+#define STM32F429_PF11_FUNC_ANALOG 0x5b11
+
+#define STM32F429_PF12_FUNC_GPIO 0x5c00
+#define STM32F429_PF12_FUNC_FMC_A6 0x5c0d
+#define STM32F429_PF12_FUNC_EVENTOUT 0x5c10
+#define STM32F429_PF12_FUNC_ANALOG 0x5c11
+
+#define STM32F429_PF13_FUNC_GPIO 0x5d00
+#define STM32F429_PF13_FUNC_FMC_A7 0x5d0d
+#define STM32F429_PF13_FUNC_EVENTOUT 0x5d10
+#define STM32F429_PF13_FUNC_ANALOG 0x5d11
+
+#define STM32F429_PF14_FUNC_GPIO 0x5e00
+#define STM32F429_PF14_FUNC_FMC_A8 0x5e0d
+#define STM32F429_PF14_FUNC_EVENTOUT 0x5e10
+#define STM32F429_PF14_FUNC_ANALOG 0x5e11
+
+#define STM32F429_PF15_FUNC_GPIO 0x5f00
+#define STM32F429_PF15_FUNC_FMC_A9 0x5f0d
+#define STM32F429_PF15_FUNC_EVENTOUT 0x5f10
+#define STM32F429_PF15_FUNC_ANALOG 0x5f11
+
+
+
+#define STM32F429_PG0_FUNC_GPIO 0x6000
+#define STM32F429_PG0_FUNC_FMC_A10 0x600d
+#define STM32F429_PG0_FUNC_EVENTOUT 0x6010
+#define STM32F429_PG0_FUNC_ANALOG 0x6011
+
+#define STM32F429_PG1_FUNC_GPIO 0x6100
+#define STM32F429_PG1_FUNC_FMC_A11 0x610d
+#define STM32F429_PG1_FUNC_EVENTOUT 0x6110
+#define STM32F429_PG1_FUNC_ANALOG 0x6111
+
+#define STM32F429_PG2_FUNC_GPIO 0x6200
+#define STM32F429_PG2_FUNC_FMC_A12 0x620d
+#define STM32F429_PG2_FUNC_EVENTOUT 0x6210
+#define STM32F429_PG2_FUNC_ANALOG 0x6211
+
+#define STM32F429_PG3_FUNC_GPIO 0x6300
+#define STM32F429_PG3_FUNC_FMC_A13 0x630d
+#define STM32F429_PG3_FUNC_EVENTOUT 0x6310
+#define STM32F429_PG3_FUNC_ANALOG 0x6311
+
+#define STM32F429_PG4_FUNC_GPIO 0x6400
+#define STM32F429_PG4_FUNC_FMC_A14_FMC_BA0 0x640d
+#define STM32F429_PG4_FUNC_EVENTOUT 0x6410
+#define STM32F429_PG4_FUNC_ANALOG 0x6411
+
+#define STM32F429_PG5_FUNC_GPIO 0x6500
+#define STM32F429_PG5_FUNC_FMC_A15_FMC_BA1 0x650d
+#define STM32F429_PG5_FUNC_EVENTOUT 0x6510
+#define STM32F429_PG5_FUNC_ANALOG 0x6511
+
+#define STM32F429_PG6_FUNC_GPIO 0x6600
+#define STM32F429_PG6_FUNC_FMC_INT2 0x660d
+#define STM32F429_PG6_FUNC_DCMI_D12 0x660e
+#define STM32F429_PG6_FUNC_LCD_R7 0x660f
+#define STM32F429_PG6_FUNC_EVENTOUT 0x6610
+#define STM32F429_PG6_FUNC_ANALOG 0x6611
+
+#define STM32F429_PG7_FUNC_GPIO 0x6700
+#define STM32F429_PG7_FUNC_USART6_CK 0x6709
+#define STM32F429_PG7_FUNC_FMC_INT3 0x670d
+#define STM32F429_PG7_FUNC_DCMI_D13 0x670e
+#define STM32F429_PG7_FUNC_LCD_CLK 0x670f
+#define STM32F429_PG7_FUNC_EVENTOUT 0x6710
+#define STM32F429_PG7_FUNC_ANALOG 0x6711
+
+#define STM32F429_PG8_FUNC_GPIO 0x6800
+#define STM32F429_PG8_FUNC_SPI6_NSS 0x6806
+#define STM32F429_PG8_FUNC_USART6_RTS 0x6809
+#define STM32F429_PG8_FUNC_ETH_PPS_OUT 0x680c
+#define STM32F429_PG8_FUNC_FMC_SDCLK 0x680d
+#define STM32F429_PG8_FUNC_EVENTOUT 0x6810
+#define STM32F429_PG8_FUNC_ANALOG 0x6811
+
+#define STM32F429_PG9_FUNC_GPIO 0x6900
+#define STM32F429_PG9_FUNC_USART6_RX 0x6909
+#define STM32F429_PG9_FUNC_FMC_NE2_FMC_NCE3 0x690d
+#define STM32F429_PG9_FUNC_DCMI_VSYNC 0x690e
+#define STM32F429_PG9_FUNC_EVENTOUT 0x6910
+#define STM32F429_PG9_FUNC_ANALOG 0x6911
+
+#define STM32F429_PG10_FUNC_GPIO 0x6a00
+#define STM32F429_PG10_FUNC_LCD_G3 0x6a0a
+#define STM32F429_PG10_FUNC_FMC_NCE4_1_FMC_NE3 0x6a0d
+#define STM32F429_PG10_FUNC_DCMI_D2 0x6a0e
+#define STM32F429_PG10_FUNC_LCD_B2 0x6a0f
+#define STM32F429_PG10_FUNC_EVENTOUT 0x6a10
+#define STM32F429_PG10_FUNC_ANALOG 0x6a11
+
+#define STM32F429_PG11_FUNC_GPIO 0x6b00
+#define STM32F429_PG11_FUNC_ETH_MII_TX_EN_ETH_RMII_TX_EN 0x6b0c
+#define STM32F429_PG11_FUNC_FMC_NCE4_2 0x6b0d
+#define STM32F429_PG11_FUNC_DCMI_D3 0x6b0e
+#define STM32F429_PG11_FUNC_LCD_B3 0x6b0f
+#define STM32F429_PG11_FUNC_EVENTOUT 0x6b10
+#define STM32F429_PG11_FUNC_ANALOG 0x6b11
+
+#define STM32F429_PG12_FUNC_GPIO 0x6c00
+#define STM32F429_PG12_FUNC_SPI6_MISO 0x6c06
+#define STM32F429_PG12_FUNC_USART6_RTS 0x6c09
+#define STM32F429_PG12_FUNC_LCD_B4 0x6c0a
+#define STM32F429_PG12_FUNC_FMC_NE4 0x6c0d
+#define STM32F429_PG12_FUNC_LCD_B1 0x6c0f
+#define STM32F429_PG12_FUNC_EVENTOUT 0x6c10
+#define STM32F429_PG12_FUNC_ANALOG 0x6c11
+
+#define STM32F429_PG13_FUNC_GPIO 0x6d00
+#define STM32F429_PG13_FUNC_SPI6_SCK 0x6d06
+#define STM32F429_PG13_FUNC_USART6_CTS 0x6d09
+#define STM32F429_PG13_FUNC_ETH_MII_TXD0_ETH_RMII_TXD0 0x6d0c
+#define STM32F429_PG13_FUNC_FMC_A24 0x6d0d
+#define STM32F429_PG13_FUNC_EVENTOUT 0x6d10
+#define STM32F429_PG13_FUNC_ANALOG 0x6d11
+
+#define STM32F429_PG14_FUNC_GPIO 0x6e00
+#define STM32F429_PG14_FUNC_SPI6_MOSI 0x6e06
+#define STM32F429_PG14_FUNC_USART6_TX 0x6e09
+#define STM32F429_PG14_FUNC_ETH_MII_TXD1_ETH_RMII_TXD1 0x6e0c
+#define STM32F429_PG14_FUNC_FMC_A25 0x6e0d
+#define STM32F429_PG14_FUNC_EVENTOUT 0x6e10
+#define STM32F429_PG14_FUNC_ANALOG 0x6e11
+
+#define STM32F429_PG15_FUNC_GPIO 0x6f00
+#define STM32F429_PG15_FUNC_USART6_CTS 0x6f09
+#define STM32F429_PG15_FUNC_FMC_SDNCAS 0x6f0d
+#define STM32F429_PG15_FUNC_DCMI_D13 0x6f0e
+#define STM32F429_PG15_FUNC_EVENTOUT 0x6f10
+#define STM32F429_PG15_FUNC_ANALOG 0x6f11
+
+
+
+#define STM32F429_PH0_FUNC_GPIO 0x7000
+#define STM32F429_PH0_FUNC_EVENTOUT 0x7010
+#define STM32F429_PH0_FUNC_ANALOG 0x7011
+
+#define STM32F429_PH1_FUNC_GPIO 0x7100
+#define STM32F429_PH1_FUNC_EVENTOUT 0x7110
+#define STM32F429_PH1_FUNC_ANALOG 0x7111
+
+#define STM32F429_PH2_FUNC_GPIO 0x7200
+#define STM32F429_PH2_FUNC_ETH_MII_CRS 0x720c
+#define STM32F429_PH2_FUNC_FMC_SDCKE0 0x720d
+#define STM32F429_PH2_FUNC_LCD_R0 0x720f
+#define STM32F429_PH2_FUNC_EVENTOUT 0x7210
+#define STM32F429_PH2_FUNC_ANALOG 0x7211
+
+#define STM32F429_PH3_FUNC_GPIO 0x7300
+#define STM32F429_PH3_FUNC_ETH_MII_COL 0x730c
+#define STM32F429_PH3_FUNC_FMC_SDNE0 0x730d
+#define STM32F429_PH3_FUNC_LCD_R1 0x730f
+#define STM32F429_PH3_FUNC_EVENTOUT 0x7310
+#define STM32F429_PH3_FUNC_ANALOG 0x7311
+
+#define STM32F429_PH4_FUNC_GPIO 0x7400
+#define STM32F429_PH4_FUNC_I2C2_SCL 0x7405
+#define STM32F429_PH4_FUNC_OTG_HS_ULPI_NXT 0x740b
+#define STM32F429_PH4_FUNC_EVENTOUT 0x7410
+#define STM32F429_PH4_FUNC_ANALOG 0x7411
+
+#define STM32F429_PH5_FUNC_GPIO 0x7500
+#define STM32F429_PH5_FUNC_I2C2_SDA 0x7505
+#define STM32F429_PH5_FUNC_SPI5_NSS 0x7506
+#define STM32F429_PH5_FUNC_FMC_SDNWE 0x750d
+#define STM32F429_PH5_FUNC_EVENTOUT 0x7510
+#define STM32F429_PH5_FUNC_ANALOG 0x7511
+
+#define STM32F429_PH6_FUNC_GPIO 0x7600
+#define STM32F429_PH6_FUNC_I2C2_SMBA 0x7605
+#define STM32F429_PH6_FUNC_SPI5_SCK 0x7606
+#define STM32F429_PH6_FUNC_TIM12_CH1 0x760a
+#define STM32F429_PH6_FUNC_ETH_MII_RXD2 0x760c
+#define STM32F429_PH6_FUNC_FMC_SDNE1 0x760d
+#define STM32F429_PH6_FUNC_DCMI_D8 0x760e
+#define STM32F429_PH6_FUNC_EVENTOUT 0x7610
+#define STM32F429_PH6_FUNC_ANALOG 0x7611
+
+#define STM32F429_PH7_FUNC_GPIO 0x7700
+#define STM32F429_PH7_FUNC_I2C3_SCL 0x7705
+#define STM32F429_PH7_FUNC_SPI5_MISO 0x7706
+#define STM32F429_PH7_FUNC_ETH_MII_RXD3 0x770c
+#define STM32F429_PH7_FUNC_FMC_SDCKE1 0x770d
+#define STM32F429_PH7_FUNC_DCMI_D9 0x770e
+#define STM32F429_PH7_FUNC_EVENTOUT 0x7710
+#define STM32F429_PH7_FUNC_ANALOG 0x7711
+
+#define STM32F429_PH8_FUNC_GPIO 0x7800
+#define STM32F429_PH8_FUNC_I2C3_SDA 0x7805
+#define STM32F429_PH8_FUNC_FMC_D16 0x780d
+#define STM32F429_PH8_FUNC_DCMI_HSYNC 0x780e
+#define STM32F429_PH8_FUNC_LCD_R2 0x780f
+#define STM32F429_PH8_FUNC_EVENTOUT 0x7810
+#define STM32F429_PH8_FUNC_ANALOG 0x7811
+
+#define STM32F429_PH9_FUNC_GPIO 0x7900
+#define STM32F429_PH9_FUNC_I2C3_SMBA 0x7905
+#define STM32F429_PH9_FUNC_TIM12_CH2 0x790a
+#define STM32F429_PH9_FUNC_FMC_D17 0x790d
+#define STM32F429_PH9_FUNC_DCMI_D0 0x790e
+#define STM32F429_PH9_FUNC_LCD_R3 0x790f
+#define STM32F429_PH9_FUNC_EVENTOUT 0x7910
+#define STM32F429_PH9_FUNC_ANALOG 0x7911
+
+#define STM32F429_PH10_FUNC_GPIO 0x7a00
+#define STM32F429_PH10_FUNC_TIM5_CH1 0x7a03
+#define STM32F429_PH10_FUNC_FMC_D18 0x7a0d
+#define STM32F429_PH10_FUNC_DCMI_D1 0x7a0e
+#define STM32F429_PH10_FUNC_LCD_R4 0x7a0f
+#define STM32F429_PH10_FUNC_EVENTOUT 0x7a10
+#define STM32F429_PH10_FUNC_ANALOG 0x7a11
+
+#define STM32F429_PH11_FUNC_GPIO 0x7b00
+#define STM32F429_PH11_FUNC_TIM5_CH2 0x7b03
+#define STM32F429_PH11_FUNC_FMC_D19 0x7b0d
+#define STM32F429_PH11_FUNC_DCMI_D2 0x7b0e
+#define STM32F429_PH11_FUNC_LCD_R5 0x7b0f
+#define STM32F429_PH11_FUNC_EVENTOUT 0x7b10
+#define STM32F429_PH11_FUNC_ANALOG 0x7b11
+
+#define STM32F429_PH12_FUNC_GPIO 0x7c00
+#define STM32F429_PH12_FUNC_TIM5_CH3 0x7c03
+#define STM32F429_PH12_FUNC_FMC_D20 0x7c0d
+#define STM32F429_PH12_FUNC_DCMI_D3 0x7c0e
+#define STM32F429_PH12_FUNC_LCD_R6 0x7c0f
+#define STM32F429_PH12_FUNC_EVENTOUT 0x7c10
+#define STM32F429_PH12_FUNC_ANALOG 0x7c11
+
+#define STM32F429_PH13_FUNC_GPIO 0x7d00
+#define STM32F429_PH13_FUNC_TIM8_CH1N 0x7d04
+#define STM32F429_PH13_FUNC_CAN1_TX 0x7d0a
+#define STM32F429_PH13_FUNC_FMC_D21 0x7d0d
+#define STM32F429_PH13_FUNC_LCD_G2 0x7d0f
+#define STM32F429_PH13_FUNC_EVENTOUT 0x7d10
+#define STM32F429_PH13_FUNC_ANALOG 0x7d11
+
+#define STM32F429_PH14_FUNC_GPIO 0x7e00
+#define STM32F429_PH14_FUNC_TIM8_CH2N 0x7e04
+#define STM32F429_PH14_FUNC_FMC_D22 0x7e0d
+#define STM32F429_PH14_FUNC_DCMI_D4 0x7e0e
+#define STM32F429_PH14_FUNC_LCD_G3 0x7e0f
+#define STM32F429_PH14_FUNC_EVENTOUT 0x7e10
+#define STM32F429_PH14_FUNC_ANALOG 0x7e11
+
+#define STM32F429_PH15_FUNC_GPIO 0x7f00
+#define STM32F429_PH15_FUNC_TIM8_CH3N 0x7f04
+#define STM32F429_PH15_FUNC_FMC_D23 0x7f0d
+#define STM32F429_PH15_FUNC_DCMI_D11 0x7f0e
+#define STM32F429_PH15_FUNC_LCD_G4 0x7f0f
+#define STM32F429_PH15_FUNC_EVENTOUT 0x7f10
+#define STM32F429_PH15_FUNC_ANALOG 0x7f11
+
+
+
+#define STM32F429_PI0_FUNC_GPIO 0x8000
+#define STM32F429_PI0_FUNC_TIM5_CH4 0x8003
+#define STM32F429_PI0_FUNC_SPI2_NSS_I2S2_WS 0x8006
+#define STM32F429_PI0_FUNC_FMC_D24 0x800d
+#define STM32F429_PI0_FUNC_DCMI_D13 0x800e
+#define STM32F429_PI0_FUNC_LCD_G5 0x800f
+#define STM32F429_PI0_FUNC_EVENTOUT 0x8010
+#define STM32F429_PI0_FUNC_ANALOG 0x8011
+
+#define STM32F429_PI1_FUNC_GPIO 0x8100
+#define STM32F429_PI1_FUNC_SPI2_SCK_I2S2_CK 0x8106
+#define STM32F429_PI1_FUNC_FMC_D25 0x810d
+#define STM32F429_PI1_FUNC_DCMI_D8 0x810e
+#define STM32F429_PI1_FUNC_LCD_G6 0x810f
+#define STM32F429_PI1_FUNC_EVENTOUT 0x8110
+#define STM32F429_PI1_FUNC_ANALOG 0x8111
+
+#define STM32F429_PI2_FUNC_GPIO 0x8200
+#define STM32F429_PI2_FUNC_TIM8_CH4 0x8204
+#define STM32F429_PI2_FUNC_SPI2_MISO 0x8206
+#define STM32F429_PI2_FUNC_I2S2EXT_SD 0x8207
+#define STM32F429_PI2_FUNC_FMC_D26 0x820d
+#define STM32F429_PI2_FUNC_DCMI_D9 0x820e
+#define STM32F429_PI2_FUNC_LCD_G7 0x820f
+#define STM32F429_PI2_FUNC_EVENTOUT 0x8210
+#define STM32F429_PI2_FUNC_ANALOG 0x8211
+
+#define STM32F429_PI3_FUNC_GPIO 0x8300
+#define STM32F429_PI3_FUNC_TIM8_ETR 0x8304
+#define STM32F429_PI3_FUNC_SPI2_MOSI_I2S2_SD 0x8306
+#define STM32F429_PI3_FUNC_FMC_D27 0x830d
+#define STM32F429_PI3_FUNC_DCMI_D10 0x830e
+#define STM32F429_PI3_FUNC_EVENTOUT 0x8310
+#define STM32F429_PI3_FUNC_ANALOG 0x8311
+
+#define STM32F429_PI4_FUNC_GPIO 0x8400
+#define STM32F429_PI4_FUNC_TIM8_BKIN 0x8404
+#define STM32F429_PI4_FUNC_FMC_NBL2 0x840d
+#define STM32F429_PI4_FUNC_DCMI_D5 0x840e
+#define STM32F429_PI4_FUNC_LCD_B4 0x840f
+#define STM32F429_PI4_FUNC_EVENTOUT 0x8410
+#define STM32F429_PI4_FUNC_ANALOG 0x8411
+
+#define STM32F429_PI5_FUNC_GPIO 0x8500
+#define STM32F429_PI5_FUNC_TIM8_CH1 0x8504
+#define STM32F429_PI5_FUNC_FMC_NBL3 0x850d
+#define STM32F429_PI5_FUNC_DCMI_VSYNC 0x850e
+#define STM32F429_PI5_FUNC_LCD_B5 0x850f
+#define STM32F429_PI5_FUNC_EVENTOUT 0x8510
+#define STM32F429_PI5_FUNC_ANALOG 0x8511
+
+#define STM32F429_PI6_FUNC_GPIO 0x8600
+#define STM32F429_PI6_FUNC_TIM8_CH2 0x8604
+#define STM32F429_PI6_FUNC_FMC_D28 0x860d
+#define STM32F429_PI6_FUNC_DCMI_D6 0x860e
+#define STM32F429_PI6_FUNC_LCD_B6 0x860f
+#define STM32F429_PI6_FUNC_EVENTOUT 0x8610
+#define STM32F429_PI6_FUNC_ANALOG 0x8611
+
+#define STM32F429_PI7_FUNC_GPIO 0x8700
+#define STM32F429_PI7_FUNC_TIM8_CH3 0x8704
+#define STM32F429_PI7_FUNC_FMC_D29 0x870d
+#define STM32F429_PI7_FUNC_DCMI_D7 0x870e
+#define STM32F429_PI7_FUNC_LCD_B7 0x870f
+#define STM32F429_PI7_FUNC_EVENTOUT 0x8710
+#define STM32F429_PI7_FUNC_ANALOG 0x8711
+
+#define STM32F429_PI8_FUNC_GPIO 0x8800
+#define STM32F429_PI8_FUNC_EVENTOUT 0x8810
+#define STM32F429_PI8_FUNC_ANALOG 0x8811
+
+#define STM32F429_PI9_FUNC_GPIO 0x8900
+#define STM32F429_PI9_FUNC_CAN1_RX 0x890a
+#define STM32F429_PI9_FUNC_FMC_D30 0x890d
+#define STM32F429_PI9_FUNC_LCD_VSYNC 0x890f
+#define STM32F429_PI9_FUNC_EVENTOUT 0x8910
+#define STM32F429_PI9_FUNC_ANALOG 0x8911
+
+#define STM32F429_PI10_FUNC_GPIO 0x8a00
+#define STM32F429_PI10_FUNC_ETH_MII_RX_ER 0x8a0c
+#define STM32F429_PI10_FUNC_FMC_D31 0x8a0d
+#define STM32F429_PI10_FUNC_LCD_HSYNC 0x8a0f
+#define STM32F429_PI10_FUNC_EVENTOUT 0x8a10
+#define STM32F429_PI10_FUNC_ANALOG 0x8a11
+
+#define STM32F429_PI11_FUNC_GPIO 0x8b00
+#define STM32F429_PI11_FUNC_OTG_HS_ULPI_DIR 0x8b0b
+#define STM32F429_PI11_FUNC_EVENTOUT 0x8b10
+#define STM32F429_PI11_FUNC_ANALOG 0x8b11
+
+#define STM32F429_PI12_FUNC_GPIO 0x8c00
+#define STM32F429_PI12_FUNC_LCD_HSYNC 0x8c0f
+#define STM32F429_PI12_FUNC_EVENTOUT 0x8c10
+#define STM32F429_PI12_FUNC_ANALOG 0x8c11
+
+#define STM32F429_PI13_FUNC_GPIO 0x8d00
+#define STM32F429_PI13_FUNC_LCD_VSYNC 0x8d0f
+#define STM32F429_PI13_FUNC_EVENTOUT 0x8d10
+#define STM32F429_PI13_FUNC_ANALOG 0x8d11
+
+#define STM32F429_PI14_FUNC_GPIO 0x8e00
+#define STM32F429_PI14_FUNC_LCD_CLK 0x8e0f
+#define STM32F429_PI14_FUNC_EVENTOUT 0x8e10
+#define STM32F429_PI14_FUNC_ANALOG 0x8e11
+
+#define STM32F429_PI15_FUNC_GPIO 0x8f00
+#define STM32F429_PI15_FUNC_LCD_R0 0x8f0f
+#define STM32F429_PI15_FUNC_EVENTOUT 0x8f10
+#define STM32F429_PI15_FUNC_ANALOG 0x8f11
+
+
+
+#define STM32F429_PJ0_FUNC_GPIO 0x9000
+#define STM32F429_PJ0_FUNC_LCD_R1 0x900f
+#define STM32F429_PJ0_FUNC_EVENTOUT 0x9010
+#define STM32F429_PJ0_FUNC_ANALOG 0x9011
+
+#define STM32F429_PJ1_FUNC_GPIO 0x9100
+#define STM32F429_PJ1_FUNC_LCD_R2 0x910f
+#define STM32F429_PJ1_FUNC_EVENTOUT 0x9110
+#define STM32F429_PJ1_FUNC_ANALOG 0x9111
+
+#define STM32F429_PJ2_FUNC_GPIO 0x9200
+#define STM32F429_PJ2_FUNC_LCD_R3 0x920f
+#define STM32F429_PJ2_FUNC_EVENTOUT 0x9210
+#define STM32F429_PJ2_FUNC_ANALOG 0x9211
+
+#define STM32F429_PJ3_FUNC_GPIO 0x9300
+#define STM32F429_PJ3_FUNC_LCD_R4 0x930f
+#define STM32F429_PJ3_FUNC_EVENTOUT 0x9310
+#define STM32F429_PJ3_FUNC_ANALOG 0x9311
+
+#define STM32F429_PJ4_FUNC_GPIO 0x9400
+#define STM32F429_PJ4_FUNC_LCD_R5 0x940f
+#define STM32F429_PJ4_FUNC_EVENTOUT 0x9410
+#define STM32F429_PJ4_FUNC_ANALOG 0x9411
+
+#define STM32F429_PJ5_FUNC_GPIO 0x9500
+#define STM32F429_PJ5_FUNC_LCD_R6 0x950f
+#define STM32F429_PJ5_FUNC_EVENTOUT 0x9510
+#define STM32F429_PJ5_FUNC_ANALOG 0x9511
+
+#define STM32F429_PJ6_FUNC_GPIO 0x9600
+#define STM32F429_PJ6_FUNC_LCD_R7 0x960f
+#define STM32F429_PJ6_FUNC_EVENTOUT 0x9610
+#define STM32F429_PJ6_FUNC_ANALOG 0x9611
+
+#define STM32F429_PJ7_FUNC_GPIO 0x9700
+#define STM32F429_PJ7_FUNC_LCD_G0 0x970f
+#define STM32F429_PJ7_FUNC_EVENTOUT 0x9710
+#define STM32F429_PJ7_FUNC_ANALOG 0x9711
+
+#define STM32F429_PJ8_FUNC_GPIO 0x9800
+#define STM32F429_PJ8_FUNC_LCD_G1 0x980f
+#define STM32F429_PJ8_FUNC_EVENTOUT 0x9810
+#define STM32F429_PJ8_FUNC_ANALOG 0x9811
+
+#define STM32F429_PJ9_FUNC_GPIO 0x9900
+#define STM32F429_PJ9_FUNC_LCD_G2 0x990f
+#define STM32F429_PJ9_FUNC_EVENTOUT 0x9910
+#define STM32F429_PJ9_FUNC_ANALOG 0x9911
+
+#define STM32F429_PJ10_FUNC_GPIO 0x9a00
+#define STM32F429_PJ10_FUNC_LCD_G3 0x9a0f
+#define STM32F429_PJ10_FUNC_EVENTOUT 0x9a10
+#define STM32F429_PJ10_FUNC_ANALOG 0x9a11
+
+#define STM32F429_PJ11_FUNC_GPIO 0x9b00
+#define STM32F429_PJ11_FUNC_LCD_G4 0x9b0f
+#define STM32F429_PJ11_FUNC_EVENTOUT 0x9b10
+#define STM32F429_PJ11_FUNC_ANALOG 0x9b11
+
+#define STM32F429_PJ12_FUNC_GPIO 0x9c00
+#define STM32F429_PJ12_FUNC_LCD_B0 0x9c0f
+#define STM32F429_PJ12_FUNC_EVENTOUT 0x9c10
+#define STM32F429_PJ12_FUNC_ANALOG 0x9c11
+
+#define STM32F429_PJ13_FUNC_GPIO 0x9d00
+#define STM32F429_PJ13_FUNC_LCD_B1 0x9d0f
+#define STM32F429_PJ13_FUNC_EVENTOUT 0x9d10
+#define STM32F429_PJ13_FUNC_ANALOG 0x9d11
+
+#define STM32F429_PJ14_FUNC_GPIO 0x9e00
+#define STM32F429_PJ14_FUNC_LCD_B2 0x9e0f
+#define STM32F429_PJ14_FUNC_EVENTOUT 0x9e10
+#define STM32F429_PJ14_FUNC_ANALOG 0x9e11
+
+#define STM32F429_PJ15_FUNC_GPIO 0x9f00
+#define STM32F429_PJ15_FUNC_LCD_B3 0x9f0f
+#define STM32F429_PJ15_FUNC_EVENTOUT 0x9f10
+#define STM32F429_PJ15_FUNC_ANALOG 0x9f11
+
+
+
+#define STM32F429_PK0_FUNC_GPIO 0xa000
+#define STM32F429_PK0_FUNC_LCD_G5 0xa00f
+#define STM32F429_PK0_FUNC_EVENTOUT 0xa010
+#define STM32F429_PK0_FUNC_ANALOG 0xa011
+
+#define STM32F429_PK1_FUNC_GPIO 0xa100
+#define STM32F429_PK1_FUNC_LCD_G6 0xa10f
+#define STM32F429_PK1_FUNC_EVENTOUT 0xa110
+#define STM32F429_PK1_FUNC_ANALOG 0xa111
+
+#define STM32F429_PK2_FUNC_GPIO 0xa200
+#define STM32F429_PK2_FUNC_LCD_G7 0xa20f
+#define STM32F429_PK2_FUNC_EVENTOUT 0xa210
+#define STM32F429_PK2_FUNC_ANALOG 0xa211
+
+#define STM32F429_PK3_FUNC_GPIO 0xa300
+#define STM32F429_PK3_FUNC_LCD_B4 0xa30f
+#define STM32F429_PK3_FUNC_EVENTOUT 0xa310
+#define STM32F429_PK3_FUNC_ANALOG 0xa311
+
+#define STM32F429_PK4_FUNC_GPIO 0xa400
+#define STM32F429_PK4_FUNC_LCD_B5 0xa40f
+#define STM32F429_PK4_FUNC_EVENTOUT 0xa410
+#define STM32F429_PK4_FUNC_ANALOG 0xa411
+
+#define STM32F429_PK5_FUNC_GPIO 0xa500
+#define STM32F429_PK5_FUNC_LCD_B6 0xa50f
+#define STM32F429_PK5_FUNC_EVENTOUT 0xa510
+#define STM32F429_PK5_FUNC_ANALOG 0xa511
+
+#define STM32F429_PK6_FUNC_GPIO 0xa600
+#define STM32F429_PK6_FUNC_LCD_B7 0xa60f
+#define STM32F429_PK6_FUNC_EVENTOUT 0xa610
+#define STM32F429_PK6_FUNC_ANALOG 0xa611
+
+#define STM32F429_PK7_FUNC_GPIO 0xa700
+#define STM32F429_PK7_FUNC_LCD_DE 0xa70f
+#define STM32F429_PK7_FUNC_EVENTOUT 0xa710
+#define STM32F429_PK7_FUNC_ANALOG 0xa711
+
+#endif /* _DT_BINDINGS_STM32F429_PINFUNC_H */
-- 
1.9.1



From mcoquelin.stm32 at gmail.com  Wed Feb  3 03:04:40 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Wed,  3 Feb 2016 12:04:40 +0100
Subject: [PATCH v5 4/9] pinctrl: Add STM32 MCUs support
In-Reply-To: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
References: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
Message-ID: <1454497485-464-5-git-send-email-mcoquelin.stm32@gmail.com>

This patch adds pinctrl and GPIO support to STMicroelectronic's STM32
family of MCUs.

While it only supports STM32F429 for now, it has been designed to enable
support of other MCUs of the family (e.g. STM32F746).

Acked-by: Patrice Chotard <patrice.chotard at st.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
---
 drivers/pinctrl/Kconfig                   |    1 +
 drivers/pinctrl/Makefile                  |    1 +
 drivers/pinctrl/stm32/Kconfig             |   16 +
 drivers/pinctrl/stm32/Makefile            |    5 +
 drivers/pinctrl/stm32/pinctrl-stm32.c     |  832 +++++++++++++++
 drivers/pinctrl/stm32/pinctrl-stm32.h     |   51 +
 drivers/pinctrl/stm32/pinctrl-stm32f429.c | 1598 +++++++++++++++++++++++++++++
 7 files changed, 2504 insertions(+)
 create mode 100644 drivers/pinctrl/stm32/Kconfig
 create mode 100644 drivers/pinctrl/stm32/Makefile
 create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.c
 create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.h
 create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32f429.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 99a4c10..f8405cd 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -257,6 +257,7 @@ source "drivers/pinctrl/qcom/Kconfig"
 source "drivers/pinctrl/samsung/Kconfig"
 source "drivers/pinctrl/sh-pfc/Kconfig"
 source "drivers/pinctrl/spear/Kconfig"
+source "drivers/pinctrl/stm32/Kconfig"
 source "drivers/pinctrl/sunxi/Kconfig"
 source "drivers/pinctrl/uniphier/Kconfig"
 source "drivers/pinctrl/vt8500/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index bf1b5ca..7c3fd63 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_ARCH_QCOM)		+= qcom/
 obj-$(CONFIG_PINCTRL_SAMSUNG)	+= samsung/
 obj-$(CONFIG_PINCTRL_SH_PFC)	+= sh-pfc/
 obj-$(CONFIG_PINCTRL_SPEAR)	+= spear/
+obj-$(CONFIG_PINCTRL_STM32)	+= stm32/
 obj-$(CONFIG_ARCH_SUNXI)	+= sunxi/
 obj-$(CONFIG_PINCTRL_UNIPHIER)	+= uniphier/
 obj-$(CONFIG_ARCH_VT8500)	+= vt8500/
diff --git a/drivers/pinctrl/stm32/Kconfig b/drivers/pinctrl/stm32/Kconfig
new file mode 100644
index 0000000..0f28841
--- /dev/null
+++ b/drivers/pinctrl/stm32/Kconfig
@@ -0,0 +1,16 @@
+if ARCH_STM32 || COMPILE_TEST
+
+config PINCTRL_STM32
+	bool
+	depends on OF
+	select PINMUX
+	select GENERIC_PINCONF
+	select GPIOLIB
+
+config PINCTRL_STM32F429
+	bool "STMicroelectronics STM32F429 pin control" if COMPILE_TEST && !MACH_STM32F429
+	depends on OF
+	default MACH_STM32F429
+	select PINCTRL_STM32
+
+endif
diff --git a/drivers/pinctrl/stm32/Makefile b/drivers/pinctrl/stm32/Makefile
new file mode 100644
index 0000000..fc17d42
--- /dev/null
+++ b/drivers/pinctrl/stm32/Makefile
@@ -0,0 +1,5 @@
+# Core
+obj-$(CONFIG_PINCTRL_STM32) += pinctrl-stm32.o
+
+# SoC Drivers
+obj-$(CONFIG_PINCTRL_STM32F429)	+= pinctrl-stm32f429.o
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c
new file mode 100644
index 0000000..9e8bc8f
--- /dev/null
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -0,0 +1,832 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author:  Maxime Coquelin <mcoquelin.stm32 at gmail.com>
+ * License terms:  GNU General Public License (GPL), version 2
+ *
+ * Heavily based on Mediatek's pinctrl driver
+ */
+#include <linux/clk.h>
+#include <linux/gpio.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/pinctrl/machine.h>
+#include <linux/pinctrl/pinconf.h>
+#include <linux/pinctrl/pinconf-generic.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/pinctrl/pinmux.h>
+#include <linux/platform_device.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+
+#include "../core.h"
+#include "../pinconf.h"
+#include "../pinctrl-utils.h"
+#include "pinctrl-stm32.h"
+
+#define STM32_GPIO_MODER	0x00
+#define STM32_GPIO_TYPER	0x04
+#define STM32_GPIO_SPEEDR	0x08
+#define STM32_GPIO_PUPDR	0x0c
+#define STM32_GPIO_IDR		0x10
+#define STM32_GPIO_ODR		0x14
+#define STM32_GPIO_BSRR		0x18
+#define STM32_GPIO_LCKR		0x1c
+#define STM32_GPIO_AFRL		0x20
+#define STM32_GPIO_AFRH		0x24
+
+#define STM32_GPIO_PINS_PER_BANK 16
+
+#define gpio_range_to_bank(chip) \
+		container_of(chip, struct stm32_gpio_bank, range)
+
+#define gpio_chip_to_bank(chip) \
+		container_of(chip, struct stm32_gpio_bank, gpio_chip)
+
+static const char * const stm32_gpio_functions[] = {
+	"gpio", "af0", "af1",
+	"af2", "af3", "af4",
+	"af5", "af6", "af7",
+	"af8", "af9", "af10",
+	"af11", "af12", "af13",
+	"af14", "af15", "analog",
+};
+
+struct stm32_pinctrl_group {
+	const char *name;
+	unsigned long config;
+	unsigned pin;
+};
+
+struct stm32_gpio_bank {
+	void __iomem *base;
+	struct clk *clk;
+	spinlock_t lock;
+	struct gpio_chip gpio_chip;
+	struct pinctrl_gpio_range range;
+};
+
+struct stm32_pinctrl {
+	struct device *dev;
+	struct pinctrl_dev *pctl_dev;
+	struct pinctrl_desc pctl_desc;
+	struct stm32_pinctrl_group *groups;
+	unsigned ngroups;
+	const char **grp_names;
+	struct stm32_gpio_bank *banks;
+	unsigned nbanks;
+	const struct stm32_pinctrl_match_data *match_data;
+};
+
+static inline int stm32_gpio_pin(int gpio)
+{
+	return gpio % STM32_GPIO_PINS_PER_BANK;
+}
+
+static inline u32 stm32_gpio_get_mode(u32 function)
+{
+	switch (function) {
+	case STM32_PIN_GPIO:
+		return 0;
+	case STM32_PIN_AF(0) ... STM32_PIN_AF(15):
+		return 2;
+	case STM32_PIN_ANALOG:
+		return 3;
+	}
+
+	return 0;
+}
+
+static inline u32 stm32_gpio_get_alt(u32 function)
+{
+	switch (function) {
+	case STM32_PIN_GPIO:
+		return 0;
+	case STM32_PIN_AF(0) ... STM32_PIN_AF(15):
+		return function - 1;
+	case STM32_PIN_ANALOG:
+		return 0;
+	}
+
+	return 0;
+}
+
+/* GPIO functions */
+
+static inline void __stm32_gpio_set(struct stm32_gpio_bank *bank,
+	unsigned offset, int value)
+{
+	if (!value)
+		offset += STM32_GPIO_PINS_PER_BANK;
+
+	clk_enable(bank->clk);
+
+	writel_relaxed(BIT(offset), bank->base + STM32_GPIO_BSRR);
+
+	clk_disable(bank->clk);
+}
+
+static int stm32_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+	return pinctrl_request_gpio(chip->base + offset);
+}
+
+static void stm32_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+	pinctrl_free_gpio(chip->base + offset);
+}
+
+static int stm32_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+	struct stm32_gpio_bank *bank = gpio_chip_to_bank(chip);
+	int ret;
+
+	clk_enable(bank->clk);
+
+	ret = !!(readl_relaxed(bank->base + STM32_GPIO_IDR) & BIT(offset));
+
+	clk_disable(bank->clk);
+
+	return ret;
+}
+
+static void stm32_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+	struct stm32_gpio_bank *bank = gpio_chip_to_bank(chip);
+
+	__stm32_gpio_set(bank, offset, value);
+}
+
+static int stm32_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+	return pinctrl_gpio_direction_input(chip->base + offset);
+}
+
+static int stm32_gpio_direction_output(struct gpio_chip *chip,
+	unsigned offset, int value)
+{
+	struct stm32_gpio_bank *bank = gpio_chip_to_bank(chip);
+
+	__stm32_gpio_set(bank, offset, value);
+	pinctrl_gpio_direction_output(chip->base + offset);
+
+	return 0;
+}
+
+static struct gpio_chip stm32_gpio_template = {
+	.request		= stm32_gpio_request,
+	.free			= stm32_gpio_free,
+	.get			= stm32_gpio_get,
+	.set			= stm32_gpio_set,
+	.direction_input	= stm32_gpio_direction_input,
+	.direction_output	= stm32_gpio_direction_output,
+};
+
+/* Pinctrl functions */
+
+static struct stm32_pinctrl_group *
+stm32_pctrl_find_group_by_pin(struct stm32_pinctrl *pctl, u32 pin)
+{
+	int i;
+
+	for (i = 0; i < pctl->ngroups; i++) {
+		struct stm32_pinctrl_group *grp = pctl->groups + i;
+
+		if (grp->pin == pin)
+			return grp;
+	}
+
+	return NULL;
+}
+
+static bool stm32_pctrl_is_function_valid(struct stm32_pinctrl *pctl,
+		u32 pin_num, u32 fnum)
+{
+	int i;
+
+	for (i = 0; i < pctl->match_data->npins; i++) {
+		const struct stm32_desc_pin *pin = pctl->match_data->pins + i;
+		const struct stm32_desc_function *func = pin->functions;
+
+		if (pin->pin.number != pin_num)
+			continue;
+
+		while (func && func->name) {
+			if (func->num == fnum)
+				return true;
+			func++;
+		}
+
+		break;
+	}
+
+	return false;
+}
+
+static int stm32_pctrl_dt_node_to_map_func(struct stm32_pinctrl *pctl,
+		u32 pin, u32 fnum, struct stm32_pinctrl_group *grp,
+		struct pinctrl_map **map, unsigned *reserved_maps,
+		unsigned *num_maps)
+{
+	if (*num_maps == *reserved_maps)
+		return -ENOSPC;
+
+	(*map)[*num_maps].type = PIN_MAP_TYPE_MUX_GROUP;
+	(*map)[*num_maps].data.mux.group = grp->name;
+
+	if (!stm32_pctrl_is_function_valid(pctl, pin, fnum)) {
+		dev_err(pctl->dev, "invalid function %d on pin %d .\n",
+				fnum, pin);
+		return -EINVAL;
+	}
+
+	(*map)[*num_maps].data.mux.function = stm32_gpio_functions[fnum];
+	(*num_maps)++;
+
+	return 0;
+}
+
+static int stm32_pctrl_dt_subnode_to_map(struct pinctrl_dev *pctldev,
+				      struct device_node *node,
+				      struct pinctrl_map **map,
+				      unsigned *reserved_maps,
+				      unsigned *num_maps)
+{
+	struct stm32_pinctrl *pctl;
+	struct stm32_pinctrl_group *grp;
+	struct property *pins;
+	u32 pinfunc, pin, func;
+	unsigned long *configs;
+	unsigned int num_configs;
+	bool has_config = 0;
+	unsigned reserve = 0;
+	int num_pins, num_funcs, maps_per_pin, i, err;
+
+	pctl = pinctrl_dev_get_drvdata(pctldev);
+
+	pins = of_find_property(node, "pinmux", NULL);
+	if (!pins) {
+		dev_err(pctl->dev, "missing pins property in node %s .\n",
+				node->name);
+		return -EINVAL;
+	}
+
+	err = pinconf_generic_parse_dt_config(node, pctldev, &configs,
+		&num_configs);
+	if (err)
+		return err;
+
+	if (num_configs)
+		has_config = 1;
+
+	num_pins = pins->length / sizeof(u32);
+	num_funcs = num_pins;
+	maps_per_pin = 0;
+	if (num_funcs)
+		maps_per_pin++;
+	if (has_config && num_pins >= 1)
+		maps_per_pin++;
+
+	if (!num_pins || !maps_per_pin)
+		return -EINVAL;
+
+	reserve = num_pins * maps_per_pin;
+
+	err = pinctrl_utils_reserve_map(pctldev, map,
+			reserved_maps, num_maps, reserve);
+	if (err)
+		return err;
+
+	for (i = 0; i < num_pins; i++) {
+		err = of_property_read_u32_index(node, "pinmux",
+				i, &pinfunc);
+		if (err)
+			return err;
+
+		pin = STM32_GET_PIN_NO(pinfunc);
+		func = STM32_GET_PIN_FUNC(pinfunc);
+
+		if (pin >= pctl->match_data->npins) {
+			dev_err(pctl->dev, "invalid pin number.\n");
+			return -EINVAL;
+		}
+
+		if (!stm32_pctrl_is_function_valid(pctl, pin, func)) {
+			dev_err(pctl->dev, "invalid function.\n");
+			return -EINVAL;
+		}
+
+		grp = stm32_pctrl_find_group_by_pin(pctl, pin);
+		if (!grp) {
+			dev_err(pctl->dev, "unable to match pin %d to group\n",
+					pin);
+			return -EINVAL;
+		}
+
+		err = stm32_pctrl_dt_node_to_map_func(pctl, pin, func, grp, map,
+				reserved_maps, num_maps);
+		if (err)
+			return err;
+
+		if (has_config) {
+			err = pinctrl_utils_add_map_configs(pctldev, map,
+					reserved_maps, num_maps, grp->name,
+					configs, num_configs,
+					PIN_MAP_TYPE_CONFIGS_GROUP);
+			if (err)
+				return err;
+		}
+	}
+
+	return 0;
+}
+
+static int stm32_pctrl_dt_node_to_map(struct pinctrl_dev *pctldev,
+				 struct device_node *np_config,
+				 struct pinctrl_map **map, unsigned *num_maps)
+{
+	struct device_node *np;
+	unsigned reserved_maps;
+	int ret;
+
+	*map = NULL;
+	*num_maps = 0;
+	reserved_maps = 0;
+
+	for_each_child_of_node(np_config, np) {
+		ret = stm32_pctrl_dt_subnode_to_map(pctldev, np, map,
+				&reserved_maps, num_maps);
+		if (ret < 0) {
+			pinctrl_utils_dt_free_map(pctldev, *map, *num_maps);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static int stm32_pctrl_get_groups_count(struct pinctrl_dev *pctldev)
+{
+	struct stm32_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
+
+	return pctl->ngroups;
+}
+
+static const char *stm32_pctrl_get_group_name(struct pinctrl_dev *pctldev,
+					      unsigned group)
+{
+	struct stm32_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
+
+	return pctl->groups[group].name;
+}
+
+static int stm32_pctrl_get_group_pins(struct pinctrl_dev *pctldev,
+				      unsigned group,
+				      const unsigned **pins,
+				      unsigned *num_pins)
+{
+	struct stm32_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
+
+	*pins = (unsigned *)&pctl->groups[group].pin;
+	*num_pins = 1;
+
+	return 0;
+}
+
+static const struct pinctrl_ops stm32_pctrl_ops = {
+	.dt_node_to_map		= stm32_pctrl_dt_node_to_map,
+	.dt_free_map		= pinctrl_utils_dt_free_map,
+	.get_groups_count	= stm32_pctrl_get_groups_count,
+	.get_group_name		= stm32_pctrl_get_group_name,
+	.get_group_pins		= stm32_pctrl_get_group_pins,
+};
+
+
+/* Pinmux functions */
+
+static int stm32_pmx_get_funcs_cnt(struct pinctrl_dev *pctldev)
+{
+	return ARRAY_SIZE(stm32_gpio_functions);
+}
+
+static const char *stm32_pmx_get_func_name(struct pinctrl_dev *pctldev,
+					   unsigned selector)
+{
+	return stm32_gpio_functions[selector];
+}
+
+static int stm32_pmx_get_func_groups(struct pinctrl_dev *pctldev,
+				     unsigned function,
+				     const char * const **groups,
+				     unsigned * const num_groups)
+{
+	struct stm32_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
+
+	*groups = pctl->grp_names;
+	*num_groups = pctl->ngroups;
+
+	return 0;
+}
+
+static void stm32_pmx_set_mode(struct stm32_gpio_bank *bank,
+		int pin, u32 mode, u32 alt)
+{
+	u32 val;
+	int alt_shift = (pin % 8) * 4;
+	int alt_offset = STM32_GPIO_AFRL + (pin / 8) * 4;
+	unsigned long flags;
+
+	clk_enable(bank->clk);
+	spin_lock_irqsave(&bank->lock, flags);
+
+	val = readl_relaxed(bank->base + alt_offset);
+	val &= ~GENMASK(alt_shift + 3, alt_shift);
+	val |= (alt << alt_shift);
+	writel_relaxed(val, bank->base + alt_offset);
+
+	val = readl_relaxed(bank->base + STM32_GPIO_MODER);
+	val &= ~GENMASK(pin * 2 + 1, pin * 2);
+	val |= mode << (pin * 2);
+	writel_relaxed(val, bank->base + STM32_GPIO_MODER);
+
+	spin_unlock_irqrestore(&bank->lock, flags);
+	clk_disable(bank->clk);
+}
+
+static int stm32_pmx_set_mux(struct pinctrl_dev *pctldev,
+			    unsigned function,
+			    unsigned group)
+{
+	bool ret;
+	struct stm32_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
+	struct stm32_pinctrl_group *g = pctl->groups + group;
+	struct pinctrl_gpio_range *range;
+	struct stm32_gpio_bank *bank;
+	u32 mode, alt;
+	int pin;
+
+	ret = stm32_pctrl_is_function_valid(pctl, g->pin, function);
+	if (!ret) {
+		dev_err(pctl->dev, "invalid function %d on group %d .\n",
+				function, group);
+		return -EINVAL;
+	}
+
+	range = pinctrl_find_gpio_range_from_pin(pctldev, g->pin);
+	bank = gpio_range_to_bank(range);
+	pin = stm32_gpio_pin(g->pin);
+
+	mode = stm32_gpio_get_mode(function);
+	alt = stm32_gpio_get_alt(function);
+
+	stm32_pmx_set_mode(bank, pin, mode, alt);
+
+	return 0;
+}
+
+static int stm32_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
+			struct pinctrl_gpio_range *range, unsigned gpio,
+			bool input)
+{
+	struct stm32_gpio_bank *bank = gpio_range_to_bank(range);
+	int pin = stm32_gpio_pin(gpio);
+
+	stm32_pmx_set_mode(bank, pin, !input, 0);
+
+	return 0;
+}
+
+static const struct pinmux_ops stm32_pmx_ops = {
+	.get_functions_count	= stm32_pmx_get_funcs_cnt,
+	.get_function_name	= stm32_pmx_get_func_name,
+	.get_function_groups	= stm32_pmx_get_func_groups,
+	.set_mux		= stm32_pmx_set_mux,
+	.gpio_set_direction	= stm32_pmx_gpio_set_direction,
+};
+
+/* Pinconf functions */
+
+static void stm32_pconf_set_driving(struct stm32_gpio_bank *bank,
+	unsigned offset, u32 drive)
+{
+	unsigned long flags;
+	u32 val;
+
+	clk_enable(bank->clk);
+	spin_lock_irqsave(&bank->lock, flags);
+
+	val = readl_relaxed(bank->base + STM32_GPIO_TYPER);
+	val &= ~BIT(offset);
+	val |= drive << offset;
+	writel_relaxed(val, bank->base + STM32_GPIO_TYPER);
+
+	spin_unlock_irqrestore(&bank->lock, flags);
+	clk_disable(bank->clk);
+}
+
+static void stm32_pconf_set_speed(struct stm32_gpio_bank *bank,
+	unsigned offset, u32 speed)
+{
+	unsigned long flags;
+	u32 val;
+
+	clk_enable(bank->clk);
+	spin_lock_irqsave(&bank->lock, flags);
+
+	val = readl_relaxed(bank->base + STM32_GPIO_SPEEDR);
+	val &= ~GENMASK(offset * 2 + 1, offset * 2);
+	val |= speed << (offset * 2);
+	writel_relaxed(val, bank->base + STM32_GPIO_SPEEDR);
+
+	spin_unlock_irqrestore(&bank->lock, flags);
+	clk_disable(bank->clk);
+}
+
+static void stm32_pconf_set_bias(struct stm32_gpio_bank *bank,
+	unsigned offset, u32 bias)
+{
+	unsigned long flags;
+	u32 val;
+
+	clk_enable(bank->clk);
+	spin_lock_irqsave(&bank->lock, flags);
+
+	val = readl_relaxed(bank->base + STM32_GPIO_PUPDR);
+	val &= ~GENMASK(offset * 2 + 1, offset * 2);
+	val |= bias << (offset * 2);
+	writel_relaxed(val, bank->base + STM32_GPIO_PUPDR);
+
+	spin_unlock_irqrestore(&bank->lock, flags);
+	clk_disable(bank->clk);
+}
+
+static int stm32_pconf_parse_conf(struct pinctrl_dev *pctldev,
+		unsigned int pin, enum pin_config_param param,
+		enum pin_config_param arg)
+{
+	struct pinctrl_gpio_range *range;
+	struct stm32_gpio_bank *bank;
+	int offset, ret = 0;
+
+	range = pinctrl_find_gpio_range_from_pin(pctldev, pin);
+	bank = gpio_range_to_bank(range);
+	offset = stm32_gpio_pin(pin);
+
+	switch (param) {
+	case PIN_CONFIG_DRIVE_PUSH_PULL:
+		stm32_pconf_set_driving(bank, offset, 0);
+		break;
+	case PIN_CONFIG_DRIVE_OPEN_DRAIN:
+		stm32_pconf_set_driving(bank, offset, 1);
+		break;
+	case PIN_CONFIG_SLEW_RATE:
+		stm32_pconf_set_speed(bank, offset, arg);
+		break;
+	case PIN_CONFIG_BIAS_DISABLE:
+		stm32_pconf_set_bias(bank, offset, 0);
+		break;
+	case PIN_CONFIG_BIAS_PULL_UP:
+		stm32_pconf_set_bias(bank, offset, 1);
+		break;
+	case PIN_CONFIG_BIAS_PULL_DOWN:
+		stm32_pconf_set_bias(bank, offset, 2);
+		break;
+	case PIN_CONFIG_OUTPUT:
+		__stm32_gpio_set(bank, offset, arg);
+		ret = stm32_pmx_gpio_set_direction(pctldev, NULL, pin, false);
+		break;
+	default:
+		ret = -EINVAL;
+	}
+
+	return ret;
+}
+
+static int stm32_pconf_group_get(struct pinctrl_dev *pctldev,
+				 unsigned group,
+				 unsigned long *config)
+{
+	struct stm32_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
+
+	*config = pctl->groups[group].config;
+
+	return 0;
+}
+
+static int stm32_pconf_group_set(struct pinctrl_dev *pctldev, unsigned group,
+				 unsigned long *configs, unsigned num_configs)
+{
+	struct stm32_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
+	struct stm32_pinctrl_group *g = &pctl->groups[group];
+	int i, ret;
+
+	for (i = 0; i < num_configs; i++) {
+		ret = stm32_pconf_parse_conf(pctldev, g->pin,
+			pinconf_to_config_param(configs[i]),
+			pinconf_to_config_argument(configs[i]));
+		if (ret < 0)
+			return ret;
+
+		g->config = configs[i];
+	}
+
+	return 0;
+}
+
+static const struct pinconf_ops stm32_pconf_ops = {
+	.pin_config_group_get	= stm32_pconf_group_get,
+	.pin_config_group_set	= stm32_pconf_group_set,
+};
+
+static int stm32_gpiolib_register_bank(struct stm32_pinctrl *pctl,
+	struct device_node *np)
+{
+	int bank_nr = pctl->nbanks;
+	struct stm32_gpio_bank *bank = &pctl->banks[bank_nr];
+	struct pinctrl_gpio_range *range = &bank->range;
+	struct device *dev = pctl->dev;
+	struct resource res;
+	struct reset_control *rstc;
+	int err, npins;
+
+	rstc = of_reset_control_get(np, NULL);
+	if (!IS_ERR(rstc))
+		reset_control_deassert(rstc);
+
+	if (of_address_to_resource(np, 0, &res))
+		return -ENODEV;
+
+	bank->base = devm_ioremap_resource(dev, &res);
+	if (IS_ERR(bank->base))
+		return PTR_ERR(bank->base);
+
+	bank->clk = of_clk_get_by_name(np, NULL);
+	if (IS_ERR(bank->clk)) {
+		dev_err(dev, "failed to get clk (%ld)\n", PTR_ERR(bank->clk));
+		return PTR_ERR(bank->clk);
+	}
+
+	err = clk_prepare(bank->clk);
+	if (err) {
+		dev_err(dev, "failed to prepare clk (%d)\n", err);
+		return err;
+	}
+
+	npins = pctl->match_data->npins;
+	npins -= bank_nr * STM32_GPIO_PINS_PER_BANK;
+	if (npins < 0)
+		return -EINVAL;
+	else if (npins > STM32_GPIO_PINS_PER_BANK)
+		npins = STM32_GPIO_PINS_PER_BANK;
+
+	bank->gpio_chip = stm32_gpio_template;
+	bank->gpio_chip.base = bank_nr * STM32_GPIO_PINS_PER_BANK;
+	bank->gpio_chip.ngpio = npins;
+	bank->gpio_chip.of_node = np;
+	bank->gpio_chip.parent = dev;
+	spin_lock_init(&bank->lock);
+
+	of_property_read_string(np, "st,bank-name", &range->name);
+	bank->gpio_chip.label = range->name;
+
+	range->id = bank_nr;
+	range->pin_base = range->base = range->id * STM32_GPIO_PINS_PER_BANK;
+	range->npins = bank->gpio_chip.ngpio;
+	range->gc = &bank->gpio_chip;
+	err  = gpiochip_add(&bank->gpio_chip);
+	if (err) {
+		dev_err(dev, "Failed to add gpiochip(%d)!\n", bank_nr);
+		return err;
+	}
+
+	dev_info(dev, "%s bank added\n", range->name);
+	return 0;
+}
+
+static int stm32_pctrl_build_state(struct platform_device *pdev)
+{
+	struct stm32_pinctrl *pctl = platform_get_drvdata(pdev);
+	int i;
+
+	pctl->ngroups = pctl->match_data->npins;
+
+	/* Allocate groups */
+	pctl->groups = devm_kcalloc(&pdev->dev, pctl->ngroups,
+				    sizeof(*pctl->groups), GFP_KERNEL);
+	if (!pctl->groups)
+		return -ENOMEM;
+
+	/* We assume that one pin is one group, use pin name as group name. */
+	pctl->grp_names = devm_kcalloc(&pdev->dev, pctl->ngroups,
+				       sizeof(*pctl->grp_names), GFP_KERNEL);
+	if (!pctl->grp_names)
+		return -ENOMEM;
+
+	for (i = 0; i < pctl->match_data->npins; i++) {
+		const struct stm32_desc_pin *pin = pctl->match_data->pins + i;
+		struct stm32_pinctrl_group *group = pctl->groups + i;
+
+		group->name = pin->pin.name;
+		group->pin = pin->pin.number;
+
+		pctl->grp_names[i] = pin->pin.name;
+	}
+
+	return 0;
+}
+
+int stm32_pctl_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *child;
+	const struct of_device_id *match;
+	struct device *dev = &pdev->dev;
+	struct stm32_pinctrl *pctl;
+	struct pinctrl_pin_desc *pins;
+	int i, ret, banks = 0;
+
+	if (!np)
+		return -EINVAL;
+
+	match = of_match_device(dev->driver->of_match_table, dev);
+	if (!match || !match->data)
+		return -EINVAL;
+
+	if (!of_find_property(np, "pins-are-numbered", NULL)) {
+		dev_err(dev, "only support pins-are-numbered format\n");
+		return -EINVAL;
+	}
+
+	pctl = devm_kzalloc(dev, sizeof(*pctl), GFP_KERNEL);
+	if (!pctl)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, pctl);
+
+	pctl->dev = dev;
+	pctl->match_data = match->data;
+	ret = stm32_pctrl_build_state(pdev);
+	if (ret) {
+		dev_err(dev, "build state failed: %d\n", ret);
+		return -EINVAL;
+	}
+
+	for_each_child_of_node(np, child)
+		if (of_property_read_bool(child, "gpio-controller"))
+			banks++;
+
+	if (!banks) {
+		dev_err(dev, "at least one GPIO bank is required\n");
+		return -EINVAL;
+	}
+
+	pctl->banks = devm_kcalloc(dev, banks, sizeof(*pctl->banks),
+			GFP_KERNEL);
+	if (!pctl->banks)
+		return -ENOMEM;
+
+	for_each_child_of_node(np, child) {
+		if (of_property_read_bool(child, "gpio-controller")) {
+			ret = stm32_gpiolib_register_bank(pctl, child);
+			if (ret)
+				return ret;
+
+			pctl->nbanks++;
+		}
+	}
+
+	pins = devm_kcalloc(&pdev->dev, pctl->match_data->npins, sizeof(*pins),
+			    GFP_KERNEL);
+	if (!pins)
+		return -ENOMEM;
+
+	for (i = 0; i < pctl->match_data->npins; i++)
+		pins[i] = pctl->match_data->pins[i].pin;
+
+	pctl->pctl_desc.name = dev_name(&pdev->dev);
+	pctl->pctl_desc.owner = THIS_MODULE;
+	pctl->pctl_desc.pins = pins;
+	pctl->pctl_desc.npins = pctl->match_data->npins;
+	pctl->pctl_desc.confops = &stm32_pconf_ops;
+	pctl->pctl_desc.pctlops = &stm32_pctrl_ops;
+	pctl->pctl_desc.pmxops = &stm32_pmx_ops;
+	pctl->dev = &pdev->dev;
+
+	pctl->pctl_dev = pinctrl_register(&pctl->pctl_desc, &pdev->dev, pctl);
+	if (!pctl->pctl_dev) {
+		dev_err(&pdev->dev, "Failed pinctrl registration\n");
+		return -EINVAL;
+	}
+
+	for (i = 0; i < pctl->nbanks; i++)
+		pinctrl_add_gpio_range(pctl->pctl_dev, &pctl->banks[i].range);
+
+	dev_info(dev, "Pinctrl STM32 initialized\n");
+
+	return 0;
+}
+
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.h b/drivers/pinctrl/stm32/pinctrl-stm32.h
new file mode 100644
index 0000000..35ebc94
--- /dev/null
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.h
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author:  Maxime Coquelin <mcoquelin.stm32 at gmail.com>
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+#ifndef __PINCTRL_STM32_H
+#define __PINCTRL_STM32_H
+
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/pinctrl/pinconf-generic.h>
+
+#define STM32_PIN_NO(x) ((x) << 8)
+#define STM32_GET_PIN_NO(x) ((x) >> 8)
+#define STM32_GET_PIN_FUNC(x) ((x) & 0xff)
+
+#define STM32_PIN_GPIO		0
+#define STM32_PIN_AF(x)		((x) + 1)
+#define STM32_PIN_ANALOG	(STM32_PIN_AF(15) + 1)
+
+struct stm32_desc_function {
+	const char *name;
+	const unsigned char num;
+};
+
+struct stm32_desc_pin {
+	struct pinctrl_pin_desc pin;
+	const struct stm32_desc_function *functions;
+};
+
+#define STM32_PIN(_pin, ...)					\
+	{							\
+		.pin = _pin,					\
+		.functions = (struct stm32_desc_function[]){	\
+			__VA_ARGS__, { } },			\
+	}
+
+#define STM32_FUNCTION(_num, _name)		\
+	{							\
+		.num = _num,					\
+		.name = _name,					\
+	}
+
+struct stm32_pinctrl_match_data {
+	const struct stm32_desc_pin *pins;
+	const unsigned int npins;
+};
+
+int stm32_pctl_probe(struct platform_device *pdev);
+
+#endif /* __PINCTRL_STM32_H */
+
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32f429.c b/drivers/pinctrl/stm32/pinctrl-stm32f429.c
new file mode 100644
index 0000000..f34016b
--- /dev/null
+++ b/drivers/pinctrl/stm32/pinctrl-stm32f429.c
@@ -0,0 +1,1598 @@
+/*
+ * Copyright (C) Maxime Coquelin 2015
+ * Author:  Maxime Coquelin <mcoquelin.stm32 at gmail.com>
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#include "pinctrl-stm32.h"
+
+static const struct stm32_desc_pin stm32f429_pins[] = {
+	STM32_PIN(
+		PINCTRL_PIN(0, "PA0"),
+		STM32_FUNCTION(0, "GPIOA0"),
+		STM32_FUNCTION(2, "TIM2_CH1 TIM2_ETR"),
+		STM32_FUNCTION(3, "TIM5_CH1"),
+		STM32_FUNCTION(4, "TIM8_ETR"),
+		STM32_FUNCTION(8, "USART2_CTS"),
+		STM32_FUNCTION(9, "UART4_TX"),
+		STM32_FUNCTION(12, "ETH_MII_CRS"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(1, "PA1"),
+		STM32_FUNCTION(0, "GPIOA1"),
+		STM32_FUNCTION(2, "TIM2_CH2"),
+		STM32_FUNCTION(3, "TIM5_CH2"),
+		STM32_FUNCTION(8, "USART2_RTS"),
+		STM32_FUNCTION(9, "UART4_RX"),
+		STM32_FUNCTION(12, "ETH_MII_RX_CLK ETH_RMII_REF_CLK"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(2, "PA2"),
+		STM32_FUNCTION(0, "GPIOA2"),
+		STM32_FUNCTION(2, "TIM2_CH3"),
+		STM32_FUNCTION(3, "TIM5_CH3"),
+		STM32_FUNCTION(4, "TIM9_CH1"),
+		STM32_FUNCTION(8, "USART2_TX"),
+		STM32_FUNCTION(12, "ETH_MDIO"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(3, "PA3"),
+		STM32_FUNCTION(0, "GPIOA3"),
+		STM32_FUNCTION(2, "TIM2_CH4"),
+		STM32_FUNCTION(3, "TIM5_CH4"),
+		STM32_FUNCTION(4, "TIM9_CH2"),
+		STM32_FUNCTION(8, "USART2_RX"),
+		STM32_FUNCTION(11, "OTG_HS_ULPI_D0"),
+		STM32_FUNCTION(12, "ETH_MII_COL"),
+		STM32_FUNCTION(15, "LCD_B5"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(4, "PA4"),
+		STM32_FUNCTION(0, "GPIOA4"),
+		STM32_FUNCTION(6, "SPI1_NSS"),
+		STM32_FUNCTION(7, "SPI3_NSS I2S3_WS"),
+		STM32_FUNCTION(8, "USART2_CK"),
+		STM32_FUNCTION(13, "OTG_HS_SOF"),
+		STM32_FUNCTION(14, "DCMI_HSYNC"),
+		STM32_FUNCTION(15, "LCD_VSYNC"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(5, "PA5"),
+		STM32_FUNCTION(0, "GPIOA5"),
+		STM32_FUNCTION(2, "TIM2_CH1 TIM2_ETR"),
+		STM32_FUNCTION(4, "TIM8_CH1N"),
+		STM32_FUNCTION(6, "SPI1_SCK"),
+		STM32_FUNCTION(11, "OTG_HS_ULPI_CK"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(6, "PA6"),
+		STM32_FUNCTION(0, "GPIOA6"),
+		STM32_FUNCTION(2, "TIM1_BKIN"),
+		STM32_FUNCTION(3, "TIM3_CH1"),
+		STM32_FUNCTION(4, "TIM8_BKIN"),
+		STM32_FUNCTION(6, "SPI1_MISO"),
+		STM32_FUNCTION(10, "TIM13_CH1"),
+		STM32_FUNCTION(14, "DCMI_PIXCLK"),
+		STM32_FUNCTION(15, "LCD_G2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(7, "PA7"),
+		STM32_FUNCTION(0, "GPIOA7"),
+		STM32_FUNCTION(2, "TIM1_CH1N"),
+		STM32_FUNCTION(3, "TIM3_CH2"),
+		STM32_FUNCTION(4, "TIM8_CH1N"),
+		STM32_FUNCTION(6, "SPI1_MOSI"),
+		STM32_FUNCTION(10, "TIM14_CH1"),
+		STM32_FUNCTION(12, "ETH_MII_RX_DV ETH_RMII_CRS_DV"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(8, "PA8"),
+		STM32_FUNCTION(0, "GPIOA8"),
+		STM32_FUNCTION(1, "MCO1"),
+		STM32_FUNCTION(2, "TIM1_CH1"),
+		STM32_FUNCTION(5, "I2C3_SCL"),
+		STM32_FUNCTION(8, "USART1_CK"),
+		STM32_FUNCTION(11, "OTG_FS_SOF"),
+		STM32_FUNCTION(15, "LCD_R6"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(9, "PA9"),
+		STM32_FUNCTION(0, "GPIOA9"),
+		STM32_FUNCTION(2, "TIM1_CH2"),
+		STM32_FUNCTION(5, "I2C3_SMBA"),
+		STM32_FUNCTION(8, "USART1_TX"),
+		STM32_FUNCTION(14, "DCMI_D0"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(10, "PA10"),
+		STM32_FUNCTION(0, "GPIOA10"),
+		STM32_FUNCTION(2, "TIM1_CH3"),
+		STM32_FUNCTION(8, "USART1_RX"),
+		STM32_FUNCTION(11, "OTG_FS_ID"),
+		STM32_FUNCTION(14, "DCMI_D1"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(11, "PA11"),
+		STM32_FUNCTION(0, "GPIOA11"),
+		STM32_FUNCTION(2, "TIM1_CH4"),
+		STM32_FUNCTION(8, "USART1_CTS"),
+		STM32_FUNCTION(10, "CAN1_RX"),
+		STM32_FUNCTION(11, "OTG_FS_DM"),
+		STM32_FUNCTION(15, "LCD_R4"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(12, "PA12"),
+		STM32_FUNCTION(0, "GPIOA12"),
+		STM32_FUNCTION(2, "TIM1_ETR"),
+		STM32_FUNCTION(8, "USART1_RTS"),
+		STM32_FUNCTION(10, "CAN1_TX"),
+		STM32_FUNCTION(11, "OTG_FS_DP"),
+		STM32_FUNCTION(15, "LCD_R5"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(13, "PA13"),
+		STM32_FUNCTION(0, "GPIOA13"),
+		STM32_FUNCTION(1, "JTMS SWDIO"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(14, "PA14"),
+		STM32_FUNCTION(0, "GPIOA14"),
+		STM32_FUNCTION(1, "JTCK SWCLK"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(15, "PA15"),
+		STM32_FUNCTION(0, "GPIOA15"),
+		STM32_FUNCTION(1, "JTDI"),
+		STM32_FUNCTION(2, "TIM2_CH1 TIM2_ETR"),
+		STM32_FUNCTION(6, "SPI1_NSS"),
+		STM32_FUNCTION(7, "SPI3_NSS I2S3_WS"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(16, "PB0"),
+		STM32_FUNCTION(0, "GPIOB0"),
+		STM32_FUNCTION(2, "TIM1_CH2N"),
+		STM32_FUNCTION(3, "TIM3_CH3"),
+		STM32_FUNCTION(4, "TIM8_CH2N"),
+		STM32_FUNCTION(10, "LCD_R3"),
+		STM32_FUNCTION(11, "OTG_HS_ULPI_D1"),
+		STM32_FUNCTION(12, "ETH_MII_RXD2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(17, "PB1"),
+		STM32_FUNCTION(0, "GPIOB1"),
+		STM32_FUNCTION(2, "TIM1_CH3N"),
+		STM32_FUNCTION(3, "TIM3_CH4"),
+		STM32_FUNCTION(4, "TIM8_CH3N"),
+		STM32_FUNCTION(10, "LCD_R6"),
+		STM32_FUNCTION(11, "OTG_HS_ULPI_D2"),
+		STM32_FUNCTION(12, "ETH_MII_RXD3"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(18, "PB2"),
+		STM32_FUNCTION(0, "GPIOB2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(19, "PB3"),
+		STM32_FUNCTION(0, "GPIOB3"),
+		STM32_FUNCTION(1, "JTDO TRACESWO"),
+		STM32_FUNCTION(2, "TIM2_CH2"),
+		STM32_FUNCTION(6, "SPI1_SCK"),
+		STM32_FUNCTION(7, "SPI3_SCK I2S3_CK"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(20, "PB4"),
+		STM32_FUNCTION(0, "GPIOB4"),
+		STM32_FUNCTION(1, "NJTRST"),
+		STM32_FUNCTION(3, "TIM3_CH1"),
+		STM32_FUNCTION(6, "SPI1_MISO"),
+		STM32_FUNCTION(7, "SPI3_MISO"),
+		STM32_FUNCTION(8, "I2S3EXT_SD"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(21, "PB5"),
+		STM32_FUNCTION(0, "GPIOB5"),
+		STM32_FUNCTION(3, "TIM3_CH2"),
+		STM32_FUNCTION(5, "I2C1_SMBA"),
+		STM32_FUNCTION(6, "SPI1_MOSI"),
+		STM32_FUNCTION(7, "SPI3_MOSI I2S3_SD"),
+		STM32_FUNCTION(10, "CAN2_RX"),
+		STM32_FUNCTION(11, "OTG_HS_ULPI_D7"),
+		STM32_FUNCTION(12, "ETH_PPS_OUT"),
+		STM32_FUNCTION(13, "FMC_SDCKE1"),
+		STM32_FUNCTION(14, "DCMI_D10"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(22, "PB6"),
+		STM32_FUNCTION(0, "GPIOB6"),
+		STM32_FUNCTION(3, "TIM4_CH1"),
+		STM32_FUNCTION(5, "I2C1_SCL"),
+		STM32_FUNCTION(8, "USART1_TX"),
+		STM32_FUNCTION(10, "CAN2_TX"),
+		STM32_FUNCTION(13, "FMC_SDNE1"),
+		STM32_FUNCTION(14, "DCMI_D5"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(23, "PB7"),
+		STM32_FUNCTION(0, "GPIOB7"),
+		STM32_FUNCTION(3, "TIM4_CH2"),
+		STM32_FUNCTION(5, "I2C1_SDA"),
+		STM32_FUNCTION(8, "USART1_RX"),
+		STM32_FUNCTION(13, "FMC_NL"),
+		STM32_FUNCTION(14, "DCMI_VSYNC"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(24, "PB8"),
+		STM32_FUNCTION(0, "GPIOB8"),
+		STM32_FUNCTION(3, "TIM4_CH3"),
+		STM32_FUNCTION(4, "TIM10_CH1"),
+		STM32_FUNCTION(5, "I2C1_SCL"),
+		STM32_FUNCTION(10, "CAN1_RX"),
+		STM32_FUNCTION(12, "ETH_MII_TXD3"),
+		STM32_FUNCTION(13, "SDIO_D4"),
+		STM32_FUNCTION(14, "DCMI_D6"),
+		STM32_FUNCTION(15, "LCD_B6"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(25, "PB9"),
+		STM32_FUNCTION(0, "GPIOB9"),
+		STM32_FUNCTION(3, "TIM4_CH4"),
+		STM32_FUNCTION(4, "TIM11_CH1"),
+		STM32_FUNCTION(5, "I2C1_SDA"),
+		STM32_FUNCTION(6, "SPI2_NSS I2S2_WS"),
+		STM32_FUNCTION(10, "CAN1_TX"),
+		STM32_FUNCTION(13, "SDIO_D5"),
+		STM32_FUNCTION(14, "DCMI_D7"),
+		STM32_FUNCTION(15, "LCD_B7"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(26, "PB10"),
+		STM32_FUNCTION(0, "GPIOB10"),
+		STM32_FUNCTION(2, "TIM2_CH3"),
+		STM32_FUNCTION(5, "I2C2_SCL"),
+		STM32_FUNCTION(6, "SPI2_SCK I2S2_CK"),
+		STM32_FUNCTION(8, "USART3_TX"),
+		STM32_FUNCTION(11, "OTG_HS_ULPI_D3"),
+		STM32_FUNCTION(12, "ETH_MII_RX_ER"),
+		STM32_FUNCTION(15, "LCD_G4"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(27, "PB11"),
+		STM32_FUNCTION(0, "GPIOB11"),
+		STM32_FUNCTION(2, "TIM2_CH4"),
+		STM32_FUNCTION(5, "I2C2_SDA"),
+		STM32_FUNCTION(8, "USART3_RX"),
+		STM32_FUNCTION(11, "OTG_HS_ULPI_D4"),
+		STM32_FUNCTION(12, "ETH_MII_TX_EN ETH_RMII_TX_EN"),
+		STM32_FUNCTION(15, "LCD_G5"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(28, "PB12"),
+		STM32_FUNCTION(0, "GPIOB12"),
+		STM32_FUNCTION(2, "TIM1_BKIN"),
+		STM32_FUNCTION(5, "I2C2_SMBA"),
+		STM32_FUNCTION(6, "SPI2_NSS I2S2_WS"),
+		STM32_FUNCTION(8, "USART3_CK"),
+		STM32_FUNCTION(10, "CAN2_RX"),
+		STM32_FUNCTION(11, "OTG_HS_ULPI_D5"),
+		STM32_FUNCTION(12, "ETH_MII_TXD0 ETH_RMII_TXD0"),
+		STM32_FUNCTION(13, "OTG_HS_ID"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(29, "PB13"),
+		STM32_FUNCTION(0, "GPIOB13"),
+		STM32_FUNCTION(2, "TIM1_CH1N"),
+		STM32_FUNCTION(6, "SPI2_SCK I2S2_CK"),
+		STM32_FUNCTION(8, "USART3_CTS"),
+		STM32_FUNCTION(10, "CAN2_TX"),
+		STM32_FUNCTION(11, "OTG_HS_ULPI_D6"),
+		STM32_FUNCTION(12, "ETH_MII_TXD1 ETH_RMII_TXD1"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(30, "PB14"),
+		STM32_FUNCTION(0, "GPIOB14"),
+		STM32_FUNCTION(2, "TIM1_CH2N"),
+		STM32_FUNCTION(4, "TIM8_CH2N"),
+		STM32_FUNCTION(6, "SPI2_MISO"),
+		STM32_FUNCTION(7, "I2S2EXT_SD"),
+		STM32_FUNCTION(8, "USART3_RTS"),
+		STM32_FUNCTION(10, "TIM12_CH1"),
+		STM32_FUNCTION(13, "OTG_HS_DM"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(31, "PB15"),
+		STM32_FUNCTION(0, "GPIOB15"),
+		STM32_FUNCTION(1, "RTC_REFIN"),
+		STM32_FUNCTION(2, "TIM1_CH3N"),
+		STM32_FUNCTION(4, "TIM8_CH3N"),
+		STM32_FUNCTION(6, "SPI2_MOSI I2S2_SD"),
+		STM32_FUNCTION(10, "TIM12_CH2"),
+		STM32_FUNCTION(13, "OTG_HS_DP"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(32, "PC0"),
+		STM32_FUNCTION(0, "GPIOC0"),
+		STM32_FUNCTION(11, "OTG_HS_ULPI_STP"),
+		STM32_FUNCTION(13, "FMC_SDNWE"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(33, "PC1"),
+		STM32_FUNCTION(0, "GPIOC1"),
+		STM32_FUNCTION(12, "ETH_MDC"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(34, "PC2"),
+		STM32_FUNCTION(0, "GPIOC2"),
+		STM32_FUNCTION(6, "SPI2_MISO"),
+		STM32_FUNCTION(7, "I2S2EXT_SD"),
+		STM32_FUNCTION(11, "OTG_HS_ULPI_DIR"),
+		STM32_FUNCTION(12, "ETH_MII_TXD2"),
+		STM32_FUNCTION(13, "FMC_SDNE0"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(35, "PC3"),
+		STM32_FUNCTION(0, "GPIOC3"),
+		STM32_FUNCTION(6, "SPI2_MOSI I2S2_SD"),
+		STM32_FUNCTION(11, "OTG_HS_ULPI_NXT"),
+		STM32_FUNCTION(12, "ETH_MII_TX_CLK"),
+		STM32_FUNCTION(13, "FMC_SDCKE0"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(36, "PC4"),
+		STM32_FUNCTION(0, "GPIOC4"),
+		STM32_FUNCTION(12, "ETH_MII_RXD0 ETH_RMII_RXD0"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(37, "PC5"),
+		STM32_FUNCTION(0, "GPIOC5"),
+		STM32_FUNCTION(12, "ETH_MII_RXD1 ETH_RMII_RXD1"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(38, "PC6"),
+		STM32_FUNCTION(0, "GPIOC6"),
+		STM32_FUNCTION(3, "TIM3_CH1"),
+		STM32_FUNCTION(4, "TIM8_CH1"),
+		STM32_FUNCTION(6, "I2S2_MCK"),
+		STM32_FUNCTION(9, "USART6_TX"),
+		STM32_FUNCTION(13, "SDIO_D6"),
+		STM32_FUNCTION(14, "DCMI_D0"),
+		STM32_FUNCTION(15, "LCD_HSYNC"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(39, "PC7"),
+		STM32_FUNCTION(0, "GPIOC7"),
+		STM32_FUNCTION(3, "TIM3_CH2"),
+		STM32_FUNCTION(4, "TIM8_CH2"),
+		STM32_FUNCTION(7, "I2S3_MCK"),
+		STM32_FUNCTION(9, "USART6_RX"),
+		STM32_FUNCTION(13, "SDIO_D7"),
+		STM32_FUNCTION(14, "DCMI_D1"),
+		STM32_FUNCTION(15, "LCD_G6"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(40, "PC8"),
+		STM32_FUNCTION(0, "GPIOC8"),
+		STM32_FUNCTION(3, "TIM3_CH3"),
+		STM32_FUNCTION(4, "TIM8_CH3"),
+		STM32_FUNCTION(9, "USART6_CK"),
+		STM32_FUNCTION(13, "SDIO_D0"),
+		STM32_FUNCTION(14, "DCMI_D2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(41, "PC9"),
+		STM32_FUNCTION(0, "GPIOC9"),
+		STM32_FUNCTION(1, "MCO2"),
+		STM32_FUNCTION(3, "TIM3_CH4"),
+		STM32_FUNCTION(4, "TIM8_CH4"),
+		STM32_FUNCTION(5, "I2C3_SDA"),
+		STM32_FUNCTION(6, "I2S_CKIN"),
+		STM32_FUNCTION(13, "SDIO_D1"),
+		STM32_FUNCTION(14, "DCMI_D3"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(42, "PC10"),
+		STM32_FUNCTION(0, "GPIOC10"),
+		STM32_FUNCTION(7, "SPI3_SCK I2S3_CK"),
+		STM32_FUNCTION(8, "USART3_TX"),
+		STM32_FUNCTION(9, "UART4_TX"),
+		STM32_FUNCTION(13, "SDIO_D2"),
+		STM32_FUNCTION(14, "DCMI_D8"),
+		STM32_FUNCTION(15, "LCD_R2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(43, "PC11"),
+		STM32_FUNCTION(0, "GPIOC11"),
+		STM32_FUNCTION(6, "I2S3EXT_SD"),
+		STM32_FUNCTION(7, "SPI3_MISO"),
+		STM32_FUNCTION(8, "USART3_RX"),
+		STM32_FUNCTION(9, "UART4_RX"),
+		STM32_FUNCTION(13, "SDIO_D3"),
+		STM32_FUNCTION(14, "DCMI_D4"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(44, "PC12"),
+		STM32_FUNCTION(0, "GPIOC12"),
+		STM32_FUNCTION(7, "SPI3_MOSI I2S3_SD"),
+		STM32_FUNCTION(8, "USART3_CK"),
+		STM32_FUNCTION(9, "UART5_TX"),
+		STM32_FUNCTION(13, "SDIO_CK"),
+		STM32_FUNCTION(14, "DCMI_D9"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(45, "PC13"),
+		STM32_FUNCTION(0, "GPIOC13"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(46, "PC14"),
+		STM32_FUNCTION(0, "GPIOC14"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(47, "PC15"),
+		STM32_FUNCTION(0, "GPIOC15"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(48, "PD0"),
+		STM32_FUNCTION(0, "GPIOD0"),
+		STM32_FUNCTION(10, "CAN1_RX"),
+		STM32_FUNCTION(13, "FMC_D2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(49, "PD1"),
+		STM32_FUNCTION(0, "GPIOD1"),
+		STM32_FUNCTION(10, "CAN1_TX"),
+		STM32_FUNCTION(13, "FMC_D3"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(50, "PD2"),
+		STM32_FUNCTION(0, "GPIOD2"),
+		STM32_FUNCTION(3, "TIM3_ETR"),
+		STM32_FUNCTION(9, "UART5_RX"),
+		STM32_FUNCTION(13, "SDIO_CMD"),
+		STM32_FUNCTION(14, "DCMI_D11"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(51, "PD3"),
+		STM32_FUNCTION(0, "GPIOD3"),
+		STM32_FUNCTION(6, "SPI2_SCK I2S2_CK"),
+		STM32_FUNCTION(8, "USART2_CTS"),
+		STM32_FUNCTION(13, "FMC_CLK"),
+		STM32_FUNCTION(14, "DCMI_D5"),
+		STM32_FUNCTION(15, "LCD_G7"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(52, "PD4"),
+		STM32_FUNCTION(0, "GPIOD4"),
+		STM32_FUNCTION(8, "USART2_RTS"),
+		STM32_FUNCTION(13, "FMC_NOE"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(53, "PD5"),
+		STM32_FUNCTION(0, "GPIOD5"),
+		STM32_FUNCTION(8, "USART2_TX"),
+		STM32_FUNCTION(13, "FMC_NWE"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(54, "PD6"),
+		STM32_FUNCTION(0, "GPIOD6"),
+		STM32_FUNCTION(6, "SPI3_MOSI I2S3_SD"),
+		STM32_FUNCTION(7, "SAI1_SD_A"),
+		STM32_FUNCTION(8, "USART2_RX"),
+		STM32_FUNCTION(13, "FMC_NWAIT"),
+		STM32_FUNCTION(14, "DCMI_D10"),
+		STM32_FUNCTION(15, "LCD_B2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(55, "PD7"),
+		STM32_FUNCTION(0, "GPIOD7"),
+		STM32_FUNCTION(8, "USART2_CK"),
+		STM32_FUNCTION(13, "FMC_NE1 FMC_NCE2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(56, "PD8"),
+		STM32_FUNCTION(0, "GPIOD8"),
+		STM32_FUNCTION(8, "USART3_TX"),
+		STM32_FUNCTION(13, "FMC_D13"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(57, "PD9"),
+		STM32_FUNCTION(0, "GPIOD9"),
+		STM32_FUNCTION(8, "USART3_RX"),
+		STM32_FUNCTION(13, "FMC_D14"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(58, "PD10"),
+		STM32_FUNCTION(0, "GPIOD10"),
+		STM32_FUNCTION(8, "USART3_CK"),
+		STM32_FUNCTION(13, "FMC_D15"),
+		STM32_FUNCTION(15, "LCD_B3"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(59, "PD11"),
+		STM32_FUNCTION(0, "GPIOD11"),
+		STM32_FUNCTION(8, "USART3_CTS"),
+		STM32_FUNCTION(13, "FMC_A16"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(60, "PD12"),
+		STM32_FUNCTION(0, "GPIOD12"),
+		STM32_FUNCTION(3, "TIM4_CH1"),
+		STM32_FUNCTION(8, "USART3_RTS"),
+		STM32_FUNCTION(13, "FMC_A17"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(61, "PD13"),
+		STM32_FUNCTION(0, "GPIOD13"),
+		STM32_FUNCTION(3, "TIM4_CH2"),
+		STM32_FUNCTION(13, "FMC_A18"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(62, "PD14"),
+		STM32_FUNCTION(0, "GPIOD14"),
+		STM32_FUNCTION(3, "TIM4_CH3"),
+		STM32_FUNCTION(13, "FMC_D0"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(63, "PD15"),
+		STM32_FUNCTION(0, "GPIOD15"),
+		STM32_FUNCTION(3, "TIM4_CH4"),
+		STM32_FUNCTION(13, "FMC_D1"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(64, "PE0"),
+		STM32_FUNCTION(0, "GPIOE0"),
+		STM32_FUNCTION(3, "TIM4_ETR"),
+		STM32_FUNCTION(9, "UART8_RX"),
+		STM32_FUNCTION(13, "FMC_NBL0"),
+		STM32_FUNCTION(14, "DCMI_D2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(65, "PE1"),
+		STM32_FUNCTION(0, "GPIOE1"),
+		STM32_FUNCTION(9, "UART8_TX"),
+		STM32_FUNCTION(13, "FMC_NBL1"),
+		STM32_FUNCTION(14, "DCMI_D3"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(66, "PE2"),
+		STM32_FUNCTION(0, "GPIOE2"),
+		STM32_FUNCTION(1, "TRACECLK"),
+		STM32_FUNCTION(6, "SPI4_SCK"),
+		STM32_FUNCTION(7, "SAI1_MCLK_A"),
+		STM32_FUNCTION(12, "ETH_MII_TXD3"),
+		STM32_FUNCTION(13, "FMC_A23"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(67, "PE3"),
+		STM32_FUNCTION(0, "GPIOE3"),
+		STM32_FUNCTION(1, "TRACED0"),
+		STM32_FUNCTION(7, "SAI1_SD_B"),
+		STM32_FUNCTION(13, "FMC_A19"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(68, "PE4"),
+		STM32_FUNCTION(0, "GPIOE4"),
+		STM32_FUNCTION(1, "TRACED1"),
+		STM32_FUNCTION(6, "SPI4_NSS"),
+		STM32_FUNCTION(7, "SAI1_FS_A"),
+		STM32_FUNCTION(13, "FMC_A20"),
+		STM32_FUNCTION(14, "DCMI_D4"),
+		STM32_FUNCTION(15, "LCD_B0"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(69, "PE5"),
+		STM32_FUNCTION(0, "GPIOE5"),
+		STM32_FUNCTION(1, "TRACED2"),
+		STM32_FUNCTION(4, "TIM9_CH1"),
+		STM32_FUNCTION(6, "SPI4_MISO"),
+		STM32_FUNCTION(7, "SAI1_SCK_A"),
+		STM32_FUNCTION(13, "FMC_A21"),
+		STM32_FUNCTION(14, "DCMI_D6"),
+		STM32_FUNCTION(15, "LCD_G0"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(70, "PE6"),
+		STM32_FUNCTION(0, "GPIOE6"),
+		STM32_FUNCTION(1, "TRACED3"),
+		STM32_FUNCTION(4, "TIM9_CH2"),
+		STM32_FUNCTION(6, "SPI4_MOSI"),
+		STM32_FUNCTION(7, "SAI1_SD_A"),
+		STM32_FUNCTION(13, "FMC_A22"),
+		STM32_FUNCTION(14, "DCMI_D7"),
+		STM32_FUNCTION(15, "LCD_G1"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(71, "PE7"),
+		STM32_FUNCTION(0, "GPIOE7"),
+		STM32_FUNCTION(2, "TIM1_ETR"),
+		STM32_FUNCTION(9, "UART7_RX"),
+		STM32_FUNCTION(13, "FMC_D4"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(72, "PE8"),
+		STM32_FUNCTION(0, "GPIOE8"),
+		STM32_FUNCTION(2, "TIM1_CH1N"),
+		STM32_FUNCTION(9, "UART7_TX"),
+		STM32_FUNCTION(13, "FMC_D5"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(73, "PE9"),
+		STM32_FUNCTION(0, "GPIOE9"),
+		STM32_FUNCTION(2, "TIM1_CH1"),
+		STM32_FUNCTION(13, "FMC_D6"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(74, "PE10"),
+		STM32_FUNCTION(0, "GPIOE10"),
+		STM32_FUNCTION(2, "TIM1_CH2N"),
+		STM32_FUNCTION(13, "FMC_D7"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(75, "PE11"),
+		STM32_FUNCTION(0, "GPIOE11"),
+		STM32_FUNCTION(2, "TIM1_CH2"),
+		STM32_FUNCTION(6, "SPI4_NSS"),
+		STM32_FUNCTION(13, "FMC_D8"),
+		STM32_FUNCTION(15, "LCD_G3"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(76, "PE12"),
+		STM32_FUNCTION(0, "GPIOE12"),
+		STM32_FUNCTION(2, "TIM1_CH3N"),
+		STM32_FUNCTION(6, "SPI4_SCK"),
+		STM32_FUNCTION(13, "FMC_D9"),
+		STM32_FUNCTION(15, "LCD_B4"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(77, "PE13"),
+		STM32_FUNCTION(0, "GPIOE13"),
+		STM32_FUNCTION(2, "TIM1_CH3"),
+		STM32_FUNCTION(6, "SPI4_MISO"),
+		STM32_FUNCTION(13, "FMC_D10"),
+		STM32_FUNCTION(15, "LCD_DE"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(78, "PE14"),
+		STM32_FUNCTION(0, "GPIOE14"),
+		STM32_FUNCTION(2, "TIM1_CH4"),
+		STM32_FUNCTION(6, "SPI4_MOSI"),
+		STM32_FUNCTION(13, "FMC_D11"),
+		STM32_FUNCTION(15, "LCD_CLK"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(79, "PE15"),
+		STM32_FUNCTION(0, "GPIOE15"),
+		STM32_FUNCTION(2, "TIM1_BKIN"),
+		STM32_FUNCTION(13, "FMC_D12"),
+		STM32_FUNCTION(15, "LCD_R7"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(80, "PF0"),
+		STM32_FUNCTION(0, "GPIOF0"),
+		STM32_FUNCTION(5, "I2C2_SDA"),
+		STM32_FUNCTION(13, "FMC_A0"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(81, "PF1"),
+		STM32_FUNCTION(0, "GPIOF1"),
+		STM32_FUNCTION(5, "I2C2_SCL"),
+		STM32_FUNCTION(13, "FMC_A1"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(82, "PF2"),
+		STM32_FUNCTION(0, "GPIOF2"),
+		STM32_FUNCTION(5, "I2C2_SMBA"),
+		STM32_FUNCTION(13, "FMC_A2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(83, "PF3"),
+		STM32_FUNCTION(0, "GPIOF3"),
+		STM32_FUNCTION(13, "FMC_A3"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(84, "PF4"),
+		STM32_FUNCTION(0, "GPIOF4"),
+		STM32_FUNCTION(13, "FMC_A4"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(85, "PF5"),
+		STM32_FUNCTION(0, "GPIOF5"),
+		STM32_FUNCTION(13, "FMC_A5"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(86, "PF6"),
+		STM32_FUNCTION(0, "GPIOF6"),
+		STM32_FUNCTION(4, "TIM10_CH1"),
+		STM32_FUNCTION(6, "SPI5_NSS"),
+		STM32_FUNCTION(7, "SAI1_SD_B"),
+		STM32_FUNCTION(9, "UART7_RX"),
+		STM32_FUNCTION(13, "FMC_NIORD"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(87, "PF7"),
+		STM32_FUNCTION(0, "GPIOF7"),
+		STM32_FUNCTION(4, "TIM11_CH1"),
+		STM32_FUNCTION(6, "SPI5_SCK"),
+		STM32_FUNCTION(7, "SAI1_MCLK_B"),
+		STM32_FUNCTION(9, "UART7_TX"),
+		STM32_FUNCTION(13, "FMC_NREG"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(88, "PF8"),
+		STM32_FUNCTION(0, "GPIOF8"),
+		STM32_FUNCTION(6, "SPI5_MISO"),
+		STM32_FUNCTION(7, "SAI1_SCK_B"),
+		STM32_FUNCTION(10, "TIM13_CH1"),
+		STM32_FUNCTION(13, "FMC_NIOWR"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(89, "PF9"),
+		STM32_FUNCTION(0, "GPIOF9"),
+		STM32_FUNCTION(6, "SPI5_MOSI"),
+		STM32_FUNCTION(7, "SAI1_FS_B"),
+		STM32_FUNCTION(10, "TIM14_CH1"),
+		STM32_FUNCTION(13, "FMC_CD"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(90, "PF10"),
+		STM32_FUNCTION(0, "GPIOF10"),
+		STM32_FUNCTION(13, "FMC_INTR"),
+		STM32_FUNCTION(14, "DCMI_D11"),
+		STM32_FUNCTION(15, "LCD_DE"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(91, "PF11"),
+		STM32_FUNCTION(0, "GPIOF11"),
+		STM32_FUNCTION(6, "SPI5_MOSI"),
+		STM32_FUNCTION(13, "FMC_SDNRAS"),
+		STM32_FUNCTION(14, "DCMI_D12"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(92, "PF12"),
+		STM32_FUNCTION(0, "GPIOF12"),
+		STM32_FUNCTION(13, "FMC_A6"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(93, "PF13"),
+		STM32_FUNCTION(0, "GPIOF13"),
+		STM32_FUNCTION(13, "FMC_A7"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(94, "PF14"),
+		STM32_FUNCTION(0, "GPIOF14"),
+		STM32_FUNCTION(13, "FMC_A8"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(95, "PF15"),
+		STM32_FUNCTION(0, "GPIOF15"),
+		STM32_FUNCTION(13, "FMC_A9"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(96, "PG0"),
+		STM32_FUNCTION(0, "GPIOG0"),
+		STM32_FUNCTION(13, "FMC_A10"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(97, "PG1"),
+		STM32_FUNCTION(0, "GPIOG1"),
+		STM32_FUNCTION(13, "FMC_A11"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(98, "PG2"),
+		STM32_FUNCTION(0, "GPIOG2"),
+		STM32_FUNCTION(13, "FMC_A12"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(99, "PG3"),
+		STM32_FUNCTION(0, "GPIOG3"),
+		STM32_FUNCTION(13, "FMC_A13"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(100, "PG4"),
+		STM32_FUNCTION(0, "GPIOG4"),
+		STM32_FUNCTION(13, "FMC_A14 FMC_BA0"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(101, "PG5"),
+		STM32_FUNCTION(0, "GPIOG5"),
+		STM32_FUNCTION(13, "FMC_A15 FMC_BA1"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(102, "PG6"),
+		STM32_FUNCTION(0, "GPIOG6"),
+		STM32_FUNCTION(13, "FMC_INT2"),
+		STM32_FUNCTION(14, "DCMI_D12"),
+		STM32_FUNCTION(15, "LCD_R7"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(103, "PG7"),
+		STM32_FUNCTION(0, "GPIOG7"),
+		STM32_FUNCTION(9, "USART6_CK"),
+		STM32_FUNCTION(13, "FMC_INT3"),
+		STM32_FUNCTION(14, "DCMI_D13"),
+		STM32_FUNCTION(15, "LCD_CLK"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(104, "PG8"),
+		STM32_FUNCTION(0, "GPIOG8"),
+		STM32_FUNCTION(6, "SPI6_NSS"),
+		STM32_FUNCTION(9, "USART6_RTS"),
+		STM32_FUNCTION(12, "ETH_PPS_OUT"),
+		STM32_FUNCTION(13, "FMC_SDCLK"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(105, "PG9"),
+		STM32_FUNCTION(0, "GPIOG9"),
+		STM32_FUNCTION(9, "USART6_RX"),
+		STM32_FUNCTION(13, "FMC_NE2 FMC_NCE3"),
+		STM32_FUNCTION(14, "DCMI_VSYNC"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(106, "PG10"),
+		STM32_FUNCTION(0, "GPIOG10"),
+		STM32_FUNCTION(10, "LCD_G3"),
+		STM32_FUNCTION(13, "FMC_NCE4_1 FMC_NE3"),
+		STM32_FUNCTION(14, "DCMI_D2"),
+		STM32_FUNCTION(15, "LCD_B2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(107, "PG11"),
+		STM32_FUNCTION(0, "GPIOG11"),
+		STM32_FUNCTION(12, "ETH_MII_TX_EN ETH_RMII_TX_EN"),
+		STM32_FUNCTION(13, "FMC_NCE4_2"),
+		STM32_FUNCTION(14, "DCMI_D3"),
+		STM32_FUNCTION(15, "LCD_B3"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(108, "PG12"),
+		STM32_FUNCTION(0, "GPIOG12"),
+		STM32_FUNCTION(6, "SPI6_MISO"),
+		STM32_FUNCTION(9, "USART6_RTS"),
+		STM32_FUNCTION(10, "LCD_B4"),
+		STM32_FUNCTION(13, "FMC_NE4"),
+		STM32_FUNCTION(15, "LCD_B1"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(109, "PG13"),
+		STM32_FUNCTION(0, "GPIOG13"),
+		STM32_FUNCTION(6, "SPI6_SCK"),
+		STM32_FUNCTION(9, "USART6_CTS"),
+		STM32_FUNCTION(12, "ETH_MII_TXD0 ETH_RMII_TXD0"),
+		STM32_FUNCTION(13, "FMC_A24"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(110, "PG14"),
+		STM32_FUNCTION(0, "GPIOG14"),
+		STM32_FUNCTION(6, "SPI6_MOSI"),
+		STM32_FUNCTION(9, "USART6_TX"),
+		STM32_FUNCTION(12, "ETH_MII_TXD1 ETH_RMII_TXD1"),
+		STM32_FUNCTION(13, "FMC_A25"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(111, "PG15"),
+		STM32_FUNCTION(0, "GPIOG15"),
+		STM32_FUNCTION(9, "USART6_CTS"),
+		STM32_FUNCTION(13, "FMC_SDNCAS"),
+		STM32_FUNCTION(14, "DCMI_D13"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(112, "PH0"),
+		STM32_FUNCTION(0, "GPIOH0"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(113, "PH1"),
+		STM32_FUNCTION(0, "GPIOH1"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(114, "PH2"),
+		STM32_FUNCTION(0, "GPIOH2"),
+		STM32_FUNCTION(12, "ETH_MII_CRS"),
+		STM32_FUNCTION(13, "FMC_SDCKE0"),
+		STM32_FUNCTION(15, "LCD_R0"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(115, "PH3"),
+		STM32_FUNCTION(0, "GPIOH3"),
+		STM32_FUNCTION(12, "ETH_MII_COL"),
+		STM32_FUNCTION(13, "FMC_SDNE0"),
+		STM32_FUNCTION(15, "LCD_R1"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(116, "PH4"),
+		STM32_FUNCTION(0, "GPIOH4"),
+		STM32_FUNCTION(5, "I2C2_SCL"),
+		STM32_FUNCTION(11, "OTG_HS_ULPI_NXT"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(117, "PH5"),
+		STM32_FUNCTION(0, "GPIOH5"),
+		STM32_FUNCTION(5, "I2C2_SDA"),
+		STM32_FUNCTION(6, "SPI5_NSS"),
+		STM32_FUNCTION(13, "FMC_SDNWE"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(118, "PH6"),
+		STM32_FUNCTION(0, "GPIOH6"),
+		STM32_FUNCTION(5, "I2C2_SMBA"),
+		STM32_FUNCTION(6, "SPI5_SCK"),
+		STM32_FUNCTION(10, "TIM12_CH1"),
+		STM32_FUNCTION(12, "ETH_MII_RXD2"),
+		STM32_FUNCTION(13, "FMC_SDNE1"),
+		STM32_FUNCTION(14, "DCMI_D8"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(119, "PH7"),
+		STM32_FUNCTION(0, "GPIOH7"),
+		STM32_FUNCTION(5, "I2C3_SCL"),
+		STM32_FUNCTION(6, "SPI5_MISO"),
+		STM32_FUNCTION(12, "ETH_MII_RXD3"),
+		STM32_FUNCTION(13, "FMC_SDCKE1"),
+		STM32_FUNCTION(14, "DCMI_D9"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(120, "PH8"),
+		STM32_FUNCTION(0, "GPIOH8"),
+		STM32_FUNCTION(5, "I2C3_SDA"),
+		STM32_FUNCTION(13, "FMC_D16"),
+		STM32_FUNCTION(14, "DCMI_HSYNC"),
+		STM32_FUNCTION(15, "LCD_R2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(121, "PH9"),
+		STM32_FUNCTION(0, "GPIOH9"),
+		STM32_FUNCTION(5, "I2C3_SMBA"),
+		STM32_FUNCTION(10, "TIM12_CH2"),
+		STM32_FUNCTION(13, "FMC_D17"),
+		STM32_FUNCTION(14, "DCMI_D0"),
+		STM32_FUNCTION(15, "LCD_R3"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(122, "PH10"),
+		STM32_FUNCTION(0, "GPIOH10"),
+		STM32_FUNCTION(3, "TIM5_CH1"),
+		STM32_FUNCTION(13, "FMC_D18"),
+		STM32_FUNCTION(14, "DCMI_D1"),
+		STM32_FUNCTION(15, "LCD_R4"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(123, "PH11"),
+		STM32_FUNCTION(0, "GPIOH11"),
+		STM32_FUNCTION(3, "TIM5_CH2"),
+		STM32_FUNCTION(13, "FMC_D19"),
+		STM32_FUNCTION(14, "DCMI_D2"),
+		STM32_FUNCTION(15, "LCD_R5"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(124, "PH12"),
+		STM32_FUNCTION(0, "GPIOH12"),
+		STM32_FUNCTION(3, "TIM5_CH3"),
+		STM32_FUNCTION(13, "FMC_D20"),
+		STM32_FUNCTION(14, "DCMI_D3"),
+		STM32_FUNCTION(15, "LCD_R6"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(125, "PH13"),
+		STM32_FUNCTION(0, "GPIOH13"),
+		STM32_FUNCTION(4, "TIM8_CH1N"),
+		STM32_FUNCTION(10, "CAN1_TX"),
+		STM32_FUNCTION(13, "FMC_D21"),
+		STM32_FUNCTION(15, "LCD_G2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(126, "PH14"),
+		STM32_FUNCTION(0, "GPIOH14"),
+		STM32_FUNCTION(4, "TIM8_CH2N"),
+		STM32_FUNCTION(13, "FMC_D22"),
+		STM32_FUNCTION(14, "DCMI_D4"),
+		STM32_FUNCTION(15, "LCD_G3"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(127, "PH15"),
+		STM32_FUNCTION(0, "GPIOH15"),
+		STM32_FUNCTION(4, "TIM8_CH3N"),
+		STM32_FUNCTION(13, "FMC_D23"),
+		STM32_FUNCTION(14, "DCMI_D11"),
+		STM32_FUNCTION(15, "LCD_G4"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(128, "PI0"),
+		STM32_FUNCTION(0, "GPIOI0"),
+		STM32_FUNCTION(3, "TIM5_CH4"),
+		STM32_FUNCTION(6, "SPI2_NSS I2S2_WS"),
+		STM32_FUNCTION(13, "FMC_D24"),
+		STM32_FUNCTION(14, "DCMI_D13"),
+		STM32_FUNCTION(15, "LCD_G5"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(129, "PI1"),
+		STM32_FUNCTION(0, "GPIOI1"),
+		STM32_FUNCTION(6, "SPI2_SCK I2S2_CK"),
+		STM32_FUNCTION(13, "FMC_D25"),
+		STM32_FUNCTION(14, "DCMI_D8"),
+		STM32_FUNCTION(15, "LCD_G6"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(130, "PI2"),
+		STM32_FUNCTION(0, "GPIOI2"),
+		STM32_FUNCTION(4, "TIM8_CH4"),
+		STM32_FUNCTION(6, "SPI2_MISO"),
+		STM32_FUNCTION(7, "I2S2EXT_SD"),
+		STM32_FUNCTION(13, "FMC_D26"),
+		STM32_FUNCTION(14, "DCMI_D9"),
+		STM32_FUNCTION(15, "LCD_G7"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(131, "PI3"),
+		STM32_FUNCTION(0, "GPIOI3"),
+		STM32_FUNCTION(4, "TIM8_ETR"),
+		STM32_FUNCTION(6, "SPI2_MOSI I2S2_SD"),
+		STM32_FUNCTION(13, "FMC_D27"),
+		STM32_FUNCTION(14, "DCMI_D10"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(132, "PI4"),
+		STM32_FUNCTION(0, "GPIOI4"),
+		STM32_FUNCTION(4, "TIM8_BKIN"),
+		STM32_FUNCTION(13, "FMC_NBL2"),
+		STM32_FUNCTION(14, "DCMI_D5"),
+		STM32_FUNCTION(15, "LCD_B4"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(133, "PI5"),
+		STM32_FUNCTION(0, "GPIOI5"),
+		STM32_FUNCTION(4, "TIM8_CH1"),
+		STM32_FUNCTION(13, "FMC_NBL3"),
+		STM32_FUNCTION(14, "DCMI_VSYNC"),
+		STM32_FUNCTION(15, "LCD_B5"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(134, "PI6"),
+		STM32_FUNCTION(0, "GPIOI6"),
+		STM32_FUNCTION(4, "TIM8_CH2"),
+		STM32_FUNCTION(13, "FMC_D28"),
+		STM32_FUNCTION(14, "DCMI_D6"),
+		STM32_FUNCTION(15, "LCD_B6"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(135, "PI7"),
+		STM32_FUNCTION(0, "GPIOI7"),
+		STM32_FUNCTION(4, "TIM8_CH3"),
+		STM32_FUNCTION(13, "FMC_D29"),
+		STM32_FUNCTION(14, "DCMI_D7"),
+		STM32_FUNCTION(15, "LCD_B7"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(136, "PI8"),
+		STM32_FUNCTION(0, "GPIOI8"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(137, "PI9"),
+		STM32_FUNCTION(0, "GPIOI9"),
+		STM32_FUNCTION(10, "CAN1_RX"),
+		STM32_FUNCTION(13, "FMC_D30"),
+		STM32_FUNCTION(15, "LCD_VSYNC"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(138, "PI10"),
+		STM32_FUNCTION(0, "GPIOI10"),
+		STM32_FUNCTION(12, "ETH_MII_RX_ER"),
+		STM32_FUNCTION(13, "FMC_D31"),
+		STM32_FUNCTION(15, "LCD_HSYNC"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(139, "PI11"),
+		STM32_FUNCTION(0, "GPIOI11"),
+		STM32_FUNCTION(11, "OTG_HS_ULPI_DIR"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(140, "PI12"),
+		STM32_FUNCTION(0, "GPIOI12"),
+		STM32_FUNCTION(15, "LCD_HSYNC"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(141, "PI13"),
+		STM32_FUNCTION(0, "GPIOI13"),
+		STM32_FUNCTION(15, "LCD_VSYNC"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(142, "PI14"),
+		STM32_FUNCTION(0, "GPIOI14"),
+		STM32_FUNCTION(15, "LCD_CLK"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(143, "PI15"),
+		STM32_FUNCTION(0, "GPIOI15"),
+		STM32_FUNCTION(15, "LCD_R0"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(144, "PJ0"),
+		STM32_FUNCTION(0, "GPIOJ0"),
+		STM32_FUNCTION(15, "LCD_R1"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(145, "PJ1"),
+		STM32_FUNCTION(0, "GPIOJ1"),
+		STM32_FUNCTION(15, "LCD_R2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(146, "PJ2"),
+		STM32_FUNCTION(0, "GPIOJ2"),
+		STM32_FUNCTION(15, "LCD_R3"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(147, "PJ3"),
+		STM32_FUNCTION(0, "GPIOJ3"),
+		STM32_FUNCTION(15, "LCD_R4"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(148, "PJ4"),
+		STM32_FUNCTION(0, "GPIOJ4"),
+		STM32_FUNCTION(15, "LCD_R5"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(149, "PJ5"),
+		STM32_FUNCTION(0, "GPIOJ5"),
+		STM32_FUNCTION(15, "LCD_R6"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(150, "PJ6"),
+		STM32_FUNCTION(0, "GPIOJ6"),
+		STM32_FUNCTION(15, "LCD_R7"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(151, "PJ7"),
+		STM32_FUNCTION(0, "GPIOJ7"),
+		STM32_FUNCTION(15, "LCD_G0"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(152, "PJ8"),
+		STM32_FUNCTION(0, "GPIOJ8"),
+		STM32_FUNCTION(15, "LCD_G1"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(153, "PJ9"),
+		STM32_FUNCTION(0, "GPIOJ9"),
+		STM32_FUNCTION(15, "LCD_G2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(154, "PJ10"),
+		STM32_FUNCTION(0, "GPIOJ10"),
+		STM32_FUNCTION(15, "LCD_G3"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(155, "PJ11"),
+		STM32_FUNCTION(0, "GPIOJ11"),
+		STM32_FUNCTION(15, "LCD_G4"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(156, "PJ12"),
+		STM32_FUNCTION(0, "GPIOJ12"),
+		STM32_FUNCTION(15, "LCD_B0"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(157, "PJ13"),
+		STM32_FUNCTION(0, "GPIOJ13"),
+		STM32_FUNCTION(15, "LCD_B1"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(158, "PJ14"),
+		STM32_FUNCTION(0, "GPIOJ14"),
+		STM32_FUNCTION(15, "LCD_B2"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(159, "PJ15"),
+		STM32_FUNCTION(0, "GPIOJ15"),
+		STM32_FUNCTION(15, "LCD_B3"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(160, "PK0"),
+		STM32_FUNCTION(0, "GPIOK0"),
+		STM32_FUNCTION(15, "LCD_G5"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(161, "PK1"),
+		STM32_FUNCTION(0, "GPIOK1"),
+		STM32_FUNCTION(15, "LCD_G6"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(162, "PK2"),
+		STM32_FUNCTION(0, "GPIOK2"),
+		STM32_FUNCTION(15, "LCD_G7"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(163, "PK3"),
+		STM32_FUNCTION(0, "GPIOK3"),
+		STM32_FUNCTION(15, "LCD_B4"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(164, "PK4"),
+		STM32_FUNCTION(0, "GPIOK4"),
+		STM32_FUNCTION(15, "LCD_B5"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(165, "PK5"),
+		STM32_FUNCTION(0, "GPIOK5"),
+		STM32_FUNCTION(15, "LCD_B6"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(166, "PK6"),
+		STM32_FUNCTION(0, "GPIOK6"),
+		STM32_FUNCTION(15, "LCD_B7"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+	STM32_PIN(
+		PINCTRL_PIN(167, "PK7"),
+		STM32_FUNCTION(0, "GPIOK7"),
+		STM32_FUNCTION(15, "LCD_DE"),
+		STM32_FUNCTION(16, "EVENTOUT"),
+		STM32_FUNCTION(17, "ANALOG")
+	),
+};
+
+static struct stm32_pinctrl_match_data stm32f429_match_data = {
+	.pins = stm32f429_pins,
+	.npins = ARRAY_SIZE(stm32f429_pins),
+};
+
+static const struct of_device_id stm32f429_pctrl_match[] = {
+	{
+		.compatible = "st,stm32f429-pinctrl",
+		.data = &stm32f429_match_data,
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, stm32f429_pctrl_match);
+
+static struct platform_driver stm32f429_pinctrl_driver = {
+	.probe = stm32_pctl_probe,
+	.driver = {
+		.name = "stm32f429-pinctrl",
+		.of_match_table = stm32f429_pctrl_match,
+	},
+};
+
+static int __init stm32f429_pinctrl_init(void)
+{
+	return platform_driver_register(&stm32f429_pinctrl_driver);
+}
+
+module_init(stm32f429_pinctrl_init);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("STM32F429 Pinctrl Driver");
+MODULE_AUTHOR("Maxime Coquelin <mcoquelin.stm32 at gmail.com>");
-- 
1.9.1



From gregory.clement at free-electrons.com  Wed Feb  3 03:13:40 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed, 03 Feb 2016 12:13:40 +0100
Subject: [PATCH 03/10] arm64: add Armada 3700 architecture entry
In-Reply-To: <4284367.sAeqrVzAbo@wuerfel> (Arnd Bergmann's message of "Wed, 03
 Feb 2016 10:11:18 +0100")
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <20160203142451.41381ff6@xhacker> <87k2mm5itx.fsf@free-electrons.com>
 <4284367.sAeqrVzAbo@wuerfel>
Message-ID: <8737ta59nf.fsf@free-electrons.com>

Hi Arnd,
 
 On mer., f?vr. 03 2016, Arnd Bergmann <arnd at arndb.de> wrote:

> On Wednesday 03 February 2016 08:55:22 Gregory CLEMENT wrote:
>> >> 
>> >> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>> >> index 21074f674bde..7da341f7b90d 100644
>> >> --- a/arch/arm64/Kconfig.platforms
>> >> +++ b/arch/arm64/Kconfig.platforms
>> >> @@ -1,5 +1,11 @@
>> >>  menu "Platform selection"
>> >>  
>> >> +config ARCH_ARMADA_3700
>> >
>> > Would it be better to use ARCH_MVEBU? IMHO, there will be more ARMv8 SoCs
>> > from our EBU, do we plan to add one CONFIG_ARMADA_yyzz for each SoC?
>> 
>> Not for each SoC but for each family, yes. As we did for the other mvebu
>> SoC families.
>> 
>
> We tend to use a little more general config strings for arm64 than we have
> for arm32. I think just using ARCH_MVEBU is fine here, no need to list
> the 3700 series separately.

OK, for the arm32 mvebu SoC, the CONFIG_ARMADA_ were barely used, and
CONFIG_ARCH_MVEBU is mostly use as a "depends on" and do not force
anything.

The only annoying point was with the irqchip, but thanks to the last
series sent by Thomas irq-armada-370-xp.c won't be inconditionnaly built
if CONFIG_ARCH_MVEBU is selected.

So OK I will use CONFIG_ARCH_MVEBU.

Thanks,

Gregory



> 	Arnd

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From mark.rutland at arm.com  Wed Feb  3 03:16:03 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 3 Feb 2016 11:16:03 +0000
Subject: [RFC PATCH] irq/mbigen:Fix the problem of IO remap for
 duplicated physical address in mbigen driver
In-Reply-To: <56B16698.6050509@huawei.com>
References: <1454327094-7848-1-git-send-email-majun258@huawei.com>
 <20160201115717.GD674@leverpostej> <56AF585E.6050005@huawei.com>
 <20160201132557.GG674@leverpostej> <56B08431.3000200@huawei.com>
 <20160202114340.GA28839@leverpostej> <56B16698.6050509@huawei.com>
Message-ID: <20160203111602.GA1234@leverpostej>

On Wed, Feb 03, 2016 at 10:31:52AM +0800, majun (F) wrote:
> 
> 
> ? 2016/2/2 19:43, Mark Rutland ??:
> > On Tue, Feb 02, 2016 at 06:25:53PM +0800, majun (F) wrote:
> >> To simplify the mbigen drvier,
> >> I didn't use the whole mbigen module as a mbgien device, but use
> >> the register collections(vector, trigger type,status etc.) corresponding
> >> to a peripheral device as a mbigen device.
> >> So, mbigen device is a logical conception or logical device.
> > 
> >>From the above, it sounds like the DT representation is not an accurate
> > representation of the hardware. We should describe the _whole_ mbigen,
> > not portions thereof. Trying to describe it piecemeal leads to problems
> > like this one.
> > 
> > I don't understand the rationale for describing the mbigen as separate
> > nodes. Above you mention that we "need to define a device node for each
> > device", but I don't see why that's necessary. Why do you believe we
> > need an mbigen node per client device?
> > 
> > As far as I can tell, we should be able to map an arbitrary
> > interrupt-specifier to a particular MSI (complete with device id) within
> > the mbigen driver. We just need to define the full set of MSIs the
> > mbigen owns.
> > 
> 
> mbigen device is a interrupt controller, it is also a ITS device for ITS module.
> So, we need to register the each mbigen device to ITS with a unique ID.
> Based on the current MSI/ITS driver, I can't register whole mbigen module which
> contains several mbigen devices at one time. Because they have different device ID.

I don't follow.

You can describe this by having a top-level mbigen node featuring a reg,
with a sub-node for each mbigen module with an appropriate msi-parent,
e.g.

mbigen {
	reg = < ... ... >;

	#interrupt-cells = <2>;

	#address-cells = <1>; /* module index */

	module at 0 {
		reg = <0>;
		msi-parent = <&its 0>;
	};

	module at 1 {
		reg = <1>;
		reg = <&its 1>;
	};
};


That clearly does not require the reg to be duplicated, and encodes the
information you want. The infrastructure for handling that might not
exist yet, but that is a Linux issue that we can fix.

Marc, thoughts?

I take it all interrupts within a module share the same device id?

> I don't know whether this explanation is clear or not.
> I think Marc can explain this well.
> 
> Marc, would you please help me explain this?  or, do you have any opinion about this ?
> 
> >> Now, a mbigen hardware module contains several logical mbigen device.
> >>
> >> -------------------------------
> >> |mgn_dev1  mgn_dev2  mgn_dev3 |
> >> |-----------------------------|
> >>    |          |        |
> >> dev1	    dev2      dev3
> >>
> >> So,mgn_dev1, mgn_dev2 and mgn_dev3 exist in same mbigen hardware module,
> >> and,they use the same reg address region,that is adress of mbigen hardware module.
> >>
> >> For this case, I think the question is can we map an reg address
> >> region more than one time?
> > 
> > As above, I think we've mis-described the hardware. Rather than making
> > things simpler, this has resulted in problems like this one.
> > 
> > We should not map a reg region more than once. Even if it's technically
> > possible to do so, I do not believe that would be the right solution
> > here. Implicitly sharing resources (e.g. portions of the mbigen control
> > registers) is inevitably going to lead to more problems later on.
> 
> Because we only need to write 1 into corresponding bit of status
> register to clear interrupt status during runtime,I think we don't
> need to worry about this.

That might be currently true, but I doubt that will remain true in
future. Presumably there are other control registers in the mbigen which
are shared between modules.

I think we do need to worry about this.

Mark.


From cyrille.pitchen at atmel.com  Wed Feb  3 03:16:53 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 12:16:53 +0100
Subject: [PATCH linux-next v2 01/14] mtd: spi-nor: remove
 micron_quad_enable()
In-Reply-To: <A765B125120D1346A63912DDE6D8B6310BF57A75@NTXXIAMBX02.xacn.micron.com>
References: <A765B125120D1346A63912DDE6D8B6310BF57A75@NTXXIAMBX02.xacn.micron.com>
Message-ID: <56B1E1A5.9060902@atmel.com>

Le 20/01/2016 06:13, Bean Huo ??? (beanhuo) a ?crit :
>> Message-ID:
>> 	<6177f7317fe11922e1d1b6dc4548afbaf0ccebdd.1452268345.git.cyrille.
>> pitchen at atmel.com>
>>
>> Content-Type: text/plain
>>
>> This patch remove the micron_quad_enable() function which force the Quad
>> SPI mode. However, once this mode is enabled, the Micron memory expect
>> ALL
>> commands to use the SPI 4-4-4 protocol. Hence a failure does occur when
>> calling spi_nor_wait_till_ready() right after the update of the Enhanced
>> Volatile Configuration Register (EVCR) in the micron_quad_enable() as
>> the SPI controller driver is not aware about the protocol change.
>> Since there is almost no performance increase using Fast Read 4-4-4
>> commands instead of Fast Read 1-1-4 commands, we rather keep on using
>> the
>> Extended SPI mode than enabling the Quad SPI mode.
>>
>> Let's take the example of the pretty standard use of 8 dummy cycles during
>> Fast Read operations on 64KB erase sectors:
>>
>> Fast Read 1-1-4 requires 8 cycles for the command, then 24 cycles for the
>> 3byte address followed by 8 dummy clock cycles and finally 65536*2 cycles
>> for the read data; so 131112 clock cycles.
>>
>> On the other hand the Fast Read 4-4-4 would require 2 cycles for the
>> command, then 6 cycles for the 3byte address followed by 8 dummy clock
>> cycles and finally 65536*2 cycles for the read data. So 131088 clock
>> cycles. The theorical bandwidth increase is 0.0%.
>>
>> Now using Fast Read operations on 512byte pages:
>> Fast Read 1-1-4 needs 8+24+8+(512*2) = 1064 clock cycles whereas Fast
>> Read 4-4-4 would requires 2+6+8+(512*2) = 1040 clock cycles. Hence the
>> theorical bandwidth increase is 2.3%.
>> Consecutive reads for non sequential pages is not a relevant use case so
>> The Quad SPI mode is not worth it.
>>
>> mtd_speedtest seems to confirm these figures.
>>
>> Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
>> Fixes: 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron SPI
>> NOR")
>> ---
>>  drivers/mtd/spi-nor/spi-nor.c | 46 +------------------------------------------
>>  1 file changed, 1 insertion(+), 45 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>> index ed0c19c558b5..3028c06547c1 100644
>> --- a/drivers/mtd/spi-nor/spi-nor.c
>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>> @@ -1100,45 +1100,6 @@ static int spansion_quad_enable(struct spi_nor
>> *nor)
>>  	return 0;
>>  }
>>
>> -static int micron_quad_enable(struct spi_nor *nor)
>> -{
>> -	int ret;
>> -	u8 val;
>> -
>> -	ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, &val, 1);
>> -	if (ret < 0) {
>> -		dev_err(nor->dev, "error %d reading EVCR\n", ret);
>> -		return ret;
>> -	}
>> -
>> -	write_enable(nor);
>> -
>> -	/* set EVCR, enable quad I/O */
>> -	nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
>> -	ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1);
>> -	if (ret < 0) {
>> -		dev_err(nor->dev, "error while writing EVCR register\n");
>> -		return ret;
>> -	}
>> -
>> -	ret = spi_nor_wait_till_ready(nor);
>> -	if (ret)
>> -		return ret;
>> -
>> -	/* read EVCR and check it */
>> -	ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, &val, 1);
>> -	if (ret < 0) {
>> -		dev_err(nor->dev, "error %d reading EVCR\n", ret);
>> -		return ret;
>> -	}
>> -	if (val & EVCR_QUAD_EN_MICRON) {
>> -		dev_err(nor->dev, "Micron EVCR Quad bit not clear\n");
>> -		return -EINVAL;
>> -	}
>> -
>> -	return 0;
>> -}
>> -
>>  static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
>>  {
>>  	int status;
>> @@ -1152,12 +1113,7 @@ static int set_quad_mode(struct spi_nor *nor,
>> const struct flash_info *info)
>>  		}
>>  		return status;
>>  	case SNOR_MFR_MICRON:
>> -		status = micron_quad_enable(nor);
>> -		if (status) {
>> -			dev_err(nor->dev, "Micron quad-read not enabled\n");
>> -			return -EINVAL;
>> -		}
>> -		return status;
>> +		return 0;
>>  	default:
>>  		status = spansion_quad_enable(nor);
>>  		if (status) {
>> --
>> 1.8.2.2
>>
>>
>>
>>
> 
> Hi, Cyrlle
> Micron_quad_enable() function is just for how to enable Micron spi nor Quad mode,
> does not force to use SPI nor quad mode. if does not need SPI NOR quad mode,
> why spi-nor.c need set_quad_mode(), according to your patch, this function also need to
> be removed?
> Another question, if there is user want to enable SPI nor quad mode, how to do?
> 

Hi Bean,

the set_quad_mode() function should not been removed from spi-nor.c as it is
needed for both Macronix and Spansion memories.
Indeed, what macronix_quad_enable() and spansion_quad_enable() do is to change
a dedicated bit in some status/configuration register to enable Quad SPI
operations. More precisely, this disables some features such as the Write
Protection (Spansion & Macronix) or the Reset (Macronix) / Hold (Spansion) so
the associated pins can be reassigned to IO2 and IO3 data lines... and that's
all!
What I mean is that once set_quad_mode() has been called, Macronix and Spansion
memories still reply to commands such as Read Status Register in protocol
SPI 1-1-1. Of course, they now also support Fast Read 1-1-4 (0x6b) or 1-4-4
(0xeb).
For Macronix memories, setting the Quad Enable bit in its Status Register is
NOT the same as entering its QPI mode. In QPI mode, ALL commands are expected
to use the SPI 4-4-4 protocol: this mode is not used by spi-nor.c

Then going back to the Micron case, micron_quad_enable() makes the memory
enter its Quad mode where ALL commands must use the SPI 4-4-4 protocol. So
it is definitely not the same thing as what either macronix_quad_enable() or
spansion_quad_enable() do.

Also the current code of micron_quad_enable() is broken:

[...]
Here, the memory still expects the SPI 1-1-1 to be used by write_reg() or
read_reg().

	/* set EVCR, enable quad I/O */
	nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
	ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1);
	if (ret < 0) {
		dev_err(nor->dev, "error while writing EVCR register\n");
		return ret;
	}

However, once the Quad Enable bit has been cleared into the Enhanced Volatile
Configuration Register, all commands must use the SPI 4-4-4 protocol.
Especially, the later call of spi_nor_wait_till_ready(), which calls read_reg()
to read the Status Register, will fail because the QSPI controller has to mean
to know about the protocol switch hence keeps on sending the Read Status
Register command with the wrong SPI 1-1-1 protocol.
This is the issue I faced when using a Micron memory with the Atmel QSPI
controller embedded in a sama5d2 SoC. Also for the same reason, users of the
m25p80 driver won't be able to use Micron memories for QSPI operations too.

	ret = spi_nor_wait_till_ready(nor);
	if (ret)
		return ret;
[...]

So in its current state, micron_quad_enable() prevents us from using Micron
memories for Quad SPI operations. Some code is missing to make it work.



As I said in the patch description, using the SPI 4-4-4 protocol is not
relevant for MTD usage. It would be worth for XIP operations but this is not the
purpose of the spi-nor driver.
Also, the series of patches still support the Micron Quad SPI mode: the spi-nor
driver no longer enables this mode itself but it still can adapt itself whether
the Quad SPI mode had already been enabled by a previous bootloader or at
reset. This is the purpose of the patch focusing on Read JEDEC ID commands:
it is used to probe the current state of the memory and use the SPI 4-4-4 if
needed.

Best regards,

Cyrille


From geert at linux-m68k.org  Wed Feb  3 03:17:24 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 3 Feb 2016 12:17:24 +0100
Subject: [PATCH] dmaengine: use phys_addr_t for slave configuration
In-Reply-To: <20151215172649.GK1854@localhost>
References: <1366967214-20776-1-git-send-email-linus.walleij@linaro.org>
 <CAMuHMdUTzTBT8DyRb5WN048U5DbVsFnhJB0c5tjHBnA4rfetJg@mail.gmail.com>
 <20150710081411.GF836@localhost>
 <CAMuHMdV8a1W1MyJPanUNBzaiNsL96JYzetBVSiZoC3=eKXzo1Q@mail.gmail.com>
 <20151215172649.GK1854@localhost>
Message-ID: <CAMuHMdXe8i2JbhOP2sWkVkqHEeBnW4AfVBbRaoZW=Kg0s_9m3g@mail.gmail.com>

Hi Vinod,

On Tue, Dec 15, 2015 at 6:26 PM, Vinod Koul <vinod.koul at intel.com> wrote:
> On Tue, Dec 15, 2015 at 11:48:24AM +0100, Geert Uytterhoeven wrote:
>> On Fri, Jul 10, 2015 at 10:14 AM, Vinod Koul <vinod.koul at intel.com> wrote:
>> > On Wed, Jul 08, 2015 at 12:12:52PM +0200, Geert Uytterhoeven wrote:
>> >> On Fri, Apr 26, 2013 at 11:06 AM, Linus Walleij

(yes, 2013)

>> >> <linus.walleij at linaro.org> wrote:
>> >> > The documentation already says these are physical addresses, and
>> >> > we have concluded that any translation into the DMA address space
>> >> > needs to reside in the dmaengine driver, so change the type of
>> >> > the passed arguments.
>> >> >
>> >> > Cc: Arnd Bergmann <arnd at arndb.de>
>> >> > Cc: Lee Jones <lee.jones at linaro.org>
>> >> > Cc: Vinod Koul <vinod.koul at intel.com>
>> >> > Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
>> >>
>> >> What's the status of this one, which has been acked by Lee and Arnd?
>> > Looks to have slipped thru. I will redo it
>>
>> Ping?
>
> I should be able to do this in next few days...

Ping?

This is a dependency for adding iommu support to the rcar-dmac driver, cfr.
"[PATCH v2 0/5] dmaengine: rcar-dmac: add iommu support for slave transfers".
http://www.spinics.net/lists/linux-renesas-soc/msg00066.html
https://www.mail-archive.com/linux-renesas-soc at vger.kernel.org/msg00108.html

Thank you for applying!

>> >> > ---
>> >> >  include/linux/dmaengine.h | 4 ++--
>> >> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >> >
>> >> > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
>> >> > index 91ac8da..681df5f9 100644
>> >> > --- a/include/linux/dmaengine.h
>> >> > +++ b/include/linux/dmaengine.h
>> >> > @@ -361,8 +361,8 @@ enum dma_slave_buswidth {
>> >> >   */
>> >> >  struct dma_slave_config {
>> >> >         enum dma_transfer_direction direction;
>> >> > -       dma_addr_t src_addr;
>> >> > -       dma_addr_t dst_addr;
>> >> > +       phys_addr_t src_addr;
>> >> > +       phys_addr_t dst_addr;
>> >> >         enum dma_slave_buswidth src_addr_width;
>> >> >         enum dma_slave_buswidth dst_addr_width;
>> >> >         u32 src_maxburst;

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From lorenzo.pieralisi at arm.com  Wed Feb  3 03:21:12 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 3 Feb 2016 11:21:12 +0000
Subject: [PATCH v3] ARM64: kernel: implement ACPI parking protocol
In-Reply-To: <20160202182657.GC15706@e104818-lin.cambridge.arm.com>
References: <1453806638-23167-1-git-send-email-lorenzo.pieralisi@arm.com>
 <20160202182657.GC15706@e104818-lin.cambridge.arm.com>
Message-ID: <20160203112112.GA18387@red-moon>

On Tue, Feb 02, 2016 at 06:26:58PM +0000, Catalin Marinas wrote:
> On Tue, Jan 26, 2016 at 11:10:38AM +0000, Lorenzo Pieralisi wrote:
> > The SBBR and ACPI specifications allow ACPI based systems that do not
> > implement PSCI (eg systems with no EL3) to boot through the ACPI parking
> > protocol specification[1].
> > 
> > This patch implements the ACPI parking protocol CPU operations, and adds
> > code that eases parsing the parking protocol data structures to the
> > ARM64 SMP initializion carried out at the same time as cpus enumeration.
> > 
> > To wake-up the CPUs from the parked state, this patch implements a
> > wakeup IPI for ARM64 (ie arch_send_wakeup_ipi_mask()) that mirrors the
> > ARM one, so that a specific IPI is sent for wake-up purpose in order
> > to distinguish it from other IPI sources.
> > 
> > Given the current ACPI MADT parsing API, the patch implements a glue
> > layer that helps passing MADT GICC data structure from SMP initialization
> > code to the parking protocol implementation somewhat overriding the CPU
> > operations interfaces. This to avoid creating a completely trasparent
> > DT/ACPI CPU operations layer that would require creating opaque
> > structure handling for CPUs data (DT represents CPU through DT nodes, ACPI
> > through static MADT table entries), which seems overkill given that ACPI
> > on ARM64 mandates only two booting protocols (PSCI and parking protocol),
> > so there is no need for further protocol additions.
> > 
> > Based on the original work by Mark Salter <msalter at redhat.com>
> > 
> > [1] https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.docx
> > 
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > Cc: Will Deacon <will.deacon at arm.com>
> > Cc: Hanjun Guo <hanjun.guo at linaro.org>
> > Cc: Loc Ho <lho at apm.com>
> > Cc: Sudeep Holla <sudeep.holla at arm.com>
> > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > Cc: Mark Rutland <mark.rutland at arm.com>
> > Cc: Mark Salter <msalter at redhat.com>
> > Cc: Al Stone <ahs3 at redhat.com>
> 
> Applied, with a minor addition just to warn people from not using it in
> other configurations (#ifdef still needed otherwise the
> acpi_parking_protocol_valid symbol is not available; but I prefer uglier
> code than people starting to use this IPI in their firmware):

It makes sense, we could include asm/acpi.h in smp.c (which is not
included by linux/acpi.h if !CONFIG_ACPI) to pull in the symbol and
remove the ifdef if you think it is cleaner.

Thanks !
Lorenzo

> 
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -767,6 +767,12 @@ void handle_IPI(int ipinr, struct pt_regs *regs)
>                 break;
>  #endif
> +
> +#ifdef CONFIG_ARM64_ACPI_PARKING_PROTOCOL
>         case IPI_WAKEUP:
> +               WARN_ONCE(!acpi_parking_protocol_valid(cpu),
> +                         "CPU%u: Wake-up IPI outside the ACPI parking protocol\n",
> +                         cpu);
>                 break;
> +#endif
>  
>         default:
> 
> Thanks.
> 
> -- 
> Catalin
> 


From paul.burton at imgtec.com  Wed Feb  3 03:30:34 2016
From: paul.burton at imgtec.com (Paul Burton)
Date: Wed, 3 Feb 2016 11:30:34 +0000
Subject: [PATCH v2 04/15] PCI: xilinx: Keep references to both IRQ domains
In-Reply-To: <1454499045-5020-1-git-send-email-paul.burton@imgtec.com>
References: <1454499045-5020-1-git-send-email-paul.burton@imgtec.com>
Message-ID: <1454499045-5020-5-git-send-email-paul.burton@imgtec.com>

pcie-xilinx creates 2 IRQ domains when built with MSI support: one for
MSI interrupts & one for legacy INTx interrupts. However, it only kept a
reference to the MSI IRQ domain. This means that any INTx interrupts
that may occur would be mapped using the wrong domain, and that only the
MSI IRQ domain would be removed along with the driver. Track both IRQ
domains & clean up both as appropriate.

Signed-off-by: Paul Burton <paul.burton at imgtec.com>
Fixes: 8961def56845 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver")

---

Changes in v2:
- Add Fixes tag.

 drivers/pci/host/pcie-xilinx.c | 58 ++++++++++++++++++++----------------------
 1 file changed, 28 insertions(+), 30 deletions(-)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 4cfa463..1490bd1 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -105,6 +105,7 @@
  * @root_busno: Root Bus number
  * @dev: Device pointer
  * @irq_domain: IRQ domain pointer
+ * @msi_irq_domain: MSI IRQ domain pointer
  * @bus_range: Bus range
  * @resources: Bus Resources
  */
@@ -115,6 +116,7 @@ struct xilinx_pcie_port {
 	u8 root_busno;
 	struct device *dev;
 	struct irq_domain *irq_domain;
+	struct irq_domain *msi_irq_domain;
 	struct resource bus_range;
 	struct list_head resources;
 };
@@ -291,7 +293,7 @@ static int xilinx_pcie_msi_setup_irq(struct msi_controller *chip,
 	if (hwirq < 0)
 		return hwirq;
 
-	irq = irq_create_mapping(port->irq_domain, hwirq);
+	irq = irq_create_mapping(port->msi_irq_domain, hwirq);
 	if (!irq)
 		return -EINVAL;
 
@@ -517,31 +519,21 @@ static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
 
 /**
  * xilinx_pcie_free_irq_domain - Free IRQ domain
- * @port: PCIe port information
+ * @domain: the IRQ domain to free
+ * @nr: the number of IRQs in the domain
  */
-static void xilinx_pcie_free_irq_domain(struct xilinx_pcie_port *port)
+static void xilinx_pcie_free_irq_domain(struct irq_domain *domain, int nr)
 {
 	int i;
-	u32 irq, num_irqs;
-
-	/* Free IRQ Domain */
-	if (IS_ENABLED(CONFIG_PCI_MSI)) {
-
-		free_pages(port->msi_pages, 0);
-
-		num_irqs = XILINX_NUM_MSI_IRQS;
-	} else {
-		/* INTx */
-		num_irqs = 4;
-	}
+	u32 irq;
 
-	for (i = 0; i < num_irqs; i++) {
-		irq = irq_find_mapping(port->irq_domain, i);
+	for (i = 0; i < nr; i++) {
+		irq = irq_find_mapping(domain, i);
 		if (irq > 0)
 			irq_dispose_mapping(irq);
 	}
 
-	irq_domain_remove(port->irq_domain);
+	irq_domain_remove(domain);
 }
 
 /**
@@ -571,20 +563,20 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
 		return PTR_ERR(port->irq_domain);
 	}
 
-	/* Setup MSI */
-	if (IS_ENABLED(CONFIG_PCI_MSI)) {
-		port->irq_domain = irq_domain_add_linear(node,
-							 XILINX_NUM_MSI_IRQS,
-							 &msi_domain_ops,
-							 &xilinx_pcie_msi_chip);
-		if (!port->irq_domain) {
-			dev_err(dev, "Failed to get a MSI IRQ domain\n");
-			return PTR_ERR(port->irq_domain);
-		}
+	if (!IS_ENABLED(CONFIG_PCI_MSI))
+		return 0;
 
-		xilinx_pcie_enable_msi(port);
+	/* Setup MSI */
+	port->msi_irq_domain = irq_domain_add_linear(node,
+						     XILINX_NUM_MSI_IRQS,
+						     &msi_domain_ops,
+						     &xilinx_pcie_msi_chip);
+	if (!port->msi_irq_domain) {
+		dev_err(dev, "Failed to get a MSI IRQ domain\n");
+		return PTR_ERR(port->msi_irq_domain);
 	}
 
+	xilinx_pcie_enable_msi(port);
 	return 0;
 }
 
@@ -869,7 +861,13 @@ static int xilinx_pcie_remove(struct platform_device *pdev)
 {
 	struct xilinx_pcie_port *port = platform_get_drvdata(pdev);
 
-	xilinx_pcie_free_irq_domain(port);
+	xilinx_pcie_free_irq_domain(port->irq_domain, 4);
+
+	if (config_enabled(CONFIG_MSI)) {
+		free_pages(port->msi_pages, 0);
+		xilinx_pcie_free_irq_domain(port->msi_irq_domain,
+					    XILINX_NUM_MSI_IRQS);
+	}
 
 	return 0;
 }
-- 
2.7.0



From paul.burton at imgtec.com  Wed Feb  3 03:30:35 2016
From: paul.burton at imgtec.com (Paul Burton)
Date: Wed, 3 Feb 2016 11:30:35 +0000
Subject: [PATCH v2 05/15] PCI: xilinx: Unify INTx & MSI interrupt FIFO decode
In-Reply-To: <1454499045-5020-1-git-send-email-paul.burton@imgtec.com>
References: <1454499045-5020-1-git-send-email-paul.burton@imgtec.com>
Message-ID: <1454499045-5020-6-git-send-email-paul.burton@imgtec.com>

When decoding either an INTx or MSI interrupt, the driver has no way to
know which it will pull out of the interrupt FIFO. If both were pending
then this would lead to either the interrupt being handled incorrectly
(MSI interrupt treated as INTx) or not at all (INTx interrupt dropped by
MSI path). Unify the reading of the interrupt FIFO & act according to
the type of interrupt actually read.

Signed-off-by: Paul Burton <paul.burton at imgtec.com>
Fixes: 8961def56845 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver")

---

Changes in v2:
- Add Fixes tag.

 drivers/pci/host/pcie-xilinx.c | 47 +++++++++++++-----------------------------
 1 file changed, 14 insertions(+), 33 deletions(-)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 1490bd1..afdfb09 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -397,7 +397,7 @@ static const struct irq_domain_ops intx_domain_ops = {
 static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
 {
 	struct xilinx_pcie_port *port = (struct xilinx_pcie_port *)data;
-	u32 val, mask, status, msi_data;
+	u32 val, mask, status;
 
 	/* Read interrupt decode and mask registers */
 	val = pcie_read(port, XILINX_PCIE_REG_IDR);
@@ -437,8 +437,8 @@ static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
 		xilinx_pcie_clear_err_interrupts(port);
 	}
 
-	if (status & XILINX_PCIE_INTR_INTX) {
-		/* INTx interrupt received */
+	if (status & (XILINX_PCIE_INTR_INTX | XILINX_PCIE_INTR_MSI)) {
+		/* Interrupt received */
 		val = pcie_read(port, XILINX_PCIE_REG_RPIFR1);
 
 		/* Check whether interrupt valid */
@@ -447,41 +447,22 @@ static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
 			return IRQ_HANDLED;
 		}
 
-		if (!(val & XILINX_PCIE_RPIFR1_MSI_INTR)) {
-			/* Clear interrupt FIFO register 1 */
-			pcie_write(port, XILINX_PCIE_RPIFR1_ALL_MASK,
-				   XILINX_PCIE_REG_RPIFR1);
-
-			/* Handle INTx Interrupt */
+		if (val & XILINX_PCIE_RPIFR1_MSI_INTR) {
+			irq = pcie_read(port, XILINX_PCIE_REG_RPIFR2) &
+				XILINX_PCIE_RPIFR2_MSG_DATA;
+		} else {
 			val = ((val & XILINX_PCIE_RPIFR1_INTR_MASK) >>
 				XILINX_PCIE_RPIFR1_INTR_SHIFT) + 1;
-			generic_handle_irq(irq_find_mapping(port->irq_domain,
-							    val));
+			irq = irq_find_mapping(port->irq_domain, val);
 		}
-	}
 
-	if (status & XILINX_PCIE_INTR_MSI) {
-		/* MSI Interrupt */
-		val = pcie_read(port, XILINX_PCIE_REG_RPIFR1);
+		/* Clear interrupt FIFO register 1 */
+		pcie_write(port, XILINX_PCIE_RPIFR1_ALL_MASK,
+			   XILINX_PCIE_REG_RPIFR1);
 
-		if (!(val & XILINX_PCIE_RPIFR1_INTR_VALID)) {
-			dev_warn(port->dev, "RP Intr FIFO1 read error\n");
-			return IRQ_HANDLED;
-		}
-
-		if (val & XILINX_PCIE_RPIFR1_MSI_INTR) {
-			msi_data = pcie_read(port, XILINX_PCIE_REG_RPIFR2) &
-				   XILINX_PCIE_RPIFR2_MSG_DATA;
-
-			/* Clear interrupt FIFO register 1 */
-			pcie_write(port, XILINX_PCIE_RPIFR1_ALL_MASK,
-				   XILINX_PCIE_REG_RPIFR1);
-
-			if (IS_ENABLED(CONFIG_PCI_MSI)) {
-				/* Handle MSI Interrupt */
-				generic_handle_irq(msi_data);
-			}
-		}
+		if (IS_ENABLED(CONFIG_PCI_MSI) ||
+			!(val & XILINX_PCIE_RPIFR1_MSI_INTR))
+			generic_handle_irq(irq);
 	}
 
 	if (status & XILINX_PCIE_INTR_SLV_UNSUPP)
-- 
2.7.0



From paul.burton at imgtec.com  Wed Feb  3 03:30:36 2016
From: paul.burton at imgtec.com (Paul Burton)
Date: Wed, 3 Feb 2016 11:30:36 +0000
Subject: [PATCH v2 06/15] PCI: xilinx: Always clear interrupt decode register
In-Reply-To: <1454499045-5020-1-git-send-email-paul.burton@imgtec.com>
References: <1454499045-5020-1-git-send-email-paul.burton@imgtec.com>
Message-ID: <1454499045-5020-7-git-send-email-paul.burton@imgtec.com>

If an MSI or INTx interrupt is incorrectly triggered with an empty FIFO
then xilinx_pcie_intr_handler will print a warning & skip further
processing. However it did not clear the interrupt in the decode
register, so the same INTX or MSI interrupt would trigger again
immediately even though the FIFO is still empty. Clear the interrupt in
the decode register to avoid that situation.

Signed-off-by: Paul Burton <paul.burton at imgtec.com>
Fixes: 8961def56845 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver")

---

Changes in v2:
- Add Fixes tag.

 drivers/pci/host/pcie-xilinx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index afdfb09..1eb74a2 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -444,7 +444,7 @@ static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
 		/* Check whether interrupt valid */
 		if (!(val & XILINX_PCIE_RPIFR1_INTR_VALID)) {
 			dev_warn(port->dev, "RP Intr FIFO1 read error\n");
-			return IRQ_HANDLED;
+			goto out;
 		}
 
 		if (val & XILINX_PCIE_RPIFR1_MSI_INTR) {
@@ -492,6 +492,7 @@ static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
 	if (status & XILINX_PCIE_INTR_MST_ERRP)
 		dev_warn(port->dev, "Master error poison\n");
 
+out:
 	/* Clear the Interrupt Decode register */
 	pcie_write(port, status, XILINX_PCIE_REG_IDR);
 
-- 
2.7.0



From paul.burton at imgtec.com  Wed Feb  3 03:30:37 2016
From: paul.burton at imgtec.com (Paul Burton)
Date: Wed, 3 Feb 2016 11:30:37 +0000
Subject: [PATCH v2 07/15] PCI: xilinx: Clear interrupt FIFO during probe
In-Reply-To: <1454499045-5020-1-git-send-email-paul.burton@imgtec.com>
References: <1454499045-5020-1-git-send-email-paul.burton@imgtec.com>
Message-ID: <1454499045-5020-8-git-send-email-paul.burton@imgtec.com>

xilinx_pcie_init_port clears the pending interrupts in the interrupt
decode register, but does not clear the interrupt FIFO. This would lead
to spurious interrupts if any were present in the FIFO at probe time.
Clear the interrupt FIFO prior to the interrupt decode register in order
to start with a clean slate as expected.

Signed-off-by: Paul Burton <paul.burton at imgtec.com>
Fixes: 8961def56845 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver")

---

Changes in v2:
- Add Fixes tag.

 drivers/pci/host/pcie-xilinx.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 1eb74a2..6c5a503 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -568,6 +568,8 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
  */
 static void xilinx_pcie_init_port(struct xilinx_pcie_port *port)
 {
+	u32 val;
+
 	if (xilinx_pcie_link_is_up(port))
 		dev_info(port->dev, "PCIe Link is UP\n");
 	else
@@ -577,6 +579,17 @@ static void xilinx_pcie_init_port(struct xilinx_pcie_port *port)
 	pcie_write(port, ~XILINX_PCIE_IDR_ALL_MASK,
 		   XILINX_PCIE_REG_IMR);
 
+	/* Clear interrupt FIFO */
+	while (1) {
+		val = pcie_read(port, XILINX_PCIE_REG_RPIFR1);
+
+		if (!(val & XILINX_PCIE_RPIFR1_INTR_VALID))
+			break;
+
+		pcie_write(port, XILINX_PCIE_RPIFR1_ALL_MASK,
+			   XILINX_PCIE_REG_RPIFR1);
+	}
+
 	/* Clear pending interrupts */
 	pcie_write(port, pcie_read(port, XILINX_PCIE_REG_IDR) &
 			 XILINX_PCIE_IMR_ALL_MASK,
-- 
2.7.0



From paul.burton at imgtec.com  Wed Feb  3 03:30:38 2016
From: paul.burton at imgtec.com (Paul Burton)
Date: Wed, 3 Feb 2016 11:30:38 +0000
Subject: [PATCH v2 08/15] PCI: xilinx: Fix INTX irq dispatch
In-Reply-To: <1454499045-5020-1-git-send-email-paul.burton@imgtec.com>
References: <1454499045-5020-1-git-send-email-paul.burton@imgtec.com>
Message-ID: <1454499045-5020-9-git-send-email-paul.burton@imgtec.com>

The IRQ domain for INTX interrupts has 4 entries, numbered 0 to 3. This
matches what the hardware reports from the interrupt FIFO exactly, but
xilinx_pcie_intr_handler was adding 1 to that value to convert to the
range 1 to 4. Stop adding 1, such that all of INTA through to INTD fall
within the range of the IRQ domain.

Signed-off-by: Paul Burton <paul.burton at imgtec.com>
Fixes: 8961def56845 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver")

---

Changes in v2:
- Add Fixes tag.

 drivers/pci/host/pcie-xilinx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 6c5a503..8013e83 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -451,8 +451,8 @@ static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
 			irq = pcie_read(port, XILINX_PCIE_REG_RPIFR2) &
 				XILINX_PCIE_RPIFR2_MSG_DATA;
 		} else {
-			val = ((val & XILINX_PCIE_RPIFR1_INTR_MASK) >>
-				XILINX_PCIE_RPIFR1_INTR_SHIFT) + 1;
+			val = (val & XILINX_PCIE_RPIFR1_INTR_MASK) >>
+				XILINX_PCIE_RPIFR1_INTR_SHIFT;
 			irq = irq_find_mapping(port->irq_domain, val);
 		}
 
-- 
2.7.0



From Gang.Liu at nxp.com  Wed Feb  3 03:27:34 2016
From: Gang.Liu at nxp.com (Liu Gang)
Date: Wed, 3 Feb 2016 19:27:34 +0800
Subject: [PATCH V4] drivers/gpio: Switch gpio-mpc8xxx to use gpio-generic
Message-ID: <1454498854-33169-1-git-send-email-Gang.Liu@nxp.com>

The new Layerscape platforms has the same ip block/controller
as GPIO on PowerPC platforms(MPC8XXX), but the GPIO registers
may be big or little endian. So the code needs to get the
endian property from DTB, then make additional functions to
fit all the PowerPC/Layerscape GPIO register read/write
operations.

gpio-generic.c provides an universal infrastructure for both
big and little endian register operations. So switch the
gpio-mpc8xxx to use gpio-generic can simplify the driver and
reduce a lot of code.

The IRQ and some workaround parts in gpio-mpc8xxx.c will be
updated with the new API interfaces but following the
original functionalities.

Signed-off-by: Liu Gang <Gang.Liu at nxp.com>
---
-V4: Rebase the kernel to v4.5-rc1 for the new gpio-generic
     infrastructure based on Linus Walleij comments.

 drivers/gpio/gpio-mpc8xxx.c | 259 +++++++++++++++++---------------------------
 1 file changed, 100 insertions(+), 159 deletions(-)

diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
index 9d40787..ecdb27a 100644
--- a/drivers/gpio/gpio-mpc8xxx.c
+++ b/drivers/gpio/gpio-mpc8xxx.c
@@ -1,7 +1,8 @@
 /*
- * GPIOs on MPC512x/8349/8572/8610 and compatible
+ * GPIOs on MPC512x/8349/8572/8610/QorIQ and compatible
  *
  * Copyright (C) 2008 Peter Korsgaard <jacmet at sunsite.dk>
+ * Copyright (C) 2016 Freescale Semiconductor Inc.
  *
  * This file is licensed under the terms of the GNU General Public License
  * version 2.  This program is licensed "as is" without any warranty of any
@@ -14,11 +15,12 @@
 #include <linux/io.h>
 #include <linux/of.h>
 #include <linux/of_gpio.h>
+#include <linux/of_address.h>
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
-#include <linux/gpio.h>
 #include <linux/slab.h>
 #include <linux/irq.h>
+#include <linux/gpio/driver.h>
 
 #define MPC8XXX_GPIO_PINS	32
 
@@ -31,32 +33,20 @@
 #define GPIO_ICR2		0x18
 
 struct mpc8xxx_gpio_chip {
-	struct of_mm_gpio_chip mm_gc;
+	struct gpio_chip	gc;
+	void __iomem *regs;
 	raw_spinlock_t lock;
 
-	/*
-	 * shadowed data register to be able to clear/set output pins in
-	 * open drain mode safely
-	 */
-	u32 data;
+	unsigned long (*read_reg)(void __iomem *reg);
+	void (*write_reg)(void __iomem *reg, unsigned long data);
+
+	int (*direction_output)(struct gpio_chip *chip,
+				unsigned offset, int value);
+
 	struct irq_domain *irq;
 	unsigned int irqn;
-	const void *of_dev_id_data;
 };
 
-static inline u32 mpc8xxx_gpio2mask(unsigned int gpio)
-{
-	return 1u << (MPC8XXX_GPIO_PINS - 1 - gpio);
-}
-
-static void mpc8xxx_gpio_save_regs(struct of_mm_gpio_chip *mm)
-{
-	struct mpc8xxx_gpio_chip *mpc8xxx_gc =
-		container_of(mm, struct mpc8xxx_gpio_chip, mm_gc);
-
-	mpc8xxx_gc->data = in_be32(mm->regs + GPIO_DAT);
-}
-
 /* Workaround GPIO 1 errata on MPC8572/MPC8536. The status of GPIOs
  * defined as output cannot be determined by reading GPDAT register,
  * so we use shadow data register instead. The status of input pins
@@ -65,117 +55,36 @@ static void mpc8xxx_gpio_save_regs(struct of_mm_gpio_chip *mm)
 static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned int gpio)
 {
 	u32 val;
-	struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
 	struct mpc8xxx_gpio_chip *mpc8xxx_gc = gpiochip_get_data(gc);
 	u32 out_mask, out_shadow;
 
-	out_mask = in_be32(mm->regs + GPIO_DIR);
-
-	val = in_be32(mm->regs + GPIO_DAT) & ~out_mask;
-	out_shadow = mpc8xxx_gc->data & out_mask;
+	out_mask = mpc8xxx_gc->read_reg(mpc8xxx_gc->regs + GPIO_DIR);
+	val = mpc8xxx_gc->read_reg(mpc8xxx_gc->regs + GPIO_DAT) & ~out_mask;
+	out_shadow = gc->bgpio_data & out_mask;
 
-	return !!((val | out_shadow) & mpc8xxx_gpio2mask(gpio));
+	return !!((val | out_shadow) & gc->pin2mask(gc, gpio));
 }
 
-static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+static int mpc5121_gpio_dir_out(struct gpio_chip *gc,
+				unsigned int gpio, int val)
 {
-	struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
-
-	return in_be32(mm->regs + GPIO_DAT) & mpc8xxx_gpio2mask(gpio);
-}
-
-static void mpc8xxx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
-{
-	struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
 	struct mpc8xxx_gpio_chip *mpc8xxx_gc = gpiochip_get_data(gc);
-	unsigned long flags;
-
-	raw_spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
-
-	if (val)
-		mpc8xxx_gc->data |= mpc8xxx_gpio2mask(gpio);
-	else
-		mpc8xxx_gc->data &= ~mpc8xxx_gpio2mask(gpio);
-
-	out_be32(mm->regs + GPIO_DAT, mpc8xxx_gc->data);
-
-	raw_spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
-}
-
-static void mpc8xxx_gpio_set_multiple(struct gpio_chip *gc,
-				      unsigned long *mask, unsigned long *bits)
-{
-	struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
-	struct mpc8xxx_gpio_chip *mpc8xxx_gc = gpiochip_get_data(gc);
-	unsigned long flags;
-	int i;
-
-	raw_spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
-
-	for (i = 0; i < gc->ngpio; i++) {
-		if (*mask == 0)
-			break;
-		if (__test_and_clear_bit(i, mask)) {
-			if (test_bit(i, bits))
-				mpc8xxx_gc->data |= mpc8xxx_gpio2mask(i);
-			else
-				mpc8xxx_gc->data &= ~mpc8xxx_gpio2mask(i);
-		}
-	}
-
-	out_be32(mm->regs + GPIO_DAT, mpc8xxx_gc->data);
-
-	raw_spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
-}
-
-static int mpc8xxx_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
-{
-	struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
-	struct mpc8xxx_gpio_chip *mpc8xxx_gc = gpiochip_get_data(gc);
-	unsigned long flags;
-
-	raw_spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
-
-	clrbits32(mm->regs + GPIO_DIR, mpc8xxx_gpio2mask(gpio));
-
-	raw_spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
-
-	return 0;
-}
-
-static int mpc8xxx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
-{
-	struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
-	struct mpc8xxx_gpio_chip *mpc8xxx_gc = gpiochip_get_data(gc);
-	unsigned long flags;
-
-	mpc8xxx_gpio_set(gc, gpio, val);
-
-	raw_spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
-
-	setbits32(mm->regs + GPIO_DIR, mpc8xxx_gpio2mask(gpio));
-
-	raw_spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
-
-	return 0;
-}
-
-static int mpc5121_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
-{
 	/* GPIO 28..31 are input only on MPC5121 */
 	if (gpio >= 28)
 		return -EINVAL;
 
-	return mpc8xxx_gpio_dir_out(gc, gpio, val);
+	return mpc8xxx_gc->direction_output(gc, gpio, val);
 }
 
-static int mpc5125_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+static int mpc5125_gpio_dir_out(struct gpio_chip *gc,
+				unsigned int gpio, int val)
 {
+	struct mpc8xxx_gpio_chip *mpc8xxx_gc = gpiochip_get_data(gc);
 	/* GPIO 0..3 are input only on MPC5125 */
 	if (gpio <= 3)
 		return -EINVAL;
 
-	return mpc8xxx_gpio_dir_out(gc, gpio, val);
+	return mpc8xxx_gc->direction_output(gc, gpio, val);
 }
 
 static int mpc8xxx_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
@@ -192,10 +101,10 @@ static void mpc8xxx_gpio_irq_cascade(struct irq_desc *desc)
 {
 	struct mpc8xxx_gpio_chip *mpc8xxx_gc = irq_desc_get_handler_data(desc);
 	struct irq_chip *chip = irq_desc_get_chip(desc);
-	struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
 	unsigned int mask;
 
-	mask = in_be32(mm->regs + GPIO_IER) & in_be32(mm->regs + GPIO_IMR);
+	mask = mpc8xxx_gc->read_reg(mpc8xxx_gc->regs + GPIO_IER)
+		& mpc8xxx_gc->read_reg(mpc8xxx_gc->regs + GPIO_IMR);
 	if (mask)
 		generic_handle_irq(irq_linear_revmap(mpc8xxx_gc->irq,
 						     32 - ffs(mask)));
@@ -206,12 +115,14 @@ static void mpc8xxx_gpio_irq_cascade(struct irq_desc *desc)
 static void mpc8xxx_irq_unmask(struct irq_data *d)
 {
 	struct mpc8xxx_gpio_chip *mpc8xxx_gc = irq_data_get_irq_chip_data(d);
-	struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+	struct gpio_chip *gc = &mpc8xxx_gc->gc;
 	unsigned long flags;
 
 	raw_spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
 
-	setbits32(mm->regs + GPIO_IMR, mpc8xxx_gpio2mask(irqd_to_hwirq(d)));
+	mpc8xxx_gc->write_reg(mpc8xxx_gc->regs + GPIO_IMR,
+		mpc8xxx_gc->read_reg(mpc8xxx_gc->regs + GPIO_IMR)
+		| gc->pin2mask(gc, irqd_to_hwirq(d)));
 
 	raw_spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
 }
@@ -219,12 +130,14 @@ static void mpc8xxx_irq_unmask(struct irq_data *d)
 static void mpc8xxx_irq_mask(struct irq_data *d)
 {
 	struct mpc8xxx_gpio_chip *mpc8xxx_gc = irq_data_get_irq_chip_data(d);
-	struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+	struct gpio_chip *gc = &mpc8xxx_gc->gc;
 	unsigned long flags;
 
 	raw_spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
 
-	clrbits32(mm->regs + GPIO_IMR, mpc8xxx_gpio2mask(irqd_to_hwirq(d)));
+	mpc8xxx_gc->write_reg(mpc8xxx_gc->regs + GPIO_IMR,
+		mpc8xxx_gc->read_reg(mpc8xxx_gc->regs + GPIO_IMR)
+		& ~(gc->pin2mask(gc, irqd_to_hwirq(d))));
 
 	raw_spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
 }
@@ -232,29 +145,32 @@ static void mpc8xxx_irq_mask(struct irq_data *d)
 static void mpc8xxx_irq_ack(struct irq_data *d)
 {
 	struct mpc8xxx_gpio_chip *mpc8xxx_gc = irq_data_get_irq_chip_data(d);
-	struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+	struct gpio_chip *gc = &mpc8xxx_gc->gc;
 
-	out_be32(mm->regs + GPIO_IER, mpc8xxx_gpio2mask(irqd_to_hwirq(d)));
+	mpc8xxx_gc->write_reg(mpc8xxx_gc->regs + GPIO_IER,
+		gc->pin2mask(gc, irqd_to_hwirq(d)));
 }
 
 static int mpc8xxx_irq_set_type(struct irq_data *d, unsigned int flow_type)
 {
 	struct mpc8xxx_gpio_chip *mpc8xxx_gc = irq_data_get_irq_chip_data(d);
-	struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
+	struct gpio_chip *gc = &mpc8xxx_gc->gc;
 	unsigned long flags;
 
 	switch (flow_type) {
 	case IRQ_TYPE_EDGE_FALLING:
 		raw_spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
-		setbits32(mm->regs + GPIO_ICR,
-			  mpc8xxx_gpio2mask(irqd_to_hwirq(d)));
+		mpc8xxx_gc->write_reg(mpc8xxx_gc->regs + GPIO_ICR,
+			mpc8xxx_gc->read_reg(mpc8xxx_gc->regs + GPIO_ICR)
+			| gc->pin2mask(gc, irqd_to_hwirq(d)));
 		raw_spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
 		break;
 
 	case IRQ_TYPE_EDGE_BOTH:
 		raw_spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
-		clrbits32(mm->regs + GPIO_ICR,
-			  mpc8xxx_gpio2mask(irqd_to_hwirq(d)));
+		mpc8xxx_gc->write_reg(mpc8xxx_gc->regs + GPIO_ICR,
+			mpc8xxx_gc->read_reg(mpc8xxx_gc->regs + GPIO_ICR)
+			& ~(gc->pin2mask(gc, irqd_to_hwirq(d))));
 		raw_spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
 		break;
 
@@ -268,17 +184,16 @@ static int mpc8xxx_irq_set_type(struct irq_data *d, unsigned int flow_type)
 static int mpc512x_irq_set_type(struct irq_data *d, unsigned int flow_type)
 {
 	struct mpc8xxx_gpio_chip *mpc8xxx_gc = irq_data_get_irq_chip_data(d);
-	struct of_mm_gpio_chip *mm = &mpc8xxx_gc->mm_gc;
 	unsigned long gpio = irqd_to_hwirq(d);
 	void __iomem *reg;
 	unsigned int shift;
 	unsigned long flags;
 
 	if (gpio < 16) {
-		reg = mm->regs + GPIO_ICR;
+		reg = mpc8xxx_gc->regs + GPIO_ICR;
 		shift = (15 - gpio) * 2;
 	} else {
-		reg = mm->regs + GPIO_ICR2;
+		reg = mpc8xxx_gc->regs + GPIO_ICR2;
 		shift = (15 - (gpio % 16)) * 2;
 	}
 
@@ -286,20 +201,25 @@ static int mpc512x_irq_set_type(struct irq_data *d, unsigned int flow_type)
 	case IRQ_TYPE_EDGE_FALLING:
 	case IRQ_TYPE_LEVEL_LOW:
 		raw_spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
-		clrsetbits_be32(reg, 3 << shift, 2 << shift);
+		mpc8xxx_gc->write_reg(reg,
+			(mpc8xxx_gc->read_reg(reg) & ~(3 << shift))
+			| (2 << shift));
 		raw_spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
 		break;
 
 	case IRQ_TYPE_EDGE_RISING:
 	case IRQ_TYPE_LEVEL_HIGH:
 		raw_spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
-		clrsetbits_be32(reg, 3 << shift, 1 << shift);
+		mpc8xxx_gc->write_reg(reg,
+			(mpc8xxx_gc->read_reg(reg) & ~(3 << shift))
+			| (1 << shift));
 		raw_spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
 		break;
 
 	case IRQ_TYPE_EDGE_BOTH:
 		raw_spin_lock_irqsave(&mpc8xxx_gc->lock, flags);
-		clrbits32(reg, 3 << shift);
+		mpc8xxx_gc->write_reg(reg,
+			(mpc8xxx_gc->read_reg(reg) & ~(3 << shift)));
 		raw_spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
 		break;
 
@@ -354,8 +274,6 @@ static const struct mpc8xxx_gpio_devtype mpc8572_gpio_devtype = {
 };
 
 static const struct mpc8xxx_gpio_devtype mpc8xxx_gpio_devtype_default = {
-	.gpio_dir_out = mpc8xxx_gpio_dir_out,
-	.gpio_get = mpc8xxx_gpio_get,
 	.irq_set_type = mpc8xxx_irq_set_type,
 };
 
@@ -374,9 +292,7 @@ static int mpc8xxx_probe(struct platform_device *pdev)
 {
 	struct device_node *np = pdev->dev.of_node;
 	struct mpc8xxx_gpio_chip *mpc8xxx_gc;
-	struct of_mm_gpio_chip *mm_gc;
-	struct gpio_chip *gc;
-	const struct of_device_id *id;
+	struct gpio_chip	*gc;
 	const struct mpc8xxx_gpio_devtype *devtype =
 		of_device_get_match_data(&pdev->dev);
 	int ret;
@@ -389,12 +305,35 @@ static int mpc8xxx_probe(struct platform_device *pdev)
 
 	raw_spin_lock_init(&mpc8xxx_gc->lock);
 
-	mm_gc = &mpc8xxx_gc->mm_gc;
-	gc = &mm_gc->gc;
+	mpc8xxx_gc->regs = of_iomap(np, 0);
+	if (!mpc8xxx_gc->regs)
+		return -ENOMEM;
+
+	gc = &mpc8xxx_gc->gc;
+
+	if (of_property_read_bool(np, "little-endian")) {
+		ret = bgpio_init(gc, &pdev->dev, 4,
+				 mpc8xxx_gc->regs + GPIO_DAT,
+				 NULL, NULL,
+				 mpc8xxx_gc->regs + GPIO_DIR, NULL,
+				 BGPIOF_BIG_ENDIAN);
+		if (ret)
+			goto err;
+		dev_dbg(&pdev->dev, "GPIO registers are LITTLE endian\n");
+	} else {
+		ret = bgpio_init(gc, &pdev->dev, 4,
+				 mpc8xxx_gc->regs + GPIO_DAT,
+				 NULL, NULL,
+				 mpc8xxx_gc->regs + GPIO_DIR, NULL,
+				 BGPIOF_BIG_ENDIAN
+				 | BGPIOF_BIG_ENDIAN_BYTE_ORDER);
+		if (ret)
+			goto err;
+		dev_dbg(&pdev->dev, "GPIO registers are BIG endian\n");
+	}
 
-	mm_gc->save_regs = mpc8xxx_gpio_save_regs;
-	gc->ngpio = MPC8XXX_GPIO_PINS;
-	gc->direction_input = mpc8xxx_gpio_dir_in;
+	mpc8xxx_gc->read_reg = gc->read_reg;
+	mpc8xxx_gc->write_reg = gc->write_reg;
 
 	if (!devtype)
 		devtype = &mpc8xxx_gpio_devtype_default;
@@ -405,18 +344,21 @@ static int mpc8xxx_probe(struct platform_device *pdev)
 	 */
 	mpc8xxx_irq_chip.irq_set_type = devtype->irq_set_type;
 
-	gc->direction_output = devtype->gpio_dir_out ?: mpc8xxx_gpio_dir_out;
-	gc->get = devtype->gpio_get ?: mpc8xxx_gpio_get;
-	gc->set = mpc8xxx_gpio_set;
-	gc->set_multiple = mpc8xxx_gpio_set_multiple;
+	gc->direction_output = devtype->gpio_dir_out ?: gc->direction_output;
+	gc->get = devtype->gpio_get ?: gc->get;
 	gc->to_irq = mpc8xxx_gpio_to_irq;
 
-	ret = of_mm_gpiochip_add_data(np, mm_gc, mpc8xxx_gc);
-	if (ret)
-		return ret;
+	mpc8xxx_gc->direction_output = gc->direction_output;
+
+	ret = gpiochip_add_data(gc, mpc8xxx_gc);
+	if (ret) {
+		pr_err("%s: GPIO chip registration failed with status %d\n",
+		       np->full_name, ret);
+		goto err;
+	}
 
 	mpc8xxx_gc->irqn = irq_of_parse_and_map(np, 0);
-	if (mpc8xxx_gc->irqn == NO_IRQ)
+	if (!mpc8xxx_gc->irqn)
 		return 0;
 
 	mpc8xxx_gc->irq = irq_domain_add_linear(np, MPC8XXX_GPIO_PINS,
@@ -424,18 +366,16 @@ static int mpc8xxx_probe(struct platform_device *pdev)
 	if (!mpc8xxx_gc->irq)
 		return 0;
 
-	id = of_match_node(mpc8xxx_gpio_ids, np);
-	if (id)
-		mpc8xxx_gc->of_dev_id_data = id->data;
-
 	/* ack and mask all irqs */
-	out_be32(mm_gc->regs + GPIO_IER, 0xffffffff);
-	out_be32(mm_gc->regs + GPIO_IMR, 0);
+	mpc8xxx_gc->write_reg(mpc8xxx_gc->regs + GPIO_IER, 0xffffffff);
+	mpc8xxx_gc->write_reg(mpc8xxx_gc->regs + GPIO_IMR, 0);
 
 	irq_set_chained_handler_and_data(mpc8xxx_gc->irqn,
 					 mpc8xxx_gpio_irq_cascade, mpc8xxx_gc);
-
 	return 0;
+err:
+	iounmap(mpc8xxx_gc->regs);
+	return ret;
 }
 
 static int mpc8xxx_remove(struct platform_device *pdev)
@@ -447,7 +387,8 @@ static int mpc8xxx_remove(struct platform_device *pdev)
 		irq_domain_remove(mpc8xxx_gc->irq);
 	}
 
-	of_mm_gpiochip_remove(&mpc8xxx_gc->mm_gc);
+	gpiochip_remove(&mpc8xxx_gc->gc);
+	iounmap(mpc8xxx_gc->regs);
 
 	return 0;
 }
-- 
2.1.0.27.g96db324



From lkp at intel.com  Wed Feb  3 03:54:21 2016
From: lkp at intel.com (kbuild test robot)
Date: Wed, 3 Feb 2016 19:54:21 +0800
Subject: [PATCH v3 2/4] power: reset: add reboot mode driver
In-Reply-To: <1454407325-4804-1-git-send-email-andy.yan@rock-chips.com>
Message-ID: <201602031943.IyDJj4gO%fengguang.wu@intel.com>

Hi Andy,

[auto build test ERROR on rockchip/for-next]
[also build test ERROR on v4.5-rc2 next-20160203]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Andy-Yan/add-reboot-mode-driver/20160202-181909
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git for-next
config: x86_64-randconfig-r0-02031912 (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

warning: (SYSCON_REBOOT_MODE) selects REBOOT_MODE which has unmet direct dependencies (POWER_RESET && OF)
   drivers/power/reset/reboot-mode.c: In function 'reboot_mode_register':
>> drivers/power/reset/reboot-mode.c:79:2: error: implicit declaration of function 'for_each_property_of_node' [-Werror=implicit-function-declaration]
     for_each_property_of_node(dev->of_node, prop) {
     ^
>> drivers/power/reset/reboot-mode.c:79:48: error: expected ';' before '{' token
     for_each_property_of_node(dev->of_node, prop) {
                                                   ^
>> drivers/power/reset/reboot-mode.c:70:9: warning: unused variable 'len' [-Wunused-variable]
     size_t len = strlen(PREFIX);
            ^
>> drivers/power/reset/reboot-mode.c:68:20: warning: unused variable 'info' [-Wunused-variable]
     struct mode_info *info;
                       ^
   drivers/power/reset/reboot-mode.c: At top level:
   drivers/power/reset/reboot-mode.c:51:12: warning: 'reboot_mode_notify' defined but not used [-Wunused-function]
    static int reboot_mode_notify(struct notifier_block *this,
               ^
   cc1: some warnings being treated as errors

vim +/for_each_property_of_node +79 drivers/power/reset/reboot-mode.c

    62		return NOTIFY_DONE;
    63	}
    64	
    65	int reboot_mode_register(struct device *dev, int (*write)(int))
    66	{
    67		struct reboot_mode_driver *reboot;
  > 68		struct mode_info *info;
    69		struct property *prop;
  > 70		size_t len = strlen(PREFIX);
    71		int ret;
    72	
    73		reboot = devm_kzalloc(dev, sizeof(*reboot), GFP_KERNEL);
    74		if (!reboot)
    75			return -ENOMEM;
    76	
    77		reboot->write = write;
    78		INIT_LIST_HEAD(&reboot->head);
  > 79		for_each_property_of_node(dev->of_node, prop) {
    80			if (len > strlen(prop->name) || strncmp(prop->name, PREFIX, len))
    81				continue;
    82			info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 24266 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/17f6916f/attachment-0001.obj>

From juri.lelli at arm.com  Wed Feb  3 03:59:54 2016
From: juri.lelli at arm.com (Juri Lelli)
Date: Wed,  3 Feb 2016 11:59:54 +0000
Subject: [PATCH v3 1/6] ARM: initialize cpu_scale to its default
In-Reply-To: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
Message-ID: <1454500799-18451-2-git-send-email-juri.lelli@arm.com>

Instead of looping through all cpus calling set_capacity_scale, we can
initialise cpu_scale per-cpu variables to SCHED_CAPACITY_SCALE with their
definition.

Cc: Russell King <linux at arm.linux.org.uk>
Acked-by: Vincent Guittot <vincent.guittot at linaro.org>
Signed-off-by: Juri Lelli <juri.lelli at arm.com>
---
 arch/arm/kernel/topology.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 08b7847..ec279d1 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -40,7 +40,7 @@
  * to run the rebalance_domains for all idle cores and the cpu_capacity can be
  * updated during this sequence.
  */
-static DEFINE_PER_CPU(unsigned long, cpu_scale);
+static DEFINE_PER_CPU(unsigned long, cpu_scale) = SCHED_CAPACITY_SCALE;
 
 unsigned long arch_scale_cpu_capacity(struct sched_domain *sd, int cpu)
 {
@@ -306,8 +306,6 @@ void __init init_cpu_topology(void)
 		cpu_topo->socket_id = -1;
 		cpumask_clear(&cpu_topo->core_sibling);
 		cpumask_clear(&cpu_topo->thread_sibling);
-
-		set_capacity_scale(cpu, SCHED_CAPACITY_SCALE);
 	}
 	smp_wmb();
 
-- 
2.7.0



From juri.lelli at arm.com  Wed Feb  3 03:59:53 2016
From: juri.lelli at arm.com (Juri Lelli)
Date: Wed,  3 Feb 2016 11:59:53 +0000
Subject: [PATCH v3 0/6] CPUs capacity information for heterogeneous systems
Message-ID: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>

Hi all,

this is take 3 of "CPUs capacity information for heterogeneous systems"
patchset [1]; some context follows.

ARM systems may be configured to have CPUs with different power/performance
characteristics within the same chip. In this case, additional information has
to be made available to the kernel (the scheduler in particular) for it to be
aware of such differences and take decisions accordingly. This RFC stems from
the ongoing discussion about introducing a simple platform energy cost model to
guide scheduling decisions (a.k.a Energy Aware Scheduling [3]), but also aims
to be an independent track aimed to standardise the way we make the scheduler
aware of heterogenous CPU systems. With these patches and in addition patches
from [3] (that make the scheduler wakeup paths aware of heterogenous CPU
systems) we enable the scheduler to have good default performance on such
systems. In addition, we get a clearly defined way of providing the scheduler
with needed information about CPU capacity on such systems.

CPU capacity is defined in this context as a number that provides the scheduler
information about CPUs heterogeneity. Such heterogeneity can come from
micro-architectural differences (e.g., ARM big.LITTLE systems) or maximum
frequency at which CPUs can run (e.g., SMP systems with multiple frequency
domains and different max frequencies). Heterogeneity in this context is about
differing performance characteristics; in practice, the binding that we propose
in this RFC tries to capture a first-order approximation of the relative
performance of CPUs.

Several approaches for providing CPUs capacity information have been already
discussed on the list:

 v1: DT + sysfs [1]

 v2: Dynamic profiling at boot [2]

Third version of this patchset proposes what seems to be the solution we agreed
upon (see [2] for reference) to the problem of how do we init CPUs original
capacity: we run a bogus benchmark (stealing int_sqrt from lib/ we run that in
a loop to perform some integer computation, better benchmarks are welcome)
on the first cpu of each frequency domain (assuming no u-arch differences
inside domains), measure time to complete a fixed number of iterations and then
normalize results to SCHED_CAPACITY_SCALE (1024). This time around we also
added a boot time parameter to disable profiling at boot (as it can be time
consuming) and sysfs attributes with which default values can be overwritten.
The proposed solution is basically putting together bits of v1 and v2 that are
considered valuable and acceptable for mainline.

What follows gives you and idea of the kind of results you can expect comparing
the dynamic approach to profiling in userspace:

                          LITTLE      big

 TC2-userspace_profile     430        1024
 TC2-dynamic_profile      ~490        1024

 JUNO-userspace_profile    446        1024
 JUNO-dynamic_profile     ~424        1024

This time around we also decided to remove the RFC tag; even if patches might
still need some degree of improvement and discussion, there seems to be general
consensus about the idea behind the current solution (i.e., nobody NAKed it yet 
:)).

Patches high level description:

 o 01/06 cleans up how cpu_scale is initialized in arm (already landed on
   Russell's patch system)
 o 02/06 introduces dynamic profiling of CPUs capacity at boot
 o [03-04]/06 enable dynamic profiling for arm and arm64.
 o [05-06]/06 introduce sysfs attribute for arm and arm64.

The patchset is based on top of mainline as of today (4.5-rc2).

In case you would like to test this out, I pushed a branch here:

 git://linux-arm.org/linux-jl.git upstream/default_caps_v3

This branch contains additional patches, useful to better understand how CPU
capacity information is actually used by the scheduler. Discussion regarding
these additional patches will be started with a different posting in the
future. We just didn't want to make discussion too broad, as we realize that
this set can be controversial already on its own.

Comments, concerns and rants are more than welcome!

Best,

- Juri

[1] v1 - https://lkml.org/lkml/2015/11/23/391
[2] v2 - https://lkml.org/lkml/2016/1/8/417
[3] https://lkml.org/lkml/2015/7/7/754

Juri Lelli (6):
  ARM: initialize cpu_scale to its default
  drivers/cpufreq: implement init_cpu_capacity_default()
  arm: Enable dynamic CPU capacity initialization
  arm64: Enable dynamic CPU capacity initialization
  arm: add sysfs cpu_capacity attribute
  arm64: add sysfs cpu_capacity attribute

 Documentation/kernel-parameters.txt |   4 +
 arch/arm/kernel/topology.c          |  79 +++++++++++++++-
 arch/arm64/kernel/topology.c        |  85 ++++++++++++++++++
 drivers/cpufreq/Makefile            |   2 +-
 drivers/cpufreq/cpufreq.c           |   1 +
 drivers/cpufreq/cpufreq_capacity.c  | 174 ++++++++++++++++++++++++++++++++++++
 include/linux/cpufreq.h             |   2 +
 7 files changed, 342 insertions(+), 5 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_capacity.c

-- 
2.7.0



From juri.lelli at arm.com  Wed Feb  3 03:59:56 2016
From: juri.lelli at arm.com (Juri Lelli)
Date: Wed,  3 Feb 2016 11:59:56 +0000
Subject: [PATCH v3 3/6] arm: Enable dynamic CPU capacity initialization
In-Reply-To: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
Message-ID: <1454500799-18451-4-git-send-email-juri.lelli@arm.com>

Define arch_wants_init_cpu_capacity() to return true; so that
cpufreq_init_cpu_capacity() can go ahead and profile CPU capacities
at boot time.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Vincent Guittot <vincent.guittot at linaro.org>
Signed-off-by: Juri Lelli <juri.lelli at arm.com>
---
 arch/arm/kernel/topology.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index c9c87a5..7d7fc2c 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -52,6 +52,11 @@ void set_capacity_scale(unsigned int cpu, unsigned long capacity)
 	per_cpu(cpu_scale, cpu) = capacity;
 }
 
+bool arch_wants_init_cpu_capacity(void)
+{
+	return true;
+}
+
 #ifdef CONFIG_OF
 struct cpu_efficiency {
 	const char *compatible;
-- 
2.7.0



From juri.lelli at arm.com  Wed Feb  3 03:59:55 2016
From: juri.lelli at arm.com (Juri Lelli)
Date: Wed,  3 Feb 2016 11:59:55 +0000
Subject: [PATCH v3 2/6] drivers/cpufreq: implement init_cpu_capacity_default()
In-Reply-To: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
Message-ID: <1454500799-18451-3-git-send-email-juri.lelli@arm.com>

To get default values for CPUs capacity we profile a simple (bogus)
integer benchmark on such CPUs; then we normalize results to 1024
(highest capacity in the system).

Architectures that want this during boot have to define a weak function
(arch_wants_init_cpu_capacity) to return true.

Also, kernel has to boot with init_cpu_capacity parameter if profiling
is needed, as it can be expensive and might add ~1 sec to boot time.

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: "Rafael J. Wysocki" <rjw at rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar at linaro.org>
Cc: Vincent Guittot <vincent.guittot at linaro.org>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Juri Lelli <juri.lelli at arm.com>
---
 Changes since v1:
 - add kernel command line parameter to enable profiling
 - add define for max trials

 Documentation/kernel-parameters.txt |   4 +
 arch/arm/kernel/topology.c          |   2 +-
 arch/arm64/kernel/topology.c        |  12 +++
 drivers/cpufreq/Makefile            |   2 +-
 drivers/cpufreq/cpufreq.c           |   1 +
 drivers/cpufreq/cpufreq_capacity.c  | 174 ++++++++++++++++++++++++++++++++++++
 include/linux/cpufreq.h             |   2 +
 7 files changed, 195 insertions(+), 2 deletions(-)
 create mode 100644 drivers/cpufreq/cpufreq_capacity.c

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 87d40a7..fad2b89 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1570,6 +1570,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
 	initrd=		[BOOT] Specify the location of the initial ramdisk
 
+	init_cpu_capacity
+			[KNL,ARM] Enables dynamic CPUs capacity benchmarking
+			at boot.
+
 	inport.irq=	[HW] Inport (ATI XL and Microsoft) busmouse driver
 			Format: <irq>
 
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index ec279d1..c9c87a5 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -47,7 +47,7 @@ unsigned long arch_scale_cpu_capacity(struct sched_domain *sd, int cpu)
 	return per_cpu(cpu_scale, cpu);
 }
 
-static void set_capacity_scale(unsigned int cpu, unsigned long capacity)
+void set_capacity_scale(unsigned int cpu, unsigned long capacity)
 {
 	per_cpu(cpu_scale, cpu) = capacity;
 }
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 694f6de..3b75d63 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -23,6 +23,18 @@
 #include <asm/cputype.h>
 #include <asm/topology.h>
 
+static DEFINE_PER_CPU(unsigned long, cpu_scale) = SCHED_CAPACITY_SCALE;
+
+unsigned long arm_arch_scale_cpu_capacity(struct sched_domain *sd, int cpu)
+{
+	return per_cpu(cpu_scale, cpu);
+}
+
+void set_capacity_scale(unsigned int cpu, unsigned long capacity)
+{
+	per_cpu(cpu_scale, cpu) = capacity;
+}
+
 static int __init get_cpu_for_node(struct device_node *node)
 {
 	struct device_node *cpu_node;
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 9e63fb1..c4025fd 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -1,5 +1,5 @@
 # CPUfreq core
-obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o freq_table.o
+obj-$(CONFIG_CPU_FREQ)			+= cpufreq.o freq_table.o cpufreq_capacity.o
 
 # CPUfreq stats
 obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index e979ec7..b22afe8 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -2440,6 +2440,7 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data)
 	}
 
 	register_hotcpu_notifier(&cpufreq_cpu_notifier);
+	cpufreq_init_cpu_capacity();
 	pr_debug("driver %s up and running\n", driver_data->name);
 
 out:
diff --git a/drivers/cpufreq/cpufreq_capacity.c b/drivers/cpufreq/cpufreq_capacity.c
new file mode 100644
index 0000000..e54310b
--- /dev/null
+++ b/drivers/cpufreq/cpufreq_capacity.c
@@ -0,0 +1,174 @@
+/*
+ * Default CPU capacity calculation for u-arch invariance
+ *
+ * Copyright (C) 2015 ARM Ltd.
+ * Juri Lelli <juri.lelli at arm.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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include <linux/cpufreq.h>
+#include <linux/sched.h>
+
+#define MAX_TRIALS 10 /* how many times benchmark is executed */
+static unsigned long long elapsed[NR_CPUS];
+
+/*
+ * Don't let compiler optimize following two functions; we want to avoid any
+ * microarchitecture specific optimization that compiler would do and favour
+ * one CPU vs. another. Also, my_int_sqrt is cut-and-paste from
+ * lib/int_sqrt.c.
+ */
+static unsigned long __attribute__((optimize("O0")))
+my_int_sqrt(unsigned long x)
+{
+	unsigned long b, m, y = 0;
+
+	if (x <= 1)
+		return x;
+
+	m = 1UL << (BITS_PER_LONG - 2);
+	while (m != 0) {
+		b = y + m;
+		y >>= 1;
+
+		if (x >= b) {
+			x -= b;
+			y += m;
+		}
+		m >>= 2;
+	}
+
+	return y;
+}
+
+static unsigned long __attribute__((optimize("O0")))
+bogus_bench(void)
+{
+	unsigned long i, res;
+
+	for (i = 0; i < 100000; i++)
+		res = my_int_sqrt(i);
+
+	return res;
+}
+
+static int run_bogus_benchmark(int cpu)
+{
+	int ret, trials = MAX_TRIALS;
+	u64 begin, end, sample, mean = 0, count = 0;
+	unsigned long res;
+
+	ret = set_cpus_allowed_ptr(current, cpumask_of(cpu));
+	if (ret) {
+		pr_warn("%s: failed to set allowed ptr\n", __func__);
+		return -EINVAL;
+	}
+
+	while (trials--) {
+		begin = local_clock();
+		res = bogus_bench();
+		end = local_clock();
+		sample = end - begin;
+
+		mean = mean * count + sample;
+		mean = div64_u64(mean, ++count);
+		pr_debug("%s: cpu=%d begin=%llu end=%llu"
+			 " sample=%llu mean=%llu count=%llu res=%lu\n",
+			__func__, cpu, begin, end, sample,
+			mean, count, res);
+	}
+	elapsed[cpu] = mean;
+
+	ret = set_cpus_allowed_ptr(current, cpu_active_mask);
+	if (ret) {
+		pr_warn("%s: failed to set allowed ptr\n", __func__);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+bool __weak arch_wants_init_cpu_capacity(void)
+{
+	return false;
+}
+
+void __weak set_capacity_scale(int cpu, unsigned long capacity) { }
+
+static __read_mostly bool init_cpu_capacity_enabled;
+
+static int __init init_cpu_capacity_setup(char *str)
+{
+	init_cpu_capacity_enabled = true;
+
+	return 0;
+}
+early_param("init_cpu_capacity", init_cpu_capacity_setup);
+
+void cpufreq_init_cpu_capacity(void)
+{
+	int cpu, fcpu;
+	unsigned long long elapsed_min = ULLONG_MAX;
+	unsigned int curr_min, curr_max;
+	struct cpufreq_policy *policy;
+
+	if (!arch_wants_init_cpu_capacity() || !init_cpu_capacity_enabled)
+		return;
+
+	for_each_possible_cpu(cpu) {
+		policy = cpufreq_cpu_get(cpu);
+		if (IS_ERR_OR_NULL(policy))
+			return;
+
+		/*
+		 * We profile only first CPU of each frequency domain;
+		 * and use that value as capacity of every CPU in the domain.
+		 */
+		fcpu = cpumask_first(policy->related_cpus);
+		if (cpu != fcpu) {
+			elapsed[cpu] = elapsed[fcpu];
+			cpufreq_cpu_put(policy);
+			continue;
+		}
+
+		down_write(&policy->rwsem);
+		curr_min = policy->user_policy.min;
+		curr_max = policy->user_policy.max;
+		policy->user_policy.min = policy->cpuinfo.max_freq;
+		policy->user_policy.max = policy->cpuinfo.max_freq;
+		up_write(&policy->rwsem);
+		cpufreq_cpu_put(policy);
+		cpufreq_update_policy(cpu);
+
+		run_bogus_benchmark(cpu);
+		if (elapsed[cpu] < elapsed_min)
+			elapsed_min = elapsed[cpu];
+		pr_debug("%s: cpu=%d elapsed=%llu (min=%llu)\n",
+				__func__, cpu, elapsed[cpu], elapsed_min);
+
+		policy = cpufreq_cpu_get(cpu);
+		down_write(&policy->rwsem);
+		policy->user_policy.min = curr_min;
+		policy->user_policy.max = curr_max;
+		up_write(&policy->rwsem);
+		cpufreq_cpu_put(policy);
+		cpufreq_update_policy(cpu);
+	}
+
+	for_each_possible_cpu(cpu) {
+		unsigned long capacity;
+
+		capacity = div64_u64((elapsed_min << 10), elapsed[cpu]);
+		pr_debug("%s: CPU%d capacity=%lu\n", __func__, cpu, capacity);
+		set_capacity_scale(cpu, capacity);
+	}
+
+	pr_info("dynamic CPUs capacity installed\n");
+}
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 88a4215..9924351 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -419,6 +419,8 @@ static inline unsigned long cpufreq_scale(unsigned long old, u_int div,
 #endif
 }
 
+void cpufreq_init_cpu_capacity(void);
+
 /*********************************************************************
  *                          CPUFREQ GOVERNORS                        *
  *********************************************************************/
-- 
2.7.0



From juri.lelli at arm.com  Wed Feb  3 03:59:57 2016
From: juri.lelli at arm.com (Juri Lelli)
Date: Wed,  3 Feb 2016 11:59:57 +0000
Subject: [PATCH v3 4/6] arm64: Enable dynamic CPU capacity initialization
In-Reply-To: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
Message-ID: <1454500799-18451-5-git-send-email-juri.lelli@arm.com>

Define arch_wants_init_cpu_capacity() to return true; so that
cpufreq_init_cpu_capacity() can go ahead and profile CPU capacities
at boot time.

Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Juri Lelli <juri.lelli at arm.com>
---
 arch/arm64/kernel/topology.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 3b75d63..f2513a6 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -35,6 +35,11 @@ void set_capacity_scale(unsigned int cpu, unsigned long capacity)
 	per_cpu(cpu_scale, cpu) = capacity;
 }
 
+bool arch_wants_init_cpu_capacity(void)
+{
+	return true;
+}
+
 static int __init get_cpu_for_node(struct device_node *node)
 {
 	struct device_node *cpu_node;
-- 
2.7.0



From juri.lelli at arm.com  Wed Feb  3 03:59:59 2016
From: juri.lelli at arm.com (Juri Lelli)
Date: Wed,  3 Feb 2016 11:59:59 +0000
Subject: [PATCH v3 6/6] arm64: add sysfs cpu_capacity attribute
In-Reply-To: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
Message-ID: <1454500799-18451-7-git-send-email-juri.lelli@arm.com>

Add a sysfs cpu_capacity attribute with which it is possible to read and
write (thus over-writing default values) CPUs capacity. This might be
useful in situation where there is no way to get proper default values
at boot time.

The new attribute shows up as:

 /sys/devices/system/cpu/cpu*/cpu_capacity

Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Mark Brown <broonie at linaro.org>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Signed-off-by: Juri Lelli <juri.lelli at arm.com>
---
 arch/arm64/kernel/topology.c | 68 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index f2513a6..f05cc07 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -40,6 +40,74 @@ bool arch_wants_init_cpu_capacity(void)
 	return true;
 }
 
+#ifdef CONFIG_PROC_SYSCTL
+#include <asm/cpu.h>
+#include <linux/string.h>
+static ssize_t show_cpu_capacity(struct device *dev,
+				 struct device_attribute *attr,
+				 char *buf)
+{
+	struct cpu *cpu = container_of(dev, struct cpu, dev);
+	ssize_t rc;
+	int cpunum = cpu->dev.id;
+	unsigned long capacity = arch_scale_cpu_capacity(NULL, cpunum);
+
+	rc = sprintf(buf, "%lu\n", capacity);
+
+	return rc;
+}
+
+static ssize_t store_cpu_capacity(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf,
+				  size_t count)
+{
+	struct cpu *cpu = container_of(dev, struct cpu, dev);
+	int this_cpu = cpu->dev.id, i;
+	unsigned long new_capacity;
+	ssize_t ret;
+
+	if (count) {
+		char *p = (char *) buf;
+
+		ret = kstrtoul(p, 0, &new_capacity);
+		if (ret)
+			return ret;
+		if (new_capacity > SCHED_CAPACITY_SCALE)
+			return -EINVAL;
+
+		for_each_cpu(i, &cpu_topology[this_cpu].core_sibling)
+			set_capacity_scale(i, new_capacity);
+	}
+
+	return count;
+}
+
+static DEVICE_ATTR(cpu_capacity,
+		   0644,
+		   show_cpu_capacity,
+		   store_cpu_capacity);
+
+static int register_cpu_capacity_sysctl(void)
+{
+	int i;
+	struct device *cpu;
+
+	for_each_possible_cpu(i) {
+		cpu = get_cpu_device(i);
+		if (!cpu) {
+			pr_err("%s: too early to get CPU%d device!\n",
+			       __func__, i);
+			continue;
+		}
+		device_create_file(cpu, &dev_attr_cpu_capacity);
+	}
+
+	return 0;
+}
+late_initcall(register_cpu_capacity_sysctl);
+#endif
+
 static int __init get_cpu_for_node(struct device_node *node)
 {
 	struct device_node *cpu_node;
-- 
2.7.0



From juri.lelli at arm.com  Wed Feb  3 03:59:58 2016
From: juri.lelli at arm.com (Juri Lelli)
Date: Wed,  3 Feb 2016 11:59:58 +0000
Subject: [PATCH v3 5/6] arm: add sysfs cpu_capacity attribute
In-Reply-To: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
Message-ID: <1454500799-18451-6-git-send-email-juri.lelli@arm.com>

Add a sysfs cpu_capacity attribute with which it is possible to read and
write (thus over-writing default values) CPUs capacity. This might be
useful in situation where there is no way to get proper default values
at boot time.

The new attribute shows up as:

 /sys/devices/system/cpu/cpu*/cpu_capacity

Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Juri Lelli <juri.lelli at arm.com>
---
 arch/arm/kernel/topology.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 7d7fc2c..9ffba65 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -57,6 +57,74 @@ bool arch_wants_init_cpu_capacity(void)
 	return true;
 }
 
+#ifdef CONFIG_PROC_SYSCTL
+#include <asm/cpu.h>
+#include <linux/string.h>
+static ssize_t show_cpu_capacity(struct device *dev,
+				 struct device_attribute *attr,
+				 char *buf)
+{
+	struct cpu *cpu = container_of(dev, struct cpu, dev);
+	ssize_t rc;
+	int cpunum = cpu->dev.id;
+	unsigned long capacity = arch_scale_cpu_capacity(NULL, cpunum);
+
+	rc = sprintf(buf, "%lu\n", capacity);
+
+	return rc;
+}
+
+static ssize_t store_cpu_capacity(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf,
+				  size_t count)
+{
+	struct cpu *cpu = container_of(dev, struct cpu, dev);
+	int this_cpu = cpu->dev.id, i;
+	unsigned long new_capacity;
+	ssize_t ret;
+
+	if (count) {
+		char *p = (char *) buf;
+
+		ret = kstrtoul(p, 0, &new_capacity);
+		if (ret)
+			return ret;
+		if (new_capacity > SCHED_CAPACITY_SCALE)
+			return -EINVAL;
+
+		for_each_cpu(i, &cpu_topology[this_cpu].core_sibling)
+			set_capacity_scale(i, new_capacity);
+	}
+
+	return count;
+}
+
+static DEVICE_ATTR(cpu_capacity,
+		   0644,
+		   show_cpu_capacity,
+		   store_cpu_capacity);
+
+static int register_cpu_capacity_sysctl(void)
+{
+	int i;
+	struct device *cpu;
+
+	for_each_possible_cpu(i) {
+		cpu = get_cpu_device(i);
+		if (!cpu) {
+			pr_err("%s: too early to get CPU%d device!\n",
+			       __func__, i);
+			continue;
+		}
+		device_create_file(cpu, &dev_attr_cpu_capacity);
+	}
+
+	return 0;
+}
+late_initcall(register_cpu_capacity_sysctl);
+#endif
+
 #ifdef CONFIG_OF
 struct cpu_efficiency {
 	const char *compatible;
-- 
2.7.0



From Suzuki.Poulose at arm.com  Wed Feb  3 04:12:53 2016
From: Suzuki.Poulose at arm.com (Suzuki K. Poulose)
Date: Wed, 3 Feb 2016 12:12:53 +0000
Subject: [PATCH v1 2/5] arm64: add ARMv8.2 id_aa64mmfr2 boiler plate
In-Reply-To: <1454432611-21333-3-git-send-email-james.morse@arm.com>
References: <1454432611-21333-1-git-send-email-james.morse@arm.com>
 <1454432611-21333-3-git-send-email-james.morse@arm.com>
Message-ID: <56B1EEC5.9020506@arm.com>

On 02/02/16 17:03, James Morse wrote:
> ARMv8.2 adds a new feature register id_aa64mmfr2. This patch adds the
> cpu feature boiler plate used by the actual features in later patches.
>
> Signed-off-by: James Morse <james.morse at arm.com>


>   #define SYS_CNTFRQ_EL0			sys_reg(3, 3, 14, 0, 0)
>   #define SYS_CTR_EL0			sys_reg(3, 3, 0, 0, 1)
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index a84febc40db2..a4f665f95f9f 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -123,6 +123,10 @@ static struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
>   	ARM64_FTR_END,
>   };
>
> +static struct arm64_ftr_bits ftr_id_aa64mmfr2[] = {
> +	ARM64_FTR_END,

It will be good to see all the defined fields in id_aa64mmfr2 added here in
this patch. You could also move the definition of UA0 field from the next patch
to here.

Otherwise looks good.

Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>

Suzuki


From Suzuki.Poulose at arm.com  Wed Feb  3 04:16:29 2016
From: Suzuki.Poulose at arm.com (Suzuki K. Poulose)
Date: Wed, 3 Feb 2016 12:16:29 +0000
Subject: [PATCH v1 4/5] arm64: cpufeature: Test 'matches' pointer to find
 the end of the list
In-Reply-To: <1454432611-21333-5-git-send-email-james.morse@arm.com>
References: <1454432611-21333-1-git-send-email-james.morse@arm.com>
 <1454432611-21333-5-git-send-email-james.morse@arm.com>
Message-ID: <56B1EF9D.9060803@arm.com>

On 02/02/16 17:03, James Morse wrote:
> CPU feature code uses the desc field as a test to find the end of the list,
> this means every entry must have a description. This generates noise for
> entries in the list that aren't really features, but combinations of them.
> e.g.
>> CPU features: detected feature: Privileged Access Never
>> CPU features: detected feature: PAN and not UAO
>
> These combination features are needed for corner cases with alternatives,
> where cpu features interact.
>
> Change all walkers of the arm64_features[] and arm64_hwcaps[] lists to test
> 'matches' not 'desc', and only print 'desc' if it is non-NULL.

Makes sense.

Reviewed-by : Suzuki K Poulose <suzuki.poulose at arm.com>

Cheers
Suzuki



From stefan.wahren at i2se.com  Wed Feb  3 04:17:15 2016
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Wed, 3 Feb 2016 13:17:15 +0100
Subject: [PATCH v4] mmc: meson: Add driver for the SD/MMC host found on
 Amlogic MesonX SoCs
In-Reply-To: <1448988109-32630-1-git-send-email-carlo@caione.org>
References: <1448988109-32630-1-git-send-email-carlo@caione.org>
Message-ID: <56B1EFCB.1020508@i2se.com>

Hi Carlo,

Am 01.12.2015 um 17:41 schrieb Carlo Caione:
> From: Carlo Caione <carlo at endlessm.com>
>
> Add a driver for the SD/MMC host found on the Amlogic MesonX SoCs. This
> is an MMC controller which provides an interface between the application
> processor and various memory cards. It supports the SD specification
> v2.0 and the eMMC specification v4.41.
>
> This patch adds also the binding documentation.

according to Documentation/devicetree/bindings/submitting-patches.txt

the binding should be a separate patch in a series.

Stefan






From rafael at kernel.org  Wed Feb  3 04:18:18 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Wed, 3 Feb 2016 13:18:18 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFqSVZffQ7WNZqn9qSRibsCgG2rY26z_97agL+LhQRVGcg@mail.gmail.com>
References: <20160201232833.GR19432@atomide.com>
 <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>
 <20160202030533.GT19432@atomide.com>
 <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>
 <20160202163536.GU19432@atomide.com>
 <CAPDyKFosQjkHDVSvy67+hstjjFseXQP5WYXrJE19GgVFYJ099w@mail.gmail.com>
 <20160202234145.GC19432@atomide.com>
 <CAPDyKFqLi8xOUeoxUTAmif5QrOjVpV_2CDLv4hjO_C9iOnv+5Q@mail.gmail.com>
 <CAPDyKFqSVZffQ7WNZqn9qSRibsCgG2rY26z_97agL+LhQRVGcg@mail.gmail.com>
Message-ID: <CAJZ5v0iSu9_uNLZstKsC1mHi3A3GRxQc=WPU6Xa7BSiaNChNCA@mail.gmail.com>

On Wed, Feb 3, 2016 at 11:25 AM, Ulf Hansson <ulf.hansson at linaro.org> wrote:
>>
>> I don't see the problem, but of course you know omap for better than I do.
>>
>> So if you are concerned about this, perhaps adding a dev_dbg print
>> when the omap hwmod's ->runtime_suspend() callback returns zero could
>
> /s/runtime_suspend/runtime_resume

OK

Let me summarize my understanding of this thread so far.

It looks like the omap3 code initializes hardware in ->probe() and
then it may return -EPROBE_DEFER due to some unmet dependencies.  In
that case the hardware is not reset to the previous state and the
runtime PM framework is left in the state that corresponds to the
current hardware state.  Before we had pm_runtime_reinit(), everything
worked as expected on the second ->probe() call, because things were
in sync then.

The introduction of pm_runtime_reinit() changed the situation and now
effectively the hardware is required to be reset to the initial state
if -EPROBE_DEFER is to be returned too.

Is that correct?

Thanks,
Rafael


From broonie at kernel.org  Wed Feb  3 04:29:52 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 3 Feb 2016 12:29:52 +0000
Subject: [PATCH V4 2/2] regulator: mt6323: Add support for MT6323 regulator
In-Reply-To: <1454477942.31375.32.camel@mtksdaap41>
References: <1453896059-44589-1-git-send-email-blogic@openwrt.org>
 <1453896059-44589-2-git-send-email-blogic@openwrt.org>
 <20160127144105.GQ6042@sirena.org.uk>
 <56AA5A5C.9080402@openwrt.org>
 <20160128231306.GD4130@sirena.org.uk>
 <1454061134.10861.14.camel@mtksdaap41>
 <20160129112717.GP4130@sirena.org.uk>
 <1454069479.10861.30.camel@mtksdaap41>
 <20160202193839.GX4455@sirena.org.uk>
 <1454477942.31375.32.camel@mtksdaap41>
Message-ID: <20160203122952.GF4455@sirena.org.uk>

On Wed, Feb 03, 2016 at 01:39:02PM +0800, menghui lin wrote:
> On Tue, 2016-02-02 at 19:38 +0000, Mark Brown wrote:

> > How does the driver know if it needs to change the mode (ie, how can it
> > tell if the current mode is inadequate) and surely if we can only change
> > in one direction this isn't terribly useful?

> I think the datasheet of buck/ldo could provide information about power
> capability of each mode. The driver should adjust regulator mode per its
> device's power requirement.

That's of no help for a consumer driver which doesn't know what
regulator is supplying it.

> case 1:

> We have a USB typeC micro-controller, which has two modes - standby and
> normal. It requires 1.8V and 3.3V to operate (both powers are always
> on). The device stays in standby mode when there is no cable in. When
> cable in, we got an interrupt and change device into normal mode.

> The standby mode power consumption is quite small, so we would like the
> change mode of regulator into STANDBY to save more power. And we change
> into NORMAL when we receive cable-in interrupt.

This seems like something that we ought to be doing via runtime PM
anyway which should be going through the suspend mode bindings, though
that would need some plumbing in.

> case 2:

> About buck regulator for CPU, it usually provides PWM mode, PWM/PFM Auto
> mode, PFM mode. I think it could map to FAST, NORMAL, IDLE mode
> respectively. Most of time we would use just normal mode. However, we
> would change regulator into PWM mode time to time to test buck output
> performance on the tested board.

That's a test use that doesn't seem a good fit for upstream at all.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/fa4e9220/attachment-0001.sig>

From maxime.ripard at free-electrons.com  Wed Feb  3 04:35:34 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 3 Feb 2016 13:35:34 +0100
Subject: [PATCH v2 2/5] dts: sun8i-h3: Add APB0 related clocks and resets
In-Reply-To: <1454448113-18810-3-git-send-email-k@japko.eu>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
 <1454448113-18810-3-git-send-email-k@japko.eu>
Message-ID: <20160203123534.GG4652@lukather>

Hi,

On Tue, Feb 02, 2016 at 10:21:50PM +0100, Krzysztof Adamski wrote:
> APB0 is bearly mentioned in H3 User Manual and it is only setup in the
> Allwinners kernel dump for CIR. I have verified experimentally that the
> gate for R_PIO exists and works, though. There are probably other gates
> there but I don't know their order right now and I don't have access to
> their peripherals on my board to test them.
> 
> Signed-off-by: Krzysztof Adamski <k at japko.eu>
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 32 ++++++++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 1524130e..ce35e93 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -276,6 +276,32 @@
>  			clocks = <&osc24M>, <&pll6 1>, <&pll5>;
>  			clock-output-names = "mbus";
>  		};
> +
> +		ahb0: ahb0_clk {
> +			compatible = "fixed-factor-clock";
> +			#clock-cells = <0>;
> +			clock-div = <1>;
> +			clock-mult = <1>;
> +			clocks = <&osc24M>, <&osc32k>;
> +			clock-output-names = "ahb0";
> +		};

I'm not sure what you mean there. The fixed factor clocks only take a
single parent, and you provided two.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/1086294a/attachment.sig>

From maxime.ripard at free-electrons.com  Wed Feb  3 04:36:18 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 3 Feb 2016 13:36:18 +0100
Subject: [PATCH v2 3/5] pinctrl: sunxi: Add H3 R_PIO controller support
In-Reply-To: <1454448113-18810-4-git-send-email-k@japko.eu>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
 <1454448113-18810-4-git-send-email-k@japko.eu>
Message-ID: <20160203123618.GH4652@lukather>

On Tue, Feb 02, 2016 at 10:21:51PM +0100, Krzysztof Adamski wrote:
> H3 has additional PIO controller similar to what we can find on A23.
> It's a 12 pin port, described in H3 Datasheet rev 1.1, pages 345-350.
> 
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/79ba258a/attachment.sig>

From Suzuki.Poulose at arm.com  Wed Feb  3 04:38:57 2016
From: Suzuki.Poulose at arm.com (Suzuki K. Poulose)
Date: Wed, 3 Feb 2016 12:38:57 +0000
Subject: [PATCH v1 3/5] arm64: kernel: Add support for User Access Override
In-Reply-To: <1454432611-21333-4-git-send-email-james.morse@arm.com>
References: <1454432611-21333-1-git-send-email-james.morse@arm.com>
 <1454432611-21333-4-git-send-email-james.morse@arm.com>
Message-ID: <56B1F4E1.4050603@arm.com>

On 02/02/16 17:03, James Morse wrote:
> 'User Access Override' is a new ARMv8.2 feature which allows the
> unprivileged load and store instructions to be overridden to behave in
> the normal way.
>
> This patch converts {get,put}_user() and friends to use ldtr*/sttr*
> instructions - so that they can only access EL0 memory, then enables
> UAO when fs==KERNEL_DS so that these functions can access kernel memory.
>
> This allows user space's read/write permissions to be checked against the
> page tables, instead of testing addr<USER_DS, then using the kernel's
> read/write permissions.
>

> +
> +#ifdef CONFIG_ARM64_UAO
> +/*
> + * Kernel threads have fs=KERNEL_DS by default, and don't need to call
> + * set_fs(), devtmpfs in particular relies on this behaviour.
> + * We need to enable the feature at runtime (instead of adding it to
> + * PSR_MODE_EL1h) as the feature may not be implemented by the cpu.
> + */
> +void cpu_enable_uao(void *__unused)
> +{
> +	asm(SET_PSTATE_UAO(1));
> +}
> +#endif /* CONFIG_ARM64_UAO */

Could this be moved to arch/arm64/mm/fault.c, just like cpu_enable_pan() ?

> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 92ddac1e8ca2..5ce2656b04df 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -192,6 +192,14 @@ out:
>   	return fault;
>   }
>
> +static inline int permission_fault(unsigned int esr)
> +{
> +	unsigned int ec       = (esr & ESR_ELx_EC_MASK)>>ESR_ELx_EC_SHIFT;

nit: space before and after >> ?

Suzuki


From nathan at nathanrossi.com  Wed Feb  3 04:41:05 2016
From: nathan at nathanrossi.com (Nathan Rossi)
Date: Wed,  3 Feb 2016 22:41:05 +1000
Subject: [PATCH] ARM: dts: zynq: Enable USB and USB PHY for ZYBO
Message-ID: <1454503265-20605-1-git-send-email-nathan@nathanrossi.com>

Setup the USB controller and configure it to operate in host mode.
Additionally add the USB phy node for the ZYBO, including reset gpio
which is connected to a external MIO pin.

Signed-off-by: Nathan Rossi <nathan at nathanrossi.com>
Cc: Rob Herring <robh+dt at kernel.org>
Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Michal Simek <michal.simek at xilinx.com>
Cc: S?ren Brinkmann <soren.brinkmann at xilinx.com>
---
 arch/arm/boot/dts/zynq-zybo.dts | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/zynq-zybo.dts b/arch/arm/boot/dts/zynq-zybo.dts
index 16c9cac..8f085b3 100644
--- a/arch/arm/boot/dts/zynq-zybo.dts
+++ b/arch/arm/boot/dts/zynq-zybo.dts
@@ -33,6 +33,11 @@
 		stdout-path = "serial0:115200n8";
 	};
 
+	usb_phy0: phy0 {
+		#phy-cells = <0>;
+		compatible = "usb-nop-xceiv";
+		reset-gpios = <&gpio0 46 1>;
+	};
 };
 
 &clkc {
@@ -56,3 +61,9 @@
 &uart1 {
 	status = "okay";
 };
+
+&usb0 {
+	status = "okay";
+	dr_mode = "host";
+	usb-phy = <&usb_phy0>;
+};
-- 
2.7.0



From christoffer.dall at linaro.org  Wed Feb  3 04:50:47 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 3 Feb 2016 13:50:47 +0100
Subject: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
In-Reply-To: <20160201140351.GE6828@arm.com>
References: <1453813968-2024-1-git-send-email-eric.auger@linaro.org>
 <1454017899.23148.0.camel@redhat.com> <56AB78B1.2030202@linaro.org>
 <1454096004.9301.1.camel@redhat.com> <56ABD8E0.6080409@linaro.org>
 <20160201140351.GE6828@arm.com>
Message-ID: <20160203125047.GB13974@cbox>

On Mon, Feb 01, 2016 at 02:03:51PM +0000, Will Deacon wrote:
> On Fri, Jan 29, 2016 at 10:25:52PM +0100, Eric Auger wrote:
> > On 01/29/2016 08:33 PM, Alex Williamson wrote:
> > >>> We know that x86 handles MSI vectors specially, so there is some
> > >>> hardware that helps the situation.  It's not just that x86 has a fixed
> > >>> range for MSI, it's how it manages that range when interrupt remapping
> > >>> hardware is enabled.  A device table indexed by source-ID references a
> > >>> per device table indexed by data from the MSI write itself.  So we get
> > >>> much, much finer granularity,
> > >> About the granularity, I think ARM GICv3 now provides a similar
> > >> capability with GICv3 ITS (interrupt translation service). Along with
> > >> the MSI MSG write transaction, the device outputs a DeviceID conveyed on
> > >> the bus. This DeviceID (~ your source-ID) enables to index a device
> > >> table. The entry in the device table points to a DeviceId interrupt
> > >> translation table indexed by the EventID found in the msi msg. So the
> > >> entry in the interrupt translation table eventually gives you the
> > >> eventual interrupt ID targeted by the MSI MSG.
> > >> This translation capability if not available in GICv2M though, ie. the
> > >> one I am currently using.
> > >>  
> > >> Those tables currently are built by the ITS irqchip (irq-gic-v3-its.c)
> 
> That's right. GICv3/ITS disambiguates the interrupt source using the
> DeviceID, which for PCI is derived from the Requester ID of the endpoint.
> GICv2m is less flexible and requires a separate physical frame per guest
> to achieve isolation.
> 
We should still support MSI passthrough with a single MSI frame host
system though, right?

(Users should just be aware that guests are not fully protected against
misbehaving hardware in that case).

-Christoffer


From catalin.marinas at arm.com  Wed Feb  3 04:57:38 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 3 Feb 2016 12:57:38 +0000
Subject: [PATCH v4 4/7] arm64: Handle early CPU boot failures
In-Reply-To: <1453745225-27736-5-git-send-email-suzuki.poulose@arm.com>
References: <1453745225-27736-1-git-send-email-suzuki.poulose@arm.com>
 <1453745225-27736-5-git-send-email-suzuki.poulose@arm.com>
Message-ID: <20160203125735.GA26487@MBP.local>

Hi Suzuki,

On Mon, Jan 25, 2016 at 06:07:02PM +0000, Suzuki K. Poulose wrote:
> +/* Values for secondary_data.status */
> +
> +#define CPU_MMU_OFF		-1
> +#define CPU_BOOT_SUCCESS	0
> +/* The cpu invoked ops->cpu_die, synchronise it with cpu_kill */
> +#define CPU_KILL_ME		1
> +/* The cpu couldn't die gracefully and is looping in the kernel */
> +#define CPU_STUCK_IN_KERNEL	2
> +/* Fatal system error detected by secondary CPU, crash the system */
> +#define CPU_PANIC_KERNEL	3

Please add braces around these numbers, just in case (I added them
locally).

>  /*
> + * The booting CPU updates the failed status, with MMU turned off,
> + * below which lies in head.txt to make sure it doesn't share the same writeback
> + * granule. So that we can invalidate it properly.

I can't really parse this (it looks like punctuation in the wrong place;
also "share the same..." with what?).

> + *
> + * update_early_cpu_boot_status tmp, status
> + *  - Corrupts tmp, x0, x1
> + *  - Writes 'status' to __early_cpu_boot_status and makes sure
> + *    it is committed to memory.
> + */
> +
> +	.macro	update_early_cpu_boot_status tmp, status
> +	mov	\tmp, lr
> +	adrp	x0, __early_cpu_boot_status
> +	add	x0, x0, #:lo12:__early_cpu_boot_status

Nitpick: you could use the adr_l macro.

> +	mov	x1, #\status
> +	str	x1, [x0]
> +	add	x1, x0, 4
> +	bl	__inval_cache_range
> +	mov	lr, \tmp
> +	.endm

If the CPU that's currently booting has the MMU off, what's the point of
invalidating the cache here? The operation may not even be broadcast to
the other CPU. So you actually need the invalidation before reading the
status on the primary CPU.

> +
> +ENTRY(__early_cpu_boot_status)
> +	.long 	0
> +END(__early_cpu_boot_status)

I think we should just do like __boot_cpu_mode and place it in the
.data..cacheline_aligned section. You can always use the safe
clean+invalidate before reading the value so that we don't care much
about the write-back granule.

> @@ -89,12 +101,14 @@ static DECLARE_COMPLETION(cpu_running);
>  int __cpu_up(unsigned int cpu, struct task_struct *idle)
>  {
>  	int ret;
> +	int status;
>  
>  	/*
>  	 * We need to tell the secondary core where to find its stack and the
>  	 * page tables.
>  	 */
>  	secondary_data.stack = task_stack_page(idle) + THREAD_START_SP;
> +	update_cpu_boot_status(CPU_MMU_OFF);
>  	__flush_dcache_area(&secondary_data, sizeof(secondary_data));
>  
>  	/*
> @@ -117,7 +131,35 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
>  		pr_err("CPU%u: failed to boot: %d\n", cpu, ret);
>  	}
>  
> +	/* Make sure the update to status is visible */
> +	smp_rmb();

Which status? In relation to what?

>  	secondary_data.stack = NULL;
> +	status = READ_ONCE(secondary_data.status);
> +	if (ret && status) {
> +
> +		if (status == CPU_MMU_OFF)
> +			status = READ_ONCE(__early_cpu_boot_status);

You need cache maintenance before reading this.

> +
> +		switch (status) {
> +		default:
> +			pr_err("CPU%u: failed in unknown state : 0x%x\n",
> +					cpu, status);
> +			break;
> +		case CPU_KILL_ME:
> +			if (!op_cpu_kill(cpu)) {
> +				pr_crit("CPU%u: died during early boot\n", cpu);
> +				break;
> +			}
> +			/* Fall through */
> +			pr_crit("CPU%u: may not have shut down cleanly\n", cpu);
> +		case CPU_STUCK_IN_KERNEL:
> +			pr_crit("CPU%u: is stuck in kernel\n", cpu);
> +			cpus_stuck_in_kernel++;
> +			break;
> +		case CPU_PANIC_KERNEL:
> +			panic("CPU%u detected unsupported configuration\n", cpu);
> +		}
> +	}
>  
>  	return ret;
>  }

BTW, you can send a fix-up on top of this series with corrections, I can
fold them in.

-- 
Catalin


From rafael at kernel.org  Wed Feb  3 05:03:49 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Wed, 3 Feb 2016 14:03:49 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160202213916.GA19432@atomide.com>
References: <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602021112320.1653-100000@iolanthe.rowland.org>
 <CAPDyKFokWcLSCAh_TX-j-df_M1hN8Qw1gbQt--SyWccGCPiN5Q@mail.gmail.com>
 <20160202213916.GA19432@atomide.com>
Message-ID: <CAJZ5v0if-OCynmN1qzBaWLHOEEHN6kJe1LCbJ=eOwUj6=iZDaw@mail.gmail.com>

On Tue, Feb 2, 2016 at 10:39 PM, Tony Lindgren <tony at atomide.com> wrote:
> * Ulf Hansson <ulf.hansson at linaro.org> [160202 12:25]:
>> >
>> > ?  pm_runtime_put_sync() _already_ does not respect the autosuspend
>> > mode.  If you want to respect it, you have to call
>> > pm_runtime_put_sync_autosuspend() instead.
>>
>> Then there's a bug in the runtime PM core.
>>
>> From Tony's regression report and from mine own local runtime PM test
>> driver, I can see that the device doesn't get RPM_SUSPENDED (the
>> ->runtime_suspend() callback isn't called), even when the usage count
>> is zero - when pm_runtime_put_sync() is called.
> ...
>> Okay, so you are saying that the pm_runtime_put_sync() should idle the
>> device even if autosuspend is in use. That seems reasonable, I will
>> look into this problem.
>
> The patch below fixes pm_runtime_put_sync() to not respect the
> autosuspend mode to match what Alan is saying above. Seems to also
> fixes the $subject issue for me. And seems to behave for PM runtime
> for other devices during runtime too based on light testing here.
>
> Regards,
>
> Tony
>
> 8< ---------------
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -353,7 +353,9 @@ static int rpm_idle(struct device *dev, int rpmflags)
>
>   out:
>         trace_rpm_return_int(dev, _THIS_IP_, retval);
> -       return retval ? retval : rpm_suspend(dev, rpmflags | RPM_AUTO);
> +       if (!(rpmflags & RPM_IGNORE_AUTO))
> +               rpmflags |= RPM_AUTO;
> +       return retval ? retval : rpm_suspend(dev, rpmflags);
>  }
>
>  /**
> --- a/include/linux/pm_runtime.h
> +++ b/include/linux/pm_runtime.h
> @@ -23,6 +23,8 @@
>                                             usage_count */
>  #define RPM_AUTO               0x08    /* Use autosuspend_delay */
>
> +#define RPM_IGNORE_AUTO                0x10    /* Ignore autosuspend */
> +
>  #ifdef CONFIG_PM
>  extern struct workqueue_struct *pm_wq;
>
> @@ -241,7 +243,7 @@ static inline int pm_runtime_put_autosuspend(struct device *dev)
>
>  static inline int pm_runtime_put_sync(struct device *dev)
>  {
> -       return __pm_runtime_idle(dev, RPM_GET_PUT);
> +       return __pm_runtime_idle(dev, RPM_GET_PUT | RPM_IGNORE_AUTO);
>  }
>
>  static inline int pm_runtime_put_sync_suspend(struct device *dev)

This changes a well-documented behavior that someone may be relying on.

Not the safest thing to do I have to say.

Thanks,
Rafael


From rafael at kernel.org  Wed Feb  3 05:06:13 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Wed, 3 Feb 2016 14:06:13 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160202234626.GD19432@atomide.com>
References: <20160202210345.GZ19432@atomide.com>
 <Pine.LNX.4.44L0.1602021626540.1653-100000@iolanthe.rowland.org>
 <20160202234626.GD19432@atomide.com>
Message-ID: <CAJZ5v0jbOJc2m=cBrvAuMUHvY8_AQPdJEyt1w-dPikU5expeLA@mail.gmail.com>

On Wed, Feb 3, 2016 at 12:46 AM, Tony Lindgren <tony at atomide.com> wrote:
> * Alan Stern <stern at rowland.harvard.edu> [160202 13:46]:
>> On Tue, 2 Feb 2016, Tony Lindgren wrote:
>>
>> > > Also, what is autosuspend_delay set to for your device?  And is
>> > > runtime_auto set?
>> >
>> > It's 100 at that point, see the commented snippet below from
>> > omap_hsmmc_probe():
>> >
>> >     pm_runtime_enable(host->dev);
>> >     pm_runtime_get_sync(host->dev);
>> >     pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY);
>> >     /* NOTE: pm_runtime_dont_use_autosuspend(host->dev) needed here? */
>> >     pm_runtime_use_autosuspend(host->dev);
>> >     ...
>> >     /* gets -EPROBE_DEFER */
>> > err_irq:
>> >     ...
>> >     pm_runtime_put_sync(host->dev);
>>
>> You could try changing this to pm_runtime_put_sync_suspend().  But
>> putting pm_runtime_dont_use_autosuspend() before the put_sync seems
>> like a perfectly reasonable thing to do, especially if you feel you
>> should reverse all the changes you made at the start.
>
> They both seem to fix the problem.
>
>> >         pm_runtime_disable(host->dev);
>> >     /* NOTE: suspend callback never gets called unless
>> >      * pm_runtime_dont_use_autosuspend() is called
>> >      * before pm_runtime_put_sync() above.
>> >      */
>> >      ...
>> >
>> > > > > Does pm_runtime_use_autosuspend() get called by the probe routine?  If
>> > > > > it does, then perhaps you can get what you want by having the probe
>> > > > > routine call pm_runtime_dont_use_autosuspend() whenever it's about to
>> > > > > return an error -- particularly -EDEFER.
>> > > >
>> > > > Yes so far that's the only fix that seems to work like I posted
>> > > > earlier. But is that the right fix though?
>> > >
>> > > No, not really.  Ideally you would leave autosuspend turned on.  The
>> > > delay would be long enough to that after -EDEFER, another probe would
>> > > start before the delay expired.  But shortly after the last probe
>> > > attempt, the delay would expire and the device would then be put in low
>> > > power.
>> >
>> > But then what about the new reinit function? To me it seems that
>> > we should not attempt to maintain a state from the earlier failed
>> > probe. Or are you thinking we just skip the reinit if autosuspend
>> > is set?
>>
>> The reinit function gets called too late to do what you want -- namely,
>> put the hardware in a low-power state.
>
> Right, the problem is the lack of suspend on the first probe. But
> for having autosuspend timeout long enough for the next probe
> would mean that we can't reset the PM runtime state in between.
>
>> That _is_ what you want, isn't it?  The alternative is to leave
>> dev->power.rpm_status set to RPM_ACTIVE, to match the hardware's actual
>> state.
>
> As far as I can tell things work just fine if the failed probe
> suspend the device at the end of the failed probe.
>
>> Given that the reinit function is supposed to restore the initial
>> settings, it probably ought to call pm_runtime_dont_use_autosuspend().
>> But that won't be enough to fix your problem.
>>
>> > > > If we wanted to have some generic fix, it seems we would have to pass
>> > > > a new flag in pm_runtime_put_sync() to ignore any autosuspend
>> > > > configuration. But I don't know if that's what we want to or should
>> > > > do though?
>> > >
>> > > I don't think so.
>> >
>> > So should we just establish a policy that pm_runtime_use_autosuspend()
>> > needs to be paired with pm_runtime_dont_use_autosuspend() for
>> > pm_runtime_put_sync() to work?
>>
>> Your understanding is slightly wrong.  pm_runtime_put_sync() _does_
>> work -- that is, it does what it's supposed to do.  The difficulty is
>> that what it's supposed to do doesn't match what you think.
>>
>> pm_runtime_put_sync() is supposed to follow the driver's wishes.  It
>> invokes the driver's runtime_idle callback if there is one, and the
>> callback routine can start a suspend or an autosuspend.  If there is no
>> callback, it will use whatever autosuspend setting the driver has set
>> up.  If you want to override the autosuspend setting, use
>> pm_runtime_put_sync_suspend() instead.
>
> Yes.. That works too. I guess the thing to consider is if we should
> make pm_runtime_put_sync() always sync along the lines of a patch
> I posted earlier today. That could avoid quite a bit of confusion
> as already seen in this thread :)

No, we shouldn't.

As I said, the current behavior is actually well documented (in
kerneldoc comments and elsewhere).

Thanks,
Rafael


From will.deacon at arm.com  Wed Feb  3 05:10:58 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 3 Feb 2016 13:10:58 +0000
Subject: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
In-Reply-To: <20160203125047.GB13974@cbox>
References: <1453813968-2024-1-git-send-email-eric.auger@linaro.org>
 <1454017899.23148.0.camel@redhat.com> <56AB78B1.2030202@linaro.org>
 <1454096004.9301.1.camel@redhat.com> <56ABD8E0.6080409@linaro.org>
 <20160201140351.GE6828@arm.com> <20160203125047.GB13974@cbox>
Message-ID: <20160203131057.GA20217@arm.com>

On Wed, Feb 03, 2016 at 01:50:47PM +0100, Christoffer Dall wrote:
> On Mon, Feb 01, 2016 at 02:03:51PM +0000, Will Deacon wrote:
> > On Fri, Jan 29, 2016 at 10:25:52PM +0100, Eric Auger wrote:
> > > On 01/29/2016 08:33 PM, Alex Williamson wrote:
> > > >>> We know that x86 handles MSI vectors specially, so there is some
> > > >>> hardware that helps the situation.  It's not just that x86 has a fixed
> > > >>> range for MSI, it's how it manages that range when interrupt remapping
> > > >>> hardware is enabled.  A device table indexed by source-ID references a
> > > >>> per device table indexed by data from the MSI write itself.  So we get
> > > >>> much, much finer granularity,
> > > >> About the granularity, I think ARM GICv3 now provides a similar
> > > >> capability with GICv3 ITS (interrupt translation service). Along with
> > > >> the MSI MSG write transaction, the device outputs a DeviceID conveyed on
> > > >> the bus. This DeviceID (~ your source-ID) enables to index a device
> > > >> table. The entry in the device table points to a DeviceId interrupt
> > > >> translation table indexed by the EventID found in the msi msg. So the
> > > >> entry in the interrupt translation table eventually gives you the
> > > >> eventual interrupt ID targeted by the MSI MSG.
> > > >> This translation capability if not available in GICv2M though, ie. the
> > > >> one I am currently using.
> > > >>  
> > > >> Those tables currently are built by the ITS irqchip (irq-gic-v3-its.c)
> > 
> > That's right. GICv3/ITS disambiguates the interrupt source using the
> > DeviceID, which for PCI is derived from the Requester ID of the endpoint.
> > GICv2m is less flexible and requires a separate physical frame per guest
> > to achieve isolation.
> > 
> We should still support MSI passthrough with a single MSI frame host
> system though, right?

I think we should treat the frame as an exclusive resource and assign it
to a single VM.

> (Users should just be aware that guests are not fully protected against
> misbehaving hardware in that case).

Is it confined to misbehaving hardware? What if a malicious/buggy guest
configures its device to DMA all over the doorbell?

Will


From arnd at arndb.de  Wed Feb  3 05:21:48 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 03 Feb 2016 14:21:48 +0100
Subject: [PATCH] [RFC] ARM: modify pgd_t definition for
 TRANSPARENT_HUGEPAGE_PUD
Message-ID: <1773775.QWf7OyDGPh@wuerfel>

I ran into build errors on ARM after Willy's newly added generic
TRANSPARENT_HUGEPAGE_PUD support. We don't support this feature
on ARM at all, but the patch causes a build error anyway:

In file included from ../kernel/memremap.c:17:0:
../include/linux/pfn_t.h:108:7: error: 'pud_mkdevmap' declared as function returning an array
 pud_t pud_mkdevmap(pud_t pud);

We don't use a PUD on ARM, so pud_t is defined as pmd_t, which
in turn is defined as

typedef unsigned long pgd_t[2];

on NOMMU and on 2-level MMU configurations. There is an (unused)
other definition using a struct around the array, which happens to
work fine here.

There is a comment in the file about the fact the other version
is "easier on the compiler", and I've traced that version back
to linux-2.1.80 when ARM support was first merged back in 1998.

It's probably a safe assumption that this is no longer necessary:
The same logic existed in asm-i386 at the time but was removed
a year later in 2.3.23pre3. The STRICT_MM_TYPECHECKS logic
also ended up getting copied into these files:

arch/alpha/include/asm/page.h
arch/arc/include/asm/page.h
arch/arm/include/asm/pgtable-3level-types.h
arch/arm64/include/asm/pgtable-types.h
arch/ia64/include/asm/page.h
arch/parisc/include/asm/page.h
arch/powerpc/include/asm/page.h
arch/sparc/include/asm/page_32.h
arch/sparc/include/asm/page_64.h
arch/tile/include/asm/page.h
arch/unicore32/include/asm/page.h

We should probably remove it everywhere, but for the moment,
this minimal patch gets things to compile on linux-next.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: a27da20ed50e ("mm: add support for PUD-sized transparent hugepages")

diff --git a/arch/arm/include/asm/page-nommu.h b/arch/arm/include/asm/page-nommu.h
index d1b162a18dcb..3db1ca22fecb 100644
--- a/arch/arm/include/asm/page-nommu.h
+++ b/arch/arm/include/asm/page-nommu.h
@@ -31,12 +31,12 @@
  */
 typedef unsigned long pte_t;
 typedef unsigned long pmd_t;
-typedef unsigned long pgd_t[2];
+typedef struct { unsigned long pgd[2]; } pgd_t;
 typedef unsigned long pgprot_t;
 
 #define pte_val(x)      (x)
 #define pmd_val(x)      (x)
-#define pgd_val(x)	((x)[0])
+#define pgd_val(x)	((x).pgd[0])
 #define pgprot_val(x)   (x)
 
 #define __pte(x)        (x)
diff --git a/arch/arm/include/asm/pgtable-2level-types.h b/arch/arm/include/asm/pgtable-2level-types.h
index 66cb5b0e89c5..9b9815d5ebd6 100644
--- a/arch/arm/include/asm/pgtable-2level-types.h
+++ b/arch/arm/include/asm/pgtable-2level-types.h
@@ -24,6 +24,9 @@
 typedef u32 pteval_t;
 typedef u32 pmdval_t;
 
+typedef struct { pmdval_t pgd[2]; } pgd_t;
+#define pgd_val(x)	((x).pgd[0])
+
 #undef STRICT_MM_TYPECHECKS
 
 #ifdef STRICT_MM_TYPECHECKS
@@ -32,12 +35,10 @@ typedef u32 pmdval_t;
  */
 typedef struct { pteval_t pte; } pte_t;
 typedef struct { pmdval_t pmd; } pmd_t;
-typedef struct { pmdval_t pgd[2]; } pgd_t;
 typedef struct { pteval_t pgprot; } pgprot_t;
 
 #define pte_val(x)      ((x).pte)
 #define pmd_val(x)      ((x).pmd)
-#define pgd_val(x)	((x).pgd[0])
 #define pgprot_val(x)   ((x).pgprot)
 
 #define __pte(x)        ((pte_t) { (x) } )
@@ -50,12 +51,10 @@ typedef struct { pteval_t pgprot; } pgprot_t;
  */
 typedef pteval_t pte_t;
 typedef pmdval_t pmd_t;
-typedef pmdval_t pgd_t[2];
 typedef pteval_t pgprot_t;
 
 #define pte_val(x)      (x)
 #define pmd_val(x)      (x)
-#define pgd_val(x)	((x)[0])
 #define pgprot_val(x)   (x)
 
 #define __pte(x)        (x)



From cyrille.pitchen at atmel.com  Wed Feb  3 05:26:45 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 14:26:45 +0100
Subject: [PATCH v3 00/14] mtd: spi-nor: add driver for Atmel QSPI controller
Message-ID: <cover.1454505161.git.cyrille.pitchen@atmel.com>

Hi all,

This series of patches adds support to the Atmel QSPI controller available
on sama5d2 SoCs. It was tested on a sama5d2 xplained ultra board with  
Micron n25q128a13, Spansion s25fl512 and Macronix mx25l51245g QSPI
memories and a at25df321a SPI memory.

The SPI protocol to be used by .read_reg(), .write_reg(), .read(), .write()
and .erase() hooks should be read by these hooks from new *_proto fields in
the struct spi_nor, the same way as the .read(), .write() and .erase()
hooks already get the op code value from dedicated *_opcode fields in the
very same struct spi_nor.
Doing so, there is no need to modify the current prototypes of all these
hooks.

Also, if some implementation is not interrested in supporting Dual or Quad
SPI protocols, it can simply ignore the value of the new  *_proto fields,
thus assuming the SPI 1-1-1 protocol is always used. Such an
implementation would work exactly as it did before introducing the *_proto
fields hence no regression should happen.
Indeed SPI protocols other than SPI 1-1-1 are used only if the caller of
spi_nor_scan() sets the value of the 'mode' argument to either
SPI_NOR_DUAL or SPI_NOR_QUAD.


This series was based and tested on linux-next

1 - Atmel QSPI controller + Micron n25q128a13 (atmel-quadspi.c driver)

SPI 1-1-1: This mode was tested replacing SPI_NOR_QUAD by SPI_NOR_FAST as
           argument to spi_nor_scan() called from atmel_qspi_probe().

SPI 1-1-4: Bootloaders (at91bootstrap/uboot) don't enable the Quad SPI
           mode of the Micron memory. When probed from Linux, the memory
           uses its Extended SPI mode and replies to the regular Read ID
           (0x9f) command.

SPI 4-4-4: The romcode enabled the Quad SPI mode the of Micron memory
           before loading the at91bootstrap. When probed from Linux, the
           memory uses its Quad SPI mode and no longer replies to the
           regular Read ID (0x9f) command but instead to the Read ID
           Multiple I/O (0xaf) command. The memory expects ALL commands
           to use the SPI 4-4-4 protocol.

2 - Atmel QSPI controller + Macronix mx25l51245g (atmel-quadspi.c driver)

SPI 1-1-4: the number of dummy cycles is set to 8 so drivers such as the
           m25p80 one can work properly.

3 - Atmel QSPI controller + Spansion s25fl512 (atmel-quadspi.c driver)

SPI 1-1-4: default settings. Early developpements on a FPGA board.

4 - Atmel SPI contoller + at25df321a (m25p80.c driver)

SPI 1-1-1: tested with the m25p80 driver for non regression purpose.


Winbond memories were NOT tested since I don't have any sample yet. The
patches were written only based on the manufacturers' datasheets.


Best regards,

Cyrille


ChangeLog:

v2 > v3:
- no longer check patterns such as FFFFFF or 000000 to detect a Read Jedec
  ID failure: always look the read ID up in the spi_nor_ids[] table (patch 2).
- fix patch 10 to configure the number of dummy cycles on Macronix memories:
  these memories use op code 0x15 to read their Configuration Register. Op
  code 0x35 is used to enter Macronix QPI mode, which was not intented.
- add "Acked-by Nicolas Ferre <nicolas.ferre at atmel.com>" to patch 14:
  driver for Atmel QSPI controller.

v1 -> v2:
- I've totally reworked the whole series. Especially I have split the
  former patch 2 to ease the code review. The Single/Dual/Quad SPI mode
  support fixes are now done by manufacturer.
- fix support and probing of Winbond memories.
- m25p80: compute the number of dummy bytes from both the number of dummy
  clock cycles and the number of I/O lines used to send them.
- fix Kconfig dependencies for the Atmel QSPI controller driver (it should
  fix the kbuild test robot warnings).
- add more comments.

Cyrille Pitchen (14):
  mtd: spi-nor: remove micron_quad_enable()
  mtd: spi-nor: properly detect the memory when it boots in Quad or Dual
    mode
  mtd: spi-nor: select op codes and SPI NOR protocols by manufacturer
  mtd: spi-nor: fix support of Macronix memories
  mtd: spi-nor: fix support of Winbond memories
  mtd: spi-nor: fix support of Micron memories
  mtd: spi-nor: fix support of Spansion memories
  mtd: spi-nor: configure the number of dummy clock cycles by
    manufacturer
  mtd: spi-nor: configure the number of dummy clock cycles on Micron
    memories
  mtd: spi-nor: configure the number of dummy clock cycles on Macronix
    memories
  mtd: spi-nor: configure the number of dummy clock cycles on Spansion
    memories
  mtd: m25p80: add support of dual and quad spi protocols to all
    commands
  Documentation: atmel-quadspi: add binding file for Atmel QSPI driver
  mtd: atmel-quadspi: add driver for Atmel QSPI controller

 .../devicetree/bindings/mtd/atmel-quadspi.txt      |  32 +
 drivers/mtd/devices/m25p80.c                       | 192 ++++-
 drivers/mtd/spi-nor/Kconfig                        |   9 +
 drivers/mtd/spi-nor/Makefile                       |   1 +
 drivers/mtd/spi-nor/atmel-quadspi.c                | 877 ++++++++++++++++++++
 drivers/mtd/spi-nor/spi-nor.c                      | 921 +++++++++++++++++++--
 include/linux/mtd/spi-nor.h                        |  74 +-
 7 files changed, 1971 insertions(+), 135 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
 create mode 100644 drivers/mtd/spi-nor/atmel-quadspi.c

-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Wed Feb  3 05:26:46 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 14:26:46 +0100
Subject: [PATCH v3 01/14] mtd: spi-nor: remove micron_quad_enable()
In-Reply-To: <cover.1454505161.git.cyrille.pitchen@atmel.com>
References: <cover.1454505161.git.cyrille.pitchen@atmel.com>
Message-ID: <2904a1d704670a9ef57b09370782e198fab6b1f4.1454505161.git.cyrille.pitchen@atmel.com>

This patch remove the micron_quad_enable() function which force the Quad
SPI mode. However, once this mode is enabled, the Micron memory expect ALL
commands to use the SPI 4-4-4 protocol. Hence a failure does occur when
calling spi_nor_wait_till_ready() right after the update of the Enhanced
Volatile Configuration Register (EVCR) in the micron_quad_enable() as
the SPI controller driver is not aware about the protocol change.

Since there is almost no performance increase using Fast Read 4-4-4
commands instead of Fast Read 1-1-4 commands, we rather keep on using the
Extended SPI mode than enabling the Quad SPI mode.

Let's take the example of the pretty standard use of 8 dummy cycles during
Fast Read operations on 64KB erase sectors:

Fast Read 1-1-4 requires 8 cycles for the command, then 24 cycles for the
3byte address followed by 8 dummy clock cycles and finally 65536*2 cycles
for the read data; so 131112 clock cycles.

On the other hand the Fast Read 4-4-4 would require 2 cycles for the
command, then 6 cycles for the 3byte address followed by 8 dummy clock
cycles and finally 65536*2 cycles for the read data. So 131088 clock
cycles. The theorical bandwidth increase is 0.0%.

Now using Fast Read operations on 512byte pages:
Fast Read 1-1-4 needs 8+24+8+(512*2) = 1064 clock cycles whereas Fast
Read 4-4-4 would requires 2+6+8+(512*2) = 1040 clock cycles. Hence the
theorical bandwidth increase is 2.3%.
Consecutive reads for non sequential pages is not a relevant use case so
The Quad SPI mode is not worth it.

mtd_speedtest seems to confirm these figures.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
Fixes: 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron SPI NOR")
---
 drivers/mtd/spi-nor/spi-nor.c | 46 +------------------------------------------
 1 file changed, 1 insertion(+), 45 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index ed0c19c558b5..3028c06547c1 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1100,45 +1100,6 @@ static int spansion_quad_enable(struct spi_nor *nor)
 	return 0;
 }
 
-static int micron_quad_enable(struct spi_nor *nor)
-{
-	int ret;
-	u8 val;
-
-	ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, &val, 1);
-	if (ret < 0) {
-		dev_err(nor->dev, "error %d reading EVCR\n", ret);
-		return ret;
-	}
-
-	write_enable(nor);
-
-	/* set EVCR, enable quad I/O */
-	nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
-	ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1);
-	if (ret < 0) {
-		dev_err(nor->dev, "error while writing EVCR register\n");
-		return ret;
-	}
-
-	ret = spi_nor_wait_till_ready(nor);
-	if (ret)
-		return ret;
-
-	/* read EVCR and check it */
-	ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, &val, 1);
-	if (ret < 0) {
-		dev_err(nor->dev, "error %d reading EVCR\n", ret);
-		return ret;
-	}
-	if (val & EVCR_QUAD_EN_MICRON) {
-		dev_err(nor->dev, "Micron EVCR Quad bit not clear\n");
-		return -EINVAL;
-	}
-
-	return 0;
-}
-
 static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
 {
 	int status;
@@ -1152,12 +1113,7 @@ static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
 		}
 		return status;
 	case SNOR_MFR_MICRON:
-		status = micron_quad_enable(nor);
-		if (status) {
-			dev_err(nor->dev, "Micron quad-read not enabled\n");
-			return -EINVAL;
-		}
-		return status;
+		return 0;
 	default:
 		status = spansion_quad_enable(nor);
 		if (status) {
-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Wed Feb  3 05:26:47 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 14:26:47 +0100
Subject: [PATCH v3 02/14] mtd: spi-nor: properly detect the memory when it
 boots in Quad or Dual mode
In-Reply-To: <cover.1454505161.git.cyrille.pitchen@atmel.com>
References: <cover.1454505161.git.cyrille.pitchen@atmel.com>
Message-ID: <0234fe7fc577854b0bf59fcb376ce8260b56fb29.1454505161.git.cyrille.pitchen@atmel.com>

The quad (or dual) mode of a spi-nor memory may be enabled at boot time by
non-volatile bits in some setting register. Also such a mode may have
already been enabled at early stage by some boot loader.

Hence, we should not guess the spi-nor memory is always configured for the
regular SPI 1-1-1 protocol.

Micron and Macronix memories, once their Quad (or dual for Micron) mode
enabled, no longer process the regular JEDEC Read ID (0x9f) command but
instead reply to a new command: JEDEC Read ID Multiple I/O (0xaf).
Besides, in Quad mode both memory manufacturers expect ALL commands to
use the SPI 4-4-4 protocol. For Micron memories, enabling their Dual mode
implies to use the SPI 2-2-2 protocol for ALL commands.

Winbond memories, once their Quad mode enabled, expect ALL commands to use
the SPI 4-4-4 protocol. Unlike Micron and Macronix memories, they still
reply to the regular JEDEC Read ID (0x9f) command.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
---
 drivers/mtd/spi-nor/spi-nor.c | 76 +++++++++++++++++++++++++++++++++++--------
 include/linux/mtd/spi-nor.h   | 50 ++++++++++++++++++++++++++--
 2 files changed, 110 insertions(+), 16 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 3028c06547c1..cff2665cea66 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -73,6 +73,13 @@ struct flash_info {
 
 #define JEDEC_MFR(info)	((info)->id[0])
 
+struct read_id_config {
+	enum read_mode		mode;
+	enum spi_nor_protocol	proto;
+	u8			opcode;
+	int			id_len;
+};
+
 static const struct flash_info *spi_nor_match_id(const char *name);
 
 /*
@@ -879,25 +886,60 @@ static const struct flash_info spi_nor_ids[] = {
 	{ },
 };
 
-static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
+static const struct flash_info *spi_nor_read_id(struct spi_nor *nor,
+						enum read_mode mode)
 {
-	int			tmp;
+	int			i, tmp;
 	u8			id[SPI_NOR_MAX_ID_LEN];
 	const struct flash_info	*info;
+	static const struct read_id_config configs[] = {
+		/* Regular JEDEC Read ID (always tested first) */
+		{SPI_NOR_NORMAL, SNOR_PROTO_1_1_1, SPINOR_OP_RDID, sizeof(id)},
 
-	tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN);
-	if (tmp < 0) {
-		dev_dbg(nor->dev, "error %d reading JEDEC ID\n", tmp);
-		return ERR_PTR(tmp);
-	}
+		/* Winbond QPI mode */
+		{SPI_NOR_QUAD, SNOR_PROTO_4_4_4, SPINOR_OP_RDID, sizeof(id)},
+
+		/* Micron Quad mode & Macronix QPI mode */
+		{SPI_NOR_QUAD, SNOR_PROTO_4_4_4, SPINOR_OP_MIO_RDID, 3},
+
+		/* Micron Dual mode */
+		{SPI_NOR_DUAL, SNOR_PROTO_2_2_2, SPINOR_OP_MIO_RDID, 3}
+	};
+
+	/*
+	 * Check whether the SPI NOR memory has already been configured (at
+	 * reset or by some bootloader) to use a protocol other than SPI 1-1-1.
+	 */
+	for (i = 0; i < ARRAY_SIZE(configs); i++) {
+		/* Only try protocols supported by the user. */
+		if (i && configs[i].mode != mode)
+			continue;
+
+		/* Set this protocol for all commands. */
+		nor->reg_proto = configs[i].proto;
+		nor->read_proto = configs[i].proto;
+		nor->write_proto = configs[i].proto;
+		nor->erase_proto = configs[i].proto;
+
+		/* Read the JEDEC ID. */
+		memset(id, 0, sizeof(id));
+		tmp = nor->read_reg(nor, configs[i].opcode,
+				    id, configs[i].id_len);
+		if (tmp < 0) {
+			dev_dbg(nor->dev, "error %d reading JEDEC ID\n", tmp);
+			return ERR_PTR(tmp);
+		}
 
-	for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
-		info = &spi_nor_ids[tmp];
-		if (info->id_len) {
-			if (!memcmp(info->id, id, info->id_len))
-				return &spi_nor_ids[tmp];
+		/* Look this ID up. */
+		for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
+			info = &spi_nor_ids[tmp];
+			if (info->id_len) {
+				if (!memcmp(info->id, id, info->id_len))
+					return &spi_nor_ids[tmp];
+			}
 		}
 	}
+
 	dev_err(nor->dev, "unrecognized JEDEC id bytes: %02x, %02x, %02x\n",
 		id[0], id[1], id[2]);
 	return ERR_PTR(-ENODEV);
@@ -1148,11 +1190,17 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
 	if (ret)
 		return ret;
 
+	/* Reset SPI protocol for all commands */
+	nor->erase_proto = SNOR_PROTO_1_1_1;
+	nor->read_proto = SNOR_PROTO_1_1_1;
+	nor->write_proto = SNOR_PROTO_1_1_1;
+	nor->reg_proto = SNOR_PROTO_1_1_1;
+
 	if (name)
 		info = spi_nor_match_id(name);
 	/* Try to auto-detect if chip name wasn't specified or not found */
 	if (!info)
-		info = spi_nor_read_id(nor);
+		info = spi_nor_read_id(nor, mode);
 	if (IS_ERR_OR_NULL(info))
 		return -ENOENT;
 
@@ -1163,7 +1211,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
 	if (name && info->id_len) {
 		const struct flash_info *jinfo;
 
-		jinfo = spi_nor_read_id(nor);
+		jinfo = spi_nor_read_id(nor, mode);
 		if (IS_ERR(jinfo)) {
 			return PTR_ERR(jinfo);
 		} else if (jinfo != info) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 62356d50815b..53932c87bcf2 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -75,8 +75,9 @@
 #define SPINOR_OP_BRWR		0x17	/* Bank register write */
 
 /* Used for Micron flashes only. */
-#define SPINOR_OP_RD_EVCR      0x65    /* Read EVCR register */
-#define SPINOR_OP_WD_EVCR      0x61    /* Write EVCR register */
+#define SPINOR_OP_MIO_RDID	0xaf	/* Multiple I/O Read JEDEC ID */
+#define SPINOR_OP_RD_EVCR	0x65    /* Read EVCR register */
+#define SPINOR_OP_WD_EVCR	0x61    /* Write EVCR register */
 
 /* Status Register bits. */
 #define SR_WIP			BIT(0)	/* Write in progress */
@@ -105,6 +106,43 @@ enum read_mode {
 	SPI_NOR_QUAD,
 };
 
+
+#define SNOR_PROTO_CMD_OFF	8
+#define SNOR_PROTO_CMD_MASK	GENMASK(11, 8)
+#define SNOR_PROTO_CMD_TO_PROTO(cmd) \
+	(((cmd) << SNOR_PROTO_CMD_OFF) & SNOR_PROTO_CMD_MASK)
+#define SNOR_PROTO_CMD_FROM_PROTO(proto) \
+	((((u32)(proto)) & SNOR_PROTO_CMD_MASK) >> SNOR_PROTO_CMD_OFF)
+
+#define SNOR_PROTO_ADDR_OFF	4
+#define SNOR_PROTO_ADDR_MASK	GENMASK(7, 4)
+#define SNOR_PROTO_ADDR_TO_PROTO(addr) \
+	(((addr) << SNOR_PROTO_ADDR_OFF) & SNOR_PROTO_ADDR_MASK)
+#define SNOR_PROTO_ADDR_FROM_PROTO(proto) \
+	((((u32)(proto)) & SNOR_PROTO_ADDR_MASK) >> SNOR_PROTO_ADDR_OFF)
+
+#define SNOR_PROTO_DATA_OFF	0
+#define SNOR_PROTO_DATA_MASK	GENMASK(3, 0)
+#define SNOR_PROTO_DATA_TO_PROTO(data) \
+	(((data) << SNOR_PROTO_DATA_OFF) & SNOR_PROTO_DATA_MASK)
+#define SNOR_PROTO_DATA_FROM_PROTO(proto) \
+	((((u32)(proto)) & SNOR_PROTO_DATA_MASK) >> SNOR_PROTO_DATA_OFF)
+
+#define SNOR_PROTO(cmd, addr, data)	  \
+	(SNOR_PROTO_CMD_TO_PROTO(cmd) |   \
+	 SNOR_PROTO_ADDR_TO_PROTO(addr) | \
+	 SNOR_PROTO_DATA_TO_PROTO(data))
+
+enum spi_nor_protocol {
+	SNOR_PROTO_1_1_1 = SNOR_PROTO(1, 1, 1),	/* SPI */
+	SNOR_PROTO_1_1_2 = SNOR_PROTO(1, 1, 2),	/* Dual Output */
+	SNOR_PROTO_1_1_4 = SNOR_PROTO(1, 1, 4),	/* Quad Output */
+	SNOR_PROTO_1_2_2 = SNOR_PROTO(1, 2, 2),	/* Dual IO */
+	SNOR_PROTO_1_4_4 = SNOR_PROTO(1, 4, 4),	/* Quad IO */
+	SNOR_PROTO_2_2_2 = SNOR_PROTO(2, 2, 2),	/* Dual Command */
+	SNOR_PROTO_4_4_4 = SNOR_PROTO(4, 4, 4),	/* Quad Command */
+};
+
 #define SPI_NOR_MAX_CMD_SIZE	8
 enum spi_nor_ops {
 	SPI_NOR_OPS_READ = 0,
@@ -132,6 +170,10 @@ enum spi_nor_option_flags {
  * @flash_read:		the mode of the read
  * @sst_write_second:	used by the SST write operation
  * @flags:		flag options for the current SPI-NOR (SNOR_F_*)
+ * @erase_proto:	the SPI protocol used by erase operations
+ * @read_proto:		the SPI protocol used by read operations
+ * @write_proto:	the SPI protocol used by write operations
+ * @reg_proto		the SPI protocol used by read_reg/write_reg operations
  * @cmd_buf:		used by the write_reg
  * @prepare:		[OPTIONAL] do some preparations for the
  *			read/write/erase/lock/unlock operations
@@ -160,6 +202,10 @@ struct spi_nor {
 	u8			read_opcode;
 	u8			read_dummy;
 	u8			program_opcode;
+	enum spi_nor_protocol	erase_proto;
+	enum spi_nor_protocol	read_proto;
+	enum spi_nor_protocol	write_proto;
+	enum spi_nor_protocol	reg_proto;
 	enum read_mode		flash_read;
 	bool			sst_write_second;
 	u32			flags;
-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Wed Feb  3 05:26:48 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 14:26:48 +0100
Subject: [PATCH v3 03/14] mtd: spi-nor: select op codes and SPI NOR protocols
 by manufacturer
In-Reply-To: <cover.1454505161.git.cyrille.pitchen@atmel.com>
References: <cover.1454505161.git.cyrille.pitchen@atmel.com>
Message-ID: <79c8e53fc1c59adc753586905db66e4b86077ae7.1454505161.git.cyrille.pitchen@atmel.com>

This is a transitional patch to prepare the split by Manufacturer of the
support of Single/Dual/Quad SPI modes.

Indeed every QSPI NOR manufacturer (Spansion, Micron, Macronix, Winbond)
supports Dual or Quad SPI modes on its way. Especially the Fast Read op
code and the SPI NOR protocols to use are not quite the same depending on
the manufacturer.

For instance Quad commands can use either the SPI 1-1-4, 1-4-4 or 4-4-4
protocol.

This is why this patch will be completed by fixes for each manufacturer.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
---
 drivers/mtd/spi-nor/spi-nor.c | 110 ++++++++++++++++++++++++++++++++----------
 include/linux/mtd/spi-nor.h   |  12 +++--
 2 files changed, 92 insertions(+), 30 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index cff2665cea66..e6438d63246d 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1153,17 +1153,61 @@ static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
 			dev_err(nor->dev, "Macronix quad-read not enabled\n");
 			return -EINVAL;
 		}
-		return status;
+		/* Check whether Macronix QPI mode is enabled. */
+		if (nor->read_proto != SNOR_PROTO_4_4_4)
+			nor->read_proto = SNOR_PROTO_1_1_4;
+		break;
+
 	case SNOR_MFR_MICRON:
-		return 0;
-	default:
+		/* Check whether Micron Quad mode is enabled. */
+		if (nor->read_proto != SNOR_PROTO_4_4_4)
+			nor->read_proto = SNOR_PROTO_1_1_4;
+		break;
+
+	case SNOR_MFR_SPANSION:
 		status = spansion_quad_enable(nor);
 		if (status) {
 			dev_err(nor->dev, "Spansion quad-read not enabled\n");
 			return -EINVAL;
 		}
-		return status;
+		nor->read_proto = SNOR_PROTO_1_1_4;
+		break;
+
+	default:
+		return -EINVAL;
 	}
+
+	nor->read_opcode = SPINOR_OP_READ_1_1_4;
+	return 0;
+}
+
+static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info)
+{
+	switch (JEDEC_MFR(info)) {
+	case SNOR_MFR_MICRON:
+		/* Check whether Micron Dual mode is enabled. */
+		if (nor->read_proto != SNOR_PROTO_2_2_2)
+			nor->read_proto = SNOR_PROTO_1_1_2;
+		break;
+
+	default:
+		nor->read_proto = SNOR_PROTO_1_1_2;
+		break;
+	}
+
+	nor->read_opcode = SPINOR_OP_READ_1_1_2;
+	return 0;
+}
+
+static int set_single_mode(struct spi_nor *nor, const struct flash_info *info)
+{
+	switch (JEDEC_MFR(info)) {
+	default:
+		nor->read_proto = SNOR_PROTO_1_1_1;
+		break;
+	}
+
+	return 0;
 }
 
 static int spi_nor_check(struct spi_nor *nor)
@@ -1311,7 +1355,30 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
 	if (info->flags & SPI_NOR_NO_FR)
 		nor->flash_read = SPI_NOR_NORMAL;
 
-	/* Quad/Dual-read mode takes precedence over fast/normal */
+	/* Default commands */
+	if (nor->flash_read == SPI_NOR_NORMAL)
+		nor->read_opcode = SPINOR_OP_READ;
+	else
+		nor->read_opcode = SPINOR_OP_READ_FAST;
+
+	nor->program_opcode = SPINOR_OP_PP;
+
+	/*
+	 * Quad/Dual-read mode takes precedence over fast/normal.
+	 *
+	 * Manufacturer specific modes are discovered when reading the JEDEC ID
+	 * and are reported by the nor->read_proto value:
+	 *  - SNOR_PROTO_4_4_4 is either:
+	 *    + Micron Quad mode enabled
+	 *    + Macronix/Winbond QPI mode enabled
+	 *  - SNOR_PROTO_2_2_2 is either:
+	 *    + Micron Dual mode enabled
+	 *
+	 * The opcodes and the protocols are updated depending on the
+	 * manufacturer.
+	 * The read opcode and protocol should be updated by the relevant
+	 * function when entering Quad or Dual mode.
+	 */
 	if (mode == SPI_NOR_QUAD && info->flags & SPI_NOR_QUAD_READ) {
 		ret = set_quad_mode(nor, info);
 		if (ret) {
@@ -1320,30 +1387,21 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
 		}
 		nor->flash_read = SPI_NOR_QUAD;
 	} else if (mode == SPI_NOR_DUAL && info->flags & SPI_NOR_DUAL_READ) {
+		ret = set_dual_mode(nor, info);
+		if (ret) {
+			dev_err(dev, "dual mode not supported\n");
+			return ret;
+		}
 		nor->flash_read = SPI_NOR_DUAL;
+	} else if (info->flags & (SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)) {
+		/* We may need to leave a Quad or Dual mode */
+		ret = set_single_mode(nor, info);
+		if (ret) {
+			dev_err(dev, "failed to switch back to single mode\n");
+			return ret;
+		}
 	}
 
-	/* Default commands */
-	switch (nor->flash_read) {
-	case SPI_NOR_QUAD:
-		nor->read_opcode = SPINOR_OP_READ_1_1_4;
-		break;
-	case SPI_NOR_DUAL:
-		nor->read_opcode = SPINOR_OP_READ_1_1_2;
-		break;
-	case SPI_NOR_FAST:
-		nor->read_opcode = SPINOR_OP_READ_FAST;
-		break;
-	case SPI_NOR_NORMAL:
-		nor->read_opcode = SPINOR_OP_READ;
-		break;
-	default:
-		dev_err(dev, "No Read opcode defined\n");
-		return -EINVAL;
-	}
-
-	nor->program_opcode = SPINOR_OP_PP;
-
 	if (info->addr_width)
 		nor->addr_width = info->addr_width;
 	else if (mtd->size > 0x1000000) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 53932c87bcf2..89e3228ec1d0 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -42,8 +42,10 @@
 #define SPINOR_OP_WRSR		0x01	/* Write status register 1 byte */
 #define SPINOR_OP_READ		0x03	/* Read data bytes (low frequency) */
 #define SPINOR_OP_READ_FAST	0x0b	/* Read data bytes (high frequency) */
-#define SPINOR_OP_READ_1_1_2	0x3b	/* Read data bytes (Dual SPI) */
-#define SPINOR_OP_READ_1_1_4	0x6b	/* Read data bytes (Quad SPI) */
+#define SPINOR_OP_READ_1_1_2	0x3b	/* Read data bytes (Dual Output SPI) */
+#define SPINOR_OP_READ_1_2_2	0xbb	/* Read data bytes (Dual I/O SPI) */
+#define SPINOR_OP_READ_1_1_4	0x6b	/* Read data bytes (Quad Output SPI) */
+#define SPINOR_OP_READ_1_4_4	0xeb	/* Read data bytes (Quad I/O SPI) */
 #define SPINOR_OP_PP		0x02	/* Page program (up to 256 bytes) */
 #define SPINOR_OP_BE_4K		0x20	/* Erase 4KiB block */
 #define SPINOR_OP_BE_4K_PMC	0xd7	/* Erase 4KiB block on PMC chips */
@@ -57,8 +59,10 @@
 /* 4-byte address opcodes - used on Spansion and some Macronix flashes. */
 #define SPINOR_OP_READ4		0x13	/* Read data bytes (low frequency) */
 #define SPINOR_OP_READ4_FAST	0x0c	/* Read data bytes (high frequency) */
-#define SPINOR_OP_READ4_1_1_2	0x3c	/* Read data bytes (Dual SPI) */
-#define SPINOR_OP_READ4_1_1_4	0x6c	/* Read data bytes (Quad SPI) */
+#define SPINOR_OP_READ4_1_1_2	0x3c	/* Read data bytes (Dual Output SPI) */
+#define SPINOR_OP_READ4_1_2_2	0xbc	/* Read data bytes (Dual I/O SPI) */
+#define SPINOR_OP_READ4_1_1_4	0x6c	/* Read data bytes (Quad Output SPI) */
+#define SPINOR_OP_READ4_1_4_4	0xec	/* Read data bytes (Quad I/O SPI) */
 #define SPINOR_OP_PP_4B		0x12	/* Page program (up to 256 bytes) */
 #define SPINOR_OP_SE_4B		0xdc	/* Sector erase (usually 64KiB) */
 
-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Wed Feb  3 05:26:49 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 14:26:49 +0100
Subject: [PATCH v3 04/14] mtd: spi-nor: fix support of Macronix memories
In-Reply-To: <cover.1454505161.git.cyrille.pitchen@atmel.com>
References: <cover.1454505161.git.cyrille.pitchen@atmel.com>
Message-ID: <25b58be3ffa0ab68cb19248d78086685583eb4ab.1454505161.git.cyrille.pitchen@atmel.com>

This patch fixes the support of Macronix memories. Especially we avoid
updating the Status Register when not needed as the Quad Enable (QE) bit
is a non-volatile bit.

Also we add comments to explain why we use some Fast Read op codes rather
than others.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
---
 drivers/mtd/spi-nor/spi-nor.c | 81 ++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 72 insertions(+), 9 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index e6438d63246d..2b2572e58a91 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1088,6 +1088,11 @@ static int macronix_quad_enable(struct spi_nor *nor)
 	val = read_sr(nor);
 	if (val < 0)
 		return val;
+
+	if (likely(val & SR_QUAD_EN_MX))
+		return 0;
+	dev_warn(nor->dev, "Macronix Quad mode disabled, enable it\n");
+
 	write_enable(nor);
 
 	write_sr(nor, val | SR_QUAD_EN_MX);
@@ -1142,21 +1147,73 @@ static int spansion_quad_enable(struct spi_nor *nor)
 	return 0;
 }
 
+static int macronix_set_quad_mode(struct spi_nor *nor)
+{
+	int status;
+
+	/* Check whether the QPI mode is enabled. */
+	if (nor->read_proto == SNOR_PROTO_4_4_4) {
+		/*
+		 * Since the QPI mode is enabled, the Quad Enabled (QE)
+		 * non-volatile bit is already set.
+		 * However in QPI mode, only the Fast Read 1-4-4 (0xeb)
+		 * op code is supported.
+		 * WARNING: we should take care about the performance
+		 * enhance toggling bits P0-P7 written during the
+		 * dummy/mode cycles to avoid entering the continuous
+		 * read (performance enhance) mode by mistake!
+		 */
+		nor->read_opcode = SPINOR_OP_READ_1_4_4;
+		return 0;
+	}
+
+	/*
+	 * The QPI mode is disabled but we still need to set the QE bit:
+	 * this disables the reset and write protect features and
+	 * frees the associated pins so they can be used as the 3rd
+	 * and 4th I/O lines required by Quad SPI commands.
+	 * Also we'd rather use the Fast Read 1-1-4 (0x6b) op code than
+	 * the Fast Read 1-4-4 (0xeb) op code so we don't care about
+	 * entering the continuous read mode by mistake if some
+	 * performance enhance toggling bits P0-P7 were written during
+	 * dummy/mode cycles.
+	 */
+	status = macronix_quad_enable(nor);
+	if (status) {
+		dev_err(nor->dev, "Macronix quad-read not enabled\n");
+		return status;
+	}
+	nor->read_proto = SNOR_PROTO_1_1_4;
+	nor->read_opcode = SPINOR_OP_READ_1_1_4;
+	return 0;
+}
+
+/*
+ * For both Macronix Dual and Single modes, we don't care about the value of
+ * the Quad Enabled (QE) bit since the memory still replies to Dual or Single
+ * SPI commands.
+ */
+
+static int macronix_set_dual_mode(struct spi_nor *nor)
+{
+	nor->read_proto = SNOR_PROTO_1_1_2;
+	nor->read_opcode = SPINOR_OP_READ_1_1_2;
+	return 0;
+}
+
+static int macronix_set_single_mode(struct spi_nor *nor)
+{
+	nor->read_proto = SNOR_PROTO_1_1_1;
+	return 0;
+}
+
 static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
 {
 	int status;
 
 	switch (JEDEC_MFR(info)) {
 	case SNOR_MFR_MACRONIX:
-		status = macronix_quad_enable(nor);
-		if (status) {
-			dev_err(nor->dev, "Macronix quad-read not enabled\n");
-			return -EINVAL;
-		}
-		/* Check whether Macronix QPI mode is enabled. */
-		if (nor->read_proto != SNOR_PROTO_4_4_4)
-			nor->read_proto = SNOR_PROTO_1_1_4;
-		break;
+		return macronix_set_quad_mode(nor);
 
 	case SNOR_MFR_MICRON:
 		/* Check whether Micron Quad mode is enabled. */
@@ -1184,6 +1241,9 @@ static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
 static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info)
 {
 	switch (JEDEC_MFR(info)) {
+	case SNOR_MFR_MACRONIX:
+		return macronix_set_dual_mode(nor);
+
 	case SNOR_MFR_MICRON:
 		/* Check whether Micron Dual mode is enabled. */
 		if (nor->read_proto != SNOR_PROTO_2_2_2)
@@ -1202,6 +1262,9 @@ static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info)
 static int set_single_mode(struct spi_nor *nor, const struct flash_info *info)
 {
 	switch (JEDEC_MFR(info)) {
+	case SNOR_MFR_MACRONIX:
+		return macronix_set_single_mode(nor);
+
 	default:
 		nor->read_proto = SNOR_PROTO_1_1_1;
 		break;
-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Wed Feb  3 05:26:50 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 14:26:50 +0100
Subject: [PATCH v3 05/14] mtd: spi-nor: fix support of Winbond memories
In-Reply-To: <cover.1454505161.git.cyrille.pitchen@atmel.com>
References: <cover.1454505161.git.cyrille.pitchen@atmel.com>
Message-ID: <b3b04c9497477d53769a7c8076c30b4f8c0d64ef.1454505161.git.cyrille.pitchen@atmel.com>

This patch fixes the support of Winbond memories. Indeed, before
performing any Quad SPI command, the Quad Enable (QE) non-volatile bit
MUST be set in the Status Register 2.

According to the w25q16fw datasheet from Winbond:
"When QE=1, the /WP pin becomes IO2 and /HOLD pin becomes IO3."

Quad SPI instructions requires the bidirectional IO2 and IO3 pins.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
---
 drivers/mtd/spi-nor/spi-nor.c | 100 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/mtd/spi-nor.h   |   6 +++
 2 files changed, 106 insertions(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 2b2572e58a91..980da91e84a4 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1147,6 +1147,40 @@ static int spansion_quad_enable(struct spi_nor *nor)
 	return 0;
 }
 
+static int winbond_quad_enable(struct spi_nor *nor)
+{
+	int ret;
+	u8 sr2;
+
+	ret = nor->read_reg(nor, SPINOR_OP_RDSR2_WINB, &sr2, 1);
+	if (ret < 0)
+		return ret;
+
+	if (likely(sr2 & SR2_QUAD_EN_WINB))
+		return 0;
+	dev_warn(nor->dev, "Winbond Quad mode disabled, enable it\n");
+
+	write_enable(nor);
+
+	sr2 |= SR2_QUAD_EN_WINB;
+	ret = nor->write_reg(nor, SPINOR_OP_WRSR2_WINB, &sr2, 1);
+	if (ret < 0)
+		return ret;
+
+	if (spi_nor_wait_till_ready(nor))
+		return -EIO;
+
+	ret = nor->read_reg(nor, SPINOR_OP_RDSR2_WINB, &sr2, 1);
+	if (ret < 0)
+		return ret;
+	if (!(sr2 & SR2_QUAD_EN_WINB)) {
+		dev_err(nor->dev, "Winbond Quad bit not set\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
 static int macronix_set_quad_mode(struct spi_nor *nor)
 {
 	int status;
@@ -1207,6 +1241,63 @@ static int macronix_set_single_mode(struct spi_nor *nor)
 	return 0;
 }
 
+static int winbond_set_quad_mode(struct spi_nor *nor)
+{
+	int status;
+
+	/* Check whether the QPI mode is enabled. */
+	if (nor->read_proto == SNOR_PROTO_4_4_4) {
+		/* Since the QPI mode is enabled, the Quad Enabled (QE)
+		 * non-volatile bit is already set.
+		 * If the Fast Read 1-4-4 (0xeb) were used, we should
+		 * take care about the value M7-M0 written during
+		 * dummy/mode cycles to avoid entering the continuous
+		 * read mode by  mistake.
+		 * Also the Fast Read 1-1-4 (0x6b) op code is not
+		 * supported in QPI mode.
+		 * Hence the Fast Read 1-1-1 (0x0b) op code is chosen.
+		 */
+		nor->read_opcode = SPINOR_OP_READ_FAST;
+		return 0;
+	}
+
+	/*
+	 * The QPI mode is disabled but we still need to set the QE bit:
+	 * when QE=1, the /WP pin becomes IO2 and /HOLD pin becomes IO3.
+	 * If the Fast Read 1-4-4 (0xeb) were used, we should take care
+	 * about the value M7-M0 written during dummy/mode cycles to
+	 * avoid entering the continuous read mode by mistake.
+	 * Hence the Fast Read 1-1-4 (0x6b) op code is preferred.
+	 */
+	status = winbond_quad_enable(nor);
+	if (status) {
+		dev_err(nor->dev, "Winbond quad-read nor enabled\n");
+		return status;
+	}
+	nor->read_proto = SNOR_PROTO_1_1_4;
+	nor->read_opcode = SPINOR_OP_READ_1_1_4;
+	return 0;
+}
+
+/*
+ * For both Winbond Dual and Single modes, we don't care about the value of
+ * the Quad Enabled (QE) bit since the memory still replies to Dual or Single
+ * SPI commands.
+ */
+
+static int winbond_set_dual_mode(struct spi_nor *nor)
+{
+	nor->read_proto = SNOR_PROTO_1_1_2;
+	nor->read_opcode = SPINOR_OP_READ_1_1_2;
+	return 0;
+}
+
+static int winbond_set_single_mode(struct spi_nor *nor)
+{
+	nor->read_proto = SNOR_PROTO_1_1_1;
+	return 0;
+}
+
 static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
 {
 	int status;
@@ -1215,6 +1306,9 @@ static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
 	case SNOR_MFR_MACRONIX:
 		return macronix_set_quad_mode(nor);
 
+	case SNOR_MFR_WINBOND:
+		return winbond_set_quad_mode(nor);
+
 	case SNOR_MFR_MICRON:
 		/* Check whether Micron Quad mode is enabled. */
 		if (nor->read_proto != SNOR_PROTO_4_4_4)
@@ -1244,6 +1338,9 @@ static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info)
 	case SNOR_MFR_MACRONIX:
 		return macronix_set_dual_mode(nor);
 
+	case SNOR_MFR_WINBOND:
+		return winbond_set_dual_mode(nor);
+
 	case SNOR_MFR_MICRON:
 		/* Check whether Micron Dual mode is enabled. */
 		if (nor->read_proto != SNOR_PROTO_2_2_2)
@@ -1265,6 +1362,9 @@ static int set_single_mode(struct spi_nor *nor, const struct flash_info *info)
 	case SNOR_MFR_MACRONIX:
 		return macronix_set_single_mode(nor);
 
+	case SNOR_MFR_WINBOND:
+		return winbond_set_single_mode(nor);
+
 	default:
 		nor->read_proto = SNOR_PROTO_1_1_1;
 		break;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 89e3228ec1d0..46343f5a8162 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -75,6 +75,12 @@
 #define SPINOR_OP_EN4B		0xb7	/* Enter 4-byte mode */
 #define SPINOR_OP_EX4B		0xe9	/* Exit 4-byte mode */
 
+/* Used for Winbond flashes only. */
+#define SPINOR_OP_RDSR2_WINB	0x35	/* Read status register 2 */
+#define SPINOR_OP_WRSR2_WINB	0x31	/* Write status register 2 */
+
+#define SR2_QUAD_EN_WINB	BIT(1)	/* Quad Enable bit */
+
 /* Used for Spansion flashes only. */
 #define SPINOR_OP_BRWR		0x17	/* Bank register write */
 
-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Wed Feb  3 05:26:51 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 14:26:51 +0100
Subject: [PATCH v3 06/14] mtd: spi-nor: fix support of Micron memories
In-Reply-To: <cover.1454505161.git.cyrille.pitchen@atmel.com>
References: <cover.1454505161.git.cyrille.pitchen@atmel.com>
Message-ID: <00471284afedfd58a6b3bb17dbd4e51ea509de03.1454505161.git.cyrille.pitchen@atmel.com>

This patch adds missing mode transitions. Indeed depending on both the
current memory mode and the new protocol wanted by the user, we may need
to perform a switch back to the Extended SPI mode.

However when the current mode is the Quad mode and the user has asked for
a Quad SPI protocol, we'd rather stay in Quad mode and use the Fast Read
4-4-4 command than switch to the Extended SPI mode and use the Fast Read
1-1-4 command.

Also we'd rather stay in Dual mode than swith to the Extended SPI mode
whenever the user has asked for Dual SPI protocol.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
---
 drivers/mtd/spi-nor/spi-nor.c | 154 +++++++++++++++++++++++++++++++++++++++---
 include/linux/mtd/spi-nor.h   |   1 +
 2 files changed, 147 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 980da91e84a4..6785e699106d 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1298,6 +1298,147 @@ static int winbond_set_single_mode(struct spi_nor *nor)
 	return 0;
 }
 
+static int micron_set_protocol(struct spi_nor *nor, u8 mask, u8 val,
+			       enum spi_nor_protocol proto)
+{
+	u8 evcr;
+	int ret;
+
+	/* Read the Enhanced Volatile Configuration Register (EVCR). */
+	ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, &evcr, 1);
+	if (ret < 0) {
+		dev_err(nor->dev, "error while reading EVCR register\n");
+		return ret;
+	}
+
+	/* Check whether we need to update the protocol bits. */
+	if ((evcr & mask) == val)
+		return 0;
+
+	/* Set EVCR protocol bits. */
+	write_enable(nor);
+	evcr = (evcr & ~mask) | val;
+	ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, &evcr, 1);
+	if (ret < 0) {
+		dev_err(nor->dev, "error while writing EVCR register\n");
+		return ret;
+	}
+
+	/* Switch reg protocol now before accessing any other registers. */
+	nor->reg_proto = proto;
+
+	ret = spi_nor_wait_till_ready(nor);
+	if (ret)
+		return ret;
+
+	/* Read EVCR and check it. */
+	ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, &evcr, 1);
+	if (ret < 0 || (evcr & mask) != val) {
+		dev_err(nor->dev, "Micron EVCR protocol bits not updated\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int micron_set_extended_spi_protocol(struct spi_nor *nor)
+{
+	int ret;
+
+	/* Set Quad/Dual bits to 11 to select the Extended SPI mode */
+	ret = micron_set_protocol(nor,
+				  EVCR_QUAD_EN_MICRON | EVCR_DUAL_EN_MICRON,
+				  EVCR_QUAD_EN_MICRON | EVCR_DUAL_EN_MICRON,
+				  SNOR_PROTO_1_1_1);
+	if (ret) {
+		dev_err(nor->dev, "Failed to set Micron Extended SPI mode\n");
+		return ret;
+	}
+
+	nor->write_proto = SNOR_PROTO_1_1_1;
+	nor->erase_proto = SNOR_PROTO_1_1_1;
+	return 0;
+}
+
+static int micron_set_quad_mode(struct spi_nor *nor)
+{
+	/* Check whether the Dual SPI mode is enabled. */
+	if (unlikely(nor->read_proto == SNOR_PROTO_2_2_2)) {
+		int ret;
+
+		/*
+		 * Exit Micron Dual mode and switch to the Extended SPI mode:
+		 * we can change the mode safely as we write into a volatile
+		 * register.
+		 * Also the Quad mode is not worth it for MTD usages: it
+		 * should only be relevant for eXecution In Place (XIP) usages,
+		 * which are out of the scope of the spi-nor framework.
+		 */
+		ret = micron_set_extended_spi_protocol(nor);
+		if (ret)
+			return ret;
+	}
+
+	/*
+	 * Whatever the Quad mode is enabled or not, the
+	 * Fast Read Quad Output 1-1-4 (0x6b) op code is supported.
+	 */
+	if (nor->read_proto != SNOR_PROTO_4_4_4)
+		nor->read_proto = SNOR_PROTO_1_1_4;
+	nor->read_opcode = SPINOR_OP_READ_1_1_4;
+	return 0;
+}
+
+static int micron_set_dual_mode(struct spi_nor *nor)
+{
+	/* Check whether Quad mode is enabled. */
+	if (unlikely(nor->read_proto == SNOR_PROTO_4_4_4)) {
+		int ret;
+
+		/*
+		 * Exit Micron Quad mode and switch to the Extended SPI mode:
+		 * we can change the mode safely as we write into a volatile
+		 * register.
+		 * Also the Dual mode is not worth it for MTD usages: it
+		 * should only be relevant for eXecution In Place (XIP) usages,
+		 * which are out of the scope of the spi-nor framework.
+		 */
+		ret = micron_set_extended_spi_protocol(nor);
+		if (ret)
+			return ret;
+	}
+
+	/*
+	 * Whatever the Dual mode is enabled or not, the
+	 * Fast Read Dual Output 1-1-2 (0x3b) op code is supported.
+	 */
+	if (nor->read_proto != SNOR_PROTO_2_2_2)
+		nor->read_proto = SNOR_PROTO_1_1_2;
+	nor->read_opcode = SPINOR_OP_READ_1_1_2;
+	return 0;
+}
+
+static int micron_set_single_mode(struct spi_nor *nor)
+{
+	/* Check whether either the Dual or Quad mode is enabled. */
+	if (unlikely(nor->read_proto != SNOR_PROTO_1_1_1)) {
+		int ret;
+
+		/*
+		 * Exit Micron Dual or Quad mode and switch to the Extended SPI
+		 * mode: we can change the mode safely as we write into a
+		 * volatile register.
+		 */
+		ret = micron_set_extended_spi_protocol(nor);
+		if (ret)
+			return ret;
+
+		nor->read_proto = SNOR_PROTO_1_1_1;
+	}
+
+	return 0;
+}
+
 static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
 {
 	int status;
@@ -1310,10 +1451,7 @@ static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
 		return winbond_set_quad_mode(nor);
 
 	case SNOR_MFR_MICRON:
-		/* Check whether Micron Quad mode is enabled. */
-		if (nor->read_proto != SNOR_PROTO_4_4_4)
-			nor->read_proto = SNOR_PROTO_1_1_4;
-		break;
+		return micron_set_quad_mode(nor);
 
 	case SNOR_MFR_SPANSION:
 		status = spansion_quad_enable(nor);
@@ -1342,10 +1480,7 @@ static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info)
 		return winbond_set_dual_mode(nor);
 
 	case SNOR_MFR_MICRON:
-		/* Check whether Micron Dual mode is enabled. */
-		if (nor->read_proto != SNOR_PROTO_2_2_2)
-			nor->read_proto = SNOR_PROTO_1_1_2;
-		break;
+		return micron_set_dual_mode(nor);
 
 	default:
 		nor->read_proto = SNOR_PROTO_1_1_2;
@@ -1365,6 +1500,9 @@ static int set_single_mode(struct spi_nor *nor, const struct flash_info *info)
 	case SNOR_MFR_WINBOND:
 		return winbond_set_single_mode(nor);
 
+	case SNOR_MFR_MICRON:
+		return micron_set_single_mode(nor);
+
 	default:
 		nor->read_proto = SNOR_PROTO_1_1_1;
 		break;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 46343f5a8162..d0a6f343a063 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -102,6 +102,7 @@
 
 /* Enhanced Volatile Configuration Register bits */
 #define EVCR_QUAD_EN_MICRON	BIT(7)	/* Micron Quad I/O */
+#define EVCR_DUAL_EN_MICRON	BIT(6)	/* Micron Dual I/O */
 
 /* Flag Status Register bits */
 #define FSR_READY		BIT(7)
-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Wed Feb  3 05:26:52 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 14:26:52 +0100
Subject: [PATCH v3 07/14] mtd: spi-nor: fix support of Spansion memories
In-Reply-To: <cover.1454505161.git.cyrille.pitchen@atmel.com>
References: <cover.1454505161.git.cyrille.pitchen@atmel.com>
Message-ID: <d7107bc2337e353c553cb88119d6f8d47575dc43.1454505161.git.cyrille.pitchen@atmel.com>

This patch is only a transitional one. It concludes the series of patches
to select op codes and protocols by manufacturer.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
---
 drivers/mtd/spi-nor/spi-nor.c | 53 ++++++++++++++++++++++++++++++-------------
 1 file changed, 37 insertions(+), 16 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 6785e699106d..f9dd1fd3f53c 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1439,10 +1439,35 @@ static int micron_set_single_mode(struct spi_nor *nor)
 	return 0;
 }
 
-static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
+static int spansion_set_quad_mode(struct spi_nor *nor)
 {
 	int status;
 
+	status = spansion_quad_enable(nor);
+	if (status) {
+		dev_err(nor->dev, "Spansion quad-read not enabled\n");
+		return -EINVAL;
+	}
+	nor->read_proto = SNOR_PROTO_1_1_4;
+	nor->read_opcode = SPINOR_OP_READ_1_1_4;
+	return 0;
+}
+
+static int spansion_set_dual_mode(struct spi_nor *nor)
+{
+	nor->read_proto = SNOR_PROTO_1_1_2;
+	nor->read_opcode = SPINOR_OP_READ_1_1_2;
+	return 0;
+}
+
+static int spansion_set_single_mode(struct spi_nor *nor)
+{
+	nor->read_proto = SNOR_PROTO_1_1_1;
+	return 0;
+}
+
+static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
+{
 	switch (JEDEC_MFR(info)) {
 	case SNOR_MFR_MACRONIX:
 		return macronix_set_quad_mode(nor);
@@ -1454,20 +1479,13 @@ static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
 		return micron_set_quad_mode(nor);
 
 	case SNOR_MFR_SPANSION:
-		status = spansion_quad_enable(nor);
-		if (status) {
-			dev_err(nor->dev, "Spansion quad-read not enabled\n");
-			return -EINVAL;
-		}
-		nor->read_proto = SNOR_PROTO_1_1_4;
-		break;
+		return spansion_set_quad_mode(nor);
 
 	default:
-		return -EINVAL;
+		break;
 	}
 
-	nor->read_opcode = SPINOR_OP_READ_1_1_4;
-	return 0;
+	return -EINVAL;
 }
 
 static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info)
@@ -1482,13 +1500,14 @@ static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info)
 	case SNOR_MFR_MICRON:
 		return micron_set_dual_mode(nor);
 
+	case SNOR_MFR_SPANSION:
+		return spansion_set_dual_mode(nor);
+
 	default:
-		nor->read_proto = SNOR_PROTO_1_1_2;
 		break;
 	}
 
-	nor->read_opcode = SPINOR_OP_READ_1_1_2;
-	return 0;
+	return -EINVAL;
 }
 
 static int set_single_mode(struct spi_nor *nor, const struct flash_info *info)
@@ -1503,12 +1522,14 @@ static int set_single_mode(struct spi_nor *nor, const struct flash_info *info)
 	case SNOR_MFR_MICRON:
 		return micron_set_single_mode(nor);
 
+	case SNOR_MFR_SPANSION:
+		return spansion_set_single_mode(nor);
+
 	default:
-		nor->read_proto = SNOR_PROTO_1_1_1;
 		break;
 	}
 
-	return 0;
+	return -EINVAL;
 }
 
 static int spi_nor_check(struct spi_nor *nor)
-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Wed Feb  3 05:26:53 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 14:26:53 +0100
Subject: [PATCH v3 08/14] mtd: spi-nor: configure the number of dummy clock
 cycles by manufacturer
In-Reply-To: <cover.1454505161.git.cyrille.pitchen@atmel.com>
References: <cover.1454505161.git.cyrille.pitchen@atmel.com>
Message-ID: <e5b618cdf62b1b33cbc07a40740a97034caf43a9.1454505161.git.cyrille.pitchen@atmel.com>

This is a transitional patch which let us set the number of dummy clock
cycles by manufacturer.

More patches will follow by manufacturer to actually configure the
relevant number of dummy clock cycles following the dedicated procedure.

For instance, some manufacturers like Spansion configure the number of
dummy clock cycles to be used by Fast Read command through some
non-volatile register. In such a case, we should avoid updating its value
but instead read it then set the nor->read_dummy accordingly.

On the other hand, some manufacturers like Micron use some volatile
register. In this case, we'd rather update this register to use a number
of dummy clock cycles, which is a multiple of 8.
Indeed some drivers, like m25p80, only support writing bytes, hence
multiples of 8 bits.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
---
 drivers/mtd/spi-nor/spi-nor.c | 99 ++++++++++++++++++++++++++++++++-----------
 1 file changed, 74 insertions(+), 25 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index f9dd1fd3f53c..ef520048edae 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -140,24 +140,6 @@ static int read_cr(struct spi_nor *nor)
 }
 
 /*
- * Dummy Cycle calculation for different type of read.
- * It can be used to support more commands with
- * different dummy cycle requirements.
- */
-static inline int spi_nor_read_dummy_cycles(struct spi_nor *nor)
-{
-	switch (nor->flash_read) {
-	case SPI_NOR_FAST:
-	case SPI_NOR_DUAL:
-	case SPI_NOR_QUAD:
-		return 8;
-	case SPI_NOR_NORMAL:
-		return 0;
-	}
-	return 0;
-}
-
-/*
  * Write status register 1 byte
  * Returns negative if error occurred.
  */
@@ -1198,6 +1180,7 @@ static int macronix_set_quad_mode(struct spi_nor *nor)
 		 * read (performance enhance) mode by mistake!
 		 */
 		nor->read_opcode = SPINOR_OP_READ_1_4_4;
+		nor->read_dummy = 8;
 		return 0;
 	}
 
@@ -1219,6 +1202,7 @@ static int macronix_set_quad_mode(struct spi_nor *nor)
 	}
 	nor->read_proto = SNOR_PROTO_1_1_4;
 	nor->read_opcode = SPINOR_OP_READ_1_1_4;
+	nor->read_dummy = 8;
 	return 0;
 }
 
@@ -1232,12 +1216,27 @@ static int macronix_set_dual_mode(struct spi_nor *nor)
 {
 	nor->read_proto = SNOR_PROTO_1_1_2;
 	nor->read_opcode = SPINOR_OP_READ_1_1_2;
+	nor->read_dummy = 8;
 	return 0;
 }
 
 static int macronix_set_single_mode(struct spi_nor *nor)
 {
+	u8 read_dummy;
+
+	switch (nor->read_opcode) {
+	case SPINOR_OP_READ:
+	case SPINOR_OP_READ4:
+		read_dummy = 0;
+		break;
+
+	default:
+		read_dummy = 8;
+		break;
+	}
+
 	nor->read_proto = SNOR_PROTO_1_1_1;
+	nor->read_dummy = read_dummy;
 	return 0;
 }
 
@@ -1258,6 +1257,7 @@ static int winbond_set_quad_mode(struct spi_nor *nor)
 		 * Hence the Fast Read 1-1-1 (0x0b) op code is chosen.
 		 */
 		nor->read_opcode = SPINOR_OP_READ_FAST;
+		nor->read_dummy = 8;
 		return 0;
 	}
 
@@ -1276,6 +1276,7 @@ static int winbond_set_quad_mode(struct spi_nor *nor)
 	}
 	nor->read_proto = SNOR_PROTO_1_1_4;
 	nor->read_opcode = SPINOR_OP_READ_1_1_4;
+	nor->read_dummy = 8;
 	return 0;
 }
 
@@ -1289,12 +1290,27 @@ static int winbond_set_dual_mode(struct spi_nor *nor)
 {
 	nor->read_proto = SNOR_PROTO_1_1_2;
 	nor->read_opcode = SPINOR_OP_READ_1_1_2;
+	nor->read_dummy = 8;
 	return 0;
 }
 
 static int winbond_set_single_mode(struct spi_nor *nor)
 {
+	u8 read_dummy;
+
+	switch (nor->read_opcode) {
+	case SPINOR_OP_READ:
+	case SPINOR_OP_READ4:
+		read_dummy = 0;
+		break;
+
+	default:
+		read_dummy = 8;
+		break;
+	}
+
 	nor->read_proto = SNOR_PROTO_1_1_1;
+	nor->read_dummy = read_dummy;
 	return 0;
 }
 
@@ -1386,6 +1402,7 @@ static int micron_set_quad_mode(struct spi_nor *nor)
 	if (nor->read_proto != SNOR_PROTO_4_4_4)
 		nor->read_proto = SNOR_PROTO_1_1_4;
 	nor->read_opcode = SPINOR_OP_READ_1_1_4;
+	nor->read_dummy = 8;
 	return 0;
 }
 
@@ -1415,11 +1432,14 @@ static int micron_set_dual_mode(struct spi_nor *nor)
 	if (nor->read_proto != SNOR_PROTO_2_2_2)
 		nor->read_proto = SNOR_PROTO_1_1_2;
 	nor->read_opcode = SPINOR_OP_READ_1_1_2;
+	nor->read_dummy = 8;
 	return 0;
 }
 
 static int micron_set_single_mode(struct spi_nor *nor)
 {
+	u8 read_dummy;
+
 	/* Check whether either the Dual or Quad mode is enabled. */
 	if (unlikely(nor->read_proto != SNOR_PROTO_1_1_1)) {
 		int ret;
@@ -1436,6 +1456,18 @@ static int micron_set_single_mode(struct spi_nor *nor)
 		nor->read_proto = SNOR_PROTO_1_1_1;
 	}
 
+	/* Force the number of dummy cycles to 8 for Fast Read, 0 for Read. */
+	switch (nor->read_opcode) {
+	case SPINOR_OP_READ:
+	case SPINOR_OP_READ4:
+		read_dummy = 0;
+		break;
+
+	default:
+		read_dummy = 8;
+		break;
+	}
+	nor->read_dummy = read_dummy;
 	return 0;
 }
 
@@ -1450,6 +1482,7 @@ static int spansion_set_quad_mode(struct spi_nor *nor)
 	}
 	nor->read_proto = SNOR_PROTO_1_1_4;
 	nor->read_opcode = SPINOR_OP_READ_1_1_4;
+	nor->read_dummy = 8;
 	return 0;
 }
 
@@ -1457,12 +1490,27 @@ static int spansion_set_dual_mode(struct spi_nor *nor)
 {
 	nor->read_proto = SNOR_PROTO_1_1_2;
 	nor->read_opcode = SPINOR_OP_READ_1_1_2;
+	nor->read_dummy = 8;
 	return 0;
 }
 
 static int spansion_set_single_mode(struct spi_nor *nor)
 {
+	u8 read_dummy;
+
+	switch (nor->read_opcode) {
+	case SPINOR_OP_READ:
+	case SPINOR_OP_READ4:
+		read_dummy = 0;
+		break;
+
+	default:
+		read_dummy = 8;
+		break;
+	}
+
 	nor->read_proto = SNOR_PROTO_1_1_1;
+	nor->read_dummy = read_dummy;
 	return 0;
 }
 
@@ -1677,11 +1725,14 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
 	if (info->flags & SPI_NOR_NO_FR)
 		nor->flash_read = SPI_NOR_NORMAL;
 
-	/* Default commands */
-	if (nor->flash_read == SPI_NOR_NORMAL)
+	/* Default commands and number of dummy cycles */
+	if (nor->flash_read == SPI_NOR_NORMAL) {
 		nor->read_opcode = SPINOR_OP_READ;
-	else
+		nor->read_dummy = 0;
+	} else {
 		nor->read_opcode = SPINOR_OP_READ_FAST;
+		nor->read_dummy = 8;
+	}
 
 	nor->program_opcode = SPINOR_OP_PP;
 
@@ -1696,8 +1747,8 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
 	 *  - SNOR_PROTO_2_2_2 is either:
 	 *    + Micron Dual mode enabled
 	 *
-	 * The opcodes and the protocols are updated depending on the
-	 * manufacturer.
+	 * The opcodes, the protocols and the number of dummy cycles are updated
+	 * depending on the manufacturer.
 	 * The read opcode and protocol should be updated by the relevant
 	 * function when entering Quad or Dual mode.
 	 */
@@ -1761,8 +1812,6 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode)
 		return -EINVAL;
 	}
 
-	nor->read_dummy = spi_nor_read_dummy_cycles(nor);
-
 	dev_info(dev, "%s (%lld Kbytes)\n", info->name,
 			(long long)mtd->size >> 10);
 
-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Wed Feb  3 05:26:54 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 14:26:54 +0100
Subject: [PATCH v3 09/14] mtd: spi-nor: configure the number of dummy clock
 cycles on Micron memories
In-Reply-To: <cover.1454505161.git.cyrille.pitchen@atmel.com>
References: <cover.1454505161.git.cyrille.pitchen@atmel.com>
Message-ID: <5ccaf4d6729c2569728cdf0038af6a3ad799647a.1454505161.git.cyrille.pitchen@atmel.com>

The spi-nor framework currently expects all Fast Read operations to use 8
dummy clock cycles. Especially some drivers like m25p80 can only support
multiple of 8 dummy clock cycles.

On Micron memories, the number of dummy clock cycles to be used by Fast
Read commands can be safely set to 8 by updating the Volatile
Configuration Register (VCR).

Also the XIP bit is set at the same time when updating the VCR so the
Continuous Read mode is disabled: this prevents us from entering it by
mistake.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
---
 drivers/mtd/spi-nor/spi-nor.c | 72 ++++++++++++++++++++++++++++++++++++++-----
 include/linux/mtd/spi-nor.h   |  2 ++
 2 files changed, 67 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index ef520048edae..2b1a26588ae6 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1314,6 +1314,53 @@ static int winbond_set_single_mode(struct spi_nor *nor)
 	return 0;
 }
 
+static int micron_set_dummy_cycles(struct spi_nor *nor, u8 read_dummy)
+{
+	u8 vcr, val, mask;
+	int ret;
+
+	/* Set bit3 (XIP) to disable the Continuous Read mode */
+	mask = GENMASK(7, 4) | BIT(3);
+	val = ((read_dummy << 4) | BIT(3)) & mask;
+
+	/* Read the Volatile Configuration Register (VCR). */
+	ret = nor->read_reg(nor, SPINOR_OP_RD_VCR, &vcr, 1);
+	if (ret < 0) {
+		dev_err(nor->dev, "error while reading VCR register\n");
+		return ret;
+	}
+
+	/* Check whether we need to update the number of dummy cycles. */
+	if ((vcr & mask) == val) {
+		nor->read_dummy = read_dummy;
+		return 0;
+	}
+
+	/* Update the number of dummy into the VCR. */
+	write_enable(nor);
+	vcr = (vcr & ~mask) | val;
+	ret = nor->write_reg(nor, SPINOR_OP_WR_VCR, &vcr, 1);
+	if (ret < 0) {
+		dev_err(nor->dev, "error while writing VCR register\n");
+		return ret;
+	}
+
+	ret = spi_nor_wait_till_ready(nor);
+	if (ret)
+		return ret;
+
+	/* Read VCR and check it. */
+	ret = nor->read_reg(nor, SPINOR_OP_RD_VCR, &vcr, 1);
+	if (ret < 0 || (vcr & mask) != val) {
+		dev_err(nor->dev, "Micron VCR dummy cycles not updated\n");
+		return -EINVAL;
+	}
+
+	/* Save the number of dummy cycles to use with Fast Read commands */
+	nor->read_dummy = read_dummy;
+	return 0;
+}
+
 static int micron_set_protocol(struct spi_nor *nor, u8 mask, u8 val,
 			       enum spi_nor_protocol proto)
 {
@@ -1398,12 +1445,15 @@ static int micron_set_quad_mode(struct spi_nor *nor)
 	/*
 	 * Whatever the Quad mode is enabled or not, the
 	 * Fast Read Quad Output 1-1-4 (0x6b) op code is supported.
+	 * Force the number of dummy cycles to 8 and disable the Continuous Read
+	 * mode to prevent some drivers from using it by mistake (m25p80).
+	 * We can change these settings safely as we write into a volatile
+	 * register.
 	 */
 	if (nor->read_proto != SNOR_PROTO_4_4_4)
 		nor->read_proto = SNOR_PROTO_1_1_4;
 	nor->read_opcode = SPINOR_OP_READ_1_1_4;
-	nor->read_dummy = 8;
-	return 0;
+	return micron_set_dummy_cycles(nor, 8);
 }
 
 static int micron_set_dual_mode(struct spi_nor *nor)
@@ -1428,12 +1478,15 @@ static int micron_set_dual_mode(struct spi_nor *nor)
 	/*
 	 * Whatever the Dual mode is enabled or not, the
 	 * Fast Read Dual Output 1-1-2 (0x3b) op code is supported.
+	 * Force the number of dummy cycles to 8 and disable the Continuous Read
+	 * mode to prevent some drivers from using it by mistake (m25p80).
+	 * We can change these settings safely as we write into a volatile
+	 * register.
 	 */
 	if (nor->read_proto != SNOR_PROTO_2_2_2)
 		nor->read_proto = SNOR_PROTO_1_1_2;
 	nor->read_opcode = SPINOR_OP_READ_1_1_2;
-	nor->read_dummy = 8;
-	return 0;
+	return micron_set_dummy_cycles(nor, 8);
 }
 
 static int micron_set_single_mode(struct spi_nor *nor)
@@ -1456,7 +1509,13 @@ static int micron_set_single_mode(struct spi_nor *nor)
 		nor->read_proto = SNOR_PROTO_1_1_1;
 	}
 
-	/* Force the number of dummy cycles to 8 for Fast Read, 0 for Read. */
+	/*
+	 * Force the number of dummy cycles to 8 for Fast Read, 0 for Read
+	 * and disable the Continuous Read mode to prevent some drivers from
+	 * using it by mistake (m25p80).
+	 * We can change these settings safely as we write into a volatile
+	 * register.
+	 */
 	switch (nor->read_opcode) {
 	case SPINOR_OP_READ:
 	case SPINOR_OP_READ4:
@@ -1467,8 +1526,7 @@ static int micron_set_single_mode(struct spi_nor *nor)
 		read_dummy = 8;
 		break;
 	}
-	nor->read_dummy = read_dummy;
-	return 0;
+	return micron_set_dummy_cycles(nor, read_dummy);
 }
 
 static int spansion_set_quad_mode(struct spi_nor *nor)
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index d0a6f343a063..2dc0f8b429ca 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -86,6 +86,8 @@
 
 /* Used for Micron flashes only. */
 #define SPINOR_OP_MIO_RDID	0xaf	/* Multiple I/O Read JEDEC ID */
+#define SPINOR_OP_RD_VCR	0x85	/* Read VCR register */
+#define SPINOR_OP_WR_VCR	0x81	/* Write VCR register */
 #define SPINOR_OP_RD_EVCR	0x65    /* Read EVCR register */
 #define SPINOR_OP_WD_EVCR	0x61    /* Write EVCR register */
 
-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Wed Feb  3 05:26:55 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 14:26:55 +0100
Subject: [PATCH v3 10/14] mtd: spi-nor: configure the number of dummy clock
 cycles on Macronix memories
In-Reply-To: <cover.1454505161.git.cyrille.pitchen@atmel.com>
References: <cover.1454505161.git.cyrille.pitchen@atmel.com>
Message-ID: <fe3d12a04383048a54dd2ffe927f854142fa8db7.1454505161.git.cyrille.pitchen@atmel.com>

The spi-nor framework currently expects all Fast Read operations to use 8
dummy clock cycles. Especially some drivers like m25p80 can only support
multiple of 8 dummy clock cycles.

On Macronix memories, the number of dummy clock cycles to be used by Fast
Read commands can be safely set to 8 by updating the DC0 and DC1 volatile
bits inside the Configuration Register.

According to the mx66l1g45g datasheet from Macronix, using 8 dummy clock
cycles should be enough to set the SPI bus clock frequency up to:
- 133 MHz for Fast Read 1-1-1, 1-1-2, 1-1-4 and 1-2-2 commands in Single
  Transfer Rate (STR)
- 104 MHz for Fast Read 1-4-4 (or 4-4-4 in QPI mode) commands (STR)

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
---
 drivers/mtd/spi-nor/spi-nor.c | 155 +++++++++++++++++++++++++++++++++++++++---
 include/linux/mtd/spi-nor.h   |   3 +
 2 files changed, 150 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 2b1a26588ae6..c560fbbb8479 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1163,6 +1163,136 @@ static int winbond_quad_enable(struct spi_nor *nor)
 	return 0;
 }
 
+static int macronix_dummy2code(u8 read_opcode, u8 read_dummy, u8 *dc)
+{
+	switch (read_opcode) {
+	case SPINOR_OP_READ:
+	case SPINOR_OP_READ4:
+		*dc = 0;
+		break;
+
+	case SPINOR_OP_READ_FAST:
+	case SPINOR_OP_READ_1_1_2:
+	case SPINOR_OP_READ_1_1_4:
+	case SPINOR_OP_READ4_FAST:
+	case SPINOR_OP_READ4_1_1_2:
+	case SPINOR_OP_READ4_1_1_4:
+		switch (read_dummy) {
+		case 6:
+			*dc = 1;
+			break;
+		case 8:
+			*dc = 0;
+			break;
+		case 10:
+			*dc = 3;
+			break;
+		default:
+			return -EINVAL;
+		}
+		break;
+
+	case SPINOR_OP_READ_1_2_2:
+	case SPINOR_OP_READ4_1_2_2:
+		switch (read_dummy) {
+		case 4:
+			*dc = 0;
+			break;
+		case 6:
+			*dc = 1;
+			break;
+		case 8:
+			*dc = 2;
+			break;
+		case 10:
+			*dc = 3;
+		default:
+			return -EINVAL;
+		}
+		break;
+
+	case SPINOR_OP_READ_1_4_4:
+	case SPINOR_OP_READ4_1_4_4:
+		switch (read_dummy) {
+		case 4:
+			*dc = 1;
+			break;
+		case 6:
+			*dc = 0;
+			break;
+		case 8:
+			*dc = 2;
+			break;
+		case 10:
+			*dc = 3;
+		default:
+			return -EINVAL;
+		}
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int macronix_set_dummy_cycles(struct spi_nor *nor, u8 read_dummy)
+{
+	int ret, sr, mask, val;
+	u16 sr_cr;
+	u8 dc, cr;
+
+	/* Convert the number of dummy cycles into Macronix DC volatile bits */
+	ret = macronix_dummy2code(nor->read_opcode, read_dummy, &dc);
+	if (ret)
+		return ret;
+
+	mask = GENMASK(7, 6);
+	val = (dc << 6) & mask;
+
+	ret = nor->read_reg(nor, SPINOR_OP_RDCR_MX, &cr, 1);
+	if (ret < 0) {
+		dev_err(nor->dev, "error while reading the config register\n");
+		return ret;
+	}
+
+	if ((cr & mask) == val) {
+		nor->read_dummy = read_dummy;
+		return 0;
+	}
+
+	sr = read_sr(nor);
+	if (sr < 0) {
+		dev_err(nor->dev, "error while reading the status register\n");
+		return sr;
+	}
+
+	cr = (cr & ~mask) | val;
+	sr_cr = (sr & 0xff) | ((cr & 0xff) << 8);
+	write_enable(nor);
+	ret = write_sr_cr(nor, sr_cr);
+	if (ret) {
+		dev_err(nor->dev,
+			"error while writing the SR and CR registers\n");
+		return ret;
+	}
+
+	ret = spi_nor_wait_till_ready(nor);
+	if (ret)
+		return ret;
+
+	ret = nor->read_reg(nor, SPINOR_OP_RDCR_MX, &cr, 1);
+	if (ret < 0 || (cr & mask) != val) {
+		dev_err(nor->dev, "Macronix Dummy Cycle bits not updated\n");
+		return -EINVAL;
+	}
+
+	/* Save the number of dummy cycles to use with Fast Read commands */
+	nor->read_dummy = read_dummy;
+	return 0;
+}
+
 static int macronix_set_quad_mode(struct spi_nor *nor)
 {
 	int status;
@@ -1180,8 +1310,7 @@ static int macronix_set_quad_mode(struct spi_nor *nor)
 		 * read (performance enhance) mode by mistake!
 		 */
 		nor->read_opcode = SPINOR_OP_READ_1_4_4;
-		nor->read_dummy = 8;
-		return 0;
+		return macronix_set_dummy_cycles(nor, 8);
 	}
 
 	/*
@@ -1194,6 +1323,9 @@ static int macronix_set_quad_mode(struct spi_nor *nor)
 	 * entering the continuous read mode by mistake if some
 	 * performance enhance toggling bits P0-P7 were written during
 	 * dummy/mode cycles.
+	 *
+	 * Use the Fast Read Quad Output 1-1-4 (0x6b) command with 8 dummy
+	 * cycles (up to 133MHz for STR and 66MHz for DTR).
 	 */
 	status = macronix_quad_enable(nor);
 	if (status) {
@@ -1202,8 +1334,7 @@ static int macronix_set_quad_mode(struct spi_nor *nor)
 	}
 	nor->read_proto = SNOR_PROTO_1_1_4;
 	nor->read_opcode = SPINOR_OP_READ_1_1_4;
-	nor->read_dummy = 8;
-	return 0;
+	return macronix_set_dummy_cycles(nor, 8);
 }
 
 /*
@@ -1214,16 +1345,25 @@ static int macronix_set_quad_mode(struct spi_nor *nor)
 
 static int macronix_set_dual_mode(struct spi_nor *nor)
 {
+	/*
+	 * Use the Fast Read Dual Output 1-1-2 (0x3b) command with 8 dummy
+	 * cycles (up to 133MHz for STR and 66MHz for DTR).
+	 */
 	nor->read_proto = SNOR_PROTO_1_1_2;
 	nor->read_opcode = SPINOR_OP_READ_1_1_2;
-	nor->read_dummy = 8;
-	return 0;
+	return macronix_set_dummy_cycles(nor, 8);
 }
 
 static int macronix_set_single_mode(struct spi_nor *nor)
 {
 	u8 read_dummy;
 
+	/*
+	 * Configure 8 dummy cycles for Fast Read 1-1-1 (0x0b) command (up to
+	 * 133MHz for STR and 66MHz for DTR). The Read 1-1-1 (0x03) command
+	 * expects no dummy cycle.
+	 * read_opcode should not be overridden here!
+	 */
 	switch (nor->read_opcode) {
 	case SPINOR_OP_READ:
 	case SPINOR_OP_READ4:
@@ -1236,8 +1376,7 @@ static int macronix_set_single_mode(struct spi_nor *nor)
 	}
 
 	nor->read_proto = SNOR_PROTO_1_1_1;
-	nor->read_dummy = read_dummy;
-	return 0;
+	return macronix_set_dummy_cycles(nor, read_dummy);
 }
 
 static int winbond_set_quad_mode(struct spi_nor *nor)
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 2dc0f8b429ca..8e0f43cecaca 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -75,6 +75,9 @@
 #define SPINOR_OP_EN4B		0xb7	/* Enter 4-byte mode */
 #define SPINOR_OP_EX4B		0xe9	/* Exit 4-byte mode */
 
+/* Used for Macronix flashes only. */
+#define SPINOR_OP_RDCR_MX	0x15	/* Read configuration register */
+
 /* Used for Winbond flashes only. */
 #define SPINOR_OP_RDSR2_WINB	0x35	/* Read status register 2 */
 #define SPINOR_OP_WRSR2_WINB	0x31	/* Write status register 2 */
-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Wed Feb  3 05:26:56 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 14:26:56 +0100
Subject: [PATCH v3 11/14] mtd: spi-nor: configure the number of dummy clock
 cycles on Spansion memories
In-Reply-To: <cover.1454505161.git.cyrille.pitchen@atmel.com>
References: <cover.1454505161.git.cyrille.pitchen@atmel.com>
Message-ID: <90dbc93adb34c4bbb7d6ea752f9f7a00219944d6.1454505161.git.cyrille.pitchen@atmel.com>

On Spansion memories, the number of dummy clock cycles to be used during
Fast Read commands is configured through the 2bit latency code (LC). These
bits are non-volatile inside the Configuration Register.

To avoid breaking the configuration expected at reset by some bootloaders,
we'd rather read the latency code and set the nor->read_dummy value
accordingly than update those non-volatile bits.

Since the Quad Enable non-volatile bit can be read at the same time from
the Control Register, we now check its value to avoid some calls of the
spansion_quad_enable() function when they are not needed.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
---
 drivers/mtd/spi-nor/spi-nor.c | 159 ++++++++++++++++++++++++++++++++++++------
 1 file changed, 137 insertions(+), 22 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index c560fbbb8479..356db141dcb2 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1668,47 +1668,162 @@ static int micron_set_single_mode(struct spi_nor *nor)
 	return micron_set_dummy_cycles(nor, read_dummy);
 }
 
-static int spansion_set_quad_mode(struct spi_nor *nor)
+static inline int spansion_get_config(struct spi_nor *nor,
+				      bool *quad_enabled,
+				      u8 *latency_code)
 {
-	int status;
+	int cr;
 
-	status = spansion_quad_enable(nor);
-	if (status) {
-		dev_err(nor->dev, "Spansion quad-read not enabled\n");
+	cr = read_cr(nor);
+	if (cr < 0) {
+		dev_err(nor->dev,
+			"error while reading the configuration register\n");
+		return cr;
+	}
+
+	if (quad_enabled)
+		*quad_enabled = !!(cr & CR_QUAD_EN_SPAN);
+
+	if (latency_code)
+		*latency_code = (u8)((cr & GENMASK(7, 6)) >> 6);
+
+	return 0;
+}
+
+static int spansion_set_dummy_cycles(struct spi_nor *nor, u8 latency_code)
+{
+	/* SDR dummy cycles */
+	switch (nor->read_opcode) {
+	case SPINOR_OP_READ:
+	case SPINOR_OP_READ4:
+		nor->read_dummy = 0;
+		break;
+
+	case SPINOR_OP_READ_FAST:
+	case SPINOR_OP_READ_1_1_2:
+	case SPINOR_OP_READ_1_1_4:
+	case SPINOR_OP_READ4_FAST:
+	case SPINOR_OP_READ4_1_1_2:
+	case SPINOR_OP_READ4_1_1_4:
+		nor->read_dummy = (latency_code == 3) ? 0 : 8;
+		break;
+
+	case SPINOR_OP_READ_1_2_2:
+	case SPINOR_OP_READ4_1_2_2:
+		switch (latency_code) {
+		default:
+		case 0:
+		case 3:
+			nor->read_dummy = 4;
+			break;
+		case 1:
+			nor->read_dummy = 5;
+			break;
+		case 2:
+			nor->read_dummy = 6;
+			break;
+		}
+		break;
+
+
+	case SPINOR_OP_READ_1_4_4:
+	case SPINOR_OP_READ4_1_4_4:
+		switch (latency_code) {
+		default:
+		case 0:
+		case 1:
+			nor->read_dummy = 4;
+			break;
+		case 2:
+			nor->read_dummy = 5;
+			break;
+		case 3:
+			nor->read_dummy = 1;
+			break;
+		}
+
+	default:
 		return -EINVAL;
 	}
+
+	return 0;
+}
+
+static int spansion_set_quad_mode(struct spi_nor *nor)
+{
+	bool quad_enabled;
+	u8 latency_code;
+	int ret;
+
+	/*
+	 * The QUAD bit of Configuration Register must be set (CR Bit1=1) for
+	 * using any Quad SPI command.
+	 */
+	ret = spansion_get_config(nor, &quad_enabled, &latency_code);
+	if (ret)
+		return ret;
+
+	/* The Quad mode should be enabled ... */
+	if (!quad_enabled) {
+		/* ... if not try to enable it. */
+		dev_warn(nor->dev, "Spansion Quad mode disabled, enable it\n");
+		ret = spansion_quad_enable(nor);
+		if (ret)
+			return ret;
+	}
+
+	/*
+	 * Don't use the Fast Read Quad I/O (0xeb / 0xec) commands as their
+	 * number of dummy cycles can not be set to a multiple of 8: some SPI
+	 * controllers, especially those relying on the m25p80 driver, expect
+	 * the number of dummy cycles to be a multiple of 8.
+	 * Also when using a Fast Read Quad I/O command, the memory checks the
+	 * value of the first mode/dummy cycles to decice whether it enters or
+	 * leaves the Countinuous Read mode. We should never enter the
+	 * Countinuous Read mode as the spi-nor framework doesn't support it.
+	 * For all these reason, we'd rather use the Fast Read Quad Output
+	 * 1-1-4 (0x6b / 0x6c) commands instead.
+	 */
 	nor->read_proto = SNOR_PROTO_1_1_4;
 	nor->read_opcode = SPINOR_OP_READ_1_1_4;
-	nor->read_dummy = 8;
-	return 0;
+	return spansion_set_dummy_cycles(nor, latency_code);
 }
 
 static int spansion_set_dual_mode(struct spi_nor *nor)
 {
+	u8 latency_code;
+	int ret;
+
+	/* We don't care about the quad mode status */
+	ret = spansion_get_config(nor, NULL, &latency_code);
+	if (ret)
+		return ret;
+
+	/*
+	 * Don't use the Fast Read Dual I/O (0xbb / 0xbc) commands as their
+	 * number of dummy cycles can not bet set to a multiple of 8: some SPI
+	 * controllers, especially those relying on the m25p80 driver, expect
+	 * the number of dummy cycles to be a multiple of 8.
+	 * For this reason, w'd rather use the Fast Read Dual Output 1-1-2
+	 * (0x3b / 0x3c) commands instead.
+	 */
 	nor->read_proto = SNOR_PROTO_1_1_2;
 	nor->read_opcode = SPINOR_OP_READ_1_1_2;
-	nor->read_dummy = 8;
-	return 0;
+	return spansion_set_dummy_cycles(nor, latency_code);
 }
 
 static int spansion_set_single_mode(struct spi_nor *nor)
 {
-	u8 read_dummy;
-
-	switch (nor->read_opcode) {
-	case SPINOR_OP_READ:
-	case SPINOR_OP_READ4:
-		read_dummy = 0;
-		break;
+	u8 latency_code;
+	int ret;
 
-	default:
-		read_dummy = 8;
-		break;
-	}
+	/* We don't care about the quad mode status */
+	ret = spansion_get_config(nor, NULL, &latency_code);
+	if (ret)
+		return ret;
 
 	nor->read_proto = SNOR_PROTO_1_1_1;
-	nor->read_dummy = read_dummy;
-	return 0;
+	return spansion_set_dummy_cycles(nor, latency_code);
 }
 
 static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Wed Feb  3 05:26:57 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 14:26:57 +0100
Subject: [PATCH v3 12/14] mtd: m25p80: add support of dual and quad spi
 protocols to all commands
In-Reply-To: <cover.1454505161.git.cyrille.pitchen@atmel.com>
References: <cover.1454505161.git.cyrille.pitchen@atmel.com>
Message-ID: <8c1d521b6ec8bd60c8d5c8911c0df56a6857109d.1454505161.git.cyrille.pitchen@atmel.com>

Before this patch, m25p80_read() supported few SPI protocols:
- regular SPI 1-1-1
- SPI Dual Output 1-1-2
- SPI Quad Output 1-1-4
On the other hand, all other m25p80_*() hooks only supported SPI 1-1-1.

However once their Quad mode enabled, Micron and Macronix spi-nor memories
expect all commands to use the SPI 4-4-4 protocol.

Also, once their Dual mode enabled, Micron spi-nor memories expect all
commands to use the SPI-2-2-2 protocol.

So this patch adds support to all currently existing SPI protocols to
cover as many protocols as possible.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
---
 drivers/mtd/devices/m25p80.c | 192 ++++++++++++++++++++++++++++++++++---------
 1 file changed, 151 insertions(+), 41 deletions(-)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index c9c3b7fa3051..a57c7d0e3f39 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -27,22 +27,64 @@
 #include <linux/spi/flash.h>
 #include <linux/mtd/spi-nor.h>
 
-#define	MAX_CMD_SIZE		6
+#define	MAX_CMD_SIZE		16
 struct m25p {
 	struct spi_device	*spi;
 	struct spi_nor		spi_nor;
 	u8			command[MAX_CMD_SIZE];
 };
 
+static inline int m25p80_proto2nbits(enum spi_nor_protocol proto,
+				     unsigned *code_nbits,
+				     unsigned *addr_nbits,
+				     unsigned *data_nbits)
+{
+	if (code_nbits)
+		*code_nbits = SNOR_PROTO_CMD_FROM_PROTO(proto);
+	if (addr_nbits)
+		*addr_nbits = SNOR_PROTO_ADDR_FROM_PROTO(proto);
+	if (data_nbits)
+		*data_nbits = SNOR_PROTO_DATA_FROM_PROTO(proto);
+
+	return 0;
+}
+
 static int m25p80_read_reg(struct spi_nor *nor, u8 code, u8 *val, int len)
 {
 	struct m25p *flash = nor->priv;
 	struct spi_device *spi = flash->spi;
+	unsigned code_nbits, data_nbits;
+	struct spi_transfer xfers[2];
 	int ret;
 
-	ret = spi_write_then_read(spi, &code, 1, val, len);
+	/* Check the total length of command op code and data. */
+	if (len + 1 > MAX_CMD_SIZE)
+		return -EINVAL;
+
+	/* Get transfer protocols (addr_nbits is not relevant here). */
+	ret = m25p80_proto2nbits(nor->reg_proto,
+				 &code_nbits, NULL, &data_nbits);
+	if (ret < 0)
+		return ret;
+
+	/* Set up transfers. */
+	memset(xfers, 0, sizeof(xfers));
+
+	flash->command[0] = code;
+	xfers[0].len = 1;
+	xfers[0].tx_buf = flash->command;
+	xfers[0].tx_nbits = code_nbits;
+
+	xfers[1].len = len;
+	xfers[1].rx_buf = &flash->command[1];
+	xfers[1].rx_nbits = data_nbits;
+
+	/* Process command. */
+	ret = spi_sync_transfer(spi, xfers, 2);
 	if (ret < 0)
 		dev_err(&spi->dev, "error %d reading %x\n", ret, code);
+	else
+		memcpy(val, &flash->command[1], len);
 
 	return ret;
 }
@@ -65,12 +107,42 @@ static int m25p80_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
 {
 	struct m25p *flash = nor->priv;
 	struct spi_device *spi = flash->spi;
+	unsigned code_nbits, data_nbits, num_xfers = 1;
+	struct spi_transfer xfers[2];
+	int ret;
+
+	/* Check the total length of command op code and data. */
+	if (buf && (len + 1 > MAX_CMD_SIZE))
+		return -EINVAL;
+
+	/* Get transfer protocols (addr_nbits is not relevant here). */
+	ret = m25p80_proto2nbits(nor->reg_proto,
+				 &code_nbits, NULL, &data_nbits);
+	if (ret < 0)
+		return ret;
+
+	/* Set up transfer(s). */
+	memset(xfers, 0, sizeof(xfers));
 
 	flash->command[0] = opcode;
-	if (buf)
+	xfers[0].len = 1;
+	xfers[0].tx_buf = flash->command;
+	xfers[0].tx_nbits = code_nbits;
+
+	if (buf) {
 		memcpy(&flash->command[1], buf, len);
+		if (data_nbits == code_nbits) {
+			xfers[0].len += len;
+		} else {
+			xfers[1].len = len;
+			xfers[1].tx_buf = &flash->command[1];
+			xfers[1].tx_nbits = data_nbits;
+			num_xfers++;
+		}
+	}
 
-	return spi_write(spi, flash->command, len + 1);
+	/* Process command. */
+	return spi_sync_transfer(spi, xfers, num_xfers);
 }
 
 static void m25p80_write(struct spi_nor *nor, loff_t to, size_t len,
@@ -78,43 +150,54 @@ static void m25p80_write(struct spi_nor *nor, loff_t to, size_t len,
 {
 	struct m25p *flash = nor->priv;
 	struct spi_device *spi = flash->spi;
-	struct spi_transfer t[2] = {};
+	unsigned code_nbits, addr_nbits, data_nbits, num_xfers = 1;
+	struct spi_transfer xfers[3];
 	struct spi_message m;
-	int cmd_sz = m25p_cmdsz(nor);
-
-	spi_message_init(&m);
+	int ret, cmd_sz = m25p_cmdsz(nor);
 
 	if (nor->program_opcode == SPINOR_OP_AAI_WP && nor->sst_write_second)
 		cmd_sz = 1;
 
-	flash->command[0] = nor->program_opcode;
-	m25p_addr2cmd(nor, to, flash->command);
+	/* Get transfer protocols. */
+	ret = m25p80_proto2nbits(nor->write_proto,
+				 &code_nbits, &addr_nbits, &data_nbits);
+	if (ret < 0) {
+		*retlen = 0;
+		return;
+	}
 
-	t[0].tx_buf = flash->command;
-	t[0].len = cmd_sz;
-	spi_message_add_tail(&t[0], &m);
+	/* Set up transfers. */
+	memset(xfers, 0, sizeof(xfers));
+
+	flash->command[0] = nor->program_opcode;
+	xfers[0].len = 1;
+	xfers[0].tx_buf = flash->command;
+	xfers[0].tx_nbits = code_nbits;
+
+	if (cmd_sz > 1) {
+		m25p_addr2cmd(nor, to, flash->command);
+		if (addr_nbits == code_nbits) {
+			xfers[0].len += nor->addr_width;
+		} else {
+			xfers[1].len = nor->addr_width;
+			xfers[1].tx_buf = &flash->command[1];
+			xfers[1].tx_nbits = addr_nbits;
+			num_xfers++;
+		}
+	}
 
-	t[1].tx_buf = buf;
-	t[1].len = len;
-	spi_message_add_tail(&t[1], &m);
+	xfers[num_xfers].len = len;
+	xfers[num_xfers].tx_buf = buf;
+	xfers[num_xfers].tx_nbits = data_nbits;
+	num_xfers++;
 
+	/* Process command. */
+	spi_message_init_with_transfers(&m, xfers, num_xfers);
 	spi_sync(spi, &m);
 
 	*retlen += m.actual_length - cmd_sz;
 }
 
-static inline unsigned int m25p80_rx_nbits(struct spi_nor *nor)
-{
-	switch (nor->flash_read) {
-	case SPI_NOR_DUAL:
-		return 2;
-	case SPI_NOR_QUAD:
-		return 4;
-	default:
-		return 0;
-	}
-}
-
 /*
  * Read an address range from the nor chip.  The address range
  * may be any size provided it is within the physical boundaries.
@@ -124,28 +207,55 @@ static int m25p80_read(struct spi_nor *nor, loff_t from, size_t len,
 {
 	struct m25p *flash = nor->priv;
 	struct spi_device *spi = flash->spi;
-	struct spi_transfer t[2];
-	struct spi_message m;
+	unsigned code_nbits, addr_nbits, data_nbits, num_xfers = 1;
 	unsigned int dummy = nor->read_dummy;
+	struct spi_transfer xfers[3];
+	struct spi_message m;
+	int ret;
+
+	/* Get transfer protocols. */
+	ret = m25p80_proto2nbits(nor->read_proto,
+				 &code_nbits, &addr_nbits, &data_nbits);
+	if (ret < 0) {
+		*retlen = 0;
+		return ret;
+	}
 
 	/* convert the dummy cycles to the number of bytes */
-	dummy /= 8;
+	dummy = (dummy * addr_nbits) / 8;
 
-	spi_message_init(&m);
-	memset(t, 0, (sizeof t));
+	/* Set up transfers. */
+	memset(xfers, 0, sizeof(xfers));
 
 	flash->command[0] = nor->read_opcode;
-	m25p_addr2cmd(nor, from, flash->command);
+	xfers[0].len = 1;
+	xfers[0].tx_buf = flash->command;
+	xfers[0].tx_nbits = code_nbits;
 
-	t[0].tx_buf = flash->command;
-	t[0].len = m25p_cmdsz(nor) + dummy;
-	spi_message_add_tail(&t[0], &m);
+	m25p_addr2cmd(nor, from, flash->command);
+	/*
+	 * Clear all dummy/mode cycle bits to avoid sending some manufacturer
+	 * specific pattern, which might make the memory enter its Continuous
+	 * Read mode by mistake.
+	 */
+	memset(flash->command + 1 + nor->addr_width, 0, dummy);
+
+	if (addr_nbits == code_nbits) {
+		xfers[0].len += nor->addr_width + dummy;
+	} else {
+		xfers[1].len = nor->addr_width + dummy;
+		xfers[1].tx_buf = &flash->command[1];
+		xfers[1].tx_nbits = addr_nbits;
+		num_xfers++;
+	}
 
-	t[1].rx_buf = buf;
-	t[1].rx_nbits = m25p80_rx_nbits(nor);
-	t[1].len = len;
-	spi_message_add_tail(&t[1], &m);
+	xfers[num_xfers].len = len;
+	xfers[num_xfers].rx_buf = buf;
+	xfers[num_xfers].rx_nbits = data_nbits;
+	num_xfers++;
 
+	/* Process command. */
+	spi_message_init_with_transfers(&m, xfers, num_xfers);
 	spi_sync(spi, &m);
 
 	*retlen = m.actual_length - m25p_cmdsz(nor) - dummy;
-- 
1.8.2.2



From Chris.Brandt at renesas.com  Wed Feb  3 05:33:13 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Wed, 3 Feb 2016 13:33:13 +0000
Subject: [PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <HKXPR06MB0565A2CFF95AD7C000F43E6A8ADF0@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu9VvskQ34w0niS+6AtF9hNcycfYDt_3Kp4T+WK8Vxf_dA@mail.gmail.com> 
Message-ID: <HKXPR06MB05656F902E0E1FBBDBD713DC8AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>

On 2 Feb 2016, Chris Brandt wrote:
> I then applied the 3 patches and tried again and this time it booted
> up....almost.
> It looks like it makes it all the way up to when it is going to mount
> my rootfs, but then dies.


I did some debugging, and here's why I'm crashing.


If you look at my System.map file, you'll see that I've got 2 "__stubs_start" symbols.

One at 0x bf353edc, the other at 0x bf353ee0.

bf353edc T __stubs_start
bf353edc T _etext
bf353ee0 t __stubs_start
bf353ee4 t vector_rst
bf353f00 t vector_irq
bf353f80 t vector_dabt
bf354000 t vector_pabt
bf354080 t vector_und
bf354100 t vector_addrexcptn
bf354120 T vector_fiq
bf3541a0 T __stubs_end
bf3541a0 T __vectors_start
bf3541c0 t __mmap_switched
bf3541c0 T __vectors_end


So, when you get to early_trap_init(), it grabs the first __stubs_start for the memcpy:

	memcpy((void *)vectors + 0x1000, __stubs_start, __stubs_end - __stubs_start);


And when a printed out the destination, I get:

   Stubs at c09ff000 :00000000 BF006F20 EF9F0000 EA000064 etc...

Notice the first entry is 0....that's not right...and we know it's using that first __stubs_start symbol.


So, I hacked the code and put an offset of 4 like this:

	memcpy((void *)vectors + 0x1000, __stubs_start+4, __stubs_end - (__stubs_start+4));


And sure enough it booted fine.


So, why are there 2 __stubs_start symbols???
I haven't figured that one out yet.

And, I'm assuming you guys don't have 2 __stubs_start symbols either, correct?


Chris


From cyrille.pitchen at atmel.com  Wed Feb  3 05:26:58 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 14:26:58 +0100
Subject: [PATCH v3 13/14] Documentation: atmel-quadspi: add binding file for
 Atmel QSPI driver
In-Reply-To: <cover.1454505161.git.cyrille.pitchen@atmel.com>
References: <cover.1454505161.git.cyrille.pitchen@atmel.com>
Message-ID: <6661b477af9b72cca1a29cac8a64c2295116cd8b.1454505161.git.cyrille.pitchen@atmel.com>

This patch documents the DT bindings for the driver of the Atmel QSPI
controller embedded inside sama5d2x SoCs.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
Acked-by: Rob Herring <robh at kernel.org>
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 .../devicetree/bindings/mtd/atmel-quadspi.txt      | 32 ++++++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/atmel-quadspi.txt

diff --git a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
new file mode 100644
index 000000000000..489807005eda
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
@@ -0,0 +1,32 @@
+* Atmel Quad Serial Peripheral Interface (QSPI)
+
+Required properties:
+- compatible:     Should be "atmel,sama5d2-qspi".
+- reg:            Should contain the locations and lengths of the base registers
+                  and the mapped memory.
+- reg-names:      Should contain the resource reg names:
+                  - qspi_base: configuration register address space
+                  - qspi_mmap: memory mapped address space
+- interrupts:     Should contain the interrupt for the device.
+- clocks:         The phandle of the clock needed by the QSPI controller.
+- #address-cells: Should be <1>.
+- #size-cells:    Should be <0>.
+
+Example:
+
+spi at f0020000 {
+	compatible = "atmel,sama5d2-qspi";
+	reg = <0xf0020000 0x100>, <0xd0000000 0x8000000>;
+	reg-names = "qspi_base", "qspi_mmap";
+	interrupts = <52 IRQ_TYPE_LEVEL_HIGH 7>;
+	clocks = <&spi0_clk>;
+	#address-cells = <1>;
+	#size-cells = <0>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_spi0_default>;
+	status = "okay";
+
+	m25p80 at 0 {
+		...
+	};
+};
-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Wed Feb  3 05:26:59 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Wed, 3 Feb 2016 14:26:59 +0100
Subject: [PATCH v3 14/14] mtd: atmel-quadspi: add driver for Atmel QSPI
 controller
In-Reply-To: <cover.1454505161.git.cyrille.pitchen@atmel.com>
References: <cover.1454505161.git.cyrille.pitchen@atmel.com>
Message-ID: <a6d1ef54e92ec033575e71d1b8e1611ac2ec427b.1454505161.git.cyrille.pitchen@atmel.com>

This driver add support to the new Atmel QSPI controller embedded into
sama5d2x SoCs. It expects a NOR memory to be connected to the QSPI
controller.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
---
 drivers/mtd/spi-nor/Kconfig         |   9 +
 drivers/mtd/spi-nor/Makefile        |   1 +
 drivers/mtd/spi-nor/atmel-quadspi.c | 877 ++++++++++++++++++++++++++++++++++++
 3 files changed, 887 insertions(+)
 create mode 100644 drivers/mtd/spi-nor/atmel-quadspi.c

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 83befab4b5b4..75c64fa6de16 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -38,6 +38,15 @@ config SPI_FSL_QUADSPI
 	  This controller does not support generic SPI. It only supports
 	  SPI NOR.
 
+config SPI_ATMEL_QUADSPI
+	tristate "Atmel Quad SPI Controller"
+	depends on ARCH_AT91 || (ARM && COMPILE_TEST)
+	depends on OF && HAS_DMA && HAS_IOMEM
+	help
+	  This enables support for the Quad SPI controller in master mode.
+	  This driver does not support generic SPI. The implementation only
+	  supports SPI NOR.
+
 config SPI_NXP_SPIFI
 	tristate "NXP SPI Flash Interface (SPIFI)"
 	depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 0bf3a7f81675..1525913698ad 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_MTD_SPI_NOR)	+= spi-nor.o
 obj-$(CONFIG_SPI_FSL_QUADSPI)	+= fsl-quadspi.o
 obj-$(CONFIG_MTD_MT81xx_NOR)    += mtk-quadspi.o
 obj-$(CONFIG_SPI_NXP_SPIFI)	+= nxp-spifi.o
+obj-$(CONFIG_SPI_ATMEL_QUADSPI)	+= atmel-quadspi.o
diff --git a/drivers/mtd/spi-nor/atmel-quadspi.c b/drivers/mtd/spi-nor/atmel-quadspi.c
new file mode 100644
index 000000000000..3a500d92e413
--- /dev/null
+++ b/drivers/mtd/spi-nor/atmel-quadspi.c
@@ -0,0 +1,877 @@
+/*
+ * Driver for Atmel QSPI Controller
+ *
+ * Copyright (C) 2015 Atmel Corporation
+ *
+ * Author: Cyrille Pitchen <cyrille.pitchen at atmel.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/>.
+ *
+ * This driver is based on drivers/mtd/spi-nor/fsl-quadspi.c from Freescale.
+ */
+
+#include <linux/kernel.h>
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/dma-mapping.h>
+#include <linux/dmaengine.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/spi-nor.h>
+#include <linux/platform_data/atmel.h>
+#include <linux/platform_data/dma-atmel.h>
+#include <linux/of.h>
+
+#include <linux/io.h>
+#include <linux/gpio.h>
+#include <linux/pinctrl/consumer.h>
+
+/* QSPI register offsets */
+#define QSPI_CR      0x0000  /* Control Register */
+#define QSPI_MR      0x0004  /* Mode Register */
+#define QSPI_RD      0x0008  /* Receive Data Register */
+#define QSPI_TD      0x000c  /* Transmit Data Register */
+#define QSPI_SR      0x0010  /* Status Register */
+#define QSPI_IER     0x0014  /* Interrupt Enable Register */
+#define QSPI_IDR     0x0018  /* Interrupt Disable Register */
+#define QSPI_IMR     0x001c  /* Interrupt Mask Register */
+#define QSPI_SCR     0x0020  /* Serial Clock Register */
+
+#define QSPI_IAR     0x0030  /* Instruction Address Register */
+#define QSPI_ICR     0x0034  /* Instruction Code Register */
+#define QSPI_IFR     0x0038  /* Instruction Frame Register */
+
+#define QSPI_SMR     0x0040  /* Scrambling Mode Register */
+#define QSPI_SKR     0x0044  /* Scrambling Key Register */
+
+#define QSPI_WPMR    0x00E4  /* Write Protection Mode Register */
+#define QSPI_WPSR    0x00E8  /* Write Protection Status Register */
+
+#define QSPI_VERSION 0x00FC  /* Version Register */
+
+
+/* Bitfields in QSPI_CR (Control Register) */
+#define QSPI_CR_QSPIEN                  BIT(0)
+#define QSPI_CR_QSPIDIS                 BIT(1)
+#define QSPI_CR_SWRST                   BIT(7)
+#define QSPI_CR_LASTXFER                BIT(24)
+
+/* Bitfields in QSPI_MR (Mode Register) */
+#define QSPI_MR_SSM                     BIT(0)
+#define QSPI_MR_LLB                     BIT(1)
+#define QSPI_MR_WDRBT                   BIT(2)
+#define QSPI_MR_SMRM                    BIT(3)
+#define QSPI_MR_CSMODE_MASK             GENMASK(5, 4)
+#define QSPI_MR_CSMODE_NOT_RELOADED     (0 << 4)
+#define QSPI_MR_CSMODE_LASTXFER         (1 << 4)
+#define QSPI_MR_CSMODE_SYSTEMATICALLY   (2 << 4)
+#define QSPI_MR_NBBITS_MASK             GENMASK(11, 8)
+#define QSPI_MR_NBBITS(n)               ((((n) - 8) << 8) & QSPI_MR_NBBITS_MASK)
+#define QSPI_MR_DLYBCT_MASK             GENMASK(23, 16)
+#define QSPI_MR_DLYBCT(n)               (((n) << 16) & QSPI_MR_DLYBCT_MASK)
+#define QSPI_MR_DLYCS_MASK              GENMASK(31, 24)
+#define QSPI_MR_DLYCS(n)                (((n) << 24) & QSPI_MR_DLYCS_MASK)
+
+/* Bitfields in QSPI_SR/QSPI_IER/QSPI_IDR/QSPI_IMR  */
+#define QSPI_SR_RDRF                    BIT(0)
+#define QSPI_SR_TDRE                    BIT(1)
+#define QSPI_SR_TXEMPTY                 BIT(2)
+#define QSPI_SR_OVRES                   BIT(3)
+#define QSPI_SR_CSR                     BIT(8)
+#define QSPI_SR_CSS                     BIT(9)
+#define QSPI_SR_INSTRE                  BIT(10)
+#define QSPI_SR_QSPIENS                 BIT(24)
+
+/* Bitfields in QSPI_SCR (Serial Clock Register) */
+#define QSPI_SCR_CPOL                   BIT(0)
+#define QSPI_SCR_CPHA                   BIT(1)
+#define QSPI_SCR_SCBR_MASK              GENMASK(15, 8)
+#define QSPI_SCR_SCBR(n)                (((n) << 8) & QSPI_SCR_SCBR_MASK)
+#define QSPI_SCR_DLYBS_MASK             GENMASK(23, 16)
+#define QSPI_SCR_DLYBS(n)               (((n) << 16) & QSPI_SCR_DLYBS_MASK)
+
+/* Bitfields in QSPI_ICR (Instruction Code Register) */
+#define QSPI_ICR_INST_MASK              GENMASK(7, 0)
+#define QSPI_ICR_INST(inst)             (((inst) << 0) & QSPI_ICR_INST_MASK)
+#define QSPI_ICR_OPT_MASK               GENMASK(23, 16)
+#define QSPI_ICR_OPT(opt)               (((opt) << 16) & QSPI_ICR_OPT_MASK)
+
+/* Bitfields in QSPI_IFR (Instruction Frame Register) */
+#define QSPI_IFR_WIDTH_MASK             GENMASK(2, 0)
+#define QSPI_IFR_WIDTH_SINGLE_BIT_SPI   (0 << 0)
+#define QSPI_IFR_WIDTH_DUAL_OUTPUT      (1 << 0)
+#define QSPI_IFR_WIDTH_QUAD_OUTPUT      (2 << 0)
+#define QSPI_IFR_WIDTH_DUAL_IO          (3 << 0)
+#define QSPI_IFR_WIDTH_QUAD_IO          (4 << 0)
+#define QSPI_IFR_WIDTH_DUAL_CMD         (5 << 0)
+#define QSPI_IFR_WIDTH_QUAD_CMD         (6 << 0)
+#define QSPI_IFR_INSTEN                 BIT(4)
+#define QSPI_IFR_ADDREN                 BIT(5)
+#define QSPI_IFR_OPTEN                  BIT(6)
+#define QSPI_IFR_DATAEN                 BIT(7)
+#define QSPI_IFR_OPTL_MASK              GENMASK(9, 8)
+#define QSPI_IFR_OPTL_1BIT              (0 << 8)
+#define QSPI_IFR_OPTL_2BIT              (1 << 8)
+#define QSPI_IFR_OPTL_4BIT              (2 << 8)
+#define QSPI_IFR_OPTL_8BIT              (3 << 8)
+#define QSPI_IFR_ADDRL                  BIT(10)
+#define QSPI_IFR_TFRTYP_MASK            GENMASK(13, 12)
+#define QSPI_IFR_TFRTYP_TRSFR_READ      (0 << 12)
+#define QSPI_IFR_TFRTYP_TRSFR_READ_MEM  (1 << 12)
+#define QSPI_IFR_TFRTYP_TRSFR_WRITE     (2 << 12)
+#define QSPI_IFR_TFRTYP_TRSFR_WRITE_MEM (3 << 13)
+#define QSPI_IFR_CRM                    BIT(14)
+#define QSPI_IFR_NBDUM_MASK             GENMASK(20, 16)
+#define QSPI_IFR_NBDUM(n)               (((n) << 16) & QSPI_IFR_NBDUM_MASK)
+
+/* Bitfields in QSPI_SMR (Scrambling Mode Register) */
+#define QSPI_SMR_SCREN                  BIT(0)
+#define QSPI_SMR_RVDIS                  BIT(1)
+
+/* Bitfields in QSPI_WPMR (Write Protection Mode Register) */
+#define QSPI_WPMR_WPEN                  BIT(0)
+#define QSPI_WPMR_WPKEY_MASK            GENMASK(31, 8)
+#define QSPI_WPMR_WPKEY(wpkey)          (((wpkey) << 8) & QSPI_WPMR_WPKEY_MASK)
+
+/* Bitfields in QSPI_WPSR (Write Protection Status Register) */
+#define QSPI_WPSR_WPVS                  BIT(0)
+#define QSPI_WPSR_WPVSRC_MASK           GENMASK(15, 8)
+#define QSPI_WPSR_WPVSRC(src)           (((src) << 8) & QSPI_WPSR_WPVSRC)
+
+
+struct atmel_qspi {
+	void __iomem		*regs;
+	void __iomem		*mem;
+	dma_addr_t		phys_addr;
+	struct dma_chan		*chan;
+	struct clk		*clk;
+	struct platform_device	*pdev;
+	u32			pending;
+
+	struct spi_nor		nor;
+	u32			clk_rate;
+	struct completion	cmd_completion;
+	struct completion	dma_completion;
+
+#ifdef DEBUG
+	u8			last_instruction;
+#endif
+};
+
+struct atmel_qspi_command {
+	u32	ifr;
+	union {
+		struct {
+			u32	instruction:1;
+			u32	address:3;
+			u32	mode:1;
+			u32	dummy:1;
+			u32	data:1;
+			u32	dma:1;
+			u32	reserved:24;
+		}		bits;
+		u32	word;
+	}	enable;
+	u8	instruction;
+	u8	mode;
+	u8	num_mode_cycles;
+	u8	num_dummy_cycles;
+	u32	address;
+
+	size_t		buf_len;
+	const void	*tx_buf;
+	void		*rx_buf;
+};
+
+/* Register access functions */
+static inline u32 qspi_readl(struct atmel_qspi *aq, u32 reg)
+{
+	return readl_relaxed(aq->regs + reg);
+}
+
+static inline void qspi_writel(struct atmel_qspi *aq, u32 reg, u32 value)
+{
+	writel_relaxed(value, aq->regs + reg);
+}
+
+
+#define QSPI_DMA_THRESHOLD	32
+
+static void atmel_qspi_dma_callback(void *arg)
+{
+	struct completion *dma_completion = arg;
+
+	complete(dma_completion);
+}
+
+static int atmel_qspi_run_dma_transfer(struct atmel_qspi *aq,
+				       const struct atmel_qspi_command *cmd)
+{
+	u32 offset = (cmd->enable.bits.address) ? cmd->address : 0;
+	struct dma_chan *chan = aq->chan;
+	struct device *dev = &aq->pdev->dev;
+	enum dma_data_direction direction;
+	dma_addr_t phys_addr, dst, src;
+	struct dma_async_tx_descriptor *desc;
+	dma_cookie_t cookie;
+	int err = 0;
+
+	if (cmd->tx_buf) {
+		direction = DMA_TO_DEVICE;
+		phys_addr = dma_map_single(dev, (void *)cmd->tx_buf,
+					   cmd->buf_len, direction);
+		src = phys_addr;
+		dst = aq->phys_addr + offset;
+	} else {
+		direction = DMA_FROM_DEVICE;
+		phys_addr = dma_map_single(dev, (void *)cmd->rx_buf,
+					   cmd->buf_len, direction);
+		src = aq->phys_addr + offset;
+		dst = phys_addr;
+	}
+	if (dma_mapping_error(dev, phys_addr))
+		return -ENOMEM;
+
+	desc = chan->device->device_prep_dma_memcpy(chan, dst, src,
+						    cmd->buf_len,
+						    DMA_PREP_INTERRUPT);
+	if (!desc) {
+		err = -ENOMEM;
+		goto unmap_single;
+	}
+
+	reinit_completion(&aq->dma_completion);
+	desc->callback = atmel_qspi_dma_callback;
+	desc->callback_param = &aq->dma_completion;
+	cookie = dmaengine_submit(desc);
+	err = dma_submit_error(cookie);
+	if (err)
+		goto unmap_single;
+	dma_async_issue_pending(chan);
+
+	if (!wait_for_completion_timeout(&aq->dma_completion,
+					 msecs_to_jiffies(1000)))
+		err = -ETIMEDOUT;
+
+	if (dma_async_is_tx_complete(chan, cookie, NULL, NULL) != DMA_COMPLETE)
+		err = -ETIMEDOUT;
+
+	if (err)
+		dmaengine_terminate_all(chan);
+unmap_single:
+	dma_unmap_single(dev, phys_addr, cmd->buf_len, direction);
+
+	return err;
+}
+
+static int atmel_qspi_run_transfer(struct atmel_qspi *aq,
+				   const struct atmel_qspi_command *cmd)
+{
+	void __iomem *ahb_mem;
+
+	/* First try a DMA transfer */
+	if (aq->chan && cmd->enable.bits.dma &&
+	    cmd->buf_len >= QSPI_DMA_THRESHOLD)
+		return atmel_qspi_run_dma_transfer(aq, cmd);
+
+	/* Then fallback to a PIO transfer (memcpy() DOES NOT work!) */
+	ahb_mem = aq->mem;
+	if (cmd->enable.bits.address)
+		ahb_mem += cmd->address;
+	if (cmd->tx_buf)
+		_memcpy_toio(ahb_mem, cmd->tx_buf, cmd->buf_len);
+	else
+		_memcpy_fromio(cmd->rx_buf, ahb_mem, cmd->buf_len);
+
+	return 0;
+}
+
+#ifdef DEBUG
+static void atmel_qspi_debug_command(struct atmel_qspi *aq,
+				     const struct atmel_qspi_command *cmd)
+{
+	u8 cmd_buf[SPI_NOR_MAX_CMD_SIZE];
+	size_t len = 0;
+	int i;
+
+	if (cmd->enable.bits.instruction) {
+		if (aq->last_instruction == cmd->instruction)
+			return;
+		aq->last_instruction = cmd->instruction;
+	}
+
+	if (cmd->enable.bits.instruction)
+		cmd_buf[len++] = cmd->instruction;
+
+	for (i = cmd->enable.bits.address-1; i >= 0; --i)
+		cmd_buf[len++] = (cmd->address >> (i << 3)) & 0xff;
+
+	if (cmd->enable.bits.mode)
+		cmd_buf[len++] = cmd->mode;
+
+	if (cmd->enable.bits.dummy) {
+		int num = cmd->num_dummy_cycles;
+
+		switch (cmd->ifr & QSPI_IFR_WIDTH_MASK) {
+		case QSPI_IFR_WIDTH_SINGLE_BIT_SPI:
+		case QSPI_IFR_WIDTH_DUAL_OUTPUT:
+		case QSPI_IFR_WIDTH_QUAD_OUTPUT:
+			num >>= 3;
+			break;
+		case QSPI_IFR_WIDTH_DUAL_IO:
+		case QSPI_IFR_WIDTH_DUAL_CMD:
+			num >>= 2;
+			break;
+		case QSPI_IFR_WIDTH_QUAD_IO:
+		case QSPI_IFR_WIDTH_QUAD_CMD:
+			num >>= 1;
+			break;
+		default:
+			return;
+		}
+
+		for (i = 0; i < num; ++i)
+			cmd_buf[len++] = 0;
+	}
+
+	/* Dump the SPI command */
+	print_hex_dump(KERN_DEBUG, "qspi cmd: ", DUMP_PREFIX_NONE,
+		       32, 1, cmd_buf, len, false);
+
+#ifdef VERBOSE_DEBUG
+	/* If verbose debug is enabled, also dump the TX data */
+	if (cmd->enable.bits.data && cmd->tx_buf)
+		print_hex_dump(KERN_DEBUG, "qspi tx : ", DUMP_PREFIX_NONE,
+			       32, 1, cmd->tx_buf, cmd->buf_len, false);
+#endif
+}
+#else
+#define atmel_qspi_debug_command(aq, cmd)
+#endif
+
+static int atmel_qspi_run_command(struct atmel_qspi *aq,
+				  const struct atmel_qspi_command *cmd)
+{
+	u32 iar, icr, ifr, sr;
+	int err = 0;
+
+	iar = 0;
+	icr = 0;
+	ifr = cmd->ifr;
+
+	/* Compute instruction parameters */
+	if (cmd->enable.bits.instruction) {
+		icr |= QSPI_ICR_INST(cmd->instruction);
+		ifr |= QSPI_IFR_INSTEN;
+	}
+
+	/* Compute address parameters */
+	switch (cmd->enable.bits.address) {
+	case 4:
+		ifr |= QSPI_IFR_ADDRL;
+		/* fall through to the 24bit (3 byte) address case. */
+	case 3:
+		iar = (cmd->enable.bits.data) ? 0 : cmd->address;
+		ifr |= QSPI_IFR_ADDREN;
+		break;
+	case 0:
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	/* Compute option parameters */
+	if (cmd->enable.bits.mode && cmd->num_mode_cycles) {
+		u32 mode_cycle_bits, mode_bits;
+
+		icr |= QSPI_ICR_OPT(cmd->mode);
+		ifr |= QSPI_IFR_OPTEN;
+
+		switch (ifr & QSPI_IFR_WIDTH_MASK) {
+		case QSPI_IFR_WIDTH_SINGLE_BIT_SPI:
+		case QSPI_IFR_WIDTH_DUAL_OUTPUT:
+		case QSPI_IFR_WIDTH_QUAD_OUTPUT:
+			mode_cycle_bits = 1;
+			break;
+		case QSPI_IFR_WIDTH_DUAL_IO:
+		case QSPI_IFR_WIDTH_DUAL_CMD:
+			mode_cycle_bits = 2;
+			break;
+		case QSPI_IFR_WIDTH_QUAD_IO:
+		case QSPI_IFR_WIDTH_QUAD_CMD:
+			mode_cycle_bits = 4;
+			break;
+		default:
+			return -EINVAL;
+		}
+
+		mode_bits = cmd->num_mode_cycles * mode_cycle_bits;
+		switch (mode_bits) {
+		case 1:
+			ifr |= QSPI_IFR_OPTL_1BIT;
+			break;
+
+		case 2:
+			ifr |= QSPI_IFR_OPTL_2BIT;
+			break;
+
+		case 4:
+			ifr |= QSPI_IFR_OPTL_4BIT;
+			break;
+
+		case 8:
+			ifr |= QSPI_IFR_OPTL_8BIT;
+			break;
+
+		default:
+			return -EINVAL;
+		}
+	}
+
+	/* Set number of dummy cycles */
+	if (cmd->enable.bits.dummy)
+		ifr |= QSPI_IFR_NBDUM(cmd->num_dummy_cycles);
+
+	/* Set data enable */
+	if (cmd->enable.bits.data) {
+		ifr |= QSPI_IFR_DATAEN;
+
+		/* Special case for Continuous Read Mode */
+		if (!cmd->tx_buf && !cmd->rx_buf)
+			ifr |= QSPI_IFR_CRM;
+	}
+
+	/* Set QSPI Instruction Frame registers */
+	atmel_qspi_debug_command(aq, cmd);
+	qspi_writel(aq, QSPI_IAR, iar);
+	qspi_writel(aq, QSPI_ICR, icr);
+	qspi_writel(aq, QSPI_IFR, ifr);
+
+	/* Skip to the final steps if there is no data */
+	if (!cmd->enable.bits.data)
+		goto no_data;
+
+	/* Dummy read of QSPI_IFR to synchronize APB and AHB accesses */
+	(void)qspi_readl(aq, QSPI_IFR);
+
+	/* Stop here for continuous read */
+	if (!cmd->tx_buf && !cmd->rx_buf)
+		return 0;
+	/* Send/Receive data */
+	err = atmel_qspi_run_transfer(aq, cmd);
+
+	/* Release the chip-select */
+	qspi_writel(aq, QSPI_CR, QSPI_CR_LASTXFER);
+
+	if (err)
+		return err;
+
+#if defined(DEBUG) && defined(VERBOSE_DEBUG)
+	/*
+	 * If verbose debug is enabled, also dump the RX data in addition to
+	 * the SPI command previously dumped by atmel_qspi_debug_command()
+	 */
+	if (cmd->rx_buf)
+		print_hex_dump(KERN_DEBUG, "qspi rx : ", DUMP_PREFIX_NONE,
+			       32, 1, cmd->rx_buf, cmd->buf_len, false);
+#endif
+no_data:
+	/* Poll INSTRuction End status */
+	sr = qspi_readl(aq, QSPI_SR);
+	if (sr & QSPI_SR_INSTRE)
+		return err;
+
+	/* Wait for INSTRuction End interrupt */
+	reinit_completion(&aq->cmd_completion);
+	aq->pending = 0;
+	qspi_writel(aq, QSPI_IER, QSPI_SR_INSTRE);
+	if (!wait_for_completion_timeout(&aq->cmd_completion,
+					 msecs_to_jiffies(1000)))
+		err = -ETIMEDOUT;
+	qspi_writel(aq, QSPI_IDR, QSPI_SR_INSTRE);
+
+	return err;
+}
+
+static int atmel_qspi_command_set_ifr(struct atmel_qspi_command *cmd,
+				      u32 ifr_tfrtyp,
+				      enum spi_nor_protocol proto)
+{
+	cmd->ifr = ifr_tfrtyp;
+
+	switch (proto) {
+	case SNOR_PROTO_1_1_1:
+		cmd->ifr |= QSPI_IFR_WIDTH_SINGLE_BIT_SPI;
+		break;
+	case SNOR_PROTO_1_1_2:
+		cmd->ifr |= QSPI_IFR_WIDTH_DUAL_OUTPUT;
+		break;
+	case SNOR_PROTO_1_1_4:
+		cmd->ifr |= QSPI_IFR_WIDTH_QUAD_OUTPUT;
+		break;
+	case SNOR_PROTO_1_2_2:
+		cmd->ifr |= QSPI_IFR_WIDTH_DUAL_IO;
+		break;
+	case SNOR_PROTO_1_4_4:
+		cmd->ifr |= QSPI_IFR_WIDTH_QUAD_IO;
+		break;
+	case SNOR_PROTO_2_2_2:
+		cmd->ifr |= QSPI_IFR_WIDTH_DUAL_CMD;
+		break;
+	case SNOR_PROTO_4_4_4:
+		cmd->ifr |= QSPI_IFR_WIDTH_QUAD_CMD;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int atmel_qspi_read_reg(struct spi_nor *nor, u8 opcode,
+			       u8 *buf, int len)
+{
+	struct atmel_qspi *aq = nor->priv;
+	struct atmel_qspi_command cmd;
+	int ret;
+
+	memset(&cmd, 0, sizeof(cmd));
+	cmd.enable.bits.instruction = 1;
+	cmd.enable.bits.data = 1;
+	cmd.instruction = opcode;
+	cmd.rx_buf = buf;
+	cmd.buf_len = len;
+
+	ret = atmel_qspi_command_set_ifr(&cmd,
+					 QSPI_IFR_TFRTYP_TRSFR_READ,
+					 nor->reg_proto);
+	if (ret)
+		return ret;
+
+	return atmel_qspi_run_command(aq, &cmd);
+}
+
+static int atmel_qspi_write_reg(struct spi_nor *nor, u8 opcode,
+				u8 *buf, int len)
+{
+	struct atmel_qspi *aq = nor->priv;
+	struct atmel_qspi_command cmd;
+	int ret;
+
+	memset(&cmd, 0, sizeof(cmd));
+	cmd.enable.bits.instruction = 1;
+	cmd.enable.bits.data = (buf != NULL && len > 0);
+	cmd.instruction = opcode;
+	cmd.tx_buf = buf;
+	cmd.buf_len = len;
+
+	ret = atmel_qspi_command_set_ifr(&cmd,
+					 QSPI_IFR_TFRTYP_TRSFR_WRITE,
+					 nor->reg_proto);
+	if (ret)
+		return ret;
+
+	return atmel_qspi_run_command(aq, &cmd);
+}
+
+static void atmel_qspi_write(struct spi_nor *nor, loff_t to, size_t len,
+			     size_t *retlen, const u_char *write_buf)
+{
+	struct atmel_qspi *aq = nor->priv;
+	struct atmel_qspi_command cmd;
+
+	memset(&cmd, 0, sizeof(cmd));
+	cmd.enable.bits.instruction = 1;
+	cmd.enable.bits.address = nor->addr_width;
+	cmd.enable.bits.data = 1;
+	cmd.enable.bits.dma = 1;
+	cmd.instruction = nor->program_opcode;
+	cmd.address = (u32)to;
+	cmd.tx_buf = write_buf;
+	cmd.buf_len = len;
+
+	if (atmel_qspi_command_set_ifr(&cmd,
+				       QSPI_IFR_TFRTYP_TRSFR_WRITE_MEM,
+				       nor->write_proto))
+		return;
+
+	if (!atmel_qspi_run_command(aq, &cmd))
+		*retlen += len;
+}
+
+static int atmel_qspi_erase(struct spi_nor *nor, loff_t offs)
+{
+	struct atmel_qspi *aq = nor->priv;
+	struct atmel_qspi_command cmd;
+	int ret;
+
+	dev_dbg(nor->dev, "%dKiB at 0x%08x\n",
+		nor->mtd.erasesize / 1024, (u32)offs);
+
+	memset(&cmd, 0, sizeof(cmd));
+	cmd.enable.bits.instruction = 1;
+	cmd.enable.bits.address = nor->addr_width;
+	cmd.instruction = nor->erase_opcode;
+	cmd.address = (u32)offs;
+
+	ret = atmel_qspi_command_set_ifr(&cmd,
+					 QSPI_IFR_TFRTYP_TRSFR_WRITE,
+					 nor->erase_proto);
+	if (ret)
+		return ret;
+
+	return atmel_qspi_run_command(aq, &cmd);
+}
+
+static int atmel_qspi_read(struct spi_nor *nor, loff_t from, size_t len,
+			   size_t *retlen, u_char *read_buf)
+{
+	struct atmel_qspi *aq = nor->priv;
+	struct atmel_qspi_command cmd;
+	int ret;
+
+	memset(&cmd, 0, sizeof(cmd));
+	cmd.enable.bits.instruction = 1;
+	cmd.enable.bits.address = nor->addr_width;
+	cmd.enable.bits.dummy = (nor->read_dummy > 0);
+	cmd.enable.bits.data = 1;
+	cmd.enable.bits.dma = 1;
+	cmd.instruction = nor->read_opcode;
+	cmd.address = (u32)from;
+	cmd.num_dummy_cycles = nor->read_dummy;
+	cmd.rx_buf = read_buf;
+	cmd.buf_len = len;
+
+	ret = atmel_qspi_command_set_ifr(&cmd,
+					 QSPI_IFR_TFRTYP_TRSFR_READ_MEM,
+					 nor->read_proto);
+	if (ret)
+		return ret;
+
+	ret = atmel_qspi_run_command(aq, &cmd);
+	if (ret)
+		return ret;
+
+	*retlen += len;
+	return 0;
+}
+
+static int atmel_qspi_init(struct atmel_qspi *aq)
+{
+	unsigned long src_rate;
+	u32 mr, scr, scbr;
+
+	/* Reset the QSPI controller */
+	qspi_writel(aq, QSPI_CR, QSPI_CR_SWRST);
+
+	/* Set the QSPI controller in Serial Memory Mode */
+	mr = QSPI_MR_NBBITS(8) | QSPI_MR_SSM;
+	qspi_writel(aq, QSPI_MR, mr);
+
+	src_rate = clk_get_rate(aq->clk);
+	if (!src_rate)
+		return -EINVAL;
+
+	/* Compute the QSPI baudrate */
+	scbr = DIV_ROUND_UP(src_rate, aq->clk_rate);
+	if (scbr > 0)
+		scbr--;
+	scr = QSPI_SCR_SCBR(scbr);
+	qspi_writel(aq, QSPI_SCR, scr);
+
+	/* Enable the QSPI controller */
+	qspi_writel(aq, QSPI_CR, QSPI_CR_QSPIEN);
+
+	return 0;
+}
+
+static irqreturn_t atmel_qspi_interrupt(int irq, void *dev_id)
+{
+	struct atmel_qspi *aq = (struct atmel_qspi *)dev_id;
+	u32 status, mask, pending;
+
+	status = qspi_readl(aq, QSPI_SR);
+	mask = qspi_readl(aq, QSPI_IMR);
+	pending = status & mask;
+
+	if (!pending)
+		return IRQ_NONE;
+
+	aq->pending |= pending;
+	if (pending & QSPI_SR_INSTRE)
+		complete(&aq->cmd_completion);
+
+	return IRQ_HANDLED;
+}
+
+static int atmel_qspi_probe(struct platform_device *pdev)
+{
+	struct device_node *child, *np = pdev->dev.of_node;
+	struct atmel_qspi *aq;
+	struct resource *res;
+	dma_cap_mask_t mask;
+	struct spi_nor *nor;
+	struct mtd_info *mtd;
+	int irq, err = 0;
+
+	if (of_get_child_count(np) != 1)
+		return -ENODEV;
+	child = of_get_next_child(np, NULL);
+
+	aq = devm_kzalloc(&pdev->dev, sizeof(*aq), GFP_KERNEL);
+	if (!aq) {
+		err = -ENOMEM;
+		goto exit;
+	}
+
+	platform_set_drvdata(pdev, aq);
+	init_completion(&aq->cmd_completion);
+	init_completion(&aq->dma_completion);
+	aq->pdev = pdev;
+
+	/* Map the registers */
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "qspi_base");
+	aq->regs = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(aq->regs)) {
+		dev_err(&pdev->dev, "missing registers\n");
+		err = PTR_ERR(aq->regs);
+		goto exit;
+	}
+
+	/* Map the AHB memory */
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "qspi_mmap");
+	aq->mem = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(aq->mem)) {
+		dev_err(&pdev->dev, "missing AHB memory\n");
+		err = PTR_ERR(aq->mem);
+		goto exit;
+	}
+	aq->phys_addr = (dma_addr_t)res->start;
+
+	/* Get the peripheral clock */
+	aq->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(aq->clk)) {
+		dev_err(&pdev->dev, "missing peripheral clock\n");
+		err = PTR_ERR(aq->clk);
+		goto exit;
+	}
+
+	/* Enable the peripheral clock */
+	err = clk_prepare_enable(aq->clk);
+	if (err) {
+		dev_err(&pdev->dev, "failed to enable the peripheral clock\n");
+		goto exit;
+	}
+
+	/* Request the IRQ */
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "missing IRQ\n");
+		err = irq;
+		goto disable_clk;
+	}
+	err = devm_request_irq(&pdev->dev, irq, atmel_qspi_interrupt,
+			       0, dev_name(&pdev->dev), aq);
+	if (err)
+		goto disable_clk;
+
+	/* Try to get a DMA channel for memcpy() operation */
+	dma_cap_zero(mask);
+	dma_cap_set(DMA_MEMCPY, mask);
+	aq->chan = dma_request_channel(mask, NULL, NULL);
+	if (!aq->chan)
+		dev_warn(&pdev->dev, "no available DMA channel\n");
+
+	/* Setup the spi-nor */
+	nor = &aq->nor;
+	mtd = &nor->mtd;
+
+	nor->dev = &pdev->dev;
+	spi_nor_set_flash_node(nor, child);
+	nor->priv = aq;
+	mtd->priv = nor;
+
+	nor->read_reg = atmel_qspi_read_reg;
+	nor->write_reg = atmel_qspi_write_reg;
+	nor->read = atmel_qspi_read;
+	nor->write = atmel_qspi_write;
+	nor->erase = atmel_qspi_erase;
+
+	err = of_property_read_u32(child, "spi-max-frequency", &aq->clk_rate);
+	if (err < 0)
+		goto release_channel;
+
+	err = atmel_qspi_init(aq);
+	if (err)
+		goto release_channel;
+
+	err = spi_nor_scan(nor, NULL, SPI_NOR_QUAD);
+	if (err)
+		goto release_channel;
+
+	err = mtd_device_register(mtd, NULL, 0);
+	if (err)
+		goto release_channel;
+
+	of_node_put(child);
+
+	return 0;
+
+release_channel:
+	if (aq->chan)
+		dma_release_channel(aq->chan);
+disable_clk:
+	clk_disable_unprepare(aq->clk);
+exit:
+	of_node_put(child);
+
+	return err;
+}
+
+static int atmel_qspi_remove(struct platform_device *pdev)
+{
+	struct atmel_qspi *aq = platform_get_drvdata(pdev);
+
+	mtd_device_unregister(&aq->nor.mtd);
+	qspi_writel(aq, QSPI_CR, QSPI_CR_QSPIDIS);
+	if (aq->chan)
+		dma_release_channel(aq->chan);
+	clk_disable_unprepare(aq->clk);
+	return 0;
+}
+
+
+static const struct of_device_id atmel_qspi_dt_ids[] = {
+	{ .compatible = "atmel,sama5d2-qspi" },
+	{ /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, atmel_qspi_dt_ids);
+
+static struct platform_driver atmel_qspi_driver = {
+	.driver = {
+		.name	= "atmel_qspi",
+		.of_match_table	= atmel_qspi_dt_ids,
+	},
+	.probe		= atmel_qspi_probe,
+	.remove		= atmel_qspi_remove,
+};
+module_platform_driver(atmel_qspi_driver);
+
+MODULE_AUTHOR("Cyrille Pitchen <cyrille.pitchen at atmel.com>");
+MODULE_DESCRIPTION("Atmel QSPI Controller driver");
+MODULE_LICENSE("GPL v2");
-- 
1.8.2.2



From ard.biesheuvel at linaro.org  Wed Feb  3 05:41:29 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 3 Feb 2016 14:41:29 +0100
Subject: [PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM
In-Reply-To: <HKXPR06MB05656F902E0E1FBBDBD713DC8AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <HKXPR06MB0565A2CFF95AD7C000F43E6A8ADF0@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu9VvskQ34w0niS+6AtF9hNcycfYDt_3Kp4T+WK8Vxf_dA@mail.gmail.com>
 <HKXPR06MB05656F902E0E1FBBDBD713DC8AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>
Message-ID: <CAKv+Gu8ZTHAqviveLMizRKPfeXwb6kcXi4cVQNYVYuPcVMgMeQ@mail.gmail.com>

On 3 February 2016 at 14:33, Chris Brandt <Chris.Brandt at renesas.com> wrote:
> On 2 Feb 2016, Chris Brandt wrote:
>> I then applied the 3 patches and tried again and this time it booted
>> up....almost.
>> It looks like it makes it all the way up to when it is going to mount
>> my rootfs, but then dies.
>
>
> I did some debugging, and here's why I'm crashing.
>
>
> If you look at my System.map file, you'll see that I've got 2 "__stubs_start" symbols.
>
> One at 0x bf353edc, the other at 0x bf353ee0.
>
> bf353edc T __stubs_start

This is a global symbol

> bf353edc T _etext
> bf353ee0 t __stubs_start

This is a local symbol

> bf353ee4 t vector_rst
> bf353f00 t vector_irq
> bf353f80 t vector_dabt
> bf354000 t vector_pabt
> bf354080 t vector_und
> bf354100 t vector_addrexcptn
> bf354120 T vector_fiq
> bf3541a0 T __stubs_end
> bf3541a0 T __vectors_start
> bf3541c0 t __mmap_switched
> bf3541c0 T __vectors_end
>
>
> So, when you get to early_trap_init(), it grabs the first __stubs_start for the memcpy:
>
>         memcpy((void *)vectors + 0x1000, __stubs_start, __stubs_end - __stubs_start);
>

Indeed. It grabs the first one, which is the one defined by the linker script.

>
> And when a printed out the destination, I get:
>
>    Stubs at c09ff000 :00000000 BF006F20 EF9F0000 EA000064 etc...
>
> Notice the first entry is 0....that's not right...and we know it's using that first __stubs_start symbol.
>

The first quantity after __stubs_start should be the address of
vector_swi. Can you check if the second value coincides with that?

>
> So, I hacked the code and put an offset of 4 like this:
>
>         memcpy((void *)vectors + 0x1000, __stubs_start+4, __stubs_end - (__stubs_start+4));
>
>
> And sure enough it booted fine.
>
>
> So, why are there 2 __stubs_start symbols???
> I haven't figured that one out yet.
>

One defined by entry-armv.S and one defined by the linker script

> And, I'm assuming you guys don't have 2 __stubs_start symbols either, correct?
>

Yes, we do.

This is caused by the fact that __stubs_start is not aligned correctly on XIP.

Could you try this, please?

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 7160658fd5d4..a5b8e7b80d17 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -164,8 +164,8 @@ SECTIONS
         * The vectors and stubs are relocatable code, and the
         * only thing that matters is their relative offsets
         */
-       __stubs_start = .;
        .stubs : {
+               __stubs_start = .;
                *(.stubs)
        }
        __stubs_end = .;


From friesendrywall at gmail.com  Wed Feb  3 05:42:46 2016
From: friesendrywall at gmail.com (Erik Friesen)
Date: Wed, 3 Feb 2016 08:42:46 -0500
Subject: SGTL5000 misc
Message-ID: <CAEuupiuhPR48Upo=8f0zV8cxf0Vefgx3qA+vC+QDWAOV4n-e3Q@mail.gmail.com>

First post on the list here..

I have been working with an embeddedarm ts4900 and built a baseboard
that uses the sgtl5000.  I also have worked with the RiotBoard, which
uses the same chip, both using the i.mx6 arm.  I find that
occasionally the sgtl5000 is resetting, and there is no way to bring
it back online.  As near as I can tell, the i2c bus comes back alive,
for example alsamixer communicates fine, coms happen on the i2c bus
per scope.  However, its obvious the chip never got re initialized by
how it acts.

I know the thing shouldn't reset, that is the primary problem, but I
still want some backup method.  Its probably due to ground bounce from
a non earth grounded setup.  It could be that using the external
regulator will help, we will see.

Is there a suggestion on a way the sgtl5000.c could be extended to
support some sort of re init routine?

I am using the embeddedarm repo as a base.


From mark.rutland at arm.com  Wed Feb  3 05:43:32 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 3 Feb 2016 13:43:32 +0000
Subject: [PATCH] arm64: Allow vmalloc regions to be set with set_memory_*
In-Reply-To: <56AC2462.20506@huawei.com>
References: <CAKv+Gu_A1C9hXgqrYDekoy1YHaRXi_mUF-kYx-TqsOBkWMVjmQ@mail.gmail.com>
 <CAKv+Gu-73QKAsFQCa=yO5+=DihLXp_AKYyY6QRTVM4nuDH=-8g@mail.gmail.com>
 <20160118115640.GK21067@leverpostej> <56A97328.9070003@huawei.com>
 <20160128105138.GE17123@leverpostej> <56A9FFBD.8030303@huawei.com>
 <20160128142746.GL17123@leverpostej> <56AABEA4.3010301@huawei.com>
 <20160129110252.GB17038@leverpostej> <56AC2462.20506@huawei.com>
Message-ID: <20160203134332.GB1234@leverpostej>

On Sat, Jan 30, 2016 at 10:48:02AM +0800, Xishi Qiu wrote:
 Hi Mark,
> 
> Thanks for your reply. Maybe I didn't express it clearly, sorry for it.
> 
> The abstract process is the following:
> 1. do not create a large block, use 4kb for all of the memory(regardless of performance).
> setup_arch->paging_init()->map_mem()->__map_memblock()->create_mapping()
> 2. alloc a page and get the the linear mapping address.
> 3. modify judgment condition of the function set_memory_ro(), so it could handle the linear mapping range.
> 4. use set_memory_ro() to change the prot flag of the page which we get in step 2.
> 
> Is it safe?

This will be free from the problems associated with splitting/fusing
sections.

My concern was with what exactly this "special memory" was and how it
was being used. It sounds like either some infrstructure is missing, or
you are using the wrong abstractions.

Thanks,
Mark.


From catalin.marinas at arm.com  Wed Feb  3 06:06:33 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 3 Feb 2016 14:06:33 +0000
Subject: [PATCH 4/4] arm64: Rename cpuid_feature field extract routines
In-Reply-To: <1453805896-4397-5-git-send-email-suzuki.poulose@arm.com>
References: <1453805896-4397-1-git-send-email-suzuki.poulose@arm.com>
 <1453805896-4397-5-git-send-email-suzuki.poulose@arm.com>
Message-ID: <20160203140632.GB16727@e104818-lin.cambridge.arm.com>

On Tue, Jan 26, 2016 at 10:58:16AM +0000, Suzuki K. Poulose wrote:
> Now that we have a clear understanding of the sign of a feature,
> rename the routines to reflect the sign, so that it is not misused.
> The cpuid_feature_extract_field() now accepts a 'sign' parameter.
> 
> Signed-off-by: Suzuki K. Poulose <suzuki.poulose at arm.com>
[...]
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 7364339..2ac4a22 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -307,7 +307,7 @@ static inline unsigned int kvm_get_vmid_bits(void)
>  {
>  	int reg = read_system_reg(SYS_ID_AA64MMFR1_EL1);
>  
> -	return (cpuid_feature_extract_field(reg, ID_AA64MMFR1_VMIDBITS_SHIFT) == 2) ? 16 : 8;
> +	return (cpuid_feature_extract_unsigned_field(reg, ID_AA64MMFR1_VMIDBITS_SHIFT) == 2) ? 16 : 8;
>  }

Since this is touch a KVM file, it would be good to have an ack from
Marc or Christoffer.

Thanks.

-- 
Catalin


From shawnguo at kernel.org  Wed Feb  3 06:13:12 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 3 Feb 2016 22:13:12 +0800
Subject: [PATCH 1/4] ARM: dts: ls1021a: add PCIe dts node
In-Reply-To: <1454401807-28751-1-git-send-email-Minghuan.Lian@nxp.com>
References: <1454401807-28751-1-git-send-email-Minghuan.Lian@nxp.com>
Message-ID: <20160203141312.GO8307@tiger>

On Tue, Feb 02, 2016 at 04:30:07PM +0800, Minghuan Lian wrote:
> LS1021a contains two PCIe controllers. The patch adds their node to
> dts file.
> 
> Signed-off-by: Minghuan Lian <Minghuan.Lian at nxp.com>

Applied, thanks.


From grygorii.strashko at ti.com  Wed Feb  3 06:14:06 2016
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Wed, 3 Feb 2016 16:14:06 +0200
Subject: [PATCH 1/2] ARM: make virt_to_idmap() return unsigned long
In-Reply-To: <56B14546.4070808@oracle.com>
References: <E1aO8F2-00074N-E8@rmk-PC.arm.linux.org.uk>
 <56A84748.3040108@oracle.com> <20160201152015.GU10826@n2100.arm.linux.org.uk>
 <56AF8F54.7030805@ti.com> <56AF917F.9030505@oracle.com>
 <56B14546.4070808@oracle.com>
Message-ID: <56B20B2E.7060408@ti.com>

On 02/03/2016 02:09 AM, santosh shilimkar wrote:
> Vitaly,
> 
> On 2/1/2016 9:10 AM, santosh shilimkar wrote:
>> On 2/1/2016 9:01 AM, Vitaly Andrianov wrote:
>>>
>>>
>>> On 02/01/2016 10:20 AM, Russell King - ARM Linux wrote:
>>>> On Tue, Jan 26, 2016 at 08:27:52PM -0800, santosh.shilimkar at oracle.com
>>>> wrote:
>>>>> On 1/26/16 10:21 AM, Russell King wrote:
>>>>>> Make virt_to_idmap() return an unsigned long rather than phys_addr_t.
>>>>>>
>>>>>> Returning phys_addr_t here makes no sense, because the definition of
>>>>>> virt_to_idmap() is that it shall return a physical address which maps
>>>>>> identically with the virtual address.  Since virtual addresses are
>>>>>> limited to 32-bit, identity mapped physical addresses are as well.
>>>>>>
>>>>>> Almost all users already had an implicit narrowing cast to unsigned
>>>>>> long
>>>>>> so let's make this official and part of this interface.
>>>>>>
>>>>>> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
>>>>>> ---
>>>>> Looks correct to me.
>>>>>
>>>>> Vitaly,
>>>>> Could you please try out this patch and see everything continue to
>>>>> work ?
>>>>
>>>> I haven't heard anything yet...  Vitaly?
>>>>
>>> Russel, Santosh,
>>>
>>> I'm not working with the latest kernel, but with the stable v4.1.y. So I
>>> couldn't apply the patch to it. I checked out 4.5.0-rc1 and applied the
>>> patch to it. Tried to boot and it crashed. I'm not sure either because
>>> of the patch or because of the network driver.
>>>
>> Thanks for checking.
>>
>>> Here is the log:
>>>
>> Based on the log, I think the patch seems to work fine since the boot
>> reached upto rootfs. The crash seems to be coming from mostky NetCP
>> related compents.
>>
> The NETCP crash you saw could be the same one others stumbled as
> mentioned in below thread. You can try the fix and see if the
> crash goes away.
> 
> http://marc.info/?l=linux-netdev&m=145445399232540&w=2

100%. I came up with absolutely similar fix.


Regarding, kexec:
- it seems can't be tested on ks2 out of the box, because there is unmet dependency in kconfig
 config KEXEC
        bool "Kexec system call (EXPERIMENTAL)"
-       depends on (!SMP || PM_SLEEP_SMP)
        depends on !CPU_V7M
        select KEXEC_CORE
        help

- any way, i've hacked kernel as above;
- downloaded and built kexec-tools
git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.git
- tried to run it using different combination of parameters, but always
with below result:
# kexec -l /boot/zImage 
kexec version: 15.12.22.16.38-g6503cb3
Could not find a free area of memory of 0x3b2ca0 bytes...
Cannot load /boot/zImage

I'm doing something wrong, but don't know what yet :(
- these patches were not applied, I'd like to see kexec not working first


-- 
regards,
-grygorii


From thierry.reding at gmail.com  Wed Feb  3 06:14:54 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Wed, 3 Feb 2016 15:14:54 +0100
Subject: [PATCH 4/4] pwm: omap-dmtimer: add dev_dbg() message for
 effective period and duty cycle
In-Reply-To: <20160202184443.1e1b0bf5.drivshin.allworx@gmail.com>
References: <1454128014-22866-1-git-send-email-drivshin.allworx@gmail.com>
 <1454128014-22866-5-git-send-email-drivshin.allworx@gmail.com>
 <CAA3gFWvSsctXtds6_SEtYY1yUdWJDR1XjznGS6qjdrGW5Dbw=A@mail.gmail.com>
 <20160201132228.2634b72e.drivshin.allworx@gmail.com>
 <20160201185952.GN19432@atomide.com> <20160202162330.GA4918@ulmo>
 <20160202184443.1e1b0bf5.drivshin.allworx@gmail.com>
Message-ID: <20160203141454.GC9650@ulmo>

On Tue, Feb 02, 2016 at 06:44:43PM -0500, David Rivshin (Allworx) wrote:
> On Tue, 2 Feb 2016 17:23:30 +0100
> Thierry Reding <thierry.reding at gmail.com> wrote:
> 
> > On Mon, Feb 01, 2016 at 10:59:52AM -0800, Tony Lindgren wrote:
> > > Hi,
> > > 
> > > * David Rivshin (Allworx) <drivshin.allworx at gmail.com> [160201
> > > 10:23]:  
> > > > On Sat, 30 Jan 2016 15:51:06 +0100
> > > > Neil Armstrong <narmstrong at baylibre.com> wrote:
> > > >   
> > > > > 2016-01-30 5:26 GMT+01:00 David Rivshin (Allworx)
> > > > > <drivshin.allworx at gmail.com>:  
> > > > > > From: David Rivshin <drivshin at allworx.com>
> > > > > >
> > > > > > After going through the math and constraints checking to
> > > > > > compute load and match values, it is helpful to know what the
> > > > > > resultant period and duty cycle are.
> > > > > >
> > > > > > Signed-off-by: David Rivshin <drivshin at allworx.com>
> > > > > > ---
> > > > > >
> > > > > > I found this helpful while testing the other changes, so I
> > > > > > included it in case it may be of use to someone in the
> > > > > > future. I would have no issues with dropping this if it's not
> > > > > > considered worthwhile.    
> > > > > 
> > > > > It's useful, but converting it as a sysfs attribute would be
> > > > > great !  
> > > > 
> > > > Hrm, yes that is an interesting thought. I imagine that many PWM 
> > > > devices have similar constraints, so perhaps that would be best 
> > > > handled generically in the pwm core? Maybe as new optional
> > > > get_*() ops, a modification to the config() op to add output
> > > > params, or just updating new fields in the struct pwm directly?  
> > > 
> > > Yeah for /sys entry it should be Linux generic. The other option
> > > is to use debugfs for driver specific things.  
> > 
> > Let's go with debugfs for this one. This is used for diagnostic
> 
> I had looked at using the dbg_show() op to add some additional data. 
> One thing that discouraged me from going down that path was that 
> it replaced the call to pwm_dbg_show() for that chip. I wouldn't 
> want to loose the existing output, as it is useful, but also didn't
> like the thought of duplicating the logic/formatting. I think some 
> way to have both the standard output and add extra output somewhere
> (e.g. same line, line after each pwm_device, block after all 
> pwm_devices on the chip) would make that path more attractive.
> 
> Or were you thinking of a separate (per-chip) debugfs file for this 
> type of information? 

Yes, generally I'd prefer a separate, chip-specific debugfs file for
extra information. To be honest I'm not entirely sure of the usefulness
of the pwm_dbg_show() or letting drivers override it. But that's
slightly off-topic. However...

> > purposes and not typically needed when configuring a PWM. While other
> > drivers may compute similar hardware-specific values, there's nothing
> > generic to them. The period and duty cycle are the generic input
> > values and those are already exposed via sysfs.
> 
> Just to clarify, what I was thinking of as generic was the concept
> that "period/duty I asked for" and "period/duty I got" may be
> different, sometimes to a substantial degree. I could imagine 
> userspace wanting to know the latter, which is what I think Neil 
> was suggesting.
> 
> For the sake of an example, the input clock for a dmtimer is sometimes
> (often?) 32768Hz, which means that the real period and duty_cycle output
> are limited to being a multiple of ~61035.2ns (16384Hz). So an attempt 
> to set a period of 100000ns (10KHz) would result in either 61035.2ns, or 
> 122070.4ns (8192Hz), depending on the implementation of the driver (and 
> patch 2 changes behavior from the former to the latter). You can also 
> have cases where you desired a 33% duty cycle, but got a 25% duty cycle 
> instead.
> 
> In a quick look, I see substantially similar calculations (i.e. 
> clk_rate*period_ns/10^9) in most of the other pwm drivers, which makes 
> sense for any that are programmed in terms of some input clock. This 
> type of calculation almost guarantees that requested and actual period/
> duty_cycle are going to be different to some degree. Some drivers look 
> like they have even more complicated behavior, apparently due to other 
> hardware constraints. For instance, fsl-ftm (among others) looks to be 
> using a power-of-2 prescaler to fit the period_cycles into a 16bit field.
> 
> Of course if the input clock rate for these types of devices is 
> sufficiently high (enough that the desired period is many input clock 
> cycles), then the difference between "desired" and "actual" is probably 
> small enough that noone cares. I'm not sure how common it is that
>   a) there is a substantial difference, and
>   b) userspace cares about it, and
>   c) userspace didn't carefully select an achievable value already
> If noone has brought it up before, then I'd guess the answer is "not very".

... I think perhaps a better way yet would be to have drivers update the
period and duty cycle to the actual values. That way there won't be a
delta between what's really being programmed to hardware and what shows
up in sysfs. It would also give users a chance to check if what's been
programmed is within an acceptable range or not.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/874a22d4/attachment-0001.sig>

From Chris.Brandt at renesas.com  Wed Feb  3 06:15:16 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Wed, 3 Feb 2016 14:15:16 +0000
Subject: [PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM
In-Reply-To: <CAKv+Gu8ZTHAqviveLMizRKPfeXwb6kcXi4cVQNYVYuPcVMgMeQ@mail.gmail.com>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <HKXPR06MB0565A2CFF95AD7C000F43E6A8ADF0@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu9VvskQ34w0niS+6AtF9hNcycfYDt_3Kp4T+WK8Vxf_dA@mail.gmail.com>
 <HKXPR06MB05656F902E0E1FBBDBD713DC8AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu8ZTHAqviveLMizRKPfeXwb6kcXi4cVQNYVYuPcVMgMeQ@mail.gmail.com>
Message-ID: <HKXPR06MB056516B5DC41AB61AA39D8B28AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>

On 2 Feb 2016, Chris Brandt wrote 
> > And when a printed out the destination, I get:
> >
> >    Stubs at c09ff000 :00000000 BF006F20 EF9F0000 EA000064 etc...
> >
> > Notice the first entry is 0....that's not right...and we know it's using that
> > first __stubs_start symbol.
> >
>
> The first quantity after __stubs_start should be the address of vector_swi. Can
>  you check if the second value coincides with that?

Yes, it does.

bf006f20 T vector_swi

Which is why it booted once I modified the start address.


> This is caused by the fact that __stubs_start is not aligned correctly on XIP.
>
> Could you try this, please?
>
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S index 7160658fd5d4..a5b8e7b80d17 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -164,8 +164,8 @@ SECTIONS
>          * The vectors and stubs are relocatable code, and the
>          * only thing that matters is their relative offsets
>          */
> -       __stubs_start = .;
>         .stubs : {
> +               __stubs_start = .;
>                 *(.stubs)
>         }
>         __stubs_end = .;


Yup, that fixed it!

bf353edc T _etext
bf353ee0 t __stubs_start
bf353ee0 T __stubs_start
bf353ee4 t vector_rst
bf353f00 t vector_irq

and my new print out:

     Stubs at c09ff000 :BF006F20 EF9F0000 EA000064 E320F000 etc...


Now that it is working on my XIP system, I will say that I'm also happy to see that extra junk in kallsyms.c and link-vmlinux.sh be removed. Those things also caused me some issues when I first started trying to get the XIP_KERNEL stuff back working.



Chris

From marc.zyngier at arm.com  Wed Feb  3 06:16:18 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 3 Feb 2016 14:16:18 +0000
Subject: [PATCH 4/4] arm64: Rename cpuid_feature field extract routines
In-Reply-To: <20160203140632.GB16727@e104818-lin.cambridge.arm.com>
References: <1453805896-4397-1-git-send-email-suzuki.poulose@arm.com>
 <1453805896-4397-5-git-send-email-suzuki.poulose@arm.com>
 <20160203140632.GB16727@e104818-lin.cambridge.arm.com>
Message-ID: <56B20BB2.4020700@arm.com>

On 03/02/16 14:06, Catalin Marinas wrote:
> On Tue, Jan 26, 2016 at 10:58:16AM +0000, Suzuki K. Poulose wrote:
>> Now that we have a clear understanding of the sign of a feature,
>> rename the routines to reflect the sign, so that it is not misused.
>> The cpuid_feature_extract_field() now accepts a 'sign' parameter.
>>
>> Signed-off-by: Suzuki K. Poulose <suzuki.poulose at arm.com>
> [...]
>> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
>> index 7364339..2ac4a22 100644
>> --- a/arch/arm64/include/asm/kvm_mmu.h
>> +++ b/arch/arm64/include/asm/kvm_mmu.h
>> @@ -307,7 +307,7 @@ static inline unsigned int kvm_get_vmid_bits(void)
>>  {
>>  	int reg = read_system_reg(SYS_ID_AA64MMFR1_EL1);
>>  
>> -	return (cpuid_feature_extract_field(reg, ID_AA64MMFR1_VMIDBITS_SHIFT) == 2) ? 16 : 8;
>> +	return (cpuid_feature_extract_unsigned_field(reg, ID_AA64MMFR1_VMIDBITS_SHIFT) == 2) ? 16 : 8;
>>  }
> 
> Since this is touch a KVM file, it would be good to have an ack from
> Marc or Christoffer.

Works for me.

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

	M.
-- 
Jazz is not dead. It just smells funny...


From ard.biesheuvel at linaro.org  Wed Feb  3 06:17:19 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 3 Feb 2016 15:17:19 +0100
Subject: [PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM
In-Reply-To: <HKXPR06MB056516B5DC41AB61AA39D8B28AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <HKXPR06MB0565A2CFF95AD7C000F43E6A8ADF0@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu9VvskQ34w0niS+6AtF9hNcycfYDt_3Kp4T+WK8Vxf_dA@mail.gmail.com>
 <HKXPR06MB05656F902E0E1FBBDBD713DC8AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu8ZTHAqviveLMizRKPfeXwb6kcXi4cVQNYVYuPcVMgMeQ@mail.gmail.com>
 <HKXPR06MB056516B5DC41AB61AA39D8B28AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>
Message-ID: <CAKv+Gu8DUkoFow_ZzQyTBe4_Nmeu7+CDYb=iAs0w3Fp_JMz+aA@mail.gmail.com>

On 3 February 2016 at 15:15, Chris Brandt <Chris.Brandt at renesas.com> wrote:
> On 2 Feb 2016, Chris Brandt wrote
>> > And when a printed out the destination, I get:
>> >
>> >    Stubs at c09ff000 :00000000 BF006F20 EF9F0000 EA000064 etc...
>> >
>> > Notice the first entry is 0....that's not right...and we know it's using that
>> > first __stubs_start symbol.
>> >
>>
>> The first quantity after __stubs_start should be the address of vector_swi. Can
>>  you check if the second value coincides with that?
>
> Yes, it does.
>
> bf006f20 T vector_swi
>
> Which is why it booted once I modified the start address.
>
>
>> This is caused by the fact that __stubs_start is not aligned correctly on XIP.
>>
>> Could you try this, please?
>>
>> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S index 7160658fd5d4..a5b8e7b80d17 100644
>> --- a/arch/arm/kernel/vmlinux.lds.S
>> +++ b/arch/arm/kernel/vmlinux.lds.S
>> @@ -164,8 +164,8 @@ SECTIONS
>>          * The vectors and stubs are relocatable code, and the
>>          * only thing that matters is their relative offsets
>>          */
>> -       __stubs_start = .;
>>         .stubs : {
>> +               __stubs_start = .;
>>                 *(.stubs)
>>         }
>>         __stubs_end = .;
>
>
> Yup, that fixed it!
>
> bf353edc T _etext
> bf353ee0 t __stubs_start
> bf353ee0 T __stubs_start
> bf353ee4 t vector_rst
> bf353f00 t vector_irq
>
> and my new print out:
>
>      Stubs at c09ff000 :BF006F20 EF9F0000 EA000064 E320F000 etc...
>
>
> Now that it is working on my XIP system, I will say that I'm also happy to see that extra junk in kallsyms.c and link-vmlinux.sh be removed. Those things also caused me some issues when I first started trying to get the XIP_KERNEL stuff back working.
>

Glad to hear that it works now. Thanks a lot for testing.

-- 
Ard.


From msalter at redhat.com  Wed Feb  3 06:22:47 2016
From: msalter at redhat.com (Mark Salter)
Date: Wed, 03 Feb 2016 09:22:47 -0500
Subject: [RFC PATCH 0/3] arm64 initrd mapping/relocation
In-Reply-To: <20160202180622.GP10166@arm.com>
References: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160202180622.GP10166@arm.com>
Message-ID: <1454509367.4108.3.camel@redhat.com>

On Tue, 2016-02-02 at 18:06 +0000, Will Deacon wrote:
> On Tue, Feb 02, 2016 at 06:56:39PM +0100, Ard Biesheuvel wrote:
> > After discussing in linux-efi with Mark, and on #armlinux with Will, this is
> > a proposal for dealing with initrd memory that is potentially not covered by
> > the linear region.
> > 
> > Note that this will look slightly differently when some of the KASLR work gets
> > merged, but this should only affect the way we deal with the initrd if it sits
> > outside of the linear region.
> > 
> > Mostly intended for discussion, not tested at all.
> 
> Thanks Ard, this looks like a much better approach to me. Mark -- does
> the general idea work for you too?
> 
> Will

Yeah, much simpler. I like it in concept but am I missing something or is it
adding memory to the system beyond the mem= limit? But even that may not be
a big deal. And I need to look at the KASLR work and understand the issues
with it and mem= if any. I'm traveling right now and can't really try it out
until tomorrow...



From festevam at gmail.com  Wed Feb  3 06:23:16 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 3 Feb 2016 12:23:16 -0200
Subject: SGTL5000 misc
In-Reply-To: <CAEuupiuhPR48Upo=8f0zV8cxf0Vefgx3qA+vC+QDWAOV4n-e3Q@mail.gmail.com>
References: <CAEuupiuhPR48Upo=8f0zV8cxf0Vefgx3qA+vC+QDWAOV4n-e3Q@mail.gmail.com>
Message-ID: <CAOMZO5BPNc1ncz6J8yhcBYywCVuTxKYMYhiNUt_Jq3LZsKdi+A@mail.gmail.com>

On Wed, Feb 3, 2016 at 11:42 AM, Erik Friesen <friesendrywall at gmail.com> wrote:
> First post on the list here..
>
> I have been working with an embeddedarm ts4900 and built a baseboard
> that uses the sgtl5000.  I also have worked with the RiotBoard, which
> uses the same chip, both using the i.mx6 arm.  I find that
> occasionally the sgtl5000 is resetting, and there is no way to bring
> it back online.  As near as I can tell, the i2c bus comes back alive,
> for example alsamixer communicates fine, coms happen on the i2c bus
> per scope.  However, its obvious the chip never got re initialized by
> how it acts.
>
> I know the thing shouldn't reset, that is the primary problem, but I
> still want some backup method.  Its probably due to ground bounce from
> a non earth grounded setup.  It could be that using the external
> regulator will help, we will see.
>
> Is there a suggestion on a way the sgtl5000.c could be extended to
> support some sort of re init routine?
>
> I am using the embeddedarm repo as a base.

Which kernel version do you use?


From ard.biesheuvel at linaro.org  Wed Feb  3 06:26:57 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 3 Feb 2016 15:26:57 +0100
Subject: [RFC PATCH 0/3] arm64 initrd mapping/relocation
In-Reply-To: <1454509367.4108.3.camel@redhat.com>
References: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160202180622.GP10166@arm.com>
 <1454509367.4108.3.camel@redhat.com>
Message-ID: <CAKv+Gu__xLKxwAXXf=C3VxpLizjP3oADYyk0bQzQT1G-gTxFqQ@mail.gmail.com>

On 3 February 2016 at 15:22, Mark Salter <msalter at redhat.com> wrote:
> On Tue, 2016-02-02 at 18:06 +0000, Will Deacon wrote:
>> On Tue, Feb 02, 2016 at 06:56:39PM +0100, Ard Biesheuvel wrote:
>> > After discussing in linux-efi with Mark, and on #armlinux with Will, this is
>> > a proposal for dealing with initrd memory that is potentially not covered by
>> > the linear region.
>> >
>> > Note that this will look slightly differently when some of the KASLR work gets
>> > merged, but this should only affect the way we deal with the initrd if it sits
>> > outside of the linear region.
>> >
>> > Mostly intended for discussion, not tested at all.
>>
>> Thanks Ard, this looks like a much better approach to me. Mark -- does
>> the general idea work for you too?
>>
>> Will
>
> Yeah, much simpler. I like it in concept but am I missing something or is it
> adding memory to the system beyond the mem= limit?

Indeed. I think it is reasonable to require that if you pass both mem=
and initrd= *and* you need your memory limit to be honored strictly,
it is up to you to ensure that the initrd does not live in the memory
you are throwing away.

> But even that may not be
> a big deal. And I need to look at the KASLR work and understand the issues
> with it and mem= if any. I'm traveling right now and can't really try it out
> until tomorrow...
>

No worries. My estimation is that Will is not going to take this as a
fix anyway, so we have plenty of time to test and/or discuss

Thanks,
Ard.


From shawnguo at kernel.org  Wed Feb  3 06:28:35 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 3 Feb 2016 22:28:35 +0800
Subject: [PATCH v2 0/4] ARM: dts: vf610: relicense the device trees under
 GPLv2/X11
In-Reply-To: <5311c9f5234f774dc34118a564f48a4c@agner.ch>
References: <1449525076-23569-1-git-send-email-stefan@agner.ch>
 <5311c9f5234f774dc34118a564f48a4c@agner.ch>
Message-ID: <20160203142835.GP8307@tiger>

On Tue, Feb 02, 2016 at 05:00:23PM -0800, Stefan Agner wrote:
> Hi Shawn,
> 
> For patches 1, 2 and 4 I think we have enough Acks to consider it safe
> to change the license.
> 
> For Patch 3, the Cosmic board, I can not get an Ack nor a Nack from Matt
> Porter, unfortunately... But IMHO it should not hold us back from
> merging the rest, what do you think?

Yes.  Applied patches 1, 2 and 4.

Shawn


From friesendrywall at gmail.com  Wed Feb  3 06:33:29 2016
From: friesendrywall at gmail.com (Erik Friesen)
Date: Wed, 3 Feb 2016 09:33:29 -0500
Subject: SGTL5000 misc
In-Reply-To: <CAOMZO5BPNc1ncz6J8yhcBYywCVuTxKYMYhiNUt_Jq3LZsKdi+A@mail.gmail.com>
References: <CAEuupiuhPR48Upo=8f0zV8cxf0Vefgx3qA+vC+QDWAOV4n-e3Q@mail.gmail.com>
 <CAOMZO5BPNc1ncz6J8yhcBYywCVuTxKYMYhiNUt_Jq3LZsKdi+A@mail.gmail.com>
Message-ID: <CAEuupiszxAj7JkJu-5ozqgEnTWkz9FQEpxN8dmEN+KtaV-76ww@mail.gmail.com>

[    0.000000] Linux version 3.10.53-gf3f6648-dirty (root at friesen-nas)
(gcc version 4.8.2 (GCC) ) #163 SMP PREEMPT Mon Feb 1 18:12:31 EST
2016

Its a bit unclear here, am I supposed to reply only to
linux-arm-kernel at list.infraread.org?

On Wed, Feb 3, 2016 at 9:23 AM, Fabio Estevam <festevam at gmail.com> wrote:
> On Wed, Feb 3, 2016 at 11:42 AM, Erik Friesen <friesendrywall at gmail.com> wrote:
>> First post on the list here..
>>
>> I have been working with an embeddedarm ts4900 and built a baseboard
>> that uses the sgtl5000.  I also have worked with the RiotBoard, which
>> uses the same chip, both using the i.mx6 arm.  I find that
>> occasionally the sgtl5000 is resetting, and there is no way to bring
>> it back online.  As near as I can tell, the i2c bus comes back alive,
>> for example alsamixer communicates fine, coms happen on the i2c bus
>> per scope.  However, its obvious the chip never got re initialized by
>> how it acts.
>>
>> I know the thing shouldn't reset, that is the primary problem, but I
>> still want some backup method.  Its probably due to ground bounce from
>> a non earth grounded setup.  It could be that using the external
>> regulator will help, we will see.
>>
>> Is there a suggestion on a way the sgtl5000.c could be extended to
>> support some sort of re init routine?
>>
>> I am using the embeddedarm repo as a base.
>
> Which kernel version do you use?


From festevam at gmail.com  Wed Feb  3 06:38:25 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 3 Feb 2016 12:38:25 -0200
Subject: SGTL5000 misc
In-Reply-To: <CAEuupiszxAj7JkJu-5ozqgEnTWkz9FQEpxN8dmEN+KtaV-76ww@mail.gmail.com>
References: <CAEuupiuhPR48Upo=8f0zV8cxf0Vefgx3qA+vC+QDWAOV4n-e3Q@mail.gmail.com>
 <CAOMZO5BPNc1ncz6J8yhcBYywCVuTxKYMYhiNUt_Jq3LZsKdi+A@mail.gmail.com>
 <CAEuupiszxAj7JkJu-5ozqgEnTWkz9FQEpxN8dmEN+KtaV-76ww@mail.gmail.com>
Message-ID: <CAOMZO5DhrzdVyTVPB3FNquV4rDQ8a0MQrsJMosVsUQN63hj1Ww@mail.gmail.com>

On Wed, Feb 3, 2016 at 12:33 PM, Erik Friesen <friesendrywall at gmail.com> wrote:
> [    0.000000] Linux version 3.10.53-gf3f6648-dirty (root at friesen-nas)

That's a very old kernel. You should try something newer like 4.4.

We had issues with sgtl5000 codec that were fixed with this commit:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/sound/soc/codecs/sgtl5000.c?id=af8ee11209e749c75eabf32b2a4ca631f396acf8

> Its a bit unclear here, am I supposed to reply only to
> linux-arm-kernel at list.infraread.org?

It is fine to reply to all.


From shawnguo at kernel.org  Wed Feb  3 06:40:51 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 3 Feb 2016 22:40:51 +0800
Subject: [PATCH v7 3/7] ARM: dts: imx: Add Advantech BA-16 Qseven module
In-Reply-To: <1454109558-22800-4-git-send-email-akshay.bhat@timesys.com>
References: <1454109558-22800-1-git-send-email-akshay.bhat@timesys.com>
 <1454109558-22800-4-git-send-email-akshay.bhat@timesys.com>
Message-ID: <20160203144051.GQ8307@tiger>

On Fri, Jan 29, 2016 at 06:19:14PM -0500, Akshay Bhat wrote:
> +&ssi1 {
> +	fsl,mode = "i2s-master";

In Documentation/devicetree/bindings/sound/fsl,ssi.txt, I do not see
'i2s-master' as a valid value for fsl,mode property.

Shawn

> +	status = "okay";
> +};


From friesendrywall at gmail.com  Wed Feb  3 06:46:31 2016
From: friesendrywall at gmail.com (Erik Friesen)
Date: Wed, 3 Feb 2016 09:46:31 -0500
Subject: SGTL5000 misc
In-Reply-To: <CAOMZO5DhrzdVyTVPB3FNquV4rDQ8a0MQrsJMosVsUQN63hj1Ww@mail.gmail.com>
References: <CAEuupiuhPR48Upo=8f0zV8cxf0Vefgx3qA+vC+QDWAOV4n-e3Q@mail.gmail.com>
 <CAOMZO5BPNc1ncz6J8yhcBYywCVuTxKYMYhiNUt_Jq3LZsKdi+A@mail.gmail.com>
 <CAEuupiszxAj7JkJu-5ozqgEnTWkz9FQEpxN8dmEN+KtaV-76ww@mail.gmail.com>
 <CAOMZO5DhrzdVyTVPB3FNquV4rDQ8a0MQrsJMosVsUQN63hj1Ww@mail.gmail.com>
Message-ID: <CAEuupiuoB7nMSc8Fbyort1rJd=ZhYc0zfJNkd=ckUYk1qd8Z7Q@mail.gmail.com>

It appears sgtl5000.c is patched the same in my kernel as the commit mentioned.

The problem the way I see it, is that there is no mechanism to deal
with a reboot on the codec itself.

This alsa stuff has too many layers.  At least coming from a non os
embedded angle it seems that way.

On Wed, Feb 3, 2016 at 9:38 AM, Fabio Estevam <festevam at gmail.com> wrote:
> On Wed, Feb 3, 2016 at 12:33 PM, Erik Friesen <friesendrywall at gmail.com> wrote:
>> [    0.000000] Linux version 3.10.53-gf3f6648-dirty (root at friesen-nas)
>
> That's a very old kernel. You should try something newer like 4.4.
>
> We had issues with sgtl5000 codec that were fixed with this commit:
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/sound/soc/codecs/sgtl5000.c?id=af8ee11209e749c75eabf32b2a4ca631f396acf8
>
>> Its a bit unclear here, am I supposed to reply only to
>> linux-arm-kernel at list.infraread.org?
>
> It is fine to reply to all.


From festevam at gmail.com  Wed Feb  3 06:51:38 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 3 Feb 2016 12:51:38 -0200
Subject: SGTL5000 misc
In-Reply-To: <CAEuupiuoB7nMSc8Fbyort1rJd=ZhYc0zfJNkd=ckUYk1qd8Z7Q@mail.gmail.com>
References: <CAEuupiuhPR48Upo=8f0zV8cxf0Vefgx3qA+vC+QDWAOV4n-e3Q@mail.gmail.com>
 <CAOMZO5BPNc1ncz6J8yhcBYywCVuTxKYMYhiNUt_Jq3LZsKdi+A@mail.gmail.com>
 <CAEuupiszxAj7JkJu-5ozqgEnTWkz9FQEpxN8dmEN+KtaV-76ww@mail.gmail.com>
 <CAOMZO5DhrzdVyTVPB3FNquV4rDQ8a0MQrsJMosVsUQN63hj1Ww@mail.gmail.com>
 <CAEuupiuoB7nMSc8Fbyort1rJd=ZhYc0zfJNkd=ckUYk1qd8Z7Q@mail.gmail.com>
Message-ID: <CAOMZO5C4QUHnJr=pisnYWCYZ0zUt+7HO846aPQui0zcLyX0N-Q@mail.gmail.com>

On Wed, Feb 3, 2016 at 12:46 PM, Erik Friesen <friesendrywall at gmail.com> wrote:
> It appears sgtl5000.c is patched the same in my kernel as the commit mentioned.
>
> The problem the way I see it, is that there is no mechanism to deal
> with a reboot on the codec itself.

There is no reset line nor reset command on the sgtl5000.

> This alsa stuff has too many layers.  At least coming from a non os
> embedded angle it seems that way.

I would suggest you to try 4.4.1 and if you still see an issue with
the codec, then report it back to the alsa-devel at alsa-project.org
list.


From shawnguo at kernel.org  Wed Feb  3 06:52:56 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Wed, 3 Feb 2016 22:52:56 +0800
Subject: [PATCH v7 4/7] ARM: dts: imx: Add support for Advantech/GE Bx50v3
In-Reply-To: <1454109558-22800-5-git-send-email-akshay.bhat@timesys.com>
References: <1454109558-22800-1-git-send-email-akshay.bhat@timesys.com>
 <1454109558-22800-5-git-send-email-akshay.bhat@timesys.com>
Message-ID: <20160203145256.GR8307@tiger>

On Fri, Jan 29, 2016 at 06:19:15PM -0500, Akshay Bhat wrote:
> From: Justin Waters <justin.waters at timesys.com>
> 
> Advantech has 3 carrier boards (B450v3, B650v3, B850v3) which use
> the Advantech BA-16 module (based on iMX6D). This file has the
> devicetree entries that are common to all 3 boards.
> 
> Signed-off-by: Akshay Bhat <akshay.bhat at timesys.com>
> Signed-off-by: Justin Waters <justin.waters at timesys.com>
> ---
>  arch/arm/boot/dts/imx6q-bx50v3.dtsi | 239 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 239 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6q-bx50v3.dtsi
> 
> diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
> new file mode 100644
> index 0000000..a44b074
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
> @@ -0,0 +1,239 @@
> +/*
> + * Copyright 2015 Timesys Corporation.
> + * Copyright 2015 General Electric Company
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License
> + *     version 2 as published by the Free Software Foundation.
> + *
> + *     This file is distributed in the hope that it will be useful
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "imx6q-ba16.dtsi"
> +
> +/ {
> +	clocks {
> +		#address-cells = <1>;
> +		#size-cells = <0>;

These are already specified in imx6qdl.dtsi.

> +
> +		mclk: clock at 0 {
> +			compatible = "fixed-clock";
> +			reg = <0>;
> +			#clock-cells = <0>;
> +			clock-frequency = <22000000>;
> +		};
> +	};

<snip>

> +&i2c1 {
> +	pca9547: mux at 70 {
> +		compatible = "nxp,pca9547";
> +		reg = <0x70>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		mux1_i2c1: i2c at 0 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x0>;
> +
> +			ads7830: ads7830 at 48 {
> +				compatible = "ti,ads7830";
> +				reg = <0x48>;
> +			};
> +
> +			mma8453: mma8453 at 1c {
> +				compatible = "fsl,mma8453";
> +				reg = <0x1c>;
> +			};
> +		};
> +
> +		mux1_i2c2: i2c at 1 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x1>;
> +
> +			eeprom: eeprom at 50 {
> +				compatible = "atmel,24c08";
> +				reg = <0x50>;
> +			};
> +
> +			mpl3115: mpl3115 at 60 {
> +				compatible = "fsl,mpl3115";
> +				reg = <0x60>;
> +			};
> +		};
> +
> +		mux1_i2c3: i2c at 2 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x2>;
> +		};
> +
> +		mux1_i2c4: i2c at 3 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x3>;
> +
> +			codec: sgtl5000 at 0a {

I think the naming schema below matches DT convention better, i.e. the
node name should be generic.

			sgtl5000: codec at 0a {

> +				compatible = "fsl,sgtl5000";
> +				reg = <0x0a>;
> +				clocks = <&mclk>;
> +				VDDA-supply = <&reg_1p8v>;
> +				VDDIO-supply = <&reg_3p3v>;
> +			};
> +		};

<snip>

> +&usdhc4 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_usdhc4>;
> +	bus-width = <4>;
> +	vmmc-supply = <&reg_wl18xx_vmmc>;
> +	no-1-8-v;
> +	non-removable;
> +	wakeup-source;
> +	keep-power-in-suspend;
> +	cap-power-off-card;
> +	max-frequency = <25000000>;
> +	status = "okay";
> +

Drop this new line and have 'status' be the last property.

> +	#address-cells = <1>;
> +	#size-cells = <0>;

I'm not sure why this and a 'reg' property in sub-nodes are necessary at
all, but ...

> +
> +	wlcore: wlcore at 0 {
> +		compatible = "ti,wl1837";
> +		reg = <2>;

... at least the 'reg' property should match the unit-address after node
name.

Shawn

> +		interrupt-parent = <&gpio2>;
> +		interrupts = <6 IRQ_TYPE_LEVEL_HIGH>;
> +		tcxo-clock-frequency = <26000000>;
> +	};
> +};
> -- 
> 2.7.0
> 
> 


From thierry.reding at gmail.com  Wed Feb  3 06:53:37 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Wed, 3 Feb 2016 15:53:37 +0100
Subject: [PATCH v3 00/12] pwm: add support for atomic update
In-Reply-To: <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
References: <1442828009-6241-1-git-send-email-boris.brezillon@free-electrons.com>
 <2341981.a79ioYM9Es@diego> <20151110173416.GB21727@ulmo>
 <CAD=FV=WL3jYEgVe-m6QcAyQwfJgdX4J5OtKisKwyoKOrTSpEQA@mail.gmail.com>
 <20160125170855.GA10182@ulmo>
 <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
Message-ID: <20160203145337.GD9650@ulmo>

On Mon, Jan 25, 2016 at 10:51:20AM -0800, Doug Anderson wrote:
> Hi,
> 
> On Mon, Jan 25, 2016 at 9:08 AM, Thierry Reding
> <thierry.reding at gmail.com> wrote:
> > I really don't understand this design decision. I presume that the PWM
> > controlling this system-critical logic is driven by the SoC? So if the
> > regulator is system-critical, doesn't that make it a chicken and egg
> > problem? How can the SoC turn the PWM on if it doesn't have power? But
> > perhaps I'm completely misunderstanding what you're saying. Perhaps if
> > somebody could summarize how exactly this works, it would help better
> > understand the requirements or what's the correct thing to do.
> 
> Sure, here's how the dang thing works, as I understand it.
> 
> First, an overview of PWM regulator in general (maybe you know this,
> but to get us on the same page).  There's an external regulator on the
> system.  Looking on at least one board I see a TLV62565 specifically.
> 
> From the docs of TLV62565, I see it describe the situation as the chip
> being able to provide an adjustable output voltage configurable via an
> external resistor divider.  In simplified terms words you can adjust
> the output voltage of the regulator by tweaking the inputs to one of
> its pins.  I'm just a software guy so I can't explain all the details
> of it, but the net-net of the situation is is that you can hook this
> configuration pin up to the output of a PWM (with a bunch of well
> balanced resistors and capacitors) and then you can set the voltage
> based on the output of the PWM.
> 
> 
> OK, so what happens at bootup?  At bootup most of the pins of the
> rk3288 (including the PWM) are configured as inputs with a pull.  The
> particular pin hooked up to this PWM has a pulldown.  Remember that
> we've got this nicely balanced set of resistors and capacitors hooked
> up to the output of our PWM pin?  So what happens when we have this
> pin configured as an input?  As I understand it / remember it:
> 
> * input w/ no pull: equivalent to 50% duty cycle on the PWM
> * input w/ pull down: equivalent to slightly higher voltage than 50%
> duty cycle on the PWM
> * input w/ pull up: equivalent to slightly lower voltage than 50% duty
> cycle on the PWM
> 
> On our particular board that means that the rail comes up with roughly
> 1.1V.  If you drive the PWM at 100% (or set the pin to output high)
> you get .86V and if you drive the PWM at 0% (or set the pin to output
> low) you get 1.36V.
> 
> Now, 1.1V is plenty of voltage to boot the system.  In fact most of
> the logic within the SoC can run as low as 0.95V I think.  ...but 0.86
> V is not enough to run the logic parts of the system (even at their
> default bootup frequencies) 1.1V is _definitely_ not enough to run the
> SDRAM memory controller at full speed.
> 
> 
> So the bootloader wants to run the system fast so it can boot fast.
> It increases the CPU rails (as is typical for a bootloader) and moves
> the ARM CPU to 1.8GHz (from the relatively slow boot frequency) and
> also raises the logic rail to 1.2V (or I think 1.15 V on systems w/
> different memory configs) and inits the SDRAM controller to run at
> full speed.  Then it boots Linux.
> 
> Note: apparently in U-Boot they actually boot system slower (this was
> at least true 1.5 years ago with some reference U-Boot Rockchip
> provided).  If I understand correctly they _didn't_ init the SDRAM
> controller as full speed in the bootloader and just left the logic
> rail at its bootup default.  If everyone had done that then our job
> would be "easier" because we wouldn't need to read in the voltage
> provided by the bootloader (by reading the PWM and cros-referencing
> with our table), though even in that case we'd have to be very careful
> not to glitch the line (since .86 V is too low).  Of course all of
> those systems are stuck running at a very slow memory speed until
> Linux gets DDR Frequency support for Rockchip whereas systems with our
> bootloader not only boot faster but also get to use the full memory
> speed even without any Linux DDRFreq drivers.
> 
> 
> In any case: I think I've demonstrated how a critical system rail can
> be using a PWM regulator and how glitching that PWM regulator at boot
> time can be catastrophic.  Possibly it's not critical to be able to
> "read" the voltage that that bootloader left things configured at
> (it's mostly nice for debugging purposes), but it's definitely
> important to make sure we don't set it to some default and important
> to never glitch it.  Said another way, presumably a DDR Freq driver
> would be able to switch the memory controller frequency sanely by
> reading the memory controller frequency and using that to figure out
> whether it needed to up the logic rail before or after the DDR Freq
> change.

Thanks for going into so much detail, this helps a lot in understanding
the actual problem we need to solve.

> > The problem that we've encountered is that since the PWM parameters are
> > specified in DT (or board files), there is the possibility of the PWM
> > hardware state and the board parameters disagreeing. To resolve such
> > situations there must be a point in time where both hardware state and
> > software state must be synchronized. Now the most straightforward way to
> > do that would be to simply apply the software state and be done with it.
> > However the software state initially lacks the duty cycle because it is
> > a parameter that usually depends on the use-case (for backlight for
> > instance it controls the brightness, for regulators it controls the
> > output voltage, ...).
> 
> Excuse me for not knowing all details that have been talked about before, but...
> 
> A) The software state here is the period and flags (AKA "inverted),
> right?  It does seem possible that you could apply the period and
> flags while keeping the calculated bootup duty cycle percentage
> (presuming that the PWM was actually enabled at probe time and there
> was a bootup duty cycle at all).  That would basically say that
> whenever you set the period of a PWM then the duty cycle of the PWM
> should remain the same percentage.  That actually seems quite sane
> IMHO.  It seems much saner than trying to keep the duty cycle "ns"
> when the period changes or resetting the PWM to some default when the
> period changes.

That really depends on the use-case. If you're interested in the output
power of the PWM then, yes, this is sane. But it might not be the right
answer in other cases.

> B) Alternatively, I'd also say that setting a period without a duty
> cycle doesn't make a lot of sense.  ...so you could just apply the
> period at the same time that you apply the duty cycle the first time.
> Presumably you'd want to "lie" to the callers of the PWM subsystem and
> tell them that you already changed the period even though the change
> won't really take effect until they actually set the duty cycle.  If
> anyone cared to find out the true hardware period we could add a new
> pwm_get_hw_period().  ...or since the only reason you'd want to know
> the hardware period would be if you're trying to read the current duty
> cycle percentage, you could instead add "pwm_get_hw_state()" and have
> that return both the hardware period ns and duty cycle ns (which is
> the most accurate way to return the "percentage" without using fix or
> floating point math).

But then you get into a situation where behaviour is dependent on the
PWM driver, whereas this is really very specific to one specific use-
case.

In the end the PWM API is as low-level as it is because it needs to be
flexible enough to cope with other use-cases. In the general case the
simple truth is that it doesn't make sense to set a period without the
duty cycle and vice versa. That's why pwm_config() takes both as input
parameters. The atomic API is going to take that one step further in
that you need to specify the complete state of the PWM when applying.

> Both of the above options seems like it could be sensible.  The 2nd
> seems cleaner because it doesn't require you to recalculate /
> approximate the old duty cycle using a new period, but it's slightly
> uglier because it no longer returns the true hardware state from
> pwm_get_period().
> 
> 
> > Applying the software state as-is also means that there's no reason at
> > all to read out the hardware state in the first place, because it will
> > simply be discarded.
> 
> Pretty sure we can't discard the hardware duty cycle at bootup, as per above.
> 
> 
> > An alternative would be to discard the software state and trust the
> > hardware to be configured correctly. That's somewhat risky because we
> > don't know if the hardware is properly configured. Or Linux might have
> > different requirements from the firmware and hence needs to configure
> > the PWM differently.
> 
> Doesn't seem like a good idea either.
> 
> 
> > Neither of the above are very attractive options. The best I've been
> > able to come up with so far is to completely remove this decision from
> > the PWM subsystem and let users handle this. That is, a PWM regulator
> > driver would have to have all the knowledge about how to configure the
> > PWM for its needs. So upon probe, the PWM regulator driver would inspect
> > the current state of the PWM and adjust if necessary, then apply again.
> > Ideally of course it wouldn't have to do anything because the hardware
> > PWM state would match the software configuration. The idea here is that
> > the PWM regulator driver knows exactly what duty cycle to configure to
> > obtain the desired output voltage.
> 
> I think this is like my suggestion B), right?  AKA the PWM regulator
> would be the sole caller of pwm_get_hw_state() and it would use this
> to figure out the existing duty cycle percentage.  Then it would
> translate that into "ns" and would set the duty cycle.  Upon the first
> set of the duty cycle both the period and duty cycle would be applied
> at the same time.

Yes and no. I think the PWM regulator would need to get the current
hardware state and derive the output power from duty cycle and period.
It would then need to rescale to whatever new period it wants to use
to ensure the same output power is used.

> > That doesn't really get us closer, though. There is still the issue of
> > the user having to deal with two states: the current hardware state and
> > the software state as configured in DT or board files.
> 
> I think the only users that need to deal with this are one that need a
> seamless transition from bootup settings.  Adding a new API call to
> support a new feature like this doesn't seem insane, and anyone who
> doesn't want this new feature can just never call the new API.
> 
> The only thing that would "change" from the point of view of old
> drivers is that the PWM period wouldn't change at bootup until the
> duty cycle was set.  IMHO this is probably a bug fix.  AKA, for a PWM
> backlight, imagine:
> 
> 1. Firmware sets period to 20000 ns, duty cycle to 8000 ns (40%)
> 2. Linux boots up and sets period to 10000 ns.  Brightness of
> backlight instantly goes to 80%.
> 3. Eventually something decides to set the backlight duty cycle and it
> goes to the proper rate.
> 
> Skipping #2 seems like the right move.  ...or did I misunderstand how
> something works?

I'm not aware of any code in the PWM subsystem that would do this
automatically. If you don't call any of the pwm_*() functions the
hardware state should not be modified. The responsibility is with
the user drivers.

That is, it is up to the regulator or backlight driver to apply any new
configuration to a PWM channel on boot, or leave it as is. For
backlight it's probably fine to simply apply some default, since having
the brightness change on boot isn't going to be terribly irritating.

With the atomic API it would be possible to avoid even this and have the
backlight driver simply read out the current hardware state and apply an
equivalent brightness even if the period changed.

For the regulator case you'd need to read out the current state and then
recompute the values that will yield the same output power given data
specified in DT. I think that much is already implemented in Boris'
series, and it's really only the details that are being debated.

The problematic issue is still that we might have a disparity between
the current hardware state and the state initially specified by DT. In
the general case the DT will specify the period and polarity of the PWM
signal and leave it up to the user driver to determine what a correct
duty cycle would be. With the atomic API we'll essentially have two
states: the current (hardware) state and the "initial" state, which is
what an OS will see as the state to apply. The problem now is that once
you have applied the initial state with a duty cycle you've determined,
there is no longer a need to keep it around. But there's also no way to
know when this is the case. So the controversial part about all this is
when to start using the current state rather that the initial state.

The most straightforward way to solve this would be to apply the initial
configuration on driver probe. That is, when the pwm-regulator driver
gets probed it would retrieve the current and initial states, then
adjust the current state such that it matches the initial state but with
a duty cycle that yields the same output power as the current state, and
finally apply the new state. After that, every regulator_set_voltage()
call could simply operate on the current state and adjust the duty cycle
exclusively.

Does that sound reasonable?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/6466984f/attachment.sig>

From alexandre.torgue at gmail.com  Wed Feb  3 06:54:31 2016
From: alexandre.torgue at gmail.com (Alexandre TORGUE)
Date: Wed,  3 Feb 2016 15:54:31 +0100
Subject: [PATCH 0/4]  Add Ethernet support on STM32F429
Message-ID: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>

STM32F429 Chip embeds a Synopsys 3.50a MAC IP.
This series:
	-enhance current stmmac driver to control it (code already available) and 
	 adds basic glue for STM32F429 chip.
	-Enable basic Net config in kernel.

Note that DT patches are not present because STM32 pinctrl code is not
yet avalaible.

Regards 

Alexandre

Alexandre TORGUE (4):
  net: ethernet: dwmac: add Ethernet glue logic for stm32 chip
  Documentation: Bindings: Add STM32 DWMAC glue
  net: ethernet: stmmac: add support of Synopsys 3.50a MAC IP
  ARM: STM32: Enable Ethernet in stm32_defconfig

 .../devicetree/bindings/net/stm32-dwmac.txt        |  41 +++++
 arch/arm/configs/stm32_defconfig                   |   9 ++
 drivers/net/ethernet/stmicro/stmmac/Kconfig        |  12 ++
 drivers/net/ethernet/stmicro/stmmac/Makefile       |   1 +
 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c  | 177 +++++++++++++++++++++
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |   1 +
 6 files changed, 241 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/stm32-dwmac.txt
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c

-- 
1.9.1



From alexandre.torgue at gmail.com  Wed Feb  3 06:54:32 2016
From: alexandre.torgue at gmail.com (Alexandre TORGUE)
Date: Wed,  3 Feb 2016 15:54:32 +0100
Subject: [PATCH 1/4] net: ethernet: dwmac: add Ethernet glue logic for stm32
 chip
In-Reply-To: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
References: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <1454511275-9791-2-git-send-email-alexandre.torgue@gmail.com>

stm324xx family chips support Synopsys MAC 3.510 IP.
This patch adds settings for logical glue logic:
-clocks
-mode selection MII or RMII.

Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index cec147d..a94dd15 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -114,6 +114,18 @@ config DWMAC_SUNXI
 	  This selects Allwinner SoC glue layer support for the
 	  stmmac device driver. This driver is used for A20/A31
 	  GMAC ethernet controller.
+
+config DWMAC_STM32
+	tristate "STM32 DWMAC support"
+	default ARCH_STM32
+	depends on OF
+	select MFD_SYSCON
+	---help---
+	  Support for ethernet controller on STM32 SOCs.
+
+	  This selects STM32 SoC glue layer support for the stmmac
+	  device driver. This driver is used on for the STM32 series
+	  SOCs GMAC ethernet controller.
 endif
 
 config STMMAC_PCI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index b390161..9fb2061 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DWMAC_SOCFPGA)	+= dwmac-socfpga.o
 obj-$(CONFIG_DWMAC_STI)		+= dwmac-sti.o
 obj-$(CONFIG_DWMAC_SUNXI)	+= dwmac-sunxi.o
 obj-$(CONFIG_DWMAC_GENERIC)	+= dwmac-generic.o
+obj-$(CONFIG_DWMAC_STM32)	+= dwmac-stm32.o
 stmmac-platform-objs:= stmmac_platform.o
 
 obj-$(CONFIG_STMMAC_PCI) += stmmac-pci.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
new file mode 100644
index 0000000..56ccc20
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
@@ -0,0 +1,177 @@
+/*
+ * dwmac-stm32.c - DWMAC Specific Glue layer for STM32 MCU
+ *
+ * Copyright (C) Alexandre Torgue 2015
+ * Author:  Alexandre Torgue <alexandre.torgue at gmail.com>
+ * License terms:  GNU General Public License (GPL), version 2
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+#include <linux/stmmac.h>
+#include <linux/phy.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/clk.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_net.h>
+
+#include "stmmac_platform.h"
+
+#define MII_PHY_SEL_MASK	BIT(23)
+
+struct stm32_dwmac {
+	int interface;		/* MII interface */
+	struct clk *clk_tx;
+	struct clk *clk_rx;
+	u32 mode_reg;		/* MAC glue-logic mode register */
+	struct device *dev;
+	struct regmap *regmap;
+	u32 speed;
+};
+
+static int stm32_dwmac_init(struct platform_device *pdev, void *priv)
+{
+	struct stm32_dwmac *dwmac = priv;
+	struct regmap *regmap = dwmac->regmap;
+	int ret, iface = dwmac->interface;
+	u32 reg = dwmac->mode_reg;
+	u32 val;
+
+	if (dwmac->clk_tx)
+		ret = clk_prepare_enable(dwmac->clk_tx);
+		if (ret)
+			goto out;
+
+	if (dwmac->clk_rx)
+		ret = clk_prepare_enable(dwmac->clk_rx);
+		if (ret)
+			goto out_disable_clk_tx;
+
+	val = (iface == PHY_INTERFACE_MODE_MII) ? 0 : 1;
+	ret = regmap_update_bits(regmap, reg, MII_PHY_SEL_MASK, val);
+	if (ret)
+		goto out_disable_clk_tx_rx;
+
+	return 0;
+
+out_disable_clk_tx_rx:
+	clk_disable_unprepare(dwmac->clk_rx);
+out_disable_clk_tx:
+	clk_disable_unprepare(dwmac->clk_tx);
+out:
+	return ret;
+}
+
+static void stm32_dwmac_exit(struct platform_device *pdev, void *priv)
+{
+	struct stm32_dwmac *dwmac = priv;
+
+	if (dwmac->clk_tx)
+		clk_disable_unprepare(dwmac->clk_tx);
+	if (dwmac->clk_rx)
+		clk_disable_unprepare(dwmac->clk_rx);
+}
+
+static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
+				  struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct regmap *regmap;
+	int err;
+
+	if (!np)
+		return -EINVAL;
+
+	/*  Get TX/RX clocks */
+	dwmac->clk_tx = devm_clk_get(dev, "tx-clk");
+	if (IS_ERR(dwmac->clk_tx)) {
+		dev_warn(dev, "No tx clock provided...\n");
+		dwmac->clk_tx = NULL;
+	}
+	dwmac->clk_rx = devm_clk_get(dev, "rx-clk");
+	if (IS_ERR(dwmac->clk_rx)) {
+		dev_warn(dev, "No rx clock provided...\n");
+		dwmac->clk_rx = NULL;
+	}
+
+	/* Get mode register */
+	regmap = syscon_regmap_lookup_by_phandle(np, "st,syscon");
+	if (IS_ERR(regmap))
+		return PTR_ERR(regmap);
+
+	err = of_property_read_u32_index(np, "st,syscon", 1, &dwmac->mode_reg);
+	if (err) {
+		dev_err(dev, "Can't get sysconfig mode offset (%d)\n", err);
+		return err;
+	}
+
+	dwmac->dev = dev;
+	dwmac->interface = of_get_phy_mode(np);
+	dwmac->regmap = regmap;
+
+	return 0;
+}
+
+static int stm32_dwmac_probe(struct platform_device *pdev)
+{
+	struct plat_stmmacenet_data *plat_dat;
+	struct stmmac_resources stmmac_res;
+	struct stm32_dwmac *dwmac;
+	int ret;
+
+	ret = stmmac_get_platform_resources(pdev, &stmmac_res);
+	if (ret)
+		return ret;
+
+	plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
+	if (IS_ERR(plat_dat))
+		return PTR_ERR(plat_dat);
+
+	dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
+	if (!dwmac)
+		return -ENOMEM;
+
+	ret = stm32_dwmac_parse_data(dwmac, pdev);
+	if (ret) {
+		dev_err(&pdev->dev, "Unable to parse OF data\n");
+		return ret;
+	}
+
+	plat_dat->bsp_priv = dwmac;
+	plat_dat->init = stm32_dwmac_init;
+	plat_dat->exit = stm32_dwmac_exit;
+
+	ret = stm32_dwmac_init(pdev, plat_dat->bsp_priv);
+	if (ret)
+		return ret;
+
+	return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
+}
+
+static const struct of_device_id stm32_dwmac_match[] = {
+	{ .compatible = "st,stm32-dwmac"},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, stm32_dwmac_match);
+
+static struct platform_driver stm32_dwmac_driver = {
+	.probe  = stm32_dwmac_probe,
+	.remove = stmmac_pltfr_remove,
+	.driver = {
+		.name           = "stm32-dwmac",
+		.pm		= &stmmac_pltfr_pm_ops,
+		.of_match_table = stm32_dwmac_match,
+	},
+};
+module_platform_driver(stm32_dwmac_driver);
+
+MODULE_AUTHOR("Alexandre Torgue <alexandre.torgue at gmail.com>");
+MODULE_DESCRIPTION("STMicroelectronics MCU DWMAC Specific Glue layer");
+MODULE_LICENSE("GPL");
+
-- 
1.9.1



From alexandre.torgue at gmail.com  Wed Feb  3 06:54:33 2016
From: alexandre.torgue at gmail.com (Alexandre TORGUE)
Date: Wed,  3 Feb 2016 15:54:33 +0100
Subject: [PATCH 2/4] Documentation: Bindings: Add STM32 DWMAC glue
In-Reply-To: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
References: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <1454511275-9791-3-git-send-email-alexandre.torgue@gmail.com>

Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>

diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
new file mode 100644
index 0000000..18734b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
@@ -0,0 +1,41 @@
+STMicroelectronics STM32 / MCU DWMAC glue layer controller
+
+This file documents platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+The device node has following properties.
+
+Required properties:
+- compatible:  Should be "st,stm32-dwmac" to select glue, and
+	       "snps,dwmac-3.50a" to select IP vesrion.
+- clocks: Should contain the GMAC main clock, and tx clock
+- compatible:  Should be "st,stm32-dwmac" to select glue and
+	       "snps,dwmac-3.50a" to select IP version.
+- clocks: Should contain the MAC main clock
+- clock-names: Should contain the clock names "stmmaceth".
+- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
+	      encompases the glue register, and the offset of the control register.
+
+Optional properties:
+- clocks: Could contain:
+	- the tx clock,
+	- the rx clock
+- clock-names: Could contain the clock names "tx-clk", "rx-clk"
+
+Example:
+
+		ethernet0: dwmac at 40028000 {
+			device_type = "network";
+			compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
+			status = "disabled";
+			reg = <0x40028000 0x8000>;
+			reg-names = "stmmaceth";
+			interrupts = <0 61 0>, <0 62 0>;
+			interrupt-names = "macirq", "eth_wake_irq";
+			clock-names = "stmmaceth", "tx-clk", "rx-clk";
+			clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
+			st,syscon = <&syscfg 0x4>;
+			snps,pbl = <32>;
+			snps,mixed-burst;
+			dma-ranges;
+		};
-- 
1.9.1



From alexandre.torgue at gmail.com  Wed Feb  3 06:54:34 2016
From: alexandre.torgue at gmail.com (Alexandre TORGUE)
Date: Wed,  3 Feb 2016 15:54:34 +0100
Subject: [PATCH 3/4] net: ethernet: stmmac: add support of Synopsys 3.50a MAC
 IP
In-Reply-To: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
References: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <1454511275-9791-4-git-send-email-alexandre.torgue@gmail.com>

Adds support of Synopsys 3.50a MAC IP in stmmac driver.

Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 6a52fa1..6cca626 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -178,6 +178,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
 	 * once needed on other platforms.
 	 */
 	if (of_device_is_compatible(np, "st,spear600-gmac") ||
+		of_device_is_compatible(np, "snps,dwmac-3.50a") ||
 		of_device_is_compatible(np, "snps,dwmac-3.70a") ||
 		of_device_is_compatible(np, "snps,dwmac")) {
 		/* Note that the max-frame-size parameter as defined in the
-- 
1.9.1



From alexandre.torgue at gmail.com  Wed Feb  3 06:54:35 2016
From: alexandre.torgue at gmail.com (Alexandre TORGUE)
Date: Wed,  3 Feb 2016 15:54:35 +0100
Subject: [PATCH 4/4] ARM: STM32: Enable Ethernet in stm32_defconfig
In-Reply-To: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
References: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <1454511275-9791-5-git-send-email-alexandre.torgue@gmail.com>

Enable basic Ethernet support (IPV4) for stm32 defconfig.

Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index ec52505..8b8abe0 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -33,11 +33,20 @@ CONFIG_XIP_PHYS_ADDR=0x08008000
 CONFIG_BINFMT_FLAT=y
 CONFIG_BINFMT_SHARED_FLAT=y
 # CONFIG_COREDUMP is not set
+CONFIG_NET=y
+CONFIG_INET=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_IPV6 is not set
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_FW_LOADER is not set
 # CONFIG_BLK_DEV is not set
 CONFIG_EEPROM_93CX6=y
+CONFIG_NETDEVICES=y
+CONFIG_STMMAC_ETH=y
+# CONFIG_WLAN is not set
 # CONFIG_INPUT is not set
 # CONFIG_SERIO is not set
 # CONFIG_VT is not set
-- 
1.9.1



From thomas.petazzoni at free-electrons.com  Wed Feb  3 06:56:48 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 3 Feb 2016 15:56:48 +0100
Subject: [PATCH 1/2] ARM: mvebu: change order of ethernet DT nodes on
 Armada 38x
In-Reply-To: <20160129114853.GQ10826@n2100.arm.linux.org.uk>
References: <1453907300-28283-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1453907300-28283-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160127193143.GF10826@n2100.arm.linux.org.uk>
 <20160127194512.GA16638@1wt.eu>
 <20160129114853.GQ10826@n2100.arm.linux.org.uk>
Message-ID: <20160203155648.1c6fed8f@free-electrons.com>

Hello Russell,

On Fri, 29 Jan 2016 11:48:53 +0000, Russell King - ARM Linux wrote:

> > Well, may be that's one more reason for fixing it before boards start to
> > ship and run distro kernels. If some boards are already in the wild running
> > on a BSP kernel, people will complain that mainline reorders their network
> > ports and will stick to the BSP kernel instead.
> 
> I've checked, and we believe not many people are using mainline kernels
> on clearfog.  I'll have to adjust my debian jessie setup to fix the
> resulting carnage though.  On the plus side, it means that mainline
> matches Marvell's kernel for interface naming.
> 
> However, I will point out that changing the DT order may fix it for now,
> but if there's changes to the kernel initialisation which results in a
> different probe order (eg, because of a change to the way probing works,
> which is something that's been discussed a few times) it's likely that
> the ethX names will change again...
> 
> In other words, what I'm saying is that there's no guarantee that
> changing the DT order will always result in the desired network device
> naming.

Yes, fully agreed, it is not a complete guarantee. But in "most cases",
it will still lead to something that is a bit more logical for normal
users.

In its vendor BSP, Marvell has gone all the way to changing the link
order of certain PCIe drivers, to make sure that the mvneta driver gets
probed first. And indeed, without this hack, if you plug an e1000e PCIe
NIC, it gets probed first and therefore assigned as eth0, while all the
built-in network interfaces get shifted at eth1, eth2, etc.

Really sad that the network subsystem doesn't follow the DT aliases to
name network interfaces, but it has been rejected multiple times by
Dave Miller as far as I know. In the absence of this, re-ordering the
DT nodes is a cheap hack that makes things look a bit more logical in
many situations.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From ulf.hansson at linaro.org  Wed Feb  3 06:58:07 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Wed, 3 Feb 2016 15:58:07 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAJZ5v0iSu9_uNLZstKsC1mHi3A3GRxQc=WPU6Xa7BSiaNChNCA@mail.gmail.com>
References: <20160201232833.GR19432@atomide.com>
 <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>
 <20160202030533.GT19432@atomide.com>
 <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>
 <20160202163536.GU19432@atomide.com>
 <CAPDyKFosQjkHDVSvy67+hstjjFseXQP5WYXrJE19GgVFYJ099w@mail.gmail.com>
 <20160202234145.GC19432@atomide.com>
 <CAPDyKFqLi8xOUeoxUTAmif5QrOjVpV_2CDLv4hjO_C9iOnv+5Q@mail.gmail.com>
 <CAPDyKFqSVZffQ7WNZqn9qSRibsCgG2rY26z_97agL+LhQRVGcg@mail.gmail.com>
 <CAJZ5v0iSu9_uNLZstKsC1mHi3A3GRxQc=WPU6Xa7BSiaNChNCA@mail.gmail.com>
Message-ID: <CAPDyKFpNRc3Nf9ofXhZrfBa54vXMxWboDScCrYFrZy97m8Y5gg@mail.gmail.com>

On 3 February 2016 at 13:18, Rafael J. Wysocki <rafael at kernel.org> wrote:
> On Wed, Feb 3, 2016 at 11:25 AM, Ulf Hansson <ulf.hansson at linaro.org> wrote:
>>>
>>> I don't see the problem, but of course you know omap for better than I do.
>>>
>>> So if you are concerned about this, perhaps adding a dev_dbg print
>>> when the omap hwmod's ->runtime_suspend() callback returns zero could
>>
>> /s/runtime_suspend/runtime_resume
>
> OK
>
> Let me summarize my understanding of this thread so far.
>
> It looks like the omap3 code initializes hardware in ->probe() and
> then it may return -EPROBE_DEFER due to some unmet dependencies.  In
> that case the hardware is not reset to the previous state and the
> runtime PM framework is left in the state that corresponds to the
> current hardware state.  Before we had pm_runtime_reinit(), everything
> worked as expected on the second ->probe() call, because things were
> in sync then.

Correct!

Before pm_runtime_reinit(), the failing probe case (-EPROBE_DEFER)
worked fine because the HW state and the runtime PM status was in
sync. The device was powered and the runtime PM status was RPM_ACTIVE.

>
> The introduction of pm_runtime_reinit() changed the situation and now
> effectively the hardware is required to be reset to the initial state
> if -EPROBE_DEFER is to be returned too.

Not correct. The hardware doesn't need a reset as it stays powered
after a failed probe.

Instead, only the runtime PM status needs to be synchronized with the
HW state the next probe attempt.

In other words, when the PM domain's ->runtime_resume() callbacks gets
called due to a pm_runtime_get_sync() in the second probe attempt, it
may find that the HW is already powered and can return zero instead of
resetting it.

Kind regards
Uffe


From slash.tmp at free.fr  Wed Feb  3 07:07:53 2016
From: slash.tmp at free.fr (Mason)
Date: Wed, 3 Feb 2016 16:07:53 +0100
Subject: Plain DFS (no voltage scaling)
In-Reply-To: <56B11B67.3090600@free.fr>
References: <56B11B67.3090600@free.fr>
Message-ID: <56B217C9.1050405@free.fr>

On 02/02/2016 22:11, Mason wrote:

> I plan to enable the on-demand governor on the tango platform:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
> 
> I found the cpufreq-dt binding doc:
> 
> https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
> 
> Something is not clear to me:
> 
> If my platform cannot scale the voltage, what information
> should I put in the voltage part of the DT?

Someone pointed out that tweaking the frequency without tweaking
the voltage might be counter-productive.

I measured the power consumption of the entire board (at the power outlet)
for 3 CPU frequencies (all other things being equal, I hope).

idle @ 111 MHz = 4.6 W
idle @ 333 MHz = 4.6 W
idle @ 999 MHz = 4.6 W

load @ 111 MHz = 5.0 W
load @ 333 MHz = 5.7 W
load @ 999 MHz = 7.7 W

When idle, the kernel calls WFI, which "turns off" most of the CPU
(clock gating?) such that the actual frequency does not matter.

At full load (I use cpuburn to jog as many FUs simultaneously as
possible) it looks like each additional MHz requires ~3 mW.

So it would appear that an on-demand governor might not help to
save power.

But I have another use-case in mind: CPU throttling on over-heating.
There's a temperature sensor in the CPU, and I'd like to say:
"if temperature exceeds a user-set threshold, don't run at the max
frequency until the temperature becomes reasonable".

And I think that requires cpufreq?

Regards.



From friesendrywall at gmail.com  Wed Feb  3 07:11:39 2016
From: friesendrywall at gmail.com (Erik Friesen)
Date: Wed, 3 Feb 2016 10:11:39 -0500
Subject: SGTL5000 misc
In-Reply-To: <CAOMZO5C4QUHnJr=pisnYWCYZ0zUt+7HO846aPQui0zcLyX0N-Q@mail.gmail.com>
References: <CAEuupiuhPR48Upo=8f0zV8cxf0Vefgx3qA+vC+QDWAOV4n-e3Q@mail.gmail.com>
 <CAOMZO5BPNc1ncz6J8yhcBYywCVuTxKYMYhiNUt_Jq3LZsKdi+A@mail.gmail.com>
 <CAEuupiszxAj7JkJu-5ozqgEnTWkz9FQEpxN8dmEN+KtaV-76ww@mail.gmail.com>
 <CAOMZO5DhrzdVyTVPB3FNquV4rDQ8a0MQrsJMosVsUQN63hj1Ww@mail.gmail.com>
 <CAEuupiuoB7nMSc8Fbyort1rJd=ZhYc0zfJNkd=ckUYk1qd8Z7Q@mail.gmail.com>
 <CAOMZO5C4QUHnJr=pisnYWCYZ0zUt+7HO846aPQui0zcLyX0N-Q@mail.gmail.com>
Message-ID: <CAEuupivdftoopCOX3f7KRbV9poKdjdD3s9hfcbgB2TYjHmrjvw@mail.gmail.com>

There is no difference in code that I can tell between the two.  I am
not asking to have this fixed, rather just some ideas on how I can
implement this. If alsa-devel list is the preferred asking place, I'll
go there.

The riotboard used kernel 4.3.0-rc2-00019-gbcee19f with the same results.

On Wed, Feb 3, 2016 at 9:51 AM, Fabio Estevam <festevam at gmail.com> wrote:
> On Wed, Feb 3, 2016 at 12:46 PM, Erik Friesen <friesendrywall at gmail.com> wrote:
>> It appears sgtl5000.c is patched the same in my kernel as the commit mentioned.
>>
>> The problem the way I see it, is that there is no mechanism to deal
>> with a reboot on the codec itself.
>
> There is no reset line nor reset command on the sgtl5000.
>
>> This alsa stuff has too many layers.  At least coming from a non os
>> embedded angle it seems that way.
>
> I would suggest you to try 4.4.1 and if you still see an issue with
> the codec, then report it back to the alsa-devel at alsa-project.org
> list.


From matt at codeblueprint.co.uk  Wed Feb  3 07:19:27 2016
From: matt at codeblueprint.co.uk (Matt Fleming)
Date: Wed, 3 Feb 2016 15:19:27 +0000
Subject: [PATCH 1/3] arm64: efistub: drop __init annotation from
 handle_kernel_image()
In-Reply-To: <CAKv+Gu_rvLMFF9ssdY4GCWpdcOwaXVsaCvBTYG30NS0zw5xBWw@mail.gmail.com>
References: <1453979254-25374-1-git-send-email-ard.biesheuvel@linaro.org>
 <1453979254-25374-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160128225809.GF2571@codeblueprint.co.uk>
 <CAKv+Gu9sE4oJrFmSK8sEjTrU8A7k53Hj1S1pTyCqyA5Gsba2Kw@mail.gmail.com>
 <20160129160006.GD2611@codeblueprint.co.uk>
 <CAKv+Gu96tdf8ZrGHDi_YKacsRF_b336Nu4Anh61j4u3Lg18BHg@mail.gmail.com>
 <20160202110821.GB2642@codeblueprint.co.uk>
 <CAKv+Gu_rvLMFF9ssdY4GCWpdcOwaXVsaCvBTYG30NS0zw5xBWw@mail.gmail.com>
Message-ID: <20160203151927.GJ2597@codeblueprint.co.uk>

On Tue, 02 Feb, at 12:09:41PM, Ard Biesheuvel wrote:
> On 2 February 2016 at 12:08, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> >
> > What about,
> >
> > #define __init __compiletime_error("__init not supported in EFI boot stub")
> >
> 
> That only works for invocations, i.e., it needs to be used in header
> files, and will trigger the error if a call to the function remains
> after optimization. We want it at function definition time instead.

Good point.

OK, how about we just do the #undef, call it good, and I add the task
of printing some helpful error message to my growing TODO list?


From ard.biesheuvel at linaro.org  Wed Feb  3 07:21:07 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 3 Feb 2016 16:21:07 +0100
Subject: [PATCH 1/3] arm64: efistub: drop __init annotation from
 handle_kernel_image()
In-Reply-To: <20160203151927.GJ2597@codeblueprint.co.uk>
References: <1453979254-25374-1-git-send-email-ard.biesheuvel@linaro.org>
 <1453979254-25374-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160128225809.GF2571@codeblueprint.co.uk>
 <CAKv+Gu9sE4oJrFmSK8sEjTrU8A7k53Hj1S1pTyCqyA5Gsba2Kw@mail.gmail.com>
 <20160129160006.GD2611@codeblueprint.co.uk>
 <CAKv+Gu96tdf8ZrGHDi_YKacsRF_b336Nu4Anh61j4u3Lg18BHg@mail.gmail.com>
 <20160202110821.GB2642@codeblueprint.co.uk>
 <CAKv+Gu_rvLMFF9ssdY4GCWpdcOwaXVsaCvBTYG30NS0zw5xBWw@mail.gmail.com>
 <20160203151927.GJ2597@codeblueprint.co.uk>
Message-ID: <CAKv+Gu8A7YmwFVgHn0QEsBzr-oFpMY_5PBuqx8o+WrcogGMRng@mail.gmail.com>

On 3 February 2016 at 16:19, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> On Tue, 02 Feb, at 12:09:41PM, Ard Biesheuvel wrote:
>> On 2 February 2016 at 12:08, Matt Fleming <matt at codeblueprint.co.uk> wrote:
>> >
>> > What about,
>> >
>> > #define __init __compiletime_error("__init not supported in EFI boot stub")
>> >
>>
>> That only works for invocations, i.e., it needs to be used in header
>> files, and will trigger the error if a call to the function remains
>> after optimization. We want it at function definition time instead.
>
> Good point.
>
> OK, how about we just do the #undef, call it good, and I add the task
> of printing some helpful error message to my growing TODO list?

I take it you didn't like my #pragma then? :-)

In any case, I don't care deeply about this, so just #undef'ing it is fine by me


From peppe.cavallaro at st.com  Wed Feb  3 07:21:39 2016
From: peppe.cavallaro at st.com (Giuseppe CAVALLARO)
Date: Wed, 3 Feb 2016 16:21:39 +0100
Subject: [PATCH 0/4]  Add Ethernet support on STM32F429
In-Reply-To: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
References: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <56B21B03.507@st.com>

Hello Alex

On 2/3/2016 3:54 PM, Alexandre TORGUE wrote:
> STM32F429 Chip embeds a Synopsys 3.50a MAC IP.
> This series:
> 	-enhance current stmmac driver to control it (code already available) and
> 	 adds basic glue for STM32F429 chip.
> 	-Enable basic Net config in kernel.
>
> Note that DT patches are not present because STM32 pinctrl code is not
> yet avalaible.

patches look ok for me

Acked-by: Giuseppe Cavallaro <peppe.cavallaro at st.com>

>
> Regards
>
> Alexandre
>
> Alexandre TORGUE (4):
>    net: ethernet: dwmac: add Ethernet glue logic for stm32 chip
>    Documentation: Bindings: Add STM32 DWMAC glue
>    net: ethernet: stmmac: add support of Synopsys 3.50a MAC IP
>    ARM: STM32: Enable Ethernet in stm32_defconfig
>
>   .../devicetree/bindings/net/stm32-dwmac.txt        |  41 +++++
>   arch/arm/configs/stm32_defconfig                   |   9 ++
>   drivers/net/ethernet/stmicro/stmmac/Kconfig        |  12 ++
>   drivers/net/ethernet/stmicro/stmmac/Makefile       |   1 +
>   drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c  | 177 +++++++++++++++++++++
>   .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |   1 +
>   6 files changed, 241 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/net/stm32-dwmac.txt
>   create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
>



From james.morse at arm.com  Wed Feb  3 07:31:00 2016
From: james.morse at arm.com (James Morse)
Date: Wed, 03 Feb 2016 15:31:00 +0000
Subject: [PATCH v1 2/5] arm64: add ARMv8.2 id_aa64mmfr2 boiler plate
In-Reply-To: <56B1EEC5.9020506@arm.com>
References: <1454432611-21333-1-git-send-email-james.morse@arm.com>
 <1454432611-21333-3-git-send-email-james.morse@arm.com>
 <56B1EEC5.9020506@arm.com>
Message-ID: <56B21D34.8060106@arm.com>

Hi Suzuki,

On 03/02/16 12:12, Suzuki K. Poulose wrote:
> On 02/02/16 17:03, James Morse wrote:
>> ARMv8.2 adds a new feature register id_aa64mmfr2. This patch adds the
>> cpu feature boiler plate used by the actual features in later patches.
>>
>> Signed-off-by: James Morse <james.morse at arm.com>
> 
> 
>>   #define SYS_CNTFRQ_EL0            sys_reg(3, 3, 14, 0, 0)
>>   #define SYS_CTR_EL0            sys_reg(3, 3, 0, 0, 1)
>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>> index a84febc40db2..a4f665f95f9f 100644
>> --- a/arch/arm64/kernel/cpufeature.c
>> +++ b/arch/arm64/kernel/cpufeature.c
>> @@ -123,6 +123,10 @@ static struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
>>       ARM64_FTR_END,
>>   };
>>
>> +static struct arm64_ftr_bits ftr_id_aa64mmfr2[] = {
>> +    ARM64_FTR_END,
> 
> It will be good to see all the defined fields in id_aa64mmfr2 added here in
> this patch. You could also move the definition of UA0 field from the next patch
> to here.

Okay, what are the rules for unsupported features?

UAO support isn't added until a later patch, I assumed it was best to add the
definition as part of that patch.

> 
> Otherwise looks good.
> 
> Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>

Thanks,

James




From slash.tmp at free.fr  Wed Feb  3 07:35:10 2016
From: slash.tmp at free.fr (Mason)
Date: Wed, 3 Feb 2016 16:35:10 +0100
Subject: Plain DFS (no voltage scaling)
In-Reply-To: <20160203021052.GK31828@vireshk>
References: <56B11B67.3090600@free.fr> <20160203021052.GK31828@vireshk>
Message-ID: <56B21E2E.1070606@free.fr>

On 03/02/2016 03:10, Viresh Kumar wrote:
> On 02-02-16, 22:11, Mason wrote:
>> Hello,
>>
>> I plan to enable the on-demand governor on the tango platform:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
>>
>> I found the cpufreq-dt binding doc:
>>
>> https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
>> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
>>
>> Something is not clear to me:
>>
>> If my platform cannot scale the voltage, what information
>> should I put in the voltage part of the DT?
> 
> Wouldn't matter if there is no regulator. i.e. you should keep 0, but
> even if they have something non-zero, core code will ignore it. But
> yeah, it makes sense to keep it zero.

Hmmm, I am missing something obvious.

My config contains:

CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_COMMON=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPUFREQ_DT=y

Yet, neither dt_cpufreq_probe() nor cpufreq_init() are being called.

Could someone please point to my mistake?

Regards.



From christoffer.dall at linaro.org  Wed Feb  3 07:36:06 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 3 Feb 2016 16:36:06 +0100
Subject: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
In-Reply-To: <20160203131057.GA20217@arm.com>
References: <1453813968-2024-1-git-send-email-eric.auger@linaro.org>
 <1454017899.23148.0.camel@redhat.com> <56AB78B1.2030202@linaro.org>
 <1454096004.9301.1.camel@redhat.com> <56ABD8E0.6080409@linaro.org>
 <20160201140351.GE6828@arm.com> <20160203125047.GB13974@cbox>
 <20160203131057.GA20217@arm.com>
Message-ID: <20160203153606.GC13974@cbox>

On Wed, Feb 03, 2016 at 01:10:58PM +0000, Will Deacon wrote:
> On Wed, Feb 03, 2016 at 01:50:47PM +0100, Christoffer Dall wrote:
> > On Mon, Feb 01, 2016 at 02:03:51PM +0000, Will Deacon wrote:
> > > On Fri, Jan 29, 2016 at 10:25:52PM +0100, Eric Auger wrote:
> > > > On 01/29/2016 08:33 PM, Alex Williamson wrote:
> > > > >>> We know that x86 handles MSI vectors specially, so there is some
> > > > >>> hardware that helps the situation.  It's not just that x86 has a fixed
> > > > >>> range for MSI, it's how it manages that range when interrupt remapping
> > > > >>> hardware is enabled.  A device table indexed by source-ID references a
> > > > >>> per device table indexed by data from the MSI write itself.  So we get
> > > > >>> much, much finer granularity,
> > > > >> About the granularity, I think ARM GICv3 now provides a similar
> > > > >> capability with GICv3 ITS (interrupt translation service). Along with
> > > > >> the MSI MSG write transaction, the device outputs a DeviceID conveyed on
> > > > >> the bus. This DeviceID (~ your source-ID) enables to index a device
> > > > >> table. The entry in the device table points to a DeviceId interrupt
> > > > >> translation table indexed by the EventID found in the msi msg. So the
> > > > >> entry in the interrupt translation table eventually gives you the
> > > > >> eventual interrupt ID targeted by the MSI MSG.
> > > > >> This translation capability if not available in GICv2M though, ie. the
> > > > >> one I am currently using.
> > > > >>  
> > > > >> Those tables currently are built by the ITS irqchip (irq-gic-v3-its.c)
> > > 
> > > That's right. GICv3/ITS disambiguates the interrupt source using the
> > > DeviceID, which for PCI is derived from the Requester ID of the endpoint.
> > > GICv2m is less flexible and requires a separate physical frame per guest
> > > to achieve isolation.
> > > 
> > We should still support MSI passthrough with a single MSI frame host
> > system though, right?
> 
> I think we should treat the frame as an exclusive resource and assign it
> to a single VM.

so on a single frame GICv2m system, either your host or a single VM gets
to do MSIs...

> 
> > (Users should just be aware that guests are not fully protected against
> > misbehaving hardware in that case).
> 
> Is it confined to misbehaving hardware? What if a malicious/buggy guest
> configures its device to DMA all over the doorbell?
> 
I guess not, I suppose we can't trap any configuration access and
mediate that for any device.  Bummer.

-Christoffer


From bharat.kumar.gogada at xilinx.com  Wed Feb  3 07:40:21 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Wed, 3 Feb 2016 15:40:21 +0000
Subject: [PATCH V2 5/5] Microblaze: Modifying microblaze PCI subsytem to
 support  generic Xilinx  AXI PCIe Host Bridge IP driver
In-Reply-To: <1452620173-4905-6-git-send-email-bharatku@xilinx.com>
References: <1452620173-4905-1-git-send-email-bharatku@xilinx.com>
 <1452620173-4905-6-git-send-email-bharatku@xilinx.com>
Message-ID: <8520D5D51A55D047800579B0941471982587F02E@XAP-PVEXMBX01.xlnx.xilinx.com>

Ping
 
> This patch does required modifications to microblaze PCI subsystem, to
> work with generic driver (drivers/pci/host/pcie-xilinx.c) on Microblaze
> and Zynq.
> 
> Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
> ---
> Changes:
> Modified pcibios_fixup_bus in pci-common.c, as per generic architecuture.
> Modified pcibios_align_resource in pci-common.c, as per generic
> architecuture.
> Modified pcibios_get_phb_of_node function in pci-common.c, to remove
> dependency on struct pci_controller.
> Removed pci_domain_nr in pci-common.c, instead using generic code.
> Added pcibios_add_device in pci-common.c, as per generic architecuture.
> Adding Kernel configuration in arch/microblaze as required for generic PCI
> domains.
> Added kernel configuration for driver to support Microblaze.
> ---
>  arch/microblaze/Kconfig          |  3 ++
>  arch/microblaze/pci/pci-common.c | 61 +++++++++++++++--------------------
> -----
>  drivers/pci/host/Kconfig         |  2 +-
>  3 files changed, 27 insertions(+), 39 deletions(-)
> 
> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
> index 0bce820..c3702b9 100644
> --- a/arch/microblaze/Kconfig
> +++ b/arch/microblaze/Kconfig
> @@ -271,6 +271,9 @@ config PCI
>  config PCI_DOMAINS
>  	def_bool PCI
> 
> +config PCI_DOMAINS_GENERIC
> +	def_bool PCI_DOMAINS
> +
>  config PCI_SYSCALL
>  	def_bool PCI
> 
> diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-
> common.c
> index ae838ed..bc72856 100644
> --- a/arch/microblaze/pci/pci-common.c
> +++ b/arch/microblaze/pci/pci-common.c
> @@ -123,17 +123,6 @@ unsigned long pci_address_to_pio(phys_addr_t
> address)
>  }
>  EXPORT_SYMBOL_GPL(pci_address_to_pio);
> 
> -/*
> - * Return the domain number for this bus.
> - */
> -int pci_domain_nr(struct pci_bus *bus)
> -{
> -	struct pci_controller *hose = pci_bus_to_host(bus);
> -
> -	return hose->global_number;
> -}
> -EXPORT_SYMBOL(pci_domain_nr);
> -
>  /* This routine is meant to be used early during boot, when the
>   * PCI bus numbers have not yet been assigned, and you need to
>   * issue PCI config cycles to an OF device.
> @@ -863,26 +852,10 @@ void pcibios_setup_bus_devices(struct pci_bus
> *bus)
> 
>  void pcibios_fixup_bus(struct pci_bus *bus)
>  {
> -	/* When called from the generic PCI probe, read PCI<->PCI bridge
> -	 * bases. This is -not- called when generating the PCI tree from
> -	 * the OF device-tree.
> -	 */
> -	if (bus->self != NULL)
> -		pci_read_bridge_bases(bus);
> -
> -	/* Now fixup the bus bus */
> -	pcibios_setup_bus_self(bus);
> -
> -	/* Now fixup devices on that bus */
> -	pcibios_setup_bus_devices(bus);
> +	/* nothing to do */
>  }
>  EXPORT_SYMBOL(pcibios_fixup_bus);
> 
> -static int skip_isa_ioresource_align(struct pci_dev *dev)
> -{
> -	return 0;
> -}
> -
>  /*
>   * We need to avoid collisions with `mirrored' VGA ports
>   * and other strange ISA hardware, so we always want the
> @@ -899,20 +872,20 @@ static int skip_isa_ioresource_align(struct pci_dev
> *dev)
>  resource_size_t pcibios_align_resource(void *data, const struct resource
> *res,
>  				resource_size_t size, resource_size_t align)
>  {
> -	struct pci_dev *dev = data;
>  	resource_size_t start = res->start;
> 
> -	if (res->flags & IORESOURCE_IO) {
> -		if (skip_isa_ioresource_align(dev))
> -			return start;
> -		if (start & 0x300)
> -			start = (start + 0x3ff) & ~0x3ff;
> -	}
> -
>  	return start;
>  }
>  EXPORT_SYMBOL(pcibios_align_resource);
> 
> +int pcibios_add_device(struct pci_dev *dev)
> +{
> +	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(pcibios_add_device);
> +
>  /*
>   * Reparent resource children of pr that conflict with res
>   * under res, and make res replace those children.
> @@ -1335,9 +1308,21 @@ static void pcibios_setup_phb_resources(struct
> pci_controller *hose,
> 
>  struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)
>  {
> -	struct pci_controller *hose = bus->sysdata;
> +	struct device_node *np;
> +
> +	for_each_node_by_type(np, "pci") {
> +		const void *prop;
> +		unsigned int bus_min;
> +
> +		prop = of_get_property(np, "bus-range", NULL);
> +		if (!prop)
> +			continue;
> +		bus_min = be32_to_cpup(prop);
> +		if (bus->number == bus_min)
> +			return np;
> +	}
> 
> -	return of_node_get(hose->dn);
> +	return NULL;
>  }
> 
>  static void pcibios_scan_phb(struct pci_controller *hose)
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index d5e58ba..7c56c2e 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -79,7 +79,7 @@ config PCI_KEYSTONE
> 
>  config PCIE_XILINX
>  	bool "Xilinx AXI PCIe host bridge support"
> -	depends on ARCH_ZYNQ
> +	depends on ARCH_ZYNQ || MICROBLAZE
>  	help
>  	  Say 'Y' here if you want kernel to support the Xilinx AXI PCIe
>  	  Host Bridge driver.
> --
> 2.1.1



From vitalya at ti.com  Wed Feb  3 07:43:23 2016
From: vitalya at ti.com (Vitaly Andrianov)
Date: Wed, 3 Feb 2016 10:43:23 -0500
Subject: [PATCH 1/2] ARM: make virt_to_idmap() return unsigned long
In-Reply-To: <56B20B2E.7060408@ti.com>
References: <E1aO8F2-00074N-E8@rmk-PC.arm.linux.org.uk>
 <56A84748.3040108@oracle.com> <20160201152015.GU10826@n2100.arm.linux.org.uk>
 <56AF8F54.7030805@ti.com> <56AF917F.9030505@oracle.com>
 <56B14546.4070808@oracle.com> <56B20B2E.7060408@ti.com>
Message-ID: <56B2201B.7020205@ti.com>



On 02/03/2016 09:14 AM, Grygorii Strashko wrote:
> On 02/03/2016 02:09 AM, santosh shilimkar wrote:
>> Vitaly,
>>
>> On 2/1/2016 9:10 AM, santosh shilimkar wrote:
>>> On 2/1/2016 9:01 AM, Vitaly Andrianov wrote:
>>>>
>>>>
>>>> On 02/01/2016 10:20 AM, Russell King - ARM Linux wrote:
>>>>> On Tue, Jan 26, 2016 at 08:27:52PM -0800, santosh.shilimkar at oracle.com
>>>>> wrote:
>>>>>> On 1/26/16 10:21 AM, Russell King wrote:
>>>>>>> Make virt_to_idmap() return an unsigned long rather than phys_addr_t.
>>>>>>>
>>>>>>> Returning phys_addr_t here makes no sense, because the definition of
>>>>>>> virt_to_idmap() is that it shall return a physical address which maps
>>>>>>> identically with the virtual address.  Since virtual addresses are
>>>>>>> limited to 32-bit, identity mapped physical addresses are as well.
>>>>>>>
>>>>>>> Almost all users already had an implicit narrowing cast to unsigned
>>>>>>> long
>>>>>>> so let's make this official and part of this interface.
>>>>>>>
>>>>>>> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
>>>>>>> ---
>>>>>> Looks correct to me.
>>>>>>
>>>>>> Vitaly,
>>>>>> Could you please try out this patch and see everything continue to
>>>>>> work ?
>>>>>
>>>>> I haven't heard anything yet...  Vitaly?
>>>>>
>>>> Russel, Santosh,
>>>>
>>>> I'm not working with the latest kernel, but with the stable v4.1.y. So I
>>>> couldn't apply the patch to it. I checked out 4.5.0-rc1 and applied the
>>>> patch to it. Tried to boot and it crashed. I'm not sure either because
>>>> of the patch or because of the network driver.
>>>>
>>> Thanks for checking.
>>>
>>>> Here is the log:
>>>>
>>> Based on the log, I think the patch seems to work fine since the boot
>>> reached upto rootfs. The crash seems to be coming from mostky NetCP
>>> related compents.
>>>
>> The NETCP crash you saw could be the same one others stumbled as
>> mentioned in below thread. You can try the fix and see if the
>> crash goes away.
>>
>> http://marc.info/?l=linux-netdev&m=145445399232540&w=2
>
> 100%. I came up with absolutely similar fix.
>
>
> Regarding, kexec:
> - it seems can't be tested on ks2 out of the box, because there is unmet dependency in kconfig
>   config KEXEC
>          bool "Kexec system call (EXPERIMENTAL)"
> -       depends on (!SMP || PM_SLEEP_SMP)
>          depends on !CPU_V7M
>          select KEXEC_CORE
>          help
>
> - any way, i've hacked kernel as above;
> - downloaded and built kexec-tools
> git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.git
> - tried to run it using different combination of parameters, but always
> with below result:
> # kexec -l /boot/zImage
> kexec version: 15.12.22.16.38-g6503cb3
> Could not find a free area of memory of 0x3b2ca0 bytes...
> Cannot load /boot/zImage
>
> I'm doing something wrong, but don't know what yet :(
> - these patches were not applied, I'd like to see kexec not working first
>
>
I'm not sure about that particular issue, but when I worked on KS2 kexec 
I had to patch kexec-tools to support KS2 LPAE memory.

Regards,
Vitaly


From Suzuki.Poulose at arm.com  Wed Feb  3 07:45:24 2016
From: Suzuki.Poulose at arm.com (Suzuki K. Poulose)
Date: Wed, 3 Feb 2016 15:45:24 +0000
Subject: [PATCH v1 2/5] arm64: add ARMv8.2 id_aa64mmfr2 boiler plate
In-Reply-To: <56B21D34.8060106@arm.com>
References: <1454432611-21333-1-git-send-email-james.morse@arm.com>
 <1454432611-21333-3-git-send-email-james.morse@arm.com>
 <56B1EEC5.9020506@arm.com> <56B21D34.8060106@arm.com>
Message-ID: <56B22094.7020408@arm.com>

On 03/02/16 15:31, James Morse wrote:
> Hi Suzuki,


>>>
>>> +static struct arm64_ftr_bits ftr_id_aa64mmfr2[] = {
>>> +    ARM64_FTR_END,
>>
>> It will be good to see all the defined fields in id_aa64mmfr2 added here in
>> this patch. You could also move the definition of UA0 field from the next patch
>> to here.
>
> Okay, what are the rules for unsupported features?
>
> UAO support isn't added until a later patch, I assumed it was best to add the
> definition as part of that patch.

The table up there is also used for SANITY checks. So even if Linux doesn't use
the fields directly, the sanity checks could run on the fields and report issues which
might be problematic for the normal operation (if at all any).

Also since you are adding the information about the new register to the table,
its good to have the fields defined along with this patch to make the UAO patch
a bit more cleaner, which would make use of it eventually.


Cheers
Suzuki


From stern at rowland.harvard.edu  Wed Feb  3 07:45:34 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Wed, 3 Feb 2016 10:45:34 -0500 (EST)
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFpNRc3Nf9ofXhZrfBa54vXMxWboDScCrYFrZy97m8Y5gg@mail.gmail.com>
Message-ID: <Pine.LNX.4.44L0.1602031034360.2041-100000@iolanthe.rowland.org>

On Wed, 3 Feb 2016, Ulf Hansson wrote:

> > Let me summarize my understanding of this thread so far.
> >
> > It looks like the omap3 code initializes hardware in ->probe() and
> > then it may return -EPROBE_DEFER due to some unmet dependencies.  In
> > that case the hardware is not reset to the previous state and the
> > runtime PM framework is left in the state that corresponds to the
> > current hardware state.  Before we had pm_runtime_reinit(), everything
> > worked as expected on the second ->probe() call, because things were
> > in sync then.
> 
> Correct!
> 
> Before pm_runtime_reinit(), the failing probe case (-EPROBE_DEFER)
> worked fine because the HW state and the runtime PM status was in
> sync. The device was powered and the runtime PM status was RPM_ACTIVE.
> 
> >
> > The introduction of pm_runtime_reinit() changed the situation and now
> > effectively the hardware is required to be reset to the initial state
> > if -EPROBE_DEFER is to be returned too.
> 
> Not correct. The hardware doesn't need a reset as it stays powered
> after a failed probe.
> 
> Instead, only the runtime PM status needs to be synchronized with the
> HW state the next probe attempt.

In other words, the probe routine assumes the actual state is the same
as the PM status.  This may have been true before pm_runtime_reinit()
came along, but it's not true now.

> In other words, when the PM domain's ->runtime_resume() callbacks gets
> called due to a pm_runtime_get_sync() in the second probe attempt, it
> may find that the HW is already powered and can return zero instead of
> resetting it.

What's wrong with going ahead and resetting the hardware anyway?

Alan Stern



From stern at rowland.harvard.edu  Wed Feb  3 07:48:25 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Wed, 3 Feb 2016 10:48:25 -0500 (EST)
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160202234626.GD19432@atomide.com>
Message-ID: <Pine.LNX.4.44L0.1602031026460.2041-100000@iolanthe.rowland.org>

On Tue, 2 Feb 2016, Tony Lindgren wrote:

> * Alan Stern <stern at rowland.harvard.edu> [160202 13:46]:
> > On Tue, 2 Feb 2016, Tony Lindgren wrote:
> > 
> > > > Also, what is autosuspend_delay set to for your device?  And is 
> > > > runtime_auto set?
> > > 
> > > It's 100 at that point, see the commented snippet below from
> > > omap_hsmmc_probe():
> > > 
> > > 	pm_runtime_enable(host->dev);
> > > 	pm_runtime_get_sync(host->dev);
> > > 	pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY);
> > > 	/* NOTE: pm_runtime_dont_use_autosuspend(host->dev) needed here? */
> > > 	pm_runtime_use_autosuspend(host->dev);
> > > 	...
> > > 	/* gets -EPROBE_DEFER */
> > > err_irq:
> > > 	...
> > > 	pm_runtime_put_sync(host->dev);
> > 
> > You could try changing this to pm_runtime_put_sync_suspend().  But
> > putting pm_runtime_dont_use_autosuspend() before the put_sync seems
> > like a perfectly reasonable thing to do, especially if you feel you
> > should reverse all the changes you made at the start.
> 
> They both seem to fix the problem.

So you could use either one.  In my opinion, the 
pm_runtime_dont_use_autosuspend() solution is a little cleaner.

> > The reinit function gets called too late to do what you want -- namely, 
> > put the hardware in a low-power state.
> 
> Right, the problem is the lack of suspend on the first probe. But
> for having autosuspend timeout long enough for the next probe
> would mean that we can't reset the PM runtime state in between.

That's one way to look at it.  But in principle you don't need to
suspend the device after an unsuccessful probe.  You can just leave it
at high power.  If this causes problems for a second probe, it's the 
second probe's own fault for assuming the actual state matches the PM 
status.

> > pm_runtime_put_sync() is supposed to follow the driver's wishes.  It
> > invokes the driver's runtime_idle callback if there is one, and the
> > callback routine can start a suspend or an autosuspend.  If there is no
> > callback, it will use whatever autosuspend setting the driver has set
> > up.  If you want to override the autosuspend setting, use
> > pm_runtime_put_sync_suspend() instead.
> 
> Yes.. That works too. I guess the thing to consider is if we should
> make pm_runtime_put_sync() always sync along the lines of a patch
> I posted earlier today. That could avoid quite a bit of confusion
> as already seen in this thread :)

As Rafael pointed out, pm_runtime_put_sync() has well-documented 
behavior.  It shouldn't be changed.  I don't see how changing the 
behavior would reduce anybody's confusion.  At least, anybody who reads 
the documentation carefully.

Alan Stern



From robh at kernel.org  Wed Feb  3 07:48:31 2016
From: robh at kernel.org (Rob Herring)
Date: Wed, 3 Feb 2016 09:48:31 -0600
Subject: [PATCH V5 10/14] Documentation: DT: bindings: Add power domain
 info for NVIDIA PMC
In-Reply-To: <56B1DE40.7080403@nvidia.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-11-git-send-email-jonathanh@nvidia.com>
 <20160129160625.GA21918@rob-hp-laptop>
 <56B1DE40.7080403@nvidia.com>
Message-ID: <CAL_JsqLcoKW2znNNvM=sYLmZ6O6ZWqn7+aXspkXoONw6-O1ygg@mail.gmail.com>

On Wed, Feb 3, 2016 at 5:02 AM, Jon Hunter <jonathanh at nvidia.com> wrote:
>
> On 29/01/16 16:06, Rob Herring wrote:
>> On Thu, Jan 28, 2016 at 04:33:48PM +0000, Jon Hunter wrote:
>>> Add power-domain binding documentation for the NVIDIA PMC driver in
>>> order to support generic power-domains.
>>>
>>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
>>> ---
>>>  .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      | 55 ++++++++++++++++++++++
>>>  1 file changed, 55 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>>> index 53aa5496c5cf..3c77373aa826 100644
>>> --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>>> +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>>> @@ -1,5 +1,7 @@
>>>  NVIDIA Tegra Power Management Controller (PMC)
>>>
>>> +== Power Management Controller Node ==
>>> +
>>>  The PMC block interacts with an external Power Management Unit. The PMC
>>>  mostly controls the entry and exit of the system from different sleep
>>>  modes. It provides power-gating controllers for SoC and CPU power-islands.
>>> @@ -70,6 +72,10 @@ Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'
>>>                       Defaults to 0. Valid values are described in section 12.5.2
>>>                       "Pinmux Support" of the Tegra4 Technical Reference Manual.
>>>
>>> +Optional nodes:
>>> +- powergates : This node contains a hierarchy of power domain nodes, which
>>> +           should match the powergates on the Tegra SoC.
>>> +
>>>  Example:
>>>
>>>  / SoC dts including file
>>> @@ -115,3 +121,52 @@ pmc at 7000f400 {
>>>      };
>>>      ...
>>>  };
>>> +
>>> +
>>> +== PM Domain Nodes ==
>>> +
>>> +Each of the PM domain nodes represents a power-domain on the Tegra SoC
>>> +that can be power-gated by the PMC and should be named appropriately.
>>> +
>>> +Required properties:
>>> +  - clocks: Must contain an entry for each clock required by the PMC for
>>> +    controlling a power-gate. See ../clocks/clock-bindings.txt for details.
>>> +  - resets: Must contain an entry for each reset required by the PMC for
>>> +    controlling a power-gate. See ../reset/reset.txt for details.
>>> +  - nvidia,powergate: Integer cell that contains an identifier for the PMC
>>> +    power-gate that is associated with the power-domain. Please refer to
>>> +    the Tegra TRM for more details.
>>
>> Why not make this value be the power-domain cell for consumers and the
>> pmc be the phandle.
>
> Is there anything wrong with using a label for the consumers? Seems
> simpler, if you can just say ...
>
>         adma: adma at 702e2000 {
>                 ...
>                 power-domains = <&pd_audio>;
>                 ...
>         };

Only that is a bit unusual. It would only really matter if we had some
common parsing that we wanted to share. I'd look at other examples and
try to align. If there's no clear pattern, then it is fine.

>> Then use reg property for the subnodes. That avoids a custom property.
>
> That is fine with me.
>
> Jon


From mathieu.poirier at linaro.org  Wed Feb  3 07:58:58 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 3 Feb 2016 08:58:58 -0700
Subject: [PATCH V5 05/14] soc: tegra: pmc: Wait for powergate state to
 change
In-Reply-To: <56B1C647.4060504@nvidia.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-6-git-send-email-jonathanh@nvidia.com>
 <CANLsYkycbEo+wyMX8RJ9H-S5kDTjQR4nnDZc5gvf2kShOZAv9w@mail.gmail.com>
 <56AF613A.1000909@nvidia.com> <56B1C647.4060504@nvidia.com>
Message-ID: <CANLsYkyPj+ExhBFffokvtMcZ-OWocMc0Hx3_nfVgRu=uUVvJfg@mail.gmail.com>

On 3 February 2016 at 02:20, Jon Hunter <jonathanh at nvidia.com> wrote:
>
> On 01/02/16 13:44, Jon Hunter wrote:
>>
>> On 29/01/16 16:58, Mathieu Poirier wrote:
>>> On 28 January 2016 at 09:33, Jon Hunter <jonathanh at nvidia.com> wrote:
>>>> Currently, the function tegra_powergate_set() simply sets the desired
>>>> powergate state but does not wait for the state to change. In most cases
>>>> we should wait for the state to change before proceeding. Currently, there
>>>> is a case for tegra114 and tegra124 devices where we do not wait when
>>>> starting the secondary CPU as this is not necessary. However, this is only
>>>> done at boot time and so waiting here will only have a small impact on
>>>> boot time. Therefore, update tegra_powergate_set() to wait when setting
>>>> the powergate.
>>>>
>>>> By adding this feature, we can also eliminate the polling loop from
>>>> tegra30_boot_secondary().
>>>>
>>>> A function has been added for checking the status of the powergate and
>>>> so update the tegra_powergate_is_powered() to use this macro as well.
>>>>
>>>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
>>>> ---
>>>>  arch/arm/mach-tegra/platsmp.c | 16 +++-------------
>>>>  drivers/soc/tegra/pmc.c       |  9 ++++++++-
>>>>  2 files changed, 11 insertions(+), 14 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
>>>> index f3f61dbbda97..75620ae73913 100644
>>>> --- a/arch/arm/mach-tegra/platsmp.c
>>>> +++ b/arch/arm/mach-tegra/platsmp.c
>>>> @@ -108,19 +108,9 @@ static int tegra30_boot_secondary(unsigned int cpu, struct task_struct *idle)
>>>>          * be un-gated by un-toggling the power gate register
>>>>          * manually.
>>>>          */
>>>> -       if (!tegra_pmc_cpu_is_powered(cpu)) {
>>>> -               ret = tegra_pmc_cpu_power_on(cpu);
>>>> -               if (ret)
>>>> -                       return ret;
>>>> -
>>>> -               /* Wait for the power to come up. */
>>>> -               timeout = jiffies + msecs_to_jiffies(100);
>>>> -               while (!tegra_pmc_cpu_is_powered(cpu)) {
>>>> -                       if (time_after(jiffies, timeout))
>>>> -                               return -ETIMEDOUT;
>>>> -                       udelay(10);
>>>> -               }
>>>> -       }
>>>> +       ret = tegra_pmc_cpu_power_on(cpu);
>>>> +       if (ret)
>>>> +               return ret;
>>>>
>>>>  remove_clamps:
>>>>         /* CPU partition is powered. Enable the CPU clock. */
>>>> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
>>>> index 99cb2fdd29e1..35ee60fd17be 100644
>>>> --- a/drivers/soc/tegra/pmc.c
>>>> +++ b/drivers/soc/tegra/pmc.c
>>>> @@ -28,6 +28,7 @@
>>>>  #include <linux/export.h>
>>>>  #include <linux/init.h>
>>>>  #include <linux/io.h>
>>>> +#include <linux/iopoll.h>
>>>>  #include <linux/of.h>
>>>>  #include <linux/of_address.h>
>>>>  #include <linux/platform_device.h>
>>>> @@ -186,6 +187,9 @@ static inline bool tegra_powergate_state(int id)
>>>>   */
>>>>  static int tegra_powergate_set(unsigned int id, bool new_state)
>>>>  {
>>>> +       bool status;
>>>> +       int err;
>>>> +
>>>>         mutex_lock(&pmc->powergates_lock);
>>>>
>>>>         if (tegra_powergate_state(id) == new_state) {
>>>> @@ -195,9 +199,12 @@ static int tegra_powergate_set(unsigned int id, bool new_state)
>>>>
>>>>         tegra_pmc_writel(PWRGATE_TOGGLE_START | id, PWRGATE_TOGGLE);
>>>>
>>>> +       err = readx_poll_timeout(tegra_powergate_state, id, status,
>>>> +                                status == new_state, 10, 100000);
>>>> +
>>>
>>> I understand (and agree) with the goal of this patch but I wonder (and
>>> I don't know much about the system/context) if holding a mutex while
>>> sleeping won't incur adverse effect on other parts of the system that
>>> weren't use to see this wait.  One way to fix this might be to use
>>> "mutex_trylock()" and let callers retry as they see fit if an
>>> operation is already in progress.
>>
>> I could unlock the mutex after writing the TOGGLE_START register. I
>> don't believe that we need to waiting for a powergate to change before
>> writing again.
>
> I was not thinking clearly here, the whole reason for the locking is to
> protect the base address as we swap it during the probe.
>
> In general, I prefer to keep it the way we have it in this patch. By
> using mutex_trylock() would mean that now clients would have to handle
> retrying if they cannot get the lock and make it more complex.

Yes, the complexity is indeed pushed to the caller but that way we
know exactly what is going on.  Another way to implement this without
any locks at all would be through RCUs.  I'll let Stephen and Thierry
make the call here.

Thanks,
Mahtieu

> Powergates should not be turned on and off that frequently and so
> hopefully a delay here should be tolerable. For CPUs, this should only
> be used on cold boot and not during CPU hotplug events.
>
> Cheers
> Jon


From helgaas at kernel.org  Wed Feb  3 07:59:20 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Wed, 3 Feb 2016 09:59:20 -0600
Subject: [PATCH V2 5/5] Microblaze: Modifying microblaze PCI subsytem to
 support  generic Xilinx  AXI PCIe Host Bridge IP driver
In-Reply-To: <8520D5D51A55D047800579B0941471982587F02E@XAP-PVEXMBX01.xlnx.xilinx.com>
References: <1452620173-4905-1-git-send-email-bharatku@xilinx.com>
 <1452620173-4905-6-git-send-email-bharatku@xilinx.com>
 <8520D5D51A55D047800579B0941471982587F02E@XAP-PVEXMBX01.xlnx.xilinx.com>
Message-ID: <20160203155920.GB32546@localhost>

Hi Bharat,

On Wed, Feb 03, 2016 at 03:40:21PM +0000, Bharat Kumar Gogada wrote:
> Ping

You said you were going to do another revision, so I'm waiting for r3.

> > This patch does required modifications to microblaze PCI subsystem, to
> > work with generic driver (drivers/pci/host/pcie-xilinx.c) on Microblaze
> > and Zynq.
> > 
> > Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> > Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
> > ---
> > Changes:
> > Modified pcibios_fixup_bus in pci-common.c, as per generic architecuture.
> > Modified pcibios_align_resource in pci-common.c, as per generic
> > architecuture.
> > Modified pcibios_get_phb_of_node function in pci-common.c, to remove
> > dependency on struct pci_controller.
> > Removed pci_domain_nr in pci-common.c, instead using generic code.
> > Added pcibios_add_device in pci-common.c, as per generic architecuture.
> > Adding Kernel configuration in arch/microblaze as required for generic PCI
> > domains.
> > Added kernel configuration for driver to support Microblaze.
> > ---
> >  arch/microblaze/Kconfig          |  3 ++
> >  arch/microblaze/pci/pci-common.c | 61 +++++++++++++++--------------------
> > -----
> >  drivers/pci/host/Kconfig         |  2 +-
> >  3 files changed, 27 insertions(+), 39 deletions(-)
> > 
> > diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
> > index 0bce820..c3702b9 100644
> > --- a/arch/microblaze/Kconfig
> > +++ b/arch/microblaze/Kconfig
> > @@ -271,6 +271,9 @@ config PCI
> >  config PCI_DOMAINS
> >  	def_bool PCI
> > 
> > +config PCI_DOMAINS_GENERIC
> > +	def_bool PCI_DOMAINS
> > +
> >  config PCI_SYSCALL
> >  	def_bool PCI
> > 
> > diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-
> > common.c
> > index ae838ed..bc72856 100644
> > --- a/arch/microblaze/pci/pci-common.c
> > +++ b/arch/microblaze/pci/pci-common.c
> > @@ -123,17 +123,6 @@ unsigned long pci_address_to_pio(phys_addr_t
> > address)
> >  }
> >  EXPORT_SYMBOL_GPL(pci_address_to_pio);
> > 
> > -/*
> > - * Return the domain number for this bus.
> > - */
> > -int pci_domain_nr(struct pci_bus *bus)
> > -{
> > -	struct pci_controller *hose = pci_bus_to_host(bus);
> > -
> > -	return hose->global_number;
> > -}
> > -EXPORT_SYMBOL(pci_domain_nr);
> > -
> >  /* This routine is meant to be used early during boot, when the
> >   * PCI bus numbers have not yet been assigned, and you need to
> >   * issue PCI config cycles to an OF device.
> > @@ -863,26 +852,10 @@ void pcibios_setup_bus_devices(struct pci_bus
> > *bus)
> > 
> >  void pcibios_fixup_bus(struct pci_bus *bus)
> >  {
> > -	/* When called from the generic PCI probe, read PCI<->PCI bridge
> > -	 * bases. This is -not- called when generating the PCI tree from
> > -	 * the OF device-tree.
> > -	 */
> > -	if (bus->self != NULL)
> > -		pci_read_bridge_bases(bus);
> > -
> > -	/* Now fixup the bus bus */
> > -	pcibios_setup_bus_self(bus);
> > -
> > -	/* Now fixup devices on that bus */
> > -	pcibios_setup_bus_devices(bus);
> > +	/* nothing to do */
> >  }
> >  EXPORT_SYMBOL(pcibios_fixup_bus);
> > 
> > -static int skip_isa_ioresource_align(struct pci_dev *dev)
> > -{
> > -	return 0;
> > -}
> > -
> >  /*
> >   * We need to avoid collisions with `mirrored' VGA ports
> >   * and other strange ISA hardware, so we always want the
> > @@ -899,20 +872,20 @@ static int skip_isa_ioresource_align(struct pci_dev
> > *dev)
> >  resource_size_t pcibios_align_resource(void *data, const struct resource
> > *res,
> >  				resource_size_t size, resource_size_t align)
> >  {
> > -	struct pci_dev *dev = data;
> >  	resource_size_t start = res->start;
> > 
> > -	if (res->flags & IORESOURCE_IO) {
> > -		if (skip_isa_ioresource_align(dev))
> > -			return start;
> > -		if (start & 0x300)
> > -			start = (start + 0x3ff) & ~0x3ff;
> > -	}
> > -
> >  	return start;
> >  }
> >  EXPORT_SYMBOL(pcibios_align_resource);
> > 
> > +int pcibios_add_device(struct pci_dev *dev)
> > +{
> > +	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(pcibios_add_device);
> > +
> >  /*
> >   * Reparent resource children of pr that conflict with res
> >   * under res, and make res replace those children.
> > @@ -1335,9 +1308,21 @@ static void pcibios_setup_phb_resources(struct
> > pci_controller *hose,
> > 
> >  struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)
> >  {
> > -	struct pci_controller *hose = bus->sysdata;
> > +	struct device_node *np;
> > +
> > +	for_each_node_by_type(np, "pci") {
> > +		const void *prop;
> > +		unsigned int bus_min;
> > +
> > +		prop = of_get_property(np, "bus-range", NULL);
> > +		if (!prop)
> > +			continue;
> > +		bus_min = be32_to_cpup(prop);
> > +		if (bus->number == bus_min)
> > +			return np;
> > +	}
> > 
> > -	return of_node_get(hose->dn);
> > +	return NULL;
> >  }
> > 
> >  static void pcibios_scan_phb(struct pci_controller *hose)
> > diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> > index d5e58ba..7c56c2e 100644
> > --- a/drivers/pci/host/Kconfig
> > +++ b/drivers/pci/host/Kconfig
> > @@ -79,7 +79,7 @@ config PCI_KEYSTONE
> > 
> >  config PCIE_XILINX
> >  	bool "Xilinx AXI PCIe host bridge support"
> > -	depends on ARCH_ZYNQ
> > +	depends on ARCH_ZYNQ || MICROBLAZE
> >  	help
> >  	  Say 'Y' here if you want kernel to support the Xilinx AXI PCIe
> >  	  Host Bridge driver.
> > --
> > 2.1.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From gregory.clement at free-electrons.com  Wed Feb  3 07:58:46 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed, 03 Feb 2016 16:58:46 +0100
Subject: [PATCH 01/10] serial: mvebu-uart: initial support for Armada-3700
 serial port
In-Reply-To: <20160202181935.19b4ab7e@lxorguk.ukuu.org.uk> (One Thousand
 Gnomes's message of "Tue, 2 Feb 2016 18:19:35 +0000")
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
 <20160202181935.19b4ab7e@lxorguk.ukuu.org.uk>
Message-ID: <87vb654wg9.fsf@free-electrons.com>

Hi,
 
 On mar., f?vr. 02 2016, One Thousand Gnomes <gnomes at lxorguk.ukuu.org.uk> wrote:

>> +static void mvebu_uart_set_termios(struct uart_port *port,
>> +				   struct ktermios *termios,
>> +				   struct ktermios *old)
>> +{
>> +	unsigned long flags;
>> +	unsigned int baud;
>> +
>> +	spin_lock_irqsave(&port->lock, flags);
>> +
>> +	port->read_status_mask = STAT_RX_RDY | STAT_OVR_ERR |
>> +		STAT_TX_RDY | STAT_TX_FIFO_FUL;
>> +
>> +	if (termios->c_iflag & INPCK)
>> +		port->read_status_mask |= STAT_FRM_ERR | STAT_PAR_ERR;
>> +
>> +	port->ignore_status_mask = 0;
>> +	if (termios->c_iflag & IGNPAR)
>> +		port->ignore_status_mask |=
>> +			STAT_FRM_ERR | STAT_PAR_ERR | STAT_OVR_ERR;
>> +
>> +	if ((termios->c_cflag & CREAD) == 0)
>> +		port->ignore_status_mask |= STAT_RX_RDY | STAT_BRK_ERR;
>
> If you don't support parity or charactive size then you should be forcing
> those bits in the tty->termios so that the caller sees what settings they
> get. tty_termios_copy_hw is close to what you need except that you can
> support IGNPAR.

OK thanks for the pointer.

>
> You also want to provide the actual baud rate chosen (see how 8250.c does
> it using tty_termios_encode_baud_rate().
>
>
>> +static struct uart_driver mvebu_uart_driver = {
>> +	.owner			= THIS_MODULE,
>> +	.driver_name		= "serial",
>> +	.dev_name		= "ttyS",
>> +	.major			= TTY_MAJOR,
>> +	.minor			= 64,
>
> NAK
>
> TTY_MAJOR 64+ is the 8250 driver and ttyS is the 8250 driver name. You
> should be using a dynamic major (0) for all new drivers and you need to
> pick a different and unused ttyXXX format name.

I missed this one, I will remove .major and .minor and use our own
ttyXX.

Thanks,

Gregory

>
> Alan

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From ezequiel at vanguardiasur.com.ar  Wed Feb  3 08:03:19 2016
From: ezequiel at vanguardiasur.com.ar (Ezequiel Garcia)
Date: Wed, 3 Feb 2016 13:03:19 -0300
Subject: [PATCH 1/2] clocksource/drivers/lpc32xx: Support periodic mode
In-Reply-To: <CAGhQ9VxtqkW4PLrpQWsyZu9bgB_98mmO=WZ7gvaeN_DWQ5M3rg@mail.gmail.com>
References: <1454136379-7517-1-git-send-email-ezequiel@vanguardiasur.com.ar>
 <CAGhQ9VxO7Rsus8Js_oZDBxWzEHuUHnRyoVTVmawbtXmK7tNMcw@mail.gmail.com>
 <CAAEAJfAVTJm-PzhjkRmkdNG39sH7eHyEXaSX4q0=TCQ0468Heg@mail.gmail.com>
 <CAAEAJfD8LUV=t97RN3U4uqgzCLP89AQtHqBccKGd6-EskP9DOQ@mail.gmail.com>
 <CAGhQ9VxtqkW4PLrpQWsyZu9bgB_98mmO=WZ7gvaeN_DWQ5M3rg@mail.gmail.com>
Message-ID: <CAAEAJfBO5jARMZyu62ccRWjA_A69qfBfHBcWncYbqOdPkYqSMQ@mail.gmail.com>

Hi Joachim,

(Ccing Vladimir)

On 1 February 2016 at 18:55, Joachim  Eastwood <manabian at gmail.com> wrote:
> On 1 February 2016 at 16:09, Ezequiel Garcia
> <ezequiel at vanguardiasur.com.ar> wrote:
>> On 31 January 2016 at 17:07, Ezequiel Garcia
>> <ezequiel at vanguardiasur.com.ar> wrote:
>>> On 30 January 2016 at 16:39, Joachim  Eastwood <manabian at gmail.com> wrote:
>>>> Hi Ezequiel,
>>>>
>>>> On 30 January 2016 at 07:46, Ezequiel Garcia
>>>> <ezequiel at vanguardiasur.com.ar> wrote:
>>>>> This commit adds the support for periodic mode. This is done by not
>>>>> setting the MR0S (Stop on TnMR0) bit on MCR, thus allowing
>>>>> interrupts to be periodically generated on MR0 matches.
>>>>>
>>>>> In order to do this, move the initial configuration that is specific to
>>>>> the one shot mode to clock_event_device.set_state_oneshot.
>>>>>
>> [...]
>>>
>>>>
>>>> I will look more closely at the new timer setup later.
>>>>
>>>> btw, didn't I look through a version of this you sent me privately
>>>> quite some time ago?
>>>> I think I had a comment about using TIMER_PR instead of TIMER_MR0
>>>> then. Unsure if that is still valid, though.
>>>>
>>>
>>> Ah, right. It was ages ago, and forgot your previous review. Sorry about that.
>>> Using TIMER_PR looks less invasive so I'll send a v2 using it instead.
>>
>> Actually, using the prescale counter and MR0 = 1 resulted in exactly
>> half the number of interrupts that I expected (HZ / 2). Using this
>> patch, with PR=0 and MR0=ticks_per_jiggies, I can see HZ no. of
>> interrupts per sec.
>>
>> Why did you choose to use the prescale in your oneshot implementation?
>
> The clockevent code was copied from arch/arm/mach-lpc32xx/timer.c so
> it's really old code.
> I think it is a strange way to use the timer, but the logic still
> seems good to me.
>
>> Did you test or measure the timer expire using the PR and MR0 = 1?
>
> I really can't remember. I do remember going through the timer setup
> and it seemed like a valid, albeit slightly strange, way to use the
> timer.
>
>> To be honest, I'm still trying to make some sense out of my results.
>
> I'll see if can find the time to do some more testing over here as well.
>

I wrote a small test driver to toggle a GPIO on a timer event.
One-shot usage of the timers results in the same measurements
with either implementation.

In other words, when triggering a one-shot timer (MCR_MR0S is set),
I get the same results using the prescale counter (PR=ticks, MR0=1)
or the timer counter (PR=0, MR0=ticks).

Here's the branch in case you want to play with it:
http://git.infradead.org/users/ezequielg/linux/shortlog/refs/heads/misc_timer_test

My logic analyzer is quite crappy, but it was clear that one-shot timers
expired correctly at the configured time, with either implementation.

However, when configuring the timer in periodic mode (MCR_MR0S
is cleared), the result is always ~twice the programmed value
(as if it takes two TC cycles to complete one event).

Hence, it seems the prescale counter is not suitable for periodic mode.

How about we change the current oneshot implementation
to not use the prescale counter at all, and so when the periodic
mode is introduced it'll be consistent with oneshot?

(Tested on LPC4350 Hitex Devkit, no idea how this works on LPC32xx)
-- 
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar


From bharat.kumar.gogada at xilinx.com  Wed Feb  3 08:08:58 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Wed, 3 Feb 2016 16:08:58 +0000
Subject: [PATCH V2 5/5] Microblaze: Modifying microblaze PCI subsytem to
 support  generic Xilinx  AXI PCIe Host Bridge IP driver
In-Reply-To: <20160203155920.GB32546@localhost>
References: <1452620173-4905-1-git-send-email-bharatku@xilinx.com>
 <1452620173-4905-6-git-send-email-bharatku@xilinx.com>
 <8520D5D51A55D047800579B0941471982587F02E@XAP-PVEXMBX01.xlnx.xilinx.com>
 <20160203155920.GB32546@localhost>
Message-ID: <8520D5D51A55D047800579B0941471982587F05F@XAP-PVEXMBX01.xlnx.xilinx.com>

> You said you were going to do another revision, so I'm waiting for r3.
Hi Bjorn, 
Do you have any comments on this patch (5/5), I will address other patches comments along with this patch, if any, in v3.

Bharat
> 
> > > This patch does required modifications to microblaze PCI subsystem,
> > > to work with generic driver (drivers/pci/host/pcie-xilinx.c) on
> > > Microblaze and Zynq.
> > >
> > > Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> > > Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
> > > ---
> > > Changes:
> > > Modified pcibios_fixup_bus in pci-common.c, as per generic
> architecuture.
> > > Modified pcibios_align_resource in pci-common.c, as per generic
> > > architecuture.
> > > Modified pcibios_get_phb_of_node function in pci-common.c, to
> remove
> > > dependency on struct pci_controller.
> > > Removed pci_domain_nr in pci-common.c, instead using generic code.
> > > Added pcibios_add_device in pci-common.c, as per generic
> architecuture.
> > > Adding Kernel configuration in arch/microblaze as required for
> > > generic PCI domains.
> > > Added kernel configuration for driver to support Microblaze.
> > > ---
> > >  arch/microblaze/Kconfig          |  3 ++
> > >  arch/microblaze/pci/pci-common.c | 61
> > > +++++++++++++++--------------------
> > > -----
> > >  drivers/pci/host/Kconfig         |  2 +-
> > >  3 files changed, 27 insertions(+), 39 deletions(-)
> > >
> > > diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig index
> > > 0bce820..c3702b9 100644
> > > --- a/arch/microblaze/Kconfig
> > > +++ b/arch/microblaze/Kconfig
> > > @@ -271,6 +271,9 @@ config PCI
> > >  config PCI_DOMAINS
> > >  	def_bool PCI
> > >
> > > +config PCI_DOMAINS_GENERIC
> > > +	def_bool PCI_DOMAINS
> > > +
> > >  config PCI_SYSCALL
> > >  	def_bool PCI
> > >
> > > diff --git a/arch/microblaze/pci/pci-common.c
> > > b/arch/microblaze/pci/pci- common.c index ae838ed..bc72856 100644
> > > --- a/arch/microblaze/pci/pci-common.c
> > > +++ b/arch/microblaze/pci/pci-common.c
> > > @@ -123,17 +123,6 @@ unsigned long pci_address_to_pio(phys_addr_t
> > > address)
> > >  }
> > >  EXPORT_SYMBOL_GPL(pci_address_to_pio);
> > >
> > > -/*
> > > - * Return the domain number for this bus.
> > > - */
> > > -int pci_domain_nr(struct pci_bus *bus) -{
> > > -	struct pci_controller *hose = pci_bus_to_host(bus);
> > > -
> > > -	return hose->global_number;
> > > -}
> > > -EXPORT_SYMBOL(pci_domain_nr);
> > > -
> > >  /* This routine is meant to be used early during boot, when the
> > >   * PCI bus numbers have not yet been assigned, and you need to
> > >   * issue PCI config cycles to an OF device.
> > > @@ -863,26 +852,10 @@ void pcibios_setup_bus_devices(struct pci_bus
> > > *bus)
> > >
> > >  void pcibios_fixup_bus(struct pci_bus *bus)  {
> > > -	/* When called from the generic PCI probe, read PCI<->PCI bridge
> > > -	 * bases. This is -not- called when generating the PCI tree from
> > > -	 * the OF device-tree.
> > > -	 */
> > > -	if (bus->self != NULL)
> > > -		pci_read_bridge_bases(bus);
> > > -
> > > -	/* Now fixup the bus bus */
> > > -	pcibios_setup_bus_self(bus);
> > > -
> > > -	/* Now fixup devices on that bus */
> > > -	pcibios_setup_bus_devices(bus);
> > > +	/* nothing to do */
> > >  }
> > >  EXPORT_SYMBOL(pcibios_fixup_bus);
> > >
> > > -static int skip_isa_ioresource_align(struct pci_dev *dev) -{
> > > -	return 0;
> > > -}
> > > -
> > >  /*
> > >   * We need to avoid collisions with `mirrored' VGA ports
> > >   * and other strange ISA hardware, so we always want the @@ -899,20
> > > +872,20 @@ static int skip_isa_ioresource_align(struct pci_dev
> > > *dev)
> > >  resource_size_t pcibios_align_resource(void *data, const struct
> > > resource *res,
> > >  				resource_size_t size, resource_size_t align)  {
> > > -	struct pci_dev *dev = data;
> > >  	resource_size_t start = res->start;
> > >
> > > -	if (res->flags & IORESOURCE_IO) {
> > > -		if (skip_isa_ioresource_align(dev))
> > > -			return start;
> > > -		if (start & 0x300)
> > > -			start = (start + 0x3ff) & ~0x3ff;
> > > -	}
> > > -
> > >  	return start;
> > >  }
> > >  EXPORT_SYMBOL(pcibios_align_resource);
> > >
> > > +int pcibios_add_device(struct pci_dev *dev) {
> > > +	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > > +
> > > +	return 0;
> > > +}
> > > +EXPORT_SYMBOL(pcibios_add_device);
> > > +
> > >  /*
> > >   * Reparent resource children of pr that conflict with res
> > >   * under res, and make res replace those children.
> > > @@ -1335,9 +1308,21 @@ static void
> > > pcibios_setup_phb_resources(struct
> > > pci_controller *hose,
> > >
> > >  struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)  {
> > > -	struct pci_controller *hose = bus->sysdata;
> > > +	struct device_node *np;
> > > +
> > > +	for_each_node_by_type(np, "pci") {
> > > +		const void *prop;
> > > +		unsigned int bus_min;
> > > +
> > > +		prop = of_get_property(np, "bus-range", NULL);
> > > +		if (!prop)
> > > +			continue;
> > > +		bus_min = be32_to_cpup(prop);
> > > +		if (bus->number == bus_min)
> > > +			return np;
> > > +	}
> > >
> > > -	return of_node_get(hose->dn);
> > > +	return NULL;
> > >  }
> > >
> > >  static void pcibios_scan_phb(struct pci_controller *hose) diff
> > > --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index
> > > d5e58ba..7c56c2e 100644
> > > --- a/drivers/pci/host/Kconfig
> > > +++ b/drivers/pci/host/Kconfig
> > > @@ -79,7 +79,7 @@ config PCI_KEYSTONE
> > >
> > >  config PCIE_XILINX
> > >  	bool "Xilinx AXI PCIe host bridge support"
> > > -	depends on ARCH_ZYNQ
> > > +	depends on ARCH_ZYNQ || MICROBLAZE
> > >  	help
> > >  	  Say 'Y' here if you want kernel to support the Xilinx AXI PCIe
> > >  	  Host Bridge driver.
> > > --
> > > 2.1.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci"
> > in the body of a message to majordomo at vger.kernel.org More
> majordomo
> > info at  http://vger.kernel.org/majordomo-info.html


From tony at atomide.com  Wed Feb  3 08:09:51 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Feb 2016 08:09:51 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <Pine.LNX.4.44L0.1602031034360.2041-100000@iolanthe.rowland.org>
References: <CAPDyKFpNRc3Nf9ofXhZrfBa54vXMxWboDScCrYFrZy97m8Y5gg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602031034360.2041-100000@iolanthe.rowland.org>
Message-ID: <20160203160951.GF19432@atomide.com>

* Alan Stern <stern at rowland.harvard.edu> [160203 07:46]:
> On Wed, 3 Feb 2016, Ulf Hansson wrote:
> 
> > > Let me summarize my understanding of this thread so far.
> > >
> > > It looks like the omap3 code initializes hardware in ->probe() and
> > > then it may return -EPROBE_DEFER due to some unmet dependencies.  In
> > > that case the hardware is not reset to the previous state and the
> > > runtime PM framework is left in the state that corresponds to the
> > > current hardware state.  Before we had pm_runtime_reinit(), everything
> > > worked as expected on the second ->probe() call, because things were
> > > in sync then.
> > 
> > Correct!

Well not quite correct. After failed probe PM runtime is set to reset
state while hardware is still enabled.

> > Before pm_runtime_reinit(), the failing probe case (-EPROBE_DEFER)
> > worked fine because the HW state and the runtime PM status was in
> > sync. The device was powered and the runtime PM status was RPM_ACTIVE.
> > 
> > >
> > > The introduction of pm_runtime_reinit() changed the situation and now
> > > effectively the hardware is required to be reset to the initial state
> > > if -EPROBE_DEFER is to be returned too.
> > 
> > Not correct. The hardware doesn't need a reset as it stays powered
> > after a failed probe.

It is really best to disable the hardware after a failed probe
like we do with pm_runtime_put_sync_(suspend)() and pm_runtime_disable().

This is because there may never be another probe attempt and we want
to have unclaimed devices shut off (or idled) for PM.

> > Instead, only the runtime PM status needs to be synchronized with the
> > HW state the next probe attempt.
>
> In other words, the probe routine assumes the actual state is the same
> as the PM status.  This may have been true before pm_runtime_reinit()
> came along, but it's not true now.
> 
> > In other words, when the PM domain's ->runtime_resume() callbacks gets
> > called due to a pm_runtime_get_sync() in the second probe attempt, it
> > may find that the HW is already powered and can return zero instead of
> > resetting it.

Certainly that should at least produce a warning in the hardware
specific implementation. It's a state mismatch between PM runtime
and the hardware specific implementation.

And as discussed, the problem does not exist as long as we understand
that we need to use pm_runtime_put_sync_suspend() if the driver has
set pm_runtime_use_autoidle(). Or else use the combination of
pm_runtime_dont_use_autoidle() and pm_runtime_put_sync().

> What's wrong with going ahead and resetting the hardware anyway?

Nothing, unless a state needs to be maintained for things like GPIO
pins power memory :)

Regards,

Tony


From mathieu.poirier at linaro.org  Wed Feb  3 08:11:57 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 3 Feb 2016 09:11:57 -0700
Subject: [PATCH V8 23/23] perf tools: adding coresight etm PMU record
 capabilities
In-Reply-To: <20160202164129.GE32488@kernel.org>
References: <1452807977-8069-1-git-send-email-mathieu.poirier@linaro.org>
 <1452807977-8069-24-git-send-email-mathieu.poirier@linaro.org>
 <CANLsYkyBCFyu3Q-3jet-6rNfa3vGzWWQ3_m+PNf4Z+n6OxsscA@mail.gmail.com>
 <20160125211048.GE22501@kernel.org> <56AB4027.2070208@intel.com>
 <CANLsYkyFSjLmT_i7ANE2VL21Y+Nud13SvjOd1akV-e9hQcTcHA@mail.gmail.com>
 <20160129211208.GB32225@kernel.org>
 <CANLsYkxwtqHyoQ7+Z4a+qJfTV_ZWc72_mJh12FHxVEhNYKsgjw@mail.gmail.com>
 <CANLsYkysvVKoaxKJu9TYLAGJaZj9=9gMN+O6NpcDLztJNrgy+w@mail.gmail.com>
 <20160202164129.GE32488@kernel.org>
Message-ID: <CANLsYkwtT7VbLJaW+jsC+X0151znDsu6rLio4f5Fg-dyY2xJtQ@mail.gmail.com>

On 2 February 2016 at 09:41, Arnaldo Carvalho de Melo <acme at kernel.org> wrote:
> Em Tue, Feb 02, 2016 at 09:20:51AM -0700, Mathieu Poirier escreveu:
>> [...]
>>
>> >>> >
>> >>> > Looks OK, apart from adding linux/coresight-pmu.h to the manifest, but I
>> >>> > mentioned that on another patch.
>> >>> >
>> >>> > However there is no decoder, which begs the question, is there anything you
>> >>> > can actually do with the perf.data file?  Might be a bit confusing for users
>> >>> > if they can capture traces but not use perf tools on the resulting perf.data
>> >>> > file?
>> >>>
>> >>> We are working on a decoding library in parallel to this work.
>> >>
>> >> Would be nice to be able to get both in the same patch kit, no? So that
>> >> one can both record and process the traces, verifying it all works.
>> >
>> > We are still a few weeks away from being in a position where the
>> > community can start playing with the decoding library.  I can hold off
>> > on the "perf tools" patches when I queue the kernel side of the work
>> > for 4.6 but since you and Adrian have already reviewed the work it
>> > would be nice to have that part included as well.
>> >
>> > We've been playing with the perf.data files for a couple of months now
>> > and things look at the right place.  This isn't surprising since we
>> > are using the same framework as X86.
>> >
>> > I think the generation of the perf.data file should be coupled with
>> > the submission of the kernel driver but would also respect a diverging
>> > point of view.  Simply let me know what you prefer and I will adjust
>> > V9 accordingly.
>>
>> Arnaldo,
>>
>> I'm preparing V9 at this time - what's your view on the above?
>
> I'd say go with something we can test, i.e. if we generate a perf.data
> file we can't then process to figure out if what was inserted is right,
> how can we decide if it is ok?

Very well - I'll hold off on the perf tools patches for now.  We can
make a submission of all the user space components when things are in
a working order.

Mathieu

>
> Otherwise please describe how you test it, preferably by having this in
> the commit log, i.e. if you decide that using plain 'perf report -D' is
> enough, state that and show the output, etc.
>
> - Arnaldo


From viresh.kumar at linaro.org  Wed Feb  3 08:13:31 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Wed, 3 Feb 2016 21:43:31 +0530
Subject: Plain DFS (no voltage scaling)
In-Reply-To: <56B217C9.1050405@free.fr>
References: <56B11B67.3090600@free.fr>
 <56B217C9.1050405@free.fr>
Message-ID: <20160203161331.GI3469@vireshk>

On 03-02-16, 16:07, Mason wrote:
> On 02/02/2016 22:11, Mason wrote:
> 
> > I plan to enable the on-demand governor on the tango platform:
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
> > 
> > I found the cpufreq-dt binding doc:
> > 
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
> > 
> > Something is not clear to me:
> > 
> > If my platform cannot scale the voltage, what information
> > should I put in the voltage part of the DT?
> 
> Someone pointed out that tweaking the frequency without tweaking
> the voltage might be counter-productive.
> 
> I measured the power consumption of the entire board (at the power outlet)
> for 3 CPU frequencies (all other things being equal, I hope).
> 
> idle @ 111 MHz = 4.6 W
> idle @ 333 MHz = 4.6 W
> idle @ 999 MHz = 4.6 W
> 
> load @ 111 MHz = 5.0 W
> load @ 333 MHz = 5.7 W
> load @ 999 MHz = 7.7 W
> 
> When idle, the kernel calls WFI, which "turns off" most of the CPU
> (clock gating?) such that the actual frequency does not matter.
> 
> At full load (I use cpuburn to jog as many FUs simultaneously as
> possible) it looks like each additional MHz requires ~3 mW.
> 
> So it would appear that an on-demand governor might not help to
> save power.

Why do you say so ?

> But I have another use-case in mind: CPU throttling on over-heating.
> There's a temperature sensor in the CPU, and I'd like to say:
> "if temperature exceeds a user-set threshold, don't run at the max
> frequency until the temperature becomes reasonable".
> 
> And I think that requires cpufreq?
> 
> Regards.

-- 
viresh


From viresh.kumar at linaro.org  Wed Feb  3 08:14:28 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Wed, 3 Feb 2016 21:44:28 +0530
Subject: Plain DFS (no voltage scaling)
In-Reply-To: <56B21E2E.1070606@free.fr>
References: <56B11B67.3090600@free.fr> <20160203021052.GK31828@vireshk>
 <56B21E2E.1070606@free.fr>
Message-ID: <20160203161428.GJ3469@vireshk>

On 03-02-16, 16:35, Mason wrote:
> On 03/02/2016 03:10, Viresh Kumar wrote:
> > On 02-02-16, 22:11, Mason wrote:
> >> Hello,
> >>
> >> I plan to enable the on-demand governor on the tango platform:
> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
> >>
> >> I found the cpufreq-dt binding doc:
> >>
> >> https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
> >> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
> >>
> >> Something is not clear to me:
> >>
> >> If my platform cannot scale the voltage, what information
> >> should I put in the voltage part of the DT?
> > 
> > Wouldn't matter if there is no regulator. i.e. you should keep 0, but
> > even if they have something non-zero, core code will ignore it. But
> > yeah, it makes sense to keep it zero.
> 
> Hmmm, I am missing something obvious.
> 
> My config contains:
> 
> CONFIG_CPU_FREQ=y
> CONFIG_CPU_FREQ_GOV_COMMON=y
> CONFIG_CPU_FREQ_STAT=y
> CONFIG_CPU_FREQ_STAT_DETAILS=y
> CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
> CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
> CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> CONFIG_CPUFREQ_DT=y
> 
> Yet, neither dt_cpufreq_probe() nor cpufreq_init() are being called.
> 
> Could someone please point to my mistake?

You need to create a platform device to get cpufreq-dt driver probed.
Check other users..

-- 
viresh


From catalin.marinas at arm.com  Wed Feb  3 08:18:36 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 3 Feb 2016 16:18:36 +0000
Subject: [PATCH v3] ARM64: kernel: implement ACPI parking protocol
In-Reply-To: <20160203112112.GA18387@red-moon>
References: <1453806638-23167-1-git-send-email-lorenzo.pieralisi@arm.com>
 <20160202182657.GC15706@e104818-lin.cambridge.arm.com>
 <20160203112112.GA18387@red-moon>
Message-ID: <20160203161834.GB26487@MBP.local>

On Wed, Feb 03, 2016 at 11:21:12AM +0000, Lorenzo Pieralisi wrote:
> On Tue, Feb 02, 2016 at 06:26:58PM +0000, Catalin Marinas wrote:
> > On Tue, Jan 26, 2016 at 11:10:38AM +0000, Lorenzo Pieralisi wrote:
> > > The SBBR and ACPI specifications allow ACPI based systems that do not
> > > implement PSCI (eg systems with no EL3) to boot through the ACPI parking
> > > protocol specification[1].
> > > 
> > > This patch implements the ACPI parking protocol CPU operations, and adds
> > > code that eases parsing the parking protocol data structures to the
> > > ARM64 SMP initializion carried out at the same time as cpus enumeration.
> > > 
> > > To wake-up the CPUs from the parked state, this patch implements a
> > > wakeup IPI for ARM64 (ie arch_send_wakeup_ipi_mask()) that mirrors the
> > > ARM one, so that a specific IPI is sent for wake-up purpose in order
> > > to distinguish it from other IPI sources.
> > > 
> > > Given the current ACPI MADT parsing API, the patch implements a glue
> > > layer that helps passing MADT GICC data structure from SMP initialization
> > > code to the parking protocol implementation somewhat overriding the CPU
> > > operations interfaces. This to avoid creating a completely trasparent
> > > DT/ACPI CPU operations layer that would require creating opaque
> > > structure handling for CPUs data (DT represents CPU through DT nodes, ACPI
> > > through static MADT table entries), which seems overkill given that ACPI
> > > on ARM64 mandates only two booting protocols (PSCI and parking protocol),
> > > so there is no need for further protocol additions.
> > > 
> > > Based on the original work by Mark Salter <msalter at redhat.com>
> > > 
> > > [1] https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.docx
> > > 
> > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > > Cc: Will Deacon <will.deacon at arm.com>
> > > Cc: Hanjun Guo <hanjun.guo at linaro.org>
> > > Cc: Loc Ho <lho at apm.com>
> > > Cc: Sudeep Holla <sudeep.holla at arm.com>
> > > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > > Cc: Mark Rutland <mark.rutland at arm.com>
> > > Cc: Mark Salter <msalter at redhat.com>
> > > Cc: Al Stone <ahs3 at redhat.com>
> > 
> > Applied, with a minor addition just to warn people from not using it in
> > other configurations (#ifdef still needed otherwise the
> > acpi_parking_protocol_valid symbol is not available; but I prefer uglier
> > code than people starting to use this IPI in their firmware):
> 
> It makes sense, we could include asm/acpi.h in smp.c (which is not
> included by linux/acpi.h if !CONFIG_ACPI) to pull in the symbol and
> remove the ifdef if you think it is cleaner.

I don't think it's worth.

BTW, the acpi_parking_protocol_valid() definition has an __init
annotation while the declaration does not. I removed the __init
altogether since I get a section mismatch warning when being called from
handle_IPI.

-- 
Catalin


From ulf.hansson at linaro.org  Wed Feb  3 08:24:55 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Wed, 3 Feb 2016 17:24:55 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160203160951.GF19432@atomide.com>
References: <CAPDyKFpNRc3Nf9ofXhZrfBa54vXMxWboDScCrYFrZy97m8Y5gg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602031034360.2041-100000@iolanthe.rowland.org>
 <20160203160951.GF19432@atomide.com>
Message-ID: <CAPDyKFoNY8xP11n6mFVicYwdy49sB4=H0fTm53754HukFX4HBQ@mail.gmail.com>

On 3 February 2016 at 17:09, Tony Lindgren <tony at atomide.com> wrote:
> * Alan Stern <stern at rowland.harvard.edu> [160203 07:46]:
>> On Wed, 3 Feb 2016, Ulf Hansson wrote:
>>
>> > > Let me summarize my understanding of this thread so far.
>> > >
>> > > It looks like the omap3 code initializes hardware in ->probe() and
>> > > then it may return -EPROBE_DEFER due to some unmet dependencies.  In
>> > > that case the hardware is not reset to the previous state and the
>> > > runtime PM framework is left in the state that corresponds to the
>> > > current hardware state.  Before we had pm_runtime_reinit(), everything
>> > > worked as expected on the second ->probe() call, because things were
>> > > in sync then.
>> >
>> > Correct!
>
> Well not quite correct. After failed probe PM runtime is set to reset
> state while hardware is still enabled.

Yes, but that's *after* pm_runtime_reinit() was added.

I think Rafael was thinking about how it worked *before*.

>
>> > Before pm_runtime_reinit(), the failing probe case (-EPROBE_DEFER)
>> > worked fine because the HW state and the runtime PM status was in
>> > sync. The device was powered and the runtime PM status was RPM_ACTIVE.
>> >
>> > >
>> > > The introduction of pm_runtime_reinit() changed the situation and now
>> > > effectively the hardware is required to be reset to the initial state
>> > > if -EPROBE_DEFER is to be returned too.
>> >
>> > Not correct. The hardware doesn't need a reset as it stays powered
>> > after a failed probe.
>
> It is really best to disable the hardware after a failed probe
> like we do with pm_runtime_put_sync_(suspend)() and pm_runtime_disable().
>
> This is because there may never be another probe attempt and we want
> to have unclaimed devices shut off (or idled) for PM.

I totally agree!

>
>> > Instead, only the runtime PM status needs to be synchronized with the
>> > HW state the next probe attempt.
>>
>> In other words, the probe routine assumes the actual state is the same
>> as the PM status.  This may have been true before pm_runtime_reinit()
>> came along, but it's not true now.
>>
>> > In other words, when the PM domain's ->runtime_resume() callbacks gets
>> > called due to a pm_runtime_get_sync() in the second probe attempt, it
>> > may find that the HW is already powered and can return zero instead of
>> > resetting it.
>
> Certainly that should at least produce a warning in the hardware
> specific implementation. It's a state mismatch between PM runtime
> and the hardware specific implementation.
>
> And as discussed, the problem does not exist as long as we understand
> that we need to use pm_runtime_put_sync_suspend() if the driver has
> set pm_runtime_use_autoidle(). Or else use the combination of
> pm_runtime_dont_use_autoidle() and pm_runtime_put_sync().

Okay, so I understand that you decided to not pick up the omap hwmod
patch I posted.

If you want some further help in fixing the omap drivers, please just
tell me I am at your service. :-)

Also, we must not forget to also update their runtime PM calls in
their ->remove() callbacks, as those seems to suffer from the same
problem as in the -EPROBE_DEFER case.

>
>> What's wrong with going ahead and resetting the hardware anyway?
>
> Nothing, unless a state needs to be maintained for things like GPIO
> pins power memory :)
>
> Regards,
>
> Tony

Kind regards
Uffe


From tony at atomide.com  Wed Feb  3 08:27:06 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Feb 2016 08:27:06 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFqLi8xOUeoxUTAmif5QrOjVpV_2CDLv4hjO_C9iOnv+5Q@mail.gmail.com>
References: <20160201232833.GR19432@atomide.com>
 <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>
 <20160202030533.GT19432@atomide.com>
 <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>
 <20160202163536.GU19432@atomide.com>
 <CAPDyKFosQjkHDVSvy67+hstjjFseXQP5WYXrJE19GgVFYJ099w@mail.gmail.com>
 <20160202234145.GC19432@atomide.com>
 <CAPDyKFqLi8xOUeoxUTAmif5QrOjVpV_2CDLv4hjO_C9iOnv+5Q@mail.gmail.com>
Message-ID: <20160203162705.GG19432@atomide.com>

* Ulf Hansson <ulf.hansson at linaro.org> [160203 02:24]:
> On 3 February 2016 at 00:41, Tony Lindgren <tony at atomide.com> wrote:
>
> > Well we actually pretty much have devices in that state to start
> > with.
> 
> That's not true, not even for omap.
> 
> There are definitely devices which HW state is reflected by RPM_ACTIVE
> at boot. It's the responsible of the subsystem/driver (including PM
> domains) to make sure the runtime PM status is updated accordingly, to
> reflect the real HW state.
> 
> For omap hwmod, at device registration in omap_device_build_from_dt()
> it may actually invoke pm_runtime_set_active() if the device is
> enabled. To my understanding, that's done to synchronize the real HW
> state with the runtime PM status, right?

Sure we do have cases where the bootloader state needs to be
preserved for some devices. Like GPIO pin state to power memory on
some devices! :)

> >> To me, it's the responsible of the PM domain to *help* with the
> >> synchronization, not prevent it as it currently does.
> >
> > The problem is that the hardware state gets out of sync with
> > PM runtime. And that's going to be a pain to debug later on.
> 
> I don't see the problem, but of course you know omap for better than I do.

Well there's also the long term maintenance aspect at least I
need to consider.

> So if you are concerned about this, perhaps adding a dev_dbg print
> when the omap hwmod's ->runtime_suspend() callback returns zero could
> be a way forward?

If we downgrade it to a debug statement or a warning, we'll soon end
up with even more driver specific warnings than we already have.
And I don't want to be chasing people around to fix their drivers
for eavery new driver that gets submitted.

Also, without this error I would not even originally have noticed we
have a problem :) So I suggest the following:

1. I'll do a series of patches to fix up the handful of omap
   specific drivers with pm_runtime_use_autosuspend() that depend
   on omap_device

2. I'll also do a patch to improve the omap_device error message
   so new drivers are easy to fix. Something like:

  "%() called from invalid state %d, use pm_runtime_put_sync_suspend()?"

Does that sounds OK to you?

Regards,

Tony


From helgaas at kernel.org  Wed Feb  3 08:32:07 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Wed, 3 Feb 2016 10:32:07 -0600
Subject: [PATCH V2 5/5] Microblaze: Modifying microblaze PCI subsytem to
 support  generic Xilinx  AXI PCIe Host Bridge IP driver
In-Reply-To: <1452620173-4905-6-git-send-email-bharatku@xilinx.com>
References: <1452620173-4905-1-git-send-email-bharatku@xilinx.com>
 <1452620173-4905-6-git-send-email-bharatku@xilinx.com>
Message-ID: <20160203163207.GC32546@localhost>

[+cc Ben, pcibios_get_phb_of_node() question]

On Tue, Jan 12, 2016 at 11:06:13PM +0530, Bharat Kumar Gogada wrote:
> This patch does required modifications to microblaze PCI subsystem, to
> work with generic driver (drivers/pci/host/pcie-xilinx.c) on Microblaze
> and Zynq.
> 
> Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
>...

>  resource_size_t pcibios_align_resource(void *data, const struct resource *res,
>  				resource_size_t size, resource_size_t align)
>  {
> -	struct pci_dev *dev = data;
>  	resource_size_t start = res->start;
>  
> -	if (res->flags & IORESOURCE_IO) {
> -		if (skip_isa_ioresource_align(dev))
> -			return start;
> -		if (start & 0x300)
> -			start = (start + 0x3ff) & ~0x3ff;
> -	}
> -
>  	return start;

"return res->start;" is sufficient; no need for a temporary variable.

>  }
>  EXPORT_SYMBOL(pcibios_align_resource);
>  
> +int pcibios_add_device(struct pci_dev *dev)
> +{
> +	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(pcibios_add_device);
> +
>  /*
>   * Reparent resource children of pr that conflict with res
>   * under res, and make res replace those children.
> @@ -1335,9 +1308,21 @@ static void pcibios_setup_phb_resources(struct pci_controller *hose,
>  
>  struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)
>  {
> -	struct pci_controller *hose = bus->sysdata;
> +	struct device_node *np;
> +
> +	for_each_node_by_type(np, "pci") {
> +		const void *prop;
> +		unsigned int bus_min;
> +
> +		prop = of_get_property(np, "bus-range", NULL);
> +		if (!prop)
> +			continue;
> +		bus_min = be32_to_cpup(prop);
> +		if (bus->number == bus_min)
> +			return np;
> +	}
>  
> -	return of_node_get(hose->dn);
> +	return NULL;

Hmmm.  The old microblaze code ("return of_node_get(hose->dn);") is
basically the same as the mips and powerpc versions.  The new code is
basically the same as the x86 version.

I like the generic weak version in drivers/pci/of.c because it doesn't
use any arch-specific data, and it looks like if we just set the
struct device.of_node members correctly, everything should Just Work.

But Ben added both the generic and the x86 versions the same day, so
there must be some complication:

  98d9f30c820d ("pci/of: Match PCI devices to OF nodes dynamically")
  3d5fe5a65af9 ("x86/devicetree: Use generic PCI <-> OF matching")

So I guess my question is, why do we need a microblaze-specific
version at all?

Bjorn


From gregory.clement at free-electrons.com  Wed Feb  3 08:32:41 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed, 03 Feb 2016 17:32:41 +0100
Subject: [PATCH 01/10] serial: mvebu-uart: initial support for Armada-3700
 serial port
In-Reply-To: <20160202182842.GD29778@leverpostej> (Mark Rutland's message of
 "Tue, 2 Feb 2016 18:28:42 +0000")
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
 <20160202182842.GD29778@leverpostej>
Message-ID: <87r3gt4uvq.fsf@free-electrons.com>

Hi Mark,
 
 On mar., f?vr. 02 2016, Mark Rutland <mark.rutland at arm.com> wrote:

> On Tue, Feb 02, 2016 at 07:07:39PM +0100, Gregory CLEMENT wrote:
>> From: Wilson Ding <dingwei at marvell.com>
>> 
>> Armada-3700's uart is a simple serial port, which doesn't
>> support. Configuring the modem control lines. The uart port has a 32
>> bytes Tx FIFO and a 64 bytes Rx FIFO
>> 
>> The uart driver implements the uart core operations. It also support the
>> system (early) console based on Armada-3700's serial port.
>> 
>> Known Issue:
>> 
>> The uart driver currently doesn't support clock programming, which means
>> the baud-rate stays with the default value configured by the bootloader
>> at boot time
>
> To ensure that the bootloader and kernel match, it's best to place the
> rate in the stdout-path property (as in
> Documentation/devicetree/bindings/chosen.txt).
>
> Presumably that is what you want?

It is done in patch 7.

>
> Is it difficutl to add clock programming?

Currently there is no clock tree support before adding it I would like
to be able to test it.

Thanks,

Gregory

>
>> 
>> [gregory.clement at free-electrons.com: Rewrite many part which are too long
>> to enumerate]
>> 
>> Signed-off-by: Wilson Ding <dingwei at marvell.com>
>> Signed-off-by: Nadav Haklai <nadavh at marvell.com>
>> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
>> ---
>>  .../devicetree/bindings/tty/serial/mvebu-uart.txt  |  13 +
>>  Documentation/kernel-parameters.txt                |   6 +
>>  drivers/tty/serial/Kconfig                         |  22 +
>>  drivers/tty/serial/Makefile                        |   1 +
>>  drivers/tty/serial/mvebu-uart.c                    | 649 +++++++++++++++++++++
>>  include/uapi/linux/serial_core.h                   |   3 +
>>  6 files changed, 694 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
>>  create mode 100644 drivers/tty/serial/mvebu-uart.c
>> 
>> diff --git a/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
>> new file mode 100644
>> index 000000000000..6087defd9f93
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
>> @@ -0,0 +1,13 @@
>> +* Marvell UART : Non standard UART used in some of Marvell EBU SoCs (e.g., Armada-3700)
>> +
>> +Required properties:
>> +- compatible: "marvell,armada-3700-uart"
>> +- reg: offset and length of the register set for the device.
>> +- interrupts: device interrupt
>> +
>> +Example:
>> +	serial at 12000 {
>> +		compatible = "marvell,armada-3700-uart";
>> +		reg = <0x12000 0x400>;
>> +		interrupts = <43>;
>> +	};
>
> There are no external clock inputs?
>
>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>> index 87d40a72f6a1..198f6bd56e84 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -1058,6 +1058,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>>  			A valid base address must be provided, and the serial
>>  			port must already be setup and configured.
>>  
>> +		mvebu_uart,<addr>
>> +			Start an early, polled-mode console on an some mvebu
>> +			SoC (as the Armada-3700) serial port at the specified
>> +			address. The serial port must already be setup and
>> +			configured. Options are not yet supported.
>> +
>
> Does the the mvebu UART vary between platforms at all?
>
> Thanks,
> Mark.

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From tony at atomide.com  Wed Feb  3 08:36:04 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Feb 2016 08:36:04 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAJZ5v0jbOJc2m=cBrvAuMUHvY8_AQPdJEyt1w-dPikU5expeLA@mail.gmail.com>
References: <20160202210345.GZ19432@atomide.com>
 <Pine.LNX.4.44L0.1602021626540.1653-100000@iolanthe.rowland.org>
 <20160202234626.GD19432@atomide.com>
 <CAJZ5v0jbOJc2m=cBrvAuMUHvY8_AQPdJEyt1w-dPikU5expeLA@mail.gmail.com>
Message-ID: <20160203163604.GH19432@atomide.com>

* Rafael J. Wysocki <rafael at kernel.org> [160203 05:07]:
> On Wed, Feb 3, 2016 at 12:46 AM, Tony Lindgren <tony at atomide.com> wrote:
> >
> > Yes.. That works too. I guess the thing to consider is if we should
> > make pm_runtime_put_sync() always sync along the lines of a patch
> > I posted earlier today. That could avoid quite a bit of confusion
> > as already seen in this thread :)
> 
> No, we shouldn't.
> 
> As I said, the current behavior is actually well documented (in
> kerneldoc comments and elsewhere).

OK. I'll do a series of fixes to the drivers using omap_device.

Regards,

Tony


From gregory.clement at free-electrons.com  Wed Feb  3 08:36:01 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed, 03 Feb 2016 17:36:01 +0100
Subject: [PATCH 01/10] serial: mvebu-uart: initial support for Armada-3700
 serial port
In-Reply-To: <5687888.WDl8xbENFR@wuerfel> (Arnd Bergmann's message of "Tue, 02
 Feb 2016 22:07:17 +0100")
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
 <5687888.WDl8xbENFR@wuerfel>
Message-ID: <87mvrh4uq6.fsf@free-electrons.com>

Hi Arnd,
 
 On mar., f?vr. 02 2016, Arnd Bergmann <arnd at arndb.de> wrote:

> On Tuesday 02 February 2016 19:07:39 Gregory CLEMENT wrote:
>
>> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>> index 39721ec4f415..b291f934d51b 100644
>> --- a/drivers/tty/serial/Kconfig
>> +++ b/drivers/tty/serial/Kconfig
>> @@ -1606,6 +1606,28 @@ config SERIAL_STM32_CONSOLE
>>  	depends on SERIAL_STM32=y
>>  	select SERIAL_CORE_CONSOLE
>>  
>> +config SERIAL_MVEBU_UART
>> +	bool "Marvell EBU serial port support"
>
> Could this be a loadable module?

I don't see any reason to not being able to use it as a module. But I
didn't test it because currently te serial port is the only way ro
cimmunicate with the board.

>
>> +config SERIAL_MVEBU_CONSOLE
>> +	bool "Console on Marvell EBU serial port"
>> +	depends on SERIAL_MVEBU_UART
>
> If yes, this would become 
>
> 	depends on SERIAL_MVEBU_UART=y

OK, let's try to enable it.

Thanks,

Gregory

>
> 	Arnd
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From tony at atomide.com  Wed Feb  3 08:37:49 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Feb 2016 08:37:49 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <Pine.LNX.4.44L0.1602031026460.2041-100000@iolanthe.rowland.org>
References: <20160202234626.GD19432@atomide.com>
 <Pine.LNX.4.44L0.1602031026460.2041-100000@iolanthe.rowland.org>
Message-ID: <20160203163749.GI19432@atomide.com>

* Alan Stern <stern at rowland.harvard.edu> [160203 07:49]:
> On Tue, 2 Feb 2016, Tony Lindgren wrote:
> 
> > * Alan Stern <stern at rowland.harvard.edu> [160202 13:46]:
> > > On Tue, 2 Feb 2016, Tony Lindgren wrote:
> > > 
> > > > > Also, what is autosuspend_delay set to for your device?  And is 
> > > > > runtime_auto set?
> > > > 
> > > > It's 100 at that point, see the commented snippet below from
> > > > omap_hsmmc_probe():
> > > > 
> > > > 	pm_runtime_enable(host->dev);
> > > > 	pm_runtime_get_sync(host->dev);
> > > > 	pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY);
> > > > 	/* NOTE: pm_runtime_dont_use_autosuspend(host->dev) needed here? */
> > > > 	pm_runtime_use_autosuspend(host->dev);
> > > > 	...
> > > > 	/* gets -EPROBE_DEFER */
> > > > err_irq:
> > > > 	...
> > > > 	pm_runtime_put_sync(host->dev);
> > > 
> > > You could try changing this to pm_runtime_put_sync_suspend().  But
> > > putting pm_runtime_dont_use_autosuspend() before the put_sync seems
> > > like a perfectly reasonable thing to do, especially if you feel you
> > > should reverse all the changes you made at the start.
> > 
> > They both seem to fix the problem.
> 
> So you could use either one.  In my opinion, the 
> pm_runtime_dont_use_autosuspend() solution is a little cleaner.
> 
> > > The reinit function gets called too late to do what you want -- namely, 
> > > put the hardware in a low-power state.
> > 
> > Right, the problem is the lack of suspend on the first probe. But
> > for having autosuspend timeout long enough for the next probe
> > would mean that we can't reset the PM runtime state in between.
> 
> That's one way to look at it.  But in principle you don't need to
> suspend the device after an unsuccessful probe.  You can just leave it
> at high power.  If this causes problems for a second probe, it's the 
> second probe's own fault for assuming the actual state matches the PM 
> status.

Yes. And I can improve the warning for omap_device so the authors
for new drivers can easily fix the issue.

> > > pm_runtime_put_sync() is supposed to follow the driver's wishes.  It
> > > invokes the driver's runtime_idle callback if there is one, and the
> > > callback routine can start a suspend or an autosuspend.  If there is no
> > > callback, it will use whatever autosuspend setting the driver has set
> > > up.  If you want to override the autosuspend setting, use
> > > pm_runtime_put_sync_suspend() instead.
> > 
> > Yes.. That works too. I guess the thing to consider is if we should
> > make pm_runtime_put_sync() always sync along the lines of a patch
> > I posted earlier today. That could avoid quite a bit of confusion
> > as already seen in this thread :)
> 
> As Rafael pointed out, pm_runtime_put_sync() has well-documented 
> behavior.  It shouldn't be changed.  I don't see how changing the 
> behavior would reduce anybody's confusion.  At least, anybody who reads 
> the documentation carefully.

Right :)

Tony


From helgaas at kernel.org  Wed Feb  3 08:38:05 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Wed, 3 Feb 2016 10:38:05 -0600
Subject: [PATCH V2 5/5] Microblaze: Modifying microblaze PCI subsytem to
 support  generic Xilinx  AXI PCIe Host Bridge IP driver
In-Reply-To: <20160203163207.GC32546@localhost>
References: <1452620173-4905-1-git-send-email-bharatku@xilinx.com>
 <1452620173-4905-6-git-send-email-bharatku@xilinx.com>
 <20160203163207.GC32546@localhost>
Message-ID: <20160203163805.GA6112@localhost>

[+cc Ben for real this time]

On Wed, Feb 03, 2016 at 10:32:07AM -0600, Bjorn Helgaas wrote:
> [+cc Ben, pcibios_get_phb_of_node() question]
> 
> On Tue, Jan 12, 2016 at 11:06:13PM +0530, Bharat Kumar Gogada wrote:
> > This patch does required modifications to microblaze PCI subsystem, to
> > work with generic driver (drivers/pci/host/pcie-xilinx.c) on Microblaze
> > and Zynq.
> > 
> > Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> > Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
> >...
> 
> >  resource_size_t pcibios_align_resource(void *data, const struct resource *res,
> >  				resource_size_t size, resource_size_t align)
> >  {
> > -	struct pci_dev *dev = data;
> >  	resource_size_t start = res->start;
> >  
> > -	if (res->flags & IORESOURCE_IO) {
> > -		if (skip_isa_ioresource_align(dev))
> > -			return start;
> > -		if (start & 0x300)
> > -			start = (start + 0x3ff) & ~0x3ff;
> > -	}
> > -
> >  	return start;
> 
> "return res->start;" is sufficient; no need for a temporary variable.
> 
> >  }
> >  EXPORT_SYMBOL(pcibios_align_resource);
> >  
> > +int pcibios_add_device(struct pci_dev *dev)
> > +{
> > +	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(pcibios_add_device);
> > +
> >  /*
> >   * Reparent resource children of pr that conflict with res
> >   * under res, and make res replace those children.
> > @@ -1335,9 +1308,21 @@ static void pcibios_setup_phb_resources(struct pci_controller *hose,
> >  
> >  struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)
> >  {
> > -	struct pci_controller *hose = bus->sysdata;
> > +	struct device_node *np;
> > +
> > +	for_each_node_by_type(np, "pci") {
> > +		const void *prop;
> > +		unsigned int bus_min;
> > +
> > +		prop = of_get_property(np, "bus-range", NULL);
> > +		if (!prop)
> > +			continue;
> > +		bus_min = be32_to_cpup(prop);
> > +		if (bus->number == bus_min)
> > +			return np;
> > +	}
> >  
> > -	return of_node_get(hose->dn);
> > +	return NULL;
> 
> Hmmm.  The old microblaze code ("return of_node_get(hose->dn);") is
> basically the same as the mips and powerpc versions.  The new code is
> basically the same as the x86 version.
> 
> I like the generic weak version in drivers/pci/of.c because it doesn't
> use any arch-specific data, and it looks like if we just set the
> struct device.of_node members correctly, everything should Just Work.
> 
> But Ben added both the generic and the x86 versions the same day, so
> there must be some complication:
> 
>   98d9f30c820d ("pci/of: Match PCI devices to OF nodes dynamically")
>   3d5fe5a65af9 ("x86/devicetree: Use generic PCI <-> OF matching")
> 
> So I guess my question is, why do we need a microblaze-specific
> version at all?
> 
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From sam at ravnborg.org  Wed Feb  3 08:39:46 2016
From: sam at ravnborg.org (Sam Ravnborg)
Date: Wed, 3 Feb 2016 17:39:46 +0100
Subject: [PATCH] [RFC] ARM: modify pgd_t definition for
 TRANSPARENT_HUGEPAGE_PUD
In-Reply-To: <1773775.QWf7OyDGPh@wuerfel>
References: <1773775.QWf7OyDGPh@wuerfel>
Message-ID: <20160203163946.GA20360@ravnborg.org>

On Wed, Feb 03, 2016 at 02:21:48PM +0100, Arnd Bergmann wrote:
> I ran into build errors on ARM after Willy's newly added generic
> TRANSPARENT_HUGEPAGE_PUD support. We don't support this feature
> on ARM at all, but the patch causes a build error anyway:
> 
> In file included from ../kernel/memremap.c:17:0:
> ../include/linux/pfn_t.h:108:7: error: 'pud_mkdevmap' declared as function returning an array
>  pud_t pud_mkdevmap(pud_t pud);
> 
> We don't use a PUD on ARM, so pud_t is defined as pmd_t, which
> in turn is defined as
> 
> typedef unsigned long pgd_t[2];
> 
> on NOMMU and on 2-level MMU configurations. There is an (unused)
> other definition using a struct around the array, which happens to
> work fine here.
> 
> There is a comment in the file about the fact the other version
> is "easier on the compiler", and I've traced that version back
> to linux-2.1.80 when ARM support was first merged back in 1998.
> 
> It's probably a safe assumption that this is no longer necessary:
> The same logic existed in asm-i386 at the time but was removed
> a year later in 2.3.23pre3. The STRICT_MM_TYPECHECKS logic
> also ended up getting copied into these files:
> 
> arch/alpha/include/asm/page.h
> arch/arc/include/asm/page.h
> arch/arm/include/asm/pgtable-3level-types.h
> arch/arm64/include/asm/pgtable-types.h
> arch/ia64/include/asm/page.h
> arch/parisc/include/asm/page.h
> arch/powerpc/include/asm/page.h
> arch/sparc/include/asm/page_32.h
> arch/sparc/include/asm/page_64.h

For the sparc32 case we use the simpler variants.
According to the comment this is due to limitation in
the way we pass arguments in the sparc32 ABI.
But I have not tried to compare a kernel for sparc32 with
and without the use of structs.

For sparc64 we use the stricter types (structs).
I did not check other architectures - but just wanted to
tell that the right choice may be architecture dependent.

	Sam


From gregory.clement at free-electrons.com  Wed Feb  3 08:43:59 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed, 03 Feb 2016 17:43:59 +0100
Subject: [PATCH 01/10] serial: mvebu-uart: initial support for Armada-3700
 serial port
In-Reply-To: <CAPv3WKfGX2dVDu2zWG4gdEMf0vO-X+NMerh9PzNDjzLBDSQcUA@mail.gmail.com>
 (Marcin Wojtas's message of "Wed, 3 Feb 2016 09:05:55 +0100")
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
 <CAPv3WKfGX2dVDu2zWG4gdEMf0vO-X+NMerh9PzNDjzLBDSQcUA@mail.gmail.com>
Message-ID: <87io254ucw.fsf@free-electrons.com>

Hi Marcin,
 
 On mer., f?vr. 03 2016, Marcin Wojtas <mw at semihalf.com> wrote:

> Hi Gregory
>
>> +
>> +static int mvebu_uart_startup(struct uart_port *port)
>> +{
>> +       int ret;
>> +
>> +       writel(CTRL_TXFIFO_RST | CTRL_RXFIFO_RST,
>> +              port->membase + UART_CTRL);
>> +       udelay(1);
>> +       writel(CTRL_RX_INT, port->membase + UART_CTRL);
>> +
>> +       ret = request_irq(port->irq, mvebu_uart_isr, port->irqflags, "serial",
>> +                         port);
>> +       if (ret) {
>> +               dev_err(port->dev, "failed to request irq\n");
>> +               return ret;
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>
>> +static int mvebu_uart_probe(struct platform_device *pdev)
>> +{
>> +       struct resource *reg = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +       struct resource *irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> +       struct uart_port *port;
>> +       struct mvebu_uart_data *data;
>> +       int ret;
>> +
>> +       if (!reg || !irq) {
>> +               dev_err(&pdev->dev, "no registers/irq defined\n");
>> +               return -EINVAL;
>> +       }
>> +
>> +       port = &mvebu_uart_ports[0];
>> +
>> +       spin_lock_init(&port->lock);
>> +
>> +       port->dev        = &pdev->dev;
>> +       port->type       = PORT_MVEBU;
>> +       port->ops        = &mvebu_uart_ops;
>> +       port->regshift   = 0;
>> +
>> +       port->fifosize   = 32;
>> +       port->iotype     = UPIO_MEM32;
>> +       port->flags      = UPF_FIXED_PORT;
>> +       port->line       = 0; /* single port: force line number to  0 */
>> +
>> +       port->irq        = irq->start;
>> +       port->irqflags   = 0;
>
> Please use port->irqflags = IRQF_SHARED;
> As ubuntu opens multiple consoles A3700 can't boot to it (only to
> buildroot with single console).

But this irq is not shared, this looks like a hack hidding the real
issue.

Gregory

>
> Best regards,
> Marcin

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From mark.rutland at arm.com  Wed Feb  3 08:46:32 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 3 Feb 2016 16:46:32 +0000
Subject: [PATCH v4 4/7] arm64: Handle early CPU boot failures
In-Reply-To: <20160203125735.GA26487@MBP.local>
References: <1453745225-27736-1-git-send-email-suzuki.poulose@arm.com>
 <1453745225-27736-5-git-send-email-suzuki.poulose@arm.com>
 <20160203125735.GA26487@MBP.local>
Message-ID: <20160203164632.GC1234@leverpostej>

On Wed, Feb 03, 2016 at 12:57:38PM +0000, Catalin Marinas wrote:
> Hi Suzuki,
> 
> On Mon, Jan 25, 2016 at 06:07:02PM +0000, Suzuki K. Poulose wrote:
> > + * update_early_cpu_boot_status tmp, status
> > + *  - Corrupts tmp, x0, x1
> > + *  - Writes 'status' to __early_cpu_boot_status and makes sure
> > + *    it is committed to memory.
> > + */
> > +
> > +	.macro	update_early_cpu_boot_status tmp, status
> > +	mov	\tmp, lr
> > +	adrp	x0, __early_cpu_boot_status
> > +	add	x0, x0, #:lo12:__early_cpu_boot_status
> 
> Nitpick: you could use the adr_l macro.
> 
> > +	mov	x1, #\status
> > +	str	x1, [x0]
> > +	add	x1, x0, 4
> > +	bl	__inval_cache_range
> > +	mov	lr, \tmp
> > +	.endm
> 
> If the CPU that's currently booting has the MMU off, what's the point of
> invalidating the cache here?

To invalidate stale lines for this address, held in any caches prior to
the PoC. I'm assuming that __early_cpu_boot_status is sufficiently
padded to the CWG.

Cache maintenance works when SCTLR_ELx.M == 0, though barriers are
required prior to cache maintenance as non-cacheable accesses do not
hazard by VA.

The MMU being off has no effect on the cache maintenance itself.

> The operation may not even be broadcast to the other CPU. So you
> actually need the invalidation before reading the status on the
> primary CPU.

We require that CPUs are coherent when they enter the kernel, so any
cache maintenance operation _must_ affect all coherent caches (i.e. it
must be broadcast and must affect all coherent caches prior to the PoC
in this case).

> > +
> > +ENTRY(__early_cpu_boot_status)
> > +	.long 	0
> > +END(__early_cpu_boot_status)
> 
> I think we should just do like __boot_cpu_mode and place it in the
> .data..cacheline_aligned section.

I think we should add a separate __writeback_aligned annotation for
stuff like this, even if it falls in .data..cacheline_aligned for now.

Otherwise, agreed.

> You can always use the safe clean+invalidate before reading the value
> so that we don't care much about the write-back granule.

To get correct data out we need to pad to the CQG regardless of whether
the reader or the writer perform the maintenance.

Mark.


From tony at atomide.com  Wed Feb  3 08:49:40 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Feb 2016 08:49:40 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAJZ5v0if-OCynmN1qzBaWLHOEEHN6kJe1LCbJ=eOwUj6=iZDaw@mail.gmail.com>
References: <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602021112320.1653-100000@iolanthe.rowland.org>
 <CAPDyKFokWcLSCAh_TX-j-df_M1hN8Qw1gbQt--SyWccGCPiN5Q@mail.gmail.com>
 <20160202213916.GA19432@atomide.com>
 <CAJZ5v0if-OCynmN1qzBaWLHOEEHN6kJe1LCbJ=eOwUj6=iZDaw@mail.gmail.com>
Message-ID: <20160203164940.GJ19432@atomide.com>

* Rafael J. Wysocki <rafael at kernel.org> [160203 05:04]:
> On Tue, Feb 2, 2016 at 10:39 PM, Tony Lindgren <tony at atomide.com> wrote:
> > * Ulf Hansson <ulf.hansson at linaro.org> [160202 12:25]:
> >> >
> >> > ?  pm_runtime_put_sync() _already_ does not respect the autosuspend
> >> > mode.  If you want to respect it, you have to call
> >> > pm_runtime_put_sync_autosuspend() instead.
> >>
> >> Then there's a bug in the runtime PM core.
> >>
> >> From Tony's regression report and from mine own local runtime PM test
> >> driver, I can see that the device doesn't get RPM_SUSPENDED (the
> >> ->runtime_suspend() callback isn't called), even when the usage count
> >> is zero - when pm_runtime_put_sync() is called.
> > ...
> >> Okay, so you are saying that the pm_runtime_put_sync() should idle the
> >> device even if autosuspend is in use. That seems reasonable, I will
> >> look into this problem.
> >
> > The patch below fixes pm_runtime_put_sync() to not respect the
> > autosuspend mode to match what Alan is saying above. Seems to also
> > fixes the $subject issue for me. And seems to behave for PM runtime
> > for other devices during runtime too based on light testing here.
> >
> > Regards,
> >
> > Tony
> >
> > 8< ---------------
> > --- a/drivers/base/power/runtime.c
> > +++ b/drivers/base/power/runtime.c
> > @@ -353,7 +353,9 @@ static int rpm_idle(struct device *dev, int rpmflags)
> >
> >   out:
> >         trace_rpm_return_int(dev, _THIS_IP_, retval);
> > -       return retval ? retval : rpm_suspend(dev, rpmflags | RPM_AUTO);
> > +       if (!(rpmflags & RPM_IGNORE_AUTO))
> > +               rpmflags |= RPM_AUTO;
> > +       return retval ? retval : rpm_suspend(dev, rpmflags);
> >  }
> >
> >  /**
> > --- a/include/linux/pm_runtime.h
> > +++ b/include/linux/pm_runtime.h
> > @@ -23,6 +23,8 @@
> >                                             usage_count */
> >  #define RPM_AUTO               0x08    /* Use autosuspend_delay */
> >
> > +#define RPM_IGNORE_AUTO                0x10    /* Ignore autosuspend */
> > +
> >  #ifdef CONFIG_PM
> >  extern struct workqueue_struct *pm_wq;
> >
> > @@ -241,7 +243,7 @@ static inline int pm_runtime_put_autosuspend(struct device *dev)
> >
> >  static inline int pm_runtime_put_sync(struct device *dev)
> >  {
> > -       return __pm_runtime_idle(dev, RPM_GET_PUT);
> > +       return __pm_runtime_idle(dev, RPM_GET_PUT | RPM_IGNORE_AUTO);
> >  }
> >
> >  static inline int pm_runtime_put_sync_suspend(struct device *dev)
> 
> This changes a well-documented behavior that someone may be relying on.
> 
> Not the safest thing to do I have to say.

Yup fine with me.

Regards,

Tony


From ivo.g.dimitrov.75 at gmail.com  Wed Feb  3 08:50:11 2016
From: ivo.g.dimitrov.75 at gmail.com (Ivaylo Dimitrov)
Date: Wed, 3 Feb 2016 18:50:11 +0200
Subject: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
In-Reply-To: <56B1A654.1060905@gmail.com>
References: <568D5F54.7040900@gmail.com> <20160107180700.GN12777@atomide.com>
 <568EDC8D.7070205@gmail.com> <20160108022619.GS12777@atomide.com>
 <568F4596.8020206@gmail.com> <20160108075913.GN11364@pali>
 <569052FE.1040008@gmail.com> <20160121091437.GT7192@pali>
 <56B077D4.3030902@gmail.com> <20160202233911.GB19432@atomide.com>
 <20160203000045.GE19432@atomide.com> <56B1A654.1060905@gmail.com>
Message-ID: <56B22FC3.3050900@gmail.com>



On  3.02.2016 09:03, Ivaylo Dimitrov wrote:
>
>
> I will play a bit more with omap2plus_defconfig here in attempt to make
> it boot, to see if I can recreate the issue.
>

ok, what I did here is:

- zImage

git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
git checkout omap-for-v4.5/fixes-rc1
make omap2plus_defconfig
make -j4 zImage
make omap3-n900.dtb
cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > zImage

- flashed maemo rootfs

sudo flasher-3.5 -f -F RX-51_2009SE_20.2010.36-2_PR_COMBINED_MR0_ARM.bin 
--flash-only=rootfs -R

- booted to maemo and powered the device off

sudo flasher-3.5 -k zImage  -l -b"init=/sbin/preinit ubi.mtd=rootfs 
root=ubi0:rootfs rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc rw 
mtdoops.mtddev=log  omapfb_vram=7M omapfb.mode=lcd:848x480-16 
nokia-modem.pm=0"

There was nothing on the screen, but backlight was on. I removed the 
battery after ~30 seconds.

At this point maemo is no longer bootable. Booting fb-console enabled 
stock kernel 
(http://mohammadag.xceleo.org/public/maemo/kernels/framebuffer/) via 
flasher3.5:

sudo flasher-3.5 -k zImage-fb-omap1-pr13 -l -b

produces http://46.249.74.23/maemo/onenend/stock/ .

Booting 4.5-rc1 kernel from https://github.com/pali/linux-n900, with 
HWMOD_INIT_NO_RESET restored and your "onenand fix" patch reverted (so 
to not introduce additional corruption), via flasher3.5:

sudo flasher-3.5 -k zImage  -l -b"init=/sbin/preinit ubi.mtd=rootfs 
root=ubi0:rootfs rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc rw 
mtdoops.mtddev=log  omapfb_vram=7M omapfb.mode=lcd:848x480-16 
nokia-modem.pm=0"

results in http://46.249.74.23/maemo/onenend/linux-n900/ .

note - don't try to play the videos in the browser, download them first 
instead, at least FF doesn't want to play videos captured by N900 :)

Regards,
Ivo




From gregory.clement at free-electrons.com  Wed Feb  3 08:56:56 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed, 03 Feb 2016 17:56:56 +0100
Subject: [PATCH 01/10] serial: mvebu-uart: initial support for Armada-3700
 serial port
In-Reply-To: <20160202182842.GD29778@leverpostej> (Mark Rutland's message of
 "Tue, 2 Feb 2016 18:28:42 +0000")
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
 <20160202182842.GD29778@leverpostej>
Message-ID: <87egct4trb.fsf@free-electrons.com>

Hi Mark,
 
 On mar., f?vr. 02 2016, Mark Rutland <mark.rutland at arm.com> wrote:

>> diff --git a/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
>> new file mode 100644
>> index 000000000000..6087defd9f93
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
>> @@ -0,0 +1,13 @@
>> +* Marvell UART : Non standard UART used in some of Marvell EBU SoCs (e.g., Armada-3700)
>> +
>> +Required properties:
>> +- compatible: "marvell,armada-3700-uart"
>> +- reg: offset and length of the register set for the device.
>> +- interrupts: device interrupt
>> +
>> +Example:
>> +	serial at 12000 {
>> +		compatible = "marvell,armada-3700-uart";
>> +		reg = <0x12000 0x400>;
>> +		interrupts = <43>;
>> +	};
>
> There are no external clock inputs?

Right, even if we don't use it in the driver we should ad it in the
binding because there is an external clock input.

>
>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>> index 87d40a72f6a1..198f6bd56e84 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -1058,6 +1058,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>>  			A valid base address must be provided, and the serial
>>  			port must already be setup and configured.
>>  
>> +		mvebu_uart,<addr>
>> +			Start an early, polled-mode console on an some mvebu
>> +			SoC (as the Armada-3700) serial port at the specified
>> +			address. The serial port must already be setup and
>> +			configured. Options are not yet supported.
>> +
>
> Does the the mvebu UART vary between platforms at all?

I am not sure to undersatnd your question.

If you asked about the UART used on the other mvebu SoCs then my answer
is: on all the other mvebu SoC until now third party IPs were used. This
one is the first one dedicated to an mevbu SoC and currently only used
on Armada 3700 but I don't know what are the plan for the future mvebu
SoCs.

Gregory

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From andre.przywara at arm.com  Wed Feb  3 08:56:51 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed,  3 Feb 2016 16:56:51 +0000
Subject: [PATCH] KVM: arm/arm64: fix reference to uninitialised VGIC
Message-ID: <1454518611-15694-1-git-send-email-andre.przywara@arm.com>

Commit 4b4b4512da2a ("arm/arm64: KVM: Rework the arch timer to use
level-triggered semantics") brought the virtual architected timer
closer to the VGIC. There is one occasion were we don't properly
check for the VGIC actually having been initialized before, but
instead go on to check the active state of some IRQ number.
If userland hasn't instantiated a virtual GIC, we end up with a
kernel NULL pointer dereference:
=========
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = ffffffc9745c5000
[00000000] *pgd=00000009f631e003, *pud=00000009f631e003, *pmd=0000000000000000
Internal error: Oops: 96000006 [#2] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 2144 Comm: kvm_simplest-ar Tainted: G      D 4.5.0-rc2+ #1300
Hardware name: ARM Juno development board (r1) (DT)
task: ffffffc976da8000 ti: ffffffc976e28000 task.ti: ffffffc976e28000
PC is at vgic_bitmap_get_irq_val+0x78/0x90
LR is at kvm_vgic_map_is_active+0xac/0xc8
pc : [<ffffffc0000b7e28>] lr : [<ffffffc0000b972c>] pstate: 20000145
....
=========

Fix this by bailing out early of kvm_timer_flush_hwstate() if we don't
have a VGIC at all.

Reported-by: Cosmin Gorgovan <cosmin at linux-geek.org>
Signed-off-by: Andre Przywara <andre.przywara at arm.com>
Cc: <stable at vger.kernel.org> # 4.4.x
---
 virt/kvm/arm/arch_timer.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 69bca18..ea60646 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -143,7 +143,7 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level)
  * Check if there was a change in the timer state (should we raise or lower
  * the line level to the GIC).
  */
-static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
+static int kvm_timer_update_state(struct kvm_vcpu *vcpu)
 {
 	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
 
@@ -154,10 +154,12 @@ static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
 	 * until we call this function from kvm_timer_flush_hwstate.
 	 */
 	if (!vgic_initialized(vcpu->kvm))
-	    return;
+		return -ENODEV;
 
 	if (kvm_timer_should_fire(vcpu) != timer->irq.level)
 		kvm_timer_update_irq(vcpu, !timer->irq.level);
+
+	return 0;
 }
 
 /*
@@ -218,7 +220,8 @@ void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu)
 	bool phys_active;
 	int ret;
 
-	kvm_timer_update_state(vcpu);
+	if (kvm_timer_update_state(vcpu))
+		return;
 
 	/*
 	* If we enter the guest with the virtual input level to the VGIC
-- 
2.6.4



From tony at atomide.com  Wed Feb  3 09:01:28 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Feb 2016 09:01:28 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFoNY8xP11n6mFVicYwdy49sB4=H0fTm53754HukFX4HBQ@mail.gmail.com>
References: <CAPDyKFpNRc3Nf9ofXhZrfBa54vXMxWboDScCrYFrZy97m8Y5gg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602031034360.2041-100000@iolanthe.rowland.org>
 <20160203160951.GF19432@atomide.com>
 <CAPDyKFoNY8xP11n6mFVicYwdy49sB4=H0fTm53754HukFX4HBQ@mail.gmail.com>
Message-ID: <20160203170128.GK19432@atomide.com>

* Ulf Hansson <ulf.hansson at linaro.org> [160203 08:25]:
> Okay, so I understand that you decided to not pick up the omap hwmod
> patch I posted.

I just suggested a solution of patching both drivers and omap_device
to make it easy for people to fix new drivers, so assuming that sounds
OK to you..

> If you want some further help in fixing the omap drivers, please just
> tell me I am at your service. :-)

Heh me too :) It's probably worth checking the non omap_device drivers
thouhg.

I can check and fix up the omap_device using drivers. So roughly it's
these ones:

$ git grep pm_runtime_use_autosuspend drivers | cut -d: -f1 | \
	sort | uniq | grep omap
drivers/i2c/busses/i2c-omap.c
drivers/mmc/host/omap_hsmmc.c
drivers/spi/spi-omap2-mcspi.c
drivers/tty/serial/8250/8250_omap.c
drivers/tty/serial/omap-serial.c

> Also, we must not forget to also update their runtime PM calls in
> their ->remove() callbacks, as those seems to suffer from the same
> problem as in the -EPROBE_DEFER case.

Yes and any sections within the driver code where clocks really
should be disabled we must use pm_runtime_put_sync_suspend() if
pm_runtime_set_autoidle() is set.

Regards,

Tony


From mark.rutland at arm.com  Wed Feb  3 09:01:15 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 3 Feb 2016 17:01:15 +0000
Subject: [PATCH v4 4/7] arm64: Handle early CPU boot failures
In-Reply-To: <1453745225-27736-5-git-send-email-suzuki.poulose@arm.com>
References: <1453745225-27736-1-git-send-email-suzuki.poulose@arm.com>
 <1453745225-27736-5-git-send-email-suzuki.poulose@arm.com>
Message-ID: <20160203170114.GD1234@leverpostej>

On Mon, Jan 25, 2016 at 06:07:02PM +0000, Suzuki K Poulose wrote:
> From: Suzuki K. Poulose <suzuki.poulose at arm.com>
> 
> A secondary CPU could fail to come online due to insufficient
> capabilities and could simply die or loop in the kernel.
> e.g, a CPU with no support for the selected kernel PAGE_SIZE
> loops in kernel with MMU turned off.
> or a hotplugged CPU which doesn't have one of the advertised
> system capability will die during the activation.
> 
> There is no way to synchronise the status of the failing CPU
> back to the master. This patch solves the issue by adding a
> field to the secondary_data which can be updated by the failing
> CPU. If the secondary CPU fails even before turning the MMU on,
> it updates the status in a special variable reserved in the head.txt
> section to make sure that the update can be cache invalidated safely
> without possible sharing of cache write back granule.
> 
> Here are the possible states :
> 
>  -1. CPU_MMU_OFF - Initial value set by the master CPU, this value
> indicates that the CPU could not turn the MMU on, hence the status
> could not be reliably updated in the secondary_data. Instead, the
> CPU has updated the status in __early_cpu_boot_status (reserved in
> head.txt section)
> 
>  0. CPU_BOOT_SUCCESS - CPU has booted successfully.
> 
>  1. CPU_KILL_ME - CPU has invoked cpu_ops->die, indicating the
> master CPU to synchronise by issuing a cpu_ops->cpu_kill.
> 
>  2. CPU_STUCK_IN_KERNEL - CPU couldn't invoke die(), instead is
> looping in the kernel. This information could be used by say,
> kexec to check if it is really safe to do a kexec reboot.
> 
>  3. CPU_PANIC_KERNEL - CPU detected some serious issues which
> requires kernel to crash immediately. The secondary CPU cannot
> call panic() until it has initialised the GIC. This flag can
> be used to instruct the master to do so.

When would we use this last case?

Perhaps a better option is to always throw any incompatible CPU into an
(MMU-off) pen, and assume that it's stuck in the kernel, even if we
could theoretically turn it off.

A system with incompatible CPUs is a broken system to begin with...

Otherwise, comments below.

> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Mark Rutland <mark.rutland at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Signed-off-by: Suzuki K. Poulose <suzuki.poulose at arm.com>
> ---
>  arch/arm64/include/asm/smp.h    |   26 ++++++++++++++++++++++
>  arch/arm64/kernel/asm-offsets.c |    2 ++
>  arch/arm64/kernel/head.S        |   39 +++++++++++++++++++++++++++++---
>  arch/arm64/kernel/smp.c         |   47 +++++++++++++++++++++++++++++++++++++++
>  4 files changed, 111 insertions(+), 3 deletions(-)

[...]

> @@ -650,6 +679,10 @@ __enable_mmu:
>  ENDPROC(__enable_mmu)
>  
>  __no_granule_support:
> +	/* Indicate that this CPU can't boot and is stuck in the kernel */
> +	update_early_cpu_boot_status x2, CPU_STUCK_IN_KERNEL
> +1:
>  	wfe
> -	b __no_granule_support
> +	wfi
> +	b 1b

The addition of wfi seems fine, but should be mentioned in the commit
message.

>  ENDPROC(__no_granule_support)
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 59f032b..d2721ae 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -63,6 +63,8 @@
>   * where to place its SVC stack
>   */
>  struct secondary_data secondary_data;
> +/* Number of CPUs which aren't online, but looping in kernel text. */
> +u32 cpus_stuck_in_kernel;

Why u32 rather than int?

>  
>  enum ipi_msg_type {
>  	IPI_RESCHEDULE,
> @@ -72,6 +74,16 @@ enum ipi_msg_type {
>  	IPI_IRQ_WORK,
>  };
>  
> +#ifdef CONFIG_HOTPLUG_CPU
> +static int op_cpu_kill(unsigned int cpu);
> +#else
> +static inline int op_cpu_kill(unsigned int cpu)
> +{
> +	return -ENOSYS;
> +}
> +#endif

There is no !CONFIG_HOTPLUG_CPU configuration any more.

> +
> +
>  /*
>   * Boot a secondary CPU, and assign it the specified idle task.
>   * This also gives us the initial stack to use for this CPU.
> @@ -89,12 +101,14 @@ static DECLARE_COMPLETION(cpu_running);
>  int __cpu_up(unsigned int cpu, struct task_struct *idle)
>  {
>  	int ret;
> +	int status;
>  
>  	/*
>  	 * We need to tell the secondary core where to find its stack and the
>  	 * page tables.
>  	 */
>  	secondary_data.stack = task_stack_page(idle) + THREAD_START_SP;
> +	update_cpu_boot_status(CPU_MMU_OFF);
>  	__flush_dcache_area(&secondary_data, sizeof(secondary_data));
>  
>  	/*

> @@ -117,7 +131,35 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
>  		pr_err("CPU%u: failed to boot: %d\n", cpu, ret);
>  	}
>  
> +	/* Make sure the update to status is visible */
> +	smp_rmb();
>  	secondary_data.stack = NULL;
> +	status = READ_ONCE(secondary_data.status);

What is the rmb intended to order here?

> +	if (ret && status) {
> +
> +		if (status == CPU_MMU_OFF)
> +			status = READ_ONCE(__early_cpu_boot_status);
> +
> +		switch (status) {
> +		default:
> +			pr_err("CPU%u: failed in unknown state : 0x%x\n",
> +					cpu, status);
> +			break;
> +		case CPU_KILL_ME:
> +			if (!op_cpu_kill(cpu)) {
> +				pr_crit("CPU%u: died during early boot\n", cpu);
> +				break;
> +			}
> +			/* Fall through */
> +			pr_crit("CPU%u: may not have shut down cleanly\n", cpu);
> +		case CPU_STUCK_IN_KERNEL:
> +			pr_crit("CPU%u: is stuck in kernel\n", cpu);
> +			cpus_stuck_in_kernel++;
> +			break;
> +		case CPU_PANIC_KERNEL:
> +			panic("CPU%u detected unsupported configuration\n", cpu);
> +		}
> +	}
>  
>  	return ret;
>  }
> @@ -185,6 +227,9 @@ asmlinkage void secondary_start_kernel(void)
>  	 */
>  	pr_info("CPU%u: Booted secondary processor [%08x]\n",
>  					 cpu, read_cpuid_id());
> +	update_cpu_boot_status(CPU_BOOT_SUCCESS);
> +	/* Make sure the status update is visible before we complete */
> +	smp_wmb();

Surely complete() has appropriate barriers?

>  	set_cpu_online(cpu, true);
>  	complete(&cpu_running);
>  
> @@ -327,10 +372,12 @@ void cpu_die_early(void)
>  	set_cpu_present(cpu, 0);
>  
>  #ifdef CONFIG_HOTPLUG_CPU
> +	update_cpu_boot_status(CPU_KILL_ME);
>  	/* Check if we can park ourselves */
>  	if (cpu_ops[cpu] && cpu_ops[cpu]->cpu_die)
>  		cpu_ops[cpu]->cpu_die(cpu);

I think you need a barrier to ensure visibility of the store prior to
calling cpu_die (i.e. you want to order an access against execution). A
dsb is what you want -- smp_wmb() only expands to a dmb.

>  #endif
> +	update_cpu_boot_status(CPU_STUCK_IN_KERNEL);
>  
>  	cpu_park_loop();

Likewise here.

Mark.


From mark.rutland at arm.com  Wed Feb  3 09:05:07 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 3 Feb 2016 17:05:07 +0000
Subject: [PATCH 01/10] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <87egct4trb.fsf@free-electrons.com>
References: <1454436468-4241-1-git-send-email-gregory.clement@free-electrons.com>
 <1454436468-4241-2-git-send-email-gregory.clement@free-electrons.com>
 <20160202182842.GD29778@leverpostej>
 <87egct4trb.fsf@free-electrons.com>
Message-ID: <20160203170506.GE1234@leverpostej>

On Wed, Feb 03, 2016 at 05:56:56PM +0100, Gregory CLEMENT wrote:
> Hi Mark,
>  
>  On mar., f?vr. 02 2016, Mark Rutland <mark.rutland at arm.com> wrote:
> >> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> >> index 87d40a72f6a1..198f6bd56e84 100644
> >> --- a/Documentation/kernel-parameters.txt
> >> +++ b/Documentation/kernel-parameters.txt
> >> @@ -1058,6 +1058,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> >>  			A valid base address must be provided, and the serial
> >>  			port must already be setup and configured.
> >>  
> >> +		mvebu_uart,<addr>
> >> +			Start an early, polled-mode console on an some mvebu
> >> +			SoC (as the Armada-3700) serial port at the specified
> >> +			address. The serial port must already be setup and
> >> +			configured. Options are not yet supported.
> >> +
> >
> > Does the the mvebu UART vary between platforms at all?
> 
> I am not sure to undersatnd your question.
> 
> If you asked about the UART used on the other mvebu SoCs then my answer
> is: on all the other mvebu SoC until now third party IPs were used.

Ah, I hadn't realised that.

> This one is the first one dedicated to an mevbu SoC and currently only
> used on Armada 3700 but I don't know what are the plan for the future
> mvebu SoCs.

Given that, I think it would be better to use "armada3700_uart=" for
now, given it doesn't cover all mvebu SoCs.

Thanks,
Mark.


From dinguyen at opensource.altera.com  Wed Feb  3 09:03:06 2016
From: dinguyen at opensource.altera.com (dinguyen at opensource.altera.com)
Date: Wed, 3 Feb 2016 11:03:06 -0600
Subject: [PATCH] ARM: multi_v7_defconfig: enable DW_WATCHDOG
Message-ID: <1454518986-25953-1-git-send-email-dinguyen@opensource.altera.com>

From: Dinh Nguyen <dinguyen at opensource.altera.com>

The watchdog timer on the SoCFPGA platform is the Synopsys Designware watchdog.
Enable CONFIG_DW_WATCHDOG for the driver to get built.

Signed-off-by: Dinh Nguyen <dinguyen at opensource.altera.com>
---
 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 69d6a6d..24ceac2 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -426,6 +426,7 @@ CONFIG_SUNXI_WATCHDOG=y
 CONFIG_IMX2_WDT=y
 CONFIG_TEGRA_WATCHDOG=m
 CONFIG_MESON_WATCHDOG=y
+CONFIG_DW_WATCHDOG=y
 CONFIG_DIGICOLOR_WATCHDOG=y
 CONFIG_MFD_AS3711=y
 CONFIG_MFD_AS3722=y
-- 
2.6.2



From jglauber at cavium.com  Wed Feb  3 09:11:55 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Wed,  3 Feb 2016 18:11:55 +0100
Subject: [PATCH v3 0/5] Cavium ThunderX PMU support
Message-ID: <cover.1454516082.git.jglauber@cavium.com>

Hi,

I'm reposting the whole series just in case my previous attempt to
repost only the broken patch was confusing. Patches are based on
4.5-rc2.

Patches 1-3 add support for ThunderX specific PMU events.

Patch 4 changes the cycle counter to overflow on 64 bit but tries to minimize
code changes. Without this change perf does not work at all on ThunderX.

Patch 5 extends the event mask according to ARMv8.1 and also affects arm32.

Changes to v2:
- fixed arm compile errors

Changes to v1:
- renamed thunderx dt pmu binding to thunder

--Jan

Jan Glauber (5):
  arm64/perf: Rename Cortex A57 events
  arm64/perf: Add Cavium ThunderX PMU support
  arm64: dts: Add Cavium ThunderX specific PMU
  arm64/perf: Enable PMCR long cycle counter bit
  arm64/perf: Extend event mask for ARMv8.1

 Documentation/devicetree/bindings/arm/pmu.txt |   1 +
 arch/arm/kernel/perf_event_v6.c               |   6 +-
 arch/arm/kernel/perf_event_v7.c               |  29 ++++--
 arch/arm/kernel/perf_event_xscale.c           |   4 +-
 arch/arm64/boot/dts/cavium/thunder-88xx.dtsi  |   5 +
 arch/arm64/kernel/perf_event.c                | 145 ++++++++++++++++++++------
 drivers/perf/arm_pmu.c                        |   5 +-
 include/linux/perf/arm_pmu.h                  |   4 +-
 8 files changed, 151 insertions(+), 48 deletions(-)

-- 
1.9.1



From jglauber at cavium.com  Wed Feb  3 09:11:56 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Wed,  3 Feb 2016 18:11:56 +0100
Subject: [PATCH v3 1/5] arm64/perf: Rename Cortex A57 events
In-Reply-To: <cover.1454516082.git.jglauber@cavium.com>
References: <cover.1454516082.git.jglauber@cavium.com>
Message-ID: <e0ecaaaffb64cc0b2ecfd8852f718a3f1d642b5c.1454516082.git.jglauber@cavium.com>

The implemented Cortex A57 events are not A57 specific.
They are recommended by ARM and can be found on other
ARMv8 SOCs like Cavium ThunderX too. Therefore move
these events to the common PMUv3 table.

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 arch/arm64/kernel/perf_event.c | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index f7ab14c..32fe656 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -87,17 +87,17 @@
 #define ARMV8_PMUV3_PERFCTR_L2D_TLB				0x2F
 #define ARMV8_PMUV3_PERFCTR_L21_TLB				0x30
 
+/* Recommended events. */
+#define ARMV8_PMUV3_PERFCTR_L1_DCACHE_ACCESS_LD			0x40
+#define ARMV8_PMUV3_PERFCTR_L1_DCACHE_ACCESS_ST			0x41
+#define ARMV8_PMUV3_PERFCTR_L1_DCACHE_REFILL_LD			0x42
+#define ARMV8_PMUV3_PERFCTR_L1_DCACHE_REFILL_ST			0x43
+#define ARMV8_PMUV3_PERFCTR_DTLB_REFILL_LD			0x4C
+#define ARMV8_PMUV3_PERFCTR_DTLB_REFILL_ST			0x4D
+
 /* ARMv8 Cortex-A53 specific event types. */
 #define ARMV8_A53_PERFCTR_PREFETCH_LINEFILL			0xC2
 
-/* ARMv8 Cortex-A57 and Cortex-A72 specific event types. */
-#define ARMV8_A57_PERFCTR_L1_DCACHE_ACCESS_LD			0x40
-#define ARMV8_A57_PERFCTR_L1_DCACHE_ACCESS_ST			0x41
-#define ARMV8_A57_PERFCTR_L1_DCACHE_REFILL_LD			0x42
-#define ARMV8_A57_PERFCTR_L1_DCACHE_REFILL_ST			0x43
-#define ARMV8_A57_PERFCTR_DTLB_REFILL_LD			0x4c
-#define ARMV8_A57_PERFCTR_DTLB_REFILL_ST			0x4d
-
 /* PMUv3 HW events mapping. */
 static const unsigned armv8_pmuv3_perf_map[PERF_COUNT_HW_MAX] = {
 	PERF_MAP_ALL_UNSUPPORTED,
@@ -174,16 +174,16 @@ static const unsigned armv8_a57_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
 					      [PERF_COUNT_HW_CACHE_RESULT_MAX] = {
 	PERF_CACHE_MAP_ALL_UNSUPPORTED,
 
-	[C(L1D)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_A57_PERFCTR_L1_DCACHE_ACCESS_LD,
-	[C(L1D)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_A57_PERFCTR_L1_DCACHE_REFILL_LD,
-	[C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)]	= ARMV8_A57_PERFCTR_L1_DCACHE_ACCESS_ST,
-	[C(L1D)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_A57_PERFCTR_L1_DCACHE_REFILL_ST,
+	[C(L1D)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_L1_DCACHE_ACCESS_LD,
+	[C(L1D)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_L1_DCACHE_REFILL_LD,
+	[C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_L1_DCACHE_ACCESS_ST,
+	[C(L1D)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_L1_DCACHE_REFILL_ST,
 
 	[C(L1I)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_L1_ICACHE_ACCESS,
 	[C(L1I)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_L1_ICACHE_REFILL,
 
-	[C(DTLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_A57_PERFCTR_DTLB_REFILL_LD,
-	[C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_A57_PERFCTR_DTLB_REFILL_ST,
+	[C(DTLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_DTLB_REFILL_LD,
+	[C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_DTLB_REFILL_ST,
 
 	[C(ITLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_ITLB_REFILL,
 
-- 
1.9.1



From jglauber at cavium.com  Wed Feb  3 09:11:57 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Wed,  3 Feb 2016 18:11:57 +0100
Subject: [PATCH v3 2/5] arm64/perf: Add Cavium ThunderX PMU support
In-Reply-To: <cover.1454516082.git.jglauber@cavium.com>
References: <cover.1454516082.git.jglauber@cavium.com>
Message-ID: <eeca4f09e712d98d69ecd7de10c53b20528b48f3.1454516082.git.jglauber@cavium.com>

Support PMU events on Caviums ThunderX SOC. ThunderX supports
some additional counters compared to the default ARMv8 PMUv3:

- branch instructions counter
- stall frontend & backend counters
- L1 dcache load & store counters
- L1 icache counters
- iTLB & dTLB counters
- L1 dcache & icache prefetch counters

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 arch/arm64/kernel/perf_event.c | 69 +++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 68 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 32fe656..c038e4e 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -94,10 +94,19 @@
 #define ARMV8_PMUV3_PERFCTR_L1_DCACHE_REFILL_ST			0x43
 #define ARMV8_PMUV3_PERFCTR_DTLB_REFILL_LD			0x4C
 #define ARMV8_PMUV3_PERFCTR_DTLB_REFILL_ST			0x4D
+#define ARMV8_PMUV3_PERFCTR_DTLB_ACCESS_LD			0x4E
+#define ARMV8_PMUV3_PERFCTR_DTLB_ACCESS_ST			0x4F
 
 /* ARMv8 Cortex-A53 specific event types. */
 #define ARMV8_A53_PERFCTR_PREFETCH_LINEFILL			0xC2
 
+/* ARMv8 Cavium Thunder specific event types. */
+#define ARMV8_THUNDER_PERFCTR_L1_DCACHE_MISS_ST			0xE9
+#define ARMV8_THUNDER_PERFCTR_L1_DCACHE_PREF_ACCESS		0xEA
+#define ARMV8_THUNDER_PERFCTR_L1_DCACHE_PREF_MISS		0xEB
+#define ARMV8_THUNDER_PERFCTR_L1_ICACHE_PREF_ACCESS		0xEC
+#define ARMV8_THUNDER_PERFCTR_L1_ICACHE_PREF_MISS		0xED
+
 /* PMUv3 HW events mapping. */
 static const unsigned armv8_pmuv3_perf_map[PERF_COUNT_HW_MAX] = {
 	PERF_MAP_ALL_UNSUPPORTED,
@@ -131,6 +140,18 @@ static const unsigned armv8_a57_perf_map[PERF_COUNT_HW_MAX] = {
 	[PERF_COUNT_HW_BUS_CYCLES]		= ARMV8_PMUV3_PERFCTR_BUS_CYCLES,
 };
 
+static const unsigned armv8_thunder_perf_map[PERF_COUNT_HW_MAX] = {
+	PERF_MAP_ALL_UNSUPPORTED,
+	[PERF_COUNT_HW_CPU_CYCLES]		= ARMV8_PMUV3_PERFCTR_CLOCK_CYCLES,
+	[PERF_COUNT_HW_INSTRUCTIONS]		= ARMV8_PMUV3_PERFCTR_INSTR_EXECUTED,
+	[PERF_COUNT_HW_CACHE_REFERENCES]	= ARMV8_PMUV3_PERFCTR_L1_DCACHE_ACCESS,
+	[PERF_COUNT_HW_CACHE_MISSES]		= ARMV8_PMUV3_PERFCTR_L1_DCACHE_REFILL,
+	[PERF_COUNT_HW_BRANCH_INSTRUCTIONS]	= ARMV8_PMUV3_PERFCTR_PC_WRITE,
+	[PERF_COUNT_HW_BRANCH_MISSES]		= ARMV8_PMUV3_PERFCTR_PC_BRANCH_MIS_PRED,
+	[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = ARMV8_PMUV3_PERFCTR_STALL_FRONTEND,
+	[PERF_COUNT_HW_STALLED_CYCLES_BACKEND]	= ARMV8_PMUV3_PERFCTR_STALL_BACKEND,
+};
+
 static const unsigned armv8_pmuv3_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
 						[PERF_COUNT_HW_CACHE_OP_MAX]
 						[PERF_COUNT_HW_CACHE_RESULT_MAX] = {
@@ -193,6 +214,36 @@ static const unsigned armv8_a57_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
 	[C(BPU)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_PC_BRANCH_MIS_PRED,
 };
 
+static const unsigned armv8_thunder_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
+						   [PERF_COUNT_HW_CACHE_OP_MAX]
+						   [PERF_COUNT_HW_CACHE_RESULT_MAX] = {
+	PERF_CACHE_MAP_ALL_UNSUPPORTED,
+
+	[C(L1D)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_L1_DCACHE_ACCESS_LD,
+	[C(L1D)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_L1_DCACHE_REFILL_LD,
+	[C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_L1_DCACHE_ACCESS_ST,
+	[C(L1D)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_THUNDER_PERFCTR_L1_DCACHE_MISS_ST,
+	[C(L1D)][C(OP_PREFETCH)][C(RESULT_ACCESS)] = ARMV8_THUNDER_PERFCTR_L1_DCACHE_PREF_ACCESS,
+	[C(L1D)][C(OP_PREFETCH)][C(RESULT_MISS)] = ARMV8_THUNDER_PERFCTR_L1_DCACHE_PREF_MISS,
+
+	[C(L1I)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_L1_ICACHE_ACCESS,
+	[C(L1I)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_L1_ICACHE_REFILL,
+	[C(L1I)][C(OP_PREFETCH)][C(RESULT_ACCESS)] = ARMV8_THUNDER_PERFCTR_L1_ICACHE_PREF_ACCESS,
+	[C(L1I)][C(OP_PREFETCH)][C(RESULT_MISS)] = ARMV8_THUNDER_PERFCTR_L1_ICACHE_PREF_MISS,
+
+	[C(DTLB)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_DTLB_ACCESS_LD,
+	[C(DTLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_DTLB_REFILL_LD,
+	[C(DTLB)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_DTLB_ACCESS_ST,
+	[C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_DTLB_REFILL_ST,
+
+	[C(ITLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_ITLB_REFILL,
+
+	[C(BPU)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_PC_BRANCH_PRED,
+	[C(BPU)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_PC_BRANCH_MIS_PRED,
+	[C(BPU)][C(OP_WRITE)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_PC_BRANCH_PRED,
+	[C(BPU)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_PC_BRANCH_MIS_PRED,
+};
+
 #define ARMV8_EVENT_ATTR_RESOLVE(m) #m
 #define ARMV8_EVENT_ATTR(name, config) \
 	PMU_EVENT_ATTR_STRING(name, armv8_event_attr_##name, \
@@ -324,7 +375,6 @@ static const struct attribute_group *armv8_pmuv3_attr_groups[] = {
 	NULL,
 };
 
-
 /*
  * Perf Events' indices
  */
@@ -743,6 +793,13 @@ static int armv8_a57_map_event(struct perf_event *event)
 				ARMV8_EVTYPE_EVENT);
 }
 
+static int armv8_thunder_map_event(struct perf_event *event)
+{
+	return armpmu_map_event(event, &armv8_thunder_perf_map,
+				&armv8_thunder_perf_cache_map,
+				ARMV8_EVTYPE_EVENT);
+}
+
 static void armv8pmu_read_num_pmnc_events(void *info)
 {
 	int *nb_cnt = info;
@@ -811,11 +868,21 @@ static int armv8_a72_pmu_init(struct arm_pmu *cpu_pmu)
 	return armv8pmu_probe_num_events(cpu_pmu);
 }
 
+static int armv8_thunder_pmu_init(struct arm_pmu *cpu_pmu)
+{
+	armv8_pmu_init(cpu_pmu);
+	cpu_pmu->name			= "armv8_cavium_thunder";
+	cpu_pmu->map_event		= armv8_thunder_map_event;
+	cpu_pmu->pmu.attr_groups	= armv8_pmuv3_attr_groups;
+	return armv8pmu_probe_num_events(cpu_pmu);
+}
+
 static const struct of_device_id armv8_pmu_of_device_ids[] = {
 	{.compatible = "arm,armv8-pmuv3",	.data = armv8_pmuv3_init},
 	{.compatible = "arm,cortex-a53-pmu",	.data = armv8_a53_pmu_init},
 	{.compatible = "arm,cortex-a57-pmu",	.data = armv8_a57_pmu_init},
 	{.compatible = "arm,cortex-a72-pmu",	.data = armv8_a72_pmu_init},
+	{.compatible = "cavium,thunder-pmu",	.data = armv8_thunder_pmu_init},
 	{},
 };
 
-- 
1.9.1



From jglauber at cavium.com  Wed Feb  3 09:11:58 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Wed,  3 Feb 2016 18:11:58 +0100
Subject: [PATCH v3 3/5] arm64: dts: Add Cavium ThunderX specific PMU
In-Reply-To: <cover.1454516082.git.jglauber@cavium.com>
References: <cover.1454516082.git.jglauber@cavium.com>
Message-ID: <d02a118085866aefb8607bacecf4c7eb4019c921.1454516082.git.jglauber@cavium.com>

Add a compatible string for the Cavium ThunderX PMU.

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 Documentation/devicetree/bindings/arm/pmu.txt | 1 +
 arch/arm64/boot/dts/cavium/thunder-88xx.dtsi  | 5 +++++
 2 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt
index 5651883..d3999a1 100644
--- a/Documentation/devicetree/bindings/arm/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/pmu.txt
@@ -25,6 +25,7 @@ Required properties:
 	"qcom,scorpion-pmu"
 	"qcom,scorpion-mp-pmu"
 	"qcom,krait-pmu"
+	"cavium,thunder-pmu"
 - interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu
                interrupt (PPI) then 1 interrupt should be specified.
 
diff --git a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
index 9cb7cf9..2eb9b22 100644
--- a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
+++ b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
@@ -360,6 +360,11 @@
 		             <1 10 0xff01>;
 	};
 
+	pmu {
+		compatible = "cavium,thunder-pmu", "arm,armv8-pmuv3";
+		interrupts = <1 7 4>;
+	};
+
 	soc {
 		compatible = "simple-bus";
 		#address-cells = <2>;
-- 
1.9.1



From jglauber at cavium.com  Wed Feb  3 09:11:59 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Wed,  3 Feb 2016 18:11:59 +0100
Subject: [PATCH v3 4/5] arm64/perf: Enable PMCR long cycle counter bit
In-Reply-To: <cover.1454516082.git.jglauber@cavium.com>
References: <cover.1454516082.git.jglauber@cavium.com>
Message-ID: <de7340e1843f7823384551db64b12eadde7eded7.1454516082.git.jglauber@cavium.com>

With the long cycle counter bit (LC) disabled the cycle counter is not
working on ThunderX SOC (ThunderX only implements Aarch64).
Also, according to documentation LC == 0 is deprecated.

To keep the code simple the patch does not introduce 64 bit wide counter
functions. Instead writing the cycle counter always sets the upper
32 bits so overflow interrupts are generated as before.

Original patch from Andrew Pinksi <Andrew.Pinksi at caviumnetworks.com>

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 arch/arm64/kernel/perf_event.c | 21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index c038e4e..5e4275e 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -405,6 +405,7 @@ static const struct attribute_group *armv8_pmuv3_attr_groups[] = {
 #define ARMV8_PMCR_D		(1 << 3) /* CCNT counts every 64th cpu cycle */
 #define ARMV8_PMCR_X		(1 << 4) /* Export to ETM */
 #define ARMV8_PMCR_DP		(1 << 5) /* Disable CCNT if non-invasive debug*/
+#define ARMV8_PMCR_LC		(1 << 6) /* Overflow on 64 bit cycle counter */
 #define	ARMV8_PMCR_N_SHIFT	11	 /* Number of counters supported */
 #define	ARMV8_PMCR_N_MASK	0x1f
 #define	ARMV8_PMCR_MASK		0x3f	 /* Mask for writable bits */
@@ -494,9 +495,16 @@ static inline void armv8pmu_write_counter(struct perf_event *event, u32 value)
 	if (!armv8pmu_counter_valid(cpu_pmu, idx))
 		pr_err("CPU%u writing wrong counter %d\n",
 			smp_processor_id(), idx);
-	else if (idx == ARMV8_IDX_CYCLE_COUNTER)
-		asm volatile("msr pmccntr_el0, %0" :: "r" (value));
-	else if (armv8pmu_select_counter(idx) == idx)
+	else if (idx == ARMV8_IDX_CYCLE_COUNTER) {
+		/*
+		 * Set the upper 32bits as this is a 64bit counter but we only
+		 * count using the lower 32bits and we want an interrupt when
+		 * it overflows.
+		 */
+		u64 value64 = 0xffffffff00000000ULL | value;
+
+		asm volatile("msr pmccntr_el0, %0" :: "r" (value64));
+	} else if (armv8pmu_select_counter(idx) == idx)
 		asm volatile("msr pmxevcntr_el0, %0" :: "r" (value));
 }
 
@@ -768,8 +776,11 @@ static void armv8pmu_reset(void *info)
 		armv8pmu_disable_intens(idx);
 	}
 
-	/* Initialize & Reset PMNC: C and P bits. */
-	armv8pmu_pmcr_write(ARMV8_PMCR_P | ARMV8_PMCR_C);
+	/*
+	 * Initialize & Reset PMNC. Request overflow on 64 bit but
+	 * cheat in armv8pmu_write_counter().
+	 */
+	armv8pmu_pmcr_write(ARMV8_PMCR_P | ARMV8_PMCR_C | ARMV8_PMCR_LC);
 }
 
 static int armv8_pmuv3_map_event(struct perf_event *event)
-- 
1.9.1



From jglauber at cavium.com  Wed Feb  3 09:12:00 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Wed,  3 Feb 2016 18:12:00 +0100
Subject: [PATCH v3 5/5] arm64/perf: Extend event mask for ARMv8.1
In-Reply-To: <cover.1454516082.git.jglauber@cavium.com>
References: <cover.1454516082.git.jglauber@cavium.com>
Message-ID: <fa91eaedf581e6a7053899f25b1b08458dbd4b8e.1454516082.git.jglauber@cavium.com>

ARMv8.1 increases the PMU event number space. Detect the
presence of this PMUv3 type and extend the event mask.

The event mask is moved to struct arm_pmu so different event masks
can exist, depending on the PMU type.

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 arch/arm/kernel/perf_event_v6.c     |  6 ++++--
 arch/arm/kernel/perf_event_v7.c     | 29 +++++++++++++++++++----------
 arch/arm/kernel/perf_event_xscale.c |  4 +++-
 arch/arm64/kernel/perf_event.c      | 33 +++++++++++++++++++--------------
 drivers/perf/arm_pmu.c              |  5 +++--
 include/linux/perf/arm_pmu.h        |  4 ++--
 6 files changed, 50 insertions(+), 31 deletions(-)

diff --git a/arch/arm/kernel/perf_event_v6.c b/arch/arm/kernel/perf_event_v6.c
index 09413e7..d6769f5 100644
--- a/arch/arm/kernel/perf_event_v6.c
+++ b/arch/arm/kernel/perf_event_v6.c
@@ -481,7 +481,7 @@ static void armv6mpcore_pmu_disable_event(struct perf_event *event)
 static int armv6_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv6_perf_map,
-				&armv6_perf_cache_map, 0xFF);
+				&armv6_perf_cache_map);
 }
 
 static void armv6pmu_init(struct arm_pmu *cpu_pmu)
@@ -494,6 +494,7 @@ static void armv6pmu_init(struct arm_pmu *cpu_pmu)
 	cpu_pmu->get_event_idx	= armv6pmu_get_event_idx;
 	cpu_pmu->start		= armv6pmu_start;
 	cpu_pmu->stop		= armv6pmu_stop;
+	cpu_pmu->event_mask	= 0xFF;
 	cpu_pmu->map_event	= armv6_map_event;
 	cpu_pmu->num_events	= 3;
 	cpu_pmu->max_period	= (1LLU << 32) - 1;
@@ -531,7 +532,7 @@ static int armv6_1176_pmu_init(struct arm_pmu *cpu_pmu)
 static int armv6mpcore_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv6mpcore_perf_map,
-				&armv6mpcore_perf_cache_map, 0xFF);
+				&armv6mpcore_perf_cache_map);
 }
 
 static int armv6mpcore_pmu_init(struct arm_pmu *cpu_pmu)
@@ -545,6 +546,7 @@ static int armv6mpcore_pmu_init(struct arm_pmu *cpu_pmu)
 	cpu_pmu->get_event_idx	= armv6pmu_get_event_idx;
 	cpu_pmu->start		= armv6pmu_start;
 	cpu_pmu->stop		= armv6pmu_stop;
+	cpu_pmu->event_mask	= 0xFF;
 	cpu_pmu->map_event	= armv6mpcore_map_event;
 	cpu_pmu->num_events	= 3;
 	cpu_pmu->max_period	= (1LLU << 32) - 1;
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 4152158..8aab098 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -1042,7 +1042,7 @@ static int armv7pmu_get_event_idx(struct pmu_hw_events *cpuc,
 	int idx;
 	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
-	unsigned long evtype = hwc->config_base & ARMV7_EVTYPE_EVENT;
+	unsigned long evtype = hwc->config_base & cpu_pmu->event_mask;
 
 	/* Always place a cycle counter into the cycle counter. */
 	if (evtype == ARMV7_PERFCTR_CPU_CYCLES) {
@@ -1109,55 +1109,55 @@ static void armv7pmu_reset(void *info)
 static int armv7_a8_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv7_a8_perf_map,
-				&armv7_a8_perf_cache_map, 0xFF);
+				&armv7_a8_perf_cache_map);
 }
 
 static int armv7_a9_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv7_a9_perf_map,
-				&armv7_a9_perf_cache_map, 0xFF);
+				&armv7_a9_perf_cache_map);
 }
 
 static int armv7_a5_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv7_a5_perf_map,
-				&armv7_a5_perf_cache_map, 0xFF);
+				&armv7_a5_perf_cache_map);
 }
 
 static int armv7_a15_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv7_a15_perf_map,
-				&armv7_a15_perf_cache_map, 0xFF);
+				&armv7_a15_perf_cache_map);
 }
 
 static int armv7_a7_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv7_a7_perf_map,
-				&armv7_a7_perf_cache_map, 0xFF);
+				&armv7_a7_perf_cache_map);
 }
 
 static int armv7_a12_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv7_a12_perf_map,
-				&armv7_a12_perf_cache_map, 0xFF);
+				&armv7_a12_perf_cache_map);
 }
 
 static int krait_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &krait_perf_map,
-				&krait_perf_cache_map, 0xFFFFF);
+				&krait_perf_cache_map);
 }
 
 static int krait_map_event_no_branch(struct perf_event *event)
 {
 	return armpmu_map_event(event, &krait_perf_map_no_branch,
-				&krait_perf_cache_map, 0xFFFFF);
+				&krait_perf_cache_map);
 }
 
 static int scorpion_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &scorpion_perf_map,
-				&scorpion_perf_cache_map, 0xFFFFF);
+				&scorpion_perf_cache_map);
 }
 
 static void armv7pmu_init(struct arm_pmu *cpu_pmu)
@@ -1196,6 +1196,7 @@ static int armv7_a8_pmu_init(struct arm_pmu *cpu_pmu)
 {
 	armv7pmu_init(cpu_pmu);
 	cpu_pmu->name		= "armv7_cortex_a8";
+	cpu_pmu->event_mask	= ARMV7_EVTYPE_EVENT;
 	cpu_pmu->map_event	= armv7_a8_map_event;
 	cpu_pmu->pmu.attr_groups = armv7_pmuv1_attr_groups;
 	return armv7_probe_num_events(cpu_pmu);
@@ -1205,6 +1206,7 @@ static int armv7_a9_pmu_init(struct arm_pmu *cpu_pmu)
 {
 	armv7pmu_init(cpu_pmu);
 	cpu_pmu->name		= "armv7_cortex_a9";
+	cpu_pmu->event_mask	= ARMV7_EVTYPE_EVENT;
 	cpu_pmu->map_event	= armv7_a9_map_event;
 	cpu_pmu->pmu.attr_groups = armv7_pmuv1_attr_groups;
 	return armv7_probe_num_events(cpu_pmu);
@@ -1214,6 +1216,7 @@ static int armv7_a5_pmu_init(struct arm_pmu *cpu_pmu)
 {
 	armv7pmu_init(cpu_pmu);
 	cpu_pmu->name		= "armv7_cortex_a5";
+	cpu_pmu->event_mask	= ARMV7_EVTYPE_EVENT;
 	cpu_pmu->map_event	= armv7_a5_map_event;
 	cpu_pmu->pmu.attr_groups = armv7_pmuv1_attr_groups;
 	return armv7_probe_num_events(cpu_pmu);
@@ -1223,6 +1226,7 @@ static int armv7_a15_pmu_init(struct arm_pmu *cpu_pmu)
 {
 	armv7pmu_init(cpu_pmu);
 	cpu_pmu->name		= "armv7_cortex_a15";
+	cpu_pmu->event_mask	= ARMV7_EVTYPE_EVENT;
 	cpu_pmu->map_event	= armv7_a15_map_event;
 	cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
 	cpu_pmu->pmu.attr_groups = armv7_pmuv2_attr_groups;
@@ -1233,6 +1237,7 @@ static int armv7_a7_pmu_init(struct arm_pmu *cpu_pmu)
 {
 	armv7pmu_init(cpu_pmu);
 	cpu_pmu->name		= "armv7_cortex_a7";
+	cpu_pmu->event_mask	= ARMV7_EVTYPE_EVENT;
 	cpu_pmu->map_event	= armv7_a7_map_event;
 	cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
 	cpu_pmu->pmu.attr_groups = armv7_pmuv2_attr_groups;
@@ -1243,6 +1248,7 @@ static int armv7_a12_pmu_init(struct arm_pmu *cpu_pmu)
 {
 	armv7pmu_init(cpu_pmu);
 	cpu_pmu->name		= "armv7_cortex_a12";
+	cpu_pmu->event_mask	= ARMV7_EVTYPE_EVENT;
 	cpu_pmu->map_event	= armv7_a12_map_event;
 	cpu_pmu->set_event_filter = armv7pmu_set_event_filter;
 	cpu_pmu->pmu.attr_groups = armv7_pmuv2_attr_groups;
@@ -1628,6 +1634,7 @@ static int krait_pmu_init(struct arm_pmu *cpu_pmu)
 {
 	armv7pmu_init(cpu_pmu);
 	cpu_pmu->name		= "armv7_krait";
+	cpu_pmu->event_mask	= 0xFFFFF;
 	/* Some early versions of Krait don't support PC write events */
 	if (of_property_read_bool(cpu_pmu->plat_device->dev.of_node,
 				  "qcom,no-pc-write"))
@@ -1957,6 +1964,7 @@ static int scorpion_pmu_init(struct arm_pmu *cpu_pmu)
 {
 	armv7pmu_init(cpu_pmu);
 	cpu_pmu->name		= "armv7_scorpion";
+	cpu_pmu->event_mask	= 0xFFFFF;
 	cpu_pmu->map_event	= scorpion_map_event;
 	cpu_pmu->reset		= scorpion_pmu_reset;
 	cpu_pmu->enable		= scorpion_pmu_enable_event;
@@ -1970,6 +1978,7 @@ static int scorpion_mp_pmu_init(struct arm_pmu *cpu_pmu)
 {
 	armv7pmu_init(cpu_pmu);
 	cpu_pmu->name		= "armv7_scorpion_mp";
+	cpu_pmu->event_mask	= 0xFFFFF;
 	cpu_pmu->map_event	= scorpion_map_event;
 	cpu_pmu->reset		= scorpion_pmu_reset;
 	cpu_pmu->enable		= scorpion_pmu_enable_event;
diff --git a/arch/arm/kernel/perf_event_xscale.c b/arch/arm/kernel/perf_event_xscale.c
index aa0499e..8708691 100644
--- a/arch/arm/kernel/perf_event_xscale.c
+++ b/arch/arm/kernel/perf_event_xscale.c
@@ -358,7 +358,7 @@ static inline void xscale1pmu_write_counter(struct perf_event *event, u32 val)
 static int xscale_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &xscale_perf_map,
-				&xscale_perf_cache_map, 0xFF);
+				&xscale_perf_cache_map);
 }
 
 static int xscale1pmu_init(struct arm_pmu *cpu_pmu)
@@ -372,6 +372,7 @@ static int xscale1pmu_init(struct arm_pmu *cpu_pmu)
 	cpu_pmu->get_event_idx	= xscale1pmu_get_event_idx;
 	cpu_pmu->start		= xscale1pmu_start;
 	cpu_pmu->stop		= xscale1pmu_stop;
+	cpu_pmu->event_mask	= 0xFF;
 	cpu_pmu->map_event	= xscale_map_event;
 	cpu_pmu->num_events	= 3;
 	cpu_pmu->max_period	= (1LLU << 32) - 1;
@@ -742,6 +743,7 @@ static int xscale2pmu_init(struct arm_pmu *cpu_pmu)
 	cpu_pmu->get_event_idx	= xscale2pmu_get_event_idx;
 	cpu_pmu->start		= xscale2pmu_start;
 	cpu_pmu->stop		= xscale2pmu_stop;
+	cpu_pmu->event_mask	= 0xFF;
 	cpu_pmu->map_event	= xscale_map_event;
 	cpu_pmu->num_events	= 5;
 	cpu_pmu->max_period	= (1LLU << 32) - 1;
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 5e4275e..78b24cb 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -419,7 +419,7 @@ static const struct attribute_group *armv8_pmuv3_attr_groups[] = {
 /*
  * PMXEVTYPER: Event selection reg
  */
-#define	ARMV8_EVTYPE_MASK	0xc80003ff	/* Mask for writable bits */
+#define	ARMV8_EVTYPE_FLT_MASK	0xc8000000	/* Writable filter bits */
 #define	ARMV8_EVTYPE_EVENT	0x3ff		/* Mask for EVENT bits */
 
 /*
@@ -510,10 +510,8 @@ static inline void armv8pmu_write_counter(struct perf_event *event, u32 value)
 
 static inline void armv8pmu_write_evtype(int idx, u32 val)
 {
-	if (armv8pmu_select_counter(idx) == idx) {
-		val &= ARMV8_EVTYPE_MASK;
+	if (armv8pmu_select_counter(idx) == idx)
 		asm volatile("msr pmxevtyper_el0, %0" :: "r" (val));
-	}
 }
 
 static inline int armv8pmu_enable_counter(int idx)
@@ -570,6 +568,7 @@ static void armv8pmu_enable_event(struct perf_event *event)
 	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
 	struct pmu_hw_events *events = this_cpu_ptr(cpu_pmu->hw_events);
 	int idx = hwc->idx;
+	u32 val;
 
 	/*
 	 * Enable counter and interrupt, and set the counter to count
@@ -585,7 +584,8 @@ static void armv8pmu_enable_event(struct perf_event *event)
 	/*
 	 * Set event (if destined for PMNx counters).
 	 */
-	armv8pmu_write_evtype(idx, hwc->config_base);
+	val = hwc->config_base & (ARMV8_EVTYPE_FLT_MASK | cpu_pmu->event_mask);
+	armv8pmu_write_evtype(idx, val);
 
 	/*
 	 * Enable interrupt for this counter
@@ -716,7 +716,7 @@ static int armv8pmu_get_event_idx(struct pmu_hw_events *cpuc,
 	int idx;
 	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
-	unsigned long evtype = hwc->config_base & ARMV8_EVTYPE_EVENT;
+	unsigned long evtype = hwc->config_base & cpu_pmu->event_mask;
 
 	/* Always place a cycle counter into the cycle counter. */
 	if (evtype == ARMV8_PMUV3_PERFCTR_CLOCK_CYCLES) {
@@ -786,29 +786,25 @@ static void armv8pmu_reset(void *info)
 static int armv8_pmuv3_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv8_pmuv3_perf_map,
-				&armv8_pmuv3_perf_cache_map,
-				ARMV8_EVTYPE_EVENT);
+				&armv8_pmuv3_perf_cache_map);
 }
 
 static int armv8_a53_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv8_a53_perf_map,
-				&armv8_a53_perf_cache_map,
-				ARMV8_EVTYPE_EVENT);
+				&armv8_a53_perf_cache_map);
 }
 
 static int armv8_a57_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv8_a57_perf_map,
-				&armv8_a57_perf_cache_map,
-				ARMV8_EVTYPE_EVENT);
+				&armv8_a57_perf_cache_map);
 }
 
 static int armv8_thunder_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv8_thunder_perf_map,
-				&armv8_thunder_perf_cache_map,
-				ARMV8_EVTYPE_EVENT);
+				&armv8_thunder_perf_cache_map);
 }
 
 static void armv8pmu_read_num_pmnc_events(void *info)
@@ -831,6 +827,8 @@ static int armv8pmu_probe_num_events(struct arm_pmu *arm_pmu)
 
 static void armv8_pmu_init(struct arm_pmu *cpu_pmu)
 {
+	u64 id;
+
 	cpu_pmu->handle_irq		= armv8pmu_handle_irq,
 	cpu_pmu->enable			= armv8pmu_enable_event,
 	cpu_pmu->disable		= armv8pmu_disable_event,
@@ -842,6 +840,13 @@ static void armv8_pmu_init(struct arm_pmu *cpu_pmu)
 	cpu_pmu->reset			= armv8pmu_reset,
 	cpu_pmu->max_period		= (1LLU << 32) - 1,
 	cpu_pmu->set_event_filter	= armv8pmu_set_event_filter;
+
+	/* detect ARMv8.1 PMUv3 with extended event mask */
+	id = read_cpuid(ID_AA64DFR0_EL1);
+	if (((id >> 8) & 0xf) == 4)
+		cpu_pmu->event_mask = 0xffff;	/* ARMv8.1 extended events */
+	else
+		cpu_pmu->event_mask = ARMV8_EVTYPE_EVENT;
 }
 
 static int armv8_pmuv3_init(struct arm_pmu *cpu_pmu)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 166637f..79e681f 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -79,9 +79,10 @@ armpmu_map_event(struct perf_event *event,
 		 const unsigned (*cache_map)
 				[PERF_COUNT_HW_CACHE_MAX]
 				[PERF_COUNT_HW_CACHE_OP_MAX]
-				[PERF_COUNT_HW_CACHE_RESULT_MAX],
-		 u32 raw_event_mask)
+				[PERF_COUNT_HW_CACHE_RESULT_MAX])
 {
+	struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
+	u32 raw_event_mask = armpmu->event_mask;
 	u64 config = event->attr.config;
 	int type = event->attr.type;
 
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 83b5e34..9a4c3a9 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -101,6 +101,7 @@ struct arm_pmu {
 	void		(*free_irq)(struct arm_pmu *);
 	int		(*map_event)(struct perf_event *event);
 	int		num_events;
+	int		event_mask;
 	atomic_t	active_events;
 	struct mutex	reserve_mutex;
 	u64		max_period;
@@ -119,8 +120,7 @@ int armpmu_map_event(struct perf_event *event,
 		     const unsigned (*event_map)[PERF_COUNT_HW_MAX],
 		     const unsigned (*cache_map)[PERF_COUNT_HW_CACHE_MAX]
 						[PERF_COUNT_HW_CACHE_OP_MAX]
-						[PERF_COUNT_HW_CACHE_RESULT_MAX],
-		     u32 raw_event_mask);
+						[PERF_COUNT_HW_CACHE_RESULT_MAX]);
 
 struct pmu_probe_info {
 	unsigned int cpuid;
-- 
1.9.1



From broonie at kernel.org  Wed Feb  3 09:15:03 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 3 Feb 2016 17:15:03 +0000
Subject: [PATCH 06/11] regulator: axp20x: support AXP809 variant
In-Reply-To: <1454408864-24112-7-git-send-email-wens@csie.org>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-7-git-send-email-wens@csie.org>
Message-ID: <20160203171503.GH4455@sirena.org.uk>

On Tue, Feb 02, 2016 at 06:27:39PM +0800, Chen-Yu Tsai wrote:
> The X-Powers AXP809 PMIC has a similar set of regulators as the AXP221,
> though a few LDOs were removed, and a new switch output added. Like the
> AXP221, AXP809 also has DC1SW and DC5LDO, which are internally chained
> to DCDC1 and DCDC5, respectively.

This looks OK to me.  Will there be a branch with the new IDs in it that
I can pull in to apply it?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/8b6473ba/attachment.sig>

From catalin.marinas at arm.com  Wed Feb  3 09:15:42 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 3 Feb 2016 17:15:42 +0000
Subject: [PATCH v4 4/7] arm64: Handle early CPU boot failures
In-Reply-To: <20160203170114.GD1234@leverpostej>
References: <1453745225-27736-1-git-send-email-suzuki.poulose@arm.com>
 <1453745225-27736-5-git-send-email-suzuki.poulose@arm.com>
 <20160203170114.GD1234@leverpostej>
Message-ID: <20160203171541.GC26487@MBP.local>

On Wed, Feb 03, 2016 at 05:01:15PM +0000, Mark Rutland wrote:
> On Mon, Jan 25, 2016 at 06:07:02PM +0000, Suzuki K Poulose wrote:
> > From: Suzuki K. Poulose <suzuki.poulose at arm.com>
> > 
> > A secondary CPU could fail to come online due to insufficient
> > capabilities and could simply die or loop in the kernel.
> > e.g, a CPU with no support for the selected kernel PAGE_SIZE
> > loops in kernel with MMU turned off.
> > or a hotplugged CPU which doesn't have one of the advertised
> > system capability will die during the activation.
> > 
> > There is no way to synchronise the status of the failing CPU
> > back to the master. This patch solves the issue by adding a
> > field to the secondary_data which can be updated by the failing
> > CPU. If the secondary CPU fails even before turning the MMU on,
> > it updates the status in a special variable reserved in the head.txt
> > section to make sure that the update can be cache invalidated safely
> > without possible sharing of cache write back granule.
> > 
> > Here are the possible states :
> > 
> >  -1. CPU_MMU_OFF - Initial value set by the master CPU, this value
> > indicates that the CPU could not turn the MMU on, hence the status
> > could not be reliably updated in the secondary_data. Instead, the
> > CPU has updated the status in __early_cpu_boot_status (reserved in
> > head.txt section)
> > 
> >  0. CPU_BOOT_SUCCESS - CPU has booted successfully.
> > 
> >  1. CPU_KILL_ME - CPU has invoked cpu_ops->die, indicating the
> > master CPU to synchronise by issuing a cpu_ops->cpu_kill.
> > 
> >  2. CPU_STUCK_IN_KERNEL - CPU couldn't invoke die(), instead is
> > looping in the kernel. This information could be used by say,
> > kexec to check if it is really safe to do a kexec reboot.
> > 
> >  3. CPU_PANIC_KERNEL - CPU detected some serious issues which
> > requires kernel to crash immediately. The secondary CPU cannot
> > call panic() until it has initialised the GIC. This flag can
> > be used to instruct the master to do so.
> 
> When would we use this last case?

It's used in a subsequent series when verifying the ASID bits. I haven't
followed the previous discussions but I guess Suzuki aims to panic the
whole kernel rather than just stop the current CPU when incompatible
ASID size is found.

-- 
Catalin


From rafael at kernel.org  Wed Feb  3 09:16:33 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Wed, 3 Feb 2016 18:16:33 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFoNY8xP11n6mFVicYwdy49sB4=H0fTm53754HukFX4HBQ@mail.gmail.com>
References: <CAPDyKFpNRc3Nf9ofXhZrfBa54vXMxWboDScCrYFrZy97m8Y5gg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602031034360.2041-100000@iolanthe.rowland.org>
 <20160203160951.GF19432@atomide.com>
 <CAPDyKFoNY8xP11n6mFVicYwdy49sB4=H0fTm53754HukFX4HBQ@mail.gmail.com>
Message-ID: <CAJZ5v0jcLb0ckR53h3RAqRJsfXTkMeFtkkqT2rX66kWZWH1x3A@mail.gmail.com>

On Wed, Feb 3, 2016 at 5:24 PM, Ulf Hansson <ulf.hansson at linaro.org> wrote:
> On 3 February 2016 at 17:09, Tony Lindgren <tony at atomide.com> wrote:
>> * Alan Stern <stern at rowland.harvard.edu> [160203 07:46]:
>>> On Wed, 3 Feb 2016, Ulf Hansson wrote:
>>>
>>> > > Let me summarize my understanding of this thread so far.
>>> > >
>>> > > It looks like the omap3 code initializes hardware in ->probe() and
>>> > > then it may return -EPROBE_DEFER due to some unmet dependencies.  In
>>> > > that case the hardware is not reset to the previous state and the
>>> > > runtime PM framework is left in the state that corresponds to the
>>> > > current hardware state.  Before we had pm_runtime_reinit(), everything
>>> > > worked as expected on the second ->probe() call, because things were
>>> > > in sync then.
>>> >
>>> > Correct!
>>
>> Well not quite correct. After failed probe PM runtime is set to reset
>> state while hardware is still enabled.
>
> Yes, but that's *after* pm_runtime_reinit() was added.
>
> I think Rafael was thinking about how it worked *before*.

Right.

Thanks,
Rafael


From rafael at kernel.org  Wed Feb  3 09:18:51 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Wed, 3 Feb 2016 18:18:51 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160202234626.GD19432@atomide.com>
References: <20160202210345.GZ19432@atomide.com>
 <Pine.LNX.4.44L0.1602021626540.1653-100000@iolanthe.rowland.org>
 <20160202234626.GD19432@atomide.com>
Message-ID: <CAJZ5v0hdDdFDiieDnsjummg6F+nV7fi=gFa=oFweyP7-ApsHrQ@mail.gmail.com>

On Wed, Feb 3, 2016 at 12:46 AM, Tony Lindgren <tony at atomide.com> wrote:
> * Alan Stern <stern at rowland.harvard.edu> [160202 13:46]:
>> On Tue, 2 Feb 2016, Tony Lindgren wrote:
>>
>> > > Also, what is autosuspend_delay set to for your device?  And is
>> > > runtime_auto set?
>> >
>> > It's 100 at that point, see the commented snippet below from
>> > omap_hsmmc_probe():
>> >
>> >     pm_runtime_enable(host->dev);
>> >     pm_runtime_get_sync(host->dev);
>> >     pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY);
>> >     /* NOTE: pm_runtime_dont_use_autosuspend(host->dev) needed here? */
>> >     pm_runtime_use_autosuspend(host->dev);
>> >     ...
>> >     /* gets -EPROBE_DEFER */
>> > err_irq:
>> >     ...
>> >     pm_runtime_put_sync(host->dev);
>>
>> You could try changing this to pm_runtime_put_sync_suspend().  But
>> putting pm_runtime_dont_use_autosuspend() before the put_sync seems
>> like a perfectly reasonable thing to do, especially if you feel you
>> should reverse all the changes you made at the start.

FWIW, I'd call pm_runtime_dont_use_autosuspend() before put_sync().

After all, the driver doesn't want to use autosuspend going forward,
so stating that explicitly looks like the right thing to do.

Thanks,
Rafael


From fu.wei at linaro.org  Wed Feb  3 09:18:38 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Thu,  4 Feb 2016 01:18:38 +0800
Subject: [PATCH v10 0/5] Watchdog: introduce ARM SBSA watchdog driver
Message-ID: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This patchset:
    (1)Introduce Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
    for FDT info of SBSA Generic Watchdog, and give two examples of
    adding SBSA Generic Watchdog device node into the dts files:
    foundation-v8.dts and amd-seattle-soc.dtsi.

    (2)Introduce ARM SBSA watchdog driver:
        a.Use linux kernel watchdog framework;
        b.Work with FDT on ARM64;
        c.Support getting timeout from parameter and FDT at the driver
          init stage.
        d.Separate the driver to two parts:
          (1) single stage timeout driver(ignore WS0 interrupt)
          (2) register WS0 interrupt for the half timeout panic
        e.Timeout is from watchdog enabled to WS1 triggered.
          User can disable "half timeout panic" by kernel config or
          module parameter panic_enabled.

Changelog:
v10:Delete pretimeout support
    Separate the driver to two parts:
        (1) single stage timeout driver(ignore WS0 interrupt)
        (2) register WS0 interrupt for the half timeout panic
    timeout == (enable --> WS1)

v9: https://lkml.org/lkml/2015/11/9/57
    Rebase to latest kernel version(4.3).
    Update the Documentation of sbsa-gwdt device node info of FDT:
        (1) move some introduction to pretimeout patch
        (2) delete WS1 value from "interrupts" of binding documentation,
            since WS1 won't be handled by Linux.

v8: https://lkml.org/lkml/2015/10/27/466
    Rebase to latest kernel version(4.3-rc7).
    Separate the patches of GTDT support and arm_arch_timer. This
    clocksource relevant patch will upstreamed in a individual patchset.
    Update all the default timeout and pretimeout to 30s and 60s.
    Improve documentation and inline comments.
    Fix a bug in pretimeout support which makes timeout and pretimeout
    parameters initialization fail.

v7: https://lkml.org/lkml/2015/8/24/611
    Rebase to latest kernel version(4.2-rc7).
    Improve FDT support: geting resource by order, instead of name.
    According to the FDT support, Update the example dts file, gtdt.c
    and sbsa_gwdt.c.
    Pass the sparse test, and fix the warning.
    Fix the max_pretimeout and max_timeout value overflow bug.
    Delete the WCV output value.
    

v6: https://lkml.org/lkml/2015/6/23/359
    Improve the dtb example files: reduce the register frame size to 4K.
    Improve pretimeout support:
        (1) improve watchdog_init_timeouts function
	(2) rename watchdog_check_min_max_timeouts back to the original name
        (1) improve watchdog_timeout_invalid/watchdog_pretimeout_invalid
    Add the new features in the sbsa_gwdt driver:
	(1) In the second stage, user can feed the dog without cleaning WS0.
	(2) In the second stage, user can trigger WS1 by setting pretimeout = 0.
	(3) expand the max value of pretimeout, in case 10 second is not enough
	    for a kdump kernel reboot in panic.

v5: https://lkml.org/lkml/2015/6/10/357
    Improve pretimeout support:
        (1)fix typo in documentation and comments.
	(2)fix the timeout limits validation bug.
    Simplify sbsa_gwdt driver:
	(1)integrate all the registers access functions into caller.

v4: https://lkml.org/lkml/2015/6/2/4
    Refactor GTDT support code: remove it from arch/arm64/kernel/acpi.c,
    put it into drivers/acpi/gtdt.c file.
    Integrate the GTDT code of drivers/clocksource/arm_arch_timer.c into
    drivers/acpi/gtdt.c.
    Improve pretimeout support, fix "pretimeout == 0" problem.
    Simplify sbsa_gwdt driver:
        (1)timeout/pretimeout limits setup;
        (2)keepalive function;
        (3)delete "clk == 0" check;
        (4)delete WS0 status bit check in interrupt routine;
        (5)sbsa_gwdt_set_wcv function.

v3: https://lkml.org/lkml/2015/5/25/111
    Delete "export arch_timer_get_rate" patch.
    Driver back to use arch_timer_get_cntfrq.
    Improve watchdog_init_timeouts function and update relevant documentation.
    Improve watchdog_timeout_invalid and watchdog_pretimeout_invalid.
    Improve foundation-v8.dts: delete the unnecessary tag of device node.
    Remove "ARM64 || COMPILE_TEST" from Kconfig.
    Add comments in arch/arm64/kernel/acpi.c
    Fix typoes and incorrect comments.

v2: https://lkml.org/lkml/2015/5/21/172
    Improve watchdog-kernel-api.txt documentation for pretimeout support.
    Export "arch_timer_get_rate" in arm_arch_timer.c.
    Add watchdog_init_timeouts API for pretimeout support in framework.
    Improve suspend and resume foundation in driver
    Improve timeout/pretimeout values init code in driver.
    Delete unnecessary items of the sbsa_gwdt struct and #define.
    Delete all unnecessary debug info in driver.
    Fix 64bit division bug.
    Use the arch_timer interface to get watchdog clock rate.
    Add MODULE_DEVICE_TABLE for platform device id.
    Fix typoes.

v1: https://lkml.org/lkml/2015/5/15/279
    The first version upstream patchset to linux mailing list.

Fu Wei (5):
  Documentation: add sbsa-gwdt driver documentation
  ARM64: add SBSA Generic Watchdog device node in foundation-v8.dts
  ARM64: add SBSA Generic Watchdog device node in amd-seattle-soc.dtsi
  Watchdog: introduce ARM SBSA watchdog driver
  Watchdog: ARM SBSA Generic Watchdog half timeout panic support

 .../devicetree/bindings/watchdog/sbsa-gwdt.txt     |  35 ++
 Documentation/watchdog/watchdog-parameters.txt     |   6 +
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi       |   9 +
 arch/arm64/boot/dts/arm/foundation-v8.dts          |   8 +
 drivers/watchdog/Kconfig                           |  27 ++
 drivers/watchdog/Makefile                          |   1 +
 drivers/watchdog/sbsa_gwdt.c                       | 366 +++++++++++++++++++++
 7 files changed, 452 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
 create mode 100644 drivers/watchdog/sbsa_gwdt.c

-- 
2.5.0



From fu.wei at linaro.org  Wed Feb  3 09:18:39 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Thu,  4 Feb 2016 01:18:39 +0800
Subject: [PATCH v10 1/5] Documentation: add sbsa-gwdt driver documentation
In-Reply-To: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1454519923-25230-2-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

The sbsa-gwdt.txt documentation in devicetree/bindings/watchdog is for
introducing SBSA(Server Base System Architecture) Generic Watchdog
device node info into FDT.

Also add sbsa-gwdt introduction in watchdog-parameters.txt

Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Fu Wei <fu.wei at linaro.org>
---
 .../devicetree/bindings/watchdog/sbsa-gwdt.txt     | 35 ++++++++++++++++++++++
 Documentation/watchdog/watchdog-parameters.txt     |  5 ++++
 2 files changed, 40 insertions(+)

diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
new file mode 100644
index 0000000..73a5d0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
@@ -0,0 +1,35 @@
+* SBSA (Server Base System Architecture) Generic Watchdog
+
+The SBSA Generic Watchdog Timer is used to force a reset of the system
+after two stages of timeout have elapsed.  A detailed definition of the
+watchdog timer can be found in the ARM document: ARM-DEN-0029 - Server
+Base System Architecture (SBSA)
+
+Required properties:
+- compatible: Should at least contain "arm,sbsa-gwdt".
+
+- reg: Each entry specifies the base physical address of a register frame
+  and the length of that frame; currently, two frames must be defined,
+  in this order:
+  1: Watchdog control frame;
+  2: Refresh frame.
+
+- interrupts: Should contain the Watchdog Signal 0 (WS0) SPI (Shared
+  Peripheral Interrupt) number of SBSA Generic Watchdog.
+
+Optional properties
+- timeout-sec: Watchdog timeout values (in seconds).
+
+- status: Indicates the device is not available for use. Should be "okay"
+  or "disabled" for available/unavailable. Default is "okay".
+
+Example for FVP Foundation Model v8:
+
+watchdog at 2a440000 {
+	compatible = "arm,sbsa-gwdt";
+	reg = <0x0 0x2a440000 0 0x1000>,
+	      <0x0 0x2a450000 0 0x1000>;
+	interrupts = <0 27 4>;
+	timeout-sec = <30>;
+	status = "okay";
+};
diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
index 9f9ec9f..300eb4d 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -284,6 +284,11 @@ sbc_fitpc2_wdt:
 margin: Watchdog margin in seconds (default 60s)
 nowayout: Watchdog cannot be stopped once started
 -------------------------------------------------
+sbsa_gwdt:
+timeout: Watchdog timeout in seconds. (default 20s)
+nowayout: Watchdog cannot be stopped once started
+	(default=kernel config parameter)
+-------------------------------------------------
 sc1200wdt:
 isapnp: When set to 0 driver ISA PnP support will be disabled (default=1)
 io: io port
-- 
2.5.0



From dirk.behme at gmail.com  Wed Feb  3 09:20:52 2016
From: dirk.behme at gmail.com (Dirk Behme)
Date: Wed, 3 Feb 2016 18:20:52 +0100
Subject: [PATCH v2] arm64: dts: r8a7795: pmu: switch to Cortex specific
 device nodes
In-Reply-To: <1452953636-4995-1-git-send-email-dirk.behme@gmail.com>
References: <1452953636-4995-1-git-send-email-dirk.behme@gmail.com>
Message-ID: <56B236F4.4090409@gmail.com>

On 16.01.2016 15:13, Dirk Behme wrote:
> Instead of using the generic armv8-pmuv3 compatibility use the more
> specific Cortex A57 compatibility.
>
> Signed-off-by: Dirk Behme <dirk.behme at gmail.com>
> ---
> Changes in v2: Drop the not yet merged Cortex A53 part.
>
>   arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index 266c5de..a82bce8 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -247,8 +247,8 @@
>   			power-domains = <&cpg>;
>   		};
>
> -		pmu {
> -			compatible = "arm,armv8-pmuv3";
> +		pmu_a57 {
> +			compatible = "arm,cortex-a57-pmu";
>   			interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
>   				     <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
>   				     <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
>


Any further comments to this? If not, could this be applied?

Best regards

Dirk


From fu.wei at linaro.org  Wed Feb  3 09:18:40 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Thu,  4 Feb 2016 01:18:40 +0800
Subject: [PATCH v10 2/5] ARM64: add SBSA Generic Watchdog device node in
 foundation-v8.dts
In-Reply-To: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1454519923-25230-3-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Fu Wei <fu.wei at linaro.org>
---
 arch/arm64/boot/dts/arm/foundation-v8.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dts b/arch/arm64/boot/dts/arm/foundation-v8.dts
index 4eac8dc..75da16b 100644
--- a/arch/arm64/boot/dts/arm/foundation-v8.dts
+++ b/arch/arm64/boot/dts/arm/foundation-v8.dts
@@ -237,4 +237,12 @@
 			};
 		};
 	};
+	watchdog at 2a440000 {
+		compatible = "arm,sbsa-gwdt";
+		reg = <0x0 0x2a440000 0 0x1000>,
+			<0x0 0x2a450000 0 0x1000>;
+		interrupts = <0 27 4>;
+		timeout-sec = <30>;
+		status = "okay";
+	};
 };
-- 
2.5.0



From dirk.behme at gmail.com  Wed Feb  3 09:21:17 2016
From: dirk.behme at gmail.com (Dirk Behme)
Date: Wed, 3 Feb 2016 18:21:17 +0100
Subject: [PATCH v2] arm64: dts: r8a7795: Add L2 cache-controller nodes
In-Reply-To: <1452953856-5146-1-git-send-email-dirk.behme@gmail.com>
References: <1452953856-5146-1-git-send-email-dirk.behme@gmail.com>
Message-ID: <56B2370D.2010102@gmail.com>

On 16.01.2016 15:17, Dirk Behme wrote:
> From: Geert Uytterhoeven <geert+renesas at glider.be>
>
> Add device nodes for the L2 caches, and link the CPU node to its L2
> cache node.
>
> The L2 cache for the Cortex-A57 CPU cores is 2 MiB large (organized as
> 128 KiB x 16 ways).
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> Signed-off-by: Dirk Behme <dirk.behme at gmail.com>
> ---
> Changes in v2: Dropped the not yet merged Cortex A53 part.
>
>   arch/arm64/boot/dts/renesas/r8a7795.dtsi | 8 ++++++++
>   1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index a82bce8..a22ae65 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -39,6 +39,7 @@
>   			compatible = "arm,cortex-a57", "arm,armv8";
>   			reg = <0x0>;
>   			device_type = "cpu";
> +			next-level-cache = <&L2_CA57>;
>   			enable-method = "psci";
>   		};
>
> @@ -46,22 +47,29 @@
>   			compatible = "arm,cortex-a57","arm,armv8";
>   			reg = <0x1>;
>   			device_type = "cpu";
> +			next-level-cache = <&L2_CA57>;
>   			enable-method = "psci";
>   		};
>   		a57_2: cpu at 2 {
>   			compatible = "arm,cortex-a57","arm,armv8";
>   			reg = <0x2>;
>   			device_type = "cpu";
> +			next-level-cache = <&L2_CA57>;
>   			enable-method = "psci";
>   		};
>   		a57_3: cpu at 3 {
>   			compatible = "arm,cortex-a57","arm,armv8";
>   			reg = <0x3>;
>   			device_type = "cpu";
> +			next-level-cache = <&L2_CA57>;
>   			enable-method = "psci";
>   		};
>   	};
>
> +	L2_CA57: cache-controller at 0 {
> +		compatible = "cache";
> +	};
> +
>   	extal_clk: extal {
>   		compatible = "fixed-clock";
>   		#clock-cells = <0>;
>


Any further comments to this? If not, could this be applied?

Best regards

Dirk


From fu.wei at linaro.org  Wed Feb  3 09:18:41 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Thu,  4 Feb 2016 01:18:41 +0800
Subject: [PATCH v10 3/5] ARM64: add SBSA Generic Watchdog device node in
 amd-seattle-soc.dtsi
In-Reply-To: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1454519923-25230-4-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Signed-off-by: Fu Wei <fu.wei at linaro.org>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 2874d92..057e9c0 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -84,6 +84,15 @@
 			clock-names = "uartclk", "apb_pclk";
 		};
 
+		watchdog0: watchdog at e0bb0000 {
+			compatible = "arm,sbsa-gwdt";
+			reg = <0x0 0xe0bc0000 0 0x1000>,
+				<0x0 0xe0bb0000 0 0x1000>;
+			interrupts = <0 337 4>;
+			timeout-sec = <30>;
+			status = "disabled";
+		};
+
 		spi0: ssp at e1020000 {
 			status = "disabled";
 			compatible = "arm,pl022", "arm,primecell";
-- 
2.5.0



From fu.wei at linaro.org  Wed Feb  3 09:18:42 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Thu,  4 Feb 2016 01:18:42 +0800
Subject: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1454519923-25230-5-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

According to Server Base System Architecture (SBSA) specification,
the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0)
is for alerting the system by interrupt, the second one (WS1) is a real
hardware reset.

This patch initially implements a simple single stage watchdog driver:
when the timeout is reached, your system will be reset by the second
signal (WS1).
The first signal (WS0) is ignored in this driver.

This driver bases on linux kernel watchdog framework, so it can get
timeout from module parameter and FDT at the driver init stage.

Signed-off-by: Fu Wei <fu.wei at linaro.org>
Reviewed-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Pratyush Anand <panand at redhat.com>
---
 drivers/watchdog/Kconfig     |  17 +++
 drivers/watchdog/Makefile    |   1 +
 drivers/watchdog/sbsa_gwdt.c | 322 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 340 insertions(+)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 4f0e7be..4ab1b05 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -201,6 +201,23 @@ config ARM_SP805_WATCHDOG
 	  ARM Primecell SP805 Watchdog timer. This will reboot your system when
 	  the timeout is reached.
 
+config ARM_SBSA_WATCHDOG
+	tristate "ARM SBSA Generic Watchdog"
+	depends on ARM64
+	depends on ARM_ARCH_TIMER
+	select WATCHDOG_CORE
+	help
+	  ARM SBSA Generic Watchdog has two stage timeouts:
+	  the first signal (WS0) is for alerting the system by interrupt,
+	  the second one (WS1) is a real hardware reset.
+	  More details: ARM DEN0029B - Server Base System Architecture (SBSA)
+
+	  This is a simple single stage driver: when the timeout is reached,
+	  your system will be reset by WS1. The first signal (WS0) is ignored.
+
+	  To compile this driver as module, choose M here: The module
+	  will be called sbsa_gwdt.
+
 config ASM9260_WATCHDOG
 	tristate "Alphascale ASM9260 watchdog"
 	depends on MACH_ASM9260
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index f566753..f9826d4 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
 
 # ARM Architecture
 obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
+obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
 obj-$(CONFIG_ASM9260_WATCHDOG) += asm9260_wdt.o
 obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
 obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
new file mode 100644
index 0000000..5a2dba3
--- /dev/null
+++ b/drivers/watchdog/sbsa_gwdt.c
@@ -0,0 +1,322 @@
+/*
+ * SBSA(Server Base System Architecture) Generic Watchdog driver
+ *
+ * Copyright (c) 2015, Linaro Ltd.
+ * Author: Fu Wei <fu.wei at linaro.org>
+ *         Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
+ *         Al Stone <al.stone at linaro.org>
+ *         Timur Tabi <timur at codeaurora.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License 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.
+ *
+ * This SBSA Generic watchdog driver is a single stage timeout version.
+ * Since this watchdog timer has two stages, and each stage is determined
+ * by WOR. So the timeout is (WOR * 2).
+ * When first timeout is reached, WS0 is triggered, the interrupt
+ * triggered by WS0 will be ignored, then the second watch period starts;
+ * when second timeout is reached, then WS1 is triggered, system reset.
+ *
+ * More details about the hardware specification of this device:
+ * ARM DEN0029B - Server Base System Architecture (SBSA)
+ *
+ * SBSA GWDT: |--------WOR-------WS0--------WOR-------WS1
+ *            |----------------timeout----------------reset
+ *
+ */
+
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/uaccess.h>
+#include <linux/watchdog.h>
+#include <asm/arch_timer.h>
+
+/* SBSA Generic Watchdog register definitions */
+/* refresh frame */
+#define SBSA_GWDT_WRR				0x000
+
+/* control frame */
+#define SBSA_GWDT_WCS				0x000
+#define SBSA_GWDT_WOR				0x008
+#define SBSA_GWDT_WCV				0x010
+
+/* refresh/control frame */
+#define SBSA_GWDT_W_IIDR			0xfcc
+#define SBSA_GWDT_IDR				0xfd0
+
+/* Watchdog Control and Status Register */
+#define SBSA_GWDT_WCS_EN			BIT(0)
+#define SBSA_GWDT_WCS_WS0			BIT(1)
+#define SBSA_GWDT_WCS_WS1			BIT(2)
+
+/**
+ * struct sbsa_gwdt - Internal representation of the SBSA GWDT
+ * @wdd:		kernel watchdog_device structure
+ * @clk:		store the System Counter clock frequency, in Hz.
+ * @refresh_base:	Virtual address of the watchdog refresh frame
+ * @control_base:	Virtual address of the watchdog control frame
+ */
+struct sbsa_gwdt {
+	struct watchdog_device	wdd;
+	u32			clk;
+	void __iomem		*refresh_base;
+	void __iomem		*control_base;
+};
+
+#define to_sbsa_gwdt(e) container_of(e, struct sbsa_gwdt, wdd)
+
+#define DEFAULT_TIMEOUT		20 /* seconds, the 1st + 2nd watch periods*/
+
+static unsigned int timeout;
+module_param(timeout, uint, 0);
+MODULE_PARM_DESC(timeout,
+		 "Watchdog timeout in seconds. (>=0, default="
+		 __MODULE_STRING(DEFAULT_TIMEOUT) ")");
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, S_IRUGO);
+MODULE_PARM_DESC(nowayout,
+		 "Watchdog cannot be stopped once started (default="
+		 __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+/*
+ * watchdog operation functions
+ */
+static int sbsa_gwdt_set_timeout(struct watchdog_device *wdd,
+				 unsigned int timeout)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	wdd->timeout = timeout;
+	writel(timeout / 2 * gwdt->clk, gwdt->control_base + SBSA_GWDT_WOR);
+
+	return 0;
+}
+
+static unsigned int sbsa_gwdt_get_timeleft(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+	u64 timeleft = readq(gwdt->control_base + SBSA_GWDT_WCV) -
+		       arch_counter_get_cntvct();
+
+	do_div(timeleft, gwdt->clk);
+
+	if (readl(gwdt->control_base + SBSA_GWDT_WCS) & SBSA_GWDT_WCS_WS0)
+		return timeleft;
+
+	return timeleft + wdd->timeout / 2;
+}
+
+static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	/*
+	* Writing WRR for an explicit watchdog refresh.
+	* You can write anyting(like 0xc0ffee).
+	*/
+	writel(0xc0ffee, gwdt->refresh_base + SBSA_GWDT_WRR);
+
+	return 0;
+}
+
+static unsigned int sbsa_gwdt_status(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+	u32 status = readl(gwdt->control_base + SBSA_GWDT_WCS);
+
+	/* is the watchdog timer running? */
+	return (status & SBSA_GWDT_WCS_EN) << WDOG_ACTIVE;
+}
+
+static int sbsa_gwdt_start(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	/* writing WCS will cause an explicit watchdog refresh */
+	writel(SBSA_GWDT_WCS_EN, gwdt->control_base + SBSA_GWDT_WCS);
+
+	return sbsa_gwdt_keepalive(wdd);
+}
+
+static int sbsa_gwdt_stop(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	writel(0, gwdt->control_base + SBSA_GWDT_WCS);
+
+	return 0;
+}
+
+static struct watchdog_info sbsa_gwdt_info = {
+	.identity	= "SBSA Generic Watchdog",
+	.options	= WDIOF_SETTIMEOUT |
+			  WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE |
+			  WDIOF_CARDRESET,
+};
+
+static struct watchdog_ops sbsa_gwdt_ops = {
+	.owner		= THIS_MODULE,
+	.start		= sbsa_gwdt_start,
+	.stop		= sbsa_gwdt_stop,
+	.status		= sbsa_gwdt_status,
+	.ping		= sbsa_gwdt_keepalive,
+	.set_timeout	= sbsa_gwdt_set_timeout,
+	.get_timeleft	= sbsa_gwdt_get_timeleft,
+};
+
+static int sbsa_gwdt_probe(struct platform_device *pdev)
+{
+	void __iomem *rf_base, *cf_base;
+	struct device *dev = &pdev->dev;
+	struct watchdog_device *wdd;
+	struct sbsa_gwdt *gwdt;
+	struct resource *res;
+	u32 status;
+	int ret;
+
+	gwdt = devm_kzalloc(dev, sizeof(*gwdt), GFP_KERNEL);
+	if (!gwdt)
+		return -ENOMEM;
+	platform_set_drvdata(pdev, gwdt);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	cf_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(cf_base))
+		return PTR_ERR(cf_base);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	rf_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(rf_base))
+		return PTR_ERR(rf_base);
+
+	/*
+	 * Get the frequency of system counter from the cp15 interface of ARM
+	 * Generic timer. We don't need to check it, because if it returns "0",
+	 * system would panic in very early stage.
+	 */
+	gwdt->clk = arch_timer_get_cntfrq();
+	gwdt->refresh_base = rf_base;
+	gwdt->control_base = cf_base;
+
+	wdd = &gwdt->wdd;
+	wdd->parent = dev;
+	wdd->info = &sbsa_gwdt_info;
+	wdd->ops = &sbsa_gwdt_ops;
+	watchdog_set_drvdata(wdd, gwdt);
+	watchdog_set_nowayout(wdd, nowayout);
+
+	wdd->min_timeout = 2;
+	wdd->max_timeout = U32_MAX / gwdt->clk * 2;
+	wdd->timeout = DEFAULT_TIMEOUT;
+	watchdog_init_timeout(wdd, timeout, dev);
+
+	status = readl(gwdt->control_base + SBSA_GWDT_WCS);
+	if (status & SBSA_GWDT_WCS_WS1) {
+		dev_warn(dev, "System reset by WDT.\n");
+		wdd->bootstatus |= WDIOF_CARDRESET;
+	}
+
+	ret = watchdog_register_device(wdd);
+	if (ret)
+		return ret;
+
+	/*
+	 * Update timeout to WOR.
+	 * Because of the explicit watchdog refresh mechanism,
+	 * it's also a ping, if watchdog is enabled.
+	 */
+	sbsa_gwdt_set_timeout(wdd, wdd->timeout);
+
+	dev_info(dev, "Initialized with %ds timeout @ %u Hz%s\n", wdd->timeout,
+		 gwdt->clk, status & SBSA_GWDT_WCS_EN ? " [enabled]" : "");
+
+	return 0;
+}
+
+static void sbsa_gwdt_shutdown(struct platform_device *pdev)
+{
+	struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
+
+	sbsa_gwdt_stop(&gwdt->wdd);
+}
+
+static int sbsa_gwdt_remove(struct platform_device *pdev)
+{
+	struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
+
+	watchdog_unregister_device(&gwdt->wdd);
+
+	return 0;
+}
+
+/* Disable watchdog if it is active during suspend */
+static int __maybe_unused sbsa_gwdt_suspend(struct device *dev)
+{
+	struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
+
+	if (watchdog_active(&gwdt->wdd))
+		sbsa_gwdt_stop(&gwdt->wdd);
+
+	return 0;
+}
+
+/* Enable watchdog and configure it if necessary */
+static int __maybe_unused sbsa_gwdt_resume(struct device *dev)
+{
+	struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
+
+	if (watchdog_active(&gwdt->wdd))
+		sbsa_gwdt_start(&gwdt->wdd);
+
+	return 0;
+}
+
+static const struct dev_pm_ops sbsa_gwdt_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(sbsa_gwdt_suspend, sbsa_gwdt_resume)
+};
+
+static const struct of_device_id sbsa_gwdt_of_match[] = {
+	{ .compatible = "arm,sbsa-gwdt", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sbsa_gwdt_of_match);
+
+static const struct platform_device_id sbsa_gwdt_pdev_match[] = {
+	{ .name = "sbsa-gwdt", },
+	{},
+};
+MODULE_DEVICE_TABLE(platform, sbsa_gwdt_pdev_match);
+
+static struct platform_driver sbsa_gwdt_driver = {
+	.driver = {
+		.name = "sbsa-gwdt",
+		.pm = &sbsa_gwdt_pm_ops,
+		.of_match_table = sbsa_gwdt_of_match,
+	},
+	.probe = sbsa_gwdt_probe,
+	.remove = sbsa_gwdt_remove,
+	.shutdown = sbsa_gwdt_shutdown,
+	.id_table = sbsa_gwdt_pdev_match,
+};
+
+module_platform_driver(sbsa_gwdt_driver);
+
+MODULE_DESCRIPTION("SBSA Generic Watchdog Driver");
+MODULE_AUTHOR("Fu Wei <fu.wei at linaro.org>");
+MODULE_AUTHOR("Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>");
+MODULE_AUTHOR("Al Stone <al.stone at linaro.org>");
+MODULE_AUTHOR("Timur Tabi <timur at codeaurora.org>");
+MODULE_LICENSE("GPL v2");
-- 
2.5.0



From tony at atomide.com  Wed Feb  3 09:22:22 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Feb 2016 09:22:22 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAJZ5v0hdDdFDiieDnsjummg6F+nV7fi=gFa=oFweyP7-ApsHrQ@mail.gmail.com>
References: <20160202210345.GZ19432@atomide.com>
 <Pine.LNX.4.44L0.1602021626540.1653-100000@iolanthe.rowland.org>
 <20160202234626.GD19432@atomide.com>
 <CAJZ5v0hdDdFDiieDnsjummg6F+nV7fi=gFa=oFweyP7-ApsHrQ@mail.gmail.com>
Message-ID: <20160203172222.GL19432@atomide.com>

* Rafael J. Wysocki <rafael at kernel.org> [160203 09:19]:
> On Wed, Feb 3, 2016 at 12:46 AM, Tony Lindgren <tony at atomide.com> wrote:
> > * Alan Stern <stern at rowland.harvard.edu> [160202 13:46]:
> >> On Tue, 2 Feb 2016, Tony Lindgren wrote:
> >>
> >> > > Also, what is autosuspend_delay set to for your device?  And is
> >> > > runtime_auto set?
> >> >
> >> > It's 100 at that point, see the commented snippet below from
> >> > omap_hsmmc_probe():
> >> >
> >> >     pm_runtime_enable(host->dev);
> >> >     pm_runtime_get_sync(host->dev);
> >> >     pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY);
> >> >     /* NOTE: pm_runtime_dont_use_autosuspend(host->dev) needed here? */
> >> >     pm_runtime_use_autosuspend(host->dev);
> >> >     ...
> >> >     /* gets -EPROBE_DEFER */
> >> > err_irq:
> >> >     ...
> >> >     pm_runtime_put_sync(host->dev);
> >>
> >> You could try changing this to pm_runtime_put_sync_suspend().  But
> >> putting pm_runtime_dont_use_autosuspend() before the put_sync seems
> >> like a perfectly reasonable thing to do, especially if you feel you
> >> should reverse all the changes you made at the start.
> 
> FWIW, I'd call pm_runtime_dont_use_autosuspend() before put_sync().
> 
> After all, the driver doesn't want to use autosuspend going forward,
> so stating that explicitly looks like the right thing to do.

Yeah agreed. FYI, this is what I typed up here into a commit message:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Regards,

Tony


From fu.wei at linaro.org  Wed Feb  3 09:18:43 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Thu,  4 Feb 2016 01:18:43 +0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1454519923-25230-6-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This patch registers the WS0 interrupt routine to trigger panic,
when the watchdog reachs the first stage (the half timeout).
This function can help administrator to backup the system context
info by panic console output or kdump (if supported), once system
goes wrong (doesn't feed the watchdog in the half timeout).

User also can skip panic by setting panic_enabled (module parameter) as 0

Signed-off-by: Fu Wei <fu.wei at linaro.org>
---
 Documentation/watchdog/watchdog-parameters.txt |  1 +
 drivers/watchdog/Kconfig                       | 10 +++++
 drivers/watchdog/sbsa_gwdt.c                   | 54 +++++++++++++++++++++++---
 3 files changed, 60 insertions(+), 5 deletions(-)

diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
index 300eb4d..31641e2 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -286,6 +286,7 @@ nowayout: Watchdog cannot be stopped once started
 -------------------------------------------------
 sbsa_gwdt:
 timeout: Watchdog timeout in seconds. (default 20s)
+panic_enabled: Enable panic at half timeout. (default=true)
 nowayout: Watchdog cannot be stopped once started
 	(default=kernel config parameter)
 -------------------------------------------------
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 4ab1b05..42adfdf 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -218,6 +218,16 @@ config ARM_SBSA_WATCHDOG
 	  To compile this driver as module, choose M here: The module
 	  will be called sbsa_gwdt.
 
+config ARM_SBSA_WATCHDOG_PANIC
+	bool "ARM SBSA Generic Watchdog triggers panic at the half timeout"
+	depends on ARM_SBSA_WATCHDOG
+	help
+	  ARM SBSA Generic Watchdog will trigger panic in the first signal
+	  (WS0) interrupt routine when the half timeout is reached.
+	  This function can help administrator to backup the system context
+	  info by panic console output or kdump (if supported).
+	  But user can skip panic by setting moduleparam panic_enabled as 0.
+
 config ASM9260_WATCHDOG
 	tristate "Alphascale ASM9260 watchdog"
 	depends on MACH_ASM9260
diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
index 5a2dba3..d18cf37 100644
--- a/drivers/watchdog/sbsa_gwdt.c
+++ b/drivers/watchdog/sbsa_gwdt.c
@@ -16,18 +16,22 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
- * This SBSA Generic watchdog driver is a single stage timeout version.
+ * This SBSA Generic watchdog driver is a two stages version.
  * Since this watchdog timer has two stages, and each stage is determined
  * by WOR. So the timeout is (WOR * 2).
- * When first timeout is reached, WS0 is triggered, the interrupt
- * triggered by WS0 will be ignored, then the second watch period starts;
- * when second timeout is reached, then WS1 is triggered, system reset.
+ * When the first stage(the half timeout) is reached, WS0 interrupt is
+ * triggered, at this moment the second watch period starts;
+ * In the WS0 interrupt routine, panic will be triggered for saving the
+ * system context.
+ * If the system is getting into trouble and cannot be reset by panic or
+ * restart properly by the kdump kernel(if supported), then the second
+ * stage (the timeout) will be reached, system will be reset by WS1.
  *
  * More details about the hardware specification of this device:
  * ARM DEN0029B - Server Base System Architecture (SBSA)
  *
  * SBSA GWDT: |--------WOR-------WS0--------WOR-------WS1
- *            |----------------timeout----------------reset
+ *            |--half_timeout--(panic)--half_timeout--reset
  *
  */
 
@@ -84,6 +88,13 @@ MODULE_PARM_DESC(timeout,
 		 "Watchdog timeout in seconds. (>=0, default="
 		 __MODULE_STRING(DEFAULT_TIMEOUT) ")");
 
+#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
+static bool panic_enabled = true;
+module_param(panic_enabled, bool, 0);
+MODULE_PARM_DESC(panic_enabled,
+		 "enable panic at half timeout. (default=true)");
+#endif
+
 static bool nowayout = WATCHDOG_NOWAYOUT;
 module_param(nowayout, bool, S_IRUGO);
 MODULE_PARM_DESC(nowayout,
@@ -159,6 +170,16 @@ static int sbsa_gwdt_stop(struct watchdog_device *wdd)
 	return 0;
 }
 
+#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
+static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
+{
+	if (panic_enabled)
+		panic("SBSA Watchdog half timeout");
+
+	return IRQ_HANDLED;
+}
+#endif
+
 static struct watchdog_info sbsa_gwdt_info = {
 	.identity	= "SBSA Generic Watchdog",
 	.options	= WDIOF_SETTIMEOUT |
@@ -186,6 +207,9 @@ static int sbsa_gwdt_probe(struct platform_device *pdev)
 	struct resource *res;
 	u32 status;
 	int ret;
+#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
+	int irq;
+#endif
 
 	gwdt = devm_kzalloc(dev, sizeof(*gwdt), GFP_KERNEL);
 	if (!gwdt)
@@ -202,6 +226,14 @@ static int sbsa_gwdt_probe(struct platform_device *pdev)
 	if (IS_ERR(rf_base))
 		return PTR_ERR(rf_base);
 
+#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(dev, "unable to get ws0 interrupt.\n");
+		return irq;
+	}
+#endif
+
 	/*
 	 * Get the frequency of system counter from the cp15 interface of ARM
 	 * Generic timer. We don't need to check it, because if it returns "0",
@@ -228,6 +260,14 @@ static int sbsa_gwdt_probe(struct platform_device *pdev)
 		dev_warn(dev, "System reset by WDT.\n");
 		wdd->bootstatus |= WDIOF_CARDRESET;
 	}
+#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
+	ret = devm_request_irq(dev, irq, sbsa_gwdt_interrupt, 0,
+			       pdev->name, gwdt);
+	if (ret) {
+		dev_err(dev, "unable to request IRQ %d\n", irq);
+		return ret;
+	}
+#endif
 
 	ret = watchdog_register_device(wdd);
 	if (ret)
@@ -242,6 +282,10 @@ static int sbsa_gwdt_probe(struct platform_device *pdev)
 
 	dev_info(dev, "Initialized with %ds timeout @ %u Hz%s\n", wdd->timeout,
 		 gwdt->clk, status & SBSA_GWDT_WCS_EN ? " [enabled]" : "");
+#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
+	dev_info(dev, "Half timeout panic %s.\n",
+		 panic_enabled ? "enabled" : "disabled");
+#endif
 
 	return 0;
 }
-- 
2.5.0



From Suzuki.Poulose at arm.com  Wed Feb  3 09:23:33 2016
From: Suzuki.Poulose at arm.com (Suzuki K. Poulose)
Date: Wed, 3 Feb 2016 17:23:33 +0000
Subject: [PATCH v4 4/7] arm64: Handle early CPU boot failures
In-Reply-To: <20160203125735.GA26487@MBP.local>
References: <1453745225-27736-1-git-send-email-suzuki.poulose@arm.com>
 <1453745225-27736-5-git-send-email-suzuki.poulose@arm.com>
 <20160203125735.GA26487@MBP.local>
Message-ID: <56B23795.5090202@arm.com>

Hi Catalin,

>> +/* Fatal system error detected by secondary CPU, crash the system */
>> +#define CPU_PANIC_KERNEL	3
>
> Please add braces around these numbers, just in case (I added them
> locally).

OK, I will base my changes on top of the corrections.

>
>>   /*
>> + * The booting CPU updates the failed status, with MMU turned off,
>> + * below which lies in head.txt to make sure it doesn't share the same writeback
>> + * granule. So that we can invalidate it properly.
>
> I can't really parse this (it looks like punctuation in the wrong place;
> also "share the same..." with what?).

Sorry it doesn't parse :(. It should have been something like :

"The booting CPU updates the failed status @__early_cpu_boot_status (with
the MMU turned off). It is placed in head.txt to make sure it doesn't
share the same write back granule with anything else while the CPU updates
it."


>> +	.macro	update_early_cpu_boot_status tmp, status
>> +	mov	\tmp, lr
>> +	adrp	x0, __early_cpu_boot_status
>> +	add	x0, x0, #:lo12:__early_cpu_boot_status
>
> Nitpick: you could use the adr_l macro.

Yes, that looks much better, will keep in mind.


>> @@ -117,7 +131,35 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
>>   		pr_err("CPU%u: failed to boot: %d\n", cpu, ret);
>>   	}
>>
>> +	/* Make sure the update to status is visible */
>> +	smp_rmb();
>
> Which status? In relation to what?

The secondary_data.status updated by the successful CPUs which have mmu turned on, and
updating the cpu_running. But as Mark pointed out, complete() implies a barrier, hence
won't need it.

>
>>   	secondary_data.stack = NULL;
>> +	status = READ_ONCE(secondary_data.status);
>> +	if (ret && status) {
>> +
>> +		if (status == CPU_MMU_OFF)
>> +			status = READ_ONCE(__early_cpu_boot_status);
>
> You need cache maintenance before reading this.

OK.

Thanks
Suzuki



From Suzuki.Poulose at arm.com  Wed Feb  3 09:24:07 2016
From: Suzuki.Poulose at arm.com (Suzuki K. Poulose)
Date: Wed, 3 Feb 2016 17:24:07 +0000
Subject: [PATCH v4 4/7] arm64: Handle early CPU boot failures
In-Reply-To: <20160203170114.GD1234@leverpostej>
References: <1453745225-27736-1-git-send-email-suzuki.poulose@arm.com>
 <1453745225-27736-5-git-send-email-suzuki.poulose@arm.com>
 <20160203170114.GD1234@leverpostej>
Message-ID: <56B237B7.1060805@arm.com>

On 03/02/16 17:01, Mark Rutland wrote:
> On Mon, Jan 25, 2016 at 06:07:02PM +0000, Suzuki K Poulose wrote:
>> From: Suzuki K. Poulose <suzuki.poulose at arm.com>
>>

>>   3. CPU_PANIC_KERNEL - CPU detected some serious issues which
>> requires kernel to crash immediately. The secondary CPU cannot
>> call panic() until it has initialised the GIC. This flag can
>> be used to instruct the master to do so.
>
> When would we use this last case?

As of now, it is used when we have incompatible ASID bits.

>
> Perhaps a better option is to always throw any incompatible CPU into an
> (MMU-off) pen, and assume that it's stuck in the kernel, even if we
> could theoretically turn it off.

Right, that is another option. I am fine with either.

>> -	b __no_granule_support
>> +	wfi
>> +	b 1b
>
> The addition of wfi seems fine, but should be mentioned in the commit
> message.

Sure.

>>   struct secondary_data secondary_data;
>> +/* Number of CPUs which aren't online, but looping in kernel text. */
>> +u32 cpus_stuck_in_kernel;
>
> Why u32 rather than int?

No specific reasons, since it is going to be a quantity, which cannot be < 0,
kept it unsigned. It could be unsigned int.

>> +#ifdef CONFIG_HOTPLUG_CPU
>> +static int op_cpu_kill(unsigned int cpu);
>> +#else
>> +static inline int op_cpu_kill(unsigned int cpu)
>> +{
>> +	return -ENOSYS;
>> +}
>> +#endif
>
> There is no !CONFIG_HOTPLUG_CPU configuration any more.

Thats what I thought but then there was [1]. If you disable CONFIG_PM_SLEEP, you can
still build with !CONFIG_HOTPLUG_CPU (or in other words allnoconfig)

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/384589.html

>>
>> +	/* Make sure the update to status is visible */
>> +	smp_rmb();
>>   	secondary_data.stack = NULL;
>> +	status = READ_ONCE(secondary_data.status);
>
> What is the rmb intended to order here?

It was for the complete(). But...

>> +	update_cpu_boot_status(CPU_BOOT_SUCCESS);
>> +	/* Make sure the status update is visible before we complete */
>> +	smp_wmb();
>
> Surely complete() has appropriate barriers?

Yes, it does. We can remove it.
  
>>   #ifdef CONFIG_HOTPLUG_CPU
>> +	update_cpu_boot_status(CPU_KILL_ME);
>>   	/* Check if we can park ourselves */
>>   	if (cpu_ops[cpu] && cpu_ops[cpu]->cpu_die)
>>   		cpu_ops[cpu]->cpu_die(cpu);
>
> I think you need a barrier to ensure visibility of the store prior to
> calling cpu_die (i.e. you want to order an access against execution). A
> dsb is what you want -- smp_wmb() only expands to a dmb.
>

OK.

>>   #endif
>> +	update_cpu_boot_status(CPU_STUCK_IN_KERNEL);
>>
>>   	cpu_park_loop();
>
> Likewise here.

OK.

Thanks
Suzuki


From rafael at kernel.org  Wed Feb  3 09:27:16 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Wed, 3 Feb 2016 18:27:16 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160203172222.GL19432@atomide.com>
References: <20160202210345.GZ19432@atomide.com>
 <Pine.LNX.4.44L0.1602021626540.1653-100000@iolanthe.rowland.org>
 <20160202234626.GD19432@atomide.com>
 <CAJZ5v0hdDdFDiieDnsjummg6F+nV7fi=gFa=oFweyP7-ApsHrQ@mail.gmail.com>
 <20160203172222.GL19432@atomide.com>
Message-ID: <CAJZ5v0j_mgtuk-eGYJTV=hNBjQR0-Rhk8ocQUyEVObYnx314pg@mail.gmail.com>

On Wed, Feb 3, 2016 at 6:22 PM, Tony Lindgren <tony at atomide.com> wrote:
> * Rafael J. Wysocki <rafael at kernel.org> [160203 09:19]:
>> On Wed, Feb 3, 2016 at 12:46 AM, Tony Lindgren <tony at atomide.com> wrote:
>> > * Alan Stern <stern at rowland.harvard.edu> [160202 13:46]:
>> >> On Tue, 2 Feb 2016, Tony Lindgren wrote:
>> >>
>> >> > > Also, what is autosuspend_delay set to for your device?  And is
>> >> > > runtime_auto set?
>> >> >
>> >> > It's 100 at that point, see the commented snippet below from
>> >> > omap_hsmmc_probe():
>> >> >
>> >> >     pm_runtime_enable(host->dev);
>> >> >     pm_runtime_get_sync(host->dev);
>> >> >     pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY);
>> >> >     /* NOTE: pm_runtime_dont_use_autosuspend(host->dev) needed here? */
>> >> >     pm_runtime_use_autosuspend(host->dev);
>> >> >     ...
>> >> >     /* gets -EPROBE_DEFER */
>> >> > err_irq:
>> >> >     ...
>> >> >     pm_runtime_put_sync(host->dev);
>> >>
>> >> You could try changing this to pm_runtime_put_sync_suspend().  But
>> >> putting pm_runtime_dont_use_autosuspend() before the put_sync seems
>> >> like a perfectly reasonable thing to do, especially if you feel you
>> >> should reverse all the changes you made at the start.
>>
>> FWIW, I'd call pm_runtime_dont_use_autosuspend() before put_sync().
>>
>> After all, the driver doesn't want to use autosuspend going forward,
>> so stating that explicitly looks like the right thing to do.
>
> Yeah agreed. FYI, this is what I typed up here into a commit message:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.

Sounds reasonable to me.

Thanks,
Rafael


From timur at codeaurora.org  Wed Feb  3 09:27:31 2016
From: timur at codeaurora.org (Timur Tabi)
Date: Wed, 3 Feb 2016 11:27:31 -0600
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
Message-ID: <56B23883.7000501@codeaurora.org>

fu.wei at linaro.org wrote:
> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
> +static bool panic_enabled = true;

I think this should default to 'false', because IMHO, this seems like an 
odd feature.  I'm not crazy about the fact that there's a Kconfig option 
for it either, but I'm not going to NACK this patch.

I personally would prefer to drop this patch, and just wait for 
full-blown pre-timeout support.  It feels like a debugging feature that 
doesn't really belong upstream.  But like I said, it's just my opinion, 
and I won't complain if I'm outvoted.


From marc.zyngier at arm.com  Wed Feb  3 09:33:54 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 3 Feb 2016 17:33:54 +0000
Subject: [PATCH] KVM: arm/arm64: fix reference to uninitialised VGIC
In-Reply-To: <1454518611-15694-1-git-send-email-andre.przywara@arm.com>
References: <1454518611-15694-1-git-send-email-andre.przywara@arm.com>
Message-ID: <56B23A02.7070804@arm.com>

On 03/02/16 16:56, Andre Przywara wrote:
> Commit 4b4b4512da2a ("arm/arm64: KVM: Rework the arch timer to use
> level-triggered semantics") brought the virtual architected timer
> closer to the VGIC. There is one occasion were we don't properly
> check for the VGIC actually having been initialized before, but
> instead go on to check the active state of some IRQ number.
> If userland hasn't instantiated a virtual GIC, we end up with a
> kernel NULL pointer dereference:
> =========
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = ffffffc9745c5000
> [00000000] *pgd=00000009f631e003, *pud=00000009f631e003, *pmd=0000000000000000
> Internal error: Oops: 96000006 [#2] PREEMPT SMP
> Modules linked in:
> CPU: 0 PID: 2144 Comm: kvm_simplest-ar Tainted: G      D 4.5.0-rc2+ #1300
> Hardware name: ARM Juno development board (r1) (DT)
> task: ffffffc976da8000 ti: ffffffc976e28000 task.ti: ffffffc976e28000
> PC is at vgic_bitmap_get_irq_val+0x78/0x90
> LR is at kvm_vgic_map_is_active+0xac/0xc8
> pc : [<ffffffc0000b7e28>] lr : [<ffffffc0000b972c>] pstate: 20000145
> ....
> =========
> 
> Fix this by bailing out early of kvm_timer_flush_hwstate() if we don't
> have a VGIC at all.
> 
> Reported-by: Cosmin Gorgovan <cosmin at linux-geek.org>
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> Cc: <stable at vger.kernel.org> # 4.4.x

Nice catch, thanks.

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

	M.
-- 
Jazz is not dead. It just smells funny...


From catalin.marinas at arm.com  Wed Feb  3 09:34:49 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 3 Feb 2016 17:34:49 +0000
Subject: [PATCH v4 4/7] arm64: Handle early CPU boot failures
In-Reply-To: <20160203164632.GC1234@leverpostej>
References: <1453745225-27736-1-git-send-email-suzuki.poulose@arm.com>
 <1453745225-27736-5-git-send-email-suzuki.poulose@arm.com>
 <20160203125735.GA26487@MBP.local>
 <20160203164632.GC1234@leverpostej>
Message-ID: <20160203173448.GD26487@MBP.local>

On Wed, Feb 03, 2016 at 04:46:32PM +0000, Mark Rutland wrote:
> On Wed, Feb 03, 2016 at 12:57:38PM +0000, Catalin Marinas wrote:
> > On Mon, Jan 25, 2016 at 06:07:02PM +0000, Suzuki K. Poulose wrote:
> > > + * update_early_cpu_boot_status tmp, status
> > > + *  - Corrupts tmp, x0, x1
> > > + *  - Writes 'status' to __early_cpu_boot_status and makes sure
> > > + *    it is committed to memory.
> > > + */
> > > +
> > > +	.macro	update_early_cpu_boot_status tmp, status
> > > +	mov	\tmp, lr
> > > +	adrp	x0, __early_cpu_boot_status
> > > +	add	x0, x0, #:lo12:__early_cpu_boot_status
> > 
> > Nitpick: you could use the adr_l macro.
> > 
> > > +	mov	x1, #\status
> > > +	str	x1, [x0]
> > > +	add	x1, x0, 4
> > > +	bl	__inval_cache_range
> > > +	mov	lr, \tmp
> > > +	.endm
> > 
> > If the CPU that's currently booting has the MMU off, what's the point of
> > invalidating the cache here?
> 
> To invalidate stale lines for this address, held in any caches prior to
> the PoC. I'm assuming that __early_cpu_boot_status is sufficiently
> padded to the CWG.

I would have rather invalidated it before writing the [x0], if that's
what it's aimed at.

> Cache maintenance works when SCTLR_ELx.M == 0, though barriers are
> required prior to cache maintenance as non-cacheable accesses do not
> hazard by VA.
> 
> The MMU being off has no effect on the cache maintenance itself.

I know, but whether it has an effect on other CPUs is a different
question (it probably has). Anyway, I would rather do the invalidation
on the CPU that actually reads this status.

> > The operation may not even be broadcast to the other CPU. So you
> > actually need the invalidation before reading the status on the
> > primary CPU.
> 
> We require that CPUs are coherent when they enter the kernel, so any
> cache maintenance operation _must_ affect all coherent caches (i.e. it
> must be broadcast and must affect all coherent caches prior to the PoC
> in this case).

In general, if you perform cache maintenance on a non-shareable mapping,
I don't think it would be broadcast. But in this case, the MMU is off,
data accesses default to Device_nGnRnE and considered outer shareable,
so it may actually work. Is this stated anywhere in the ARM ARM?

But see my point above about invalidating on the secondary CPU before
writing the location and invalidating again on the primary CPU before
reading it.

-- 
Catalin


From mark.rutland at arm.com  Wed Feb  3 09:35:36 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 3 Feb 2016 17:35:36 +0000
Subject: [PATCH v4 4/7] arm64: Handle early CPU boot failures
In-Reply-To: <56B237B7.1060805@arm.com>
References: <1453745225-27736-1-git-send-email-suzuki.poulose@arm.com>
 <1453745225-27736-5-git-send-email-suzuki.poulose@arm.com>
 <20160203170114.GD1234@leverpostej> <56B237B7.1060805@arm.com>
Message-ID: <20160203173535.GF1234@leverpostej>

On Wed, Feb 03, 2016 at 05:24:07PM +0000, Suzuki K. Poulose wrote:
> On 03/02/16 17:01, Mark Rutland wrote:
> >On Mon, Jan 25, 2016 at 06:07:02PM +0000, Suzuki K Poulose wrote:
> >>From: Suzuki K. Poulose <suzuki.poulose at arm.com>

[...]

> >>  struct secondary_data secondary_data;
> >>+/* Number of CPUs which aren't online, but looping in kernel text. */
> >>+u32 cpus_stuck_in_kernel;
> >
> >Why u32 rather than int?
> 
> No specific reasons, since it is going to be a quantity, which cannot be < 0,
> kept it unsigned. It could be unsigned int.

Elsewhere, int or unsigned int is used to contain a cpu number. I think
either would be preferable to u32, to at least limit the inconsistency.

> >>+#ifdef CONFIG_HOTPLUG_CPU
> >>+static int op_cpu_kill(unsigned int cpu);
> >>+#else
> >>+static inline int op_cpu_kill(unsigned int cpu)
> >>+{
> >>+	return -ENOSYS;
> >>+}
> >>+#endif
> >
> >There is no !CONFIG_HOTPLUG_CPU configuration any more.
> 
> Thats what I thought but then there was [1]. If you disable CONFIG_PM_SLEEP, you can
> still build with !CONFIG_HOTPLUG_CPU (or in other words allnoconfig)
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/384589.html

Aargh, indeed. I had confused CONFIG_HOTPLUG_CPU and CONFIG_SMP. Sorry!

Mark. 


From stillcompiling at gmail.com  Wed Feb  3 09:37:45 2016
From: stillcompiling at gmail.com (Joshua Clayton)
Date: Wed,  3 Feb 2016 09:37:45 -0800
Subject: [PATCH v3] ARM: dts: Add dts for Uniwest evi
In-Reply-To: <1454491459.3415.6.camel@pengutronix.de>
References: <1454491459.3415.6.camel@pengutronix.de>
Message-ID: <1454521065-14241-1-git-send-email-stillcompiling@gmail.com>

Uniwest evi is a portable electrical eddy current non-destructive
testing device.

Signed-off-by: Joshua Clayton <stillcompiling at gmail.com>
---

Changes since v2:
- removed fsl,data-mapping and fsl,data-width from lvds0 per Phillip Zabel
- removed MX6QDL_PAD_GPIO_19__GPIO4_IO05 from hoggrp. This pin is
  used in a not yet upstreamed input driver.

 arch/arm/boot/dts/Makefile      |   1 +
 arch/arm/boot/dts/imx6q-evi.dts | 502 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 503 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-evi.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c4f42a78..4a4ef29 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -326,6 +326,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
 	imx6q-cubox-i.dtb \
 	imx6q-dfi-fs700-m60.dtb \
 	imx6q-dmo-edmqmx6.dtb \
+	imx6q-evi.dtb \
 	imx6q-gk802.dtb \
 	imx6q-gw51xx.dtb \
 	imx6q-gw52xx.dtb \
diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
new file mode 100644
index 0000000..4fa5601
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-evi.dts
@@ -0,0 +1,502 @@
+/*
+ * Copyright 2016 United Western Technologies.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	model = "Uniwest Evi";
+	compatible = "uniwest,imx6q-evi", "fsl,imx6q";
+
+	memory {
+		reg = <0x10000000 0x40000000>;
+	};
+
+	reg_usbh1_vbus: regulator-usbhubreset {
+		compatible = "regulator-fixed";
+		regulator-name = "usbh1_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		startup-delay-us = <2>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbh1_hubreset>;
+		gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
+	};
+
+	reg_usb_otg_vbus: regulator-usbotgvbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_otg_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbotgvbus>;
+		gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		regulator-always-on;
+	};
+
+	panel {
+		compatible = "sharp,lq101k1ly04";
+
+		port {
+			panel_in: endpoint {
+				remote-endpoint = <&lvds0_out>;
+			};
+		};
+	};
+};
+
+&ecspi1 {
+	fsl,spi-num-chipselects = <1>;
+	cs-gpios = <&gpio4 10 GPIO_ACTIVE_LOW>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_ecspi1cs>;
+	status = "okay";
+};
+
+&ecspi3 {
+	fsl,spi-num-chipselects = <3>;
+	cs-gpios = <&gpio4 24 GPIO_ACTIVE_LOW>,
+		<&gpio4 25 GPIO_ACTIVE_LOW>,
+		<&gpio4 26 GPIO_ACTIVE_LOW>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3cs>;
+	status = "okay";
+};
+
+&ecspi5 {
+	fsl,spi-num-chipselects = <4>;
+	cs-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>,
+		<&gpio1 13 GPIO_ACTIVE_LOW>,
+		<&gpio1 12 GPIO_ACTIVE_LOW>,
+		<&gpio2 9 GPIO_ACTIVE_HIGH>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi5 &pinctrl_ecspi5cs>;
+	status = "okay";
+
+	eeprom: m95m02 at 1 {
+		compatible = "st,m95m02", "atmel,at25";
+		size = <262144>;
+		pagesize = <256>;
+		address-width = <24>;
+		spi-max-frequency = <5000000>;
+		reg = <1>;
+	};
+
+	pb_rtc: rtc at 3 {
+		compatible = "nxp,rtc-pcf2123";
+		spi-max-frequency = <2450000>;
+		spi-cs-high;
+		reg = <3>;
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet>;
+	phy-mode = "rgmii";
+	phy-reset-gpios = <&gpio1 25 0>;
+	status = "okay";
+};
+
+&gpmi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_gpminand>;
+	status = "okay";
+};
+
+&i2c2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	clock-frequency = <100000>;
+	status = "okay";
+};
+
+&i2c3 {
+	pinctrl-names = "default", "gpio";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	pinctrl-1 = <&pinctrl_i2c3_gpio>;
+	clock-frequency = <100000>;
+	scl-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+	sda-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+
+	battery: sbs-battery at b {
+		compatible = "sbs,sbs-battery";
+		reg = <0x0b>;
+		sbs,poll-retry-count = <100>;
+		sbs,i2c-retry-count = <100>;
+	};
+};
+
+&ldb {
+	status = "okay";
+
+	lvds0: lvds-channel at 0 {
+		status = "okay";
+
+		port at 4 {
+			reg = <4>;
+			lvds0_out: endpoint {
+				remote-endpoint = <&panel_in>;
+			};
+		};
+	};
+};
+
+&ssi1 {
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2>;
+	status = "okay";
+};
+
+&usbh1 {
+	vbus-supply = <&reg_usbh1_vbus>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbh1>;
+	dr_mode = "host";
+	disable-over-current;
+	status = "okay";
+};
+
+&usbotg {
+	vbus-supply = <&reg_usb_otg_vbus>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbotg>;
+	disable-over-current;
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	non-removable;
+	status = "okay";
+};
+
+&weim {
+	#address-cells = <2>;
+	#size-cells = <1>;
+	ranges = <0 0 0x08000000 0x08000000>;
+	fsl,weim-cs-gpr = <&gpr>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_weimfpga &pinctrl_weimcs>;
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	pinctrl_hog: hoggrp {
+		fsl,pins = <
+			/* pwr mcu alert irq */
+			MX6QDL_PAD_SD4_DAT2__GPIO2_IO10 0x1b0b0
+			/* remainder ???? */
+			MX6QDL_PAD_CSI0_MCLK__GPIO5_IO19 0x1b0b0
+		>;
+	};
+
+	pinctrl_ecspi1: ecspi1grp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL1__ECSPI1_MISO 0x100b1
+			MX6QDL_PAD_KEY_ROW0__ECSPI1_MOSI 0x100b1
+			MX6QDL_PAD_KEY_COL0__ECSPI1_SCLK 0x100b1
+		>;
+	};
+
+	pinctrl_ecspi1cs: ecspi1csgrp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
+		>;
+	};
+
+	pinctrl_ecspi3: ecspi3grp {
+		fsl,pins = <
+			MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x10068
+			MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x10068
+			MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x1f068
+		>;
+	};
+
+	pinctrl_ecspi3cs: ecspi3csgrp {
+		fsl,pins = <
+			MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x1b0b0
+			MX6QDL_PAD_DISP0_DAT4__GPIO4_IO25 0x1b0b0
+			MX6QDL_PAD_DISP0_DAT5__GPIO4_IO26 0x1b0b0
+			MX6QDL_PAD_DISP0_DAT6__GPIO4_IO27 0x1b0b0
+		>;
+	};
+
+	pinctrl_ecspi5: ecspi5grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD2_CLK__ECSPI5_SCLK 0x100b1
+			MX6QDL_PAD_SD2_CMD__ECSPI5_MOSI 0x100b1
+			MX6QDL_PAD_SD2_DAT0__ECSPI5_MISO 0x100b1
+		>;
+	};
+
+	pinctrl_ecspi5cs: ecspi5csgrp {
+		fsl,pins = <
+			MX6QDL_PAD_SD2_DAT1__GPIO1_IO14 0x1b0b0
+			MX6QDL_PAD_SD2_DAT2__GPIO1_IO13 0x1b0b0
+			MX6QDL_PAD_SD2_DAT3__GPIO1_IO12 0x1b0b0
+			MX6QDL_PAD_SD4_DAT1__GPIO2_IO09 0x1b0b0
+		>;
+	};
+
+	pinctrl_enet: enetgrp {
+		fsl,pins = <
+			MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+			MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+			MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b0b0
+			MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b0b0
+			MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b0b0
+			MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b0b0
+			MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b0b0
+			MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
+			MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
+			MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b0b0
+			MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b0b0
+			MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b0b0
+			MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0
+			MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0
+			MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
+			MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x4001b0a8
+			MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x1b0b0
+		>;
+	};
+
+	pinctrl_gpminand: gpminandgrp {
+		fsl,pins = <
+			MX6QDL_PAD_NANDF_CLE__NAND_CLE 0xb0b1
+			MX6QDL_PAD_NANDF_ALE__NAND_ALE 0xb0b1
+			MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0xb0b1
+			MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0xb000
+			MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0xb0b1
+			MX6QDL_PAD_NANDF_CS1__NAND_CE1_B 0xb0b1
+			MX6QDL_PAD_SD4_CMD__NAND_RE_B 0xb0b1
+			MX6QDL_PAD_SD4_CLK__NAND_WE_B 0xb0b1
+			MX6QDL_PAD_NANDF_D0__NAND_DATA00 0xb0b1
+			MX6QDL_PAD_NANDF_D1__NAND_DATA01 0xb0b1
+			MX6QDL_PAD_NANDF_D2__NAND_DATA02 0xb0b1
+			MX6QDL_PAD_NANDF_D3__NAND_DATA03 0xb0b1
+			MX6QDL_PAD_NANDF_D4__NAND_DATA04 0xb0b1
+			MX6QDL_PAD_NANDF_D5__NAND_DATA05 0xb0b1
+			MX6QDL_PAD_NANDF_D6__NAND_DATA06 0xb0b1
+			MX6QDL_PAD_NANDF_D7__NAND_DATA07 0xb0b1
+			MX6QDL_PAD_SD4_DAT0__NAND_DQS 0x00b1
+		>;
+	};
+
+	pinctrl_i2c2: i2c2grp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+			MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+		>;
+	};
+
+	pinctrl_i2c3: i2c3grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
+			MX6QDL_PAD_GPIO_16__I2C3_SDA 0x4001b8b1
+		>;
+	};
+
+	pinctrl_i2c3_gpio: i2c3gpiogrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_5__GPIO1_IO05 0x4001b8b1
+			MX6QDL_PAD_GPIO_16__GPIO7_IO11 0x4001b8b1
+		>;
+	};
+
+	pinctrl_weimcs: weimcsgrp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_CS0__EIM_CS0_B 0xb0b1
+			MX6QDL_PAD_EIM_CS1__EIM_CS1_B 0xb0b1
+		>;
+	};
+
+	pinctrl_weimfpga: weimfpgagrp {
+		fsl,pins = <
+			/* weim misc */
+			MX6QDL_PAD_EIM_OE__EIM_OE_B 0xb0b1
+			MX6QDL_PAD_EIM_RW__EIM_RW 0xb0b1
+			MX6QDL_PAD_EIM_WAIT__EIM_WAIT_B 0xb060
+			MX6QDL_PAD_EIM_BCLK__EIM_BCLK 0xb0b1
+			MX6QDL_PAD_EIM_LBA__EIM_LBA_B 0xb0b1
+			MX6QDL_PAD_EIM_EB0__EIM_EB0_B 0xb0b1
+			MX6QDL_PAD_EIM_EB1__EIM_EB1_B 0xb0b1
+			MX6QDL_PAD_EIM_EB2__EIM_EB2_B 0xb0b1
+			MX6QDL_PAD_EIM_EB3__EIM_EB3_B 0xb0b1
+			/* weim data */
+			MX6QDL_PAD_CSI0_DATA_EN__EIM_DATA00 0x1b0b0
+			MX6QDL_PAD_CSI0_VSYNC__EIM_DATA01 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT4__EIM_DATA02 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT5__EIM_DATA03 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT6__EIM_DATA04 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT7__EIM_DATA05 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT8__EIM_DATA06 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT9__EIM_DATA07 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT12__EIM_DATA08 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT13__EIM_DATA09 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT14__EIM_DATA10 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT15__EIM_DATA11 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT16__EIM_DATA12 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT17__EIM_DATA13 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT18__EIM_DATA14 0x1b0b0
+			MX6QDL_PAD_CSI0_DAT19__EIM_DATA15 0x1b0b0
+			MX6QDL_PAD_EIM_D16__EIM_DATA16 0x1b0b0
+			MX6QDL_PAD_EIM_D17__EIM_DATA17 0x1b0b0
+			MX6QDL_PAD_EIM_D18__EIM_DATA18 0x1b0b0
+			MX6QDL_PAD_EIM_D19__EIM_DATA19 0x1b0b0
+			MX6QDL_PAD_EIM_D20__EIM_DATA20 0x1b0b0
+			MX6QDL_PAD_EIM_D21__EIM_DATA21 0x1b0b0
+			MX6QDL_PAD_EIM_D22__EIM_DATA22 0x1b0b0
+			MX6QDL_PAD_EIM_D23__EIM_DATA23 0x1b0b0
+			MX6QDL_PAD_EIM_D24__EIM_DATA24 0x1b0b0
+			MX6QDL_PAD_EIM_D25__EIM_DATA25 0x1b0b0
+			MX6QDL_PAD_EIM_D26__EIM_DATA26 0x1b0b0
+			MX6QDL_PAD_EIM_D27__EIM_DATA27 0x1b0b0
+			MX6QDL_PAD_EIM_D28__EIM_DATA28 0x1b0b0
+			MX6QDL_PAD_EIM_D29__EIM_DATA29 0x1b0b0
+			MX6QDL_PAD_EIM_D30__EIM_DATA30 0x1b0b0
+			MX6QDL_PAD_EIM_D31__EIM_DATA31 0x1b0b0
+			/* weim address */
+			MX6QDL_PAD_EIM_A25__EIM_ADDR25 0xb0b1
+			MX6QDL_PAD_EIM_A24__EIM_ADDR24 0xb0b1
+			MX6QDL_PAD_EIM_A23__EIM_ADDR23 0xb0b1
+			MX6QDL_PAD_EIM_A22__EIM_ADDR22 0xb0b1
+			MX6QDL_PAD_EIM_A21__EIM_ADDR21 0xb0b1
+			MX6QDL_PAD_EIM_A20__EIM_ADDR20 0xb0b1
+			MX6QDL_PAD_EIM_A19__EIM_ADDR19 0xb0b1
+			MX6QDL_PAD_EIM_A18__EIM_ADDR18 0xb0b1
+			MX6QDL_PAD_EIM_A17__EIM_ADDR17 0xb0b1
+			MX6QDL_PAD_EIM_A16__EIM_ADDR16 0xb0b1
+			MX6QDL_PAD_EIM_DA15__EIM_AD15 0xb0b1
+			MX6QDL_PAD_EIM_DA14__EIM_AD14 0xb0b1
+			MX6QDL_PAD_EIM_DA13__EIM_AD13 0xb0b1
+			MX6QDL_PAD_EIM_DA12__EIM_AD12 0xb0b1
+			MX6QDL_PAD_EIM_DA11__EIM_AD11 0xb0b1
+			MX6QDL_PAD_EIM_DA10__EIM_AD10 0xb0b1
+			MX6QDL_PAD_EIM_DA9__EIM_AD09 0xb0b1
+			MX6QDL_PAD_EIM_DA8__EIM_AD08 0xb0b1
+			MX6QDL_PAD_EIM_DA7__EIM_AD07 0xb0b1
+			MX6QDL_PAD_EIM_DA6__EIM_AD06 0xb0b1
+			MX6QDL_PAD_EIM_DA5__EIM_AD05 0xb0b1
+			MX6QDL_PAD_EIM_DA4__EIM_AD04 0xb0b1
+			MX6QDL_PAD_EIM_DA3__EIM_AD03 0xb0b1
+			MX6QDL_PAD_EIM_DA2__EIM_AD02 0xb0b1
+			MX6QDL_PAD_EIM_DA1__EIM_AD01 0xb0b1
+			MX6QDL_PAD_EIM_DA0__EIM_AD00 0xb0b1
+		>;
+	};
+
+	pinctrl_uart1: uart1grp {
+		fsl,pins = <
+			MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
+			MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
+		>;
+	};
+
+	pinctrl_uart2: uart2grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD3_DAT5__UART2_TX_DATA 0x1b0b1
+			MX6QDL_PAD_SD3_DAT4__UART2_RX_DATA 0x1b0b1
+			MX6QDL_PAD_SD3_CLK__UART2_RTS_B 0x1b0b1
+			MX6QDL_PAD_SD3_CMD__UART2_CTS_B 0x1b0b1
+		>;
+	};
+
+	pinctrl_usbh1: usbh1grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_3__USB_H1_OC 0x1b0b0
+			/* usbh1_b OC */
+			MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
+		>;
+	};
+
+	pinctrl_usbh1_hubreset: usbh1hubresetgrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
+		>;
+	};
+
+	pinctrl_usbotg: usbotggrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
+			MX6QDL_PAD_KEY_COL4__USB_OTG_OC 0x1b0b0
+		>;
+	};
+
+	pinctrl_usbotgvbus: usbotgvbusgrp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x000b0
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17059
+			MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10059
+			MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17059
+			MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17059
+			MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17059
+			MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17059
+		>;
+	};
+};
-- 
2.5.0



From marc.zyngier at arm.com  Wed Feb  3 09:45:47 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 3 Feb 2016 17:45:47 +0000
Subject: [PATCH v2 21/21] arm64: Panic when VHE and non VHE CPUs coexist
In-Reply-To: <20160203084913.GA13974@cbox>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-22-git-send-email-marc.zyngier@arm.com>
 <20160201153605.GA1478@cbox> <56B0CBF4.9030507@arm.com>
 <20160203084913.GA13974@cbox>
Message-ID: <56B23CCB.4000009@arm.com>

On 03/02/16 08:49, Christoffer Dall wrote:
> On Tue, Feb 02, 2016 at 03:32:04PM +0000, Marc Zyngier wrote:
>> On 01/02/16 15:36, Christoffer Dall wrote:
>>> On Mon, Jan 25, 2016 at 03:53:55PM +0000, Marc Zyngier wrote:
>>>> Having both VHE and non-VHE capable CPUs in the same system
>>>> is likely to be a recipe for disaster.
>>>>
>>>> If the boot CPU has VHE, but a secondary is not, we won't be
>>>> able to downgrade and run the kernel at EL1. Add CPU hotplug
>>>> to the mix, and this produces a terrifying mess.
>>>>
>>>> Let's solve the problem once and for all. If you mix VHE and
>>>> non-VHE CPUs in the same system, you deserve to loose, and this
>>>> patch makes sure you don't get a chance.
>>>>
>>>> This is implemented by storing the kernel execution level in
>>>> a global variable. Secondaries will park themselves in a
>>>> WFI loop if they observe a mismatch. Also, the primary CPU
>>>> will detect that the secondary CPU has died on a mismatched
>>>> execution level. Panic will follow.
>>>>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>>> ---
>>>>  arch/arm64/include/asm/virt.h | 17 +++++++++++++++++
>>>>  arch/arm64/kernel/head.S      | 19 +++++++++++++++++++
>>>>  arch/arm64/kernel/smp.c       |  3 +++
>>>>  3 files changed, 39 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
>>>> index 9f22dd6..f81a345 100644
>>>> --- a/arch/arm64/include/asm/virt.h
>>>> +++ b/arch/arm64/include/asm/virt.h
>>>> @@ -36,6 +36,11 @@
>>>>   */
>>>>  extern u32 __boot_cpu_mode[2];
>>>>  
>>>> +/*
>>>> + * __run_cpu_mode records the mode the boot CPU uses for the kernel.
>>>> + */
>>>> +extern u32 __run_cpu_mode[2];
>>>> +
>>>>  void __hyp_set_vectors(phys_addr_t phys_vector_base);
>>>>  phys_addr_t __hyp_get_vectors(void);
>>>>  
>>>> @@ -60,6 +65,18 @@ static inline bool is_kernel_in_hyp_mode(void)
>>>>  	return el == CurrentEL_EL2;
>>>>  }
>>>>  
>>>> +static inline bool is_kernel_mode_mismatched(void)
>>>> +{
>>>> +	/*
>>>> +	 * A mismatched CPU will have written its own CurrentEL in
>>>> +	 * __run_cpu_mode[1] (initially set to zero) after failing to
>>>> +	 * match the value in __run_cpu_mode[0]. Thus, a non-zero
>>>> +	 * value in __run_cpu_mode[1] is enough to detect the
>>>> +	 * pathological case.
>>>> +	 */
>>>> +	return !!ACCESS_ONCE(__run_cpu_mode[1]);
>>>> +}
>>>> +
>>>>  /* The section containing the hypervisor text */
>>>>  extern char __hyp_text_start[];
>>>>  extern char __hyp_text_end[];
>>>> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
>>>> index 2a7134c..bc44cf8 100644
>>>> --- a/arch/arm64/kernel/head.S
>>>> +++ b/arch/arm64/kernel/head.S
>>>> @@ -577,7 +577,23 @@ ENTRY(set_cpu_boot_mode_flag)
>>>>  1:	str	w20, [x1]			// This CPU has booted in EL1
>>>>  	dmb	sy
>>>>  	dc	ivac, x1			// Invalidate potentially stale cache line
>>>> +	adr_l	x1, __run_cpu_mode
>>>> +	ldr	w0, [x1]
>>>> +	mrs	x20, CurrentEL
>>>> +	cbz	x0, skip_el_check
>>>> +	cmp	x0, x20
>>>> +	bne	mismatched_el
>>>
>>> can't you do a ret here instead of writing the same value and flushing
>>> caches etc.?
>>
>> Yes, good point.
>>
>>>
>>>> +skip_el_check:			// Only the first CPU gets to set the rule
>>>> +	str	w20, [x1]
>>>> +	dmb	sy
>>>> +	dc	ivac, x1	// Invalidate potentially stale cache line
>>>>  	ret
>>>> +mismatched_el:
>>>> +	str	w20, [x1, #4]
>>>> +	dmb	sy
>>>> +	dc	ivac, x1	// Invalidate potentially stale cache line
>>>> +1:	wfi
>>>
>>> I'm no expert on SMP bringup, but doesn't this prevent the CPU from
>>> signaling completion and thus you'll never actually reach the checking
>>> code in __cpu_up?
>>
>> Indeed, and that's the whole point. The primary CPU will notice that the
>> secondary CPU has failed to boot (timeout), and will find the reason in
>> __run_cpu_mode.
>>
> That wasn't exactly my point.  If I understand correctly and __cpu_up is
> the primary CPU executing a function to bring up a secondary core, then
> it will wait for the cpu_running completion which should be signalled by
> the secondary core, but because the secondary core never makes any
> progress it will timeout the wait for completion and you will see that
> error "..failed to come online" instead of the "incompatible execution
> level".

It will actually do both. Here's an example on the model configured for
such a braindead case:

CPU4: failed to come online
Kernel panic - not syncing: CPU4: incompatible execution level
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc2+ #5459
Hardware name: FVP Base (DT)
Call trace:
[<ffffffc0000899e0>] dump_backtrace+0x0/0x180
[<ffffffc000089b74>] show_stack+0x14/0x20
[<ffffffc000333b08>] dump_stack+0x90/0xc8
[<ffffffc00014d424>] panic+0x10c/0x250
[<ffffffc00008ef24>] __cpu_up+0xfc/0x100
[<ffffffc0000b7a9c>] _cpu_up+0x154/0x188
[<ffffffc0000b7b54>] cpu_up+0x84/0xa8
[<ffffffc0009e9d00>] smp_init+0xbc/0xc0
[<ffffffc0009dca10>] kernel_init_freeable+0x94/0x1ec
[<ffffffc000712f90>] kernel_init+0x10/0xe0
[<ffffffc000085cd0>] ret_from_fork+0x10/0x40

Am I missing something *really* obvious?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From broonie at kernel.org  Wed Feb  3 09:47:53 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 3 Feb 2016 17:47:53 +0000
Subject: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
 ACT8945A
In-Reply-To: <B256D81BAE5131468A838E5D7A243641D64026CB@penmbx01>
References: <1453863463-30515-1-git-send-email-wenyou.yang@atmel.com>
 <1453863463-30515-2-git-send-email-wenyou.yang@atmel.com>
 <20160129001603.GM4130@sirena.org.uk>
 <B256D81BAE5131468A838E5D7A243641D63FBF8B@penmbx01>
 <20160129113518.GQ4130@sirena.org.uk>
 <CABxcv=kNKmgRytxB5ppawrAvC-GDRhV4T_UUGvpHgKp9+BsUmQ@mail.gmail.com>
 <B256D81BAE5131468A838E5D7A243641D63FE2C7@penmbx01>
 <CABxcv=nJsWEv9KW-5iPpUnyN8ZVpx6CV07gBRaLNWqd644YOqQ@mail.gmail.com>
 <B256D81BAE5131468A838E5D7A243641D64026CB@penmbx01>
Message-ID: <20160203174753.GJ4455@sirena.org.uk>

On Wed, Feb 03, 2016 at 02:33:11AM +0000, Yang, Wenyou wrote:

> > I would just remove the "active-semi,act8945a-regulator" node and make "active-
> > semi,vsel-high" a property of the "active-semi,act8945a" node.
> > That way you can remove the mfd cell .of_compatible and OF table in the
> > regulator driver and read the "active-semi,vsel-high" using the platform device's
> > parent of_node.

> > But it's better if you wait for Mark's opinions before re-spining your patches.

> Hi Mark, what is your opinions?

Like Javier says you should make your DT binding look like the DT
bindings for other MFDs and not use of_compatible.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/30814480/attachment.sig>

From timur at codeaurora.org  Wed Feb  3 09:48:17 2016
From: timur at codeaurora.org (Timur Tabi)
Date: Wed, 3 Feb 2016 11:48:17 -0600
Subject: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <1454519923-25230-5-git-send-email-fu.wei@linaro.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-5-git-send-email-fu.wei@linaro.org>
Message-ID: <56B23D61.2050001@codeaurora.org>

fu.wei at linaro.org wrote:
> +static struct platform_driver sbsa_gwdt_driver = {
> +	.driver = {
> +		.name = "sbsa-gwdt",
> +		.pm = &sbsa_gwdt_pm_ops,
> +		.of_match_table = sbsa_gwdt_of_match,
> +	},
> +	.probe = sbsa_gwdt_probe,
> +	.remove = sbsa_gwdt_remove,
> +	.shutdown = sbsa_gwdt_shutdown,
> +	.id_table = sbsa_gwdt_pdev_match,
> +};

I just noticed you dropped ACPI support.  Server platforms are supposed 
to use ACPI, so that seems like a critical omission to me.  You had a 
GTDT parser in an older version of this patch.  What happened to it?


From fu.wei at linaro.org  Wed Feb  3 09:49:02 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Thu, 4 Feb 2016 01:49:02 +0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <56B23883.7000501@codeaurora.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
Message-ID: <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>

Hi Timur,

Thanks for your rapid feedback :-)

On 4 February 2016 at 01:27, Timur Tabi <timur at codeaurora.org> wrote:
> fu.wei at linaro.org wrote:
>>
>> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
>> +static bool panic_enabled = true;
>
>
> I think this should default to 'false', because IMHO, this seems like an odd

yes, It make sense to make it default to 'false'.

> feature.  I'm not crazy about the fact that there's a Kconfig option for it
> either, but I'm not going to NACK this patch.
>
> I personally would prefer to drop this patch, and just wait for full-blown
> pre-timeout support.  It feels like a debugging feature that doesn't really

sorry, are you saying : using pre-timeout instead of this half timeout?

But even we have pre-timeout support, pre-timeout  == timeout / 2, it
can not be configured without touch timeout.

if you want pre-timeout  != timeout / 2, we have to modify WCV in the
interrupt routine.
 (because of the explicit watchdog refresh  mechanism)

Could you let me know why we need pre-timeout  here ?? :-)

> belong upstream.  But like I said, it's just my opinion, and I won't
> complain if I'm outvoted.

 I think this debugging feature is the  purpose of the two-stage
watchdog, if I understand correctly



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From timur at codeaurora.org  Wed Feb  3 09:53:29 2016
From: timur at codeaurora.org (Timur Tabi)
Date: Wed, 3 Feb 2016 11:53:29 -0600
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
Message-ID: <56B23E99.1030604@codeaurora.org>

Fu Wei wrote:
> sorry, are you saying : using pre-timeout instead of this half timeout?
>
> But even we have pre-timeout support, pre-timeout  == timeout / 2, it
> can not be configured without touch timeout.
>
> if you want pre-timeout  != timeout / 2, we have to modify WCV in the
> interrupt routine.
>   (because of the explicit watchdog refresh  mechanism)
>
> Could you let me know why we need pre-timeout  here ??:-)

What I meant was that if we had full-blown pre-timeout support in the 
watchdog layer, then you could use that to implement the 
panic-on-half-timeout feature.

When pre-timeout is implemented, will you modify the interrupt handler 
to use it?

>> >belong upstream.  But like I said, it's just my opinion, and I won't
>> >complain if I'm outvoted.
>   I think this debugging feature is the  purpose of the two-stage
> watchdog, if I understand correctly

Hmmm... that make sense.  I think maybe you should drop the Kconfig 
option, and just have "static bool panic_enabled = false;"  Also, then 
do this:

if (panic_enabled) {
	ret = devm_request_irq(dev, irq, sbsa_gwdt_interrupt, 0,
			       pdev->name, gwdt);
	if (ret) {
		dev_err(dev, "unable to request IRQ %d\n", irq);
		return ret;
	}
}

That way, the interrupt handler is never registered if the command-line 
parameter is not specified.



From mark.rutland at arm.com  Wed Feb  3 09:53:51 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 3 Feb 2016 17:53:51 +0000
Subject: [PATCH v4 4/7] arm64: Handle early CPU boot failures
In-Reply-To: <20160203173448.GD26487@MBP.local>
References: <1453745225-27736-1-git-send-email-suzuki.poulose@arm.com>
 <1453745225-27736-5-git-send-email-suzuki.poulose@arm.com>
 <20160203125735.GA26487@MBP.local>
 <20160203164632.GC1234@leverpostej>
 <20160203173448.GD26487@MBP.local>
Message-ID: <20160203175351.GG1234@leverpostej>

On Wed, Feb 03, 2016 at 05:34:49PM +0000, Catalin Marinas wrote:
> On Wed, Feb 03, 2016 at 04:46:32PM +0000, Mark Rutland wrote:
> > On Wed, Feb 03, 2016 at 12:57:38PM +0000, Catalin Marinas wrote:
> > > On Mon, Jan 25, 2016 at 06:07:02PM +0000, Suzuki K. Poulose wrote:
> > > > + * update_early_cpu_boot_status tmp, status
> > > > + *  - Corrupts tmp, x0, x1
> > > > + *  - Writes 'status' to __early_cpu_boot_status and makes sure
> > > > + *    it is committed to memory.
> > > > + */
> > > > +
> > > > +	.macro	update_early_cpu_boot_status tmp, status
> > > > +	mov	\tmp, lr
> > > > +	adrp	x0, __early_cpu_boot_status
> > > > +	add	x0, x0, #:lo12:__early_cpu_boot_status
> > > 
> > > Nitpick: you could use the adr_l macro.
> > > 
> > > > +	mov	x1, #\status
> > > > +	str	x1, [x0]
> > > > +	add	x1, x0, 4
> > > > +	bl	__inval_cache_range
> > > > +	mov	lr, \tmp
> > > > +	.endm
> > > 
> > > If the CPU that's currently booting has the MMU off, what's the point of
> > > invalidating the cache here?
> > 
> > To invalidate stale lines for this address, held in any caches prior to
> > the PoC. I'm assuming that __early_cpu_boot_status is sufficiently
> > padded to the CWG.
> 
> I would have rather invalidated it before writing the [x0], if that's
> what it's aimed at.

That alone wouldn't not be sufficient, due to speculative fetches
allocating new (clean) lines prior to the write completing.

I was expecting the CWG-aligned region to only be written to with the
MMU off, i.e. we'd only have clean stale lines and no dirty lines.

> > Cache maintenance works when SCTLR_ELx.M == 0, though barriers are
> > required prior to cache maintenance as non-cacheable accesses do not
> > hazard by VA.
> > 
> > The MMU being off has no effect on the cache maintenance itself.
> 
> I know, but whether it has an effect on other CPUs is a different
> question (it probably has). Anyway, I would rather do the invalidation
> on the CPU that actually reads this status.

My only worry would be how this gets ordered against the (non-cacheable)
store. I guess we'd complete that with a DSB SY regardless.

Given that, I have no problem doing the invalidate on the read side.
Assuming we only write from the side with the MMU off, we don't need
maintenance on that side.

> > > The operation may not even be broadcast to the other CPU. So you
> > > actually need the invalidation before reading the status on the
> > > primary CPU.
> > 
> > We require that CPUs are coherent when they enter the kernel, so any
> > cache maintenance operation _must_ affect all coherent caches (i.e. it
> > must be broadcast and must affect all coherent caches prior to the PoC
> > in this case).
> 
> In general, if you perform cache maintenance on a non-shareable mapping,
> I don't think it would be broadcast. But in this case, the MMU is off,
> data accesses default to Device_nGnRnE and considered outer shareable,
> so it may actually work. Is this stated anywhere in the ARM ARM?

In ARM DDI 0487A.h, D4.2.8 "The effects of disabling a stage of address
translation" we state:

	Cache maintenance instructions act on the target cache
	regardless of whether any stages of address translation are
	disabled, and regardless of the values of the memory attributes.
	However, if a stage of address translation is disabled, they use
	the flat address mapping for that translation stage.

Thanks,
Mark.


From fu.wei at linaro.org  Wed Feb  3 09:57:23 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Thu, 4 Feb 2016 01:57:23 +0800
Subject: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <56B23D61.2050001@codeaurora.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-5-git-send-email-fu.wei@linaro.org>
 <56B23D61.2050001@codeaurora.org>
Message-ID: <CADyBb7tteV7VF9oxMaq5NprVdS2UBKobupxoyfSp+jQwp5wmQA@mail.gmail.com>

Hi Timur,

On 4 February 2016 at 01:48, Timur Tabi <timur at codeaurora.org> wrote:
> fu.wei at linaro.org wrote:
>>
>> +static struct platform_driver sbsa_gwdt_driver = {
>> +       .driver = {
>> +               .name = "sbsa-gwdt",
>> +               .pm = &sbsa_gwdt_pm_ops,
>> +               .of_match_table = sbsa_gwdt_of_match,
>> +       },
>> +       .probe = sbsa_gwdt_probe,
>> +       .remove = sbsa_gwdt_remove,
>> +       .shutdown = sbsa_gwdt_shutdown,
>> +       .id_table = sbsa_gwdt_pdev_match,
>> +};
>
>
> I just noticed you dropped ACPI support.  Server platforms are supposed to
> use ACPI, so that seems like a critical omission to me.  You had a GTDT
> parser in an older version of this patch.  What happened to it?

I have posted  GTDT support separately : https://lkml.org/lkml/2016/2/1/660

devicetree driver and GTDT driver both export sbsa gwdt info to
"platform resource".

this driver get hardware info from platform resource.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From timur at codeaurora.org  Wed Feb  3 09:58:57 2016
From: timur at codeaurora.org (Timur Tabi)
Date: Wed, 3 Feb 2016 11:58:57 -0600
Subject: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <CADyBb7tteV7VF9oxMaq5NprVdS2UBKobupxoyfSp+jQwp5wmQA@mail.gmail.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-5-git-send-email-fu.wei@linaro.org>
 <56B23D61.2050001@codeaurora.org>
 <CADyBb7tteV7VF9oxMaq5NprVdS2UBKobupxoyfSp+jQwp5wmQA@mail.gmail.com>
Message-ID: <56B23FE1.2010207@codeaurora.org>

Fu Wei wrote:
> I have posted  GTDT support separately :https://lkml.org/lkml/2016/2/1/660
>
> devicetree driver and GTDT driver both export sbsa gwdt info to
> "platform resource".
>
> this driver get hardware info from platform resource.

I must be missing something.  How does the driver probe?  It only has an 
entry for device tree:

+		.of_match_table = sbsa_gwdt_of_match,

Doesn't there need to be an ACPI match table to probe on an ACPI system?


From grant.likely at linaro.org  Wed Feb  3 10:00:01 2016
From: grant.likely at linaro.org (Grant Likely)
Date: Wed,  3 Feb 2016 18:00:01 +0000
Subject: [PATCH] aarch64: Enable i2c chardev in defconfig
Message-ID: <1454522401-3729-1-git-send-email-grant.likely@linaro.org>

The I2C character device is commonly used, and should be enabled by
default. Add it to the defconfig.

Signed-off-by: Grant Likely <grant.likely at linaro.org>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d63b6e3797b6..3c26e587a264 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -147,6 +147,7 @@ CONFIG_SERIAL_XILINX_PS_UART=y
 CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
 CONFIG_VIRTIO_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
+CONFIG_I2C_CHARDEV=y
 CONFIG_I2C_DESIGNWARE_PLATFORM=y
 CONFIG_I2C_QUP=y
 CONFIG_SPI=y
-- 
2.5.0



From marc.zyngier at arm.com  Wed Feb  3 09:59:56 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 17:59:56 +0000
Subject: [PATCH v3 03/23] arm/arm64: Add new is_kernel_in_hyp_mode predicate
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-4-git-send-email-marc.zyngier@arm.com>

With ARMv8.1 VHE extension, it will be possible to run the kernel
at EL2 (aka HYP mode). In order for the kernel to easily find out
where it is running, add a new predicate that returns whether or
not the kernel is in HYP mode.

For completeness, the 32bit code also get such a predicate (always
returning false) so that code common to both architecture (timers,
KVM) can use it transparently.

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/virt.h   |  5 +++++
 arch/arm64/include/asm/virt.h | 10 ++++++++++
 2 files changed, 15 insertions(+)

diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
index 4371f45..b6a3cef 100644
--- a/arch/arm/include/asm/virt.h
+++ b/arch/arm/include/asm/virt.h
@@ -74,6 +74,11 @@ static inline bool is_hyp_mode_mismatched(void)
 {
 	return !!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH);
 }
+
+static inline bool is_kernel_in_hyp_mode(void)
+{
+	return false;
+}
 #endif
 
 #endif /* __ASSEMBLY__ */
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 7a5df52..9f22dd6 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -23,6 +23,8 @@
 
 #ifndef __ASSEMBLY__
 
+#include <asm/ptrace.h>
+
 /*
  * __boot_cpu_mode records what mode CPUs were booted in.
  * A correctly-implemented bootloader must start all CPUs in the same mode:
@@ -50,6 +52,14 @@ static inline bool is_hyp_mode_mismatched(void)
 	return __boot_cpu_mode[0] != __boot_cpu_mode[1];
 }
 
+static inline bool is_kernel_in_hyp_mode(void)
+{
+	u64 el;
+
+	asm("mrs %0, CurrentEL" : "=r" (el));
+	return el == CurrentEL_EL2;
+}
+
 /* The section containing the hypervisor text */
 extern char __hyp_text_start[];
 extern char __hyp_text_end[];
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 09:59:54 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 17:59:54 +0000
Subject: [PATCH v3 01/23] arm/arm64: KVM: Add hook for C-based stage2 init
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-2-git-send-email-marc.zyngier@arm.com>

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_host.h   | 4 ++++
 arch/arm/kvm/arm.c                | 1 +
 arch/arm64/include/asm/kvm_host.h | 4 ++++
 3 files changed, 9 insertions(+)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index f9f2779..f1e86f1 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -220,6 +220,10 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
 	kvm_call_hyp((void*)hyp_stack_ptr, vector_ptr, pgd_ptr);
 }
 
+static inline void __cpu_init_stage2(void)
+{
+}
+
 static inline int kvm_arch_dev_ioctl_check_extension(long ext)
 {
 	return 0;
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dda1959..6b76e01 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -985,6 +985,7 @@ static void cpu_init_hyp_mode(void *dummy)
 	vector_ptr = (unsigned long)__kvm_hyp_vector;
 
 	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
+	__cpu_init_stage2();
 
 	kvm_arm_init_debug();
 }
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 689d4c9..fe86cf9 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -332,6 +332,10 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
 		     hyp_stack_ptr, vector_ptr);
 }
 
+static inline void __cpu_init_stage2(void)
+{
+}
+
 static inline void kvm_arch_hardware_disable(void) {}
 static inline void kvm_arch_hardware_unsetup(void) {}
 static inline void kvm_arch_sync_events(struct kvm *kvm) {}
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 09:59:53 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 17:59:53 +0000
Subject: [PATCH v3 00/23] arm64: Virtualization Host Extension support
Message-ID: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>

ARMv8.1 comes with the "Virtualization Host Extension" (VHE for
short), which enables simpler support of Type-2 hypervisors.

This extension allows the kernel to directly run at EL2, and
significantly reduces the number of system registers shared between
host and guest, reducing the overhead of virtualization.

In order to have the same kernel binary running on all versions of the
architecture, this series makes heavy use of runtime code patching.

The first 22 patches massage the KVM code to deal with VHE and enable
Linux to run at EL2. The last patch catches an ugly case when VHE
capable CPUs are paired with some of their less capable siblings. This
should never happen, but hey...

I have deliberately left out some of the more "advanced"
optimizations, as they are likely to distract the reviewer from the
core infrastructure, which is what I care about at the moment.

Note: GDB is currently busted on VHE systems, as it checks for version
      6 on the debug architecture, while VHE is version 7. The
      binutils people are on the case.

This has been tested on the FVP_Base_SLV-V8-A model, and based on
v4.5-rc2. I've put a branch out on:

git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/vhe

* From v2:
  - Added support for perf to count kernel events in EL2
  - Added support for EL2 breakpoints
  - Moved the VTCR_EL2 setup from assembly to C
  - Made the fault handling easier to understand (hopefuly)
  - Plenty of smaller fixups

* From v1:
  - Full rewrite now that the World Switch is written in C code.
  - Dropped the "early IRQ handling" for the moment.

Marc Zyngier (23):
  arm/arm64: KVM: Add hook for C-based stage2 init
  arm64: KVM: Switch to C-based stage2 init
  arm/arm64: Add new is_kernel_in_hyp_mode predicate
  arm64: Allow the arch timer to use the HYP timer
  arm64: Add ARM64_HAS_VIRT_HOST_EXTN feature
  arm64: KVM: Skip HYP setup when already running in HYP
  arm64: KVM: VHE: Patch out use of HVC
  arm64: KVM: VHE: Patch out kern_hyp_va
  arm64: KVM: VHE: Introduce unified system register accessors
  arm64: KVM: VHE: Differenciate host/guest sysreg save/restore
  arm64: KVM: VHE: Split save/restore of registers shared between guest
    and host
  arm64: KVM: VHE: Use unified system register accessors
  arm64: KVM: VHE: Enable minimal sysreg save/restore
  arm64: KVM: VHE: Make __fpsimd_enabled VHE aware
  arm64: KVM: VHE: Implement VHE activate/deactivate_traps
  arm64: KVM: VHE: Use unified sysreg accessors for timer
  arm64: KVM: VHE: Add fpsimd enabling on guest access
  arm64: KVM: VHE: Add alternative panic handling
  arm64: KVM: Move most of the fault decoding to C
  arm64: perf: Count EL2 events if the kernel is running in HYP
  arm64: hw_breakpoint: Allow EL2 breakpoints if running in HYP
  arm64: VHE: Add support for running Linux in EL2 mode
  arm64: Panic when VHE and non VHE CPUs coexist

 arch/arm/include/asm/kvm_host.h        |   4 +
 arch/arm/include/asm/virt.h            |   5 +
 arch/arm/kvm/arm.c                     | 174 +++++++++++++++++++----------
 arch/arm/kvm/mmu.c                     |   7 ++
 arch/arm64/Kconfig                     |  13 +++
 arch/arm64/include/asm/cpufeature.h    |   3 +-
 arch/arm64/include/asm/hw_breakpoint.h |  49 ++++++---
 arch/arm64/include/asm/kvm_arm.h       |   6 +-
 arch/arm64/include/asm/kvm_asm.h       |   2 +
 arch/arm64/include/asm/kvm_emulate.h   |   3 +
 arch/arm64/include/asm/kvm_host.h      |   6 +
 arch/arm64/include/asm/kvm_mmu.h       |  12 +-
 arch/arm64/include/asm/virt.h          |  27 +++++
 arch/arm64/kernel/asm-offsets.c        |   3 -
 arch/arm64/kernel/cpufeature.c         |  11 ++
 arch/arm64/kernel/head.S               |  48 +++++++-
 arch/arm64/kernel/perf_event.c         |  14 ++-
 arch/arm64/kernel/smp.c                |   3 +
 arch/arm64/kvm/hyp-init.S              |  18 ---
 arch/arm64/kvm/hyp.S                   |   7 ++
 arch/arm64/kvm/hyp/Makefile            |   1 +
 arch/arm64/kvm/hyp/entry.S             |   6 +
 arch/arm64/kvm/hyp/hyp-entry.S         | 109 ++++++------------
 arch/arm64/kvm/hyp/hyp.h               | 108 ++++++++++++++++--
 arch/arm64/kvm/hyp/s2-setup.c          |  44 ++++++++
 arch/arm64/kvm/hyp/switch.c            | 196 ++++++++++++++++++++++++++++++---
 arch/arm64/kvm/hyp/sysreg-sr.c         | 147 ++++++++++++++++---------
 arch/arm64/kvm/hyp/timer-sr.c          |  10 +-
 drivers/clocksource/arm_arch_timer.c   |  96 +++++++++-------
 29 files changed, 837 insertions(+), 295 deletions(-)
 create mode 100644 arch/arm64/kvm/hyp/s2-setup.c

-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 09:59:55 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 17:59:55 +0000
Subject: [PATCH v3 02/23] arm64: KVM: Switch to C-based stage2 init
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-3-git-send-email-marc.zyngier@arm.com>

There is no real need to leave the stage2 initialization as part
of the early HYP bootstrap, and we can easily postpone it to
the point where we can safely run C code.

This will help VHE, which doesn't need any of this bootstrap.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_asm.h  |  2 ++
 arch/arm64/include/asm/kvm_host.h |  2 ++
 arch/arm64/kvm/hyp-init.S         | 18 ----------------
 arch/arm64/kvm/hyp/Makefile       |  1 +
 arch/arm64/kvm/hyp/s2-setup.c     | 44 +++++++++++++++++++++++++++++++++++++++
 5 files changed, 49 insertions(+), 18 deletions(-)
 create mode 100644 arch/arm64/kvm/hyp/s2-setup.c

diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 52b777b..67ac580 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -48,6 +48,8 @@ extern u64 __vgic_v3_get_ich_vtr_el2(void);
 
 extern u32 __kvm_get_mdcr_el2(void);
 
+extern void __init_stage2_translation(void);
+
 #endif
 
 #endif /* __ARM_KVM_ASM_H__ */
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index fe86cf9..43688d9 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -25,6 +25,7 @@
 #include <linux/types.h>
 #include <linux/kvm_types.h>
 #include <asm/kvm.h>
+#include <asm/kvm_asm.h>
 #include <asm/kvm_mmio.h>
 
 #define __KVM_HAVE_ARCH_INTC_INITIALIZED
@@ -334,6 +335,7 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
 
 static inline void __cpu_init_stage2(void)
 {
+	kvm_call_hyp(__init_stage2_translation);
 }
 
 static inline void kvm_arch_hardware_disable(void) {}
diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
index 3e568dc..80fda7e 100644
--- a/arch/arm64/kvm/hyp-init.S
+++ b/arch/arm64/kvm/hyp-init.S
@@ -87,24 +87,6 @@ __do_hyp_init:
 #endif
 	msr	tcr_el2, x4
 
-	ldr	x4, =VTCR_EL2_FLAGS
-	/*
-	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
-	 * VTCR_EL2.
-	 */
-	mrs	x5, ID_AA64MMFR0_EL1
-	bfi	x4, x5, #16, #3
-	/*
-	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS bit in
-	 * VTCR_EL2.
-	 */
-	mrs	x5, ID_AA64MMFR1_EL1
-	ubfx	x5, x5, #5, #1
-	lsl	x5, x5, #VTCR_EL2_VS
-	orr	x4, x4, x5
-
-	msr	vtcr_el2, x4
-
 	mrs	x4, mair_el1
 	msr	mair_el2, x4
 	isb
diff --git a/arch/arm64/kvm/hyp/Makefile b/arch/arm64/kvm/hyp/Makefile
index 826032b..5326e66 100644
--- a/arch/arm64/kvm/hyp/Makefile
+++ b/arch/arm64/kvm/hyp/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_KVM_ARM_HOST) += switch.o
 obj-$(CONFIG_KVM_ARM_HOST) += fpsimd.o
 obj-$(CONFIG_KVM_ARM_HOST) += tlb.o
 obj-$(CONFIG_KVM_ARM_HOST) += hyp-entry.o
+obj-$(CONFIG_KVM_ARM_HOST) += s2-setup.o
diff --git a/arch/arm64/kvm/hyp/s2-setup.c b/arch/arm64/kvm/hyp/s2-setup.c
new file mode 100644
index 0000000..17e8cc0
--- /dev/null
+++ b/arch/arm64/kvm/hyp/s2-setup.c
@@ -0,0 +1,44 @@
+/*
+ * Copyright (C) 2016 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.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/types.h>
+#include <asm/kvm_arm.h>
+#include <asm/kvm_asm.h>
+
+#include "hyp.h"
+
+void __hyp_text __init_stage2_translation(void)
+{
+	u64 val = VTCR_EL2_FLAGS;
+	u64 tmp;
+
+	/*
+	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS
+	 * bits in VTCR_EL2. Amusingly, the PARange is 4 bits, while
+	 * PS is only 3. Fortunately, bit 19 is RES0 in VTCR_EL2...
+	 */
+	val |= (read_sysreg(id_aa64mmfr0_el1) & 7) << 16;
+
+	/*
+	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS
+	 * bit in VTCR_EL2.
+	 */
+	tmp = (read_sysreg(id_aa64mmfr1_el1) >> 4) & 0xf;
+	val |= (tmp == 2) ? VTCR_EL2_VS : 0;
+
+	write_sysreg(val, vtcr_el2);
+}
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 09:59:57 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 17:59:57 +0000
Subject: [PATCH v3 04/23] arm64: Allow the arch timer to use the HYP timer
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-5-git-send-email-marc.zyngier@arm.com>

With the ARMv8.1 VHE, the kernel can run in HYP mode, and thus
use the HYP timer instead of the normal guest timer in a mostly
transparent way, except for the interrupt line.

This patch reworks the arch timer code to allow the selection of
the HYP PPI, possibly falling back to the guest timer if not
available.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 drivers/clocksource/arm_arch_timer.c | 96 ++++++++++++++++++++++--------------
 1 file changed, 59 insertions(+), 37 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index c64d543..ffe9d1c 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -67,7 +67,7 @@ static int arch_timer_ppi[MAX_TIMER_PPI];
 
 static struct clock_event_device __percpu *arch_timer_evt;
 
-static bool arch_timer_use_virtual = true;
+static enum ppi_nr arch_timer_uses_ppi = VIRT_PPI;
 static bool arch_timer_c3stop;
 static bool arch_timer_mem_use_virtual;
 
@@ -263,14 +263,20 @@ static void __arch_timer_setup(unsigned type,
 		clk->name = "arch_sys_timer";
 		clk->rating = 450;
 		clk->cpumask = cpumask_of(smp_processor_id());
-		if (arch_timer_use_virtual) {
-			clk->irq = arch_timer_ppi[VIRT_PPI];
+		clk->irq = arch_timer_ppi[arch_timer_uses_ppi];
+		switch (arch_timer_uses_ppi) {
+		case VIRT_PPI:
 			clk->set_state_shutdown = arch_timer_shutdown_virt;
 			clk->set_next_event = arch_timer_set_next_event_virt;
-		} else {
-			clk->irq = arch_timer_ppi[PHYS_SECURE_PPI];
+			break;
+		case PHYS_SECURE_PPI:
+		case PHYS_NONSECURE_PPI:
+		case HYP_PPI:
 			clk->set_state_shutdown = arch_timer_shutdown_phys;
 			clk->set_next_event = arch_timer_set_next_event_phys;
+			break;
+		default:
+			BUG();
 		}
 	} else {
 		clk->features |= CLOCK_EVT_FEAT_DYNIRQ;
@@ -338,17 +344,20 @@ static void arch_counter_set_user_access(void)
 	arch_timer_set_cntkctl(cntkctl);
 }
 
+static bool arch_timer_has_nonsecure_ppi(void)
+{
+	return (arch_timer_uses_ppi == PHYS_SECURE_PPI &&
+		arch_timer_ppi[PHYS_NONSECURE_PPI]);
+}
+
 static int arch_timer_setup(struct clock_event_device *clk)
 {
 	__arch_timer_setup(ARCH_CP15_TIMER, clk);
 
-	if (arch_timer_use_virtual)
-		enable_percpu_irq(arch_timer_ppi[VIRT_PPI], 0);
-	else {
-		enable_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI], 0);
-		if (arch_timer_ppi[PHYS_NONSECURE_PPI])
-			enable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI], 0);
-	}
+	enable_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi], 0);
+
+	if (arch_timer_has_nonsecure_ppi())
+		enable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI], 0);
 
 	arch_counter_set_user_access();
 	if (IS_ENABLED(CONFIG_ARM_ARCH_TIMER_EVTSTREAM))
@@ -390,7 +399,7 @@ static void arch_timer_banner(unsigned type)
 		     (unsigned long)arch_timer_rate / 1000000,
 		     (unsigned long)(arch_timer_rate / 10000) % 100,
 		     type & ARCH_CP15_TIMER ?
-			arch_timer_use_virtual ? "virt" : "phys" :
+		     (arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :
 			"",
 		     type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ?  "/" : "",
 		     type & ARCH_MEM_TIMER ?
@@ -460,7 +469,7 @@ static void __init arch_counter_register(unsigned type)
 
 	/* Register the CP15 based counter if we have one */
 	if (type & ARCH_CP15_TIMER) {
-		if (IS_ENABLED(CONFIG_ARM64) || arch_timer_use_virtual)
+		if (IS_ENABLED(CONFIG_ARM64) || arch_timer_uses_ppi == VIRT_PPI)
 			arch_timer_read_counter = arch_counter_get_cntvct;
 		else
 			arch_timer_read_counter = arch_counter_get_cntpct;
@@ -490,13 +499,9 @@ static void arch_timer_stop(struct clock_event_device *clk)
 	pr_debug("arch_timer_teardown disable IRQ%d cpu #%d\n",
 		 clk->irq, smp_processor_id());
 
-	if (arch_timer_use_virtual)
-		disable_percpu_irq(arch_timer_ppi[VIRT_PPI]);
-	else {
-		disable_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI]);
-		if (arch_timer_ppi[PHYS_NONSECURE_PPI])
-			disable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI]);
-	}
+	disable_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi]);
+	if (arch_timer_has_nonsecure_ppi())
+		disable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI]);
 
 	clk->set_state_shutdown(clk);
 }
@@ -562,12 +567,14 @@ static int __init arch_timer_register(void)
 		goto out;
 	}
 
-	if (arch_timer_use_virtual) {
-		ppi = arch_timer_ppi[VIRT_PPI];
+	ppi = arch_timer_ppi[arch_timer_uses_ppi];
+	switch (arch_timer_uses_ppi) {
+	case VIRT_PPI:
 		err = request_percpu_irq(ppi, arch_timer_handler_virt,
 					 "arch_timer", arch_timer_evt);
-	} else {
-		ppi = arch_timer_ppi[PHYS_SECURE_PPI];
+		break;
+	case PHYS_SECURE_PPI:
+	case PHYS_NONSECURE_PPI:
 		err = request_percpu_irq(ppi, arch_timer_handler_phys,
 					 "arch_timer", arch_timer_evt);
 		if (!err && arch_timer_ppi[PHYS_NONSECURE_PPI]) {
@@ -578,6 +585,13 @@ static int __init arch_timer_register(void)
 				free_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI],
 						arch_timer_evt);
 		}
+		break;
+	case HYP_PPI:
+		err = request_percpu_irq(ppi, arch_timer_handler_phys,
+					 "arch_timer", arch_timer_evt);
+		break;
+	default:
+		BUG();
 	}
 
 	if (err) {
@@ -602,15 +616,10 @@ static int __init arch_timer_register(void)
 out_unreg_notify:
 	unregister_cpu_notifier(&arch_timer_cpu_nb);
 out_free_irq:
-	if (arch_timer_use_virtual)
-		free_percpu_irq(arch_timer_ppi[VIRT_PPI], arch_timer_evt);
-	else {
-		free_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI],
+	free_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi], arch_timer_evt);
+	if (arch_timer_has_nonsecure_ppi())
+		free_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI],
 				arch_timer_evt);
-		if (arch_timer_ppi[PHYS_NONSECURE_PPI])
-			free_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI],
-					arch_timer_evt);
-	}
 
 out_free:
 	free_percpu(arch_timer_evt);
@@ -697,12 +706,25 @@ static void __init arch_timer_init(void)
 	 *
 	 * If no interrupt provided for virtual timer, we'll have to
 	 * stick to the physical timer. It'd better be accessible...
+	 *
+	 * On ARMv8.1 with VH extensions, the kernel runs in HYP. VHE
+	 * accesses to CNTP_*_EL1 registers are silently redirected to
+	 * their CNTHP_*_EL2 counterparts, and use a different PPI
+	 * number.
 	 */
 	if (is_hyp_mode_available() || !arch_timer_ppi[VIRT_PPI]) {
-		arch_timer_use_virtual = false;
+		bool has_ppi;
+
+		if (is_kernel_in_hyp_mode()) {
+			arch_timer_uses_ppi = HYP_PPI;
+			has_ppi = !!arch_timer_ppi[HYP_PPI];
+		} else {
+			arch_timer_uses_ppi = PHYS_SECURE_PPI;
+			has_ppi = (!!arch_timer_ppi[PHYS_SECURE_PPI] ||
+				   !!arch_timer_ppi[PHYS_NONSECURE_PPI]);
+		}
 
-		if (!arch_timer_ppi[PHYS_SECURE_PPI] ||
-		    !arch_timer_ppi[PHYS_NONSECURE_PPI]) {
+		if (!has_ppi) {
 			pr_warn("arch_timer: No interrupt available, giving up\n");
 			return;
 		}
@@ -735,7 +757,7 @@ static void __init arch_timer_of_init(struct device_node *np)
 	 */
 	if (IS_ENABLED(CONFIG_ARM) &&
 	    of_property_read_bool(np, "arm,cpu-registers-not-fw-configured"))
-			arch_timer_use_virtual = false;
+		arch_timer_uses_ppi = PHYS_SECURE_PPI;
 
 	arch_timer_init();
 }
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 09:59:58 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 17:59:58 +0000
Subject: [PATCH v3 05/23] arm64: Add ARM64_HAS_VIRT_HOST_EXTN feature
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-6-git-send-email-marc.zyngier@arm.com>

Add a new ARM64_HAS_VIRT_HOST_EXTN features to indicate that the
CPU has the ARMv8.1 VHE capability.

This will be used to trigger kernel patching in KVM.

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/cpufeature.h |  3 ++-
 arch/arm64/kernel/cpufeature.c      | 11 +++++++++++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 8f271b8..c705d6a 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -30,8 +30,9 @@
 #define ARM64_HAS_LSE_ATOMICS			5
 #define ARM64_WORKAROUND_CAVIUM_23154		6
 #define ARM64_WORKAROUND_834220			7
+#define ARM64_HAS_VIRT_HOST_EXTN		8
 
-#define ARM64_NCAPS				8
+#define ARM64_NCAPS				9
 
 #ifndef __ASSEMBLY__
 
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 5c90aa4..ba74519 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -26,6 +26,7 @@
 #include <asm/cpu_ops.h>
 #include <asm/processor.h>
 #include <asm/sysreg.h>
+#include <asm/virt.h>
 
 unsigned long elf_hwcap __read_mostly;
 EXPORT_SYMBOL_GPL(elf_hwcap);
@@ -621,6 +622,11 @@ static bool has_useable_gicv3_cpuif(const struct arm64_cpu_capabilities *entry)
 	return has_sre;
 }
 
+static bool runs_at_el2(const struct arm64_cpu_capabilities *entry)
+{
+	return is_kernel_in_hyp_mode();
+}
+
 static const struct arm64_cpu_capabilities arm64_features[] = {
 	{
 		.desc = "GIC system register CPU interface",
@@ -651,6 +657,11 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.min_field_value = 2,
 	},
 #endif /* CONFIG_AS_LSE && CONFIG_ARM64_LSE_ATOMICS */
+	{
+		.desc = "Virtualization Host Extensions",
+		.capability = ARM64_HAS_VIRT_HOST_EXTN,
+		.matches = runs_at_el2,
+	},
 	{},
 };
 
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 10:00:02 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:02 +0000
Subject: [PATCH v3 09/23] arm64: KVM: VHE: Introduce unified system register
 accessors
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-10-git-send-email-marc.zyngier@arm.com>

VHE brings its own bag of new system registers, or rather system
register accessors, as it define new ways to access both guest
and host system registers. For example, from the host:

- The host TCR_EL2 register is accessed using the TCR_EL1 accessor
- The guest TCR_EL1 register is accessed using the TCR_EL12 accessor

Obviously, this is confusing. A way to somehow reduce the complexity
of writing code for both ARMv8 and ARMv8.1 is to use a set of unified
accessors that will generate the right sysreg, depending on the mode
the CPU is running in. For example:

- read_sysreg_el1(tcr) will use TCR_EL1 on ARMv8, and TCR_EL12 on
  ARMv8.1 with VHE.
- read_sysreg_el2(tcr) will use TCR_EL2 on ARMv8, and TCR_EL1 on
  ARMv8.1 with VHE.

We end up with three sets of accessors ({read,write}_sysreg_el[012])
that can be directly used from C code. We take this opportunity to
also add the definition for the new VHE sysregs.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/hyp.h | 72 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
index fc502f3..744c919 100644
--- a/arch/arm64/kvm/hyp/hyp.h
+++ b/arch/arm64/kvm/hyp/hyp.h
@@ -48,6 +48,78 @@ static inline unsigned long __hyp_kern_va(unsigned long v)
 
 #define hyp_kern_va(v) (typeof(v))(__hyp_kern_va((unsigned long)(v)))
 
+#define read_sysreg_elx(r,nvh,vh)					\
+	({								\
+		u64 reg;						\
+		asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##nvh),\
+					 "mrs_s %0, " __stringify(r##vh),\
+					 ARM64_HAS_VIRT_HOST_EXTN)	\
+			     : "=r" (reg));				\
+		reg;							\
+	})
+
+#define write_sysreg_elx(v,r,nvh,vh)					\
+	do {								\
+		u64 __val = (u64)(v);					\
+		asm volatile(ALTERNATIVE("msr " __stringify(r##nvh) ", %x0",\
+					 "msr_s " __stringify(r##vh) ", %x0",\
+					 ARM64_HAS_VIRT_HOST_EXTN)	\
+					 : : "rZ" (__val));		\
+	} while (0)
+
+/*
+ * Unified accessors for registers that have a different encoding
+ * between VHE and non-VHE. They must be specified without their "ELx"
+ * encoding.
+ */
+#define read_sysreg_el2(r)						\
+	({								\
+		u64 reg;						\
+		asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##_EL2),\
+					 "mrs %0, " __stringify(r##_EL1),\
+					 ARM64_HAS_VIRT_HOST_EXTN)	\
+			     : "=r" (reg));				\
+		reg;							\
+	})
+
+#define write_sysreg_el2(v,r)						\
+	do {								\
+		u64 __val = (u64)(v);					\
+		asm volatile(ALTERNATIVE("msr " __stringify(r##_EL2) ", %x0",\
+					 "msr " __stringify(r##_EL1) ", %x0",\
+					 ARM64_HAS_VIRT_HOST_EXTN)	\
+					 : : "rZ" (__val));		\
+	} while (0)
+
+#define read_sysreg_el0(r)	read_sysreg_elx(r, _EL0, _EL02)
+#define write_sysreg_el0(v,r)	write_sysreg_elx(v, r, _EL0, _EL02)
+#define read_sysreg_el1(r)	read_sysreg_elx(r, _EL1, _EL12)
+#define write_sysreg_el1(v,r)	write_sysreg_elx(v, r, _EL1, _EL12)
+
+/* The VHE specific system registers and their encoding */
+#define sctlr_EL12              sys_reg(3, 5, 1, 0, 0)
+#define cpacr_EL12              sys_reg(3, 5, 1, 0, 2)
+#define ttbr0_EL12              sys_reg(3, 5, 2, 0, 0)
+#define ttbr1_EL12              sys_reg(3, 5, 2, 0, 1)
+#define tcr_EL12                sys_reg(3, 5, 2, 0, 2)
+#define afsr0_EL12              sys_reg(3, 5, 5, 1, 0)
+#define afsr1_EL12              sys_reg(3, 5, 5, 1, 1)
+#define esr_EL12                sys_reg(3, 5, 5, 2, 0)
+#define far_EL12                sys_reg(3, 5, 6, 0, 0)
+#define mair_EL12               sys_reg(3, 5, 10, 2, 0)
+#define amair_EL12              sys_reg(3, 5, 10, 3, 0)
+#define vbar_EL12               sys_reg(3, 5, 12, 0, 0)
+#define contextidr_EL12         sys_reg(3, 5, 13, 0, 1)
+#define cntkctl_EL12            sys_reg(3, 5, 14, 1, 0)
+#define cntp_tval_EL02          sys_reg(3, 5, 14, 2, 0)
+#define cntp_ctl_EL02           sys_reg(3, 5, 14, 2, 1)
+#define cntp_cval_EL02          sys_reg(3, 5, 14, 2, 2)
+#define cntv_tval_EL02          sys_reg(3, 5, 14, 3, 0)
+#define cntv_ctl_EL02           sys_reg(3, 5, 14, 3, 1)
+#define cntv_cval_EL02          sys_reg(3, 5, 14, 3, 2)
+#define spsr_EL12               sys_reg(3, 5, 4, 0, 0)
+#define elr_EL12                sys_reg(3, 5, 4, 0, 1)
+
 /**
  * hyp_alternate_select - Generates patchable code sequences that are
  * used to switch between two implementations of a function, depending
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 10:00:05 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:05 +0000
Subject: [PATCH v3 12/23] arm64: KVM: VHE: Use unified system register
 accessors
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-13-git-send-email-marc.zyngier@arm.com>

Use the recently introduced unified system register accessors for
those sysregs that behave differently depending on VHE being in
use or not.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/sysreg-sr.c | 84 +++++++++++++++++++++---------------------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
index 61bad17..7d7d757 100644
--- a/arch/arm64/kvm/hyp/sysreg-sr.c
+++ b/arch/arm64/kvm/hyp/sysreg-sr.c
@@ -37,34 +37,34 @@ static void __hyp_text __sysreg_save_common_state(struct kvm_cpu_context *ctxt)
 	ctxt->sys_regs[TPIDRRO_EL0]	= read_sysreg(tpidrro_el0);
 	ctxt->sys_regs[TPIDR_EL1]	= read_sysreg(tpidr_el1);
 	ctxt->gp_regs.regs.sp		= read_sysreg(sp_el0);
-	ctxt->gp_regs.regs.pc		= read_sysreg(elr_el2);
-	ctxt->gp_regs.regs.pstate	= read_sysreg(spsr_el2);
+	ctxt->gp_regs.regs.pc		= read_sysreg_el2(elr);
+	ctxt->gp_regs.regs.pstate	= read_sysreg_el2(spsr);
 }
 
 static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
 {
 	ctxt->sys_regs[MPIDR_EL1]	= read_sysreg(vmpidr_el2);
 	ctxt->sys_regs[CSSELR_EL1]	= read_sysreg(csselr_el1);
-	ctxt->sys_regs[SCTLR_EL1]	= read_sysreg(sctlr_el1);
-	ctxt->sys_regs[CPACR_EL1]	= read_sysreg(cpacr_el1);
-	ctxt->sys_regs[TTBR0_EL1]	= read_sysreg(ttbr0_el1);
-	ctxt->sys_regs[TTBR1_EL1]	= read_sysreg(ttbr1_el1);
-	ctxt->sys_regs[TCR_EL1]		= read_sysreg(tcr_el1);
-	ctxt->sys_regs[ESR_EL1]		= read_sysreg(esr_el1);
-	ctxt->sys_regs[AFSR0_EL1]	= read_sysreg(afsr0_el1);
-	ctxt->sys_regs[AFSR1_EL1]	= read_sysreg(afsr1_el1);
-	ctxt->sys_regs[FAR_EL1]		= read_sysreg(far_el1);
-	ctxt->sys_regs[MAIR_EL1]	= read_sysreg(mair_el1);
-	ctxt->sys_regs[VBAR_EL1]	= read_sysreg(vbar_el1);
-	ctxt->sys_regs[CONTEXTIDR_EL1]	= read_sysreg(contextidr_el1);
-	ctxt->sys_regs[AMAIR_EL1]	= read_sysreg(amair_el1);
-	ctxt->sys_regs[CNTKCTL_EL1]	= read_sysreg(cntkctl_el1);
+	ctxt->sys_regs[SCTLR_EL1]	= read_sysreg_el1(sctlr);
+	ctxt->sys_regs[CPACR_EL1]	= read_sysreg_el1(cpacr);
+	ctxt->sys_regs[TTBR0_EL1]	= read_sysreg_el1(ttbr0);
+	ctxt->sys_regs[TTBR1_EL1]	= read_sysreg_el1(ttbr1);
+	ctxt->sys_regs[TCR_EL1]		= read_sysreg_el1(tcr);
+	ctxt->sys_regs[ESR_EL1]		= read_sysreg_el1(esr);
+	ctxt->sys_regs[AFSR0_EL1]	= read_sysreg_el1(afsr0);
+	ctxt->sys_regs[AFSR1_EL1]	= read_sysreg_el1(afsr1);
+	ctxt->sys_regs[FAR_EL1]		= read_sysreg_el1(far);
+	ctxt->sys_regs[MAIR_EL1]	= read_sysreg_el1(mair);
+	ctxt->sys_regs[VBAR_EL1]	= read_sysreg_el1(vbar);
+	ctxt->sys_regs[CONTEXTIDR_EL1]	= read_sysreg_el1(contextidr);
+	ctxt->sys_regs[AMAIR_EL1]	= read_sysreg_el1(amair);
+	ctxt->sys_regs[CNTKCTL_EL1]	= read_sysreg_el1(cntkctl);
 	ctxt->sys_regs[PAR_EL1]		= read_sysreg(par_el1);
 	ctxt->sys_regs[MDSCR_EL1]	= read_sysreg(mdscr_el1);
 
 	ctxt->gp_regs.sp_el1		= read_sysreg(sp_el1);
-	ctxt->gp_regs.elr_el1		= read_sysreg(elr_el1);
-	ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg(spsr_el1);
+	ctxt->gp_regs.elr_el1		= read_sysreg_el1(elr);
+	ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg_el1(spsr);
 }
 
 void __hyp_text __sysreg_save_host_state(struct kvm_cpu_context *ctxt)
@@ -86,34 +86,34 @@ static void __hyp_text __sysreg_restore_common_state(struct kvm_cpu_context *ctx
 	write_sysreg(ctxt->sys_regs[TPIDRRO_EL0], tpidrro_el0);
 	write_sysreg(ctxt->sys_regs[TPIDR_EL1],	  tpidr_el1);
 	write_sysreg(ctxt->gp_regs.regs.sp,	  sp_el0);
-	write_sysreg(ctxt->gp_regs.regs.pc,	  elr_el2);
-	write_sysreg(ctxt->gp_regs.regs.pstate,	  spsr_el2);
+	write_sysreg_el2(ctxt->gp_regs.regs.pc,	  elr);
+	write_sysreg_el2(ctxt->gp_regs.regs.pstate, spsr);
 }
 
 static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
 {
-	write_sysreg(ctxt->sys_regs[MPIDR_EL1],	  vmpidr_el2);
-	write_sysreg(ctxt->sys_regs[CSSELR_EL1],  csselr_el1);
-	write_sysreg(ctxt->sys_regs[SCTLR_EL1],	  sctlr_el1);
-	write_sysreg(ctxt->sys_regs[CPACR_EL1],	  cpacr_el1);
-	write_sysreg(ctxt->sys_regs[TTBR0_EL1],	  ttbr0_el1);
-	write_sysreg(ctxt->sys_regs[TTBR1_EL1],	  ttbr1_el1);
-	write_sysreg(ctxt->sys_regs[TCR_EL1],	  tcr_el1);
-	write_sysreg(ctxt->sys_regs[ESR_EL1],	  esr_el1);
-	write_sysreg(ctxt->sys_regs[AFSR0_EL1],	  afsr0_el1);
-	write_sysreg(ctxt->sys_regs[AFSR1_EL1],	  afsr1_el1);
-	write_sysreg(ctxt->sys_regs[FAR_EL1],	  far_el1);
-	write_sysreg(ctxt->sys_regs[MAIR_EL1],	  mair_el1);
-	write_sysreg(ctxt->sys_regs[VBAR_EL1],	  vbar_el1);
-	write_sysreg(ctxt->sys_regs[CONTEXTIDR_EL1], contextidr_el1);
-	write_sysreg(ctxt->sys_regs[AMAIR_EL1],	  amair_el1);
-	write_sysreg(ctxt->sys_regs[CNTKCTL_EL1], cntkctl_el1);
-	write_sysreg(ctxt->sys_regs[PAR_EL1],	  par_el1);
-	write_sysreg(ctxt->sys_regs[MDSCR_EL1],	  mdscr_el1);
-
-	write_sysreg(ctxt->gp_regs.sp_el1,	sp_el1);
-	write_sysreg(ctxt->gp_regs.elr_el1,	elr_el1);
-	write_sysreg(ctxt->gp_regs.spsr[KVM_SPSR_EL1], spsr_el1);
+	write_sysreg(ctxt->sys_regs[MPIDR_EL1],		vmpidr_el2);
+	write_sysreg(ctxt->sys_regs[CSSELR_EL1],	csselr_el1);
+	write_sysreg_el1(ctxt->sys_regs[SCTLR_EL1],	sctlr);
+	write_sysreg_el1(ctxt->sys_regs[CPACR_EL1],	cpacr);
+	write_sysreg_el1(ctxt->sys_regs[TTBR0_EL1],	ttbr0);
+	write_sysreg_el1(ctxt->sys_regs[TTBR1_EL1],	ttbr1);
+	write_sysreg_el1(ctxt->sys_regs[TCR_EL1],	tcr);
+	write_sysreg_el1(ctxt->sys_regs[ESR_EL1],	esr);
+	write_sysreg_el1(ctxt->sys_regs[AFSR0_EL1],	afsr0);
+	write_sysreg_el1(ctxt->sys_regs[AFSR1_EL1],	afsr1);
+	write_sysreg_el1(ctxt->sys_regs[FAR_EL1],	far);
+	write_sysreg_el1(ctxt->sys_regs[MAIR_EL1],	mair);
+	write_sysreg_el1(ctxt->sys_regs[VBAR_EL1],	vbar);
+	write_sysreg_el1(ctxt->sys_regs[CONTEXTIDR_EL1],contextidr);
+	write_sysreg_el1(ctxt->sys_regs[AMAIR_EL1],	amair);
+	write_sysreg_el1(ctxt->sys_regs[CNTKCTL_EL1], 	cntkctl);
+	write_sysreg(ctxt->sys_regs[PAR_EL1],		par_el1);
+	write_sysreg(ctxt->sys_regs[MDSCR_EL1],		mdscr_el1);
+
+	write_sysreg(ctxt->gp_regs.sp_el1,		sp_el1);
+	write_sysreg_el1(ctxt->gp_regs.elr_el1,		elr);
+	write_sysreg_el1(ctxt->gp_regs.spsr[KVM_SPSR_EL1],spsr);
 }
 
 void __hyp_text __sysreg_restore_host_state(struct kvm_cpu_context *ctxt)
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 10:00:04 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:04 +0000
Subject: [PATCH v3 11/23] arm64: KVM: VHE: Split save/restore of registers
 shared between guest and host
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-12-git-send-email-marc.zyngier@arm.com>

A handful of system registers are still shared between host and guest,
even while using VHE (tpidr*_el[01] and actlr_el1).

Also, some of the vcpu state (sp_el0, PC and PSTATE) must be
save/restored on entry/exit, as they are used on the host as well.

In order to facilitate the introduction of a VHE-specific sysreg
save/restore, make move the access to these registers to their
own save/restore functions.

No functionnal change.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/sysreg-sr.c | 48 +++++++++++++++++++++++++++++-------------
 1 file changed, 33 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
index bd5b543..61bad17 100644
--- a/arch/arm64/kvm/hyp/sysreg-sr.c
+++ b/arch/arm64/kvm/hyp/sysreg-sr.c
@@ -23,13 +23,29 @@
 
 #include "hyp.h"
 
-/* ctxt is already in the HYP VA space */
+/*
+ * Non-VHE: Both host and guest must save everything.
+ *
+ * VHE: Host must save tpidr*_el[01], actlr_el1, sp0, pc, pstate, and
+ * guest must save everything.
+ */
+
+static void __hyp_text __sysreg_save_common_state(struct kvm_cpu_context *ctxt)
+{
+	ctxt->sys_regs[ACTLR_EL1]	= read_sysreg(actlr_el1);
+	ctxt->sys_regs[TPIDR_EL0]	= read_sysreg(tpidr_el0);
+	ctxt->sys_regs[TPIDRRO_EL0]	= read_sysreg(tpidrro_el0);
+	ctxt->sys_regs[TPIDR_EL1]	= read_sysreg(tpidr_el1);
+	ctxt->gp_regs.regs.sp		= read_sysreg(sp_el0);
+	ctxt->gp_regs.regs.pc		= read_sysreg(elr_el2);
+	ctxt->gp_regs.regs.pstate	= read_sysreg(spsr_el2);
+}
+
 static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
 {
 	ctxt->sys_regs[MPIDR_EL1]	= read_sysreg(vmpidr_el2);
 	ctxt->sys_regs[CSSELR_EL1]	= read_sysreg(csselr_el1);
 	ctxt->sys_regs[SCTLR_EL1]	= read_sysreg(sctlr_el1);
-	ctxt->sys_regs[ACTLR_EL1]	= read_sysreg(actlr_el1);
 	ctxt->sys_regs[CPACR_EL1]	= read_sysreg(cpacr_el1);
 	ctxt->sys_regs[TTBR0_EL1]	= read_sysreg(ttbr0_el1);
 	ctxt->sys_regs[TTBR1_EL1]	= read_sysreg(ttbr1_el1);
@@ -41,17 +57,11 @@ static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
 	ctxt->sys_regs[MAIR_EL1]	= read_sysreg(mair_el1);
 	ctxt->sys_regs[VBAR_EL1]	= read_sysreg(vbar_el1);
 	ctxt->sys_regs[CONTEXTIDR_EL1]	= read_sysreg(contextidr_el1);
-	ctxt->sys_regs[TPIDR_EL0]	= read_sysreg(tpidr_el0);
-	ctxt->sys_regs[TPIDRRO_EL0]	= read_sysreg(tpidrro_el0);
-	ctxt->sys_regs[TPIDR_EL1]	= read_sysreg(tpidr_el1);
 	ctxt->sys_regs[AMAIR_EL1]	= read_sysreg(amair_el1);
 	ctxt->sys_regs[CNTKCTL_EL1]	= read_sysreg(cntkctl_el1);
 	ctxt->sys_regs[PAR_EL1]		= read_sysreg(par_el1);
 	ctxt->sys_regs[MDSCR_EL1]	= read_sysreg(mdscr_el1);
 
-	ctxt->gp_regs.regs.sp		= read_sysreg(sp_el0);
-	ctxt->gp_regs.regs.pc		= read_sysreg(elr_el2);
-	ctxt->gp_regs.regs.pstate	= read_sysreg(spsr_el2);
 	ctxt->gp_regs.sp_el1		= read_sysreg(sp_el1);
 	ctxt->gp_regs.elr_el1		= read_sysreg(elr_el1);
 	ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg(spsr_el1);
@@ -60,11 +70,24 @@ static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
 void __hyp_text __sysreg_save_host_state(struct kvm_cpu_context *ctxt)
 {
 	__sysreg_save_state(ctxt);
+	__sysreg_save_common_state(ctxt);
 }
 
 void __hyp_text __sysreg_save_guest_state(struct kvm_cpu_context *ctxt)
 {
 	__sysreg_save_state(ctxt);
+	__sysreg_save_common_state(ctxt);
+}
+
+static void __hyp_text __sysreg_restore_common_state(struct kvm_cpu_context *ctxt)
+{
+	write_sysreg(ctxt->sys_regs[ACTLR_EL1],	  actlr_el1);
+	write_sysreg(ctxt->sys_regs[TPIDR_EL0],	  tpidr_el0);
+	write_sysreg(ctxt->sys_regs[TPIDRRO_EL0], tpidrro_el0);
+	write_sysreg(ctxt->sys_regs[TPIDR_EL1],	  tpidr_el1);
+	write_sysreg(ctxt->gp_regs.regs.sp,	  sp_el0);
+	write_sysreg(ctxt->gp_regs.regs.pc,	  elr_el2);
+	write_sysreg(ctxt->gp_regs.regs.pstate,	  spsr_el2);
 }
 
 static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
@@ -72,7 +95,6 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
 	write_sysreg(ctxt->sys_regs[MPIDR_EL1],	  vmpidr_el2);
 	write_sysreg(ctxt->sys_regs[CSSELR_EL1],  csselr_el1);
 	write_sysreg(ctxt->sys_regs[SCTLR_EL1],	  sctlr_el1);
-	write_sysreg(ctxt->sys_regs[ACTLR_EL1],	  actlr_el1);
 	write_sysreg(ctxt->sys_regs[CPACR_EL1],	  cpacr_el1);
 	write_sysreg(ctxt->sys_regs[TTBR0_EL1],	  ttbr0_el1);
 	write_sysreg(ctxt->sys_regs[TTBR1_EL1],	  ttbr1_el1);
@@ -84,17 +106,11 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
 	write_sysreg(ctxt->sys_regs[MAIR_EL1],	  mair_el1);
 	write_sysreg(ctxt->sys_regs[VBAR_EL1],	  vbar_el1);
 	write_sysreg(ctxt->sys_regs[CONTEXTIDR_EL1], contextidr_el1);
-	write_sysreg(ctxt->sys_regs[TPIDR_EL0],	  tpidr_el0);
-	write_sysreg(ctxt->sys_regs[TPIDRRO_EL0], tpidrro_el0);
-	write_sysreg(ctxt->sys_regs[TPIDR_EL1],	  tpidr_el1);
 	write_sysreg(ctxt->sys_regs[AMAIR_EL1],	  amair_el1);
 	write_sysreg(ctxt->sys_regs[CNTKCTL_EL1], cntkctl_el1);
 	write_sysreg(ctxt->sys_regs[PAR_EL1],	  par_el1);
 	write_sysreg(ctxt->sys_regs[MDSCR_EL1],	  mdscr_el1);
 
-	write_sysreg(ctxt->gp_regs.regs.sp,	sp_el0);
-	write_sysreg(ctxt->gp_regs.regs.pc,	elr_el2);
-	write_sysreg(ctxt->gp_regs.regs.pstate,	spsr_el2);
 	write_sysreg(ctxt->gp_regs.sp_el1,	sp_el1);
 	write_sysreg(ctxt->gp_regs.elr_el1,	elr_el1);
 	write_sysreg(ctxt->gp_regs.spsr[KVM_SPSR_EL1], spsr_el1);
@@ -103,11 +119,13 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
 void __hyp_text __sysreg_restore_host_state(struct kvm_cpu_context *ctxt)
 {
 	__sysreg_restore_state(ctxt);
+	__sysreg_restore_common_state(ctxt);
 }
 
 void __hyp_text __sysreg_restore_guest_state(struct kvm_cpu_context *ctxt)
 {
 	__sysreg_restore_state(ctxt);
+	__sysreg_restore_common_state(ctxt);
 }
 
 void __hyp_text __sysreg32_save_state(struct kvm_vcpu *vcpu)
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 10:00:10 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:10 +0000
Subject: [PATCH v3 17/23] arm64: KVM: VHE: Add fpsimd enabling on guest access
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-18-git-send-email-marc.zyngier@arm.com>

Despite the fact that a VHE enabled kernel runs at EL2, it uses
CPACR_EL1 to trap FPSIMD access. Add the required alternative
code to re-enable guest FPSIMD access when it has trapped to
EL2.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/entry.S | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
index fd0fbe9..ce9e5e5 100644
--- a/arch/arm64/kvm/hyp/entry.S
+++ b/arch/arm64/kvm/hyp/entry.S
@@ -130,9 +130,15 @@ ENDPROC(__guest_exit)
 ENTRY(__fpsimd_guest_restore)
 	stp	x4, lr, [sp, #-16]!
 
+alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
 	mrs	x2, cptr_el2
 	bic	x2, x2, #CPTR_EL2_TFP
 	msr	cptr_el2, x2
+alternative_else
+	mrs	x2, cpacr_el1
+	orr	x2, x2, #CPACR_EL1_FPEN
+	msr	cpacr_el1, x2
+alternative_endif
 	isb
 
 	mrs	x3, tpidr_el2
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 10:00:16 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:16 +0000
Subject: [PATCH v3 23/23] arm64: Panic when VHE and non VHE CPUs coexist
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-24-git-send-email-marc.zyngier@arm.com>

Having both VHE and non-VHE capable CPUs in the same system
is likely to be a recipe for disaster.

If the boot CPU has VHE, but a secondary is not, we won't be
able to downgrade and run the kernel at EL1. Add CPU hotplug
to the mix, and this produces a terrifying mess.

Let's solve the problem once and for all. If you mix VHE and
non-VHE CPUs in the same system, you deserve to loose, and this
patch makes sure you don't get a chance.

This is implemented by storing the kernel execution level in
a global variable. Secondaries will park themselves in a
WFI loop if they observe a mismatch. Also, the primary CPU
will detect that the secondary CPU has died on a mismatched
execution level. Panic will follow.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/virt.h | 17 +++++++++++++++++
 arch/arm64/kernel/head.S      | 20 ++++++++++++++++++++
 arch/arm64/kernel/smp.c       |  3 +++
 3 files changed, 40 insertions(+)

diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 9f22dd6..f81a345 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -36,6 +36,11 @@
  */
 extern u32 __boot_cpu_mode[2];
 
+/*
+ * __run_cpu_mode records the mode the boot CPU uses for the kernel.
+ */
+extern u32 __run_cpu_mode[2];
+
 void __hyp_set_vectors(phys_addr_t phys_vector_base);
 phys_addr_t __hyp_get_vectors(void);
 
@@ -60,6 +65,18 @@ static inline bool is_kernel_in_hyp_mode(void)
 	return el == CurrentEL_EL2;
 }
 
+static inline bool is_kernel_mode_mismatched(void)
+{
+	/*
+	 * A mismatched CPU will have written its own CurrentEL in
+	 * __run_cpu_mode[1] (initially set to zero) after failing to
+	 * match the value in __run_cpu_mode[0]. Thus, a non-zero
+	 * value in __run_cpu_mode[1] is enough to detect the
+	 * pathological case.
+	 */
+	return !!ACCESS_ONCE(__run_cpu_mode[1]);
+}
+
 /* The section containing the hypervisor text */
 extern char __hyp_text_start[];
 extern char __hyp_text_end[];
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 6f2f377..f9b6a5b 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -578,7 +578,24 @@ ENTRY(set_cpu_boot_mode_flag)
 1:	str	w20, [x1]			// This CPU has booted in EL1
 	dmb	sy
 	dc	ivac, x1			// Invalidate potentially stale cache line
+	adr_l	x1, __run_cpu_mode
+	ldr	w0, [x1]
+	mrs	x20, CurrentEL
+	cbz	x0, skip_el_check
+	cmp	x0, x20
+	bne	mismatched_el
 	ret
+skip_el_check:			// Only the first CPU gets to set the rule
+	str	w20, [x1]
+	dmb	sy
+	dc	ivac, x1	// Invalidate potentially stale cache line
+	ret
+mismatched_el:
+	str	w20, [x1, #4]
+	dmb	sy
+	dc	ivac, x1	// Invalidate potentially stale cache line
+1:	wfi
+	b	1b
 ENDPROC(set_cpu_boot_mode_flag)
 
 /*
@@ -593,6 +610,9 @@ ENDPROC(set_cpu_boot_mode_flag)
 ENTRY(__boot_cpu_mode)
 	.long	BOOT_CPU_MODE_EL2
 	.long	BOOT_CPU_MODE_EL1
+ENTRY(__run_cpu_mode)
+	.long	0
+	.long	0
 	.popsection
 
 	/*
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index b1adc51..bc7650a 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -113,6 +113,9 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
 			pr_crit("CPU%u: failed to come online\n", cpu);
 			ret = -EIO;
 		}
+
+		if (is_kernel_mode_mismatched())
+			panic("CPU%u: incompatible execution level", cpu);
 	} else {
 		pr_err("CPU%u: failed to boot: %d\n", cpu, ret);
 	}
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 10:00:09 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:09 +0000
Subject: [PATCH v3 16/23] arm64: KVM: VHE: Use unified sysreg accessors for
 timer
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-17-git-send-email-marc.zyngier@arm.com>

Switch the timer code to the unified sysreg accessors.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/timer-sr.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kvm/hyp/timer-sr.c b/arch/arm64/kvm/hyp/timer-sr.c
index 1051e5d..f276d9e 100644
--- a/arch/arm64/kvm/hyp/timer-sr.c
+++ b/arch/arm64/kvm/hyp/timer-sr.c
@@ -31,12 +31,12 @@ void __hyp_text __timer_save_state(struct kvm_vcpu *vcpu)
 	u64 val;
 
 	if (kvm->arch.timer.enabled) {
-		timer->cntv_ctl = read_sysreg(cntv_ctl_el0);
-		timer->cntv_cval = read_sysreg(cntv_cval_el0);
+		timer->cntv_ctl = read_sysreg_el0(cntv_ctl);
+		timer->cntv_cval = read_sysreg_el0(cntv_cval);
 	}
 
 	/* Disable the virtual timer */
-	write_sysreg(0, cntv_ctl_el0);
+	write_sysreg_el0(0, cntv_ctl);
 
 	/* Allow physical timer/counter access for the host */
 	val = read_sysreg(cnthctl_el2);
@@ -64,8 +64,8 @@ void __hyp_text __timer_restore_state(struct kvm_vcpu *vcpu)
 
 	if (kvm->arch.timer.enabled) {
 		write_sysreg(kvm->arch.timer.cntvoff, cntvoff_el2);
-		write_sysreg(timer->cntv_cval, cntv_cval_el0);
+		write_sysreg_el0(timer->cntv_cval, cntv_cval);
 		isb();
-		write_sysreg(timer->cntv_ctl, cntv_ctl_el0);
+		write_sysreg_el0(timer->cntv_ctl, cntv_ctl);
 	}
 }
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 10:00:11 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:11 +0000
Subject: [PATCH v3 18/23] arm64: KVM: VHE: Add alternative panic handling
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-19-git-send-email-marc.zyngier@arm.com>

As the kernel fully runs in HYP when VHE is enabled, we can
directly branch to the kernel's panic() implementation, and
not perform an exception return.

Add the alternative code to deal with this.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/switch.c | 35 +++++++++++++++++++++++++++--------
 1 file changed, 27 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 686ca35..e90683a 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -206,11 +206,34 @@ __alias(__guest_run) int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
 
 static const char __hyp_panic_string[] = "HYP panic:\nPS:%08llx PC:%016llx ESR:%08llx\nFAR:%016llx HPFAR:%016llx PAR:%016llx\nVCPU:%p\n";
 
-void __hyp_text __noreturn __hyp_panic(void)
+static void __hyp_text __hyp_call_panic_nvhe(u64 spsr, u64 elr, u64 par)
 {
 	unsigned long str_va = (unsigned long)__hyp_panic_string;
-	u64 spsr = read_sysreg(spsr_el2);
-	u64 elr = read_sysreg(elr_el2);
+
+	__hyp_do_panic(hyp_kern_va(str_va),
+		       spsr,  elr,
+		       read_sysreg(esr_el2),   read_sysreg_el2(far),
+		       read_sysreg(hpfar_el2), par,
+		       (void *)read_sysreg(tpidr_el2));
+}
+
+static void __hyp_text __hyp_call_panic_vhe(u64 spsr, u64 elr, u64 par)
+{
+	panic(__hyp_panic_string,
+	      spsr,  elr,
+	      read_sysreg_el2(esr),   read_sysreg_el2(far),
+	      read_sysreg(hpfar_el2), par,
+	      (void *)read_sysreg(tpidr_el2));
+}
+
+static hyp_alternate_select(__hyp_call_panic,
+			    __hyp_call_panic_nvhe, __hyp_call_panic_vhe,
+			    ARM64_HAS_VIRT_HOST_EXTN);
+
+void __hyp_text __noreturn __hyp_panic(void)
+{
+	u64 spsr = read_sysreg_el2(spsr);
+	u64 elr = read_sysreg_el2(elr);
 	u64 par = read_sysreg(par_el1);
 
 	if (read_sysreg(vttbr_el2)) {
@@ -225,11 +248,7 @@ void __hyp_text __noreturn __hyp_panic(void)
 	}
 
 	/* Call panic for real */
-	__hyp_do_panic(hyp_kern_va(str_va),
-		       spsr,  elr,
-		       read_sysreg(esr_el2),   read_sysreg(far_el2),
-		       read_sysreg(hpfar_el2), par,
-		       (void *)read_sysreg(tpidr_el2));
+	__hyp_call_panic()(spsr, elr, par);
 
 	unreachable();
 }
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 10:00:12 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:12 +0000
Subject: [PATCH v3 19/23] arm64: KVM: Move most of the fault decoding to C
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-20-git-send-email-marc.zyngier@arm.com>

The fault decoding process (including computing the IPA in the case
of a permission fault) would be much better done in C code, as we
have a reasonable infrastructure to deal with the VHE/non-VHE
differences.

Let's move the whole thing to C, including the workaround for
erratum 834220, and just patch the odd ESR_EL2 access remaining
in hyp-entry.S.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kernel/asm-offsets.c |  3 --
 arch/arm64/kvm/hyp/hyp-entry.S  | 69 +++------------------------------
 arch/arm64/kvm/hyp/switch.c     | 85 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 90 insertions(+), 67 deletions(-)

diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index fffa4ac6..b0ab4e9 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -110,9 +110,6 @@ int main(void)
   DEFINE(CPU_USER_PT_REGS,	offsetof(struct kvm_regs, regs));
   DEFINE(CPU_FP_REGS,		offsetof(struct kvm_regs, fp_regs));
   DEFINE(VCPU_FPEXC32_EL2,	offsetof(struct kvm_vcpu, arch.ctxt.sys_regs[FPEXC32_EL2]));
-  DEFINE(VCPU_ESR_EL2,		offsetof(struct kvm_vcpu, arch.fault.esr_el2));
-  DEFINE(VCPU_FAR_EL2,		offsetof(struct kvm_vcpu, arch.fault.far_el2));
-  DEFINE(VCPU_HPFAR_EL2,	offsetof(struct kvm_vcpu, arch.fault.hpfar_el2));
   DEFINE(VCPU_HOST_CONTEXT,	offsetof(struct kvm_vcpu, arch.host_cpu_context));
 #endif
 #ifdef CONFIG_CPU_PM
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
index 1bdeee7..3488894 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -19,7 +19,6 @@
 
 #include <asm/alternative.h>
 #include <asm/assembler.h>
-#include <asm/asm-offsets.h>
 #include <asm/cpufeature.h>
 #include <asm/kvm_arm.h>
 #include <asm/kvm_asm.h>
@@ -69,7 +68,11 @@ ENDPROC(__vhe_hyp_call)
 el1_sync:				// Guest trapped into EL2
 	save_x0_to_x3
 
+alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
 	mrs	x1, esr_el2
+alternative_else
+	mrs	x1, esr_el1
+alternative_endif
 	lsr	x2, x1, #ESR_ELx_EC_SHIFT
 
 	cmp	x2, #ESR_ELx_EC_HVC64
@@ -105,72 +108,10 @@ el1_trap:
 	cmp	x2, #ESR_ELx_EC_FP_ASIMD
 	b.eq	__fpsimd_guest_restore
 
-	cmp	x2, #ESR_ELx_EC_DABT_LOW
-	mov	x0, #ESR_ELx_EC_IABT_LOW
-	ccmp	x2, x0, #4, ne
-	b.ne	1f		// Not an abort we care about
-
-	/* This is an abort. Check for permission fault */
-alternative_if_not ARM64_WORKAROUND_834220
-	and	x2, x1, #ESR_ELx_FSC_TYPE
-	cmp	x2, #FSC_PERM
-	b.ne	1f		// Not a permission fault
-alternative_else
-	nop			// Use the permission fault path to
-	nop			// check for a valid S1 translation,
-	nop			// regardless of the ESR value.
-alternative_endif
-
-	/*
-	 * Check for Stage-1 page table walk, which is guaranteed
-	 * to give a valid HPFAR_EL2.
-	 */
-	tbnz	x1, #7, 1f	// S1PTW is set
-
-	/* Preserve PAR_EL1 */
-	mrs	x3, par_el1
-	stp	x3, xzr, [sp, #-16]!
-
-	/*
-	 * Permission fault, HPFAR_EL2 is invalid.
-	 * Resolve the IPA the hard way using the guest VA.
-	 * Stage-1 translation already validated the memory access rights.
-	 * As such, we can use the EL1 translation regime, and don't have
-	 * to distinguish between EL0 and EL1 access.
-	 */
-	mrs	x2, far_el2
-	at	s1e1r, x2
-	isb
-
-	/* Read result */
-	mrs	x3, par_el1
-	ldp	x0, xzr, [sp], #16	// Restore PAR_EL1 from the stack
-	msr	par_el1, x0
-	tbnz	x3, #0, 3f		// Bail out if we failed the translation
-	ubfx	x3, x3, #12, #36	// Extract IPA
-	lsl	x3, x3, #4		// and present it like HPFAR
-	b	2f
-
-1:	mrs	x3, hpfar_el2
-	mrs	x2, far_el2
-
-2:	mrs	x0, tpidr_el2
-	str	w1, [x0, #VCPU_ESR_EL2]
-	str	x2, [x0, #VCPU_FAR_EL2]
-	str	x3, [x0, #VCPU_HPFAR_EL2]
-
+	mrs	x0, tpidr_el2
 	mov	x1, #ARM_EXCEPTION_TRAP
 	b	__guest_exit
 
-	/*
-	 * Translation failed. Just return to the guest and
-	 * let it fault again. Another CPU is probably playing
-	 * behind our back.
-	 */
-3:	restore_x0_to_x3
-
-	eret
-
 el1_irq:
 	save_x0_to_x3
 	mrs	x0, tpidr_el2
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index e90683a..a192357 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -15,6 +15,7 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/types.h>
 #include <asm/kvm_asm.h>
 
 #include "hyp.h"
@@ -145,6 +146,86 @@ static void __hyp_text __vgic_restore_state(struct kvm_vcpu *vcpu)
 	__vgic_call_restore_state()(vcpu);
 }
 
+static bool __hyp_text __true_value(void)
+{
+	return true;
+}
+
+static bool __hyp_text __false_value(void)
+{
+	return false;
+}
+
+static hyp_alternate_select(__check_arm_834220,
+			    __false_value, __true_value,
+			    ARM64_WORKAROUND_834220);
+
+static bool __hyp_text __translate_far_to_hpfar(u64 far, u64 *hpfar)
+{
+	u64 par, tmp;
+
+	/*
+	 * Resolve the IPA the hard way using the guest VA.
+	 *
+	 * Stage-1 translation already validated the memory access
+	 * rights. As such, we can use the EL1 translation regime, and
+	 * don't have to distinguish between EL0 and EL1 access.
+	 *
+	 * We do need to save/restore PAR_EL1 though, as we haven't
+	 * saved the guest context yet, and we may return early...
+	 */
+	par = read_sysreg(par_el1);
+	asm volatile("at s1e1r, %0" : : "r" (far));
+	isb();
+
+	tmp = read_sysreg(par_el1);
+	write_sysreg(par, par_el1);
+
+	if (unlikely(tmp & 1))
+		return false; /* Translation failed, back to guest */
+
+	/* Convert PAR to HPFAR format */
+	*hpfar = ((tmp >> 12) & ((1UL << 36) - 1)) << 4;
+	return true;
+}
+
+static bool __hyp_text __populate_fault_info(struct kvm_vcpu *vcpu)
+{
+	u64 esr = read_sysreg_el2(esr);
+	u8 ec = esr >> ESR_ELx_EC_SHIFT;
+	u64 hpfar, far;
+
+	vcpu->arch.fault.esr_el2 = esr;
+
+	if (ec != ESR_ELx_EC_DABT_LOW && ec != ESR_ELx_EC_IABT_LOW)
+		return true;
+
+	far = read_sysreg_el2(far);
+
+	/*
+	 * The HPFAR can be invalid if the stage 2 fault did not
+	 * happen during a stage 1 page table walk (the ESR_EL2.S1PTW
+	 * bit is clear) and one of the two following cases are true:
+	 *   1. The fault was due to a permission fault
+	 *   2. The processor carries errata 834220
+	 *
+	 * Therefore, for all non S1PTW faults where we either have a
+	 * permission fault or the errata workaround is enabled, we
+	 * resolve the IPA using the AT instruction.
+	 */
+	if (!(esr & ESR_ELx_S1PTW) &&
+	    (__check_arm_834220()() || (esr & ESR_ELx_FSC_TYPE) == FSC_PERM)) {
+		if (!__translate_far_to_hpfar(far, &hpfar))
+			return false;
+	} else {
+		hpfar = read_sysreg(hpfar_el2);
+	}
+
+	vcpu->arch.fault.far_el2 = far;
+	vcpu->arch.fault.hpfar_el2 = hpfar;
+	return true;
+}
+
 static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
 {
 	struct kvm_cpu_context *host_ctxt;
@@ -176,9 +257,13 @@ static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
 	__debug_restore_state(vcpu, kern_hyp_va(vcpu->arch.debug_ptr), guest_ctxt);
 
 	/* Jump in the fire! */
+again:
 	exit_code = __guest_enter(vcpu, host_ctxt);
 	/* And we're baaack! */
 
+	if (exit_code == ARM_EXCEPTION_TRAP && !__populate_fault_info(vcpu))
+		goto again;
+
 	fp_enabled = __fpsimd_enabled();
 
 	__sysreg_save_guest_state(guest_ctxt);
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 10:00:13 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:13 +0000
Subject: [PATCH v3 20/23] arm64: perf: Count EL2 events if the kernel is
 running in HYP
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-21-git-send-email-marc.zyngier@arm.com>

When the kernel is running in HYP (with VHE), it is necessary to
include EL2 events if the user requests counting kernel or
hypervisor events.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kernel/perf_event.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index f7ab14c..6013a38 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -20,6 +20,7 @@
  */
 
 #include <asm/irq_regs.h>
+#include <asm/virt.h>
 
 #include <linux/of.h>
 #include <linux/perf/arm_pmu.h>
@@ -693,10 +694,15 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
 		return -EPERM;
 	if (attr->exclude_user)
 		config_base |= ARMV8_EXCLUDE_EL0;
-	if (attr->exclude_kernel)
-		config_base |= ARMV8_EXCLUDE_EL1;
-	if (!attr->exclude_hv)
-		config_base |= ARMV8_INCLUDE_EL2;
+	if (is_kernel_in_hyp_mode()) {
+		if (!attr->exclude_kernel || !attr->exclude_hv)
+			config_base |= ARMV8_INCLUDE_EL2;
+	} else {
+		if (attr->exclude_kernel)
+			config_base |= ARMV8_EXCLUDE_EL1;
+		if (!attr->exclude_hv)
+			config_base |= ARMV8_INCLUDE_EL2;
+	}
 
 	/*
 	 * Install the filter into config_base as this is used to
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 10:00:00 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:00 +0000
Subject: [PATCH v3 07/23] arm64: KVM: VHE: Patch out use of HVC
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-8-git-send-email-marc.zyngier@arm.com>

With VHE, the host never issues an HVC instruction to get into the
KVM code, as we can simply branch there.

Use runtime code patching to simplify things a bit.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp.S           |  7 +++++++
 arch/arm64/kvm/hyp/hyp-entry.S | 40 +++++++++++++++++++++++++++++++---------
 2 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index 0ccdcbb..0689a74 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -17,7 +17,9 @@
 
 #include <linux/linkage.h>
 
+#include <asm/alternative.h>
 #include <asm/assembler.h>
+#include <asm/cpufeature.h>
 
 /*
  * u64 kvm_call_hyp(void *hypfn, ...);
@@ -38,6 +40,11 @@
  * arch/arm64/kernel/hyp_stub.S.
  */
 ENTRY(kvm_call_hyp)
+alternative_if_not ARM64_HAS_VIRT_HOST_EXTN	
 	hvc	#0
 	ret
+alternative_else
+	b	__vhe_hyp_call
+	nop
+alternative_endif
 ENDPROC(kvm_call_hyp)
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
index 93e8d983..1bdeee7 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -38,6 +38,34 @@
 	ldp	x0, x1, [sp], #16
 .endm
 
+.macro do_el2_call
+	/*
+	 * Shuffle the parameters before calling the function
+	 * pointed to in x0. Assumes parameters in x[1,2,3].
+	 */
+	sub	sp, sp, #16
+	str	lr, [sp]
+	mov	lr, x0
+	mov	x0, x1
+	mov	x1, x2
+	mov	x2, x3
+	blr	lr
+	ldr	lr, [sp]
+	add	sp, sp, #16
+.endm
+
+ENTRY(__vhe_hyp_call)
+	do_el2_call
+	/*
+	 * We used to rely on having an exception return to get
+	 * an implicit isb. In the E2H case, we don't have it anymore.
+	 * rather than changing all the leaf functions, just do it here
+	 * before returning to the rest of the kernel.
+	 */
+	isb
+	ret
+ENDPROC(__vhe_hyp_call)
+	
 el1_sync:				// Guest trapped into EL2
 	save_x0_to_x3
 
@@ -58,19 +86,13 @@ el1_sync:				// Guest trapped into EL2
 	mrs	x0, vbar_el2
 	b	2f
 
-1:	stp	lr, xzr, [sp, #-16]!
-
+1:
 	/*
-	 * Compute the function address in EL2, and shuffle the parameters.
+	 * Perform the EL2 call
 	 */
 	kern_hyp_va	x0
-	mov	lr, x0
-	mov	x0, x1
-	mov	x1, x2
-	mov	x2, x3
-	blr	lr
+	do_el2_call
 
-	ldp	lr, xzr, [sp], #16
 2:	eret
 
 el1_trap:
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 10:00:01 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:01 +0000
Subject: [PATCH v3 08/23] arm64: KVM: VHE: Patch out kern_hyp_va
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-9-git-send-email-marc.zyngier@arm.com>

The kern_hyp_va macro is pretty meaninless with VHE, as there is
only one mapping - the kernel one.

In order to keep the code readable and efficient, use runtime
patching to replace the 'and' instruction used to compute the VA
with a 'nop'.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_mmu.h | 12 +++++++++++-
 arch/arm64/kvm/hyp/hyp.h         | 25 ++++++++++++++++++++++---
 2 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 7364339..9a9318a 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -23,13 +23,16 @@
 #include <asm/cpufeature.h>
 
 /*
- * As we only have the TTBR0_EL2 register, we cannot express
+ * As ARMv8.0 only has the TTBR0_EL2 register, we cannot express
  * "negative" addresses. This makes it impossible to directly share
  * mappings with the kernel.
  *
  * Instead, give the HYP mode its own VA region at a fixed offset from
  * the kernel by just masking the top bits (which are all ones for a
  * kernel address).
+ *
+ * ARMv8.1 (using VHE) does have a TTBR1_EL2, and doesn't use these
+ * macros (the entire kernel runs at EL2).
  */
 #define HYP_PAGE_OFFSET_SHIFT	VA_BITS
 #define HYP_PAGE_OFFSET_MASK	((UL(1) << HYP_PAGE_OFFSET_SHIFT) - 1)
@@ -56,12 +59,19 @@
 
 #ifdef __ASSEMBLY__
 
+#include <asm/alternative.h>
+#include <asm/cpufeature.h>
+
 /*
  * Convert a kernel VA into a HYP VA.
  * reg: VA to be converted.
  */
 .macro kern_hyp_va	reg
+alternative_if_not ARM64_HAS_VIRT_HOST_EXTN	
 	and	\reg, \reg, #HYP_PAGE_OFFSET_MASK
+alternative_else
+	nop
+alternative_endif
 .endm
 
 #else
diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
index fb27517..fc502f3 100644
--- a/arch/arm64/kvm/hyp/hyp.h
+++ b/arch/arm64/kvm/hyp/hyp.h
@@ -25,9 +25,28 @@
 
 #define __hyp_text __section(.hyp.text) notrace
 
-#define kern_hyp_va(v) (typeof(v))((unsigned long)(v) & HYP_PAGE_OFFSET_MASK)
-#define hyp_kern_va(v) (typeof(v))((unsigned long)(v) - HYP_PAGE_OFFSET \
-						      + PAGE_OFFSET)
+static inline unsigned long __kern_hyp_va(unsigned long v)
+{
+	asm volatile(ALTERNATIVE("and %0, %0, %1",
+				 "nop",
+				 ARM64_HAS_VIRT_HOST_EXTN)
+		     : "+r" (v) : "i" (HYP_PAGE_OFFSET_MASK));
+	return v;
+}
+
+#define kern_hyp_va(v) (typeof(v))(__kern_hyp_va((unsigned long)(v)))
+
+static inline unsigned long __hyp_kern_va(unsigned long v)
+{
+	u64 offset = PAGE_OFFSET - HYP_PAGE_OFFSET;
+	asm volatile(ALTERNATIVE("add %0, %0, %1",
+				 "nop",
+				 ARM64_HAS_VIRT_HOST_EXTN)
+		     : "+r" (v) : "r" (offset));
+	return v;
+}
+
+#define hyp_kern_va(v) (typeof(v))(__hyp_kern_va((unsigned long)(v)))
 
 /**
  * hyp_alternate_select - Generates patchable code sequences that are
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 09:59:59 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 17:59:59 +0000
Subject: [PATCH v3 06/23] arm64: KVM: Skip HYP setup when already running in
 HYP
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-7-git-send-email-marc.zyngier@arm.com>

With the kernel running at EL2, there is no point trying to
configure page tables for HYP, as the kernel is already mapped.

Take this opportunity to refactor the whole init a bit, allowing
the various parts of the hypervisor bringup to be split across
multiple functions.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/arm.c | 173 +++++++++++++++++++++++++++++++++++------------------
 arch/arm/kvm/mmu.c |   7 +++
 2 files changed, 121 insertions(+), 59 deletions(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 6b76e01..58f89e3 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -967,6 +967,11 @@ long kvm_arch_vm_ioctl(struct file *filp,
 	}
 }
 
+static void cpu_init_stage2(void *dummy)
+{
+	__cpu_init_stage2();
+}
+
 static void cpu_init_hyp_mode(void *dummy)
 {
 	phys_addr_t boot_pgd_ptr;
@@ -1036,6 +1041,82 @@ static inline void hyp_cpu_pm_init(void)
 }
 #endif
 
+static void teardown_common_resources(void)
+{
+	free_percpu(kvm_host_cpu_state);
+}
+
+static int init_common_resources(void)
+{
+	kvm_host_cpu_state = alloc_percpu(kvm_cpu_context_t);
+	if (!kvm_host_cpu_state) {
+		kvm_err("Cannot allocate host CPU state\n");
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+static int init_subsystems(void)
+{
+	int err;
+
+	/*
+	 * Init HYP view of VGIC
+	 */
+	err = kvm_vgic_hyp_init();
+	switch (err) {
+	case 0:
+		vgic_present = true;
+		break;
+	case -ENODEV:
+	case -ENXIO:
+		vgic_present = false;
+		break;
+	default:
+		return err;
+	}
+
+	/*
+	 * Init HYP architected timer support
+	 */
+	err = kvm_timer_hyp_init();
+	if (err)
+		return err;
+
+	kvm_perf_init();
+	kvm_coproc_table_init();
+
+	return 0;
+}
+
+static void teardown_hyp_mode(void)
+{
+	int cpu;
+
+	if (is_kernel_in_hyp_mode())
+		return;
+
+	free_hyp_pgds();
+	for_each_possible_cpu(cpu)
+		free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
+}
+
+static int init_vhe_mode(void)
+{
+	/*
+	 * Execute the init code on each CPU.
+	 */
+	on_each_cpu(cpu_init_stage2, NULL, 1);
+
+	/* set size of VMID supported by CPU */
+	kvm_vmid_bits = kvm_get_vmid_bits();
+	kvm_info("%d-bit VMID\n", kvm_vmid_bits);
+
+	kvm_info("VHE mode initialized successfully\n");
+	return 0;
+}
+
 /**
  * Inits Hyp-mode on all online CPUs
  */
@@ -1066,7 +1147,7 @@ static int init_hyp_mode(void)
 		stack_page = __get_free_page(GFP_KERNEL);
 		if (!stack_page) {
 			err = -ENOMEM;
-			goto out_free_stack_pages;
+			goto out_err;
 		}
 
 		per_cpu(kvm_arm_hyp_stack_page, cpu) = stack_page;
@@ -1078,13 +1159,13 @@ static int init_hyp_mode(void)
 	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
 	if (err) {
 		kvm_err("Cannot map world-switch code\n");
-		goto out_free_mappings;
+		goto out_err;
 	}
 
 	err = create_hyp_mappings(__start_rodata, __end_rodata);
 	if (err) {
 		kvm_err("Cannot map rodata section\n");
-		goto out_free_mappings;
+		goto out_err;
 	}
 
 	/*
@@ -1096,20 +1177,10 @@ static int init_hyp_mode(void)
 
 		if (err) {
 			kvm_err("Cannot map hyp stack\n");
-			goto out_free_mappings;
+			goto out_err;
 		}
 	}
 
-	/*
-	 * Map the host CPU structures
-	 */
-	kvm_host_cpu_state = alloc_percpu(kvm_cpu_context_t);
-	if (!kvm_host_cpu_state) {
-		err = -ENOMEM;
-		kvm_err("Cannot allocate host CPU state\n");
-		goto out_free_mappings;
-	}
-
 	for_each_possible_cpu(cpu) {
 		kvm_cpu_context_t *cpu_ctxt;
 
@@ -1118,7 +1189,7 @@ static int init_hyp_mode(void)
 
 		if (err) {
 			kvm_err("Cannot map host CPU state: %d\n", err);
-			goto out_free_context;
+			goto out_err;
 		}
 	}
 
@@ -1127,34 +1198,22 @@ static int init_hyp_mode(void)
 	 */
 	on_each_cpu(cpu_init_hyp_mode, NULL, 1);
 
-	/*
-	 * Init HYP view of VGIC
-	 */
-	err = kvm_vgic_hyp_init();
-	switch (err) {
-	case 0:
-		vgic_present = true;
-		break;
-	case -ENODEV:
-	case -ENXIO:
-		vgic_present = false;
-		break;
-	default:
-		goto out_free_context;
-	}
-
-	/*
-	 * Init HYP architected timer support
-	 */
-	err = kvm_timer_hyp_init();
-	if (err)
-		goto out_free_context;
-
 #ifndef CONFIG_HOTPLUG_CPU
 	free_boot_hyp_pgd();
 #endif
 
-	kvm_perf_init();
+	cpu_notifier_register_begin();
+
+	err = __register_cpu_notifier(&hyp_init_cpu_nb);
+
+	cpu_notifier_register_done();
+
+	if (err) {
+		kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
+		goto out_err;
+	}
+
+	hyp_cpu_pm_init();
 
 	/* set size of VMID supported by CPU */
 	kvm_vmid_bits = kvm_get_vmid_bits();
@@ -1163,14 +1222,9 @@ static int init_hyp_mode(void)
 	kvm_info("Hyp mode initialized successfully\n");
 
 	return 0;
-out_free_context:
-	free_percpu(kvm_host_cpu_state);
-out_free_mappings:
-	free_hyp_pgds();
-out_free_stack_pages:
-	for_each_possible_cpu(cpu)
-		free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
+
 out_err:
+	teardown_hyp_mode();
 	kvm_err("error initializing Hyp mode: %d\n", err);
 	return err;
 }
@@ -1214,26 +1268,27 @@ int kvm_arch_init(void *opaque)
 		}
 	}
 
-	cpu_notifier_register_begin();
-
-	err = init_hyp_mode();
+	err = init_common_resources();
 	if (err)
-		goto out_err;
+		return err;
 
-	err = __register_cpu_notifier(&hyp_init_cpu_nb);
-	if (err) {
-		kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
+	if (is_kernel_in_hyp_mode())
+		err = init_vhe_mode();
+	else
+		err = init_hyp_mode();
+	if (err)
 		goto out_err;
-	}
-
-	cpu_notifier_register_done();
 
-	hyp_cpu_pm_init();
+	err = init_subsystems();
+	if (err)
+		goto out_hyp;
 
-	kvm_coproc_table_init();
 	return 0;
+
+out_hyp:
+	teardown_hyp_mode();
 out_err:
-	cpu_notifier_register_done();
+	teardown_common_resources();
 	return err;
 }
 
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index aba61fd..920d0c3 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -28,6 +28,7 @@
 #include <asm/kvm_mmio.h>
 #include <asm/kvm_asm.h>
 #include <asm/kvm_emulate.h>
+#include <asm/virt.h>
 
 #include "trace.h"
 
@@ -598,6 +599,9 @@ int create_hyp_mappings(void *from, void *to)
 	unsigned long start = KERN_TO_HYP((unsigned long)from);
 	unsigned long end = KERN_TO_HYP((unsigned long)to);
 
+	if (is_kernel_in_hyp_mode())
+		return 0;
+
 	start = start & PAGE_MASK;
 	end = PAGE_ALIGN(end);
 
@@ -630,6 +634,9 @@ int create_hyp_io_mappings(void *from, void *to, phys_addr_t phys_addr)
 	unsigned long start = KERN_TO_HYP((unsigned long)from);
 	unsigned long end = KERN_TO_HYP((unsigned long)to);
 
+	if (is_kernel_in_hyp_mode())
+		return 0;
+
 	/* Check for a valid kernel IO mapping */
 	if (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1))
 		return -EINVAL;
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 10:00:03 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:03 +0000
Subject: [PATCH v3 10/23] arm64: KVM: VHE: Differenciate host/guest sysreg
 save/restore
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-11-git-send-email-marc.zyngier@arm.com>

With ARMv8, host and guest share the same system register file,
making the save/restore procedure completely symetrical.
With VHE, host and guest now have different requirements, as they
use different sysregs.

In order to prepare for this, add split sysreg save/restore functions
for both host and guest. No functional changes yet.

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/hyp.h       |  6 ++++--
 arch/arm64/kvm/hyp/switch.c    | 10 +++++-----
 arch/arm64/kvm/hyp/sysreg-sr.c | 24 ++++++++++++++++++++++--
 3 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
index 744c919..5dfa883 100644
--- a/arch/arm64/kvm/hyp/hyp.h
+++ b/arch/arm64/kvm/hyp/hyp.h
@@ -153,8 +153,10 @@ void __vgic_v3_restore_state(struct kvm_vcpu *vcpu);
 void __timer_save_state(struct kvm_vcpu *vcpu);
 void __timer_restore_state(struct kvm_vcpu *vcpu);
 
-void __sysreg_save_state(struct kvm_cpu_context *ctxt);
-void __sysreg_restore_state(struct kvm_cpu_context *ctxt);
+void __sysreg_save_host_state(struct kvm_cpu_context *ctxt);
+void __sysreg_restore_host_state(struct kvm_cpu_context *ctxt);
+void __sysreg_save_guest_state(struct kvm_cpu_context *ctxt);
+void __sysreg_restore_guest_state(struct kvm_cpu_context *ctxt);
 void __sysreg32_save_state(struct kvm_vcpu *vcpu);
 void __sysreg32_restore_state(struct kvm_vcpu *vcpu);
 
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index ca8f5a5..9071dee 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -98,7 +98,7 @@ static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
 	host_ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
 	guest_ctxt = &vcpu->arch.ctxt;
 
-	__sysreg_save_state(host_ctxt);
+	__sysreg_save_host_state(host_ctxt);
 	__debug_cond_save_host_state(vcpu);
 
 	__activate_traps(vcpu);
@@ -112,7 +112,7 @@ static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
 	 * to Cortex-A57 erratum #852523.
 	 */
 	__sysreg32_restore_state(vcpu);
-	__sysreg_restore_state(guest_ctxt);
+	__sysreg_restore_guest_state(guest_ctxt);
 	__debug_restore_state(vcpu, kern_hyp_va(vcpu->arch.debug_ptr), guest_ctxt);
 
 	/* Jump in the fire! */
@@ -121,7 +121,7 @@ static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
 
 	fp_enabled = __fpsimd_enabled();
 
-	__sysreg_save_state(guest_ctxt);
+	__sysreg_save_guest_state(guest_ctxt);
 	__sysreg32_save_state(vcpu);
 	__timer_save_state(vcpu);
 	__vgic_save_state(vcpu);
@@ -129,7 +129,7 @@ static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
 	__deactivate_traps(vcpu);
 	__deactivate_vm(vcpu);
 
-	__sysreg_restore_state(host_ctxt);
+	__sysreg_restore_host_state(host_ctxt);
 
 	if (fp_enabled) {
 		__fpsimd_save_state(&guest_ctxt->gp_regs.fp_regs);
@@ -161,7 +161,7 @@ void __hyp_text __noreturn __hyp_panic(void)
 		host_ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
 		__deactivate_traps(vcpu);
 		__deactivate_vm(vcpu);
-		__sysreg_restore_state(host_ctxt);
+		__sysreg_restore_host_state(host_ctxt);
 	}
 
 	/* Call panic for real */
diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
index 42563098..bd5b543 100644
--- a/arch/arm64/kvm/hyp/sysreg-sr.c
+++ b/arch/arm64/kvm/hyp/sysreg-sr.c
@@ -24,7 +24,7 @@
 #include "hyp.h"
 
 /* ctxt is already in the HYP VA space */
-void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
+static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
 {
 	ctxt->sys_regs[MPIDR_EL1]	= read_sysreg(vmpidr_el2);
 	ctxt->sys_regs[CSSELR_EL1]	= read_sysreg(csselr_el1);
@@ -57,7 +57,17 @@ void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
 	ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg(spsr_el1);
 }
 
-void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
+void __hyp_text __sysreg_save_host_state(struct kvm_cpu_context *ctxt)
+{
+	__sysreg_save_state(ctxt);
+}
+
+void __hyp_text __sysreg_save_guest_state(struct kvm_cpu_context *ctxt)
+{
+	__sysreg_save_state(ctxt);
+}
+
+static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
 {
 	write_sysreg(ctxt->sys_regs[MPIDR_EL1],	  vmpidr_el2);
 	write_sysreg(ctxt->sys_regs[CSSELR_EL1],  csselr_el1);
@@ -90,6 +100,16 @@ void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
 	write_sysreg(ctxt->gp_regs.spsr[KVM_SPSR_EL1], spsr_el1);
 }
 
+void __hyp_text __sysreg_restore_host_state(struct kvm_cpu_context *ctxt)
+{
+	__sysreg_restore_state(ctxt);
+}
+
+void __hyp_text __sysreg_restore_guest_state(struct kvm_cpu_context *ctxt)
+{
+	__sysreg_restore_state(ctxt);
+}
+
 void __hyp_text __sysreg32_save_state(struct kvm_vcpu *vcpu)
 {
 	u64 *spsr, *sysreg;
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 10:00:07 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:07 +0000
Subject: [PATCH v3 14/23] arm64: KVM: VHE: Make __fpsimd_enabled VHE aware
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-15-git-send-email-marc.zyngier@arm.com>

As non-VHE and VHE have different ways to express the trapping of
FPSIMD registers to EL2, make __fpsimd_enabled a patchable predicate
and provide a VHE implementation.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_arm.h |  3 +++
 arch/arm64/kvm/hyp/hyp.h         |  5 +----
 arch/arm64/kvm/hyp/switch.c      | 19 +++++++++++++++++++
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 738a95f..498335e 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -217,4 +217,7 @@
 	ECN(SOFTSTP_CUR), ECN(WATCHPT_LOW), ECN(WATCHPT_CUR), \
 	ECN(BKPT32), ECN(VECTOR32), ECN(BRK64)
 
+#define CPACR_EL1_FPEN		(3 << 20)
+#define CPACR_EL1_TTA		(1 << 28)
+
 #endif /* __ARM64_KVM_ARM_H__ */
diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
index 5dfa883..44eaff7 100644
--- a/arch/arm64/kvm/hyp/hyp.h
+++ b/arch/arm64/kvm/hyp/hyp.h
@@ -171,10 +171,7 @@ void __debug_cond_restore_host_state(struct kvm_vcpu *vcpu);
 
 void __fpsimd_save_state(struct user_fpsimd_state *fp_regs);
 void __fpsimd_restore_state(struct user_fpsimd_state *fp_regs);
-static inline bool __fpsimd_enabled(void)
-{
-	return !(read_sysreg(cptr_el2) & CPTR_EL2_TFP);
-}
+bool __fpsimd_enabled(void);
 
 u64 __guest_enter(struct kvm_vcpu *vcpu, struct kvm_cpu_context *host_ctxt);
 void __noreturn __hyp_do_panic(unsigned long, ...);
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 9071dee..0db161e 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -17,6 +17,25 @@
 
 #include "hyp.h"
 
+static bool __hyp_text __fpsimd_enabled_nvhe(void)
+{
+	return !(read_sysreg(cptr_el2) & CPTR_EL2_TFP);
+}
+
+static bool __hyp_text __fpsimd_enabled_vhe(void)
+{
+	return !!(read_sysreg(cpacr_el1) & CPACR_EL1_FPEN);
+}
+
+static hyp_alternate_select(__fpsimd_is_enabled,
+			    __fpsimd_enabled_nvhe, __fpsimd_enabled_vhe,
+			    ARM64_HAS_VIRT_HOST_EXTN);
+
+bool __hyp_text __fpsimd_enabled(void)
+{
+	return __fpsimd_is_enabled()();
+}
+
 static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
 {
 	u64 val;
-- 
2.1.4



From will.deacon at arm.com  Wed Feb  3 10:00:58 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed,  3 Feb 2016 18:00:58 +0000
Subject: [PATCH] dt-bindings: arm,
 gic-v3: require that reserved cells are always 0
Message-ID: <1454522458-29643-1-git-send-email-will.deacon@arm.com>

The arm,gic-v3 binding was written with good intentions and doesn't
enforce interrupt-cells to be 3, therefore making it easy to extend
the irq description in future if necessary:

  > Cells 4 and beyond are reserved for future use.

Unfortunately, this sentence is immediately followed up with:

  > When the 1st cell has a value of 0 or 1, cells 4 and beyond act as
  > padding, and may be ignored. It is recommended that padding cells
  > have a value of 0.

Consequently, any extensions to the PPI or SPI interrupt specifiers must
be able to work with random crap from legacy DTs, effectively
necessitating a new interrupt type in the first cell. Sigh.

This patch fixes the text so that additional, reserved cells are
required to be zero. This looks like a reasonable thing to require and
is already satisifed by the .dts files in-tree.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 .../devicetree/bindings/interrupt-controller/arm,gic-v3.txt          | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
index 7803e77d85cb..007a5b46256a 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
@@ -24,9 +24,8 @@ Main node required properties:
 		1 = edge triggered
 		4 = level triggered
 
-  Cells 4 and beyond are reserved for future use. When the 1st cell
-  has a value of 0 or 1, cells 4 and beyond act as padding, and may be
-  ignored. It is recommended that padding cells have a value of 0.
+  Cells 4 and beyond are reserved for future use and must have a value
+  of 0 if present.
 
 - reg : Specifies base physical address(s) and size of the GIC
   registers, in the following order:
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 10:00:15 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:15 +0000
Subject: [PATCH v3 22/23] arm64: VHE: Add support for running Linux in EL2 mode
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-23-git-send-email-marc.zyngier@arm.com>

With ARMv8.1 VHE, the architecture is able to (almost) transparently
run the kernel at EL2, despite being written for EL1.

This patch takes care of the "almost" part, mostly preventing the kernel
from dropping from EL2 to EL1, and setting up the HYP configuration.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/Kconfig       | 13 +++++++++++++
 arch/arm64/kernel/head.S | 28 +++++++++++++++++++++++++++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc6228..cf118d9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -750,6 +750,19 @@ config ARM64_LSE_ATOMICS
 	  not support these instructions and requires the kernel to be
 	  built with binutils >= 2.25.
 
+config ARM64_VHE
+	bool "Enable support for Virtualization Host Extensions (VHE)"
+	default y
+	help
+	  Virtualization Host Extensions (VHE) allow the kernel to run
+	  directly at EL2 (instead of EL1) on processors that support
+	  it. This leads to better performance for KVM, as they reduce
+	  the cost of the world switch.
+
+	  Selecting this option allows the VHE feature to be detected
+	  at runtime, and does not affect processors that do not
+	  implement this feature.
+
 endmenu
 
 endmenu
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 917d981..6f2f377 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -30,6 +30,7 @@
 #include <asm/cache.h>
 #include <asm/cputype.h>
 #include <asm/kernel-pgtable.h>
+#include <asm/kvm_arm.h>
 #include <asm/memory.h>
 #include <asm/pgtable-hwdef.h>
 #include <asm/pgtable.h>
@@ -464,9 +465,27 @@ CPU_LE(	bic	x0, x0, #(3 << 24)	)	// Clear the EE and E0E bits for EL1
 	isb
 	ret
 
+2:
+#ifdef CONFIG_ARM64_VHE
+	/*
+	 * Check for VHE being present. For the rest of the EL2 setup,
+	 * x2 being non-zero indicates that we do have VHE, and that the
+	 * kernel is intended to run at EL2.
+	 */
+	mrs	x2, id_aa64mmfr1_el1
+	ubfx	x2, x2, #8, #4
+#else
+	mov	x2, xzr
+#endif
+
 	/* Hyp configuration. */
-2:	mov	x0, #(1 << 31)			// 64-bit EL1
+	mov	x0, #HCR_RW			// 64-bit EL1
+	cbz	x2, set_hcr
+	orr	x0, x0, #HCR_TGE		// Enable Host Extensions
+	orr	x0, x0, #HCR_E2H
+set_hcr:
 	msr	hcr_el2, x0
+	isb
 
 	/* Generic timers. */
 	mrs	x0, cnthctl_el2
@@ -526,6 +545,13 @@ CPU_LE(	movk	x0, #0x30d0, lsl #16	)	// Clear EE and E0E on LE systems
 	/* Stage-2 translation */
 	msr	vttbr_el2, xzr
 
+	cbz	x2, install_el2_stub
+
+	mov	w20, #BOOT_CPU_MODE_EL2		// This CPU booted in EL2
+	isb
+	ret
+
+install_el2_stub:
 	/* Hypervisor stub */
 	adrp	x0, __hyp_stub_vectors
 	add	x0, x0, #:lo12:__hyp_stub_vectors
-- 
2.1.4



From ulf.hansson at linaro.org  Wed Feb  3 10:02:32 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Wed, 3 Feb 2016 19:02:32 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160203162705.GG19432@atomide.com>
References: <20160201232833.GR19432@atomide.com>
 <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>
 <20160202030533.GT19432@atomide.com>
 <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>
 <20160202163536.GU19432@atomide.com>
 <CAPDyKFosQjkHDVSvy67+hstjjFseXQP5WYXrJE19GgVFYJ099w@mail.gmail.com>
 <20160202234145.GC19432@atomide.com>
 <CAPDyKFqLi8xOUeoxUTAmif5QrOjVpV_2CDLv4hjO_C9iOnv+5Q@mail.gmail.com>
 <20160203162705.GG19432@atomide.com>
Message-ID: <CAPDyKFrsbW+vOoKBDvkNbJa=aUZE1EcikCqrAuO4cv+TkW-FnA@mail.gmail.com>

On 3 February 2016 at 17:27, Tony Lindgren <tony at atomide.com> wrote:
>
>> >> To me, it's the responsible of the PM domain to *help* with the
>> >> synchronization, not prevent it as it currently does.
>> >
>> > The problem is that the hardware state gets out of sync with
>> > PM runtime. And that's going to be a pain to debug later on.
>>
>> I don't see the problem, but of course you know omap for better than I do.
>
> Well there's also the long term maintenance aspect at least I
> need to consider.
>
>> So if you are concerned about this, perhaps adding a dev_dbg print
>> when the omap hwmod's ->runtime_suspend() callback returns zero could
>> be a way forward?
>
> If we downgrade it to a debug statement or a warning, we'll soon end
> up with even more driver specific warnings than we already have.
> And I don't want to be chasing people around to fix their drivers
> for eavery new driver that gets submitted.
>
> Also, without this error I would not even originally have noticed we
> have a problem :) So I suggest the following:

Well, I am actually not removing that existing warning in the
omap_device_enable(), as it's being called from other places as well.

It's just the runtime PM path that's being changed.

>
> 1. I'll do a series of patches to fix up the handful of omap
>    specific drivers with pm_runtime_use_autosuspend() that depend
>    on omap_device
>
> 2. I'll also do a patch to improve the omap_device error message
>    so new drivers are easy to fix. Something like:
>
>   "%() called from invalid state %d, use pm_runtime_put_sync_suspend()?"
>
> Does that sounds OK to you?

Sure.

>
> Regards,
>
> Tony

One more thing though. I just realized that you have yet another issue
to consider going for the approach fixing *only* drivers.

Let me summarize it here:

If userspace has prevented runtime PM (pm_runtime_forbid()) when a
driver becomes unbound, the driver will not be able to suspend the
device by using any of the pm_runtime_suspend() APIs, as the usage
count is isn't zero.

As pm_runtime_reinit() is invoked as part of the driver unbind
sequence, the runtime PM status goes out of sync. A following driver
rebind will then trigger the warning when the PM domain's
->runtime_resume() callback gets invoked. Again, forever preventing
the device from being runtime suspended.

How do you intend to solve this case?
I guess there are two options, pick up the patch I posted for omap
hwmod or make use of pm_runtime_force_suspend() in the driver.

Kind regards
Uffe


From marc.zyngier at arm.com  Wed Feb  3 10:00:08 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:08 +0000
Subject: [PATCH v3 15/23] arm64: KVM: VHE: Implement VHE
 activate/deactivate_traps
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-16-git-send-email-marc.zyngier@arm.com>

Running the kernel in HYP mode requires the HCR_E2H bit to be set
at all times, and the HCR_TGE bit to be set when running as a host
(and cleared when running as a guest). At the same time, the vector
 must be set to the current role of the kernel (either host or
hypervisor), and a couple of system registers differ between VHE
and non-VHE.

We implement these by using another set of alternate functions
that get dynamically patched.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_arm.h     |  3 ++-
 arch/arm64/include/asm/kvm_emulate.h |  3 +++
 arch/arm64/kvm/hyp/switch.c          | 47 +++++++++++++++++++++++++++++++++---
 3 files changed, 49 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 498335e..100cbec 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -23,6 +23,7 @@
 #include <asm/types.h>
 
 /* Hyp Configuration Register (HCR) bits */
+#define HCR_E2H		(UL(1) << 34)
 #define HCR_ID		(UL(1) << 33)
 #define HCR_CD		(UL(1) << 32)
 #define HCR_RW_SHIFT	31
@@ -81,7 +82,7 @@
 			 HCR_AMO | HCR_SWIO | HCR_TIDCP | HCR_RW)
 #define HCR_VIRT_EXCP_MASK (HCR_VA | HCR_VI | HCR_VF)
 #define HCR_INT_OVERRIDE   (HCR_FMO | HCR_IMO)
-
+#define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H)
 
 /* Hyp System Control Register (SCTLR_EL2) bits */
 #define SCTLR_EL2_EE	(1 << 25)
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 3066328..5ae0c69 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -29,6 +29,7 @@
 #include <asm/kvm_mmio.h>
 #include <asm/ptrace.h>
 #include <asm/cputype.h>
+#include <asm/virt.h>
 
 unsigned long *vcpu_reg32(const struct kvm_vcpu *vcpu, u8 reg_num);
 unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu);
@@ -43,6 +44,8 @@ void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
 static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu)
 {
 	vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
+	if (is_kernel_in_hyp_mode())
+		vcpu->arch.hcr_el2 |= HCR_E2H;
 	if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features))
 		vcpu->arch.hcr_el2 &= ~HCR_RW;
 }
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 0db161e..686ca35 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -15,6 +15,8 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <asm/kvm_asm.h>
+
 #include "hyp.h"
 
 static bool __hyp_text __fpsimd_enabled_nvhe(void)
@@ -36,6 +38,27 @@ bool __hyp_text __fpsimd_enabled(void)
 	return __fpsimd_is_enabled()();
 }
 
+static void __hyp_text __activate_traps_vhe(void)
+{
+	u64 val;
+
+	val = read_sysreg(cpacr_el1);
+	val |= CPACR_EL1_TTA;
+	val &= ~CPACR_EL1_FPEN;
+	write_sysreg(val, cpacr_el1);
+
+	write_sysreg(__kvm_hyp_vector, vbar_el1);
+}
+
+static void __hyp_text __activate_traps_nvhe(void)
+{
+	write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
+}
+
+static hyp_alternate_select(__activate_traps_arch,
+			    __activate_traps_nvhe, __activate_traps_vhe,
+			    ARM64_HAS_VIRT_HOST_EXTN);
+
 static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
 {
 	u64 val;
@@ -55,16 +78,34 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
 	write_sysreg(val, hcr_el2);
 	/* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
 	write_sysreg(1 << 15, hstr_el2);
-	write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
 	write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
+	__activate_traps_arch()();
 }
 
-static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
+static void __hyp_text __deactivate_traps_vhe(void)
+{
+	extern char vectors[];	/* kernel exception vectors */
+
+	write_sysreg(HCR_HOST_VHE_FLAGS, hcr_el2);
+	write_sysreg(CPACR_EL1_FPEN, cpacr_el1);
+	write_sysreg(vectors, vbar_el1);
+}
+
+static void __hyp_text __deactivate_traps_nvhe(void)
 {
 	write_sysreg(HCR_RW, hcr_el2);
+	write_sysreg(0, cptr_el2);
+}
+
+static hyp_alternate_select(__deactivate_traps_arch,
+			    __deactivate_traps_nvhe, __deactivate_traps_vhe,
+			    ARM64_HAS_VIRT_HOST_EXTN);
+
+static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
+{
+	__deactivate_traps_arch()();
 	write_sysreg(0, hstr_el2);
 	write_sysreg(read_sysreg(mdcr_el2) & MDCR_EL2_HPMN_MASK, mdcr_el2);
-	write_sysreg(0, cptr_el2);
 }
 
 static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
-- 
2.1.4



From fu.wei at linaro.org  Wed Feb  3 10:06:02 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Thu, 4 Feb 2016 02:06:02 +0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <56B23E99.1030604@codeaurora.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
Message-ID: <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>

Hi Timur

On 4 February 2016 at 01:53, Timur Tabi <timur at codeaurora.org> wrote:
> Fu Wei wrote:
>>
>> sorry, are you saying : using pre-timeout instead of this half timeout?
>>
>> But even we have pre-timeout support, pre-timeout  == timeout / 2, it
>> can not be configured without touch timeout.
>>
>> if you want pre-timeout  != timeout / 2, we have to modify WCV in the
>> interrupt routine.
>>   (because of the explicit watchdog refresh  mechanism)
>>
>> Could you let me know why we need pre-timeout  here ??:-)
>
>
> What I meant was that if we had full-blown pre-timeout support in the
> watchdog layer, then you could use that to implement the
> panic-on-half-timeout feature.
>
> When pre-timeout is implemented, will you modify the interrupt handler to
> use it?

Sorry I am little confused.

Actually I am taking your suggestion to avoid touching WCV in
interrupt routine.
So even we have pre-timeout support , it is useless for this
panic-on-half-timeout feature,
because pre-timeout  == timeout / 2 (always).

So maybe I misunderstand your suggestion,
could you let me know : why we want pre-timeout here?


>
>>> >belong upstream.  But like I said, it's just my opinion, and I won't
>>> >complain if I'm outvoted.
>>
>>   I think this debugging feature is the  purpose of the two-stage
>> watchdog, if I understand correctly
>
>
> Hmmm... that make sense.  I think maybe you should drop the Kconfig option,
> and just have "static bool panic_enabled = false;"  Also, then do this:
>
> if (panic_enabled) {
>         ret = devm_request_irq(dev, irq, sbsa_gwdt_interrupt, 0,
>                                pdev->name, gwdt);
>         if (ret) {
>                 dev_err(dev, "unable to request IRQ %d\n", irq);
>                 return ret;
>         }
> }

yes, agree

>
> That way, the interrupt handler is never registered if the command-line
> parameter is not specified.
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From marc.zyngier at arm.com  Wed Feb  3 10:00:06 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:06 +0000
Subject: [PATCH v3 13/23] arm64: KVM: VHE: Enable minimal sysreg save/restore
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-14-git-send-email-marc.zyngier@arm.com>

We're now in a position where we can introduce VHE's minimal
save/restore, which is limited to the handful of shared sysregs.

Add the required alternative function calls that result in a
"do nothing" call on VHE, and the normal save/restore for non-VHE.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/sysreg-sr.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
index 7d7d757..74b5f81 100644
--- a/arch/arm64/kvm/hyp/sysreg-sr.c
+++ b/arch/arm64/kvm/hyp/sysreg-sr.c
@@ -23,6 +23,9 @@
 
 #include "hyp.h"
 
+/* Yes, this does nothing, on purpose */
+static void __hyp_text __sysreg_do_nothing(struct kvm_cpu_context *ctxt) { }
+
 /*
  * Non-VHE: Both host and guest must save everything.
  *
@@ -67,9 +70,13 @@ static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
 	ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg_el1(spsr);
 }
 
+static hyp_alternate_select(__sysreg_call_save_host_state,
+			    __sysreg_save_state, __sysreg_do_nothing,
+			    ARM64_HAS_VIRT_HOST_EXTN);
+
 void __hyp_text __sysreg_save_host_state(struct kvm_cpu_context *ctxt)
 {
-	__sysreg_save_state(ctxt);
+	__sysreg_call_save_host_state()(ctxt);
 	__sysreg_save_common_state(ctxt);
 }
 
@@ -116,9 +123,13 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
 	write_sysreg_el1(ctxt->gp_regs.spsr[KVM_SPSR_EL1],spsr);
 }
 
+static hyp_alternate_select(__sysreg_call_restore_host_state,
+			    __sysreg_restore_state, __sysreg_do_nothing,
+			    ARM64_HAS_VIRT_HOST_EXTN);
+
 void __hyp_text __sysreg_restore_host_state(struct kvm_cpu_context *ctxt)
 {
-	__sysreg_restore_state(ctxt);
+	__sysreg_call_restore_host_state()(ctxt);
 	__sysreg_restore_common_state(ctxt);
 }
 
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb  3 10:00:14 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed,  3 Feb 2016 18:00:14 +0000
Subject: [PATCH v3 21/23] arm64: hw_breakpoint: Allow EL2 breakpoints if
 running in HYP
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454522416-6874-22-git-send-email-marc.zyngier@arm.com>

With VHE, we place kernel {watch,break}-points at EL2 to get things
like kgdb and "perf -e mem:..." working.

This requires a bit of repainting in the low-level encore/decode,
but is otherwise pretty simple.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/hw_breakpoint.h | 49 +++++++++++++++++++++-------------
 1 file changed, 31 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
index 9732908..0da0272 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -18,6 +18,7 @@
 
 #include <asm/cputype.h>
 #include <asm/cpufeature.h>
+#include <asm/virt.h>
 
 #ifdef __KERNEL__
 
@@ -35,24 +36,6 @@ struct arch_hw_breakpoint {
 	struct arch_hw_breakpoint_ctrl ctrl;
 };
 
-static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
-{
-	return (ctrl.len << 5) | (ctrl.type << 3) | (ctrl.privilege << 1) |
-		ctrl.enabled;
-}
-
-static inline void decode_ctrl_reg(u32 reg,
-				   struct arch_hw_breakpoint_ctrl *ctrl)
-{
-	ctrl->enabled	= reg & 0x1;
-	reg >>= 1;
-	ctrl->privilege	= reg & 0x3;
-	reg >>= 2;
-	ctrl->type	= reg & 0x3;
-	reg >>= 2;
-	ctrl->len	= reg & 0xff;
-}
-
 /* Breakpoint */
 #define ARM_BREAKPOINT_EXECUTE	0
 
@@ -76,6 +59,36 @@ static inline void decode_ctrl_reg(u32 reg,
 #define ARM_KERNEL_STEP_ACTIVE	1
 #define ARM_KERNEL_STEP_SUSPEND	2
 
+#define DBG_HMC_HYP		(1 << 13)
+#define DBG_SSC_HYP		(3 << 14)
+
+static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
+{
+	u32 val = (ctrl.len << 5) | (ctrl.type << 3) | ctrl.enabled;
+
+	if (is_kernel_in_hyp_mode() && ctrl.privilege == AARCH64_BREAKPOINT_EL1)
+		val |= DBG_HMC_HYP | DBG_SSC_HYP;
+	else
+		val |= ctrl.privilege << 1;
+
+	return val;
+}
+
+static inline void decode_ctrl_reg(u32 reg,
+				   struct arch_hw_breakpoint_ctrl *ctrl)
+{
+	ctrl->enabled	= reg & 0x1;
+	reg >>= 1;
+	if (is_kernel_in_hyp_mode())
+		ctrl->privilege = !!(reg & (DBG_HMC_HYP >> 1));
+	else
+		ctrl->privilege	= reg & 0x3;
+	reg >>= 2;
+	ctrl->type	= reg & 0x3;
+	reg >>= 2;
+	ctrl->len	= reg & 0xff;
+}
+
 /*
  * Limits.
  * Changing these will require modifications to the register accessors.
-- 
2.1.4



From timur at codeaurora.org  Wed Feb  3 10:08:59 2016
From: timur at codeaurora.org (Timur Tabi)
Date: Wed, 3 Feb 2016 12:08:59 -0600
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
Message-ID: <56B2423B.1020109@codeaurora.org>

Fu Wei wrote:
> Actually I am taking your suggestion to avoid touching WCV in
> interrupt routine.
> So even we have pre-timeout support , it is useless for this
> panic-on-half-timeout feature,
> because pre-timeout  == timeout / 2 (always).
>
> So maybe I misunderstand your suggestion,
> could you let me know : why we want pre-timeout here?

Maybe I'm confused.

For pre-timeout, I think the SBSA watchdog driver should support only 
half-timeout.  That is, the user cannot configure the length of the 
pre-timeout with this driver.  He can only enable it, and it is 
automatically set to 1/2 timeout.

So when pre-timeout occurs, the interrupt handler calls panic() or 
whatever it's supposed to do.

So "pre-timeout  == timeout / 2 (always)" is exactly what we want.


From fu.wei at linaro.org  Wed Feb  3 10:09:55 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Thu, 4 Feb 2016 02:09:55 +0800
Subject: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <56B23FE1.2010207@codeaurora.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-5-git-send-email-fu.wei@linaro.org>
 <56B23D61.2050001@codeaurora.org>
 <CADyBb7tteV7VF9oxMaq5NprVdS2UBKobupxoyfSp+jQwp5wmQA@mail.gmail.com>
 <56B23FE1.2010207@codeaurora.org>
Message-ID: <CADyBb7vRTz9NxEmeGvxDooUUUXPPFFcNsjUADHcmSKHS56ZYjA@mail.gmail.com>

On 4 February 2016 at 01:58, Timur Tabi <timur at codeaurora.org> wrote:
> Fu Wei wrote:
>>
>> I have posted  GTDT support separately :https://lkml.org/lkml/2016/2/1/660
>>
>> devicetree driver and GTDT driver both export sbsa gwdt info to
>> "platform resource".
>>
>> this driver get hardware info from platform resource.
>
>
> I must be missing something.  How does the driver probe?  It only has an

maybe you miss a  line of code for platform resource :

---------------------
static const struct platform_device_id sbsa_gwdt_pdev_match[] = {
 { .name = "sbsa-gwdt", },
 {},
};
MODULE_DEVICE_TABLE(platform, sbsa_gwdt_pdev_match);
---------------------

> entry for device tree:
>
> +               .of_match_table = sbsa_gwdt_of_match,
>
> Doesn't there need to be an ACPI match table to probe on an ACPI system?

No, we don't. And this have been tested.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From balbi at kernel.org  Wed Feb  3 10:12:59 2016
From: balbi at kernel.org (Felipe Balbi)
Date: Wed, 03 Feb 2016 20:12:59 +0200
Subject: [PATCH 0/7] USB changes for rare warnings
In-Reply-To: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
Message-ID: <87oabxpsr8.fsf@ti.com>


Hi Arnd,

Arnd Bergmann <arnd at arndb.de> writes:
> Hi Felipe,
>
> This set of patches addresses warnings I got in randconfig builds,
> in the USB drivers. The first three patches are for the pxa25x
> UDC driver and are a larger scale cleanup triggered by finding
> the initial bug. The other four are relatively simple but still
> need to be reviewed properly, as I have done only compile-time
> testing. After these patches, I get no other warnings for USB
> drivers at the moment.
>
> Arnd Bergmann (7):
>   usb: gadget: pxa25x_udc: move register definitions from arch
>   usb: gadget: pxa25x_udc cleanup
>   usb: gadget: pxa25x_udc: use readl/writel for mmio
>   usb: fsl: drop USB_FSL_MPH_DR_OF Kconfig symbol
>   usb: isp1301-omap: mark power_up as __maybe_unused
>   usb: musb: use %pad format string from dma_addr_t
>   usb: musb/ux500: remove duplicate check for dma_is_compatible
>
>  arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h | 198 ---------
>  arch/arm/mach-pxa/include/mach/pxa25x-udc.h     | 163 --------

for arch/arm I need Acked-by from relevant folks.

Also, do you think we need this during the -rc or can we consider it
non-critical fixes for v4.6 merge window ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/a9a73c4d/attachment-0001.sig>

From timur at codeaurora.org  Wed Feb  3 10:12:31 2016
From: timur at codeaurora.org (Timur Tabi)
Date: Wed, 3 Feb 2016 12:12:31 -0600
Subject: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <CADyBb7vRTz9NxEmeGvxDooUUUXPPFFcNsjUADHcmSKHS56ZYjA@mail.gmail.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-5-git-send-email-fu.wei@linaro.org>
 <56B23D61.2050001@codeaurora.org>
 <CADyBb7tteV7VF9oxMaq5NprVdS2UBKobupxoyfSp+jQwp5wmQA@mail.gmail.com>
 <56B23FE1.2010207@codeaurora.org>
 <CADyBb7vRTz9NxEmeGvxDooUUUXPPFFcNsjUADHcmSKHS56ZYjA@mail.gmail.com>
Message-ID: <56B2430F.4070708@codeaurora.org>

Fu Wei wrote:
> static const struct platform_device_id sbsa_gwdt_pdev_match[] = {
>   { .name = "sbsa-gwdt", },
>   {},
> };
> MODULE_DEVICE_TABLE(platform, sbsa_gwdt_pdev_match);

Ok, thanks.


From catalin.marinas at arm.com  Wed Feb  3 10:12:52 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 3 Feb 2016 18:12:52 +0000
Subject: [PATCH v4 4/7] arm64: Handle early CPU boot failures
In-Reply-To: <20160203175351.GG1234@leverpostej>
References: <1453745225-27736-1-git-send-email-suzuki.poulose@arm.com>
 <1453745225-27736-5-git-send-email-suzuki.poulose@arm.com>
 <20160203125735.GA26487@MBP.local>
 <20160203164632.GC1234@leverpostej>
 <20160203173448.GD26487@MBP.local>
 <20160203175351.GG1234@leverpostej>
Message-ID: <20160203181250.GE26487@MBP.local>

On Wed, Feb 03, 2016 at 05:53:51PM +0000, Mark Rutland wrote:
> On Wed, Feb 03, 2016 at 05:34:49PM +0000, Catalin Marinas wrote:
> > On Wed, Feb 03, 2016 at 04:46:32PM +0000, Mark Rutland wrote:
> > > On Wed, Feb 03, 2016 at 12:57:38PM +0000, Catalin Marinas wrote:
> > > > On Mon, Jan 25, 2016 at 06:07:02PM +0000, Suzuki K. Poulose wrote:
> > > > > + * update_early_cpu_boot_status tmp, status
> > > > > + *  - Corrupts tmp, x0, x1
> > > > > + *  - Writes 'status' to __early_cpu_boot_status and makes sure
> > > > > + *    it is committed to memory.
> > > > > + */
> > > > > +
> > > > > +	.macro	update_early_cpu_boot_status tmp, status
> > > > > +	mov	\tmp, lr
> > > > > +	adrp	x0, __early_cpu_boot_status
> > > > > +	add	x0, x0, #:lo12:__early_cpu_boot_status
> > > > 
> > > > Nitpick: you could use the adr_l macro.
> > > > 
> > > > > +	mov	x1, #\status
> > > > > +	str	x1, [x0]
> > > > > +	add	x1, x0, 4
> > > > > +	bl	__inval_cache_range
> > > > > +	mov	lr, \tmp
> > > > > +	.endm
> > > > 
> > > > If the CPU that's currently booting has the MMU off, what's the point of
> > > > invalidating the cache here?
> > > 
> > > To invalidate stale lines for this address, held in any caches prior to
> > > the PoC. I'm assuming that __early_cpu_boot_status is sufficiently
> > > padded to the CWG.
> > 
> > I would have rather invalidated it before writing the [x0], if that's
> > what it's aimed at.
> 
> That alone wouldn't not be sufficient, due to speculative fetches
> allocating new (clean) lines prior to the write completing.

Indeed.

> I was expecting the CWG-aligned region to only be written to with the
> MMU off, i.e. we'd only have clean stale lines and no dirty lines.

I assume that's true even in a guest.

> > > Cache maintenance works when SCTLR_ELx.M == 0, though barriers are
> > > required prior to cache maintenance as non-cacheable accesses do not
> > > hazard by VA.
> > > 
> > > The MMU being off has no effect on the cache maintenance itself.
> > 
> > I know, but whether it has an effect on other CPUs is a different
> > question (it probably has). Anyway, I would rather do the invalidation
> > on the CPU that actually reads this status.
> 
> My only worry would be how this gets ordered against the (non-cacheable)
> store. I guess we'd complete that with a DSB SY regardless.

The synchronisation on the primary CPU is a bit flaky anyway and just
relies on long timeouts. It waits for a while to complete (1 sec) and
than it reads the status. So it assumes that the secondary CPU finished
its writing but neither DSB nor cache maintenance guarantee this.

> Given that, I have no problem doing the invalidate on the read side.
> Assuming we only write from the side with the MMU off, we don't need
> maintenance on that side.

I agree.

> > > > The operation may not even be broadcast to the other CPU. So you
> > > > actually need the invalidation before reading the status on the
> > > > primary CPU.
> > > 
> > > We require that CPUs are coherent when they enter the kernel, so any
> > > cache maintenance operation _must_ affect all coherent caches (i.e. it
> > > must be broadcast and must affect all coherent caches prior to the PoC
> > > in this case).
> > 
> > In general, if you perform cache maintenance on a non-shareable mapping,
> > I don't think it would be broadcast. But in this case, the MMU is off,
> > data accesses default to Device_nGnRnE and considered outer shareable,
> > so it may actually work. Is this stated anywhere in the ARM ARM?
> 
> In ARM DDI 0487A.h, D4.2.8 "The effects of disabling a stage of address
> translation" we state:
> 
> 	Cache maintenance instructions act on the target cache
> 	regardless of whether any stages of address translation are
> 	disabled, and regardless of the values of the memory attributes.
> 	However, if a stage of address translation is disabled, they use
> 	the flat address mapping for that translation stage.

But does "target cache" include other CPUs in the system?

-- 
Catalin


From marc.zyngier at arm.com  Wed Feb  3 10:15:42 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 3 Feb 2016 18:15:42 +0000
Subject: [PATCH] dt-bindings: arm, gic-v3: require that reserved cells are
 always 0
In-Reply-To: <1454522458-29643-1-git-send-email-will.deacon@arm.com>
References: <1454522458-29643-1-git-send-email-will.deacon@arm.com>
Message-ID: <56B243CE.9030807@arm.com>

On 03/02/16 18:00, Will Deacon wrote:
> The arm,gic-v3 binding was written with good intentions and doesn't
> enforce interrupt-cells to be 3, therefore making it easy to extend
> the irq description in future if necessary:
> 
>   > Cells 4 and beyond are reserved for future use.
> 
> Unfortunately, this sentence is immediately followed up with:
> 
>   > When the 1st cell has a value of 0 or 1, cells 4 and beyond act as
>   > padding, and may be ignored. It is recommended that padding cells
>   > have a value of 0.
> 
> Consequently, any extensions to the PPI or SPI interrupt specifiers must
> be able to work with random crap from legacy DTs, effectively
> necessitating a new interrupt type in the first cell. Sigh.
> 
> This patch fixes the text so that additional, reserved cells are
> required to be zero. This looks like a reasonable thing to require and
> is already satisifed by the .dts files in-tree.
> 
> Cc: Mark Rutland <mark.rutland at arm.com>
> Cc: Marc Zyngier <marc.zyngier at arm.com>
> Signed-off-by: Will Deacon <will.deacon at arm.com>

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

	M.
-- 
Jazz is not dead. It just smells funny...


From fu.wei at linaro.org  Wed Feb  3 10:18:38 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Thu, 4 Feb 2016 02:18:38 +0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <56B2423B.1020109@codeaurora.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
Message-ID: <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>

On 4 February 2016 at 02:08, Timur Tabi <timur at codeaurora.org> wrote:
> Fu Wei wrote:
>>
>> Actually I am taking your suggestion to avoid touching WCV in
>> interrupt routine.
>> So even we have pre-timeout support , it is useless for this
>> panic-on-half-timeout feature,
>> because pre-timeout  == timeout / 2 (always).
>>
>> So maybe I misunderstand your suggestion,
>> could you let me know : why we want pre-timeout here?
>
>
> Maybe I'm confused.
>
> For pre-timeout, I think the SBSA watchdog driver should support only
> half-timeout.  That is, the user cannot configure the length of the
> pre-timeout with this driver.  He can only enable it, and it is
> automatically set to 1/2 timeout.

Actually,
the SBSA watchdog driver should support only  half-timeout for panic
the user cannot configure the length of "panic time",  He can only
enable it, and it is automatically set to 1/2 timeout.

we don't need pre-timeout here.

Hope I understand you correctly :-) sorry for your confusion

>
> So when pre-timeout occurs, the interrupt handler calls panic() or whatever
> it's supposed to do.

Actually,
So when 1/2 timeout occurs, the interrupt handler calls panic() or
whatever it's supposed to do.

>
> So "pre-timeout  == timeout / 2 (always)" is exactly what we want.

our patchset is doing this way.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From slash.tmp at free.fr  Wed Feb  3 10:19:12 2016
From: slash.tmp at free.fr (Mason)
Date: Wed, 3 Feb 2016 19:19:12 +0100
Subject: Plain DFS (no voltage scaling)
In-Reply-To: <20160203161331.GI3469@vireshk>
References: <56B11B67.3090600@free.fr> <56B217C9.1050405@free.fr>
 <20160203161331.GI3469@vireshk>
Message-ID: <56B244A0.60309@free.fr>

On 03/02/2016 17:13, Viresh Kumar wrote:
> On 03-02-16, 16:07, Mason wrote:
>> On 02/02/2016 22:11, Mason wrote:
>>
>>> I plan to enable the on-demand governor on the tango platform:
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
>>>
>>> I found the cpufreq-dt binding doc:
>>>
>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
>>>
>>> Something is not clear to me:
>>>
>>> If my platform cannot scale the voltage, what information
>>> should I put in the voltage part of the DT?
>>
>> Someone pointed out that tweaking the frequency without tweaking
>> the voltage might be counter-productive.
>>
>> I measured the power consumption of the entire board (at the power outlet)
>> for 3 CPU frequencies (all other things being equal, I hope).
>>
>> idle @ 111 MHz = 4.6 W
>> idle @ 333 MHz = 4.6 W
>> idle @ 999 MHz = 4.6 W
>>
>> load @ 111 MHz = 5.0 W
>> load @ 333 MHz = 5.7 W
>> load @ 999 MHz = 7.7 W
>>
>> When idle, the kernel calls WFI, which "turns off" most of the CPU
>> (clock gating?) such that the actual frequency does not matter.
>>
>> At full load (I use cpuburn to jog as many FUs simultaneously as
>> possible) it looks like each additional MHz requires ~3 mW.
>>
>> So it would appear that an on-demand governor might not help to
>> save power.
> 
> Why do you say so ?

Here's my (possibly incorrect) reasoning:

If the CPU is idle, kernel calls WFI and frequency apparently
doesn't matter.

If the CPU has work to do, the on-demand governor will bump the
frequency to the max (I think).

I don't think the CPU spends a lot of time in the intermediate
frequencies (neither max nor min).

But maybe my logic is flawed?

Also, some users (of our older kernel) reported problems were
they considered the on-demand governor was "too slow" to ramp
the frequency up. (But I don't know if they'd played with the
configuration knobs.)

Regards.



From slash.tmp at free.fr  Wed Feb  3 10:25:56 2016
From: slash.tmp at free.fr (Mason)
Date: Wed, 3 Feb 2016 19:25:56 +0100
Subject: Plain DFS (no voltage scaling)
In-Reply-To: <20160203161428.GJ3469@vireshk>
References: <56B11B67.3090600@free.fr> <20160203021052.GK31828@vireshk>
 <56B21E2E.1070606@free.fr> <20160203161428.GJ3469@vireshk>
Message-ID: <56B24634.6060001@free.fr>

On 03/02/2016 17:14, Viresh Kumar wrote:
> On 03-02-16, 16:35, Mason wrote:
>> On 03/02/2016 03:10, Viresh Kumar wrote:
>>> On 02-02-16, 22:11, Mason wrote:
>>>> Hello,
>>>>
>>>> I plan to enable the on-demand governor on the tango platform:
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
>>>>
>>>> I found the cpufreq-dt binding doc:
>>>>
>>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
>>>> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
>>>>
>>>> Something is not clear to me:
>>>>
>>>> If my platform cannot scale the voltage, what information
>>>> should I put in the voltage part of the DT?
>>>
>>> Wouldn't matter if there is no regulator. i.e. you should keep 0, but
>>> even if they have something non-zero, core code will ignore it. But
>>> yeah, it makes sense to keep it zero.
>>
>> Hmmm, I am missing something obvious.
>>
>> My config contains:
>>
>> CONFIG_CPU_FREQ=y
>> CONFIG_CPU_FREQ_GOV_COMMON=y
>> CONFIG_CPU_FREQ_STAT=y
>> CONFIG_CPU_FREQ_STAT_DETAILS=y
>> CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
>> CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
>> CONFIG_CPU_FREQ_GOV_ONDEMAND=y
>> CONFIG_CPUFREQ_DT=y
>>
>> Yet, neither dt_cpufreq_probe() nor cpufreq_init() are being called.
>>
>> Could someone please point to my mistake?
> 
> You need to create a platform device to get cpufreq-dt driver probed.
> Check other users..

The sunxi guys pointed me in the right direction.

http://lxr.free-electrons.com/source/arch/arm/mach-sunxi/sunxi.c#L20

Why isn't there a compatible string like other drivers?

Such as
  compatible = "cpufreq-dt"
which would enable cpufreq on the platform?

Regards.



From timur at codeaurora.org  Wed Feb  3 10:26:10 2016
From: timur at codeaurora.org (Timur Tabi)
Date: Wed, 3 Feb 2016 12:26:10 -0600
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
Message-ID: <56B24642.8090105@codeaurora.org>

Fu Wei wrote:
> Actually,
> the SBSA watchdog driver should support only  half-timeout for panic
> the user cannot configure the length of "panic time",  He can only
> enable it, and it is automatically set to 1/2 timeout.
>
> we don't need pre-timeout here.
>
> Hope I understand you correctly:-)  sorry for your confusion
>
>> >
>> >So when pre-timeout occurs, the interrupt handler calls panic() or whatever
>> >it's supposed to do.
> Actually,
> So when 1/2 timeout occurs, the interrupt handler calls panic() or
> whatever it's supposed to do.
>

I understand all that.  What I'm saying is that, in the future, when 
pre-timeout support is added to the watchdog layer, I think it makes 
sense to modify this driver to use pre-timeout support.


From tony at atomide.com  Wed Feb  3 10:28:28 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Feb 2016 10:28:28 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFrsbW+vOoKBDvkNbJa=aUZE1EcikCqrAuO4cv+TkW-FnA@mail.gmail.com>
References: <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>
 <20160202030533.GT19432@atomide.com>
 <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>
 <20160202163536.GU19432@atomide.com>
 <CAPDyKFosQjkHDVSvy67+hstjjFseXQP5WYXrJE19GgVFYJ099w@mail.gmail.com>
 <20160202234145.GC19432@atomide.com>
 <CAPDyKFqLi8xOUeoxUTAmif5QrOjVpV_2CDLv4hjO_C9iOnv+5Q@mail.gmail.com>
 <20160203162705.GG19432@atomide.com>
 <CAPDyKFrsbW+vOoKBDvkNbJa=aUZE1EcikCqrAuO4cv+TkW-FnA@mail.gmail.com>
Message-ID: <20160203182828.GM19432@atomide.com>

* Ulf Hansson <ulf.hansson at linaro.org> [160203 10:03]:
> 
> One more thing though. I just realized that you have yet another issue
> to consider going for the approach fixing *only* drivers.
> 
> Let me summarize it here:
> 
> If userspace has prevented runtime PM (pm_runtime_forbid()) when a
> driver becomes unbound, the driver will not be able to suspend the
> device by using any of the pm_runtime_suspend() APIs, as the usage
> count is isn't zero.
> 
> As pm_runtime_reinit() is invoked as part of the driver unbind
> sequence, the runtime PM status goes out of sync. A following driver
> rebind will then trigger the warning when the PM domain's
> ->runtime_resume() callback gets invoked. Again, forever preventing
> the device from being runtime suspended.

Hmm yeah that's a good point.

> How do you intend to solve this case?
> I guess there are two options, pick up the patch I posted for omap
> hwmod or make use of pm_runtime_force_suspend() in the driver.

My gut feeling right now is we should just have
BUS_NOTIFY_UNBIND_DRIVER shut down the device on the interconnect
automatically as it's unused after the driver has unloaded :)

Regards,

Tony


From okaya at codeaurora.org  Wed Feb  3 10:32:01 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Wed, 3 Feb 2016 13:32:01 -0500
Subject: [PATCH V13 08/10] dma: qcom_hidma: read the channel id from HW
In-Reply-To: <20160201153542.GA20396@leverpostej>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-9-git-send-email-okaya@codeaurora.org>
 <20160201153542.GA20396@leverpostej>
Message-ID: <56B247A1.20503@codeaurora.org>

Hi Mark,

On 2/1/2016 10:35 AM, Mark Rutland wrote:
>> Removing the flexibility to choose the event channel as there is no real
>> > use case right now. We have been using the values in ACPI that match the HW
>> > defaults. OS is reading the event-channel from the HW register now.
> Fold this in to the patches adding the binding and the driver.
> 
> There is no reason to add this then remove it within the same series.
> 
> Mark.
> 

Before I post the next rev, I'd like to see if I missed something in the series when 
it comes to your comments. 

Can you please take a look and let me know?

Sinan

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


From okaya at codeaurora.org  Wed Feb  3 10:32:47 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Wed, 3 Feb 2016 13:32:47 -0500
Subject: [PATCH V13 08/10] dma: qcom_hidma: read the channel id from HW
In-Reply-To: <20160201151455.GA10961@rob-hp-laptop>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-9-git-send-email-okaya@codeaurora.org>
 <20160201151455.GA10961@rob-hp-laptop>
Message-ID: <56B247CF.5060408@codeaurora.org>

On 2/1/2016 10:14 AM, Rob Herring wrote:
> On Fri, Jan 29, 2016 at 05:35:11PM -0500, Sinan Kaya wrote:
>> Removing the flexibility to choose the event channel as there is no real
>> use case right now. We have been using the values in ACPI that match the HW
>> defaults. OS is reading the event-channel from the HW register now.
>>
>> Signed-off-by: Sinan Kaya <okaya at codeaurora.org>
>> ---
>>  .../devicetree/bindings/dma/qcom_hidma_mgmt.txt    |  3 --
>>  drivers/dma/qcom/hidma.c                           | 39 +---------------------
>>  2 files changed, 1 insertion(+), 41 deletions(-)
> 
> Acked-by: Rob Herring <robh at kernel.org>
> 


Thanks Rob,
I'll merge this patch to the existing documentation and code on the next rev.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


From mark.rutland at arm.com  Wed Feb  3 10:20:54 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 3 Feb 2016 18:20:54 +0000
Subject: [PATCH] dt-bindings: arm, gic-v3: require that reserved cells are
 always 0
In-Reply-To: <1454522458-29643-1-git-send-email-will.deacon@arm.com>
References: <1454522458-29643-1-git-send-email-will.deacon@arm.com>
Message-ID: <20160203182054.GH1234@leverpostej>

On Wed, Feb 03, 2016 at 06:00:58PM +0000, Will Deacon wrote:
> The arm,gic-v3 binding was written with good intentions and doesn't
> enforce interrupt-cells to be 3, therefore making it easy to extend
> the irq description in future if necessary:
> 
>   > Cells 4 and beyond are reserved for future use.
> 
> Unfortunately, this sentence is immediately followed up with:
> 
>   > When the 1st cell has a value of 0 or 1, cells 4 and beyond act as
>   > padding, and may be ignored. It is recommended that padding cells
>   > have a value of 0.

The initial intention of this was to allow for new, longer entries which
were identified by a new value in cell 1.

Regardless, I agree that it should be a requirement that padding cells
must be zero.

> Consequently, any extensions to the PPI or SPI interrupt specifiers must
> be able to work with random crap from legacy DTs, effectively
> necessitating a new interrupt type in the first cell. Sigh.

I'm not sure that's true if we allocate a new value for the 1st cell for
"extended" PPI or SPI interrupt-sepcficiers (which presumably add
restrictions). That would also allow old kernels to safely skip such
interrupts rather than mis-parsing them.

> This patch fixes the text so that additional, reserved cells are
> required to be zero. This looks like a reasonable thing to require and
> is already satisifed by the .dts files in-tree.
> 
> Cc: Mark Rutland <mark.rutland at arm.com>
> Cc: Marc Zyngier <marc.zyngier at arm.com>
> Signed-off-by: Will Deacon <will.deacon at arm.com>

This patch itself makes sense, so FWIW:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Any proposed extention to the binding requires its own discussion.

Thanks,
Mark.

> ---
>  .../devicetree/bindings/interrupt-controller/arm,gic-v3.txt          | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
> index 7803e77d85cb..007a5b46256a 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
> @@ -24,9 +24,8 @@ Main node required properties:
>  		1 = edge triggered
>  		4 = level triggered
>  
> -  Cells 4 and beyond are reserved for future use. When the 1st cell
> -  has a value of 0 or 1, cells 4 and beyond act as padding, and may be
> -  ignored. It is recommended that padding cells have a value of 0.
> +  Cells 4 and beyond are reserved for future use and must have a value
> +  of 0 if present.
>  
>  - reg : Specifies base physical address(s) and size of the GIC
>    registers, in the following order:
> -- 
> 2.1.4
> 


From fu.wei at linaro.org  Wed Feb  3 10:37:14 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Thu, 4 Feb 2016 02:37:14 +0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <56B24642.8090105@codeaurora.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
Message-ID: <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>

On 4 February 2016 at 02:26, Timur Tabi <timur at codeaurora.org> wrote:
> Fu Wei wrote:
>>
>> Actually,
>> the SBSA watchdog driver should support only  half-timeout for panic
>> the user cannot configure the length of "panic time",  He can only
>> enable it, and it is automatically set to 1/2 timeout.
>>
>> we don't need pre-timeout here.
>>
>> Hope I understand you correctly:-)  sorry for your confusion
>>
>>> >
>>> >So when pre-timeout occurs, the interrupt handler calls panic() or
>>> > whatever
>>> >it's supposed to do.
>>
>> Actually,
>> So when 1/2 timeout occurs, the interrupt handler calls panic() or
>> whatever it's supposed to do.
>>
>
> I understand all that.  What I'm saying is that, in the future, when
> pre-timeout support is added to the watchdog layer, I think it makes sense
> to modify this driver to use pre-timeout support.

As you know I have made the pre-timeout support patch, If people like
it, i am happy to go on upstream it separately.

If we want to use pre-timeout here, user only can use get_pretimeout
and disable panic by setting pretimeout to 0
but user can not really set pretimeout, because "pre-timeout  ==
timeout / 2 (always)".
if user want to change pretimeout, he/she has to set_time instead.




-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From mark.rutland at arm.com  Wed Feb  3 10:36:50 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 3 Feb 2016 18:36:50 +0000
Subject: [PATCH V13 08/10] dma: qcom_hidma: read the channel id from HW
In-Reply-To: <56B247A1.20503@codeaurora.org>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-9-git-send-email-okaya@codeaurora.org>
 <20160201153542.GA20396@leverpostej>
 <56B247A1.20503@codeaurora.org>
Message-ID: <20160203183650.GI1234@leverpostej>

On Wed, Feb 03, 2016 at 01:32:01PM -0500, Sinan Kaya wrote:
> Hi Mark,
> 
> On 2/1/2016 10:35 AM, Mark Rutland wrote:
> >> Removing the flexibility to choose the event channel as there is no real
> >> > use case right now. We have been using the values in ACPI that match the HW
> >> > defaults. OS is reading the event-channel from the HW register now.
> > Fold this in to the patches adding the binding and the driver.
> > 
> > There is no reason to add this then remove it within the same series.
> > 
> > Mark.
> > 
> 
> Before I post the next rev, I'd like to see if I missed something in the series when 
> it comes to your comments. 
> 
> Can you please take a look and let me know?

Sorry, but it's going to be far easier to review with useless code
removed, so I will wait until the next posting where this patch is
folded in.

Thanks,
Mark.


From ulf.hansson at linaro.org  Wed Feb  3 10:37:31 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Wed, 3 Feb 2016 19:37:31 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160203182828.GM19432@atomide.com>
References: <Pine.LNX.4.44L0.1602011844540.2869-100000@netrider.rowland.org>
 <20160202030533.GT19432@atomide.com>
 <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>
 <20160202163536.GU19432@atomide.com>
 <CAPDyKFosQjkHDVSvy67+hstjjFseXQP5WYXrJE19GgVFYJ099w@mail.gmail.com>
 <20160202234145.GC19432@atomide.com>
 <CAPDyKFqLi8xOUeoxUTAmif5QrOjVpV_2CDLv4hjO_C9iOnv+5Q@mail.gmail.com>
 <20160203162705.GG19432@atomide.com>
 <CAPDyKFrsbW+vOoKBDvkNbJa=aUZE1EcikCqrAuO4cv+TkW-FnA@mail.gmail.com>
 <20160203182828.GM19432@atomide.com>
Message-ID: <CAPDyKFonA4AAzx9JaQ2NZViMLvCjoa5vy2WRuhEF_5Hg8gPKeg@mail.gmail.com>

On 3 February 2016 at 19:28, Tony Lindgren <tony at atomide.com> wrote:
> * Ulf Hansson <ulf.hansson at linaro.org> [160203 10:03]:
>>
>> One more thing though. I just realized that you have yet another issue
>> to consider going for the approach fixing *only* drivers.
>>
>> Let me summarize it here:
>>
>> If userspace has prevented runtime PM (pm_runtime_forbid()) when a
>> driver becomes unbound, the driver will not be able to suspend the
>> device by using any of the pm_runtime_suspend() APIs, as the usage
>> count is isn't zero.
>>
>> As pm_runtime_reinit() is invoked as part of the driver unbind
>> sequence, the runtime PM status goes out of sync. A following driver
>> rebind will then trigger the warning when the PM domain's
>> ->runtime_resume() callback gets invoked. Again, forever preventing
>> the device from being runtime suspended.
>
> Hmm yeah that's a good point.
>
>> How do you intend to solve this case?
>> I guess there are two options, pick up the patch I posted for omap
>> hwmod or make use of pm_runtime_force_suspend() in the driver.
>
> My gut feeling right now is we should just have
> BUS_NOTIFY_UNBIND_DRIVER shut down the device on the interconnect
> automatically as it's unused after the driver has unloaded :)

BUS_NOTIFY_UNBIND_DRIVER is sent prior the ->remove() callbacks is
invoked from driver core.
So if the driver requires to do a pm_runtime_get_sync() during
->remove() callback, this won't work.

BUS_NOTIFY_UNBOUND_DRIVER may work though.

Kind regards
Uffe


From okaya at codeaurora.org  Wed Feb  3 10:38:12 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Wed, 3 Feb 2016 13:38:12 -0500
Subject: [PATCH V13 09/10] vfio, platform: add support for ACPI while
 detecting the reset driver
In-Reply-To: <56AF87E2.8040201@linaro.org>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-10-git-send-email-okaya@codeaurora.org>
 <56AF82FA.7000303@linaro.org> <56AF84F4.2080809@codeaurora.org>
 <56AF87E2.8040201@linaro.org>
Message-ID: <56B24914.6030103@codeaurora.org>

Hi Baptiste, Alex;

On 2/1/2016 11:29 AM, Eric Auger wrote:
>>> I added Baptiste who is vfio platform driver sub-system maintainer.
>> > 
>> > Thanks, we should ask Baptiste to get his email into the Maintainer file list.
> I think it is:
> ./scripts/get_maintainer.pl
> 0001-vfio-platform-add-support-for-ACPI-while-detecting-t.patch

Any comments on these two reviews?

https://lkml.org/lkml/2016/1/29/679
https://lkml.org/lkml/2016/1/29/677

Sinan

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


From mathieu.poirier at linaro.org  Wed Feb  3 10:38:58 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:38:58 -0700
Subject: [PATCH V9 00/18] Coresight integration with perf 
Message-ID: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>

This is the ninth iteration of this serie.  Changes are minor and don't
affect how the integration is done.

One notable thing is the absence of the patches adding support for this
PMU at the user space perf tool level.  Those will be lumped with the
rest of the user space trace decoding solution currently being worked
on.

This set is based on [1] and assumes [2] and [3] have been applied.

Best regards,
Mathieu

[1]. https://git.linaro.org/kernel/coresight.git/shortlog/refs/heads/next 
[2]. http://www.spinics.net/lists/arm-kernel/msg479330.html
[3]. https://lkml.org/lkml/2016/1/26/793 

Original description:

This patchset aims to integrate configuration and control of
the Coresight tracers with the perf sub-system.

The goal is to use PMUs to represent tracers and the auxiliary
buffer enhancement to collect processor traces.  As such a lot
of work is done to move the current Coresight sysFS oriented
configuration and control commands to perf's AUX API.

For the time being the work concentrates on ETMv3 and ETB1.0
sink buffer.  Work on ETMv4 and other type of sink buffers
will follow once a foundation has been established.

Changes since V8:
* Rebased to v4.5-rc2.
* Fixed the possibility of a type overflow in etb_reset_buffer().
* Removed unneeded spinlock grab in etb_update_buffer().
* Removed unneeded event->cpu range check in etm_event_init().
* Removed warning when perf_aux_output_begin() fails in etm_event_start().
* Added warning when a sink can't be found in etm_event_start().
* As stated above, removed patches related to the user space perf tools.

Changes since V7:
* Moved coresight_release_path() a workqueue context, preventing
  pm_runtime_put_sync() from being called from an invalid
  (i.e interrupt) context.
* Fixed wrong 'buf_ptr' type in function etb_update_buffer().
* In function auxtrace_record__init(), no longer setting the 'err'
  pointer to '-EINVAL'.
* Removing erroneous call to kfree() in function etm_disable_sysfs(). 

[1]. https://git.linaro.org/kernel/coresight.git/shortlog/refs/heads/next 
[2]. http://www.spinics.net/lists/arm-kernel/msg474573.html 

Changes since V6:
* Rebased to 4.4-rc5.
* Thanks to [1], all tracer configuration now happens
  when events are scheduled.

[1]. https://lwn.net/Articles/667573/

Changes since V5:
* Addressed Arnaldo's comment about using a struct perf_evlist rather
  than a struct perf_session.
* Addressed kbuild test robot's anomaly report [1].
* Moved perf_aux_output_{begin|end} to etm_event_{start|stop} in
  accordance with [2].

[1]. https://lkml.org/lkml/2015/11/30/46
[2]. http://thread.gmane.org/gmane.linux.kernel/2099328/focus=2099343

Changes since V4:
* Reworked the way event configuration information is kept, fixing
  a few corner cases when doing per CPU tracing.
* Rebased on 4.4-rc1.
* Added 'Cc' to specific perf related patches in the hope of suscitating
  interest from reviewers, i.e perf maintainers.

Changes since V3:
* Rebased to GKH's char-misc-next tree (e2d8680741ed).

Changes since V2:
* Rebased to v4.3.
* Used the -M option to "git format-patch".
* Decoupled tracers and path - both are now completely independent.
* Moved path enablement/release to Perf's add/del functions.
* Moved PM runtime operations to the coresight core rather than
  individual drivers.
* Enhanced mutual exclusion scheme between perf and sysFS.
* Removed architecture specific define in perf cmd line tool.
* Got rid of unused fields in structure 'cs_buffers'.
* Enhanced changelog for patch 16/26.

Changes since V1:
 * Fixed typos in typographical error in documentation.
 * Moved to a multi session support scheme.
 * Split static and dynamic tracer configuration.
 * Fixed configuration for user and kernel space tracing.
 * Using WARN_ON_ONCE() rather than WARN_ON().
 * Implemented strategy to prevent tracers from being used simultaneously.
 * Changed sink_ops::unset_buffer() to sink_ops::reset_buffer().
 * Moves ETM's sysFS interface from driver core to dedicated file.
 * Removed spinlock in "etm_cpu_id()".
 * Aggregated PMU driver pieces in a single patch.
 * Added user space changes and rebased everything to v4.3-rc5.




Mathieu Poirier (18):
  coresight: associating path with session rather than tracer
  coresight: add API to get sink from path
  coresight: moving PM runtime operations to core framework
  coresight: etm3x: moving etm_readl/writel to header file
  coresight: etm3x: moving sysFS entries to dedicated file
  coresight: etm3x: unlocking tracers in default arch init
  coresight: etm3x: splitting struct etm_drvdata
  coresight: etm3x: adding operation mode for etm_enable()
  coresight: etm3x: set progbit to stop trace collection
  coresight: etm3x: changing default trace configuration
  coresight: etm3x: consolidating initial config
  coresight: etm3x: implementing user/kernel mode tracing
  coresight: etm3x: implementing perf_enable/disable() API
  coresight: etb10: moving to local atomic operations
  coresight: etb10: adding operation mode for sink->enable()
  coresight: etb10: implementing AUX API
  coresight: etm-perf: new PMU driver for ETM tracers
  coresight: introducing a global trace ID function

 drivers/hwtracing/coresight/Kconfig                |    1 +
 drivers/hwtracing/coresight/Makefile               |    4 +-
 drivers/hwtracing/coresight/coresight-etb10.c      |  273 ++-
 drivers/hwtracing/coresight/coresight-etm-perf.c   |  393 +++++
 drivers/hwtracing/coresight/coresight-etm-perf.h   |   32 +
 drivers/hwtracing/coresight/coresight-etm.h        |  142 +-
 .../hwtracing/coresight/coresight-etm3x-sysfs.c    | 1272 ++++++++++++++
 drivers/hwtracing/coresight/coresight-etm3x.c      | 1816 +++++---------------
 drivers/hwtracing/coresight/coresight-etm4x.c      |   10 +-
 drivers/hwtracing/coresight/coresight-funnel.c     |    2 -
 drivers/hwtracing/coresight/coresight-priv.h       |   15 +
 .../coresight/coresight-replicator-qcom.c          |    4 -
 drivers/hwtracing/coresight/coresight-replicator.c |    2 -
 drivers/hwtracing/coresight/coresight-tmc.c        |    7 +-
 drivers/hwtracing/coresight/coresight-tpiu.c       |    4 +-
 drivers/hwtracing/coresight/coresight.c            |  326 ++--
 include/linux/coresight-pmu.h                      |   39 +
 include/linux/coresight.h                          |   31 +-
 18 files changed, 2756 insertions(+), 1617 deletions(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-etm-perf.c
 create mode 100644 drivers/hwtracing/coresight/coresight-etm-perf.h
 create mode 100644 drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
 create mode 100644 include/linux/coresight-pmu.h

-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb  3 10:38:59 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:38:59 -0700
Subject: [PATCH V9 01/18] coresight: associating path with session rather than
 tracer
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-2-git-send-email-mathieu.poirier@linaro.org>

When using the Coresight framework from the sysFS interface a
tracer is always handling a single session and as such, a path
can be associated with a tracer.  But when supporting multiple
session per tracer there is no guarantee that sessions will always
have the same path from source to sink.

This patch is removing the automatic association between path and
tracers.  The building of a path and enablement of the components
in the path are decoupled, allowing for the association of a path
with a session rather than a tracer.

To keep backward functionality with the current sysFS access methods
a per-cpu place holder is used to keep a handle on the path built when
tracers are enabled.  Lastly APIs to build paths and enable tracers are
made public so that other subsystem can interact with the Coresight
framework.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-priv.h |   5 +
 drivers/hwtracing/coresight/coresight.c      | 296 ++++++++++++++++++---------
 include/linux/coresight.h                    |   2 -
 3 files changed, 206 insertions(+), 97 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 62fcd98cc7cf..7b193a34d709 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -52,6 +52,11 @@ static inline void CS_UNLOCK(void __iomem *addr)
 	} while (0);
 }
 
+void coresight_disable_path(struct list_head *path);
+int coresight_enable_path(struct list_head *path);
+struct list_head *coresight_build_path(struct coresight_device *csdev);
+void coresight_release_path(struct list_head *path);
+
 #ifdef CONFIG_CORESIGHT_SOURCE_ETM3X
 extern int etm_readl_cp14(u32 off, unsigned int *val);
 extern int etm_writel_cp14(u32 off, u32 val);
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 7e6e9ff27dd1..f26589effb70 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -29,6 +29,22 @@
 
 static DEFINE_MUTEX(coresight_mutex);
 
+/**
+ * struct coresight_node - elements of a path, from source to sink
+ * @csdev:	Address of an element.
+ * @link:	hook to the list.
+ */
+struct coresight_node {
+	struct coresight_device *csdev;
+	struct list_head link;
+};
+
+/*
+ * When operating Coresight drivers from the sysFS interface, only a single
+ * path can exist from a tracer (associated to a CPU) to a sink.
+ */
+static DEFINE_PER_CPU(struct list_head *, sysfs_path);
+
 static int coresight_id_match(struct device *dev, void *data)
 {
 	int trace_id, i_trace_id;
@@ -68,15 +84,12 @@ static int coresight_source_is_unique(struct coresight_device *csdev)
 				 csdev, coresight_id_match);
 }
 
-static int coresight_find_link_inport(struct coresight_device *csdev)
+static int coresight_find_link_inport(struct coresight_device *csdev,
+				      struct coresight_device *parent)
 {
 	int i;
-	struct coresight_device *parent;
 	struct coresight_connection *conn;
 
-	parent = container_of(csdev->path_link.next,
-			      struct coresight_device, path_link);
-
 	for (i = 0; i < parent->nr_outport; i++) {
 		conn = &parent->conns[i];
 		if (conn->child_dev == csdev)
@@ -89,15 +102,12 @@ static int coresight_find_link_inport(struct coresight_device *csdev)
 	return 0;
 }
 
-static int coresight_find_link_outport(struct coresight_device *csdev)
+static int coresight_find_link_outport(struct coresight_device *csdev,
+				       struct coresight_device *child)
 {
 	int i;
-	struct coresight_device *child;
 	struct coresight_connection *conn;
 
-	child = container_of(csdev->path_link.prev,
-			     struct coresight_device, path_link);
-
 	for (i = 0; i < csdev->nr_outport; i++) {
 		conn = &csdev->conns[i];
 		if (conn->child_dev == child)
@@ -138,14 +148,19 @@ static void coresight_disable_sink(struct coresight_device *csdev)
 	}
 }
 
-static int coresight_enable_link(struct coresight_device *csdev)
+static int coresight_enable_link(struct coresight_device *csdev,
+				 struct coresight_device *parent,
+				 struct coresight_device *child)
 {
 	int ret;
 	int link_subtype;
 	int refport, inport, outport;
 
-	inport = coresight_find_link_inport(csdev);
-	outport = coresight_find_link_outport(csdev);
+	if (!parent || !child)
+		return -EINVAL;
+
+	inport = coresight_find_link_inport(csdev, parent);
+	outport = coresight_find_link_outport(csdev, child);
 	link_subtype = csdev->subtype.link_subtype;
 
 	if (link_subtype == CORESIGHT_DEV_SUBTYPE_LINK_MERG)
@@ -168,14 +183,19 @@ static int coresight_enable_link(struct coresight_device *csdev)
 	return 0;
 }
 
-static void coresight_disable_link(struct coresight_device *csdev)
+static void coresight_disable_link(struct coresight_device *csdev,
+				   struct coresight_device *parent,
+				   struct coresight_device *child)
 {
 	int i, nr_conns;
 	int link_subtype;
 	int refport, inport, outport;
 
-	inport = coresight_find_link_inport(csdev);
-	outport = coresight_find_link_outport(csdev);
+	if (!parent || !child)
+		return;
+
+	inport = coresight_find_link_inport(csdev, parent);
+	outport = coresight_find_link_outport(csdev, child);
 	link_subtype = csdev->subtype.link_subtype;
 
 	if (link_subtype == CORESIGHT_DEV_SUBTYPE_LINK_MERG) {
@@ -235,109 +255,167 @@ static void coresight_disable_source(struct coresight_device *csdev)
 	}
 }
 
-static int coresight_enable_path(struct list_head *path)
+void coresight_disable_path(struct list_head *path)
 {
-	int ret = 0;
-	struct coresight_device *cd;
+	struct coresight_node *nd;
+	struct coresight_device *csdev, *parent, *child;
 
-	/*
-	 * At this point we have a full @path, from source to sink.  The
-	 * sink is the first entry and the source the last one.  Go through
-	 * all the components and enable them one by one.
-	 */
-	list_for_each_entry(cd, path, path_link) {
-		if (cd == list_first_entry(path, struct coresight_device,
-					   path_link)) {
-			ret = coresight_enable_sink(cd);
-		} else if (list_is_last(&cd->path_link, path)) {
-			/*
-			 * Don't enable the source just yet - this needs to
-			 * happen at the very end when all links and sink
-			 * along the path have been configured properly.
-			 */
-			;
-		} else {
-			ret = coresight_enable_link(cd);
+	list_for_each_entry(nd, path, link) {
+		csdev = nd->csdev;
+
+		switch (csdev->type) {
+		case CORESIGHT_DEV_TYPE_SINK:
+		case CORESIGHT_DEV_TYPE_LINKSINK:
+			coresight_disable_sink(csdev);
+			break;
+		case CORESIGHT_DEV_TYPE_SOURCE:
+			/* sources are disabled from either sysFS or Perf */
+			break;
+		case CORESIGHT_DEV_TYPE_LINK:
+			parent = list_prev_entry(nd, link)->csdev;
+			child = list_next_entry(nd, link)->csdev;
+			coresight_disable_link(csdev, parent, child);
+			break;
+		default:
+			break;
 		}
-		if (ret)
-			goto err;
 	}
+}
 
-	return 0;
-err:
-	list_for_each_entry_continue_reverse(cd, path, path_link) {
-		if (cd == list_first_entry(path, struct coresight_device,
-					   path_link)) {
-			coresight_disable_sink(cd);
-		} else if (list_is_last(&cd->path_link, path)) {
-			;
-		} else {
-			coresight_disable_link(cd);
+int coresight_enable_path(struct list_head *path)
+{
+
+	int ret = 0;
+	struct coresight_node *nd;
+	struct coresight_device *csdev, *parent, *child;
+
+	list_for_each_entry_reverse(nd, path, link) {
+		csdev = nd->csdev;
+
+		switch (csdev->type) {
+		case CORESIGHT_DEV_TYPE_SINK:
+		case CORESIGHT_DEV_TYPE_LINKSINK:
+			ret = coresight_enable_sink(csdev);
+			if (ret)
+				goto err;
+			break;
+		case CORESIGHT_DEV_TYPE_SOURCE:
+			/* sources are enabled from either sysFS or Perf */
+			break;
+		case CORESIGHT_DEV_TYPE_LINK:
+			parent = list_prev_entry(nd, link)->csdev;
+			child = list_next_entry(nd, link)->csdev;
+			ret = coresight_enable_link(csdev, parent, child);
+			if (ret)
+				goto err;
+			break;
+		default:
+			goto err;
 		}
 	}
 
+out:
 	return ret;
+err:
+	coresight_disable_path(path);
+	goto out;
 }
 
-static int coresight_disable_path(struct list_head *path)
+/**
+ * _coresight_build_path - recursively build a path from a @csdev to a sink.
+ * @csdev:	The device to start from.
+ * @path:	The list to add devices to.
+ *
+ * The tree of Coresight device is traversed until an activated sink is
+ * found.  From there the sink is added to the list along with all the
+ * devices that led to that point - the end result is a list from source
+ * to sink. In that list the source is the first device and the sink the
+ * last one.
+ */
+static int _coresight_build_path(struct coresight_device *csdev,
+				 struct list_head *path)
 {
-	struct coresight_device *cd;
+	int i;
+	bool found = false;
+	struct coresight_node *node;
+	struct coresight_connection *conn;
 
-	list_for_each_entry_reverse(cd, path, path_link) {
-		if (cd == list_first_entry(path, struct coresight_device,
-					   path_link)) {
-			coresight_disable_sink(cd);
-		} else if (list_is_last(&cd->path_link, path)) {
-			/*
-			 * The source has already been stopped, no need
-			 * to do it again here.
-			 */
-			;
-		} else {
-			coresight_disable_link(cd);
+	/* An activated sink has been found.  Enqueue the element */
+	if ((csdev->type == CORESIGHT_DEV_TYPE_SINK ||
+	     csdev->type == CORESIGHT_DEV_TYPE_LINKSINK) && csdev->activated)
+		goto out;
+
+	/* Not a sink - recursively explore each port found on this element */
+	for (i = 0; i < csdev->nr_outport; i++) {
+		conn = &csdev->conns[i];
+		if (_coresight_build_path(conn->child_dev, path) == 0) {
+			found = true;
+			break;
 		}
 	}
 
+	if (!found)
+		return -ENODEV;
+
+out:
+	/*
+	 * A path from this element to a sink has been found.  The elements
+	 * leading to the sink are already enqueued, all that is left to do
+	 * is add a node for this element.
+	 */
+	node = kzalloc(sizeof(struct coresight_node), GFP_KERNEL);
+	if (!node)
+		return -ENOMEM;
+
+	node->csdev = csdev;
+	list_add(&node->link, path);
+
 	return 0;
 }
 
-static int coresight_build_paths(struct coresight_device *csdev,
-				 struct list_head *path,
-				 bool enable)
+struct list_head *coresight_build_path(struct coresight_device *csdev)
 {
-	int i, ret = -EINVAL;
-	struct coresight_connection *conn;
+	struct list_head *path;
 
-	list_add(&csdev->path_link, path);
+	path = kzalloc(sizeof(struct list_head), GFP_KERNEL);
+	if (!path)
+		return NULL;
 
-	if ((csdev->type == CORESIGHT_DEV_TYPE_SINK ||
-	    csdev->type == CORESIGHT_DEV_TYPE_LINKSINK) &&
-	    csdev->activated) {
-		if (enable)
-			ret = coresight_enable_path(path);
-		else
-			ret = coresight_disable_path(path);
-	} else {
-		for (i = 0; i < csdev->nr_outport; i++) {
-			conn = &csdev->conns[i];
-			if (coresight_build_paths(conn->child_dev,
-						    path, enable) == 0)
-				ret = 0;
-		}
+	INIT_LIST_HEAD(path);
+
+	if (_coresight_build_path(csdev, path)) {
+		kfree(path);
+		path = NULL;
 	}
 
-	if (list_first_entry(path, struct coresight_device, path_link) != csdev)
-		dev_err(&csdev->dev, "wrong device in %s\n", __func__);
+	return path;
+}
 
-	list_del(&csdev->path_link);
+/**
+ * coresight_release_path - release a previously built path.
+ * @path:	the path to release.
+ *
+ * Go through all the elements of a path and 1) removed it from the list and
+ * 2) free the memory allocated for each node.
+ */
+void coresight_release_path(struct list_head *path)
+{
+	struct coresight_node *nd, *next;
 
-	return ret;
+	list_for_each_entry_safe(nd, next, path, link) {
+		list_del(&nd->link);
+		kfree(nd);
+	}
+
+	kfree(path);
+	path = NULL;
 }
 
 int coresight_enable(struct coresight_device *csdev)
 {
 	int ret = 0;
-	LIST_HEAD(path);
+	int cpu;
+	struct list_head *path;
 
 	mutex_lock(&coresight_mutex);
 	if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE) {
@@ -348,22 +426,47 @@ int coresight_enable(struct coresight_device *csdev)
 	if (csdev->enable)
 		goto out;
 
-	if (coresight_build_paths(csdev, &path, true)) {
-		dev_err(&csdev->dev, "building path(s) failed\n");
+	path = coresight_build_path(csdev);
+	if (!path) {
+		pr_err("building path(s) failed\n");
 		goto out;
 	}
 
-	if (coresight_enable_source(csdev))
-		dev_err(&csdev->dev, "source enable failed\n");
+	ret = coresight_enable_path(path);
+	if (ret)
+		goto err_path;
+
+	ret = coresight_enable_source(csdev);
+	if (ret)
+		goto err_source;
+
+	/*
+	 * When working from sysFS it is important to keep track
+	 * of the paths that were created so that they can be
+	 * undone in 'coresight_disable()'.  Since there can only
+	 * be a single session per tracer (when working from sysFS)
+	 * a per-cpu variable will do just fine.
+	 */
+	cpu = source_ops(csdev)->cpu_id(csdev);
+	per_cpu(sysfs_path, cpu) = path;
+
 out:
 	mutex_unlock(&coresight_mutex);
 	return ret;
+
+err_source:
+	coresight_disable_path(path);
+
+err_path:
+	coresight_release_path(path);
+	goto out;
 }
 EXPORT_SYMBOL_GPL(coresight_enable);
 
 void coresight_disable(struct coresight_device *csdev)
 {
-	LIST_HEAD(path);
+	int cpu;
+	struct list_head *path;
 
 	mutex_lock(&coresight_mutex);
 	if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE) {
@@ -373,9 +476,12 @@ void coresight_disable(struct coresight_device *csdev)
 	if (!csdev->enable)
 		goto out;
 
+	cpu = source_ops(csdev)->cpu_id(csdev);
+	path = per_cpu(sysfs_path, cpu);
 	coresight_disable_source(csdev);
-	if (coresight_build_paths(csdev, &path, false))
-		dev_err(&csdev->dev, "releasing path(s) failed\n");
+	coresight_disable_path(path);
+	coresight_release_path(path);
+	per_cpu(sysfs_path, cpu) = NULL;
 
 out:
 	mutex_unlock(&coresight_mutex);
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index bf62b265bf52..851ecb22397e 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -152,7 +152,6 @@ struct coresight_connection {
 		by @coresight_ops.
  * @dev:	The device entity associated to this component.
  * @refcnt:	keep track of what is in use.
- * @path_link:	link of current component into the path being enabled.
  * @orphan:	true if the component has connections that haven't been linked.
  * @enable:	'true' if component is currently part of an active path.
  * @activated:	'true' only if a _sink_ has been activated.  A sink can be
@@ -168,7 +167,6 @@ struct coresight_device {
 	const struct coresight_ops *ops;
 	struct device dev;
 	atomic_t *refcnt;
-	struct list_head path_link;
 	bool orphan;
 	bool enable;	/* true only if configured as part of a path */
 	bool activated;	/* true only if a sink is part of a path */
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb  3 10:39:08 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:08 -0700
Subject: [PATCH V9 10/18] coresight: etm3x: changing default trace
 configuration
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-11-git-send-email-mathieu.poirier@linaro.org>

Changing default configuration to include the entire address
range rather than just the kernel.  That way traces are more
inclusive and it is easier to narrow down if needed.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm.h   |  2 ++
 drivers/hwtracing/coresight/coresight-etm3x.c | 29 ++++++++++++---------------
 2 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
index 5b29d5540fe5..44585d4adb26 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -146,6 +146,7 @@
  * @startstop_ctrl: setting for register ETMTSSCR.
  * @enable_event: setting for register ETMTEEVR.
  * @enable_ctrl1: setting for register ETMTECR1.
+ * @enable_ctrl2: setting for register ETMTECR2.
  * @fifofull_level: setting for register ETMFFLR.
  * @addr_idx:	index for the address comparator selection.
  * @addr_val:	value for address comparator register.
@@ -179,6 +180,7 @@ struct etm_config {
 	u32				startstop_ctrl;
 	u32				enable_event;
 	u32				enable_ctrl1;
+	u32				enable_ctrl2;
 	u32				fifofull_level;
 	u8				addr_idx;
 	u32				addr_val[ETM_MAX_ADDR_CMP];
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 447459969cb5..92139674bea4 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -579,26 +579,23 @@ static void etm_init_arch_data(void *info)
 
 static void etm_init_default_data(struct etm_config *config)
 {
-	u32 flags = (1 << 0 | /* instruction execute*/
-		     3 << 3 | /* ARM instruction */
-		     0 << 5 | /* No data value comparison */
-		     0 << 7 | /* No exact mach */
-		     0 << 8 | /* Ignore context ID */
-		     0 << 10); /* Security ignored */
-
 	if (WARN_ON_ONCE(!config))
 		return;
 
-	config->ctrl = (ETMCR_CYC_ACC | ETMCR_TIMESTAMP_EN);
-	config->enable_ctrl1 = ETMTECR1_ADDR_COMP_1;
-	config->addr_val[0] = (u32) _stext;
-	config->addr_val[1] = (u32) _etext;
-	config->addr_acctype[0] = flags;
-	config->addr_acctype[1] = flags;
-	config->addr_type[0] = ETM_ADDR_TYPE_RANGE;
-	config->addr_type[1] = ETM_ADDR_TYPE_RANGE;
-
 	etm_set_default(config);
+
+	/*
+	 * Taken verbatim from the TRM:
+	 *
+	 * To trace all memory:
+	 *  set bit [24] in register 0x009, the ETMTECR1, to 1
+	 *  set all other bits in register 0x009, the ETMTECR1, to 0
+	 *  set all bits in register 0x007, the ETMTECR2, to 0
+	 *  set register 0x008, the ETMTEEVR, to 0x6F (TRUE).
+	 */
+	config->enable_ctrl1 = BIT(24);
+	config->enable_ctrl2 = 0x0;
+	config->enable_event = ETM_HARD_WIRE_RES_A;
 }
 
 static void etm_init_trace_id(struct etm_drvdata *drvdata)
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb  3 10:39:07 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:07 -0700
Subject: [PATCH V9 09/18] coresight: etm3x: set progbit to stop trace
 collection
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-10-git-send-email-mathieu.poirier@linaro.org>

There is no need to use the event enable's "always false" event to
stop trace collection.  For that purpose setting the programming bit
(ETMCR:10) is enough.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm3x.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index e16501b41ed8..447459969cb5 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -398,9 +398,6 @@ static void etm_disable_hw(void *info)
 	CS_UNLOCK(drvdata->base);
 	etm_set_prog(drvdata);
 
-	/* Program trace enable to low by using always false event */
-	etm_writel(drvdata, ETM_HARD_WIRE_RES_A | ETM_EVENT_NOT_A, ETMTEEVR);
-
 	/* Read back sequencer and counters for post trace analysis */
 	config->seq_curr_state = (etm_readl(drvdata, ETMSQR) & ETM_SQR_MASK);
 
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb  3 10:39:09 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:09 -0700
Subject: [PATCH V9 11/18] coresight: etm3x: consolidating initial config
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-12-git-send-email-mathieu.poirier@linaro.org>

There is really no point in having two functions to take care
of doing the initial tracer configuration.  As such moving
everything to 'etm_set_default()'.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm3x.c | 37 ++++++++++-----------------
 1 file changed, 14 insertions(+), 23 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 92139674bea4..34a69583ccbc 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -41,7 +41,6 @@ module_param_named(boot_enable, boot_enable, int, S_IRUGO);
 /* The number of ETM/PTM currently registered */
 static int etm_count;
 static struct etm_drvdata *etmdrvdata[NR_CPUS];
-static void etm_init_default_data(struct etm_config *config);
 
 /*
  * Memory mapped writes to clear os lock are not supported on some processors
@@ -194,6 +193,19 @@ void etm_set_default(struct etm_config *config)
 	if (WARN_ON_ONCE(!config))
 		return;
 
+	/*
+	 * Taken verbatim from the TRM:
+	 *
+	 * To trace all memory:
+	 *  set bit [24] in register 0x009, the ETMTECR1, to 1
+	 *  set all other bits in register 0x009, the ETMTECR1, to 0
+	 *  set all bits in register 0x007, the ETMTECR2, to 0
+	 *  set register 0x008, the ETMTEEVR, to 0x6F (TRUE).
+	 */
+	config->enable_ctrl1 = BIT(24);
+	config->enable_ctrl2 = 0x0;
+	config->enable_event = ETM_HARD_WIRE_RES_A;
+
 	config->trigger_event = ETM_DEFAULT_EVENT_VAL;
 	config->enable_event = ETM_HARD_WIRE_RES_A;
 
@@ -577,27 +589,6 @@ static void etm_init_arch_data(void *info)
 	CS_LOCK(drvdata->base);
 }
 
-static void etm_init_default_data(struct etm_config *config)
-{
-	if (WARN_ON_ONCE(!config))
-		return;
-
-	etm_set_default(config);
-
-	/*
-	 * Taken verbatim from the TRM:
-	 *
-	 * To trace all memory:
-	 *  set bit [24] in register 0x009, the ETMTECR1, to 1
-	 *  set all other bits in register 0x009, the ETMTECR1, to 0
-	 *  set all bits in register 0x007, the ETMTECR2, to 0
-	 *  set register 0x008, the ETMTEEVR, to 0x6F (TRUE).
-	 */
-	config->enable_ctrl1 = BIT(24);
-	config->enable_ctrl2 = 0x0;
-	config->enable_event = ETM_HARD_WIRE_RES_A;
-}
-
 static void etm_init_trace_id(struct etm_drvdata *drvdata)
 {
 	/*
@@ -674,7 +665,7 @@ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
 	}
 
 	etm_init_trace_id(drvdata);
-	etm_init_default_data(&drvdata->config);
+	etm_set_default(&drvdata->config);
 
 	desc->type = CORESIGHT_DEV_TYPE_SOURCE;
 	desc->subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_PROC;
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb  3 10:39:06 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:06 -0700
Subject: [PATCH V9 08/18] coresight: etm3x: adding operation mode for
 etm_enable()
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-9-git-send-email-mathieu.poirier@linaro.org>

Adding a new mode to source API enable() in order to
distinguish where the request comes from.  That way it is
possible to perform different operations based on where
the request was issued from.

The ETM4x driver is also modified to keep in sync with the
new interface.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm.h        |  5 +-
 .../hwtracing/coresight/coresight-etm3x-sysfs.c    |  4 +-
 drivers/hwtracing/coresight/coresight-etm3x.c      | 68 +++++++++++++++++++---
 drivers/hwtracing/coresight/coresight-etm4x.c      |  2 +-
 drivers/hwtracing/coresight/coresight-priv.h       |  6 ++
 drivers/hwtracing/coresight/coresight.c            |  6 +-
 include/linux/coresight.h                          |  2 +-
 7 files changed, 76 insertions(+), 17 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
index 371fb7d2e829..5b29d5540fe5 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -13,6 +13,7 @@
 #ifndef _CORESIGHT_CORESIGHT_ETM_H
 #define _CORESIGHT_CORESIGHT_ETM_H
 
+#include <asm/local.h>
 #include <linux/spinlock.h>
 #include "coresight-priv.h"
 
@@ -214,7 +215,7 @@ struct etm_config {
  * @port_size:	port size as reported by ETMCR bit 4-6 and 21.
  * @arch:	ETM/PTM version number.
  * @use_cpu14:	true if management registers need to be accessed via CP14.
- * @enable:	is this ETM/PTM currently tracing.
+ * @mode:	this tracer's mode, i.e sysFS, Perf or disabled.
  * @sticky_enable: true if ETM base configuration has been done.
  * @boot_enable:true if we should start tracing at boot time.
  * @os_unlock:	true if access to management registers is allowed.
@@ -238,7 +239,7 @@ struct etm_drvdata {
 	int				port_size;
 	u8				arch;
 	bool				use_cp14;
-	bool				enable;
+	local_t				mode;
 	bool				sticky_enable;
 	bool				boot_enable;
 	bool				os_unlock;
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
index 456df2378a6f..387c79fd9d5e 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
@@ -716,7 +716,7 @@ static ssize_t cntr_val_show(struct device *dev,
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
 	struct etm_config *config = &drvdata->config;
 
-	if (!drvdata->enable) {
+	if (!local_read(&drvdata->mode)) {
 		spin_lock(&drvdata->spinlock);
 		for (i = 0; i < drvdata->nr_cntr; i++)
 			ret += sprintf(buf, "counter %d: %x\n",
@@ -935,7 +935,7 @@ static ssize_t seq_curr_state_show(struct device *dev,
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
 	struct etm_config *config = &drvdata->config;
 
-	if (!drvdata->enable) {
+	if (!local_read(&drvdata->mode)) {
 		val = config->seq_curr_state;
 		goto out;
 	}
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 1952dc31fee4..e16501b41ed8 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -306,7 +306,7 @@ int etm_get_trace_id(struct etm_drvdata *drvdata)
 	if (!drvdata)
 		goto out;
 
-	if (!drvdata->enable)
+	if (!local_read(&drvdata->mode))
 		return drvdata->traceid;
 
 	pm_runtime_get_sync(drvdata->dev);
@@ -332,7 +332,7 @@ static int etm_trace_id(struct coresight_device *csdev)
 	return etm_get_trace_id(drvdata);
 }
 
-static int etm_enable(struct coresight_device *csdev)
+static int etm_enable_sysfs(struct coresight_device *csdev)
 {
 	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	int ret;
@@ -351,18 +351,44 @@ static int etm_enable(struct coresight_device *csdev)
 			goto err;
 	}
 
-	drvdata->enable = true;
 	drvdata->sticky_enable = true;
-
 	spin_unlock(&drvdata->spinlock);
 
 	dev_info(drvdata->dev, "ETM tracing enabled\n");
 	return 0;
+
 err:
 	spin_unlock(&drvdata->spinlock);
 	return ret;
 }
 
+static int etm_enable(struct coresight_device *csdev, u32 mode)
+{
+	int ret;
+	u32 val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	val = local_cmpxchg(&drvdata->mode, CS_MODE_DISABLED, mode);
+
+	/* Someone is already using the tracer */
+	if (val)
+		return -EBUSY;
+
+	switch (mode) {
+	case CS_MODE_SYSFS:
+		ret = etm_enable_sysfs(csdev);
+		break;
+	default:
+		ret = -EINVAL;
+	}
+
+	/* The tracer didn't start */
+	if (ret)
+		local_set(&drvdata->mode, CS_MODE_DISABLED);
+
+	return ret;
+}
+
 static void etm_disable_hw(void *info)
 {
 	int i;
@@ -387,7 +413,7 @@ static void etm_disable_hw(void *info)
 	dev_dbg(drvdata->dev, "cpu: %d disable smp call done\n", drvdata->cpu);
 }
 
-static void etm_disable(struct coresight_device *csdev)
+static void etm_disable_sysfs(struct coresight_device *csdev)
 {
 	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
@@ -405,7 +431,6 @@ static void etm_disable(struct coresight_device *csdev)
 	 * ensures that register writes occur when cpu is powered.
 	 */
 	smp_call_function_single(drvdata->cpu, etm_disable_hw, drvdata, 1);
-	drvdata->enable = false;
 
 	spin_unlock(&drvdata->spinlock);
 	put_online_cpus();
@@ -413,6 +438,33 @@ static void etm_disable(struct coresight_device *csdev)
 	dev_info(drvdata->dev, "ETM tracing disabled\n");
 }
 
+static void etm_disable(struct coresight_device *csdev)
+{
+	u32 mode;
+	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	/*
+	 * For as long as the tracer isn't disabled another entity can't
+	 * change its status.  As such we can read the status here without
+	 * fearing it will change under us.
+	 */
+	mode = local_read(&drvdata->mode);
+
+	switch (mode) {
+	case CS_MODE_DISABLED:
+		break;
+	case CS_MODE_SYSFS:
+		etm_disable_sysfs(csdev);
+		break;
+	default:
+		WARN_ON_ONCE(mode);
+		return;
+	}
+
+	if (mode)
+		local_set(&drvdata->mode, CS_MODE_DISABLED);
+}
+
 static const struct coresight_ops_source etm_source_ops = {
 	.cpu_id		= etm_cpu_id,
 	.trace_id	= etm_trace_id,
@@ -440,7 +492,7 @@ static int etm_cpu_callback(struct notifier_block *nfb, unsigned long action,
 			etmdrvdata[cpu]->os_unlock = true;
 		}
 
-		if (etmdrvdata[cpu]->enable)
+		if (local_read(&etmdrvdata[cpu]->mode))
 			etm_enable_hw(etmdrvdata[cpu]);
 		spin_unlock(&etmdrvdata[cpu]->spinlock);
 		break;
@@ -453,7 +505,7 @@ static int etm_cpu_callback(struct notifier_block *nfb, unsigned long action,
 
 	case CPU_DYING:
 		spin_lock(&etmdrvdata[cpu]->spinlock);
-		if (etmdrvdata[cpu]->enable)
+		if (local_read(&etmdrvdata[cpu]->mode))
 			etm_disable_hw(etmdrvdata[cpu]);
 		spin_unlock(&etmdrvdata[cpu]->spinlock);
 		break;
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index c2f518fbc9a8..0026092fec7f 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -187,7 +187,7 @@ static void etm4_enable_hw(void *info)
 	dev_dbg(drvdata->dev, "cpu: %d enable smp call done\n", drvdata->cpu);
 }
 
-static int etm4_enable(struct coresight_device *csdev)
+static int etm4_enable(struct coresight_device *csdev, u32 mode)
 {
 	struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	int ret;
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 14f245a2018d..ed116b303e87 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -34,6 +34,12 @@
 #define TIMEOUT_US		100
 #define BMVAL(val, lsb, msb)	((val & GENMASK(msb, lsb)) >> lsb)
 
+enum cs_mode {
+	CS_MODE_DISABLED,
+	CS_MODE_SYSFS,
+	CS_MODE_PERF,
+};
+
 static inline void CS_LOCK(void __iomem *addr)
 {
 	do {
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 6b44928c1076..b20afb709141 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -222,7 +222,7 @@ static void coresight_disable_link(struct coresight_device *csdev,
 	csdev->enable = false;
 }
 
-static int coresight_enable_source(struct coresight_device *csdev)
+static int coresight_enable_source(struct coresight_device *csdev, u32 mode)
 {
 	int ret;
 
@@ -234,7 +234,7 @@ static int coresight_enable_source(struct coresight_device *csdev)
 
 	if (!csdev->enable) {
 		if (source_ops(csdev)->enable) {
-			ret = source_ops(csdev)->enable(csdev);
+			ret = source_ops(csdev)->enable(csdev, mode);
 			if (ret)
 				return ret;
 		}
@@ -458,7 +458,7 @@ int coresight_enable(struct coresight_device *csdev)
 	if (ret)
 		goto err_path;
 
-	ret = coresight_enable_source(csdev);
+	ret = coresight_enable_source(csdev, CS_MODE_SYSFS);
 	if (ret)
 		goto err_source;
 
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 851ecb22397e..61dfb8d511ea 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -213,7 +213,7 @@ struct coresight_ops_link {
 struct coresight_ops_source {
 	int (*cpu_id)(struct coresight_device *csdev);
 	int (*trace_id)(struct coresight_device *csdev);
-	int (*enable)(struct coresight_device *csdev);
+	int (*enable)(struct coresight_device *csdev, u32 mode);
 	void (*disable)(struct coresight_device *csdev);
 };
 
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb  3 10:39:11 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:11 -0700
Subject: [PATCH V9 13/18] coresight: etm3x: implementing perf_enable/disable()
 API
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-14-git-send-email-mathieu.poirier@linaro.org>

That way traces can be enabled and disabled automatically
from the Perf subystem using the PMU abstraction.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/Kconfig           |  1 +
 drivers/hwtracing/coresight/coresight-etm3x.c | 95 +++++++++++++++++++++++++--
 drivers/hwtracing/coresight/coresight-etm4x.c |  4 +-
 drivers/hwtracing/coresight/coresight.c       |  2 +-
 include/linux/coresight.h                     |  6 +-
 5 files changed, 99 insertions(+), 9 deletions(-)

diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
index c85935f3525a..db0541031c72 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -4,6 +4,7 @@
 menuconfig CORESIGHT
 	bool "CoreSight Tracing Support"
 	select ARM_AMBA
+	select PERF_EVENTS
 	help
 	  This framework provides a kernel interface for the CoreSight debug
 	  and trace drivers to register themselves with. It's intended to build
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index c82d545e68ef..a9b820ec16aa 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -31,6 +31,7 @@
 #include <linux/seq_file.h>
 #include <linux/uaccess.h>
 #include <linux/clk.h>
+#include <linux/perf_event.h>
 #include <asm/sections.h>
 
 #include "coresight-etm.h"
@@ -297,6 +298,47 @@ void etm_config_trace_mode(struct etm_config *config)
 	config->addr_type[1] = ETM_ADDR_TYPE_RANGE;
 }
 
+#define ETM3X_SUPPORTED_OPTIONS (ETMCR_CYC_ACC | ETMCR_TIMESTAMP_EN)
+
+static int etm_parse_event_config(struct etm_drvdata *drvdata,
+				  struct perf_event_attr *attr)
+{
+	struct etm_config *config = &drvdata->config;
+
+	if (!attr)
+		return -EINVAL;
+
+	/* Clear configuration from previous run */
+	memset(config, 0, sizeof(struct etm_config));
+
+	if (attr->exclude_kernel)
+		config->mode = ETM_MODE_EXCL_KERN;
+
+	if (attr->exclude_user)
+		config->mode = ETM_MODE_EXCL_USER;
+
+	/* Always start from the default config */
+	etm_set_default(config);
+
+	/*
+	 * By default the tracers are configured to trace the whole address
+	 * range.  Narrow the field only if requested by user space.
+	 */
+	if (config->mode)
+		etm_config_trace_mode(config);
+
+	/*
+	 * At this time only cycle accurate and timestamp options are
+	 * available.
+	 */
+	if (attr->config & ~ETM3X_SUPPORTED_OPTIONS)
+		return -EINVAL;
+
+	config->ctrl = attr->config;
+
+	return 0;
+}
+
 static void etm_enable_hw(void *info)
 {
 	int i;
@@ -316,8 +358,10 @@ static void etm_enable_hw(void *info)
 	etm_set_prog(drvdata);
 
 	etmcr = etm_readl(drvdata, ETMCR);
-	etmcr &= (ETMCR_PWD_DWN | ETMCR_ETM_PRG);
+	/* Clear setting from a previous run if need be */
+	etmcr &= ~ETM3X_SUPPORTED_OPTIONS;
 	etmcr |= drvdata->port_size;
+	etmcr |= ETMCR_ETM_EN;
 	etm_writel(drvdata, config->ctrl | etmcr, ETMCR);
 	etm_writel(drvdata, config->trigger_event, ETMTRIGGER);
 	etm_writel(drvdata, config->startstop_ctrl, ETMTSSCR);
@@ -357,9 +401,6 @@ static void etm_enable_hw(void *info)
 	/* No VMID comparator value selected */
 	etm_writel(drvdata, 0x0, ETMVMIDCVR);
 
-	/* Ensures trace output is enabled from this ETM */
-	etm_writel(drvdata, config->ctrl | ETMCR_ETM_EN | etmcr, ETMCR);
-
 	etm_clr_prog(drvdata);
 	CS_LOCK(drvdata->base);
 
@@ -407,6 +448,22 @@ static int etm_trace_id(struct coresight_device *csdev)
 	return etm_get_trace_id(drvdata);
 }
 
+static int etm_enable_perf(struct coresight_device *csdev,
+			   struct perf_event_attr *attr)
+{
+	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	if (WARN_ON_ONCE(drvdata->cpu != smp_processor_id()))
+		return -EINVAL;
+
+	/* Configure the tracer based on the session's specifics */
+	etm_parse_event_config(drvdata, attr);
+	/* And enable it */
+	etm_enable_hw(drvdata);
+
+	return 0;
+}
+
 static int etm_enable_sysfs(struct coresight_device *csdev)
 {
 	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
@@ -437,7 +494,8 @@ err:
 	return ret;
 }
 
-static int etm_enable(struct coresight_device *csdev, u32 mode)
+static int etm_enable(struct coresight_device *csdev,
+		      struct perf_event_attr *attr, u32 mode)
 {
 	int ret;
 	u32 val;
@@ -453,6 +511,9 @@ static int etm_enable(struct coresight_device *csdev, u32 mode)
 	case CS_MODE_SYSFS:
 		ret = etm_enable_sysfs(csdev);
 		break;
+	case CS_MODE_PERF:
+		ret = etm_enable_perf(csdev, attr);
+		break;
 	default:
 		ret = -EINVAL;
 	}
@@ -485,6 +546,27 @@ static void etm_disable_hw(void *info)
 	dev_dbg(drvdata->dev, "cpu: %d disable smp call done\n", drvdata->cpu);
 }
 
+static void etm_disable_perf(struct coresight_device *csdev)
+{
+	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	if (WARN_ON_ONCE(drvdata->cpu != smp_processor_id()))
+		return;
+
+	CS_UNLOCK(drvdata->base);
+
+	/* Setting the prog bit disables tracing immediately */
+	etm_set_prog(drvdata);
+
+	/*
+	 * There is no way to know when the tracer will be used again so
+	 * power down the tracer.
+	 */
+	etm_set_pwrdwn(drvdata);
+
+	CS_LOCK(drvdata->base);
+}
+
 static void etm_disable_sysfs(struct coresight_device *csdev)
 {
 	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
@@ -528,6 +610,9 @@ static void etm_disable(struct coresight_device *csdev)
 	case CS_MODE_SYSFS:
 		etm_disable_sysfs(csdev);
 		break;
+	case CS_MODE_PERF:
+		etm_disable_perf(csdev);
+		break;
 	default:
 		WARN_ON_ONCE(mode);
 		return;
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index 0026092fec7f..d0169ba7fbf2 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -32,6 +32,7 @@
 #include <linux/seq_file.h>
 #include <linux/uaccess.h>
 #include <linux/pm_runtime.h>
+#include <linux/perf_event.h>
 #include <asm/sections.h>
 
 #include "coresight-etm4x.h"
@@ -187,7 +188,8 @@ static void etm4_enable_hw(void *info)
 	dev_dbg(drvdata->dev, "cpu: %d enable smp call done\n", drvdata->cpu);
 }
 
-static int etm4_enable(struct coresight_device *csdev, u32 mode)
+static int etm4_enable(struct coresight_device *csdev,
+		       struct perf_event_attr *attr, u32 mode)
 {
 	struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	int ret;
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index b20afb709141..95cccb179763 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -234,7 +234,7 @@ static int coresight_enable_source(struct coresight_device *csdev, u32 mode)
 
 	if (!csdev->enable) {
 		if (source_ops(csdev)->enable) {
-			ret = source_ops(csdev)->enable(csdev, mode);
+			ret = source_ops(csdev)->enable(csdev, NULL, mode);
 			if (ret)
 				return ret;
 		}
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 61dfb8d511ea..6801dd64ee5d 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -14,6 +14,7 @@
 #define _LINUX_CORESIGHT_H
 
 #include <linux/device.h>
+#include <linux/perf_event.h>
 #include <linux/sched.h>
 
 /* Peripheral id registers (0xFD0-0xFEC) */
@@ -206,14 +207,15 @@ struct coresight_ops_link {
  * @cpu_id:	returns the value of the CPU number this component
  *		is associated to.
  * @trace_id:	returns the value of the component's trace ID as known
-		to the HW.
+ *		to the HW.
  * @enable:	enables tracing for a source.
  * @disable:	disables tracing for a source.
  */
 struct coresight_ops_source {
 	int (*cpu_id)(struct coresight_device *csdev);
 	int (*trace_id)(struct coresight_device *csdev);
-	int (*enable)(struct coresight_device *csdev, u32 mode);
+	int (*enable)(struct coresight_device *csdev,
+		      struct perf_event_attr *attr,  u32 mode);
 	void (*disable)(struct coresight_device *csdev);
 };
 
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb  3 10:39:14 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:14 -0700
Subject: [PATCH V9 16/18] coresight: etb10: implementing AUX API
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-17-git-send-email-mathieu.poirier@linaro.org>

Adding an ETB10 specific AUX area operations to be used
by the perf framework when events are initialised.

Part of this operation involves modeling the mmap'ed area
based on the specific ways a sink buffer gathers information.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etb10.c | 234 ++++++++++++++++++++++++++
 include/linux/coresight.h                     |  21 ++-
 2 files changed, 253 insertions(+), 2 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 79099f95ba3f..a2eb6bdeaafa 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -28,6 +28,11 @@
 #include <linux/coresight.h>
 #include <linux/amba/bus.h>
 #include <linux/clk.h>
+#include <linux/circ_buf.h>
+#include <linux/mm.h>
+#include <linux/perf_event.h>
+
+#include <asm/local.h>
 
 #include "coresight-priv.h"
 
@@ -65,6 +70,26 @@
 #define ETB_FRAME_SIZE_WORDS	4
 
 /**
+ * struct cs_buffer - keep track of a recording session' specifics
+ * @cur:	index of the current buffer
+ * @nr_pages:	max number of pages granted to us
+ * @offset:	offset within the current buffer
+ * @data_size:	how much we collected in this run
+ * @lost:	other than zero if we had a HW buffer wrap around
+ * @snapshot:	is this run in snapshot mode
+ * @data_pages:	a handle the ring buffer
+ */
+struct cs_buffers {
+	unsigned int		cur;
+	unsigned int		nr_pages;
+	unsigned long		offset;
+	local_t			data_size;
+	local_t			lost;
+	bool			snapshot;
+	void			**data_pages;
+};
+
+/**
  * struct etb_drvdata - specifics associated to an ETB component
  * @base:	memory mapped base address for this component.
  * @dev:	the device entity associated to this component.
@@ -265,9 +290,218 @@ static void etb_disable(struct coresight_device *csdev)
 	dev_info(drvdata->dev, "ETB disabled\n");
 }
 
+static void *etb_alloc_buffer(struct coresight_device *csdev, int cpu,
+			      void **pages, int nr_pages, bool overwrite)
+{
+	int node;
+	struct cs_buffers *buf;
+
+	if (cpu == -1)
+		cpu = smp_processor_id();
+	node = cpu_to_node(cpu);
+
+	buf = kzalloc_node(sizeof(struct cs_buffers), GFP_KERNEL, node);
+	if (!buf)
+		return NULL;
+
+	buf->snapshot = overwrite;
+	buf->nr_pages = nr_pages;
+	buf->data_pages = pages;
+
+	return buf;
+}
+
+static void etb_free_buffer(void *config)
+{
+	struct cs_buffers *buf = config;
+
+	kfree(buf);
+}
+
+static int etb_set_buffer(struct coresight_device *csdev,
+			  struct perf_output_handle *handle,
+			  void *sink_config)
+{
+	int ret = 0;
+	unsigned long head;
+	struct cs_buffers *buf = sink_config;
+
+	/* wrap head around to the amount of space we have */
+	head = handle->head & ((buf->nr_pages << PAGE_SHIFT) - 1);
+
+	/* find the page to write to */
+	buf->cur = head / PAGE_SIZE;
+
+	/* and offset within that page */
+	buf->offset = head % PAGE_SIZE;
+
+	local_set(&buf->data_size, 0);
+
+	return ret;
+}
+
+static unsigned long etb_reset_buffer(struct coresight_device *csdev,
+				      struct perf_output_handle *handle,
+				      void *sink_config, bool *lost)
+{
+	unsigned long size = 0;
+	struct cs_buffers *buf = sink_config;
+
+	if (buf) {
+		/*
+		 * In snapshot mode ->data_size holds the new address of the
+		 * ring buffer's head.  The size itself is the whole address
+		 * range since we want the latest information.
+		 */
+		if (buf->snapshot)
+			handle->head = local_xchg(&buf->data_size,
+						  buf->nr_pages << PAGE_SHIFT);
+
+		/*
+		 * Tell the tracer PMU how much we got in this run and if
+		 * something went wrong along the way.  Nobody else can use
+		 * this cs_buffers instance until we are done.  As such
+		 * resetting parameters here and squaring off with the ring
+		 * buffer API in the tracer PMU is fine.
+		 */
+		*lost = !!local_xchg(&buf->lost, 0);
+		size = local_xchg(&buf->data_size, 0);
+	}
+
+	return size;
+}
+
+static void etb_update_buffer(struct coresight_device *csdev,
+			      struct perf_output_handle *handle,
+			      void *sink_config)
+{
+	int i, cur;
+	u8 *buf_ptr;
+	u32 read_ptr, write_ptr, capacity;
+	u32 status, read_data, to_read;
+	unsigned long offset;
+	struct cs_buffers *buf = sink_config;
+	struct etb_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	if (!buf)
+		return;
+
+	capacity = drvdata->buffer_depth * ETB_FRAME_SIZE_WORDS;
+
+	CS_UNLOCK(drvdata->base);
+	etb_disable_hw(drvdata);
+
+	/* unit is in words, not bytes */
+	read_ptr = readl_relaxed(drvdata->base + ETB_RAM_READ_POINTER);
+	write_ptr = readl_relaxed(drvdata->base + ETB_RAM_WRITE_POINTER);
+
+	/*
+	 * Entries should be aligned to the frame size.  If they are not
+	 * go back to the last alignement point to give decoding tools a
+	 * chance to fix things.
+	 */
+	if (write_ptr % ETB_FRAME_SIZE_WORDS) {
+		dev_err(drvdata->dev,
+			"write_ptr: %lu not aligned to formatter frame size\n",
+			(unsigned long)write_ptr);
+
+		write_ptr &= ~(ETB_FRAME_SIZE_WORDS - 1);
+		local_inc(&buf->lost);
+	}
+
+	/*
+	 * Get a hold of the status register and see if a wrap around
+	 * has occurred.  If so adjust things accordingly.  Otherwise
+	 * start at the beginning and go until the write pointer has
+	 * been reached.
+	 */
+	status = readl_relaxed(drvdata->base + ETB_STATUS_REG);
+	if (status & ETB_STATUS_RAM_FULL) {
+		local_inc(&buf->lost);
+		to_read = capacity;
+		read_ptr = write_ptr;
+	} else {
+		to_read = CIRC_CNT(write_ptr, read_ptr, drvdata->buffer_depth);
+		to_read *= ETB_FRAME_SIZE_WORDS;
+	}
+
+	/*
+	 * Make sure we don't overwrite data that hasn't been consumed yet.
+	 * It is entirely possible that the HW buffer has more data than the
+	 * ring buffer can currently handle.  If so adjust the start address
+	 * to take only the last traces.
+	 *
+	 * In snapshot mode we are looking to get the latest traces only and as
+	 * such, we don't care about not overwriting data that hasn't been
+	 * processed by user space.
+	 */
+	if (!buf->snapshot && to_read > handle->size) {
+		u32 mask = ~(ETB_FRAME_SIZE_WORDS - 1);
+
+		/* The new read pointer must be frame size aligned */
+		to_read -= handle->size & mask;
+		/*
+		 * Move the RAM read pointer up, keeping in mind that
+		 * everything is in frame size units.
+		 */
+		read_ptr = (write_ptr + drvdata->buffer_depth) -
+					to_read / ETB_FRAME_SIZE_WORDS;
+		/* Wrap around if need be*/
+		read_ptr &= ~(drvdata->buffer_depth - 1);
+		/* let the decoder know we've skipped ahead */
+		local_inc(&buf->lost);
+	}
+
+	/* finally tell HW where we want to start reading from */
+	writel_relaxed(read_ptr, drvdata->base + ETB_RAM_READ_POINTER);
+
+	cur = buf->cur;
+	offset = buf->offset;
+	for (i = 0; i < to_read; i += 4) {
+		buf_ptr = buf->data_pages[cur] + offset;
+		read_data = readl_relaxed(drvdata->base +
+					  ETB_RAM_READ_DATA_REG);
+		*buf_ptr++ = read_data >> 0;
+		*buf_ptr++ = read_data >> 8;
+		*buf_ptr++ = read_data >> 16;
+		*buf_ptr++ = read_data >> 24;
+
+		offset += 4;
+		if (offset >= PAGE_SIZE) {
+			offset = 0;
+			cur++;
+			/* wrap around at the end of the buffer */
+			cur &= buf->nr_pages - 1;
+		}
+	}
+
+	/* reset ETB buffer for next run */
+	writel_relaxed(0x0, drvdata->base + ETB_RAM_READ_POINTER);
+	writel_relaxed(0x0, drvdata->base + ETB_RAM_WRITE_POINTER);
+
+	/*
+	 * In snapshot mode all we have to do is communicate to
+	 * perf_aux_output_end() the address of the current head.  In full
+	 * trace mode the same function expects a size to move rb->aux_head
+	 * forward.
+	 */
+	if (buf->snapshot)
+		local_set(&buf->data_size, (cur * PAGE_SIZE) + offset);
+	else
+		local_add(to_read, &buf->data_size);
+
+	etb_enable_hw(drvdata);
+	CS_LOCK(drvdata->base);
+}
+
 static const struct coresight_ops_sink etb_sink_ops = {
 	.enable		= etb_enable,
 	.disable	= etb_disable,
+	.alloc_buffer	= etb_alloc_buffer,
+	.free_buffer	= etb_free_buffer,
+	.set_buffer	= etb_set_buffer,
+	.reset_buffer	= etb_reset_buffer,
+	.update_buffer	= etb_update_buffer,
 };
 
 static const struct coresight_ops etb_cs_ops = {
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 9fa92dcdd2ea..385d62e64abb 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -182,12 +182,29 @@ struct coresight_device {
 /**
  * struct coresight_ops_sink - basic operations for a sink
  * Operations available for sinks
- * @enable:	enables the sink.
- * @disable:	disables the sink.
+ * @enable:		enables the sink.
+ * @disable:		disables the sink.
+ * @alloc_buffer:	initialises perf's ring buffer for trace collection.
+ * @free_buffer:	release memory allocated in @get_config.
+ * @set_buffer:		initialises buffer mechanic before a trace session.
+ * @reset_buffer:	finalises buffer mechanic after a trace session.
+ * @update_buffer:	update buffer pointers after a trace session.
  */
 struct coresight_ops_sink {
 	int (*enable)(struct coresight_device *csdev, u32 mode);
 	void (*disable)(struct coresight_device *csdev);
+	void *(*alloc_buffer)(struct coresight_device *csdev, int cpu,
+			      void **pages, int nr_pages, bool overwrite);
+	void (*free_buffer)(void *config);
+	int (*set_buffer)(struct coresight_device *csdev,
+			  struct perf_output_handle *handle,
+			  void *sink_config);
+	unsigned long (*reset_buffer)(struct coresight_device *csdev,
+				      struct perf_output_handle *handle,
+				      void *sink_config, bool *lost);
+	void (*update_buffer)(struct coresight_device *csdev,
+			      struct perf_output_handle *handle,
+			      void *sink_config);
 };
 
 /**
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb  3 10:39:05 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:05 -0700
Subject: [PATCH V9 07/18] coresight: etm3x: splitting struct etm_drvdata
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-8-git-send-email-mathieu.poirier@linaro.org>

Splitting "etm_drvdata" in two sections, one for the HW specific
data and another for user configuration.

That way it is easier to manipulate and zero out the configuration
data when more than one concurrent tracing session configuration
is active.

Also taking care of up-lifting all the code affected by this new
arrangement.  No loss or gain of functionality (other than what is
mentioned above) is introduced by this patch.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm.h        | 102 ++++----
 .../hwtracing/coresight/coresight-etm3x-sysfs.c    | 290 ++++++++++++---------
 drivers/hwtracing/coresight/coresight-etm3x.c      | 153 +++++------
 3 files changed, 305 insertions(+), 240 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
index 9a30aa392ed9..371fb7d2e829 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -136,29 +136,9 @@
 #define ETM_DEFAULT_EVENT_VAL	(ETM_HARD_WIRE_RES_A	|	\
 				 ETM_ADD_COMP_0		|	\
 				 ETM_EVENT_NOT_A)
+
 /**
- * struct etm_drvdata - specifics associated to an ETM component
- * @base:	memory mapped base address for this component.
- * @dev:	the device entity associated to this component.
- * @atclk:	optional clock for the core parts of the ETM.
- * @csdev:	component vitals needed by the framework.
- * @spinlock:	only one at a time pls.
- * @cpu:	the cpu this component is affined to.
- * @port_size:	port size as reported by ETMCR bit 4-6 and 21.
- * @arch:	ETM/PTM version number.
- * @use_cpu14:	true if management registers need to be accessed via CP14.
- * @enable:	is this ETM/PTM currently tracing.
- * @sticky_enable: true if ETM base configuration has been done.
- * @boot_enable:true if we should start tracing at boot time.
- * @os_unlock:	true if access to management registers is allowed.
- * @nr_addr_cmp:Number of pairs of address comparators as found in ETMCCR.
- * @nr_cntr:	Number of counters as found in ETMCCR bit 13-15.
- * @nr_ext_inp:	Number of external input as found in ETMCCR bit 17-19.
- * @nr_ext_out:	Number of external output as found in ETMCCR bit 20-22.
- * @nr_ctxid_cmp: Number of contextID comparators as found in ETMCCR bit 24-25.
- * @etmccr:	value of register ETMCCR.
- * @etmccer:	value of register ETMCCER.
- * @traceid:	value of the current ID for this component.
+ * struct etm_config - configuration information related to an ETM
  * @mode:	controls various modes supported by this ETM/PTM.
  * @ctrl:	used in conjunction with @mode.
  * @trigger_event: setting for register ETMTRIGGER.
@@ -189,30 +169,9 @@
  * @ctxid_mask: mask applicable to all the context IDs.
  * @sync_freq:	Synchronisation frequency.
  * @timestamp_event: Defines an event that requests the insertion
-		     of a timestamp into the trace stream.
+ *		     of a timestamp into the trace stream.
  */
-struct etm_drvdata {
-	void __iomem			*base;
-	struct device			*dev;
-	struct clk			*atclk;
-	struct coresight_device		*csdev;
-	spinlock_t			spinlock;
-	int				cpu;
-	int				port_size;
-	u8				arch;
-	bool				use_cp14;
-	bool				enable;
-	bool				sticky_enable;
-	bool				boot_enable;
-	bool				os_unlock;
-	u8				nr_addr_cmp;
-	u8				nr_cntr;
-	u8				nr_ext_inp;
-	u8				nr_ext_out;
-	u8				nr_ctxid_cmp;
-	u32				etmccr;
-	u32				etmccer;
-	u32				traceid;
+struct etm_config {
 	u32				mode;
 	u32				ctrl;
 	u32				trigger_event;
@@ -244,6 +203,56 @@ struct etm_drvdata {
 	u32				timestamp_event;
 };
 
+/**
+ * struct etm_drvdata - specifics associated to an ETM component
+ * @base:	memory mapped base address for this component.
+ * @dev:	the device entity associated to this component.
+ * @atclk:	optional clock for the core parts of the ETM.
+ * @csdev:	component vitals needed by the framework.
+ * @spinlock:	only one at a time pls.
+ * @cpu:	the cpu this component is affined to.
+ * @port_size:	port size as reported by ETMCR bit 4-6 and 21.
+ * @arch:	ETM/PTM version number.
+ * @use_cpu14:	true if management registers need to be accessed via CP14.
+ * @enable:	is this ETM/PTM currently tracing.
+ * @sticky_enable: true if ETM base configuration has been done.
+ * @boot_enable:true if we should start tracing at boot time.
+ * @os_unlock:	true if access to management registers is allowed.
+ * @nr_addr_cmp:Number of pairs of address comparators as found in ETMCCR.
+ * @nr_cntr:	Number of counters as found in ETMCCR bit 13-15.
+ * @nr_ext_inp:	Number of external input as found in ETMCCR bit 17-19.
+ * @nr_ext_out:	Number of external output as found in ETMCCR bit 20-22.
+ * @nr_ctxid_cmp: Number of contextID comparators as found in ETMCCR bit 24-25.
+ * @etmccr:	value of register ETMCCR.
+ * @etmccer:	value of register ETMCCER.
+ * @traceid:	value of the current ID for this component.
+ * @config:	structure holding configuration parameters.
+ */
+struct etm_drvdata {
+	void __iomem			*base;
+	struct device			*dev;
+	struct clk			*atclk;
+	struct coresight_device		*csdev;
+	spinlock_t			spinlock;
+	int				cpu;
+	int				port_size;
+	u8				arch;
+	bool				use_cp14;
+	bool				enable;
+	bool				sticky_enable;
+	bool				boot_enable;
+	bool				os_unlock;
+	u8				nr_addr_cmp;
+	u8				nr_cntr;
+	u8				nr_ext_inp;
+	u8				nr_ext_out;
+	u8				nr_ctxid_cmp;
+	u32				etmccr;
+	u32				etmccer;
+	u32				traceid;
+	struct etm_config		config;
+};
+
 enum etm_addr_type {
 	ETM_ADDR_TYPE_NONE,
 	ETM_ADDR_TYPE_SINGLE,
@@ -283,5 +292,6 @@ static inline unsigned int etm_readl(struct etm_drvdata *drvdata, u32 off)
 
 extern const struct attribute_group *coresight_etm_groups[];
 int etm_get_trace_id(struct etm_drvdata *drvdata);
-void etm_set_default(struct etm_drvdata *drvdata);
+void etm_set_default(struct etm_config *config);
+struct etm_config *get_etm_config(struct etm_drvdata *drvdata);
 #endif
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
index f409f5a88e95..456df2378a6f 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
@@ -78,6 +78,7 @@ static ssize_t reset_store(struct device *dev,
 	int i, ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
@@ -85,19 +86,14 @@ static ssize_t reset_store(struct device *dev,
 
 	if (val) {
 		spin_lock(&drvdata->spinlock);
-		drvdata->mode = ETM_MODE_EXCLUDE;
-		drvdata->ctrl = 0x0;
-		drvdata->trigger_event = ETM_DEFAULT_EVENT_VAL;
-		drvdata->startstop_ctrl = 0x0;
-		drvdata->addr_idx = 0x0;
+		memset(config, 0, sizeof(struct etm_config));
+		config->mode = ETM_MODE_EXCLUDE;
+		config->trigger_event = ETM_DEFAULT_EVENT_VAL;
 		for (i = 0; i < drvdata->nr_addr_cmp; i++) {
-			drvdata->addr_val[i] = 0x0;
-			drvdata->addr_acctype[i] = 0x0;
-			drvdata->addr_type[i] = ETM_ADDR_TYPE_NONE;
+			config->addr_type[i] = ETM_ADDR_TYPE_NONE;
 		}
-		drvdata->cntr_idx = 0x0;
 
-		etm_set_default(drvdata);
+		etm_set_default(config);
 		spin_unlock(&drvdata->spinlock);
 	}
 
@@ -110,8 +106,9 @@ static ssize_t mode_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->mode;
+	val = config->mode;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -122,48 +119,49 @@ static ssize_t mode_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	drvdata->mode = val & ETM_MODE_ALL;
+	config->mode = val & ETM_MODE_ALL;
 
-	if (drvdata->mode & ETM_MODE_EXCLUDE)
-		drvdata->enable_ctrl1 |= ETMTECR1_INC_EXC;
+	if (config->mode & ETM_MODE_EXCLUDE)
+		config->enable_ctrl1 |= ETMTECR1_INC_EXC;
 	else
-		drvdata->enable_ctrl1 &= ~ETMTECR1_INC_EXC;
+		config->enable_ctrl1 &= ~ETMTECR1_INC_EXC;
 
-	if (drvdata->mode & ETM_MODE_CYCACC)
-		drvdata->ctrl |= ETMCR_CYC_ACC;
+	if (config->mode & ETM_MODE_CYCACC)
+		config->ctrl |= ETMCR_CYC_ACC;
 	else
-		drvdata->ctrl &= ~ETMCR_CYC_ACC;
+		config->ctrl &= ~ETMCR_CYC_ACC;
 
-	if (drvdata->mode & ETM_MODE_STALL) {
+	if (config->mode & ETM_MODE_STALL) {
 		if (!(drvdata->etmccr & ETMCCR_FIFOFULL)) {
 			dev_warn(drvdata->dev, "stall mode not supported\n");
 			ret = -EINVAL;
 			goto err_unlock;
 		}
-		drvdata->ctrl |= ETMCR_STALL_MODE;
+		config->ctrl |= ETMCR_STALL_MODE;
 	 } else
-		drvdata->ctrl &= ~ETMCR_STALL_MODE;
+		config->ctrl &= ~ETMCR_STALL_MODE;
 
-	if (drvdata->mode & ETM_MODE_TIMESTAMP) {
+	if (config->mode & ETM_MODE_TIMESTAMP) {
 		if (!(drvdata->etmccer & ETMCCER_TIMESTAMP)) {
 			dev_warn(drvdata->dev, "timestamp not supported\n");
 			ret = -EINVAL;
 			goto err_unlock;
 		}
-		drvdata->ctrl |= ETMCR_TIMESTAMP_EN;
+		config->ctrl |= ETMCR_TIMESTAMP_EN;
 	} else
-		drvdata->ctrl &= ~ETMCR_TIMESTAMP_EN;
+		config->ctrl &= ~ETMCR_TIMESTAMP_EN;
 
-	if (drvdata->mode & ETM_MODE_CTXID)
-		drvdata->ctrl |= ETMCR_CTXID_SIZE;
+	if (config->mode & ETM_MODE_CTXID)
+		config->ctrl |= ETMCR_CTXID_SIZE;
 	else
-		drvdata->ctrl &= ~ETMCR_CTXID_SIZE;
+		config->ctrl &= ~ETMCR_CTXID_SIZE;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -179,8 +177,9 @@ static ssize_t trigger_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->trigger_event;
+	val = config->trigger_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -191,12 +190,13 @@ static ssize_t trigger_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->trigger_event = val & ETM_EVENT_MASK;
+	config->trigger_event = val & ETM_EVENT_MASK;
 
 	return size;
 }
@@ -207,8 +207,9 @@ static ssize_t enable_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->enable_event;
+	val = config->enable_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -219,12 +220,13 @@ static ssize_t enable_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->enable_event = val & ETM_EVENT_MASK;
+	config->enable_event = val & ETM_EVENT_MASK;
 
 	return size;
 }
@@ -235,8 +237,9 @@ static ssize_t fifofull_level_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->fifofull_level;
+	val = config->fifofull_level;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -247,12 +250,13 @@ static ssize_t fifofull_level_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->fifofull_level = val;
+	config->fifofull_level = val;
 
 	return size;
 }
@@ -263,8 +267,9 @@ static ssize_t addr_idx_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->addr_idx;
+	val = config->addr_idx;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -275,6 +280,7 @@ static ssize_t addr_idx_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
@@ -288,7 +294,7 @@ static ssize_t addr_idx_store(struct device *dev,
 	 * dereferenced multiple times within a spinlock block elsewhere.
 	 */
 	spin_lock(&drvdata->spinlock);
-	drvdata->addr_idx = val;
+	config->addr_idx = val;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -301,16 +307,17 @@ static ssize_t addr_single_show(struct device *dev,
 	u8 idx;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
+	idx = config->addr_idx;
+	if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      config->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
 		spin_unlock(&drvdata->spinlock);
 		return -EINVAL;
 	}
 
-	val = drvdata->addr_val[idx];
+	val = config->addr_val[idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -324,21 +331,22 @@ static ssize_t addr_single_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
+	idx = config->addr_idx;
+	if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      config->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
 		spin_unlock(&drvdata->spinlock);
 		return -EINVAL;
 	}
 
-	drvdata->addr_val[idx] = val;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_SINGLE;
+	config->addr_val[idx] = val;
+	config->addr_type[idx] = ETM_ADDR_TYPE_SINGLE;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -351,23 +359,24 @@ static ssize_t addr_range_show(struct device *dev,
 	u8 idx;
 	unsigned long val1, val2;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
+	idx = config->addr_idx;
 	if (idx % 2 != 0) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
-	if (!((drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
-	      (drvdata->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
+	if (!((config->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
+	       config->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
+	      (config->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
+	       config->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
 
-	val1 = drvdata->addr_val[idx];
-	val2 = drvdata->addr_val[idx + 1];
+	val1 = config->addr_val[idx];
+	val2 = config->addr_val[idx + 1];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx %#lx\n", val1, val2);
@@ -380,6 +389,7 @@ static ssize_t addr_range_store(struct device *dev,
 	u8 idx;
 	unsigned long val1, val2;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	if (sscanf(buf, "%lx %lx", &val1, &val2) != 2)
 		return -EINVAL;
@@ -388,24 +398,24 @@ static ssize_t addr_range_store(struct device *dev,
 		return -EINVAL;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
+	idx = config->addr_idx;
 	if (idx % 2 != 0) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
-	if (!((drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
-	      (drvdata->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
+	if (!((config->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
+	       config->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
+	      (config->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
+	       config->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
 
-	drvdata->addr_val[idx] = val1;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_RANGE;
-	drvdata->addr_val[idx + 1] = val2;
-	drvdata->addr_type[idx + 1] = ETM_ADDR_TYPE_RANGE;
-	drvdata->enable_ctrl1 |= (1 << (idx/2));
+	config->addr_val[idx] = val1;
+	config->addr_type[idx] = ETM_ADDR_TYPE_RANGE;
+	config->addr_val[idx + 1] = val2;
+	config->addr_type[idx + 1] = ETM_ADDR_TYPE_RANGE;
+	config->enable_ctrl1 |= (1 << (idx/2));
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -418,16 +428,17 @@ static ssize_t addr_start_show(struct device *dev,
 	u8 idx;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_START)) {
+	idx = config->addr_idx;
+	if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      config->addr_type[idx] == ETM_ADDR_TYPE_START)) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
 
-	val = drvdata->addr_val[idx];
+	val = config->addr_val[idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -441,23 +452,24 @@ static ssize_t addr_start_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_START)) {
+	idx = config->addr_idx;
+	if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      config->addr_type[idx] == ETM_ADDR_TYPE_START)) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
 
-	drvdata->addr_val[idx] = val;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_START;
-	drvdata->startstop_ctrl |= (1 << idx);
-	drvdata->enable_ctrl1 |= BIT(25);
+	config->addr_val[idx] = val;
+	config->addr_type[idx] = ETM_ADDR_TYPE_START;
+	config->startstop_ctrl |= (1 << idx);
+	config->enable_ctrl1 |= BIT(25);
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -470,16 +482,17 @@ static ssize_t addr_stop_show(struct device *dev,
 	u8 idx;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
+	idx = config->addr_idx;
+	if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      config->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
 
-	val = drvdata->addr_val[idx];
+	val = config->addr_val[idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -493,23 +506,24 @@ static ssize_t addr_stop_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
+	idx = config->addr_idx;
+	if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      config->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
 
-	drvdata->addr_val[idx] = val;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_STOP;
-	drvdata->startstop_ctrl |= (1 << (idx + 16));
-	drvdata->enable_ctrl1 |= ETMTECR1_START_STOP;
+	config->addr_val[idx] = val;
+	config->addr_type[idx] = ETM_ADDR_TYPE_STOP;
+	config->startstop_ctrl |= (1 << (idx + 16));
+	config->enable_ctrl1 |= ETMTECR1_START_STOP;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -521,9 +535,10 @@ static ssize_t addr_acctype_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	val = drvdata->addr_acctype[drvdata->addr_idx];
+	val = config->addr_acctype[config->addr_idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -536,13 +551,14 @@ static ssize_t addr_acctype_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	drvdata->addr_acctype[drvdata->addr_idx] = val;
+	config->addr_acctype[config->addr_idx] = val;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -554,8 +570,9 @@ static ssize_t cntr_idx_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->cntr_idx;
+	val = config->cntr_idx;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -566,6 +583,7 @@ static ssize_t cntr_idx_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
@@ -578,7 +596,7 @@ static ssize_t cntr_idx_store(struct device *dev,
 	 * dereferenced multiple times within a spinlock block elsewhere.
 	 */
 	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_idx = val;
+	config->cntr_idx = val;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -590,9 +608,10 @@ static ssize_t cntr_rld_val_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	val = drvdata->cntr_rld_val[drvdata->cntr_idx];
+	val = config->cntr_rld_val[config->cntr_idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -605,13 +624,14 @@ static ssize_t cntr_rld_val_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_rld_val[drvdata->cntr_idx] = val;
+	config->cntr_rld_val[config->cntr_idx] = val;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -623,9 +643,10 @@ static ssize_t cntr_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	val = drvdata->cntr_event[drvdata->cntr_idx];
+	val = config->cntr_event[config->cntr_idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -638,13 +659,14 @@ static ssize_t cntr_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_event[drvdata->cntr_idx] = val & ETM_EVENT_MASK;
+	config->cntr_event[config->cntr_idx] = val & ETM_EVENT_MASK;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -656,9 +678,10 @@ static ssize_t cntr_rld_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	val = drvdata->cntr_rld_event[drvdata->cntr_idx];
+	val = config->cntr_rld_event[config->cntr_idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -671,13 +694,14 @@ static ssize_t cntr_rld_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_rld_event[drvdata->cntr_idx] = val & ETM_EVENT_MASK;
+	config->cntr_rld_event[config->cntr_idx] = val & ETM_EVENT_MASK;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -690,12 +714,13 @@ static ssize_t cntr_val_show(struct device *dev,
 	int i, ret = 0;
 	u32 val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	if (!drvdata->enable) {
 		spin_lock(&drvdata->spinlock);
 		for (i = 0; i < drvdata->nr_cntr; i++)
 			ret += sprintf(buf, "counter %d: %x\n",
-				       i, drvdata->cntr_val[i]);
+				       i, config->cntr_val[i]);
 		spin_unlock(&drvdata->spinlock);
 		return ret;
 	}
@@ -715,13 +740,14 @@ static ssize_t cntr_val_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_val[drvdata->cntr_idx] = val;
+	config->cntr_val[config->cntr_idx] = val;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -733,8 +759,9 @@ static ssize_t seq_12_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->seq_12_event;
+	val = config->seq_12_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -745,12 +772,13 @@ static ssize_t seq_12_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->seq_12_event = val & ETM_EVENT_MASK;
+	config->seq_12_event = val & ETM_EVENT_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(seq_12_event);
@@ -760,8 +788,9 @@ static ssize_t seq_21_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->seq_21_event;
+	val = config->seq_21_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -772,12 +801,13 @@ static ssize_t seq_21_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->seq_21_event = val & ETM_EVENT_MASK;
+	config->seq_21_event = val & ETM_EVENT_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(seq_21_event);
@@ -787,8 +817,9 @@ static ssize_t seq_23_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->seq_23_event;
+	val = config->seq_23_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -799,12 +830,13 @@ static ssize_t seq_23_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->seq_23_event = val & ETM_EVENT_MASK;
+	config->seq_23_event = val & ETM_EVENT_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(seq_23_event);
@@ -814,8 +846,9 @@ static ssize_t seq_31_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->seq_31_event;
+	val = config->seq_31_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -826,12 +859,13 @@ static ssize_t seq_31_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->seq_31_event = val & ETM_EVENT_MASK;
+	config->seq_31_event = val & ETM_EVENT_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(seq_31_event);
@@ -841,8 +875,9 @@ static ssize_t seq_32_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->seq_32_event;
+	val = config->seq_32_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -853,12 +888,13 @@ static ssize_t seq_32_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->seq_32_event = val & ETM_EVENT_MASK;
+	config->seq_32_event = val & ETM_EVENT_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(seq_32_event);
@@ -868,8 +904,9 @@ static ssize_t seq_13_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->seq_13_event;
+	val = config->seq_13_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -880,12 +917,13 @@ static ssize_t seq_13_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->seq_13_event = val & ETM_EVENT_MASK;
+	config->seq_13_event = val & ETM_EVENT_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(seq_13_event);
@@ -895,9 +933,10 @@ static ssize_t seq_curr_state_show(struct device *dev,
 {
 	unsigned long val, flags;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	if (!drvdata->enable) {
-		val = drvdata->seq_curr_state;
+		val = config->seq_curr_state;
 		goto out;
 	}
 
@@ -921,6 +960,7 @@ static ssize_t seq_curr_state_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
@@ -929,7 +969,7 @@ static ssize_t seq_curr_state_store(struct device *dev,
 	if (val > ETM_SEQ_STATE_MAX_VAL)
 		return -EINVAL;
 
-	drvdata->seq_curr_state = val;
+	config->seq_curr_state = val;
 
 	return size;
 }
@@ -940,8 +980,9 @@ static ssize_t ctxid_idx_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->ctxid_idx;
+	val = config->ctxid_idx;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -952,6 +993,7 @@ static ssize_t ctxid_idx_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
@@ -965,7 +1007,7 @@ static ssize_t ctxid_idx_store(struct device *dev,
 	 * dereferenced multiple times within a spinlock block elsewhere.
 	 */
 	spin_lock(&drvdata->spinlock);
-	drvdata->ctxid_idx = val;
+	config->ctxid_idx = val;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -977,9 +1019,10 @@ static ssize_t ctxid_pid_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	val = drvdata->ctxid_vpid[drvdata->ctxid_idx];
+	val = config->ctxid_vpid[config->ctxid_idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -992,6 +1035,7 @@ static ssize_t ctxid_pid_store(struct device *dev,
 	int ret;
 	unsigned long vpid, pid;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &vpid);
 	if (ret)
@@ -1000,8 +1044,8 @@ static ssize_t ctxid_pid_store(struct device *dev,
 	pid = coresight_vpid_to_pid(vpid);
 
 	spin_lock(&drvdata->spinlock);
-	drvdata->ctxid_pid[drvdata->ctxid_idx] = pid;
-	drvdata->ctxid_vpid[drvdata->ctxid_idx] = vpid;
+	config->ctxid_pid[config->ctxid_idx] = pid;
+	config->ctxid_vpid[config->ctxid_idx] = vpid;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -1013,8 +1057,9 @@ static ssize_t ctxid_mask_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->ctxid_mask;
+	val = config->ctxid_mask;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -1025,12 +1070,13 @@ static ssize_t ctxid_mask_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->ctxid_mask = val;
+	config->ctxid_mask = val;
 	return size;
 }
 static DEVICE_ATTR_RW(ctxid_mask);
@@ -1040,8 +1086,9 @@ static ssize_t sync_freq_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->sync_freq;
+	val = config->sync_freq;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -1052,12 +1099,13 @@ static ssize_t sync_freq_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->sync_freq = val & ETM_SYNC_MASK;
+	config->sync_freq = val & ETM_SYNC_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(sync_freq);
@@ -1067,8 +1115,9 @@ static ssize_t timestamp_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->timestamp_event;
+	val = config->timestamp_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -1079,12 +1128,13 @@ static ssize_t timestamp_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->timestamp_event = val & ETM_EVENT_MASK;
+	config->timestamp_event = val & ETM_EVENT_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(timestamp_event);
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index f2c74bb56993..1952dc31fee4 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -41,6 +41,7 @@ module_param_named(boot_enable, boot_enable, int, S_IRUGO);
 /* The number of ETM/PTM currently registered */
 static int etm_count;
 static struct etm_drvdata *etmdrvdata[NR_CPUS];
+static void etm_init_default_data(struct etm_config *config);
 
 /*
  * Memory mapped writes to clear os lock are not supported on some processors
@@ -186,36 +187,39 @@ static void etm_clr_prog(struct etm_drvdata *drvdata)
 	}
 }
 
-void etm_set_default(struct etm_drvdata *drvdata)
+void etm_set_default(struct etm_config *config)
 {
 	int i;
 
-	drvdata->trigger_event = ETM_DEFAULT_EVENT_VAL;
-	drvdata->enable_event = ETM_HARD_WIRE_RES_A;
-
-	drvdata->seq_12_event = ETM_DEFAULT_EVENT_VAL;
-	drvdata->seq_21_event = ETM_DEFAULT_EVENT_VAL;
-	drvdata->seq_23_event = ETM_DEFAULT_EVENT_VAL;
-	drvdata->seq_31_event = ETM_DEFAULT_EVENT_VAL;
-	drvdata->seq_32_event = ETM_DEFAULT_EVENT_VAL;
-	drvdata->seq_13_event = ETM_DEFAULT_EVENT_VAL;
-	drvdata->timestamp_event = ETM_DEFAULT_EVENT_VAL;
-
-	for (i = 0; i < drvdata->nr_cntr; i++) {
-		drvdata->cntr_rld_val[i] = 0x0;
-		drvdata->cntr_event[i] = ETM_DEFAULT_EVENT_VAL;
-		drvdata->cntr_rld_event[i] = ETM_DEFAULT_EVENT_VAL;
-		drvdata->cntr_val[i] = 0x0;
+	if (WARN_ON_ONCE(!config))
+		return;
+
+	config->trigger_event = ETM_DEFAULT_EVENT_VAL;
+	config->enable_event = ETM_HARD_WIRE_RES_A;
+
+	config->seq_12_event = ETM_DEFAULT_EVENT_VAL;
+	config->seq_21_event = ETM_DEFAULT_EVENT_VAL;
+	config->seq_23_event = ETM_DEFAULT_EVENT_VAL;
+	config->seq_31_event = ETM_DEFAULT_EVENT_VAL;
+	config->seq_32_event = ETM_DEFAULT_EVENT_VAL;
+	config->seq_13_event = ETM_DEFAULT_EVENT_VAL;
+	config->timestamp_event = ETM_DEFAULT_EVENT_VAL;
+
+	for (i = 0; i < ETM_MAX_CNTR; i++) {
+		config->cntr_rld_val[i] = 0x0;
+		config->cntr_event[i] = ETM_DEFAULT_EVENT_VAL;
+		config->cntr_rld_event[i] = ETM_DEFAULT_EVENT_VAL;
+		config->cntr_val[i] = 0x0;
 	}
 
-	drvdata->seq_curr_state = 0x0;
-	drvdata->ctxid_idx = 0x0;
-	for (i = 0; i < drvdata->nr_ctxid_cmp; i++) {
-		drvdata->ctxid_pid[i] = 0x0;
-		drvdata->ctxid_vpid[i] = 0x0;
+	config->seq_curr_state = 0x0;
+	config->ctxid_idx = 0x0;
+	for (i = 0; i < ETM_MAX_CTXID_CMP; i++) {
+		config->ctxid_pid[i] = 0x0;
+		config->ctxid_vpid[i] = 0x0;
 	}
 
-	drvdata->ctxid_mask = 0x0;
+	config->ctxid_mask = 0x0;
 }
 
 static void etm_enable_hw(void *info)
@@ -223,6 +227,7 @@ static void etm_enable_hw(void *info)
 	int i;
 	u32 etmcr;
 	struct etm_drvdata *drvdata = info;
+	struct etm_config *config = &drvdata->config;
 
 	CS_UNLOCK(drvdata->base);
 
@@ -238,39 +243,39 @@ static void etm_enable_hw(void *info)
 	etmcr = etm_readl(drvdata, ETMCR);
 	etmcr &= (ETMCR_PWD_DWN | ETMCR_ETM_PRG);
 	etmcr |= drvdata->port_size;
-	etm_writel(drvdata, drvdata->ctrl | etmcr, ETMCR);
-	etm_writel(drvdata, drvdata->trigger_event, ETMTRIGGER);
-	etm_writel(drvdata, drvdata->startstop_ctrl, ETMTSSCR);
-	etm_writel(drvdata, drvdata->enable_event, ETMTEEVR);
-	etm_writel(drvdata, drvdata->enable_ctrl1, ETMTECR1);
-	etm_writel(drvdata, drvdata->fifofull_level, ETMFFLR);
+	etm_writel(drvdata, config->ctrl | etmcr, ETMCR);
+	etm_writel(drvdata, config->trigger_event, ETMTRIGGER);
+	etm_writel(drvdata, config->startstop_ctrl, ETMTSSCR);
+	etm_writel(drvdata, config->enable_event, ETMTEEVR);
+	etm_writel(drvdata, config->enable_ctrl1, ETMTECR1);
+	etm_writel(drvdata, config->fifofull_level, ETMFFLR);
 	for (i = 0; i < drvdata->nr_addr_cmp; i++) {
-		etm_writel(drvdata, drvdata->addr_val[i], ETMACVRn(i));
-		etm_writel(drvdata, drvdata->addr_acctype[i], ETMACTRn(i));
+		etm_writel(drvdata, config->addr_val[i], ETMACVRn(i));
+		etm_writel(drvdata, config->addr_acctype[i], ETMACTRn(i));
 	}
 	for (i = 0; i < drvdata->nr_cntr; i++) {
-		etm_writel(drvdata, drvdata->cntr_rld_val[i], ETMCNTRLDVRn(i));
-		etm_writel(drvdata, drvdata->cntr_event[i], ETMCNTENRn(i));
-		etm_writel(drvdata, drvdata->cntr_rld_event[i],
+		etm_writel(drvdata, config->cntr_rld_val[i], ETMCNTRLDVRn(i));
+		etm_writel(drvdata, config->cntr_event[i], ETMCNTENRn(i));
+		etm_writel(drvdata, config->cntr_rld_event[i],
 			   ETMCNTRLDEVRn(i));
-		etm_writel(drvdata, drvdata->cntr_val[i], ETMCNTVRn(i));
+		etm_writel(drvdata, config->cntr_val[i], ETMCNTVRn(i));
 	}
-	etm_writel(drvdata, drvdata->seq_12_event, ETMSQ12EVR);
-	etm_writel(drvdata, drvdata->seq_21_event, ETMSQ21EVR);
-	etm_writel(drvdata, drvdata->seq_23_event, ETMSQ23EVR);
-	etm_writel(drvdata, drvdata->seq_31_event, ETMSQ31EVR);
-	etm_writel(drvdata, drvdata->seq_32_event, ETMSQ32EVR);
-	etm_writel(drvdata, drvdata->seq_13_event, ETMSQ13EVR);
-	etm_writel(drvdata, drvdata->seq_curr_state, ETMSQR);
+	etm_writel(drvdata, config->seq_12_event, ETMSQ12EVR);
+	etm_writel(drvdata, config->seq_21_event, ETMSQ21EVR);
+	etm_writel(drvdata, config->seq_23_event, ETMSQ23EVR);
+	etm_writel(drvdata, config->seq_31_event, ETMSQ31EVR);
+	etm_writel(drvdata, config->seq_32_event, ETMSQ32EVR);
+	etm_writel(drvdata, config->seq_13_event, ETMSQ13EVR);
+	etm_writel(drvdata, config->seq_curr_state, ETMSQR);
 	for (i = 0; i < drvdata->nr_ext_out; i++)
 		etm_writel(drvdata, ETM_DEFAULT_EVENT_VAL, ETMEXTOUTEVRn(i));
 	for (i = 0; i < drvdata->nr_ctxid_cmp; i++)
-		etm_writel(drvdata, drvdata->ctxid_pid[i], ETMCIDCVRn(i));
-	etm_writel(drvdata, drvdata->ctxid_mask, ETMCIDCMR);
-	etm_writel(drvdata, drvdata->sync_freq, ETMSYNCFR);
+		etm_writel(drvdata, config->ctxid_pid[i], ETMCIDCVRn(i));
+	etm_writel(drvdata, config->ctxid_mask, ETMCIDCMR);
+	etm_writel(drvdata, config->sync_freq, ETMSYNCFR);
 	/* No external input selected */
 	etm_writel(drvdata, 0x0, ETMEXTINSELR);
-	etm_writel(drvdata, drvdata->timestamp_event, ETMTSEVR);
+	etm_writel(drvdata, config->timestamp_event, ETMTSEVR);
 	/* No auxiliary control selected */
 	etm_writel(drvdata, 0x0, ETMAUXCR);
 	etm_writel(drvdata, drvdata->traceid, ETMTRACEIDR);
@@ -278,7 +283,7 @@ static void etm_enable_hw(void *info)
 	etm_writel(drvdata, 0x0, ETMVMIDCVR);
 
 	/* Ensures trace output is enabled from this ETM */
-	etm_writel(drvdata, drvdata->ctrl | ETMCR_ETM_EN | etmcr, ETMCR);
+	etm_writel(drvdata, config->ctrl | ETMCR_ETM_EN | etmcr, ETMCR);
 
 	etm_clr_prog(drvdata);
 	CS_LOCK(drvdata->base);
@@ -362,6 +367,7 @@ static void etm_disable_hw(void *info)
 {
 	int i;
 	struct etm_drvdata *drvdata = info;
+	struct etm_config *config = &drvdata->config;
 
 	CS_UNLOCK(drvdata->base);
 	etm_set_prog(drvdata);
@@ -370,10 +376,10 @@ static void etm_disable_hw(void *info)
 	etm_writel(drvdata, ETM_HARD_WIRE_RES_A | ETM_EVENT_NOT_A, ETMTEEVR);
 
 	/* Read back sequencer and counters for post trace analysis */
-	drvdata->seq_curr_state = (etm_readl(drvdata, ETMSQR) & ETM_SQR_MASK);
+	config->seq_curr_state = (etm_readl(drvdata, ETMSQR) & ETM_SQR_MASK);
 
 	for (i = 0; i < drvdata->nr_cntr; i++)
-		drvdata->cntr_val[i] = etm_readl(drvdata, ETMCNTVRn(i));
+		config->cntr_val[i] = etm_readl(drvdata, ETMCNTVRn(i));
 
 	etm_set_pwrdwn(drvdata);
 	CS_LOCK(drvdata->base);
@@ -522,14 +528,8 @@ static void etm_init_arch_data(void *info)
 	CS_LOCK(drvdata->base);
 }
 
-static void etm_init_default_data(struct etm_drvdata *drvdata)
+static void etm_init_default_data(struct etm_config *config)
 {
-	/*
-	 * A trace ID of value 0 is invalid, so let's start at some
-	 * random value that fits in 7 bits and will be just as good.
-	 */
-	static int etm3x_traceid = 0x10;
-
 	u32 flags = (1 << 0 | /* instruction execute*/
 		     3 << 3 | /* ARM instruction */
 		     0 << 5 | /* No data value comparison */
@@ -537,25 +537,28 @@ static void etm_init_default_data(struct etm_drvdata *drvdata)
 		     0 << 8 | /* Ignore context ID */
 		     0 << 10); /* Security ignored */
 
+	if (WARN_ON_ONCE(!config))
+		return;
+
+	config->ctrl = (ETMCR_CYC_ACC | ETMCR_TIMESTAMP_EN);
+	config->enable_ctrl1 = ETMTECR1_ADDR_COMP_1;
+	config->addr_val[0] = (u32) _stext;
+	config->addr_val[1] = (u32) _etext;
+	config->addr_acctype[0] = flags;
+	config->addr_acctype[1] = flags;
+	config->addr_type[0] = ETM_ADDR_TYPE_RANGE;
+	config->addr_type[1] = ETM_ADDR_TYPE_RANGE;
+
+	etm_set_default(config);
+}
+
+static void etm_init_trace_id(struct etm_drvdata *drvdata)
+{
 	/*
-	 * Initial configuration only - guarantees sources handled by
-	 * this driver have a unique ID at startup time but not between
-	 * all other types of sources.  For that we lean on the core
-	 * framework.
+	 * A trace ID of value 0 is invalid, so let's start at some
+	 * random value that fits in 7 bits and go from there.
 	 */
-	drvdata->traceid = etm3x_traceid++;
-	drvdata->ctrl = (ETMCR_CYC_ACC | ETMCR_TIMESTAMP_EN);
-	drvdata->enable_ctrl1 = ETMTECR1_ADDR_COMP_1;
-	if (drvdata->nr_addr_cmp >= 2) {
-		drvdata->addr_val[0] = (u32) _stext;
-		drvdata->addr_val[1] = (u32) _etext;
-		drvdata->addr_acctype[0] = flags;
-		drvdata->addr_acctype[1] = flags;
-		drvdata->addr_type[0] = ETM_ADDR_TYPE_RANGE;
-		drvdata->addr_type[1] = ETM_ADDR_TYPE_RANGE;
-	}
-
-	etm_set_default(drvdata);
+	drvdata->traceid = 0x10 + drvdata->cpu;
 }
 
 static int etm_probe(struct amba_device *adev, const struct amba_id *id)
@@ -623,7 +626,9 @@ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
 		ret = -EINVAL;
 		goto err_arch_supported;
 	}
-	etm_init_default_data(drvdata);
+
+	etm_init_trace_id(drvdata);
+	etm_init_default_data(&drvdata->config);
 
 	desc->type = CORESIGHT_DEV_TYPE_SOURCE;
 	desc->subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_PROC;
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb  3 10:39:15 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:15 -0700
Subject: [PATCH V9 17/18] coresight: etm-perf: new PMU driver for ETM tracers
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-18-git-send-email-mathieu.poirier@linaro.org>

Perf is a well known and used tool for performance monitoring
and much more. A such it is an ideal candidate for integration
with coresight based HW tracing.

This patch introduces a PMU that represent a coresight tracer to
the Perf core.

Cc: Alexander Shishkin <alexander.shishkin at linux.intel.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/Makefile             |   3 +-
 drivers/hwtracing/coresight/coresight-etm-perf.c | 393 +++++++++++++++++++++++
 drivers/hwtracing/coresight/coresight-etm-perf.h |  32 ++
 drivers/hwtracing/coresight/coresight-etm3x.c    |   7 +
 include/linux/coresight-pmu.h                    |  27 ++
 5 files changed, 461 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-etm-perf.c
 create mode 100644 drivers/hwtracing/coresight/coresight-etm-perf.h
 create mode 100644 include/linux/coresight-pmu.h

diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 233d66cf22d3..cf8c6d689747 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_CORESIGHT_SINK_ETBV10) += coresight-etb10.o
 obj-$(CONFIG_CORESIGHT_LINKS_AND_SINKS) += coresight-funnel.o \
 					   coresight-replicator.o
 obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o coresight-etm-cp14.o \
-					coresight-etm3x-sysfs.o
+					coresight-etm3x-sysfs.o \
+					coresight-etm-perf.o
 obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
 obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
new file mode 100644
index 000000000000..36153a77e982
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -0,0 +1,393 @@
+/*
+ * Copyright(C) 2015 Linaro Limited. All rights reserved.
+ * Author: Mathieu Poirier <mathieu.poirier at linaro.org>
+ *
+ * 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/coresight.h>
+#include <linux/coresight-pmu.h>
+#include <linux/cpumask.h>
+#include <linux/device.h>
+#include <linux/list.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/perf_event.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/workqueue.h>
+
+#include "coresight-priv.h"
+
+static struct pmu etm_pmu;
+static bool etm_perf_up;
+
+/**
+ * struct etm_event_data - Coresight specifics associated to an event
+ * @work:		Handle to free allocated memory outside IRQ context.
+ * @mask:		Hold the CPU(s) this event was set for.
+ * @snk_config:		The sink configuration.
+ * @path:		An array of path, each slot for one CPU.
+ */
+struct etm_event_data {
+	struct work_struct work;
+	cpumask_t mask;
+	void *snk_config;
+	struct list_head **path;
+};
+
+static DEFINE_PER_CPU(struct perf_output_handle, ctx_handle);
+static DEFINE_PER_CPU(struct coresight_device *, csdev_src);
+
+/* ETMv3.5/PTM's ETMCR is 'config' */
+PMU_FORMAT_ATTR(cycacc,		"config:" __stringify(ETM_OPT_CYCACC));
+PMU_FORMAT_ATTR(timestamp,	"config:" __stringify(ETM_OPT_TS));
+
+static struct attribute *etm_config_formats_attr[] = {
+	&format_attr_cycacc.attr,
+	&format_attr_timestamp.attr,
+	NULL,
+};
+
+static struct attribute_group etm_pmu_format_group = {
+	.name   = "format",
+	.attrs  = etm_config_formats_attr,
+};
+
+static const struct attribute_group *etm_pmu_attr_groups[] = {
+	&etm_pmu_format_group,
+	NULL,
+};
+
+static void etm_event_read(struct perf_event *event) {}
+
+static int etm_event_init(struct perf_event *event)
+{
+	if (event->attr.type != etm_pmu.type)
+		return -ENOENT;
+
+	return 0;
+}
+
+static void free_event_data(struct work_struct *work)
+{
+	int cpu;
+	cpumask_t *mask;
+	struct etm_event_data *event_data;
+	struct coresight_device *sink;
+
+	event_data = container_of(work, struct etm_event_data, work);
+	mask = &event_data->mask;
+	/*
+	 * First deal with the sink configuration.  See comment in
+	 * etm_setup_aux() about why we take the first available path.
+	 */
+	if (event_data->snk_config) {
+		cpu = cpumask_first(mask);
+		sink = coresight_get_sink(event_data->path[cpu]);
+		if (sink_ops(sink)->free_buffer)
+			sink_ops(sink)->free_buffer(event_data->snk_config);
+	}
+
+	for_each_cpu(cpu, mask) {
+		if (event_data->path[cpu])
+			coresight_release_path(event_data->path[cpu]);
+	}
+
+	kfree(event_data->path);
+	kfree(event_data);
+}
+
+static void *alloc_event_data(int cpu)
+{
+	int size;
+	cpumask_t *mask;
+	struct etm_event_data *event_data;
+
+	/* First get memory for the session's data */
+	event_data = kzalloc(sizeof(struct etm_event_data), GFP_KERNEL);
+	if (!event_data)
+		return NULL;
+
+	/* Make sure nothing disappears under us */
+	get_online_cpus();
+	size = num_online_cpus();
+
+	mask = &event_data->mask;
+	if (cpu != -1)
+		cpumask_set_cpu(cpu, mask);
+	else
+		cpumask_copy(mask, cpu_online_mask);
+	put_online_cpus();
+
+	/*
+	 * Each CPU has a single path between source and destination.  As such
+	 * allocate an array using CPU numbers as indexes.  That way a path
+	 * for any CPU can easily be accessed at any given time.  We proceed
+	 * the same way for sessions involving a single CPU.  The cost of
+	 * unused memory when dealing with single CPU trace scenarios is small
+	 * compared to the cost of searching through an optimized array.
+	 */
+	event_data->path = kcalloc(size,
+				   sizeof(struct list_head *), GFP_KERNEL);
+	if (!event_data->path) {
+		kfree(event_data);
+		return NULL;
+	}
+
+	return event_data;
+}
+
+static void etm_free_aux(void *data)
+{
+	struct etm_event_data *event_data = data;
+
+	schedule_work(&event_data->work);
+}
+
+static void *etm_setup_aux(int event_cpu, void **pages,
+			   int nr_pages, bool overwrite)
+{
+	int cpu;
+	cpumask_t *mask;
+	struct coresight_device *sink;
+	struct etm_event_data *event_data = NULL;
+
+	event_data = alloc_event_data(event_cpu);
+	if (!event_data)
+		return NULL;
+
+	INIT_WORK(&event_data->work, free_event_data);
+
+	mask = &event_data->mask;
+
+	/* Setup the path for each CPU in a trace session */
+	for_each_cpu(cpu, mask) {
+		struct coresight_device *csdev;
+
+		csdev = per_cpu(csdev_src, cpu);
+		if (!csdev)
+			goto err;
+
+		/*
+		 * Building a path doesn't enable it, it simply builds a
+		 * list of devices from source to sink that can be
+		 * referenced later when the path is actually needed.
+		 */
+		event_data->path[cpu] = coresight_build_path(csdev);
+		if (!event_data->path[cpu])
+			goto err;
+	}
+
+	/*
+	 * In theory nothing prevent tracers in a trace session from being
+	 * associated with different sinks, nor having a sink per tracer.  But
+	 * until we have HW with this kind of topology and a way to convey
+	 * sink assignement from the perf cmd line we need to assume tracers
+	 * in a trace session are using the same sink.  Therefore pick the sink
+	 * found at the end of the first available path.
+	 */
+	cpu = cpumask_first(mask);
+	/* Grab the sink at the end of the path */
+	sink = coresight_get_sink(event_data->path[cpu]);
+	if (!sink)
+		goto err;
+
+	if (!sink_ops(sink)->alloc_buffer)
+		goto err;
+
+	/* Get the AUX specific data from the sink buffer */
+	event_data->snk_config =
+			sink_ops(sink)->alloc_buffer(sink, cpu, pages,
+						     nr_pages, overwrite);
+	if (!event_data->snk_config)
+		goto err;
+
+out:
+	return event_data;
+
+err:
+	etm_free_aux(event_data);
+	event_data = NULL;
+	goto out;
+}
+
+static void etm_event_start(struct perf_event *event, int flags)
+{
+	int cpu = smp_processor_id();
+	struct etm_event_data *event_data;
+	struct perf_output_handle *handle = this_cpu_ptr(&ctx_handle);
+	struct coresight_device *sink, *csdev = per_cpu(csdev_src, cpu);
+
+	if (!csdev)
+		goto fail;
+
+	/*
+	 * Deal with the ring buffer API and get a handle on the
+	 * session's information.
+	 */
+	event_data = perf_aux_output_begin(handle, event);
+	if (!event_data)
+		goto fail;
+
+	/* We need a sink, no need to continue without one */
+	sink = coresight_get_sink(event_data->path[cpu]);
+	if (WARN_ON_ONCE(!sink || !sink_ops(sink)->set_buffer))
+		goto fail_end_stop;
+
+	/* Configure the sink */
+	if (sink_ops(sink)->set_buffer(sink, handle,
+				       event_data->snk_config))
+		goto fail_end_stop;
+
+	/* Nothing will happen without a path */
+	if (coresight_enable_path(event_data->path[cpu], CS_MODE_PERF))
+		goto fail_end_stop;
+
+	/* Tell the perf core the event is alive */
+	event->hw.state = 0;
+
+	/* Finally enable the tracer */
+	if (source_ops(csdev)->enable(csdev, &event->attr, CS_MODE_PERF))
+		goto fail_end_stop;
+
+out:
+	return;
+
+fail_end_stop:
+	perf_aux_output_end(handle, 0, true);
+fail:
+	event->hw.state = PERF_HES_STOPPED;
+	goto out;
+}
+
+static void etm_event_stop(struct perf_event *event, int mode)
+{
+	bool lost;
+	int cpu = smp_processor_id();
+	unsigned long size;
+	struct coresight_device *sink, *csdev = per_cpu(csdev_src, cpu);
+	struct perf_output_handle *handle = this_cpu_ptr(&ctx_handle);
+	struct etm_event_data *event_data = perf_get_aux(handle);
+
+	if (event->hw.state == PERF_HES_STOPPED)
+		return;
+
+	if (!csdev)
+		return;
+
+	sink = coresight_get_sink(event_data->path[cpu]);
+	if (!sink)
+		return;
+
+	/* stop tracer */
+	source_ops(csdev)->disable(csdev);
+
+	/* tell the core */
+	event->hw.state = PERF_HES_STOPPED;
+
+	if (mode & PERF_EF_UPDATE) {
+		if (WARN_ON_ONCE(handle->event != event))
+			return;
+
+		/* update trace information */
+		if (!sink_ops(sink)->update_buffer)
+			return;
+
+		sink_ops(sink)->update_buffer(sink, handle,
+					      event_data->snk_config);
+
+		if (!sink_ops(sink)->reset_buffer)
+			return;
+
+		size = sink_ops(sink)->reset_buffer(sink, handle,
+						    event_data->snk_config,
+						    &lost);
+
+		perf_aux_output_end(handle, size, lost);
+	}
+
+	/* Disabling the path make its elements available to other sessions */
+	coresight_disable_path(event_data->path[cpu]);
+}
+
+static int etm_event_add(struct perf_event *event, int mode)
+{
+	int ret = 0;
+	struct hw_perf_event *hwc = &event->hw;
+
+	if (mode & PERF_EF_START) {
+		etm_event_start(event, 0);
+		if (hwc->state & PERF_HES_STOPPED)
+			ret = -EINVAL;
+	} else {
+		hwc->state = PERF_HES_STOPPED;
+	}
+
+	return ret;
+}
+
+static void etm_event_del(struct perf_event *event, int mode)
+{
+	etm_event_stop(event, PERF_EF_UPDATE);
+}
+
+int etm_perf_symlink(struct coresight_device *csdev, bool link)
+{
+	char entry[sizeof("cpu9999999")];
+	int ret = 0, cpu = source_ops(csdev)->cpu_id(csdev);
+	struct device *pmu_dev = etm_pmu.dev;
+	struct device *cs_dev = &csdev->dev;
+
+	sprintf(entry, "cpu%d", cpu);
+
+	if (!etm_perf_up)
+		return -EPROBE_DEFER;
+
+	if (link) {
+		ret = sysfs_create_link(&pmu_dev->kobj, &cs_dev->kobj, entry);
+		if (ret)
+			return ret;
+		per_cpu(csdev_src, cpu) = csdev;
+	} else {
+		sysfs_remove_link(&pmu_dev->kobj, entry);
+		per_cpu(csdev_src, cpu) = NULL;
+	}
+
+	return 0;
+}
+
+static int __init etm_perf_init(void)
+{
+	int ret;
+
+	etm_pmu.capabilities	= PERF_PMU_CAP_EXCLUSIVE;
+
+	etm_pmu.attr_groups	= etm_pmu_attr_groups;
+	etm_pmu.task_ctx_nr	= perf_sw_context;
+	etm_pmu.read		= etm_event_read;
+	etm_pmu.event_init	= etm_event_init;
+	etm_pmu.setup_aux	= etm_setup_aux;
+	etm_pmu.free_aux	= etm_free_aux;
+	etm_pmu.start		= etm_event_start;
+	etm_pmu.stop		= etm_event_stop;
+	etm_pmu.add		= etm_event_add;
+	etm_pmu.del		= etm_event_del;
+
+	ret = perf_pmu_register(&etm_pmu, CORESIGHT_ETM_PMU_NAME, -1);
+	if (ret == 0)
+		etm_perf_up = true;
+
+	return ret;
+}
+module_init(etm_perf_init);
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h
new file mode 100644
index 000000000000..87f5a134eb6f
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright(C) 2015 Linaro Limited. All rights reserved.
+ * Author: Mathieu Poirier <mathieu.poirier at linaro.org>
+ *
+ * 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/>.
+ */
+
+#ifndef _CORESIGHT_ETM_PERF_H
+#define _CORESIGHT_ETM_PERF_H
+
+struct coresight_device;
+
+#ifdef CONFIG_CORESIGHT
+int etm_perf_symlink(struct coresight_device *csdev, bool link);
+
+#else
+static inline int etm_perf_symlink(struct coresight_device *csdev, bool link)
+{ return -EINVAL; }
+
+#endif /* CONFIG_CORESIGHT */
+
+#endif
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index a9b820ec16aa..77b37413803f 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -35,6 +35,7 @@
 #include <asm/sections.h>
 
 #include "coresight-etm.h"
+#include "coresight-etm-perf.h"
 
 static int boot_enable;
 module_param_named(boot_enable, boot_enable, int, S_IRUGO);
@@ -827,6 +828,12 @@ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
 		goto err_arch_supported;
 	}
 
+	ret = etm_perf_symlink(drvdata->csdev, true);
+	if (ret) {
+		coresight_unregister(drvdata->csdev);
+		goto err_arch_supported;
+	}
+
 	pm_runtime_put(&adev->dev);
 	dev_info(dev, "%s initialized\n", (char *)id->data);
 
diff --git a/include/linux/coresight-pmu.h b/include/linux/coresight-pmu.h
new file mode 100644
index 000000000000..6c5386b23b10
--- /dev/null
+++ b/include/linux/coresight-pmu.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright(C) 2015 Linaro Limited. All rights reserved.
+ * Author: Mathieu Poirier <mathieu.poirier at linaro.org>
+ *
+ * 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/>.
+ */
+
+#ifndef _LINUX_CORESIGHT_PMU_H
+#define _LINUX_CORESIGHT_PMU_H
+
+#define CORESIGHT_ETM_PMU_NAME "cs_etm"
+
+/* ETMv3.5/PTM's ETMCR config bit */
+#define ETM_OPT_CYCACC  12
+#define ETM_OPT_TS      28
+
+#endif
-- 
2.1.4



From gregory.clement at free-electrons.com  Wed Feb  3 10:41:18 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed,  3 Feb 2016 19:41:18 +0100
Subject: [PATCH v2 01/12] irqchip: armada-370-xp: add Kconfig option for the
 driver
In-Reply-To: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454524889-9207-2-git-send-email-gregory.clement@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Instead of building the irq-armada-370-xp driver directly when
CONFIG_ARCH_MVEBU is enabled, this commit introduces an intermediate
CONFIG_ARMADA_370_XP_IRQ hidden Kconfig option.

This allows this option to select other interrupt-related Kconfig
options (which will be needed in follow-up commits) rather than having
such selects done from arch/arm/mach-<foo>/.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/irqchip/Kconfig  | 5 +++++
 drivers/irqchip/Makefile | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 715923d5236c..e2cab879d641 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -60,6 +60,11 @@ config ARM_VIC_NR
 	  The maximum number of VICs available in the system, for
 	  power management.
 
+config ARMADA_370_XP_IRQ
+	bool
+	default y if ARCH_MVEBU
+	select GENERIC_IRQ_CHIP
+
 config ATMEL_AIC_IRQ
 	bool
 	select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 18caacb60d58..30dba044d0b8 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -5,7 +5,6 @@ obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2836.o
 obj-$(CONFIG_ARCH_EXYNOS)		+= exynos-combiner.o
 obj-$(CONFIG_ARCH_HIP04)		+= irq-hip04.o
 obj-$(CONFIG_ARCH_MMP)			+= irq-mmp.o
-obj-$(CONFIG_ARCH_MVEBU)		+= irq-armada-370-xp.o
 obj-$(CONFIG_IRQ_MXS)			+= irq-mxs.o
 obj-$(CONFIG_ARCH_TEGRA)		+= irq-tegra.o
 obj-$(CONFIG_ARCH_S3C24XX)		+= irq-s3c24xx.o
@@ -28,6 +27,7 @@ obj-$(CONFIG_ARM_GIC_V3_ITS)		+= irq-gic-v3-its.o irq-gic-v3-its-pci-msi.o irq-g
 obj-$(CONFIG_HISILICON_IRQ_MBIGEN)	+= irq-mbigen.o
 obj-$(CONFIG_ARM_NVIC)			+= irq-nvic.o
 obj-$(CONFIG_ARM_VIC)			+= irq-vic.o
+obj-$(CONFIG_ARMADA_370_XP_IRQ)		+= irq-armada-370-xp.o
 obj-$(CONFIG_ATMEL_AIC_IRQ)		+= irq-atmel-aic-common.o irq-atmel-aic.o
 obj-$(CONFIG_ATMEL_AIC5_IRQ)	+= irq-atmel-aic-common.o irq-atmel-aic5.o
 obj-$(CONFIG_I8259)			+= irq-i8259.o
-- 
2.5.0



From gregory.clement at free-electrons.com  Wed Feb  3 10:41:20 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed,  3 Feb 2016 19:41:20 +0100
Subject: [PATCH v2 03/12] serial: mvebu-uart: initial support for Armada-3700
 serial port
In-Reply-To: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454524889-9207-4-git-send-email-gregory.clement@free-electrons.com>

From: Wilson Ding <dingwei at marvell.com>

Armada-3700's uart is a simple serial port, which doesn't
support. Configuring the modem control lines. The uart port has a 32
bytes Tx FIFO and a 64 bytes Rx FIFO

The uart driver implements the uart core operations. It also support the
system (early) console based on Armada-3700's serial port.

Known Issue:

The uart driver currently doesn't support clock programming, which means
the baud-rate stays with the default value configured by the bootloader
at boot time

[gregory.clement at free-electrons.com: Rewrite many part which are too long
to enumerate]

Signed-off-by: Wilson Ding <dingwei at marvell.com>
Signed-off-by: Nadav Haklai <nadavh at marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/tty/serial/mvebu-uart.txt  |  13 +
 Documentation/kernel-parameters.txt                |   6 +
 drivers/tty/serial/Kconfig                         |  22 +
 drivers/tty/serial/Makefile                        |   1 +
 drivers/tty/serial/mvebu-uart.c                    | 650 +++++++++++++++++++++
 include/uapi/linux/serial_core.h                   |   3 +
 6 files changed, 695 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
 create mode 100644 drivers/tty/serial/mvebu-uart.c

diff --git a/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
new file mode 100644
index 000000000000..6087defd9f93
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
@@ -0,0 +1,13 @@
+* Marvell UART : Non standard UART used in some of Marvell EBU SoCs (e.g., Armada-3700)
+
+Required properties:
+- compatible: "marvell,armada-3700-uart"
+- reg: offset and length of the register set for the device.
+- interrupts: device interrupt
+
+Example:
+	serial at 12000 {
+		compatible = "marvell,armada-3700-uart";
+		reg = <0x12000 0x400>;
+		interrupts = <43>;
+	};
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 87d40a72f6a1..ea0aba48d616 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1058,6 +1058,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			A valid base address must be provided, and the serial
 			port must already be setup and configured.
 
+		armada3700_uart,<addr>
+			Start an early, polled-mode console on the
+			Armada 3700 serial port at the specified
+			address. The serial port must already be setup
+			and configured. Options are not yet supported.
+
 	earlyprintk=	[X86,SH,BLACKFIN,ARM,M68k]
 			earlyprintk=vga
 			earlyprintk=efi
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 39721ec4f415..b291f934d51b 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1606,6 +1606,28 @@ config SERIAL_STM32_CONSOLE
 	depends on SERIAL_STM32=y
 	select SERIAL_CORE_CONSOLE
 
+config SERIAL_MVEBU_UART
+	bool "Marvell EBU serial port support"
+	select SERIAL_CORE
+	help
+	  This driver is for Marvell EBU SoC's UART. If you have a machine
+	  based on the Armada-3700 SoC and wish to use the on-board serial
+	  port,
+	  say 'Y' here.
+	  Otherwise, say 'N'.
+
+config SERIAL_MVEBU_CONSOLE
+	bool "Console on Marvell EBU serial port"
+	depends on SERIAL_MVEBU_UART
+	select SERIAL_CORE_CONSOLE
+	select SERIAL_EARLYCON
+	default y
+	help
+	  Say 'Y' here if you wish to use Armada-3700 UART as the system console.
+	  (the system console is the device which receives all kernel messages
+	  and warnings and which allows logins in single user mode)
+	  Otherwise, say 'N'.
+
 endmenu
 
 config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index b391c9b31960..988167595330 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
 obj-$(CONFIG_SERIAL_MEN_Z135)	+= men_z135_uart.o
 obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
 obj-$(CONFIG_SERIAL_STM32)	+= stm32-usart.o
+obj-$(CONFIG_SERIAL_MVEBU_UART)	+= mvebu-uart.o
 
 # GPIOLIB helpers for modem control lines
 obj-$(CONFIG_SERIAL_MCTRL_GPIO)	+= serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
new file mode 100644
index 000000000000..f8e3ba21a7b7
--- /dev/null
+++ b/drivers/tty/serial/mvebu-uart.c
@@ -0,0 +1,650 @@
+/*
+* ***************************************************************************
+* Copyright (C) 2015 Marvell International Ltd.
+* ***************************************************************************
+* This program is free software: you can redistribute it and/or modify it
+* under the terms of the GNU General Public License as published by the Free
+* Software Foundation, either version 2 of the License, or any later version.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+* GNU General Public License for more details.
+*
+* 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/clk.h>
+#include <linux/console.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/slab.h>
+#include <linux/tty.h>
+#include <linux/tty_flip.h>
+
+/* Register Map */
+#define UART_RBR		0x00
+#define  RBR_BRK_DET		BIT(15)
+#define  RBR_FRM_ERR_DET	BIT(14)
+#define  RBR_PAR_ERR_DET	BIT(13)
+#define  RBR_OVR_ERR_DET	BIT(12)
+
+#define UART_TSH		0x04
+
+#define UART_CTRL		0x08
+#define  CTRL_SOFT_RST		BIT(31)
+#define  CTRL_TXFIFO_RST	BIT(15)
+#define  CTRL_RXFIFO_RST	BIT(14)
+#define  CTRL_ST_MIRR_EN	BIT(13)
+#define  CTRL_LPBK_EN		BIT(12)
+#define  CTRL_SND_BRK_SEQ	BIT(11)
+#define  CTRL_PAR_EN		BIT(10)
+#define  CTRL_TWO_STOP		BIT(9)
+#define  CTRL_TX_HFL_INT	BIT(8)
+#define  CTRL_RX_HFL_INT	BIT(7)
+#define  CTRL_TX_EMP_INT	BIT(6)
+#define  CTRL_TX_RDY_INT	BIT(5)
+#define  CTRL_RX_RDY_INT	BIT(4)
+#define  CTRL_BRK_DET_INT	BIT(3)
+#define  CTRL_FRM_ERR_INT	BIT(2)
+#define  CTRL_PAR_ERR_INT	BIT(1)
+#define  CTRL_OVR_ERR_INT	BIT(0)
+#define  CTRL_RX_INT			(CTRL_RX_RDY_INT | CTRL_BRK_DET_INT |\
+	CTRL_FRM_ERR_INT | CTRL_PAR_ERR_INT | CTRL_OVR_ERR_INT)
+
+#define UART_STAT		0x0c
+#define  STAT_TX_FIFO_EMP	BIT(13)
+#define  STAT_RX_FIFO_EMP	BIT(12)
+#define  STAT_TX_FIFO_FUL	BIT(11)
+#define  STAT_TX_FIFO_HFL	BIT(10)
+#define  STAT_RX_TOGL		BIT(9)
+#define  STAT_RX_FIFO_FUL	BIT(8)
+#define  STAT_RX_FIFO_HFL	BIT(7)
+#define  STAT_TX_EMP		BIT(6)
+#define  STAT_TX_RDY		BIT(5)
+#define  STAT_RX_RDY		BIT(4)
+#define  STAT_BRK_DET		BIT(3)
+#define  STAT_FRM_ERR		BIT(2)
+#define  STAT_PAR_ERR		BIT(1)
+#define  STAT_OVR_ERR		BIT(0)
+#define  STAT_BRK_ERR		(STAT_BRK_DET | STAT_FRM_ERR | STAT_FRM_ERR\
+				 | STAT_PAR_ERR | STAT_OVR_ERR)
+
+#define UART_BRDV		0x10
+
+#define MVEBU_NR_UARTS		1
+
+#define MVEBU_UART_TYPE		"mvebu-uart"
+
+static struct uart_port mvebu_uart_ports[MVEBU_NR_UARTS];
+
+struct mvebu_uart_data {
+	struct uart_port *port;
+	struct clk       *clk;
+};
+
+/* Core UART Driver Operations */
+static unsigned int mvebu_uart_tx_empty(struct uart_port *port)
+{
+	unsigned long flags;
+	unsigned int st;
+
+	spin_lock_irqsave(&port->lock, flags);
+	st = readl(port->membase + UART_STAT);
+	spin_unlock_irqrestore(&port->lock, flags);
+
+	return (st & STAT_TX_FIFO_EMP) ? TIOCSER_TEMT : 0;
+}
+
+static unsigned int mvebu_uart_get_mctrl(struct uart_port *port)
+{
+	return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
+}
+
+static void mvebu_uart_set_mctrl(struct uart_port *port,
+				 unsigned int mctrl)
+{
+/*
+ * Even if we do not support configuring the modem control lines, this
+ * function must be proided to the serial core
+ */
+}
+
+static void mvebu_uart_stop_tx(struct uart_port *port)
+{
+	unsigned int ctl = readl(port->membase + UART_CTRL);
+
+	ctl &= ~CTRL_TX_RDY_INT;
+	writel(ctl, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_start_tx(struct uart_port *port)
+{
+	unsigned int ctl = readl(port->membase + UART_CTRL);
+
+	ctl |= CTRL_TX_RDY_INT;
+	writel(ctl, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_stop_rx(struct uart_port *port)
+{
+	unsigned int ctl = readl(port->membase + UART_CTRL);
+
+	ctl &= ~CTRL_RX_INT;
+	writel(ctl, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_break_ctl(struct uart_port *port, int brk)
+{
+	unsigned int ctl;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port->lock, flags);
+	ctl = readl(port->membase + UART_CTRL);
+	if (brk == -1)
+		ctl |= CTRL_SND_BRK_SEQ;
+	else
+		ctl &= ~CTRL_SND_BRK_SEQ;
+	writel(ctl, port->membase + UART_CTRL);
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static void mvebu_uart_rx_chars(struct uart_port *port, unsigned int status)
+{
+	struct tty_port *tport = &port->state->port;
+	unsigned char ch = 0;
+	char flag = 0;
+
+	do {
+		if (status & STAT_RX_RDY) {
+			ch = readl(port->membase + UART_RBR);
+			ch &= 0xff;
+			flag = TTY_NORMAL;
+			port->icount.rx++;
+
+			if (status & STAT_PAR_ERR)
+				port->icount.parity++;
+		}
+
+		if (status & STAT_BRK_DET) {
+			port->icount.brk++;
+			status &= ~(STAT_FRM_ERR | STAT_PAR_ERR);
+			if (uart_handle_break(port))
+				goto ignore_char;
+		}
+
+		if (status & STAT_OVR_ERR)
+			port->icount.overrun++;
+
+		if (status & STAT_FRM_ERR)
+			port->icount.frame++;
+
+		if (uart_handle_sysrq_char(port, ch))
+			goto ignore_char;
+
+		if (status & port->ignore_status_mask & STAT_PAR_ERR)
+			status &= ~STAT_RX_RDY;
+
+		status &= port->read_status_mask;
+
+		if (status & STAT_PAR_ERR)
+			flag = TTY_PARITY;
+
+		status &= ~port->ignore_status_mask;
+
+		if (status & STAT_RX_RDY)
+			tty_insert_flip_char(tport, ch, flag);
+
+		if (status & STAT_BRK_DET)
+			tty_insert_flip_char(tport, 0, TTY_BREAK);
+
+		if (status & STAT_FRM_ERR)
+			tty_insert_flip_char(tport, 0, TTY_FRAME);
+
+		if (status & STAT_OVR_ERR)
+			tty_insert_flip_char(tport, 0, TTY_OVERRUN);
+
+ignore_char:
+		status = readl(port->membase + UART_STAT);
+	} while (status & (STAT_RX_RDY | STAT_BRK_DET));
+
+	tty_flip_buffer_push(tport);
+}
+
+static void mvebu_uart_tx_chars(struct uart_port *port, unsigned int status)
+{
+	struct circ_buf *xmit = &port->state->xmit;
+	unsigned int count;
+	unsigned int st;
+
+	if (port->x_char) {
+		writel(port->x_char, port->membase + UART_TSH);
+		port->icount.tx++;
+		port->x_char = 0;
+		return;
+	}
+
+	if (uart_circ_empty(xmit) || uart_tx_stopped(port)) {
+		mvebu_uart_stop_tx(port);
+		return;
+	}
+
+	for (count = 0; count < port->fifosize; count++) {
+		writel(xmit->buf[xmit->tail], port->membase + UART_TSH);
+		xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+		port->icount.tx++;
+
+		if (uart_circ_empty(xmit))
+			break;
+
+		st = readl(port->membase + UART_STAT);
+		if (st & STAT_TX_FIFO_FUL)
+			break;
+	}
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+
+	if (uart_circ_empty(xmit))
+		mvebu_uart_stop_tx(port);
+}
+
+static irqreturn_t mvebu_uart_isr(int irq, void *dev_id)
+{
+	struct uart_port *port = (struct uart_port *)dev_id;
+	unsigned int st = readl(port->membase + UART_STAT);
+
+	if (st & (STAT_RX_RDY | STAT_OVR_ERR | STAT_FRM_ERR | STAT_BRK_DET))
+		mvebu_uart_rx_chars(port, st);
+
+	if (st & STAT_TX_RDY)
+		mvebu_uart_tx_chars(port, st);
+
+	return IRQ_HANDLED;
+}
+
+static int mvebu_uart_startup(struct uart_port *port)
+{
+	int ret;
+
+	writel(CTRL_TXFIFO_RST | CTRL_RXFIFO_RST,
+	       port->membase + UART_CTRL);
+	udelay(1);
+	writel(CTRL_RX_INT, port->membase + UART_CTRL);
+
+	ret = request_irq(port->irq, mvebu_uart_isr, port->irqflags, "serial",
+			  port);
+	if (ret) {
+		dev_err(port->dev, "failed to request irq\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static void mvebu_uart_shutdown(struct uart_port *port)
+{
+	writel(0, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_set_termios(struct uart_port *port,
+				   struct ktermios *termios,
+				   struct ktermios *old)
+{
+	unsigned long flags;
+	unsigned int baud;
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	port->read_status_mask = STAT_RX_RDY | STAT_OVR_ERR |
+		STAT_TX_RDY | STAT_TX_FIFO_FUL;
+
+	if (termios->c_iflag & INPCK)
+		port->read_status_mask |= STAT_FRM_ERR | STAT_PAR_ERR;
+
+	port->ignore_status_mask = 0;
+	if (termios->c_iflag & IGNPAR)
+		port->ignore_status_mask |=
+			STAT_FRM_ERR | STAT_PAR_ERR | STAT_OVR_ERR;
+
+	if ((termios->c_cflag & CREAD) == 0)
+		port->ignore_status_mask |= STAT_RX_RDY | STAT_BRK_ERR;
+
+	if (old)
+		tty_termios_copy_hw(termios, old);
+
+	baud = uart_get_baud_rate(port, termios, old, 0, 460800);
+	uart_update_timeout(port, termios->c_cflag, baud);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *mvebu_uart_type(struct uart_port *port)
+{
+	return MVEBU_UART_TYPE;
+}
+
+static void mvebu_uart_release_port(struct uart_port *port)
+{
+	/* Nothing to do here */
+}
+
+static int mvebu_uart_request_port(struct uart_port *port)
+{
+	return 0;
+}
+
+#ifdef CONFIG_CONSOLE_POLL
+static int mvebu_uart_get_poll_char(struct uart_port *port)
+{
+	unsigned int st = readl(port->membase + UART_STAT);
+
+	if (!(st & STAT_RX_RDY))
+		return NO_POLL_CHAR;
+
+	return readl(port->membase + UART_RBR);
+}
+
+static void mvebu_uart_put_poll_char(struct uart_port *port, unsigned char c)
+{
+	unsigned int st;
+
+	for (;;) {
+		st = readl(port->membase + UART_STAT);
+
+		if (!(st & STAT_TX_FIFO_FUL))
+			break;
+
+		udelay(1);
+	}
+
+	writel(c, port->membase + UART_TSH);
+}
+#endif
+
+static const struct uart_ops mvebu_uart_ops = {
+	.tx_empty	= mvebu_uart_tx_empty,
+	.set_mctrl	= mvebu_uart_set_mctrl,
+	.get_mctrl	= mvebu_uart_get_mctrl,
+	.stop_tx	= mvebu_uart_stop_tx,
+	.start_tx	= mvebu_uart_start_tx,
+	.stop_rx	= mvebu_uart_stop_rx,
+	.break_ctl	= mvebu_uart_break_ctl,
+	.startup	= mvebu_uart_startup,
+	.shutdown	= mvebu_uart_shutdown,
+	.set_termios	= mvebu_uart_set_termios,
+	.type		= mvebu_uart_type,
+	.release_port	= mvebu_uart_release_port,
+	.request_port	= mvebu_uart_request_port,
+#ifdef CONFIG_CONSOLE_POLL
+	.poll_get_char	= mvebu_uart_get_poll_char,
+	.poll_put_char	= mvebu_uart_put_poll_char,
+#endif
+};
+
+/* Console Driver Operations  */
+
+#ifdef CONFIG_SERIAL_MVEBU_CONSOLE
+/* Early Console */
+static void mvebu_uart_putc(struct uart_port *port, int c)
+{
+	unsigned int st;
+
+	for (;;) {
+		st = readl(port->membase + UART_STAT);
+		if (!(st & STAT_TX_FIFO_FUL))
+			break;
+	}
+
+	writel(c, port->membase + UART_TSH);
+
+	for (;;) {
+		st = readl(port->membase + UART_STAT);
+		if (st & STAT_TX_FIFO_EMP)
+			break;
+	}
+}
+
+static void mvebu_uart_putc_early_write(struct console *con,
+					const char *s,
+					unsigned n)
+{
+	struct earlycon_device *dev = con->data;
+
+	uart_console_write(&dev->port, s, n, mvebu_uart_putc);
+}
+
+static int __init
+mvebu_uart_early_console_setup(struct earlycon_device *device,
+			       const char *opt)
+{
+	if (!device->port.membase)
+		return -ENODEV;
+
+	device->con->write = mvebu_uart_putc_early_write;
+
+	return 0;
+}
+
+EARLYCON_DECLARE(ar3700_uart, mvebu_uart_early_console_setup);
+OF_EARLYCON_DECLARE(ar3700_uart, "marvell,armada-3700-uart",
+		    mvebu_uart_early_console_setup);
+
+static void wait_for_xmitr(struct uart_port *port)
+{
+	u32 val;
+
+	readl_poll_timeout_atomic(port->membase + UART_STAT, val,
+				  (val & STAT_TX_EMP), 1, 10000);
+}
+
+static void mvebu_uart_console_putchar(struct uart_port *port, int ch)
+{
+	wait_for_xmitr(port);
+	writel(ch, port->membase + UART_TSH);
+}
+
+static void mvebu_uart_console_write(struct console *co, const char *s,
+				     unsigned int count)
+{
+	struct uart_port *port = &mvebu_uart_ports[co->index];
+	unsigned long flags;
+	unsigned int ier;
+	int locked = 1;
+
+	if (oops_in_progress)
+		locked = spin_trylock_irqsave(&port->lock, flags);
+	else
+		spin_lock_irqsave(&port->lock, flags);
+
+	ier = readl(port->membase + UART_CTRL) &
+		(CTRL_RX_INT | CTRL_TX_RDY_INT);
+	writel(0, port->membase + UART_CTRL);
+
+	uart_console_write(port, s, count, mvebu_uart_console_putchar);
+
+	wait_for_xmitr(port);
+
+	if (ier)
+		writel(ier, port->membase + UART_CTRL);
+
+	if (locked)
+		spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static int mvebu_uart_console_setup(struct console *co, char *options)
+{
+	struct uart_port *port;
+	int baud = 9600;
+	int bits = 8;
+	int parity = 'n';
+	int flow = 'n';
+
+	if (co->index < 0 || co->index >= MVEBU_NR_UARTS)
+		return -EINVAL;
+
+	port = &mvebu_uart_ports[co->index];
+
+	if (!port->mapbase || !port->membase) {
+		pr_debug("console on ttyS%i not present\n", co->index);
+		return -ENODEV;
+	}
+
+	if (options)
+		uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+	return uart_set_options(port, co, baud, parity, bits, flow);
+}
+
+static struct uart_driver mvebu_uart_driver;
+
+static struct console mvebu_uart_console = {
+	.name	= "ttyS",
+	.write	= mvebu_uart_console_write,
+	.device	= uart_console_device,
+	.setup	= mvebu_uart_console_setup,
+	.flags	= CON_PRINTBUFFER,
+	.index	= -1,
+	.data	= &mvebu_uart_driver,
+};
+
+static int __init mvebu_uart_console_init(void)
+{
+	register_console(&mvebu_uart_console);
+	return 0;
+}
+
+console_initcall(mvebu_uart_console_init);
+
+
+#endif /* CONFIG_SERIAL_MVEBU_CONSOLE */
+
+static struct uart_driver mvebu_uart_driver = {
+	.owner			= THIS_MODULE,
+	.driver_name		= "serial",
+	.dev_name		= "ttyMV",
+	.nr			= MVEBU_NR_UARTS,
+#ifdef CONFIG_SERIAL_MVEBU_CONSOLE
+	.cons			= &mvebu_uart_console,
+#endif
+};
+
+static int mvebu_uart_probe(struct platform_device *pdev)
+{
+	struct resource *reg = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	struct resource *irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+	struct uart_port *port;
+	struct mvebu_uart_data *data;
+	int ret;
+
+	if (!reg || !irq) {
+		dev_err(&pdev->dev, "no registers/irq defined\n");
+		return -EINVAL;
+	}
+
+	port = &mvebu_uart_ports[0];
+
+	spin_lock_init(&port->lock);
+
+	port->dev        = &pdev->dev;
+	port->type       = PORT_MVEBU;
+	port->ops        = &mvebu_uart_ops;
+	port->regshift   = 0;
+
+	port->fifosize   = 32;
+	port->iotype     = UPIO_MEM32;
+	port->flags      = UPF_FIXED_PORT;
+	port->line       = 0; /* single port: force line number to  0 */
+
+	port->irq        = irq->start;
+	port->irqflags   = 0;
+	port->mapbase    = reg->start;
+
+	port->membase = devm_ioremap_resource(&pdev->dev, reg);
+	if (IS_ERR(port->membase))
+		return -PTR_ERR(port->membase);
+
+	data = devm_kzalloc(&pdev->dev, sizeof(struct mvebu_uart_data),
+			    GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->port = port;
+
+	port->private_data = data;
+	platform_set_drvdata(pdev, data);
+
+	ret = uart_add_one_port(&mvebu_uart_driver, port);
+	if (ret)
+		return ret;
+	return 0;
+}
+
+static int mvebu_uart_remove(struct platform_device *pdev)
+{
+	struct mvebu_uart_data *data = platform_get_drvdata(pdev);
+
+	uart_remove_one_port(&mvebu_uart_driver, data->port);
+	data->port->private_data = NULL;
+	data->port->mapbase      = 0;
+	return 0;
+}
+
+/* Match table for of_platform binding */
+static const struct of_device_id mvebu_uart_of_match[] = {
+	{ .compatible = "marvell,armada-3700-uart", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, mvebu_uart_of_match);
+
+static struct platform_driver mvebu_uart_platform_driver = {
+	.probe	= mvebu_uart_probe,
+	.remove	= mvebu_uart_remove,
+	.driver	= {
+		.owner	= THIS_MODULE,
+		.name  = "mvebu-uart",
+		.of_match_table = of_match_ptr(mvebu_uart_of_match),
+	},
+};
+
+static int __init mvebu_uart_init(void)
+{
+	int ret;
+
+	ret = uart_register_driver(&mvebu_uart_driver);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&mvebu_uart_platform_driver);
+	if (ret)
+		uart_unregister_driver(&mvebu_uart_driver);
+
+	return ret;
+}
+
+static void __exit mvebu_uart_exit(void)
+{
+	platform_driver_unregister(&mvebu_uart_platform_driver);
+	uart_unregister_driver(&mvebu_uart_driver);
+}
+
+arch_initcall(mvebu_uart_init);
+module_exit(mvebu_uart_exit);
+
+MODULE_AUTHOR("Wilson Ding <dingwei at marvell.com>");
+MODULE_DESCRIPTION("Marvell Armada-3700 Serial Driver");
+MODULE_LICENSE("GPL");
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 3e5d757407fb..e513a4ee369b 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -261,4 +261,7 @@
 /* STM32 USART */
 #define PORT_STM32	113
 
+/* MVEBU UART */
+#define PORT_MVEBU	114
+
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
2.5.0



From mathieu.poirier at linaro.org  Wed Feb  3 10:39:10 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:10 -0700
Subject: [PATCH V9 12/18] coresight: etm3x: implementing user/kernel mode
 tracing
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-13-git-send-email-mathieu.poirier@linaro.org>

Adding new mode to limit tracing to kernel or user space.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm.h        |  6 ++-
 .../hwtracing/coresight/coresight-etm3x-sysfs.c    |  4 ++
 drivers/hwtracing/coresight/coresight-etm3x.c      | 63 ++++++++++++++++++++++
 drivers/hwtracing/coresight/coresight-priv.h       |  3 ++
 4 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
index 44585d4adb26..51597cb2c08a 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -110,7 +110,10 @@
 #define ETM_MODE_STALL		BIT(2)
 #define ETM_MODE_TIMESTAMP	BIT(3)
 #define ETM_MODE_CTXID		BIT(4)
-#define ETM_MODE_ALL		0x1f
+#define ETM_MODE_ALL		(ETM_MODE_EXCLUDE | ETM_MODE_CYCACC | \
+				 ETM_MODE_STALL | ETM_MODE_TIMESTAMP | \
+				 ETM_MODE_CTXID | ETM_MODE_EXCL_KERN | \
+				 ETM_MODE_EXCL_USER)
 
 #define ETM_SQR_MASK		0x3
 #define ETM_TRACEID_MASK	0x3f
@@ -296,5 +299,6 @@ static inline unsigned int etm_readl(struct etm_drvdata *drvdata, u32 off)
 extern const struct attribute_group *coresight_etm_groups[];
 int etm_get_trace_id(struct etm_drvdata *drvdata);
 void etm_set_default(struct etm_config *config);
+void etm_config_trace_mode(struct etm_config *config);
 struct etm_config *get_etm_config(struct etm_drvdata *drvdata);
 #endif
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
index 387c79fd9d5e..cbb4046c1070 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
@@ -162,6 +162,10 @@ static ssize_t mode_store(struct device *dev,
 		config->ctrl |= ETMCR_CTXID_SIZE;
 	else
 		config->ctrl &= ~ETMCR_CTXID_SIZE;
+
+	if (config->mode & (ETM_MODE_EXCL_KERN | ETM_MODE_EXCL_USER))
+		etm_config_trace_mode(config);
+
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 34a69583ccbc..c82d545e68ef 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -234,6 +234,69 @@ void etm_set_default(struct etm_config *config)
 	config->ctxid_mask = 0x0;
 }
 
+void etm_config_trace_mode(struct etm_config *config)
+{
+	u32 flags, mode;
+
+	mode = config->mode;
+
+	mode &= (ETM_MODE_EXCL_KERN | ETM_MODE_EXCL_USER);
+
+	/* excluding kernel AND user space doesn't make sense */
+	if (mode == (ETM_MODE_EXCL_KERN | ETM_MODE_EXCL_USER))
+		return;
+
+	/* nothing to do if neither flags are set */
+	if (!(mode & ETM_MODE_EXCL_KERN) && !(mode & ETM_MODE_EXCL_USER))
+		return;
+
+	flags = (1 << 0 |	/* instruction execute */
+		 3 << 3 |	/* ARM instruction */
+		 0 << 5 |	/* No data value comparison */
+		 0 << 7 |	/* No exact mach */
+		 0 << 8);	/* Ignore context ID */
+
+	/* No need to worry about single address comparators. */
+	config->enable_ctrl2 = 0x0;
+
+	/* Bit 0 is address range comparator 1 */
+	config->enable_ctrl1 = ETMTECR1_ADDR_COMP_1;
+
+	/*
+	 * On ETMv3.5:
+	 * ETMACTRn[13,11] == Non-secure state comparison control
+	 * ETMACTRn[12,10] == Secure state comparison control
+	 *
+	 * b00 == Match in all modes in this state
+	 * b01 == Do not match in any more in this state
+	 * b10 == Match in all modes excepts user mode in this state
+	 * b11 == Match only in user mode in this state
+	 */
+
+	/* Tracing in secure mode is not supported at this time */
+	flags |= (0 << 12 | 1 << 10);
+
+	if (mode & ETM_MODE_EXCL_USER) {
+		/* exclude user, match all modes except user mode */
+		flags |= (1 << 13 | 0 << 11);
+	} else {
+		/* exclude kernel, match only in user mode */
+		flags |= (1 << 13 | 1 << 11);
+	}
+
+	/*
+	 * The ETMEEVR register is already set to "hard wire A".  As such
+	 * all there is to do is setup an address comparator that spans
+	 * the entire address range and configure the state and mode bits.
+	 */
+	config->addr_val[0] = (u32) 0x0;
+	config->addr_val[1] = (u32) ~0x0;
+	config->addr_acctype[0] = flags;
+	config->addr_acctype[1] = flags;
+	config->addr_type[0] = ETM_ADDR_TYPE_RANGE;
+	config->addr_type[1] = ETM_ADDR_TYPE_RANGE;
+}
+
 static void etm_enable_hw(void *info)
 {
 	int i;
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index ed116b303e87..932f34a84d96 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -34,6 +34,9 @@
 #define TIMEOUT_US		100
 #define BMVAL(val, lsb, msb)	((val & GENMASK(msb, lsb)) >> lsb)
 
+#define ETM_MODE_EXCL_KERN	BIT(30)
+#define ETM_MODE_EXCL_USER	BIT(31)
+
 enum cs_mode {
 	CS_MODE_DISABLED,
 	CS_MODE_SYSFS,
-- 
2.1.4



From gregory.clement at free-electrons.com  Wed Feb  3 10:41:21 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed,  3 Feb 2016 19:41:21 +0100
Subject: [PATCH v2 04/12] ata: ahci_mvebu: add support for Armada 3700 variant
In-Reply-To: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454524889-9207-5-git-send-email-gregory.clement@free-electrons.com>

From: Lior Amsalem <alior at marvell.com>

The main difference in the new Armada 3700 is that no address
decoding needs to take place in the driver probe.

[gregory.clement at free-electrons.com: reformulate the commit log]

Signed-off-by: Lior Amsalem <alior at marvell.com>
Reviewed-by: Nadav Haklai <nadavh at marvell.com>
Tested-by: Nadav Haklai <nadavh at marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/ata/ahci_mvebu.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/ata/ahci_mvebu.c b/drivers/ata/ahci_mvebu.c
index f7a7fa81740e..de7128d81e9c 100644
--- a/drivers/ata/ahci_mvebu.c
+++ b/drivers/ata/ahci_mvebu.c
@@ -112,12 +112,15 @@ static int ahci_mvebu_probe(struct platform_device *pdev)
 	if (rc)
 		return rc;
 
-	dram = mv_mbus_dram_info();
-	if (!dram)
-		return -ENODEV;
+	if (of_device_is_compatible(pdev->dev.of_node,
+				    "marvell,armada-380-ahci")) {
+		dram = mv_mbus_dram_info();
+		if (!dram)
+			return -ENODEV;
 
-	ahci_mvebu_mbus_config(hpriv, dram);
-	ahci_mvebu_regret_option(hpriv);
+		ahci_mvebu_mbus_config(hpriv, dram);
+		ahci_mvebu_regret_option(hpriv);
+	}
 
 	rc = ahci_platform_init_host(pdev, hpriv, &ahci_mvebu_port_info,
 				     &ahci_platform_sht);
@@ -133,6 +136,7 @@ disable_resources:
 
 static const struct of_device_id ahci_mvebu_of_match[] = {
 	{ .compatible = "marvell,armada-380-ahci", },
+	{ .compatible = "marvell,armada-3700-ahci", },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, ahci_mvebu_of_match);
-- 
2.5.0



From gregory.clement at free-electrons.com  Wed Feb  3 10:41:23 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed,  3 Feb 2016 19:41:23 +0100
Subject: [PATCH v2 06/12] Documentation: dt-bindings: Add a new compatible for
 the Armada 3700
In-Reply-To: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454524889-9207-7-git-send-email-gregory.clement@free-electrons.com>

The AHCI interfaces used in the Armada 3700 has a few differences with
the one used in the Armada 38x, so it deserves its own compatible string.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/ata/ahci-platform.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index c2340eeeb97f..796e2c23e5df 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -13,6 +13,7 @@ Required properties:
   - "hisilicon,hisi-ahci"
   - "ibm,476gtr-ahci"
   - "marvell,armada-380-ahci"
+  - "marvell,armada-3700-ahci"
   - "snps,dwc-ahci"
   - "snps,exynos5440-ahci"
   - "snps,spear-ahci"
-- 
2.5.0



From gregory.clement at free-electrons.com  Wed Feb  3 10:41:24 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed,  3 Feb 2016 19:41:24 +0100
Subject: [PATCH v2 07/12] Documentation: dt: Tidy up the Marvell related files
In-Reply-To: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454524889-9207-8-git-send-email-gregory.clement@free-electrons.com>

Over the last releases we have added more and more Marvell related binding
directly in the arm directory. It's time to have our proper directory
inside it, and move all the files in it.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/arm/{ => marvell}/armada-370-xp-pmsu.txt          | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp.txt     | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-375.txt        | 0
 .../devicetree/bindings/arm/{ => marvell}/armada-380-mpcore-soc-ctrl.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-38x.txt        | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-39x.txt        | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-cpu-reset.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/coherency-fabric.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/kirkwood.txt          | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/marvell,berlin.txt    | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/marvell,dove.txt      | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/marvell,kirkwood.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-cpu-config.txt  | 0
 .../devicetree/bindings/arm/{ => marvell}/mvebu-system-controller.txt     | 0
 14 files changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp-pmsu.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-375.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-380-mpcore-soc-ctrl.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-38x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-39x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-cpu-reset.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/coherency-fabric.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,berlin.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,dove.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-cpu-config.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-system-controller.txt (100%)

diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt b/Documentation/devicetree/bindings/arm/marvell/armada-370-xp-pmsu.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-370-xp-pmsu.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp.txt b/Documentation/devicetree/bindings/arm/marvell/armada-370-xp.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-370-xp.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-370-xp.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-375.txt b/Documentation/devicetree/bindings/arm/marvell/armada-375.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-375.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-375.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-38x.txt b/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-38x.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-39x.txt b/Documentation/devicetree/bindings/arm/marvell/armada-39x.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-39x.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-39x.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-cpu-reset.txt b/Documentation/devicetree/bindings/arm/marvell/armada-cpu-reset.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-cpu-reset.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-cpu-reset.txt
diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/marvell/coherency-fabric.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/coherency-fabric.txt
rename to Documentation/devicetree/bindings/arm/marvell/coherency-fabric.txt
diff --git a/Documentation/devicetree/bindings/arm/kirkwood.txt b/Documentation/devicetree/bindings/arm/marvell/kirkwood.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/kirkwood.txt
rename to Documentation/devicetree/bindings/arm/marvell/kirkwood.txt
diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,berlin.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/marvell,berlin.txt
rename to Documentation/devicetree/bindings/arm/marvell/marvell,berlin.txt
diff --git a/Documentation/devicetree/bindings/arm/marvell,dove.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,dove.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/marvell,dove.txt
rename to Documentation/devicetree/bindings/arm/marvell/marvell,dove.txt
diff --git a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
rename to Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.txt
diff --git a/Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt b/Documentation/devicetree/bindings/arm/marvell/mvebu-cpu-config.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt
rename to Documentation/devicetree/bindings/arm/marvell/mvebu-cpu-config.txt
diff --git a/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/mvebu-system-controller.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/mvebu-system-controller.txt
rename to Documentation/devicetree/bindings/arm/marvell/mvebu-system-controller.txt
-- 
2.5.0



From will.deacon at arm.com  Wed Feb  3 10:40:18 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 3 Feb 2016 18:40:18 +0000
Subject: [PATCH] dt-bindings: arm, gic-v3: require that reserved cells are
 always 0
In-Reply-To: <20160203182054.GH1234@leverpostej>
References: <1454522458-29643-1-git-send-email-will.deacon@arm.com>
 <20160203182054.GH1234@leverpostej>
Message-ID: <20160203184017.GA15852@arm.com>

On Wed, Feb 03, 2016 at 06:20:54PM +0000, Mark Rutland wrote:
> On Wed, Feb 03, 2016 at 06:00:58PM +0000, Will Deacon wrote:
> > Consequently, any extensions to the PPI or SPI interrupt specifiers must
> > be able to work with random crap from legacy DTs, effectively
> > necessitating a new interrupt type in the first cell. Sigh.
> 
> I'm not sure that's true if we allocate a new value for the 1st cell for
> "extended" PPI or SPI interrupt-sepcficiers (which presumably add
> restrictions). That would also allow old kernels to safely skip such
> interrupts rather than mis-parsing them.

Right, that's what I said :)

> > This patch fixes the text so that additional, reserved cells are
> > required to be zero. This looks like a reasonable thing to require and
> > is already satisifed by the .dts files in-tree.
> > 
> > Cc: Mark Rutland <mark.rutland at arm.com>
> > Cc: Marc Zyngier <marc.zyngier at arm.com>
> > Signed-off-by: Will Deacon <will.deacon at arm.com>
> 
> This patch itself makes sense, so FWIW:
> 
> Acked-by: Mark Rutland <mark.rutland at arm.com>
> 
> Any proposed extention to the binding requires its own discussion.

Yup.

Marc -- can you queue this please?

Will


From gregory.clement at free-electrons.com  Wed Feb  3 10:41:19 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed,  3 Feb 2016 19:41:19 +0100
Subject: [PATCH v2 02/12] irqchip: armada-370-xp: do not enable it by default
 when ARCH_MVEBU is selected
In-Reply-To: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454524889-9207-3-git-send-email-gregory.clement@free-electrons.com>

The irq-armada-370-xp driver can only be built for ARM 32 bits. The mvebu
family had grown with a new ARM64 SoC which will also select the
ARCH_MEVBU configuration. Since "ARM: mvebu: use the ARMADA_370_XP_IRQ
option", the ARM32 mvebu SoC directly select this new option. Selecting
it by default when ARCH_MEVBU is selected is no more needed.

This patch removes this dependency, thanks to this, a kernel for ARM64
mvebu SoC can be built without error due this driver.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/irqchip/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index e2cab879d641..b6e7e86a57e1 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -62,7 +62,6 @@ config ARM_VIC_NR
 
 config ARMADA_370_XP_IRQ
 	bool
-	default y if ARCH_MVEBU
 	select GENERIC_IRQ_CHIP
 
 config ATMEL_AIC_IRQ
-- 
2.5.0



From gregory.clement at free-electrons.com  Wed Feb  3 10:41:17 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed,  3 Feb 2016 19:41:17 +0100
Subject: [PATCH v2 00/12] Add support for the Armada 3700 SoC an mvebu ARM64
 based
Message-ID: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>

Hi,

This series introduce the support of the Armada 3700 family: it is the
first ARM64 SoC of the mvebu family submitted to the mainline!

Currently there are two members of the Armada 3700 family, the only
difference is the number of core: the Armada 3710 comes with one
Cortex-A53 whereas the Armada 3720 comes with 2 Cortex-A53. In this
series we enabled only the minimum to boot, pinctrl and clock tree
will come soon.

This is the second version of the series, see the changelog for the
detail. The bigger change was the addition of two itqchip patches to
be able to use the the ARCH_MVEBU for the Armada 3700 SoCs. The first
ones is only here to have standalone series but it comes from Thomas
Petazzoni's series:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/472625

Then on top of it I added a small patch allowing building the kernel
without this driver for ARM64. So now there is a dependency :/

Besides this the patches are pretty usual:

The third patch introduces a new serial driver for the uart used on
this SoC. The driver remains simple even if the hardware is capable of
doing more.

The forth one adapts the ahci driver to support the Armada 3700 SoC.
The forth patch updates the binding documentation with the new
compatible string.

The fifth patch adds a new entry Kconfig entry for this SoC family.

I took the opportunity of this series to tidy up the Marvell related
files in the binding documentation with the seventh patch.

The eighth patch introduces the compatible string for the SoCs of the
Armada 3700 family.

The ninth patch could be considered as the bulk of this series: it
adds the device tree files for the Armada 3700 SoCs and for the
reference board.

With the introduction of this new family the MAINTAINERS file, the
Marvell README and the ARM64 defconfig files have to be updated: it is
the purpose of the last 3 patches.

The patches 3 and 4 could be taken directly by the maintainer of their
respective subsystem as there is no dependency at all with the rest of
the series. I think that the rest of the series should go through the
arm-soc maintainer but in doubt I also added the ARM64 maintainer as
suggested by get_maintainer.pl. 

Thanks,

Gregory

Changelog:
v1 -> v2
- Added Rob acked-by on patches 3, 6 and 7
- Used armada3700_uart instead of mvebu_uart for the uart driver:
  suggested by Mark
- In mvebu-uart, do not use anymore TTY_MAJOR, or ttyS, but dynamic
  major and ttyMV: pointed by Alan
- Use tty_termios_copy_hw in mvebu_uart_set_termios: suggested by Alan
- Use ARCH_MVEBU instead of creating ARCH_ARMADA_3700: suggested by
  Jisheng
- Added a new irqchip pacthes to fix build on ARM64 when ARCH_MVEBU is
  selected
- Removed marvell,armada3700 from the device tree binding and directly
  used marvell,armada3710 for common feature: pointed by Rob
- Fix memory node with coorect size in armada-3720-db.dts: suggested
  by Mark

Gregory CLEMENT (9):
  irqchip: armada-370-xp: do not enable it by default when ARCH_MVEBU is
    selected
  arm64: add mvebu architecture entry
  Documentation: dt-bindings: Add a new compatible for the Armada 3700
  Documentation: dt: Tidy up the Marvell related files
  devicetree: bindings: add DT binding for the Marvell Armada 3700 SoC
    family
  arm64: dts: add the Marvell Armada 3700 family and a development board
  MAINTAINERS: Extend dts entry for ARM64 mvebu files
  Documentation: arm: update supported Marvell EBU processors
  arm64: defconfig: enable Armada 3700 related config

Lior Amsalem (1):
  ata: ahci_mvebu: add support for Armada 3700 variant

Thomas Petazzoni (1):
  irqchip: armada-370-xp: add Kconfig option for the driver

Wilson Ding (1):
  serial: mvebu-uart: initial support for Armada-3700 serial port

 Documentation/arm/Marvell/README                   |  13 +
 .../arm/{ => marvell}/armada-370-xp-pmsu.txt       |   0
 .../bindings/arm/{ => marvell}/armada-370-xp.txt   |   0
 .../bindings/arm/{ => marvell}/armada-375.txt      |   0
 .../bindings/arm/marvell/armada-37xx.txt           |  16 +
 .../{ => marvell}/armada-380-mpcore-soc-ctrl.txt   |   0
 .../bindings/arm/{ => marvell}/armada-38x.txt      |   0
 .../bindings/arm/{ => marvell}/armada-39x.txt      |   0
 .../arm/{ => marvell}/armada-cpu-reset.txt         |   0
 .../arm/{ => marvell}/coherency-fabric.txt         |   0
 .../bindings/arm/{ => marvell}/kirkwood.txt        |   0
 .../bindings/arm/{ => marvell}/marvell,berlin.txt  |   0
 .../bindings/arm/{ => marvell}/marvell,dove.txt    |   0
 .../arm/{ => marvell}/marvell,kirkwood.txt         |   0
 .../arm/{ => marvell}/mvebu-cpu-config.txt         |   0
 .../arm/{ => marvell}/mvebu-system-controller.txt  |   0
 .../devicetree/bindings/ata/ahci-platform.txt      |   1 +
 .../devicetree/bindings/tty/serial/mvebu-uart.txt  |  13 +
 Documentation/kernel-parameters.txt                |   6 +
 MAINTAINERS                                        |   1 +
 arch/arm64/Kconfig.platforms                       |   6 +
 arch/arm64/boot/dts/marvell/Makefile               |   4 +
 arch/arm64/boot/dts/marvell/armada-371x.dtsi       |  53 ++
 arch/arm64/boot/dts/marvell/armada-3720-db.dts     |  86 +++
 arch/arm64/boot/dts/marvell/armada-372x.dtsi       |  63 ++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi       | 131 +++++
 arch/arm64/configs/defconfig                       |   5 +
 drivers/ata/ahci_mvebu.c                           |  14 +-
 drivers/irqchip/Kconfig                            |   4 +
 drivers/irqchip/Makefile                           |   2 +-
 drivers/tty/serial/Kconfig                         |  22 +
 drivers/tty/serial/Makefile                        |   1 +
 drivers/tty/serial/mvebu-uart.c                    | 650 +++++++++++++++++++++
 include/uapi/linux/serial_core.h                   |   3 +
 34 files changed, 1088 insertions(+), 6 deletions(-)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp-pmsu.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-375.txt (100%)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-380-mpcore-soc-ctrl.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-38x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-39x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-cpu-reset.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/coherency-fabric.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,berlin.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,dove.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-cpu-config.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-system-controller.txt (100%)
 create mode 100644 Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
 create mode 100644 arch/arm64/boot/dts/marvell/armada-371x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-db.dts
 create mode 100644 arch/arm64/boot/dts/marvell/armada-372x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-37xx.dtsi
 create mode 100644 drivers/tty/serial/mvebu-uart.c

-- 
2.5.0



From gregory.clement at free-electrons.com  Wed Feb  3 10:41:22 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed,  3 Feb 2016 19:41:22 +0100
Subject: [PATCH v2 05/12] arm64: add mvebu architecture entry
In-Reply-To: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454524889-9207-6-git-send-email-gregory.clement@free-electrons.com>

The Armada 3700 is an mvebu ARM64 SoC using one or two Cortex-A53 cores
depending of the variant.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm64/Kconfig.platforms | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f674bde..d6fee5cafcae 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -1,5 +1,11 @@
 menu "Platform selection"
 
+config ARCH_MVEBU
+	bool "Marvell EBU SoC Family"
+	help
+	  This enables support for Marvell EBU familly such as the
+	  Armada 3700 SoC Family.
+
 config ARCH_BCM_IPROC
 	bool "Broadcom iProc SoC Family"
 	help
-- 
2.5.0



From gregory.clement at free-electrons.com  Wed Feb  3 10:41:25 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed,  3 Feb 2016 19:41:25 +0100
Subject: [PATCH v2 08/12] devicetree: bindings: add DT binding for the Marvell
 Armada 3700 SoC family
In-Reply-To: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454524889-9207-9-git-send-email-gregory.clement@free-electrons.com>

The Marvell Armada 3700 is a family of ARMv8 CA53 SoCs. This commit
introduces the Device Tree binding that documents the top-level
compatible strings for Armada 3700 based platforms.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 .../devicetree/bindings/arm/marvell/armada-37xx.txt      | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
new file mode 100644
index 000000000000..17e90e8b5f76
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
@@ -0,0 +1,16 @@
+Marvell Armada 37xx Platforms Device Tree Bindings
+--------------------------------------------------
+
+Boards using a SoC of the Marvell Armada 37xx family must carry the
+following root node property:
+
+ - compatible: must contain "marvell,armada3710"
+
+In addition, boards using the Marvell Armada 3720 SoC shall have the
+following property before the previous one:
+
+ - compatible: must contain "marvell,armada3720"
+
+Example:
+
+compatible = "marvell,armada-3720-db", "marvell,armada3710", "marvell,armada3720";
-- 
2.5.0



From gregory.clement at free-electrons.com  Wed Feb  3 10:41:27 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed,  3 Feb 2016 19:41:27 +0100
Subject: [PATCH v2 10/12] MAINTAINERS: Extend dts entry for ARM64 mvebu files
In-Reply-To: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454524889-9207-11-git-send-email-gregory.clement@free-electrons.com>

Extend the mvebu entry to ARM64 device tree sources.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 30aca4aa5467..ad49b62c5abc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1279,6 +1279,7 @@ F:	arch/arm/mach-mvebu/
 F:	drivers/rtc/rtc-armada38x.c
 F:	arch/arm/boot/dts/armada*
 F:	arch/arm/boot/dts/kirkwood*
+F:	arch/arm64/boot/dts/marvell/armada*
 
 
 ARM/Marvell Berlin SoC support
-- 
2.5.0



From gregory.clement at free-electrons.com  Wed Feb  3 10:41:28 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed,  3 Feb 2016 19:41:28 +0100
Subject: [PATCH v2 11/12] Documentation: arm: update supported Marvell EBU
 processors
In-Reply-To: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454524889-9207-12-git-send-email-gregory.clement@free-electrons.com>

Now that we support Armada 37xx, let's add this family of SoC to the
Marvell documentation, and a reference to a link with more details about
those processors. As for Armda 39x, no datasheet is publicly
available at this time.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 Documentation/arm/Marvell/README | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index ae89b67d8e23..ddbc048bb467 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -118,6 +118,19 @@ EBU Armada family
   Linux kernel mach directory: arch/arm/mach-mvebu
   Linux kernel plat directory: none
 
+EBU Armada family ARMv8
+-----------------------
+
+  Armada 3710/3720 Flavors:
+	88F3710
+	88F3720
+
+  Core: ARM Cortex A53 (ARMv8)
+
+  Homepage     : http://www.marvell.com/embedded-processors/armada-3700/
+
+  Device tree descritpion located in arch/arm64/boot/dts/marvell/armada-37*
+
 Avanta family
 -------------
 
-- 
2.5.0



From gregory.clement at free-electrons.com  Wed Feb  3 10:41:29 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed,  3 Feb 2016 19:41:29 +0100
Subject: [PATCH v2 12/12] arm64: defconfig: enable Armada 3700 related config
In-Reply-To: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454524889-9207-13-git-send-email-gregory.clement@free-electrons.com>

This patch enables the configuration for the Armada 3700 family and for
the related driver it uses.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm64/configs/defconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 18ca9fb9e65f..7ca2f0247ec5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -31,6 +31,7 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_ARCH_MVEBU=y
 CONFIG_ARCH_BCM_IPROC=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_ARCH_EXYNOS7=y
@@ -93,6 +94,7 @@ CONFIG_ATA=y
 CONFIG_SATA_AHCI=y
 CONFIG_SATA_AHCI_PLATFORM=y
 CONFIG_AHCI_CEVA=y
+CONFIG_AHCI_MVEBU=y
 CONFIG_AHCI_XGENE=y
 CONFIG_SATA_RCAR=y
 CONFIG_PATA_PLATFORM=y
@@ -132,6 +134,7 @@ CONFIG_SERIAL_MSM_CONSOLE=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SERIAL_XILINX_PS_UART=y
 CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
+CONFIG_SERIAL_MVEBU_UART=y
 CONFIG_VIRTIO_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 CONFIG_I2C=y
@@ -162,6 +165,8 @@ CONFIG_SND_SOC=y
 CONFIG_SND_SOC_RCAR=y
 CONFIG_SND_SOC_AK4613=y
 CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_PLATFORM=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
 CONFIG_USB_OHCI_HCD=y
-- 
2.5.0



From mathieu.poirier at linaro.org  Wed Feb  3 10:39:12 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:12 -0700
Subject: [PATCH V9 14/18] coresight: etb10: moving to local atomic operations
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-15-git-send-email-mathieu.poirier@linaro.org>

Moving to use local atomic operations to take advantage of the
lockless implementation, something that will come handy when
the ETB is accessed from the Perf subsystem. Also changing the
name of the variable to something more meaningful.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etb10.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 917562ecf82a..162c9ccc8c33 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -10,6 +10,7 @@
  * GNU General Public License for more details.
  */
 
+#include <asm/local.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/init.h>
@@ -71,7 +72,7 @@
  * @csdev:	component vitals needed by the framework.
  * @miscdev:	specifics to handle "/dev/xyz.etb" entry.
  * @spinlock:	only one at a time pls.
- * @in_use:	synchronise user space access to etb buffer.
+ * @reading:	synchronise user space access to etb buffer.
  * @buf:	area of memory where ETB buffer content gets sent.
  * @buffer_depth: size of @buf.
  * @enable:	this ETB is being used.
@@ -84,7 +85,7 @@ struct etb_drvdata {
 	struct coresight_device	*csdev;
 	struct miscdevice	miscdev;
 	spinlock_t		spinlock;
-	atomic_t		in_use;
+	local_t			reading;
 	u8			*buf;
 	u32			buffer_depth;
 	bool			enable;
@@ -277,7 +278,7 @@ static int etb_open(struct inode *inode, struct file *file)
 	struct etb_drvdata *drvdata = container_of(file->private_data,
 						   struct etb_drvdata, miscdev);
 
-	if (atomic_cmpxchg(&drvdata->in_use, 0, 1))
+	if (local_cmpxchg(&drvdata->reading, 0, 1))
 		return -EBUSY;
 
 	dev_dbg(drvdata->dev, "%s: successfully opened\n", __func__);
@@ -313,7 +314,7 @@ static int etb_release(struct inode *inode, struct file *file)
 {
 	struct etb_drvdata *drvdata = container_of(file->private_data,
 						   struct etb_drvdata, miscdev);
-	atomic_set(&drvdata->in_use, 0);
+	local_set(&drvdata->reading, 0);
 
 	dev_dbg(drvdata->dev, "%s: released\n", __func__);
 	return 0;
-- 
2.1.4



From gregory.clement at free-electrons.com  Wed Feb  3 10:41:26 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed,  3 Feb 2016 19:41:26 +0100
Subject: [PATCH v2 09/12] arm64: dts: add the Marvell Armada 3700 family and a
 development board
In-Reply-To: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454524889-9207-10-git-send-email-gregory.clement@free-electrons.com>

Add initial dtsi files to support Marvell Armada 3700 SoC with Cortex-A53
CPUs. There are two members in this family: the Armada 3710 (Single CPU)
and the Armada 3720 (Dual CPUs).

It also adds a dts file for the Marvell Armada 3720 DB board.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm64/boot/dts/marvell/Makefile           |   4 +
 arch/arm64/boot/dts/marvell/armada-371x.dtsi   |  53 ++++++++++
 arch/arm64/boot/dts/marvell/armada-3720-db.dts |  86 ++++++++++++++++
 arch/arm64/boot/dts/marvell/armada-372x.dtsi   |  63 ++++++++++++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   | 131 +++++++++++++++++++++++++
 5 files changed, 337 insertions(+)
 create mode 100644 arch/arm64/boot/dts/marvell/armada-371x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-db.dts
 create mode 100644 arch/arm64/boot/dts/marvell/armada-372x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-37xx.dtsi

diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index 348f4db4f313..2114af8d312d 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -1,6 +1,10 @@
+# Berlin SoC Family
 dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-dmp.dtb
 dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
 
+# Mvebu SoC Family
+dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
+
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
 clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/marvell/armada-371x.dtsi b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
new file mode 100644
index 000000000000..c9e5325b8ac3
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
@@ -0,0 +1,53 @@
+/*
+ * Device Tree Include file for Marvell Armada 371x family of SoCs
+ * (also named 88F3710)
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "armada-37xx.dtsi"
+
+/ {
+	model = "Marvell Armada 3710 SoC";
+	compatible = "marvell,armada3710", "marvell,armada3700";
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
new file mode 100644
index 000000000000..359050154511
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -0,0 +1,86 @@
+/*
+ * Device Tree file for Marvell Armada 3720 development board
+ * (DB-88F3720-DDR3)
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "armada-372x.dtsi"
+
+/ {
+	model = "Marvell Armada 3720 Development Board DB-88F3720-DDR3";
+	compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x00000000 0x00000000 0x20000000>;
+	};
+
+	soc {
+		internal-regs {
+			/*
+			* Exported on the micro USB connector CON32
+			* through an FTDI
+			*/
+			uart0: serial at 12000 {
+				status = "okay";
+			};
+
+			/* CON31 */
+			usb3 at 58000 {
+				status = "okay";
+			};
+
+			/* CON3 */
+			sata at e0000 {
+			       status = "okay";
+			};
+		};
+	};
+};
+
diff --git a/arch/arm64/boot/dts/marvell/armada-372x.dtsi b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
new file mode 100644
index 000000000000..f292a00ce97c
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
@@ -0,0 +1,63 @@
+/*
+ * Device Tree Include file for Marvell Armada 372x family of SoCs
+ * (also named 88F3720)
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "armada-37xx.dtsi"
+
+/ {
+	model = "Marvell Armada 3720 SoC";
+	compatible = "marvell,armada3720", "marvell,armada3710";
+
+	cpus {
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53","arm,armv8";
+			reg = <0x1>;
+			enable-method = "psci";
+		};
+	};
+
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
new file mode 100644
index 000000000000..ba9df7ff2a72
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -0,0 +1,131 @@
+/*
+ * Device Tree Include file for Marvell Armada 37xx family of SoCs.
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	model = "Marvell Armada 37xx SoC";
+	compatible = "marvell,armada3700";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0>;
+			enable-method = "psci";
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		internal-regs {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "simple-bus";
+			/* 32M internal register @ 0xd000_0000 */
+			ranges = <0x0 0x0 0xd0000000 0x2000000>;
+
+			uart0: serial at 12000 {
+				compatible = "marvell,armada-3700-uart";
+				reg = <0x12000 0x400>;
+				interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+				status = "disabled";
+			};
+
+			usb3 at 58000 {
+				compatible = "generic-xhci";
+				reg = <0x58000 0x4000>;
+				interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+				status = "disabled";
+			};
+
+			sata at e0000 {
+				compatible = "marvell,armada-3700-ahci";
+				reg = <0xe0000 0x2000>;
+				interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+				status = "disabled";
+			};
+
+			gic: interrupt-controller at 1d00000 {
+				compatible = "arm,gic-v3";
+				#interrupt-cells = <3>;
+				interrupt-controller;
+				reg = <0x1d00000 0x10000>, /* GICD */
+				      <0x1d40000 0x40000>; /* GICR */
+			};
+		};
+	};
+};
-- 
2.5.0



From timur at codeaurora.org  Wed Feb  3 10:45:09 2016
From: timur at codeaurora.org (Timur Tabi)
Date: Wed, 3 Feb 2016 12:45:09 -0600
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
Message-ID: <56B24AB5.3070001@codeaurora.org>

Fu Wei wrote:
> As you know I have made the pre-timeout support patch, If people like
> it, i am happy to go on upstream it separately.
>
> If we want to use pre-timeout here, user only can use get_pretimeout
> and disable panic by setting pretimeout to 0
> but user can not really set pretimeout, because "pre-timeout  ==
> timeout / 2 (always)".
> if user want to change pretimeout, he/she has to set_time instead.

Ok, I think patches 4 and 5 should be combined, and I think the Kconfig 
entry should be removed and just use panic_enabled.


From tony at atomide.com  Wed Feb  3 10:45:05 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Feb 2016 10:45:05 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFonA4AAzx9JaQ2NZViMLvCjoa5vy2WRuhEF_5Hg8gPKeg@mail.gmail.com>
References: <CAPDyKFqQb+jtTpZbq6EvbfAk28yVkgdtiOswngNH_BjCWBDxFg@mail.gmail.com>
 <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>
 <20160202163536.GU19432@atomide.com>
 <CAPDyKFosQjkHDVSvy67+hstjjFseXQP5WYXrJE19GgVFYJ099w@mail.gmail.com>
 <20160202234145.GC19432@atomide.com>
 <CAPDyKFqLi8xOUeoxUTAmif5QrOjVpV_2CDLv4hjO_C9iOnv+5Q@mail.gmail.com>
 <20160203162705.GG19432@atomide.com>
 <CAPDyKFrsbW+vOoKBDvkNbJa=aUZE1EcikCqrAuO4cv+TkW-FnA@mail.gmail.com>
 <20160203182828.GM19432@atomide.com>
 <CAPDyKFonA4AAzx9JaQ2NZViMLvCjoa5vy2WRuhEF_5Hg8gPKeg@mail.gmail.com>
Message-ID: <20160203184504.GN19432@atomide.com>

* Ulf Hansson <ulf.hansson at linaro.org> [160203 10:38]:
> On 3 February 2016 at 19:28, Tony Lindgren <tony at atomide.com> wrote:
> > * Ulf Hansson <ulf.hansson at linaro.org> [160203 10:03]:
> >>
> >> One more thing though. I just realized that you have yet another issue
> >> to consider going for the approach fixing *only* drivers.
> >>
> >> Let me summarize it here:
> >>
> >> If userspace has prevented runtime PM (pm_runtime_forbid()) when a
> >> driver becomes unbound, the driver will not be able to suspend the
> >> device by using any of the pm_runtime_suspend() APIs, as the usage
> >> count is isn't zero.
> >>
> >> As pm_runtime_reinit() is invoked as part of the driver unbind
> >> sequence, the runtime PM status goes out of sync. A following driver
> >> rebind will then trigger the warning when the PM domain's
> >> ->runtime_resume() callback gets invoked. Again, forever preventing
> >> the device from being runtime suspended.
> >
> > Hmm yeah that's a good point.
> >
> >> How do you intend to solve this case?
> >> I guess there are two options, pick up the patch I posted for omap
> >> hwmod or make use of pm_runtime_force_suspend() in the driver.
> >
> > My gut feeling right now is we should just have
> > BUS_NOTIFY_UNBIND_DRIVER shut down the device on the interconnect
> > automatically as it's unused after the driver has unloaded :)
> 
> BUS_NOTIFY_UNBIND_DRIVER is sent prior the ->remove() callbacks is
> invoked from driver core.
> So if the driver requires to do a pm_runtime_get_sync() during
> ->remove() callback, this won't work.
> 
> BUS_NOTIFY_UNBOUND_DRIVER may work though.

Right sorry that's what I meant. Naturally we can't do it before
remove :)

I'll take a look.

Tony


From okaya at codeaurora.org  Wed Feb  3 10:46:03 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Wed, 3 Feb 2016 13:46:03 -0500
Subject: [PATCH V13 08/10] dma: qcom_hidma: read the channel id from HW
In-Reply-To: <20160203183650.GI1234@leverpostej>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-9-git-send-email-okaya@codeaurora.org>
 <20160201153542.GA20396@leverpostej> <56B247A1.20503@codeaurora.org>
 <20160203183650.GI1234@leverpostej>
Message-ID: <56B24AEB.9070405@codeaurora.org>

On 2/3/2016 1:36 PM, Mark Rutland wrote:
>> Can you please take a look and let me know?
> Sorry, but it's going to be far easier to review with useless code
> removed, so I will wait until the next posting where this patch is
> folded in.
> 
> Thanks,
> Mark.

OK, I'll post the next rev by the end of this week. 

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


From dianders at google.com  Wed Feb  3 11:04:20 2016
From: dianders at google.com (Doug Anderson)
Date: Wed, 3 Feb 2016 11:04:20 -0800
Subject: [PATCH v3 00/12] pwm: add support for atomic update
In-Reply-To: <20160203145337.GD9650@ulmo>
References: <1442828009-6241-1-git-send-email-boris.brezillon@free-electrons.com>
 <2341981.a79ioYM9Es@diego> <20151110173416.GB21727@ulmo>
 <CAD=FV=WL3jYEgVe-m6QcAyQwfJgdX4J5OtKisKwyoKOrTSpEQA@mail.gmail.com>
 <20160125170855.GA10182@ulmo>
 <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
 <20160203145337.GD9650@ulmo>
Message-ID: <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>

Thierry

On Wed, Feb 3, 2016 at 6:53 AM, Thierry Reding <thierry.reding at gmail.com> wrote:
>> A) The software state here is the period and flags (AKA "inverted),
>> right?  It does seem possible that you could apply the period and
>> flags while keeping the calculated bootup duty cycle percentage
>> (presuming that the PWM was actually enabled at probe time and there
>> was a bootup duty cycle at all).  That would basically say that
>> whenever you set the period of a PWM then the duty cycle of the PWM
>> should remain the same percentage.  That actually seems quite sane
>> IMHO.  It seems much saner than trying to keep the duty cycle "ns"
>> when the period changes or resetting the PWM to some default when the
>> period changes.
>
> That really depends on the use-case. If you're interested in the output
> power of the PWM then, yes, this is sane. But it might not be the right
> answer in other cases.

Ah, I see.  You're envisioning a device where active time in "ns" is
more important than the percentage of active time.  Perhaps an LED
where it's more important to have it on for no more than .1 seconds
(so we don't drive it too long and burn it out?).  If we slowed down
the duty cycle and adjusted the period to match, we could get into a
bad state.


>> B) Alternatively, I'd also say that setting a period without a duty
>> cycle doesn't make a lot of sense.  ...so you could just apply the
>> period at the same time that you apply the duty cycle the first time.
>> Presumably you'd want to "lie" to the callers of the PWM subsystem and
>> tell them that you already changed the period even though the change
>> won't really take effect until they actually set the duty cycle.  If
>> anyone cared to find out the true hardware period we could add a new
>> pwm_get_hw_period().  ...or since the only reason you'd want to know
>> the hardware period would be if you're trying to read the current duty
>> cycle percentage, you could instead add "pwm_get_hw_state()" and have
>> that return both the hardware period ns and duty cycle ns (which is
>> the most accurate way to return the "percentage" without using fix or
>> floating point math).
>
> But then you get into a situation where behaviour is dependent on the
> PWM driver, whereas this is really very specific to one specific use-
> case.

This is because only some drivers would be able to read the hardware
state?  I'm not sure how we can get away from that.  In all proposals
we've talked about (including what you propose below, right?) the PWM
regulator will need a PWM driver that can read hardware state.  Only
PWM drivers that have been upgraded to support reading hardware state
can use the PWM regulator (or at least only those drivers will be able
to use the PWM regulator glitch-free).

When we add a new feature then it's expected that only updated drivers
will support that feature.

We need to make sure that we don't regress / negatively change the
behavior for anyone running non-updated drivers.  ...and we should
strive to require as few changes to drivers as possible.  ...but if
the best we can do requires changes to the PWM driver API then we will
certainly have differences depending on the PWM driver.


> In the end the PWM API is as low-level as it is because it needs to be
> flexible enough to cope with other use-cases. In the general case the
> simple truth is that it doesn't make sense to set a period without the
> duty cycle and vice versa. That's why pwm_config() takes both as input
> parameters. The atomic API is going to take that one step further in
> that you need to specify the complete state of the PWM when applying.

I guess this is still showing the strangeness of the device tree
specifying a period without a duty cycle.  You just said it doesn't
make sense, but that's exactly what the device tree has.

I'd imagine that the only reason that the device tree specifies just
the period is that it's intended to be there only for clients that
don't care about the specific duty cycle in terms of seconds but
_only_ care about the duty cycle in terms of percentage.  Anyone who
cared about the duty cycle in terms of seconds would presumably also
care about specifying the period (in terms of seconds) in the same
place they specify the duty cycle.


>> I think this is like my suggestion B), right?  AKA the PWM regulator
>> would be the sole caller of pwm_get_hw_state() and it would use this
>> to figure out the existing duty cycle percentage.  Then it would
>> translate that into "ns" and would set the duty cycle.  Upon the first
>> set of the duty cycle both the period and duty cycle would be applied
>> at the same time.
>
> Yes and no. I think the PWM regulator would need to get the current
> hardware state and derive the output power from duty cycle and period.
> It would then need to rescale to whatever new period it wants to use
> to ensure the same output power is used.

Right.  We all agree that somehow this needs to happen, it's just a
question of the implementation.


>> > That doesn't really get us closer, though. There is still the issue of
>> > the user having to deal with two states: the current hardware state and
>> > the software state as configured in DT or board files.
>>
>> I think the only users that need to deal with this are one that need a
>> seamless transition from bootup settings.  Adding a new API call to
>> support a new feature like this doesn't seem insane, and anyone who
>> doesn't want this new feature can just never call the new API.
>>
>> The only thing that would "change" from the point of view of old
>> drivers is that the PWM period wouldn't change at bootup until the
>> duty cycle was set.  IMHO this is probably a bug fix.  AKA, for a PWM
>> backlight, imagine:
>>
>> 1. Firmware sets period to 20000 ns, duty cycle to 8000 ns (40%)
>> 2. Linux boots up and sets period to 10000 ns.  Brightness of
>> backlight instantly goes to 80%.
>> 3. Eventually something decides to set the backlight duty cycle and it
>> goes to the proper rate.
>>
>> Skipping #2 seems like the right move.  ...or did I misunderstand how
>> something works?
>
> I'm not aware of any code in the PWM subsystem that would do this
> automatically. If you don't call any of the pwm_*() functions the
> hardware state should not be modified. The responsibility is with
> the user drivers.

Ah, OK.  I must have gotten confused.

Oh, I see.  So pwm_get_period() is actually "lying" about the hardware
today!  So what you're saying is that at boot time we grab the period
out of the device tree but we _don't_ apply it to the hardware, right?
 I was thinking it would get applied right away...

That means that if you call pwm_get_period() right away at boot time
you're not getting the current period of the hardware but the period
that was specified in the device tree.

So all we need is a new API call that lets you read the hardware
values and make sure that the PWM regulator calls that before anyone
calls pwm_config().  That's roughly B) above.


> That is, it is up to the regulator or backlight driver to apply any new
> configuration to a PWM channel on boot, or leave it as is. For
> backlight it's probably fine to simply apply some default, since having
> the brightness change on boot isn't going to be terribly irritating.
>
> With the atomic API it would be possible to avoid even this and have the
> backlight driver simply read out the current hardware state and apply an
> equivalent brightness even if the period changed.
>
> For the regulator case you'd need to read out the current state and then
> recompute the values that will yield the same output power given data
> specified in DT. I think that much is already implemented in Boris'
> series, and it's really only the details that are being debated.
>
> The problematic issue is still that we might have a disparity between
> the current hardware state and the state initially specified by DT. In
> the general case the DT will specify the period and polarity of the PWM
> signal and leave it up to the user driver to determine what a correct
> duty cycle would be. With the atomic API we'll essentially have two
> states: the current (hardware) state and the "initial" state, which is
> what an OS will see as the state to apply. The problem now is that once
> you have applied the initial state with a duty cycle you've determined,
> there is no longer a need to keep it around. But there's also no way to
> know when this is the case. So the controversial part about all this is
> when to start using the current state rather that the initial state.
>
> The most straightforward way to solve this would be to apply the initial
> configuration on driver probe. That is, when the pwm-regulator driver
> gets probed it would retrieve the current and initial states, then
> adjust the current state such that it matches the initial state but with
> a duty cycle that yields the same output power as the current state, and
> finally apply the new state. After that, every regulator_set_voltage()
> call could simply operate on the current state and adjust the duty cycle
> exclusively.
>
> Does that sound reasonable?

Sure.  ...but you agree that somehow you need a new API call for this,
right?  Somehow the PWM regulator needs to be able to say that it
wants the hardware state, not the initial state as specified in the
device tree.


-Doug


From ard.biesheuvel at linaro.org  Wed Feb  3 11:04:53 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed,  3 Feb 2016 20:04:53 +0100
Subject: [PATCH v2 0/4] kallsyms: remove special handling for CONFIG_ARM
Message-ID: <1454526297-5269-1-git-send-email-ard.biesheuvel@linaro.org>

This series applies on top of today's -next, and addresses an issue with
the new kallsyms code that is queued there, that enables base relative
kallsyms tables for all architectures (except IA-64)

Two issues have surfaced on ARM with the new kallsyms code:
a) CONFIG_HAVE_TCM creates a virtual region that is too far away for the
   relative kallsyms code to reach it;
b) CONFIG_XIP_KERNEL=y kernel symbols are not filtered against PAGE_OFFSET,
   as is the case for kernels that execute from RAM, resulting in symbols
   that are out of range.

Since the way kallsyms deals with XIP kernels on ARM leaves some room for
improvement regardless of the base relative changes, this series proposes
a fix that allows the special case to be removed from the kallsyms handling
entirely.

Changes since v1:
- new patch #4 (optional, RFC)
- added Nico's ack to #1 - #3
- use PROVIDE() for vector_fiq_offset since vector_fiq itself is not always
  defined
- put __stubs_start/_end inside the section definition so that the value of the
  start symbol equals the start of the section after alignment (fixes an issue
  on XIP spotted by Chris)

Patch #1 moves the .stubs and .vectors section back into the kernel VMA, while
preserving the guaranteed virtual offset of 4 KB. This results in all symbols
that kallsyms sees to be in a reasonable interval.

Patch #2 removes the special case for CONFIG_ARM && !CONFIG_XIP_KERNEL in the
invocation of scripts/kallsyms

Patch #3 removes the now unused --page-offset command line argument handling
from scripts/kallsyms.c

Patch #4 is included as an RFC, it removes the magic constant 0x1000 which is
the offset between the start of the .vectors section and the start of the
.stubs section.

Note that we may still need to remove ARM from the list of architectures that
support base relative kallsyms tables if we cannot fix issue a) above, but
removing this special case seemed like an obvious improvement to me. Note the
a) is a pathological case where VMSPLIT_1G, KALLSYMS_ALL and HAVE_TCM are all
set.

Ard Biesheuvel (4):
  ARM: move .vectors and .stubs sections back into the kernel VMA
  kallsyms: remove special lower address limit for CONFIG_ARM
  kallsyms: remove --page-offset command line option
  ARM: use single definition for vectors-to-stubs section offset

 arch/arm/kernel/entry-armv.S  | 20 ++++++++++-----
 arch/arm/kernel/traps.c       |  4 ++-
 arch/arm/kernel/vmlinux.lds.S | 22 +++++++++++-----
 scripts/kallsyms.c            | 27 ++++----------------
 scripts/link-vmlinux.sh       |  4 ---
 5 files changed, 37 insertions(+), 40 deletions(-)

-- 
2.5.0



From ard.biesheuvel at linaro.org  Wed Feb  3 11:04:54 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed,  3 Feb 2016 20:04:54 +0100
Subject: [PATCH v2 1/4] ARM: move .vectors and .stubs sections back into the
 kernel VMA
In-Reply-To: <1454526297-5269-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454526297-5269-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454526297-5269-2-git-send-email-ard.biesheuvel@linaro.org>

Commit b9b32bf70f2f ("ARM: use linker magic for vectors and vector stubs")
updated the linker script to emit the .vectors and .stubs sections into a
VMA range that is zero based and disjoint from the normal static kernel
region. The reason for that was that this way, the sections can be placed
exactly 4 KB apart, while the payload of the .vectors section is only 32
bytes.

Since the symbols that are part of the .stubs section are emitted into the
kallsyms table, they appear with zero based addresses as well, e.g.,

  00000000 t __vectors_start
  00001000 t __stubs_start
  00001004 t vector_rst
  00001020 t vector_irq
  000010a0 t vector_dabt
  00001120 t vector_pabt
  000011a0 t vector_und
  00001220 t vector_addrexcptn
  00001240 t vector_fiq
  00001240 T vector_fiq_offset

As this confuses perf when it accesses the kallsyms tables, commit
7122c3e9154b ("scripts/link-vmlinux.sh: only filter kernel symbols for
arm") implemented a somewhat ugly special case for ARM, where the value
of CONFIG_PAGE_OFFSET is passed to scripts/kallsyms, and symbols whose
address is below it are filtered out. Note that this special case only
applies to CONFIG_XIP_KERNEL=n, not because the issue the patch addresses
exists only in that case, but because finding a limit below which to apply
the filtering is too difficult.

Since the constraint we are trying to meet here is that the .vectors
section lives exactly 4 KB before the .stubs section, regardless of the
absolute addresses of either (since relative branches are used to jump from
the vector table to the stubs), we can simply emit the .stubs section as
part of the kernel VMA, and place the .vectors section 4 KB before it using
an explicit VMA override. By doing that, and renaming the __vectors_start
symbol that is local to arch/arm/kernel/entry-armv.S (not the one in the
linker script), the kallsyms table looks somewhat sane, regardless of
whether CONFIG_XIP_KERNEL is set, and we can drop the special case in
scripts/kallsyms entirely. E.g.,

  00001240 A vector_fiq_offset
  ...
  c0c35000 T __init_begin
  c0c35000 t __stubs_start
  c0c35000 T __stubs_start
  c0c35004 t vector_rst
  c0c35020 t vector_irq
  c0c350a0 t vector_dabt
  c0c35120 t vector_pabt
  c0c351a0 t vector_und
  c0c35220 t vector_addrexcptn
  c0c35240 T vector_fiq
  c0c352c0 T __stubs_end
  c0c352c0 T __vectors_start
  c0c352e0 t __mmap_switched
  c0c352e0 T _sinittext
  c0c352e0 T __vectors_end

(Note that vector_fiq_offset is now an absolute symbol, which kallsyms
already ignores by default)

The sections themselves are emitted 4 KB apart, as required:
  ...
  [16] .stubs       PROGBITS   c0c35000 a35000 0002c0 00  AX  0   0 32
  [17] .vectors     PROGBITS   c0c34000 a44000 000020 00  AX  0   0  2
  ...

and the relative branches in the .vectors section still point to the
right place:

  c0c34000 <.vectors>:
  c0c34000:       f001 b800       b.w     c0c35004 <vector_rst>
  c0c34004:       f001 b8cc       b.w     c0c351a0 <vector_und>
  c0c34008:       f8df fff4       ldr.w   pc, [pc, #4084] ; c0c35000
  c0c3400c:       f001 b888       b.w     c0c35120 <vector_pabt>
  c0c34010:       f001 b846       b.w     c0c350a0 <vector_dabt>
  c0c34014:       f001 b904       b.w     c0c35220 <vector_addrexcptn>
  c0c34018:       f001 b802       b.w     c0c35020 <vector_irq>
  c0c3401c:       f001 b910       b.w     c0c35240 <vector_fiq>

Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm/kernel/entry-armv.S  |  7 +++----
 arch/arm/kernel/vmlinux.lds.S | 15 ++++++++-------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 3ce377f7251f..8575ff42c0d4 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -1202,14 +1202,13 @@ vector_addrexcptn:
 	.long	__fiq_svc			@  e
 	.long	__fiq_svc			@  f
 
-	.globl	vector_fiq_offset
-	.equ	vector_fiq_offset, vector_fiq
+	.globl	vector_fiq
 
 	.section .vectors, "ax", %progbits
-__vectors_start:
+.L__vectors_start:
 	W(b)	vector_rst
 	W(b)	vector_und
-	W(ldr)	pc, __vectors_start + 0x1000
+	W(ldr)	pc, .L__vectors_start + 0x1000
 	W(b)	vector_pabt
 	W(b)	vector_dabt
 	W(b)	vector_addrexcptn
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 8b60fde5ce48..9f96a54c7d90 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -164,19 +164,20 @@ SECTIONS
 	 * The vectors and stubs are relocatable code, and the
 	 * only thing that matters is their relative offsets
 	 */
+	.stubs : {
+		__stubs_start = .;
+		*(.stubs)
+		__stubs_end = .;
+	}
+
 	__vectors_start = .;
-	.vectors 0 : AT(__vectors_start) {
+	.vectors ADDR(.stubs) - 0x1000 : AT(__vectors_start) {
 		*(.vectors)
 	}
 	. = __vectors_start + SIZEOF(.vectors);
 	__vectors_end = .;
 
-	__stubs_start = .;
-	.stubs 0x1000 : AT(__stubs_start) {
-		*(.stubs)
-	}
-	. = __stubs_start + SIZEOF(.stubs);
-	__stubs_end = .;
+	PROVIDE(vector_fiq_offset = vector_fiq - ADDR(.vectors));
 
 	INIT_TEXT_SECTION(8)
 	.exit.text : {
-- 
2.5.0



From ard.biesheuvel at linaro.org  Wed Feb  3 11:04:56 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed,  3 Feb 2016 20:04:56 +0100
Subject: [PATCH v2 3/4] kallsyms: remove --page-offset command line option
In-Reply-To: <1454526297-5269-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454526297-5269-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454526297-5269-4-git-send-email-ard.biesheuvel@linaro.org>

The --page-offset command line option was only used for ARM, to filter
symbol addresses below CONFIG_PAGE_OFFSET. This is no longer needed, so
remove the functionality altogether.

Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 scripts/kallsyms.c | 27 ++++----------------
 1 file changed, 5 insertions(+), 22 deletions(-)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 02473b71643b..ce36fc02fe8c 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -63,7 +63,6 @@ static unsigned int table_size, table_cnt;
 static int all_symbols = 0;
 static int absolute_percpu = 0;
 static char symbol_prefix_char = '\0';
-static unsigned long long kernel_start_addr = 0;
 static int base_relative = 0;
 
 int token_profit[0x10000];
@@ -229,9 +228,6 @@ static int symbol_valid(struct sym_entry *s)
 	char *sym_name = (char *)s->sym + 1;
 
 
-	if (s->addr < kernel_start_addr)
-		return 0;
-
 	/* skip prefix char */
 	if (symbol_prefix_char && *sym_name == symbol_prefix_char)
 		sym_name++;
@@ -742,21 +738,11 @@ static void record_relative_base(void)
 {
 	unsigned int i;
 
-	if (kernel_start_addr > 0) {
-		/*
-		 * If the kernel start address was specified, use that as
-		 * the relative base rather than going through the table,
-		 * since it should be a reasonable default, and values below
-		 * it will be ignored anyway.
-		 */
-		relative_base = kernel_start_addr;
-	} else {
-		relative_base = -1ULL;
-		for (i = 0; i < table_cnt; i++)
-			if (!symbol_absolute(&table[i]) &&
-			    table[i].addr < relative_base)
-				relative_base = table[i].addr;
-	}
+	relative_base = -1ULL;
+	for (i = 0; i < table_cnt; i++)
+		if (!symbol_absolute(&table[i]) &&
+		    table[i].addr < relative_base)
+			relative_base = table[i].addr;
 }
 
 int main(int argc, char **argv)
@@ -774,9 +760,6 @@ int main(int argc, char **argv)
 				if ((*p == '"' && *(p+2) == '"') || (*p == '\'' && *(p+2) == '\''))
 					p++;
 				symbol_prefix_char = *p;
-			} else if (strncmp(argv[i], "--page-offset=", 14) == 0) {
-				const char *p = &argv[i][14];
-				kernel_start_addr = strtoull(p, NULL, 16);
 			} else if (strcmp(argv[i], "--base-relative") == 0)
 				base_relative = 1;
 			else
-- 
2.5.0



From ard.biesheuvel at linaro.org  Wed Feb  3 11:04:55 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed,  3 Feb 2016 20:04:55 +0100
Subject: [PATCH v2 2/4] kallsyms: remove special lower address limit for
 CONFIG_ARM
In-Reply-To: <1454526297-5269-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454526297-5269-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454526297-5269-3-git-send-email-ard.biesheuvel@linaro.org>

Now that we no longer emit .stubs symbols into a section VMA loaded
at absolute address 0x1000, we can drop the ARM-specific override that
sets a lower limit based on CONFIG_PAGE_OFFSET, below which symbols are
filtered from the kallsyms output.

Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 scripts/link-vmlinux.sh | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index aae2473301ea..b83f918c7830 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -82,10 +82,6 @@ kallsyms()
 		kallsymopt="${kallsymopt} --all-symbols"
 	fi
 
-	if [ -n "${CONFIG_ARM}" ] && [ -z "${CONFIG_XIP_KERNEL}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
-		kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
-	fi
-
 	if [ -n "${CONFIG_X86_64}" ] && [ -n "${CONFIG_SMP}" ]; then
 		kallsymopt="${kallsymopt} --absolute-percpu"
 	fi
-- 
2.5.0



From ard.biesheuvel at linaro.org  Wed Feb  3 11:04:57 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed,  3 Feb 2016 20:04:57 +0100
Subject: [PATCH v2 4/4] ARM: use single definition for vectors-to-stubs
 section offset
In-Reply-To: <1454526297-5269-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454526297-5269-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454526297-5269-5-git-send-email-ard.biesheuvel@linaro.org>

This replaces a couple of unannotated uses of the constant 0x1000 with
a single definition in the linker script, and updates the referring
code to use it.

Note that this involves explicitly emitting a relocation against the
literal in .stubs containing the address of vector_swi(), since the
assembler refuses to do so.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm/kernel/entry-armv.S  | 17 +++++++++++++----
 arch/arm/kernel/traps.c       |  4 +++-
 arch/arm/kernel/vmlinux.lds.S |  9 ++++++++-
 3 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 8575ff42c0d4..c19d3b82edb8 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -1064,8 +1064,7 @@ ENDPROC(vector_\name)
 	.endm
 
 	.section .stubs, "ax", %progbits
-__stubs_start:
-	@ This must be the first word
+.Lvector_swi:
 	.word	vector_swi
 
 vector_rst:
@@ -1205,16 +1204,26 @@ vector_addrexcptn:
 	.globl	vector_fiq
 
 	.section .vectors, "ax", %progbits
-.L__vectors_start:
 	W(b)	vector_rst
 	W(b)	vector_und
-	W(ldr)	pc, .L__vectors_start + 0x1000
+0:	W(ldr)	pc, .				@ vector_swi
 	W(b)	vector_pabt
 	W(b)	vector_dabt
 	W(b)	vector_addrexcptn
 	W(b)	vector_irq
 	W(b)	vector_fiq
 
+	/*
+	 * The assembler refuses to emit the correct relocation for the
+	 * cross-section reference to .Lvector_swi inside the ldr instruction
+	 * above, so we have to emit it manually. Note that the addend cannot
+	 * be set by the .reloc directive, and the initial offset recorded in
+	 * the instruction should compensate for the PC bias of the execution
+	 * mode, hence the use of '.' as the label.
+	 */
+ ARM(	.reloc	0b, R_ARM_LDR_PC_G0, .Lvector_swi	)
+ THUMB(	.reloc	0b, R_ARM_THM_PC12, .Lvector_swi	)
+
 	.data
 
 	.globl	cr_alignment
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index bc698383e822..d90a5b2c02a3 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -792,6 +792,8 @@ void __init early_trap_init(void *vectors_base)
 {
 #ifndef CONFIG_CPU_V7M
 	unsigned long vectors = (unsigned long)vectors_base;
+	extern char __stubs_offset[];
+	unsigned long stubs = vectors + (unsigned long)&__stubs_offset;
 	extern char __stubs_start[], __stubs_end[];
 	extern char __vectors_start[], __vectors_end[];
 	unsigned i;
@@ -813,7 +815,7 @@ void __init early_trap_init(void *vectors_base)
 	 * are visible to the instruction stream.
 	 */
 	memcpy((void *)vectors, __vectors_start, __vectors_end - __vectors_start);
-	memcpy((void *)vectors + 0x1000, __stubs_start, __stubs_end - __stubs_start);
+	memcpy((void *)stubs, __stubs_start, __stubs_end - __stubs_start);
 
 	kuser_init(vectors_base);
 
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 9f96a54c7d90..8f270c8e9153 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -163,7 +163,14 @@ SECTIONS
 	/*
 	 * The vectors and stubs are relocatable code, and the
 	 * only thing that matters is their relative offsets
+	 * The .stubs section is virtually placed exactly 4 KB after
+	 * the .vectors section, so that it is in reach for indirect
+	 * jumps from the vector table ('ldr pc, <label>', where the
+	 * label itself is inside the .stubs section) but can still
+	 * be mapped with different permissions.
 	 */
+	__stubs_offset = 0x1000;
+
 	.stubs : {
 		__stubs_start = .;
 		*(.stubs)
@@ -171,7 +178,7 @@ SECTIONS
 	}
 
 	__vectors_start = .;
-	.vectors ADDR(.stubs) - 0x1000 : AT(__vectors_start) {
+	.vectors ADDR(.stubs) - __stubs_offset : AT(__vectors_start) {
 		*(.vectors)
 	}
 	. = __vectors_start + SIZEOF(.vectors);
-- 
2.5.0



From maxime.ripard at free-electrons.com  Wed Feb  3 11:07:46 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 3 Feb 2016 20:07:46 +0100
Subject: [PATCH v3 2/2] clk: sunxi: Refactor A31 PLL6 so that it can be
 reused
In-Reply-To: <20160202075239.e4318e9dced1eeed29c593f6@free.fr>
References: <1454008958-12655-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454008958-12655-2-git-send-email-maxime.ripard@free-electrons.com>
 <20160130185714.7abcf1de9ef8108c2f48c7fe@free.fr>
 <20160201201754.GI4652@lukather>
 <20160202075239.e4318e9dced1eeed29c593f6@free.fr>
Message-ID: <20160203190746.GJ4652@lukather>

On Tue, Feb 02, 2016 at 07:52:39AM +0100, Jean-Francois Moine wrote:
> On Mon, 1 Feb 2016 21:17:54 +0100
> Maxime Ripard <maxime.ripard at free-electrons.com> wrote:
> 
> > > Also, for the H3 PLL periph1 (aka PLL8), why didn't you create a
> > > 'pll8x2' clock with 'pll8' as a divider?
> > 
> > No one seems to use it. We can always add it later in a separate
> > patch when someone will.
> 
> Well, then, I don't understand. The pll periph/peripheral/periph0,
> aka PLL6 works well for many SoCs and there is no need to change
> its DT definition.
> 
> In the patch header, you wrote:
> 
> > Remove the fixed dividers from the PLL6 driver to be able to have a
> > reusable driver that can be used across several SoCs that share the same
> > controller, but don't have the same set of dividers for this clock, and to
> > also be reused multiple times in the same SoC, since we're droping the
> > clock name.
> 
> then, for the H3, you do
> (the comment should be "until pll8 can be reused"),

No. The comment is right. Even though pll8 was just another instance
of pll6, the pll6 driver couldn't be reused because the clock name was
hardcoded in the driver, and you couldn't register two clocks with the
same name.

This was done because this driver has several outputs, the main PLL
output, plus all the various dividers it might have in the various
SoCs.

So, no. It was not working fine on "many" SoCs. And this is exactly
what this patch fixes.

> > -		/* dummy clock until pll6 can be reused */
> > -		pll8: pll8_clk {
> > +		pll8: clk at 01c20044 {
> >  			#clock-cells = <0>;
> > -			compatible = "fixed-clock";
> > -			clock-frequency = <1>;
> > +			compatible = "allwinner,sun6i-a31-pll6-clk";
> > +			reg = <0x01c20044 0x4>;
> > +			clocks = <&osc24M>;
> >  			clock-output-names = "pll8";
> >  		};
> 
> that is, you add the PLL8, don't you?

I guess it's just a matter of interpretation, but no, I'm just
removing the placeholder that was there.

> 
> And, further, you change the MMC clocks:
> 
> > @@ -243,7 +243,7 @@
> >  			#clock-cells = <1>;
> >  			compatible = "allwinner,sun4i-a10-mmc-clk";
> >  			reg = <0x01c20088 0x4>;
> > -			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
> > +			clocks = <&osc24M>, <&pll6>, <&pll8>;
> >  			clock-output-names = "mmc0",
> >  					     "mmc0_output",
> >  					     "mmc0_sample";
> 
> where the PLL8 is already used.
> 
> So, how can you say
> 
> > No one seems to use it. We can always add it later in a separate
> > patch when someone will.

Because I was replying to a request from you asking about
pll8x2. The code you quote is about pll8...

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/d4be01d1/attachment.sig>

From mathieu.poirier at linaro.org  Wed Feb  3 10:39:02 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:02 -0700
Subject: [PATCH V9 04/18] coresight: etm3x: moving etm_readl/writel to header
 file
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-5-git-send-email-mathieu.poirier@linaro.org>

Moving functions etm_readl/writel to file "coresight-etm.h"
so that the main ETM3x driver can be split in more than one
file.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm.h   | 29 +++++++++++++++++++++++++++
 drivers/hwtracing/coresight/coresight-etm3x.c | 29 ---------------------------
 2 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
index b4481eb29304..34f7db881fa7 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -251,4 +251,33 @@ enum etm_addr_type {
 	ETM_ADDR_TYPE_START,
 	ETM_ADDR_TYPE_STOP,
 };
+
+static inline void etm_writel(struct etm_drvdata *drvdata,
+			      u32 val, u32 off)
+{
+	if (drvdata->use_cp14) {
+		if (etm_writel_cp14(off, val)) {
+			dev_err(drvdata->dev,
+				"invalid CP14 access to ETM reg: %#x", off);
+		}
+	} else {
+		writel_relaxed(val, drvdata->base + off);
+	}
+}
+
+static inline unsigned int etm_readl(struct etm_drvdata *drvdata, u32 off)
+{
+	u32 val;
+
+	if (drvdata->use_cp14) {
+		if (etm_readl_cp14(off, &val)) {
+			dev_err(drvdata->dev,
+				"invalid CP14 access to ETM reg: %#x", off);
+		}
+	} else {
+		val = readl_relaxed(drvdata->base + off);
+	}
+
+	return val;
+}
 #endif
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index fe6791e0c66c..d53440e9af6f 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -42,35 +42,6 @@ module_param_named(boot_enable, boot_enable, int, S_IRUGO);
 static int etm_count;
 static struct etm_drvdata *etmdrvdata[NR_CPUS];
 
-static inline void etm_writel(struct etm_drvdata *drvdata,
-			      u32 val, u32 off)
-{
-	if (drvdata->use_cp14) {
-		if (etm_writel_cp14(off, val)) {
-			dev_err(drvdata->dev,
-				"invalid CP14 access to ETM reg: %#x", off);
-		}
-	} else {
-		writel_relaxed(val, drvdata->base + off);
-	}
-}
-
-static inline unsigned int etm_readl(struct etm_drvdata *drvdata, u32 off)
-{
-	u32 val;
-
-	if (drvdata->use_cp14) {
-		if (etm_readl_cp14(off, &val)) {
-			dev_err(drvdata->dev,
-				"invalid CP14 access to ETM reg: %#x", off);
-		}
-	} else {
-		val = readl_relaxed(drvdata->base + off);
-	}
-
-	return val;
-}
-
 /*
  * Memory mapped writes to clear os lock are not supported on some processors
  * and OS lock must be unlocked before any memory mapped access on such
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb  3 10:39:04 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:04 -0700
Subject: [PATCH V9 06/18] coresight: etm3x: unlocking tracers in default arch
 init
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-7-git-send-email-mathieu.poirier@linaro.org>

Calling function 'smp_call_function_single()' to unlock a
tracer and calling it again right after to perform the
default initialisation doesn't make sense.

Moving 'etm_os_unlock()' just before making the default
initialisation results in the same outcome while saving
one call to 'smp_call_function_single()'.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm3x.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 6ea35b350958..f2c74bb56993 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -47,11 +47,11 @@ static struct etm_drvdata *etmdrvdata[NR_CPUS];
  * and OS lock must be unlocked before any memory mapped access on such
  * processors, otherwise memory mapped reads/writes will be invalid.
  */
-static void etm_os_unlock(void *info)
+static void etm_os_unlock(struct etm_drvdata *drvdata)
 {
-	struct etm_drvdata *drvdata = (struct etm_drvdata *)info;
 	/* Writing any value to ETMOSLAR unlocks the trace registers */
 	etm_writel(drvdata, 0x0, ETMOSLAR);
+	drvdata->os_unlock = true;
 	isb();
 }
 
@@ -483,6 +483,9 @@ static void etm_init_arch_data(void *info)
 	u32 etmccr;
 	struct etm_drvdata *drvdata = info;
 
+	/* Make sure all registers are accessible */
+	etm_os_unlock(drvdata);
+
 	CS_UNLOCK(drvdata->base);
 
 	/* First dummy read */
@@ -607,9 +610,6 @@ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
 	get_online_cpus();
 	etmdrvdata[drvdata->cpu] = drvdata;
 
-	if (!smp_call_function_single(drvdata->cpu, etm_os_unlock, drvdata, 1))
-		drvdata->os_unlock = true;
-
 	if (smp_call_function_single(drvdata->cpu,
 				     etm_init_arch_data,  drvdata, 1))
 		dev_err(dev, "ETM arch init failed\n");
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb  3 10:39:01 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:01 -0700
Subject: [PATCH V9 03/18] coresight: moving PM runtime operations to core
 framework
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-4-git-send-email-mathieu.poirier@linaro.org>

Moving PM runtime operations in Coresight devices enable() and
disable() API to the framework core when a path is setup.  That
way the runtime core doesn't have to be involved everytime a
path is enabled.  It also avoids calling runtime PM operations
in IRQ context.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etb10.c           | 4 ----
 drivers/hwtracing/coresight/coresight-etm3x.c           | 3 ---
 drivers/hwtracing/coresight/coresight-etm4x.c           | 6 ------
 drivers/hwtracing/coresight/coresight-funnel.c          | 2 --
 drivers/hwtracing/coresight/coresight-replicator-qcom.c | 4 ----
 drivers/hwtracing/coresight/coresight-replicator.c      | 2 --
 drivers/hwtracing/coresight/coresight-tmc.c             | 5 -----
 drivers/hwtracing/coresight/coresight-tpiu.c            | 2 --
 drivers/hwtracing/coresight/coresight.c                 | 9 ++++++++-
 9 files changed, 8 insertions(+), 29 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 92969dae739d..917562ecf82a 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -137,8 +137,6 @@ static int etb_enable(struct coresight_device *csdev)
 	struct etb_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	unsigned long flags;
 
-	pm_runtime_get_sync(drvdata->dev);
-
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 	etb_enable_hw(drvdata);
 	drvdata->enable = true;
@@ -247,8 +245,6 @@ static void etb_disable(struct coresight_device *csdev)
 	drvdata->enable = false;
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
 
-	pm_runtime_put(drvdata->dev);
-
 	dev_info(drvdata->dev, "ETB disabled\n");
 }
 
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index aae80e14508d..fe6791e0c66c 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -349,7 +349,6 @@ static int etm_enable(struct coresight_device *csdev)
 	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	int ret;
 
-	pm_runtime_get_sync(csdev->dev.parent);
 	spin_lock(&drvdata->spinlock);
 
 	/*
@@ -373,7 +372,6 @@ static int etm_enable(struct coresight_device *csdev)
 	return 0;
 err:
 	spin_unlock(&drvdata->spinlock);
-	pm_runtime_put(csdev->dev.parent);
 	return ret;
 }
 
@@ -422,7 +420,6 @@ static void etm_disable(struct coresight_device *csdev)
 
 	spin_unlock(&drvdata->spinlock);
 	put_online_cpus();
-	pm_runtime_put(csdev->dev.parent);
 
 	dev_info(drvdata->dev, "ETM tracing disabled\n");
 }
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index d6a92c6d3a66..c2f518fbc9a8 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -79,7 +79,6 @@ static int etm4_trace_id(struct coresight_device *csdev)
 	if (!drvdata->enable)
 		return drvdata->trcid;
 
-	pm_runtime_get_sync(drvdata->dev);
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 
 	CS_UNLOCK(drvdata->base);
@@ -88,7 +87,6 @@ static int etm4_trace_id(struct coresight_device *csdev)
 	CS_LOCK(drvdata->base);
 
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
-	pm_runtime_put(drvdata->dev);
 
 	return trace_id;
 }
@@ -194,7 +192,6 @@ static int etm4_enable(struct coresight_device *csdev)
 	struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	int ret;
 
-	pm_runtime_get_sync(drvdata->dev);
 	spin_lock(&drvdata->spinlock);
 
 	/*
@@ -214,7 +211,6 @@ static int etm4_enable(struct coresight_device *csdev)
 	return 0;
 err:
 	spin_unlock(&drvdata->spinlock);
-	pm_runtime_put(drvdata->dev);
 	return ret;
 }
 
@@ -263,8 +259,6 @@ static void etm4_disable(struct coresight_device *csdev)
 	spin_unlock(&drvdata->spinlock);
 	put_online_cpus();
 
-	pm_runtime_put(drvdata->dev);
-
 	dev_info(drvdata->dev, "ETM tracing disabled\n");
 }
 
diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c
index 25e8ea140a09..fb2c679fbc44 100644
--- a/drivers/hwtracing/coresight/coresight-funnel.c
+++ b/drivers/hwtracing/coresight/coresight-funnel.c
@@ -69,7 +69,6 @@ static int funnel_enable(struct coresight_device *csdev, int inport,
 {
 	struct funnel_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
-	pm_runtime_get_sync(drvdata->dev);
 	funnel_enable_hw(drvdata, inport);
 
 	dev_info(drvdata->dev, "FUNNEL inport %d enabled\n", inport);
@@ -95,7 +94,6 @@ static void funnel_disable(struct coresight_device *csdev, int inport,
 	struct funnel_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
 	funnel_disable_hw(drvdata, inport);
-	pm_runtime_put(drvdata->dev);
 
 	dev_info(drvdata->dev, "FUNNEL inport %d disabled\n", inport);
 }
diff --git a/drivers/hwtracing/coresight/coresight-replicator-qcom.c b/drivers/hwtracing/coresight/coresight-replicator-qcom.c
index 444815179460..286f90b50989 100644
--- a/drivers/hwtracing/coresight/coresight-replicator-qcom.c
+++ b/drivers/hwtracing/coresight/coresight-replicator-qcom.c
@@ -48,8 +48,6 @@ static int replicator_enable(struct coresight_device *csdev, int inport,
 {
 	struct replicator_state *drvdata = dev_get_drvdata(csdev->dev.parent);
 
-	pm_runtime_get_sync(drvdata->dev);
-
 	CS_UNLOCK(drvdata->base);
 
 	/*
@@ -86,8 +84,6 @@ static void replicator_disable(struct coresight_device *csdev, int inport,
 
 	CS_LOCK(drvdata->base);
 
-	pm_runtime_put(drvdata->dev);
-
 	dev_info(drvdata->dev, "REPLICATOR disabled\n");
 }
 
diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
index b77d700a3f0e..0ce98903992c 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -41,7 +41,6 @@ static int replicator_enable(struct coresight_device *csdev, int inport,
 {
 	struct replicator_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
-	pm_runtime_get_sync(drvdata->dev);
 	dev_info(drvdata->dev, "REPLICATOR enabled\n");
 	return 0;
 }
@@ -51,7 +50,6 @@ static void replicator_disable(struct coresight_device *csdev, int inport,
 {
 	struct replicator_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
-	pm_runtime_put(drvdata->dev);
 	dev_info(drvdata->dev, "REPLICATOR disabled\n");
 }
 
diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
index c4fa70ed14ce..b526396d80b6 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -242,12 +242,9 @@ static int tmc_enable(struct tmc_drvdata *drvdata, enum tmc_mode mode)
 {
 	unsigned long flags;
 
-	pm_runtime_get_sync(drvdata->dev);
-
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 	if (drvdata->reading) {
 		spin_unlock_irqrestore(&drvdata->spinlock, flags);
-		pm_runtime_put(drvdata->dev);
 		return -EBUSY;
 	}
 
@@ -381,8 +378,6 @@ out:
 	drvdata->enable = false;
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
 
-	pm_runtime_put(drvdata->dev);
-
 	dev_info(drvdata->dev, "TMC disabled\n");
 }
 
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
index ca50e73d9df7..0d8fce651ff7 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -74,7 +74,6 @@ static int tpiu_enable(struct coresight_device *csdev)
 {
 	struct tpiu_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
-	pm_runtime_get_sync(csdev->dev.parent);
 	tpiu_enable_hw(drvdata);
 
 	dev_info(drvdata->dev, "TPIU enabled\n");
@@ -98,7 +97,6 @@ static void tpiu_disable(struct coresight_device *csdev)
 	struct tpiu_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
 	tpiu_disable_hw(drvdata);
-	pm_runtime_put(csdev->dev.parent);
 
 	dev_info(drvdata->dev, "TPIU disabled\n");
 }
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 2ed48545df26..6b44928c1076 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -24,6 +24,7 @@
 #include <linux/coresight.h>
 #include <linux/of_platform.h>
 #include <linux/delay.h>
+#include <linux/pm_runtime.h>
 
 #include "coresight-priv.h"
 
@@ -376,7 +377,8 @@ out:
 	/*
 	 * A path from this element to a sink has been found.  The elements
 	 * leading to the sink are already enqueued, all that is left to do
-	 * is add a node for this element.
+	 * is tell the PM runtime core we need this element and add a node
+	 * for it.
 	 */
 	node = kzalloc(sizeof(struct coresight_node), GFP_KERNEL);
 	if (!node)
@@ -384,6 +386,7 @@ out:
 
 	node->csdev = csdev;
 	list_add(&node->link, path);
+	pm_runtime_get_sync(csdev->dev.parent);
 
 	return 0;
 }
@@ -415,9 +418,13 @@ struct list_head *coresight_build_path(struct coresight_device *csdev)
  */
 void coresight_release_path(struct list_head *path)
 {
+	struct coresight_device *csdev;
 	struct coresight_node *nd, *next;
 
 	list_for_each_entry_safe(nd, next, path, link) {
+		csdev = nd->csdev;
+
+		pm_runtime_put_sync(csdev->dev.parent);
 		list_del(&nd->link);
 		kfree(nd);
 	}
-- 
2.1.4



From christoffer.dall at linaro.org  Wed Feb  3 11:12:54 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 3 Feb 2016 20:12:54 +0100
Subject: [PATCH v2 21/21] arm64: Panic when VHE and non VHE CPUs coexist
In-Reply-To: <56B23CCB.4000009@arm.com>
References: <1453737235-16522-1-git-send-email-marc.zyngier@arm.com>
 <1453737235-16522-22-git-send-email-marc.zyngier@arm.com>
 <20160201153605.GA1478@cbox> <56B0CBF4.9030507@arm.com>
 <20160203084913.GA13974@cbox> <56B23CCB.4000009@arm.com>
Message-ID: <20160203191254.GD13974@cbox>

On Wed, Feb 03, 2016 at 05:45:47PM +0000, Marc Zyngier wrote:
> On 03/02/16 08:49, Christoffer Dall wrote:
> > On Tue, Feb 02, 2016 at 03:32:04PM +0000, Marc Zyngier wrote:
> >> On 01/02/16 15:36, Christoffer Dall wrote:
> >>> On Mon, Jan 25, 2016 at 03:53:55PM +0000, Marc Zyngier wrote:
> >>>> Having both VHE and non-VHE capable CPUs in the same system
> >>>> is likely to be a recipe for disaster.
> >>>>
> >>>> If the boot CPU has VHE, but a secondary is not, we won't be
> >>>> able to downgrade and run the kernel at EL1. Add CPU hotplug
> >>>> to the mix, and this produces a terrifying mess.
> >>>>
> >>>> Let's solve the problem once and for all. If you mix VHE and
> >>>> non-VHE CPUs in the same system, you deserve to loose, and this
> >>>> patch makes sure you don't get a chance.
> >>>>
> >>>> This is implemented by storing the kernel execution level in
> >>>> a global variable. Secondaries will park themselves in a
> >>>> WFI loop if they observe a mismatch. Also, the primary CPU
> >>>> will detect that the secondary CPU has died on a mismatched
> >>>> execution level. Panic will follow.
> >>>>
> >>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >>>> ---
> >>>>  arch/arm64/include/asm/virt.h | 17 +++++++++++++++++
> >>>>  arch/arm64/kernel/head.S      | 19 +++++++++++++++++++
> >>>>  arch/arm64/kernel/smp.c       |  3 +++
> >>>>  3 files changed, 39 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
> >>>> index 9f22dd6..f81a345 100644
> >>>> --- a/arch/arm64/include/asm/virt.h
> >>>> +++ b/arch/arm64/include/asm/virt.h
> >>>> @@ -36,6 +36,11 @@
> >>>>   */
> >>>>  extern u32 __boot_cpu_mode[2];
> >>>>  
> >>>> +/*
> >>>> + * __run_cpu_mode records the mode the boot CPU uses for the kernel.
> >>>> + */
> >>>> +extern u32 __run_cpu_mode[2];
> >>>> +
> >>>>  void __hyp_set_vectors(phys_addr_t phys_vector_base);
> >>>>  phys_addr_t __hyp_get_vectors(void);
> >>>>  
> >>>> @@ -60,6 +65,18 @@ static inline bool is_kernel_in_hyp_mode(void)
> >>>>  	return el == CurrentEL_EL2;
> >>>>  }
> >>>>  
> >>>> +static inline bool is_kernel_mode_mismatched(void)
> >>>> +{
> >>>> +	/*
> >>>> +	 * A mismatched CPU will have written its own CurrentEL in
> >>>> +	 * __run_cpu_mode[1] (initially set to zero) after failing to
> >>>> +	 * match the value in __run_cpu_mode[0]. Thus, a non-zero
> >>>> +	 * value in __run_cpu_mode[1] is enough to detect the
> >>>> +	 * pathological case.
> >>>> +	 */
> >>>> +	return !!ACCESS_ONCE(__run_cpu_mode[1]);
> >>>> +}
> >>>> +
> >>>>  /* The section containing the hypervisor text */
> >>>>  extern char __hyp_text_start[];
> >>>>  extern char __hyp_text_end[];
> >>>> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> >>>> index 2a7134c..bc44cf8 100644
> >>>> --- a/arch/arm64/kernel/head.S
> >>>> +++ b/arch/arm64/kernel/head.S
> >>>> @@ -577,7 +577,23 @@ ENTRY(set_cpu_boot_mode_flag)
> >>>>  1:	str	w20, [x1]			// This CPU has booted in EL1
> >>>>  	dmb	sy
> >>>>  	dc	ivac, x1			// Invalidate potentially stale cache line
> >>>> +	adr_l	x1, __run_cpu_mode
> >>>> +	ldr	w0, [x1]
> >>>> +	mrs	x20, CurrentEL
> >>>> +	cbz	x0, skip_el_check
> >>>> +	cmp	x0, x20
> >>>> +	bne	mismatched_el
> >>>
> >>> can't you do a ret here instead of writing the same value and flushing
> >>> caches etc.?
> >>
> >> Yes, good point.
> >>
> >>>
> >>>> +skip_el_check:			// Only the first CPU gets to set the rule
> >>>> +	str	w20, [x1]
> >>>> +	dmb	sy
> >>>> +	dc	ivac, x1	// Invalidate potentially stale cache line
> >>>>  	ret
> >>>> +mismatched_el:
> >>>> +	str	w20, [x1, #4]
> >>>> +	dmb	sy
> >>>> +	dc	ivac, x1	// Invalidate potentially stale cache line
> >>>> +1:	wfi
> >>>
> >>> I'm no expert on SMP bringup, but doesn't this prevent the CPU from
> >>> signaling completion and thus you'll never actually reach the checking
> >>> code in __cpu_up?
> >>
> >> Indeed, and that's the whole point. The primary CPU will notice that the
> >> secondary CPU has failed to boot (timeout), and will find the reason in
> >> __run_cpu_mode.
> >>
> > That wasn't exactly my point.  If I understand correctly and __cpu_up is
> > the primary CPU executing a function to bring up a secondary core, then
> > it will wait for the cpu_running completion which should be signalled by
> > the secondary core, but because the secondary core never makes any
> > progress it will timeout the wait for completion and you will see that
> > error "..failed to come online" instead of the "incompatible execution
> > level".
> 
> It will actually do both. Here's an example on the model configured for
> such a braindead case:
> 
> CPU4: failed to come online
> Kernel panic - not syncing: CPU4: incompatible execution level
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc2+ #5459
> Hardware name: FVP Base (DT)
> Call trace:
> [<ffffffc0000899e0>] dump_backtrace+0x0/0x180
> [<ffffffc000089b74>] show_stack+0x14/0x20
> [<ffffffc000333b08>] dump_stack+0x90/0xc8
> [<ffffffc00014d424>] panic+0x10c/0x250
> [<ffffffc00008ef24>] __cpu_up+0xfc/0x100
> [<ffffffc0000b7a9c>] _cpu_up+0x154/0x188
> [<ffffffc0000b7b54>] cpu_up+0x84/0xa8
> [<ffffffc0009e9d00>] smp_init+0xbc/0xc0
> [<ffffffc0009dca10>] kernel_init_freeable+0x94/0x1ec
> [<ffffffc000712f90>] kernel_init+0x10/0xe0
> [<ffffffc000085cd0>] ret_from_fork+0x10/0x40
> 
> Am I missing something *really* obvious?
> 
No, I was, it says "ret = -EIO;" not "return -EIO"...

sorry.

-Christoffer


From robert.jarzmik at free.fr  Wed Feb  3 11:15:47 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Wed, 03 Feb 2016 20:15:47 +0100
Subject: [PATCH 0/7] USB changes for rare warnings
In-Reply-To: <87oabxpsr8.fsf@ti.com> (Felipe Balbi's message of "Wed, 03 Feb
 2016 20:12:59 +0200")
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <87oabxpsr8.fsf@ti.com>
Message-ID: <87lh7161wc.fsf@belgarion.home>

Felipe Balbi <balbi at kernel.org> writes:

> Hi Arnd,
>
>>  arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h | 198 ---------
>>  arch/arm/mach-pxa/include/mach/pxa25x-udc.h     | 163 --------
>
> for arch/arm I need Acked-by from relevant folks.
You already have mine for arch/arm/mach-pxa/include/mach/pxa25x-udc.h I think,
or did my mailer betray me again ...

I cannot speak for ixp4xx though.

Cheers.

-- 
Robert


From mathieu.poirier at linaro.org  Wed Feb  3 10:39:16 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:16 -0700
Subject: [PATCH V9 18/18] coresight: introducing a global trace ID function
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-19-git-send-email-mathieu.poirier@linaro.org>

TraceID values have to be unique for all tracers and
consistent between drivers and user space.  As such
introducing a central function to be used whenever a
traceID value is required.

The patch also account for data traceIDs, which are usually
I(N) + 1.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm3x.c |  7 ++-----
 include/linux/coresight-pmu.h                 | 12 ++++++++++++
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 77b37413803f..0ba1a3981373 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -27,6 +27,7 @@
 #include <linux/cpu.h>
 #include <linux/of.h>
 #include <linux/coresight.h>
+#include <linux/coresight-pmu.h>
 #include <linux/amba/bus.h>
 #include <linux/seq_file.h>
 #include <linux/uaccess.h>
@@ -740,11 +741,7 @@ static void etm_init_arch_data(void *info)
 
 static void etm_init_trace_id(struct etm_drvdata *drvdata)
 {
-	/*
-	 * A trace ID of value 0 is invalid, so let's start at some
-	 * random value that fits in 7 bits and go from there.
-	 */
-	drvdata->traceid = 0x10 + drvdata->cpu;
+	drvdata->traceid = coresight_get_trace_id(drvdata->cpu);
 }
 
 static int etm_probe(struct amba_device *adev, const struct amba_id *id)
diff --git a/include/linux/coresight-pmu.h b/include/linux/coresight-pmu.h
index 6c5386b23b10..7d410260661b 100644
--- a/include/linux/coresight-pmu.h
+++ b/include/linux/coresight-pmu.h
@@ -19,9 +19,21 @@
 #define _LINUX_CORESIGHT_PMU_H
 
 #define CORESIGHT_ETM_PMU_NAME "cs_etm"
+#define CORESIGHT_ETM_PMU_SEED  0x10
 
 /* ETMv3.5/PTM's ETMCR config bit */
 #define ETM_OPT_CYCACC  12
 #define ETM_OPT_TS      28
 
+static inline int coresight_get_trace_id(int cpu)
+{
+	/*
+	 * A trace ID of value 0 is invalid, so let's start at some
+	 * random value that fits in 7 bits and go from there.  Since
+	 * the common convention is to have data trace IDs be I(N) + 1,
+	 * set instruction trace IDs as a function of the CPU number.
+	 */
+	return (CORESIGHT_ETM_PMU_SEED + (cpu * 2));
+}
+
 #endif
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb  3 10:39:13 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:13 -0700
Subject: [PATCH V9 15/18] coresight: etb10: adding operation mode for
 sink->enable()
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-16-git-send-email-mathieu.poirier@linaro.org>

Adding an operation mode to the sink->enable() API in order
to prevent simultaneous access from different callers.

TPIU and TMC won't be supplemented with the AUX area
API immediately and as such ignore the new mode.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etb10.c | 30 ++++++++++++++++++++-------
 drivers/hwtracing/coresight/coresight-priv.h  |  2 +-
 drivers/hwtracing/coresight/coresight-tmc.c   |  2 +-
 drivers/hwtracing/coresight/coresight-tpiu.c  |  2 +-
 drivers/hwtracing/coresight/coresight.c       | 10 ++++-----
 include/linux/coresight.h                     |  2 +-
 6 files changed, 32 insertions(+), 16 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 162c9ccc8c33..79099f95ba3f 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -73,9 +73,9 @@
  * @miscdev:	specifics to handle "/dev/xyz.etb" entry.
  * @spinlock:	only one at a time pls.
  * @reading:	synchronise user space access to etb buffer.
+ * @mode:	this ETB is being used.
  * @buf:	area of memory where ETB buffer content gets sent.
  * @buffer_depth: size of @buf.
- * @enable:	this ETB is being used.
  * @trigger_cntr: amount of words to store after a trigger.
  */
 struct etb_drvdata {
@@ -86,9 +86,9 @@ struct etb_drvdata {
 	struct miscdevice	miscdev;
 	spinlock_t		spinlock;
 	local_t			reading;
+	local_t			mode;
 	u8			*buf;
 	u32			buffer_depth;
-	bool			enable;
 	u32			trigger_cntr;
 };
 
@@ -133,16 +133,31 @@ static void etb_enable_hw(struct etb_drvdata *drvdata)
 	CS_LOCK(drvdata->base);
 }
 
-static int etb_enable(struct coresight_device *csdev)
+static int etb_enable(struct coresight_device *csdev, u32 mode)
 {
-	struct etb_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+	u32 val;
 	unsigned long flags;
+	struct etb_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	val = local_cmpxchg(&drvdata->mode,
+			    CS_MODE_DISABLED, mode);
+	/*
+	 * When accessing from Perf, a HW buffer can be handled
+	 * by a single trace entity.  In sysFS mode many tracers
+	 * can be logging to the same HW buffer.
+	 */
+	if (val == CS_MODE_PERF)
+		return -EBUSY;
+
+	/* Nothing to do, the tracer is already enabled. */
+	if (val == CS_MODE_SYSFS)
+		goto out;
 
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 	etb_enable_hw(drvdata);
-	drvdata->enable = true;
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
 
+out:
 	dev_info(drvdata->dev, "ETB enabled\n");
 	return 0;
 }
@@ -243,9 +258,10 @@ static void etb_disable(struct coresight_device *csdev)
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 	etb_disable_hw(drvdata);
 	etb_dump_hw(drvdata);
-	drvdata->enable = false;
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
 
+	local_set(&drvdata->mode, CS_MODE_DISABLED);
+
 	dev_info(drvdata->dev, "ETB disabled\n");
 }
 
@@ -263,7 +279,7 @@ static void etb_dump(struct etb_drvdata *drvdata)
 	unsigned long flags;
 
 	spin_lock_irqsave(&drvdata->spinlock, flags);
-	if (drvdata->enable) {
+	if (local_read(&drvdata->mode) == CS_MODE_SYSFS) {
 		etb_disable_hw(drvdata);
 		etb_dump_hw(drvdata);
 		etb_enable_hw(drvdata);
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 932f34a84d96..333eddaed339 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -62,7 +62,7 @@ static inline void CS_UNLOCK(void __iomem *addr)
 }
 
 void coresight_disable_path(struct list_head *path);
-int coresight_enable_path(struct list_head *path);
+int coresight_enable_path(struct list_head *path, u32 mode);
 struct coresight_device *coresight_get_sink(struct list_head *path);
 struct list_head *coresight_build_path(struct coresight_device *csdev);
 void coresight_release_path(struct list_head *path);
diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
index b526396d80b6..ac91b0b40ec2 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -265,7 +265,7 @@ static int tmc_enable(struct tmc_drvdata *drvdata, enum tmc_mode mode)
 	return 0;
 }
 
-static int tmc_enable_sink(struct coresight_device *csdev)
+static int tmc_enable_sink(struct coresight_device *csdev, u32 mode)
 {
 	struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
index 0d8fce651ff7..71582f6dfd4c 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -70,7 +70,7 @@ static void tpiu_enable_hw(struct tpiu_drvdata *drvdata)
 	CS_LOCK(drvdata->base);
 }
 
-static int tpiu_enable(struct coresight_device *csdev)
+static int tpiu_enable(struct coresight_device *csdev, u32 mode)
 {
 	struct tpiu_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 95cccb179763..6ec2b66af9ee 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -121,13 +121,13 @@ static int coresight_find_link_outport(struct coresight_device *csdev,
 	return 0;
 }
 
-static int coresight_enable_sink(struct coresight_device *csdev)
+static int coresight_enable_sink(struct coresight_device *csdev, u32 mode)
 {
 	int ret;
 
 	if (!csdev->enable) {
 		if (sink_ops(csdev)->enable) {
-			ret = sink_ops(csdev)->enable(csdev);
+			ret = sink_ops(csdev)->enable(csdev, mode);
 			if (ret)
 				return ret;
 		}
@@ -283,7 +283,7 @@ void coresight_disable_path(struct list_head *path)
 	}
 }
 
-int coresight_enable_path(struct list_head *path)
+int coresight_enable_path(struct list_head *path, u32 mode)
 {
 
 	int ret = 0;
@@ -296,7 +296,7 @@ int coresight_enable_path(struct list_head *path)
 		switch (csdev->type) {
 		case CORESIGHT_DEV_TYPE_SINK:
 		case CORESIGHT_DEV_TYPE_LINKSINK:
-			ret = coresight_enable_sink(csdev);
+			ret = coresight_enable_sink(csdev, mode);
 			if (ret)
 				goto err;
 			break;
@@ -454,7 +454,7 @@ int coresight_enable(struct coresight_device *csdev)
 		goto out;
 	}
 
-	ret = coresight_enable_path(path);
+	ret = coresight_enable_path(path, CS_MODE_SYSFS);
 	if (ret)
 		goto err_path;
 
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 6801dd64ee5d..9fa92dcdd2ea 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -186,7 +186,7 @@ struct coresight_device {
  * @disable:	disables the sink.
  */
 struct coresight_ops_sink {
-	int (*enable)(struct coresight_device *csdev);
+	int (*enable)(struct coresight_device *csdev, u32 mode);
 	void (*disable)(struct coresight_device *csdev);
 };
 
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb  3 10:39:03 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:03 -0700
Subject: [PATCH V9 05/18] coresight: etm3x: moving sysFS entries to dedicated
 file
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-6-git-send-email-mathieu.poirier@linaro.org>

SysFS entries are big enough to justify their own file.
As such moving all sysFS related declarations to a dedicated
location.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/Makefile               |    3 +-
 drivers/hwtracing/coresight/coresight-etm.h        |    4 +
 .../hwtracing/coresight/coresight-etm3x-sysfs.c    | 1218 +++++++++++++++++++
 drivers/hwtracing/coresight/coresight-etm3x.c      | 1234 +-------------------
 4 files changed, 1241 insertions(+), 1218 deletions(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-etm3x-sysfs.c

diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 99f8e5f6256e..233d66cf22d3 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CORESIGHT_SINK_TPIU) += coresight-tpiu.o
 obj-$(CONFIG_CORESIGHT_SINK_ETBV10) += coresight-etb10.o
 obj-$(CONFIG_CORESIGHT_LINKS_AND_SINKS) += coresight-funnel.o \
 					   coresight-replicator.o
-obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o coresight-etm-cp14.o
+obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o coresight-etm-cp14.o \
+					coresight-etm3x-sysfs.o
 obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
 obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
index 34f7db881fa7..9a30aa392ed9 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -280,4 +280,8 @@ static inline unsigned int etm_readl(struct etm_drvdata *drvdata, u32 off)
 
 	return val;
 }
+
+extern const struct attribute_group *coresight_etm_groups[];
+int etm_get_trace_id(struct etm_drvdata *drvdata);
+void etm_set_default(struct etm_drvdata *drvdata);
 #endif
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
new file mode 100644
index 000000000000..f409f5a88e95
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
@@ -0,0 +1,1218 @@
+/*
+ * Copyright(C) 2015 Linaro Limited. All rights reserved.
+ * Author: Mathieu Poirier <mathieu.poirier at linaro.org>
+ *
+ * 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/pm_runtime.h>
+#include <linux/sysfs.h>
+#include "coresight-etm.h"
+
+static ssize_t nr_addr_cmp_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->nr_addr_cmp;
+	return sprintf(buf, "%#lx\n", val);
+}
+static DEVICE_ATTR_RO(nr_addr_cmp);
+
+static ssize_t nr_cntr_show(struct device *dev,
+			    struct device_attribute *attr, char *buf)
+{	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->nr_cntr;
+	return sprintf(buf, "%#lx\n", val);
+}
+static DEVICE_ATTR_RO(nr_cntr);
+
+static ssize_t nr_ctxid_cmp_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->nr_ctxid_cmp;
+	return sprintf(buf, "%#lx\n", val);
+}
+static DEVICE_ATTR_RO(nr_ctxid_cmp);
+
+static ssize_t etmsr_show(struct device *dev,
+			  struct device_attribute *attr, char *buf)
+{
+	unsigned long flags, val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	pm_runtime_get_sync(drvdata->dev);
+	spin_lock_irqsave(&drvdata->spinlock, flags);
+	CS_UNLOCK(drvdata->base);
+
+	val = etm_readl(drvdata, ETMSR);
+
+	CS_LOCK(drvdata->base);
+	spin_unlock_irqrestore(&drvdata->spinlock, flags);
+	pm_runtime_put(drvdata->dev);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+static DEVICE_ATTR_RO(etmsr);
+
+static ssize_t reset_store(struct device *dev,
+			   struct device_attribute *attr,
+			   const char *buf, size_t size)
+{
+	int i, ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	if (val) {
+		spin_lock(&drvdata->spinlock);
+		drvdata->mode = ETM_MODE_EXCLUDE;
+		drvdata->ctrl = 0x0;
+		drvdata->trigger_event = ETM_DEFAULT_EVENT_VAL;
+		drvdata->startstop_ctrl = 0x0;
+		drvdata->addr_idx = 0x0;
+		for (i = 0; i < drvdata->nr_addr_cmp; i++) {
+			drvdata->addr_val[i] = 0x0;
+			drvdata->addr_acctype[i] = 0x0;
+			drvdata->addr_type[i] = ETM_ADDR_TYPE_NONE;
+		}
+		drvdata->cntr_idx = 0x0;
+
+		etm_set_default(drvdata);
+		spin_unlock(&drvdata->spinlock);
+	}
+
+	return size;
+}
+static DEVICE_ATTR_WO(reset);
+
+static ssize_t mode_show(struct device *dev,
+			 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->mode;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t mode_store(struct device *dev,
+			  struct device_attribute *attr,
+			  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->mode = val & ETM_MODE_ALL;
+
+	if (drvdata->mode & ETM_MODE_EXCLUDE)
+		drvdata->enable_ctrl1 |= ETMTECR1_INC_EXC;
+	else
+		drvdata->enable_ctrl1 &= ~ETMTECR1_INC_EXC;
+
+	if (drvdata->mode & ETM_MODE_CYCACC)
+		drvdata->ctrl |= ETMCR_CYC_ACC;
+	else
+		drvdata->ctrl &= ~ETMCR_CYC_ACC;
+
+	if (drvdata->mode & ETM_MODE_STALL) {
+		if (!(drvdata->etmccr & ETMCCR_FIFOFULL)) {
+			dev_warn(drvdata->dev, "stall mode not supported\n");
+			ret = -EINVAL;
+			goto err_unlock;
+		}
+		drvdata->ctrl |= ETMCR_STALL_MODE;
+	 } else
+		drvdata->ctrl &= ~ETMCR_STALL_MODE;
+
+	if (drvdata->mode & ETM_MODE_TIMESTAMP) {
+		if (!(drvdata->etmccer & ETMCCER_TIMESTAMP)) {
+			dev_warn(drvdata->dev, "timestamp not supported\n");
+			ret = -EINVAL;
+			goto err_unlock;
+		}
+		drvdata->ctrl |= ETMCR_TIMESTAMP_EN;
+	} else
+		drvdata->ctrl &= ~ETMCR_TIMESTAMP_EN;
+
+	if (drvdata->mode & ETM_MODE_CTXID)
+		drvdata->ctrl |= ETMCR_CTXID_SIZE;
+	else
+		drvdata->ctrl &= ~ETMCR_CTXID_SIZE;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+
+err_unlock:
+	spin_unlock(&drvdata->spinlock);
+	return ret;
+}
+static DEVICE_ATTR_RW(mode);
+
+static ssize_t trigger_event_show(struct device *dev,
+				  struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->trigger_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t trigger_event_store(struct device *dev,
+				   struct device_attribute *attr,
+				   const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->trigger_event = val & ETM_EVENT_MASK;
+
+	return size;
+}
+static DEVICE_ATTR_RW(trigger_event);
+
+static ssize_t enable_event_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->enable_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t enable_event_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->enable_event = val & ETM_EVENT_MASK;
+
+	return size;
+}
+static DEVICE_ATTR_RW(enable_event);
+
+static ssize_t fifofull_level_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->fifofull_level;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t fifofull_level_store(struct device *dev,
+				    struct device_attribute *attr,
+				    const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->fifofull_level = val;
+
+	return size;
+}
+static DEVICE_ATTR_RW(fifofull_level);
+
+static ssize_t addr_idx_show(struct device *dev,
+			     struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->addr_idx;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t addr_idx_store(struct device *dev,
+			      struct device_attribute *attr,
+			      const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	if (val >= drvdata->nr_addr_cmp)
+		return -EINVAL;
+
+	/*
+	 * Use spinlock to ensure index doesn't change while it gets
+	 * dereferenced multiple times within a spinlock block elsewhere.
+	 */
+	spin_lock(&drvdata->spinlock);
+	drvdata->addr_idx = val;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(addr_idx);
+
+static ssize_t addr_single_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	u8 idx;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
+		spin_unlock(&drvdata->spinlock);
+		return -EINVAL;
+	}
+
+	val = drvdata->addr_val[idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t addr_single_store(struct device *dev,
+				 struct device_attribute *attr,
+				 const char *buf, size_t size)
+{
+	u8 idx;
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
+		spin_unlock(&drvdata->spinlock);
+		return -EINVAL;
+	}
+
+	drvdata->addr_val[idx] = val;
+	drvdata->addr_type[idx] = ETM_ADDR_TYPE_SINGLE;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(addr_single);
+
+static ssize_t addr_range_show(struct device *dev,
+			       struct device_attribute *attr, char *buf)
+{
+	u8 idx;
+	unsigned long val1, val2;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (idx % 2 != 0) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+	if (!((drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
+	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
+	      (drvdata->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
+	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+
+	val1 = drvdata->addr_val[idx];
+	val2 = drvdata->addr_val[idx + 1];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx %#lx\n", val1, val2);
+}
+
+static ssize_t addr_range_store(struct device *dev,
+			      struct device_attribute *attr,
+			      const char *buf, size_t size)
+{
+	u8 idx;
+	unsigned long val1, val2;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	if (sscanf(buf, "%lx %lx", &val1, &val2) != 2)
+		return -EINVAL;
+	/* Lower address comparator cannot have a higher address value */
+	if (val1 > val2)
+		return -EINVAL;
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (idx % 2 != 0) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+	if (!((drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
+	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
+	      (drvdata->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
+	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+
+	drvdata->addr_val[idx] = val1;
+	drvdata->addr_type[idx] = ETM_ADDR_TYPE_RANGE;
+	drvdata->addr_val[idx + 1] = val2;
+	drvdata->addr_type[idx + 1] = ETM_ADDR_TYPE_RANGE;
+	drvdata->enable_ctrl1 |= (1 << (idx/2));
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(addr_range);
+
+static ssize_t addr_start_show(struct device *dev,
+			       struct device_attribute *attr, char *buf)
+{
+	u8 idx;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_START)) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+
+	val = drvdata->addr_val[idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t addr_start_store(struct device *dev,
+				struct device_attribute *attr,
+				const char *buf, size_t size)
+{
+	u8 idx;
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_START)) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+
+	drvdata->addr_val[idx] = val;
+	drvdata->addr_type[idx] = ETM_ADDR_TYPE_START;
+	drvdata->startstop_ctrl |= (1 << idx);
+	drvdata->enable_ctrl1 |= BIT(25);
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(addr_start);
+
+static ssize_t addr_stop_show(struct device *dev,
+			      struct device_attribute *attr, char *buf)
+{
+	u8 idx;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+
+	val = drvdata->addr_val[idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t addr_stop_store(struct device *dev,
+			       struct device_attribute *attr,
+			       const char *buf, size_t size)
+{
+	u8 idx;
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+
+	drvdata->addr_val[idx] = val;
+	drvdata->addr_type[idx] = ETM_ADDR_TYPE_STOP;
+	drvdata->startstop_ctrl |= (1 << (idx + 16));
+	drvdata->enable_ctrl1 |= ETMTECR1_START_STOP;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(addr_stop);
+
+static ssize_t addr_acctype_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	val = drvdata->addr_acctype[drvdata->addr_idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t addr_acctype_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->addr_acctype[drvdata->addr_idx] = val;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(addr_acctype);
+
+static ssize_t cntr_idx_show(struct device *dev,
+			     struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->cntr_idx;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t cntr_idx_store(struct device *dev,
+			      struct device_attribute *attr,
+			      const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	if (val >= drvdata->nr_cntr)
+		return -EINVAL;
+	/*
+	 * Use spinlock to ensure index doesn't change while it gets
+	 * dereferenced multiple times within a spinlock block elsewhere.
+	 */
+	spin_lock(&drvdata->spinlock);
+	drvdata->cntr_idx = val;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(cntr_idx);
+
+static ssize_t cntr_rld_val_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	val = drvdata->cntr_rld_val[drvdata->cntr_idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t cntr_rld_val_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->cntr_rld_val[drvdata->cntr_idx] = val;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(cntr_rld_val);
+
+static ssize_t cntr_event_show(struct device *dev,
+			       struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	val = drvdata->cntr_event[drvdata->cntr_idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t cntr_event_store(struct device *dev,
+				struct device_attribute *attr,
+				const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->cntr_event[drvdata->cntr_idx] = val & ETM_EVENT_MASK;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(cntr_event);
+
+static ssize_t cntr_rld_event_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	val = drvdata->cntr_rld_event[drvdata->cntr_idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t cntr_rld_event_store(struct device *dev,
+				    struct device_attribute *attr,
+				    const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->cntr_rld_event[drvdata->cntr_idx] = val & ETM_EVENT_MASK;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(cntr_rld_event);
+
+static ssize_t cntr_val_show(struct device *dev,
+			     struct device_attribute *attr, char *buf)
+{
+	int i, ret = 0;
+	u32 val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	if (!drvdata->enable) {
+		spin_lock(&drvdata->spinlock);
+		for (i = 0; i < drvdata->nr_cntr; i++)
+			ret += sprintf(buf, "counter %d: %x\n",
+				       i, drvdata->cntr_val[i]);
+		spin_unlock(&drvdata->spinlock);
+		return ret;
+	}
+
+	for (i = 0; i < drvdata->nr_cntr; i++) {
+		val = etm_readl(drvdata, ETMCNTVRn(i));
+		ret += sprintf(buf, "counter %d: %x\n", i, val);
+	}
+
+	return ret;
+}
+
+static ssize_t cntr_val_store(struct device *dev,
+			      struct device_attribute *attr,
+			      const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->cntr_val[drvdata->cntr_idx] = val;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(cntr_val);
+
+static ssize_t seq_12_event_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->seq_12_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t seq_12_event_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->seq_12_event = val & ETM_EVENT_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(seq_12_event);
+
+static ssize_t seq_21_event_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->seq_21_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t seq_21_event_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->seq_21_event = val & ETM_EVENT_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(seq_21_event);
+
+static ssize_t seq_23_event_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->seq_23_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t seq_23_event_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->seq_23_event = val & ETM_EVENT_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(seq_23_event);
+
+static ssize_t seq_31_event_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->seq_31_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t seq_31_event_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->seq_31_event = val & ETM_EVENT_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(seq_31_event);
+
+static ssize_t seq_32_event_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->seq_32_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t seq_32_event_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->seq_32_event = val & ETM_EVENT_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(seq_32_event);
+
+static ssize_t seq_13_event_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->seq_13_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t seq_13_event_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->seq_13_event = val & ETM_EVENT_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(seq_13_event);
+
+static ssize_t seq_curr_state_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	unsigned long val, flags;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	if (!drvdata->enable) {
+		val = drvdata->seq_curr_state;
+		goto out;
+	}
+
+	pm_runtime_get_sync(drvdata->dev);
+	spin_lock_irqsave(&drvdata->spinlock, flags);
+
+	CS_UNLOCK(drvdata->base);
+	val = (etm_readl(drvdata, ETMSQR) & ETM_SQR_MASK);
+	CS_LOCK(drvdata->base);
+
+	spin_unlock_irqrestore(&drvdata->spinlock, flags);
+	pm_runtime_put(drvdata->dev);
+out:
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t seq_curr_state_store(struct device *dev,
+				    struct device_attribute *attr,
+				    const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	if (val > ETM_SEQ_STATE_MAX_VAL)
+		return -EINVAL;
+
+	drvdata->seq_curr_state = val;
+
+	return size;
+}
+static DEVICE_ATTR_RW(seq_curr_state);
+
+static ssize_t ctxid_idx_show(struct device *dev,
+			      struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->ctxid_idx;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t ctxid_idx_store(struct device *dev,
+				struct device_attribute *attr,
+				const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	if (val >= drvdata->nr_ctxid_cmp)
+		return -EINVAL;
+
+	/*
+	 * Use spinlock to ensure index doesn't change while it gets
+	 * dereferenced multiple times within a spinlock block elsewhere.
+	 */
+	spin_lock(&drvdata->spinlock);
+	drvdata->ctxid_idx = val;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(ctxid_idx);
+
+static ssize_t ctxid_pid_show(struct device *dev,
+			      struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	val = drvdata->ctxid_vpid[drvdata->ctxid_idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t ctxid_pid_store(struct device *dev,
+			       struct device_attribute *attr,
+			       const char *buf, size_t size)
+{
+	int ret;
+	unsigned long vpid, pid;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &vpid);
+	if (ret)
+		return ret;
+
+	pid = coresight_vpid_to_pid(vpid);
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->ctxid_pid[drvdata->ctxid_idx] = pid;
+	drvdata->ctxid_vpid[drvdata->ctxid_idx] = vpid;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(ctxid_pid);
+
+static ssize_t ctxid_mask_show(struct device *dev,
+			       struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->ctxid_mask;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t ctxid_mask_store(struct device *dev,
+				struct device_attribute *attr,
+				const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->ctxid_mask = val;
+	return size;
+}
+static DEVICE_ATTR_RW(ctxid_mask);
+
+static ssize_t sync_freq_show(struct device *dev,
+			      struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->sync_freq;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t sync_freq_store(struct device *dev,
+			       struct device_attribute *attr,
+			       const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->sync_freq = val & ETM_SYNC_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(sync_freq);
+
+static ssize_t timestamp_event_show(struct device *dev,
+				    struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->timestamp_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t timestamp_event_store(struct device *dev,
+				     struct device_attribute *attr,
+				     const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->timestamp_event = val & ETM_EVENT_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(timestamp_event);
+
+static ssize_t cpu_show(struct device *dev,
+			struct device_attribute *attr, char *buf)
+{
+	int val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->cpu;
+	return scnprintf(buf, PAGE_SIZE, "%d\n", val);
+
+}
+static DEVICE_ATTR_RO(cpu);
+
+static ssize_t traceid_show(struct device *dev,
+			    struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = etm_get_trace_id(drvdata);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t traceid_store(struct device *dev,
+			     struct device_attribute *attr,
+			     const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->traceid = val & ETM_TRACEID_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(traceid);
+
+static struct attribute *coresight_etm_attrs[] = {
+	&dev_attr_nr_addr_cmp.attr,
+	&dev_attr_nr_cntr.attr,
+	&dev_attr_nr_ctxid_cmp.attr,
+	&dev_attr_etmsr.attr,
+	&dev_attr_reset.attr,
+	&dev_attr_mode.attr,
+	&dev_attr_trigger_event.attr,
+	&dev_attr_enable_event.attr,
+	&dev_attr_fifofull_level.attr,
+	&dev_attr_addr_idx.attr,
+	&dev_attr_addr_single.attr,
+	&dev_attr_addr_range.attr,
+	&dev_attr_addr_start.attr,
+	&dev_attr_addr_stop.attr,
+	&dev_attr_addr_acctype.attr,
+	&dev_attr_cntr_idx.attr,
+	&dev_attr_cntr_rld_val.attr,
+	&dev_attr_cntr_event.attr,
+	&dev_attr_cntr_rld_event.attr,
+	&dev_attr_cntr_val.attr,
+	&dev_attr_seq_12_event.attr,
+	&dev_attr_seq_21_event.attr,
+	&dev_attr_seq_23_event.attr,
+	&dev_attr_seq_31_event.attr,
+	&dev_attr_seq_32_event.attr,
+	&dev_attr_seq_13_event.attr,
+	&dev_attr_seq_curr_state.attr,
+	&dev_attr_ctxid_idx.attr,
+	&dev_attr_ctxid_pid.attr,
+	&dev_attr_ctxid_mask.attr,
+	&dev_attr_sync_freq.attr,
+	&dev_attr_timestamp_event.attr,
+	&dev_attr_traceid.attr,
+	&dev_attr_cpu.attr,
+	NULL,
+};
+
+#define coresight_simple_func(name, offset)                             \
+static ssize_t name##_show(struct device *_dev,                         \
+			   struct device_attribute *attr, char *buf)    \
+{                                                                       \
+	struct etm_drvdata *drvdata = dev_get_drvdata(_dev->parent);    \
+	return scnprintf(buf, PAGE_SIZE, "0x%x\n",                      \
+			 readl_relaxed(drvdata->base + offset));        \
+}                                                                       \
+DEVICE_ATTR_RO(name)
+
+coresight_simple_func(etmccr, ETMCCR);
+coresight_simple_func(etmccer, ETMCCER);
+coresight_simple_func(etmscr, ETMSCR);
+coresight_simple_func(etmidr, ETMIDR);
+coresight_simple_func(etmcr, ETMCR);
+coresight_simple_func(etmtraceidr, ETMTRACEIDR);
+coresight_simple_func(etmteevr, ETMTEEVR);
+coresight_simple_func(etmtssvr, ETMTSSCR);
+coresight_simple_func(etmtecr1, ETMTECR1);
+coresight_simple_func(etmtecr2, ETMTECR2);
+
+static struct attribute *coresight_etm_mgmt_attrs[] = {
+	&dev_attr_etmccr.attr,
+	&dev_attr_etmccer.attr,
+	&dev_attr_etmscr.attr,
+	&dev_attr_etmidr.attr,
+	&dev_attr_etmcr.attr,
+	&dev_attr_etmtraceidr.attr,
+	&dev_attr_etmteevr.attr,
+	&dev_attr_etmtssvr.attr,
+	&dev_attr_etmtecr1.attr,
+	&dev_attr_etmtecr2.attr,
+	NULL,
+};
+
+static const struct attribute_group coresight_etm_group = {
+	.attrs = coresight_etm_attrs,
+};
+
+static const struct attribute_group coresight_etm_mgmt_group = {
+	.attrs = coresight_etm_mgmt_attrs,
+	.name = "mgmt",
+};
+
+const struct attribute_group *coresight_etm_groups[] = {
+	&coresight_etm_group,
+	&coresight_etm_mgmt_group,
+	NULL,
+};
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index d53440e9af6f..6ea35b350958 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -186,7 +186,7 @@ static void etm_clr_prog(struct etm_drvdata *drvdata)
 	}
 }
 
-static void etm_set_default(struct etm_drvdata *drvdata)
+void etm_set_default(struct etm_drvdata *drvdata)
 {
 	int i;
 
@@ -293,15 +293,18 @@ static int etm_cpu_id(struct coresight_device *csdev)
 	return drvdata->cpu;
 }
 
-static int etm_trace_id(struct coresight_device *csdev)
+int etm_get_trace_id(struct etm_drvdata *drvdata)
 {
-	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	unsigned long flags;
 	int trace_id = -1;
 
+	if (!drvdata)
+		goto out;
+
 	if (!drvdata->enable)
 		return drvdata->traceid;
-	pm_runtime_get_sync(csdev->dev.parent);
+
+	pm_runtime_get_sync(drvdata->dev);
 
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 
@@ -310,9 +313,18 @@ static int etm_trace_id(struct coresight_device *csdev)
 	CS_LOCK(drvdata->base);
 
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
-	pm_runtime_put(csdev->dev.parent);
+	pm_runtime_put(drvdata->dev);
 
+out:
 	return trace_id;
+
+}
+
+static int etm_trace_id(struct coresight_device *csdev)
+{
+	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	return etm_get_trace_id(drvdata);
 }
 
 static int etm_enable(struct coresight_device *csdev)
@@ -406,1218 +418,6 @@ static const struct coresight_ops etm_cs_ops = {
 	.source_ops	= &etm_source_ops,
 };
 
-static ssize_t nr_addr_cmp_show(struct device *dev,
-				struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->nr_addr_cmp;
-	return sprintf(buf, "%#lx\n", val);
-}
-static DEVICE_ATTR_RO(nr_addr_cmp);
-
-static ssize_t nr_cntr_show(struct device *dev,
-			    struct device_attribute *attr, char *buf)
-{	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->nr_cntr;
-	return sprintf(buf, "%#lx\n", val);
-}
-static DEVICE_ATTR_RO(nr_cntr);
-
-static ssize_t nr_ctxid_cmp_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->nr_ctxid_cmp;
-	return sprintf(buf, "%#lx\n", val);
-}
-static DEVICE_ATTR_RO(nr_ctxid_cmp);
-
-static ssize_t etmsr_show(struct device *dev,
-			  struct device_attribute *attr, char *buf)
-{
-	unsigned long flags, val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	pm_runtime_get_sync(drvdata->dev);
-	spin_lock_irqsave(&drvdata->spinlock, flags);
-	CS_UNLOCK(drvdata->base);
-
-	val = etm_readl(drvdata, ETMSR);
-
-	CS_LOCK(drvdata->base);
-	spin_unlock_irqrestore(&drvdata->spinlock, flags);
-	pm_runtime_put(drvdata->dev);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-static DEVICE_ATTR_RO(etmsr);
-
-static ssize_t reset_store(struct device *dev,
-			   struct device_attribute *attr,
-			   const char *buf, size_t size)
-{
-	int i, ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	if (val) {
-		spin_lock(&drvdata->spinlock);
-		drvdata->mode = ETM_MODE_EXCLUDE;
-		drvdata->ctrl = 0x0;
-		drvdata->trigger_event = ETM_DEFAULT_EVENT_VAL;
-		drvdata->startstop_ctrl = 0x0;
-		drvdata->addr_idx = 0x0;
-		for (i = 0; i < drvdata->nr_addr_cmp; i++) {
-			drvdata->addr_val[i] = 0x0;
-			drvdata->addr_acctype[i] = 0x0;
-			drvdata->addr_type[i] = ETM_ADDR_TYPE_NONE;
-		}
-		drvdata->cntr_idx = 0x0;
-
-		etm_set_default(drvdata);
-		spin_unlock(&drvdata->spinlock);
-	}
-
-	return size;
-}
-static DEVICE_ATTR_WO(reset);
-
-static ssize_t mode_show(struct device *dev,
-			 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->mode;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t mode_store(struct device *dev,
-			  struct device_attribute *attr,
-			  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	drvdata->mode = val & ETM_MODE_ALL;
-
-	if (drvdata->mode & ETM_MODE_EXCLUDE)
-		drvdata->enable_ctrl1 |= ETMTECR1_INC_EXC;
-	else
-		drvdata->enable_ctrl1 &= ~ETMTECR1_INC_EXC;
-
-	if (drvdata->mode & ETM_MODE_CYCACC)
-		drvdata->ctrl |= ETMCR_CYC_ACC;
-	else
-		drvdata->ctrl &= ~ETMCR_CYC_ACC;
-
-	if (drvdata->mode & ETM_MODE_STALL) {
-		if (!(drvdata->etmccr & ETMCCR_FIFOFULL)) {
-			dev_warn(drvdata->dev, "stall mode not supported\n");
-			ret = -EINVAL;
-			goto err_unlock;
-		}
-		drvdata->ctrl |= ETMCR_STALL_MODE;
-	 } else
-		drvdata->ctrl &= ~ETMCR_STALL_MODE;
-
-	if (drvdata->mode & ETM_MODE_TIMESTAMP) {
-		if (!(drvdata->etmccer & ETMCCER_TIMESTAMP)) {
-			dev_warn(drvdata->dev, "timestamp not supported\n");
-			ret = -EINVAL;
-			goto err_unlock;
-		}
-		drvdata->ctrl |= ETMCR_TIMESTAMP_EN;
-	} else
-		drvdata->ctrl &= ~ETMCR_TIMESTAMP_EN;
-
-	if (drvdata->mode & ETM_MODE_CTXID)
-		drvdata->ctrl |= ETMCR_CTXID_SIZE;
-	else
-		drvdata->ctrl &= ~ETMCR_CTXID_SIZE;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-
-err_unlock:
-	spin_unlock(&drvdata->spinlock);
-	return ret;
-}
-static DEVICE_ATTR_RW(mode);
-
-static ssize_t trigger_event_show(struct device *dev,
-				  struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->trigger_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t trigger_event_store(struct device *dev,
-				   struct device_attribute *attr,
-				   const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->trigger_event = val & ETM_EVENT_MASK;
-
-	return size;
-}
-static DEVICE_ATTR_RW(trigger_event);
-
-static ssize_t enable_event_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->enable_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t enable_event_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->enable_event = val & ETM_EVENT_MASK;
-
-	return size;
-}
-static DEVICE_ATTR_RW(enable_event);
-
-static ssize_t fifofull_level_show(struct device *dev,
-				   struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->fifofull_level;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t fifofull_level_store(struct device *dev,
-				    struct device_attribute *attr,
-				    const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->fifofull_level = val;
-
-	return size;
-}
-static DEVICE_ATTR_RW(fifofull_level);
-
-static ssize_t addr_idx_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->addr_idx;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t addr_idx_store(struct device *dev,
-			      struct device_attribute *attr,
-			      const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	if (val >= drvdata->nr_addr_cmp)
-		return -EINVAL;
-
-	/*
-	 * Use spinlock to ensure index doesn't change while it gets
-	 * dereferenced multiple times within a spinlock block elsewhere.
-	 */
-	spin_lock(&drvdata->spinlock);
-	drvdata->addr_idx = val;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(addr_idx);
-
-static ssize_t addr_single_show(struct device *dev,
-				struct device_attribute *attr, char *buf)
-{
-	u8 idx;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
-		spin_unlock(&drvdata->spinlock);
-		return -EINVAL;
-	}
-
-	val = drvdata->addr_val[idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t addr_single_store(struct device *dev,
-				 struct device_attribute *attr,
-				 const char *buf, size_t size)
-{
-	u8 idx;
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
-		spin_unlock(&drvdata->spinlock);
-		return -EINVAL;
-	}
-
-	drvdata->addr_val[idx] = val;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_SINGLE;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(addr_single);
-
-static ssize_t addr_range_show(struct device *dev,
-			       struct device_attribute *attr, char *buf)
-{
-	u8 idx;
-	unsigned long val1, val2;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (idx % 2 != 0) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-	if (!((drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
-	      (drvdata->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-
-	val1 = drvdata->addr_val[idx];
-	val2 = drvdata->addr_val[idx + 1];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx %#lx\n", val1, val2);
-}
-
-static ssize_t addr_range_store(struct device *dev,
-			      struct device_attribute *attr,
-			      const char *buf, size_t size)
-{
-	u8 idx;
-	unsigned long val1, val2;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	if (sscanf(buf, "%lx %lx", &val1, &val2) != 2)
-		return -EINVAL;
-	/* Lower address comparator cannot have a higher address value */
-	if (val1 > val2)
-		return -EINVAL;
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (idx % 2 != 0) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-	if (!((drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
-	      (drvdata->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-
-	drvdata->addr_val[idx] = val1;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_RANGE;
-	drvdata->addr_val[idx + 1] = val2;
-	drvdata->addr_type[idx + 1] = ETM_ADDR_TYPE_RANGE;
-	drvdata->enable_ctrl1 |= (1 << (idx/2));
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(addr_range);
-
-static ssize_t addr_start_show(struct device *dev,
-			       struct device_attribute *attr, char *buf)
-{
-	u8 idx;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_START)) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-
-	val = drvdata->addr_val[idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t addr_start_store(struct device *dev,
-				struct device_attribute *attr,
-				const char *buf, size_t size)
-{
-	u8 idx;
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_START)) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-
-	drvdata->addr_val[idx] = val;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_START;
-	drvdata->startstop_ctrl |= (1 << idx);
-	drvdata->enable_ctrl1 |= BIT(25);
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(addr_start);
-
-static ssize_t addr_stop_show(struct device *dev,
-			      struct device_attribute *attr, char *buf)
-{
-	u8 idx;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-
-	val = drvdata->addr_val[idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t addr_stop_store(struct device *dev,
-			       struct device_attribute *attr,
-			       const char *buf, size_t size)
-{
-	u8 idx;
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-
-	drvdata->addr_val[idx] = val;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_STOP;
-	drvdata->startstop_ctrl |= (1 << (idx + 16));
-	drvdata->enable_ctrl1 |= ETMTECR1_START_STOP;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(addr_stop);
-
-static ssize_t addr_acctype_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	val = drvdata->addr_acctype[drvdata->addr_idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t addr_acctype_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	drvdata->addr_acctype[drvdata->addr_idx] = val;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(addr_acctype);
-
-static ssize_t cntr_idx_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->cntr_idx;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t cntr_idx_store(struct device *dev,
-			      struct device_attribute *attr,
-			      const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	if (val >= drvdata->nr_cntr)
-		return -EINVAL;
-	/*
-	 * Use spinlock to ensure index doesn't change while it gets
-	 * dereferenced multiple times within a spinlock block elsewhere.
-	 */
-	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_idx = val;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(cntr_idx);
-
-static ssize_t cntr_rld_val_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	val = drvdata->cntr_rld_val[drvdata->cntr_idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t cntr_rld_val_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_rld_val[drvdata->cntr_idx] = val;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(cntr_rld_val);
-
-static ssize_t cntr_event_show(struct device *dev,
-			       struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	val = drvdata->cntr_event[drvdata->cntr_idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t cntr_event_store(struct device *dev,
-				struct device_attribute *attr,
-				const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_event[drvdata->cntr_idx] = val & ETM_EVENT_MASK;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(cntr_event);
-
-static ssize_t cntr_rld_event_show(struct device *dev,
-				   struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	val = drvdata->cntr_rld_event[drvdata->cntr_idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t cntr_rld_event_store(struct device *dev,
-				    struct device_attribute *attr,
-				    const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_rld_event[drvdata->cntr_idx] = val & ETM_EVENT_MASK;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(cntr_rld_event);
-
-static ssize_t cntr_val_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
-{
-	int i, ret = 0;
-	u32 val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	if (!drvdata->enable) {
-		spin_lock(&drvdata->spinlock);
-		for (i = 0; i < drvdata->nr_cntr; i++)
-			ret += sprintf(buf, "counter %d: %x\n",
-				       i, drvdata->cntr_val[i]);
-		spin_unlock(&drvdata->spinlock);
-		return ret;
-	}
-
-	for (i = 0; i < drvdata->nr_cntr; i++) {
-		val = etm_readl(drvdata, ETMCNTVRn(i));
-		ret += sprintf(buf, "counter %d: %x\n", i, val);
-	}
-
-	return ret;
-}
-
-static ssize_t cntr_val_store(struct device *dev,
-			      struct device_attribute *attr,
-			      const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_val[drvdata->cntr_idx] = val;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(cntr_val);
-
-static ssize_t seq_12_event_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->seq_12_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t seq_12_event_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->seq_12_event = val & ETM_EVENT_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(seq_12_event);
-
-static ssize_t seq_21_event_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->seq_21_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t seq_21_event_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->seq_21_event = val & ETM_EVENT_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(seq_21_event);
-
-static ssize_t seq_23_event_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->seq_23_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t seq_23_event_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->seq_23_event = val & ETM_EVENT_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(seq_23_event);
-
-static ssize_t seq_31_event_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->seq_31_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t seq_31_event_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->seq_31_event = val & ETM_EVENT_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(seq_31_event);
-
-static ssize_t seq_32_event_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->seq_32_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t seq_32_event_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->seq_32_event = val & ETM_EVENT_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(seq_32_event);
-
-static ssize_t seq_13_event_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->seq_13_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t seq_13_event_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->seq_13_event = val & ETM_EVENT_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(seq_13_event);
-
-static ssize_t seq_curr_state_show(struct device *dev,
-				   struct device_attribute *attr, char *buf)
-{
-	unsigned long val, flags;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	if (!drvdata->enable) {
-		val = drvdata->seq_curr_state;
-		goto out;
-	}
-
-	pm_runtime_get_sync(drvdata->dev);
-	spin_lock_irqsave(&drvdata->spinlock, flags);
-
-	CS_UNLOCK(drvdata->base);
-	val = (etm_readl(drvdata, ETMSQR) & ETM_SQR_MASK);
-	CS_LOCK(drvdata->base);
-
-	spin_unlock_irqrestore(&drvdata->spinlock, flags);
-	pm_runtime_put(drvdata->dev);
-out:
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t seq_curr_state_store(struct device *dev,
-				    struct device_attribute *attr,
-				    const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	if (val > ETM_SEQ_STATE_MAX_VAL)
-		return -EINVAL;
-
-	drvdata->seq_curr_state = val;
-
-	return size;
-}
-static DEVICE_ATTR_RW(seq_curr_state);
-
-static ssize_t ctxid_idx_show(struct device *dev,
-			      struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->ctxid_idx;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t ctxid_idx_store(struct device *dev,
-				struct device_attribute *attr,
-				const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	if (val >= drvdata->nr_ctxid_cmp)
-		return -EINVAL;
-
-	/*
-	 * Use spinlock to ensure index doesn't change while it gets
-	 * dereferenced multiple times within a spinlock block elsewhere.
-	 */
-	spin_lock(&drvdata->spinlock);
-	drvdata->ctxid_idx = val;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(ctxid_idx);
-
-static ssize_t ctxid_pid_show(struct device *dev,
-			      struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	val = drvdata->ctxid_vpid[drvdata->ctxid_idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t ctxid_pid_store(struct device *dev,
-			       struct device_attribute *attr,
-			       const char *buf, size_t size)
-{
-	int ret;
-	unsigned long vpid, pid;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &vpid);
-	if (ret)
-		return ret;
-
-	pid = coresight_vpid_to_pid(vpid);
-
-	spin_lock(&drvdata->spinlock);
-	drvdata->ctxid_pid[drvdata->ctxid_idx] = pid;
-	drvdata->ctxid_vpid[drvdata->ctxid_idx] = vpid;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(ctxid_pid);
-
-static ssize_t ctxid_mask_show(struct device *dev,
-			       struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->ctxid_mask;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t ctxid_mask_store(struct device *dev,
-				struct device_attribute *attr,
-				const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->ctxid_mask = val;
-	return size;
-}
-static DEVICE_ATTR_RW(ctxid_mask);
-
-static ssize_t sync_freq_show(struct device *dev,
-			      struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->sync_freq;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t sync_freq_store(struct device *dev,
-			       struct device_attribute *attr,
-			       const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->sync_freq = val & ETM_SYNC_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(sync_freq);
-
-static ssize_t timestamp_event_show(struct device *dev,
-				    struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->timestamp_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t timestamp_event_store(struct device *dev,
-				     struct device_attribute *attr,
-				     const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->timestamp_event = val & ETM_EVENT_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(timestamp_event);
-
-static ssize_t cpu_show(struct device *dev,
-			struct device_attribute *attr, char *buf)
-{
-	int val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->cpu;
-	return scnprintf(buf, PAGE_SIZE, "%d\n", val);
-
-}
-static DEVICE_ATTR_RO(cpu);
-
-static ssize_t traceid_show(struct device *dev,
-			    struct device_attribute *attr, char *buf)
-{
-	unsigned long val, flags;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	if (!drvdata->enable) {
-		val = drvdata->traceid;
-		goto out;
-	}
-
-	pm_runtime_get_sync(drvdata->dev);
-	spin_lock_irqsave(&drvdata->spinlock, flags);
-	CS_UNLOCK(drvdata->base);
-
-	val = (etm_readl(drvdata, ETMTRACEIDR) & ETM_TRACEID_MASK);
-
-	CS_LOCK(drvdata->base);
-	spin_unlock_irqrestore(&drvdata->spinlock, flags);
-	pm_runtime_put(drvdata->dev);
-out:
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t traceid_store(struct device *dev,
-			     struct device_attribute *attr,
-			     const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->traceid = val & ETM_TRACEID_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(traceid);
-
-static struct attribute *coresight_etm_attrs[] = {
-	&dev_attr_nr_addr_cmp.attr,
-	&dev_attr_nr_cntr.attr,
-	&dev_attr_nr_ctxid_cmp.attr,
-	&dev_attr_etmsr.attr,
-	&dev_attr_reset.attr,
-	&dev_attr_mode.attr,
-	&dev_attr_trigger_event.attr,
-	&dev_attr_enable_event.attr,
-	&dev_attr_fifofull_level.attr,
-	&dev_attr_addr_idx.attr,
-	&dev_attr_addr_single.attr,
-	&dev_attr_addr_range.attr,
-	&dev_attr_addr_start.attr,
-	&dev_attr_addr_stop.attr,
-	&dev_attr_addr_acctype.attr,
-	&dev_attr_cntr_idx.attr,
-	&dev_attr_cntr_rld_val.attr,
-	&dev_attr_cntr_event.attr,
-	&dev_attr_cntr_rld_event.attr,
-	&dev_attr_cntr_val.attr,
-	&dev_attr_seq_12_event.attr,
-	&dev_attr_seq_21_event.attr,
-	&dev_attr_seq_23_event.attr,
-	&dev_attr_seq_31_event.attr,
-	&dev_attr_seq_32_event.attr,
-	&dev_attr_seq_13_event.attr,
-	&dev_attr_seq_curr_state.attr,
-	&dev_attr_ctxid_idx.attr,
-	&dev_attr_ctxid_pid.attr,
-	&dev_attr_ctxid_mask.attr,
-	&dev_attr_sync_freq.attr,
-	&dev_attr_timestamp_event.attr,
-	&dev_attr_traceid.attr,
-	&dev_attr_cpu.attr,
-	NULL,
-};
-
-#define coresight_simple_func(name, offset)                             \
-static ssize_t name##_show(struct device *_dev,                         \
-			   struct device_attribute *attr, char *buf)    \
-{                                                                       \
-	struct etm_drvdata *drvdata = dev_get_drvdata(_dev->parent);    \
-	return scnprintf(buf, PAGE_SIZE, "0x%x\n",                      \
-			 readl_relaxed(drvdata->base + offset));        \
-}                                                                       \
-DEVICE_ATTR_RO(name)
-
-coresight_simple_func(etmccr, ETMCCR);
-coresight_simple_func(etmccer, ETMCCER);
-coresight_simple_func(etmscr, ETMSCR);
-coresight_simple_func(etmidr, ETMIDR);
-coresight_simple_func(etmcr, ETMCR);
-coresight_simple_func(etmtraceidr, ETMTRACEIDR);
-coresight_simple_func(etmteevr, ETMTEEVR);
-coresight_simple_func(etmtssvr, ETMTSSCR);
-coresight_simple_func(etmtecr1, ETMTECR1);
-coresight_simple_func(etmtecr2, ETMTECR2);
-
-static struct attribute *coresight_etm_mgmt_attrs[] = {
-	&dev_attr_etmccr.attr,
-	&dev_attr_etmccer.attr,
-	&dev_attr_etmscr.attr,
-	&dev_attr_etmidr.attr,
-	&dev_attr_etmcr.attr,
-	&dev_attr_etmtraceidr.attr,
-	&dev_attr_etmteevr.attr,
-	&dev_attr_etmtssvr.attr,
-	&dev_attr_etmtecr1.attr,
-	&dev_attr_etmtecr2.attr,
-	NULL,
-};
-
-static const struct attribute_group coresight_etm_group = {
-	.attrs = coresight_etm_attrs,
-};
-
-
-static const struct attribute_group coresight_etm_mgmt_group = {
-	.attrs = coresight_etm_mgmt_attrs,
-	.name = "mgmt",
-};
-
-static const struct attribute_group *coresight_etm_groups[] = {
-	&coresight_etm_group,
-	&coresight_etm_mgmt_group,
-	NULL,
-};
-
 static int etm_cpu_callback(struct notifier_block *nfb, unsigned long action,
 			    void *hcpu)
 {
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb  3 10:39:00 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed,  3 Feb 2016 11:39:00 -0700
Subject: [PATCH V9 02/18] coresight: add API to get sink from path
In-Reply-To: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
References: <1454524756-10628-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1454524756-10628-3-git-send-email-mathieu.poirier@linaro.org>

Add an API allowing external code to quickly get a handle on the
sink within a path.  The sink is always last, but adding an API allows
to keep the path's node structure private and remove redundant checks.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-priv.h |  1 +
 drivers/hwtracing/coresight/coresight.c      | 15 +++++++++++++++
 2 files changed, 16 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 7b193a34d709..14f245a2018d 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -54,6 +54,7 @@ static inline void CS_UNLOCK(void __iomem *addr)
 
 void coresight_disable_path(struct list_head *path);
 int coresight_enable_path(struct list_head *path);
+struct coresight_device *coresight_get_sink(struct list_head *path);
 struct list_head *coresight_build_path(struct coresight_device *csdev);
 void coresight_release_path(struct list_head *path);
 
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index f26589effb70..2ed48545df26 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -321,6 +321,21 @@ err:
 	goto out;
 }
 
+struct coresight_device *coresight_get_sink(struct list_head *path)
+{
+	struct coresight_device *csdev;
+
+	if (!path)
+		return NULL;
+
+	csdev = list_last_entry(path, struct coresight_node, link)->csdev;
+	if (csdev->type != CORESIGHT_DEV_TYPE_SINK &&
+	    csdev->type != CORESIGHT_DEV_TYPE_LINKSINK)
+		return NULL;
+
+	return csdev;
+}
+
 /**
  * _coresight_build_path - recursively build a path from a @csdev to a sink.
  * @csdev:	The device to start from.
-- 
2.1.4



From maxime.ripard at free-electrons.com  Wed Feb  3 11:29:13 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 3 Feb 2016 20:29:13 +0100
Subject: [PATCH 5/5] clk: sunxi: Remove clk_register_clkdev calls
In-Reply-To: <20160202112604.447baec98bf89a79542fd240@free.fr>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454402834-6385-6-git-send-email-maxime.ripard@free-electrons.com>
 <20160202112604.447baec98bf89a79542fd240@free.fr>
Message-ID: <20160203192913.GA3327@lukather>

On Tue, Feb 02, 2016 at 11:26:04AM +0100, Jean-Francois Moine wrote:
> On Tue,  2 Feb 2016 09:47:14 +0100
> Maxime Ripard <maxime.ripard at free-electrons.com> wrote:
> 
> > diff --git a/drivers/clk/sunxi/clk-mod0.c b/drivers/clk/sunxi/clk-mod0.c
> > index 578bff0dd251..b38d71cec74c 100644
> > --- a/drivers/clk/sunxi/clk-mod0.c
> > +++ b/drivers/clk/sunxi/clk-mod0.c
> > @@ -15,6 +15,7 @@
> >   */
> >  
> >  #include <linux/clk.h>
> > +#include <linux/clkdev.h>
> 
> Why?

Because this driver uses __clk_get, that it was previously included in
clk-factors.h and is not anymore, and that otherwise it won't compile,
obviously.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/bfdb411e/attachment.sig>

From mark.rutland at arm.com  Wed Feb  3 11:31:50 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 3 Feb 2016 19:31:50 +0000
Subject: [PATCH v4 4/7] arm64: Handle early CPU boot failures
In-Reply-To: <20160203181250.GE26487@MBP.local>
References: <1453745225-27736-1-git-send-email-suzuki.poulose@arm.com>
 <1453745225-27736-5-git-send-email-suzuki.poulose@arm.com>
 <20160203125735.GA26487@MBP.local>
 <20160203164632.GC1234@leverpostej>
 <20160203173448.GD26487@MBP.local>
 <20160203175351.GG1234@leverpostej>
 <20160203181250.GE26487@MBP.local>
Message-ID: <20160203193149.GJ1234@leverpostej>

On Wed, Feb 03, 2016 at 06:12:52PM +0000, Catalin Marinas wrote:
> On Wed, Feb 03, 2016 at 05:53:51PM +0000, Mark Rutland wrote:
> > On Wed, Feb 03, 2016 at 05:34:49PM +0000, Catalin Marinas wrote:
> > > In general, if you perform cache maintenance on a non-shareable mapping,
> > > I don't think it would be broadcast. But in this case, the MMU is off,
> > > data accesses default to Device_nGnRnE and considered outer shareable,
> > > so it may actually work. Is this stated anywhere in the ARM ARM?
> > 
> > In ARM DDI 0487A.h, D4.2.8 "The effects of disabling a stage of address
> > translation" we state:
> > 
> > 	Cache maintenance instructions act on the target cache
> > 	regardless of whether any stages of address translation are
> > 	disabled, and regardless of the values of the memory attributes.
> > 	However, if a stage of address translation is disabled, they use
> > 	the flat address mapping for that translation stage.
> 
> But does "target cache" include other CPUs in the system?

It appears so. There's a more complete description (with a table) on
page D3-1718, "Effects of instructions that operate by VA to the Point
of Coherency", where it's explicitly stated:

	For Device memory and Normal memory that is Inner Non-cacheable,
	Outer Non-cacheable, these instructions must affect the caches
	of all PEs in the Outer Shareable shareability domain of the PE
	on which the instruction is operating.

In other cases, per the table, the maintenance may be limited to a
smaller set of caches.

Thanks,
Mark.


From tchalamarla at caviumnetworks.com  Wed Feb  3 11:43:08 2016
From: tchalamarla at caviumnetworks.com (tchalamarla at caviumnetworks.com)
Date: Wed, 3 Feb 2016 11:43:08 -0800
Subject: [PATCH] irqchip-gicv3: wait for ack from redistributer after read_iar
Message-ID: <1454528588-32721-1-git-send-email-tchalamarla@caviumnetworks.com>

From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>

Systems with high number of cores and sufficiently loaded,
there exists a small window where it is possible for re-distributor
to illegally merge two LPI and cuases missing interrupts.

Solution is, wait for ack from the redistributor after read_iar.
A "dsb sy" after IAR read ensures there is no illegal merge windows.

giv3 spec version 32 also warns this, see section 4.4.13

Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
---
 arch/arm64/include/asm/arch_gicv3.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/include/asm/arch_gicv3.h b/arch/arm64/include/asm/arch_gicv3.h
index 2731d3b..8ec88e5 100644
--- a/arch/arm64/include/asm/arch_gicv3.h
+++ b/arch/arm64/include/asm/arch_gicv3.h
@@ -103,6 +103,7 @@ static inline u64 gic_read_iar_common(void)
 	u64 irqstat;
 
 	asm volatile("mrs_s %0, " __stringify(ICC_IAR1_EL1) : "=r" (irqstat));
+	dsb(sy);
 	return irqstat;
 }
 
-- 
2.1.0



From linus.walleij at linaro.org  Wed Feb  3 11:55:08 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed,  3 Feb 2016 20:55:08 +0100
Subject: [PATCH] ARM: ICST: avoid arithmetic overflow in icst_hz()
Message-ID: <1454529308-31887-1-git-send-email-linus.walleij@linaro.org>

When trying to set the ICST 307 clock to 25174000 Hz I ran into
this arithmetic error: the icst_hz_to_vco() correctly figure out
DIVIDE=2, RDW=100 and VDW=99 yielding a frequency of
25174000 Hz out of the VCO. (I replicated the icst_hz() function
in a spreadsheet to verify this.)

However, when I called icst_hz() on these VCO settings it would
instead return 4122709 Hz. This causes an error in the common
clock driver for ICST as the common clock framework will call
.round_rate() on the clock which will utilize icst_hz_to_vco()
followed by icst_hz() suggesting the erroneous frequency, and
then the clock gets set to this.

The error did not manifest in the old clock framework since
this high frequency was only used by the CLCD, which calls
clk_set_rate() without first calling clk_round_rate() and since
the old clock framework would not call clk_round_rate() before
setting the frequency, the correct values propagated into
the VCO.

After some experimenting I figured out that it was due to a simple
arithmetic overflow: the divisor for 24Mhz reference frequency
as reference becomes 24000000*2*(99+8)=0x132212400 and the "1"
in bit 32 overflows and is lost.

But introducing an explicit 64-by-32 bit do_div() and casting
the divisor into (u64) we get the right frequency back, and the
right frequency gets set.

Tested on the ARM Versatile.

Cc: stable at vger.kernel.org
Cc: linux-clk at vger.kernel.org
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Pawel Moll <pawel.moll at arm.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/common/icst.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/common/icst.c b/arch/arm/common/icst.c
index 2dc6da70ae59..d3c0e69df259 100644
--- a/arch/arm/common/icst.c
+++ b/arch/arm/common/icst.c
@@ -16,7 +16,7 @@
  */
 #include <linux/module.h>
 #include <linux/kernel.h>
-
+#include <asm/div64.h>
 #include <asm/hardware/icst.h>
 
 /*
@@ -29,7 +29,11 @@ EXPORT_SYMBOL(icst525_s2div);
 
 unsigned long icst_hz(const struct icst_params *p, struct icst_vco vco)
 {
-	return p->ref * 2 * (vco.v + 8) / ((vco.r + 2) * p->s2div[vco.s]);
+	u64 dividend = p->ref * 2 * (u64)(vco.v + 8);
+	u32 divisor = (vco.r + 2) * p->s2div[vco.s];
+
+	do_div(dividend, divisor);
+	return (unsigned long)dividend;
 }
 
 EXPORT_SYMBOL(icst_hz);
-- 
2.4.3



From maxime.ripard at free-electrons.com  Wed Feb  3 11:59:19 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 3 Feb 2016 20:59:19 +0100
Subject: [PATCH v2 17/26] drm: sun4i: Add DT bindings documentation
In-Reply-To: <20160115031515.GA19797@rob-hp-laptop>
References: <1452785109-6172-1-git-send-email-maxime.ripard@free-electrons.com>
 <1452785109-6172-18-git-send-email-maxime.ripard@free-electrons.com>
 <20160115031515.GA19797@rob-hp-laptop>
Message-ID: <20160203195919.GB3327@lukather>

Hi Rob,

On Thu, Jan 14, 2016 at 09:15:15PM -0600, Rob Herring wrote:
> On Thu, Jan 14, 2016 at 04:25:00PM +0100, Maxime Ripard wrote:
> > The display pipeline of the Allwinner A10 is involving several loosely
> > coupled components.
> > 
> > Add a documentation for the bindings.
> > 
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > ---
> >  .../bindings/display/sunxi/sun4i-drm.txt           | 228 +++++++++++++++++++++
> 
> drm is a linuxism. It shouldn't be used for binding doc.

Ack

> >  1 file changed, 228 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > new file mode 100644
> > index 000000000000..061bc87147a3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > @@ -0,0 +1,228 @@
> > +Allwinner A10 Display Pipeline
> > +==============================
> > +
> > +The Allwinner A10 Display pipeline is composed of several components
> > +that are going to be documented below:
> > +
> > +TV Encoder
> > +----------
> > +
> > +The TV Encoder supports the composite and VGA output. It is one end of
> > +the pipeline.
> > +
> > +Required properties:
> > + - compatible: value should be "allwinner,sun4i-a10-tv-encoder".
> > + - reg: base address and size of memory-mapped region
> > + - clocks: the clocks driving the TV encoder
> > +
> > +- ports: A ports node with endpoint definitions as defined in
> > +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > +  first port should be the input endpoint.
> > +
> > +TCON
> > +----
> > +
> > +The TCON acts as a timing controller for RGB, LVDS and TV interfaces.
> > +
> > +Required properties:
> > + - compatible: value should be "allwinner,sun4i-a10-tcon".
> > + - reg: base address and size of memory-mapped region
> > + - interrupts: interrupt associated to this IP
> > + - clocks: phandles to the clocks feeding the TCON. Three are needed:
> > +   - 'ahb': the interface clocks
> > +   - 'tcon-ch0': The clock driving the TCON channel 0
> > +   - 'tcon-ch1': The clock driving the TCON channel 1
> > +
> > + - clock-names: the clock names mentioned above
> > + - clock-output-names: Name of the pixel clock created
> > +
> > +- ports: A ports node with endpoint definitions as defined in
> > +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > +  first port should be the input endpoint, the second one the output
> > +
> > +Optional properties:
> > +  - allwinner,panel: phandle to the panel used in our RGB interface
> > +
> > +
> > +Display Engine Backend
> > +----------------------
> > +
> > +The display engine backend exposes layers and sprites to the
> > +system.
> > +
> > +Required properties:
> > +  - compatible: value must be one of:
> > +    * allwinner,sun5i-a13-display-backend
> > +  - reg: base address and size of the memory-mapped region.
> > +  - clocks: phandles to the clocks feeding the frontend and backend
> > +    * ahb: the backend interface clock
> > +    * mod: the backend module clock
> > +    * ram: the backend DRAM clock
> > +  - clock-names: the clock names mentioned above
> > +  - resets: phandles to the reset controllers driving the backend
> > +
> > +- ports: A ports node with endpoint definitions as defined in
> > +  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > +  first port should be the input endpoints, the second one the output
> > +
> > +Display Engine Frontend
> > +-----------------------
> > +
> > +The display engine frontend does formats conversion, scaling,
> > +deinterlacing and color space conversion.
> > +
> > +Required properties:
> > +  - compatible: value must be one of:
> > +    * allwinner,sun5i-a13-display-frontend
> > +  - reg: base address and size of the memory-mapped region.
> > +  - interrupts: interrupt associated to this IP
> > +  - clocks: phandles to the clocks feeding the frontend and backend
> 
> > +    * ahb: the backend interface clock
> > +    * mod: the backend module clock
> > +    * ram: the backend DRAM clock
> 
> should be frontend?

Yeah, stupid copy/paste mistake :/

> 
> > +  - clock-names: the clock names mentioned above
> > +  - resets: phandles to the reset controllers driving the backend
> 
> ditto
> 
> > +
> > +Display Engine Pipeline
> > +-----------------------
> > +
> > +The display engine pipeline (and its entry point, since it can be
> > +either directly the backend or the frontend) is represented as an
> > +extra node.
> > +
> > +Required properties:
> > +  - compatible: value must be one of:
> > +    * allwinner,sun5i-a13-display-engine
> > +  - allwinner,pipelines: list of phandle to the entry points of the
> > +    pipelines (either to the frontend or backend)
> > +
> > +Example:
> > +
> > +panel: panel {
> > +	compatible = "olimex,lcd-olinuxino-43-ts";
> 
> This should either be a child of what it is attached to or use of-graph.

You had a similar discussion with Thierry last time I sent it, and it
seemed to settle on keeping that property:

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/382115.html

Has that changed?

> > +};
> > +
> > +tve0: tv-encoder at 01c0a000 {
> > +	compatible = "allwinner,sun4i-a10-tv-encoder";
> > +	reg = <0x01c0a000 0x1000>;
> > +	clocks = <&ahb_gates 34>;
> > +
> > +	port {
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		tve0_in_tcon0: endpoint at 0 {
> > +			reg = <0>;
> 
> I would drop the reg where you only have 1 node for ports or endpoints.

Ok

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/441bf2b8/attachment-0001.sig>

From linux at arm.linux.org.uk  Wed Feb  3 11:59:06 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 3 Feb 2016 19:59:06 +0000
Subject: [PATCH 1/2] ARM: make virt_to_idmap() return unsigned long
In-Reply-To: <56B2201B.7020205@ti.com>
References: <E1aO8F2-00074N-E8@rmk-PC.arm.linux.org.uk>
 <56A84748.3040108@oracle.com>
 <20160201152015.GU10826@n2100.arm.linux.org.uk>
 <56AF8F54.7030805@ti.com> <56AF917F.9030505@oracle.com>
 <56B14546.4070808@oracle.com> <56B20B2E.7060408@ti.com>
 <56B2201B.7020205@ti.com>
Message-ID: <20160203195905.GC10826@n2100.arm.linux.org.uk>

On Wed, Feb 03, 2016 at 10:43:23AM -0500, Vitaly Andrianov wrote:
> >100%. I came up with absolutely similar fix.
> >
> >
> >Regarding, kexec:
> >- it seems can't be tested on ks2 out of the box, because there is unmet dependency in kconfig
> >  config KEXEC
> >         bool "Kexec system call (EXPERIMENTAL)"
> >-       depends on (!SMP || PM_SLEEP_SMP)
> >         depends on !CPU_V7M
> >         select KEXEC_CORE
> >         help
> >
> >- any way, i've hacked kernel as above;
> >- downloaded and built kexec-tools
> >git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.git
> >- tried to run it using different combination of parameters, but always
> >with below result:
> ># kexec -l /boot/zImage
> >kexec version: 15.12.22.16.38-g6503cb3
> >Could not find a free area of memory of 0x3b2ca0 bytes...
> >Cannot load /boot/zImage
> >
> >I'm doing something wrong, but don't know what yet :(
> >- these patches were not applied, I'd like to see kexec not working first
> >
> >
> I'm not sure about that particular issue, but when I worked on KS2 kexec I
> had to patch kexec-tools to support KS2 LPAE memory.

This was specifically for Vitaly to test, as he has patches to work
around most of the KS2 issues with kexec (although I have a KS2, I
don't have everything that's necessary to get a working kexec in
place.)

What I do want to know is whether this patch makes Vitaly's kexec
patch smaller, and most importantly, what's left to deal with - in
other words, I'd like to see the kernel patch for what's remaining.

Alternatively, if I can have both the kernel and userland patches
so I can get a working kexec setup here, that may be a better way
forward.

Either way, I think I'm going to push these patches out into
linux-next very soon, because I believe that they're the correct
approach to solving some of the issues found in Vitaly's original
patch, unless someone discovers that they're broken in some manner.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From Chris.Brandt at renesas.com  Wed Feb  3 12:00:50 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Wed, 3 Feb 2016 20:00:50 +0000
Subject: [PATCH v2 0/4] kallsyms: remove special handling for CONFIG_ARM
In-Reply-To: <1454526297-5269-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454526297-5269-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <HKXPR06MB056557F78EB9F04F271019C68AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>

On 3 Feb 2016, Ard Biesheuvel wrote:

> This series applies on top of today's -next, and addresses an issue
> with the new kallsyms code that is queued there, that enables base
> relative kallsyms tables for all architectures (except IA-64)
>
> Two issues have surfaced on ARM with the new kallsyms code:
> a) CONFIG_HAVE_TCM creates a virtual region that is too far away for the
>    relative kallsyms code to reach it;
> b) CONFIG_XIP_KERNEL=y kernel symbols are not filtered against PAGE_OFFSET,
>   as is the case for kernels that execute from RAM, resulting in symbols
>   that are out of range.
>
> Since the way kallsyms deals with XIP kernels on ARM leaves some room for
>  improvement regardless of the base relative changes, this series proposes
>  a fix that allows the special case to be removed from the kallsyms
>  handling entirely.
>
> Changes since v1:
> - new patch #4 (optional, RFC)
> - added Nico's ack to #1 - #3
> - use PROVIDE() for vector_fiq_offset since vector_fiq itself is not
>  always
>   defined
> - put __stubs_start/_end inside the section definition so that the
>  value of the
>   start symbol equals the start of the section after alignment
>  (fixes an issue
>   on XIP spotted by Chris)
> 
> Patch #1 moves the .stubs and .vectors section back into the kernel
> VMA, while preserving the guaranteed virtual offset of 4 KB. This
> results in all symbols that kallsyms sees to be in a reasonable interval.
> 
> Patch #2 removes the special case for CONFIG_ARM && !CONFIG_XIP_KERNEL
> in the invocation of scripts/kallsyms
> 
> Patch #3 removes the now unused --page-offset command line argument
> handling from scripts/kallsyms.c
> 
> Patch #4 is included as an RFC, it removes the magic constant 0x1000
> which is the offset between the start of the .vectors section and the
> start of the .stubs section.


For patches 1,2,3:

Tested with ARCH_R7S72100 with CONFIG_XIP_KERNEL=y


Acked-by: Chris Brandt <chris.brandt at renesas.com>




From linux at arm.linux.org.uk  Wed Feb  3 12:01:08 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 3 Feb 2016 20:01:08 +0000
Subject: [PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM
In-Reply-To: <CAKv+Gu8ZTHAqviveLMizRKPfeXwb6kcXi4cVQNYVYuPcVMgMeQ@mail.gmail.com>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <HKXPR06MB0565A2CFF95AD7C000F43E6A8ADF0@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu9VvskQ34w0niS+6AtF9hNcycfYDt_3Kp4T+WK8Vxf_dA@mail.gmail.com>
 <HKXPR06MB05656F902E0E1FBBDBD713DC8AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu8ZTHAqviveLMizRKPfeXwb6kcXi4cVQNYVYuPcVMgMeQ@mail.gmail.com>
Message-ID: <20160203200107.GD10826@n2100.arm.linux.org.uk>

On Wed, Feb 03, 2016 at 02:41:29PM +0100, Ard Biesheuvel wrote:
> > bf353edc T __stubs_start
> 
> This is a global symbol
> 
> > bf353edc T _etext
> > bf353ee0 t __stubs_start
> 
> This is a local symbol

Stop this madness.  This gets you an immediate NAK on the patch set.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From ard.biesheuvel at linaro.org  Wed Feb  3 12:02:30 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 3 Feb 2016 21:02:30 +0100
Subject: [PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM
In-Reply-To: <20160203200107.GD10826@n2100.arm.linux.org.uk>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <HKXPR06MB0565A2CFF95AD7C000F43E6A8ADF0@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu9VvskQ34w0niS+6AtF9hNcycfYDt_3Kp4T+WK8Vxf_dA@mail.gmail.com>
 <HKXPR06MB05656F902E0E1FBBDBD713DC8AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu8ZTHAqviveLMizRKPfeXwb6kcXi4cVQNYVYuPcVMgMeQ@mail.gmail.com>
 <20160203200107.GD10826@n2100.arm.linux.org.uk>
Message-ID: <CAKv+Gu_MyPvDnnQ0hScqW6XR77h0MD6LxEb_q2Z-mS0AQw3djA@mail.gmail.com>

On 3 February 2016 at 21:01, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Wed, Feb 03, 2016 at 02:41:29PM +0100, Ard Biesheuvel wrote:
>> > bf353edc T __stubs_start
>>
>> This is a global symbol
>>
>> > bf353edc T _etext
>> > bf353ee0 t __stubs_start
>>
>> This is a local symbol
>
> Stop this madness.  This gets you an immediate NAK on the patch set.
>

What madness? This does not change at all with my patches, these
duplicates already exist in the current code.


From linus.walleij at linaro.org  Wed Feb  3 12:14:15 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 3 Feb 2016 21:14:15 +0100
Subject: [PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM
In-Reply-To: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <CACRpkdZ+uDTM+LZPyvkZiFSzxUipP_6ArzoN_JAJbqVw6+=u7A@mail.gmail.com>

On Tue, Feb 2, 2016 at 2:19 PM, Ard Biesheuvel
<ard.biesheuvel at linaro.org> wrote:

> a) CONFIG_HAVE_TCM creates a virtual region that is too far away for the
>    relative kallsyms code to reach it;

We have discussed the TCM before in context of SRAM and other
embedded on-chip RAMs.

There was some consensus that the statically allocated area for TCM is
not really scaleable, especially not for multiplatform kernels, which will
try to compile the sum total of all platforms' code tagged for TCM into this
memory which is bound to overflow if people start to take advantage
of it. It would be better to have just the machine-relevant code loaded
into TCM at boot. People have also shown interest in deploying
SRAM/TCM applications from userspace (for hard processing
kernels etc).

The best would be to advance that work and thus get rid of the
static TCM linkage I think?

Yours,
Linus Walleij


From maxime.ripard at free-electrons.com  Wed Feb  3 12:18:34 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 3 Feb 2016 21:18:34 +0100
Subject: [PATCH v2 05/26] clk: sunxi: Add display and TCON0 clocks driver
In-Reply-To: <CAGb2v65=EVTQo8KFMECVR4=94i0rt0V1H07hWKyXShSZxGYKEQ@mail.gmail.com>
References: <1452785109-6172-1-git-send-email-maxime.ripard@free-electrons.com>
 <1452785109-6172-6-git-send-email-maxime.ripard@free-electrons.com>
 <CAGb2v65=EVTQo8KFMECVR4=94i0rt0V1H07hWKyXShSZxGYKEQ@mail.gmail.com>
Message-ID: <20160203201834.GC3327@lukather>

On Sat, Jan 16, 2016 at 11:29:41PM +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> On Thu, Jan 14, 2016 at 11:24 PM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > The A10 SoCs and its relatives has a special clock controller to drive the
> > display engines (both frontend and backend), that have a lot in common with
> > the clock to drive the first TCON channel.
> >
> > Add a driver to support both.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > ---
> >  Documentation/devicetree/bindings/clock/sunxi.txt |   2 +
> >  drivers/clk/sunxi/Makefile                        |   1 +
> >  drivers/clk/sunxi/clk-sun4i-display.c             | 241 ++++++++++++++++++++++
> >  3 files changed, 244 insertions(+)
> >  create mode 100644 drivers/clk/sunxi/clk-sun4i-display.c
> >
> > diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> > index 8a47b77abfca..5360554a7d3f 100644
> > --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> > +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> > @@ -55,6 +55,7 @@ Required properties:
> >         "allwinner,sun9i-a80-apb1-gates-clk" - for the APB1 gates on A80
> >         "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
> >         "allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
> > +       "allwinner,sun4i-a10-display-clk" - for the display clocks on the A10
> >         "allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
> >         "allwinner,sun4i-a10-mmc-clk" - for the MMC clock
> >         "allwinner,sun9i-a80-mmc-clk" - for mmc module clocks on A80
> > @@ -64,6 +65,7 @@ Required properties:
> >         "allwinner,sun8i-a23-mbus-clk" - for the MBUS clock on A23
> >         "allwinner,sun7i-a20-out-clk" - for the external output clocks
> >         "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
> > +       "allwinner,sun4i-a10-tcon-ch0-clk" - for the TCON channel 0 clock on the A10
> >         "allwinner,sun4i-a10-usb-clk" - for usb gates + resets on A10 / A20
> >         "allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13
> >         "allwinner,sun6i-a31-usb-clk" - for usb gates + resets on A31
> > diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> > index cb4c299214ce..a991cd8ca509 100644
> > --- a/drivers/clk/sunxi/Makefile
> > +++ b/drivers/clk/sunxi/Makefile
> > @@ -10,6 +10,7 @@ obj-y += clk-a10-pll2.o
> >  obj-y += clk-a20-gmac.o
> >  obj-y += clk-mod0.o
> >  obj-y += clk-simple-gates.o
> > +obj-y += clk-sun4i-display.o
> >  obj-y += clk-sun8i-mbus.o
> >  obj-y += clk-sun9i-core.o
> >  obj-y += clk-sun9i-mmc.o
> > diff --git a/drivers/clk/sunxi/clk-sun4i-display.c b/drivers/clk/sunxi/clk-sun4i-display.c
> > new file mode 100644
> > index 000000000000..9dc6894f0934
> > --- /dev/null
> > +++ b/drivers/clk/sunxi/clk-sun4i-display.c
> > @@ -0,0 +1,241 @@
> > +/*
> > + * Copyright 2015 Maxime Ripard
> > + *
> > + * Maxime Ripard <maxime.ripard at free-electrons.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/clk-provider.h>
> > +#include <linux/kernel.h>
> > +#include <linux/of_address.h>
> > +#include <linux/reset-controller.h>
> > +#include <linux/slab.h>
> > +#include <linux/spinlock.h>
> > +
> > +struct sun4i_a10_display_clk_data {
> > +       bool    has_div;
> > +       bool    has_rst;
> > +       u8      parents;
> > +
> > +       u8      offset_en;
> > +       u8      offset_div;
> > +       u8      offset_mux;
> > +       u8      offset_rst;
> > +
> > +       u8      width_div;
> > +       u8      width_mux;
> > +};
> > +
> > +struct reset_data {
> > +       void __iomem                    *reg;
> > +       spinlock_t                      *lock;
> > +       struct reset_controller_dev     rcdev;
> > +       u8                              offset;
> > +};
> > +
> > +static DEFINE_SPINLOCK(sun4i_a10_display_lock);
> > +
> > +static inline struct reset_data *rcdev_to_reset_data(struct reset_controller_dev *rcdev)
> > +{
> > +       return container_of(rcdev, struct reset_data, rcdev);
> > +};
> > +
> > +static int sun4i_a10_display_assert(struct reset_controller_dev *rcdev,
> > +                                   unsigned long id)
> > +{
> > +       struct reset_data *data = rcdev_to_reset_data(rcdev);
> > +       unsigned long flags;
> > +       u32 reg;
> > +
> > +       spin_lock_irqsave(data->lock, flags);
> > +
> > +       reg = readl(data->reg);
> > +       writel(reg & ~BIT(data->offset), data->reg);
> > +
> > +       spin_unlock_irqrestore(data->lock, flags);
> > +
> > +       return 0;
> > +}
> > +
> > +static int sun4i_a10_display_deassert(struct reset_controller_dev *rcdev,
> > +                                     unsigned long id)
> > +{
> > +       struct reset_data *data = rcdev_to_reset_data(rcdev);
> > +       unsigned long flags;
> > +       u32 reg;
> > +
> > +       spin_lock_irqsave(data->lock, flags);
> > +
> > +       reg = readl(data->reg);
> > +       writel(reg | BIT(data->offset), data->reg);
> > +
> > +       spin_unlock_irqrestore(data->lock, flags);
> > +
> > +       return 0;
> > +}
> > +
> > +static int sun4i_a10_display_status(struct reset_controller_dev *rcdev,
> > +                                   unsigned long id)
> > +{
> > +       struct reset_data *data = rcdev_to_reset_data(rcdev);
> > +
> > +       return !(readl(data->reg) & BIT(data->offset));
> > +}
> > +
> > +static const struct reset_control_ops sun4i_a10_display_reset_ops = {
> > +       .assert         = sun4i_a10_display_assert,
> > +       .deassert       = sun4i_a10_display_deassert,
> > +       .status         = sun4i_a10_display_status,
> > +};
> > +
> > +static int sun4i_a10_display_reset_xlate(struct reset_controller_dev *rcdev,
> > +                                        const struct of_phandle_args *spec)
> > +{
> > +       /* We only have a single reset signal */
> > +       return 0;
> > +}
> > +
> > +static void __init sun4i_a10_display_init(struct device_node *node,
> > +                                         struct sun4i_a10_display_clk_data *data)
> > +{
> > +       const char *parents[data->parents];
> > +       const char *clk_name = node->name;
> > +       struct reset_data *reset_data;
> > +       struct clk_divider *div = NULL;
> > +       struct clk_gate *gate;
> > +       struct clk_mux *mux;
> > +       void __iomem *reg;
> > +       struct clk *clk;
> > +       int i;
> > +
> > +       of_property_read_string(node, "clock-output-names", &clk_name);
> > +
> > +       reg = of_io_request_and_map(node, 0, of_node_full_name(node));
> > +       if (IS_ERR(reg)) {
> > +               pr_err("%s: Could not map the clock registers\n", clk_name);
> > +               return;
> > +       }
> > +
> > +       of_clk_parent_fill(node, parents, data->parents);
> 
> What if someone uses an incorrect DT that has less parents described?

Then here be dragons ? :)

I'll fix that.

> > +
> > +       mux = kzalloc(sizeof(*mux), GFP_KERNEL);
> > +       if (!mux)
> > +               return;
> > +
> > +       mux->reg = reg;
> > +       mux->shift = data->offset_mux;
> > +       mux->mask = (1 << data->width_mux) - 1;
> > +       mux->lock = &sun4i_a10_display_lock;
> > +
> > +       gate = kzalloc(sizeof(*gate), GFP_KERNEL);
> > +       if (!gate)
> > +               goto free_mux;
> > +
> > +       gate->reg = reg;
> > +       gate->bit_idx = data->offset_en;
> > +       gate->lock = &sun4i_a10_display_lock;
> > +
> > +       if (data->has_div) {
> > +               div = kzalloc(sizeof(*div), GFP_KERNEL);
> > +               if (!div)
> > +                       goto free_gate;
> > +
> > +               div->reg = reg;
> > +               div->shift = data->offset_div;
> > +               div->width = data->width_div;
> > +               div->lock = &sun4i_a10_display_lock;
> > +       }
> > +
> > +       clk = clk_register_composite(NULL, clk_name,
> > +                                    parents, data->parents,
> > +                                    &mux->hw, &clk_mux_ops,
> > +                                    data->has_div ? &div->hw : NULL,
> > +                                    data->has_div ? &clk_divider_ops : NULL,
> > +                                    &gate->hw, &clk_gate_ops,
> > +                                    0);
> > +       if (IS_ERR(clk)) {
> > +               pr_err("%s: Couldn't register the clock\n", clk_name);
> > +               goto free_div;
> > +       }
> > +
> > +       of_clk_add_provider(node, of_clk_src_simple_get, clk);
> 
> Check for errors?

Yep.

> > +
> > +       if (!data->has_rst)
> > +               return;
> > +
> > +       reset_data = kzalloc(sizeof(*reset_data), GFP_KERNEL);
> > +       if (!reset_data)
> > +               goto free_clk;
> > +
> > +       reset_data->reg = reg;
> > +       reset_data->offset = data->offset_rst;
> > +       reset_data->lock = &sun4i_a10_display_lock;
> > +       reset_data->rcdev.nr_resets = 1;
> > +       reset_data->rcdev.ops = &sun4i_a10_display_reset_ops;
> > +       reset_data->rcdev.of_node = node;
> > +       reset_data->rcdev.of_reset_n_cells = 0;
> > +       reset_data->rcdev.of_xlate = &sun4i_a10_display_reset_xlate;
> > +
> > +       if (reset_controller_register(&reset_data->rcdev)) {
> > +               pr_err("%s: Couldn't register the reset controller\n",
> > +                      clk_name);
> > +               goto free_reset;
> > +       }
> > +
> > +       return;
> > +
> > +free_reset:
> > +       kfree(reset_data);
> > +free_clk:
> > +       clk_unregister(clk);
> > +free_div:
> > +       if (data->has_div)
> > +               kfree(div);
> > +free_gate:
> > +       kfree(gate);
> > +free_mux:
> > +       kfree(mux);
> 
> Cleanup after of_io_request_and_map()?

Hmm, indeed...

> 
> > +}
> > +
> > +static struct sun4i_a10_display_clk_data sun4i_a10_tcon_ch0_data = {
> > +       .has_rst        = true,
> > +       .parents        = 4,
> > +       .offset_en      = 31,
> > +       .offset_rst     = 29,
> 
> My datasheets (A10 v1.5, A20 v1.4), say bit 30 for LCD0 ch0 reset.
> 
> A13 and R8 manuals do not list this clock, but A10s does, which has
> bit 30 for LCD reset and bit 29 for TV encoder reset.
> 
> I suggest changing has_rst to int, and for sun5i variant, have
> has_rst = 2, reset_cells = 1, for 2 separate reset controls.
> The tcon and tv encoder bits of the DTSI should be updated as
> well.
> 
> I assume your tests work because U-boot already de-asserted the
> resets (both if you're using composite output).

You're right, I'll fix it as you suggested.

> > +       .offset_mux     = 24,
> > +       .width_mux      = 2,
> > +};
> > +
> > +static void __init sun4i_a10_tcon_ch0_setup(struct device_node *node)
> > +{
> > +       sun4i_a10_display_init(node, &sun4i_a10_tcon_ch0_data);
> > +}
> > +CLK_OF_DECLARE(sun4i_a10_tcon_ch0, "allwinner,sun4i-a10-tcon-ch0-clk",
> > +              sun4i_a10_tcon_ch0_setup);
> > +
> > +static struct sun4i_a10_display_clk_data sun4i_a10_display_data = {
> > +       .has_div        = true,
> 
> Missing .has_rst = true.

Indeed

> > +       .parents        = 3,
> > +       .offset_en      = 31,
> > +       .offset_rst     = 30,
> > +       .offset_mux     = 24,
> > +       .offset_div     = 0,
> 
> This is already implied.

Because the structure would already by initialised to 0?

Yeah, true, but I wanted to make that explicit that the div offset is
actually 0, and not something that got forgotten.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/f5f4063e/attachment-0001.sig>

From robh at kernel.org  Wed Feb  3 12:19:31 2016
From: robh at kernel.org (Rob Herring)
Date: Wed, 3 Feb 2016 14:19:31 -0600
Subject: [PATCH v2 17/26] drm: sun4i: Add DT bindings documentation
In-Reply-To: <20160203195919.GB3327@lukather>
References: <1452785109-6172-1-git-send-email-maxime.ripard@free-electrons.com>
 <1452785109-6172-18-git-send-email-maxime.ripard@free-electrons.com>
 <20160115031515.GA19797@rob-hp-laptop> <20160203195919.GB3327@lukather>
Message-ID: <CAL_JsqLLvK0L+PaOxesgr9u_3hb6EWbb9w2-yw80D8sUqiohTA@mail.gmail.com>

On Wed, Feb 3, 2016 at 1:59 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> Hi Rob,
>
> On Thu, Jan 14, 2016 at 09:15:15PM -0600, Rob Herring wrote:
>> On Thu, Jan 14, 2016 at 04:25:00PM +0100, Maxime Ripard wrote:
>> > The display pipeline of the Allwinner A10 is involving several loosely
>> > coupled components.
>> >
>> > Add a documentation for the bindings.
>> >
>> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
>> > ---
>> >  .../bindings/display/sunxi/sun4i-drm.txt           | 228 +++++++++++++++++++++

[...]

>> > +Required properties:
>> > +  - compatible: value must be one of:
>> > +    * allwinner,sun5i-a13-display-engine
>> > +  - allwinner,pipelines: list of phandle to the entry points of the
>> > +    pipelines (either to the frontend or backend)
>> > +
>> > +Example:
>> > +
>> > +panel: panel {
>> > +   compatible = "olimex,lcd-olinuxino-43-ts";
>>
>> This should either be a child of what it is attached to or use of-graph.
>
> You had a similar discussion with Thierry last time I sent it, and it
> seemed to settle on keeping that property:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/382115.html
>
> Has that changed?

No, I still disagree. We already have 2 ways to describe panels: as a
child node of its controller or with of-graph. We don't need a 3rd way
even if it is simple. The problem with of-graph today is too much of
the parsing is left to the individual drivers. We need to fix that and
make it be handled by common code.

Rob


From robh at kernel.org  Wed Feb  3 12:23:00 2016
From: robh at kernel.org (Rob Herring)
Date: Wed, 3 Feb 2016 14:23:00 -0600
Subject: [PATCH v2 08/12] devicetree: bindings: add DT binding for the
 Marvell Armada 3700 SoC family
In-Reply-To: <1454524889-9207-9-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
 <1454524889-9207-9-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <CAL_JsqJ8tY-XNo7LcP82LB5ywK_41fQzDqcyFOca2MXhu+Gw2A@mail.gmail.com>

On Wed, Feb 3, 2016 at 12:41 PM, Gregory CLEMENT
<gregory.clement at free-electrons.com> wrote:
> The Marvell Armada 3700 is a family of ARMv8 CA53 SoCs. This commit
> introduces the Device Tree binding that documents the top-level
> compatible strings for Armada 3700 based platforms.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  .../devicetree/bindings/arm/marvell/armada-37xx.txt      | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
> new file mode 100644
> index 000000000000..17e90e8b5f76
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
> @@ -0,0 +1,16 @@
> +Marvell Armada 37xx Platforms Device Tree Bindings
> +--------------------------------------------------
> +
> +Boards using a SoC of the Marvell Armada 37xx family must carry the
> +following root node property:
> +
> + - compatible: must contain "marvell,armada3710"
> +
> +In addition, boards using the Marvell Armada 3720 SoC shall have the
> +following property before the previous one:
> +
> + - compatible: must contain "marvell,armada3720"
> +
> +Example:
> +
> +compatible = "marvell,armada-3720-db", "marvell,armada3710", "marvell,armada3720";

The order is wrong?


From nicolas.pitre at linaro.org  Wed Feb  3 12:23:52 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 3 Feb 2016 15:23:52 -0500 (EST)
Subject: [PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM
In-Reply-To: <CAKv+Gu_MyPvDnnQ0hScqW6XR77h0MD6LxEb_q2Z-mS0AQw3djA@mail.gmail.com>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <HKXPR06MB0565A2CFF95AD7C000F43E6A8ADF0@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu9VvskQ34w0niS+6AtF9hNcycfYDt_3Kp4T+WK8Vxf_dA@mail.gmail.com>
 <HKXPR06MB05656F902E0E1FBBDBD713DC8AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu8ZTHAqviveLMizRKPfeXwb6kcXi4cVQNYVYuPcVMgMeQ@mail.gmail.com>
 <20160203200107.GD10826@n2100.arm.linux.org.uk>
 <CAKv+Gu_MyPvDnnQ0hScqW6XR77h0MD6LxEb_q2Z-mS0AQw3djA@mail.gmail.com>
Message-ID: <alpine.LFD.2.20.1602031522090.17825@knanqh.ubzr>

On Wed, 3 Feb 2016, Ard Biesheuvel wrote:

> On 3 February 2016 at 21:01, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Wed, Feb 03, 2016 at 02:41:29PM +0100, Ard Biesheuvel wrote:
> >> > bf353edc T __stubs_start
> >>
> >> This is a global symbol
> >>
> >> > bf353edc T _etext
> >> > bf353ee0 t __stubs_start
> >>
> >> This is a local symbol
> >
> > Stop this madness.  This gets you an immediate NAK on the patch set.
> >
> 
> What madness? This does not change at all with my patches, these
> duplicates already exist in the current code.

That doesn't make it any better, and was cause for issue as Chris 
demonstrated.  Can we get rid of that duplication please?


Nicolas


From maxime.ripard at free-electrons.com  Wed Feb  3 12:27:58 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 3 Feb 2016 21:27:58 +0100
Subject: [PATCH v2 06/26] clk: sunxi: Add PLL3 clock
In-Reply-To: <CAGb2v64pj5Ga4-QaF7RpExUSyYntyMU2dQ87TPsm5WbNeAXMOQ@mail.gmail.com>
References: <1452785109-6172-1-git-send-email-maxime.ripard@free-electrons.com>
 <1452785109-6172-7-git-send-email-maxime.ripard@free-electrons.com>
 <CAGb2v64pj5Ga4-QaF7RpExUSyYntyMU2dQ87TPsm5WbNeAXMOQ@mail.gmail.com>
Message-ID: <20160203202758.GD3327@lukather>

On Sun, Jan 17, 2016 at 12:05:06AM +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> On Thu, Jan 14, 2016 at 11:24 PM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > The A10 SoCs and relatives have a PLL controller to drive the PLL3 and
> > PLL7, clocked from a 3MHz oscillator, that drives the display related
> > clocks (GPU, display engine, TCON, etc.)
> >
> > Add a driver for it.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > ---
> >  Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
> >  drivers/clk/sunxi/Makefile                        |  1 +
> >  drivers/clk/sunxi/clk-sun4i-pll3.c                | 90 +++++++++++++++++++++++
> >  3 files changed, 92 insertions(+)
> >  create mode 100644 drivers/clk/sunxi/clk-sun4i-pll3.c
> >
> > diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> > index 5360554a7d3f..bb9fb78dcff8 100644
> > --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> > +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> > @@ -10,6 +10,7 @@ Required properties:
> >         "allwinner,sun4i-a10-pll1-clk" - for the main PLL clock and PLL4
> >         "allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
> >         "allwinner,sun8i-a23-pll1-clk" - for the main PLL clock on A23
> > +       "allwinner,sun4i-a10-pll3-clk" - for the video PLL clock on A10
> >         "allwinner,sun9i-a80-pll4-clk" - for the peripheral PLLs on A80
> >         "allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock
> >         "allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock
> > diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> > index a991cd8ca509..40c32ffd912c 100644
> > --- a/drivers/clk/sunxi/Makefile
> > +++ b/drivers/clk/sunxi/Makefile
> > @@ -11,6 +11,7 @@ obj-y += clk-a20-gmac.o
> >  obj-y += clk-mod0.o
> >  obj-y += clk-simple-gates.o
> >  obj-y += clk-sun4i-display.o
> > +obj-y += clk-sun4i-pll3.o
> >  obj-y += clk-sun8i-mbus.o
> >  obj-y += clk-sun9i-core.o
> >  obj-y += clk-sun9i-mmc.o
> > diff --git a/drivers/clk/sunxi/clk-sun4i-pll3.c b/drivers/clk/sunxi/clk-sun4i-pll3.c
> > new file mode 100644
> > index 000000000000..6c9c2210b6b2
> > --- /dev/null
> > +++ b/drivers/clk/sunxi/clk-sun4i-pll3.c
> > @@ -0,0 +1,90 @@
> > +/*
> > + * Copyright 2015 Maxime Ripard
> > + *
> > + * Maxime Ripard <maxime.ripard at free-electrons.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/clk-provider.h>
> > +#include <linux/of.h>
> > +#include <linux/of_address.h>
> > +#include <linux/slab.h>
> > +#include <linux/spinlock.h>
> > +
> > +#define SUN4I_A10_PLL3_GATE_BIT        31
> > +#define SUN4I_A10_PLL3_DIV_WIDTH       7
> > +#define SUN4I_A10_PLL3_DIV_SHIFT       0
> > +
> > +static DEFINE_SPINLOCK(sun4i_a10_pll3_lock);
> > +
> > +static void __init sun4i_a10_pll3_setup(struct device_node *node)
> > +{
> > +       const char *clk_name = node->name, *parent;
> > +       struct clk_multiplier *mult;
> > +       struct clk_gate *gate;
> > +       void __iomem *reg;
> > +       struct clk *clk;
> > +       int ret;
> > +
> > +       of_property_read_string(node, "clock-output-names", &clk_name);
> > +       parent = of_clk_get_parent_name(node, 0);
> > +
> > +       reg = of_io_request_and_map(node, 0, of_node_full_name(node));
> > +       if (IS_ERR(reg)) {
> > +               pr_err("%s: Could not map the clock registers\n", clk_name);
> > +               return;
> > +       }
> > +
> > +       gate = kzalloc(sizeof(*gate), GFP_KERNEL);
> > +       if (!gate)
> > +               return;
> > +
> > +       gate->reg = reg;
> > +       gate->bit_idx = SUN4I_A10_PLL3_GATE_BIT;
> > +       gate->lock = &sun4i_a10_pll3_lock;
> > +
> > +       mult = kzalloc(sizeof(*mult), GFP_KERNEL);
> > +       if (!mult)
> > +               goto err_free_gate;
> > +
> > +       mult->reg = reg;
> > +       mult->shift = SUN4I_A10_PLL3_DIV_SHIFT;
> > +       mult->width = SUN4I_A10_PLL3_DIV_WIDTH;
> > +       mult->lock = &sun4i_a10_pll3_lock;
> > +
> > +       clk = clk_register_composite(NULL, clk_name,
> > +                                    &parent, 1,
> > +                                    NULL, NULL,
> > +                                    &mult->hw, &clk_multiplier_ops,
> > +                                    &gate->hw, &clk_gate_ops,
> > +                                    0);
> > +       if (IS_ERR(clk)) {
> > +               pr_err("%s: Couldn't register the clock\n", clk_name);
> > +               goto err_free_mult;
> > +       }
> > +
> > +       ret = of_clk_add_provider(node, of_clk_src_simple_get, clk);
> > +       if (WARN_ON(ret))
> 
> Any particular reason for WARN_ON instead of pr_err like above?

I guess not, I'll change that.

> 
> > +               goto err_clk_unregister;
> > +
> > +       return;
> > +
> > +err_clk_unregister:
> > +       clk_unregister_composite(clk);
> > +err_free_mult:
> > +       kfree(mult);
> > +err_free_gate:
> > +       kfree(gate);
> 
> Clean up after of_io_request_and_map(), otherwise

Ack

> 
> Acked-by: Chen-Yu Tsai <wens at csie.org>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/c7f23515/attachment.sig>

From maxime.ripard at free-electrons.com  Wed Feb  3 12:29:26 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 3 Feb 2016 21:29:26 +0100
Subject: [PATCH v2 07/26] clk: sunxi: Add TCON channel1 clock
In-Reply-To: <CAGb2v65_jsmiQ6DNCznFuQCcWxqs1N2fYJ-8OiUJ_BR+jf314w@mail.gmail.com>
References: <1452785109-6172-1-git-send-email-maxime.ripard@free-electrons.com>
 <1452785109-6172-8-git-send-email-maxime.ripard@free-electrons.com>
 <CAGb2v65_jsmiQ6DNCznFuQCcWxqs1N2fYJ-8OiUJ_BR+jf314w@mail.gmail.com>
Message-ID: <20160203202926.GE3327@lukather>

Hi,

On Sun, Jan 17, 2016 at 12:36:20AM +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> On Thu, Jan 14, 2016 at 11:24 PM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > The TCON is a controller generating the timings to output videos signals,
> > acting like both a CRTC and an encoder.
> >
> > It has two channels depending on the output, each channel being driven by
> > its own clock (and own clock controller).
> >
> > Add a driver for the channel 1 clock.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > ---
> >  Documentation/devicetree/bindings/clock/sunxi.txt |   1 +
> >  drivers/clk/sunxi/Makefile                        |   1 +
> >  drivers/clk/sunxi/clk-sun4i-tcon-ch1.c            | 154 ++++++++++++++++++++++
> >  3 files changed, 156 insertions(+)
> >  create mode 100644 drivers/clk/sunxi/clk-sun4i-tcon-ch1.c
> >
> > diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> > index bb9fb78dcff8..fe34fc56e803 100644
> > --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> > +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> > @@ -67,6 +67,7 @@ Required properties:
> >         "allwinner,sun7i-a20-out-clk" - for the external output clocks
> >         "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
> >         "allwinner,sun4i-a10-tcon-ch0-clk" - for the TCON channel 0 clock on the A10
> > +       "allwinner,sun4i-a10-tcon-ch1-clk" - for the TCON channel 1 clock on the A10
> >         "allwinner,sun4i-a10-usb-clk" - for usb gates + resets on A10 / A20
> >         "allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13
> >         "allwinner,sun6i-a31-usb-clk" - for usb gates + resets on A31
> > diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> > index 40c32ffd912c..0a20873cd103 100644
> > --- a/drivers/clk/sunxi/Makefile
> > +++ b/drivers/clk/sunxi/Makefile
> > @@ -12,6 +12,7 @@ obj-y += clk-mod0.o
> >  obj-y += clk-simple-gates.o
> >  obj-y += clk-sun4i-display.o
> >  obj-y += clk-sun4i-pll3.o
> > +obj-y += clk-sun4i-tcon-ch1.o
> >  obj-y += clk-sun8i-mbus.o
> >  obj-y += clk-sun9i-core.o
> >  obj-y += clk-sun9i-mmc.o
> > diff --git a/drivers/clk/sunxi/clk-sun4i-tcon-ch1.c b/drivers/clk/sunxi/clk-sun4i-tcon-ch1.c
> > new file mode 100644
> > index 000000000000..51ddc38821f7
> > --- /dev/null
> > +++ b/drivers/clk/sunxi/clk-sun4i-tcon-ch1.c
> > @@ -0,0 +1,154 @@
> > +/*
> > + * Copyright 2015 Maxime Ripard
> > + *
> > + * Maxime Ripard <maxime.ripard at free-electrons.com>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/clk-provider.h>
> > +#include <linux/of.h>
> > +#include <linux/of_address.h>
> > +#include <linux/slab.h>
> > +#include <linux/spinlock.h>
> > +
> > +#define SUN4I_TCON_CH1_SCLK_NAME_LEN   32
> > +
> > +#define SUN4I_A10_TCON_CH1_SCLK2_PARENTS       4
> > +
> > +#define SUN4I_A10_TCON_CH1_SCLK2_GATE_BIT      31
> > +#define SUN4I_A10_TCON_CH1_SCLK2_MUX_MASK      3
> > +#define SUN4I_A10_TCON_CH1_SCLK2_MUX_SHIFT     24
> > +#define SUN4I_A10_TCON_CH1_SCLK2_DIV_WIDTH     4
> > +#define SUN4I_A10_TCON_CH1_SCLK2_DIV_SHIFT     0
> > +
> > +#define SUN4I_A10_TCON_CH1_SCLK1_GATE_BIT      15
> > +#define SUN4I_A10_TCON_CH1_SCLK1_DIV_WIDTH     1
> > +#define SUN4I_A10_TCON_CH1_SCLK1_DIV_SHIFT     11
> > +
> > +static DEFINE_SPINLOCK(sun4i_a10_tcon_ch1_lock);
> > +
> > +static void __init sun4i_a10_tcon_ch1_setup(struct device_node *node)
> > +{
> > +       const char *sclk2_parents[SUN4I_A10_TCON_CH1_SCLK2_PARENTS];
> > +       const char *sclk1_name = node->name;
> > +       const char *sclk2_name;
> > +       struct clk_divider *sclk1_div, *sclk2_div;
> > +       struct clk_gate *sclk1_gate, *sclk2_gate;
> > +       struct clk_mux *sclk2_mux;
> > +       struct clk *sclk1, *sclk2;
> > +       void __iomem *reg;
> > +       int i, ret;
> > +
> > +       of_property_read_string(node, "clock-output-names",
> > +                               &sclk1_name);
> > +
> > +       sclk2_name = kasprintf(GFP_KERNEL, "%s2", sclk1_name);
> > +       if (!sclk2_name)
> > +               return;
> > +
> > +       reg = of_io_request_and_map(node, 0, of_node_full_name(node));
> > +       if (IS_ERR(reg)) {
> > +               pr_err("%s: Could not map the clock registers\n", sclk2_name);
> > +               return;
> > +       }
> > +
> > +       for (i = 0; i < SUN4I_A10_TCON_CH1_SCLK2_PARENTS; i++)
> > +               sclk2_parents[i] = of_clk_get_parent_name(node, i);
> 
> of_clk_parent_fill?

Indeed

> 
> > +
> > +       sclk2_mux = kzalloc(sizeof(*sclk2_mux), GFP_KERNEL);
> > +       if (!sclk2_mux)
> > +               return;
> > +
> > +       sclk2_mux->reg = reg;
> > +       sclk2_mux->shift = SUN4I_A10_TCON_CH1_SCLK2_MUX_SHIFT;
> > +       sclk2_mux->mask = SUN4I_A10_TCON_CH1_SCLK2_MUX_MASK;
> > +       sclk2_mux->lock = &sun4i_a10_tcon_ch1_lock;
> > +
> > +       sclk2_gate = kzalloc(sizeof(*sclk2_gate), GFP_KERNEL);
> > +       if (!sclk2_gate)
> > +               goto free_sclk2_mux;
> > +
> > +       sclk2_gate->reg = reg;
> > +       sclk2_gate->bit_idx = SUN4I_A10_TCON_CH1_SCLK2_GATE_BIT;
> > +       sclk2_gate->lock = &sun4i_a10_tcon_ch1_lock;
> > +
> > +       sclk2_div = kzalloc(sizeof(*sclk2_div), GFP_KERNEL);
> > +       if (!sclk2_div)
> > +               goto free_sclk2_gate;
> > +
> > +       sclk2_div->reg = reg;
> > +       sclk2_div->shift = SUN4I_A10_TCON_CH1_SCLK2_DIV_SHIFT;
> > +       sclk2_div->width = SUN4I_A10_TCON_CH1_SCLK2_DIV_WIDTH;
> > +       sclk2_div->lock = &sun4i_a10_tcon_ch1_lock;
> > +
> > +       sclk2 = clk_register_composite(NULL, sclk2_name, sclk2_parents,
> > +                                      SUN4I_A10_TCON_CH1_SCLK2_PARENTS,
> > +                                      &sclk2_mux->hw, &clk_mux_ops,                                   &
> 
> > +                                      sclk2_div->hw, &clk_divider_ops,
> 
> Placement of the "&" is very weird.

Hmm, right. I don't know what happened here, but it's obviously wrong :)

> 
> > +                                      &sclk2_gate->hw, &clk_gate_ops,
> > +                                      0);
> > +       if (IS_ERR(sclk2)) {
> > +               pr_err("%s: Couldn't register the clock\n", sclk2_name);
> > +               goto free_sclk2_div;
> > +       }
> > +
> > +       sclk1_div = kzalloc(sizeof(*sclk1_div), GFP_KERNEL);
> > +       if (!sclk1_div)
> > +               goto free_sclk2;
> > +
> > +       sclk1_div->reg = reg;
> > +       sclk1_div->shift = SUN4I_A10_TCON_CH1_SCLK1_DIV_SHIFT;
> > +       sclk1_div->width = SUN4I_A10_TCON_CH1_SCLK1_DIV_WIDTH;
> > +       sclk1_div->lock = &sun4i_a10_tcon_ch1_lock;
> > +
> > +       sclk1_gate = kzalloc(sizeof(*sclk1_gate), GFP_KERNEL);
> > +       if (!sclk1_gate)
> > +               goto free_sclk1_mux;
> > +
> > +       sclk1_gate->reg = reg;
> > +       sclk1_gate->bit_idx = SUN4I_A10_TCON_CH1_SCLK1_GATE_BIT;
> > +       sclk1_gate->lock = &sun4i_a10_tcon_ch1_lock;
> > +
> > +       sclk1 = clk_register_composite(NULL, sclk1_name, &sclk2_name, 1,
> > +                                      NULL, NULL,
> > +                                      &sclk1_div->hw, &clk_divider_ops,
> > +                                      &sclk1_gate->hw, &clk_gate_ops,
> > +                                      0);
> > +       if (IS_ERR(sclk1)) {
> > +               pr_err("%s: Couldn't register the clock\n", sclk1_name);
> > +               goto free_sclk1_gate;
> > +       }
> > +
> > +       ret = of_clk_add_provider(node, of_clk_src_simple_get, sclk1);
> > +       if (WARN_ON(ret))
> > +               goto free_sclk1;
> > +
> > +       return;
> > +
> > +free_sclk1:
> > +       clk_unregister_composite(sclk1);
> > +free_sclk1_gate:
> > +       kfree(sclk1_gate);
> > +free_sclk1_mux:
> > +       kfree(sclk1_div);
> > +free_sclk2:
> > +       clk_unregister(sclk2);
> > +free_sclk2_div:
> > +       kfree(sclk2_div);
> > +free_sclk2_gate:
> > +       kfree(sclk2_gate);
> > +free_sclk2_mux:
> > +       kfree(sclk2_mux);
> 
> Cleanup after of_io_request_and_map?

Indeed.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/a23789f0/attachment-0001.sig>

From ard.biesheuvel at linaro.org  Wed Feb  3 12:30:35 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 3 Feb 2016 21:30:35 +0100
Subject: [PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM
In-Reply-To: <alpine.LFD.2.20.1602031522090.17825@knanqh.ubzr>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <HKXPR06MB0565A2CFF95AD7C000F43E6A8ADF0@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu9VvskQ34w0niS+6AtF9hNcycfYDt_3Kp4T+WK8Vxf_dA@mail.gmail.com>
 <HKXPR06MB05656F902E0E1FBBDBD713DC8AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu8ZTHAqviveLMizRKPfeXwb6kcXi4cVQNYVYuPcVMgMeQ@mail.gmail.com>
 <20160203200107.GD10826@n2100.arm.linux.org.uk>
 <CAKv+Gu_MyPvDnnQ0hScqW6XR77h0MD6LxEb_q2Z-mS0AQw3djA@mail.gmail.com>
 <alpine.LFD.2.20.1602031522090.17825@knanqh.ubzr>
Message-ID: <CAKv+Gu_50f+yqs20a6j_QyCg3NcSfe5cD00fWXebLXBFhV_eGg@mail.gmail.com>

On 3 February 2016 at 21:23, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> On Wed, 3 Feb 2016, Ard Biesheuvel wrote:
>
>> On 3 February 2016 at 21:01, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>> > On Wed, Feb 03, 2016 at 02:41:29PM +0100, Ard Biesheuvel wrote:
>> >> > bf353edc T __stubs_start
>> >>
>> >> This is a global symbol
>> >>
>> >> > bf353edc T _etext
>> >> > bf353ee0 t __stubs_start
>> >>
>> >> This is a local symbol
>> >
>> > Stop this madness.  This gets you an immediate NAK on the patch set.
>> >
>>
>> What madness? This does not change at all with my patches, these
>> duplicates already exist in the current code.
>
> That doesn't make it any better, and was cause for issue as Chris
> demonstrated.  Can we get rid of that duplication please?
>

4/4 in my v2 removes the redundant symbols.


From maxime.ripard at free-electrons.com  Wed Feb  3 12:31:20 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 3 Feb 2016 21:31:20 +0100
Subject: [PATCH v2 10/26] ARM: sun5i: a13: Add display and TCON clocks
In-Reply-To: <CAGb2v67fqMUQsG-+zVxfgE3UzY7uyomBkwxgNHeXbqA1pwM8pA@mail.gmail.com>
References: <1452785109-6172-1-git-send-email-maxime.ripard@free-electrons.com>
 <1452785109-6172-11-git-send-email-maxime.ripard@free-electrons.com>
 <CAGb2v67fqMUQsG-+zVxfgE3UzY7uyomBkwxgNHeXbqA1pwM8pA@mail.gmail.com>
Message-ID: <20160203203120.GF3327@lukather>

Hi,

On Sun, Jan 17, 2016 at 01:06:07AM +0800, Chen-Yu Tsai wrote:
> > +                       compatible = "allwinner,sun4i-a10-tcon-ch0-clk";
> > +                       reg = <0x01c20118 0x4>;
> > +                       clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> > +                       clock-output-names = "tcon-ch0-sclk";
> > +               };
> > +
> > +               tcon_ch1_clk: clk at 01c2012c {
> > +                       #clock-cells = <0>;
> > +                       compatible = "allwinner,sun4i-a10-tcon-ch1-clk";
> > +                       reg = <0x01c2012c 0x4>;
> > +                       clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
> > +                       clock-output-names = "tcon-ch1-sclk";
> > +               };
> 
> I suggest moving these to sun5i.dtsi, as they are shared amongst them.

Eventually, yes, but I don't have an a10s board handy, and I couldn't
test the clocks that needs to be taken by simplefb.

Once properly tested, they can definitely be moved to sun5i.dtsi.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/73dab241/attachment.sig>

From maxime.ripard at free-electrons.com  Wed Feb  3 12:36:16 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 3 Feb 2016 21:36:16 +0100
Subject: [PATCH v2 11/26] ARM: sun5i: Add DRAM gates
In-Reply-To: <CAGb2v65gCieH2-WS+1WeBNCVqRyw8fOxODdSC5xeKf-hkfgs6A@mail.gmail.com>
References: <1452785109-6172-1-git-send-email-maxime.ripard@free-electrons.com>
 <1452785109-6172-12-git-send-email-maxime.ripard@free-electrons.com>
 <CAGb2v65gCieH2-WS+1WeBNCVqRyw8fOxODdSC5xeKf-hkfgs6A@mail.gmail.com>
Message-ID: <20160203203616.GG3327@lukather>

On Sun, Jan 17, 2016 at 01:10:02AM +0800, Chen-Yu Tsai wrote:
> On Thu, Jan 14, 2016 at 11:24 PM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > The DRAM gates control whether the image / display devices on the SoC have
> > access to the DRAM clock or not.
> >
> > Enable it.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > ---
> >  arch/arm/boot/dts/sun5i-a10s.dtsi |  7 ++++---
> >  arch/arm/boot/dts/sun5i-a13.dtsi  |  2 +-
> >  arch/arm/boot/dts/sun5i-r8.dtsi   |  2 +-
> >  arch/arm/boot/dts/sun5i.dtsi      | 19 +++++++++++++++++++
> >  4 files changed, 25 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
> > index bddd0de88af6..52d2c79cb37b 100644
> > --- a/arch/arm/boot/dts/sun5i-a10s.dtsi
> > +++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
> > @@ -66,7 +66,7 @@
> >                                      "simple-framebuffer";
> >                         allwinner,pipeline = "de_be0-lcd0-hdmi";
> >                         clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>,
> > -                                <&ahb_gates 44>;
> > +                                <&ahb_gates 44>, <&dram_gates 26>;
> >                         status = "disabled";
> >                 };
> >
> > @@ -74,7 +74,8 @@
> >                         compatible = "allwinner,simple-framebuffer",
> >                                      "simple-framebuffer";
> >                         allwinner,pipeline = "de_be0-lcd0";
> > -                       clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 44>;
> > +                       clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 44>,
> > +                                <&dram_gates 26>;
> >                         status = "disabled";
> >                 };
> >
> > @@ -83,7 +84,7 @@
> >                                      "simple-framebuffer";
> >                         allwinner,pipeline = "de_be0-lcd0-tve0";
> >                         clocks = <&pll5 1>, <&ahb_gates 34>, <&ahb_gates 36>,
> > -                                <&ahb_gates 44>;
> > +                                <&ahb_gates 44>, <&dram_gates 26>;
> >                         status = "disabled";
> >                 };
> >         };
> > diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
> > index 9669b03f20f3..f29163650ca8 100644
> > --- a/arch/arm/boot/dts/sun5i-a13.dtsi
> > +++ b/arch/arm/boot/dts/sun5i-a13.dtsi
> > @@ -62,7 +62,7 @@
> >                                      "simple-framebuffer";
> >                         allwinner,pipeline = "de_be0-lcd0";
> >                         clocks = <&ahb_gates 36>, <&ahb_gates 44>, <&de_be_clk>,
> > -                                <&tcon_ch0_clk>;
> > +                                <&tcon_ch0_clk>, <&dram_gates 26>;
> >                         status = "disabled";
> >                 };
> >         };
> > diff --git a/arch/arm/boot/dts/sun5i-r8.dtsi b/arch/arm/boot/dts/sun5i-r8.dtsi
> > index b1e4e0170d51..691d3de75b35 100644
> > --- a/arch/arm/boot/dts/sun5i-r8.dtsi
> > +++ b/arch/arm/boot/dts/sun5i-r8.dtsi
> > @@ -53,7 +53,7 @@
> >                         allwinner,pipeline = "de_be0-lcd0-tve0";
> >                         clocks = <&ahb_gates 34>, <&ahb_gates 36>,
> >                                  <&ahb_gates 44>, <&de_be_clk>,
> > -                                <&tcon_ch1_clk>;
> > +                                <&tcon_ch1_clk>, <&dram_gates 26>;
> >                         status = "disabled";
> >                 };
> >         };
> > diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
> > index 0840612b5ed6..c72d94228915 100644
> > --- a/arch/arm/boot/dts/sun5i.dtsi
> > +++ b/arch/arm/boot/dts/sun5i.dtsi
> > @@ -338,6 +338,25 @@
> >                         clock-output-names = "usb_ohci0", "usb_phy";
> >                 };
> >
> > +               dram_gates: clk at 01c20100 {
> > +                       #clock-cells = <1>;
> > +                       compatible = "allwinner,sun5i-a13-dram-gates-clk";
> > +                       reg = <0x01c20100 0x4>;
> > +                       clocks = <&pll5 0>;
> > +                       clock-indices = <0>,
> > +                                       <1>,
> 
> According to A10s manual, bit 3 is DRAM clock for TS (transport stream
> decoder), while bit 5 is for the TV encoder.
> 
> The others look good.

I'll fix that, thanks!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/6fac5061/attachment.sig>

From arnd at arndb.de  Wed Feb  3 12:36:38 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 03 Feb 2016 21:36:38 +0100
Subject: [PATCH] [RFC] ARM: modify pgd_t definition for
 TRANSPARENT_HUGEPAGE_PUD
In-Reply-To: <20160203163946.GA20360@ravnborg.org>
References: <1773775.QWf7OyDGPh@wuerfel> <20160203163946.GA20360@ravnborg.org>
Message-ID: <15001627.5KATBhJaXU@wuerfel>

On Wednesday 03 February 2016 17:39:46 Sam Ravnborg wrote:
> On Wed, Feb 03, 2016 at 02:21:48PM +0100, Arnd Bergmann wrote:
> > arch/alpha/include/asm/page.h
> > arch/arc/include/asm/page.h
> > arch/arm/include/asm/pgtable-3level-types.h
> > arch/arm64/include/asm/pgtable-types.h
> > arch/ia64/include/asm/page.h
> > arch/parisc/include/asm/page.h
> > arch/powerpc/include/asm/page.h
> > arch/sparc/include/asm/page_32.h
> > arch/sparc/include/asm/page_64.h
> 
> For the sparc32 case we use the simpler variants.
> According to the comment this is due to limitation in
> the way we pass arguments in the sparc32 ABI.
> But I have not tried to compare a kernel for sparc32 with
> and without the use of structs.
> 
> For sparc64 we use the stricter types (structs).
> I did not check other architectures - but just wanted to
> tell that the right choice may be architecture dependent.
> 

I see. I was assuming that they all (wrongly) default to the simple
definitions.

It seems we have these categories:

* both defined, but using strict:
arch/alpha/include/asm/page.h:#define STRICT_MM_TYPECHECKS
arch/sparc/include/asm/page_64.h:#define STRICT_MM_TYPECHECKS
arch/ia64/include/asm/page.h:#  define STRICT_MM_TYPECHECKS
arch/parisc/include/asm/page.h:#define STRICT_MM_TYPECHECKS

* both defined, but using non-strict:
arch/arc/include/asm/page.h:#undef STRICT_MM_TYPECHECKS
arch/arm/include/asm/pgtable-2level-types.h:#undef STRICT_MM_TYPECHECKS
arch/arm/include/asm/pgtable-3level-types.h:#undef STRICT_MM_TYPECHECKS
arch/arm64/include/asm/pgtable-types.h:#undef STRICT_MM_TYPECHECKS
arch/sparc/include/asm/page_32.h:/* #define STRICT_MM_TYPECHECKS */
arch/unicore32/include/asm/page.h:#undef STRICT_MM_TYPECHECKS

* Kconfig option:
arch/powerpc/Kconfig.debug:config STRICT_MM_TYPECHECKS
			 	default n

* only strict defined:
everything else


	Arnd


From thomas.petazzoni at free-electrons.com  Wed Feb  3 12:38:25 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 3 Feb 2016 21:38:25 +0100
Subject: [PATCH v2 08/12] devicetree: bindings: add DT binding for the
 Marvell Armada 3700 SoC family
In-Reply-To: <1454524889-9207-9-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
 <1454524889-9207-9-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160203213825.4fa6a0ef@free-electrons.com>

Hello,

On Wed,  3 Feb 2016 19:41:25 +0100, Gregory CLEMENT wrote:
> The Marvell Armada 3700 is a family of ARMv8 CA53 SoCs. This commit
> introduces the Device Tree binding that documents the top-level
> compatible strings for Armada 3700 based platforms.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  .../devicetree/bindings/arm/marvell/armada-37xx.txt      | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
> new file mode 100644
> index 000000000000..17e90e8b5f76
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
> @@ -0,0 +1,16 @@
> +Marvell Armada 37xx Platforms Device Tree Bindings
> +--------------------------------------------------
> +
> +Boards using a SoC of the Marvell Armada 37xx family must carry the
> +following root node property:
> +
> + - compatible: must contain "marvell,armada3710"

Are we sure at this point that the 3720 is a strict super-set of the
3710 ?

If that's not the case, then it would be somewhat weird for a platform
using the 3720 platform to carry the marvell,armada3710 compatible
string, no?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From ard.biesheuvel at linaro.org  Wed Feb  3 12:41:21 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 3 Feb 2016 21:41:21 +0100
Subject: [PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM
In-Reply-To: <CAKv+Gu_50f+yqs20a6j_QyCg3NcSfe5cD00fWXebLXBFhV_eGg@mail.gmail.com>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <HKXPR06MB0565A2CFF95AD7C000F43E6A8ADF0@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu9VvskQ34w0niS+6AtF9hNcycfYDt_3Kp4T+WK8Vxf_dA@mail.gmail.com>
 <HKXPR06MB05656F902E0E1FBBDBD713DC8AD00@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu8ZTHAqviveLMizRKPfeXwb6kcXi4cVQNYVYuPcVMgMeQ@mail.gmail.com>
 <20160203200107.GD10826@n2100.arm.linux.org.uk>
 <CAKv+Gu_MyPvDnnQ0hScqW6XR77h0MD6LxEb_q2Z-mS0AQw3djA@mail.gmail.com>
 <alpine.LFD.2.20.1602031522090.17825@knanqh.ubzr>
 <CAKv+Gu_50f+yqs20a6j_QyCg3NcSfe5cD00fWXebLXBFhV_eGg@mail.gmail.com>
Message-ID: <CAKv+Gu_p9QaK31h5K0t=ZQ1HYRgbjH3tsZ8hG5fZ=-vJCiKSaA@mail.gmail.com>

On 3 February 2016 at 21:30, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 3 February 2016 at 21:23, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
>> On Wed, 3 Feb 2016, Ard Biesheuvel wrote:
>>
>>> On 3 February 2016 at 21:01, Russell King - ARM Linux
>>> <linux at arm.linux.org.uk> wrote:
>>> > On Wed, Feb 03, 2016 at 02:41:29PM +0100, Ard Biesheuvel wrote:
>>> >> > bf353edc T __stubs_start
>>> >>
>>> >> This is a global symbol
>>> >>
>>> >> > bf353edc T _etext
>>> >> > bf353ee0 t __stubs_start
>>> >>
>>> >> This is a local symbol
>>> >
>>> > Stop this madness.  This gets you an immediate NAK on the patch set.
>>> >
>>>
>>> What madness? This does not change at all with my patches, these
>>> duplicates already exist in the current code.
>>
>> That doesn't make it any better, and was cause for issue as Chris
>> demonstrated.  Can we get rid of that duplication please?
>>
>
> 4/4 in my v2 removes the redundant symbols.

... actually, that only removes the redundant __stub_start, and the
redundant __vectors_start is already removed in patch #1. Patch #4
(v2) may be shot down for other reasons, in that case I can simply
move the removal of __stubs_start to patch #1 instead.


From robh at kernel.org  Wed Feb  3 12:47:17 2016
From: robh at kernel.org (Rob Herring)
Date: Wed, 3 Feb 2016 14:47:17 -0600
Subject: [PATCH v6 1/4] dt-bindings: mailbox: Document Hi6220 mailbox
 driver
In-Reply-To: <1454407782-24674-2-git-send-email-leo.yan@linaro.org>
References: <1454407782-24674-1-git-send-email-leo.yan@linaro.org>
 <1454407782-24674-2-git-send-email-leo.yan@linaro.org>
Message-ID: <20160203204717.GA1713@rob-hp-laptop>

On Tue, Feb 02, 2016 at 06:09:39PM +0800, Leo Yan wrote:
> Document DT binding for Hisilicon Hi6220 mailbox driver.
> 
> Signed-off-by: Leo Yan <leo.yan at linaro.org>
> ---
>  .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  | 74 ++++++++++++++++++++++
>  1 file changed, 74 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt

One nit, otherwise:

Acked-by: Rob Herring <robh at kernel.org>

> 
> diff --git a/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
> new file mode 100644
> index 0000000..8508c8a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
> @@ -0,0 +1,74 @@
> +Hisilicon Hi6220 Mailbox Driver
> +===============================
> +
> +Hisilicon Hi6220 mailbox supports up to 32 channels. Each channel
> +is unidirectional with a maximum message size of 8 words. I/O is
> +performed using register access (there is no DMA) and the cell
> +raises an interrupt when messages are received.
> +
> +Mailbox Device Node:
> +====================
> +
> +Required properties:
> +--------------------
> +- compatible:		Shall be "hisilicon,hi6220-mbox"
> +- reg:			Contains the mailbox register address range (base
> +			address and length); the first item is for IPC
> +			registers, the second item is shared buffer for
> +			slots.
> +- #mbox-cells:		Common mailbox binding property to identify the number
> +			of cells required for the mailbox specifier. Must be 3.
> +			<&phandle slot_id dst_irq ack_irq>
> +			  phandle: Label name of mailbox controller
> +			  slot_id: Slot id used either for TX or RX
> +			  dst_irq: IRQ identifier index number which used by MCU
> +			  ack_irq: IRQ identifier index number with generating a
> +			           TX/RX interrupt to application processor,
> +				   mailbox driver uses it to acknowledge interrupt
> +- interrupts:		Contains the interrupt information for the mailbox
> +			device. The format is dependent on which interrupt
> +			controller the SoCs use.
> +
> +Optional Properties:
> +--------------------
> +- hi6220,mbox-tx-noirq: Property of MCU firmware's feature, so mailbox driver
> +			use this flag to ask MCU to enable "automatic idle
> +			flag" mode or IRQ generated mode to acknowledge a TX
> +			completion.
> +
> +Example:
> +--------
> +
> +	mailbox: mailbox at F7510000 {

use lowercase for hex

> +		compatible = "hisilicon,hi6220-mbox";
> +		reg = <0x0 0xF7510000 0x0 0x1000>, /* IPC_S */
> +		      <0x0 0x06DFF800 0x0 0x0800>; /* Mailbox */

and here too.

> +		interrupt-parent = <&gic>;
> +		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
> +		#mbox-cells = <3>;
> +	};
> +
> +
> +Mailbox client
> +===============
> +
> +Required properties:
> +--------------------
> +- compatible:		Many (See the client docs).
> +- mboxes:		Standard property to specify a Mailbox (See ./mailbox.txt)
> +			Cells must match 'mbox-cells' (See Mailbox Device Node above).
> +
> +Optional Properties:
> +--------------------
> +- mbox-names:		Name given to channels seen in the 'mboxes' property.
> +
> +Example:
> +--------
> +
> +	stub_clock: stub_clock {
> +		compatible = "hisilicon,hi6220-stub-clk";
> +		hisilicon,hi6220-clk-sram = <&sram>;
> +		#clock-cells = <1>;
> +		mbox-names = "mbox-tx", "mbox-rx";
> +		mboxes = <&mailbox 1 0 11>, <&mailbox 0 1 10>;
> +	};
> -- 
> 1.9.1
> 


From maxime.ripard at free-electrons.com  Wed Feb  3 12:47:30 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 3 Feb 2016 21:47:30 +0100
Subject: [PATCH v2 17/26] drm: sun4i: Add DT bindings documentation
In-Reply-To: <CAL_JsqLLvK0L+PaOxesgr9u_3hb6EWbb9w2-yw80D8sUqiohTA@mail.gmail.com>
References: <1452785109-6172-1-git-send-email-maxime.ripard@free-electrons.com>
 <1452785109-6172-18-git-send-email-maxime.ripard@free-electrons.com>
 <20160115031515.GA19797@rob-hp-laptop>
 <20160203195919.GB3327@lukather>
 <CAL_JsqLLvK0L+PaOxesgr9u_3hb6EWbb9w2-yw80D8sUqiohTA@mail.gmail.com>
Message-ID: <20160203204730.GH3327@lukather>

On Wed, Feb 03, 2016 at 02:19:31PM -0600, Rob Herring wrote:
> >> > +Required properties:
> >> > +  - compatible: value must be one of:
> >> > +    * allwinner,sun5i-a13-display-engine
> >> > +  - allwinner,pipelines: list of phandle to the entry points of the
> >> > +    pipelines (either to the frontend or backend)
> >> > +
> >> > +Example:
> >> > +
> >> > +panel: panel {
> >> > +   compatible = "olimex,lcd-olinuxino-43-ts";
> >>
> >> This should either be a child of what it is attached to or use of-graph.
> >
> > You had a similar discussion with Thierry last time I sent it, and it
> > seemed to settle on keeping that property:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/382115.html
> >
> > Has that changed?
> 
> No, I still disagree. We already have 2 ways to describe panels: as a
> child node of its controller or with of-graph. We don't need a 3rd way
> even if it is simple. The problem with of-graph today is too much of
> the parsing is left to the individual drivers. We need to fix that and
> make it be handled by common code.

Ok. I'm guessing from your answer you prefer of-graph over a child
node ?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160203/d38c1394/attachment.sig>

From arnd at arndb.de  Wed Feb  3 12:49:22 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 03 Feb 2016 21:49:22 +0100
Subject: [PATCH 0/7] USB changes for rare warnings
In-Reply-To: <87lh7161wc.fsf@belgarion.home>
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <87oabxpsr8.fsf@ti.com> <87lh7161wc.fsf@belgarion.home>
Message-ID: <1964102.4NLQkU883F@wuerfel>

On Wednesday 03 February 2016 20:15:47 Robert Jarzmik wrote:
> Felipe Balbi <balbi at kernel.org> writes:
> 
> > Hi Arnd,
> >
> >>  arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h | 198 ---------
> >>  arch/arm/mach-pxa/include/mach/pxa25x-udc.h     | 163 --------
> >
> > for arch/arm I need Acked-by from relevant folks.
> You already have mine for arch/arm/mach-pxa/include/mach/pxa25x-udc.h I think,
> or did my mailer betray me again ...

I saw it.

> I cannot speak for ixp4xx though.

Krzysztof Halasa <khalasa at piap.pl> gave an Ack for the first patch already,
and I think we concluded that the patch was keeping the current behavior
otherwise and is therefore not a regression, though we did not finish
the side-discussion about whether ixp4xx actually works in both BE and LE
mode with both indirect and direct I/O, or which of the four combinations
is broken.

> > Also, do you think we need this during the -rc or can we consider it
> > non-critical fixes for v4.6 merge window ?

I meant it for 4.6, sorry for not being very clear about that.
All the warnings I fixed in this series are harmless as far as I
can tell, and they only show up in rare randconfig builds.

	Arnd


From vincent.guittot at linaro.org  Wed Feb  3 13:04:37 2016
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Wed, 3 Feb 2016 22:04:37 +0100
Subject: [PATCH v3 2/6] drivers/cpufreq: implement
 init_cpu_capacity_default()
In-Reply-To: <1454500799-18451-3-git-send-email-juri.lelli@arm.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <1454500799-18451-3-git-send-email-juri.lelli@arm.com>
Message-ID: <CAKfTPtDGk5BC25WqHdhDYDOBgUsuidAMhrXS=eDi6wJPZjfrwA@mail.gmail.com>

On 3 February 2016 at 12:59, Juri Lelli <juri.lelli at arm.com> wrote:
> To get default values for CPUs capacity we profile a simple (bogus)
> integer benchmark on such CPUs; then we normalize results to 1024
> (highest capacity in the system).
>
> Architectures that want this during boot have to define a weak function
> (arch_wants_init_cpu_capacity) to return true.
>
> Also, kernel has to boot with init_cpu_capacity parameter if profiling
> is needed, as it can be expensive and might add ~1 sec to boot time.
>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: "Rafael J. Wysocki" <rjw at rjwysocki.net>
> Cc: Viresh Kumar <viresh.kumar at linaro.org>
> Cc: Vincent Guittot <vincent.guittot at linaro.org>
> Cc: Sudeep Holla <sudeep.holla at arm.com>
> Cc: Mark Rutland <mark.rutland at arm.com>
> Signed-off-by: Juri Lelli <juri.lelli at arm.com>
> ---
>  Changes since v1:
>  - add kernel command line parameter to enable profiling
>  - add define for max trials
>
>  Documentation/kernel-parameters.txt |   4 +
>  arch/arm/kernel/topology.c          |   2 +-
>  arch/arm64/kernel/topology.c        |  12 +++
>  drivers/cpufreq/Makefile            |   2 +-
>  drivers/cpufreq/cpufreq.c           |   1 +
>  drivers/cpufreq/cpufreq_capacity.c  | 174 ++++++++++++++++++++++++++++++++++++
>  include/linux/cpufreq.h             |   2 +
>  7 files changed, 195 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/cpufreq/cpufreq_capacity.c
>
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 87d40a7..fad2b89 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1570,6 +1570,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>
>         initrd=         [BOOT] Specify the location of the initial ramdisk
>
> +       init_cpu_capacity
> +                       [KNL,ARM] Enables dynamic CPUs capacity benchmarking
> +                       at boot.
> +
>         inport.irq=     [HW] Inport (ATI XL and Microsoft) busmouse driver
>                         Format: <irq>
>
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index ec279d1..c9c87a5 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -47,7 +47,7 @@ unsigned long arch_scale_cpu_capacity(struct sched_domain *sd, int cpu)
>         return per_cpu(cpu_scale, cpu);
>  }
>
> -static void set_capacity_scale(unsigned int cpu, unsigned long capacity)
> +void set_capacity_scale(unsigned int cpu, unsigned long capacity)
>  {
>         per_cpu(cpu_scale, cpu) = capacity;
>  }
> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> index 694f6de..3b75d63 100644
> --- a/arch/arm64/kernel/topology.c
> +++ b/arch/arm64/kernel/topology.c
> @@ -23,6 +23,18 @@
>  #include <asm/cputype.h>
>  #include <asm/topology.h>
>
> +static DEFINE_PER_CPU(unsigned long, cpu_scale) = SCHED_CAPACITY_SCALE;
> +
> +unsigned long arm_arch_scale_cpu_capacity(struct sched_domain *sd, int cpu)
> +{
> +       return per_cpu(cpu_scale, cpu);
> +}
> +
> +void set_capacity_scale(unsigned int cpu, unsigned long capacity)
> +{
> +       per_cpu(cpu_scale, cpu) = capacity;
> +}
> +
>  static int __init get_cpu_for_node(struct device_node *node)
>  {
>         struct device_node *cpu_node;
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 9e63fb1..c4025fd 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -1,5 +1,5 @@
>  # CPUfreq core
> -obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o
> +obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o cpufreq_capacity.o

Do you really want to have the calibration of capacity dependent of
cpufreq ? It means that we can't use it without a cpufreq driver.
IMHO, this creates a unnecessary dependency. I understand that you
must ensure that core runs at max fequency if a driver is present but
you should be able to calibrate the capacity if cpufreq is not
available but you have different capacity because micro architecture

>
>  # CPUfreq stats
>  obj-$(CONFIG_CPU_FREQ_STAT)             += cpufreq_stats.o
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index e979ec7..b22afe8 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -2440,6 +2440,7 @@ int cpufreq_register_driver(struct cpufreq_driver *driver_data)
>         }
>
>         register_hotcpu_notifier(&cpufreq_cpu_notifier);
> +       cpufreq_init_cpu_capacity();
>         pr_debug("driver %s up and running\n", driver_data->name);
>
>  out:
> diff --git a/drivers/cpufreq/cpufreq_capacity.c b/drivers/cpufreq/cpufreq_capacity.c
> new file mode 100644
> index 0000000..e54310b
> --- /dev/null
> +++ b/drivers/cpufreq/cpufreq_capacity.c
> @@ -0,0 +1,174 @@
> +/*
> + * Default CPU capacity calculation for u-arch invariance
> + *
> + * Copyright (C) 2015 ARM Ltd.
> + * Juri Lelli <juri.lelli at arm.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 "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#include <linux/cpufreq.h>
> +#include <linux/sched.h>
> +
> +#define MAX_TRIALS 10 /* how many times benchmark is executed */
> +static unsigned long long elapsed[NR_CPUS];
> +
> +/*
> + * Don't let compiler optimize following two functions; we want to avoid any
> + * microarchitecture specific optimization that compiler would do and favour
> + * one CPU vs. another. Also, my_int_sqrt is cut-and-paste from
> + * lib/int_sqrt.c.
> + */
> +static unsigned long __attribute__((optimize("O0")))
> +my_int_sqrt(unsigned long x)
> +{
> +       unsigned long b, m, y = 0;
> +
> +       if (x <= 1)
> +               return x;
> +
> +       m = 1UL << (BITS_PER_LONG - 2);
> +       while (m != 0) {
> +               b = y + m;
> +               y >>= 1;
> +
> +               if (x >= b) {
> +                       x -= b;
> +                       y += m;
> +               }
> +               m >>= 2;
> +       }
> +
> +       return y;
> +}
> +
> +static unsigned long __attribute__((optimize("O0")))
> +bogus_bench(void)
> +{
> +       unsigned long i, res;
> +
> +       for (i = 0; i < 100000; i++)
> +               res = my_int_sqrt(i);
> +
> +       return res;
> +}
> +
> +static int run_bogus_benchmark(int cpu)
> +{
> +       int ret, trials = MAX_TRIALS;
> +       u64 begin, end, sample, mean = 0, count = 0;
> +       unsigned long res;
> +
> +       ret = set_cpus_allowed_ptr(current, cpumask_of(cpu));
> +       if (ret) {
> +               pr_warn("%s: failed to set allowed ptr\n", __func__);
> +               return -EINVAL;
> +       }
> +
> +       while (trials--) {
> +               begin = local_clock();
> +               res = bogus_bench();
> +               end = local_clock();
> +               sample = end - begin;
> +
> +               mean = mean * count + sample;
> +               mean = div64_u64(mean, ++count);
> +               pr_debug("%s: cpu=%d begin=%llu end=%llu"
> +                        " sample=%llu mean=%llu count=%llu res=%lu\n",
> +                       __func__, cpu, begin, end, sample,
> +                       mean, count, res);
> +       }
> +       elapsed[cpu] = mean;
> +
> +       ret = set_cpus_allowed_ptr(current, cpu_active_mask);
> +       if (ret) {
> +               pr_warn("%s: failed to set allowed ptr\n", __func__);
> +               return -EINVAL;
> +       }
> +
> +       return 0;
> +}
> +
> +bool __weak arch_wants_init_cpu_capacity(void)
> +{
> +       return false;
> +}
> +
> +void __weak set_capacity_scale(int cpu, unsigned long capacity) { }
> +
> +static __read_mostly bool init_cpu_capacity_enabled;
> +
> +static int __init init_cpu_capacity_setup(char *str)
> +{
> +       init_cpu_capacity_enabled = true;
> +
> +       return 0;
> +}
> +early_param("init_cpu_capacity", init_cpu_capacity_setup);
> +
> +void cpufreq_init_cpu_capacity(void)
> +{
> +       int cpu, fcpu;
> +       unsigned long long elapsed_min = ULLONG_MAX;
> +       unsigned int curr_min, curr_max;
> +       struct cpufreq_policy *policy;
> +
> +       if (!arch_wants_init_cpu_capacity() || !init_cpu_capacity_enabled)
> +               return;
> +
> +       for_each_possible_cpu(cpu) {
> +               policy = cpufreq_cpu_get(cpu);
> +               if (IS_ERR_OR_NULL(policy))
> +                       return;
> +
> +               /*
> +                * We profile only first CPU of each frequency domain;
> +                * and use that value as capacity of every CPU in the domain.
> +                */
> +               fcpu = cpumask_first(policy->related_cpus);
> +               if (cpu != fcpu) {
> +                       elapsed[cpu] = elapsed[fcpu];
> +                       cpufreq_cpu_put(policy);
> +                       continue;
> +               }
> +
> +               down_write(&policy->rwsem);
> +               curr_min = policy->user_policy.min;
> +               curr_max = policy->user_policy.max;
> +               policy->user_policy.min = policy->cpuinfo.max_freq;
> +               policy->user_policy.max = policy->cpuinfo.max_freq;
> +               up_write(&policy->rwsem);
> +               cpufreq_cpu_put(policy);
> +               cpufreq_update_policy(cpu);
> +
> +               run_bogus_benchmark(cpu);
> +               if (elapsed[cpu] < elapsed_min)
> +                       elapsed_min = elapsed[cpu];
> +               pr_debug("%s: cpu=%d elapsed=%llu (min=%llu)\n",
> +                               __func__, cpu, elapsed[cpu], elapsed_min);
> +
> +               policy = cpufreq_cpu_get(cpu);
> +               down_write(&policy->rwsem);
> +               policy->user_policy.min = curr_min;
> +               policy->user_policy.max = curr_max;
> +               up_write(&policy->rwsem);
> +               cpufreq_cpu_put(policy);
> +               cpufreq_update_policy(cpu);
> +       }
> +
> +       for_each_possible_cpu(cpu) {
> +               unsigned long capacity;
> +
> +               capacity = div64_u64((elapsed_min << 10), elapsed[cpu]);
> +               pr_debug("%s: CPU%d capacity=%lu\n", __func__, cpu, capacity);
> +               set_capacity_scale(cpu, capacity);
> +       }
> +
> +       pr_info("dynamic CPUs capacity installed\n");
> +}
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 88a4215..9924351 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -419,6 +419,8 @@ static inline unsigned long cpufreq_scale(unsigned long old, u_int div,
>  #endif
>  }
>
> +void cpufreq_init_cpu_capacity(void);
> +
>  /*********************************************************************
>   *                          CPUFREQ GOVERNORS                        *
>   *********************************************************************/
> --
> 2.7.0
>


From mw at semihalf.com  Wed Feb  3 13:41:15 2016
From: mw at semihalf.com (Marcin Wojtas)
Date: Wed, 3 Feb 2016 22:41:15 +0100
Subject: [PATCH v2 03/12] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <1454524889-9207-4-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
 <1454524889-9207-4-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <CAPv3WKdh8D8GYMabALQQW-Z7L+=XhkZw2cXdYpcQ8tF0Rjckag@mail.gmail.com>

Hi Gregory,

> +       port->irq        = irq->start;
> +       port->irqflags   = 0;

Same request as for v1, which you must have overlooked:
port->irqflags = IRQF_SHARED;

Best regards,
Marcin


From tony at atomide.com  Wed Feb  3 13:51:09 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Feb 2016 13:51:09 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160203184504.GN19432@atomide.com>
References: <CAPDyKFras1o13WBZzaZ_Snnj5TBQQFWKr=PtCjUvwe+yGPQn9w@mail.gmail.com>
 <20160202163536.GU19432@atomide.com>
 <CAPDyKFosQjkHDVSvy67+hstjjFseXQP5WYXrJE19GgVFYJ099w@mail.gmail.com>
 <20160202234145.GC19432@atomide.com>
 <CAPDyKFqLi8xOUeoxUTAmif5QrOjVpV_2CDLv4hjO_C9iOnv+5Q@mail.gmail.com>
 <20160203162705.GG19432@atomide.com>
 <CAPDyKFrsbW+vOoKBDvkNbJa=aUZE1EcikCqrAuO4cv+TkW-FnA@mail.gmail.com>
 <20160203182828.GM19432@atomide.com>
 <CAPDyKFonA4AAzx9JaQ2NZViMLvCjoa5vy2WRuhEF_5Hg8gPKeg@mail.gmail.com>
 <20160203184504.GN19432@atomide.com>
Message-ID: <20160203215109.GO19432@atomide.com>

* Tony Lindgren <tony at atomide.com> [160203 10:46]:
> * Ulf Hansson <ulf.hansson at linaro.org> [160203 10:38]:
> > On 3 February 2016 at 19:28, Tony Lindgren <tony at atomide.com> wrote:
> > > * Ulf Hansson <ulf.hansson at linaro.org> [160203 10:03]:
> > >>
> > >> One more thing though. I just realized that you have yet another issue
> > >> to consider going for the approach fixing *only* drivers.
> > >>
> > >> Let me summarize it here:
> > >>
> > >> If userspace has prevented runtime PM (pm_runtime_forbid()) when a
> > >> driver becomes unbound, the driver will not be able to suspend the
> > >> device by using any of the pm_runtime_suspend() APIs, as the usage
> > >> count is isn't zero.
> > >>
> > >> As pm_runtime_reinit() is invoked as part of the driver unbind
> > >> sequence, the runtime PM status goes out of sync. A following driver
> > >> rebind will then trigger the warning when the PM domain's
> > >> ->runtime_resume() callback gets invoked. Again, forever preventing
> > >> the device from being runtime suspended.
> > >
> > > Hmm yeah that's a good point.
> > >
> > >> How do you intend to solve this case?
> > >> I guess there are two options, pick up the patch I posted for omap
> > >> hwmod or make use of pm_runtime_force_suspend() in the driver.
> > >
> > > My gut feeling right now is we should just have
> > > BUS_NOTIFY_UNBIND_DRIVER shut down the device on the interconnect
> > > automatically as it's unused after the driver has unloaded :)
> > 
> > BUS_NOTIFY_UNBIND_DRIVER is sent prior the ->remove() callbacks is
> > invoked from driver core.
> > So if the driver requires to do a pm_runtime_get_sync() during
> > ->remove() callback, this won't work.
> > 
> > BUS_NOTIFY_UNBOUND_DRIVER may work though.
> 
> Right sorry that's what I meant. Naturally we can't do it before
> remove :)
> 
> I'll take a look.

This patch below seems to fix this issue. I'll do some more
testing here and send the driver fixes and this with proper
commit messages. Thanks for letting me know about that one!

Regards,

Tony

8< -------------------
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -191,12 +191,22 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
 {
 	struct platform_device *pdev = to_platform_device(dev);
 	struct omap_device *od;
+	int err;
 
 	switch (event) {
 	case BUS_NOTIFY_DEL_DEVICE:
 		if (pdev->archdata.od)
 			omap_device_delete(pdev->archdata.od);
 		break;
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+		od = to_omap_device(pdev);
+		if (od && (od->_state == OMAP_DEVICE_STATE_ENABLED)) {
+			dev_info(&pdev->dev, "enabled after unload, idling\n");
+			err = omap_device_idle(pdev);
+			if (err)
+				dev_err(&pdev->dev, "failed to idle\n");
+		}
+		break;
 	case BUS_NOTIFY_ADD_DEVICE:
 		if (pdev->dev.of_node)
 			omap_device_build_from_dt(pdev);


From arnd at arndb.de  Wed Feb  3 13:59:51 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed,  3 Feb 2016 22:59:51 +0100
Subject: [PATCH 1/2] of: always define of_node_cmp() and other functions
Message-ID: <1454536806-3755190-1-git-send-email-arnd@arndb.de>

The ti-vpe driver started using of_node_cmp(), and it can
be used when CONFIG_OF is disabled, which results in a
build failure:

drivers/media/platform/ti-vpe/cal.c: In function 'of_get_next_port':
drivers/media/platform/ti-vpe/cal.c:1655:12: error: implicit declaration of function 'of_node_cmp' [-Werror=implicit-function-declaration]

There is no reason for this, we can simply move the definition
outside of the #ifdef CONFIG_OF section without any downsides.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 include/linux/of.h | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/include/linux/of.h b/include/linux/of.h
index dc6e39696b64..f8d9b558f9bd 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -128,6 +128,23 @@ extern raw_spinlock_t devtree_lock;
 
 #define OF_BAD_ADDR	((u64)-1)
 
+#if defined(CONFIG_SPARC)
+#include <asm/prom.h>
+#endif
+
+/* Default #address and #size cells.  Allow arch asm/prom.h to override */
+#if !defined(OF_ROOT_NODE_ADDR_CELLS_DEFAULT)
+#define OF_ROOT_NODE_ADDR_CELLS_DEFAULT 1
+#define OF_ROOT_NODE_SIZE_CELLS_DEFAULT 1
+#endif
+
+/* Default string compare functions, Allow arch asm/prom.h to override */
+#if !defined(of_compat_cmp)
+#define of_compat_cmp(s1, s2, l)	strcasecmp((s1), (s2))
+#define of_prop_cmp(s1, s2)		strcmp((s1), (s2))
+#define of_node_cmp(s1, s2)		strcasecmp((s1), (s2))
+#endif
+
 #ifdef CONFIG_OF
 void of_core_init(void);
 
@@ -211,23 +228,6 @@ static inline unsigned long of_read_ulong(const __be32 *cell, int size)
 	return of_read_number(cell, size);
 }
 
-#if defined(CONFIG_SPARC)
-#include <asm/prom.h>
-#endif
-
-/* Default #address and #size cells.  Allow arch asm/prom.h to override */
-#if !defined(OF_ROOT_NODE_ADDR_CELLS_DEFAULT)
-#define OF_ROOT_NODE_ADDR_CELLS_DEFAULT 1
-#define OF_ROOT_NODE_SIZE_CELLS_DEFAULT 1
-#endif
-
-/* Default string compare functions, Allow arch asm/prom.h to override */
-#if !defined(of_compat_cmp)
-#define of_compat_cmp(s1, s2, l)	strcasecmp((s1), (s2))
-#define of_prop_cmp(s1, s2)		strcmp((s1), (s2))
-#define of_node_cmp(s1, s2)		strcasecmp((s1), (s2))
-#endif
-
 #define OF_IS_DYNAMIC(x) test_bit(OF_DYNAMIC, &x->_flags)
 #define OF_MARK_DYNAMIC(x) set_bit(OF_DYNAMIC, &x->_flags)
 
-- 
2.7.0



From arnd at arndb.de  Wed Feb  3 13:59:52 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed,  3 Feb 2016 22:59:52 +0100
Subject: [PATCH 2/2] of: provide of_n_{addr,
 size}_cells wrappers for !CONFIG_OF
In-Reply-To: <1454536806-3755190-1-git-send-email-arnd@arndb.de>
References: <1454536806-3755190-1-git-send-email-arnd@arndb.de>
Message-ID: <1454536806-3755190-2-git-send-email-arnd@arndb.de>

The pci-rcar driver is enabled for compile tests, and this has
now shown that the driver cannot build without CONFIG_OF,
following the inclusion of f8f2fe7355fb "PCI: rcar: Use new OF
interrupt mapping when possible":

../drivers/pci/host/pcie-rcar.c: In function 'pci_dma_range_parser_init':
../drivers/pci/host/pcie-rcar.c:856:2: error: implicit declaration of function 'of_n_addr_cells' [-Werror=implicit-function-declaration]
  parser->pna = of_n_addr_cells(node);
  ^
As pointed out by Ben Dooks and Geert Uytterhoeven, this is actually
supposed to build fine, which we can achieve if we make the
declaration of of_irq_parse_and_map_pci conditional on CONFIG_OF
and provide an empty inline function otherwise, as we do for
a lot of other of interfaces.

This lets us build the rcar_pci driver again without CONFIG_OF
for build testing. All platforms using this driver select OF,
so this doesn't change anything for the users.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: devicetree at vger.kernel.org
Cc: Rob Herring <robh+dt at kernel.org>
Cc: Grant Likely <grant.likely at linaro.org>
Cc: Lucas Stach <l.stach at pengutronix.de>
Cc: Bjorn Helgaas <bhelgaas at google.com>
Cc: Magnus Damm <damm at opensource.se>
Cc: Geert Uytterhoeven <geert at linux-m68k.org>
Cc: Ben Dooks <ben.dooks at codethink.co.uk>
Cc: linux-pci at vger.kernel.org
Cc: linux-sh at vger.kernel.org

---
I originally sent the patch in 2014 when things initially broke
and then forgot about while it was applied in my randconfig patch
stack. It's still broken and I think this is hte correct fix.
---
 include/linux/of.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/of.h b/include/linux/of.h
index f8d9b558f9bd..9c941cd3ba58 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -565,6 +565,9 @@ static inline struct device_node *of_get_cpu_node(int cpu,
 	return NULL;
 }
 
+static inline int of_n_addr_cells(struct device_node *np) { return 0; }
+static inline int of_n_size_cells(struct device_node *np) { return 0; }
+
 static inline int of_property_read_u64(const struct device_node *np,
 				       const char *propname, u64 *out_value)
 {
-- 
2.7.0



From thomas.petazzoni at free-electrons.com  Wed Feb  3 14:02:24 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 3 Feb 2016 23:02:24 +0100
Subject: [PATCH v2 03/12] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <CAPv3WKdh8D8GYMabALQQW-Z7L+=XhkZw2cXdYpcQ8tF0Rjckag@mail.gmail.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
 <1454524889-9207-4-git-send-email-gregory.clement@free-electrons.com>
 <CAPv3WKdh8D8GYMabALQQW-Z7L+=XhkZw2cXdYpcQ8tF0Rjckag@mail.gmail.com>
Message-ID: <20160203230224.5ea52f65@free-electrons.com>

Dear Marcin Wojtas,

On Wed, 3 Feb 2016 22:41:15 +0100, Marcin Wojtas wrote:
> Hi Gregory,
> 
> > +       port->irq        = irq->start;
> > +       port->irqflags   = 0;
> 
> Same request as for v1, which you must have overlooked:
> port->irqflags = IRQF_SHARED;

Gregory didn't overlook this comment you made on v1, he even replied to
it. Please check Gregory's reply to your review.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From friesendrywall at gmail.com  Wed Feb  3 14:05:14 2016
From: friesendrywall at gmail.com (Erik Friesen)
Date: Wed, 3 Feb 2016 17:05:14 -0500
Subject: SGTL5000 misc
In-Reply-To: <CAEuupivdftoopCOX3f7KRbV9poKdjdD3s9hfcbgB2TYjHmrjvw@mail.gmail.com>
References: <CAEuupiuhPR48Upo=8f0zV8cxf0Vefgx3qA+vC+QDWAOV4n-e3Q@mail.gmail.com>
 <CAOMZO5BPNc1ncz6J8yhcBYywCVuTxKYMYhiNUt_Jq3LZsKdi+A@mail.gmail.com>
 <CAEuupiszxAj7JkJu-5ozqgEnTWkz9FQEpxN8dmEN+KtaV-76ww@mail.gmail.com>
 <CAOMZO5DhrzdVyTVPB3FNquV4rDQ8a0MQrsJMosVsUQN63hj1Ww@mail.gmail.com>
 <CAEuupiuoB7nMSc8Fbyort1rJd=ZhYc0zfJNkd=ckUYk1qd8Z7Q@mail.gmail.com>
 <CAOMZO5C4QUHnJr=pisnYWCYZ0zUt+7HO846aPQui0zcLyX0N-Q@mail.gmail.com>
 <CAEuupivdftoopCOX3f7KRbV9poKdjdD3s9hfcbgB2TYjHmrjvw@mail.gmail.com>
Message-ID: <CAEuupit8pVdnehkZkZPmq1QBHaS0sUG4NFuVFX37dKHn18j7DQ@mail.gmail.com>

Anyway, I think something like this should be added to sgtl5000.c

static int sgtl5000_enable_regulators(struct snd_soc_codec *codec) {
 int reg;
 int ret;
 int rev;
 int i;
 const u32 *property;
 int external_vddd = 0;
 int use_ext_vdd = 0;
 struct sgtl5000_priv *sgtl5000 = snd_soc_codec_get_drvdata(codec);

 for (i = 0; i < ARRAY_SIZE(sgtl5000->supplies); i++)
  sgtl5000->supplies[i].supply = supply_names[i];

 //allow dtb to select option to use vddd external per errata
 //VDDD-external = <1>;
 ++ property = of_get_property(codec->dev->of_node, "VDDD-external", NULL);
 ++ if(property != NULL){
 ++ dev_info(codec->dev, "DTB = use VDDD %x\n", *property);
 ++ use_ext_vdd = 1;
 ++ }
 ret = regulator_bulk_get(codec->dev, ARRAY_SIZE(sgtl5000->supplies),
sgtl5000->supplies);
 if (!ret) {
  external_vddd = 1;
 } else {
  ret = sgtl5000_replace_vddd_with_ldo(codec);
 if (ret)
 return ret;
 }

 ret = regulator_bulk_enable(ARRAY_SIZE(sgtl5000->supplies),
  sgtl5000->supplies);
if (ret)
goto err_regulator_free;

/* wait for all power rails bring up */
udelay(10);

/*
* workaround for revision 0x11 and later,
* roll back to use internal LDO
*/

ret = regmap_read(sgtl5000->regmap, SGTL5000_CHIP_ID, &reg);
if (ret)
goto err_regulator_disable;

rev = (reg & SGTL5000_REVID_MASK) >> SGTL5000_REVID_SHIFT;

--if (external_vddd && rev >= 0x11)
++if (external_vddd && rev >= 0x11 && !use_ext_vdd) {
/* disable all regulator first */

On Wed, Feb 3, 2016 at 10:11 AM, Erik Friesen <friesendrywall at gmail.com> wrote:
> There is no difference in code that I can tell between the two.  I am
> not asking to have this fixed, rather just some ideas on how I can
> implement this. If alsa-devel list is the preferred asking place, I'll
> go there.
>
> The riotboard used kernel 4.3.0-rc2-00019-gbcee19f with the same results.
>
> On Wed, Feb 3, 2016 at 9:51 AM, Fabio Estevam <festevam at gmail.com> wrote:
>> On Wed, Feb 3, 2016 at 12:46 PM, Erik Friesen <friesendrywall at gmail.com> wrote:
>>> It appears sgtl5000.c is patched the same in my kernel as the commit mentioned.
>>>
>>> The problem the way I see it, is that there is no mechanism to deal
>>> with a reboot on the codec itself.
>>
>> There is no reset line nor reset command on the sgtl5000.
>>
>>> This alsa stuff has too many layers.  At least coming from a non os
>>> embedded angle it seems that way.
>>
>> I would suggest you to try 4.4.1 and if you still see an issue with
>> the codec, then report it back to the alsa-devel at alsa-project.org
>> list.


From arnd at arndb.de  Wed Feb  3 14:05:50 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed,  3 Feb 2016 23:05:50 +0100
Subject: [PATCH] kernel/locking/lockdep.c: mark chainhashentry as
 __maybe_unused
Message-ID: <1454537158-3759624-1-git-send-email-arnd@arndb.de>

The newly added chainhashentry() function is only use when
CONFIG_PROVE_LOCKING is enabled, otherwise we get a warning about it.

kernel/locking/lockdep.c:318:26: error: 'chainhashentry' defined but not used [-Werror=unused-function]

We could add another #ifdef or add __maybe_unused to avoid the warning,
this patch picks the second option.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: a33a23c7def8 ("kernel/locking/lockdep.c: make lockdep initialize itself on demand")
---
 kernel/locking/lockdep.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 9269b1a74260..0d3c08d23946 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -315,7 +315,7 @@ static inline struct list_head *classhashentry(struct lockdep_subclass_key *key)
 
 static struct list_head __chainhash_table[CHAINHASH_SIZE];
 
-static struct list_head *chainhashentry(unsigned long chain)
+static __maybe_unused struct list_head * chainhashentry(unsigned long chain)
 {
 	if (unlikely(!lockdep_initialized))
 		lockdep_init();
-- 
2.7.0



From arnd at arndb.de  Wed Feb  3 14:15:05 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed,  3 Feb 2016 23:15:05 +0100
Subject: [PATCH] mm/debug-pagealloc: add missing debug_pagealloc_enabled
Message-ID: <1454537757-3760706-1-git-send-email-arnd@arndb.de>

The change to move the pagealloc logic broke the slab allocator
check when it's disabled at compile time:

mm/slab.c: In function 'is_debug_pagealloc_cache':
mm/slab.c:1608:29: error: implicit declaration of function 'debug_pagealloc_enabled' [-Werror=implicit-function-declaration]

This adds an inline helper to get it to work again.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 0a244aea1a61 ("mm/slab: clean up DEBUG_PAGEALLOC processing code")
---
 include/linux/mm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 5d86eb2e8584..90d600ce56ad 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2242,6 +2242,7 @@ kernel_map_pages(struct page *page, int numpages, int enable)
 extern bool kernel_page_present(struct page *page);
 #endif /* CONFIG_HIBERNATION */
 #else
+static inline bool debug_pagealloc_enabled(void) { return 0; }
 static inline void
 kernel_map_pages(struct page *page, int numpages, int enable) {}
 #ifdef CONFIG_HIBERNATION
-- 
2.7.0



From festevam at gmail.com  Wed Feb  3 14:20:39 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 3 Feb 2016 20:20:39 -0200
Subject: SGTL5000 misc
In-Reply-To: <CAEuupit8pVdnehkZkZPmq1QBHaS0sUG4NFuVFX37dKHn18j7DQ@mail.gmail.com>
References: <CAEuupiuhPR48Upo=8f0zV8cxf0Vefgx3qA+vC+QDWAOV4n-e3Q@mail.gmail.com>
 <CAOMZO5BPNc1ncz6J8yhcBYywCVuTxKYMYhiNUt_Jq3LZsKdi+A@mail.gmail.com>
 <CAEuupiszxAj7JkJu-5ozqgEnTWkz9FQEpxN8dmEN+KtaV-76ww@mail.gmail.com>
 <CAOMZO5DhrzdVyTVPB3FNquV4rDQ8a0MQrsJMosVsUQN63hj1Ww@mail.gmail.com>
 <CAEuupiuoB7nMSc8Fbyort1rJd=ZhYc0zfJNkd=ckUYk1qd8Z7Q@mail.gmail.com>
 <CAOMZO5C4QUHnJr=pisnYWCYZ0zUt+7HO846aPQui0zcLyX0N-Q@mail.gmail.com>
 <CAEuupivdftoopCOX3f7KRbV9poKdjdD3s9hfcbgB2TYjHmrjvw@mail.gmail.com>
 <CAEuupit8pVdnehkZkZPmq1QBHaS0sUG4NFuVFX37dKHn18j7DQ@mail.gmail.com>
Message-ID: <CAOMZO5BxFRzi3qJAK=xDGger_MK9GZhuM00ugo836PHK_zJKjQ@mail.gmail.com>

On Wed, Feb 3, 2016 at 8:05 PM, Erik Friesen <friesendrywall at gmail.com> wrote:
> Anyway, I think something like this should be added to sgtl5000.c

Yes, please send a formal patch for it.


From k at japko.eu  Wed Feb  3 14:21:17 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Wed, 3 Feb 2016 23:21:17 +0100
Subject: [PATCH v2 2/5] dts: sun8i-h3: Add APB0 related clocks and resets
In-Reply-To: <20160203123534.GG4652@lukather>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
 <1454448113-18810-3-git-send-email-k@japko.eu>
 <20160203123534.GG4652@lukather>
Message-ID: <20160203222117.GA12071@box2.japko.eu>

On Wed, Feb 03, 2016 at 01:35:34PM +0100, Maxime Ripard wrote:
>Hi,
>
>On Tue, Feb 02, 2016 at 10:21:50PM +0100, Krzysztof Adamski wrote:
>> APB0 is bearly mentioned in H3 User Manual and it is only setup in the
>> Allwinners kernel dump for CIR. I have verified experimentally that the
>> gate for R_PIO exists and works, though. There are probably other gates
>> there but I don't know their order right now and I don't have access to
>> their peripherals on my board to test them.
>>
>> Signed-off-by: Krzysztof Adamski <k at japko.eu>
>> ---
>>  arch/arm/boot/dts/sun8i-h3.dtsi | 32 ++++++++++++++++++++++++++++++++
>>  1 file changed, 32 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index 1524130e..ce35e93 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -276,6 +276,32 @@
>>  			clocks = <&osc24M>, <&pll6 1>, <&pll5>;
>>  			clock-output-names = "mbus";
>>  		};
>> +
>> +		ahb0: ahb0_clk {
>> +			compatible = "fixed-factor-clock";
>> +			#clock-cells = <0>;
>> +			clock-div = <1>;
>> +			clock-mult = <1>;
>> +			clocks = <&osc24M>, <&osc32k>;
>> +			clock-output-names = "ahb0";
>> +		};
>
>I'm not sure what you mean there. The fixed factor clocks only take a
>single parent, and you provided two.

True, I that's actually some stupid leftover. As mentioned in the commit 
message I didn't really know how the clock tree looks like here so I 
wanted to just pretend it's connectet to osc24M. After some experiments 
I think that 0x01f0140c register does not exist on H3 and I was finally 
(hopefully) able to understand how this clock is set up in Allwinner's 
code. So I changed the clock to factors clock with possible osc32k and 
osc24M parrents. Will send it in v3.


From mw at semihalf.com  Wed Feb  3 14:22:36 2016
From: mw at semihalf.com (Marcin Wojtas)
Date: Wed, 3 Feb 2016 23:22:36 +0100
Subject: [PATCH v2 03/12] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <20160203230224.5ea52f65@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
 <1454524889-9207-4-git-send-email-gregory.clement@free-electrons.com>
 <CAPv3WKdh8D8GYMabALQQW-Z7L+=XhkZw2cXdYpcQ8tF0Rjckag@mail.gmail.com>
 <20160203230224.5ea52f65@free-electrons.com>
Message-ID: <CAPv3WKe6=705iEtsuo0cUtugofiFa_Zt9xydRsgOV+mZ18H-3Q@mail.gmail.com>

I'm sorry, indeed, I was the one to overlook - there was a lot going
on in a thread and I missed it.

Ofer, as you found out that IRQF_SHARED help booting ubuntu - do you
think it's a hack or fix?

Best regards,
Marcin

2016-02-03 23:02 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni at free-electrons.com>:
> Dear Marcin Wojtas,
>
> On Wed, 3 Feb 2016 22:41:15 +0100, Marcin Wojtas wrote:
>> Hi Gregory,
>>
>> > +       port->irq        = irq->start;
>> > +       port->irqflags   = 0;
>>
>> Same request as for v1, which you must have overlooked:
>> port->irqflags = IRQF_SHARED;
>
> Gregory didn't overlook this comment you made on v1, he even replied to
> it. Please check Gregory's reply to your review.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com


From labbott at redhat.com  Wed Feb  3 14:30:09 2016
From: labbott at redhat.com (Laura Abbott)
Date: Wed, 3 Feb 2016 14:30:09 -0800
Subject: [PATCH] mm/debug-pagealloc: add missing debug_pagealloc_enabled
In-Reply-To: <1454537757-3760706-1-git-send-email-arnd@arndb.de>
References: <1454537757-3760706-1-git-send-email-arnd@arndb.de>
Message-ID: <56B27F71.2000700@redhat.com>

On 02/03/2016 02:15 PM, Arnd Bergmann wrote:
> The change to move the pagealloc logic broke the slab allocator
> check when it's disabled at compile time:
>
> mm/slab.c: In function 'is_debug_pagealloc_cache':
> mm/slab.c:1608:29: error: implicit declaration of function 'debug_pagealloc_enabled' [-Werror=implicit-function-declaration]
>
> This adds an inline helper to get it to work again.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 0a244aea1a61 ("mm/slab: clean up DEBUG_PAGEALLOC processing code")
> ---
>   include/linux/mm.h | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 5d86eb2e8584..90d600ce56ad 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2242,6 +2242,7 @@ kernel_map_pages(struct page *page, int numpages, int enable)
>   extern bool kernel_page_present(struct page *page);
>   #endif /* CONFIG_HIBERNATION */
>   #else
> +static inline bool debug_pagealloc_enabled(void) { return 0; }
>   static inline void
>   kernel_map_pages(struct page *page, int numpages, int enable) {}
>   #ifdef CONFIG_HIBERNATION
>

I believe this should be fixed with http://article.gmane.org/gmane.linux.kernel.mm/145655


From tchalamarla at caviumnetworks.com  Wed Feb  3 14:37:45 2016
From: tchalamarla at caviumnetworks.com (tchalamarla at caviumnetworks.com)
Date: Wed, 3 Feb 2016 14:37:45 -0800
Subject: [PATCH] AHCI: Workaround for ThunderX Errata#22536
Message-ID: <1454539065-16891-1-git-send-email-tchalamarla@caviumnetworks.com>

From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>

Due to Errata in some versions of ThunderX,
HOST_IRQ_STAT is neither EDGE nor LEVEL,
ThunderX needs a special sequence for handling interrupt.
The patch attempts to satisfy the need.

Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
---
 drivers/ata/ahci.c    |  3 +++
 drivers/ata/ahci.h    |  4 ++++
 drivers/ata/libahci.c | 52 +++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 59 insertions(+)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 594fcab..6416af7 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1534,6 +1534,9 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 	if (ahci_sb600_enable_64bit(pdev))
 		hpriv->flags &= ~AHCI_HFLAG_32BIT_ONLY;
 
+	if (pdev->vendor == 0x177d && pdev->device == 0xa01c)
+		hpriv->flags |= AHCI_HFLAG_CAVIUM_ERRATA_22536;
+
 	hpriv->mmio = pcim_iomap_table(pdev)[ahci_pci_bar];
 
 	/* must set flag prior to save config in order to take effect */
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index a44c75d..50b2afd 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -252,6 +252,10 @@ enum {
 #endif
 	AHCI_HFLAG_WAKE_BEFORE_STOP	= (1 << 22), /* wake before DMA stop */
 
+	AHCI_HFLAG_CAVIUM_ERRATA_22536	= (1 << 23), /* Thunder HOST_IRQ_STAT
+						      *	is not Level or EDGE
+						      */
+
 	/* ap->flags bits */
 
 	AHCI_FLAG_COMMON		= ATA_FLAG_SATA | ATA_FLAG_PIO_DMA |
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index 4029679..e186482 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -1952,6 +1952,55 @@ static irqreturn_t ahci_single_level_irq_intr(int irq, void *dev_instance)
 	return IRQ_RETVAL(rc);
 }
 
+
+static irqreturn_t ahci_level_irq_with_errata(int irq, void *dev_instance)
+{
+	struct ata_host *host = dev_instance;
+	struct ahci_host_priv *hpriv;
+	unsigned int rc = 0;
+	void __iomem *mmio;
+	u32 irq_stat, irq_masked;
+	unsigned int handled = 1;
+
+	VPRINTK("ENTER\n");
+
+	hpriv = host->private_data;
+	mmio = hpriv->mmio;
+
+	/* sigh.  0xffffffff is a valid return from h/w */
+	irq_stat = readl(mmio + HOST_IRQ_STAT);
+	if (!irq_stat)
+		return IRQ_NONE;
+redo:
+
+	irq_masked = irq_stat & hpriv->port_map;
+
+	spin_lock(&host->lock);
+
+	rc = ahci_handle_port_intr(host, irq_masked);
+
+	if (!rc)
+		handled = 0;
+
+	writel(irq_stat, mmio + HOST_IRQ_STAT);
+
+	/* Due to ERRATA#22536, ThunderX need to handle
+	 * HOST_IRQ_STAT differently.
+	 * Work around is to make sure all pending IRQs
+	 * are served before leaving handler
+	 */
+	irq_stat = readl(mmio + HOST_IRQ_STAT);
+
+	spin_unlock(&host->lock);
+
+	if (irq_stat)
+		goto redo;
+
+	VPRINTK("EXIT\n");
+
+	return IRQ_RETVAL(handled);
+}
+
 unsigned int ahci_qc_issue(struct ata_queued_cmd *qc)
 {
 	struct ata_port *ap = qc->ap;
@@ -2540,6 +2589,9 @@ int ahci_host_activate(struct ata_host *host, struct scsi_host_template *sht)
 	else if (hpriv->flags & AHCI_HFLAG_EDGE_IRQ)
 		rc = ata_host_activate(host, irq, ahci_single_edge_irq_intr,
 				       IRQF_SHARED, sht);
+	else if (hpriv->flags & AHCI_HFLAG_CAVIUM_ERRATA_22536)
+		rc = ata_host_activate(host, irq, ahci_level_irq_with_errata,
+					IRQF_SHARED, sht);
 	else
 		rc = ata_host_activate(host, irq, ahci_single_level_irq_intr,
 				       IRQF_SHARED, sht);
-- 
2.1.0



From marcel.ziswiler at toradex.com  Wed Feb  3 14:46:18 2016
From: marcel.ziswiler at toradex.com (Marcel Ziswiler)
Date: Wed, 3 Feb 2016 22:46:18 +0000
Subject: [PATCH v4 1/2] ARM: dts: imx6: Add support for Toradex Apalis
 iMX6Q/D SoM
In-Reply-To: <20160125094628.GH27359@ibawizard.net>
References: <1453675703-31594-1-git-send-email-marcel.ziswiler@toradex.com>
 <1453675703-31594-2-git-send-email-marcel.ziswiler@toradex.com>
 <20160125094628.GH27359@ibawizard.net>
Message-ID: <1454539575.11389.5.camel@toradex.com>

Hi Petr

On Mon, 2016-01-25 at 10:46 +0100, Petr ?tetiar wrote:

[snip]

> What problems are you having if you remove that parent regulators
> node?

To be honest I don't remember the exact issues it caused. I just tried
again now with latest?next-20160203 and besides slab being broken it
worked like a charm. So finally rid of it I got (;-p).

> 1. http://lists.infradead.org/pipermail/linux-arm-kernel/2015-Novembe
> r/386456.html
> 2. https://raw.githubusercontent.com/ynezz/linux-2.6/5a211784544a3a46
> 0df7e7e45479010ae3feaf76/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> 3. git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
> 
> Thanks for your work!

You are very welcome.

> -- ynezz

Cheers

Marcel

From arnd at arndb.de  Wed Feb  3 14:51:17 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 03 Feb 2016 23:51:17 +0100
Subject: [PATCH] mm/debug-pagealloc: add missing debug_pagealloc_enabled
In-Reply-To: <56B27F71.2000700@redhat.com>
References: <1454537757-3760706-1-git-send-email-arnd@arndb.de>
 <56B27F71.2000700@redhat.com>
Message-ID: <1715666.B0erB7v9pc@wuerfel>

On Wednesday 03 February 2016 14:30:09 Laura Abbott wrote:
> On 02/03/2016 02:15 PM, Arnd Bergmann wrote:
> > The change to move the pagealloc logic broke the slab allocator
> > check when it's disabled at compile time:
> >
> > mm/slab.c: In function 'is_debug_pagealloc_cache':
> > mm/slab.c:1608:29: error: implicit declaration of function 'debug_pagealloc_enabled' [-Werror=implicit-function-declaration]
> >
> > This adds an inline helper to get it to work again.
> >
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > Fixes: 0a244aea1a61 ("mm/slab: clean up DEBUG_PAGEALLOC processing code")
> > ---
> >   include/linux/mm.h | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 5d86eb2e8584..90d600ce56ad 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -2242,6 +2242,7 @@ kernel_map_pages(struct page *page, int numpages, int enable)
> >   extern bool kernel_page_present(struct page *page);
> >   #endif /* CONFIG_HIBERNATION */
> >   #else
> > +static inline bool debug_pagealloc_enabled(void) { return 0; }
> >   static inline void
> >   kernel_map_pages(struct page *page, int numpages, int enable) {}
> >   #ifdef CONFIG_HIBERNATION
> >
> 
> I believe this should be fixed with http://article.gmane.org/gmane.linux.kernel.mm/145655

Yes, Christian's version looks nicer too (correct return type).

Thanks,

	Arnd


From marcel.ziswiler at toradex.com  Wed Feb  3 14:55:18 2016
From: marcel.ziswiler at toradex.com (Marcel Ziswiler)
Date: Wed, 3 Feb 2016 22:55:18 +0000
Subject: [PATCH v4 1/2] ARM: dts: imx6: Add support for Toradex Apalis
 iMX6Q/D SoM
In-Reply-To: <20160201132916.GF10671@tiger>
References: <1453675703-31594-1-git-send-email-marcel.ziswiler@toradex.com>
 <1453675703-31594-2-git-send-email-marcel.ziswiler@toradex.com>
 <20160201132916.GF10671@tiger>
Message-ID: <1454540116.11389.11.camel@toradex.com>

On Mon, 2016-02-01 at 21:29 +0800, Shawn Guo wrote:

[snip]

> +	/* STMPE811 touch screen controller */
> > +	stmpe811 at 41 {
> > +		compatible = "st,stmpe811";
> 
> The compatible seems to be used by kernel without a binding document.

Indeed and looking at git logs Linus himself introduced it (;-p):

commit 5a826feedc331a2d5ced2afd832199a70b3af891
Author: Linus Walleij <linus.walleij at linaro.org>
Date:???Wed Apr 23 23:35:58 2014 +0200
Subject: mfd: stmpe: Probe properly from the Device Tree

From fu.wei at linaro.org  Wed Feb  3 15:00:32 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Thu, 4 Feb 2016 07:00:32 +0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <56B24AB5.3070001@codeaurora.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
Message-ID: <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>

On 4 February 2016 at 02:45, Timur Tabi <timur at codeaurora.org> wrote:
> Fu Wei wrote:
>>
>> As you know I have made the pre-timeout support patch, If people like
>> it, i am happy to go on upstream it separately.
>>
>> If we want to use pre-timeout here, user only can use get_pretimeout
>> and disable panic by setting pretimeout to 0
>> but user can not really set pretimeout, because "pre-timeout  ==
>> timeout / 2 (always)".
>> if user want to change pretimeout, he/she has to set_time instead.
>
>
> Ok, I think patches 4 and 5 should be combined, and I think the Kconfig
> entry should be removed and just use panic_enabled.

NP, will update this patchset like that ,  thanks :-)


-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From marcel.ziswiler at toradex.com  Wed Feb  3 15:02:22 2016
From: marcel.ziswiler at toradex.com (Marcel Ziswiler)
Date: Wed, 3 Feb 2016 23:02:22 +0000
Subject: [PATCH v4 1/2] ARM: dts: imx6: Add support for Toradex Apalis
 iMX6Q/D SoM
In-Reply-To: <1454540116.11389.11.camel@toradex.com>
References: <1453675703-31594-1-git-send-email-marcel.ziswiler@toradex.com>
 <1453675703-31594-2-git-send-email-marcel.ziswiler@toradex.com>
 <20160201132916.GF10671@tiger> <1454540116.11389.11.camel@toradex.com>
Message-ID: <1454540539.11389.14.camel@toradex.com>

On Wed, 2016-02-03 at 23:55 +0100, Marcel Ziswiler wrote:
> On Mon, 2016-02-01 at 21:29 +0800, Shawn Guo wrote:
> 
> [snip]
> 
> > +	/* STMPE811 touch screen controller */
> > > +	stmpe811 at 41 {
> > > +		compatible = "st,stmpe811";
> > 
> > The compatible seems to be used by kernel without a binding
> > document.
> 
> Indeed and looking at git logs Linus himself introduced it (;-p):
> 
> commit 5a826feedc331a2d5ced2afd832199a70b3af891
> Author: Linus Walleij <linus.walleij at linaro.org>
> Date:???Wed Apr 23 23:35:58 2014 +0200
> Subject: mfd: stmpe: Probe properly from the Device Tree

Looking more closely there is actually a proper binding document which
got added by Lee Jones:

commit 84e6de813b2d1bdb127943d3c8edf1c1afaa90da
Author: Lee Jones <lee.jones at linaro.org>
Date:???Mon Nov 5 16:10:34 2012 +0100
Subject: Documentation: Describe bindings for STMPE Multi-Functional
Device driver

Documentation/devicetree/bindings/mfd/stmpe.txt

Required properties:
?- compatible???????????????????: "st,stmpe[811|1601|2401|2403]"

Sorry for the noise.

From marcel.ziswiler at toradex.com  Wed Feb  3 15:26:23 2016
From: marcel.ziswiler at toradex.com (Marcel Ziswiler)
Date: Wed, 3 Feb 2016 23:26:23 +0000
Subject: [PATCH v4 1/2] ARM: dts: imx6: Add support for Toradex Apalis
 iMX6Q/D SoM
In-Reply-To: <20160201132916.GF10671@tiger>
References: <1453675703-31594-1-git-send-email-marcel.ziswiler@toradex.com>
 <1453675703-31594-2-git-send-email-marcel.ziswiler@toradex.com>
 <20160201132916.GF10671@tiger>
Message-ID: <1454541981.11389.17.camel@toradex.com>

On Mon, 2016-02-01 at 21:29 +0800, Shawn Guo wrote:

[snip]

> > +		stmpe_touchscreen {
> 
> Shouldn't the node name be generic as just touchscreen???Or at least,
> hyphen instead of underscore should be used in node name.

This one is actually as per binding document example:

Documentation/devicetree/bindings/input/touchscreen/stmpe.txt:

Example:

????????stmpe_touchscreen {

[snip]

From k at japko.eu  Wed Feb  3 15:33:47 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Thu,  4 Feb 2016 00:33:47 +0100
Subject: [PATCH v3 2/5] dts: sun8i-h3: Add APB0 related clocks and resets
In-Reply-To: <1454542430-16572-1-git-send-email-k@japko.eu>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
Message-ID: <1454542430-16572-3-git-send-email-k@japko.eu>

APB0 is bearly mentioned in H3 User Manual and it is only setup in the
Allwinners kernel dump for CIR. I have verified experimentally that the
gate for R_PIO exists and works, though. There are probably other gates
there but I don't know their order right now and I don't have access to
their peripherals on my board to test them.

After some experiments and reviewing how this is organized on other
sunxi SoCs, I couldn't actually find any way to disable clocks for R_PIO
and they are working properly without doing anything so I assume they
are connected straight to the 24Mhz oscillator for now.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 1524130e..bb37f52 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -276,6 +276,24 @@
 			clocks = <&osc24M>, <&pll6 1>, <&pll5>;
 			clock-output-names = "mbus";
 		};
+
+		apb0: apb0_clk {
+			compatible = "fixed-factor-clock";
+			#clock-cells = <0>;
+			clock-div = <1>;
+			clock-mult = <1>;
+			clocks = <&osc24M>;
+			clock-output-names = "apb0";
+		};
+
+		apb0_gates: clk at 01f01428 {
+			compatible = "allwinner,sun8i-h3-apb0-gates-clk";
+			reg = <0x01f01428 0x4>;
+			#clock-cells = <1>;
+			clocks = <&apb0>;
+			clock-indices = <0>, <1>;
+			clock-output-names = "apb0_pio", "apb0_ir";
+		};
 	};
 
 	soc {
@@ -493,5 +511,11 @@
 			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
 		};
+
+		apb0_reset: reset at 01f014b0 {
+			reg = <0x01f014b0 0x4>;
+			compatible = "allwinner,sun6i-a31-clock-reset";
+			#reset-cells = <1>;
+		};
 	};
 };
-- 
2.1.4



From k at japko.eu  Wed Feb  3 15:33:45 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Thu,  4 Feb 2016 00:33:45 +0100
Subject: [PATCH v3 0/5] pinctrl: sunxi: Add H3 R_PIO controller support 
Message-ID: <1454542430-16572-1-git-send-email-k@japko.eu>

This patch series is extension of my original single patch with the same
subject. It adds support for R_PIO so that GPIO port L can be used in H3
based devices. It was tested on OrangePi PC where PL is connected amount
others to an onboard led, a switch, an IR receiver and some VCC
controllers.

Patchset is based on next-20160129.

--- 

Changes since v2:
- fixed apb0 parrent clocks list
- moved binding documentation change to the proper patch
- simplified sunxi_pinctrl_gpio_get according to ChenYu suggestions
- fixed ordering in sunxi binding documentation

Changes since v1:
- splited patch to two separate - dtsi and c files
- added APB0 clocks a parent for R_PIO
- added fix in sunxi_pinctrl_gpio_get for getting pin value when in irq
  mode and on 2nd pinctrl
- fixed a "pwn" > "pwm" typo
- fixed order in allwinner,sunxi-pinctrl.txt


Krzysztof Adamski (5):
  clk: sunxi: Add apb0 gates for H3
  dts: sun8i-h3: Add APB0 related clocks and resets
  pinctrl: sunxi: Add H3 R_PIO controller support
  ARM: dts: sun8i-h3: Add R_PIO controller node to the dtsi
  pinctrl: sunxi: Use pin number when calling sunxi_pmx_set

 Documentation/devicetree/bindings/clock/sunxi.txt  |   1 +
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 arch/arm/boot/dts/sun8i-h3.dtsi                    |  36 +++++++
 drivers/clk/sunxi/clk-simple-gates.c               |   2 +
 drivers/pinctrl/sunxi/Kconfig                      |   4 +
 drivers/pinctrl/sunxi/Makefile                     |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c         | 106 +++++++++++++++++++++
 drivers/pinctrl/sunxi/pinctrl-sunxi.c              |   5 +-
 8 files changed, 154 insertions(+), 2 deletions(-)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c

-- 
2.1.4



From k at japko.eu  Wed Feb  3 15:33:46 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Thu,  4 Feb 2016 00:33:46 +0100
Subject: [PATCH v3 1/5] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <1454542430-16572-1-git-send-email-k@japko.eu>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
Message-ID: <1454542430-16572-2-git-send-email-k@japko.eu>

This patch adds support for APB0 in H3. It seems to be compatible with
earlier SOCs. apb0 gates controls R_ block peripherals (R_PIO, R_IR,
etc).

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
 drivers/clk/sunxi/clk-simple-gates.c              | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index e59f57b..751c8b9f0 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -45,6 +45,7 @@ Required properties:
 	"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
 	"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
 	"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
+	"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
 	"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
 	"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
 	"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
diff --git a/drivers/clk/sunxi/clk-simple-gates.c b/drivers/clk/sunxi/clk-simple-gates.c
index f4da52b..6753c87 100644
--- a/drivers/clk/sunxi/clk-simple-gates.c
+++ b/drivers/clk/sunxi/clk-simple-gates.c
@@ -130,6 +130,8 @@ CLK_OF_DECLARE(sun8i_a23_apb2, "allwinner,sun8i-a23-apb2-gates-clk",
 	       sunxi_simple_gates_init);
 CLK_OF_DECLARE(sun8i_a33_ahb1, "allwinner,sun8i-a33-ahb1-gates-clk",
 	       sunxi_simple_gates_init);
+CLK_OF_DECLARE(sun8i_h3_apb0, "allwinner,sun8i-h3-apb0-gates-clk",
+	       sunxi_simple_gates_init);
 CLK_OF_DECLARE(sun9i_a80_ahb0, "allwinner,sun9i-a80-ahb0-gates-clk",
 	       sunxi_simple_gates_init);
 CLK_OF_DECLARE(sun9i_a80_ahb1, "allwinner,sun9i-a80-ahb1-gates-clk",
-- 
2.1.4



From k at japko.eu  Wed Feb  3 15:33:49 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Thu,  4 Feb 2016 00:33:49 +0100
Subject: [PATCH v3 4/5] ARM: dts: sun8i-h3: Add R_PIO controller node to the
 dtsi
In-Reply-To: <1454542430-16572-1-git-send-email-k@japko.eu>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
Message-ID: <1454542430-16572-5-git-send-email-k@japko.eu>

Add the corresponding device node for R_PIO on H3 to the dtsi. Support
for the controller was added in earlier commit.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index bb37f52..f618a95 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -517,5 +517,17 @@
 			compatible = "allwinner,sun6i-a31-clock-reset";
 			#reset-cells = <1>;
 		};
+
+		r_pio: pinctrl at 01f02c00 {
+			compatible = "allwinner,sun8i-h3-r-pinctrl";
+			reg = <0x01f02c00 0x400>;
+			interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&apb0_gates 0>;
+			resets = <&apb0_reset 0>;
+			gpio-controller;
+			#gpio-cells = <3>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
 	};
 };
-- 
2.1.4



From k at japko.eu  Wed Feb  3 15:33:48 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Thu,  4 Feb 2016 00:33:48 +0100
Subject: [PATCH v3 3/5] pinctrl: sunxi: Add H3 R_PIO controller support
In-Reply-To: <1454542430-16572-1-git-send-email-k@japko.eu>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
Message-ID: <1454542430-16572-4-git-send-email-k@japko.eu>

H3 has additional PIO controller similar to what we can find on A23.
It's a 12 pin port, described in H3 Datasheet rev 1.1, pages 345-350.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 drivers/pinctrl/sunxi/Kconfig                      |   4 +
 drivers/pinctrl/sunxi/Makefile                     |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c         | 106 +++++++++++++++++++++
 4 files changed, 112 insertions(+)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c

diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index 9213b27..3e56b16 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -21,6 +21,7 @@ Required properties:
   "allwinner,sun9i-a80-r-pinctrl"
   "allwinner,sun8i-a83t-pinctrl"
   "allwinner,sun8i-h3-pinctrl"
+  "allwinner,sun8i-h3-r-pinctrl"
 
 - reg: Should contain the register physical address and length for the
   pin controller.
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index f8dbc8b..75a26c9 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -55,6 +55,10 @@ config PINCTRL_SUN8I_H3
 	def_bool MACH_SUN8I
 	select PINCTRL_SUNXI_COMMON
 
+config PINCTRL_SUN8I_H3_R
+	def_bool MACH_SUN8I
+	select PINCTRL_SUNXI_COMMON
+
 config PINCTRL_SUN9I_A80
 	def_bool MACH_SUN9I
 	select PINCTRL_SUNXI_COMMON
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index ef82f22..a5d56f1 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -14,5 +14,6 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23_R)	+= pinctrl-sun8i-a23-r.o
 obj-$(CONFIG_PINCTRL_SUN8I_A33)		+= pinctrl-sun8i-a33.o
 obj-$(CONFIG_PINCTRL_SUN8I_A83T)	+= pinctrl-sun8i-a83t.o
 obj-$(CONFIG_PINCTRL_SUN8I_H3)		+= pinctrl-sun8i-h3.o
+obj-$(CONFIG_PINCTRL_SUN8I_H3_R)	+= pinctrl-sun8i-h3-r.o
 obj-$(CONFIG_PINCTRL_SUN9I_A80)		+= pinctrl-sun9i-a80.o
 obj-$(CONFIG_PINCTRL_SUN9I_A80_R)	+= pinctrl-sun9i-a80-r.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
new file mode 100644
index 0000000..686ec21
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
@@ -0,0 +1,106 @@
+/*
+ * Allwinner H3 SoCs pinctrl driver.
+ *
+ * Copyright (C) 2016 Krzysztof Adamski <k at japko.eu>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/pinctrl.h>
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin sun8i_h3_r_pins[] = {
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_twi"),         /* SCK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),	/* PL_EINT0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_twi"),         /* SDA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),	/* PL_EINT1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_uart"),        /* TX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),	/* PL_EINT2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_uart"),        /* RX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),	/* PL_EINT3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* MS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),	/* PL_EINT4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* CK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),	/* PL_EINT5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* DO */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),	/* PL_EINT6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* DI */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),	/* PL_EINT7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),	/* PL_EINT8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),	/* PL_EINT9 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_pwm"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)),	/* PL_EINT10 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_cir_rx"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 11)),	/* PL_EINT11 */
+};
+
+static const struct sunxi_pinctrl_desc sun8i_h3_r_pinctrl_data = {
+	.pins = sun8i_h3_r_pins,
+	.npins = ARRAY_SIZE(sun8i_h3_r_pins),
+	.irq_banks = 1,
+	.pin_base = PL_BASE,
+	.irq_read_needs_mux = true
+};
+
+static int sun8i_h3_r_pinctrl_probe(struct platform_device *pdev)
+{
+	return sunxi_pinctrl_init(pdev,
+				  &sun8i_h3_r_pinctrl_data);
+}
+
+static const struct of_device_id sun8i_h3_r_pinctrl_match[] = {
+	{ .compatible = "allwinner,sun8i-h3-r-pinctrl", },
+	{}
+};
+
+static struct platform_driver sun8i_h3_r_pinctrl_driver = {
+	.probe	= sun8i_h3_r_pinctrl_probe,
+	.driver	= {
+		.name		= "sun8i-h3-r-pinctrl",
+		.of_match_table	= sun8i_h3_r_pinctrl_match,
+	},
+};
+builtin_platform_driver(sun8i_h3_r_pinctrl_driver);
-- 
2.1.4



From k at japko.eu  Wed Feb  3 15:33:50 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Thu,  4 Feb 2016 00:33:50 +0100
Subject: [PATCH v3 5/5] pinctrl: sunxi: Use pin number when calling
 sunxi_pmx_set
In-Reply-To: <1454542430-16572-1-git-send-email-k@japko.eu>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
Message-ID: <1454542430-16572-6-git-send-email-k@japko.eu>

sunxi_pmx_set accepts pin number and then calculates offset by
subtracting pin_base from it. sunxi_pinctrl_gpio_get, on the other hand,
gets offset so we have to convert it to pin number so we won't get
negative value in sunxi_pmx_set.

This was only used on A10 so far, where there is only one GPIO chip with
pin_base set to 0 so it didn't matter. However H3 also requires this
workaround but have two pinmux sections, triggering problem for PL port.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 drivers/pinctrl/sunxi/pinctrl-sunxi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 7a2465f..96f64a1 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -459,15 +459,16 @@ static int sunxi_pinctrl_gpio_get(struct gpio_chip *chip, unsigned offset)
 	u8 index = sunxi_data_offset(offset);
 	u32 set_mux = pctl->desc->irq_read_needs_mux &&
 			test_bit(FLAG_USED_AS_IRQ, &chip->desc[offset].flags);
+	u32 pin = offset + chip->base;
 	u32 val;
 
 	if (set_mux)
-		sunxi_pmx_set(pctl->pctl_dev, offset, SUN4I_FUNC_INPUT);
+		sunxi_pmx_set(pctl->pctl_dev, pin, SUN4I_FUNC_INPUT);
 
 	val = (readl(pctl->membase + reg) >> index) & DATA_PINS_MASK;
 
 	if (set_mux)
-		sunxi_pmx_set(pctl->pctl_dev, offset, SUN4I_FUNC_IRQ);
+		sunxi_pmx_set(pctl->pctl_dev, pin, SUN4I_FUNC_IRQ);
 
 	return !!val;
 }
-- 
2.1.4



From k at japko.eu  Wed Feb  3 15:44:04 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Thu, 4 Feb 2016 00:44:04 +0100
Subject: [PATCH v2 2/5] dts: sun8i-h3: Add APB0 related clocks and resets
In-Reply-To: <20160203222117.GA12071@box2.japko.eu>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
 <1454448113-18810-3-git-send-email-k@japko.eu>
 <20160203123534.GG4652@lukather>
 <20160203222117.GA12071@box2.japko.eu>
Message-ID: <20160203234403.GB12071@box2.japko.eu>

On Wed, Feb 03, 2016 at 11:21:17PM +0100, Krzysztof Adamski wrote:
>On Wed, Feb 03, 2016 at 01:35:34PM +0100, Maxime Ripard wrote:
>>Hi,
>>
>>I'm not sure what you mean there. The fixed factor clocks only take a
>>single parent, and you provided two.
>
>True, I that's actually some stupid leftover. As mentioned in the 
>commit message I didn't really know how the clock tree looks like here 
>so I wanted to just pretend it's connectet to osc24M. After some 
>experiments I think that 0x01f0140c register does not exist on H3 and 
>I was finally (hopefully) able to understand how this clock is set up 
>in Allwinner's code. So I changed the clock to factors clock with 
>possible osc32k and osc24M parrents. Will send it in v3.

I've changed my mind about using factors clock. The clock I was thinking 
about is only setup for CIR peripheral and I have no information on how 
r_pio is clocked other than the fact it works by default so I assume 
it's clocked from 24M oscillator. New patchset send, let me know what 
you think.


From lkp at intel.com  Wed Feb  3 16:28:53 2016
From: lkp at intel.com (kbuild test robot)
Date: Thu, 4 Feb 2016 08:28:53 +0800
Subject: [PATCH 1/4] net: ethernet: dwmac: add Ethernet glue logic for
 stm32 chip
In-Reply-To: <1454511275-9791-2-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <201602040842.LxCCQ6Q3%fengguang.wu@intel.com>

Hi Alexandre,

[auto build test WARNING on net/master]
[also build test WARNING on v4.5-rc2 next-20160203]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Alexandre-TORGUE/Add-Ethernet-support-on-STM32F429/20160203-225940
config: um-allyesconfig (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=um 

All warnings (new ones prefixed by >>):

warning: (ST_IRQCHIP && HIP04_ETH && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && DWMAC_STM32 && TI_CPSW && PINCTRL_ROCKCHIP && PINCTRL_DOVE && POWER_RESET_KEYSTONE && POWER_RESET_SYSCON && POWER_RESET_SYSCON_POWEROFF && S3C2410_WATCHDOG && VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 17523 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/cb3c4c9a/attachment-0001.obj>

From khilman at baylibre.com  Wed Feb  3 16:53:37 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Wed, 03 Feb 2016 16:53:37 -0800
Subject: [PATCH] ARM: multi_v7_defconfig: enable DW_WATCHDOG
In-Reply-To: <1454518986-25953-1-git-send-email-dinguyen@opensource.altera.com>
 (dinguyen@opensource.altera.com's message of "Wed, 3 Feb 2016 11:03:06
 -0600")
References: <1454518986-25953-1-git-send-email-dinguyen@opensource.altera.com>
Message-ID: <7htwlpb8j2.fsf@baylibre.com>

<dinguyen at opensource.altera.com> writes:

> From: Dinh Nguyen <dinguyen at opensource.altera.com>
>
> The watchdog timer on the SoCFPGA platform is the Synopsys Designware watchdog.
> Enable CONFIG_DW_WATCHDOG for the driver to get built.
>
> Signed-off-by: Dinh Nguyen <dinguyen at opensource.altera.com>

Tested-by: Kevin Hilman <khilman at baylibre.com>

I confirm that this fixes the boot problems I was seeing on my socfpga
board.

Kevin

> ---
>  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 69d6a6d..24ceac2 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -426,6 +426,7 @@ CONFIG_SUNXI_WATCHDOG=y
>  CONFIG_IMX2_WDT=y
>  CONFIG_TEGRA_WATCHDOG=m
>  CONFIG_MESON_WATCHDOG=y
> +CONFIG_DW_WATCHDOG=y
>  CONFIG_DIGICOLOR_WATCHDOG=y
>  CONFIG_MFD_AS3711=y
>  CONFIG_MFD_AS3722=y


From lkp at intel.com  Wed Feb  3 17:34:07 2016
From: lkp at intel.com (kbuild test robot)
Date: Thu, 4 Feb 2016 09:34:07 +0800
Subject: [PATCH 7/8] ARM: dts: rockchip: enable the tsadc for rk3228 evb
In-Reply-To: <1454472767-5767-8-git-send-email-wxt@rock-chips.com>
Message-ID: <201602040923.uH3zLqrT%fengguang.wu@intel.com>

Hi Caesar,

[auto build test ERROR on rockchip/for-next]
[also build test ERROR on v4.5-rc2 next-20160203]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Caesar-Wang/Support-and-fixes-the-rk3228-SoCS-for-thermal/20160203-121829
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git for-next
config: arm-multi_v7_defconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=arm 

Note: the linux-review/Caesar-Wang/Support-and-fixes-the-rk3228-SoCS-for-thermal/20160203-121829 HEAD 661e15b9e9c05d7a350ca8928be2b89e5c36b4d6 builds fine.
      It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> Error: arch/arm/boot/dts/rk3228-evb.dts:64.1-7 Label or path tsadc not found
   FATAL ERROR: Syntax error parsing input tree

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 36561 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/e1d7595f/attachment-0001.obj>

From hzpeterchen at gmail.com  Wed Feb  3 17:59:28 2016
From: hzpeterchen at gmail.com (Peter Chen)
Date: Thu, 4 Feb 2016 09:59:28 +0800
Subject: [PATCH v4 1/1] USB: core: let USB device know device node
In-Reply-To: <1453706679-18948-1-git-send-email-peter.chen@freescale.com>
References: <1453706679-18948-1-git-send-email-peter.chen@freescale.com>
Message-ID: <20160204015928.GA11158@shlinux2>

On Mon, Jan 25, 2016 at 03:24:39PM +0800, Peter Chen wrote:
> Although most of USB devices are hot-plug's, there are still some devices
> are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
> If these kinds of USB devices are multiple functions, and they can supply
> other interfaces like i2c, gpios for other devices, we may need to
> describe these at device tree.
> 
> In this commit, it uses "reg" in dts as physical port number to match
> the phyiscal port number decided by USB core, if they are the same,
> then the device node is for the device we are creating for USB core.
> 
> Signed-off-by: Peter Chen <peter.chen at freescale.com>
> ---
> Changes for v4:
> - The range of "reg" should be 1-31, changing device node address
>   style as in lower case hexadecimal with leading zeroes suppressed
>   [binding doc, usb-device.txt]
> - Improve the example at binding doc, it describes node from the top
>   (the controller)
> - Delete the struct of_node * within struct usb_device
> - Using usb_hcd_find_raw_port_number to get raw port number under root
>   hub port
> 

Hi Alan, Arnd, and others, would you please give Ack for it if you
are OK with this patch? I am not sure if Greg will queue it or not
if no one Acks it, thanks.

Peter

> Changes for v3:
> - typo: s/descirbe/describe/
> 
> Changes for v2:
> - Fix build error reported by kbuild robot, lack of "static" for
>   inline usb_of_get_child_node
> - Fix typo, "devcie_node" -> "device_node"
> - Add kernel-doc for of_node at struct usb_device
> 
> Changes from RFC:
> - Fix the error address for binding doc, and add compatible for binding doc
> - Change get child node API from "usb_of_find_node" to
>   "usb_of_get_child_node"
> - Delete unecessary header files
> - One typo
> 
>  .../devicetree/bindings/usb/usb-device.txt         | 25 ++++++++++++
>  drivers/usb/core/Makefile                          |  2 +-
>  drivers/usb/core/of.c                              | 47 ++++++++++++++++++++++
>  drivers/usb/core/usb.c                             | 14 ++++++-
>  include/linux/usb/of.h                             |  7 ++++
>  5 files changed, 92 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/usb-device.txt
>  create mode 100644 drivers/usb/core/of.c
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt b/Documentation/devicetree/bindings/usb/usb-device.txt
> new file mode 100644
> index 0000000..c702885
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/usb-device.txt
> @@ -0,0 +1,25 @@
> +Generic USB Device Properties
> +
> +Usually, we only use device tree for hard wired USB device.
> +The reference binding doc is from:
> +http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
> +
> +Required properties:
> +- compatible: usbVID,PID
> +- reg: the port number which this device is connecting to, the range
> +  is 1-31.
> +
> +
> +Example:
> +
> +&usb1 {
> +	status = "okay";
> +
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	hub: genesys at 1 {
> +		compatible = "usb05e3,0608";
> +		reg = <0x1>;
> +	};
> +}
> diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> index 2f6f932..9780877 100644
> --- a/drivers/usb/core/Makefile
> +++ b/drivers/usb/core/Makefile
> @@ -5,7 +5,7 @@
>  usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o
>  usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o
>  usbcore-y += devio.o notify.o generic.o quirks.o devices.o
> -usbcore-y += port.o
> +usbcore-y += port.o of.o
>  
>  usbcore-$(CONFIG_PCI)		+= hcd-pci.o
>  usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
> diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
> new file mode 100644
> index 0000000..2289700
> --- /dev/null
> +++ b/drivers/usb/core/of.c
> @@ -0,0 +1,47 @@
> +/*
> + * of.c		The helpers for hcd device tree support
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen <peter.chen at freescale.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  of
> + * the License 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/of.h>
> +
> +/**
> + * usb_of_get_child_node - Find the device node match port number
> + * @parent: the parent device node
> + * @portnum: the port number which device is connecting
> + *
> + * Find the node from device tree according to its port number.
> + *
> + * Return: On success, a pointer to the device node, %NULL on failure.
> + */
> +struct device_node *usb_of_get_child_node(struct device_node *parent,
> +					int portnum)
> +{
> +	struct device_node *node;
> +	u32 port;
> +
> +	for_each_child_of_node(parent, node) {
> +		if (!of_property_read_u32(node, "reg", &port)) {
> +			if (port == portnum)
> +				return node;
> +		}
> +	}
> +
> +	return NULL;
> +}
> +EXPORT_SYMBOL_GPL(usb_of_get_child_node);
> +
> diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> index ebb29ca..25d9770 100644
> --- a/drivers/usb/core/usb.c
> +++ b/drivers/usb/core/usb.c
> @@ -36,6 +36,7 @@
>  #include <linux/mutex.h>
>  #include <linux/workqueue.h>
>  #include <linux/debugfs.h>
> +#include <linux/usb/of.h>
>  
>  #include <asm/io.h>
>  #include <linux/scatterlist.h>
> @@ -508,11 +509,20 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
>  	dev->connect_time = jiffies;
>  	dev->active_duration = -jiffies;
>  #endif
> -	if (root_hub)	/* Root hub always ok [and always wired] */
> +	if (root_hub) {	/* Root hub always ok [and always wired] */
>  		dev->authorized = 1;
> -	else {
> +		dev->dev.of_node = bus->controller->of_node;
> +	} else {
>  		dev->authorized = !!HCD_DEV_AUTHORIZED(usb_hcd);
>  		dev->wusb = usb_bus_is_wusb(bus) ? 1 : 0;
> +
> +		if (dev->dev.parent->parent == bus->controller)
> +			/* device under root hub's port */
> +			port1 = usb_hcd_find_raw_port_number(usb_hcd,
> +				port1);
> +
> +		dev->dev.of_node = usb_of_get_child_node(parent->dev.of_node,
> +				port1);
>  	}
>  	return dev;
>  }
> diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
> index 974bce9..de3237f 100644
> --- a/include/linux/usb/of.h
> +++ b/include/linux/usb/of.h
> @@ -16,6 +16,8 @@ enum usb_dr_mode of_usb_get_dr_mode_by_phy(struct device_node *phy_np);
>  bool of_usb_host_tpl_support(struct device_node *np);
>  int of_usb_update_otg_caps(struct device_node *np,
>  			struct usb_otg_caps *otg_caps);
> +struct device_node *usb_of_get_child_node(struct device_node *parent,
> +			int portnum);
>  #else
>  static inline enum usb_dr_mode
>  of_usb_get_dr_mode_by_phy(struct device_node *phy_np)
> @@ -31,6 +33,11 @@ static inline int of_usb_update_otg_caps(struct device_node *np,
>  {
>  	return 0;
>  }
> +static inline struct device_node *usb_of_get_child_node
> +		(struct device_node *parent, int portnum)
> +{
> +	return NULL;
> +}
>  #endif
>  
>  #if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_SUPPORT)
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen


From sfr at canb.auug.org.au  Wed Feb  3 18:19:59 2016
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Thu, 4 Feb 2016 13:19:59 +1100
Subject: linux-next: build failure after merge of the aio tree
In-Reply-To: <CAMuHMdUy-cqeN8COO4rdpY-mOH+6gth40wB31-edkj8CO5PFCw@mail.gmail.com>
References: <20160112164034.0fe945a7@canb.auug.org.au>
 <20160112163835.GD347@kvack.org>
 <20160127134024.0fababf6@canb.auug.org.au>
 <20160129113056.GP10826@n2100.arm.linux.org.uk>
 <CAMuHMdUy-cqeN8COO4rdpY-mOH+6gth40wB31-edkj8CO5PFCw@mail.gmail.com>
Message-ID: <20160204131959.6695c7bf@canb.auug.org.au>

Hi Benjamin,

On Fri, 29 Jan 2016 13:03:39 +0100 Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>
> On Fri, Jan 29, 2016 at 12:30 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> >> Background: new aio code is adding __get_user() calls referencing 64
> >> bit quantities (__u64 and __s64).  
> >
> > There's lots more architectures which do not support 64-bit get_user()
> > _or_ __get_user(): avr32, blackfin, metag for example, and m68k which
> > has this interesting thing "/* case 8: disabled because gcc-4.1 has a
> > broken typeof \" in its *get_user() implementation.  
> 
> And if you enable it again, you get lots of "warning: cast to pointer from
> integer of different size", like you mentioned.

Any thoughts?  I am still using the version of tha aio tree from
next-20160111.

-- 
Cheers,
Stephen Rothwell


From menghui.lin at mediatek.com  Wed Feb  3 18:42:43 2016
From: menghui.lin at mediatek.com (menghui lin)
Date: Thu, 4 Feb 2016 10:42:43 +0800
Subject: [PATCH V4 2/2] regulator: mt6323: Add support for MT6323 regulator
In-Reply-To: <20160203122952.GF4455@sirena.org.uk>
References: <1453896059-44589-1-git-send-email-blogic@openwrt.org>
 <1453896059-44589-2-git-send-email-blogic@openwrt.org>
 <20160127144105.GQ6042@sirena.org.uk> <56AA5A5C.9080402@openwrt.org>
 <20160128231306.GD4130@sirena.org.uk>
 <1454061134.10861.14.camel@mtksdaap41>
 <20160129112717.GP4130@sirena.org.uk>
 <1454069479.10861.30.camel@mtksdaap41>
 <20160202193839.GX4455@sirena.org.uk>
 <1454477942.31375.32.camel@mtksdaap41>
 <20160203122952.GF4455@sirena.org.uk>
Message-ID: <1454553763.24913.8.camel@mtksdaap41>

On Wed, 2016-02-03 at 12:29 +0000, Mark Brown wrote:
> On Wed, Feb 03, 2016 at 01:39:02PM +0800, menghui lin wrote:
> > On Tue, 2016-02-02 at 19:38 +0000, Mark Brown wrote:
> 
> > > How does the driver know if it needs to change the mode (ie, how can it
> > > tell if the current mode is inadequate) and surely if we can only change
> > > in one direction this isn't terribly useful?
> 
> > I think the datasheet of buck/ldo could provide information about power
> > capability of each mode. The driver should adjust regulator mode per its
> > device's power requirement.
> 
> That's of no help for a consumer driver which doesn't know what
> regulator is supplying it.
> 
> > case 1:
> 
> > We have a USB typeC micro-controller, which has two modes - standby and
> > normal. It requires 1.8V and 3.3V to operate (both powers are always
> > on). The device stays in standby mode when there is no cable in. When
> > cable in, we got an interrupt and change device into normal mode.
> 
> > The standby mode power consumption is quite small, so we would like the
> > change mode of regulator into STANDBY to save more power. And we change
> > into NORMAL when we receive cable-in interrupt.
> 
> This seems like something that we ought to be doing via runtime PM
> anyway which should be going through the suspend mode bindings, though
> that would need some plumbing in.
> 
> > case 2:
> 
> > About buck regulator for CPU, it usually provides PWM mode, PWM/PFM Auto
> > mode, PFM mode. I think it could map to FAST, NORMAL, IDLE mode
> > respectively. Most of time we would use just normal mode. However, we
> > would change regulator into PWM mode time to time to test buck output
> > performance on the tested board.
> 
> That's a test use that doesn't seem a good fit for upstream at all.

Hi Mark,

Thanks for your response.
It seems more work is required for dynamic mode switch.
For MT6323 regulator patch, we would remove mode-switch related code for
now to provide basic regulator support first.



From hongzhou.yang at mediatek.com  Wed Feb  3 19:03:35 2016
From: hongzhou.yang at mediatek.com (Hongzhou Yang)
Date: Wed, 3 Feb 2016 19:03:35 -0800
Subject: [PATCH 1/2] pinctrl: mediatek: fix direction control issue
In-Reply-To: <1454462686-770-2-git-send-email-biao.huang@mediatek.com>
References: <1454462686-770-1-git-send-email-biao.huang@mediatek.com>
 <1454462686-770-2-git-send-email-biao.huang@mediatek.com>
Message-ID: <1454555015.4618.10.camel@mussux00>

On Wed, 2016-02-03 at 09:24 +0800, Biao Huang wrote:
> Since input-enable/disable and input-schmitt-enable/disable are
> workable when gpio direction is input, so add direction setting
> when do input-enable/disable and input-schmitt-enable/disable
> properties.
> 
> Signed-off-by: Biao Huang <biao.huang at mediatek.com>
> ---
>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> index 8cac73d..6eb01c9 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> @@ -352,6 +352,7 @@ static int mtk_pconf_parse_conf(struct pinctrl_dev *pctldev,
>  		ret = mtk_pconf_set_pull_select(pctl, pin, true, false, arg);
>  		break;
>  	case PIN_CONFIG_INPUT_ENABLE:
> +		mtk_pmx_gpio_set_direction(pctldev, NULL, pin, true);
>  		ret = mtk_pconf_set_ies_smt(pctl, pin, arg, param);

Hi Linus,

>From pinctrl-bindings.txt, 'input-enable' property defined as following:
input-enable        - enable input on pin (no effect on output)

Since input enable and input direction are two different settings on our
SOC, could you tell me the exact meaning of this property? Input enable
only? Or set input direction at the same time?

Thanks,
Hongzhou



From oferh at marvell.com  Wed Feb  3 19:22:04 2016
From: oferh at marvell.com (Ofer Heifetz)
Date: Thu, 4 Feb 2016 03:22:04 +0000
Subject: [PATCH v2 03/12] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <CAPv3WKe6=705iEtsuo0cUtugofiFa_Zt9xydRsgOV+mZ18H-3Q@mail.gmail.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
 <1454524889-9207-4-git-send-email-gregory.clement@free-electrons.com>
 <CAPv3WKdh8D8GYMabALQQW-Z7L+=XhkZw2cXdYpcQ8tF0Rjckag@mail.gmail.com>
 <20160203230224.5ea52f65@free-electrons.com>
 <CAPv3WKe6=705iEtsuo0cUtugofiFa_Zt9xydRsgOV+mZ18H-3Q@mail.gmail.com>
Message-ID: <d18a261fae544e27b12a56bebf4a7006@IL-EXCH01.marvell.com>

Hi Marcin,

I think it is a partial fix since once QA started to use this patch and found that /proc/interrupts prints serial interrupt string multiple times which is clobbering the print.

/Ofer


-----Original Message-----
From: Marcin Wojtas [mailto:mw at semihalf.com] 
Sent: Thursday, February 04, 2016 12:23 AM
To: Thomas Petazzoni; Ofer Heifetz
Cc: Gregory CLEMENT; Jason Cooper; Andrew Lunn; Sebastian Hesselbarth; arm at kernel.org; Catalin Marinas; Will Deacon; Jonathan Corbet; Mark Rutland; devicetree at vger.kernel.org; linux-ide at vger.kernel.org; Greg Kroah-Hartman; Omri Itach; linux-kernel at vger.kernel.org; Nadav Haklai; Hans de Goede; Lior Amsalem; linux-serial at vger.kernel.org; Jiri Slaby; Tejun Heo; Wilson Ding; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH v2 03/12] serial: mvebu-uart: initial support for Armada-3700 serial port

I'm sorry, indeed, I was the one to overlook - there was a lot going on in a thread and I missed it.

Ofer, as you found out that IRQF_SHARED help booting ubuntu - do you think it's a hack or fix?

Best regards,
Marcin

2016-02-03 23:02 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni at free-electrons.com>:
> Dear Marcin Wojtas,
>
> On Wed, 3 Feb 2016 22:41:15 +0100, Marcin Wojtas wrote:
>> Hi Gregory,
>>
>> > +       port->irq        = irq->start;
>> > +       port->irqflags   = 0;
>>
>> Same request as for v1, which you must have overlooked:
>> port->irqflags = IRQF_SHARED;
>
> Gregory didn't overlook this comment you made on v1, he even replied 
> to it. Please check Gregory's reply to your review.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering 
> http://free-electrons.com

From viresh.kumar at linaro.org  Wed Feb  3 19:23:07 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 4 Feb 2016 08:53:07 +0530
Subject: Plain DFS (no voltage scaling)
In-Reply-To: <56B244A0.60309@free.fr>
References: <56B11B67.3090600@free.fr> <56B217C9.1050405@free.fr>
 <20160203161331.GI3469@vireshk> <56B244A0.60309@free.fr>
Message-ID: <20160204032307.GP3469@vireshk>

On 03-02-16, 19:19, Mason wrote:
> On 03/02/2016 17:13, Viresh Kumar wrote:
> > On 03-02-16, 16:07, Mason wrote:
> >> On 02/02/2016 22:11, Mason wrote:
> >>
> >>> I plan to enable the on-demand governor on the tango platform:
> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/tango4-smp8758.dtsi
> >>>
> >>> I found the cpufreq-dt binding doc:
> >>>
> >>> https://www.kernel.org/doc/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt
> >>> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt
> >>>
> >>> Something is not clear to me:
> >>>
> >>> If my platform cannot scale the voltage, what information
> >>> should I put in the voltage part of the DT?
> >>
> >> Someone pointed out that tweaking the frequency without tweaking
> >> the voltage might be counter-productive.
> >>
> >> I measured the power consumption of the entire board (at the power outlet)
> >> for 3 CPU frequencies (all other things being equal, I hope).
> >>
> >> idle @ 111 MHz = 4.6 W
> >> idle @ 333 MHz = 4.6 W
> >> idle @ 999 MHz = 4.6 W
> >>
> >> load @ 111 MHz = 5.0 W
> >> load @ 333 MHz = 5.7 W
> >> load @ 999 MHz = 7.7 W
> >>
> >> When idle, the kernel calls WFI, which "turns off" most of the CPU
> >> (clock gating?) such that the actual frequency does not matter.
> >>
> >> At full load (I use cpuburn to jog as many FUs simultaneously as
> >> possible) it looks like each additional MHz requires ~3 mW.
> >>
> >> So it would appear that an on-demand governor might not help to
> >> save power.

IOW, what's so special about how on-demand will behave in your case ?
If it doesn't work properly, then that's the same for everybody, isn't
it ?

> > Why do you say so ?
> 
> Here's my (possibly incorrect) reasoning:
> 
> If the CPU is idle, kernel calls WFI and frequency apparently
> doesn't matter.

Right.

> If the CPU has work to do, the on-demand governor will bump the
> frequency to the max (I think).

Not always, but it will choose the best frequency based on the load.

> I don't think the CPU spends a lot of time in the intermediate
> frequencies (neither max nor min).

It does, it was fixed somewhere in v3.* .

> But maybe my logic is flawed?

Yes.

> Also, some users (of our older kernel) reported problems were
> they considered the on-demand governor was "too slow" to ramp
> the frequency up. (But I don't know if they'd played with the
> configuration knobs.)

Shouldn't be the case anymore, or maybe those guys are more in favor
of the interactive governor :)

-- 
viresh


From viresh.kumar at linaro.org  Wed Feb  3 19:23:53 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 4 Feb 2016 08:53:53 +0530
Subject: Plain DFS (no voltage scaling)
In-Reply-To: <56B24634.6060001@free.fr>
References: <56B11B67.3090600@free.fr> <20160203021052.GK31828@vireshk>
 <56B21E2E.1070606@free.fr> <20160203161428.GJ3469@vireshk>
 <56B24634.6060001@free.fr>
Message-ID: <20160204032353.GQ3469@vireshk>

On 03-02-16, 19:25, Mason wrote:
> The sunxi guys pointed me in the right direction.
> 
> http://lxr.free-electrons.com/source/arch/arm/mach-sunxi/sunxi.c#L20
> 
> Why isn't there a compatible string like other drivers?
> 
> Such as
>   compatible = "cpufreq-dt"
> which would enable cpufreq on the platform?

Because DT can't have nodes for virtual devices :(

-- 
viresh


From alim.akhtar at samsung.com  Wed Feb  3 20:02:14 2016
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Thu, 04 Feb 2016 09:32:14 +0530
Subject: [PATCH v2] arm64: defconfig: Enable samsung MFD and related
 configs
In-Reply-To: <20151106163743.GA7637@e104818-lin.cambridge.arm.com>
References: <1446787654-18306-1-git-send-email-alim.akhtar@samsung.com>
 <CAJKOXPeWerSTi2QedEwyHRVN4xA0vWM2CSOvb5v9SWUmOSPe7Q@mail.gmail.com>
 <20151106163743.GA7637@e104818-lin.cambridge.arm.com>
Message-ID: <56B2CD46.6070607@samsung.com>



On 11/06/2015 10:07 PM, Catalin Marinas wrote:
> On Fri, Nov 06, 2015 at 02:47:12PM +0900, Krzysztof Kozlowski wrote:
>> 2015-11-06 14:27 GMT+09:00 Alim Akhtar <alim.akhtar at samsung.com>:
>>> Exynos7 based espresso board uses S2MPS15, a multifunction device.
>>> This patch enables S2MPS1X regulator, pmic-clk and rtc drivers utilized by
>>> the same.
>>>
>>> Signed-off-by: Alim Akhtar <alim.akhtar at samsung.com>
>>> ---
>>> Changes since v1:
>>> * updated the comment message to describe which platfrom uses it.
>>> * enable COMMON_CLK_S2MPS11 which is needed to enable pmic-clk block.
>>>
>>>   arch/arm64/configs/defconfig |    4 ++++
>>>   1 file changed, 4 insertions(+)
>>
>> Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
>>
>> Catalin,
>>
>> Are you usually taking such arm64 defconfig changes or should they go
>> through arm-soc?
>
> Usually arm-soc but I don't mind either way.
>
Looks like this patch is not merged...because of this 4.5-rc1 on 
exynos7-esspreso does not boot to user space.
Do I need to resend this patch?

Regards,
Alim


From vishnupatekar0510 at gmail.com  Wed Feb  3 20:25:14 2016
From: vishnupatekar0510 at gmail.com (Vishnu Patekar)
Date: Thu, 4 Feb 2016 12:25:14 +0800
Subject: [PATCH 14/14] ARM: dts: sun8i: Add A83T based Sinovoip Bpi-M3
 Board
In-Reply-To: <CAGb2v65BwAcT8920WXt7dBjNx4zjycw2Ea+sNZrm0aM_3JA8pA@mail.gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-15-git-send-email-vishnupatekar0510@gmail.com>
 <CAGb2v65BwAcT8920WXt7dBjNx4zjycw2Ea+sNZrm0aM_3JA8pA@mail.gmail.com>
Message-ID: <CAEzqOZtwyk2oChsSvfxWwqc=bKn3dT0eLDzcgAXi--N0W=cMuA@mail.gmail.com>

Hello Wens,



On Tue, Feb 2, 2016 at 3:37 PM, Chen-Yu Tsai <wens at csie.org> wrote:
>
> On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
> <vishnupatekar0510 at gmail.com> wrote:
> > This patch adds support for Sinovoip BPI-M3 A83T based board.
> >
> > It has 2G LPDDR3, UART, ethernet, USB, HDMI, USB Sata, MIPI DSI,
> > mic, AP6212 Wifi, etc on it.
> > It is paired with AXP813 PMIC which is almost same as AXP818.
> >
> > Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
> > ---
> >  arch/arm/boot/dts/Makefile                       |  1 +
> >  arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts | 88 ++++++++++++++++++++++++
> >  2 files changed, 89 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 58e461a..c0dd016 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -694,6 +694,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> >         sun8i-a33-sinlinx-sina33.dtb \
> >         sun8i-a83t-allwinner-h8homlet-v2.dtb \
> >         sun8i-a83t-cubietruck-plus.dtb \
> > +       sun8i-a83t-sinovoip-bpi-m3.dtb \
> >         sun8i-h3-orangepi-plus.dtb
> >  dtb-$(CONFIG_MACH_SUN9I) += \
> >         sun9i-a80-optimus.dtb \
> > diff --git a/arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts
> > new file mode 100644
> > index 0000000..fecc7dc
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/sun8i-a83t-sinovoip-bpi-m3.dts
> > @@ -0,0 +1,88 @@
> > +/*
> > + * Copyright 2015 Vishnu Patekar
>
> 2016?
>
> > + * Vishnu Patekar <vishnupatekar0510 at gmail.com>
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPL or the X11 license, at your option. Note that this dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + *  a) This file is free software; you can redistribute it and/or
> > + *     modify it under the terms of the GNU General Public License as
> > + *     published by the Free Software Foundation; either version 2 of the
> > + *     License, or (at your option) any later version.
> > + *
> > + *     This file is distributed in the hope that it will be useful,
> > + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + *     GNU General Public License for more details.
> > + *
> > + * Or, alternatively,
> > + *
> > + *  b) Permission is hereby granted, free of charge, to any person
> > + *     obtaining a copy of this software and associated documentation
> > + *     files (the "Software"), to deal in the Software without
> > + *     restriction, including without limitation the rights to use,
> > + *     copy, modify, merge, publish, distribute, sublicense, and/or
> > + *     sell copies of the Software, and to permit persons to whom the
> > + *     Software is furnished to do so, subject to the following
> > + *     conditions:
> > + *
> > + *     The above copyright notice and this permission notice shall be
> > + *     included in all copies or substantial portions of the Software.
> > + *
> > + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> > + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + *     OTHER DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +/dts-v1/;
> > +#include "sun8i-a83t.dtsi"
> > +#include "sunxi-common-regulators.dtsi"
> > +
> > +/ {
> > +       model = "Sinovoip BananaPi M3 v1.2";
> > +       compatible = "sinovoip,bpi-m3", "allwinner,sun8i-a83t";
> > +
> > +       aliases {
> > +               serial0 = &uart0;
> > +       };
> > +
> > +       chosen {
> > +               stdout-path = "serial0:115200n8";
> > +       };
> > +};
> > +
> > +&pio {
> > +       mmc0_cd_pin_bpi_m3: mmc0_cd_pin at 0 {
> > +               allwinner,pins = "PF6";
> > +               allwinner,function = "gpio_in";
> > +               allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> > +               allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> > +       };
>
> Maybe we should just put this in the .dtsi and call it
> "mmc0_cd_pin_reference_design"?
>
> We have something similar for sun4i-a10.
Yes, I'll modify it.
>
> > +};
> > +
> > +&mmc0 {
> > +       pinctrl-names = "default";
> > +       pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_bpi_m3>;
> > +       vmmc-supply = <&reg_vcc3v0>;
> > +       cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> > +       bus-width = <4>;
> > +       cd-inverted;
> > +       status = "okay";
> > +};
> > +
> > +&uart0 {
> > +       pinctrl-names = "default";
> > +       pinctrl-0 = <&uart0_pins_b>;
> > +       status = "okay";
> > +};
> > +
> > +&r_rsb {
>
> This goes before uart0.
Okie.
>
> > +       status = "okay";
> > +};
>
> What about eMMC?
I've not yet tried the emmc.
>
>
> Thanks!
> ChenYu

Regards,
Vishnu


From linux at roeck-us.net  Wed Feb  3 21:17:24 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 3 Feb 2016 21:17:24 -0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
 <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
Message-ID: <56B2DEE4.7060901@roeck-us.net>

On 02/03/2016 03:00 PM, Fu Wei wrote:
> On 4 February 2016 at 02:45, Timur Tabi <timur at codeaurora.org> wrote:
>> Fu Wei wrote:
>>>
>>> As you know I have made the pre-timeout support patch, If people like
>>> it, i am happy to go on upstream it separately.
>>>
>>> If we want to use pre-timeout here, user only can use get_pretimeout
>>> and disable panic by setting pretimeout to 0
>>> but user can not really set pretimeout, because "pre-timeout  ==
>>> timeout / 2 (always)".
>>> if user want to change pretimeout, he/she has to set_time instead.
>>
>>
>> Ok, I think patches 4 and 5 should be combined, and I think the Kconfig
>> entry should be removed and just use panic_enabled.

Agreed.
>
> NP, will update this patchset like that ,  thanks :-)
>

Also, if panic is enabled, the timeout needs to be adjusted accordingly
(to only panic after the entire timeout period has expired, not after
half of it). We can not panic the system after timeout / 2.

I am not too happy with the parameter name (panic_enabled). How about
"action", to match machzwd ?

Thanks,
Guenter



From tony at atomide.com  Wed Feb  3 21:35:18 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 3 Feb 2016 21:35:18 -0800
Subject: N900 sleep mode (in 4.5-rc0, if that matters)
In-Reply-To: <20160201221111.GP19432@atomide.com>
References: <20160123121022.GB12497@amd> <20160125163332.GT19432@atomide.com>
 <20160126140010.GA29723@amd> <20160126172527.GY3500@atomide.com>
 <20160130200244.GA30429@amd> <20160130201452.GC30429@amd>
 <20160130221509.GA28644@amd> <20160201181316.GM19432@atomide.com>
 <20160201211736.GA11283@amd> <20160201221111.GP19432@atomide.com>
Message-ID: <20160204053518.GP19432@atomide.com>

* Tony Lindgren <tony at atomide.com> [160201 14:12]:
> * Pavel Machek <pavel at ucw.cz> [160201 13:18]:
> > 
> > No, sorry, that was with 4.4. As you hit "PM regression with commit
> > 5de85b9d57ab PM runtime re-init in v4.5-rc1", I thought I'd avoid
> > v4.5-rc. 
> 
> OK
> 
> > (I assume I have to insmod and rmmod, right? Because powersave is not
> > entered if I simply compile-out usb).
> 
> Depending on what the bootloader does and probably also if
> USB was used during the booting.. So yeah you may need to modprobe
> and then rmmod.
> 
> > Would you have commit ids for those rmmod fixes? It might be good to
> > push them into stable, and I should try again with them applied...
> 
> 055555fc459 ("usb: musb: core: Fix handling of the phy notifications")
> 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable")

Oh and looks like these two phy-twl4030-phy fixes never got
merged from thread "[PATCH 0/2] Two phy-twl4030-usb fixes for
unloading the module":

phy: twl4030-usb: Relase usb phy on unload
phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload

I'll resend those. But without those again deeper idle states
are blocked.. And it could be that n900 needs similar additional
patches for it's USB PHY as I've tested things so far only with
phy-twl4030-usb PHY based systems.

Regards,

Tony


From mturquette at baylibre.com  Wed Feb  3 21:48:03 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Wed, 03 Feb 2016 21:48:03 -0800
Subject: [PATCH] clk: Deprecate CLK_IS_ROOT
In-Reply-To: <1454463733-25281-1-git-send-email-sboyd@codeaurora.org>
References: <1454463733-25281-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <20160204054803.32018.95106@quark.deferred.io>

Quoting Stephen Boyd (2016-02-02 17:42:13)
> We don't use CLK_IS_ROOT but in a few places in the common clk
> framework core. Let's replace those checks with a check for the
> number of parents a clk has instead of the flag, freeing up one
> flag for something else. We don't remove the flag yet so that
> things keep building, but we'll remove it once all drivers have
> removed their flag usage.
> 
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>

Looks good to me.

Regards,
Mike

> ---
> 
> A bunch of patches to remove CLK_IS_ROOT are coming...
> 
>  drivers/clk/clk.c            | 6 +++---
>  include/linux/clk-provider.h | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index bb01ed6cc63e..cd8382c83f48 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -385,7 +385,7 @@ static unsigned long clk_core_get_rate_nolock(struct clk_core *core)
>  
>         ret = core->rate;
>  
> -       if (core->flags & CLK_IS_ROOT)
> +       if (!core->num_parents)
>                 goto out;
>  
>         if (!core->parent)
> @@ -2351,7 +2351,7 @@ static int __clk_core_init(struct clk_core *core)
>         /*
>          * Populate core->parent if parent has already been __clk_init'd.  If
>          * parent has not yet been __clk_init'd then place clk in the orphan
> -        * list.  If clk has set the CLK_IS_ROOT flag then place it in the root
> +        * list.  If clk doesn't have any parents then place it in the root
>          * clk list.
>          *
>          * Every time a new clk is clk_init'd then we walk the list of orphan
> @@ -2362,7 +2362,7 @@ static int __clk_core_init(struct clk_core *core)
>                 hlist_add_head(&core->child_node,
>                                 &core->parent->children);
>                 core->orphan = core->parent->orphan;
> -       } else if (core->flags & CLK_IS_ROOT) {
> +       } else if (!core->num_parents) {
>                 hlist_add_head(&core->child_node, &clk_root_list);
>                 core->orphan = false;
>         } else {
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index fabe5bedbba6..9c3a18c1a984 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -25,7 +25,7 @@
>  #define CLK_SET_PARENT_GATE    BIT(1) /* must be gated across re-parent */
>  #define CLK_SET_RATE_PARENT    BIT(2) /* propagate rate change up one level */
>  #define CLK_IGNORE_UNUSED      BIT(3) /* do not gate even if unused */
> -#define CLK_IS_ROOT            BIT(4) /* root clk, has no parent */
> +#define CLK_IS_ROOT            BIT(4) /* Deprecated: Don't use */
>  #define CLK_IS_BASIC           BIT(5) /* Basic clk, can't do a to_clk_foo() */
>  #define CLK_GET_RATE_NOCACHE   BIT(6) /* do not use the cached clk rate */
>  #define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate change */
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 


From bharat.kumar.gogada at xilinx.com  Wed Feb  3 21:49:20 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Thu, 4 Feb 2016 05:49:20 +0000
Subject: [PATCH V2 5/5] Microblaze: Modifying microblaze PCI subsytem to
 support  generic Xilinx  AXI PCIe Host Bridge IP driver
In-Reply-To: <20160203163805.GA6112@localhost>
References: <1452620173-4905-1-git-send-email-bharatku@xilinx.com>
 <1452620173-4905-6-git-send-email-bharatku@xilinx.com>
 <20160203163207.GC32546@localhost> <20160203163805.GA6112@localhost>
Message-ID: <8520D5D51A55D047800579B0941471982587F199@XAP-PVEXMBX01.xlnx.xilinx.com>

> Subject: Re: [PATCH V2 5/5] Microblaze: Modifying microblaze PCI subsytem
> to support generic Xilinx AXI PCIe Host Bridge IP driver
> 
> [+cc Ben for real this time]
> 
> On Wed, Feb 03, 2016 at 10:32:07AM -0600, Bjorn Helgaas wrote:
> > [+cc Ben, pcibios_get_phb_of_node() question]
> >
> > On Tue, Jan 12, 2016 at 11:06:13PM +0530, Bharat Kumar Gogada wrote:
> > > This patch does required modifications to microblaze PCI subsystem,
> > > to work with generic driver (drivers/pci/host/pcie-xilinx.c) on
> > > Microblaze and Zynq.
> > >
> > > Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> > > Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com> ...
> >
> > >  resource_size_t pcibios_align_resource(void *data, const struct resource
> *res,
> > >  				resource_size_t size, resource_size_t align)  {
> > > -	struct pci_dev *dev = data;
> > >  	resource_size_t start = res->start;
> > >
> > > -	if (res->flags & IORESOURCE_IO) {
> > > -		if (skip_isa_ioresource_align(dev))
> > > -			return start;
> > > -		if (start & 0x300)
> > > -			start = (start + 0x3ff) & ~0x3ff;
> > > -	}
> > > -
> > >  	return start;
> >
> > "return res->start;" is sufficient; no need for a temporary variable.
> >
Agreed will address in next patch.
> > >  }
> > >  EXPORT_SYMBOL(pcibios_align_resource);
> > >
> > > +int pcibios_add_device(struct pci_dev *dev) {
> > > +	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > > +
> > > +	return 0;
> > > +}
> > > +EXPORT_SYMBOL(pcibios_add_device);
> > > +
> > >  /*
> > >   * Reparent resource children of pr that conflict with res
> > >   * under res, and make res replace those children.
> > > @@ -1335,9 +1308,21 @@ static void
> > > pcibios_setup_phb_resources(struct pci_controller *hose,
> > >
> > >  struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)  {
> > > -	struct pci_controller *hose = bus->sysdata;
> > > +	struct device_node *np;
> > > +
> > > +	for_each_node_by_type(np, "pci") {
> > > +		const void *prop;
> > > +		unsigned int bus_min;
> > > +
> > > +		prop = of_get_property(np, "bus-range", NULL);
> > > +		if (!prop)
> > > +			continue;
> > > +		bus_min = be32_to_cpup(prop);
> > > +		if (bus->number == bus_min)
> > > +			return np;
> > > +	}
> > >
> > > -	return of_node_get(hose->dn);
> > > +	return NULL;
> >
> > Hmmm.  The old microblaze code ("return of_node_get(hose->dn);") is
> > basically the same as the mips and powerpc versions.  The new code is
> > basically the same as the x86 version.
> >
> > I like the generic weak version in drivers/pci/of.c because it doesn't
> > use any arch-specific data, and it looks like if we just set the
> > struct device.of_node members correctly, everything should Just Work.
> >
> > But Ben added both the generic and the x86 versions the same day, so
> > there must be some complication:
> >
> >   98d9f30c820d ("pci/of: Match PCI devices to OF nodes dynamically")
> >   3d5fe5a65af9 ("x86/devicetree: Use generic PCI <-> OF matching")
> >
> > So I guess my question is, why do we need a microblaze-specific
> > version at all?
> >
I did not notice the weak version in /pci/of.c, I have tested with weak version also and it is working.  We might not need this microblaze specific version, but will wait for ben's reply.  

Bharat


From vishnupatekar0510 at gmail.com  Wed Feb  3 22:06:45 2016
From: vishnupatekar0510 at gmail.com (Vishnu Patekar)
Date: Thu, 4 Feb 2016 14:06:45 +0800
Subject: [PATCH 04/14] clk: sunxi: add ahb1 clock for A83T
In-Reply-To: <20160202131725.GQ4652@lukather>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-5-git-send-email-vishnupatekar0510@gmail.com>
 <20160202131725.GQ4652@lukather>
Message-ID: <CAEzqOZuBz2jexvZvvtkvjbE8UtzUMKL9nT5JJ9JcvMPmzEKTcQ@mail.gmail.com>

Hello Maxime,


On Tue, Feb 2, 2016 at 9:17 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> Hi,
>
> On Sun, Jan 31, 2016 at 09:20:56AM +0800, Vishnu Patekar wrote:
>> AHB1 on A83T is similar to ahb1 on A31, except parents are different.
>> clock index 0b1x is PLL6.
>>
>> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
>
> If the clock is the same but the parents are different, then we don't
> need to duplicate all the logic. Simply add the number of parents to
> mux_data, and you're all set.

Problem here is: parent 0b10 for A31 ahb1 is AXI, 0b11 is pll6/pre_div.
0b10 and 0b11 is pll6/pre_div.
So, just adding number of parents to mux_data will not solve problem.

Regards,
Vishnu
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com


From kishon at ti.com  Wed Feb  3 22:31:31 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 4 Feb 2016 12:01:31 +0530
Subject: [PATCH] ARM: DRA7: hwmod: Fix OCP2SCP sysconfig
Message-ID: <1454567491-30499-1-git-send-email-kishon@ti.com>

OCP2SCP doesn't support smart idle wakeup according to
DRA72x_SR1.0_NDA_TRM_vL and DRA75x_DRA74x_SR1.1_NDA_TRM_vW.
Remove SIDLE_SMART_WKUP from the list of supported SIDLE modes
in hwmod data.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 848356e..84c2699 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1482,8 +1482,7 @@ static struct omap_hwmod_class_sysconfig dra7xx_ocp2scp_sysc = {
 	.syss_offs	= 0x0014,
 	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
 			   SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
-	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
-			   SIDLE_SMART_WKUP),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
 	.sysc_fields	= &omap_hwmod_sysc_type1,
 };
 
-- 
1.7.9.5



From kishon at ti.com  Wed Feb  3 22:45:00 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 4 Feb 2016 12:15:00 +0530
Subject: [PATCH] ARM: DRA7: hwmod: Fix OCP2SCP sysconfig
In-Reply-To: <1454567491-30499-1-git-send-email-kishon@ti.com>
References: <1454567491-30499-1-git-send-email-kishon@ti.com>
Message-ID: <56B2F36C.1070406@ti.com>

Hi,

On Thursday 04 February 2016 12:01 PM, Kishon Vijay Abraham I wrote:
> OCP2SCP doesn't support smart idle wakeup according to
> DRA72x_SR1.0_NDA_TRM_vL and DRA75x_DRA74x_SR1.1_NDA_TRM_vW.

Ignore this patch. I'll re-send the patch with a public TRM link.

Thanks
Kishon

> Remove SIDLE_SMART_WKUP from the list of supported SIDLE modes
> in hwmod data.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c |    3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 848356e..84c2699 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1482,8 +1482,7 @@ static struct omap_hwmod_class_sysconfig dra7xx_ocp2scp_sysc = {
>  	.syss_offs	= 0x0014,
>  	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
>  			   SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
> -	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> -			   SIDLE_SMART_WKUP),
> +	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
>  	.sysc_fields	= &omap_hwmod_sysc_type1,
>  };
>  
> 


From yingjoe.chen at mediatek.com  Wed Feb  3 22:54:03 2016
From: yingjoe.chen at mediatek.com (Yingjoe Chen)
Date: Thu, 4 Feb 2016 14:54:03 +0800
Subject: [PATCH v6] i2c: mt8173: add 4GB mode support in i2c driver.
In-Reply-To: <1454347143-31461-1-git-send-email-liguo.zhang@mediatek.com>
References: <1454347143-31461-1-git-send-email-liguo.zhang@mediatek.com>
Message-ID: <1454568843.15541.1.camel@mtksdaap41>

On Tue, 2016-02-02 at 01:19 +0800, Liguo Zhang wrote:
> If 4GB mode is enable, we should add 4gb mode support in i2c driver.
> Set 4GB mode register to support 4GB mode.
> 
> Signed-off-by: Liguo Zhang <liguo.zhang at mediatek.com>
> ---
> change in v6:
> Remove unnecessary init for reg_4g_mode.
> change in v5:
> Use BIT_ULL() to fix kernel building warning.
> change in v4:
> Use BIT_ULL() to fix kernel building warning.
> change in v3:
> Only inline the computation of reg_4g_mode in mtk_i2c_set_4g_mode().
> change in v2:
> Define a static inline function mtk_i2c_set_4g_mode() for support 4g mode.
> ---
>  drivers/i2c/busses/i2c-mt65xx.c | 42 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 42 insertions(+)


Looks good to me, Thanks.

Reviewed-by: Yingjoe Chen <yingjoe.chen at mediatek.com>

Joe.C




From p.fedin at samsung.com  Wed Feb  3 23:36:10 2016
From: p.fedin at samsung.com (Pavel Fedin)
Date: Thu, 04 Feb 2016 10:36:10 +0300
Subject: [PATCH] KVM: arm/arm64: fix reference to uninitialised VGIC
In-Reply-To: <56B23A02.7070804@arm.com>
References: <1454518611-15694-1-git-send-email-andre.przywara@arm.com>
 <56B23A02.7070804@arm.com>
Message-ID: <009701d15f1e$b8398510$28ac8f30$@samsung.com>

 Hello!

> > Fix this by bailing out early of kvm_timer_flush_hwstate() if we don't
> > have a VGIC at all.
> >
> > Reported-by: Cosmin Gorgovan <cosmin at linux-geek.org>
> > Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> > Cc: <stable at vger.kernel.org> # 4.4.x
> 
> Nice catch, thanks.

 Can you check this: http://www.spinics.net/lists/kvm/msg124540.html ? It also should fix this issue. Just omit the very first hunk
from it, if you don't want to apply the whole set.


Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia




From wenyou.yang at atmel.com  Wed Feb  3 23:37:47 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Thu, 4 Feb 2016 15:37:47 +0800
Subject: [PATCH v2 0/4] ARM: at91: pm: add ULP1 mode support
Message-ID: <1454571471-4434-1-git-send-email-wenyou.yang@atmel.com>

The ULP1 (Ultra Low-power mode 1) is introduced by SAMA5D2.

In order to achieve the lowest power consumption, in the ULP1 mode,
all the clocks are shut off, inclusive the embedded 12MHz RC oscillator.

The fast startup signal is used as a wake up source for ULP1 mode.
As soon as the wake up event is asserted, the embedded 12MHz RC
oscillator restarts automatically, which fast startup signal
to trigger the PMC to wake up the system from the ULP1 mode can be
configured via DT.

It is based on the following patch set:
	http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390954.html

Changes in v2:
 - fix label pm_exit to ulp_exit.
 - shorten the pmc-fast-startup property's name.
 - use the value property, instead of bool property for high
   or low triggered.
 - change the property name and property description.

Wenyou Yang (4):
  ARM: at91: pm: create a separate procedure for the ULP0 mode
  ARM: at91: pm: add ULP1 mode support
  ARM: at91: pm: configure PMC fast startup signals
  Documentation: atmel-pmc: add DT bindings for fast startup

 .../devicetree/bindings/arm/atmel-pmc.txt          |   63 ++++++++
 arch/arm/mach-at91/pm.c                            |  131 +++++++++++++++-
 arch/arm/mach-at91/pm.h                            |    7 +
 arch/arm/mach-at91/pm_suspend.S                    |  158 +++++++++++++++++---
 include/linux/clk/at91_pmc.h                       |   36 +++++
 5 files changed, 370 insertions(+), 25 deletions(-)

-- 
1.7.9.5



From wenyou.yang at atmel.com  Wed Feb  3 23:37:48 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Thu, 4 Feb 2016 15:37:48 +0800
Subject: [PATCH v2 1/4] ARM: at91: pm: create a separate procedure for the
 ULP0 mode
In-Reply-To: <1454571471-4434-1-git-send-email-wenyou.yang@atmel.com>
References: <1454571471-4434-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1454571471-4434-2-git-send-email-wenyou.yang@atmel.com>

To make the code more legible and prepare to add the ULP1 mode
support in the future, create a separate procedure for the ULP0 mode.

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---

Changes in v2: None

 arch/arm/mach-at91/pm_suspend.S |   65 ++++++++++++++++++++++++---------------
 1 file changed, 40 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index a25defd..5fcffdc 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -107,7 +107,7 @@ ENTRY(at91_pm_suspend_in_sram)
 
 	ldr	r0, .pm_mode
 	tst	r0, #AT91_PM_SLOW_CLOCK
-	beq	skip_disable_main_clock
+	beq	standby_mode
 
 	ldr	pmc, .pmc_base
 
@@ -131,32 +131,13 @@ ENTRY(at91_pm_suspend_in_sram)
 	orr	tmp1, tmp1, #(1 << 29)		/* bit 29 always set */
 	str	tmp1, [pmc, #AT91_CKGR_PLLAR]
 
-	/* Turn off the main oscillator */
-	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
-	bic	tmp1, tmp1, #AT91_PMC_MOSCEN
-	orr	tmp1, tmp1, #AT91_PMC_KEY
-	str	tmp1, [pmc, #AT91_CKGR_MOR]
-
-skip_disable_main_clock:
-	ldr	pmc, .pmc_base
-
-	/* Wait for interrupt */
-	at91_cpu_idle
-
-	ldr	r0, .pm_mode
-	tst	r0, #AT91_PM_SLOW_CLOCK
-	beq	skip_enable_main_clock
+ulp0_mode:
+	bl	at91_pm_ulp0_mode
+	b	ulp_exit
 
+ulp_exit:
 	ldr	pmc, .pmc_base
 
-	/* Turn on the main oscillator */
-	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
-	orr	tmp1, tmp1, #AT91_PMC_MOSCEN
-	orr	tmp1, tmp1, #AT91_PMC_KEY
-	str	tmp1, [pmc, #AT91_CKGR_MOR]
-
-	wait_moscrdy
-
 	/* Restore PLLA setting */
 	ldr	tmp1, .saved_pllar
 	str	tmp1, [pmc, #AT91_CKGR_PLLAR]
@@ -177,7 +158,15 @@ skip_disable_main_clock:
 
 	wait_mckrdy
 
-skip_enable_main_clock:
+	b	pm_exit
+
+standby_mode:
+	ldr	pmc, .pmc_base
+
+	/* Wait for interrupt */
+	at91_cpu_idle
+
+pm_exit:
 	/* Exit the self-refresh mode */
 	mov	r0, #SRAMC_SELF_FRESH_EXIT
 	bl	at91_sramc_self_refresh
@@ -311,6 +300,32 @@ exit_sramc_sf:
 	mov	pc, lr
 ENDPROC(at91_sramc_self_refresh)
 
+/*
+ * void at91_pm_ulp0_mode(void)
+ */
+ENTRY(at91_pm_ulp0_mode)
+	ldr	pmc, .pmc_base
+
+	/* Turn off the crystal oscillator */
+	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
+	bic	tmp1, tmp1, #AT91_PMC_MOSCEN
+	orr	tmp1, tmp1, #AT91_PMC_KEY
+	str	tmp1, [pmc, #AT91_CKGR_MOR]
+
+	/* Wait for interrupt */
+	at91_cpu_idle
+
+	/* Turn on the crystal oscillator */
+	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
+	orr	tmp1, tmp1, #AT91_PMC_MOSCEN
+	orr	tmp1, tmp1, #AT91_PMC_KEY
+	str	tmp1, [pmc, #AT91_CKGR_MOR]
+
+	wait_moscrdy
+
+	mov	pc, lr
+ENDPROC(at91_pm_ulp0_mode)
+
 .pmc_base:
 	.word 0
 .sramc_base:
-- 
1.7.9.5



From wenyou.yang at atmel.com  Wed Feb  3 23:37:49 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Thu, 4 Feb 2016 15:37:49 +0800
Subject: [PATCH v2 2/4] ARM: at91: pm: add ULP1 mode support
In-Reply-To: <1454571471-4434-1-git-send-email-wenyou.yang@atmel.com>
References: <1454571471-4434-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1454571471-4434-3-git-send-email-wenyou.yang@atmel.com>

The ULP1 (Ultra Low-power mode 1) is introduced by SAMA5D2.

In the ULP1 mode, all the clocks are shut off, inclusive the embedded
12MHz RC oscillator, so as to achieve the lowest power consumption
with the system in retention mode and able to resume on the wake up
events. As soon as the wake up event is asserted, the embedded 12MHz
RC oscillator restarts automatically.

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---

Changes in v2:
 - fix label pm_exit to ulp_exit.

 arch/arm/mach-at91/pm.c         |   16 ++++++-
 arch/arm/mach-at91/pm.h         |    7 +++
 arch/arm/mach-at91/pm_suspend.S |   97 +++++++++++++++++++++++++++++++++++++++
 include/linux/clk/at91_pmc.h    |    4 ++
 4 files changed, 122 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index f82df15..a7aec35 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -36,6 +36,11 @@
 #include "generic.h"
 #include "pm.h"
 
+#define ULP0_MODE	0x00
+#define ULP1_MODE	0x11
+
+#define SAMA5D2_PMC_VERSION	0x20540
+
 void __iomem *pmc;
 
 /*
@@ -52,6 +57,7 @@ extern void at91_pinctrl_gpio_resume(void);
 static struct {
 	unsigned long uhp_udp_mask;
 	int memctrl;
+	u32 ulp_mode;
 } at91_pm_data;
 
 void __iomem *at91_ramc_base[2];
@@ -141,8 +147,11 @@ static void at91_pm_suspend(suspend_state_t state)
 {
 	unsigned int pm_data = at91_pm_data.memctrl;
 
-	pm_data |= (state == PM_SUSPEND_MEM) ?
-				AT91_PM_MODE(AT91_PM_SLOW_CLOCK) : 0;
+	if (state == PM_SUSPEND_MEM) {
+		pm_data |= AT91_PM_MODE(AT91_PM_SLOW_CLOCK);
+		if (at91_pm_data.ulp_mode == ULP1_MODE)
+			pm_data |= AT91_PM_ULP(AT91_PM_ULP1_MODE);
+	}
 
 	flush_cache_all();
 	outer_disable();
@@ -497,4 +506,7 @@ void __init sama5_pm_init(void)
 	at91_pm_data.uhp_udp_mask = AT91SAM926x_PMC_UHP | AT91SAM926x_PMC_UDP;
 	at91_pm_data.memctrl = AT91_MEMCTRL_DDRSDR;
 	at91_pm_init(NULL);
+
+	if (readl(pmc + AT91_PMC_VERSION) >= SAMA5D2_PMC_VERSION)
+		at91_pm_data.ulp_mode = ULP1_MODE;
 }
diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index 3fcf881..2e76745 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -39,4 +39,11 @@ extern void __iomem *at91_ramc_base[];
 
 #define	AT91_PM_SLOW_CLOCK	0x01
 
+#define AT91_PM_ULP_OFFSET	5
+#define AT91_PM_ULP_MASK	0x03
+#define AT91_PM_ULP(x)		(((x) & AT91_PM_ULP_MASK) << AT91_PM_ULP_OFFSET)
+
+#define AT91_PM_ULP0_MODE	0x00
+#define AT91_PM_ULP1_MODE	0x01
+
 #endif
diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 5fcffdc..f2a5c4b 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -41,6 +41,15 @@ tmp2	.req	r5
 	.endm
 
 /*
+ * Wait for main oscillator selection is done
+ */
+	.macro wait_moscsels
+1:	ldr	tmp1, [pmc, #AT91_PMC_SR]
+	tst	tmp1, #AT91_PMC_MOSCSELS
+	beq	1b
+	.endm
+
+/*
  * Wait until PLLA has locked.
  */
 	.macro wait_pllalock
@@ -101,6 +110,10 @@ ENTRY(at91_pm_suspend_in_sram)
 	and	r0, r0, #AT91_PM_MODE_MASK
 	str	r0, .pm_mode
 
+	lsr	r0, r3, #AT91_PM_ULP_OFFSET
+	and	r0, r0, #AT91_PM_ULP_MASK
+	str	r0, .ulp_mode
+
 	/* Active the self-refresh mode */
 	mov	r0, #SRAMC_SELF_FRESH_ACTIVE
 	bl	at91_sramc_self_refresh
@@ -131,6 +144,13 @@ ENTRY(at91_pm_suspend_in_sram)
 	orr	tmp1, tmp1, #(1 << 29)		/* bit 29 always set */
 	str	tmp1, [pmc, #AT91_CKGR_PLLAR]
 
+	ldr	r0, .ulp_mode
+	tst	r0, #AT91_PM_ULP1_MODE
+	beq	ulp0_mode
+
+	bl	at91_pm_ulp1_mode
+	b	ulp_exit
+
 ulp0_mode:
 	bl	at91_pm_ulp0_mode
 	b	ulp_exit
@@ -326,6 +346,81 @@ ENTRY(at91_pm_ulp0_mode)
 	mov	pc, lr
 ENDPROC(at91_pm_ulp0_mode)
 
+/*
+ * void at91_pm_ulp1_mode(void)
+ */
+ENTRY(at91_pm_ulp1_mode)
+	ldr	pmc, .pmc_base
+
+	/* Switch the main clock source to 12-MHz RC oscillator */
+	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
+	bic	tmp1, tmp1, #AT91_PMC_MOSCSEL
+	bic	tmp1, tmp1, #AT91_PMC_KEY_MASK
+	orr	tmp1, tmp1, #AT91_PMC_KEY
+	str	tmp1, [pmc, #AT91_CKGR_MOR]
+
+	wait_moscsels
+
+	/* Disable the crystal oscillator */
+	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
+	bic	tmp1, tmp1, #AT91_PMC_MOSCEN
+	bic	tmp1, tmp1, #AT91_PMC_KEY_MASK
+	orr	tmp1, tmp1, #AT91_PMC_KEY
+	str	tmp1, [pmc, #AT91_CKGR_MOR]
+
+	/* Switch the master clock source to main clock */
+	ldr	tmp1, [pmc, #AT91_PMC_MCKR]
+	bic	tmp1, tmp1, #AT91_PMC_CSS
+	orr	tmp1, tmp1, #AT91_PMC_CSS_MAIN
+	str	tmp1, [pmc, #AT91_PMC_MCKR]
+
+	wait_mckrdy
+
+	/* Enter the ULP1 mode by set WAITMODE bit in CKGR_MOR */
+	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
+	orr	tmp1, tmp1, #AT91_PMC_WAITMODE
+	bic	tmp1, tmp1, #AT91_PMC_KEY_MASK
+	orr	tmp1, tmp1, #AT91_PMC_KEY
+	str	tmp1, [pmc, #AT91_CKGR_MOR]
+
+	wait_mckrdy
+
+	/* Enable the crystal oscillator */
+	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
+	orr	tmp1, tmp1, #AT91_PMC_MOSCEN
+	bic	tmp1, tmp1, #AT91_PMC_KEY_MASK
+	orr	tmp1, tmp1, #AT91_PMC_KEY
+	str	tmp1, [pmc, #AT91_CKGR_MOR]
+
+	wait_moscrdy
+
+	/* Switch the master clock source to slow clock */
+	ldr	tmp1, [pmc, #AT91_PMC_MCKR]
+	bic	tmp1, tmp1, #AT91_PMC_CSS
+	str	tmp1, [pmc, #AT91_PMC_MCKR]
+
+	wait_mckrdy
+
+	/* Switch main clock source to crystal oscillator */
+	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
+	orr	tmp1, tmp1, #AT91_PMC_MOSCSEL
+	bic	tmp1, tmp1, #AT91_PMC_KEY_MASK
+	orr	tmp1, tmp1, #AT91_PMC_KEY
+	str	tmp1, [pmc, #AT91_CKGR_MOR]
+
+	wait_moscsels
+
+	/* Switch the master clock source to main clock */
+	ldr	tmp1, [pmc, #AT91_PMC_MCKR]
+	bic	tmp1, tmp1, #AT91_PMC_CSS
+	orr	tmp1, tmp1, #AT91_PMC_CSS_MAIN
+	str	tmp1, [pmc, #AT91_PMC_MCKR]
+
+	wait_mckrdy
+
+	mov	pc, lr
+ENDPROC(at91_pm_ulp1_mode)
+
 .pmc_base:
 	.word 0
 .sramc_base:
@@ -336,6 +431,8 @@ ENDPROC(at91_pm_ulp0_mode)
 	.word 0
 .pm_mode:
 	.word 0
+.ulp_mode:
+	.word 0
 .saved_mckr:
 	.word 0
 .saved_pllar:
diff --git a/include/linux/clk/at91_pmc.h b/include/linux/clk/at91_pmc.h
index 17f413b..4afd891 100644
--- a/include/linux/clk/at91_pmc.h
+++ b/include/linux/clk/at91_pmc.h
@@ -47,8 +47,10 @@
 #define	AT91_CKGR_MOR		0x20			/* Main Oscillator Register [not on SAM9RL] */
 #define		AT91_PMC_MOSCEN		(1    <<  0)		/* Main Oscillator Enable */
 #define		AT91_PMC_OSCBYPASS	(1    <<  1)		/* Oscillator Bypass */
+#define		AT91_PMC_WAITMODE	(1    <<  2)		/* Wait Mode Command */
 #define		AT91_PMC_MOSCRCEN	(1    <<  3)		/* Main On-Chip RC Oscillator Enable [some SAM9] */
 #define		AT91_PMC_OSCOUNT	(0xff <<  8)		/* Main Oscillator Start-up Time */
+#define		AT91_PMC_KEY_MASK	(0xff << 16)
 #define		AT91_PMC_KEY		(0x37 << 16)		/* MOR Writing Key */
 #define		AT91_PMC_MOSCSEL	(1    << 24)		/* Main Oscillator Selection [some SAM9] */
 #define		AT91_PMC_CFDEN		(1    << 25)		/* Clock Failure Detector Enable [some SAM9] */
@@ -166,6 +168,8 @@
 #define		AT91_PMC_WPVS		(0x1  <<  0)		/* Write Protect Violation Status */
 #define		AT91_PMC_WPVSRC		(0xffff  <<  8)		/* Write Protect Violation Source */
 
+#define AT91_PMC_VERSION	0xfc
+
 #define AT91_PMC_PCER1		0x100			/* Peripheral Clock Enable Register 1 [SAMA5 only]*/
 #define AT91_PMC_PCDR1		0x104			/* Peripheral Clock Enable Register 1 */
 #define AT91_PMC_PCSR1		0x108			/* Peripheral Clock Enable Register 1 */
-- 
1.7.9.5



From wenyou.yang at atmel.com  Wed Feb  3 23:37:50 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Thu, 4 Feb 2016 15:37:50 +0800
Subject: [PATCH v2 3/4] ARM: at91: pm: configure PMC fast startup signals
In-Reply-To: <1454571471-4434-1-git-send-email-wenyou.yang@atmel.com>
References: <1454571471-4434-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1454571471-4434-4-git-send-email-wenyou.yang@atmel.com>

The fast startup signal is used as wake up sources for ULP1 mode.
As soon as a fast startup signal is asserted, the embedded 12 MHz
RC oscillator restarts automatically.

This patch is to configure the fast startup signals, which signal
is enabled to trigger the PMC to wake up the system from ULP1 mode
should be configured via the DT.

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---

Changes in v2:
 - shorten the pmc-fast-startup property's name.
 - use the value property, instead of bool property for high
   or low triggered.

 arch/arm/mach-at91/pm.c      |  115 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/clk/at91_pmc.h |   32 ++++++++++++
 2 files changed, 147 insertions(+)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index a7aec35..6763de8 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -24,6 +24,8 @@
 #include <linux/platform_device.h>
 #include <linux/io.h>
 #include <linux/clk/at91_pmc.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
 
 #include <asm/irq.h>
 #include <linux/atomic.h>
@@ -425,6 +427,117 @@ static void __init at91_pm_sram_init(void)
 			&at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
 }
 
+static int __init at91_pmc_fast_startup_init(void)
+{
+	struct device_node *np;
+	struct regmap *regmap;
+	const char *pm;
+	u32 mode = 0, polarity = 0;
+
+	np = of_find_compatible_node(NULL, NULL,
+				     "atmel,sama5d2-pmc-fast-startup");
+	if (!np)
+		return -ENODEV;
+
+	regmap = syscon_node_to_regmap(of_get_parent(np));
+	if (IS_ERR(regmap)) {
+		pr_info("AT91: failed to find PMC fast startup\n");
+		return PTR_ERR(regmap);
+	}
+
+	mode |= of_property_read_bool(np, "atmel,wkup-trigger") ?
+		AT91_PMC_FSTT0 : 0;
+	mode |= of_property_read_bool(np, "atmel,secumod-trigger") ?
+		AT91_PMC_FSTT1 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu0-trigger") ?
+		AT91_PMC_FSTT2 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu1-trigger") ?
+		AT91_PMC_FSTT3 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu2-trigger") ?
+		AT91_PMC_FSTT4 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu3-trigger") ?
+		AT91_PMC_FSTT5 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu4-trigger") ?
+		AT91_PMC_FSTT6 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu5-trigger") ?
+		AT91_PMC_FSTT7 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu6-trigger") ?
+		AT91_PMC_FSTT8 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu7-trigger") ?
+		AT91_PMC_FSTT9 : 0;
+	mode |= of_property_read_bool(np, "atmel,gmac-wol-trigger") ?
+		AT91_PMC_FSTT10 : 0;
+	mode |= of_property_read_bool(np, "atmel,rtc-alarm-trigger") ?
+		AT91_PMC_RTCAL : 0;
+	mode |= of_property_read_bool(np, "atmel,usb-resume-trigger") ?
+		AT91_PMC_USBAL : 0;
+	mode |= of_property_read_bool(np, "atmel,sdmmc-cd-trigger") ?
+		AT91_PMC_SDMMC_CD : 0;
+	mode |= of_property_read_bool(np, "atmel,rxlp-match-trigger") ?
+		AT91_PMC_RXLP_MCE : 0;
+	mode |= of_property_read_bool(np, "atmel,acc-comparison-trigger") ?
+		AT91_PMC_ACC_CE : 0;
+
+	if (!of_property_read_string(np, "atmel,wkup-trigger-level", &pm)) {
+		if (!strcasecmp(pm, "high"))
+			polarity |= AT91_PMC_FSTP0;
+	}
+
+	if (mode & AT91_PMC_FSTT1)
+		polarity |= AT91_PMC_FSTP1;
+
+	if (!of_property_read_string(np, "atmel,piobu0-trigger-level", &pm)) {
+		if (!strcasecmp(pm, "high"))
+			polarity |= AT91_PMC_FSTP2;
+	}
+
+	if (!of_property_read_string(np, "atmel,piobu1-trigger-level", &pm)) {
+		if (!strcasecmp(pm, "high"))
+			polarity |= AT91_PMC_FSTP3;
+	}
+
+	if (!of_property_read_string(np, "atmel,piobu2-trigger-level", &pm)) {
+		if (!strcasecmp(pm, "high"))
+			polarity |= AT91_PMC_FSTP4;
+	}
+
+	if (!of_property_read_string(np, "atmel,piobu3-trigger-level", &pm)) {
+		if (!strcasecmp(pm, "high"))
+			polarity |= AT91_PMC_FSTP5;
+	}
+
+	if (!of_property_read_string(np, "atmel,piobu4-trigger-level", &pm)) {
+		if (!strcasecmp(pm, "high"))
+			polarity |= AT91_PMC_FSTP6;
+	}
+
+	if (!of_property_read_string(np, "atmel,piobu5-trigger-level", &pm)) {
+		if (!strcasecmp(pm, "high"))
+			polarity |= AT91_PMC_FSTP7;
+	}
+
+	if (!of_property_read_string(np, "atmel,piobu6-trigger-level", &pm)) {
+		if (!strcasecmp(pm, "high"))
+			polarity |= AT91_PMC_FSTP8;
+	}
+
+	if (!of_property_read_string(np, "atmel,piobu7-trigger-level", &pm)) {
+		if (!strcasecmp(pm, "high"))
+			polarity |= AT91_PMC_FSTP9;
+	}
+
+	if (mode & AT91_PMC_FSTT10)
+		polarity |= AT91_PMC_FSTP10;
+
+	regmap_write(regmap, AT91_PMC_FSMR, mode);
+
+	regmap_write(regmap, AT91_PMC_FSPR, polarity);
+
+	of_node_put(np);
+
+	return 0;
+}
+
 static const struct of_device_id atmel_pmc_ids[] = {
 	{ .compatible = "atmel,at91rm9200-pmc"  },
 	{ .compatible = "atmel,at91sam9260-pmc" },
@@ -509,4 +622,6 @@ void __init sama5_pm_init(void)
 
 	if (readl(pmc + AT91_PMC_VERSION) >= SAMA5D2_PMC_VERSION)
 		at91_pm_data.ulp_mode = ULP1_MODE;
+
+	at91_pmc_fast_startup_init();
 }
diff --git a/include/linux/clk/at91_pmc.h b/include/linux/clk/at91_pmc.h
index 4afd891..683580e 100644
--- a/include/linux/clk/at91_pmc.h
+++ b/include/linux/clk/at91_pmc.h
@@ -168,6 +168,38 @@
 #define		AT91_PMC_WPVS		(0x1  <<  0)		/* Write Protect Violation Status */
 #define		AT91_PMC_WPVSRC		(0xffff  <<  8)		/* Write Protect Violation Source */
 
+#define AT91_PMC_FSMR		0x70		/* Fast Startup Mode Register */
+#define AT91_PMC_FSTT0		BIT(0)		/* WKUP Pin Enable */
+#define AT91_PMC_FSTT1		BIT(1)		/* Security Module Enable */
+#define AT91_PMC_FSTT2		BIT(2)		/* PIOBU0 Input Enable */
+#define AT91_PMC_FSTT3		BIT(3)		/* PIOBU1 Input Enable */
+#define AT91_PMC_FSTT4		BIT(4)		/* PIOBU2 Input Enable */
+#define AT91_PMC_FSTT5		BIT(5)		/* PIOBU3 Input Enable */
+#define AT91_PMC_FSTT6		BIT(6)		/* PIOBU4 Input Enable */
+#define AT91_PMC_FSTT7		BIT(7)		/* PIOBU5 Input Enable */
+#define AT91_PMC_FSTT8		BIT(8)		/* PIOBU6 Input Enable */
+#define AT91_PMC_FSTT9		BIT(9)		/* PIOBU7 Input Enable */
+#define AT91_PMC_FSTT10		BIT(10)		/* GMAC Wake-up On LAN Enable */
+#define AT91_PMC_RTCAL		BIT(17)		/* RTC Alarm Enable */
+#define AT91_PMC_USBAL		BIT(18)		/* USB Resume Enable */
+#define AT91_PMC_SDMMC_CD	BIT(19)		/* SDMMC Card Detect Enable */
+#define AT91_PMC_LPM		BIT(20)		/* Low-power Mode */
+#define AT91_PMC_RXLP_MCE	BIT(24)		/* Backup UART Receive Enable */
+#define AT91_PMC_ACC_CE		BIT(25)		/* ACC Enable */
+
+#define AT91_PMC_FSPR		0x74		/* Fast Startup Polarity Reg */
+#define AT91_PMC_FSTP0		BIT(0)		/* WKUP Pin Polarity */
+#define AT91_PMC_FSTP1		BIT(1)		/* Security Module Polarity */
+#define AT91_PMC_FSTP2		BIT(2)		/* PIOBU0 Pin Polarity */
+#define AT91_PMC_FSTP3		BIT(3)		/* PIOBU1 Pin Polarity */
+#define AT91_PMC_FSTP4		BIT(4)		/* PIOBU2 Pin Polarity */
+#define AT91_PMC_FSTP5		BIT(5)		/* PIOBU3 Pin Polarity */
+#define AT91_PMC_FSTP6		BIT(6)		/* PIOBU4 Pin Polarity */
+#define AT91_PMC_FSTP7		BIT(7)		/* PIOBU5 Pin Polarity */
+#define AT91_PMC_FSTP8		BIT(8)		/* PIOBU6 Pin Polarity */
+#define AT91_PMC_FSTP9		BIT(9)		/* PIOBU7 Pin Polarity */
+#define AT91_PMC_FSTP10		BIT(10)		/* Wake-up On LAN Polarity */
+
 #define AT91_PMC_VERSION	0xfc
 
 #define AT91_PMC_PCER1		0x100			/* Peripheral Clock Enable Register 1 [SAMA5 only]*/
-- 
1.7.9.5



From wenyou.yang at atmel.com  Wed Feb  3 23:37:51 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Thu, 4 Feb 2016 15:37:51 +0800
Subject: [PATCH v2 4/4] Documentation: atmel-pmc: add DT bindings for fast
 startup
In-Reply-To: <1454571471-4434-1-git-send-email-wenyou.yang@atmel.com>
References: <1454571471-4434-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1454571471-4434-5-git-send-email-wenyou.yang@atmel.com>

Add DT bindings to configurate the PMC_FSMR and PMC_FSPR registers
to trigger a fast restart signal to PMC.

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---

Changes in v2:
 - change the property name and property description.

 .../devicetree/bindings/arm/atmel-pmc.txt          |   63 ++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/atmel-pmc.txt b/Documentation/devicetree/bindings/arm/atmel-pmc.txt
index 795cc78..1b3833b 100644
--- a/Documentation/devicetree/bindings/arm/atmel-pmc.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-pmc.txt
@@ -12,3 +12,66 @@ Examples:
 		compatible = "atmel,at91rm9200-pmc";
 		reg = <0xfffffc00 0x100>;
 	};
+
+PMC Fast Startup Signals
+
+The PMC Fast Start Signals are used as the wake up source to trigger the PMC
+to wake up the system from the ULP1 mode.
+
+required properties:
+- compatible: Should be "atmel,sama5d2-pmc-fast-startup".
+
+optional properties:
+- atmel,wkup-trigger: boolean, WKUP input can trigger a fast restart signal.
+- atmel,secumod-trigger: boolean, SECUMOD can trigger a fast restart signal.
+- atmel,piobu0-trigger: boolean, PIOBU0 input can trigger a fast restart signal.
+- atmel,piobu1-trigger: boolean, PIOBU1 input can trigger a fast restart signal.
+- atmel,piobu2-trigger: boolean, PIOBU2 input can trigger a fast restart signal.
+- atmel,piobu3-trigger: boolean, PIOBU3 input can trigger a fast restart signal.
+- atmel,piobu4-trigger: boolean, PIOBU4 input can trigger a fast restart signal.
+- atmel,piobu5-trigger: boolean, PIOBU5 input can trigger a fast restart signal.
+- atmel,piobu6-trigger: boolean, PIOBU6 input can trigger a fast restart signal.
+- atmel,piobu7-trigger: boolean, PIOBU7 input can trigger a fast restart signal.
+- atmel,gmac-wol-trigger: boolean, GMAC_WOL can trigger a fast restart signal.
+- atmel,rtc-alarm-trigger: boolean, RTC alarm can trigger a fast restart signal.
+- atmel,usb-resume-trigger: boolean, USB resume can trigger a fast restart
+  signal.
+- atmel,sdmmc-cd-trigger: boolean, SDMMC card detect can trigger a fast
+  restart signal.
+- atmel,rxlp-match-trigger: boolean, Matching condition on RXLP can trigger
+  a fast restart signal.
+- atmel,acc-comparison-trigger: boolean, ACC comparison can trigger a fast
+  restart signal.
+
+- atmel,wkup-trigger-level: string, defines the active polarity of the wake-up
+  input. Supported values are: "high" or "low".
+- atmel,piobu0-trigger-level: string, defines the active polarity of
+  the corresponding PIOBU0 input. Supported values are: "high" or "low".
+- atmel,piobu1-trigger-level: string, defines the active polarity of
+  the corresponding PIOBU1 input. Supported values are: "high" or "low".
+- atmel,piobu2-trigger-level: string, defines the active polarity of
+  the corresponding PIOBU2 input. Supported values are: "high" or "low".
+- atmel,piobu3-trigger-level: string, defines the active polarity of
+  the corresponding PIOBU3 input. Supported values are: "high" or "low".
+- atmel,piobu4-trigger-level: string, defines the active polarity of
+  the corresponding PIOBU4 input. Supported values are: "high" or "low".
+- atmel,piobu5-trigger-level: string, defines the active polarity of
+  the corresponding PIOBU5 input. Supported values are: "high" or "low".
+- atmel,piobu6-trigger-level: string, defines the active polarity of
+  the corresponding PIOBU6 input. Supported values are: "high" or "low".
+- atmel,piobu7-trigger-level: string, defines the active polarity of
+  the corresponding PIOBU7 input. Supported values are: "high" or "low".
+
+Example:
+
+	pmc: pmc at f0014000 {
+		compatible = "atmel,sama5d2-pmc";
+		reg = <0xf0014000 0x160>;
+
+		pmc_fast_restart {
+			compatible = "atmel,sama5d2-pmc-fast-startup";
+			atmel,wkup-trigger;
+			atmel,rtc-alarm-trigger;
+			atmel,wkup-trigger-level = "low";
+		};
+	};
-- 
1.7.9.5



From maxime.ripard at free-electrons.com  Thu Feb  4 00:01:09 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 4 Feb 2016 09:01:09 +0100
Subject: [PATCH 04/14] clk: sunxi: add ahb1 clock for A83T
In-Reply-To: <CAEzqOZuBz2jexvZvvtkvjbE8UtzUMKL9nT5JJ9JcvMPmzEKTcQ@mail.gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-5-git-send-email-vishnupatekar0510@gmail.com>
 <20160202131725.GQ4652@lukather>
 <CAEzqOZuBz2jexvZvvtkvjbE8UtzUMKL9nT5JJ9JcvMPmzEKTcQ@mail.gmail.com>
Message-ID: <20160204080109.GA4270@lukather>

On Thu, Feb 04, 2016 at 02:06:45PM +0800, Vishnu Patekar wrote:
> Hello Maxime,
> 
> 
> On Tue, Feb 2, 2016 at 9:17 PM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > Hi,
> >
> > On Sun, Jan 31, 2016 at 09:20:56AM +0800, Vishnu Patekar wrote:
> >> AHB1 on A83T is similar to ahb1 on A31, except parents are different.
> >> clock index 0b1x is PLL6.
> >>
> >> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
> >
> > If the clock is the same but the parents are different, then we don't
> > need to duplicate all the logic. Simply add the number of parents to
> > mux_data, and you're all set.
> 
> Problem here is: parent 0b10 for A31 ahb1 is AXI, 0b11 is pll6/pre_div.
> 0b10 and 0b11 is pll6/pre_div.
> So, just adding number of parents to mux_data will not solve problem.

Is anyone using 0b11 ? Can't we just ignore it?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/27906fdc/attachment.sig>

From leo.yan at linaro.org  Thu Feb  4 00:28:10 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 4 Feb 2016 16:28:10 +0800
Subject: [PATCH v6 1/4] dt-bindings: mailbox: Document Hi6220 mailbox
 driver
In-Reply-To: <20160203204717.GA1713@rob-hp-laptop>
References: <1454407782-24674-1-git-send-email-leo.yan@linaro.org>
 <1454407782-24674-2-git-send-email-leo.yan@linaro.org>
 <20160203204717.GA1713@rob-hp-laptop>
Message-ID: <20160204082810.GA28299@leoy-linaro>

On Wed, Feb 03, 2016 at 02:47:17PM -0600, Rob Herring wrote:
> On Tue, Feb 02, 2016 at 06:09:39PM +0800, Leo Yan wrote:
> > Document DT binding for Hisilicon Hi6220 mailbox driver.
> > 
> > Signed-off-by: Leo Yan <leo.yan at linaro.org>
> > ---
> >  .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  | 74 ++++++++++++++++++++++
> >  1 file changed, 74 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
> 
> One nit, otherwise:
> 
> Acked-by: Rob Herring <robh at kernel.org>

Thanks, Rob. I will send a new version to fix them.

Thanks,
Leo Yan

> > 
> > diff --git a/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
> > new file mode 100644
> > index 0000000..8508c8a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
> > @@ -0,0 +1,74 @@
> > +Hisilicon Hi6220 Mailbox Driver
> > +===============================
> > +
> > +Hisilicon Hi6220 mailbox supports up to 32 channels. Each channel
> > +is unidirectional with a maximum message size of 8 words. I/O is
> > +performed using register access (there is no DMA) and the cell
> > +raises an interrupt when messages are received.
> > +
> > +Mailbox Device Node:
> > +====================
> > +
> > +Required properties:
> > +--------------------
> > +- compatible:		Shall be "hisilicon,hi6220-mbox"
> > +- reg:			Contains the mailbox register address range (base
> > +			address and length); the first item is for IPC
> > +			registers, the second item is shared buffer for
> > +			slots.
> > +- #mbox-cells:		Common mailbox binding property to identify the number
> > +			of cells required for the mailbox specifier. Must be 3.
> > +			<&phandle slot_id dst_irq ack_irq>
> > +			  phandle: Label name of mailbox controller
> > +			  slot_id: Slot id used either for TX or RX
> > +			  dst_irq: IRQ identifier index number which used by MCU
> > +			  ack_irq: IRQ identifier index number with generating a
> > +			           TX/RX interrupt to application processor,
> > +				   mailbox driver uses it to acknowledge interrupt
> > +- interrupts:		Contains the interrupt information for the mailbox
> > +			device. The format is dependent on which interrupt
> > +			controller the SoCs use.
> > +
> > +Optional Properties:
> > +--------------------
> > +- hi6220,mbox-tx-noirq: Property of MCU firmware's feature, so mailbox driver
> > +			use this flag to ask MCU to enable "automatic idle
> > +			flag" mode or IRQ generated mode to acknowledge a TX
> > +			completion.
> > +
> > +Example:
> > +--------
> > +
> > +	mailbox: mailbox at F7510000 {
> 
> use lowercase for hex
> 
> > +		compatible = "hisilicon,hi6220-mbox";
> > +		reg = <0x0 0xF7510000 0x0 0x1000>, /* IPC_S */
> > +		      <0x0 0x06DFF800 0x0 0x0800>; /* Mailbox */
> 
> and here too.
> 
> > +		interrupt-parent = <&gic>;
> > +		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
> > +		#mbox-cells = <3>;
> > +	};
> > +
> > +
> > +Mailbox client
> > +===============
> > +
> > +Required properties:
> > +--------------------
> > +- compatible:		Many (See the client docs).
> > +- mboxes:		Standard property to specify a Mailbox (See ./mailbox.txt)
> > +			Cells must match 'mbox-cells' (See Mailbox Device Node above).
> > +
> > +Optional Properties:
> > +--------------------
> > +- mbox-names:		Name given to channels seen in the 'mboxes' property.
> > +
> > +Example:
> > +--------
> > +
> > +	stub_clock: stub_clock {
> > +		compatible = "hisilicon,hi6220-stub-clk";
> > +		hisilicon,hi6220-clk-sram = <&sram>;
> > +		#clock-cells = <1>;
> > +		mbox-names = "mbox-tx", "mbox-rx";
> > +		mboxes = <&mailbox 1 0 11>, <&mailbox 0 1 10>;
> > +	};
> > -- 
> > 1.9.1
> > 


From ard.biesheuvel at linaro.org  Thu Feb  4 00:31:45 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu,  4 Feb 2016 09:31:45 +0100
Subject: [PATCH] ARM: remove duplicate definitions of __vectors_start and
 __stubs_start
Message-ID: <1454574705-15109-1-git-send-email-ard.biesheuvel@linaro.org>

Commit b9b32bf70f2f ("ARM: use linker magic for vectors and vector stubs")
introduced new global definitions of __vectors_start and __stubs_start,
and changed the existing ones to have internal linkage only. However, these
symbols are still visible to kallsyms, and due to the way the .vectors and
.stubs sections are emitted at the base of the VMA space, these duplicate
definitions have conflicting values.

  $ nm -n vmlinux |grep -E __vectors\|__stubs
  00000000 t __vectors_start
  00001000 t __stubs_start
  c0e77000 T __vectors_start
  c0e77020 T __stubs_start

This is completely harmless by itself, since the wrong values are local
symbols that cannot be referenced by other object files directly. However,
since these symbols are also listed in the kallsyms symbol table in some
cases (i.e., CONFIG_KALLSYMS_ALL=y and CONFIG_XIP_KERNEL=y), having these
conflicting values can be confusing. So either remove them, or make them
strictly local.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---

This is a separate fix for the duplicate symbols based on v4.5-rc2,
so that it can be applied separately if desired. In that case, I will
rebase my kallsyms series onto this patch.

 arch/arm/kernel/entry-armv.S | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 3ce377f7251f..788e40c1254f 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -1064,7 +1064,6 @@ ENDPROC(vector_\name)
 	.endm
 
 	.section .stubs, "ax", %progbits
-__stubs_start:
 	@ This must be the first word
 	.word	vector_swi
 
@@ -1206,10 +1205,10 @@ vector_addrexcptn:
 	.equ	vector_fiq_offset, vector_fiq
 
 	.section .vectors, "ax", %progbits
-__vectors_start:
+.L__vectors_start:
 	W(b)	vector_rst
 	W(b)	vector_und
-	W(ldr)	pc, __vectors_start + 0x1000
+	W(ldr)	pc, .L__vectors_start + 0x1000
 	W(b)	vector_pabt
 	W(b)	vector_dabt
 	W(b)	vector_addrexcptn
-- 
2.5.0



From vishnupatekar0510 at gmail.com  Thu Feb  4 00:51:06 2016
From: vishnupatekar0510 at gmail.com (Vishnu Patekar)
Date: Thu, 4 Feb 2016 16:51:06 +0800
Subject: [PATCH 06/14] ARM: dts: sun8i-a83t: Correct low speed oscillator
 clocks
In-Reply-To: <20160202131947.GS4652@lukather>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-7-git-send-email-vishnupatekar0510@gmail.com>
 <20160202131947.GS4652@lukather>
Message-ID: <CAEzqOZvcy58T_uxvymGxuQXh_Goj3yHmgkmL4VL+x2_bycMgNg@mail.gmail.com>

Hello Maxime,


On Tue, Feb 2, 2016 at 9:19 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> On Sun, Jan 31, 2016 at 09:20:58AM +0800, Vishnu Patekar wrote:
>> From: Chen-Yu Tsai <wens at csie.org>
>>
>> The A83T does not have a 32.768 kHz low speed oscillator, either as
>> an external crystal or input. It has a 16 MHz RC-based (inaccurate)
>> internal oscillator, which is then divided by 512 for a clock close
>> to 32 kHz.
>>
>> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
>
> You should have your SoB here.
>
> Is it ok to add it?
Yes, please add.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com


From zhang.chunyan at linaro.org  Thu Feb  4 00:56:19 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Thu,  4 Feb 2016 16:56:19 +0800
Subject: [PATCH V2 2/6] stm class: adds a loop to extract the first valid STM
 device name
In-Reply-To: <1454487337-30184-3-git-send-email-zhang.chunyan@linaro.org>
References: <1454487337-30184-3-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454576179-27224-1-git-send-email-zhang.chunyan@linaro.org>

The node name of STM master management policy is a concatenation of an
STM device name to which this policy applies and following an arbitrary
string, these two strings are concatenated with a dot.

This patch adds a loop for extracting the STM device name when an
arbitrary number of dot(s) are found in this STM device name.

Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 drivers/hwtracing/stm/policy.c | 27 ++++++++++++++++-----------
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
index 11ab6d0..691686e 100644
--- a/drivers/hwtracing/stm/policy.c
+++ b/drivers/hwtracing/stm/policy.c
@@ -321,21 +321,26 @@ stp_policies_make(struct config_group *group, const char *name)
 	/*
 	 * node must look like <device_name>.<policy_name>, where
 	 * <device_name> is the name of an existing stm device and
-	 * <policy_name> is an arbitrary string
+	 * <policy_name> is an arbitrary string, when an arbitrary
+	 * number of dot(s) are found in the <device_name>, the
+	 * first matched STM device name would be extracted.
 	 */
-	p = strchr(devname, '.');
-	if (!p) {
-		kfree(devname);
-		return ERR_PTR(-EINVAL);
-	}
+	for (p = devname; ; p++) {
+		p = strchr(p, '.');
+		if (!p) {
+			kfree(devname);
+			return ERR_PTR(-EINVAL);
+		}
 
-	*p++ = '\0';
+		*p = '\0';
 
-	stm = stm_find_device(devname);
-	kfree(devname);
+		stm = stm_find_device(devname);
+		if (stm)
+			break;
+		*p = '.';
+	}
 
-	if (!stm)
-		return ERR_PTR(-ENODEV);
+	kfree(devname);
 
 	mutex_lock(&stm->policy_mutex);
 	if (stm->policy) {
-- 
1.9.1



From carlo at caione.org  Thu Feb  4 01:12:05 2016
From: carlo at caione.org (Carlo Caione)
Date: Thu, 4 Feb 2016 10:12:05 +0100
Subject: [PATCH v4] mmc: meson: Add driver for the SD/MMC host found on
 Amlogic MesonX SoCs
In-Reply-To: <CAPDyKFo=LdzFsELZJKXj_CDcNYj96J4Q9-KqS63041d3BVUEDQ@mail.gmail.com>
References: <1448988109-32630-1-git-send-email-carlo@caione.org>
 <CAPDyKFp=buvJ8Li3XC8XSUAUO7BsE+U6vEQH2xTrgcHAkdG8bQ@mail.gmail.com>
 <CAOQ7t2aJAPWd3Xmvu7n0EWL-KC8ZriM3KryfsYEh556uXhuR+g@mail.gmail.com>
 <CAPDyKFpcsKihuOiF5=RwoWrF0Jf7hRsXVSU5uV8qZf1mUsa-iQ@mail.gmail.com>
 <CAOQ7t2afXxStCsj=M-FX7eMep1gLt4jkyXDiLas_SQ1UwHc0=Q@mail.gmail.com>
 <CAPDyKFpX+_fHvv_bJUKZmSufKKnuONC582E7u3b20a+Rbbggng@mail.gmail.com>
 <CAOQ7t2aS0yRDhM3+8wW5xrycG371uthDJy6U_oDAZip4jHRiRA@mail.gmail.com>
 <CAPDyKFo=LdzFsELZJKXj_CDcNYj96J4Q9-KqS63041d3BVUEDQ@mail.gmail.com>
Message-ID: <CAOQ7t2aF=wzYHF8LXK5WVMJ=mEDHzfvbL=iRvorq+FZshL0q0g@mail.gmail.com>

On Wed, Feb 3, 2016 at 11:46 AM, Ulf Hansson <ulf.hansson at linaro.org> wrote:
> On 2 February 2016 at 22:54, Carlo Caione <carlo at caione.org> wrote:

[cut]

> Huh, another broken MMC controller. :-)

Oh, actually I found in the datasheet a couple of undocumented
registers (also not used in the original Amlogic SDK code) that seems
to have something to do with timeout (hard to say without proper
documentation but they are called "Timeout counter for preload setting
and present status" and "Timeout Counter Interrupt Enable for ARC/ARM"
so I guess I'm on the right track here).
I briefly tried yesterday to enable this timeout interrupt with a
dummy value in the counter register (I have no idea how get this value
from the clocking) and it seems working (the counter value is
decremented when reading the register upon command completion).

> In some cases there are no data in the request, it's just a command
> being sent. So to deal with this issue, you will have to adjust the
> timer depending on the request we send to the controller.

I see that the CMD13 used to poll the card has no data so in that case
should we use a fixed / dummy value to use as timeout counter?
I'm kind of confused here since the MMC drivers I'm looking at use the
hardware timeout register only when the data->timeout_ns is actually
present.

-- 
Carlo Caione


From marc.zyngier at arm.com  Thu Feb  4 01:32:03 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 4 Feb 2016 09:32:03 +0000
Subject: [PATCH] irqchip-gicv3: wait for ack from redistributer after
 read_iar
In-Reply-To: <1454528588-32721-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1454528588-32721-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <56B31A93.5050608@arm.com>

Tirumalesh,

On 03/02/16 19:43, tchalamarla at caviumnetworks.com wrote:
> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> 
> Systems with high number of cores and sufficiently loaded,
> there exists a small window where it is possible for re-distributor
> to illegally merge two LPI and cuases missing interrupts.

s/cuases/causes/

It has nothing to do with the number of cores or the load, but
everything to do with the latency between the CPU interface and the
redistributor, and how quickly the redistributor gets notified that the
interrupt is not pending anymore.

> 
> Solution is, wait for ack from the redistributor after read_iar.
> A "dsb sy" after IAR read ensures there is no illegal merge windows.

You don't "wait for the ack". You actually *push* the ack (as in
Interrupt Acknowledgement Register) towards the redistributor.

The fact that the DSB generates an ACK message from the redistributor is
an HW implementation detail is not universally relevant. Please stay at
the architecture level, and avoid implementation details.

> 
> giv3 spec version 32 also warns this, see section 4.4.13

What is the point of pointing to an engineering specification that is
unavailable to almost anyone (hint: it has the word "Confidential" on
each and every page)?

A much better reference would be a quote from the publicly available GIC
Architecture Specification (ARM IHI 0069B). Something like:

4.1.1 Physical CPU Interface:
"The effects of reading ICC_IAR0_EL1 and ICC_IAR1_EL1 on the state of a
returned INTID are not guaranteed to be visible until after the
execution of a DSB."

> 
> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> ---
>  arch/arm64/include/asm/arch_gicv3.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/include/asm/arch_gicv3.h b/arch/arm64/include/asm/arch_gicv3.h
> index 2731d3b..8ec88e5 100644
> --- a/arch/arm64/include/asm/arch_gicv3.h
> +++ b/arch/arm64/include/asm/arch_gicv3.h
> @@ -103,6 +103,7 @@ static inline u64 gic_read_iar_common(void)
>  	u64 irqstat;
>  
>  	asm volatile("mrs_s %0, " __stringify(ICC_IAR1_EL1) : "=r" (irqstat));
> +	dsb(sy);
>  	return irqstat;
>  }
>  
> 

Other than that, I'm fine with this. Please repost with an amended
commit message and subject.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From morten.rasmussen at arm.com  Thu Feb  4 01:36:00 2016
From: morten.rasmussen at arm.com (Morten Rasmussen)
Date: Thu, 4 Feb 2016 09:36:00 +0000
Subject: [PATCH v3 2/6] drivers/cpufreq: implement
 init_cpu_capacity_default()
In-Reply-To: <CAKfTPtDGk5BC25WqHdhDYDOBgUsuidAMhrXS=eDi6wJPZjfrwA@mail.gmail.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <1454500799-18451-3-git-send-email-juri.lelli@arm.com>
 <CAKfTPtDGk5BC25WqHdhDYDOBgUsuidAMhrXS=eDi6wJPZjfrwA@mail.gmail.com>
Message-ID: <20160204093559.GA14099@e105550-lin.cambridge.arm.com>

On Wed, Feb 03, 2016 at 10:04:37PM +0100, Vincent Guittot wrote:
> On 3 February 2016 at 12:59, Juri Lelli <juri.lelli at arm.com> wrote:
> > To get default values for CPUs capacity we profile a simple (bogus)
> > integer benchmark on such CPUs; then we normalize results to 1024
> > (highest capacity in the system).
> >
> > Architectures that want this during boot have to define a weak function
> > (arch_wants_init_cpu_capacity) to return true.
> >
> > Also, kernel has to boot with init_cpu_capacity parameter if profiling
> > is needed, as it can be expensive and might add ~1 sec to boot time.
> >
> > Cc: Russell King <linux at arm.linux.org.uk>
> > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > Cc: Will Deacon <will.deacon at arm.com>
> > Cc: "Rafael J. Wysocki" <rjw at rjwysocki.net>
> > Cc: Viresh Kumar <viresh.kumar at linaro.org>
> > Cc: Vincent Guittot <vincent.guittot at linaro.org>
> > Cc: Sudeep Holla <sudeep.holla at arm.com>
> > Cc: Mark Rutland <mark.rutland at arm.com>
> > Signed-off-by: Juri Lelli <juri.lelli at arm.com>
> > ---
> >  Changes since v1:
> >  - add kernel command line parameter to enable profiling
> >  - add define for max trials
> >
> >  Documentation/kernel-parameters.txt |   4 +
> >  arch/arm/kernel/topology.c          |   2 +-
> >  arch/arm64/kernel/topology.c        |  12 +++
> >  drivers/cpufreq/Makefile            |   2 +-
> >  drivers/cpufreq/cpufreq.c           |   1 +
> >  drivers/cpufreq/cpufreq_capacity.c  | 174 ++++++++++++++++++++++++++++++++++++
> >  include/linux/cpufreq.h             |   2 +
> >  7 files changed, 195 insertions(+), 2 deletions(-)
> >  create mode 100644 drivers/cpufreq/cpufreq_capacity.c
> >
> > diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> > index 87d40a7..fad2b89 100644
> > --- a/Documentation/kernel-parameters.txt
> > +++ b/Documentation/kernel-parameters.txt
> > @@ -1570,6 +1570,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> >
> >         initrd=         [BOOT] Specify the location of the initial ramdisk
> >
> > +       init_cpu_capacity
> > +                       [KNL,ARM] Enables dynamic CPUs capacity benchmarking
> > +                       at boot.
> > +
> >         inport.irq=     [HW] Inport (ATI XL and Microsoft) busmouse driver
> >                         Format: <irq>
> >
> > diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> > index ec279d1..c9c87a5 100644
> > --- a/arch/arm/kernel/topology.c
> > +++ b/arch/arm/kernel/topology.c
> > @@ -47,7 +47,7 @@ unsigned long arch_scale_cpu_capacity(struct sched_domain *sd, int cpu)
> >         return per_cpu(cpu_scale, cpu);
> >  }
> >
> > -static void set_capacity_scale(unsigned int cpu, unsigned long capacity)
> > +void set_capacity_scale(unsigned int cpu, unsigned long capacity)
> >  {
> >         per_cpu(cpu_scale, cpu) = capacity;
> >  }
> > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> > index 694f6de..3b75d63 100644
> > --- a/arch/arm64/kernel/topology.c
> > +++ b/arch/arm64/kernel/topology.c
> > @@ -23,6 +23,18 @@
> >  #include <asm/cputype.h>
> >  #include <asm/topology.h>
> >
> > +static DEFINE_PER_CPU(unsigned long, cpu_scale) = SCHED_CAPACITY_SCALE;
> > +
> > +unsigned long arm_arch_scale_cpu_capacity(struct sched_domain *sd, int cpu)
> > +{
> > +       return per_cpu(cpu_scale, cpu);
> > +}
> > +
> > +void set_capacity_scale(unsigned int cpu, unsigned long capacity)
> > +{
> > +       per_cpu(cpu_scale, cpu) = capacity;
> > +}
> > +
> >  static int __init get_cpu_for_node(struct device_node *node)
> >  {
> >         struct device_node *cpu_node;
> > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> > index 9e63fb1..c4025fd 100644
> > --- a/drivers/cpufreq/Makefile
> > +++ b/drivers/cpufreq/Makefile
> > @@ -1,5 +1,5 @@
> >  # CPUfreq core
> > -obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o
> > +obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o cpufreq_capacity.o
> 
> Do you really want to have the calibration of capacity dependent of
> cpufreq ? It means that we can't use it without a cpufreq driver.
> IMHO, this creates a unnecessary dependency. I understand that you
> must ensure that core runs at max fequency if a driver is present but
> you should be able to calibrate the capacity if cpufreq is not
> available but you have different capacity because micro architecture

We could remove the dependency on cpufreq, but it would make things more
complicated for systems which do have frequency scaling as we would have
to either:

1) Run the calibration again once cpufreq has been initialized.

2) Know the frequency of all cpus at calibration time so we can
determine the correct micro-archicture difference. This option would
however mean that we have to provide a frequency scaling factor even for
systems that don't have cpufreq.

3) Find a way to do the calibration anyway if cpufreq doesn't
initialize. I'm not sure how that would work though.


From ard.biesheuvel at linaro.org  Thu Feb  4 01:41:04 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu,  4 Feb 2016 10:41:04 +0100
Subject: [PATCH] ARM: hide TCM section markers from kallsyms
Message-ID: <1454578864-1136-1-git-send-email-ard.biesheuvel@linaro.org>

The new base relative kallsyms implementation that is queued for inclusion
in v4.6 assumes that kernel symbols are within 2 GB of each other, and
hence splits the 32-bit kallsyms symbol address space into 2 GB of absolute
addresses and 2 GB of relative values.

This triggers a pathological case on ARM, where, if CONFIG_KALLSYMS_ALL,
CONFIG_HAVE_TCM and CONFIG_VMSPLIT_1G are all enabled, the distance
between kernel symbols exceeds this 2 GB, and the kallsyms table generation
fails. Since both VMSPLIT_1G and HAVE_TCM are niche features, and there
is no code in mainline that actually populates the TCM code and data
regions, we can work around the issue by hiding the TCM section markers
from kallsyms, by emitting them as absolute symbols.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm/kernel/vmlinux.lds.S | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 8b60fde5ce48..931ebd0696ea 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -293,11 +293,11 @@ SECTIONS
 	 */
 	.text_itcm ITCM_OFFSET : AT(__itcm_start)
 	{
-		__sitcm_text = .;
+		__sitcm_text = ABSOLUTE(.);
 		*(.tcm.text)
 		*(.tcm.rodata)
 		. = ALIGN(4);
-		__eitcm_text = .;
+		__eitcm_text = ABSOLUTE(.);
 	}
 
 	/*
@@ -314,10 +314,10 @@ SECTIONS
 	.data_dtcm DTCM_OFFSET : AT(__dtcm_start)
 	{
 		. = ALIGN(4);
-		__sdtcm_data = .;
+		__sdtcm_data = ABSOLUTE(.);
 		*(.tcm.data)
 		. = ALIGN(4);
-		__edtcm_data = .;
+		__edtcm_data = ABSOLUTE(.);
 	}
 
 	/* Reset the dot pointer or the linker gets confused */
-- 
2.5.0



From dirk.behme at de.bosch.com  Thu Feb  4 01:58:48 2016
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Thu, 4 Feb 2016 10:58:48 +0100
Subject: [PATCH v2] drivers/perf: arm_pmu: make info messages more verbose
Message-ID: <1454579928-20231-1-git-send-email-dirk.behme@de.bosch.com>

On a big.LITTLE system e.g. with Cortex A57 and A53 in case not all cores
are online at PMU probe time we might get

hw perfevents: failed to probe PMU!
hw perfevents: failed to register PMU devices!

making it unclear which cores failed, here.

Add the device tree full name which failed and the error value resulting
in a more verbose and helpful message like

hw perfevents: /soc/pmu_a53: failed to probe PMU! Error -6
hw perfevents: /soc/pmu_a53: failed to register PMU devices! Error -6

Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
---
Changes in v2: Use the full node name from DT instead of pmu->name, as if
we fail to find anything in the match table, that'll be NULL. Additionally,
add the error value to get an idea why it failed.

 drivers/perf/arm_pmu.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 166637f..6fb63a3 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -898,7 +898,8 @@ int arm_pmu_device_probe(struct platform_device *pdev,
 	}
 
 	if (ret) {
-		pr_info("failed to probe PMU!\n");
+		pr_info("%s: failed to probe PMU! Error %i\n",
+			node->full_name, ret);
 		goto out_free;
 	}
 
@@ -918,7 +919,8 @@ int arm_pmu_device_probe(struct platform_device *pdev,
 out_destroy:
 	cpu_pmu_destroy(pmu);
 out_free:
-	pr_info("failed to register PMU devices!\n");
+	pr_info("%s: failed to register PMU devices! Error %i\n",
+		node->full_name, ret);
 	kfree(pmu);
 	return ret;
 }
-- 
2.5.1



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:25 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:25 +0100
Subject: [PATCH v2 02/51] mtd: create an mtd_oobavail() helper and make use of
 it
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-3-git-send-email-boris.brezillon@free-electrons.com>

Currently, all MTD drivers/sublayers exposing an OOB area are
doing the same kind of test to extract the available OOB size
based on the mtd_info and mtd_oob_ops structures.
Move this common logic into an inline function and make use of it.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
Suggested-by: Priit Laes <plaes at plaes.org>
---
 drivers/mtd/mtdpart.c              |  5 +----
 drivers/mtd/nand/nand_base.c       | 16 ++++------------
 drivers/mtd/onenand/onenand_base.c | 19 +++----------------
 include/linux/mtd/mtd.h            |  5 +++++
 4 files changed, 13 insertions(+), 32 deletions(-)

diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 10bf304..08de4b2 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -126,10 +126,7 @@ static int part_read_oob(struct mtd_info *mtd, loff_t from,
 	if (ops->oobbuf) {
 		size_t len, pages;
 
-		if (ops->mode == MTD_OPS_AUTO_OOB)
-			len = mtd->oobavail;
-		else
-			len = mtd->oobsize;
+		len = mtd_oobavail(mtd, ops);
 		pages = mtd_div_by_ws(mtd->size, mtd);
 		pages -= mtd_div_by_ws(from, mtd);
 		if (ops->ooboffs + ops->ooblen > pages * len)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 21c48ff..7f21719 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1723,8 +1723,7 @@ static int nand_do_read_ops(struct mtd_info *mtd, loff_t from,
 	int ret = 0;
 	uint32_t readlen = ops->len;
 	uint32_t oobreadlen = ops->ooblen;
-	uint32_t max_oobsize = ops->mode == MTD_OPS_AUTO_OOB ?
-		mtd->oobavail : mtd->oobsize;
+	uint32_t max_oobsize = mtd_oobavail(mtd, ops);
 
 	uint8_t *bufpoi, *oob, *buf;
 	int use_bufpoi;
@@ -2075,10 +2074,7 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
 
 	stats = mtd->ecc_stats;
 
-	if (ops->mode == MTD_OPS_AUTO_OOB)
-		len = mtd->oobavail;
-	else
-		len = mtd->oobsize;
+	len = mtd_oobavail(mtd, ops);
 
 	if (unlikely(ops->ooboffs >= len)) {
 		pr_debug("%s: attempt to start read outside oob\n",
@@ -2575,8 +2571,7 @@ static int nand_do_write_ops(struct mtd_info *mtd, loff_t to,
 	uint32_t writelen = ops->len;
 
 	uint32_t oobwritelen = ops->ooblen;
-	uint32_t oobmaxlen = ops->mode == MTD_OPS_AUTO_OOB ?
-				mtd->oobavail : mtd->oobsize;
+	uint32_t oobmaxlen = mtd_oobavail(mtd, ops);
 
 	uint8_t *oob = ops->oobbuf;
 	uint8_t *buf = ops->datbuf;
@@ -2766,10 +2761,7 @@ static int nand_do_write_oob(struct mtd_info *mtd, loff_t to,
 	pr_debug("%s: to = 0x%08x, len = %i\n",
 			 __func__, (unsigned int)to, (int)ops->ooblen);
 
-	if (ops->mode == MTD_OPS_AUTO_OOB)
-		len = mtd->oobavail;
-	else
-		len = mtd->oobsize;
+	len = mtd_oobavail(mtd, ops);
 
 	/* Do not allow write past end of page */
 	if ((ops->ooboffs + ops->ooblen) > len) {
diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index d70bbfd..03a80de 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1124,11 +1124,7 @@ static int onenand_mlc_read_ops_nolock(struct mtd_info *mtd, loff_t from,
 	pr_debug("%s: from = 0x%08x, len = %i\n", __func__, (unsigned int)from,
 			(int)len);
 
-	if (ops->mode == MTD_OPS_AUTO_OOB)
-		oobsize = mtd->oobavail;
-	else
-		oobsize = mtd->oobsize;
-
+	oobsize = mtd_oobavail(mtd, ops);
 	oobcolumn = from & (mtd->oobsize - 1);
 
 	/* Do not allow reads past end of device */
@@ -1229,11 +1225,7 @@ static int onenand_read_ops_nolock(struct mtd_info *mtd, loff_t from,
 	pr_debug("%s: from = 0x%08x, len = %i\n", __func__, (unsigned int)from,
 			(int)len);
 
-	if (ops->mode == MTD_OPS_AUTO_OOB)
-		oobsize = mtd->oobavail;
-	else
-		oobsize = mtd->oobsize;
-
+	oobsize = mtd_oobavail(mtd, ops);
 	oobcolumn = from & (mtd->oobsize - 1);
 
 	/* Do not allow reads past end of device */
@@ -1885,12 +1877,7 @@ static int onenand_write_ops_nolock(struct mtd_info *mtd, loff_t to,
 	/* Check zero length */
 	if (!len)
 		return 0;
-
-	if (ops->mode == MTD_OPS_AUTO_OOB)
-		oobsize = mtd->oobavail;
-	else
-		oobsize = mtd->oobsize;
-
+	oobsize = mtd_oobavail(mtd, ops);
 	oobcolumn = to & (mtd->oobsize - 1);
 
 	column = to & (mtd->writesize - 1);
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 9cf13c4..7712721 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -264,6 +264,11 @@ static inline struct device_node *mtd_get_of_node(struct mtd_info *mtd)
 	return mtd->dev.of_node;
 }
 
+static inline int mtd_oobavail(struct mtd_info *mtd, struct mtd_oob_ops *ops)
+{
+	return ops->mode == MTD_OPS_AUTO_OOB ? mtd->oobavail : mtd->oobsize;
+}
+
 int mtd_erase(struct mtd_info *mtd, struct erase_info *instr);
 int mtd_point(struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen,
 	      void **virt, resource_size_t *phys);
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:23 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:23 +0100
Subject: [PATCH v2 00/51] mtd: rework ECC layout definition
Message-ID: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>

Hello,

This patchset aims at getting rid of the nand_ecclayout limitations.
struct nand_ecclayout is defining fixed eccpos and oobfree arrays which
can only be increased by modifying the MTD_MAX_ECCPOS_ENTRIES_LARGE and
MTD_MAX_OOBFREE_ENTRIES_LARGE macros.
This approach forces us to modify the macro values each time we add a
new NAND chip with a bigger OOB area, and increasing these arrays also
penalize all platforms, even those who only support small NAND devices
(with small OOB area).

The idea to overcome this limitation, is to define the ECC/OOB layout
by the mean of two functions: ->ecc() and ->free(), which will
basically return the same information has those stored in the
nand_ecclayout struct.

Another advantage of this solution is that ECC layouts are usually
following a repetitive pattern (i.e. leave X bytes free and put Y bytes
of ECC per ECC chunk), which allows one to implement the ->ecc()
and ->free() functions with a simple logic that can be applied
to any size of OOB.

Patches 1 to 4 are just cleanups or trivial fixes that can be taken
independently.

Also note that the last two commits are removing the nand_ecclayout
definition, thus preventing any new driver to use this structure.
Of course, this step can be delayed if some of the previous patches
are not accepted.

Best Regards,

Boris

Changes since v1:
- unified the way of defining ECC and free bytes
- fixed a few bugs in some ->ecc()/->free() implementations
- added new helpers to ease ECC and free bytes manipulation
- separated driver changes in different commits to ease review
- dropped already applied patches

Boris Brezillon (51):
  mtd: kill the ecclayout->oobavail field
  mtd: create an mtd_oobavail() helper and make use of it
  mtd: mtdswap: remove useless if (!mtd->ecclayout) test
  mtd: nand: simplify nand_bch_init() usage
  mtd: add mtd_ooblayout_xxx() helper functions
  mtd: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: core: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: atmel: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: fsl_ifc: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: gpmi: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: lpc32xx: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: onenand: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: add mtd_set_ecclayout() helper function
  mtd: use mtd_set_ecclayout() where appropriate
  mtd: nand: use mtd_set_ecclayout() where appropriate
  mtd: onenand: use mtd_set_ecclayout() where appropriate
  mtd: docg3: use mtd_set_ecclayout() where appropriate
  mtd: create an mtd_ooblayout_ops struct to ease ECC layout definition
  mtd: docg3: switch to mtd_ooblayout_ops
  mtd: nand: implement the default mtd_ooblayout_ops
  mtd: nand: bch: switch to mtd_ooblayout_ops
  mtd: nand: sharpsl: switch to mtd_ooblayout_ops
  mtd: nand: jz4740: switch to mtd_ooblayout_ops
  mtd: nand: atmel: switch to mtd_ooblayout_ops
  mtd: nand: bf5xx: switch to mtd_ooblayout_ops
  mtd: nand: brcm: switch to mtd_ooblayout_ops
  mtd: nand: cafe: switch to mtd_ooblayout_ops
  mtd: nand: davinci: switch to mtd_ooblayout_ops
  mtd: nand: denali: switch to mtd_ooblayout_ops
  mtd: nand: diskonchip: switch to mtd_ooblayout_ops
  mtd: nand: docg4: switch to mtd_ooblayout_ops
  mtd: nand: fsl_elbc: switch to mtd_ooblayout_ops
  mtd: nand: fsl_ifc: switch to mtd_ooblayout_ops
  mtd: nand: fsmc: switch to mtd_ooblayout_ops
  mtd: nand: gpmi: switch to mtd_ooblayout_ops
  mtd: nand: hisi504: switch to mtd_ooblayout_ops
  mtd: nand: jz4780: switch to mtd_ooblayout_ops
  mtd: nand: lpc32xx: switch to mtd_ooblayout_ops
  mtd: nand: mxc: switch to mtd_ooblayout_ops
  mtd: nand: omap2: switch to mtd_ooblayout_ops
  mtd: nand: pxa3xx: switch to mtd_ooblayout_ops
  mtd: nand: s3c2410: switch to mtd_ooblayout_ops
  mtd: nand: sh_flctl: switch to mtd_ooblayout_ops
  mtd: nand: sm_common: switch to mtd_ooblayout_ops
  mtd: nand: sunxi: switch to mtd_ooblayout_ops
  mtd: nand: vf610: switch to mtd_ooblayout_ops
  mtd: onenand: switch to mtd_ooblayout_ops
  staging: mt29f_spinand: switch to mtd_ooblayout_ops
  mtd: nand: kill the ecc->layout field
  mtd: kill the nand_ecclayout struct

 arch/arm/mach-pxa/spitz.c                       |  55 +++-
 arch/mips/include/asm/mach-jz4740/jz4740_nand.h |   2 +-
 arch/mips/jz4740/board-qi_lb60.c                |  87 +++---
 drivers/mtd/devices/docg3.c                     |  43 ++-
 drivers/mtd/mtdchar.c                           | 123 ++++++--
 drivers/mtd/mtdconcat.c                         |   2 +-
 drivers/mtd/mtdcore.c                           | 358 ++++++++++++++++++++++++
 drivers/mtd/mtdpart.c                           |  28 +-
 drivers/mtd/mtdswap.c                           |  24 +-
 drivers/mtd/nand/atmel_nand.c                   | 120 ++++----
 drivers/mtd/nand/bf5xx_nand.c                   |  51 ++--
 drivers/mtd/nand/brcmnand/brcmnand.c            | 262 ++++++++++-------
 drivers/mtd/nand/cafe_nand.c                    |  45 ++-
 drivers/mtd/nand/davinci_nand.c                 | 118 +++-----
 drivers/mtd/nand/denali.c                       |  51 +++-
 drivers/mtd/nand/diskonchip.c                   |  38 ++-
 drivers/mtd/nand/docg4.c                        |  34 ++-
 drivers/mtd/nand/fsl_elbc_nand.c                |  83 +++---
 drivers/mtd/nand/fsl_ifc_nand.c                 | 246 +++++-----------
 drivers/mtd/nand/fsmc_nand.c                    | 300 ++++++--------------
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c          |  61 ++--
 drivers/mtd/nand/hisi504_nand.c                 |  28 +-
 drivers/mtd/nand/jz4740_nand.c                  |   2 +-
 drivers/mtd/nand/jz4780_nand.c                  |  19 +-
 drivers/mtd/nand/lpc32xx_mlc.c                  |  50 ++--
 drivers/mtd/nand/lpc32xx_slc.c                  |  58 +++-
 drivers/mtd/nand/mxc_nand.c                     | 212 +++++++-------
 drivers/mtd/nand/nand_base.c                    | 334 +++++++++++-----------
 drivers/mtd/nand/nand_bch.c                     |  46 ++-
 drivers/mtd/nand/omap2.c                        | 241 +++++++++-------
 drivers/mtd/nand/pxa3xx_nand.c                  | 104 ++++---
 drivers/mtd/nand/s3c2410.c                      |  32 ++-
 drivers/mtd/nand/sh_flctl.c                     |  87 ++++--
 drivers/mtd/nand/sharpsl.c                      |   2 +-
 drivers/mtd/nand/sm_common.c                    |  93 ++++--
 drivers/mtd/nand/sunxi_nand.c                   | 114 ++++----
 drivers/mtd/nand/vf610_nfc.c                    |  34 +--
 drivers/mtd/onenand/onenand_base.c              | 254 ++++++++---------
 drivers/mtd/tests/oobtest.c                     |  49 ++--
 drivers/staging/mt29f_spinand/mt29f_spinand.c   |  49 ++--
 fs/jffs2/wbuf.c                                 |   6 +-
 include/linux/mtd/mtd.h                         |  69 ++++-
 include/linux/mtd/nand.h                        |   5 +-
 include/linux/mtd/nand_bch.h                    |   8 +-
 include/linux/mtd/onenand.h                     |   2 -
 include/linux/mtd/sharpsl.h                     |   2 +-
 include/uapi/mtd/mtd-abi.h                      |   2 +-
 47 files changed, 2349 insertions(+), 1684 deletions(-)

-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:24 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:24 +0100
Subject: [PATCH v2 01/51] mtd: kill the ecclayout->oobavail field
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-2-git-send-email-boris.brezillon@free-electrons.com>

ecclayout->oobavail is just redundant with the mtd->oobavail field.
Moreover, it prevents static const definition of ecc layouts since the
NAND framework is calculating this value based on the ecclayout->oobfree
field.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/devices/docg3.c                   |  5 ++-
 drivers/mtd/mtdswap.c                         | 16 ++++-----
 drivers/mtd/nand/brcmnand/brcmnand.c          |  8 ++---
 drivers/mtd/nand/docg4.c                      |  1 -
 drivers/mtd/nand/hisi504_nand.c               |  1 -
 drivers/mtd/nand/nand_base.c                  | 12 +++----
 drivers/mtd/onenand/onenand_base.c            | 16 ++++-----
 drivers/mtd/tests/oobtest.c                   | 49 +++++++++++++--------------
 drivers/staging/mt29f_spinand/mt29f_spinand.c |  1 -
 fs/jffs2/wbuf.c                               |  6 ++--
 include/linux/mtd/mtd.h                       |  1 -
 11 files changed, 51 insertions(+), 65 deletions(-)

diff --git a/drivers/mtd/devices/docg3.c b/drivers/mtd/devices/docg3.c
index c3a2695..e7b2e43 100644
--- a/drivers/mtd/devices/docg3.c
+++ b/drivers/mtd/devices/docg3.c
@@ -72,13 +72,11 @@ MODULE_PARM_DESC(reliable_mode, "Set the docg3 mode (0=normal MLC, 1=fast, "
  * @eccbytes: 8 bytes are used (1 for Hamming ECC, 7 for BCH ECC)
  * @eccpos: ecc positions (byte 7 is Hamming ECC, byte 8-14 are BCH ECC)
  * @oobfree: free pageinfo bytes (byte 0 until byte 6, byte 15
- * @oobavail: 8 available bytes remaining after ECC toll
  */
 static struct nand_ecclayout docg3_oobinfo = {
 	.eccbytes = 8,
 	.eccpos = {7, 8, 9, 10, 11, 12, 13, 14},
 	.oobfree = {{0, 7}, {15, 1} },
-	.oobavail = 8,
 };
 
 static inline u8 doc_readb(struct docg3 *docg3, u16 reg)
@@ -1438,7 +1436,7 @@ static int doc_write_oob(struct mtd_info *mtd, loff_t ofs,
 		oobdelta = mtd->oobsize;
 		break;
 	case MTD_OPS_AUTO_OOB:
-		oobdelta = mtd->ecclayout->oobavail;
+		oobdelta = mtd->oobavail;
 		break;
 	default:
 		return -EINVAL;
@@ -1860,6 +1858,7 @@ static int __init doc_set_driver_info(int chip_id, struct mtd_info *mtd)
 	mtd->_write_oob = doc_write_oob;
 	mtd->_block_isbad = doc_block_isbad;
 	mtd->ecclayout = &docg3_oobinfo;
+	mtd->oobavail = 8;
 	mtd->ecc_strength = DOC_ECC_BCH_T;
 
 	return 0;
diff --git a/drivers/mtd/mtdswap.c b/drivers/mtd/mtdswap.c
index fc8b3d1..d330eb1 100644
--- a/drivers/mtd/mtdswap.c
+++ b/drivers/mtd/mtdswap.c
@@ -346,7 +346,7 @@ static int mtdswap_read_markers(struct mtdswap_dev *d, struct swap_eb *eb)
 	if (mtd_can_have_bb(d->mtd) && mtd_block_isbad(d->mtd, offset))
 		return MTDSWAP_SCANNED_BAD;
 
-	ops.ooblen = 2 * d->mtd->ecclayout->oobavail;
+	ops.ooblen = 2 * d->mtd->oobavail;
 	ops.oobbuf = d->oob_buf;
 	ops.ooboffs = 0;
 	ops.datbuf = NULL;
@@ -359,7 +359,7 @@ static int mtdswap_read_markers(struct mtdswap_dev *d, struct swap_eb *eb)
 
 	data = (struct mtdswap_oobdata *)d->oob_buf;
 	data2 = (struct mtdswap_oobdata *)
-		(d->oob_buf + d->mtd->ecclayout->oobavail);
+		(d->oob_buf + d->mtd->oobavail);
 
 	if (le16_to_cpu(data->magic) == MTDSWAP_MAGIC_CLEAN) {
 		eb->erase_count = le32_to_cpu(data->count);
@@ -933,7 +933,7 @@ static unsigned int mtdswap_eblk_passes(struct mtdswap_dev *d,
 
 	ops.mode = MTD_OPS_AUTO_OOB;
 	ops.len = mtd->writesize;
-	ops.ooblen = mtd->ecclayout->oobavail;
+	ops.ooblen = mtd->oobavail;
 	ops.ooboffs = 0;
 	ops.datbuf = d->page_buf;
 	ops.oobbuf = d->oob_buf;
@@ -945,7 +945,7 @@ static unsigned int mtdswap_eblk_passes(struct mtdswap_dev *d,
 		for (i = 0; i < mtd_pages; i++) {
 			patt = mtdswap_test_patt(test + i);
 			memset(d->page_buf, patt, mtd->writesize);
-			memset(d->oob_buf, patt, mtd->ecclayout->oobavail);
+			memset(d->oob_buf, patt, mtd->oobavail);
 			ret = mtd_write_oob(mtd, pos, &ops);
 			if (ret)
 				goto error;
@@ -964,7 +964,7 @@ static unsigned int mtdswap_eblk_passes(struct mtdswap_dev *d,
 				if (p1[j] != patt)
 					goto error;
 
-			for (j = 0; j < mtd->ecclayout->oobavail; j++)
+			for (j = 0; j < mtd->oobavail; j++)
 				if (p2[j] != (unsigned char)patt)
 					goto error;
 
@@ -1387,7 +1387,7 @@ static int mtdswap_init(struct mtdswap_dev *d, unsigned int eblocks,
 	if (!d->page_buf)
 		goto page_buf_fail;
 
-	d->oob_buf = kmalloc(2 * mtd->ecclayout->oobavail, GFP_KERNEL);
+	d->oob_buf = kmalloc(2 * mtd->oobavail, GFP_KERNEL);
 	if (!d->oob_buf)
 		goto oob_buf_fail;
 
@@ -1454,10 +1454,10 @@ static void mtdswap_add_mtd(struct mtd_blktrans_ops *tr, struct mtd_info *mtd)
 		return;
 	}
 
-	if (!mtd->oobsize || oinfo->oobavail < MTDSWAP_OOBSIZE) {
+	if (!mtd->oobsize || mtd->oobavail < MTDSWAP_OOBSIZE) {
 		printk(KERN_ERR "%s: Not enough free bytes in OOB, "
 			"%d available, %zu needed.\n",
-			MTDSWAP_PREFIX, oinfo->oobavail, MTDSWAP_OOBSIZE);
+			MTDSWAP_PREFIX, mtd->oobavail, MTDSWAP_OOBSIZE);
 		return;
 	}
 
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c
index 844fc07..b86882b 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -796,7 +796,8 @@ static struct nand_ecclayout *brcmnand_create_layout(int ecc_level,
 				    idx2 >= MTD_MAX_OOBFREE_ENTRIES_LARGE - 1)
 				break;
 		}
-		goto out;
+
+		return layout;
 	}
 
 	/*
@@ -847,10 +848,7 @@ static struct nand_ecclayout *brcmnand_create_layout(int ecc_level,
 				idx2 >= MTD_MAX_OOBFREE_ENTRIES_LARGE - 1)
 			break;
 	}
-out:
-	/* Sum available OOB */
-	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES_LARGE; i++)
-		layout->oobavail += layout->oobfree[i].length;
+
 	return layout;
 }
 
diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c
index df4165b..fb46fd7 100644
--- a/drivers/mtd/nand/docg4.c
+++ b/drivers/mtd/nand/docg4.c
@@ -225,7 +225,6 @@ struct docg4_priv {
 static struct nand_ecclayout docg4_oobinfo = {
 	.eccbytes = 9,
 	.eccpos = {7, 8, 9, 10, 11, 12, 13, 14, 15},
-	.oobavail = 5,
 	.oobfree = { {.offset = 2, .length = 5} }
 };
 
diff --git a/drivers/mtd/nand/hisi504_nand.c b/drivers/mtd/nand/hisi504_nand.c
index f8d37f3..96502b6 100644
--- a/drivers/mtd/nand/hisi504_nand.c
+++ b/drivers/mtd/nand/hisi504_nand.c
@@ -632,7 +632,6 @@ static void hisi_nfc_host_init(struct hinfc_host *host)
 }
 
 static struct nand_ecclayout nand_ecc_2K_16bits = {
-	.oobavail = 6,
 	.oobfree = { {2, 6} },
 };
 
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index f2c8ff3..21c48ff 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2076,7 +2076,7 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
 	stats = mtd->ecc_stats;
 
 	if (ops->mode == MTD_OPS_AUTO_OOB)
-		len = chip->ecc.layout->oobavail;
+		len = mtd->oobavail;
 	else
 		len = mtd->oobsize;
 
@@ -2767,7 +2767,7 @@ static int nand_do_write_oob(struct mtd_info *mtd, loff_t to,
 			 __func__, (unsigned int)to, (int)ops->ooblen);
 
 	if (ops->mode == MTD_OPS_AUTO_OOB)
-		len = chip->ecc.layout->oobavail;
+		len = mtd->oobavail;
 	else
 		len = mtd->oobsize;
 
@@ -4325,11 +4325,9 @@ int nand_scan_tail(struct mtd_info *mtd)
 	 * The number of bytes available for a client to place data into
 	 * the out of band area.
 	 */
-	ecc->layout->oobavail = 0;
-	for (i = 0; ecc->layout->oobfree[i].length
-			&& i < ARRAY_SIZE(ecc->layout->oobfree); i++)
-		ecc->layout->oobavail += ecc->layout->oobfree[i].length;
-	mtd->oobavail = ecc->layout->oobavail;
+	mtd->oobavail = 0;
+	for (i = 0; ecc->layout->oobfree[i].length; i++)
+		mtd->oobavail += ecc->layout->oobfree[i].length;
 
 	/* ECC sanity check: warn if it's too weak */
 	if (!nand_ecc_strength_good(mtd))
diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index 43b3392..d70bbfd 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1125,7 +1125,7 @@ static int onenand_mlc_read_ops_nolock(struct mtd_info *mtd, loff_t from,
 			(int)len);
 
 	if (ops->mode == MTD_OPS_AUTO_OOB)
-		oobsize = this->ecclayout->oobavail;
+		oobsize = mtd->oobavail;
 	else
 		oobsize = mtd->oobsize;
 
@@ -1230,7 +1230,7 @@ static int onenand_read_ops_nolock(struct mtd_info *mtd, loff_t from,
 			(int)len);
 
 	if (ops->mode == MTD_OPS_AUTO_OOB)
-		oobsize = this->ecclayout->oobavail;
+		oobsize = mtd->oobavail;
 	else
 		oobsize = mtd->oobsize;
 
@@ -1365,7 +1365,7 @@ static int onenand_read_oob_nolock(struct mtd_info *mtd, loff_t from,
 	ops->oobretlen = 0;
 
 	if (mode == MTD_OPS_AUTO_OOB)
-		oobsize = this->ecclayout->oobavail;
+		oobsize = mtd->oobavail;
 	else
 		oobsize = mtd->oobsize;
 
@@ -1887,7 +1887,7 @@ static int onenand_write_ops_nolock(struct mtd_info *mtd, loff_t to,
 		return 0;
 
 	if (ops->mode == MTD_OPS_AUTO_OOB)
-		oobsize = this->ecclayout->oobavail;
+		oobsize = mtd->oobavail;
 	else
 		oobsize = mtd->oobsize;
 
@@ -2063,7 +2063,7 @@ static int onenand_write_oob_nolock(struct mtd_info *mtd, loff_t to,
 	ops->oobretlen = 0;
 
 	if (mode == MTD_OPS_AUTO_OOB)
-		oobsize = this->ecclayout->oobavail;
+		oobsize = mtd->oobavail;
 	else
 		oobsize = mtd->oobsize;
 
@@ -4049,12 +4049,10 @@ int onenand_scan(struct mtd_info *mtd, int maxchips)
 	 * The number of bytes available for a client to place data into
 	 * the out of band area
 	 */
-	this->ecclayout->oobavail = 0;
+	mtd->oobavail = 0;
 	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES &&
 	    this->ecclayout->oobfree[i].length; i++)
-		this->ecclayout->oobavail +=
-			this->ecclayout->oobfree[i].length;
-	mtd->oobavail = this->ecclayout->oobavail;
+		mtd->oobavail += this->ecclayout->oobfree[i].length;
 
 	mtd->ecclayout = this->ecclayout;
 	mtd->ecc_strength = 1;
diff --git a/drivers/mtd/tests/oobtest.c b/drivers/mtd/tests/oobtest.c
index 3176212..1cb3f77 100644
--- a/drivers/mtd/tests/oobtest.c
+++ b/drivers/mtd/tests/oobtest.c
@@ -215,19 +215,19 @@ static int verify_eraseblock(int ebnum)
 			pr_info("ignoring error as within bitflip_limit\n");
 		}
 
-		if (use_offset != 0 || use_len < mtd->ecclayout->oobavail) {
+		if (use_offset != 0 || use_len < mtd->oobavail) {
 			int k;
 
 			ops.mode      = MTD_OPS_AUTO_OOB;
 			ops.len       = 0;
 			ops.retlen    = 0;
-			ops.ooblen    = mtd->ecclayout->oobavail;
+			ops.ooblen    = mtd->oobavail;
 			ops.oobretlen = 0;
 			ops.ooboffs   = 0;
 			ops.datbuf    = NULL;
 			ops.oobbuf    = readbuf;
 			err = mtd_read_oob(mtd, addr, &ops);
-			if (err || ops.oobretlen != mtd->ecclayout->oobavail) {
+			if (err || ops.oobretlen != mtd->oobavail) {
 				pr_err("error: readoob failed at %#llx\n",
 						(long long)addr);
 				errcnt += 1;
@@ -244,7 +244,7 @@ static int verify_eraseblock(int ebnum)
 			/* verify post-(use_offset + use_len) area for 0xff */
 			k = use_offset + use_len;
 			bitflips += memffshow(addr, k, readbuf + k,
-					      mtd->ecclayout->oobavail - k);
+					      mtd->oobavail - k);
 
 			if (bitflips > bitflip_limit) {
 				pr_err("error: verify failed at %#llx\n",
@@ -269,8 +269,8 @@ static int verify_eraseblock_in_one_go(int ebnum)
 	struct mtd_oob_ops ops;
 	int err = 0;
 	loff_t addr = (loff_t)ebnum * mtd->erasesize;
-	size_t len = mtd->ecclayout->oobavail * pgcnt;
-	size_t oobavail = mtd->ecclayout->oobavail;
+	size_t len = mtd->oobavail * pgcnt;
+	size_t oobavail = mtd->oobavail;
 	size_t bitflips;
 	int i;
 
@@ -394,8 +394,8 @@ static int __init mtd_oobtest_init(void)
 		goto out;
 
 	use_offset = 0;
-	use_len = mtd->ecclayout->oobavail;
-	use_len_max = mtd->ecclayout->oobavail;
+	use_len = mtd->oobavail;
+	use_len_max = mtd->oobavail;
 	vary_offset = 0;
 
 	/* First test: write all OOB, read it back and verify */
@@ -460,8 +460,8 @@ static int __init mtd_oobtest_init(void)
 
 	/* Write all eraseblocks */
 	use_offset = 0;
-	use_len = mtd->ecclayout->oobavail;
-	use_len_max = mtd->ecclayout->oobavail;
+	use_len = mtd->oobavail;
+	use_len_max = mtd->oobavail;
 	vary_offset = 1;
 	prandom_seed_state(&rnd_state, 5);
 
@@ -471,8 +471,8 @@ static int __init mtd_oobtest_init(void)
 
 	/* Check all eraseblocks */
 	use_offset = 0;
-	use_len = mtd->ecclayout->oobavail;
-	use_len_max = mtd->ecclayout->oobavail;
+	use_len = mtd->oobavail;
+	use_len_max = mtd->oobavail;
 	vary_offset = 1;
 	prandom_seed_state(&rnd_state, 5);
 	err = verify_all_eraseblocks();
@@ -480,8 +480,8 @@ static int __init mtd_oobtest_init(void)
 		goto out;
 
 	use_offset = 0;
-	use_len = mtd->ecclayout->oobavail;
-	use_len_max = mtd->ecclayout->oobavail;
+	use_len = mtd->oobavail;
+	use_len_max = mtd->oobavail;
 	vary_offset = 0;
 
 	/* Fourth test: try to write off end of device */
@@ -501,7 +501,7 @@ static int __init mtd_oobtest_init(void)
 	ops.retlen    = 0;
 	ops.ooblen    = 1;
 	ops.oobretlen = 0;
-	ops.ooboffs   = mtd->ecclayout->oobavail;
+	ops.ooboffs   = mtd->oobavail;
 	ops.datbuf    = NULL;
 	ops.oobbuf    = writebuf;
 	pr_info("attempting to start write past end of OOB\n");
@@ -521,7 +521,7 @@ static int __init mtd_oobtest_init(void)
 	ops.retlen    = 0;
 	ops.ooblen    = 1;
 	ops.oobretlen = 0;
-	ops.ooboffs   = mtd->ecclayout->oobavail;
+	ops.ooboffs   = mtd->oobavail;
 	ops.datbuf    = NULL;
 	ops.oobbuf    = readbuf;
 	pr_info("attempting to start read past end of OOB\n");
@@ -543,7 +543,7 @@ static int __init mtd_oobtest_init(void)
 		ops.mode      = MTD_OPS_AUTO_OOB;
 		ops.len       = 0;
 		ops.retlen    = 0;
-		ops.ooblen    = mtd->ecclayout->oobavail + 1;
+		ops.ooblen    = mtd->oobavail + 1;
 		ops.oobretlen = 0;
 		ops.ooboffs   = 0;
 		ops.datbuf    = NULL;
@@ -563,7 +563,7 @@ static int __init mtd_oobtest_init(void)
 		ops.mode      = MTD_OPS_AUTO_OOB;
 		ops.len       = 0;
 		ops.retlen    = 0;
-		ops.ooblen    = mtd->ecclayout->oobavail + 1;
+		ops.ooblen    = mtd->oobavail + 1;
 		ops.oobretlen = 0;
 		ops.ooboffs   = 0;
 		ops.datbuf    = NULL;
@@ -587,7 +587,7 @@ static int __init mtd_oobtest_init(void)
 		ops.mode      = MTD_OPS_AUTO_OOB;
 		ops.len       = 0;
 		ops.retlen    = 0;
-		ops.ooblen    = mtd->ecclayout->oobavail;
+		ops.ooblen    = mtd->oobavail;
 		ops.oobretlen = 0;
 		ops.ooboffs   = 1;
 		ops.datbuf    = NULL;
@@ -607,7 +607,7 @@ static int __init mtd_oobtest_init(void)
 		ops.mode      = MTD_OPS_AUTO_OOB;
 		ops.len       = 0;
 		ops.retlen    = 0;
-		ops.ooblen    = mtd->ecclayout->oobavail;
+		ops.ooblen    = mtd->oobavail;
 		ops.oobretlen = 0;
 		ops.ooboffs   = 1;
 		ops.datbuf    = NULL;
@@ -638,7 +638,7 @@ static int __init mtd_oobtest_init(void)
 	for (i = 0; i < ebcnt - 1; ++i) {
 		int cnt = 2;
 		int pg;
-		size_t sz = mtd->ecclayout->oobavail;
+		size_t sz = mtd->oobavail;
 		if (bbt[i] || bbt[i + 1])
 			continue;
 		addr = (loff_t)(i + 1) * mtd->erasesize - mtd->writesize;
@@ -673,13 +673,12 @@ static int __init mtd_oobtest_init(void)
 	for (i = 0; i < ebcnt - 1; ++i) {
 		if (bbt[i] || bbt[i + 1])
 			continue;
-		prandom_bytes_state(&rnd_state, writebuf,
-					mtd->ecclayout->oobavail * 2);
+		prandom_bytes_state(&rnd_state, writebuf, mtd->oobavail * 2);
 		addr = (loff_t)(i + 1) * mtd->erasesize - mtd->writesize;
 		ops.mode      = MTD_OPS_AUTO_OOB;
 		ops.len       = 0;
 		ops.retlen    = 0;
-		ops.ooblen    = mtd->ecclayout->oobavail * 2;
+		ops.ooblen    = mtd->oobavail * 2;
 		ops.oobretlen = 0;
 		ops.ooboffs   = 0;
 		ops.datbuf    = NULL;
@@ -688,7 +687,7 @@ static int __init mtd_oobtest_init(void)
 		if (err)
 			goto out;
 		if (memcmpshow(addr, readbuf, writebuf,
-			       mtd->ecclayout->oobavail * 2)) {
+			       mtd->oobavail * 2)) {
 			pr_err("error: verify failed at %#llx\n",
 			       (long long)addr);
 			errcnt += 1;
diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c b/drivers/staging/mt29f_spinand/mt29f_spinand.c
index 197d112..6728376 100644
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -49,7 +49,6 @@ static struct nand_ecclayout spinand_oob_64 = {
 		17, 18, 19, 20, 21, 22,
 		33, 34, 35, 36, 37, 38,
 		49, 50, 51, 52, 53, 54, },
-	.oobavail = 32,
 	.oobfree = {
 		{.offset = 8,
 			.length = 8},
diff --git a/fs/jffs2/wbuf.c b/fs/jffs2/wbuf.c
index 5a3da3f..b25d28a 100644
--- a/fs/jffs2/wbuf.c
+++ b/fs/jffs2/wbuf.c
@@ -1183,22 +1183,20 @@ void jffs2_dirty_trigger(struct jffs2_sb_info *c)
 
 int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
 {
-	struct nand_ecclayout *oinfo = c->mtd->ecclayout;
-
 	if (!c->mtd->oobsize)
 		return 0;
 
 	/* Cleanmarker is out-of-band, so inline size zero */
 	c->cleanmarker_size = 0;
 
-	if (!oinfo || oinfo->oobavail == 0) {
+	if (c->mtd->oobavail == 0) {
 		pr_err("inconsistent device description\n");
 		return -EINVAL;
 	}
 
 	jffs2_dbg(1, "using OOB on NAND\n");
 
-	c->oobavail = oinfo->oobavail;
+	c->oobavail = c->mtd->oobavail;
 
 	/* Initialise write buffer */
 	init_rwsem(&c->wbuf_sem);
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index cc84923..9cf13c4 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -105,7 +105,6 @@ struct mtd_oob_ops {
 struct nand_ecclayout {
 	__u32 eccbytes;
 	__u32 eccpos[MTD_MAX_ECCPOS_ENTRIES_LARGE];
-	__u32 oobavail;
 	struct nand_oobfree oobfree[MTD_MAX_OOBFREE_ENTRIES_LARGE];
 };
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:26 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:26 +0100
Subject: [PATCH v2 03/51] mtd: mtdswap: remove useless if (!mtd->ecclayout)
 test
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-4-git-send-email-boris.brezillon@free-electrons.com>

If the MTD device does not have OOB, the mtd->oobsize and mtd->oobavail
fields are set to zero, and we are testing those values in the following
test.
Remove the useless if (!mtd->ecclayout) test.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/mtdswap.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/mtd/mtdswap.c b/drivers/mtd/mtdswap.c
index d330eb1..cb06bdd 100644
--- a/drivers/mtd/mtdswap.c
+++ b/drivers/mtd/mtdswap.c
@@ -1417,7 +1417,6 @@ static void mtdswap_add_mtd(struct mtd_blktrans_ops *tr, struct mtd_info *mtd)
 	unsigned long part;
 	unsigned int eblocks, eavailable, bad_blocks, spare_cnt;
 	uint64_t swap_size, use_size, size_limit;
-	struct nand_ecclayout *oinfo;
 	int ret;
 
 	parts = &partitions[0];
@@ -1447,13 +1446,6 @@ static void mtdswap_add_mtd(struct mtd_blktrans_ops *tr, struct mtd_info *mtd)
 		return;
 	}
 
-	oinfo = mtd->ecclayout;
-	if (!oinfo) {
-		printk(KERN_ERR "%s: mtd%d does not have OOB\n",
-			MTDSWAP_PREFIX, mtd->index);
-		return;
-	}
-
 	if (!mtd->oobsize || mtd->oobavail < MTDSWAP_OOBSIZE) {
 		printk(KERN_ERR "%s: Not enough free bytes in OOB, "
 			"%d available, %zu needed.\n",
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:29 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:29 +0100
Subject: [PATCH v2 06/51] mtd: use mtd_ooblayout_xxx() helpers where
 appropriate
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-7-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/mtdchar.c | 107 +++++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 88 insertions(+), 19 deletions(-)

diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index 6d19835..cd64ab7 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -472,28 +472,101 @@ static int mtdchar_readoob(struct file *file, struct mtd_info *mtd,
  * nand_ecclayout flexibly (i.e. the struct may change size in new
  * releases without requiring major rewrites).
  */
-static int shrink_ecclayout(const struct nand_ecclayout *from,
-		struct nand_ecclayout_user *to)
+static int shrink_ecclayout(struct mtd_info *mtd,
+			    struct nand_ecclayout_user *to)
 {
-	int i;
+	struct mtd_oob_region oobregion;
+	int i, section = 0, ret;
 
-	if (!from || !to)
+	if (!mtd || !to)
 		return -EINVAL;
 
 	memset(to, 0, sizeof(*to));
 
-	to->eccbytes = min((int)from->eccbytes, MTD_MAX_ECCPOS_ENTRIES);
-	for (i = 0; i < to->eccbytes; i++)
-		to->eccpos[i] = from->eccpos[i];
+	to->eccbytes = 0;
+	for (i = 0; i < MTD_MAX_ECCPOS_ENTRIES;) {
+		u32 eccpos;
+
+		ret = mtd_ooblayout_ecc(mtd, section, &oobregion);
+		if (ret < 0) {
+			if (ret != -ERANGE)
+				return ret;
+
+			break;
+		}
+
+		eccpos = oobregion.offset;
+		for (; i < MTD_MAX_ECCPOS_ENTRIES &&
+		       eccpos < oobregion.offset + oobregion.length; i++) {
+			to->eccpos[i] = eccpos++;
+			to->eccbytes++;
+		}
+	}
 
 	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES; i++) {
-		if (from->oobfree[i].length == 0 &&
-				from->oobfree[i].offset == 0)
+		ret = mtd_ooblayout_free(mtd, i, &oobregion);
+		if (ret < 0) {
+			if (ret != -ERANGE)
+				return ret;
+
+			break;
+		}
+
+		to->oobfree[i].offset = oobregion.offset;
+		to->oobfree[i].length = oobregion.length;
+		to->oobavail += to->oobfree[i].length;
+	}
+
+	return 0;
+}
+
+static int get_oobinfo(struct mtd_info *mtd, struct nand_oobinfo *to)
+{
+	struct mtd_oob_region oobregion;
+	int i, section = 0, ret;
+
+	if (!mtd || !to)
+		return -EINVAL;
+
+	memset(to, 0, sizeof(*to));
+
+	to->eccbytes = 0;
+	for (i = 0; i < ARRAY_SIZE(to->eccpos);) {
+		u32 eccpos;
+
+		ret = mtd_ooblayout_ecc(mtd, section, &oobregion);
+		if (ret < 0) {
+			if (ret != -ERANGE)
+				return ret;
+
 			break;
-		to->oobavail += from->oobfree[i].length;
-		to->oobfree[i] = from->oobfree[i];
+		}
+
+		if (oobregion.length + i > ARRAY_SIZE(to->eccpos))
+			return -EINVAL;
+
+		eccpos = oobregion.offset;
+		for (; eccpos < oobregion.offset + oobregion.length; i++) {
+			to->eccpos[i] = eccpos++;
+			to->eccbytes++;
+		}
 	}
 
+	for (i = 0; i < 8; i++) {
+		ret = mtd_ooblayout_free(mtd, i, &oobregion);
+		if (ret < 0) {
+			if (ret != -ERANGE)
+				return ret;
+
+			break;
+		}
+
+		to->oobfree[i][0] = oobregion.offset;
+		to->oobfree[i][1] = oobregion.length;
+	}
+
+	to->useecc = MTD_NANDECC_AUTOPLACE;
+
 	return 0;
 }
 
@@ -817,14 +890,10 @@ static int mtdchar_ioctl(struct file *file, u_int cmd, u_long arg)
 
 		if (!mtd->ecclayout)
 			return -EOPNOTSUPP;
-		if (mtd->ecclayout->eccbytes > ARRAY_SIZE(oi.eccpos))
-			return -EINVAL;
 
-		oi.useecc = MTD_NANDECC_AUTOPLACE;
-		memcpy(&oi.eccpos, mtd->ecclayout->eccpos, sizeof(oi.eccpos));
-		memcpy(&oi.oobfree, mtd->ecclayout->oobfree,
-		       sizeof(oi.oobfree));
-		oi.eccbytes = mtd->ecclayout->eccbytes;
+		ret = get_oobinfo(mtd, &oi);
+		if (ret)
+			return ret;
 
 		if (copy_to_user(argp, &oi, sizeof(struct nand_oobinfo)))
 			return -EFAULT;
@@ -920,7 +989,7 @@ static int mtdchar_ioctl(struct file *file, u_int cmd, u_long arg)
 		if (!usrlay)
 			return -ENOMEM;
 
-		shrink_ecclayout(mtd->ecclayout, usrlay);
+		shrink_ecclayout(mtd, usrlay);
 
 		if (copy_to_user(argp, usrlay, sizeof(*usrlay)))
 			ret = -EFAULT;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:39 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:39 +0100
Subject: [PATCH v2 16/51] mtd: nand: use mtd_set_ecclayout() where appropriate
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-17-git-send-email-boris.brezillon@free-electrons.com>

Use the mtd_set_ecclayout() helper instead of directly assigning the
mtd->ecclayout field.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/nand_base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index e01a9b5..a01b472 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -4367,7 +4367,7 @@ int nand_scan_tail(struct mtd_info *mtd)
 	mtd->writebufsize = mtd->writesize;
 
 	/* propagate ecc info to mtd_info */
-	mtd->ecclayout = ecc->layout;
+	mtd_set_ecclayout(mtd, ecc->layout);
 	mtd->ecc_strength = ecc->strength;
 	mtd->ecc_step_size = ecc->size;
 	/*
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:41 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:41 +0100
Subject: [PATCH v2 18/51] mtd: docg3: use mtd_set_ecclayout() where appropriate
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-19-git-send-email-boris.brezillon@free-electrons.com>

Use the mtd_set_ecclayout() helper instead of directly assigning the
mtd->ecclayout field.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/devices/docg3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/devices/docg3.c b/drivers/mtd/devices/docg3.c
index e7b2e43..6b516e1 100644
--- a/drivers/mtd/devices/docg3.c
+++ b/drivers/mtd/devices/docg3.c
@@ -1857,7 +1857,7 @@ static int __init doc_set_driver_info(int chip_id, struct mtd_info *mtd)
 	mtd->_read_oob = doc_read_oob;
 	mtd->_write_oob = doc_write_oob;
 	mtd->_block_isbad = doc_block_isbad;
-	mtd->ecclayout = &docg3_oobinfo;
+	mtd_set_ecclayout(mtd, &docg3_oobinfo);
 	mtd->oobavail = 8;
 	mtd->ecc_strength = DOC_ECC_BCH_T;
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:54 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:54 +0100
Subject: [PATCH v2 31/51] mtd: nand: diskonchip: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-32-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/diskonchip.c | 38 +++++++++++++++++++++++++++++++++-----
 1 file changed, 33 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c
index f170f3c..9fb63b4 100644
--- a/drivers/mtd/nand/diskonchip.c
+++ b/drivers/mtd/nand/diskonchip.c
@@ -960,10 +960,38 @@ static int doc200x_correct_data(struct mtd_info *mtd, u_char *dat,
  * safer.  The only problem with it is that any code that parses oobfree must
  * be able to handle out-of-order segments.
  */
-static struct nand_ecclayout doc200x_oobinfo = {
-	.eccbytes = 6,
-	.eccpos = {0, 1, 2, 3, 4, 5},
-	.oobfree = {{8, 8}, {6, 2}}
+static int doc200x_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 0;
+	oobregion->length = 6;
+
+	return 0;
+}
+
+static int doc200x_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	if (section > 1)
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 8;
+		oobregion->length = 8;
+	} else {
+		oobregion->offset = 6;
+		oobregion->length = 2;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops doc200x_ooblayout_ops = {
+	.ecc = doc200x_ooblayout_ecc,
+	.free = doc200x_ooblayout_free,
 };
 
 /* Find the (I)NFTL Media Header, and optionally also the mirror media header.
@@ -1537,6 +1565,7 @@ static int __init doc_probe(unsigned long physadr)
 	nand->bbt_md		= nand->bbt_td + 1;
 
 	mtd->owner		= THIS_MODULE;
+	mtd_set_ooblayout(mtd, &doc200x_ooblayout_ops);
 
 	nand_set_controller_data(nand, doc);
 	nand->select_chip	= doc200x_select_chip;
@@ -1548,7 +1577,6 @@ static int __init doc_probe(unsigned long physadr)
 	nand->ecc.calculate	= doc200x_calculate_ecc;
 	nand->ecc.correct	= doc200x_correct_data;
 
-	nand->ecc.layout	= &doc200x_oobinfo;
 	nand->ecc.mode		= NAND_ECC_HW_SYNDROME;
 	nand->ecc.size		= 512;
 	nand->ecc.bytes		= 6;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:37 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:37 +0100
Subject: [PATCH v2 14/51] mtd: add mtd_set_ecclayout() helper function
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-15-git-send-email-boris.brezillon@free-electrons.com>

Add an mtd_set_ecclayout() helper function to avoid direct accesses to the
mtd->ecclayout field. This will ease future reworks of ECC layout
definition.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 include/linux/mtd/mtd.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index b141f26..6250dd8 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -286,6 +286,12 @@ int mtd_ooblayout_set_databytes(struct mtd_info *mtd, const u8 *databuf,
 int mtd_ooblayout_count_freebytes(struct mtd_info *mtd);
 int mtd_ooblayout_count_eccbytes(struct mtd_info *mtd);
 
+static inline void mtd_set_ecclayout(struct mtd_info *mtd,
+				     struct nand_ecclayout *ecclayout)
+{
+	mtd->ecclayout = ecclayout;
+}
+
 static inline void mtd_set_of_node(struct mtd_info *mtd,
 				   struct device_node *np)
 {
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:42 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:42 +0100
Subject: [PATCH v2 19/51] mtd: create an mtd_ooblayout_ops struct to ease ECC
 layout definition
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-20-git-send-email-boris.brezillon@free-electrons.com>

ECC layout definitions are currently exposed using the nand_ecclayout
struct which embeds oobfree and eccpos arrays with predefined size.
This approach was acceptable when NAND chips were providing relatively
small OOB regions, but MLC and TLC now provide OOB regions of several
hundreds of bytes, which implies a non negligible overhead for everybody
even those who only need to support legacy NANDs.

Create an mtd_ooblayout_ops interface providing the same functionality
(expose the ECC and oobfree layout) without the need for this huge
structure.

The mtd->ecclayout is now deprecated and should be replaced by the
equivalent mtd_ooblayout_ops. In the meantime we provide a wrapper around
the ->ecclayout field to ease migration to this new model.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/mtdchar.c   |   4 +-
 drivers/mtd/mtdconcat.c |   2 +-
 drivers/mtd/mtdcore.c   | 171 +++++++++++++++++++++++++++++++++++-------------
 drivers/mtd/mtdpart.c   |  23 ++++++-
 include/linux/mtd/mtd.h |  32 +++++++--
 5 files changed, 177 insertions(+), 55 deletions(-)

diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index cd64ab7..3fad2c7 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -888,7 +888,7 @@ static int mtdchar_ioctl(struct file *file, u_int cmd, u_long arg)
 	{
 		struct nand_oobinfo oi;
 
-		if (!mtd->ecclayout)
+		if (!mtd->ooblayout)
 			return -EOPNOTSUPP;
 
 		ret = get_oobinfo(mtd, &oi);
@@ -982,7 +982,7 @@ static int mtdchar_ioctl(struct file *file, u_int cmd, u_long arg)
 	{
 		struct nand_ecclayout_user *usrlay;
 
-		if (!mtd->ecclayout)
+		if (!mtd->ooblayout)
 			return -EOPNOTSUPP;
 
 		usrlay = kmalloc(sizeof(*usrlay), GFP_KERNEL);
diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c
index 481565e..d573606 100644
--- a/drivers/mtd/mtdconcat.c
+++ b/drivers/mtd/mtdconcat.c
@@ -777,7 +777,7 @@ struct mtd_info *mtd_concat_create(struct mtd_info *subdev[],	/* subdevices to c
 
 	}
 
-	mtd_set_ecclayout(&concat->mtd, subdev[0]->ecclayout);
+	mtd_set_ooblayout(&concat->mtd, subdev[0]->ooblayout);
 
 	concat->num_subdev = num_devs;
 	concat->mtd.name = name;
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 14e46ca..dccd132 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1016,52 +1016,15 @@ EXPORT_SYMBOL_GPL(mtd_read_oob);
 int mtd_ooblayout_ecc(struct mtd_info *mtd, int section,
 		      struct mtd_oob_region *oobecc)
 {
-	int eccbyte = 0, cursection = 0, length = 0, eccpos = 0;
-
 	memset(oobecc, 0, sizeof(*oobecc));
 
 	if (!mtd || section < 0)
 		return -EINVAL;
 
-	if (!mtd->ecclayout)
+	if (!mtd->ooblayout || !mtd->ooblayout->ecc)
 		return -ENOTSUPP;
 
-	if (mtd->ecclayout->eccbytes < 1)
-		return -ERANGE;
-
-	/*
-	 * This logic allows us to reuse the ->ecclayout information and
-	 * expose them as ECC regions (as done for the OOB free regions).
-	 *
-	 * TODO: this should be dropped as soon as we get rid of the
-	 * ->ecclayout field.
-	 */
-	for (eccbyte = 0; eccbyte < mtd->ecclayout->eccbytes; eccbyte++) {
-		eccpos = mtd->ecclayout->eccpos[eccbyte];
-
-		if (eccbyte < mtd->ecclayout->eccbytes - 1) {
-			int neccpos = mtd->ecclayout->eccpos[eccbyte + 1];
-
-			if (eccpos + 1 == neccpos) {
-				length++;
-				continue;
-			}
-		}
-
-		if (section == cursection)
-			break;
-
-		length = 0;
-		cursection++;
-	}
-
-	if (cursection != section)
-		return -ERANGE;
-
-	oobecc->length = length + 1;
-	oobecc->offset = eccpos - length;
-
-	return 0;
+	return mtd->ooblayout->ecc(mtd, section, oobecc);
 }
 EXPORT_SYMBOL_GPL(mtd_ooblayout_ecc);
 
@@ -1090,16 +1053,10 @@ int mtd_ooblayout_free(struct mtd_info *mtd, int section,
 	if (!mtd || section < 0)
 		return -EINVAL;
 
-	if (!mtd->ecclayout)
+	if (!mtd->ooblayout || !mtd->ooblayout->free)
 		return -ENOTSUPP;
 
-	if (section >= MTD_MAX_OOBFREE_ENTRIES_LARGE)
-		return -ERANGE;
-
-	oobfree->offset = mtd->ecclayout->oobfree[section].offset;
-	oobfree->length = mtd->ecclayout->oobfree[section].length;
-
-	return 0;
+	return mtd->ooblayout->free(mtd, section, oobfree);
 }
 EXPORT_SYMBOL_GPL(mtd_ooblayout_free);
 
@@ -1398,6 +1355,126 @@ int mtd_ooblayout_count_eccbytes(struct mtd_info *mtd)
 }
 EXPORT_SYMBOL_GPL(mtd_ooblayout_count_eccbytes);
 
+/**
+ * mtd_ecclayout_ecc - Default ooblayout_ecc iterator implementation
+ * @mtd: MTD device structure
+ * @section: ECC section. Depending on the layout you may have all the ECC
+ *	     bytes stored in a single contiguous section, or one section
+ *	     per ECC chunk (and sometime several sections for a single ECC
+ *	     ECC chunk)
+ * @oobecc: OOB region struct filled with the appropriate ECC position
+ *	    information
+ *
+ * This function is just a wrapper around the mtd->ecclayout field and is
+ * here to ease the transition to the mtd_ooblayout_ops approach.
+ * All it does is convert the layout->eccpos information into proper oob
+ * region definitions.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+static int mtd_ecclayout_ecc(struct mtd_info *mtd, int section,
+			     struct mtd_oob_region *oobecc)
+{
+	int eccbyte = 0, cursection = 0, length = 0, eccpos = 0;
+
+	if (!mtd->ecclayout)
+		return -ENOTSUPP;
+
+	if (mtd->ecclayout->eccbytes < 1)
+		return -ERANGE;
+
+	/*
+	 * This logic allows us to reuse the ->ecclayout information and
+	 * expose them as ECC regions (as done for the OOB free regions).
+	 *
+	 * TODO: this should be dropped as soon as we get rid of the
+	 * ->ecclayout field.
+	 */
+	for (eccbyte = 0; eccbyte < mtd->ecclayout->eccbytes; eccbyte++) {
+		eccpos = mtd->ecclayout->eccpos[eccbyte];
+
+		if (eccbyte < mtd->ecclayout->eccbytes - 1) {
+			int neccpos = mtd->ecclayout->eccpos[eccbyte + 1];
+
+			if (eccpos + 1 == neccpos) {
+				length++;
+				continue;
+			}
+		}
+
+		if (section == cursection)
+			break;
+
+		length = 0;
+		cursection++;
+	}
+
+	if (cursection != section)
+		return -ERANGE;
+
+	oobecc->length = length + 1;
+	oobecc->offset = eccpos - length;
+
+	return 0;
+}
+
+/**
+ * mtd_ecclayout_ecc - Default ooblayout_free iterator implementation
+ * @mtd: MTD device structure
+ * @section: Free section. Depending on the layout you may have all the free
+ *	     bytes stored in a single contiguous section, or one section
+ *	     per ECC chunk (and sometime several sections for a single ECC
+ *	     ECC chunk)
+ * @oobfree: OOB region struct filled with the appropriate free position
+ *	     information
+ *
+ * This function is just a wrapper around the mtd->ecclayout field and is
+ * here to ease the transition to the mtd_ooblayout_ops approach.
+ * All it does is convert the layout->oobfree information into proper oob
+ * region definitions.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+static int mtd_ecclayout_free(struct mtd_info *mtd, int section,
+			      struct mtd_oob_region *oobfree)
+{
+	struct nand_ecclayout *layout = mtd->ecclayout;
+
+	if (!layout)
+		return -ENOTSUPP;
+
+	if (section >= MTD_MAX_OOBFREE_ENTRIES_LARGE ||
+	    !layout->oobfree[section].length)
+		return -ERANGE;
+
+	oobfree->offset = layout->oobfree[section].offset;
+	oobfree->length = layout->oobfree[section].length;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops mtd_ecclayout_wrapper_ops = {
+	.ecc = mtd_ecclayout_ecc,
+	.free = mtd_ecclayout_free,
+};
+
+/**
+ * mtd_set_ecclayout - Attach an ecclayout to an MTD device
+ * @mtd: MTD device structure
+ * @ecclayout: The ecclayout to attach to the device
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+void mtd_set_ecclayout(struct mtd_info *mtd, struct nand_ecclayout *ecclayout)
+{
+	if (!mtd || !ecclayout)
+		return;
+
+	mtd->ecclayout = ecclayout;
+	mtd_set_ooblayout(mtd, &mtd_ecclayout_wrapper_ops);
+}
+EXPORT_SYMBOL_GPL(mtd_set_ecclayout);
+
 /*
  * Method to access the protection register area, present in some flash
  * devices. The user data is one time programmable but the factory data is read
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index f53d9d7..1f13e32 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -317,6 +317,27 @@ static int part_block_markbad(struct mtd_info *mtd, loff_t ofs)
 	return res;
 }
 
+static int part_ooblayout_ecc(struct mtd_info *mtd, int section,
+			      struct mtd_oob_region *oobregion)
+{
+	struct mtd_part *part = mtd_to_part(mtd);
+
+	return mtd_ooblayout_ecc(part->master, section, oobregion);
+}
+
+static int part_ooblayout_free(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	struct mtd_part *part = mtd_to_part(mtd);
+
+	return mtd_ooblayout_free(part->master, section, oobregion);
+}
+
+static const struct mtd_ooblayout_ops part_ooblayout_ops = {
+	.ecc = part_ooblayout_ecc,
+	.free = part_ooblayout_free,
+};
+
 static inline void free_partition(struct mtd_part *p)
 {
 	kfree(p->mtd.name);
@@ -533,7 +554,7 @@ static struct mtd_part *allocate_partition(struct mtd_info *master,
 			part->name);
 	}
 
-	mtd_set_ecclayout(&slave->mtd, master->ecclayout);
+	mtd_set_ooblayout(&slave->mtd, &part_ooblayout_ops);
 	slave->mtd.ecc_step_size = master->ecc_step_size;
 	slave->mtd.ecc_strength = master->ecc_strength;
 	slave->mtd.bitflip_threshold = master->bitflip_threshold;
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 6250dd8..a38fe9a 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -101,6 +101,9 @@ struct mtd_oob_ops {
  * similar, smaller struct nand_ecclayout_user (in mtd-abi.h) that is retained
  * for export to user-space via the ECCGETLAYOUT ioctl.
  * nand_ecclayout should be expandable in the future simply by the above macros.
+ *
+ * This structure is now deprecated, you should use struct nand_ecclayout_ops
+ * to describe your OOB layout.
  */
 struct nand_ecclayout {
 	__u32 eccbytes;
@@ -123,6 +126,22 @@ struct mtd_oob_region {
 	u32 length;
 };
 
+/*
+ * struct mtd_ooblayout_ops - NAND OOB layout operations
+ * @ecc: function returning an ECC region in the OOB area.
+ *	 Should return -ERANGE if %section exceeds the total number of
+ *	 ECC sections.
+ * @free: function returning a free region in the OOB area.
+ *	  Should return -ERANGE if %section exceeds the total number of
+ *	  free sections.
+ */
+struct mtd_ooblayout_ops {
+	int (*ecc)(struct mtd_info *mtd, int section,
+		   struct mtd_oob_region *oobecc);
+	int (*free)(struct mtd_info *mtd, int section,
+		    struct mtd_oob_region *oobfree);
+};
+
 struct module;	/* only needed for owner field in mtd_info */
 
 struct mtd_info {
@@ -181,9 +200,12 @@ struct mtd_info {
 	const char *name;
 	int index;
 
-	/* ECC layout structure pointer - read only! */
+	/* [Deprecated] ECC layout structure pointer - read only! */
 	struct nand_ecclayout *ecclayout;
 
+	/* OOB layout description */
+	const struct mtd_ooblayout_ops *ooblayout;
+
 	/* the ecc step size. */
 	unsigned int ecc_step_size;
 
@@ -286,10 +308,12 @@ int mtd_ooblayout_set_databytes(struct mtd_info *mtd, const u8 *databuf,
 int mtd_ooblayout_count_freebytes(struct mtd_info *mtd);
 int mtd_ooblayout_count_eccbytes(struct mtd_info *mtd);
 
-static inline void mtd_set_ecclayout(struct mtd_info *mtd,
-				     struct nand_ecclayout *ecclayout)
+void mtd_set_ecclayout(struct mtd_info *mtd, struct nand_ecclayout *ecclayout);
+
+static inline void mtd_set_ooblayout(struct mtd_info *mtd,
+				     const struct mtd_ooblayout_ops *ooblayout)
 {
-	mtd->ecclayout = ecclayout;
+	mtd->ooblayout = ooblayout;
 }
 
 static inline void mtd_set_of_node(struct mtd_info *mtd,
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:38 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:38 +0100
Subject: [PATCH v2 15/51] mtd: use mtd_set_ecclayout() where appropriate
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-16-git-send-email-boris.brezillon@free-electrons.com>

Use the mtd_set_ecclayout() helper instead of directly assigning the
mtd->ecclayout field.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/mtdconcat.c | 2 +-
 drivers/mtd/mtdpart.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c
index 239a8c8..481565e 100644
--- a/drivers/mtd/mtdconcat.c
+++ b/drivers/mtd/mtdconcat.c
@@ -777,7 +777,7 @@ struct mtd_info *mtd_concat_create(struct mtd_info *subdev[],	/* subdevices to c
 
 	}
 
-	concat->mtd.ecclayout = subdev[0]->ecclayout;
+	mtd_set_ecclayout(&concat->mtd, subdev[0]->ecclayout);
 
 	concat->num_subdev = num_devs;
 	concat->mtd.name = name;
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 08de4b2..f53d9d7 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -533,7 +533,7 @@ static struct mtd_part *allocate_partition(struct mtd_info *master,
 			part->name);
 	}
 
-	slave->mtd.ecclayout = master->ecclayout;
+	mtd_set_ecclayout(&slave->mtd, master->ecclayout);
 	slave->mtd.ecc_step_size = master->ecc_step_size;
 	slave->mtd.ecc_strength = master->ecc_strength;
 	slave->mtd.bitflip_threshold = master->bitflip_threshold;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:35 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:35 +0100
Subject: [PATCH v2 12/51] mtd: nand: omap2: use mtd_ooblayout_xxx() helpers
 where appropriate
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-13-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/omap2.c | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 0749ca1..4ebf16b 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1495,9 +1495,8 @@ static int omap_elm_correct_data(struct mtd_info *mtd, u_char *data,
 static int omap_write_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
 			       const uint8_t *buf, int oob_required, int page)
 {
-	int i;
+	int ret;
 	uint8_t *ecc_calc = chip->buffers->ecccalc;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 
 	/* Enable GPMC ecc engine */
 	chip->ecc.hwctl(mtd, NAND_ECC_WRITE);
@@ -1508,8 +1507,10 @@ static int omap_write_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
 	/* Update ecc vector from GPMC result registers */
 	chip->ecc.calculate(mtd, buf, &ecc_calc[0]);
 
-	for (i = 0; i < chip->ecc.total; i++)
-		chip->oob_poi[eccpos[i]] = ecc_calc[i];
+	ret = mtd_ooblayout_set_eccbytes(mtd, ecc_calc, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	/* Write ecc vector to OOB area */
 	chip->write_buf(mtd, chip->oob_poi, mtd->oobsize);
@@ -1536,10 +1537,7 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
 {
 	uint8_t *ecc_calc = chip->buffers->ecccalc;
 	uint8_t *ecc_code = chip->buffers->ecccode;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
-	uint8_t *oob = &chip->oob_poi[eccpos[0]];
-	uint32_t oob_pos = mtd->writesize + chip->ecc.layout->eccpos[0];
-	int stat;
+	int stat, ret;
 	unsigned int max_bitflips = 0;
 
 	/* Enable GPMC ecc engine */
@@ -1549,13 +1547,16 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
 	chip->read_buf(mtd, buf, mtd->writesize);
 
 	/* Read oob bytes */
-	chip->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_pos, -1);
-	chip->read_buf(mtd, oob, chip->ecc.total);
+	chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
+	chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
 
 	/* Calculate ecc bytes */
 	chip->ecc.calculate(mtd, buf, ecc_calc);
 
-	memcpy(ecc_code, &chip->oob_poi[eccpos[0]], chip->ecc.total);
+	ret = mtd_ooblayout_get_eccbytes(mtd, ecc_code, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	stat = chip->ecc.correct(mtd, buf, ecc_code, ecc_calc);
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:36 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:36 +0100
Subject: [PATCH v2 13/51] mtd: onenand: use mtd_ooblayout_xxx() helpers where
 appropriate
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-14-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/onenand/onenand_base.c | 73 +++++++-------------------------------
 1 file changed, 13 insertions(+), 60 deletions(-)

diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index 03a80de..6906c95 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1024,34 +1024,15 @@ static int onenand_transfer_auto_oob(struct mtd_info *mtd, uint8_t *buf, int col
 				int thislen)
 {
 	struct onenand_chip *this = mtd->priv;
-	struct nand_oobfree *free;
-	int readcol = column;
-	int readend = column + thislen;
-	int lastgap = 0;
-	unsigned int i;
-	uint8_t *oob_buf = this->oob_buf;
-
-	free = this->ecclayout->oobfree;
-	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES && free->length; i++, free++) {
-		if (readcol >= lastgap)
-			readcol += free->offset - lastgap;
-		if (readend >= lastgap)
-			readend += free->offset - lastgap;
-		lastgap = free->offset + free->length;
-	}
-	this->read_bufferram(mtd, ONENAND_SPARERAM, oob_buf, 0, mtd->oobsize);
-	free = this->ecclayout->oobfree;
-	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES && free->length; i++, free++) {
-		int free_end = free->offset + free->length;
-		if (free->offset < readend && free_end > readcol) {
-			int st = max_t(int,free->offset,readcol);
-			int ed = min_t(int,free_end,readend);
-			int n = ed - st;
-			memcpy(buf, oob_buf + st, n);
-			buf += n;
-		} else if (column == 0)
-			break;
-	}
+	int ret;
+
+	this->read_bufferram(mtd, ONENAND_SPARERAM, this->oob_buf, 0,
+			     mtd->oobsize);
+	ret = mtd_ooblayout_get_databytes(mtd, buf, this->oob_buf,
+					  column, thislen);
+	if (ret)
+		return ret;
+
 	return 0;
 }
 
@@ -1808,34 +1789,7 @@ static int onenand_panic_write(struct mtd_info *mtd, loff_t to, size_t len,
 static int onenand_fill_auto_oob(struct mtd_info *mtd, u_char *oob_buf,
 				  const u_char *buf, int column, int thislen)
 {
-	struct onenand_chip *this = mtd->priv;
-	struct nand_oobfree *free;
-	int writecol = column;
-	int writeend = column + thislen;
-	int lastgap = 0;
-	unsigned int i;
-
-	free = this->ecclayout->oobfree;
-	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES && free->length; i++, free++) {
-		if (writecol >= lastgap)
-			writecol += free->offset - lastgap;
-		if (writeend >= lastgap)
-			writeend += free->offset - lastgap;
-		lastgap = free->offset + free->length;
-	}
-	free = this->ecclayout->oobfree;
-	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES && free->length; i++, free++) {
-		int free_end = free->offset + free->length;
-		if (free->offset < writeend && free_end > writecol) {
-			int st = max_t(int,free->offset,writecol);
-			int ed = min_t(int,free_end,writeend);
-			int n = ed - st;
-			memcpy(oob_buf + st, buf, n);
-			buf += n;
-		} else if (column == 0)
-			break;
-	}
-	return 0;
+	return mtd_ooblayout_set_databytes(mtd, buf, oob_buf, column, thislen);
 }
 
 /**
@@ -4036,10 +3990,9 @@ int onenand_scan(struct mtd_info *mtd, int maxchips)
 	 * The number of bytes available for a client to place data into
 	 * the out of band area
 	 */
-	mtd->oobavail = 0;
-	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES &&
-	    this->ecclayout->oobfree[i].length; i++)
-		mtd->oobavail += this->ecclayout->oobfree[i].length;
+	mtd->oobavail = mtd_ooblayout_count_freebytes(mtd);
+	if (mtd->oobavail < 0)
+		mtd->oobavail = 0;
 
 	mtd->ecclayout = this->ecclayout;
 	mtd->ecc_strength = 1;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:28 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:28 +0100
Subject: [PATCH v2 05/51] mtd: add mtd_ooblayout_xxx() helper functions
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-6-git-send-email-boris.brezillon@free-electrons.com>

In order to make the ecclayout definition completely dynamic we need to
rework the way the OOB layout are defined and iterated.

Create a few mtd_ooblayout_xxx() helpers to ease OOB bytes manipulation
and hide ecclayout internals to their users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/mtdcore.c   | 401 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mtd/mtd.h |  33 ++++
 2 files changed, 434 insertions(+)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 3096251..14e46ca 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -997,6 +997,407 @@ int mtd_read_oob(struct mtd_info *mtd, loff_t from, struct mtd_oob_ops *ops)
 }
 EXPORT_SYMBOL_GPL(mtd_read_oob);
 
+/**
+ * mtd_ooblayout_ecc - Get the OOB region definition of a specific ECC section
+ * @mtd: MTD device structure
+ * @section: ECC section. Depending on the layout you may have all the ECC
+ *	     bytes stored in a single contiguous section, or one section
+ *	     per ECC chunk (and sometime several sections for a single ECC
+ *	     ECC chunk)
+ * @oobecc: OOB region struct filled with the appropriate ECC position
+ *	    information
+ *
+ * This functions return ECC section information in the OOB area. I you want
+ * to get all the ECC bytes information, then you should call
+ * mtd_ooblayout_ecc(mtd, section++, oobecc) until it returns -ERANGE.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_ecc(struct mtd_info *mtd, int section,
+		      struct mtd_oob_region *oobecc)
+{
+	int eccbyte = 0, cursection = 0, length = 0, eccpos = 0;
+
+	memset(oobecc, 0, sizeof(*oobecc));
+
+	if (!mtd || section < 0)
+		return -EINVAL;
+
+	if (!mtd->ecclayout)
+		return -ENOTSUPP;
+
+	if (mtd->ecclayout->eccbytes < 1)
+		return -ERANGE;
+
+	/*
+	 * This logic allows us to reuse the ->ecclayout information and
+	 * expose them as ECC regions (as done for the OOB free regions).
+	 *
+	 * TODO: this should be dropped as soon as we get rid of the
+	 * ->ecclayout field.
+	 */
+	for (eccbyte = 0; eccbyte < mtd->ecclayout->eccbytes; eccbyte++) {
+		eccpos = mtd->ecclayout->eccpos[eccbyte];
+
+		if (eccbyte < mtd->ecclayout->eccbytes - 1) {
+			int neccpos = mtd->ecclayout->eccpos[eccbyte + 1];
+
+			if (eccpos + 1 == neccpos) {
+				length++;
+				continue;
+			}
+		}
+
+		if (section == cursection)
+			break;
+
+		length = 0;
+		cursection++;
+	}
+
+	if (cursection != section)
+		return -ERANGE;
+
+	oobecc->length = length + 1;
+	oobecc->offset = eccpos - length;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_ecc);
+
+/**
+ * mtd_ooblayout_free - Get the OOB region definition of a specific free
+ *			section
+ * @mtd: MTD device structure
+ * @section: Free section you are interested in. Depending on the layout
+ *	     you may have all the free bytes stored in a single contiguous
+ *	     section, or one section per ECC chunk plus an extra section
+ *	     for the remaining bytes (or other funky layout).
+ * @oobfree: OOB region struct filled with the appropriate free position
+ *	     information
+ *
+ * This functions return free bytes position in the OOB area. I you want
+ * to get all the free bytes information, then you should call
+ * mtd_ooblayout_free(mtd, section++, oobfree) until it returns -ERANGE.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_free(struct mtd_info *mtd, int section,
+		       struct mtd_oob_region *oobfree)
+{
+	memset(oobfree, 0, sizeof(*oobfree));
+
+	if (!mtd || section < 0)
+		return -EINVAL;
+
+	if (!mtd->ecclayout)
+		return -ENOTSUPP;
+
+	if (section >= MTD_MAX_OOBFREE_ENTRIES_LARGE)
+		return -ERANGE;
+
+	oobfree->offset = mtd->ecclayout->oobfree[section].offset;
+	oobfree->length = mtd->ecclayout->oobfree[section].length;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_free);
+
+/**
+ * mtd_ooblayout_find_region - Find the region attached to a specific byte
+ * @mtd: mtd info structure
+ * @byte: the byte we are searching for
+ * @sectionp: pointer where the section id will be stored
+ * @oobregion: used to retrieve the ECC position
+ * @iter: iterator function. Should be either mtd_ooblayout_free or
+ *	  mtd_ooblayout_ecc depending on the region type you're searching for
+ *
+ * This functions returns the section id and oobregion information of a
+ * specific byte. For example, say you want to know where the 4th ECC byte is
+ * stored, you'll use:
+ *
+ * mtd_ooblayout_find_region(mtd, 3, &section, &oobregion, mtd_ooblayout_ecc);
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+static int mtd_ooblayout_find_region(struct mtd_info *mtd, int byte,
+				int *sectionp, struct mtd_oob_region *oobregion,
+				int (*iter)(struct mtd_info *,
+					    int section,
+					    struct mtd_oob_region *oobregion))
+{
+	int pos = 0, ret, section = 0;
+
+	memset(oobregion, 0, sizeof(*oobregion));
+
+	while (pos + oobregion->length <= byte) {
+		ret = iter(mtd, section++, oobregion);
+		if (ret)
+			return ret;
+
+		pos += oobregion->length;
+	}
+
+	/*
+	 * Adjust region info to make it start at the beginning at the
+	 * 'start' ECC byte.
+	 */
+	oobregion->offset += byte - pos;
+	oobregion->length -= byte - pos;
+	*sectionp = section;
+
+	return 0;
+}
+
+/**
+ * mtd_ooblayout_find_eccregion - Find the ECC region attached to a specific
+ *				  ECC byte
+ * @mtd: mtd info structure
+ * @eccbyte: the byte we are searching for
+ * @sectionp: pointer where the section id will be stored
+ * @oobregion: OOB region information
+ *
+ * Works like mtd_ooblayout_find_region() except it searches for a specific ECC
+ * byte.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_find_eccregion(struct mtd_info *mtd, int eccbyte,
+				 int *section,
+				 struct mtd_oob_region *oobregion)
+{
+	return mtd_ooblayout_find_region(mtd, eccbyte, section, oobregion,
+					 mtd_ooblayout_ecc);
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_find_eccregion);
+
+/**
+ * mtd_ooblayout_get_bytes - Extract OOB bytes from the oob buffer
+ * @mtd: mtd info structure
+ * @buf: destination buffer to store OOB bytes
+ * @oobbuf: OOB buffer
+ * @start: first byte to retrieve
+ * @nbytes: number of bytes to retrieve
+ * @iter: section iterator
+ *
+ * Extract bytes attached to a specific category (ECC or free)
+ * from the OOB buffer and copy them into buf.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+static int mtd_ooblayout_get_bytes(struct mtd_info *mtd, u8 *buf,
+				const u8 *oobbuf, int start, int nbytes,
+				int (*iter)(struct mtd_info *,
+					    int section,
+					    struct mtd_oob_region *oobregion))
+{
+	struct mtd_oob_region oobregion = { };
+	int section = 0, ret;
+
+	ret = mtd_ooblayout_find_region(mtd, start, &section,
+					&oobregion, iter);
+	if (ret)
+		return ret;
+
+	while (nbytes) {
+		int cnt;
+
+		ret = iter(mtd, section++, &oobregion);
+		if (ret)
+			return ret;
+
+		cnt = oobregion.length > nbytes ? nbytes : oobregion.length;
+		memcpy(buf, oobbuf + oobregion.offset, cnt);
+		buf += cnt;
+		nbytes -= cnt;
+	}
+
+	return !nbytes ? 0 : -ERANGE;
+}
+
+/**
+ * mtd_ooblayout_set_bytes - put OOB bytes into the oob buffer
+ * @mtd: mtd info structure
+ * @buf: source buffer to get OOB bytes from
+ * @oobbuf: OOB buffer
+ * @start: first OOB byte to set
+ * @nbytes: number of OOB bytes to set
+ * @iter: section iterator
+ *
+ * Fill the OOB buffer with data provided in buf. The category (ECC or free)
+ * is selected by passing the appropriate iterator.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+static int mtd_ooblayout_set_bytes(struct mtd_info *mtd, const u8 *buf,
+				u8 *oobbuf, int start, int nbytes,
+				int (*iter)(struct mtd_info *,
+					    int section,
+					    struct mtd_oob_region *oobregion))
+{
+	struct mtd_oob_region oobregion = { };
+	int section = 0, ret;
+
+	ret = mtd_ooblayout_find_region(mtd, start, &section,
+					&oobregion, iter);
+	if (ret)
+		return ret;
+
+	while (nbytes) {
+		int cnt;
+
+		ret = iter(mtd, section++, &oobregion);
+		if (ret)
+			return ret;
+
+		cnt = oobregion.length > nbytes ? nbytes : oobregion.length;
+		memcpy(oobbuf + oobregion.offset, buf, cnt);
+		buf += cnt;
+		nbytes -= cnt;
+	}
+
+	return !nbytes ? 0 : -ERANGE;
+}
+
+/**
+ * mtd_ooblayout_count_bytes - count the number of bytes in a OOB category
+ * @mtd: mtd info structure
+ * @iter: category iterator
+ *
+ * Count the number of bytes in a given category.
+ *
+ * Returns a positive value on success, a negative error code otherwise.
+ */
+static int mtd_ooblayout_count_bytes(struct mtd_info *mtd,
+				int (*iter)(struct mtd_info *,
+					    int section,
+					    struct mtd_oob_region *oobregion))
+{
+	struct mtd_oob_region oobregion = { };
+	int section = 0, ret, nbytes = 0;
+
+	while (1) {
+		ret = iter(mtd, section, &oobregion);
+		if (ret) {
+			if (ret == -ERANGE)
+				ret = nbytes;
+			break;
+		}
+
+		nbytes += oobregion.length;
+	}
+
+	return ret;
+}
+
+/**
+ * mtd_ooblayout_get_eccbytes - extract ECC bytes from the oob buffer
+ * @mtd: mtd info structure
+ * @eccbuf: destination buffer to store ECC bytes
+ * @oobbuf: OOB buffer
+ * @start: first ECC byte to retrieve
+ * @nbytes: number of ECC bytes to retrieve
+ *
+ * Works like mtd_ooblayout_get_bytes(), except it acts on ECC bytes.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_get_eccbytes(struct mtd_info *mtd, u8 *eccbuf,
+			       const u8 *oobbuf, int start, int nbytes)
+{
+	return mtd_ooblayout_get_bytes(mtd, eccbuf, oobbuf, start, nbytes,
+				       mtd_ooblayout_ecc);
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_get_eccbytes);
+
+/**
+ * mtd_ooblayout_set_eccbytes - set ECC bytes into the oob buffer
+ * @mtd: mtd info structure
+ * @eccbuf: source buffer to get ECC bytes from
+ * @oobbuf: OOB buffer
+ * @start: first ECC byte to set
+ * @nbytes: number of ECC bytes to set
+ *
+ * Works like mtd_ooblayout_set_bytes(), except it acts on ECC bytes.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_set_eccbytes(struct mtd_info *mtd, const u8 *eccbuf,
+			       u8 *oobbuf, int start, int nbytes)
+{
+	return mtd_ooblayout_set_bytes(mtd, eccbuf, oobbuf, start, nbytes,
+				       mtd_ooblayout_ecc);
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_set_eccbytes);
+
+/**
+ * mtd_ooblayout_get_databytes - extract data bytes from the oob buffer
+ * @mtd: mtd info structure
+ * @databuf: destination buffer to store ECC bytes
+ * @oobbuf: OOB buffer
+ * @start: first ECC byte to retrieve
+ * @nbytes: number of ECC bytes to retrieve
+ *
+ * Works like mtd_ooblayout_get_bytes(), except it acts on free bytes.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_get_databytes(struct mtd_info *mtd, u8 *databuf,
+				const u8 *oobbuf, int start, int nbytes)
+{
+	return mtd_ooblayout_get_bytes(mtd, databuf, oobbuf, start, nbytes,
+				       mtd_ooblayout_free);
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_get_databytes);
+
+/**
+ * mtd_ooblayout_get_eccbytes - set data bytes into the oob buffer
+ * @mtd: mtd info structure
+ * @eccbuf: source buffer to get data bytes from
+ * @oobbuf: OOB buffer
+ * @start: first ECC byte to set
+ * @nbytes: number of ECC bytes to set
+ *
+ * Works like mtd_ooblayout_get_bytes(), except it acts on free bytes.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_set_databytes(struct mtd_info *mtd, const u8 *databuf,
+				u8 *oobbuf, int start, int nbytes)
+{
+	return mtd_ooblayout_set_bytes(mtd, databuf, oobbuf, start, nbytes,
+				       mtd_ooblayout_free);
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_set_databytes);
+
+/**
+ * mtd_ooblayout_count_freebytes - count the number of free bytes in OOB
+ * @mtd: mtd info structure
+ *
+ * Works like mtd_ooblayout_count_bytes(), except it count free bytes.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_count_freebytes(struct mtd_info *mtd)
+{
+	return mtd_ooblayout_count_bytes(mtd, mtd_ooblayout_free);
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_count_freebytes);
+
+/**
+ * mtd_ooblayout_count_freebytes - count the number of ECC bytes in OOB
+ * @mtd: mtd info structure
+ *
+ * Works like mtd_ooblayout_count_bytes(), except it count ECC bytes.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_count_eccbytes(struct mtd_info *mtd)
+{
+	return mtd_ooblayout_count_bytes(mtd, mtd_ooblayout_ecc);
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_count_eccbytes);
+
 /*
  * Method to access the protection register area, present in some flash
  * devices. The user data is one time programmable but the factory data is read
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 7712721..b141f26 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -108,6 +108,21 @@ struct nand_ecclayout {
 	struct nand_oobfree oobfree[MTD_MAX_OOBFREE_ENTRIES_LARGE];
 };
 
+/**
+ * struct mtd_oob_region - oob region definition
+ * @offset: region offset
+ * @length: region length
+ *
+ * This structure describes a region of the OOB area, and is used
+ * to retrieve ECC or free bytes sections.
+ * Each section is defined by an offset within the OOB area and a
+ * length.
+ */
+struct mtd_oob_region {
+	u32 offset;
+	u32 length;
+};
+
 struct module;	/* only needed for owner field in mtd_info */
 
 struct mtd_info {
@@ -253,6 +268,24 @@ struct mtd_info {
 	int usecount;
 };
 
+int mtd_ooblayout_ecc(struct mtd_info *mtd, int section,
+		      struct mtd_oob_region *oobecc);
+int mtd_ooblayout_find_eccregion(struct mtd_info *mtd, int eccbyte,
+				 int *section,
+				 struct mtd_oob_region *oobregion);
+int mtd_ooblayout_get_eccbytes(struct mtd_info *mtd, u8 *eccbuf,
+			       const u8 *oobbuf, int start, int nbytes);
+int mtd_ooblayout_set_eccbytes(struct mtd_info *mtd, const u8 *eccbuf,
+			       u8 *oobbuf, int start, int nbytes);
+int mtd_ooblayout_free(struct mtd_info *mtd, int section,
+		       struct mtd_oob_region *oobfree);
+int mtd_ooblayout_get_databytes(struct mtd_info *mtd, u8 *databuf,
+				const u8 *oobbuf, int start, int nbytes);
+int mtd_ooblayout_set_databytes(struct mtd_info *mtd, const u8 *databuf,
+				u8 *oobbuf, int start, int nbytes);
+int mtd_ooblayout_count_freebytes(struct mtd_info *mtd);
+int mtd_ooblayout_count_eccbytes(struct mtd_info *mtd);
+
 static inline void mtd_set_of_node(struct mtd_info *mtd,
 				   struct device_node *np)
 {
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:53 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:53 +0100
Subject: [PATCH v2 30/51] mtd: nand: denali: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-31-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/denali.c | 51 +++++++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 15 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 30bf5f6..b832375 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1374,13 +1374,42 @@ static void denali_hw_init(struct denali_nand_info *denali)
  * correction
  */
 #define ECC_8BITS	14
-static struct nand_ecclayout nand_8bit_oob = {
-	.eccbytes = 14,
-};
-
 #define ECC_15BITS	26
-static struct nand_ecclayout nand_15bit_oob = {
-	.eccbytes = 26,
+
+static int denali_ooblayout_ecc(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	struct denali_nand_info *denali = mtd_to_denali(mtd);
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = denali->bbtskipbytes;
+	oobregion->length = chip->ecc.bytes * chip->ecc.steps;
+
+	return 0;
+}
+
+static int denali_ooblayout_free(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct denali_nand_info *denali = mtd_to_denali(mtd);
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int eccbytes = chip->ecc.bytes * chip->ecc.steps;
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = eccbytes + denali->bbtskipbytes;
+	oobregion->length = mtd->oobsize - oobregion->offset;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops denali_ooblayout_ops = {
+	.ecc = denali_ooblayout_ecc,
+	.free = denali_ooblayout_free,
 };
 
 static uint8_t bbt_pattern[] = {'B', 'b', 't', '0' };
@@ -1561,7 +1590,6 @@ int denali_init(struct denali_nand_info *denali)
 			ECC_SECTOR_SIZE)))) {
 		/* if MLC OOB size is large enough, use 15bit ECC*/
 		denali->nand.ecc.strength = 15;
-		denali->nand.ecc.layout = &nand_15bit_oob;
 		denali->nand.ecc.bytes = ECC_15BITS;
 		iowrite32(15, denali->flash_reg + ECC_CORRECTION);
 	} else if (mtd->oobsize < (denali->bbtskipbytes +
@@ -1571,20 +1599,13 @@ int denali_init(struct denali_nand_info *denali)
 		goto failed_req_irq;
 	} else {
 		denali->nand.ecc.strength = 8;
-		denali->nand.ecc.layout = &nand_8bit_oob;
 		denali->nand.ecc.bytes = ECC_8BITS;
 		iowrite32(8, denali->flash_reg + ECC_CORRECTION);
 	}
 
+	mtd_set_ooblayout(mtd, &denali_ooblayout_ops);
 	denali->nand.ecc.bytes *= denali->devnum;
 	denali->nand.ecc.strength *= denali->devnum;
-	denali->nand.ecc.layout->eccbytes *=
-		mtd->writesize / ECC_SECTOR_SIZE;
-	denali->nand.ecc.layout->oobfree[0].offset =
-		denali->bbtskipbytes + denali->nand.ecc.layout->eccbytes;
-	denali->nand.ecc.layout->oobfree[0].length =
-		mtd->oobsize - denali->nand.ecc.layout->eccbytes -
-		denali->bbtskipbytes;
 
 	/*
 	 * Let driver know the total blocks number and how many blocks
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:33 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:33 +0100
Subject: [PATCH v2 10/51] mtd: nand: gpmi: use mtd_ooblayout_xxx() helpers
 where appropriate
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-11-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 8122c69..3a29b65 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1327,18 +1327,19 @@ static int gpmi_ecc_read_oob(struct mtd_info *mtd, struct nand_chip *chip,
 static int
 gpmi_ecc_write_oob(struct mtd_info *mtd, struct nand_chip *chip, int page)
 {
-	struct nand_oobfree *of = mtd->ecclayout->oobfree;
+	struct mtd_oob_region of = { };
 	int status = 0;
 
 	/* Do we have available oob area? */
-	if (!of->length)
+	mtd_ooblayout_free(mtd, 0, &of);
+	if (!of.length)
 		return -EPERM;
 
 	if (!nand_is_slc(chip))
 		return -EPERM;
 
-	chip->cmdfunc(mtd, NAND_CMD_SEQIN, mtd->writesize + of->offset, page);
-	chip->write_buf(mtd, chip->oob_poi + of->offset, of->length);
+	chip->cmdfunc(mtd, NAND_CMD_SEQIN, mtd->writesize + of.offset, page);
+	chip->write_buf(mtd, chip->oob_poi + of.offset, of.length);
 	chip->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1);
 
 	status = chip->waitfunc(mtd, chip);
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:34 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:34 +0100
Subject: [PATCH v2 11/51] mtd: nand: lpc32xx: use mtd_ooblayout_xxx() helpers
 where appropriate
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-12-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/lpc32xx_slc.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/lpc32xx_slc.c b/drivers/mtd/nand/lpc32xx_slc.c
index 3b8f373..10cf8e62 100644
--- a/drivers/mtd/nand/lpc32xx_slc.c
+++ b/drivers/mtd/nand/lpc32xx_slc.c
@@ -604,7 +604,8 @@ static int lpc32xx_nand_read_page_syndrome(struct mtd_info *mtd,
 					   int oob_required, int page)
 {
 	struct lpc32xx_nand_host *host = nand_get_controller_data(chip);
-	int stat, i, status;
+	struct mtd_oob_region oobregion = { };
+	int stat, i, status, error;
 	uint8_t *oobecc, tmpecc[LPC32XX_ECC_SAVE_SIZE];
 
 	/* Issue read command */
@@ -620,7 +621,11 @@ static int lpc32xx_nand_read_page_syndrome(struct mtd_info *mtd,
 	lpc32xx_slc_ecc_copy(tmpecc, (uint32_t *) host->ecc_buf, chip->ecc.steps);
 
 	/* Pointer to ECC data retrieved from NAND spare area */
-	oobecc = chip->oob_poi + chip->ecc.layout->eccpos[0];
+	error = mtd_ooblayout_ecc(mtd, 0, &oobregion);
+	if (error)
+		return error;
+
+	oobecc = chip->oob_poi + oobregion.offset;
 
 	for (i = 0; i < chip->ecc.steps; i++) {
 		stat = chip->ecc.correct(mtd, buf, oobecc,
@@ -666,7 +671,8 @@ static int lpc32xx_nand_write_page_syndrome(struct mtd_info *mtd,
 					    int oob_required, int page)
 {
 	struct lpc32xx_nand_host *host = nand_get_controller_data(chip);
-	uint8_t *pb = chip->oob_poi + chip->ecc.layout->eccpos[0];
+	struct mtd_oob_region oobregion = { };
+	uint8_t *pb;
 	int error;
 
 	/* Write data, calculate ECC on outbound data */
@@ -678,6 +684,11 @@ static int lpc32xx_nand_write_page_syndrome(struct mtd_info *mtd,
 	 * The calculated ECC needs some manual work done to it before
 	 * committing it to NAND. Process the calculated ECC and place
 	 * the resultant values directly into the OOB buffer. */
+	error = mtd_ooblayout_ecc(mtd, 0, &oobregion);
+	if (error)
+		return error;
+
+	pb = chip->oob_poi + oobregion.offset;
 	lpc32xx_slc_ecc_copy(pb, (uint32_t *)host->ecc_buf, chip->ecc.steps);
 
 	/* Write ECC data to device */
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:07:01 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:07:01 +0100
Subject: [PATCH v2 38/51] mtd: nand: jz4780: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-39-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/jz4780_nand.c | 19 +++++--------------
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/drivers/mtd/nand/jz4780_nand.c b/drivers/mtd/nand/jz4780_nand.c
index e1c016c..b86a579 100644
--- a/drivers/mtd/nand/jz4780_nand.c
+++ b/drivers/mtd/nand/jz4780_nand.c
@@ -56,8 +56,6 @@ struct jz4780_nand_chip {
 	struct nand_chip chip;
 	struct list_head chip_list;
 
-	struct nand_ecclayout ecclayout;
-
 	struct gpio_desc *busy_gpio;
 	struct gpio_desc *wp_gpio;
 	unsigned int reading: 1;
@@ -165,8 +163,7 @@ static int jz4780_nand_init_ecc(struct jz4780_nand_chip *nand, struct device *de
 	struct nand_chip *chip = &nand->chip;
 	struct mtd_info *mtd = nand_to_mtd(chip);
 	struct jz4780_nand_controller *nfc = to_jz4780_nand_controller(chip->controller);
-	struct nand_ecclayout *layout = &nand->ecclayout;
-	u32 start, i;
+	int eccbytes;
 
 	chip->ecc.bytes = fls((1 + 8) * chip->ecc.size)	*
 				(chip->ecc.strength / 8);
@@ -201,23 +198,17 @@ static int jz4780_nand_init_ecc(struct jz4780_nand_chip *nand, struct device *de
 		return 0;
 
 	/* Generate ECC layout. ECC codes are right aligned in the OOB area. */
-	layout->eccbytes = mtd->writesize / chip->ecc.size * chip->ecc.bytes;
+	eccbytes = mtd->writesize / chip->ecc.size * chip->ecc.bytes;
 
-	if (layout->eccbytes > mtd->oobsize - 2) {
+	if (eccbytes > mtd->oobsize - 2) {
 		dev_err(dev,
 			"invalid ECC config: required %d ECC bytes, but only %d are available",
-			layout->eccbytes, mtd->oobsize - 2);
+			eccbytes, mtd->oobsize - 2);
 		return -EINVAL;
 	}
 
-	start = mtd->oobsize - layout->eccbytes;
-	for (i = 0; i < layout->eccbytes; i++)
-		layout->eccpos[i] = start + i;
-
-	layout->oobfree[0].offset = 2;
-	layout->oobfree[0].length = mtd->oobsize - layout->eccbytes - 2;
+	mtd->ooblayout = &nand_ooblayout_lp_ops;
 
-	chip->ecc.layout = layout;
 	return 0;
 }
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:07:02 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:07:02 +0100
Subject: [PATCH v2 39/51] mtd: nand: lpc32xx: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-40-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/lpc32xx_mlc.c | 50 ++++++++++++++++++++++++++++--------------
 drivers/mtd/nand/lpc32xx_slc.c | 41 +++++++++++++++++++++++++++-------
 2 files changed, 66 insertions(+), 25 deletions(-)

diff --git a/drivers/mtd/nand/lpc32xx_mlc.c b/drivers/mtd/nand/lpc32xx_mlc.c
index d8c3e7a..f668282 100644
--- a/drivers/mtd/nand/lpc32xx_mlc.c
+++ b/drivers/mtd/nand/lpc32xx_mlc.c
@@ -139,22 +139,37 @@ struct lpc32xx_nand_cfg_mlc {
 	unsigned num_parts;
 };
 
-static struct nand_ecclayout lpc32xx_nand_oob = {
-	.eccbytes = 40,
-	.eccpos = { 6,  7,  8,  9, 10, 11, 12, 13, 14, 15,
-		   22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
-		   38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
-		   54, 55, 56, 57, 58, 59, 60, 61, 62, 63 },
-	.oobfree = {
-		{ .offset = 0,
-		  .length = 6, },
-		{ .offset = 16,
-		  .length = 6, },
-		{ .offset = 32,
-		  .length = 6, },
-		{ .offset = 48,
-		  .length = 6, },
-		},
+static int lpc32xx_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand_chip = mtd_to_nand(mtd);
+
+	if (section >= nand_chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = ((section + 1) * 16) - nand_chip->ecc.bytes;
+	oobregion->length = nand_chip->ecc.bytes;
+
+	return 0;
+}
+
+static int lpc32xx_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand_chip = mtd_to_nand(mtd);
+
+	if (section >= nand_chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = 16 * section;
+	oobregion->length = 16 - nand_chip->ecc.bytes;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops lpc32xx_ooblayout_ops = {
+	.ecc = lpc32xx_ooblayout_ecc,
+	.free = lpc32xx_ooblayout_free,
 };
 
 static struct nand_bbt_descr lpc32xx_nand_bbt = {
@@ -713,6 +728,7 @@ static int lpc32xx_nand_probe(struct platform_device *pdev)
 	nand_chip->ecc.write_oob = lpc32xx_write_oob;
 	nand_chip->ecc.read_oob = lpc32xx_read_oob;
 	nand_chip->ecc.strength = 4;
+	nand_chip->ecc.bytes = 10;
 	nand_chip->waitfunc = lpc32xx_waitfunc;
 
 	nand_chip->options = NAND_NO_SUBPAGE_WRITE;
@@ -751,7 +767,7 @@ static int lpc32xx_nand_probe(struct platform_device *pdev)
 
 	nand_chip->ecc.mode = NAND_ECC_HW;
 	nand_chip->ecc.size = 512;
-	nand_chip->ecc.layout = &lpc32xx_nand_oob;
+	mtd_set_ooblayout(mtd, &lpc32xx_ooblayout_ops);
 	host->mlcsubpages = mtd->writesize / 512;
 
 	/* initially clear interrupt status */
diff --git a/drivers/mtd/nand/lpc32xx_slc.c b/drivers/mtd/nand/lpc32xx_slc.c
index 10cf8e62..219dd67 100644
--- a/drivers/mtd/nand/lpc32xx_slc.c
+++ b/drivers/mtd/nand/lpc32xx_slc.c
@@ -146,13 +146,38 @@
  * NAND ECC Layout for small page NAND devices
  * Note: For large and huge page devices, the default layouts are used
  */
-static struct nand_ecclayout lpc32xx_nand_oob_16 = {
-	.eccbytes = 6,
-	.eccpos = {10, 11, 12, 13, 14, 15},
-	.oobfree = {
-		{ .offset = 0, .length = 4 },
-		{ .offset = 6, .length = 4 },
-	},
+static int lpc32xx_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->length = 6;
+	oobregion->offset = 10;
+
+	return 0;
+}
+
+static int lpc32xx_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	if (section > 1)
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 0;
+		oobregion->length = 4;
+	} else {
+		oobregion->offset = 6;
+		oobregion->length = 4;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops lpc32xx_ooblayout_ops = {
+	.ecc = lpc32xx_ooblayout_ecc,
+	.free = lpc32xx_ooblayout_free,
 };
 
 static u8 bbt_pattern[] = {'B', 'b', 't', '0' };
@@ -886,7 +911,7 @@ static int lpc32xx_nand_probe(struct platform_device *pdev)
 	 * custom BBT marker layout.
 	 */
 	if (mtd->writesize <= 512)
-		chip->ecc.layout = &lpc32xx_nand_oob_16;
+		mtd_set_ooblayout(mtd, &lpc32xx_ooblayout_ops);
 
 	/* These sizes remain the same regardless of page size */
 	chip->ecc.size = 256;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:57 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:57 +0100
Subject: [PATCH v2 34/51] mtd: nand: fsl_ifc: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-35-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/fsl_ifc_nand.c | 232 ++++++++++++----------------------------
 1 file changed, 67 insertions(+), 165 deletions(-)

diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 2e970ac..9419fb1 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -67,136 +67,6 @@ struct fsl_ifc_nand_ctrl {
 
 static struct fsl_ifc_nand_ctrl *ifc_nand_ctrl;
 
-/* 512-byte page with 4-bit ECC, 8-bit */
-static struct nand_ecclayout oob_512_8bit_ecc4 = {
-	.eccbytes = 8,
-	.eccpos = {8, 9, 10, 11, 12, 13, 14, 15},
-	.oobfree = { {0, 5}, {6, 2} },
-};
-
-/* 512-byte page with 4-bit ECC, 16-bit */
-static struct nand_ecclayout oob_512_16bit_ecc4 = {
-	.eccbytes = 8,
-	.eccpos = {8, 9, 10, 11, 12, 13, 14, 15},
-	.oobfree = { {2, 6}, },
-};
-
-/* 2048-byte page size with 4-bit ECC */
-static struct nand_ecclayout oob_2048_ecc4 = {
-	.eccbytes = 32,
-	.eccpos = {
-		8, 9, 10, 11, 12, 13, 14, 15,
-		16, 17, 18, 19, 20, 21, 22, 23,
-		24, 25, 26, 27, 28, 29, 30, 31,
-		32, 33, 34, 35, 36, 37, 38, 39,
-	},
-	.oobfree = { {2, 6}, {40, 24} },
-};
-
-/* 4096-byte page size with 4-bit ECC */
-static struct nand_ecclayout oob_4096_ecc4 = {
-	.eccbytes = 64,
-	.eccpos = {
-		8, 9, 10, 11, 12, 13, 14, 15,
-		16, 17, 18, 19, 20, 21, 22, 23,
-		24, 25, 26, 27, 28, 29, 30, 31,
-		32, 33, 34, 35, 36, 37, 38, 39,
-		40, 41, 42, 43, 44, 45, 46, 47,
-		48, 49, 50, 51, 52, 53, 54, 55,
-		56, 57, 58, 59, 60, 61, 62, 63,
-		64, 65, 66, 67, 68, 69, 70, 71,
-	},
-	.oobfree = { {2, 6}, {72, 56} },
-};
-
-/* 4096-byte page size with 8-bit ECC -- requires 218-byte OOB */
-static struct nand_ecclayout oob_4096_ecc8 = {
-	.eccbytes = 128,
-	.eccpos = {
-		8, 9, 10, 11, 12, 13, 14, 15,
-		16, 17, 18, 19, 20, 21, 22, 23,
-		24, 25, 26, 27, 28, 29, 30, 31,
-		32, 33, 34, 35, 36, 37, 38, 39,
-		40, 41, 42, 43, 44, 45, 46, 47,
-		48, 49, 50, 51, 52, 53, 54, 55,
-		56, 57, 58, 59, 60, 61, 62, 63,
-		64, 65, 66, 67, 68, 69, 70, 71,
-		72, 73, 74, 75, 76, 77, 78, 79,
-		80, 81, 82, 83, 84, 85, 86, 87,
-		88, 89, 90, 91, 92, 93, 94, 95,
-		96, 97, 98, 99, 100, 101, 102, 103,
-		104, 105, 106, 107, 108, 109, 110, 111,
-		112, 113, 114, 115, 116, 117, 118, 119,
-		120, 121, 122, 123, 124, 125, 126, 127,
-		128, 129, 130, 131, 132, 133, 134, 135,
-	},
-	.oobfree = { {2, 6}, {136, 82} },
-};
-
-/* 8192-byte page size with 4-bit ECC */
-static struct nand_ecclayout oob_8192_ecc4 = {
-	.eccbytes = 128,
-	.eccpos = {
-		8, 9, 10, 11, 12, 13, 14, 15,
-		16, 17, 18, 19, 20, 21, 22, 23,
-		24, 25, 26, 27, 28, 29, 30, 31,
-		32, 33, 34, 35, 36, 37, 38, 39,
-		40, 41, 42, 43, 44, 45, 46, 47,
-		48, 49, 50, 51, 52, 53, 54, 55,
-		56, 57, 58, 59, 60, 61, 62, 63,
-		64, 65, 66, 67, 68, 69, 70, 71,
-		72, 73, 74, 75, 76, 77, 78, 79,
-		80, 81, 82, 83, 84, 85, 86, 87,
-		88, 89, 90, 91, 92, 93, 94, 95,
-		96, 97, 98, 99, 100, 101, 102, 103,
-		104, 105, 106, 107, 108, 109, 110, 111,
-		112, 113, 114, 115, 116, 117, 118, 119,
-		120, 121, 122, 123, 124, 125, 126, 127,
-		128, 129, 130, 131, 132, 133, 134, 135,
-	},
-	.oobfree = { {2, 6}, {136, 208} },
-};
-
-/* 8192-byte page size with 8-bit ECC -- requires 218-byte OOB */
-static struct nand_ecclayout oob_8192_ecc8 = {
-	.eccbytes = 256,
-	.eccpos = {
-		8, 9, 10, 11, 12, 13, 14, 15,
-		16, 17, 18, 19, 20, 21, 22, 23,
-		24, 25, 26, 27, 28, 29, 30, 31,
-		32, 33, 34, 35, 36, 37, 38, 39,
-		40, 41, 42, 43, 44, 45, 46, 47,
-		48, 49, 50, 51, 52, 53, 54, 55,
-		56, 57, 58, 59, 60, 61, 62, 63,
-		64, 65, 66, 67, 68, 69, 70, 71,
-		72, 73, 74, 75, 76, 77, 78, 79,
-		80, 81, 82, 83, 84, 85, 86, 87,
-		88, 89, 90, 91, 92, 93, 94, 95,
-		96, 97, 98, 99, 100, 101, 102, 103,
-		104, 105, 106, 107, 108, 109, 110, 111,
-		112, 113, 114, 115, 116, 117, 118, 119,
-		120, 121, 122, 123, 124, 125, 126, 127,
-		128, 129, 130, 131, 132, 133, 134, 135,
-		136, 137, 138, 139, 140, 141, 142, 143,
-		144, 145, 146, 147, 148, 149, 150, 151,
-		152, 153, 154, 155, 156, 157, 158, 159,
-		160, 161, 162, 163, 164, 165, 166, 167,
-		168, 169, 170, 171, 172, 173, 174, 175,
-		176, 177, 178, 179, 180, 181, 182, 183,
-		184, 185, 186, 187, 188, 189, 190, 191,
-		192, 193, 194, 195, 196, 197, 198, 199,
-		200, 201, 202, 203, 204, 205, 206, 207,
-		208, 209, 210, 211, 212, 213, 214, 215,
-		216, 217, 218, 219, 220, 221, 222, 223,
-		224, 225, 226, 227, 228, 229, 230, 231,
-		232, 233, 234, 235, 236, 237, 238, 239,
-		240, 241, 242, 243, 244, 245, 246, 247,
-		248, 249, 250, 251, 252, 253, 254, 255,
-		256, 257, 258, 259, 260, 261, 262, 263,
-	},
-	.oobfree = { {2, 6}, {264, 80} },
-};
-
 /*
  * Generic flash bbt descriptors
  */
@@ -223,6 +93,58 @@ static struct nand_bbt_descr bbt_mirror_descr = {
 	.pattern = mirror_pattern,
 };
 
+static int fsl_ifc_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 8;
+	oobregion->length = chip->ecc.bytes * chip->ecc.steps;
+
+	return 0;
+}
+
+static int fsl_ifc_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int eccbytes = chip->ecc.bytes * chip->ecc.steps;
+
+	if (section > 1)
+		return -ERANGE;
+
+	if (mtd->writesize == 512 &&
+	    !(chip->options & NAND_BUSWIDTH_16)) {
+		if (!section) {
+			oobregion->offset = 0;
+			oobregion->length = 5;
+		} else {
+			oobregion->offset = 6;
+			oobregion->length = 2;
+		}
+
+		return 0;
+	}
+
+	if (!section) {
+		oobregion->offset = 2;
+		oobregion->length = 6;
+	} else {
+		oobregion->offset = eccbytes + 8;
+		oobregion->length = mtd->oobsize - oobregion->offset;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops fsl_ifc_ooblayout_ops = {
+	.ecc = fsl_ifc_ooblayout_ecc,
+	.free = fsl_ifc_ooblayout_free,
+};
+
 /*
  * Set up the IFC hardware block and page address fields, and the ifc nand
  * structure addr field to point to the correct IFC buffer in memory
@@ -812,8 +734,8 @@ static int fsl_ifc_chip_init_tail(struct mtd_info *mtd)
 							chip->ecc.bytes);
 	dev_dbg(priv->dev, "%s: nand->ecc.total = %d\n", __func__,
 							chip->ecc.total);
-	dev_dbg(priv->dev, "%s: nand->ecc.layout = %p\n", __func__,
-							chip->ecc.layout);
+	dev_dbg(priv->dev, "%s: mtd->ooblayout = %p\n", __func__,
+							mtd->ooblayout);
 	dev_dbg(priv->dev, "%s: mtd->flags = %08x\n", __func__, mtd->flags);
 	dev_dbg(priv->dev, "%s: mtd->size = %lld\n", __func__, mtd->size);
 	dev_dbg(priv->dev, "%s: mtd->erasesize = %d\n", __func__,
@@ -880,8 +802,6 @@ static int fsl_ifc_chip_init(struct fsl_ifc_mtd *priv)
 	struct fsl_ifc_ctrl *ctrl = priv->ctrl;
 	struct fsl_ifc_regs __iomem *ifc = ctrl->regs;
 	struct nand_chip *chip = &priv->chip;
-	struct mtd_info *mtd = nand_to_mtd(&priv->chip);
-	struct nand_ecclayout *layout;
 	u32 csor;
 
 	/* Fill in fsl_ifc_mtd structure */
@@ -925,18 +845,9 @@ static int fsl_ifc_chip_init(struct fsl_ifc_mtd *priv)
 
 	csor = ifc_in32(&ifc->csor_cs[priv->bank].csor);
 
-	/* Hardware generates ECC per 512 Bytes */
-	chip->ecc.size = 512;
-	chip->ecc.bytes = 8;
-	chip->ecc.strength = 4;
-
 	switch (csor & CSOR_NAND_PGS_MASK) {
 	case CSOR_NAND_PGS_512:
-		if (chip->options & NAND_BUSWIDTH_16) {
-			layout = &oob_512_16bit_ecc4;
-		} else {
-			layout = &oob_512_8bit_ecc4;
-
+		if (!(chip->options & NAND_BUSWIDTH_16)) {
 			/* Avoid conflict with bad block marker */
 			bbt_main_descr.offs = 0;
 			bbt_mirror_descr.offs = 0;
@@ -946,35 +857,16 @@ static int fsl_ifc_chip_init(struct fsl_ifc_mtd *priv)
 		break;
 
 	case CSOR_NAND_PGS_2K:
-		layout = &oob_2048_ecc4;
 		priv->bufnum_mask = 3;
 		break;
 
 	case CSOR_NAND_PGS_4K:
-		if ((csor & CSOR_NAND_ECC_MODE_MASK) ==
-		    CSOR_NAND_ECC_MODE_4) {
-			layout = &oob_4096_ecc4;
-		} else {
-			layout = &oob_4096_ecc8;
-			chip->ecc.bytes = 16;
-			chip->ecc.strength = 8;
-		}
-
 		priv->bufnum_mask = 1;
 		break;
 
 	case CSOR_NAND_PGS_8K:
-		if ((csor & CSOR_NAND_ECC_MODE_MASK) ==
-		    CSOR_NAND_ECC_MODE_4) {
-			layout = &oob_8192_ecc4;
-		} else {
-			layout = &oob_8192_ecc8;
-			chip->ecc.bytes = 16;
-			chip->ecc.strength = 8;
-		}
-
 		priv->bufnum_mask = 0;
-	break;
+		break;
 
 	default:
 		dev_err(priv->dev, "bad csor %#x: bad page size\n", csor);
@@ -984,7 +876,17 @@ static int fsl_ifc_chip_init(struct fsl_ifc_mtd *priv)
 	/* Must also set CSOR_NAND_ECC_ENC_EN if DEC_EN set */
 	if (csor & CSOR_NAND_ECC_DEC_EN) {
 		chip->ecc.mode = NAND_ECC_HW;
-		chip->ecc.layout = layout;
+		mtd_set_ooblayout(&priv->mtd, &fsl_ifc_ooblayout_ops);
+
+		/* Hardware generates ECC per 512 Bytes */
+		chip->ecc.size = 512;
+		if ((csor & CSOR_NAND_ECC_MODE_MASK) == CSOR_NAND_ECC_MODE_4) {
+			chip->ecc.bytes = 8;
+			chip->ecc.strength = 4;
+		} else {
+			chip->ecc.bytes = 16;
+			chip->ecc.strength = 8;
+		}
 	} else {
 		chip->ecc.mode = NAND_ECC_SOFT;
 	}
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:32 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:32 +0100
Subject: [PATCH v2 09/51] mtd: nand: fsl_ifc: use mtd_ooblayout_xxx() helpers
 where appropriate
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-10-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/fsl_ifc_nand.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 43f5a3a..2e970ac 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -257,18 +257,22 @@ static int is_blank(struct mtd_info *mtd, unsigned int bufnum)
 	u8 __iomem *addr = priv->vbase + bufnum * (mtd->writesize * 2);
 	u32 __iomem *mainarea = (u32 __iomem *)addr;
 	u8 __iomem *oob = addr + mtd->writesize;
-	int i;
+	struct mtd_oob_region oobregion = { };
+	int i, section = 0;
 
 	for (i = 0; i < mtd->writesize / 4; i++) {
 		if (__raw_readl(&mainarea[i]) != 0xffffffff)
 			return 0;
 	}
 
-	for (i = 0; i < chip->ecc.layout->eccbytes; i++) {
-		int pos = chip->ecc.layout->eccpos[i];
+	mtd_ooblayout_ecc(mtd, section++, &oobregion);
+	while (oobregion.length) {
+		for (i = 0; i < oobregion.length; i++) {
+			if (__raw_readb(&oob[oobregion.offset + i]) != 0xff)
+				return 0;
+		}
 
-		if (__raw_readb(&oob[pos]) != 0xff)
-			return 0;
+		mtd_ooblayout_ecc(mtd, section++, &oobregion);
 	}
 
 	return 1;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:31 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:31 +0100
Subject: [PATCH v2 08/51] mtd: nand: atmel: use mtd_ooblayout_xxx() helpers
 where appropriate
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-9-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/atmel_nand.c | 38 ++++++++++++++++++++++++--------------
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index affe7a7..9dde308 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -828,13 +828,16 @@ static void pmecc_correct_data(struct mtd_info *mtd, uint8_t *buf, uint8_t *ecc,
 			dev_dbg(host->dev, "Bit flip in data area, byte_pos: %d, bit_pos: %d, 0x%02x -> 0x%02x\n",
 				pos, bit_pos, err_byte, *(buf + byte_pos));
 		} else {
+			struct mtd_oob_region oobregion;
+
 			/* Bit flip in OOB area */
 			tmp = sector_num * nand_chip->ecc.bytes
 					+ (byte_pos - sector_size);
 			err_byte = ecc[tmp];
 			ecc[tmp] ^= (1 << bit_pos);
 
-			pos = tmp + nand_chip->ecc.layout->eccpos[0];
+			mtd_ooblayout_ecc(mtd, 0, &oobregion);
+			pos = tmp + oobregion.offset;
 			dev_dbg(host->dev, "Bit flip in OOB, oob_byte_pos: %d, bit_pos: %d, 0x%02x -> 0x%02x\n",
 				pos, bit_pos, err_byte, ecc[tmp]);
 		}
@@ -923,7 +926,6 @@ static int atmel_nand_pmecc_read_page(struct mtd_info *mtd,
 	struct atmel_nand_host *host = nand_get_controller_data(chip);
 	int eccsize = chip->ecc.size * chip->ecc.steps;
 	uint8_t *oob = chip->oob_poi;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 	uint32_t stat;
 	unsigned long end_time;
 	int bitflips = 0;
@@ -945,7 +947,11 @@ static int atmel_nand_pmecc_read_page(struct mtd_info *mtd,
 
 	stat = pmecc_readl_relaxed(host->ecc, ISR);
 	if (stat != 0) {
-		bitflips = pmecc_correction(mtd, stat, buf, &oob[eccpos[0]]);
+		struct mtd_oob_region oobregion;
+
+		mtd_ooblayout_ecc(mtd, 0, &oobregion);
+		bitflips = pmecc_correction(mtd, stat, buf,
+					    &oob[oobregion.offset]);
 		if (bitflips < 0)
 			/* uncorrectable errors */
 			return 0;
@@ -959,8 +965,8 @@ static int atmel_nand_pmecc_write_page(struct mtd_info *mtd,
 		int page)
 {
 	struct atmel_nand_host *host = nand_get_controller_data(chip);
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
-	int i, j;
+	struct mtd_oob_region oobregion = { };
+	int i, j, section = 0;
 	unsigned long end_time;
 
 	if (!host->nfc || !host->nfc->write_by_sram) {
@@ -979,11 +985,12 @@ static int atmel_nand_pmecc_write_page(struct mtd_info *mtd,
 
 	for (i = 0; i < chip->ecc.steps; i++) {
 		for (j = 0; j < chip->ecc.bytes; j++) {
-			int pos;
+			if (!oobregion.length)
+				mtd_ooblayout_ecc(mtd, section++, &oobregion);
 
-			pos = i * chip->ecc.bytes + j;
-			chip->oob_poi[eccpos[pos]] =
+			chip->oob_poi[oobregion.offset++] =
 				pmecc_readb_ecc_relaxed(host->ecc, i, j);
+			oobregion.length--;
 		}
 	}
 	chip->write_buf(mtd, chip->oob_poi, mtd->oobsize);
@@ -997,6 +1004,7 @@ static void atmel_pmecc_core_init(struct mtd_info *mtd)
 	struct atmel_nand_host *host = nand_get_controller_data(nand_chip);
 	uint32_t val = 0;
 	struct nand_ecclayout *ecc_layout;
+	struct mtd_oob_region oobregion;
 
 	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_RST);
 	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DISABLE);
@@ -1045,9 +1053,10 @@ static void atmel_pmecc_core_init(struct mtd_info *mtd)
 
 	ecc_layout = nand_chip->ecc.layout;
 	pmecc_writel(host->ecc, SAREA, mtd->oobsize - 1);
-	pmecc_writel(host->ecc, SADDR, ecc_layout->eccpos[0]);
+	mtd_ooblayout_ecc(mtd, 0, &oobregion);
+	pmecc_writel(host->ecc, SADDR, oobregion.offset);
 	pmecc_writel(host->ecc, EADDR,
-			ecc_layout->eccpos[ecc_layout->eccbytes - 1]);
+		     oobregion.offset + ecc_layout->eccbytes - 1);
 	/* See datasheet about PMECC Clock Control Register */
 	pmecc_writel(host->ecc, CLK, 2);
 	pmecc_writel(host->ecc, IDR, 0xff);
@@ -1341,12 +1350,12 @@ static int atmel_nand_read_page(struct mtd_info *mtd, struct nand_chip *chip,
 {
 	int eccsize = chip->ecc.size;
 	int eccbytes = chip->ecc.bytes;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 	uint8_t *p = buf;
 	uint8_t *oob = chip->oob_poi;
 	uint8_t *ecc_pos;
 	int stat;
 	unsigned int max_bitflips = 0;
+	struct mtd_oob_region oobregion = {};
 
 	/*
 	 * Errata: ALE is incorrectly wired up to the ECC controller
@@ -1364,7 +1373,8 @@ static int atmel_nand_read_page(struct mtd_info *mtd, struct nand_chip *chip,
 	chip->read_buf(mtd, p, eccsize);
 
 	/* move to ECC position if needed */
-	if (eccpos[0] != 0) {
+	mtd_ooblayout_ecc(mtd, 0, &oobregion);
+	if (oobregion.offset != 0) {
 		/* This only works on large pages
 		 * because the ECC controller waits for
 		 * NAND_CMD_RNDOUTSTART after the
@@ -1372,11 +1382,11 @@ static int atmel_nand_read_page(struct mtd_info *mtd, struct nand_chip *chip,
 		 * anyway, for small pages, the eccpos[0] == 0
 		 */
 		chip->cmdfunc(mtd, NAND_CMD_RNDOUT,
-				mtd->writesize + eccpos[0], -1);
+				mtd->writesize + oobregion.offset, -1);
 	}
 
 	/* the ECC controller needs to read the ECC just after the data */
-	ecc_pos = oob + eccpos[0];
+	ecc_pos = oob + oobregion.offset;
 	chip->read_buf(mtd, ecc_pos, eccbytes);
 
 	/* check if there's an error */
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:50 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:50 +0100
Subject: [PATCH v2 27/51] mtd: nand: brcm: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-28-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 258 +++++++++++++++++++++--------------
 1 file changed, 157 insertions(+), 101 deletions(-)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c
index b86882b..169a095 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -749,127 +749,183 @@ static inline bool is_hamming_ecc(struct brcmnand_cfg *cfg)
 }
 
 /*
- * Returns a nand_ecclayout strucutre for the given layout/configuration.
- * Returns NULL on failure.
+ * Set mtd->ooblayout to the appropriate mtd_ooblayout_ops given
+ * the layout/configuration.
+ * Returns -ERRCODE on failure.
  */
-static struct nand_ecclayout *brcmnand_create_layout(int ecc_level,
-						     struct brcmnand_host *host)
+static int brcmnand_hamming_ooblayout_ecc(struct mtd_info *mtd, int section,
+					  struct mtd_oob_region *oobregion)
 {
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct brcmnand_host *host = nand_get_controller_data(chip);
 	struct brcmnand_cfg *cfg = &host->hwcfg;
-	int i, j;
-	struct nand_ecclayout *layout;
-	int req;
-	int sectors;
-	int sas;
-	int idx1, idx2;
-
-	layout = devm_kzalloc(&host->pdev->dev, sizeof(*layout), GFP_KERNEL);
-	if (!layout)
-		return NULL;
-
-	sectors = cfg->page_size / (512 << cfg->sector_size_1k);
-	sas = cfg->spare_area_size << cfg->sector_size_1k;
-
-	/* Hamming */
-	if (is_hamming_ecc(cfg)) {
-		for (i = 0, idx1 = 0, idx2 = 0; i < sectors; i++) {
-			/* First sector of each page may have BBI */
-			if (i == 0) {
-				layout->oobfree[idx2].offset = i * sas + 1;
-				/* Small-page NAND use byte 6 for BBI */
-				if (cfg->page_size == 512)
-					layout->oobfree[idx2].offset--;
-				layout->oobfree[idx2].length = 5;
-			} else {
-				layout->oobfree[idx2].offset = i * sas;
-				layout->oobfree[idx2].length = 6;
-			}
-			idx2++;
-			layout->eccpos[idx1++] = i * sas + 6;
-			layout->eccpos[idx1++] = i * sas + 7;
-			layout->eccpos[idx1++] = i * sas + 8;
-			layout->oobfree[idx2].offset = i * sas + 9;
-			layout->oobfree[idx2].length = 7;
-			idx2++;
-			/* Leave zero-terminated entry for OOBFREE */
-			if (idx1 >= MTD_MAX_ECCPOS_ENTRIES_LARGE ||
-				    idx2 >= MTD_MAX_OOBFREE_ENTRIES_LARGE - 1)
-				break;
-		}
+	int sas = cfg->spare_area_size << cfg->sector_size_1k;
+	int sectors = cfg->page_size / (512 << cfg->sector_size_1k);
 
-		return layout;
-	}
+	if (section >= sectors)
+		return -ERANGE;
 
-	/*
-	 * CONTROLLER_VERSION:
-	 *   < v5.0: ECC_REQ = ceil(BCH_T * 13/8)
-	 *  >= v5.0: ECC_REQ = ceil(BCH_T * 14/8)
-	 * But we will just be conservative.
-	 */
-	req = DIV_ROUND_UP(ecc_level * 14, 8);
-	if (req >= sas) {
-		dev_err(&host->pdev->dev,
-			"error: ECC too large for OOB (ECC bytes %d, spare sector %d)\n",
-			req, sas);
-		return NULL;
-	}
+	oobregion->offset = (section * sas) + 6;
+	oobregion->length = 3;
+
+	return 0;
+}
+
+static int brcmnand_hamming_ooblayout_free(struct mtd_info *mtd, int section,
+					   struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct brcmnand_host *host = nand_get_controller_data(chip);
+	struct brcmnand_cfg *cfg = &host->hwcfg;
+	int sas = cfg->spare_area_size << cfg->sector_size_1k;
+	int sectors = cfg->page_size / (512 << cfg->sector_size_1k);
+
+	if (section >= sectors * 2)
+		return -ERANGE;
 
-	layout->eccbytes = req * sectors;
-	for (i = 0, idx1 = 0, idx2 = 0; i < sectors; i++) {
-		for (j = sas - req; j < sas && idx1 <
-				MTD_MAX_ECCPOS_ENTRIES_LARGE; j++, idx1++)
-			layout->eccpos[idx1] = i * sas + j;
+	oobregion->offset = (section / 2) * sas;
+
+	if (section & 1) {
+		oobregion->offset += 9;
+		oobregion->length = 7;
+	} else {
+		oobregion->length = 6;
 
 		/* First sector of each page may have BBI */
-		if (i == 0) {
-			if (cfg->page_size == 512 && (sas - req >= 6)) {
-				/* Small-page NAND use byte 6 for BBI */
-				layout->oobfree[idx2].offset = 0;
-				layout->oobfree[idx2].length = 5;
-				idx2++;
-				if (sas - req > 6) {
-					layout->oobfree[idx2].offset = 6;
-					layout->oobfree[idx2].length =
-						sas - req - 6;
-					idx2++;
-				}
-			} else if (sas > req + 1) {
-				layout->oobfree[idx2].offset = i * sas + 1;
-				layout->oobfree[idx2].length = sas - req - 1;
-				idx2++;
-			}
-		} else if (sas > req) {
-			layout->oobfree[idx2].offset = i * sas;
-			layout->oobfree[idx2].length = sas - req;
-			idx2++;
+		if (!section) {
+			/*
+			 * Small-page NAND use byte 6 for BBI while large-page
+			 * NAND use byte 0.
+			 */
+			if (cfg->page_size > 512)
+				oobregion->offset++;
+			oobregion->length--;
 		}
-		/* Leave zero-terminated entry for OOBFREE */
-		if (idx1 >= MTD_MAX_ECCPOS_ENTRIES_LARGE ||
-				idx2 >= MTD_MAX_OOBFREE_ENTRIES_LARGE - 1)
-			break;
 	}
 
-	return layout;
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops brcmnand_hamming_ooblayout_ops = {
+	.ecc = brcmnand_hamming_ooblayout_ecc,
+	.free = brcmnand_hamming_ooblayout_free,
+};
+
+static int brcmnand_bch_ooblayout_ecc(struct mtd_info *mtd, int section,
+				      struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct brcmnand_host *host = nand_get_controller_data(chip);
+	struct brcmnand_cfg *cfg = &host->hwcfg;
+	int sas = cfg->spare_area_size << cfg->sector_size_1k;
+	int sectors = cfg->page_size / (512 << cfg->sector_size_1k);
+
+	if (section >= sectors)
+		return -ERANGE;
+
+	oobregion->offset = (section * (sas + 1)) - chip->ecc.bytes;
+	oobregion->length = chip->ecc.bytes;
+
+	return 0;
 }
 
-static struct nand_ecclayout *brcmstb_choose_ecc_layout(
-		struct brcmnand_host *host)
+static int brcmnand_bch_ooblayout_free_lp(struct mtd_info *mtd, int section,
+					  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct brcmnand_host *host = nand_get_controller_data(chip);
+	struct brcmnand_cfg *cfg = &host->hwcfg;
+	int sas = cfg->spare_area_size << cfg->sector_size_1k;
+	int sectors = cfg->page_size / (512 << cfg->sector_size_1k);
+
+	if (section >= sectors)
+		return -ERANGE;
+
+	if (sas <= chip->ecc.bytes)
+		return 0;
+
+	oobregion->offset = section * sas;
+	oobregion->length = sas - chip->ecc.bytes;
+
+	if (!section) {
+		oobregion->offset++;
+		oobregion->length--;
+	}
+
+	return 0;
+}
+
+static int brcmnand_bch_ooblayout_free_sp(struct mtd_info *mtd, int section,
+					  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct brcmnand_host *host = nand_get_controller_data(chip);
+	struct brcmnand_cfg *cfg = &host->hwcfg;
+	int sas = cfg->spare_area_size << cfg->sector_size_1k;
+
+	if (section > 1 || sas - chip->ecc.bytes < 6 ||
+	    (section && sas - chip->ecc.bytes == 6))
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 0;
+		oobregion->length = 5;
+	} else {
+		oobregion->offset = 6;
+		oobregion->length = sas - chip->ecc.bytes - 6;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops brcmnand_bch_lp_ooblayout_ops = {
+	.ecc = brcmnand_bch_ooblayout_ecc,
+	.free = brcmnand_bch_ooblayout_free_lp,
+};
+
+static const struct mtd_ooblayout_ops brcmnand_bch_sp_ooblayout_ops = {
+	.ecc = brcmnand_bch_ooblayout_ecc,
+	.free = brcmnand_bch_ooblayout_free_sp,
+};
+
+static int brcmstb_choose_ecc_layout(struct brcmnand_host *host)
 {
-	struct nand_ecclayout *layout;
 	struct brcmnand_cfg *p = &host->hwcfg;
+	struct mtd_info *mtd = nand_to_mtd(&host->chip);
+	struct nand_ecc_ctrl *ecc = &host->chip.ecc;
 	unsigned int ecc_level = p->ecc_level;
+	int sas = p->spare_area_size << p->sector_size_1k;
+	int sectors = p->page_size / (512 << p->sector_size_1k);
 
 	if (p->sector_size_1k)
 		ecc_level <<= 1;
 
-	layout = brcmnand_create_layout(ecc_level, host);
-	if (!layout) {
+	if (is_hamming_ecc(p)) {
+		ecc->bytes = 3 * sectors;
+		mtd_set_ooblayout(mtd, &brcmnand_hamming_ooblayout_ops);
+		return 0;
+	}
+
+	/*
+	 * CONTROLLER_VERSION:
+	 *   < v5.0: ECC_REQ = ceil(BCH_T * 13/8)
+	 *  >= v5.0: ECC_REQ = ceil(BCH_T * 14/8)
+	 * But we will just be conservative.
+	 */
+	ecc->bytes = DIV_ROUND_UP(ecc_level * 14, 8);
+	if (p->page_size == 512)
+		mtd_set_ooblayout(mtd, &brcmnand_bch_sp_ooblayout_ops);
+	else
+		mtd_set_ooblayout(mtd, &brcmnand_bch_lp_ooblayout_ops);
+
+	if (ecc->bytes >= sas) {
 		dev_err(&host->pdev->dev,
-				"no proper ecc_layout for this NAND cfg\n");
-		return NULL;
+			"error: ECC too large for OOB (ECC bytes %d, spare sector %d)\n",
+			ecc->bytes, sas);
+		return -EINVAL;
 	}
 
-	return layout;
+	return 0;
 }
 
 static void brcmnand_wp(struct mtd_info *mtd, int wp)
@@ -1979,9 +2035,9 @@ static int brcmnand_init_cs(struct brcmnand_host *host, struct device_node *dn)
 	/* only use our internal HW threshold */
 	mtd->bitflip_threshold = 1;
 
-	chip->ecc.layout = brcmstb_choose_ecc_layout(host);
-	if (!chip->ecc.layout)
-		return -ENXIO;
+	ret = brcmstb_choose_ecc_layout(host);
+	if (ret)
+		return ret;
 
 	if (nand_scan_tail(mtd))
 		return -ENXIO;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:45 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:45 +0100
Subject: [PATCH v2 22/51] mtd: nand: bch: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-23-git-send-email-boris.brezillon@free-electrons.com>

Replace the nand_ecclayout definition by the equivalent mtd_ooblayout_ops
definition.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/nand_bch.c | 33 +++++++++++----------------------
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/drivers/mtd/nand/nand_bch.c b/drivers/mtd/nand/nand_bch.c
index b3039de..e29e75f 100644
--- a/drivers/mtd/nand/nand_bch.c
+++ b/drivers/mtd/nand/nand_bch.c
@@ -32,13 +32,11 @@
 /**
  * struct nand_bch_control - private NAND BCH control structure
  * @bch:       BCH control structure
- * @ecclayout: private ecc layout for this BCH configuration
  * @errloc:    error location array
  * @eccmask:   XOR ecc mask, allows erased pages to be decoded as valid
  */
 struct nand_bch_control {
 	struct bch_control   *bch;
-	struct nand_ecclayout ecclayout;
 	unsigned int         *errloc;
 	unsigned char        *eccmask;
 };
@@ -124,7 +122,6 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
 {
 	struct nand_chip *nand = mtd_to_nand(mtd);
 	unsigned int m, t, eccsteps, i;
-	struct nand_ecclayout *layout = nand->ecc.layout;
 	struct nand_bch_control *nbc = NULL;
 	unsigned char *erased_page;
 	unsigned int eccsize = nand->ecc.size;
@@ -161,8 +158,17 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
 
 	eccsteps = mtd->writesize/eccsize;
 
+	/*
+	 * Rely on the default ecclayout to ooblayout wrapper provided by MTD
+	 * core if ecc.layout is not NULL.
+	 * FIXME: this should be removed when all callers have moved to the
+	 * mtd_ooblayout_ops approach.
+	 */
+	if (nand->ecc.layout)
+		mtd_set_ecclayout(mtd, nand->ecc.layout);
+
 	/* if no ecc placement scheme was provided, build one */
-	if (!layout) {
+	if (!mtd->ooblayout) {
 
 		/* handle large page devices only */
 		if (mtd->oobsize < 64) {
@@ -171,24 +177,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
 			goto fail;
 		}
 
-		layout = &nbc->ecclayout;
-		layout->eccbytes = eccsteps*eccbytes;
-
-		/* reserve 2 bytes for bad block marker */
-		if (layout->eccbytes+2 > mtd->oobsize) {
-			printk(KERN_WARNING "no suitable oob scheme available "
-			       "for oobsize %d eccbytes %u\n", mtd->oobsize,
-			       eccbytes);
-			goto fail;
-		}
-		/* put ecc bytes at oob tail */
-		for (i = 0; i < layout->eccbytes; i++)
-			layout->eccpos[i] = mtd->oobsize-layout->eccbytes+i;
-
-		layout->oobfree[0].offset = 2;
-		layout->oobfree[0].length = mtd->oobsize-2-layout->eccbytes;
-
-		nand->ecc.layout = layout;
+		mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
 	}
 
 	/* sanity checks */
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:07:03 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:07:03 +0100
Subject: [PATCH v2 40/51] mtd: nand: mxc: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-41-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/mxc_nand.c | 212 ++++++++++++++++++++++----------------------
 1 file changed, 105 insertions(+), 107 deletions(-)

diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
index 854c832..628f834 100644
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -149,7 +149,7 @@ struct mxc_nand_devtype_data {
 	int (*check_int)(struct mxc_nand_host *);
 	void (*irq_control)(struct mxc_nand_host *, int);
 	u32 (*get_ecc_status)(struct mxc_nand_host *);
-	struct nand_ecclayout *ecclayout_512, *ecclayout_2k, *ecclayout_4k;
+	const struct mtd_ooblayout_ops *ooblayout;
 	void (*select_chip)(struct mtd_info *mtd, int chip);
 	int (*correct_data)(struct mtd_info *mtd, u_char *dat,
 			u_char *read_ecc, u_char *calc_ecc);
@@ -200,73 +200,6 @@ struct mxc_nand_host {
 	struct mxc_nand_platform_data pdata;
 };
 
-/* OOB placement block for use with hardware ecc generation */
-static struct nand_ecclayout nandv1_hw_eccoob_smallpage = {
-	.eccbytes = 5,
-	.eccpos = {6, 7, 8, 9, 10},
-	.oobfree = {{0, 5}, {12, 4}, }
-};
-
-static struct nand_ecclayout nandv1_hw_eccoob_largepage = {
-	.eccbytes = 20,
-	.eccpos = {6, 7, 8, 9, 10, 22, 23, 24, 25, 26,
-		   38, 39, 40, 41, 42, 54, 55, 56, 57, 58},
-	.oobfree = {{2, 4}, {11, 10}, {27, 10}, {43, 10}, {59, 5}, }
-};
-
-/* OOB description for 512 byte pages with 16 byte OOB */
-static struct nand_ecclayout nandv2_hw_eccoob_smallpage = {
-	.eccbytes = 1 * 9,
-	.eccpos = {
-		 7,  8,  9, 10, 11, 12, 13, 14, 15
-	},
-	.oobfree = {
-		{.offset = 0, .length = 5}
-	}
-};
-
-/* OOB description for 2048 byte pages with 64 byte OOB */
-static struct nand_ecclayout nandv2_hw_eccoob_largepage = {
-	.eccbytes = 4 * 9,
-	.eccpos = {
-		 7,  8,  9, 10, 11, 12, 13, 14, 15,
-		23, 24, 25, 26, 27, 28, 29, 30, 31,
-		39, 40, 41, 42, 43, 44, 45, 46, 47,
-		55, 56, 57, 58, 59, 60, 61, 62, 63
-	},
-	.oobfree = {
-		{.offset = 2, .length = 4},
-		{.offset = 16, .length = 7},
-		{.offset = 32, .length = 7},
-		{.offset = 48, .length = 7}
-	}
-};
-
-/* OOB description for 4096 byte pages with 128 byte OOB */
-static struct nand_ecclayout nandv2_hw_eccoob_4k = {
-	.eccbytes = 8 * 9,
-	.eccpos = {
-		7,  8,  9, 10, 11, 12, 13, 14, 15,
-		23, 24, 25, 26, 27, 28, 29, 30, 31,
-		39, 40, 41, 42, 43, 44, 45, 46, 47,
-		55, 56, 57, 58, 59, 60, 61, 62, 63,
-		71, 72, 73, 74, 75, 76, 77, 78, 79,
-		87, 88, 89, 90, 91, 92, 93, 94, 95,
-		103, 104, 105, 106, 107, 108, 109, 110, 111,
-		119, 120, 121, 122, 123, 124, 125, 126, 127,
-	},
-	.oobfree = {
-		{.offset = 2, .length = 4},
-		{.offset = 16, .length = 7},
-		{.offset = 32, .length = 7},
-		{.offset = 48, .length = 7},
-		{.offset = 64, .length = 7},
-		{.offset = 80, .length = 7},
-		{.offset = 96, .length = 7},
-		{.offset = 112, .length = 7},
-	}
-};
-
 static const char * const part_probes[] = {
 	"cmdlinepart", "RedBoot", "ofpart", NULL };
 
@@ -942,6 +875,99 @@ static void mxc_do_addr_cycle(struct mtd_info *mtd, int column, int page_addr)
 	}
 }
 
+static int mxc_v1_ooblayout_ecc(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand_chip = mtd_to_nand(mtd);
+
+	if (section >= nand_chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 6;
+	oobregion->length = nand_chip->ecc.bytes;
+
+	return 0;
+}
+
+static int mxc_v1_ooblayout_free(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand_chip = mtd_to_nand(mtd);
+
+	if (section > nand_chip->ecc.steps)
+		return -ERANGE;
+
+	if (!section) {
+		if (mtd->writesize <= 512) {
+			oobregion->offset = 0;
+			oobregion->length = 5;
+		} else {
+			oobregion->offset = 2;
+			oobregion->length = 4;
+		}
+	} else {
+		oobregion->offset = ((section - 1) * 16) +
+				    nand_chip->ecc.bytes + 6;
+		if (section < nand_chip->ecc.steps)
+			oobregion->length = (section * 16) + 6 -
+					    oobregion->offset;
+		else
+			oobregion->length = mtd->oobsize - oobregion->offset;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops mxc_v1_ooblayout_ops = {
+	.ecc = mxc_v1_ooblayout_ecc,
+	.free = mxc_v1_ooblayout_free,
+};
+
+static int mxc_v2_ooblayout_ecc(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand_chip = mtd_to_nand(mtd);
+	int stepsize = nand_chip->ecc.bytes == 9 ? 16 : 26;
+
+	if (section >= nand_chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = (section * stepsize) + 7;
+	oobregion->length = nand_chip->ecc.bytes;
+
+	return 0;
+}
+
+static int mxc_v2_ooblayout_free(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand_chip = mtd_to_nand(mtd);
+	int stepsize = nand_chip->ecc.bytes == 9 ? 16 : 26;
+
+	if (section > nand_chip->ecc.steps)
+		return -ERANGE;
+
+	if (!section) {
+		if (mtd->writesize <= 512) {
+			oobregion->offset = 0;
+			oobregion->length = 5;
+		} else {
+			oobregion->offset = 2;
+			oobregion->length = 4;
+		}
+	} else {
+		oobregion->offset = section * stepsize;
+		oobregion->length = 7;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops mxc_v2_ooblayout_ops = {
+	.ecc = mxc_v2_ooblayout_ecc,
+	.free = mxc_v2_ooblayout_free,
+};
+
 /*
  * v2 and v3 type controllers can do 4bit or 8bit ecc depending
  * on how much oob the nand chip has. For 8bit ecc we need at least
@@ -959,23 +985,6 @@ static int get_eccsize(struct mtd_info *mtd)
 		return 8;
 }
 
-static void ecc_8bit_layout_4k(struct nand_ecclayout *layout)
-{
-	int i, j;
-
-	layout->eccbytes = 8*18;
-	for (i = 0; i < 8; i++)
-		for (j = 0; j < 18; j++)
-			layout->eccpos[i*18 + j] = i*26 + j + 7;
-
-	layout->oobfree[0].offset = 2;
-	layout->oobfree[0].length = 4;
-	for (i = 1; i < 8; i++) {
-		layout->oobfree[i].offset = i*26;
-		layout->oobfree[i].length = 7;
-	}
-}
-
 static void preset_v1(struct mtd_info *mtd)
 {
 	struct nand_chip *nand_chip = mtd_to_nand(mtd);
@@ -1269,9 +1278,7 @@ static const struct mxc_nand_devtype_data imx21_nand_devtype_data = {
 	.check_int = check_int_v1_v2,
 	.irq_control = irq_control_v1_v2,
 	.get_ecc_status = get_ecc_status_v1,
-	.ecclayout_512 = &nandv1_hw_eccoob_smallpage,
-	.ecclayout_2k = &nandv1_hw_eccoob_largepage,
-	.ecclayout_4k = &nandv1_hw_eccoob_smallpage, /* XXX: needs fix */
+	.ooblayout = &mxc_v1_ooblayout_ops,
 	.select_chip = mxc_nand_select_chip_v1_v3,
 	.correct_data = mxc_nand_correct_data_v1,
 	.irqpending_quirk = 1,
@@ -1294,9 +1301,7 @@ static const struct mxc_nand_devtype_data imx27_nand_devtype_data = {
 	.check_int = check_int_v1_v2,
 	.irq_control = irq_control_v1_v2,
 	.get_ecc_status = get_ecc_status_v1,
-	.ecclayout_512 = &nandv1_hw_eccoob_smallpage,
-	.ecclayout_2k = &nandv1_hw_eccoob_largepage,
-	.ecclayout_4k = &nandv1_hw_eccoob_smallpage, /* XXX: needs fix */
+	.ooblayout = &mxc_v1_ooblayout_ops,
 	.select_chip = mxc_nand_select_chip_v1_v3,
 	.correct_data = mxc_nand_correct_data_v1,
 	.irqpending_quirk = 0,
@@ -1320,9 +1325,7 @@ static const struct mxc_nand_devtype_data imx25_nand_devtype_data = {
 	.check_int = check_int_v1_v2,
 	.irq_control = irq_control_v1_v2,
 	.get_ecc_status = get_ecc_status_v2,
-	.ecclayout_512 = &nandv2_hw_eccoob_smallpage,
-	.ecclayout_2k = &nandv2_hw_eccoob_largepage,
-	.ecclayout_4k = &nandv2_hw_eccoob_4k,
+	.ooblayout = &mxc_v2_ooblayout_ops,
 	.select_chip = mxc_nand_select_chip_v2,
 	.correct_data = mxc_nand_correct_data_v2_v3,
 	.irqpending_quirk = 0,
@@ -1346,9 +1349,7 @@ static const struct mxc_nand_devtype_data imx51_nand_devtype_data = {
 	.check_int = check_int_v3,
 	.irq_control = irq_control_v3,
 	.get_ecc_status = get_ecc_status_v3,
-	.ecclayout_512 = &nandv2_hw_eccoob_smallpage,
-	.ecclayout_2k = &nandv2_hw_eccoob_largepage,
-	.ecclayout_4k = &nandv2_hw_eccoob_smallpage, /* XXX: needs fix */
+	.ooblayout = &mxc_v2_ooblayout_ops,
 	.select_chip = mxc_nand_select_chip_v1_v3,
 	.correct_data = mxc_nand_correct_data_v2_v3,
 	.irqpending_quirk = 0,
@@ -1373,9 +1374,7 @@ static const struct mxc_nand_devtype_data imx53_nand_devtype_data = {
 	.check_int = check_int_v3,
 	.irq_control = irq_control_v3,
 	.get_ecc_status = get_ecc_status_v3,
-	.ecclayout_512 = &nandv2_hw_eccoob_smallpage,
-	.ecclayout_2k = &nandv2_hw_eccoob_largepage,
-	.ecclayout_4k = &nandv2_hw_eccoob_smallpage, /* XXX: needs fix */
+	.ooblayout = &mxc_v2_ooblayout_ops,
 	.select_chip = mxc_nand_select_chip_v1_v3,
 	.correct_data = mxc_nand_correct_data_v2_v3,
 	.irqpending_quirk = 0,
@@ -1576,7 +1575,7 @@ static int mxcnd_probe(struct platform_device *pdev)
 
 	this->select_chip = host->devtype_data->select_chip;
 	this->ecc.size = 512;
-	this->ecc.layout = host->devtype_data->ecclayout_512;
+	mtd_set_ooblayout(mtd, host->devtype_data->ooblayout);
 
 	if (host->pdata.hw_ecc) {
 		this->ecc.calculate = mxc_nand_calculate_ecc;
@@ -1649,12 +1648,11 @@ static int mxcnd_probe(struct platform_device *pdev)
 	/* Call preset again, with correct writesize this time */
 	host->devtype_data->preset(mtd);
 
-	if (mtd->writesize == 2048)
-		this->ecc.layout = host->devtype_data->ecclayout_2k;
-	else if (mtd->writesize == 4096) {
-		this->ecc.layout = host->devtype_data->ecclayout_4k;
-		if (get_eccsize(mtd) == 8)
-			ecc_8bit_layout_4k(this->ecc.layout);
+	if (!this->ecc.bytes) {
+		if (host->eccsize == 8)
+			this->ecc.bytes = 18;
+		else if (host->eccsize == 4)
+			this->ecc.bytes = 9;
 	}
 
 	/*
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:49 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:49 +0100
Subject: [PATCH v2 26/51] mtd: nand: bf5xx: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-27-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/bf5xx_nand.c | 51 ++++++++++++++++++++++++-------------------
 1 file changed, 28 insertions(+), 23 deletions(-)

diff --git a/drivers/mtd/nand/bf5xx_nand.c b/drivers/mtd/nand/bf5xx_nand.c
index 7f6b30e..b38f414 100644
--- a/drivers/mtd/nand/bf5xx_nand.c
+++ b/drivers/mtd/nand/bf5xx_nand.c
@@ -109,28 +109,33 @@ static const unsigned short bfin_nfc_pin_req[] =
 	 0};
 
 #ifdef CONFIG_MTD_NAND_BF5XX_BOOTROM_ECC
-static struct nand_ecclayout bootrom_ecclayout = {
-	.eccbytes = 24,
-	.eccpos = {
-		0x8 * 0, 0x8 * 0 + 1, 0x8 * 0 + 2,
-		0x8 * 1, 0x8 * 1 + 1, 0x8 * 1 + 2,
-		0x8 * 2, 0x8 * 2 + 1, 0x8 * 2 + 2,
-		0x8 * 3, 0x8 * 3 + 1, 0x8 * 3 + 2,
-		0x8 * 4, 0x8 * 4 + 1, 0x8 * 4 + 2,
-		0x8 * 5, 0x8 * 5 + 1, 0x8 * 5 + 2,
-		0x8 * 6, 0x8 * 6 + 1, 0x8 * 6 + 2,
-		0x8 * 7, 0x8 * 7 + 1, 0x8 * 7 + 2
-	},
-	.oobfree = {
-		{ 0x8 * 0 + 3, 5 },
-		{ 0x8 * 1 + 3, 5 },
-		{ 0x8 * 2 + 3, 5 },
-		{ 0x8 * 3 + 3, 5 },
-		{ 0x8 * 4 + 3, 5 },
-		{ 0x8 * 5 + 3, 5 },
-		{ 0x8 * 6 + 3, 5 },
-		{ 0x8 * 7 + 3, 5 },
-	}
+static int bootrom_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	if (section > 7)
+		return -ERANGE;
+
+	oobregion->offset = section * 8;
+	oobregion->length = 3;
+
+	return 0;
+}
+
+static int bootrom_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	if (section > 7)
+		return -ERANGE;
+
+	oobregion->offset = (section * 8) + 3;
+	oobregion->length = 5;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops bootrom_ooblayout_ops = {
+	.ecc = bootrom_ooblayout_ecc,
+	.free = bootrom_ooblayout_free,
 };
 #endif
 
@@ -800,7 +805,7 @@ static int bf5xx_nand_probe(struct platform_device *pdev)
 	/* setup hardware ECC data struct */
 	if (hardware_ecc) {
 #ifdef CONFIG_MTD_NAND_BF5XX_BOOTROM_ECC
-		chip->ecc.layout = &bootrom_ecclayout;
+		mtd_set_ooblayout(mtd, &bootrom_ooblayout_ops);
 #endif
 		chip->read_buf      = bf5xx_nand_dma_read_buf;
 		chip->write_buf     = bf5xx_nand_dma_write_buf;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:59 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:59 +0100
Subject: [PATCH v2 36/51] mtd: nand: gpmi: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-37-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 52 ++++++++++++++++++++++++++--------
 1 file changed, 40 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 3a29b65..316b5ac 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -47,10 +47,44 @@ static struct nand_bbt_descr gpmi_bbt_descr = {
  * We may change the layout if we can get the ECC info from the datasheet,
  * else we will use all the (page + OOB).
  */
-static struct nand_ecclayout gpmi_hw_ecclayout = {
-	.eccbytes = 0,
-	.eccpos = { 0, },
-	.oobfree = { {.offset = 0, .length = 0} }
+static int gpmi_ooblayout_ecc(struct mtd_info *mtd, int section,
+			      struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct gpmi_nand_data *this = nand_get_controller_data(chip);
+	struct bch_geometry *geo = &this->bch_geometry;
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 0;
+	oobregion->length = geo->page_size - mtd->writesize;
+
+	return 0;
+}
+
+static int gpmi_ooblayout_free(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct gpmi_nand_data *this = nand_get_controller_data(chip);
+	struct bch_geometry *geo = &this->bch_geometry;
+
+	if (section)
+		return -ERANGE;
+
+	/* The available oob size we have. */
+	if (geo->page_size < mtd->writesize + mtd->oobsize) {
+		oobregion->offset = geo->page_size - mtd->writesize;
+		oobregion->length = mtd->oobsize - oobregion->offset;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops gpmi_ooblayout_ops = {
+	.ecc = gpmi_ooblayout_ecc,
+	.free = gpmi_ooblayout_free,
 };
 
 static const struct gpmi_devdata gpmi_devdata_imx23 = {
@@ -141,7 +175,6 @@ static int set_geometry_by_ecc_info(struct gpmi_nand_data *this)
 	struct bch_geometry *geo = &this->bch_geometry;
 	struct nand_chip *chip = &this->nand;
 	struct mtd_info *mtd = nand_to_mtd(chip);
-	struct nand_oobfree *of = gpmi_hw_ecclayout.oobfree;
 	unsigned int block_mark_bit_offset;
 
 	if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
@@ -229,12 +262,6 @@ static int set_geometry_by_ecc_info(struct gpmi_nand_data *this)
 	geo->page_size = mtd->writesize + geo->metadata_size +
 		(geo->gf_len * geo->ecc_strength * geo->ecc_chunk_count) / 8;
 
-	/* The available oob size we have. */
-	if (geo->page_size < mtd->writesize + mtd->oobsize) {
-		of->offset = geo->page_size - mtd->writesize;
-		of->length = mtd->oobsize - of->offset;
-	}
-
 	geo->payload_size = mtd->writesize;
 
 	geo->auxiliary_status_offset = ALIGN(geo->metadata_size, 4);
@@ -1841,6 +1868,7 @@ static void gpmi_nand_exit(struct gpmi_nand_data *this)
 static int gpmi_init_last(struct gpmi_nand_data *this)
 {
 	struct nand_chip *chip = &this->nand;
+	struct mtd_info *mtd = nand_to_mtd(chip);
 	struct nand_ecc_ctrl *ecc = &chip->ecc;
 	struct bch_geometry *bch_geo = &this->bch_geometry;
 	int ret;
@@ -1862,7 +1890,7 @@ static int gpmi_init_last(struct gpmi_nand_data *this)
 	ecc->mode	= NAND_ECC_HW;
 	ecc->size	= bch_geo->ecc_chunk_size;
 	ecc->strength	= bch_geo->ecc_strength;
-	ecc->layout	= &gpmi_hw_ecclayout;
+	mtd_set_ooblayout(mtd, &gpmi_ooblayout_ops);
 
 	/*
 	 * We only enable the subpage read when:
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:51 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:51 +0100
Subject: [PATCH v2 28/51] mtd: nand: cafe: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-29-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/cafe_nand.c | 45 ++++++++++++++++++++++++++++++++------------
 1 file changed, 33 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/nand/cafe_nand.c b/drivers/mtd/nand/cafe_nand.c
index aa1a616..0935b7c 100644
--- a/drivers/mtd/nand/cafe_nand.c
+++ b/drivers/mtd/nand/cafe_nand.c
@@ -459,10 +459,38 @@ static int cafe_nand_read_page(struct mtd_info *mtd, struct nand_chip *chip,
 	return max_bitflips;
 }
 
-static struct nand_ecclayout cafe_oobinfo_2048 = {
-	.eccbytes = 14,
-	.eccpos = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13},
-	.oobfree = {{14, 50}}
+static int cafe_ooblayout_ecc(struct mtd_info *mtd, int section,
+			      struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 0;
+	oobregion->length = chip->ecc.steps * chip->ecc.bytes;
+
+	return 0;
+}
+
+static int cafe_ooblayout_free(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int eccbytes = chip->ecc.steps * chip->ecc.bytes;
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = eccbytes;
+	oobregion->length = mtd->oobsize - eccbytes;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops cafe_ooblayout_ops = {
+	.ecc = cafe_ooblayout_ecc,
+	.free = cafe_ooblayout_free,
 };
 
 /* Ick. The BBT code really ought to be able to work this bit out
@@ -494,12 +522,6 @@ static struct nand_bbt_descr cafe_bbt_mirror_descr_2048 = {
 	.pattern = cafe_mirror_pattern_2048
 };
 
-static struct nand_ecclayout cafe_oobinfo_512 = {
-	.eccbytes = 14,
-	.eccpos = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13},
-	.oobfree = {{14, 2}}
-};
-
 static struct nand_bbt_descr cafe_bbt_main_descr_512 = {
 	.options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE
 		| NAND_BBT_2BIT | NAND_BBT_VERSION,
@@ -743,12 +765,11 @@ static int cafe_nand_probe(struct pci_dev *pdev,
 		cafe->ctl2 |= 1<<29; /* 2KiB page size */
 
 	/* Set up ECC according to the type of chip we found */
+	mtd_set_ooblayout(mtd, &cafe_ooblayout_ops);
 	if (mtd->writesize == 2048) {
-		cafe->nand.ecc.layout = &cafe_oobinfo_2048;
 		cafe->nand.bbt_td = &cafe_bbt_main_descr_2048;
 		cafe->nand.bbt_md = &cafe_bbt_mirror_descr_2048;
 	} else if (mtd->writesize == 512) {
-		cafe->nand.ecc.layout = &cafe_oobinfo_512;
 		cafe->nand.bbt_td = &cafe_bbt_main_descr_512;
 		cafe->nand.bbt_md = &cafe_bbt_mirror_descr_512;
 	} else {
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:44 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:44 +0100
Subject: [PATCH v2 21/51] mtd: nand: implement the default mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-22-git-send-email-boris.brezillon@free-electrons.com>

Replace the default nand_ecclayout definitions for large and small page
devices with the equivalent mtd_ooblayout_ops.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/nand_base.c | 147 ++++++++++++++++++++++++++++---------------
 include/linux/mtd/nand.h     |   3 +
 2 files changed, 99 insertions(+), 51 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index a01b472..e4dc62b 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -48,50 +48,6 @@
 #include <linux/mtd/partitions.h>
 #include <linux/of_mtd.h>
 
-/* Define default oob placement schemes for large and small page devices */
-static struct nand_ecclayout nand_oob_8 = {
-	.eccbytes = 3,
-	.eccpos = {0, 1, 2},
-	.oobfree = {
-		{.offset = 3,
-		 .length = 2},
-		{.offset = 6,
-		 .length = 2} }
-};
-
-static struct nand_ecclayout nand_oob_16 = {
-	.eccbytes = 6,
-	.eccpos = {0, 1, 2, 3, 6, 7},
-	.oobfree = {
-		{.offset = 8,
-		 . length = 8} }
-};
-
-static struct nand_ecclayout nand_oob_64 = {
-	.eccbytes = 24,
-	.eccpos = {
-		   40, 41, 42, 43, 44, 45, 46, 47,
-		   48, 49, 50, 51, 52, 53, 54, 55,
-		   56, 57, 58, 59, 60, 61, 62, 63},
-	.oobfree = {
-		{.offset = 2,
-		 .length = 38} }
-};
-
-static struct nand_ecclayout nand_oob_128 = {
-	.eccbytes = 48,
-	.eccpos = {
-		   80, 81, 82, 83, 84, 85, 86, 87,
-		   88, 89, 90, 91, 92, 93, 94, 95,
-		   96, 97, 98, 99, 100, 101, 102, 103,
-		   104, 105, 106, 107, 108, 109, 110, 111,
-		   112, 113, 114, 115, 116, 117, 118, 119,
-		   120, 121, 122, 123, 124, 125, 126, 127},
-	.oobfree = {
-		{.offset = 2,
-		 .length = 78} }
-};
-
 static int nand_get_device(struct mtd_info *mtd, int new_state);
 
 static int nand_do_write_oob(struct mtd_info *mtd, loff_t to,
@@ -103,6 +59,92 @@ static int nand_do_write_oob(struct mtd_info *mtd, loff_t to,
  */
 DEFINE_LED_TRIGGER(nand_led_trigger);
 
+/* Define default oob placement schemes for large and small page devices */
+static int nand_ooblayout_ecc_sp(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct nand_ecc_ctrl *ecc = &chip->ecc;
+
+	if (section > 1)
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 0;
+		oobregion->length = 4;
+	} else {
+		oobregion->offset = 6;
+		oobregion->length = (ecc->bytes * ecc->steps) - 4;
+	}
+
+	return 0;
+}
+
+static int nand_ooblayout_free_sp(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	if (section > 1)
+		return -ERANGE;
+
+	if (mtd->oobsize == 16) {
+		if (section)
+			return -ERANGE;
+
+		oobregion->length = 8;
+		oobregion->offset = 8;
+	} else {
+		oobregion->length = 2;
+		if (!section)
+			oobregion->offset = 3;
+		else
+			oobregion->offset = 6;
+	}
+
+	return 0;
+}
+
+const struct mtd_ooblayout_ops nand_ooblayout_sp_ops = {
+	.ecc = nand_ooblayout_ecc_sp,
+	.free = nand_ooblayout_free_sp,
+};
+EXPORT_SYMBOL_GPL(nand_ooblayout_sp_ops);
+
+static int nand_ooblayout_ecc_lp(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct nand_ecc_ctrl *ecc = &chip->ecc;
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->length = ecc->bytes * ecc->steps;
+	oobregion->offset = mtd->oobsize - oobregion->length;
+
+	return 0;
+}
+
+static int nand_ooblayout_free_lp(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct nand_ecc_ctrl *ecc = &chip->ecc;
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->length = mtd->oobsize - (ecc->bytes * ecc->steps) - 2;
+	oobregion->offset = 2;
+
+	return 0;
+}
+
+const struct mtd_ooblayout_ops nand_ooblayout_lp_ops = {
+	.ecc = nand_ooblayout_ecc_lp,
+	.free = nand_ooblayout_free_lp,
+};
+EXPORT_SYMBOL_GPL(nand_ooblayout_lp_ops);
+
 static int check_offs_len(struct mtd_info *mtd,
 					loff_t ofs, uint64_t len)
 {
@@ -4119,21 +4161,24 @@ int nand_scan_tail(struct mtd_info *mtd)
 	chip->oob_poi = chip->buffers->databuf + mtd->writesize;
 
 	/*
+	 * Set the provided ECC layout. If ecc->layout is NULL, the MTD core
+	 * will just leave mtd->ooblayout to NULL, if it's not NULL, it will
+	 * set ->ooblayout to the default ecclayout wrapper.
+	 */
+	mtd_set_ecclayout(mtd, ecc->layout);
+
+	/*
 	 * If no default placement scheme is given, select an appropriate one.
 	 */
-	if (!ecc->layout && (ecc->mode != NAND_ECC_SOFT_BCH)) {
+	if (!mtd->ooblayout && (ecc->mode != NAND_ECC_SOFT_BCH)) {
 		switch (mtd->oobsize) {
 		case 8:
-			ecc->layout = &nand_oob_8;
-			break;
 		case 16:
-			ecc->layout = &nand_oob_16;
+			mtd_set_ooblayout(mtd, &nand_ooblayout_sp_ops);
 			break;
 		case 64:
-			ecc->layout = &nand_oob_64;
-			break;
 		case 128:
-			ecc->layout = &nand_oob_128;
+			mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
 			break;
 		default:
 			pr_warn("No oob scheme defined for oobsize %d\n",
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 7604f4b..82a005a 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -740,6 +740,9 @@ struct nand_chip {
 	void *priv;
 };
 
+extern const struct mtd_ooblayout_ops nand_ooblayout_sp_ops;
+extern const struct mtd_ooblayout_ops nand_ooblayout_lp_ops;
+
 static inline void nand_set_flash_node(struct nand_chip *chip,
 				       struct device_node *np)
 {
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:07:08 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:07:08 +0100
Subject: [PATCH v2 45/51] mtd: nand: sm_common: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-46-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/sm_common.c | 93 ++++++++++++++++++++++++++++++++++++--------
 1 file changed, 77 insertions(+), 16 deletions(-)

diff --git a/drivers/mtd/nand/sm_common.c b/drivers/mtd/nand/sm_common.c
index c514740..355ca12 100644
--- a/drivers/mtd/nand/sm_common.c
+++ b/drivers/mtd/nand/sm_common.c
@@ -12,14 +12,47 @@
 #include <linux/sizes.h>
 #include "sm_common.h"
 
-static struct nand_ecclayout nand_oob_sm = {
-	.eccbytes = 6,
-	.eccpos = {8, 9, 10, 13, 14, 15},
-	.oobfree = {
-		{.offset = 0 , .length = 4}, /* reserved */
-		{.offset = 6 , .length = 2}, /* LBA1 */
-		{.offset = 11, .length = 2}  /* LBA2 */
+static int oob_sm_ooblayout_ecc(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	if (section > 1)
+		return -ERANGE;
+
+	oobregion->length = 3;
+	oobregion->offset = ((section + 1) * 8) - 3;
+
+	return 0;
+}
+
+static int oob_sm_ooblayout_free(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	switch (section) {
+	case 0:
+		/* reserved */
+		oobregion->offset = 0;
+		oobregion->length = 4;
+		break;
+	case 1:
+		/* LBA1 */
+		oobregion->offset = 6;
+		oobregion->length = 2;
+		break;
+	case 2:
+		/* LBA2 */
+		oobregion->offset = 11;
+		oobregion->length = 2;
+		break;
+	default:
+		return -ERANGE;
 	}
+
+	return 0;
+}
+
+const struct mtd_ooblayout_ops oob_sm_ops = {
+	.ecc = oob_sm_ooblayout_ecc,
+	.free = oob_sm_ooblayout_free,
 };
 
 /* NOTE: This layout is is not compatabable with SmartMedia, */
@@ -28,15 +61,43 @@ static struct nand_ecclayout nand_oob_sm = {
 /* If you use smftl, it will bypass this and work correctly */
 /* If you not, then you break SmartMedia compliance anyway */
 
-static struct nand_ecclayout nand_oob_sm_small = {
-	.eccbytes = 3,
-	.eccpos = {0, 1, 2},
-	.oobfree = {
-		{.offset = 3 , .length = 2}, /* reserved */
-		{.offset = 6 , .length = 2}, /* LBA1 */
+static int oob_sm_small_ooblayout_ecc(struct mtd_info *mtd, int section,
+				      struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->length = 3;
+	oobregion->offset = 0;
+
+	return 0;
+}
+
+static int oob_sm_small_ooblayout_free(struct mtd_info *mtd, int section,
+				       struct mtd_oob_region *oobregion)
+{
+	switch (section) {
+	case 0:
+		/* reserved */
+		oobregion->offset = 3;
+		oobregion->length = 2;
+		break;
+	case 1:
+		/* LBA1 */
+		oobregion->offset = 6;
+		oobregion->length = 2;
+		break;
+	default:
+		return -ERANGE;
 	}
-};
 
+	return 0;
+}
+
+const struct mtd_ooblayout_ops oob_sm_small_ops = {
+	.ecc = oob_sm_small_ooblayout_ecc,
+	.free = oob_sm_small_ooblayout_free,
+};
 
 static int sm_block_markbad(struct mtd_info *mtd, loff_t ofs)
 {
@@ -121,9 +182,9 @@ int sm_register_device(struct mtd_info *mtd, int smartmedia)
 
 	/* ECC layout */
 	if (mtd->writesize == SM_SECTOR_SIZE)
-		chip->ecc.layout = &nand_oob_sm;
+		mtd_set_ooblayout(mtd, &oob_sm_ops);
 	else if (mtd->writesize == SM_SMALL_PAGE)
-		chip->ecc.layout = &nand_oob_sm_small;
+		mtd_set_ooblayout(mtd, &oob_sm_small_ops);
 	else
 		return -ENODEV;
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:27 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:27 +0100
Subject: [PATCH v2 04/51] mtd: nand: simplify nand_bch_init() usage
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-5-git-send-email-boris.brezillon@free-electrons.com>

nand_bch_init() requires several arguments which could directly be deduced
from the mtd device. Get rid of those useless parameters.

nand_bch_init() is also requiring the caller to provide a proper eccbytes
value, while this value could be deduced from the ecc.size and
ecc.strength value. Fallback to eccbytes calculation when it is set to 0.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/nand_base.c |  6 ++----
 drivers/mtd/nand/nand_bch.c  | 27 +++++++++++++++++----------
 drivers/mtd/nand/omap2.c     | 28 ++++++++++++----------------
 include/linux/mtd/nand_bch.h |  8 ++------
 4 files changed, 33 insertions(+), 36 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 7f21719..572369d 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -4279,10 +4279,8 @@ int nand_scan_tail(struct mtd_info *mtd)
 		}
 
 		/* See nand_bch_init() for details. */
-		ecc->bytes = DIV_ROUND_UP(
-				ecc->strength * fls(8 * ecc->size), 8);
-		ecc->priv = nand_bch_init(mtd, ecc->size, ecc->bytes,
-					       &ecc->layout);
+		ecc->bytes = 0;
+		ecc->priv = nand_bch_init(mtd);
 		if (!ecc->priv) {
 			pr_warn("BCH ECC initialization failed!\n");
 			BUG();
diff --git a/drivers/mtd/nand/nand_bch.c b/drivers/mtd/nand/nand_bch.c
index a87c1b6..b585bae 100644
--- a/drivers/mtd/nand/nand_bch.c
+++ b/drivers/mtd/nand/nand_bch.c
@@ -107,9 +107,6 @@ EXPORT_SYMBOL(nand_bch_correct_data);
 /**
  * nand_bch_init - [NAND Interface] Initialize NAND BCH error correction
  * @mtd:	MTD block structure
- * @eccsize:	ecc block size in bytes
- * @eccbytes:	ecc length in bytes
- * @ecclayout:	output default layout
  *
  * Returns:
  *  a pointer to a new NAND BCH control structure, or NULL upon failure
@@ -123,14 +120,21 @@ EXPORT_SYMBOL(nand_bch_correct_data);
  * @eccsize = 512  (thus, m=13 is the smallest integer such that 2^m-1 > 512*8)
  * @eccbytes = 7   (7 bytes are required to store m*t = 13*4 = 52 bits)
  */
-struct nand_bch_control *
-nand_bch_init(struct mtd_info *mtd, unsigned int eccsize, unsigned int eccbytes,
-	      struct nand_ecclayout **ecclayout)
+struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
 {
+	struct nand_chip *nand = mtd_to_nand(mtd);
 	unsigned int m, t, eccsteps, i;
-	struct nand_ecclayout *layout;
+	struct nand_ecclayout *layout = nand->ecc.layout;
 	struct nand_bch_control *nbc = NULL;
 	unsigned char *erased_page;
+	unsigned int eccsize = nand->ecc.size;
+	unsigned int eccbytes = nand->ecc.bytes;
+	unsigned int eccstrength = nand->ecc.strength;
+
+	if (!eccbytes && eccstrength) {
+		eccbytes = DIV_ROUND_UP(eccstrength * fls(8 * eccsize), 8);
+		nand->ecc.bytes = eccbytes;
+	}
 
 	if (!eccsize || !eccbytes) {
 		printk(KERN_WARNING "ecc parameters not supplied\n");
@@ -158,7 +162,7 @@ nand_bch_init(struct mtd_info *mtd, unsigned int eccsize, unsigned int eccbytes,
 	eccsteps = mtd->writesize/eccsize;
 
 	/* if no ecc placement scheme was provided, build one */
-	if (!*ecclayout) {
+	if (!layout) {
 
 		/* handle large page devices only */
 		if (mtd->oobsize < 64) {
@@ -184,7 +188,7 @@ nand_bch_init(struct mtd_info *mtd, unsigned int eccsize, unsigned int eccbytes,
 		layout->oobfree[0].offset = 2;
 		layout->oobfree[0].length = mtd->oobsize-2-layout->eccbytes;
 
-		*ecclayout = layout;
+		nand->ecc.layout = layout;
 	}
 
 	/* sanity checks */
@@ -192,7 +196,7 @@ nand_bch_init(struct mtd_info *mtd, unsigned int eccsize, unsigned int eccbytes,
 		printk(KERN_WARNING "eccsize %u is too large\n", eccsize);
 		goto fail;
 	}
-	if ((*ecclayout)->eccbytes != (eccsteps*eccbytes)) {
+	if (layout->eccbytes != (eccsteps*eccbytes)) {
 		printk(KERN_WARNING "invalid ecc layout\n");
 		goto fail;
 	}
@@ -216,6 +220,9 @@ nand_bch_init(struct mtd_info *mtd, unsigned int eccsize, unsigned int eccbytes,
 	for (i = 0; i < eccbytes; i++)
 		nbc->eccmask[i] ^= 0xff;
 
+	if (!eccstrength)
+		nand->ecc.strength = (eccbytes * 8) / fls(8 * eccsize);
+
 	return nbc;
 fail:
 	nand_bch_free(nbc);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index c553f78..0749ca1 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1807,13 +1807,19 @@ static int omap_nand_probe(struct platform_device *pdev)
 		goto return_error;
 	}
 
+	/*
+	 * Bail out earlier to let NAND_ECC_SOFT code create its own
+	 * ecclayout instead of using ours.
+	 */
+	if (info->ecc_opt == OMAP_ECC_HAM1_CODE_SW) {
+		nand_chip->ecc.mode = NAND_ECC_SOFT;
+		goto scan_tail;
+	}
+
 	/* populate MTD interface based on ECC scheme */
 	ecclayout		= &info->oobinfo;
+	nand_chip->ecc.layout	= ecclayout;
 	switch (info->ecc_opt) {
-	case OMAP_ECC_HAM1_CODE_SW:
-		nand_chip->ecc.mode = NAND_ECC_SOFT;
-		break;
-
 	case OMAP_ECC_HAM1_CODE_HW:
 		pr_info("nand: using OMAP_ECC_HAM1_CODE_HW\n");
 		nand_chip->ecc.mode             = NAND_ECC_HW;
@@ -1861,10 +1867,7 @@ static int omap_nand_probe(struct platform_device *pdev)
 		ecclayout->oobfree->offset	= 1 +
 				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
 		/* software bch library is used for locating errors */
-		nand_chip->ecc.priv		= nand_bch_init(mtd,
-							nand_chip->ecc.size,
-							nand_chip->ecc.bytes,
-							&ecclayout);
+		nand_chip->ecc.priv		= nand_bch_init(mtd);
 		if (!nand_chip->ecc.priv) {
 			dev_err(&info->pdev->dev, "unable to use BCH library\n");
 			err = -EINVAL;
@@ -1925,10 +1928,7 @@ static int omap_nand_probe(struct platform_device *pdev)
 		ecclayout->oobfree->offset	= 1 +
 				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
 		/* software bch library is used for locating errors */
-		nand_chip->ecc.priv		= nand_bch_init(mtd,
-							nand_chip->ecc.size,
-							nand_chip->ecc.bytes,
-							&ecclayout);
+		nand_chip->ecc.priv		= nand_bch_init(mtd);
 		if (!nand_chip->ecc.priv) {
 			dev_err(&info->pdev->dev, "unable to use BCH library\n");
 			err = -EINVAL;
@@ -2002,9 +2002,6 @@ static int omap_nand_probe(struct platform_device *pdev)
 		goto return_error;
 	}
 
-	if (info->ecc_opt == OMAP_ECC_HAM1_CODE_SW)
-		goto scan_tail;
-
 	/* all OOB bytes from oobfree->offset till end off OOB are free */
 	ecclayout->oobfree->length = mtd->oobsize - ecclayout->oobfree->offset;
 	/* check if NAND device's OOB is enough to store ECC signatures */
@@ -2015,7 +2012,6 @@ static int omap_nand_probe(struct platform_device *pdev)
 		err = -EINVAL;
 		goto return_error;
 	}
-	nand_chip->ecc.layout = ecclayout;
 
 scan_tail:
 	/* second phase scan */
diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
index fb0bc34..98f20ef 100644
--- a/include/linux/mtd/nand_bch.h
+++ b/include/linux/mtd/nand_bch.h
@@ -32,9 +32,7 @@ int nand_bch_correct_data(struct mtd_info *mtd, u_char *dat, u_char *read_ecc,
 /*
  * Initialize BCH encoder/decoder
  */
-struct nand_bch_control *
-nand_bch_init(struct mtd_info *mtd, unsigned int eccsize,
-	      unsigned int eccbytes, struct nand_ecclayout **ecclayout);
+struct nand_bch_control *nand_bch_init(struct mtd_info *mtd);
 /*
  * Release BCH encoder/decoder resources
  */
@@ -58,9 +56,7 @@ nand_bch_correct_data(struct mtd_info *mtd, unsigned char *buf,
 	return -ENOTSUPP;
 }
 
-static inline struct nand_bch_control *
-nand_bch_init(struct mtd_info *mtd, unsigned int eccsize,
-	      unsigned int eccbytes, struct nand_ecclayout **ecclayout)
+static inline struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
 {
 	return NULL;
 }
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:56 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:56 +0100
Subject: [PATCH v2 33/51] mtd: nand: fsl_elbc: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-34-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/fsl_elbc_nand.c | 83 +++++++++++++++++++++++-----------------
 1 file changed, 47 insertions(+), 36 deletions(-)

diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 059d5f7..487eae0 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -79,32 +79,53 @@ struct fsl_elbc_fcm_ctrl {
 
 /* These map to the positions used by the FCM hardware ECC generator */
 
-/* Small Page FLASH with FMR[ECCM] = 0 */
-static struct nand_ecclayout fsl_elbc_oob_sp_eccm0 = {
-	.eccbytes = 3,
-	.eccpos = {6, 7, 8},
-	.oobfree = { {0, 5}, {9, 7} },
-};
+static int fsl_elbc_ooblayout_ecc(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct fsl_elbc_mtd *priv = nand_get_controller_data(chip);
 
-/* Small Page FLASH with FMR[ECCM] = 1 */
-static struct nand_ecclayout fsl_elbc_oob_sp_eccm1 = {
-	.eccbytes = 3,
-	.eccpos = {8, 9, 10},
-	.oobfree = { {0, 5}, {6, 2}, {11, 5} },
-};
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
 
-/* Large Page FLASH with FMR[ECCM] = 0 */
-static struct nand_ecclayout fsl_elbc_oob_lp_eccm0 = {
-	.eccbytes = 12,
-	.eccpos = {6, 7, 8, 22, 23, 24, 38, 39, 40, 54, 55, 56},
-	.oobfree = { {1, 5}, {9, 13}, {25, 13}, {41, 13}, {57, 7} },
-};
+	oobregion->offset = (16 * section) + 6;
+	if (priv->fmr & FMR_ECCM)
+		oobregion->offset += 2;
 
-/* Large Page FLASH with FMR[ECCM] = 1 */
-static struct nand_ecclayout fsl_elbc_oob_lp_eccm1 = {
-	.eccbytes = 12,
-	.eccpos = {8, 9, 10, 24, 25, 26, 40, 41, 42, 56, 57, 58},
-	.oobfree = { {1, 7}, {11, 13}, {27, 13}, {43, 13}, {59, 5} },
+	oobregion->length = chip->ecc.bytes;
+
+	return 0;
+}
+
+static int fsl_elbc_ooblayout_free(struct mtd_info *mtd, int section,
+				   struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct fsl_elbc_mtd *priv = nand_get_controller_data(chip);
+
+	if (section > chip->ecc.steps)
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 0;
+		if (mtd->writesize > 512)
+			oobregion->offset++;
+		oobregion->length = (priv->fmr & FMR_ECCM) ? 7 : 5;
+	} else {
+		oobregion->offset = (16 * section) -
+				    ((priv->fmr & FMR_ECCM) ? 5 : 7);
+		if (section < chip->ecc.steps)
+			oobregion->length = 13;
+		else
+			oobregion->length = mtd->oobsize - oobregion->offset;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops fsl_elbc_ooblayout_ops = {
+	.ecc = fsl_elbc_ooblayout_ecc,
+	.free = fsl_elbc_ooblayout_free,
 };
 
 /*
@@ -657,8 +678,8 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
 	        chip->ecc.bytes);
 	dev_dbg(priv->dev, "fsl_elbc_init: nand->ecc.total = %d\n",
 	        chip->ecc.total);
-	dev_dbg(priv->dev, "fsl_elbc_init: nand->ecc.layout = %p\n",
-	        chip->ecc.layout);
+	dev_dbg(priv->dev, "fsl_elbc_init: mtd->ooblayout = %p\n",
+		mtd->ooblayout);
 	dev_dbg(priv->dev, "fsl_elbc_init: mtd->flags = %08x\n", mtd->flags);
 	dev_dbg(priv->dev, "fsl_elbc_init: mtd->size = %lld\n", mtd->size);
 	dev_dbg(priv->dev, "fsl_elbc_init: mtd->erasesize = %d\n",
@@ -675,14 +696,6 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
 	} else if (mtd->writesize == 2048) {
 		priv->page_size = 1;
 		setbits32(&lbc->bank[priv->bank].or, OR_FCM_PGS);
-		/* adjust ecc setup if needed */
-		if ((in_be32(&lbc->bank[priv->bank].br) & BR_DECC) ==
-		    BR_DECC_CHK_GEN) {
-			chip->ecc.size = 512;
-			chip->ecc.layout = (priv->fmr & FMR_ECCM) ?
-			                   &fsl_elbc_oob_lp_eccm1 :
-			                   &fsl_elbc_oob_lp_eccm0;
-		}
 	} else {
 		dev_err(priv->dev,
 		        "fsl_elbc_init: page size %d is not supported\n",
@@ -780,9 +793,7 @@ static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv)
 	if ((in_be32(&lbc->bank[priv->bank].br) & BR_DECC) ==
 	    BR_DECC_CHK_GEN) {
 		chip->ecc.mode = NAND_ECC_HW;
-		/* put in small page settings and adjust later if needed */
-		chip->ecc.layout = (priv->fmr & FMR_ECCM) ?
-				&fsl_elbc_oob_sp_eccm1 : &fsl_elbc_oob_sp_eccm0;
+		mtd_set_ooblayout(mtd, &fsl_elbc_ooblayout_ops);
 		chip->ecc.size = 512;
 		chip->ecc.bytes = 3;
 		chip->ecc.strength = 1;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:30 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:30 +0100
Subject: [PATCH v2 07/51] mtd: nand: core: use mtd_ooblayout_xxx() helpers
 where appropriate
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-8-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/nand_base.c | 169 ++++++++++++++++++-------------------------
 drivers/mtd/nand/nand_bch.c  |   3 +-
 2 files changed, 74 insertions(+), 98 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 572369d..e01a9b5 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1309,13 +1309,12 @@ static int nand_read_page_raw_syndrome(struct mtd_info *mtd,
 static int nand_read_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
 				uint8_t *buf, int oob_required, int page)
 {
-	int i, eccsize = chip->ecc.size;
+	int i, eccsize = chip->ecc.size, ret;
 	int eccbytes = chip->ecc.bytes;
 	int eccsteps = chip->ecc.steps;
 	uint8_t *p = buf;
 	uint8_t *ecc_calc = chip->buffers->ecccalc;
 	uint8_t *ecc_code = chip->buffers->ecccode;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 	unsigned int max_bitflips = 0;
 
 	chip->ecc.read_page_raw(mtd, chip, buf, 1, page);
@@ -1323,8 +1322,10 @@ static int nand_read_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
 	for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize)
 		chip->ecc.calculate(mtd, p, &ecc_calc[i]);
 
-	for (i = 0; i < chip->ecc.total; i++)
-		ecc_code[i] = chip->oob_poi[eccpos[i]];
+	ret = mtd_ooblayout_get_eccbytes(mtd, ecc_code, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	eccsteps = chip->ecc.steps;
 	p = buf;
@@ -1356,14 +1357,14 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip,
 			uint32_t data_offs, uint32_t readlen, uint8_t *bufpoi,
 			int page)
 {
-	int start_step, end_step, num_steps;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
+	int start_step, end_step, num_steps, ret;
 	uint8_t *p;
 	int data_col_addr, i, gaps = 0;
 	int datafrag_len, eccfrag_len, aligned_len, aligned_pos;
 	int busw = (chip->options & NAND_BUSWIDTH_16) ? 2 : 1;
-	int index;
+	int index, section = 0;
 	unsigned int max_bitflips = 0;
+	struct mtd_oob_region oobregion = { };
 
 	/* Column address within the page aligned to ECC size (256bytes) */
 	start_step = data_offs / chip->ecc.size;
@@ -1391,12 +1392,13 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip,
 	 * The performance is faster if we position offsets according to
 	 * ecc.pos. Let's make sure that there are no gaps in ECC positions.
 	 */
-	for (i = 0; i < eccfrag_len - 1; i++) {
-		if (eccpos[i + index] + 1 != eccpos[i + index + 1]) {
-			gaps = 1;
-			break;
-		}
-	}
+	ret = mtd_ooblayout_find_eccregion(mtd, index, &section, &oobregion);
+	if (ret)
+		return ret;
+
+	if (oobregion.length < eccfrag_len)
+		gaps = 1;
+
 	if (gaps) {
 		chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
 		chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
@@ -1405,20 +1407,23 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip,
 		 * Send the command to read the particular ECC bytes take care
 		 * about buswidth alignment in read_buf.
 		 */
-		aligned_pos = eccpos[index] & ~(busw - 1);
+		aligned_pos = oobregion.offset & ~(busw - 1);
 		aligned_len = eccfrag_len;
-		if (eccpos[index] & (busw - 1))
+		if (oobregion.offset & (busw - 1))
 			aligned_len++;
-		if (eccpos[index + (num_steps * chip->ecc.bytes)] & (busw - 1))
+		if ((oobregion.offset + (num_steps * chip->ecc.bytes)) &
+		    (busw - 1))
 			aligned_len++;
 
 		chip->cmdfunc(mtd, NAND_CMD_RNDOUT,
-					mtd->writesize + aligned_pos, -1);
+			      mtd->writesize + aligned_pos, -1);
 		chip->read_buf(mtd, &chip->oob_poi[aligned_pos], aligned_len);
 	}
 
-	for (i = 0; i < eccfrag_len; i++)
-		chip->buffers->ecccode[i] = chip->oob_poi[eccpos[i + index]];
+	ret = mtd_ooblayout_get_eccbytes(mtd, chip->buffers->ecccode,
+					 chip->oob_poi, index, eccfrag_len);
+	if (ret)
+		return ret;
 
 	p = bufpoi + data_col_addr;
 	for (i = 0; i < eccfrag_len ; i += chip->ecc.bytes, p += chip->ecc.size) {
@@ -1459,13 +1464,12 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip,
 static int nand_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
 				uint8_t *buf, int oob_required, int page)
 {
-	int i, eccsize = chip->ecc.size;
+	int i, eccsize = chip->ecc.size, ret;
 	int eccbytes = chip->ecc.bytes;
 	int eccsteps = chip->ecc.steps;
 	uint8_t *p = buf;
 	uint8_t *ecc_calc = chip->buffers->ecccalc;
 	uint8_t *ecc_code = chip->buffers->ecccode;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 	unsigned int max_bitflips = 0;
 
 	for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
@@ -1475,8 +1479,10 @@ static int nand_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
 	}
 	chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
 
-	for (i = 0; i < chip->ecc.total; i++)
-		ecc_code[i] = chip->oob_poi[eccpos[i]];
+	ret = mtd_ooblayout_get_eccbytes(mtd, ecc_code, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	eccsteps = chip->ecc.steps;
 	p = buf;
@@ -1521,12 +1527,11 @@ static int nand_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
 static int nand_read_page_hwecc_oob_first(struct mtd_info *mtd,
 	struct nand_chip *chip, uint8_t *buf, int oob_required, int page)
 {
-	int i, eccsize = chip->ecc.size;
+	int i, eccsize = chip->ecc.size, ret;
 	int eccbytes = chip->ecc.bytes;
 	int eccsteps = chip->ecc.steps;
 	uint8_t *p = buf;
 	uint8_t *ecc_code = chip->buffers->ecccode;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 	uint8_t *ecc_calc = chip->buffers->ecccalc;
 	unsigned int max_bitflips = 0;
 
@@ -1535,8 +1540,10 @@ static int nand_read_page_hwecc_oob_first(struct mtd_info *mtd,
 	chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
 	chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
 
-	for (i = 0; i < chip->ecc.total; i++)
-		ecc_code[i] = chip->oob_poi[eccpos[i]];
+	ret = mtd_ooblayout_get_eccbytes(mtd, ecc_code, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
 		int stat;
@@ -1637,14 +1644,17 @@ static int nand_read_page_syndrome(struct mtd_info *mtd, struct nand_chip *chip,
 
 /**
  * nand_transfer_oob - [INTERN] Transfer oob to client buffer
- * @chip: nand chip structure
+ * @mtd: mtd info structure
  * @oob: oob destination address
  * @ops: oob ops structure
  * @len: size of oob to transfer
  */
-static uint8_t *nand_transfer_oob(struct nand_chip *chip, uint8_t *oob,
+static uint8_t *nand_transfer_oob(struct mtd_info *mtd, uint8_t *oob,
 				  struct mtd_oob_ops *ops, size_t len)
 {
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int ret;
+
 	switch (ops->mode) {
 
 	case MTD_OPS_PLACE_OOB:
@@ -1652,31 +1662,12 @@ static uint8_t *nand_transfer_oob(struct nand_chip *chip, uint8_t *oob,
 		memcpy(oob, chip->oob_poi + ops->ooboffs, len);
 		return oob + len;
 
-	case MTD_OPS_AUTO_OOB: {
-		struct nand_oobfree *free = chip->ecc.layout->oobfree;
-		uint32_t boffs = 0, roffs = ops->ooboffs;
-		size_t bytes = 0;
-
-		for (; free->length && len; free++, len -= bytes) {
-			/* Read request not from offset 0? */
-			if (unlikely(roffs)) {
-				if (roffs >= free->length) {
-					roffs -= free->length;
-					continue;
-				}
-				boffs = free->offset + roffs;
-				bytes = min_t(size_t, len,
-					      (free->length - roffs));
-				roffs = 0;
-			} else {
-				bytes = min_t(size_t, len, free->length);
-				boffs = free->offset;
-			}
-			memcpy(oob, chip->oob_poi + boffs, bytes);
-			oob += bytes;
-		}
-		return oob;
-	}
+	case MTD_OPS_AUTO_OOB:
+		ret = mtd_ooblayout_get_databytes(mtd, oob, chip->oob_poi,
+						  ops->ooboffs, len);
+		BUG_ON(ret);
+		return oob + len;
+
 	default:
 		BUG();
 	}
@@ -1810,7 +1801,7 @@ read_retry:
 				int toread = min(oobreadlen, max_oobsize);
 
 				if (toread) {
-					oob = nand_transfer_oob(chip,
+					oob = nand_transfer_oob(mtd,
 						oob, ops, toread);
 					oobreadlen -= toread;
 				}
@@ -2108,7 +2099,7 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
 			break;
 
 		len = min(len, readlen);
-		buf = nand_transfer_oob(chip, buf, ops, len);
+		buf = nand_transfer_oob(mtd, buf, ops, len);
 
 		if (chip->options & NAND_NEED_READRDY) {
 			/* Apply delay or wait for ready/busy pin */
@@ -2267,19 +2258,20 @@ static int nand_write_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
 				 const uint8_t *buf, int oob_required,
 				 int page)
 {
-	int i, eccsize = chip->ecc.size;
+	int i, eccsize = chip->ecc.size, ret;
 	int eccbytes = chip->ecc.bytes;
 	int eccsteps = chip->ecc.steps;
 	uint8_t *ecc_calc = chip->buffers->ecccalc;
 	const uint8_t *p = buf;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 
 	/* Software ECC calculation */
 	for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize)
 		chip->ecc.calculate(mtd, p, &ecc_calc[i]);
 
-	for (i = 0; i < chip->ecc.total; i++)
-		chip->oob_poi[eccpos[i]] = ecc_calc[i];
+	ret = mtd_ooblayout_set_eccbytes(mtd, ecc_calc, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	return chip->ecc.write_page_raw(mtd, chip, buf, 1, page);
 }
@@ -2296,12 +2288,11 @@ static int nand_write_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
 				  const uint8_t *buf, int oob_required,
 				  int page)
 {
-	int i, eccsize = chip->ecc.size;
+	int i, eccsize = chip->ecc.size, ret;
 	int eccbytes = chip->ecc.bytes;
 	int eccsteps = chip->ecc.steps;
 	uint8_t *ecc_calc = chip->buffers->ecccalc;
 	const uint8_t *p = buf;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 
 	for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
 		chip->ecc.hwctl(mtd, NAND_ECC_WRITE);
@@ -2309,8 +2300,10 @@ static int nand_write_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
 		chip->ecc.calculate(mtd, p, &ecc_calc[i]);
 	}
 
-	for (i = 0; i < chip->ecc.total; i++)
-		chip->oob_poi[eccpos[i]] = ecc_calc[i];
+	ret = mtd_ooblayout_set_eccbytes(mtd, ecc_calc, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	chip->write_buf(mtd, chip->oob_poi, mtd->oobsize);
 
@@ -2338,11 +2331,10 @@ static int nand_write_subpage_hwecc(struct mtd_info *mtd,
 	int ecc_size      = chip->ecc.size;
 	int ecc_bytes     = chip->ecc.bytes;
 	int ecc_steps     = chip->ecc.steps;
-	uint32_t *eccpos  = chip->ecc.layout->eccpos;
 	uint32_t start_step = offset / ecc_size;
 	uint32_t end_step   = (offset + data_len - 1) / ecc_size;
 	int oob_bytes       = mtd->oobsize / ecc_steps;
-	int step, i;
+	int step, ret;
 
 	for (step = 0; step < ecc_steps; step++) {
 		/* configure controller for WRITE access */
@@ -2370,8 +2362,10 @@ static int nand_write_subpage_hwecc(struct mtd_info *mtd,
 	/* copy calculated ECC for whole page to chip->buffer->oob */
 	/* this include masked-value(0xFF) for unwritten subpages */
 	ecc_calc = chip->buffers->ecccalc;
-	for (i = 0; i < chip->ecc.total; i++)
-		chip->oob_poi[eccpos[i]] = ecc_calc[i];
+	ret = mtd_ooblayout_set_eccbytes(mtd, ecc_calc, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	/* write OOB buffer to NAND device */
 	chip->write_buf(mtd, chip->oob_poi, mtd->oobsize);
@@ -2508,6 +2502,7 @@ static uint8_t *nand_fill_oob(struct mtd_info *mtd, uint8_t *oob, size_t len,
 			      struct mtd_oob_ops *ops)
 {
 	struct nand_chip *chip = mtd_to_nand(mtd);
+	int ret;
 
 	/*
 	 * Initialise to all 0xFF, to avoid the possibility of left over OOB
@@ -2522,31 +2517,12 @@ static uint8_t *nand_fill_oob(struct mtd_info *mtd, uint8_t *oob, size_t len,
 		memcpy(chip->oob_poi + ops->ooboffs, oob, len);
 		return oob + len;
 
-	case MTD_OPS_AUTO_OOB: {
-		struct nand_oobfree *free = chip->ecc.layout->oobfree;
-		uint32_t boffs = 0, woffs = ops->ooboffs;
-		size_t bytes = 0;
-
-		for (; free->length && len; free++, len -= bytes) {
-			/* Write request not from offset 0? */
-			if (unlikely(woffs)) {
-				if (woffs >= free->length) {
-					woffs -= free->length;
-					continue;
-				}
-				boffs = free->offset + woffs;
-				bytes = min_t(size_t, len,
-					      (free->length - woffs));
-				woffs = 0;
-			} else {
-				bytes = min_t(size_t, len, free->length);
-				boffs = free->offset;
-			}
-			memcpy(chip->oob_poi + boffs, oob, bytes);
-			oob += bytes;
-		}
-		return oob;
-	}
+	case MTD_OPS_AUTO_OOB:
+		ret = mtd_ooblayout_set_databytes(mtd, oob, chip->oob_poi,
+						  ops->ooboffs, len);
+		BUG_ON(ret);
+		return oob + len;
+
 	default:
 		BUG();
 	}
@@ -4116,7 +4092,6 @@ static bool nand_ecc_strength_good(struct mtd_info *mtd)
  */
 int nand_scan_tail(struct mtd_info *mtd)
 {
-	int i;
 	struct nand_chip *chip = mtd_to_nand(mtd);
 	struct nand_ecc_ctrl *ecc = &chip->ecc;
 	struct nand_buffers *nbuf;
@@ -4315,9 +4290,9 @@ int nand_scan_tail(struct mtd_info *mtd)
 	 * The number of bytes available for a client to place data into
 	 * the out of band area.
 	 */
-	mtd->oobavail = 0;
-	for (i = 0; ecc->layout->oobfree[i].length; i++)
-		mtd->oobavail += ecc->layout->oobfree[i].length;
+	mtd->oobavail = mtd_ooblayout_count_freebytes(mtd);
+	if (mtd->oobavail < 0)
+		mtd->oobavail = 0;
 
 	/* ECC sanity check: warn if it's too weak */
 	if (!nand_ecc_strength_good(mtd))
diff --git a/drivers/mtd/nand/nand_bch.c b/drivers/mtd/nand/nand_bch.c
index b585bae..b3039de 100644
--- a/drivers/mtd/nand/nand_bch.c
+++ b/drivers/mtd/nand/nand_bch.c
@@ -196,7 +196,8 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
 		printk(KERN_WARNING "eccsize %u is too large\n", eccsize);
 		goto fail;
 	}
-	if (layout->eccbytes != (eccsteps*eccbytes)) {
+
+	if (mtd_ooblayout_count_eccbytes(mtd) != (eccsteps*eccbytes)) {
 		printk(KERN_WARNING "invalid ecc layout\n");
 		goto fail;
 	}
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:07:06 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:07:06 +0100
Subject: [PATCH v2 43/51] mtd: nand: s3c2410: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-44-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/s3c2410.c | 32 +++++++++++++++++++++++++++-----
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
index 9c9397b..efa339b 100644
--- a/drivers/mtd/nand/s3c2410.c
+++ b/drivers/mtd/nand/s3c2410.c
@@ -84,11 +84,33 @@
 
 /* new oob placement block for use with hardware ecc generation
  */
+static int s3c2410_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oov_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 0;
+	oobregion->length = 3;
+
+	return 0;
+}
+
+static int s3c2410_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oov_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 8;
+	oobregion->length = 8;
+
+	return 0;
+}
 
-static struct nand_ecclayout nand_hw_eccoob = {
-	.eccbytes = 3,
-	.eccpos = {0, 1, 2},
-	.oobfree = {{8, 8}}
+const struct mtd_ooblayout_ops s3c2410_ooblayout_ops = {
+	.eccpos = s3c2410_eccpos,
+	.oobfree = s3c2410_oobfree,
 };
 
 /* controller and mtd information */
@@ -919,7 +941,7 @@ static void s3c2410_nand_update_chip(struct s3c2410_nand_info *info,
 	} else {
 		chip->ecc.size	    = 512;
 		chip->ecc.bytes	    = 3;
-		chip->ecc.layout    = &nand_hw_eccoob;
+		mtd_set_ooblayout(nand_to_mtd(chip), &s3c2410_ooblayout_ops);
 	}
 }
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:07:09 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:07:09 +0100
Subject: [PATCH v2 46/51] mtd: nand: sunxi: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-47-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand.c | 114 +++++++++++++++++++-----------------------
 1 file changed, 52 insertions(+), 62 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index b5ea6b3..a32a894 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -212,12 +212,9 @@ struct sunxi_nand_chip_sel {
  * sunxi HW ECC infos: stores information related to HW ECC support
  *
  * @mode:	the sunxi ECC mode field deduced from ECC requirements
- * @layout:	the OOB layout depending on the ECC requirements and the
- *		selected ECC mode
  */
 struct sunxi_nand_hw_ecc {
 	int mode;
-	struct nand_ecclayout layout;
 };
 
 /*
@@ -1257,6 +1254,57 @@ static int sunxi_nand_chip_init_timings(struct sunxi_nand_chip *chip,
 	return sunxi_nand_chip_set_timings(chip, timings);
 }
 
+static int sunxi_nand_ooblayout_ecc(struct mtd_info *mtd, int section,
+				    struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand = mtd_to_nand(mtd);
+	struct nand_ecc_ctrl *ecc = &nand->ecc;
+
+	if (section >= ecc->steps)
+		return -ERANGE;
+
+	oobregion->offset = section * (ecc->bytes + 4) + 4;
+	oobregion->length = ecc->bytes;
+
+	return 0;
+}
+
+static int sunxi_nand_ooblayout_free(struct mtd_info *mtd, int section,
+				     struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand = mtd_to_nand(mtd);
+	struct nand_ecc_ctrl *ecc = &nand->ecc;
+
+	if (section > ecc->steps)
+		return -ERANGE;
+
+	/*
+	 * The first 2 bytes are used for BB markers, hence we
+	 * only have 2 bytes available in the first user data
+	 * section.
+	 */
+	if (!section && ecc->mode == NAND_ECC_HW) {
+		oobregion->offset = 2;
+		oobregion->length = 2;
+
+		return 0;
+	}
+
+	oobregion->offset = section * (ecc->bytes + 4);
+
+	if (section < ecc->steps)
+		oobregion->length = 4;
+	else
+		oobregion->offset = mtd->oobsize - oobregion->offset;
+
+	return 0;
+}
+
+const struct mtd_ooblayout_ops sunxi_nand_ooblayout_ops = {
+	.ecc = sunxi_nand_ooblayout_ecc,
+	.free = sunxi_nand_ooblayout_free,
+};
+
 static int sunxi_nand_hw_common_ecc_ctrl_init(struct mtd_info *mtd,
 					      struct nand_ecc_ctrl *ecc,
 					      struct device_node *np)
@@ -1266,7 +1314,6 @@ static int sunxi_nand_hw_common_ecc_ctrl_init(struct mtd_info *mtd,
 	struct sunxi_nand_chip *sunxi_nand = to_sunxi_nand(nand);
 	struct sunxi_nfc *nfc = to_sunxi_nfc(sunxi_nand->nand.controller);
 	struct sunxi_nand_hw_ecc *data;
-	struct nand_ecclayout *layout;
 	int nsectors;
 	int ret;
 	int i;
@@ -1295,7 +1342,6 @@ static int sunxi_nand_hw_common_ecc_ctrl_init(struct mtd_info *mtd,
 	/* HW ECC always work with even numbers of ECC bytes */
 	ecc->bytes = ALIGN(ecc->bytes, 2);
 
-	layout = &data->layout;
 	nsectors = mtd->writesize / ecc->size;
 
 	if (mtd->oobsize < ((ecc->bytes + 4) * nsectors)) {
@@ -1303,9 +1349,7 @@ static int sunxi_nand_hw_common_ecc_ctrl_init(struct mtd_info *mtd,
 		goto err;
 	}
 
-	layout->eccbytes = (ecc->bytes * nsectors);
-
-	ecc->layout = layout;
+	mtd_set_ooblayout(mtd, &sunxi_nand_ooblayout_ops);
 	ecc->priv = data;
 
 	return 0;
@@ -1325,9 +1369,6 @@ static int sunxi_nand_hw_ecc_ctrl_init(struct mtd_info *mtd,
 				       struct nand_ecc_ctrl *ecc,
 				       struct device_node *np)
 {
-	struct nand_ecclayout *layout;
-	int nsectors;
-	int i, j;
 	int ret;
 
 	ret = sunxi_nand_hw_common_ecc_ctrl_init(mtd, ecc, np);
@@ -1336,40 +1377,6 @@ static int sunxi_nand_hw_ecc_ctrl_init(struct mtd_info *mtd,
 
 	ecc->read_page = sunxi_nfc_hw_ecc_read_page;
 	ecc->write_page = sunxi_nfc_hw_ecc_write_page;
-	layout = ecc->layout;
-	nsectors = mtd->writesize / ecc->size;
-
-	for (i = 0; i < nsectors; i++) {
-		if (i) {
-			layout->oobfree[i].offset =
-				layout->oobfree[i - 1].offset +
-				layout->oobfree[i - 1].length +
-				ecc->bytes;
-			layout->oobfree[i].length = 4;
-		} else {
-			/*
-			 * The first 2 bytes are used for BB markers, hence we
-			 * only have 2 bytes available in the first user data
-			 * section.
-			 */
-			layout->oobfree[i].length = 2;
-			layout->oobfree[i].offset = 2;
-		}
-
-		for (j = 0; j < ecc->bytes; j++)
-			layout->eccpos[(ecc->bytes * i) + j] =
-					layout->oobfree[i].offset +
-					layout->oobfree[i].length + j;
-	}
-
-	if (mtd->oobsize > (ecc->bytes + 4) * nsectors) {
-		layout->oobfree[nsectors].offset =
-				layout->oobfree[nsectors - 1].offset +
-				layout->oobfree[nsectors - 1].length +
-				ecc->bytes;
-		layout->oobfree[nsectors].length = mtd->oobsize -
-				((ecc->bytes + 4) * nsectors);
-	}
 
 	return 0;
 }
@@ -1378,9 +1385,6 @@ static int sunxi_nand_hw_syndrome_ecc_ctrl_init(struct mtd_info *mtd,
 						struct nand_ecc_ctrl *ecc,
 						struct device_node *np)
 {
-	struct nand_ecclayout *layout;
-	int nsectors;
-	int i;
 	int ret;
 
 	ret = sunxi_nand_hw_common_ecc_ctrl_init(mtd, ecc, np);
@@ -1391,15 +1395,6 @@ static int sunxi_nand_hw_syndrome_ecc_ctrl_init(struct mtd_info *mtd,
 	ecc->read_page = sunxi_nfc_hw_syndrome_ecc_read_page;
 	ecc->write_page = sunxi_nfc_hw_syndrome_ecc_write_page;
 
-	layout = ecc->layout;
-	nsectors = mtd->writesize / ecc->size;
-
-	for (i = 0; i < (ecc->bytes * nsectors); i++)
-		layout->eccpos[i] = i;
-
-	layout->oobfree[0].length = mtd->oobsize - i;
-	layout->oobfree[0].offset = i;
-
 	return 0;
 }
 
@@ -1411,7 +1406,6 @@ static void sunxi_nand_ecc_cleanup(struct nand_ecc_ctrl *ecc)
 		sunxi_nand_hw_common_ecc_ctrl_cleanup(ecc);
 		break;
 	case NAND_ECC_NONE:
-		kfree(ecc->layout);
 	default:
 		break;
 	}
@@ -1445,10 +1439,6 @@ static int sunxi_nand_ecc_init(struct mtd_info *mtd, struct nand_ecc_ctrl *ecc,
 			return ret;
 		break;
 	case NAND_ECC_NONE:
-		ecc->layout = kzalloc(sizeof(*ecc->layout), GFP_KERNEL);
-		if (!ecc->layout)
-			return -ENOMEM;
-		ecc->layout->oobfree[0].length = mtd->oobsize;
 	case NAND_ECC_SOFT:
 		break;
 	default:
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:07:11 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:07:11 +0100
Subject: [PATCH v2 48/51] mtd: onenand: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-49-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users. Modify the onenand drivers to switch to this
approach.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/onenand/onenand_base.c | 154 ++++++++++++++++++++++---------------
 include/linux/mtd/onenand.h        |   2 -
 2 files changed, 92 insertions(+), 64 deletions(-)

diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index 1d8406d..a41cb4c 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -68,21 +68,33 @@ MODULE_PARM_DESC(otp,	"Corresponding behaviour of OneNAND in OTP"
  * flexonenand_oob_128 - oob info for Flex-Onenand with 4KB page
  * For now, we expose only 64 out of 80 ecc bytes
  */
-static struct nand_ecclayout flexonenand_oob_128 = {
-	.eccbytes	= 64,
-	.eccpos		= {
-		6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
-		22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
-		38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
-		54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
-		70, 71, 72, 73, 74, 75, 76, 77, 78, 79,
-		86, 87, 88, 89, 90, 91, 92, 93, 94, 95,
-		102, 103, 104, 105
-		},
-	.oobfree	= {
-		{2, 4}, {18, 4}, {34, 4}, {50, 4},
-		{66, 4}, {82, 4}, {98, 4}, {114, 4}
-	}
+static int flexonenand_ooblayout_ecc(struct mtd_info *mtd, int section,
+				     struct mtd_oob_region *oobregion)
+{
+	if (section > 7)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 6;
+	oobregion->length = 10;
+
+	return 0;
+}
+
+static int flexonenand_ooblayout_free(struct mtd_info *mtd, int section,
+				      struct mtd_oob_region *oobregion)
+{
+	if (section > 7)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 2;
+	oobregion->length = 4;
+
+	return 0;
+}
+
+const struct mtd_ooblayout_ops flexonenand_ooblayout_ops = {
+	.ecc = flexonenand_ooblayout_ecc,
+	.free = flexonenand_ooblayout_free,
 };
 
 /*
@@ -91,56 +103,75 @@ static struct nand_ecclayout flexonenand_oob_128 = {
  * Based on specification:
  * 4Gb M-die OneNAND Flash (KFM4G16Q4M, KFN8G16Q4M). Rev. 1.3, Apr. 2010
  *
- * For eccpos we expose only 64 bytes out of 72 (see struct nand_ecclayout)
- *
  * oobfree uses the spare area fields marked as
  * "Managed by internal ECC logic for Logical Sector Number area"
  */
-static struct nand_ecclayout onenand_oob_128 = {
-	.eccbytes	= 64,
-	.eccpos		= {
-		7, 8, 9, 10, 11, 12, 13, 14, 15,
-		23, 24, 25, 26, 27, 28, 29, 30, 31,
-		39, 40, 41, 42, 43, 44, 45, 46, 47,
-		55, 56, 57, 58, 59, 60, 61, 62, 63,
-		71, 72, 73, 74, 75, 76, 77, 78, 79,
-		87, 88, 89, 90, 91, 92, 93, 94, 95,
-		103, 104, 105, 106, 107, 108, 109, 110, 111,
-		119
-	},
-	.oobfree	= {
-		{2, 3}, {18, 3}, {34, 3}, {50, 3},
-		{66, 3}, {82, 3}, {98, 3}, {114, 3}
-	}
+static int onenand_ooblayout_128_ecc(struct mtd_info *mtd, int section,
+				     struct mtd_oob_region *oobregion)
+{
+	if (section > 7)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 7;
+	oobregion->length = 9;
+
+	return 0;
+}
+
+static int onenand_ooblayout_128_free(struct mtd_info *mtd, int section,
+				      struct mtd_oob_region *oobregion)
+{
+	if (section >= 8)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 2;
+	oobregion->length = 3;
+
+	return 0;
+}
+
+const struct mtd_ooblayout_ops onenand_oob_128_ooblayout_ops = {
+	.ecc = onenand_ooblayout_128_ecc,
+	.free = onenand_ooblayout_128_free,
 };
 
 /**
- * onenand_oob_64 - oob info for large (2KB) page
+ * onenand_oob_32_64 - oob info for large (2KB) page
  */
-static struct nand_ecclayout onenand_oob_64 = {
-	.eccbytes	= 20,
-	.eccpos		= {
-		8, 9, 10, 11, 12,
-		24, 25, 26, 27, 28,
-		40, 41, 42, 43, 44,
-		56, 57, 58, 59, 60,
-		},
-	.oobfree	= {
-		{2, 3}, {14, 2}, {18, 3}, {30, 2},
-		{34, 3}, {46, 2}, {50, 3}, {62, 2}
+static int onenand_ooblayout_32_64_ecc(struct mtd_info *mtd, int section,
+				       struct mtd_oob_region *oobregion)
+{
+	if (section > 3)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 8;
+	oobregion->length = 5;
+
+	return 0;
+}
+
+static int onenand_ooblayout_32_64_free(struct mtd_info *mtd, int section,
+					struct mtd_oob_region *oobregion)
+{
+	int sections = (mtd->oobsize / 32) * 2;
+
+	if (section >= sections)
+		return -ERANGE;
+
+	if (section & 1) {
+		oobregion->offset = ((section - 1) * 16) + 14;
+		oobregion->length = 2;
+	} else  {
+		oobregion->offset = (section * 16) + 2;
+		oobregion->length = 3;
 	}
-};
 
-/**
- * onenand_oob_32 - oob info for middle (1KB) page
- */
-static struct nand_ecclayout onenand_oob_32 = {
-	.eccbytes	= 10,
-	.eccpos		= {
-		8, 9, 10, 11, 12,
-		24, 25, 26, 27, 28,
-		},
-	.oobfree	= { {2, 3}, {14, 2}, {18, 3}, {30, 2} }
+	return 0;
+}
+
+const struct mtd_ooblayout_ops onenand_oob_32_64_ooblayout_ops = {
+	.ecc = onenand_ooblayout_32_64_ecc,
+	.free = onenand_ooblayout_32_64_free,
 };
 
 static const unsigned char ffchars[] = {
@@ -3956,22 +3987,22 @@ int onenand_scan(struct mtd_info *mtd, int maxchips)
 	switch (mtd->oobsize) {
 	case 128:
 		if (FLEXONENAND(this)) {
-			this->ecclayout = &flexonenand_oob_128;
+			mtd_set_ooblayout(mtd, &flexonenand_ooblayout_ops);
 			mtd->subpage_sft = 0;
 		} else {
-			this->ecclayout = &onenand_oob_128;
+			mtd_set_ooblayout(mtd, &onenand_oob_128_ooblayout_ops);
 			mtd->subpage_sft = 2;
 		}
 		if (ONENAND_IS_NOP_1(this))
 			mtd->subpage_sft = 0;
 		break;
 	case 64:
-		this->ecclayout = &onenand_oob_64;
+		mtd_set_ooblayout(mtd, &onenand_oob_32_64_ooblayout_ops);
 		mtd->subpage_sft = 2;
 		break;
 
 	case 32:
-		this->ecclayout = &onenand_oob_32;
+		mtd_set_ooblayout(mtd, &onenand_oob_32_64_ooblayout_ops);
 		mtd->subpage_sft = 1;
 		break;
 
@@ -3980,7 +4011,7 @@ int onenand_scan(struct mtd_info *mtd, int maxchips)
 			__func__, mtd->oobsize);
 		mtd->subpage_sft = 0;
 		/* To prevent kernel oops */
-		this->ecclayout = &onenand_oob_32;
+		mtd_set_ooblayout(mtd, &onenand_oob_32_64_ooblayout_ops);
 		break;
 	}
 
@@ -3994,7 +4025,6 @@ int onenand_scan(struct mtd_info *mtd, int maxchips)
 	if (mtd->oobavail < 0)
 		mtd->oobavail = 0;
 
-	mtd_set_ecclayout(mtd, this->ecclayout);
 	mtd->ecc_strength = 1;
 
 	/* Fill in remaining MTD driver data */
diff --git a/include/linux/mtd/onenand.h b/include/linux/mtd/onenand.h
index 4596503..0aaa98b 100644
--- a/include/linux/mtd/onenand.h
+++ b/include/linux/mtd/onenand.h
@@ -80,7 +80,6 @@ struct onenand_bufferram {
  * @page_buf:		[INTERN] page main data buffer
  * @oob_buf:		[INTERN] page oob data buffer
  * @subpagesize:	[INTERN] holds the subpagesize
- * @ecclayout:		[REPLACEABLE] the default ecc placement scheme
  * @bbm:		[REPLACEABLE] pointer to Bad Block Management
  * @priv:		[OPTIONAL] pointer to private chip date
  */
@@ -134,7 +133,6 @@ struct onenand_chip {
 #endif
 
 	int			subpagesize;
-	struct nand_ecclayout	*ecclayout;
 
 	void			*bbm;
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:07:14 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:07:14 +0100
Subject: [PATCH v2 51/51] mtd: kill the nand_ecclayout struct
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-52-git-send-email-boris.brezillon@free-electrons.com>

Now that all MTD drivers have moved to the mtd_ooblayout_ops model we can
safely remove the struct nand_ecclayout definition, and all the remaining
places where it was still used.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/mtdchar.c      |  12 ++---
 drivers/mtd/mtdcore.c      | 120 ---------------------------------------------
 include/linux/mtd/mtd.h    |  20 --------
 include/uapi/mtd/mtd-abi.h |   2 +-
 4 files changed, 7 insertions(+), 147 deletions(-)

diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index 3fad2c7..2a47a3f 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -465,12 +465,12 @@ static int mtdchar_readoob(struct file *file, struct mtd_info *mtd,
 }
 
 /*
- * Copies (and truncates, if necessary) data from the larger struct,
- * nand_ecclayout, to the smaller, deprecated layout struct,
- * nand_ecclayout_user. This is necessary only to support the deprecated
- * API ioctl ECCGETLAYOUT while allowing all new functionality to use
- * nand_ecclayout flexibly (i.e. the struct may change size in new
- * releases without requiring major rewrites).
+ * Copies (and truncates, if necessary) OOB layout information to the
+ * deprecated layout struct, nand_ecclayout_user. This is necessary only to
+ * support the deprecated API ioctl ECCGETLAYOUT while allowing all new
+ * functionality to use mtd_ooblayout_ops flexibly (i.e. mtd_ooblayout_ops
+ * can describe any kind of OOB layout with almost zero overhead from a
+ * memory usage point of view).
  */
 static int shrink_ecclayout(struct mtd_info *mtd,
 			    struct nand_ecclayout_user *to)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index dccd132..9c520a9 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1355,126 +1355,6 @@ int mtd_ooblayout_count_eccbytes(struct mtd_info *mtd)
 }
 EXPORT_SYMBOL_GPL(mtd_ooblayout_count_eccbytes);
 
-/**
- * mtd_ecclayout_ecc - Default ooblayout_ecc iterator implementation
- * @mtd: MTD device structure
- * @section: ECC section. Depending on the layout you may have all the ECC
- *	     bytes stored in a single contiguous section, or one section
- *	     per ECC chunk (and sometime several sections for a single ECC
- *	     ECC chunk)
- * @oobecc: OOB region struct filled with the appropriate ECC position
- *	    information
- *
- * This function is just a wrapper around the mtd->ecclayout field and is
- * here to ease the transition to the mtd_ooblayout_ops approach.
- * All it does is convert the layout->eccpos information into proper oob
- * region definitions.
- *
- * Returns zero on success, a negative error code otherwise.
- */
-static int mtd_ecclayout_ecc(struct mtd_info *mtd, int section,
-			     struct mtd_oob_region *oobecc)
-{
-	int eccbyte = 0, cursection = 0, length = 0, eccpos = 0;
-
-	if (!mtd->ecclayout)
-		return -ENOTSUPP;
-
-	if (mtd->ecclayout->eccbytes < 1)
-		return -ERANGE;
-
-	/*
-	 * This logic allows us to reuse the ->ecclayout information and
-	 * expose them as ECC regions (as done for the OOB free regions).
-	 *
-	 * TODO: this should be dropped as soon as we get rid of the
-	 * ->ecclayout field.
-	 */
-	for (eccbyte = 0; eccbyte < mtd->ecclayout->eccbytes; eccbyte++) {
-		eccpos = mtd->ecclayout->eccpos[eccbyte];
-
-		if (eccbyte < mtd->ecclayout->eccbytes - 1) {
-			int neccpos = mtd->ecclayout->eccpos[eccbyte + 1];
-
-			if (eccpos + 1 == neccpos) {
-				length++;
-				continue;
-			}
-		}
-
-		if (section == cursection)
-			break;
-
-		length = 0;
-		cursection++;
-	}
-
-	if (cursection != section)
-		return -ERANGE;
-
-	oobecc->length = length + 1;
-	oobecc->offset = eccpos - length;
-
-	return 0;
-}
-
-/**
- * mtd_ecclayout_ecc - Default ooblayout_free iterator implementation
- * @mtd: MTD device structure
- * @section: Free section. Depending on the layout you may have all the free
- *	     bytes stored in a single contiguous section, or one section
- *	     per ECC chunk (and sometime several sections for a single ECC
- *	     ECC chunk)
- * @oobfree: OOB region struct filled with the appropriate free position
- *	     information
- *
- * This function is just a wrapper around the mtd->ecclayout field and is
- * here to ease the transition to the mtd_ooblayout_ops approach.
- * All it does is convert the layout->oobfree information into proper oob
- * region definitions.
- *
- * Returns zero on success, a negative error code otherwise.
- */
-static int mtd_ecclayout_free(struct mtd_info *mtd, int section,
-			      struct mtd_oob_region *oobfree)
-{
-	struct nand_ecclayout *layout = mtd->ecclayout;
-
-	if (!layout)
-		return -ENOTSUPP;
-
-	if (section >= MTD_MAX_OOBFREE_ENTRIES_LARGE ||
-	    !layout->oobfree[section].length)
-		return -ERANGE;
-
-	oobfree->offset = layout->oobfree[section].offset;
-	oobfree->length = layout->oobfree[section].length;
-
-	return 0;
-}
-
-static const struct mtd_ooblayout_ops mtd_ecclayout_wrapper_ops = {
-	.ecc = mtd_ecclayout_ecc,
-	.free = mtd_ecclayout_free,
-};
-
-/**
- * mtd_set_ecclayout - Attach an ecclayout to an MTD device
- * @mtd: MTD device structure
- * @ecclayout: The ecclayout to attach to the device
- *
- * Returns zero on success, a negative error code otherwise.
- */
-void mtd_set_ecclayout(struct mtd_info *mtd, struct nand_ecclayout *ecclayout)
-{
-	if (!mtd || !ecclayout)
-		return;
-
-	mtd->ecclayout = ecclayout;
-	mtd_set_ooblayout(mtd, &mtd_ecclayout_wrapper_ops);
-}
-EXPORT_SYMBOL_GPL(mtd_set_ecclayout);
-
 /*
  * Method to access the protection register area, present in some flash
  * devices. The user data is one time programmable but the factory data is read
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index a38fe9a..df8c116 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -96,21 +96,6 @@ struct mtd_oob_ops {
 
 #define MTD_MAX_OOBFREE_ENTRIES_LARGE	32
 #define MTD_MAX_ECCPOS_ENTRIES_LARGE	640
-/*
- * Internal ECC layout control structure. For historical reasons, there is a
- * similar, smaller struct nand_ecclayout_user (in mtd-abi.h) that is retained
- * for export to user-space via the ECCGETLAYOUT ioctl.
- * nand_ecclayout should be expandable in the future simply by the above macros.
- *
- * This structure is now deprecated, you should use struct nand_ecclayout_ops
- * to describe your OOB layout.
- */
-struct nand_ecclayout {
-	__u32 eccbytes;
-	__u32 eccpos[MTD_MAX_ECCPOS_ENTRIES_LARGE];
-	struct nand_oobfree oobfree[MTD_MAX_OOBFREE_ENTRIES_LARGE];
-};
-
 /**
  * struct mtd_oob_region - oob region definition
  * @offset: region offset
@@ -200,9 +185,6 @@ struct mtd_info {
 	const char *name;
 	int index;
 
-	/* [Deprecated] ECC layout structure pointer - read only! */
-	struct nand_ecclayout *ecclayout;
-
 	/* OOB layout description */
 	const struct mtd_ooblayout_ops *ooblayout;
 
@@ -308,8 +290,6 @@ int mtd_ooblayout_set_databytes(struct mtd_info *mtd, const u8 *databuf,
 int mtd_ooblayout_count_freebytes(struct mtd_info *mtd);
 int mtd_ooblayout_count_eccbytes(struct mtd_info *mtd);
 
-void mtd_set_ecclayout(struct mtd_info *mtd, struct nand_ecclayout *ecclayout);
-
 static inline void mtd_set_ooblayout(struct mtd_info *mtd,
 				     const struct mtd_ooblayout_ops *ooblayout)
 {
diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
index 763bb69..0ec1da2 100644
--- a/include/uapi/mtd/mtd-abi.h
+++ b/include/uapi/mtd/mtd-abi.h
@@ -228,7 +228,7 @@ struct nand_oobfree {
  * complete set of ECC information. The ioctl truncates the larger internal
  * structure to retain binary compatibility with the static declaration of the
  * ioctl. Note that the "MTD_MAX_..._ENTRIES" macros represent the max size of
- * the user struct, not the MAX size of the internal struct nand_ecclayout.
+ * the user struct, not the MAX size of the internal OOB layout representation.
  */
 struct nand_ecclayout_user {
 	__u32 eccbytes;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:40 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:40 +0100
Subject: [PATCH v2 17/51] mtd: onenand: use mtd_set_ecclayout() where
 appropriate
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-18-git-send-email-boris.brezillon@free-electrons.com>

Use the mtd_set_ecclayout() helper instead of directly assigning the
mtd->ecclayout field.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/onenand/onenand_base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index 6906c95..1d8406d 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -3994,7 +3994,7 @@ int onenand_scan(struct mtd_info *mtd, int maxchips)
 	if (mtd->oobavail < 0)
 		mtd->oobavail = 0;
 
-	mtd->ecclayout = this->ecclayout;
+	mtd_set_ecclayout(mtd, this->ecclayout);
 	mtd->ecc_strength = 1;
 
 	/* Fill in remaining MTD driver data */
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:58 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:58 +0100
Subject: [PATCH v2 35/51] mtd: nand: fsmc: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-36-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/fsmc_nand.c | 300 ++++++++++++-------------------------------
 1 file changed, 84 insertions(+), 216 deletions(-)

diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
index 1bdcd4f..d989acf 100644
--- a/drivers/mtd/nand/fsmc_nand.c
+++ b/drivers/mtd/nand/fsmc_nand.c
@@ -39,212 +39,6 @@
 #include <linux/amba/bus.h>
 #include <mtd/mtd-abi.h>
 
-static struct nand_ecclayout fsmc_ecc1_128_layout = {
-	.eccbytes = 24,
-	.eccpos = {2, 3, 4, 18, 19, 20, 34, 35, 36, 50, 51, 52,
-		66, 67, 68, 82, 83, 84, 98, 99, 100, 114, 115, 116},
-	.oobfree = {
-		{.offset = 8, .length = 8},
-		{.offset = 24, .length = 8},
-		{.offset = 40, .length = 8},
-		{.offset = 56, .length = 8},
-		{.offset = 72, .length = 8},
-		{.offset = 88, .length = 8},
-		{.offset = 104, .length = 8},
-		{.offset = 120, .length = 8}
-	}
-};
-
-static struct nand_ecclayout fsmc_ecc1_64_layout = {
-	.eccbytes = 12,
-	.eccpos = {2, 3, 4, 18, 19, 20, 34, 35, 36, 50, 51, 52},
-	.oobfree = {
-		{.offset = 8, .length = 8},
-		{.offset = 24, .length = 8},
-		{.offset = 40, .length = 8},
-		{.offset = 56, .length = 8},
-	}
-};
-
-static struct nand_ecclayout fsmc_ecc1_16_layout = {
-	.eccbytes = 3,
-	.eccpos = {2, 3, 4},
-	.oobfree = {
-		{.offset = 8, .length = 8},
-	}
-};
-
-/*
- * ECC4 layout for NAND of pagesize 8192 bytes & OOBsize 256 bytes. 13*16 bytes
- * of OB size is reserved for ECC, Byte no. 0 & 1 reserved for bad block and 46
- * bytes are free for use.
- */
-static struct nand_ecclayout fsmc_ecc4_256_layout = {
-	.eccbytes = 208,
-	.eccpos = {  2,   3,   4,   5,   6,   7,   8,
-		9,  10,  11,  12,  13,  14,
-		18,  19,  20,  21,  22,  23,  24,
-		25,  26,  27,  28,  29,  30,
-		34,  35,  36,  37,  38,  39,  40,
-		41,  42,  43,  44,  45,  46,
-		50,  51,  52,  53,  54,  55,  56,
-		57,  58,  59,  60,  61,  62,
-		66,  67,  68,  69,  70,  71,  72,
-		73,  74,  75,  76,  77,  78,
-		82,  83,  84,  85,  86,  87,  88,
-		89,  90,  91,  92,  93,  94,
-		98,  99, 100, 101, 102, 103, 104,
-		105, 106, 107, 108, 109, 110,
-		114, 115, 116, 117, 118, 119, 120,
-		121, 122, 123, 124, 125, 126,
-		130, 131, 132, 133, 134, 135, 136,
-		137, 138, 139, 140, 141, 142,
-		146, 147, 148, 149, 150, 151, 152,
-		153, 154, 155, 156, 157, 158,
-		162, 163, 164, 165, 166, 167, 168,
-		169, 170, 171, 172, 173, 174,
-		178, 179, 180, 181, 182, 183, 184,
-		185, 186, 187, 188, 189, 190,
-		194, 195, 196, 197, 198, 199, 200,
-		201, 202, 203, 204, 205, 206,
-		210, 211, 212, 213, 214, 215, 216,
-		217, 218, 219, 220, 221, 222,
-		226, 227, 228, 229, 230, 231, 232,
-		233, 234, 235, 236, 237, 238,
-		242, 243, 244, 245, 246, 247, 248,
-		249, 250, 251, 252, 253, 254
-	},
-	.oobfree = {
-		{.offset = 15, .length = 3},
-		{.offset = 31, .length = 3},
-		{.offset = 47, .length = 3},
-		{.offset = 63, .length = 3},
-		{.offset = 79, .length = 3},
-		{.offset = 95, .length = 3},
-		{.offset = 111, .length = 3},
-		{.offset = 127, .length = 3},
-		{.offset = 143, .length = 3},
-		{.offset = 159, .length = 3},
-		{.offset = 175, .length = 3},
-		{.offset = 191, .length = 3},
-		{.offset = 207, .length = 3},
-		{.offset = 223, .length = 3},
-		{.offset = 239, .length = 3},
-		{.offset = 255, .length = 1}
-	}
-};
-
-/*
- * ECC4 layout for NAND of pagesize 4096 bytes & OOBsize 224 bytes. 13*8 bytes
- * of OOB size is reserved for ECC, Byte no. 0 & 1 reserved for bad block & 118
- * bytes are free for use.
- */
-static struct nand_ecclayout fsmc_ecc4_224_layout = {
-	.eccbytes = 104,
-	.eccpos = {  2,   3,   4,   5,   6,   7,   8,
-		9,  10,  11,  12,  13,  14,
-		18,  19,  20,  21,  22,  23,  24,
-		25,  26,  27,  28,  29,  30,
-		34,  35,  36,  37,  38,  39,  40,
-		41,  42,  43,  44,  45,  46,
-		50,  51,  52,  53,  54,  55,  56,
-		57,  58,  59,  60,  61,  62,
-		66,  67,  68,  69,  70,  71,  72,
-		73,  74,  75,  76,  77,  78,
-		82,  83,  84,  85,  86,  87,  88,
-		89,  90,  91,  92,  93,  94,
-		98,  99, 100, 101, 102, 103, 104,
-		105, 106, 107, 108, 109, 110,
-		114, 115, 116, 117, 118, 119, 120,
-		121, 122, 123, 124, 125, 126
-	},
-	.oobfree = {
-		{.offset = 15, .length = 3},
-		{.offset = 31, .length = 3},
-		{.offset = 47, .length = 3},
-		{.offset = 63, .length = 3},
-		{.offset = 79, .length = 3},
-		{.offset = 95, .length = 3},
-		{.offset = 111, .length = 3},
-		{.offset = 127, .length = 97}
-	}
-};
-
-/*
- * ECC4 layout for NAND of pagesize 4096 bytes & OOBsize 128 bytes. 13*8 bytes
- * of OOB size is reserved for ECC, Byte no. 0 & 1 reserved for bad block & 22
- * bytes are free for use.
- */
-static struct nand_ecclayout fsmc_ecc4_128_layout = {
-	.eccbytes = 104,
-	.eccpos = {  2,   3,   4,   5,   6,   7,   8,
-		9,  10,  11,  12,  13,  14,
-		18,  19,  20,  21,  22,  23,  24,
-		25,  26,  27,  28,  29,  30,
-		34,  35,  36,  37,  38,  39,  40,
-		41,  42,  43,  44,  45,  46,
-		50,  51,  52,  53,  54,  55,  56,
-		57,  58,  59,  60,  61,  62,
-		66,  67,  68,  69,  70,  71,  72,
-		73,  74,  75,  76,  77,  78,
-		82,  83,  84,  85,  86,  87,  88,
-		89,  90,  91,  92,  93,  94,
-		98,  99, 100, 101, 102, 103, 104,
-		105, 106, 107, 108, 109, 110,
-		114, 115, 116, 117, 118, 119, 120,
-		121, 122, 123, 124, 125, 126
-	},
-	.oobfree = {
-		{.offset = 15, .length = 3},
-		{.offset = 31, .length = 3},
-		{.offset = 47, .length = 3},
-		{.offset = 63, .length = 3},
-		{.offset = 79, .length = 3},
-		{.offset = 95, .length = 3},
-		{.offset = 111, .length = 3},
-		{.offset = 127, .length = 1}
-	}
-};
-
-/*
- * ECC4 layout for NAND of pagesize 2048 bytes & OOBsize 64 bytes. 13*4 bytes of
- * OOB size is reserved for ECC, Byte no. 0 & 1 reserved for bad block and 10
- * bytes are free for use.
- */
-static struct nand_ecclayout fsmc_ecc4_64_layout = {
-	.eccbytes = 52,
-	.eccpos = {  2,   3,   4,   5,   6,   7,   8,
-		9,  10,  11,  12,  13,  14,
-		18,  19,  20,  21,  22,  23,  24,
-		25,  26,  27,  28,  29,  30,
-		34,  35,  36,  37,  38,  39,  40,
-		41,  42,  43,  44,  45,  46,
-		50,  51,  52,  53,  54,  55,  56,
-		57,  58,  59,  60,  61,  62,
-	},
-	.oobfree = {
-		{.offset = 15, .length = 3},
-		{.offset = 31, .length = 3},
-		{.offset = 47, .length = 3},
-		{.offset = 63, .length = 1},
-	}
-};
-
-/*
- * ECC4 layout for NAND of pagesize 512 bytes & OOBsize 16 bytes. 13 bytes of
- * OOB size is reserved for ECC, Byte no. 4 & 5 reserved for bad block and One
- * byte is free for use.
- */
-static struct nand_ecclayout fsmc_ecc4_16_layout = {
-	.eccbytes = 13,
-	.eccpos = { 0,  1,  2,  3,  6,  7, 8,
-		9, 10, 11, 12, 13, 14
-	},
-	.oobfree = {
-		{.offset = 15, .length = 1},
-	}
-};
-
 /*
  * ECC placement definitions in oobfree type format.
  * There are 13 bytes of ecc for every 512 byte block and it has to be read
@@ -274,6 +68,86 @@ static struct fsmc_eccplace fsmc_ecc4_sp_place = {
 	}
 };
 
+static int fsmc_ecc1_ooblayout_ecc(struct mtd_info *mtd, int section,
+				   struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int eccbytes = chip->ecc.bytes * chip->ecc.steps;
+
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 2;
+	oobregion->length = 3;
+
+	return 0;
+}
+
+static int fsmc_ecc1_ooblayout_free(struct mtd_info *mtd, int section,
+				    struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
+
+	oobfree->offset = (section * 16) + 8;
+
+	if (section < chip->ecc.steps - 1)
+		oobfree->length = 8;
+	else
+		oobfree->length = mtd->oobsize - oobfree->offset;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops fsmc_ecc1_ooblayout_ops = {
+	.ecc = fsmc_ecc1_ooblayout_ecc,
+	.free = fsmc_ecc1_ooblayout_free,
+};
+
+static int fsmc_ecc4_ooblayout_ecc(struct mtd_info *mtd, int section,
+				   struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int eccbytes = chip->ecc.bytes * chip->ecc.steps;
+
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
+
+	oobfree->length = chip->ecc.bytes;
+
+	if (!section && mtd->writesize <= 512)
+		oobfree->offset = 0;
+	else
+		oobfree->offset = (section * 16) + 2;
+
+	return 0;
+}
+
+static int fsmc_ecc4_ooblayout_free(struct mtd_info *mtd, int section,
+				    struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
+
+	oobfree->offset = (section * 16) + 15;
+
+	if (section < chip->ecc.steps - 1)
+		oobfree->length = 3;
+	else
+		oobfree->length = mtd->oobsize - oobfree->offset;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops fsmc_ecc4_ooblayout_ops = {
+	.ecc = fsmc_ecc4_ooblayout_ecc,
+	.free = fsmc_ecc4_ooblayout_free,
+};
+
 /**
  * struct fsmc_nand_data - structure for FSMC NAND device state
  *
@@ -1084,23 +958,18 @@ static int __init fsmc_nand_probe(struct platform_device *pdev)
 	if (AMBA_REV_BITS(host->pid) >= 8) {
 		switch (mtd->oobsize) {
 		case 16:
-			nand->ecc.layout = &fsmc_ecc4_16_layout;
 			host->ecc_place = &fsmc_ecc4_sp_place;
 			break;
 		case 64:
-			nand->ecc.layout = &fsmc_ecc4_64_layout;
 			host->ecc_place = &fsmc_ecc4_lp_place;
 			break;
 		case 128:
-			nand->ecc.layout = &fsmc_ecc4_128_layout;
 			host->ecc_place = &fsmc_ecc4_lp_place;
 			break;
 		case 224:
-			nand->ecc.layout = &fsmc_ecc4_224_layout;
 			host->ecc_place = &fsmc_ecc4_lp_place;
 			break;
 		case 256:
-			nand->ecc.layout = &fsmc_ecc4_256_layout;
 			host->ecc_place = &fsmc_ecc4_lp_place;
 			break;
 		default:
@@ -1109,6 +978,8 @@ static int __init fsmc_nand_probe(struct platform_device *pdev)
 			ret = -EINVAL;
 			goto err_probe;
 		}
+
+		mtd_set_ooblayout(mtd, &fsmc_ecc4_ooblayout_ops);
 	} else {
 		switch (nand->ecc.mode) {
 		case NAND_ECC_HW:
@@ -1135,13 +1006,10 @@ static int __init fsmc_nand_probe(struct platform_device *pdev)
 		if (nand->ecc.mode != NAND_ECC_SOFT_BCH) {
 			switch (mtd->oobsize) {
 			case 16:
-				nand->ecc.layout = &fsmc_ecc1_16_layout;
-				break;
 			case 64:
-				nand->ecc.layout = &fsmc_ecc1_64_layout;
-				break;
 			case 128:
-				nand->ecc.layout = &fsmc_ecc1_128_layout;
+				mtd_set_ooblayout(mtd,
+						  &fsmc_ecc1_ooblayout_ops);
 				break;
 			default:
 				dev_warn(&pdev->dev,
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:07:10 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:07:10 +0100
Subject: [PATCH v2 47/51] mtd: nand: vf610: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-48-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/vf610_nfc.c | 34 ++++------------------------------
 1 file changed, 4 insertions(+), 30 deletions(-)

diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index 293feb1..da34de1 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -175,34 +175,6 @@ static inline struct vf610_nfc *mtd_to_nfc(struct mtd_info *mtd)
 	return container_of(mtd_to_nand(mtd), struct vf610_nfc, chip);
 }
 
-static struct nand_ecclayout vf610_nfc_ecc45 = {
-	.eccbytes = 45,
-	.eccpos = {19, 20, 21, 22, 23,
-		   24, 25, 26, 27, 28, 29, 30, 31,
-		   32, 33, 34, 35, 36, 37, 38, 39,
-		   40, 41, 42, 43, 44, 45, 46, 47,
-		   48, 49, 50, 51, 52, 53, 54, 55,
-		   56, 57, 58, 59, 60, 61, 62, 63},
-	.oobfree = {
-		{.offset = 2,
-		 .length = 17} }
-};
-
-static struct nand_ecclayout vf610_nfc_ecc60 = {
-	.eccbytes = 60,
-	.eccpos = { 4,  5,  6,  7,  8,  9, 10, 11,
-		   12, 13, 14, 15, 16, 17, 18, 19,
-		   20, 21, 22, 23, 24, 25, 26, 27,
-		   28, 29, 30, 31, 32, 33, 34, 35,
-		   36, 37, 38, 39, 40, 41, 42, 43,
-		   44, 45, 46, 47, 48, 49, 50, 51,
-		   52, 53, 54, 55, 56, 57, 58, 59,
-		   60, 61, 62, 63 },
-	.oobfree = {
-		{.offset = 2,
-		 .length = 2} }
-};
-
 static inline u32 vf610_nfc_read(struct vf610_nfc *nfc, uint reg)
 {
 	return readl(nfc->regs + reg);
@@ -781,14 +753,16 @@ static int vf610_nfc_probe(struct platform_device *pdev)
 		if (mtd->oobsize > 64)
 			mtd->oobsize = 64;
 
+		/*
+		 * mtd->ecclayout is not specified here because we're using the
+		 * default large page ECC layout defined in NAND core.
+		 */
 		if (chip->ecc.strength == 32) {
 			nfc->ecc_mode = ECC_60_BYTE;
 			chip->ecc.bytes = 60;
-			chip->ecc.layout = &vf610_nfc_ecc60;
 		} else if (chip->ecc.strength == 24) {
 			nfc->ecc_mode = ECC_45_BYTE;
 			chip->ecc.bytes = 45;
-			chip->ecc.layout = &vf610_nfc_ecc45;
 		} else {
 			dev_err(nfc->dev, "Unsupported ECC strength\n");
 			err = -ENXIO;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:07:13 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:07:13 +0100
Subject: [PATCH v2 50/51] mtd: nand: kill the ecc->layout field
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-51-git-send-email-boris.brezillon@free-electrons.com>

Now that all NAND drivers have switch to mtd_ooblayout_ops, we can kill
the ecc->layout field.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/nand_base.c | 8 --------
 drivers/mtd/nand/nand_bch.c  | 9 ---------
 include/linux/mtd/nand.h     | 2 --
 3 files changed, 19 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index e4dc62b..9f6b7609 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -4161,13 +4161,6 @@ int nand_scan_tail(struct mtd_info *mtd)
 	chip->oob_poi = chip->buffers->databuf + mtd->writesize;
 
 	/*
-	 * Set the provided ECC layout. If ecc->layout is NULL, the MTD core
-	 * will just leave mtd->ooblayout to NULL, if it's not NULL, it will
-	 * set ->ooblayout to the default ecclayout wrapper.
-	 */
-	mtd_set_ecclayout(mtd, ecc->layout);
-
-	/*
 	 * If no default placement scheme is given, select an appropriate one.
 	 */
 	if (!mtd->ooblayout && (ecc->mode != NAND_ECC_SOFT_BCH)) {
@@ -4412,7 +4405,6 @@ int nand_scan_tail(struct mtd_info *mtd)
 	mtd->writebufsize = mtd->writesize;
 
 	/* propagate ecc info to mtd_info */
-	mtd_set_ecclayout(mtd, ecc->layout);
 	mtd->ecc_strength = ecc->strength;
 	mtd->ecc_step_size = ecc->size;
 	/*
diff --git a/drivers/mtd/nand/nand_bch.c b/drivers/mtd/nand/nand_bch.c
index e29e75f..ca9b2a4 100644
--- a/drivers/mtd/nand/nand_bch.c
+++ b/drivers/mtd/nand/nand_bch.c
@@ -158,15 +158,6 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
 
 	eccsteps = mtd->writesize/eccsize;
 
-	/*
-	 * Rely on the default ecclayout to ooblayout wrapper provided by MTD
-	 * core if ecc.layout is not NULL.
-	 * FIXME: this should be removed when all callers have moved to the
-	 * mtd_ooblayout_ops approach.
-	 */
-	if (nand->ecc.layout)
-		mtd_set_ecclayout(mtd, nand->ecc.layout);
-
 	/* if no ecc placement scheme was provided, build one */
 	if (!mtd->ooblayout) {
 
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 82a005a..fdcc2b8 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -466,7 +466,6 @@ struct nand_hw_control {
  * @prepad:	padding information for syndrome based ECC generators
  * @postpad:	padding information for syndrome based ECC generators
  * @options:	ECC specific options (see NAND_ECC_XXX flags defined above)
- * @layout:	ECC layout control struct pointer
  * @priv:	pointer to private ECC control data
  * @hwctl:	function to control hardware ECC generator. Must only
  *		be provided if an hardware ECC is available
@@ -516,7 +515,6 @@ struct nand_ecc_ctrl {
 	int prepad;
 	int postpad;
 	unsigned int options;
-	struct nand_ecclayout	*layout;
 	void *priv;
 	void (*hwctl)(struct mtd_info *mtd, int mode);
 	int (*calculate)(struct mtd_info *mtd, const uint8_t *dat,
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:07:12 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:07:12 +0100
Subject: [PATCH v2 49/51] staging: mt29f_spinand: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-50-git-send-email-boris.brezillon@free-electrons.com>

Replace the nand_ecclayout definition by the equivalent mtd_ooblayout_ops
definition.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/staging/mt29f_spinand/mt29f_spinand.c | 48 +++++++++++++++++----------
 1 file changed, 30 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c b/drivers/staging/mt29f_spinand/mt29f_spinand.c
index 6728376..04b711759 100644
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -42,23 +42,33 @@ static inline struct spinand_state *mtd_to_state(struct mtd_info *mtd)
 static int enable_hw_ecc;
 static int enable_read_hw_ecc;
 
-static struct nand_ecclayout spinand_oob_64 = {
-	.eccbytes = 24,
-	.eccpos = {
-		1, 2, 3, 4, 5, 6,
-		17, 18, 19, 20, 21, 22,
-		33, 34, 35, 36, 37, 38,
-		49, 50, 51, 52, 53, 54, },
-	.oobfree = {
-		{.offset = 8,
-			.length = 8},
-		{.offset = 24,
-			.length = 8},
-		{.offset = 40,
-			.length = 8},
-		{.offset = 56,
-			.length = 8},
-	}
+static int spinand_ooblayout_64_ecc(struct mtd_info *mtd, int section,
+				    struct mtd_oob_region *oobregion)
+{
+	if (section > 3)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 1;
+	oobregion->length = 6;
+
+	return 0;
+}
+
+static int spinand_ooblayout_64_free(struct mtd_info *mtd, int section,
+				     struct mtd_oob_region *oobregion)
+{
+	if (section > 3)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 8;
+	oobregion->length = 8;
+
+	return 0;
+}
+
+const struct mtd_ooblayout_ops spinand_oob_64_ops = {
+	.ecc = spinand_ooblayout_64_ecc,
+	.free = spinand_ooblayout_64_free,
 };
 #endif
 
@@ -883,7 +893,6 @@ static int spinand_probe(struct spi_device *spi_nand)
 
 	chip->ecc.strength = 1;
 	chip->ecc.total	= chip->ecc.steps * chip->ecc.bytes;
-	chip->ecc.layout = &spinand_oob_64;
 	chip->ecc.read_page = spinand_read_page_hwecc;
 	chip->ecc.write_page = spinand_write_page_hwecc;
 #else
@@ -908,6 +917,9 @@ static int spinand_probe(struct spi_device *spi_nand)
 
 	mtd->dev.parent = &spi_nand->dev;
 	mtd->oobsize = 64;
+#ifdef CONFIG_MTD_SPINAND_ONDIEECC
+	mtd_set_ooblayout(mtd, &spinand_oob_64_ops);
+#endif
 
 	if (nand_scan(mtd, 1))
 		return -ENXIO;
-- 
2.1.4



From ulf.hansson at linaro.org  Thu Feb  4 02:20:03 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 4 Feb 2016 11:20:03 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAJZ5v0hdDdFDiieDnsjummg6F+nV7fi=gFa=oFweyP7-ApsHrQ@mail.gmail.com>
References: <20160202210345.GZ19432@atomide.com>
 <Pine.LNX.4.44L0.1602021626540.1653-100000@iolanthe.rowland.org>
 <20160202234626.GD19432@atomide.com>
 <CAJZ5v0hdDdFDiieDnsjummg6F+nV7fi=gFa=oFweyP7-ApsHrQ@mail.gmail.com>
Message-ID: <CAPDyKFr3jqh5bDFOuKLgomhQ2P9+yN5Ps8E0CH8r-oOjvBuswg@mail.gmail.com>

On 3 February 2016 at 18:18, Rafael J. Wysocki <rafael at kernel.org> wrote:
> On Wed, Feb 3, 2016 at 12:46 AM, Tony Lindgren <tony at atomide.com> wrote:
>> * Alan Stern <stern at rowland.harvard.edu> [160202 13:46]:
>>> On Tue, 2 Feb 2016, Tony Lindgren wrote:
>>>
>>> > > Also, what is autosuspend_delay set to for your device?  And is
>>> > > runtime_auto set?
>>> >
>>> > It's 100 at that point, see the commented snippet below from
>>> > omap_hsmmc_probe():
>>> >
>>> >     pm_runtime_enable(host->dev);
>>> >     pm_runtime_get_sync(host->dev);
>>> >     pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY);
>>> >     /* NOTE: pm_runtime_dont_use_autosuspend(host->dev) needed here? */
>>> >     pm_runtime_use_autosuspend(host->dev);
>>> >     ...
>>> >     /* gets -EPROBE_DEFER */
>>> > err_irq:
>>> >     ...
>>> >     pm_runtime_put_sync(host->dev);
>>>
>>> You could try changing this to pm_runtime_put_sync_suspend().  But
>>> putting pm_runtime_dont_use_autosuspend() before the put_sync seems
>>> like a perfectly reasonable thing to do, especially if you feel you
>>> should reverse all the changes you made at the start.
>
> FWIW, I'd call pm_runtime_dont_use_autosuspend() before put_sync().
>
> After all, the driver doesn't want to use autosuspend going forward,
> so stating that explicitly looks like the right thing to do.

Just wanted to add yet some new findings while I was looking into this
regression.

So, the reason why pm_runtime_put_sync() doesn't idle the device in
these cases, is because autosuspend is respected and for some reason
the autosuspend timer hasn't expired.
I was wondering *why* the timer isn't considered as expired, because
the driver don't call pm_runtime_mark_last_busy() in the failing probe
case...

Then I realized the following commit was merged a few releases ago,
which makes the runtime PM core to invoke pm_runtime_mark_last_busy()
for us.

commit 56f487c78015936097474fd89b2ccb229d500d0f
Author: Tony Lindgren <tony at atomide.com>
Date:   Wed May 13 16:36:32 2015 -0700
PM / Runtime: Update last_busy in rpm_resume

So, this commit actually causes the devices to stay active after a
failed probe attempt.

I think it's a good idea to revert this change, but what to you think?

Kind regards
Uffe


From georgi.djakov at linaro.org  Thu Feb  4 02:32:56 2016
From: georgi.djakov at linaro.org (Georgi Djakov)
Date: Thu,  4 Feb 2016 12:32:56 +0200
Subject: [PATCH] arm64: defconfig: Add Qualcomm sdhci and restart functionality
Message-ID: <1454581976-25364-1-git-send-email-georgi.djakov@linaro.org>

Enable sdhci and restart functionality for devices based on msm8916 platform.
Also increase the number of minors per block device to detect all available
partitions.

Signed-off-by: Georgi Djakov <georgi.djakov at linaro.org>
---
 arch/arm64/configs/defconfig |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index bdd7aa358d2a..901d3a311ed4 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -131,6 +131,7 @@ CONFIG_SPI_QUP=y
 CONFIG_PINCTRL_MSM8916=y
 CONFIG_GPIO_PL061=y
 CONFIG_GPIO_XGENE=y
+CONFIG_POWER_RESET_MSM=y
 CONFIG_POWER_RESET_XGENE=y
 CONFIG_POWER_RESET_SYSCON=y
 # CONFIG_HWMON is not set
@@ -152,9 +153,11 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_ISP1760=y
 CONFIG_USB_ULPI=y
 CONFIG_MMC=y
+CONFIG_MMC_BLOCK_MINORS=32
 CONFIG_MMC_ARMMMCI=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_MSM=y
 CONFIG_MMC_SPI=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_IDMAC=y


From p.zabel at pengutronix.de  Thu Feb  4 02:44:50 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 04 Feb 2016 11:44:50 +0100
Subject: [PATCH v4 1/1] USB: core: let USB device know device node
In-Reply-To: <1453706679-18948-1-git-send-email-peter.chen@freescale.com>
References: <1453706679-18948-1-git-send-email-peter.chen@freescale.com>
Message-ID: <1454582690.3356.18.camel@pengutronix.de>

Hi Peter,

Am Montag, den 25.01.2016, 15:24 +0800 schrieb Peter Chen:
> Although most of USB devices are hot-plug's, there are still some devices
> are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
> If these kinds of USB devices are multiple functions, and they can supply
> other interfaces like i2c, gpios for other devices, we may need to
> describe these at device tree.
> 
> In this commit, it uses "reg" in dts as physical port number to match
> the phyiscal port number decided by USB core, if they are the same,
> then the device node is for the device we are creating for USB core.
> 
> Signed-off-by: Peter Chen <peter.chen at freescale.com>
> ---
> Changes for v4:
> - The range of "reg" should be 1-31, changing device node address
>   style as in lower case hexadecimal with leading zeroes suppressed
>   [binding doc, usb-device.txt]
> - Improve the example at binding doc, it describes node from the top
>   (the controller)
> - Delete the struct of_node * within struct usb_device
> - Using usb_hcd_find_raw_port_number to get raw port number under root
>   hub port
> 
> Changes for v3:
> - typo: s/descirbe/describe/
> 
> Changes for v2:
> - Fix build error reported by kbuild robot, lack of "static" for
>   inline usb_of_get_child_node
> - Fix typo, "devcie_node" -> "device_node"
> - Add kernel-doc for of_node at struct usb_device
> 
> Changes from RFC:
> - Fix the error address for binding doc, and add compatible for binding doc
> - Change get child node API from "usb_of_find_node" to
>   "usb_of_get_child_node"
> - Delete unecessary header files
> - One typo
> 
>  .../devicetree/bindings/usb/usb-device.txt         | 25 ++++++++++++
>  drivers/usb/core/Makefile                          |  2 +-
>  drivers/usb/core/of.c                              | 47 ++++++++++++++++++++++
>  drivers/usb/core/usb.c                             | 14 ++++++-
>  include/linux/usb/of.h                             |  7 ++++
>  5 files changed, 92 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/usb-device.txt
>  create mode 100644 drivers/usb/core/of.c
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt b/Documentation/devicetree/bindings/usb/usb-device.txt
> new file mode 100644
> index 0000000..c702885
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/usb-device.txt
> @@ -0,0 +1,25 @@
> +Generic USB Device Properties
> +
> +Usually, we only use device tree for hard wired USB device.
> +The reference binding doc is from:
> +http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
> +
> +Required properties:
> +- compatible: usbVID,PID

The reference recommendation states that for single-configuration USB
devices the compatible should contain all of the applicable strings from
the list starting with 2) "usbVID,PID.REV" and ending with 11)
"usb,device". Are we going to ignore this?

The document also states that "the textual representation of VID, PID
[...] shall be in lower case hexadecimal with leading zeroes
suppressed". This should be documented here.

> +- reg: the port number which this device is connecting to, the range
> +  is 1-31.
> +
> +
> +Example:
> +
> +&usb1 {
> +	status = "okay";
> +
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	hub: genesys at 1 {

There are node names specified for hubs and mass storage devices:
"hub", "storage", "cdrom", "tape", "solid-state", and "device" for
everything else. Should we follow this recommendation?

> +		compatible = "usb05e3,0608";
> +		reg = <0x1>;
> +	};

I'd have written this node as:

	hub: hub at 1 {
		compatible = "usb5e3,608", "usb5e3,class9",
			     "usb,class9", "usb,device";
		reg = <1>;
	};

As another example, I'd like to introduce the USB WLAN Adapter soldered
onto the imx6q-gk802 board to its power enable GPIO via the device tree:

/* Internal USB port (USBH1) */
&usbh1 {
	#address-cells = <1>;
	#size-cells = <0>;
	status = "okay";

	/* RTL8192CU 802.11n WLAN Adapter */
	device at 1 {
		compatible = "usbbda,8176.200", "usbbda,8176",
			     "usb,device";
		reg = <1>;

		enable-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
	};
};

regards
Philipp



From ulf.hansson at linaro.org  Thu Feb  4 02:34:16 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 4 Feb 2016 11:34:16 +0100
Subject: [PATCH v4] mmc: meson: Add driver for the SD/MMC host found on
 Amlogic MesonX SoCs
In-Reply-To: <CAOQ7t2aF=wzYHF8LXK5WVMJ=mEDHzfvbL=iRvorq+FZshL0q0g@mail.gmail.com>
References: <1448988109-32630-1-git-send-email-carlo@caione.org>
 <CAPDyKFp=buvJ8Li3XC8XSUAUO7BsE+U6vEQH2xTrgcHAkdG8bQ@mail.gmail.com>
 <CAOQ7t2aJAPWd3Xmvu7n0EWL-KC8ZriM3KryfsYEh556uXhuR+g@mail.gmail.com>
 <CAPDyKFpcsKihuOiF5=RwoWrF0Jf7hRsXVSU5uV8qZf1mUsa-iQ@mail.gmail.com>
 <CAOQ7t2afXxStCsj=M-FX7eMep1gLt4jkyXDiLas_SQ1UwHc0=Q@mail.gmail.com>
 <CAPDyKFpX+_fHvv_bJUKZmSufKKnuONC582E7u3b20a+Rbbggng@mail.gmail.com>
 <CAOQ7t2aS0yRDhM3+8wW5xrycG371uthDJy6U_oDAZip4jHRiRA@mail.gmail.com>
 <CAPDyKFo=LdzFsELZJKXj_CDcNYj96J4Q9-KqS63041d3BVUEDQ@mail.gmail.com>
 <CAOQ7t2aF=wzYHF8LXK5WVMJ=mEDHzfvbL=iRvorq+FZshL0q0g@mail.gmail.com>
Message-ID: <CAPDyKFqpgEtAvK9HesdA5tLuj7htUmo5ZrvbDC0wCzHB3=_-xQ@mail.gmail.com>

On 4 February 2016 at 10:12, Carlo Caione <carlo at caione.org> wrote:
> On Wed, Feb 3, 2016 at 11:46 AM, Ulf Hansson <ulf.hansson at linaro.org> wrote:
>> On 2 February 2016 at 22:54, Carlo Caione <carlo at caione.org> wrote:
>
> [cut]
>
>> Huh, another broken MMC controller. :-)
>
> Oh, actually I found in the datasheet a couple of undocumented
> registers (also not used in the original Amlogic SDK code) that seems
> to have something to do with timeout (hard to say without proper
> documentation but they are called "Timeout counter for preload setting
> and present status" and "Timeout Counter Interrupt Enable for ARC/ARM"
> so I guess I'm on the right track here).
> I briefly tried yesterday to enable this timeout interrupt with a
> dummy value in the counter register (I have no idea how get this value
> from the clocking) and it seems working (the counter value is
> decremented when reading the register upon command completion).

Let's hope this works, as this will for sure be a better solution.

>
>> In some cases there are no data in the request, it's just a command
>> being sent. So to deal with this issue, you will have to adjust the
>> timer depending on the request we send to the controller.
>
> I see that the CMD13 used to poll the card has no data so in that case
> should we use a fixed / dummy value to use as timeout counter?
> I'm kind of confused here since the MMC drivers I'm looking at use the
> hardware timeout register only when the data->timeout_ns is actually
> present.

That's a different timeout value. It's elated to *each* block data
transfer and not the entire request. So it provides information to the
controller about what delays it shall accept during a block being
written/read.

More details is found in the electrical descriptions of the interface
in the eMMC/SD spec.

Kind regards
Uffe


From boris.brezillon at free-electrons.com  Thu Feb  4 02:07:07 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:07:07 +0100
Subject: [PATCH v2 44/51] mtd: nand: sh_flctl: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-45-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/sh_flctl.c | 87 ++++++++++++++++++++++++++++++++++-----------
 1 file changed, 67 insertions(+), 20 deletions(-)

diff --git a/drivers/mtd/nand/sh_flctl.c b/drivers/mtd/nand/sh_flctl.c
index 4814402..be4d331 100644
--- a/drivers/mtd/nand/sh_flctl.c
+++ b/drivers/mtd/nand/sh_flctl.c
@@ -43,26 +43,73 @@
 #include <linux/mtd/partitions.h>
 #include <linux/mtd/sh_flctl.h>
 
-static struct nand_ecclayout flctl_4secc_oob_16 = {
-	.eccbytes = 10,
-	.eccpos = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
-	.oobfree = {
-		{.offset = 12,
-		. length = 4} },
+static int flctl_4secc_ooblayout_sp_ecc(struct mtd_info *mtd, int section,
+					struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 0;
+	oobregion->length = chip->ecc.bytes;
+
+	return 0;
+}
+
+static int flctl_4secc_ooblayout_sp_free(struct mtd_info *mtd, int section,
+					 struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 12;
+	oobregion->length = 4;
+
+	return 0;
+}
+
+const struct mtd_ooblayout_ops flctl_4secc_oob_smallpage_ops = {
+	.ecc = flctl_4secc_ooblayout_sp_ecc,
+	.free = flctl_4secc_ooblayout_sp_free,
 };
 
-static struct nand_ecclayout flctl_4secc_oob_64 = {
-	.eccbytes = 4 * 10,
-	.eccpos = {
-		 6,  7,  8,  9, 10, 11, 12, 13, 14, 15,
-		22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
-		38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
-		54, 55, 56, 57, 58, 59, 60, 61, 62, 63 },
-	.oobfree = {
-		{.offset =  2, .length = 4},
-		{.offset = 16, .length = 6},
-		{.offset = 32, .length = 6},
-		{.offset = 48, .length = 6} },
+static int flctl_4secc_ooblayout_lp_ecc(struct mtd_info *mtd, int section,
+					struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 6;
+	oobregion->length = chip->ecc.bytes;
+
+	return 0;
+}
+
+static int flctl_4secc_ooblayout_lp_free(struct mtd_info *mtd, int section,
+					 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = section * 16;
+	oobregion->length = 6;
+
+	if (!section) {
+		oobregion->offset += 2;
+		oobregion->length -= 2;
+	}
+
+	return 0;
+}
+
+const struct mtd_ooblayout_ops flctl_4secc_oob_largepage_ops = {
+	.ecc = flctl_4secc_ooblayout_lp_ecc,
+	.free = flctl_4secc_ooblayout_lp_free,
 };
 
 static uint8_t scan_ff_pattern[] = { 0xff, 0xff };
@@ -987,10 +1034,10 @@ static int flctl_chip_init_tail(struct mtd_info *mtd)
 
 	if (flctl->hwecc) {
 		if (mtd->writesize == 512) {
-			chip->ecc.layout = &flctl_4secc_oob_16;
+			mtd_set_ooblayout(mtd, &flctl_4secc_oob_smallpage_ops);
 			chip->badblock_pattern = &flctl_4secc_smallpage;
 		} else {
-			chip->ecc.layout = &flctl_4secc_oob_64;
+			mtd_set_ooblayout(mtd, &flctl_4secc_oob_largepage_ops);
 			chip->badblock_pattern = &flctl_4secc_largepage;
 		}
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:55 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:55 +0100
Subject: [PATCH v2 32/51] mtd: nand: docg4: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-33-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/docg4.c | 33 ++++++++++++++++++++++++++++-----
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c
index fb46fd7..f5ca9a5 100644
--- a/drivers/mtd/nand/docg4.c
+++ b/drivers/mtd/nand/docg4.c
@@ -222,10 +222,33 @@ struct docg4_priv {
  * Bytes 8 - 14 are hw-generated ecc covering entire page + oob bytes 0 - 14.
  * Byte 15 (the last) is used by the driver as a "page written" flag.
  */
-static struct nand_ecclayout docg4_oobinfo = {
-	.eccbytes = 9,
-	.eccpos = {7, 8, 9, 10, 11, 12, 13, 14, 15},
-	.oobfree = { {.offset = 2, .length = 5} }
+static int docg4_ooblayout_ecc(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 7;
+	oobregion->length = 9;
+
+	return 0;
+}
+
+static int docg4_ooblayout_free(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 2;
+	oobregion->length = 5;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops docg4_ooblayout_ops = {
+	.ecc = docg4_ooblayout_ecc,
+	.free = docg4_ooblayout_free,
 };
 
 /*
@@ -1209,6 +1232,7 @@ static void __init init_mtd_structs(struct mtd_info *mtd)
 	mtd->writesize = DOCG4_PAGE_SIZE;
 	mtd->erasesize = DOCG4_BLOCK_SIZE;
 	mtd->oobsize = DOCG4_OOB_SIZE;
+	mtd_set_ooblayout(mtd, &docg4_ooblayout_ops);
 	nand->chipsize = DOCG4_CHIP_SIZE;
 	nand->chip_shift = DOCG4_CHIP_SHIFT;
 	nand->bbt_erase_shift = nand->phys_erase_shift = DOCG4_ERASE_SHIFT;
@@ -1217,7 +1241,6 @@ static void __init init_mtd_structs(struct mtd_info *mtd)
 	nand->pagemask = 0x3ffff;
 	nand->badblockpos = NAND_LARGE_BADBLOCK_POS;
 	nand->badblockbits = 8;
-	nand->ecc.layout = &docg4_oobinfo;
 	nand->ecc.mode = NAND_ECC_HW_SYNDROME;
 	nand->ecc.size = DOCG4_PAGE_SIZE;
 	nand->ecc.prepad = 8;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:43 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:43 +0100
Subject: [PATCH v2 20/51] mtd: docg3: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-21-git-send-email-boris.brezillon@free-electrons.com>

Replace the nand_ecclayout definition by the equivalent mtd_ooblayout_ops
definition.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/devices/docg3.c | 38 +++++++++++++++++++++++++++++++++-----
 1 file changed, 33 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/devices/docg3.c b/drivers/mtd/devices/docg3.c
index 6b516e1..0f63f51 100644
--- a/drivers/mtd/devices/docg3.c
+++ b/drivers/mtd/devices/docg3.c
@@ -73,10 +73,38 @@ MODULE_PARM_DESC(reliable_mode, "Set the docg3 mode (0=normal MLC, 1=fast, "
  * @eccpos: ecc positions (byte 7 is Hamming ECC, byte 8-14 are BCH ECC)
  * @oobfree: free pageinfo bytes (byte 0 until byte 6, byte 15
  */
-static struct nand_ecclayout docg3_oobinfo = {
-	.eccbytes = 8,
-	.eccpos = {7, 8, 9, 10, 11, 12, 13, 14},
-	.oobfree = {{0, 7}, {15, 1} },
+static int docg3_ooblayout_ecc(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 7;
+	oobregion->length = 8;
+
+	return 0;
+}
+
+static int docg3_ooblayout_free(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	if (section > 1)
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 0;
+		oobregion->length = 7;
+	} else {
+		oobregion->offset = 15;
+		oobregion->length = 1;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops nand_ooblayout_docg3_ops = {
+	.ecc = docg3_ooblayout_ecc,
+	.free = docg3_ooblayout_free,
 };
 
 static inline u8 doc_readb(struct docg3 *docg3, u16 reg)
@@ -1857,7 +1885,7 @@ static int __init doc_set_driver_info(int chip_id, struct mtd_info *mtd)
 	mtd->_read_oob = doc_read_oob;
 	mtd->_write_oob = doc_write_oob;
 	mtd->_block_isbad = doc_block_isbad;
-	mtd_set_ecclayout(mtd, &docg3_oobinfo);
+	mtd_set_ooblayout(mtd, &nand_ooblayout_docg3_ops);
 	mtd->oobavail = 8;
 	mtd->ecc_strength = DOC_ECC_BCH_T;
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:07:04 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:07:04 +0100
Subject: [PATCH v2 41/51] mtd: nand: omap2: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-42-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/omap2.c | 194 +++++++++++++++++++++++++++--------------------
 1 file changed, 113 insertions(+), 81 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 4ebf16b..11d5bff 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -169,8 +169,6 @@ struct omap_nand_info {
 	u_char				*buf;
 	int					buf_len;
 	struct gpmc_nand_regs		reg;
-	/* generated at runtime depending on ECC algorithm and layout selected */
-	struct nand_ecclayout		oobinfo;
 	/* fields specific for BCHx_HW ECC scheme */
 	struct device			*elm_dev;
 	struct device_node		*of_node;
@@ -1639,19 +1637,108 @@ static bool omap2_nand_ecc_check(struct omap_nand_info *info,
 	return true;
 }
 
+static int omap_ooblayout_ecc(struct mtd_info *mtd, int section,
+			      struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int off = chip->options & NAND_BUSWIDTH_16 ?
+		  BADBLOCK_MARKER_LENGTH : 1;
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = off;
+	oobregion->length = chip->ecc.bytes * chip->ecc.steps;
+
+	return 0;
+}
+
+static int omap_ooblayout_free(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int off = chip->options & NAND_BUSWIDTH_16 ?
+		  BADBLOCK_MARKER_LENGTH : 1;
+
+	if (section)
+		return -ERANGE;
+
+	off += chip->ecc.bytes * chip->ecc.steps;
+	if (off >= mtd->oobsize)
+		return -ERANGE;
+
+	oobregion->offset = off;
+	oobregion->length = mtd->oobsize - off;
+
+	return 0;
+}
+
+const struct mtd_ooblayout_ops omap_ooblayout_ops = {
+	.ecc = omap_ooblayout_ecc,
+	.free = omap_ooblayout_free,
+};
+
+static int omap_sw_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int off = chip->options & NAND_BUSWIDTH_16 ?
+		  BADBLOCK_MARKER_LENGTH : 1;
+
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
+
+	/*
+	 * When SW correction is employed, one OMAP specific marker byte is
+	 * reserved after each ECC step.
+	 */
+	oobregion->offset = off + (section * (chip->ecc.bytes + 1));
+	oobregion->length = chip->ecc.bytes;
+
+	return 0;
+}
+
+static int omap_sw_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int off = chip->options & NAND_BUSWIDTH_16 ?
+		  BADBLOCK_MARKER_LENGTH : 1;
+
+	if (section)
+		return -ERANGE;
+
+	/*
+	 * When SW correction is employed, one OMAP specific marker byte is
+	 * reserved after each ECC step.
+	 */
+	off += ((chip->ecc.bytes + 1) * chip->ecc.steps);
+	if (off >= mtd->oobsize)
+		return -ERANGE;
+
+	oobregion->offset = off;
+	oobregion->length = mtd->oobsize - off;
+
+	return 0;
+}
+
+const struct mtd_ooblayout_ops omap_sw_ooblayout_ops = {
+	.ecc = omap_sw_ooblayout_ecc,
+	.free = omap_sw_ooblayout_free,
+};
+
 static int omap_nand_probe(struct platform_device *pdev)
 {
 	struct omap_nand_info		*info;
 	struct omap_nand_platform_data	*pdata;
 	struct mtd_info			*mtd;
 	struct nand_chip		*nand_chip;
-	struct nand_ecclayout		*ecclayout;
 	int				err;
-	int				i;
 	dma_cap_mask_t			mask;
 	unsigned			sig;
-	unsigned			oob_index;
 	struct resource			*res;
+	int				min_oobbytes;
+	int				oobbytes_per_step;
 
 	pdata = dev_get_platdata(&pdev->dev);
 	if (pdata == NULL) {
@@ -1810,7 +1897,7 @@ static int omap_nand_probe(struct platform_device *pdev)
 
 	/*
 	 * Bail out earlier to let NAND_ECC_SOFT code create its own
-	 * ecclayout instead of using ours.
+	 * ooblayout instead of using ours.
 	 */
 	if (info->ecc_opt == OMAP_ECC_HAM1_CODE_SW) {
 		nand_chip->ecc.mode = NAND_ECC_SOFT;
@@ -1818,8 +1905,6 @@ static int omap_nand_probe(struct platform_device *pdev)
 	}
 
 	/* populate MTD interface based on ECC scheme */
-	ecclayout		= &info->oobinfo;
-	nand_chip->ecc.layout	= ecclayout;
 	switch (info->ecc_opt) {
 	case OMAP_ECC_HAM1_CODE_HW:
 		pr_info("nand: using OMAP_ECC_HAM1_CODE_HW\n");
@@ -1830,19 +1915,8 @@ static int omap_nand_probe(struct platform_device *pdev)
 		nand_chip->ecc.calculate        = omap_calculate_ecc;
 		nand_chip->ecc.hwctl            = omap_enable_hwecc;
 		nand_chip->ecc.correct          = omap_correct_data;
-		/* define ECC layout */
-		ecclayout->eccbytes		= nand_chip->ecc.bytes *
-							(mtd->writesize /
-							nand_chip->ecc.size);
-		if (nand_chip->options & NAND_BUSWIDTH_16)
-			oob_index		= BADBLOCK_MARKER_LENGTH;
-		else
-			oob_index		= 1;
-		for (i = 0; i < ecclayout->eccbytes; i++, oob_index++)
-			ecclayout->eccpos[i]	= oob_index;
-		/* no reserved-marker in ecclayout for this ecc-scheme */
-		ecclayout->oobfree->offset	=
-				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
+		mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
+		oobbytes_per_step		= nand_chip->ecc.bytes;
 		break;
 
 	case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
@@ -1854,19 +1928,9 @@ static int omap_nand_probe(struct platform_device *pdev)
 		nand_chip->ecc.hwctl		= omap_enable_hwecc_bch;
 		nand_chip->ecc.correct		= nand_bch_correct_data;
 		nand_chip->ecc.calculate	= omap_calculate_ecc_bch;
-		/* define ECC layout */
-		ecclayout->eccbytes		= nand_chip->ecc.bytes *
-							(mtd->writesize /
-							nand_chip->ecc.size);
-		oob_index			= BADBLOCK_MARKER_LENGTH;
-		for (i = 0; i < ecclayout->eccbytes; i++, oob_index++) {
-			ecclayout->eccpos[i] = oob_index;
-			if (((i + 1) % nand_chip->ecc.bytes) == 0)
-				oob_index++;
-		}
-		/* include reserved-marker in ecclayout->oobfree calculation */
-		ecclayout->oobfree->offset	= 1 +
-				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
+		mtd_set_ooblayout(mtd, &omap_sw_ooblayout_ops);
+		/* Reserve one byte for the OMAP marker */
+		oobbytes_per_step		= nand_chip->ecc.bytes + 1;
 		/* software bch library is used for locating errors */
 		nand_chip->ecc.priv		= nand_bch_init(mtd);
 		if (!nand_chip->ecc.priv) {
@@ -1888,16 +1952,8 @@ static int omap_nand_probe(struct platform_device *pdev)
 		nand_chip->ecc.calculate	= omap_calculate_ecc_bch;
 		nand_chip->ecc.read_page	= omap_read_page_bch;
 		nand_chip->ecc.write_page	= omap_write_page_bch;
-		/* define ECC layout */
-		ecclayout->eccbytes		= nand_chip->ecc.bytes *
-							(mtd->writesize /
-							nand_chip->ecc.size);
-		oob_index			= BADBLOCK_MARKER_LENGTH;
-		for (i = 0; i < ecclayout->eccbytes; i++, oob_index++)
-			ecclayout->eccpos[i]	= oob_index;
-		/* reserved marker already included in ecclayout->eccbytes */
-		ecclayout->oobfree->offset	=
-				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
+		mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
+		oobbytes_per_step		= nand_chip->ecc.bytes;
 
 		err = elm_config(info->elm_dev, BCH4_ECC,
 				 mtd->writesize / nand_chip->ecc.size,
@@ -1915,19 +1971,9 @@ static int omap_nand_probe(struct platform_device *pdev)
 		nand_chip->ecc.hwctl		= omap_enable_hwecc_bch;
 		nand_chip->ecc.correct		= nand_bch_correct_data;
 		nand_chip->ecc.calculate	= omap_calculate_ecc_bch;
-		/* define ECC layout */
-		ecclayout->eccbytes		= nand_chip->ecc.bytes *
-							(mtd->writesize /
-							nand_chip->ecc.size);
-		oob_index			= BADBLOCK_MARKER_LENGTH;
-		for (i = 0; i < ecclayout->eccbytes; i++, oob_index++) {
-			ecclayout->eccpos[i] = oob_index;
-			if (((i + 1) % nand_chip->ecc.bytes) == 0)
-				oob_index++;
-		}
-		/* include reserved-marker in ecclayout->oobfree calculation */
-		ecclayout->oobfree->offset	= 1 +
-				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
+		mtd_set_ooblayout(mtd, &omap_sw_ooblayout_ops);
+		/* Reserve one byte for the OMAP marker */
+		oobbytes_per_step		= nand_chip->ecc.bytes + 1;
 		/* software bch library is used for locating errors */
 		nand_chip->ecc.priv		= nand_bch_init(mtd);
 		if (!nand_chip->ecc.priv) {
@@ -1949,6 +1995,8 @@ static int omap_nand_probe(struct platform_device *pdev)
 		nand_chip->ecc.calculate	= omap_calculate_ecc_bch;
 		nand_chip->ecc.read_page	= omap_read_page_bch;
 		nand_chip->ecc.write_page	= omap_write_page_bch;
+		mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
+		oobbytes_per_step		= nand_chip->ecc.bytes;
 
 		err = elm_config(info->elm_dev, BCH8_ECC,
 				 mtd->writesize / nand_chip->ecc.size,
@@ -1956,16 +2004,6 @@ static int omap_nand_probe(struct platform_device *pdev)
 		if (err < 0)
 			goto return_error;
 
-		/* define ECC layout */
-		ecclayout->eccbytes		= nand_chip->ecc.bytes *
-							(mtd->writesize /
-							nand_chip->ecc.size);
-		oob_index			= BADBLOCK_MARKER_LENGTH;
-		for (i = 0; i < ecclayout->eccbytes; i++, oob_index++)
-			ecclayout->eccpos[i]	= oob_index;
-		/* reserved marker already included in ecclayout->eccbytes */
-		ecclayout->oobfree->offset	=
-				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
 		break;
 
 	case OMAP_ECC_BCH16_CODE_HW:
@@ -1979,6 +2017,8 @@ static int omap_nand_probe(struct platform_device *pdev)
 		nand_chip->ecc.calculate	= omap_calculate_ecc_bch;
 		nand_chip->ecc.read_page	= omap_read_page_bch;
 		nand_chip->ecc.write_page	= omap_write_page_bch;
+		mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
+		oobbytes_per_step		= nand_chip->ecc.bytes;
 
 		err = elm_config(info->elm_dev, BCH16_ECC,
 				 mtd->writesize / nand_chip->ecc.size,
@@ -1986,16 +2026,6 @@ static int omap_nand_probe(struct platform_device *pdev)
 		if (err < 0)
 			goto return_error;
 
-		/* define ECC layout */
-		ecclayout->eccbytes		= nand_chip->ecc.bytes *
-							(mtd->writesize /
-							nand_chip->ecc.size);
-		oob_index			= BADBLOCK_MARKER_LENGTH;
-		for (i = 0; i < ecclayout->eccbytes; i++, oob_index++)
-			ecclayout->eccpos[i]	= oob_index;
-		/* reserved marker already included in ecclayout->eccbytes */
-		ecclayout->oobfree->offset	=
-				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
 		break;
 	default:
 		dev_err(&info->pdev->dev, "invalid or unsupported ECC scheme\n");
@@ -2003,13 +2033,15 @@ static int omap_nand_probe(struct platform_device *pdev)
 		goto return_error;
 	}
 
-	/* all OOB bytes from oobfree->offset till end off OOB are free */
-	ecclayout->oobfree->length = mtd->oobsize - ecclayout->oobfree->offset;
 	/* check if NAND device's OOB is enough to store ECC signatures */
-	if (mtd->oobsize < (ecclayout->eccbytes + BADBLOCK_MARKER_LENGTH)) {
+	min_oobbytes = (oobbytes_per_step *
+			(mtd->writesize / nand_chip->ecc.size)) +
+		       (nand_chip->options & NAND_BUSWIDTH_16 ?
+			BADBLOCK_MARKER_LENGTH : 1);
+	if (mtd->oobsize < min_oobbytes) {
 		dev_err(&info->pdev->dev,
 			"not enough OOB bytes required = %d, available=%d\n",
-			ecclayout->eccbytes, mtd->oobsize);
+			min_oobbytes, mtd->oobsize);
 		err = -EINVAL;
 		goto return_error;
 	}
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:47 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:47 +0100
Subject: [PATCH v2 24/51] mtd: nand: jz4740: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-25-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 arch/mips/include/asm/mach-jz4740/jz4740_nand.h |  2 +-
 arch/mips/jz4740/board-qi_lb60.c                | 87 +++++++++++++++----------
 drivers/mtd/nand/jz4740_nand.c                  |  2 +-
 3 files changed, 53 insertions(+), 38 deletions(-)

diff --git a/arch/mips/include/asm/mach-jz4740/jz4740_nand.h b/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
index 398733e..7f7b0fc 100644
--- a/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
+++ b/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
@@ -27,7 +27,7 @@ struct jz_nand_platform_data {
 
 	unsigned char banks[JZ_NAND_NUM_BANKS];
 
-	void (*ident_callback)(struct platform_device *, struct nand_chip *,
+	void (*ident_callback)(struct platform_device *, struct mtd_info *,
 				struct mtd_partition **, int *num_partitions);
 };
 
diff --git a/arch/mips/jz4740/board-qi_lb60.c b/arch/mips/jz4740/board-qi_lb60.c
index 934b15b..a1c1afb 100644
--- a/arch/mips/jz4740/board-qi_lb60.c
+++ b/arch/mips/jz4740/board-qi_lb60.c
@@ -50,20 +50,6 @@ static bool is_avt2;
 #define QI_LB60_GPIO_KEYIN8		JZ_GPIO_PORTD(26)
 
 /* NAND */
-static struct nand_ecclayout qi_lb60_ecclayout_1gb = {
-	.eccbytes = 36,
-	.eccpos = {
-		6,  7,	8,  9,	10, 11, 12, 13,
-		14, 15, 16, 17, 18, 19, 20, 21,
-		22, 23, 24, 25, 26, 27, 28, 29,
-		30, 31, 32, 33, 34, 35, 36, 37,
-		38, 39, 40, 41
-	},
-	.oobfree = {
-		{ .offset = 2, .length = 4 },
-		{ .offset = 42, .length = 22 }
-	},
-};
 
 /* Early prototypes of the QI LB60 had only 1GB of NAND.
  * In order to support these devices as well the partition and ecc layout is
@@ -86,25 +72,6 @@ static struct mtd_partition qi_lb60_partitions_1gb[] = {
 	},
 };
 
-static struct nand_ecclayout qi_lb60_ecclayout_2gb = {
-	.eccbytes = 72,
-	.eccpos = {
-		12, 13, 14, 15, 16, 17, 18, 19,
-		20, 21, 22, 23, 24, 25, 26, 27,
-		28, 29, 30, 31, 32, 33, 34, 35,
-		36, 37, 38, 39, 40, 41, 42, 43,
-		44, 45, 46, 47, 48, 49, 50, 51,
-		52, 53, 54, 55, 56, 57, 58, 59,
-		60, 61, 62, 63, 64, 65, 66, 67,
-		68, 69, 70, 71, 72, 73, 74, 75,
-		76, 77, 78, 79, 80, 81, 82, 83
-	},
-	.oobfree = {
-		{ .offset = 2, .length = 10 },
-		{ .offset = 84, .length = 44 },
-	},
-};
-
 static struct mtd_partition qi_lb60_partitions_2gb[] = {
 	{
 		.name = "NAND BOOT partition",
@@ -123,19 +90,67 @@ static struct mtd_partition qi_lb60_partitions_2gb[] = {
 	},
 };
 
+static int qi_lb60_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->length = 36;
+	oobregion->offset = 6;
+
+	if (mtd->oobsize == 128) {
+		oobregion->length *= 2;
+		oobregion->offset *= 2;
+	}
+
+	return 0;
+}
+
+static int qi_lb60_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	int eccbytes = 36, eccoff = 6;
+
+	if (section > 1)
+		return -ERANGE;
+
+	if (mtd->oobsize == 128) {
+		eccbytes *= 2;
+		eccoff *= 2;
+	}
+
+	if (!section) {
+		oobregion->offset = 2;
+		oobregion->length = eccoff - 2;
+	} else {
+		oobregion->offset = eccoff + eccbytes;
+		oobregion->length = mtd->oobsize - oobregion->offset;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops qi_lb60_ooblayout_ops = {
+	.ecc = qi_lb60_ooblayout_ecc,
+	.free = qi_lb60_ooblayout_free,
+};
+
 static void qi_lb60_nand_ident(struct platform_device *pdev,
-		struct nand_chip *chip, struct mtd_partition **partitions,
+		struct mtd_info *mtd, struct mtd_partition **partitions,
 		int *num_partitions)
 {
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
 	if (chip->page_shift == 12) {
-		chip->ecc.layout = &qi_lb60_ecclayout_2gb;
 		*partitions = qi_lb60_partitions_2gb;
 		*num_partitions = ARRAY_SIZE(qi_lb60_partitions_2gb);
 	} else {
-		chip->ecc.layout = &qi_lb60_ecclayout_1gb;
 		*partitions = qi_lb60_partitions_1gb;
 		*num_partitions = ARRAY_SIZE(qi_lb60_partitions_1gb);
 	}
+
+	mtd_set_ooblayout(mtd, &qi_lb60_ooblayout_ops);
 }
 
 static struct jz_nand_platform_data qi_lb60_nand_pdata = {
diff --git a/drivers/mtd/nand/jz4740_nand.c b/drivers/mtd/nand/jz4740_nand.c
index 673ceb2..df74408 100644
--- a/drivers/mtd/nand/jz4740_nand.c
+++ b/drivers/mtd/nand/jz4740_nand.c
@@ -476,7 +476,7 @@ static int jz_nand_probe(struct platform_device *pdev)
 	}
 
 	if (pdata && pdata->ident_callback) {
-		pdata->ident_callback(pdev, chip, &pdata->partitions,
+		pdata->ident_callback(pdev, mtd, &pdata->partitions,
 					&pdata->num_partitions);
 	}
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:07:00 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:07:00 +0100
Subject: [PATCH v2 37/51] mtd: nand: hisi504: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-38-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/hisi504_nand.c | 27 ++++++++++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/hisi504_nand.c b/drivers/mtd/nand/hisi504_nand.c
index 96502b6..a2a8eb0 100644
--- a/drivers/mtd/nand/hisi504_nand.c
+++ b/drivers/mtd/nand/hisi504_nand.c
@@ -631,8 +631,29 @@ static void hisi_nfc_host_init(struct hinfc_host *host)
 	hinfc_write(host, HINFC504_INTEN_DMA, HINFC504_INTEN);
 }
 
-static struct nand_ecclayout nand_ecc_2K_16bits = {
-	.oobfree = { {2, 6} },
+static int hisi_ooblayout_ecc(struct mtd_info *mtd, int section,
+			      struct mtd_oob_region *oobregion)
+{
+	/* FIXME: add real eccpos definition. */
+	return -ENOTSUPP;
+}
+
+static int hisi_ooblayout_free(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	/* FIXME: add full oobfree definition. */
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 2;
+	oobregion->length = 6;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops hisi_ooblayout_ops = {
+	.ecc = hisi_ooblayout_ecc,
+	.free = hisi_ooblayout_free,
 };
 
 static int hisi_nfc_ecc_probe(struct hinfc_host *host)
@@ -668,7 +689,7 @@ static int hisi_nfc_ecc_probe(struct hinfc_host *host)
 	case 16:
 		ecc_bits = 6;
 		if (mtd->writesize == 2048)
-			chip->ecc.layout = &nand_ecc_2K_16bits;
+			mtd_set_ooblayout(mtd, &hisi_ooblayout_ops);
 
 		/* TODO: add more page size support */
 		break;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:48 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:48 +0100
Subject: [PATCH v2 25/51] mtd: nand: atmel: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-26-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/atmel_nand.c | 84 ++++++++++++++++++++-----------------------
 1 file changed, 38 insertions(+), 46 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 9dde308..dddb219 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -67,30 +67,44 @@ struct atmel_nand_caps {
 	bool pmecc_correct_erase_page;
 };
 
-/* oob layout for large page size
+/*
+ * oob layout for large page size
  * bad block info is on bytes 0 and 1
  * the bytes have to be consecutives to avoid
  * several NAND_CMD_RNDOUT during read
- */
-static struct nand_ecclayout atmel_oobinfo_large = {
-	.eccbytes = 4,
-	.eccpos = {60, 61, 62, 63},
-	.oobfree = {
-		{2, 58}
-	},
-};
-
-/* oob layout for small page size
+ *
+ * oob layout for small page size
  * bad block info is on bytes 4 and 5
  * the bytes have to be consecutives to avoid
  * several NAND_CMD_RNDOUT during read
  */
-static struct nand_ecclayout atmel_oobinfo_small = {
-	.eccbytes = 4,
-	.eccpos = {0, 1, 2, 3},
-	.oobfree = {
-		{6, 10}
-	},
+static int atmel_ooblayout_ecc_sp(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->length = 4;
+	oobregion->offset = 0;
+
+	return 0;
+}
+
+static int atmel_ooblayout_free_sp(struct mtd_info *mtd, int section,
+				   struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 6;
+	oobregion->length = mtd->oobsize - oobregion->offset;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops atmel_ooblayout_sp_ops = {
+	.ecc = atmel_ooblayout_ecc_sp,
+	.free = atmel_ooblayout_free_sp,
 };
 
 struct atmel_nfc {
@@ -156,8 +170,6 @@ struct atmel_nand_host {
 	int			*pmecc_delta;
 };
 
-static struct nand_ecclayout atmel_pmecc_oobinfo;
-
 /*
  * Enable NAND.
  */
@@ -475,22 +487,6 @@ static int pmecc_get_ecc_bytes(int cap, int sector_size)
 	return (m * cap + 7) / 8;
 }
 
-static void pmecc_config_ecc_layout(struct nand_ecclayout *layout,
-				    int oobsize, int ecc_len)
-{
-	int i;
-
-	layout->eccbytes = ecc_len;
-
-	/* ECC will occupy the last ecc_len bytes continuously */
-	for (i = 0; i < ecc_len; i++)
-		layout->eccpos[i] = oobsize - ecc_len + i;
-
-	layout->oobfree[0].offset = PMECC_OOB_RESERVED_BYTES;
-	layout->oobfree[0].length =
-		oobsize - ecc_len - layout->oobfree[0].offset;
-}
-
 static void __iomem *pmecc_get_alpha_to(struct atmel_nand_host *host)
 {
 	int table_size;
@@ -1002,8 +998,8 @@ static void atmel_pmecc_core_init(struct mtd_info *mtd)
 {
 	struct nand_chip *nand_chip = mtd_to_nand(mtd);
 	struct atmel_nand_host *host = nand_get_controller_data(nand_chip);
+	int eccbytes = mtd_ooblayout_count_eccbytes(mtd);
 	uint32_t val = 0;
-	struct nand_ecclayout *ecc_layout;
 	struct mtd_oob_region oobregion;
 
 	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_RST);
@@ -1051,12 +1047,11 @@ static void atmel_pmecc_core_init(struct mtd_info *mtd)
 		| PMECC_CFG_AUTO_DISABLE);
 	pmecc_writel(host->ecc, CFG, val);
 
-	ecc_layout = nand_chip->ecc.layout;
 	pmecc_writel(host->ecc, SAREA, mtd->oobsize - 1);
 	mtd_ooblayout_ecc(mtd, 0, &oobregion);
 	pmecc_writel(host->ecc, SADDR, oobregion.offset);
 	pmecc_writel(host->ecc, EADDR,
-		     oobregion.offset + ecc_layout->eccbytes - 1);
+		     oobregion.offset + eccbytes - 1);
 	/* See datasheet about PMECC Clock Control Register */
 	pmecc_writel(host->ecc, CLK, 2);
 	pmecc_writel(host->ecc, IDR, 0xff);
@@ -1271,11 +1266,8 @@ static int atmel_pmecc_nand_init_params(struct platform_device *pdev,
 			err_no = -EINVAL;
 			goto err;
 		}
-		pmecc_config_ecc_layout(&atmel_pmecc_oobinfo,
-					mtd->oobsize,
-					nand_chip->ecc.total);
 
-		nand_chip->ecc.layout = &atmel_pmecc_oobinfo;
+		mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
 		break;
 	default:
 		dev_warn(host->dev,
@@ -1617,19 +1609,19 @@ static int atmel_hw_nand_init_params(struct platform_device *pdev,
 	/* set ECC page size and oob layout */
 	switch (mtd->writesize) {
 	case 512:
-		nand_chip->ecc.layout = &atmel_oobinfo_small;
+		mtd_set_ooblayout(mtd, &atmel_ooblayout_sp_ops);
 		ecc_writel(host->ecc, MR, ATMEL_ECC_PAGESIZE_528);
 		break;
 	case 1024:
-		nand_chip->ecc.layout = &atmel_oobinfo_large;
+		mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
 		ecc_writel(host->ecc, MR, ATMEL_ECC_PAGESIZE_1056);
 		break;
 	case 2048:
-		nand_chip->ecc.layout = &atmel_oobinfo_large;
+		mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
 		ecc_writel(host->ecc, MR, ATMEL_ECC_PAGESIZE_2112);
 		break;
 	case 4096:
-		nand_chip->ecc.layout = &atmel_oobinfo_large;
+		mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
 		ecc_writel(host->ecc, MR, ATMEL_ECC_PAGESIZE_4224);
 		break;
 	default:
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:46 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:46 +0100
Subject: [PATCH v2 23/51] mtd: nand: sharpsl: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-24-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 arch/arm/mach-pxa/spitz.c   | 55 ++++++++++++++++++++++++++++++++++++---------
 drivers/mtd/nand/sharpsl.c  |  2 +-
 include/linux/mtd/sharpsl.h |  2 +-
 3 files changed, 47 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 825f903..9050a1b 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -763,14 +763,49 @@ static struct nand_bbt_descr spitz_nand_bbt = {
 	.pattern	= scan_ff_pattern
 };
 
-static struct nand_ecclayout akita_oobinfo = {
-	.oobfree	= { {0x08, 0x09} },
-	.eccbytes	= 24,
-	.eccpos		= {
-			0x05, 0x01, 0x02, 0x03, 0x06, 0x07, 0x15, 0x11,
-			0x12, 0x13, 0x16, 0x17, 0x25, 0x21, 0x22, 0x23,
-			0x26, 0x27, 0x35, 0x31, 0x32, 0x33, 0x36, 0x37,
-	},
+static int akita_ooblayout_ecc(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	if (section > 12)
+		return -ERANGE;
+
+	switch (section % 3) {
+	case 0:
+		oobregion->offset = 5;
+		oobregion->length = 1;
+		break;
+
+	case 1:
+		oobregion->offset = 1;
+		oobregion->length = 3;
+		break;
+
+	case 2:
+		oobregion->offset = 6;
+		oobregion->length = 2;
+		break;
+	}
+
+	oobregion->offset += (section / 3) * 0x10;
+
+	return 0;
+}
+
+static int akita_ooblayout_free(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobfree->offset = 8;
+	oobfree->length = 9;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops akita_ooblayout_ops = {
+	.eccpos = akita_ooblayout_ecc,
+	.oobfree = akita_ooblayout_free,
 };
 
 static struct sharpsl_nand_platform_data spitz_nand_pdata = {
@@ -804,11 +839,11 @@ static void __init spitz_nand_init(void)
 	} else if (machine_is_akita()) {
 		spitz_nand_partitions[1].size = 58 * 1024 * 1024;
 		spitz_nand_bbt.len = 1;
-		spitz_nand_pdata.ecc_layout = &akita_oobinfo;
+		spitz_nand_pdata.ecc_layout = &akita_ooblayout_ops;
 	} else if (machine_is_borzoi()) {
 		spitz_nand_partitions[1].size = 32 * 1024 * 1024;
 		spitz_nand_bbt.len = 1;
-		spitz_nand_pdata.ecc_layout = &akita_oobinfo;
+		spitz_nand_pdata.ecc_layout = &akita_ooblayout_ops;
 	}
 
 	platform_device_register(&spitz_nand_device);
diff --git a/drivers/mtd/nand/sharpsl.c b/drivers/mtd/nand/sharpsl.c
index b7d1b55..064ca17 100644
--- a/drivers/mtd/nand/sharpsl.c
+++ b/drivers/mtd/nand/sharpsl.c
@@ -148,6 +148,7 @@ static int sharpsl_nand_probe(struct platform_device *pdev)
 	/* Link the private data with the MTD structure */
 	mtd = nand_to_mtd(this);
 	mtd->dev.parent = &pdev->dev;
+	mtd_set_ooblayout(mtd, data->ecc_layout);
 
 	platform_set_drvdata(pdev, sharpsl);
 
@@ -170,7 +171,6 @@ static int sharpsl_nand_probe(struct platform_device *pdev)
 	this->ecc.bytes = 3;
 	this->ecc.strength = 1;
 	this->badblock_pattern = data->badblock_pattern;
-	this->ecc.layout = data->ecc_layout;
 	this->ecc.hwctl = sharpsl_nand_enable_hwecc;
 	this->ecc.calculate = sharpsl_nand_calculate_ecc;
 	this->ecc.correct = nand_correct_data;
diff --git a/include/linux/mtd/sharpsl.h b/include/linux/mtd/sharpsl.h
index 25f4d2a..65e91d0 100644
--- a/include/linux/mtd/sharpsl.h
+++ b/include/linux/mtd/sharpsl.h
@@ -14,7 +14,7 @@
 
 struct sharpsl_nand_platform_data {
 	struct nand_bbt_descr	*badblock_pattern;
-	struct nand_ecclayout	*ecc_layout;
+	const struct mtd_ooblayout_ops *ecc_layout;
 	struct mtd_partition	*partitions;
 	unsigned int		nr_partitions;
 };
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:06:52 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:06:52 +0100
Subject: [PATCH v2 29/51] mtd: nand: davinci: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-30-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/davinci_nand.c | 118 +++++++++++++++-------------------------
 1 file changed, 44 insertions(+), 74 deletions(-)

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 8cb821b..fe3fd29 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -54,7 +54,6 @@
  */
 struct davinci_nand_info {
 	struct nand_chip	chip;
-	struct nand_ecclayout	ecclayout;
 
 	struct device		*dev;
 	struct clk		*clk;
@@ -480,63 +479,46 @@ static int nand_davinci_dev_ready(struct mtd_info *mtd)
  * ten ECC bytes plus the manufacturer's bad block marker byte, and
  * and not overlapping the default BBT markers.
  */
-static struct nand_ecclayout hwecc4_small = {
-	.eccbytes = 10,
-	.eccpos = { 0, 1, 2, 3, 4,
-		/* offset 5 holds the badblock marker */
-		6, 7,
-		13, 14, 15, },
-	.oobfree = {
-		{.offset = 8, .length = 5, },
-		{.offset = 16, },
-	},
-};
+static int hwecc4_ooblayout_small_ecc(struct mtd_info *mtd, int section,
+				      struct mtd_oob_region *oobregion)
+{
+	if (section > 2)
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 0;
+		oobregion->length = 5;
+	} else if (section == 1) {
+		oobregion->offset = 6;
+		oobregion->length = 2;
+	} else {
+		oobregion->offset = 13;
+		oobregion->length = 3;
+	}
 
-/* An ECC layout for using 4-bit ECC with large-page (2048bytes) flash,
- * storing ten ECC bytes plus the manufacturer's bad block marker byte,
- * and not overlapping the default BBT markers.
- */
-static struct nand_ecclayout hwecc4_2048 = {
-	.eccbytes = 40,
-	.eccpos = {
-		/* at the end of spare sector */
-		24, 25, 26, 27, 28, 29,	30, 31, 32, 33,
-		34, 35, 36, 37, 38, 39,	40, 41, 42, 43,
-		44, 45, 46, 47, 48, 49, 50, 51, 52, 53,
-		54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
-		},
-	.oobfree = {
-		/* 2 bytes at offset 0 hold manufacturer badblock markers */
-		{.offset = 2, .length = 22, },
-		/* 5 bytes at offset 8 hold BBT markers */
-		/* 8 bytes at offset 16 hold JFFS2 clean markers */
-	},
-};
+	return 0;
+}
 
-/*
- * An ECC layout for using 4-bit ECC with large-page (4096bytes) flash,
- * storing ten ECC bytes plus the manufacturer's bad block marker byte,
- * and not overlapping the default BBT markers.
- */
-static struct nand_ecclayout hwecc4_4096 = {
-	.eccbytes = 80,
-	.eccpos = {
-		/* at the end of spare sector */
-		48, 49, 50, 51, 52, 53, 54, 55, 56, 57,
-		58, 59, 60, 61, 62, 63, 64, 65, 66, 67,
-		68, 69, 70, 71, 72, 73, 74, 75, 76, 77,
-		78, 79, 80, 81, 82, 83, 84, 85, 86, 87,
-		88, 89, 90, 91, 92, 93, 94, 95, 96, 97,
-		98, 99, 100, 101, 102, 103, 104, 105, 106, 107,
-		108, 109, 110, 111, 112, 113, 114, 115, 116, 117,
-		118, 119, 120, 121, 122, 123, 124, 125, 126, 127,
-	},
-	.oobfree = {
-		/* 2 bytes at offset 0 hold manufacturer badblock markers */
-		{.offset = 2, .length = 46, },
-		/* 5 bytes at offset 8 hold BBT markers */
-		/* 8 bytes at offset 16 hold JFFS2 clean markers */
-	},
+static int hwecc4_ooblayout_small_free(struct mtd_info *mtd, int section,
+				       struct mtd_oob_region *oobregion)
+{
+	if (section > 1)
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 8;
+		oobregion->length = 5;
+	} else {
+		oobregion->offset = 16;
+		oobregion->length = mtd->oobsize - 16;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops hwecc4_small_ooblayout_ops = {
+	.ecc = hwecc4_ooblayout_small_ecc,
+	.free = hwecc4_ooblayout_small_free,
 };
 
 #if defined(CONFIG_OF)
@@ -805,26 +787,14 @@ static int nand_davinci_probe(struct platform_device *pdev)
 		 * table marker fits in the free bytes.
 		 */
 		if (chunks == 1) {
-			info->ecclayout = hwecc4_small;
-			info->ecclayout.oobfree[1].length = mtd->oobsize - 16;
-			goto syndrome_done;
-		}
-		if (chunks == 4) {
-			info->ecclayout = hwecc4_2048;
+			mtd_set_ooblayout(mtd, &hwecc4_small_ooblayout_ops);
+		} else if (chunks == 4 || chunks == 8) {
+			mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
 			info->chip.ecc.mode = NAND_ECC_HW_OOB_FIRST;
-			goto syndrome_done;
-		}
-		if (chunks == 8) {
-			info->ecclayout = hwecc4_4096;
-			info->chip.ecc.mode = NAND_ECC_HW_OOB_FIRST;
-			goto syndrome_done;
+		} else {
+			ret = -EIO;
+			goto err;
 		}
-
-		ret = -EIO;
-		goto err;
-
-syndrome_done:
-		info->chip.ecc.layout = &info->ecclayout;
 	}
 
 	ret = nand_scan_tail(mtd);
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb  4 02:07:05 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu,  4 Feb 2016 11:07:05 +0100
Subject: [PATCH v2 42/51] mtd: nand: pxa3xx: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1454580434-32078-43-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/pxa3xx_nand.c | 104 +++++++++++++++++++++++++----------------
 1 file changed, 64 insertions(+), 40 deletions(-)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index e42496a..2ce5111 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -296,6 +296,62 @@ static struct pxa3xx_nand_flash builtin_flash_types[] = {
 	{ 0xba20, 16, 16, &timing[3] },
 };
 
+static int pxa3xx_ooblayout_ecc(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct pxa3xx_nand_host *host = nand_get_controller_data(chip);
+	struct pxa3xx_nand_info *info = host->info_data;
+	int nchunks = mtd->writesize / info->chunk_size;
+
+	if (section >= nchunks)
+		return -ERANGE;
+
+	oobregion->offset = ((info->ecc_size + info->spare_size) * section) +
+			    info->spare_size;
+	oobregion->length = info->ecc_size;
+
+	return 0;
+}
+
+static int pxa3xx_ooblayout_free(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct pxa3xx_nand_host *host = nand_get_controller_data(chip);
+	struct pxa3xx_nand_info *info = host->info_data;
+	int nchunks = mtd->writesize / info->chunk_size;
+
+	if (section >= nchunks)
+		return -ERANGE;
+
+	if (!info->spare_size)
+		return 0;
+
+	oobregion->offset = section * (info->ecc_size + info->spare_size);
+	oobregion->length = info->spare_size;
+	if (!section) {
+		/*
+		 * Bootrom looks in bytes 0 & 5 for bad blocks for the
+		 * 4KB page / 4bit BCH combination.
+		 */
+		if (mtd->writesize == 4096 && info->chunk_size == 2048) {
+			oobregion->offset += 6;
+			oobregion->length -= 6;
+		} else {
+			oobregion->offset += 2;
+			oobregion->length -= 2;
+		}
+	}
+
+	return 0;
+}
+
+const struct mtd_ooblayout_ops pxa3xx_ooblayout_ops = {
+	.ecc = pxa3xx_ooblayout_ecc,
+	.free = pxa3xx_ooblayout_free,
+};
+
 static u8 bbt_pattern[] = {'M', 'V', 'B', 'b', 't', '0' };
 static u8 bbt_mirror_pattern[] = {'1', 't', 'b', 'B', 'V', 'M' };
 
@@ -319,41 +375,6 @@ static struct nand_bbt_descr bbt_mirror_descr = {
 	.pattern = bbt_mirror_pattern
 };
 
-static struct nand_ecclayout ecc_layout_2KB_bch4bit = {
-	.eccbytes = 32,
-	.eccpos = {
-		32, 33, 34, 35, 36, 37, 38, 39,
-		40, 41, 42, 43, 44, 45, 46, 47,
-		48, 49, 50, 51, 52, 53, 54, 55,
-		56, 57, 58, 59, 60, 61, 62, 63},
-	.oobfree = { {2, 30} }
-};
-
-static struct nand_ecclayout ecc_layout_4KB_bch4bit = {
-	.eccbytes = 64,
-	.eccpos = {
-		32,  33,  34,  35,  36,  37,  38,  39,
-		40,  41,  42,  43,  44,  45,  46,  47,
-		48,  49,  50,  51,  52,  53,  54,  55,
-		56,  57,  58,  59,  60,  61,  62,  63,
-		96,  97,  98,  99,  100, 101, 102, 103,
-		104, 105, 106, 107, 108, 109, 110, 111,
-		112, 113, 114, 115, 116, 117, 118, 119,
-		120, 121, 122, 123, 124, 125, 126, 127},
-	/* Bootrom looks in bytes 0 & 5 for bad blocks */
-	.oobfree = { {6, 26}, { 64, 32} }
-};
-
-static struct nand_ecclayout ecc_layout_4KB_bch8bit = {
-	.eccbytes = 128,
-	.eccpos = {
-		32,  33,  34,  35,  36,  37,  38,  39,
-		40,  41,  42,  43,  44,  45,  46,  47,
-		48,  49,  50,  51,  52,  53,  54,  55,
-		56,  57,  58,  59,  60,  61,  62,  63},
-	.oobfree = { }
-};
-
 #define NDTR0_tCH(c)	(min((c), 7) << 19)
 #define NDTR0_tCS(c)	(min((c), 7) << 16)
 #define NDTR0_tWH(c)	(min((c), 7) << 11)
@@ -1514,9 +1535,12 @@ static void pxa3xx_nand_free_buff(struct pxa3xx_nand_info *info)
 }
 
 static int pxa_ecc_init(struct pxa3xx_nand_info *info,
-			struct nand_ecc_ctrl *ecc,
+			struct mtd_info *mtd,
 			int strength, int ecc_stepsize, int page_size)
 {
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct nand_ecc_ctrl *ecc = &chip->ecc;
+
 	if (strength == 1 && ecc_stepsize == 512 && page_size == 2048) {
 		info->chunk_size = 2048;
 		info->spare_size = 40;
@@ -1544,7 +1568,7 @@ static int pxa_ecc_init(struct pxa3xx_nand_info *info,
 		info->ecc_size = 32;
 		ecc->mode = NAND_ECC_HW;
 		ecc->size = info->chunk_size;
-		ecc->layout = &ecc_layout_2KB_bch4bit;
+		mtd_set_ooblayout(mtd, &pxa3xx_ooblayout_ops);
 		ecc->strength = 16;
 
 	} else if (strength == 4 && ecc_stepsize == 512 && page_size == 4096) {
@@ -1554,7 +1578,7 @@ static int pxa_ecc_init(struct pxa3xx_nand_info *info,
 		info->ecc_size = 32;
 		ecc->mode = NAND_ECC_HW;
 		ecc->size = info->chunk_size;
-		ecc->layout = &ecc_layout_4KB_bch4bit;
+		mtd_set_ooblayout(mtd, &pxa3xx_ooblayout_ops);
 		ecc->strength = 16;
 
 	/*
@@ -1568,7 +1592,7 @@ static int pxa_ecc_init(struct pxa3xx_nand_info *info,
 		info->ecc_size = 32;
 		ecc->mode = NAND_ECC_HW;
 		ecc->size = info->chunk_size;
-		ecc->layout = &ecc_layout_4KB_bch8bit;
+		mtd_set_ooblayout(mtd, &pxa3xx_ooblayout_ops);
 		ecc->strength = 16;
 	} else {
 		dev_err(&info->pdev->dev,
@@ -1659,7 +1683,7 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
 		ecc_step = 512;
 	}
 
-	ret = pxa_ecc_init(info, &chip->ecc, ecc_strength,
+	ret = pxa_ecc_init(info, mtd, ecc_strength,
 			   ecc_step, mtd->writesize);
 	if (ret)
 		return ret;
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:19 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:19 +0000
Subject: [PATCH v2 02/28] ARM: KVM: Remove
 __kvm_hyp_code_start/__kvm_hyp_code_end
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-3-git-send-email-marc.zyngier@arm.com>

Now that we've unified the way we refer to the HYP text between
arm and arm64, drop __kvm_hyp_code_start/end, and just use the
__hyp_text_start/end symbols.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_asm.h   | 3 ---
 arch/arm/kvm/arm.c               | 2 +-
 arch/arm64/include/asm/kvm_asm.h | 3 ---
 3 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index fa2fd25..4841225 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -93,9 +93,6 @@ extern char __kvm_hyp_exit_end[];
 
 extern char __kvm_hyp_vector[];
 
-#define	__kvm_hyp_code_start	__hyp_text_start
-#define __kvm_hyp_code_end	__hyp_text_end
-
 extern void __kvm_flush_vm_context(void);
 extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
 extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 6b76e01..fcf6c13 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -1075,7 +1075,7 @@ static int init_hyp_mode(void)
 	/*
 	 * Map the Hyp-code called directly from the host
 	 */
-	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
+	err = create_hyp_mappings(__hyp_text_start, __hyp_text_end);
 	if (err) {
 		kvm_err("Cannot map world-switch code\n");
 		goto out_free_mappings;
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 52b777b..2ad8930 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -35,9 +35,6 @@ extern char __kvm_hyp_init_end[];
 
 extern char __kvm_hyp_vector[];
 
-#define	__kvm_hyp_code_start	__hyp_text_start
-#define	__kvm_hyp_code_end	__hyp_text_end
-
 extern void __kvm_flush_vm_context(void);
 extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
 extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:23 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:23 +0000
Subject: [PATCH v2 06/28] ARM: KVM: Add a HYP-specific header file
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-7-git-send-email-marc.zyngier@arm.com>

In order to expose the various HYP services that are private to
the hypervisor, add a new hyp.h file.

So far, it only contains mundane things such as section annotation
and VA manipulation.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/hyp/hyp.h | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 arch/arm/kvm/hyp/hyp.h

diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
new file mode 100644
index 0000000..c723870
--- /dev/null
+++ b/arch/arm/kvm/hyp/hyp.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2015 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.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/>.
+ */
+
+#ifndef __ARM_KVM_HYP_H__
+#define __ARM_KVM_HYP_H__
+
+#include <linux/compiler.h>
+#include <linux/kvm_host.h>
+#include <asm/kvm_mmu.h>
+
+#define __hyp_text __section(.hyp.text) notrace
+
+#define kern_hyp_va(v) (v)
+#define hyp_kern_va(v) (v)
+
+#endif /* __ARM_KVM_HYP_H__ */
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:22 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:22 +0000
Subject: [PATCH v2 05/28] ARM: KVM: Move GP registers into the CPU context
 structure
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-6-git-send-email-marc.zyngier@arm.com>

Continuing our rework of the CPU context, we now move the GP
registers into the CPU context structure.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_emulate.h |  8 ++++----
 arch/arm/include/asm/kvm_host.h    |  3 +--
 arch/arm/kernel/asm-offsets.c      | 18 +++++++++---------
 arch/arm/kvm/emulate.c             | 12 ++++++------
 arch/arm/kvm/guest.c               |  4 ++--
 arch/arm/kvm/interrupts_head.S     | 11 +++++++++++
 arch/arm/kvm/reset.c               |  2 +-
 7 files changed, 34 insertions(+), 24 deletions(-)

diff --git a/arch/arm/include/asm/kvm_emulate.h b/arch/arm/include/asm/kvm_emulate.h
index 32bb52a..f710616 100644
--- a/arch/arm/include/asm/kvm_emulate.h
+++ b/arch/arm/include/asm/kvm_emulate.h
@@ -68,12 +68,12 @@ static inline bool vcpu_mode_is_32bit(struct kvm_vcpu *vcpu)
 
 static inline unsigned long *vcpu_pc(struct kvm_vcpu *vcpu)
 {
-	return &vcpu->arch.regs.usr_regs.ARM_pc;
+	return &vcpu->arch.ctxt.gp_regs.usr_regs.ARM_pc;
 }
 
 static inline unsigned long *vcpu_cpsr(struct kvm_vcpu *vcpu)
 {
-	return &vcpu->arch.regs.usr_regs.ARM_cpsr;
+	return &vcpu->arch.ctxt.gp_regs.usr_regs.ARM_cpsr;
 }
 
 static inline void vcpu_set_thumb(struct kvm_vcpu *vcpu)
@@ -83,13 +83,13 @@ static inline void vcpu_set_thumb(struct kvm_vcpu *vcpu)
 
 static inline bool mode_has_spsr(struct kvm_vcpu *vcpu)
 {
-	unsigned long cpsr_mode = vcpu->arch.regs.usr_regs.ARM_cpsr & MODE_MASK;
+	unsigned long cpsr_mode = vcpu->arch.ctxt.gp_regs.usr_regs.ARM_cpsr & MODE_MASK;
 	return (cpsr_mode > USR_MODE && cpsr_mode < SYSTEM_MODE);
 }
 
 static inline bool vcpu_mode_priv(struct kvm_vcpu *vcpu)
 {
-	unsigned long cpsr_mode = vcpu->arch.regs.usr_regs.ARM_cpsr & MODE_MASK;
+	unsigned long cpsr_mode = vcpu->arch.ctxt.gp_regs.usr_regs.ARM_cpsr & MODE_MASK;
 	return cpsr_mode > USR_MODE;;
 }
 
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 4203701..02932ba 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -89,6 +89,7 @@ struct kvm_vcpu_fault_info {
 };
 
 struct kvm_cpu_context {
+	struct kvm_regs	gp_regs;
 	struct vfp_hard_struct vfp;
 	u32 cp15[NR_CP15_REGS];
 };
@@ -98,8 +99,6 @@ typedef struct kvm_cpu_context kvm_cpu_context_t;
 struct kvm_vcpu_arch {
 	struct kvm_cpu_context ctxt;
 
-	struct kvm_regs regs;
-
 	int target; /* Processor target */
 	DECLARE_BITMAP(features, KVM_VCPU_MAX_FEATURES);
 
diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
index 43f8b01..2f3e0b0 100644
--- a/arch/arm/kernel/asm-offsets.c
+++ b/arch/arm/kernel/asm-offsets.c
@@ -176,15 +176,15 @@ int main(void)
   DEFINE(VCPU_HOST_CTXT,	offsetof(struct kvm_vcpu, arch.host_cpu_context));
   DEFINE(CPU_CTXT_VFP,		offsetof(struct kvm_cpu_context, vfp));
   DEFINE(CPU_CTXT_CP15,		offsetof(struct kvm_cpu_context, cp15));
-  DEFINE(VCPU_REGS,		offsetof(struct kvm_vcpu, arch.regs));
-  DEFINE(VCPU_USR_REGS,		offsetof(struct kvm_vcpu, arch.regs.usr_regs));
-  DEFINE(VCPU_SVC_REGS,		offsetof(struct kvm_vcpu, arch.regs.svc_regs));
-  DEFINE(VCPU_ABT_REGS,		offsetof(struct kvm_vcpu, arch.regs.abt_regs));
-  DEFINE(VCPU_UND_REGS,		offsetof(struct kvm_vcpu, arch.regs.und_regs));
-  DEFINE(VCPU_IRQ_REGS,		offsetof(struct kvm_vcpu, arch.regs.irq_regs));
-  DEFINE(VCPU_FIQ_REGS,		offsetof(struct kvm_vcpu, arch.regs.fiq_regs));
-  DEFINE(VCPU_PC,		offsetof(struct kvm_vcpu, arch.regs.usr_regs.ARM_pc));
-  DEFINE(VCPU_CPSR,		offsetof(struct kvm_vcpu, arch.regs.usr_regs.ARM_cpsr));
+  DEFINE(CPU_CTXT_GP_REGS,	offsetof(struct kvm_cpu_context, gp_regs));
+  DEFINE(GP_REGS_USR,		offsetof(struct kvm_regs, usr_regs));
+  DEFINE(GP_REGS_SVC,		offsetof(struct kvm_regs, svc_regs));
+  DEFINE(GP_REGS_ABT,		offsetof(struct kvm_regs, abt_regs));
+  DEFINE(GP_REGS_UND,		offsetof(struct kvm_regs, und_regs));
+  DEFINE(GP_REGS_IRQ,		offsetof(struct kvm_regs, irq_regs));
+  DEFINE(GP_REGS_FIQ,		offsetof(struct kvm_regs, fiq_regs));
+  DEFINE(GP_REGS_PC,		offsetof(struct kvm_regs, usr_regs.ARM_pc));
+  DEFINE(GP_REGS_CPSR,		offsetof(struct kvm_regs, usr_regs.ARM_cpsr));
   DEFINE(VCPU_HCR,		offsetof(struct kvm_vcpu, arch.hcr));
   DEFINE(VCPU_IRQ_LINES,	offsetof(struct kvm_vcpu, arch.irq_lines));
   DEFINE(VCPU_HSR,		offsetof(struct kvm_vcpu, arch.fault.hsr));
diff --git a/arch/arm/kvm/emulate.c b/arch/arm/kvm/emulate.c
index ee161b1..a494def 100644
--- a/arch/arm/kvm/emulate.c
+++ b/arch/arm/kvm/emulate.c
@@ -112,7 +112,7 @@ static const unsigned long vcpu_reg_offsets[VCPU_NR_MODES][15] = {
  */
 unsigned long *vcpu_reg(struct kvm_vcpu *vcpu, u8 reg_num)
 {
-	unsigned long *reg_array = (unsigned long *)&vcpu->arch.regs;
+	unsigned long *reg_array = (unsigned long *)&vcpu->arch.ctxt.gp_regs;
 	unsigned long mode = *vcpu_cpsr(vcpu) & MODE_MASK;
 
 	switch (mode) {
@@ -147,15 +147,15 @@ unsigned long *vcpu_spsr(struct kvm_vcpu *vcpu)
 	unsigned long mode = *vcpu_cpsr(vcpu) & MODE_MASK;
 	switch (mode) {
 	case SVC_MODE:
-		return &vcpu->arch.regs.KVM_ARM_SVC_spsr;
+		return &vcpu->arch.ctxt.gp_regs.KVM_ARM_SVC_spsr;
 	case ABT_MODE:
-		return &vcpu->arch.regs.KVM_ARM_ABT_spsr;
+		return &vcpu->arch.ctxt.gp_regs.KVM_ARM_ABT_spsr;
 	case UND_MODE:
-		return &vcpu->arch.regs.KVM_ARM_UND_spsr;
+		return &vcpu->arch.ctxt.gp_regs.KVM_ARM_UND_spsr;
 	case IRQ_MODE:
-		return &vcpu->arch.regs.KVM_ARM_IRQ_spsr;
+		return &vcpu->arch.ctxt.gp_regs.KVM_ARM_IRQ_spsr;
 	case FIQ_MODE:
-		return &vcpu->arch.regs.KVM_ARM_FIQ_spsr;
+		return &vcpu->arch.ctxt.gp_regs.KVM_ARM_FIQ_spsr;
 	default:
 		BUG();
 	}
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index 5fa69d7..86e26fb 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -55,7 +55,7 @@ static u64 core_reg_offset_from_id(u64 id)
 static int get_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 {
 	u32 __user *uaddr = (u32 __user *)(long)reg->addr;
-	struct kvm_regs *regs = &vcpu->arch.regs;
+	struct kvm_regs *regs = &vcpu->arch.ctxt.gp_regs;
 	u64 off;
 
 	if (KVM_REG_SIZE(reg->id) != 4)
@@ -72,7 +72,7 @@ static int get_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 static int set_core_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 {
 	u32 __user *uaddr = (u32 __user *)(long)reg->addr;
-	struct kvm_regs *regs = &vcpu->arch.regs;
+	struct kvm_regs *regs = &vcpu->arch.ctxt.gp_regs;
 	u64 off, val;
 
 	if (KVM_REG_SIZE(reg->id) != 4)
diff --git a/arch/arm/kvm/interrupts_head.S b/arch/arm/kvm/interrupts_head.S
index b9d9531..e0943cb8 100644
--- a/arch/arm/kvm/interrupts_head.S
+++ b/arch/arm/kvm/interrupts_head.S
@@ -1,6 +1,17 @@
 #include <linux/irqchip/arm-gic.h>
 #include <asm/assembler.h>
 
+/* Compat macro, until we get rid of this file entierely */
+#define VCPU_GP_REGS		(VCPU_GUEST_CTXT + CPU_CTXT_GP_REGS)
+#define VCPU_USR_REGS		(VCPU_GP_REGS + GP_REGS_USR)
+#define VCPU_SVC_REGS		(VCPU_GP_REGS + GP_REGS_SVC)
+#define VCPU_ABT_REGS		(VCPU_GP_REGS + GP_REGS_ABT)
+#define VCPU_UND_REGS		(VCPU_GP_REGS + GP_REGS_UND)
+#define VCPU_IRQ_REGS		(VCPU_GP_REGS + GP_REGS_IRQ)
+#define VCPU_FIQ_REGS		(VCPU_GP_REGS + GP_REGS_FIQ)
+#define VCPU_PC			(VCPU_GP_REGS + GP_REGS_PC)
+#define VCPU_CPSR		(VCPU_GP_REGS + GP_REGS_CPSR)
+
 #define VCPU_USR_REG(_reg_nr)	(VCPU_USR_REGS + (_reg_nr * 4))
 #define VCPU_USR_SP		(VCPU_USR_REG(13))
 #define VCPU_USR_LR		(VCPU_USR_REG(14))
diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
index eeb85858..0048b5a 100644
--- a/arch/arm/kvm/reset.c
+++ b/arch/arm/kvm/reset.c
@@ -71,7 +71,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 	}
 
 	/* Reset core registers */
-	memcpy(&vcpu->arch.regs, reset_regs, sizeof(vcpu->arch.regs));
+	memcpy(&vcpu->arch.ctxt.gp_regs, reset_regs, sizeof(vcpu->arch.ctxt.gp_regs));
 
 	/* Reset CP15 registers */
 	kvm_reset_coprocs(vcpu);
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:30 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:30 +0000
Subject: [PATCH v2 13/28] ARM: KVM: Add banked registers save/restore
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-14-git-send-email-marc.zyngier@arm.com>

Banked registers are one of the many perks of the 32bit architecture,
and the world switch needs to cope with it.

This requires some "special" accessors, as these are not accessed
using a standard coprocessor instruction.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/hyp/Makefile    |  1 +
 arch/arm/kvm/hyp/banked-sr.c | 77 ++++++++++++++++++++++++++++++++++++++++++++
 arch/arm/kvm/hyp/hyp.h       | 11 +++++++
 3 files changed, 89 insertions(+)
 create mode 100644 arch/arm/kvm/hyp/banked-sr.c

diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
index 5a45f4c..173bd1d 100644
--- a/arch/arm/kvm/hyp/Makefile
+++ b/arch/arm/kvm/hyp/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_KVM_ARM_HOST) += cp15-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += timer-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += vgic-v2-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += vfp.o
+obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o
diff --git a/arch/arm/kvm/hyp/banked-sr.c b/arch/arm/kvm/hyp/banked-sr.c
new file mode 100644
index 0000000..d02dc80
--- /dev/null
+++ b/arch/arm/kvm/hyp/banked-sr.c
@@ -0,0 +1,77 @@
+/*
+ * Original code:
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall at virtualopensystems.com>
+ *
+ * Mostly rewritten in C by Marc Zyngier <marc.zyngier at arm.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 "hyp.h"
+
+__asm__(".arch_extension     virt");
+
+void __hyp_text __banked_save_state(struct kvm_cpu_context *ctxt)
+{
+	ctxt->gp_regs.usr_regs.ARM_sp	= read_special(SP_usr);
+	ctxt->gp_regs.usr_regs.ARM_pc	= read_special(ELR_hyp);
+	ctxt->gp_regs.usr_regs.ARM_cpsr	= read_special(SPSR);
+	ctxt->gp_regs.KVM_ARM_SVC_sp	= read_special(SP_svc);
+	ctxt->gp_regs.KVM_ARM_SVC_lr	= read_special(LR_svc);
+	ctxt->gp_regs.KVM_ARM_SVC_spsr	= read_special(SPSR_svc);
+	ctxt->gp_regs.KVM_ARM_ABT_sp	= read_special(SP_abt);
+	ctxt->gp_regs.KVM_ARM_ABT_lr	= read_special(LR_abt);
+	ctxt->gp_regs.KVM_ARM_ABT_spsr	= read_special(SPSR_abt);
+	ctxt->gp_regs.KVM_ARM_UND_sp	= read_special(SP_und);
+	ctxt->gp_regs.KVM_ARM_UND_lr	= read_special(LR_und);
+	ctxt->gp_regs.KVM_ARM_UND_spsr	= read_special(SPSR_und);
+	ctxt->gp_regs.KVM_ARM_IRQ_sp	= read_special(SP_irq);
+	ctxt->gp_regs.KVM_ARM_IRQ_lr	= read_special(LR_irq);
+	ctxt->gp_regs.KVM_ARM_IRQ_spsr	= read_special(SPSR_irq);
+	ctxt->gp_regs.KVM_ARM_FIQ_r8	= read_special(R8_fiq);
+	ctxt->gp_regs.KVM_ARM_FIQ_r9	= read_special(R9_fiq);
+	ctxt->gp_regs.KVM_ARM_FIQ_r10	= read_special(R10_fiq);
+	ctxt->gp_regs.KVM_ARM_FIQ_fp	= read_special(R11_fiq);
+	ctxt->gp_regs.KVM_ARM_FIQ_ip	= read_special(R12_fiq);
+	ctxt->gp_regs.KVM_ARM_FIQ_sp	= read_special(SP_fiq);
+	ctxt->gp_regs.KVM_ARM_FIQ_lr	= read_special(LR_fiq);
+	ctxt->gp_regs.KVM_ARM_FIQ_spsr	= read_special(SPSR_fiq);
+}
+
+void __hyp_text __banked_restore_state(struct kvm_cpu_context *ctxt)
+{
+	write_special(ctxt->gp_regs.usr_regs.ARM_sp,	SP_usr);
+	write_special(ctxt->gp_regs.usr_regs.ARM_pc,	ELR_hyp);
+	write_special(ctxt->gp_regs.usr_regs.ARM_cpsr,	SPSR_cxsf);
+	write_special(ctxt->gp_regs.KVM_ARM_SVC_sp,	SP_svc);
+	write_special(ctxt->gp_regs.KVM_ARM_SVC_lr,	LR_svc);
+	write_special(ctxt->gp_regs.KVM_ARM_SVC_spsr,	SPSR_svc);
+	write_special(ctxt->gp_regs.KVM_ARM_ABT_sp,	SP_abt);
+	write_special(ctxt->gp_regs.KVM_ARM_ABT_lr,	LR_abt);
+	write_special(ctxt->gp_regs.KVM_ARM_ABT_spsr,	SPSR_abt);
+	write_special(ctxt->gp_regs.KVM_ARM_UND_sp,	SP_und);
+	write_special(ctxt->gp_regs.KVM_ARM_UND_lr,	LR_und);
+	write_special(ctxt->gp_regs.KVM_ARM_UND_spsr,	SPSR_und);
+	write_special(ctxt->gp_regs.KVM_ARM_IRQ_sp,	SP_irq);
+	write_special(ctxt->gp_regs.KVM_ARM_IRQ_lr,	LR_irq);
+	write_special(ctxt->gp_regs.KVM_ARM_IRQ_spsr,	SPSR_irq);
+	write_special(ctxt->gp_regs.KVM_ARM_FIQ_r8,	R8_fiq);
+	write_special(ctxt->gp_regs.KVM_ARM_FIQ_r9,	R9_fiq);
+	write_special(ctxt->gp_regs.KVM_ARM_FIQ_r10,	R10_fiq);
+	write_special(ctxt->gp_regs.KVM_ARM_FIQ_fp,	R11_fiq);
+	write_special(ctxt->gp_regs.KVM_ARM_FIQ_ip,	R12_fiq);
+	write_special(ctxt->gp_regs.KVM_ARM_FIQ_sp,	SP_fiq);
+	write_special(ctxt->gp_regs.KVM_ARM_FIQ_lr,	LR_fiq);
+	write_special(ctxt->gp_regs.KVM_ARM_FIQ_spsr,	SPSR_fiq);
+}
diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
index dce0f73..278eb1f 100644
--- a/arch/arm/kvm/hyp/hyp.h
+++ b/arch/arm/kvm/hyp/hyp.h
@@ -45,6 +45,14 @@
 })
 #define read_sysreg(...)		__read_sysreg(__VA_ARGS__)
 
+#define write_special(v, r)					\
+	asm volatile("msr " __stringify(r) ", %0" : : "r" (v))
+#define read_special(r) ({					\
+	u32 __val;						\
+	asm volatile("mrs %0, " __stringify(r) : "=r" (__val));	\
+	__val;							\
+})
+
 #define TTBR0		__ACCESS_CP15_64(0, c2)
 #define TTBR1		__ACCESS_CP15_64(1, c2)
 #define VTTBR		__ACCESS_CP15_64(6, c2)
@@ -99,4 +107,7 @@ static inline bool __vfp_enabled(void)
 	return !(read_sysreg(HCPTR) & (HCPTR_TCP(11) | HCPTR_TCP(10)));
 }
 
+void __hyp_text __banked_save_state(struct kvm_cpu_context *ctxt);
+void __hyp_text __banked_restore_state(struct kvm_cpu_context *ctxt);
+
 #endif /* __ARM_KVM_HYP_H__ */
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:25 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:25 +0000
Subject: [PATCH v2 08/28] ARM: KVM: Add TLB invalidation code
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-9-git-send-email-marc.zyngier@arm.com>

Convert the TLB invalidation code to C, hooking it into the
build system whilst we're at it.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/Makefile     |  1 +
 arch/arm/kvm/hyp/Makefile |  5 ++++
 arch/arm/kvm/hyp/hyp.h    |  5 ++++
 arch/arm/kvm/hyp/tlb.c    | 71 +++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 82 insertions(+)
 create mode 100644 arch/arm/kvm/hyp/Makefile
 create mode 100644 arch/arm/kvm/hyp/tlb.c

diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
index c5eef02c..eb1bf43 100644
--- a/arch/arm/kvm/Makefile
+++ b/arch/arm/kvm/Makefile
@@ -17,6 +17,7 @@ AFLAGS_interrupts.o := -Wa,-march=armv7-a$(plus_virt)
 KVM := ../../../virt/kvm
 kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o $(KVM)/vfio.o
 
+obj-$(CONFIG_KVM_ARM_HOST) += hyp/
 obj-y += kvm-arm.o init.o interrupts.o
 obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o
 obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o
diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
new file mode 100644
index 0000000..36c760d
--- /dev/null
+++ b/arch/arm/kvm/hyp/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for Kernel-based Virtual Machine module, HYP part
+#
+
+obj-$(CONFIG_KVM_ARM_HOST) += tlb.o
diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
index 727089f..5808bbd 100644
--- a/arch/arm/kvm/hyp/hyp.h
+++ b/arch/arm/kvm/hyp/hyp.h
@@ -42,4 +42,9 @@
 })
 #define read_sysreg(...)		__read_sysreg(__VA_ARGS__)
 
+#define VTTBR		__ACCESS_CP15_64(6, c2)
+#define ICIALLUIS	__ACCESS_CP15(c7, 0, c1, 0)
+#define TLBIALLIS	__ACCESS_CP15(c8, 0, c3, 0)
+#define TLBIALLNSNHIS	__ACCESS_CP15(c8, 4, c3, 4)
+
 #endif /* __ARM_KVM_HYP_H__ */
diff --git a/arch/arm/kvm/hyp/tlb.c b/arch/arm/kvm/hyp/tlb.c
new file mode 100644
index 0000000..993fe89
--- /dev/null
+++ b/arch/arm/kvm/hyp/tlb.c
@@ -0,0 +1,71 @@
+/*
+ * Original code:
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall at virtualopensystems.com>
+ *
+ * Mostly rewritten in C by Marc Zyngier <marc.zyngier at arm.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 "hyp.h"
+
+/**
+ * Flush per-VMID TLBs
+ *
+ * __kvm_tlb_flush_vmid(struct kvm *kvm);
+ *
+ * We rely on the hardware to broadcast the TLB invalidation to all CPUs
+ * inside the inner-shareable domain (which is the case for all v7
+ * implementations).  If we come across a non-IS SMP implementation, we'll
+ * have to use an IPI based mechanism. Until then, we stick to the simple
+ * hardware assisted version.
+ *
+ * As v7 does not support flushing per IPA, just nuke the whole TLB
+ * instead, ignoring the ipa value.
+ */
+static void __hyp_text __tlb_flush_vmid(struct kvm *kvm)
+{
+	dsb(ishst);
+
+	/* Switch to requested VMID */
+	kvm = kern_hyp_va(kvm);
+	write_sysreg(kvm->arch.vttbr, VTTBR);
+	isb();
+
+	write_sysreg(0, TLBIALLIS);
+	dsb(ish);
+	isb();
+
+	write_sysreg(0, VTTBR);
+}
+
+__alias(__tlb_flush_vmid) void __weak __kvm_tlb_flush_vmid(struct kvm *kvm);
+
+static void __hyp_text __tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
+{
+	__tlb_flush_vmid(kvm);
+}
+
+__alias(__tlb_flush_vmid_ipa) void __weak __kvm_tlb_flush_vmid_ipa(struct kvm *kvm,
+							    phys_addr_t ipa);
+
+static void __hyp_text __tlb_flush_vm_context(void)
+{
+	dsb(ishst);
+	write_sysreg(0, TLBIALLNSNHIS);
+	write_sysreg(0, ICIALLUIS);
+	dsb(ish);
+}
+
+__alias(__tlb_flush_vm_context) void __weak __kvm_flush_vm_context(void);
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:20 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:20 +0000
Subject: [PATCH v2 03/28] ARM: KVM: Move VFP registers to a CPU context
 structure
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-4-git-send-email-marc.zyngier@arm.com>

In order to turn the WS code into something that looks a bit
more like the arm64 version, move the VFP registers into a
CPU context container for both the host and the guest.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_host.h | 11 +++++++----
 arch/arm/kernel/asm-offsets.c   |  5 +++--
 arch/arm/kvm/coproc.c           | 20 ++++++++++----------
 arch/arm/kvm/interrupts.S       | 10 ++++++----
 4 files changed, 26 insertions(+), 20 deletions(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index f1e86f1..b64ac8e 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -88,9 +88,15 @@ struct kvm_vcpu_fault_info {
 	u32 hyp_pc;		/* PC when exception was taken from Hyp mode */
 };
 
-typedef struct vfp_hard_struct kvm_cpu_context_t;
+struct kvm_cpu_context {
+	struct vfp_hard_struct vfp;
+};
+
+typedef struct kvm_cpu_context kvm_cpu_context_t;
 
 struct kvm_vcpu_arch {
+	struct kvm_cpu_context ctxt;
+
 	struct kvm_regs regs;
 
 	int target; /* Processor target */
@@ -111,9 +117,6 @@ struct kvm_vcpu_arch {
 	/* Exception Information */
 	struct kvm_vcpu_fault_info fault;
 
-	/* Floating point registers (VFP and Advanced SIMD/NEON) */
-	struct vfp_hard_struct vfp_guest;
-
 	/* Host FP context */
 	kvm_cpu_context_t *host_cpu_context;
 
diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
index 871b826..346bfca 100644
--- a/arch/arm/kernel/asm-offsets.c
+++ b/arch/arm/kernel/asm-offsets.c
@@ -173,8 +173,9 @@ int main(void)
   DEFINE(VCPU_KVM,		offsetof(struct kvm_vcpu, kvm));
   DEFINE(VCPU_MIDR,		offsetof(struct kvm_vcpu, arch.midr));
   DEFINE(VCPU_CP15,		offsetof(struct kvm_vcpu, arch.cp15));
-  DEFINE(VCPU_VFP_GUEST,	offsetof(struct kvm_vcpu, arch.vfp_guest));
-  DEFINE(VCPU_VFP_HOST,		offsetof(struct kvm_vcpu, arch.host_cpu_context));
+  DEFINE(VCPU_GUEST_CTXT,	offsetof(struct kvm_vcpu, arch.ctxt));
+  DEFINE(VCPU_HOST_CTXT,	offsetof(struct kvm_vcpu, arch.host_cpu_context));
+  DEFINE(CPU_CTXT_VFP,		offsetof(struct kvm_cpu_context, vfp));
   DEFINE(VCPU_REGS,		offsetof(struct kvm_vcpu, arch.regs));
   DEFINE(VCPU_USR_REGS,		offsetof(struct kvm_vcpu, arch.regs.usr_regs));
   DEFINE(VCPU_SVC_REGS,		offsetof(struct kvm_vcpu, arch.regs.svc_regs));
diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index f3d88dc..1a643f3 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -901,7 +901,7 @@ static int vfp_get_reg(const struct kvm_vcpu *vcpu, u64 id, void __user *uaddr)
 	if (vfpid < num_fp_regs()) {
 		if (KVM_REG_SIZE(id) != 8)
 			return -ENOENT;
-		return reg_to_user(uaddr, &vcpu->arch.vfp_guest.fpregs[vfpid],
+		return reg_to_user(uaddr, &vcpu->arch.ctxt.vfp.fpregs[vfpid],
 				   id);
 	}
 
@@ -911,13 +911,13 @@ static int vfp_get_reg(const struct kvm_vcpu *vcpu, u64 id, void __user *uaddr)
 
 	switch (vfpid) {
 	case KVM_REG_ARM_VFP_FPEXC:
-		return reg_to_user(uaddr, &vcpu->arch.vfp_guest.fpexc, id);
+		return reg_to_user(uaddr, &vcpu->arch.ctxt.vfp.fpexc, id);
 	case KVM_REG_ARM_VFP_FPSCR:
-		return reg_to_user(uaddr, &vcpu->arch.vfp_guest.fpscr, id);
+		return reg_to_user(uaddr, &vcpu->arch.ctxt.vfp.fpscr, id);
 	case KVM_REG_ARM_VFP_FPINST:
-		return reg_to_user(uaddr, &vcpu->arch.vfp_guest.fpinst, id);
+		return reg_to_user(uaddr, &vcpu->arch.ctxt.vfp.fpinst, id);
 	case KVM_REG_ARM_VFP_FPINST2:
-		return reg_to_user(uaddr, &vcpu->arch.vfp_guest.fpinst2, id);
+		return reg_to_user(uaddr, &vcpu->arch.ctxt.vfp.fpinst2, id);
 	case KVM_REG_ARM_VFP_MVFR0:
 		val = fmrx(MVFR0);
 		return reg_to_user(uaddr, &val, id);
@@ -945,7 +945,7 @@ static int vfp_set_reg(struct kvm_vcpu *vcpu, u64 id, const void __user *uaddr)
 	if (vfpid < num_fp_regs()) {
 		if (KVM_REG_SIZE(id) != 8)
 			return -ENOENT;
-		return reg_from_user(&vcpu->arch.vfp_guest.fpregs[vfpid],
+		return reg_from_user(&vcpu->arch.ctxt.vfp.fpregs[vfpid],
 				     uaddr, id);
 	}
 
@@ -955,13 +955,13 @@ static int vfp_set_reg(struct kvm_vcpu *vcpu, u64 id, const void __user *uaddr)
 
 	switch (vfpid) {
 	case KVM_REG_ARM_VFP_FPEXC:
-		return reg_from_user(&vcpu->arch.vfp_guest.fpexc, uaddr, id);
+		return reg_from_user(&vcpu->arch.ctxt.vfp.fpexc, uaddr, id);
 	case KVM_REG_ARM_VFP_FPSCR:
-		return reg_from_user(&vcpu->arch.vfp_guest.fpscr, uaddr, id);
+		return reg_from_user(&vcpu->arch.ctxt.vfp.fpscr, uaddr, id);
 	case KVM_REG_ARM_VFP_FPINST:
-		return reg_from_user(&vcpu->arch.vfp_guest.fpinst, uaddr, id);
+		return reg_from_user(&vcpu->arch.ctxt.vfp.fpinst, uaddr, id);
 	case KVM_REG_ARM_VFP_FPINST2:
-		return reg_from_user(&vcpu->arch.vfp_guest.fpinst2, uaddr, id);
+		return reg_from_user(&vcpu->arch.ctxt.vfp.fpinst2, uaddr, id);
 	/* These are invariant. */
 	case KVM_REG_ARM_VFP_MVFR0:
 		if (reg_from_user(&val, uaddr, id))
diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index 9d9cb71..7bfb289 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -172,10 +172,11 @@ __kvm_vcpu_return:
 
 #ifdef CONFIG_VFPv3
 	@ Switch VFP/NEON hardware state to the host's
-	add	r7, vcpu, #VCPU_VFP_GUEST
+	add	r7, vcpu, #(VCPU_GUEST_CTXT + CPU_CTXT_VFP)
 	store_vfp_state r7
-	add	r7, vcpu, #VCPU_VFP_HOST
+	add	r7, vcpu, #VCPU_HOST_CTXT
 	ldr	r7, [r7]
+	add	r7, r7, #CPU_CTXT_VFP
 	restore_vfp_state r7
 
 after_vfp_restore:
@@ -482,10 +483,11 @@ switch_to_guest_vfp:
 	set_hcptr vmtrap, (HCPTR_TCP(10) | HCPTR_TCP(11))
 
 	@ Switch VFP/NEON hardware state to the guest's
-	add	r7, r0, #VCPU_VFP_HOST
+	add	r7, r0, #VCPU_HOST_CTXT
 	ldr	r7, [r7]
+	add	r7, r7, #CPU_CTXT_VFP
 	store_vfp_state r7
-	add	r7, r0, #VCPU_VFP_GUEST
+	add	r7, r0, #(VCPU_GUEST_CTXT + CPU_CTXT_VFP)
 	restore_vfp_state r7
 
 	pop	{r3-r7}
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:28 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:28 +0000
Subject: [PATCH v2 11/28] ARM: KVM: Add vgic v2 save/restore
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-12-git-send-email-marc.zyngier@arm.com>

This patch shouldn't exist, as we should be able to reuse the
arm64 version for free. I'll get there eventually, but in the
meantime I need an interrupt controller.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/hyp/Makefile     |  1 +
 arch/arm/kvm/hyp/hyp.h        |  3 ++
 arch/arm/kvm/hyp/vgic-v2-sr.c | 84 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 88 insertions(+)
 create mode 100644 arch/arm/kvm/hyp/vgic-v2-sr.c

diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
index 9241ae8..d8acbb6 100644
--- a/arch/arm/kvm/hyp/Makefile
+++ b/arch/arm/kvm/hyp/Makefile
@@ -5,3 +5,4 @@
 obj-$(CONFIG_KVM_ARM_HOST) += tlb.o
 obj-$(CONFIG_KVM_ARM_HOST) += cp15-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += timer-sr.o
+obj-$(CONFIG_KVM_ARM_HOST) += vgic-v2-sr.o
diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
index 4924418..7eb1c21 100644
--- a/arch/arm/kvm/hyp/hyp.h
+++ b/arch/arm/kvm/hyp/hyp.h
@@ -80,6 +80,9 @@
 void __timer_save_state(struct kvm_vcpu *vcpu);
 void __timer_restore_state(struct kvm_vcpu *vcpu);
 
+void __vgic_v2_save_state(struct kvm_vcpu *vcpu);
+void __vgic_v2_restore_state(struct kvm_vcpu *vcpu);
+
 void __sysreg_save_state(struct kvm_cpu_context *ctxt);
 void __sysreg_restore_state(struct kvm_cpu_context *ctxt);
 
diff --git a/arch/arm/kvm/hyp/vgic-v2-sr.c b/arch/arm/kvm/hyp/vgic-v2-sr.c
new file mode 100644
index 0000000..e717612
--- /dev/null
+++ b/arch/arm/kvm/hyp/vgic-v2-sr.c
@@ -0,0 +1,84 @@
+/*
+ * Copyright (C) 2012-2015 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.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/compiler.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/kvm_host.h>
+
+#include <asm/kvm_mmu.h>
+
+#include "hyp.h"
+
+/* vcpu is already in the HYP VA space */
+void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
+{
+	struct kvm *kvm = kern_hyp_va(vcpu->kvm);
+	struct vgic_v2_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v2;
+	struct vgic_dist *vgic = &kvm->arch.vgic;
+	void __iomem *base = kern_hyp_va(vgic->vctrl_base);
+	u32 eisr0, eisr1, elrsr0, elrsr1;
+	int i, nr_lr;
+
+	if (!base)
+		return;
+
+	nr_lr = vcpu->arch.vgic_cpu.nr_lr;
+	cpu_if->vgic_vmcr = readl_relaxed(base + GICH_VMCR);
+	cpu_if->vgic_misr = readl_relaxed(base + GICH_MISR);
+	eisr0  = readl_relaxed(base + GICH_EISR0);
+	elrsr0 = readl_relaxed(base + GICH_ELRSR0);
+	if (unlikely(nr_lr > 32)) {
+		eisr1  = readl_relaxed(base + GICH_EISR1);
+		elrsr1 = readl_relaxed(base + GICH_ELRSR1);
+	} else {
+		eisr1 = elrsr1 = 0;
+	}
+#ifdef CONFIG_CPU_BIG_ENDIAN
+	cpu_if->vgic_eisr  = ((u64)eisr0 << 32) | eisr1;
+	cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
+#else
+	cpu_if->vgic_eisr  = ((u64)eisr1 << 32) | eisr0;
+	cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
+#endif
+	cpu_if->vgic_apr    = readl_relaxed(base + GICH_APR);
+
+	writel_relaxed(0, base + GICH_HCR);
+
+	for (i = 0; i < nr_lr; i++)
+		cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
+}
+
+/* vcpu is already in the HYP VA space */
+void __hyp_text __vgic_v2_restore_state(struct kvm_vcpu *vcpu)
+{
+	struct kvm *kvm = kern_hyp_va(vcpu->kvm);
+	struct vgic_v2_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v2;
+	struct vgic_dist *vgic = &kvm->arch.vgic;
+	void __iomem *base = kern_hyp_va(vgic->vctrl_base);
+	int i, nr_lr;
+
+	if (!base)
+		return;
+
+	writel_relaxed(cpu_if->vgic_hcr, base + GICH_HCR);
+	writel_relaxed(cpu_if->vgic_vmcr, base + GICH_VMCR);
+	writel_relaxed(cpu_if->vgic_apr, base + GICH_APR);
+
+	nr_lr = vcpu->arch.vgic_cpu.nr_lr;
+	for (i = 0; i < nr_lr; i++)
+		writel_relaxed(cpu_if->vgic_lr[i], base + GICH_LR0 + (i * 4));
+}
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:24 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:24 +0000
Subject: [PATCH v2 07/28] ARM: KVM: Add system register accessor macros
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-8-git-send-email-marc.zyngier@arm.com>

In order to move system register (CP15, mostly) access to C code,
add a few macros to facilitate this, and minimize the difference
between 32 and 64bit CP15 registers.

This will get heavily used in the following patches.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/hyp/hyp.h | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
index c723870..727089f 100644
--- a/arch/arm/kvm/hyp/hyp.h
+++ b/arch/arm/kvm/hyp/hyp.h
@@ -27,4 +27,19 @@
 #define kern_hyp_va(v) (v)
 #define hyp_kern_va(v) (v)
 
+#define __ACCESS_CP15(CRn, Op1, CRm, Op2)	\
+	"mrc", "mcr", __stringify(p15, Op1, %0, CRn, CRm, Op2), u32
+#define __ACCESS_CP15_64(Op1, CRm)		\
+	"mrrc", "mcrr", __stringify(p15, Op1, %Q0, %R0, CRm), u64
+
+#define __write_sysreg(v, r, w, c, t)	asm volatile(w " " c : : "r" ((t)(v)))
+#define write_sysreg(v, ...)		__write_sysreg(v, __VA_ARGS__)
+
+#define __read_sysreg(r, w, c, t) ({				\
+	t __val;						\
+	asm volatile(r " " c : "=r" (__val));			\
+	__val;							\
+})
+#define read_sysreg(...)		__read_sysreg(__VA_ARGS__)
+
 #endif /* __ARM_KVM_HYP_H__ */
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:33 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:33 +0000
Subject: [PATCH v2 16/28] ARM: KVM: Add the new world switch implementation
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-17-git-send-email-marc.zyngier@arm.com>

The new world switch implementation is modeled after the arm64 one,
calling the various save/restore functions in turn, and having as
little state as possible.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/hyp/Makefile |   1 +
 arch/arm/kvm/hyp/hyp.h    |   7 +++
 arch/arm/kvm/hyp/switch.c | 136 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 144 insertions(+)
 create mode 100644 arch/arm/kvm/hyp/switch.c

diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
index c779690..cfab402 100644
--- a/arch/arm/kvm/hyp/Makefile
+++ b/arch/arm/kvm/hyp/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_KVM_ARM_HOST) += vgic-v2-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += vfp.o
 obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += entry.o
+obj-$(CONFIG_KVM_ARM_HOST) += switch.o
diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
index b3f6ed2..2ca651f 100644
--- a/arch/arm/kvm/hyp/hyp.h
+++ b/arch/arm/kvm/hyp/hyp.h
@@ -60,11 +60,16 @@
 #define CNTV_CVAL	__ACCESS_CP15_64(3, c14)
 #define CNTVOFF		__ACCESS_CP15_64(4, c14)
 
+#define MIDR		__ACCESS_CP15(c0, 0, c0, 0)
 #define CSSELR		__ACCESS_CP15(c0, 2, c0, 0)
+#define VMIDR		__ACCESS_CP15(c0, 4, c0, 0)
 #define VMPIDR		__ACCESS_CP15(c0, 4, c0, 5)
 #define SCTLR		__ACCESS_CP15(c1, 0, c0, 0)
 #define CPACR		__ACCESS_CP15(c1, 0, c0, 2)
+#define HCR		__ACCESS_CP15(c1, 4, c1, 0)
+#define HDCR		__ACCESS_CP15(c1, 4, c1, 1)
 #define HCPTR		__ACCESS_CP15(c1, 4, c1, 2)
+#define HSTR		__ACCESS_CP15(c1, 4, c1, 3)
 #define TTBCR		__ACCESS_CP15(c2, 0, c0, 2)
 #define DACR		__ACCESS_CP15(c3, 0, c0, 0)
 #define DFSR		__ACCESS_CP15(c5, 0, c0, 0)
@@ -73,6 +78,7 @@
 #define AIFSR		__ACCESS_CP15(c5, 0, c1, 1)
 #define DFAR		__ACCESS_CP15(c6, 0, c0, 0)
 #define IFAR		__ACCESS_CP15(c6, 0, c0, 2)
+#define HDFAR		__ACCESS_CP15(c6, 4, c0, 0)
 #define ICIALLUIS	__ACCESS_CP15(c7, 0, c1, 0)
 #define TLBIALLIS	__ACCESS_CP15(c8, 0, c3, 0)
 #define TLBIALLNSNHIS	__ACCESS_CP15(c8, 4, c3, 4)
@@ -85,6 +91,7 @@
 #define TID_URW		__ACCESS_CP15(c13, 0, c0, 2)
 #define TID_URO		__ACCESS_CP15(c13, 0, c0, 3)
 #define TID_PRIV	__ACCESS_CP15(c13, 0, c0, 4)
+#define HTPIDR		__ACCESS_CP15(c13, 4, c0, 2)
 #define CNTKCTL		__ACCESS_CP15(c14, 0, c1, 0)
 #define CNTV_CTL	__ACCESS_CP15(c14, 0, c3, 1)
 #define CNTHCTL		__ACCESS_CP15(c14, 4, c1, 0)
diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
new file mode 100644
index 0000000..f715b0d
--- /dev/null
+++ b/arch/arm/kvm/hyp/switch.c
@@ -0,0 +1,136 @@
+/*
+ * Copyright (C) 2015 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.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 <asm/kvm_asm.h>
+#include "hyp.h"
+
+__asm__(".arch_extension     virt");
+
+static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu, u32 *fpexc)
+{
+	u32 val;
+
+	/*
+	 * We are about to set HCPTR.TCP10/11 to trap all floating point
+	 * register accesses to HYP, however, the ARM ARM clearly states that
+	 * traps are only taken to HYP if the operation would not otherwise
+	 * trap to SVC.  Therefore, always make sure that for 32-bit guests,
+	 * we set FPEXC.EN to prevent traps to SVC, when setting the TCP bits.
+	 */
+	val = read_sysreg(VFP_FPEXC);
+	*fpexc = val;
+	if (!(val & FPEXC_EN)) {
+		write_sysreg(val | FPEXC_EN, VFP_FPEXC);
+		isb();
+	}
+
+	write_sysreg(vcpu->arch.hcr | vcpu->arch.irq_lines, HCR);
+	/* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
+	write_sysreg(HSTR_T(15), HSTR);
+	write_sysreg(HCPTR_TTA | HCPTR_TCP(10) | HCPTR_TCP(11), HCPTR);
+	val = read_sysreg(HDCR);
+	write_sysreg(val | HDCR_TPM | HDCR_TPMCR, HDCR);
+}
+
+static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
+{
+	u32 val;
+
+	write_sysreg(0, HCR);
+	write_sysreg(0, HSTR);
+	val = read_sysreg(HDCR);
+	write_sysreg(val & ~(HDCR_TPM | HDCR_TPMCR), HDCR);
+	write_sysreg(0, HCPTR);
+}
+
+static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
+{
+	struct kvm *kvm = kern_hyp_va(vcpu->kvm);
+	write_sysreg(kvm->arch.vttbr, VTTBR);
+	write_sysreg(vcpu->arch.midr, VMIDR);
+}
+
+static void __hyp_text __deactivate_vm(struct kvm_vcpu *vcpu)
+{
+	write_sysreg(0, VTTBR);
+	write_sysreg(read_sysreg(MIDR), VMIDR);
+}
+
+static void __hyp_text __vgic_save_state(struct kvm_vcpu *vcpu)
+{
+	__vgic_v2_save_state(vcpu);
+}
+
+static void __hyp_text __vgic_restore_state(struct kvm_vcpu *vcpu)
+{
+	__vgic_v2_restore_state(vcpu);
+}
+
+static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
+{
+	struct kvm_cpu_context *host_ctxt;
+	struct kvm_cpu_context *guest_ctxt;
+	bool fp_enabled;
+	u64 exit_code;
+	u32 fpexc;
+
+	vcpu = kern_hyp_va(vcpu);
+	write_sysreg(vcpu, HTPIDR);
+
+	host_ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
+	guest_ctxt = &vcpu->arch.ctxt;
+
+	__sysreg_save_state(host_ctxt);
+	__banked_save_state(host_ctxt);
+
+	__activate_traps(vcpu, &fpexc);
+	__activate_vm(vcpu);
+
+	__vgic_restore_state(vcpu);
+	__timer_restore_state(vcpu);
+
+	__sysreg_restore_state(guest_ctxt);
+	__banked_restore_state(guest_ctxt);
+
+	/* Jump in the fire! */
+	exit_code = __guest_enter(vcpu, host_ctxt);
+	/* And we're baaack! */
+
+	fp_enabled = __vfp_enabled();
+
+	__banked_save_state(guest_ctxt);
+	__sysreg_save_state(guest_ctxt);
+	__timer_save_state(vcpu);
+	__vgic_save_state(vcpu);
+
+	__deactivate_traps(vcpu);
+	__deactivate_vm(vcpu);
+
+	__banked_restore_state(host_ctxt);
+	__sysreg_restore_state(host_ctxt);
+
+	if (fp_enabled) {
+		__vfp_save_state(&guest_ctxt->vfp);
+		__vfp_restore_state(&host_ctxt->vfp);
+	}
+
+	write_sysreg(fpexc, VFP_FPEXC);
+
+	return exit_code;
+}
+
+__alias(__guest_run) int __weak __kvm_vcpu_run(struct kvm_vcpu *vcpu);
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:39 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:39 +0000
Subject: [PATCH v2 22/28] ARM: KVM: Switch to C-based stage2 init
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-23-git-send-email-marc.zyngier@arm.com>

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_asm.h  |  2 ++
 arch/arm/include/asm/kvm_host.h |  1 +
 arch/arm/kvm/hyp/Makefile       |  1 +
 arch/arm/kvm/hyp/hyp.h          |  2 ++
 arch/arm/kvm/hyp/s2-setup.c     | 34 ++++++++++++++++++++++++++++++++++
 arch/arm/kvm/init.S             |  8 --------
 6 files changed, 40 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/kvm/hyp/s2-setup.c

diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index 4841225..3283a2f 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -98,6 +98,8 @@ extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
 extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
 
 extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
+
+extern void __init_stage2_translation(void);
 #endif
 
 #endif /* __ARM_KVM_ASM_H__ */
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index c62d717..0fe41aa 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -224,6 +224,7 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
 
 static inline void __cpu_init_stage2(void)
 {
+	kvm_call_hyp(__init_stage2_translation);
 }
 
 static inline int kvm_arch_dev_ioctl_check_extension(long ext)
diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
index a7d3a7e..7152369 100644
--- a/arch/arm/kvm/hyp/Makefile
+++ b/arch/arm/kvm/hyp/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += entry.o
 obj-$(CONFIG_KVM_ARM_HOST) += hyp-entry.o
 obj-$(CONFIG_KVM_ARM_HOST) += switch.o
+obj-$(CONFIG_KVM_ARM_HOST) += s2-setup.o
diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
index 8bbd2a7..73bf9e3 100644
--- a/arch/arm/kvm/hyp/hyp.h
+++ b/arch/arm/kvm/hyp/hyp.h
@@ -71,6 +71,8 @@
 #define HCPTR		__ACCESS_CP15(c1, 4, c1, 2)
 #define HSTR		__ACCESS_CP15(c1, 4, c1, 3)
 #define TTBCR		__ACCESS_CP15(c2, 0, c0, 2)
+#define HTCR		__ACCESS_CP15(c2, 4, c0, 2)
+#define VTCR		__ACCESS_CP15(c2, 4, c1, 2)
 #define DACR		__ACCESS_CP15(c3, 0, c0, 0)
 #define DFSR		__ACCESS_CP15(c5, 0, c0, 0)
 #define IFSR		__ACCESS_CP15(c5, 0, c0, 1)
diff --git a/arch/arm/kvm/hyp/s2-setup.c b/arch/arm/kvm/hyp/s2-setup.c
new file mode 100644
index 0000000..f5f49c5
--- /dev/null
+++ b/arch/arm/kvm/hyp/s2-setup.c
@@ -0,0 +1,34 @@
+/*
+ * Copyright (C) 2016 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.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/types.h>
+#include <asm/kvm_arm.h>
+#include <asm/kvm_asm.h>
+
+#include "hyp.h"
+
+void __hyp_text __init_stage2_translation(void)
+{
+	u64 val;
+
+	val = read_sysreg(VTCR) & ~VTCR_MASK;
+
+	val |= read_sysreg(HTCR) & VTCR_HTCR_SH;
+	val |= KVM_VTCR_SL0 | KVM_VTCR_T0SZ | KVM_VTCR_S;
+
+	write_sysreg(val, VTCR);
+}
diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
index 3988e72..1f9ae17 100644
--- a/arch/arm/kvm/init.S
+++ b/arch/arm/kvm/init.S
@@ -84,14 +84,6 @@ __do_hyp_init:
 	orr	r0, r0, r1
 	mcr	p15, 4, r0, c2, c0, 2	@ HTCR
 
-	mrc	p15, 4, r1, c2, c1, 2	@ VTCR
-	ldr	r2, =VTCR_MASK
-	bic	r1, r1, r2
-	bic	r0, r0, #(~VTCR_HTCR_SH)	@ clear non-reusable HTCR bits
-	orr	r1, r0, r1
-	orr	r1, r1, #(KVM_VTCR_SL0 | KVM_VTCR_T0SZ | KVM_VTCR_S)
-	mcr	p15, 4, r1, c2, c1, 2	@ VTCR
-
 	@ Use the same memory attributes for hyp. accesses as the kernel
 	@ (copy MAIRx ro HMAIRx).
 	mrc	p15, 0, r0, c10, c2, 0
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:41 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:41 +0000
Subject: [PATCH v2 24/28] ARM: KVM: Turn CP15 defines to an enum
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-25-git-send-email-marc.zyngier@arm.com>

Just like on arm64, having the CP15 registers expressed as a set
of #defines has been very conflict-prone. Let's turn it into an
enum, which should make it more manageable.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_asm.h  | 33 ---------------------------------
 arch/arm/include/asm/kvm_host.h | 39 +++++++++++++++++++++++++++++++++++++++
 arch/arm/kvm/guest.c            |  1 -
 3 files changed, 39 insertions(+), 34 deletions(-)

diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index 3283a2f..083825f 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -21,39 +21,6 @@
 
 #include <asm/virt.h>
 
-/* 0 is reserved as an invalid value. */
-#define c0_MPIDR	1	/* MultiProcessor ID Register */
-#define c0_CSSELR	2	/* Cache Size Selection Register */
-#define c1_SCTLR	3	/* System Control Register */
-#define c1_ACTLR	4	/* Auxiliary Control Register */
-#define c1_CPACR	5	/* Coprocessor Access Control */
-#define c2_TTBR0	6	/* Translation Table Base Register 0 */
-#define c2_TTBR0_high	7	/* TTBR0 top 32 bits */
-#define c2_TTBR1	8	/* Translation Table Base Register 1 */
-#define c2_TTBR1_high	9	/* TTBR1 top 32 bits */
-#define c2_TTBCR	10	/* Translation Table Base Control R. */
-#define c3_DACR		11	/* Domain Access Control Register */
-#define c5_DFSR		12	/* Data Fault Status Register */
-#define c5_IFSR		13	/* Instruction Fault Status Register */
-#define c5_ADFSR	14	/* Auxilary Data Fault Status R */
-#define c5_AIFSR	15	/* Auxilary Instrunction Fault Status R */
-#define c6_DFAR		16	/* Data Fault Address Register */
-#define c6_IFAR		17	/* Instruction Fault Address Register */
-#define c7_PAR		18	/* Physical Address Register */
-#define c7_PAR_high	19	/* PAR top 32 bits */
-#define c9_L2CTLR	20	/* Cortex A15/A7 L2 Control Register */
-#define c10_PRRR	21	/* Primary Region Remap Register */
-#define c10_NMRR	22	/* Normal Memory Remap Register */
-#define c12_VBAR	23	/* Vector Base Address Register */
-#define c13_CID		24	/* Context ID Register */
-#define c13_TID_URW	25	/* Thread ID, User R/W */
-#define c13_TID_URO	26	/* Thread ID, User R/O */
-#define c13_TID_PRIV	27	/* Thread ID, Privileged */
-#define c14_CNTKCTL	28	/* Timer Control Register (PL1) */
-#define c10_AMAIR0	29	/* Auxilary Memory Attribute Indirection Reg0 */
-#define c10_AMAIR1	30	/* Auxilary Memory Attribute Indirection Reg1 */
-#define NR_CP15_REGS	31	/* Number of regs (incl. invalid) */
-
 #define ARM_EXCEPTION_RESET	  0
 #define ARM_EXCEPTION_UNDEFINED   1
 #define ARM_EXCEPTION_SOFTWARE    2
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 0fe41aa..daf6a71 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -88,6 +88,45 @@ struct kvm_vcpu_fault_info {
 	u32 hyp_pc;		/* PC when exception was taken from Hyp mode */
 };
 
+/*
+ * 0 is reserved as an invalid value.
+ * Order should be kept in sync with the save/restore code.
+ */
+enum vcpu_sysreg {
+	__INVALID_SYSREG__,
+	c0_MPIDR,		/* MultiProcessor ID Register */
+	c0_CSSELR,		/* Cache Size Selection Register */
+	c1_SCTLR,		/* System Control Register */
+	c1_ACTLR,		/* Auxiliary Control Register */
+	c1_CPACR,		/* Coprocessor Access Control */
+	c2_TTBR0,		/* Translation Table Base Register 0 */
+	c2_TTBR0_high,		/* TTBR0 top 32 bits */
+	c2_TTBR1,		/* Translation Table Base Register 1 */
+	c2_TTBR1_high,		/* TTBR1 top 32 bits */
+	c2_TTBCR,		/* Translation Table Base Control R. */
+	c3_DACR,		/* Domain Access Control Register */
+	c5_DFSR,		/* Data Fault Status Register */
+	c5_IFSR,		/* Instruction Fault Status Register */
+	c5_ADFSR,		/* Auxilary Data Fault Status R */
+	c5_AIFSR,		/* Auxilary Instrunction Fault Status R */
+	c6_DFAR,		/* Data Fault Address Register */
+	c6_IFAR,		/* Instruction Fault Address Register */
+	c7_PAR,			/* Physical Address Register */
+	c7_PAR_high,		/* PAR top 32 bits */
+	c9_L2CTLR,		/* Cortex A15/A7 L2 Control Register */
+	c10_PRRR,		/* Primary Region Remap Register */
+	c10_NMRR,		/* Normal Memory Remap Register */
+	c12_VBAR,		/* Vector Base Address Register */
+	c13_CID,		/* Context ID Register */
+	c13_TID_URW,		/* Thread ID, User R/W */
+	c13_TID_URO,		/* Thread ID, User R/O */
+	c13_TID_PRIV,		/* Thread ID, Privileged */
+	c14_CNTKCTL,		/* Timer Control Register (PL1) */
+	c10_AMAIR0,		/* Auxilary Memory Attribute Indirection Reg0 */
+	c10_AMAIR1,		/* Auxilary Memory Attribute Indirection Reg1 */
+	NR_CP15_REGS		/* Number of regs (incl. invalid) */
+};
+
 struct kvm_cpu_context {
 	struct kvm_regs	gp_regs;
 	struct vfp_hard_struct vfp;
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index 86e26fb..12cbb68 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -25,7 +25,6 @@
 #include <asm/cputype.h>
 #include <asm/uaccess.h>
 #include <asm/kvm.h>
-#include <asm/kvm_asm.h>
 #include <asm/kvm_emulate.h>
 #include <asm/kvm_coproc.h>
 
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:43 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:43 +0000
Subject: [PATCH v2 26/28] ARM: KVM: Remove unused hyp_pc field
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-27-git-send-email-marc.zyngier@arm.com>

This field was never populated, and the panic code already
does something similar. Delete the related code.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_emulate.h | 5 -----
 arch/arm/include/asm/kvm_host.h    | 1 -
 arch/arm/kernel/asm-offsets.c      | 1 -
 arch/arm/kvm/handle_exit.c         | 5 -----
 4 files changed, 12 deletions(-)

diff --git a/arch/arm/include/asm/kvm_emulate.h b/arch/arm/include/asm/kvm_emulate.h
index f710616..8a8c6de 100644
--- a/arch/arm/include/asm/kvm_emulate.h
+++ b/arch/arm/include/asm/kvm_emulate.h
@@ -108,11 +108,6 @@ static inline phys_addr_t kvm_vcpu_get_fault_ipa(struct kvm_vcpu *vcpu)
 	return ((phys_addr_t)vcpu->arch.fault.hpfar & HPFAR_MASK) << 8;
 }
 
-static inline unsigned long kvm_vcpu_get_hyp_pc(struct kvm_vcpu *vcpu)
-{
-	return vcpu->arch.fault.hyp_pc;
-}
-
 static inline bool kvm_vcpu_dabt_isvalid(struct kvm_vcpu *vcpu)
 {
 	return kvm_vcpu_get_hsr(vcpu) & HSR_ISV;
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index daf6a71..19e9aba 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -85,7 +85,6 @@ struct kvm_vcpu_fault_info {
 	u32 hsr;		/* Hyp Syndrome Register */
 	u32 hxfar;		/* Hyp Data/Inst. Fault Address Register */
 	u32 hpfar;		/* Hyp IPA Fault Address Register */
-	u32 hyp_pc;		/* PC when exception was taken from Hyp mode */
 };
 
 /*
diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
index 1f24c32..27d0581 100644
--- a/arch/arm/kernel/asm-offsets.c
+++ b/arch/arm/kernel/asm-offsets.c
@@ -175,7 +175,6 @@ int main(void)
   DEFINE(CPU_CTXT_VFP,		offsetof(struct kvm_cpu_context, vfp));
   DEFINE(CPU_CTXT_GP_REGS,	offsetof(struct kvm_cpu_context, gp_regs));
   DEFINE(GP_REGS_USR,		offsetof(struct kvm_regs, usr_regs));
-  DEFINE(VCPU_HYP_PC,		offsetof(struct kvm_vcpu, arch.fault.hyp_pc));
 #endif
   BLANK();
 #ifdef CONFIG_VDSO
diff --git a/arch/arm/kvm/handle_exit.c b/arch/arm/kvm/handle_exit.c
index 3ede90d..5377d753 100644
--- a/arch/arm/kvm/handle_exit.c
+++ b/arch/arm/kvm/handle_exit.c
@@ -147,11 +147,6 @@ int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
 	switch (exception_index) {
 	case ARM_EXCEPTION_IRQ:
 		return 1;
-	case ARM_EXCEPTION_UNDEFINED:
-		kvm_err("Undefined exception in Hyp mode at: %#08lx\n",
-			kvm_vcpu_get_hyp_pc(vcpu));
-		BUG();
-		panic("KVM: Hypervisor undefined exception!\n");
 	case ARM_EXCEPTION_DATA_ABORT:
 	case ARM_EXCEPTION_PREF_ABORT:
 	case ARM_EXCEPTION_HVC:
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:32 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:32 +0000
Subject: [PATCH v2 15/28] ARM: KVM: Add VFP lazy save/restore handler
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-16-git-send-email-marc.zyngier@arm.com>

Similar to the arm64 version, add the code that deals with VFP traps,
re-enabling VFP, save/restoring the registers and resuming the guest.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/hyp/entry.S | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/kvm/hyp/entry.S b/arch/arm/kvm/hyp/entry.S
index 32f79b0..21c2388 100644
--- a/arch/arm/kvm/hyp/entry.S
+++ b/arch/arm/kvm/hyp/entry.S
@@ -66,5 +66,36 @@ ENTRY(__guest_exit)
 	bx	lr
 ENDPROC(__guest_exit)
 
+/*
+ * If VFPv3 support is not available, then we will not switch the VFP
+ * registers; however cp10 and cp11 accesses will still trap and fallback
+ * to the regular coprocessor emulation code, which currently will
+ * inject an undefined exception to the guest.
+ */
+#ifdef CONFIG_VFPv3
+ENTRY(__vfp_guest_restore)
+	push	{r3, r4, lr}
+
+	@ NEON/VFP used.  Turn on VFP access.
+	mrc	p15, 4, r1, c1, c1, 2		@ HCPTR
+	bic	r1, r1, #(HCPTR_TCP(10) | HCPTR_TCP(11))
+	mcr	p15, 4, r1, c1, c1, 2		@ HCPTR
+	isb
+
+	@ Switch VFP/NEON hardware state to the guest's
+	mov	r4, r0
+	ldr	r0, [r0, #VCPU_HOST_CTXT]
+	add	r0, r0, #CPU_CTXT_VFP
+	bl	__vfp_save_state
+	add	r0, r4, #(VCPU_GUEST_CTXT + CPU_CTXT_VFP)
+	bl	__vfp_restore_state
+
+	pop	{r3, r4, lr}
+	pop	{r0, r1, r2}
+	clrex
+	eret
+ENDPROC(__vfp_guest_restore)
+#endif
+
 	.popsection
 
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:37 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:37 +0000
Subject: [PATCH v2 20/28] ARM: KVM: Change kvm_call_hyp return type to
 unsigned long
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-21-git-send-email-marc.zyngier@arm.com>

Having u64 as the kvm_call_hyp return type is problematic, as
it forces all kind of tricks for the return values from HYP
to be promoted to 64bit (LE has the LSB in r0, and BE has them
in r1).

Since the only user of the return value is perfectly happy with
a 32bit value, let's make kvm_call_hyp return an unsigned long,
which is 32bit on ARM.

This solves yet another headache.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_host.h |  2 +-
 arch/arm/kvm/interrupts.S       | 10 ++--------
 2 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 02932ba..c62d717 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -165,7 +165,7 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
 int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
 int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
 int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
-u64 kvm_call_hyp(void *hypfn, ...);
+unsigned long kvm_call_hyp(void *hypfn, ...);
 void force_vm_exit(const cpumask_t *mask);
 
 #define KVM_ARCH_WANT_MMU_NOTIFIER
diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index 7bfb289..01eb169 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -207,20 +207,14 @@ after_vfp_restore:
 
 	restore_host_regs
 	clrex				@ Clear exclusive monitor
-#ifndef CONFIG_CPU_ENDIAN_BE8
 	mov	r0, r1			@ Return the return code
-	mov	r1, #0			@ Clear upper bits in return value
-#else
-	@ r1 already has return code
-	mov	r0, #0			@ Clear upper bits in return value
-#endif /* CONFIG_CPU_ENDIAN_BE8 */
 	bx	lr			@ return to IOCTL
 
 /********************************************************************
  *  Call function in Hyp mode
  *
  *
- * u64 kvm_call_hyp(void *hypfn, ...);
+ * unsigned long kvm_call_hyp(void *hypfn, ...);
  *
  * This is not really a variadic function in the classic C-way and care must
  * be taken when calling this to ensure parameters are passed in registers
@@ -231,7 +225,7 @@ after_vfp_restore:
  * passed as r0, r1, and r2 (a maximum of 3 arguments in addition to the
  * function pointer can be passed).  The function being called must be mapped
  * in Hyp mode (see init_hyp_mode in arch/arm/kvm/arm.c).  Return values are
- * passed in r0 and r1.
+ * passed in r0 (strictly 32bit).
  *
  * A function pointer with a value of 0xffffffff has a special meaning,
  * and is used to implement __hyp_get_vectors in the same way as in
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:26 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:26 +0000
Subject: [PATCH v2 09/28] ARM: KVM: Add CP15 save/restore code
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-10-git-send-email-marc.zyngier@arm.com>

Concert the CP15 save/restore code to C.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/hyp/Makefile  |  1 +
 arch/arm/kvm/hyp/cp15-sr.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm/kvm/hyp/hyp.h     | 28 ++++++++++++++++
 3 files changed, 113 insertions(+)
 create mode 100644 arch/arm/kvm/hyp/cp15-sr.c

diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
index 36c760d..9f96fcb 100644
--- a/arch/arm/kvm/hyp/Makefile
+++ b/arch/arm/kvm/hyp/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_KVM_ARM_HOST) += tlb.o
+obj-$(CONFIG_KVM_ARM_HOST) += cp15-sr.o
diff --git a/arch/arm/kvm/hyp/cp15-sr.c b/arch/arm/kvm/hyp/cp15-sr.c
new file mode 100644
index 0000000..732abbc
--- /dev/null
+++ b/arch/arm/kvm/hyp/cp15-sr.c
@@ -0,0 +1,84 @@
+/*
+ * Original code:
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall at virtualopensystems.com>
+ *
+ * Mostly rewritten in C by Marc Zyngier <marc.zyngier at arm.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 "hyp.h"
+
+static u64 *cp15_64(struct kvm_cpu_context *ctxt, int idx)
+{
+	return (u64 *)(ctxt->cp15 + idx);
+}
+
+void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
+{
+	ctxt->cp15[c0_MPIDR]		= read_sysreg(VMPIDR);
+	ctxt->cp15[c0_CSSELR]		= read_sysreg(CSSELR);
+	ctxt->cp15[c1_SCTLR]		= read_sysreg(SCTLR);
+	ctxt->cp15[c1_CPACR]		= read_sysreg(CPACR);
+	*cp15_64(ctxt, c2_TTBR0)	= read_sysreg(TTBR0);
+	*cp15_64(ctxt, c2_TTBR1)	= read_sysreg(TTBR1);
+	ctxt->cp15[c2_TTBCR]		= read_sysreg(TTBCR);
+	ctxt->cp15[c3_DACR]		= read_sysreg(DACR);
+	ctxt->cp15[c5_DFSR]		= read_sysreg(DFSR);
+	ctxt->cp15[c5_IFSR]		= read_sysreg(IFSR);
+	ctxt->cp15[c5_ADFSR]		= read_sysreg(ADFSR);
+	ctxt->cp15[c5_AIFSR]		= read_sysreg(AIFSR);
+	ctxt->cp15[c6_DFAR]		= read_sysreg(DFAR);
+	ctxt->cp15[c6_IFAR]		= read_sysreg(IFAR);
+	*cp15_64(ctxt, c7_PAR)		= read_sysreg(PAR);
+	ctxt->cp15[c10_PRRR]		= read_sysreg(PRRR);
+	ctxt->cp15[c10_NMRR]		= read_sysreg(NMRR);
+	ctxt->cp15[c10_AMAIR0]		= read_sysreg(AMAIR0);
+	ctxt->cp15[c10_AMAIR1]		= read_sysreg(AMAIR1);
+	ctxt->cp15[c12_VBAR]		= read_sysreg(VBAR);
+	ctxt->cp15[c13_CID]		= read_sysreg(CID);
+	ctxt->cp15[c13_TID_URW]		= read_sysreg(TID_URW);
+	ctxt->cp15[c13_TID_URO]		= read_sysreg(TID_URO);
+	ctxt->cp15[c13_TID_PRIV]	= read_sysreg(TID_PRIV);
+	ctxt->cp15[c14_CNTKCTL]		= read_sysreg(CNTKCTL);
+}
+
+void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
+{
+	write_sysreg(ctxt->cp15[c0_MPIDR],	VMPIDR);
+	write_sysreg(ctxt->cp15[c0_CSSELR],	CSSELR);
+	write_sysreg(ctxt->cp15[c1_SCTLR],	SCTLR);
+	write_sysreg(ctxt->cp15[c1_CPACR],	CPACR);
+	write_sysreg(*cp15_64(ctxt, c2_TTBR0),	TTBR0);
+	write_sysreg(*cp15_64(ctxt, c2_TTBR1),	TTBR1);
+	write_sysreg(ctxt->cp15[c2_TTBCR],	TTBCR);
+	write_sysreg(ctxt->cp15[c3_DACR],	DACR);
+	write_sysreg(ctxt->cp15[c5_DFSR],	DFSR);
+	write_sysreg(ctxt->cp15[c5_IFSR],	IFSR);
+	write_sysreg(ctxt->cp15[c5_ADFSR],	ADFSR);
+	write_sysreg(ctxt->cp15[c5_AIFSR],	AIFSR);
+	write_sysreg(ctxt->cp15[c6_DFAR],	DFAR);
+	write_sysreg(ctxt->cp15[c6_IFAR],	IFAR);
+	write_sysreg(*cp15_64(ctxt, c7_PAR),	PAR);
+	write_sysreg(ctxt->cp15[c10_PRRR],	PRRR);
+	write_sysreg(ctxt->cp15[c10_NMRR],	NMRR);
+	write_sysreg(ctxt->cp15[c10_AMAIR0],	AMAIR0);
+	write_sysreg(ctxt->cp15[c10_AMAIR1],	AMAIR1);
+	write_sysreg(ctxt->cp15[c12_VBAR],	VBAR);
+	write_sysreg(ctxt->cp15[c13_CID],	CID);
+	write_sysreg(ctxt->cp15[c13_TID_URW],	TID_URW);
+	write_sysreg(ctxt->cp15[c13_TID_URO],	TID_URO);
+	write_sysreg(ctxt->cp15[c13_TID_PRIV],	TID_PRIV);
+	write_sysreg(ctxt->cp15[c14_CNTKCTL],	CNTKCTL);
+}
diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
index 5808bbd..ab2cb82 100644
--- a/arch/arm/kvm/hyp/hyp.h
+++ b/arch/arm/kvm/hyp/hyp.h
@@ -42,9 +42,37 @@
 })
 #define read_sysreg(...)		__read_sysreg(__VA_ARGS__)
 
+#define TTBR0		__ACCESS_CP15_64(0, c2)
+#define TTBR1		__ACCESS_CP15_64(1, c2)
 #define VTTBR		__ACCESS_CP15_64(6, c2)
+#define PAR		__ACCESS_CP15_64(0, c7)
+#define CSSELR		__ACCESS_CP15(c0, 2, c0, 0)
+#define VMPIDR		__ACCESS_CP15(c0, 4, c0, 5)
+#define SCTLR		__ACCESS_CP15(c1, 0, c0, 0)
+#define CPACR		__ACCESS_CP15(c1, 0, c0, 2)
+#define TTBCR		__ACCESS_CP15(c2, 0, c0, 2)
+#define DACR		__ACCESS_CP15(c3, 0, c0, 0)
+#define DFSR		__ACCESS_CP15(c5, 0, c0, 0)
+#define IFSR		__ACCESS_CP15(c5, 0, c0, 1)
+#define ADFSR		__ACCESS_CP15(c5, 0, c1, 0)
+#define AIFSR		__ACCESS_CP15(c5, 0, c1, 1)
+#define DFAR		__ACCESS_CP15(c6, 0, c0, 0)
+#define IFAR		__ACCESS_CP15(c6, 0, c0, 2)
 #define ICIALLUIS	__ACCESS_CP15(c7, 0, c1, 0)
 #define TLBIALLIS	__ACCESS_CP15(c8, 0, c3, 0)
 #define TLBIALLNSNHIS	__ACCESS_CP15(c8, 4, c3, 4)
+#define PRRR		__ACCESS_CP15(c10, 0, c2, 0)
+#define NMRR		__ACCESS_CP15(c10, 0, c2, 1)
+#define AMAIR0		__ACCESS_CP15(c10, 0, c3, 0)
+#define AMAIR1		__ACCESS_CP15(c10, 0, c3, 1)
+#define VBAR		__ACCESS_CP15(c12, 0, c0, 0)
+#define CID		__ACCESS_CP15(c13, 0, c0, 1)
+#define TID_URW		__ACCESS_CP15(c13, 0, c0, 2)
+#define TID_URO		__ACCESS_CP15(c13, 0, c0, 3)
+#define TID_PRIV	__ACCESS_CP15(c13, 0, c0, 4)
+#define CNTKCTL		__ACCESS_CP15(c14, 0, c1, 0)
+
+void __sysreg_save_state(struct kvm_cpu_context *ctxt);
+void __sysreg_restore_state(struct kvm_cpu_context *ctxt);
 
 #endif /* __ARM_KVM_HYP_H__ */
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:44 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:44 +0000
Subject: [PATCH v2 27/28] ARM: KVM: Remove handling of
 ARM_EXCEPTION_DATA/PREF_ABORT
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-28-git-send-email-marc.zyngier@arm.com>

These are now handled as a panic, so there is little point in
keeping them around.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/handle_exit.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/kvm/handle_exit.c b/arch/arm/kvm/handle_exit.c
index 5377d753..3f1ef0d 100644
--- a/arch/arm/kvm/handle_exit.c
+++ b/arch/arm/kvm/handle_exit.c
@@ -147,8 +147,6 @@ int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
 	switch (exception_index) {
 	case ARM_EXCEPTION_IRQ:
 		return 1;
-	case ARM_EXCEPTION_DATA_ABORT:
-	case ARM_EXCEPTION_PREF_ABORT:
 	case ARM_EXCEPTION_HVC:
 		/*
 		 * See ARM ARM B1.14.1: "Hyp traps on instructions
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:38 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:38 +0000
Subject: [PATCH v2 21/28] ARM: KVM: Remove the old world switch
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-22-git-send-email-marc.zyngier@arm.com>

As we now have a full reimplementation of the world switch, it is
time to kiss the old stuff goodbye. I'm not sure we'll miss it.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/interrupts.S      | 469 +----------------------------
 arch/arm/kvm/interrupts_head.S | 660 -----------------------------------------
 2 files changed, 1 insertion(+), 1128 deletions(-)
 delete mode 100644 arch/arm/kvm/interrupts_head.S

diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index 01eb169..b1bd316 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -17,198 +17,8 @@
  */
 
 #include <linux/linkage.h>
-#include <linux/const.h>
-#include <asm/unified.h>
-#include <asm/page.h>
-#include <asm/ptrace.h>
-#include <asm/asm-offsets.h>
-#include <asm/kvm_asm.h>
-#include <asm/kvm_arm.h>
-#include <asm/vfpmacros.h>
-#include "interrupts_head.S"
 
 	.text
-	.pushsection	.hyp.text, "ax"
-
-/********************************************************************
- * Flush per-VMID TLBs
- *
- * void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
- *
- * We rely on the hardware to broadcast the TLB invalidation to all CPUs
- * inside the inner-shareable domain (which is the case for all v7
- * implementations).  If we come across a non-IS SMP implementation, we'll
- * have to use an IPI based mechanism. Until then, we stick to the simple
- * hardware assisted version.
- *
- * As v7 does not support flushing per IPA, just nuke the whole TLB
- * instead, ignoring the ipa value.
- */
-ENTRY(__kvm_tlb_flush_vmid_ipa)
-	push	{r2, r3}
-
-	dsb	ishst
-	add	r0, r0, #KVM_VTTBR
-	ldrd	r2, r3, [r0]
-	mcrr	p15, 6, rr_lo_hi(r2, r3), c2	@ Write VTTBR
-	isb
-	mcr     p15, 0, r0, c8, c3, 0	@ TLBIALLIS (rt ignored)
-	dsb	ish
-	isb
-	mov	r2, #0
-	mov	r3, #0
-	mcrr	p15, 6, r2, r3, c2	@ Back to VMID #0
-	isb				@ Not necessary if followed by eret
-
-	pop	{r2, r3}
-	bx	lr
-ENDPROC(__kvm_tlb_flush_vmid_ipa)
-
-/**
- * void __kvm_tlb_flush_vmid(struct kvm *kvm) - Flush per-VMID TLBs
- *
- * Reuses __kvm_tlb_flush_vmid_ipa() for ARMv7, without passing address
- * parameter
- */
-
-ENTRY(__kvm_tlb_flush_vmid)
-	b	__kvm_tlb_flush_vmid_ipa
-ENDPROC(__kvm_tlb_flush_vmid)
-
-/********************************************************************
- * Flush TLBs and instruction caches of all CPUs inside the inner-shareable
- * domain, for all VMIDs
- *
- * void __kvm_flush_vm_context(void);
- */
-ENTRY(__kvm_flush_vm_context)
-	mov	r0, #0			@ rn parameter for c15 flushes is SBZ
-
-	/* Invalidate NS Non-Hyp TLB Inner Shareable (TLBIALLNSNHIS) */
-	mcr     p15, 4, r0, c8, c3, 4
-	/* Invalidate instruction caches Inner Shareable (ICIALLUIS) */
-	mcr     p15, 0, r0, c7, c1, 0
-	dsb	ish
-	isb				@ Not necessary if followed by eret
-
-	bx	lr
-ENDPROC(__kvm_flush_vm_context)
-
-
-/********************************************************************
- *  Hypervisor world-switch code
- *
- *
- * int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
- */
-ENTRY(__kvm_vcpu_run)
-	@ Save the vcpu pointer
-	mcr	p15, 4, vcpu, c13, c0, 2	@ HTPIDR
-
-	save_host_regs
-
-	restore_vgic_state
-	restore_timer_state
-
-	@ Store hardware CP15 state and load guest state
-	read_cp15_state store_to_vcpu = 0
-	write_cp15_state read_from_vcpu = 1
-
-	@ If the host kernel has not been configured with VFPv3 support,
-	@ then it is safer if we deny guests from using it as well.
-#ifdef CONFIG_VFPv3
-	@ Set FPEXC_EN so the guest doesn't trap floating point instructions
-	VFPFMRX r2, FPEXC		@ VMRS
-	push	{r2}
-	orr	r2, r2, #FPEXC_EN
-	VFPFMXR FPEXC, r2		@ VMSR
-#endif
-
-	@ Configure Hyp-role
-	configure_hyp_role vmentry
-
-	@ Trap coprocessor CRx accesses
-	set_hstr vmentry
-	set_hcptr vmentry, (HCPTR_TTA | HCPTR_TCP(10) | HCPTR_TCP(11))
-	set_hdcr vmentry
-
-	@ Write configured ID register into MIDR alias
-	ldr	r1, [vcpu, #VCPU_MIDR]
-	mcr	p15, 4, r1, c0, c0, 0
-
-	@ Write guest view of MPIDR into VMPIDR
-	ldr	r1, [vcpu, #CP15_OFFSET(c0_MPIDR)]
-	mcr	p15, 4, r1, c0, c0, 5
-
-	@ Set up guest memory translation
-	ldr	r1, [vcpu, #VCPU_KVM]
-	add	r1, r1, #KVM_VTTBR
-	ldrd	r2, r3, [r1]
-	mcrr	p15, 6, rr_lo_hi(r2, r3), c2	@ Write VTTBR
-
-	@ We're all done, just restore the GPRs and go to the guest
-	restore_guest_regs
-	clrex				@ Clear exclusive monitor
-	eret
-
-__kvm_vcpu_return:
-	/*
-	 * return convention:
-	 * guest r0, r1, r2 saved on the stack
-	 * r0: vcpu pointer
-	 * r1: exception code
-	 */
-	save_guest_regs
-
-	@ Set VMID == 0
-	mov	r2, #0
-	mov	r3, #0
-	mcrr	p15, 6, r2, r3, c2	@ Write VTTBR
-
-	@ Don't trap coprocessor accesses for host kernel
-	set_hstr vmexit
-	set_hdcr vmexit
-	set_hcptr vmexit, (HCPTR_TTA | HCPTR_TCP(10) | HCPTR_TCP(11)), after_vfp_restore
-
-#ifdef CONFIG_VFPv3
-	@ Switch VFP/NEON hardware state to the host's
-	add	r7, vcpu, #(VCPU_GUEST_CTXT + CPU_CTXT_VFP)
-	store_vfp_state r7
-	add	r7, vcpu, #VCPU_HOST_CTXT
-	ldr	r7, [r7]
-	add	r7, r7, #CPU_CTXT_VFP
-	restore_vfp_state r7
-
-after_vfp_restore:
-	@ Restore FPEXC_EN which we clobbered on entry
-	pop	{r2}
-	VFPFMXR FPEXC, r2
-#else
-after_vfp_restore:
-#endif
-
-	@ Reset Hyp-role
-	configure_hyp_role vmexit
-
-	@ Let host read hardware MIDR
-	mrc	p15, 0, r2, c0, c0, 0
-	mcr	p15, 4, r2, c0, c0, 0
-
-	@ Back to hardware MPIDR
-	mrc	p15, 0, r2, c0, c0, 5
-	mcr	p15, 4, r2, c0, c0, 5
-
-	@ Store guest CP15 state and restore host state
-	read_cp15_state store_to_vcpu = 1
-	write_cp15_state read_from_vcpu = 0
-
-	save_timer_state
-	save_vgic_state
-
-	restore_host_regs
-	clrex				@ Clear exclusive monitor
-	mov	r0, r1			@ Return the return code
-	bx	lr			@ return to IOCTL
 
 /********************************************************************
  *  Call function in Hyp mode
@@ -239,281 +49,4 @@ after_vfp_restore:
 ENTRY(kvm_call_hyp)
 	hvc	#0
 	bx	lr
-
-/********************************************************************
- * Hypervisor exception vector and handlers
- *
- *
- * The KVM/ARM Hypervisor ABI is defined as follows:
- *
- * Entry to Hyp mode from the host kernel will happen _only_ when an HVC
- * instruction is issued since all traps are disabled when running the host
- * kernel as per the Hyp-mode initialization at boot time.
- *
- * HVC instructions cause a trap to the vector page + offset 0x14 (see hyp_hvc
- * below) when the HVC instruction is called from SVC mode (i.e. a guest or the
- * host kernel) and they cause a trap to the vector page + offset 0x8 when HVC
- * instructions are called from within Hyp-mode.
- *
- * Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
- *    Switching to Hyp mode is done through a simple HVC #0 instruction. The
- *    exception vector code will check that the HVC comes from VMID==0 and if
- *    so will push the necessary state (SPSR, lr_usr) on the Hyp stack.
- *    - r0 contains a pointer to a HYP function
- *    - r1, r2, and r3 contain arguments to the above function.
- *    - The HYP function will be called with its arguments in r0, r1 and r2.
- *    On HYP function return, we return directly to SVC.
- *
- * Note that the above is used to execute code in Hyp-mode from a host-kernel
- * point of view, and is a different concept from performing a world-switch and
- * executing guest code SVC mode (with a VMID != 0).
- */
-
-/* Handle undef, svc, pabt, or dabt by crashing with a user notice */
-.macro bad_exception exception_code, panic_str
-	push	{r0-r2}
-	mrrc	p15, 6, r0, r1, c2	@ Read VTTBR
-	lsr	r1, r1, #16
-	ands	r1, r1, #0xff
-	beq	99f
-
-	load_vcpu			@ Load VCPU pointer
-	.if \exception_code == ARM_EXCEPTION_DATA_ABORT
-	mrc	p15, 4, r2, c5, c2, 0	@ HSR
-	mrc	p15, 4, r1, c6, c0, 0	@ HDFAR
-	str	r2, [vcpu, #VCPU_HSR]
-	str	r1, [vcpu, #VCPU_HxFAR]
-	.endif
-	.if \exception_code == ARM_EXCEPTION_PREF_ABORT
-	mrc	p15, 4, r2, c5, c2, 0	@ HSR
-	mrc	p15, 4, r1, c6, c0, 2	@ HIFAR
-	str	r2, [vcpu, #VCPU_HSR]
-	str	r1, [vcpu, #VCPU_HxFAR]
-	.endif
-	mov	r1, #\exception_code
-	b	__kvm_vcpu_return
-
-	@ We were in the host already. Let's craft a panic-ing return to SVC.
-99:	mrs	r2, cpsr
-	bic	r2, r2, #MODE_MASK
-	orr	r2, r2, #SVC_MODE
-THUMB(	orr	r2, r2, #PSR_T_BIT	)
-	msr	spsr_cxsf, r2
-	mrs	r1, ELR_hyp
-	ldr	r2, =panic
-	msr	ELR_hyp, r2
-	ldr	r0, =\panic_str
-	clrex				@ Clear exclusive monitor
-	eret
-.endm
-
-	.align 5
-__kvm_hyp_vector:
-	.globl __kvm_hyp_vector
-
-	@ Hyp-mode exception vector
-	W(b)	hyp_reset
-	W(b)	hyp_undef
-	W(b)	hyp_svc
-	W(b)	hyp_pabt
-	W(b)	hyp_dabt
-	W(b)	hyp_hvc
-	W(b)	hyp_irq
-	W(b)	hyp_fiq
-
-	.align
-hyp_reset:
-	b	hyp_reset
-
-	.align
-hyp_undef:
-	bad_exception ARM_EXCEPTION_UNDEFINED, und_die_str
-
-	.align
-hyp_svc:
-	bad_exception ARM_EXCEPTION_HVC, svc_die_str
-
-	.align
-hyp_pabt:
-	bad_exception ARM_EXCEPTION_PREF_ABORT, pabt_die_str
-
-	.align
-hyp_dabt:
-	bad_exception ARM_EXCEPTION_DATA_ABORT, dabt_die_str
-
-	.align
-hyp_hvc:
-	/*
-	 * Getting here is either becuase of a trap from a guest or from calling
-	 * HVC from the host kernel, which means "switch to Hyp mode".
-	 */
-	push	{r0, r1, r2}
-
-	@ Check syndrome register
-	mrc	p15, 4, r1, c5, c2, 0	@ HSR
-	lsr	r0, r1, #HSR_EC_SHIFT
-	cmp	r0, #HSR_EC_HVC
-	bne	guest_trap		@ Not HVC instr.
-
-	/*
-	 * Let's check if the HVC came from VMID 0 and allow simple
-	 * switch to Hyp mode
-	 */
-	mrrc    p15, 6, r0, r2, c2
-	lsr     r2, r2, #16
-	and     r2, r2, #0xff
-	cmp     r2, #0
-	bne	guest_trap		@ Guest called HVC
-
-	/*
-	 * Getting here means host called HVC, we shift parameters and branch
-	 * to Hyp function.
-	 */
-	pop	{r0, r1, r2}
-
-	/* Check for __hyp_get_vectors */
-	cmp	r0, #-1
-	mrceq	p15, 4, r0, c12, c0, 0	@ get HVBAR
-	beq	1f
-
-	push	{lr}
-	mrs	lr, SPSR
-	push	{lr}
-
-	mov	lr, r0
-	mov	r0, r1
-	mov	r1, r2
-	mov	r2, r3
-
-THUMB(	orr	lr, #1)
-	blx	lr			@ Call the HYP function
-
-	pop	{lr}
-	msr	SPSR_csxf, lr
-	pop	{lr}
-1:	eret
-
-guest_trap:
-	load_vcpu			@ Load VCPU pointer to r0
-	str	r1, [vcpu, #VCPU_HSR]
-
-	@ Check if we need the fault information
-	lsr	r1, r1, #HSR_EC_SHIFT
-#ifdef CONFIG_VFPv3
-	cmp	r1, #HSR_EC_CP_0_13
-	beq	switch_to_guest_vfp
-#endif
-	cmp	r1, #HSR_EC_IABT
-	mrceq	p15, 4, r2, c6, c0, 2	@ HIFAR
-	beq	2f
-	cmp	r1, #HSR_EC_DABT
-	bne	1f
-	mrc	p15, 4, r2, c6, c0, 0	@ HDFAR
-
-2:	str	r2, [vcpu, #VCPU_HxFAR]
-
-	/*
-	 * B3.13.5 Reporting exceptions taken to the Non-secure PL2 mode:
-	 *
-	 * Abort on the stage 2 translation for a memory access from a
-	 * Non-secure PL1 or PL0 mode:
-	 *
-	 * For any Access flag fault or Translation fault, and also for any
-	 * Permission fault on the stage 2 translation of a memory access
-	 * made as part of a translation table walk for a stage 1 translation,
-	 * the HPFAR holds the IPA that caused the fault. Otherwise, the HPFAR
-	 * is UNKNOWN.
-	 */
-
-	/* Check for permission fault, and S1PTW */
-	mrc	p15, 4, r1, c5, c2, 0	@ HSR
-	and	r0, r1, #HSR_FSC_TYPE
-	cmp	r0, #FSC_PERM
-	tsteq	r1, #(1 << 7)		@ S1PTW
-	mrcne	p15, 4, r2, c6, c0, 4	@ HPFAR
-	bne	3f
-
-	/* Preserve PAR */
-	mrrc	p15, 0, r0, r1, c7	@ PAR
-	push	{r0, r1}
-
-	/* Resolve IPA using the xFAR */
-	mcr	p15, 0, r2, c7, c8, 0	@ ATS1CPR
-	isb
-	mrrc	p15, 0, r0, r1, c7	@ PAR
-	tst	r0, #1
-	bne	4f			@ Failed translation
-	ubfx	r2, r0, #12, #20
-	lsl	r2, r2, #4
-	orr	r2, r2, r1, lsl #24
-
-	/* Restore PAR */
-	pop	{r0, r1}
-	mcrr	p15, 0, r0, r1, c7	@ PAR
-
-3:	load_vcpu			@ Load VCPU pointer to r0
-	str	r2, [r0, #VCPU_HPFAR]
-
-1:	mov	r1, #ARM_EXCEPTION_HVC
-	b	__kvm_vcpu_return
-
-4:	pop	{r0, r1}		@ Failed translation, return to guest
-	mcrr	p15, 0, r0, r1, c7	@ PAR
-	clrex
-	pop	{r0, r1, r2}
-	eret
-
-/*
- * If VFPv3 support is not available, then we will not switch the VFP
- * registers; however cp10 and cp11 accesses will still trap and fallback
- * to the regular coprocessor emulation code, which currently will
- * inject an undefined exception to the guest.
- */
-#ifdef CONFIG_VFPv3
-switch_to_guest_vfp:
-	push	{r3-r7}
-
-	@ NEON/VFP used.  Turn on VFP access.
-	set_hcptr vmtrap, (HCPTR_TCP(10) | HCPTR_TCP(11))
-
-	@ Switch VFP/NEON hardware state to the guest's
-	add	r7, r0, #VCPU_HOST_CTXT
-	ldr	r7, [r7]
-	add	r7, r7, #CPU_CTXT_VFP
-	store_vfp_state r7
-	add	r7, r0, #(VCPU_GUEST_CTXT + CPU_CTXT_VFP)
-	restore_vfp_state r7
-
-	pop	{r3-r7}
-	pop	{r0-r2}
-	clrex
-	eret
-#endif
-
-	.align
-hyp_irq:
-	push	{r0, r1, r2}
-	mov	r1, #ARM_EXCEPTION_IRQ
-	load_vcpu			@ Load VCPU pointer to r0
-	b	__kvm_vcpu_return
-
-	.align
-hyp_fiq:
-	b	hyp_fiq
-
-	.ltorg
-
-	.popsection
-
-	.pushsection ".rodata"
-
-und_die_str:
-	.ascii	"unexpected undefined exception in Hyp mode at: %#08x\n"
-pabt_die_str:
-	.ascii	"unexpected prefetch abort in Hyp mode at: %#08x\n"
-dabt_die_str:
-	.ascii	"unexpected data abort in Hyp mode at: %#08x\n"
-svc_die_str:
-	.ascii	"unexpected HVC/SVC trap in Hyp mode at: %#08x\n"
-
-	.popsection
+ENDPROC(kvm_call_hyp)
diff --git a/arch/arm/kvm/interrupts_head.S b/arch/arm/kvm/interrupts_head.S
deleted file mode 100644
index e0943cb8..0000000
--- a/arch/arm/kvm/interrupts_head.S
+++ /dev/null
@@ -1,660 +0,0 @@
-#include <linux/irqchip/arm-gic.h>
-#include <asm/assembler.h>
-
-/* Compat macro, until we get rid of this file entierely */
-#define VCPU_GP_REGS		(VCPU_GUEST_CTXT + CPU_CTXT_GP_REGS)
-#define VCPU_USR_REGS		(VCPU_GP_REGS + GP_REGS_USR)
-#define VCPU_SVC_REGS		(VCPU_GP_REGS + GP_REGS_SVC)
-#define VCPU_ABT_REGS		(VCPU_GP_REGS + GP_REGS_ABT)
-#define VCPU_UND_REGS		(VCPU_GP_REGS + GP_REGS_UND)
-#define VCPU_IRQ_REGS		(VCPU_GP_REGS + GP_REGS_IRQ)
-#define VCPU_FIQ_REGS		(VCPU_GP_REGS + GP_REGS_FIQ)
-#define VCPU_PC			(VCPU_GP_REGS + GP_REGS_PC)
-#define VCPU_CPSR		(VCPU_GP_REGS + GP_REGS_CPSR)
-
-#define VCPU_USR_REG(_reg_nr)	(VCPU_USR_REGS + (_reg_nr * 4))
-#define VCPU_USR_SP		(VCPU_USR_REG(13))
-#define VCPU_USR_LR		(VCPU_USR_REG(14))
-#define VCPU_CP15_BASE		(VCPU_GUEST_CTXT + CPU_CTXT_CP15)
-#define CP15_OFFSET(_cp15_reg_idx) (VCPU_CP15_BASE + (_cp15_reg_idx * 4))
-
-/*
- * Many of these macros need to access the VCPU structure, which is always
- * held in r0. These macros should never clobber r1, as it is used to hold the
- * exception code on the return path (except of course the macro that switches
- * all the registers before the final jump to the VM).
- */
-vcpu	.req	r0		@ vcpu pointer always in r0
-
-/* Clobbers {r2-r6} */
-.macro store_vfp_state vfp_base
-	@ The VFPFMRX and VFPFMXR macros are the VMRS and VMSR instructions
-	VFPFMRX	r2, FPEXC
-	@ Make sure VFP is enabled so we can touch the registers.
-	orr	r6, r2, #FPEXC_EN
-	VFPFMXR	FPEXC, r6
-
-	VFPFMRX	r3, FPSCR
-	tst	r2, #FPEXC_EX		@ Check for VFP Subarchitecture
-	beq	1f
-	@ If FPEXC_EX is 0, then FPINST/FPINST2 reads are upredictable, so
-	@ we only need to save them if FPEXC_EX is set.
-	VFPFMRX r4, FPINST
-	tst	r2, #FPEXC_FP2V
-	VFPFMRX r5, FPINST2, ne		@ vmrsne
-	bic	r6, r2, #FPEXC_EX	@ FPEXC_EX disable
-	VFPFMXR	FPEXC, r6
-1:
-	VFPFSTMIA \vfp_base, r6		@ Save VFP registers
-	stm	\vfp_base, {r2-r5}	@ Save FPEXC, FPSCR, FPINST, FPINST2
-.endm
-
-/* Assume FPEXC_EN is on and FPEXC_EX is off, clobbers {r2-r6} */
-.macro restore_vfp_state vfp_base
-	VFPFLDMIA \vfp_base, r6		@ Load VFP registers
-	ldm	\vfp_base, {r2-r5}	@ Load FPEXC, FPSCR, FPINST, FPINST2
-
-	VFPFMXR FPSCR, r3
-	tst	r2, #FPEXC_EX		@ Check for VFP Subarchitecture
-	beq	1f
-	VFPFMXR FPINST, r4
-	tst	r2, #FPEXC_FP2V
-	VFPFMXR FPINST2, r5, ne
-1:
-	VFPFMXR FPEXC, r2	@ FPEXC	(last, in case !EN)
-.endm
-
-/* These are simply for the macros to work - value don't have meaning */
-.equ usr, 0
-.equ svc, 1
-.equ abt, 2
-.equ und, 3
-.equ irq, 4
-.equ fiq, 5
-
-.macro push_host_regs_mode mode
-	mrs	r2, SP_\mode
-	mrs	r3, LR_\mode
-	mrs	r4, SPSR_\mode
-	push	{r2, r3, r4}
-.endm
-
-/*
- * Store all host persistent registers on the stack.
- * Clobbers all registers, in all modes, except r0 and r1.
- */
-.macro save_host_regs
-	/* Hyp regs. Only ELR_hyp (SPSR_hyp already saved) */
-	mrs	r2, ELR_hyp
-	push	{r2}
-
-	/* usr regs */
-	push	{r4-r12}	@ r0-r3 are always clobbered
-	mrs	r2, SP_usr
-	mov	r3, lr
-	push	{r2, r3}
-
-	push_host_regs_mode svc
-	push_host_regs_mode abt
-	push_host_regs_mode und
-	push_host_regs_mode irq
-
-	/* fiq regs */
-	mrs	r2, r8_fiq
-	mrs	r3, r9_fiq
-	mrs	r4, r10_fiq
-	mrs	r5, r11_fiq
-	mrs	r6, r12_fiq
-	mrs	r7, SP_fiq
-	mrs	r8, LR_fiq
-	mrs	r9, SPSR_fiq
-	push	{r2-r9}
-.endm
-
-.macro pop_host_regs_mode mode
-	pop	{r2, r3, r4}
-	msr	SP_\mode, r2
-	msr	LR_\mode, r3
-	msr	SPSR_\mode, r4
-.endm
-
-/*
- * Restore all host registers from the stack.
- * Clobbers all registers, in all modes, except r0 and r1.
- */
-.macro restore_host_regs
-	pop	{r2-r9}
-	msr	r8_fiq, r2
-	msr	r9_fiq, r3
-	msr	r10_fiq, r4
-	msr	r11_fiq, r5
-	msr	r12_fiq, r6
-	msr	SP_fiq, r7
-	msr	LR_fiq, r8
-	msr	SPSR_fiq, r9
-
-	pop_host_regs_mode irq
-	pop_host_regs_mode und
-	pop_host_regs_mode abt
-	pop_host_regs_mode svc
-
-	pop	{r2, r3}
-	msr	SP_usr, r2
-	mov	lr, r3
-	pop	{r4-r12}
-
-	pop	{r2}
-	msr	ELR_hyp, r2
-.endm
-
-/*
- * Restore SP, LR and SPSR for a given mode. offset is the offset of
- * this mode's registers from the VCPU base.
- *
- * Assumes vcpu pointer in vcpu reg
- *
- * Clobbers r1, r2, r3, r4.
- */
-.macro restore_guest_regs_mode mode, offset
-	add	r1, vcpu, \offset
-	ldm	r1, {r2, r3, r4}
-	msr	SP_\mode, r2
-	msr	LR_\mode, r3
-	msr	SPSR_\mode, r4
-.endm
-
-/*
- * Restore all guest registers from the vcpu struct.
- *
- * Assumes vcpu pointer in vcpu reg
- *
- * Clobbers *all* registers.
- */
-.macro restore_guest_regs
-	restore_guest_regs_mode svc, #VCPU_SVC_REGS
-	restore_guest_regs_mode abt, #VCPU_ABT_REGS
-	restore_guest_regs_mode und, #VCPU_UND_REGS
-	restore_guest_regs_mode irq, #VCPU_IRQ_REGS
-
-	add	r1, vcpu, #VCPU_FIQ_REGS
-	ldm	r1, {r2-r9}
-	msr	r8_fiq, r2
-	msr	r9_fiq, r3
-	msr	r10_fiq, r4
-	msr	r11_fiq, r5
-	msr	r12_fiq, r6
-	msr	SP_fiq, r7
-	msr	LR_fiq, r8
-	msr	SPSR_fiq, r9
-
-	@ Load return state
-	ldr	r2, [vcpu, #VCPU_PC]
-	ldr	r3, [vcpu, #VCPU_CPSR]
-	msr	ELR_hyp, r2
-	msr	SPSR_cxsf, r3
-
-	@ Load user registers
-	ldr	r2, [vcpu, #VCPU_USR_SP]
-	ldr	r3, [vcpu, #VCPU_USR_LR]
-	msr	SP_usr, r2
-	mov	lr, r3
-	add	vcpu, vcpu, #(VCPU_USR_REGS)
-	ldm	vcpu, {r0-r12}
-.endm
-
-/*
- * Save SP, LR and SPSR for a given mode. offset is the offset of
- * this mode's registers from the VCPU base.
- *
- * Assumes vcpu pointer in vcpu reg
- *
- * Clobbers r2, r3, r4, r5.
- */
-.macro save_guest_regs_mode mode, offset
-	add	r2, vcpu, \offset
-	mrs	r3, SP_\mode
-	mrs	r4, LR_\mode
-	mrs	r5, SPSR_\mode
-	stm	r2, {r3, r4, r5}
-.endm
-
-/*
- * Save all guest registers to the vcpu struct
- * Expects guest's r0, r1, r2 on the stack.
- *
- * Assumes vcpu pointer in vcpu reg
- *
- * Clobbers r2, r3, r4, r5.
- */
-.macro save_guest_regs
-	@ Store usr registers
-	add	r2, vcpu, #VCPU_USR_REG(3)
-	stm	r2, {r3-r12}
-	add	r2, vcpu, #VCPU_USR_REG(0)
-	pop	{r3, r4, r5}		@ r0, r1, r2
-	stm	r2, {r3, r4, r5}
-	mrs	r2, SP_usr
-	mov	r3, lr
-	str	r2, [vcpu, #VCPU_USR_SP]
-	str	r3, [vcpu, #VCPU_USR_LR]
-
-	@ Store return state
-	mrs	r2, ELR_hyp
-	mrs	r3, spsr
-	str	r2, [vcpu, #VCPU_PC]
-	str	r3, [vcpu, #VCPU_CPSR]
-
-	@ Store other guest registers
-	save_guest_regs_mode svc, #VCPU_SVC_REGS
-	save_guest_regs_mode abt, #VCPU_ABT_REGS
-	save_guest_regs_mode und, #VCPU_UND_REGS
-	save_guest_regs_mode irq, #VCPU_IRQ_REGS
-.endm
-
-/* Reads cp15 registers from hardware and stores them in memory
- * @store_to_vcpu: If 0, registers are written in-order to the stack,
- * 		   otherwise to the VCPU struct pointed to by vcpup
- *
- * Assumes vcpu pointer in vcpu reg
- *
- * Clobbers r2 - r12
- */
-.macro read_cp15_state store_to_vcpu
-	mrc	p15, 0, r2, c1, c0, 0	@ SCTLR
-	mrc	p15, 0, r3, c1, c0, 2	@ CPACR
-	mrc	p15, 0, r4, c2, c0, 2	@ TTBCR
-	mrc	p15, 0, r5, c3, c0, 0	@ DACR
-	mrrc	p15, 0, r6, r7, c2	@ TTBR 0
-	mrrc	p15, 1, r8, r9, c2	@ TTBR 1
-	mrc	p15, 0, r10, c10, c2, 0	@ PRRR
-	mrc	p15, 0, r11, c10, c2, 1	@ NMRR
-	mrc	p15, 2, r12, c0, c0, 0	@ CSSELR
-
-	.if \store_to_vcpu == 0
-	push	{r2-r12}		@ Push CP15 registers
-	.else
-	str	r2, [vcpu, #CP15_OFFSET(c1_SCTLR)]
-	str	r3, [vcpu, #CP15_OFFSET(c1_CPACR)]
-	str	r4, [vcpu, #CP15_OFFSET(c2_TTBCR)]
-	str	r5, [vcpu, #CP15_OFFSET(c3_DACR)]
-	add	r2, vcpu, #CP15_OFFSET(c2_TTBR0)
-	strd	r6, r7, [r2]
-	add	r2, vcpu, #CP15_OFFSET(c2_TTBR1)
-	strd	r8, r9, [r2]
-	str	r10, [vcpu, #CP15_OFFSET(c10_PRRR)]
-	str	r11, [vcpu, #CP15_OFFSET(c10_NMRR)]
-	str	r12, [vcpu, #CP15_OFFSET(c0_CSSELR)]
-	.endif
-
-	mrc	p15, 0, r2, c13, c0, 1	@ CID
-	mrc	p15, 0, r3, c13, c0, 2	@ TID_URW
-	mrc	p15, 0, r4, c13, c0, 3	@ TID_URO
-	mrc	p15, 0, r5, c13, c0, 4	@ TID_PRIV
-	mrc	p15, 0, r6, c5, c0, 0	@ DFSR
-	mrc	p15, 0, r7, c5, c0, 1	@ IFSR
-	mrc	p15, 0, r8, c5, c1, 0	@ ADFSR
-	mrc	p15, 0, r9, c5, c1, 1	@ AIFSR
-	mrc	p15, 0, r10, c6, c0, 0	@ DFAR
-	mrc	p15, 0, r11, c6, c0, 2	@ IFAR
-	mrc	p15, 0, r12, c12, c0, 0	@ VBAR
-
-	.if \store_to_vcpu == 0
-	push	{r2-r12}		@ Push CP15 registers
-	.else
-	str	r2, [vcpu, #CP15_OFFSET(c13_CID)]
-	str	r3, [vcpu, #CP15_OFFSET(c13_TID_URW)]
-	str	r4, [vcpu, #CP15_OFFSET(c13_TID_URO)]
-	str	r5, [vcpu, #CP15_OFFSET(c13_TID_PRIV)]
-	str	r6, [vcpu, #CP15_OFFSET(c5_DFSR)]
-	str	r7, [vcpu, #CP15_OFFSET(c5_IFSR)]
-	str	r8, [vcpu, #CP15_OFFSET(c5_ADFSR)]
-	str	r9, [vcpu, #CP15_OFFSET(c5_AIFSR)]
-	str	r10, [vcpu, #CP15_OFFSET(c6_DFAR)]
-	str	r11, [vcpu, #CP15_OFFSET(c6_IFAR)]
-	str	r12, [vcpu, #CP15_OFFSET(c12_VBAR)]
-	.endif
-
-	mrc	p15, 0, r2, c14, c1, 0	@ CNTKCTL
-	mrrc	p15, 0, r4, r5, c7	@ PAR
-	mrc	p15, 0, r6, c10, c3, 0	@ AMAIR0
-	mrc	p15, 0, r7, c10, c3, 1	@ AMAIR1
-
-	.if \store_to_vcpu == 0
-	push	{r2,r4-r7}
-	.else
-	str	r2, [vcpu, #CP15_OFFSET(c14_CNTKCTL)]
-	add	r12, vcpu, #CP15_OFFSET(c7_PAR)
-	strd	r4, r5, [r12]
-	str	r6, [vcpu, #CP15_OFFSET(c10_AMAIR0)]
-	str	r7, [vcpu, #CP15_OFFSET(c10_AMAIR1)]
-	.endif
-.endm
-
-/*
- * Reads cp15 registers from memory and writes them to hardware
- * @read_from_vcpu: If 0, registers are read in-order from the stack,
- *		    otherwise from the VCPU struct pointed to by vcpup
- *
- * Assumes vcpu pointer in vcpu reg
- */
-.macro write_cp15_state read_from_vcpu
-	.if \read_from_vcpu == 0
-	pop	{r2,r4-r7}
-	.else
-	ldr	r2, [vcpu, #CP15_OFFSET(c14_CNTKCTL)]
-	add	r12, vcpu, #CP15_OFFSET(c7_PAR)
-	ldrd	r4, r5, [r12]
-	ldr	r6, [vcpu, #CP15_OFFSET(c10_AMAIR0)]
-	ldr	r7, [vcpu, #CP15_OFFSET(c10_AMAIR1)]
-	.endif
-
-	mcr	p15, 0, r2, c14, c1, 0	@ CNTKCTL
-	mcrr	p15, 0, r4, r5, c7	@ PAR
-	mcr	p15, 0, r6, c10, c3, 0	@ AMAIR0
-	mcr	p15, 0, r7, c10, c3, 1	@ AMAIR1
-
-	.if \read_from_vcpu == 0
-	pop	{r2-r12}
-	.else
-	ldr	r2, [vcpu, #CP15_OFFSET(c13_CID)]
-	ldr	r3, [vcpu, #CP15_OFFSET(c13_TID_URW)]
-	ldr	r4, [vcpu, #CP15_OFFSET(c13_TID_URO)]
-	ldr	r5, [vcpu, #CP15_OFFSET(c13_TID_PRIV)]
-	ldr	r6, [vcpu, #CP15_OFFSET(c5_DFSR)]
-	ldr	r7, [vcpu, #CP15_OFFSET(c5_IFSR)]
-	ldr	r8, [vcpu, #CP15_OFFSET(c5_ADFSR)]
-	ldr	r9, [vcpu, #CP15_OFFSET(c5_AIFSR)]
-	ldr	r10, [vcpu, #CP15_OFFSET(c6_DFAR)]
-	ldr	r11, [vcpu, #CP15_OFFSET(c6_IFAR)]
-	ldr	r12, [vcpu, #CP15_OFFSET(c12_VBAR)]
-	.endif
-
-	mcr	p15, 0, r2, c13, c0, 1	@ CID
-	mcr	p15, 0, r3, c13, c0, 2	@ TID_URW
-	mcr	p15, 0, r4, c13, c0, 3	@ TID_URO
-	mcr	p15, 0, r5, c13, c0, 4	@ TID_PRIV
-	mcr	p15, 0, r6, c5, c0, 0	@ DFSR
-	mcr	p15, 0, r7, c5, c0, 1	@ IFSR
-	mcr	p15, 0, r8, c5, c1, 0	@ ADFSR
-	mcr	p15, 0, r9, c5, c1, 1	@ AIFSR
-	mcr	p15, 0, r10, c6, c0, 0	@ DFAR
-	mcr	p15, 0, r11, c6, c0, 2	@ IFAR
-	mcr	p15, 0, r12, c12, c0, 0	@ VBAR
-
-	.if \read_from_vcpu == 0
-	pop	{r2-r12}
-	.else
-	ldr	r2, [vcpu, #CP15_OFFSET(c1_SCTLR)]
-	ldr	r3, [vcpu, #CP15_OFFSET(c1_CPACR)]
-	ldr	r4, [vcpu, #CP15_OFFSET(c2_TTBCR)]
-	ldr	r5, [vcpu, #CP15_OFFSET(c3_DACR)]
-	add	r12, vcpu, #CP15_OFFSET(c2_TTBR0)
-	ldrd	r6, r7, [r12]
-	add	r12, vcpu, #CP15_OFFSET(c2_TTBR1)
-	ldrd	r8, r9, [r12]
-	ldr	r10, [vcpu, #CP15_OFFSET(c10_PRRR)]
-	ldr	r11, [vcpu, #CP15_OFFSET(c10_NMRR)]
-	ldr	r12, [vcpu, #CP15_OFFSET(c0_CSSELR)]
-	.endif
-
-	mcr	p15, 0, r2, c1, c0, 0	@ SCTLR
-	mcr	p15, 0, r3, c1, c0, 2	@ CPACR
-	mcr	p15, 0, r4, c2, c0, 2	@ TTBCR
-	mcr	p15, 0, r5, c3, c0, 0	@ DACR
-	mcrr	p15, 0, r6, r7, c2	@ TTBR 0
-	mcrr	p15, 1, r8, r9, c2	@ TTBR 1
-	mcr	p15, 0, r10, c10, c2, 0	@ PRRR
-	mcr	p15, 0, r11, c10, c2, 1	@ NMRR
-	mcr	p15, 2, r12, c0, c0, 0	@ CSSELR
-.endm
-
-/*
- * Save the VGIC CPU state into memory
- *
- * Assumes vcpu pointer in vcpu reg
- */
-.macro save_vgic_state
-	/* Get VGIC VCTRL base into r2 */
-	ldr	r2, [vcpu, #VCPU_KVM]
-	ldr	r2, [r2, #KVM_VGIC_VCTRL]
-	cmp	r2, #0
-	beq	2f
-
-	/* Compute the address of struct vgic_cpu */
-	add	r11, vcpu, #VCPU_VGIC_CPU
-
-	/* Save all interesting registers */
-	ldr	r4, [r2, #GICH_VMCR]
-	ldr	r5, [r2, #GICH_MISR]
-	ldr	r6, [r2, #GICH_EISR0]
-	ldr	r7, [r2, #GICH_EISR1]
-	ldr	r8, [r2, #GICH_ELRSR0]
-	ldr	r9, [r2, #GICH_ELRSR1]
-	ldr	r10, [r2, #GICH_APR]
-ARM_BE8(rev	r4, r4	)
-ARM_BE8(rev	r5, r5	)
-ARM_BE8(rev	r6, r6	)
-ARM_BE8(rev	r7, r7	)
-ARM_BE8(rev	r8, r8	)
-ARM_BE8(rev	r9, r9	)
-ARM_BE8(rev	r10, r10	)
-
-	str	r4, [r11, #VGIC_V2_CPU_VMCR]
-	str	r5, [r11, #VGIC_V2_CPU_MISR]
-#ifdef CONFIG_CPU_ENDIAN_BE8
-	str	r6, [r11, #(VGIC_V2_CPU_EISR + 4)]
-	str	r7, [r11, #VGIC_V2_CPU_EISR]
-	str	r8, [r11, #(VGIC_V2_CPU_ELRSR + 4)]
-	str	r9, [r11, #VGIC_V2_CPU_ELRSR]
-#else
-	str	r6, [r11, #VGIC_V2_CPU_EISR]
-	str	r7, [r11, #(VGIC_V2_CPU_EISR + 4)]
-	str	r8, [r11, #VGIC_V2_CPU_ELRSR]
-	str	r9, [r11, #(VGIC_V2_CPU_ELRSR + 4)]
-#endif
-	str	r10, [r11, #VGIC_V2_CPU_APR]
-
-	/* Clear GICH_HCR */
-	mov	r5, #0
-	str	r5, [r2, #GICH_HCR]
-
-	/* Save list registers */
-	add	r2, r2, #GICH_LR0
-	add	r3, r11, #VGIC_V2_CPU_LR
-	ldr	r4, [r11, #VGIC_CPU_NR_LR]
-1:	ldr	r6, [r2], #4
-ARM_BE8(rev	r6, r6	)
-	str	r6, [r3], #4
-	subs	r4, r4, #1
-	bne	1b
-2:
-.endm
-
-/*
- * Restore the VGIC CPU state from memory
- *
- * Assumes vcpu pointer in vcpu reg
- */
-.macro restore_vgic_state
-	/* Get VGIC VCTRL base into r2 */
-	ldr	r2, [vcpu, #VCPU_KVM]
-	ldr	r2, [r2, #KVM_VGIC_VCTRL]
-	cmp	r2, #0
-	beq	2f
-
-	/* Compute the address of struct vgic_cpu */
-	add	r11, vcpu, #VCPU_VGIC_CPU
-
-	/* We only restore a minimal set of registers */
-	ldr	r3, [r11, #VGIC_V2_CPU_HCR]
-	ldr	r4, [r11, #VGIC_V2_CPU_VMCR]
-	ldr	r8, [r11, #VGIC_V2_CPU_APR]
-ARM_BE8(rev	r3, r3	)
-ARM_BE8(rev	r4, r4	)
-ARM_BE8(rev	r8, r8	)
-
-	str	r3, [r2, #GICH_HCR]
-	str	r4, [r2, #GICH_VMCR]
-	str	r8, [r2, #GICH_APR]
-
-	/* Restore list registers */
-	add	r2, r2, #GICH_LR0
-	add	r3, r11, #VGIC_V2_CPU_LR
-	ldr	r4, [r11, #VGIC_CPU_NR_LR]
-1:	ldr	r6, [r3], #4
-ARM_BE8(rev	r6, r6  )
-	str	r6, [r2], #4
-	subs	r4, r4, #1
-	bne	1b
-2:
-.endm
-
-#define CNTHCTL_PL1PCTEN	(1 << 0)
-#define CNTHCTL_PL1PCEN		(1 << 1)
-
-/*
- * Save the timer state onto the VCPU and allow physical timer/counter access
- * for the host.
- *
- * Assumes vcpu pointer in vcpu reg
- * Clobbers r2-r5
- */
-.macro save_timer_state
-	ldr	r4, [vcpu, #VCPU_KVM]
-	ldr	r2, [r4, #KVM_TIMER_ENABLED]
-	cmp	r2, #0
-	beq	1f
-
-	mrc	p15, 0, r2, c14, c3, 1	@ CNTV_CTL
-	str	r2, [vcpu, #VCPU_TIMER_CNTV_CTL]
-
-	isb
-
-	mrrc	p15, 3, rr_lo_hi(r2, r3), c14	@ CNTV_CVAL
-	ldr	r4, =VCPU_TIMER_CNTV_CVAL
-	add	r5, vcpu, r4
-	strd	r2, r3, [r5]
-
-	@ Ensure host CNTVCT == CNTPCT
-	mov	r2, #0
-	mcrr	p15, 4, r2, r2, c14	@ CNTVOFF
-
-1:
-	mov	r2, #0			@ Clear ENABLE
-	mcr	p15, 0, r2, c14, c3, 1	@ CNTV_CTL
-
-	@ Allow physical timer/counter access for the host
-	mrc	p15, 4, r2, c14, c1, 0	@ CNTHCTL
-	orr	r2, r2, #(CNTHCTL_PL1PCEN | CNTHCTL_PL1PCTEN)
-	mcr	p15, 4, r2, c14, c1, 0	@ CNTHCTL
-.endm
-
-/*
- * Load the timer state from the VCPU and deny physical timer/counter access
- * for the host.
- *
- * Assumes vcpu pointer in vcpu reg
- * Clobbers r2-r5
- */
-.macro restore_timer_state
-	@ Disallow physical timer access for the guest
-	@ Physical counter access is allowed
-	mrc	p15, 4, r2, c14, c1, 0	@ CNTHCTL
-	orr	r2, r2, #CNTHCTL_PL1PCTEN
-	bic	r2, r2, #CNTHCTL_PL1PCEN
-	mcr	p15, 4, r2, c14, c1, 0	@ CNTHCTL
-
-	ldr	r4, [vcpu, #VCPU_KVM]
-	ldr	r2, [r4, #KVM_TIMER_ENABLED]
-	cmp	r2, #0
-	beq	1f
-
-	ldr	r2, [r4, #KVM_TIMER_CNTVOFF]
-	ldr	r3, [r4, #(KVM_TIMER_CNTVOFF + 4)]
-	mcrr	p15, 4, rr_lo_hi(r2, r3), c14	@ CNTVOFF
-
-	ldr	r4, =VCPU_TIMER_CNTV_CVAL
-	add	r5, vcpu, r4
-	ldrd	r2, r3, [r5]
-	mcrr	p15, 3, rr_lo_hi(r2, r3), c14	@ CNTV_CVAL
-	isb
-
-	ldr	r2, [vcpu, #VCPU_TIMER_CNTV_CTL]
-	and	r2, r2, #3
-	mcr	p15, 0, r2, c14, c3, 1	@ CNTV_CTL
-1:
-.endm
-
-.equ vmentry,	0
-.equ vmexit,	1
-
-/* Configures the HSTR (Hyp System Trap Register) on entry/return
- * (hardware reset value is 0) */
-.macro set_hstr operation
-	mrc	p15, 4, r2, c1, c1, 3
-	ldr	r3, =HSTR_T(15)
-	.if \operation == vmentry
-	orr	r2, r2, r3		@ Trap CR{15}
-	.else
-	bic	r2, r2, r3		@ Don't trap any CRx accesses
-	.endif
-	mcr	p15, 4, r2, c1, c1, 3
-.endm
-
-/* Configures the HCPTR (Hyp Coprocessor Trap Register) on entry/return
- * (hardware reset value is 0). Keep previous value in r2.
- * An ISB is emited on vmexit/vmtrap, but executed on vmexit only if
- * VFP wasn't already enabled (always executed on vmtrap).
- * If a label is specified with vmexit, it is branched to if VFP wasn't
- * enabled.
- */
-.macro set_hcptr operation, mask, label = none
-	mrc	p15, 4, r2, c1, c1, 2
-	ldr	r3, =\mask
-	.if \operation == vmentry
-	orr	r3, r2, r3		@ Trap coproc-accesses defined in mask
-	.else
-	bic	r3, r2, r3		@ Don't trap defined coproc-accesses
-	.endif
-	mcr	p15, 4, r3, c1, c1, 2
-	.if \operation != vmentry
-	.if \operation == vmexit
-	tst	r2, #(HCPTR_TCP(10) | HCPTR_TCP(11))
-	beq	1f
-	.endif
-	isb
-	.if \label != none
-	b	\label
-	.endif
-1:
-	.endif
-.endm
-
-/* Configures the HDCR (Hyp Debug Configuration Register) on entry/return
- * (hardware reset value is 0) */
-.macro set_hdcr operation
-	mrc	p15, 4, r2, c1, c1, 1
-	ldr	r3, =(HDCR_TPM|HDCR_TPMCR)
-	.if \operation == vmentry
-	orr	r2, r2, r3		@ Trap some perfmon accesses
-	.else
-	bic	r2, r2, r3		@ Don't trap any perfmon accesses
-	.endif
-	mcr	p15, 4, r2, c1, c1, 1
-.endm
-
-/* Enable/Disable: stage-2 trans., trap interrupts, trap wfi, trap smc */
-.macro configure_hyp_role operation
-	.if \operation == vmentry
-	ldr	r2, [vcpu, #VCPU_HCR]
-	ldr	r3, [vcpu, #VCPU_IRQ_LINES]
-	orr	r2, r2, r3
-	.else
-	mov	r2, #0
-	.endif
-	mcr	p15, 4, r2, c1, c1, 0	@ HCR
-.endm
-
-.macro load_vcpu
-	mrc	p15, 4, vcpu, c13, c0, 2	@ HTPIDR
-.endm
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:29 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:29 +0000
Subject: [PATCH v2 12/28] ARM: KVM: Add VFP save/restore
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-13-git-send-email-marc.zyngier@arm.com>

This is almost a copy/paste of the existing version, with a couple
of subtle differences:
- Only write to FPEXC once on the save path
- Add an isb when enabling VFP access

The patch also defines a few sysreg accessors and a __vfp_enabled
predicate that test the VFP trapping state.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/hyp/Makefile |  1 +
 arch/arm/kvm/hyp/hyp.h    | 13 +++++++++
 arch/arm/kvm/hyp/vfp.S    | 68 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 82 insertions(+)
 create mode 100644 arch/arm/kvm/hyp/vfp.S

diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
index d8acbb6..5a45f4c 100644
--- a/arch/arm/kvm/hyp/Makefile
+++ b/arch/arm/kvm/hyp/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_KVM_ARM_HOST) += tlb.o
 obj-$(CONFIG_KVM_ARM_HOST) += cp15-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += timer-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += vgic-v2-sr.o
+obj-$(CONFIG_KVM_ARM_HOST) += vfp.o
diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
index 7eb1c21..dce0f73 100644
--- a/arch/arm/kvm/hyp/hyp.h
+++ b/arch/arm/kvm/hyp/hyp.h
@@ -21,6 +21,7 @@
 #include <linux/compiler.h>
 #include <linux/kvm_host.h>
 #include <asm/kvm_mmu.h>
+#include <asm/vfp.h>
 
 #define __hyp_text __section(.hyp.text) notrace
 
@@ -31,6 +32,8 @@
 	"mrc", "mcr", __stringify(p15, Op1, %0, CRn, CRm, Op2), u32
 #define __ACCESS_CP15_64(Op1, CRm)		\
 	"mrrc", "mcrr", __stringify(p15, Op1, %Q0, %R0, CRm), u64
+#define __ACCESS_VFP(CRn)			\
+	"mrc", "mcr", __stringify(p10, 7, %0, CRn, cr0, 0), u32
 
 #define __write_sysreg(v, r, w, c, t)	asm volatile(w " " c : : "r" ((t)(v)))
 #define write_sysreg(v, ...)		__write_sysreg(v, __VA_ARGS__)
@@ -53,6 +56,7 @@
 #define VMPIDR		__ACCESS_CP15(c0, 4, c0, 5)
 #define SCTLR		__ACCESS_CP15(c1, 0, c0, 0)
 #define CPACR		__ACCESS_CP15(c1, 0, c0, 2)
+#define HCPTR		__ACCESS_CP15(c1, 4, c1, 2)
 #define TTBCR		__ACCESS_CP15(c2, 0, c0, 2)
 #define DACR		__ACCESS_CP15(c3, 0, c0, 0)
 #define DFSR		__ACCESS_CP15(c5, 0, c0, 0)
@@ -77,6 +81,8 @@
 #define CNTV_CTL	__ACCESS_CP15(c14, 0, c3, 1)
 #define CNTHCTL		__ACCESS_CP15(c14, 4, c1, 0)
 
+#define VFP_FPEXC	__ACCESS_VFP(FPEXC)
+
 void __timer_save_state(struct kvm_vcpu *vcpu);
 void __timer_restore_state(struct kvm_vcpu *vcpu);
 
@@ -86,4 +92,11 @@ void __vgic_v2_restore_state(struct kvm_vcpu *vcpu);
 void __sysreg_save_state(struct kvm_cpu_context *ctxt);
 void __sysreg_restore_state(struct kvm_cpu_context *ctxt);
 
+void asmlinkage __vfp_save_state(struct vfp_hard_struct *vfp);
+void asmlinkage __vfp_restore_state(struct vfp_hard_struct *vfp);
+static inline bool __vfp_enabled(void)
+{
+	return !(read_sysreg(HCPTR) & (HCPTR_TCP(11) | HCPTR_TCP(10)));
+}
+
 #endif /* __ARM_KVM_HYP_H__ */
diff --git a/arch/arm/kvm/hyp/vfp.S b/arch/arm/kvm/hyp/vfp.S
new file mode 100644
index 0000000..7c297e8
--- /dev/null
+++ b/arch/arm/kvm/hyp/vfp.S
@@ -0,0 +1,68 @@
+/*
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall at virtualopensystems.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/linkage.h>
+#include <asm/vfpmacros.h>
+
+	.text
+	.pushsection	.hyp.text, "ax"
+
+/* void __vfp_save_state(struct vfp_hard_struct *vfp); */
+ENTRY(__vfp_save_state)
+	push	{r4, r5}
+	VFPFMRX	r1, FPEXC
+
+	@ Make sure *really* VFP is enabled so we can touch the registers.
+	orr	r5, r1, #FPEXC_EN
+	tst	r5, #FPEXC_EX		@ Check for VFP Subarchitecture
+	bic	r5, r5, #FPEXC_EX	@ FPEXC_EX disable
+	VFPFMXR	FPEXC, r5
+	isb
+
+	VFPFMRX	r2, FPSCR
+	beq	1f
+
+	@ If FPEXC_EX is 0, then FPINST/FPINST2 reads are upredictable, so
+	@ we only need to save them if FPEXC_EX is set.
+	VFPFMRX r3, FPINST
+	tst	r5, #FPEXC_FP2V
+	VFPFMRX r4, FPINST2, ne		@ vmrsne
+1:
+	VFPFSTMIA r0, r5		@ Save VFP registers
+	stm	r0, {r1-r4}		@ Save FPEXC, FPSCR, FPINST, FPINST2
+	pop	{r4, r5}
+	bx	lr
+ENDPROC(__vfp_save_state)
+
+/* void __vfp_restore_state(struct vfp_hard_struct *vfp);
+ * Assume FPEXC_EN is on and FPEXC_EX is off */
+ENTRY(__vfp_restore_state)
+	VFPFLDMIA r0, r1		@ Load VFP registers
+	ldm	r0, {r0-r3}		@ Load FPEXC, FPSCR, FPINST, FPINST2
+
+	VFPFMXR FPSCR, r1
+	tst	r0, #FPEXC_EX		@ Check for VFP Subarchitecture
+	beq	1f
+	VFPFMXR FPINST, r2
+	tst	r0, #FPEXC_FP2V
+	VFPFMXR FPINST2, r3, ne
+1:
+	VFPFMXR FPEXC, r0		@ FPEXC	(last, in case !EN)
+	bx	lr
+ENDPROC(__vfp_restore_state)
+
+	.popsection
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:36 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:36 +0000
Subject: [PATCH v2 19/28] ARM: KVM: Add panic handling code
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-20-git-send-email-marc.zyngier@arm.com>

Instead of spinning forever, let's "properly" handle any unexpected
exception ("properly" meaning "print a spat on the console and die").

This has proved useful quite a few times...

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/hyp/hyp-entry.S | 28 +++++++++++++++++++++-------
 arch/arm/kvm/hyp/switch.c    | 38 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 59 insertions(+), 7 deletions(-)

diff --git a/arch/arm/kvm/hyp/hyp-entry.S b/arch/arm/kvm/hyp/hyp-entry.S
index 44bc11f..ca412ad 100644
--- a/arch/arm/kvm/hyp/hyp-entry.S
+++ b/arch/arm/kvm/hyp/hyp-entry.S
@@ -75,15 +75,29 @@ __kvm_hyp_vector:
 
 .macro invalid_vector label, cause
 	.align
-\label:	b	.
+\label:	mov	r0, #\cause
+	b	__hyp_panic
 .endm
 
-	invalid_vector	hyp_reset
-	invalid_vector	hyp_undef
-	invalid_vector	hyp_svc
-	invalid_vector	hyp_pabt
-	invalid_vector	hyp_dabt
-	invalid_vector	hyp_fiq
+	invalid_vector	hyp_reset	ARM_EXCEPTION_RESET
+	invalid_vector	hyp_undef	ARM_EXCEPTION_UNDEFINED
+	invalid_vector	hyp_svc		ARM_EXCEPTION_SOFTWARE
+	invalid_vector	hyp_pabt	ARM_EXCEPTION_PREF_ABORT
+	invalid_vector	hyp_dabt	ARM_EXCEPTION_DATA_ABORT
+	invalid_vector	hyp_fiq		ARM_EXCEPTION_FIQ
+
+ENTRY(__hyp_do_panic)
+	mrs	lr, cpsr
+	bic	lr, lr, #MODE_MASK
+	orr	lr, lr, #SVC_MODE
+THUMB(	orr	lr, lr, #PSR_T_BIT	)
+	msr	spsr_cxsf, lr
+	ldr	lr, =panic
+	msr	ELR_hyp, lr
+	ldr	lr, =kvm_call_hyp
+	clrex
+	eret
+ENDPROC(__hyp_do_panic)
 
 hyp_hvc:
 	/*
diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
index 8bfd729..67f3944 100644
--- a/arch/arm/kvm/hyp/switch.c
+++ b/arch/arm/kvm/hyp/switch.c
@@ -188,3 +188,41 @@ again:
 }
 
 __alias(__guest_run) int __weak __kvm_vcpu_run(struct kvm_vcpu *vcpu);
+
+static const char * const __hyp_panic_string[] = {
+	[ARM_EXCEPTION_RESET]      = "\nHYP panic: RST?? PC:%08x CPSR:%08x",
+	[ARM_EXCEPTION_UNDEFINED]  = "\nHYP panic: UNDEF PC:%08x CPSR:%08x",
+	[ARM_EXCEPTION_SOFTWARE]   = "\nHYP panic: SVC?? PC:%08x CPSR:%08x",
+	[ARM_EXCEPTION_PREF_ABORT] = "\nHYP panic: PABRT PC:%08x CPSR:%08x",
+	[ARM_EXCEPTION_DATA_ABORT] = "\nHYP panic: DABRT PC:%08x ADDR:%08x",
+	[ARM_EXCEPTION_IRQ]        = "\nHYP panic: IRQ?? PC:%08x CPSR:%08x",
+	[ARM_EXCEPTION_FIQ]        = "\nHYP panic: FIQ?? PC:%08x CPSR:%08x",
+	[ARM_EXCEPTION_HVC]        = "\nHYP panic: HVC?? PC:%08x CPSR:%08x",
+};
+
+void __hyp_text __noreturn __hyp_panic(int cause)
+{
+	u32 elr = read_special(ELR_hyp);
+	u32 val;
+
+	if (cause == ARM_EXCEPTION_DATA_ABORT)
+		val = read_sysreg(HDFAR);
+	else
+		val = read_special(SPSR);
+
+	if (read_sysreg(VTTBR)) {
+		struct kvm_vcpu *vcpu;
+		struct kvm_cpu_context *host_ctxt;
+
+		vcpu = (struct kvm_vcpu *)read_sysreg(HTPIDR);
+		host_ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
+		__deactivate_traps(vcpu);
+		__deactivate_vm(vcpu);
+		__sysreg_restore_state(host_ctxt);
+	}
+
+	/* Call panic for real */
+	__hyp_do_panic(__hyp_panic_string[cause], elr, val);
+
+	unreachable();
+}
-- 
2.1.4



From broonie at kernel.org  Thu Feb  4 03:02:03 2016
From: broonie at kernel.org (Mark Brown)
Date: Thu, 4 Feb 2016 11:02:03 +0000
Subject: [PATCH v3 00/12] pwm: add support for atomic update
In-Reply-To: <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
References: <1442828009-6241-1-git-send-email-boris.brezillon@free-electrons.com>
 <2341981.a79ioYM9Es@diego> <20151110173416.GB21727@ulmo>
 <CAD=FV=WL3jYEgVe-m6QcAyQwfJgdX4J5OtKisKwyoKOrTSpEQA@mail.gmail.com>
 <20160125170855.GA10182@ulmo>
 <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
 <20160203145337.GD9650@ulmo>
 <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
Message-ID: <20160204110203.GL4455@sirena.org.uk>

On Wed, Feb 03, 2016 at 11:04:20AM -0800, Doug Anderson wrote:

> Sure.  ...but you agree that somehow you need a new API call for this,
> right?  Somehow the PWM regulator needs to be able to say that it
> wants the hardware state, not the initial state as specified in the
> device tree.

Wouldn't the most direct way to do that be to just not specify anything
in the DT?  If there *is* something in DT but we ignore it that's a bit
weird.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/3d4f608e/attachment-0001.sig>

From marc.zyngier at arm.com  Thu Feb  4 03:00:27 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:27 +0000
Subject: [PATCH v2 10/28] ARM: KVM: Add timer save/restore
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-11-git-send-email-marc.zyngier@arm.com>

This patch shouldn't exist, as we should be able to reuse the
arm64 version for free. I'll get there eventually, but in the
meantime I need a timer ticking.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/hyp/Makefile   |  1 +
 arch/arm/kvm/hyp/hyp.h      |  8 +++++
 arch/arm/kvm/hyp/timer-sr.c | 71 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 80 insertions(+)
 create mode 100644 arch/arm/kvm/hyp/timer-sr.c

diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
index 9f96fcb..9241ae8 100644
--- a/arch/arm/kvm/hyp/Makefile
+++ b/arch/arm/kvm/hyp/Makefile
@@ -4,3 +4,4 @@
 
 obj-$(CONFIG_KVM_ARM_HOST) += tlb.o
 obj-$(CONFIG_KVM_ARM_HOST) += cp15-sr.o
+obj-$(CONFIG_KVM_ARM_HOST) += timer-sr.o
diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
index ab2cb82..4924418 100644
--- a/arch/arm/kvm/hyp/hyp.h
+++ b/arch/arm/kvm/hyp/hyp.h
@@ -46,6 +46,9 @@
 #define TTBR1		__ACCESS_CP15_64(1, c2)
 #define VTTBR		__ACCESS_CP15_64(6, c2)
 #define PAR		__ACCESS_CP15_64(0, c7)
+#define CNTV_CVAL	__ACCESS_CP15_64(3, c14)
+#define CNTVOFF		__ACCESS_CP15_64(4, c14)
+
 #define CSSELR		__ACCESS_CP15(c0, 2, c0, 0)
 #define VMPIDR		__ACCESS_CP15(c0, 4, c0, 5)
 #define SCTLR		__ACCESS_CP15(c1, 0, c0, 0)
@@ -71,6 +74,11 @@
 #define TID_URO		__ACCESS_CP15(c13, 0, c0, 3)
 #define TID_PRIV	__ACCESS_CP15(c13, 0, c0, 4)
 #define CNTKCTL		__ACCESS_CP15(c14, 0, c1, 0)
+#define CNTV_CTL	__ACCESS_CP15(c14, 0, c3, 1)
+#define CNTHCTL		__ACCESS_CP15(c14, 4, c1, 0)
+
+void __timer_save_state(struct kvm_vcpu *vcpu);
+void __timer_restore_state(struct kvm_vcpu *vcpu);
 
 void __sysreg_save_state(struct kvm_cpu_context *ctxt);
 void __sysreg_restore_state(struct kvm_cpu_context *ctxt);
diff --git a/arch/arm/kvm/hyp/timer-sr.c b/arch/arm/kvm/hyp/timer-sr.c
new file mode 100644
index 0000000..d7535fd
--- /dev/null
+++ b/arch/arm/kvm/hyp/timer-sr.c
@@ -0,0 +1,71 @@
+/*
+ * Copyright (C) 2012-2015 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.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 <clocksource/arm_arch_timer.h>
+#include <linux/compiler.h>
+#include <linux/kvm_host.h>
+
+#include <asm/kvm_mmu.h>
+
+#include "hyp.h"
+
+/* vcpu is already in the HYP VA space */
+void __hyp_text __timer_save_state(struct kvm_vcpu *vcpu)
+{
+	struct kvm *kvm = kern_hyp_va(vcpu->kvm);
+	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
+	u64 val;
+
+	if (kvm->arch.timer.enabled) {
+		timer->cntv_ctl = read_sysreg(CNTV_CTL);
+		timer->cntv_cval = read_sysreg(CNTV_CVAL);
+	}
+
+	/* Disable the virtual timer */
+	write_sysreg(0, CNTV_CTL);
+
+	/* Allow physical timer/counter access for the host */
+	val = read_sysreg(CNTHCTL);
+	val |= CNTHCTL_EL1PCTEN | CNTHCTL_EL1PCEN;
+	write_sysreg(val, CNTHCTL);
+
+	/* Clear cntvoff for the host */
+	write_sysreg(0, CNTVOFF);
+}
+
+void __hyp_text __timer_restore_state(struct kvm_vcpu *vcpu)
+{
+	struct kvm *kvm = kern_hyp_va(vcpu->kvm);
+	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
+	u64 val;
+
+	/*
+	 * Disallow physical timer access for the guest
+	 * Physical counter access is allowed
+	 */
+	val = read_sysreg(CNTHCTL);
+	val &= ~CNTHCTL_EL1PCEN;
+	val |= CNTHCTL_EL1PCTEN;
+	write_sysreg(val, CNTHCTL);
+
+	if (kvm->arch.timer.enabled) {
+		write_sysreg(kvm->arch.timer.cntvoff, CNTVOFF);
+		write_sysreg(timer->cntv_cval, CNTV_CVAL);
+		isb();
+		write_sysreg(timer->cntv_ctl, CNTV_CTL);
+	}
+}
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:35 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:35 +0000
Subject: [PATCH v2 18/28] ARM: KVM: Add HYP mode entry code
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-19-git-send-email-marc.zyngier@arm.com>

This part is almost entierely borrowed from the existing code, just
slightly simplifying the HYP function call (as we now save SPSR_hyp
in the world switch).

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/hyp/Makefile    |   1 +
 arch/arm/kvm/hyp/hyp-entry.S | 157 +++++++++++++++++++++++++++++++++++++++++++
 arch/arm/kvm/hyp/hyp.h       |   2 +
 3 files changed, 160 insertions(+)
 create mode 100644 arch/arm/kvm/hyp/hyp-entry.S

diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
index cfab402..a7d3a7e 100644
--- a/arch/arm/kvm/hyp/Makefile
+++ b/arch/arm/kvm/hyp/Makefile
@@ -9,4 +9,5 @@ obj-$(CONFIG_KVM_ARM_HOST) += vgic-v2-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += vfp.o
 obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += entry.o
+obj-$(CONFIG_KVM_ARM_HOST) += hyp-entry.o
 obj-$(CONFIG_KVM_ARM_HOST) += switch.o
diff --git a/arch/arm/kvm/hyp/hyp-entry.S b/arch/arm/kvm/hyp/hyp-entry.S
new file mode 100644
index 0000000..44bc11f
--- /dev/null
+++ b/arch/arm/kvm/hyp/hyp-entry.S
@@ -0,0 +1,157 @@
+/*
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall at virtualopensystems.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, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ */
+
+#include <linux/linkage.h>
+#include <asm/kvm_arm.h>
+#include <asm/kvm_asm.h>
+
+	.arch_extension     virt
+
+	.text
+	.pushsection	.hyp.text, "ax"
+
+.macro load_vcpu	reg
+	mrc	p15, 4, \reg, c13, c0, 2	@ HTPIDR
+.endm
+
+/********************************************************************
+ * Hypervisor exception vector and handlers
+ *
+ *
+ * The KVM/ARM Hypervisor ABI is defined as follows:
+ *
+ * Entry to Hyp mode from the host kernel will happen _only_ when an HVC
+ * instruction is issued since all traps are disabled when running the host
+ * kernel as per the Hyp-mode initialization at boot time.
+ *
+ * HVC instructions cause a trap to the vector page + offset 0x14 (see hyp_hvc
+ * below) when the HVC instruction is called from SVC mode (i.e. a guest or the
+ * host kernel) and they cause a trap to the vector page + offset 0x8 when HVC
+ * instructions are called from within Hyp-mode.
+ *
+ * Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
+ *    Switching to Hyp mode is done through a simple HVC #0 instruction. The
+ *    exception vector code will check that the HVC comes from VMID==0.
+ *    - r0 contains a pointer to a HYP function
+ *    - r1, r2, and r3 contain arguments to the above function.
+ *    - The HYP function will be called with its arguments in r0, r1 and r2.
+ *    On HYP function return, we return directly to SVC.
+ *
+ * Note that the above is used to execute code in Hyp-mode from a host-kernel
+ * point of view, and is a different concept from performing a world-switch and
+ * executing guest code SVC mode (with a VMID != 0).
+ */
+
+	.align 5
+__hyp_vector:
+	.global	__hyp_vector
+__kvm_hyp_vector:
+	.weak __kvm_hyp_vector
+
+	@ Hyp-mode exception vector
+	W(b)	hyp_reset
+	W(b)	hyp_undef
+	W(b)	hyp_svc
+	W(b)	hyp_pabt
+	W(b)	hyp_dabt
+	W(b)	hyp_hvc
+	W(b)	hyp_irq
+	W(b)	hyp_fiq
+
+.macro invalid_vector label, cause
+	.align
+\label:	b	.
+.endm
+
+	invalid_vector	hyp_reset
+	invalid_vector	hyp_undef
+	invalid_vector	hyp_svc
+	invalid_vector	hyp_pabt
+	invalid_vector	hyp_dabt
+	invalid_vector	hyp_fiq
+
+hyp_hvc:
+	/*
+	 * Getting here is either because of a trap from a guest,
+	 * or from executing HVC from the host kernel, which means
+	 * "do something in Hyp mode".
+	 */
+	push	{r0, r1, r2}
+
+	@ Check syndrome register
+	mrc	p15, 4, r1, c5, c2, 0	@ HSR
+	lsr	r0, r1, #HSR_EC_SHIFT
+	cmp	r0, #HSR_EC_HVC
+	bne	guest_trap		@ Not HVC instr.
+
+	/*
+	 * Let's check if the HVC came from VMID 0 and allow simple
+	 * switch to Hyp mode
+	 */
+	mrrc    p15, 6, r0, r2, c2
+	lsr     r2, r2, #16
+	and     r2, r2, #0xff
+	cmp     r2, #0
+	bne	guest_trap		@ Guest called HVC
+
+	/*
+	 * Getting here means host called HVC, we shift parameters and branch
+	 * to Hyp function.
+	 */
+	pop	{r0, r1, r2}
+
+	/* Check for __hyp_get_vectors */
+	cmp	r0, #-1
+	mrceq	p15, 4, r0, c12, c0, 0	@ get HVBAR
+	beq	1f
+
+	push	{lr}
+
+	mov	lr, r0
+	mov	r0, r1
+	mov	r1, r2
+	mov	r2, r3
+
+THUMB(	orr	lr, #1)
+	blx	lr			@ Call the HYP function
+
+	pop	{lr}
+1:	eret
+
+guest_trap:
+	load_vcpu r0			@ Load VCPU pointer to r0
+
+	@ Check if we need the fault information
+	lsr	r1, r1, #HSR_EC_SHIFT
+#ifdef CONFIG_VFPv3
+	cmp	r1, #HSR_EC_CP_0_13
+	beq	__vfp_guest_restore
+#endif
+
+	mov	r1, #ARM_EXCEPTION_HVC
+	b	__guest_exit
+
+hyp_irq:
+	push	{r0, r1, r2}
+	mov	r1, #ARM_EXCEPTION_IRQ
+	load_vcpu r0			@ Load VCPU pointer to r0
+	b	__guest_exit
+
+	.ltorg
+
+	.popsection
diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
index 7ddca54..8bbd2a7 100644
--- a/arch/arm/kvm/hyp/hyp.h
+++ b/arch/arm/kvm/hyp/hyp.h
@@ -123,4 +123,6 @@ void __hyp_text __banked_restore_state(struct kvm_cpu_context *ctxt);
 
 int asmlinkage __guest_enter(struct kvm_vcpu *vcpu,
 			     struct kvm_cpu_context *host);
+int asmlinkage __hyp_do_panic(const char *, int, u32);
+
 #endif /* __ARM_KVM_HYP_H__ */
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:45 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:45 +0000
Subject: [PATCH v2 28/28] ARM: KVM: Remove __kvm_hyp_exit/__kvm_hyp_exit_end
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-29-git-send-email-marc.zyngier@arm.com>

I have no idea what these were for - probably a leftover from an
early implementation. Good bye!

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_asm.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index 083825f..15d58b4 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -55,9 +55,6 @@ struct kvm_vcpu;
 extern char __kvm_hyp_init[];
 extern char __kvm_hyp_init_end[];
 
-extern char __kvm_hyp_exit[];
-extern char __kvm_hyp_exit_end[];
-
 extern char __kvm_hyp_vector[];
 
 extern void __kvm_flush_vm_context(void);
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:34 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:34 +0000
Subject: [PATCH v2 17/28] ARM: KVM: Add populating of fault data structure
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-18-git-send-email-marc.zyngier@arm.com>

On guest exit, we must take care of populating our fault data
structure so that the host code can handle it. This includes
resolving the IPA for permission faults, which can result in
restarting the guest.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/hyp/hyp.h    |  4 ++++
 arch/arm/kvm/hyp/switch.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 58 insertions(+)

diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
index 2ca651f..7ddca54 100644
--- a/arch/arm/kvm/hyp/hyp.h
+++ b/arch/arm/kvm/hyp/hyp.h
@@ -76,10 +76,14 @@
 #define IFSR		__ACCESS_CP15(c5, 0, c0, 1)
 #define ADFSR		__ACCESS_CP15(c5, 0, c1, 0)
 #define AIFSR		__ACCESS_CP15(c5, 0, c1, 1)
+#define HSR		__ACCESS_CP15(c5, 4, c2, 0)
 #define DFAR		__ACCESS_CP15(c6, 0, c0, 0)
 #define IFAR		__ACCESS_CP15(c6, 0, c0, 2)
 #define HDFAR		__ACCESS_CP15(c6, 4, c0, 0)
+#define HIFAR		__ACCESS_CP15(c6, 4, c0, 2)
+#define HPFAR		__ACCESS_CP15(c6, 4, c0, 4)
 #define ICIALLUIS	__ACCESS_CP15(c7, 0, c1, 0)
+#define ATS1CPR		__ACCESS_CP15(c7, 0, c8, 0)
 #define TLBIALLIS	__ACCESS_CP15(c8, 0, c3, 0)
 #define TLBIALLNSNHIS	__ACCESS_CP15(c8, 4, c3, 4)
 #define PRRR		__ACCESS_CP15(c10, 0, c2, 0)
diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
index f715b0d..8bfd729 100644
--- a/arch/arm/kvm/hyp/switch.c
+++ b/arch/arm/kvm/hyp/switch.c
@@ -80,6 +80,56 @@ static void __hyp_text __vgic_restore_state(struct kvm_vcpu *vcpu)
 	__vgic_v2_restore_state(vcpu);
 }
 
+static bool __hyp_text __populate_fault_info(struct kvm_vcpu *vcpu)
+{
+	u32 hsr = read_sysreg(HSR);
+	u8 ec = hsr >> HSR_EC_SHIFT;
+	u32 hpfar, far;
+
+	vcpu->arch.fault.hsr = hsr;
+
+	if (ec == HSR_EC_IABT)
+		far = read_sysreg(HIFAR);
+	else if (ec == HSR_EC_DABT)
+		far = read_sysreg(HDFAR);
+	else
+		return true;
+
+	/*
+	 * B3.13.5 Reporting exceptions taken to the Non-secure PL2 mode:
+	 *
+	 * Abort on the stage 2 translation for a memory access from a
+	 * Non-secure PL1 or PL0 mode:
+	 *
+	 * For any Access flag fault or Translation fault, and also for any
+	 * Permission fault on the stage 2 translation of a memory access
+	 * made as part of a translation table walk for a stage 1 translation,
+	 * the HPFAR holds the IPA that caused the fault. Otherwise, the HPFAR
+	 * is UNKNOWN.
+	 */
+	if (!(hsr & HSR_DABT_S1PTW) && (hsr & HSR_FSC_TYPE) == FSC_PERM) {
+		u64 par, tmp;
+
+		par = read_sysreg(PAR);
+		write_sysreg(far, ATS1CPR);
+		isb();
+
+		tmp = read_sysreg(PAR);
+		write_sysreg(par, PAR);
+
+		if (unlikely(tmp & 1))
+			return false; /* Translation failed, back to guest */
+
+		hpfar = ((tmp >> 12) & ((1UL << 28) - 1)) << 4;
+	} else {
+		hpfar = read_sysreg(HPFAR);
+	}
+
+	vcpu->arch.fault.hxfar = far;
+	vcpu->arch.fault.hpfar = hpfar;
+	return true;
+}
+
 static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
 {
 	struct kvm_cpu_context *host_ctxt;
@@ -107,9 +157,13 @@ static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
 	__banked_restore_state(guest_ctxt);
 
 	/* Jump in the fire! */
+again:
 	exit_code = __guest_enter(vcpu, host_ctxt);
 	/* And we're baaack! */
 
+	if (exit_code == ARM_EXCEPTION_HVC && !__populate_fault_info(vcpu))
+		goto again;
+
 	fp_enabled = __vfp_enabled();
 
 	__banked_save_state(guest_ctxt);
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:31 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:31 +0000
Subject: [PATCH v2 14/28] ARM: KVM: Add guest entry code
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-15-git-send-email-marc.zyngier@arm.com>

Add the very minimal piece of code that is now required to jump
into the guest (and return from it). This code is only concerned
with save/restoring the USR registers (r0-r12+lr for the guest,
r4-r12+lr for the host), as everything else is dealt with in C
(VFP is another matter though).

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/hyp/Makefile |  1 +
 arch/arm/kvm/hyp/entry.S  | 70 +++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm/kvm/hyp/hyp.h    |  2 ++
 3 files changed, 73 insertions(+)
 create mode 100644 arch/arm/kvm/hyp/entry.S

diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
index 173bd1d..c779690 100644
--- a/arch/arm/kvm/hyp/Makefile
+++ b/arch/arm/kvm/hyp/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_KVM_ARM_HOST) += timer-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += vgic-v2-sr.o
 obj-$(CONFIG_KVM_ARM_HOST) += vfp.o
 obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o
+obj-$(CONFIG_KVM_ARM_HOST) += entry.o
diff --git a/arch/arm/kvm/hyp/entry.S b/arch/arm/kvm/hyp/entry.S
new file mode 100644
index 0000000..32f79b0
--- /dev/null
+++ b/arch/arm/kvm/hyp/entry.S
@@ -0,0 +1,70 @@
+/*
+ * Copyright (C) 2016 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.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/linkage.h>
+#include <asm/asm-offsets.h>
+#include <asm/kvm_arm.h>
+
+	.arch_extension     virt
+
+	.text
+	.pushsection	.hyp.text, "ax"
+
+#define USR_REGS_OFFSET		(CPU_CTXT_GP_REGS + GP_REGS_USR)
+
+/* int __guest_enter(struct kvm_vcpu *vcpu, struct kvm_cpu_context *host) */
+ENTRY(__guest_enter)
+	@ Save host registers
+	add	r1, r1, #(USR_REGS_OFFSET + S_R4)
+	stm	r1!, {r4-r12}
+	str	lr, [r1, #4]	@ Skip SP_usr (already saved)
+
+	@ Restore guest registers
+	add	r0, r0,  #(VCPU_GUEST_CTXT + USR_REGS_OFFSET + S_R0)
+	ldr	lr, [r0, #S_LR]
+	ldm	r0, {r0-r12}
+
+	clrex
+	eret
+ENDPROC(__guest_enter)
+
+ENTRY(__guest_exit)
+	/*
+	 * return convention:
+	 * guest r0, r1, r2 saved on the stack
+	 * r0: vcpu pointer
+	 * r1: exception code
+	 */
+
+	add	r2, r0, #(VCPU_GUEST_CTXT + USR_REGS_OFFSET + S_R3)
+	stm	r2!, {r3-r12}
+	str	lr, [r2, #4]
+	add	r2, r0, #(VCPU_GUEST_CTXT + USR_REGS_OFFSET + S_R0)
+	pop	{r3, r4, r5}		@ r0, r1, r2
+	stm	r2, {r3-r5}
+
+	ldr	r0, [r0, #VCPU_HOST_CTXT]
+	add	r0, r0, #(USR_REGS_OFFSET + S_R4)
+	ldm	r0!, {r4-r12}
+	ldr	lr, [r0, #4]
+
+	mov	r0, r1
+	bx	lr
+ENDPROC(__guest_exit)
+
+	.popsection
+
diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
index 278eb1f..b3f6ed2 100644
--- a/arch/arm/kvm/hyp/hyp.h
+++ b/arch/arm/kvm/hyp/hyp.h
@@ -110,4 +110,6 @@ static inline bool __vfp_enabled(void)
 void __hyp_text __banked_save_state(struct kvm_cpu_context *ctxt);
 void __hyp_text __banked_restore_state(struct kvm_cpu_context *ctxt);
 
+int asmlinkage __guest_enter(struct kvm_vcpu *vcpu,
+			     struct kvm_cpu_context *host);
 #endif /* __ARM_KVM_HYP_H__ */
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:21 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:21 +0000
Subject: [PATCH v2 04/28] ARM: KVM: Move CP15 array into the CPU context
 structure
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-5-git-send-email-marc.zyngier@arm.com>

Continuing our rework of the CPU context, we now move the CP15
array into the CPU context structure. As this causes quite a bit
of churn, we introduce the vcpu_cp15() macro that abstract the
location of the actual array. This will probably help next time
we have to revisit that code.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_emulate.h |  2 +-
 arch/arm/include/asm/kvm_host.h    |  6 +++---
 arch/arm/include/asm/kvm_mmu.h     |  2 +-
 arch/arm/kernel/asm-offsets.c      |  2 +-
 arch/arm/kvm/coproc.c              | 32 ++++++++++++++++----------------
 arch/arm/kvm/coproc.h              | 16 ++++++++--------
 arch/arm/kvm/emulate.c             | 22 +++++++++++-----------
 arch/arm/kvm/interrupts_head.S     |  3 ++-
 8 files changed, 43 insertions(+), 42 deletions(-)

diff --git a/arch/arm/include/asm/kvm_emulate.h b/arch/arm/include/asm/kvm_emulate.h
index 3095df0..32bb52a 100644
--- a/arch/arm/include/asm/kvm_emulate.h
+++ b/arch/arm/include/asm/kvm_emulate.h
@@ -192,7 +192,7 @@ static inline u32 kvm_vcpu_hvc_get_imm(struct kvm_vcpu *vcpu)
 
 static inline unsigned long kvm_vcpu_get_mpidr_aff(struct kvm_vcpu *vcpu)
 {
-	return vcpu->arch.cp15[c0_MPIDR] & MPIDR_HWID_BITMASK;
+	return vcpu_cp15(vcpu, c0_MPIDR) & MPIDR_HWID_BITMASK;
 }
 
 static inline void kvm_vcpu_set_be(struct kvm_vcpu *vcpu)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index b64ac8e..4203701 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -90,6 +90,7 @@ struct kvm_vcpu_fault_info {
 
 struct kvm_cpu_context {
 	struct vfp_hard_struct vfp;
+	u32 cp15[NR_CP15_REGS];
 };
 
 typedef struct kvm_cpu_context kvm_cpu_context_t;
@@ -102,9 +103,6 @@ struct kvm_vcpu_arch {
 	int target; /* Processor target */
 	DECLARE_BITMAP(features, KVM_VCPU_MAX_FEATURES);
 
-	/* System control coprocessor (cp15) */
-	u32 cp15[NR_CP15_REGS];
-
 	/* The CPU type we expose to the VM */
 	u32 midr;
 
@@ -161,6 +159,8 @@ struct kvm_vcpu_stat {
 	u64 exits;
 };
 
+#define vcpu_cp15(v,r)	(v)->arch.ctxt.cp15[r]
+
 int kvm_vcpu_preferred_target(struct kvm_vcpu_init *init);
 unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
 int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index a520b79..da44be9 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -179,7 +179,7 @@ struct kvm;
 
 static inline bool vcpu_has_cache_enabled(struct kvm_vcpu *vcpu)
 {
-	return (vcpu->arch.cp15[c1_SCTLR] & 0b101) == 0b101;
+	return (vcpu_cp15(vcpu, c1_SCTLR) & 0b101) == 0b101;
 }
 
 static inline void __coherent_cache_guest_page(struct kvm_vcpu *vcpu,
diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
index 346bfca..43f8b01 100644
--- a/arch/arm/kernel/asm-offsets.c
+++ b/arch/arm/kernel/asm-offsets.c
@@ -172,10 +172,10 @@ int main(void)
 #ifdef CONFIG_KVM_ARM_HOST
   DEFINE(VCPU_KVM,		offsetof(struct kvm_vcpu, kvm));
   DEFINE(VCPU_MIDR,		offsetof(struct kvm_vcpu, arch.midr));
-  DEFINE(VCPU_CP15,		offsetof(struct kvm_vcpu, arch.cp15));
   DEFINE(VCPU_GUEST_CTXT,	offsetof(struct kvm_vcpu, arch.ctxt));
   DEFINE(VCPU_HOST_CTXT,	offsetof(struct kvm_vcpu, arch.host_cpu_context));
   DEFINE(CPU_CTXT_VFP,		offsetof(struct kvm_cpu_context, vfp));
+  DEFINE(CPU_CTXT_CP15,		offsetof(struct kvm_cpu_context, cp15));
   DEFINE(VCPU_REGS,		offsetof(struct kvm_vcpu, arch.regs));
   DEFINE(VCPU_USR_REGS,		offsetof(struct kvm_vcpu, arch.regs.usr_regs));
   DEFINE(VCPU_SVC_REGS,		offsetof(struct kvm_vcpu, arch.regs.svc_regs));
diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index 1a643f3..e3e86c4 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -54,8 +54,8 @@ static inline void vcpu_cp15_reg64_set(struct kvm_vcpu *vcpu,
 				       const struct coproc_reg *r,
 				       u64 val)
 {
-	vcpu->arch.cp15[r->reg] = val & 0xffffffff;
-	vcpu->arch.cp15[r->reg + 1] = val >> 32;
+	vcpu_cp15(vcpu, r->reg) = val & 0xffffffff;
+	vcpu_cp15(vcpu, r->reg + 1) = val >> 32;
 }
 
 static inline u64 vcpu_cp15_reg64_get(struct kvm_vcpu *vcpu,
@@ -63,9 +63,9 @@ static inline u64 vcpu_cp15_reg64_get(struct kvm_vcpu *vcpu,
 {
 	u64 val;
 
-	val = vcpu->arch.cp15[r->reg + 1];
+	val = vcpu_cp15(vcpu, r->reg + 1);
 	val = val << 32;
-	val = val | vcpu->arch.cp15[r->reg];
+	val = val | vcpu_cp15(vcpu, r->reg);
 	return val;
 }
 
@@ -104,7 +104,7 @@ static void reset_mpidr(struct kvm_vcpu *vcpu, const struct coproc_reg *r)
 	 * vcpu_id, but we read the 'U' bit from the underlying
 	 * hardware directly.
 	 */
-	vcpu->arch.cp15[c0_MPIDR] = ((read_cpuid_mpidr() & MPIDR_SMP_BITMASK) |
+	vcpu_cp15(vcpu, c0_MPIDR) = ((read_cpuid_mpidr() & MPIDR_SMP_BITMASK) |
 				     ((vcpu->vcpu_id >> 2) << MPIDR_LEVEL_BITS) |
 				     (vcpu->vcpu_id & 3));
 }
@@ -117,7 +117,7 @@ static bool access_actlr(struct kvm_vcpu *vcpu,
 	if (p->is_write)
 		return ignore_write(vcpu, p);
 
-	*vcpu_reg(vcpu, p->Rt1) = vcpu->arch.cp15[c1_ACTLR];
+	*vcpu_reg(vcpu, p->Rt1) = vcpu_cp15(vcpu, c1_ACTLR);
 	return true;
 }
 
@@ -139,7 +139,7 @@ static bool access_l2ctlr(struct kvm_vcpu *vcpu,
 	if (p->is_write)
 		return ignore_write(vcpu, p);
 
-	*vcpu_reg(vcpu, p->Rt1) = vcpu->arch.cp15[c9_L2CTLR];
+	*vcpu_reg(vcpu, p->Rt1) = vcpu_cp15(vcpu, c9_L2CTLR);
 	return true;
 }
 
@@ -156,7 +156,7 @@ static void reset_l2ctlr(struct kvm_vcpu *vcpu, const struct coproc_reg *r)
 	ncores = min(ncores, 3U);
 	l2ctlr |= (ncores & 3) << 24;
 
-	vcpu->arch.cp15[c9_L2CTLR] = l2ctlr;
+	vcpu_cp15(vcpu, c9_L2CTLR) = l2ctlr;
 }
 
 static void reset_actlr(struct kvm_vcpu *vcpu, const struct coproc_reg *r)
@@ -171,7 +171,7 @@ static void reset_actlr(struct kvm_vcpu *vcpu, const struct coproc_reg *r)
 	else
 		actlr &= ~(1U << 6);
 
-	vcpu->arch.cp15[c1_ACTLR] = actlr;
+	vcpu_cp15(vcpu, c1_ACTLR) = actlr;
 }
 
 /*
@@ -218,9 +218,9 @@ bool access_vm_reg(struct kvm_vcpu *vcpu,
 
 	BUG_ON(!p->is_write);
 
-	vcpu->arch.cp15[r->reg] = *vcpu_reg(vcpu, p->Rt1);
+	vcpu_cp15(vcpu, r->reg) = *vcpu_reg(vcpu, p->Rt1);
 	if (p->is_64bit)
-		vcpu->arch.cp15[r->reg + 1] = *vcpu_reg(vcpu, p->Rt2);
+		vcpu_cp15(vcpu, r->reg + 1) = *vcpu_reg(vcpu, p->Rt2);
 
 	kvm_toggle_cache(vcpu, was_enabled);
 	return true;
@@ -1030,7 +1030,7 @@ int kvm_arm_coproc_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 		val = vcpu_cp15_reg64_get(vcpu, r);
 		ret = reg_to_user(uaddr, &val, reg->id);
 	} else if (KVM_REG_SIZE(reg->id) == 4) {
-		ret = reg_to_user(uaddr, &vcpu->arch.cp15[r->reg], reg->id);
+		ret = reg_to_user(uaddr, &vcpu_cp15(vcpu, r->reg), reg->id);
 	}
 
 	return ret;
@@ -1060,7 +1060,7 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 		if (!ret)
 			vcpu_cp15_reg64_set(vcpu, r, val);
 	} else if (KVM_REG_SIZE(reg->id) == 4) {
-		ret = reg_from_user(&vcpu->arch.cp15[r->reg], uaddr, reg->id);
+		ret = reg_from_user(&vcpu_cp15(vcpu, r->reg), uaddr, reg->id);
 	}
 
 	return ret;
@@ -1248,7 +1248,7 @@ void kvm_reset_coprocs(struct kvm_vcpu *vcpu)
 	const struct coproc_reg *table;
 
 	/* Catch someone adding a register without putting in reset entry. */
-	memset(vcpu->arch.cp15, 0x42, sizeof(vcpu->arch.cp15));
+	memset(vcpu->arch.ctxt.cp15, 0x42, sizeof(vcpu->arch.ctxt.cp15));
 
 	/* Generic chip reset first (so target could override). */
 	reset_coproc_regs(vcpu, cp15_regs, ARRAY_SIZE(cp15_regs));
@@ -1257,6 +1257,6 @@ void kvm_reset_coprocs(struct kvm_vcpu *vcpu)
 	reset_coproc_regs(vcpu, table, num);
 
 	for (num = 1; num < NR_CP15_REGS; num++)
-		if (vcpu->arch.cp15[num] == 0x42424242)
-			panic("Didn't reset vcpu->arch.cp15[%zi]", num);
+		if (vcpu_cp15(vcpu, num) == 0x42424242)
+			panic("Didn't reset vcpu_cp15(vcpu, %zi)", num);
 }
diff --git a/arch/arm/kvm/coproc.h b/arch/arm/kvm/coproc.h
index 88d24a3..2735132 100644
--- a/arch/arm/kvm/coproc.h
+++ b/arch/arm/kvm/coproc.h
@@ -47,7 +47,7 @@ struct coproc_reg {
 	/* Initialization for vcpu. */
 	void (*reset)(struct kvm_vcpu *, const struct coproc_reg *);
 
-	/* Index into vcpu->arch.cp15[], or 0 if we don't need to save it. */
+	/* Index into vcpu_cp15(vcpu, ...), or 0 if we don't need to save it. */
 	unsigned long reg;
 
 	/* Value (usually reset value) */
@@ -104,25 +104,25 @@ static inline void reset_unknown(struct kvm_vcpu *vcpu,
 				 const struct coproc_reg *r)
 {
 	BUG_ON(!r->reg);
-	BUG_ON(r->reg >= ARRAY_SIZE(vcpu->arch.cp15));
-	vcpu->arch.cp15[r->reg] = 0xdecafbad;
+	BUG_ON(r->reg >= ARRAY_SIZE(vcpu->arch.ctxt.cp15));
+	vcpu_cp15(vcpu, r->reg) = 0xdecafbad;
 }
 
 static inline void reset_val(struct kvm_vcpu *vcpu, const struct coproc_reg *r)
 {
 	BUG_ON(!r->reg);
-	BUG_ON(r->reg >= ARRAY_SIZE(vcpu->arch.cp15));
-	vcpu->arch.cp15[r->reg] = r->val;
+	BUG_ON(r->reg >= ARRAY_SIZE(vcpu->arch.ctxt.cp15));
+	vcpu_cp15(vcpu, r->reg) = r->val;
 }
 
 static inline void reset_unknown64(struct kvm_vcpu *vcpu,
 				   const struct coproc_reg *r)
 {
 	BUG_ON(!r->reg);
-	BUG_ON(r->reg + 1 >= ARRAY_SIZE(vcpu->arch.cp15));
+	BUG_ON(r->reg + 1 >= ARRAY_SIZE(vcpu->arch.ctxt.cp15));
 
-	vcpu->arch.cp15[r->reg] = 0xdecafbad;
-	vcpu->arch.cp15[r->reg+1] = 0xd0c0ffee;
+	vcpu_cp15(vcpu, r->reg) = 0xdecafbad;
+	vcpu_cp15(vcpu, r->reg+1) = 0xd0c0ffee;
 }
 
 static inline int cmp_reg(const struct coproc_reg *i1,
diff --git a/arch/arm/kvm/emulate.c b/arch/arm/kvm/emulate.c
index dc99159..ee161b1 100644
--- a/arch/arm/kvm/emulate.c
+++ b/arch/arm/kvm/emulate.c
@@ -266,8 +266,8 @@ void kvm_skip_instr(struct kvm_vcpu *vcpu, bool is_wide_instr)
 
 static u32 exc_vector_base(struct kvm_vcpu *vcpu)
 {
-	u32 sctlr = vcpu->arch.cp15[c1_SCTLR];
-	u32 vbar = vcpu->arch.cp15[c12_VBAR];
+	u32 sctlr = vcpu_cp15(vcpu, c1_SCTLR);
+	u32 vbar = vcpu_cp15(vcpu, c12_VBAR);
 
 	if (sctlr & SCTLR_V)
 		return 0xffff0000;
@@ -282,7 +282,7 @@ static u32 exc_vector_base(struct kvm_vcpu *vcpu)
 static void kvm_update_psr(struct kvm_vcpu *vcpu, unsigned long mode)
 {
 	unsigned long cpsr = *vcpu_cpsr(vcpu);
-	u32 sctlr = vcpu->arch.cp15[c1_SCTLR];
+	u32 sctlr = vcpu_cp15(vcpu, c1_SCTLR);
 
 	*vcpu_cpsr(vcpu) = (cpsr & ~MODE_MASK) | mode;
 
@@ -357,22 +357,22 @@ static void inject_abt(struct kvm_vcpu *vcpu, bool is_pabt, unsigned long addr)
 
 	if (is_pabt) {
 		/* Set IFAR and IFSR */
-		vcpu->arch.cp15[c6_IFAR] = addr;
-		is_lpae = (vcpu->arch.cp15[c2_TTBCR] >> 31);
+		vcpu_cp15(vcpu, c6_IFAR) = addr;
+		is_lpae = (vcpu_cp15(vcpu, c2_TTBCR) >> 31);
 		/* Always give debug fault for now - should give guest a clue */
 		if (is_lpae)
-			vcpu->arch.cp15[c5_IFSR] = 1 << 9 | 0x22;
+			vcpu_cp15(vcpu, c5_IFSR) = 1 << 9 | 0x22;
 		else
-			vcpu->arch.cp15[c5_IFSR] = 2;
+			vcpu_cp15(vcpu, c5_IFSR) = 2;
 	} else { /* !iabt */
 		/* Set DFAR and DFSR */
-		vcpu->arch.cp15[c6_DFAR] = addr;
-		is_lpae = (vcpu->arch.cp15[c2_TTBCR] >> 31);
+		vcpu_cp15(vcpu, c6_DFAR) = addr;
+		is_lpae = (vcpu_cp15(vcpu, c2_TTBCR) >> 31);
 		/* Always give debug fault for now - should give guest a clue */
 		if (is_lpae)
-			vcpu->arch.cp15[c5_DFSR] = 1 << 9 | 0x22;
+			vcpu_cp15(vcpu, c5_DFSR) = 1 << 9 | 0x22;
 		else
-			vcpu->arch.cp15[c5_DFSR] = 2;
+			vcpu_cp15(vcpu, c5_DFSR) = 2;
 	}
 
 }
diff --git a/arch/arm/kvm/interrupts_head.S b/arch/arm/kvm/interrupts_head.S
index 51a5950..b9d9531 100644
--- a/arch/arm/kvm/interrupts_head.S
+++ b/arch/arm/kvm/interrupts_head.S
@@ -4,7 +4,8 @@
 #define VCPU_USR_REG(_reg_nr)	(VCPU_USR_REGS + (_reg_nr * 4))
 #define VCPU_USR_SP		(VCPU_USR_REG(13))
 #define VCPU_USR_LR		(VCPU_USR_REG(14))
-#define CP15_OFFSET(_cp15_reg_idx) (VCPU_CP15 + (_cp15_reg_idx * 4))
+#define VCPU_CP15_BASE		(VCPU_GUEST_CTXT + CPU_CTXT_CP15)
+#define CP15_OFFSET(_cp15_reg_idx) (VCPU_CP15_BASE + (_cp15_reg_idx * 4))
 
 /*
  * Many of these macros need to access the VCPU structure, which is always
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:17 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:17 +0000
Subject: [PATCH v2 00/28] ARM: KVM: Rewrite the world switch in C (mostly)
Message-ID: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>

Now that the arm64 rewrite is in mainline, I've taken a stab at fixing
the 32bit code the same way. This is fairly straightforward (once
you've been through it once...), with a few patches that adapt the
code to be similar to the 64bit version.

Note that the timer and GIC code should be made common between the two
architectures, as this is litterally the exact same code (I've posted
some proof of concept for that a while ago, see
http://www.spinics.net/lists/kvm/msg126775.html).

This has been tested on a Dual A7, and the code is pushed on a branch:

git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm/wsinc

	M.

* From v1:
  - Rebased on -rc2
  - Moved VTCR setup out of the init sequence (and into C code)
  - Now depends on the first patch of the VHE series

Marc Zyngier (28):
  ARM: KVM: Move the  HYP code to its own section
  ARM: KVM: Remove __kvm_hyp_code_start/__kvm_hyp_code_end
  ARM: KVM: Move VFP registers to a CPU context structure
  ARM: KVM: Move CP15 array into the CPU context structure
  ARM: KVM: Move GP registers into the CPU context structure
  ARM: KVM: Add a HYP-specific header file
  ARM: KVM: Add system register accessor macros
  ARM: KVM: Add TLB invalidation code
  ARM: KVM: Add CP15 save/restore code
  ARM: KVM: Add timer save/restore
  ARM: KVM: Add vgic v2 save/restore
  ARM: KVM: Add VFP save/restore
  ARM: KVM: Add banked registers save/restore
  ARM: KVM: Add guest entry code
  ARM: KVM: Add VFP lazy save/restore handler
  ARM: KVM: Add the new world switch implementation
  ARM: KVM: Add populating of fault data structure
  ARM: KVM: Add HYP mode entry code
  ARM: KVM: Add panic handling code
  ARM: KVM: Change kvm_call_hyp return type to unsigned long
  ARM: KVM: Remove the old world switch
  ARM: KVM: Switch to C-based stage2 init
  ARM: KVM: Remove __weak attributes
  ARM: KVM: Turn CP15 defines to an enum
  ARM: KVM: Cleanup asm-offsets.c
  ARM: KVM: Remove unused hyp_pc field
  ARM: KVM: Remove handling of ARM_EXCEPTION_DATA/PREF_ABORT
  ARM: KVM: Remove __kvm_hyp_exit/__kvm_hyp_exit_end

 arch/arm/include/asm/kvm_asm.h     |  41 +--
 arch/arm/include/asm/kvm_emulate.h |  15 +-
 arch/arm/include/asm/kvm_host.h    |  61 +++-
 arch/arm/include/asm/kvm_mmu.h     |   2 +-
 arch/arm/include/asm/virt.h        |   4 +
 arch/arm/kernel/asm-offsets.c      |  40 +--
 arch/arm/kernel/vmlinux.lds.S      |   6 +
 arch/arm/kvm/Makefile              |   1 +
 arch/arm/kvm/arm.c                 |   2 +-
 arch/arm/kvm/coproc.c              |  52 +--
 arch/arm/kvm/coproc.h              |  16 +-
 arch/arm/kvm/emulate.c             |  34 +-
 arch/arm/kvm/guest.c               |   5 +-
 arch/arm/kvm/handle_exit.c         |   7 -
 arch/arm/kvm/hyp/Makefile          |  14 +
 arch/arm/kvm/hyp/banked-sr.c       |  77 +++++
 arch/arm/kvm/hyp/cp15-sr.c         |  84 +++++
 arch/arm/kvm/hyp/entry.S           | 101 ++++++
 arch/arm/kvm/hyp/hyp-entry.S       | 169 ++++++++++
 arch/arm/kvm/hyp/hyp.h             | 130 ++++++++
 arch/arm/kvm/hyp/s2-setup.c        |  34 ++
 arch/arm/kvm/hyp/switch.c          | 228 +++++++++++++
 arch/arm/kvm/hyp/timer-sr.c        |  71 ++++
 arch/arm/kvm/hyp/tlb.c             |  71 ++++
 arch/arm/kvm/hyp/vfp.S             |  68 ++++
 arch/arm/kvm/hyp/vgic-v2-sr.c      |  84 +++++
 arch/arm/kvm/init.S                |   8 -
 arch/arm/kvm/interrupts.S          | 480 +--------------------------
 arch/arm/kvm/interrupts_head.S     | 648 -------------------------------------
 arch/arm/kvm/reset.c               |   2 +-
 arch/arm64/include/asm/kvm_asm.h   |   3 -
 31 files changed, 1265 insertions(+), 1293 deletions(-)
 create mode 100644 arch/arm/kvm/hyp/Makefile
 create mode 100644 arch/arm/kvm/hyp/banked-sr.c
 create mode 100644 arch/arm/kvm/hyp/cp15-sr.c
 create mode 100644 arch/arm/kvm/hyp/entry.S
 create mode 100644 arch/arm/kvm/hyp/hyp-entry.S
 create mode 100644 arch/arm/kvm/hyp/hyp.h
 create mode 100644 arch/arm/kvm/hyp/s2-setup.c
 create mode 100644 arch/arm/kvm/hyp/switch.c
 create mode 100644 arch/arm/kvm/hyp/timer-sr.c
 create mode 100644 arch/arm/kvm/hyp/tlb.c
 create mode 100644 arch/arm/kvm/hyp/vfp.S
 create mode 100644 arch/arm/kvm/hyp/vgic-v2-sr.c
 delete mode 100644 arch/arm/kvm/interrupts_head.S

-- 
2.1.4



From codekipper at gmail.com  Thu Feb  4 03:09:21 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Thu,  4 Feb 2016 12:09:21 +0100
Subject: [PATCH v4 1/2] dt-bindings: sunxi :add sun4i SPDIF transceiver
In-Reply-To: <1454584162-32449-1-git-send-email-codekipper@gmail.com>
References: <1454584162-32449-1-git-send-email-codekipper@gmail.com>
Message-ID: <1454584162-32449-2-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

Add devicetree bindings for the SPDIF transceiver found on
found on Allwinners A10 and A20 SoCs.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
 .../bindings/sound/sunxi,sun4i-spdif.txt           | 39 ++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt

diff --git a/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
new file mode 100644
index 0000000..13503aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
@@ -0,0 +1,39 @@
+Allwinner Sony/Philips Digital Interface Format (S/PDIF) Controller
+
+The Allwinner S/PDIF audio block is a transceiver that allows the
+processor to receive and transmit digital audio via an coaxial cable or
+a fibre cable.
+For now only playback is supported.
+
+Required properties:
+
+  - compatible		: should be one of the following:
+    - "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC
+
+  - reg			: Offset and length of the register set for the device.
+
+  - interrupts		: Contains the spdif interrupt.
+
+  - dmas		: Generic dma devicetree binding as described in
+			  Documentation/devicetree/bindings/dma/dma.txt.
+
+  - dma-names		: Two dmas have to be defined, "tx" and "rx".
+
+  - clocks		: Contains an entry for each entry in clock-names.
+
+  - clock-names		: Includes the following entries:
+	"apb"		  clock for the spdif bus.
+	"spdif"		  clock for spdif controller.
+
+Example:
+
+spdif: spdif at 01c21000 {
+	compatible = "allwinner,sun4i-a10-spdif";
+	reg = <0x01c21000 0x40>;
+	interrupts = <13>;
+	clocks = <&apb0_gates 1>, <&spdif_clk>;
+	clock-names = "apb", "spdif";
+	dmas = <&dma 0 2>, <&dma 0 2>;
+	dma-names = "rx", "tx";
+	status = "okay";
+};
-- 
2.7.0



From codekipper at gmail.com  Thu Feb  4 03:09:20 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Thu,  4 Feb 2016 12:09:20 +0100
Subject: [PATCH v4 0/2] ASoC: Add SPDIF support for Allwinner SoCs
Message-ID: <1454584162-32449-1-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

This patch set adds support for the Allwinner SPDIF transceiver.

For now just the SPDIF transmitter has been tested on a Mele A2000(A10)
and a Itead Ibox(A20).

In order for this patch set to be functional we require an audio clock patch
which will be delivered separately. For those that are interested I've pushed
the patches here with all the required changes to get SPDIF audio out of the
device.

https://github.com/codekipper/linux-sunxi/commits/spdif_delivery

Thanks in advance,
CK

---
Changes since v3:
- removed code required for spdif capture
- added disable/enable of apb clk to suspend/resume.
- removed unnecessary dt checks in probe
- fixed error conditions in probe/resume
- modified pm_runtime functionality(confirmed driver worked with PM disabled).
- removed .owner from platform driver
- renamed bindings file
 
Changes since v2:
- removed sunxi-machine-spdif and replaced with simple audio card
- removed untested compatibilities from device tree documentation
- added pm_runtime and remove shutdown
- removed pll2 as it's the parent of the spdif clock
- rename clk to spdif_clk
- removed enabling of mclk output
- removed interrupts status being cleared as it's not being used
- use default fifo settings for now
- fixed alignments for wrapped lines

Changes since v1:
- Moved sunxi-machine-spdif.c to separate patch
- replaced sunxi in naming scheme with sun4i in the sun4i-spdif driver.
- split tx controller into separate enable/disable functions
- moved setclk and setfmt functionality into hw params
- added support for mono signals.
- cleaned up probe clock set up.
- removed all writes to transmit status registers.
- removed of_id
- removed power management code.
- Added support for more rates.

Marcus Cooper (2):
  dt-bindings: sunxi :add sun4i SPDIF transceiver
  ASoC: sunxi: Add support for the SPDIF block

 .../bindings/sound/sunxi,sun4i-spdif.txt           |  39 ++
 sound/soc/sunxi/Kconfig                            |   8 +
 sound/soc/sunxi/Makefile                           |   1 +
 sound/soc/sunxi/sun4i-spdif.c                      | 561 +++++++++++++++++++++
 4 files changed, 609 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
 create mode 100644 sound/soc/sunxi/sun4i-spdif.c

-- 
2.7.0



From codekipper at gmail.com  Thu Feb  4 03:09:22 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Thu,  4 Feb 2016 12:09:22 +0100
Subject: [PATCH v4 2/2] ASoC: sunxi: Add support for the SPDIF block
In-Reply-To: <1454584162-32449-1-git-send-email-codekipper@gmail.com>
References: <1454584162-32449-1-git-send-email-codekipper@gmail.com>
Message-ID: <1454584162-32449-3-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

The sun4i, sun5i and sun7i SoC families have an SPDIF
block which is capable of playback and capture.

This patch enables the playback of this block for
the sun4i families.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
 sound/soc/sunxi/Kconfig       |   8 +
 sound/soc/sunxi/Makefile      |   1 +
 sound/soc/sunxi/sun4i-spdif.c | 561 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 570 insertions(+)
 create mode 100644 sound/soc/sunxi/sun4i-spdif.c

diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
index 84c72ec..6af7224 100644
--- a/sound/soc/sunxi/Kconfig
+++ b/sound/soc/sunxi/Kconfig
@@ -8,4 +8,12 @@ config SND_SUN4I_CODEC
 	  Select Y or M to add support for the Codec embedded in the Allwinner
 	  A10 and affiliated SoCs.
 
+config SND_SUN4I_SPDIF
+        tristate "Allwinner A10 SPDIF Support"
+	depends on OF
+        select SND_SOC_GENERIC_DMAENGINE_PCM
+        select REGMAP_MMIO
+        help
+          Say Y or M to add support for the S/PDIF audio block in the Allwinner
+	  A10 and affiliated SoCs.
 endmenu
diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
index ea8a08c..8f5e889 100644
--- a/sound/soc/sunxi/Makefile
+++ b/sound/soc/sunxi/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
 
+obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o
diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
new file mode 100644
index 0000000..bb32344
--- /dev/null
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -0,0 +1,561 @@
+/*
+ * ALSA SoC SPDIF Audio Layer
+ *
+ * Copyright 2015 Andrea Venturi <be17068 at iperbole.bo.it>
+ * Copyright 2015 Marcus Cooper <codekipper at gmail.com>
+ *
+ * Based on the Allwinner SDK driver, released under the GPL.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/regmap.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/ioport.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <sound/dmaengine_pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+
+#define	SUN4I_SPDIF_CTL		(0x00)
+	#define SUN4I_SPDIF_CTL_MCLKDIV(v)		((v) << 4) /* v even */
+	#define SUN4I_SPDIF_CTL_MCLKOUTEN		BIT(2)
+	#define SUN4I_SPDIF_CTL_GEN			BIT(1)
+	#define SUN4I_SPDIF_CTL_RESET			BIT(0)
+
+#define SUN4I_SPDIF_TXCFG	(0x04)
+	#define SUN4I_SPDIF_TXCFG_SINGLEMOD		BIT(31)
+	#define SUN4I_SPDIF_TXCFG_ASS			BIT(17)
+	#define SUN4I_SPDIF_TXCFG_NONAUDIO		BIT(16)
+	#define SUN4I_SPDIF_TXCFG_TXRATIO(v)		((v) << 4)
+	#define SUN4I_SPDIF_TXCFG_TXRATIO_MASK		GENMASK(8, 4)
+	#define SUN4I_SPDIF_TXCFG_FMTRVD		GENMASK(3, 2)
+	#define SUN4I_SPDIF_TXCFG_FMT16BIT		(0 << 2)
+	#define SUN4I_SPDIF_TXCFG_FMT20BIT		(1 << 2)
+	#define SUN4I_SPDIF_TXCFG_FMT24BIT		(2 << 2)
+	#define SUN4I_SPDIF_TXCFG_CHSTMODE		BIT(1)
+	#define SUN4I_SPDIF_TXCFG_TXEN			BIT(0)
+
+#define SUN4I_SPDIF_RXCFG	(0x08)
+	#define SUN4I_SPDIF_RXCFG_LOCKFLAG		BIT(4)
+	#define SUN4I_SPDIF_RXCFG_CHSTSRC		BIT(3)
+	#define SUN4I_SPDIF_RXCFG_CHSTCP		BIT(1)
+	#define SUN4I_SPDIF_RXCFG_RXEN			BIT(0)
+
+#define SUN4I_SPDIF_TXFIFO	(0x0C)
+
+#define SUN4I_SPDIF_RXFIFO	(0x10)
+
+#define SUN4I_SPDIF_FCTL	(0x14)
+	#define SUN4I_SPDIF_FCTL_FIFOSRC		BIT(31)
+	#define SUN4I_SPDIF_FCTL_FTX			BIT(17)
+	#define SUN4I_SPDIF_FCTL_FRX			BIT(16)
+	#define SUN4I_SPDIF_FCTL_TXTL(v)		((v) << 8)
+	#define SUN4I_SPDIF_FCTL_TXTL_MASK		GENMASK(12, 8)
+	#define SUN4I_SPDIF_FCTL_RXTL(v)		((v) << 3)
+	#define SUN4I_SPDIF_FCTL_RXTL_MASK		GENMASK(7, 3)
+	#define SUN4I_SPDIF_FCTL_TXIM			BIT(2)
+	#define SUN4I_SPDIF_FCTL_RXOM(v)		((v) << 0)
+	#define SUN4I_SPDIF_FCTL_RXOM_MASK		GENMASK(1, 0)
+
+#define SUN4I_SPDIF_FSTA	(0x18)
+	#define SUN4I_SPDIF_FSTA_TXE			BIT(14)
+	#define SUN4I_SPDIF_FSTA_TXECNTSHT		(8)
+	#define SUN4I_SPDIF_FSTA_RXA			BIT(6)
+	#define SUN4I_SPDIF_FSTA_RXACNTSHT		(0)
+
+#define SUN4I_SPDIF_INT		(0x1C)
+	#define SUN4I_SPDIF_INT_RXLOCKEN		BIT(18)
+	#define SUN4I_SPDIF_INT_RXUNLOCKEN		BIT(17)
+	#define SUN4I_SPDIF_INT_RXPARERREN		BIT(16)
+	#define SUN4I_SPDIF_INT_TXDRQEN			BIT(7)
+	#define SUN4I_SPDIF_INT_TXUIEN			BIT(6)
+	#define SUN4I_SPDIF_INT_TXOIEN			BIT(5)
+	#define SUN4I_SPDIF_INT_TXEIEN			BIT(4)
+	#define SUN4I_SPDIF_INT_RXDRQEN			BIT(2)
+	#define SUN4I_SPDIF_INT_RXOIEN			BIT(1)
+	#define SUN4I_SPDIF_INT_RXAIEN			BIT(0)
+
+#define SUN4I_SPDIF_ISTA	(0x20)
+	#define SUN4I_SPDIF_ISTA_RXLOCKSTA		BIT(18)
+	#define SUN4I_SPDIF_ISTA_RXUNLOCKSTA		BIT(17)
+	#define SUN4I_SPDIF_ISTA_RXPARERRSTA		BIT(16)
+	#define SUN4I_SPDIF_ISTA_TXUSTA			BIT(6)
+	#define SUN4I_SPDIF_ISTA_TXOSTA			BIT(5)
+	#define SUN4I_SPDIF_ISTA_TXESTA			BIT(4)
+	#define SUN4I_SPDIF_ISTA_RXOSTA			BIT(1)
+	#define SUN4I_SPDIF_ISTA_RXASTA			BIT(0)
+
+#define SUN4I_SPDIF_TXCNT	(0x24)
+
+#define SUN4I_SPDIF_RXCNT	(0x28)
+
+#define SUN4I_SPDIF_TXCHSTA0	(0x2C)
+	#define SUN4I_SPDIF_TXCHSTA0_CLK(v)		((v) << 28)
+	#define SUN4I_SPDIF_TXCHSTA0_SAMFREQ(v)		((v) << 24)
+	#define SUN4I_SPDIF_TXCHSTA0_SAMFREQ_MASK	GENMASK(27, 24)
+	#define SUN4I_SPDIF_TXCHSTA0_CHNUM(v)		((v) << 20)
+	#define SUN4I_SPDIF_TXCHSTA0_CHNUM_MASK		GENMASK(23, 20)
+	#define SUN4I_SPDIF_TXCHSTA0_SRCNUM(v)		((v) << 16)
+	#define SUN4I_SPDIF_TXCHSTA0_CATACOD(v)		((v) << 8)
+	#define SUN4I_SPDIF_TXCHSTA0_MODE(v)		((v) << 6)
+	#define SUN4I_SPDIF_TXCHSTA0_EMPHASIS(v)	((v) << 3)
+	#define SUN4I_SPDIF_TXCHSTA0_CP			BIT(2)
+	#define SUN4I_SPDIF_TXCHSTA0_AUDIO		BIT(1)
+	#define SUN4I_SPDIF_TXCHSTA0_PRO		BIT(0)
+
+#define SUN4I_SPDIF_TXCHSTA1	(0x30)
+	#define SUN4I_SPDIF_TXCHSTA1_CGMSA(v)		((v) << 8)
+	#define SUN4I_SPDIF_TXCHSTA1_ORISAMFREQ(v)	((v) << 4)
+	#define SUN4I_SPDIF_TXCHSTA1_ORISAMFREQ_MASK	GENMASK(7, 4)
+	#define SUN4I_SPDIF_TXCHSTA1_SAMWORDLEN(v)	((v) << 1)
+	#define SUN4I_SPDIF_TXCHSTA1_MAXWORDLEN		BIT(0)
+
+#define SUN4I_SPDIF_RXCHSTA0	(0x34)
+	#define SUN4I_SPDIF_RXCHSTA0_CLK(v)		((v) << 28)
+	#define SUN4I_SPDIF_RXCHSTA0_SAMFREQ(v)		((v) << 24)
+	#define SUN4I_SPDIF_RXCHSTA0_CHNUM(v)		((v) << 20)
+	#define SUN4I_SPDIF_RXCHSTA0_SRCNUM(v)		((v) << 16)
+	#define SUN4I_SPDIF_RXCHSTA0_CATACOD(v)		((v) << 8)
+	#define SUN4I_SPDIF_RXCHSTA0_MODE(v)		((v) << 6)
+	#define SUN4I_SPDIF_RXCHSTA0_EMPHASIS(v)	((v) << 3)
+	#define SUN4I_SPDIF_RXCHSTA0_CP			BIT(2)
+	#define SUN4I_SPDIF_RXCHSTA0_AUDIO		BIT(1)
+	#define SUN4I_SPDIF_RXCHSTA0_PRO		BIT(0)
+
+#define SUN4I_SPDIF_RXCHSTA1	(0x38)
+	#define SUN4I_SPDIF_RXCHSTA1_CGMSA(v)		((v) << 8)
+	#define SUN4I_SPDIF_RXCHSTA1_ORISAMFREQ(v)	((v) << 4)
+	#define SUN4I_SPDIF_RXCHSTA1_SAMWORDLEN(v)	((v) << 1)
+	#define SUN4I_SPDIF_RXCHSTA1_MAXWORDLEN		BIT(0)
+
+/* Defines for Sampling Frequency */
+#define SUN4I_SPDIF_SAMFREQ_44_1KHZ		0x0
+#define SUN4I_SPDIF_SAMFREQ_NOT_INDICATED	0x1
+#define SUN4I_SPDIF_SAMFREQ_48KHZ		0x2
+#define SUN4I_SPDIF_SAMFREQ_32KHZ		0x3
+#define SUN4I_SPDIF_SAMFREQ_22_05KHZ		0x4
+#define SUN4I_SPDIF_SAMFREQ_24KHZ		0x6
+#define SUN4I_SPDIF_SAMFREQ_88_2KHZ		0x8
+#define SUN4I_SPDIF_SAMFREQ_76_8KHZ		0x9
+#define SUN4I_SPDIF_SAMFREQ_96KHZ		0xa
+#define SUN4I_SPDIF_SAMFREQ_176_4KHZ		0xc
+#define SUN4I_SPDIF_SAMFREQ_192KHZ		0xe
+
+/*
+ * Original sampling frequency can be represented by inverting the value of the
+ * sampling frequency.
+ */
+#define ORIGINAL(v) ((~v) & 0xf)
+
+struct sun4i_spdif_dev {
+	struct platform_device *pdev;
+	struct clk *spdif_clk;
+	struct clk *apb_clk;
+	struct snd_soc_dai_driver cpu_dai_drv;
+	struct regmap *regmap;
+	struct snd_dmaengine_dai_dma_data dma_params_tx;
+};
+
+static void sun4i_spdif_configure(struct sun4i_spdif_dev *host)
+{
+	/* soft reset SPDIF */
+	regmap_write(host->regmap, SUN4I_SPDIF_CTL, SUN4I_SPDIF_CTL_RESET);
+
+	/* flush TX FIFO */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_FCTL,
+			   SUN4I_SPDIF_FCTL_FTX, SUN4I_SPDIF_FCTL_FTX);
+
+	/* clear TX counter */
+	regmap_write(host->regmap, SUN4I_SPDIF_TXCNT, 0);
+}
+
+static void sun4i_snd_txctrl_on(struct snd_pcm_substream *substream,
+				struct sun4i_spdif_dev *host)
+{
+	if (substream->runtime->channels == 1)
+		regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+				   SUN4I_SPDIF_TXCFG_SINGLEMOD,
+				   SUN4I_SPDIF_TXCFG_SINGLEMOD);
+
+	/* SPDIF TX ENABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+			   SUN4I_SPDIF_TXCFG_TXEN, SUN4I_SPDIF_TXCFG_TXEN);
+
+	/* DRQ ENABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_INT,
+			   SUN4I_SPDIF_INT_TXDRQEN, SUN4I_SPDIF_INT_TXDRQEN);
+
+	/* Global enable */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_CTL,
+			   SUN4I_SPDIF_CTL_GEN, SUN4I_SPDIF_CTL_GEN);
+}
+
+static void sun4i_snd_txctrl_off(struct snd_pcm_substream *substream,
+				 struct sun4i_spdif_dev *host)
+{
+	/* SPDIF TX DISABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+			   SUN4I_SPDIF_TXCFG_TXEN, 0);
+
+	/* DRQ DISABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_INT,
+			   SUN4I_SPDIF_INT_TXDRQEN, 0);
+
+	/* Global disable */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_CTL,
+			   SUN4I_SPDIF_CTL_GEN, 0);
+}
+
+static int sun4i_spdif_startup(struct snd_pcm_substream *substream,
+			       struct snd_soc_dai *cpu_dai)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(rtd->cpu_dai);
+
+	if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK)
+		return -EINVAL;
+
+	sun4i_spdif_configure(host);
+
+	return 0;
+}
+
+static int sun4i_spdif_hw_params(struct snd_pcm_substream *substream,
+				 struct snd_pcm_hw_params *params,
+				 struct snd_soc_dai *cpu_dai)
+{
+	int ret = 0;
+	int fmt;
+	unsigned long rate = params_rate(params);
+	u32 mclk_div = 0;
+	unsigned int mclk = 0;
+	u32 reg_val;
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
+	struct platform_device *pdev = host->pdev;
+
+	/* Add the PCM and raw data select interface */
+	switch (params_channels(params)) {
+	case 1: /* PCM mode */
+	case 2:
+		fmt = 0;
+		break;
+	case 4: /* raw data mode */
+		fmt = SUN4I_SPDIF_TXCFG_NONAUDIO;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	switch (params_format(params)) {
+	case SNDRV_PCM_FORMAT_S16_LE:
+		fmt |= SUN4I_SPDIF_TXCFG_FMT16BIT;
+		break;
+	case SNDRV_PCM_FORMAT_S20_3LE:
+		fmt |= SUN4I_SPDIF_TXCFG_FMT20BIT;
+		break;
+	case SNDRV_PCM_FORMAT_S24_LE:
+		fmt |= SUN4I_SPDIF_TXCFG_FMT24BIT;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	switch (rate) {
+	case 22050:
+	case 44100:
+	case 88200:
+	case 176400:
+		mclk = 22579200;
+		break;
+	case 24000:
+	case 32000:
+	case 48000:
+	case 96000:
+	case 192000:
+		mclk = 24576000;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	ret = clk_set_rate(host->spdif_clk, mclk);
+	if (ret < 0) {
+		dev_err(&pdev->dev,
+			"Setting SPDIF clock rate for %d Hz failed!\n", mclk);
+		return ret;
+	}
+
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_FCTL,
+			   SUN4I_SPDIF_FCTL_TXIM, SUN4I_SPDIF_FCTL_TXIM);
+
+	switch (rate) {
+	case 22050:
+	case 24000:
+		mclk_div = 8;
+		break;
+	case 32000:
+		mclk_div = 6;
+		break;
+	case 44100:
+	case 48000:
+		mclk_div = 4;
+		break;
+	case 88200:
+	case 96000:
+		mclk_div = 2;
+		break;
+	case 176400:
+	case 192000:
+		mclk_div = 1;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	reg_val = 0;
+	reg_val |= SUN4I_SPDIF_TXCFG_ASS;
+	reg_val |= fmt; /* set non audio and bit depth */
+	reg_val |= SUN4I_SPDIF_TXCFG_CHSTMODE;
+	reg_val |= SUN4I_SPDIF_TXCFG_TXRATIO(mclk_div - 1);
+	regmap_write(host->regmap, SUN4I_SPDIF_TXCFG, reg_val);
+
+	return 0;
+}
+
+static int sun4i_spdif_trigger(struct snd_pcm_substream *substream, int cmd,
+			       struct snd_soc_dai *dai)
+{
+	int ret = 0;
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(dai);
+
+	if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK)
+		return -EINVAL;
+
+	switch (cmd) {
+	case SNDRV_PCM_TRIGGER_START:
+	case SNDRV_PCM_TRIGGER_RESUME:
+	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+		sun4i_snd_txctrl_on(substream, host);
+		break;
+
+	case SNDRV_PCM_TRIGGER_STOP:
+	case SNDRV_PCM_TRIGGER_SUSPEND:
+	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+		sun4i_snd_txctrl_off(substream, host);
+		break;
+
+	default:
+		ret = -EINVAL;
+		break;
+	}
+	return ret;
+}
+
+static int sun4i_spdif_soc_dai_probe(struct snd_soc_dai *dai)
+{
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(dai);
+
+	snd_soc_dai_init_dma_data(dai, &host->dma_params_tx, NULL);
+	return 0;
+}
+
+static const struct snd_soc_dai_ops sun4i_spdif_dai_ops = {
+	.startup	= sun4i_spdif_startup,
+	.trigger	= sun4i_spdif_trigger,
+	.hw_params	= sun4i_spdif_hw_params,
+};
+
+static const struct regmap_config sun4i_spdif_regmap_config = {
+	.reg_bits = 32,
+	.reg_stride = 4,
+	.val_bits = 32,
+	.max_register = SUN4I_SPDIF_RXCHSTA1,
+};
+
+#define SUN4I_RATES	SNDRV_PCM_RATE_8000_192000
+
+#define SUN4I_FORMATS	(SNDRV_PCM_FORMAT_S16_LE | \
+				SNDRV_PCM_FORMAT_S20_3LE | \
+				SNDRV_PCM_FORMAT_S24_LE)
+
+static struct snd_soc_dai_driver sun4i_spdif_dai = {
+	.playback = {
+		.channels_min = 1,
+		.channels_max = 2,
+		.rates = SUN4I_RATES,
+		.formats = SUN4I_FORMATS,
+	},
+	.probe = sun4i_spdif_soc_dai_probe,
+	.ops = &sun4i_spdif_dai_ops,
+	.name = "spdif",
+};
+
+static const struct snd_soc_dapm_widget dit_widgets[] = {
+	SND_SOC_DAPM_OUTPUT("spdif-out"),
+};
+
+static const struct snd_soc_dapm_route dit_routes[] = {
+	{ "spdif-out", NULL, "Playback" },
+};
+
+static const struct of_device_id sun4i_spdif_of_match[] = {
+	{ .compatible = "allwinner,sun4i-a10-spdif", },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sun4i_spdif_of_match);
+
+static const struct snd_soc_component_driver sun4i_spdif_component = {
+	.name		= "sun4i-spdif",
+};
+
+static int sun4i_spdif_runtime_suspend(struct device *dev)
+{
+	struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
+
+	clk_disable_unprepare(host->spdif_clk);
+	clk_disable_unprepare(host->apb_clk);
+
+	return 0;
+}
+
+static int sun4i_spdif_runtime_resume(struct device *dev)
+{
+	struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
+
+	clk_prepare_enable(host->spdif_clk);
+	clk_prepare_enable(host->apb_clk);
+
+	return 0;
+}
+
+static int sun4i_spdif_probe(struct platform_device *pdev)
+{
+	struct sun4i_spdif_dev *host;
+	struct resource *res;
+	int ret;
+	void __iomem *base;
+
+	dev_dbg(&pdev->dev, "Entered %s\n", __func__);
+
+	host = devm_kzalloc(&pdev->dev, sizeof(*host), GFP_KERNEL);
+	if (!host)
+		return -ENOMEM;
+
+	host->pdev = pdev;
+
+	/* Initialize this copy of the CPU DAI driver structure */
+	memcpy(&host->cpu_dai_drv, &sun4i_spdif_dai, sizeof(sun4i_spdif_dai));
+	host->cpu_dai_drv.name = dev_name(&pdev->dev);
+
+	/* Get the addresses */
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	host->regmap = devm_regmap_init_mmio(&pdev->dev, base,
+						&sun4i_spdif_regmap_config);
+
+	/* Clocks */
+	host->apb_clk = devm_clk_get(&pdev->dev, "apb");
+	if (IS_ERR(host->apb_clk)) {
+		dev_err(&pdev->dev, "failed to get a apb clock.\n");
+		return PTR_ERR(host->apb_clk);
+	}
+
+	ret = clk_prepare_enable(host->apb_clk);
+	if (ret) {
+		dev_err(&pdev->dev, "try to enable apb_spdif_clk failed\n");
+		return ret;
+	}
+
+	host->spdif_clk = devm_clk_get(&pdev->dev, "spdif");
+	if (IS_ERR(host->spdif_clk)) {
+		dev_err(&pdev->dev, "failed to get a spdif clock.\n");
+		goto err_disable_apb_clk;
+	}
+
+	host->dma_params_tx.addr = res->start + SUN4I_SPDIF_TXFIFO;
+	host->dma_params_tx.maxburst = 4;
+	host->dma_params_tx.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
+
+	platform_set_drvdata(pdev, host);
+
+	ret = devm_snd_soc_register_component(&pdev->dev,
+				&sun4i_spdif_component, &sun4i_spdif_dai, 1);
+	if (ret)
+		goto err_disable_apb_clk;
+
+	pm_runtime_enable(&pdev->dev);
+	if (!pm_runtime_enabled(&pdev->dev)) {
+		ret = sun4i_spdif_runtime_resume(&pdev->dev);
+		if (ret)
+			goto err_unregister;
+	}
+
+	ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
+	if (ret)
+		goto err_suspend;
+	return 0;
+err_suspend:
+	if (!pm_runtime_status_suspended(&pdev->dev))
+		sun4i_spdif_runtime_suspend(&pdev->dev);
+err_unregister:
+	pm_runtime_disable(&pdev->dev);
+	snd_soc_unregister_component(&pdev->dev);
+err_disable_apb_clk:
+	clk_disable_unprepare(host->apb_clk);
+	return ret;
+}
+
+static int sun4i_spdif_remove(struct platform_device *pdev)
+{
+	pm_runtime_disable(&pdev->dev);
+	if (!pm_runtime_status_suspended(&pdev->dev))
+		sun4i_spdif_runtime_suspend(&pdev->dev);
+
+	snd_soc_unregister_platform(&pdev->dev);
+	snd_soc_unregister_component(&pdev->dev);
+
+	return 0;
+}
+
+static const struct dev_pm_ops sun4i_spdif_pm = {
+	SET_RUNTIME_PM_OPS(sun4i_spdif_runtime_suspend,
+			   sun4i_spdif_runtime_resume, NULL)
+};
+
+static struct platform_driver sun4i_spdif_driver = {
+	.driver		= {
+		.name	= "sun4i-spdif",
+		.of_match_table = of_match_ptr(sun4i_spdif_of_match),
+		.pm	= &sun4i_spdif_pm,
+	},
+	.probe		= sun4i_spdif_probe,
+	.remove		= sun4i_spdif_remove,
+};
+
+module_platform_driver(sun4i_spdif_driver);
+
+MODULE_AUTHOR("Marcus Cooper <codekipper at gmail.com>");
+MODULE_AUTHOR("Andrea Venturi <be17068 at iperbole.bo.it>");
+MODULE_DESCRIPTION("Allwinner sun4i SPDIF SoC Interface");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:sun4i-spdif");
-- 
2.7.0



From gpkulkarni at gmail.com  Thu Feb  4 03:15:44 2016
From: gpkulkarni at gmail.com (Ganapatrao Kulkarni)
Date: Thu, 4 Feb 2016 16:45:44 +0530
Subject: [PATCH v10 3/8] dt, numa: adding numa dt binding implementation.
In-Reply-To: <20160202233417.GA4739@rob-hp-laptop>
References: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
 <1454407763-1017-4-git-send-email-gkulkarni@caviumnetworks.com>
 <20160202233417.GA4739@rob-hp-laptop>
Message-ID: <CAFpQJXUtZcWt9xSAL0MZiFZegPUwrppQgv4ipTNGstvHR6-pBg@mail.gmail.com>

Hi Rob,

On Wed, Feb 3, 2016 at 5:04 AM, Rob Herring <robh at kernel.org> wrote:
> On Tue, Feb 02, 2016 at 03:39:18PM +0530, Ganapatrao Kulkarni wrote:
>> dt node parsing for numa topology is done using device property
>> numa-node-id and device node distance-map.
>>
>> Reviewed-by: Robert Richter <rrichter at cavium.com>
>> Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
>> ---
>>  drivers/of/Kconfig   |  11 +++
>>  drivers/of/Makefile  |   1 +
>>  drivers/of/of_numa.c | 207 +++++++++++++++++++++++++++++++++++++++++++++++++++
>>  include/linux/of.h   |   4 +
>>  4 files changed, 223 insertions(+)
>>  create mode 100644 drivers/of/of_numa.c
>>
>> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
>> index e2a4841..8f9cc3a 100644
>> --- a/drivers/of/Kconfig
>> +++ b/drivers/of/Kconfig
>> @@ -112,4 +112,15 @@ config OF_OVERLAY
>>         While this option is selected automatically when needed, you can
>>         enable it manually to improve device tree unit test coverage.
>>
>> +config OF_NUMA
>> +     bool "Device Tree NUMA support"
>
> Does this need to be user visible?

thanks, not required, arch can select
>
>> +     depends on NUMA
>> +     depends on OF
>> +     depends on ARM64
>
> drop this (and make sure it compiles on other arches). It will fail
> because you also have a dependency on FDT.

thanks will add OF_EARLY_FLATTREE
>
>> +     default y
>> +     help
>> +       Enable Device Tree NUMA support.
>> +       This enables the numa mapping of cpu, memory, io and
>> +       inter node distances using dt bindings.
>> +
>>  endif # OF
>> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
>> index 156c072..bee3fa9 100644
>> --- a/drivers/of/Makefile
>> +++ b/drivers/of/Makefile
>> @@ -14,5 +14,6 @@ obj-$(CONFIG_OF_MTD)        += of_mtd.o
>>  obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
>>  obj-$(CONFIG_OF_RESOLVE)  += resolver.o
>>  obj-$(CONFIG_OF_OVERLAY) += overlay.o
>> +obj-$(CONFIG_OF_NUMA) += of_numa.o
>>
>>  obj-$(CONFIG_OF_UNITTEST) += unittest-data/
>> diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
>> new file mode 100644
>> index 0000000..1142cdb
>> --- /dev/null
>> +++ b/drivers/of/of_numa.c
>> @@ -0,0 +1,207 @@
>> +/*
>> + * OF NUMA Parsing support.
>> + *
>> + * Copyright (C) 2015 Cavium Inc.
>> + * Author: Ganapatrao Kulkarni <gkulkarni at 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/of.h>
>> +#include <linux/of_fdt.h>
>
> Surely you need some numa related includes.
ok
>
>> +
>> +/* define default numa node to 0 */
>> +#define DEFAULT_NODE 0
>> +
>> +/* Returns nid in the range [0..MAX_NUMNODES-1],
>> + * or NUMA_NO_NODE if no valid numa-node-id entry found
>> + * or DEFAULT_NODE if no numa-node-id entry exists
>> + */
>> +static int of_numa_prop_to_nid(const __be32 *of_numa_prop, int length)
>> +{
>> +     int nid;
>> +
>> +     if (!of_numa_prop)
>> +             return DEFAULT_NODE;
>> +
>> +     if (length != sizeof(*of_numa_prop)) {
>> +             pr_warn("NUMA: Invalid of_numa_prop length %d found.\n",
>> +                             length);
>> +             return NUMA_NO_NODE;
>> +     }
>> +
>> +     nid = of_read_number(of_numa_prop, 1);
>> +     if (nid >= MAX_NUMNODES) {
>> +             pr_warn("NUMA: Invalid numa node %d found.\n", nid);
>> +             return NUMA_NO_NODE;
>> +     }
>> +
>> +     return nid;
>> +}
>> +
>> +static int __init early_init_of_node_to_nid(unsigned long node)
>> +{
>> +     int length;
>> +     const __be32 *of_numa_prop;
>> +
>> +     of_numa_prop = of_get_flat_dt_prop(node, "numa-node-id", &length);
>> +
>> +     return of_numa_prop_to_nid(of_numa_prop, length);
>> +}
>> +
>> +/*
>> + * Even though we connect cpus to numa domains later in SMP
>> + * init, we need to know the node ids now for all cpus.
>> +*/
>> +static int __init early_init_parse_cpu_node(unsigned long node)
>> +{
>> +     int nid;
>> +     const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
>> +
>> +     if (type == NULL)
>> +             return 0;
>> +
>> +     if (strcmp(type, "cpu") != 0)
>> +             return 0;
>> +
>> +     nid = early_init_of_node_to_nid(node);
>> +     if (nid == NUMA_NO_NODE)
>> +             return -EINVAL;
>> +
>> +     node_set(nid, numa_nodes_parsed);
>> +     return 0;
>> +}
>> +
>> +static int __init early_init_parse_memory_node(unsigned long node)
>> +{
>> +     const __be32 *reg, *endp;
>> +     int length;
>> +     int nid;
>> +     const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
>> +
>> +     if (type == NULL)
>> +             return 0;
>> +
>> +     if (strcmp(type, "memory") != 0)
>> +             return 0;
>> +
>> +     nid = early_init_of_node_to_nid(node);
>> +     if (nid == NUMA_NO_NODE)
>> +             return -EINVAL;
>> +
>> +     reg = of_get_flat_dt_prop(node, "reg", &length);
>> +     endp = reg + (length / sizeof(__be32));
>> +
>> +     while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
>> +             u64 base, size;
>> +
>> +             base = dt_mem_next_cell(dt_root_addr_cells, &reg);
>> +             size = dt_mem_next_cell(dt_root_size_cells, &reg);
>> +             pr_debug("NUMA:  base = %llx , node = %u\n",
>> +                             base, nid);
>> +
>
> We already have code to parse memory nodes. Can the NUMA part be
> combined somehow.

it is too early to parse numa in core code since there are no
variables ready to hold parsed information.
which is done in numa_init()
>
>> +             if (numa_add_memblk(nid, base, size) < 0)
>> +                     return -EINVAL;
>> +     }
>> +
>> +     return 0;
>> +}
>> +
>> +static int __init early_init_parse_distance_map_v1(unsigned long node,
>> +             const char *uname)
>> +{
>> +     const __be32 *prop_dist_matrix;
>> +     int length = 0, i, matrix_count;
>> +     int nr_size_cells = OF_ROOT_NODE_SIZE_CELLS_DEFAULT;
>> +
>> +     pr_info("NUMA: parsing numa-distance-map-v1\n");
>> +
>> +     prop_dist_matrix =
>> +             of_get_flat_dt_prop(node, "distance-matrix", &length);
>> +
>> +     if (!length) {
>> +             pr_err("NUMA: failed to parse distance-matrix\n");
>> +             return -ENODEV;
>> +     }
>> +
>> +     matrix_count = ((length / sizeof(__be32)) / (3 * nr_size_cells));
>> +
>> +     if ((matrix_count * sizeof(__be32) * 3 * nr_size_cells) !=  length) {
>> +             pr_warn("NUMA: invalid distance-matrix length %d\n", length);
>> +             return -EINVAL;
>> +     }
>> +
>> +     for (i = 0; i < matrix_count; i++) {
>> +             u32 nodea, nodeb, distance;
>> +
>> +             nodea = dt_mem_next_cell(nr_size_cells, &prop_dist_matrix);
>> +             nodeb = dt_mem_next_cell(nr_size_cells, &prop_dist_matrix);
>> +             distance = dt_mem_next_cell(nr_size_cells, &prop_dist_matrix);
>> +             numa_set_distance(nodea, nodeb, distance);
>> +             pr_debug("NUMA:  distance[node%d -> node%d] = %d\n",
>> +                             nodea, nodeb, distance);
>> +
>> +             /* Set default distance of node B->A same as A->B */
>> +             if (nodeb > nodea)
>> +                     numa_set_distance(nodeb, nodea, distance);
>> +     }
>> +
>> +     return 0;
>> +}
>> +
>> +static int __init early_init_parse_distance_map(unsigned long node,
>> +             const char *uname)
>> +{
>> +     if (strcmp(uname, "distance-map") != 0)
>> +             return 0;
>> +
>> +     if (of_flat_dt_is_compatible(node, "numa-distance-map-v1"))
>> +             return early_init_parse_distance_map_v1(node, uname);
>> +
>> +     pr_err("NUMA: invalid distance-map device node\n");
>> +     return -EINVAL;
>> +}
>> +
>> +static int __init early_init_of_scan_numa_map(unsigned long node, const char *uname,
>> +                                  int depth, void *data)
>> +{
>> +     int ret;
>> +
>> +     ret = early_init_parse_cpu_node(node);
>> +     if (ret)
>> +             return ret;
>> +
>> +     ret = early_init_parse_memory_node(node);
>> +     if (ret)
>> +             return ret;
>> +
>> +     return early_init_parse_distance_map(node, uname);
>> +}
>> +
>> +int of_node_to_nid(struct device_node *device)
>> +{
>> +     const __be32 *of_numa_prop;
>> +     int length;
>> +
>> +     of_numa_prop = of_get_property(device, "numa-node-id", &length);
>> +     if (of_numa_prop)
>> +             return of_numa_prop_to_nid(of_numa_prop, length);
>> +
>> +     return NUMA_NO_NODE;
>> +}
>> +
>> +/* DT node mapping is done already early_init_of_scan_memory */
>> +int __init of_numa_init(void)
>> +{
>> +     return of_scan_flat_dt(early_init_of_scan_numa_map, NULL);
>> +}
>> diff --git a/include/linux/of.h b/include/linux/of.h
>> index dd10626..23e5bad 100644
>> --- a/include/linux/of.h
>> +++ b/include/linux/of.h
>> @@ -685,6 +685,10 @@ static inline int of_node_to_nid(struct device_node *device)
>>  }
>>  #endif
>>
>> +#ifdef CONFIG_OF_NUMA
>> +extern int __init of_numa_init(void);
>> +#endif
>
> You don't need an ifdef here unless you need an empty function.
>
> Can this be called internally by the DT code when it does the all
> the other flat scanning instead of adding another call from arch code to
> DT code. Ideally, the arch code would call DT code once and it would do
> all the parsing it needs to.

It is too early to include numa related dt parsing in the core dt
parsing like early_init_dt_scan()
since, numa init is called in bootmem_init after some mmblk related
variables are set.
which is little late in sequence to setup_machine_fdt

of_numa_init is called through numa_init, after required variables are
initialized.
In current implementation, the dt scan for numa parsing like memory
node, cpus and distance map
happens after the required data structures are initialized, moving this parsing
to core dt parsing will make this implementation in to 2 levels and
makes it complex,
which is at present fairly simple and straightforward.

>
> Rob

thanks
Ganapat


From marc.zyngier at arm.com  Thu Feb  4 03:00:18 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:18 +0000
Subject: [PATCH v2 01/28] ARM: KVM: Move the  HYP code to its own section
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-2-git-send-email-marc.zyngier@arm.com>

In order to be able to spread the HYP code into multiple compilation
units, adopt a layout similar to that of arm64:
- the HYP text is emited in its own section (.hyp.text)
- two linker generated symbols are use to identify the boundaries
  of that section

No functionnal change.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_asm.h |  6 ++++--
 arch/arm/include/asm/virt.h    |  4 ++++
 arch/arm/kernel/vmlinux.lds.S  |  6 ++++++
 arch/arm/kvm/interrupts.S      | 13 +++++--------
 4 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index 194c91b..fa2fd25 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -19,6 +19,8 @@
 #ifndef __ARM_KVM_ASM_H__
 #define __ARM_KVM_ASM_H__
 
+#include <asm/virt.h>
+
 /* 0 is reserved as an invalid value. */
 #define c0_MPIDR	1	/* MultiProcessor ID Register */
 #define c0_CSSELR	2	/* Cache Size Selection Register */
@@ -91,8 +93,8 @@ extern char __kvm_hyp_exit_end[];
 
 extern char __kvm_hyp_vector[];
 
-extern char __kvm_hyp_code_start[];
-extern char __kvm_hyp_code_end[];
+#define	__kvm_hyp_code_start	__hyp_text_start
+#define __kvm_hyp_code_end	__hyp_text_end
 
 extern void __kvm_flush_vm_context(void);
 extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
index 4371f45..5fdbfea 100644
--- a/arch/arm/include/asm/virt.h
+++ b/arch/arm/include/asm/virt.h
@@ -74,6 +74,10 @@ static inline bool is_hyp_mode_mismatched(void)
 {
 	return !!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH);
 }
+
+/* The section containing the hypervisor text */
+extern char __hyp_text_start[];
+extern char __hyp_text_end[];
 #endif
 
 #endif /* __ASSEMBLY__ */
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 8b60fde..b4139cb 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -18,6 +18,11 @@
 	*(.proc.info.init)						\
 	VMLINUX_SYMBOL(__proc_info_end) = .;
 
+#define HYPERVISOR_TEXT							\
+	VMLINUX_SYMBOL(__hyp_text_start) = .;				\
+	*(.hyp.text)							\
+	VMLINUX_SYMBOL(__hyp_text_end) = .;
+
 #define IDMAP_TEXT							\
 	ALIGN_FUNCTION();						\
 	VMLINUX_SYMBOL(__idmap_text_start) = .;				\
@@ -108,6 +113,7 @@ SECTIONS
 			TEXT_TEXT
 			SCHED_TEXT
 			LOCK_TEXT
+			HYPERVISOR_TEXT
 			KPROBES_TEXT
 			*(.gnu.warning)
 			*(.glue_7)
diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index 900ef6d..9d9cb71 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -28,9 +28,7 @@
 #include "interrupts_head.S"
 
 	.text
-
-__kvm_hyp_code_start:
-	.globl __kvm_hyp_code_start
+	.pushsection	.hyp.text, "ax"
 
 /********************************************************************
  * Flush per-VMID TLBs
@@ -314,8 +312,6 @@ THUMB(	orr	r2, r2, #PSR_T_BIT	)
 	eret
 .endm
 
-	.text
-
 	.align 5
 __kvm_hyp_vector:
 	.globl __kvm_hyp_vector
@@ -511,10 +507,9 @@ hyp_fiq:
 
 	.ltorg
 
-__kvm_hyp_code_end:
-	.globl	__kvm_hyp_code_end
+	.popsection
 
-	.section ".rodata"
+	.pushsection ".rodata"
 
 und_die_str:
 	.ascii	"unexpected undefined exception in Hyp mode at: %#08x\n"
@@ -524,3 +519,5 @@ dabt_die_str:
 	.ascii	"unexpected data abort in Hyp mode at: %#08x\n"
 svc_die_str:
 	.ascii	"unexpected HVC/SVC trap in Hyp mode at: %#08x\n"
+
+	.popsection
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:40 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:40 +0000
Subject: [PATCH v2 23/28] ARM: KVM: Remove __weak attributes
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-24-git-send-email-marc.zyngier@arm.com>

Now that the old code is long gone, we can remove all the weak
attributes, as there is only one version of the code.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/hyp/hyp-entry.S | 4 +---
 arch/arm/kvm/hyp/switch.c    | 2 +-
 arch/arm/kvm/hyp/tlb.c       | 6 +++---
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/arch/arm/kvm/hyp/hyp-entry.S b/arch/arm/kvm/hyp/hyp-entry.S
index ca412ad..e2a45b8 100644
--- a/arch/arm/kvm/hyp/hyp-entry.S
+++ b/arch/arm/kvm/hyp/hyp-entry.S
@@ -58,10 +58,8 @@
  */
 
 	.align 5
-__hyp_vector:
-	.global	__hyp_vector
 __kvm_hyp_vector:
-	.weak __kvm_hyp_vector
+	.global __kvm_hyp_vector
 
 	@ Hyp-mode exception vector
 	W(b)	hyp_reset
diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
index 67f3944..7325ad3 100644
--- a/arch/arm/kvm/hyp/switch.c
+++ b/arch/arm/kvm/hyp/switch.c
@@ -187,7 +187,7 @@ again:
 	return exit_code;
 }
 
-__alias(__guest_run) int __weak __kvm_vcpu_run(struct kvm_vcpu *vcpu);
+__alias(__guest_run) int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
 
 static const char * const __hyp_panic_string[] = {
 	[ARM_EXCEPTION_RESET]      = "\nHYP panic: RST?? PC:%08x CPSR:%08x",
diff --git a/arch/arm/kvm/hyp/tlb.c b/arch/arm/kvm/hyp/tlb.c
index 993fe89..3854e31 100644
--- a/arch/arm/kvm/hyp/tlb.c
+++ b/arch/arm/kvm/hyp/tlb.c
@@ -50,14 +50,14 @@ static void __hyp_text __tlb_flush_vmid(struct kvm *kvm)
 	write_sysreg(0, VTTBR);
 }
 
-__alias(__tlb_flush_vmid) void __weak __kvm_tlb_flush_vmid(struct kvm *kvm);
+__alias(__tlb_flush_vmid) void __kvm_tlb_flush_vmid(struct kvm *kvm);
 
 static void __hyp_text __tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
 {
 	__tlb_flush_vmid(kvm);
 }
 
-__alias(__tlb_flush_vmid_ipa) void __weak __kvm_tlb_flush_vmid_ipa(struct kvm *kvm,
+__alias(__tlb_flush_vmid_ipa) void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm,
 							    phys_addr_t ipa);
 
 static void __hyp_text __tlb_flush_vm_context(void)
@@ -68,4 +68,4 @@ static void __hyp_text __tlb_flush_vm_context(void)
 	dsb(ish);
 }
 
-__alias(__tlb_flush_vm_context) void __weak __kvm_flush_vm_context(void);
+__alias(__tlb_flush_vm_context) void __kvm_flush_vm_context(void);
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb  4 03:00:42 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu,  4 Feb 2016 11:00:42 +0000
Subject: [PATCH v2 25/28] ARM: KVM: Cleanup asm-offsets.c
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454583645-10144-26-git-send-email-marc.zyngier@arm.com>

Since we don't have much assembler left, most of the KVM stuff
in asm-offsets.c is now superfluous. Let's get rid of it.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kernel/asm-offsets.c | 30 ------------------------------
 1 file changed, 30 deletions(-)

diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
index 2f3e0b0..1f24c32 100644
--- a/arch/arm/kernel/asm-offsets.c
+++ b/arch/arm/kernel/asm-offsets.c
@@ -170,42 +170,12 @@ int main(void)
   DEFINE(CACHE_WRITEBACK_GRANULE, __CACHE_WRITEBACK_GRANULE);
   BLANK();
 #ifdef CONFIG_KVM_ARM_HOST
-  DEFINE(VCPU_KVM,		offsetof(struct kvm_vcpu, kvm));
-  DEFINE(VCPU_MIDR,		offsetof(struct kvm_vcpu, arch.midr));
   DEFINE(VCPU_GUEST_CTXT,	offsetof(struct kvm_vcpu, arch.ctxt));
   DEFINE(VCPU_HOST_CTXT,	offsetof(struct kvm_vcpu, arch.host_cpu_context));
   DEFINE(CPU_CTXT_VFP,		offsetof(struct kvm_cpu_context, vfp));
-  DEFINE(CPU_CTXT_CP15,		offsetof(struct kvm_cpu_context, cp15));
   DEFINE(CPU_CTXT_GP_REGS,	offsetof(struct kvm_cpu_context, gp_regs));
   DEFINE(GP_REGS_USR,		offsetof(struct kvm_regs, usr_regs));
-  DEFINE(GP_REGS_SVC,		offsetof(struct kvm_regs, svc_regs));
-  DEFINE(GP_REGS_ABT,		offsetof(struct kvm_regs, abt_regs));
-  DEFINE(GP_REGS_UND,		offsetof(struct kvm_regs, und_regs));
-  DEFINE(GP_REGS_IRQ,		offsetof(struct kvm_regs, irq_regs));
-  DEFINE(GP_REGS_FIQ,		offsetof(struct kvm_regs, fiq_regs));
-  DEFINE(GP_REGS_PC,		offsetof(struct kvm_regs, usr_regs.ARM_pc));
-  DEFINE(GP_REGS_CPSR,		offsetof(struct kvm_regs, usr_regs.ARM_cpsr));
-  DEFINE(VCPU_HCR,		offsetof(struct kvm_vcpu, arch.hcr));
-  DEFINE(VCPU_IRQ_LINES,	offsetof(struct kvm_vcpu, arch.irq_lines));
-  DEFINE(VCPU_HSR,		offsetof(struct kvm_vcpu, arch.fault.hsr));
-  DEFINE(VCPU_HxFAR,		offsetof(struct kvm_vcpu, arch.fault.hxfar));
-  DEFINE(VCPU_HPFAR,		offsetof(struct kvm_vcpu, arch.fault.hpfar));
   DEFINE(VCPU_HYP_PC,		offsetof(struct kvm_vcpu, arch.fault.hyp_pc));
-  DEFINE(VCPU_VGIC_CPU,		offsetof(struct kvm_vcpu, arch.vgic_cpu));
-  DEFINE(VGIC_V2_CPU_HCR,	offsetof(struct vgic_cpu, vgic_v2.vgic_hcr));
-  DEFINE(VGIC_V2_CPU_VMCR,	offsetof(struct vgic_cpu, vgic_v2.vgic_vmcr));
-  DEFINE(VGIC_V2_CPU_MISR,	offsetof(struct vgic_cpu, vgic_v2.vgic_misr));
-  DEFINE(VGIC_V2_CPU_EISR,	offsetof(struct vgic_cpu, vgic_v2.vgic_eisr));
-  DEFINE(VGIC_V2_CPU_ELRSR,	offsetof(struct vgic_cpu, vgic_v2.vgic_elrsr));
-  DEFINE(VGIC_V2_CPU_APR,	offsetof(struct vgic_cpu, vgic_v2.vgic_apr));
-  DEFINE(VGIC_V2_CPU_LR,	offsetof(struct vgic_cpu, vgic_v2.vgic_lr));
-  DEFINE(VGIC_CPU_NR_LR,	offsetof(struct vgic_cpu, nr_lr));
-  DEFINE(VCPU_TIMER_CNTV_CTL,	offsetof(struct kvm_vcpu, arch.timer_cpu.cntv_ctl));
-  DEFINE(VCPU_TIMER_CNTV_CVAL,	offsetof(struct kvm_vcpu, arch.timer_cpu.cntv_cval));
-  DEFINE(KVM_TIMER_CNTVOFF,	offsetof(struct kvm, arch.timer.cntvoff));
-  DEFINE(KVM_TIMER_ENABLED,	offsetof(struct kvm, arch.timer.enabled));
-  DEFINE(KVM_VGIC_VCTRL,	offsetof(struct kvm, arch.vgic.vctrl_base));
-  DEFINE(KVM_VTTBR,		offsetof(struct kvm, arch.vttbr));
 #endif
   BLANK();
 #ifdef CONFIG_VDSO
-- 
2.1.4



From ulf.hansson at linaro.org  Thu Feb  4 02:38:35 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 4 Feb 2016 11:38:35 +0100
Subject: [PATCH v4 00/13] mmc: use sdhci_pltfm_init for private allocation
 and clean up
In-Reply-To: <1453803353-6266-1-git-send-email-jszhang@marvell.com>
References: <1453803353-6266-1-git-send-email-jszhang@marvell.com>
Message-ID: <CAPDyKFpFSTYsAUCG9nFnnzmVsA3zm4hAPO8+6REArt9BJtn+0Q@mail.gmail.com>

+ Adrian

On 26 January 2016 at 11:15, Jisheng Zhang <jszhang at marvell.com> wrote:
> These patches are to complete the TODOs in Commit 0e748234293f ("mmc:
> sdhci: Add size for caller in init+register"), I.E:
>
> - todo: migrate clients to using allocation this way
> - todo: remove priv variable once migration is complete
>
> Since v3:
>  - based on v4.5-rc1
>  - add Ludovic's ack for sdhci-of-at91 changes
>  - fix use-after-free in some drivers: some host drivers still needs to
>    access sdhci_pltfm_host->private after sdhci_pltfm_unregister(), but
>    the private should be already freed by sdhci_pltfm_unregister.
>  - add patch5 to fix one clk bug in sdhci_arasan_remove(). IMHO, It's
>    better to add this patch to fixes rather than waiting for next merge
>    window
>
> Since v2:
>  - based on mmc next tree and remove all priv usage introduced in newly
>    commits in this tree
>  - don't break two lines if sdhci_pltfm_init() call could be put into
>    one line. Thank Ludovic Desroches.
>
> Since v1:
>  - add new patch03 to factorise sdhci_msm_pdata outisde of sdhci_msm_host.
>    This is to fix drivers/mmc/host/sdhci-msm.c:440:32: warning: 'msm_host'
>    is used uninitialized in this function [-Wuninitialized]
>  - Add Arnd's Ack for all patches except patch3 which is new in v2
>
>
> Jisheng Zhang (13):
>   mmc: sdhci-bcm2835: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-esdhc-imx: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-msm: factorise sdhci_msm_pdata outisde of sdhci_msm_host
>   mmc: sdhci-msm: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-of-arasan: fix clk issue in sdhci_arasan_remove()
>   mmc: sdhci-of-arasan: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-of-at91: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-of-esdhc: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-pxav3: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-st: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-tegra: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-pxav2: remove unnecessary assignment of pltfm_host->priv
>   mmc: sdhci-pltfm: remove priv variable from sdhci_pltfm_host
>
>  drivers/mmc/host/sdhci-bcm2835.c   | 14 +++----------
>  drivers/mmc/host/sdhci-esdhc-imx.c | 38 ++++++++++++++++--------------------
>  drivers/mmc/host/sdhci-msm.c       | 25 +++++++++++-------------
>  drivers/mmc/host/sdhci-of-arasan.c | 33 +++++++++++++++----------------
>  drivers/mmc/host/sdhci-of-at91.c   | 33 ++++++++++++++-----------------
>  drivers/mmc/host/sdhci-of-esdhc.c  | 19 +++++++++---------
>  drivers/mmc/host/sdhci-pltfm.h     |  1 -
>  drivers/mmc/host/sdhci-pxav2.c     |  1 -
>  drivers/mmc/host/sdhci-pxav3.c     | 20 ++++++++-----------
>  drivers/mmc/host/sdhci-st.c        | 40 +++++++++++++++++++-------------------
>  drivers/mmc/host/sdhci-tegra.c     | 21 +++++++-------------
>  11 files changed, 106 insertions(+), 139 deletions(-)
>
> --
> 2.7.0
>

To avoid confusions. I don't intend to pick up any further sdhci
patches, unless they are acked by Adrian Hunter.

Kind regards
Uffe


From gabriele.paoloni at huawei.com  Thu Feb  4 03:37:38 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Thu, 4 Feb 2016 19:37:38 +0800
Subject: [RFC PATCH 2/4] PCI: hisi: re-architect Hip05/Hip06 controllers
 driver to preapare for ACPI
In-Reply-To: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
References: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
Message-ID: <1454585860-60709-3-git-send-email-gabriele.paoloni@huawei.com>

From: gabriele paoloni <gabriele.paoloni at huawei.com>

re-architect the Hip05/Hip06 host controllers driver to prepare
for the ACPI based driver.
The common functions used also by the ACPI driver have been grouped
into a new "common" file

Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
---
 MAINTAINERS                         |   2 +
 drivers/pci/host/Makefile           |   2 +-
 drivers/pci/host/pcie-hisi-common.c |  88 +++++++++++++++++++++++
 drivers/pci/host/pcie-hisi.c        | 135 ++++++------------------------------
 drivers/pci/host/pcie-hisi.h        |  44 ++++++++++++
 5 files changed, 157 insertions(+), 114 deletions(-)
 create mode 100644 drivers/pci/host/pcie-hisi-common.c
 create mode 100644 drivers/pci/host/pcie-hisi.h

diff --git a/MAINTAINERS b/MAINTAINERS
index c80d9ff..8d6ec25 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8247,7 +8247,9 @@ M:	Gabriele Paoloni <gabriele.paoloni at huawei.com>
 L:	linux-pci at vger.kernel.org
 S:	Maintained
 F:	Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
+F:	drivers/pci/host/pcie-hisi.h
 F:	drivers/pci/host/pcie-hisi.c
+F:	drivers/pci/host/pcie-hisi-common.c
 
 PCMCIA SUBSYSTEM
 P:	Linux PCMCIA Team
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 9d4d3c6..6248320 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -19,4 +19,4 @@ obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
-obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
+obj-$(CONFIG_PCI_HISI) += pcie-hisi.o pcie-hisi-common.o
diff --git a/drivers/pci/host/pcie-hisi-common.c b/drivers/pci/host/pcie-hisi-common.c
new file mode 100644
index 0000000..ff93293
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi-common.c
@@ -0,0 +1,88 @@
+/*
+ * PCIe host controller common functions for HiSilicon SoCs
+ *
+ * Copyright (C) 2015 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Zhou Wang <wangzhou1 at hisilicon.com>
+ *         Dacai Zhu <zhudacai at hisilicon.com>
+ *         Gabriele Paoloni <gabriele.paoloni at huawei.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.
+ */
+
+#include <linux/acpi.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of_pci.h>
+#include <linux/regmap.h>
+
+#include "pcie-designware.h"
+#include "pcie-hisi.h"
+
+/* HipXX PCIe host only supports 32-bit config access */
+static int hisi_pcie_cfg_read(struct pcie_port *pp, int where, int size,
+			      u32 *val)
+{
+	u32 reg;
+	u32 reg_val;
+	struct hisi_pcie *pcie = to_hisi_pcie(pp);
+	void *walker = &reg_val;
+
+	walker += (where & 0x3);
+	reg = where & ~0x3;
+	reg_val = hisi_pcie_apb_readl(pcie, reg);
+
+	if (size == 1)
+		*val = *(u8 __force *) walker;
+	else if (size == 2)
+		*val = *(u16 __force *) walker;
+	else if (size == 4)
+		*val = reg_val;
+	else
+		return PCIBIOS_BAD_REGISTER_NUMBER;
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+/* HipXX PCIe host only supports 32-bit config access */
+static int hisi_pcie_cfg_write(struct pcie_port *pp, int where, int  size,
+				u32 val)
+{
+	u32 reg_val;
+	u32 reg;
+	struct hisi_pcie *pcie = to_hisi_pcie(pp);
+	void *walker = &reg_val;
+
+	walker += (where & 0x3);
+	reg = where & ~0x3;
+	if (size == 4)
+		hisi_pcie_apb_writel(pcie, val, reg);
+	else if (size == 2) {
+		reg_val = hisi_pcie_apb_readl(pcie, reg);
+		*(u16 __force *) walker = val;
+		hisi_pcie_apb_writel(pcie, reg_val, reg);
+	} else if (size == 1) {
+		reg_val = hisi_pcie_apb_readl(pcie, reg);
+		*(u8 __force *) walker = val;
+		hisi_pcie_apb_writel(pcie, reg_val, reg);
+	} else
+		return PCIBIOS_BAD_REGISTER_NUMBER;
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static int hisi_pcie_link_up(struct pcie_port *pp)
+{
+	struct hisi_pcie *hisi_pcie = to_hisi_pcie(pp);
+
+	return hisi_pcie->soc_ops->hisi_pcie_link_up(hisi_pcie);
+}
+
+struct pcie_host_ops hisi_pcie_host_ops = {
+	.rd_own_conf = hisi_pcie_cfg_read,
+	.wr_own_conf = hisi_pcie_cfg_write,
+	.link_up = hisi_pcie_link_up,
+};
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index 3e98d4e..552ebfc 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -21,124 +21,13 @@
 #include <linux/regmap.h>
 
 #include "pcie-designware.h"
+#include "pcie-hisi.h"
 
 #define PCIE_LTSSM_LINKUP_STATE				0x11
 #define PCIE_LTSSM_STATE_MASK				0x3F
 #define PCIE_SUBCTRL_SYS_STATE4_REG			0x6818
-#define PCIE_SYS_STATE4						0x31c
 #define PCIE_HIP06_CTRL_OFF					0x1000
-
-#define to_hisi_pcie(x)	container_of(x, struct hisi_pcie, pp)
-
-struct hisi_pcie;
-
-struct pcie_soc_ops {
-	int (*hisi_pcie_link_up)(struct hisi_pcie *pcie);
-};
-
-struct hisi_pcie {
-	struct regmap *subctrl;
-	void __iomem *reg_base;
-	u32 port_id;
-	struct pcie_port pp;
-	struct pcie_soc_ops *soc_ops;
-};
-
-static inline void hisi_pcie_apb_writel(struct hisi_pcie *pcie,
-					u32 val, u32 reg)
-{
-	writel(val, pcie->reg_base + reg);
-}
-
-static inline u32 hisi_pcie_apb_readl(struct hisi_pcie *pcie, u32 reg)
-{
-	return readl(pcie->reg_base + reg);
-}
-
-/* HipXX PCIe host only supports 32-bit config access */
-static int hisi_pcie_cfg_read(struct pcie_port *pp, int where, int size,
-			      u32 *val)
-{
-	u32 reg;
-	u32 reg_val;
-	struct hisi_pcie *pcie = to_hisi_pcie(pp);
-	void *walker = &reg_val;
-
-	walker += (where & 0x3);
-	reg = where & ~0x3;
-	reg_val = hisi_pcie_apb_readl(pcie, reg);
-
-	if (size == 1)
-		*val = *(u8 __force *) walker;
-	else if (size == 2)
-		*val = *(u16 __force *) walker;
-	else if (size == 4)
-		*val = reg_val;
-	else
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	return PCIBIOS_SUCCESSFUL;
-}
-
-/* HipXX PCIe host only supports 32-bit config access */
-static int hisi_pcie_cfg_write(struct pcie_port *pp, int where, int  size,
-				u32 val)
-{
-	u32 reg_val;
-	u32 reg;
-	struct hisi_pcie *pcie = to_hisi_pcie(pp);
-	void *walker = &reg_val;
-
-	walker += (where & 0x3);
-	reg = where & ~0x3;
-	if (size == 4)
-		hisi_pcie_apb_writel(pcie, val, reg);
-	else if (size == 2) {
-		reg_val = hisi_pcie_apb_readl(pcie, reg);
-		*(u16 __force *) walker = val;
-		hisi_pcie_apb_writel(pcie, reg_val, reg);
-	} else if (size == 1) {
-		reg_val = hisi_pcie_apb_readl(pcie, reg);
-		*(u8 __force *) walker = val;
-		hisi_pcie_apb_writel(pcie, reg_val, reg);
-	} else
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	return PCIBIOS_SUCCESSFUL;
-}
-
-static int hisi_pcie_link_up_hip05(struct hisi_pcie *hisi_pcie)
-{
-	u32 val;
-
-	regmap_read(hisi_pcie->subctrl, PCIE_SUBCTRL_SYS_STATE4_REG +
-		    0x100 * hisi_pcie->port_id, &val);
-
-	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
-}
-
-static int hisi_pcie_link_up_hip06(struct hisi_pcie *hisi_pcie)
-{
-	u32 val;
-
-	val = hisi_pcie_apb_readl(hisi_pcie, PCIE_HIP06_CTRL_OFF +
-			PCIE_SYS_STATE4);
-
-	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
-}
-
-static int hisi_pcie_link_up(struct pcie_port *pp)
-{
-	struct hisi_pcie *hisi_pcie = to_hisi_pcie(pp);
-
-	return hisi_pcie->soc_ops->hisi_pcie_link_up(hisi_pcie);
-}
-
-static struct pcie_host_ops hisi_pcie_host_ops = {
-	.rd_own_conf = hisi_pcie_cfg_read,
-	.wr_own_conf = hisi_pcie_cfg_write,
-	.link_up = hisi_pcie_link_up,
-};
+#define PCIE_SYS_STATE4						0x31c
 
 static int hisi_add_pcie_port(struct pcie_port *pp,
 				     struct platform_device *pdev)
@@ -215,6 +104,26 @@ static int hisi_pcie_probe(struct platform_device *pdev)
 	return 0;
 }
 
+static int hisi_pcie_link_up_hip05(struct hisi_pcie *hisi_pcie)
+{
+	u32 val;
+
+	regmap_read(hisi_pcie->subctrl, PCIE_SUBCTRL_SYS_STATE4_REG +
+		    0x100 * hisi_pcie->port_id, &val);
+
+	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
+}
+
+static int hisi_pcie_link_up_hip06(struct hisi_pcie *hisi_pcie)
+{
+	u32 val;
+
+	val = hisi_pcie_apb_readl(hisi_pcie, PCIE_HIP06_CTRL_OFF +
+			PCIE_SYS_STATE4);
+
+	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
+}
+
 static struct pcie_soc_ops hip05_ops = {
 		&hisi_pcie_link_up_hip05
 };
diff --git a/drivers/pci/host/pcie-hisi.h b/drivers/pci/host/pcie-hisi.h
new file mode 100644
index 0000000..f64249d
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi.h
@@ -0,0 +1,44 @@
+/*
+ * PCIe host controller driver for HiSilicon SoCs
+ *
+ * Copyright (C) 2015 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Zhou Wang <wangzhou1 at hisilicon.com>
+ *         Dacai Zhu <zhudacai at hisilicon.com>
+ *         Gabriele Paoloni <gabriele.paoloni at huawei.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.
+ */
+#ifndef PCIE_HISI_H_
+#define PCIE_HISI_H_
+
+struct hisi_pcie {
+	struct regmap *subctrl;
+	void __iomem *reg_base;
+	u32 port_id;
+	struct pcie_port pp;
+	struct pcie_soc_ops *soc_ops;
+};
+
+struct pcie_soc_ops {
+	int (*hisi_pcie_link_up)(struct hisi_pcie *pcie);
+};
+
+static inline void hisi_pcie_apb_writel(struct hisi_pcie *pcie,
+					u32 val, u32 reg)
+{
+	writel(val, pcie->reg_base + reg);
+}
+
+static inline u32 hisi_pcie_apb_readl(struct hisi_pcie *pcie, u32 reg)
+{
+	return readl(pcie->reg_base + reg);
+}
+
+#define to_hisi_pcie(x)	container_of(x, struct hisi_pcie, pp)
+
+extern struct pcie_host_ops hisi_pcie_host_ops;
+
+#endif /* PCIE_HISI_H_ */
-- 
1.9.1



From gabriele.paoloni at huawei.com  Thu Feb  4 03:37:37 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Thu, 4 Feb 2016 19:37:37 +0800
Subject: [RFC PATCH 1/4] PCI: Designware: Add support for ACPI based
 controllers
In-Reply-To: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
References: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
Message-ID: <1454585860-60709-2-git-send-email-gabriele.paoloni@huawei.com>

From: gabriele paoloni <gabriele.paoloni at huawei.com>

This patch reworks the current Designware framework to
enable ACPI based controllers.

Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
Signed-off-by: Dongdong Liu <liudongdong3 at huawei.com>
---
 drivers/pci/host/pcie-designware.c | 39 +++++++++++++++++++++++++++++++++-----
 drivers/pci/host/pcie-designware.h |  1 +
 2 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
index 02a7452..4ced20d 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -11,6 +11,7 @@
  * published by the Free Software Foundation.
  */
 
+#include <linux/acpi.h>
 #include <linux/irq.h>
 #include <linux/irqdomain.h>
 #include <linux/kernel.h>
@@ -19,6 +20,7 @@
 #include <linux/of_address.h>
 #include <linux/of_pci.h>
 #include <linux/pci.h>
+#include <linux/pci-acpi.h>
 #include <linux/pci_regs.h>
 #include <linux/platform_device.h>
 #include <linux/types.h>
@@ -46,7 +48,6 @@
 #define PCIE_MSI_INTR0_ENABLE		0x828
 #define PCIE_MSI_INTR0_MASK		0x82C
 #define PCIE_MSI_INTR0_STATUS		0x830
-
 #define PCIE_ATU_VIEWPORT		0x900
 #define PCIE_ATU_REGION_INBOUND		(0x1 << 31)
 #define PCIE_ATU_REGION_OUTBOUND	(0x0 << 31)
@@ -69,7 +70,7 @@
 #define PCIE_ATU_FUNC(x)		(((x) & 0x7) << 16)
 #define PCIE_ATU_UPPER_TARGET		0x91C
 
-static struct pci_ops dw_pcie_ops;
+struct pci_ops dw_pcie_ops;
 
 int dw_pcie_cfg_read(void __iomem *addr, int size, u32 *val)
 {
@@ -657,8 +658,22 @@ static int dw_pcie_valid_config(struct pcie_port *pp,
 static int dw_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
 			int size, u32 *val)
 {
-	struct pcie_port *pp = bus->sysdata;
 	int ret;
+	struct pcie_port *pp;
+	struct pci_bus *bridge_bus;
+
+	for (bridge_bus = bus; bridge_bus->parent;
+			bridge_bus = bridge_bus->parent)
+		;
+
+	if (has_acpi_companion(bridge_bus->bridge)) {
+#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
+		struct acpi_pci_root *root = bus->sysdata;
+
+		pp = root->sysdata;
+#endif /* CONFIG_ACPI_PCI_HOST_GENERIC */
+	} else
+		pp = bus->sysdata;
 
 	if (dw_pcie_valid_config(pp, bus, PCI_SLOT(devfn)) == 0) {
 		*val = 0xffffffff;
@@ -681,8 +696,22 @@ static int dw_pcie_rd_conf(struct pci_bus *bus, u32 devfn, int where,
 static int dw_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
 			int where, int size, u32 val)
 {
-	struct pcie_port *pp = bus->sysdata;
 	int ret;
+	struct pcie_port *pp;
+	struct pci_bus *bridge_bus;
+
+	for (bridge_bus = bus; bridge_bus->parent;
+			bridge_bus = bridge_bus->parent)
+		;
+
+	if (has_acpi_companion(bridge_bus->bridge)) {
+#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
+		struct acpi_pci_root *root = bus->sysdata;
+
+		pp = root->sysdata;
+#endif /* CONFIG_ACPI_PCI_HOST_GENERIC */
+	} else
+		pp = bus->sysdata;
 
 	if (dw_pcie_valid_config(pp, bus, PCI_SLOT(devfn)) == 0)
 		return PCIBIOS_DEVICE_NOT_FOUND;
@@ -700,7 +729,7 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
 	return ret;
 }
 
-static struct pci_ops dw_pcie_ops = {
+struct pci_ops dw_pcie_ops = {
 	.read = dw_pcie_rd_conf,
 	.write = dw_pcie_wr_conf,
 };
diff --git a/drivers/pci/host/pcie-designware.h b/drivers/pci/host/pcie-designware.h
index 2356d29..fd27fa4 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -80,4 +80,5 @@ int dw_pcie_link_up(struct pcie_port *pp);
 void dw_pcie_setup_rc(struct pcie_port *pp);
 int dw_pcie_host_init(struct pcie_port *pp);
 
+extern struct pci_ops dw_pcie_ops;
 #endif /* _PCIE_DESIGNWARE_H */
-- 
1.9.1



From gabriele.paoloni at huawei.com  Thu Feb  4 03:37:40 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Thu, 4 Feb 2016 19:37:40 +0800
Subject: [RFC PATCH 4/4] PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs
 Host Controllers
In-Reply-To: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
References: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
Message-ID: <1454585860-60709-5-git-send-email-gabriele.paoloni@huawei.com>

From: gabriele paoloni <gabriele.paoloni at huawei.com>

This patch adds specific quirks for PCI config space accessors,
it uses _HID to decide whether to hook pci_ops or not.

Signed-off-by: Dongdong Liu <liudongdong3 at huawei.com>
Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
---
 MAINTAINERS                       |   1 +
 drivers/pci/host/Kconfig          |   9 +++
 drivers/pci/host/Makefile         |   1 +
 drivers/pci/host/pcie-hisi-acpi.c | 147 ++++++++++++++++++++++++++++++++++++++
 drivers/pci/host/pcie-hisi.c      |   2 -
 drivers/pci/host/pcie-hisi.h      |   6 ++
 6 files changed, 164 insertions(+), 2 deletions(-)
 create mode 100644 drivers/pci/host/pcie-hisi-acpi.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 8d6ec25..d35c300 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8250,6 +8250,7 @@ F:	Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
 F:	drivers/pci/host/pcie-hisi.h
 F:	drivers/pci/host/pcie-hisi.c
 F:	drivers/pci/host/pcie-hisi-common.c
+F:	drivers/pci/host/pcie-hisi-acpi.c
 
 PCMCIA SUBSYSTEM
 P:	Linux PCMCIA Team
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 4d385d6..7a6b80d 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -174,4 +174,13 @@ config PCI_HISI
 	  Say Y here if you want PCIe controller support on HiSilicon
 	  Hip05 and Hip06 SoCs
 
+config PCI_HISI_ACPI
+	bool "ACPI PCI HiSilicon SoC HIP05 PCIe controller"
+	depends on ACPI
+	select ACPI_PCI_HOST_GENERIC
+	select PCIE_DW
+	help
+	  Say Y here if you want ACPI PCIe controller support on
+	  HiSilicon Hip05 and Hip06 SoCs
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 6248320..ff010b6 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -20,3 +20,4 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
 obj-$(CONFIG_PCI_HISI) += pcie-hisi.o pcie-hisi-common.o
+obj-$(CONFIG_PCI_HISI_ACPI) += pcie-hisi-acpi.o pcie-hisi-common.o
diff --git a/drivers/pci/host/pcie-hisi-acpi.c b/drivers/pci/host/pcie-hisi-acpi.c
new file mode 100644
index 0000000..1bca4f1
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi-acpi.c
@@ -0,0 +1,147 @@
+/*
+ * PCIe host controller driver for HiSilicon HipXX SoCs
+ *
+ * Copyright (C) 2016 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Dongdong Liu <liudongdong3 at huawei.com>
+ *         Gabriele Paoloni <gabriele.paoloni at huawei.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.
+ */
+#include <linux/interrupt.h>
+#include <linux/acpi.h>
+#include <linux/ecam.h>
+#include <linux/pci.h>
+#include <linux/pci-acpi.h>
+#include "pcie-designware.h"
+#include "pcie-hisi.h"
+
+#define GET_PCIE_LINK_STATUS  0x0
+
+/* uuid 6d30f553-836c-408e-b6ad-45bccc957949 */
+const u8 hisi_pcie_acpi_dsm_uuid[] = {
+	0x53, 0xf5, 0x30, 0x6d, 0x6c, 0x83, 0x8e, 0x40,
+	0xb6, 0xad, 0x45, 0xbc, 0xcc, 0x95, 0x79, 0x49
+};
+
+static const struct acpi_device_id hisi_pcie_ids[] = {
+	{"HISI0080", 0},
+	{"", 0},
+};
+
+static int hisi_pcie_get_addr(struct acpi_pci_root *root, const char *name,
+				void __iomem **addr)
+{
+	struct acpi_device *device;
+	u64 base;
+	u64 size;
+	u32 buf[4];
+	int ret;
+
+	device =  root->device;
+	ret = fwnode_property_read_u32_array(&device->fwnode, name,
+					buf, ARRAY_SIZE(buf));
+	if (ret) {
+		dev_err(&device->dev, "can't get %s\n", name);
+		return ret;
+	}
+
+	base = ((u64)buf[0] << 32) | buf[1];
+	size =  ((u64)buf[2] << 32) | buf[3];
+	*addr = devm_ioremap(&device->dev, base, size);
+	if (!(*addr)) {
+		dev_err(&device->dev, "error with ioremap\n");
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+
+static int hisi_pcie_link_up_acpi(struct hisi_pcie *hisi_pcie)
+{
+	u32 val;
+
+	struct acpi_pci_root *root;
+	struct acpi_device *device;
+	union acpi_object *obj;
+
+	root = hisi_pcie->root;
+	device = root->device;
+	obj = acpi_evaluate_dsm(device->handle,
+		hisi_pcie_acpi_dsm_uuid, 0,
+		GET_PCIE_LINK_STATUS, NULL);
+
+	if (!obj  ||  obj->type != ACPI_TYPE_INTEGER)  {
+		dev_err(&device->dev, "can't get link status from _DSM\n");
+		return 0;
+	}
+	val = obj->integer.value;
+
+	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
+
+}
+
+static struct pcie_soc_ops acpi_ops = {
+		&hisi_pcie_link_up_acpi
+};
+
+/*
+ * Retrieve rc_dbi base and size from _DSD
+ * Name (_DSD, Package () {
+ *	ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+ *	Package () {
+ *	Package () {"rc-dbi", Package () { 0x0, 0xb0080000, 0x0, 0x10000 }},
+ *	}
+ *	})
+ */
+static int hisi_pcie_init(struct acpi_pci_root *root)
+{
+	struct hisi_pcie  *pcie;
+	int ret;
+	struct acpi_device *device;
+
+	device =  root->device;
+	pcie = devm_kzalloc(&device->dev, sizeof(*pcie), GFP_KERNEL);
+	if (!pcie)
+		return -ENOMEM;
+
+	ret = hisi_pcie_get_addr(root, "rc-dbi", &pcie->reg_base);
+	if (ret) {
+		dev_err(&device->dev, "can't get rc-dbi\n");
+		return ret;
+	}
+
+	pcie->pp.dbi_base = pcie->reg_base;
+	pcie->pp.root_bus_nr = root->secondary.start;
+	pcie->pp.ops = &hisi_pcie_host_ops;
+	pcie->root = root;
+	pcie->soc_ops = &acpi_ops;
+	root->sysdata = &pcie->pp;
+	return 0;
+}
+
+static int hisi_pcie_match(struct pci_mcfg_fixup *fixup,
+			struct acpi_pci_root *root)
+{
+	int ret;
+	struct acpi_device *device;
+
+	device = root->device;
+	ret = acpi_match_device_ids(device, hisi_pcie_ids);
+	if (ret)
+		return 0;
+
+	ret = hisi_pcie_init(root);
+	if (ret)
+		dev_warn(&device->dev, "hisi pcie init fail\n");
+
+	dw_pcie_ops.map_bus = pci_mcfg_dev_base;
+
+	return 1;
+}
+
+DECLARE_ACPI_MCFG_FIXUP(NULL, hisi_pcie_match, &dw_pcie_ops,
+	PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index 1e45869..d7867cf 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -23,8 +23,6 @@
 #include "pcie-designware.h"
 #include "pcie-hisi.h"
 
-#define PCIE_LTSSM_LINKUP_STATE				0x11
-#define PCIE_LTSSM_STATE_MASK				0x3F
 #define PCIE_SUBCTRL_SYS_STATE4_REG			0x6818
 #define PCIE_HIP06_CTRL_OFF					0x1000
 #define PCIE_SYS_STATE4						0x31c
diff --git a/drivers/pci/host/pcie-hisi.h b/drivers/pci/host/pcie-hisi.h
index f64249d..396deb2 100644
--- a/drivers/pci/host/pcie-hisi.h
+++ b/drivers/pci/host/pcie-hisi.h
@@ -15,6 +15,9 @@
 #define PCIE_HISI_H_
 
 struct hisi_pcie {
+#ifdef CONFIG_PCI_HISI_ACPI
+	struct acpi_pci_root *root;
+#endif /* CONFIG_ACPI_HOST_GENERIC */
 	struct regmap *subctrl;
 	void __iomem *reg_base;
 	u32 port_id;
@@ -41,4 +44,7 @@ static inline u32 hisi_pcie_apb_readl(struct hisi_pcie *pcie, u32 reg)
 
 extern struct pcie_host_ops hisi_pcie_host_ops;
 
+#define PCIE_LTSSM_LINKUP_STATE				0x11
+#define PCIE_LTSSM_STATE_MASK				0x3F
+
 #endif /* PCIE_HISI_H_ */
-- 
1.9.1



From gabriele.paoloni at huawei.com  Thu Feb  4 03:37:39 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Thu, 4 Feb 2016 19:37:39 +0800
Subject: [RFC PATCH 3/4] PCI: hisi: Make the HiSilicon PCIe host controller
 ECAM compliant
In-Reply-To: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
References: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
Message-ID: <1454585860-60709-4-git-send-email-gabriele.paoloni@huawei.com>

From: gabriele paoloni <gabriele.paoloni at huawei.com>

This patch modifies the current Hip05/Hip06 PCIe host controller
driver to make it ECAM compliant. This is needed in preparation
for the ACPI based driver to allow both DT and ACPI drivers to
use the same BIOS (that configure the Designware iATUs).

Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
Signed-off-by: Dongdong Liu <liudongdong3 at huawei.com>
---
 .../devicetree/bindings/pci/hisilicon-pcie.txt     |  4 ++--
 drivers/pci/host/pcie-hisi-common.c                | 15 +++++++++++++++
 drivers/pci/host/pcie-hisi.c                       | 22 ++++++++++++++++++++++
 3 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
index b721bea..5c1bad0 100644
--- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
@@ -23,8 +23,8 @@ Optional properties:
 Hip05 Example (note that Hip06 is the same except compatible):
 	pcie at 0xb0080000 {
 		compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
-		reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0 0x2000>;
-		reg-names = "rc_dbi", "config";
+		reg = <0 0xb0080000 0 0x10000>, <0x220 0x00100000 0 0x0f00000>;
+		reg-names = "rc_dbi", "ecam-cfg";
 		bus-range = <0  15>;
 		msi-parent = <&its_pcie>;
 		#address-cells = <3>;
diff --git a/drivers/pci/host/pcie-hisi-common.c b/drivers/pci/host/pcie-hisi-common.c
index ff93293..cbfb6c4 100644
--- a/drivers/pci/host/pcie-hisi-common.c
+++ b/drivers/pci/host/pcie-hisi-common.c
@@ -23,6 +23,19 @@
 #include "pcie-hisi.h"
 
 /* HipXX PCIe host only supports 32-bit config access */
+static int hisi_rd_other_conf(struct pcie_port *pp, struct pci_bus *bus,
+		unsigned int devfn, int where, int size, u32 *value)
+{
+	return pci_generic_config_read(bus, devfn, where, size, value);
+}
+
+static int hisi_wr_other_conf(struct pcie_port *pp, struct pci_bus *bus,
+		unsigned int devfn, int where, int size, u32 value)
+{
+	return pci_generic_config_write(bus, devfn, where, size, value);
+}
+
+/* HipXX PCIe host only supports 32-bit config access */
 static int hisi_pcie_cfg_read(struct pcie_port *pp, int where, int size,
 			      u32 *val)
 {
@@ -82,6 +95,8 @@ static int hisi_pcie_link_up(struct pcie_port *pp)
 }
 
 struct pcie_host_ops hisi_pcie_host_ops = {
+	.rd_other_conf = hisi_rd_other_conf,
+	.wr_other_conf = hisi_wr_other_conf,
 	.rd_own_conf = hisi_pcie_cfg_read,
 	.wr_own_conf = hisi_pcie_cfg_write,
 	.link_up = hisi_pcie_link_up,
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index 552ebfc..1e45869 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -29,6 +29,18 @@
 #define PCIE_HIP06_CTRL_OFF					0x1000
 #define PCIE_SYS_STATE4						0x31c
 
+static void __iomem *hisi_pci_map_cfg_bus_cam(struct pci_bus *bus,
+					     unsigned int devfn,
+					     int where)
+{
+	void __iomem *addr;
+	struct pcie_port *pp = bus->sysdata;
+
+	addr = pp->va_cfg1_base + where;
+
+	return addr;
+}
+
 static int hisi_add_pcie_port(struct pcie_port *pp,
 				     struct platform_device *pdev)
 {
@@ -48,6 +60,8 @@ static int hisi_add_pcie_port(struct pcie_port *pp,
 
 	pp->ops = &hisi_pcie_host_ops;
 
+	dw_pcie_ops.map_bus = hisi_pci_map_cfg_bus_cam;
+
 	ret = dw_pcie_host_init(pp);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to initialize host\n");
@@ -93,6 +107,14 @@ static int hisi_pcie_probe(struct platform_device *pdev)
 
 	hisi_pcie->pp.dbi_base = hisi_pcie->reg_base;
 
+	reg = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam-cfg");
+	hisi_pcie->pp.va_cfg0_base = devm_ioremap_resource(&pdev->dev, reg);
+	if (IS_ERR(hisi_pcie->pp.va_cfg0_base)) {
+		dev_err(pp->dev, "cannot get ecam-cfg\n");
+		return PTR_ERR(hisi_pcie->pp.va_cfg0_base);
+	}
+	hisi_pcie->pp.va_cfg1_base = hisi_pcie->pp.va_cfg0_base;
+
 	ret = hisi_add_pcie_port(pp, pdev);
 	if (ret)
 		return ret;
-- 
1.9.1



From gabriele.paoloni at huawei.com  Thu Feb  4 03:37:36 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Thu, 4 Feb 2016 19:37:36 +0800
Subject: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host Controllers
Message-ID: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>

From: gabriele paoloni <gabriele.paoloni at huawei.com>

This patchset adds ACPI support for the HiSilicon Hip05/Hip06 SoC PCIe controllers
The four patches respectively:
        - rework PCie Designware to be used for ACPI PCI Host controllers
        - re-architect the current HiSilicon driver to make it scalable to the
          new ACPI quirks
	- rework the current HiSilicon driver to make it ECAM compliant
        - adds the HiSilicon ACPI specific quirks.

   This patchset  is based on 
   https://github.com/semihalf-nowicki-tomasz/linux.git
   branch pci-acpi-v3 + Hip06 support applied on top:
   https://patchwork.ozlabs.org/patch/549198/

gabriele paoloni (4):
  PCI: Designware: Add support for ACPI based controllers
  PCI: hisi: re-architect Hip05/Hip06 controllers driver to preapare for
    ACPI
  PCI: hisi: Make the HiSilicon PCIe host controller ECAM compliant
  PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

 .../devicetree/bindings/pci/hisilicon-pcie.txt     |   4 +-
 MAINTAINERS                                        |   3 +
 drivers/pci/host/Kconfig                           |   9 ++
 drivers/pci/host/Makefile                          |   3 +-
 drivers/pci/host/pcie-designware.c                 |  39 +++++-
 drivers/pci/host/pcie-designware.h                 |   1 +
 drivers/pci/host/pcie-hisi-acpi.c                  | 147 ++++++++++++++++++++
 drivers/pci/host/pcie-hisi-common.c                | 103 ++++++++++++++
 drivers/pci/host/pcie-hisi.c                       | 149 ++++++---------------
 drivers/pci/host/pcie-hisi.h                       |  50 +++++++
 10 files changed, 390 insertions(+), 118 deletions(-)
 create mode 100644 drivers/pci/host/pcie-hisi-acpi.c
 create mode 100644 drivers/pci/host/pcie-hisi-common.c
 create mode 100644 drivers/pci/host/pcie-hisi.h

-- 
1.9.1



From moinejf at free.fr  Thu Feb  4 03:11:07 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Thu, 4 Feb 2016 12:11:07 +0100
Subject: [PATCH v4 2/2] drm: sunxi: Add a basic DRM driver for Allwinner
 DE2
In-Reply-To: <20160202215036.GA25521@rob-hp-laptop>
References: <cover.1454435944.git.moinejf@free.fr>
 <76ae5b406ad64b2717c0b1c62c3005a62b2715b8.1454435944.git.moinejf@free.fr>
 <20160202215036.GA25521@rob-hp-laptop>
Message-ID: <20160204121107.2fa6d12c161ce37a3901f118@free.fr>

On Tue, 2 Feb 2016 15:50:36 -0600
Rob Herring <robh at kernel.org> wrote:

> > diff --git a/Documentation/devicetree/bindings/display/sunxi.txt b/Documentation/devicetree/bindings/display/sunxi.txt
> > new file mode 100644
> > index 0000000..35f9763
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/sunxi.txt
> > @@ -0,0 +1,81 @@
> > +Allwinner sunxi display subsystem
> > +=================================
> > +
> > +The sunxi display subsystems contain a display controller (DE),
> > +one or two LCD controllers (TCON) and their external interfaces.
> > +
> > +Display controller
> > +==================
> > +
> > +Required properties:
> > +
> > +- compatible: value should be one of the following
> > +		"allwinner,sun8i-h3-display-engine"
> > +
> > +- clocks: must include clock specifiers corresponding to entries in the
> > +		clock-names property.
> > +
> > +- clock-names: must contain
> > +		gate: for DE activation
> > +		clock: DE clock
> > +
> > +- resets: phandle to the reset of the device
> > +
> > +- ports: phandle's to the LCD ports
> > +
> > +LCD controller
> > +==============
> > +
> > +Required properties:
> > +
> > +- compatible: value should be one of the following
> > +		"allwinner,sun8i-h3-lcd"
> > +
> > +- clocks: must include clock specifiers corresponding to entries in the
> > +		clock-names property.
> > +
> > +- clock-names: must contain
> > +		gate: for LCD activation
> > +		clock: pixel clock
> > +
> > +- resets: phandle to the reset of the device
> > +
> > +- port: port node with endpoint definitions as defined in
> > +	Documentation/devicetree/bindings/media/video-interfaces.txt
> 
> Define how many ports and endpoints.

As told in some other mail, such a video binding should be generic.
The number of ports depends on the hardware. Most SoCs have only one
port per LCD, but some other have many ports as the A83T (3 ports from
the LCD0).

> > +
> > +Example:
> > +
> > +	de: de-controller at 01000000 {
> > +		compatible = "allwinner,sun8i-h3-display-engine";
> > +		...
> > +		clocks = <&bus_gates 44>, <&de_clk>;
> > +		clock-names = "gate", "clock";
> > +		resets = <&ahb_rst 44>;
> > +		ports = <&lcd0_p>;
> 
> This is pointless if you only have one item in ports. Is this really a 
> separate h/w block? Can't you move all this into the node below?

Well, this example is extracted from the H3 where the DE and LCDs have
different clocks, I/O resources and functions (the DE builds the video
frames while the LCDs - TCONs - convert them to video flows).

The example is not complete because there are 2 LCDs in the H3:
		ports = <&lcd0_p>,		/* HDMI */
			<&lcd1_p>;		/* TV (CVBS) */
But, for SoCs with only one LCD, the description would be the same.

> > +	};
> > +
> > +	lcd0: lcd-controller at 01c0c000 {
> > +		compatible = "allwinner,sun8i-h3-lcd";
> > +		...
> > +		clocks = <&bus_gates 35>, <&tcon0_clk>;
> > +		clock-names = "gate", "clock";
> > +		resets = <&ahb_rst 35>;
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +		lcd0_p: port {
> > +			lcd0_ep: endpoint {
> > +				remote-endpoint = <&hdmi_ep>;
> > +			};
> > +		};
> > +	};


-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/



From will.deacon at arm.com  Thu Feb  4 03:33:45 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 4 Feb 2016 11:33:45 +0000
Subject: [PATCH v2] drivers/perf: arm_pmu: make info messages more verbose
In-Reply-To: <1454579928-20231-1-git-send-email-dirk.behme@de.bosch.com>
References: <1454579928-20231-1-git-send-email-dirk.behme@de.bosch.com>
Message-ID: <20160204113343.GC17257@arm.com>

On Thu, Feb 04, 2016 at 10:58:48AM +0100, Dirk Behme wrote:
> On a big.LITTLE system e.g. with Cortex A57 and A53 in case not all cores
> are online at PMU probe time we might get
> 
> hw perfevents: failed to probe PMU!
> hw perfevents: failed to register PMU devices!
> 
> making it unclear which cores failed, here.
> 
> Add the device tree full name which failed and the error value resulting
> in a more verbose and helpful message like
> 
> hw perfevents: /soc/pmu_a53: failed to probe PMU! Error -6
> hw perfevents: /soc/pmu_a53: failed to register PMU devices! Error -6
> 
> Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
> ---
> Changes in v2: Use the full node name from DT instead of pmu->name, as if
> we fail to find anything in the match table, that'll be NULL. Additionally,
> add the error value to get an idea why it failed.
> 
>  drivers/perf/arm_pmu.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)

This looks fine to me, but please can you rebase on top of my perf/updates
branch [1] so that I can queue it?

Cheers,

Will

[1] https://git.kernel.org/cgit/linux/kernel/git/will/linux.git/log/?h=perf/updates


From tiffany.lin at mediatek.com  Thu Feb  4 03:35:03 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Thu, 4 Feb 2016 19:35:03 +0800
Subject: [PATCH v4 8/8] arm64: dts: mediatek: Add Video Encoder for MT8173
In-Reply-To: <1454585703-42428-8-git-send-email-tiffany.lin@mediatek.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-7-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-8-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <1454585703-42428-9-git-send-email-tiffany.lin@mediatek.com>

Add video encoder node for MT8173

Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   39 ++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 5b0b38a..f61669d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -1150,6 +1150,45 @@
 			clock-names = "apb", "smi";
 		};
 
+		vcodec_enc: vcodec at 18002000 {
+			compatible = "mediatek,mt8173-vcodec-enc";
+			reg = <0 0x18002000 0 0x1000>,	/* VENC_SYS */
+			      <0 0x19002000 0 0x1000>;	/* VENC_LT_SYS */
+			interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>,
+				     <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>;
+			mediatek,larb = <&larb3>,
+					<&larb5>;
+			iommus = <&iommu M4U_PORT_VENC_RCPU>,
+				 <&iommu M4U_PORT_VENC_REC>,
+				 <&iommu M4U_PORT_VENC_BSDMA>,
+				 <&iommu M4U_PORT_VENC_SV_COMV>,
+				 <&iommu M4U_PORT_VENC_RD_COMV>,
+				 <&iommu M4U_PORT_VENC_CUR_LUMA>,
+				 <&iommu M4U_PORT_VENC_CUR_CHROMA>,
+				 <&iommu M4U_PORT_VENC_REF_LUMA>,
+				 <&iommu M4U_PORT_VENC_REF_CHROMA>,
+				 <&iommu M4U_PORT_VENC_NBM_RDMA>,
+				 <&iommu M4U_PORT_VENC_NBM_WDMA>,
+				 <&iommu M4U_PORT_VENC_RCPU_SET2>,
+				 <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
+				 <&iommu M4U_PORT_VENC_BSDMA_SET2>,
+				 <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
+				 <&iommu M4U_PORT_VENC_RD_COMA_SET2>,
+				 <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
+				 <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
+				 <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
+				 <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
+			mediatek,vpu = <&vpu>;
+			clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
+				 <&topckgen CLK_TOP_VENC_SEL>,
+				 <&topckgen CLK_TOP_UNIVPLL1_D2>,
+				 <&topckgen CLK_TOP_VENC_LT_SEL>;
+			clock-names = "vencpll_d2",
+				      "venc_sel",
+				      "univpll1_d2",
+				      "venc_lt_sel";
+		};
+
 		vencltsys: clock-controller at 19000000 {
 			compatible = "mediatek,mt8173-vencltsys", "syscon";
 			reg = <0 0x19000000 0 0x1000>;
-- 
1.7.9.5



From tiffany.lin at mediatek.com  Thu Feb  4 03:34:56 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Thu, 4 Feb 2016 19:34:56 +0800
Subject: [PATCH v4 1/8] dt-bindings: Add a binding for Mediatek Video Processor
In-Reply-To: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>

From: Andrew-CT Chen <andrew-ct.chen at mediatek.com>

Add a DT binding documentation of Video Processor Unit for the
MT8173 SoC from Mediatek.


Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
---
 .../devicetree/bindings/media/mediatek-vpu.txt     |   31 ++++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-vpu.txt b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
new file mode 100644
index 0000000..2a5bac3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
@@ -0,0 +1,31 @@
+* Mediatek Video Processor Unit
+
+Video Processor Unit is a HW video controller. It controls HW Codec including
+H.264/VP8/VP9 Decode, H.264/VP8 Encode and Image Processor (scale/rotate/color convert).
+
+Required properties:
+  - compatible: "mediatek,mt8173-vpu"
+  - reg: Must contain an entry for each entry in reg-names.
+  - reg-names: Must include the following entries:
+    "tcm": tcm base
+    "cfg_reg": Main configuration registers base
+  - interrupts: interrupt number to the cpu.
+  - clocks : clock name from clock manager
+  - clock-names: must be main. It is the main clock of VPU
+
+Optional properties:
+  - memory-region: phandle to a node describing memory (see
+    Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
+    to be used for VPU extended memory; if not present, VPU may be located
+    anywhere in the memory
+
+Example:
+	vpu: vpu at 10020000 {
+		compatible = "mediatek,mt8173-vpu";
+		reg = <0 0x10020000 0 0x30000>,
+		      <0 0x10050000 0 0x100>;
+		reg-names = "tcm", "cfg_reg";
+		interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&topckgen TOP_SCP_SEL>;
+		clock-names = "main";
+	};
-- 
1.7.9.5



From tiffany.lin at mediatek.com  Thu Feb  4 03:34:59 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Thu, 4 Feb 2016 19:34:59 +0800
Subject: [PATCH v4 4/8] dt-bindings: Add a binding for Mediatek Video Encoder
In-Reply-To: <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>

Add a DT binding documentation of Video Encoder for the
MT8173 SoC from Mediatek.

Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
---
 .../devicetree/bindings/media/mediatek-vcodec.txt  |   59 ++++++++++++++++++++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
new file mode 100644
index 0000000..572bfdd
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -0,0 +1,59 @@
+Mediatek Video Codec
+
+Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
+supports high resolution encoding functionalities.
+
+Required properties:
+- compatible : "mediatek,mt8173-vcodec-enc" for encoder
+- reg : Physical base address of the video codec registers and length of
+  memory mapped region.
+- interrupts : interrupt number to the cpu.
+- mediatek,larb : must contain the local arbiters in the current Socs.
+- clocks : list of clock specifiers, corresponding to entries in
+  the clock-names property.
+- clock-names: encoder must contain "vencpll_d2", "venc_sel", "univpll1_d2",
+  "venc_lt_sel".
+- iommus : should point to the respective IOMMU block with master port as
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  for details.
+- mediatek,vpu : the node of video processor unit
+
+Example:
+vcodec_enc: vcodec at 0x18002000 {
+    compatible = "mediatek,mt8173-vcodec-enc";
+    reg = <0 0x18002000 0 0x1000>,    /*VENC_SYS*/
+          <0 0x19002000 0 0x1000>;    /*VENC_LT_SYS*/
+    interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>,
+           <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>;
+    mediatek,larb = <&larb3>,
+		    <&larb5>;
+    iommus = <&iommu M4U_PORT_VENC_RCPU>,
+             <&iommu M4U_PORT_VENC_REC>,
+             <&iommu M4U_PORT_VENC_BSDMA>,
+             <&iommu M4U_PORT_VENC_SV_COMV>,
+             <&iommu M4U_PORT_VENC_RD_COMV>,
+             <&iommu M4U_PORT_VENC_CUR_LUMA>,
+             <&iommu M4U_PORT_VENC_CUR_CHROMA>,
+             <&iommu M4U_PORT_VENC_REF_LUMA>,
+             <&iommu M4U_PORT_VENC_REF_CHROMA>,
+             <&iommu M4U_PORT_VENC_NBM_RDMA>,
+             <&iommu M4U_PORT_VENC_NBM_WDMA>,
+             <&iommu M4U_PORT_VENC_RCPU_SET2>,
+             <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
+             <&iommu M4U_PORT_VENC_BSDMA_SET2>,
+             <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
+             <&iommu M4U_PORT_VENC_RD_COMA_SET2>,
+             <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
+             <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
+             <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
+             <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
+    mediatek,vpu = <&vpu>;
+    clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
+             <&topckgen CLK_TOP_VENC_SEL>,
+             <&topckgen CLK_TOP_UNIVPLL1_D2>,
+             <&topckgen CLK_TOP_VENC_LT_SEL>;
+    clock-names = "vencpll_d2",
+                  "venc_sel",
+                  "univpll1_d2",
+                  "venc_lt_sel";
+  };
-- 
1.7.9.5



From tiffany.lin at mediatek.com  Thu Feb  4 03:34:58 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Thu, 4 Feb 2016 19:34:58 +0800
Subject: [PATCH v4 3/8] arm64: dts: mediatek: Add node for Mediatek Video
 Processor Unit
In-Reply-To: <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>

Add VPU drivers for MT8173

Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 60a1284..5b0b38a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -200,6 +200,18 @@
 		clock-output-names = "cpum_ck";
 	};
 
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		vpu_dma_reserved: vpu_dma_mem_region {
+			compatible = "shared-dma-pool";
+			reg = <0 0xb7000000 0 0x500000>;
+			alignment = <0x1000>;
+			no-map;
+		};
+	};
+
 	thermal-zones {
 		cpu_thermal: cpu_thermal {
 			polling-delay-passive = <1000>; /* milliseconds */
@@ -422,6 +434,17 @@
 			clocks = <&infracfg CLK_INFRA_CEC>;
 		};
 
+		vpu: vpu at 10020000 {
+			compatible = "mediatek,mt8173-vpu";
+			reg = <0 0x10020000 0 0x30000>,
+			      <0 0x10050000 0 0x100>;
+			reg-names = "tcm", "cfg_reg";
+			interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&topckgen CLK_TOP_SCP_SEL>;
+			clock-names = "main";
+			memory-region = <&vpu_dma_reserved>;
+		};
+
 		sysirq: intpol-controller at 10200620 {
 			compatible = "mediatek,mt8173-sysirq",
 				     "mediatek,mt6577-sysirq";
-- 
1.7.9.5



From tiffany.lin at mediatek.com  Thu Feb  4 03:34:55 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Thu, 4 Feb 2016 19:34:55 +0800
Subject: [PATCH v4 0/8] Add MT8173 Video Encoder Driver and VPU Driver
Message-ID: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>


==============
 Introduction
==============

The purpose of this series is to add the driver for video codec hw embedded in the Mediatek's MT8173 SoCs.
Mediatek Video Codec is able to handle video encoding of in a range of formats.

This patch series also include VPU driver. Mediatek Video Codec driver rely on VPU driver to load, communicate with VPU.

Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI.
MTK IOMMU[1] and MTK SMI[2] have not yet been merged, but we wanted to start discussion about the driver earlier so it could be merged sooner.

[1]https://patchwork.kernel.org/patch/8120921/
[2]https://patchwork.kernel.org/patch/8120941/


==================
 Device interface
==================

In principle the driver bases on v4l2 memory-to-memory framework:
it provides a single video node and each opened file handle gets its own private context with separate buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source buffers, i.e. raw video frames) and CAPTURE (for destination buffers, i.e. encoded video frames).

==============================
 VPU (Video Processor Unit)
==============================
The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
It is able to handle video decoding/encoding in a range of formats.
The driver provides with VPU firmware download, memory management and the communication interface between CPU and VPU.
For VPU initialization, it will create virtual memory for CPU access and physical address for VPU hw device access. When a decode/encode instance opens a device node, vpu driver will download vpu firmware to the device.
A decode/encode instant will decode/encode a frame using VPU interface to interrupt vpu to handle decoding/encoding jobs.

Please have a look at the code and comments will be very much appreciated.


Change in v4:
Vcodec Part
1. Remove MTK_ENCODE_PARAM_SKIP_FRAME support
2. Remove MTK_ENCODE_PARAM_FRAME_TYPE and change to use V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME[3]
3. Refine Encoder HW clock source
4. Refine debug log
5. Add watchdog support
6. With patch "media: v4l2-compat-ioctl32: fix missing length copy in put_v4l2_buffer32"[4], v4l2-compliance test passed[5] in v4.4-rc5 

VPU Part
1. These two patches were Acked-by: Rob Herring <robh at kernel.org> in v3
   [PATCH v3 1/8] dt-bindings: Add a binding for Mediatek Video Processor
   [PATCH v3 3/8] arm64: dts: mediatek: Add node for Mediatek Video Processor Unit
   Because we were wrong about how the hardware works, there is no connection between VPU and IOMMU HW
   We remove VPU attaching to IOMMU
2. Support VPU running on 4GB DRAM system
3. Support VPU watchdog reset
4. Refine for coding style 

[3]https://patchwork.linuxtv.org/patch/32670/
[4] https://patchwork.linuxtv.org/patch/32631/
[5]localhost ~ # /usr/bin/v4l2-compliance -d /dev/video1
Driver Info:
        Driver name   : mtk-vcodec-en
        Card type     : platform:mt817
        Bus info      : platform:mt817
        Driver version: 4.4.0
        Capabilities  : 0x84204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps   : 0x04204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format

Compliance test for device /dev/video1 (not using libv4l2):

Required ioctls:
        test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
        test second video open: OK
        test VIDIOC_QUERYCAP: OK
        test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
        test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
        test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
        test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
        test VIDIOC_ENUMAUDIO: OK (Not Supported)
        test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDIO: OK (Not Supported)
        Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
        test VIDIOC_G/S_MODULATOR: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_ENUMAUDOUT: OK (Not Supported)
        test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDOUT: OK (Not Supported)
        Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
        test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
        test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
        test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
        test VIDIOC_G/S_EDID: OK (Not Supported)

        Control ioctls:
                test VIDIOC_QUERYCTRL/MENU: OK
                test VIDIOC_G/S_CTRL: OK
                test VIDIOC_G/S/TRY_EXT_CTRLS: OK
                test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
                test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
                Standard Controls: 12 Private Controls: 0

        Format ioctls:
                test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
                test VIDIOC_G/S_PARM: OK (Not Supported)
                test VIDIOC_G_FBUF: OK (Not Supported)
                test VIDIOC_G_FMT: OK
                test VIDIOC_TRY_FMT: OK
                test VIDIOC_S_FMT: OK
                test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)

        Codec ioctls:
                test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
                test VIDIOC_G_ENC_INDEX: OK (Not Supported)
                test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

        Buffer ioctls:
                warn: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(475): VIDIOC_CREATE_BUFS not supported
                warn: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(475): VIDIOC_CREATE_BUFS not supported
                test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
                test VIDIOC_EXPBUF: OK

Total: 38, Succeeded: 38, Failed: 0, Warnings: 2


Change in v3:
1.Refine code to pass v4l2-compliance test, now it still has 2 issues 2.Refine code according to latest MTK IOMMU patches[1] 3.Remove MFC51 specific CIDs and add MTK specific CIDs for for keyframe and
  skip I-frame
4.Refine code according to review comments

Below is the v1.6 version v4l2-compliance report for the mt8173 encoder driver.
Now there are still 2 test fail in v1.6.
For VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF, we directly use v4l2_m2m_ioctl_* functions, but it still fail. It pass in kernel 3.18 but fail in kernel 4.4.
We will try v1.8 in next version.
VIDIOC_EXPBUF is becuase we support all three memory types VB2_DMABUF, VB2_MMAP and VB2_USERPTR. VIDIOC_EXPBUF only allowed when only VB2_MMAP supported.
localhost ~ # /usr/bin/v4l2-compliance -d /dev/video1 Driver Info:
        Driver name   : mtk-vcodec-en
        Card type     : platform:mt817
        Bus info      : platform:mt817
        Driver version: 4.4.0
        Capabilities  : 0x84204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps   : 0x04204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format

Compliance test for device /dev/video1 (not using libv4l2):

Required ioctls:
        test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
        test second video open: OK
        test VIDIOC_QUERYCAP: OK
        test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
        test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
        test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
        test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
        test VIDIOC_ENUMAUDIO: OK (Not Supported)
        test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDIO: OK (Not Supported)
        Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
        test VIDIOC_G/S_MODULATOR: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_ENUMAUDOUT: OK (Not Supported)
        test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDOUT: OK (Not Supported)
        Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
        test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
        test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
        test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
        test VIDIOC_G/S_EDID: OK (Not Supported)

        Control ioctls:
                test VIDIOC_QUERYCTRL/MENU: OK
                test VIDIOC_G/S_CTRL: OK
                test VIDIOC_G/S/TRY_EXT_CTRLS: OK
                test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
                test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
                Standard Controls: 11 Private Controls: 2

        Format ioctls:
                test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
                test VIDIOC_G/S_PARM: OK (Not Supported)
                test VIDIOC_G_FBUF: OK (Not Supported)
                test VIDIOC_G_FMT: OK
                test VIDIOC_TRY_FMT: OK
                test VIDIOC_S_FMT: OK
                test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)

        Codec ioctls:
                test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
                test VIDIOC_G_ENC_INDEX: OK (Not Supported)
                test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

        Buffer ioctls:
                fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(266): vp->length == 0
                fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(335): buf.check(Unqueued, i)
                fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(420): testQueryBuf(node, i, q.g_buffers())
                test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
                fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(500): q.has_expbuf(node)
                test VIDIOC_EXPBUF: FAIL
Total: 38, Succeeded: 36, Failed: 2, Warnings: 0


Change in v2:
Vcodec Part
1.Remove common and include directory in mtk-vcodec 2.Refine vb2ops_venc_start_streaming and vb2ops_venc_stop_streaming and state machine 3.Remove venc_if_init and venc_if_deinit 4.Refine debug message 5.Refine lab and vpu decription in mediatek-vcodec.txt

VPU Part
1. Modify VPU Kconfig
2. Move encoder header files to other patch sets 3. Remove marcos for extended virtual/iova address 4. Change register and variable names 5. Add a reference counter for VPU watchdog 6. Remove one busy waiting in function vpu_ipi_send 7. Operate VPU clock in VPU driver (not called by encoder drivers) 8. Refine memory mapping, firmware download and extended memory allocation/free functions 9. Release more allocated resources in driver remove function



Andrew-CT Chen (2):
  dt-bindings: Add a binding for Mediatek Video Processor
  [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver

Tiffany Lin (6):
  [media] VPU: mediatek: support Mediatek VPU
  arm64: dts: mediatek: Add node for Mediatek Video Processor Unit
  dt-bindings: Add a binding for Mediatek Video Encoder
  [media] vcodec: mediatek: Add Mediatek VP8 Video Encoder Driver
  [media] vcodec: mediatek: Add Mediatek H264 Video Encoder Driver
  arm64: dts: mediatek: Add Video Encoder for MT8173

 .../devicetree/bindings/media/mediatek-vcodec.txt  |   59 +
 .../devicetree/bindings/media/mediatek-vpu.txt     |   31 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi           |   62 +
 drivers/media/platform/Kconfig                     |   20 +
 drivers/media/platform/Makefile                    |    4 +
 drivers/media/platform/mtk-vcodec/Makefile         |   11 +
 .../media/platform/mtk-vcodec/h264_enc/Makefile    |    6 +
 .../platform/mtk-vcodec/h264_enc/venc_h264_if.c    |  540 ++++++++
 .../platform/mtk-vcodec/h264_enc/venc_h264_if.h    |  165 +++
 .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.c   |  309 +++++
 .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.h   |   30 +
 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |  388 ++++++
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1380 ++++++++++++++++++++
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h |   46 +
 .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c |  476 +++++++
 .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c  |  132 ++
 .../media/platform/mtk-vcodec/mtk_vcodec_intr.c    |  102 ++
 .../media/platform/mtk-vcodec/mtk_vcodec_intr.h    |   29 +
 drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h  |   26 +
 .../media/platform/mtk-vcodec/mtk_vcodec_util.c    |  106 ++
 .../media/platform/mtk-vcodec/mtk_vcodec_util.h    |   85 ++
 drivers/media/platform/mtk-vcodec/venc_drv_base.h  |   62 +
 drivers/media/platform/mtk-vcodec/venc_drv_if.c    |  106 ++
 drivers/media/platform/mtk-vcodec/venc_drv_if.h    |  175 +++
 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h   |  212 +++
 drivers/media/platform/mtk-vcodec/vp8_enc/Makefile |    6 +
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_if.c      |  422 ++++++
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_if.h      |  149 +++
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c     |  240 ++++
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h     |   28 +
 drivers/media/platform/mtk-vpu/Makefile            |    1 +
 drivers/media/platform/mtk-vpu/mtk_vpu.c           |  994 ++++++++++++++
 drivers/media/platform/mtk-vpu/mtk_vpu.h           |  167 +++
 include/uapi/linux/v4l2-controls.h                 |    4 +
 34 files changed, 6573 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt
 create mode 100644 drivers/media/platform/mtk-vcodec/Makefile
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/Makefile
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/Makefile
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.h
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h
 create mode 100644 drivers/media/platform/mtk-vpu/Makefile
 create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c
 create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h
 mode change 100644 => 100755 include/uapi/linux/v4l2-controls.h

-- 
1.7.9.5



From tiffany.lin at mediatek.com  Thu Feb  4 03:35:02 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Thu, 4 Feb 2016 19:35:02 +0800
Subject: [PATCH v4 7/8] [media] vcodec: mediatek: Add Mediatek H264 Video
 Encoder Driver
In-Reply-To: <1454585703-42428-7-git-send-email-tiffany.lin@mediatek.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-7-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <1454585703-42428-8-git-send-email-tiffany.lin@mediatek.com>

Add h264 encoder driver for MT8173

Signed-off-by: Daniel Hsiao <daniel.hsiao at mediatek.com>
Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
---
 drivers/media/platform/mtk-vcodec/Makefile         |    3 +-
 .../media/platform/mtk-vcodec/h264_enc/Makefile    |    6 +
 .../platform/mtk-vcodec/h264_enc/venc_h264_if.c    |  540 ++++++++++++++++++++
 .../platform/mtk-vcodec/h264_enc/venc_h264_if.h    |  165 ++++++
 .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.c   |  309 +++++++++++
 .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.h   |   30 ++
 drivers/media/platform/mtk-vcodec/venc_drv_if.c    |    3 +
 7 files changed, 1055 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/Makefile
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h

diff --git a/drivers/media/platform/mtk-vcodec/Makefile b/drivers/media/platform/mtk-vcodec/Makefile
index f4ef502..f47dfc7 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk_vcodec_intr.o \
 				       mtk_vcodec_enc_pm.o \
 				       venc_drv_if.o
 
-obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += vp8_enc/
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += vp8_enc/ h264_enc/
 
 ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/Makefile b/drivers/media/platform/mtk-vcodec/h264_enc/Makefile
new file mode 100644
index 0000000..765b45f
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/h264_enc/Makefile
@@ -0,0 +1,6 @@
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += venc_h264_if.o venc_h264_vpu.o
+
+ccflags-y += \
+    -I$(srctree)/drivers/media/platform/mtk-vcodec/ \
+    -I$(srctree)/drivers/media/platform/mtk-vcodec/h264_enc \
+    -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
new file mode 100644
index 0000000..c35fb26
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
@@ -0,0 +1,540 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
+ *         Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+
+#include "mtk_vcodec_drv.h"
+#include "mtk_vcodec_util.h"
+#include "mtk_vcodec_intr.h"
+#include "mtk_vcodec_enc.h"
+#include "mtk_vcodec_pm.h"
+#include "mtk_vpu.h"
+
+#include "venc_h264_if.h"
+#include "venc_h264_vpu.h"
+
+#define VENC_PIC_BITSTREAM_BYTE_CNT 0x0098
+
+enum venc_h264_irq_status {
+	H264_IRQ_STATUS_ENC_SPS_INT = (1 << 0),
+	H264_IRQ_STATUS_ENC_PPS_INT = (1 << 1),
+	H264_IRQ_STATUS_ENC_FRM_INT = (1 << 2),
+};
+
+static inline void h264_write_reg(struct venc_h264_inst *inst, u32 addr,
+				  u32 val)
+{
+	writel(val, inst->hw_base + addr);
+}
+
+static inline u32 h264_read_reg(struct venc_h264_inst *inst, u32 addr)
+{
+	return readl(inst->hw_base + addr);
+}
+
+static void h264_enc_free_work_buf(struct venc_h264_inst *inst)
+{
+	int i;
+
+	mtk_vcodec_debug_enter(inst);
+
+	/* Except the SKIP_FRAME buffers,
+	 * other buffers need to be freed by AP.
+	 */
+	for (i = 0; i < VENC_H264_VPU_WORK_BUF_MAX; i++) {
+		if (i != VENC_H264_VPU_WORK_BUF_SKIP_FRAME)
+			if (inst->work_bufs[i].va != NULL)
+				mtk_vcodec_mem_free(inst->ctx,
+						    &inst->work_bufs[i]);
+	}
+
+	if (inst->pps_buf.va != NULL)
+		mtk_vcodec_mem_free(inst->ctx, &inst->pps_buf);
+
+	mtk_vcodec_debug_leave(inst);
+}
+
+static int h264_enc_alloc_work_buf(struct venc_h264_inst *inst, void *param)
+{
+	int i;
+	int ret = 0;
+	struct venc_h264_vpu_buf *wb = inst->vpu_inst.drv->work_bufs;
+	struct venc_enc_prm *enc_param = param;
+
+	mtk_vcodec_debug_enter(inst);
+
+	for (i = 0; i < VENC_H264_VPU_WORK_BUF_MAX; i++) {
+		/*
+		 * This 'wb' structure is set by VPU side and shared to AP for
+		 * buffer allocation and IO virtual addr mapping. For most of
+		 * the buffers, AP will allocate the buffer according to 'size'
+		 * field and store the IO virtual addr in 'iova' field. There
+		 * are two exceptions:
+		 * (1) RC_CODE buffer, it's pre-allocated in the VPU side, and
+		 * save the VPU addr in the 'vpua' field. The AP will translate
+		 * the VPU addr to the corresponding IO virtual addr and store
+		 * in 'iova' field for reg setting in VPU side.
+		 * (2) SKIP_FRAME buffer, it's pre-allocated in the VPU side,
+		 * and save the VPU addr in the 'vpua' field. The AP will
+		 * translate the VPU addr to the corresponding AP side virtual
+		 * address and do some memcpy access to move to bitstream buffer
+		 * assigned by v4l2 layer.
+		 */
+		if (i == VENC_H264_VPU_WORK_BUF_RC_CODE) {
+			void *tmp_va;
+
+			tmp_va = vpu_mapping_dm_addr(inst->dev, wb[i].vpua);
+			inst->work_bufs[i].size = wb[i].size;
+			if (mtk_vcodec_mem_alloc(inst->ctx,
+						 &inst->work_bufs[i])) {
+				mtk_vcodec_err(inst,
+					       "cannot allocate buf %d", i);
+				ret = -ENOMEM;
+				goto err_alloc;
+			}
+			memcpy(inst->work_bufs[i].va, tmp_va, wb[i].size);
+			wb[i].iova = inst->work_bufs[i].dma_addr;
+		} else if (i == VENC_H264_VPU_WORK_BUF_SKIP_FRAME) {
+			inst->work_bufs[i].size = wb[i].size;
+			inst->work_bufs[i].va = vpu_mapping_dm_addr(
+				inst->dev, wb[i].vpua);
+			inst->work_bufs[i].dma_addr = 0;
+			wb[i].iova = inst->work_bufs[i].dma_addr;
+		} else if (i == VENC_H264_VPU_WORK_BUF_SRC_LUMA ||
+			   i == VENC_H264_VPU_WORK_BUF_SRC_CHROMA ||
+			   i == VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CB ||
+			   i == VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CR) {
+			inst->work_bufs[i].size = wb[i].size;
+			inst->work_bufs[i].dma_addr = 0;
+			inst->work_bufs[i].va = NULL;
+			wb[i].iova = inst->work_bufs[i].dma_addr;
+		} else {
+			inst->work_bufs[i].size = wb[i].size;
+			if (mtk_vcodec_mem_alloc(inst->ctx,
+						 &inst->work_bufs[i])) {
+				mtk_vcodec_err(inst,
+					       "cannot allocate buf %d", i);
+				ret = -ENOMEM;
+				goto err_alloc;
+			}
+			wb[i].iova = inst->work_bufs[i].dma_addr;
+		}
+		mtk_vcodec_debug(inst, "buf[%d] va=0x%p iova=0x%p size=0x%lx",
+				 i, inst->work_bufs[i].va,
+				 (void *)inst->work_bufs[i].dma_addr,
+				 inst->work_bufs[i].size);
+	}
+
+	if (enc_param->input_fourcc == VENC_YUV_FORMAT_NV12 ||
+	    enc_param->input_fourcc == VENC_YUV_FORMAT_NV21) {
+		enc_param->sizeimage[0] =
+			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_LUMA].size;
+		enc_param->sizeimage[1] =
+			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_CHROMA].size;
+		enc_param->sizeimage[2] = 0;
+	} else {
+		enc_param->sizeimage[0] =
+			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_LUMA].size;
+		enc_param->sizeimage[1] =
+			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CB].size;
+		enc_param->sizeimage[2] =
+			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CR].size;
+	}
+
+	/* the pps_buf is used by AP side only */
+	inst->pps_buf.size = 128;
+	if (mtk_vcodec_mem_alloc(inst->ctx,
+				 &inst->pps_buf)) {
+		mtk_vcodec_err(inst, "cannot allocate pps_buf");
+		ret = -ENOMEM;
+		goto err_alloc;
+	}
+	mtk_vcodec_debug_leave(inst);
+
+	return ret;
+
+err_alloc:
+	h264_enc_free_work_buf(inst);
+
+	return ret;
+}
+
+static unsigned int h264_enc_wait_venc_done(struct venc_h264_inst *inst)
+{
+	unsigned int irq_status = 0;
+	struct mtk_vcodec_ctx *ctx = (struct mtk_vcodec_ctx *)inst->ctx;
+
+	mtk_vcodec_wait_for_done_ctx(ctx, MTK_INST_IRQ_RECEIVED,
+				     WAIT_INTR_TIMEOUT, true);
+	irq_status = ctx->irq_status;
+	mtk_vcodec_debug(inst, "irq_status %x <-", irq_status);
+
+	return irq_status;
+}
+
+static int h264_encode_sps(struct venc_h264_inst *inst,
+			   struct mtk_vcodec_mem *bs_buf,
+			   unsigned int *bs_size)
+{
+	int ret = 0;
+	unsigned int irq_status;
+
+	mtk_vcodec_debug_enter(inst);
+
+	ret = h264_enc_vpu_encode(inst, H264_BS_MODE_SPS, NULL,
+				  bs_buf, bs_size);
+	if (ret)
+		return ret;
+
+	irq_status = h264_enc_wait_venc_done(inst);
+	if (irq_status != H264_IRQ_STATUS_ENC_SPS_INT) {
+		mtk_vcodec_err(inst, "expect irq status %d",
+			       H264_IRQ_STATUS_ENC_SPS_INT);
+		return -EINVAL;
+	}
+
+	*bs_size = h264_read_reg(inst, VENC_PIC_BITSTREAM_BYTE_CNT);
+	mtk_vcodec_debug(inst, "bs size %d <-", *bs_size);
+
+	return ret;
+}
+
+static int h264_encode_pps(struct venc_h264_inst *inst,
+			   struct mtk_vcodec_mem *bs_buf,
+			   unsigned int *bs_size)
+{
+	int ret = 0;
+	unsigned int irq_status;
+
+	mtk_vcodec_debug_enter(inst);
+
+	ret = h264_enc_vpu_encode(inst, H264_BS_MODE_PPS, NULL,
+				  bs_buf, bs_size);
+	if (ret)
+		return ret;
+
+	irq_status = h264_enc_wait_venc_done(inst);
+	if (irq_status != H264_IRQ_STATUS_ENC_PPS_INT) {
+		mtk_vcodec_err(inst, "expect irq status %d",
+			       H264_IRQ_STATUS_ENC_PPS_INT);
+		return -EINVAL;
+	}
+
+	*bs_size = h264_read_reg(inst, VENC_PIC_BITSTREAM_BYTE_CNT);
+	mtk_vcodec_debug(inst, "bs size %d <-", *bs_size);
+
+	return ret;
+}
+
+static int h264_encode_frame(struct venc_h264_inst *inst,
+			     struct venc_frm_buf *frm_buf,
+			     struct mtk_vcodec_mem *bs_buf,
+			     unsigned int *bs_size)
+{
+	int ret = 0;
+	unsigned int irq_status;
+
+	mtk_vcodec_debug_enter(inst);
+
+	ret = h264_enc_vpu_encode(inst, H264_BS_MODE_FRAME, frm_buf,
+				  bs_buf, bs_size);
+	if (ret)
+		return ret;
+
+	/*
+	 * skip frame case: The skip frame buffer is composed by vpu side only,
+	 * it does not trigger the hw, so skip the wait interrupt operation.
+	 */
+	if (!inst->vpu_inst.wait_int) {
+		++inst->frm_cnt;
+		return ret;
+	}
+
+	irq_status = h264_enc_wait_venc_done(inst);
+	if (irq_status != H264_IRQ_STATUS_ENC_FRM_INT) {
+		mtk_vcodec_err(inst, "irq_status=%d failed", irq_status);
+		return -EINVAL;
+	}
+
+	*bs_size = h264_read_reg(inst,
+				 VENC_PIC_BITSTREAM_BYTE_CNT);
+	++inst->frm_cnt;
+	mtk_vcodec_debug(inst, "frm %d bs size %d key_frm %d <-",
+			 inst->frm_cnt,
+			 *bs_size, inst->is_key_frm);
+
+	return ret;
+}
+
+static void h264_encode_filler(struct venc_h264_inst *inst, void *buf,
+			       int size)
+{
+	unsigned char *p = buf;
+
+	*p++ = 0x0;
+	*p++ = 0x0;
+	*p++ = 0x0;
+	*p++ = 0x1;
+	*p++ = 0xc;
+	size -= 5;
+	while (size) {
+		*p++ = 0xff;
+		size -= 1;
+	}
+}
+
+static int h264_enc_init(struct mtk_vcodec_ctx *ctx, unsigned long *handle)
+{
+	int ret = 0;
+	struct venc_h264_inst *inst;
+
+	inst = kzalloc(sizeof(*inst), GFP_KERNEL);
+	if (!inst)
+		return -ENOMEM;
+
+	inst->ctx = ctx;
+	inst->dev = mtk_vcodec_get_plat_dev(ctx);
+	inst->hw_base = mtk_vcodec_get_reg_addr(inst->ctx, VENC_SYS);
+
+	mtk_vcodec_debug_enter(inst);
+	ret = h264_enc_vpu_init(inst);
+	if (ret)
+		kfree(inst);
+	else
+		(*handle) = (unsigned long)inst;
+
+	mtk_vcodec_debug_leave(inst);
+
+	return ret;
+}
+
+static int h264_enc_encode(unsigned long handle,
+			   enum venc_start_opt opt,
+			   struct venc_frm_buf *frm_buf,
+			   struct mtk_vcodec_mem *bs_buf,
+			   struct venc_done_result *result)
+{
+	int ret = 0;
+	struct venc_h264_inst *inst = (struct venc_h264_inst *)handle;
+	struct mtk_vcodec_ctx *ctx = inst->ctx;
+
+	mtk_vcodec_debug(inst, "opt %d ->", opt);
+
+	enable_irq(ctx->dev->enc_irq);
+
+	switch (opt) {
+	case VENC_START_OPT_ENCODE_SEQUENCE_HEADER: {
+		unsigned int bs_size_sps;
+		unsigned int bs_size_pps;
+
+		memset(bs_buf->va, 0x38, 20);
+		ret = h264_encode_sps(inst, bs_buf, &bs_size_sps);
+		if (ret)
+			goto encode_err;
+
+		memset(inst->pps_buf.va, 0x49, 20);
+		ret = h264_encode_pps(inst, &inst->pps_buf, &bs_size_pps);
+		if (ret)
+			goto encode_err;
+
+		memcpy(bs_buf->va + bs_size_sps,
+		       inst->pps_buf.va,
+		       bs_size_pps);
+		result->bs_size = bs_size_sps + bs_size_pps;
+		result->is_key_frm = false;
+	}
+	break;
+
+	case VENC_START_OPT_ENCODE_FRAME:
+		if (inst->prepend_hdr) {
+			int hdr_sz;
+			int hdr_sz_ext;
+			int bs_alignment = 128;
+			int filler_sz = 0;
+			struct mtk_vcodec_mem tmp_bs_buf;
+			unsigned int bs_size_sps;
+			unsigned int bs_size_pps;
+			unsigned int bs_size_frm;
+
+			mtk_vcodec_debug(inst,
+					 "h264_encode_frame prepend SPS/PPS");
+			ret = h264_encode_sps(inst, bs_buf, &bs_size_sps);
+			if (ret)
+				goto encode_err;
+
+			ret = h264_encode_pps(inst, &inst->pps_buf,
+					      &bs_size_pps);
+			if (ret)
+				goto encode_err;
+
+			memcpy(bs_buf->va + bs_size_sps,
+			       inst->pps_buf.va,
+			       bs_size_pps);
+
+			hdr_sz = bs_size_sps + bs_size_pps;
+			hdr_sz_ext = (hdr_sz & (bs_alignment - 1));
+			if (hdr_sz_ext) {
+				filler_sz = bs_alignment - hdr_sz_ext;
+				if (hdr_sz_ext + 5 > bs_alignment)
+					filler_sz += bs_alignment;
+				h264_encode_filler(
+					inst, bs_buf->va + hdr_sz,
+					filler_sz);
+			}
+
+			tmp_bs_buf.va = bs_buf->va + hdr_sz +
+				filler_sz;
+			tmp_bs_buf.dma_addr = bs_buf->dma_addr + hdr_sz +
+				filler_sz;
+			tmp_bs_buf.size = bs_buf->size -
+				(hdr_sz + filler_sz);
+
+			ret = h264_encode_frame(inst, frm_buf, &tmp_bs_buf,
+						&bs_size_frm);
+			if (ret)
+				goto encode_err;
+
+			result->bs_size = hdr_sz + filler_sz + bs_size_frm;
+			mtk_vcodec_debug(inst,
+					 "hdr %d filler %d frame %d bs %d",
+					 hdr_sz, filler_sz, bs_size_frm,
+					 result->bs_size);
+
+			inst->prepend_hdr = 0;
+		} else {
+			ret = h264_encode_frame(inst, frm_buf, bs_buf,
+						&result->bs_size);
+			if (ret)
+				goto encode_err;
+		}
+		result->is_key_frm = inst->is_key_frm;
+		break;
+
+	default:
+		mtk_vcodec_err(inst, "venc_start_opt %d not supported", opt);
+		ret = -EINVAL;
+		break;
+	}
+
+encode_err:
+	if (ret)
+		result->msg = VENC_MESSAGE_ERR;
+	else
+		result->msg = VENC_MESSAGE_OK;
+
+	disable_irq(ctx->dev->enc_irq);
+	mtk_vcodec_debug(inst, "opt %d <-", opt);
+
+	return ret;
+}
+
+static int h264_enc_set_param(unsigned long handle,
+			      enum venc_set_param_type type, void *in)
+{
+	int ret = 0;
+	struct venc_h264_inst *inst = (struct venc_h264_inst *)handle;
+	struct venc_enc_prm *enc_prm;
+
+	mtk_vcodec_debug(inst, "->type=%d", type);
+
+	switch (type) {
+	case VENC_SET_PARAM_ENC:
+		enc_prm = in;
+		ret = h264_enc_vpu_set_param(inst, type, enc_prm);
+		if (ret)
+			break;
+		if (inst->work_buf_allocated == 1) {
+			h264_enc_free_work_buf(inst);
+			inst->work_buf_allocated = 0;
+		}
+		if (inst->work_buf_allocated == 0) {
+			ret = h264_enc_alloc_work_buf(inst, enc_prm);
+			if (ret)
+				break;
+			inst->work_buf_allocated = 1;
+		}
+		break;
+
+	case VENC_SET_PARAM_FORCE_INTRA:
+		ret = h264_enc_vpu_set_param(inst, type, 0);
+		break;
+
+	case VENC_SET_PARAM_ADJUST_BITRATE:
+		enc_prm = in;
+		ret = h264_enc_vpu_set_param(inst, type, &enc_prm->bitrate);
+		break;
+
+	case VENC_SET_PARAM_ADJUST_FRAMERATE:
+		enc_prm = in;
+		ret = h264_enc_vpu_set_param(inst, type, &enc_prm->frm_rate);
+		break;
+
+	case VENC_SET_PARAM_I_FRAME_INTERVAL:
+		ret = h264_enc_vpu_set_param(inst, type, in);
+		break;
+
+	case VENC_SET_PARAM_SKIP_FRAME:
+		ret = h264_enc_vpu_set_param(inst, type, 0);
+		break;
+
+	case VENC_SET_PARAM_PREPEND_HEADER:
+		inst->prepend_hdr = 1;
+		mtk_vcodec_debug(inst, "set prepend header mode");
+		break;
+
+	default:
+		mtk_vcodec_err(inst, "type %d not supported", type);
+		ret = -EINVAL;
+		break;
+	}
+
+	mtk_vcodec_debug_leave(inst);
+
+	return ret;
+}
+
+static int h264_enc_deinit(unsigned long handle)
+{
+	int ret = 0;
+	struct venc_h264_inst *inst = (struct venc_h264_inst *)handle;
+
+	mtk_vcodec_debug_enter(inst);
+
+	ret = h264_enc_vpu_deinit(inst);
+
+	if (inst->work_buf_allocated)
+		h264_enc_free_work_buf(inst);
+
+	mtk_vcodec_debug_leave(inst);
+	kfree(inst);
+
+	return ret;
+}
+
+static struct venc_common_if venc_h264_if = {
+	h264_enc_init,
+	h264_enc_encode,
+	h264_enc_set_param,
+	h264_enc_deinit,
+};
+
+struct venc_common_if *get_h264_enc_comm_if(void)
+{
+	return &venc_h264_if;
+}
diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
new file mode 100644
index 0000000..9ac317a
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
@@ -0,0 +1,165 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
+ *         Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#ifndef _VENC_H264_IF_H_
+#define _VENC_H264_IF_H_
+
+#include "venc_drv_base.h"
+
+/**
+ * enum venc_h264_vpu_work_buf - h264 encoder buffer index
+ */
+enum venc_h264_vpu_work_buf {
+	VENC_H264_VPU_WORK_BUF_RC_INFO,
+	VENC_H264_VPU_WORK_BUF_RC_CODE,
+	VENC_H264_VPU_WORK_BUF_REC_LUMA,
+	VENC_H264_VPU_WORK_BUF_REC_CHROMA,
+	VENC_H264_VPU_WORK_BUF_REF_LUMA,
+	VENC_H264_VPU_WORK_BUF_REF_CHROMA,
+	VENC_H264_VPU_WORK_BUF_MV_INFO_1,
+	VENC_H264_VPU_WORK_BUF_MV_INFO_2,
+	VENC_H264_VPU_WORK_BUF_SKIP_FRAME,
+	VENC_H264_VPU_WORK_BUF_SRC_LUMA,
+	VENC_H264_VPU_WORK_BUF_SRC_CHROMA,
+	VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CB,
+	VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CR,
+	VENC_H264_VPU_WORK_BUF_MAX,
+};
+
+/**
+ * enum venc_h264_bs_mode - for bs_mode argument in h264_enc_vpu_encode
+ */
+enum venc_h264_bs_mode {
+	H264_BS_MODE_SPS,
+	H264_BS_MODE_PPS,
+	H264_BS_MODE_FRAME,
+};
+
+/*
+ * struct venc_h264_vpu_config - Structure for h264 encoder configuration
+ * @input_fourcc: input fourcc
+ * @bitrate: target bitrate (in bps)
+ * @pic_w: picture width
+ * @pic_h: picture height
+ * @buf_w: buffer width
+ * @buf_h: buffer height
+ * @intra_period: intra frame period
+ * @framerate: frame rate
+ * @profile: as specified in standard
+ * @level: as specified in standard
+ * @wfd: WFD mode 1:on, 0:off
+ */
+struct venc_h264_vpu_config {
+	u32 input_fourcc;
+	u32 bitrate;
+	u32 pic_w;
+	u32 pic_h;
+	u32 buf_w;
+	u32 buf_h;
+	u32 intra_period;
+	u32 framerate;
+	u32 profile;
+	u32 level;
+	u32 wfd;
+};
+
+/*
+ * struct venc_h264_vpu_buf - Structure for buffer information
+ * @align: buffer alignment (in bytes)
+ * @iova: IO virtual address
+ * @vpua: VPU side memory addr which is used by RC_CODE
+ * @size: buffer size (in bytes)
+ */
+struct venc_h264_vpu_buf {
+	u32 align;
+	u32 iova;
+	u32 vpua;
+	u32 size;
+};
+
+/*
+ * struct venc_h264_vpu_drv - Structure for VPU driver control and info share
+ * This structure is allocated in VPU side and shared to AP side.
+ * @config: h264 encoder configuration
+ * @work_bufs: working buffer information in VPU side
+ * The work_bufs here is for storing the 'size' info shared to AP side.
+ * The similar item in struct venc_h264_inst is for memory allocation
+ * in AP side. The AP driver will copy the 'size' from here to the one in
+ * struct mtk_vcodec_mem, then invoke mtk_vcodec_mem_alloc to allocate
+ * the buffer. After that, bypass the 'dma_addr' to the 'iova' field here for
+ * register setting in VPU side.
+ */
+struct venc_h264_vpu_drv {
+	struct venc_h264_vpu_config config;
+	struct venc_h264_vpu_buf work_bufs[VENC_H264_VPU_WORK_BUF_MAX];
+};
+
+/*
+ * struct venc_h264_vpu_inst - h264 encoder VPU driver instance
+ * @wq_hd: wait queue used for vpu cmd trigger then wait vpu interrupt done
+ * @signaled: flag used for checking vpu interrupt done
+ * @failure: flag to show vpu cmd succeeds or not
+ * @state: enum venc_ipi_msg_enc_state
+ * @bs_size: bitstream size for skip frame case usage
+ * @wait_int: flag to wait interrupt done (0: for skip frame case, 1: normal
+ *	      case)
+ * @id: VPU instance id
+ * @drv: driver structure allocated by VPU side and shared to AP side for
+ *	 control and info share
+ */
+struct venc_h264_vpu_inst {
+	wait_queue_head_t wq_hd;
+	int signaled;
+	int failure;
+	int state;
+	int bs_size;
+	int wait_int;
+	unsigned int id;
+	struct venc_h264_vpu_drv *drv;
+};
+
+/*
+ * struct venc_h264_inst - h264 encoder AP driver instance
+ * @hw_base: h264 encoder hardware register base
+ * @work_bufs: working buffer
+ * @pps_buf: buffer to store the pps bitstream
+ * @work_buf_allocated: working buffer allocated flag
+ * @frm_cnt: encoded frame count
+ * @prepend_hdr: when the v4l2 layer send VENC_SET_PARAM_PREPEND_HEADER cmd
+ *  through h264_enc_set_param interface, it will set this flag and prepend the
+ *  sps/pps in h264_enc_encode function.
+ * @is_key_frm: key frame flag
+ * @vpu_inst: VPU instance to exchange information between AP and VPU
+ * @ctx: context for v4l2 layer integration
+ * @dev: device for v4l2 layer integration
+ */
+struct venc_h264_inst {
+	void __iomem *hw_base;
+	struct mtk_vcodec_mem work_bufs[VENC_H264_VPU_WORK_BUF_MAX];
+	struct mtk_vcodec_mem pps_buf;
+	bool work_buf_allocated;
+	unsigned int frm_cnt;
+	unsigned int prepend_hdr;
+	unsigned int is_key_frm;
+	struct venc_h264_vpu_inst vpu_inst;
+	void *ctx;
+	struct platform_device *dev;
+};
+
+struct venc_common_if *get_h264_enc_comm_if(void);
+
+#endif
diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
new file mode 100644
index 0000000..450be45
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
@@ -0,0 +1,309 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
+ *         Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#include "mtk_vpu.h"
+
+#include "venc_h264_if.h"
+#include "venc_h264_vpu.h"
+#include "venc_ipi_msg.h"
+
+static unsigned int h264_get_profile(unsigned int profile)
+{
+	/* (Baseline=66, Main=77, High=100) */
+	switch (profile) {
+	case V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE:
+		return 66;
+	case V4L2_MPEG_VIDEO_H264_PROFILE_MAIN:
+		return 77;
+	case V4L2_MPEG_VIDEO_H264_PROFILE_HIGH:
+		return 100;
+	default:
+		return 100;
+	}
+}
+
+static unsigned int h264_get_level(unsigned int level)
+{
+	/* (UpTo4.1(HighProfile)) */
+	switch (level) {
+	case V4L2_MPEG_VIDEO_H264_LEVEL_1_0:
+		return 10;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_1_1:
+		return 11;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_1_2:
+		return 12;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_1_3:
+		return 13;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_2_0:
+		return 20;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_2_1:
+		return 21;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_2_2:
+		return 22;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_3_0:
+		return 30;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_3_1:
+		return 31;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_3_2:
+		return 32;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_4_0:
+		return 40;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_4_1:
+		return 41;
+	default:
+		return 31;
+	}
+}
+
+static void handle_h264_enc_init_msg(struct venc_h264_inst *inst, void *data)
+{
+	struct venc_vpu_ipi_msg_init *msg = data;
+
+	inst->vpu_inst.id = msg->inst_id;
+	inst->vpu_inst.drv = (struct venc_h264_vpu_drv *)vpu_mapping_dm_addr(
+		inst->dev, msg->inst_id);
+}
+
+static void handle_h264_enc_encode_msg(struct venc_h264_inst *inst, void *data)
+{
+	struct venc_vpu_ipi_msg_enc *msg = data;
+
+	inst->vpu_inst.state = msg->state;
+	inst->vpu_inst.bs_size = msg->bs_size;
+	inst->is_key_frm = msg->key_frame;
+}
+
+static void h264_enc_vpu_ipi_handler(void *data, unsigned int len, void *priv)
+{
+	struct venc_vpu_ipi_msg_common *msg = data;
+	struct venc_h264_inst *inst = (struct venc_h264_inst *)msg->venc_inst;
+
+	mtk_vcodec_debug(inst, "msg_id %x inst %p status %d",
+			 msg->msg_id, inst, msg->status);
+
+	switch (msg->msg_id) {
+	case VPU_IPIMSG_H264_ENC_INIT_DONE:
+		handle_h264_enc_init_msg(inst, data);
+		break;
+	case VPU_IPIMSG_H264_ENC_SET_PARAM_DONE:
+		break;
+	case VPU_IPIMSG_H264_ENC_ENCODE_DONE:
+		handle_h264_enc_encode_msg(inst, data);
+		break;
+	case VPU_IPIMSG_H264_ENC_DEINIT_DONE:
+		break;
+	default:
+		mtk_vcodec_err(inst, "unknown msg id %x", msg->msg_id);
+		break;
+	}
+
+	inst->vpu_inst.signaled = 1;
+	inst->vpu_inst.failure = (msg->status != VENC_IPI_MSG_STATUS_OK);
+
+	mtk_vcodec_debug_leave(inst);
+}
+
+static int h264_enc_vpu_send_msg(struct venc_h264_inst *inst, void *msg,
+				 int len)
+{
+	int status;
+
+	mtk_vcodec_debug_enter(inst);
+	status = vpu_ipi_send(inst->dev, IPI_VENC_H264, msg, len);
+	if (status) {
+		mtk_vcodec_err(inst, "vpu_ipi_send msg %x len %d fail %d",
+			       *(unsigned int *)msg, len, status);
+		return -EINVAL;
+	}
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
+
+int h264_enc_vpu_init(struct venc_h264_inst *inst)
+{
+	int status;
+	struct venc_ap_ipi_msg_init out;
+
+	mtk_vcodec_debug_enter(inst);
+
+	init_waitqueue_head(&inst->vpu_inst.wq_hd);
+	inst->vpu_inst.signaled = 0;
+	inst->vpu_inst.failure = 0;
+
+	status = vpu_ipi_register(inst->dev, IPI_VENC_H264,
+				  h264_enc_vpu_ipi_handler,
+				  "h264_enc", NULL);
+	if (status) {
+		mtk_vcodec_err(inst, "vpu_ipi_register fail %d", status);
+		return -EINVAL;
+	}
+
+	out.msg_id = AP_IPIMSG_H264_ENC_INIT;
+	out.venc_inst = (unsigned long)inst;
+	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst, "AP_IPIMSG_H264_ENC_INIT failed");
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
+
+int h264_enc_vpu_set_param(struct venc_h264_inst *inst, unsigned int id,
+			   void *param)
+{
+	struct venc_ap_ipi_msg_set_param out;
+
+	mtk_vcodec_debug(inst, "id %d ->", id);
+
+	out.msg_id = AP_IPIMSG_H264_ENC_SET_PARAM;
+	out.inst_id = inst->vpu_inst.id;
+	out.param_id = id;
+	switch (id) {
+	case VENC_SET_PARAM_ENC: {
+		struct venc_enc_prm *enc_param = (struct venc_enc_prm *)param;
+
+		inst->vpu_inst.drv->config.input_fourcc =
+			enc_param->input_fourcc;
+		inst->vpu_inst.drv->config.bitrate = enc_param->bitrate;
+		inst->vpu_inst.drv->config.pic_w = enc_param->width;
+		inst->vpu_inst.drv->config.pic_h = enc_param->height;
+		inst->vpu_inst.drv->config.buf_w = enc_param->buf_width;
+		inst->vpu_inst.drv->config.buf_h = enc_param->buf_height;
+		inst->vpu_inst.drv->config.intra_period =
+			enc_param->intra_period;
+		inst->vpu_inst.drv->config.framerate = enc_param->frm_rate;
+		inst->vpu_inst.drv->config.profile =
+			h264_get_profile(enc_param->h264_profile);
+		inst->vpu_inst.drv->config.level =
+			h264_get_level(enc_param->h264_level);
+		inst->vpu_inst.drv->config.wfd = 0;
+		out.data_item = 0;
+		break;
+	}
+	case VENC_SET_PARAM_FORCE_INTRA:
+		out.data_item = 0;
+		break;
+	case VENC_SET_PARAM_ADJUST_BITRATE:
+		out.data_item = 1;
+		out.data[0] = *(unsigned int *)param;
+		break;
+	case VENC_SET_PARAM_ADJUST_FRAMERATE:
+		out.data_item = 1;
+		out.data[0] = *(unsigned int *)param;
+		break;
+	case VENC_SET_PARAM_I_FRAME_INTERVAL:
+		out.data_item = 1;
+		out.data[0] = *(unsigned int *)param;
+		break;
+	case VENC_SET_PARAM_SKIP_FRAME:
+		out.data_item = 0;
+		break;
+	}
+	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst,
+			       "AP_IPIMSG_H264_ENC_SET_PARAM %d fail", id);
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug(inst, "id %d <-", id);
+
+	return 0;
+}
+
+int h264_enc_vpu_encode(struct venc_h264_inst *inst, unsigned int bs_mode,
+			struct venc_frm_buf *frm_buf,
+			struct mtk_vcodec_mem *bs_buf,
+			unsigned int *bs_size)
+{
+	struct venc_ap_ipi_msg_enc out;
+
+	mtk_vcodec_debug(inst, "bs_mode %d ->", bs_mode);
+
+	out.msg_id = AP_IPIMSG_H264_ENC_ENCODE;
+	out.inst_id = inst->vpu_inst.id;
+	out.bs_mode = bs_mode;
+	if (frm_buf) {
+		if ((frm_buf->fb_addr.dma_addr % 16 == 0) &&
+		    (frm_buf->fb_addr1.dma_addr % 16 == 0) &&
+		    (frm_buf->fb_addr2.dma_addr % 16 == 0)) {
+			out.input_addr[0] = frm_buf->fb_addr.dma_addr;
+			out.input_addr[1] = frm_buf->fb_addr1.dma_addr;
+			out.input_addr[2] = frm_buf->fb_addr2.dma_addr;
+		} else {
+			mtk_vcodec_err(inst, "dma_addr not align to 16");
+			return -EINVAL;
+		}
+	} else {
+		out.input_addr[0] = 0;
+		out.input_addr[1] = 0;
+		out.input_addr[2] = 0;
+	}
+	if (bs_buf) {
+		out.bs_addr = bs_buf->dma_addr;
+		out.bs_size = bs_buf->size;
+	} else {
+		out.bs_addr = 0;
+		out.bs_size = 0;
+	}
+	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst, "AP_IPIMSG_H264_ENC_ENCODE %d fail",
+			       bs_mode);
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug(inst, "state %d size %d key_frm %d",
+			 inst->vpu_inst.state, inst->vpu_inst.bs_size,
+			 inst->is_key_frm);
+
+	inst->vpu_inst.wait_int = 1;
+	if (inst->vpu_inst.state == VEN_IPI_MSG_ENC_STATE_SKIP) {
+		*bs_size = inst->vpu_inst.bs_size;
+		memcpy(bs_buf->va,
+		       inst->work_bufs[VENC_H264_VPU_WORK_BUF_SKIP_FRAME].va,
+		       *bs_size);
+		inst->vpu_inst.wait_int = 0;
+	}
+
+	mtk_vcodec_debug(inst, "bs_mode %d <-", bs_mode);
+
+	return 0;
+}
+
+int h264_enc_vpu_deinit(struct venc_h264_inst *inst)
+{
+	struct venc_ap_ipi_msg_deinit out;
+
+	mtk_vcodec_debug_enter(inst);
+
+	out.msg_id = AP_IPIMSG_H264_ENC_DEINIT;
+	out.inst_id = inst->vpu_inst.id;
+	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst, "AP_IPIMSG_H264_ENC_DEINIT fail");
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
new file mode 100644
index 0000000..deccc6f
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
+ *         Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#ifndef _VENC_H264_VPU_H_
+#define _VENC_H264_VPU_H_
+
+int h264_enc_vpu_init(struct venc_h264_inst *inst);
+int h264_enc_vpu_set_param(struct venc_h264_inst *inst, unsigned int id,
+			   void *param);
+int h264_enc_vpu_encode(struct venc_h264_inst *inst, unsigned int bs_mode,
+			struct venc_frm_buf *frm_buf,
+			struct mtk_vcodec_mem *bs_buf,
+			unsigned int *bs_size);
+int h264_enc_vpu_deinit(struct venc_h264_inst *inst);
+
+#endif
diff --git a/drivers/media/platform/mtk-vcodec/venc_drv_if.c b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
index d293f2c..28ef4a7 100644
--- a/drivers/media/platform/mtk-vcodec/venc_drv_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
@@ -25,6 +25,7 @@
 
 #include "venc_drv_base.h"
 #include "vp8_enc/venc_vp8_if.h"
+#include "h264_enc/venc_h264_if.h"
 
 int venc_if_create(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
 {
@@ -38,6 +39,8 @@ int venc_if_create(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
                 ctx->enc_if = get_vp8_enc_comm_if();
                 break;
 	case V4L2_PIX_FMT_H264:
+	        ctx->enc_if = get_h264_enc_comm_if();
+	        break;
 	default:
 		return -EINVAL;
 	}
-- 
1.7.9.5



From tiffany.lin at mediatek.com  Thu Feb  4 03:35:01 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Thu, 4 Feb 2016 19:35:01 +0800
Subject: [PATCH v4 6/8] [media] vcodec: mediatek: Add Mediatek VP8 Video
 Encoder Driver
In-Reply-To: <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <1454585703-42428-7-git-send-email-tiffany.lin@mediatek.com>

Add vp8 encoder driver for MT8173

Signed-off-by: Daniel Hsiao <daniel.hsiao at mediatek.com>
Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
---
 drivers/media/platform/mtk-vcodec/Makefile         |    2 +
 drivers/media/platform/mtk-vcodec/venc_drv_if.c    |    3 +
 drivers/media/platform/mtk-vcodec/vp8_enc/Makefile |    6 +
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_if.c      |  422 ++++++++++++++++++++
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_if.h      |  149 +++++++
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c     |  240 +++++++++++
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h     |   28 ++
 7 files changed, 850 insertions(+)
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/Makefile
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.h
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h

diff --git a/drivers/media/platform/mtk-vcodec/Makefile b/drivers/media/platform/mtk-vcodec/Makefile
index ce38689..f4ef502 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -5,4 +5,6 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk_vcodec_intr.o \
 				       mtk_vcodec_enc_pm.o \
 				       venc_drv_if.o
 
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += vp8_enc/
+
 ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/venc_drv_if.c b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
index daa8e93..d293f2c 100644
--- a/drivers/media/platform/mtk-vcodec/venc_drv_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
@@ -24,6 +24,7 @@
 #include "mtk_vpu.h"
 
 #include "venc_drv_base.h"
+#include "vp8_enc/venc_vp8_if.h"
 
 int venc_if_create(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
 {
@@ -34,6 +35,8 @@ int venc_if_create(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
 
 	switch (fourcc) {
 	case V4L2_PIX_FMT_VP8:
+                ctx->enc_if = get_vp8_enc_comm_if();
+                break;
 	case V4L2_PIX_FMT_H264:
 	default:
 		return -EINVAL;
diff --git a/drivers/media/platform/mtk-vcodec/vp8_enc/Makefile b/drivers/media/platform/mtk-vcodec/vp8_enc/Makefile
new file mode 100644
index 0000000..0f515c7
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vp8_enc/Makefile
@@ -0,0 +1,6 @@
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += venc_vp8_if.o venc_vp8_vpu.o
+
+ccflags-y += \
+    -I$(srctree)/drivers/media/platform/mtk-vcodec/ \
+    -I$(srctree)/drivers/media/platform/mtk-vcodec/vp8_enc \
+    -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c
new file mode 100644
index 0000000..4253317
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c
@@ -0,0 +1,422 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+
+#include "mtk_vcodec_drv.h"
+#include "mtk_vcodec_util.h"
+#include "mtk_vcodec_intr.h"
+#include "mtk_vcodec_enc.h"
+#include "mtk_vcodec_pm.h"
+#include "mtk_vpu.h"
+
+#include "venc_vp8_if.h"
+#include "venc_vp8_vpu.h"
+
+#define VENC_PIC_BITSTREAM_BYTE_CNT 0x0098
+#define VENC_PIC_BITSTREAM_BYTE_CNT1 0x00e8
+#define VENC_IRQ_STATUS_ENC_FRM_INT 0x04
+
+#define MAX_AC_TAG_SZ 10
+
+static inline void vp8_enc_write_reg(struct venc_vp8_inst *inst, u32 addr,
+				     u32 val)
+{
+	writel(val, inst->hw_base + addr);
+}
+
+static inline u32 vp8_enc_read_reg(struct venc_vp8_inst *inst, u32 addr)
+{
+	return readl(inst->hw_base + addr);
+}
+
+static void vp8_enc_free_work_buf(struct venc_vp8_inst *inst)
+{
+	int i;
+
+	mtk_vcodec_debug_enter(inst);
+
+	/* Buffers need to be freed by AP. */
+	for (i = 0; i < VENC_VP8_VPU_WORK_BUF_MAX; i++)
+		if (inst->work_bufs[i].va != NULL)
+			mtk_vcodec_mem_free(inst->ctx,
+					    &inst->work_bufs[i]);
+
+	mtk_vcodec_debug_leave(inst);
+}
+
+static int vp8_enc_alloc_work_buf(struct venc_vp8_inst *inst, void *param)
+{
+	int i;
+	int ret = 0;
+	struct venc_vp8_vpu_buf *wb = inst->vpu_inst.drv->work_bufs;
+	struct venc_enc_prm *enc_param = param;
+
+	mtk_vcodec_debug_enter(inst);
+
+	for (i = 0; i < VENC_VP8_VPU_WORK_BUF_MAX; i++) {
+		/*
+		 * Only temporal scalability mode will use RC_CODE2 & RC_CODE3
+		 * Each three temporal layer has its own rate control code.
+		 */
+		if ((i == VENC_VP8_VPU_WORK_BUF_RC_CODE2 ||
+		     i == VENC_VP8_VPU_WORK_BUF_RC_CODE3) && !inst->ts_mode)
+			continue;
+
+		/*
+		 * This 'wb' structure is set by VPU side and shared to AP for
+		 * buffer allocation and IO virtual addr mapping. For most of
+		 * the buffers, AP will allocate the buffer according to 'size'
+		 * field and store the IO virtual addr in 'iova' field. For the
+		 * RC_CODEx buffers, they are pre-allocated in the VPU side
+		 * because they are inside VPU SRAM, and save the VPU addr in
+		 * the 'vpua' field. The AP will translate the VPU addr to the
+		 * corresponding IO virtual addr and store in 'iova' field.
+		 */
+		if (i < VENC_VP8_VPU_WORK_BUF_RC_CODE) {
+			inst->work_bufs[i].size = wb[i].size;
+			ret = mtk_vcodec_mem_alloc(inst->ctx,
+						   &inst->work_bufs[i]);
+			if (ret) {
+				mtk_vcodec_err(inst,
+					       "cannot alloc work_bufs[%d]", i);
+				goto err_alloc;
+			}
+			wb[i].iova = inst->work_bufs[i].dma_addr;
+		} else if (i == VENC_VP8_VPU_WORK_BUF_SRC_LUMA ||
+			   i == VENC_VP8_VPU_WORK_BUF_SRC_CHROMA ||
+			   i == VENC_VP8_VPU_WORK_BUF_SRC_CHROMA_CB ||
+			   i == VENC_VP8_VPU_WORK_BUF_SRC_CHROMA_CR) {
+			inst->work_bufs[i].size = wb[i].size;
+			inst->work_bufs[i].dma_addr = 0;
+			inst->work_bufs[i].va = NULL;
+			wb[i].iova = inst->work_bufs[i].dma_addr;
+		} else {
+			void *tmp_va;
+
+			tmp_va = vpu_mapping_dm_addr(inst->dev, wb[i].vpua);
+			inst->work_bufs[i].size = wb[i].size;
+			ret = mtk_vcodec_mem_alloc(inst->ctx,
+						   &inst->work_bufs[i]);
+			if (ret) {
+				mtk_vcodec_err(inst,
+					       "cannot alloc work_bufs[%d]", i);
+				goto err_alloc;
+			}
+			memcpy(inst->work_bufs[i].va, tmp_va, wb[i].size);
+			wb[i].iova = inst->work_bufs[i].dma_addr;
+		}
+		mtk_vcodec_debug(inst,
+				 "work_bufs[%d] va=0x%p,iova=0x%p,size=0x%lx",
+				 i, inst->work_bufs[i].va,
+				 (void *)inst->work_bufs[i].dma_addr,
+				 inst->work_bufs[i].size);
+	}
+
+	if (enc_param->input_fourcc == VENC_YUV_FORMAT_NV12 ||
+	    enc_param->input_fourcc == VENC_YUV_FORMAT_NV21) {
+		enc_param->sizeimage[0] =
+			inst->work_bufs[VENC_VP8_VPU_WORK_BUF_SRC_LUMA].size;
+		enc_param->sizeimage[1] =
+			inst->work_bufs[VENC_VP8_VPU_WORK_BUF_SRC_CHROMA].size;
+		enc_param->sizeimage[2] = 0;
+	} else {
+		enc_param->sizeimage[0] =
+			inst->work_bufs[VENC_VP8_VPU_WORK_BUF_SRC_LUMA].size;
+		enc_param->sizeimage[1] =
+			inst->work_bufs[VENC_VP8_VPU_WORK_BUF_SRC_CHROMA_CB].size;
+		enc_param->sizeimage[2] =
+			inst->work_bufs[VENC_VP8_VPU_WORK_BUF_SRC_CHROMA_CR].size;
+	}
+	mtk_vcodec_debug_leave(inst);
+
+	return ret;
+
+err_alloc:
+	vp8_enc_free_work_buf(inst);
+
+	return ret;
+}
+
+static unsigned int vp8_enc_wait_venc_done(struct venc_vp8_inst *inst)
+{
+	unsigned int irq_status = 0;
+	struct mtk_vcodec_ctx *ctx = (struct mtk_vcodec_ctx *)inst->ctx;
+
+	mtk_vcodec_wait_for_done_ctx(ctx, MTK_INST_IRQ_RECEIVED,
+				     WAIT_INTR_TIMEOUT, true);
+	irq_status = ctx->irq_status;
+	mtk_vcodec_debug(inst, "isr return %x", irq_status);
+
+	return irq_status;
+}
+
+/*
+ * Compose ac_tag, bitstream header and bitstream payload into
+ * one bitstream buffer.
+ */
+static int vp8_enc_compose_one_frame(struct venc_vp8_inst *inst,
+				     struct mtk_vcodec_mem *bs_buf,
+				     unsigned int *bs_size)
+{
+	unsigned int is_key;
+	u32 bs_size_frm;
+	u32 bs_hdr_len;
+	unsigned int ac_tag_sz;
+	u8 ac_tag[MAX_AC_TAG_SZ];
+
+	bs_size_frm = vp8_enc_read_reg(inst,
+				       VENC_PIC_BITSTREAM_BYTE_CNT);
+	bs_hdr_len = vp8_enc_read_reg(inst,
+				      VENC_PIC_BITSTREAM_BYTE_CNT1);
+
+	/* if a frame is key frame, is_key is 0 */
+	is_key = !inst->is_key_frm;
+	*(u32 *)ac_tag = __cpu_to_le32((bs_hdr_len << 5) | 0x10 | is_key);
+	/* key frame */
+	if (is_key == 0) {
+		ac_tag[3] = 0x9d;
+		ac_tag[4] = 0x01;
+		ac_tag[5] = 0x2a;
+		ac_tag[6] = inst->vpu_inst.drv->config.pic_w;
+		ac_tag[7] = inst->vpu_inst.drv->config.pic_w >> 8;
+		ac_tag[8] = inst->vpu_inst.drv->config.pic_h;
+		ac_tag[9] = inst->vpu_inst.drv->config.pic_h >> 8;
+	}
+
+	if (is_key == 0)
+		ac_tag_sz = MAX_AC_TAG_SZ;
+	else
+		ac_tag_sz = 3;
+
+	if (bs_buf->size <= bs_hdr_len + bs_size_frm + ac_tag_sz) {
+		mtk_vcodec_err(inst, "bitstream buf size is too small(%ld)",
+			       bs_buf->size);
+		return -EINVAL;
+	}
+
+	/*
+	* (1) The vp8 bitstream header and body are generated by the HW vp8
+	* encoder separately at the same time. We cannot know the bitstream
+	* header length in advance.
+	* (2) From the vp8 spec, there is no stuffing byte allowed between the
+	* ac tag, bitstream header and bitstream body.
+	*/
+	memmove(bs_buf->va + bs_hdr_len + ac_tag_sz,
+		bs_buf->va, bs_size_frm);
+	memcpy(bs_buf->va + ac_tag_sz,
+	       inst->work_bufs[VENC_VP8_VPU_WORK_BUF_BS_HD].va,
+	       bs_hdr_len);
+	memcpy(bs_buf->va, ac_tag, ac_tag_sz);
+	*bs_size = bs_size_frm + bs_hdr_len + ac_tag_sz;
+
+	return 0;
+}
+
+static int vp8_enc_encode_frame(struct venc_vp8_inst *inst,
+				struct venc_frm_buf *frm_buf,
+				struct mtk_vcodec_mem *bs_buf,
+				unsigned int *bs_size)
+{
+	int ret = 0;
+	unsigned int irq_status;
+
+	mtk_vcodec_debug(inst, "->frm_cnt=%d", inst->frm_cnt);
+
+	ret = vp8_enc_vpu_encode(inst, frm_buf, bs_buf);
+	if (ret)
+		return ret;
+
+	irq_status = vp8_enc_wait_venc_done(inst);
+	if (irq_status != VENC_IRQ_STATUS_ENC_FRM_INT) {
+		mtk_vcodec_err(inst, "irq_status=%d failed", irq_status);
+		return -EINVAL;
+	}
+
+	if (vp8_enc_compose_one_frame(inst, bs_buf, bs_size)) {
+		mtk_vcodec_err(inst, "vp8_enc_compose_one_frame failed");
+		return -EINVAL;
+	}
+
+	inst->frm_cnt++;
+	mtk_vcodec_debug(inst, "<-size=%d key_frm=%d", *bs_size,
+			 inst->is_key_frm);
+
+	return ret;
+}
+
+static int vp8_enc_init(struct mtk_vcodec_ctx *ctx, unsigned long *handle)
+{
+	int ret = 0;
+	struct venc_vp8_inst *inst;
+
+	inst = kzalloc(sizeof(*inst), GFP_KERNEL);
+	if (!inst)
+		return -ENOMEM;
+
+	inst->ctx = ctx;
+	inst->dev = mtk_vcodec_get_plat_dev(ctx);
+	inst->hw_base = mtk_vcodec_get_reg_addr(inst->ctx, VENC_LT_SYS);
+
+	mtk_vcodec_debug_enter(inst);
+	ret = vp8_enc_vpu_init(inst);
+	if (ret)
+		kfree(inst);
+	else
+		(*handle) = (unsigned long)inst;
+
+	mtk_vcodec_debug_leave(inst);
+
+	return ret;
+}
+
+static int vp8_enc_encode(unsigned long handle,
+			  enum venc_start_opt opt,
+			  struct venc_frm_buf *frm_buf,
+			  struct mtk_vcodec_mem *bs_buf,
+			  struct venc_done_result *result)
+{
+	int ret = 0;
+	struct venc_vp8_inst *inst = (struct venc_vp8_inst *)handle;
+	struct mtk_vcodec_ctx *ctx = inst->ctx;
+
+	mtk_vcodec_debug_enter(inst);
+
+	enable_irq(ctx->dev->enc_lt_irq);
+
+	switch (opt) {
+	case VENC_START_OPT_ENCODE_FRAME:
+		ret = vp8_enc_encode_frame(inst, frm_buf, bs_buf,
+					   &result->bs_size);
+		if (ret)
+			goto encode_err;
+		result->is_key_frm = inst->is_key_frm;
+		break;
+
+	default:
+		mtk_vcodec_err(inst, "opt not support:%d", opt);
+		ret = -EINVAL;
+		break;
+	}
+
+encode_err:
+	if (ret)
+		result->msg = VENC_MESSAGE_ERR;
+	else
+		result->msg = VENC_MESSAGE_OK;
+
+	disable_irq(ctx->dev->enc_lt_irq);
+	mtk_vcodec_debug_leave(inst);
+
+	return ret;
+}
+
+static int vp8_enc_set_param(unsigned long handle,
+			     enum venc_set_param_type type, void *in)
+{
+	int ret = 0;
+	struct venc_vp8_inst *inst = (struct venc_vp8_inst *)handle;
+	struct venc_enc_prm *enc_prm;
+
+	mtk_vcodec_debug(inst, "->type=%d", type);
+
+	switch (type) {
+	case VENC_SET_PARAM_ENC:
+		enc_prm = in;
+		ret = vp8_enc_vpu_set_param(inst, type, enc_prm);
+		if (ret)
+			break;
+		if (inst->work_buf_allocated == 1) {
+			vp8_enc_free_work_buf(inst);
+			inst->work_buf_allocated = 0;
+		}
+		if (inst->work_buf_allocated == 0) {
+			ret = vp8_enc_alloc_work_buf(inst, enc_prm);
+			if (ret)
+				break;
+			inst->work_buf_allocated = 1;
+		}
+		break;
+
+	case VENC_SET_PARAM_FORCE_INTRA:
+		ret = vp8_enc_vpu_set_param(inst, type, 0);
+		break;
+
+	case VENC_SET_PARAM_ADJUST_BITRATE:
+		enc_prm = in;
+		ret = vp8_enc_vpu_set_param(inst, type, &enc_prm->bitrate);
+		break;
+
+	case VENC_SET_PARAM_ADJUST_FRAMERATE:
+		enc_prm = in;
+		ret = vp8_enc_vpu_set_param(inst, type, &enc_prm->frm_rate);
+		break;
+
+	case VENC_SET_PARAM_I_FRAME_INTERVAL:
+		ret = vp8_enc_vpu_set_param(inst, type, in);
+		break;
+
+	/*
+	 * VENC_SET_PARAM_TS_MODE must be called before
+	 * VENC_SET_PARAM_ENC
+	 */
+	case VENC_SET_PARAM_TS_MODE:
+		inst->ts_mode = 1;
+		mtk_vcodec_debug(inst, "set ts_mode");
+		break;
+
+	default:
+		mtk_vcodec_err(inst, "type not support:%d", type);
+		ret = -EINVAL;
+		break;
+	}
+
+	mtk_vcodec_debug_leave(inst);
+
+	return ret;
+}
+
+static int vp8_enc_deinit(unsigned long handle)
+{
+	int ret = 0;
+	struct venc_vp8_inst *inst = (struct venc_vp8_inst *)handle;
+
+	mtk_vcodec_debug_enter(inst);
+
+	ret = vp8_enc_vpu_deinit(inst);
+
+	if (inst->work_buf_allocated)
+		vp8_enc_free_work_buf(inst);
+
+	mtk_vcodec_debug_leave(inst);
+	kfree(inst);
+
+	return ret;
+}
+
+static struct venc_common_if venc_vp8_if = {
+	vp8_enc_init,
+	vp8_enc_encode,
+	vp8_enc_set_param,
+	vp8_enc_deinit,
+};
+
+struct venc_common_if *get_vp8_enc_comm_if(void)
+{
+	return &venc_vp8_if;
+}
diff --git a/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.h b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.h
new file mode 100644
index 0000000..b32220e
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.h
@@ -0,0 +1,149 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#ifndef _VENC_VP8_IF_H_
+#define _VENC_VP8_IF_H_
+
+#include "venc_drv_base.h"
+
+/**
+ * enum venc_vp8_vpu_work_buf - vp8 encoder buffer index
+ */
+enum venc_vp8_vpu_work_buf {
+	VENC_VP8_VPU_WORK_BUF_LUMA,
+	VENC_VP8_VPU_WORK_BUF_LUMA2,
+	VENC_VP8_VPU_WORK_BUF_LUMA3,
+	VENC_VP8_VPU_WORK_BUF_CHROMA,
+	VENC_VP8_VPU_WORK_BUF_CHROMA2,
+	VENC_VP8_VPU_WORK_BUF_CHROMA3,
+	VENC_VP8_VPU_WORK_BUF_MV_INFO,
+	VENC_VP8_VPU_WORK_BUF_BS_HD,
+	VENC_VP8_VPU_WORK_BUF_PROB_BUF,
+	VENC_VP8_VPU_WORK_BUF_RC_INFO,
+	VENC_VP8_VPU_WORK_BUF_RC_CODE,
+	VENC_VP8_VPU_WORK_BUF_RC_CODE2,
+	VENC_VP8_VPU_WORK_BUF_RC_CODE3,
+	VENC_VP8_VPU_WORK_BUF_SRC_LUMA,
+	VENC_VP8_VPU_WORK_BUF_SRC_CHROMA,
+	VENC_VP8_VPU_WORK_BUF_SRC_CHROMA_CB,
+	VENC_VP8_VPU_WORK_BUF_SRC_CHROMA_CR,
+	VENC_VP8_VPU_WORK_BUF_MAX,
+};
+
+/*
+ * struct venc_vp8_vpu_config - Structure for vp8 encoder configuration
+ * @input_fourcc: input fourcc
+ * @bitrate: target bitrate (in bps)
+ * @pic_w: picture width
+ * @pic_h: picture height
+ * @buf_w: buffer width (with 16 alignment)
+ * @buf_h: buffer height (with 16 alignment)
+ * @intra_period: intra frame period
+ * @framerate: frame rate
+ * @ts_mode: temporal scalability mode (0: disable, 1: enable)
+ *	     support three temporal layers - 0: 7.5fps 1: 7.5fps 2: 15fps.
+ */
+struct venc_vp8_vpu_config {
+	u32 input_fourcc;
+	u32 bitrate;
+	u32 pic_w;
+	u32 pic_h;
+	u32 buf_w;
+	u32 buf_h;
+	u32 intra_period;
+	u32 framerate;
+	u32 ts_mode;
+};
+
+/*
+ * struct venc_vp8_vpu_buf -Structure for buffer information
+ * @align: buffer alignment (in bytes)
+ * @iova: IO virtual address
+ * @vpua: VPU side memory addr which is used by RC_CODE
+ * @size: buffer size (in bytes)
+ */
+struct venc_vp8_vpu_buf {
+	u32 align;
+	u32 iova;
+	u32 vpua;
+	u32 size;
+};
+
+/*
+ * struct venc_vp8_vpu_drv - Structure for VPU driver control and info share
+ * This structure is allocated in VPU side and shared to AP side.
+ * @config: vp8 encoder configuration
+ * @work_bufs: working buffer information in VPU side
+ * The work_bufs here is for storing the 'size' info shared to AP side.
+ * The similar item in struct venc_vp8_inst is for memory allocation
+ * in AP side. The AP driver will copy the 'size' from here to the one in
+ * struct mtk_vcodec_mem, then invoke mtk_vcodec_mem_alloc to allocate
+ * the buffer. After that, bypass the 'dma_addr' to the 'iova' field here for
+ * register setting in VPU side.
+ */
+struct venc_vp8_vpu_drv {
+	struct venc_vp8_vpu_config config;
+	struct venc_vp8_vpu_buf work_bufs[VENC_VP8_VPU_WORK_BUF_MAX];
+};
+
+/*
+ * struct venc_vp8_vpu_inst - vp8 encoder VPU driver instance
+ * @wq_hd: wait queue used for vpu cmd trigger then wait vpu interrupt done
+ * @signaled: flag used for checking vpu interrupt done
+ * @failure: flag to show vpu cmd succeeds or not
+ * @state: enum venc_ipi_msg_enc_state
+ * @id: VPU instance id
+ * @drv: driver structure allocated by VPU side and shared to AP side for
+ *	 control and info share
+ */
+struct venc_vp8_vpu_inst {
+	wait_queue_head_t wq_hd;
+	int signaled;
+	int failure;
+	int state;
+	unsigned int id;
+	struct venc_vp8_vpu_drv *drv;
+};
+
+/*
+ * struct venc_vp8_inst - vp8 encoder AP driver instance
+ * @hw_base: vp8 encoder hardware register base
+ * @work_bufs: working buffer
+ * @work_buf_allocated: working buffer allocated flag
+ * @frm_cnt: encoded frame count, it's used for I-frame judgement and
+ *	     reset when force intra cmd received.
+ * @ts_mode: temporal scalability mode (0: disable, 1: enable)
+ *	     support three temporal layers - 0: 7.5fps 1: 7.5fps 2: 15fps.
+ * @is_key_frm: key frame flag
+ * @vpu_inst: VPU instance to exchange information between AP and VPU
+ * @ctx: context for v4l2 layer integration
+ * @dev: device for v4l2 layer integration
+ */
+struct venc_vp8_inst {
+	void __iomem *hw_base;
+	struct mtk_vcodec_mem work_bufs[VENC_VP8_VPU_WORK_BUF_MAX];
+	bool work_buf_allocated;
+	unsigned int frm_cnt;
+	unsigned int ts_mode;
+	unsigned int is_key_frm;
+	struct venc_vp8_vpu_inst vpu_inst;
+	void *ctx;
+	struct platform_device *dev;
+};
+
+struct venc_common_if *get_vp8_enc_comm_if(void);
+
+#endif
diff --git a/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c
new file mode 100644
index 0000000..5f797c9
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c
@@ -0,0 +1,240 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#include "mtk_vpu.h"
+
+#include "venc_vp8_if.h"
+#include "venc_vp8_vpu.h"
+#include "venc_ipi_msg.h"
+
+static void handle_vp8_enc_init_msg(struct venc_vp8_inst *inst, void *data)
+{
+	struct venc_vpu_ipi_msg_init *msg = data;
+
+	inst->vpu_inst.id = msg->inst_id;
+	inst->vpu_inst.drv = (struct venc_vp8_vpu_drv *)
+		vpu_mapping_dm_addr(inst->dev, msg->inst_id);
+}
+
+static void handle_vp8_enc_encode_msg(struct venc_vp8_inst *inst, void *data)
+{
+	struct venc_vpu_ipi_msg_enc *msg = data;
+
+	inst->vpu_inst.state = msg->state;
+	inst->is_key_frm = msg->key_frame;
+}
+
+static void vp8_enc_vpu_ipi_handler(void *data, unsigned int len, void *priv)
+{
+	struct venc_vpu_ipi_msg_common *msg = data;
+	struct venc_vp8_inst *inst = (struct venc_vp8_inst *)msg->venc_inst;
+
+	mtk_vcodec_debug(inst, "->msg_id=%x status=%d",
+			 msg->msg_id, msg->status);
+
+	switch (msg->msg_id) {
+	case VPU_IPIMSG_VP8_ENC_INIT_DONE:
+		handle_vp8_enc_init_msg(inst, data);
+		break;
+	case VPU_IPIMSG_VP8_ENC_SET_PARAM_DONE:
+		break;
+	case VPU_IPIMSG_VP8_ENC_ENCODE_DONE:
+		handle_vp8_enc_encode_msg(inst, data);
+		break;
+	case VPU_IPIMSG_VP8_ENC_DEINIT_DONE:
+		break;
+	default:
+		mtk_vcodec_err(inst, "unknown msg id=%x", msg->msg_id);
+		break;
+	}
+
+	inst->vpu_inst.signaled = 1;
+	inst->vpu_inst.failure = (msg->status != VENC_IPI_MSG_STATUS_OK);
+
+	mtk_vcodec_debug_leave(inst);
+}
+
+static int vp8_enc_vpu_send_msg(struct venc_vp8_inst *inst, void *msg,
+				int len)
+{
+	int status;
+
+	mtk_vcodec_debug_enter(inst);
+	status = vpu_ipi_send(inst->dev, IPI_VENC_VP8, (void *)msg, len);
+	if (status) {
+		mtk_vcodec_err(inst,
+			       "vpu_ipi_send msg_id=%x len=%d failed status=%d",
+			       *(unsigned int *)msg, len, status);
+		return -EINVAL;
+	}
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
+
+int vp8_enc_vpu_init(struct venc_vp8_inst *inst)
+{
+	int status;
+	struct venc_ap_ipi_msg_init out;
+
+	mtk_vcodec_debug_enter(inst);
+
+	init_waitqueue_head(&inst->vpu_inst.wq_hd);
+	inst->vpu_inst.signaled = 0;
+	inst->vpu_inst.failure = 0;
+
+	status = vpu_ipi_register(inst->dev, IPI_VENC_VP8,
+				  vp8_enc_vpu_ipi_handler,
+				  "vp8_enc", NULL);
+	if (status) {
+		mtk_vcodec_err(inst,
+			       "vpu_ipi_register failed status=%d", status);
+		return -EINVAL;
+	}
+
+	out.msg_id = AP_IPIMSG_VP8_ENC_INIT;
+	out.venc_inst = (unsigned long)inst;
+	if (vp8_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst, "failed");
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
+
+int vp8_enc_vpu_set_param(struct venc_vp8_inst *inst, unsigned int id,
+			  void *param)
+{
+	struct venc_ap_ipi_msg_set_param out;
+
+	mtk_vcodec_debug_enter(inst);
+
+	out.msg_id = AP_IPIMSG_VP8_ENC_SET_PARAM;
+	out.inst_id = inst->vpu_inst.id;
+	out.param_id = id;
+	switch (id) {
+	case VENC_SET_PARAM_ENC: {
+		struct venc_enc_prm *enc_param = (struct venc_enc_prm *)param;
+
+		inst->vpu_inst.drv->config.input_fourcc =
+			enc_param->input_fourcc;
+		inst->vpu_inst.drv->config.bitrate = enc_param->bitrate;
+		inst->vpu_inst.drv->config.pic_w = enc_param->width;
+		inst->vpu_inst.drv->config.pic_h = enc_param->height;
+		inst->vpu_inst.drv->config.buf_w = enc_param->buf_width;
+		inst->vpu_inst.drv->config.buf_h = enc_param->buf_height;
+		inst->vpu_inst.drv->config.intra_period =
+			enc_param->intra_period;
+		inst->vpu_inst.drv->config.framerate = enc_param->frm_rate;
+		inst->vpu_inst.drv->config.ts_mode = inst->ts_mode;
+		out.data_item = 0;
+		break;
+	}
+	case VENC_SET_PARAM_FORCE_INTRA:
+		out.data_item = 0;
+		break;
+	case VENC_SET_PARAM_ADJUST_BITRATE:
+		out.data_item = 1;
+		out.data[0] = *(unsigned int *)param;
+		break;
+	case VENC_SET_PARAM_ADJUST_FRAMERATE:
+		out.data_item = 1;
+		out.data[0] = *(unsigned int *)param;
+		break;
+	case VENC_SET_PARAM_I_FRAME_INTERVAL:
+		out.data_item = 1;
+		out.data[0] = *(unsigned int *)param;
+		break;
+	}
+	if (vp8_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst, "failed");
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
+
+int vp8_enc_vpu_encode(struct venc_vp8_inst *inst,
+		       struct venc_frm_buf *frm_buf,
+		       struct mtk_vcodec_mem *bs_buf)
+{
+	struct venc_ap_ipi_msg_enc out;
+
+	mtk_vcodec_debug_enter(inst);
+
+	out.msg_id = AP_IPIMSG_VP8_ENC_ENCODE;
+	out.inst_id = inst->vpu_inst.id;
+	if (frm_buf) {
+		if ((frm_buf->fb_addr.dma_addr % 16 == 0) &&
+		    (frm_buf->fb_addr1.dma_addr % 16 == 0) &&
+		    (frm_buf->fb_addr2.dma_addr % 16 == 0)) {
+			out.input_addr[0] = frm_buf->fb_addr.dma_addr;
+			out.input_addr[1] = frm_buf->fb_addr1.dma_addr;
+			out.input_addr[2] = frm_buf->fb_addr2.dma_addr;
+		} else {
+			mtk_vcodec_err(inst, "dma_addr not align to 16");
+			return -EINVAL;
+		}
+	} else {
+		out.input_addr[0] = 0;
+		out.input_addr[1] = 0;
+		out.input_addr[2] = 0;
+	}
+	if (bs_buf) {
+		out.bs_addr = bs_buf->dma_addr;
+		out.bs_size = bs_buf->size;
+	} else {
+		out.bs_addr = 0;
+		out.bs_size = 0;
+	}
+	if (vp8_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst, "failed");
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug(inst, "state=%d key_frm=%d",
+			 inst->vpu_inst.state, inst->is_key_frm);
+
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
+
+int vp8_enc_vpu_deinit(struct venc_vp8_inst *inst)
+{
+	struct venc_ap_ipi_msg_deinit out;
+
+	mtk_vcodec_debug_enter(inst);
+
+	out.msg_id = AP_IPIMSG_VP8_ENC_DEINIT;
+	out.inst_id = inst->vpu_inst.id;
+	if (vp8_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst, "failed");
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
diff --git a/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h
new file mode 100644
index 0000000..d7d79a8
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h
@@ -0,0 +1,28 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#ifndef _VENC_VP8_VPU_H_
+#define _VENC_VP8_VPU_H_
+
+int vp8_enc_vpu_init(struct venc_vp8_inst *inst);
+int vp8_enc_vpu_set_param(struct venc_vp8_inst *inst, unsigned int id,
+			  void *param);
+int vp8_enc_vpu_encode(struct venc_vp8_inst *inst,
+		       struct venc_frm_buf *frm_buf,
+		       struct mtk_vcodec_mem *bs_buf);
+int vp8_enc_vpu_deinit(struct venc_vp8_inst *inst);
+
+#endif
-- 
1.7.9.5



From tiffany.lin at mediatek.com  Thu Feb  4 03:34:57 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Thu, 4 Feb 2016 19:34:57 +0800
Subject: [PATCH v4 2/8] [media] VPU: mediatek: support Mediatek VPU
In-Reply-To: <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>

The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
It is able to handle video decoding/encoding of in a range of formats.
The driver provides with VPU firmware download, memory management and
the communication interface between CPU and VPU.
For VPU initialization, it will create virtual memory for CPU access and
IOMMU address for vcodec hw device access. When a decode/encode instance
opens a device node, vpu driver will download vpu firmware to the device.
A decode/encode instant will decode/encode a frame using VPU
interface to interrupt vpu to handle decoding/encoding jobs.

Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
---
 drivers/media/platform/Kconfig           |    9 +
 drivers/media/platform/Makefile          |    2 +
 drivers/media/platform/mtk-vpu/Makefile  |    1 +
 drivers/media/platform/mtk-vpu/mtk_vpu.c |  994 ++++++++++++++++++++++++++++++
 drivers/media/platform/mtk-vpu/mtk_vpu.h |  167 +++++
 5 files changed, 1173 insertions(+)
 create mode 100644 drivers/media/platform/mtk-vpu/Makefile
 create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c
 create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ccbc974..ba812d6 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -148,6 +148,15 @@ config VIDEO_CODA
 	   Coda is a range of video codec IPs that supports
 	   H.264, MPEG-4, and other video formats.
 
+config VIDEO_MEDIATEK_VPU
+	tristate "Mediatek Video Processor Unit"
+	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MEDIATEK
+	---help---
+	    This driver provides downloading VPU firmware and
+	    communicating with VPU. This driver for hw video
+	    codec embedded in new Mediatek's SOCs. It is able
+	    to handle video decoding/encoding in a range of formats.
+
 config VIDEO_MEM2MEM_DEINTERLACE
 	tristate "Deinterlace support"
 	depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index efa0295..e5b19c6 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -55,3 +55,5 @@ obj-$(CONFIG_VIDEO_AM437X_VPFE)		+= am437x/
 obj-$(CONFIG_VIDEO_XILINX)		+= xilinx/
 
 ccflags-y += -I$(srctree)/drivers/media/i2c
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VPU)	+= mtk-vpu/
diff --git a/drivers/media/platform/mtk-vpu/Makefile b/drivers/media/platform/mtk-vpu/Makefile
new file mode 100644
index 0000000..d890a66
--- /dev/null
+++ b/drivers/media/platform/mtk-vpu/Makefile
@@ -0,0 +1 @@
+obj-y += mtk_vpu.o
diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c
new file mode 100644
index 0000000..f54fd89
--- /dev/null
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
@@ -0,0 +1,994 @@
+/*
+* Copyright (c) 2015 MediaTek Inc.
+* Author: Andrew-CT Chen <andrew-ct.chen at mediatek.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.
+*/
+#include <linux/bootmem.h>
+#include <linux/clk.h>
+#include <linux/debugfs.h>
+#include <linux/firmware.h>
+#include <linux/interrupt.h>
+#include <linux/iommu.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/of_reserved_mem.h>
+#include <linux/sched.h>
+#include <linux/sizes.h>
+
+#include "mtk_vpu.h"
+
+/**
+ * VPU (video processor unit) is a tiny processor controlling video hardware
+ * related to video codec, scaling and color format converting.
+ * VPU interfaces with other blocks by share memory and interrupt.
+ **/
+
+#define INIT_TIMEOUT_MS		2000U
+#define IPI_TIMEOUT_MS		2000U
+#define VPU_FW_VER_LEN		16
+
+/* maximum program/data TCM (Tightly-Coupled Memory) size */
+#define VPU_PTCM_SIZE		(96 * SZ_1K)
+#define VPU_DTCM_SIZE		(32 * SZ_1K)
+/* the offset to get data tcm address */
+#define VPU_DTCM_OFFSET		0x18000UL
+/* daynamic allocated maximum extended memory size */
+#define VPU_EXT_P_SIZE		SZ_1M
+#define VPU_EXT_D_SIZE		SZ_4M
+/* maximum binary firmware size */
+#define VPU_P_FW_SIZE		(VPU_PTCM_SIZE + VPU_EXT_P_SIZE)
+#define VPU_D_FW_SIZE		(VPU_DTCM_SIZE + VPU_EXT_D_SIZE)
+/* the size of share buffer between Host and  VPU */
+#define SHARE_BUF_SIZE		48
+
+/* binary firmware name */
+#define VPU_P_FW		"vpu_p.bin"
+#define VPU_D_FW		"vpu_d.bin"
+
+#define VPU_RESET		0x0
+#define VPU_TCM_CFG		0x0008
+#define VPU_PMEM_EXT0_ADDR	0x000C
+#define VPU_PMEM_EXT1_ADDR	0x0010
+#define VPU_TO_HOST		0x001C
+#define VPU_DMEM_EXT0_ADDR	0x0014
+#define VPU_DMEM_EXT1_ADDR	0x0018
+#define HOST_TO_VPU		0x0024
+#define VPU_PC_REG		0x0060
+#define VPU_WDT_REG		0x0084
+
+/* vpu inter-processor communication interrupt */
+#define VPU_IPC_INT		BIT(8)
+
+/**
+ * enum vpu_fw_type - VPU firmware type
+ *
+ * @P_FW: program firmware
+ * @D_FW: data firmware
+ *
+ */
+enum vpu_fw_type {
+	P_FW,
+	D_FW,
+};
+
+/**
+ * struct vpu_mem - VPU extended program/data memory information
+ *
+ * @va:		the kernel virtual memory address of VPU extended memory
+ * @pa:		the physical memory address of VPU extended memory
+ *
+ */
+struct vpu_mem {
+	void *va;
+	dma_addr_t pa;
+};
+
+/**
+ * struct vpu_regs - VPU TCM and configuration registers
+ *
+ * @tcm:	the register for VPU Tightly-Coupled Memory
+ * @cfg:	the register for VPU configuration
+ * @irq:	the irq number for VPU interrupt
+ */
+struct vpu_regs {
+	void __iomem *tcm;
+	void __iomem *cfg;
+	int irq;
+};
+
+/**
+ * struct vpu_wdt_handler - VPU watchdog reset handler
+ *
+ * @reset_func:	reset handler
+ * @priv:	private data
+ */
+struct vpu_wdt_handler {
+	void (*reset_func)(void *);
+	void *priv;
+};
+
+/**
+ * struct vpu_wdt - VPU watchdog workqueue
+ *
+ * @handler:	VPU watchdog reset handler
+ * @ws:		workstruct for VPU watchdog
+ * @wq:		workqueue for VPU watchdog
+ */
+struct vpu_wdt {
+	struct vpu_wdt_handler handler[VPU_RST_MAX];
+	struct work_struct ws;
+	struct workqueue_struct *wq;
+};
+
+/**
+ * struct vpu_run - VPU initialization status
+ *
+ * @signaled:		the signal of vpu initialization completed
+ * @fw_ver:		VPU firmware version
+ * @enc_capability:	encoder capability
+ * @wq:			wait queue for VPU initialization status
+ */
+struct vpu_run {
+	u32 signaled;
+	char fw_ver[VPU_FW_VER_LEN];
+	unsigned int	enc_capability;
+	wait_queue_head_t wq;
+};
+
+/**
+ * struct vpu_ipi_desc - VPU IPI descriptor
+ *
+ * @handler:	IPI handler
+ * @name:	the name of IPI handler
+ * @priv:	the private data of IPI handler
+ */
+struct vpu_ipi_desc {
+	ipi_handler_t handler;
+	const char *name;
+	void *priv;
+};
+
+/**
+ * struct share_obj - DTCM (Data Tightly-Coupled Memory) buffer shared with
+ *		      AP and VPU
+ *
+ * @id:		IPI id
+ * @len:	share buffer length
+ * @share_buf:	share buffer data
+ */
+struct share_obj {
+	s32 id;
+	u32 len;
+	unsigned char share_buf[SHARE_BUF_SIZE];
+};
+
+/**
+ * struct mtk_vpu - vpu driver data
+ * @extmem:		VPU extended memory information
+ * @reg:		VPU TCM and configuration registers
+ * @run:		VPU initialization status
+ * @ipi_desc:		VPU IPI descriptor
+ * @recv_buf:		VPU DTCM share buffer for receiving. The
+ *			receive buffer is only accessed in interrupt context.
+ * @send_buf:		VPU DTCM share buffer for sending
+ * @dev:		VPU struct device
+ * @clk:		VPU clock on/off
+ * @enable_4GB:		VPU 4GB mode on/off
+ * @vpu_mutex:		protect mtk_vpu (except recv_buf) and ensure only
+ *			one client to use VPU service at a time. For example,
+ *			suppose a client is using VPU to decode VP8.
+ *			If the other client wants to encode VP8,
+ *			it has to wait until VP8 decode completes.
+ * @wdt_refcnt		WDT reference count to make sure the watchdog can be
+ *			disabled if no other client is using VPU service
+ * @ipi_ack_signaled:	The ACKs for registered IPI function sending
+ *			interrupt to VPU
+ * @ack_wq:		The wait queue for each codec and mdp. When sleeping
+ *			processes wake up, they will check the condition
+ *			"ipi_ack_signaled" to run the corresponding action or
+ *			go back to sleep.
+ *
+ */
+struct mtk_vpu {
+	struct vpu_mem extmem[2];
+	struct vpu_regs reg;
+	struct vpu_run run;
+	struct vpu_wdt wdt;
+	struct vpu_ipi_desc ipi_desc[IPI_MAX];
+	struct share_obj *recv_buf;
+	struct share_obj *send_buf;
+	struct device *dev;
+	struct clk *clk;
+	bool enable_4GB;
+	struct mutex vpu_mutex; /* for protecting vpu data data structure */
+	atomic_t wdt_refcnt;
+	wait_queue_head_t ack_wq;
+	bool ipi_id_ack[IPI_MAX];
+};
+
+static inline void vpu_cfg_writel(struct mtk_vpu *vpu, u32 val, u32 offset)
+{
+	writel(val, vpu->reg.cfg + offset);
+}
+
+static inline u32 vpu_cfg_readl(struct mtk_vpu *vpu, u32 offset)
+{
+	return readl(vpu->reg.cfg + offset);
+}
+
+static inline bool vpu_running(struct mtk_vpu *vpu)
+{
+	return vpu_cfg_readl(vpu, VPU_RESET) & BIT(0);
+}
+
+void vpu_clock_disable(struct mtk_vpu *vpu)
+{
+	/* Disable VPU watchdog */
+	if (atomic_dec_and_test(&vpu->wdt_refcnt))
+		vpu_cfg_writel(vpu,
+			       vpu_cfg_readl(vpu, VPU_WDT_REG) & ~(1L << 31),
+			       VPU_WDT_REG);
+
+	clk_disable(vpu->clk);
+}
+
+int vpu_clock_enable(struct mtk_vpu *vpu)
+{
+	int ret;
+
+	ret = clk_enable(vpu->clk);
+	if (ret)
+		return ret;
+	/* Enable VPU watchdog */
+	if (!atomic_read(&vpu->wdt_refcnt))
+		vpu_cfg_writel(vpu,
+			       vpu_cfg_readl(vpu, VPU_WDT_REG) | (1L << 31),
+			       VPU_WDT_REG);
+
+	atomic_inc(&vpu->wdt_refcnt);
+
+	return ret;
+}
+
+int vpu_ipi_register(struct platform_device *pdev,
+		     enum ipi_id id, ipi_handler_t handler,
+		     const char *name, void *priv)
+{
+	struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+	struct vpu_ipi_desc *ipi_desc;
+
+	if (!vpu) {
+		dev_err(&pdev->dev, "vpu device in not ready\n");
+		return -EPROBE_DEFER;
+	}
+
+	if (id < IPI_MAX && handler) {
+		ipi_desc = vpu->ipi_desc;
+		ipi_desc[id].name = name;
+		ipi_desc[id].handler = handler;
+		ipi_desc[id].priv = priv;
+		return 0;
+	}
+
+	dev_err(&pdev->dev, "register vpu ipi with invalid arguments\n");
+	return -EINVAL;
+}
+
+int vpu_ipi_send(struct platform_device *pdev,
+		 enum ipi_id id, void *buf,
+		 unsigned int len)
+{
+	struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+	struct share_obj *send_obj = vpu->send_buf;
+	unsigned long timeout;
+	int ret = 0;
+
+	if (id <= IPI_VPU_INIT || id >= IPI_MAX ||
+	    len > sizeof(send_obj->share_buf) || !buf) {
+		dev_err(vpu->dev, "failed to send ipi message\n");
+		return -EINVAL;
+	}
+
+	ret = vpu_clock_enable(vpu);
+	if (ret) {
+		dev_err(vpu->dev, "failed to enable vpu clock\n");
+		return ret;
+	}
+	if (!vpu_running(vpu)) {
+		dev_err(vpu->dev, "vpu_ipi_send: VPU is not running\n");
+		ret = -EINVAL;
+		goto clock_disable;
+	}
+
+	mutex_lock(&vpu->vpu_mutex);
+
+	 /* Wait until VPU receives the last command */
+	timeout = jiffies + msecs_to_jiffies(IPI_TIMEOUT_MS);
+	do {
+		if (time_after(jiffies, timeout)) {
+			dev_err(vpu->dev, "vpu_ipi_send: IPI timeout!\n");
+			ret = -EIO;
+			goto mut_unlock;
+		}
+	} while (vpu_cfg_readl(vpu, HOST_TO_VPU));
+
+	memcpy((void *)send_obj->share_buf, buf, len);
+	send_obj->len = len;
+	send_obj->id = id;
+
+	vpu->ipi_id_ack[id] = false;
+	/* send the command to VPU */
+	vpu_cfg_writel(vpu, 0x1, HOST_TO_VPU);
+
+	mutex_unlock(&vpu->vpu_mutex);
+
+	/* wait for VPU's ACK */
+	timeout = msecs_to_jiffies(IPI_TIMEOUT_MS);
+	ret = wait_event_interruptible_timeout(vpu->ack_wq,
+					       vpu->ipi_id_ack[id], timeout);
+	vpu->ipi_id_ack[id] = false;
+	if (ret == 0) {
+		dev_err(vpu->dev, "vpu ipi %d ack time out !", id);
+		ret = -EIO;
+		goto clock_disable;
+	} else if (-ERESTARTSYS == ret) {
+		dev_err(vpu->dev, "vpu ipi %d ack wait interrupted by a signal",
+			id);
+		ret = -ERESTARTSYS;
+		goto clock_disable;
+	}
+	vpu_clock_disable(vpu);
+
+	return 0;
+
+mut_unlock:
+	vpu->ipi_id_ack[id] = false;
+	mutex_unlock(&vpu->vpu_mutex);
+clock_disable:
+	vpu_clock_disable(vpu);
+
+	return ret;
+}
+
+static void vpu_wdt_reset_func(struct work_struct *ws)
+{
+	struct vpu_wdt *wdt = container_of(ws, struct vpu_wdt, ws);
+	struct mtk_vpu *vpu = container_of(wdt, struct mtk_vpu, wdt);
+	struct vpu_wdt_handler *handler = wdt->handler;
+	int index, ret;
+
+	dev_info(vpu->dev, "vpu reset\n");
+	mutex_lock(&vpu->vpu_mutex);
+	ret = vpu_clock_enable(vpu);
+	if (ret) {
+		dev_err(vpu->dev, "[VPU] wdt enables clock failed %d\n", ret);
+		return;
+	}
+	vpu_cfg_writel(vpu, 0x0, VPU_RESET);
+	vpu_clock_disable(vpu);
+	mutex_unlock(&vpu->vpu_mutex);
+
+	for (index = 0; index < VPU_RST_MAX; index++) {
+		if (handler[index].reset_func) {
+			handler[index].reset_func(handler[index].priv);
+			dev_dbg(vpu->dev, "wdt handler func %d\n", index);
+		}
+	}
+}
+
+int vpu_wdt_reg_handler(struct platform_device *pdev,
+			void wdt_reset(void *),
+			void *priv, enum rst_id id)
+{
+	struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+	struct vpu_wdt_handler *handler = vpu->wdt.handler;
+
+	if (!vpu) {
+		dev_err(vpu->dev, "vpu device in not ready\n");
+		return -EPROBE_DEFER;
+	}
+
+	if (id < VPU_RST_MAX && wdt_reset != NULL) {
+		dev_dbg(vpu->dev, "wdt register id %d\n", id);
+		mutex_lock(&vpu->vpu_mutex);
+		handler[id].reset_func = wdt_reset;
+		handler[id].priv = priv;
+		mutex_unlock(&vpu->vpu_mutex);
+		return 0;
+	}
+
+	dev_err(vpu->dev, "register vpu wdt handler failed\n");
+	return -EINVAL;
+}
+
+unsigned int vpu_get_venc_hw_capa(struct platform_device *pdev)
+{
+	struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+
+	return vpu->run.enc_capability;
+}
+
+void *vpu_mapping_dm_addr(struct platform_device *pdev,
+			  u32 dtcm_dmem_addr)
+{
+	struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+
+	if (!dtcm_dmem_addr ||
+	    (dtcm_dmem_addr > (VPU_DTCM_SIZE + VPU_EXT_D_SIZE))) {
+		dev_err(vpu->dev, "invalid virtual data memory address\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (dtcm_dmem_addr < VPU_DTCM_SIZE)
+		return dtcm_dmem_addr + vpu->reg.tcm + VPU_DTCM_OFFSET;
+
+	return vpu->extmem[D_FW].va + (dtcm_dmem_addr - VPU_DTCM_SIZE);
+}
+
+struct platform_device *vpu_get_plat_device(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *vpu_node;
+	struct platform_device *vpu_pdev;
+
+	vpu_node = of_parse_phandle(dev->of_node, "mediatek,vpu", 0);
+	if (!vpu_node) {
+		dev_err(dev, "can't get vpu node\n");
+		return NULL;
+	}
+
+	vpu_pdev = of_find_device_by_node(vpu_node);
+	if (WARN_ON(!vpu_pdev)) {
+		dev_err(dev, "vpu pdev failed\n");
+		of_node_put(vpu_node);
+		return NULL;
+	}
+
+	return vpu_pdev;
+}
+
+/* load vpu program/data memory */
+static int load_requested_vpu(struct mtk_vpu *vpu,
+			      const struct firmware *vpu_fw,
+			      u8 fw_type)
+{
+	size_t tcm_size = fw_type ? VPU_DTCM_SIZE : VPU_PTCM_SIZE;
+	size_t fw_size = fw_type ? VPU_D_FW_SIZE : VPU_P_FW_SIZE;
+	char *fw_name = fw_type ? VPU_D_FW : VPU_P_FW;
+	size_t dl_size = 0;
+	size_t extra_fw_size = 0;
+	void *dest;
+	int ret;
+
+	ret = request_firmware(&vpu_fw, fw_name, vpu->dev);
+	if (ret < 0) {
+		dev_err(vpu->dev, "Failed to load %s, %d\n", fw_name, ret);
+		return ret;
+	}
+	dl_size = vpu_fw->size;
+	if (dl_size > fw_size) {
+		dev_err(vpu->dev, "fw %s size %zu is abnormal\n", fw_name,
+			dl_size);
+		release_firmware(vpu_fw);
+		return  -EFBIG;
+	}
+	dev_dbg(vpu->dev, "Downloaded fw %s size: %zu.\n",
+		fw_name,
+		dl_size);
+	/* reset VPU */
+	vpu_cfg_writel(vpu, 0x0, VPU_RESET);
+
+	/* handle extended firmware size */
+	if (dl_size > tcm_size) {
+		dev_dbg(vpu->dev, "fw size %lx > limited fw size %lx\n",
+			dl_size, tcm_size);
+		extra_fw_size = dl_size - tcm_size;
+		dev_dbg(vpu->dev, "extra_fw_size %lx\n", extra_fw_size);
+		dl_size = tcm_size;
+	}
+	dest = vpu->reg.tcm;
+	if (fw_type == D_FW)
+		dest += VPU_DTCM_OFFSET;
+	memcpy(dest, vpu_fw->data, dl_size);
+	/* download to extended memory if need */
+	if (extra_fw_size > 0) {
+		dest = vpu->extmem[fw_type].va;
+		dev_dbg(vpu->dev, "download extended memory type %x\n",
+			fw_type);
+		memcpy(dest, vpu_fw->data + tcm_size, extra_fw_size);
+	}
+
+	release_firmware(vpu_fw);
+
+	return 0;
+}
+
+int vpu_load_firmware(struct platform_device *pdev)
+{
+	struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+	struct device *dev = &pdev->dev;
+	struct vpu_run *run = &vpu->run;
+	const struct firmware *vpu_fw;
+	int ret;
+
+	if (!pdev) {
+		dev_err(dev, "VPU platform device is invalid\n");
+		return -EINVAL;
+	}
+
+	mutex_lock(&vpu->vpu_mutex);
+
+	ret = vpu_clock_enable(vpu);
+	if (ret) {
+		dev_err(dev, "enable clock failed %d\n", ret);
+		goto OUT_LOAD_FW;
+	}
+
+	if (vpu_running(vpu)) {
+		vpu_clock_disable(vpu);
+		mutex_unlock(&vpu->vpu_mutex);
+		dev_warn(dev, "vpu is running already\n");
+		return 0;
+	}
+
+	run->signaled = false;
+	dev_dbg(vpu->dev, "firmware request\n");
+	/* Downloading program firmware to device*/
+	ret = load_requested_vpu(vpu, vpu_fw, P_FW);
+	if (ret < 0) {
+		dev_err(dev, "Failed to request %s, %d\n", VPU_P_FW, ret);
+		goto OUT_LOAD_FW;
+	}
+
+	/* Downloading data firmware to device */
+	ret = load_requested_vpu(vpu, vpu_fw, D_FW);
+	if (ret < 0) {
+		dev_err(dev, "Failed to request %s, %d\n", VPU_D_FW, ret);
+		goto OUT_LOAD_FW;
+	}
+
+	/* boot up vpu */
+	vpu_cfg_writel(vpu, 0x1, VPU_RESET);
+
+	ret = wait_event_interruptible_timeout(run->wq,
+					       run->signaled,
+					       msecs_to_jiffies(INIT_TIMEOUT_MS)
+					       );
+	if (ret == 0) {
+		ret = -ETIME;
+		dev_err(dev, "wait vpu initialization timout!\n");
+		goto OUT_LOAD_FW;
+	} else if (-ERESTARTSYS == ret) {
+		dev_err(dev, "wait vpu interrupted by a signal!\n");
+		goto OUT_LOAD_FW;
+	}
+
+	ret = 0;
+	dev_info(dev, "vpu is ready. Fw version %s\n", run->fw_ver);
+
+OUT_LOAD_FW:
+	vpu_clock_disable(vpu);
+	mutex_unlock(&vpu->vpu_mutex);
+
+	return ret;
+}
+
+int vpu_compare_version(struct platform_device *pdev,
+			const char *expected_version)
+{
+	struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+	int cur_major, cur_minor, cur_build, cur_rel, cur_ver_num;
+	int major, minor, build, rel, ver_num;
+	char *cur_version = vpu->run.fw_ver;
+
+	cur_ver_num = sscanf(cur_version, "%d.%d.%d-rc%d",
+			     &cur_major, &cur_minor, &cur_build, &cur_rel);
+	if (cur_ver_num < 3)
+		return -1;
+	ver_num = sscanf(expected_version, "%d.%d.%d-rc%d",
+			 &major, &minor, &build, &rel);
+	if (ver_num < 3)
+		return -1;
+
+	if (cur_major < major)
+		return -1;
+	if (cur_major > major)
+		return 1;
+
+	if (cur_minor < minor)
+		return -1;
+	if (cur_minor > minor)
+		return 1;
+
+	if (cur_build < build)
+		return -1;
+	if (cur_build > build)
+		return 1;
+
+	if (cur_ver_num < ver_num)
+		return -1;
+	if (cur_ver_num > ver_num)
+		return 1;
+
+	if (ver_num > 3) {
+		if (cur_rel < rel)
+			return -1;
+		if (cur_rel > rel)
+			return 1;
+	}
+
+	return 0;
+}
+
+static void vpu_init_ipi_handler(void *data, unsigned int len, void *priv)
+{
+	struct mtk_vpu *vpu = (struct mtk_vpu *)priv;
+	struct vpu_run *run = (struct vpu_run *)data;
+
+	vpu->run.signaled = run->signaled;
+	strncpy(vpu->run.fw_ver, run->fw_ver, VPU_FW_VER_LEN);
+	vpu->run.enc_capability = run->enc_capability;
+	wake_up_interruptible(&vpu->run.wq);
+}
+
+#ifdef CONFIG_DEBUG_FS
+static int vpu_debug_open(struct inode *inode, struct file *file)
+{
+	file->private_data = inode->i_private;
+	return 0;
+}
+
+static ssize_t vpu_debug_read(struct file *file, char __user *user_buf,
+			      size_t count, loff_t *ppos)
+{
+	char buf[256];
+	unsigned int len;
+	unsigned int running, pc, vpu_to_host, host_to_vpu, wdt;
+	int ret;
+	struct device *dev = file->private_data;
+	struct mtk_vpu *vpu = dev_get_drvdata(dev);
+
+	ret = vpu_clock_enable(vpu);
+	if (ret) {
+		dev_err(vpu->dev, "[VPU] enable clock failed %d\n", ret);
+		return 0;
+	}
+
+	/* vpu register status */
+	running = vpu_running(vpu);
+	pc = vpu_cfg_readl(vpu, VPU_PC_REG);
+	wdt = vpu_cfg_readl(vpu, VPU_WDT_REG);
+	host_to_vpu = vpu_cfg_readl(vpu, HOST_TO_VPU);
+	vpu_to_host = vpu_cfg_readl(vpu, VPU_TO_HOST);
+	vpu_clock_disable(vpu);
+
+	if (running) {
+		len = sprintf(buf, "VPU is running\n\n"
+		"FW Version: %s\n"
+		"PC: 0x%x\n"
+		"WDT: 0x%x\n"
+		"Host to VPU: 0x%x\n"
+		"VPU to Host: 0x%x\n",
+		vpu->run.fw_ver, pc, wdt,
+		host_to_vpu, vpu_to_host);
+	} else {
+		len = sprintf(buf, "VPU not running\n");
+	}
+
+	return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static const struct file_operations vpu_debug_fops = {
+	.open = vpu_debug_open,
+	.read = vpu_debug_read,
+};
+#endif /* CONFIG_DEBUG_FS */
+
+static void vpu_free_ext_mem(struct mtk_vpu *vpu, u8 fw_type)
+{
+	struct device *dev = vpu->dev;
+	size_t fw_ext_size = fw_type ? VPU_EXT_D_SIZE : VPU_EXT_P_SIZE;
+
+	dma_free_coherent(dev, fw_ext_size, vpu->extmem[fw_type].va,
+			  vpu->extmem[fw_type].pa);
+}
+
+static int vpu_alloc_ext_mem(struct mtk_vpu *vpu, u32 fw_type)
+{
+	struct device *dev = vpu->dev;
+	size_t fw_ext_size = fw_type ? VPU_EXT_D_SIZE : VPU_EXT_P_SIZE;
+	u32 vpu_ext_mem0 = fw_type ? VPU_DMEM_EXT0_ADDR : VPU_PMEM_EXT0_ADDR;
+	u32 vpu_ext_mem1 = fw_type ? VPU_DMEM_EXT1_ADDR : VPU_PMEM_EXT1_ADDR;
+	u32 offset_4gb = vpu->enable_4GB ? 0x40000000 : 0;
+
+	vpu->extmem[fw_type].va = dma_alloc_coherent(dev,
+					       fw_ext_size,
+					       &vpu->extmem[fw_type].pa,
+					       GFP_KERNEL);
+	if (!vpu->extmem[fw_type].va) {
+		dev_err(dev, "Failed to allocate the extended program memory\n");
+		return PTR_ERR(vpu->extmem[fw_type].va);
+	}
+
+	/* Disable extend0. Enable extend1 */
+	vpu_cfg_writel(vpu, 0x1, vpu_ext_mem0);
+	vpu_cfg_writel(vpu, (vpu->extmem[fw_type].pa & 0xFFFFF000) + offset_4gb,
+		       vpu_ext_mem1);
+
+	dev_info(dev, "%s extend memory phy=0x%llx virt=0x%p\n",
+		 fw_type ? "Data" : "Program",
+		 (unsigned long long)vpu->extmem[fw_type].pa,
+		 vpu->extmem[fw_type].va);
+
+	return 0;
+}
+
+static void vpu_ipi_handler(struct mtk_vpu *vpu)
+{
+	struct share_obj *rcv_obj = vpu->recv_buf;
+	struct vpu_ipi_desc *ipi_desc = vpu->ipi_desc;
+
+	if (rcv_obj->id < IPI_MAX && ipi_desc[rcv_obj->id].handler) {
+		ipi_desc[rcv_obj->id].handler(rcv_obj->share_buf,
+					      rcv_obj->len,
+					      ipi_desc[rcv_obj->id].priv);
+		if (rcv_obj->id > IPI_VPU_INIT) {
+			vpu->ipi_id_ack[rcv_obj->id] = true;
+			wake_up_interruptible(&vpu->ack_wq);
+		}
+	} else {
+		dev_err(vpu->dev, "No such ipi id = %d\n", rcv_obj->id);
+	}
+}
+
+static int vpu_ipi_init(struct mtk_vpu *vpu)
+{
+	/* Disable VPU to host interrupt */
+	vpu_cfg_writel(vpu, 0x0, VPU_TO_HOST);
+
+	/* shared buffer initialization */
+	vpu->recv_buf = (struct share_obj *)(vpu->reg.tcm + VPU_DTCM_OFFSET);
+	vpu->send_buf = vpu->recv_buf + 1;
+	memset(vpu->recv_buf, 0, sizeof(struct share_obj));
+	memset(vpu->send_buf, 0, sizeof(struct share_obj));
+	mutex_init(&vpu->vpu_mutex);
+
+	return 0;
+}
+
+static irqreturn_t vpu_irq_handler(int irq, void *priv)
+{
+	struct mtk_vpu *vpu = priv;
+	u32 vpu_to_host;
+	int ret;
+
+	/*
+	 * Clock should have been enabled already.
+	 * Enable again in case vpu_ipi_send times out
+	 * and has disabled the clock.
+	 */
+	ret = clk_enable(vpu->clk);
+	if (ret) {
+		dev_err(vpu->dev, "[VPU] enable clock failed %d\n", ret);
+		return IRQ_NONE;
+	}
+	vpu_to_host = vpu_cfg_readl(vpu, VPU_TO_HOST);
+	if (vpu_to_host & VPU_IPC_INT) {
+		vpu_ipi_handler(vpu);
+	} else {
+		dev_err(vpu->dev, "vpu watchdog timeout! 0x%x", vpu_to_host);
+		if (vpu->wdt.wq)
+			queue_work(vpu->wdt.wq, &vpu->wdt.ws);
+	}
+
+	/* VPU won't send another interrupt until we set VPU_TO_HOST to 0. */
+	vpu_cfg_writel(vpu, 0x0, VPU_TO_HOST);
+	clk_disable(vpu->clk);
+
+	return IRQ_HANDLED;
+}
+
+#ifdef CONFIG_DEBUG_FS
+static struct dentry *vpu_debugfs;
+#endif
+static int mtk_vpu_probe(struct platform_device *pdev)
+{
+	struct mtk_vpu *vpu;
+	struct device *dev;
+	struct resource *res;
+	int ret = 0;
+
+	dev_dbg(&pdev->dev, "initialization\n");
+
+	dev = &pdev->dev;
+	vpu = devm_kzalloc(dev, sizeof(*vpu), GFP_KERNEL);
+	if (!vpu)
+		return -ENOMEM;
+
+	vpu->dev = &pdev->dev;
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "tcm");
+	vpu->reg.tcm = devm_ioremap_resource(dev, res);
+	if (IS_ERR(vpu->reg.tcm)) {
+		dev_err(dev, "devm_ioremap_resource vpu tcm failed.\n");
+		return PTR_ERR(vpu->reg.tcm);
+	}
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg_reg");
+	vpu->reg.cfg = devm_ioremap_resource(dev, res);
+	if (IS_ERR(vpu->reg.cfg)) {
+		dev_err(dev, "devm_ioremap_resource vpu cfg failed.\n");
+		return PTR_ERR(vpu->reg.cfg);
+	}
+
+	/* Get VPU clock */
+	vpu->clk = devm_clk_get(dev, "main");
+	if (!vpu->clk) {
+		dev_err(dev, "get vpu clock failed\n");
+		return -EINVAL;
+	}
+
+	platform_set_drvdata(pdev, vpu);
+
+	ret = clk_prepare(vpu->clk);
+	if (ret) {
+		dev_err(dev, "prepare vpu clock failed\n");
+		return ret;
+	}
+
+	/* VPU watchdog */
+	vpu->wdt.wq = create_singlethread_workqueue("vpu_wdt");
+	if (!vpu->wdt.wq) {
+		dev_err(dev, "initialize wdt workqueue failed\n");
+		return -ENOMEM;
+	}
+	INIT_WORK(&vpu->wdt.ws, vpu_wdt_reset_func);
+
+	ret = vpu_clock_enable(vpu);
+	if (ret) {
+		dev_err(dev, "enable vpu clock failed\n");
+		goto workqueue_destroy;
+	}
+
+	dev_dbg(dev, "vpu ipi init\n");
+	ret = vpu_ipi_init(vpu);
+	if (ret) {
+		dev_err(dev, "Failed to init ipi\n");
+		goto disable_vpu_clk;
+	}
+
+	/* register vpu initialization IPI */
+	ret = vpu_ipi_register(pdev, IPI_VPU_INIT, vpu_init_ipi_handler,
+			       "vpu_init", vpu);
+	if (ret) {
+		dev_err(dev, "Failed to register IPI_VPU_INIT\n");
+		goto vpu_mutex_destroy;
+	}
+
+#ifdef CONFIG_DEBUG_FS
+	vpu_debugfs = debugfs_create_file("mtk_vpu", S_IRUGO, NULL, (void *)dev,
+					  &vpu_debug_fops);
+	if (!vpu_debugfs) {
+		ret = -ENOMEM;
+		goto cleanup_ipi;
+	}
+#endif
+
+	/* Set PTCM to 96K and DTCM to 32K */
+	vpu_cfg_writel(vpu, 0x2, VPU_TCM_CFG);
+
+	vpu->enable_4GB = !!(max_pfn > (0xffffffffUL >> PAGE_SHIFT));
+	dev_dbg(dev, "4GB mode %u\n", vpu->enable_4GB);
+
+	if (vpu->enable_4GB) {
+		ret = of_reserved_mem_device_init(dev);
+		if (ret)
+			dev_info(dev, "init reserved memory failed\n");
+			/* continue to use dynamic allocation if failed */
+	}
+
+	ret = vpu_alloc_ext_mem(vpu, D_FW);
+	if (ret) {
+		dev_err(dev, "Allocate DM failed\n");
+		goto remove_debugfs;
+	}
+
+	ret = vpu_alloc_ext_mem(vpu, P_FW);
+	if (ret) {
+		dev_err(dev, "Allocate PM failed\n");
+		goto free_d_mem;
+	}
+
+	init_waitqueue_head(&vpu->run.wq);
+	init_waitqueue_head(&vpu->ack_wq);
+
+	res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+	if (!res) {
+		dev_err(dev, "get IRQ resource failed.\n");
+		ret = -ENXIO;
+		goto free_p_mem;
+	}
+	vpu->reg.irq = platform_get_irq(pdev, 0);
+	ret = devm_request_irq(dev, vpu->reg.irq, vpu_irq_handler, 0,
+			       pdev->name, vpu);
+	if (ret) {
+		dev_err(dev, "failed to request irq\n");
+		goto free_p_mem;
+	}
+
+	vpu_clock_disable(vpu);
+	dev_dbg(dev, "initialization completed\n");
+
+	return 0;
+
+free_p_mem:
+	vpu_free_ext_mem(vpu, P_FW);
+free_d_mem:
+	vpu_free_ext_mem(vpu, D_FW);
+remove_debugfs:
+	of_reserved_mem_device_release(dev);
+#ifdef CONFIG_DEBUG_FS
+	debugfs_remove(vpu_debugfs);
+cleanup_ipi:
+#endif
+	memset(vpu->ipi_desc, 0, sizeof(struct vpu_ipi_desc) * IPI_MAX);
+vpu_mutex_destroy:
+	mutex_destroy(&vpu->vpu_mutex);
+disable_vpu_clk:
+	vpu_clock_disable(vpu);
+workqueue_destroy:
+	destroy_workqueue(vpu->wdt.wq);
+
+	return ret;
+}
+
+static const struct of_device_id mtk_vpu_match[] = {
+	{
+		.compatible = "mediatek,mt8173-vpu",
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, mtk_vpu_match);
+
+static int mtk_vpu_remove(struct platform_device *pdev)
+{
+	struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+
+#ifdef CONFIG_DEBUG_FS
+	debugfs_remove(vpu_debugfs);
+#endif
+	if (vpu->wdt.wq) {
+		flush_workqueue(vpu->wdt.wq);
+		destroy_workqueue(vpu->wdt.wq);
+	}
+	vpu_free_ext_mem(vpu, P_FW);
+	vpu_free_ext_mem(vpu, D_FW);
+	mutex_destroy(&vpu->vpu_mutex);
+	clk_unprepare(vpu->clk);
+
+	return 0;
+}
+
+static struct platform_driver mtk_vpu_driver = {
+	.probe	= mtk_vpu_probe,
+	.remove	= mtk_vpu_remove,
+	.driver	= {
+		.name	= "mtk_vpu",
+		.owner	= THIS_MODULE,
+		.of_match_table = mtk_vpu_match,
+	},
+};
+
+module_platform_driver(mtk_vpu_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Mediatek Video Prosessor Unit driver");
diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.h b/drivers/media/platform/mtk-vpu/mtk_vpu.h
new file mode 100644
index 0000000..d9c3cde
--- /dev/null
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.h
@@ -0,0 +1,167 @@
+/*
+* Copyright (c) 2015 MediaTek Inc.
+* Author: Andrew-CT Chen <andrew-ct.chen at mediatek.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.
+*/
+
+#ifndef _MTK_VPU_H
+#define _MTK_VPU_H
+
+#include <linux/platform_device.h>
+
+/**
+ * VPU (video processor unit) is a tiny processor controlling video hardware
+ * related to video codec, scaling and color format converting.
+ * VPU interfaces with other blocks by share memory and interrupt.
+ **/
+
+typedef void (*ipi_handler_t) (void *data,
+			       unsigned int len,
+			       void *priv);
+
+/**
+ * enum ipi_id - the id of inter-processor interrupt
+ *
+ * @IPI_VPU_INIT:	 The interrupt from vpu is to notfiy kernel
+			 VPU initialization completed.
+			 IPI_VPU_INIT is sent from VPU when firmware is
+			 loaded. AP doesn't need to send IPI_VPU_INIT
+			 command to VPU.
+			 For other IPI below, AP should send the request
+			 to VPU to trigger the interrupt.
+ * @IPI_VENC_H264:	 The interrupt from vpu is to notify kernel to
+			 handle H264 video encoder job, and vice versa.
+ * @IPI_VENC_VP8:	 The interrupt fro vpu is to notify kernel to
+			 handle VP8 video encoder job,, and vice versa.
+ * @IPI_MAX:		 The maximum IPI number
+ */
+
+enum ipi_id {
+	IPI_VPU_INIT = 0,
+	IPI_VENC_H264,
+	IPI_VENC_VP8,
+	IPI_MAX,
+};
+
+/**
+ * enum rst_id - reset id to register reset function for VPU watchdog timeout
+ *
+ * @VPU_RST_DEC: decoder reset id
+ * @VPU_RST_ENC: encoder reset id
+ * @VPU_RST_MDP: MDP (Media Data Path) reset id
+ * @VPU_RST_MAX: maximum reset id
+ */
+enum rst_id {
+	VPU_RST_ENC,
+	VPU_RST_DEC,
+	VPU_RST_MDP,
+	VPU_RST_MAX,
+};
+
+/**
+ * vpu_ipi_register - register an ipi function
+ *
+ * @pdev:	VPU platform device
+ * @id:		IPI ID
+ * @handler:	IPI handler
+ * @name:	IPI name
+ * @priv:	private data for IPI handler
+ *
+ * Register an ipi function to receive ipi interrupt from VPU.
+ *
+ * Return: Return 0 if ipi registers successfully, otherwise it is failed.
+ */
+int vpu_ipi_register(struct platform_device *pdev, enum ipi_id id,
+		     ipi_handler_t handler, const char *name, void *priv);
+
+/**
+ * vpu_ipi_send - send data from AP to vpu.
+ *
+ * @pdev:	VPU platform device
+ * @id:		IPI ID
+ * @buf:	the data buffer
+ * @len:	the data buffer length
+ *
+ * This function is thread-safe. When this function returns,
+ * VPU has received the data and starts the processing.
+ * When the processing completes, IPI handler registered
+ * by vpu_ipi_register will be called in interrupt context.
+ *
+ * Return: Return 0 if sending data successfully, otherwise it is failed.
+ **/
+int vpu_ipi_send(struct platform_device *pdev,
+		 enum ipi_id id, void *buf,
+		 unsigned int len);
+
+/**
+ * vpu_get_plat_device - get VPU's platform device
+ *
+ * @pdev:	the platform device of the module requesting VPU platform
+ *		device for using VPU API.
+ *
+ * Return: Return NULL if it is failed.
+ * otherwise it is VPU's platform device
+ **/
+struct platform_device *vpu_get_plat_device(struct platform_device *pdev);
+
+/**
+ * vpu_wdt_reg_handler - register a VPU watchdog handler
+ *
+ * @pdev:               VPU platform device
+ * @vpu_wdt_reset_func:	the callback reset function
+ * @private_data:       the private data for reset function
+ * @rst_id:		reset id
+ *
+ * Register a handler performing own tasks when vpu reset by watchdog
+ *
+ * Return: Return 0 if the handler is added successfully,
+ * otherwise it is failed.
+ *
+ **/
+int vpu_wdt_reg_handler(struct platform_device *pdev,
+			void vpu_wdt_reset_func(void *),
+			void *priv, enum rst_id id);
+
+/**
+ * vpu_get_venc_hw_capa - get video encoder hardware capability
+ *
+ * @pdev:	VPU platform device
+ *
+ * Return: video encoder hardware capability
+ **/
+unsigned int vpu_get_venc_hw_capa(struct platform_device *pdev);
+
+/**
+ * vpu_load_firmware - download VPU firmware and boot it
+ *
+ * @pdev:	VPU platform device
+ *
+ * Return: Return 0 if downloading firmware successfully,
+ * otherwise it is failed
+ **/
+int vpu_load_firmware(struct platform_device *pdev);
+
+/**
+ * vpu_mapping_dm_addr - Mapping DTCM/DMEM to kernel virtual address
+ *
+ * @pdev:	VPU platform device
+ * @dmem_addr:	VPU's data memory address
+ *
+ * Mapping the VPU's DTCM (Data Tightly-Coupled Memory) /
+ * DMEM (Data Extended Memory) memory address to
+ * kernel virtual address.
+ *
+ * Return: Return ERR_PTR(-EINVAL) if mapping failed,
+ * otherwise the mapped kernel virtual address
+ **/
+void *vpu_mapping_dm_addr(struct platform_device *pdev,
+			  u32 dtcm_dmem_addr);
+#endif /* _MTK_VPU_H */
-- 
1.7.9.5



From tiffany.lin at mediatek.com  Thu Feb  4 03:49:43 2016
From: tiffany.lin at mediatek.com (tiffany lin)
Date: Thu, 4 Feb 2016 19:49:43 +0800
Subject: [PATCH v3 1/8] dt-bindings: Add a binding for Mediatek Video
 Processor
In-Reply-To: <20160104141506.GA22801@rob-hp-laptop>
References: <1451902316-55931-1-git-send-email-tiffany.lin@mediatek.com>
 <1451902316-55931-2-git-send-email-tiffany.lin@mediatek.com>
 <20160104141506.GA22801@rob-hp-laptop>
Message-ID: <1454586583.7571.3.camel@mtksdaap41>

Hi Rob,




On Mon, 2016-01-04 at 22:15 +0800, Rob Herring wrote:
> On Mon, Jan 04, 2016 at 06:11:49PM +0800, Tiffany Lin wrote:
> > From: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
> > 
> > Add a DT binding documentation of Video Processor Unit for the
> > MT8173 SoC from Mediatek.
> > 
> > Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
> > Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
> 
> Please add acks when sending new versions as I already acked the last 
> version.
> 
Since we remove iommu attach and add 4GB support for VPU.
We send the new device tree and binding document.
We do not add Acked-by in v4 patches.

> Acked-by: Rob Herring <robh at kernel.org>

best regards,
Tiffany



From grygorii.strashko at ti.com  Thu Feb  4 03:53:16 2016
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Thu, 4 Feb 2016 13:53:16 +0200
Subject: [PATCH 1/2] ARM: make virt_to_idmap() return unsigned long
In-Reply-To: <20160203195905.GC10826@n2100.arm.linux.org.uk>
References: <E1aO8F2-00074N-E8@rmk-PC.arm.linux.org.uk>
 <56A84748.3040108@oracle.com> <20160201152015.GU10826@n2100.arm.linux.org.uk>
 <56AF8F54.7030805@ti.com> <56AF917F.9030505@oracle.com>
 <56B14546.4070808@oracle.com> <56B20B2E.7060408@ti.com>
 <56B2201B.7020205@ti.com> <20160203195905.GC10826@n2100.arm.linux.org.uk>
Message-ID: <56B33BAC.6020303@ti.com>

On 02/03/2016 09:59 PM, Russell King - ARM Linux wrote:
> On Wed, Feb 03, 2016 at 10:43:23AM -0500, Vitaly Andrianov wrote:
>>> 100%. I came up with absolutely similar fix.
>>>
>>>
>>> Regarding, kexec:
>>> - it seems can't be tested on ks2 out of the box, because there is unmet dependency in kconfig
>>>   config KEXEC
>>>          bool "Kexec system call (EXPERIMENTAL)"
>>> -       depends on (!SMP || PM_SLEEP_SMP)
>>>          depends on !CPU_V7M
>>>          select KEXEC_CORE
>>>          help
>>>
>>> - any way, i've hacked kernel as above;
>>> - downloaded and built kexec-tools
>>> git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.git
>>> - tried to run it using different combination of parameters, but always
>>> with below result:
>>> # kexec -l /boot/zImage
>>> kexec version: 15.12.22.16.38-g6503cb3
>>> Could not find a free area of memory of 0x3b2ca0 bytes...
>>> Cannot load /boot/zImage
>>>
>>> I'm doing something wrong, but don't know what yet :(
>>> - these patches were not applied, I'd like to see kexec not working first
>>>
>>>
>> I'm not sure about that particular issue, but when I worked on KS2 kexec I
>> had to patch kexec-tools to support KS2 LPAE memory.
> 
> This was specifically for Vitaly to test, as he has patches to work
> around most of the KS2 issues with kexec (although I have a KS2, I
> don't have everything that's necessary to get a working kexec in
> place.)
> 
> What I do want to know is whether this patch makes Vitaly's kexec
> patch smaller, and most importantly, what's left to deal with - in
> other words, I'd like to see the kernel patch for what's remaining.
> 
> Alternatively, if I can have both the kernel and userland patches
> so I can get a working kexec setup here, that may be a better way
> forward.
> 
> Either way, I think I'm going to push these patches out into
> linux-next very soon, because I believe that they're the correct
> approach to solving some of the issues found in Vitaly's original
> patch, unless someone discovers that they're broken in some manner.
> 

This patch boot/reboot tested on k2hk-evm (LPAE=y), ping works (with netcp regression fixed)
Tested-by: Grygorii Strashko <grygorii.strashko at ti.com>


-- 
regards,
-grygorii


From vincent.guittot at linaro.org  Thu Feb  4 04:03:07 2016
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 4 Feb 2016 13:03:07 +0100
Subject: [PATCH v3 2/6] drivers/cpufreq: implement
 init_cpu_capacity_default()
In-Reply-To: <20160204093559.GA14099@e105550-lin.cambridge.arm.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <1454500799-18451-3-git-send-email-juri.lelli@arm.com>
 <CAKfTPtDGk5BC25WqHdhDYDOBgUsuidAMhrXS=eDi6wJPZjfrwA@mail.gmail.com>
 <20160204093559.GA14099@e105550-lin.cambridge.arm.com>
Message-ID: <CAKfTPtB4G3bP5N0hU6zWXJTddO34x3RnyGpp-4_otc8O=Wq2hw@mail.gmail.com>

On 4 February 2016 at 10:36, Morten Rasmussen <morten.rasmussen at arm.com> wrote:
> On Wed, Feb 03, 2016 at 10:04:37PM +0100, Vincent Guittot wrote:
>> On 3 February 2016 at 12:59, Juri Lelli <juri.lelli at arm.com> wrote:

[snip]

>> > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> > index 9e63fb1..c4025fd 100644
>> > --- a/drivers/cpufreq/Makefile
>> > +++ b/drivers/cpufreq/Makefile
>> > @@ -1,5 +1,5 @@
>> >  # CPUfreq core
>> > -obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o
>> > +obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o cpufreq_capacity.o
>>
>> Do you really want to have the calibration of capacity dependent of
>> cpufreq ? It means that we can't use it without a cpufreq driver.
>> IMHO, this creates a unnecessary dependency. I understand that you
>> must ensure that core runs at max fequency if a driver is present but
>> you should be able to calibrate the capacity if cpufreq is not
>> available but you have different capacity because micro architecture
>
> We could remove the dependency on cpufreq, but it would make things more
> complicated for systems which do have frequency scaling as we would have
> to either:
>
> 1) Run the calibration again once cpufreq has been initialized.

or wait and let time for a driver to initialize and trig the
calibration. If calibration has not been done at the end of the boot,
you can force a calibration. If the cpufeq driver is a module and is
loaded far later for any good or bad reason, we will have to run the
calibration once again but at least the capacity will reflect he
current capacity of the CPUs.
I'm mainly worried that the compilation of the calibration is
dependent of CONFIG_CPU_FREQ not that cpufreq can trig the calibration
sequence

>
> 2) Know the frequency of all cpus at calibration time so we can
> determine the correct micro-archicture difference. This option would
> however mean that we have to provide a frequency scaling factor even for
> systems that don't have cpufreq.
>
> 3) Find a way to do the calibration anyway if cpufreq doesn't
> initialize. I'm not sure how that would work though.


From dledford at redhat.com  Thu Feb  4 04:15:05 2016
From: dledford at redhat.com (Doug Ledford)
Date: Thu, 4 Feb 2016 07:15:05 -0500
Subject: [PATCH] staging: amso1100: fix format string for 64-bit phys_addr
In-Reply-To: <2307631.X1DYNXxKPZ@wuerfel>
References: <2307631.X1DYNXxKPZ@wuerfel>
Message-ID: <56B340C9.2060303@redhat.com>

On 02/01/2016 11:34 AM, Arnd Bergmann wrote:
> The amso1100 driver prints a phys_addr_t by casting it to a pointer,
> which causes a warning when phys_addr_t is 64-bit and pointers
> are 32-bit:
> 
> drivers/staging/rdma/amso1100/c2.c: In function 'c2_rx_error':
> drivers/staging/rdma/amso1100/c2.c:430:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> 
> This changes the format string to print the address as a 64-bit
> number all the time to avoids the warnings. Ideally we would use
> the %pap format string for phys_addr_t, but that doesn't work
> here easily as it requires passing a pointer to the address.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
> Found on ARM randconfig testing. This must have been there forever but is
> rather hard to trigger even with randconfig builds.
> 
> diff --git a/drivers/staging/rdma/amso1100/c2.c b/drivers/staging/rdma/amso1100/c2.c
> index b46ebd1ae15a..170a42a60552 100644
> --- a/drivers/staging/rdma/amso1100/c2.c
> +++ b/drivers/staging/rdma/amso1100/c2.c
> @@ -426,8 +426,8 @@ static void c2_rx_error(struct c2_port *c2_port, struct c2_element *elem)
>  		pr_debug("    index : %Zu\n",
>  			elem - c2_port->rx_ring.start);
>  		pr_debug("    len   : %u\n", rx_desc->len);
> -		pr_debug("  rxp_hdr : %p [PA %p]\n", rxp_hdr,
> -			(void *) __pa((unsigned long) rxp_hdr));
> +		pr_debug("  rxp_hdr : %p [PA %016llx\n", rxp_hdr,
> +			(u64)__pa((unsigned long) rxp_hdr));
>  		pr_debug("    flags : 0x%x\n", rxp_hdr->flags);
>  		pr_debug("    status: 0x%x\n", rxp_hdr->status);
>  		pr_debug("    len   : %u\n", rxp_hdr->len);
> 

I've sent off a deletion of this file to Linus already, sorry.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: 0E572FDD


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/f4c4bc6a/attachment.sig>

From juri.lelli at arm.com  Thu Feb  4 04:16:20 2016
From: juri.lelli at arm.com (Juri Lelli)
Date: Thu, 4 Feb 2016 12:16:20 +0000
Subject: [PATCH v3 2/6] drivers/cpufreq: implement
 init_cpu_capacity_default()
In-Reply-To: <CAKfTPtB4G3bP5N0hU6zWXJTddO34x3RnyGpp-4_otc8O=Wq2hw@mail.gmail.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <1454500799-18451-3-git-send-email-juri.lelli@arm.com>
 <CAKfTPtDGk5BC25WqHdhDYDOBgUsuidAMhrXS=eDi6wJPZjfrwA@mail.gmail.com>
 <20160204093559.GA14099@e105550-lin.cambridge.arm.com>
 <CAKfTPtB4G3bP5N0hU6zWXJTddO34x3RnyGpp-4_otc8O=Wq2hw@mail.gmail.com>
Message-ID: <20160204121620.GB29586@e106622-lin>

Hi Vincent,

On 04/02/16 13:03, Vincent Guittot wrote:
> On 4 February 2016 at 10:36, Morten Rasmussen <morten.rasmussen at arm.com> wrote:
> > On Wed, Feb 03, 2016 at 10:04:37PM +0100, Vincent Guittot wrote:
> >> On 3 February 2016 at 12:59, Juri Lelli <juri.lelli at arm.com> wrote:
> 
> [snip]
> 
> >> > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> >> > index 9e63fb1..c4025fd 100644
> >> > --- a/drivers/cpufreq/Makefile
> >> > +++ b/drivers/cpufreq/Makefile
> >> > @@ -1,5 +1,5 @@
> >> >  # CPUfreq core
> >> > -obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o
> >> > +obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o cpufreq_capacity.o
> >>
> >> Do you really want to have the calibration of capacity dependent of
> >> cpufreq ? It means that we can't use it without a cpufreq driver.
> >> IMHO, this creates a unnecessary dependency. I understand that you
> >> must ensure that core runs at max fequency if a driver is present but
> >> you should be able to calibrate the capacity if cpufreq is not
> >> available but you have different capacity because micro architecture
> >
> > We could remove the dependency on cpufreq, but it would make things more
> > complicated for systems which do have frequency scaling as we would have
> > to either:
> >
> > 1) Run the calibration again once cpufreq has been initialized.
> 
> or wait and let time for a driver to initialize and trig the
> calibration. If calibration has not been done at the end of the boot,
> you can force a calibration. If the cpufeq driver is a module and is
> loaded far later for any good or bad reason, we will have to run the
> calibration once again but at least the capacity will reflect he
> current capacity of the CPUs.
> I'm mainly worried that the compilation of the calibration is
> dependent of CONFIG_CPU_FREQ not that cpufreq can trig the calibration
> sequence
> 

Yes, I guess we can make this work in some way. Out of curiosity,
though, are out there heterogenous platforms that don't use cpufreq?
I mean, I wouldn't add code and complexity from start, if there are not
good reasons to do so.

Thanks,

- Juri


From maxime.ripard at free-electrons.com  Thu Feb  4 04:08:17 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 4 Feb 2016 13:08:17 +0100
Subject: [PATCH 2/5] clk: sunxi: Make clocks setup functions take const
 pointer
In-Reply-To: <1454402834-6385-3-git-send-email-maxime.ripard@free-electrons.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454402834-6385-3-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20160204120817.GE4270@lukather>

On Tue, Feb 02, 2016 at 09:47:11AM +0100, Maxime Ripard wrote:
> All the data structure that we pass to the clocks setup functions are
> declared const, while our setup functions expects a regular pointer. This
> was hidden by the fact that we cast a void * pointer back to these
> structures, which made it go unnoticed.
> 
> Fix the functions prototype.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Applied with Andre and Chen-Yu Acked-by's

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/b27f5495/attachment-0001.sig>

From maxime.ripard at free-electrons.com  Thu Feb  4 04:05:07 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 4 Feb 2016 13:05:07 +0100
Subject: [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused
In-Reply-To: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20160204120507.GC4270@lukather>

On Mon, Feb 01, 2016 at 09:20:00PM +0100, Maxime Ripard wrote:
> Remove the fixed dividers from the PLL6 driver to be able to have a
> reusable driver that can be used across several SoCs that share the same
> controller, but don't have the same set of dividers for this clock, and to
> also be reused multiple times in the same SoC, since we're droping the
> clock name.
> 
> Acked-by: Chen-Yu Tsai <wens at csie.org>
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Applied.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/92ce1654/attachment.sig>

From maxime.ripard at free-electrons.com  Thu Feb  4 04:07:38 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 4 Feb 2016 13:07:38 +0100
Subject: [PATCH 1/5] clk: sunxi: Make clocks setup functions return their
 clock
In-Reply-To: <1454402834-6385-2-git-send-email-maxime.ripard@free-electrons.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454402834-6385-2-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20160204120738.GD4270@lukather>

On Tue, Feb 02, 2016 at 09:47:10AM +0100, Maxime Ripard wrote:
> The clocks registration code in clk-sunxi was most of the time not
> returning the struct clk (or struct clk array) that was registered,
> preventing the users of such functions to manipulate it, for example to
> protect it.
> 
> Make them return it so that we can start using it.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

After discussing it with Chen-Yu on IRC, the error logging will be
done as a subsequent patch.

Applied.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/72a9f1ac/attachment.sig>

From maxime.ripard at free-electrons.com  Thu Feb  4 04:04:07 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 4 Feb 2016 13:04:07 +0100
Subject: [PATCH 06/14] ARM: dts: sun8i-a83t: Correct low speed oscillator
 clocks
In-Reply-To: <CAEzqOZvcy58T_uxvymGxuQXh_Goj3yHmgkmL4VL+x2_bycMgNg@mail.gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-7-git-send-email-vishnupatekar0510@gmail.com>
 <20160202131947.GS4652@lukather>
 <CAEzqOZvcy58T_uxvymGxuQXh_Goj3yHmgkmL4VL+x2_bycMgNg@mail.gmail.com>
Message-ID: <20160204120407.GB4270@lukather>

On Thu, Feb 04, 2016 at 04:51:06PM +0800, Vishnu Patekar wrote:
> Hello Maxime,
> 
> 
> On Tue, Feb 2, 2016 at 9:19 PM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > On Sun, Jan 31, 2016 at 09:20:58AM +0800, Vishnu Patekar wrote:
> >> From: Chen-Yu Tsai <wens at csie.org>
> >>
> >> The A83T does not have a 32.768 kHz low speed oscillator, either as
> >> an external crystal or input. It has a 16 MHz RC-based (inaccurate)
> >> internal oscillator, which is then divided by 512 for a clock close
> >> to 32 kHz.
> >>
> >> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
> >
> > You should have your SoB here.
> >
> > Is it ok to add it?
> Yes, please add.

Done, thanks.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/728bb909/attachment.sig>

From maxime.ripard at free-electrons.com  Thu Feb  4 04:15:57 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 4 Feb 2016 13:15:57 +0100
Subject: [PATCH 4/5] clk: sunxi: Remove old probe and protection code
In-Reply-To: <1454402834-6385-5-git-send-email-maxime.ripard@free-electrons.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454402834-6385-5-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20160204121557.GG4270@lukather>

On Tue, Feb 02, 2016 at 09:47:13AM +0100, Maxime Ripard wrote:
> Now that we don't have any user left for the old registration code, we can
> remove it.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Applied.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/dbb69dad/attachment.sig>

From maxime.ripard at free-electrons.com  Thu Feb  4 04:17:13 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 4 Feb 2016 13:17:13 +0100
Subject: [PATCH 5/5] clk: sunxi: Remove clk_register_clkdev calls
In-Reply-To: <1454402834-6385-6-git-send-email-maxime.ripard@free-electrons.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454402834-6385-6-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20160204121713.GH4270@lukather>

On Tue, Feb 02, 2016 at 09:47:14AM +0100, Maxime Ripard wrote:
> Now that our protection code doesn't use the global name lookup anymore, we
> can remove the clkdev registrations.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Applied.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/0ddf838d/attachment.sig>

From maxime.ripard at free-electrons.com  Thu Feb  4 04:13:48 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 4 Feb 2016 13:13:48 +0100
Subject: [PATCH 3/5] clk: sunxi: convert current clocks registration to
 CLK_OF_DECLARE
In-Reply-To: <1454402834-6385-4-git-send-email-maxime.ripard@free-electrons.com>
References: <1454402834-6385-1-git-send-email-maxime.ripard@free-electrons.com>
 <1454402834-6385-4-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <20160204121348.GF4270@lukather>

On Tue, Feb 02, 2016 at 09:47:12AM +0100, Maxime Ripard wrote:
> The current clock registration and protection code has a few drawbacks, the
> two main ones being that we create a lot of orphans clock in the
> registration phase, which will be troublesome when we will start being less
> relaxed about them.
> 
> The protection code also relies on clkdev, which we don't really use but
> for this particular case.
> 
> Fix both at the same time by moving everyone to the CLK_OF_DECLARE that
> will probe our clock tree in the right and thus avoid orphans, and by
> protecting directly the clock returned by our registration function.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Fixed the issue reported by Andre, and applied.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/d458471c/attachment.sig>

From Jean-Philippe.Brucker at arm.com  Thu Feb  4 04:28:05 2016
From: Jean-Philippe.Brucker at arm.com (Jean-Philippe Brucker)
Date: Thu, 4 Feb 2016 12:28:05 +0000
Subject: [RFC PATCH 1/2] ARM: deprecate old APCS frame format
In-Reply-To: <20160201175907.GW10826@n2100.arm.linux.org.uk>
References: <1453741521-6878-1-git-send-email-jean-philippe.brucker@arm.com>
 <1453741521-6878-2-git-send-email-jean-philippe.brucker@arm.com>
 <20160201175907.GW10826@n2100.arm.linux.org.uk>
Message-ID: <20160204122805.GA18502@e106794-lin.cambridge.arm.com>

Russell,

On Mon, Feb 01, 2016 at 05:59:07PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 25, 2016 at 05:05:20PM +0000, Jean-Philippe Brucker wrote:
> > GCC 5 deprecated option -mapcs-frame, which generated frames following
> > the old ABI format. In preparation for a possible removal in future
> > versions of GCC, deprecate use of this flag in Linux as well.
> > 
> > Instead of completely removing the bits that depend on APCS frame, we
> > move them behind a DEPRECATED config option to smoothen the transition.
> > 
> > Neither AAPCS nor EABI guarantees any frame format, so only ARM_UNWIND
> > should now be used for stack traces and introspection. It is already
> > selected by most defconfigs.
> > Furthermore, frames currently generated by GCC are different for leaf
> > and non-leaf functions, which would make adaptation quite tricky.
> 
> As I mentioned on the call last week, I'm not happy with deprecating
> APCS frames.  The unwinder does not always work, and each time the
> unwinder fails to work, it creates more work.
> 
> The latest scenario can be found in the "[PATCH 1/2] ARM: make
> virt_to_idmap() return unsigned long" thread, where we have a
> failure to unwind the first oops - unwinding stops for apparently
> no reason after the first frame.

I spent some time trying to break the unwinder this week. The only
possibility I found so far is that the oops is triggered before the
function stack is stable.
I don't think it happens in your example, since lr couldn't be on
spin_unlock, but I will still describe that case because it is a bit
worrying.

My GCC 4.9 generates the following prologue for driver_unregister in a
Thumb2 kernel:

    801fd194 <driver_unregister>
    cbz     r0, 801fd1b0        <driver_unregister+0x1c>
    ldr     r3, [r0, #60]
    cbz     r3, 801fd1b0        <driver_unregister+0x1c>
    push    {r4, lr}

If the second instruction faults, we won't get a proper trace, because
the unwinder will find the following entry in the unwind table, and
assume r4 and lr are already on the stack:

    $ readelf -u vmlinux
    ...
    0x801fd194 <driver_unregister>: 0x80a8b0b0
    Compact model 0
    0xa8      pop {r4, r14}
    0xb0      finish
    ...

I might have missed something in the ABI, but if there's no possible way
to handle this case properly in unwind.c, we need to sort it out with
the GCC people.
I found similar constructions in kernels generated with GCC 4.6 and 5.1.

> So, we have no idea how tasket_action() got called.
> 
> My current idea on that oops is... I have no idea, and the only way
> to get more of an idea would be to request a rebuild with thumb
> disabled and frame pointers enabled, and for the problem to be
> reproduced.
> 
> This is the issue: APCS frame pointer based backtracing works every
> time.  The unwinder is and always has been unreliable.
> 
> GCC people need to think about this, because if they persue, we're
> going to end up having to tell people to rebuild their kernels with
> older GCC versions just to get debug information out of them, unless
> the quality of the unwinder and unwind information can be improved.
> 
> However, having experienced the "quality" of gdb over the last five
> years in userspace, I'm really not hopeful that there is a solution
> that works using the unwind information: I suspect there's a great
> number of cases where the unwind information is basically wrong or
> otherwise broken.
> 
> The problem with unwind based solutions is the only time you know
> that the unwinding information is broken is when the code goes wrong
> and the unwind information has to be used.  The nice thing about the
> frame-pointer based solution is that it's correctness is an inherent
> requirement for the program to work, so any problem with a frame-
> pointer based solution shows up as a program crash.
> 
> This is probably the root cause why the unwind based backtracing
> tends to fail.
> 
[...]
> 
> If we can't get a good backtrace, it limits those who can diagnose
> the case of the failure, which really isn't good.
> 

The current unwinder code also doesn't handle recursive calls (e.g.
of_platform_bus_create). There is room for improvement, and we probably
need to come up with a good self-test infrastructure before that
EXPERIMENTAL qualifier can be removed.
I agree that unwinding is not ready, which is one of the main reasons we
can't get rid of the -mapcs flag quite yet. However, I believe most
kernels out there already use ARM_UNWIND by default.

The other reason we can't remove -mapcs is that FUNCTION_GRAPH_TRACER
depends solely on the APCS frame at the moment, and is not easy to
change.
During my tests, I hacked function_graph to work with unwinding info.
It is a terrible solution because of the massive overhead it introduces
for each function call.
But the resulting graphs are the same as the ones generated using APCS
frames, which means that unwinding info are not too far from being
reliable.
I think we need to gather a comprehensive list of broken cases before we
can argue against unwinding to GCC people and ask for something more
reliable, but it does seem like we'll need a better solution for traces.

The problem is that -mapcs is not coming back as is, since it relies on
deprecated instructions. The motivation behind my series (apart from
starting this discussion) is to prevent people from introducing more
features that rely on it, while we work with GCC people to improve the
backtrace.

> What we _might_ end up having to do is to walk every word on the
> kernel stack, check whether it's in a module .text or kernel .text,
> and print it as a "best guess" at a backtrace, but that will be
> very misleading, as registers contain pointers to literal data,
> which can be located not only at the end of a function, but also
> the middle of a function, and that can end up on the stack too.

I really hope it won't come to that...

Thanks,
Jean-Philippe


From vincent.guittot at linaro.org  Thu Feb  4 04:35:35 2016
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 4 Feb 2016 13:35:35 +0100
Subject: [PATCH v3 2/6] drivers/cpufreq: implement
 init_cpu_capacity_default()
In-Reply-To: <20160204121620.GB29586@e106622-lin>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <1454500799-18451-3-git-send-email-juri.lelli@arm.com>
 <CAKfTPtDGk5BC25WqHdhDYDOBgUsuidAMhrXS=eDi6wJPZjfrwA@mail.gmail.com>
 <20160204093559.GA14099@e105550-lin.cambridge.arm.com>
 <CAKfTPtB4G3bP5N0hU6zWXJTddO34x3RnyGpp-4_otc8O=Wq2hw@mail.gmail.com>
 <20160204121620.GB29586@e106622-lin>
Message-ID: <CAKfTPtDVasamRtG2kLxP0HsohmVQTPrXRgx36e+jb3gozDoo6g@mail.gmail.com>

On 4 February 2016 at 13:16, Juri Lelli <juri.lelli at arm.com> wrote:
> Hi Vincent,
>
> On 04/02/16 13:03, Vincent Guittot wrote:
>> On 4 February 2016 at 10:36, Morten Rasmussen <morten.rasmussen at arm.com> wrote:
>> > On Wed, Feb 03, 2016 at 10:04:37PM +0100, Vincent Guittot wrote:
>> >> On 3 February 2016 at 12:59, Juri Lelli <juri.lelli at arm.com> wrote:
>>
>> [snip]
>>
>> >> > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> >> > index 9e63fb1..c4025fd 100644
>> >> > --- a/drivers/cpufreq/Makefile
>> >> > +++ b/drivers/cpufreq/Makefile
>> >> > @@ -1,5 +1,5 @@
>> >> >  # CPUfreq core
>> >> > -obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o
>> >> > +obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o cpufreq_capacity.o
>> >>
>> >> Do you really want to have the calibration of capacity dependent of
>> >> cpufreq ? It means that we can't use it without a cpufreq driver.
>> >> IMHO, this creates a unnecessary dependency. I understand that you
>> >> must ensure that core runs at max fequency if a driver is present but
>> >> you should be able to calibrate the capacity if cpufreq is not
>> >> available but you have different capacity because micro architecture
>> >
>> > We could remove the dependency on cpufreq, but it would make things more
>> > complicated for systems which do have frequency scaling as we would have
>> > to either:
>> >
>> > 1) Run the calibration again once cpufreq has been initialized.
>>
>> or wait and let time for a driver to initialize and trig the
>> calibration. If calibration has not been done at the end of the boot,
>> you can force a calibration. If the cpufeq driver is a module and is
>> loaded far later for any good or bad reason, we will have to run the
>> calibration once again but at least the capacity will reflect he
>> current capacity of the CPUs.
>> I'm mainly worried that the compilation of the calibration is
>> dependent of CONFIG_CPU_FREQ not that cpufreq can trig the calibration
>> sequence
>>
>
> Yes, I guess we can make this work in some way. Out of curiosity,
> though, are out there heterogenous platforms that don't use cpufreq?

At least, you can find several heterogeneous platforms without OPP
table for CPUs in the kernel. That's probably a temporary situation
but which can become a permanent one. It means that we can't calibrate
the CPUs for these platforms.

Thanks,
Vincent

> I mean, I wouldn't add code and complexity from start, if there are not
> good reasons to do so.
>
> Thanks,
>
> - Juri


From arnd at arndb.de  Thu Feb  4 05:07:53 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 04 Feb 2016 14:07:53 +0100
Subject: [PATCH] staging: amso1100: fix format string for 64-bit phys_addr
In-Reply-To: <56B340C9.2060303@redhat.com>
References: <2307631.X1DYNXxKPZ@wuerfel> <56B340C9.2060303@redhat.com>
Message-ID: <5022285.uJY04l8BmE@wuerfel>

On Thursday 04 February 2016 07:15:05 Doug Ledford wrote:
> I've sent off a deletion of this file to Linus already, sorry.
> 

Even better, thanks!

	Arnd


From arnd at arndb.de  Thu Feb  4 05:11:32 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 04 Feb 2016 14:11:32 +0100
Subject: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host
 Controllers
In-Reply-To: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
References: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
Message-ID: <2387127.DMZaDnZvEW@wuerfel>

On Thursday 04 February 2016 19:37:36 Gabriele Paoloni wrote:
> From: gabriele paoloni <gabriele.paoloni at huawei.com>
> 
> This patchset adds ACPI support for the HiSilicon Hip05/Hip06 SoC PCIe controllers
> The four patches respectively:
>         - rework PCie Designware to be used for ACPI PCI Host controllers
>         - re-architect the current HiSilicon driver to make it scalable to the
>           new ACPI quirks
>         - rework the current HiSilicon driver to make it ECAM compliant
>         - adds the HiSilicon ACPI specific quirks.
> 
>    This patchset  is based on 
>    https://github.com/semihalf-nowicki-tomasz/linux.git
>    branch pci-acpi-v3 + Hip06 support applied on top:
>    https://patchwork.ozlabs.org/patch/549198/
> 

ACPI has its own PCI support, and should not need drivers for host
bridges. I don't think we can really mix the two things, as ACPI
needs to have access to things like PCI config space way before
we are probing normal device drivers.

Please put this in drivers/acpi/pci*.c.

	Arnd


From grygorii.strashko at ti.com  Thu Feb  4 05:14:31 2016
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Thu, 4 Feb 2016 15:14:31 +0200
Subject: [PATCH 3/3] ARM: OMAP2+: remove misuse of IRQF_NO_SUSPEND flag
In-Reply-To: <1454351299-27440-4-git-send-email-sudeep.holla@arm.com>
References: <1454351299-27440-1-git-send-email-sudeep.holla@arm.com>
 <1454351299-27440-4-git-send-email-sudeep.holla@arm.com>
Message-ID: <56B34EB7.4080005@ti.com>

Hi Sudeep,

On 02/01/2016 08:28 PM, Sudeep Holla wrote:
> The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
> be left enabled so as to allow them to work as expected during the
> suspend-resume cycle, but doesn't guarantee that it will wake the system
> from a suspended state, enable_irq_wake is recommended to be used for
> the wakeup.
> 
> This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
> enable_irq_wake instead.

And sorry for delayed reply - I've spent some time investigating it, but
It was during Christmas holidays and finally I lost track of it :)

So, what we have:
1) bad news: it will not work :(

The PRCM wake up is handled in the following way on OMAP3+
-- PRCM IRQ omap_prcm_irq_handler()
   |- (a) "wkup" event -> _prcm_int_handle_wakeup()
   |- "io" event (shared)
       |- (b) _prcm_int_handle_io()
       |- (c) pcs_irq_handler()
(mux is for legacy platform - can be ignored for now)

All "wkup"/"io" events must be handled in PRCM registers before
PRCM IRQ status bits can be acked and reset.

It means that all IRQs (a), (b) (c) have to be enabled at the
moment when PRCM IRQ is fired. Unfortunately this can't be 
guaranteed by IR PM core and omap_prcm_irq_handler() 
will stuck forever on Resume :(.

Resume example:
 omap_prcm_irq_handler()
[1] -> prcm_irq_setup->read_pending_irqs(pending);
    -> is there pending irqs?
	-> io event
	    -> (c) pcs_irq (enabled | wakeup src)
		-> irq_pm_check_wakeup() 
		   -> (disabled | suspended| pending)
			pcs_irq_handler() not run
   ->  goto [1] ----- OOps dead-loop
	  

2) Potential good news: It could be fixed the same way as it's done
omap34xx (and as it was before :

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 58920bc..a0f8265 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -221,8 +221,7 @@ static int omap_pm_enter(suspend_state_t suspend_state)
 static int omap_pm_begin(suspend_state_t state)
 {
        cpu_idle_poll_ctrl(true);
-       if (cpu_is_omap34xx())
-               omap_prcm_irq_prepare();
+       omap_prcm_irq_prepare();
        return 0;
 }
 
@@ -233,8 +232,7 @@ static void omap_pm_end(void)
 
 static void omap_pm_finish(void)
 {
-       if (cpu_is_omap34xx())
-               omap_prcm_irq_complete();
+       omap_prcm_irq_complete();
 }

Another option is to convert omap_prcm_irq_handler to the generic handler
(now chained) and, probably, make it threaded and all cascaded IRQs as
nested threaded (this is just a theory).

I'll be on business trip next two weeks and will not be able to help more with it
Sorry.



> 
> Cc: Grygorii Strashko <grygorii.strashko at ti.com>
> Cc: Tony Lindgren <tony at atomide.com>
> Cc: linux-omap at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
> ---
>   arch/arm/mach-omap2/mux.c        | 4 ++--
>   arch/arm/mach-omap2/pm34xx.c     | 9 ++++-----
>   arch/arm/mach-omap2/prm_common.c | 1 +
>   3 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index 176eef6ef338..12012bef8e63 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -810,13 +810,13 @@ int __init omap_mux_late_init(void)
>   		return 0;
>   
>   	ret = request_irq(omap_prcm_event_to_irq("io"),
> -		omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
> +		omap_hwmod_mux_handle_irq, IRQF_SHARED,
>   			"hwmod_io", omap_mux_late_init);
>   
>   	if (ret)
>   		pr_warn("mux: Failed to setup hwmod io irq %d\n", ret);
>   
> -	return 0;
> +	return enable_irq_wake(omap_prcm_event_to_irq("io"));
>   }
>   
>   static void __init omap_mux_package_fixup(struct omap_mux *p,
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 2dbd3785ee6f..49604e0023c4 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -472,23 +472,22 @@ int __init omap3_pm_init(void)
>   	prcm_setup_regs();
>   
>   	ret = request_irq(omap_prcm_event_to_irq("wkup"),
> -		_prcm_int_handle_wakeup, IRQF_NO_SUSPEND, "pm_wkup", NULL);
> +		_prcm_int_handle_wakeup, 0, "pm_wkup", NULL);
>   
>   	if (ret) {
>   		pr_err("pm: Failed to request pm_wkup irq\n");
>   		goto err1;
>   	}
> +	enable_irq_wake(omap_prcm_event_to_irq("wkup"));
>   
>   	/* IO interrupt is shared with mux code */
>   	ret = request_irq(omap_prcm_event_to_irq("io"),
> -		_prcm_int_handle_io, IRQF_SHARED | IRQF_NO_SUSPEND, "pm_io",
> -		omap3_pm_init);
> -	enable_irq(omap_prcm_event_to_irq("io"));
> -
> +		_prcm_int_handle_io, IRQF_SHARED, "pm_io", omap3_pm_init);
>   	if (ret) {
>   		pr_err("pm: Failed to request pm_io irq\n");
>   		goto err2;
>   	}
> +	enable_irq_wake(omap_prcm_event_to_irq("io"));
>   
>   	ret = pwrdm_for_each(pwrdms_setup, NULL);
>   	if (ret) {
> diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
> index 5b2f5138d938..7af688273e0d 100644
> --- a/arch/arm/mach-omap2/prm_common.c
> +++ b/arch/arm/mach-omap2/prm_common.c
> @@ -338,6 +338,7 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
>   		ct->chip.irq_ack = irq_gc_ack_set_bit;
>   		ct->chip.irq_mask = irq_gc_mask_clr_bit;
>   		ct->chip.irq_unmask = irq_gc_mask_set_bit;
> +		ct->chip.flags = IRQCHIP_SKIP_SET_WAKE;
>   
>   		ct->regs.ack = irq_setup->ack + i * 4;
>   		ct->regs.mask = irq_setup->mask + i * 4;
> 


-- 
regards,
-grygorii


From Wenyou.Yang at atmel.com  Thu Feb  4 05:28:57 2016
From: Wenyou.Yang at atmel.com (Yang, Wenyou)
Date: Thu, 4 Feb 2016 13:28:57 +0000
Subject: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
 ACT8945A
In-Reply-To: <20160203174753.GJ4455@sirena.org.uk>
References: <1453863463-30515-1-git-send-email-wenyou.yang@atmel.com>
 <1453863463-30515-2-git-send-email-wenyou.yang@atmel.com>
 <20160129001603.GM4130@sirena.org.uk>
 <B256D81BAE5131468A838E5D7A243641D63FBF8B@penmbx01>
 <20160129113518.GQ4130@sirena.org.uk>
 <CABxcv=kNKmgRytxB5ppawrAvC-GDRhV4T_UUGvpHgKp9+BsUmQ@mail.gmail.com>
 <B256D81BAE5131468A838E5D7A243641D63FE2C7@penmbx01>
 <CABxcv=nJsWEv9KW-5iPpUnyN8ZVpx6CV07gBRaLNWqd644YOqQ@mail.gmail.com>
 <B256D81BAE5131468A838E5D7A243641D64026CB@penmbx01>
 <20160203174753.GJ4455@sirena.org.uk>
Message-ID: <B256D81BAE5131468A838E5D7A243641D64062A0@penmbx01>



> -----Original Message-----
> From: Mark Brown [mailto:broonie at kernel.org]
> Sent: 2016?2?4? 1:48
> To: Yang, Wenyou <Wenyou.Yang at atmel.com>
> Cc: Javier Martinez Canillas <javier at dowhile0.org>; Liam Girdwood
> <lgirdwood at gmail.com>; Rob Herring <robh+dt at kernel.org>; Pawel Moll
> <pawel.moll at arm.com>; Ian Campbell <ijc+devicetree at hellion.org.uk>; Kumar
> Gala <galak at codeaurora.org>; Krzysztof Kozlowski
> <k.kozlowski at samsung.com>; Lee Jones <lee.jones at linaro.org>; Peter
> Korsgaard <jacmet at gmail.com>; Ferre, Nicolas <Nicolas.FERRE at atmel.com>;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org
> Subject: Re: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
> ACT8945A
> 
> On Wed, Feb 03, 2016 at 02:33:11AM +0000, Yang, Wenyou wrote:
> 
> > > I would just remove the "active-semi,act8945a-regulator" node and
> > > make "active- semi,vsel-high" a property of the "active-semi,act8945a" node.
> > > That way you can remove the mfd cell .of_compatible and OF table in
> > > the regulator driver and read the "active-semi,vsel-high" using the
> > > platform device's parent of_node.
> 
> > > But it's better if you wait for Mark's opinions before re-spining your patches.
> 
> > Hi Mark, what is your opinions?
> 
> Like Javier says you should make your DT binding look like the DT bindings for
> other MFDs and not use of_compatible.

All right.

Thank you, Mark, Javier.


Best Regards,
Wenyou Yang

From sudeep.holla at arm.com  Thu Feb  4 05:34:28 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Thu, 4 Feb 2016 13:34:28 +0000
Subject: [PATCH 3/3] ARM: OMAP2+: remove misuse of IRQF_NO_SUSPEND flag
In-Reply-To: <56B34EB7.4080005@ti.com>
References: <1454351299-27440-1-git-send-email-sudeep.holla@arm.com>
 <1454351299-27440-4-git-send-email-sudeep.holla@arm.com>
 <56B34EB7.4080005@ti.com>
Message-ID: <56B35364.8090104@arm.com>



On 04/02/16 13:14, Grygorii Strashko wrote:
> Hi Sudeep,
>
> On 02/01/2016 08:28 PM, Sudeep Holla wrote:
>> The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
>> be left enabled so as to allow them to work as expected during the
>> suspend-resume cycle, but doesn't guarantee that it will wake the system
>> from a suspended state, enable_irq_wake is recommended to be used for
>> the wakeup.
>>
>> This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
>> enable_irq_wake instead.
>
> And sorry for delayed reply - I've spent some time investigating it, but
> It was during Christmas holidays and finally I lost track of it :)
>

That's fine, usually that's the case in general will all of us :)

[..]
>
> Another option is to convert omap_prcm_irq_handler to the generic handler
> (now chained) and, probably, make it threaded and all cascaded IRQs as
> nested threaded (this is just a theory).
>

Since I don't have any knowledge of OMAP, I will completely depend on
your for anything OMAP specific.

> I'll be on business trip next two weeks and will not be able to help more with it
> Sorry.
>

No problem, let me know once you get a chance to try out things at your end.

-- 
Regards,
Sudeep


From bcrl at kvack.org  Thu Feb  4 05:41:42 2016
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Thu, 4 Feb 2016 08:41:42 -0500
Subject: linux-next: build failure after merge of the aio tree
In-Reply-To: <20160204131959.6695c7bf@canb.auug.org.au>
References: <20160112164034.0fe945a7@canb.auug.org.au>
 <20160112163835.GD347@kvack.org> <20160127134024.0fababf6@canb.auug.org.au>
 <20160129113056.GP10826@n2100.arm.linux.org.uk>
 <CAMuHMdUy-cqeN8COO4rdpY-mOH+6gth40wB31-edkj8CO5PFCw@mail.gmail.com>
 <20160204131959.6695c7bf@canb.auug.org.au>
Message-ID: <20160204134142.GA16315@kvack.org>

On Thu, Feb 04, 2016 at 01:19:59PM +1100, Stephen Rothwell wrote:
> Hi Benjamin,
> 
> On Fri, 29 Jan 2016 13:03:39 +0100 Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> >
> > On Fri, Jan 29, 2016 at 12:30 PM, Russell King - ARM Linux
> > <linux at arm.linux.org.uk> wrote:
> > >> Background: new aio code is adding __get_user() calls referencing 64
> > >> bit quantities (__u64 and __s64).  
> > >
> > > There's lots more architectures which do not support 64-bit get_user()
> > > _or_ __get_user(): avr32, blackfin, metag for example, and m68k which
> > > has this interesting thing "/* case 8: disabled because gcc-4.1 has a
> > > broken typeof \" in its *get_user() implementation.  
> > 
> > And if you enable it again, you get lots of "warning: cast to pointer from
> > integer of different size", like you mentioned.
> 
> Any thoughts?  I am still using the version of tha aio tree from
> next-20160111.

I am still convinced that this is an architecture issue.  Given that 64 bit 
values work in the *get_user implementations on other architectures, I see 
no reason there should need to be a workaround for this in common code.

		-ben

> -- 
> Cheers,
> Stephen Rothwell

-- 
"Thought is the essence of where you are now."


From timur at codeaurora.org  Thu Feb  4 05:48:08 2016
From: timur at codeaurora.org (Timur Tabi)
Date: Thu, 4 Feb 2016 07:48:08 -0600
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <56B2DEE4.7060901@roeck-us.net>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
 <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
 <56B2DEE4.7060901@roeck-us.net>
Message-ID: <56B35698.4020100@codeaurora.org>

Guenter Roeck wrote:
> Also, if panic is enabled, the timeout needs to be adjusted accordingly
> (to only panic after the entire timeout period has expired, not after
> half of it). We can not panic the system after timeout / 2.

It's a debugging feature, not an actual watchdog timeout panic.  That's 
why it's disabled by default.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.


From matthias.bgg at gmail.com  Thu Feb  4 05:48:58 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 4 Feb 2016 14:48:58 +0100
Subject: [PATCH v3 4/5] pinctrl: mediatek: Add Pinctrl/GPIO/EINT driver
 for mt2701
In-Reply-To: <1451290066.11129.4.camel@mtksdaap41>
References: <1451286546-5920-1-git-send-email-biao.huang@mediatek.com>
 <1451286546-5920-5-git-send-email-biao.huang@mediatek.com>
 <1451290066.11129.4.camel@mtksdaap41>
Message-ID: <56B356CA.1010200@gmail.com>



On 28/12/15 09:07, Yingjoe Chen wrote:
> On Mon, 2015-12-28 at 15:09 +0800, Biao Huang wrote:
>> Add mt2701 support using mediatek common pinctrl driver.
>> MT2701 have some special pins need an extra setting register
>> than other ICs, so adding this support to common code.
>>
>> Signed-off-by: Biao Huang <biao.huang at mediatek.com>
>> Acked-by: Yingjoe Chen <yingjoe.chen at mediatek.com>
> <...>
>> +
>> +static struct platform_driver mtk_pinctrl_driver = {
>> +	.probe = mt2701_pinctrl_probe,
>> +	.driver = {
>> +		.name = "mediatek-mt2701-pinctrl",
>> +		.owner = THIS_MODULE,
>> +		.of_match_table = mt2701_pctrl_match,
>> +	},
>> +};
>> +
>> +static int __init mtk_pinctrl_init(void)
>> +{
>> +	return platform_driver_register(&mtk_pinctrl_driver);
>> +}
>> +
>> +arch_initcall(mtk_pinctrl_init);
>
>
> As discussed in
> http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003350.html
> we should use subsys_initcall() instead.
>
>
>> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
>> index f307f1d..76279f0 100644
>> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
>> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> <...>
>> @@ -347,6 +352,7 @@ static int mtk_pconf_parse_conf(struct pinctrl_dev *pctldev,
>>   		ret = mtk_pconf_set_pull_select(pctl, pin, true, false, arg);
>>   		break;
>>   	case PIN_CONFIG_INPUT_ENABLE:
>> +		mtk_pmx_gpio_set_direction(pctldev, NULL, pin, true);
>>   		ret = mtk_pconf_set_ies_smt(pctl, pin, arg, param);
>>   		break;
>>   	case PIN_CONFIG_OUTPUT:
>> @@ -354,6 +360,7 @@ static int mtk_pconf_parse_conf(struct pinctrl_dev *pctldev,
>>   		ret = mtk_pmx_gpio_set_direction(pctldev, NULL, pin, false);
>>   		break;
>>   	case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
>> +		mtk_pmx_gpio_set_direction(pctldev, NULL, pin, true);
>>   		ret = mtk_pconf_set_ies_smt(pctl, pin, arg, param);
>>   		break;
>>   	case PIN_CONFIG_DRIVE_STRENGTH:
>
> This change is not directly related to adding mt2710 support and change
> behavior for all MTK pinctrl drivers, please create a separate patch for
> this.
>

Hi Biao,

This patch didn't make it into v4.5-rc1. Are you thinking of sending a 
new version addressing the comments from Yingjoe?

Regards,
Matthias


From linux at arm.linux.org.uk  Thu Feb  4 05:50:56 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 4 Feb 2016 13:50:56 +0000
Subject: linux-next: build failure after merge of the aio tree
In-Reply-To: <20160204134142.GA16315@kvack.org>
References: <20160112164034.0fe945a7@canb.auug.org.au>
 <20160112163835.GD347@kvack.org>
 <20160127134024.0fababf6@canb.auug.org.au>
 <20160129113056.GP10826@n2100.arm.linux.org.uk>
 <CAMuHMdUy-cqeN8COO4rdpY-mOH+6gth40wB31-edkj8CO5PFCw@mail.gmail.com>
 <20160204131959.6695c7bf@canb.auug.org.au>
 <20160204134142.GA16315@kvack.org>
Message-ID: <20160204135056.GE10826@n2100.arm.linux.org.uk>

On Thu, Feb 04, 2016 at 08:41:42AM -0500, Benjamin LaHaise wrote:
> On Thu, Feb 04, 2016 at 01:19:59PM +1100, Stephen Rothwell wrote:
> > Hi Benjamin,
> > 
> > On Fri, 29 Jan 2016 13:03:39 +0100 Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> > >
> > > On Fri, Jan 29, 2016 at 12:30 PM, Russell King - ARM Linux
> > > <linux at arm.linux.org.uk> wrote:
> > > >> Background: new aio code is adding __get_user() calls referencing 64
> > > >> bit quantities (__u64 and __s64).  
> > > >
> > > > There's lots more architectures which do not support 64-bit get_user()
> > > > _or_ __get_user(): avr32, blackfin, metag for example, and m68k which
> > > > has this interesting thing "/* case 8: disabled because gcc-4.1 has a
> > > > broken typeof \" in its *get_user() implementation.  
> > > 
> > > And if you enable it again, you get lots of "warning: cast to pointer from
> > > integer of different size", like you mentioned.
> > 
> > Any thoughts?  I am still using the version of tha aio tree from
> > next-20160111.
> 
> I am still convinced that this is an architecture issue.  Given that 64 bit 
> values work in the *get_user implementations on other architectures, I see 
> no reason there should need to be a workaround for this in common code.

So you're happy to break x86-32 then...

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From yingjoe.chen at mediatek.com  Thu Feb  4 05:57:48 2016
From: yingjoe.chen at mediatek.com (Yingjoe Chen)
Date: Thu, 4 Feb 2016 21:57:48 +0800
Subject: [PATCH v3 4/5] pinctrl: mediatek: Add Pinctrl/GPIO/EINT driver
 for mt2701
In-Reply-To: <56B356CA.1010200@gmail.com>
References: <1451286546-5920-1-git-send-email-biao.huang@mediatek.com>
 <1451286546-5920-5-git-send-email-biao.huang@mediatek.com>
 <1451290066.11129.4.camel@mtksdaap41> <56B356CA.1010200@gmail.com>
Message-ID: <1454594268.15541.14.camel@mtksdaap41>

On Thu, 2016-02-04 at 14:48 +0100, Matthias Brugger wrote:
> 
> On 28/12/15 09:07, Yingjoe Chen wrote:
> > On Mon, 2015-12-28 at 15:09 +0800, Biao Huang wrote:
> >> Add mt2701 support using mediatek common pinctrl driver.
> >> MT2701 have some special pins need an extra setting register
> >> than other ICs, so adding this support to common code.
> >>
> >> Signed-off-by: Biao Huang <biao.huang at mediatek.com>
> >> Acked-by: Yingjoe Chen <yingjoe.chen at mediatek.com>
> > <...>
> >> +
> >> +static struct platform_driver mtk_pinctrl_driver = {
> >> +	.probe = mt2701_pinctrl_probe,
> >> +	.driver = {
> >> +		.name = "mediatek-mt2701-pinctrl",
> >> +		.owner = THIS_MODULE,
> >> +		.of_match_table = mt2701_pctrl_match,
> >> +	},
> >> +};
> >> +
> >> +static int __init mtk_pinctrl_init(void)
> >> +{
> >> +	return platform_driver_register(&mtk_pinctrl_driver);
> >> +}
> >> +
> >> +arch_initcall(mtk_pinctrl_init);
> >
> >
> > As discussed in
> > http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003350.html
> > we should use subsys_initcall() instead.
> >
> >
> >> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> >> index f307f1d..76279f0 100644
> >> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> >> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> > <...>
> >> @@ -347,6 +352,7 @@ static int mtk_pconf_parse_conf(struct pinctrl_dev *pctldev,
> >>   		ret = mtk_pconf_set_pull_select(pctl, pin, true, false, arg);
> >>   		break;
> >>   	case PIN_CONFIG_INPUT_ENABLE:
> >> +		mtk_pmx_gpio_set_direction(pctldev, NULL, pin, true);
> >>   		ret = mtk_pconf_set_ies_smt(pctl, pin, arg, param);
> >>   		break;
> >>   	case PIN_CONFIG_OUTPUT:
> >> @@ -354,6 +360,7 @@ static int mtk_pconf_parse_conf(struct pinctrl_dev *pctldev,
> >>   		ret = mtk_pmx_gpio_set_direction(pctldev, NULL, pin, false);
> >>   		break;
> >>   	case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
> >> +		mtk_pmx_gpio_set_direction(pctldev, NULL, pin, true);
> >>   		ret = mtk_pconf_set_ies_smt(pctl, pin, arg, param);
> >>   		break;
> >>   	case PIN_CONFIG_DRIVE_STRENGTH:
> >
> > This change is not directly related to adding mt2710 support and change
> > behavior for all MTK pinctrl drivers, please create a separate patch for
> > this.
> >
> 
> Hi Biao,
> 
> This patch didn't make it into v4.5-rc1. Are you thinking of sending a 
> new version addressing the comments from Yingjoe?

He already did,
http://lists.infradead.org/pipermail/linux-mediatek/2016-February/003980.html

The issue now is whether this change match the property.

Joe.C




From boris.brezillon at free-electrons.com  Thu Feb  4 06:01:50 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Thu, 4 Feb 2016 15:01:50 +0100
Subject: [PATCH v3 00/12] pwm: add support for atomic update
In-Reply-To: <20160204110203.GL4455@sirena.org.uk>
References: <1442828009-6241-1-git-send-email-boris.brezillon@free-electrons.com>
 <2341981.a79ioYM9Es@diego> <20151110173416.GB21727@ulmo>
 <CAD=FV=WL3jYEgVe-m6QcAyQwfJgdX4J5OtKisKwyoKOrTSpEQA@mail.gmail.com>
 <20160125170855.GA10182@ulmo>
 <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
 <20160203145337.GD9650@ulmo>
 <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
 <20160204110203.GL4455@sirena.org.uk>
Message-ID: <20160204150150.553d36df@bbrezillon>

Hi Mark, Thierry,

On Thu, 4 Feb 2016 11:02:03 +0000
Mark Brown <broonie at kernel.org> wrote:

> On Wed, Feb 03, 2016 at 11:04:20AM -0800, Doug Anderson wrote:
> 
> > Sure.  ...but you agree that somehow you need a new API call for this,
> > right?  Somehow the PWM regulator needs to be able to say that it
> > wants the hardware state, not the initial state as specified in the
> > device tree.
> 
> Wouldn't the most direct way to do that be to just not specify anything
> in the DT?  If there *is* something in DT but we ignore it that's a bit
> weird.

Just adding some inputs on this specific aspect. The reason we have to
specify a period (and, to a lesser extent, the polarity) in the DT or
PWM lookup table is because what most PWM users want is to specify a
dutycycle relatively to a predefined period value.
If we decide to remove those information from the DT, then you'll need
a way to define it somewhere else, and then the is question is 'where?'.

Users that really want to control their period (this could the case for
the clk-pwm driver) could completely ignore DT/lookup-table information
and set the period and absolute dutycycle directly.

Now, from what I seen, what most PWM users want to do is:

	pwm_set_rel_duty_scale(pwm, rel_value, scale);
or 
	rel_duty = pwm_get_rel_duty_cycle(pwm, scale);

where scale depends on the precision you need for your use case (most
of the time it's expressed in percent).

So, how about providing this kind of API (this is what I proposed in
one of my previous email)?

This would not only solve our problem (say you have a period at
boot-time that differs from the one you'll set when first applying a
new relative duty cycle, then the resulting relative value would still
be correct), but it would also remove a lot of boiler plate code from
PWM users code (if you take a look at pwm-regulator, pwm-leds, pwm-fan
and probably others, you'll see that they are all doing this conversion
manually).

Now, the last blocking point is, what if the PWM driver does not
implement HW-readout. In this case, the pwm-regulator will probably
expose a 0V output (IIRC, dutycycle is set to 0 by default) when it's
actually providing something else. But is this really important? I
mean, if the user really wants to have a reliable information, then he
will implement initial-state retrieval in its PWM controller driver.
Alternatively, we could put a flag specifying whether the PWM chip
supports initial state retrieval.

Am I missing something?

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


From linus.walleij at linaro.org  Thu Feb  4 06:04:09 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu,  4 Feb 2016 15:04:09 +0100
Subject: [PATCH 00/11] CLCD Nomadik+Versatile support
Message-ID: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>

This is the result of some tiresome work to adopt the CLCD
driver to use device tree properly for Nomadik, Integrator,
Versatile and RealView.

The Nomadik support basically just adds some vendor data stuff
similar to what we have done for other drivers, but also add
as per-vendor .board_init() and .panel_init() hook.

These hooks are then used to handle panels on these boards.
Versatile is the most elaborate and took the most time, as it
is doing autodetection of the panel at runtime, and thus we
encode all possible panels in the DT and select the detected
panel at .panel_init() time.

The patches have been tested quite extensively on my Nomadik
NHK8815 and the ARM Integrator, Versatile, and RealView
reference designs, as well as on the more forgiving QEMU
emulation of Versatile.

Eventually I would like to have patches 1 thru 8 (those with
patches to CLCD or the DT bindings) applied through the FBDEV
subsystem, while I will take the SoC specifics (patches 9 thru 11,
and some non-included Nomadik patches) separately as it affects
multiple ARM SoC files.

Linus Walleij (11):
  video: ARM CLCD: backlight support for OF
  video: ARM CLCD: support DT signal inversion flags
  video: ARM CLCD: support pads connected in reverse order
  video: ARM CLCD: support Nomadik variant
  video: ARM CLCD: add special board and panel hooks for Nomadik
  Documentation/DT: add blurb for IB2 syscon to Versatile
  Documentation/DT: add Versatile display bindings
  video: ARM CLCD: add special panel hook for Versatiles
  ARM: PB11MPCore: define a standard VGA panel
  ARM: PB1176: define a standard VGA panel
  ARM: versatile: move CLCD configuration to device tree

 Documentation/devicetree/bindings/arm/arm-boards   |   8 +
 .../bindings/display/panel/epson,l2f50113t00.txt   |   7 +
 .../bindings/display/panel/sanyo,alr252rgt.txt     |   7 +
 .../bindings/display/panel/sanyo,tm38qv67a02a.txt  |   7 +
 .../bindings/display/panel/sharp,lq084v1dg21.txt   |   7 +
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/arm-realview-pb1176.dts          |  40 ++
 arch/arm/boot/dts/arm-realview-pb11mp.dts          |  19 +-
 arch/arm/boot/dts/versatile-ab-ib2.dts             |  20 +
 arch/arm/boot/dts/versatile-ab.dts                 | 203 ++++++++++-
 arch/arm/mach-versatile/versatile_dt.c             | 162 --------
 drivers/video/fbdev/Kconfig                        |   6 +-
 drivers/video/fbdev/Makefile                       |   1 +
 drivers/video/fbdev/amba-clcd-nomadik.c            | 263 +++++++++++++
 drivers/video/fbdev/amba-clcd-nomadik.h            |  24 ++
 drivers/video/fbdev/amba-clcd-versatile.c          | 406 +++++++++++++++++++++
 drivers/video/fbdev/amba-clcd-versatile.h          |  17 +
 drivers/video/fbdev/amba-clcd.c                    | 205 ++++++++++-
 include/linux/amba/clcd.h                          |  76 +++-
 20 files changed, 1279 insertions(+), 201 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
 create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt
 create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt
 create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt
 create mode 100644 arch/arm/boot/dts/versatile-ab-ib2.dts
 create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.c
 create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.h
 create mode 100644 drivers/video/fbdev/amba-clcd-versatile.h

-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb  4 06:04:10 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu,  4 Feb 2016 15:04:10 +0100
Subject: [PATCH 01/11] video: ARM CLCD: backlight support for OF
In-Reply-To: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1454594660-7532-2-git-send-email-linus.walleij@linaro.org>

If the device is probed from device tree, we can support
backlight. This is used with some systems such as the
ST Microelectronics Nomadik.

We have to add HAS_IOMEM to the dependencies of CLCD since
the backlight class device will now be selected, and if it
gets selected on an arch that does not have IOMEM,
compilation will fail.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/video/fbdev/Kconfig     |  4 +++-
 drivers/video/fbdev/amba-clcd.c | 40 ++++++++++++++++++++++++++++++++++++++++
 include/linux/amba/clcd.h       |  3 +++
 3 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8ea45a5cd806..6dcd91237551 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -284,12 +284,14 @@ config FB_PM2_FIFO_DISCONNECT
 config FB_ARMCLCD
 	tristate "ARM PrimeCell PL110 support"
 	depends on ARM || ARM64 || COMPILE_TEST
-	depends on FB && ARM_AMBA
+	depends on FB && ARM_AMBA && HAS_IOMEM
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
 	select FB_MODE_HELPERS if OF
 	select VIDEOMODE_HELPERS if OF
+	select BACKLIGHT_LCD_SUPPORT if OF
+	select BACKLIGHT_CLASS_DEVICE if OF
 	help
 	  This framebuffer device driver is for the ARM PrimeCell PL110
 	  Colour LCD controller.  ARM PrimeCells provide the building
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index f9ef06d0cd48..c5d1e9ca81ab 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -30,6 +30,7 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_graph.h>
+#include <linux/backlight.h>
 #include <video/display_timing.h>
 #include <video/of_display_timing.h>
 #include <video/videomode.h>
@@ -73,6 +74,11 @@ static void clcdfb_disable(struct clcd_fb *fb)
 	if (fb->board->disable)
 		fb->board->disable(fb);
 
+	if (fb->panel->backlight) {
+		fb->panel->backlight->props.power = FB_BLANK_POWERDOWN;
+		backlight_update_status(fb->panel->backlight);
+	}
+
 	val = readl(fb->regs + fb->off_cntl);
 	if (val & CNTL_LCDPWR) {
 		val &= ~CNTL_LCDPWR;
@@ -119,6 +125,14 @@ static void clcdfb_enable(struct clcd_fb *fb, u32 cntl)
 	writel(cntl, fb->regs + fb->off_cntl);
 
 	/*
+	 * Turn on backlight
+	 */
+	if (fb->panel->backlight) {
+		fb->panel->backlight->props.power = FB_BLANK_UNBLANK;
+		backlight_update_status(fb->panel->backlight);
+	}
+
+	/*
 	 * finally, enable the interface.
 	 */
 	if (fb->board->enable)
@@ -578,6 +592,28 @@ static int clcdfb_snprintf_mode(char *buf, int size, struct fb_videomode *mode)
 			mode->refresh);
 }
 
+static int clcdfb_of_get_backlight(struct device_node *endpoint,
+				   struct clcd_panel *clcd_panel)
+{
+	struct device_node *panel;
+	struct device_node *backlight;
+
+	panel = of_graph_get_remote_port_parent(endpoint);
+	if (!panel)
+		return -ENODEV;
+
+	/* Look up the optional backlight phandle */
+	backlight = of_parse_phandle(panel, "backlight", 0);
+	if (backlight) {
+		clcd_panel->backlight = of_find_backlight_by_node(backlight);
+		of_node_put(backlight);
+
+		if (!clcd_panel->backlight)
+			return -EPROBE_DEFER;
+	}
+	return 0;
+}
+
 static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
 		struct fb_videomode *mode)
 {
@@ -664,6 +700,10 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
 	if (!endpoint)
 		return -ENODEV;
 
+	err = clcdfb_of_get_backlight(endpoint, fb->panel);
+	if (err)
+		return err;
+
 	err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, &fb->panel->mode);
 	if (err)
 		return err;
diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h
index e82e3ee2c54a..e64c1ccebb76 100644
--- a/include/linux/amba/clcd.h
+++ b/include/linux/amba/clcd.h
@@ -93,6 +93,8 @@ enum {
 	CLCD_CAP_ALL		= CLCD_CAP_BGR | CLCD_CAP_RGB,
 };
 
+struct backlight_device;
+
 struct clcd_panel {
 	struct fb_videomode	mode;
 	signed short		width;	/* width in mm */
@@ -105,6 +107,7 @@ struct clcd_panel {
 				fixedtimings:1,
 				grayscale:1;
 	unsigned int		connector;
+	struct backlight_device	*backlight;
 };
 
 struct clcd_regs {
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb  4 06:04:11 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu,  4 Feb 2016 15:04:11 +0100
Subject: [PATCH 02/11] video: ARM CLCD: support DT signal inversion flags
In-Reply-To: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1454594660-7532-3-git-send-email-linus.walleij@linaro.org>

The device tree bindings from display-timing.txt allows us to
specify if data enable, hsync, vsync or the pixed clock should be
inverted on the way to the display. The driver does not currently
handle this so add support for those flags as it is needed for
the Versatile Sanyo LCD display.

Note that the previous behaviour was to invert the pixel clock
for all displays, so unless the pixel clock polarity is
explicitly defined in the device tree (i.e. the timings node
has the "pixelclk-active" property) we fall back to inverting
the pixel clock. This needs some extra compatibility code.

Since the timing flags have to be set up inside the struct
clcd_panel, we need to refactor the code a bit to pass around
the panel rather than just the mode.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/video/fbdev/amba-clcd.c | 41 ++++++++++++++++++++++++++++++++++-------
 1 file changed, 34 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index c5d1e9ca81ab..8903a42c4122 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -567,10 +567,11 @@ static int clcdfb_register(struct clcd_fb *fb)
 
 #ifdef CONFIG_OF
 static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
-		struct fb_videomode *mode)
+		struct clcd_panel *clcd_panel)
 {
 	int err;
 	struct display_timing timing;
+	struct device_node *timnp;
 	struct videomode video;
 
 	err = of_get_display_timing(node, "panel-timing", &timing);
@@ -579,10 +580,34 @@ static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
 
 	videomode_from_timing(&timing, &video);
 
-	err = fb_videomode_from_videomode(&video, mode);
+	err = fb_videomode_from_videomode(&video, &clcd_panel->mode);
 	if (err)
 		return err;
 
+	/* Set up some inversion flags */
+	timnp = of_get_child_by_name(node, "panel-timing");
+	if (timnp && of_property_read_bool(timnp, "pixelclk-active")) {
+		if (timing.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+			clcd_panel->tim2 |= TIM2_IPC;
+	} else {
+		/*
+		 * To preserve backwards compatibility, the IPC (inverted
+		 * pixel clock) flag needs to be set on any display that
+		 * doesn't explicitly specify that the pixel clock is
+		 * active on the negative edge.
+		 */
+		clcd_panel->tim2 |= TIM2_IPC;
+	}
+
+	if (timing.flags & DISPLAY_FLAGS_HSYNC_LOW)
+		clcd_panel->tim2 |= TIM2_IHS;
+
+	if (timing.flags & DISPLAY_FLAGS_VSYNC_LOW)
+		clcd_panel->tim2 |= TIM2_IVS;
+
+	if (timing.flags & DISPLAY_FLAGS_DE_LOW)
+		clcd_panel->tim2 |= TIM2_IOE;
+
 	return 0;
 }
 
@@ -615,10 +640,11 @@ static int clcdfb_of_get_backlight(struct device_node *endpoint,
 }
 
 static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
-		struct fb_videomode *mode)
+		struct clcd_panel *clcd_panel)
 {
 	int err;
 	struct device_node *panel;
+	struct fb_videomode *mode;
 	char *name;
 	int len;
 
@@ -628,11 +654,12 @@ static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
 
 	/* Only directly connected DPI panels supported for now */
 	if (of_device_is_compatible(panel, "panel-dpi"))
-		err = clcdfb_of_get_dpi_panel_mode(panel, mode);
+		err = clcdfb_of_get_dpi_panel_mode(panel, clcd_panel);
 	else
 		err = -ENOENT;
 	if (err)
 		return err;
+	mode = &clcd_panel->mode;
 
 	len = clcdfb_snprintf_mode(NULL, 0, mode);
 	name = devm_kzalloc(dev, len + 1, GFP_KERNEL);
@@ -663,8 +690,8 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
 	};
 	int i;
 
-	/* Bypass pixel clock divider, data output on the falling edge */
-	fb->panel->tim2 = TIM2_BCD | TIM2_IPC;
+	/* Bypass pixel clock divider */
+	fb->panel->tim2 |= TIM2_BCD;
 
 	/* TFT display, vert. comp. interrupt at the start of the back porch */
 	fb->panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
@@ -704,7 +731,7 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
 	if (err)
 		return err;
 
-	err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, &fb->panel->mode);
+	err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, fb->panel);
 	if (err)
 		return err;
 
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb  4 06:04:12 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu,  4 Feb 2016 15:04:12 +0100
Subject: [PATCH 03/11] video: ARM CLCD: support pads connected in reverse order
In-Reply-To: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1454594660-7532-4-git-send-email-linus.walleij@linaro.org>

There are CLCDs connected with the pads in BGR rather than RGB
order. It really doesn't matter since the CLCD has a flag and
a bit to switch the position of the RGB and BGR components.
This is needed to put something logical into the
arm,pl11x,tft-r0g0b0-pads property of the device tree on the
Nomadik which will then be <16 8 0>.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/video/fbdev/amba-clcd.c |  8 ++++++++
 include/linux/amba/clcd.h       | 31 ++++++++++++++++++++++++-------
 2 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 8903a42c4122..9a631a8e2c04 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -681,6 +681,7 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
 	} panels[] = {
 		{ 0x110, 1,  7, 13, CLCD_CAP_5551 },
 		{ 0x110, 0,  8, 16, CLCD_CAP_888 },
+		{ 0x110, 16, 8, 0,  CLCD_CAP_888 },
 		{ 0x111, 4, 14, 20, CLCD_CAP_444 },
 		{ 0x111, 3, 11, 19, CLCD_CAP_444 | CLCD_CAP_5551 },
 		{ 0x111, 3, 10, 19, CLCD_CAP_444 | CLCD_CAP_5551 |
@@ -708,6 +709,13 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
 			fb->panel->caps = panels[i].caps;
 	}
 
+	/*
+	 * If we actually physically connected the R lines to B and
+	 * vice versa
+	 */
+	if (r0 != 0 && b0 == 0)
+		fb->panel->bgr_connection = true;
+
 	return fb->panel->caps ? 0 : -EINVAL;
 }
 
diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h
index e64c1ccebb76..c60f32e23a83 100644
--- a/include/linux/amba/clcd.h
+++ b/include/linux/amba/clcd.h
@@ -108,6 +108,12 @@ struct clcd_panel {
 				grayscale:1;
 	unsigned int		connector;
 	struct backlight_device	*backlight;
+	/*
+	 * If the B/R lines are switched between the CLCD
+	 * and the panel we need to know this and not try to
+	 * compensate with the BGR bit in the control register.
+	 */
+	bool			bgr_connection;
 };
 
 struct clcd_regs {
@@ -234,16 +240,27 @@ static inline void clcdfb_decode(struct clcd_fb *fb, struct clcd_regs *regs)
 	if (var->grayscale)
 		val |= CNTL_LCDBW;
 
-	if (fb->panel->caps && fb->board->caps &&
-	    var->bits_per_pixel >= 16) {
+	if (fb->panel->caps && fb->board->caps && var->bits_per_pixel >= 16) {
 		/*
 		 * if board and panel supply capabilities, we can support
-		 * changing BGR/RGB depending on supplied parameters
+		 * changing BGR/RGB depending on supplied parameters. Here
+		 * we switch to what the framebuffer is providing if need
+		 * be, so if the framebuffer is BGR but the display connection
+		 * is RGB (first case) we switch it around. Vice versa mutatis
+		 * mutandis if the framebuffer is RGB but the display connection
+		 * is BGR, we flip it around.
 		 */
-		if (var->red.offset == 0)
-			val &= ~CNTL_BGR;
-		else
-			val |= CNTL_BGR;
+		if (!fb->panel->bgr_connection) {
+			if (var->red.offset == 0)
+				val &= ~CNTL_BGR;
+			else
+				val |= CNTL_BGR;
+		} else {
+			if (var->blue.offset == 0)
+				val &= ~CNTL_BGR;
+			else
+				val |= CNTL_BGR;
+		}
 	}
 
 	switch (var->bits_per_pixel) {
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb  4 06:04:13 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu,  4 Feb 2016 15:04:13 +0100
Subject: [PATCH 04/11] video: ARM CLCD: support Nomadik variant
In-Reply-To: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1454594660-7532-5-git-send-email-linus.walleij@linaro.org>

The Nomadik variant has a few special quirks that need to be respected
to make the driver work:

- The block need to be clocked during writing of the TIMn registers
  or the bus will stall.
- Special bits in the control register select how many of the output
  display lines get activated.
- Special bits in the control register select how to manage the
  different 565 and 5551 modes.
- There is a packed 24bit graphics mode, i.e 888 pixels can be stored
  in memory is three consecutive bytes, not evenly aligned to a 32bit
  word.

This patch uses the vendor data pointer from the AMBA matching mechanism
to track the quirks for this variant, and adds two hooks that variants
can use to initialize boards and panels during start-up. These will
later be used to adopt a Nomadik board profile.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/video/fbdev/amba-clcd.c | 108 ++++++++++++++++++++++++++++++++++++----
 include/linux/amba/clcd.h       |  42 ++++++++++++++++
 2 files changed, 140 insertions(+), 10 deletions(-)

diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 9a631a8e2c04..77fb50e00670 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -227,6 +227,15 @@ clcdfb_set_bitfields(struct clcd_fb *fb, struct fb_var_screeninfo *var)
 			var->blue.length = 4;
 		}
 		break;
+	case 24:
+		if (fb->vendor->packed_24_bit_pixels) {
+			var->red.length = 8;
+			var->green.length = 8;
+			var->blue.length = 8;
+		} else {
+			ret = -EINVAL;
+		}
+		break;
 	case 32:
 		/* If we can't do 888, reject */
 		caps &= CLCD_CAP_888;
@@ -313,6 +322,12 @@ static int clcdfb_set_par(struct fb_info *info)
 
 	clcdfb_disable(fb);
 
+	/* Some variants must be clocked here */
+	if (fb->vendor->clock_timregs && !fb->clk_enabled) {
+		fb->clk_enabled = true;
+		clk_enable(fb->clk);
+	}
+
 	writel(regs.tim0, fb->regs + CLCD_TIM0);
 	writel(regs.tim1, fb->regs + CLCD_TIM1);
 	writel(regs.tim2, fb->regs + CLCD_TIM2);
@@ -716,12 +731,48 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
 	if (r0 != 0 && b0 == 0)
 		fb->panel->bgr_connection = true;
 
+	if (fb->panel->caps && fb->vendor->st_bitmux_control) {
+		/*
+		 * Set up the special bits for the Nomadik control register
+		 * (other platforms tend to do this through an external
+		 * register).
+		 */
+
+		/* Offset of the highest used color */
+		int maxoff = max3(r0, g0, b0);
+		/* Most significant bit out, highest used bit */
+		int msb = 0;
+
+		if (fb->panel->caps & CLCD_CAP_888) {
+			msb = maxoff + 8 - 1;
+		} else if (fb->panel->caps & CLCD_CAP_565) {
+			msb = maxoff + 5 - 1;
+			fb->panel->cntl |= CNTL_ST_1XBPP_565;
+		} else if (fb->panel->caps & CLCD_CAP_5551) {
+			msb = maxoff + 5 - 1;
+			fb->panel->cntl |= CNTL_ST_1XBPP_5551;
+		} else if (fb->panel->caps & CLCD_CAP_444) {
+			msb = maxoff + 4 - 1;
+			fb->panel->cntl |= CNTL_ST_1XBPP_444;
+		}
+
+		/* Send out as many bits as we need */
+		if (msb > 17)
+			fb->panel->cntl |= CNTL_ST_CDWID_24;
+		else if (msb > 15)
+			fb->panel->cntl |= CNTL_ST_CDWID_18;
+		else if (msb > 11)
+			fb->panel->cntl |= CNTL_ST_CDWID_16;
+		else
+			fb->panel->cntl |= CNTL_ST_CDWID_12;
+	}
+
 	return fb->panel->caps ? 0 : -EINVAL;
 }
 
 static int clcdfb_of_init_display(struct clcd_fb *fb)
 {
-	struct device_node *endpoint;
+	struct device_node *endpoint = NULL;
 	int err;
 	unsigned int bpp;
 	u32 max_bandwidth;
@@ -731,9 +782,21 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
 	if (!fb->panel)
 		return -ENOMEM;
 
-	endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node, NULL);
-	if (!endpoint)
-		return -ENODEV;
+	if (fb->vendor->init_panel) {
+		err = fb->vendor->init_panel(fb, &endpoint);
+		if (err)
+			return err;
+	}
+	/*
+	 * If the vendor-specific code did not choose an endpoint,
+	 * take the first one.
+	 */
+	if (!endpoint) {
+		endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node,
+						      NULL);
+		if (!endpoint)
+			return -ENODEV;
+	}
 
 	err = clcdfb_of_get_backlight(endpoint, fb->panel);
 	if (err)
@@ -770,11 +833,11 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
 
 	if (of_property_read_u32_array(endpoint,
 			"arm,pl11x,tft-r0g0b0-pads",
-			tft_r0b0g0, ARRAY_SIZE(tft_r0b0g0)) == 0)
-		return clcdfb_of_init_tft_panel(fb, tft_r0b0g0[0],
-				 tft_r0b0g0[1],  tft_r0b0g0[2]);
+			tft_r0b0g0, ARRAY_SIZE(tft_r0b0g0)) != 0)
+		return -ENOENT;
 
-	return -ENOENT;
+	return clcdfb_of_init_tft_panel(fb, tft_r0b0g0[0],
+					tft_r0b0g0[1],  tft_r0b0g0[2]);
 }
 
 static int clcdfb_of_vram_setup(struct clcd_fb *fb)
@@ -895,6 +958,7 @@ static struct clcd_board *clcdfb_of_get_board(struct amba_device *dev)
 static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
 {
 	struct clcd_board *board = dev_get_platdata(&dev->dev);
+	struct clcd_vendor_data *vendor = id->data;
 	struct clcd_fb *fb;
 	int ret;
 
@@ -904,6 +968,12 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
 	if (!board)
 		return -EINVAL;
 
+	if (vendor->init_board) {
+		ret = vendor->init_board(dev, board);
+		if (ret)
+			return ret;
+	}
+
 	ret = dma_set_mask_and_coherent(&dev->dev, DMA_BIT_MASK(32));
 	if (ret)
 		goto out;
@@ -922,10 +992,11 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
 	}
 
 	fb->dev = dev;
+	fb->vendor = vendor;
 	fb->board = board;
 
-	dev_info(&fb->dev->dev, "PL%03x rev%u at 0x%08llx\n",
-		amba_part(dev), amba_rev(dev),
+	dev_info(&fb->dev->dev, "PL%03x designer %02x rev%u at 0x%08llx\n",
+		amba_part(dev), amba_manf(dev), amba_rev(dev),
 		(unsigned long long)dev->res.start);
 
 	ret = fb->board->setup(fb);
@@ -968,10 +1039,27 @@ static int clcdfb_remove(struct amba_device *dev)
 	return 0;
 }
 
+static struct clcd_vendor_data vendor_arm = {
+	/* No special business */
+};
+
+static struct clcd_vendor_data vendor_nomadik = {
+	.clock_timregs = true,
+	.packed_24_bit_pixels = true,
+	.st_bitmux_control = true,
+};
+
 static struct amba_id clcdfb_id_table[] = {
 	{
 		.id	= 0x00041110,
 		.mask	= 0x000ffffe,
+		.data	= &vendor_arm,
+	},
+	/* ST Electronics Nomadik variant */
+	{
+		.id	= 0x00180110,
+		.mask	= 0x00fffffe,
+		.data	= &vendor_nomadik,
 	},
 	{ 0, 0 },
 };
diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h
index c60f32e23a83..9d2e03fae84d 100644
--- a/include/linux/amba/clcd.h
+++ b/include/linux/amba/clcd.h
@@ -67,6 +67,17 @@
 #define CNTL_LDMAFIFOTIME	(1 << 15)
 #define CNTL_WATERMARK		(1 << 16)
 
+/* ST Microelectronics variant bits */
+#define CNTL_ST_1XBPP_444	0x0
+#define CNTL_ST_1XBPP_5551	(1 << 17)
+#define CNTL_ST_1XBPP_565	(1 << 18)
+#define CNTL_ST_CDWID_12	0x0
+#define CNTL_ST_CDWID_16	(1 << 19)
+#define CNTL_ST_CDWID_18	(1 << 20)
+#define CNTL_ST_CDWID_24	((1 << 19)|(1 << 20))
+#define CNTL_ST_CEAEN		(1 << 21)
+#define CNTL_ST_LCDBPP24_PACKED	(6 << 1)
+
 enum {
 	/* individual formats */
 	CLCD_CAP_RGB444		= (1 << 0),
@@ -179,11 +190,38 @@ struct clcd_board {
 struct amba_device;
 struct clk;
 
+/**
+ * struct clcd_vendor_data - holds hardware (IP-block) vendor-specific
+ * variant information
+ *
+ * @clock_timregs: the CLCD needs to be clocked when accessing the
+ * timer registers, or the hardware will hang.
+ * @packed_24_bit_pixels: this variant supports 24bit packed pixel data,
+ * so that RGB accesses 3 bytes at a time, not just on even 32bit
+ * boundaries, packing the pixel data in memory. ST Microelectronics
+ * have this.
+ * @st_bitmux_control: ST Microelectronics have implemented output
+ * bit line multiplexing into the CLCD control register. This indicates
+ * that we need to use this.
+ * @init_board: custom board init function for this variant
+ * @init_panel: custom panel init function for this variant
+ */
+struct clcd_vendor_data {
+	bool	clock_timregs;
+	bool	packed_24_bit_pixels;
+	bool	st_bitmux_control;
+	int	(*init_board)(struct amba_device *adev,
+			      struct clcd_board *board);
+	int	(*init_panel)(struct clcd_fb *fb,
+			      struct device_node **panel);
+};
+
 /* this data structure describes each frame buffer device we find */
 struct clcd_fb {
 	struct fb_info		fb;
 	struct amba_device	*dev;
 	struct clk		*clk;
+	struct clcd_vendor_data	*vendor;
 	struct clcd_panel	*panel;
 	struct clcd_board	*board;
 	void			*board_data;
@@ -290,6 +328,10 @@ static inline void clcdfb_decode(struct clcd_fb *fb, struct clcd_regs *regs)
 		else
 			val |= CNTL_LCDBPP16_444;
 		break;
+	case 24:
+		/* Modified variant supporting 24 bit packed pixels */
+		val |= CNTL_ST_LCDBPP24_PACKED;
+		break;
 	case 32:
 		val |= CNTL_LCDBPP24;
 		break;
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb  4 06:04:14 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu,  4 Feb 2016 15:04:14 +0100
Subject: [PATCH 05/11] video: ARM CLCD: add special board and panel hooks for
 Nomadik
In-Reply-To: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1454594660-7532-6-git-send-email-linus.walleij@linaro.org>

In the .board_init() callback will set up a mux register in
the Nomadik system controller. It so happens that the platform
has two display output engines, and we have to poke a bit in
a special register to make sure the right engine is muxed in
as they are mutually exclusive.

The Nomadik CLCD variant is instantiated on a platform where
it is combined with a 800x480 TPO WVGA display. In the
.panel_init() hook we will detect this display from the
compatible string and set it up. We also add .enable() and
.disable() callbacks for it as the sleep state is software
controlled.

The display is connected with a special 3-wire serial bus
(this is sadly neither I2C or SPI) using three GPIO lines that
we bitbang to detect the display and enable/disable sleep
state.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/video/fbdev/Makefile            |   1 +
 drivers/video/fbdev/amba-clcd-nomadik.c | 263 ++++++++++++++++++++++++++++++++
 drivers/video/fbdev/amba-clcd-nomadik.h |  24 +++
 drivers/video/fbdev/amba-clcd.c         |   6 +-
 4 files changed, 293 insertions(+), 1 deletion(-)
 create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.c
 create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.h

diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index 65fb15075c8f..f0aec3aa213c 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_FB_ATMEL)		  += atmel_lcdfb.o
 obj-$(CONFIG_FB_PVR2)             += pvr2fb.o
 obj-$(CONFIG_FB_VOODOO1)          += sstfb.o
 obj-$(CONFIG_FB_ARMCLCD)	  += amba-clcd.o
+obj-$(CONFIG_ARCH_NOMADIK)	  += amba-clcd-nomadik.o
 obj-$(CONFIG_PLAT_VERSATILE_CLCD) += amba-clcd-versatile.o
 obj-$(CONFIG_FB_GOLDFISH)         += goldfishfb.o
 obj-$(CONFIG_FB_68328)            += 68328fb.o
diff --git a/drivers/video/fbdev/amba-clcd-nomadik.c b/drivers/video/fbdev/amba-clcd-nomadik.c
new file mode 100644
index 000000000000..bc3519d1b5c0
--- /dev/null
+++ b/drivers/video/fbdev/amba-clcd-nomadik.c
@@ -0,0 +1,263 @@
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+#include <linux/gpio/consumer.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/delay.h>
+#include <linux/bitops.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+
+#include "amba-clcd-nomadik.h"
+
+static struct gpio_desc *grestb;
+static struct gpio_desc *scen;
+static struct gpio_desc *scl;
+static struct gpio_desc *sda;
+
+static u8 tpg110_readwrite_reg(bool write, u8 address, u8 outval)
+{
+	int i;
+	u8 inval = 0;
+
+	/* Assert SCEN */
+	gpiod_set_value_cansleep(scen, 1);
+	ndelay(150);
+	/* Hammer out the address */
+	for (i = 5; i >= 0; i--) {
+		if (address & BIT(i))
+			gpiod_set_value_cansleep(sda, 1);
+		else
+			gpiod_set_value_cansleep(sda, 0);
+		ndelay(150);
+		/* Send an SCL pulse */
+		gpiod_set_value_cansleep(scl, 1);
+		ndelay(160);
+		gpiod_set_value_cansleep(scl, 0);
+		ndelay(160);
+	}
+
+	if (write) {
+		/* WRITE */
+		gpiod_set_value_cansleep(sda, 0);
+	} else {
+		/* READ */
+		gpiod_set_value_cansleep(sda, 1);
+	}
+	ndelay(150);
+	/* Send an SCL pulse */
+	gpiod_set_value_cansleep(scl, 1);
+	ndelay(160);
+	gpiod_set_value_cansleep(scl, 0);
+	ndelay(160);
+
+	if (!write)
+		/* HiZ turn-around cycle */
+		gpiod_direction_input(sda);
+	ndelay(150);
+	/* Send an SCL pulse */
+	gpiod_set_value_cansleep(scl, 1);
+	ndelay(160);
+	gpiod_set_value_cansleep(scl, 0);
+	ndelay(160);
+
+	/* Hammer in/out the data */
+	for (i = 7; i >= 0; i--) {
+		int value;
+
+		if (write) {
+			value = !!(outval & BIT(i));
+			gpiod_set_value_cansleep(sda, value);
+		} else {
+			value = gpiod_get_value(sda);
+			if (value)
+				inval |= BIT(i);
+		}
+		ndelay(150);
+		/* Send an SCL pulse */
+		gpiod_set_value_cansleep(scl, 1);
+		ndelay(160);
+		gpiod_set_value_cansleep(scl, 0);
+		ndelay(160);
+	}
+
+	gpiod_direction_output(sda, 0);
+	/* Deassert SCEN */
+	gpiod_set_value_cansleep(scen, 0);
+	/* Satisfies SCEN pulse width */
+	udelay(1);
+
+	return inval;
+}
+
+static u8 tpg110_read_reg(u8 address)
+{
+	return tpg110_readwrite_reg(false, address, 0);
+}
+
+static void tpg110_write_reg(u8 address, u8 outval)
+{
+	tpg110_readwrite_reg(true, address, outval);
+}
+
+static void tpg110_startup(struct device *dev)
+{
+	u8 val;
+
+	dev_info(dev, "TPG110 display enable\n");
+	/* De-assert the reset signal */
+	gpiod_set_value_cansleep(grestb, 0);
+	mdelay(1);
+	dev_info(dev, "de-asserted GRESTB\n");
+
+	/* Test display communication */
+	tpg110_write_reg(0x00, 0x55);
+	val = tpg110_read_reg(0x00);
+	if (val == 0x55)
+		dev_info(dev, "passed communication test\n");
+	val = tpg110_read_reg(0x01);
+	dev_info(dev, "TPG110 chip ID: %d version: %d\n",
+		val>>4, val&0x0f);
+
+	/* Show display resolution */
+	val = tpg110_read_reg(0x02);
+	val &= 7;
+	switch (val) {
+	case 0x0:
+		dev_info(dev, "IN 400x240 RGB -> OUT 800x480 RGB (dual scan)");
+		break;
+	case 0x1:
+		dev_info(dev, "IN 480x272 RGB -> OUT 800x480 RGB (dual scan)");
+		break;
+	case 0x4:
+		dev_info(dev, "480x640 RGB");
+		break;
+	case 0x5:
+		dev_info(dev, "480x272 RGB");
+		break;
+	case 0x6:
+		dev_info(dev, "640x480 RGB");
+		break;
+	case 0x7:
+		dev_info(dev, "800x480 RGB");
+		break;
+	default:
+		dev_info(dev, "ILLEGAL RESOLUTION");
+		break;
+	}
+
+	val = tpg110_read_reg(0x03);
+	dev_info(dev, "resolution is controlled by %s\n",
+		(val & BIT(7)) ? "software" : "hardware");
+}
+
+static void tpg110_enable(struct clcd_fb *fb)
+{
+	struct fb_var_screeninfo *var = &fb->fb.var;
+	struct device *dev = &fb->dev->dev;
+	static bool startup;
+	u8 val;
+
+	if (!startup) {
+		tpg110_startup(dev);
+		startup = true;
+	}
+
+	/* Take chip out of standby */
+	val = tpg110_read_reg(0x03);
+	val |= BIT(0);
+	tpg110_write_reg(0x03, val);
+}
+
+static void tpg110_disable(struct clcd_fb *fb)
+{
+	u8 val;
+
+	dev_info(&fb->dev->dev, "TPG110 display disable\n");
+	val = tpg110_read_reg(0x03);
+	/* Put into standby */
+	val &= ~BIT(0);
+	tpg110_write_reg(0x03, val);
+}
+
+static void tpg110_init(struct device *dev, struct device_node *np,
+			struct clcd_board *board)
+{
+	dev_info(dev, "TPG110 display init\n");
+
+	grestb = devm_get_gpiod_from_child(dev, "grestb", &np->fwnode);
+	if (IS_ERR(grestb)) {
+		dev_err(dev, "no GRESTB GPIO\n");
+		return;
+	}
+	/* This asserts the GRESTB signal, putting the display into reset */
+	gpiod_direction_output(grestb, 1);
+
+	scen = devm_get_gpiod_from_child(dev, "scen", &np->fwnode);
+	if (IS_ERR(scen)) {
+		dev_err(dev, "no SCEN GPIO\n");
+		return;
+	}
+	gpiod_direction_output(scen, 0);
+	scl = devm_get_gpiod_from_child(dev, "scl", &np->fwnode);
+	if (IS_ERR(scl)) {
+		dev_err(dev, "no SCL GPIO\n");
+		return;
+	}
+	gpiod_direction_output(scl, 0);
+	sda = devm_get_gpiod_from_child(dev, "sda", &np->fwnode);
+	if (IS_ERR(sda)) {
+		dev_err(dev, "no SDA GPIO\n");
+		return;
+	}
+	gpiod_direction_output(sda, 0);
+	board->enable = tpg110_enable;
+	board->disable = tpg110_disable;
+}
+
+int nomadik_clcd_init_panel(struct clcd_fb *fb,
+			    struct device_node **endpoint)
+{
+	struct device_node *panel;
+
+	*endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node,
+					       NULL);
+	if (!*endpoint)
+		return -ENODEV;
+
+	panel = of_graph_get_remote_port_parent(endpoint);
+	if (!panel)
+		return -ENODEV;
+
+	if (of_device_is_compatible(panel, "tpo,tpg110"))
+		tpg110_init(&fb->dev->dev, panel, fb->board);
+	else
+		dev_info(&fb->dev->dev, "unknown panel\n");
+
+	/* Unknown panel, fall through */
+	return 0;
+}
+
+#define PMU_CTRL_OFFSET 0x0000
+#define PMU_CTRL_LCDNDIF BIT(26)
+
+int nomadik_clcd_init_board(struct amba_device *adev,
+			    struct clcd_board *board)
+{
+	struct regmap *pmu_regmap;
+
+	dev_info(&adev->dev, "Nomadik CLCD board init\n");
+	pmu_regmap =
+		syscon_regmap_lookup_by_compatible("stericsson,nomadik-pmu");
+	if (IS_ERR(pmu_regmap)) {
+		dev_err(&adev->dev, "could not find PMU syscon regmap\n");
+		return PTR_ERR(pmu_regmap);
+	}
+	regmap_update_bits(pmu_regmap,
+			   PMU_CTRL_OFFSET,
+			   PMU_CTRL_LCDNDIF,
+			   0);
+	dev_info(&adev->dev, "set PMU mux to CLCD mode\n");
+
+	return 0;
+}
diff --git a/drivers/video/fbdev/amba-clcd-nomadik.h b/drivers/video/fbdev/amba-clcd-nomadik.h
new file mode 100644
index 000000000000..b34dbf3061bf
--- /dev/null
+++ b/drivers/video/fbdev/amba-clcd-nomadik.h
@@ -0,0 +1,24 @@
+#ifndef _AMBA_CLCD_NOMADIK_H
+#define _AMBA_CLCD_NOMADIK_H
+
+#include <linux/amba/bus.h>
+
+#ifdef CONFIG_ARCH_NOMADIK
+int nomadik_clcd_init_board(struct amba_device *adev,
+			     struct clcd_board *board);
+int nomadik_clcd_init_panel(struct clcd_fb *fb,
+			    struct device_node **endpoint);
+#else
+static inline int nomadik_clcd_init_board(struct amba_device *adev,
+					  struct clcd_board *board)
+{
+	return 0;
+}
+static inline int nomadik_clcd_init_panel(struct clcd_fb *fb,
+					  struct device_node **endpoint)
+{
+	return 0;
+}
+#endif
+
+#endif /* inclusion guard */
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 77fb50e00670..53c5ec31168d 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -37,6 +37,8 @@
 
 #include <asm/sizes.h>
 
+#include "amba-clcd-nomadik.h"
+
 #define to_clcd(info)	container_of(info, struct clcd_fb, fb)
 
 /* This is limited to 16 characters when displayed by X startup */
@@ -1003,7 +1005,7 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
 	if (ret)
 		goto free_fb;
 
-	ret = clcdfb_register(fb); 
+	ret = clcdfb_register(fb);
 	if (ret == 0) {
 		amba_set_drvdata(dev, fb);
 		goto out;
@@ -1047,6 +1049,8 @@ static struct clcd_vendor_data vendor_nomadik = {
 	.clock_timregs = true,
 	.packed_24_bit_pixels = true,
 	.st_bitmux_control = true,
+	.init_board = nomadik_clcd_init_board,
+	.init_panel = nomadik_clcd_init_panel,
 };
 
 static struct amba_id clcdfb_id_table[] = {
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb  4 06:04:15 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu,  4 Feb 2016 15:04:15 +0100
Subject: [PATCH 06/11] Documentation/DT: add blurb for IB2 syscon to Versatile
In-Reply-To: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1454594660-7532-7-git-send-email-linus.walleij@linaro.org>

The ARM Versatile has an optional daughterboard, if this is
mounted, we need to be able to access its system controller.
Put in a documentation blurb for this.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 Documentation/devicetree/bindings/arm/arm-boards | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards
index 1a709970e7f7..2daeabc519de 100644
--- a/Documentation/devicetree/bindings/arm/arm-boards
+++ b/Documentation/devicetree/bindings/arm/arm-boards
@@ -93,6 +93,14 @@ Required nodes:
   a core-module with regs and the compatible strings
   "arm,core-module-versatile", "syscon"
 
+Optional nodes:
+
+- arm,versatile-ib2-syscon : if the Versatile has an IB2 interface
+  board mounted, this has a separate system controller that is
+  defined in this node.
+  Required properties:
+  compatible = "arm,versatile-ib2-syscon", "syscon"
+
 ARM RealView Boards
 -------------------
 The RealView boards cover tailored evaluation boards that are used to explore
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb  4 06:04:16 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu,  4 Feb 2016 15:04:16 +0100
Subject: [PATCH 07/11] Documentation/DT: add Versatile display bindings
In-Reply-To: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1454594660-7532-8-git-send-email-linus.walleij@linaro.org>

This adds bindings for the LCD displays that can be found connected
to the ARM Versatile reference design, interface boards IB1 and
IB2.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 .../devicetree/bindings/display/panel/epson,l2f50113t00.txt        | 7 +++++++
 .../devicetree/bindings/display/panel/sanyo,alr252rgt.txt          | 7 +++++++
 .../devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt       | 7 +++++++
 .../devicetree/bindings/display/panel/sharp,lq084v1dg21.txt        | 7 +++++++
 Documentation/devicetree/bindings/vendor-prefixes.txt              | 1 +
 5 files changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
 create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt
 create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt
 create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt

diff --git a/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt b/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
new file mode 100644
index 000000000000..58eca804dbe8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
@@ -0,0 +1,7 @@
+Epson Mobile display
+
+Required properties:
+- compatible: should be "epson,l2f50113t00"
+
+This binding is compatible with the panel-dpi binding, which is specified
+in panel-dpi.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt b/Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt
new file mode 100644
index 000000000000..d24562b34cd0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt
@@ -0,0 +1,7 @@
+Sanyo Electric Co. 2.5" panel
+
+Required properties:
+- compatible: should be "sanyo,alr252rgt"
+
+This binding is compatible with the panel-dpi binding, which is specified
+in panel-dpi.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt b/Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt
new file mode 100644
index 000000000000..c1582012d52e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt
@@ -0,0 +1,7 @@
+Sanyo Electric Co. 3.8" panel
+
+Required properties:
+- compatible: should be "sanyo,tm38qv67a02a"
+
+This binding is compatible with the panel-dpi binding, which is specified
+in panel-dpi.txt in this directory.
diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt b/Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt
new file mode 100644
index 000000000000..8318c2422740
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt
@@ -0,0 +1,7 @@
+Sharp 8.4" VGA color TFT
+
+Required properties:
+- compatible: should be "sharp,lq084v1dg21"
+
+This binding is compatible with the panel-dpi binding, which is specified
+in panel-dpi.txt in this directory.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 72e2c5a2b327..da5d8bf13818 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -198,6 +198,7 @@ ricoh	Ricoh Co. Ltd.
 rockchip	Fuzhou Rockchip Electronics Co., Ltd
 samsung	Samsung Semiconductor
 sandisk	Sandisk Corporation
+sanyo	Sanyo Electric Co., Ltd.
 sbs	Smart Battery System
 schindler	Schindler
 seagate	Seagate Technology PLC
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb  4 06:04:19 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu,  4 Feb 2016 15:04:19 +0100
Subject: [PATCH 10/11] ARM: PB1176: define a standard VGA panel
In-Reply-To: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1454594660-7532-11-git-send-email-linus.walleij@linaro.org>

This defines the CLCD block in the PB1176 and adds a standard
640x480 VGA panel to the device tree.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/arm-realview-pb1176.dts | 40 +++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/arm-realview-pb1176.dts b/arch/arm/boot/dts/arm-realview-pb1176.dts
index d012ecf25127..af10d888545b 100644
--- a/arch/arm/boot/dts/arm-realview-pb1176.dts
+++ b/arch/arm/boot/dts/arm-realview-pb1176.dts
@@ -362,6 +362,46 @@
 			clocks = <&uartclk>, <&pclk>;
 			clock-names = "uartclk", "apb_pclk";
 		};
+
+		clcd at 10112000 {
+			compatible = "arm,pl111", "arm,primecell";
+			reg = <0x10112000 0x1000>;
+			interrupt-parent = <&intc_dc1176>;
+			interrupt-names = "combined";
+			interrupts = <0 47 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&oscclk0>, <&pclk>;
+			clock-names = "clcdclk", "apb_pclk";
+
+			port {
+				clcd_pads: endpoint {
+					remote-endpoint = <&clcd_panel>;
+					arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+				};
+			};
+
+			panel {
+				compatible = "panel-dpi";
+
+				port {
+					clcd_panel: endpoint {
+						remote-endpoint = <&clcd_pads>;
+					};
+				};
+
+				/* Standard 640x480 VGA timings */
+				panel-timing {
+					clock-frequency = <25175000>;
+					hactive = <640>;
+					hback-porch = <48>;
+					hfront-porch = <16>;
+					hsync-len = <96>;
+					vactive = <480>;
+					vback-porch = <33>;
+					vfront-porch = <10>;
+					vsync-len = <2>;
+				};
+			};
+		};
 	};
 
 	/* These peripherals are inside the FPGA rather than the DevChip */
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb  4 06:04:18 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu,  4 Feb 2016 15:04:18 +0100
Subject: [PATCH 09/11] ARM: PB11MPCore: define a standard VGA panel
In-Reply-To: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1454594660-7532-10-git-send-email-linus.walleij@linaro.org>

Let's supply a standard VGA panel by default on the PB11MPCore,
this will work with most monitors. If more screen real estate is
desired, users can update the DPI definition.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/arm-realview-pb11mp.dts | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/arm-realview-pb11mp.dts b/arch/arm/boot/dts/arm-realview-pb11mp.dts
index 3d9b1b0f4ffc..9e744c83f5ee 100644
--- a/arch/arm/boot/dts/arm-realview-pb11mp.dts
+++ b/arch/arm/boot/dts/arm-realview-pb11mp.dts
@@ -629,16 +629,17 @@
 					};
 				};
 
+				/* Standard 640x480 VGA timings */
 				panel-timing {
-					clock-frequency = <63500127>;
-					hactive = <1024>;
-					hback-porch = <152>;
-					hfront-porch = <48>;
-					hsync-len = <104>;
-					vactive = <768>;
-					vback-porch = <23>;
-					vfront-porch = <3>;
-					vsync-len = <4>;
+					clock-frequency = <25175000>;
+					hactive = <640>;
+					hback-porch = <48>;
+					hfront-porch = <16>;
+					hsync-len = <96>;
+					vactive = <480>;
+					vback-porch = <33>;
+					vfront-porch = <10>;
+					vsync-len = <2>;
 				};
 			};
 		};
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb  4 06:04:17 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu,  4 Feb 2016 15:04:17 +0100
Subject: [PATCH 08/11] video: ARM CLCD: add special panel hook for Versatiles
In-Reply-To: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1454594660-7532-9-git-send-email-linus.walleij@linaro.org>

This adds a special panel init hook for the ARM reference designs
Integrator (IM-PD1), Versatile and RealView, so we can configure
a DPI panel from device tree and have it working without
boardfiles for these machines.

Basically this is the same code as from the board files, just
moved over to look up the syscon DT node and manipulate the
special CLCD register from their regmap.

Tested on RealView PB11MPcore.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/video/fbdev/Kconfig               |   2 +
 drivers/video/fbdev/amba-clcd-versatile.c | 406 ++++++++++++++++++++++++++++++
 drivers/video/fbdev/amba-clcd-versatile.h |  17 ++
 drivers/video/fbdev/amba-clcd.c           |   4 +-
 4 files changed, 428 insertions(+), 1 deletion(-)
 create mode 100644 drivers/video/fbdev/amba-clcd-versatile.h

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 6dcd91237551..a3fdc4cd1837 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -307,6 +307,8 @@ config PLAT_VERSATILE_CLCD
 	def_bool ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS || ARCH_INTEGRATOR
 	depends on ARM
 	depends on FB_ARMCLCD && FB=y
+	select REGMAP
+	select MFD_SYSCON
 
 config FB_ACORN
 	bool "Acorn VIDC support"
diff --git a/drivers/video/fbdev/amba-clcd-versatile.c b/drivers/video/fbdev/amba-clcd-versatile.c
index 7a8afcd4573e..5d125f77215d 100644
--- a/drivers/video/fbdev/amba-clcd-versatile.c
+++ b/drivers/video/fbdev/amba-clcd-versatile.c
@@ -3,6 +3,12 @@
 #include <linux/amba/bus.h>
 #include <linux/amba/clcd.h>
 #include <linux/platform_data/video-clcd-versatile.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+#include <linux/bitops.h>
+#include "amba-clcd-versatile.h"
 
 static struct clcd_panel vga = {
 	.mode		= {
@@ -180,3 +186,403 @@ void versatile_clcd_remove_dma(struct clcd_fb *fb)
 	dma_free_writecombine(&fb->dev->dev, fb->fb.fix.smem_len,
 			      fb->fb.screen_base, fb->fb.fix.smem_start);
 }
+
+#ifdef CONFIG_OF
+
+static struct regmap *versatile_syscon_map;
+static struct regmap *versatile_ib2_map;
+
+/*
+ * We detect the different syscon types from the compatible strings.
+ */
+enum versatile_clcd {
+	INTEGRATOR_CLCD_CM,
+	VERSATILE_CLCD,
+	REALVIEW_CLCD_EB,
+	REALVIEW_CLCD_PB1176,
+	REALVIEW_CLCD_PB11MP,
+	REALVIEW_CLCD_PBA8,
+	REALVIEW_CLCD_PBX,
+};
+
+static const struct of_device_id versatile_clcd_of_match[] = {
+	{
+		.compatible = "arm,core-module-integrator",
+		.data = (void *)INTEGRATOR_CLCD_CM,
+	},
+	{
+		.compatible = "arm,versatile-sysreg",
+		.data = (void *)VERSATILE_CLCD,
+	},
+	{
+		.compatible = "arm,realview-eb-syscon",
+		.data = (void *)REALVIEW_CLCD_EB,
+	},
+	{
+		.compatible = "arm,realview-pb1176-syscon",
+		.data = (void *)REALVIEW_CLCD_PB1176,
+	},
+	{
+		.compatible = "arm,realview-pb11mp-syscon",
+		.data = (void *)REALVIEW_CLCD_PB11MP,
+	},
+	{
+		.compatible = "arm,realview-pba8-syscon",
+		.data = (void *)REALVIEW_CLCD_PBA8,
+	},
+	{
+		.compatible = "arm,realview-pbx-syscon",
+		.data = (void *)REALVIEW_CLCD_PBX,
+	},
+	{},
+};
+
+/*
+ * Core module CLCD control on the Integrator/CP, bits
+ * 8 thru 19 of the CM_CONTROL register controls a bunch
+ * of CLCD settings.
+ */
+#define INTEGRATOR_HDR_CTRL_OFFSET	0x0C
+#define INTEGRATOR_CLCD_LCDBIASEN	BIT(8)
+#define INTEGRATOR_CLCD_LCDBIASUP	BIT(9)
+#define INTEGRATOR_CLCD_LCDBIASDN	BIT(10)
+/* Bits 11,12,13 controls the LCD type */
+#define INTEGRATOR_CLCD_LCDMUX_MASK	(BIT(11)|BIT(12)|BIT(13))
+#define INTEGRATOR_CLCD_LCDMUX_LCD24	BIT(11)
+#define INTEGRATOR_CLCD_LCDMUX_VGA565	BIT(12)
+#define INTEGRATOR_CLCD_LCDMUX_SHARP	(BIT(11)|BIT(12))
+#define INTEGRATOR_CLCD_LCDMUX_VGA555	BIT(13)
+#define INTEGRATOR_CLCD_LCDMUX_VGA24	(BIT(11)|BIT(12)|BIT(13))
+#define INTEGRATOR_CLCD_LCD0_EN		BIT(14)
+#define INTEGRATOR_CLCD_LCD1_EN		BIT(15)
+/* R/L flip on Sharp */
+#define INTEGRATOR_CLCD_LCD_STATIC1	BIT(16)
+/* U/D flip on Sharp */
+#define INTEGRATOR_CLCD_LCD_STATIC2	BIT(17)
+/* No connection on Sharp */
+#define INTEGRATOR_CLCD_LCD_STATIC	BIT(18)
+/* 0 = 24bit VGA, 1 = 18bit VGA */
+#define INTEGRATOR_CLCD_LCD_N24BITEN	BIT(19)
+
+#define INTEGRATOR_CLCD_MASK		(INTEGRATOR_CLCD_LCDMUX_MASK | \
+					 INTEGRATOR_CLCD_LCD0_EN | \
+					 INTEGRATOR_CLCD_LCD1_EN | \
+					 INTEGRATOR_CLCD_LCD_STATIC1 | \
+					 INTEGRATOR_CLCD_LCD_STATIC2 | \
+					 INTEGRATOR_CLCD_LCD_STATIC | \
+					 INTEGRATOR_CLCD_LCD_N24BITEN)
+
+static void integrator_clcd_enable(struct clcd_fb *fb)
+{
+	struct fb_var_screeninfo *var = &fb->fb.var;
+	u32 val;
+
+	dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");
+
+	val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
+		INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
+	if (var->bits_per_pixel <= 8 ||
+	    (var->bits_per_pixel == 16 && var->green.length == 5))
+		/* Pseudocolor, RGB555, BGR555 */
+		val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
+	else if (fb->fb.var.bits_per_pixel <= 16)
+		/* truecolor RGB565 */
+		val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
+	else
+		val = 0; /* no idea for this, don't trust the docs */
+
+	regmap_update_bits(versatile_syscon_map,
+			   INTEGRATOR_HDR_CTRL_OFFSET,
+			   0,
+			   INTEGRATOR_CLCD_MASK);
+}
+
+/*
+ * This configuration register in the Versatile and RealView
+ * family is uniformly present but appears more and more
+ * unutilized starting with the RealView series.
+ */
+#define SYS_CLCD			0x50
+#define SYS_CLCD_MODE_MASK		(BIT(0)|BIT(1))
+#define SYS_CLCD_MODE_888		0
+#define SYS_CLCD_MODE_5551		BIT(0)
+#define SYS_CLCD_MODE_565_R_LSB		BIT(1)
+#define SYS_CLCD_MODE_565_B_LSB		(BIT(0)|BIT(1))
+#define SYS_CLCD_CONNECTOR_MASK		(BIT(2)|BIT(3)|BIT(4)|BIT(5))
+#define SYS_CLCD_NLCDIOON		BIT(2)
+#define SYS_CLCD_VDDPOSSWITCH		BIT(3)
+#define SYS_CLCD_PWR3V5SWITCH		BIT(4)
+#define SYS_CLCD_VDDNEGSWITCH		BIT(5)
+#define SYS_CLCD_TSNSS			BIT(6) /* touchscreen enable */
+#define SYS_CLCD_SSPEXP			BIT(7) /* SSP expansion enable */
+
+/* The Versatile can detect the connected panel type */
+#define SYS_CLCD_CLCDID_MASK		(BIT(8)|BIT(9)|BIT(10)|BIT(11)|BIT(12))
+#define SYS_CLCD_ID_SANYO_3_8		(0x00 << 8)
+#define SYS_CLCD_ID_SHARP_8_4		(0x01 << 8)
+#define SYS_CLCD_ID_EPSON_2_2		(0x02 << 8)
+#define SYS_CLCD_ID_SANYO_2_5		(0x07 << 8)
+#define SYS_CLCD_ID_VGA			(0x1f << 8)
+
+#define SYS_CLCD_TSNDAV			BIT(13) /* data ready from TS */
+
+/* IB2 control register for the Versatile daughterboard */
+#define IB2_CTRL			0x00
+#define IB2_CTRL_LCD_SD			BIT(1) /* 1 = shut down LCD */
+#define IB2_CTRL_LCD_BL_ON		BIT(0)
+#define IB2_CTRL_LCD_MASK		(BIT(0)|BIT(1))
+
+static void versatile_clcd_disable(struct clcd_fb *fb)
+{
+	dev_info(&fb->dev->dev, "disable Versatile CLCD connectors\n");
+	regmap_update_bits(versatile_syscon_map,
+			   SYS_CLCD,
+			   SYS_CLCD_CONNECTOR_MASK,
+			   0);
+
+	/* If we're on an IB2 daughterboard, turn off display */
+	if (versatile_ib2_map) {
+		dev_info(&fb->dev->dev, "disable IB2 display\n");
+		regmap_update_bits(versatile_ib2_map,
+				   IB2_CTRL,
+				   IB2_CTRL_LCD_MASK,
+				   IB2_CTRL_LCD_SD);
+	}
+}
+
+static void versatile_clcd_enable(struct clcd_fb *fb)
+{
+	struct fb_var_screeninfo *var = &fb->fb.var;
+	u32 val = 0;
+
+	dev_info(&fb->dev->dev, "enable Versatile CLCD connectors\n");
+	switch (var->green.length) {
+	case 5:
+		val |= SYS_CLCD_MODE_5551;
+		break;
+	case 6:
+		if (var->red.offset == 0)
+			val |= SYS_CLCD_MODE_565_R_LSB;
+		else
+			val |= SYS_CLCD_MODE_565_B_LSB;
+		break;
+	case 8:
+		val |= SYS_CLCD_MODE_888;
+		break;
+	}
+
+	/* Set up the MUX */
+	regmap_update_bits(versatile_syscon_map,
+			   SYS_CLCD,
+			   SYS_CLCD_MODE_MASK,
+			   val);
+
+	/* Then enable the display */
+	regmap_update_bits(versatile_syscon_map,
+			   SYS_CLCD,
+			   SYS_CLCD_CONNECTOR_MASK,
+			   SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH);
+
+	/* If we're on an IB2 daughterboard, turn on display */
+	if (versatile_ib2_map) {
+		dev_info(&fb->dev->dev, "enable IB2 display\n");
+		regmap_update_bits(versatile_ib2_map,
+				   IB2_CTRL,
+				   IB2_CTRL_LCD_MASK,
+				   IB2_CTRL_LCD_BL_ON);
+	}
+}
+
+static void versatile_clcd_decode(struct clcd_fb *fb, struct clcd_regs *regs)
+{
+	clcdfb_decode(fb, regs);
+
+	/* Always clear BGR for RGB565: we do the routing externally */
+	if (fb->fb.var.green.length == 6)
+		regs->cntl &= ~CNTL_BGR;
+}
+
+static void realview_clcd_disable(struct clcd_fb *fb)
+{
+	dev_info(&fb->dev->dev, "disable RealView CLCD connectors\n");
+	regmap_update_bits(versatile_syscon_map,
+			   SYS_CLCD,
+			   SYS_CLCD_CONNECTOR_MASK,
+			   0);
+}
+
+static void realview_clcd_enable(struct clcd_fb *fb)
+{
+	dev_info(&fb->dev->dev, "enable RealView CLCD connectors\n");
+	regmap_update_bits(versatile_syscon_map,
+			   SYS_CLCD,
+			   SYS_CLCD_CONNECTOR_MASK,
+			   SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH);
+}
+
+struct versatile_panel {
+	u32 id;
+	char *compatible;
+	bool ib2;
+};
+
+static const struct versatile_panel versatile_panels[] = {
+	{
+		.id = SYS_CLCD_ID_VGA,
+		.compatible = "VGA",
+	},
+	{
+		.id = SYS_CLCD_ID_SANYO_3_8,
+		.compatible = "sanyo,tm38qv67a02a",
+	},
+	{
+		.id = SYS_CLCD_ID_SHARP_8_4,
+		.compatible = "sharp,lq084v1dg21",
+	},
+	{
+		.id = SYS_CLCD_ID_EPSON_2_2,
+		.compatible = "epson,l2f50113t00",
+	},
+	{
+		.id = SYS_CLCD_ID_SANYO_2_5,
+		.compatible = "sanyo,alr252rgt",
+		.ib2 = true,
+	},
+};
+
+static void versatile_panel_probe(struct device *dev,
+				  struct device_node **endpoint)
+{
+	struct versatile_panel const *vpanel = NULL;
+	struct device_node *ep = NULL;
+	struct device_node *panel = NULL;
+	u32 val;
+	int ret;
+	int i;
+
+	/*
+	 * The Versatile CLCD has a panel auto-detection mechanism.
+	 * We use this and look for the compatible panel in the
+	 * device tree.
+	 */
+	ret = regmap_read(versatile_syscon_map, SYS_CLCD, &val);
+	if (ret) {
+		dev_err(dev, "cannot read CLCD syscon register\n");
+		return;
+	}
+	val &= SYS_CLCD_CLCDID_MASK;
+	dev_info(dev, "SYS_CLCD=%08x\n", val);
+
+	/* First find corresponding panel information */
+	for (i = 0; i < ARRAY_SIZE(versatile_panels); i++) {
+		vpanel = &versatile_panels[i];
+
+		if (val == vpanel->id) {
+			dev_err(dev, "autodetected panel \"%s\"\n",
+				vpanel->compatible);
+			break;
+		}
+	}
+	if (i == ARRAY_SIZE(versatile_panels)) {
+		dev_err(dev, "could not auto-detect panel\n");
+		return;
+	}
+
+	/* Then look for a compatible endpoint/panel */
+	for_each_endpoint_of_node(dev->of_node, ep) {
+		panel = of_graph_get_remote_port_parent(ep);
+		if (!panel) {
+			dev_err(dev, "could not locate remote port for panel\n");
+			return;
+		}
+
+		if (of_device_is_compatible(panel, vpanel->compatible))
+			break;
+	}
+	if (ep == NULL) {
+		dev_err(dev, "could not find a panel compatible with \"%s\"\n",
+			vpanel->compatible);
+		return;
+	}
+
+
+	/*
+	 * If we have a Sanyo 2.5" port
+	 * that we're running on an IB2 and proceed to look for the
+	 * IB2 syscon regmap.
+	 */
+	if (!vpanel->ib2) {
+		/* Tell the driver to use this panel */
+		*endpoint = ep;
+		return;
+	}
+
+	versatile_ib2_map = syscon_regmap_lookup_by_compatible(
+		"arm,versatile-ib2-syscon");
+	if (IS_ERR(versatile_ib2_map)) {
+		dev_err(dev, "could not locate IB2 control register\n");
+		versatile_ib2_map = NULL;
+		return;
+	}
+	*endpoint = ep;
+}
+
+int versatile_clcd_init_panel(struct clcd_fb *fb,
+			      struct device_node **endpoint)
+{
+	const struct of_device_id *clcd_id;
+	enum versatile_clcd versatile_clcd_type;
+	struct device_node *np;
+	struct regmap *map;
+	struct device *dev = &fb->dev->dev;
+
+	np = of_find_matching_node_and_match(NULL, versatile_clcd_of_match,
+					     &clcd_id);
+	if (!np) {
+		dev_err(dev, "no Versatile syscon node\n");
+		return -ENODEV;
+	}
+	versatile_clcd_type = (enum versatile_clcd)clcd_id->data;
+
+	map = syscon_node_to_regmap(np);
+	if (!map) {
+		dev_err(dev, "no Versatile syscon regmap\n");
+		return -ENODEV;
+	}
+
+	switch (versatile_clcd_type) {
+	case INTEGRATOR_CLCD_CM:
+		versatile_syscon_map = map;
+		fb->board->enable = integrator_clcd_enable;
+		/* Override the caps, we have only these */
+		fb->board->caps = CLCD_CAP_5551 | CLCD_CAP_RGB565 |
+			CLCD_CAP_888;
+		dev_info(dev, "set up callbacks for Integrator PL110\n");
+		break;
+	case VERSATILE_CLCD:
+		versatile_syscon_map = map;
+		fb->board->enable = versatile_clcd_enable;
+		fb->board->disable = versatile_clcd_disable;
+		fb->board->decode = versatile_clcd_decode;
+		versatile_panel_probe(dev, endpoint);
+		dev_info(dev, "set up callbacks for Versatile\n");
+		break;
+	case REALVIEW_CLCD_EB:
+	case REALVIEW_CLCD_PB1176:
+	case REALVIEW_CLCD_PB11MP:
+	case REALVIEW_CLCD_PBA8:
+	case REALVIEW_CLCD_PBX:
+		versatile_syscon_map = map;
+		fb->board->enable = realview_clcd_enable;
+		fb->board->disable = realview_clcd_disable;
+		dev_info(dev, "set up callbacks for RealView PL111\n");
+		break;
+	default:
+		dev_info(dev, "unknown Versatile system controller\n");
+		break;
+	}
+
+	return 0;
+}
+
+#endif
diff --git a/drivers/video/fbdev/amba-clcd-versatile.h b/drivers/video/fbdev/amba-clcd-versatile.h
new file mode 100644
index 000000000000..dc44557a2466
--- /dev/null
+++ b/drivers/video/fbdev/amba-clcd-versatile.h
@@ -0,0 +1,17 @@
+/*
+ * Special local versatile callbacks
+ */
+#include <linux/of.h>
+#include <linux/amba/bus.h>
+#include <linux/platform_data/video-clcd-versatile.h>
+
+#if defined(CONFIG_PLAT_VERSATILE_CLCD) && defined(CONFIG_OF)
+int versatile_clcd_init_panel(struct clcd_fb *fb,
+			      struct device_node **endpoint);
+#else
+static inline int versatile_clcd_init_panel(struct clcd_fb *fb,
+				struct device_node **endpoint)
+{
+	return 0;
+}
+#endif
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 53c5ec31168d..e1897cb657f5 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -38,6 +38,7 @@
 #include <asm/sizes.h>
 
 #include "amba-clcd-nomadik.h"
+#include "amba-clcd-versatile.h"
 
 #define to_clcd(info)	container_of(info, struct clcd_fb, fb)
 
@@ -1042,7 +1043,8 @@ static int clcdfb_remove(struct amba_device *dev)
 }
 
 static struct clcd_vendor_data vendor_arm = {
-	/* No special business */
+	/* Sets up the versatile board displays */
+	.init_panel = versatile_clcd_init_panel,
 };
 
 static struct clcd_vendor_data vendor_nomadik = {
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb  4 06:04:20 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu,  4 Feb 2016 15:04:20 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device tree
In-Reply-To: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>

This moves the versatile CLCD configuration to the device tree by:

- Deleting the board file set-up of CLCD displays and quirks,
  instead relying on the driver to handle this. The driver will
  attempt to auto-detect (like the board file did) and match to
  a corresponding panel in the device tree.

- Defining all auto-detectable panels in the device tree for the
  versatile-ab, defaulting the first one to VGA. The right
  panel will be selected at panel initialization, and should
  just work for the IB1 daughterboard panels, like EPSON.

- Creating a special superset DTS file for the IB2 daughterboard
  (phone form-factor) equipped Versatile, overriding the default VGA
  display with the Sanyo 2.5" portrait display definitions, so that
  the IB2-equipped Versatile can be used with this. This follows
  the pattern of how we define the Versatile PB as a superset of
  Versatile AB.

Tested on Versatile AB with just VGA with the default device tree,
and with the IB2 daughterboard with the custom IB2 device tree.
Tested to shunt in XVGA by modifying the device tree and this works
too. Also tested on QEMU for Versatile in both VGA and Sanyo 2.5"
mode. I don't have the IB1 daughterboard and its add-on displays,
but it should work as long as the detection mechanism and device
tree parameters are sound.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/Makefile             |   1 +
 arch/arm/boot/dts/versatile-ab-ib2.dts |  20 ++++
 arch/arm/boot/dts/versatile-ab.dts     | 203 ++++++++++++++++++++++++++++++++-
 arch/arm/mach-versatile/versatile_dt.c | 162 --------------------------
 4 files changed, 220 insertions(+), 166 deletions(-)
 create mode 100644 arch/arm/boot/dts/versatile-ab-ib2.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70e8b26..76baaa51080c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -743,6 +743,7 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
 	uniphier-proxstream2-vodka.dtb
 dtb-$(CONFIG_ARCH_VERSATILE) += \
 	versatile-ab.dtb \
+	versatile-ab-ib2.dtb \
 	versatile-pb.dtb
 dtb-$(CONFIG_ARCH_VEXPRESS) += \
 	vexpress-v2p-ca5s.dtb \
diff --git a/arch/arm/boot/dts/versatile-ab-ib2.dts b/arch/arm/boot/dts/versatile-ab-ib2.dts
new file mode 100644
index 000000000000..4b98b5382922
--- /dev/null
+++ b/arch/arm/boot/dts/versatile-ab-ib2.dts
@@ -0,0 +1,20 @@
+#include <versatile-ab.dts>
+
+/ {
+	model = "ARM Versatile AB + IB2 board";
+
+	/* Special IB2 control register */
+	ib2_syscon at 27000000 {
+		compatible = "arm,versatile-ib2-syscon", "syscon", "simple-mfd";
+		reg = <0x27000000 0x4>;
+
+		led at 00.4 {
+			compatible = "register-bit-led";
+			offset = <0x00>;
+			mask = <0x10>;
+			label = "versatile-ib2:0";
+			linux,default-trigger = "heartbeat";
+			default-state = "on";
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/versatile-ab.dts b/arch/arm/boot/dts/versatile-ab.dts
index 6fd7efbead34..836511cf8046 100644
--- a/arch/arm/boot/dts/versatile-ab.dts
+++ b/arch/arm/boot/dts/versatile-ab.dts
@@ -29,6 +29,147 @@
 		clock-frequency = <24000000>;
 	};
 
+	vga_panel {
+		compatible = "VGA", "panel-dpi";
+		port {
+			clcd_vga_panel: endpoint {
+				remote-endpoint = <&clcd_vga_pads>;
+			};
+		};
+
+		/* Standard 640x480 VGA timings */
+		panel-timing {
+			clock-frequency = <25175000>;
+			pixelclk-active = <0>;
+			hactive = <640>;
+			hback-porch = <48>;
+			hfront-porch = <16>;
+			hsync-len = <96>;
+			vactive = <480>;
+			vback-porch = <33>;
+			vfront-porch = <10>;
+			vsync-len = <2>;
+		};
+	};
+
+	xvga_panel {
+		compatible = "XVGA", "panel-dpi";
+		port {
+			clcd_xvga_panel: endpoint {
+				remote-endpoint = <&clcd_xvga_pads>;
+			};
+		};
+
+		/* Standard 1024x768 XVGA timings */
+		panel-timing {
+			clock-frequency = <63500127>;
+			pixelclk-active = <0>;
+			hactive = <1024>;
+			hback-porch = <152>;
+			hfront-porch = <48>;
+			hsync-len = <104>;
+			vactive = <768>;
+			vback-porch = <23>;
+			vfront-porch = <3>;
+			vsync-len = <4>;
+		};
+	};
+
+	sanyo38_panel {
+		compatible = "sanyo,tm38qv67a02a", "panel-dpi";
+		port {
+			clcd_sanyo38_panel: endpoint {
+				remote-endpoint = <&clcd_sanyo38_pads>;
+			};
+		};
+
+		panel-timing {
+			clock-frequency = <10000000>;
+			pixelclk-active = <1>;
+			hactive = <320>;
+			hback-porch = <6>;
+			hfront-porch = <6>;
+			hsync-len = <6>;
+			vactive = <240>;
+			vback-porch = <6>;
+			vfront-porch = <6>;
+			vsync-len = <0>;
+		};
+	};
+
+	sharp84_panel {
+		compatible = "sharp,lq084v1dg21", "panel-dpi";
+		port {
+			clcd_sharp84_panel: endpoint {
+				remote-endpoint = <&clcd_sharp84_pads>;
+			};
+		};
+
+		/* Standard 640x480 VGA timings */
+		panel-timing {
+			clock-frequency = <25175000>;
+			pixelclk-active = <0>;
+			hactive = <640>;
+			hback-porch = <48>;
+			hfront-porch = <16>;
+			hsync-len = <96>;
+			vactive = <480>;
+			vback-porch = <33>;
+			vfront-porch = <10>;
+			vsync-len = <2>;
+		};
+	};
+
+	/*
+	 * The IB2 has a Sanyo ALR252RGT QVGA panel mounted.
+	 */
+	sanyo25_panel {
+		compatible = "sanyo,alr252rgt", "panel-dpi";
+		port {
+			clcd_sanyo25_panel: endpoint {
+				remote-endpoint = <&clcd_sanyo25_pads>;
+			};
+		};
+
+		panel-timing {
+			clock-frequency = <5440000>;
+			pixelclk-active = <0>;
+			hsync-active = <0>;
+			vsync-active = <0>;
+			de-active = <1>;
+			hactive = <240>;
+			hback-porch = <20>;
+			hfront-porch = <10>;
+			hsync-len = <10>;
+			vactive = <320>;
+			vback-porch = <2>;
+			vfront-porch = <2>;
+			vsync-len = <2>;
+		};
+	};
+
+	epson_panel {
+		compatible = "epson,l2f50113t00", "panel-dpi";
+		port {
+			clcd_epson_panel: endpoint {
+				remote-endpoint = <&clcd_epson_pads>;
+			};
+		};
+
+		panel-timing {
+			clock-frequency = <16000000>;
+			pixelclk-active = <0>;
+			hactive = <176>;
+			hback-porch = <3>;
+			hfront-porch = <2>;
+			hsync-len = <3>;
+			vactive = <220>;
+			vback-porch = <1>;
+			vfront-porch = <0>;
+			vsync-len = <2>;
+		};
+	};
+
 	core-module at 10000000 {
 		compatible = "arm,core-module-versatile", "syscon", "simple-mfd";
 		reg = <0x10000000 0x200>;
@@ -93,10 +234,20 @@
 			default-state = "off";
 		};
 
-		/* OSC1 on AB, OSC4 on PB */
-		osc1: cm_aux_osc at 24M {
+		oscclk0: osc0 at 0c {
+			compatible = "arm,syscon-icst307";
 			#clock-cells = <0>;
-			compatible = "arm,versatile-cm-auxosc";
+			lock-offset = <0x20>;
+			vco-offset = <0x0C>;
+			clocks = <&xtal24mhz>;
+		};
+
+		/* This is called OSC1 on AB, OSC4 on PB, call it OSC4 here */
+		oscclk4: osc4 at 1c {
+			compatible = "arm,syscon-icst307";
+			#clock-cells = <0>;
+			lock-offset = <0x20>;
+			vco-offset = <0x1C>;
 			clocks = <&xtal24mhz>;
 		};
 
@@ -227,8 +378,52 @@
 			compatible = "arm,pl110", "arm,primecell";
 			reg = <0x10120000 0x1000>;
 			interrupts = <16>;
-			clocks = <&osc1>, <&pclk>;
+			clocks = <&oscclk4>, <&pclk>;
 			clock-names = "clcd", "apb_pclk";
+			/* 16bpp @ 25.175MHz = 50350000 bytes per second */
+			max-memory-bandwidth = <50350000>;
+
+			port {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				/*
+				 * The CLCD connects to either of these panels.
+				 * at run-time, board-specific code will
+				 * detect and select the right one. If no
+				 * panel is detected, the first one (VGA)
+				 * will be used by default.
+				 */
+				clcd_vga_pads: endpoint at 0 {
+					reg = <0>;
+					remote-endpoint = <&clcd_vga_panel>;
+					arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
+				};
+				clcd_xvga_pads: endpoint at 1 {
+					reg = <1>;
+					remote-endpoint = <&clcd_xvga_panel>;
+					arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
+				};
+				clcd_sanyo38_pads: endpoint at 2 {
+					reg = <2>;
+					remote-endpoint = <&clcd_sanyo38_panel>;
+					arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+				};
+				clcd_sharp84_pads: endpoint at 3 {
+					reg = <3>;
+					remote-endpoint = <&clcd_sharp84_panel>;
+					arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+				};
+				clcd_sanyo25_pads: endpoint at 4 {
+					reg = <4>;
+					remote-endpoint = <&clcd_sanyo25_panel>;
+					arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+				};
+				clcd_epson_pads: endpoint at 5 {
+					reg = <5>;
+					remote-endpoint = <&clcd_epson_panel>;
+					arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+				};
+			};
 		};
 
 		sctl at 101e0000 {
diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index c44871851255..ebe27945fea5 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -29,8 +29,6 @@
 #include <linux/of_platform.h>
 #include <linux/slab.h>
 #include <linux/amba/bus.h>
-#include <linux/amba/clcd.h>
-#include <linux/platform_data/video-clcd-versatile.h>
 #include <linux/amba/mmci.h>
 #include <linux/mtd/physmap.h>
 #include <asm/mach-types.h>
@@ -57,7 +55,6 @@
 #define VERSATILE_SYS_PCICTL_OFFSET           0x44
 #define VERSATILE_SYS_MCI_OFFSET              0x48
 #define VERSATILE_SYS_FLASH_OFFSET            0x4C
-#define VERSATILE_SYS_CLCD_OFFSET             0x50
 
 /*
  * VERSATILE_SYS_FLASH
@@ -69,10 +66,7 @@
  */
 #define VERSATILE_MMCI0_BASE           0x10005000	/* MMC interface */
 #define VERSATILE_MMCI1_BASE           0x1000B000	/* MMC Interface */
-#define VERSATILE_CLCD_BASE            0x10120000	/* CLCD */
 #define VERSATILE_SCTL_BASE            0x101E0000	/* System controller */
-#define VERSATILE_IB2_BASE             0x24000000	/* IB2 module */
-#define VERSATILE_IB2_CTL_BASE		(VERSATILE_IB2_BASE + 0x03000000)
 
 /*
  * System controller bit assignment
@@ -86,7 +80,6 @@
 #define VERSATILE_TIMER4_EnSel	21
 
 static void __iomem *versatile_sys_base;
-static void __iomem *versatile_ib2_ctrl;
 
 static void versatile_flash_set_vpp(struct platform_device *pdev, int on)
 {
@@ -149,158 +142,6 @@ static struct mmci_platform_data mmc1_plat_data = {
 };
 
 /*
- * CLCD support.
- */
-#define SYS_CLCD_MODE_MASK	(3 << 0)
-#define SYS_CLCD_MODE_888	(0 << 0)
-#define SYS_CLCD_MODE_5551	(1 << 0)
-#define SYS_CLCD_MODE_565_RLSB	(2 << 0)
-#define SYS_CLCD_MODE_565_BLSB	(3 << 0)
-#define SYS_CLCD_NLCDIOON	(1 << 2)
-#define SYS_CLCD_VDDPOSSWITCH	(1 << 3)
-#define SYS_CLCD_PWR3V5SWITCH	(1 << 4)
-#define SYS_CLCD_ID_MASK	(0x1f << 8)
-#define SYS_CLCD_ID_SANYO_3_8	(0x00 << 8)
-#define SYS_CLCD_ID_UNKNOWN_8_4	(0x01 << 8)
-#define SYS_CLCD_ID_EPSON_2_2	(0x02 << 8)
-#define SYS_CLCD_ID_SANYO_2_5	(0x07 << 8)
-#define SYS_CLCD_ID_VGA		(0x1f << 8)
-
-static bool is_sanyo_2_5_lcd;
-
-/*
- * Disable all display connectors on the interface module.
- */
-static void versatile_clcd_disable(struct clcd_fb *fb)
-{
-	void __iomem *sys_clcd = versatile_sys_base + VERSATILE_SYS_CLCD_OFFSET;
-	u32 val;
-
-	val = readl(sys_clcd);
-	val &= ~SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
-	writel(val, sys_clcd);
-
-	/*
-	 * If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light off
-	 */
-	if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
-		unsigned long ctrl;
-
-		ctrl = readl(versatile_ib2_ctrl);
-		ctrl &= ~0x01;
-		writel(ctrl, versatile_ib2_ctrl);
-	}
-}
-
-/*
- * Enable the relevant connector on the interface module.
- */
-static void versatile_clcd_enable(struct clcd_fb *fb)
-{
-	struct fb_var_screeninfo *var = &fb->fb.var;
-	void __iomem *sys_clcd = versatile_sys_base + VERSATILE_SYS_CLCD_OFFSET;
-	u32 val;
-
-	val = readl(sys_clcd);
-	val &= ~SYS_CLCD_MODE_MASK;
-
-	switch (var->green.length) {
-	case 5:
-		val |= SYS_CLCD_MODE_5551;
-		break;
-	case 6:
-		if (var->red.offset == 0)
-			val |= SYS_CLCD_MODE_565_RLSB;
-		else
-			val |= SYS_CLCD_MODE_565_BLSB;
-		break;
-	case 8:
-		val |= SYS_CLCD_MODE_888;
-		break;
-	}
-
-	/*
-	 * Set the MUX
-	 */
-	writel(val, sys_clcd);
-
-	/*
-	 * And now enable the PSUs
-	 */
-	val |= SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH;
-	writel(val, sys_clcd);
-
-	/*
-	 * If the LCD is Sanyo 2x5 in on the IB2 board, turn the back-light on
-	 */
-	if (of_machine_is_compatible("arm,versatile-ab") && is_sanyo_2_5_lcd) {
-		unsigned long ctrl;
-
-		ctrl = readl(versatile_ib2_ctrl);
-		ctrl |= 0x01;
-		writel(ctrl, versatile_ib2_ctrl);
-	}
-}
-
-/*
- * Detect which LCD panel is connected, and return the appropriate
- * clcd_panel structure.  Note: we do not have any information on
- * the required timings for the 8.4in panel, so we presently assume
- * VGA timings.
- */
-static int versatile_clcd_setup(struct clcd_fb *fb)
-{
-	void __iomem *sys_clcd = versatile_sys_base + VERSATILE_SYS_CLCD_OFFSET;
-	const char *panel_name;
-	u32 val;
-
-	is_sanyo_2_5_lcd = false;
-
-	val = readl(sys_clcd) & SYS_CLCD_ID_MASK;
-	if (val == SYS_CLCD_ID_SANYO_3_8)
-		panel_name = "Sanyo TM38QV67A02A";
-	else if (val == SYS_CLCD_ID_SANYO_2_5) {
-		panel_name = "Sanyo QVGA Portrait";
-		is_sanyo_2_5_lcd = true;
-	} else if (val == SYS_CLCD_ID_EPSON_2_2)
-		panel_name = "Epson L2F50113T00";
-	else if (val == SYS_CLCD_ID_VGA)
-		panel_name = "VGA";
-	else {
-		printk(KERN_ERR "CLCD: unknown LCD panel ID 0x%08x, using VGA\n",
-			val);
-		panel_name = "VGA";
-	}
-
-	fb->panel = versatile_clcd_get_panel(panel_name);
-	if (!fb->panel)
-		return -EINVAL;
-
-	return versatile_clcd_setup_dma(fb, SZ_1M);
-}
-
-static void versatile_clcd_decode(struct clcd_fb *fb, struct clcd_regs *regs)
-{
-	clcdfb_decode(fb, regs);
-
-	/* Always clear BGR for RGB565: we do the routing externally */
-	if (fb->fb.var.green.length == 6)
-		regs->cntl &= ~CNTL_BGR;
-}
-
-static struct clcd_board clcd_plat_data = {
-	.name		= "Versatile",
-	.caps		= CLCD_CAP_5551 | CLCD_CAP_565 | CLCD_CAP_888,
-	.check		= clcdfb_check,
-	.decode		= versatile_clcd_decode,
-	.disable	= versatile_clcd_disable,
-	.enable		= versatile_clcd_enable,
-	.setup		= versatile_clcd_setup,
-	.mmap		= versatile_clcd_mmap_dma,
-	.remove		= versatile_clcd_remove_dma,
-};
-
-/*
  * Lookup table for attaching a specific name and platform_data pointer to
  * devices as they get created by of_platform_populate().  Ideally this table
  * would not exist, but the current clock implementation depends on some devices
@@ -309,7 +150,6 @@ static struct clcd_board clcd_plat_data = {
 struct of_dev_auxdata versatile_auxdata_lookup[] __initdata = {
 	OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI0_BASE, "fpga:05", &mmc0_plat_data),
 	OF_DEV_AUXDATA("arm,primecell", VERSATILE_MMCI1_BASE, "fpga:0b", &mmc1_plat_data),
-	OF_DEV_AUXDATA("arm,primecell", VERSATILE_CLCD_BASE, "dev:20", &clcd_plat_data),
 	{}
 };
 
@@ -400,8 +240,6 @@ static void __init versatile_dt_init(void)
 		versatile_sys_base = of_iomap(np, 0);
 	WARN_ON(!versatile_sys_base);
 
-	versatile_ib2_ctrl = ioremap(VERSATILE_IB2_CTL_BASE, SZ_4K);
-
 	versatile_dt_pci_init();
 
 	platform_device_register(&versatile_flash_device);
-- 
2.4.3



From bcrl at kvack.org  Thu Feb  4 06:08:22 2016
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Thu, 4 Feb 2016 09:08:22 -0500
Subject: linux-next: build failure after merge of the aio tree
In-Reply-To: <20160204135056.GE10826@n2100.arm.linux.org.uk>
References: <20160112164034.0fe945a7@canb.auug.org.au>
 <20160112163835.GD347@kvack.org> <20160127134024.0fababf6@canb.auug.org.au>
 <20160129113056.GP10826@n2100.arm.linux.org.uk>
 <CAMuHMdUy-cqeN8COO4rdpY-mOH+6gth40wB31-edkj8CO5PFCw@mail.gmail.com>
 <20160204131959.6695c7bf@canb.auug.org.au> <20160204134142.GA16315@kvack.org>
 <20160204135056.GE10826@n2100.arm.linux.org.uk>
Message-ID: <20160204140822.GB16315@kvack.org>

On Thu, Feb 04, 2016 at 01:50:56PM +0000, Russell King - ARM Linux wrote:
> > I am still convinced that this is an architecture issue.  Given that 64 bit 
> > values work in the *get_user implementations on other architectures, I see 
> > no reason there should need to be a workaround for this in common code.
> 
> So you're happy to break x86-32 then...

x86-32 works fine.

		-ben
-- 
"Thought is the essence of where you are now."


From linux at arm.linux.org.uk  Thu Feb  4 06:12:53 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 4 Feb 2016 14:12:53 +0000
Subject: linux-next: build failure after merge of the aio tree
In-Reply-To: <20160204140822.GB16315@kvack.org>
References: <20160112164034.0fe945a7@canb.auug.org.au>
 <20160112163835.GD347@kvack.org>
 <20160127134024.0fababf6@canb.auug.org.au>
 <20160129113056.GP10826@n2100.arm.linux.org.uk>
 <CAMuHMdUy-cqeN8COO4rdpY-mOH+6gth40wB31-edkj8CO5PFCw@mail.gmail.com>
 <20160204131959.6695c7bf@canb.auug.org.au>
 <20160204134142.GA16315@kvack.org>
 <20160204135056.GE10826@n2100.arm.linux.org.uk>
 <20160204140822.GB16315@kvack.org>
Message-ID: <20160204141253.GF10826@n2100.arm.linux.org.uk>

On Thu, Feb 04, 2016 at 09:08:22AM -0500, Benjamin LaHaise wrote:
> On Thu, Feb 04, 2016 at 01:50:56PM +0000, Russell King - ARM Linux wrote:
> > > I am still convinced that this is an architecture issue.  Given that 64 bit 
> > > values work in the *get_user implementations on other architectures, I see 
> > > no reason there should need to be a workaround for this in common code.
> > 
> > So you're happy to break x86-32 then...
> 
> x86-32 works fine.

Let me repeat the quote from my previous email:

#define __get_user(x, ptr)                                              \
        __get_user_nocheck((x), (ptr), sizeof(*(ptr)))

#define __get_user_nocheck(x, ptr, size)                                \
({                                                                      \
        int __gu_err;                                                   \
        unsigned long __gu_val;                                         \
        __uaccess_begin();                                              \
        __get_user_size(__gu_val, (ptr), (size), __gu_err, -EFAULT);    \
        __uaccess_end();                                                \
        (x) = (__force __typeof__(*(ptr)))__gu_val;                     \
        __builtin_expect(__gu_err, 0);                                  \
})

#define __get_user_size(x, ptr, size, retval, errret)                   \
do {                                                                    \
        retval = 0;                                                     \
        __chk_user_ptr(ptr);                                            \
        switch (size) {                                                 \
        case 1:                                                         \
                __get_user_asm(x, ptr, retval, "b", "b", "=q", errret); \
                break;                                                  \
        case 2:                                                         \
                __get_user_asm(x, ptr, retval, "w", "w", "=r", errret); \
                break;                                                  \
        case 4:                                                         \
                __get_user_asm(x, ptr, retval, "l", "k", "=r", errret); \
                break;                                                  \
        case 8:                                                         \
                __get_user_asm_u64(x, ptr, retval, errret);             \
                break;                                                  \
        default:                                                        \
                (x) = __get_user_bad();                                 \
        }                                                               \
} while (0)

#ifdef CONFIG_X86_32
#define __get_user_asm_u64(x, ptr, retval, errret)      (x) = __get_user_bad()
#define __get_user_asm_ex_u64(x, ptr)                   (x) = __get_user_bad()
#else
#define __get_user_asm_u64(x, ptr, retval, errret) \
         __get_user_asm(x, ptr, retval, "q", "", "=r", errret)
#define __get_user_asm_ex_u64(x, ptr) \
         __get_user_asm_ex(x, ptr, "q", "", "=r")
#endif

Hence, __get_user() on x86-32 with a 64-bit quantity results in
__get_user_bad() being called, which is an undefined function.
Only if you build with x86-64 support enabled (iow, CONFIG_X86_32 not
defined) then you get the 64-bit __get_user() support.

Given this, I fail to see how x86-32 can possibly work.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From juri.lelli at arm.com  Thu Feb  4 06:13:45 2016
From: juri.lelli at arm.com (Juri Lelli)
Date: Thu, 4 Feb 2016 14:13:45 +0000
Subject: [PATCH v3 2/6] drivers/cpufreq: implement
 init_cpu_capacity_default()
In-Reply-To: <CAKfTPtDVasamRtG2kLxP0HsohmVQTPrXRgx36e+jb3gozDoo6g@mail.gmail.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <1454500799-18451-3-git-send-email-juri.lelli@arm.com>
 <CAKfTPtDGk5BC25WqHdhDYDOBgUsuidAMhrXS=eDi6wJPZjfrwA@mail.gmail.com>
 <20160204093559.GA14099@e105550-lin.cambridge.arm.com>
 <CAKfTPtB4G3bP5N0hU6zWXJTddO34x3RnyGpp-4_otc8O=Wq2hw@mail.gmail.com>
 <20160204121620.GB29586@e106622-lin>
 <CAKfTPtDVasamRtG2kLxP0HsohmVQTPrXRgx36e+jb3gozDoo6g@mail.gmail.com>
Message-ID: <20160204141345.GD29586@e106622-lin>

On 04/02/16 13:35, Vincent Guittot wrote:
> On 4 February 2016 at 13:16, Juri Lelli <juri.lelli at arm.com> wrote:
> > Hi Vincent,
> >
> > On 04/02/16 13:03, Vincent Guittot wrote:
> >> On 4 February 2016 at 10:36, Morten Rasmussen <morten.rasmussen at arm.com> wrote:
> >> > On Wed, Feb 03, 2016 at 10:04:37PM +0100, Vincent Guittot wrote:
> >> >> On 3 February 2016 at 12:59, Juri Lelli <juri.lelli at arm.com> wrote:
> >>
> >> [snip]
> >>
> >> >> > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> >> >> > index 9e63fb1..c4025fd 100644
> >> >> > --- a/drivers/cpufreq/Makefile
> >> >> > +++ b/drivers/cpufreq/Makefile
> >> >> > @@ -1,5 +1,5 @@
> >> >> >  # CPUfreq core
> >> >> > -obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o
> >> >> > +obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o cpufreq_capacity.o
> >> >>
> >> >> Do you really want to have the calibration of capacity dependent of
> >> >> cpufreq ? It means that we can't use it without a cpufreq driver.
> >> >> IMHO, this creates a unnecessary dependency. I understand that you
> >> >> must ensure that core runs at max fequency if a driver is present but
> >> >> you should be able to calibrate the capacity if cpufreq is not
> >> >> available but you have different capacity because micro architecture
> >> >
> >> > We could remove the dependency on cpufreq, but it would make things more
> >> > complicated for systems which do have frequency scaling as we would have
> >> > to either:
> >> >
> >> > 1) Run the calibration again once cpufreq has been initialized.
> >>
> >> or wait and let time for a driver to initialize and trig the
> >> calibration. If calibration has not been done at the end of the boot,
> >> you can force a calibration. If the cpufeq driver is a module and is
> >> loaded far later for any good or bad reason, we will have to run the
> >> calibration once again but at least the capacity will reflect he
> >> current capacity of the CPUs.
> >> I'm mainly worried that the compilation of the calibration is
> >> dependent of CONFIG_CPU_FREQ not that cpufreq can trig the calibration
> >> sequence
> >>
> >
> > Yes, I guess we can make this work in some way. Out of curiosity,
> > though, are out there heterogenous platforms that don't use cpufreq?
> 
> At least, you can find several heterogeneous platforms without OPP
> table for CPUs in the kernel. That's probably a temporary situation
> but which can become a permanent one. It means that we can't calibrate
> the CPUs for these platforms.
> 

Sorry, can you make some examples so that I'm sure I understand what you
are referring to?

Anyway, don't these platform still make use of cpufreq (even if without
an OPP table) so that we can still control policy->max and min?

Thanks,

- Juri


From b.zolnierkie at samsung.com  Thu Feb  4 06:15:19 2016
From: b.zolnierkie at samsung.com (Bartlomiej Zolnierkiewicz)
Date: Thu, 04 Feb 2016 15:15:19 +0100
Subject: [RFT PATCH] arm: collie_defconfig: convert to use libata PATA
 drivers
In-Reply-To: <CALT56yO0Z3hs4CGAmT_Qtpc8482cUzK_GMROjQ=_4+rOJs0TBw@mail.gmail.com>
References: <1439571876-13758-1-git-send-email-b.zolnierkie@samsung.com>
 <1439571876-13758-6-git-send-email-b.zolnierkie@samsung.com>
 <CALT56yO0Z3hs4CGAmT_Qtpc8482cUzK_GMROjQ=_4+rOJs0TBw@mail.gmail.com>
Message-ID: <2391832.J7vu9NK7zC@amdc1976>


Hi,

On Friday, August 14, 2015 08:25:45 PM Dmitry Eremin-Solenikov wrote:
> 2015-08-14 20:04 GMT+03:00 Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>:
> > IDE subsystem has been deprecated since 2009 and the majority
> > (if not all) of Linux distributions have switched to use
> > libata for ATA support exclusively.  However there are still
> > some users (mostly old or/and embedded non-x86 systems) that
> > have not converted from using IDE subsystem to libata PATA
> > drivers.  This doesn't seem to be good thing in the long-term
> > for Linux as while there is less and less PATA systems left
> > in use:
> >
> > * testing efforts are divided between two subsystems
> >
> > * having duplicate drivers for same hardware confuses users
> >
> > This patch converts collie_defconfig to use libata PATA
> > drivers.
> >
> > Cc: Dmitry Eremin-Solenikov <dbaryshkov at gmail.com>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
> 
> Acked-by: Dmitry Eremin-Solenikov <dbaryshkov at gmail.com>

Thank you.

Arnd/Olof, could you please merge this patch?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics



From b.zolnierkie at samsung.com  Thu Feb  4 06:16:10 2016
From: b.zolnierkie at samsung.com (Bartlomiej Zolnierkiewicz)
Date: Thu, 04 Feb 2016 15:16:10 +0100
Subject: [RFT PATCH] arm: omap1_defconfig: convert to use libata PATA
 drivers
In-Reply-To: <20150817063454.GF4215@atomide.com>
References: <1439571876-13758-1-git-send-email-b.zolnierkie@samsung.com>
 <1439571876-13758-16-git-send-email-b.zolnierkie@samsung.com>
 <20150817063454.GF4215@atomide.com>
Message-ID: <6359194.rjne3vOG9H@amdc1976>


Hi,

On Sunday, August 16, 2015 11:34:55 PM Tony Lindgren wrote:
> * Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com> [150814 10:10]:
> > IDE subsystem has been deprecated since 2009 and the majority
> > (if not all) of Linux distributions have switched to use
> > libata for ATA support exclusively.  However there are still
> > some users (mostly old or/and embedded non-x86 systems) that
> > have not converted from using IDE subsystem to libata PATA
> > drivers.  This doesn't seem to be good thing in the long-term
> > for Linux as while there is less and less PATA systems left
> > in use:
> > 
> > * testing efforts are divided between two subsystems
> > 
> > * having duplicate drivers for same hardware confuses users
> > 
> > This patch converts omap1_defconfig to use libata PATA
> > drivers.
> > 
> > Cc: Tony Lindgren <tony at atomide.com>
> > Cc: linux-omap at vger.kernel.org
> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie at samsung.com>
> > ---
> > Build tested only.
> > If you have affected hardware please test.  Thank you.
> 
> All my omap1 devices are in a rack using NFSroot or MMC so
> I can't test this. Seems like a good idea to me thoug, and does
> not cause merge conflicts. So if you want to queue this via
> along with other PATA related patches, please feel free to
> add:
> 
> Acked-by: Tony Lindgren <tony at atomide.com>

Thank you.

Arnd/Olof, could you please merge this patch?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> >  arch/arm/configs/omap1_defconfig | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig
> > index 0c8a787..6ffc984 100644
> > --- a/arch/arm/configs/omap1_defconfig
> > +++ b/arch/arm/configs/omap1_defconfig
> > @@ -96,14 +96,14 @@ CONFIG_BLK_DEV_LOOP=y
> >  CONFIG_BLK_DEV_RAM=y
> >  CONFIG_BLK_DEV_RAM_COUNT=2
> >  CONFIG_BLK_DEV_RAM_SIZE=8192
> > -CONFIG_IDE=m
> > -CONFIG_BLK_DEV_IDECS=m
> >  CONFIG_SCSI=y
> >  # CONFIG_SCSI_PROC_FS is not set
> >  CONFIG_BLK_DEV_SD=y
> >  CONFIG_CHR_DEV_ST=y
> >  CONFIG_BLK_DEV_SR=y
> >  CONFIG_CHR_DEV_SG=y
> > +CONFIG_ATA=m
> > +CONFIG_PATA_PCMCIA=m
> >  CONFIG_NETDEVICES=y
> >  CONFIG_TUN=y
> >  CONFIG_PHYLIB=y



From k.debski at samsung.com  Thu Feb  4 06:23:02 2016
From: k.debski at samsung.com (Kamil Debski)
Date: Thu, 04 Feb 2016 15:23:02 +0100
Subject: [PATCH 3/4] [media] s5p-mfc: don't close instance after free
 OUTPUT buffers
In-Reply-To: <1454180017-29071-4-git-send-email-ayaka@soulik.info>
References: <1454180017-29071-1-git-send-email-ayaka@soulik.info>
 <1454180017-29071-4-git-send-email-ayaka@soulik.info>
Message-ID: <003501d15f57$8f1904b0$ad4b0e10$@samsung.com>

Hi,

> From: ayaka [mailto:ayaka at soulik.info]
> Sent: Saturday, January 30, 2016 7:54 PM
>
> Free buffers in OUTPUT is quite normal to detect the driver's buffer
capacity,
> it doesn't mean the application want to close that mfc instance.
> 
> Signed-off-by: ayaka <ayaka at soulik.info>
> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index aebe4fd..609b17b 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -474,7 +474,6 @@ static int reqbufs_output(struct s5p_mfc_dev *dev,
> struct s5p_mfc_ctx *ctx,
>  		ret = vb2_reqbufs(&ctx->vq_src, reqbufs);
>  		if (ret)
>  			goto out;
> -		s5p_mfc_close_mfc_inst(dev, ctx);
>  		ctx->src_bufs_cnt = 0;
>  		ctx->output_state = QUEUE_FREE;
>  	} else if (ctx->output_state == QUEUE_FREE) {

What exactly do you mean by "detecting buffer capacity"  ? Is it the max
number of buffer
that can be allocated?

Anyway, if the instance is not closed, then in a consecutive call to reqbufs
(with cound != 0)
the instance will be opened for a second time. So either the instance has to
be closed, or
it should be opened in another place.

Best wishes,
-- 
Kamil Debski
Samsung R&D Institute Poland



From Chris.Brandt at renesas.com  Thu Feb  4 06:25:57 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Thu, 4 Feb 2016 14:25:57 +0000
Subject: [PATCH] ARM: remove duplicate definitions of __vectors_start and
 __stubs_start
In-Reply-To: <1454574705-15109-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454574705-15109-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <HKXPR06MB0565A610565403E9E5E9546C8AD10@HKXPR06MB0565.apcprd06.prod.outlook.com>

On 4 Feb 2016, Ard Biesheuvel wrote:

> This is completely harmless by itself, since the wrong values are local
> symbols that cannot be referenced by other object files directly. However,
> since these symbols are also listed in the kallsyms symbol table in some
> cases (i.e., CONFIG_KALLSYMS_ALL=y and CONFIG_XIP_KERNEL=y), having these
> conflicting values can be confusing. So either remove them, or make them
> strictly local.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
>
> This is a separate fix for the duplicate symbols based on v4.5-rc2,
> so that it can be applied separately if desired. In that case, I will
> rebase my kallsyms series onto this patch.
>
>  arch/arm/kernel/entry-armv.S | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> index 3ce377f7251f..788e40c1254f 100644
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -1064,7 +1064,6 @@ ENDPROC(vector_\name)
>  	.endm
>  
>  	.section .stubs, "ax", %progbits
> -__stubs_start:
>  	@ This must be the first word
>  	.word	vector_swi
>  
> @@ -1206,10 +1205,10 @@ vector_addrexcptn:
>  	.equ	vector_fiq_offset, vector_fiq
>  
>  	.section .vectors, "ax", %progbits
> -__vectors_start:
> +.L__vectors_start:
>  	W(b)	vector_rst
>  	W(b)	vector_und
> -	W(ldr)	pc, __vectors_start + 0x1000
> +	W(ldr)	pc, .L__vectors_start + 0x1000
>  	W(b)	vector_pabt
>  	W(b)	vector_dabt
>  	W(b)	vector_addrexcptn


Tested with ARCH_R7S72100 with CONFIG_XIP_KERNEL=y and CONFIG_XIP_KERNEL=n

Duplicate symbols are gone, and boots fine (given the other patches from "[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM" for the CONFIG_XIP_KERNEL=y case) 


Acked-by: Chris Brandt <chris.brandt at renesas.com>





From horms+renesas at verge.net.au  Thu Feb  4 06:29:34 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:34 +0100
Subject: [GIT PULL] Renesas ARM Based SoC Cleanup for v4.6
Message-ID: <cover.1454595116.git.horms+renesas@verge.net.au>

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM based SoC cleanup for v4.6.

These are all minor cleanups from Geert.


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-cleanup-for-v4.6

for you to fetch changes up to 2c7bdcfd8912ce47d8360017265713c5a110b9ed:

  ARM: shmobile: r8a7779: Remove remainings of removed SCU boot setup code (2016-02-02 15:06:30 +0100)

----------------------------------------------------------------
Renesas ARM Based SoC Cleanup for v4.6

* Remove remnants of removed SCU boot setup code for r8a7779
* Correct s/MIPDR/MPIDR/ typo
* Add includes providing forward declarations
* Make rcar_gen2_dma_contiguous static

----------------------------------------------------------------
Geert Uytterhoeven (4):
      ARM: shmobile: rcar-gen2: Make rcar_gen2_dma_contiguous static
      ARM: shmobile: Add includes providing forward declarations
      ARM: shmobile: Typo s/MIPDR/MPIDR/
      ARM: shmobile: r8a7779: Remove remainings of removed SCU boot setup code

 arch/arm/mach-shmobile/cpufreq.c         | 2 ++
 arch/arm/mach-shmobile/headsmp-scu.S     | 2 +-
 arch/arm/mach-shmobile/setup-rcar-gen2.c | 7 ++++---
 arch/arm/mach-shmobile/smp-r8a7779.c     | 2 --
 arch/arm/mach-shmobile/suspend.c         | 2 ++
 arch/arm/mach-shmobile/timer.c           | 2 ++
 6 files changed, 11 insertions(+), 6 deletions(-)


From horms+renesas at verge.net.au  Thu Feb  4 06:29:32 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:32 +0100
Subject: [PATCH 1/4] ARM: shmobile: rcar-gen2: Make rcar_gen2_dma_contiguous
 static
In-Reply-To: <cover.1454595116.git.horms+renesas@verge.net.au>
References: <cover.1454595116.git.horms+renesas@verge.net.au>
Message-ID: <0c1690705417ac1b33f01125552349e3cfc9766d.1454595116.git.horms+renesas@verge.net.au>

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

make C=1:

    arch/arm/mach-shmobile/setup-rcar-gen2.c:186:12: warning: symbol 'rcar_gen2_dma_contiguous' was not declared. Should it be static?

Make it static, and move it inside the function to avoid a "defined but
not used" warning if CONFIG_DMA_CMA=n.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-rcar-gen2.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c
index 9eccde3c7b13..6d0ebdfb03a2 100644
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -182,8 +182,6 @@ static int __init rcar_gen2_scan_mem(unsigned long node, const char *uname,
 	return 0;
 }
 
-struct cma *rcar_gen2_dma_contiguous;
-
 void __init rcar_gen2_reserve(void)
 {
 	struct memory_reserve_config mrc;
@@ -194,8 +192,11 @@ void __init rcar_gen2_reserve(void)
 
 	of_scan_flat_dt(rcar_gen2_scan_mem, &mrc);
 #ifdef CONFIG_DMA_CMA
-	if (mrc.size && memblock_is_region_memory(mrc.base, mrc.size))
+	if (mrc.size && memblock_is_region_memory(mrc.base, mrc.size)) {
+		static struct cma *rcar_gen2_dma_contiguous;
+
 		dma_contiguous_reserve_area(mrc.size, mrc.base, 0,
 					    &rcar_gen2_dma_contiguous, true);
+	}
 #endif
 }
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:33 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:33 +0100
Subject: [PATCH 2/4] ARM: shmobile: Add includes providing forward declarations
In-Reply-To: <cover.1454595116.git.horms+renesas@verge.net.au>
References: <cover.1454595116.git.horms+renesas@verge.net.au>
Message-ID: <2e41e5fe88f99c03a77c4325870f160378b42268.1454595116.git.horms+renesas@verge.net.au>

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

make C=1:

    arch/arm/mach-shmobile/timer.c:38:13: warning: symbol 'shmobile_init_delay' was not declared. Should it be static?
    arch/arm/mach-shmobile/suspend.c:37:29: warning: symbol 'shmobile_suspend_ops' was not declared. Should it be static?
    arch/arm/mach-shmobile/suspend.c:44:12: warning: symbol 'shmobile_suspend_init' was not declared. Should it be static?
    arch/arm/mach-shmobile/cpufreq.c:13:12: warning: symbol 'shmobile_cpufreq_init' was not declared. Should it be static?

Include "common.h" to fix these.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/cpufreq.c | 2 ++
 arch/arm/mach-shmobile/suspend.c | 2 ++
 arch/arm/mach-shmobile/timer.c   | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/arch/arm/mach-shmobile/cpufreq.c b/arch/arm/mach-shmobile/cpufreq.c
index 57fbff024dcd..634d701c56a7 100644
--- a/arch/arm/mach-shmobile/cpufreq.c
+++ b/arch/arm/mach-shmobile/cpufreq.c
@@ -10,6 +10,8 @@
 
 #include <linux/platform_device.h>
 
+#include "common.h"
+
 int __init shmobile_cpufreq_init(void)
 {
 	platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
diff --git a/arch/arm/mach-shmobile/suspend.c b/arch/arm/mach-shmobile/suspend.c
index 5d92b5dd486b..74b30bade2c1 100644
--- a/arch/arm/mach-shmobile/suspend.c
+++ b/arch/arm/mach-shmobile/suspend.c
@@ -17,6 +17,8 @@
 #include <asm/io.h>
 #include <asm/system_misc.h>
 
+#include "common.h"
+
 static int shmobile_suspend_default_enter(suspend_state_t suspend_state)
 {
 	cpu_do_idle();
diff --git a/arch/arm/mach-shmobile/timer.c b/arch/arm/mach-shmobile/timer.c
index c17d4d3881ff..ad008e4b0c49 100644
--- a/arch/arm/mach-shmobile/timer.c
+++ b/arch/arm/mach-shmobile/timer.c
@@ -18,6 +18,8 @@
 #include <linux/delay.h>
 #include <linux/of_address.h>
 
+#include "common.h"
+
 static void __init shmobile_setup_delay_hz(unsigned int max_cpu_core_hz,
 					   unsigned int mult, unsigned int div)
 {
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:34 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:34 +0100
Subject: [PATCH 3/4] ARM: shmobile: Typo s/MIPDR/MPIDR/
In-Reply-To: <cover.1454595116.git.horms+renesas@verge.net.au>
References: <cover.1454595116.git.horms+renesas@verge.net.au>
Message-ID: <e24f317c859f2d904d1eb87cbb503c309e6dead7.1454595116.git.horms+renesas@verge.net.au>

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

The ARM Multiprocessor Affinity Register is called "MPIDR".

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/headsmp-scu.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/headsmp-scu.S b/arch/arm/mach-shmobile/headsmp-scu.S
index fa5248c52399..c0008a5aa4ca 100644
--- a/arch/arm/mach-shmobile/headsmp-scu.S
+++ b/arch/arm/mach-shmobile/headsmp-scu.S
@@ -27,7 +27,7 @@
  */
 ENTRY(shmobile_boot_scu)
 					@ r0 = SCU base address
-	mrc     p15, 0, r1, c0, c0, 5	@ read MIPDR
+	mrc     p15, 0, r1, c0, c0, 5	@ read MPIDR
 	and	r1, r1, #3		@ mask out cpu ID
 	lsl	r1, r1, #3		@ we will shift by cpu_id * 8 bits
 	ldr	r2, [r0, #8]		@ SCU Power Status Register
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:44 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:44 +0100
Subject: [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.6
Message-ID: <cover.1454595726.git.horms+renesas@verge.net.au>

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM64 based SoC DT updates for v4.6.


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-dt-for-v4.6

for you to fetch changes up to a3fc85e27b7e3c29b30909929bc64737a19fd251:

  arm64: dts: salvator-x: Enable SCIF_CLK frequency and pins (2016-02-03 10:04:33 +0100)

----------------------------------------------------------------
Renesas ARM64 Based SoC DT Updates for v4.6

* Use SCIF fallback compatibility strings
* Add Baud Rate Generator (BRG) support for (H)SCIF
* Enable SCIF_CLK frequency and pins
* Enable USB 3.0 host
* Add Add USB-DMAC device nodes
* Complete SYS-DMAC device nodes

----------------------------------------------------------------
Geert Uytterhoeven (5):
      arm64: dts: r8a7795: Complete SYS-DMAC nodes
      arm64: dts: r8a7795: Add SCIF fallback compatibility strings
      arm64: dts: r8a7795: Rename the serial port clock to fck
      arm64: dts: r8a7795: Add BRG support for (H)SCIF
      arm64: dts: salvator-x: Enable SCIF_CLK frequency and pins

Yoshihiro Shimoda (3):
      arm64: dts: r8a7795: Add USB3.0 host device nodes
      arm64: dts: salvator-x: enable usb3.0 host channel 0
      arm64: dts: r8a7795: Add USB-DMAC device nodes

 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  16 ++
 arch/arm64/boot/dts/renesas/r8a7795.dtsi           | 249 ++++++++++++++++++---
 2 files changed, 229 insertions(+), 36 deletions(-)


From horms+renesas at verge.net.au  Thu Feb  4 06:29:38 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:38 +0100
Subject: [PATCH 1/8] arm64: dts: r8a7795: Complete SYS-DMAC nodes
In-Reply-To: <cover.1454595726.git.horms+renesas@verge.net.au>
References: <cover.1454595726.git.horms+renesas@verge.net.au>
Message-ID: <e2102cea9bced786a07ae5c244eff6e5e03376e3.1454595726.git.horms+renesas@verge.net.au>

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

Complete the dma-controller nodes for SYS-DMAC 0 to 2.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 93 ++++++++++++++++++++++++++++++--
 1 file changed, 90 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index bb353cde1253..221a8f5d24af 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -333,15 +333,102 @@
 		};
 
 		dmac0: dma-controller at e6700000 {
-			/* Empty node for now */
+			compatible = "renesas,dmac-r8a7795",
+				     "renesas,rcar-dmac";
+			reg = <0 0xe6700000 0 0x10000>;
+			interrupts = <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "error",
+					"ch0", "ch1", "ch2", "ch3",
+					"ch4", "ch5", "ch6", "ch7",
+					"ch8", "ch9", "ch10", "ch11",
+					"ch12", "ch13", "ch14", "ch15";
+			clocks = <&cpg CPG_MOD 219>;
+			clock-names = "fck";
+			power-domains = <&cpg>;
+			#dma-cells = <1>;
+			dma-channels = <16>;
 		};
 
 		dmac1: dma-controller at e7300000 {
-			/* Empty node for now */
+			compatible = "renesas,dmac-r8a7795",
+				     "renesas,rcar-dmac";
+			reg = <0 0xe7300000 0 0x10000>;
+			interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 319 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "error",
+					"ch0", "ch1", "ch2", "ch3",
+					"ch4", "ch5", "ch6", "ch7",
+					"ch8", "ch9", "ch10", "ch11",
+					"ch12", "ch13", "ch14", "ch15";
+			clocks = <&cpg CPG_MOD 218>;
+			clock-names = "fck";
+			power-domains = <&cpg>;
+			#dma-cells = <1>;
+			dma-channels = <16>;
 		};
 
 		dmac2: dma-controller at e7310000 {
-			/* Empty node for now */
+			compatible = "renesas,dmac-r8a7795",
+				     "renesas,rcar-dmac";
+			reg = <0 0xe7310000 0 0x10000>;
+			interrupts = <GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 419 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 420 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 421 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 423 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 427 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 428 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 429 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 430 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 431 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "error",
+					"ch0", "ch1", "ch2", "ch3",
+					"ch4", "ch5", "ch6", "ch7",
+					"ch8", "ch9", "ch10", "ch11",
+					"ch12", "ch13", "ch14", "ch15";
+			clocks = <&cpg CPG_MOD 217>;
+			clock-names = "fck";
+			power-domains = <&cpg>;
+			#dma-cells = <1>;
+			dma-channels = <16>;
 		};
 
 		avb: ethernet at e6800000 {
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:39 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:39 +0100
Subject: [PATCH 2/8] arm64: dts: r8a7795: Add USB3.0 host device nodes
In-Reply-To: <cover.1454595726.git.horms+renesas@verge.net.au>
References: <cover.1454595726.git.horms+renesas@verge.net.au>
Message-ID: <171f2ef82284f61b763a620747806ec2724d1a84.1454595726.git.horms+renesas@verge.net.au>

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 221a8f5d24af..119549e6502d 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -862,5 +862,23 @@
 			clocks = <&cpg CPG_MOD 815>;
 			status = "disabled";
 		};
+
+		xhci0: usb at ee000000 {
+			compatible = "renesas,xhci-r8a7795";
+			reg = <0 0xee000000 0 0xc00>;
+			interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 328>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		xhci1: usb at ee0400000 {
+			compatible = "renesas,xhci-r8a7795";
+			reg = <0 0xee040000 0 0xc00>;
+			interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 327>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
 	};
 };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:35 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:35 +0100
Subject: [PATCH 4/4] ARM: shmobile: r8a7779: Remove remainings of removed SCU
 boot setup code
In-Reply-To: <cover.1454595116.git.horms+renesas@verge.net.au>
References: <cover.1454595116.git.horms+renesas@verge.net.au>
Message-ID: <cdef6b0b6ff40da9a55c8175206c45635428d9fe.1454595116.git.horms+renesas@verge.net.au>

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

Commit 0ca2894b5a900709 ("ARM: shmobile: Use shared SCU SMP boot code on
r8a7779") obsoleted the r8a7779-specific SCU boot code, but forgot to
remove the setup of shmobile_boot_fn and shmobile_boot_arg, which is
overwritten by shmobile_smp_scu_prepare_cpus().

Note that shmobile_scu_base wasn't initialized at that point yet anyway.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/smp-r8a7779.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/smp-r8a7779.c b/arch/arm/mach-shmobile/smp-r8a7779.c
index b854fe2095ad..0b024a9dbd43 100644
--- a/arch/arm/mach-shmobile/smp-r8a7779.c
+++ b/arch/arm/mach-shmobile/smp-r8a7779.c
@@ -92,8 +92,6 @@ static void __init r8a7779_smp_prepare_cpus(unsigned int max_cpus)
 {
 	/* Map the reset vector (in headsmp-scu.S, headsmp.S) */
 	__raw_writel(__pa(shmobile_boot_vector), AVECR);
-	shmobile_boot_fn = virt_to_phys(shmobile_boot_scu);
-	shmobile_boot_arg = (unsigned long)shmobile_scu_base;
 
 	/* setup r8a7779 specific SCU bits */
 	shmobile_scu_base = IOMEM(R8A7779_SCU_BASE);
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:40 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:40 +0100
Subject: [PATCH 3/8] arm64: dts: salvator-x: enable usb3.0 host channel 0
In-Reply-To: <cover.1454595726.git.horms+renesas@verge.net.au>
References: <cover.1454595726.git.horms+renesas@verge.net.au>
Message-ID: <856ea9eddbf46dc401f426da4eb3339a6baaed7b.1454595726.git.horms+renesas@verge.net.au>

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 265d12ff6022..9af1e3fdc468 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -249,3 +249,7 @@
 		interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
 	};
 };
+
+&xhci0 {
+	status = "okay";
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:41 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:41 +0100
Subject: [PATCH 4/8] arm64: dts: r8a7795: Add USB-DMAC device nodes
In-Reply-To: <cover.1454595726.git.horms+renesas@verge.net.au>
References: <cover.1454595726.git.horms+renesas@verge.net.au>
Message-ID: <652a4306be7684d4009e83f5028b3147c6f1c735.1454595726.git.horms+renesas@verge.net.au>

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 119549e6502d..95967b72db35 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -880,5 +880,31 @@
 			power-domains = <&cpg>;
 			status = "disabled";
 		};
+
+		usb_dmac0: dma-controller at e65a0000 {
+			compatible = "renesas,r8a7795-usb-dmac",
+				     "renesas,usb-dmac";
+			reg = <0 0xe65a0000 0 0x100>;
+			interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "ch0", "ch1";
+			clocks = <&cpg CPG_MOD 330>;
+			power-domains = <&cpg>;
+			#dma-cells = <1>;
+			dma-channels = <2>;
+		};
+
+		usb_dmac1: dma-controller at e65b0000 {
+			compatible = "renesas,r8a7795-usb-dmac",
+				     "renesas,usb-dmac";
+			reg = <0 0xe65b0000 0 0x100>;
+			interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "ch0", "ch1";
+			clocks = <&cpg CPG_MOD 331>;
+			power-domains = <&cpg>;
+			#dma-cells = <1>;
+			dma-channels = <2>;
+		};
 	};
 };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:43 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:43 +0100
Subject: [PATCH 6/8] arm64: dts: r8a7795: Rename the serial port clock to fck
In-Reply-To: <cover.1454595726.git.horms+renesas@verge.net.au>
References: <cover.1454595726.git.horms+renesas@verge.net.au>
Message-ID: <69e359ca8811582cf7433f3fa894a7d6cbba4905.1454595726.git.horms+renesas@verge.net.au>

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

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 013df449fc30..ddeec7d7b6eb 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -480,7 +480,7 @@
 			reg = <0 0xe6540000 0 96>;
 			interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 520>;
-			clock-names = "sci_ick";
+			clock-names = "fck";
 			dmas = <&dmac1 0x31>, <&dmac1 0x30>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -494,7 +494,7 @@
 			reg = <0 0xe6550000 0 96>;
 			interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 519>;
-			clock-names = "sci_ick";
+			clock-names = "fck";
 			dmas = <&dmac1 0x33>, <&dmac1 0x32>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -508,7 +508,7 @@
 			reg = <0 0xe6560000 0 96>;
 			interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 518>;
-			clock-names = "sci_ick";
+			clock-names = "fck";
 			dmas = <&dmac1 0x35>, <&dmac1 0x34>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -522,7 +522,7 @@
 			reg = <0 0xe66a0000 0 96>;
 			interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 517>;
-			clock-names = "sci_ick";
+			clock-names = "fck";
 			dmas = <&dmac0 0x37>, <&dmac0 0x36>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -536,7 +536,7 @@
 			reg = <0 0xe66b0000 0 96>;
 			interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 516>;
-			clock-names = "sci_ick";
+			clock-names = "fck";
 			dmas = <&dmac0 0x39>, <&dmac0 0x38>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -549,7 +549,7 @@
 			reg = <0 0xe6e60000 0 64>;
 			interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 207>;
-			clock-names = "sci_ick";
+			clock-names = "fck";
 			dmas = <&dmac1 0x51>, <&dmac1 0x50>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -562,7 +562,7 @@
 			reg = <0 0xe6e68000 0 64>;
 			interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 206>;
-			clock-names = "sci_ick";
+			clock-names = "fck";
 			dmas = <&dmac1 0x53>, <&dmac1 0x52>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -575,7 +575,7 @@
 			reg = <0 0xe6e88000 0 64>;
 			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 310>;
-			clock-names = "sci_ick";
+			clock-names = "fck";
 			dmas = <&dmac1 0x13>, <&dmac1 0x12>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -588,7 +588,7 @@
 			reg = <0 0xe6c50000 0 64>;
 			interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 204>;
-			clock-names = "sci_ick";
+			clock-names = "fck";
 			dmas = <&dmac0 0x57>, <&dmac0 0x56>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -601,7 +601,7 @@
 			reg = <0 0xe6c40000 0 64>;
 			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 203>;
-			clock-names = "sci_ick";
+			clock-names = "fck";
 			dmas = <&dmac0 0x59>, <&dmac0 0x58>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -614,7 +614,7 @@
 			reg = <0 0xe6f30000 0 64>;
 			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 202>;
-			clock-names = "sci_ick";
+			clock-names = "fck";
 			dmas = <&dmac1 0x5b>, <&dmac1 0x5a>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:28:59 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:28:59 +0100
Subject: [PATCH 05/70] ARM: dts: alt: Add QSPI device to DT
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <6b78e6ae688b09aa75376537bcfa990c9d4eff07.1454595846.git.horms+renesas@verge.net.au>

Enable the QSPI controller in the alt device tree.

Based similar work for the silk board by by Vladimir Barinov and
Sergei Shtylyov.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7794-alt.dts | 46 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
index 2394e4883786..773f304d1142 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -138,6 +138,13 @@
 	status = "okay";
 };
 
+&pfc {
+	qspi_pins: spi0 {
+		renesas,groups = "qspi_ctrl", "qspi_data4";
+		renesas,function = "qspi";
+	};
+};
+
 &ether {
 	pinctrl-0 = <&ether_pins &phy1_pins>;
 	pinctrl-names = "default";
@@ -197,3 +204,42 @@
 
 	status = "okay";
 };
+
+&qspi {
+	pinctrl-0 = <&qspi_pins>;
+	pinctrl-names = "default";
+
+	status = "okay";
+
+	flash at 0 {
+		compatible = "spansion,s25fl512s", "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <30000000>;
+		spi-tx-bus-width = <4>;
+		spi-rx-bus-width = <4>;
+		spi-cpol;
+		spi-cpha;
+		m25p,fast-read;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition at 0 {
+				label = "loader";
+				reg = <0x00000000 0x00040000>;
+				read-only;
+			};
+			partition at 40000 {
+				label = "system";
+				reg = <0x00040000 0x00040000>;
+				read-only;
+			};
+			partition at 80000 {
+				label = "user";
+				reg = <0x00080000 0x03f80000>;
+			};
+		};
+	};
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:02 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:02 +0100
Subject: [PATCH 08/70] ARM: dts: r8a7794: use fallback usbhs compatibility
 string
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <1472ffa81a9089af6250e299068f9a877369333f.1454595846.git.horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7794 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7794.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 6c78f1fae90f..f8cd3a0beebf 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -724,7 +724,7 @@
 	};
 
 	hsusb: usb at e6590000 {
-		compatible = "renesas,usbhs-r8a7794";
+		compatible = "renesas,usbhs-r8a7794", "renesas,rcar-gen2-usbhs";
 		reg = <0 0xe6590000 0 0x100>;
 		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSUSB>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:01 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:01 +0100
Subject: [PATCH 07/70] ARM: dts: r8a7791: use fallback usbhs compatibility
 string
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <8cf1d454b24961223fc3e8d26808d4f72b484a1b.1454595846.git.horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7791 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7791.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 2a369ddcb6fd..829224d2a3ed 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -822,7 +822,7 @@
 	};
 
 	hsusb: usb at e6590000 {
-		compatible = "renesas,usbhs-r8a7791";
+		compatible = "renesas,usbhs-r8a7791", "renesas,rcar-gen2-usbhs";
 		reg = <0 0xe6590000 0 0x100>;
 		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSUSB>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:03 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:03 +0100
Subject: [PATCH 09/70] ARM: dts: r8a7793: move dmac nodes
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <cefe5a56d3ffcdad0c63dda37f90845f42518e0a.1454595846.git.horms+renesas@verge.net.au>

Move dmac nodes in the r8a7793 device tree to match their location
in the r8a7791 device tree to aid comparison between the device
trees of these similar SoCs.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 124 ++++++++++++++++++++---------------------
 1 file changed, 62 insertions(+), 62 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index f9d92de4f65b..0ce7cc420c9d 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -239,6 +239,68 @@
 		power-domains = <&cpg_clocks>;
 	};
 
+	dmac0: dma-controller at e6700000 {
+		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
+		reg = <0 0xe6700000 0 0x20000>;
+		interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH
+			      0 200 IRQ_TYPE_LEVEL_HIGH
+			      0 201 IRQ_TYPE_LEVEL_HIGH
+			      0 202 IRQ_TYPE_LEVEL_HIGH
+			      0 203 IRQ_TYPE_LEVEL_HIGH
+			      0 204 IRQ_TYPE_LEVEL_HIGH
+			      0 205 IRQ_TYPE_LEVEL_HIGH
+			      0 206 IRQ_TYPE_LEVEL_HIGH
+			      0 207 IRQ_TYPE_LEVEL_HIGH
+			      0 208 IRQ_TYPE_LEVEL_HIGH
+			      0 209 IRQ_TYPE_LEVEL_HIGH
+			      0 210 IRQ_TYPE_LEVEL_HIGH
+			      0 211 IRQ_TYPE_LEVEL_HIGH
+			      0 212 IRQ_TYPE_LEVEL_HIGH
+			      0 213 IRQ_TYPE_LEVEL_HIGH
+			      0 214 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "error",
+				"ch0", "ch1", "ch2", "ch3",
+				"ch4", "ch5", "ch6", "ch7",
+				"ch8", "ch9", "ch10", "ch11",
+				"ch12", "ch13", "ch14";
+		clocks = <&mstp2_clks R8A7793_CLK_SYS_DMAC0>;
+		clock-names = "fck";
+		power-domains = <&cpg_clocks>;
+		#dma-cells = <1>;
+		dma-channels = <15>;
+	};
+
+	dmac1: dma-controller at e6720000 {
+		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
+		reg = <0 0xe6720000 0 0x20000>;
+		interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
+			      0 216 IRQ_TYPE_LEVEL_HIGH
+			      0 217 IRQ_TYPE_LEVEL_HIGH
+			      0 218 IRQ_TYPE_LEVEL_HIGH
+			      0 219 IRQ_TYPE_LEVEL_HIGH
+			      0 308 IRQ_TYPE_LEVEL_HIGH
+			      0 309 IRQ_TYPE_LEVEL_HIGH
+			      0 310 IRQ_TYPE_LEVEL_HIGH
+			      0 311 IRQ_TYPE_LEVEL_HIGH
+			      0 312 IRQ_TYPE_LEVEL_HIGH
+			      0 313 IRQ_TYPE_LEVEL_HIGH
+			      0 314 IRQ_TYPE_LEVEL_HIGH
+			      0 315 IRQ_TYPE_LEVEL_HIGH
+			      0 316 IRQ_TYPE_LEVEL_HIGH
+			      0 317 IRQ_TYPE_LEVEL_HIGH
+			      0 318 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "error",
+				"ch0", "ch1", "ch2", "ch3",
+				"ch4", "ch5", "ch6", "ch7",
+				"ch8", "ch9", "ch10", "ch11",
+				"ch12", "ch13", "ch14";
+		clocks = <&mstp2_clks R8A7793_CLK_SYS_DMAC1>;
+		clock-names = "fck";
+		power-domains = <&cpg_clocks>;
+		#dma-cells = <1>;
+		dma-channels = <15>;
+	};
+
 	/* The memory map in the User's Manual maps the cores to bus numbers */
 	i2c0: i2c at e6508000 {
 		#address-cells = <1>;
@@ -358,68 +420,6 @@
 		reg = <0 0xe6060000 0 0x250>;
 	};
 
-	dmac0: dma-controller at e6700000 {
-		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
-		reg = <0 0xe6700000 0 0x20000>;
-		interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH
-			      0 200 IRQ_TYPE_LEVEL_HIGH
-			      0 201 IRQ_TYPE_LEVEL_HIGH
-			      0 202 IRQ_TYPE_LEVEL_HIGH
-			      0 203 IRQ_TYPE_LEVEL_HIGH
-			      0 204 IRQ_TYPE_LEVEL_HIGH
-			      0 205 IRQ_TYPE_LEVEL_HIGH
-			      0 206 IRQ_TYPE_LEVEL_HIGH
-			      0 207 IRQ_TYPE_LEVEL_HIGH
-			      0 208 IRQ_TYPE_LEVEL_HIGH
-			      0 209 IRQ_TYPE_LEVEL_HIGH
-			      0 210 IRQ_TYPE_LEVEL_HIGH
-			      0 211 IRQ_TYPE_LEVEL_HIGH
-			      0 212 IRQ_TYPE_LEVEL_HIGH
-			      0 213 IRQ_TYPE_LEVEL_HIGH
-			      0 214 IRQ_TYPE_LEVEL_HIGH>;
-		interrupt-names = "error",
-				"ch0", "ch1", "ch2", "ch3",
-				"ch4", "ch5", "ch6", "ch7",
-				"ch8", "ch9", "ch10", "ch11",
-				"ch12", "ch13", "ch14";
-		clocks = <&mstp2_clks R8A7793_CLK_SYS_DMAC0>;
-		clock-names = "fck";
-		power-domains = <&cpg_clocks>;
-		#dma-cells = <1>;
-		dma-channels = <15>;
-	};
-
-	dmac1: dma-controller at e6720000 {
-		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
-		reg = <0 0xe6720000 0 0x20000>;
-		interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
-			      0 216 IRQ_TYPE_LEVEL_HIGH
-			      0 217 IRQ_TYPE_LEVEL_HIGH
-			      0 218 IRQ_TYPE_LEVEL_HIGH
-			      0 219 IRQ_TYPE_LEVEL_HIGH
-			      0 308 IRQ_TYPE_LEVEL_HIGH
-			      0 309 IRQ_TYPE_LEVEL_HIGH
-			      0 310 IRQ_TYPE_LEVEL_HIGH
-			      0 311 IRQ_TYPE_LEVEL_HIGH
-			      0 312 IRQ_TYPE_LEVEL_HIGH
-			      0 313 IRQ_TYPE_LEVEL_HIGH
-			      0 314 IRQ_TYPE_LEVEL_HIGH
-			      0 315 IRQ_TYPE_LEVEL_HIGH
-			      0 316 IRQ_TYPE_LEVEL_HIGH
-			      0 317 IRQ_TYPE_LEVEL_HIGH
-			      0 318 IRQ_TYPE_LEVEL_HIGH>;
-		interrupt-names = "error",
-				"ch0", "ch1", "ch2", "ch3",
-				"ch4", "ch5", "ch6", "ch7",
-				"ch8", "ch9", "ch10", "ch11",
-				"ch12", "ch13", "ch14";
-		clocks = <&mstp2_clks R8A7793_CLK_SYS_DMAC1>;
-		clock-names = "fck";
-		power-domains = <&cpg_clocks>;
-		#dma-cells = <1>;
-		dma-channels = <15>;
-	};
-
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:04 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:04 +0100
Subject: [PATCH 10/70] ARM: dts: gose: add i2c2 bus to device tree
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <f6890af3ad2b6440d287c8ee97b3f38e18b0674e.1454595846.git.horms+renesas@verge.net.au>

Activate i2c2 bus in r8a7793/gose device tree.

Based on similar work for the r8a7791/koelsch by Wolfram Sang.

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Acked-by: Wolfram Sang <wsa+renesas at sang-engineering.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 90b587c3c736..987ed03b1e02 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -136,6 +136,11 @@
 };
 
 &pfc {
+	i2c2_pins: i2c2 {
+		renesas,groups = "i2c2";
+		renesas,function = "i2c2";
+	};
+
 	scif0_pins: serial0 {
 		renesas,groups = "scif0_data_d";
 		renesas,function = "scif0";
@@ -234,3 +239,17 @@
 		};
 	};
 };
+
+&i2c2 {
+	pinctrl-0 = <&i2c2_pins>;
+	pinctrl-names = "default";
+
+	status = "okay";
+	clock-frequency = <100000>;
+
+	eeprom at 50 {
+		compatible = "renesas,r1ex24002", "atmel,24c02";
+		reg = <0x50>;
+		pagesize = <16>;
+	};
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:07 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:07 +0100
Subject: [PATCH 13/70] ARM: dts: silk: add DU DT support
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <84e734f497cd48f60c16c400d14b8da08cd281dc.1454595846.git.horms+renesas@verge.net.au>

From: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

Define  the SILK board dependent part of the DU device node.
Add the device nodes for the Analog Devices ADV7511W HDMI transmitter
(connected to DU0) and ADV7123  video DAC (connected to DU1). Add the
necessary subnodes to interconnect DU, HDMI/VDAC devices, and HDMI/VGA
connectors.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794-silk.dts | 109 +++++++++++++++++++++++++++++++++++++
 1 file changed, 109 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
index 5153e3af25d9..98b8bcca84da 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -64,6 +64,61 @@
 		states = <3300000 1
 			  1800000 0>;
 	};
+
+	vga-encoder {
+		compatible = "adi,adv7123";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				adv7123_in: endpoint {
+					remote-endpoint = <&du_out_rgb1>;
+				};
+			};
+			port at 1 {
+				reg = <1>;
+				adv7123_out: endpoint {
+					remote-endpoint = <&vga_in>;
+				};
+			};
+		};
+	};
+
+	hdmi-out {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_con: endpoint {
+				remote-endpoint = <&adv7511_out>;
+			};
+		};
+	};
+
+	vga {
+		compatible = "vga-connector";
+
+		port {
+			vga_in: endpoint {
+				remote-endpoint = <&adv7123_out>;
+			};
+		};
+	};
+
+	x2_clk: x2-clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <148500000>;
+	};
+
+	x3_clk: x3-clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <74250000>;
+	};
 };
 
 &extal_clk {
@@ -164,6 +219,38 @@
 			};
 		};
 	};
+
+	hdmi at 39 {
+		compatible = "adi,adv7511w";
+		reg = <0x39>;
+		interrupt-parent = <&gpio5>;
+		interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
+
+		adi,input-depth = <8>;
+		adi,input-colorspace = "rgb";
+		adi,input-clock = "1x";
+		adi,input-style = <1>;
+		adi,input-justification = "evenly";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				adv7511_in: endpoint {
+					remote-endpoint = <&du_out_rgb0>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+				adv7511_out: endpoint {
+					remote-endpoint = <&hdmi_con>;
+				};
+			};
+		};
+	};
 };
 
 &mmcif0 {
@@ -258,3 +345,25 @@
 &usbphy {
 	status = "okay";
 };
+
+&du {
+	status = "okay";
+
+	clocks = <&mstp7_clks R8A7794_CLK_DU0>,
+		 <&mstp7_clks R8A7794_CLK_DU0>,
+		 <&x2_clk>, <&x3_clk>;
+	clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";
+
+	ports {
+		port at 0 {
+			endpoint {
+				remote-endpoint = <&adv7511_in>;
+			};
+		};
+		port at 1 {
+			endpoint {
+				remote-endpoint = <&adv7123_in>;
+			};
+		};
+	};
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:30:02 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:30:02 +0100
Subject: [GIT PULL] Renesas ARM Based SoC DT Updates for v4.6
Message-ID: <cover.1454595846.git.horms+renesas@verge.net.au>

Hi Olof, Hi Kevin, Hi Arnd,

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


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

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

for you to fetch changes up to d7a11140d0a659e5c1f83627792f95b6713030a2:

  ARM: dts: silk: Enable SCIF_CLK frequency and pins (2016-02-02 14:02:28 +0100)

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

* Use SCIF and USBHS fallback compatibility strings
* Add Baud Rate Generator (BRG) support for (H)SCIF
* Enable SCIF_CLK frequency and pins
* Use GIC_* defines
* Migrate to generic l2c OF initialization on r8a7740
* Enable audio on r8a7793/gose
* Enable HDMI vidio out on r8a7793
* Enable i2c on r8a7793/gose
* Enable QSPI on alt
* Enable GPIO keys and leds on gise
* Enable audio on porter
* Enable DU on porter

----------------------------------------------------------------
Geert Uytterhoeven (22):
      ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization
      ARM: shmobile: r8a7740: Remove mapping of L2 cache controller registers
      ARM: dts: r8a7778: Add SCIF fallback compatibility strings
      ARM: dts: r8a7779: Add SCIF fallback compatibility strings
      ARM: dts: r8a7790: Add SCIF fallback compatibility strings
      ARM: dts: r8a7791: Add SCIF fallback compatibility strings
      ARM: dts: r8a7793: Add SCIF fallback compatibility strings
      ARM: dts: r8a7794: Add SCIF fallback compatibility strings
      ARM: dts: r8a7778: Add BRG support for SCIF
      ARM: dts: r8a7779: Add BRG support for SCIF
      ARM: dts: r8a7790: Add BRG support for (H)SCIF
      ARM: dts: r8a7791: Add BRG support for (H)SCIF
      ARM: dts: r8a7793: Add BRG support for SCIF
      ARM: dts: r8a7794: Add BRG support for (H)SCIF
      ARM: dts: alt: Enable SCIF_CLK frequency and pins
      ARM: dts: bockw: Enable SCIF_CLK frequency and pins
      ARM: dts: gose: Enable SCIF_CLK frequency and pins
      ARM: dts: koelsch: Enable SCIF_CLK frequency and pins
      ARM: dts: lager: Enable SCIF_CLK frequency and pins
      ARM: dts: marzen: Enable SCIF_CLK frequency and pins
      ARM: dts: porter: Enable SCIF_CLK frequency and pins
      ARM: dts: silk: Enable SCIF_CLK frequency and pins

Laurent Pinchart (11):
      ARM: dts: r8a7793: Add I2C master nodes to DT
      ARM: dts: sh73a0: Rename the serial port clock to fck
      ARM: dts: r7s72100: Rename the serial port clock to fck
      ARM: dts: r8a73a4: Rename the serial port clock to fck
      ARM: dts: r8a7740: Rename the serial port clock to fck
      ARM: dts: r8a7778: Rename the serial port clock to fck
      ARM: dts: r8a7779: Rename the serial port clock to fck
      ARM: dts: r8a7790: Rename the serial port clock to fck
      ARM: dts: r8a7791: Rename the serial port clock to fck
      ARM: dts: r8a7793: Rename the serial port clock to fck
      ARM: dts: r8a7794: Rename the serial port clock to fck

Magnus Damm (1):
      ARM: dts: r8a7793: gose: Add HDMI video out support

Sergei Shtylyov (3):
      ARM: dts: porter: add DU DT support
      ARM: dts: silk: add DU DT support
      ARM: dts: porter: add sound support

Simon Horman (33):
      ARM: dts: gose: Add GPIO keys to DT
      ARM: dts: gose: Add GPIO leds to DT
      ARM: dts: alt: Add QSPI device to DT
      ARM: dts: r8a7790: use fallback usbhs compatibility string
      ARM: dts: r8a7791: use fallback usbhs compatibility string
      ARM: dts: r8a7794: use fallback usbhs compatibility string
      ARM: dts: r8a7793: move dmac nodes
      ARM: dts: gose: add i2c2 bus to device tree
      ARM: dts: r8a7790: use GIC_* defines
      ARM: dts: r8a7791: use GIC_* defines
      ARM: dts: r8a7793: use GIC_* defines
      ARM: dts: r8a7794: use GIC_* defines
      ARM: dts: r8a7778: use GIC_* defines
      ARM: dts: r8a7779: use GIC_* defines
      ARM: dts: r8a73a4: use GIC_* defines
      ARM: dts: r8a7740: use GIC_* defines
      ARM: dts: r8a7793: add MSTP10 clocks to device tree
      ARM: dts: r8a7793: add audio clock to device tree
      ARM: dts: r8a7793: add m2 clock to device tree
      ARM: dts: r8a7793: add R-Car sound support to device tree
      ARM: dts: r8a7793: add DVC support to device tree
      ARM: dts: r8a7793: add audio DMAC clocks to device tree
      ARM: dts: r8a7793: add audio DMAC to device tree
      ARM: dts: r8a7793: enable Audio DMAC peri peri via sound driver
      ARM: dts: gose: Enable sound PIO support in device tree
      ARM: dts: gose: enable sound DMA support in device tree
      ARM: dts: gose: enable sound DMA support via BUSIF in device tree
      ARM: dts: gose: enable sound DMA support via SRC in device tree
      ARM: dts: gose: enable sound DMA support via DVC in device tree
      ARM: dts: r8a7793: enable audio DMAC in device tree
      ARM: dts: r7s72100: use GIC_* defines
      ARM: dts: sh73a0: use GIC_* defines
      ARM: dts: emev2: use GIC_* defines

 arch/arm/boot/dts/emev2.dtsi              |  39 +-
 arch/arm/boot/dts/r7s72100.dtsi           | 177 +++----
 arch/arm/boot/dts/r8a73a4.dtsi            | 224 ++++-----
 arch/arm/boot/dts/r8a7740.dtsi            | 161 +++----
 arch/arm/boot/dts/r8a7778-bockw.dts       |  13 +
 arch/arm/boot/dts/r8a7778.dtsi            | 144 +++---
 arch/arm/boot/dts/r8a7779-marzen.dts      |  13 +
 arch/arm/boot/dts/r8a7779.dtsi            | 135 +++---
 arch/arm/boot/dts/r8a7790-lager.dts       |  13 +
 arch/arm/boot/dts/r8a7790.dtsi            | 441 +++++++++--------
 arch/arm/boot/dts/r8a7791-koelsch.dts     |  13 +
 arch/arm/boot/dts/r8a7791-porter.dts      | 165 +++++++
 arch/arm/boot/dts/r8a7791.dtsi            | 514 ++++++++++----------
 arch/arm/boot/dts/r8a7793-gose.dts        | 304 ++++++++++++
 arch/arm/boot/dts/r8a7793.dtsi            | 758 ++++++++++++++++++++++++------
 arch/arm/boot/dts/r8a7794-alt.dts         |  59 +++
 arch/arm/boot/dts/r8a7794-silk.dts        | 122 +++++
 arch/arm/boot/dts/r8a7794.dtsi            | 362 +++++++-------
 arch/arm/boot/dts/sh73a0.dtsi             | 186 ++++----
 arch/arm/mach-shmobile/setup-r8a7740.c    |  18 +-
 include/dt-bindings/clock/r8a7793-clock.h |   2 +
 21 files changed, 2571 insertions(+), 1292 deletions(-)


From horms+renesas at verge.net.au  Thu Feb  4 06:29:44 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:44 +0100
Subject: [PATCH 7/8] arm64: dts: r8a7795: Add BRG support for (H)SCIF
In-Reply-To: <cover.1454595726.git.horms+renesas@verge.net.au>
References: <cover.1454595726.git.horms+renesas@verge.net.au>
Message-ID: <3da41e4cf65a322937db48ce0d55c6f6a68032b0.1454595726.git.horms+renesas@verge.net.au>

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

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depend on
the actual board.

Add the two optional clock sources (S3D1 and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF and HSCIF device nodes.

This increases the range and accuracy of supported baud rates on
(H)SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 74 ++++++++++++++++++++++----------
 1 file changed, 52 insertions(+), 22 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index ddeec7d7b6eb..9634e3a4858e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -99,6 +99,14 @@
 		clock-frequency = <0>;
 	};
 
+	/* External SCIF clock - to be overridden by boards that provide it */
+	scif_clk: scif {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <0>;
+		status = "disabled";
+	};
+
 	soc {
 		compatible = "simple-bus";
 		interrupt-parent = <&gic>;
@@ -479,8 +487,10 @@
 				     "renesas,hscif";
 			reg = <0 0xe6540000 0 96>;
 			interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 520>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 520>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "brg_int", "scif_clk";
 			dmas = <&dmac1 0x31>, <&dmac1 0x30>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -493,8 +503,10 @@
 				     "renesas,hscif";
 			reg = <0 0xe6550000 0 96>;
 			interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 519>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 519>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "brg_int", "scif_clk";
 			dmas = <&dmac1 0x33>, <&dmac1 0x32>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -507,8 +519,10 @@
 				     "renesas,hscif";
 			reg = <0 0xe6560000 0 96>;
 			interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 518>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 518>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "brg_int", "scif_clk";
 			dmas = <&dmac1 0x35>, <&dmac1 0x34>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -521,8 +535,10 @@
 				     "renesas,hscif";
 			reg = <0 0xe66a0000 0 96>;
 			interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 517>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 517>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "brg_int", "scif_clk";
 			dmas = <&dmac0 0x37>, <&dmac0 0x36>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -535,8 +551,10 @@
 				     "renesas,hscif";
 			reg = <0 0xe66b0000 0 96>;
 			interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 516>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 516>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "brg_int", "scif_clk";
 			dmas = <&dmac0 0x39>, <&dmac0 0x38>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -548,8 +566,10 @@
 				     "renesas,rcar-gen3-scif", "renesas,scif";
 			reg = <0 0xe6e60000 0 64>;
 			interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 207>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 207>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "brg_int", "scif_clk";
 			dmas = <&dmac1 0x51>, <&dmac1 0x50>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -561,8 +581,10 @@
 				     "renesas,rcar-gen3-scif", "renesas,scif";
 			reg = <0 0xe6e68000 0 64>;
 			interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 206>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 206>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "brg_int", "scif_clk";
 			dmas = <&dmac1 0x53>, <&dmac1 0x52>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -574,8 +596,10 @@
 				     "renesas,rcar-gen3-scif", "renesas,scif";
 			reg = <0 0xe6e88000 0 64>;
 			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 310>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 310>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "brg_int", "scif_clk";
 			dmas = <&dmac1 0x13>, <&dmac1 0x12>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -587,8 +611,10 @@
 				     "renesas,rcar-gen3-scif", "renesas,scif";
 			reg = <0 0xe6c50000 0 64>;
 			interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 204>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 204>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "brg_int", "scif_clk";
 			dmas = <&dmac0 0x57>, <&dmac0 0x56>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -600,8 +626,10 @@
 				     "renesas,rcar-gen3-scif", "renesas,scif";
 			reg = <0 0xe6c40000 0 64>;
 			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 203>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 203>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "brg_int", "scif_clk";
 			dmas = <&dmac0 0x59>, <&dmac0 0x58>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
@@ -613,8 +641,10 @@
 				     "renesas,rcar-gen3-scif", "renesas,scif";
 			reg = <0 0xe6f30000 0 64>;
 			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&cpg CPG_MOD 202>;
-			clock-names = "fck";
+			clocks = <&cpg CPG_MOD 202>,
+				 <&cpg CPG_CORE R8A7795_CLK_S3D1>,
+				 <&scif_clk>;
+			clock-names = "fck", "brg_int", "scif_clk";
 			dmas = <&dmac1 0x5b>, <&dmac1 0x5a>;
 			dma-names = "tx", "rx";
 			power-domains = <&cpg>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:28:55 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:28:55 +0100
Subject: [PATCH 01/70] ARM: dts: gose: Add GPIO keys to DT
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <d7d5974b156e2ef7436483de00ccada5987c9d31.1454595846.git.horms+renesas@verge.net.au>

Instantiate the GPIO keys in the gose device tree.

Based on similar work for the koelsch board by Laurent Pinchart.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Tested-by: Magnus Damm <damm+renesas at opensource.se>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 82 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 82 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index baa59fe84298..ccbc1c66cc6c 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -31,6 +31,88 @@
 		device_type = "memory";
 		reg = <0 0x40000000 0 0x40000000>;
 	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		key-1 {
+		        gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_1>;
+		        label = "SW2-1";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-2 {
+		        gpios = <&gpio5 1 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_2>;
+		        label = "SW2-2";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-3 {
+		        gpios = <&gpio5 2 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_3>;
+		        label = "SW2-3";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-4 {
+		        gpios = <&gpio5 3 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_4>;
+		        label = "SW2-4";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-a {
+		        gpios = <&gpio7 0 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_A>;
+		        label = "SW30";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-b {
+		        gpios = <&gpio7 1 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_B>;
+		        label = "SW31";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-c {
+		        gpios = <&gpio7 2 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_C>;
+		        label = "SW32";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-d {
+		        gpios = <&gpio7 3 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_D>;
+		        label = "SW33";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-e {
+		        gpios = <&gpio7 4 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_E>;
+		        label = "SW34";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-f {
+		        gpios = <&gpio7 5 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_F>;
+		        label = "SW35";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-g {
+		        gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_G>;
+		        label = "SW36";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+	};
 };
 
 &extal_clk {
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:28:56 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:28:56 +0100
Subject: [PATCH 02/70] ARM: dts: gose: Add GPIO leds to DT
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <3b18d8593d4cb6880c6647c26ccfcd3eb5a849d9.1454595846.git.horms+renesas@verge.net.au>

Instantiate the GPIO leds in the gose device tree.

Based on similar work for the koelsch board by Magnus Damm.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Tested-by: Magnus Damm <damm+renesas at opensource.se>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index ccbc1c66cc6c..90b587c3c736 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -113,6 +113,22 @@
 		        debounce-interval = <20>;
 		};
 	};
+
+	leds {
+		compatible = "gpio-leds";
+		led6 {
+			gpios = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+			label = "LED6";
+		};
+		led7 {
+			gpios = <&gpio2 20 GPIO_ACTIVE_HIGH>;
+			label = "LED7";
+		};
+		led8 {
+			gpios = <&gpio2 21 GPIO_ACTIVE_HIGH>;
+			label = "LED8";
+		};
+	};
 };
 
 &extal_clk {
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:28:57 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:28:57 +0100
Subject: [PATCH 03/70] ARM: dts: porter: add DU DT support
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <c5af8a4248d3cb01078d2a20df28081dd588b0e3.1454595846.git.horms+renesas@verge.net.au>

From: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

Define  the Porter board dependent part of the DU device node.
Add the device node  for Analog Devices ADV7511W  HDMI transmitter to I2C2
bus and the HDMI connector. Add the necessary subnodes to interconnect  DU
and HDMI devices.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791-porter.dts | 81 ++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
index 6713b1ea732b..fe81fa0e478c 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -78,6 +78,29 @@
 		states = <3300000 1
 			  1800000 0>;
 	};
+
+	hdmi-out {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_con: endpoint {
+				remote-endpoint = <&adv7511_out>;
+			};
+		};
+	};
+
+	x3_clk: x3-clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <148500000>;
+	};
+
+	x16_clk: x16-clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <74250000>;
+	};
 };
 
 &extal_clk {
@@ -139,6 +162,11 @@
 		renesas,groups = "can0_data";
 		renesas,function = "can0";
 	};
+
+	du_pins: du {
+		renesas,groups = "du_rgb888", "du_sync", "du_disp", "du_clk_out_0";
+		renesas,function = "du";
+	};
 };
 
 &scif0 {
@@ -241,6 +269,38 @@
 			};
 		};
 	};
+
+	hdmi at 39 {
+		compatible = "adi,adv7511w";
+		reg = <0x39>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+
+		adi,input-depth = <8>;
+		adi,input-colorspace = "rgb";
+		adi,input-clock = "1x";
+		adi,input-style = <1>;
+		adi,input-justification = "evenly";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				adv7511_in: endpoint {
+					remote-endpoint = <&du_out_rgb>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+				adv7511_out: endpoint {
+					remote-endpoint = <&hdmi_con>;
+				};
+			};
+		};
+	};
 };
 
 &sata0 {
@@ -304,3 +364,24 @@
 
 	status = "okay";
 };
+
+&du {
+	pinctrl-0 = <&du_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	clocks = <&mstp7_clks R8A7791_CLK_DU0>,
+		 <&mstp7_clks R8A7791_CLK_DU1>,
+		 <&mstp7_clks R8A7791_CLK_LVDS0>,
+		 <&x3_clk>, <&x16_clk>;
+	clock-names = "du.0", "du.1", "lvds.0",
+		      "dclkin.0", "dclkin.1";
+
+	ports {
+		port at 1 {
+			endpoint {
+				remote-endpoint = <&adv7511_in>;
+			};
+		};
+	};
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:28:58 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:28:58 +0100
Subject: [PATCH 04/70] ARM: dts: r8a7793: Add I2C master nodes to DT
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <7aed17f4450ba6863937797d88dab64088f38ccc.1454595846.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Instantiate all the 9 I2C controllers in the disabled state.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 135 ++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 132 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index aef9e69d6c26..f9d92de4f65b 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -19,6 +19,15 @@
 	#size-cells = <2>;
 
 	aliases {
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+		i2c4 = &i2c4;
+		i2c5 = &i2c5;
+		i2c6 = &i2c6;
+		i2c7 = &i2c7;
+		i2c8 = &i2c8;
 		spi0 = &qspi;
 	};
 
@@ -230,6 +239,120 @@
 		power-domains = <&cpg_clocks>;
 	};
 
+	/* The memory map in the User's Manual maps the cores to bus numbers */
+	i2c0: i2c at e6508000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,i2c-r8a7793";
+		reg = <0 0xe6508000 0 0x40>;
+		interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp9_clks R8A7793_CLK_I2C0>;
+		power-domains = <&cpg_clocks>;
+		i2c-scl-internal-delay-ns = <6>;
+		status = "disabled";
+	};
+
+	i2c1: i2c at e6518000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,i2c-r8a7793";
+		reg = <0 0xe6518000 0 0x40>;
+		interrupts = <0 288 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp9_clks R8A7793_CLK_I2C1>;
+		power-domains = <&cpg_clocks>;
+		i2c-scl-internal-delay-ns = <6>;
+		status = "disabled";
+	};
+
+	i2c2: i2c at e6530000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,i2c-r8a7793";
+		reg = <0 0xe6530000 0 0x40>;
+		interrupts = <0 286 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp9_clks R8A7793_CLK_I2C2>;
+		power-domains = <&cpg_clocks>;
+		i2c-scl-internal-delay-ns = <6>;
+		status = "disabled";
+	};
+
+	i2c3: i2c at e6540000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,i2c-r8a7793";
+		reg = <0 0xe6540000 0 0x40>;
+		interrupts = <0 290 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp9_clks R8A7793_CLK_I2C3>;
+		power-domains = <&cpg_clocks>;
+		i2c-scl-internal-delay-ns = <6>;
+		status = "disabled";
+	};
+
+	i2c4: i2c at e6520000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,i2c-r8a7793";
+		reg = <0 0xe6520000 0 0x40>;
+		interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp9_clks R8A7793_CLK_I2C4>;
+		power-domains = <&cpg_clocks>;
+		i2c-scl-internal-delay-ns = <6>;
+		status = "disabled";
+	};
+
+	i2c5: i2c at e6528000 {
+		/* doesn't need pinmux */
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,i2c-r8a7793";
+		reg = <0 0xe6528000 0 0x40>;
+		interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp9_clks R8A7793_CLK_I2C5>;
+		power-domains = <&cpg_clocks>;
+		i2c-scl-internal-delay-ns = <110>;
+		status = "disabled";
+	};
+
+	i2c6: i2c at e60b0000 {
+		/* doesn't need pinmux */
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
+		reg = <0 0xe60b0000 0 0x425>;
+		interrupts = <0 173 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp9_clks R8A7793_CLK_IICDVFS>;
+		dmas = <&dmac0 0x77>, <&dmac0 0x78>;
+		dma-names = "tx", "rx";
+		power-domains = <&cpg_clocks>;
+		status = "disabled";
+	};
+
+	i2c7: i2c at e6500000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
+		reg = <0 0xe6500000 0 0x425>;
+		interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp3_clks R8A7793_CLK_IIC0>;
+		dmas = <&dmac0 0x61>, <&dmac0 0x62>;
+		dma-names = "tx", "rx";
+		power-domains = <&cpg_clocks>;
+		status = "disabled";
+	};
+
+	i2c8: i2c at e6510000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
+		reg = <0 0xe6510000 0 0x425>;
+		interrupts = <0 175 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp3_clks R8A7793_CLK_IIC1>;
+		dmas = <&dmac0 0x65>, <&dmac0 0x66>;
+		dma-names = "tx", "rx";
+		power-domains = <&cpg_clocks>;
+		status = "disabled";
+	};
+
 	pfc: pfc at e6060000 {
 		compatible = "renesas,pfc-r8a7793";
 		reg = <0 0xe6060000 0 0x250>;
@@ -820,19 +943,25 @@
 			reg = <0 0xe6150994 0 4>, <0 0xe61509a4 0 4>;
 			clocks = <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>,
 				 <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>,
-				 <&cpg_clocks R8A7793_CLK_QSPI>;
+				 <&cpg_clocks R8A7793_CLK_QSPI>, <&hp_clk>,
+				 <&cp_clk>, <&hp_clk>, <&hp_clk>, <&hp_clk>,
+				 <&hp_clk>, <&hp_clk>;
 			#clock-cells = <1>;
 			clock-indices = <
 				R8A7793_CLK_GPIO7 R8A7793_CLK_GPIO6
 				R8A7793_CLK_GPIO5 R8A7793_CLK_GPIO4
 				R8A7793_CLK_GPIO3 R8A7793_CLK_GPIO2
 				R8A7793_CLK_GPIO1 R8A7793_CLK_GPIO0
-				R8A7793_CLK_QSPI_MOD
+				R8A7793_CLK_QSPI_MOD R8A7793_CLK_I2C5
+				R8A7793_CLK_IICDVFS R8A7793_CLK_I2C4
+				R8A7793_CLK_I2C3 R8A7793_CLK_I2C2
+				R8A7793_CLK_I2C1 R8A7793_CLK_I2C0
 			>;
 			clock-output-names =
 				"gpio7", "gpio6", "gpio5", "gpio4",
 				"gpio3", "gpio2", "gpio1", "gpio0",
-				"qspi_mod";
+				"qspi_mod", "i2c5", "i2c6", "i2c4",
+				"i2c3", "i2c2", "i2c1", "i2c0";
 		};
 		mstp11_clks: mstp11_clks at e615099c {
 			compatible = "renesas,r8a7793-mstp-clocks", "renesas,cpg-mstp-clocks";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:00 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:00 +0100
Subject: [PATCH 06/70] ARM: dts: r8a7790: use fallback usbhs compatibility
 string
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <d87ec94aee6dc62ed5db4cad7dba47006c0dd00e.1454595846.git.horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7790 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7790.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 7dfd393bfc7e..4d9af0f46fab 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -746,7 +746,7 @@
 	};
 
 	hsusb: usb at e6590000 {
-		compatible = "renesas,usbhs-r8a7790";
+		compatible = "renesas,usbhs-r8a7790", "renesas,rcar-gen2-usbhs";
 		reg = <0 0xe6590000 0 0x100>;
 		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:08 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:08 +0100
Subject: [PATCH 14/70] ARM: dts: r8a7793: use GIC_* defines
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <214e8481fe1fef5e88f80f0da6c9bfbd1963099f.1454595846.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7793 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7793.dtsi | 216 ++++++++++++++++++++---------------------
 1 file changed, 108 insertions(+), 108 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 0ce7cc420c9d..ea1196b99d52 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -63,13 +63,13 @@
 			<0 0xf1002000 0 0x1000>,
 			<0 0xf1004000 0 0x2000>,
 			<0 0xf1006000 0 0x2000>;
-		interrupts = <1 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
 	};
 
 	gpio0: gpio at e6050000 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6050000 0 0x50>;
-		interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 0 32>;
@@ -82,7 +82,7 @@
 	gpio1: gpio at e6051000 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6051000 0 0x50>;
-		interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 32 26>;
@@ -95,7 +95,7 @@
 	gpio2: gpio at e6052000 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6052000 0 0x50>;
-		interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 64 32>;
@@ -108,7 +108,7 @@
 	gpio3: gpio at e6053000 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6053000 0 0x50>;
-		interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 96 32>;
@@ -121,7 +121,7 @@
 	gpio4: gpio at e6054000 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6054000 0 0x50>;
-		interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 128 32>;
@@ -134,7 +134,7 @@
 	gpio5: gpio at e6055000 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6055000 0 0x50>;
-		interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 160 32>;
@@ -147,7 +147,7 @@
 	gpio6: gpio at e6055400 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6055400 0 0x50>;
-		interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 192 32>;
@@ -160,7 +160,7 @@
 	gpio7: gpio at e6055800 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6055800 0 0x50>;
-		interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 224 26>;
@@ -173,24 +173,24 @@
 	thermal at e61f0000 {
 		compatible = "renesas,thermal-r8a7793", "renesas,rcar-thermal";
 		reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
-		interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks R8A7793_CLK_THERMAL>;
 		power-domains = <&cpg_clocks>;
 	};
 
 	timer {
 		compatible = "arm,armv7-timer";
-		interrupts = <1 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
 	};
 
 	cmt0: timer at ffca0000 {
 		compatible = "renesas,cmt-48-r8a7793", "renesas,cmt-48-gen2";
 		reg = <0 0xffca0000 0 0x1004>;
-		interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 143 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7793_CLK_CMT0>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -203,14 +203,14 @@
 	cmt1: timer at e6130000 {
 		compatible = "renesas,cmt-48-r8a7793", "renesas,cmt-48-gen2";
 		reg = <0 0xe6130000 0 0x1004>;
-		interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 121 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 122 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 123 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 124 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 125 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 126 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 127 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7793_CLK_CMT1>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -225,16 +225,16 @@
 		#interrupt-cells = <2>;
 		interrupt-controller;
 		reg = <0 0xe61c0000 0 0x200>;
-		interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 1 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 2 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 3 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 12 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 13 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 14 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 15 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 16 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 17 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A7793_CLK_IRQC>;
 		power-domains = <&cpg_clocks>;
 	};
@@ -242,22 +242,22 @@
 	dmac0: dma-controller at e6700000 {
 		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
 		reg = <0 0xe6700000 0 0x20000>;
-		interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH
-			      0 200 IRQ_TYPE_LEVEL_HIGH
-			      0 201 IRQ_TYPE_LEVEL_HIGH
-			      0 202 IRQ_TYPE_LEVEL_HIGH
-			      0 203 IRQ_TYPE_LEVEL_HIGH
-			      0 204 IRQ_TYPE_LEVEL_HIGH
-			      0 205 IRQ_TYPE_LEVEL_HIGH
-			      0 206 IRQ_TYPE_LEVEL_HIGH
-			      0 207 IRQ_TYPE_LEVEL_HIGH
-			      0 208 IRQ_TYPE_LEVEL_HIGH
-			      0 209 IRQ_TYPE_LEVEL_HIGH
-			      0 210 IRQ_TYPE_LEVEL_HIGH
-			      0 211 IRQ_TYPE_LEVEL_HIGH
-			      0 212 IRQ_TYPE_LEVEL_HIGH
-			      0 213 IRQ_TYPE_LEVEL_HIGH
-			      0 214 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -273,22 +273,22 @@
 	dmac1: dma-controller at e6720000 {
 		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
 		reg = <0 0xe6720000 0 0x20000>;
-		interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
-			      0 216 IRQ_TYPE_LEVEL_HIGH
-			      0 217 IRQ_TYPE_LEVEL_HIGH
-			      0 218 IRQ_TYPE_LEVEL_HIGH
-			      0 219 IRQ_TYPE_LEVEL_HIGH
-			      0 308 IRQ_TYPE_LEVEL_HIGH
-			      0 309 IRQ_TYPE_LEVEL_HIGH
-			      0 310 IRQ_TYPE_LEVEL_HIGH
-			      0 311 IRQ_TYPE_LEVEL_HIGH
-			      0 312 IRQ_TYPE_LEVEL_HIGH
-			      0 313 IRQ_TYPE_LEVEL_HIGH
-			      0 314 IRQ_TYPE_LEVEL_HIGH
-			      0 315 IRQ_TYPE_LEVEL_HIGH
-			      0 316 IRQ_TYPE_LEVEL_HIGH
-			      0 317 IRQ_TYPE_LEVEL_HIGH
-			      0 318 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -307,7 +307,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7793";
 		reg = <0 0xe6508000 0 0x40>;
-		interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_I2C0>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -319,7 +319,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7793";
 		reg = <0 0xe6518000 0 0x40>;
-		interrupts = <0 288 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_I2C1>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -331,7 +331,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7793";
 		reg = <0 0xe6530000 0 0x40>;
-		interrupts = <0 286 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_I2C2>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -343,7 +343,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7793";
 		reg = <0 0xe6540000 0 0x40>;
-		interrupts = <0 290 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_I2C3>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -355,7 +355,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7793";
 		reg = <0 0xe6520000 0 0x40>;
-		interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_I2C4>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -368,7 +368,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7793";
 		reg = <0 0xe6528000 0 0x40>;
-		interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_I2C5>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <110>;
@@ -381,7 +381,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
 		reg = <0 0xe60b0000 0 0x425>;
-		interrupts = <0 173 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_IICDVFS>;
 		dmas = <&dmac0 0x77>, <&dmac0 0x78>;
 		dma-names = "tx", "rx";
@@ -394,7 +394,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
 		reg = <0 0xe6500000 0 0x425>;
-		interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7793_CLK_IIC0>;
 		dmas = <&dmac0 0x61>, <&dmac0 0x62>;
 		dma-names = "tx", "rx";
@@ -407,7 +407,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
 		reg = <0 0xe6510000 0 0x425>;
-		interrupts = <0 175 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7793_CLK_IIC1>;
 		dmas = <&dmac0 0x65>, <&dmac0 0x66>;
 		dma-names = "tx", "rx";
@@ -423,7 +423,7 @@
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
-		interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
@@ -435,7 +435,7 @@
 	scifa1: serial at e6c50000 {
 		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
-		interrupts = <0 145 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
@@ -447,7 +447,7 @@
 	scifa2: serial at e6c60000 {
 		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
-		interrupts = <0 151 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
@@ -459,7 +459,7 @@
 	scifa3: serial at e6c70000 {
 		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
 		reg = <0 0xe6c70000 0 64>;
-		interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA3>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1b>, <&dmac0 0x1c>;
@@ -471,7 +471,7 @@
 	scifa4: serial at e6c78000 {
 		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
 		reg = <0 0xe6c78000 0 64>;
-		interrupts = <0 30 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA4>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1f>, <&dmac0 0x20>;
@@ -483,7 +483,7 @@
 	scifa5: serial at e6c80000 {
 		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
 		reg = <0 0xe6c80000 0 64>;
-		interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA5>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x23>, <&dmac0 0x24>;
@@ -495,7 +495,7 @@
 	scifb0: serial at e6c20000 {
 		compatible = "renesas,scifb-r8a7793", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
-		interrupts = <0 148 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
@@ -507,7 +507,7 @@
 	scifb1: serial at e6c30000 {
 		compatible = "renesas,scifb-r8a7793", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
@@ -519,7 +519,7 @@
 	scifb2: serial at e6ce0000 {
 		compatible = "renesas,scifb-r8a7793", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
-		interrupts = <0 150 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
@@ -531,7 +531,7 @@
 	scif0: serial at e6e60000 {
 		compatible = "renesas,scif-r8a7793", "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
-		interrupts = <0 152 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
@@ -543,7 +543,7 @@
 	scif1: serial at e6e68000 {
 		compatible = "renesas,scif-r8a7793", "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
-		interrupts = <0 153 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
@@ -555,7 +555,7 @@
 	scif2: serial at e6e58000 {
 		compatible = "renesas,scif-r8a7793", "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
-		interrupts = <0 22 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
@@ -567,7 +567,7 @@
 	scif3: serial at e6ea8000 {
 		compatible = "renesas,scif-r8a7793", "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
-		interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF3>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
@@ -579,7 +579,7 @@
 	scif4: serial at e6ee0000 {
 		compatible = "renesas,scif-r8a7793", "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
-		interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF4>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
@@ -591,7 +591,7 @@
 	scif5: serial at e6ee8000 {
 		compatible = "renesas,scif-r8a7793", "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
-		interrupts = <0 25 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF5>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
@@ -603,7 +603,7 @@
 	hscif0: serial at e62c0000 {
 		compatible = "renesas,hscif-r8a7793", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
-		interrupts = <0 154 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
@@ -615,7 +615,7 @@
 	hscif1: serial at e62c8000 {
 		compatible = "renesas,hscif-r8a7793", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
-		interrupts = <0 155 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
@@ -627,7 +627,7 @@
 	hscif2: serial at e62d0000 {
 		compatible = "renesas,hscif-r8a7793", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
-		interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
@@ -639,7 +639,7 @@
 	ether: ethernet at ee700000 {
 		compatible = "renesas,ether-r8a7793";
 		reg = <0 0xee700000 0 0x400>;
-		interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7793_CLK_ETHER>;
 		power-domains = <&cpg_clocks>;
 		phy-mode = "rmii";
@@ -651,7 +651,7 @@
 	qspi: spi at e6b10000 {
 		compatible = "renesas,qspi-r8a7793", "renesas,qspi";
 		reg = <0 0xe6b10000 0 0x2c>;
-		interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_QSPI_MOD>;
 		dmas = <&dmac0 0x17>, <&dmac0 0x18>;
 		dma-names = "tx", "rx";
@@ -667,8 +667,8 @@
 		reg = <0 0xfeb00000 0 0x40000>,
 		      <0 0xfeb90000 0 0x1c>;
 		reg-names = "du", "lvds.0";
-		interrupts = <0 256 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 268 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_DU0>,
 			 <&mstp7_clks R8A7793_CLK_DU1>,
 			 <&mstp7_clks R8A7793_CLK_LVDS0>;
@@ -978,8 +978,8 @@
 	ipmmu_sy0: mmu at e6280000 {
 		compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6280000 0 0x1000>;
-		interrupts = <0 223 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 224 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -987,7 +987,7 @@
 	ipmmu_sy1: mmu at e6290000 {
 		compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6290000 0 0x1000>;
-		interrupts = <0 225 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -995,8 +995,8 @@
 	ipmmu_ds: mmu at e6740000 {
 		compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6740000 0 0x1000>;
-		interrupts = <0 198 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 199 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1004,7 +1004,7 @@
 	ipmmu_mp: mmu at ec680000 {
 		compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
 		reg = <0 0xec680000 0 0x1000>;
-		interrupts = <0 226 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1012,8 +1012,8 @@
 	ipmmu_mx: mmu at fe951000 {
 		compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
 		reg = <0 0xfe951000 0 0x1000>;
-		interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 221 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1021,7 +1021,7 @@
 	ipmmu_rt: mmu at ffc80000 {
 		compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
 		reg = <0 0xffc80000 0 0x1000>;
-		interrupts = <0 307 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1029,8 +1029,8 @@
 	ipmmu_gp: mmu at e62a0000 {
 		compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
 		reg = <0 0xe62a0000 0 0x1000>;
-		interrupts = <0 260 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 261 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 261 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From bcrl at kvack.org  Thu Feb  4 06:32:04 2016
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Thu, 4 Feb 2016 09:32:04 -0500
Subject: linux-next: build failure after merge of the aio tree
In-Reply-To: <20160204141253.GF10826@n2100.arm.linux.org.uk>
References: <20160112164034.0fe945a7@canb.auug.org.au>
 <20160112163835.GD347@kvack.org> <20160127134024.0fababf6@canb.auug.org.au>
 <20160129113056.GP10826@n2100.arm.linux.org.uk>
 <CAMuHMdUy-cqeN8COO4rdpY-mOH+6gth40wB31-edkj8CO5PFCw@mail.gmail.com>
 <20160204131959.6695c7bf@canb.auug.org.au> <20160204134142.GA16315@kvack.org>
 <20160204135056.GE10826@n2100.arm.linux.org.uk>
 <20160204140822.GB16315@kvack.org>
 <20160204141253.GF10826@n2100.arm.linux.org.uk>
Message-ID: <20160204143204.GC16315@kvack.org>

On Thu, Feb 04, 2016 at 02:12:53PM +0000, Russell King - ARM Linux wrote:
> Hence, __get_user() on x86-32 with a 64-bit quantity results in
> __get_user_bad() being called, which is an undefined function.
> Only if you build with x86-64 support enabled (iow, CONFIG_X86_32 not
> defined) then you get the 64-bit __get_user() support.
> 
> Given this, I fail to see how x86-32 can possibly work.

You're right; mea culpa.  It compiles without warning on x86-32, but it 
does not link.  I still think this is broken archtecture stupidity since 
put_user() works for 64 bit data types.

		-ben
-- 
"Thought is the essence of where you are now."


From horms+renesas at verge.net.au  Thu Feb  4 06:29:05 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:05 +0100
Subject: [PATCH 11/70] ARM: dts: r8a7790: use GIC_* defines
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <3abb4d5fc3a1fbfdd414d50d9c1d01bfd453c4a9.1454595846.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7791 device tree.

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 368 ++++++++++++++++++++---------------------
 1 file changed, 184 insertions(+), 184 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 4d9af0f46fab..cc7eccf0ada7 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -121,13 +121,13 @@
 			<0 0xf1002000 0 0x1000>,
 			<0 0xf1004000 0 0x2000>,
 			<0 0xf1006000 0 0x2000>;
-		interrupts = <1 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
 	};
 
 	gpio0: gpio at e6050000 {
 		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
 		reg = <0 0xe6050000 0 0x50>;
-		interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 0 32>;
@@ -140,7 +140,7 @@
 	gpio1: gpio at e6051000 {
 		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
 		reg = <0 0xe6051000 0 0x50>;
-		interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 32 30>;
@@ -153,7 +153,7 @@
 	gpio2: gpio at e6052000 {
 		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
 		reg = <0 0xe6052000 0 0x50>;
-		interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 64 30>;
@@ -166,7 +166,7 @@
 	gpio3: gpio at e6053000 {
 		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
 		reg = <0 0xe6053000 0 0x50>;
-		interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 96 32>;
@@ -179,7 +179,7 @@
 	gpio4: gpio at e6054000 {
 		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
 		reg = <0 0xe6054000 0 0x50>;
-		interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 128 32>;
@@ -192,7 +192,7 @@
 	gpio5: gpio at e6055000 {
 		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
 		reg = <0 0xe6055000 0 0x50>;
-		interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 160 32>;
@@ -205,24 +205,24 @@
 	thermal at e61f0000 {
 		compatible = "renesas,thermal-r8a7790", "renesas,rcar-thermal";
 		reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
-		interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks R8A7790_CLK_THERMAL>;
 		power-domains = <&cpg_clocks>;
 	};
 
 	timer {
 		compatible = "arm,armv7-timer";
-		interrupts = <1 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
 	};
 
 	cmt0: timer at ffca0000 {
 		compatible = "renesas,cmt-48-r8a7790", "renesas,cmt-48-gen2";
 		reg = <0 0xffca0000 0 0x1004>;
-		interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 143 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7790_CLK_CMT0>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -235,14 +235,14 @@
 	cmt1: timer at e6130000 {
 		compatible = "renesas,cmt-48-r8a7790", "renesas,cmt-48-gen2";
 		reg = <0 0xe6130000 0 0x1004>;
-		interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 121 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 122 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 123 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 124 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 125 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 126 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 127 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_CMT1>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -257,10 +257,10 @@
 		#interrupt-cells = <2>;
 		interrupt-controller;
 		reg = <0 0xe61c0000 0 0x200>;
-		interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 1 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 2 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 3 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A7790_CLK_IRQC>;
 		power-domains = <&cpg_clocks>;
 	};
@@ -268,22 +268,22 @@
 	dmac0: dma-controller at e6700000 {
 		compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
 		reg = <0 0xe6700000 0 0x20000>;
-		interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH
-			      0 200 IRQ_TYPE_LEVEL_HIGH
-			      0 201 IRQ_TYPE_LEVEL_HIGH
-			      0 202 IRQ_TYPE_LEVEL_HIGH
-			      0 203 IRQ_TYPE_LEVEL_HIGH
-			      0 204 IRQ_TYPE_LEVEL_HIGH
-			      0 205 IRQ_TYPE_LEVEL_HIGH
-			      0 206 IRQ_TYPE_LEVEL_HIGH
-			      0 207 IRQ_TYPE_LEVEL_HIGH
-			      0 208 IRQ_TYPE_LEVEL_HIGH
-			      0 209 IRQ_TYPE_LEVEL_HIGH
-			      0 210 IRQ_TYPE_LEVEL_HIGH
-			      0 211 IRQ_TYPE_LEVEL_HIGH
-			      0 212 IRQ_TYPE_LEVEL_HIGH
-			      0 213 IRQ_TYPE_LEVEL_HIGH
-			      0 214 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -299,22 +299,22 @@
 	dmac1: dma-controller at e6720000 {
 		compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
 		reg = <0 0xe6720000 0 0x20000>;
-		interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
-			      0 216 IRQ_TYPE_LEVEL_HIGH
-			      0 217 IRQ_TYPE_LEVEL_HIGH
-			      0 218 IRQ_TYPE_LEVEL_HIGH
-			      0 219 IRQ_TYPE_LEVEL_HIGH
-			      0 308 IRQ_TYPE_LEVEL_HIGH
-			      0 309 IRQ_TYPE_LEVEL_HIGH
-			      0 310 IRQ_TYPE_LEVEL_HIGH
-			      0 311 IRQ_TYPE_LEVEL_HIGH
-			      0 312 IRQ_TYPE_LEVEL_HIGH
-			      0 313 IRQ_TYPE_LEVEL_HIGH
-			      0 314 IRQ_TYPE_LEVEL_HIGH
-			      0 315 IRQ_TYPE_LEVEL_HIGH
-			      0 316 IRQ_TYPE_LEVEL_HIGH
-			      0 317 IRQ_TYPE_LEVEL_HIGH
-			      0 318 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -330,20 +330,20 @@
 	audma0: dma-controller at ec700000 {
 		compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
 		reg = <0 0xec700000 0 0x10000>;
-		interrupts =	<0 346 IRQ_TYPE_LEVEL_HIGH
-				 0 320 IRQ_TYPE_LEVEL_HIGH
-				 0 321 IRQ_TYPE_LEVEL_HIGH
-				 0 322 IRQ_TYPE_LEVEL_HIGH
-				 0 323 IRQ_TYPE_LEVEL_HIGH
-				 0 324 IRQ_TYPE_LEVEL_HIGH
-				 0 325 IRQ_TYPE_LEVEL_HIGH
-				 0 326 IRQ_TYPE_LEVEL_HIGH
-				 0 327 IRQ_TYPE_LEVEL_HIGH
-				 0 328 IRQ_TYPE_LEVEL_HIGH
-				 0 329 IRQ_TYPE_LEVEL_HIGH
-				 0 330 IRQ_TYPE_LEVEL_HIGH
-				 0 331 IRQ_TYPE_LEVEL_HIGH
-				 0 332 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts =	<GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -359,20 +359,20 @@
 	audma1: dma-controller at ec720000 {
 		compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
 		reg = <0 0xec720000 0 0x10000>;
-		interrupts =	<0 347 IRQ_TYPE_LEVEL_HIGH
-				 0 333 IRQ_TYPE_LEVEL_HIGH
-				 0 334 IRQ_TYPE_LEVEL_HIGH
-				 0 335 IRQ_TYPE_LEVEL_HIGH
-				 0 336 IRQ_TYPE_LEVEL_HIGH
-				 0 337 IRQ_TYPE_LEVEL_HIGH
-				 0 338 IRQ_TYPE_LEVEL_HIGH
-				 0 339 IRQ_TYPE_LEVEL_HIGH
-				 0 340 IRQ_TYPE_LEVEL_HIGH
-				 0 341 IRQ_TYPE_LEVEL_HIGH
-				 0 342 IRQ_TYPE_LEVEL_HIGH
-				 0 343 IRQ_TYPE_LEVEL_HIGH
-				 0 344 IRQ_TYPE_LEVEL_HIGH
-				 0 345 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts =	<GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -388,8 +388,8 @@
 	usb_dmac0: dma-controller at e65a0000 {
 		compatible = "renesas,r8a7790-usb-dmac", "renesas,usb-dmac";
 		reg = <0 0xe65a0000 0 0x100>;
-		interrupts = <0 109 IRQ_TYPE_LEVEL_HIGH
-			      0 109 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "ch0", "ch1";
 		clocks = <&mstp3_clks R8A7790_CLK_USBDMAC0>;
 		power-domains = <&cpg_clocks>;
@@ -400,8 +400,8 @@
 	usb_dmac1: dma-controller at e65b0000 {
 		compatible = "renesas,r8a7790-usb-dmac", "renesas,usb-dmac";
 		reg = <0 0xe65b0000 0 0x100>;
-		interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH
-			      0 110 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "ch0", "ch1";
 		clocks = <&mstp3_clks R8A7790_CLK_USBDMAC1>;
 		power-domains = <&cpg_clocks>;
@@ -414,7 +414,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7790";
 		reg = <0 0xe6508000 0 0x40>;
-		interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_I2C0>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <110>;
@@ -426,7 +426,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7790";
 		reg = <0 0xe6518000 0 0x40>;
-		interrupts = <0 288 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_I2C1>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -438,7 +438,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7790";
 		reg = <0 0xe6530000 0 0x40>;
-		interrupts = <0 286 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_I2C2>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -450,7 +450,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7790";
 		reg = <0 0xe6540000 0 0x40>;
-		interrupts = <0 290 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_I2C3>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <110>;
@@ -462,7 +462,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
 		reg = <0 0xe6500000 0 0x425>;
-		interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_IIC0>;
 		dmas = <&dmac0 0x61>, <&dmac0 0x62>;
 		dma-names = "tx", "rx";
@@ -475,7 +475,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
 		reg = <0 0xe6510000 0 0x425>;
-		interrupts = <0 175 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_IIC1>;
 		dmas = <&dmac0 0x65>, <&dmac0 0x66>;
 		dma-names = "tx", "rx";
@@ -488,7 +488,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
 		reg = <0 0xe6520000 0 0x425>;
-		interrupts = <0 176 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_IIC2>;
 		dmas = <&dmac0 0x69>, <&dmac0 0x6a>;
 		dma-names = "tx", "rx";
@@ -501,7 +501,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
 		reg = <0 0xe60b0000 0 0x425>;
-		interrupts = <0 173 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_IICDVFS>;
 		dmas = <&dmac0 0x77>, <&dmac0 0x78>;
 		dma-names = "tx", "rx";
@@ -512,7 +512,7 @@
 	mmcif0: mmc at ee200000 {
 		compatible = "renesas,mmcif-r8a7790", "renesas,sh-mmcif";
 		reg = <0 0xee200000 0 0x80>;
-		interrupts = <0 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_MMCIF0>;
 		dmas = <&dmac0 0xd1>, <&dmac0 0xd2>;
 		dma-names = "tx", "rx";
@@ -525,7 +525,7 @@
 	mmcif1: mmc at ee220000 {
 		compatible = "renesas,mmcif-r8a7790", "renesas,sh-mmcif";
 		reg = <0 0xee220000 0 0x80>;
-		interrupts = <0 170 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_MMCIF1>;
 		dmas = <&dmac0 0xe1>, <&dmac0 0xe2>;
 		dma-names = "tx", "rx";
@@ -543,7 +543,7 @@
 	sdhi0: sd at ee100000 {
 		compatible = "renesas,sdhi-r8a7790";
 		reg = <0 0xee100000 0 0x328>;
-		interrupts = <0 165 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_SDHI0>;
 		dmas = <&dmac1 0xcd>, <&dmac1 0xce>;
 		dma-names = "tx", "rx";
@@ -554,7 +554,7 @@
 	sdhi1: sd at ee120000 {
 		compatible = "renesas,sdhi-r8a7790";
 		reg = <0 0xee120000 0 0x328>;
-		interrupts = <0 166 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_SDHI1>;
 		dmas = <&dmac1 0xc9>, <&dmac1 0xca>;
 		dma-names = "tx", "rx";
@@ -565,7 +565,7 @@
 	sdhi2: sd at ee140000 {
 		compatible = "renesas,sdhi-r8a7790";
 		reg = <0 0xee140000 0 0x100>;
-		interrupts = <0 167 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_SDHI2>;
 		dmas = <&dmac1 0xc1>, <&dmac1 0xc2>;
 		dma-names = "tx", "rx";
@@ -576,7 +576,7 @@
 	sdhi3: sd at ee160000 {
 		compatible = "renesas,sdhi-r8a7790";
 		reg = <0 0xee160000 0 0x100>;
-		interrupts = <0 168 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_SDHI3>;
 		dmas = <&dmac1 0xd3>, <&dmac1 0xd4>;
 		dma-names = "tx", "rx";
@@ -587,7 +587,7 @@
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a7790", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
-		interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
@@ -599,7 +599,7 @@
 	scifa1: serial at e6c50000 {
 		compatible = "renesas,scifa-r8a7790", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
-		interrupts = <0 145 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
@@ -611,7 +611,7 @@
 	scifa2: serial at e6c60000 {
 		compatible = "renesas,scifa-r8a7790", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
-		interrupts = <0 151 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
@@ -623,7 +623,7 @@
 	scifb0: serial at e6c20000 {
 		compatible = "renesas,scifb-r8a7790", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
-		interrupts = <0 148 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
@@ -635,7 +635,7 @@
 	scifb1: serial at e6c30000 {
 		compatible = "renesas,scifb-r8a7790", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
@@ -647,7 +647,7 @@
 	scifb2: serial at e6ce0000 {
 		compatible = "renesas,scifb-r8a7790", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
-		interrupts = <0 150 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
@@ -659,7 +659,7 @@
 	scif0: serial at e6e60000 {
 		compatible = "renesas,scif-r8a7790", "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
-		interrupts = <0 152 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_SCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
@@ -671,7 +671,7 @@
 	scif1: serial at e6e68000 {
 		compatible = "renesas,scif-r8a7790", "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
-		interrupts = <0 153 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_SCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
@@ -683,7 +683,7 @@
 	hscif0: serial at e62c0000 {
 		compatible = "renesas,hscif-r8a7790", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
-		interrupts = <0 154 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
@@ -695,7 +695,7 @@
 	hscif1: serial at e62c8000 {
 		compatible = "renesas,hscif-r8a7790", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
-		interrupts = <0 155 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
@@ -707,7 +707,7 @@
 	ether: ethernet at ee700000 {
 		compatible = "renesas,ether-r8a7790";
 		reg = <0 0xee700000 0 0x400>;
-		interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_ETHER>;
 		power-domains = <&cpg_clocks>;
 		phy-mode = "rmii";
@@ -719,7 +719,7 @@
 	avb: ethernet at e6800000 {
 		compatible = "renesas,etheravb-r8a7790";
 		reg = <0 0xe6800000 0 0x800>, <0 0xee0e8000 0 0x4000>;
-		interrupts = <0 163 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_ETHERAVB>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -730,7 +730,7 @@
 	sata0: sata at ee300000 {
 		compatible = "renesas,sata-r8a7790";
 		reg = <0 0xee300000 0 0x2000>;
-		interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_SATA0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -739,7 +739,7 @@
 	sata1: sata at ee500000 {
 		compatible = "renesas,sata-r8a7790";
 		reg = <0 0xee500000 0 0x2000>;
-		interrupts = <0 106 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_SATA1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -748,7 +748,7 @@
 	hsusb: usb at e6590000 {
 		compatible = "renesas,usbhs-r8a7790", "renesas,rcar-gen2-usbhs";
 		reg = <0 0xe6590000 0 0x100>;
-		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
 		dmas = <&usb_dmac0 0>, <&usb_dmac0 1>,
 		       <&usb_dmac1 0>, <&usb_dmac1 1>;
@@ -783,7 +783,7 @@
 	vin0: video at e6ef0000 {
 		compatible = "renesas,vin-r8a7790";
 		reg = <0 0xe6ef0000 0 0x1000>;
-		interrupts = <0 188 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_VIN0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -792,7 +792,7 @@
 	vin1: video at e6ef1000 {
 		compatible = "renesas,vin-r8a7790";
 		reg = <0 0xe6ef1000 0 0x1000>;
-		interrupts = <0 189 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_VIN1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -801,7 +801,7 @@
 	vin2: video at e6ef2000 {
 		compatible = "renesas,vin-r8a7790";
 		reg = <0 0xe6ef2000 0 0x1000>;
-		interrupts = <0 190 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_VIN2>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -810,7 +810,7 @@
 	vin3: video at e6ef3000 {
 		compatible = "renesas,vin-r8a7790";
 		reg = <0 0xe6ef3000 0 0x1000>;
-		interrupts = <0 191 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_VIN3>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -819,7 +819,7 @@
 	vsp1 at fe920000 {
 		compatible = "renesas,vsp1";
 		reg = <0 0xfe920000 0 0x8000>;
-		interrupts = <0 266 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7790_CLK_VSP1_R>;
 		power-domains = <&cpg_clocks>;
 
@@ -832,7 +832,7 @@
 	vsp1 at fe928000 {
 		compatible = "renesas,vsp1";
 		reg = <0 0xfe928000 0 0x8000>;
-		interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7790_CLK_VSP1_S>;
 		power-domains = <&cpg_clocks>;
 
@@ -846,7 +846,7 @@
 	vsp1 at fe930000 {
 		compatible = "renesas,vsp1";
 		reg = <0 0xfe930000 0 0x8000>;
-		interrupts = <0 246 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7790_CLK_VSP1_DU0>;
 		power-domains = <&cpg_clocks>;
 
@@ -860,7 +860,7 @@
 	vsp1 at fe938000 {
 		compatible = "renesas,vsp1";
 		reg = <0 0xfe938000 0 0x8000>;
-		interrupts = <0 247 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7790_CLK_VSP1_DU1>;
 		power-domains = <&cpg_clocks>;
 
@@ -877,9 +877,9 @@
 		      <0 0xfeb90000 0 0x1c>,
 		      <0 0xfeb94000 0 0x1c>;
 		reg-names = "du", "lvds.0", "lvds.1";
-		interrupts = <0 256 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 268 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 269 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_DU0>,
 			 <&mstp7_clks R8A7790_CLK_DU1>,
 			 <&mstp7_clks R8A7790_CLK_DU2>,
@@ -913,7 +913,7 @@
 	can0: can at e6e80000 {
 		compatible = "renesas,can-r8a7790";
 		reg = <0 0xe6e80000 0 0x1000>;
-		interrupts = <0 186 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_RCAN0>,
 			 <&cpg_clocks R8A7790_CLK_RCAN>, <&can_clk>;
 		clock-names = "clkp1", "clkp2", "can_clk";
@@ -924,7 +924,7 @@
 	can1: can at e6e88000 {
 		compatible = "renesas,can-r8a7790";
 		reg = <0 0xe6e88000 0 0x1000>;
-		interrupts = <0 187 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_RCAN1>,
 			 <&cpg_clocks R8A7790_CLK_RCAN>, <&can_clk>;
 		clock-names = "clkp1", "clkp2", "can_clk";
@@ -935,7 +935,7 @@
 	jpu: jpeg-codec at fe980000 {
 		compatible = "renesas,jpu-r8a7790";
 		reg = <0 0xfe980000 0 0x10300>;
-		interrupts = <0 272 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7790_CLK_JPU>;
 		power-domains = <&cpg_clocks>;
 	};
@@ -1401,7 +1401,7 @@
 	qspi: spi at e6b10000 {
 		compatible = "renesas,qspi-r8a7790", "renesas,qspi";
 		reg = <0 0xe6b10000 0 0x2c>;
-		interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_QSPI_MOD>;
 		dmas = <&dmac0 0x17>, <&dmac0 0x18>;
 		dma-names = "tx", "rx";
@@ -1415,7 +1415,7 @@
 	msiof0: spi at e6e20000 {
 		compatible = "renesas,msiof-r8a7790";
 		reg = <0 0xe6e20000 0 0x0064>;
-		interrupts = <0 156 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7790_CLK_MSIOF0>;
 		dmas = <&dmac0 0x51>, <&dmac0 0x52>;
 		dma-names = "tx", "rx";
@@ -1428,7 +1428,7 @@
 	msiof1: spi at e6e10000 {
 		compatible = "renesas,msiof-r8a7790";
 		reg = <0 0xe6e10000 0 0x0064>;
-		interrupts = <0 157 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_MSIOF1>;
 		dmas = <&dmac0 0x55>, <&dmac0 0x56>;
 		dma-names = "tx", "rx";
@@ -1441,7 +1441,7 @@
 	msiof2: spi at e6e00000 {
 		compatible = "renesas,msiof-r8a7790";
 		reg = <0 0xe6e00000 0 0x0064>;
-		interrupts = <0 158 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_MSIOF2>;
 		dmas = <&dmac0 0x41>, <&dmac0 0x42>;
 		dma-names = "tx", "rx";
@@ -1454,7 +1454,7 @@
 	msiof3: spi at e6c90000 {
 		compatible = "renesas,msiof-r8a7790";
 		reg = <0 0xe6c90000 0 0x0064>;
-		interrupts = <0 159 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_MSIOF3>;
 		dmas = <&dmac0 0x45>, <&dmac0 0x46>;
 		dma-names = "tx", "rx";
@@ -1467,7 +1467,7 @@
 	xhci: usb at ee000000 {
 		compatible = "renesas,xhci-r8a7790";
 		reg = <0 0xee000000 0 0xc00>;
-		interrupts = <0 101 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_SSUSB>;
 		power-domains = <&cpg_clocks>;
 		phys = <&usb2 1>;
@@ -1480,7 +1480,7 @@
 		device_type = "pci";
 		reg = <0 0xee090000 0 0xc00>,
 		      <0 0xee080000 0 0x1100>;
-		interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_EHCI>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -1491,9 +1491,9 @@
 		#interrupt-cells = <1>;
 		ranges = <0x02000000 0 0xee080000 0 0xee080000 0 0x00010000>;
 		interrupt-map-mask = <0xff00 0 0 0x7>;
-		interrupt-map = <0x0000 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
-				 0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
-				 0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH
+				 0x0800 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH
+				 0x1000 0 0 2 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 
 		usb at 0,1 {
 			reg = <0x800 0 0 0 0>;
@@ -1515,7 +1515,7 @@
 		device_type = "pci";
 		reg = <0 0xee0b0000 0 0xc00>,
 		      <0 0xee0a0000 0 0x1100>;
-		interrupts = <0 112 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_EHCI>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -1526,9 +1526,9 @@
 		#interrupt-cells = <1>;
 		ranges = <0x02000000 0 0xee0a0000 0 0xee0a0000 0 0x00010000>;
 		interrupt-map-mask = <0xff00 0 0 0x7>;
-		interrupt-map = <0x0000 0 0 1 &gic 0 112 IRQ_TYPE_LEVEL_HIGH
-				 0x0800 0 0 1 &gic 0 112 IRQ_TYPE_LEVEL_HIGH
-				 0x1000 0 0 2 &gic 0 112 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH
+				 0x0800 0 0 1 &gic GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH
+				 0x1000 0 0 2 &gic GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
 	};
 
 	pci2: pci at ee0d0000 {
@@ -1538,7 +1538,7 @@
 		power-domains = <&cpg_clocks>;
 		reg = <0 0xee0d0000 0 0xc00>,
 		      <0 0xee0c0000 0 0x1100>;
-		interrupts = <0 113 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
 		status = "disabled";
 
 		bus-range = <2 2>;
@@ -1547,9 +1547,9 @@
 		#interrupt-cells = <1>;
 		ranges = <0x02000000 0 0xee0c0000 0 0xee0c0000 0 0x00010000>;
 		interrupt-map-mask = <0xff00 0 0 0x7>;
-		interrupt-map = <0x0000 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
-				 0x0800 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
-				 0x1000 0 0 2 &gic 0 113 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
+				 0x0800 0 0 1 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
+				 0x1000 0 0 2 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
 
 		usb at 0,1 {
 			reg = <0x800 0 0 0 0>;
@@ -1580,12 +1580,12 @@
 		/* Map all possible DDR as inbound ranges */
 		dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000
 			      0x43000000 1 0x80000000 1 0x80000000 0 0x80000000>;
-		interrupts = <0 116 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 117 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 118 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
 		#interrupt-cells = <1>;
 		interrupt-map-mask = <0 0 0 0>;
-		interrupt-map = <0 0 0 0 &gic 0 116 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0 0 0 0 &gic GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_PCIEC>, <&pcie_bus_clk>;
 		clock-names = "pcie", "pcie_bus";
 		power-domains = <&cpg_clocks>;
@@ -1664,52 +1664,52 @@
 
 		rcar_sound,src {
 			src0: src at 0 {
-				interrupts = <0 352 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x85>, <&audma1 0x9a>;
 				dma-names = "rx", "tx";
 			};
 			src1: src at 1 {
-				interrupts = <0 353 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x87>, <&audma1 0x9c>;
 				dma-names = "rx", "tx";
 			};
 			src2: src at 2 {
-				interrupts = <0 354 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x89>, <&audma1 0x9e>;
 				dma-names = "rx", "tx";
 			};
 			src3: src at 3 {
-				interrupts = <0 355 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x8b>, <&audma1 0xa0>;
 				dma-names = "rx", "tx";
 			};
 			src4: src at 4 {
-				interrupts = <0 356 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x8d>, <&audma1 0xb0>;
 				dma-names = "rx", "tx";
 			};
 			src5: src at 5 {
-				interrupts = <0 357 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x8f>, <&audma1 0xb2>;
 				dma-names = "rx", "tx";
 			};
 			src6: src at 6 {
-				interrupts = <0 358 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x91>, <&audma1 0xb4>;
 				dma-names = "rx", "tx";
 			};
 			src7: src at 7 {
-				interrupts = <0 359 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x93>, <&audma1 0xb6>;
 				dma-names = "rx", "tx";
 			};
 			src8: src at 8 {
-				interrupts = <0 360 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x95>, <&audma1 0xb8>;
 				dma-names = "rx", "tx";
 			};
 			src9: src at 9 {
-				interrupts = <0 361 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x97>, <&audma1 0xba>;
 				dma-names = "rx", "tx";
 			};
@@ -1717,52 +1717,52 @@
 
 		rcar_sound,ssi {
 			ssi0: ssi at 0 {
-				interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x01>, <&audma1 0x02>, <&audma0 0x15>, <&audma1 0x16>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi1: ssi at 1 {
-				 interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>;
+				 interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x03>, <&audma1 0x04>, <&audma0 0x49>, <&audma1 0x4a>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi2: ssi at 2 {
-				interrupts = <0 372 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x05>, <&audma1 0x06>, <&audma0 0x63>, <&audma1 0x64>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi3: ssi at 3 {
-				interrupts = <0 373 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x07>, <&audma1 0x08>, <&audma0 0x6f>, <&audma1 0x70>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi4: ssi at 4 {
-				interrupts = <0 374 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x09>, <&audma1 0x0a>, <&audma0 0x71>, <&audma1 0x72>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi5: ssi at 5 {
-				interrupts = <0 375 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x0b>, <&audma1 0x0c>, <&audma0 0x73>, <&audma1 0x74>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi6: ssi at 6 {
-				interrupts = <0 376 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x0d>, <&audma1 0x0e>, <&audma0 0x75>, <&audma1 0x76>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi7: ssi at 7 {
-				interrupts = <0 377 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x0f>, <&audma1 0x10>, <&audma0 0x79>, <&audma1 0x7a>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi8: ssi at 8 {
-				interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x11>, <&audma1 0x12>, <&audma0 0x7b>, <&audma1 0x7c>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi9: ssi at 9 {
-				interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x13>, <&audma1 0x14>, <&audma0 0x7d>, <&audma1 0x7e>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
@@ -1772,8 +1772,8 @@
 	ipmmu_sy0: mmu at e6280000 {
 		compatible = "renesas,ipmmu-r8a7790", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6280000 0 0x1000>;
-		interrupts = <0 223 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 224 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1781,7 +1781,7 @@
 	ipmmu_sy1: mmu at e6290000 {
 		compatible = "renesas,ipmmu-r8a7790", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6290000 0 0x1000>;
-		interrupts = <0 225 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1789,8 +1789,8 @@
 	ipmmu_ds: mmu at e6740000 {
 		compatible = "renesas,ipmmu-r8a7790", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6740000 0 0x1000>;
-		interrupts = <0 198 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 199 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1798,7 +1798,7 @@
 	ipmmu_mp: mmu at ec680000 {
 		compatible = "renesas,ipmmu-r8a7790", "renesas,ipmmu-vmsa";
 		reg = <0 0xec680000 0 0x1000>;
-		interrupts = <0 226 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1806,8 +1806,8 @@
 	ipmmu_mx: mmu at fe951000 {
 		compatible = "renesas,ipmmu-r8a7790", "renesas,ipmmu-vmsa";
 		reg = <0 0xfe951000 0 0x1000>;
-		interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 221 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1815,7 +1815,7 @@
 	ipmmu_rt: mmu at ffc80000 {
 		compatible = "renesas,ipmmu-r8a7790", "renesas,ipmmu-vmsa";
 		reg = <0 0xffc80000 0 0x1000>;
-		interrupts = <0 307 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:06 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:06 +0100
Subject: [PATCH 12/70] ARM: dts: r8a7791: use GIC_* defines
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <386a9291134b55493b2af2bc1317eeeb05f8a49a.1454595846.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7791 device tree.

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791.dtsi | 386 ++++++++++++++++++++---------------------
 1 file changed, 193 insertions(+), 193 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 829224d2a3ed..6b3b02c0c58a 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -78,13 +78,13 @@
 			<0 0xf1002000 0 0x1000>,
 			<0 0xf1004000 0 0x2000>,
 			<0 0xf1006000 0 0x2000>;
-		interrupts = <1 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
 	};
 
 	gpio0: gpio at e6050000 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6050000 0 0x50>;
-		interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 0 32>;
@@ -97,7 +97,7 @@
 	gpio1: gpio at e6051000 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6051000 0 0x50>;
-		interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 32 26>;
@@ -110,7 +110,7 @@
 	gpio2: gpio at e6052000 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6052000 0 0x50>;
-		interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 64 32>;
@@ -123,7 +123,7 @@
 	gpio3: gpio at e6053000 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6053000 0 0x50>;
-		interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 96 32>;
@@ -136,7 +136,7 @@
 	gpio4: gpio at e6054000 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6054000 0 0x50>;
-		interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 128 32>;
@@ -149,7 +149,7 @@
 	gpio5: gpio at e6055000 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6055000 0 0x50>;
-		interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 160 32>;
@@ -162,7 +162,7 @@
 	gpio6: gpio at e6055400 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6055400 0 0x50>;
-		interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 192 32>;
@@ -175,7 +175,7 @@
 	gpio7: gpio at e6055800 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6055800 0 0x50>;
-		interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 224 26>;
@@ -188,24 +188,24 @@
 	thermal at e61f0000 {
 		compatible = "renesas,thermal-r8a7791", "renesas,rcar-thermal";
 		reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
-		interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks R8A7791_CLK_THERMAL>;
 		power-domains = <&cpg_clocks>;
 	};
 
 	timer {
 		compatible = "arm,armv7-timer";
-		interrupts = <1 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
 	};
 
 	cmt0: timer at ffca0000 {
 		compatible = "renesas,cmt-48-r8a7791", "renesas,cmt-48-gen2";
 		reg = <0 0xffca0000 0 0x1004>;
-		interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 143 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7791_CLK_CMT0>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -218,14 +218,14 @@
 	cmt1: timer at e6130000 {
 		compatible = "renesas,cmt-48-r8a7791", "renesas,cmt-48-gen2";
 		reg = <0 0xe6130000 0 0x1004>;
-		interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 121 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 122 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 123 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 124 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 125 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 126 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 127 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_CMT1>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -240,16 +240,16 @@
 		#interrupt-cells = <2>;
 		interrupt-controller;
 		reg = <0 0xe61c0000 0 0x200>;
-		interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 1 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 2 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 3 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 12 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 13 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 14 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 15 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 16 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 17 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A7791_CLK_IRQC>;
 		power-domains = <&cpg_clocks>;
 	};
@@ -257,22 +257,22 @@
 	dmac0: dma-controller at e6700000 {
 		compatible = "renesas,dmac-r8a7791", "renesas,rcar-dmac";
 		reg = <0 0xe6700000 0 0x20000>;
-		interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH
-			      0 200 IRQ_TYPE_LEVEL_HIGH
-			      0 201 IRQ_TYPE_LEVEL_HIGH
-			      0 202 IRQ_TYPE_LEVEL_HIGH
-			      0 203 IRQ_TYPE_LEVEL_HIGH
-			      0 204 IRQ_TYPE_LEVEL_HIGH
-			      0 205 IRQ_TYPE_LEVEL_HIGH
-			      0 206 IRQ_TYPE_LEVEL_HIGH
-			      0 207 IRQ_TYPE_LEVEL_HIGH
-			      0 208 IRQ_TYPE_LEVEL_HIGH
-			      0 209 IRQ_TYPE_LEVEL_HIGH
-			      0 210 IRQ_TYPE_LEVEL_HIGH
-			      0 211 IRQ_TYPE_LEVEL_HIGH
-			      0 212 IRQ_TYPE_LEVEL_HIGH
-			      0 213 IRQ_TYPE_LEVEL_HIGH
-			      0 214 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -288,22 +288,22 @@
 	dmac1: dma-controller at e6720000 {
 		compatible = "renesas,dmac-r8a7791", "renesas,rcar-dmac";
 		reg = <0 0xe6720000 0 0x20000>;
-		interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
-			      0 216 IRQ_TYPE_LEVEL_HIGH
-			      0 217 IRQ_TYPE_LEVEL_HIGH
-			      0 218 IRQ_TYPE_LEVEL_HIGH
-			      0 219 IRQ_TYPE_LEVEL_HIGH
-			      0 308 IRQ_TYPE_LEVEL_HIGH
-			      0 309 IRQ_TYPE_LEVEL_HIGH
-			      0 310 IRQ_TYPE_LEVEL_HIGH
-			      0 311 IRQ_TYPE_LEVEL_HIGH
-			      0 312 IRQ_TYPE_LEVEL_HIGH
-			      0 313 IRQ_TYPE_LEVEL_HIGH
-			      0 314 IRQ_TYPE_LEVEL_HIGH
-			      0 315 IRQ_TYPE_LEVEL_HIGH
-			      0 316 IRQ_TYPE_LEVEL_HIGH
-			      0 317 IRQ_TYPE_LEVEL_HIGH
-			      0 318 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -319,20 +319,20 @@
 	audma0: dma-controller at ec700000 {
 		compatible = "renesas,dmac-r8a7791", "renesas,rcar-dmac";
 		reg = <0 0xec700000 0 0x10000>;
-		interrupts =	<0 346 IRQ_TYPE_LEVEL_HIGH
-				 0 320 IRQ_TYPE_LEVEL_HIGH
-				 0 321 IRQ_TYPE_LEVEL_HIGH
-				 0 322 IRQ_TYPE_LEVEL_HIGH
-				 0 323 IRQ_TYPE_LEVEL_HIGH
-				 0 324 IRQ_TYPE_LEVEL_HIGH
-				 0 325 IRQ_TYPE_LEVEL_HIGH
-				 0 326 IRQ_TYPE_LEVEL_HIGH
-				 0 327 IRQ_TYPE_LEVEL_HIGH
-				 0 328 IRQ_TYPE_LEVEL_HIGH
-				 0 329 IRQ_TYPE_LEVEL_HIGH
-				 0 330 IRQ_TYPE_LEVEL_HIGH
-				 0 331 IRQ_TYPE_LEVEL_HIGH
-				 0 332 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts =	<GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -348,20 +348,20 @@
 	audma1: dma-controller at ec720000 {
 		compatible = "renesas,dmac-r8a7791", "renesas,rcar-dmac";
 		reg = <0 0xec720000 0 0x10000>;
-		interrupts =	<0 347 IRQ_TYPE_LEVEL_HIGH
-				 0 333 IRQ_TYPE_LEVEL_HIGH
-				 0 334 IRQ_TYPE_LEVEL_HIGH
-				 0 335 IRQ_TYPE_LEVEL_HIGH
-				 0 336 IRQ_TYPE_LEVEL_HIGH
-				 0 337 IRQ_TYPE_LEVEL_HIGH
-				 0 338 IRQ_TYPE_LEVEL_HIGH
-				 0 339 IRQ_TYPE_LEVEL_HIGH
-				 0 340 IRQ_TYPE_LEVEL_HIGH
-				 0 341 IRQ_TYPE_LEVEL_HIGH
-				 0 342 IRQ_TYPE_LEVEL_HIGH
-				 0 343 IRQ_TYPE_LEVEL_HIGH
-				 0 344 IRQ_TYPE_LEVEL_HIGH
-				 0 345 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts =	<GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -377,8 +377,8 @@
 	usb_dmac0: dma-controller at e65a0000 {
 		compatible = "renesas,r8a7791-usb-dmac", "renesas,usb-dmac";
 		reg = <0 0xe65a0000 0 0x100>;
-		interrupts = <0 109 IRQ_TYPE_LEVEL_HIGH
-			      0 109 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "ch0", "ch1";
 		clocks = <&mstp3_clks R8A7791_CLK_USBDMAC0>;
 		power-domains = <&cpg_clocks>;
@@ -389,8 +389,8 @@
 	usb_dmac1: dma-controller at e65b0000 {
 		compatible = "renesas,r8a7791-usb-dmac", "renesas,usb-dmac";
 		reg = <0 0xe65b0000 0 0x100>;
-		interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH
-			      0 110 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "ch0", "ch1";
 		clocks = <&mstp3_clks R8A7791_CLK_USBDMAC1>;
 		power-domains = <&cpg_clocks>;
@@ -404,7 +404,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7791";
 		reg = <0 0xe6508000 0 0x40>;
-		interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -416,7 +416,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7791";
 		reg = <0 0xe6518000 0 0x40>;
-		interrupts = <0 288 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_I2C1>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -428,7 +428,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7791";
 		reg = <0 0xe6530000 0 0x40>;
-		interrupts = <0 286 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_I2C2>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -440,7 +440,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7791";
 		reg = <0 0xe6540000 0 0x40>;
-		interrupts = <0 290 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_I2C3>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -452,7 +452,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7791";
 		reg = <0 0xe6520000 0 0x40>;
-		interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_I2C4>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -465,7 +465,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7791";
 		reg = <0 0xe6528000 0 0x40>;
-		interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_I2C5>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <110>;
@@ -478,7 +478,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7791", "renesas,rmobile-iic";
 		reg = <0 0xe60b0000 0 0x425>;
-		interrupts = <0 173 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_IICDVFS>;
 		dmas = <&dmac0 0x77>, <&dmac0 0x78>;
 		dma-names = "tx", "rx";
@@ -491,7 +491,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7791", "renesas,rmobile-iic";
 		reg = <0 0xe6500000 0 0x425>;
-		interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_IIC0>;
 		dmas = <&dmac0 0x61>, <&dmac0 0x62>;
 		dma-names = "tx", "rx";
@@ -504,7 +504,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7791", "renesas,rmobile-iic";
 		reg = <0 0xe6510000 0 0x425>;
-		interrupts = <0 175 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_IIC1>;
 		dmas = <&dmac0 0x65>, <&dmac0 0x66>;
 		dma-names = "tx", "rx";
@@ -520,7 +520,7 @@
 	mmcif0: mmc at ee200000 {
 		compatible = "renesas,mmcif-r8a7791", "renesas,sh-mmcif";
 		reg = <0 0xee200000 0 0x80>;
-		interrupts = <0 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_MMCIF0>;
 		dmas = <&dmac0 0xd1>, <&dmac0 0xd2>;
 		dma-names = "tx", "rx";
@@ -533,7 +533,7 @@
 	sdhi0: sd at ee100000 {
 		compatible = "renesas,sdhi-r8a7791";
 		reg = <0 0xee100000 0 0x328>;
-		interrupts = <0 165 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_SDHI0>;
 		dmas = <&dmac1 0xcd>, <&dmac1 0xce>;
 		dma-names = "tx", "rx";
@@ -544,7 +544,7 @@
 	sdhi1: sd at ee140000 {
 		compatible = "renesas,sdhi-r8a7791";
 		reg = <0 0xee140000 0 0x100>;
-		interrupts = <0 167 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_SDHI1>;
 		dmas = <&dmac1 0xc1>, <&dmac1 0xc2>;
 		dma-names = "tx", "rx";
@@ -555,7 +555,7 @@
 	sdhi2: sd at ee160000 {
 		compatible = "renesas,sdhi-r8a7791";
 		reg = <0 0xee160000 0 0x100>;
-		interrupts = <0 168 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_SDHI2>;
 		dmas = <&dmac1 0xd3>, <&dmac1 0xd4>;
 		dma-names = "tx", "rx";
@@ -566,7 +566,7 @@
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
-		interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
@@ -578,7 +578,7 @@
 	scifa1: serial at e6c50000 {
 		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
-		interrupts = <0 145 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
@@ -590,7 +590,7 @@
 	scifa2: serial at e6c60000 {
 		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
-		interrupts = <0 151 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
@@ -602,7 +602,7 @@
 	scifa3: serial at e6c70000 {
 		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
 		reg = <0 0xe6c70000 0 64>;
-		interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA3>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1b>, <&dmac0 0x1c>;
@@ -614,7 +614,7 @@
 	scifa4: serial at e6c78000 {
 		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
 		reg = <0 0xe6c78000 0 64>;
-		interrupts = <0 30 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA4>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1f>, <&dmac0 0x20>;
@@ -626,7 +626,7 @@
 	scifa5: serial at e6c80000 {
 		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
 		reg = <0 0xe6c80000 0 64>;
-		interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA5>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x23>, <&dmac0 0x24>;
@@ -638,7 +638,7 @@
 	scifb0: serial at e6c20000 {
 		compatible = "renesas,scifb-r8a7791", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
-		interrupts = <0 148 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
@@ -650,7 +650,7 @@
 	scifb1: serial at e6c30000 {
 		compatible = "renesas,scifb-r8a7791", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
@@ -662,7 +662,7 @@
 	scifb2: serial at e6ce0000 {
 		compatible = "renesas,scifb-r8a7791", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
-		interrupts = <0 150 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
@@ -674,7 +674,7 @@
 	scif0: serial at e6e60000 {
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
-		interrupts = <0 152 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
@@ -686,7 +686,7 @@
 	scif1: serial at e6e68000 {
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
-		interrupts = <0 153 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
@@ -698,7 +698,7 @@
 	scif2: serial at e6e58000 {
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
-		interrupts = <0 22 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
@@ -710,7 +710,7 @@
 	scif3: serial at e6ea8000 {
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
-		interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF3>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
@@ -722,7 +722,7 @@
 	scif4: serial at e6ee0000 {
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
-		interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF4>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
@@ -734,7 +734,7 @@
 	scif5: serial at e6ee8000 {
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
-		interrupts = <0 25 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF5>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
@@ -746,7 +746,7 @@
 	hscif0: serial at e62c0000 {
 		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
-		interrupts = <0 154 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
@@ -758,7 +758,7 @@
 	hscif1: serial at e62c8000 {
 		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
-		interrupts = <0 155 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
@@ -770,7 +770,7 @@
 	hscif2: serial at e62d0000 {
 		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
-		interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
@@ -782,7 +782,7 @@
 	ether: ethernet at ee700000 {
 		compatible = "renesas,ether-r8a7791";
 		reg = <0 0xee700000 0 0x400>;
-		interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7791_CLK_ETHER>;
 		power-domains = <&cpg_clocks>;
 		phy-mode = "rmii";
@@ -795,7 +795,7 @@
 		compatible = "renesas,etheravb-r8a7791",
 			     "renesas,etheravb-rcar-gen2";
 		reg = <0 0xe6800000 0 0x800>, <0 0xee0e8000 0 0x4000>;
-		interrupts = <0 163 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7791_CLK_ETHERAVB>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -806,7 +806,7 @@
 	sata0: sata at ee300000 {
 		compatible = "renesas,sata-r8a7791";
 		reg = <0 0xee300000 0 0x2000>;
-		interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7791_CLK_SATA0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -815,7 +815,7 @@
 	sata1: sata at ee500000 {
 		compatible = "renesas,sata-r8a7791";
 		reg = <0 0xee500000 0 0x2000>;
-		interrupts = <0 106 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7791_CLK_SATA1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -824,7 +824,7 @@
 	hsusb: usb at e6590000 {
 		compatible = "renesas,usbhs-r8a7791", "renesas,rcar-gen2-usbhs";
 		reg = <0 0xe6590000 0 0x100>;
-		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSUSB>;
 		dmas = <&usb_dmac0 0>, <&usb_dmac0 1>,
 		       <&usb_dmac1 0>, <&usb_dmac1 1>;
@@ -859,7 +859,7 @@
 	vin0: video at e6ef0000 {
 		compatible = "renesas,vin-r8a7791";
 		reg = <0 0xe6ef0000 0 0x1000>;
-		interrupts = <0 188 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7791_CLK_VIN0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -868,7 +868,7 @@
 	vin1: video at e6ef1000 {
 		compatible = "renesas,vin-r8a7791";
 		reg = <0 0xe6ef1000 0 0x1000>;
-		interrupts = <0 189 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7791_CLK_VIN1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -877,7 +877,7 @@
 	vin2: video at e6ef2000 {
 		compatible = "renesas,vin-r8a7791";
 		reg = <0 0xe6ef2000 0 0x1000>;
-		interrupts = <0 190 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7791_CLK_VIN2>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -886,7 +886,7 @@
 	vsp1 at fe928000 {
 		compatible = "renesas,vsp1";
 		reg = <0 0xfe928000 0 0x8000>;
-		interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7791_CLK_VSP1_S>;
 		power-domains = <&cpg_clocks>;
 
@@ -900,7 +900,7 @@
 	vsp1 at fe930000 {
 		compatible = "renesas,vsp1";
 		reg = <0 0xfe930000 0 0x8000>;
-		interrupts = <0 246 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7791_CLK_VSP1_DU0>;
 		power-domains = <&cpg_clocks>;
 
@@ -914,7 +914,7 @@
 	vsp1 at fe938000 {
 		compatible = "renesas,vsp1";
 		reg = <0 0xfe938000 0 0x8000>;
-		interrupts = <0 247 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7791_CLK_VSP1_DU1>;
 		power-domains = <&cpg_clocks>;
 
@@ -930,8 +930,8 @@
 		reg = <0 0xfeb00000 0 0x40000>,
 		      <0 0xfeb90000 0 0x1c>;
 		reg-names = "du", "lvds.0";
-		interrupts = <0 256 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 268 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_DU0>,
 			 <&mstp7_clks R8A7791_CLK_DU1>,
 			 <&mstp7_clks R8A7791_CLK_LVDS0>;
@@ -958,7 +958,7 @@
 	can0: can at e6e80000 {
 		compatible = "renesas,can-r8a7791";
 		reg = <0 0xe6e80000 0 0x1000>;
-		interrupts = <0 186 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_RCAN0>,
 			 <&cpg_clocks R8A7791_CLK_RCAN>, <&can_clk>;
 		clock-names = "clkp1", "clkp2", "can_clk";
@@ -969,7 +969,7 @@
 	can1: can at e6e88000 {
 		compatible = "renesas,can-r8a7791";
 		reg = <0 0xe6e88000 0 0x1000>;
-		interrupts = <0 187 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_RCAN1>,
 			 <&cpg_clocks R8A7791_CLK_RCAN>, <&can_clk>;
 		clock-names = "clkp1", "clkp2", "can_clk";
@@ -980,7 +980,7 @@
 	jpu: jpeg-codec at fe980000 {
 		compatible = "renesas,jpu-r8a7791";
 		reg = <0 0xfe980000 0 0x10300>;
-		interrupts = <0 272 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7791_CLK_JPU>;
 		power-domains = <&cpg_clocks>;
 	};
@@ -1432,7 +1432,7 @@
 	qspi: spi at e6b10000 {
 		compatible = "renesas,qspi-r8a7791", "renesas,qspi";
 		reg = <0 0xe6b10000 0 0x2c>;
-		interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_QSPI_MOD>;
 		dmas = <&dmac0 0x17>, <&dmac0 0x18>;
 		dma-names = "tx", "rx";
@@ -1446,7 +1446,7 @@
 	msiof0: spi at e6e20000 {
 		compatible = "renesas,msiof-r8a7791";
 		reg = <0 0xe6e20000 0 0x0064>;
-		interrupts = <0 156 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7791_CLK_MSIOF0>;
 		dmas = <&dmac0 0x51>, <&dmac0 0x52>;
 		dma-names = "tx", "rx";
@@ -1459,7 +1459,7 @@
 	msiof1: spi at e6e10000 {
 		compatible = "renesas,msiof-r8a7791";
 		reg = <0 0xe6e10000 0 0x0064>;
-		interrupts = <0 157 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_MSIOF1>;
 		dmas = <&dmac0 0x55>, <&dmac0 0x56>;
 		dma-names = "tx", "rx";
@@ -1472,7 +1472,7 @@
 	msiof2: spi at e6e00000 {
 		compatible = "renesas,msiof-r8a7791";
 		reg = <0 0xe6e00000 0 0x0064>;
-		interrupts = <0 158 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_MSIOF2>;
 		dmas = <&dmac0 0x41>, <&dmac0 0x42>;
 		dma-names = "tx", "rx";
@@ -1485,7 +1485,7 @@
 	xhci: usb at ee000000 {
 		compatible = "renesas,xhci-r8a7791";
 		reg = <0 0xee000000 0 0xc00>;
-		interrupts = <0 101 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_SSUSB>;
 		power-domains = <&cpg_clocks>;
 		phys = <&usb2 1>;
@@ -1498,7 +1498,7 @@
 		device_type = "pci";
 		reg = <0 0xee090000 0 0xc00>,
 		      <0 0xee080000 0 0x1100>;
-		interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_EHCI>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -1509,9 +1509,9 @@
 		#interrupt-cells = <1>;
 		ranges = <0x02000000 0 0xee080000 0 0xee080000 0 0x00010000>;
 		interrupt-map-mask = <0xff00 0 0 0x7>;
-		interrupt-map = <0x0000 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
-				 0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
-				 0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH
+				 0x0800 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH
+				 0x1000 0 0 2 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 
 		usb at 0,1 {
 			reg = <0x800 0 0 0 0>;
@@ -1533,7 +1533,7 @@
 		device_type = "pci";
 		reg = <0 0xee0d0000 0 0xc00>,
 		      <0 0xee0c0000 0 0x1100>;
-		interrupts = <0 113 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_EHCI>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -1544,9 +1544,9 @@
 		#interrupt-cells = <1>;
 		ranges = <0x02000000 0 0xee0c0000 0 0xee0c0000 0 0x00010000>;
 		interrupt-map-mask = <0xff00 0 0 0x7>;
-		interrupt-map = <0x0000 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
-				 0x0800 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
-				 0x1000 0 0 2 &gic 0 113 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
+				 0x0800 0 0 1 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
+				 0x1000 0 0 2 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
 
 		usb at 0,1 {
 			reg = <0x800 0 0 0 0>;
@@ -1577,12 +1577,12 @@
 		/* Map all possible DDR as inbound ranges */
 		dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000
 			      0x43000000 2 0x00000000 2 0x00000000 1 0x00000000>;
-		interrupts = <0 116 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 117 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 118 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
 		#interrupt-cells = <1>;
 		interrupt-map-mask = <0 0 0 0>;
-		interrupt-map = <0 0 0 0 &gic 0 116 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0 0 0 0 &gic GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_PCIEC>, <&pcie_bus_clk>;
 		clock-names = "pcie", "pcie_bus";
 		power-domains = <&cpg_clocks>;
@@ -1592,8 +1592,8 @@
 	ipmmu_sy0: mmu at e6280000 {
 		compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6280000 0 0x1000>;
-		interrupts = <0 223 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 224 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1601,7 +1601,7 @@
 	ipmmu_sy1: mmu at e6290000 {
 		compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6290000 0 0x1000>;
-		interrupts = <0 225 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1609,8 +1609,8 @@
 	ipmmu_ds: mmu at e6740000 {
 		compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6740000 0 0x1000>;
-		interrupts = <0 198 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 199 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1618,7 +1618,7 @@
 	ipmmu_mp: mmu at ec680000 {
 		compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";
 		reg = <0 0xec680000 0 0x1000>;
-		interrupts = <0 226 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1626,8 +1626,8 @@
 	ipmmu_mx: mmu at fe951000 {
 		compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";
 		reg = <0 0xfe951000 0 0x1000>;
-		interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 221 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1635,7 +1635,7 @@
 	ipmmu_rt: mmu at ffc80000 {
 		compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";
 		reg = <0 0xffc80000 0 0x1000>;
-		interrupts = <0 307 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1643,8 +1643,8 @@
 	ipmmu_gp: mmu at e62a0000 {
 		compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";
 		reg = <0 0xe62a0000 0 0x1000>;
-		interrupts = <0 260 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 261 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 261 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1721,52 +1721,52 @@
 
 		rcar_sound,src {
 			src0: src at 0 {
-				interrupts = <0 352 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x85>, <&audma1 0x9a>;
 				dma-names = "rx", "tx";
 			};
 			src1: src at 1 {
-				interrupts = <0 353 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x87>, <&audma1 0x9c>;
 				dma-names = "rx", "tx";
 			};
 			src2: src at 2 {
-				interrupts = <0 354 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x89>, <&audma1 0x9e>;
 				dma-names = "rx", "tx";
 			};
 			src3: src at 3 {
-				interrupts = <0 355 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x8b>, <&audma1 0xa0>;
 				dma-names = "rx", "tx";
 			};
 			src4: src at 4 {
-				interrupts = <0 356 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x8d>, <&audma1 0xb0>;
 				dma-names = "rx", "tx";
 			};
 			src5: src at 5 {
-				interrupts = <0 357 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x8f>, <&audma1 0xb2>;
 				dma-names = "rx", "tx";
 			};
 			src6: src at 6 {
-				interrupts = <0 358 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x91>, <&audma1 0xb4>;
 				dma-names = "rx", "tx";
 			};
 			src7: src at 7 {
-				interrupts = <0 359 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x93>, <&audma1 0xb6>;
 				dma-names = "rx", "tx";
 			};
 			src8: src at 8 {
-				interrupts = <0 360 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x95>, <&audma1 0xb8>;
 				dma-names = "rx", "tx";
 			};
 			src9: src at 9 {
-				interrupts = <0 361 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x97>, <&audma1 0xba>;
 				dma-names = "rx", "tx";
 			};
@@ -1774,52 +1774,52 @@
 
 		rcar_sound,ssi {
 			ssi0: ssi at 0 {
-				interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x01>, <&audma1 0x02>, <&audma0 0x15>, <&audma1 0x16>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi1: ssi at 1 {
-				 interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>;
+				 interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x03>, <&audma1 0x04>, <&audma0 0x49>, <&audma1 0x4a>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi2: ssi at 2 {
-				interrupts = <0 372 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x05>, <&audma1 0x06>, <&audma0 0x63>, <&audma1 0x64>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi3: ssi at 3 {
-				interrupts = <0 373 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x07>, <&audma1 0x08>, <&audma0 0x6f>, <&audma1 0x70>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi4: ssi at 4 {
-				interrupts = <0 374 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x09>, <&audma1 0x0a>, <&audma0 0x71>, <&audma1 0x72>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi5: ssi at 5 {
-				interrupts = <0 375 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x0b>, <&audma1 0x0c>, <&audma0 0x73>, <&audma1 0x74>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi6: ssi at 6 {
-				interrupts = <0 376 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x0d>, <&audma1 0x0e>, <&audma0 0x75>, <&audma1 0x76>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi7: ssi at 7 {
-				interrupts = <0 377 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x0f>, <&audma1 0x10>, <&audma0 0x79>, <&audma1 0x7a>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi8: ssi at 8 {
-				interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x11>, <&audma1 0x12>, <&audma0 0x7b>, <&audma1 0x7c>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi9: ssi at 9 {
-				interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x13>, <&audma1 0x14>, <&audma0 0x7d>, <&audma1 0x7e>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:10 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:10 +0100
Subject: [PATCH 16/70] ARM: dts: r8a7793: gose: Add HDMI video out support
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <8871eb07c0e77196f1f6cd2ccd659516e3e5d9aa.1454595846.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm+renesas at opensource.se>

This patch adds r8a7793 GOSE HDMI video out support.

The r8a7793 GOSE board is similar to r8a7791 Koelsch. For those
boards an on-board HDMI encoder chip provides HDMI video out
and also a LVDS port is available for external LCD panels.

Tested on r8a7793 Gose with HDMI hooked up to a Toshiba TV.

Signed-off-by: Magnus Damm <damm+renesas at opensource.se>
[simon: rebased; reused existing i2c2 node]
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 85 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 85 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 987ed03b1e02..0b4cc8d99390 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -129,6 +129,54 @@
 			label = "LED8";
 		};
 	};
+
+	hdmi-out {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_con: endpoint {
+				remote-endpoint = <&adv7511_out>;
+			};
+		};
+	};
+
+	x2_clk: x2-clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <74250000>;
+	};
+
+	x13_clk: x13-clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <148500000>;
+	};
+};
+
+&du {
+	pinctrl-0 = <&du_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	clocks = <&mstp7_clks R8A7793_CLK_DU0>,
+		 <&mstp7_clks R8A7793_CLK_DU1>,
+		 <&mstp7_clks R8A7793_CLK_LVDS0>,
+		 <&x13_clk>, <&x2_clk>;
+	clock-names = "du.0", "du.1", "lvds.0",
+		      "dclkin.0", "dclkin.1";
+
+	ports {
+		port at 0 {
+			endpoint {
+				remote-endpoint = <&adv7511_in>;
+			};
+		};
+		port at 1 {
+			lvds_connector: endpoint {
+			};
+		};
+	};
 };
 
 &extal_clk {
@@ -141,6 +189,11 @@
 		renesas,function = "i2c2";
 	};
 
+	du_pins: du {
+		renesas,groups = "du_rgb888", "du_sync", "du_disp", "du_clk_out_0";
+		renesas,function = "du";
+	};
+
 	scif0_pins: serial0 {
 		renesas,groups = "scif0_data_d";
 		renesas,function = "scif0";
@@ -247,6 +300,38 @@
 	status = "okay";
 	clock-frequency = <100000>;
 
+	hdmi at 39 {
+		compatible = "adi,adv7511w";
+		reg = <0x39>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+
+		adi,input-depth = <8>;
+		adi,input-colorspace = "rgb";
+		adi,input-clock = "1x";
+		adi,input-style = <1>;
+		adi,input-justification = "evenly";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				adv7511_in: endpoint {
+					remote-endpoint = <&du_out_rgb>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+				adv7511_out: endpoint {
+					remote-endpoint = <&hdmi_con>;
+				};
+			};
+		};
+	};
+
 	eeprom at 50 {
 		compatible = "renesas,r1ex24002", "atmel,24c02";
 		reg = <0x50>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:11 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:11 +0100
Subject: [PATCH 17/70] ARM: dts: r8a7778: use GIC_* defines
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <0c34bd1e00b0c60407ede0ca0d49862ef6116fa5.1454595846.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7778 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7778.dtsi | 87 +++++++++++++++++++++---------------------
 1 file changed, 44 insertions(+), 43 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index 791aafd310a5..fc5e7243467a 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -17,6 +17,7 @@
 /include/ "skeleton.dtsi"
 
 #include <dt-bindings/clock/r8a7778-clock.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/interrupt-controller/irq.h>
 
 / {
@@ -51,7 +52,7 @@
 	ether: ethernet at fde00000 {
 		compatible = "renesas,ether-r8a7778";
 		reg = <0xfde00000 0x400>;
-		interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7778_CLK_ETHER>;
 		power-domains = <&cpg_clocks>;
 		phy-mode = "rmii";
@@ -79,17 +80,17 @@
 			<0xfe780024 4>,
 			<0xfe780044 4>,
 			<0xfe780064 4>;
-		interrupts =   <0 27 IRQ_TYPE_LEVEL_HIGH
-				0 28 IRQ_TYPE_LEVEL_HIGH
-				0 29 IRQ_TYPE_LEVEL_HIGH
-				0 30 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts =   <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH
+				GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH
+				GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH
+				GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		sense-bitfield-width = <2>;
 	};
 
 	gpio0: gpio at ffc40000 {
 		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
 		reg = <0xffc40000 0x2c>;
-		interrupts = <0 103 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 0 32>;
@@ -100,7 +101,7 @@
 	gpio1: gpio at ffc41000 {
 		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
 		reg = <0xffc41000 0x2c>;
-		interrupts = <0 103 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 32 32>;
@@ -111,7 +112,7 @@
 	gpio2: gpio at ffc42000 {
 		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
 		reg = <0xffc42000 0x2c>;
-		interrupts = <0 103 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 64 32>;
@@ -122,7 +123,7 @@
 	gpio3: gpio at ffc43000 {
 		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
 		reg = <0xffc43000 0x2c>;
-		interrupts = <0 103 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 96 32>;
@@ -133,7 +134,7 @@
 	gpio4: gpio at ffc44000 {
 		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
 		reg = <0xffc44000 0x2c>;
-		interrupts = <0 103 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 128 27>;
@@ -151,7 +152,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7778";
 		reg = <0xffc70000 0x1000>;
-		interrupts = <0 67 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_I2C0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -162,7 +163,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7778";
 		reg = <0xffc71000 0x1000>;
-		interrupts = <0 78 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_I2C1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -173,7 +174,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7778";
 		reg = <0xffc72000 0x1000>;
-		interrupts = <0 76 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_I2C2>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -184,7 +185,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7778";
 		reg = <0xffc73000 0x1000>;
-		interrupts = <0 77 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_I2C3>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -193,9 +194,9 @@
 	tmu0: timer at ffd80000 {
 		compatible = "renesas,tmu-r8a7778", "renesas,tmu";
 		reg = <0xffd80000 0x30>;
-		interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 33 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 34 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_TMU0>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -208,9 +209,9 @@
 	tmu1: timer at ffd81000 {
 		compatible = "renesas,tmu-r8a7778", "renesas,tmu";
 		reg = <0xffd81000 0x30>;
-		interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 37 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 38 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_TMU1>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -223,9 +224,9 @@
 	tmu2: timer at ffd82000 {
 		compatible = "renesas,tmu-r8a7778", "renesas,tmu";
 		reg = <0xffd82000 0x30>;
-		interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 41 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 42 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_TMU2>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -285,20 +286,20 @@
 		};
 
 		rcar_sound,ssi {
-			ssi3: ssi at 3 { interrupts = <0 0x85 IRQ_TYPE_LEVEL_HIGH>; };
-			ssi4: ssi at 4 { interrupts = <0 0x85 IRQ_TYPE_LEVEL_HIGH>; };
-			ssi5: ssi at 5 { interrupts = <0 0x86 IRQ_TYPE_LEVEL_HIGH>; };
-			ssi6: ssi at 6 { interrupts = <0 0x86 IRQ_TYPE_LEVEL_HIGH>; };
-			ssi7: ssi at 7 { interrupts = <0 0x86 IRQ_TYPE_LEVEL_HIGH>; };
-			ssi8: ssi at 8 { interrupts = <0 0x86 IRQ_TYPE_LEVEL_HIGH>; };
-			ssi9: ssi at 9 { interrupts = <0 0x86 IRQ_TYPE_LEVEL_HIGH>; };
+			ssi3: ssi at 3 { interrupts = <GIC_SPI 0x85 IRQ_TYPE_LEVEL_HIGH>; };
+			ssi4: ssi at 4 { interrupts = <GIC_SPI 0x85 IRQ_TYPE_LEVEL_HIGH>; };
+			ssi5: ssi at 5 { interrupts = <GIC_SPI 0x86 IRQ_TYPE_LEVEL_HIGH>; };
+			ssi6: ssi at 6 { interrupts = <GIC_SPI 0x86 IRQ_TYPE_LEVEL_HIGH>; };
+			ssi7: ssi at 7 { interrupts = <GIC_SPI 0x86 IRQ_TYPE_LEVEL_HIGH>; };
+			ssi8: ssi at 8 { interrupts = <GIC_SPI 0x86 IRQ_TYPE_LEVEL_HIGH>; };
+			ssi9: ssi at 9 { interrupts = <GIC_SPI 0x86 IRQ_TYPE_LEVEL_HIGH>; };
 		};
 	};
 
 	scif0: serial at ffe40000 {
 		compatible = "renesas,scif-r8a7778", "renesas,scif";
 		reg = <0xffe40000 0x100>;
-		interrupts = <0 70 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF0>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -308,7 +309,7 @@
 	scif1: serial at ffe41000 {
 		compatible = "renesas,scif-r8a7778", "renesas,scif";
 		reg = <0xffe41000 0x100>;
-		interrupts = <0 71 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF1>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -318,7 +319,7 @@
 	scif2: serial at ffe42000 {
 		compatible = "renesas,scif-r8a7778", "renesas,scif";
 		reg = <0xffe42000 0x100>;
-		interrupts = <0 72 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF2>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -328,7 +329,7 @@
 	scif3: serial at ffe43000 {
 		compatible = "renesas,scif-r8a7778", "renesas,scif";
 		reg = <0xffe43000 0x100>;
-		interrupts = <0 73 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF3>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -338,7 +339,7 @@
 	scif4: serial at ffe44000 {
 		compatible = "renesas,scif-r8a7778", "renesas,scif";
 		reg = <0xffe44000 0x100>;
-		interrupts = <0 74 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF4>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -348,7 +349,7 @@
 	scif5: serial at ffe45000 {
 		compatible = "renesas,scif-r8a7778", "renesas,scif";
 		reg = <0xffe45000 0x100>;
-		interrupts = <0 75 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF5>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -358,7 +359,7 @@
 	mmcif: mmc at ffe4e000 {
 		compatible = "renesas,sh-mmcif";
 		reg = <0xffe4e000 0x100>;
-		interrupts = <0 61 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7778_CLK_MMC>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -367,7 +368,7 @@
 	sdhi0: sd at ffe4c000 {
 		compatible = "renesas,sdhi-r8a7778";
 		reg = <0xffe4c000 0x100>;
-		interrupts = <0 87 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7778_CLK_SDHI0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -376,7 +377,7 @@
 	sdhi1: sd at ffe4d000 {
 		compatible = "renesas,sdhi-r8a7778";
 		reg = <0xffe4d000 0x100>;
-		interrupts = <0 88 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7778_CLK_SDHI1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -385,7 +386,7 @@
 	sdhi2: sd at ffe4f000 {
 		compatible = "renesas,sdhi-r8a7778";
 		reg = <0xffe4f000 0x100>;
-		interrupts = <0 86 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7778_CLK_SDHI2>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -394,7 +395,7 @@
 	hspi0: spi at fffc7000 {
 		compatible = "renesas,hspi-r8a7778", "renesas,hspi";
 		reg = <0xfffc7000 0x18>;
-		interrupts = <0 63 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_HSPI>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -405,7 +406,7 @@
 	hspi1: spi at fffc8000 {
 		compatible = "renesas,hspi-r8a7778", "renesas,hspi";
 		reg = <0xfffc8000 0x18>;
-		interrupts = <0 84 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_HSPI>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -416,7 +417,7 @@
 	hspi2: spi at fffc6000 {
 		compatible = "renesas,hspi-r8a7778", "renesas,hspi";
 		reg = <0xfffc6000 0x18>;
-		interrupts = <0 85 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_HSPI>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:12 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:12 +0100
Subject: [PATCH 18/70] ARM: dts: r8a7779: use GIC_* defines
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <854b7733fee0ebdb70e34ffa5f57de4cff319a49.1454595846.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7779 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7779.dtsi | 78 +++++++++++++++++++++---------------------
 1 file changed, 39 insertions(+), 39 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 6afa909865b5..93f3fdf95e31 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -74,7 +74,7 @@
 	gpio0: gpio at ffc40000 {
 		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
 		reg = <0xffc40000 0x2c>;
-		interrupts = <0 141 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 0 32>;
@@ -85,7 +85,7 @@
 	gpio1: gpio at ffc41000 {
 		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
 		reg = <0xffc41000 0x2c>;
-		interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 32 32>;
@@ -96,7 +96,7 @@
 	gpio2: gpio at ffc42000 {
 		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
 		reg = <0xffc42000 0x2c>;
-		interrupts = <0 143 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 64 32>;
@@ -107,7 +107,7 @@
 	gpio3: gpio at ffc43000 {
 		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
 		reg = <0xffc43000 0x2c>;
-		interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 96 32>;
@@ -118,7 +118,7 @@
 	gpio4: gpio at ffc44000 {
 		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
 		reg = <0xffc44000 0x2c>;
-		interrupts = <0 145 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 128 32>;
@@ -129,7 +129,7 @@
 	gpio5: gpio at ffc45000 {
 		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
 		reg = <0xffc45000 0x2c>;
-		interrupts = <0 146 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 160 32>;
@@ -140,7 +140,7 @@
 	gpio6: gpio at ffc46000 {
 		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
 		reg = <0xffc46000 0x2c>;
-		interrupts = <0 147 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 192 9>;
@@ -159,10 +159,10 @@
 			<0xfe780044 4>,
 			<0xfe780064 4>,
 			<0xfe780000 4>;
-		interrupts = <0 27 IRQ_TYPE_LEVEL_HIGH
-			      0 28 IRQ_TYPE_LEVEL_HIGH
-			      0 29 IRQ_TYPE_LEVEL_HIGH
-			      0 30 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		sense-bitfield-width = <2>;
 	};
 
@@ -171,7 +171,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7779";
 		reg = <0xffc70000 0x1000>;
-		interrupts = <0 79 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_I2C0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -182,7 +182,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7779";
 		reg = <0xffc71000 0x1000>;
-		interrupts = <0 82 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_I2C1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -193,7 +193,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7779";
 		reg = <0xffc72000 0x1000>;
-		interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_I2C2>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -204,7 +204,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7779";
 		reg = <0xffc73000 0x1000>;
-		interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_I2C3>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -213,7 +213,7 @@
 	scif0: serial at ffe40000 {
 		compatible = "renesas,scif-r8a7779", "renesas,scif";
 		reg = <0xffe40000 0x100>;
-		interrupts = <0 88 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF0>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -223,7 +223,7 @@
 	scif1: serial at ffe41000 {
 		compatible = "renesas,scif-r8a7779", "renesas,scif";
 		reg = <0xffe41000 0x100>;
-		interrupts = <0 89 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF1>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -233,7 +233,7 @@
 	scif2: serial at ffe42000 {
 		compatible = "renesas,scif-r8a7779", "renesas,scif";
 		reg = <0xffe42000 0x100>;
-		interrupts = <0 90 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF2>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -243,7 +243,7 @@
 	scif3: serial at ffe43000 {
 		compatible = "renesas,scif-r8a7779", "renesas,scif";
 		reg = <0xffe43000 0x100>;
-		interrupts = <0 91 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF3>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -253,7 +253,7 @@
 	scif4: serial at ffe44000 {
 		compatible = "renesas,scif-r8a7779", "renesas,scif";
 		reg = <0xffe44000 0x100>;
-		interrupts = <0 92 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF4>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -263,7 +263,7 @@
 	scif5: serial at ffe45000 {
 		compatible = "renesas,scif-r8a7779", "renesas,scif";
 		reg = <0xffe45000 0x100>;
-		interrupts = <0 93 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF5>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -283,9 +283,9 @@
 	tmu0: timer at ffd80000 {
 		compatible = "renesas,tmu-r8a7779", "renesas,tmu";
 		reg = <0xffd80000 0x30>;
-		interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 33 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 34 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_TMU0>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -298,9 +298,9 @@
 	tmu1: timer at ffd81000 {
 		compatible = "renesas,tmu-r8a7779", "renesas,tmu";
 		reg = <0xffd81000 0x30>;
-		interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 37 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 38 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_TMU1>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -313,9 +313,9 @@
 	tmu2: timer at ffd82000 {
 		compatible = "renesas,tmu-r8a7779", "renesas,tmu";
 		reg = <0xffd82000 0x30>;
-		interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 41 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 42 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_TMU2>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -328,7 +328,7 @@
 	sata: sata at fc600000 {
 		compatible = "renesas,sata-r8a7779", "renesas,rcar-sata";
 		reg = <0xfc600000 0x2000>;
-		interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7779_CLK_SATA>;
 		power-domains = <&cpg_clocks>;
 	};
@@ -336,7 +336,7 @@
 	sdhi0: sd at ffe4c000 {
 		compatible = "renesas,sdhi-r8a7779";
 		reg = <0xffe4c000 0x100>;
-		interrupts = <0 104 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7779_CLK_SDHI0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -345,7 +345,7 @@
 	sdhi1: sd at ffe4d000 {
 		compatible = "renesas,sdhi-r8a7779";
 		reg = <0xffe4d000 0x100>;
-		interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7779_CLK_SDHI1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -354,7 +354,7 @@
 	sdhi2: sd at ffe4e000 {
 		compatible = "renesas,sdhi-r8a7779";
 		reg = <0xffe4e000 0x100>;
-		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7779_CLK_SDHI2>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -363,7 +363,7 @@
 	sdhi3: sd at ffe4f000 {
 		compatible = "renesas,sdhi-r8a7779";
 		reg = <0xffe4f000 0x100>;
-		interrupts = <0 106 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7779_CLK_SDHI3>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -372,7 +372,7 @@
 	hspi0: spi at fffc7000 {
 		compatible = "renesas,hspi-r8a7779", "renesas,hspi";
 		reg = <0xfffc7000 0x18>;
-		interrupts = <0 73 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&mstp0_clks R8A7779_CLK_HSPI>;
@@ -383,7 +383,7 @@
 	hspi1: spi at fffc8000 {
 		compatible = "renesas,hspi-r8a7779", "renesas,hspi";
 		reg = <0xfffc8000 0x18>;
-		interrupts = <0 74 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&mstp0_clks R8A7779_CLK_HSPI>;
@@ -394,7 +394,7 @@
 	hspi2: spi at fffc6000 {
 		compatible = "renesas,hspi-r8a7779", "renesas,hspi";
 		reg = <0xfffc6000 0x18>;
-		interrupts = <0 75 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&mstp0_clks R8A7779_CLK_HSPI>;
@@ -405,7 +405,7 @@
 	du: display at fff80000 {
 		compatible = "renesas,du-r8a7779";
 		reg = <0 0xfff80000 0 0x40000>;
-		interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7779_CLK_DU>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:09 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:09 +0100
Subject: [PATCH 15/70] ARM: dts: r8a7794: use GIC_* defines
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <8d47e6af6f824e6f68f0af3f09816cc424e6fbac.1454595846.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7794 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7794.dtsi | 234 ++++++++++++++++++++---------------------
 1 file changed, 117 insertions(+), 117 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index f8cd3a0beebf..21be4bdc4001 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -59,13 +59,13 @@
 			<0 0xf1002000 0 0x1000>,
 			<0 0xf1004000 0 0x2000>,
 			<0 0xf1006000 0 0x2000>;
-		interrupts = <1 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
 	};
 
 	gpio0: gpio at e6050000 {
 		compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
 		reg = <0 0xe6050000 0 0x50>;
-		interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 0 32>;
@@ -78,7 +78,7 @@
 	gpio1: gpio at e6051000 {
 		compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
 		reg = <0 0xe6051000 0 0x50>;
-		interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 32 26>;
@@ -91,7 +91,7 @@
 	gpio2: gpio at e6052000 {
 		compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
 		reg = <0 0xe6052000 0 0x50>;
-		interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 64 32>;
@@ -104,7 +104,7 @@
 	gpio3: gpio at e6053000 {
 		compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
 		reg = <0 0xe6053000 0 0x50>;
-		interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 96 32>;
@@ -117,7 +117,7 @@
 	gpio4: gpio at e6054000 {
 		compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
 		reg = <0 0xe6054000 0 0x50>;
-		interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 128 32>;
@@ -130,7 +130,7 @@
 	gpio5: gpio at e6055000 {
 		compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
 		reg = <0 0xe6055000 0 0x50>;
-		interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 160 28>;
@@ -143,7 +143,7 @@
 	gpio6: gpio at e6055400 {
 		compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
 		reg = <0 0xe6055400 0 0x50>;
-		interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 192 26>;
@@ -156,8 +156,8 @@
 	cmt0: timer at ffca0000 {
 		compatible = "renesas,cmt-48-gen2";
 		reg = <0 0xffca0000 0 0x1004>;
-		interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 143 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7794_CLK_CMT0>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -170,14 +170,14 @@
 	cmt1: timer at e6130000 {
 		compatible = "renesas,cmt-48-gen2";
 		reg = <0 0xe6130000 0 0x1004>;
-		interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 121 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 122 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 123 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 124 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 125 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 126 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 127 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7794_CLK_CMT1>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -189,10 +189,10 @@
 
 	timer {
 		compatible = "arm,armv7-timer";
-		interrupts = <1 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
 	};
 
 	irqc0: interrupt-controller at e61c0000 {
@@ -200,16 +200,16 @@
 		#interrupt-cells = <2>;
 		interrupt-controller;
 		reg = <0 0xe61c0000 0 0x200>;
-		interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 1 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 2 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 3 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 12 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 13 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 14 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 15 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 16 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 17 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A7794_CLK_IRQC>;
 		power-domains = <&cpg_clocks>;
 	};
@@ -222,22 +222,22 @@
 	dmac0: dma-controller at e6700000 {
 		compatible = "renesas,dmac-r8a7794", "renesas,rcar-dmac";
 		reg = <0 0xe6700000 0 0x20000>;
-		interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH
-			      0 200 IRQ_TYPE_LEVEL_HIGH
-			      0 201 IRQ_TYPE_LEVEL_HIGH
-			      0 202 IRQ_TYPE_LEVEL_HIGH
-			      0 203 IRQ_TYPE_LEVEL_HIGH
-			      0 204 IRQ_TYPE_LEVEL_HIGH
-			      0 205 IRQ_TYPE_LEVEL_HIGH
-			      0 206 IRQ_TYPE_LEVEL_HIGH
-			      0 207 IRQ_TYPE_LEVEL_HIGH
-			      0 208 IRQ_TYPE_LEVEL_HIGH
-			      0 209 IRQ_TYPE_LEVEL_HIGH
-			      0 210 IRQ_TYPE_LEVEL_HIGH
-			      0 211 IRQ_TYPE_LEVEL_HIGH
-			      0 212 IRQ_TYPE_LEVEL_HIGH
-			      0 213 IRQ_TYPE_LEVEL_HIGH
-			      0 214 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -253,22 +253,22 @@
 	dmac1: dma-controller at e6720000 {
 		compatible = "renesas,dmac-r8a7794", "renesas,rcar-dmac";
 		reg = <0 0xe6720000 0 0x20000>;
-		interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
-			      0 216 IRQ_TYPE_LEVEL_HIGH
-			      0 217 IRQ_TYPE_LEVEL_HIGH
-			      0 218 IRQ_TYPE_LEVEL_HIGH
-			      0 219 IRQ_TYPE_LEVEL_HIGH
-			      0 308 IRQ_TYPE_LEVEL_HIGH
-			      0 309 IRQ_TYPE_LEVEL_HIGH
-			      0 310 IRQ_TYPE_LEVEL_HIGH
-			      0 311 IRQ_TYPE_LEVEL_HIGH
-			      0 312 IRQ_TYPE_LEVEL_HIGH
-			      0 313 IRQ_TYPE_LEVEL_HIGH
-			      0 314 IRQ_TYPE_LEVEL_HIGH
-			      0 315 IRQ_TYPE_LEVEL_HIGH
-			      0 316 IRQ_TYPE_LEVEL_HIGH
-			      0 317 IRQ_TYPE_LEVEL_HIGH
-			      0 318 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -284,7 +284,7 @@
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
-		interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
@@ -296,7 +296,7 @@
 	scifa1: serial at e6c50000 {
 		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
-		interrupts = <0 145 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
@@ -308,7 +308,7 @@
 	scifa2: serial at e6c60000 {
 		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
-		interrupts = <0 151 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
@@ -320,7 +320,7 @@
 	scifa3: serial at e6c70000 {
 		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
 		reg = <0 0xe6c70000 0 64>;
-		interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA3>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1b>, <&dmac0 0x1c>;
@@ -332,7 +332,7 @@
 	scifa4: serial at e6c78000 {
 		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
 		reg = <0 0xe6c78000 0 64>;
-		interrupts = <0 30 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA4>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1f>, <&dmac0 0x20>;
@@ -344,7 +344,7 @@
 	scifa5: serial at e6c80000 {
 		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
 		reg = <0 0xe6c80000 0 64>;
-		interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA5>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x23>, <&dmac0 0x24>;
@@ -356,7 +356,7 @@
 	scifb0: serial at e6c20000 {
 		compatible = "renesas,scifb-r8a7794", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
-		interrupts = <0 148 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
@@ -368,7 +368,7 @@
 	scifb1: serial at e6c30000 {
 		compatible = "renesas,scifb-r8a7794", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
@@ -380,7 +380,7 @@
 	scifb2: serial at e6ce0000 {
 		compatible = "renesas,scifb-r8a7794", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
-		interrupts = <0 150 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
@@ -392,7 +392,7 @@
 	scif0: serial at e6e60000 {
 		compatible = "renesas,scif-r8a7794", "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
-		interrupts = <0 152 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
@@ -404,7 +404,7 @@
 	scif1: serial at e6e68000 {
 		compatible = "renesas,scif-r8a7794", "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
-		interrupts = <0 153 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
@@ -416,7 +416,7 @@
 	scif2: serial at e6e58000 {
 		compatible = "renesas,scif-r8a7794", "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
-		interrupts = <0 22 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
@@ -428,7 +428,7 @@
 	scif3: serial at e6ea8000 {
 		compatible = "renesas,scif-r8a7794", "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
-		interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF3>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
@@ -440,7 +440,7 @@
 	scif4: serial at e6ee0000 {
 		compatible = "renesas,scif-r8a7794", "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
-		interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF4>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
@@ -452,7 +452,7 @@
 	scif5: serial at e6ee8000 {
 		compatible = "renesas,scif-r8a7794", "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
-		interrupts = <0 25 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF5>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
@@ -464,7 +464,7 @@
 	hscif0: serial at e62c0000 {
 		compatible = "renesas,hscif-r8a7794", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
-		interrupts = <0 154 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
@@ -476,7 +476,7 @@
 	hscif1: serial at e62c8000 {
 		compatible = "renesas,hscif-r8a7794", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
-		interrupts = <0 155 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
@@ -488,7 +488,7 @@
 	hscif2: serial at e62d0000 {
 		compatible = "renesas,hscif-r8a7794", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
-		interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
@@ -500,7 +500,7 @@
 	ether: ethernet at ee700000 {
 		compatible = "renesas,ether-r8a7794";
 		reg = <0 0xee700000 0 0x400>;
-		interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7794_CLK_ETHER>;
 		power-domains = <&cpg_clocks>;
 		phy-mode = "rmii";
@@ -513,7 +513,7 @@
 	i2c0: i2c at e6508000 {
 		compatible = "renesas,i2c-r8a7794";
 		reg = <0 0xe6508000 0 0x40>;
-		interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7794_CLK_I2C0>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -525,7 +525,7 @@
 	i2c1: i2c at e6518000 {
 		compatible = "renesas,i2c-r8a7794";
 		reg = <0 0xe6518000 0 0x40>;
-		interrupts = <0 288 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7794_CLK_I2C1>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -537,7 +537,7 @@
 	i2c2: i2c at e6530000 {
 		compatible = "renesas,i2c-r8a7794";
 		reg = <0 0xe6530000 0 0x40>;
-		interrupts = <0 286 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7794_CLK_I2C2>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -549,7 +549,7 @@
 	i2c3: i2c at e6540000 {
 		compatible = "renesas,i2c-r8a7794";
 		reg = <0 0xe6540000 0 0x40>;
-		interrupts = <0 290 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7794_CLK_I2C3>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -561,7 +561,7 @@
 	i2c4: i2c at e6520000 {
 		compatible = "renesas,i2c-r8a7794";
 		reg = <0 0xe6520000 0 0x40>;
-		interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7794_CLK_I2C4>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -573,7 +573,7 @@
 	i2c5: i2c at e6528000 {
 		compatible = "renesas,i2c-r8a7794";
 		reg = <0 0xe6528000 0 0x40>;
-		interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7794_CLK_I2C5>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -585,7 +585,7 @@
 	mmcif0: mmc at ee200000 {
 		compatible = "renesas,mmcif-r8a7794", "renesas,sh-mmcif";
 		reg = <0 0xee200000 0 0x80>;
-		interrupts = <0 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7794_CLK_MMCIF0>;
 		dmas = <&dmac0 0xd1>, <&dmac0 0xd2>;
 		dma-names = "tx", "rx";
@@ -597,7 +597,7 @@
 	sdhi0: sd at ee100000 {
 		compatible = "renesas,sdhi-r8a7794";
 		reg = <0 0xee100000 0 0x200>;
-		interrupts = <0 165 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7794_CLK_SDHI0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -606,7 +606,7 @@
 	sdhi1: sd at ee140000 {
 		compatible = "renesas,sdhi-r8a7794";
 		reg = <0 0xee140000 0 0x100>;
-		interrupts = <0 167 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7794_CLK_SDHI1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -615,7 +615,7 @@
 	sdhi2: sd at ee160000 {
 		compatible = "renesas,sdhi-r8a7794";
 		reg = <0 0xee160000 0 0x100>;
-		interrupts = <0 168 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7794_CLK_SDHI2>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -624,7 +624,7 @@
 	qspi: spi at e6b10000 {
 		compatible = "renesas,qspi-r8a7794", "renesas,qspi";
 		reg = <0 0xe6b10000 0 0x2c>;
-		interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7794_CLK_QSPI_MOD>;
 		dmas = <&dmac0 0x17>, <&dmac0 0x18>;
 		dma-names = "tx", "rx";
@@ -638,7 +638,7 @@
 	vin0: video at e6ef0000 {
 		compatible = "renesas,vin-r8a7794";
 		reg = <0 0xe6ef0000 0 0x1000>;
-		interrupts = <0 188 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7794_CLK_VIN0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -647,7 +647,7 @@
 	vin1: video at e6ef1000 {
 		compatible = "renesas,vin-r8a7794";
 		reg = <0 0xe6ef1000 0 0x1000>;
-		interrupts = <0 189 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7794_CLK_VIN1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -658,7 +658,7 @@
 		device_type = "pci";
 		reg = <0 0xee090000 0 0xc00>,
 		      <0 0xee080000 0 0x1100>;
-		interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_EHCI>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -669,9 +669,9 @@
 		#interrupt-cells = <1>;
 		ranges = <0x02000000 0 0xee080000 0 0xee080000 0 0x00010000>;
 		interrupt-map-mask = <0xff00 0 0 0x7>;
-		interrupt-map = <0x0000 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
-				 0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
-				 0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH
+				 0x0800 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH
+				 0x1000 0 0 2 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 
 		usb at 0,1 {
 			reg = <0x800 0 0 0 0>;
@@ -693,7 +693,7 @@
 		device_type = "pci";
 		reg = <0 0xee0d0000 0 0xc00>,
 		      <0 0xee0c0000 0 0x1100>;
-		interrupts = <0 113 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_EHCI>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -704,9 +704,9 @@
 		#interrupt-cells = <1>;
 		ranges = <0x02000000 0 0xee0c0000 0 0xee0c0000 0 0x00010000>;
 		interrupt-map-mask = <0xff00 0 0 0x7>;
-		interrupt-map = <0x0000 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
-				 0x0800 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
-				 0x1000 0 0 2 &gic 0 113 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
+				 0x0800 0 0 1 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
+				 0x1000 0 0 2 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
 
 		usb at 0,1 {
 			reg = <0x800 0 0 0 0>;
@@ -726,7 +726,7 @@
 	hsusb: usb at e6590000 {
 		compatible = "renesas,usbhs-r8a7794", "renesas,rcar-gen2-usbhs";
 		reg = <0 0xe6590000 0 0x100>;
-		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSUSB>;
 		power-domains = <&cpg_clocks>;
 		renesas,buswait = <4>;
@@ -759,8 +759,8 @@
 		compatible = "renesas,du-r8a7794";
 		reg = <0 0xfeb00000 0 0x40000>;
 		reg-names = "du";
-		interrupts = <0 256 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 268 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_DU0>,
 			 <&mstp7_clks R8A7794_CLK_DU0>;
 		clock-names = "du.0", "du.1";
@@ -1111,8 +1111,8 @@
 	ipmmu_sy0: mmu at e6280000 {
 		compatible = "renesas,ipmmu-r8a7794", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6280000 0 0x1000>;
-		interrupts = <0 223 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 224 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1120,7 +1120,7 @@
 	ipmmu_sy1: mmu at e6290000 {
 		compatible = "renesas,ipmmu-r8a7794", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6290000 0 0x1000>;
-		interrupts = <0 225 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1128,8 +1128,8 @@
 	ipmmu_ds: mmu at e6740000 {
 		compatible = "renesas,ipmmu-r8a7794", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6740000 0 0x1000>;
-		interrupts = <0 198 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 199 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1137,7 +1137,7 @@
 	ipmmu_mp: mmu at ec680000 {
 		compatible = "renesas,ipmmu-r8a7794", "renesas,ipmmu-vmsa";
 		reg = <0 0xec680000 0 0x1000>;
-		interrupts = <0 226 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1145,8 +1145,8 @@
 	ipmmu_mx: mmu at fe951000 {
 		compatible = "renesas,ipmmu-r8a7794", "renesas,ipmmu-vmsa";
 		reg = <0 0xfe951000 0 0x1000>;
-		interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 221 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1154,8 +1154,8 @@
 	ipmmu_gp: mmu at e62a0000 {
 		compatible = "renesas,ipmmu-r8a7794", "renesas,ipmmu-vmsa";
 		reg = <0 0xe62a0000 0 0x1000>;
-		interrupts = <0 260 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 261 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 261 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:13 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:13 +0100
Subject: [PATCH 19/70] ARM: dts: porter: add sound support
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <493b4da7c10ca647850627849bcf6031c0a80f13.1454595846.git.horms+renesas@verge.net.au>

From: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

Define the Porter board dependent part of the R8A7791 sound device node.
Add device node for Asahi Kasei AK4642 stereo codec  to the I2C2 bus.
Add the "simple-audio-card" device node to interconnect the SoC sound
device  and the codec.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791-porter.dts | 71 ++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
index fe81fa0e478c..5015eaa0ae50 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -8,6 +8,17 @@
  * kind, whether express or implied.
  */
 
+/*
+ * SSI-AK4642
+ *
+ * SW3: 1: AK4642
+ *      3: ADV7511
+ *
+ * This command is required before playback/capture:
+ *
+ *	amixer set "LINEOUT Mixer DACL" on
+ */
+
 /dts-v1/;
 #include "r8a7791.dtsi"
 #include <dt-bindings/gpio/gpio.h>
@@ -101,6 +112,30 @@
 		#clock-cells = <0>;
 		clock-frequency = <74250000>;
 	};
+
+	x14_clk: x14-clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <11289600>;
+		clock-output-names = "audio_clock";
+	};
+
+	sound {
+		compatible = "simple-audio-card";
+
+		simple-audio-card,format = "left_j";
+		simple-audio-card,bitclock-master = <&soundcodec>;
+		simple-audio-card,frame-master = <&soundcodec>;
+
+		simple-audio-card,cpu {
+			sound-dai = <&rcar_sound>;
+		};
+
+		soundcodec: simple-audio-card,codec {
+			sound-dai = <&ak4642>;
+			clocks = <&x14_clk>;
+		};
+	};
 };
 
 &extal_clk {
@@ -167,6 +202,16 @@
 		renesas,groups = "du_rgb888", "du_sync", "du_disp", "du_clk_out_0";
 		renesas,function = "du";
 	};
+
+	ssi_pins: sound {
+		renesas,groups = "ssi0129_ctrl", "ssi0_data", "ssi1_data";
+		renesas,function = "ssi";
+	};
+
+	audio_clk_pins: audio_clk {
+		renesas,groups = "audio_clk_a";
+		renesas,function = "audio_clk";
+	};
 };
 
 &scif0 {
@@ -257,6 +302,12 @@
 	status = "okay";
 	clock-frequency = <400000>;
 
+	ak4642: codec at 12 {
+		compatible = "asahi-kasei,ak4642";
+		#sound-dai-cells = <0>;
+		reg = <0x12>;
+	};
+
 	composite-in at 20 {
 		compatible = "adi,adv7180";
 		reg = <0x20>;
@@ -385,3 +436,23 @@
 		};
 	};
 };
+
+&rcar_sound {
+	pinctrl-0 = <&ssi_pins &audio_clk_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	/* Single DAI */
+	#sound-dai-cells = <0>;
+
+	rcar_sound,dai {
+		dai0 {
+			playback = <&ssi0>;
+			capture  = <&ssi1>;
+		};
+	};
+};
+
+&ssi1 {
+	shared-pin;
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:16 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:16 +0100
Subject: [PATCH 22/70] ARM: dts: r8a7793: add MSTP10 clocks to device tree
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <072d326542e491874c31adda10bf513b371e560c.1454595846.git.horms+renesas@verge.net.au>

Instantiate MSTP10 clocks in r8a7793 device tree.

Based on similar work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi            | 36 +++++++++++++++++++++++++++++++
 include/dt-bindings/clock/r8a7793-clock.h |  2 ++
 2 files changed, 38 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index ea1196b99d52..c4459f147330 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -963,6 +963,42 @@
 				"qspi_mod", "i2c5", "i2c6", "i2c4",
 				"i2c3", "i2c2", "i2c1", "i2c0";
 		};
+		mstp10_clks: mstp10_clks at e6150998 {
+			compatible = "renesas,r8a7793-mstp-clocks", "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>;
+			clocks = <&p_clk>,
+				<&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+				<&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+				<&p_clk>,
+				<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>,
+				<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>,
+				<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>,
+				<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>,
+				<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>,
+				<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>,
+				<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>;
+
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7793_CLK_SSI_ALL
+				R8A7793_CLK_SSI9 R8A7793_CLK_SSI8 R8A7793_CLK_SSI7 R8A7793_CLK_SSI6 R8A7793_CLK_SSI5
+				R8A7793_CLK_SSI4 R8A7793_CLK_SSI3 R8A7793_CLK_SSI2 R8A7793_CLK_SSI1 R8A7793_CLK_SSI0
+				R8A7793_CLK_SCU_ALL
+				R8A7793_CLK_SCU_DVC1 R8A7793_CLK_SCU_DVC0
+				R8A7793_CLK_SCU_CTU1_MIX1 R8A7793_CLK_SCU_CTU0_MIX0
+				R8A7793_CLK_SCU_SRC9 R8A7793_CLK_SCU_SRC8 R8A7793_CLK_SCU_SRC7 R8A7793_CLK_SCU_SRC6 R8A7793_CLK_SCU_SRC5
+				R8A7793_CLK_SCU_SRC4 R8A7793_CLK_SCU_SRC3 R8A7793_CLK_SCU_SRC2 R8A7793_CLK_SCU_SRC1 R8A7793_CLK_SCU_SRC0
+			>;
+			clock-output-names =
+				"ssi-all",
+				"ssi9", "ssi8", "ssi7", "ssi6", "ssi5",
+				"ssi4", "ssi3", "ssi2", "ssi1", "ssi0",
+				"scu-all",
+				"scu-dvc1", "scu-dvc0",
+				"scu-ctu1-mix1", "scu-ctu0-mix0",
+				"scu-src9", "scu-src8", "scu-src7", "scu-src6", "scu-src5",
+				"scu-src4", "scu-src3", "scu-src2", "scu-src1", "scu-src0";
+		};
 		mstp11_clks: mstp11_clks at e615099c {
 			compatible = "renesas,r8a7793-mstp-clocks", "renesas,cpg-mstp-clocks";
 			reg = <0 0xe615099c 0 4>, <0 0xe61509ac 0 4>;
diff --git a/include/dt-bindings/clock/r8a7793-clock.h b/include/dt-bindings/clock/r8a7793-clock.h
index 1579e07f96a3..efcbc594fe82 100644
--- a/include/dt-bindings/clock/r8a7793-clock.h
+++ b/include/dt-bindings/clock/r8a7793-clock.h
@@ -145,6 +145,8 @@
 #define R8A7793_CLK_SCU_ALL		17
 #define R8A7793_CLK_SCU_DVC1		18
 #define R8A7793_CLK_SCU_DVC0		19
+#define R8A7793_CLK_SCU_CTU1_MIX1	20
+#define R8A7793_CLK_SCU_CTU0_MIX0	21
 #define R8A7793_CLK_SCU_SRC9		22
 #define R8A7793_CLK_SCU_SRC8		23
 #define R8A7793_CLK_SCU_SRC7		24
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:17 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:17 +0100
Subject: [PATCH 23/70] ARM: dts: r8a7793: add audio clock to device tree
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <ad6472bf11464d498fefcea9ae30ddf9255e4f49.1454595846.git.horms+renesas@verge.net.au>

Instantiate audio clock in r8a7793 device tree.
audio_clk_a/b/c are required for R-Car sound.

Based on similar work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index c4459f147330..530fa9488a4a 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -706,6 +706,29 @@
 			clock-output-names = "extal";
 		};
 
+		/*
+		 * The external audio clocks are configured as 0 Hz fixed frequency clocks by
+		 * default. Boards that provide audio clocks should override them.
+		 */
+		audio_clk_a: audio_clk_a {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+			clock-output-names = "audio_clk_a";
+		};
+		audio_clk_b: audio_clk_b {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+			clock-output-names = "audio_clk_b";
+		};
+		audio_clk_c: audio_clk_c {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+			clock-output-names = "audio_clk_c";
+		};
+
 		/* Special CPG clocks */
 		cpg_clocks: cpg_clocks at e6150000 {
 			compatible = "renesas,r8a7793-cpg-clocks",
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:45 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:45 +0100
Subject: [PATCH 8/8] arm64: dts: salvator-x: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1454595726.git.horms+renesas@verge.net.au>
References: <cover.1454595726.git.horms+renesas@verge.net.au>
Message-ID: <a3fc85e27b7e3c29b30909929bc64737a19fd251.1454595726.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates:
  - SCIF:
      - Supports now 50, 230400, 460800, 500000, and 921600 bps,
      - Perfect match for standard 50-460800, and 9216000 bps.
  - HSCIF:
      - Supports now 50, 75, and 110 bps,
      - Perfect match for standard 50-460800, and 9216000 bps.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 9af1e3fdc468..31ace9c1f79d 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -93,6 +93,9 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	scif1_pins: scif1 {
 		renesas,groups = "scif1_data_a", "scif1_ctrl";
 		renesas,function = "scif1";
@@ -101,6 +104,10 @@
 		renesas,groups = "scif2_data_a";
 		renesas,function = "scif2";
 	};
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk_a";
+		renesas,function = "scif_clk";
+	};
 
 	i2c2_pins: i2c2 {
 		renesas,groups = "i2c2_a";
@@ -138,6 +145,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &i2c2 {
 	pinctrl-0 = <&i2c2_pins>;
 	pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



From linux at arm.linux.org.uk  Thu Feb  4 06:39:07 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 4 Feb 2016 14:39:07 +0000
Subject: linux-next: build failure after merge of the aio tree
In-Reply-To: <20160204143204.GC16315@kvack.org>
References: <20160112163835.GD347@kvack.org>
 <20160127134024.0fababf6@canb.auug.org.au>
 <20160129113056.GP10826@n2100.arm.linux.org.uk>
 <CAMuHMdUy-cqeN8COO4rdpY-mOH+6gth40wB31-edkj8CO5PFCw@mail.gmail.com>
 <20160204131959.6695c7bf@canb.auug.org.au>
 <20160204134142.GA16315@kvack.org>
 <20160204135056.GE10826@n2100.arm.linux.org.uk>
 <20160204140822.GB16315@kvack.org>
 <20160204141253.GF10826@n2100.arm.linux.org.uk>
 <20160204143204.GC16315@kvack.org>
Message-ID: <20160204143907.GG10826@n2100.arm.linux.org.uk>

On Thu, Feb 04, 2016 at 09:32:04AM -0500, Benjamin LaHaise wrote:
> On Thu, Feb 04, 2016 at 02:12:53PM +0000, Russell King - ARM Linux wrote:
> > Hence, __get_user() on x86-32 with a 64-bit quantity results in
> > __get_user_bad() being called, which is an undefined function.
> > Only if you build with x86-64 support enabled (iow, CONFIG_X86_32 not
> > defined) then you get the 64-bit __get_user() support.
> > 
> > Given this, I fail to see how x86-32 can possibly work.
> 
> You're right; mea culpa.  It compiles without warning on x86-32, but it 
> does not link.  I still think this is broken archtecture stupidity since 
> put_user() works for 64 bit data types.

Indeed, and you'll find that several other architectures besides ARM and
x86-32 have exactly the same problem - as I listed in my message from a
few days ago.

Okay, so now I get to set you a challenge, since you're the one wanting
64-bit __get_user(): try implementing it on x86-32 :)

Also in my previous message from a few days ago I provided a set of
functions which test out the implementation.  Here they are... again.

All these should not produce any warnings, and should produce correct
code - especially the narrowing/widening tests:

int test_8(unsigned char *v, unsigned char *p)
{ return __get_user(*v, p); }
int test_8_constp(unsigned char *v, const unsigned char *p)
{ return __get_user(*v, p); }
int test_8_volatilep(unsigned char *v, volatile unsigned char *p)
{ return __get_user(*v, p); }
int test_16(unsigned short *v, unsigned short *p)
{ return __get_user(*v, p); }
int test_16_constp(unsigned short *v, const unsigned short *p)
{ return __get_user(*v, p); }
int test_32(unsigned int *v, unsigned int *p)
{ return __get_user(*v, p); }
int test_32_constp(unsigned int *v, const unsigned int *p)
{ return __get_user(*v, p); }
int test_64(unsigned long long *v, unsigned long long *p)
{ return __get_user(*v, p); }
int test_64_constp(unsigned long long *v, const unsigned long long *p)
{ return __get_user(*v, p); }
int test_ptr(unsigned int **v, unsigned int **p)
{ return __get_user(*v, p); }
int test_const(unsigned int *v, const unsigned int *p)
{ return __get_user(*v, p); }
int test_64_narrow(unsigned long *v, unsigned long long *p)
{ return __get_user(*v, p); }
int test_32_wide(unsigned long long *v, unsigned long *p)
{ return __get_user(*v, p); }

However, this one should warn:

int test_wrong(char **v, const char **p)
{ return __get_user(*v, p); }

Good luck (I think you'll need lots of it to get a working solution)! :)

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From horms+renesas at verge.net.au  Thu Feb  4 06:29:18 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:18 +0100
Subject: [PATCH 24/70] ARM: dts: r8a7793: add m2 clock to device tree
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <892f09f1528d113f8d1e5983ecebd322236ded95.1454595846.git.horms+renesas@verge.net.au>

Declare m2 clock in r8a7793 device tree.

Based on similar work for the r8a7791 by Laurent Pinchart.

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 530fa9488a4a..6aabba6ef92c 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -817,6 +817,14 @@
 			clock-mult = <1>;
 			clock-output-names = "p";
 		};
+		m2_clk: m2_clk {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7793_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <8>;
+			clock-mult = <1>;
+			clock-output-names = "m2";
+		};
 		rclk_clk: rclk_clk {
 			compatible = "fixed-factor-clock";
 			clocks = <&cpg_clocks R8A7793_CLK_PLL1>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:15 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:15 +0100
Subject: [PATCH 21/70] ARM: dts: r8a7740: use GIC_* defines
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <e1e7b6fa83f0d8372392662ebdffdd79c71ba6a3.1454595846.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7740 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7740.dtsi | 143 +++++++++++++++++++++--------------------
 1 file changed, 72 insertions(+), 71 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 6ef954766eef..36bcb39cca03 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -11,6 +11,7 @@
 /include/ "skeleton.dtsi"
 
 #include <dt-bindings/clock/r8a7740-clock.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/interrupt-controller/irq.h>
 
 / {
@@ -41,7 +42,7 @@
 	L2: cache-controller {
 		compatible = "arm,pl310-cache";
 		reg = <0xf0100000 0x1000>;
-		interrupts = <0 84 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
 		power-domains = <&pd_a3sm>;
 		arm,data-latency = <3 3 3>;
 		arm,tag-latency = <2 2 2>;
@@ -58,7 +59,7 @@
 
 	pmu {
 		compatible = "arm,cortex-a9-pmu";
-		interrupts = <0 83 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
 	};
 
 	ptm {
@@ -69,7 +70,7 @@
 	cmt1: timer at e6138000 {
 		compatible = "renesas,cmt-48-r8a7740", "renesas,cmt-48";
 		reg = <0xe6138000 0x170>;
-		interrupts = <0 58 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7740_CLK_CMT1>;
 		clock-names = "fck";
 		power-domains = <&pd_c5>;
@@ -89,14 +90,14 @@
 			<0xe6900020 1>,
 			<0xe6900040 1>,
 			<0xe6900060 1>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_INTCA>;
 		power-domains = <&pd_a4s>;
 	};
@@ -111,14 +112,14 @@
 			<0xe6900024 1>,
 			<0xe6900044 1>,
 			<0xe6900064 1>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_INTCA>;
 		power-domains = <&pd_a4s>;
 	};
@@ -133,14 +134,14 @@
 			<0xe6900028 1>,
 			<0xe6900048 1>,
 			<0xe6900068 1>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_INTCA>;
 		power-domains = <&pd_a4s>;
 	};
@@ -155,14 +156,14 @@
 			<0xe690002c 1>,
 			<0xe690004c 1>,
 			<0xe690006c 1>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_INTCA>;
 		power-domains = <&pd_a4s>;
 	};
@@ -171,7 +172,7 @@
 		compatible = "renesas,gether-r8a7740";
 		reg = <0xe9a00000 0x800>,
 		      <0xe9a01800 0x800>;
-		interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7740_CLK_GETHER>;
 		power-domains = <&pd_a4s>;
 		phy-mode = "mii";
@@ -185,10 +186,10 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7740", "renesas,rmobile-iic";
 		reg = <0xfff20000 0x425>;
-		interrupts = <0 201 IRQ_TYPE_LEVEL_HIGH
-			      0 202 IRQ_TYPE_LEVEL_HIGH
-			      0 203 IRQ_TYPE_LEVEL_HIGH
-			      0 204 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7740_CLK_IIC0>;
 		power-domains = <&pd_a4r>;
 		status = "disabled";
@@ -199,10 +200,10 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7740", "renesas,rmobile-iic";
 		reg = <0xe6c20000 0x425>;
-		interrupts = <0 70 IRQ_TYPE_LEVEL_HIGH
-			      0 71 IRQ_TYPE_LEVEL_HIGH
-			      0 72 IRQ_TYPE_LEVEL_HIGH
-			      0 73 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7740_CLK_IIC1>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -211,7 +212,7 @@
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6c40000 0x100>;
-		interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA0>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -221,7 +222,7 @@
 	scifa1: serial at e6c50000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6c50000 0x100>;
-		interrupts = <0 101 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA1>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -231,7 +232,7 @@
 	scifa2: serial at e6c60000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6c60000 0x100>;
-		interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA2>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -241,7 +242,7 @@
 	scifa3: serial at e6c70000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6c70000 0x100>;
-		interrupts = <0 103 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA3>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -251,7 +252,7 @@
 	scifa4: serial at e6c80000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6c80000 0x100>;
-		interrupts = <0 104 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA4>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -261,7 +262,7 @@
 	scifa5: serial at e6cb0000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6cb0000 0x100>;
-		interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA5>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -271,7 +272,7 @@
 	scifa6: serial at e6cc0000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6cc0000 0x100>;
-		interrupts = <0 106 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA6>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -281,7 +282,7 @@
 	scifa7: serial at e6cd0000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6cd0000 0x100>;
-		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA7>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -291,7 +292,7 @@
 	scifb: serial at e6c30000 {
 		compatible = "renesas,scifb-r8a7740", "renesas,scifb";
 		reg = <0xe6c30000 0x100>;
-		interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFB>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -329,8 +330,8 @@
 	mmcif0: mmc at e6bd0000 {
 		compatible = "renesas,mmcif-r8a7740", "renesas,sh-mmcif";
 		reg = <0xe6bd0000 0x100>;
-		interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH
-			      0 57 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7740_CLK_MMC>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -339,9 +340,9 @@
 	sdhi0: sd at e6850000 {
 		compatible = "renesas,sdhi-r8a7740";
 		reg = <0xe6850000 0x100>;
-		interrupts = <0 117 IRQ_TYPE_LEVEL_HIGH
-			      0 118 IRQ_TYPE_LEVEL_HIGH
-			      0 119 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7740_CLK_SDHI0>;
 		power-domains = <&pd_a3sp>;
 		cap-sd-highspeed;
@@ -352,9 +353,9 @@
 	sdhi1: sd at e6860000 {
 		compatible = "renesas,sdhi-r8a7740";
 		reg = <0xe6860000 0x100>;
-		interrupts = <0 121 IRQ_TYPE_LEVEL_HIGH
-			      0 122 IRQ_TYPE_LEVEL_HIGH
-			      0 123 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7740_CLK_SDHI1>;
 		power-domains = <&pd_a3sp>;
 		cap-sd-highspeed;
@@ -365,9 +366,9 @@
 	sdhi2: sd at e6870000 {
 		compatible = "renesas,sdhi-r8a7740";
 		reg = <0xe6870000 0x100>;
-		interrupts = <0 125 IRQ_TYPE_LEVEL_HIGH
-			      0 126 IRQ_TYPE_LEVEL_HIGH
-			      0 127 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A7740_CLK_SDHI2>;
 		power-domains = <&pd_a3sp>;
 		cap-sd-highspeed;
@@ -379,7 +380,7 @@
 		#sound-dai-cells = <1>;
 		compatible = "renesas,fsi2-r8a7740", "renesas,sh_fsi2";
 		reg = <0xfe1f0000 0x400>;
-		interrupts = <0 9 0x4>;
+		interrupts = <GIC_SPI 9 0x4>;
 		clocks = <&mstp3_clks R8A7740_CLK_FSI>;
 		power-domains = <&pd_a4mp>;
 		status = "disabled";
@@ -388,9 +389,9 @@
 	tmu0: timer at fff80000 {
 		compatible = "renesas,tmu-r8a7740", "renesas,tmu";
 		reg = <0xfff80000 0x2c>;
-		interrupts = <0 198 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 199 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 200 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7740_CLK_TMU0>;
 		clock-names = "fck";
 		power-domains = <&pd_a4r>;
@@ -403,9 +404,9 @@
 	tmu1: timer at fff90000 {
 		compatible = "renesas,tmu-r8a7740", "renesas,tmu";
 		reg = <0xfff90000 0x2c>;
-		interrupts = <0 170 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 171 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 172 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7740_CLK_TMU1>;
 		clock-names = "fck";
 		power-domains = <&pd_a4r>;
-- 
2.7.0.rc3.207.g0ac5344



From linux at roeck-us.net  Thu Feb  4 06:41:35 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 4 Feb 2016 06:41:35 -0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <56B35698.4020100@codeaurora.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
 <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
 <56B2DEE4.7060901@roeck-us.net> <56B35698.4020100@codeaurora.org>
Message-ID: <56B3631F.6090304@roeck-us.net>

On 02/04/2016 05:48 AM, Timur Tabi wrote:
> Guenter Roeck wrote:
>> Also, if panic is enabled, the timeout needs to be adjusted accordingly
>> (to only panic after the entire timeout period has expired, not after
>> half of it). We can not panic the system after timeout / 2.
>
> It's a debugging feature, not an actual watchdog timeout panic.  That's why it's disabled by default.
>

"* When the first stage(the half timeout) is reached, WS0 interrupt is
  * triggered, at this moment the second watch period starts;
  * In the WS0 interrupt routine, panic will be triggered for saving the
  * system context.
  * If the system is getting into trouble and cannot be reset by panic or
  * restart properly by the kdump kernel(if supported), then the second
  * stage (the timeout) will be reached, system will be reset by WS1."

That doesn't sound like debugging to me.

Guenter



From horms+renesas at verge.net.au  Thu Feb  4 06:29:19 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:19 +0100
Subject: [PATCH 25/70] ARM: dts: r8a7793: add R-Car sound support to device
 tree
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <951431e08636858bafabb7654c3aae0eac18d950.1454595846.git.horms+renesas@verge.net.au>

Instantiate R-Car sound node in r8a7793 device tree.
This only supports PIO transfers.

Based on similar work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 83 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 83 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 6aabba6ef92c..8b1ec47754ac 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -1101,4 +1101,87 @@
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
+
+	rcar_sound: sound at ec500000 {
+		/*
+		 * #sound-dai-cells is required
+		 *
+		 * Single DAI : #sound-dai-cells = <0>;         <&rcar_sound>;
+		 * Multi  DAI : #sound-dai-cells = <1>;         <&rcar_sound N>;
+		 */
+		compatible =  "renesas,rcar_sound-r8a7793", "renesas,rcar_sound-gen2";
+		reg =	<0 0xec500000 0 0x1000>, /* SCU */
+			<0 0xec5a0000 0 0x100>,  /* ADG */
+			<0 0xec540000 0 0x1000>, /* SSIU */
+			<0 0xec541000 0 0x280>;  /* SSI */
+		reg-names = "scu", "adg", "ssiu", "ssi";
+
+		clocks = <&mstp10_clks R8A7793_CLK_SSI_ALL>,
+			<&mstp10_clks R8A7793_CLK_SSI9>, <&mstp10_clks R8A7793_CLK_SSI8>,
+			<&mstp10_clks R8A7793_CLK_SSI7>, <&mstp10_clks R8A7793_CLK_SSI6>,
+			<&mstp10_clks R8A7793_CLK_SSI5>, <&mstp10_clks R8A7793_CLK_SSI4>,
+			<&mstp10_clks R8A7793_CLK_SSI3>, <&mstp10_clks R8A7793_CLK_SSI2>,
+			<&mstp10_clks R8A7793_CLK_SSI1>, <&mstp10_clks R8A7793_CLK_SSI0>,
+			<&mstp10_clks R8A7793_CLK_SCU_SRC9>, <&mstp10_clks R8A7793_CLK_SCU_SRC8>,
+			<&mstp10_clks R8A7793_CLK_SCU_SRC7>, <&mstp10_clks R8A7793_CLK_SCU_SRC6>,
+			<&mstp10_clks R8A7793_CLK_SCU_SRC5>, <&mstp10_clks R8A7793_CLK_SCU_SRC4>,
+			<&mstp10_clks R8A7793_CLK_SCU_SRC3>, <&mstp10_clks R8A7793_CLK_SCU_SRC2>,
+			<&mstp10_clks R8A7793_CLK_SCU_SRC1>, <&mstp10_clks R8A7793_CLK_SCU_SRC0>,
+			<&audio_clk_a>, <&audio_clk_b>, <&audio_clk_c>, <&m2_clk>;
+		clock-names = "ssi-all",
+				"ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
+				"ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0",
+				"src.9", "src.8", "src.7", "src.6", "src.5",
+				"src.4", "src.3", "src.2", "src.1", "src.0",
+				"clk_a", "clk_b", "clk_c", "clk_i";
+		power-domains = <&cpg_clocks>;
+
+		status = "disabled";
+
+		rcar_sound,src {
+			src0: src at 0 { };
+			src1: src at 1 { };
+			src2: src at 2 { };
+			src3: src at 3 { };
+			src4: src at 4 { };
+			src5: src at 5 { };
+			src6: src at 6 { };
+			src7: src at 7 { };
+			src8: src at 8 { };
+			src9: src at 9 { };
+		};
+
+		rcar_sound,ssi {
+			ssi0: ssi at 0 {
+				interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi1: ssi at 1 {
+				 interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi2: ssi at 2 {
+				interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi3: ssi at 3 {
+				interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi4: ssi at 4 {
+				interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi5: ssi at 5 {
+				interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi6: ssi at 6 {
+				interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi7: ssi at 7 {
+				interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi8: ssi at 8 {
+				interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi9: ssi at 9 {
+				interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
+			};
+		};
+	};
 };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:24 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:24 +0100
Subject: [PATCH 30/70] ARM: dts: gose: Enable sound PIO support in device tree
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <f8905ce841deb22b43c6cc1f2ef47638e61bbec6.1454595846.git.horms+renesas@verge.net.au>

Enable sound PIO support in the r8a7793/gose device tree.

Based on similar work for the r8a7791/koelsch by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 77 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 0b4cc8d99390..395ea63746ac 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -8,6 +8,17 @@
  * kind, whether express or implied.
  */
 
+/*
+ * SSI-AK4643
+ *
+ * SW1: 1: AK4643
+ *      2: CN22
+ *      3: ADV7511
+ *
+ * This command is required when Playback/Capture
+ *
+ *	amixer set "LINEOUT Mixer DACL" on
+ */
 /dts-v1/;
 #include "r8a7793.dtsi"
 #include <dt-bindings/gpio/gpio.h>
@@ -130,6 +141,30 @@
 		};
 	};
 
+	audio_clock: clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <11289600>;
+		clock-output-names = "audio_clock";
+	};
+
+	rsnd_ak4643: sound {
+		compatible = "simple-audio-card";
+
+		simple-audio-card,format = "left_j";
+		simple-audio-card,bitclock-master = <&sndcodec>;
+		simple-audio-card,frame-master = <&sndcodec>;
+
+		sndcpu: simple-audio-card,cpu {
+			sound-dai = <&rcar_sound>;
+		};
+
+		sndcodec: simple-audio-card,codec {
+			sound-dai = <&ak4643>;
+			clocks = <&audio_clock>;
+		};
+	};
+
 	hdmi-out {
 		compatible = "hdmi-connector";
 		type = "a";
@@ -218,6 +253,16 @@
 		renesas,groups = "qspi_ctrl", "qspi_data4";
 		renesas,function = "qspi";
 	};
+
+	sound_pins: sound {
+		renesas,groups = "ssi0129_ctrl", "ssi0_data", "ssi1_data";
+		renesas,function = "ssi";
+	};
+
+	sound_clk_pins: sound_clk {
+		renesas,groups = "audio_clk_a";
+		renesas,function = "audio_clk";
+	};
 };
 
 &ether {
@@ -300,6 +345,12 @@
 	status = "okay";
 	clock-frequency = <100000>;
 
+	ak4643: codec at 12 {
+		compatible = "asahi-kasei,ak4643";
+		#sound-dai-cells = <0>;
+		reg = <0x12>;
+	};
+
 	hdmi at 39 {
 		compatible = "adi,adv7511w";
 		reg = <0x39>;
@@ -338,3 +389,29 @@
 		pagesize = <16>;
 	};
 };
+
+&rcar_sound {
+	pinctrl-0 = <&sound_pins &sound_clk_pins>;
+	pinctrl-names = "default";
+
+	/* Single DAI */
+	#sound-dai-cells = <0>;
+
+	status = "okay";
+
+	rcar_sound,dai {
+		dai0 {
+			playback = <&ssi0>;
+			capture  = <&ssi1>;
+		};
+	};
+};
+
+&ssi0 {
+	pio-transfer;
+};
+
+&ssi1 {
+	pio-transfer;
+	shared-pin;
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:42 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:42 +0100
Subject: [PATCH 5/8] arm64: dts: r8a7795: Add SCIF fallback compatibility
 strings
In-Reply-To: <cover.1454595726.git.horms+renesas@verge.net.au>
References: <cover.1454595726.git.horms+renesas@verge.net.au>
Message-ID: <653f502d779e9ef90daa32443d0c60ebf67d5da9.1454595726.git.horms+renesas@verge.net.au>

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

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 38 +++++++++++++++++++++++---------
 1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 95967b72db35..013df449fc30 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -474,7 +474,9 @@
 		};
 
 		hscif0: serial at e6540000 {
-			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
+			compatible = "renesas,hscif-r8a7795",
+				     "renesas,rcar-gen3-hscif",
+				     "renesas,hscif";
 			reg = <0 0xe6540000 0 96>;
 			interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 520>;
@@ -486,7 +488,9 @@
 		};
 
 		hscif1: serial at e6550000 {
-			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
+			compatible = "renesas,hscif-r8a7795",
+				     "renesas,rcar-gen3-hscif",
+				     "renesas,hscif";
 			reg = <0 0xe6550000 0 96>;
 			interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 519>;
@@ -498,7 +502,9 @@
 		};
 
 		hscif2: serial at e6560000 {
-			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
+			compatible = "renesas,hscif-r8a7795",
+				     "renesas,rcar-gen3-hscif",
+				     "renesas,hscif";
 			reg = <0 0xe6560000 0 96>;
 			interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 518>;
@@ -510,7 +516,9 @@
 		};
 
 		hscif3: serial at e66a0000 {
-			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
+			compatible = "renesas,hscif-r8a7795",
+				     "renesas,rcar-gen3-hscif",
+				     "renesas,hscif";
 			reg = <0 0xe66a0000 0 96>;
 			interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 517>;
@@ -522,7 +530,9 @@
 		};
 
 		hscif4: serial at e66b0000 {
-			compatible = "renesas,hscif-r8a7795", "renesas,hscif";
+			compatible = "renesas,hscif-r8a7795",
+				     "renesas,rcar-gen3-hscif",
+				     "renesas,hscif";
 			reg = <0 0xe66b0000 0 96>;
 			interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 516>;
@@ -534,7 +544,8 @@
 		};
 
 		scif0: serial at e6e60000 {
-			compatible = "renesas,scif-r8a7795", "renesas,scif";
+			compatible = "renesas,scif-r8a7795",
+				     "renesas,rcar-gen3-scif", "renesas,scif";
 			reg = <0 0xe6e60000 0 64>;
 			interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 207>;
@@ -546,7 +557,8 @@
 		};
 
 		scif1: serial at e6e68000 {
-			compatible = "renesas,scif-r8a7795", "renesas,scif";
+			compatible = "renesas,scif-r8a7795",
+				     "renesas,rcar-gen3-scif", "renesas,scif";
 			reg = <0 0xe6e68000 0 64>;
 			interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 206>;
@@ -558,7 +570,8 @@
 		};
 
 		scif2: serial at e6e88000 {
-			compatible = "renesas,scif-r8a7795", "renesas,scif";
+			compatible = "renesas,scif-r8a7795",
+				     "renesas,rcar-gen3-scif", "renesas,scif";
 			reg = <0 0xe6e88000 0 64>;
 			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 310>;
@@ -570,7 +583,8 @@
 		};
 
 		scif3: serial at e6c50000 {
-			compatible = "renesas,scif-r8a7795", "renesas,scif";
+			compatible = "renesas,scif-r8a7795",
+				     "renesas,rcar-gen3-scif", "renesas,scif";
 			reg = <0 0xe6c50000 0 64>;
 			interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 204>;
@@ -582,7 +596,8 @@
 		};
 
 		scif4: serial at e6c40000 {
-			compatible = "renesas,scif-r8a7795", "renesas,scif";
+			compatible = "renesas,scif-r8a7795",
+				     "renesas,rcar-gen3-scif", "renesas,scif";
 			reg = <0 0xe6c40000 0 64>;
 			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 203>;
@@ -594,7 +609,8 @@
 		};
 
 		scif5: serial at e6f30000 {
-			compatible = "renesas,scif-r8a7795", "renesas,scif";
+			compatible = "renesas,scif-r8a7795",
+				     "renesas,rcar-gen3-scif", "renesas,scif";
 			reg = <0 0xe6f30000 0 64>;
 			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
 			clocks = <&cpg CPG_MOD 202>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:20 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:20 +0100
Subject: [PATCH 26/70] ARM: dts: r8a7793: add DVC support to device tree
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <4dfc6f8bbf821850c7a4e7f1364a42b63375ad4e.1454595846.git.horms+renesas@verge.net.au>

Add DVC support to sound node in r8a7793 device tree.

Based on similar work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 8b1ec47754ac..3531d30fe107 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -1127,17 +1127,23 @@
 			<&mstp10_clks R8A7793_CLK_SCU_SRC5>, <&mstp10_clks R8A7793_CLK_SCU_SRC4>,
 			<&mstp10_clks R8A7793_CLK_SCU_SRC3>, <&mstp10_clks R8A7793_CLK_SCU_SRC2>,
 			<&mstp10_clks R8A7793_CLK_SCU_SRC1>, <&mstp10_clks R8A7793_CLK_SCU_SRC0>,
+			<&mstp10_clks R8A7793_CLK_SCU_DVC0>, <&mstp10_clks R8A7793_CLK_SCU_DVC1>,
 			<&audio_clk_a>, <&audio_clk_b>, <&audio_clk_c>, <&m2_clk>;
 		clock-names = "ssi-all",
 				"ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
 				"ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0",
 				"src.9", "src.8", "src.7", "src.6", "src.5",
 				"src.4", "src.3", "src.2", "src.1", "src.0",
+				"dvc.0", "dvc.1",
 				"clk_a", "clk_b", "clk_c", "clk_i";
 		power-domains = <&cpg_clocks>;
 
 		status = "disabled";
 
+		rcar_sound,dvc {
+			dvc0: dvc at 0 { };
+			dvc1: dvc at 1 { };
+		};
 		rcar_sound,src {
 			src0: src at 0 { };
 			src1: src at 1 { };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:21 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:21 +0100
Subject: [PATCH 27/70] ARM: dts: r8a7793: add audio DMAC clocks to device tree
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <8d2883bddf47e3d59a4f041c6bd338f0d18783fe.1454595846.git.horms+renesas@verge.net.au>

Instantiate Audio DMA clocks in the r8a7791 device tree.

Based on similar work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 3531d30fe107..cb6251e71ef9 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -924,10 +924,11 @@
 		mstp5_clks: mstp5_clks at e6150144 {
 			compatible = "renesas,r8a7793-mstp-clocks", "renesas,cpg-mstp-clocks";
 			reg = <0 0xe6150144 0 4>, <0 0xe615003c 0 4>;
-			clocks = <&extal_clk>;
+			clocks = <&hp_clk>, <&hp_clk>, <&extal_clk>;
 			#clock-cells = <1>;
-			clock-indices = <R8A7793_CLK_THERMAL>;
-			clock-output-names = "thermal";
+			clock-indices = <R8A7793_CLK_AUDIO_DMAC0 R8A7793_CLK_AUDIO_DMAC1
+					 R8A7793_CLK_THERMAL>;
+			clock-output-names = "audmac0", "audmac1", "thermal";
 		};
 		mstp7_clks: mstp7_clks at e615014c {
 			compatible = "renesas,r8a7793-mstp-clocks",
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:22 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:22 +0100
Subject: [PATCH 28/70] ARM: dts: r8a7793: add audio DMAC to device tree
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <6708eb73183e226ddd73dae128239e76b3807390.1454595846.git.horms+renesas@verge.net.au>

Instantiate the two Audio DMA controllers in the r8a7791 device tree.

Based on similar work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 58 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index cb6251e71ef9..2c9ab9f18b41 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -301,6 +301,64 @@
 		dma-channels = <15>;
 	};
 
+	audma0: dma-controller at ec700000 {
+		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
+		reg = <0 0xec700000 0 0x10000>;
+		interrupts = <GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "error",
+				"ch0", "ch1", "ch2", "ch3",
+				"ch4", "ch5", "ch6", "ch7",
+				"ch8", "ch9", "ch10", "ch11",
+				"ch12";
+		clocks = <&mstp5_clks R8A7793_CLK_AUDIO_DMAC0>;
+		clock-names = "fck";
+		power-domains = <&cpg_clocks>;
+		#dma-cells = <1>;
+		dma-channels = <13>;
+	};
+
+	audma1: dma-controller at ec720000 {
+		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
+		reg = <0 0xec720000 0 0x10000>;
+		interrupts = <GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "error",
+				"ch0", "ch1", "ch2", "ch3",
+				"ch4", "ch5", "ch6", "ch7",
+				"ch8", "ch9", "ch10", "ch11",
+				"ch12";
+		clocks = <&mstp5_clks R8A7793_CLK_AUDIO_DMAC1>;
+		clock-names = "fck";
+		power-domains = <&cpg_clocks>;
+		#dma-cells = <1>;
+		dma-channels = <13>;
+	};
+
 	/* The memory map in the User's Manual maps the cores to bus numbers */
 	i2c0: i2c at e6508000 {
 		#address-cells = <1>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:14 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:14 +0100
Subject: [PATCH 20/70] ARM: dts: r8a73a4: use GIC_* defines
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <4d5746a3ec3a705028aeb81b34fbca70e523668a.1454595846.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a73a4 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a73a4.dtsi | 212 ++++++++++++++++++++---------------------
 1 file changed, 106 insertions(+), 106 deletions(-)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index cb4f7b2798fe..64f3efcd7ba5 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -39,10 +39,10 @@
 
 	timer {
 		compatible = "arm,armv7-timer";
-		interrupts = <1 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
 	};
 
 	dbsc1: memory-controller at e6790000 {
@@ -69,27 +69,27 @@
 		dma0: dma-controller at e6700020 {
 			compatible = "renesas,shdma-r8a73a4";
 			reg = <0 0xe6700020 0 0x89e0>;
-			interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
-					0 200 IRQ_TYPE_LEVEL_HIGH
-					0 201 IRQ_TYPE_LEVEL_HIGH
-					0 202 IRQ_TYPE_LEVEL_HIGH
-					0 203 IRQ_TYPE_LEVEL_HIGH
-					0 204 IRQ_TYPE_LEVEL_HIGH
-					0 205 IRQ_TYPE_LEVEL_HIGH
-					0 206 IRQ_TYPE_LEVEL_HIGH
-					0 207 IRQ_TYPE_LEVEL_HIGH
-					0 208 IRQ_TYPE_LEVEL_HIGH
-					0 209 IRQ_TYPE_LEVEL_HIGH
-					0 210 IRQ_TYPE_LEVEL_HIGH
-					0 211 IRQ_TYPE_LEVEL_HIGH
-					0 212 IRQ_TYPE_LEVEL_HIGH
-					0 213 IRQ_TYPE_LEVEL_HIGH
-					0 214 IRQ_TYPE_LEVEL_HIGH
-					0 215 IRQ_TYPE_LEVEL_HIGH
-					0 216 IRQ_TYPE_LEVEL_HIGH
-					0 217 IRQ_TYPE_LEVEL_HIGH
-					0 218 IRQ_TYPE_LEVEL_HIGH
-					0 219 IRQ_TYPE_LEVEL_HIGH>;
+			interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "error",
 					"ch0", "ch1", "ch2", "ch3",
 					"ch4", "ch5", "ch6", "ch7",
@@ -106,7 +106,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe60b0000 0 0x428>;
-		interrupts = <0 179 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A73A4_CLK_IIC5>;
 		power-domains = <&pd_a3sp>;
 
@@ -116,7 +116,7 @@
 	cmt1: timer at e6130000 {
 		compatible = "renesas,cmt-48-r8a73a4", "renesas,cmt-48-gen2";
 		reg = <0 0xe6130000 0 0x1004>;
-		interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_CMT1>;
 		clock-names = "fck";
 		power-domains = <&pd_c5>;
@@ -131,38 +131,38 @@
 		#interrupt-cells = <2>;
 		interrupt-controller;
 		reg = <0 0xe61c0000 0 0x200>;
-		interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 1 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 2 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 3 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 4 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 5 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 6 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 7 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 8 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 9 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 10 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 11 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 12 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 13 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 14 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 15 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 16 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 17 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 18 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 19 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 20 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 21 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 22 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 23 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 24 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 25 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 26 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 27 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 28 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 29 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 30 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 31 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A73A4_CLK_IRQC>;
 		power-domains = <&pd_c4>;
 	};
@@ -172,32 +172,32 @@
 		#interrupt-cells = <2>;
 		interrupt-controller;
 		reg = <0 0xe61c0200 0 0x200>;
-		interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 33 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 34 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 35 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 36 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 37 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 38 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 39 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 40 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 41 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 42 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 43 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 44 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 45 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 46 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 47 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 48 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 49 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 50 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 51 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 52 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 53 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 54 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 55 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 56 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 57 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A73A4_CLK_IRQC>;
 		power-domains = <&pd_c4>;
 	};
@@ -237,7 +237,7 @@
 		compatible = "renesas,thermal-r8a73a4", "renesas,rcar-thermal";
 		reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>,
 			 <0 0xe61f0200 0 0x38>, <0 0xe61f0300 0 0x38>;
-		interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks R8A73A4_CLK_THERMAL>;
 		power-domains = <&pd_c5>;
 	};
@@ -247,7 +247,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6500000 0 0x428>;
-		interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_IIC0>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -258,7 +258,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6510000 0 0x428>;
-		interrupts = <0 175 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_IIC1>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -269,7 +269,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6520000 0 0x428>;
-		interrupts = <0 176 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_IIC2>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -280,7 +280,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6530000 0 0x428>;
-		interrupts = <0 177 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A73A4_CLK_IIC3>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -291,7 +291,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6540000 0 0x428>;
-		interrupts = <0 178 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A73A4_CLK_IIC4>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -302,7 +302,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6550000 0 0x428>;
-		interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_IIC6>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -313,7 +313,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6560000 0 0x428>;
-		interrupts = <0 185 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_IIC7>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -324,7 +324,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6570000 0 0x428>;
-		interrupts = <0 173 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks R8A73A4_CLK_IIC8>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -333,7 +333,7 @@
 	scifb0: serial at e6c20000 {
 		compatible = "renesas,scifb-r8a73a4", "renesas,scifb";
 		reg = <0 0xe6c20000 0 0x100>;
-		interrupts = <0 148 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB0>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -343,7 +343,7 @@
 	scifb1: serial at e6c30000 {
 		compatible = "renesas,scifb-r8a73a4", "renesas,scifb";
 		reg = <0 0xe6c30000 0 0x100>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB1>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -353,7 +353,7 @@
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a73a4", "renesas,scifa";
 		reg = <0 0xe6c40000 0 0x100>;
-		interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFA0>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -363,7 +363,7 @@
 	scifa1: serial at e6c50000 {
 		compatible = "renesas,scifa-r8a73a4", "renesas,scifa";
 		reg = <0 0xe6c50000 0 0x100>;
-		interrupts = <0 145 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFA1>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -373,7 +373,7 @@
 	scifb2: serial at e6ce0000 {
 		compatible = "renesas,scifb-r8a73a4", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 0x100>;
-		interrupts = <0 150 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB2>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -383,7 +383,7 @@
 	scifb3: serial at e6cf0000 {
 		compatible = "renesas,scifb-r8a73a4", "renesas,scifb";
 		reg = <0 0xe6cf0000 0 0x100>;
-		interrupts = <0 151 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB3>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_c4>;
@@ -393,7 +393,7 @@
 	sdhi0: sd at ee100000 {
 		compatible = "renesas,sdhi-r8a73a4";
 		reg = <0 0xee100000 0 0x100>;
-		interrupts = <0 165 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_SDHI0>;
 		power-domains = <&pd_a3sp>;
 		cap-sd-highspeed;
@@ -403,7 +403,7 @@
 	sdhi1: sd at ee120000 {
 		compatible = "renesas,sdhi-r8a73a4";
 		reg = <0 0xee120000 0 0x100>;
-		interrupts = <0 166 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_SDHI1>;
 		power-domains = <&pd_a3sp>;
 		cap-sd-highspeed;
@@ -413,7 +413,7 @@
 	sdhi2: sd at ee140000 {
 		compatible = "renesas,sdhi-r8a73a4";
 		reg = <0 0xee140000 0 0x100>;
-		interrupts = <0 167 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_SDHI2>;
 		power-domains = <&pd_a3sp>;
 		cap-sd-highspeed;
@@ -423,7 +423,7 @@
 	mmcif0: mmc at ee200000 {
 		compatible = "renesas,sh-mmcif";
 		reg = <0 0xee200000 0 0x80>;
-		interrupts = <0 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_MMCIF0>;
 		power-domains = <&pd_a3sp>;
 		reg-io-width = <4>;
@@ -433,7 +433,7 @@
 	mmcif1: mmc at ee220000 {
 		compatible = "renesas,sh-mmcif";
 		reg = <0 0xee220000 0 0x80>;
-		interrupts = <0 170 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_MMCIF1>;
 		power-domains = <&pd_a3sp>;
 		reg-io-width = <4>;
@@ -449,7 +449,7 @@
 			<0 0xf1002000 0 0x1000>,
 			<0 0xf1004000 0 0x2000>,
 			<0 0xf1006000 0 0x2000>;
-		interrupts = <1 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
 	};
 
 	bsc: bus at fec10000 {
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:23 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:23 +0100
Subject: [PATCH 29/70] ARM: dts: r8a7793: enable Audio DMAC peri peri via
 sound driver
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <3cf7452a5ae2a90448121feb29810bf437d72f02.1454595846.git.horms+renesas@verge.net.au>

Audio DMAC peri peri is no longer DMAEngine. it is supported by
sound driver. this patch enable it.

Base on work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 2c9ab9f18b41..ddbda9d2c177 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -1172,8 +1172,9 @@
 		reg =	<0 0xec500000 0 0x1000>, /* SCU */
 			<0 0xec5a0000 0 0x100>,  /* ADG */
 			<0 0xec540000 0 0x1000>, /* SSIU */
-			<0 0xec541000 0 0x280>;  /* SSI */
-		reg-names = "scu", "adg", "ssiu", "ssi";
+			<0 0xec541000 0 0x280>,  /* SSI */
+			<0 0xec740000 0 0x200>;  /* Audio DMAC peri peri*/
+		reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
 
 		clocks = <&mstp10_clks R8A7793_CLK_SSI_ALL>,
 			<&mstp10_clks R8A7793_CLK_SSI9>, <&mstp10_clks R8A7793_CLK_SSI8>,
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:25 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:25 +0100
Subject: [PATCH 31/70] ARM: dts: gose: enable sound DMA support in device tree
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <96c1b8d8507102759c1e232f371ff333811ccdd9.1454595846.git.horms+renesas@verge.net.au>

Enable DMA transfer to/from SSI in r8a7793/gose device tree.

     DMA
[MEM] -> [SSI]

     DMA
[MEM] <- [SSI]

Based on similar work for the r8a7791/koelsch by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 395ea63746ac..a4b2dcb8e73d 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -408,10 +408,10 @@
 };
 
 &ssi0 {
-	pio-transfer;
+	no-busif;
 };
 
 &ssi1 {
-	pio-transfer;
+	no-busif;
 	shared-pin;
 };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:26 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:26 +0100
Subject: [PATCH 32/70] ARM: dts: gose: enable sound DMA support via BUSIF in
 device tree
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <402586d0cce05317100356cfd73f0c044c60ccd7.1454595846.git.horms+renesas@verge.net.au>

Enable DMA transfer to/from SSIU in gose/r8a7791 device tree.

     DMA
[MEM] -> [SSIU] -> [SSI]

     DMA
[MEM] <- [SSIU] <- [SSI]

Based on similar work for the r8a7791/koelsch by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index a4b2dcb8e73d..81bfe9484bbc 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -407,11 +407,6 @@
 	};
 };
 
-&ssi0 {
-	no-busif;
-};
-
 &ssi1 {
-	no-busif;
 	shared-pin;
 };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:27 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:27 +0100
Subject: [PATCH 33/70] ARM: dts: gose: enable sound DMA support via SRC in
 device tree
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <d2cde3b6103678a4f3d2079af744937dfc9c4104.1454595846.git.horms+renesas@verge.net.au>

Enable DMA transfer to/from SRC in r8a7793/gose device tree.

     DMA      DMApp
[MEM] -> [SRC] -> [SSIU] -> [SSI]

     DMA      DMApp
[MEM] <- [SRC] <- [SSIU] <- [SSI]

Current sound driver is supporting
SSI/SRC random connection.
So, this patch is tring
SSI0 -> SRC2
SSI1 <- SRC3

Based on similar work for the r8a7791/koeslch by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 81bfe9484bbc..17c87fe0944f 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -401,8 +401,8 @@
 
 	rcar_sound,dai {
 		dai0 {
-			playback = <&ssi0>;
-			capture  = <&ssi1>;
+			playback = <&ssi0 &src2>;
+			capture  = <&ssi1 &src3>;
 		};
 	};
 };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:30 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:30 +0100
Subject: [PATCH 36/70] ARM: shmobile: r8a7740: Migrate to generic l2c OF
 initialization
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <540977ae9746e60cb95bc3d7d6769fd59b6b2cfc.1454595846.git.horms+renesas@verge.net.au>

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

Migrate the generic r8a7740 platform from calling l2x0_of_init() to the
generic l2c OF initialization.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7740.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 0c8f80c5b04d..7b16c12e3f81 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -110,10 +110,6 @@ static void __init r8a7740_generic_init(void)
 {
 	r8a7740_meram_workaround();
 
-#ifdef CONFIG_CACHE_L2X0
-	/* Shared attribute override enable, 32K*8way */
-	l2x0_init(IOMEM(0xf0002000), 0x00400000, 0xc20f0fff);
-#endif
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
@@ -123,6 +119,8 @@ static const char *const r8a7740_boards_compat_dt[] __initconst = {
 };
 
 DT_MACHINE_START(R8A7740_DT, "Generic R8A7740 (Flattened Device Tree)")
+	.l2c_aux_val	= 0,
+	.l2c_aux_mask	= ~0,
 	.map_io		= r8a7740_map_io,
 	.init_early	= shmobile_init_delay,
 	.init_irq	= r8a7740_init_irq_of,
-- 
2.7.0.rc3.207.g0ac5344



From moinejf at free.fr  Thu Feb  4 06:47:52 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Thu, 4 Feb 2016 15:47:52 +0100
Subject: [PATCH v3 1/5] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <1454542430-16572-2-git-send-email-k@japko.eu>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-2-git-send-email-k@japko.eu>
Message-ID: <20160204154752.4df7808be3364a98c496c030@free.fr>

On Thu,  4 Feb 2016 00:33:46 +0100
Krzysztof Adamski <k at japko.eu> wrote:

> This patch adds support for APB0 in H3. It seems to be compatible with
> earlier SOCs. apb0 gates controls R_ block peripherals (R_PIO, R_IR,
> etc).
> 
> Signed-off-by: Krzysztof Adamski <k at japko.eu>
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
>  drivers/clk/sunxi/clk-simple-gates.c              | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index e59f57b..751c8b9f0 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -45,6 +45,7 @@ Required properties:
>  	"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
>  	"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
>  	"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
> +	"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
>  	"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
>  	"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
>  	"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
> diff --git a/drivers/clk/sunxi/clk-simple-gates.c b/drivers/clk/sunxi/clk-simple-gates.c
> index f4da52b..6753c87 100644
> --- a/drivers/clk/sunxi/clk-simple-gates.c
> +++ b/drivers/clk/sunxi/clk-simple-gates.c
> @@ -130,6 +130,8 @@ CLK_OF_DECLARE(sun8i_a23_apb2, "allwinner,sun8i-a23-apb2-gates-clk",
>  	       sunxi_simple_gates_init);
>  CLK_OF_DECLARE(sun8i_a33_ahb1, "allwinner,sun8i-a33-ahb1-gates-clk",
>  	       sunxi_simple_gates_init);
> +CLK_OF_DECLARE(sun8i_h3_apb0, "allwinner,sun8i-h3-apb0-gates-clk",
> +	       sunxi_simple_gates_init);
>  CLK_OF_DECLARE(sun9i_a80_ahb0, "allwinner,sun9i-a80-ahb0-gates-clk",
>  	       sunxi_simple_gates_init);
>  CLK_OF_DECLARE(sun9i_a80_ahb1, "allwinner,sun9i-a80-ahb1-gates-clk",

It seems that the other compatible strings are there for historical
reasons. Why do you need a new one with such a specific name?

It would have been more sensible to add a generic compatible string as
"allwinner,apb-gates", letting the removal of the other strings for a
later patch...

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/



From horms+renesas at verge.net.au  Thu Feb  4 06:29:31 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:31 +0100
Subject: [PATCH 37/70] ARM: shmobile: r8a7740: Remove mapping of L2 cache
 controller registers
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <eba5fa581f0d056e0323a8398cf9a020bd6de065.1454595846.git.horms+renesas@verge.net.au>

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

Now all r8a7740-based platforms have been migrated to the generic l2c OF
initialization, it's no longer needed to map the L2 cache controller
registers from .map_io().

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7740.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 7b16c12e3f81..496569f9d578 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -38,18 +38,6 @@ static struct map_desc r8a7740_io_desc[] __initdata = {
 		.length		= 160 << 20,
 		.type		= MT_DEVICE_NONSHARED
 	},
-#ifdef CONFIG_CACHE_L2X0
-	/*
-	 * for l2x0_init()
-	 * 0xf0100000-0xf0101000 -> 0xf0002000-0xf0003000
-	 */
-	{
-		.virtual	= 0xf0002000,
-		.pfn		= __phys_to_pfn(0xf0100000),
-		.length		= PAGE_SIZE,
-		.type		= MT_DEVICE_NONSHARED
-	},
-#endif
 };
 
 static void __init r8a7740_map_io(void)
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:34 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:34 +0100
Subject: [PATCH 40/70] ARM: dts: emev2: use GIC_* defines
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <d8c76241e05f6e124a22ab36032f98d99733bc90.1454595846.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in emev2 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/emev2.dtsi | 39 ++++++++++++++++++++-------------------
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/arch/arm/boot/dts/emev2.dtsi b/arch/arm/boot/dts/emev2.dtsi
index 57795da616cb..bcce6f50c93d 100644
--- a/arch/arm/boot/dts/emev2.dtsi
+++ b/arch/arm/boot/dts/emev2.dtsi
@@ -9,6 +9,7 @@
  */
 
 #include "skeleton.dtsi"
+#include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/interrupt-controller/irq.h>
 
 / {
@@ -53,8 +54,8 @@
 
 	pmu {
 		compatible = "arm,cortex-a9-pmu";
-		interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 121 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
 	};
 
 	clocks at e0110000 {
@@ -158,7 +159,7 @@
 	timer at e0180000 {
 		compatible = "renesas,em-sti";
 		reg = <0xe0180000 0x54>;
-		interrupts = <0 125 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&sti_sclk>;
 		clock-names = "sclk";
 	};
@@ -166,7 +167,7 @@
 	uart0: serial at e1020000 {
 		compatible = "renesas,em-uart";
 		reg = <0xe1020000 0x38>;
-		interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&usia_u0_sclk>;
 		clock-names = "sclk";
 	};
@@ -174,7 +175,7 @@
 	uart1: serial at e1030000 {
 		compatible = "renesas,em-uart";
 		reg = <0xe1030000 0x38>;
-		interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&usib_u1_sclk>;
 		clock-names = "sclk";
 	};
@@ -182,7 +183,7 @@
 	uart2: serial at e1040000 {
 		compatible = "renesas,em-uart";
 		reg = <0xe1040000 0x38>;
-		interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&usib_u2_sclk>;
 		clock-names = "sclk";
 	};
@@ -190,7 +191,7 @@
 	uart3: serial at e1050000 {
 		compatible = "renesas,em-uart";
 		reg = <0xe1050000 0x38>;
-		interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&usib_u3_sclk>;
 		clock-names = "sclk";
 	};
@@ -203,8 +204,8 @@
 	gpio0: gpio at e0050000 {
 		compatible = "renesas,em-gio";
 		reg = <0xe0050000 0x2c>, <0xe0050040 0x20>;
-		interrupts = <0 67 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 68 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 0 32>;
 		#gpio-cells = <2>;
@@ -215,8 +216,8 @@
 	gpio1: gpio at e0050080 {
 		compatible = "renesas,em-gio";
 		reg = <0xe0050080 0x2c>, <0xe00500c0 0x20>;
-		interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 70 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 32 32>;
 		#gpio-cells = <2>;
@@ -227,8 +228,8 @@
 	gpio2: gpio at e0050100 {
 		compatible = "renesas,em-gio";
 		reg = <0xe0050100 0x2c>, <0xe0050140 0x20>;
-		interrupts = <0 71 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 72 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 64 32>;
 		#gpio-cells = <2>;
@@ -239,8 +240,8 @@
 	gpio3: gpio at e0050180 {
 		compatible = "renesas,em-gio";
 		reg = <0xe0050180 0x2c>, <0xe00501c0 0x20>;
-		interrupts = <0 73 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 74 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 96 32>;
 		#gpio-cells = <2>;
@@ -251,8 +252,8 @@
 	gpio4: gpio at e0050200 {
 		compatible = "renesas,em-gio";
 		reg = <0xe0050200 0x2c>, <0xe0050240 0x20>;
-		interrupts = <0 75 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 76 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 128 31>;
 		#gpio-cells = <2>;
@@ -266,7 +267,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-emev2";
 		reg = <0xe0070000 0x28>;
-		interrupts = <0 32 IRQ_TYPE_EDGE_RISING>;
+		interrupts = <GIC_SPI 32 IRQ_TYPE_EDGE_RISING>;
 		clocks = <&iic0_sclk>;
 		clock-names = "sclk";
 		status = "disabled";
@@ -277,7 +278,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-emev2";
 		reg = <0xe10a0000 0x28>;
-		interrupts = <0 33 IRQ_TYPE_EDGE_RISING>;
+		interrupts = <GIC_SPI 33 IRQ_TYPE_EDGE_RISING>;
 		clocks = <&iic1_sclk>;
 		clock-names = "sclk";
 		status = "disabled";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:36 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:36 +0100
Subject: [PATCH 42/70] ARM: dts: r8a7779: Add SCIF fallback compatibility
 strings
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <2add0b94bb9db2ba387108461e432de339eb2608.1454595846.git.horms+renesas@verge.net.au>

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

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779.dtsi | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 93f3fdf95e31..1671839f55a6 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -211,7 +211,8 @@
 	};
 
 	scif0: serial at ffe40000 {
-		compatible = "renesas,scif-r8a7779", "renesas,scif";
+		compatible = "renesas,scif-r8a7779", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe40000 0x100>;
 		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF0>;
@@ -221,7 +222,8 @@
 	};
 
 	scif1: serial at ffe41000 {
-		compatible = "renesas,scif-r8a7779", "renesas,scif";
+		compatible = "renesas,scif-r8a7779", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe41000 0x100>;
 		interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF1>;
@@ -231,7 +233,8 @@
 	};
 
 	scif2: serial at ffe42000 {
-		compatible = "renesas,scif-r8a7779", "renesas,scif";
+		compatible = "renesas,scif-r8a7779", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe42000 0x100>;
 		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF2>;
@@ -241,7 +244,8 @@
 	};
 
 	scif3: serial at ffe43000 {
-		compatible = "renesas,scif-r8a7779", "renesas,scif";
+		compatible = "renesas,scif-r8a7779", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe43000 0x100>;
 		interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF3>;
@@ -251,7 +255,8 @@
 	};
 
 	scif4: serial at ffe44000 {
-		compatible = "renesas,scif-r8a7779", "renesas,scif";
+		compatible = "renesas,scif-r8a7779", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe44000 0x100>;
 		interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF4>;
@@ -261,7 +266,8 @@
 	};
 
 	scif5: serial at ffe45000 {
-		compatible = "renesas,scif-r8a7779", "renesas,scif";
+		compatible = "renesas,scif-r8a7779", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe45000 0x100>;
 		interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF5>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:39 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:39 +0100
Subject: [PATCH 45/70] ARM: dts: r8a7793: Add SCIF fallback compatibility
 strings
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <02e010e8338c99eb0a8e89a072ca3f7e670aca64.1454595846.git.horms+renesas@verge.net.au>

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

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 6817f14314e2..b49f9271ceb3 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -479,7 +479,8 @@
 	};
 
 	scifa0: serial at e6c40000 {
-		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7793",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA0>;
@@ -491,7 +492,8 @@
 	};
 
 	scifa1: serial at e6c50000 {
-		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7793",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA1>;
@@ -503,7 +505,8 @@
 	};
 
 	scifa2: serial at e6c60000 {
-		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7793",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA2>;
@@ -515,7 +518,8 @@
 	};
 
 	scifa3: serial at e6c70000 {
-		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7793",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c70000 0 64>;
 		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA3>;
@@ -527,7 +531,8 @@
 	};
 
 	scifa4: serial at e6c78000 {
-		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7793",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c78000 0 64>;
 		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA4>;
@@ -539,7 +544,8 @@
 	};
 
 	scifa5: serial at e6c80000 {
-		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7793",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c80000 0 64>;
 		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA5>;
@@ -551,7 +557,8 @@
 	};
 
 	scifb0: serial at e6c20000 {
-		compatible = "renesas,scifb-r8a7793", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7793",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB0>;
@@ -563,7 +570,8 @@
 	};
 
 	scifb1: serial at e6c30000 {
-		compatible = "renesas,scifb-r8a7793", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7793",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB1>;
@@ -575,7 +583,8 @@
 	};
 
 	scifb2: serial at e6ce0000 {
-		compatible = "renesas,scifb-r8a7793", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7793",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB2>;
@@ -587,7 +596,8 @@
 	};
 
 	scif0: serial at e6e60000 {
-		compatible = "renesas,scif-r8a7793", "renesas,scif";
+		compatible = "renesas,scif-r8a7793", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF0>;
@@ -599,7 +609,8 @@
 	};
 
 	scif1: serial at e6e68000 {
-		compatible = "renesas,scif-r8a7793", "renesas,scif";
+		compatible = "renesas,scif-r8a7793", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF1>;
@@ -611,7 +622,8 @@
 	};
 
 	scif2: serial at e6e58000 {
-		compatible = "renesas,scif-r8a7793", "renesas,scif";
+		compatible = "renesas,scif-r8a7793", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF2>;
@@ -623,7 +635,8 @@
 	};
 
 	scif3: serial at e6ea8000 {
-		compatible = "renesas,scif-r8a7793", "renesas,scif";
+		compatible = "renesas,scif-r8a7793", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF3>;
@@ -635,7 +648,8 @@
 	};
 
 	scif4: serial at e6ee0000 {
-		compatible = "renesas,scif-r8a7793", "renesas,scif";
+		compatible = "renesas,scif-r8a7793", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF4>;
@@ -647,7 +661,8 @@
 	};
 
 	scif5: serial at e6ee8000 {
-		compatible = "renesas,scif-r8a7793", "renesas,scif";
+		compatible = "renesas,scif-r8a7793", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF5>;
@@ -659,7 +674,8 @@
 	};
 
 	hscif0: serial at e62c0000 {
-		compatible = "renesas,hscif-r8a7793", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7793",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF0>;
@@ -671,7 +687,8 @@
 	};
 
 	hscif1: serial at e62c8000 {
-		compatible = "renesas,hscif-r8a7793", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7793",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF1>;
@@ -683,7 +700,8 @@
 	};
 
 	hscif2: serial at e62d0000 {
-		compatible = "renesas,hscif-r8a7793", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7793",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF2>;
-- 
2.7.0.rc3.207.g0ac5344



From helgaas at kernel.org  Thu Feb  4 06:51:48 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Thu, 4 Feb 2016 08:51:48 -0600
Subject: [PATCH V2 5/5] Microblaze: Modifying microblaze PCI subsytem to
 support  generic Xilinx  AXI PCIe Host Bridge IP driver
In-Reply-To: <8520D5D51A55D047800579B0941471982587F199@XAP-PVEXMBX01.xlnx.xilinx.com>
References: <1452620173-4905-1-git-send-email-bharatku@xilinx.com>
 <1452620173-4905-6-git-send-email-bharatku@xilinx.com>
 <20160203163207.GC32546@localhost>
 <20160203163805.GA6112@localhost>
 <8520D5D51A55D047800579B0941471982587F199@XAP-PVEXMBX01.xlnx.xilinx.com>
Message-ID: <20160204145148.GA26361@localhost>

On Thu, Feb 04, 2016 at 05:49:20AM +0000, Bharat Kumar Gogada wrote:
> > Subject: Re: [PATCH V2 5/5] Microblaze: Modifying microblaze PCI subsytem
> > to support generic Xilinx AXI PCIe Host Bridge IP driver
> > 
> > [+cc Ben for real this time]
> > 
> > On Wed, Feb 03, 2016 at 10:32:07AM -0600, Bjorn Helgaas wrote:
> > > [+cc Ben, pcibios_get_phb_of_node() question]
> > >
> > > On Tue, Jan 12, 2016 at 11:06:13PM +0530, Bharat Kumar Gogada wrote:
> > > > This patch does required modifications to microblaze PCI subsystem,
> > > > to work with generic driver (drivers/pci/host/pcie-xilinx.c) on
> > > > Microblaze and Zynq.
> > > >
> > > > Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> > > > Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com> ...
> > >
> > > >  resource_size_t pcibios_align_resource(void *data, const struct resource
> > *res,
> > > >  				resource_size_t size, resource_size_t align)  {
> > > > -	struct pci_dev *dev = data;
> > > >  	resource_size_t start = res->start;
> > > >
> > > > -	if (res->flags & IORESOURCE_IO) {
> > > > -		if (skip_isa_ioresource_align(dev))
> > > > -			return start;
> > > > -		if (start & 0x300)
> > > > -			start = (start + 0x3ff) & ~0x3ff;
> > > > -	}
> > > > -
> > > >  	return start;
> > >
> > > "return res->start;" is sufficient; no need for a temporary variable.
> > >
> Agreed will address in next patch.
> > > >  }
> > > >  EXPORT_SYMBOL(pcibios_align_resource);
> > > >
> > > > +int pcibios_add_device(struct pci_dev *dev) {
> > > > +	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > > > +
> > > > +	return 0;
> > > > +}
> > > > +EXPORT_SYMBOL(pcibios_add_device);
> > > > +
> > > >  /*
> > > >   * Reparent resource children of pr that conflict with res
> > > >   * under res, and make res replace those children.
> > > > @@ -1335,9 +1308,21 @@ static void
> > > > pcibios_setup_phb_resources(struct pci_controller *hose,
> > > >
> > > >  struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)  {
> > > > -	struct pci_controller *hose = bus->sysdata;
> > > > +	struct device_node *np;
> > > > +
> > > > +	for_each_node_by_type(np, "pci") {
> > > > +		const void *prop;
> > > > +		unsigned int bus_min;
> > > > +
> > > > +		prop = of_get_property(np, "bus-range", NULL);
> > > > +		if (!prop)
> > > > +			continue;
> > > > +		bus_min = be32_to_cpup(prop);
> > > > +		if (bus->number == bus_min)
> > > > +			return np;
> > > > +	}
> > > >
> > > > -	return of_node_get(hose->dn);
> > > > +	return NULL;
> > >
> > > Hmmm.  The old microblaze code ("return of_node_get(hose->dn);") is
> > > basically the same as the mips and powerpc versions.  The new code is
> > > basically the same as the x86 version.
> > >
> > > I like the generic weak version in drivers/pci/of.c because it doesn't
> > > use any arch-specific data, and it looks like if we just set the
> > > struct device.of_node members correctly, everything should Just Work.
> > >
> > > But Ben added both the generic and the x86 versions the same day, so
> > > there must be some complication:
> > >
> > >   98d9f30c820d ("pci/of: Match PCI devices to OF nodes dynamically")
> > >   3d5fe5a65af9 ("x86/devicetree: Use generic PCI <-> OF matching")
> > >
> > > So I guess my question is, why do we need a microblaze-specific
> > > version at all?
> > >
> I did not notice the weak version in /pci/of.c, I have tested with
> weak version also and it is working.  We might not need this
> microblaze specific version, but will wait for ben's reply.  

If the generic version works, and you don't need the microblaze-
specific version, just remove it and we'll get this wrapped up.  No
need to wait for Ben.

Bjorn


From horms+renesas at verge.net.au  Thu Feb  4 06:29:38 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:38 +0100
Subject: [PATCH 44/70] ARM: dts: r8a7791: Add SCIF fallback compatibility
 strings
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <012e207e94f85ae891e5e1ff5dcff09f5a012f16.1454595846.git.horms+renesas@verge.net.au>

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

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791.dtsi | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 6b3b02c0c58a..e7537ba68b5e 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -564,7 +564,8 @@
 	};
 
 	scifa0: serial at e6c40000 {
-		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7791",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA0>;
@@ -576,7 +577,8 @@
 	};
 
 	scifa1: serial at e6c50000 {
-		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7791",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA1>;
@@ -588,7 +590,8 @@
 	};
 
 	scifa2: serial at e6c60000 {
-		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7791",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA2>;
@@ -600,7 +603,8 @@
 	};
 
 	scifa3: serial at e6c70000 {
-		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7791",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c70000 0 64>;
 		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA3>;
@@ -612,7 +616,8 @@
 	};
 
 	scifa4: serial at e6c78000 {
-		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7791",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c78000 0 64>;
 		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA4>;
@@ -624,7 +629,8 @@
 	};
 
 	scifa5: serial at e6c80000 {
-		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7791",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c80000 0 64>;
 		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA5>;
@@ -636,7 +642,8 @@
 	};
 
 	scifb0: serial at e6c20000 {
-		compatible = "renesas,scifb-r8a7791", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7791",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB0>;
@@ -648,7 +655,8 @@
 	};
 
 	scifb1: serial at e6c30000 {
-		compatible = "renesas,scifb-r8a7791", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7791",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB1>;
@@ -660,7 +668,8 @@
 	};
 
 	scifb2: serial at e6ce0000 {
-		compatible = "renesas,scifb-r8a7791", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7791",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB2>;
@@ -672,7 +681,8 @@
 	};
 
 	scif0: serial at e6e60000 {
-		compatible = "renesas,scif-r8a7791", "renesas,scif";
+		compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF0>;
@@ -684,7 +694,8 @@
 	};
 
 	scif1: serial at e6e68000 {
-		compatible = "renesas,scif-r8a7791", "renesas,scif";
+		compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF1>;
@@ -696,7 +707,8 @@
 	};
 
 	scif2: serial at e6e58000 {
-		compatible = "renesas,scif-r8a7791", "renesas,scif";
+		compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF2>;
@@ -708,7 +720,8 @@
 	};
 
 	scif3: serial at e6ea8000 {
-		compatible = "renesas,scif-r8a7791", "renesas,scif";
+		compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF3>;
@@ -720,7 +733,8 @@
 	};
 
 	scif4: serial at e6ee0000 {
-		compatible = "renesas,scif-r8a7791", "renesas,scif";
+		compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF4>;
@@ -732,7 +746,8 @@
 	};
 
 	scif5: serial at e6ee8000 {
-		compatible = "renesas,scif-r8a7791", "renesas,scif";
+		compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF5>;
@@ -744,7 +759,8 @@
 	};
 
 	hscif0: serial at e62c0000 {
-		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7791",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF0>;
@@ -756,7 +772,8 @@
 	};
 
 	hscif1: serial at e62c8000 {
-		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7791",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF1>;
@@ -768,7 +785,8 @@
 	};
 
 	hscif2: serial at e62d0000 {
-		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7791",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF2>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:37 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:37 +0100
Subject: [PATCH 43/70] ARM: dts: r8a7790: Add SCIF fallback compatibility
 strings
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <945d876f92e8ec1e8a87b97b13a65379c78edea3.1454595846.git.horms+renesas@verge.net.au>

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

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 30 ++++++++++++++++++++----------
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index cc7eccf0ada7..1d94dfd53141 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -585,7 +585,8 @@
 	};
 
 	scifa0: serial at e6c40000 {
-		compatible = "renesas,scifa-r8a7790", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7790",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA0>;
@@ -597,7 +598,8 @@
 	};
 
 	scifa1: serial at e6c50000 {
-		compatible = "renesas,scifa-r8a7790", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7790",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA1>;
@@ -609,7 +611,8 @@
 	};
 
 	scifa2: serial at e6c60000 {
-		compatible = "renesas,scifa-r8a7790", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7790",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA2>;
@@ -621,7 +624,8 @@
 	};
 
 	scifb0: serial at e6c20000 {
-		compatible = "renesas,scifb-r8a7790", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7790",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB0>;
@@ -633,7 +637,8 @@
 	};
 
 	scifb1: serial at e6c30000 {
-		compatible = "renesas,scifb-r8a7790", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7790",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB1>;
@@ -645,7 +650,8 @@
 	};
 
 	scifb2: serial at e6ce0000 {
-		compatible = "renesas,scifb-r8a7790", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7790",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB2>;
@@ -657,7 +663,8 @@
 	};
 
 	scif0: serial at e6e60000 {
-		compatible = "renesas,scif-r8a7790", "renesas,scif";
+		compatible = "renesas,scif-r8a7790", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_SCIF0>;
@@ -669,7 +676,8 @@
 	};
 
 	scif1: serial at e6e68000 {
-		compatible = "renesas,scif-r8a7790", "renesas,scif";
+		compatible = "renesas,scif-r8a7790", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_SCIF1>;
@@ -681,7 +689,8 @@
 	};
 
 	hscif0: serial at e62c0000 {
-		compatible = "renesas,hscif-r8a7790", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7790",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSCIF0>;
@@ -693,7 +702,8 @@
 	};
 
 	hscif1: serial at e62c8000 {
-		compatible = "renesas,hscif-r8a7790", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7790",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSCIF1>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:35 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:35 +0100
Subject: [PATCH 41/70] ARM: dts: r8a7778: Add SCIF fallback compatibility
 strings
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <53149a68df5ef39cebce5dae7344b3f59f3df13c.1454595846.git.horms+renesas@verge.net.au>

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

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7778.dtsi | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index fc5e7243467a..8ea1792c5146 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -297,7 +297,8 @@
 	};
 
 	scif0: serial at ffe40000 {
-		compatible = "renesas,scif-r8a7778", "renesas,scif";
+		compatible = "renesas,scif-r8a7778", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe40000 0x100>;
 		interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF0>;
@@ -307,7 +308,8 @@
 	};
 
 	scif1: serial at ffe41000 {
-		compatible = "renesas,scif-r8a7778", "renesas,scif";
+		compatible = "renesas,scif-r8a7778", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe41000 0x100>;
 		interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF1>;
@@ -317,7 +319,8 @@
 	};
 
 	scif2: serial at ffe42000 {
-		compatible = "renesas,scif-r8a7778", "renesas,scif";
+		compatible = "renesas,scif-r8a7778", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe42000 0x100>;
 		interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF2>;
@@ -327,7 +330,8 @@
 	};
 
 	scif3: serial at ffe43000 {
-		compatible = "renesas,scif-r8a7778", "renesas,scif";
+		compatible = "renesas,scif-r8a7778", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe43000 0x100>;
 		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF3>;
@@ -337,7 +341,8 @@
 	};
 
 	scif4: serial at ffe44000 {
-		compatible = "renesas,scif-r8a7778", "renesas,scif";
+		compatible = "renesas,scif-r8a7778", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe44000 0x100>;
 		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF4>;
@@ -347,7 +352,8 @@
 	};
 
 	scif5: serial at ffe45000 {
-		compatible = "renesas,scif-r8a7778", "renesas,scif";
+		compatible = "renesas,scif-r8a7778", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe45000 0x100>;
 		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF5>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:40 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:40 +0100
Subject: [PATCH 46/70] ARM: dts: r8a7794: Add SCIF fallback compatibility
 strings
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <c72a339364c00477a9e314fc2f929782bb296827.1454595846.git.horms+renesas@verge.net.au>

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

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794.dtsi | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 21be4bdc4001..a49bf303a02d 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -282,7 +282,8 @@
 	};
 
 	scifa0: serial at e6c40000 {
-		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7794",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA0>;
@@ -294,7 +295,8 @@
 	};
 
 	scifa1: serial at e6c50000 {
-		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7794",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA1>;
@@ -306,7 +308,8 @@
 	};
 
 	scifa2: serial at e6c60000 {
-		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7794",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA2>;
@@ -318,7 +321,8 @@
 	};
 
 	scifa3: serial at e6c70000 {
-		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7794",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c70000 0 64>;
 		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA3>;
@@ -330,7 +334,8 @@
 	};
 
 	scifa4: serial at e6c78000 {
-		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7794",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c78000 0 64>;
 		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA4>;
@@ -342,7 +347,8 @@
 	};
 
 	scifa5: serial at e6c80000 {
-		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7794",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c80000 0 64>;
 		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA5>;
@@ -354,7 +360,8 @@
 	};
 
 	scifb0: serial at e6c20000 {
-		compatible = "renesas,scifb-r8a7794", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7794",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB0>;
@@ -366,7 +373,8 @@
 	};
 
 	scifb1: serial at e6c30000 {
-		compatible = "renesas,scifb-r8a7794", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7794",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB1>;
@@ -378,7 +386,8 @@
 	};
 
 	scifb2: serial at e6ce0000 {
-		compatible = "renesas,scifb-r8a7794", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7794",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB2>;
@@ -390,7 +399,8 @@
 	};
 
 	scif0: serial at e6e60000 {
-		compatible = "renesas,scif-r8a7794", "renesas,scif";
+		compatible = "renesas,scif-r8a7794", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF0>;
@@ -402,7 +412,8 @@
 	};
 
 	scif1: serial at e6e68000 {
-		compatible = "renesas,scif-r8a7794", "renesas,scif";
+		compatible = "renesas,scif-r8a7794", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF1>;
@@ -414,7 +425,8 @@
 	};
 
 	scif2: serial at e6e58000 {
-		compatible = "renesas,scif-r8a7794", "renesas,scif";
+		compatible = "renesas,scif-r8a7794", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF2>;
@@ -426,7 +438,8 @@
 	};
 
 	scif3: serial at e6ea8000 {
-		compatible = "renesas,scif-r8a7794", "renesas,scif";
+		compatible = "renesas,scif-r8a7794", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF3>;
@@ -438,7 +451,8 @@
 	};
 
 	scif4: serial at e6ee0000 {
-		compatible = "renesas,scif-r8a7794", "renesas,scif";
+		compatible = "renesas,scif-r8a7794", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF4>;
@@ -450,7 +464,8 @@
 	};
 
 	scif5: serial at e6ee8000 {
-		compatible = "renesas,scif-r8a7794", "renesas,scif";
+		compatible = "renesas,scif-r8a7794", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF5>;
@@ -462,7 +477,8 @@
 	};
 
 	hscif0: serial at e62c0000 {
-		compatible = "renesas,hscif-r8a7794", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7794",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF0>;
@@ -474,7 +490,8 @@
 	};
 
 	hscif1: serial at e62c8000 {
-		compatible = "renesas,hscif-r8a7794", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7794",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF1>;
@@ -486,7 +503,8 @@
 	};
 
 	hscif2: serial at e62d0000 {
-		compatible = "renesas,hscif-r8a7794", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7794",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF2>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:33 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:33 +0100
Subject: [PATCH 39/70] ARM: dts: sh73a0: use GIC_* defines
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <a51b6c7fdfc040136c34a69564ba42c71287cfd3.1454595846.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in sh73a0 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/sh73a0.dtsi | 168 +++++++++++++++++++++---------------------
 1 file changed, 84 insertions(+), 84 deletions(-)

diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index 3a6056f9f0d2..453280c41d27 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -58,7 +58,7 @@
 	L2: cache-controller {
 		compatible = "arm,pl310-cache";
 		reg = <0xf0100000 0x1000>;
-		interrupts = <0 44 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
 		power-domains = <&pd_a3sm>;
 		arm,data-latency = <3 3 3>;
 		arm,tag-latency = <2 2 2>;
@@ -70,8 +70,8 @@
 	sbsc2: memory-controller at fb400000 {
 		compatible = "renesas,sbsc-sh73a0";
 		reg = <0xfb400000 0x400>;
-		interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 38 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "sec", "temp";
 		power-domains = <&pd_a4bc1>;
 	};
@@ -79,22 +79,22 @@
 	sbsc1: memory-controller at fe400000 {
 		compatible = "renesas,sbsc-sh73a0";
 		reg = <0xfe400000 0x400>;
-		interrupts = <0 35 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 36 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "sec", "temp";
 		power-domains = <&pd_a4bc0>;
 	};
 
 	pmu {
 		compatible = "arm,cortex-a9-pmu";
-		interrupts = <0 55 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 56 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
 	};
 
 	cmt1: timer at e6138000 {
 		compatible = "renesas,cmt-48-sh73a0", "renesas,cmt-48";
 		reg = <0xe6138000 0x200>;
-		interrupts = <0 65 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_CMT1>;
 		clock-names = "fck";
 		power-domains = <&pd_c5>;
@@ -113,14 +113,14 @@
 			<0xe6900020 1>,
 			<0xe6900040 1>,
 			<0xe6900060 1>;
-		interrupts = <0 1 IRQ_TYPE_LEVEL_HIGH
-			      0 2 IRQ_TYPE_LEVEL_HIGH
-			      0 3 IRQ_TYPE_LEVEL_HIGH
-			      0 4 IRQ_TYPE_LEVEL_HIGH
-			      0 5 IRQ_TYPE_LEVEL_HIGH
-			      0 6 IRQ_TYPE_LEVEL_HIGH
-			      0 7 IRQ_TYPE_LEVEL_HIGH
-			      0 8 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks SH73A0_CLK_INTCA0>;
 		power-domains = <&pd_a4s>;
 		control-parent;
@@ -135,14 +135,14 @@
 			<0xe6900024 1>,
 			<0xe6900044 1>,
 			<0xe6900064 1>;
-		interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH
-			      0 10 IRQ_TYPE_LEVEL_HIGH
-			      0 11 IRQ_TYPE_LEVEL_HIGH
-			      0 12 IRQ_TYPE_LEVEL_HIGH
-			      0 13 IRQ_TYPE_LEVEL_HIGH
-			      0 14 IRQ_TYPE_LEVEL_HIGH
-			      0 15 IRQ_TYPE_LEVEL_HIGH
-			      0 16 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks SH73A0_CLK_INTCA0>;
 		power-domains = <&pd_a4s>;
 		control-parent;
@@ -157,14 +157,14 @@
 			<0xe6900028 1>,
 			<0xe6900048 1>,
 			<0xe6900068 1>;
-		interrupts = <0 17 IRQ_TYPE_LEVEL_HIGH
-			      0 18 IRQ_TYPE_LEVEL_HIGH
-			      0 19 IRQ_TYPE_LEVEL_HIGH
-			      0 20 IRQ_TYPE_LEVEL_HIGH
-			      0 21 IRQ_TYPE_LEVEL_HIGH
-			      0 22 IRQ_TYPE_LEVEL_HIGH
-			      0 23 IRQ_TYPE_LEVEL_HIGH
-			      0 24 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks SH73A0_CLK_INTCA0>;
 		power-domains = <&pd_a4s>;
 		control-parent;
@@ -179,14 +179,14 @@
 			<0xe690002c 1>,
 			<0xe690004c 1>,
 			<0xe690006c 1>;
-		interrupts = <0 25 IRQ_TYPE_LEVEL_HIGH
-			      0 26 IRQ_TYPE_LEVEL_HIGH
-			      0 27 IRQ_TYPE_LEVEL_HIGH
-			      0 28 IRQ_TYPE_LEVEL_HIGH
-			      0 29 IRQ_TYPE_LEVEL_HIGH
-			      0 30 IRQ_TYPE_LEVEL_HIGH
-			      0 31 IRQ_TYPE_LEVEL_HIGH
-			      0 32 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks SH73A0_CLK_INTCA0>;
 		power-domains = <&pd_a4s>;
 		control-parent;
@@ -197,10 +197,10 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-sh73a0", "renesas,rmobile-iic";
 		reg = <0xe6820000 0x425>;
-		interrupts = <0 167 IRQ_TYPE_LEVEL_HIGH
-			      0 168 IRQ_TYPE_LEVEL_HIGH
-			      0 169 IRQ_TYPE_LEVEL_HIGH
-			      0 170 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks SH73A0_CLK_IIC0>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -211,10 +211,10 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-sh73a0", "renesas,rmobile-iic";
 		reg = <0xe6822000 0x425>;
-		interrupts = <0 51 IRQ_TYPE_LEVEL_HIGH
-			      0 52 IRQ_TYPE_LEVEL_HIGH
-			      0 53 IRQ_TYPE_LEVEL_HIGH
-			      0 54 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_IIC1>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -225,10 +225,10 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-sh73a0", "renesas,rmobile-iic";
 		reg = <0xe6824000 0x425>;
-		interrupts = <0 171 IRQ_TYPE_LEVEL_HIGH
-			      0 172 IRQ_TYPE_LEVEL_HIGH
-			      0 173 IRQ_TYPE_LEVEL_HIGH
-			      0 174 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks SH73A0_CLK_IIC2>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -239,10 +239,10 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-sh73a0", "renesas,rmobile-iic";
 		reg = <0xe6826000 0x425>;
-		interrupts = <0 183 IRQ_TYPE_LEVEL_HIGH
-			      0 184 IRQ_TYPE_LEVEL_HIGH
-			      0 185 IRQ_TYPE_LEVEL_HIGH
-			      0 186 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks SH73A0_CLK_IIC3>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -253,10 +253,10 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-sh73a0", "renesas,rmobile-iic";
 		reg = <0xe6828000 0x425>;
-		interrupts = <0 187 IRQ_TYPE_LEVEL_HIGH
-			      0 188 IRQ_TYPE_LEVEL_HIGH
-			      0 189 IRQ_TYPE_LEVEL_HIGH
-			      0 190 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks SH73A0_CLK_IIC4>;
 		power-domains = <&pd_c5>;
 		status = "disabled";
@@ -265,8 +265,8 @@
 	mmcif: mmc at e6bd0000 {
 		compatible = "renesas,sh-mmcif";
 		reg = <0xe6bd0000 0x100>;
-		interrupts = <0 140 IRQ_TYPE_LEVEL_HIGH
-			      0 141 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_MMCIF0>;
 		power-domains = <&pd_a3sp>;
 		reg-io-width = <4>;
@@ -276,7 +276,7 @@
 	msiof0: spi at e6e20000 {
 		compatible = "renesas,msiof-sh73a0", "renesas,sh-mobile-msiof";
 		reg = <0xe6e20000 0x0064>;
-		interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks SH73A0_CLK_MSIOF0>;
 		power-domains = <&pd_a3sp>;
 		#address-cells = <1>;
@@ -287,7 +287,7 @@
 	msiof1: spi at e6e10000 {
 		compatible = "renesas,msiof-sh73a0", "renesas,sh-mobile-msiof";
 		reg = <0xe6e10000 0x0064>;
-		interrupts = <0 77 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_MSIOF1>;
 		power-domains = <&pd_a3sp>;
 		#address-cells = <1>;
@@ -298,7 +298,7 @@
 	msiof2: spi at e6e00000 {
 		compatible = "renesas,msiof-sh73a0", "renesas,sh-mobile-msiof";
 		reg = <0xe6e00000 0x0064>;
-		interrupts = <0 76 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_MSIOF2>;
 		power-domains = <&pd_a3sp>;
 		#address-cells = <1>;
@@ -309,7 +309,7 @@
 	msiof3: spi at e6c90000 {
 		compatible = "renesas,msiof-sh73a0", "renesas,sh-mobile-msiof";
 		reg = <0xe6c90000 0x0064>;
-		interrupts = <0 59 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_MSIOF3>;
 		power-domains = <&pd_a3sp>;
 		#address-cells = <1>;
@@ -320,9 +320,9 @@
 	sdhi0: sd at ee100000 {
 		compatible = "renesas,sdhi-sh73a0";
 		reg = <0xee100000 0x100>;
-		interrupts = <0 83 IRQ_TYPE_LEVEL_HIGH
-			      0 84 IRQ_TYPE_LEVEL_HIGH
-			      0 85 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_SDHI0>;
 		power-domains = <&pd_a3sp>;
 		cap-sd-highspeed;
@@ -333,8 +333,8 @@
 	sdhi1: sd at ee120000 {
 		compatible = "renesas,sdhi-sh73a0";
 		reg = <0xee120000 0x100>;
-		interrupts = <0 88 IRQ_TYPE_LEVEL_HIGH
-			      0 89 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_SDHI1>;
 		power-domains = <&pd_a3sp>;
 		toshiba,mmc-wrprotect-disable;
@@ -345,8 +345,8 @@
 	sdhi2: sd at ee140000 {
 		compatible = "renesas,sdhi-sh73a0";
 		reg = <0xee140000 0x100>;
-		interrupts = <0 104 IRQ_TYPE_LEVEL_HIGH
-			      0 105 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_SDHI2>;
 		power-domains = <&pd_a3sp>;
 		toshiba,mmc-wrprotect-disable;
@@ -357,7 +357,7 @@
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6c40000 0x100>;
-		interrupts = <0 72 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA0>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -367,7 +367,7 @@
 	scifa1: serial at e6c50000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6c50000 0x100>;
-		interrupts = <0 73 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA1>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -377,7 +377,7 @@
 	scifa2: serial at e6c60000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6c60000 0x100>;
-		interrupts = <0 74 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA2>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -387,7 +387,7 @@
 	scifa3: serial at e6c70000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6c70000 0x100>;
-		interrupts = <0 75 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA3>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -397,7 +397,7 @@
 	scifa4: serial at e6c80000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6c80000 0x100>;
-		interrupts = <0 78 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA4>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -407,7 +407,7 @@
 	scifa5: serial at e6cb0000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6cb0000 0x100>;
-		interrupts = <0 79 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA5>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -417,7 +417,7 @@
 	scifa6: serial at e6cc0000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6cc0000 0x100>;
-		interrupts = <0 156 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_SCIFA6>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -427,7 +427,7 @@
 	scifa7: serial at e6cd0000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6cd0000 0x100>;
-		interrupts = <0 143 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA7>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -437,7 +437,7 @@
 	scifb: serial at e6c30000 {
 		compatible = "renesas,scifb-sh73a0", "renesas,scifb";
 		reg = <0xe6c30000 0x100>;
-		interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFB>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -579,7 +579,7 @@
 		#sound-dai-cells = <1>;
 		compatible = "renesas,fsi2-sh73a0", "renesas,sh_fsi2";
 		reg = <0xec230000 0x400>;
-		interrupts = <0 146 0x4>;
+		interrupts = <GIC_SPI 146 0x4>;
 		power-domains = <&pd_a4mp>;
 		status = "disabled";
 	};
@@ -591,7 +591,7 @@
 		#size-cells = <1>;
 		ranges = <0 0 0x20000000>;
 		reg = <0xfec10000 0x400>;
-		interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&zb_clk>;
 		power-domains = <&pd_a4s>;
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:41 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:41 +0100
Subject: [PATCH 47/70] ARM: dts: sh73a0: Rename the serial port clock to fck
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <63ec4b72fa52fef9caf709000b53e0714453d912.1454595846.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/sh73a0.dtsi | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index 453280c41d27..bf825ca4f6f7 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -359,7 +359,7 @@
 		reg = <0xe6c40000 0x100>;
 		interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -369,7 +369,7 @@
 		reg = <0xe6c50000 0x100>;
 		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -379,7 +379,7 @@
 		reg = <0xe6c60000 0x100>;
 		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -389,7 +389,7 @@
 		reg = <0xe6c70000 0x100>;
 		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -399,7 +399,7 @@
 		reg = <0xe6c80000 0x100>;
 		interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -409,7 +409,7 @@
 		reg = <0xe6cb0000 0x100>;
 		interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -419,7 +419,7 @@
 		reg = <0xe6cc0000 0x100>;
 		interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_SCIFA6>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -429,7 +429,7 @@
 		reg = <0xe6cd0000 0x100>;
 		interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA7>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -439,7 +439,7 @@
 		reg = <0xe6c30000 0x100>;
 		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFB>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:32 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:32 +0100
Subject: [PATCH 38/70] ARM: dts: r7s72100: use GIC_* defines
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <ce06e3e573733f8d2618b3ad496038197b86623e.1454595846.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r7s72100 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r7s72100.dtsi | 161 ++++++++++++++++++++--------------------
 1 file changed, 81 insertions(+), 80 deletions(-)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 4657d7fb5bce..a5938c72d5bd 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -10,6 +10,7 @@
  */
 
 #include <dt-bindings/clock/r7s72100-clock.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/interrupt-controller/irq.h>
 
 / {
@@ -152,10 +153,10 @@
 	scif0: serial at e8007000 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe8007000 64>;
-		interrupts = <0 190 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 191 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 192 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 189 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF0>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -165,10 +166,10 @@
 	scif1: serial at e8007800 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe8007800 64>;
-		interrupts = <0 194 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 195 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 196 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 193 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF1>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -178,10 +179,10 @@
 	scif2: serial at e8008000 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe8008000 64>;
-		interrupts = <0 198 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 199 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 200 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 197 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF2>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -191,10 +192,10 @@
 	scif3: serial at e8008800 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe8008800 64>;
-		interrupts = <0 202 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 203 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 204 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 201 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF3>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -204,10 +205,10 @@
 	scif4: serial at e8009000 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe8009000 64>;
-		interrupts = <0 206 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 207 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 208 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 205 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF4>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -217,10 +218,10 @@
 	scif5: serial at e8009800 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe8009800 64>;
-		interrupts = <0 210 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 211 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 212 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 209 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF5>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -230,10 +231,10 @@
 	scif6: serial at e800a000 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe800a000 64>;
-		interrupts = <0 214 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 215 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 216 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 213 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF6>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -243,10 +244,10 @@
 	scif7: serial at e800a800 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe800a800 64>;
-		interrupts = <0 218 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 219 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 220 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 217 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF7>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -256,9 +257,9 @@
 	spi0: spi at e800c800 {
 		compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
 		reg = <0xe800c800 0x24>;
-		interrupts = <0 238 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 239 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 240 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 238 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 239 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error", "rx", "tx";
 		clocks = <&mstp10_clks R7S72100_CLK_SPI0>;
 		power-domains = <&cpg_clocks>;
@@ -271,9 +272,9 @@
 	spi1: spi at e800d000 {
 		compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
 		reg = <0xe800d000 0x24>;
-		interrupts = <0 241 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 242 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 243 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 241 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 242 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error", "rx", "tx";
 		clocks = <&mstp10_clks R7S72100_CLK_SPI1>;
 		power-domains = <&cpg_clocks>;
@@ -286,9 +287,9 @@
 	spi2: spi at e800d800 {
 		compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
 		reg = <0xe800d800 0x24>;
-		interrupts = <0 244 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 245 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 246 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error", "rx", "tx";
 		clocks = <&mstp10_clks R7S72100_CLK_SPI2>;
 		power-domains = <&cpg_clocks>;
@@ -301,9 +302,9 @@
 	spi3: spi at e800e000 {
 		compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
 		reg = <0xe800e000 0x24>;
-		interrupts = <0 247 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 248 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 249 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 248 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 249 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error", "rx", "tx";
 		clocks = <&mstp10_clks R7S72100_CLK_SPI3>;
 		power-domains = <&cpg_clocks>;
@@ -316,9 +317,9 @@
 	spi4: spi at e800e800 {
 		compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
 		reg = <0xe800e800 0x24>;
-		interrupts = <0 250 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 251 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 252 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 250 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 251 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 252 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error", "rx", "tx";
 		clocks = <&mstp10_clks R7S72100_CLK_SPI4>;
 		power-domains = <&cpg_clocks>;
@@ -342,14 +343,14 @@
 		#size-cells = <0>;
 		compatible = "renesas,riic-r7s72100", "renesas,riic-rz";
 		reg = <0xfcfee000 0x44>;
-		interrupts = <0 157 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 158 IRQ_TYPE_EDGE_RISING>,
-			     <0 159 IRQ_TYPE_EDGE_RISING>,
-			     <0 160 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 161 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 162 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 163 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 164 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 158 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 159 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R7S72100_CLK_I2C0>;
 		clock-frequency = <100000>;
 		power-domains = <&cpg_clocks>;
@@ -361,14 +362,14 @@
 		#size-cells = <0>;
 		compatible = "renesas,riic-r7s72100", "renesas,riic-rz";
 		reg = <0xfcfee400 0x44>;
-		interrupts = <0 165 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 166 IRQ_TYPE_EDGE_RISING>,
-			     <0 167 IRQ_TYPE_EDGE_RISING>,
-			     <0 168 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 169 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 170 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 171 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 172 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 166 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 167 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R7S72100_CLK_I2C1>;
 		clock-frequency = <100000>;
 		power-domains = <&cpg_clocks>;
@@ -380,14 +381,14 @@
 		#size-cells = <0>;
 		compatible = "renesas,riic-r7s72100", "renesas,riic-rz";
 		reg = <0xfcfee800 0x44>;
-		interrupts = <0 173 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 174 IRQ_TYPE_EDGE_RISING>,
-			     <0 175 IRQ_TYPE_EDGE_RISING>,
-			     <0 176 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 177 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 178 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 179 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 180 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 174 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 175 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R7S72100_CLK_I2C2>;
 		clock-frequency = <100000>;
 		power-domains = <&cpg_clocks>;
@@ -399,14 +400,14 @@
 		#size-cells = <0>;
 		compatible = "renesas,riic-r7s72100", "renesas,riic-rz";
 		reg = <0xfcfeec00 0x44>;
-		interrupts = <0 181 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 182 IRQ_TYPE_EDGE_RISING>,
-			     <0 183 IRQ_TYPE_EDGE_RISING>,
-			     <0 184 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 185 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 186 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 187 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 188 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 182 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 183 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R7S72100_CLK_I2C3>;
 		clock-frequency = <100000>;
 		power-domains = <&cpg_clocks>;
@@ -416,7 +417,7 @@
 	mtu2: timer at fcff0000 {
 		compatible = "renesas,mtu2-r7s72100", "renesas,mtu2";
 		reg = <0xfcff0000 0x400>;
-		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "tgi0a";
 		clocks = <&mstp3_clks R7S72100_CLK_MTU2>;
 		clock-names = "fck";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:42 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:42 +0100
Subject: [PATCH 48/70] ARM: dts: r7s72100: Rename the serial port clock to fck
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <6e6c5553b4dbacffb1305db7912510d5e7e5ff99.1454595846.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r7s72100.dtsi | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index a5938c72d5bd..89e46ebef1bc 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -158,7 +158,7 @@
 			     <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -171,7 +171,7 @@
 			     <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -184,7 +184,7 @@
 			     <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -197,7 +197,7 @@
 			     <GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -210,7 +210,7 @@
 			     <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -223,7 +223,7 @@
 			     <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -236,7 +236,7 @@
 			     <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF6>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -249,7 +249,7 @@
 			     <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF7>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:43 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:43 +0100
Subject: [PATCH 49/70] ARM: dts: r8a73a4: Rename the serial port clock to fck
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <55b2a2185f2e0ee4f66554a6744d520a85f72611.1454595846.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a73a4.dtsi | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 64f3efcd7ba5..138414a7d170 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -335,7 +335,7 @@
 		reg = <0 0xe6c20000 0 0x100>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -345,7 +345,7 @@
 		reg = <0 0xe6c30000 0 0x100>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -355,7 +355,7 @@
 		reg = <0 0xe6c40000 0 0x100>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFA0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -365,7 +365,7 @@
 		reg = <0 0xe6c50000 0 0x100>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFA1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -375,7 +375,7 @@
 		reg = <0 0xe6ce0000 0 0x100>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -385,7 +385,7 @@
 		reg = <0 0xe6cf0000 0 0x100>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_c4>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:44 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:44 +0100
Subject: [PATCH 50/70] ARM: dts: r8a7740: Rename the serial port clock to fck
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <13b4c7efe9886e0272789b0795fa0c6df6fc8bb1.1454595846.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7740.dtsi | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 36bcb39cca03..995fbda74b7a 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -214,7 +214,7 @@
 		reg = <0xe6c40000 0x100>;
 		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -224,7 +224,7 @@
 		reg = <0xe6c50000 0x100>;
 		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -234,7 +234,7 @@
 		reg = <0xe6c60000 0x100>;
 		interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -244,7 +244,7 @@
 		reg = <0xe6c70000 0x100>;
 		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -254,7 +254,7 @@
 		reg = <0xe6c80000 0x100>;
 		interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -264,7 +264,7 @@
 		reg = <0xe6cb0000 0x100>;
 		interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -274,7 +274,7 @@
 		reg = <0xe6cc0000 0x100>;
 		interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA6>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -284,7 +284,7 @@
 		reg = <0xe6cd0000 0x100>;
 		interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA7>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -294,7 +294,7 @@
 		reg = <0xe6c30000 0x100>;
 		interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFB>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:45 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:45 +0100
Subject: [PATCH 51/70] ARM: dts: r8a7778: Rename the serial port clock to fck
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <3c185e492b336981aeba53336b1dcb043c3e5ed3.1454595846.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7778.dtsi | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index 8ea1792c5146..50784e2b632d 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -302,7 +302,7 @@
 		reg = <0xffe40000 0x100>;
 		interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -313,7 +313,7 @@
 		reg = <0xffe41000 0x100>;
 		interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -324,7 +324,7 @@
 		reg = <0xffe42000 0x100>;
 		interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -335,7 +335,7 @@
 		reg = <0xffe43000 0x100>;
 		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -346,7 +346,7 @@
 		reg = <0xffe44000 0x100>;
 		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -357,7 +357,7 @@
 		reg = <0xffe45000 0x100>;
 		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From bharat.kumar.gogada at xilinx.com  Thu Feb  4 06:56:29 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Thu, 4 Feb 2016 14:56:29 +0000
Subject: [PATCH V2 5/5] Microblaze: Modifying microblaze PCI subsytem to
 support  generic Xilinx  AXI PCIe Host Bridge IP driver
In-Reply-To: <20160204145148.GA26361@localhost>
References: <1452620173-4905-1-git-send-email-bharatku@xilinx.com>
 <1452620173-4905-6-git-send-email-bharatku@xilinx.com>
 <20160203163207.GC32546@localhost> <20160203163805.GA6112@localhost>
 <8520D5D51A55D047800579B0941471982587F199@XAP-PVEXMBX01.xlnx.xilinx.com>
 <20160204145148.GA26361@localhost>
Message-ID: <8520D5D51A55D047800579B094147198258803F8@XAP-PVEXMBX01.xlnx.xilinx.com>

> Subject: Re: [PATCH V2 5/5] Microblaze: Modifying microblaze PCI subsytem
> to support generic Xilinx AXI PCIe Host Bridge IP driver
> 
> On Thu, Feb 04, 2016 at 05:49:20AM +0000, Bharat Kumar Gogada wrote:
> > > Subject: Re: [PATCH V2 5/5] Microblaze: Modifying microblaze PCI
> > > subsytem to support generic Xilinx AXI PCIe Host Bridge IP driver
> > >
> > > [+cc Ben for real this time]
> > >
> > > On Wed, Feb 03, 2016 at 10:32:07AM -0600, Bjorn Helgaas wrote:
> > > > [+cc Ben, pcibios_get_phb_of_node() question]
> > > >
> > > > On Tue, Jan 12, 2016 at 11:06:13PM +0530, Bharat Kumar Gogada wrote:
> > > > > This patch does required modifications to microblaze PCI
> > > > > subsystem, to work with generic driver
> > > > > (drivers/pci/host/pcie-xilinx.c) on Microblaze and Zynq.
> > > > >
> > > > > Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> > > > > Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com> ...
> > > >
> > > > >  resource_size_t pcibios_align_resource(void *data, const struct
> > > > > resource
> > > *res,
> > > > >  				resource_size_t size, resource_size_t
> align)  {
> > > > > -	struct pci_dev *dev = data;
> > > > >  	resource_size_t start = res->start;
> > > > >
> > > > > -	if (res->flags & IORESOURCE_IO) {
> > > > > -		if (skip_isa_ioresource_align(dev))
> > > > > -			return start;
> > > > > -		if (start & 0x300)
> > > > > -			start = (start + 0x3ff) & ~0x3ff;
> > > > > -	}
> > > > > -
> > > > >  	return start;
> > > >
> > > > "return res->start;" is sufficient; no need for a temporary variable.
> > > >
> > Agreed will address in next patch.
> > > > >  }
> > > > >  EXPORT_SYMBOL(pcibios_align_resource);
> > > > >
> > > > > +int pcibios_add_device(struct pci_dev *dev) {
> > > > > +	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > > > > +
> > > > > +	return 0;
> > > > > +}
> > > > > +EXPORT_SYMBOL(pcibios_add_device);
> > > > > +
> > > > >  /*
> > > > >   * Reparent resource children of pr that conflict with res
> > > > >   * under res, and make res replace those children.
> > > > > @@ -1335,9 +1308,21 @@ static void
> > > > > pcibios_setup_phb_resources(struct pci_controller *hose,
> > > > >
> > > > >  struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)
> {
> > > > > -	struct pci_controller *hose = bus->sysdata;
> > > > > +	struct device_node *np;
> > > > > +
> > > > > +	for_each_node_by_type(np, "pci") {
> > > > > +		const void *prop;
> > > > > +		unsigned int bus_min;
> > > > > +
> > > > > +		prop = of_get_property(np, "bus-range", NULL);
> > > > > +		if (!prop)
> > > > > +			continue;
> > > > > +		bus_min = be32_to_cpup(prop);
> > > > > +		if (bus->number == bus_min)
> > > > > +			return np;
> > > > > +	}
> > > > >
> > > > > -	return of_node_get(hose->dn);
> > > > > +	return NULL;
> > > >
> > > > Hmmm.  The old microblaze code ("return of_node_get(hose->dn);")
> > > > is basically the same as the mips and powerpc versions.  The new
> > > > code is basically the same as the x86 version.
> > > >
> > > > I like the generic weak version in drivers/pci/of.c because it
> > > > doesn't use any arch-specific data, and it looks like if we just
> > > > set the struct device.of_node members correctly, everything should
> Just Work.
> > > >
> > > > But Ben added both the generic and the x86 versions the same day,
> > > > so there must be some complication:
> > > >
> > > >   98d9f30c820d ("pci/of: Match PCI devices to OF nodes dynamically")
> > > >   3d5fe5a65af9 ("x86/devicetree: Use generic PCI <-> OF matching")
> > > >
> > > > So I guess my question is, why do we need a microblaze-specific
> > > > version at all?
> > > >
> > I did not notice the weak version in /pci/of.c, I have tested with
> > weak version also and it is working.  We might not need this
> > microblaze specific version, but will wait for ben's reply.
> 
> If the generic version works, and you don't need the microblaze- specific
> version, just remove it and we'll get this wrapped up.  No need to wait for
> Ben.
>
Ok Bjorn, I will remove it and send next series of patches.

Bharat



From horms+renesas at verge.net.au  Thu Feb  4 06:29:46 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:46 +0100
Subject: [PATCH 52/70] ARM: dts: r8a7779: Rename the serial port clock to fck
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <5336794cb8cc939cdaea5b3f93d5f459994ae0eb.1454595846.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779.dtsi | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 1671839f55a6..8fddfae13865 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -216,7 +216,7 @@
 		reg = <0xffe40000 0x100>;
 		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -227,7 +227,7 @@
 		reg = <0xffe41000 0x100>;
 		interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -238,7 +238,7 @@
 		reg = <0xffe42000 0x100>;
 		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -249,7 +249,7 @@
 		reg = <0xffe43000 0x100>;
 		interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -260,7 +260,7 @@
 		reg = <0xffe44000 0x100>;
 		interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -271,7 +271,7 @@
 		reg = <0xffe45000 0x100>;
 		interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:47 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:47 +0100
Subject: [PATCH 53/70] ARM: dts: r8a7790: Rename the serial port clock to fck
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <e26ccfc3db9237ba65b40ea16a11f79eb6cc6e60.1454595846.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 1d94dfd53141..c5672745a1e5 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -590,7 +590,7 @@
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -603,7 +603,7 @@
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -616,7 +616,7 @@
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -629,7 +629,7 @@
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -642,7 +642,7 @@
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -655,7 +655,7 @@
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -668,7 +668,7 @@
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_SCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -681,7 +681,7 @@
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_SCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -694,7 +694,7 @@
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -707,7 +707,7 @@
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:48 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:48 +0100
Subject: [PATCH 54/70] ARM: dts: r8a7791: Rename the serial port clock to fck
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <23a68279e3d1f6d905e333e7ea2497278579c17c.1454595846.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791.dtsi | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index e7537ba68b5e..194e9464b748 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -569,7 +569,7 @@
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -582,7 +582,7 @@
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -595,7 +595,7 @@
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -608,7 +608,7 @@
 		reg = <0 0xe6c70000 0 64>;
 		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1b>, <&dmac0 0x1c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -621,7 +621,7 @@
 		reg = <0 0xe6c78000 0 64>;
 		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1f>, <&dmac0 0x20>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -634,7 +634,7 @@
 		reg = <0 0xe6c80000 0 64>;
 		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x23>, <&dmac0 0x24>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -647,7 +647,7 @@
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -660,7 +660,7 @@
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -673,7 +673,7 @@
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -686,7 +686,7 @@
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -699,7 +699,7 @@
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -712,7 +712,7 @@
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -725,7 +725,7 @@
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -738,7 +738,7 @@
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -751,7 +751,7 @@
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -764,7 +764,7 @@
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -777,7 +777,7 @@
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -790,7 +790,7 @@
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:49 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:49 +0100
Subject: [PATCH 55/70] ARM: dts: r8a7793: Rename the serial port clock to fck
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <2acab11f53e6b111cbe29082bdf633a9ca48aea4.1454595846.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index b49f9271ceb3..07af584915c6 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -484,7 +484,7 @@
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -497,7 +497,7 @@
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -510,7 +510,7 @@
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -523,7 +523,7 @@
 		reg = <0 0xe6c70000 0 64>;
 		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1b>, <&dmac0 0x1c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -536,7 +536,7 @@
 		reg = <0 0xe6c78000 0 64>;
 		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1f>, <&dmac0 0x20>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -549,7 +549,7 @@
 		reg = <0 0xe6c80000 0 64>;
 		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x23>, <&dmac0 0x24>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -562,7 +562,7 @@
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -575,7 +575,7 @@
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -588,7 +588,7 @@
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -601,7 +601,7 @@
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -614,7 +614,7 @@
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -627,7 +627,7 @@
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -640,7 +640,7 @@
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -653,7 +653,7 @@
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -666,7 +666,7 @@
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -679,7 +679,7 @@
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -692,7 +692,7 @@
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -705,7 +705,7 @@
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:50 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:50 +0100
Subject: [PATCH 56/70] ARM: dts: r8a7794: Rename the serial port clock to fck
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <dd80379542112aad673d8472e4dccb51764cd0dd.1454595846.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794.dtsi | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index a49bf303a02d..b03a77b3d22f 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -287,7 +287,7 @@
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -300,7 +300,7 @@
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -313,7 +313,7 @@
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -326,7 +326,7 @@
 		reg = <0 0xe6c70000 0 64>;
 		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1b>, <&dmac0 0x1c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -339,7 +339,7 @@
 		reg = <0 0xe6c78000 0 64>;
 		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1f>, <&dmac0 0x20>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -352,7 +352,7 @@
 		reg = <0 0xe6c80000 0 64>;
 		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x23>, <&dmac0 0x24>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -365,7 +365,7 @@
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -378,7 +378,7 @@
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -391,7 +391,7 @@
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -404,7 +404,7 @@
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -417,7 +417,7 @@
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -430,7 +430,7 @@
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -443,7 +443,7 @@
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -456,7 +456,7 @@
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -469,7 +469,7 @@
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -482,7 +482,7 @@
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -495,7 +495,7 @@
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -508,7 +508,7 @@
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:51 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:51 +0100
Subject: [PATCH 57/70] ARM: dts: r8a7778: Add BRG support for SCIF
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <226b5b7b11bfd519bcf75df0f5150a97efea512a.1454595846.git.horms+renesas@verge.net.au>

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

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depends on
the actual board.

Add the two optional clock sources (S1 and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF device nodes.

This increases the range and accuracy of supported baud rates on SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7778.dtsi | 39 +++++++++++++++++++++++++++------------
 1 file changed, 27 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index 50784e2b632d..f83a348fc07a 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -301,8 +301,9 @@
 			     "renesas,scif";
 		reg = <0xffe40000 0x100>;
 		interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7778_CLK_SCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7778_CLK_SCIF0>,
+			 <&cpg_clocks R8A7778_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -312,8 +313,9 @@
 			     "renesas,scif";
 		reg = <0xffe41000 0x100>;
 		interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7778_CLK_SCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7778_CLK_SCIF1>,
+			 <&cpg_clocks R8A7778_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -323,8 +325,9 @@
 			     "renesas,scif";
 		reg = <0xffe42000 0x100>;
 		interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7778_CLK_SCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7778_CLK_SCIF2>,
+			 <&cpg_clocks R8A7778_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -334,8 +337,9 @@
 			     "renesas,scif";
 		reg = <0xffe43000 0x100>;
 		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7778_CLK_SCIF3>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7778_CLK_SCIF3>,
+			 <&cpg_clocks R8A7778_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -345,8 +349,9 @@
 			     "renesas,scif";
 		reg = <0xffe44000 0x100>;
 		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7778_CLK_SCIF4>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7778_CLK_SCIF4>,
+			 <&cpg_clocks R8A7778_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -356,8 +361,9 @@
 			     "renesas,scif";
 		reg = <0xffe45000 0x100>;
 		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7778_CLK_SCIF5>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7778_CLK_SCIF5>,
+			 <&cpg_clocks R8A7778_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -444,6 +450,15 @@
 			clock-output-names = "extal";
 		};
 
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+			status = "disabled";
+		};
+
 		/* Special CPG clocks */
 		cpg_clocks: cpg_clocks at ffc80000 {
 			compatible = "renesas,r8a7778-cpg-clocks";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:52 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:52 +0100
Subject: [PATCH 58/70] ARM: dts: r8a7779: Add BRG support for SCIF
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <746a135be6849eb52db2bd6db6e0fa57912c6fd4.1454595846.git.horms+renesas@verge.net.au>

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

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depends on
the actual board.

Add the two optional clock sources (S1 and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF device nodes.

This increases the range and accuracy of supported baud rates on SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779.dtsi | 39 +++++++++++++++++++++++++++------------
 1 file changed, 27 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 8fddfae13865..a0cc08e6295b 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -215,8 +215,9 @@
 			     "renesas,scif";
 		reg = <0xffe40000 0x100>;
 		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7779_CLK_SCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7779_CLK_SCIF0>,
+			 <&cpg_clocks R8A7779_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -226,8 +227,9 @@
 			     "renesas,scif";
 		reg = <0xffe41000 0x100>;
 		interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7779_CLK_SCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7779_CLK_SCIF1>,
+			 <&cpg_clocks R8A7779_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -237,8 +239,9 @@
 			     "renesas,scif";
 		reg = <0xffe42000 0x100>;
 		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7779_CLK_SCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7779_CLK_SCIF2>,
+			 <&cpg_clocks R8A7779_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -248,8 +251,9 @@
 			     "renesas,scif";
 		reg = <0xffe43000 0x100>;
 		interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7779_CLK_SCIF3>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7779_CLK_SCIF3>,
+			 <&cpg_clocks R8A7779_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -259,8 +263,9 @@
 			     "renesas,scif";
 		reg = <0xffe44000 0x100>;
 		interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7779_CLK_SCIF4>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7779_CLK_SCIF4>,
+			 <&cpg_clocks R8A7779_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -270,8 +275,9 @@
 			     "renesas,scif";
 		reg = <0xffe45000 0x100>;
 		interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7779_CLK_SCIF5>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7779_CLK_SCIF5>,
+			 <&cpg_clocks R8A7779_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -447,6 +453,15 @@
 			clock-output-names = "extal";
 		};
 
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+			status = "disabled";
+		};
+
 		/* Special CPG clocks */
 		cpg_clocks: clocks at ffc80000 {
 			compatible = "renesas,r8a7779-cpg-clocks";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:53 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:53 +0100
Subject: [PATCH 59/70] ARM: dts: r8a7790: Add BRG support for (H)SCIF
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <b4c30ea6936303031f5f919e7652d5eaa40388d2.1454595846.git.horms+renesas@verge.net.au>

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

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depends on
the actual board.

Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF and HSCIF device nodes.

This increases the range and accuracy of supported baud rates on
(H)SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 29 +++++++++++++++++++++--------
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index c5672745a1e5..c9583fa6cae7 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -667,8 +667,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7790_CLK_SCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7790_CLK_SCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -680,8 +681,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7790_CLK_SCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7790_CLK_SCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -693,8 +695,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7790_CLK_HSCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7790_CLK_HSCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -706,8 +709,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7790_CLK_HSCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7790_CLK_HSCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -996,6 +1000,15 @@
 			clock-output-names = "audio_clk_c";
 		};
 
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+			status = "disabled";
+		};
+
 		/* External USB clock - can be overridden by the board */
 		usb_extal_clk: usb_extal_clk {
 			compatible = "fixed-clock";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:54 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:54 +0100
Subject: [PATCH 60/70] ARM: dts: r8a7791: Add BRG support for (H)SCIF
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <0702cf94d2d8be4d72f02f3887a495b455888205.1454595846.git.horms+renesas@verge.net.au>

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

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depends on
the actual board.

Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF and HSCIF device nodes.

This increases the range and accuracy of supported baud rates on
(H)SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791.dtsi | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 194e9464b748..14aa62539ff2 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -685,8 +685,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -698,8 +699,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -711,8 +713,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -724,8 +727,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF3>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF3>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -737,8 +741,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF4>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF4>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -750,8 +755,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF5>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF5>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -763,8 +769,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_HSCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_HSCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -776,8 +783,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_HSCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_HSCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -789,8 +797,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_HSCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_HSCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -1049,6 +1058,15 @@
 			status = "disabled";
 		};
 
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+			status = "disabled";
+		};
+
 		/* External USB clock - can be overridden by the board */
 		usb_extal_clk: usb_extal_clk {
 			compatible = "fixed-clock";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:55 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:55 +0100
Subject: [PATCH 61/70] ARM: dts: r8a7793: Add BRG support for SCIF
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <612c0afe452fff4602ecf20e778fe14e0b5d2a85.1454595846.git.horms+renesas@verge.net.au>

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

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depends on
the actual board.

Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF and HSCIF device nodes.

This increases the range and accuracy of supported baud rates on
(H)SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 07af584915c6..45dba1c79a43 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -600,8 +600,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_SCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_SCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -613,8 +614,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_SCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_SCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -626,8 +628,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_SCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_SCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -639,8 +642,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_SCIF3>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_SCIF3>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -652,8 +656,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_SCIF4>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_SCIF4>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -665,8 +670,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_SCIF5>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_SCIF5>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -678,8 +684,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_HSCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_HSCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -691,8 +698,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_HSCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_HSCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -704,8 +712,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_HSCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_HSCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -805,6 +814,15 @@
 			clock-output-names = "audio_clk_c";
 		};
 
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+			status = "disabled";
+		};
+
 		/* Special CPG clocks */
 		cpg_clocks: cpg_clocks at e6150000 {
 			compatible = "renesas,r8a7793-cpg-clocks",
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:56 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:56 +0100
Subject: [PATCH 62/70] ARM: dts: r8a7794: Add BRG support for (H)SCIF
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <2a814aa1dcdc50916c8d7854175a7934e18bb29e.1454595846.git.horms+renesas@verge.net.au>

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

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depends on
the actual board.

Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF and HSCIF device nodes.

This increases the range and accuracy of supported baud rates on
(H)SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794.dtsi | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index b03a77b3d22f..7d4c5597af5b 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -403,8 +403,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_SCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_SCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -416,8 +417,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_SCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_SCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -429,8 +431,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_SCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_SCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -442,8 +445,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_SCIF3>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_SCIF3>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -455,8 +459,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_SCIF4>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_SCIF4>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -468,8 +473,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_SCIF5>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_SCIF5>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -481,8 +487,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_HSCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_HSCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -494,8 +501,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_HSCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_HSCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -507,8 +515,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_HSCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_HSCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -815,6 +824,15 @@
 			clock-output-names = "extal";
 		};
 
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+			status = "disabled";
+		};
+
 		/* Special CPG clocks */
 		cpg_clocks: cpg_clocks at e6150000 {
 			compatible = "renesas,r8a7794-cpg-clocks",
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:57 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:57 +0100
Subject: [PATCH 63/70] ARM: dts: alt: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <4acffec170c09213f78c2fce201212516c447734.1454595846.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794-alt.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
index 773f304d1142..ca9bc4fff287 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -103,6 +103,9 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	du_pins: du {
 		renesas,groups = "du1_rgb666", "du1_sync", "du1_disp", "du1_dotclkout0";
 		renesas,function = "du";
@@ -113,6 +116,11 @@
 		renesas,function = "scif2";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	ether_pins: ether {
 		renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
 		renesas,function = "eth";
@@ -205,6 +213,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &qspi {
 	pinctrl-0 = <&qspi_pins>;
 	pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:30:01 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:30:01 +0100
Subject: [PATCH 67/70] ARM: dts: lager: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <c538d4ca3722cb0640d3f67724128ac635f3d785.1454595846.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790-lager.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 052dcee4790d..cdc0414f5f07 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -291,6 +291,9 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	du_pins: du {
 		renesas,groups = "du_rgb666", "du_sync_1", "du_clk_out_0";
 		renesas,function = "du";
@@ -301,6 +304,11 @@
 		renesas,function = "scif0";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	ether_pins: ether {
 		renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
 		renesas,function = "eth";
@@ -485,6 +493,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &msiof1 {
 	pinctrl-0 = <&msiof1_pins>;
 	pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:30:02 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:30:02 +0100
Subject: [PATCH 68/70] ARM: dts: marzen: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <4603bc2b08134ad2257b1d968c9293bcc07a8bb9.1454595846.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779-marzen.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7779-marzen.dts b/arch/arm/boot/dts/r8a7779-marzen.dts
index fe396c8d58db..e111d35d02ae 100644
--- a/arch/arm/boot/dts/r8a7779-marzen.dts
+++ b/arch/arm/boot/dts/r8a7779-marzen.dts
@@ -165,6 +165,9 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	du_pins: du {
 		du0 {
 			renesas,groups = "du0_rgb888", "du0_sync_1", "du0_clk_out_0";
@@ -176,6 +179,11 @@
 		};
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk_b";
+		renesas,function = "scif_clk";
+	};
+
 	ethernet_pins: ethernet {
 		intc {
 			renesas,groups = "intc_irq1_b";
@@ -222,6 +230,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &sdhi0 {
 	pinctrl-0 = <&sdhi0_pins>;
 	pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:30:03 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:30:03 +0100
Subject: [PATCH 69/70] ARM: dts: porter: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <8ce468946f103b8c6074baedca6e20ba156eac3f.1454595846.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791-porter.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
index 5015eaa0ae50..ed1f6f884e2b 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -143,11 +143,19 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	scif0_pins: serial0 {
 		renesas,groups = "scif0_data_d";
 		renesas,function = "scif0";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	ether_pins: ether {
 		renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
 		renesas,function = "eth";
@@ -221,6 +229,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &ether {
 	pinctrl-0 = <&ether_pins &phy1_pins>;
 	pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:30:04 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:30:04 +0100
Subject: [PATCH 70/70] ARM: dts: silk: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <d7a11140d0a659e5c1f83627792f95b6713030a2.1454595846.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794-silk.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
index 98b8bcca84da..66f077a3ca41 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -126,11 +126,19 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	scif2_pins: serial2 {
 		renesas,groups = "scif2_data";
 		renesas,function = "scif2";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	ether_pins: ether {
 		renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
 		renesas,function = "eth";
@@ -184,6 +192,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &ether {
 	pinctrl-0 = <&ether_pins &phy1_pins>;
 	pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



From dvyukov at google.com  Thu Feb  4 07:05:16 2016
From: dvyukov at google.com (Dmitry Vyukov)
Date: Thu,  4 Feb 2016 16:05:16 +0100
Subject: [PATCH v7] kernel: add kcov code coverage
Message-ID: <1454598316-134094-1-git-send-email-dvyukov@google.com>

kcov provides code coverage collection for coverage-guided fuzzing
(randomized testing). Coverage-guided fuzzing is a testing technique
that uses coverage feedback to determine new interesting inputs to a
system. A notable user-space example is AFL
(http://lcamtuf.coredump.cx/afl/). However, this technique is not
widely used for kernel testing due to missing compiler and kernel
support.

kcov does not aim to collect as much coverage as possible. It aims
to collect more or less stable coverage that is function of syscall
inputs. To achieve this goal it does not collect coverage in
soft/hard interrupts and instrumentation of some inherently
non-deterministic or non-interesting parts of kernel is disbled
(e.g. scheduler, locking).

Currently there is a single coverage collection mode (tracing),
but the API anticipates additional collection modes.
Initially I also implemented a second mode which exposes
coverage in a fixed-size hash table of counters (what Quentin
used in his original patch). I've dropped the second mode for
simplicity.

This patch adds the necessary support on kernel side.
The complimentary compiler support was added in gcc revision 231296.

We've used this support to build syzkaller system call fuzzer,
which has found 90 kernel bugs in just 2 months:
https://github.com/google/syzkaller/wiki/Found-Bugs
We've also found 30+ bugs in our internal systems with syzkaller.
Another (yet unexplored) direction where kcov coverage would greatly
help is more traditional "blob mutation". For example, mounting
a random blob as a filesystem, or receiving a random blob over wire.

Why not gcov. Typical fuzzing loop looks as follows: (1) reset
coverage, (2) execute a bit of code, (3) collect coverage, repeat.
A typical coverage can be just a dozen of basic blocks (e.g. an
invalid input). In such context gcov becomes prohibitively expensive
as reset/collect coverage steps depend on total number of basic
blocks/edges in program (in case of kernel it is about 2M). Cost of
kcov depends only on number of executed basic blocks/edges. On top of
that, kernel requires per-thread coverage because there are
always background threads and unrelated processes that also produce
coverage. With inlined gcov instrumentation per-thread coverage is not
possible.

kcov exposes kernel PCs and control flow to user-space which
is insecure. But debugfs should not be mapped as user accessible.

Based on a patch by Quentin Casasnovas.
Signed-off-by: Dmitry Vyukov <dvyukov at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
Anticipating reasonable questions regarding usage of this feature.
Quentin Casasnovas and Vegard Nossum also plan to use kcov for
coverage-guided fuzzing. Currently they use a custom kernel patch
for their fuzzer and found several dozens of bugs.
There is also interest from Intel 0-DAY kernel test infrastructure.

Based on commit b37a05c083c85c2657dca9bbe1f5d79dccf756d5.

v2: - added note to commit desciption that kcov is insecure,
      but debugfs should not be mapped as user accessible.
    - make CONFIG_KCOV depend on CONFIG_ARCH_HAS_KCOV
      instead of conditional inclusion with if/endif
      (as per Kees comments).

v3: - disabled instrumentation of lib/hweight.c
    - changed task_struct.kcov_size type to unsigned
    - moved kcov.c from kernel/kcov/ to kernel/
    - fixed multi-line comment formatting
    - changed BUG_ONs to WARN_ONs
    - added kcov_get() helper

v4: - pre-populate mapping with pages in kcov_mmap()
    - don't get kcov references on vma open/copy,
      vma holds a reference to the file which is enough
    - extend KCOV_INIT_TRACE to support both compressed
      4-byte PCs and full 8-byte PCs (it now accepts a struct)
    - update example in Documentation/kcov.txt

v5: - export only unsigned long PCs (no compression to 4 bytes)
    - remove KCOV dependency on !RANDOMIZE_BASE
    - update example in Documentation/kcov.txt
    - rename kcov_mode_trace to KCOV_MODE_TRACE
    - warn about failed vm_insert_page()
    - ensure that arg for KCOV_ENABLE/KCOV_DISABLE is 0

v6: - export kcov file as 0600 instead of 0666

v7: - select DEBUG_FS when KCOV is selected
    - disable instrumentation of drivers/firmware/efi/libstub/*
---
 Documentation/kcov.txt                | 111 ++++++++++++++
 Makefile                              |  10 +-
 arch/x86/Kconfig                      |   1 +
 arch/x86/boot/Makefile                |   6 +
 arch/x86/boot/compressed/Makefile     |   2 +
 arch/x86/entry/vdso/Makefile          |   2 +
 arch/x86/kernel/Makefile              |   5 +
 arch/x86/kernel/apic/Makefile         |   4 +
 arch/x86/kernel/cpu/Makefile          |   4 +
 arch/x86/lib/Makefile                 |   3 +
 arch/x86/mm/Makefile                  |   3 +
 arch/x86/realmode/rm/Makefile         |   2 +
 drivers/firmware/efi/libstub/Makefile |   2 +
 include/linux/kcov.h                  |  19 +++
 include/linux/sched.h                 |  10 ++
 include/uapi/linux/kcov.h             |  10 ++
 kernel/Makefile                       |  12 ++
 kernel/exit.c                         |   2 +
 kernel/fork.c                         |   3 +
 kernel/kcov.c                         | 269 ++++++++++++++++++++++++++++++++++
 kernel/locking/Makefile               |   3 +
 kernel/rcu/Makefile                   |   4 +
 kernel/sched/Makefile                 |   4 +
 lib/Kconfig.debug                     |  21 +++
 lib/Makefile                          |  12 ++
 mm/Makefile                           |  15 ++
 mm/kasan/Makefile                     |   1 +
 scripts/Makefile.lib                  |   6 +
 28 files changed, 545 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/kcov.txt
 create mode 100644 include/linux/kcov.h
 create mode 100644 include/uapi/linux/kcov.h
 create mode 100644 kernel/kcov.c

diff --git a/Documentation/kcov.txt b/Documentation/kcov.txt
new file mode 100644
index 0000000..779ff4a
--- /dev/null
+++ b/Documentation/kcov.txt
@@ -0,0 +1,111 @@
+kcov: code coverage for fuzzing
+===============================
+
+kcov exposes kernel code coverage information in a form suitable for coverage-
+guided fuzzing (randomized testing). Coverage data of a running kernel is
+exported via the "kcov" debugfs file. Coverage collection is enabled on a task
+basis, and thus it can capture precise coverage of a single system call.
+
+Note that kcov does not aim to collect as much coverage as possible. It aims
+to collect more or less stable coverage that is function of syscall inputs.
+To achieve this goal it does not collect coverage in soft/hard interrupts
+and instrumentation of some inherently non-deterministic parts of kernel is
+disbled (e.g. scheduler, locking).
+
+Usage:
+======
+
+Configure kernel with:
+
+        CONFIG_KCOV=y
+
+CONFIG_KCOV requires gcc built on revision 231296 or later.
+Profiling data will only become accessible once debugfs has been mounted:
+
+        mount -t debugfs none /sys/kernel/debug
+
+The following program demonstrates kcov usage from within a test program:
+
+#include <stdio.h>
+#include <stddef.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <unistd.h>
+#include <fcntl.h>
+
+#define KCOV_INIT_TRACE			_IOR('c', 1, unsigned long)
+#define KCOV_ENABLE			_IO('c', 100)
+#define KCOV_DISABLE			_IO('c', 101)
+#define COVER_SIZE			(64<<10)
+
+int main(int argc, char **argv)
+{
+	int fd;
+	unsigned long *cover, n, i;
+
+	/* A single fd descriptor allows coverage collection on a single
+	 * thread.
+	 */
+	fd = open("/sys/kernel/debug/kcov", O_RDWR);
+	if (fd == -1)
+		perror("open"), exit(1);
+	/* Setup trace mode and trace size. */
+	if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE))
+		perror("ioctl"), exit(1);
+	/* Mmap buffer shared between kernel- and user-space. */
+	cover = (unsigned long*)mmap(NULL, COVER_SIZE * sizeof(unsigned long),
+				     PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
+	if ((void*)cover == MAP_FAILED)
+		perror("mmap"), exit(1);
+	/* Enable coverage collection on the current thread. */
+	if (ioctl(fd, KCOV_ENABLE, 0))
+		perror("ioctl"), exit(1);
+	/* Reset coverage from the tail of the ioctl() call. */
+	__atomic_store_n(&cover[0], 0, __ATOMIC_RELAXED);
+	/* That's the target syscal call. */
+	read(-1, NULL, 0);
+	/* Read number of PCs collected. */
+	n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED);
+	for (i = 0; i < n; i++)
+		printf("0x%lx\n", cover[i + 1]);
+	/* Disable coverage collection for the current thread. After this call
+	 * coverage can be enabled for a different thread.
+	 */
+	if (ioctl(fd, KCOV_DISABLE, 0))
+		perror("ioctl"), exit(1);
+	/* Free resources. */
+	if (munmap(cover, COVER_SIZE * sizeof(unsigned long)))
+		perror("munmap"), exit(1);
+	if (close(fd))
+		perror("close"), exit(1);
+	return 0;
+}
+
+After piping through addr2line output of the program looks as follows:
+
+SyS_read
+fs/read_write.c:562
+__fdget_pos
+fs/file.c:774
+__fget_light
+fs/file.c:746
+__fget_light
+fs/file.c:750
+__fget_light
+fs/file.c:760
+__fdget_pos
+fs/file.c:784
+SyS_read
+fs/read_write.c:562
+
+If a program needs to collect coverage from several threads (independently),
+it needs to open /sys/kernel/debug/kcov in each thread separately.
+
+The interface is fine-grained to allow efficient forking of test processes.
+That is, a parent process opens /sys/kernel/debug/kcov, enables trace mode,
+mmaps coverage buffer and then forks child processes in a loop. Child processes
+only need to enable coverage (disable happens automatically on thread end).
diff --git a/Makefile b/Makefile
index 6c1a3c2..574ccc4a 100644
--- a/Makefile
+++ b/Makefile
@@ -365,6 +365,7 @@ LDFLAGS_MODULE  =
 CFLAGS_KERNEL	=
 AFLAGS_KERNEL	=
 CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage
+CFLAGS_KCOV	= -fsanitize-coverage=trace-pc
 
 
 # Use USERINCLUDE when you must reference the UAPI directories only.
@@ -411,7 +412,7 @@ export MAKE AWK GENKSYMS INSTALLKERNEL PERL PYTHON UTS_MACHINE
 export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
 
 export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
-export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV CFLAGS_KASAN CFLAGS_UBSAN
+export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV CFLAGS_KCOV CFLAGS_KASAN CFLAGS_UBSAN
 export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
 export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
 export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
@@ -673,6 +674,13 @@ endif
 endif
 KBUILD_CFLAGS += $(stackp-flag)
 
+ifdef CONFIG_KCOV
+  ifeq ($(call cc-option, $(CFLAGS_KCOV)),)
+    $(warning Cannot use CONFIG_KCOV: \
+             -fsanitize-coverage=trace-pc is not supported by compiler)
+  endif
+endif
+
 ifeq ($(cc-name),clang)
 KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
 KBUILD_CPPFLAGS += $(call cc-option,-Wno-unknown-warning-option,)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9af2e63..e102416 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -28,6 +28,7 @@ config X86
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_FAST_MULTIPLIER
 	select ARCH_HAS_GCOV_PROFILE_ALL
+	select ARCH_HAS_KCOV			if X86_64
 	select ARCH_HAS_PMEM_API		if X86_64
 	select ARCH_HAS_MMIO_FLUSH
 	select ARCH_HAS_SG_CHAIN
diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
index bbe1a62..5f93ca0 100644
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -10,6 +10,12 @@
 #
 
 KASAN_SANITIZE := n
+# Kernel does not boot with kcov instrumentation here.
+# One of the problems observed was insertion of __sanitizer_cov_trace_pc()
+# callback into middle of per-cpu data enabling code. Thus the callback observed
+# inconsistent state and crashed. We are interested mostly in syscall coverage,
+# so boot code is not interesting anyway.
+KCOV_INSTRUMENT := n
 
 # If you want to preset the SVGA mode, uncomment the next line and
 # set SVGA_MODE to whatever number you want.
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index f9ce75d..ad9e9fa 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -17,6 +17,8 @@
 #	compressed vmlinux.bin.all + u32 size of vmlinux.bin.all
 
 KASAN_SANITIZE := n
+# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
+KCOV_INSTRUMENT := n
 
 targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma \
 	vmlinux.bin.xz vmlinux.bin.lzo vmlinux.bin.lz4
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index c854541..5a19939 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -5,6 +5,8 @@
 KBUILD_CFLAGS += $(DISABLE_LTO)
 KASAN_SANITIZE := n
 UBSAN_SANITIZE := n
+# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
+KCOV_INSTRUMENT := n
 
 VDSO64-$(CONFIG_X86_64)		:= y
 VDSOX32-$(CONFIG_X86_X32_ABI)	:= y
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index b1b78ff..4648960 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -19,6 +19,11 @@ endif
 KASAN_SANITIZE_head$(BITS).o := n
 KASAN_SANITIZE_dumpstack.o := n
 KASAN_SANITIZE_dumpstack_$(BITS).o := n
+# If instrumentation of this dir is enabled, boot hangs during first second.
+# Probably could be more selective here, but note that files related to irqs,
+# boot, dumpstack/stacktrace, etc are either non-interesting or can lead to
+# non-deterministic coverage.
+KCOV_INSTRUMENT := n
 
 CFLAGS_irq.o := -I$(src)/../include/asm/trace
 
diff --git a/arch/x86/kernel/apic/Makefile b/arch/x86/kernel/apic/Makefile
index 8bb12dd..8f2a3d7 100644
--- a/arch/x86/kernel/apic/Makefile
+++ b/arch/x86/kernel/apic/Makefile
@@ -2,6 +2,10 @@
 # Makefile for local APIC drivers and for the IO-APIC code
 #
 
+# Leads to non-deterministic coverage that is not a function of syscall inputs.
+# In particualr, smp_apic_timer_interrupt() is called in random places.
+KCOV_INSTRUMENT := n
+
 obj-$(CONFIG_X86_LOCAL_APIC)	+= apic.o apic_noop.o ipi.o vector.o
 obj-y				+= hw_nmi.o
 
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 5803130..c108683 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -8,6 +8,10 @@ CFLAGS_REMOVE_common.o = -pg
 CFLAGS_REMOVE_perf_event.o = -pg
 endif
 
+# If these files are instrumented, boot hangs during the first second.
+KCOV_INSTRUMENT_common.o := n
+KCOV_INSTRUMENT_perf_event.o := n
+
 # Make sure load_percpu_segment has no stackprotector
 nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_common.o		:= $(nostackp)
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index a501fa2..fefca94 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -2,6 +2,9 @@
 # Makefile for x86 specific library files.
 #
 
+# Produces uninteresting flaky coverage.
+KCOV_INSTRUMENT_delay.o := n
+
 inat_tables_script = $(srctree)/arch/x86/tools/gen-insn-attr-x86.awk
 inat_tables_maps = $(srctree)/arch/x86/lib/x86-opcode-map.txt
 quiet_cmd_inat_tables = GEN     $@
diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile
index f9d38a4..147def6 100644
--- a/arch/x86/mm/Makefile
+++ b/arch/x86/mm/Makefile
@@ -1,3 +1,6 @@
+# Kernel does not boot with instrumentation of tlb.c.
+KCOV_INSTRUMENT_tlb.o := n
+
 obj-y	:=  init.o init_$(BITS).o fault.o ioremap.o extable.o pageattr.o mmap.o \
 	    pat.o pgtable.o physaddr.o gup.o setup_nx.o
 
diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile
index 3e75fcf..35129dc 100644
--- a/arch/x86/realmode/rm/Makefile
+++ b/arch/x86/realmode/rm/Makefile
@@ -7,6 +7,8 @@
 #
 #
 KASAN_SANITIZE := n
+# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
+KCOV_INSTRUMENT := n
 
 always := realmode.bin realmode.relocs
 
diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index aaf9c0b..37cc9e3 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -23,6 +23,8 @@ KBUILD_CFLAGS			:= $(cflags-y) -DDISABLE_BRANCH_PROFILING \
 GCOV_PROFILE			:= n
 KASAN_SANITIZE			:= n
 UBSAN_SANITIZE			:= n
+# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
+KCOV_INSTRUMENT			:= n
 
 lib-y				:= efi-stub-helper.o
 
diff --git a/include/linux/kcov.h b/include/linux/kcov.h
new file mode 100644
index 0000000..72ff663
--- /dev/null
+++ b/include/linux/kcov.h
@@ -0,0 +1,19 @@
+#ifndef _LINUX_KCOV_H
+#define _LINUX_KCOV_H
+
+#include <uapi/linux/kcov.h>
+
+struct task_struct;
+
+#ifdef CONFIG_KCOV
+
+void kcov_task_init(struct task_struct *t);
+void kcov_task_exit(struct task_struct *t);
+
+#else
+
+static inline void kcov_task_init(struct task_struct *t) {}
+static inline void kcov_task_exit(struct task_struct *t) {}
+
+#endif /* CONFIG_KCOV */
+#endif /* _LINUX_KCOV_H */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a10494a..bbd991e 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1811,6 +1811,16 @@ struct task_struct {
 	/* bitmask and counter of trace recursion */
 	unsigned long trace_recursion;
 #endif /* CONFIG_TRACING */
+#ifdef CONFIG_KCOV
+	/* Coverage collection mode enabled for this task (0 if disabled). */
+	int		kcov_mode;
+	/* Size of the kcov_area. */
+	unsigned	kcov_size;
+	/* Buffer for coverage collection. */
+	void		*kcov_area;
+	/* kcov desciptor wired with this task or NULL. */
+	struct kcov	*kcov;
+#endif
 #ifdef CONFIG_MEMCG
 	struct mem_cgroup *memcg_in_oom;
 	gfp_t memcg_oom_gfp_mask;
diff --git a/include/uapi/linux/kcov.h b/include/uapi/linux/kcov.h
new file mode 100644
index 0000000..574e22e
--- /dev/null
+++ b/include/uapi/linux/kcov.h
@@ -0,0 +1,10 @@
+#ifndef _LINUX_KCOV_IOCTLS_H
+#define _LINUX_KCOV_IOCTLS_H
+
+#include <linux/types.h>
+
+#define KCOV_INIT_TRACE			_IOR('c', 1, unsigned long)
+#define KCOV_ENABLE			_IO('c', 100)
+#define KCOV_DISABLE			_IO('c', 101)
+
+#endif /* _LINUX_KCOV_IOCTLS_H */
diff --git a/kernel/Makefile b/kernel/Makefile
index 53abf00..2dea801 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -19,6 +19,17 @@ CFLAGS_REMOVE_cgroup-debug.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_irq_work.o = $(CC_FLAGS_FTRACE)
 endif
 
+# Prevents flicker of uninteresting __do_softirq()/__local_bh_disable_ip()
+# in coverage traces.
+KCOV_INSTRUMENT_softirq.o := n
+# These are called from save_stack_trace() on slub debug path,
+# and produce insane amounts of uninteresting coverage.
+KCOV_INSTRUMENT_module.o := n
+KCOV_INSTRUMENT_extable.o := n
+# Don't self-instrument.
+KCOV_INSTRUMENT_kcov.o := n
+KASAN_SANITIZE_kcov.o := n
+
 # cond_syscall is currently not LTO compatible
 CFLAGS_sys_ni.o = $(DISABLE_LTO)
 
@@ -69,6 +80,7 @@ obj-$(CONFIG_AUDITSYSCALL) += auditsc.o
 obj-$(CONFIG_AUDIT_WATCH) += audit_watch.o audit_fsnotify.o
 obj-$(CONFIG_AUDIT_TREE) += audit_tree.o
 obj-$(CONFIG_GCOV_KERNEL) += gcov/
+obj-$(CONFIG_KCOV) += kcov.o
 obj-$(CONFIG_KPROBES) += kprobes.o
 obj-$(CONFIG_KGDB) += debug/
 obj-$(CONFIG_DETECT_HUNG_TASK) += hung_task.o
diff --git a/kernel/exit.c b/kernel/exit.c
index 10e0882..953d1a1 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -53,6 +53,7 @@
 #include <linux/oom.h>
 #include <linux/writeback.h>
 #include <linux/shm.h>
+#include <linux/kcov.h>
 
 #include <asm/uaccess.h>
 #include <asm/unistd.h>
@@ -655,6 +656,7 @@ void do_exit(long code)
 	TASKS_RCU(int tasks_rcu_i);
 
 	profile_task_exit(tsk);
+	kcov_task_exit(tsk);
 
 	WARN_ON(blk_needs_flush_plug(tsk));
 
diff --git a/kernel/fork.c b/kernel/fork.c
index 2e391c7..7c222c5 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -75,6 +75,7 @@
 #include <linux/aio.h>
 #include <linux/compiler.h>
 #include <linux/sysctl.h>
+#include <linux/kcov.h>
 
 #include <asm/pgtable.h>
 #include <asm/pgalloc.h>
@@ -384,6 +385,8 @@ static struct task_struct *dup_task_struct(struct task_struct *orig)
 
 	account_kernel_stack(ti, 1);
 
+	kcov_task_init(tsk);
+
 	return tsk;
 
 free_ti:
diff --git a/kernel/kcov.c b/kernel/kcov.c
new file mode 100644
index 0000000..662c401
--- /dev/null
+++ b/kernel/kcov.c
@@ -0,0 +1,269 @@
+#define pr_fmt(fmt) "kcov: " fmt
+
+#include <linux/compiler.h>
+#include <linux/types.h>
+#include <linux/file.h>
+#include <linux/fs.h>
+#include <linux/mm.h>
+#include <linux/printk.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/vmalloc.h>
+#include <linux/debugfs.h>
+#include <linux/uaccess.h>
+#include <linux/kcov.h>
+
+enum kcov_mode {
+	/*
+	 * Tracing coverage collection mode.
+	 * Covered PCs are collected in a per-task buffer.
+	 */
+	KCOV_MODE_TRACE = 1,
+};
+
+/*
+ * kcov descriptor (one per opened debugfs file).
+ * State transitions of the descriptor:
+ *  - initial state after open()
+ *  - then there must be a single ioctl(KCOV_INIT_TRACE) call
+ *  - then, mmap() call (several calls are allowed but not useful)
+ *  - then, repeated enable/disable for a task (only one task a time allowed)
+ */
+struct kcov {
+	/*
+	 * Reference counter. We keep one for:
+	 *  - opened file descriptor
+	 *  - task with enabled coverage (we can't unwire it from another task)
+	 */
+	atomic_t		rc;
+	/* The lock protects mode, size, area and t. */
+	spinlock_t		lock;
+	enum kcov_mode		mode;
+	unsigned		size;
+	void			*area;
+	struct task_struct	*t;
+};
+
+/*
+ * Entry point from instrumented code.
+ * This is called once per basic-block/edge.
+ */
+void __sanitizer_cov_trace_pc(void)
+{
+	struct task_struct *t;
+	enum kcov_mode mode;
+
+	t = current;
+	/*
+	 * We are interested in code coverage as a function of a syscall inputs,
+	 * so we ignore code executed in interrupts.
+	 */
+	if (!t || in_interrupt())
+		return;
+	mode = READ_ONCE(t->kcov_mode);
+	if (mode == KCOV_MODE_TRACE) {
+		unsigned long *area;
+		unsigned long pos;
+
+		/*
+		 * There is some code that runs in interrupts but for which
+		 * in_interrupt() returns false (e.g. preempt_schedule_irq()).
+		 * READ_ONCE()/barrier() effectively provides load-acquire wrt
+		 * interrupts, there are paired barrier()/WRITE_ONCE() in
+		 * kcov_ioctl_locked().
+		 */
+		barrier();
+		area = t->kcov_area;
+		/* The first word is number of subsequent PCs. */
+		pos = READ_ONCE(area[0]) + 1;
+		if (likely(pos < t->kcov_size)) {
+			area[pos] = _RET_IP_;
+			WRITE_ONCE(area[0], pos);
+		}
+	}
+}
+EXPORT_SYMBOL(__sanitizer_cov_trace_pc);
+
+static void kcov_get(struct kcov *kcov)
+{
+	atomic_inc(&kcov->rc);
+}
+
+static void kcov_put(struct kcov *kcov)
+{
+	if (atomic_dec_and_test(&kcov->rc)) {
+		vfree(kcov->area);
+		kfree(kcov);
+	}
+}
+
+void kcov_task_init(struct task_struct *t)
+{
+	t->kcov_mode = 0;
+	t->kcov_size = 0;
+	t->kcov_area = NULL;
+	t->kcov = NULL;
+}
+
+void kcov_task_exit(struct task_struct *t)
+{
+	struct kcov *kcov;
+
+	kcov = t->kcov;
+	if (kcov == NULL)
+		return;
+	spin_lock(&kcov->lock);
+	if (WARN_ON(kcov->t != t)) {
+		spin_unlock(&kcov->lock);
+		return;
+	}
+	/* Just to not leave dangling references behind. */
+	kcov_task_init(t);
+	kcov->t = NULL;
+	spin_unlock(&kcov->lock);
+	kcov_put(kcov);
+}
+
+static int kcov_mmap(struct file *filep, struct vm_area_struct *vma)
+{
+	int res = 0;
+	void *area;
+	struct kcov *kcov = vma->vm_file->private_data;
+	unsigned long size, off;
+	struct page *page;
+
+	area = vmalloc_user(vma->vm_end - vma->vm_start);
+	if (!area)
+		return -ENOMEM;
+
+	spin_lock(&kcov->lock);
+	size = kcov->size * sizeof(unsigned long);
+	if (kcov->mode == 0 || vma->vm_pgoff != 0 ||
+	    vma->vm_end - vma->vm_start != size) {
+		res = -EINVAL;
+		goto exit;
+	}
+	if (!kcov->area) {
+		kcov->area = area;
+		vma->vm_flags |= VM_DONTEXPAND;
+		spin_unlock(&kcov->lock);
+		for (off = 0; off < size; off += PAGE_SIZE) {
+			page = vmalloc_to_page(kcov->area + off);
+			if (vm_insert_page(vma, vma->vm_start + off, page))
+				WARN_ONCE(1, "vm_insert_page() failed");
+		}
+		return 0;
+	}
+exit:
+	spin_unlock(&kcov->lock);
+	vfree(area);
+	return res;
+}
+
+static int kcov_open(struct inode *inode, struct file *filep)
+{
+	struct kcov *kcov;
+
+	kcov = kzalloc(sizeof(*kcov), GFP_KERNEL);
+	if (!kcov)
+		return -ENOMEM;
+	atomic_set(&kcov->rc, 1);
+	spin_lock_init(&kcov->lock);
+	filep->private_data = kcov;
+	return nonseekable_open(inode, filep);
+}
+
+static int kcov_close(struct inode *inode, struct file *filep)
+{
+	kcov_put(filep->private_data);
+	return 0;
+}
+
+static int kcov_ioctl_locked(struct kcov *kcov, unsigned int cmd,
+			     unsigned long arg)
+{
+	struct task_struct *t;
+
+	switch (cmd) {
+	case KCOV_INIT_TRACE:
+		/*
+		 * Enable kcov in trace mode and setup buffer size.
+		 * Must happen before anything else.
+		 * Size must be at least 2 to hold current position and one PC.
+		 */
+		if (arg < 2 || arg > INT_MAX)
+			return -EINVAL;
+		if (kcov->mode != 0)
+			return -EBUSY;
+		kcov->mode = KCOV_MODE_TRACE;
+		kcov->size = arg;
+		return 0;
+	case KCOV_ENABLE:
+		/*
+		 * Enable coverage for the current task.
+		 * At this point user must have been enabled trace mode,
+		 * and mmapped the file. Coverage collection is disabled only
+		 * at task exit or voluntary by KCOV_DISABLE. After that it can
+		 * be enabled for another task.
+		 */
+		if (arg != 0 || kcov->mode == 0 || kcov->area == NULL)
+			return -EINVAL;
+		if (kcov->t != NULL)
+			return -EBUSY;
+		t = current;
+		/* Cache in task struct for performance. */
+		t->kcov_size = kcov->size;
+		t->kcov_area = kcov->area;
+		/* See comment in __sanitizer_cov_trace_pc(). */
+		barrier();
+		WRITE_ONCE(t->kcov_mode, kcov->mode);
+		t->kcov = kcov;
+		kcov->t = t;
+		/* This is put either in kcov_task_exit() or in KCOV_DISABLE. */
+		kcov_get(kcov);
+		return 0;
+	case KCOV_DISABLE:
+		/* Disable coverage for the current task. */
+		if (arg != 0 || current->kcov != kcov)
+			return -EINVAL;
+		t = current;
+		if (WARN_ON(kcov->t != t))
+			return -EINVAL;
+		kcov_task_init(t);
+		kcov->t = NULL;
+		kcov_put(kcov);
+		return 0;
+	default:
+		return -EINVAL;
+	}
+}
+
+static long kcov_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
+{
+	struct kcov *kcov;
+	int res;
+
+	kcov = filep->private_data;
+	spin_lock(&kcov->lock);
+	res = kcov_ioctl_locked(kcov, cmd, arg);
+	spin_unlock(&kcov->lock);
+	return res;
+}
+
+static const struct file_operations kcov_fops = {
+	.open		= kcov_open,
+	.unlocked_ioctl	= kcov_ioctl,
+	.mmap		= kcov_mmap,
+	.release        = kcov_close,
+};
+
+static int __init kcov_init(void)
+{
+	if (!debugfs_create_file("kcov", 0600, NULL, NULL, &kcov_fops)) {
+		pr_err("failed to create kcov in debugfs\n");
+		return -ENOMEM;
+	}
+	return 0;
+}
+
+device_initcall(kcov_init);
diff --git a/kernel/locking/Makefile b/kernel/locking/Makefile
index 8e96f6c..f816de9 100644
--- a/kernel/locking/Makefile
+++ b/kernel/locking/Makefile
@@ -1,3 +1,6 @@
+# Any varying coverage in these files is non-deterministic
+# and is generally not a function of system call inputs.
+KCOV_INSTRUMENT := n
 
 obj-y += mutex.o semaphore.o rwsem.o percpu-rwsem.o
 
diff --git a/kernel/rcu/Makefile b/kernel/rcu/Makefile
index 61a1656..032b2c0 100644
--- a/kernel/rcu/Makefile
+++ b/kernel/rcu/Makefile
@@ -1,3 +1,7 @@
+# Any varying coverage in these files is non-deterministic
+# and is generally not a function of system call inputs.
+KCOV_INSTRUMENT := n
+
 obj-y += update.o sync.o
 obj-$(CONFIG_SRCU) += srcu.o
 obj-$(CONFIG_RCU_TORTURE_TEST) += rcutorture.o
diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
index 6768797..f0a9265 100644
--- a/kernel/sched/Makefile
+++ b/kernel/sched/Makefile
@@ -2,6 +2,10 @@ ifdef CONFIG_FUNCTION_TRACER
 CFLAGS_REMOVE_clock.o = $(CC_FLAGS_FTRACE)
 endif
 
+# These files are disabled because they produce non-interesting flaky coverage
+# that is not a function of syscall inputs. E.g. involuntary context switches.
+KCOV_INSTRUMENT := n
+
 ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER),y)
 # According to Alan Modra <alan at linuxcare.com.au>, the -fno-omit-frame-pointer is
 # needed for x86 only.  Why this used to be enabled for all architectures is beyond
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ecb9e75..38bfd79 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -678,6 +678,27 @@ config DEBUG_STACKOVERFLOW
 
 	  If in doubt, say "N".
 
+config ARCH_HAS_KCOV
+	bool
+	help
+	  KCOV does not have any arch-specific code, but currently it is enabled
+	  only for x86_64. KCOV requires testing on other archs, and most likely
+	  disabling of instrumentation for some early boot code.
+
+config KCOV
+	bool "Code coverage for fuzzing"
+	depends on ARCH_HAS_KCOV
+	select DEBUG_FS
+	help
+	  KCOV exposes kernel code coverage information in a form suitable
+	  for coverage-guided fuzzing (randomized testing).
+
+	  If RANDOMIZE_BASE is enabled, PC values will not be stable across
+	  different machines and across reboots. If you need stable PC values,
+	  disable RANDOMIZE_BASE.
+
+	  For more details, see Documentation/kcov.txt.
+
 source "lib/Kconfig.kmemcheck"
 
 source "lib/Kconfig.kasan"
diff --git a/lib/Makefile b/lib/Makefile
index a7c26a4..309aaf7 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -7,6 +7,18 @@ ORIG_CFLAGS := $(KBUILD_CFLAGS)
 KBUILD_CFLAGS = $(subst $(CC_FLAGS_FTRACE),,$(ORIG_CFLAGS))
 endif
 
+# These files are disabled because they produce lots of non-interesting and/or
+# flaky coverage that is not a function of syscall inputs. For example,
+# rbtree can be global and individual rotations don't correlate with inputs.
+KCOV_INSTRUMENT_string.o := n
+KCOV_INSTRUMENT_rbtree.o := n
+KCOV_INSTRUMENT_list_debug.o := n
+KCOV_INSTRUMENT_debugobjects.o := n
+KCOV_INSTRUMENT_dynamic_debug.o := n
+# Kernel does not boot if we instrument this file as it uses custom calling
+# convention (see CONFIG_ARCH_HWEIGHT_CFLAGS).
+KCOV_INSTRUMENT_hweight.o := n
+
 lib-y := ctype.o string.o vsprintf.o cmdline.o \
 	 rbtree.o radix-tree.o dump_stack.o timerqueue.o\
 	 idr.o int_sqrt.o extable.o \
diff --git a/mm/Makefile b/mm/Makefile
index 2ed4319..cf751bb 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -5,6 +5,21 @@
 KASAN_SANITIZE_slab_common.o := n
 KASAN_SANITIZE_slub.o := n
 
+# These files are disabled because they produce non-interesting and/or
+# flaky coverage that is not a function of syscall inputs. E.g. slab is out of
+# free pages, or a task is migrated between nodes.
+KCOV_INSTRUMENT_slab_common.o := n
+KCOV_INSTRUMENT_slob.o := n
+KCOV_INSTRUMENT_slab.o := n
+KCOV_INSTRUMENT_slub.o := n
+KCOV_INSTRUMENT_page_alloc.o := n
+KCOV_INSTRUMENT_debug-pagealloc.o := n
+KCOV_INSTRUMENT_kmemleak.o := n
+KCOV_INSTRUMENT_kmemcheck.o := n
+KCOV_INSTRUMENT_memcontrol.o := n
+KCOV_INSTRUMENT_mmzone.o := n
+KCOV_INSTRUMENT_vmstat.o := n
+
 mmu-y			:= nommu.o
 mmu-$(CONFIG_MMU)	:= gup.o highmem.o memory.o mincore.o \
 			   mlock.o mmap.o mprotect.o mremap.o msync.o rmap.o \
diff --git a/mm/kasan/Makefile b/mm/kasan/Makefile
index a61460d..131daad 100644
--- a/mm/kasan/Makefile
+++ b/mm/kasan/Makefile
@@ -1,5 +1,6 @@
 KASAN_SANITIZE := n
 UBSAN_SANITIZE_kasan.o := n
+KCOV_INSTRUMENT := n
 
 CFLAGS_REMOVE_kasan.o = -pg
 # Function splitter causes unnecessary splits in __asan_load1/__asan_store1
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 2edbcad..31d7a73 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -136,6 +136,12 @@ _c_flags += $(if $(patsubst n%,, \
 		$(CFLAGS_UBSAN))
 endif
 
+ifeq ($(CONFIG_KCOV),y)
+_c_flags += $(if $(patsubst n%,, \
+	$(KCOV_INSTRUMENT_$(basetarget).o)$(KCOV_INSTRUMENT)y), \
+	$(CFLAGS_KCOV))
+endif
+
 # If building the kernel in a separate objtree expand all occurrences
 # of -Idir to -I$(srctree)/dir except for absolute paths (starting with '/').
 
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:58 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:58 +0100
Subject: [PATCH 64/70] ARM: dts: bockw: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <50f27ac4fc464c4b1f2a5f7ac84fa4d469ceafd8.1454595846.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7778-bockw.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7778-bockw.dts b/arch/arm/boot/dts/r8a7778-bockw.dts
index a52b359e2ae2..21e3b9dda2da 100644
--- a/arch/arm/boot/dts/r8a7778-bockw.dts
+++ b/arch/arm/boot/dts/r8a7778-bockw.dts
@@ -126,11 +126,19 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	scif0_pins: serial0 {
 		renesas,groups = "scif0_data_a", "scif0_ctrl";
 		renesas,function = "scif0";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	mmc_pins: mmc {
 		renesas,groups = "mmc_data8", "mmc_ctrl";
 		renesas,function = "mmc";
@@ -217,3 +225,8 @@
 
 	status = "okay";
 };
+
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:59 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:59 +0100
Subject: [PATCH 65/70] ARM: dts: gose: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <f3446b0fdac2ceb9dc03737bf14c14bd47df1503.1454595846.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 2fa052036dbc..cfe142c2ba38 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -236,6 +236,9 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	i2c2_pins: i2c2 {
 		renesas,groups = "i2c2";
 		renesas,function = "i2c2";
@@ -256,6 +259,11 @@
 		renesas,function = "scif1";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	ether_pins: ether {
 		renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
 		renesas,function = "eth";
@@ -316,6 +324,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &qspi {
 	pinctrl-0 = <&qspi_pins>;
 	pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:30:00 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:30:00 +0100
Subject: [PATCH 66/70] ARM: dts: koelsch: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <895c27aa8815eb5518e73ee5e9e35359ff8e03e8.1454595846.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates:
  - SCIF:
      - Supports now 50, 75, 110, 1152000, 1500000, 2000000, and
        4000000 bps,
      - Perfect match for standard 50-460800, and 9216000 bps.
      - More accurate 576000 bps.
  - HSCIF:
      - Supports now 50, 75, 110, 134, 150, and 200 bps,
      - Perfect match for standard 50-460800, and 9216000 bps.
      - More accurate 576000, 1152000, 3000000, 3500000, and 4000000
	bps.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 45256f3cc835..0ad71b81d3a2 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -320,6 +320,9 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	i2c2_pins: i2c2 {
 		renesas,groups = "i2c2";
 		renesas,function = "i2c2";
@@ -340,6 +343,11 @@
 		renesas,function = "scif1";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	ether_pins: ether {
 		renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
 		renesas,function = "eth";
@@ -440,6 +448,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &sdhi0 {
 	pinctrl-0 = <&sdhi0_pins>;
 	pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:29 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:29 +0100
Subject: [PATCH 35/70] ARM: dts: r8a7793: enable audio DMAC in device tree
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <f418cbb69a2f5a481bd5f210bb5c8c5cc9322224.1454595846.git.horms+renesas@verge.net.au>

Enable audio DMAC (= rcar-dmac) in r8a7793 device tree.

Based on similar work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---
v4
* Use GIC_SPI in interrupts properties
---
 arch/arm/boot/dts/r8a7793.dtsi | 91 ++++++++++++++++++++++++++++++++++++------
 1 file changed, 79 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index ddbda9d2c177..6817f14314e2 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -1201,52 +1201,119 @@
 		status = "disabled";
 
 		rcar_sound,dvc {
-			dvc0: dvc at 0 { };
-			dvc1: dvc at 1 { };
+			dvc0: dvc at 0 {
+				dmas = <&audma0 0xbc>;
+				dma-names = "tx";
+			};
+			dvc1: dvc at 1 {
+				dmas = <&audma0 0xbe>;
+				dma-names = "tx";
+			};
 		};
+
 		rcar_sound,src {
-			src0: src at 0 { };
-			src1: src at 1 { };
-			src2: src at 2 { };
-			src3: src at 3 { };
-			src4: src at 4 { };
-			src5: src at 5 { };
-			src6: src at 6 { };
-			src7: src at 7 { };
-			src8: src at 8 { };
-			src9: src at 9 { };
+			src0: src at 0 {
+				interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x85>, <&audma1 0x9a>;
+				dma-names = "rx", "tx";
+			};
+			src1: src at 1 {
+				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x87>, <&audma1 0x9c>;
+				dma-names = "rx", "tx";
+			};
+			src2: src at 2 {
+				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x89>, <&audma1 0x9e>;
+				dma-names = "rx", "tx";
+			};
+			src3: src at 3 {
+				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x8b>, <&audma1 0xa0>;
+				dma-names = "rx", "tx";
+			};
+			src4: src at 4 {
+				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x8d>, <&audma1 0xb0>;
+				dma-names = "rx", "tx";
+			};
+			src5: src at 5 {
+				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x8f>, <&audma1 0xb2>;
+				dma-names = "rx", "tx";
+			};
+			src6: src at 6 {
+				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x91>, <&audma1 0xb4>;
+				dma-names = "rx", "tx";
+			};
+			src7: src at 7 {
+				interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x93>, <&audma1 0xb6>;
+				dma-names = "rx", "tx";
+			};
+			src8: src at 8 {
+				interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x95>, <&audma1 0xb8>;
+				dma-names = "rx", "tx";
+			};
+			src9: src at 9 {
+				interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x97>, <&audma1 0xba>;
+				dma-names = "rx", "tx";
+			};
 		};
 
 		rcar_sound,ssi {
 			ssi0: ssi at 0 {
 				interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x01>, <&audma1 0x02>, <&audma0 0x15>, <&audma1 0x16>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi1: ssi at 1 {
 				 interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x03>, <&audma1 0x04>, <&audma0 0x49>, <&audma1 0x4a>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi2: ssi at 2 {
 				interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x05>, <&audma1 0x06>, <&audma0 0x63>, <&audma1 0x64>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi3: ssi at 3 {
 				interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x07>, <&audma1 0x08>, <&audma0 0x6f>, <&audma1 0x70>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi4: ssi at 4 {
 				interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x09>, <&audma1 0x0a>, <&audma0 0x71>, <&audma1 0x72>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi5: ssi at 5 {
 				interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x0b>, <&audma1 0x0c>, <&audma0 0x73>, <&audma1 0x74>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi6: ssi at 6 {
 				interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x0d>, <&audma1 0x0e>, <&audma0 0x75>, <&audma1 0x76>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi7: ssi at 7 {
 				interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x0f>, <&audma1 0x10>, <&audma0 0x79>, <&audma1 0x7a>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi8: ssi at 8 {
 				interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x11>, <&audma1 0x12>, <&audma0 0x7b>, <&audma1 0x7c>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi9: ssi at 9 {
 				interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x13>, <&audma1 0x14>, <&audma0 0x7d>, <&audma1 0x7e>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 		};
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb  4 06:29:28 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Thu,  4 Feb 2016 15:29:28 +0100
Subject: [PATCH 34/70] ARM: dts: gose: enable sound DMA support via DVC in
 device tree
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <ae79f66db7e75dfe696df7f392f4db4980117306.1454595846.git.horms+renesas@verge.net.au>

Enable DMA transfer using DVC in r8a7793/gose device tree.

     DMA               DMApp
[MEM] -> [SRC] -> [DVC] -> [SSIU] -> [SSI]

     DMA               DMApp
[MEM] <- [DVC] <- [SRC] <- [SSIU] <- [SSI]

Based on similar work for the r8a7791/koelsch by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 17c87fe0944f..2fa052036dbc 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -18,7 +18,24 @@
  * This command is required when Playback/Capture
  *
  *	amixer set "LINEOUT Mixer DACL" on
+ *	amixer set "DVC Out" 100%
+ *	amixer set "DVC In" 100%
+ *
+ * You can use Mute
+ *
+ *	amixer set "DVC Out Mute" on
+ *	amixer set "DVC In Mute" on
+ *
+ * You can use Volume Ramp
+ *
+ *	amixer set "DVC Out Ramp Up Rate"   "0.125 dB/64 steps"
+ *	amixer set "DVC Out Ramp Down Rate" "0.125 dB/512 steps"
+ *	amixer set "DVC Out Ramp" on
+ *	aplay xxx.wav &
+ *	amixer set "DVC Out"  80%  // Volume Down
+ *	amixer set "DVC Out" 100%  // Volume Up
  */
+
 /dts-v1/;
 #include "r8a7793.dtsi"
 #include <dt-bindings/gpio/gpio.h>
@@ -401,8 +418,8 @@
 
 	rcar_sound,dai {
 		dai0 {
-			playback = <&ssi0 &src2>;
-			capture  = <&ssi1 &src3>;
+			playback = <&ssi0 &src2 &dvc0>;
+			capture  = <&ssi1 &src3 &dvc1>;
 		};
 	};
 };
-- 
2.7.0.rc3.207.g0ac5344



From dvyukov at google.com  Thu Feb  4 07:07:16 2016
From: dvyukov at google.com (Dmitry Vyukov)
Date: Thu, 4 Feb 2016 16:07:16 +0100
Subject: [PATCH v6] kernel: add kcov code coverage
In-Reply-To: <CAPAsAGz6vVGfAPSimwqkneUmzMmrwX_WxdCoQ1xg3UyNn4+-eQ@mail.gmail.com>
References: <1453726850-49137-1-git-send-email-dvyukov@google.com>
 <CAPAsAGz6vVGfAPSimwqkneUmzMmrwX_WxdCoQ1xg3UyNn4+-eQ@mail.gmail.com>
Message-ID: <CACT4Y+YygZitF6508qNX9885+nWu7iY9YVqdtE0bCA2+soTp_Q@mail.gmail.com>

On Tue, Feb 2, 2016 at 5:02 PM, Andrey Ryabinin <ryabinin.a.a at gmail.com> wrote:
> 2016-01-25 16:00 GMT+03:00 Dmitry Vyukov <dvyukov at google.com>:
>
>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> index ecb9e75..cde6bd1 100644
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> @@ -678,6 +678,26 @@ config DEBUG_STACKOVERFLOW
>>
>>           If in doubt, say "N".
>>
>> +config ARCH_HAS_KCOV
>> +       bool
>> +       help
>> +         KCOV does not have any arch-specific code, but currently it is enabled
>> +         only for x86_64. KCOV requires testing on other archs, and most likely
>> +         disabling of instrumentation for some early boot code.
>> +
>> +config KCOV
>> +       bool "Code coverage for fuzzing"
>> +       depends on ARCH_HAS_KCOV
>
> I think we should select DEBUG_FS here, since this useless without it.

Done in v7

> Also you placed this into 'Memory Debugging' submenu which seems wrong.

Any better suggestions?

>> +       help
>> +         KCOV exposes kernel code coverage information in a form suitable
>> +         for coverage-guided fuzzing (randomized testing).
>> +
>> +         If RANDOMIZE_BASE is enabled, PC values will not be stable across
>> +         different machines and across reboots. If you need stable PC values,
>> +         disable RANDOMIZE_BASE.
>> +
>> +         For more details, see Documentation/kcov.txt.
>> +
>>  source "lib/Kconfig.kmemcheck"
>>


From dvyukov at google.com  Thu Feb  4 07:07:38 2016
From: dvyukov at google.com (Dmitry Vyukov)
Date: Thu, 4 Feb 2016 16:07:38 +0100
Subject: [PATCH v6] kernel: add kcov code coverage
In-Reply-To: <56B0E530.8090908@suse.cz>
References: <1453726850-49137-1-git-send-email-dvyukov@google.com>
 <56B0E530.8090908@suse.cz>
Message-ID: <CACT4Y+aKhnpwCpycay1fZuGeCSUgn1CqL8hN3PoFZPdQQsfCNg@mail.gmail.com>

On Tue, Feb 2, 2016 at 6:19 PM, Jiri Slaby <jslaby at suse.cz> wrote:
> On 01/25/2016, 02:00 PM, Dmitry Vyukov wrote:
>> --- a/scripts/Makefile.lib
>> +++ b/scripts/Makefile.lib
>> @@ -136,6 +136,12 @@ _c_flags += $(if $(patsubst n%,, \
>>               $(CFLAGS_UBSAN))
>>  endif
>>
>> +ifeq ($(CONFIG_KCOV),y)
>> +_c_flags += $(if $(patsubst n%,, \
>> +     $(KCOV_INSTRUMENT_$(basetarget).o)$(KCOV_INSTRUMENT)y), \
>> +     $(CFLAGS_KCOV))
>
> Now that KCOV does not inherit KASAN's "n"s, I see link errors in efi
> lib with EFI_STUB:
> drivers/firmware/efi/libstub/lib.a(efi-stub-helper.o): In function
> `efi_printk':
> efi-stub-helper.c:(.text+0x13): undefined reference to
> `__sanitizer_cov_trace_pc'
> efi-stub-helper.c:(.text+0x31): undefined reference to
> `__sanitizer_cov_trace_pc'
> ...
>
> I fixed it by adding "KCOV_INSTRUMENT := n" to
>   drivers/firmware/efi/libstub/Makefile


Done in v7
Thanks for testing!


From gabriele.paoloni at huawei.com  Thu Feb  4 07:11:18 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Thu, 4 Feb 2016 15:11:18 +0000
Subject: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host
 Controllers
In-Reply-To: <2387127.DMZaDnZvEW@wuerfel>
References: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
 <2387127.DMZaDnZvEW@wuerfel>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1EC9EC12@lhreml503-mbs>

Hi Arnd

Thanks for looking at this

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 04 February 2016 13:12
> To: Gabriele Paoloni
> Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C); Linuxarm;
> qiujiang; bhelgaas at google.com; Lorenzo.Pieralisi at arm.com;
> tn at semihalf.com; zhangjukuo; xuwei (O); Liguozhu (Kenneth); linux-
> pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> acpi at vger.kernel.org; linux-kernel at vger.kernel.org; jcm at redhat.com
> Subject: Re: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host
> Controllers
> 
> On Thursday 04 February 2016 19:37:36 Gabriele Paoloni wrote:
> > From: gabriele paoloni <gabriele.paoloni at huawei.com>
> >
> > This patchset adds ACPI support for the HiSilicon Hip05/Hip06 SoC
> PCIe controllers
> > The four patches respectively:
> >         - rework PCie Designware to be used for ACPI PCI Host
> controllers
> >         - re-architect the current HiSilicon driver to make it
> scalable to the
> >           new ACPI quirks
> >         - rework the current HiSilicon driver to make it ECAM
> compliant
> >         - adds the HiSilicon ACPI specific quirks.
> >
> >    This patchset  is based on
> >    https://github.com/semihalf-nowicki-tomasz/linux.git
> >    branch pci-acpi-v3 + Hip06 support applied on top:
> >    https://patchwork.ozlabs.org/patch/549198/
> >
> 
> ACPI has its own PCI support, and should not need drivers for host
> bridges. I don't think we can really mix the two things, as ACPI
> needs to have access to things like PCI config space way before
> we are probing normal device drivers.
> 
> Please put this in drivers/acpi/pci*.c.

I can put pcie-hisi-acpi.c under drivers/acpi/

However if you look at the driver it is made up of three parts:
pcie-hisi.c --> the DT based driver
pcie-hisi-acpi.c --> the ACPI based hook and ACPI specific init callback
pcie-hisi-common.c --> common functions shared between DT and ACPI versions 
                       of the driver

Now I think that moving pcie-hisi-acpi.c under drivers/acpi/
would make it hard to read as you need to jump across directories
and it seems a bit unnatural...

However it is not a big issue to me...

Cheers

Gab

> 
> 	Arnd


From catalin.marinas at arm.com  Thu Feb  4 07:13:04 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 4 Feb 2016 15:13:04 +0000
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160204151303.GB6076@e104818-lin.cambridge.arm.com>

On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
> This adds support for emitting PLTs at module load time for relative
> branches that are out of range. This is a prerequisite for KASLR, which
> may place the kernel and the modules anywhere in the vmalloc area,
> making it more likely that branch target offsets exceed the maximum
> range of +/- 128 MB.

Any downside to trying to keep the kernel+modules coupled together so
that we avoid the PLT?

-- 
Catalin


From ryabinin.a.a at gmail.com  Thu Feb  4 07:19:14 2016
From: ryabinin.a.a at gmail.com (Andrey Ryabinin)
Date: Thu, 4 Feb 2016 18:19:14 +0300
Subject: [PATCH v6] kernel: add kcov code coverage
In-Reply-To: <CACT4Y+YygZitF6508qNX9885+nWu7iY9YVqdtE0bCA2+soTp_Q@mail.gmail.com>
References: <1453726850-49137-1-git-send-email-dvyukov@google.com>
 <CAPAsAGz6vVGfAPSimwqkneUmzMmrwX_WxdCoQ1xg3UyNn4+-eQ@mail.gmail.com>
 <CACT4Y+YygZitF6508qNX9885+nWu7iY9YVqdtE0bCA2+soTp_Q@mail.gmail.com>
Message-ID: <CAPAsAGx+6tfwbo32EGu6H9Mb6S1WXLvQOYzBrhhc=q=N7sFYgw@mail.gmail.com>

2016-02-04 18:07 GMT+03:00 Dmitry Vyukov <dvyukov at google.com>:
> On Tue, Feb 2, 2016 at 5:02 PM, Andrey Ryabinin <ryabinin.a.a at gmail.com> wrote:
>> 2016-01-25 16:00 GMT+03:00 Dmitry Vyukov <dvyukov at google.com>:
>>
>>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>>> index ecb9e75..cde6bd1 100644
>>> --- a/lib/Kconfig.debug
>>> +++ b/lib/Kconfig.debug
>>> @@ -678,6 +678,26 @@ config DEBUG_STACKOVERFLOW
>>>
>>>           If in doubt, say "N".
>>>
>>> +config ARCH_HAS_KCOV
>>> +       bool
>>> +       help
>>> +         KCOV does not have any arch-specific code, but currently it is enabled
>>> +         only for x86_64. KCOV requires testing on other archs, and most likely
>>> +         disabling of instrumentation for some early boot code.
>>> +
>>> +config KCOV
>>> +       bool "Code coverage for fuzzing"
>>> +       depends on ARCH_HAS_KCOV
>>
>> I think we should select DEBUG_FS here, since this useless without it.
>
> Done in v7
>
>> Also you placed this into 'Memory Debugging' submenu which seems wrong.
>
> Any better suggestions?
>

Just 'Kernel hacking'


From leo.yan at linaro.org  Thu Feb  4 07:24:56 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Thu,  4 Feb 2016 23:24:56 +0800
Subject: [PATCH v7 0/4] mailbox: hisilicon: add Hi6220 mailbox driver
Message-ID: <1454599500-15600-1-git-send-email-leo.yan@linaro.org>

Hi6220 mailbox supports up to 32 channels. Each channel is unidirectional
with a maximum message size of 8 words. I/O is performed using register
access (there is no DMA) and the cell raises an interrupt when messages
are received.

This patch series is to implement Hi6220 mailbox driver. It registers
two channels into framework for communication with MCU, one is tx channel
and another is rx channel. Now mailbox driver is used to send message to
MCU to control dynamic voltage and frequency scaling for CPU, GPU and DDR.

Changes from v6:
* Fix to use lowercase for hexadecimal value in DT binding document

Changes from v5:
* Refine to use mailbox three specifiers for client driver, so add xlate
  callback function in mailbox driver to support these specifiers
* Refine document for property "hi6220,mbox-tx-noirq"

Changes from v4:
* According to Jassi's suggestion, using DT binding to register channels
* Change to use operating-points-v2 to register operating points

Changes from v3:
* The patch series for enabling idle state for Hi6220 has reserved memory
  regions, so this series will not include it anymore
* Refined mailbox driver according to Jassi's suggestion;
  Removed kfifo from mailbox driver;
  Removed spinlock for ipc registers accessing, due every channel has its
  own dedicated bit in ipc register and readl/writel will introduce memory
  barrier, so don't need spinlock to protect ipc registers accessing
* After mailbox driver is ready, can use patch 4 to enable CPU's OPPs and
  stub clock driver; finally can enable CPUFreq driver for CPU frequency
  scaling

Changes from v2:
* Get rid of unused memory regions from memory node in DT, and don't use
  reserved-memory node according to Mark and Leif's suggestion; Haojian also
  has updated UEFI for efi memory info

Changes from v1:
* Correct lock usage for SMP scenario

Changes from RFC:
* According to Jassi's review, totally remove the abstract common driver
  layer and only commit driver dedicated for Hi6220
* According to Paul Bolle's review, fix typo issue for Kconfig and remove
  unnecessary dependency with OF and fix minor for mailbox driver
* Refine a little for dts nodes


Leo Yan (4):
  dt-bindings: mailbox: Document Hi6220 mailbox driver
  mailbox: Hi6220: add mailbox driver
  arm64: dts: add mailbox node for Hi6220
  arm64: dts: add Hi6220's stub clock node

 .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  |  74 ++++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi          |  64 ++++
 drivers/mailbox/Kconfig                            |   8 +
 drivers/mailbox/Makefile                           |   2 +
 drivers/mailbox/hi6220-mailbox.c                   | 395 +++++++++++++++++++++
 5 files changed, 543 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
 create mode 100644 drivers/mailbox/hi6220-mailbox.c

-- 
1.9.1



From leo.yan at linaro.org  Thu Feb  4 07:24:57 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Thu,  4 Feb 2016 23:24:57 +0800
Subject: [PATCH v7 1/4] dt-bindings: mailbox: Document Hi6220 mailbox driver
In-Reply-To: <1454599500-15600-1-git-send-email-leo.yan@linaro.org>
References: <1454599500-15600-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1454599500-15600-2-git-send-email-leo.yan@linaro.org>

Document DT binding for Hisilicon Hi6220 mailbox driver.

Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  | 74 ++++++++++++++++++++++
 1 file changed, 74 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt

diff --git a/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
new file mode 100644
index 0000000..044b17f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
@@ -0,0 +1,74 @@
+Hisilicon Hi6220 Mailbox Driver
+===============================
+
+Hisilicon Hi6220 mailbox supports up to 32 channels. Each channel
+is unidirectional with a maximum message size of 8 words. I/O is
+performed using register access (there is no DMA) and the cell
+raises an interrupt when messages are received.
+
+Mailbox Device Node:
+====================
+
+Required properties:
+--------------------
+- compatible:		Shall be "hisilicon,hi6220-mbox"
+- reg:			Contains the mailbox register address range (base
+			address and length); the first item is for IPC
+			registers, the second item is shared buffer for
+			slots.
+- #mbox-cells:		Common mailbox binding property to identify the number
+			of cells required for the mailbox specifier. Must be 3.
+			<&phandle slot_id dst_irq ack_irq>
+			  phandle: Label name of mailbox controller
+			  slot_id: Slot id used either for TX or RX
+			  dst_irq: IRQ identifier index number which used by MCU
+			  ack_irq: IRQ identifier index number with generating a
+			           TX/RX interrupt to application processor,
+				   mailbox driver uses it to acknowledge interrupt
+- interrupts:		Contains the interrupt information for the mailbox
+			device. The format is dependent on which interrupt
+			controller the SoCs use.
+
+Optional Properties:
+--------------------
+- hi6220,mbox-tx-noirq: Property of MCU firmware's feature, so mailbox driver
+			use this flag to ask MCU to enable "automatic idle
+			flag" mode or IRQ generated mode to acknowledge a TX
+			completion.
+
+Example:
+--------
+
+	mailbox: mailbox at f7510000 {
+		compatible = "hisilicon,hi6220-mbox";
+		reg = <0x0 0xf7510000 0x0 0x1000>, /* IPC_S */
+		      <0x0 0x06dff800 0x0 0x0800>; /* Mailbox */
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+		#mbox-cells = <3>;
+	};
+
+
+Mailbox client
+===============
+
+Required properties:
+--------------------
+- compatible:		Many (See the client docs).
+- mboxes:		Standard property to specify a Mailbox (See ./mailbox.txt)
+			Cells must match 'mbox-cells' (See Mailbox Device Node above).
+
+Optional Properties:
+--------------------
+- mbox-names:		Name given to channels seen in the 'mboxes' property.
+
+Example:
+--------
+
+	stub_clock: stub_clock {
+		compatible = "hisilicon,hi6220-stub-clk";
+		hisilicon,hi6220-clk-sram = <&sram>;
+		#clock-cells = <1>;
+		mbox-names = "mbox-tx", "mbox-rx";
+		mboxes = <&mailbox 1 0 11>, <&mailbox 0 1 10>;
+	};
-- 
1.9.1



From leo.yan at linaro.org  Thu Feb  4 07:24:58 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Thu,  4 Feb 2016 23:24:58 +0800
Subject: [PATCH v7 2/4] mailbox: Hi6220: add mailbox driver
In-Reply-To: <1454599500-15600-1-git-send-email-leo.yan@linaro.org>
References: <1454599500-15600-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1454599500-15600-3-git-send-email-leo.yan@linaro.org>

Add driver for Hi6220 mailbox, the mailbox communicates with MCU; for
sending data, it can support two methods for low level implementation:
one is to use interrupt as acknowledge, another is automatic mode which
without any acknowledge. These two methods have been supported in the
driver. For receiving data, it will depend on the interrupt to notify
the channel has incoming message.

Now mailbox driver is used to send message to MCU to control dynamic
voltage and frequency scaling for CPU, GPU and DDR.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 drivers/mailbox/Kconfig          |   8 +
 drivers/mailbox/Makefile         |   2 +
 drivers/mailbox/hi6220-mailbox.c | 395 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 405 insertions(+)
 create mode 100644 drivers/mailbox/hi6220-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 546d05f..b8bbeb0 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -78,6 +78,14 @@ config STI_MBOX
 	  Mailbox implementation for STMicroelectonics family chips with
 	  hardware for interprocessor communication.
 
+config HI6220_MBOX
+	tristate "Hi6220 Mailbox"
+	depends on ARCH_HISI
+	help
+	  An implementation of the hi6220 mailbox. It is used to send message
+	  between application processors and MCU. Say Y here if you want to
+	  build Hi6220 mailbox controller driver.
+
 config MAILBOX_TEST
 	tristate "Mailbox Test Client"
 	depends on OF
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 92435ef..565adda 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -17,3 +17,5 @@ obj-$(CONFIG_ALTERA_MBOX)	+= mailbox-altera.o
 obj-$(CONFIG_BCM2835_MBOX)	+= bcm2835-mailbox.o
 
 obj-$(CONFIG_STI_MBOX)		+= mailbox-sti.o
+
+obj-$(CONFIG_HI6220_MBOX)	+= hi6220-mailbox.o
diff --git a/drivers/mailbox/hi6220-mailbox.c b/drivers/mailbox/hi6220-mailbox.c
new file mode 100644
index 0000000..613722d
--- /dev/null
+++ b/drivers/mailbox/hi6220-mailbox.c
@@ -0,0 +1,395 @@
+/*
+ * Hisilicon's Hi6220 mailbox driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ * Copyright (c) 2015 Linaro Limited.
+ *
+ * Author: Leo Yan <leo.yan at linaro.org>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kfifo.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#define MBOX_CHAN_MAX			32
+
+#define MBOX_TX				0x1
+
+/* Mailbox message length: 8 words */
+#define MBOX_MSG_LEN			8
+
+/* Mailbox Registers */
+#define MBOX_OFF(m)			(0x40 * (m))
+#define MBOX_MODE_REG(m)		(MBOX_OFF(m) + 0x0)
+#define MBOX_DATA_REG(m)		(MBOX_OFF(m) + 0x4)
+
+#define MBOX_STATE_MASK			(0xF << 4)
+#define MBOX_STATE_IDLE			(0x1 << 4)
+#define MBOX_STATE_TX			(0x2 << 4)
+#define MBOX_STATE_RX			(0x4 << 4)
+#define MBOX_STATE_ACK			(0x8 << 4)
+#define MBOX_ACK_CONFIG_MASK		(0x1 << 0)
+#define MBOX_ACK_AUTOMATIC		(0x1 << 0)
+#define MBOX_ACK_IRQ			(0x0 << 0)
+
+/* IPC registers */
+#define ACK_INT_RAW_REG(i)		((i) + 0x400)
+#define ACK_INT_MSK_REG(i)		((i) + 0x404)
+#define ACK_INT_STAT_REG(i)		((i) + 0x408)
+#define ACK_INT_CLR_REG(i)		((i) + 0x40c)
+#define ACK_INT_ENA_REG(i)		((i) + 0x500)
+#define ACK_INT_DIS_REG(i)		((i) + 0x504)
+#define DST_INT_RAW_REG(i)		((i) + 0x420)
+
+
+struct hi6220_mbox_chan {
+
+	/*
+	 * Description for channel's hardware info:
+	 *  - direction: tx or rx
+	 *  - dst irq: peer core's irq number
+	 *  - ack irq: local irq number
+	 *  - slot number
+	 */
+	unsigned int dir, dst_irq, ack_irq;
+	unsigned int slot;
+
+	struct hi6220_mbox *parent;
+};
+
+struct hi6220_mbox {
+	struct device *dev;
+
+	int irq;
+
+	/* flag of enabling tx's irq mode */
+	bool tx_irq_mode;
+
+	/* region for ipc event */
+	void __iomem *ipc;
+
+	/* region for mailbox */
+	void __iomem *base;
+
+	unsigned int chan_num;
+	struct hi6220_mbox_chan *mchan;
+
+	void *irq_map_chan[MBOX_CHAN_MAX];
+	struct mbox_chan *chan;
+	struct mbox_controller controller;
+};
+
+static void mbox_set_state(struct hi6220_mbox *mbox,
+			   unsigned int slot, u32 val)
+{
+	u32 status;
+
+	status = readl(mbox->base + MBOX_MODE_REG(slot));
+	status = (status & ~MBOX_STATE_MASK) | val;
+	writel(status, mbox->base + MBOX_MODE_REG(slot));
+}
+
+static void mbox_set_mode(struct hi6220_mbox *mbox,
+			  unsigned int slot, u32 val)
+{
+	u32 mode;
+
+	mode = readl(mbox->base + MBOX_MODE_REG(slot));
+	mode = (mode & ~MBOX_ACK_CONFIG_MASK) | val;
+	writel(mode, mbox->base + MBOX_MODE_REG(slot));
+}
+
+static bool hi6220_mbox_last_tx_done(struct mbox_chan *chan)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+	u32 state;
+
+	/* Only set idle state for polling mode */
+	BUG_ON(mbox->tx_irq_mode);
+
+	state = readl(mbox->base + MBOX_MODE_REG(mchan->slot));
+	return ((state & MBOX_STATE_MASK) == MBOX_STATE_IDLE);
+}
+
+static int hi6220_mbox_send_data(struct mbox_chan *chan, void *msg)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+	unsigned int slot = mchan->slot;
+	u32 *buf = msg;
+	int i;
+
+	/* indicate as a TX channel */
+	mchan->dir = MBOX_TX;
+
+	mbox_set_state(mbox, slot, MBOX_STATE_TX);
+
+	if (mbox->tx_irq_mode)
+		mbox_set_mode(mbox, slot, MBOX_ACK_IRQ);
+	else
+		mbox_set_mode(mbox, slot, MBOX_ACK_AUTOMATIC);
+
+	for (i = 0; i < MBOX_MSG_LEN; i++)
+		writel(buf[i], mbox->base + MBOX_DATA_REG(slot) + i * 4);
+
+	/* trigger remote request */
+	writel(BIT(mchan->dst_irq), DST_INT_RAW_REG(mbox->ipc));
+	return 0;
+}
+
+static irqreturn_t hi6220_mbox_interrupt(int irq, void *p)
+{
+	struct hi6220_mbox *mbox = p;
+	struct hi6220_mbox_chan *mchan;
+	struct mbox_chan *chan;
+	unsigned int state, intr_bit, i;
+	u32 msg[MBOX_MSG_LEN];
+
+	state = readl(ACK_INT_STAT_REG(mbox->ipc));
+	if (!state) {
+		dev_warn(mbox->dev, "%s: spurious interrupt\n",
+			 __func__);
+		return IRQ_HANDLED;
+	}
+
+	while (state) {
+		intr_bit = __ffs(state);
+		state &= (state - 1);
+
+		chan = mbox->irq_map_chan[intr_bit];
+		if (!chan) {
+			dev_warn(mbox->dev, "%s: unexpected irq vector %d\n",
+				 __func__, intr_bit);
+			continue;
+		}
+
+		mchan = chan->con_priv;
+		if (mchan->dir == MBOX_TX)
+			mbox_chan_txdone(chan, 0);
+		else {
+			for (i = 0; i < MBOX_MSG_LEN; i++)
+				msg[i] = readl(mbox->base +
+					MBOX_DATA_REG(mchan->slot) + i * 4);
+
+			mbox_chan_received_data(chan, (void *)msg);
+		}
+
+		/* clear IRQ source */
+		writel(BIT(mchan->ack_irq), ACK_INT_CLR_REG(mbox->ipc));
+		mbox_set_state(mbox, mchan->slot, MBOX_STATE_IDLE);
+	}
+
+	return IRQ_HANDLED;
+}
+
+static int hi6220_mbox_startup(struct mbox_chan *chan)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+
+	mchan->dir = 0;
+
+	/* enable interrupt */
+	writel(BIT(mchan->ack_irq), ACK_INT_ENA_REG(mbox->ipc));
+	return 0;
+}
+
+static void hi6220_mbox_shutdown(struct mbox_chan *chan)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+
+	/* disable interrupt */
+	writel(BIT(mchan->ack_irq), ACK_INT_DIS_REG(mbox->ipc));
+	mbox->irq_map_chan[mchan->ack_irq] = NULL;
+}
+
+static struct mbox_chan_ops hi6220_mbox_ops = {
+	.send_data    = hi6220_mbox_send_data,
+	.startup      = hi6220_mbox_startup,
+	.shutdown     = hi6220_mbox_shutdown,
+	.last_tx_done = hi6220_mbox_last_tx_done,
+};
+
+static struct mbox_chan *hi6220_mbox_xlate(struct mbox_controller *controller,
+					   const struct of_phandle_args *spec)
+{
+	struct hi6220_mbox *mbox = dev_get_drvdata(controller->dev);
+	struct hi6220_mbox_chan *mchan;
+	struct mbox_chan *chan;
+	unsigned int i = spec->args[0];
+	unsigned int dst_irq = spec->args[1];
+	unsigned int ack_irq = spec->args[2];
+
+	/* Bounds checking */
+	if (i >= mbox->chan_num || dst_irq >= mbox->chan_num ||
+	    ack_irq >= mbox->chan_num) {
+		dev_err(mbox->dev,
+			"Invalid channel idx %d dst_irq %d ack_irq %d\n",
+			i, dst_irq, ack_irq);
+		return ERR_PTR(-EINVAL);
+	}
+
+	/* Is requested channel free? */
+	chan = &mbox->chan[i];
+	if (mbox->irq_map_chan[ack_irq] == (void *)chan) {
+		dev_err(mbox->dev, "Channel in use\n");
+		return ERR_PTR(-EBUSY);
+	}
+
+	mchan = chan->con_priv;
+	mchan->dst_irq = dst_irq;
+	mchan->ack_irq = ack_irq;
+
+	mbox->irq_map_chan[ack_irq] = (void *)chan;
+	return chan;
+}
+
+static const struct of_device_id hi6220_mbox_of_match[] = {
+	{ .compatible = "hisilicon,hi6220-mbox", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, hi6220_mbox_of_match);
+
+static int hi6220_mbox_probe(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	struct device *dev = &pdev->dev;
+	struct hi6220_mbox *mbox;
+	struct resource *res;
+	int i, err;
+
+	mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+	if (!mbox)
+		return -ENOMEM;
+
+	mbox->dev = dev;
+	mbox->chan_num = MBOX_CHAN_MAX;
+	mbox->mchan = devm_kzalloc(dev,
+		mbox->chan_num * sizeof(*mbox->mchan), GFP_KERNEL);
+	if (!mbox->mchan)
+		return -ENOMEM;
+
+	mbox->chan = devm_kzalloc(dev,
+		mbox->chan_num * sizeof(*mbox->chan), GFP_KERNEL);
+	if (!mbox->chan)
+		return -ENOMEM;
+
+	mbox->irq = platform_get_irq(pdev, 0);
+	if (mbox->irq < 0)
+		return mbox->irq;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mbox->ipc = devm_ioremap_resource(dev, res);
+	if (IS_ERR(mbox->ipc)) {
+		dev_err(dev, "ioremap ipc failed\n");
+		return PTR_ERR(mbox->ipc);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	mbox->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(mbox->base)) {
+		dev_err(dev, "ioremap buffer failed\n");
+		return PTR_ERR(mbox->base);
+	}
+
+	err = devm_request_irq(dev, mbox->irq, hi6220_mbox_interrupt, 0,
+			dev_name(dev), mbox);
+	if (err) {
+		dev_err(dev, "Failed to register a mailbox IRQ handler: %d\n",
+			err);
+		return -ENODEV;
+	}
+
+	mbox->controller.dev = dev;
+	mbox->controller.chans = &mbox->chan[0];
+	mbox->controller.num_chans = mbox->chan_num;
+	mbox->controller.ops = &hi6220_mbox_ops;
+	mbox->controller.of_xlate = hi6220_mbox_xlate;
+
+	for (i = 0; i < mbox->chan_num; i++) {
+		mbox->chan[i].con_priv = &mbox->mchan[i];
+		mbox->irq_map_chan[i] = NULL;
+
+		mbox->mchan[i].parent = mbox;
+		mbox->mchan[i].slot   = i;
+	}
+
+	/* mask and clear all interrupt vectors */
+	writel(0x0,  ACK_INT_MSK_REG(mbox->ipc));
+	writel(~0x0, ACK_INT_CLR_REG(mbox->ipc));
+
+	/* use interrupt for tx's ack */
+	if (of_find_property(node, "hi6220,mbox-tx-noirq", NULL))
+		mbox->tx_irq_mode = false;
+	else
+		mbox->tx_irq_mode = true;
+
+	if (mbox->tx_irq_mode)
+		mbox->controller.txdone_irq = true;
+	else {
+		mbox->controller.txdone_poll = true;
+		mbox->controller.txpoll_period = 5;
+	}
+
+	err = mbox_controller_register(&mbox->controller);
+	if (err) {
+		dev_err(dev, "Failed to register mailbox %d\n", err);
+		return err;
+	}
+
+	platform_set_drvdata(pdev, mbox);
+	dev_info(dev, "Mailbox enabled\n");
+	return 0;
+}
+
+static int hi6220_mbox_remove(struct platform_device *pdev)
+{
+	struct hi6220_mbox *mbox = platform_get_drvdata(pdev);
+
+	mbox_controller_unregister(&mbox->controller);
+	return 0;
+}
+
+static struct platform_driver hi6220_mbox_driver = {
+	.driver = {
+		.name = "hi6220-mbox",
+		.owner = THIS_MODULE,
+		.of_match_table = hi6220_mbox_of_match,
+	},
+	.probe	= hi6220_mbox_probe,
+	.remove	= hi6220_mbox_remove,
+};
+
+static int __init hi6220_mbox_init(void)
+{
+	return platform_driver_register(&hi6220_mbox_driver);
+}
+core_initcall(hi6220_mbox_init);
+
+static void __exit hi6220_mbox_exit(void)
+{
+	platform_driver_unregister(&hi6220_mbox_driver);
+}
+module_exit(hi6220_mbox_exit);
+
+MODULE_AUTHOR("Leo Yan <leo.yan at linaro.org>");
+MODULE_DESCRIPTION("Hi6220 mailbox driver");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1



From leo.yan at linaro.org  Thu Feb  4 07:25:00 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Thu,  4 Feb 2016 23:25:00 +0800
Subject: [PATCH v7 4/4] arm64: dts: add Hi6220's stub clock node
In-Reply-To: <1454599500-15600-1-git-send-email-leo.yan@linaro.org>
References: <1454599500-15600-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1454599500-15600-5-git-send-email-leo.yan@linaro.org>

Enable SRAM node and stub clock node for Hi6220, which uses mailbox
channel 1 for CPU's frequency change.

Furthermore, add the CPU clock phandle in CPU's node and using
operating-points-v2 to register operating points. So can be used by
cpufreq-dt driver.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 56 +++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 23c79e1..f588be9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -81,6 +81,11 @@
 			device_type = "cpu";
 			reg = <0x0 0x0>;
 			enable-method = "psci";
+			clocks = <&stub_clock 0>;
+			operating-points-v2 = <&cpu_opp_table>;
+			cooling-min-level = <4>;
+			cooling-max-level = <0>;
+			#cooling-cells = <2>; /* min followed by max */
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -89,6 +94,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x1>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -97,6 +103,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x2>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -105,6 +112,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x3>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -113,6 +121,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x100>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -121,6 +130,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x101>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -129,6 +139,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x102>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -137,10 +148,42 @@
 			device_type = "cpu";
 			reg = <0x0 0x103>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 	};
 
+	cpu_opp_table: cpu_opp_table {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp00 {
+			opp-hz = /bits/ 64 <208000000>;
+			opp-microvolt = <1040000>;
+			clock-latency-ns = <500000>;
+		};
+		opp01 {
+			opp-hz = /bits/ 64 <432000000>;
+			opp-microvolt = <1040000>;
+			clock-latency-ns = <500000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <729000000>;
+			opp-microvolt = <1090000>;
+			clock-latency-ns = <500000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <960000000>;
+			opp-microvolt = <1180000>;
+			clock-latency-ns = <500000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt = <1330000>;
+			clock-latency-ns = <500000>;
+		};
+	};
+
 	gic: interrupt-controller at f6801000 {
 		compatible = "arm,gic-400";
 		reg = <0x0 0xf6801000 0 0x1000>, /* GICD */
@@ -168,6 +211,11 @@
 		#size-cells = <2>;
 		ranges;
 
+		sram: sram at fff80000 {
+			compatible = "hisilicon,hi6220-sramctrl", "syscon";
+			reg = <0x0 0xfff80000 0x0 0x12000>;
+		};
+
 		ao_ctrl: ao_ctrl at f7800000 {
 			compatible = "hisilicon,hi6220-aoctrl", "syscon";
 			reg = <0x0 0xf7800000 0x0 0x2000>;
@@ -193,6 +241,14 @@
 			#clock-cells = <1>;
 		};
 
+		stub_clock: stub_clock {
+			compatible = "hisilicon,hi6220-stub-clk";
+			hisilicon,hi6220-clk-sram = <&sram>;
+			#clock-cells = <1>;
+			mbox-names = "mbox-tx";
+			mboxes = <&mailbox 1 0 11>;
+		};
+
 		uart0: uart at f8015000 {	/* console */
 			compatible = "arm,pl011", "arm,primecell";
 			reg = <0x0 0xf8015000 0x0 0x1000>;
-- 
1.9.1



From ard.biesheuvel at linaro.org  Thu Feb  4 07:31:59 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 4 Feb 2016 16:31:59 +0100
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <20160204151303.GB6076@e104818-lin.cambridge.arm.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160204151303.GB6076@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu9n=bmsZ=UOBiLWzaG2JSsbdC8k1mB7yFbH0czrbXS-1g@mail.gmail.com>

On 4 February 2016 at 16:13, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
>> This adds support for emitting PLTs at module load time for relative
>> branches that are out of range. This is a prerequisite for KASLR, which
>> may place the kernel and the modules anywhere in the vmalloc area,
>> making it more likely that branch target offsets exceed the maximum
>> range of +/- 128 MB.
>
> Any downside to trying to keep the kernel+modules coupled together so
> that we avoid the PLT?
>

First of all, note that it is unlikely that the PLTs are ever required
in practice, considering that either
a) the kernel is loaded at the default location right at the base of
the vmalloc range, and in this case, the module space is reserved for
modules only, or
b) the kernel is loaded at some random offset in the 240+ GB vmalloc
space, and it is unlikely that all VMA space around the kernel happens
to be given out to non-randomized vmalloc/ioremap allocations

So while this patch was a requirement at first (since in the first
version of the series, the modules always remained below the vmalloc
area so they would always be out of range when KASLR was enabled), in
the current series, it is simply a last resort (although still
required) to make sure that modules can be loaded far away from the
kernel in the unlikely event that all VMA space in close proximity is
given to another user.

Reserving a dedicated module region around the kernel while it is
loaded at a random offset is not straight forward, since it affects
all other users of the vmalloc area. So generic vmalloc/vmap/ioremap
code would need to be updated to disregard the area around the kernel,
since simply reserving the VMA area for the modules would make it
inaccessible to module_alloc() as well (unless we reserve the whole
region and manage the module allocations separately)

So the bottom line is that it may be possible, but it is unlikely to
be worth the effort imo

-- 
Ard.


From leo.yan at linaro.org  Thu Feb  4 07:24:59 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Thu,  4 Feb 2016 23:24:59 +0800
Subject: [PATCH v7 3/4] arm64: dts: add mailbox node for Hi6220
In-Reply-To: <1454599500-15600-1-git-send-email-leo.yan@linaro.org>
References: <1454599500-15600-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1454599500-15600-4-git-send-email-leo.yan@linaro.org>

This patch add device mailbox node for Hi6220 in DT.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 2585236..23c79e1 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -249,5 +249,13 @@
 			clocks = <&ao_ctrl 27>;
 			clock-names = "apb_pclk";
 		};
+
+		mailbox: mailbox at f7510000 {
+			compatible = "hisilicon,hi6220-mbox";
+			reg = <0x0 0xf7510000 0x0 0x1000>, /* IPC_S */
+			      <0x0 0x06dff800 0x0 0x0800>; /* Mailbox buffer */
+			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+			#mbox-cells = <3>;
+		};
 	};
 };
-- 
1.9.1



From moinejf at free.fr  Thu Feb  4 07:25:45 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Thu, 4 Feb 2016 16:25:45 +0100
Subject: [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused
In-Reply-To: <20160204120507.GC4270@lukather>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <20160204120507.GC4270@lukather>
Message-ID: <20160204162545.f806fcb64a826d2c3313985b@free.fr>

On Thu, 4 Feb 2016 13:05:07 +0100
Maxime Ripard <maxime.ripard at free-electrons.com> wrote:

> On Mon, Feb 01, 2016 at 09:20:00PM +0100, Maxime Ripard wrote:
> > Remove the fixed dividers from the PLL6 driver to be able to have a
> > reusable driver that can be used across several SoCs that share the same
> > controller, but don't have the same set of dividers for this clock, and to
> > also be reused multiple times in the same SoC, since we're droping the
> > clock name.
> > 
> > Acked-by: Chen-Yu Tsai <wens at csie.org>
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> 
> Applied.
> 
> Maxime

I don't agree:
- you changed the DTs of many SoCs without any valid reason,
- you complexified the treatment of the pll6 in clk-sunxi.c while
  defining a x2 rate instead of the single rate would also work for
  the other pll periphs (pll8).

Here is a simpler patch:

--- a/arch/arm/boot/dts/sun8i-h3.dtsi	2016-02-01 08:24:06.179396522 +0100
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi	2016-02-04 16:18:05.911509291 +0100
@@ -137,12 +137,23 @@
 			clock-output-names = "pll6d2";
 		};
 
-		/* dummy clock until pll6 can be reused */
+		pll8x2: clk at 01c20044 {			/* PLL_PERIPH1 */
+			#clock-cells = <0>;
+			compatible = "allwinner,pll-periphx2-clk";
+			reg = <0x01c20044 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll8x2";
+		};
+
 		pll8: pll8_clk {
 			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <1>;
+			compatible = "fixed-factor-clock";
+			clock-div = <2>;
+			clock-mult = <1>;
+			clocks = <&pll8x2>;
 			clock-output-names = "pll8";
+			assigned-clocks = <&pll8x2>;
+			assigned-clock-rates = <1200000000>;
 		};
 
 		cpu: cpu_clk at 01c20050 {
--- a/drivers/clk/sunxi/clk-sunxi.c	2016-02-01 08:24:06.199396132 +0100
+++ b/drivers/clk/sunxi/clk-sunxi.c	2016-02-04 16:03:41.056322804 +0100
@@ -714,6 +714,12 @@
 	.name = "pll6",
 };
 
+static const struct factors_data pll_periphx2_data __initconst = {
+	.enable = 31,
+	.table = &sun6i_a31_pll6_config,
+	.getter = sun6i_a31_get_pll6_factors,
+};
+
 static const struct factors_data sun6i_a31_pll6_data __initconst = {
 	.enable = 31,
 	.table = &sun6i_a31_pll6_config,
@@ -1110,6 +1116,7 @@
 	{.compatible = "allwinner,sun5i-a13-ahb-clk", .data = &sun5i_a13_ahb_data,},
 	{.compatible = "allwinner,sun4i-a10-apb1-clk", .data = &sun4i_apb1_data,},
 	{.compatible = "allwinner,sun7i-a20-out-clk", .data = &sun7i_a20_out_data,},
+	{.compatible = "allwinner,pll-periphx2-clk", .data = &pll_periphx2_data,},
 	{}
 };
 

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/



From dvyukov at google.com  Thu Feb  4 07:40:41 2016
From: dvyukov at google.com (Dmitry Vyukov)
Date: Thu,  4 Feb 2016 16:40:41 +0100
Subject: [PATCH v8] kernel: add kcov code coverage
Message-ID: <1454600441-70701-1-git-send-email-dvyukov@google.com>

kcov provides code coverage collection for coverage-guided fuzzing
(randomized testing). Coverage-guided fuzzing is a testing technique
that uses coverage feedback to determine new interesting inputs to a
system. A notable user-space example is AFL
(http://lcamtuf.coredump.cx/afl/). However, this technique is not
widely used for kernel testing due to missing compiler and kernel
support.

kcov does not aim to collect as much coverage as possible. It aims
to collect more or less stable coverage that is function of syscall
inputs. To achieve this goal it does not collect coverage in
soft/hard interrupts and instrumentation of some inherently
non-deterministic or non-interesting parts of kernel is disbled
(e.g. scheduler, locking).

Currently there is a single coverage collection mode (tracing),
but the API anticipates additional collection modes.
Initially I also implemented a second mode which exposes
coverage in a fixed-size hash table of counters (what Quentin
used in his original patch). I've dropped the second mode for
simplicity.

This patch adds the necessary support on kernel side.
The complimentary compiler support was added in gcc revision 231296.

We've used this support to build syzkaller system call fuzzer,
which has found 90 kernel bugs in just 2 months:
https://github.com/google/syzkaller/wiki/Found-Bugs
We've also found 30+ bugs in our internal systems with syzkaller.
Another (yet unexplored) direction where kcov coverage would greatly
help is more traditional "blob mutation". For example, mounting
a random blob as a filesystem, or receiving a random blob over wire.

Why not gcov. Typical fuzzing loop looks as follows: (1) reset
coverage, (2) execute a bit of code, (3) collect coverage, repeat.
A typical coverage can be just a dozen of basic blocks (e.g. an
invalid input). In such context gcov becomes prohibitively expensive
as reset/collect coverage steps depend on total number of basic
blocks/edges in program (in case of kernel it is about 2M). Cost of
kcov depends only on number of executed basic blocks/edges. On top of
that, kernel requires per-thread coverage because there are
always background threads and unrelated processes that also produce
coverage. With inlined gcov instrumentation per-thread coverage is not
possible.

kcov exposes kernel PCs and control flow to user-space which
is insecure. But debugfs should not be mapped as user accessible.

Based on a patch by Quentin Casasnovas.
Signed-off-by: Dmitry Vyukov <dvyukov at google.com>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
Anticipating reasonable questions regarding usage of this feature.
Quentin Casasnovas and Vegard Nossum also plan to use kcov for
coverage-guided fuzzing. Currently they use a custom kernel patch
for their fuzzer and found several dozens of bugs.
There is also interest from Intel 0-DAY kernel test infrastructure.

Based on commit b37a05c083c85c2657dca9bbe1f5d79dccf756d5.

v2: - added note to commit desciption that kcov is insecure,
      but debugfs should not be mapped as user accessible.
    - make CONFIG_KCOV depend on CONFIG_ARCH_HAS_KCOV
      instead of conditional inclusion with if/endif
      (as per Kees comments).

v3: - disabled instrumentation of lib/hweight.c
    - changed task_struct.kcov_size type to unsigned
    - moved kcov.c from kernel/kcov/ to kernel/
    - fixed multi-line comment formatting
    - changed BUG_ONs to WARN_ONs
    - added kcov_get() helper

v4: - pre-populate mapping with pages in kcov_mmap()
    - don't get kcov references on vma open/copy,
      vma holds a reference to the file which is enough
    - extend KCOV_INIT_TRACE to support both compressed
      4-byte PCs and full 8-byte PCs (it now accepts a struct)
    - update example in Documentation/kcov.txt

v5: - export only unsigned long PCs (no compression to 4 bytes)
    - remove KCOV dependency on !RANDOMIZE_BASE
    - update example in Documentation/kcov.txt
    - rename kcov_mode_trace to KCOV_MODE_TRACE
    - warn about failed vm_insert_page()
    - ensure that arg for KCOV_ENABLE/KCOV_DISABLE is 0

v6: - export kcov file as 0600 instead of 0666

v7: - select DEBUG_FS when KCOV is selected
    - disable instrumentation of drivers/firmware/efi/libstub/*

v8: - move CONFIG_KCOV from "Memory debugging" to "Kernel hacking"
---
 Documentation/kcov.txt                | 111 ++++++++++++++
 Makefile                              |  10 +-
 arch/x86/Kconfig                      |   1 +
 arch/x86/boot/Makefile                |   6 +
 arch/x86/boot/compressed/Makefile     |   2 +
 arch/x86/entry/vdso/Makefile          |   2 +
 arch/x86/kernel/Makefile              |   5 +
 arch/x86/kernel/apic/Makefile         |   4 +
 arch/x86/kernel/cpu/Makefile          |   4 +
 arch/x86/lib/Makefile                 |   3 +
 arch/x86/mm/Makefile                  |   3 +
 arch/x86/realmode/rm/Makefile         |   2 +
 drivers/firmware/efi/libstub/Makefile |   2 +
 include/linux/kcov.h                  |  19 +++
 include/linux/sched.h                 |  10 ++
 include/uapi/linux/kcov.h             |  10 ++
 kernel/Makefile                       |  12 ++
 kernel/exit.c                         |   2 +
 kernel/fork.c                         |   3 +
 kernel/kcov.c                         | 269 ++++++++++++++++++++++++++++++++++
 kernel/locking/Makefile               |   3 +
 kernel/rcu/Makefile                   |   4 +
 kernel/sched/Makefile                 |   4 +
 lib/Kconfig.debug                     |  21 +++
 lib/Makefile                          |  12 ++
 mm/Makefile                           |  15 ++
 mm/kasan/Makefile                     |   1 +
 scripts/Makefile.lib                  |   6 +
 28 files changed, 545 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/kcov.txt
 create mode 100644 include/linux/kcov.h
 create mode 100644 include/uapi/linux/kcov.h
 create mode 100644 kernel/kcov.c

diff --git a/Documentation/kcov.txt b/Documentation/kcov.txt
new file mode 100644
index 0000000..779ff4a
--- /dev/null
+++ b/Documentation/kcov.txt
@@ -0,0 +1,111 @@
+kcov: code coverage for fuzzing
+===============================
+
+kcov exposes kernel code coverage information in a form suitable for coverage-
+guided fuzzing (randomized testing). Coverage data of a running kernel is
+exported via the "kcov" debugfs file. Coverage collection is enabled on a task
+basis, and thus it can capture precise coverage of a single system call.
+
+Note that kcov does not aim to collect as much coverage as possible. It aims
+to collect more or less stable coverage that is function of syscall inputs.
+To achieve this goal it does not collect coverage in soft/hard interrupts
+and instrumentation of some inherently non-deterministic parts of kernel is
+disbled (e.g. scheduler, locking).
+
+Usage:
+======
+
+Configure kernel with:
+
+        CONFIG_KCOV=y
+
+CONFIG_KCOV requires gcc built on revision 231296 or later.
+Profiling data will only become accessible once debugfs has been mounted:
+
+        mount -t debugfs none /sys/kernel/debug
+
+The following program demonstrates kcov usage from within a test program:
+
+#include <stdio.h>
+#include <stddef.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <unistd.h>
+#include <fcntl.h>
+
+#define KCOV_INIT_TRACE			_IOR('c', 1, unsigned long)
+#define KCOV_ENABLE			_IO('c', 100)
+#define KCOV_DISABLE			_IO('c', 101)
+#define COVER_SIZE			(64<<10)
+
+int main(int argc, char **argv)
+{
+	int fd;
+	unsigned long *cover, n, i;
+
+	/* A single fd descriptor allows coverage collection on a single
+	 * thread.
+	 */
+	fd = open("/sys/kernel/debug/kcov", O_RDWR);
+	if (fd == -1)
+		perror("open"), exit(1);
+	/* Setup trace mode and trace size. */
+	if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE))
+		perror("ioctl"), exit(1);
+	/* Mmap buffer shared between kernel- and user-space. */
+	cover = (unsigned long*)mmap(NULL, COVER_SIZE * sizeof(unsigned long),
+				     PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
+	if ((void*)cover == MAP_FAILED)
+		perror("mmap"), exit(1);
+	/* Enable coverage collection on the current thread. */
+	if (ioctl(fd, KCOV_ENABLE, 0))
+		perror("ioctl"), exit(1);
+	/* Reset coverage from the tail of the ioctl() call. */
+	__atomic_store_n(&cover[0], 0, __ATOMIC_RELAXED);
+	/* That's the target syscal call. */
+	read(-1, NULL, 0);
+	/* Read number of PCs collected. */
+	n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED);
+	for (i = 0; i < n; i++)
+		printf("0x%lx\n", cover[i + 1]);
+	/* Disable coverage collection for the current thread. After this call
+	 * coverage can be enabled for a different thread.
+	 */
+	if (ioctl(fd, KCOV_DISABLE, 0))
+		perror("ioctl"), exit(1);
+	/* Free resources. */
+	if (munmap(cover, COVER_SIZE * sizeof(unsigned long)))
+		perror("munmap"), exit(1);
+	if (close(fd))
+		perror("close"), exit(1);
+	return 0;
+}
+
+After piping through addr2line output of the program looks as follows:
+
+SyS_read
+fs/read_write.c:562
+__fdget_pos
+fs/file.c:774
+__fget_light
+fs/file.c:746
+__fget_light
+fs/file.c:750
+__fget_light
+fs/file.c:760
+__fdget_pos
+fs/file.c:784
+SyS_read
+fs/read_write.c:562
+
+If a program needs to collect coverage from several threads (independently),
+it needs to open /sys/kernel/debug/kcov in each thread separately.
+
+The interface is fine-grained to allow efficient forking of test processes.
+That is, a parent process opens /sys/kernel/debug/kcov, enables trace mode,
+mmaps coverage buffer and then forks child processes in a loop. Child processes
+only need to enable coverage (disable happens automatically on thread end).
diff --git a/Makefile b/Makefile
index 6c1a3c2..574ccc4a 100644
--- a/Makefile
+++ b/Makefile
@@ -365,6 +365,7 @@ LDFLAGS_MODULE  =
 CFLAGS_KERNEL	=
 AFLAGS_KERNEL	=
 CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage
+CFLAGS_KCOV	= -fsanitize-coverage=trace-pc
 
 
 # Use USERINCLUDE when you must reference the UAPI directories only.
@@ -411,7 +412,7 @@ export MAKE AWK GENKSYMS INSTALLKERNEL PERL PYTHON UTS_MACHINE
 export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
 
 export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
-export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV CFLAGS_KASAN CFLAGS_UBSAN
+export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_GCOV CFLAGS_KCOV CFLAGS_KASAN CFLAGS_UBSAN
 export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
 export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
 export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
@@ -673,6 +674,13 @@ endif
 endif
 KBUILD_CFLAGS += $(stackp-flag)
 
+ifdef CONFIG_KCOV
+  ifeq ($(call cc-option, $(CFLAGS_KCOV)),)
+    $(warning Cannot use CONFIG_KCOV: \
+             -fsanitize-coverage=trace-pc is not supported by compiler)
+  endif
+endif
+
 ifeq ($(cc-name),clang)
 KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
 KBUILD_CPPFLAGS += $(call cc-option,-Wno-unknown-warning-option,)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9af2e63..e102416 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -28,6 +28,7 @@ config X86
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_FAST_MULTIPLIER
 	select ARCH_HAS_GCOV_PROFILE_ALL
+	select ARCH_HAS_KCOV			if X86_64
 	select ARCH_HAS_PMEM_API		if X86_64
 	select ARCH_HAS_MMIO_FLUSH
 	select ARCH_HAS_SG_CHAIN
diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
index bbe1a62..5f93ca0 100644
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -10,6 +10,12 @@
 #
 
 KASAN_SANITIZE := n
+# Kernel does not boot with kcov instrumentation here.
+# One of the problems observed was insertion of __sanitizer_cov_trace_pc()
+# callback into middle of per-cpu data enabling code. Thus the callback observed
+# inconsistent state and crashed. We are interested mostly in syscall coverage,
+# so boot code is not interesting anyway.
+KCOV_INSTRUMENT := n
 
 # If you want to preset the SVGA mode, uncomment the next line and
 # set SVGA_MODE to whatever number you want.
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index f9ce75d..ad9e9fa 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -17,6 +17,8 @@
 #	compressed vmlinux.bin.all + u32 size of vmlinux.bin.all
 
 KASAN_SANITIZE := n
+# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
+KCOV_INSTRUMENT := n
 
 targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma \
 	vmlinux.bin.xz vmlinux.bin.lzo vmlinux.bin.lz4
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index c854541..5a19939 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -5,6 +5,8 @@
 KBUILD_CFLAGS += $(DISABLE_LTO)
 KASAN_SANITIZE := n
 UBSAN_SANITIZE := n
+# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
+KCOV_INSTRUMENT := n
 
 VDSO64-$(CONFIG_X86_64)		:= y
 VDSOX32-$(CONFIG_X86_X32_ABI)	:= y
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index b1b78ff..4648960 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -19,6 +19,11 @@ endif
 KASAN_SANITIZE_head$(BITS).o := n
 KASAN_SANITIZE_dumpstack.o := n
 KASAN_SANITIZE_dumpstack_$(BITS).o := n
+# If instrumentation of this dir is enabled, boot hangs during first second.
+# Probably could be more selective here, but note that files related to irqs,
+# boot, dumpstack/stacktrace, etc are either non-interesting or can lead to
+# non-deterministic coverage.
+KCOV_INSTRUMENT := n
 
 CFLAGS_irq.o := -I$(src)/../include/asm/trace
 
diff --git a/arch/x86/kernel/apic/Makefile b/arch/x86/kernel/apic/Makefile
index 8bb12dd..8f2a3d7 100644
--- a/arch/x86/kernel/apic/Makefile
+++ b/arch/x86/kernel/apic/Makefile
@@ -2,6 +2,10 @@
 # Makefile for local APIC drivers and for the IO-APIC code
 #
 
+# Leads to non-deterministic coverage that is not a function of syscall inputs.
+# In particualr, smp_apic_timer_interrupt() is called in random places.
+KCOV_INSTRUMENT := n
+
 obj-$(CONFIG_X86_LOCAL_APIC)	+= apic.o apic_noop.o ipi.o vector.o
 obj-y				+= hw_nmi.o
 
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 5803130..c108683 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -8,6 +8,10 @@ CFLAGS_REMOVE_common.o = -pg
 CFLAGS_REMOVE_perf_event.o = -pg
 endif
 
+# If these files are instrumented, boot hangs during the first second.
+KCOV_INSTRUMENT_common.o := n
+KCOV_INSTRUMENT_perf_event.o := n
+
 # Make sure load_percpu_segment has no stackprotector
 nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_common.o		:= $(nostackp)
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index a501fa2..fefca94 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -2,6 +2,9 @@
 # Makefile for x86 specific library files.
 #
 
+# Produces uninteresting flaky coverage.
+KCOV_INSTRUMENT_delay.o := n
+
 inat_tables_script = $(srctree)/arch/x86/tools/gen-insn-attr-x86.awk
 inat_tables_maps = $(srctree)/arch/x86/lib/x86-opcode-map.txt
 quiet_cmd_inat_tables = GEN     $@
diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile
index f9d38a4..147def6 100644
--- a/arch/x86/mm/Makefile
+++ b/arch/x86/mm/Makefile
@@ -1,3 +1,6 @@
+# Kernel does not boot with instrumentation of tlb.c.
+KCOV_INSTRUMENT_tlb.o := n
+
 obj-y	:=  init.o init_$(BITS).o fault.o ioremap.o extable.o pageattr.o mmap.o \
 	    pat.o pgtable.o physaddr.o gup.o setup_nx.o
 
diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile
index 3e75fcf..35129dc 100644
--- a/arch/x86/realmode/rm/Makefile
+++ b/arch/x86/realmode/rm/Makefile
@@ -7,6 +7,8 @@
 #
 #
 KASAN_SANITIZE := n
+# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
+KCOV_INSTRUMENT := n
 
 always := realmode.bin realmode.relocs
 
diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index aaf9c0b..37cc9e3 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -23,6 +23,8 @@ KBUILD_CFLAGS			:= $(cflags-y) -DDISABLE_BRANCH_PROFILING \
 GCOV_PROFILE			:= n
 KASAN_SANITIZE			:= n
 UBSAN_SANITIZE			:= n
+# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
+KCOV_INSTRUMENT			:= n
 
 lib-y				:= efi-stub-helper.o
 
diff --git a/include/linux/kcov.h b/include/linux/kcov.h
new file mode 100644
index 0000000..72ff663
--- /dev/null
+++ b/include/linux/kcov.h
@@ -0,0 +1,19 @@
+#ifndef _LINUX_KCOV_H
+#define _LINUX_KCOV_H
+
+#include <uapi/linux/kcov.h>
+
+struct task_struct;
+
+#ifdef CONFIG_KCOV
+
+void kcov_task_init(struct task_struct *t);
+void kcov_task_exit(struct task_struct *t);
+
+#else
+
+static inline void kcov_task_init(struct task_struct *t) {}
+static inline void kcov_task_exit(struct task_struct *t) {}
+
+#endif /* CONFIG_KCOV */
+#endif /* _LINUX_KCOV_H */
diff --git a/include/linux/sched.h b/include/linux/sched.h
index a10494a..bbd991e 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1811,6 +1811,16 @@ struct task_struct {
 	/* bitmask and counter of trace recursion */
 	unsigned long trace_recursion;
 #endif /* CONFIG_TRACING */
+#ifdef CONFIG_KCOV
+	/* Coverage collection mode enabled for this task (0 if disabled). */
+	int		kcov_mode;
+	/* Size of the kcov_area. */
+	unsigned	kcov_size;
+	/* Buffer for coverage collection. */
+	void		*kcov_area;
+	/* kcov desciptor wired with this task or NULL. */
+	struct kcov	*kcov;
+#endif
 #ifdef CONFIG_MEMCG
 	struct mem_cgroup *memcg_in_oom;
 	gfp_t memcg_oom_gfp_mask;
diff --git a/include/uapi/linux/kcov.h b/include/uapi/linux/kcov.h
new file mode 100644
index 0000000..574e22e
--- /dev/null
+++ b/include/uapi/linux/kcov.h
@@ -0,0 +1,10 @@
+#ifndef _LINUX_KCOV_IOCTLS_H
+#define _LINUX_KCOV_IOCTLS_H
+
+#include <linux/types.h>
+
+#define KCOV_INIT_TRACE			_IOR('c', 1, unsigned long)
+#define KCOV_ENABLE			_IO('c', 100)
+#define KCOV_DISABLE			_IO('c', 101)
+
+#endif /* _LINUX_KCOV_IOCTLS_H */
diff --git a/kernel/Makefile b/kernel/Makefile
index 53abf00..2dea801 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -19,6 +19,17 @@ CFLAGS_REMOVE_cgroup-debug.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_irq_work.o = $(CC_FLAGS_FTRACE)
 endif
 
+# Prevents flicker of uninteresting __do_softirq()/__local_bh_disable_ip()
+# in coverage traces.
+KCOV_INSTRUMENT_softirq.o := n
+# These are called from save_stack_trace() on slub debug path,
+# and produce insane amounts of uninteresting coverage.
+KCOV_INSTRUMENT_module.o := n
+KCOV_INSTRUMENT_extable.o := n
+# Don't self-instrument.
+KCOV_INSTRUMENT_kcov.o := n
+KASAN_SANITIZE_kcov.o := n
+
 # cond_syscall is currently not LTO compatible
 CFLAGS_sys_ni.o = $(DISABLE_LTO)
 
@@ -69,6 +80,7 @@ obj-$(CONFIG_AUDITSYSCALL) += auditsc.o
 obj-$(CONFIG_AUDIT_WATCH) += audit_watch.o audit_fsnotify.o
 obj-$(CONFIG_AUDIT_TREE) += audit_tree.o
 obj-$(CONFIG_GCOV_KERNEL) += gcov/
+obj-$(CONFIG_KCOV) += kcov.o
 obj-$(CONFIG_KPROBES) += kprobes.o
 obj-$(CONFIG_KGDB) += debug/
 obj-$(CONFIG_DETECT_HUNG_TASK) += hung_task.o
diff --git a/kernel/exit.c b/kernel/exit.c
index 10e0882..953d1a1 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -53,6 +53,7 @@
 #include <linux/oom.h>
 #include <linux/writeback.h>
 #include <linux/shm.h>
+#include <linux/kcov.h>
 
 #include <asm/uaccess.h>
 #include <asm/unistd.h>
@@ -655,6 +656,7 @@ void do_exit(long code)
 	TASKS_RCU(int tasks_rcu_i);
 
 	profile_task_exit(tsk);
+	kcov_task_exit(tsk);
 
 	WARN_ON(blk_needs_flush_plug(tsk));
 
diff --git a/kernel/fork.c b/kernel/fork.c
index 2e391c7..7c222c5 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -75,6 +75,7 @@
 #include <linux/aio.h>
 #include <linux/compiler.h>
 #include <linux/sysctl.h>
+#include <linux/kcov.h>
 
 #include <asm/pgtable.h>
 #include <asm/pgalloc.h>
@@ -384,6 +385,8 @@ static struct task_struct *dup_task_struct(struct task_struct *orig)
 
 	account_kernel_stack(ti, 1);
 
+	kcov_task_init(tsk);
+
 	return tsk;
 
 free_ti:
diff --git a/kernel/kcov.c b/kernel/kcov.c
new file mode 100644
index 0000000..662c401
--- /dev/null
+++ b/kernel/kcov.c
@@ -0,0 +1,269 @@
+#define pr_fmt(fmt) "kcov: " fmt
+
+#include <linux/compiler.h>
+#include <linux/types.h>
+#include <linux/file.h>
+#include <linux/fs.h>
+#include <linux/mm.h>
+#include <linux/printk.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/vmalloc.h>
+#include <linux/debugfs.h>
+#include <linux/uaccess.h>
+#include <linux/kcov.h>
+
+enum kcov_mode {
+	/*
+	 * Tracing coverage collection mode.
+	 * Covered PCs are collected in a per-task buffer.
+	 */
+	KCOV_MODE_TRACE = 1,
+};
+
+/*
+ * kcov descriptor (one per opened debugfs file).
+ * State transitions of the descriptor:
+ *  - initial state after open()
+ *  - then there must be a single ioctl(KCOV_INIT_TRACE) call
+ *  - then, mmap() call (several calls are allowed but not useful)
+ *  - then, repeated enable/disable for a task (only one task a time allowed)
+ */
+struct kcov {
+	/*
+	 * Reference counter. We keep one for:
+	 *  - opened file descriptor
+	 *  - task with enabled coverage (we can't unwire it from another task)
+	 */
+	atomic_t		rc;
+	/* The lock protects mode, size, area and t. */
+	spinlock_t		lock;
+	enum kcov_mode		mode;
+	unsigned		size;
+	void			*area;
+	struct task_struct	*t;
+};
+
+/*
+ * Entry point from instrumented code.
+ * This is called once per basic-block/edge.
+ */
+void __sanitizer_cov_trace_pc(void)
+{
+	struct task_struct *t;
+	enum kcov_mode mode;
+
+	t = current;
+	/*
+	 * We are interested in code coverage as a function of a syscall inputs,
+	 * so we ignore code executed in interrupts.
+	 */
+	if (!t || in_interrupt())
+		return;
+	mode = READ_ONCE(t->kcov_mode);
+	if (mode == KCOV_MODE_TRACE) {
+		unsigned long *area;
+		unsigned long pos;
+
+		/*
+		 * There is some code that runs in interrupts but for which
+		 * in_interrupt() returns false (e.g. preempt_schedule_irq()).
+		 * READ_ONCE()/barrier() effectively provides load-acquire wrt
+		 * interrupts, there are paired barrier()/WRITE_ONCE() in
+		 * kcov_ioctl_locked().
+		 */
+		barrier();
+		area = t->kcov_area;
+		/* The first word is number of subsequent PCs. */
+		pos = READ_ONCE(area[0]) + 1;
+		if (likely(pos < t->kcov_size)) {
+			area[pos] = _RET_IP_;
+			WRITE_ONCE(area[0], pos);
+		}
+	}
+}
+EXPORT_SYMBOL(__sanitizer_cov_trace_pc);
+
+static void kcov_get(struct kcov *kcov)
+{
+	atomic_inc(&kcov->rc);
+}
+
+static void kcov_put(struct kcov *kcov)
+{
+	if (atomic_dec_and_test(&kcov->rc)) {
+		vfree(kcov->area);
+		kfree(kcov);
+	}
+}
+
+void kcov_task_init(struct task_struct *t)
+{
+	t->kcov_mode = 0;
+	t->kcov_size = 0;
+	t->kcov_area = NULL;
+	t->kcov = NULL;
+}
+
+void kcov_task_exit(struct task_struct *t)
+{
+	struct kcov *kcov;
+
+	kcov = t->kcov;
+	if (kcov == NULL)
+		return;
+	spin_lock(&kcov->lock);
+	if (WARN_ON(kcov->t != t)) {
+		spin_unlock(&kcov->lock);
+		return;
+	}
+	/* Just to not leave dangling references behind. */
+	kcov_task_init(t);
+	kcov->t = NULL;
+	spin_unlock(&kcov->lock);
+	kcov_put(kcov);
+}
+
+static int kcov_mmap(struct file *filep, struct vm_area_struct *vma)
+{
+	int res = 0;
+	void *area;
+	struct kcov *kcov = vma->vm_file->private_data;
+	unsigned long size, off;
+	struct page *page;
+
+	area = vmalloc_user(vma->vm_end - vma->vm_start);
+	if (!area)
+		return -ENOMEM;
+
+	spin_lock(&kcov->lock);
+	size = kcov->size * sizeof(unsigned long);
+	if (kcov->mode == 0 || vma->vm_pgoff != 0 ||
+	    vma->vm_end - vma->vm_start != size) {
+		res = -EINVAL;
+		goto exit;
+	}
+	if (!kcov->area) {
+		kcov->area = area;
+		vma->vm_flags |= VM_DONTEXPAND;
+		spin_unlock(&kcov->lock);
+		for (off = 0; off < size; off += PAGE_SIZE) {
+			page = vmalloc_to_page(kcov->area + off);
+			if (vm_insert_page(vma, vma->vm_start + off, page))
+				WARN_ONCE(1, "vm_insert_page() failed");
+		}
+		return 0;
+	}
+exit:
+	spin_unlock(&kcov->lock);
+	vfree(area);
+	return res;
+}
+
+static int kcov_open(struct inode *inode, struct file *filep)
+{
+	struct kcov *kcov;
+
+	kcov = kzalloc(sizeof(*kcov), GFP_KERNEL);
+	if (!kcov)
+		return -ENOMEM;
+	atomic_set(&kcov->rc, 1);
+	spin_lock_init(&kcov->lock);
+	filep->private_data = kcov;
+	return nonseekable_open(inode, filep);
+}
+
+static int kcov_close(struct inode *inode, struct file *filep)
+{
+	kcov_put(filep->private_data);
+	return 0;
+}
+
+static int kcov_ioctl_locked(struct kcov *kcov, unsigned int cmd,
+			     unsigned long arg)
+{
+	struct task_struct *t;
+
+	switch (cmd) {
+	case KCOV_INIT_TRACE:
+		/*
+		 * Enable kcov in trace mode and setup buffer size.
+		 * Must happen before anything else.
+		 * Size must be at least 2 to hold current position and one PC.
+		 */
+		if (arg < 2 || arg > INT_MAX)
+			return -EINVAL;
+		if (kcov->mode != 0)
+			return -EBUSY;
+		kcov->mode = KCOV_MODE_TRACE;
+		kcov->size = arg;
+		return 0;
+	case KCOV_ENABLE:
+		/*
+		 * Enable coverage for the current task.
+		 * At this point user must have been enabled trace mode,
+		 * and mmapped the file. Coverage collection is disabled only
+		 * at task exit or voluntary by KCOV_DISABLE. After that it can
+		 * be enabled for another task.
+		 */
+		if (arg != 0 || kcov->mode == 0 || kcov->area == NULL)
+			return -EINVAL;
+		if (kcov->t != NULL)
+			return -EBUSY;
+		t = current;
+		/* Cache in task struct for performance. */
+		t->kcov_size = kcov->size;
+		t->kcov_area = kcov->area;
+		/* See comment in __sanitizer_cov_trace_pc(). */
+		barrier();
+		WRITE_ONCE(t->kcov_mode, kcov->mode);
+		t->kcov = kcov;
+		kcov->t = t;
+		/* This is put either in kcov_task_exit() or in KCOV_DISABLE. */
+		kcov_get(kcov);
+		return 0;
+	case KCOV_DISABLE:
+		/* Disable coverage for the current task. */
+		if (arg != 0 || current->kcov != kcov)
+			return -EINVAL;
+		t = current;
+		if (WARN_ON(kcov->t != t))
+			return -EINVAL;
+		kcov_task_init(t);
+		kcov->t = NULL;
+		kcov_put(kcov);
+		return 0;
+	default:
+		return -EINVAL;
+	}
+}
+
+static long kcov_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
+{
+	struct kcov *kcov;
+	int res;
+
+	kcov = filep->private_data;
+	spin_lock(&kcov->lock);
+	res = kcov_ioctl_locked(kcov, cmd, arg);
+	spin_unlock(&kcov->lock);
+	return res;
+}
+
+static const struct file_operations kcov_fops = {
+	.open		= kcov_open,
+	.unlocked_ioctl	= kcov_ioctl,
+	.mmap		= kcov_mmap,
+	.release        = kcov_close,
+};
+
+static int __init kcov_init(void)
+{
+	if (!debugfs_create_file("kcov", 0600, NULL, NULL, &kcov_fops)) {
+		pr_err("failed to create kcov in debugfs\n");
+		return -ENOMEM;
+	}
+	return 0;
+}
+
+device_initcall(kcov_init);
diff --git a/kernel/locking/Makefile b/kernel/locking/Makefile
index 8e96f6c..f816de9 100644
--- a/kernel/locking/Makefile
+++ b/kernel/locking/Makefile
@@ -1,3 +1,6 @@
+# Any varying coverage in these files is non-deterministic
+# and is generally not a function of system call inputs.
+KCOV_INSTRUMENT := n
 
 obj-y += mutex.o semaphore.o rwsem.o percpu-rwsem.o
 
diff --git a/kernel/rcu/Makefile b/kernel/rcu/Makefile
index 61a1656..032b2c0 100644
--- a/kernel/rcu/Makefile
+++ b/kernel/rcu/Makefile
@@ -1,3 +1,7 @@
+# Any varying coverage in these files is non-deterministic
+# and is generally not a function of system call inputs.
+KCOV_INSTRUMENT := n
+
 obj-y += update.o sync.o
 obj-$(CONFIG_SRCU) += srcu.o
 obj-$(CONFIG_RCU_TORTURE_TEST) += rcutorture.o
diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
index 6768797..f0a9265 100644
--- a/kernel/sched/Makefile
+++ b/kernel/sched/Makefile
@@ -2,6 +2,10 @@ ifdef CONFIG_FUNCTION_TRACER
 CFLAGS_REMOVE_clock.o = $(CC_FLAGS_FTRACE)
 endif
 
+# These files are disabled because they produce non-interesting flaky coverage
+# that is not a function of syscall inputs. E.g. involuntary context switches.
+KCOV_INSTRUMENT := n
+
 ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER),y)
 # According to Alan Modra <alan at linuxcare.com.au>, the -fno-omit-frame-pointer is
 # needed for x86 only.  Why this used to be enabled for all architectures is beyond
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ecb9e75..431c748e 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -684,6 +684,27 @@ source "lib/Kconfig.kasan"
 
 endmenu # "Memory Debugging"
 
+config ARCH_HAS_KCOV
+	bool
+	help
+	  KCOV does not have any arch-specific code, but currently it is enabled
+	  only for x86_64. KCOV requires testing on other archs, and most likely
+	  disabling of instrumentation for some early boot code.
+
+config KCOV
+	bool "Code coverage for fuzzing"
+	depends on ARCH_HAS_KCOV
+	select DEBUG_FS
+	help
+	  KCOV exposes kernel code coverage information in a form suitable
+	  for coverage-guided fuzzing (randomized testing).
+
+	  If RANDOMIZE_BASE is enabled, PC values will not be stable across
+	  different machines and across reboots. If you need stable PC values,
+	  disable RANDOMIZE_BASE.
+
+	  For more details, see Documentation/kcov.txt.
+
 config DEBUG_SHIRQ
 	bool "Debug shared IRQ handlers"
 	depends on DEBUG_KERNEL
diff --git a/lib/Makefile b/lib/Makefile
index a7c26a4..309aaf7 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -7,6 +7,18 @@ ORIG_CFLAGS := $(KBUILD_CFLAGS)
 KBUILD_CFLAGS = $(subst $(CC_FLAGS_FTRACE),,$(ORIG_CFLAGS))
 endif
 
+# These files are disabled because they produce lots of non-interesting and/or
+# flaky coverage that is not a function of syscall inputs. For example,
+# rbtree can be global and individual rotations don't correlate with inputs.
+KCOV_INSTRUMENT_string.o := n
+KCOV_INSTRUMENT_rbtree.o := n
+KCOV_INSTRUMENT_list_debug.o := n
+KCOV_INSTRUMENT_debugobjects.o := n
+KCOV_INSTRUMENT_dynamic_debug.o := n
+# Kernel does not boot if we instrument this file as it uses custom calling
+# convention (see CONFIG_ARCH_HWEIGHT_CFLAGS).
+KCOV_INSTRUMENT_hweight.o := n
+
 lib-y := ctype.o string.o vsprintf.o cmdline.o \
 	 rbtree.o radix-tree.o dump_stack.o timerqueue.o\
 	 idr.o int_sqrt.o extable.o \
diff --git a/mm/Makefile b/mm/Makefile
index 2ed4319..cf751bb 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -5,6 +5,21 @@
 KASAN_SANITIZE_slab_common.o := n
 KASAN_SANITIZE_slub.o := n
 
+# These files are disabled because they produce non-interesting and/or
+# flaky coverage that is not a function of syscall inputs. E.g. slab is out of
+# free pages, or a task is migrated between nodes.
+KCOV_INSTRUMENT_slab_common.o := n
+KCOV_INSTRUMENT_slob.o := n
+KCOV_INSTRUMENT_slab.o := n
+KCOV_INSTRUMENT_slub.o := n
+KCOV_INSTRUMENT_page_alloc.o := n
+KCOV_INSTRUMENT_debug-pagealloc.o := n
+KCOV_INSTRUMENT_kmemleak.o := n
+KCOV_INSTRUMENT_kmemcheck.o := n
+KCOV_INSTRUMENT_memcontrol.o := n
+KCOV_INSTRUMENT_mmzone.o := n
+KCOV_INSTRUMENT_vmstat.o := n
+
 mmu-y			:= nommu.o
 mmu-$(CONFIG_MMU)	:= gup.o highmem.o memory.o mincore.o \
 			   mlock.o mmap.o mprotect.o mremap.o msync.o rmap.o \
diff --git a/mm/kasan/Makefile b/mm/kasan/Makefile
index a61460d..131daad 100644
--- a/mm/kasan/Makefile
+++ b/mm/kasan/Makefile
@@ -1,5 +1,6 @@
 KASAN_SANITIZE := n
 UBSAN_SANITIZE_kasan.o := n
+KCOV_INSTRUMENT := n
 
 CFLAGS_REMOVE_kasan.o = -pg
 # Function splitter causes unnecessary splits in __asan_load1/__asan_store1
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 2edbcad..31d7a73 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -136,6 +136,12 @@ _c_flags += $(if $(patsubst n%,, \
 		$(CFLAGS_UBSAN))
 endif
 
+ifeq ($(CONFIG_KCOV),y)
+_c_flags += $(if $(patsubst n%,, \
+	$(KCOV_INSTRUMENT_$(basetarget).o)$(KCOV_INSTRUMENT)y), \
+	$(CFLAGS_KCOV))
+endif
+
 # If building the kernel in a separate objtree expand all occurrences
 # of -Idir to -I$(srctree)/dir except for absolute paths (starting with '/').
 
-- 
2.7.0.rc3.207.g0ac5344



From vincent.guittot at linaro.org  Thu Feb  4 07:44:28 2016
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 4 Feb 2016 16:44:28 +0100
Subject: [PATCH v3 2/6] drivers/cpufreq: implement
 init_cpu_capacity_default()
In-Reply-To: <20160204141345.GD29586@e106622-lin>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <1454500799-18451-3-git-send-email-juri.lelli@arm.com>
 <CAKfTPtDGk5BC25WqHdhDYDOBgUsuidAMhrXS=eDi6wJPZjfrwA@mail.gmail.com>
 <20160204093559.GA14099@e105550-lin.cambridge.arm.com>
 <CAKfTPtB4G3bP5N0hU6zWXJTddO34x3RnyGpp-4_otc8O=Wq2hw@mail.gmail.com>
 <20160204121620.GB29586@e106622-lin>
 <CAKfTPtDVasamRtG2kLxP0HsohmVQTPrXRgx36e+jb3gozDoo6g@mail.gmail.com>
 <20160204141345.GD29586@e106622-lin>
Message-ID: <CAKfTPtDWP-AgqXsSuxCfVj33dh+i7oqDTkL=gUy7n-AB1anoow@mail.gmail.com>

On 4 February 2016 at 15:13, Juri Lelli <juri.lelli at arm.com> wrote:
> On 04/02/16 13:35, Vincent Guittot wrote:
>> On 4 February 2016 at 13:16, Juri Lelli <juri.lelli at arm.com> wrote:
>> > Hi Vincent,
>> >
>> > On 04/02/16 13:03, Vincent Guittot wrote:
>> >> On 4 February 2016 at 10:36, Morten Rasmussen <morten.rasmussen at arm.com> wrote:
>> >> > On Wed, Feb 03, 2016 at 10:04:37PM +0100, Vincent Guittot wrote:
>> >> >> On 3 February 2016 at 12:59, Juri Lelli <juri.lelli at arm.com> wrote:
>> >>
>> >> [snip]
>> >>
>> >> >> > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>> >> >> > index 9e63fb1..c4025fd 100644
>> >> >> > --- a/drivers/cpufreq/Makefile
>> >> >> > +++ b/drivers/cpufreq/Makefile
>> >> >> > @@ -1,5 +1,5 @@
>> >> >> >  # CPUfreq core
>> >> >> > -obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o
>> >> >> > +obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o cpufreq_capacity.o
>> >> >>
>> >> >> Do you really want to have the calibration of capacity dependent of
>> >> >> cpufreq ? It means that we can't use it without a cpufreq driver.
>> >> >> IMHO, this creates a unnecessary dependency. I understand that you
>> >> >> must ensure that core runs at max fequency if a driver is present but
>> >> >> you should be able to calibrate the capacity if cpufreq is not
>> >> >> available but you have different capacity because micro architecture
>> >> >
>> >> > We could remove the dependency on cpufreq, but it would make things more
>> >> > complicated for systems which do have frequency scaling as we would have
>> >> > to either:
>> >> >
>> >> > 1) Run the calibration again once cpufreq has been initialized.
>> >>
>> >> or wait and let time for a driver to initialize and trig the
>> >> calibration. If calibration has not been done at the end of the boot,
>> >> you can force a calibration. If the cpufeq driver is a module and is
>> >> loaded far later for any good or bad reason, we will have to run the
>> >> calibration once again but at least the capacity will reflect he
>> >> current capacity of the CPUs.
>> >> I'm mainly worried that the compilation of the calibration is
>> >> dependent of CONFIG_CPU_FREQ not that cpufreq can trig the calibration
>> >> sequence
>> >>
>> >
>> > Yes, I guess we can make this work in some way. Out of curiosity,
>> > though, are out there heterogenous platforms that don't use cpufreq?
>>
>> At least, you can find several heterogeneous platforms without OPP
>> table for CPUs in the kernel. That's probably a temporary situation
>> but which can become a permanent one. It means that we can't calibrate
>> the CPUs for these platforms.
>>
>
> Sorry, can you make some examples so that I'm sure I understand what you
> are referring to?

As an example, the uniphier arm64 Soc doesn't have a cpufreq driver so far

>
> Anyway, don't these platform still make use of cpufreq (even if without
> an OPP table) so that we can still control policy->max and min?

AFAICT, They don't have a dedicated cpufreq driver.

More generally speaking, it can take time before having

>
> Thanks,
>
> - Juri


From ulf.hansson at linaro.org  Thu Feb  4 07:44:59 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 4 Feb 2016 16:44:59 +0100
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
Message-ID: <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>

On 28 January 2016 at 17:33, Jon Hunter <jonathanh at nvidia.com> wrote:
> Adds generic PM support to the PMC driver where the PM domains are
> populated from device-tree and the PM domain consumer devices are
> bound to their relevant PM domains via device-tree as well.
>
> Update the tegra_powergate_sequence_power_up() API so that internally
> it calls the same tegra_powergate_xxx functions that are used by the
> tegra generic power domain code for consistency.
>
> This is based upon work by Thierry Reding <treding at nvidia.com>
> and Vince Hsu <vinceh at nvidia.com>.
>
> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
> ---
>  drivers/soc/tegra/pmc.c                     | 470 ++++++++++++++++++++++++++--
>  include/dt-bindings/power/tegra-powergate.h |  36 +++
>  include/soc/tegra/pmc.h                     |  39 +--

I suggest you split the header changes into a separate patch.

Moreover, these new DT definitions should be documented in the patch
describing the new powergate DT bindings. At least a simple list
providing the available options.

[...]

>
> +static void tegra_powergate_disable_clocks(struct tegra_powergate *pg)
> +{
> +       unsigned int i;
> +
> +       for (i = 0; i < pg->num_clks; i++)
> +               clk_disable_unprepare(pg->clks[i]);
> +}
> +
> +static int tegra_powergate_enable_clocks(struct tegra_powergate *pg)
> +{
> +       unsigned int i;
> +       int err;
> +
> +       for (i = 0; i < pg->num_clks; i++) {
> +               err = clk_prepare_enable(pg->clks[i]);
> +               if (err)
> +                       goto out;
> +       }
> +
> +       return 0;
> +
> +out:
> +       while (i--)
> +               clk_disable_unprepare(pg->clks[i]);
> +
> +       return err;
> +}

I have seen similar code around in other PM domains, dealing with
enabling/disabling a *list* of clocks.
Perhaps we should invent a new clock API that helps with this to
prevents code duplication!?

[...]

>  /**
>   * tegra_powergate_power_on() - power on partition
>   * @id: partition ID
> @@ -319,35 +512,20 @@ EXPORT_SYMBOL(tegra_powergate_remove_clamping);
>  int tegra_powergate_sequence_power_up(unsigned int id, struct clk *clk,
>                                       struct reset_control *rst)

There seems to be two viable ways for a driver to control tegra powergates.

1)
$Subject patch enables the use of runtime PM.

2)
The current tegra_powergate_sequence_power_up() and
tegra_powergate_power_off() API.

It seems fragile to allow both options, but perhaps your are
protecting this with some lock to prevent concurrent accesses?

Also, I assume you need the two options in a transition phase, before
you have deployed runtime PM for these drivers?

[...]

> +static int tegra_powergate_of_get_clks(struct device *dev,
> +                                      struct tegra_powergate *pg)
> +{
> +       struct clk *clk;
> +       unsigned int i;
> +       int err;
> +
> +       pg->num_clks = of_count_phandle_with_args(pg->of_node, "clocks",
> +                                                 "#clock-cells");
> +       if (pg->num_clks == 0)
> +               return -ENODEV;
> +
> +       pg->clks = devm_kcalloc(dev, pg->num_clks, sizeof(clk), GFP_KERNEL);
> +       if (!pg->clks)
> +               return -ENOMEM;
> +
> +       for (i = 0; i < pg->num_clks; i++) {
> +               pg->clks[i] = of_clk_get(pg->of_node, i);
> +               if (IS_ERR(pg->clks[i])) {
> +                       err = PTR_ERR(pg->clks[i]);
> +                       goto err;
> +               }
> +       }
> +
> +       return 0;
> +
> +err:
> +       while (i--)
> +               clk_put(pg->clks[i]);
> +
> +       pg->num_clks = 0;
> +
> +       return err;
> +}

Fetching clocks like above function does, seems to be a quite common case.

As I suggested to add an enable/disable API for a clock list, the
similar can be done for creating the clock list.

Just an idea...

[...]

> +
> +static void tegra_powergate_remove(struct tegra_pmc *pmc)
> +{
> +       struct tegra_powergate *pg, *n;
> +
> +       list_for_each_entry_safe(pg, n, &pmc->powergates_list, node) {

The tegra powergate driver will hold a list of nvidia powergates
domains, and the generic PM domain will hold a list of all generic PM
domains.

Perhaps there's a way to allow the generic PM domain to control this
by itself. If we for example used the struct device corresponding to
the powergate driver, genpd could use it to distinguish between
various instances of genpd structs..!? Maybe it would simplify the way
to deal with removing domains?

> +               of_genpd_del_provider(pg->of_node);
> +
> +               if (pg->parent) {
> +                       if (WARN_ON(pm_genpd_remove_subdomain(pg->parent,
> +                                                             &pg->genpd)))
> +                               return;
> +
> +                       pg->parent = NULL;
> +               }
> +
> +               if (WARN_ON(pm_genpd_remove(&pg->genpd)))
> +                       return;
> +
> +               while (pg->num_clks--)
> +                       clk_put(pg->clks[pg->num_clks]);
> +
> +               while (pg->num_resets--)
> +                       reset_control_put(pg->resets[pg->num_resets]);
> +
> +               list_del(&pg->node);
> +       }
> +}
> +

[...]

Kind regards
Uffe


From vincent.guittot at linaro.org  Thu Feb  4 07:46:17 2016
From: vincent.guittot at linaro.org (Vincent Guittot)
Date: Thu, 4 Feb 2016 16:46:17 +0100
Subject: [PATCH v3 2/6] drivers/cpufreq: implement
 init_cpu_capacity_default()
In-Reply-To: <CAKfTPtDWP-AgqXsSuxCfVj33dh+i7oqDTkL=gUy7n-AB1anoow@mail.gmail.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <1454500799-18451-3-git-send-email-juri.lelli@arm.com>
 <CAKfTPtDGk5BC25WqHdhDYDOBgUsuidAMhrXS=eDi6wJPZjfrwA@mail.gmail.com>
 <20160204093559.GA14099@e105550-lin.cambridge.arm.com>
 <CAKfTPtB4G3bP5N0hU6zWXJTddO34x3RnyGpp-4_otc8O=Wq2hw@mail.gmail.com>
 <20160204121620.GB29586@e106622-lin>
 <CAKfTPtDVasamRtG2kLxP0HsohmVQTPrXRgx36e+jb3gozDoo6g@mail.gmail.com>
 <20160204141345.GD29586@e106622-lin>
 <CAKfTPtDWP-AgqXsSuxCfVj33dh+i7oqDTkL=gUy7n-AB1anoow@mail.gmail.com>
Message-ID: <CAKfTPtD4jTmUZoShGBm3oAFywizjp8jsEukmkeZU+x+zk-KZRA@mail.gmail.com>

On 4 February 2016 at 16:44, Vincent Guittot <vincent.guittot at linaro.org> wrote:
> On 4 February 2016 at 15:13, Juri Lelli <juri.lelli at arm.com> wrote:
>> On 04/02/16 13:35, Vincent Guittot wrote:
>>> On 4 February 2016 at 13:16, Juri Lelli <juri.lelli at arm.com> wrote:
>>> > Hi Vincent,
>>> >
>>> > On 04/02/16 13:03, Vincent Guittot wrote:
>>> >> On 4 February 2016 at 10:36, Morten Rasmussen <morten.rasmussen at arm.com> wrote:
>>> >> > On Wed, Feb 03, 2016 at 10:04:37PM +0100, Vincent Guittot wrote:
>>> >> >> On 3 February 2016 at 12:59, Juri Lelli <juri.lelli at arm.com> wrote:
>>> >>
>>> >> [snip]
>>> >>
>>> >> >> > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
>>> >> >> > index 9e63fb1..c4025fd 100644
>>> >> >> > --- a/drivers/cpufreq/Makefile
>>> >> >> > +++ b/drivers/cpufreq/Makefile
>>> >> >> > @@ -1,5 +1,5 @@
>>> >> >> >  # CPUfreq core
>>> >> >> > -obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o
>>> >> >> > +obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o cpufreq_capacity.o
>>> >> >>
>>> >> >> Do you really want to have the calibration of capacity dependent of
>>> >> >> cpufreq ? It means that we can't use it without a cpufreq driver.
>>> >> >> IMHO, this creates a unnecessary dependency. I understand that you
>>> >> >> must ensure that core runs at max fequency if a driver is present but
>>> >> >> you should be able to calibrate the capacity if cpufreq is not
>>> >> >> available but you have different capacity because micro architecture
>>> >> >
>>> >> > We could remove the dependency on cpufreq, but it would make things more
>>> >> > complicated for systems which do have frequency scaling as we would have
>>> >> > to either:
>>> >> >
>>> >> > 1) Run the calibration again once cpufreq has been initialized.
>>> >>
>>> >> or wait and let time for a driver to initialize and trig the
>>> >> calibration. If calibration has not been done at the end of the boot,
>>> >> you can force a calibration. If the cpufeq driver is a module and is
>>> >> loaded far later for any good or bad reason, we will have to run the
>>> >> calibration once again but at least the capacity will reflect he
>>> >> current capacity of the CPUs.
>>> >> I'm mainly worried that the compilation of the calibration is
>>> >> dependent of CONFIG_CPU_FREQ not that cpufreq can trig the calibration
>>> >> sequence
>>> >>
>>> >
>>> > Yes, I guess we can make this work in some way. Out of curiosity,
>>> > though, are out there heterogenous platforms that don't use cpufreq?
>>>
>>> At least, you can find several heterogeneous platforms without OPP
>>> table for CPUs in the kernel. That's probably a temporary situation
>>> but which can become a permanent one. It means that we can't calibrate
>>> the CPUs for these platforms.
>>>
>>
>> Sorry, can you make some examples so that I'm sure I understand what you
>> are referring to?
>
> As an example, the uniphier arm64 Soc doesn't have a cpufreq driver so far
>
>>
>> Anyway, don't these platform still make use of cpufreq (even if without
>> an OPP table) so that we can still control policy->max and min?
>
> AFAICT, They don't have a dedicated cpufreq driver.
>
> More generally speaking, it can take time before having

email sent before the ne d of the sentence ...

More generally speaking, it can take time before having a cpufreq
driver whereas we want to run and test scheduler behavior of these
heterogenous platform

Thanks,
Vincent
>
>>
>> Thanks,
>>
>> - Juri


From ulf.hansson at linaro.org  Thu Feb  4 07:49:39 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 4 Feb 2016 16:49:39 +0100
Subject: [PATCH] ARM: nomadik: fix up SD/MMC DT settings
In-Reply-To: <1454332737-631-1-git-send-email-linus.walleij@linaro.org>
References: <1454332737-631-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <CAPDyKFo2S1Urn8eqdaztWU_ZSpYwPi7-N1m5PgGZH2aSD3PTPg@mail.gmail.com>

On 1 February 2016 at 14:18, Linus Walleij <linus.walleij at linaro.org> wrote:
> The DTSI file for the Nomadik does not properly specify how the
> PL180 levelshifter is connected: the Nomadik actually needs all
> the five st,sig-dir-* flags set to properly control all lines out.
>
> Further this board supports full power cycling of the card, and
> since this variant has no hardware clock gating, it needs a
> ridiculously low frequency setting to keep up with the ever
> overflowing FIFO.
>
> The pin configuration set-up is a bit of a mystery, because of
> course these pins are a mix of inputs and outputs. However the
> reference implementation sets all pins to "output" with
> unspecified initial value, so let's do that here as well.
>
> Cc: stable at vger.kernel.org
> Cc: Ulf Hansson <ulf.hansson at linaro.org>

Looks good to me!

Acked-by: Ulf Hansson <ulf.hansson at linaro.org>

> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> ARM SoC folks: this fixes the non-working SD/MMC card on the
> Nomadik please apply this directly for fixes if Ulf is OK with
> it.
> ---
>  arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 37 ++++++++++++++++--------------
>  1 file changed, 20 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
> index 50c256f0fd98..b1707f6217bf 100644
> --- a/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
> +++ b/arch/arm/boot/dts/ste-nomadik-stn8815.dtsi
> @@ -128,22 +128,14 @@
>                         };
>                         mmcsd_default_mode: mmcsd_default {
>                                 mmcsd_default_cfg1 {
> -                                       /* MCCLK */
> -                                       pins = "GPIO8_B10";
> -                                       ste,output = <0>;
> -                               };
> -                               mmcsd_default_cfg2 {
> -                                       /* MCCMDDIR, MCDAT0DIR, MCDAT31DIR, MCDATDIR2 */
> -                                       pins = "GPIO10_C11", "GPIO15_A12",
> -                                       "GPIO16_C13", "GPIO23_D15";
> -                                       ste,output = <1>;
> -                               };
> -                               mmcsd_default_cfg3 {
> -                                       /* MCCMD, MCDAT3-0, MCMSFBCLK */
> -                                       pins = "GPIO9_A10", "GPIO11_B11",
> -                                       "GPIO12_A11", "GPIO13_C12",
> -                                       "GPIO14_B12", "GPIO24_C15";
> -                                       ste,input = <1>;
> +                                       /*
> +                                        * MCCLK, MCCMDDIR, MCDAT0DIR, MCDAT31DIR, MCDATDIR2
> +                                        * MCCMD, MCDAT3-0, MCMSFBCLK
> +                                        */
> +                                       pins = "GPIO8_B10", "GPIO9_A10", "GPIO10_C11", "GPIO11_B11",
> +                                              "GPIO12_A11", "GPIO13_C12", "GPIO14_B12", "GPIO15_A12",
> +                                              "GPIO16_C13", "GPIO23_D15", "GPIO24_C15";
> +                                       ste,output = <2>;
>                                 };
>                         };
>                 };
> @@ -803,10 +795,21 @@
>                         clock-names = "mclk", "apb_pclk";
>                         interrupt-parent = <&vica>;
>                         interrupts = <22>;
> -                       max-frequency = <48000000>;
> +                       max-frequency = <400000>;
>                         bus-width = <4>;
>                         cap-mmc-highspeed;
>                         cap-sd-highspeed;
> +                       full-pwr-cycle;
> +                       /*
> +                        * The STw4811 circuit used with the Nomadik strictly
> +                        * requires that all of these signal direction pins be
> +                        * routed and used for its 4-bit levelshifter.
> +                        */
> +                       st,sig-dir-dat0;
> +                       st,sig-dir-dat2;
> +                       st,sig-dir-dat31;
> +                       st,sig-dir-cmd;
> +                       st,sig-pin-fbclk;
>                         pinctrl-names = "default";
>                         pinctrl-0 = <&mmcsd_default_mux>, <&mmcsd_default_mode>;
>                         vmmc-supply = <&vmmc_regulator>;
> --
> 2.4.3
>


From ard.biesheuvel at linaro.org  Thu Feb  4 07:50:23 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu,  4 Feb 2016 16:50:23 +0100
Subject: [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks
Message-ID: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>

I merged two EFI/ARM related series, whose v1's I sent out last week:

Changes since v1:
- added various tags from various people
- new patch #3 to undefine __init

@Matt: are you happy with all of this going through the arm64 tree? I don't
think it clashes with anything else we've got queued up for v4.6 in tip/efi/core

Series 1: arm efi minor fixes
http://thread.gmane.org/gmane.linux.ports.arm.kernel/473027
This fixes two minor issues with the handling of .init data in the stub (#1, #2)

Patch #3 is a new patch that un-#defines __init in efistub.h, to catch its
inadvertent use in the UEFI stub

Patch #4 replaces some instances of early_memremap() with early_memremap_ro()
where the region in question is only accessed in r/o mode.

Series 2: UEFI stub pre-boot compat checks
http://thread.gmane.org/gmane.linux.ports.arm.kernel/473189

As discussed earlier today [1], and last year [2], it makes sense for the
UEFI stub to perform some basic checks on the hardware for missing features
that would prevent the kernel from booting to a state where it can even
complain about this.

So implements this for ARM, to check on LPAE builds whether the CPU supports
it (patch #5), and for arm64, to check whether the build time granule is
implemented by the CPU (patch #6). Patch #7 wires it up into the shared init
code.

[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/472880
[2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/447370

Ard Biesheuvel (7):
  arm64: efistub: drop __init annotation from handle_kernel_image()
  arm64: vmlinux.lds.S: handle .init.rodata.xxx and .init.bss sections
  efi: efistub: prevent __init annotations from being used
  efi: arm-init: use read-only early mappings
  ARM: efistub: check for LPAE support before booting a LPAE kernel
  arm64: efistub: check for h/w support before booting a >4 KB granule
    kernel
  ARM/arm64: efistub: perform hardware compatibility check

 arch/arm64/kernel/vmlinux.lds.S           |  1 +
 drivers/firmware/efi/arm-init.c           | 14 ++++----
 drivers/firmware/efi/libstub/arm-stub.c   |  4 +++
 drivers/firmware/efi/libstub/arm32-stub.c | 17 ++++++++++
 drivers/firmware/efi/libstub/arm64-stub.c | 34 ++++++++++++++++----
 drivers/firmware/efi/libstub/efistub.h    | 12 +++++++
 6 files changed, 68 insertions(+), 14 deletions(-)

-- 
2.5.0



From ard.biesheuvel at linaro.org  Thu Feb  4 07:50:26 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu,  4 Feb 2016 16:50:26 +0100
Subject: [PATCH v2 3/7] efi: efistub: prevent __init annotations from being
 used
In-Reply-To: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454601030-9093-4-git-send-email-ard.biesheuvel@linaro.org>

__init annotations should not be used in the EFI stub, since the code is
either included in the decompressor (x86, ARM) where they have no effect,
or the whole stub is __init annotated at the section level (arm64), by
renaming the sections, in which case the __init annotations will be
redundant, and will result in section names like .init.init.text, and our
linker script does not expect that. So un-#define __init so that its
inadvertent use will force a build error.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/firmware/efi/libstub/efistub.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 6b6548fda089..275f395c886d 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -5,6 +5,16 @@
 /* error code which can't be mistaken for valid address */
 #define EFI_ERROR	(~0UL)
 
+/*
+ * __init annotations should not be used in the EFI stub, since the code is
+ * either included in the decompressor (x86, ARM) where they have no effect,
+ * or the whole stub is __init annotated at the section level (arm64), by
+ * renaming the sections, in which case the __init annotation will be
+ * redundant, and will result in section names like .init.init.text, and our
+ * linker script does not expect that.
+ */
+#undef __init
+
 void efi_char16_printk(efi_system_table_t *, efi_char16_t *);
 
 efi_status_t efi_open_volume(efi_system_table_t *sys_table_arg, void *__image,
-- 
2.5.0



From ard.biesheuvel at linaro.org  Thu Feb  4 07:50:27 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu,  4 Feb 2016 16:50:27 +0100
Subject: [PATCH v2 4/7] efi: arm-init: use read-only early mappings
In-Reply-To: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454601030-9093-5-git-send-email-ard.biesheuvel@linaro.org>

The early mappings of the EFI system table contents and the UEFI memory
map are read-only from the OS point of view. So map them read-only to
protect them from inadvertent modification.

Acked-by: Mark Rutland <mark.rutland at arm.com>
Tested-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/firmware/efi/arm-init.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9e15d571b53c..aa1f743152a2 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -61,8 +61,8 @@ static int __init uefi_init(void)
 	char vendor[100] = "unknown";
 	int i, retval;
 
-	efi.systab = early_memremap(efi_system_table,
-				    sizeof(efi_system_table_t));
+	efi.systab = early_memremap_ro(efi_system_table,
+				       sizeof(efi_system_table_t));
 	if (efi.systab == NULL) {
 		pr_warn("Unable to map EFI system table.\n");
 		return -ENOMEM;
@@ -86,8 +86,8 @@ static int __init uefi_init(void)
 			efi.systab->hdr.revision & 0xffff);
 
 	/* Show what we know for posterity */
-	c16 = early_memremap(efi_to_phys(efi.systab->fw_vendor),
-			     sizeof(vendor) * sizeof(efi_char16_t));
+	c16 = early_memremap_ro(efi_to_phys(efi.systab->fw_vendor),
+				sizeof(vendor) * sizeof(efi_char16_t));
 	if (c16) {
 		for (i = 0; i < (int) sizeof(vendor) - 1 && *c16; ++i)
 			vendor[i] = c16[i];
@@ -100,8 +100,8 @@ static int __init uefi_init(void)
 		efi.systab->hdr.revision & 0xffff, vendor);
 
 	table_size = sizeof(efi_config_table_64_t) * efi.systab->nr_tables;
-	config_tables = early_memremap(efi_to_phys(efi.systab->tables),
-				       table_size);
+	config_tables = early_memremap_ro(efi_to_phys(efi.systab->tables),
+					  table_size);
 	if (config_tables == NULL) {
 		pr_warn("Unable to map EFI config table array.\n");
 		retval = -ENOMEM;
@@ -185,7 +185,7 @@ void __init efi_init(void)
 	efi_system_table = params.system_table;
 
 	memmap.phys_map = params.mmap;
-	memmap.map = early_memremap(params.mmap, params.mmap_size);
+	memmap.map = early_memremap_ro(params.mmap, params.mmap_size);
 	if (memmap.map == NULL) {
 		/*
 		* If we are booting via UEFI, the UEFI memory map is the only
-- 
2.5.0



From ard.biesheuvel at linaro.org  Thu Feb  4 07:50:30 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu,  4 Feb 2016 16:50:30 +0100
Subject: [PATCH v2 7/7] ARM/arm64: efistub: perform hardware compatibility
 check
In-Reply-To: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454601030-9093-8-git-send-email-ard.biesheuvel@linaro.org>

Before proceeding with relocating the kernel and parsing the command line,
insert a call to check_platform_features() to allow an arch specific check
to be performed whether the current kernel can execute on the current
hardware.

Reviewed-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/firmware/efi/libstub/arm-stub.c | 4 ++++
 drivers/firmware/efi/libstub/efistub.h  | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
index 3397902e4040..6086a874fa3c 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -190,6 +190,10 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
 
 	pr_efi(sys_table, "Booting Linux Kernel...\n");
 
+	status = check_platform_features(sys_table);
+	if (status != EFI_SUCCESS)
+		goto fail;
+
 	/*
 	 * Get a handle to the loaded image protocol.  This is used to get
 	 * information about the running image, such as size and the command
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 275f395c886d..a25ac4c7955f 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -53,4 +53,6 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
 		     unsigned long desc_size, efi_memory_desc_t *runtime_map,
 		     int *count);
 
+efi_status_t check_platform_features(efi_system_table_t *sys_table_arg);
+
 #endif
-- 
2.5.0



From ard.biesheuvel at linaro.org  Thu Feb  4 07:50:28 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu,  4 Feb 2016 16:50:28 +0100
Subject: [PATCH v2 5/7] ARM: efistub: check for LPAE support before booting a
 LPAE kernel
In-Reply-To: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454601030-9093-6-git-send-email-ard.biesheuvel@linaro.org>

A kernel built with support for LPAE cannot boot to a state where it
can inform the user about it if it fails due to missing LPAE support
in the hardware.

If we happen to be booting via UEFI, we can fail gracefully so check
for LPAE support in the hardware on CONFIG_ARM_LPAE builds before
entering the kernel proper.

Reviewed-by: Jeremy Linton <jeremy.linton at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/firmware/efi/libstub/arm32-stub.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/firmware/efi/libstub/arm32-stub.c b/drivers/firmware/efi/libstub/arm32-stub.c
index 495ebd657e38..6f42be4d0084 100644
--- a/drivers/firmware/efi/libstub/arm32-stub.c
+++ b/drivers/firmware/efi/libstub/arm32-stub.c
@@ -9,6 +9,23 @@
 #include <linux/efi.h>
 #include <asm/efi.h>
 
+efi_status_t check_platform_features(efi_system_table_t *sys_table_arg)
+{
+	int block;
+
+	/* non-LPAE kernels can run anywhere */
+	if (!IS_ENABLED(CONFIG_ARM_LPAE))
+		return EFI_SUCCESS;
+
+	/* LPAE kernels need compatible hardware */
+	block = cpuid_feature_extract(CPUID_EXT_MMFR0, 0);
+	if (block < 5) {
+		pr_efi_err(sys_table_arg, "This LPAE kernel is not supported by your CPU\n");
+		return EFI_UNSUPPORTED;
+	}
+	return EFI_SUCCESS;
+}
+
 efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
 				 unsigned long *image_addr,
 				 unsigned long *image_size,
-- 
2.5.0



From ard.biesheuvel at linaro.org  Thu Feb  4 07:50:25 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu,  4 Feb 2016 16:50:25 +0100
Subject: [PATCH v2 2/7] arm64: vmlinux.lds.S: handle .init.rodata.xxx and
 .init.bss sections
In-Reply-To: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454601030-9093-3-git-send-email-ard.biesheuvel@linaro.org>

The EFI stub is typically built into the decompressor (x86, ARM) so none
of its symbols are annotated as __init. However, on arm64, the stub is
linked into the kernel proper, and the code is __init annotated at the
section level by prepending all names of SHF_ALLOC sections with '.init'.

This results in section names like .init.rodata.str1.8 (for string literals)
and .init.bss (which is tiny), both of which can be moved into the .init.data
output section.

Acked-by: Will Deacon <will.deacon at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Tested-by: Mark Rutland <mark.rutland at arm.com>
Reviewed-by: Matt Fleming <matt at codeblueprint.co.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/kernel/vmlinux.lds.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index e3928f578891..cbf4db440e9c 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -134,6 +134,7 @@ SECTIONS
 		CON_INITCALL
 		SECURITY_INITCALL
 		INIT_RAM_FS
+		*(.init.rodata.* .init.bss)	/* from the EFI stub */
 	}
 	.exit.data : {
 		ARM_EXIT_KEEP(EXIT_DATA)
-- 
2.5.0



From ard.biesheuvel at linaro.org  Thu Feb  4 07:50:24 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu,  4 Feb 2016 16:50:24 +0100
Subject: [PATCH v2 1/7] arm64: efistub: drop __init annotation from
 handle_kernel_image()
In-Reply-To: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454601030-9093-2-git-send-email-ard.biesheuvel@linaro.org>

After moving arm64-stub.c to libstub/, all of its sections are emitted
as .init.xxx sections automatically, and the __init annotation of
handle_kernel_image() causes it to end up in .init.init.text, which is
not recognized as an __init section by the linker scripts. So drop the
annotation.

Acked-by: Will Deacon <will.deacon at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Tested-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/firmware/efi/libstub/arm64-stub.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c
index 78dfbd34b6bf..9e0342745e4f 100644
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -13,13 +13,13 @@
 #include <asm/efi.h>
 #include <asm/sections.h>
 
-efi_status_t __init handle_kernel_image(efi_system_table_t *sys_table_arg,
-					unsigned long *image_addr,
-					unsigned long *image_size,
-					unsigned long *reserve_addr,
-					unsigned long *reserve_size,
-					unsigned long dram_base,
-					efi_loaded_image_t *image)
+efi_status_t handle_kernel_image(efi_system_table_t *sys_table_arg,
+				 unsigned long *image_addr,
+				 unsigned long *image_size,
+				 unsigned long *reserve_addr,
+				 unsigned long *reserve_size,
+				 unsigned long dram_base,
+				 efi_loaded_image_t *image)
 {
 	efi_status_t status;
 	unsigned long kernel_size, kernel_memsize = 0;
-- 
2.5.0



From bcrl at kvack.org  Thu Feb  4 08:01:01 2016
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Thu, 4 Feb 2016 11:01:01 -0500
Subject: linux-next: build failure after merge of the aio tree
In-Reply-To: <20160204143907.GG10826@n2100.arm.linux.org.uk>
References: <20160127134024.0fababf6@canb.auug.org.au>
 <20160129113056.GP10826@n2100.arm.linux.org.uk>
 <CAMuHMdUy-cqeN8COO4rdpY-mOH+6gth40wB31-edkj8CO5PFCw@mail.gmail.com>
 <20160204131959.6695c7bf@canb.auug.org.au> <20160204134142.GA16315@kvack.org>
 <20160204135056.GE10826@n2100.arm.linux.org.uk>
 <20160204140822.GB16315@kvack.org>
 <20160204141253.GF10826@n2100.arm.linux.org.uk>
 <20160204143204.GC16315@kvack.org>
 <20160204143907.GG10826@n2100.arm.linux.org.uk>
Message-ID: <20160204160101.GD16315@kvack.org>

On Thu, Feb 04, 2016 at 02:39:07PM +0000, Russell King - ARM Linux wrote:
> However, this one should warn:
> 
> int test_wrong(char **v, const char **p)
> { return __get_user(*v, p); }
> 
> Good luck (I think you'll need lots of it to get a working solution)! :)

This works with your test cases on x86-32.  Note that it's only compile + 
link tested at present.

		-ben
-- 
"Thought is the essence of where you are now."

diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 09b1b0a..d8834c2 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -326,7 +326,21 @@ do {									\
 } while (0)
 
 #ifdef CONFIG_X86_32
-#define __get_user_asm_u64(x, ptr, retval, errret)	(x) = __get_user_bad()
+#define __get_user_asm_u64(x, addr, err, errret)			\
+	asm volatile(ASM_STAC "\n"					\
+		     "1:	movl %2,%%eax\n"			\
+		     "		movl %3,%%edx\n"			\
+		     "2: " ASM_CLAC "\n"				\
+		     ".section .fixup,\"ax\"\n"				\
+		     "3:	mov %4,%0\n"				\
+		     "	xorl %%eax,%%eax\n"				\
+		     "	xorl %%edx,%%edx\n"				\
+		     "	jmp 2b\n"					\
+		     ".previous\n"					\
+		     _ASM_EXTABLE(1b, 3b)				\
+		     : "=r" (err), "=A"(x)				\
+		     : "m" (__m(addr)), "m" __m(((u32 *)addr) + 1), "i" (errret), "0" (err))
+
 #define __get_user_asm_ex_u64(x, ptr)			(x) = __get_user_bad()
 #else
 #define __get_user_asm_u64(x, ptr, retval, errret) \


From stern at rowland.harvard.edu  Thu Feb  4 08:04:50 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Thu, 4 Feb 2016 11:04:50 -0500 (EST)
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFr3jqh5bDFOuKLgomhQ2P9+yN5Ps8E0CH8r-oOjvBuswg@mail.gmail.com>
Message-ID: <Pine.LNX.4.44L0.1602041059070.1515-100000@iolanthe.rowland.org>

On Thu, 4 Feb 2016, Ulf Hansson wrote:

> Just wanted to add yet some new findings while I was looking into this
> regression.
> 
> So, the reason why pm_runtime_put_sync() doesn't idle the device in
> these cases, is because autosuspend is respected and for some reason
> the autosuspend timer hasn't expired.

No doubt the autosuspend delay is longer than the time it takes for a 
probe to fail.

> I was wondering *why* the timer isn't considered as expired, because
> the driver don't call pm_runtime_mark_last_busy() in the failing probe
> case...
> 
> Then I realized the following commit was merged a few releases ago,
> which makes the runtime PM core to invoke pm_runtime_mark_last_busy()
> for us.
> 
> commit 56f487c78015936097474fd89b2ccb229d500d0f
> Author: Tony Lindgren <tony at atomide.com>
> Date:   Wed May 13 16:36:32 2015 -0700
> PM / Runtime: Update last_busy in rpm_resume
> 
> So, this commit actually causes the devices to stay active after a
> failed probe attempt.
> 
> I think it's a good idea to revert this change, but what to you think?

I disagree.  The whole idea of autosuspend is to prevent the device's
power state from bouncing up and down too rapidly.  This implies that 
whenever the device gets resumed, we should wait at least the minimum 
autosuspend delay before allowing the next autosuspend.

Perhaps you think that it's silly to behave that way in this case,
because the device wasn't accessed at all during the time it was at
full power.  That's a valid objection, but the proper solution is not
to revert the 56f487c78015 commit.  Rather, change the driver to avoid
doing a pm_runtime_resume_sync until you _know_ that the device will be
accessed soon.

Alan Stern



From arnd at arndb.de  Thu Feb  4 08:07:17 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 04 Feb 2016 17:07:17 +0100
Subject: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host
 Controllers
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1EC9EC12@lhreml503-mbs>
References: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
 <2387127.DMZaDnZvEW@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1EC9EC12@lhreml503-mbs>
Message-ID: <76564455.dlc1WHiVY2@wuerfel>

On Thursday 04 February 2016 15:11:18 Gabriele Paoloni wrote:
> > 
> > ACPI has its own PCI support, and should not need drivers for host
> > bridges. I don't think we can really mix the two things, as ACPI
> > needs to have access to things like PCI config space way before
> > we are probing normal device drivers.
> > 
> > Please put this in drivers/acpi/pci*.c.
> 
> I can put pcie-hisi-acpi.c under drivers/acpi/
> 
> However if you look at the driver it is made up of three parts:
> pcie-hisi.c --> the DT based driver
> pcie-hisi-acpi.c --> the ACPI based hook and ACPI specific init callback
> pcie-hisi-common.c --> common functions shared between DT and ACPI versions 
>                        of the driver
> 
> Now I think that moving pcie-hisi-acpi.c under drivers/acpi/
> would make it hard to read as you need to jump across directories
> and it seems a bit unnatural...
> 
> However it is not a big issue to me...

That's not really what I meant though: the pcie-hisi driver uses the
pcie-designware.c library, most of which makes no sense in an environment
where you have ACPI, e.g. link training, custom MSI support, initial
register setup, platform driver hooks, etc.

You should add a very minimal set of hacks for the parts in this driver
that diverge from a standard SBSA compliant PCIe host that ACPI expects.

	Arnd


From paul.burton at imgtec.com  Thu Feb  4 08:10:07 2016
From: paul.burton at imgtec.com (Paul Burton)
Date: Thu, 4 Feb 2016 16:10:07 +0000
Subject: [PATCH v3 0/6] Xilinx AXI PCIe Host Bridge driver fixes
Message-ID: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>

This series fixes a number of issues found using the Xilinx AXI PCIe
Host Bridge IP on the Imagination Technologies MIPS Boston development
board. It has been split out of the larger Boston board support series
at Michal's request.

Applies atop v4.5-rc2.

Paul Burton (6):
  PCI: xilinx: Keep references to both IRQ domains
  PCI: xilinx: Unify INTx & MSI interrupt FIFO decode
  PCI: xilinx: Always clear interrupt decode register
  PCI: xilinx: Clear interrupt FIFO during probe
  PCI: xilinx: Fix INTX irq dispatch
  PCI: xilinx: Allow build on MIPS platforms

 drivers/pci/host/Kconfig       |   2 +-
 drivers/pci/host/pcie-xilinx.c | 125 +++++++++++++++++++----------------------
 2 files changed, 60 insertions(+), 67 deletions(-)

-- 
2.7.0



From paul.burton at imgtec.com  Thu Feb  4 08:10:08 2016
From: paul.burton at imgtec.com (Paul Burton)
Date: Thu, 4 Feb 2016 16:10:08 +0000
Subject: [PATCH v3 1/6] PCI: xilinx: Keep references to both IRQ domains
In-Reply-To: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>
References: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>
Message-ID: <1454602213-967-2-git-send-email-paul.burton@imgtec.com>

pcie-xilinx creates 2 IRQ domains when built with MSI support: one for
MSI interrupts & one for legacy INTx interrupts. However, it only kept a
reference to the MSI IRQ domain. This means that any INTx interrupts
that may occur would be mapped using the wrong domain, and that only the
MSI IRQ domain would be removed along with the driver. Track both IRQ
domains & clean up both as appropriate.

Signed-off-by: Paul Burton <paul.burton at imgtec.com>
Fixes: 8961def56845 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver")

---

Changes in v3:
- Split out from Boston patchset.

Changes in v2:
- Add Fixes tag.

 drivers/pci/host/pcie-xilinx.c | 58 ++++++++++++++++++++----------------------
 1 file changed, 28 insertions(+), 30 deletions(-)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 4cfa463..1490bd1 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -105,6 +105,7 @@
  * @root_busno: Root Bus number
  * @dev: Device pointer
  * @irq_domain: IRQ domain pointer
+ * @msi_irq_domain: MSI IRQ domain pointer
  * @bus_range: Bus range
  * @resources: Bus Resources
  */
@@ -115,6 +116,7 @@ struct xilinx_pcie_port {
 	u8 root_busno;
 	struct device *dev;
 	struct irq_domain *irq_domain;
+	struct irq_domain *msi_irq_domain;
 	struct resource bus_range;
 	struct list_head resources;
 };
@@ -291,7 +293,7 @@ static int xilinx_pcie_msi_setup_irq(struct msi_controller *chip,
 	if (hwirq < 0)
 		return hwirq;
 
-	irq = irq_create_mapping(port->irq_domain, hwirq);
+	irq = irq_create_mapping(port->msi_irq_domain, hwirq);
 	if (!irq)
 		return -EINVAL;
 
@@ -517,31 +519,21 @@ static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
 
 /**
  * xilinx_pcie_free_irq_domain - Free IRQ domain
- * @port: PCIe port information
+ * @domain: the IRQ domain to free
+ * @nr: the number of IRQs in the domain
  */
-static void xilinx_pcie_free_irq_domain(struct xilinx_pcie_port *port)
+static void xilinx_pcie_free_irq_domain(struct irq_domain *domain, int nr)
 {
 	int i;
-	u32 irq, num_irqs;
-
-	/* Free IRQ Domain */
-	if (IS_ENABLED(CONFIG_PCI_MSI)) {
-
-		free_pages(port->msi_pages, 0);
-
-		num_irqs = XILINX_NUM_MSI_IRQS;
-	} else {
-		/* INTx */
-		num_irqs = 4;
-	}
+	u32 irq;
 
-	for (i = 0; i < num_irqs; i++) {
-		irq = irq_find_mapping(port->irq_domain, i);
+	for (i = 0; i < nr; i++) {
+		irq = irq_find_mapping(domain, i);
 		if (irq > 0)
 			irq_dispose_mapping(irq);
 	}
 
-	irq_domain_remove(port->irq_domain);
+	irq_domain_remove(domain);
 }
 
 /**
@@ -571,20 +563,20 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
 		return PTR_ERR(port->irq_domain);
 	}
 
-	/* Setup MSI */
-	if (IS_ENABLED(CONFIG_PCI_MSI)) {
-		port->irq_domain = irq_domain_add_linear(node,
-							 XILINX_NUM_MSI_IRQS,
-							 &msi_domain_ops,
-							 &xilinx_pcie_msi_chip);
-		if (!port->irq_domain) {
-			dev_err(dev, "Failed to get a MSI IRQ domain\n");
-			return PTR_ERR(port->irq_domain);
-		}
+	if (!IS_ENABLED(CONFIG_PCI_MSI))
+		return 0;
 
-		xilinx_pcie_enable_msi(port);
+	/* Setup MSI */
+	port->msi_irq_domain = irq_domain_add_linear(node,
+						     XILINX_NUM_MSI_IRQS,
+						     &msi_domain_ops,
+						     &xilinx_pcie_msi_chip);
+	if (!port->msi_irq_domain) {
+		dev_err(dev, "Failed to get a MSI IRQ domain\n");
+		return PTR_ERR(port->msi_irq_domain);
 	}
 
+	xilinx_pcie_enable_msi(port);
 	return 0;
 }
 
@@ -869,7 +861,13 @@ static int xilinx_pcie_remove(struct platform_device *pdev)
 {
 	struct xilinx_pcie_port *port = platform_get_drvdata(pdev);
 
-	xilinx_pcie_free_irq_domain(port);
+	xilinx_pcie_free_irq_domain(port->irq_domain, 4);
+
+	if (config_enabled(CONFIG_MSI)) {
+		free_pages(port->msi_pages, 0);
+		xilinx_pcie_free_irq_domain(port->msi_irq_domain,
+					    XILINX_NUM_MSI_IRQS);
+	}
 
 	return 0;
 }
-- 
2.7.0



From paul.burton at imgtec.com  Thu Feb  4 08:10:09 2016
From: paul.burton at imgtec.com (Paul Burton)
Date: Thu, 4 Feb 2016 16:10:09 +0000
Subject: [PATCH v3 2/6] PCI: xilinx: Unify INTx & MSI interrupt FIFO decode
In-Reply-To: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>
References: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>
Message-ID: <1454602213-967-3-git-send-email-paul.burton@imgtec.com>

When decoding either an INTx or MSI interrupt, the driver has no way to
know which it will pull out of the interrupt FIFO. If both were pending
then this would lead to either the interrupt being handled incorrectly
(MSI interrupt treated as INTx) or not at all (INTx interrupt dropped by
MSI path). Unify the reading of the interrupt FIFO & act according to
the type of interrupt actually read.

Signed-off-by: Paul Burton <paul.burton at imgtec.com>
Fixes: 8961def56845 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver")

---

Changes in v3:
- Split out from Boston patchset.

Changes in v2:
- Add Fixes tag.

 drivers/pci/host/pcie-xilinx.c | 47 +++++++++++++-----------------------------
 1 file changed, 14 insertions(+), 33 deletions(-)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 1490bd1..afdfb09 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -397,7 +397,7 @@ static const struct irq_domain_ops intx_domain_ops = {
 static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
 {
 	struct xilinx_pcie_port *port = (struct xilinx_pcie_port *)data;
-	u32 val, mask, status, msi_data;
+	u32 val, mask, status;
 
 	/* Read interrupt decode and mask registers */
 	val = pcie_read(port, XILINX_PCIE_REG_IDR);
@@ -437,8 +437,8 @@ static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
 		xilinx_pcie_clear_err_interrupts(port);
 	}
 
-	if (status & XILINX_PCIE_INTR_INTX) {
-		/* INTx interrupt received */
+	if (status & (XILINX_PCIE_INTR_INTX | XILINX_PCIE_INTR_MSI)) {
+		/* Interrupt received */
 		val = pcie_read(port, XILINX_PCIE_REG_RPIFR1);
 
 		/* Check whether interrupt valid */
@@ -447,41 +447,22 @@ static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
 			return IRQ_HANDLED;
 		}
 
-		if (!(val & XILINX_PCIE_RPIFR1_MSI_INTR)) {
-			/* Clear interrupt FIFO register 1 */
-			pcie_write(port, XILINX_PCIE_RPIFR1_ALL_MASK,
-				   XILINX_PCIE_REG_RPIFR1);
-
-			/* Handle INTx Interrupt */
+		if (val & XILINX_PCIE_RPIFR1_MSI_INTR) {
+			irq = pcie_read(port, XILINX_PCIE_REG_RPIFR2) &
+				XILINX_PCIE_RPIFR2_MSG_DATA;
+		} else {
 			val = ((val & XILINX_PCIE_RPIFR1_INTR_MASK) >>
 				XILINX_PCIE_RPIFR1_INTR_SHIFT) + 1;
-			generic_handle_irq(irq_find_mapping(port->irq_domain,
-							    val));
+			irq = irq_find_mapping(port->irq_domain, val);
 		}
-	}
 
-	if (status & XILINX_PCIE_INTR_MSI) {
-		/* MSI Interrupt */
-		val = pcie_read(port, XILINX_PCIE_REG_RPIFR1);
+		/* Clear interrupt FIFO register 1 */
+		pcie_write(port, XILINX_PCIE_RPIFR1_ALL_MASK,
+			   XILINX_PCIE_REG_RPIFR1);
 
-		if (!(val & XILINX_PCIE_RPIFR1_INTR_VALID)) {
-			dev_warn(port->dev, "RP Intr FIFO1 read error\n");
-			return IRQ_HANDLED;
-		}
-
-		if (val & XILINX_PCIE_RPIFR1_MSI_INTR) {
-			msi_data = pcie_read(port, XILINX_PCIE_REG_RPIFR2) &
-				   XILINX_PCIE_RPIFR2_MSG_DATA;
-
-			/* Clear interrupt FIFO register 1 */
-			pcie_write(port, XILINX_PCIE_RPIFR1_ALL_MASK,
-				   XILINX_PCIE_REG_RPIFR1);
-
-			if (IS_ENABLED(CONFIG_PCI_MSI)) {
-				/* Handle MSI Interrupt */
-				generic_handle_irq(msi_data);
-			}
-		}
+		if (IS_ENABLED(CONFIG_PCI_MSI) ||
+			!(val & XILINX_PCIE_RPIFR1_MSI_INTR))
+			generic_handle_irq(irq);
 	}
 
 	if (status & XILINX_PCIE_INTR_SLV_UNSUPP)
-- 
2.7.0



From paul.burton at imgtec.com  Thu Feb  4 08:10:10 2016
From: paul.burton at imgtec.com (Paul Burton)
Date: Thu, 4 Feb 2016 16:10:10 +0000
Subject: [PATCH v3 3/6] PCI: xilinx: Always clear interrupt decode register
In-Reply-To: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>
References: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>
Message-ID: <1454602213-967-4-git-send-email-paul.burton@imgtec.com>

If an MSI or INTx interrupt is incorrectly triggered with an empty FIFO
then xilinx_pcie_intr_handler will print a warning & skip further
processing. However it did not clear the interrupt in the decode
register, so the same INTX or MSI interrupt would trigger again
immediately even though the FIFO is still empty. Clear the interrupt in
the decode register to avoid that situation.

Signed-off-by: Paul Burton <paul.burton at imgtec.com>
Fixes: 8961def56845 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver")

---

Changes in v3:
- Split out from Boston patchset.

Changes in v2:
- Add Fixes tag.

 drivers/pci/host/pcie-xilinx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index afdfb09..1eb74a2 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -444,7 +444,7 @@ static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
 		/* Check whether interrupt valid */
 		if (!(val & XILINX_PCIE_RPIFR1_INTR_VALID)) {
 			dev_warn(port->dev, "RP Intr FIFO1 read error\n");
-			return IRQ_HANDLED;
+			goto out;
 		}
 
 		if (val & XILINX_PCIE_RPIFR1_MSI_INTR) {
@@ -492,6 +492,7 @@ static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
 	if (status & XILINX_PCIE_INTR_MST_ERRP)
 		dev_warn(port->dev, "Master error poison\n");
 
+out:
 	/* Clear the Interrupt Decode register */
 	pcie_write(port, status, XILINX_PCIE_REG_IDR);
 
-- 
2.7.0



From paul.burton at imgtec.com  Thu Feb  4 08:10:11 2016
From: paul.burton at imgtec.com (Paul Burton)
Date: Thu, 4 Feb 2016 16:10:11 +0000
Subject: [PATCH v3 4/6] PCI: xilinx: Clear interrupt FIFO during probe
In-Reply-To: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>
References: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>
Message-ID: <1454602213-967-5-git-send-email-paul.burton@imgtec.com>

xilinx_pcie_init_port clears the pending interrupts in the interrupt
decode register, but does not clear the interrupt FIFO. This would lead
to spurious interrupts if any were present in the FIFO at probe time.
Clear the interrupt FIFO prior to the interrupt decode register in order
to start with a clean slate as expected.

Signed-off-by: Paul Burton <paul.burton at imgtec.com>
Fixes: 8961def56845 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver")

---

Changes in v3:
- Split out from Boston patchset.

Changes in v2:
- Add Fixes tag.

 drivers/pci/host/pcie-xilinx.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 1eb74a2..6c5a503 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -568,6 +568,8 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
  */
 static void xilinx_pcie_init_port(struct xilinx_pcie_port *port)
 {
+	u32 val;
+
 	if (xilinx_pcie_link_is_up(port))
 		dev_info(port->dev, "PCIe Link is UP\n");
 	else
@@ -577,6 +579,17 @@ static void xilinx_pcie_init_port(struct xilinx_pcie_port *port)
 	pcie_write(port, ~XILINX_PCIE_IDR_ALL_MASK,
 		   XILINX_PCIE_REG_IMR);
 
+	/* Clear interrupt FIFO */
+	while (1) {
+		val = pcie_read(port, XILINX_PCIE_REG_RPIFR1);
+
+		if (!(val & XILINX_PCIE_RPIFR1_INTR_VALID))
+			break;
+
+		pcie_write(port, XILINX_PCIE_RPIFR1_ALL_MASK,
+			   XILINX_PCIE_REG_RPIFR1);
+	}
+
 	/* Clear pending interrupts */
 	pcie_write(port, pcie_read(port, XILINX_PCIE_REG_IDR) &
 			 XILINX_PCIE_IMR_ALL_MASK,
-- 
2.7.0



From paul.burton at imgtec.com  Thu Feb  4 08:10:12 2016
From: paul.burton at imgtec.com (Paul Burton)
Date: Thu, 4 Feb 2016 16:10:12 +0000
Subject: [PATCH v3 5/6] PCI: xilinx: Fix INTX irq dispatch
In-Reply-To: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>
References: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>
Message-ID: <1454602213-967-6-git-send-email-paul.burton@imgtec.com>

The IRQ domain for INTX interrupts has 4 entries, numbered 0 to 3. This
matches what the hardware reports from the interrupt FIFO exactly, but
xilinx_pcie_intr_handler was adding 1 to that value to convert to the
range 1 to 4. Stop adding 1, such that all of INTA through to INTD fall
within the range of the IRQ domain.

Signed-off-by: Paul Burton <paul.burton at imgtec.com>
Fixes: 8961def56845 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver")

---

Changes in v3:
- Split out from Boston patchset.

Changes in v2:
- Add Fixes tag.

 drivers/pci/host/pcie-xilinx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 6c5a503..8013e83 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -451,8 +451,8 @@ static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
 			irq = pcie_read(port, XILINX_PCIE_REG_RPIFR2) &
 				XILINX_PCIE_RPIFR2_MSG_DATA;
 		} else {
-			val = ((val & XILINX_PCIE_RPIFR1_INTR_MASK) >>
-				XILINX_PCIE_RPIFR1_INTR_SHIFT) + 1;
+			val = (val & XILINX_PCIE_RPIFR1_INTR_MASK) >>
+				XILINX_PCIE_RPIFR1_INTR_SHIFT;
 			irq = irq_find_mapping(port->irq_domain, val);
 		}
 
-- 
2.7.0



From mark.rutland at arm.com  Thu Feb  4 08:13:01 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 4 Feb 2016 16:13:01 +0000
Subject: [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks
In-Reply-To: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160204161300.GC17587@leverpostej>

On Thu, Feb 04, 2016 at 04:50:23PM +0100, Ard Biesheuvel wrote:
> Ard Biesheuvel (7):
>   arm64: efistub: drop __init annotation from handle_kernel_image()
>   arm64: vmlinux.lds.S: handle .init.rodata.xxx and .init.bss sections
>   efi: efistub: prevent __init annotations from being used
>   efi: arm-init: use read-only early mappings
>   ARM: efistub: check for LPAE support before booting a LPAE kernel
>   arm64: efistub: check for h/w support before booting a >4 KB granule
>     kernel
>   ARM/arm64: efistub: perform hardware compatibility check

This all looks good to be, so FWIW, for the series:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Mark.


From linux at arm.linux.org.uk  Thu Feb  4 08:17:42 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 4 Feb 2016 16:17:42 +0000
Subject: linux-next: build failure after merge of the aio tree
In-Reply-To: <20160204160101.GD16315@kvack.org>
References: <20160129113056.GP10826@n2100.arm.linux.org.uk>
 <CAMuHMdUy-cqeN8COO4rdpY-mOH+6gth40wB31-edkj8CO5PFCw@mail.gmail.com>
 <20160204131959.6695c7bf@canb.auug.org.au>
 <20160204134142.GA16315@kvack.org>
 <20160204135056.GE10826@n2100.arm.linux.org.uk>
 <20160204140822.GB16315@kvack.org>
 <20160204141253.GF10826@n2100.arm.linux.org.uk>
 <20160204143204.GC16315@kvack.org>
 <20160204143907.GG10826@n2100.arm.linux.org.uk>
 <20160204160101.GD16315@kvack.org>
Message-ID: <20160204161741.GH10826@n2100.arm.linux.org.uk>

On Thu, Feb 04, 2016 at 11:01:01AM -0500, Benjamin LaHaise wrote:
> On Thu, Feb 04, 2016 at 02:39:07PM +0000, Russell King - ARM Linux wrote:
> > However, this one should warn:
> > 
> > int test_wrong(char **v, const char **p)
> > { return __get_user(*v, p); }
> > 
> > Good luck (I think you'll need lots of it to get a working solution)! :)
> 
> This works with your test cases on x86-32.  Note that it's only compile + 
> link tested at present.

That's the easy bit!

The problem you're going to run into is here:

#define __get_user_nocheck(x, ptr, size)                                \
({                                                                      \
        int __gu_err;                                                   \
        unsigned long __gu_val;                                         \
        __uaccess_begin();                                              \
        __get_user_size(__gu_val, (ptr), (size), __gu_err, -EFAULT);    \
        __uaccess_end();                                                \
        (x) = (__force __typeof__(*(ptr)))__gu_val;                     \

__gu_val will be 32-bit, even when you're wanting a 64-bit quantity.
That's where the fun and games start...

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From mathieu.poirier at linaro.org  Thu Feb  4 08:25:51 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 4 Feb 2016 09:25:51 -0700
Subject: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <1454519923-25230-5-git-send-email-fu.wei@linaro.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-5-git-send-email-fu.wei@linaro.org>
Message-ID: <CANLsYkzQpEHa4hnO4D1E0+P-i961+ak=Hr_RPPrOxd-+VMhLSQ@mail.gmail.com>

On 3 February 2016 at 10:18,  <fu.wei at linaro.org> wrote:
> From: Fu Wei <fu.wei at linaro.org>
>
> According to Server Base System Architecture (SBSA) specification,
> the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0)
> is for alerting the system by interrupt, the second one (WS1) is a real
> hardware reset.
>
> This patch initially implements a simple single stage watchdog driver:
> when the timeout is reached, your system will be reset by the second
> signal (WS1).
> The first signal (WS0) is ignored in this driver.
>
> This driver bases on linux kernel watchdog framework, so it can get
> timeout from module parameter and FDT at the driver init stage.
>
> Signed-off-by: Fu Wei <fu.wei at linaro.org>
> Reviewed-by: Graeme Gregory <graeme.gregory at linaro.org>
> Tested-by: Pratyush Anand <panand at redhat.com>
> ---
>  drivers/watchdog/Kconfig     |  17 +++
>  drivers/watchdog/Makefile    |   1 +
>  drivers/watchdog/sbsa_gwdt.c | 322 +++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 340 insertions(+)
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 4f0e7be..4ab1b05 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -201,6 +201,23 @@ config ARM_SP805_WATCHDOG
>           ARM Primecell SP805 Watchdog timer. This will reboot your system when
>           the timeout is reached.
>
> +config ARM_SBSA_WATCHDOG
> +       tristate "ARM SBSA Generic Watchdog"
> +       depends on ARM64
> +       depends on ARM_ARCH_TIMER
> +       select WATCHDOG_CORE
> +       help
> +         ARM SBSA Generic Watchdog has two stage timeouts:
> +         the first signal (WS0) is for alerting the system by interrupt,
> +         the second one (WS1) is a real hardware reset.
> +         More details: ARM DEN0029B - Server Base System Architecture (SBSA)
> +
> +         This is a simple single stage driver: when the timeout is reached,
> +         your system will be reset by WS1. The first signal (WS0) is ignored.
> +
> +         To compile this driver as module, choose M here: The module
> +         will be called sbsa_gwdt.
> +
>  config ASM9260_WATCHDOG
>         tristate "Alphascale ASM9260 watchdog"
>         depends on MACH_ASM9260
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index f566753..f9826d4 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
>
>  # ARM Architecture
>  obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
> +obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
>  obj-$(CONFIG_ASM9260_WATCHDOG) += asm9260_wdt.o
>  obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
>  obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
> new file mode 100644
> index 0000000..5a2dba3
> --- /dev/null
> +++ b/drivers/watchdog/sbsa_gwdt.c
> @@ -0,0 +1,322 @@
> +/*
> + * SBSA(Server Base System Architecture) Generic Watchdog driver
> + *
> + * Copyright (c) 2015, Linaro Ltd.
> + * Author: Fu Wei <fu.wei at linaro.org>
> + *         Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
> + *         Al Stone <al.stone at linaro.org>
> + *         Timur Tabi <timur at codeaurora.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License 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.
> + *
> + * This SBSA Generic watchdog driver is a single stage timeout version.
> + * Since this watchdog timer has two stages, and each stage is determined
> + * by WOR. So the timeout is (WOR * 2).
> + * When first timeout is reached, WS0 is triggered, the interrupt
> + * triggered by WS0 will be ignored, then the second watch period starts;
> + * when second timeout is reached, then WS1 is triggered, system reset.
> + *
> + * More details about the hardware specification of this device:
> + * ARM DEN0029B - Server Base System Architecture (SBSA)
> + *
> + * SBSA GWDT: |--------WOR-------WS0--------WOR-------WS1
> + *            |----------------timeout----------------reset
> + *
> + */
> +
> +#include <linux/io.h>
> +#include <linux/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/uaccess.h>
> +#include <linux/watchdog.h>
> +#include <asm/arch_timer.h>
> +
> +/* SBSA Generic Watchdog register definitions */
> +/* refresh frame */
> +#define SBSA_GWDT_WRR                          0x000
> +
> +/* control frame */
> +#define SBSA_GWDT_WCS                          0x000
> +#define SBSA_GWDT_WOR                          0x008
> +#define SBSA_GWDT_WCV                          0x010
> +
> +/* refresh/control frame */
> +#define SBSA_GWDT_W_IIDR                       0xfcc
> +#define SBSA_GWDT_IDR                          0xfd0
> +
> +/* Watchdog Control and Status Register */
> +#define SBSA_GWDT_WCS_EN                       BIT(0)
> +#define SBSA_GWDT_WCS_WS0                      BIT(1)
> +#define SBSA_GWDT_WCS_WS1                      BIT(2)
> +
> +/**
> + * struct sbsa_gwdt - Internal representation of the SBSA GWDT
> + * @wdd:               kernel watchdog_device structure
> + * @clk:               store the System Counter clock frequency, in Hz.
> + * @refresh_base:      Virtual address of the watchdog refresh frame
> + * @control_base:      Virtual address of the watchdog control frame
> + */
> +struct sbsa_gwdt {
> +       struct watchdog_device  wdd;
> +       u32                     clk;
> +       void __iomem            *refresh_base;
> +       void __iomem            *control_base;
> +};
> +
> +#define to_sbsa_gwdt(e) container_of(e, struct sbsa_gwdt, wdd)
> +
> +#define DEFAULT_TIMEOUT                20 /* seconds, the 1st + 2nd watch periods*/
> +
> +static unsigned int timeout;
> +module_param(timeout, uint, 0);
> +MODULE_PARM_DESC(timeout,
> +                "Watchdog timeout in seconds. (>=0, default="
> +                __MODULE_STRING(DEFAULT_TIMEOUT) ")");
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +module_param(nowayout, bool, S_IRUGO);
> +MODULE_PARM_DESC(nowayout,
> +                "Watchdog cannot be stopped once started (default="
> +                __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> +
> +/*
> + * watchdog operation functions
> + */
> +static int sbsa_gwdt_set_timeout(struct watchdog_device *wdd,
> +                                unsigned int timeout)
> +{
> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +
> +       wdd->timeout = timeout;
> +       writel(timeout / 2 * gwdt->clk, gwdt->control_base + SBSA_GWDT_WOR);
> +
> +       return 0;
> +}
> +
> +static unsigned int sbsa_gwdt_get_timeleft(struct watchdog_device *wdd)
> +{
> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +       u64 timeleft = readq(gwdt->control_base + SBSA_GWDT_WCV) -
> +                      arch_counter_get_cntvct();
> +
> +       do_div(timeleft, gwdt->clk);
> +
> +       if (readl(gwdt->control_base + SBSA_GWDT_WCS) & SBSA_GWDT_WCS_WS0)
> +               return timeleft;
> +
> +       return timeleft + wdd->timeout / 2;

It would be great to have a comment whenever hard coded values are
used.  That way people understand why things were set this way.  The
same applies for the rest of this patch.

> +}
> +
> +static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
> +{
> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +
> +       /*
> +       * Writing WRR for an explicit watchdog refresh.
> +       * You can write anyting(like 0xc0ffee).
> +       */
> +       writel(0xc0ffee, gwdt->refresh_base + SBSA_GWDT_WRR);
> +
> +       return 0;
> +}
> +
> +static unsigned int sbsa_gwdt_status(struct watchdog_device *wdd)
> +{
> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +       u32 status = readl(gwdt->control_base + SBSA_GWDT_WCS);
> +
> +       /* is the watchdog timer running? */
> +       return (status & SBSA_GWDT_WCS_EN) << WDOG_ACTIVE;
> +}
> +
> +static int sbsa_gwdt_start(struct watchdog_device *wdd)
> +{
> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +
> +       /* writing WCS will cause an explicit watchdog refresh */
> +       writel(SBSA_GWDT_WCS_EN, gwdt->control_base + SBSA_GWDT_WCS);
> +
> +       return sbsa_gwdt_keepalive(wdd);
> +}
> +
> +static int sbsa_gwdt_stop(struct watchdog_device *wdd)
> +{
> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +
> +       writel(0, gwdt->control_base + SBSA_GWDT_WCS);
> +
> +       return 0;
> +}
> +
> +static struct watchdog_info sbsa_gwdt_info = {
> +       .identity       = "SBSA Generic Watchdog",
> +       .options        = WDIOF_SETTIMEOUT |
> +                         WDIOF_KEEPALIVEPING |
> +                         WDIOF_MAGICCLOSE |
> +                         WDIOF_CARDRESET,
> +};
> +
> +static struct watchdog_ops sbsa_gwdt_ops = {
> +       .owner          = THIS_MODULE,
> +       .start          = sbsa_gwdt_start,
> +       .stop           = sbsa_gwdt_stop,
> +       .status         = sbsa_gwdt_status,
> +       .ping           = sbsa_gwdt_keepalive,
> +       .set_timeout    = sbsa_gwdt_set_timeout,
> +       .get_timeleft   = sbsa_gwdt_get_timeleft,
> +};
> +
> +static int sbsa_gwdt_probe(struct platform_device *pdev)
> +{
> +       void __iomem *rf_base, *cf_base;
> +       struct device *dev = &pdev->dev;
> +       struct watchdog_device *wdd;
> +       struct sbsa_gwdt *gwdt;
> +       struct resource *res;
> +       u32 status;
> +       int ret;
> +
> +       gwdt = devm_kzalloc(dev, sizeof(*gwdt), GFP_KERNEL);
> +       if (!gwdt)
> +               return -ENOMEM;
> +       platform_set_drvdata(pdev, gwdt);
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       cf_base = devm_ioremap_resource(dev, res);
> +       if (IS_ERR(cf_base))
> +               return PTR_ERR(cf_base);
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +       rf_base = devm_ioremap_resource(dev, res);
> +       if (IS_ERR(rf_base))
> +               return PTR_ERR(rf_base);
> +
> +       /*
> +        * Get the frequency of system counter from the cp15 interface of ARM
> +        * Generic timer. We don't need to check it, because if it returns "0",
> +        * system would panic in very early stage.
> +        */
> +       gwdt->clk = arch_timer_get_cntfrq();
> +       gwdt->refresh_base = rf_base;
> +       gwdt->control_base = cf_base;
> +
> +       wdd = &gwdt->wdd;
> +       wdd->parent = dev;
> +       wdd->info = &sbsa_gwdt_info;
> +       wdd->ops = &sbsa_gwdt_ops;
> +       watchdog_set_drvdata(wdd, gwdt);
> +       watchdog_set_nowayout(wdd, nowayout);
> +
> +       wdd->min_timeout = 2;
> +       wdd->max_timeout = U32_MAX / gwdt->clk * 2;
> +       wdd->timeout = DEFAULT_TIMEOUT;
> +       watchdog_init_timeout(wdd, timeout, dev);
> +
> +       status = readl(gwdt->control_base + SBSA_GWDT_WCS);
> +       if (status & SBSA_GWDT_WCS_WS1) {
> +               dev_warn(dev, "System reset by WDT.\n");
> +               wdd->bootstatus |= WDIOF_CARDRESET;
> +       }
> +
> +       ret = watchdog_register_device(wdd);
> +       if (ret)
> +               return ret;
> +
> +       /*
> +        * Update timeout to WOR.
> +        * Because of the explicit watchdog refresh mechanism,
> +        * it's also a ping, if watchdog is enabled.
> +        */
> +       sbsa_gwdt_set_timeout(wdd, wdd->timeout);
> +
> +       dev_info(dev, "Initialized with %ds timeout @ %u Hz%s\n", wdd->timeout,
> +                gwdt->clk, status & SBSA_GWDT_WCS_EN ? " [enabled]" : "");
> +
> +       return 0;
> +}
> +
> +static void sbsa_gwdt_shutdown(struct platform_device *pdev)
> +{
> +       struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
> +
> +       sbsa_gwdt_stop(&gwdt->wdd);
> +}
> +
> +static int sbsa_gwdt_remove(struct platform_device *pdev)
> +{
> +       struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
> +
> +       watchdog_unregister_device(&gwdt->wdd);
> +
> +       return 0;
> +}
> +
> +/* Disable watchdog if it is active during suspend */
> +static int __maybe_unused sbsa_gwdt_suspend(struct device *dev)
> +{
> +       struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
> +
> +       if (watchdog_active(&gwdt->wdd))
> +               sbsa_gwdt_stop(&gwdt->wdd);
> +
> +       return 0;
> +}
> +
> +/* Enable watchdog and configure it if necessary */
> +static int __maybe_unused sbsa_gwdt_resume(struct device *dev)
> +{
> +       struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
> +
> +       if (watchdog_active(&gwdt->wdd))
> +               sbsa_gwdt_start(&gwdt->wdd);
> +
> +       return 0;
> +}
> +
> +static const struct dev_pm_ops sbsa_gwdt_pm_ops = {
> +       SET_SYSTEM_SLEEP_PM_OPS(sbsa_gwdt_suspend, sbsa_gwdt_resume)
> +};
> +
> +static const struct of_device_id sbsa_gwdt_of_match[] = {
> +       { .compatible = "arm,sbsa-gwdt", },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(of, sbsa_gwdt_of_match);
> +
> +static const struct platform_device_id sbsa_gwdt_pdev_match[] = {
> +       { .name = "sbsa-gwdt", },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(platform, sbsa_gwdt_pdev_match);
> +
> +static struct platform_driver sbsa_gwdt_driver = {
> +       .driver = {
> +               .name = "sbsa-gwdt",
> +               .pm = &sbsa_gwdt_pm_ops,
> +               .of_match_table = sbsa_gwdt_of_match,
> +       },
> +       .probe = sbsa_gwdt_probe,
> +       .remove = sbsa_gwdt_remove,
> +       .shutdown = sbsa_gwdt_shutdown,
> +       .id_table = sbsa_gwdt_pdev_match,
> +};
> +
> +module_platform_driver(sbsa_gwdt_driver);
> +
> +MODULE_DESCRIPTION("SBSA Generic Watchdog Driver");
> +MODULE_AUTHOR("Fu Wei <fu.wei at linaro.org>");
> +MODULE_AUTHOR("Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>");
> +MODULE_AUTHOR("Al Stone <al.stone at linaro.org>");
> +MODULE_AUTHOR("Timur Tabi <timur at codeaurora.org>");
> +MODULE_LICENSE("GPL v2");
> --
> 2.5.0
>


From bcrl at kvack.org  Thu Feb  4 08:27:52 2016
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Thu, 4 Feb 2016 11:27:52 -0500
Subject: linux-next: build failure after merge of the aio tree
In-Reply-To: <20160204161741.GH10826@n2100.arm.linux.org.uk>
References: <CAMuHMdUy-cqeN8COO4rdpY-mOH+6gth40wB31-edkj8CO5PFCw@mail.gmail.com>
 <20160204131959.6695c7bf@canb.auug.org.au> <20160204134142.GA16315@kvack.org>
 <20160204135056.GE10826@n2100.arm.linux.org.uk>
 <20160204140822.GB16315@kvack.org>
 <20160204141253.GF10826@n2100.arm.linux.org.uk>
 <20160204143204.GC16315@kvack.org>
 <20160204143907.GG10826@n2100.arm.linux.org.uk>
 <20160204160101.GD16315@kvack.org>
 <20160204161741.GH10826@n2100.arm.linux.org.uk>
Message-ID: <20160204162752.GE16315@kvack.org>

On Thu, Feb 04, 2016 at 04:17:42PM +0000, Russell King - ARM Linux wrote:
> On Thu, Feb 04, 2016 at 11:01:01AM -0500, Benjamin LaHaise wrote:
> > On Thu, Feb 04, 2016 at 02:39:07PM +0000, Russell King - ARM Linux wrote:
> > > However, this one should warn:
> > > 
> > > int test_wrong(char **v, const char **p)
> > > { return __get_user(*v, p); }
> > > 
> > > Good luck (I think you'll need lots of it to get a working solution)! :)
> > 
> > This works with your test cases on x86-32.  Note that it's only compile + 
> > link tested at present.
> 
> That's the easy bit!
> 
> The problem you're going to run into is here:
> 
> #define __get_user_nocheck(x, ptr, size)                                \
> ({                                                                      \
>         int __gu_err;                                                   \
>         unsigned long __gu_val;                                         \
>         __uaccess_begin();                                              \
>         __get_user_size(__gu_val, (ptr), (size), __gu_err, -EFAULT);    \
>         __uaccess_end();                                                \
>         (x) = (__force __typeof__(*(ptr)))__gu_val;                     \
> 
> __gu_val will be 32-bit, even when you're wanting a 64-bit quantity.
> That's where the fun and games start...

Ugh.  You're making me install a 32 bit distro.....!

		-ben

> -- 
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
"Thought is the essence of where you are now."


From will.deacon at arm.com  Thu Feb  4 08:31:02 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 4 Feb 2016 16:31:02 +0000
Subject: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <1454519923-25230-5-git-send-email-fu.wei@linaro.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-5-git-send-email-fu.wei@linaro.org>
Message-ID: <20160204163101.GH17257@arm.com>

On Thu, Feb 04, 2016 at 01:18:42AM +0800, fu.wei at linaro.org wrote:
> +static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
> +{
> +	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +
> +	/*
> +	* Writing WRR for an explicit watchdog refresh.
> +	* You can write anyting(like 0xc0ffee).
> +	*/
> +	writel(0xc0ffee, gwdt->refresh_base + SBSA_GWDT_WRR);
> +
> +	return 0;
> +}

You might get in trouble for that. 0xd09f00d is probably less poisonous.

http://www.petpoisonhelpline.com/poison/caffeine/

Will


From mathieu.poirier at linaro.org  Thu Feb  4 08:32:36 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 4 Feb 2016 09:32:36 -0700
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
Message-ID: <CANLsYkyLBfSKFM6CCyPP+Eaua2B+n80wL2hnQVSvfUNMPd3OdQ@mail.gmail.com>

On 3 February 2016 at 10:18,  <fu.wei at linaro.org> wrote:
> From: Fu Wei <fu.wei at linaro.org>
>
> This patch registers the WS0 interrupt routine to trigger panic,
> when the watchdog reachs the first stage (the half timeout).
> This function can help administrator to backup the system context
> info by panic console output or kdump (if supported), once system
> goes wrong (doesn't feed the watchdog in the half timeout).
>
> User also can skip panic by setting panic_enabled (module parameter) as 0
>
> Signed-off-by: Fu Wei <fu.wei at linaro.org>
> ---
>  Documentation/watchdog/watchdog-parameters.txt |  1 +
>  drivers/watchdog/Kconfig                       | 10 +++++
>  drivers/watchdog/sbsa_gwdt.c                   | 54 +++++++++++++++++++++++---
>  3 files changed, 60 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
> index 300eb4d..31641e2 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -286,6 +286,7 @@ nowayout: Watchdog cannot be stopped once started
>  -------------------------------------------------
>  sbsa_gwdt:
>  timeout: Watchdog timeout in seconds. (default 20s)
> +panic_enabled: Enable panic at half timeout. (default=true)
>  nowayout: Watchdog cannot be stopped once started
>         (default=kernel config parameter)
>  -------------------------------------------------
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 4ab1b05..42adfdf 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -218,6 +218,16 @@ config ARM_SBSA_WATCHDOG
>           To compile this driver as module, choose M here: The module
>           will be called sbsa_gwdt.
>
> +config ARM_SBSA_WATCHDOG_PANIC
> +       bool "ARM SBSA Generic Watchdog triggers panic at the half timeout"
> +       depends on ARM_SBSA_WATCHDOG
> +       help
> +         ARM SBSA Generic Watchdog will trigger panic in the first signal
> +         (WS0) interrupt routine when the half timeout is reached.
> +         This function can help administrator to backup the system context
> +         info by panic console output or kdump (if supported).
> +         But user can skip panic by setting moduleparam panic_enabled as 0.
> +
>  config ASM9260_WATCHDOG
>         tristate "Alphascale ASM9260 watchdog"
>         depends on MACH_ASM9260
> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
> index 5a2dba3..d18cf37 100644
> --- a/drivers/watchdog/sbsa_gwdt.c
> +++ b/drivers/watchdog/sbsa_gwdt.c
> @@ -16,18 +16,22 @@
>   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>   * GNU General Public License for more details.
>   *
> - * This SBSA Generic watchdog driver is a single stage timeout version.
> + * This SBSA Generic watchdog driver is a two stages version.
>   * Since this watchdog timer has two stages, and each stage is determined
>   * by WOR. So the timeout is (WOR * 2).
> - * When first timeout is reached, WS0 is triggered, the interrupt
> - * triggered by WS0 will be ignored, then the second watch period starts;
> - * when second timeout is reached, then WS1 is triggered, system reset.
> + * When the first stage(the half timeout) is reached, WS0 interrupt is
> + * triggered, at this moment the second watch period starts;
> + * In the WS0 interrupt routine, panic will be triggered for saving the
> + * system context.
> + * If the system is getting into trouble and cannot be reset by panic or
> + * restart properly by the kdump kernel(if supported), then the second
> + * stage (the timeout) will be reached, system will be reset by WS1.
>   *
>   * More details about the hardware specification of this device:
>   * ARM DEN0029B - Server Base System Architecture (SBSA)
>   *
>   * SBSA GWDT: |--------WOR-------WS0--------WOR-------WS1
> - *            |----------------timeout----------------reset
> + *            |--half_timeout--(panic)--half_timeout--reset
>   *
>   */
>
> @@ -84,6 +88,13 @@ MODULE_PARM_DESC(timeout,
>                  "Watchdog timeout in seconds. (>=0, default="
>                  __MODULE_STRING(DEFAULT_TIMEOUT) ")");
>
> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
> +static bool panic_enabled = true;
> +module_param(panic_enabled, bool, 0);
> +MODULE_PARM_DESC(panic_enabled,
> +                "enable panic at half timeout. (default=true)");
> +#endif
> +
>  static bool nowayout = WATCHDOG_NOWAYOUT;
>  module_param(nowayout, bool, S_IRUGO);
>  MODULE_PARM_DESC(nowayout,
> @@ -159,6 +170,16 @@ static int sbsa_gwdt_stop(struct watchdog_device *wdd)
>         return 0;
>  }
>
> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
> +static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
> +{
> +       if (panic_enabled)
> +               panic("SBSA Watchdog half timeout");
> +
> +       return IRQ_HANDLED;
> +}
> +#endif
> +
>  static struct watchdog_info sbsa_gwdt_info = {
>         .identity       = "SBSA Generic Watchdog",
>         .options        = WDIOF_SETTIMEOUT |
> @@ -186,6 +207,9 @@ static int sbsa_gwdt_probe(struct platform_device *pdev)
>         struct resource *res;
>         u32 status;
>         int ret;
> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
> +       int irq;
> +#endif
>
>         gwdt = devm_kzalloc(dev, sizeof(*gwdt), GFP_KERNEL);
>         if (!gwdt)
> @@ -202,6 +226,14 @@ static int sbsa_gwdt_probe(struct platform_device *pdev)
>         if (IS_ERR(rf_base))
>                 return PTR_ERR(rf_base);
>
> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
> +       irq = platform_get_irq(pdev, 0);
> +       if (irq < 0) {
> +               dev_err(dev, "unable to get ws0 interrupt.\n");
> +               return irq;
> +       }
> +#endif
> +

Can't the driver revert to single stage mode if platform_get_irq()
fails?  That way the value of 'irq' can be tested throughout the
_probe() function and the #ifdefs removed.

Thanks,
Mathieu

>         /*
>          * Get the frequency of system counter from the cp15 interface of ARM
>          * Generic timer. We don't need to check it, because if it returns "0",
> @@ -228,6 +260,14 @@ static int sbsa_gwdt_probe(struct platform_device *pdev)
>                 dev_warn(dev, "System reset by WDT.\n");
>                 wdd->bootstatus |= WDIOF_CARDRESET;
>         }
> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
> +       ret = devm_request_irq(dev, irq, sbsa_gwdt_interrupt, 0,
> +                              pdev->name, gwdt);
> +       if (ret) {
> +               dev_err(dev, "unable to request IRQ %d\n", irq);
> +               return ret;
> +       }
> +#endif
>
>         ret = watchdog_register_device(wdd);
>         if (ret)
> @@ -242,6 +282,10 @@ static int sbsa_gwdt_probe(struct platform_device *pdev)
>
>         dev_info(dev, "Initialized with %ds timeout @ %u Hz%s\n", wdd->timeout,
>                  gwdt->clk, status & SBSA_GWDT_WCS_EN ? " [enabled]" : "");
> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
> +       dev_info(dev, "Half timeout panic %s.\n",
> +                panic_enabled ? "enabled" : "disabled");
> +#endif
>
>         return 0;
>  }
> --
> 2.5.0
>


From stern at rowland.harvard.edu  Thu Feb  4 08:36:53 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Thu, 4 Feb 2016 11:36:53 -0500 (EST)
Subject: [PATCH v4 1/1] USB: core: let USB device know device node
In-Reply-To: <20160204015928.GA11158@shlinux2>
Message-ID: <Pine.LNX.4.44L0.1602041130590.1515-100000@iolanthe.rowland.org>

On Thu, 4 Feb 2016, Peter Chen wrote:

> On Mon, Jan 25, 2016 at 03:24:39PM +0800, Peter Chen wrote:
> > Although most of USB devices are hot-plug's, there are still some devices
> > are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
> > If these kinds of USB devices are multiple functions, and they can supply
> > other interfaces like i2c, gpios for other devices, we may need to
> > describe these at device tree.
> > 
> > In this commit, it uses "reg" in dts as physical port number to match
> > the phyiscal port number decided by USB core, if they are the same,
> > then the device node is for the device we are creating for USB core.
> > 
> > Signed-off-by: Peter Chen <peter.chen at freescale.com>
> > ---
> > Changes for v4:
> > - The range of "reg" should be 1-31, changing device node address
> >   style as in lower case hexadecimal with leading zeroes suppressed
> >   [binding doc, usb-device.txt]
> > - Improve the example at binding doc, it describes node from the top
> >   (the controller)
> > - Delete the struct of_node * within struct usb_device
> > - Using usb_hcd_find_raw_port_number to get raw port number under root
> >   hub port
> > 
> 
> Hi Alan, Arnd, and others, would you please give Ack for it if you
> are OK with this patch? I am not sure if Greg will queue it or not
> if no one Acks it, thanks.


> > @@ -508,11 +509,20 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
> >  	dev->connect_time = jiffies;
> >  	dev->active_duration = -jiffies;
> >  #endif
> > -	if (root_hub)	/* Root hub always ok [and always wired] */
> > +	if (root_hub) {	/* Root hub always ok [and always wired] */
> >  		dev->authorized = 1;
> > -	else {
> > +		dev->dev.of_node = bus->controller->of_node;
> > +	} else {
> >  		dev->authorized = !!HCD_DEV_AUTHORIZED(usb_hcd);
> >  		dev->wusb = usb_bus_is_wusb(bus) ? 1 : 0;
> > +
> > +		if (dev->dev.parent->parent == bus->controller)
> > +			/* device under root hub's port */
> > +			port1 = usb_hcd_find_raw_port_number(usb_hcd,
> > +				port1);

I would change the test to "if (!parent->parent)" and add {} around the 
body (since it's 3 lines long).  Also, although this doesn't really 
matter, you could consider putting the new code inside the previous big 
"if" statement instead of down here at the end of the function.

Otherwise the USB parts of this patch look okay to me.  I can't comment 
on the DT parts.

Alan Stern



From timur at codeaurora.org  Thu Feb  4 08:37:38 2016
From: timur at codeaurora.org (Timur Tabi)
Date: Thu, 4 Feb 2016 10:37:38 -0600
Subject: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <20160204163101.GH17257@arm.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-5-git-send-email-fu.wei@linaro.org>
 <20160204163101.GH17257@arm.com>
Message-ID: <56B37E52.300@codeaurora.org>

Will Deacon wrote:
>> +static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
>> >+{
>> >+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
>> >+
>> >+	/*
>> >+	* Writing WRR for an explicit watchdog refresh.
>> >+	* You can write anyting(like 0xc0ffee).
>> >+	*/
>> >+	writel(0xc0ffee, gwdt->refresh_base + SBSA_GWDT_WRR);
>> >+
>> >+	return 0;
>> >+}
> You might get in trouble for that. 0xd09f00d is probably less poisonous.
>
> http://www.petpoisonhelpline.com/poison/caffeine/

Any reason why we can't just keep it simple and write 0?


From linux at roeck-us.net  Thu Feb  4 08:41:55 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 4 Feb 2016 08:41:55 -0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <CANLsYkyLBfSKFM6CCyPP+Eaua2B+n80wL2hnQVSvfUNMPd3OdQ@mail.gmail.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <CANLsYkyLBfSKFM6CCyPP+Eaua2B+n80wL2hnQVSvfUNMPd3OdQ@mail.gmail.com>
Message-ID: <56B37F53.9060002@roeck-us.net>

On 02/04/2016 08:32 AM, Mathieu Poirier wrote:
> On 3 February 2016 at 10:18,  <fu.wei at linaro.org> wrote:
>> From: Fu Wei <fu.wei at linaro.org>
>>
>> This patch registers the WS0 interrupt routine to trigger panic,
>> when the watchdog reachs the first stage (the half timeout).
>> This function can help administrator to backup the system context
>> info by panic console output or kdump (if supported), once system
>> goes wrong (doesn't feed the watchdog in the half timeout).
>>
>> User also can skip panic by setting panic_enabled (module parameter) as 0
>>
>> Signed-off-by: Fu Wei <fu.wei at linaro.org>
>> ---
>>   Documentation/watchdog/watchdog-parameters.txt |  1 +
>>   drivers/watchdog/Kconfig                       | 10 +++++
>>   drivers/watchdog/sbsa_gwdt.c                   | 54 +++++++++++++++++++++++---
>>   3 files changed, 60 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
>> index 300eb4d..31641e2 100644
>> --- a/Documentation/watchdog/watchdog-parameters.txt
>> +++ b/Documentation/watchdog/watchdog-parameters.txt
>> @@ -286,6 +286,7 @@ nowayout: Watchdog cannot be stopped once started
>>   -------------------------------------------------
>>   sbsa_gwdt:
>>   timeout: Watchdog timeout in seconds. (default 20s)
>> +panic_enabled: Enable panic at half timeout. (default=true)
>>   nowayout: Watchdog cannot be stopped once started
>>          (default=kernel config parameter)
>>   -------------------------------------------------
>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>> index 4ab1b05..42adfdf 100644
>> --- a/drivers/watchdog/Kconfig
>> +++ b/drivers/watchdog/Kconfig
>> @@ -218,6 +218,16 @@ config ARM_SBSA_WATCHDOG
>>            To compile this driver as module, choose M here: The module
>>            will be called sbsa_gwdt.
>>
>> +config ARM_SBSA_WATCHDOG_PANIC
>> +       bool "ARM SBSA Generic Watchdog triggers panic at the half timeout"
>> +       depends on ARM_SBSA_WATCHDOG
>> +       help
>> +         ARM SBSA Generic Watchdog will trigger panic in the first signal
>> +         (WS0) interrupt routine when the half timeout is reached.
>> +         This function can help administrator to backup the system context
>> +         info by panic console output or kdump (if supported).
>> +         But user can skip panic by setting moduleparam panic_enabled as 0.
>> +
>>   config ASM9260_WATCHDOG
>>          tristate "Alphascale ASM9260 watchdog"
>>          depends on MACH_ASM9260
>> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
>> index 5a2dba3..d18cf37 100644
>> --- a/drivers/watchdog/sbsa_gwdt.c
>> +++ b/drivers/watchdog/sbsa_gwdt.c
>> @@ -16,18 +16,22 @@
>>    * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>    * GNU General Public License for more details.
>>    *
>> - * This SBSA Generic watchdog driver is a single stage timeout version.
>> + * This SBSA Generic watchdog driver is a two stages version.
>>    * Since this watchdog timer has two stages, and each stage is determined
>>    * by WOR. So the timeout is (WOR * 2).
>> - * When first timeout is reached, WS0 is triggered, the interrupt
>> - * triggered by WS0 will be ignored, then the second watch period starts;
>> - * when second timeout is reached, then WS1 is triggered, system reset.
>> + * When the first stage(the half timeout) is reached, WS0 interrupt is
>> + * triggered, at this moment the second watch period starts;
>> + * In the WS0 interrupt routine, panic will be triggered for saving the
>> + * system context.
>> + * If the system is getting into trouble and cannot be reset by panic or
>> + * restart properly by the kdump kernel(if supported), then the second
>> + * stage (the timeout) will be reached, system will be reset by WS1.
>>    *
>>    * More details about the hardware specification of this device:
>>    * ARM DEN0029B - Server Base System Architecture (SBSA)
>>    *
>>    * SBSA GWDT: |--------WOR-------WS0--------WOR-------WS1
>> - *            |----------------timeout----------------reset
>> + *            |--half_timeout--(panic)--half_timeout--reset
>>    *
>>    */
>>
>> @@ -84,6 +88,13 @@ MODULE_PARM_DESC(timeout,
>>                   "Watchdog timeout in seconds. (>=0, default="
>>                   __MODULE_STRING(DEFAULT_TIMEOUT) ")");
>>
>> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
>> +static bool panic_enabled = true;
>> +module_param(panic_enabled, bool, 0);
>> +MODULE_PARM_DESC(panic_enabled,
>> +                "enable panic at half timeout. (default=true)");
>> +#endif
>> +
>>   static bool nowayout = WATCHDOG_NOWAYOUT;
>>   module_param(nowayout, bool, S_IRUGO);
>>   MODULE_PARM_DESC(nowayout,
>> @@ -159,6 +170,16 @@ static int sbsa_gwdt_stop(struct watchdog_device *wdd)
>>          return 0;
>>   }
>>
>> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
>> +static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
>> +{
>> +       if (panic_enabled)
>> +               panic("SBSA Watchdog half timeout");
>> +
>> +       return IRQ_HANDLED;
>> +}
>> +#endif
>> +
>>   static struct watchdog_info sbsa_gwdt_info = {
>>          .identity       = "SBSA Generic Watchdog",
>>          .options        = WDIOF_SETTIMEOUT |
>> @@ -186,6 +207,9 @@ static int sbsa_gwdt_probe(struct platform_device *pdev)
>>          struct resource *res;
>>          u32 status;
>>          int ret;
>> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
>> +       int irq;
>> +#endif
>>
>>          gwdt = devm_kzalloc(dev, sizeof(*gwdt), GFP_KERNEL);
>>          if (!gwdt)
>> @@ -202,6 +226,14 @@ static int sbsa_gwdt_probe(struct platform_device *pdev)
>>          if (IS_ERR(rf_base))
>>                  return PTR_ERR(rf_base);
>>
>> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
>> +       irq = platform_get_irq(pdev, 0);
>> +       if (irq < 0) {
>> +               dev_err(dev, "unable to get ws0 interrupt.\n");
>> +               return irq;
>> +       }
>> +#endif
>> +
>
> Can't the driver revert to single stage mode if platform_get_irq()
> fails?  That way the value of 'irq' can be tested throughout the
> _probe() function and the #ifdefs removed.
>
Good point. Making irq support mandatory on all systems isn't really
a good idea.

Thanks,
Guenter

> Thanks,
> Mathieu
>
>>          /*
>>           * Get the frequency of system counter from the cp15 interface of ARM
>>           * Generic timer. We don't need to check it, because if it returns "0",
>> @@ -228,6 +260,14 @@ static int sbsa_gwdt_probe(struct platform_device *pdev)
>>                  dev_warn(dev, "System reset by WDT.\n");
>>                  wdd->bootstatus |= WDIOF_CARDRESET;
>>          }
>> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
>> +       ret = devm_request_irq(dev, irq, sbsa_gwdt_interrupt, 0,
>> +                              pdev->name, gwdt);
>> +       if (ret) {
>> +               dev_err(dev, "unable to request IRQ %d\n", irq);
>> +               return ret;
>> +       }
>> +#endif
>>
>>          ret = watchdog_register_device(wdd);
>>          if (ret)
>> @@ -242,6 +282,10 @@ static int sbsa_gwdt_probe(struct platform_device *pdev)
>>
>>          dev_info(dev, "Initialized with %ds timeout @ %u Hz%s\n", wdd->timeout,
>>                   gwdt->clk, status & SBSA_GWDT_WCS_EN ? " [enabled]" : "");
>> +#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
>> +       dev_info(dev, "Half timeout panic %s.\n",
>> +                panic_enabled ? "enabled" : "disabled");
>> +#endif
>>
>>          return 0;
>>   }
>> --
>> 2.5.0
>>
>



From timur at codeaurora.org  Thu Feb  4 08:43:12 2016
From: timur at codeaurora.org (Timur Tabi)
Date: Thu, 4 Feb 2016 10:43:12 -0600
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <CANLsYkyLBfSKFM6CCyPP+Eaua2B+n80wL2hnQVSvfUNMPd3OdQ@mail.gmail.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <CANLsYkyLBfSKFM6CCyPP+Eaua2B+n80wL2hnQVSvfUNMPd3OdQ@mail.gmail.com>
Message-ID: <56B37FA0.5000209@codeaurora.org>

Mathieu Poirier wrote:
>> >+#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
>> >+       irq = platform_get_irq(pdev, 0);
>> >+       if (irq < 0) {
>> >+               dev_err(dev, "unable to get ws0 interrupt.\n");
>> >+               return irq;
>> >+       }
>> >+#endif
>> >+
> Can't the driver revert to single stage mode if platform_get_irq()
> fails?  That way the value of 'irq' can be tested throughout the
> _probe() function and the #ifdefs removed.

I like that idea.  The same can be done with the devm_request_irq() 
call.  It should definitely still display a warning if the command-line 
option is set but no interrupt is available.


From gabriele.paoloni at huawei.com  Thu Feb  4 08:44:12 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Thu, 4 Feb 2016 16:44:12 +0000
Subject: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host
 Controllers
In-Reply-To: <76564455.dlc1WHiVY2@wuerfel>
References: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
 <2387127.DMZaDnZvEW@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1EC9EC12@lhreml503-mbs>
 <76564455.dlc1WHiVY2@wuerfel>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1EC9EF4B@lhreml503-mbs>

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 04 February 2016 16:07
> To: Gabriele Paoloni
> Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C); Linuxarm;
> qiujiang; bhelgaas at google.com; Lorenzo.Pieralisi at arm.com;
> tn at semihalf.com; zhangjukuo; xuwei (O); Liguozhu (Kenneth); linux-
> pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> acpi at vger.kernel.org; linux-kernel at vger.kernel.org; jcm at redhat.com
> Subject: Re: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host
> Controllers
> 
> On Thursday 04 February 2016 15:11:18 Gabriele Paoloni wrote:
> > >
> > > ACPI has its own PCI support, and should not need drivers for host
> > > bridges. I don't think we can really mix the two things, as ACPI
> > > needs to have access to things like PCI config space way before
> > > we are probing normal device drivers.
> > >
> > > Please put this in drivers/acpi/pci*.c.
> >
> > I can put pcie-hisi-acpi.c under drivers/acpi/
> >
> > However if you look at the driver it is made up of three parts:
> > pcie-hisi.c --> the DT based driver
> > pcie-hisi-acpi.c --> the ACPI based hook and ACPI specific init
> callback
> > pcie-hisi-common.c --> common functions shared between DT and ACPI
> versions
> >                        of the driver
> >
> > Now I think that moving pcie-hisi-acpi.c under drivers/acpi/
> > would make it hard to read as you need to jump across directories
> > and it seems a bit unnatural...
> >
> > However it is not a big issue to me...
> 
> That's not really what I meant though: the pcie-hisi driver uses the
> pcie-designware.c library, most of which makes no sense in an
> environment
> where you have ACPI, e.g. link training, custom MSI support, initial
> register setup, platform driver hooks, etc.
> 
> You should add a very minimal set of hacks for the parts in this driver
> that diverge from a standard SBSA compliant PCIe host that ACPI expects.

Effectively the ACPI version of the HiSilicon driver does not rely on
Designware as much as the DT version (that calls dw_pcie_host_init());
however in order to do what you suggest I'd need to copy and paste and
modify dw_pcie_rd_conf and dw_pcie_wr_conf.
Also I'd need to declare duplicate version of the functions in
pcie-hisi-common.c (if I do not want to split the object across
different paths "drivers/pci/host" and "drivers/acpi/")

Now I can do it but I thought it was more correct to pass &dw_pcie_ops
as input pointer in DECLARE_ACPI_MCFG_FIXUP(); this is also because maybe in
future other Designware based controllers may need to support ACPI and it
would be easier for them to reuse their DT based driver functions

Honestly I am a bit confused...

Thanks

Gab

> 
> 	Arnd


From linux at roeck-us.net  Thu Feb  4 08:46:49 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 4 Feb 2016 08:46:49 -0800
Subject: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <56B37E52.300@codeaurora.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-5-git-send-email-fu.wei@linaro.org>
 <20160204163101.GH17257@arm.com> <56B37E52.300@codeaurora.org>
Message-ID: <56B38079.10607@roeck-us.net>

On 02/04/2016 08:37 AM, Timur Tabi wrote:
> Will Deacon wrote:
>>> +static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
>>> >+{
>>> >+    struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
>>> >+
>>> >+    /*
>>> >+    * Writing WRR for an explicit watchdog refresh.
>>> >+    * You can write anyting(like 0xc0ffee).
>>> >+    */
>>> >+    writel(0xc0ffee, gwdt->refresh_base + SBSA_GWDT_WRR);
>>> >+
>>> >+    return 0;
>>> >+}
>> You might get in trouble for that. 0xd09f00d is probably less poisonous.
>>
>> http://www.petpoisonhelpline.com/poison/caffeine/
>
> Any reason why we can't just keep it simple and write 0?

+1

Guenter



From bcrl at kvack.org  Thu Feb  4 08:47:18 2016
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Thu, 4 Feb 2016 11:47:18 -0500
Subject: linux-next: build failure after merge of the aio tree
In-Reply-To: <20160204161741.GH10826@n2100.arm.linux.org.uk>
References: <CAMuHMdUy-cqeN8COO4rdpY-mOH+6gth40wB31-edkj8CO5PFCw@mail.gmail.com>
 <20160204131959.6695c7bf@canb.auug.org.au> <20160204134142.GA16315@kvack.org>
 <20160204135056.GE10826@n2100.arm.linux.org.uk>
 <20160204140822.GB16315@kvack.org>
 <20160204141253.GF10826@n2100.arm.linux.org.uk>
 <20160204143204.GC16315@kvack.org>
 <20160204143907.GG10826@n2100.arm.linux.org.uk>
 <20160204160101.GD16315@kvack.org>
 <20160204161741.GH10826@n2100.arm.linux.org.uk>
Message-ID: <20160204164718.GF16315@kvack.org>

On Thu, Feb 04, 2016 at 04:17:42PM +0000, Russell King - ARM Linux wrote:
> That's the easy bit!
> 
> The problem you're going to run into is here:
> 
> #define __get_user_nocheck(x, ptr, size)                                \
> ({                                                                      \
>         int __gu_err;                                                   \
>         unsigned long __gu_val;                                         \
>         __uaccess_begin();                                              \
>         __get_user_size(__gu_val, (ptr), (size), __gu_err, -EFAULT);    \
>         __uaccess_end();                                                \
>         (x) = (__force __typeof__(*(ptr)))__gu_val;                     \
> 
> __gu_val will be 32-bit, even when you're wanting a 64-bit quantity.
> That's where the fun and games start...

You're right -- it's quite non-trivial.  How evil would it be to make a 
separate __get_user64() macro?

		-ben
-- 
"Thought is the essence of where you are now."


From nicolas.pitre at linaro.org  Thu Feb  4 08:49:34 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 4 Feb 2016 11:49:34 -0500 (EST)
Subject: [PATCH] ARM: remove duplicate definitions of __vectors_start
 and __stubs_start
In-Reply-To: <1454574705-15109-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454574705-15109-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <alpine.LFD.2.20.1602041148050.17825@knanqh.ubzr>

On Thu, 4 Feb 2016, Ard Biesheuvel wrote:

> Commit b9b32bf70f2f ("ARM: use linker magic for vectors and vector stubs")
> introduced new global definitions of __vectors_start and __stubs_start,
> and changed the existing ones to have internal linkage only. However, these
> symbols are still visible to kallsyms, and due to the way the .vectors and
> .stubs sections are emitted at the base of the VMA space, these duplicate
> definitions have conflicting values.
> 
>   $ nm -n vmlinux |grep -E __vectors\|__stubs
>   00000000 t __vectors_start
>   00001000 t __stubs_start
>   c0e77000 T __vectors_start
>   c0e77020 T __stubs_start
> 
> This is completely harmless by itself, since the wrong values are local
> symbols that cannot be referenced by other object files directly. However,
> since these symbols are also listed in the kallsyms symbol table in some
> cases (i.e., CONFIG_KALLSYMS_ALL=y and CONFIG_XIP_KERNEL=y), having these
> conflicting values can be confusing. So either remove them, or make them
> strictly local.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

Acked-by: Nicolas Pitre <nico at linaro.org>


> ---
> 
> This is a separate fix for the duplicate symbols based on v4.5-rc2,
> so that it can be applied separately if desired. In that case, I will
> rebase my kallsyms series onto this patch.
> 
>  arch/arm/kernel/entry-armv.S | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> index 3ce377f7251f..788e40c1254f 100644
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -1064,7 +1064,6 @@ ENDPROC(vector_\name)
>  	.endm
>  
>  	.section .stubs, "ax", %progbits
> -__stubs_start:
>  	@ This must be the first word
>  	.word	vector_swi
>  
> @@ -1206,10 +1205,10 @@ vector_addrexcptn:
>  	.equ	vector_fiq_offset, vector_fiq
>  
>  	.section .vectors, "ax", %progbits
> -__vectors_start:
> +.L__vectors_start:
>  	W(b)	vector_rst
>  	W(b)	vector_und
> -	W(ldr)	pc, __vectors_start + 0x1000
> +	W(ldr)	pc, .L__vectors_start + 0x1000
>  	W(b)	vector_pabt
>  	W(b)	vector_dabt
>  	W(b)	vector_addrexcptn
> -- 
> 2.5.0
> 
> 


From ard.biesheuvel at linaro.org  Thu Feb  4 07:50:29 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu,  4 Feb 2016 16:50:29 +0100
Subject: [PATCH v2 6/7] arm64: efistub: check for h/w support before booting a
 >4 KB granule kernel
In-Reply-To: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1454601030-9093-7-git-send-email-ard.biesheuvel@linaro.org>

A kernel built with support for a page size that is not supported by the
hardware it runs on cannot boot to a state where it can inform the user
about it.

If we happen to be booting via UEFI, we can fail gracefully so check
if the currently configured page size is supported by the hardware before
entering the kernel proper. Note that UEFI mandates support for 4 KB pages,
so in that case, no check is needed.

Reviewed-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/firmware/efi/libstub/arm64-stub.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c
index 9e0342745e4f..aef04ad60e0d 100644
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -12,6 +12,26 @@
 #include <linux/efi.h>
 #include <asm/efi.h>
 #include <asm/sections.h>
+#include <asm/sysreg.h>
+
+efi_status_t check_platform_features(efi_system_table_t *sys_table_arg)
+{
+	u64 tg;
+
+	/* UEFI mandates support for 4 KB granule, no need to check */
+	if (IS_ENABLED(CONFIG_ARM64_4K_PAGES))
+		return EFI_SUCCESS;
+
+	tg = (read_cpuid(ID_AA64MMFR0_EL1) >> ID_AA64MMFR0_TGRAN_SHIFT) & 0xf;
+	if (tg != ID_AA64MMFR0_TGRAN_SUPPORTED) {
+		if (IS_ENABLED(CONFIG_ARM64_64K_PAGES))
+			pr_efi_err(sys_table_arg, "This 64 KB granule kernel is not supported by your CPU\n");
+		else
+			pr_efi_err(sys_table_arg, "This 16 KB granule kernel is not supported by your CPU\n");
+		return EFI_UNSUPPORTED;
+	}
+	return EFI_SUCCESS;
+}
 
 efi_status_t handle_kernel_image(efi_system_table_t *sys_table_arg,
 				 unsigned long *image_addr,
-- 
2.5.0



From p.zabel at pengutronix.de  Thu Feb  4 08:54:26 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 04 Feb 2016 17:54:26 +0100
Subject: [PATCH v3 1/3] reset: Make [of_]reset_control_get[_foo]
 functions wrappers
In-Reply-To: <1453918516-3078-2-git-send-email-hdegoede@redhat.com>
References: <1453918516-3078-1-git-send-email-hdegoede@redhat.com>
 <1453918516-3078-2-git-send-email-hdegoede@redhat.com>
Message-ID: <1454604866.3356.78.camel@pengutronix.de>

Hi Hans,

Am Mittwoch, den 27.01.2016, 19:15 +0100 schrieb Hans de Goede:
[...]
> +/**
> + * reset_control_get - Lookup and obtain a reference to a reset controller.
> + * @dev: device to be reset by the controller
> + * @id: reset line name
> + *
> + * Returns a struct reset_control or IS_ERR() condition containing errno.
> + *
> + * Use of id names is optional.
> + */
> +static inline struct reset_control *__must_check reset_control_get(
>  					struct device *dev, const char *id)
>  {
> -	return ERR_PTR(-ENOTSUPP);
> +#ifndef CONFIG_RESET_CONTROLLER
> +	WARN_ON(1);
> +#endif
> +	return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0);

Even though we are device tree only at this point, I'd prefer to keep an
exported function that takes a struct device argument, for example:

	return __reset_control_get(dev, id, 0);

regards
Philipp



From p.zabel at pengutronix.de  Thu Feb  4 08:55:22 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 04 Feb 2016 17:55:22 +0100
Subject: [PATCH v3 3/3] reset: Add support for shared reset controls
In-Reply-To: <56ADCFEF.3040707@redhat.com>
References: <1453918516-3078-1-git-send-email-hdegoede@redhat.com>
 <1453918516-3078-4-git-send-email-hdegoede@redhat.com>
 <20160130113837.GA25528@pengutronix.de> <56ADCFEF.3040707@redhat.com>
Message-ID: <1454604922.3356.80.camel@pengutronix.de>

Hi Hans,

Am Sonntag, den 31.01.2016, 10:12 +0100 schrieb Hans de Goede:
> Hi,
> 
> On 01/30/2016 12:38 PM, Philipp Zabel wrote:
> > Hi Hans,
> >
> > On Wed, Jan 27, 2016 at 07:15:16PM +0100, Hans de Goede wrote:
> >> In some SoCs some hw-blocks share a reset control. Add support for this
> >> setup by adding new:
> >>
> >> reset_control_get_shared()
> >> devm_reset_control_get_shared()
> >> devm_reset_control_get_shared_by_index()
> >>
> >> methods to get a reset_control. Note that this patch omits adding of_
> >> variants, if these are needed later they can be easily added.
> >>
> >> This patch also changes the behavior of the existing exclusive
> >> reset_control_get() variants, if these are now called more then once
> >> for the same reset_control they will return -EBUSY. To catch existing
> >> drivers triggering this error (there should not be any) a WARN_ON(1)
> >> is added in this path.
> >
> > Which is a good thing.
> >
> >> When a reset_control is shared, the behavior of reset_control_assert /
> >> deassert is changed, for shared reset_controls these will work like the
> >> clock-enable/disable and regulator-on/off functions. They will keep a
> >> deassert_count, and only (re-)assert the reset after reset_control_assert
> >> has been called as many times as reset_control_deassert was called.
> >>
> >> Calling reset_control_assert without first calling reset_control_deassert
> >> is not allowed on a shared reset control. Calling reset_control_reset is
> >> also not allowed on a shared reset control.
> >>
> >> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
> >
> > All three patches look very nice. I'll give them a test-drive next week.
> > So far I have one small issue, and I like Stephens suggestion of
> > elaborating on how shared resets are to be used a bit more.
> 
> I can do that, where would you like me to put this, a doxygen style comment
> in include/linux/reset.h ?

Sorry for the delay. I had just thought of extending the
reset_control_get_shared comment below, but an overview comment in
reset.h would be fine, too.

[...]
> >>   /**
> >> - * of_reset_control_get - Lookup and obtain a reference to a reset controller.
> >> + * reset_control_get_shared - Lookup and obtain a shared reference to a
> >> + *                            reset controller.
> >> + * @dev: device to be reset by the controller
> >> + * @id: reset line name
> >> + *
> >> + * Returns a struct reset_control or IS_ERR() condition containing errno.
> >
> > How about addressing Stephen's suggestion by extending this kerneldoc comment a
> > bit?

^^^ this.

Now that I think of it, the reset_control_assert function comment should
explicitly state that for shared resets the drivers can't expect their
registers and internal state to be reset, but must be prepared for this
to happen.

best regards
Philipp



From arnd at arndb.de  Thu Feb  4 09:01:51 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 04 Feb 2016 18:01:51 +0100
Subject: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host
 Controllers
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1EC9EF4B@lhreml503-mbs>
References: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
 <76564455.dlc1WHiVY2@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1EC9EF4B@lhreml503-mbs>
Message-ID: <1930535.mkCdtpUWq7@wuerfel>

On Thursday 04 February 2016 16:44:12 Gabriele Paoloni wrote:
> Effectively the ACPI version of the HiSilicon driver does not rely on
> Designware as much as the DT version (that calls dw_pcie_host_init());
> however in order to do what you suggest I'd need to copy and paste and
> modify dw_pcie_rd_conf and dw_pcie_wr_conf.
> Also I'd need to declare duplicate version of the functions in
> pcie-hisi-common.c (if I do not want to split the object across
> different paths "drivers/pci/host" and "drivers/acpi/")
> 
> Now I can do it but I thought it was more correct to pass &dw_pcie_ops
> as input pointer in DECLARE_ACPI_MCFG_FIXUP(); this is also because maybe in
> future other Designware based controllers may need to support ACPI and it
> would be easier for them to reuse their DT based driver functions
> 
> Honestly I am a bit confused...
> 

I don't think you can use the dw_pcie_ops as-is anyway, as they in
turn rely on the device driver structure, and you also don't need
those as they seem to be written for the generic case of a 32-bit
architecture that does not have enough space to map the entire
config space into MMIO. Just set up all those mapping registers from
the firmware and pass the config space base address as you'd normally
do on ACPI.

	Arnd


From dirk.behme at gmail.com  Thu Feb  4 09:06:10 2016
From: dirk.behme at gmail.com (Dirk Behme)
Date: Thu,  4 Feb 2016 18:06:10 +0100
Subject: [PATCH v3] drivers/perf: arm_pmu: make info messages more verbose
Message-ID: <1454605570-4725-1-git-send-email-dirk.behme@gmail.com>

From: Dirk Behme <dirk.behme at de.bosch.com>

On a big.LITTLE system e.g. with Cortex A57 and A53 in case not all cores
are online at PMU probe time we might get

hw perfevents: failed to probe PMU!
hw perfevents: failed to register PMU devices!

making it unclear which cores failed, here.

Add the device tree full name which failed and the error value resulting
in a more verbose and helpful message like

hw perfevents: /soc/pmu_a53: failed to probe PMU! Error -6
hw perfevents: /soc/pmu_a53: failed to register PMU devices! Error -6

Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
---
Changes in v3: Rebase against Will's perf/updates (8d1a0ae72)

Changes in v2: Use the full node name from DT instead of pmu->name, as if
we fail to find anything in the match table, that'll be NULL. Additionally,
add the error value to get an idea why it failed.

 drivers/perf/arm_pmu.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index eb5bee0..ca63a45 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -907,7 +907,8 @@ int arm_pmu_device_probe(struct platform_device *pdev,
 	}
 
 	if (ret) {
-		pr_info("failed to probe PMU!\n");
+		pr_info("%s: failed to probe PMU! Error %i\n",
+			node->full_name, ret);
 		goto out_free;
 	}
 
@@ -927,7 +928,8 @@ int arm_pmu_device_probe(struct platform_device *pdev,
 out_destroy:
 	cpu_pmu_destroy(pmu);
 out_free:
-	pr_info("failed to register PMU devices!\n");
+	pr_info("%s: failed to register PMU devices! Error %i\n",
+		node->full_name, ret);
 	kfree(pmu);
 	return ret;
 }
-- 
2.7.0



From gabriele.paoloni at huawei.com  Thu Feb  4 09:06:40 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Thu, 4 Feb 2016 17:06:40 +0000
Subject: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host
 Controllers
In-Reply-To: <1930535.mkCdtpUWq7@wuerfel>
References: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
 <76564455.dlc1WHiVY2@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1EC9EF4B@lhreml503-mbs>
 <1930535.mkCdtpUWq7@wuerfel>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1EC9F055@lhreml503-mbs>

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 04 February 2016 17:02
> To: Gabriele Paoloni
> Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C); Linuxarm;
> qiujiang; bhelgaas at google.com; Lorenzo.Pieralisi at arm.com;
> tn at semihalf.com; zhangjukuo; xuwei (O); Liguozhu (Kenneth); linux-
> pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> acpi at vger.kernel.org; linux-kernel at vger.kernel.org; jcm at redhat.com
> Subject: Re: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host
> Controllers
> 
> On Thursday 04 February 2016 16:44:12 Gabriele Paoloni wrote:
> > Effectively the ACPI version of the HiSilicon driver does not rely on
> > Designware as much as the DT version (that calls
> dw_pcie_host_init());
> > however in order to do what you suggest I'd need to copy and paste
> and
> > modify dw_pcie_rd_conf and dw_pcie_wr_conf.
> > Also I'd need to declare duplicate version of the functions in
> > pcie-hisi-common.c (if I do not want to split the object across
> > different paths "drivers/pci/host" and "drivers/acpi/")
> >
> > Now I can do it but I thought it was more correct to pass
> &dw_pcie_ops
> > as input pointer in DECLARE_ACPI_MCFG_FIXUP(); this is also because
> maybe in
> > future other Designware based controllers may need to support ACPI
> and it
> > would be easier for them to reuse their DT based driver functions
> >
> > Honestly I am a bit confused...
> >
> 
> I don't think you can use the dw_pcie_ops as-is anyway, as they in
> turn rely on the device driver structure, and you also don't need
> those as they seem to be written for the generic case of a 32-bit
> architecture that does not have enough space to map the entire
> config space into MMIO. Just set up all those mapping registers from
> the firmware and pass the config space base address as you'd normally
> do on ACPI.

Ok thanks, I'll wait a bit to see if there is any comment on this
from other people, if not I'll rework the ACPI driver as you suggest
and remove any dependency on Designware.

Cheers

Gab

> 
> 	Arnd


From tony at atomide.com  Thu Feb  4 09:20:25 2016
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Feb 2016 09:20:25 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <Pine.LNX.4.44L0.1602041059070.1515-100000@iolanthe.rowland.org>
References: <CAPDyKFr3jqh5bDFOuKLgomhQ2P9+yN5Ps8E0CH8r-oOjvBuswg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602041059070.1515-100000@iolanthe.rowland.org>
Message-ID: <20160204172025.GQ19432@atomide.com>

* Alan Stern <stern at rowland.harvard.edu> [160204 08:05]:
> On Thu, 4 Feb 2016, Ulf Hansson wrote:
> 
> > Just wanted to add yet some new findings while I was looking into this
> > regression.
> > 
> > So, the reason why pm_runtime_put_sync() doesn't idle the device in
> > these cases, is because autosuspend is respected and for some reason
> > the autosuspend timer hasn't expired.
> 
> No doubt the autosuspend delay is longer than the time it takes for a 
> probe to fail.
> 
> > I was wondering *why* the timer isn't considered as expired, because
> > the driver don't call pm_runtime_mark_last_busy() in the failing probe
> > case...
> > 
> > Then I realized the following commit was merged a few releases ago,
> > which makes the runtime PM core to invoke pm_runtime_mark_last_busy()
> > for us.
> > 
> > commit 56f487c78015936097474fd89b2ccb229d500d0f
> > Author: Tony Lindgren <tony at atomide.com>
> > Date:   Wed May 13 16:36:32 2015 -0700
> > PM / Runtime: Update last_busy in rpm_resume
> > 
> > So, this commit actually causes the devices to stay active after a
> > failed probe attempt.
> > 
> > I think it's a good idea to revert this change, but what to you think?
> 
> I disagree.  The whole idea of autosuspend is to prevent the device's
> power state from bouncing up and down too rapidly.  This implies that 
> whenever the device gets resumed, we should wait at least the minimum 
> autosuspend delay before allowing the next autosuspend.

Yeah let's not revert 56f487c78015. Without that we have devices
falling right back to sleep.

Regards,

Tony


From romain.izard.pro at gmail.com  Thu Feb  4 09:21:33 2016
From: romain.izard.pro at gmail.com (Romain Izard)
Date: Thu,  4 Feb 2016 18:21:33 +0100
Subject: [PATCH v1] clocksource: atmel-pit: register as a sched_clock
Message-ID: <1454606493-15094-1-git-send-email-romain.izard.pro@gmail.com>

Register the counter of the Periodic Interval Timer as a possible source
for sched_clock. This provides a better precision than the jiffies-based
default.

Signed-off-by: Romain Izard <romain.izard.pro at gmail.com>
---

To reduce overhead and cache consumption, sched_clock_register does not
take a void* argument, as it is the case when using interrupt handlers.
As a result, the signature of the function used to read the counter is
u64 (*) (void). It is thus necessary to use a static variable inside the
driver to keep a reference to the clocksource. It is a common pattern in
other existing clocksource drivers.

All existing Atmel SoCs that rely on the PIT only have a single instance
of the controller, and future SoCs should remain this way as additional
timers are provided in 'Timer Counter' controllers. Additional code
handling the case of multiple PIT instances would thus be dead code.

 drivers/clocksource/timer-atmel-pit.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/clocksource/timer-atmel-pit.c b/drivers/clocksource/timer-atmel-pit.c
index d911c5dca8f1..744e1afc4b69 100644
--- a/drivers/clocksource/timer-atmel-pit.c
+++ b/drivers/clocksource/timer-atmel-pit.c
@@ -21,6 +21,7 @@
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
 #include <linux/slab.h>
+#include <linux/sched_clock.h>
 
 #define AT91_PIT_MR		0x00			/* Mode Register */
 #define AT91_PIT_PITIEN			BIT(25)			/* Timer Interrupt Enable */
@@ -174,6 +175,13 @@ static irqreturn_t at91sam926x_pit_interrupt(int irq, void *dev_id)
 	return IRQ_NONE;
 }
 
+static struct clocksource *pit_sched_clock;
+
+static u64 pit_sched_clock_read(void)
+{
+	return read_pit_clk(pit_sched_clock);
+}
+
 /*
  * Set up both clocksource and clockevent support.
  */
@@ -206,6 +214,9 @@ static void __init at91sam926x_pit_common_init(struct pit_data *data)
 	data->clksrc.flags = CLOCK_SOURCE_IS_CONTINUOUS;
 	clocksource_register_hz(&data->clksrc, pit_rate);
 
+	pit_sched_clock = &data->clksrc;
+	sched_clock_register(pit_sched_clock_read, bits, pit_rate);
+
 	/* Set up irq handler */
 	ret = request_irq(data->irq, at91sam926x_pit_interrupt,
 			  IRQF_SHARED | IRQF_TIMER | IRQF_IRQPOLL,
-- 
2.5.0



From tn at semihalf.com  Thu Feb  4 09:28:38 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:38 +0100
Subject: [PATCH V4 00/23] MMCONFIG refactoring and support for ARM64 PCI
 hostbridge init based on ACPI
Message-ID: <1454606941-9523-1-git-send-email-tn@semihalf.com>

>From the functionality point of view this series might be split into the
following logic parts:
1. Make MMCONFIG code arch-agnostic which allows all architectures to collect
   PCI config regions and used when necessary.
2. Move non-arch specific bits to the core code.
3. Use MMCONFIG code and implement generic ACPI based PCI host controller driver.
4. Enable above driver on ARM64

Patches has been built on top of 4.5-rc1 and can be found here:
git at github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v4)

NOTE, this patch set depends on Lorenzo's fixes:
https://patchwork.ozlabs.org/patch/576450/
which can be found in pci-acpi-v4 branch.

This has been tested on Cavium ThunderX server, JunoR2, HP RX2660 IA64, x86,
Hip05, X-Gene and QEMU-aarch64. Any help in reviewing and testing is very appreciated.

v3 -> v4
- dropped Jiang's fix http://lkml.iu.edu/hypermail/linux/kernel/1601.1/04318.html
- added Lorenzo's fix patch 19/24
- ACPI PCI bus domain number assigning cleanup
- changed resource management, we now claim and reassign resources
- improvements for applying quirks
- dropped Matthew's http://www.spinics.net/lists/linux-pci/msg45950.html dependency
- rebased to 4.5-rc1

v2 -> v3
- fix legacy IRQ assigning and IO ports registration
- remove reference to arch specific companion device for ia64
- move ACPI PCI host controller driver to pci_root.c
- drop generic domain assignment for x86 and ia64 as I am not
  able to run all necessary test variants
- drop patch which cleaned legacy IRQ assignment since it belongs to
  Mathew's series:
  https://patchwork.ozlabs.org/patch/557504/
- extend MCFG quirk code
- rebased to 4.4

v1 -> v2
- moved non-arch specific piece of code to dirver/acpi/ directory
- fixed IO resource handling
- introduced PCI config accessors quirks matching
- moved ACPI_COMPANION_SET to generic code

v1 - https://lkml.org/lkml/2015/10/27/504
v2 - https://lkml.org/lkml/2015/12/16/246
v3 - http://lkml.iu.edu/hypermail/linux/kernel/1601.1/04308.html

Lorenzo Pieralisi (1):
  drivers: pci: add generic code to claim bus resources

Tomasz Nowicki (22):
  x86, pci: Reorder logic of pci_mmconfig_insert() function
  x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code
    out of arch/x86/ directory
  pci, acpi, mcfg: Provide generic implementation of MCFG code
    initialization.
  x86, pci: mmconfig_{32,64}.c code refactoring - remove code
    duplication.
  x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM
    driver.
  XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y
  pci, acpi, mcfg: Provide default RAW ACPI PCI config space accessors.
  arm64, acpi: Use MCFG and empty PCI config space accessors from mcfg.c
    file.
  pci, acpi, ecam: Add flag to indicate whether ECAM region was hot
    added or not.
  x86, pci: Cleanup platform specific MCFG data by using ECAM hot_added
    flag.
  pci, acpi: Move ACPI host bridge device companion assignment to core
    code.
  x86, ia64, pci: Remove ACPI companion device from platform specific
    data.
  pci, acpi: Provide generic way to assign bus domain number.
  x86, ia64: Include acpi_pci_{add|remove}_bus to the default
    pcibios_{add|remove}_bus implementation.
  acpi, mcfg: Implement two calls that might be used to inject/remove
    MCFG region.
  x86, acpi, pci: Use equivalent function from mcfg.c driver.
  acpi, mcfg: Add default PCI config accessors implementation and
    initial support for related quirks.
  pci, of: Move the PCI I/O space management to PCI core code.
  pci, acpi: Support for ACPI based generic PCI host controller init
  pci, acpi: Match PCI config space accessors against platfrom specific
    quirks.
  arm64, pci, acpi: Assign legacy IRQs once device is enable.
  arm64, pci, acpi: Start using ACPI based PCI host bridge driver for
    ARM64.

 arch/arm64/Kconfig                 |   8 ++
 arch/arm64/kernel/pci.c            |  37 ++----
 arch/ia64/hp/common/sba_iommu.c    |   2 +-
 arch/ia64/include/asm/pci.h        |   1 -
 arch/ia64/pci/pci.c                |  26 ----
 arch/ia64/sn/kernel/io_acpi_init.c |   4 +-
 arch/x86/Kconfig                   |   4 +
 arch/x86/include/asm/pci.h         |   3 -
 arch/x86/include/asm/pci_x86.h     |  28 +----
 arch/x86/pci/acpi.c                |  56 ++-------
 arch/x86/pci/common.c              |  10 --
 arch/x86/pci/mmconfig-shared.c     | 250 ++++++-------------------------------
 arch/x86/pci/mmconfig_32.c         |  11 +-
 arch/x86/pci/mmconfig_64.c         |  67 +---------
 arch/x86/pci/numachip.c            |   1 +
 drivers/acpi/Kconfig               |   7 ++
 drivers/acpi/Makefile              |   1 +
 drivers/acpi/mcfg.c                | 201 +++++++++++++++++++++++++++++
 drivers/acpi/pci_root.c            | 134 +++++++++++++++++++-
 drivers/of/address.c               | 116 +----------------
 drivers/pci/Kconfig                |  10 ++
 drivers/pci/Makefile               |   5 +
 drivers/pci/ecam.c                 | 234 ++++++++++++++++++++++++++++++++++
 drivers/pci/pci.c                  | 126 ++++++++++++++++++-
 drivers/pci/probe.c                |   5 +
 drivers/pci/setup-bus.c            |  63 ++++++++++
 drivers/xen/pci.c                  |   7 +-
 include/acpi/acpi_bus.h            |   1 +
 include/asm-generic/vmlinux.lds.h  |   7 ++
 include/linux/acpi.h               |   2 +
 include/linux/ecam.h               |  62 +++++++++
 include/linux/of_address.h         |   9 --
 include/linux/pci-acpi.h           |  19 +++
 include/linux/pci.h                |   6 +
 34 files changed, 962 insertions(+), 561 deletions(-)
 create mode 100644 drivers/acpi/mcfg.c
 create mode 100644 drivers/pci/ecam.c
 create mode 100644 include/linux/ecam.h

-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:39 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:39 +0100
Subject: [PATCH V4 01/23] x86,
 pci: Reorder logic of pci_mmconfig_insert() function
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-2-git-send-email-tn@semihalf.com>

This patch is the first step for MMCONFIG refactoring process.

Code that uses pci_mmcfg_lock will be moved to common file and become
accessible for all architectures. pci_mmconfig_insert() cannot be moved
so easily since it is mixing generic mmconfig code with x86 specific logic
inside of mutual exclusive block guarded by pci_mmcfg_lock.

To get rid of that constraint, we reorder actions as follow:
1. sanity check for mmconfig region presence, if we already have such
region it doesn't make snese to alloc new mmconfig list entry
2. mmconfig entry allocation, no need to lock
3. insertion to iomem_resource has its own lock, no need to wrap it into mutex
4. insertion to mmconfig list can be done as the final step in separate
function (candidate for further refactoring) and needs another mmconfig
lookup to avoid race condition.

Signed-off-by: Tomasz Nowicki <tomasz.nowicki at linaro.org>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 arch/x86/pci/mmconfig-shared.c | 101 +++++++++++++++++++++++------------------
 1 file changed, 58 insertions(+), 43 deletions(-)

diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index dd30b7e..c8bb9b0 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -720,6 +720,38 @@ static int __init pci_mmcfg_late_insert_resources(void)
  */
 late_initcall(pci_mmcfg_late_insert_resources);
 
+static int pci_mmconfig_inject(struct pci_mmcfg_region *cfg)
+{
+	struct pci_mmcfg_region *cfg_conflict;
+	int err = 0;
+
+	mutex_lock(&pci_mmcfg_lock);
+	cfg_conflict = pci_mmconfig_lookup(cfg->segment, cfg->start_bus);
+	if (cfg_conflict) {
+		if (cfg_conflict->end_bus < cfg->end_bus)
+			pr_info(FW_INFO "MMCONFIG for "
+				"domain %04x [bus %02x-%02x] "
+				"only partially covers this bridge\n",
+				cfg_conflict->segment, cfg_conflict->start_bus,
+				cfg_conflict->end_bus);
+		err = -EEXIST;
+		goto out;
+	}
+
+	if (pci_mmcfg_arch_map(cfg)) {
+		pr_warn("fail to map MMCONFIG %pR.\n", &cfg->res);
+		err = -ENOMEM;
+		goto out;
+	} else {
+		list_add_sorted(cfg);
+		pr_info("MMCONFIG at %pR (base %#lx)\n",
+			&cfg->res, (unsigned long)cfg->address);
+	}
+out:
+	mutex_unlock(&pci_mmcfg_lock);
+	return err;
+}
+
 /* Add MMCFG information for host bridges */
 int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
 			phys_addr_t addr)
@@ -734,63 +766,46 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
 	if (start > end)
 		return -EINVAL;
 
-	mutex_lock(&pci_mmcfg_lock);
+	rcu_read_lock();
 	cfg = pci_mmconfig_lookup(seg, start);
-	if (cfg) {
-		if (cfg->end_bus < end)
-			dev_info(dev, FW_INFO
-				 "MMCONFIG for "
-				 "domain %04x [bus %02x-%02x] "
-				 "only partially covers this bridge\n",
-				  cfg->segment, cfg->start_bus, cfg->end_bus);
-		mutex_unlock(&pci_mmcfg_lock);
+	rcu_read_unlock();
+	if (cfg)
 		return -EEXIST;
-	}
 
-	if (!addr) {
-		mutex_unlock(&pci_mmcfg_lock);
+	if (!addr)
 		return -EINVAL;
-	}
 
-	rc = -EBUSY;
 	cfg = pci_mmconfig_alloc(seg, start, end, addr);
-	if (cfg == NULL) {
+	if (!cfg) {
 		dev_warn(dev, "fail to add MMCONFIG (out of memory)\n");
-		rc = -ENOMEM;
-	} else if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
+		return -ENOMEM;
+	}
+
+	rc = -EBUSY;
+	if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
 		dev_warn(dev, FW_BUG "MMCONFIG %pR isn't reserved\n",
 			 &cfg->res);
-	} else {
-		/* Insert resource if it's not in boot stage */
-		if (pci_mmcfg_running_state)
-			tmp = insert_resource_conflict(&iomem_resource,
-						       &cfg->res);
-
-		if (tmp) {
-			dev_warn(dev,
-				 "MMCONFIG %pR conflicts with "
-				 "%s %pR\n",
-				 &cfg->res, tmp->name, tmp);
-		} else if (pci_mmcfg_arch_map(cfg)) {
-			dev_warn(dev, "fail to map MMCONFIG %pR.\n",
-				 &cfg->res);
-		} else {
-			list_add_sorted(cfg);
-			dev_info(dev, "MMCONFIG at %pR (base %#lx)\n",
-				 &cfg->res, (unsigned long)addr);
-			cfg = NULL;
-			rc = 0;
-		}
+		goto error;
 	}
 
-	if (cfg) {
-		if (cfg->res.parent)
-			release_resource(&cfg->res);
-		kfree(cfg);
+	/* Insert resource if it's not in boot stage */
+	if (pci_mmcfg_running_state)
+		tmp = insert_resource_conflict(&iomem_resource, &cfg->res);
+
+	if (tmp) {
+		dev_warn(dev, "MMCONFIG %pR conflicts with %s %pR\n",
+			 &cfg->res, tmp->name, tmp);
+		goto error;
 	}
 
-	mutex_unlock(&pci_mmcfg_lock);
+	rc = pci_mmconfig_inject(cfg);
+	if (!rc)
+		return 0;
 
+error:
+	if (cfg->res.parent)
+		release_resource(&cfg->res);
+	kfree(cfg);
 	return rc;
 }
 
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:41 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:41 +0100
Subject: [PATCH V4 03/23] pci, acpi,
 mcfg: Provide generic implementation of MCFG code initialization.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-4-git-send-email-tn@semihalf.com>

First function acpi_mcfg_check_entry() does not apply any quirks by default.

Last two functions are required by ACPI subsystem to make PCI config
space accessible. Generic code assume to do nothing for early init call but
late init call does as follow:
- parse MCFG table and add regions to ECAM resource list
- map regions
- add regions to iomem_resource

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/acpi/mcfg.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index 5ecef20..fad9917 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -57,3 +57,29 @@ int __init acpi_parse_mcfg(struct acpi_table_header *header)
 
 	return 0;
 }
+
+int __init __weak acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
+					struct acpi_mcfg_allocation *cfg)
+{
+	return 0;
+}
+
+void __init __weak pci_mmcfg_early_init(void)
+{
+
+}
+
+void __init __weak pci_mmcfg_late_init(void)
+{
+	struct pci_mmcfg_region *cfg;
+
+	acpi_table_parse(ACPI_SIG_MCFG, acpi_parse_mcfg);
+
+	if (list_empty(&pci_mmcfg_list))
+		return;
+	if (!pci_mmcfg_arch_init())
+		free_all_mmcfg();
+
+	list_for_each_entry(cfg, &pci_mmcfg_list, list)
+		insert_resource(&iomem_resource, &cfg->res);
+}
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:40 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:40 +0100
Subject: [PATCH V4 02/23] x86, pci,
 acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of
 arch/x86/ directory
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-3-git-send-email-tn@semihalf.com>

ECAM standard and MCFG table are architecture independent and it makes
sense to share common code across all architectures. Both are going to
corresponding files - ecam.c and mcfg.c

While we are here, rename pci_parse_mcfg to acpi_parse_mcfg.
We already have acpi_parse_mcfg prototype which is used nowhere.
At the same time, we need pci_parse_mcfg been global so acpi_parse_mcfg
can be used perfectly here.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 arch/x86/Kconfig               |   3 +
 arch/x86/include/asm/pci_x86.h |  21 -----
 arch/x86/pci/acpi.c            |   1 +
 arch/x86/pci/mmconfig-shared.c | 205 +----------------------------------------
 arch/x86/pci/mmconfig_32.c     |   1 +
 arch/x86/pci/mmconfig_64.c     |   1 +
 arch/x86/pci/numachip.c        |   1 +
 drivers/acpi/Makefile          |   1 +
 drivers/acpi/mcfg.c            |  59 ++++++++++++
 drivers/pci/Kconfig            |   7 ++
 drivers/pci/Makefile           |   5 +
 drivers/pci/ecam.c             | 175 +++++++++++++++++++++++++++++++++++
 drivers/xen/pci.c              |   1 +
 include/linux/acpi.h           |   2 +
 include/linux/ecam.h           |  37 ++++++++
 15 files changed, 299 insertions(+), 221 deletions(-)
 create mode 100644 drivers/acpi/mcfg.c
 create mode 100644 drivers/pci/ecam.c
 create mode 100644 include/linux/ecam.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 330e738..a74acce 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -131,6 +131,7 @@ config X86
 	select HAVE_MIXED_BREAKPOINTS_REGS
 	select HAVE_OPROFILE
 	select HAVE_OPTPROBES
+	select HAVE_PCI_ECAM
 	select HAVE_PCSPKR_PLATFORM
 	select HAVE_PERF_EVENTS
 	select HAVE_PERF_EVENTS_NMI
@@ -2399,6 +2400,7 @@ config PCI_DIRECT
 
 config PCI_MMCONFIG
 	def_bool y
+	select PCI_ECAM
 	depends on X86_32 && PCI && (ACPI || SFI) && (PCI_GOMMCONFIG || PCI_GOANY)
 
 config PCI_OLPC
@@ -2416,6 +2418,7 @@ config PCI_DOMAINS
 
 config PCI_MMCONFIG
 	bool "Support mmconfig PCI config space access"
+	select PCI_ECAM
 	depends on X86_64 && PCI && ACPI
 
 config PCI_CNB20LE_QUIRK
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 46873fb..0281d2d 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -122,33 +122,12 @@ extern int pci_legacy_init(void);
 extern void pcibios_fixup_irqs(void);
 
 /* pci-mmconfig.c */
-
-/* "PCI MMCONFIG %04x [bus %02x-%02x]" */
-#define PCI_MMCFG_RESOURCE_NAME_LEN (22 + 4 + 2 + 2)
-
-struct pci_mmcfg_region {
-	struct list_head list;
-	struct resource res;
-	u64 address;
-	char __iomem *virt;
-	u16 segment;
-	u8 start_bus;
-	u8 end_bus;
-	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
-};
-
 extern int __init pci_mmcfg_arch_init(void);
 extern void __init pci_mmcfg_arch_free(void);
 extern int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg);
 extern void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg);
 extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
 			       phys_addr_t addr);
-extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
-extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
-
-extern struct list_head pci_mmcfg_list;
-
-#define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
 
 /*
  * On AMD Fam10h CPUs, all PCI MMIO configuration space accesses must use
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index e20dbe5..a997d7c 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -5,6 +5,7 @@
 #include <linux/dmi.h>
 #include <linux/slab.h>
 #include <linux/pci-acpi.h>
+#include <linux/ecam.h>
 #include <asm/numa.h>
 #include <asm/pci_x86.h>
 
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index c8bb9b0..ce2c2e4 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -18,6 +18,7 @@
 #include <linux/slab.h>
 #include <linux/mutex.h>
 #include <linux/rculist.h>
+#include <linux/ecam.h>
 #include <asm/e820.h>
 #include <asm/pci_x86.h>
 #include <asm/acpi.h>
@@ -27,103 +28,6 @@
 /* Indicate if the mmcfg resources have been placed into the resource table. */
 static bool pci_mmcfg_running_state;
 static bool pci_mmcfg_arch_init_failed;
-static DEFINE_MUTEX(pci_mmcfg_lock);
-
-LIST_HEAD(pci_mmcfg_list);
-
-static void __init pci_mmconfig_remove(struct pci_mmcfg_region *cfg)
-{
-	if (cfg->res.parent)
-		release_resource(&cfg->res);
-	list_del(&cfg->list);
-	kfree(cfg);
-}
-
-static void __init free_all_mmcfg(void)
-{
-	struct pci_mmcfg_region *cfg, *tmp;
-
-	pci_mmcfg_arch_free();
-	list_for_each_entry_safe(cfg, tmp, &pci_mmcfg_list, list)
-		pci_mmconfig_remove(cfg);
-}
-
-static void list_add_sorted(struct pci_mmcfg_region *new)
-{
-	struct pci_mmcfg_region *cfg;
-
-	/* keep list sorted by segment and starting bus number */
-	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list) {
-		if (cfg->segment > new->segment ||
-		    (cfg->segment == new->segment &&
-		     cfg->start_bus >= new->start_bus)) {
-			list_add_tail_rcu(&new->list, &cfg->list);
-			return;
-		}
-	}
-	list_add_tail_rcu(&new->list, &pci_mmcfg_list);
-}
-
-static struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
-						   int end, u64 addr)
-{
-	struct pci_mmcfg_region *new;
-	struct resource *res;
-
-	if (addr == 0)
-		return NULL;
-
-	new = kzalloc(sizeof(*new), GFP_KERNEL);
-	if (!new)
-		return NULL;
-
-	new->address = addr;
-	new->segment = segment;
-	new->start_bus = start;
-	new->end_bus = end;
-
-	res = &new->res;
-	res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
-	res->end = addr + PCI_MMCFG_BUS_OFFSET(end + 1) - 1;
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
-	snprintf(new->name, PCI_MMCFG_RESOURCE_NAME_LEN,
-		 "PCI MMCONFIG %04x [bus %02x-%02x]", segment, start, end);
-	res->name = new->name;
-
-	return new;
-}
-
-static struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
-							int end, u64 addr)
-{
-	struct pci_mmcfg_region *new;
-
-	new = pci_mmconfig_alloc(segment, start, end, addr);
-	if (new) {
-		mutex_lock(&pci_mmcfg_lock);
-		list_add_sorted(new);
-		mutex_unlock(&pci_mmcfg_lock);
-
-		pr_info(PREFIX
-		       "MMCONFIG for domain %04x [bus %02x-%02x] at %pR "
-		       "(base %#lx)\n",
-		       segment, start, end, &new->res, (unsigned long)addr);
-	}
-
-	return new;
-}
-
-struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus)
-{
-	struct pci_mmcfg_region *cfg;
-
-	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
-		if (cfg->segment == segment &&
-		    cfg->start_bus <= bus && bus <= cfg->end_bus)
-			return cfg;
-
-	return NULL;
-}
 
 static const char *__init pci_mmcfg_e7520(void)
 {
@@ -543,8 +447,8 @@ static void __init pci_mmcfg_reject_broken(int early)
 	}
 }
 
-static int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
-					struct acpi_mcfg_allocation *cfg)
+int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
+				 struct acpi_mcfg_allocation *cfg)
 {
 	int year;
 
@@ -566,50 +470,6 @@ static int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
 	return -EINVAL;
 }
 
-static int __init pci_parse_mcfg(struct acpi_table_header *header)
-{
-	struct acpi_table_mcfg *mcfg;
-	struct acpi_mcfg_allocation *cfg_table, *cfg;
-	unsigned long i;
-	int entries;
-
-	if (!header)
-		return -EINVAL;
-
-	mcfg = (struct acpi_table_mcfg *)header;
-
-	/* how many config structures do we have */
-	free_all_mmcfg();
-	entries = 0;
-	i = header->length - sizeof(struct acpi_table_mcfg);
-	while (i >= sizeof(struct acpi_mcfg_allocation)) {
-		entries++;
-		i -= sizeof(struct acpi_mcfg_allocation);
-	}
-	if (entries == 0) {
-		pr_err(PREFIX "MMCONFIG has no entries\n");
-		return -ENODEV;
-	}
-
-	cfg_table = (struct acpi_mcfg_allocation *) &mcfg[1];
-	for (i = 0; i < entries; i++) {
-		cfg = &cfg_table[i];
-		if (acpi_mcfg_check_entry(mcfg, cfg)) {
-			free_all_mmcfg();
-			return -ENODEV;
-		}
-
-		if (pci_mmconfig_add(cfg->pci_segment, cfg->start_bus_number,
-				   cfg->end_bus_number, cfg->address) == NULL) {
-			pr_warn(PREFIX "no memory for MCFG entries\n");
-			free_all_mmcfg();
-			return -ENOMEM;
-		}
-	}
-
-	return 0;
-}
-
 #ifdef CONFIG_ACPI_APEI
 extern int (*arch_apei_filter_addr)(int (*func)(__u64 start, __u64 size,
 				     void *data), void *data);
@@ -668,7 +528,7 @@ void __init pci_mmcfg_early_init(void)
 		if (pci_mmcfg_check_hostbridge())
 			known_bridge = 1;
 		else
-			acpi_sfi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg);
+			acpi_sfi_table_parse(ACPI_SIG_MCFG, acpi_parse_mcfg);
 		__pci_mmcfg_init(1);
 
 		set_apei_filter();
@@ -686,7 +546,7 @@ void __init pci_mmcfg_late_init(void)
 
 	/* MMCONFIG hasn't been enabled yet, try again */
 	if (pci_probe & PCI_PROBE_MASK & ~PCI_PROBE_MMCONF) {
-		acpi_sfi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg);
+		acpi_sfi_table_parse(ACPI_SIG_MCFG, acpi_parse_mcfg);
 		__pci_mmcfg_init(0);
 	}
 }
@@ -720,38 +580,6 @@ static int __init pci_mmcfg_late_insert_resources(void)
  */
 late_initcall(pci_mmcfg_late_insert_resources);
 
-static int pci_mmconfig_inject(struct pci_mmcfg_region *cfg)
-{
-	struct pci_mmcfg_region *cfg_conflict;
-	int err = 0;
-
-	mutex_lock(&pci_mmcfg_lock);
-	cfg_conflict = pci_mmconfig_lookup(cfg->segment, cfg->start_bus);
-	if (cfg_conflict) {
-		if (cfg_conflict->end_bus < cfg->end_bus)
-			pr_info(FW_INFO "MMCONFIG for "
-				"domain %04x [bus %02x-%02x] "
-				"only partially covers this bridge\n",
-				cfg_conflict->segment, cfg_conflict->start_bus,
-				cfg_conflict->end_bus);
-		err = -EEXIST;
-		goto out;
-	}
-
-	if (pci_mmcfg_arch_map(cfg)) {
-		pr_warn("fail to map MMCONFIG %pR.\n", &cfg->res);
-		err = -ENOMEM;
-		goto out;
-	} else {
-		list_add_sorted(cfg);
-		pr_info("MMCONFIG at %pR (base %#lx)\n",
-			&cfg->res, (unsigned long)cfg->address);
-	}
-out:
-	mutex_unlock(&pci_mmcfg_lock);
-	return err;
-}
-
 /* Add MMCFG information for host bridges */
 int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
 			phys_addr_t addr)
@@ -808,26 +636,3 @@ error:
 	kfree(cfg);
 	return rc;
 }
-
-/* Delete MMCFG information for host bridges */
-int pci_mmconfig_delete(u16 seg, u8 start, u8 end)
-{
-	struct pci_mmcfg_region *cfg;
-
-	mutex_lock(&pci_mmcfg_lock);
-	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
-		if (cfg->segment == seg && cfg->start_bus == start &&
-		    cfg->end_bus == end) {
-			list_del_rcu(&cfg->list);
-			synchronize_rcu();
-			pci_mmcfg_arch_unmap(cfg);
-			if (cfg->res.parent)
-				release_resource(&cfg->res);
-			mutex_unlock(&pci_mmcfg_lock);
-			kfree(cfg);
-			return 0;
-		}
-	mutex_unlock(&pci_mmcfg_lock);
-
-	return -ENOENT;
-}
diff --git a/arch/x86/pci/mmconfig_32.c b/arch/x86/pci/mmconfig_32.c
index 43984bc..246f135 100644
--- a/arch/x86/pci/mmconfig_32.c
+++ b/arch/x86/pci/mmconfig_32.c
@@ -12,6 +12,7 @@
 #include <linux/pci.h>
 #include <linux/init.h>
 #include <linux/rcupdate.h>
+#include <linux/ecam.h>
 #include <asm/e820.h>
 #include <asm/pci_x86.h>
 
diff --git a/arch/x86/pci/mmconfig_64.c b/arch/x86/pci/mmconfig_64.c
index bea5249..b14fcd3 100644
--- a/arch/x86/pci/mmconfig_64.c
+++ b/arch/x86/pci/mmconfig_64.c
@@ -10,6 +10,7 @@
 #include <linux/acpi.h>
 #include <linux/bitmap.h>
 #include <linux/rcupdate.h>
+#include <linux/ecam.h>
 #include <asm/e820.h>
 #include <asm/pci_x86.h>
 
diff --git a/arch/x86/pci/numachip.c b/arch/x86/pci/numachip.c
index 2e565e6..55fbd18 100644
--- a/arch/x86/pci/numachip.c
+++ b/arch/x86/pci/numachip.c
@@ -13,6 +13,7 @@
  *
  */
 
+#include <linux/ecam.h>
 #include <linux/pci.h>
 #include <asm/pci_x86.h>
 
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 7ea903d..e660805 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_ACPI_BUTTON)	+= button.o
 obj-$(CONFIG_ACPI_FAN)		+= fan.o
 obj-$(CONFIG_ACPI_VIDEO)	+= video.o
 obj-$(CONFIG_ACPI_PCI_SLOT)	+= pci_slot.o
+obj-$(CONFIG_PCI_MMCONFIG)	+= mcfg.o
 obj-$(CONFIG_ACPI_PROCESSOR)	+= processor.o
 obj-$(CONFIG_ACPI)		+= container.o
 obj-$(CONFIG_ACPI_THERMAL)	+= thermal.o
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
new file mode 100644
index 0000000..5ecef20
--- /dev/null
+++ b/drivers/acpi/mcfg.c
@@ -0,0 +1,59 @@
+/*
+ * MCFG ACPI table parser.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/acpi.h>
+#include <linux/ecam.h>
+
+#include <asm/pci_x86.h> /* Temp hack before refactoring arch-specific calls */
+
+#define	PREFIX	"MCFG: "
+
+int __init acpi_parse_mcfg(struct acpi_table_header *header)
+{
+	struct acpi_table_mcfg *mcfg;
+	struct acpi_mcfg_allocation *cfg_table, *cfg;
+	unsigned long i;
+	int entries;
+
+	if (!header)
+		return -EINVAL;
+
+	mcfg = (struct acpi_table_mcfg *)header;
+
+	/* how many config structures do we have */
+	free_all_mmcfg();
+	entries = 0;
+	i = header->length - sizeof(struct acpi_table_mcfg);
+	while (i >= sizeof(struct acpi_mcfg_allocation)) {
+		entries++;
+		i -= sizeof(struct acpi_mcfg_allocation);
+	}
+	if (entries == 0) {
+		pr_err(PREFIX "MCFG table has no entries\n");
+		return -ENODEV;
+	}
+
+	cfg_table = (struct acpi_mcfg_allocation *) &mcfg[1];
+	for (i = 0; i < entries; i++) {
+		cfg = &cfg_table[i];
+		if (acpi_mcfg_check_entry(mcfg, cfg)) {
+			free_all_mmcfg();
+			return -ENODEV;
+		}
+
+		if (pci_mmconfig_add(cfg->pci_segment, cfg->start_bus_number,
+				 cfg->end_bus_number, cfg->address) == NULL) {
+			pr_warn(PREFIX "no memory for MCFG entries\n");
+			free_all_mmcfg();
+			return -ENOMEM;
+		}
+	}
+
+	return 0;
+}
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 73de4ef..9950248 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -26,6 +26,13 @@ config PCI_MSI_IRQ_DOMAIN
 	depends on PCI_MSI
 	select GENERIC_MSI_IRQ_DOMAIN
 
+config PCI_ECAM
+	bool "Enhanced Configuration Access Mechanism (ECAM)"
+	depends on PCI && HAVE_PCI_ECAM
+
+config HAVE_PCI_ECAM
+	bool
+
 config PCI_DEBUG
 	bool "PCI Debugging"
 	depends on PCI && DEBUG_KERNEL
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index be3f631..eb574f8 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -42,6 +42,11 @@ obj-$(CONFIG_SPARC_LEON) += setup-irq.o
 obj-$(CONFIG_M68K) += setup-irq.o
 
 #
+# Enhanced Configuration Access Mechanism (ECAM)
+#
+obj-$(CONFIG_PCI_ECAM)	+= ecam.o
+
+#
 # ACPI Related PCI FW Functions
 # ACPI _DSM provided firmware instance and string name
 #
diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
new file mode 100644
index 0000000..d221dba
--- /dev/null
+++ b/drivers/pci/ecam.c
@@ -0,0 +1,175 @@
+/*
+ * Arch agnostic direct PCI config space access via
+ * ECAM (Enhanced Configuration Access Mechanism)
+ *
+ * Per-architecture code takes care of the mappings, region validation and
+ * accesses themselves.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/mutex.h>
+#include <linux/rculist.h>
+#include <linux/ecam.h>
+
+#include <asm/io.h>
+#include <asm/pci_x86.h> /* Temp hack before refactoring arch-specific calls */
+
+#define PREFIX "PCI: "
+
+static DEFINE_MUTEX(pci_mmcfg_lock);
+
+LIST_HEAD(pci_mmcfg_list);
+
+static void __init pci_mmconfig_remove(struct pci_mmcfg_region *cfg)
+{
+	if (cfg->res.parent)
+		release_resource(&cfg->res);
+	list_del(&cfg->list);
+	kfree(cfg);
+}
+
+void __init free_all_mmcfg(void)
+{
+	struct pci_mmcfg_region *cfg, *tmp;
+
+	pci_mmcfg_arch_free();
+	list_for_each_entry_safe(cfg, tmp, &pci_mmcfg_list, list)
+		pci_mmconfig_remove(cfg);
+}
+
+void list_add_sorted(struct pci_mmcfg_region *new)
+{
+	struct pci_mmcfg_region *cfg;
+
+	/* keep list sorted by segment and starting bus number */
+	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list) {
+		if (cfg->segment > new->segment ||
+		    (cfg->segment == new->segment &&
+		     cfg->start_bus >= new->start_bus)) {
+			list_add_tail_rcu(&new->list, &cfg->list);
+			return;
+		}
+	}
+	list_add_tail_rcu(&new->list, &pci_mmcfg_list);
+}
+
+struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
+					    int end, u64 addr)
+{
+	struct pci_mmcfg_region *new;
+	struct resource *res;
+
+	if (addr == 0)
+		return NULL;
+
+	new = kzalloc(sizeof(*new), GFP_KERNEL);
+	if (!new)
+		return NULL;
+
+	new->address = addr;
+	new->segment = segment;
+	new->start_bus = start;
+	new->end_bus = end;
+
+	res = &new->res;
+	res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
+	res->end = addr + PCI_MMCFG_BUS_OFFSET(end + 1) - 1;
+	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	snprintf(new->name, PCI_MMCFG_RESOURCE_NAME_LEN,
+		 "PCI MMCONFIG %04x [bus %02x-%02x]", segment, start, end);
+	res->name = new->name;
+
+	return new;
+}
+
+struct pci_mmcfg_region *pci_mmconfig_add(int segment, int start,
+					  int end, u64 addr)
+{
+	struct pci_mmcfg_region *new;
+
+	new = pci_mmconfig_alloc(segment, start, end, addr);
+	if (new) {
+		mutex_lock(&pci_mmcfg_lock);
+		list_add_sorted(new);
+		mutex_unlock(&pci_mmcfg_lock);
+
+		pr_info(PREFIX
+		       "MMCONFIG for domain %04x [bus %02x-%02x] at %pR "
+		       "(base %#lx)\n",
+		       segment, start, end, &new->res, (unsigned long)addr);
+	}
+
+	return new;
+}
+
+struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus)
+{
+	struct pci_mmcfg_region *cfg;
+
+	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
+		if (cfg->segment == segment &&
+		    cfg->start_bus <= bus && bus <= cfg->end_bus)
+			return cfg;
+
+	return NULL;
+}
+
+/* Delete MMCFG information for host bridges */
+int pci_mmconfig_delete(u16 seg, u8 start, u8 end)
+{
+	struct pci_mmcfg_region *cfg;
+
+	mutex_lock(&pci_mmcfg_lock);
+	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
+		if (cfg->segment == seg && cfg->start_bus == start &&
+		    cfg->end_bus == end) {
+			list_del_rcu(&cfg->list);
+			synchronize_rcu();
+			pci_mmcfg_arch_unmap(cfg);
+			if (cfg->res.parent)
+				release_resource(&cfg->res);
+			mutex_unlock(&pci_mmcfg_lock);
+			kfree(cfg);
+			return 0;
+		}
+	mutex_unlock(&pci_mmcfg_lock);
+
+	return -ENOENT;
+}
+
+int pci_mmconfig_inject(struct pci_mmcfg_region *cfg)
+{
+	struct pci_mmcfg_region *cfg_conflict;
+	int err = 0;
+
+	mutex_lock(&pci_mmcfg_lock);
+	cfg_conflict = pci_mmconfig_lookup(cfg->segment, cfg->start_bus);
+	if (cfg_conflict) {
+		if (cfg_conflict->end_bus < cfg->end_bus)
+			pr_info(FW_INFO "MMCONFIG for "
+				"domain %04x [bus %02x-%02x] "
+				"only partially covers this bridge\n",
+				cfg_conflict->segment, cfg_conflict->start_bus,
+				cfg_conflict->end_bus);
+		err = -EEXIST;
+		goto out;
+	}
+
+	if (pci_mmcfg_arch_map(cfg)) {
+		pr_warn("fail to map MMCONFIG %pR.\n", &cfg->res);
+		err = -ENOMEM;
+		goto out;
+	} else {
+		list_add_sorted(cfg);
+		pr_info("MMCONFIG at %pR (base %#lx)\n",
+			&cfg->res, (unsigned long)cfg->address);
+
+	}
+out:
+	mutex_unlock(&pci_mmcfg_lock);
+	return err;
+}
diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
index 7494dbe..6785ebb 100644
--- a/drivers/xen/pci.c
+++ b/drivers/xen/pci.c
@@ -20,6 +20,7 @@
 #include <linux/pci.h>
 #include <linux/acpi.h>
 #include <linux/pci-acpi.h>
+#include <linux/ecam.h>
 #include <xen/xen.h>
 #include <xen/interface/physdev.h>
 #include <xen/interface/xen.h>
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 06ed7e5..c8130b3 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -237,6 +237,8 @@ int acpi_table_parse_madt(enum acpi_madt_type id,
 			  acpi_tbl_entry_handler handler,
 			  unsigned int max_entries);
 int acpi_parse_mcfg (struct acpi_table_header *header);
+int acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
+			  struct acpi_mcfg_allocation *cfg);
 void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);
 
 /* the following four functions are architecture-dependent */
diff --git a/include/linux/ecam.h b/include/linux/ecam.h
new file mode 100644
index 0000000..dec3b52
--- /dev/null
+++ b/include/linux/ecam.h
@@ -0,0 +1,37 @@
+#ifndef __ECAM_H
+#define __ECAM_H
+#ifdef __KERNEL__
+
+#include <linux/types.h>
+#include <linux/acpi.h>
+
+/* "PCI MMCONFIG %04x [bus %02x-%02x]" */
+#define PCI_MMCFG_RESOURCE_NAME_LEN (22 + 4 + 2 + 2)
+
+struct pci_mmcfg_region {
+	struct list_head list;
+	struct resource res;
+	u64 address;
+	char __iomem *virt;
+	u16 segment;
+	u8 start_bus;
+	u8 end_bus;
+	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
+};
+
+struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
+struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
+						   int end, u64 addr);
+int pci_mmconfig_inject(struct pci_mmcfg_region *cfg);
+struct pci_mmcfg_region *pci_mmconfig_add(int segment, int start,
+						 int end, u64 addr);
+void list_add_sorted(struct pci_mmcfg_region *new);
+void free_all_mmcfg(void);
+int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
+
+extern struct list_head pci_mmcfg_list;
+
+#define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
+
+#endif  /* __KERNEL__ */
+#endif  /* __ECAM_H */
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:42 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:42 +0100
Subject: [PATCH V4 04/23] x86, pci: mmconfig_{32,
 64}.c code refactoring - remove code duplication.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-5-git-send-email-tn@semihalf.com>

mmconfig_64.c version is going to be default implementation for low-level
operation on mmconfig regions. However, now it initializes raw_pci_ext_ops pointer which is specific for
x86 only. Moreover, mmconfig_32.c is doing the same thing at the same time.
So lets move it to mmconfig_shared.c so it becomes common for both and
mmconfig_64.c turns out to be purely arch agnostic.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 arch/x86/include/asm/pci_x86.h |  5 +++++
 arch/x86/pci/mmconfig-shared.c | 10 ++++++++--
 arch/x86/pci/mmconfig_32.c     | 10 ++--------
 arch/x86/pci/mmconfig_64.c     | 11 ++---------
 4 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 0281d2d..26e7dd4 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -129,6 +129,11 @@ extern void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg);
 extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
 			       phys_addr_t addr);
 
+int pci_mmcfg_read(unsigned int seg, unsigned int bus, unsigned int devfn,
+		   int reg, int len, u32 *value);
+int pci_mmcfg_write(unsigned int seg, unsigned int bus, unsigned int devfn,
+		    int reg, int len, u32 value);
+
 /*
  * On AMD Fam10h CPUs, all PCI MMIO configuration space accesses must use
  * %eax.  No other source or target registers may be used.  The following
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index ce2c2e4..980f304 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -29,6 +29,11 @@
 static bool pci_mmcfg_running_state;
 static bool pci_mmcfg_arch_init_failed;
 
+const struct pci_raw_ops pci_mmcfg = {
+	.read =		pci_mmcfg_read,
+	.write =	pci_mmcfg_write,
+};
+
 static const char *__init pci_mmcfg_e7520(void)
 {
 	u32 win;
@@ -512,9 +517,10 @@ static void __init __pci_mmcfg_init(int early)
 		}
 	}
 
-	if (pci_mmcfg_arch_init())
+	if (pci_mmcfg_arch_init()) {
+		raw_pci_ext_ops = &pci_mmcfg;
 		pci_probe = (pci_probe & ~PCI_PROBE_MASK) | PCI_PROBE_MMCONF;
-	else {
+	} else {
 		free_all_mmcfg();
 		pci_mmcfg_arch_init_failed = true;
 	}
diff --git a/arch/x86/pci/mmconfig_32.c b/arch/x86/pci/mmconfig_32.c
index 246f135..2ded56f 100644
--- a/arch/x86/pci/mmconfig_32.c
+++ b/arch/x86/pci/mmconfig_32.c
@@ -50,7 +50,7 @@ static void pci_exp_set_dev_base(unsigned int base, int bus, int devfn)
 	}
 }
 
-static int pci_mmcfg_read(unsigned int seg, unsigned int bus,
+int pci_mmcfg_read(unsigned int seg, unsigned int bus,
 			  unsigned int devfn, int reg, int len, u32 *value)
 {
 	unsigned long flags;
@@ -89,7 +89,7 @@ err:		*value = -1;
 	return 0;
 }
 
-static int pci_mmcfg_write(unsigned int seg, unsigned int bus,
+int pci_mmcfg_write(unsigned int seg, unsigned int bus,
 			   unsigned int devfn, int reg, int len, u32 value)
 {
 	unsigned long flags;
@@ -126,15 +126,9 @@ static int pci_mmcfg_write(unsigned int seg, unsigned int bus,
 	return 0;
 }
 
-const struct pci_raw_ops pci_mmcfg = {
-	.read =		pci_mmcfg_read,
-	.write =	pci_mmcfg_write,
-};
-
 int __init pci_mmcfg_arch_init(void)
 {
 	printk(KERN_INFO "PCI: Using MMCONFIG for extended config space\n");
-	raw_pci_ext_ops = &pci_mmcfg;
 	return 1;
 }
 
diff --git a/arch/x86/pci/mmconfig_64.c b/arch/x86/pci/mmconfig_64.c
index b14fcd3..d0c48eb 100644
--- a/arch/x86/pci/mmconfig_64.c
+++ b/arch/x86/pci/mmconfig_64.c
@@ -25,7 +25,7 @@ static char __iomem *pci_dev_base(unsigned int seg, unsigned int bus, unsigned i
 	return NULL;
 }
 
-static int pci_mmcfg_read(unsigned int seg, unsigned int bus,
+int pci_mmcfg_read(unsigned int seg, unsigned int bus,
 			  unsigned int devfn, int reg, int len, u32 *value)
 {
 	char __iomem *addr;
@@ -59,7 +59,7 @@ err:		*value = -1;
 	return 0;
 }
 
-static int pci_mmcfg_write(unsigned int seg, unsigned int bus,
+int pci_mmcfg_write(unsigned int seg, unsigned int bus,
 			   unsigned int devfn, int reg, int len, u32 value)
 {
 	char __iomem *addr;
@@ -91,11 +91,6 @@ static int pci_mmcfg_write(unsigned int seg, unsigned int bus,
 	return 0;
 }
 
-const struct pci_raw_ops pci_mmcfg = {
-	.read =		pci_mmcfg_read,
-	.write =	pci_mmcfg_write,
-};
-
 static void __iomem *mcfg_ioremap(struct pci_mmcfg_region *cfg)
 {
 	void __iomem *addr;
@@ -121,8 +116,6 @@ int __init pci_mmcfg_arch_init(void)
 			return 0;
 		}
 
-	raw_pci_ext_ops = &pci_mmcfg;
-
 	return 1;
 }
 
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:44 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:44 +0100
Subject: [PATCH V4 06/23] XEN / PCI: Remove the dependence on arch x86 when
 PCI_MMCONFIG=y
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-7-git-send-email-tn@semihalf.com>

In drivers/xen/pci.c, there are arch x86 dependent codes when
CONFIG_PCI_MMCONFIG is enabled, since CONFIG_PCI_MMCONFIG
depends on ACPI, so this will prevent XEN PCI running on other
architectures using ACPI with PCI_MMCONFIG enabled (such as ARM64).

Fortunatly, it can be sloved in a simple way. In drivers/xen/pci.c,
the only x86 dependent code is if ((pci_probe & PCI_PROBE_MMCONF) == 0),
and it's defined in asm/pci_x86.h, the code means that
if the PCI resource is not probed in PCI_PROBE_MMCONF way, just
ingnore the xen mcfg init. Actually this is duplicate, because
if PCI resource is not probed in PCI_PROBE_MMCONF way, the
pci_mmconfig_list will be empty, and the if (list_empty())
after it will do the same job.

So just remove the arch related code and the head file, this
will be no functional change for x86, and also makes xen/pci.c
usable for other architectures.

Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
CC: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
CC: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Cc: Stefano Stabellini <Stefano.Stabellini at eu.citrix.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 drivers/xen/pci.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
index 6785ebb..9a8dbe3 100644
--- a/drivers/xen/pci.c
+++ b/drivers/xen/pci.c
@@ -28,9 +28,6 @@
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include "../pci/pci.h"
-#ifdef CONFIG_PCI_MMCONFIG
-#include <asm/pci_x86.h>
-#endif
 
 static bool __read_mostly pci_seg_supported = true;
 
@@ -222,9 +219,6 @@ static int __init xen_mcfg_late(void)
 	if (!xen_initial_domain())
 		return 0;
 
-	if ((pci_probe & PCI_PROBE_MMCONF) == 0)
-		return 0;
-
 	if (list_empty(&pci_mmcfg_list))
 		return 0;
 
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:45 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:45 +0100
Subject: [PATCH V4 07/23] pci, acpi,
 mcfg: Provide default RAW ACPI PCI config space accessors.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-8-git-send-email-tn@semihalf.com>

Lets keep RAW ACPI PCI config space accessors empty by default,
since we are note sure if they are necessary accross all archs.
Once we sort this out, we can provide generic version or let
architectures to overwrite, like now x86.

Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/acpi/mcfg.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index 745b83e..3e1e7be 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -9,9 +9,30 @@
 
 #include <linux/acpi.h>
 #include <linux/ecam.h>
+#include <linux/pci.h>
 
 #define	PREFIX	"MCFG: "
 
+/*
+ * raw_pci_read/write - raw ACPI PCI config space accessors.
+ *
+ * By defauly (__weak) these accessors are empty and should be overwritten
+ * by architectures which support operations on ACPI PCI_Config regions,
+ * see osl.c file.
+ */
+
+int __weak raw_pci_read(unsigned int domain, unsigned int bus,
+			unsigned int devfn, int reg, int len, u32 *val)
+{
+	return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
+int __weak raw_pci_write(unsigned int domain, unsigned int bus,
+			 unsigned int devfn, int reg, int len, u32 val)
+{
+	return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
 int __init acpi_parse_mcfg(struct acpi_table_header *header)
 {
 	struct acpi_table_mcfg *mcfg;
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:46 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:46 +0100
Subject: [PATCH V4 08/23] arm64,
 acpi: Use MCFG and empty PCI config space accessors from mcfg.c file.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-9-git-send-email-tn@semihalf.com>

We can now enable MCFG driver and its GENERIC_ECAM_MAP feature.
Currently there is no RAW pci config accessor use case for ARM64,
so lets use empty one for now. At the same time we can cleanup
the old implementation of RAW accessors from arch/arm64/kernel/pci.c

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 arch/arm64/Kconfig      |  7 +++++++
 arch/arm64/kernel/pci.c | 15 ---------------
 2 files changed, 7 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc6228..4f45ea4 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -34,6 +34,7 @@ config ARM64
 	select GENERIC_CLOCKEVENTS_BROADCAST
 	select GENERIC_CPU_AUTOPROBE
 	select GENERIC_EARLY_IOREMAP
+	select GENERIC_ECAM_MAP
 	select GENERIC_IDLE_POLL_SETUP
 	select GENERIC_IRQ_PROBE
 	select GENERIC_IRQ_SHOW
@@ -96,6 +97,7 @@ config ARM64
 	select SYSCTL_EXCEPTION_TRACE
 	select HAVE_CONTEXT_TRACKING
 	select HAVE_ARM_SMCCC
+	select HAVE_PCI_ECAM
 	help
 	  ARM 64-bit (AArch64) Linux support.
 
@@ -238,6 +240,11 @@ source "drivers/pci/Kconfig"
 source "drivers/pci/pcie/Kconfig"
 source "drivers/pci/hotplug/Kconfig"
 
+config PCI_MMCONFIG
+	def_bool y
+	select PCI_ECAM
+	depends on ACPI
+
 endmenu
 
 menu "Kernel Features"
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index b3d098b..023b983 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -61,21 +61,6 @@ int pcibios_add_device(struct pci_dev *dev)
 	return 0;
 }
 
-/*
- * raw_pci_read/write - Platform-specific PCI config space access.
- */
-int raw_pci_read(unsigned int domain, unsigned int bus,
-		  unsigned int devfn, int reg, int len, u32 *val)
-{
-	return -ENXIO;
-}
-
-int raw_pci_write(unsigned int domain, unsigned int bus,
-		unsigned int devfn, int reg, int len, u32 val)
-{
-	return -ENXIO;
-}
-
 #ifdef CONFIG_ACPI
 /* Root bridge scanning */
 struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:47 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:47 +0100
Subject: [PATCH V4 09/23] pci, acpi,
 ecam: Add flag to indicate whether ECAM region was hot added or not.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-10-git-send-email-tn@semihalf.com>

There are two ways we can get ECAM (aka MCFG) regions using ACPI,
from MCFG static table and from _CBA method. We cannot remove static
regions, however regions coming from _CBA should be removed while removing
bridge device.

In the light of above we need flag to mark hot added ECAM entries
so that user should use pci_mmconfig_inject while adding regions from
_CBA method.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/pci/ecam.c   | 2 ++
 include/linux/ecam.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
index 7bc75af..fea5700 100644
--- a/drivers/pci/ecam.c
+++ b/drivers/pci/ecam.c
@@ -131,6 +131,7 @@ struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
 	new->segment = segment;
 	new->start_bus = start;
 	new->end_bus = end;
+	new->hot_added = false;
 
 	res = &new->res;
 	res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
@@ -221,6 +222,7 @@ int pci_mmconfig_inject(struct pci_mmcfg_region *cfg)
 		err = -ENOMEM;
 		goto out;
 	} else {
+		cfg->hot_added = true;
 		list_add_sorted(cfg);
 		pr_info("MMCONFIG at %pR (base %#lx)\n",
 			&cfg->res, (unsigned long)cfg->address);
diff --git a/include/linux/ecam.h b/include/linux/ecam.h
index 813acd1..e0f322e 100644
--- a/include/linux/ecam.h
+++ b/include/linux/ecam.h
@@ -17,6 +17,7 @@ struct pci_mmcfg_region {
 	u8 start_bus;
 	u8 end_bus;
 	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
+	bool hot_added;
 };
 
 struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:48 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:48 +0100
Subject: [PATCH V4 10/23] x86,
 pci: Cleanup platform specific MCFG data by using ECAM hot_added flag.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-11-git-send-email-tn@semihalf.com>

Because of two facts:
1. MCFG region has hot_added flag
2. struct acpi_pci_root has topology info (domain, bus number)
we can get rid of arch specific mcfg data from x86 struct pci_root_info.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 arch/x86/pci/acpi.c | 36 ++++++++++++++----------------------
 1 file changed, 14 insertions(+), 22 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index a997d7c..8e89921 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -12,11 +12,6 @@
 struct pci_root_info {
 	struct acpi_pci_root_info common;
 	struct pci_sysdata sd;
-#ifdef	CONFIG_PCI_MMCONFIG
-	bool mcfg_added;
-	u8 start_bus;
-	u8 end_bus;
-#endif
 };
 
 static bool pci_use_crs = true;
@@ -180,16 +175,13 @@ static int check_segment(u16 seg, struct device *dev, char *estr)
 
 static int setup_mcfg_map(struct acpi_pci_root_info *ci)
 {
-	int result, seg;
-	struct pci_root_info *info;
+	int result, seg, start, end;
 	struct acpi_pci_root *root = ci->root;
 	struct device *dev = &ci->bridge->dev;
 
-	info = container_of(ci, struct pci_root_info, common);
-	info->start_bus = (u8)root->secondary.start;
-	info->end_bus = (u8)root->secondary.end;
-	info->mcfg_added = false;
-	seg = info->sd.domain;
+	seg = root->segment;
+	start = root->secondary.start;
+	end = root->secondary.end;
 
 	/* return success if MMCFG is not in use */
 	if (raw_pci_ext_ops && raw_pci_ext_ops != &pci_mmcfg)
@@ -198,13 +190,11 @@ static int setup_mcfg_map(struct acpi_pci_root_info *ci)
 	if (!(pci_probe & PCI_PROBE_MMCONF))
 		return check_segment(seg, dev, "MMCONFIG is disabled,");
 
-	result = pci_mmconfig_insert(dev, seg, info->start_bus, info->end_bus,
-				     root->mcfg_addr);
+	result = pci_mmconfig_insert(dev, seg, start, end, root->mcfg_addr);
 	if (result == 0) {
 		/* enable MMCFG if it hasn't been enabled yet */
 		if (raw_pci_ext_ops == NULL)
 			raw_pci_ext_ops = &pci_mmcfg;
-		info->mcfg_added = true;
 	} else if (result != -EEXIST)
 		return check_segment(seg, dev,
 			 "fail to add MMCONFIG information,");
@@ -214,14 +204,16 @@ static int setup_mcfg_map(struct acpi_pci_root_info *ci)
 
 static void teardown_mcfg_map(struct acpi_pci_root_info *ci)
 {
-	struct pci_root_info *info;
+	struct acpi_pci_root *root = ci->root;
+	struct pci_mmcfg_region *cfg;
 
-	info = container_of(ci, struct pci_root_info, common);
-	if (info->mcfg_added) {
-		pci_mmconfig_delete(info->sd.domain,
-				    info->start_bus, info->end_bus);
-		info->mcfg_added = false;
-	}
+	cfg = pci_mmconfig_lookup(root->segment, root->secondary.start);
+	if (!cfg)
+		return;
+
+	if (cfg->hot_added)
+		pci_mmconfig_delete(root->segment, root->secondary.start,
+				    root->secondary.end);
 }
 #else
 static int setup_mcfg_map(struct acpi_pci_root_info *ci)
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:49 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:49 +0100
Subject: [PATCH V4 11/23] pci,
 acpi: Move ACPI host bridge device companion assignment to core code.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-12-git-send-email-tn@semihalf.com>

Currently we have two platforms (x86 & ia64) capable of PCI ACPI host
bridge initialization. They both use sysdata to pass down parent
device reference and both rely on NULL parent in pci_create_root_bus()
to validate sysdata content.

It looks hacky and prevents us from getting some firmware specific
info for PCI host controller e.g. PCI bus domain number.
However, we overcome that blocker by passing down parent
device via pci_create_root_bus parameter (as the ACPI device type)
and using ACPI_COMPANION_SET in core code for ACPI boot method.
ACPI_COMPANION_SET is safe to run for all cases DT, ACPI and DT&ACPI.

Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/acpi/pci_root.c | 5 ++++-
 drivers/pci/probe.c     | 2 ++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index ae3fe4e..a65c8c2 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -846,7 +846,10 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
 
 	pci_acpi_root_add_resources(info);
 	pci_add_resource(&info->resources, &root->secondary);
-	bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
+
+	/* Root bridge device needs to be sure of parent ACPI type */
+	ACPI_COMPANION_SET(&device->dev, device);
+	bus = pci_create_root_bus(&device->dev, busnum, ops->pci_ops,
 				  sysdata, &info->resources);
 	if (!bus)
 		goto out_release_info;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 6d7ab9b..81dd3a2 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2100,6 +2100,8 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
 	bridge->dev.parent = parent;
 	bridge->dev.release = pci_release_host_bridge_dev;
 	dev_set_name(&bridge->dev, "pci%04x:%02x", pci_domain_nr(b), bus);
+	ACPI_COMPANION_SET(&bridge->dev,
+			   parent ? to_acpi_device_node(parent->fwnode) : NULL);
 	error = pcibios_root_bridge_prepare(bridge);
 	if (error) {
 		kfree(bridge);
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:52 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:52 +0100
Subject: [PATCH V4 14/23] x86,
 ia64: Include acpi_pci_{add|remove}_bus to the default
 pcibios_{add|remove}_bus implementation.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-15-git-send-email-tn@semihalf.com>

x86 and ia64 are the only arches that implement pcibios_{add|remove}_bus hooks
and implement them in the same way. Moreover ARM64 is going to do the same.
So it seems that acpi_pci_{add|remove}_bus is generic enough to be default
option for pcibios_{add|remove}_bus hooks. Also, it is always safe to run
acpi_pci_{add|remove}_bus as they have empty stubs for !ACPI case and
return if ACPI has been switched off in run time.

After all we can remove x86 and ia64 pcibios_{add|remove}_bus
implementation.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 arch/ia64/pci/pci.c   | 10 ----------
 arch/x86/pci/common.c | 10 ----------
 drivers/pci/probe.c   |  3 +++
 3 files changed, 3 insertions(+), 20 deletions(-)

diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 978d6af..be4c9ef 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -358,16 +358,6 @@ void pcibios_fixup_bus(struct pci_bus *b)
 	platform_pci_fixup_bus(b);
 }
 
-void pcibios_add_bus(struct pci_bus *bus)
-{
-	acpi_pci_add_bus(bus);
-}
-
-void pcibios_remove_bus(struct pci_bus *bus)
-{
-	acpi_pci_remove_bus(bus);
-}
-
 void pcibios_set_master (struct pci_dev *dev)
 {
 	/* No special bus mastering setup handling */
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 2879efc..5aa25f1 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -171,16 +171,6 @@ void pcibios_fixup_bus(struct pci_bus *b)
 		pcibios_fixup_device_resources(dev);
 }
 
-void pcibios_add_bus(struct pci_bus *bus)
-{
-	acpi_pci_add_bus(bus);
-}
-
-void pcibios_remove_bus(struct pci_bus *bus)
-{
-	acpi_pci_remove_bus(bus);
-}
-
 /*
  * Only use DMI information to set this if nothing was passed
  * on the kernel command line (which was parsed earlier).
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 81dd3a2..ef22a22 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -12,6 +12,7 @@
 #include <linux/slab.h>
 #include <linux/module.h>
 #include <linux/cpumask.h>
+#include <linux/pci-acpi.h>
 #include <linux/pci-aspm.h>
 #include <linux/aer.h>
 #include <linux/acpi.h>
@@ -2060,10 +2061,12 @@ int __weak pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
 
 void __weak pcibios_add_bus(struct pci_bus *bus)
 {
+	acpi_pci_add_bus(bus);
 }
 
 void __weak pcibios_remove_bus(struct pci_bus *bus)
 {
+	acpi_pci_remove_bus(bus);
 }
 
 struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:53 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:53 +0100
Subject: [PATCH V4 15/23] acpi,
 mcfg: Implement two calls that might be used to inject/remove MCFG
 region.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-16-git-send-email-tn@semihalf.com>

Lets abstract two calls which allow to inject and remove MCFG regions
which may come from DSDT table. These calls will be used for x86 and ARM64
PCI host bridge driver in the later patches.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/acpi/mcfg.c      | 38 ++++++++++++++++++++++++++++++++++++++
 include/linux/pci-acpi.h |  9 +++++++++
 2 files changed, 47 insertions(+)

diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index 3e1e7be..dca4c4e 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -10,6 +10,7 @@
 #include <linux/acpi.h>
 #include <linux/ecam.h>
 #include <linux/pci.h>
+#include <linux/pci-acpi.h>
 
 #define	PREFIX	"MCFG: "
 
@@ -77,6 +78,43 @@ int __init acpi_parse_mcfg(struct acpi_table_header *header)
 	return 0;
 }
 
+int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci)
+{
+	struct pci_mmcfg_region *cfg;
+	struct acpi_pci_root *root;
+	int seg, start, end, err;
+
+	root = ci->root;
+	seg = root->segment;
+	start = root->secondary.start;
+	end = root->secondary.end;
+
+	cfg = pci_mmconfig_lookup(seg, start);
+	if (cfg)
+		return 0;
+
+	cfg = pci_mmconfig_alloc(seg, start, end, root->mcfg_addr);
+	if (!cfg)
+		return -ENOMEM;
+
+	err = pci_mmconfig_inject(cfg);
+	return err;
+}
+
+void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci)
+{
+	struct acpi_pci_root *root = ci->root;
+	struct pci_mmcfg_region *cfg;
+
+	cfg = pci_mmconfig_lookup(root->segment, root->secondary.start);
+	if (!cfg)
+		return;
+
+	if (cfg->hot_added)
+		pci_mmconfig_delete(root->segment, root->secondary.start,
+				    root->secondary.end);
+}
+
 int __init __weak acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
 					struct acpi_mcfg_allocation *cfg)
 {
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index a72e22d..65b91f3 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -80,6 +80,15 @@ extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
 void acpi_pci_add_bus(struct pci_bus *bus);
 void acpi_pci_remove_bus(struct pci_bus *bus);
 
+#ifdef	CONFIG_PCI_MMCONFIG
+int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci);
+void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci);
+#else
+static inline int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci)
+{ return 0; }
+static inline void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci) { }
+#endif
+
 #ifdef	CONFIG_ACPI_PCI_SLOT
 void acpi_pci_slot_init(void);
 void acpi_pci_slot_enumerate(struct pci_bus *bus);
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:55 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:55 +0100
Subject: [PATCH V4 17/23] acpi,
 mcfg: Add default PCI config accessors implementation and initial
 support for related quirks.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-18-git-send-email-tn@semihalf.com>

We use generic accessors from access.c by default. However, we already
know platforms that need special handling while accessing to PCI config
space. These platforms will need different accessors set matched against
platform ID, domain, bus touple. Therefore we are going to add (in future)
DECLARE_ACPI_MCFG_FIXUP which will register platform specific custom
accessors. For now, we let pci_mcfg_get_ops to take acpi_pci_root structure
as an arguments and left some space for quirk matching algorithm.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/acpi/mcfg.c      | 30 ++++++++++++++++++++++++++++++
 include/linux/pci-acpi.h |  8 ++++++++
 2 files changed, 38 insertions(+)

diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index dca4c4e..dfc2d14 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -34,6 +34,36 @@ int __weak raw_pci_write(unsigned int domain, unsigned int bus,
 	return PCIBIOS_DEVICE_NOT_FOUND;
 }
 
+void __iomem *
+pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
+{
+	struct pci_mmcfg_region *cfg;
+
+	cfg = pci_mmconfig_lookup(pci_domain_nr(bus), bus->number);
+	if (cfg && cfg->virt)
+		return cfg->virt +
+			(PCI_MMCFG_BUS_OFFSET(bus->number) | (devfn << 12)) +
+			offset;
+	return NULL;
+}
+
+/* Default generic PCI config accessors */
+static struct pci_ops default_pci_mcfg_ops = {
+	.map_bus = pci_mcfg_dev_base,
+	.read = pci_generic_config_read,
+	.write = pci_generic_config_write,
+};
+
+struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
+{
+	/*
+	 * TODO: Match against platform specific quirks and return
+	 * corresponding PCI config space accessor set.
+	 */
+
+	return &default_pci_mcfg_ops;
+}
+
 int __init acpi_parse_mcfg(struct acpi_table_header *header)
 {
 	struct acpi_table_mcfg *mcfg;
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index 65b91f3..c974586 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -83,10 +83,18 @@ void acpi_pci_remove_bus(struct pci_bus *bus);
 #ifdef	CONFIG_PCI_MMCONFIG
 int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci);
 void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci);
+struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
+void __iomem *
+pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset);
 #else
 static inline int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci)
 { return 0; }
 static inline void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci) { }
+static inline struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
+{ return NULL; }
+static inline void __iomem *
+pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
+{ return NULL; }
 #endif
 
 #ifdef	CONFIG_ACPI_PCI_SLOT
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:57 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:57 +0100
Subject: [PATCH V4 19/23] drivers: pci: add generic code to claim bus resources
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-20-git-send-email-tn@semihalf.com>

From: Lorenzo Pieralisi <Lorenzo.Pieralisi at arm.com>

PCI core code contains a set of functions, eg:

pci_assign_unassigned_bus_resources()

that allow to assign the PCI resources for a given bus after
enumeration.

On systems where the PCI BARs are immutable (ie they must not and can
not be assigned), PCI resources must be claimed in order to be
validated and inserted in the PCI resources tree, but there is no generic
PCI kernel function for that purpose and the resource claiming is
implemented in an arch specific fashion which resulted in arches
implementations that contain duplicated code.

This patch, based on the ia64 resource claiming arch implementation,
implements a set of functions in core PCI code that provides a PCI core
interface for resources claiming for a given PCI bus hierarchy, paving
the way for further resource claiming consolidation across architectures.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Bjorn Helgaas <bhelgaas at google.com>
Cc: Yinghai Lu <yinghai at kernel.org>
---
 drivers/pci/setup-bus.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/pci.h     |  1 +
 2 files changed, 64 insertions(+)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 7796d0a..c959398 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1424,6 +1424,69 @@ void pci_bus_assign_resources(const struct pci_bus *bus)
 }
 EXPORT_SYMBOL(pci_bus_assign_resources);
 
+static void pci_claim_device_resources(struct pci_dev *dev)
+{
+	int i;
+
+	for (i = 0; i < PCI_BRIDGE_RESOURCES; i++) {
+		struct resource *r = &dev->resource[i];
+
+		if (!r->flags || r->parent)
+			continue;
+
+		pci_claim_resource(dev, i);
+	}
+}
+
+static void pci_claim_bridge_resources(struct pci_dev *dev)
+{
+	int i;
+
+	for (i = PCI_BRIDGE_RESOURCES; i < PCI_NUM_RESOURCES; i++) {
+		struct resource *r = &dev->resource[i];
+
+		if (!r->flags || r->parent)
+			continue;
+
+		pci_claim_bridge_resource(dev, i);
+	}
+}
+
+static void pci_bus_allocate_dev_resources(struct pci_bus *b)
+{
+	struct pci_dev *dev;
+	struct pci_bus *child;
+
+	list_for_each_entry(dev, &b->devices, bus_list) {
+		pci_claim_device_resources(dev);
+
+		child = dev->subordinate;
+		if (child)
+			pci_bus_allocate_dev_resources(child);
+	}
+}
+
+static void pci_bus_allocate_resources(struct pci_bus *b)
+{
+	struct pci_bus *child;
+
+	/* Depth-First Search on bus tree */
+	if (b->self) {
+		pci_read_bridge_bases(b);
+		pci_claim_bridge_resources(b->self);
+	}
+
+	list_for_each_entry(child, &b->children, node)
+		pci_bus_allocate_resources(child);
+}
+
+void pci_bus_claim_resources(struct pci_bus *b)
+{
+	pci_bus_allocate_resources(b);
+	pci_bus_allocate_dev_resources(b);
+}
+EXPORT_SYMBOL(pci_bus_claim_resources);
+
 static void __pci_bridge_assign_resources(const struct pci_dev *bridge,
 					  struct list_head *add_head,
 					  struct list_head *fail_head)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index dac677c..6faf994 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1119,6 +1119,7 @@ ssize_t pci_write_vpd(struct pci_dev *dev, loff_t pos, size_t count, const void
 /* Helper functions for low-level code (drivers/pci/setup-[bus,res].c) */
 resource_size_t pcibios_retrieve_fw_addr(struct pci_dev *dev, int idx);
 void pci_bus_assign_resources(const struct pci_bus *bus);
+void pci_bus_claim_resources(struct pci_bus *bus);
 void pci_bus_size_bridges(struct pci_bus *bus);
 int pci_claim_resource(struct pci_dev *, int);
 int pci_claim_bridge_resource(struct pci_dev *bridge, int i);
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:56 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:56 +0100
Subject: [PATCH V4 18/23] pci,
 of: Move the PCI I/O space management to PCI core code.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-19-git-send-email-tn@semihalf.com>

No functional changes in this patch.

PCI I/O space mapping code does not depend on OF, therefore it can be
moved to PCI core code. This way we will be able to use it
e.g. in ACPI PCI code.

Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
CC: Arnd Bergmann <arnd at arndb.de>
CC: Liviu Dudau <Liviu.Dudau at arm.com>
CC: Lorenzo Pieralisi <Lorenzo.Pieralisi at arm.com>
---
 drivers/of/address.c       | 116 +--------------------------------------------
 drivers/pci/pci.c          | 115 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of_address.h |   9 ----
 include/linux/pci.h        |   5 ++
 4 files changed, 121 insertions(+), 124 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 91a469d..0a553c0 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -4,6 +4,7 @@
 #include <linux/ioport.h>
 #include <linux/module.h>
 #include <linux/of_address.h>
+#include <linux/pci.h>
 #include <linux/pci_regs.h>
 #include <linux/sizes.h>
 #include <linux/slab.h>
@@ -673,121 +674,6 @@ const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
 }
 EXPORT_SYMBOL(of_get_address);
 
-#ifdef PCI_IOBASE
-struct io_range {
-	struct list_head list;
-	phys_addr_t start;
-	resource_size_t size;
-};
-
-static LIST_HEAD(io_range_list);
-static DEFINE_SPINLOCK(io_range_lock);
-#endif
-
-/*
- * Record the PCI IO range (expressed as CPU physical address + size).
- * Return a negative value if an error has occured, zero otherwise
- */
-int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
-{
-	int err = 0;
-
-#ifdef PCI_IOBASE
-	struct io_range *range;
-	resource_size_t allocated_size = 0;
-
-	/* check if the range hasn't been previously recorded */
-	spin_lock(&io_range_lock);
-	list_for_each_entry(range, &io_range_list, list) {
-		if (addr >= range->start && addr + size <= range->start + size) {
-			/* range already registered, bail out */
-			goto end_register;
-		}
-		allocated_size += range->size;
-	}
-
-	/* range not registed yet, check for available space */
-	if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
-		/* if it's too big check if 64K space can be reserved */
-		if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
-			err = -E2BIG;
-			goto end_register;
-		}
-
-		size = SZ_64K;
-		pr_warn("Requested IO range too big, new size set to 64K\n");
-	}
-
-	/* add the range to the list */
-	range = kzalloc(sizeof(*range), GFP_ATOMIC);
-	if (!range) {
-		err = -ENOMEM;
-		goto end_register;
-	}
-
-	range->start = addr;
-	range->size = size;
-
-	list_add_tail(&range->list, &io_range_list);
-
-end_register:
-	spin_unlock(&io_range_lock);
-#endif
-
-	return err;
-}
-
-phys_addr_t pci_pio_to_address(unsigned long pio)
-{
-	phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
-
-#ifdef PCI_IOBASE
-	struct io_range *range;
-	resource_size_t allocated_size = 0;
-
-	if (pio > IO_SPACE_LIMIT)
-		return address;
-
-	spin_lock(&io_range_lock);
-	list_for_each_entry(range, &io_range_list, list) {
-		if (pio >= allocated_size && pio < allocated_size + range->size) {
-			address = range->start + pio - allocated_size;
-			break;
-		}
-		allocated_size += range->size;
-	}
-	spin_unlock(&io_range_lock);
-#endif
-
-	return address;
-}
-
-unsigned long __weak pci_address_to_pio(phys_addr_t address)
-{
-#ifdef PCI_IOBASE
-	struct io_range *res;
-	resource_size_t offset = 0;
-	unsigned long addr = -1;
-
-	spin_lock(&io_range_lock);
-	list_for_each_entry(res, &io_range_list, list) {
-		if (address >= res->start && address < res->start + res->size) {
-			addr = address - res->start + offset;
-			break;
-		}
-		offset += res->size;
-	}
-	spin_unlock(&io_range_lock);
-
-	return addr;
-#else
-	if (address > IO_SPACE_LIMIT)
-		return (unsigned long)-1;
-
-	return (unsigned long) address;
-#endif
-}
-
 static int __of_address_to_resource(struct device_node *dev,
 		const __be32 *addrp, u64 size, unsigned int flags,
 		const char *name, struct resource *r)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d6c768e..3a516c0 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3023,6 +3023,121 @@ int pci_request_regions_exclusive(struct pci_dev *pdev, const char *res_name)
 }
 EXPORT_SYMBOL(pci_request_regions_exclusive);
 
+#ifdef PCI_IOBASE
+struct io_range {
+	struct list_head list;
+	phys_addr_t start;
+	resource_size_t size;
+};
+
+static LIST_HEAD(io_range_list);
+static DEFINE_SPINLOCK(io_range_lock);
+#endif
+
+/*
+ * Record the PCI IO range (expressed as CPU physical address + size).
+ * Return a negative value if an error has occured, zero otherwise
+ */
+int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
+{
+	int err = 0;
+
+#ifdef PCI_IOBASE
+	struct io_range *range;
+	resource_size_t allocated_size = 0;
+
+	/* check if the range hasn't been previously recorded */
+	spin_lock(&io_range_lock);
+	list_for_each_entry(range, &io_range_list, list) {
+		if (addr >= range->start && addr + size <= range->start + size) {
+			/* range already registered, bail out */
+			goto end_register;
+		}
+		allocated_size += range->size;
+	}
+
+	/* range not registed yet, check for available space */
+	if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
+		/* if it's too big check if 64K space can be reserved */
+		if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
+			err = -E2BIG;
+			goto end_register;
+		}
+
+		size = SZ_64K;
+		pr_warn("Requested IO range too big, new size set to 64K\n");
+	}
+
+	/* add the range to the list */
+	range = kzalloc(sizeof(*range), GFP_ATOMIC);
+	if (!range) {
+		err = -ENOMEM;
+		goto end_register;
+	}
+
+	range->start = addr;
+	range->size = size;
+
+	list_add_tail(&range->list, &io_range_list);
+
+end_register:
+	spin_unlock(&io_range_lock);
+#endif
+
+	return err;
+}
+
+phys_addr_t pci_pio_to_address(unsigned long pio)
+{
+	phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
+
+#ifdef PCI_IOBASE
+	struct io_range *range;
+	resource_size_t allocated_size = 0;
+
+	if (pio > IO_SPACE_LIMIT)
+		return address;
+
+	spin_lock(&io_range_lock);
+	list_for_each_entry(range, &io_range_list, list) {
+		if (pio >= allocated_size && pio < allocated_size + range->size) {
+			address = range->start + pio - allocated_size;
+			break;
+		}
+		allocated_size += range->size;
+	}
+	spin_unlock(&io_range_lock);
+#endif
+
+	return address;
+}
+
+unsigned long __weak pci_address_to_pio(phys_addr_t address)
+{
+#ifdef PCI_IOBASE
+	struct io_range *res;
+	resource_size_t offset = 0;
+	unsigned long addr = -1;
+
+	spin_lock(&io_range_lock);
+	list_for_each_entry(res, &io_range_list, list) {
+		if (address >= res->start && address < res->start + res->size) {
+			addr = address - res->start + offset;
+			break;
+		}
+		offset += res->size;
+	}
+	spin_unlock(&io_range_lock);
+
+	return addr;
+#else
+	if (address > IO_SPACE_LIMIT)
+		return (unsigned long)-1;
+
+	return (unsigned long) address;
+#endif
+}
+
 /**
  *	pci_remap_iospace - Remap the memory mapped I/O space
  *	@res: Resource describing the I/O space
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 01c0a55..3786473 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -47,10 +47,6 @@ void __iomem *of_io_request_and_map(struct device_node *device,
 extern const __be32 *of_get_address(struct device_node *dev, int index,
 			   u64 *size, unsigned int *flags);
 
-extern int pci_register_io_range(phys_addr_t addr, resource_size_t size);
-extern unsigned long pci_address_to_pio(phys_addr_t addr);
-extern phys_addr_t pci_pio_to_address(unsigned long pio);
-
 extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
 			struct device_node *node);
 extern struct of_pci_range *of_pci_range_parser_one(
@@ -86,11 +82,6 @@ static inline const __be32 *of_get_address(struct device_node *dev, int index,
 	return NULL;
 }
 
-static inline phys_addr_t pci_pio_to_address(unsigned long pio)
-{
-	return 0;
-}
-
 static inline int of_pci_range_parser_init(struct of_pci_range_parser *parser,
 			struct device_node *node)
 {
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 27df4a6..dac677c 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1168,6 +1168,9 @@ int __must_check pci_bus_alloc_resource(struct pci_bus *bus,
 			void *alignf_data);
 
 
+int pci_register_io_range(phys_addr_t addr, resource_size_t size);
+unsigned long pci_address_to_pio(phys_addr_t addr);
+phys_addr_t pci_pio_to_address(unsigned long pio);
 int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
 
 static inline pci_bus_addr_t pci_bus_address(struct pci_dev *pdev, int bar)
@@ -1488,6 +1491,8 @@ static inline int pci_request_regions(struct pci_dev *dev, const char *res_name)
 { return -EIO; }
 static inline void pci_release_regions(struct pci_dev *dev) { }
 
+static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
+
 static inline void pci_block_cfg_access(struct pci_dev *dev) { }
 static inline int pci_block_cfg_access_in_atomic(struct pci_dev *dev)
 { return 0; }
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:43 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:43 +0100
Subject: [PATCH V4 05/23] x86, pci,
 ecam: mmconfig_64.c becomes default implementation for ECAM driver.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-6-git-send-email-tn@semihalf.com>

mmconfig_64.c functions responsible for ECAM regions mapping
are generic enough to use them for other architectures, GENERIC_ECAM_MAP
should be selected in that case (like 64bit x86). Some hosts may need
arch-specific mapping logic, thus they are obligated to provide own
implementation and resign GENERIC_ECAM_MAP feature (like 32bit x86 does).

Note, we leaved x86-specific PCI config accessors in the corresponding files.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 arch/x86/Kconfig               |  1 +
 arch/x86/include/asm/pci_x86.h |  4 ---
 arch/x86/pci/mmconfig_64.c     | 55 ---------------------------------------
 drivers/acpi/mcfg.c            |  2 --
 drivers/pci/Kconfig            |  3 +++
 drivers/pci/ecam.c             | 59 +++++++++++++++++++++++++++++++++++++++++-
 include/linux/ecam.h           |  6 +++++
 7 files changed, 68 insertions(+), 62 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a74acce..15674b9 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -65,6 +65,7 @@ config X86
 	select GENERIC_CMOS_UPDATE
 	select GENERIC_CPU_AUTOPROBE
 	select GENERIC_EARLY_IOREMAP
+	select GENERIC_ECAM_MAP			if X86_64
 	select GENERIC_FIND_FIRST_BIT
 	select GENERIC_IOMAP
 	select GENERIC_IRQ_PROBE
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 26e7dd4..6e14518 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -122,10 +122,6 @@ extern int pci_legacy_init(void);
 extern void pcibios_fixup_irqs(void);
 
 /* pci-mmconfig.c */
-extern int __init pci_mmcfg_arch_init(void);
-extern void __init pci_mmcfg_arch_free(void);
-extern int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg);
-extern void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg);
 extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
 			       phys_addr_t addr);
 
diff --git a/arch/x86/pci/mmconfig_64.c b/arch/x86/pci/mmconfig_64.c
index d0c48eb..fd356cc 100644
--- a/arch/x86/pci/mmconfig_64.c
+++ b/arch/x86/pci/mmconfig_64.c
@@ -90,58 +90,3 @@ int pci_mmcfg_write(unsigned int seg, unsigned int bus,
 
 	return 0;
 }
-
-static void __iomem *mcfg_ioremap(struct pci_mmcfg_region *cfg)
-{
-	void __iomem *addr;
-	u64 start, size;
-	int num_buses;
-
-	start = cfg->address + PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
-	num_buses = cfg->end_bus - cfg->start_bus + 1;
-	size = PCI_MMCFG_BUS_OFFSET(num_buses);
-	addr = ioremap_nocache(start, size);
-	if (addr)
-		addr -= PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
-	return addr;
-}
-
-int __init pci_mmcfg_arch_init(void)
-{
-	struct pci_mmcfg_region *cfg;
-
-	list_for_each_entry(cfg, &pci_mmcfg_list, list)
-		if (pci_mmcfg_arch_map(cfg)) {
-			pci_mmcfg_arch_free();
-			return 0;
-		}
-
-	return 1;
-}
-
-void __init pci_mmcfg_arch_free(void)
-{
-	struct pci_mmcfg_region *cfg;
-
-	list_for_each_entry(cfg, &pci_mmcfg_list, list)
-		pci_mmcfg_arch_unmap(cfg);
-}
-
-int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg)
-{
-	cfg->virt = mcfg_ioremap(cfg);
-	if (!cfg->virt) {
-		pr_err(PREFIX "can't map MMCONFIG at %pR\n", &cfg->res);
-		return -ENOMEM;
-	}
-
-	return 0;
-}
-
-void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg)
-{
-	if (cfg && cfg->virt) {
-		iounmap(cfg->virt + PCI_MMCFG_BUS_OFFSET(cfg->start_bus));
-		cfg->virt = NULL;
-	}
-}
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index fad9917..745b83e 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -10,8 +10,6 @@
 #include <linux/acpi.h>
 #include <linux/ecam.h>
 
-#include <asm/pci_x86.h> /* Temp hack before refactoring arch-specific calls */
-
 #define	PREFIX	"MCFG: "
 
 int __init acpi_parse_mcfg(struct acpi_table_header *header)
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 9950248..dd26f39 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -33,6 +33,9 @@ config PCI_ECAM
 config HAVE_PCI_ECAM
 	bool
 
+config GENERIC_ECAM_MAP
+	bool
+
 config PCI_DEBUG
 	bool "PCI Debugging"
 	depends on PCI && DEBUG_KERNEL
diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
index d221dba..7bc75af 100644
--- a/drivers/pci/ecam.c
+++ b/drivers/pci/ecam.c
@@ -16,7 +16,6 @@
 #include <linux/ecam.h>
 
 #include <asm/io.h>
-#include <asm/pci_x86.h> /* Temp hack before refactoring arch-specific calls */
 
 #define PREFIX "PCI: "
 
@@ -24,6 +23,64 @@ static DEFINE_MUTEX(pci_mmcfg_lock);
 
 LIST_HEAD(pci_mmcfg_list);
 
+#ifdef CONFIG_GENERIC_ECAM_MAP
+
+static void __iomem *mcfg_ioremap(struct pci_mmcfg_region *cfg)
+{
+	void __iomem *addr;
+	u64 start, size;
+	int num_buses;
+
+	start = cfg->address + PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
+	num_buses = cfg->end_bus - cfg->start_bus + 1;
+	size = PCI_MMCFG_BUS_OFFSET(num_buses);
+	addr = ioremap_nocache(start, size);
+	if (addr)
+		addr -= PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
+	return addr;
+}
+
+int __init pci_mmcfg_arch_init(void)
+{
+	struct pci_mmcfg_region *cfg;
+
+	list_for_each_entry(cfg, &pci_mmcfg_list, list)
+		if (pci_mmcfg_arch_map(cfg)) {
+			pci_mmcfg_arch_free();
+			return 0;
+		}
+
+	return 1;
+}
+
+void __init pci_mmcfg_arch_free(void)
+{
+	struct pci_mmcfg_region *cfg;
+
+	list_for_each_entry(cfg, &pci_mmcfg_list, list)
+		pci_mmcfg_arch_unmap(cfg);
+}
+
+int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg)
+{
+	cfg->virt = mcfg_ioremap(cfg);
+	if (!cfg->virt) {
+		pr_err(PREFIX "can't map MMCONFIG at %pR\n", &cfg->res);
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg)
+{
+	if (cfg && cfg->virt) {
+		iounmap(cfg->virt + PCI_MMCFG_BUS_OFFSET(cfg->start_bus));
+		cfg->virt = NULL;
+	}
+}
+#endif /* CONFIG_GENERIC_ECAM_MAP */
+
 static void __init pci_mmconfig_remove(struct pci_mmcfg_region *cfg)
 {
 	if (cfg->res.parent)
diff --git a/include/linux/ecam.h b/include/linux/ecam.h
index dec3b52..813acd1 100644
--- a/include/linux/ecam.h
+++ b/include/linux/ecam.h
@@ -29,6 +29,12 @@ void list_add_sorted(struct pci_mmcfg_region *new);
 void free_all_mmcfg(void);
 int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
 
+/* Arch specific calls */
+int pci_mmcfg_arch_init(void);
+void pci_mmcfg_arch_free(void);
+int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg);
+void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg);
+
 extern struct list_head pci_mmcfg_list;
 
 #define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:50 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:50 +0100
Subject: [PATCH V4 12/23] x86, ia64,
 pci: Remove ACPI companion device from platform specific data.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-13-git-send-email-tn@semihalf.com>

Since PCI core code is setting ACPI companion device for us now,
platform specific ACPI companion device setting turns out to be dead now.
Therefore we can get rid of it, including related companion reference
from PCI sysdata structure.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 arch/ia64/hp/common/sba_iommu.c    |  2 +-
 arch/ia64/include/asm/pci.h        |  1 -
 arch/ia64/pci/pci.c                | 16 ----------------
 arch/ia64/sn/kernel/io_acpi_init.c |  4 ++--
 arch/x86/include/asm/pci.h         |  3 ---
 arch/x86/pci/acpi.c                | 17 -----------------
 6 files changed, 3 insertions(+), 40 deletions(-)

diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index a6d6190..78e4444 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -1981,7 +1981,7 @@ sba_connect_bus(struct pci_bus *bus)
 	if (PCI_CONTROLLER(bus)->iommu)
 		return;
 
-	handle = acpi_device_handle(PCI_CONTROLLER(bus)->companion);
+	handle = acpi_device_handle(ACPI_COMPANION(bus->bridge));
 	if (!handle)
 		return;
 
diff --git a/arch/ia64/include/asm/pci.h b/arch/ia64/include/asm/pci.h
index 07039d1..5050748 100644
--- a/arch/ia64/include/asm/pci.h
+++ b/arch/ia64/include/asm/pci.h
@@ -65,7 +65,6 @@ extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
 #define pci_legacy_write platform_pci_legacy_write
 
 struct pci_controller {
-	struct acpi_device *companion;
 	void *iommu;
 	int segment;
 	int node;		/* nearest node with memory or NUMA_NO_NODE for global allocation */
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 8f6ac2f..978d6af 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -301,28 +301,12 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
 	}
 
 	info->controller.segment = root->segment;
-	info->controller.companion = device;
 	info->controller.node = acpi_get_node(device->handle);
 	INIT_LIST_HEAD(&info->io_resources);
 	return acpi_pci_root_create(root, &pci_acpi_root_ops,
 				    &info->common, &info->controller);
 }
 
-int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
-{
-	/*
-	 * We pass NULL as parent to pci_create_root_bus(), so if it is not NULL
-	 * here, pci_create_root_bus() has been called by someone else and
-	 * sysdata is likely to be different from what we expect.  Let it go in
-	 * that case.
-	 */
-	if (!bridge->dev.parent) {
-		struct pci_controller *controller = bridge->bus->sysdata;
-		ACPI_COMPANION_SET(&bridge->dev, controller->companion);
-	}
-	return 0;
-}
-
 void pcibios_fixup_device_resources(struct pci_dev *dev)
 {
 	int idx;
diff --git a/arch/ia64/sn/kernel/io_acpi_init.c b/arch/ia64/sn/kernel/io_acpi_init.c
index 0640739..bcfddc2 100644
--- a/arch/ia64/sn/kernel/io_acpi_init.c
+++ b/arch/ia64/sn/kernel/io_acpi_init.c
@@ -132,7 +132,7 @@ sn_get_bussoft_ptr(struct pci_bus *bus)
 	struct acpi_resource_vendor_typed *vendor;
 
 
-	handle = acpi_device_handle(PCI_CONTROLLER(bus)->companion);
+	handle = acpi_device_handle(ACPI_COMPANION(bus->bridge));
 	status = acpi_get_vendor_resource(handle, METHOD_NAME__CRS,
 					  &sn_uuid, &buffer);
 	if (ACPI_FAILURE(status)) {
@@ -360,7 +360,7 @@ sn_acpi_get_pcidev_info(struct pci_dev *dev, struct pcidev_info **pcidev_info,
 	acpi_status status;
 	struct acpi_buffer name_buffer = { ACPI_ALLOCATE_BUFFER, NULL };
 
-	rootbus_handle = acpi_device_handle(PCI_CONTROLLER(dev)->companion);
+	rootbus_handle = acpi_device_handle(ACPI_COMPANION(dev->bus->bridge));
         status = acpi_evaluate_integer(rootbus_handle, METHOD_NAME__SEG, NULL,
                                        &segment);
         if (ACPI_SUCCESS(status)) {
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 4625943..a98c022 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -14,9 +14,6 @@
 struct pci_sysdata {
 	int		domain;		/* PCI domain */
 	int		node;		/* NUMA node */
-#ifdef CONFIG_ACPI
-	struct acpi_device *companion;	/* ACPI companion device */
-#endif
 #ifdef CONFIG_X86_64
 	void		*iommu;		/* IOMMU private data */
 #endif
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 8e89921..d5086d1 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -341,7 +341,6 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
 		struct pci_sysdata sd = {
 			.domain = domain,
 			.node = node,
-			.companion = root->device
 		};
 
 		memcpy(bus->sysdata, &sd, sizeof(sd));
@@ -356,7 +355,6 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
 		else {
 			info->sd.domain = domain;
 			info->sd.node = node;
-			info->sd.companion = root->device;
 			bus = acpi_pci_root_create(root, &acpi_pci_root_ops,
 						   &info->common, &info->sd);
 		}
@@ -374,21 +372,6 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
 	return bus;
 }
 
-int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
-{
-	/*
-	 * We pass NULL as parent to pci_create_root_bus(), so if it is not NULL
-	 * here, pci_create_root_bus() has been called by someone else and
-	 * sysdata is likely to be different from what we expect.  Let it go in
-	 * that case.
-	 */
-	if (!bridge->dev.parent) {
-		struct pci_sysdata *sd = bridge->bus->sysdata;
-		ACPI_COMPANION_SET(&bridge->dev, sd->companion);
-	}
-	return 0;
-}
-
 int __init pci_acpi_init(void)
 {
 	struct pci_dev *dev = NULL;
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:51 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:51 +0100
Subject: [PATCH V4 13/23] pci,
 acpi: Provide generic way to assign bus domain number.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-14-git-send-email-tn@semihalf.com>

As we now have valid PCI host bridge device reference we can
introduce code that is going to find its bus domain number using
ACPI _SEG method.

Note that _SEG method is optional, therefore _SEG absence means
that all PCI buses belong to domain 0.

While at it, for the sake of code clarity we put ACPI and DT domain
assign methods into the corresponding helpers.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Reviewed-by: Liviu Dudau <Liviu.Dudau at arm.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/acpi/pci_root.c  | 18 ++++++++++++++++++
 drivers/pci/pci.c        | 11 +++++++++--
 include/linux/pci-acpi.h |  2 ++
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index a65c8c2..cc2c73a 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -419,6 +419,24 @@ out:
 }
 EXPORT_SYMBOL(acpi_pci_osc_control_set);
 
+int acpi_pci_bus_domain_nr(struct device *parent)
+{
+	struct acpi_device *acpi_dev = to_acpi_device(parent);
+	unsigned long long segment = 0;
+	acpi_status status;
+
+	/*
+	 * If _SEG method does not exist, following ACPI spec (6.5.6)
+	 * all PCI buses belong to domain 0.
+	 */
+	status = acpi_evaluate_integer(acpi_dev->handle, METHOD_NAME__SEG, NULL,
+				       &segment);
+	if (ACPI_FAILURE(status) && status != AE_NOT_FOUND)
+		dev_err(&acpi_dev->dev, "can't evaluate _SEG\n");
+
+	return segment;
+}
+
 static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm)
 {
 	u32 support, control, requested;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 602eb42..d6c768e 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -19,6 +19,7 @@
 #include <linux/spinlock.h>
 #include <linux/string.h>
 #include <linux/log2.h>
+#include <linux/pci-acpi.h>
 #include <linux/pci-aspm.h>
 #include <linux/pm_wakeup.h>
 #include <linux/interrupt.h>
@@ -4769,7 +4770,7 @@ int pci_get_new_domain_nr(void)
 }
 
 #ifdef CONFIG_PCI_DOMAINS_GENERIC
-void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
+static int of_pci_bus_domain_nr(struct device *parent)
 {
 	static int use_dt_domains = -1;
 	int domain = of_get_pci_domain_nr(parent->of_node);
@@ -4811,7 +4812,13 @@ void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
 		domain = -1;
 	}
 
-	bus->domain_nr = domain;
+	return domain;
+}
+
+void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
+{
+	bus->domain_nr = acpi_disabled ? of_pci_bus_domain_nr(parent) :
+					 acpi_pci_bus_domain_nr(parent);
 }
 #endif
 #endif
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index 89ab057..a72e22d 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -22,6 +22,7 @@ static inline acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
 {
 	return acpi_remove_pm_notifier(dev);
 }
+extern int acpi_pci_bus_domain_nr(struct device *parent);
 extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
 
 static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
@@ -109,6 +110,7 @@ extern const u8 pci_acpi_dsm_uuid[];
 #else	/* CONFIG_ACPI */
 static inline void acpi_pci_add_bus(struct pci_bus *bus) { }
 static inline void acpi_pci_remove_bus(struct pci_bus *bus) { }
+static inline int acpi_pci_bus_domain_nr(struct device *parent) { return -1; }
 #endif	/* CONFIG_ACPI */
 
 #ifdef CONFIG_ACPI_APEI
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:54 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:54 +0100
Subject: [PATCH V4 16/23] x86, acpi,
 pci: Use equivalent function from mcfg.c driver.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-17-git-send-email-tn@semihalf.com>

Since mcfg.c driver provides the same function lets use it and remove
code duplication.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 arch/x86/pci/acpi.c | 20 +-------------------
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index d5086d1..b4e72b5 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -201,29 +201,11 @@ static int setup_mcfg_map(struct acpi_pci_root_info *ci)
 
 	return 0;
 }
-
-static void teardown_mcfg_map(struct acpi_pci_root_info *ci)
-{
-	struct acpi_pci_root *root = ci->root;
-	struct pci_mmcfg_region *cfg;
-
-	cfg = pci_mmconfig_lookup(root->segment, root->secondary.start);
-	if (!cfg)
-		return;
-
-	if (cfg->hot_added)
-		pci_mmconfig_delete(root->segment, root->secondary.start,
-				    root->secondary.end);
-}
 #else
 static int setup_mcfg_map(struct acpi_pci_root_info *ci)
 {
 	return 0;
 }
-
-static void teardown_mcfg_map(struct acpi_pci_root_info *ci)
-{
-}
 #endif
 
 static int pci_acpi_root_get_node(struct acpi_pci_root *root)
@@ -251,7 +233,7 @@ static int pci_acpi_root_init_info(struct acpi_pci_root_info *ci)
 
 static void pci_acpi_root_release_info(struct acpi_pci_root_info *ci)
 {
-	teardown_mcfg_map(ci);
+	pci_mmcfg_teardown_map(ci);
 	kfree(container_of(ci, struct pci_root_info, common));
 }
 
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:58 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:58 +0100
Subject: [PATCH V4 20/23] pci,
 acpi: Support for ACPI based generic PCI host controller init
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-21-git-send-email-tn@semihalf.com>

Because of two patch series:
1. Jiang Liu's common interface to support PCI host controller init
2. MMCONFIG refactoring (part of this patch set)
now we can think about generic ACPI based PCI host controller init
implementation out of arch/ directory.

These calls use information from MCFG table (PCI config space regions)
and _CRS method (IO/irq resources) to initialize PCI hostbridge.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
CC: Arnd Bergmann <arnd at arndb.de>
CC: Catalin Marinas <catalin.marinas at arm.com>
CC: Liviu Dudau <Liviu.Dudau at arm.com>
CC: Lorenzo Pieralisi <Lorenzo.Pieralisi at arm.com>
CC: Will Deacon <will.deacon at arm.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/acpi/Kconfig    |   7 +++
 drivers/acpi/pci_root.c | 111 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 118 insertions(+)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 183ffa3..1c7f57bd 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -346,6 +346,13 @@ config ACPI_PCI_SLOT
 	  i.e., segment/bus/device/function tuples, with physical slots in
 	  the system.  If you are unsure, say N.
 
+config ACPI_PCI_HOST_GENERIC
+	bool
+	help
+	  Select this config option from the architecture Kconfig,
+	  if it is preferred to enable ACPI PCI host controller driver which
+	  has no arch-specific assumptions.
+
 config X86_PM_TIMER
 	bool "Power Management Timer Support" if EXPERT
 	depends on X86
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index cc2c73a..acf0d53 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -532,6 +532,117 @@ static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm)
 	}
 }
 
+#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
+static void pci_mcfg_release_info(struct acpi_pci_root_info *ci)
+{
+	pci_mmcfg_teardown_map(ci);
+	kfree(ci);
+}
+
+static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
+{
+	struct list_head *list = &ci->resources;
+	struct acpi_device *device = ci->bridge;
+	struct resource_entry *entry, *tmp;
+	unsigned long flags;
+	int ret;
+
+	flags = IORESOURCE_IO | IORESOURCE_MEM;
+	ret = acpi_dev_get_resources(device, list,
+				     acpi_dev_filter_resource_type_cb,
+				     (void *)flags);
+	if (ret < 0) {
+		dev_warn(&device->dev,
+			 "failed to parse _CRS method, error code %d\n", ret);
+		return ret;
+	} else if (ret == 0)
+		dev_dbg(&device->dev,
+			"no IO and memory resources present in _CRS\n");
+
+	resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
+		struct resource *res = entry->res;
+
+		if (entry->res->flags & IORESOURCE_DISABLED)
+			resource_list_destroy_entry(entry);
+		else
+			res->name = ci->name;
+
+		if (res->flags & IORESOURCE_IO) {
+			resource_size_t cpu_addr = res->start;
+			resource_size_t pci_addr = cpu_addr - entry->offset;
+			resource_size_t length = resource_size(res);
+			unsigned long port;
+
+			if (pci_register_io_range(cpu_addr, length)) {
+				resource_list_destroy_entry(entry);
+				continue;
+			}
+
+			port = pci_address_to_pio(cpu_addr);
+			if (port == (unsigned long)-1) {
+				resource_list_destroy_entry(entry);
+				continue;
+			}
+
+			res->start = port;
+			res->end = port + length - 1;
+			entry->offset = port - pci_addr;
+
+			if (pci_remap_iospace(res, cpu_addr) < 0)
+				resource_list_destroy_entry(entry);
+		}
+	}
+	return ret;
+}
+
+static struct acpi_pci_root_ops acpi_pci_root_ops = {
+	.init_info = pci_mmcfg_setup_map,
+	.release_info = pci_mcfg_release_info,
+	.prepare_resources = pci_acpi_root_prepare_resources,
+};
+
+/* Root bridge scanning */
+struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
+{
+	int node = acpi_get_node(root->device->handle);
+	int domain = root->segment;
+	int busnum = root->secondary.start;
+	struct acpi_pci_root_info *info;
+	struct pci_bus *bus, *child;
+
+	if (domain && !pci_domains_supported) {
+		pr_warn("PCI %04x:%02x: multiple domains not supported.\n",
+			domain, busnum);
+		return NULL;
+	}
+
+	info = kzalloc_node(sizeof(*info), GFP_KERNEL, node);
+	if (!info) {
+		dev_err(&root->device->dev,
+			"pci_bus %04x:%02x: ignored (out of memory)\n",
+			domain, busnum);
+		return NULL;
+	}
+
+	acpi_pci_root_ops.pci_ops = pci_mcfg_get_ops(root);
+	bus = acpi_pci_root_create(root, &acpi_pci_root_ops, info, root);
+	if (!bus)
+		return NULL;
+
+	pci_bus_claim_resources(bus);
+	pci_assign_unassigned_bus_resources(bus);
+
+	/*
+	 * After the PCI-E bus has been walked and all devices discovered,
+	 * configure any settings of the fabric that might be necessary.
+	 */
+	list_for_each_entry(child, &bus->children, node)
+		pcie_bus_configure_settings(child);
+
+	return bus;
+}
+#endif /* CONFIG_ACPI_PCI_HOST_GENERIC */
+
 static int acpi_pci_root_add(struct acpi_device *device,
 			     const struct acpi_device_id *not_used)
 {
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:28:59 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:28:59 +0100
Subject: [PATCH V4 21/23] pci,
 acpi: Match PCI config space accessors against platfrom specific
 quirks.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-22-git-send-email-tn@semihalf.com>

Some platforms may not be fully compliant with generic set of PCI config
accessors. For these cases we implement the way to overwrite accessors
set prior to PCI buses enumeration. Algorithm traverses available quirk
list, matches against <platform ID (DMI), domain, bus number> tuple and
returns corresponding accessors. All quirks can be defined using:
DECLARE_ACPI_MCFG_FIXUP() and kept self contained. Example,

static const struct dmi_system_id foo_dmi[] = {
        {
                .ident = "<Platform ident string>",
                .callback = <handler>,
                .matches = {
                        DMI_MATCH(DMI_SYS_VENDOR, "<system vendor>"),
                        DMI_MATCH(DMI_PRODUCT_NAME, "<product name>"),
                        DMI_MATCH(DMI_PRODUCT_VERSION, "product version"),
                },
        },
        { }
};

static struct pci_ops foo_ecam_pci_ops = {
        .map_bus = pci_mcfg_dev_base,
        .read = foo_ecam_config_read,
        .write = foo_ecam_config_write,
};
DECLARE_ACPI_MCFG_FIXUP(foo_dmi, NULL, &foo_ecam_pci_ops, <domain_nr>, <bus_nr>);

More custom (non-DMI) matching can be done via an extra call.
Note that there is possibility to assign quirk related private data to
root->sysdata which will be available along read/wriate accessor, example:

static int boo_match(struct pci_mcfg_fixup *fixup, struct acpi_pci_root *root)
{
        return [condition] ? 1 : 0;
}

int boo_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
                          int where, int size, u32 *val)
{
        struct acpi_pci_root *root = bus->sysdata;
        struct boo_priv_data *boo_data = root->sysdata;

        [..]
}

static struct pci_ops boo_ecam_pci_ops = {
	.map_bus = pci_mcfg_dev_base,
	.read = boo_ecam_config_read,
	.write = boo_ecam_config_write,
};
DECLARE_ACPI_MCFG_FIXUP(NULL, boo_match, &boo_ecam_pci_ops, <domain_nr>, <bus_nr>);

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/acpi/mcfg.c               | 33 +++++++++++++++++++++++++++++++--
 include/acpi/acpi_bus.h           |  1 +
 include/asm-generic/vmlinux.lds.h |  7 +++++++
 include/linux/ecam.h              | 18 ++++++++++++++++++
 4 files changed, 57 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index dfc2d14..4663f70 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -8,6 +8,7 @@
  */
 
 #include <linux/acpi.h>
+#include <linux/dmi.h>
 #include <linux/ecam.h>
 #include <linux/pci.h>
 #include <linux/pci-acpi.h>
@@ -34,6 +35,29 @@ int __weak raw_pci_write(unsigned int domain, unsigned int bus,
 	return PCIBIOS_DEVICE_NOT_FOUND;
 }
 
+extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
+
+static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root *root)
+{
+	struct pci_mcfg_fixup *f;
+	int bus_num = root->secondary.start;
+	int domain = root->segment;
+
+	/*
+	 * First match against PCI topology <domain:bus> then use DMI or
+	 * custom match handler.
+	 */
+	for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
+		if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
+		    (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
+		    (f->system ? dmi_check_system(f->system) : 1 &&
+		     f->match ? f->match(f, root) : 1))
+			return f->ops;
+	}
+	return NULL;
+}
+
 void __iomem *
 pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
 {
@@ -56,10 +80,15 @@ static struct pci_ops default_pci_mcfg_ops = {
 
 struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
 {
+	struct pci_ops *pci_mcfg_ops_quirk;
+
 	/*
-	 * TODO: Match against platform specific quirks and return
-	 * corresponding PCI config space accessor set.
+	 * Match against platform specific quirks and return corresponding
+	 * PCI config space accessor set.
 	 */
+	pci_mcfg_ops_quirk = pci_mcfg_check_quirks(root);
+	if (pci_mcfg_ops_quirk)
+		return pci_mcfg_ops_quirk;
 
 	return &default_pci_mcfg_ops;
 }
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 14362a8..0fc6f13 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -556,6 +556,7 @@ struct acpi_pci_root {
 	struct pci_bus *bus;
 	u16 segment;
 	struct resource secondary;	/* downstream bus range */
+	void *sysdata;
 
 	u32 osc_support_set;	/* _OSC state of support bits */
 	u32 osc_control_set;	/* _OSC state of control bits */
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index c4bd0e2..c93fc97 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -298,6 +298,13 @@
 		VMLINUX_SYMBOL(__end_pci_fixups_suspend_late) = .;	\
 	}								\
 									\
+	/* ACPI MCFG quirks */						\
+	.acpi_fixup        : AT(ADDR(.acpi_fixup) - LOAD_OFFSET) {	\
+		VMLINUX_SYMBOL(__start_acpi_mcfg_fixups) = .;		\
+		*(.acpi_fixup_mcfg)					\
+		VMLINUX_SYMBOL(__end_acpi_mcfg_fixups) = .;		\
+	}								\
+									\
 	/* Built-in firmware blobs */					\
 	.builtin_fw        : AT(ADDR(.builtin_fw) - LOAD_OFFSET) {	\
 		VMLINUX_SYMBOL(__start_builtin_fw) = .;			\
diff --git a/include/linux/ecam.h b/include/linux/ecam.h
index e0f322e..21215be 100644
--- a/include/linux/ecam.h
+++ b/include/linux/ecam.h
@@ -20,6 +20,24 @@ struct pci_mmcfg_region {
 	bool hot_added;
 };
 
+struct pci_mcfg_fixup {
+	const struct dmi_system_id *system;
+	int (*match)(struct pci_mcfg_fixup *, struct acpi_pci_root *);
+	struct pci_ops *ops;
+	int domain;
+	int bus_num;
+};
+
+#define PCI_MCFG_DOMAIN_ANY	-1
+#define PCI_MCFG_BUS_ANY	-1
+
+/* Designate a routine to fix up buggy MCFG */
+#define DECLARE_ACPI_MCFG_FIXUP(system, match, ops, dom, bus)		\
+	static const struct pci_mcfg_fixup __mcfg_fixup_##system##dom##bus\
+	 __used	__attribute__((__section__(".acpi_fixup_mcfg"),		\
+				aligned((sizeof(void *))))) =		\
+	{ system, match, ops, dom, bus };
+
 struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
 struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
 						   int end, u64 addr);
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:29:00 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:29:00 +0100
Subject: [PATCH V4 22/23] arm64, pci,
 acpi: Assign legacy IRQs once device is enable.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-23-git-send-email-tn@semihalf.com>

This is the last step before enabling generic ACPI PCI host controller
for ARM64. We need to take care of legacy IRQ mapping for non-MSI(X)
PCI devices. pcibios_enable_device() boot order is not sensitive to
ACPI device enumeration, so it is the best place to assign device's IRQs.

NOTE: *This is going to be temporary solution*. There is ongoing work
which aims for cleaning legacy IRQ allocation, see [1].
We can consider this patch as the necessary evil which will be removed
once [1] series hits mailnline in the near future.

1. http://comments.gmane.org/gmane.linux.kernel.pci/46461

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
---
 arch/arm64/kernel/pci.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 023b983..d1a701f 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -39,16 +39,26 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
 }
 
 /**
- * pcibios_enable_device - Enable I/O and memory.
+ * pcibios_enable_device - Enable I/O, memory and legacy IRQs for ACPI.
  * @dev: PCI device to be enabled
  * @mask: bitmask of BARs to enable
  */
 int pcibios_enable_device(struct pci_dev *dev, int mask)
 {
+	int ret;
+
 	if (pci_has_flag(PCI_PROBE_ONLY))
 		return 0;
 
-	return pci_enable_resources(dev, mask);
+	ret = pci_enable_resources(dev, mask);
+	if (ret < 0)
+		return ret;
+
+#ifdef CONFIG_ACPI
+	if (!pci_dev_msi_enabled(dev))
+		return acpi_pci_irq_enable(dev);
+#endif
+	return 0;
 }
 
 /*
-- 
1.9.1



From tn at semihalf.com  Thu Feb  4 09:29:01 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu,  4 Feb 2016 18:29:01 +0100
Subject: [PATCH V4 23/23] arm64, pci,
 acpi: Start using ACPI based PCI host bridge driver for ARM64.
In-Reply-To: <1454606941-9523-1-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
Message-ID: <1454606941-9523-24-git-send-email-tn@semihalf.com>

Lets get rid of empty PCI init stub, related ACPI header and
go with full-blown PCI host bridge driver.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
CC: Arnd Bergmann <arnd at arndb.de>
CC: Catalin Marinas <catalin.marinas at arm.com>
CC: Liviu Dudau <Liviu.Dudau at arm.com>
CC: Lorenzo Pieralisi <Lorenzo.Pieralisi at arm.com>
CC: Will Deacon <will.deacon at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 arch/arm64/Kconfig      | 1 +
 arch/arm64/kernel/pci.c | 9 ---------
 2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4f45ea4..567523b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2,6 +2,7 @@ config ARM64
 	def_bool y
 	select ACPI_CCA_REQUIRED if ACPI
 	select ACPI_GENERIC_GSI if ACPI
+	select ACPI_PCI_HOST_GENERIC if ACPI
 	select ACPI_REDUCED_HARDWARE_ONLY if ACPI
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index d1a701f..0b53262 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -70,12 +70,3 @@ int pcibios_add_device(struct pci_dev *dev)
 
 	return 0;
 }
-
-#ifdef CONFIG_ACPI
-/* Root bridge scanning */
-struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
-{
-	/* TODO: Should be revisited when implementing PCI on ACPI */
-	return NULL;
-}
-#endif
-- 
1.9.1



From alexander.shishkin at linux.intel.com  Thu Feb  4 09:30:43 2016
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Thu, 04 Feb 2016 19:30:43 +0200
Subject: [PATCH V2 2/6] stm class: adds a loop to extract the first valid
 STM device name
In-Reply-To: <1454576179-27224-1-git-send-email-zhang.chunyan@linaro.org>
References: <1454487337-30184-3-git-send-email-zhang.chunyan@linaro.org>
 <1454576179-27224-1-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <871t8se62k.fsf@ashishki-desk.ger.corp.intel.com>

Chunyan Zhang <zhang.chunyan at linaro.org> writes:

I few comments below:

> The node name of STM master management policy is a concatenation of an
> STM device name to which this policy applies and following an arbitrary
> string, these two strings are concatenated with a dot.

This is true.

> This patch adds a loop for extracting the STM device name when an
> arbitrary number of dot(s) are found in this STM device name.

It's not very easy to tell what's going on here from this
description. The reader be left curious as to why an arbitrary number of
dots is a reason to run a loop. When in doubt, try to imagine as if
you're seeing this patch for the first time and ask yourself, does the
message give a clear explanation of what's going on in it.

> Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
> ---
>  drivers/hwtracing/stm/policy.c | 27 ++++++++++++++++-----------
>  1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
> index 11ab6d0..691686e 100644
> --- a/drivers/hwtracing/stm/policy.c
> +++ b/drivers/hwtracing/stm/policy.c
> @@ -321,21 +321,26 @@ stp_policies_make(struct config_group *group, const char *name)
>  	/*
>  	 * node must look like <device_name>.<policy_name>, where
>  	 * <device_name> is the name of an existing stm device and
> -	 * <policy_name> is an arbitrary string
> +	 * <policy_name> is an arbitrary string, when an arbitrary
> +	 * number of dot(s) are found in the <device_name>, the
> +	 * first matched STM device name would be extracted.
>  	 */

This leaves room for a number of suspicious situations. What if both
"xyz" and "xyz.0" are stm devices, how would you create a policy for the
latter, for example?

The rules should be such that you can tell exactly what the intended stm
device is from a policy directory name, otherwise it's just asking for
trouble.

> -	p = strchr(devname, '.');
> -	if (!p) {
> -		kfree(devname);
> -		return ERR_PTR(-EINVAL);
> -	}
> +	for (p = devname; ; p++) {
> +		p = strchr(p, '.');
> +		if (!p) {
> +			kfree(devname);
> +			return ERR_PTR(-EINVAL);
> +		}
>  
> -	*p++ = '\0';
> +		*p = '\0';
>  
> -	stm = stm_find_device(devname);
> -	kfree(devname);
> +		stm = stm_find_device(devname);
> +		if (stm)
> +			break;
> +		*p = '.';
> +	}
>  
> -	if (!stm)
> -		return ERR_PTR(-ENODEV);
> +	kfree(devname);

In the existing code there is a clear distinction between -ENODEV, which
is to say "we didn't find the device" and -EINVAL, "directory name
breaks rules/is badly formatted". After the change, it's all -EINVAL,
which also becomes "we tried everything, sorry".

So, having said all that, does the following patch solve your problem:

>From 870dc5fefa5623c39552511d31e0fa0da984d581 Mon Sep 17 00:00:00 2001
From: Alexander Shishkin <alexander.shishkin at linux.intel.com>
Date: Thu, 4 Feb 2016 18:56:34 +0200
Subject: [PATCH] stm class: Support devices with multiple instances

By convention, the name of the stm policy directory in configfs consists of
the device name to which it applies and the actual policy name, separated
by a dot. Now, some devices already have dots in their names that separate
name of the actual device from its instance identifier. Such devices will
result in two (or more, who can tell) dots in the policy directory name.

Existing policy code, however, will treat the first dot as the one that
separates device name from policy name, therefore failing the above case.

This patch makes the last dot in the directory name be the separator, thus
prohibiting dots from being used in policy names.

Suggested-by: Chunyan Zhang <zhang.chunyan at linaro.org>
Signed-off-by: Alexander Shishkin <alexander.shishkin at linux.intel.com>
---
 drivers/hwtracing/stm/policy.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
index 94d3abfb73..1db189657b 100644
--- a/drivers/hwtracing/stm/policy.c
+++ b/drivers/hwtracing/stm/policy.c
@@ -332,10 +332,11 @@ stp_policies_make(struct config_group *group, const char *name)
 
 	/*
 	 * node must look like <device_name>.<policy_name>, where
-	 * <device_name> is the name of an existing stm device and
-	 * <policy_name> is an arbitrary string
+	 * <device_name> is the name of an existing stm device; may
+	 *               contain dots;
+	 * <policy_name> is an arbitrary string; may not contain dots
 	 */
-	p = strchr(devname, '.');
+	p = strrchr(devname, '.');
 	if (!p) {
 		kfree(devname);
 		return ERR_PTR(-EINVAL);
-- 
2.7.0



From thierry.reding at gmail.com  Thu Feb  4 09:52:42 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu,  4 Feb 2016 18:52:42 +0100
Subject: [GIT PULL] clk: tegra: Fixes for v4.5-rc3
Message-ID: <1454608362-8954-1-git-send-email-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

Hi Mike, Stephen,

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.5-clk-fixes

for you to fetch changes up to 5a1d5eff3ede4de4482015a9999336051054283f:

  clk: tegra: super: Fix sparse warnings for functions not declared as static (2016-02-02 15:49:34 +0100)

Thanks,
Thierry

----------------------------------------------------------------
clk: tegra: Fixes for v4.5-rc3

This set contains a bunch of miscellaneous fixes that have accumulated
over the past couple of weeks, primarily for the Tegra210 support added
in v4.5-rc1.

----------------------------------------------------------------
Amitoj Kaur Chawla (1):
      clk: tegra: Add missing of_node_put()

Andrew Bresticker (1):
      clk: tegra: pll: Fix potential sleeping-while-atomic

Jon Hunter (7):
      clk: tegra: Add the APB2APE audio clock on Tegra210
      clk: tegra: Fix clock sources for Tegra210 EMC
      clk: tegra: Fix warning caused by pll_u failing to lock
      clk: tegra: Use definition for pll_u override bit
      clk: tegra: Fix sparse warning for pll_m
      clk: tegra: Fix sparse warnings for functions not declared as static
      clk: tegra: super: Fix sparse warnings for functions not declared as static

Mark Kuo (2):
      clk: tegra: Do not disable PLLE when under hardware control
      clk: tegra: Fix PLLE SS coefficients

Rhyland Klein (6):
      clk: tegra: Fix divider on VI_I2C
      clk: tegra: Remove improper flags for lock_enable
      clk: tegra: Fix naming of MISC registers
      clk: tegra: Fix the misnaming of nvenc from msenc
      clk: tegra: Fix pllx dyn step calculation
      clk: tegra: Fix typos around clearing PLLE bits during enable

 drivers/clk/tegra/clk-emc.c              |   6 +-
 drivers/clk/tegra/clk-id.h               |   1 +
 drivers/clk/tegra/clk-pll.c              |  50 +++++++-----
 drivers/clk/tegra/clk-tegra-periph.c     |   5 +-
 drivers/clk/tegra/clk-tegra-super-gen4.c |   6 +-
 drivers/clk/tegra/clk-tegra210.c         | 132 ++++++++++++++-----------------
 include/dt-bindings/clock/tegra210-car.h |   2 +-
 7 files changed, 104 insertions(+), 98 deletions(-)


From robh at kernel.org  Thu Feb  4 10:04:14 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 4 Feb 2016 12:04:14 -0600
Subject: [PATCH v3 1/8] dt-bindings: Add a binding for Mediatek Video
 Processor
In-Reply-To: <1454586583.7571.3.camel@mtksdaap41>
References: <1451902316-55931-1-git-send-email-tiffany.lin@mediatek.com>
 <1451902316-55931-2-git-send-email-tiffany.lin@mediatek.com>
 <20160104141506.GA22801@rob-hp-laptop> <1454586583.7571.3.camel@mtksdaap41>
Message-ID: <CAL_JsqJqQ+QRgg6HGQeGk0=rBEwQq7i-ZfoDahZwXLuvMC-=_A@mail.gmail.com>

On Thu, Feb 4, 2016 at 5:49 AM, tiffany lin <tiffany.lin at mediatek.com> wrote:
> Hi Rob,
>
>
>
>
> On Mon, 2016-01-04 at 22:15 +0800, Rob Herring wrote:
>> On Mon, Jan 04, 2016 at 06:11:49PM +0800, Tiffany Lin wrote:
>> > From: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
>> >
>> > Add a DT binding documentation of Video Processor Unit for the
>> > MT8173 SoC from Mediatek.
>> >
>> > Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
>> > Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
>>
>> Please add acks when sending new versions as I already acked the last
>> version.
>>
> Since we remove iommu attach and add 4GB support for VPU.
> We send the new device tree and binding document.
> We do not add Acked-by in v4 patches.

Okay, then you should explain that in the patch.

Rob


From grygorii.strashko at ti.com  Thu Feb  4 10:20:17 2016
From: grygorii.strashko at ti.com (Grygorii Strashko)
Date: Thu, 4 Feb 2016 20:20:17 +0200
Subject: [RFC PATCH] ARM: clocksource: make ARM_GLOBAL_TIMER selectable
Message-ID: <1454610017-25499-1-git-send-email-grygorii.strashko@ti.com>

This patch intended to fix following cases: 
- SoC-A has ARM GT, defines DT node for ARM GT and selects ARM_GLOBAL_TIMER
statically in Kconfig file. SoC-B has ARM GT and defines DT node for ARM GT,
but do not selects ARM_GLOBAL_TIMER statically in Kconfig file. In case of
multiplatform build ARM GT will be implicitly enabled for SoC-B.

- There is no way to disable ARM GT without modifying Kconfig file,
once ARM_GLOBAL_TIMER is selected statically in Kconfig file.

Hence, fix above case by defining both HAVE_ARM_GLOBAL_TIMER and
ARM_GLOBAL_TIMER as recommended by 'Adding common features and make
the usage configurable' section in kconfig-language.txt. All places in
ARM folder where ARM_GLOBAL_TIMER was used now replaced on
HAVE_ARM_GLOBAL_TIMER.

Cc: Florian Fainelli <f.fainelli at gmail.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Wei Xu <xuwei5 at hisilicon.com>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Sascha Hauer <kernel at pengutronix.de>
Cc: Srinivas Kandagatla <srinivas.kandagatla at gmail.com>
Cc: Maxime Coquelin <maxime.coquelin at st.com>
Cc: Masahiro Yamada <yamada.masahiro at socionext.com>
Cc: Liviu Dudau <liviu.dudau at arm.com>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Jun Nie <jun.nie at linaro.org>
Cc: Michal Simek <michal.simek at xilinx.com>
Cc: "S??ren Brinkmann" <soren.brinkmann at xilinx.com>
Cc: Daniel Lezcano <daniel.lezcano at linaro.org>

Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
---
 arch/arm/mach-bcm/Kconfig      | 4 ++--
 arch/arm/mach-hisi/Kconfig     | 2 +-
 arch/arm/mach-imx/Kconfig      | 2 +-
 arch/arm/mach-rockchip/Kconfig | 2 +-
 arch/arm/mach-sti/Kconfig      | 2 +-
 arch/arm/mach-uniphier/Kconfig | 2 +-
 arch/arm/mach-vexpress/Kconfig | 2 +-
 arch/arm/mach-zx/Kconfig       | 2 +-
 arch/arm/mach-zynq/Kconfig     | 2 +-
 drivers/clocksource/Kconfig    | 7 ++++++-
 10 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 7ef1214..d4d079a7 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -14,7 +14,7 @@ config ARCH_BCM_IPROC
 	select CACHE_L2X0
 	select HAVE_ARM_SCU if SMP
 	select HAVE_ARM_TWD if SMP
-	select ARM_GLOBAL_TIMER
+	select HAVE_ARM_GLOBAL_TIMER
 	select COMMON_CLK_IPROC
 	select CLKSRC_MMIO
 	select ARCH_REQUIRE_GPIOLIB
@@ -156,7 +156,7 @@ config ARCH_BCM_63XX
 	select ARM_ERRATA_754322
 	select ARM_ERRATA_764369 if SMP
 	select ARM_GIC
-	select ARM_GLOBAL_TIMER
+	select HAVE_ARM_GLOBAL_TIMER
 	select CACHE_L2X0
 	select HAVE_ARM_ARCH_TIMER
 	select HAVE_ARM_TWD if SMP
diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig
index a3b091a..251bb03 100644
--- a/arch/arm/mach-hisi/Kconfig
+++ b/arch/arm/mach-hisi/Kconfig
@@ -28,7 +28,7 @@ config ARCH_HIP01
        depends on ARCH_MULTI_V7
        select HAVE_ARM_SCU if SMP
        select HAVE_ARM_TWD if SMP
-       select ARM_GLOBAL_TIMER
+       select HAVE_ARM_GLOBAL_TIMER
        help
          Support for Hisilicon HIP01 SoC family
 
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 15df34fb..7ea4c65 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -600,7 +600,7 @@ choice
 	config VF_USE_ARM_GLOBAL_TIMER
 		bool "Use ARM Global Timer"
 		depends on ARCH_MULTI_V7
-		select ARM_GLOBAL_TIMER
+		select HAVE_ARM_GLOBAL_TIMER
 		select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
 		help
 		  Use the ARM Global Timer as clocksource
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index cef42fd..a53b787 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -14,7 +14,7 @@ config ARCH_ROCKCHIP
 	select DW_APB_TIMER_OF
 	select REGULATOR if PM
 	select ROCKCHIP_TIMER
-	select ARM_GLOBAL_TIMER
+	select HAVE_ARM_GLOBAL_TIMER
 	select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
 	help
 	  Support for Rockchip's Cortex-A9 Single-to-Quad-Core-SoCs
diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
index a196d14..c799f9d 100644
--- a/arch/arm/mach-sti/Kconfig
+++ b/arch/arm/mach-sti/Kconfig
@@ -3,7 +3,7 @@ menuconfig ARCH_STI
 	depends on ARCH_MULTI_V7
 	select ARM_GIC
 	select ST_IRQCHIP
-	select ARM_GLOBAL_TIMER
+	select HAVE_ARM_GLOBAL_TIMER
 	select CLKSRC_ST_LPC
 	select PINCTRL
 	select PINCTRL_ST
diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig
index 82dddee..81bdf77 100644
--- a/arch/arm/mach-uniphier/Kconfig
+++ b/arch/arm/mach-uniphier/Kconfig
@@ -2,7 +2,7 @@ config ARCH_UNIPHIER
 	bool "Socionext UniPhier SoCs"
 	depends on ARCH_MULTI_V7
 	select ARM_AMBA
-	select ARM_GLOBAL_TIMER
+	select HAVE_ARM_GLOBAL_TIMER
 	select ARM_GIC
 	select HAVE_ARM_SCU
 	select HAVE_ARM_TWD if SMP
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 398a297..e89941d 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -5,7 +5,7 @@ menuconfig ARCH_VEXPRESS
 	select ARCH_SUPPORTS_BIG_ENDIAN
 	select ARM_AMBA
 	select ARM_GIC
-	select ARM_GLOBAL_TIMER
+	select HAVE_ARM_GLOBAL_TIMER
 	select ARM_TIMER_SP804
 	select COMMON_CLK_VERSATILE
 	select HAVE_ARM_SCU if SMP
diff --git a/arch/arm/mach-zx/Kconfig b/arch/arm/mach-zx/Kconfig
index 209c979..e84b0c2 100644
--- a/arch/arm/mach-zx/Kconfig
+++ b/arch/arm/mach-zx/Kconfig
@@ -11,7 +11,7 @@ if ARCH_ZX
 config SOC_ZX296702
 	def_bool y
 	select ARM_GIC
-	select ARM_GLOBAL_TIMER
+	select HAVE_ARM_GLOBAL_TIMER
 	select HAVE_ARM_SCU if SMP
 	select HAVE_ARM_TWD if SMP
 	select PM_GENERIC_DOMAINS if PM
diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
index fd0aeeb..3165720 100644
--- a/arch/arm/mach-zynq/Kconfig
+++ b/arch/arm/mach-zynq/Kconfig
@@ -5,7 +5,7 @@ config ARCH_ZYNQ
 	select ARCH_SUPPORTS_BIG_ENDIAN
 	select ARM_AMBA
 	select ARM_GIC
-	select ARM_GLOBAL_TIMER if !CPU_FREQ
+	select HAVE_ARM_GLOBAL_TIMER if !CPU_FREQ
 	select CADENCE_TTC_TIMER
 	select HAVE_ARM_SCU if SMP
 	select HAVE_ARM_TWD if SMP
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 33db740..9fcb5a8 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -206,9 +206,14 @@ config ARM_ARCH_TIMER_EVTSTREAM
 	  This must be disabled for hardware validation purposes to detect any
 	  hardware anomalies of missing events.
 
-config ARM_GLOBAL_TIMER
+config HAVE_ARM_GLOBAL_TIMER
 	bool
+
+config ARM_GLOBAL_TIMER
+	bool "Support for ARM global timer unit"
 	select CLKSRC_OF if OF
+	default y
+	depends on HAVE_ARM_GLOBAL_TIMER
 	help
 	  This options enables support for the ARM global timer unit
 
-- 
2.7.0



From tchalamarla at caviumnetworks.com  Thu Feb  4 10:45:25 2016
From: tchalamarla at caviumnetworks.com (tchalamarla at caviumnetworks.com)
Date: Thu, 4 Feb 2016 10:45:25 -0800
Subject: [PATCH] irqchip-gicv3: Make sure read from ICC_IAR1_EL1 is visible on
 redestributor
Message-ID: <1454611525-18032-1-git-send-email-tchalamarla@caviumnetworks.com>

From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>

ARM GIC specification mention the need for dsb after ICC_IAR1_EL1 read.

4.1.1 Physical CPU Interface:
"The effects of reading ICC_IAR0_EL1 and ICC_IAR1_EL1 on the state of a
returned INTID are not guaranteed to be visible until after the
execution of a DSB."

The effect of not having this is, missing interrupts.
this patch address the problem by adding a dsb .

changes form V1:
	- modified subject line and commit message.

Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
---
 arch/arm64/include/asm/arch_gicv3.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/include/asm/arch_gicv3.h b/arch/arm64/include/asm/arch_gicv3.h
index 2731d3b..8ec88e5 100644
--- a/arch/arm64/include/asm/arch_gicv3.h
+++ b/arch/arm64/include/asm/arch_gicv3.h
@@ -103,6 +103,7 @@ static inline u64 gic_read_iar_common(void)
 	u64 irqstat;
 
 	asm volatile("mrs_s %0, " __stringify(ICC_IAR1_EL1) : "=r" (irqstat));
+	dsb(sy);
 	return irqstat;
 }
 
-- 
2.1.0



From bcrl at kvack.org  Thu Feb  4 10:48:25 2016
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Thu, 4 Feb 2016 13:48:25 -0500
Subject: linux-next: build failure after merge of the aio tree
In-Reply-To: <20160204161741.GH10826@n2100.arm.linux.org.uk>
References: <CAMuHMdUy-cqeN8COO4rdpY-mOH+6gth40wB31-edkj8CO5PFCw@mail.gmail.com>
 <20160204131959.6695c7bf@canb.auug.org.au> <20160204134142.GA16315@kvack.org>
 <20160204135056.GE10826@n2100.arm.linux.org.uk>
 <20160204140822.GB16315@kvack.org>
 <20160204141253.GF10826@n2100.arm.linux.org.uk>
 <20160204143204.GC16315@kvack.org>
 <20160204143907.GG10826@n2100.arm.linux.org.uk>
 <20160204160101.GD16315@kvack.org>
 <20160204161741.GH10826@n2100.arm.linux.org.uk>
Message-ID: <20160204184825.GG16315@kvack.org>

On Thu, Feb 04, 2016 at 04:17:42PM +0000, Russell King - ARM Linux wrote:
> __gu_val will be 32-bit, even when you're wanting a 64-bit quantity.
> That's where the fun and games start...

Okay, I figured out how to do it: instead of using a 64 bit unsigned long 
long for __gu_val, use an array of 2 unsigned longs.  See the patch below 
which I verified boots, passes your tests and doesn't truncate 64 bit 
values.  Comments?  A simple test module to verify things is located at 
http://www.kvack.org/~bcrl/test_module2.c .

		-ben
-- 
"Thought is the essence of where you are now."


diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 09b1b0a..53244ae 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -326,7 +326,22 @@ do {									\
 } while (0)
 
 #ifdef CONFIG_X86_32
-#define __get_user_asm_u64(x, ptr, retval, errret)	(x) = __get_user_bad()
+#define __get_user_asm_u64(x, addr, err, errret)			\
+	asm volatile(ASM_STAC "\n"					\
+		     "1:	movl %2,%%eax\n"			\
+		     "2:	movl %3,%%edx\n"			\
+		     "3: " ASM_CLAC "\n"				\
+		     ".section .fixup,\"ax\"\n"				\
+		     "4:	mov %4,%0\n"				\
+		     "	xorl %%eax,%%eax\n"				\
+		     "	xorl %%edx,%%edx\n"				\
+		     "	jmp 3b\n"					\
+		     ".previous\n"					\
+		     _ASM_EXTABLE(1b, 4b)				\
+		     _ASM_EXTABLE(2b, 4b)				\
+		     : "=r" (err), "=A"(x)				\
+		     : "m" (__m(addr)), "m" __m(((u32 *)addr) + 1), "i" (errret), "0" (err))
+
 #define __get_user_asm_ex_u64(x, ptr)			(x) = __get_user_bad()
 #else
 #define __get_user_asm_u64(x, ptr, retval, errret) \
@@ -407,9 +422,16 @@ do {									\
 #define __get_user_nocheck(x, ptr, size)				\
 ({									\
 	int __gu_err;							\
-	unsigned long __gu_val;						\
-	__get_user_size(__gu_val, (ptr), (size), __gu_err, -EFAULT);	\
-	(x) = (__force __typeof__(*(ptr)))__gu_val;			\
+	if (size == 8) {						\
+		unsigned long __gu_val[2];				\
+		__gu_err = 0;						\
+		__get_user_asm_u64(__gu_val, ptr, __gu_err, -EFAULT);	\
+		(x) = *(__force __typeof__((ptr)))__gu_val;		\
+	} else {							\
+		unsigned long __gu_val;					\
+		__get_user_size(__gu_val, (ptr), (size), __gu_err, -EFAULT); \
+		(x) = (__force __typeof__(*(ptr)))__gu_val;		\
+	}								\
 	__builtin_expect(__gu_err, 0);					\
 })
 


From will.deacon at arm.com  Thu Feb  4 10:49:22 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 4 Feb 2016 18:49:22 +0000
Subject: [GIT PULL] arm64: fixes for -rc3
Message-ID: <20160204184922.GC21422@arm.com>

Hi Linus,

Please pull these arm64 fixes for -rc3. Nothing particularly interesting
here, but all important fixes nonetheless. Details in the tag.

Cheers,

Will

--->8

The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3:

  Linux 4.5-rc2 (2016-01-31 18:12:16 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes

for you to fetch changes up to 3e275c64a973ba1554ef87f76c9f0f5b5221ab14:

  arm64: asm: Explicitly include linux/personality.h in asm/page.h (2016-02-03 19:22:02 +0000)

----------------------------------------------------------------
arm64 fixes:

- Add missing PAN toggling in the futex code

- Fix missing #include that briefly caused issues in -next

- Allow changing of vmalloc permissions with set_memory_* (used by bpf)

----------------------------------------------------------------
Ard Biesheuvel (1):
      arm64: allow vmalloc regions to be set with set_memory_*

James Morse (1):
      arm64: futex.h: Add missing PAN toggling

Mark Brown (1):
      arm64: asm: Explicitly include linux/personality.h in asm/page.h

 arch/arm64/include/asm/futex.h |  2 ++
 arch/arm64/include/asm/page.h  |  1 +
 arch/arm64/mm/pageattr.c       | 23 +++++++++++++++++++----
 3 files changed, 22 insertions(+), 4 deletions(-)


From maxime.ripard at free-electrons.com  Thu Feb  4 08:44:38 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 4 Feb 2016 17:44:38 +0100
Subject: [PATCH 10/11] ARM: dts: sun9i: a80-optimus: Disable dummy
 regulators vcc3v0, vcc3v3, vcc5v0
In-Reply-To: <CAGb2v66xjgsoVEBocUfDk6DDx4QcH-4pP94v+4FHLTJ=rii09Q@mail.gmail.com>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-11-git-send-email-wens@csie.org>
 <20160202162136.GX4652@lukather>
 <CAGb2v66xjgsoVEBocUfDk6DDx4QcH-4pP94v+4FHLTJ=rii09Q@mail.gmail.com>
Message-ID: <20160204164438.GJ4270@lukather>

On Wed, Feb 03, 2016 at 12:41:37AM +0800, Chen-Yu Tsai wrote:
> On Wed, Feb 3, 2016 at 12:21 AM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > Hi,
> >
> > On Tue, Feb 02, 2016 at 06:27:43PM +0800, Chen-Yu Tsai wrote:
> >> These 3 regulators are provided in sunxi-common-regulators.dtsi.
> >> 3.0V/3.3V and 5.0V are commonly used voltages in Allwinner devices.
> >> These dummy regulators provide a stand-in when bindings that require
> >> one, but the real regulator is not supported yet.
> >>
> >> Since these are no longer needed, we can disable them.
> >>
> >> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
> >
> > Why not remove the include entirely then?
> 
> reg_vbus* are still used. Or should we move them as well?

I think so yeah. It's totally fine to disable per-boards regulators.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/87bf6d46/attachment-0001.sig>

From maxime.ripard at free-electrons.com  Thu Feb  4 08:51:51 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 4 Feb 2016 17:51:51 +0100
Subject: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
In-Reply-To: <56B0DF26.10203@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-6-git-send-email-andre.przywara@arm.com>
 <20160201182754.GA14737@excalibur.cnev.de>
 <56AFE0EC.8080207@arm.com> <20160202100046.GM4652@lukather>
 <56B0DF26.10203@arm.com>
Message-ID: <20160204165151.GK4270@lukather>

Hi Andre,

On Tue, Feb 02, 2016 at 04:53:58PM +0000, Andre Przywara wrote:
> > So, droping it in the filenames, why not. But I'd really like to keep
> > the same compatible scheme.
> 
> And I still don't get this: in the DT compatible scheme we always have a
> vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. core
> or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So
> why should we add an arbitrary and confusing sun50i naming to it (when
> it actually should be more like "sun8i-a64").

I don't decide on their marketing names. And I know you want to start
anew with the arm64 SoCs, but the truth is, you don't. Most of the
compatibles in the DTSI are from earlier SoCs, and we have to keep
that legacy and remain consistent with it. With all the good and bad
things a legacy imply.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/a8aca967/attachment.sig>

From christoffer.dall at linaro.org  Thu Feb  4 11:15:09 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Thu, 4 Feb 2016 20:15:09 +0100
Subject: [PATCH v3 11/23] arm64: KVM: VHE: Split save/restore of
 registers shared between guest and host
In-Reply-To: <1454522416-6874-12-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-12-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160204191509.GE13974@cbox>

On Wed, Feb 03, 2016 at 06:00:04PM +0000, Marc Zyngier wrote:
> A handful of system registers are still shared between host and guest,
> even while using VHE (tpidr*_el[01] and actlr_el1).
> 
> Also, some of the vcpu state (sp_el0, PC and PSTATE) must be
> save/restored on entry/exit, as they are used on the host as well.
> 
> In order to facilitate the introduction of a VHE-specific sysreg
> save/restore, make move the access to these registers to their
> own save/restore functions.
> 
> No functionnal change.

uber nit: s/functionnal/functional/

> 
> Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/hyp/sysreg-sr.c | 48 +++++++++++++++++++++++++++++-------------
>  1 file changed, 33 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
> index bd5b543..61bad17 100644
> --- a/arch/arm64/kvm/hyp/sysreg-sr.c
> +++ b/arch/arm64/kvm/hyp/sysreg-sr.c
> @@ -23,13 +23,29 @@
>  
>  #include "hyp.h"
>  
> -/* ctxt is already in the HYP VA space */
> +/*
> + * Non-VHE: Both host and guest must save everything.
> + *
> + * VHE: Host must save tpidr*_el[01], actlr_el1, sp0, pc, pstate, and
> + * guest must save everything.
> + */
> +
> +static void __hyp_text __sysreg_save_common_state(struct kvm_cpu_context *ctxt)
> +{
> +	ctxt->sys_regs[ACTLR_EL1]	= read_sysreg(actlr_el1);
> +	ctxt->sys_regs[TPIDR_EL0]	= read_sysreg(tpidr_el0);
> +	ctxt->sys_regs[TPIDRRO_EL0]	= read_sysreg(tpidrro_el0);
> +	ctxt->sys_regs[TPIDR_EL1]	= read_sysreg(tpidr_el1);
> +	ctxt->gp_regs.regs.sp		= read_sysreg(sp_el0);
> +	ctxt->gp_regs.regs.pc		= read_sysreg(elr_el2);
> +	ctxt->gp_regs.regs.pstate	= read_sysreg(spsr_el2);
> +}
> +
>  static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
>  {
>  	ctxt->sys_regs[MPIDR_EL1]	= read_sysreg(vmpidr_el2);
>  	ctxt->sys_regs[CSSELR_EL1]	= read_sysreg(csselr_el1);
>  	ctxt->sys_regs[SCTLR_EL1]	= read_sysreg(sctlr_el1);
> -	ctxt->sys_regs[ACTLR_EL1]	= read_sysreg(actlr_el1);
>  	ctxt->sys_regs[CPACR_EL1]	= read_sysreg(cpacr_el1);
>  	ctxt->sys_regs[TTBR0_EL1]	= read_sysreg(ttbr0_el1);
>  	ctxt->sys_regs[TTBR1_EL1]	= read_sysreg(ttbr1_el1);
> @@ -41,17 +57,11 @@ static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
>  	ctxt->sys_regs[MAIR_EL1]	= read_sysreg(mair_el1);
>  	ctxt->sys_regs[VBAR_EL1]	= read_sysreg(vbar_el1);
>  	ctxt->sys_regs[CONTEXTIDR_EL1]	= read_sysreg(contextidr_el1);
> -	ctxt->sys_regs[TPIDR_EL0]	= read_sysreg(tpidr_el0);
> -	ctxt->sys_regs[TPIDRRO_EL0]	= read_sysreg(tpidrro_el0);
> -	ctxt->sys_regs[TPIDR_EL1]	= read_sysreg(tpidr_el1);
>  	ctxt->sys_regs[AMAIR_EL1]	= read_sysreg(amair_el1);
>  	ctxt->sys_regs[CNTKCTL_EL1]	= read_sysreg(cntkctl_el1);
>  	ctxt->sys_regs[PAR_EL1]		= read_sysreg(par_el1);
>  	ctxt->sys_regs[MDSCR_EL1]	= read_sysreg(mdscr_el1);
>  
> -	ctxt->gp_regs.regs.sp		= read_sysreg(sp_el0);
> -	ctxt->gp_regs.regs.pc		= read_sysreg(elr_el2);
> -	ctxt->gp_regs.regs.pstate	= read_sysreg(spsr_el2);
>  	ctxt->gp_regs.sp_el1		= read_sysreg(sp_el1);
>  	ctxt->gp_regs.elr_el1		= read_sysreg(elr_el1);
>  	ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg(spsr_el1);
> @@ -60,11 +70,24 @@ static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
>  void __hyp_text __sysreg_save_host_state(struct kvm_cpu_context *ctxt)
>  {
>  	__sysreg_save_state(ctxt);
> +	__sysreg_save_common_state(ctxt);
>  }
>  
>  void __hyp_text __sysreg_save_guest_state(struct kvm_cpu_context *ctxt)
>  {
>  	__sysreg_save_state(ctxt);
> +	__sysreg_save_common_state(ctxt);
> +}
> +
> +static void __hyp_text __sysreg_restore_common_state(struct kvm_cpu_context *ctxt)
> +{
> +	write_sysreg(ctxt->sys_regs[ACTLR_EL1],	  actlr_el1);
> +	write_sysreg(ctxt->sys_regs[TPIDR_EL0],	  tpidr_el0);
> +	write_sysreg(ctxt->sys_regs[TPIDRRO_EL0], tpidrro_el0);
> +	write_sysreg(ctxt->sys_regs[TPIDR_EL1],	  tpidr_el1);
> +	write_sysreg(ctxt->gp_regs.regs.sp,	  sp_el0);
> +	write_sysreg(ctxt->gp_regs.regs.pc,	  elr_el2);
> +	write_sysreg(ctxt->gp_regs.regs.pstate,	  spsr_el2);
>  }
>  
>  static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
> @@ -72,7 +95,6 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
>  	write_sysreg(ctxt->sys_regs[MPIDR_EL1],	  vmpidr_el2);
>  	write_sysreg(ctxt->sys_regs[CSSELR_EL1],  csselr_el1);
>  	write_sysreg(ctxt->sys_regs[SCTLR_EL1],	  sctlr_el1);
> -	write_sysreg(ctxt->sys_regs[ACTLR_EL1],	  actlr_el1);
>  	write_sysreg(ctxt->sys_regs[CPACR_EL1],	  cpacr_el1);
>  	write_sysreg(ctxt->sys_regs[TTBR0_EL1],	  ttbr0_el1);
>  	write_sysreg(ctxt->sys_regs[TTBR1_EL1],	  ttbr1_el1);
> @@ -84,17 +106,11 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
>  	write_sysreg(ctxt->sys_regs[MAIR_EL1],	  mair_el1);
>  	write_sysreg(ctxt->sys_regs[VBAR_EL1],	  vbar_el1);
>  	write_sysreg(ctxt->sys_regs[CONTEXTIDR_EL1], contextidr_el1);
> -	write_sysreg(ctxt->sys_regs[TPIDR_EL0],	  tpidr_el0);
> -	write_sysreg(ctxt->sys_regs[TPIDRRO_EL0], tpidrro_el0);
> -	write_sysreg(ctxt->sys_regs[TPIDR_EL1],	  tpidr_el1);
>  	write_sysreg(ctxt->sys_regs[AMAIR_EL1],	  amair_el1);
>  	write_sysreg(ctxt->sys_regs[CNTKCTL_EL1], cntkctl_el1);
>  	write_sysreg(ctxt->sys_regs[PAR_EL1],	  par_el1);
>  	write_sysreg(ctxt->sys_regs[MDSCR_EL1],	  mdscr_el1);
>  
> -	write_sysreg(ctxt->gp_regs.regs.sp,	sp_el0);
> -	write_sysreg(ctxt->gp_regs.regs.pc,	elr_el2);
> -	write_sysreg(ctxt->gp_regs.regs.pstate,	spsr_el2);
>  	write_sysreg(ctxt->gp_regs.sp_el1,	sp_el1);
>  	write_sysreg(ctxt->gp_regs.elr_el1,	elr_el1);
>  	write_sysreg(ctxt->gp_regs.spsr[KVM_SPSR_EL1], spsr_el1);
> @@ -103,11 +119,13 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
>  void __hyp_text __sysreg_restore_host_state(struct kvm_cpu_context *ctxt)
>  {
>  	__sysreg_restore_state(ctxt);
> +	__sysreg_restore_common_state(ctxt);
>  }
>  
>  void __hyp_text __sysreg_restore_guest_state(struct kvm_cpu_context *ctxt)
>  {
>  	__sysreg_restore_state(ctxt);
> +	__sysreg_restore_common_state(ctxt);
>  }
>  
>  void __hyp_text __sysreg32_save_state(struct kvm_vcpu *vcpu)
> -- 
> 2.1.4
> 


From christoffer.dall at linaro.org  Thu Feb  4 11:20:59 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Thu, 4 Feb 2016 20:20:59 +0100
Subject: [PATCH v3 19/23] arm64: KVM: Move most of the fault decoding to C
In-Reply-To: <1454522416-6874-20-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-20-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160204192059.GF13974@cbox>

On Wed, Feb 03, 2016 at 06:00:12PM +0000, Marc Zyngier wrote:
> The fault decoding process (including computing the IPA in the case
> of a permission fault) would be much better done in C code, as we
> have a reasonable infrastructure to deal with the VHE/non-VHE
> differences.
> 
> Let's move the whole thing to C, including the workaround for
> erratum 834220, and just patch the odd ESR_EL2 access remaining
> in hyp-entry.S.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kernel/asm-offsets.c |  3 --
>  arch/arm64/kvm/hyp/hyp-entry.S  | 69 +++------------------------------
>  arch/arm64/kvm/hyp/switch.c     | 85 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 90 insertions(+), 67 deletions(-)
> 
> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> index fffa4ac6..b0ab4e9 100644
> --- a/arch/arm64/kernel/asm-offsets.c
> +++ b/arch/arm64/kernel/asm-offsets.c
> @@ -110,9 +110,6 @@ int main(void)
>    DEFINE(CPU_USER_PT_REGS,	offsetof(struct kvm_regs, regs));
>    DEFINE(CPU_FP_REGS,		offsetof(struct kvm_regs, fp_regs));
>    DEFINE(VCPU_FPEXC32_EL2,	offsetof(struct kvm_vcpu, arch.ctxt.sys_regs[FPEXC32_EL2]));
> -  DEFINE(VCPU_ESR_EL2,		offsetof(struct kvm_vcpu, arch.fault.esr_el2));
> -  DEFINE(VCPU_FAR_EL2,		offsetof(struct kvm_vcpu, arch.fault.far_el2));
> -  DEFINE(VCPU_HPFAR_EL2,	offsetof(struct kvm_vcpu, arch.fault.hpfar_el2));
>    DEFINE(VCPU_HOST_CONTEXT,	offsetof(struct kvm_vcpu, arch.host_cpu_context));
>  #endif
>  #ifdef CONFIG_CPU_PM
> diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
> index 1bdeee7..3488894 100644
> --- a/arch/arm64/kvm/hyp/hyp-entry.S
> +++ b/arch/arm64/kvm/hyp/hyp-entry.S
> @@ -19,7 +19,6 @@
>  
>  #include <asm/alternative.h>
>  #include <asm/assembler.h>
> -#include <asm/asm-offsets.h>
>  #include <asm/cpufeature.h>
>  #include <asm/kvm_arm.h>
>  #include <asm/kvm_asm.h>
> @@ -69,7 +68,11 @@ ENDPROC(__vhe_hyp_call)
>  el1_sync:				// Guest trapped into EL2
>  	save_x0_to_x3
>  
> +alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
>  	mrs	x1, esr_el2
> +alternative_else
> +	mrs	x1, esr_el1
> +alternative_endif
>  	lsr	x2, x1, #ESR_ELx_EC_SHIFT
>  
>  	cmp	x2, #ESR_ELx_EC_HVC64
> @@ -105,72 +108,10 @@ el1_trap:
>  	cmp	x2, #ESR_ELx_EC_FP_ASIMD
>  	b.eq	__fpsimd_guest_restore
>  
> -	cmp	x2, #ESR_ELx_EC_DABT_LOW
> -	mov	x0, #ESR_ELx_EC_IABT_LOW
> -	ccmp	x2, x0, #4, ne
> -	b.ne	1f		// Not an abort we care about
> -
> -	/* This is an abort. Check for permission fault */
> -alternative_if_not ARM64_WORKAROUND_834220
> -	and	x2, x1, #ESR_ELx_FSC_TYPE
> -	cmp	x2, #FSC_PERM
> -	b.ne	1f		// Not a permission fault
> -alternative_else
> -	nop			// Use the permission fault path to
> -	nop			// check for a valid S1 translation,
> -	nop			// regardless of the ESR value.
> -alternative_endif
> -
> -	/*
> -	 * Check for Stage-1 page table walk, which is guaranteed
> -	 * to give a valid HPFAR_EL2.
> -	 */
> -	tbnz	x1, #7, 1f	// S1PTW is set
> -
> -	/* Preserve PAR_EL1 */
> -	mrs	x3, par_el1
> -	stp	x3, xzr, [sp, #-16]!
> -
> -	/*
> -	 * Permission fault, HPFAR_EL2 is invalid.
> -	 * Resolve the IPA the hard way using the guest VA.
> -	 * Stage-1 translation already validated the memory access rights.
> -	 * As such, we can use the EL1 translation regime, and don't have
> -	 * to distinguish between EL0 and EL1 access.
> -	 */
> -	mrs	x2, far_el2
> -	at	s1e1r, x2
> -	isb
> -
> -	/* Read result */
> -	mrs	x3, par_el1
> -	ldp	x0, xzr, [sp], #16	// Restore PAR_EL1 from the stack
> -	msr	par_el1, x0
> -	tbnz	x3, #0, 3f		// Bail out if we failed the translation
> -	ubfx	x3, x3, #12, #36	// Extract IPA
> -	lsl	x3, x3, #4		// and present it like HPFAR
> -	b	2f
> -
> -1:	mrs	x3, hpfar_el2
> -	mrs	x2, far_el2
> -
> -2:	mrs	x0, tpidr_el2
> -	str	w1, [x0, #VCPU_ESR_EL2]
> -	str	x2, [x0, #VCPU_FAR_EL2]
> -	str	x3, [x0, #VCPU_HPFAR_EL2]
> -
> +	mrs	x0, tpidr_el2
>  	mov	x1, #ARM_EXCEPTION_TRAP
>  	b	__guest_exit
>  
> -	/*
> -	 * Translation failed. Just return to the guest and
> -	 * let it fault again. Another CPU is probably playing
> -	 * behind our back.
> -	 */
> -3:	restore_x0_to_x3
> -
> -	eret
> -
>  el1_irq:
>  	save_x0_to_x3
>  	mrs	x0, tpidr_el2
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index e90683a..a192357 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/switch.c
> @@ -15,6 +15,7 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <linux/types.h>
>  #include <asm/kvm_asm.h>
>  
>  #include "hyp.h"
> @@ -145,6 +146,86 @@ static void __hyp_text __vgic_restore_state(struct kvm_vcpu *vcpu)
>  	__vgic_call_restore_state()(vcpu);
>  }
>  
> +static bool __hyp_text __true_value(void)
> +{
> +	return true;
> +}
> +
> +static bool __hyp_text __false_value(void)
> +{
> +	return false;
> +}
> +
> +static hyp_alternate_select(__check_arm_834220,
> +			    __false_value, __true_value,
> +			    ARM64_WORKAROUND_834220);
> +
> +static bool __hyp_text __translate_far_to_hpfar(u64 far, u64 *hpfar)
> +{
> +	u64 par, tmp;
> +
> +	/*
> +	 * Resolve the IPA the hard way using the guest VA.
> +	 *
> +	 * Stage-1 translation already validated the memory access
> +	 * rights. As such, we can use the EL1 translation regime, and
> +	 * don't have to distinguish between EL0 and EL1 access.
> +	 *
> +	 * We do need to save/restore PAR_EL1 though, as we haven't
> +	 * saved the guest context yet, and we may return early...
> +	 */
> +	par = read_sysreg(par_el1);
> +	asm volatile("at s1e1r, %0" : : "r" (far));
> +	isb();
> +
> +	tmp = read_sysreg(par_el1);
> +	write_sysreg(par, par_el1);
> +
> +	if (unlikely(tmp & 1))
> +		return false; /* Translation failed, back to guest */
> +
> +	/* Convert PAR to HPFAR format */
> +	*hpfar = ((tmp >> 12) & ((1UL << 36) - 1)) << 4;
> +	return true;
> +}
> +
> +static bool __hyp_text __populate_fault_info(struct kvm_vcpu *vcpu)
> +{
> +	u64 esr = read_sysreg_el2(esr);
> +	u8 ec = esr >> ESR_ELx_EC_SHIFT;
> +	u64 hpfar, far;
> +
> +	vcpu->arch.fault.esr_el2 = esr;
> +
> +	if (ec != ESR_ELx_EC_DABT_LOW && ec != ESR_ELx_EC_IABT_LOW)
> +		return true;
> +
> +	far = read_sysreg_el2(far);
> +
> +	/*
> +	 * The HPFAR can be invalid if the stage 2 fault did not
> +	 * happen during a stage 1 page table walk (the ESR_EL2.S1PTW
> +	 * bit is clear) and one of the two following cases are true:
> +	 *   1. The fault was due to a permission fault
> +	 *   2. The processor carries errata 834220
> +	 *
> +	 * Therefore, for all non S1PTW faults where we either have a
> +	 * permission fault or the errata workaround is enabled, we
> +	 * resolve the IPA using the AT instruction.
> +	 */
> +	if (!(esr & ESR_ELx_S1PTW) &&
> +	    (__check_arm_834220()() || (esr & ESR_ELx_FSC_TYPE) == FSC_PERM)) {
> +		if (!__translate_far_to_hpfar(far, &hpfar))
> +			return false;
> +	} else {
> +		hpfar = read_sysreg(hpfar_el2);
> +	}
> +
> +	vcpu->arch.fault.far_el2 = far;
> +	vcpu->arch.fault.hpfar_el2 = hpfar;
> +	return true;
> +}
> +
>  static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
>  {
>  	struct kvm_cpu_context *host_ctxt;
> @@ -176,9 +257,13 @@ static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
>  	__debug_restore_state(vcpu, kern_hyp_va(vcpu->arch.debug_ptr), guest_ctxt);
>  
>  	/* Jump in the fire! */
> +again:
>  	exit_code = __guest_enter(vcpu, host_ctxt);
>  	/* And we're baaack! */
>  
> +	if (exit_code == ARM_EXCEPTION_TRAP && !__populate_fault_info(vcpu))
> +		goto again;
> +
>  	fp_enabled = __fpsimd_enabled();
>  
>  	__sysreg_save_guest_state(guest_ctxt);
> -- 
> 2.1.4
> 

Thanks for the rewrite, I find this code really nice now, especially
comparing to the confusing job-security-creating stuff we had in
assembly before.

-Christoffer


From christoffer.dall at linaro.org  Thu Feb  4 11:23:01 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Thu, 4 Feb 2016 20:23:01 +0100
Subject: [PATCH v3 20/23] arm64: perf: Count EL2 events if the kernel is
 running in HYP
In-Reply-To: <1454522416-6874-21-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-21-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160204192301.GG13974@cbox>

On Wed, Feb 03, 2016 at 06:00:13PM +0000, Marc Zyngier wrote:
> When the kernel is running in HYP (with VHE), it is necessary to
> include EL2 events if the user requests counting kernel or
> hypervisor events.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kernel/perf_event.c | 14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index f7ab14c..6013a38 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -20,6 +20,7 @@
>   */
>  
>  #include <asm/irq_regs.h>
> +#include <asm/virt.h>
>  
>  #include <linux/of.h>
>  #include <linux/perf/arm_pmu.h>
> @@ -693,10 +694,15 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
>  		return -EPERM;
>  	if (attr->exclude_user)
>  		config_base |= ARMV8_EXCLUDE_EL0;
> -	if (attr->exclude_kernel)
> -		config_base |= ARMV8_EXCLUDE_EL1;
> -	if (!attr->exclude_hv)
> -		config_base |= ARMV8_INCLUDE_EL2;
> +	if (is_kernel_in_hyp_mode()) {
> +		if (!attr->exclude_kernel || !attr->exclude_hv)
> +			config_base |= ARMV8_INCLUDE_EL2;

is exclude_hv a perf generic construct?

is it really correct to count everything the host kernel does (even
unrelated to running VMs) when counting hypervisor events?

Other than my ignorance in this area, this patch looks fine to me.

Thanks,
-Christoffer

> +	} else {
> +		if (attr->exclude_kernel)
> +			config_base |= ARMV8_EXCLUDE_EL1;
> +		if (!attr->exclude_hv)
> +			config_base |= ARMV8_INCLUDE_EL2;
> +	}
>  
>  	/*
>  	 * Install the filter into config_base as this is used to
> -- 
> 2.1.4
> 


From christoffer.dall at linaro.org  Thu Feb  4 11:25:17 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Thu, 4 Feb 2016 20:25:17 +0100
Subject: [PATCH v3 23/23] arm64: Panic when VHE and non VHE CPUs coexist
In-Reply-To: <1454522416-6874-24-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-24-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160204192517.GH13974@cbox>

On Wed, Feb 03, 2016 at 06:00:16PM +0000, Marc Zyngier wrote:
> Having both VHE and non-VHE capable CPUs in the same system
> is likely to be a recipe for disaster.
> 
> If the boot CPU has VHE, but a secondary is not, we won't be
> able to downgrade and run the kernel at EL1. Add CPU hotplug
> to the mix, and this produces a terrifying mess.
> 
> Let's solve the problem once and for all. If you mix VHE and
> non-VHE CPUs in the same system, you deserve to loose, and this
> patch makes sure you don't get a chance.
> 
> This is implemented by storing the kernel execution level in
> a global variable. Secondaries will park themselves in a
> WFI loop if they observe a mismatch. Also, the primary CPU
> will detect that the secondary CPU has died on a mismatched
> execution level. Panic will follow.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Thu Feb  4 11:25:25 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Thu, 4 Feb 2016 20:25:25 +0100
Subject: [PATCH v3 22/23] arm64: VHE: Add support for running Linux in
 EL2 mode
In-Reply-To: <1454522416-6874-23-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-23-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160204192525.GI13974@cbox>

On Wed, Feb 03, 2016 at 06:00:15PM +0000, Marc Zyngier wrote:
> With ARMv8.1 VHE, the architecture is able to (almost) transparently
> run the kernel at EL2, despite being written for EL1.
> 
> This patch takes care of the "almost" part, mostly preventing the kernel
> from dropping from EL2 to EL1, and setting up the HYP configuration.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Thu Feb  4 11:26:41 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Thu, 4 Feb 2016 20:26:41 +0100
Subject: [PATCH v3 00/23] arm64: Virtualization Host Extension support
In-Reply-To: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160204192641.GJ13974@cbox>

On Wed, Feb 03, 2016 at 05:59:53PM +0000, Marc Zyngier wrote:
> ARMv8.1 comes with the "Virtualization Host Extension" (VHE for
> short), which enables simpler support of Type-2 hypervisors.
> 
> This extension allows the kernel to directly run at EL2, and
> significantly reduces the number of system registers shared between
> host and guest, reducing the overhead of virtualization.
> 
> In order to have the same kernel binary running on all versions of the
> architecture, this series makes heavy use of runtime code patching.
> 
> The first 22 patches massage the KVM code to deal with VHE and enable
> Linux to run at EL2. The last patch catches an ugly case when VHE
> capable CPUs are paired with some of their less capable siblings. This
> should never happen, but hey...
> 
> I have deliberately left out some of the more "advanced"
> optimizations, as they are likely to distract the reviewer from the
> core infrastructure, which is what I care about at the moment.
> 
> Note: GDB is currently busted on VHE systems, as it checks for version
>       6 on the debug architecture, while VHE is version 7. The
>       binutils people are on the case.
> 
> This has been tested on the FVP_Base_SLV-V8-A model, and based on
> v4.5-rc2. I've put a branch out on:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/vhe
> 

You can have my reviewed-by on all patches that I didn't already review
or ack explicitly.

Only exception is the debug stuff where I didn't manage to page in the
context, so hopefully familiar with that code can have a look.

Then this is ready to be queued.

Thanks,
-Christoffer


From wsa at the-dreams.de  Thu Feb  4 11:30:37 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Thu, 4 Feb 2016 20:30:37 +0100
Subject: [PATCH v2] clk: shmobile: r8a7795: Add SD divider support
In-Reply-To: <1454135639-4102-1-git-send-email-dirk.behme@gmail.com>
References: <1454135639-4102-1-git-send-email-dirk.behme@gmail.com>
Message-ID: <20160204193036.GA1958@tetsubishi>

On Sat, Jan 30, 2016 at 07:33:59AM +0100, Dirk Behme wrote:
> This patch adds SD[0..3] clock divider support for R-Car Gen3 SoC.
> 
> Signed-off-by: Takeshi Kihara <takeshi.kihara.df at renesas.com>
> Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>

Tested-by: Wolfram Sang <wsa+renesas at sang-engineering.com>

Since we don't have UHS support currently, changing the clock is not
really exercised; but the code looks good and if it needs fixing, we can
do it incrementally IMO. What is currently needed works fine on my
Salvator-X for the exposed SD interfaces.

Thanks,

   Wolfram

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/45685662/attachment.sig>

From labbott at fedoraproject.org  Thu Feb  4 11:43:37 2016
From: labbott at fedoraproject.org (Laura Abbott)
Date: Thu,  4 Feb 2016 11:43:37 -0800
Subject: [PATCHv3 3/3] arm64: ptdump: Indicate whether memory should be
 faulting
In-Reply-To: <1454615017-24672-1-git-send-email-labbott@fedoraproject.org>
References: <1454615017-24672-1-git-send-email-labbott@fedoraproject.org>
Message-ID: <1454615017-24672-4-git-send-email-labbott@fedoraproject.org>


With CONFIG_DEBUG_PAGEALLOC, pages do not have the valid bit
set when free in the buddy allocator. Add an indiciation to
the page table dumping code that the valid bit is not set,
'F' for fault, to make this easier to understand.

Signed-off-by: Laura Abbott <labbott at fedoraproject.org>
---
 arch/arm64/mm/dump.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index 5a22a11..f381ac9 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -90,6 +90,11 @@ struct prot_bits {
 
 static const struct prot_bits pte_bits[] = {
 	{
+		.mask	= PTE_VALID,
+		.val	= PTE_VALID,
+		.set	= " ",
+		.clear	= "F",
+	}, {
 		.mask	= PTE_USER,
 		.val	= PTE_USER,
 		.set	= "USR",
-- 
2.5.0



From labbott at fedoraproject.org  Thu Feb  4 11:43:36 2016
From: labbott at fedoraproject.org (Laura Abbott)
Date: Thu,  4 Feb 2016 11:43:36 -0800
Subject: [PATCHv2 2/3] arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
In-Reply-To: <1454615017-24672-1-git-send-email-labbott@fedoraproject.org>
References: <1454615017-24672-1-git-send-email-labbott@fedoraproject.org>
Message-ID: <1454615017-24672-3-git-send-email-labbott@fedoraproject.org>


ARCH_SUPPORTS_DEBUG_PAGEALLOC provides a hook to map and unmap
pages for debugging purposes. This requires memory be mapped
with PAGE_SIZE mappings since breaking down larger mappings
at runtime will lead to TLB conflicts. Check if debug_pagealloc
is enabled at runtime and if so, map everyting with PAGE_SIZE
pages. Implement the functions to actually map/unmap the
pages at runtime.

Signed-off-by: Laura Abbott <labbott at fedoraproject.org>
---
 arch/arm64/Kconfig       |  3 +++
 arch/arm64/mm/mmu.c      | 25 +++++++++++++++++++++----
 arch/arm64/mm/pageattr.c | 46 ++++++++++++++++++++++++++++++++++++----------
 3 files changed, 60 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc6228..0f33218 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -537,6 +537,9 @@ config HOTPLUG_CPU
 source kernel/Kconfig.preempt
 source kernel/Kconfig.hz
 
+config ARCH_SUPPORTS_DEBUG_PAGEALLOC
+	def_bool y
+
 config ARCH_HAS_HOLES_MEMORYMODEL
 	def_bool y if SPARSEMEM
 
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index ef0d66c..be81a59 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -180,8 +180,14 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
 	pmd = pmd_set_fixmap_offset(pud, addr);
 	do {
 		next = pmd_addr_end(addr, end);
-		/* try section mapping first */
-		if (((addr | next | phys) & ~SECTION_MASK) == 0) {
+		/*
+		 * try a section mapping first
+		 *
+		 * See comment in use_1G_block for why we need the check
+		 * for !pgtable_alloc with !debug_pagealloc
+		 */
+		if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
+		      (!debug_pagealloc_enabled() || !pgtable_alloc)) {
 			pmd_t old_pmd =*pmd;
 			set_pmd(pmd, __pmd(phys |
 					   pgprot_val(mk_sect_prot(prot))));
@@ -208,8 +214,19 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
 }
 
 static inline bool use_1G_block(unsigned long addr, unsigned long next,
-			unsigned long phys)
+			unsigned long phys, phys_addr_t (*pgtable_alloc)(void))
 {
+	/*
+	 * If debug_page_alloc is enabled we don't want to be using sections
+	 * since everything needs to be mapped with pages. The catch is
+	 * that we only want to force pages if we can allocate the next
+	 * layer of page tables. If there is no pgtable_alloc function,
+	 * it's too early to allocate another layer and we should use
+	 * section mappings.
+	 */
+	if (pgtable_alloc && debug_pagealloc_enabled())
+		return false;
+
 	if (PAGE_SHIFT != 12)
 		return false;
 
@@ -241,7 +258,7 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
 		/*
 		 * For 4K granule only, attempt to put down a 1GB block
 		 */
-		if (use_1G_block(addr, next, phys)) {
+		if (use_1G_block(addr, next, phys, pgtable_alloc)) {
 			pud_t old_pud = *pud;
 			set_pud(pud, __pud(phys |
 					   pgprot_val(mk_sect_prot(prot))));
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index 1360a02..57877af 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -37,14 +37,31 @@ static int change_page_range(pte_t *ptep, pgtable_t token, unsigned long addr,
 	return 0;
 }
 
+/*
+ * This function assumes that the range is mapped with PAGE_SIZE pages.
+ */
+static int __change_memory_common(unsigned long start, unsigned long size,
+				pgprot_t set_mask, pgprot_t clear_mask)
+{
+	struct page_change_data data;
+	int ret;
+
+	data.set_mask = set_mask;
+	data.clear_mask = clear_mask;
+
+	ret = apply_to_page_range(&init_mm, start, size, change_page_range,
+					&data);
+
+	flush_tlb_kernel_range(start, start+size);
+	return ret;
+}
+
 static int change_memory_common(unsigned long addr, int numpages,
 				pgprot_t set_mask, pgprot_t clear_mask)
 {
 	unsigned long start = addr;
 	unsigned long size = PAGE_SIZE*numpages;
 	unsigned long end = start + size;
-	int ret;
-	struct page_change_data data;
 	struct vm_struct *area;
 
 	if (!PAGE_ALIGNED(addr)) {
@@ -72,14 +89,7 @@ static int change_memory_common(unsigned long addr, int numpages,
 	    !(area->flags & VM_ALLOC))
 		return -EINVAL;
 
-	data.set_mask = set_mask;
-	data.clear_mask = clear_mask;
-
-	ret = apply_to_page_range(&init_mm, start, size, change_page_range,
-					&data);
-
-	flush_tlb_kernel_range(start, end);
-	return ret;
+	return __change_memory_common(start, size, set_mask, clear_mask);
 }
 
 int set_memory_ro(unsigned long addr, int numpages)
@@ -111,3 +121,19 @@ int set_memory_x(unsigned long addr, int numpages)
 					__pgprot(PTE_PXN));
 }
 EXPORT_SYMBOL_GPL(set_memory_x);
+
+#ifdef CONFIG_DEBUG_PAGEALLOC
+void __kernel_map_pages(struct page *page, int numpages, int enable)
+{
+	unsigned long addr = (unsigned long) page_address(page);
+
+	if (enable)
+		__change_memory_common(addr, PAGE_SIZE*numpages,
+					__pgprot(PTE_VALID),
+					__pgprot(0));
+	else
+		__change_memory_common(addr, PAGE_SIZE*numpages,
+					__pgprot(0),
+					__pgprot(PTE_VALID));
+}
+#endif
-- 
2.5.0



From labbott at fedoraproject.org  Thu Feb  4 11:43:35 2016
From: labbott at fedoraproject.org (Laura Abbott)
Date: Thu,  4 Feb 2016 11:43:35 -0800
Subject: [PATCHv3 1/3] arm64: Drop alloc function from create_mapping
In-Reply-To: <1454615017-24672-1-git-send-email-labbott@fedoraproject.org>
References: <1454615017-24672-1-git-send-email-labbott@fedoraproject.org>
Message-ID: <1454615017-24672-2-git-send-email-labbott@fedoraproject.org>


create_mapping is only used in fixmap_remap_fdt. All the create_mapping
calls need to happen on existing translation table pages without
additional allocations. Rather than have an alloc function be called
and fail, just set it to NULL and catch its use. Also change
the name to create_mapping_noalloc to better capture what exactly is
going on.

Reviewed-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Reviewed-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Laura Abbott <labbott at fedoraproject.org>
---
 arch/arm64/mm/mmu.c | 29 ++++++++++++++++++++---------
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 7711554..ef0d66c 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -116,7 +116,9 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
 	pte_t *pte;
 
 	if (pmd_none(*pmd) || pmd_sect(*pmd)) {
-		phys_addr_t pte_phys = pgtable_alloc();
+		phys_addr_t pte_phys;
+		BUG_ON(!pgtable_alloc);
+		pte_phys = pgtable_alloc();
 		pte = pte_set_fixmap(pte_phys);
 		if (pmd_sect(*pmd))
 			split_pmd(pmd, pte);
@@ -158,7 +160,9 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
 	 * Check for initial section mappings in the pgd/pud and remove them.
 	 */
 	if (pud_none(*pud) || pud_sect(*pud)) {
-		phys_addr_t pmd_phys = pgtable_alloc();
+		phys_addr_t pmd_phys;
+		BUG_ON(!pgtable_alloc);
+		pmd_phys = pgtable_alloc();
 		pmd = pmd_set_fixmap(pmd_phys);
 		if (pud_sect(*pud)) {
 			/*
@@ -223,7 +227,9 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
 	unsigned long next;
 
 	if (pgd_none(*pgd)) {
-		phys_addr_t pud_phys = pgtable_alloc();
+		phys_addr_t pud_phys;
+		BUG_ON(!pgtable_alloc);
+		pud_phys = pgtable_alloc();
 		__pgd_populate(pgd, pud_phys, PUD_TYPE_TABLE);
 	}
 	BUG_ON(pgd_bad(*pgd));
@@ -312,7 +318,12 @@ static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
 	init_pgd(pgd_offset_raw(pgdir, virt), phys, virt, size, prot, alloc);
 }
 
-static void __init create_mapping(phys_addr_t phys, unsigned long virt,
+/*
+ * This function can only be used to modify existing table entries,
+ * without allocating new levels of table. Note that this permits the
+ * creation of new section or page entries.
+ */
+static void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
 				  phys_addr_t size, pgprot_t prot)
 {
 	if (virt < VMALLOC_START) {
@@ -321,7 +332,7 @@ static void __init create_mapping(phys_addr_t phys, unsigned long virt,
 		return;
 	}
 	__create_pgd_mapping(init_mm.pgd, phys, virt, size, prot,
-			     early_pgtable_alloc);
+			     NULL);
 }
 
 void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
@@ -680,7 +691,7 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
 	/*
 	 * Make sure that the FDT region can be mapped without the need to
 	 * allocate additional translation table pages, so that it is safe
-	 * to call create_mapping() this early.
+	 * to call create_mapping_noalloc() this early.
 	 *
 	 * On 64k pages, the FDT will be mapped using PTEs, so we need to
 	 * be in the same PMD as the rest of the fixmap.
@@ -696,8 +707,8 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
 	dt_virt = (void *)dt_virt_base + offset;
 
 	/* map the first chunk so we can read the size from the header */
-	create_mapping(round_down(dt_phys, SWAPPER_BLOCK_SIZE), dt_virt_base,
-		       SWAPPER_BLOCK_SIZE, prot);
+	create_mapping_noalloc(round_down(dt_phys, SWAPPER_BLOCK_SIZE),
+			dt_virt_base, SWAPPER_BLOCK_SIZE, prot);
 
 	if (fdt_check_header(dt_virt) != 0)
 		return NULL;
@@ -707,7 +718,7 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
 		return NULL;
 
 	if (offset + size > SWAPPER_BLOCK_SIZE)
-		create_mapping(round_down(dt_phys, SWAPPER_BLOCK_SIZE), dt_virt_base,
+		create_mapping_noalloc(round_down(dt_phys, SWAPPER_BLOCK_SIZE), dt_virt_base,
 			       round_up(offset + size, SWAPPER_BLOCK_SIZE), prot);
 
 	memblock_reserve(dt_phys, size);
-- 
2.5.0



From wsa at the-dreams.de  Thu Feb  4 12:09:03 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Thu, 4 Feb 2016 21:09:03 +0100
Subject: [PATCH V7 3/6] i2c: qup: Transfer each i2c_msg in i2c_msgs
 without a stop bit
In-Reply-To: <001401d15988$59f6dcf0$0de496d0$@codeaurora.org>
References: <1453197766-18976-1-git-send-email-sricharan@codeaurora.org>
 <1453197766-18976-4-git-send-email-sricharan@codeaurora.org>
 <20160124112915.GA1775@katana>
 <001401d15988$59f6dcf0$0de496d0$@codeaurora.org>
Message-ID: <20160204200903.GE1958@tetsubishi>

Hi,

> Ah, so what I meant above is there is no 'STOP' bit between each msg in
> i2c_msgs,
> but 'REAPEATED_START' still holds true.  We are sending 'START' bit for each
> msg.
> So these is how each msg in i2c_msg is sent,
>
> |------MSG1--------|-----MSG2---------|------MSG3------------|
>
>   |START|DATA|------|START|DATA|---|START|DATA|STOP|
>
> If my commit text does not make this clear, I  can reword that ?

OK, now this looks to me perfectly fine: A number of *messages*
concatenated into one *transfer* by repeated start. That's the way it
should be.

So, I'd simply remove these words:

"The QUP i2c hardware has no way to inform that there should not be a
'STOP' at the end of transaction. The only way to implement this is to
coalesce all the i2c_msg in i2c_msgs in to one transaction and transfer
them."

This sounded like the HW needed a special handling, so I was under the
impression REP_START was broken. However, unless I misunderstood
something again, this now sounds like the standard case and we can keep
the commit message simple. If you are okay with that, I can update it
here, no need to resend.

Thanks,

   Wolfram
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160204/4a962cfe/attachment.sig>

From helgaas at kernel.org  Thu Feb  4 12:37:55 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Thu, 4 Feb 2016 14:37:55 -0600
Subject: [PATCH] PCI: designware: comment the condition of programming
 ATU in host init
In-Reply-To: <1452147158-2526-1-git-send-email-jszhang@marvell.com>
References: <1452147158-2526-1-git-send-email-jszhang@marvell.com>
Message-ID: <20160204203755.GB7031@localhost>

On Thu, Jan 07, 2016 at 02:12:38PM +0800, Jisheng Zhang wrote:
> Some platforms don't support ATU, e.g pci-keystone.c, these platforms
> use their own address translation component rather than ATU, and they
> provide the rd_other_conf and wr_other_conf to programming the
> translation component then do the required access, so we ignore the ATU
> programming for these platforms. Add the comment to explain the reason.
> 
> As Bjorn pointed out,
> 
>   "these definitions:
> 
>   #define PCIE_ATU_TYPE_MEM
>   #define PCIE_ATU_TYPE_IO
>   #define PCIE_ATU_TYPE_CFG0
>   #define PCIE_ATU_TYPE_CFG1
> 
>   and these uses:
> 
>   - In dw_pcie_host_init(), set PCIE_ATU_TYPE_MEM for unit 1
>     (but only if rd_other_conf is not overridden)
> 
>   - In dw_pcie_rd_other_conf() and dw_pcie_wr_other_conf(),
>     set PCIE_ATU_TYPE_CFG0 before config access to own bus;
>     set PCIE_ATU_TYPE_CFG1 before config access to other bus;
>     set PCIE_ATU_TYPE_IO after completion
> 
>    Why is that initialization related to rd_other_conf?  Shouldn't that
>    be set up always?  A comment here would be nice..."
> 
> To be honest, I can't answer this question immediately until I read the
> code carefully again. So indeed, the comment is really necessary.
> 
> Signed-off-by: Jisheng Zhang <jszhang at marvell.com>

Applied to pci/host-designware for v4.6, thanks, Jisheng!

> ---
>  drivers/pci/host/pcie-designware.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
> index 02a7452..b795b20 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -517,6 +517,12 @@ int dw_pcie_host_init(struct pcie_port *pp)
>  	if (pp->ops->host_init)
>  		pp->ops->host_init(pp);
>  
> +	/*
> +	 * If the platform provides ->rd_other_conf, it means the platform
> +	 * doesn't support ATU, it uses its own address translation component
> +	 * rather than ATU, so we should ignore ATU programming for this
> +	 * kind of platform.
> +	 */
>  	if (!pp->ops->rd_other_conf)
>  		dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
>  					  PCIE_ATU_TYPE_MEM, pp->mem_base,
> -- 
> 2.7.0.rc3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From k at japko.eu  Thu Feb  4 12:56:02 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Thu, 4 Feb 2016 21:56:02 +0100
Subject: [PATCH v3 1/5] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <20160204154752.4df7808be3364a98c496c030@free.fr>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-2-git-send-email-k@japko.eu>
 <20160204154752.4df7808be3364a98c496c030@free.fr>
Message-ID: <20160204205602.GC12071@box2.japko.eu>

On Thu, Feb 04, 2016 at 03:47:52PM +0100, Jean-Francois Moine wrote:
>On Thu,  4 Feb 2016 00:33:46 +0100
>Krzysztof Adamski <k at japko.eu> wrote:
>
>> This patch adds support for APB0 in H3. It seems to be compatible with
>> earlier SOCs. apb0 gates controls R_ block peripherals (R_PIO, R_IR,
>> etc).
>>
>> Signed-off-by: Krzysztof Adamski <k at japko.eu>
>> ---
>>  Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
>>  drivers/clk/sunxi/clk-simple-gates.c              | 2 ++
>>  2 files changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
>> index e59f57b..751c8b9f0 100644
>> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
>> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
>> @@ -45,6 +45,7 @@ Required properties:
>>  	"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
>>  	"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
>>  	"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
>> +	"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
>>  	"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
>>  	"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
>>  	"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
>> diff --git a/drivers/clk/sunxi/clk-simple-gates.c b/drivers/clk/sunxi/clk-simple-gates.c
>> index f4da52b..6753c87 100644
>> --- a/drivers/clk/sunxi/clk-simple-gates.c
>> +++ b/drivers/clk/sunxi/clk-simple-gates.c
>> @@ -130,6 +130,8 @@ CLK_OF_DECLARE(sun8i_a23_apb2, "allwinner,sun8i-a23-apb2-gates-clk",
>>  	       sunxi_simple_gates_init);
>>  CLK_OF_DECLARE(sun8i_a33_ahb1, "allwinner,sun8i-a33-ahb1-gates-clk",
>>  	       sunxi_simple_gates_init);
>> +CLK_OF_DECLARE(sun8i_h3_apb0, "allwinner,sun8i-h3-apb0-gates-clk",
>> +	       sunxi_simple_gates_init);
>>  CLK_OF_DECLARE(sun9i_a80_ahb0, "allwinner,sun9i-a80-ahb0-gates-clk",
>>  	       sunxi_simple_gates_init);
>>  CLK_OF_DECLARE(sun9i_a80_ahb1, "allwinner,sun9i-a80-ahb1-gates-clk",
>
>It seems that the other compatible strings are there for historical
>reasons. Why do you need a new one with such a specific name?
>
>It would have been more sensible to add a generic compatible string as
>"allwinner,apb-gates", letting the removal of the other strings for a
>later patch...

Seems like a good idea but is it possible to remove those binding in 
separate patch? I mean, wouldn't that, in theory, break ABI? Are such 
patches accepted?


From gregory.clement at free-electrons.com  Thu Feb  4 13:09:22 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu,  4 Feb 2016 22:09:22 +0100
Subject: [PATCH v3 net 0/7] mvneta fixes for SMP
Message-ID: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>

Hi,

Following this bug report:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/468173 and the
suggestions from Russell King, I reviewed all the code involving
multi-CPU. It ended with this series of patches which should improve
the stability of the driver.

During my test I found another bug which is fixed by new patch (the
second one of this new version of the series)

The two first patches fix real bugs, the others fix potential issues
in the driver.

Thanks,

Gregory

Changelog:

v1 -> v2
Fix spinlock comment. Pointed by David Miller

v2 -> v3
 - Fix typos and mistake in the comments. Pointed by Sergei Shtylyov
 - Add a new patch fixing the CPU choice in mvneta_percpu_elect
 - Use lock in last patch to prevent remaining race condition. Pointed
   by Jisheng

Gregory CLEMENT (7):
  net: mvneta: Fix for_each_present_cpu usage
  net: mvneta: Fix the CPU choice in mvneta_percpu_elect
  net: mvneta: Use on_each_cpu when possible
  net: mvneta: Remove unused code
  net: mvneta: Modify the queue related fields from each cpu
  net: mvneta: The mvneta_percpu_elect function should be atomic
  net: mvneta: Fix race condition during stopping

 drivers/net/ethernet/marvell/mvneta.c | 184 +++++++++++++++++++---------------
 1 file changed, 101 insertions(+), 83 deletions(-)

-- 
2.5.0



From gregory.clement at free-electrons.com  Thu Feb  4 13:09:23 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu,  4 Feb 2016 22:09:23 +0100
Subject: [PATCH v3 net 1/7] net: mvneta: Fix for_each_present_cpu usage
In-Reply-To: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454620169-8156-2-git-send-email-gregory.clement@free-electrons.com>

This patch convert the for_each_present in on_each_cpu, instead of
applying on the present cpus it will be applied only on the online cpus.
This fix a bug reported on
http://thread.gmane.org/gmane.linux.ports.arm.kernel/468173.

Using the macro on_each_cpu (instead of a for_each_* loop) also ensures
that all the calls will be done all at once.

Fixes: f86428854480 ("net: mvneta: Statically assign queues to CPUs")
Reported-by: Stefan Roese <stefan.roese at gmail.com>
Suggested-by: Jisheng Zhang <jszhang at marvell.com>
Suggested-by: Russell King <rmk+kernel at arm.linux.org.uk>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 662c2ee268c7..90ff5c7e19ea 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2564,7 +2564,7 @@ static void mvneta_start_dev(struct mvneta_port *pp)
 	mvneta_port_enable(pp);
 
 	/* Enable polling on the port */
-	for_each_present_cpu(cpu) {
+	for_each_online_cpu(cpu) {
 		struct mvneta_pcpu_port *port = per_cpu_ptr(pp->ports, cpu);
 
 		napi_enable(&port->napi);
@@ -2589,7 +2589,7 @@ static void mvneta_stop_dev(struct mvneta_port *pp)
 
 	phy_stop(pp->phy_dev);
 
-	for_each_present_cpu(cpu) {
+	for_each_online_cpu(cpu) {
 		struct mvneta_pcpu_port *port = per_cpu_ptr(pp->ports, cpu);
 
 		napi_disable(&port->napi);
@@ -3057,13 +3057,11 @@ err_cleanup_rxqs:
 static int mvneta_stop(struct net_device *dev)
 {
 	struct mvneta_port *pp = netdev_priv(dev);
-	int cpu;
 
 	mvneta_stop_dev(pp);
 	mvneta_mdio_remove(pp);
 	unregister_cpu_notifier(&pp->cpu_notifier);
-	for_each_present_cpu(cpu)
-		smp_call_function_single(cpu, mvneta_percpu_disable, pp, true);
+	on_each_cpu(mvneta_percpu_disable, pp, true);
 	free_percpu_irq(dev->irq, pp->ports);
 	mvneta_cleanup_rxqs(pp);
 	mvneta_cleanup_txqs(pp);
-- 
2.5.0



From gregory.clement at free-electrons.com  Thu Feb  4 13:09:26 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu,  4 Feb 2016 22:09:26 +0100
Subject: [PATCH v3 net 4/7] net: mvneta: Remove unused code
In-Reply-To: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454620169-8156-5-git-send-email-gregory.clement@free-electrons.com>

Since the commit 2dcf75e2793c ("net: mvneta: Associate RX queues with
each CPU") all the percpu irq are used and disabled at initialization, so
there is no point to disable them first.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index f496f9716569..74f8158df2b0 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3014,14 +3014,6 @@ static int mvneta_open(struct net_device *dev)
 		goto err_cleanup_txqs;
 	}
 
-	/* Even though the documentation says that request_percpu_irq
-	 * doesn't enable the interrupts automatically, it actually
-	 * does so on the local CPU.
-	 *
-	 * Make sure it's disabled.
-	 */
-	mvneta_percpu_disable(pp);
-
 	/* Enable per-CPU interrupt on all the CPU to handle our RX
 	 * queue interrupts
 	 */
-- 
2.5.0



From gregory.clement at free-electrons.com  Thu Feb  4 13:09:24 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu,  4 Feb 2016 22:09:24 +0100
Subject: [PATCH v3 net 2/7] net: mvneta: Fix the CPU choice in
 mvneta_percpu_elect
In-Reply-To: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454620169-8156-3-git-send-email-gregory.clement@free-electrons.com>

When passing to the management of multiple RX queue, the
mvneta_percpu_elect function was broken. The use of the modulo can lead
to elect the wrong cpu. For example with rxq_def=2, if the CPU 2 goes
offline and then online, we ended with the third RX queue activated in
the same time on CPU 0 and CPU2, which lead to a kernel crash.

With this fix, we don't try to get "the closer" CPU if the default CPU is
gone, now we just use CPU 0 which always be there. Thanks to this, the
code becomes more readable, easier to maintain and more predicable.

Cc: stable at vger.kernel.org
Fixes: 2dcf75e2793c ("net: mvneta: Associate RX queues with each CPU")
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 90ff5c7e19ea..4c2d12423750 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2849,9 +2849,14 @@ static void mvneta_percpu_disable(void *arg)
 
 static void mvneta_percpu_elect(struct mvneta_port *pp)
 {
-	int online_cpu_idx, max_cpu, cpu, i = 0;
+	int elected_cpu = 0, max_cpu, cpu, i = 0;
+
+	/* Use the cpu associated to the rxq when it is online, in all
+	 * the other cases, use the cpu 0 which can't be offline.
+	 */
+	if (cpu_online(pp->rxq_def))
+		elected_cpu = pp->rxq_def;
 
-	online_cpu_idx = pp->rxq_def % num_online_cpus();
 	max_cpu = num_present_cpus();
 
 	for_each_online_cpu(cpu) {
@@ -2862,7 +2867,7 @@ static void mvneta_percpu_elect(struct mvneta_port *pp)
 			if ((rxq % max_cpu) == cpu)
 				rxq_map |= MVNETA_CPU_RXQ_ACCESS(rxq);
 
-		if (i == online_cpu_idx)
+		if (cpu == elected_cpu)
 			/* Map the default receive queue queue to the
 			 * elected CPU
 			 */
@@ -2873,7 +2878,7 @@ static void mvneta_percpu_elect(struct mvneta_port *pp)
 		 * the CPU bound to the default RX queue
 		 */
 		if (txq_number == 1)
-			txq_map = (i == online_cpu_idx) ?
+			txq_map = (cpu == elected_cpu) ?
 				MVNETA_CPU_TXQ_ACCESS(1) : 0;
 		else
 			txq_map = mvreg_read(pp, MVNETA_CPU_MAP(cpu)) &
-- 
2.5.0



From gregory.clement at free-electrons.com  Thu Feb  4 13:09:25 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu,  4 Feb 2016 22:09:25 +0100
Subject: [PATCH v3 net 3/7] net: mvneta: Use on_each_cpu when possible
In-Reply-To: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454620169-8156-4-git-send-email-gregory.clement@free-electrons.com>

Instead of using a for_each_* loop in which we just call the
smp_call_function_single macro, it is more simple to directly use the
on_each_cpu macro. Moreover, this macro ensures that the calls will be
done all at once.

Suggested-by: Russell King <rmk+kernel at arm.linux.org.uk>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 4c2d12423750..f496f9716569 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2555,7 +2555,7 @@ static void mvneta_percpu_mask_interrupt(void *arg)
 
 static void mvneta_start_dev(struct mvneta_port *pp)
 {
-	unsigned int cpu;
+	int cpu;
 
 	mvneta_max_rx_size_set(pp, pp->pkt_size);
 	mvneta_txq_max_tx_size_set(pp, pp->pkt_size);
@@ -2571,9 +2571,8 @@ static void mvneta_start_dev(struct mvneta_port *pp)
 	}
 
 	/* Unmask interrupts. It has to be done from each CPU */
-	for_each_online_cpu(cpu)
-		smp_call_function_single(cpu, mvneta_percpu_unmask_interrupt,
-					 pp, true);
+	on_each_cpu(mvneta_percpu_unmask_interrupt, pp, true);
+
 	mvreg_write(pp, MVNETA_INTR_MISC_MASK,
 		    MVNETA_CAUSE_PHY_STATUS_CHANGE |
 		    MVNETA_CAUSE_LINK_CHANGE |
@@ -2993,7 +2992,7 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 static int mvneta_open(struct net_device *dev)
 {
 	struct mvneta_port *pp = netdev_priv(dev);
-	int ret, cpu;
+	int ret;
 
 	pp->pkt_size = MVNETA_RX_PKT_SIZE(pp->dev->mtu);
 	pp->frag_size = SKB_DATA_ALIGN(MVNETA_RX_BUF_SIZE(pp->pkt_size)) +
@@ -3026,9 +3025,7 @@ static int mvneta_open(struct net_device *dev)
 	/* Enable per-CPU interrupt on all the CPU to handle our RX
 	 * queue interrupts
 	 */
-	for_each_online_cpu(cpu)
-		smp_call_function_single(cpu, mvneta_percpu_enable,
-					 pp, true);
+	on_each_cpu(mvneta_percpu_enable, pp, true);
 
 
 	/* Register a CPU notifier to handle the case where our CPU
@@ -3315,9 +3312,7 @@ static int  mvneta_config_rss(struct mvneta_port *pp)
 
 	netif_tx_stop_all_queues(pp->dev);
 
-	for_each_online_cpu(cpu)
-		smp_call_function_single(cpu, mvneta_percpu_mask_interrupt,
-					 pp, true);
+	on_each_cpu(mvneta_percpu_mask_interrupt, pp, true);
 
 	/* We have to synchronise on the napi of each CPU */
 	for_each_online_cpu(cpu) {
-- 
2.5.0



From gregory.clement at free-electrons.com  Thu Feb  4 13:09:28 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu,  4 Feb 2016 22:09:28 +0100
Subject: [PATCH v3 net 6/7] net: mvneta: The mvneta_percpu_elect function
 should be atomic
In-Reply-To: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454620169-8156-7-git-send-email-gregory.clement@free-electrons.com>

Electing a CPU must be done in an atomic way: it should be done after or
before the removal/insertion of a CPU and this function is not reentrant.

During the loop of mvneta_percpu_elect we associates the queues to the
CPUs, if there is a topology change during this loop, then the mapping
between the CPUs and the queues could be wrong. During this loop the
interrupt mask is also updating for each CPUs, It should not be changed
in the same time by other part of the driver.

This patch adds spinlock to create the needed critical sections.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 2d0e8a605ca9..b12a745a0e4c 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -370,6 +370,10 @@ struct mvneta_port {
 	struct net_device *dev;
 	struct notifier_block cpu_notifier;
 	int rxq_def;
+	/* Protect the access to the percpu interrupt registers,
+	 * ensuring that the configuration remains coherent.
+	 */
+	spinlock_t lock;
 
 	/* Core clock */
 	struct clk *clk;
@@ -2855,6 +2859,12 @@ static void mvneta_percpu_elect(struct mvneta_port *pp)
 {
 	int elected_cpu = 0, max_cpu, cpu, i = 0;
 
+	/* Electing a CPU must be done in an atomic way: it should be
+	 * done after or before the removal/insertion of a CPU and
+	 * this function is not reentrant.
+	 */
+	spin_lock(&pp->lock);
+
 	/* Use the cpu associated to the rxq when it is online, in all
 	 * the other cases, use the cpu 0 which can't be offline.
 	 */
@@ -2898,6 +2908,7 @@ static void mvneta_percpu_elect(struct mvneta_port *pp)
 		i++;
 
 	}
+	spin_unlock(&pp->lock);
 };
 
 static int mvneta_percpu_notifier(struct notifier_block *nfb,
@@ -2952,8 +2963,13 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 	case CPU_DOWN_PREPARE:
 	case CPU_DOWN_PREPARE_FROZEN:
 		netif_tx_stop_all_queues(pp->dev);
+		/* Thanks to this lock we are sure that any pending
+		 * cpu election is done
+		 */
+		spin_lock(&pp->lock);
 		/* Mask all ethernet port interrupts */
 		on_each_cpu(mvneta_percpu_mask_interrupt, pp, true);
+		spin_unlock(&pp->lock);
 
 		napi_synchronize(&port->napi);
 		napi_disable(&port->napi);
-- 
2.5.0



From gregory.clement at free-electrons.com  Thu Feb  4 13:09:29 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu,  4 Feb 2016 22:09:29 +0100
Subject: [PATCH v3 net 7/7] net: mvneta: Fix race condition during stopping
In-Reply-To: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454620169-8156-8-git-send-email-gregory.clement@free-electrons.com>

When stopping the port, the CPU notifier are still there whereas the
mvneta_stop_dev function calls mvneta_percpu_disable() on each CPUs.
It was possible to have a new CPU coming at this point which could be
racy.

This patch adds a flag preventing executing the code notifier for a new
CPU when the port is stopping. It also uses the spinlock introduces
previously. To avoid the deadlock, the lock has been moved outside the
mvneta_percpu_elect function.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 36 +++++++++++++++++++++++++++--------
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index b12a745a0e4c..b0ae69f84493 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -374,6 +374,7 @@ struct mvneta_port {
 	 * ensuring that the configuration remains coherent.
 	 */
 	spinlock_t lock;
+	bool is_stopped;
 
 	/* Core clock */
 	struct clk *clk;
@@ -2855,16 +2856,14 @@ static void mvneta_percpu_disable(void *arg)
 	disable_percpu_irq(pp->dev->irq);
 }
 
+/* Electing a CPU must be done in an atomic way: it should be done
+ * after or before the removal/insertion of a CPU and this function is
+ * not reentrant.
+ */
 static void mvneta_percpu_elect(struct mvneta_port *pp)
 {
 	int elected_cpu = 0, max_cpu, cpu, i = 0;
 
-	/* Electing a CPU must be done in an atomic way: it should be
-	 * done after or before the removal/insertion of a CPU and
-	 * this function is not reentrant.
-	 */
-	spin_lock(&pp->lock);
-
 	/* Use the cpu associated to the rxq when it is online, in all
 	 * the other cases, use the cpu 0 which can't be offline.
 	 */
@@ -2908,7 +2907,6 @@ static void mvneta_percpu_elect(struct mvneta_port *pp)
 		i++;
 
 	}
-	spin_unlock(&pp->lock);
 };
 
 static int mvneta_percpu_notifier(struct notifier_block *nfb,
@@ -2922,6 +2920,14 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 	switch (action) {
 	case CPU_ONLINE:
 	case CPU_ONLINE_FROZEN:
+		spin_lock(&pp->lock);
+		/* Configuring the driver for a new CPU while the
+		 * driver is stopping is racy, so just avoid it.
+		 */
+		if (pp->is_stopped) {
+			spin_unlock(&pp->lock);
+			break;
+		}
 		netif_tx_stop_all_queues(pp->dev);
 
 		/* We have to synchronise on tha napi of each CPU
@@ -2959,6 +2965,7 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 			MVNETA_CAUSE_LINK_CHANGE |
 			MVNETA_CAUSE_PSC_SYNC_CHANGE);
 		netif_tx_start_all_queues(pp->dev);
+		spin_unlock(&pp->lock);
 		break;
 	case CPU_DOWN_PREPARE:
 	case CPU_DOWN_PREPARE_FROZEN:
@@ -2983,7 +2990,9 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 	case CPU_DEAD:
 	case CPU_DEAD_FROZEN:
 		/* Check if a new CPU must be elected now this on is down */
+		spin_lock(&pp->lock);
 		mvneta_percpu_elect(pp);
+		spin_unlock(&pp->lock);
 		/* Unmask all ethernet port interrupts */
 		on_each_cpu(mvneta_percpu_unmask_interrupt, pp, true);
 		mvreg_write(pp, MVNETA_INTR_MISC_MASK,
@@ -3027,7 +3036,7 @@ static int mvneta_open(struct net_device *dev)
 	 */
 	on_each_cpu(mvneta_percpu_enable, pp, true);
 
-
+	pp->is_stopped = false;
 	/* Register a CPU notifier to handle the case where our CPU
 	 * might be taken offline.
 	 */
@@ -3060,9 +3069,18 @@ static int mvneta_stop(struct net_device *dev)
 {
 	struct mvneta_port *pp = netdev_priv(dev);
 
+	/* Inform that we are stopping so we don't want to setup the
+	 * driver for new CPUs in the notifiers
+	 */
+	spin_lock(&pp->lock);
+	pp->is_stopped = true;
 	mvneta_stop_dev(pp);
 	mvneta_mdio_remove(pp);
 	unregister_cpu_notifier(&pp->cpu_notifier);
+	/* Now that the notifier are unregistered, we can release le
+	 * lock
+	 */
+	spin_unlock(&pp->lock);
 	on_each_cpu(mvneta_percpu_disable, pp, true);
 	free_percpu_irq(dev->irq, pp->ports);
 	mvneta_cleanup_rxqs(pp);
@@ -3333,7 +3351,9 @@ static int  mvneta_config_rss(struct mvneta_port *pp)
 	mvreg_write(pp, MVNETA_PORT_CONFIG, val);
 
 	/* Update the elected CPU matching the new rxq_def */
+	spin_lock(&pp->lock);
 	mvneta_percpu_elect(pp);
+	spin_unlock(&pp->lock);
 
 	/* We have to synchronise on the napi of each CPU */
 	for_each_online_cpu(cpu) {
-- 
2.5.0



From gregory.clement at free-electrons.com  Thu Feb  4 13:09:27 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu,  4 Feb 2016 22:09:27 +0100
Subject: [PATCH v3 net 5/7] net: mvneta: Modify the queue related fields from
 each cpu
In-Reply-To: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454620169-8156-6-git-send-email-gregory.clement@free-electrons.com>

In the MVNETA_INTR_* registers, the queues related fields are per cpu,
according to the datasheet (comment in [] are added by me):
"In a multi-CPU system, bits of RX[or TX] queues for which the access by
the reading[or writing] CPU is disabled are read as 0, and cannot be
cleared[or written]."

That means that each time we want to manipulate these bits we had to do
it on each cpu and not only on the current cpu.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/net/ethernet/marvell/mvneta.c | 100 ++++++++++++++++------------------
 1 file changed, 46 insertions(+), 54 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 74f8158df2b0..2d0e8a605ca9 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1038,6 +1038,43 @@ static void mvneta_set_autoneg(struct mvneta_port *pp, int enable)
 	}
 }
 
+static void mvneta_percpu_unmask_interrupt(void *arg)
+{
+	struct mvneta_port *pp = arg;
+
+	/* All the queue are unmasked, but actually only the ones
+	 * mapped to this CPU will be unmasked
+	 */
+	mvreg_write(pp, MVNETA_INTR_NEW_MASK,
+		    MVNETA_RX_INTR_MASK_ALL |
+		    MVNETA_TX_INTR_MASK_ALL |
+		    MVNETA_MISCINTR_INTR_MASK);
+}
+
+static void mvneta_percpu_mask_interrupt(void *arg)
+{
+	struct mvneta_port *pp = arg;
+
+	/* All the queue are masked, but actually only the ones
+	 * mapped to this CPU will be masked
+	 */
+	mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0);
+	mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0);
+	mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0);
+}
+
+static void mvneta_percpu_clear_intr_cause(void *arg)
+{
+	struct mvneta_port *pp = arg;
+
+	/* All the queue are cleared, but actually only the ones
+	 * mapped to this CPU will be cleared
+	 */
+	mvreg_write(pp, MVNETA_INTR_NEW_CAUSE, 0);
+	mvreg_write(pp, MVNETA_INTR_MISC_CAUSE, 0);
+	mvreg_write(pp, MVNETA_INTR_OLD_CAUSE, 0);
+}
+
 /* This method sets defaults to the NETA port:
  *	Clears interrupt Cause and Mask registers.
  *	Clears all MAC tables.
@@ -1055,14 +1092,10 @@ static void mvneta_defaults_set(struct mvneta_port *pp)
 	int max_cpu = num_present_cpus();
 
 	/* Clear all Cause registers */
-	mvreg_write(pp, MVNETA_INTR_NEW_CAUSE, 0);
-	mvreg_write(pp, MVNETA_INTR_OLD_CAUSE, 0);
-	mvreg_write(pp, MVNETA_INTR_MISC_CAUSE, 0);
+	on_each_cpu(mvneta_percpu_clear_intr_cause, pp, true);
 
 	/* Mask all interrupts */
-	mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0);
-	mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0);
-	mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0);
+	on_each_cpu(mvneta_percpu_mask_interrupt, pp, true);
 	mvreg_write(pp, MVNETA_INTR_ENABLE, 0);
 
 	/* Enable MBUS Retry bit16 */
@@ -2528,31 +2561,6 @@ static int mvneta_setup_txqs(struct mvneta_port *pp)
 	return 0;
 }
 
-static void mvneta_percpu_unmask_interrupt(void *arg)
-{
-	struct mvneta_port *pp = arg;
-
-	/* All the queue are unmasked, but actually only the ones
-	 * maped to this CPU will be unmasked
-	 */
-	mvreg_write(pp, MVNETA_INTR_NEW_MASK,
-		    MVNETA_RX_INTR_MASK_ALL |
-		    MVNETA_TX_INTR_MASK_ALL |
-		    MVNETA_MISCINTR_INTR_MASK);
-}
-
-static void mvneta_percpu_mask_interrupt(void *arg)
-{
-	struct mvneta_port *pp = arg;
-
-	/* All the queue are masked, but actually only the ones
-	 * maped to this CPU will be masked
-	 */
-	mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0);
-	mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0);
-	mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0);
-}
-
 static void mvneta_start_dev(struct mvneta_port *pp)
 {
 	int cpu;
@@ -2603,13 +2611,10 @@ static void mvneta_stop_dev(struct mvneta_port *pp)
 	mvneta_port_disable(pp);
 
 	/* Clear all ethernet port interrupts */
-	mvreg_write(pp, MVNETA_INTR_MISC_CAUSE, 0);
-	mvreg_write(pp, MVNETA_INTR_OLD_CAUSE, 0);
+	on_each_cpu(mvneta_percpu_clear_intr_cause, pp, true);
 
 	/* Mask all ethernet port interrupts */
-	mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0);
-	mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0);
-	mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0);
+	on_each_cpu(mvneta_percpu_mask_interrupt, pp, true);
 
 	mvneta_tx_reset(pp);
 	mvneta_rx_reset(pp);
@@ -2921,9 +2926,7 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 		}
 
 		/* Mask all ethernet port interrupts */
-		mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0);
-		mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0);
-		mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0);
+		on_each_cpu(mvneta_percpu_mask_interrupt, pp, true);
 		napi_enable(&port->napi);
 
 
@@ -2938,14 +2941,8 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 		 */
 		mvneta_percpu_elect(pp);
 
-		/* Unmask all ethernet port interrupts, as this
-		 * notifier is called for each CPU then the CPU to
-		 * Queue mapping is applied
-		 */
-		mvreg_write(pp, MVNETA_INTR_NEW_MASK,
-			MVNETA_RX_INTR_MASK(rxq_number) |
-			MVNETA_TX_INTR_MASK(txq_number) |
-			MVNETA_MISCINTR_INTR_MASK);
+		/* Unmask all ethernet port interrupts */
+		on_each_cpu(mvneta_percpu_unmask_interrupt, pp, true);
 		mvreg_write(pp, MVNETA_INTR_MISC_MASK,
 			MVNETA_CAUSE_PHY_STATUS_CHANGE |
 			MVNETA_CAUSE_LINK_CHANGE |
@@ -2956,9 +2953,7 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 	case CPU_DOWN_PREPARE_FROZEN:
 		netif_tx_stop_all_queues(pp->dev);
 		/* Mask all ethernet port interrupts */
-		mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0);
-		mvreg_write(pp, MVNETA_INTR_OLD_MASK, 0);
-		mvreg_write(pp, MVNETA_INTR_MISC_MASK, 0);
+		on_each_cpu(mvneta_percpu_mask_interrupt, pp, true);
 
 		napi_synchronize(&port->napi);
 		napi_disable(&port->napi);
@@ -2974,10 +2969,7 @@ static int mvneta_percpu_notifier(struct notifier_block *nfb,
 		/* Check if a new CPU must be elected now this on is down */
 		mvneta_percpu_elect(pp);
 		/* Unmask all ethernet port interrupts */
-		mvreg_write(pp, MVNETA_INTR_NEW_MASK,
-			MVNETA_RX_INTR_MASK(rxq_number) |
-			MVNETA_TX_INTR_MASK(txq_number) |
-			MVNETA_MISCINTR_INTR_MASK);
+		on_each_cpu(mvneta_percpu_unmask_interrupt, pp, true);
 		mvreg_write(pp, MVNETA_INTR_MISC_MASK,
 			MVNETA_CAUSE_PHY_STATUS_CHANGE |
 			MVNETA_CAUSE_LINK_CHANGE |
-- 
2.5.0



From ulf.hansson at linaro.org  Thu Feb  4 13:11:55 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 4 Feb 2016 22:11:55 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <Pine.LNX.4.44L0.1602041059070.1515-100000@iolanthe.rowland.org>
References: <CAPDyKFr3jqh5bDFOuKLgomhQ2P9+yN5Ps8E0CH8r-oOjvBuswg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602041059070.1515-100000@iolanthe.rowland.org>
Message-ID: <CAPDyKFpRnmn+h_VH3jtC3u-BOf7-00nbzD30omaxaaZOOAK8Gg@mail.gmail.com>

On 4 February 2016 at 17:04, Alan Stern <stern at rowland.harvard.edu> wrote:
> On Thu, 4 Feb 2016, Ulf Hansson wrote:
>
>> Just wanted to add yet some new findings while I was looking into this
>> regression.
>>
>> So, the reason why pm_runtime_put_sync() doesn't idle the device in
>> these cases, is because autosuspend is respected and for some reason
>> the autosuspend timer hasn't expired.
>
> No doubt the autosuspend delay is longer than the time it takes for a
> probe to fail.
>
>> I was wondering *why* the timer isn't considered as expired, because
>> the driver don't call pm_runtime_mark_last_busy() in the failing probe
>> case...
>>
>> Then I realized the following commit was merged a few releases ago,
>> which makes the runtime PM core to invoke pm_runtime_mark_last_busy()
>> for us.
>>
>> commit 56f487c78015936097474fd89b2ccb229d500d0f
>> Author: Tony Lindgren <tony at atomide.com>
>> Date:   Wed May 13 16:36:32 2015 -0700
>> PM / Runtime: Update last_busy in rpm_resume
>>
>> So, this commit actually causes the devices to stay active after a
>> failed probe attempt.
>>
>> I think it's a good idea to revert this change, but what to you think?
>
> I disagree.  The whole idea of autosuspend is to prevent the device's
> power state from bouncing up and down too rapidly.  This implies that
> whenever the device gets resumed, we should wait at least the minimum
> autosuspend delay before allowing the next autosuspend.

I am really not questioning the autosuspend feature at all, it's a
really great feature!

Now, I question the minor benefit we actually gain from having the
runtime PM core to update the mark in rpm_resume().

To me, the best decision when to update the mark is know by the
driver/subsystem for the device and not the core.

In most cases the mark will be updated after a request has been
completed, which leads to one unnecessary update at rpm_resume().

In this path (the resume), you really want to keep latencies to a
minimum and for sure not do unnecessary things.

>
> Perhaps you think that it's silly to behave that way in this case,
> because the device wasn't accessed at all during the time it was at
> full power.  That's a valid objection, but the proper solution is not
> to revert the 56f487c78015 commit.  Rather, change the driver to avoid
> doing a pm_runtime_resume_sync until you _know_ that the device will be
> accessed soon.

That's not always going to work.

Sometimes you need to access the device when trying to probe. Failing
later in probe, shows just *one* case where it doesn't make sense to
update the last busy mark. I suspect there may be other cases as well.

Of course one can always use runtime PM APIs which overrides the
autosuspend mode, so it's not a big deal.

Kind regards
Uffe


From eric at anholt.net  Thu Feb  4 13:14:28 2016
From: eric at anholt.net (Eric Anholt)
Date: Thu,  4 Feb 2016 13:14:28 -0800
Subject: [PATCH] irqchip: bcm2836: Drop extra memory barrier in SMP boot.
Message-ID: <1454620468-31303-1-git-send-email-eric@anholt.net>

The writel() immediately after this has a barrier, anyway.

Signed-off-by: Eric Anholt <eric at anholt.net>
---
 drivers/irqchip/irq-bcm2836.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index 963065a..b6e950d 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -229,7 +229,6 @@ int __init bcm2836_smp_boot_secondary(unsigned int cpu,
 	unsigned long secondary_startup_phys =
 		(unsigned long)virt_to_phys((void *)secondary_startup);
 
-	dsb();
 	writel(secondary_startup_phys,
 	       intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
 
-- 
2.7.0



From dmitry.torokhov at gmail.com  Thu Feb  4 13:18:42 2016
From: dmitry.torokhov at gmail.com (Dmitry Torokhov)
Date: Thu, 4 Feb 2016 13:18:42 -0800
Subject: [PATCH v2 2/3] Input: rotary-encoder - move configuration data
 to driver data
In-Reply-To: <20160203093527.GD13664@pengutronix.de>
References: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <1454408678-6011-3-git-send-email-u.kleine-koenig@pengutronix.de>
 <56B09CAB.5020600@zonque.org>
 <20160203093527.GD13664@pengutronix.de>
Message-ID: <20160204211842.GA40137@dtor-ws>

On Wed, Feb 03, 2016 at 10:35:27AM +0100, Uwe Kleine-K?nig wrote:
> Hello,
> 
> On Tue, Feb 02, 2016 at 01:10:19PM +0100, Daniel Mack wrote:
> > On 02/02/2016 11:24 AM, Uwe Kleine-K?nig wrote:
> > > This is a preparation for the next patche. There is no change in
> > > behaviour intended.
> > 
> > This one looks good to me, but it clashes with Dmitry's latest patch
> > sets (which I haven't found the time to test yet, sorry!).
> 
> There is nothing in next-20160203, so I assume Dmitry either fixes this
> up when applying my patches or tells me when I should rebase.

Please take a look at my rotary-encoder branch. I am waiting to merge it
into next until I can get some testers. If you have raumfild device that
would be awesome.

Thanks.

-- 
Dmitry


From olof at lixom.net  Thu Feb  4 13:24:04 2016
From: olof at lixom.net (Olof Johansson)
Date: Thu, 4 Feb 2016 13:24:04 -0800
Subject: [PATCH] ARM: nomadik: fix up SD/MMC DT settings
In-Reply-To: <1454332737-631-1-git-send-email-linus.walleij@linaro.org>
References: <1454332737-631-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <20160204212404.GA10600@localhost>

On Mon, Feb 01, 2016 at 02:18:57PM +0100, Linus Walleij wrote:
> The DTSI file for the Nomadik does not properly specify how the
> PL180 levelshifter is connected: the Nomadik actually needs all
> the five st,sig-dir-* flags set to properly control all lines out.
> 
> Further this board supports full power cycling of the card, and
> since this variant has no hardware clock gating, it needs a
> ridiculously low frequency setting to keep up with the ever
> overflowing FIFO.
> 
> The pin configuration set-up is a bit of a mystery, because of
> course these pins are a mix of inputs and outputs. However the
> reference implementation sets all pins to "output" with
> unspecified initial value, so let's do that here as well.
> 
> Cc: stable at vger.kernel.org
> Cc: Ulf Hansson <ulf.hansson at linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> ARM SoC folks: this fixes the non-working SD/MMC card on the
> Nomadik please apply this directly for fixes if Ulf is OK with
> it.

Thanks, applied.


-Olof


From olof at lixom.net  Thu Feb  4 13:25:31 2016
From: olof at lixom.net (Olof Johansson)
Date: Thu, 4 Feb 2016 13:25:31 -0800
Subject: [PATCH] ARM: multi_v7_defconfig: enable DW_WATCHDOG
In-Reply-To: <7htwlpb8j2.fsf@baylibre.com>
References: <1454518986-25953-1-git-send-email-dinguyen@opensource.altera.com>
 <7htwlpb8j2.fsf@baylibre.com>
Message-ID: <20160204212531.GA10933@localhost>

On Wed, Feb 03, 2016 at 04:53:37PM -0800, Kevin Hilman wrote:
> <dinguyen at opensource.altera.com> writes:
> 
> > From: Dinh Nguyen <dinguyen at opensource.altera.com>
> >
> > The watchdog timer on the SoCFPGA platform is the Synopsys Designware watchdog.
> > Enable CONFIG_DW_WATCHDOG for the driver to get built.
> >
> > Signed-off-by: Dinh Nguyen <dinguyen at opensource.altera.com>
> 
> Tested-by: Kevin Hilman <khilman at baylibre.com>
> 
> I confirm that this fixes the boot problems I was seeing on my socfpga
> board.

Thanks, applied to fixes.


-Olof


From stern at rowland.harvard.edu  Thu Feb  4 14:09:43 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Thu, 4 Feb 2016 17:09:43 -0500 (EST)
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFpRnmn+h_VH3jtC3u-BOf7-00nbzD30omaxaaZOOAK8Gg@mail.gmail.com>
Message-ID: <Pine.LNX.4.44L0.1602041702550.1515-100000@iolanthe.rowland.org>

On Thu, 4 Feb 2016, Ulf Hansson wrote:

> I am really not questioning the autosuspend feature at all, it's a
> really great feature!
> 
> Now, I question the minor benefit we actually gain from having the
> runtime PM core to update the mark in rpm_resume().

As Tony pointed out, it prevents some devices from going to sleep right 
away.

> To me, the best decision when to update the mark is know by the
> driver/subsystem for the device and not the core.
> 
> In most cases the mark will be updated after a request has been
> completed, which leads to one unnecessary update at rpm_resume().

Sure, but that update is a simple assignment statement.  It's about as 
cheap as you can get, short of doing nothing at all.

> In this path (the resume), you really want to keep latencies to a
> minimum and for sure not do unnecessary things.
> 
> >
> > Perhaps you think that it's silly to behave that way in this case,
> > because the device wasn't accessed at all during the time it was at
> > full power.  That's a valid objection, but the proper solution is not
> > to revert the 56f487c78015 commit.  Rather, change the driver to avoid
> > doing a pm_runtime_resume_sync until you _know_ that the device will be
> > accessed soon.
> 
> That's not always going to work.
> 
> Sometimes you need to access the device when trying to probe. Failing
> later in probe, shows just *one* case where it doesn't make sense to
> update the last busy mark. I suspect there may be other cases as well.

I don't follow your reasoning.  If you don't update the last_busy mark 
then the probe fails, the device goes to sleep immediately, and then 
wakes up again a fraction of a second later for another probe attempt 
(if the error was -EDEFER).  Thus you get an unnecessary suspend 
followed by an unnecessary resume.

If the error was something other than -EDEFER and there will be no more 
probes, then yes -- the device remains at full power for longer than 
necessary.  But how often does that happen?  In general, people have 
drivers that _do_ work with their devices.

> Of course one can always use runtime PM APIs which overrides the
> autosuspend mode, so it's not a big deal.

Or turn autosuspend off completely when you know you're not going to
want it any more.  True.

Alan Stern



From akpm at linux-foundation.org  Thu Feb  4 14:30:07 2016
From: akpm at linux-foundation.org (Andrew Morton)
Date: Thu, 4 Feb 2016 14:30:07 -0800
Subject: [PATCH v8] kernel: add kcov code coverage
In-Reply-To: <1454600441-70701-1-git-send-email-dvyukov@google.com>
References: <1454600441-70701-1-git-send-email-dvyukov@google.com>
Message-ID: <20160204143007.674a7e847b4c8fed957bba7c@linux-foundation.org>

On Thu,  4 Feb 2016 16:40:41 +0100 Dmitry Vyukov <dvyukov at google.com> wrote:

> kcov provides code coverage collection for coverage-guided fuzzing
> (randomized testing). Coverage-guided fuzzing is a testing technique
> that uses coverage feedback to determine new interesting inputs to a
> system. A notable user-space example is AFL
> (http://lcamtuf.coredump.cx/afl/). However, this technique is not
> widely used for kernel testing due to missing compiler and kernel
> support.
> 
> kcov does not aim to collect as much coverage as possible. It aims
> to collect more or less stable coverage that is function of syscall
> inputs. To achieve this goal it does not collect coverage in
> soft/hard interrupts and instrumentation of some inherently
> non-deterministic or non-interesting parts of kernel is disbled
> (e.g. scheduler, locking).
> 
> Currently there is a single coverage collection mode (tracing),
> but the API anticipates additional collection modes.
> Initially I also implemented a second mode which exposes
> coverage in a fixed-size hash table of counters (what Quentin
> used in his original patch). I've dropped the second mode for
> simplicity.
> 
> This patch adds the necessary support on kernel side.
> The complimentary compiler support was added in gcc revision 231296.
> 
> We've used this support to build syzkaller system call fuzzer,
> which has found 90 kernel bugs in just 2 months:
> https://github.com/google/syzkaller/wiki/Found-Bugs
> We've also found 30+ bugs in our internal systems with syzkaller.
> Another (yet unexplored) direction where kcov coverage would greatly
> help is more traditional "blob mutation". For example, mounting
> a random blob as a filesystem, or receiving a random blob over wire.
> 
> Why not gcov. Typical fuzzing loop looks as follows: (1) reset
> coverage, (2) execute a bit of code, (3) collect coverage, repeat.
> A typical coverage can be just a dozen of basic blocks (e.g. an
> invalid input). In such context gcov becomes prohibitively expensive
> as reset/collect coverage steps depend on total number of basic
> blocks/edges in program (in case of kernel it is about 2M). Cost of
> kcov depends only on number of executed basic blocks/edges. On top of
> that, kernel requires per-thread coverage because there are
> always background threads and unrelated processes that also produce
> coverage. With inlined gcov instrumentation per-thread coverage is not
> possible.
> 
> kcov exposes kernel PCs and control flow to user-space which
> is insecure. But debugfs should not be mapped as user accessible.

So the proposed user interface is ioctls against /sys/kernel/debug/kcov.

I guess that's OK.  We could just add sys_kcov() - syscalls are cheap
enough.  But we store state within the fd, don't we?  So sys_kcov()
would take an fd argument.

> Based on a patch by Quentin Casasnovas.
> Signed-off-by: Dmitry Vyukov <dvyukov at google.com>
> Reviewed-by: Kees Cook <keescook at chromium.org>
> ---
> Anticipating reasonable questions regarding usage of this feature.
> Quentin Casasnovas and Vegard Nossum also plan to use kcov for
> coverage-guided fuzzing. Currently they use a custom kernel patch
> for their fuzzer and found several dozens of bugs.
> There is also interest from Intel 0-DAY kernel test infrastructure.
> 
> ...
>
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1811,6 +1811,16 @@ struct task_struct {
>  	/* bitmask and counter of trace recursion */
>  	unsigned long trace_recursion;
>  #endif /* CONFIG_TRACING */
> +#ifdef CONFIG_KCOV
> +	/* Coverage collection mode enabled for this task (0 if disabled). */
> +	int		kcov_mode;

Should really be enum kcov_mode.  We could move it into <linux/kcov.h>:

--- a/include/linux/kcov.h~kernel-add-kcov-code-coverage-fix
+++ a/include/linux/kcov.h
@@ -10,6 +10,14 @@ struct task_struct;
 void kcov_task_init(struct task_struct *t);
 void kcov_task_exit(struct task_struct *t);
 
+enum kcov_mode {
+	/*
+	 * Tracing coverage collection mode.
+	 * Covered PCs are collected in a per-task buffer.
+	 */
+	KCOV_MODE_TRACE = 1,
+};
+
 #else
 
 static inline void kcov_task_init(struct task_struct *t) {}
--- a/include/linux/sched.h~kernel-add-kcov-code-coverage-fix
+++ a/include/linux/sched.h
@@ -51,6 +51,7 @@ struct sched_param {
 #include <linux/resource.h>
 #include <linux/timer.h>
 #include <linux/hrtimer.h>
+#include <linux/kcov.h>
 #include <linux/task_io_accounting.h>
 #include <linux/latencytop.h>
 #include <linux/cred.h>
@@ -1814,7 +1815,7 @@ struct task_struct {
 #endif /* CONFIG_TRACING */
 #ifdef CONFIG_KCOV
 	/* Coverage collection mode enabled for this task (0 if disabled). */
-	int		kcov_mode;
+	enum kcov_mode kcov_mode;
 	/* Size of the kcov_area. */
 	unsigned	kcov_size;
 	/* Buffer for coverage collection. */
--- a/kernel/kcov.c~kernel-add-kcov-code-coverage-fix
+++ a/kernel/kcov.c
@@ -13,14 +13,6 @@
 #include <linux/uaccess.h>
 #include <linux/kcov.h>
 
-enum kcov_mode {
-	/*
-	 * Tracing coverage collection mode.
-	 * Covered PCs are collected in a per-task buffer.
-	 */
-	KCOV_MODE_TRACE = 1,
-};
-
 /*
  * kcov descriptor (one per opened debugfs file).
  * State transitions of the descriptor:

>
> ...
>
> +/*
> + * kcov descriptor (one per opened debugfs file). 
> + * State transitions of the descriptor:
> + * - initial state after open()
> + * - then there must be a single ioctl(KCOV_INIT_TRACE) call
> + * - then, mmap() call (several calls are allowed but not useful)
> + * - then, repeated enable/disable for a task (only one task a time allowed)
> + */
> +struct kcov {
> + /*
> + * Reference counter.  We keep one for:
> + * - opened file descriptor
> + * - task with enabled coverage (we can't unwire it from another task)
> + */
> +	atomic_t rc;

"rc" usually means "return code".  Calling this "refcount" would cause
less surprise.

> +	/* The lock protects mode, size, area and t. */
> +	spinlock_t		lock;
> +	enum kcov_mode		mode;
> +	unsigned		size;
> +	void			*area;
> +	struct task_struct	*t;

Can we get some documentation in place for the above?  I find that
documenting the data structures is more valuable than documenting the
code.

> +};
> +
> +/*
> + * Entry point from instrumented code.
> + * This is called once per basic-block/edge.
> + */
> +void __sanitizer_cov_trace_pc(void)
> +{
> +	struct task_struct *t;
> +	enum kcov_mode mode;
> +
> +	t = current;
> +	/*
> +	 * We are interested in code coverage as a function of a syscall inputs,
> +	 * so we ignore code executed in interrupts.
> +	 */
> +	if (!t || in_interrupt())
> +		return;
> +	mode = READ_ONCE(t->kcov_mode);
> +	if (mode == KCOV_MODE_TRACE) {
> +		unsigned long *area;
> +		unsigned long pos;
> +
> +		/*
> +		 * There is some code that runs in interrupts but for which
> +		 * in_interrupt() returns false (e.g. preempt_schedule_irq()).
> +		 * READ_ONCE()/barrier() effectively provides load-acquire wrt
> +		 * interrupts, there are paired barrier()/WRITE_ONCE() in
> +		 * kcov_ioctl_locked().
> +		 */
> +		barrier();
> +		area = t->kcov_area;
> +		/* The first word is number of subsequent PCs. */
> +		pos = READ_ONCE(area[0]) + 1;
> +		if (likely(pos < t->kcov_size)) {
> +			area[pos] = _RET_IP_;
> +			WRITE_ONCE(area[0], pos);
> +		}
> +	}
> +}
> +EXPORT_SYMBOL(__sanitizer_cov_trace_pc);

Why is this exported to modules?  gcc emits the call?

>
> ...
>
> +static int kcov_mmap(struct file *filep, struct vm_area_struct *vma)
> +{
> +	int res = 0;
> +	void *area;
> +	struct kcov *kcov = vma->vm_file->private_data;
> +	unsigned long size, off;
> +	struct page *page;
> +
> +	area = vmalloc_user(vma->vm_end - vma->vm_start);
> +	if (!area)
> +		return -ENOMEM;
> +
> +	spin_lock(&kcov->lock);
> +	size = kcov->size * sizeof(unsigned long);
> +	if (kcov->mode == 0 || vma->vm_pgoff != 0 ||

kcov->mode has type `enum kcov_mode'.  We should hard-wire a zero in
here: neater to create KCOV_MODE_DISABLED or whatever?  In multiple
places.

> +	    vma->vm_end - vma->vm_start != size) {
> +		res = -EINVAL;
> +		goto exit;
> +	}
> +	if (!kcov->area) {
> +		kcov->area = area;
> +		vma->vm_flags |= VM_DONTEXPAND;
> +		spin_unlock(&kcov->lock);
> +		for (off = 0; off < size; off += PAGE_SIZE) {
> +			page = vmalloc_to_page(kcov->area + off);
> +			if (vm_insert_page(vma, vma->vm_start + off, page))
> +				WARN_ONCE(1, "vm_insert_page() failed");
> +		}
> +		return 0;
> +	}
> +exit:
> +	spin_unlock(&kcov->lock);
> +	vfree(area);
> +	return res;
> +}
> +
>
> ...
>
> +static int kcov_ioctl_locked(struct kcov *kcov, unsigned int cmd,
> +			     unsigned long arg)
> +{
> +	struct task_struct *t;
> +
> +	switch (cmd) {
> +	case KCOV_INIT_TRACE:
> +		/*
> +		 * Enable kcov in trace mode and setup buffer size.
> +		 * Must happen before anything else.
> +		 * Size must be at least 2 to hold current position and one PC.
> +		 */
> +		if (arg < 2 || arg > INT_MAX)
> +			return -EINVAL;
> +		if (kcov->mode != 0)
> +			return -EBUSY;
> +		kcov->mode = KCOV_MODE_TRACE;
> +		kcov->size = arg;

kcov->size comes in from userspace and later get multiplied by
sizeof(unsigned long).  This means that userspace can trigger math
overflows (on 32-bit if that happens) and havoc might ensue.  So can we
please get some better checks in place for `size'?

Also, move these checks (of `arg') so they immediately precede this
*usage* of `arg' so the reader can better see what's happening.

> +		return 0;
> +	case KCOV_ENABLE:
> +		/*
> +		 * Enable coverage for the current task.
> +		 * At this point user must have been enabled trace mode,
> +		 * and mmapped the file. Coverage collection is disabled only
> +		 * at task exit or voluntary by KCOV_DISABLE. After that it can
> +		 * be enabled for another task.
> +		 */
> +		if (arg != 0 || kcov->mode == 0 || kcov->area == NULL)
> +			return -EINVAL;

This reader doesn't know what is in "arg".  Documentation, please.  Or
copy `arg' into a suitably named local.

> +		if (kcov->t != NULL)
> +			return -EBUSY;
> +		t = current;
> +		/* Cache in task struct for performance. */
> +		t->kcov_size = kcov->size;
> +		t->kcov_area = kcov->area;
> +		/* See comment in __sanitizer_cov_trace_pc(). */
> +		barrier();
> +		WRITE_ONCE(t->kcov_mode, kcov->mode);
> +		t->kcov = kcov;
> +		kcov->t = t;
> +		/* This is put either in kcov_task_exit() or in KCOV_DISABLE. */
> +		kcov_get(kcov);

We didn't get a ref on the task_struct.  I guess that's OK because
task_struct.kcov gets torn down in kcov_task_exit().

But what happens if userspace simply closes the fd without running
KCOV_DISABLE?  ?

> +		return 0;
> +	case KCOV_DISABLE:
> +		/* Disable coverage for the current task. */
> +		if (arg != 0 || current->kcov != kcov)
> +			return -EINVAL;

This reader doesn't know what `arg' means.

> +		t = current;
> +		if (WARN_ON(kcov->t != t))
> +			return -EINVAL;
> +		kcov_task_init(t);
> +		kcov->t = NULL;
> +		kcov_put(kcov);
> +		return 0;
> +	default:
> +		return -EINVAL;

For reasons I don't recall, we conventionally return -ENOTTY for
unimplemented ioctl modes.  Alan Cox will remember ;)

http://www.makelinux.net/ldd3/chp-6-sect-1 says

: This error code is interpreted by the C library as "inappropriate ioctl
: for device," which is usually exactly what the programmer needs to
: hear.  It's still pretty common, though, to return -EINVAL in response
: to an invalid ioctl command.

> +	}
> +}
> +
> +static long kcov_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
> +{
> +	struct kcov *kcov;
> +	int res;
> +
> +	kcov = filep->private_data;
> +	spin_lock(&kcov->lock);
> +	res = kcov_ioctl_locked(kcov, cmd, arg);
> +	spin_unlock(&kcov->lock);
> +	return res;
> +}

Wait.  `unsigned long arg' is going to be a 32-bit quantity when a
32-bit executable is running on a 64-bit kernel.  Doesn't this ioctl
need compat handling?

>
> ...
>


From ulf.hansson at linaro.org  Thu Feb  4 14:34:28 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 4 Feb 2016 23:34:28 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <Pine.LNX.4.44L0.1602041702550.1515-100000@iolanthe.rowland.org>
References: <CAPDyKFpRnmn+h_VH3jtC3u-BOf7-00nbzD30omaxaaZOOAK8Gg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602041702550.1515-100000@iolanthe.rowland.org>
Message-ID: <CAPDyKFrMZYdeun67FBXdWL16DBOuO16qqOxRsks3QBJhNB8SoQ@mail.gmail.com>

On 4 February 2016 at 23:09, Alan Stern <stern at rowland.harvard.edu> wrote:
> On Thu, 4 Feb 2016, Ulf Hansson wrote:
>
>> I am really not questioning the autosuspend feature at all, it's a
>> really great feature!
>>
>> Now, I question the minor benefit we actually gain from having the
>> runtime PM core to update the mark in rpm_resume().
>
> As Tony pointed out, it prevents some devices from going to sleep right
> away.

Because their drivers don't care to update the last busy mark!?

>
>> To me, the best decision when to update the mark is know by the
>> driver/subsystem for the device and not the core.
>>
>> In most cases the mark will be updated after a request has been
>> completed, which leads to one unnecessary update at rpm_resume().
>
> Sure, but that update is a simple assignment statement.  It's about as
> cheap as you can get, short of doing nothing at all.

Valid point. I rest my case. :-)

Thanks for the discussion.

[...]

Kind regards
Uffe


From helgaas at kernel.org  Thu Feb  4 14:37:11 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Thu, 4 Feb 2016 16:37:11 -0600
Subject: [PATCH] PCI: layerscape: add ls2085a compatible
In-Reply-To: <56A906F4.3050809@linaro.org>
References: <1453915925-19198-1-git-send-email-yang.shi@linaro.org>
 <56A906F4.3050809@linaro.org>
Message-ID: <20160204223711.GE7031@localhost>

On Wed, Jan 27, 2016 at 10:05:40AM -0800, Shi, Yang wrote:
> Correct FSL folks email address to nxp.com, sorry for the inconvenience.

Do we need some MAINTAINERS updates in addition to the ack for this patch?
I see a bunch of @freescale.com addresses in MAINTAINERS.

> On 1/27/2016 9:32 AM, Yang Shi wrote:
> >The layerscape PCI host driver needs recognize ls2085a compatible when using
> >firmware with ls2085a compatible property, otherwise the PCI bus won't be
> >detected even though ls2085a compatible is included by the dts.
> >
> >Signed-off-by: Yang Shi <yang.shi at linaro.org>
> >---
> >  drivers/pci/host/pci-layerscape.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> >diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
> >index 3923bed..c40d8b2 100644
> >--- a/drivers/pci/host/pci-layerscape.c
> >+++ b/drivers/pci/host/pci-layerscape.c
> >@@ -203,6 +203,7 @@ static const struct of_device_id ls_pcie_of_match[] = {
> >  	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
> >  	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
> >  	{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
> >+	{ .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },
> >  	{ },
> >  };
> >  MODULE_DEVICE_TABLE(of, ls_pcie_of_match);
> >
> 


From soren.brinkmann at xilinx.com  Thu Feb  4 14:41:29 2016
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Thu, 4 Feb 2016 14:41:29 -0800
Subject: [RFC PATCH] ARM: clocksource: make ARM_GLOBAL_TIMER selectable
In-Reply-To: <1454610017-25499-1-git-send-email-grygorii.strashko@ti.com>
References: <1454610017-25499-1-git-send-email-grygorii.strashko@ti.com>
Message-ID: <20160204224128.GG4215@xsjsorenbubuntu>

On Thu, 2016-02-04 at 20:20:17 +0200, Grygorii Strashko wrote:
> This patch intended to fix following cases: 
> - SoC-A has ARM GT, defines DT node for ARM GT and selects ARM_GLOBAL_TIMER
> statically in Kconfig file. SoC-B has ARM GT and defines DT node for ARM GT,
> but do not selects ARM_GLOBAL_TIMER statically in Kconfig file. In case of
> multiplatform build ARM GT will be implicitly enabled for SoC-B.
> 
> - There is no way to disable ARM GT without modifying Kconfig file,
> once ARM_GLOBAL_TIMER is selected statically in Kconfig file.
> 
> Hence, fix above case by defining both HAVE_ARM_GLOBAL_TIMER and
> ARM_GLOBAL_TIMER as recommended by 'Adding common features and make
> the usage configurable' section in kconfig-language.txt. All places in
> ARM folder where ARM_GLOBAL_TIMER was used now replaced on
> HAVE_ARM_GLOBAL_TIMER.
> 
> Cc: Florian Fainelli <f.fainelli at gmail.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Wei Xu <xuwei5 at hisilicon.com>
> Cc: Shawn Guo <shawnguo at kernel.org>
> Cc: Sascha Hauer <kernel at pengutronix.de>
> Cc: Srinivas Kandagatla <srinivas.kandagatla at gmail.com>
> Cc: Maxime Coquelin <maxime.coquelin at st.com>
> Cc: Masahiro Yamada <yamada.masahiro at socionext.com>
> Cc: Liviu Dudau <liviu.dudau at arm.com>
> Cc: Sudeep Holla <sudeep.holla at arm.com>
> Cc: Jun Nie <jun.nie at linaro.org>
> Cc: Michal Simek <michal.simek at xilinx.com>
> Cc: "S?ren Brinkmann" <soren.brinkmann at xilinx.com>
> Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
> 
> Signed-off-by: Grygorii Strashko <grygorii.strashko at ti.com>
> ---
[...]
> diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
> index fd0aeeb..3165720 100644
> --- a/arch/arm/mach-zynq/Kconfig
> +++ b/arch/arm/mach-zynq/Kconfig
> @@ -5,7 +5,7 @@ config ARCH_ZYNQ
>  	select ARCH_SUPPORTS_BIG_ENDIAN
>  	select ARM_AMBA
>  	select ARM_GIC
> -	select ARM_GLOBAL_TIMER if !CPU_FREQ
> +	select HAVE_ARM_GLOBAL_TIMER if !CPU_FREQ

We actually have this issue, as we don't want to use GT when CPU_FREQ is
enabled. But with this change the 'if !CPU_FREQ' becomes obsolete.

Acked-by: S?ren Brinkmann <soren.brinkmann at xilinx.com>

	S?ren


From alexandre.belloni at free-electrons.com  Thu Feb  4 14:56:55 2016
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Thu, 4 Feb 2016 23:56:55 +0100
Subject: [rtc-linux] Re: [PATCH v4 00/10] rtc: max77686: Extend driver
 and add max77802 support
In-Reply-To: <56ADF9D4.2050208@samsung.com>
References: <1453865806-4661-1-git-send-email-javier@osg.samsung.com>
 <20160131120525.GM20165@piout.net> <56ADF9D4.2050208@samsung.com>
Message-ID: <20160204225655.GE4782@piout.net>

On 31/01/2016 at 21:11:00 +0900, Krzysztof Kozlowski wrote :
> W dniu 31.01.2016 o 21:05, Alexandre Belloni pisze:
> > Hi,
> > 
> > On 27/01/2016 at 00:36:36 -0300, Javier Martinez Canillas wrote :
> >> Hello,
> >>
> >> On a recent disussion [0] with Krzysztof Kozlowski and Laxman Dewangan,
> >> we came to the conclusion that the max77686 and max77802 RTC are almost
> >> the same with only a few differences so there shouldn't be two separate
> >> drivers and is better to extend max77686 driver and delete rtc-max77802.
> >>
> >> By making the driver more generic, other RTC IP blocks from Maxim PMICs
> >> could be supported as well like the max77620.
> >>
> >> This is a v4 of a series that do this, that address issues pointed out
> >> in the latest version. The v1, v2 and v3 can be found at [1], [2], [3].
> >>
> >> I've tested this patch-set on an Exynos5800 Peach Pi Chromebook that has
> >> a max77802 PMIC and the RTC was working correctly. Krzysztof Kozlowski
> >> tested v3 on an max77686 but this version only has cosmetic changes so
> >> it should not cause any functionality changes.
> >>
> >> [0]: http://www.spinics.net/lists/devicetree/msg110348.html
> >> [1]: https://lwn.net/Articles/672568/
> >> [2]: https://lkml.org/lkml/2016/1/25/767
> >> [3]: https://lkml.org/lkml/2016/1/26/787
> >>
> > 
> > I've applied patches 1 to 8 and I'll discussed with Arnd and Olof about
> > what I should do with the defconfig changes.
> 
> To avoid conflicts they could go through samsung-soc tree. I could pick
> them if you provide me a tag with rest of patchset (dependencies).
> 
> Would that be okay for you?
> 

Let's do that, I've prepared a tag, rtc-max77686-4.6 with all the
max77686 material collected until now.  If I need to rebase rtc-next,
I'll rebase on top of that.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From alexandre.belloni at free-electrons.com  Thu Feb  4 14:58:59 2016
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Thu, 4 Feb 2016 23:58:59 +0100
Subject: [PATCH 03/11] drivers: rtc: allow compilation of sun6i RTC for
 all sunxi SoCs
In-Reply-To: <1454348370-3816-4-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-4-git-send-email-andre.przywara@arm.com>
Message-ID: <20160204225859.GF4782@piout.net>

On 01/02/2016 at 17:39:22 +0000, Andre Przywara wrote :
> At the moment the "sun6i" RTC drivers depends on having two specific
> SoC families selected.
> The Allwinner A64 SoC has the same RTC, so extend the Kconfig option
> to allow inclusion of the driver for all Allwinner SoCs.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  drivers/rtc/Kconfig | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From robh at kernel.org  Thu Feb  4 15:08:14 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 4 Feb 2016 17:08:14 -0600
Subject: [PATCH v3 1/4] dt-bindings: power: reset: add document for
 reboot-mode driver
In-Reply-To: <1454407151-4751-1-git-send-email-andy.yan@rock-chips.com>
References: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
 <1454407151-4751-1-git-send-email-andy.yan@rock-chips.com>
Message-ID: <20160204230814.GA4847@rob-hp-laptop>

On Tue, Feb 02, 2016 at 05:59:11PM +0800, Andy Yan wrote:
> add device tree bindings document for reboot-mode driver
> 
> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
> 
> ---
> 
> Changes in v3:
> - descirbe all reboot mode as properity instead of subnode
> 
> Changes in v2: None
> Changes in v1: None
> 
>  .../bindings/power/reset/reboot-mode.txt           | 26 ++++++++++++++++
>  .../bindings/power/reset/syscon-reboot-mode.txt    | 36 ++++++++++++++++++++++
>  2 files changed, 62 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/reset/reboot-mode.txt
>  create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
> 
> diff --git a/Documentation/devicetree/bindings/power/reset/reboot-mode.txt b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
> new file mode 100644
> index 0000000..517080f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
> @@ -0,0 +1,26 @@
> +Generic reboot mode core map driver
> +
> +This driver get reboot mode arguments and call the write
> +interface to stores the magic value in special register
> +or ram . Then the bootloader can read it and take different
> +action according the argument stored.
> +
> +All mode properties are vendor specific, it is a indication to tell

The values should be vendor specific. The property names should not. We 
can allow vendor specific ones, but we need to have a common set.

> +the bootloder what to do when the system reboot, and should be named
> +as mode-xxx = <magic> (xxx is mode name).
> +
> +- mode-normal: Normal reboot mode, system reboot with command "reboot".
> +- mode-recovery: Android Recovery mode, it is a mode to format the device or update a new image.
> +- mode-fastboot: Android fastboot mode, it's a mode to  re-flash partitions on the device.
> +- mode-loader: A bootloader mode, it's a mode used to download image on Rockchip platform,
> +	       usually used in development.
> +- mode-maskrom: It's a mode to download bootloader on Rockchip platform.
> +
> +Example:
> +	reboot-mode {
> +		mode-normal = <BOOT_NORMAL>;
> +		mode-recovery = <BOOT_RECOVERY>;
> +		mode-fastboot = <BOOT_FASTBOOT>;

I tend to agree with John on calling this mode-bootloader.

OTOH, fastboot is more specific about what the mode is. The name in DT 
and the userspace name don't necessarily have to be the same.

> +		mode-loader = <BOOT_LOADER>;

This one needs a better name. Maybe it should be 'rockchip,mode-loader' 
as it is vendor specific. Either way, loader is vague. Perhaps 
rockchip,mode-bl-download?

> +		mode-maskrom = <BOOT_MASKROM>;

I think this should be "mode-rom-download".

> +	}
> diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
> new file mode 100644
> index 0000000..923c82b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
> @@ -0,0 +1,36 @@
> +SYSCON reboot mode driver
> +
> +This driver get reboot mode magic value form reboot-mode driver
> +and stores it in a SYSCON mapped register. Then the bootloader
> +can read it and take different action according to the magic
> +value stored.
> +
> +This DT node should be represented as a sub-node of a "syscon", "simple-mfd"
> +node.

Whether or not it is a simple-mfd or not depends on the syscon node.

> +
> +Required properties:
> +- compatible: should be "syscon-reboot-mode"
> +- offset: offset in the register map for the storage register (in bytes)
> +
> +Optional properity:
> +- mask: the mask bits of the mode magic value, default set to 0xffffffff if missing.
> +
> +The rest of the properties should follow the generic reboot-mode discription
> +found in reboot-mode.txt
> +
> +Example:
> +	pmu: pmu at 20004000 {
> +		compatible = "rockchip,rk3066-pmu", "syscon", "simple-mfd";
> +		reg = <0x20004000 0x100>;
> +
> +		reboot-mode {
> +			compatible = "syscon-reboot-mode";
> +			offset = <0x40>;
> +			mode-normal = <BOOT_NORMAL>;
> +			mode-recovery = <BOOT_RECOVERY>;
> +			mode-fastboot = <BOOT_FASTBOOT>;
> +			mode-loader = <BOOT_LOADER>;
> +			mode-maskrom = <BOOT_MASKROM>;
> +
> +		};
> +	};
> -- 
> 1.9.1
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From moritz.fischer at ettus.com  Thu Feb  4 15:14:47 2016
From: moritz.fischer at ettus.com (Moritz Fischer)
Date: Thu, 4 Feb 2016 15:14:47 -0800
Subject: [RFC PATCH] ARM: clocksource: make ARM_GLOBAL_TIMER selectable
In-Reply-To: <20160204224128.GG4215@xsjsorenbubuntu>
References: <1454610017-25499-1-git-send-email-grygorii.strashko@ti.com>
 <20160204224128.GG4215@xsjsorenbubuntu>
Message-ID: <CAAtXAHcV-9gXcZOX8dzUOBZUwj9M=O4MAsMCJNQYAP+os-D7Tg@mail.gmail.com>

Hi Soeren,

On Thu, Feb 4, 2016 at 2:41 PM, S?ren Brinkmann
<soren.brinkmann at xilinx.com> wrote:

> But with this change the 'if !CPU_FREQ' becomes obsolete.
I'm confused, could you explain that statement? You don't want people
accidentally running with GT when CPU_FREQ is on, right?

Patch looks good to me, FWIW:

Acked-by: Moritz Fischer <moritz.fischer at ettus.com>

Moritz


From soren.brinkmann at xilinx.com  Thu Feb  4 15:39:50 2016
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Thu, 4 Feb 2016 15:39:50 -0800
Subject: [RFC PATCH] ARM: clocksource: make ARM_GLOBAL_TIMER selectable
In-Reply-To: <CAAtXAHcV-9gXcZOX8dzUOBZUwj9M=O4MAsMCJNQYAP+os-D7Tg@mail.gmail.com>
References: <1454610017-25499-1-git-send-email-grygorii.strashko@ti.com>
 <20160204224128.GG4215@xsjsorenbubuntu>
 <CAAtXAHcV-9gXcZOX8dzUOBZUwj9M=O4MAsMCJNQYAP+os-D7Tg@mail.gmail.com>
Message-ID: <20160204233950.GH4215@xsjsorenbubuntu>

On Thu, 2016-02-04 at 15:14:47 -0800, Moritz Fischer wrote:
> Hi Soeren,
> 
> On Thu, Feb 4, 2016 at 2:41 PM, S?ren Brinkmann
> <soren.brinkmann at xilinx.com> wrote:
> 
> > But with this change the 'if !CPU_FREQ' becomes obsolete.
> I'm confused, could you explain that statement? You don't want people
> accidentally running with GT when CPU_FREQ is on, right?

Correct. But with this Kconfig rework you can just deselect it in
Kconfig. The generic HAVE_GT could always be selected.

	S?ren


From akshay.bhat at timesys.com  Thu Feb  4 15:41:07 2016
From: akshay.bhat at timesys.com (Akshay Bhat)
Date: Thu, 4 Feb 2016 18:41:07 -0500
Subject: [PATCH v7 3/7] ARM: dts: imx: Add Advantech BA-16 Qseven module
In-Reply-To: <20160203144051.GQ8307@tiger>
References: <1454109558-22800-1-git-send-email-akshay.bhat@timesys.com>
 <1454109558-22800-4-git-send-email-akshay.bhat@timesys.com>
 <20160203144051.GQ8307@tiger>
Message-ID: <56B3E193.8090603@timesys.com>



On 02/03/2016 09:40 AM, Shawn Guo wrote:
> On Fri, Jan 29, 2016 at 06:19:14PM -0500, Akshay Bhat wrote:
>> +&ssi1 {
>> +	fsl,mode = "i2s-master";
>
> In Documentation/devicetree/bindings/sound/fsl,ssi.txt, I do not see
> 'i2s-master' as a valid value for fsl,mode property.
>
> Shawn
>
Will fix this in the next rev (was copied over from an older kernel).

Is there a tool to find such errors (to help catch these errors before 
submitting it)?

Thanks,
Akshay

>> +	status = "okay";
>> +};


From john.stultz at linaro.org  Thu Feb  4 15:46:15 2016
From: john.stultz at linaro.org (John Stultz)
Date: Thu, 4 Feb 2016 15:46:15 -0800
Subject: [PATCH v3 1/4] dt-bindings: power: reset: add document for
 reboot-mode driver
In-Reply-To: <20160204230814.GA4847@rob-hp-laptop>
References: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
 <1454407151-4751-1-git-send-email-andy.yan@rock-chips.com>
 <20160204230814.GA4847@rob-hp-laptop>
Message-ID: <CALAqxLVyznpLd2MLgGr28TDECpLZ=RpmhxH-SHqntXfBsctcmQ@mail.gmail.com>

On Thu, Feb 4, 2016 at 3:08 PM, Rob Herring <robh at kernel.org> wrote:
> On Tue, Feb 02, 2016 at 05:59:11PM +0800, Andy Yan wrote:
>> add device tree bindings document for reboot-mode driver
>>
>> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
>>
>> ---
>>
>> Changes in v3:
>> - descirbe all reboot mode as properity instead of subnode
>>
>> Changes in v2: None
>> Changes in v1: None
>>
>>  .../bindings/power/reset/reboot-mode.txt           | 26 ++++++++++++++++
>>  .../bindings/power/reset/syscon-reboot-mode.txt    | 36 ++++++++++++++++++++++
>>  2 files changed, 62 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/power/reset/reboot-mode.txt
>>  create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
>>
>> diff --git a/Documentation/devicetree/bindings/power/reset/reboot-mode.txt b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
>> new file mode 100644
>> index 0000000..517080f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
>> @@ -0,0 +1,26 @@
>> +Generic reboot mode core map driver
>> +
>> +This driver get reboot mode arguments and call the write
>> +interface to stores the magic value in special register
>> +or ram . Then the bootloader can read it and take different
>> +action according the argument stored.
>> +
>> +All mode properties are vendor specific, it is a indication to tell
>
> The values should be vendor specific. The property names should not. We
> can allow vendor specific ones, but we need to have a common set.
>
>> +the bootloder what to do when the system reboot, and should be named
>> +as mode-xxx = <magic> (xxx is mode name).
>> +
>> +- mode-normal: Normal reboot mode, system reboot with command "reboot".
>> +- mode-recovery: Android Recovery mode, it is a mode to format the device or update a new image.
>> +- mode-fastboot: Android fastboot mode, it's a mode to  re-flash partitions on the device.
>> +- mode-loader: A bootloader mode, it's a mode used to download image on Rockchip platform,
>> +            usually used in development.
>> +- mode-maskrom: It's a mode to download bootloader on Rockchip platform.
>> +
>> +Example:
>> +     reboot-mode {
>> +             mode-normal = <BOOT_NORMAL>;
>> +             mode-recovery = <BOOT_RECOVERY>;
>> +             mode-fastboot = <BOOT_FASTBOOT>;
>
> I tend to agree with John on calling this mode-bootloader.
>
> OTOH, fastboot is more specific about what the mode is. The name in DT
> and the userspace name don't necessarily have to be the same.

Wait. This is a bit confusing. The utility of adding a property name
and using that name be the reboot command parsed for made sense
(compared to earlier versions which had command strings) as it made
the dts more terse.   But it sounds here like you're suggesting we
should have some logic in the driver that translates "reboot fastboot"
to mode-bootloader or vice versa.

>> +             mode-loader = <BOOT_LOADER>;
>
> This one needs a better name. Maybe it should be 'rockchip,mode-loader'
> as it is vendor specific. Either way, loader is vague. Perhaps
> rockchip,mode-bl-download?

Hrm. So how what reboot command do you expect to trigger that?

Though I do like the vendor specific prefix here, as it clarifies how
universal the command is (and its easy add standard commands if they
become more established and remap things in the future).

>
>> +             mode-maskrom = <BOOT_MASKROM>;
>
> I think this should be "mode-rom-download".

I think one of the difficult things here is that there's no real
standards for all bios/bootloader modes. So they are somewhat
firmware/bootloader/device specific, and thus we need something that
is flexible enough to allow lots of different modes to be easily
specified.  That said, this does expose a userspace interface (though
one could argue kernel ABI doesn't cross reboots :) so we should try
to have some consistency so the same userspace can work on various
devices.

I do think the "bootloader" and "recovery" arguments are somewhat
defacto standards, well established on most android devices.

I think here the concern is rockchip probably has some userspace that
is already using "reboot maskrom" or "reboot loader" for their own
uses. And its a bit of a pain to ask that userspace to be reworked to
use "reboot rom-download" or "reboot rockchip,rom-download" depending
on how we try to deal with these.  (Granted, non-upstream interfaces
aren't official, so that is their risk somewhat, but we avoid being
smug about that :)

Another part of the issue is there isn't really a way to probe for
reboot cmd capability here. As much as I'd rather not complicate
things, one couldn't easily extend existing userspace to work with
current kernels as well as future kernels, since the reboot with an
invalid command won't fail. The machine still resets. So you can't try
one and fallback to the other.

Maybe there needs to be a sysfs entry with the list of the supported commands?

thanks
-john


From yang.shi at linaro.org  Thu Feb  4 15:49:26 2016
From: yang.shi at linaro.org (Shi, Yang)
Date: Thu, 4 Feb 2016 15:49:26 -0800
Subject: [PATCH] PCI: layerscape: add ls2085a compatible
In-Reply-To: <20160204223711.GE7031@localhost>
References: <1453915925-19198-1-git-send-email-yang.shi@linaro.org>
 <56A906F4.3050809@linaro.org> <20160204223711.GE7031@localhost>
Message-ID: <56B3E386.8010002@linaro.org>

On 2/4/2016 2:37 PM, Bjorn Helgaas wrote:
> On Wed, Jan 27, 2016 at 10:05:40AM -0800, Shi, Yang wrote:
>> Correct FSL folks email address to nxp.com, sorry for the inconvenience.
>
> Do we need some MAINTAINERS updates in addition to the ack for this patch?
> I see a bunch of @freescale.com addresses in MAINTAINERS.

I guess so if the @freescale.com address is not valid anymore.

Thanks,
Yang

>
>> On 1/27/2016 9:32 AM, Yang Shi wrote:
>>> The layerscape PCI host driver needs recognize ls2085a compatible when using
>>> firmware with ls2085a compatible property, otherwise the PCI bus won't be
>>> detected even though ls2085a compatible is included by the dts.
>>>
>>> Signed-off-by: Yang Shi <yang.shi at linaro.org>
>>> ---
>>>   drivers/pci/host/pci-layerscape.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
>>> index 3923bed..c40d8b2 100644
>>> --- a/drivers/pci/host/pci-layerscape.c
>>> +++ b/drivers/pci/host/pci-layerscape.c
>>> @@ -203,6 +203,7 @@ static const struct of_device_id ls_pcie_of_match[] = {
>>>   	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
>>>   	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
>>>   	{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
>>> +	{ .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },
>>>   	{ },
>>>   };
>>>   MODULE_DEVICE_TABLE(of, ls_pcie_of_match);
>>>
>>



From akshay.bhat at timesys.com  Thu Feb  4 15:57:44 2016
From: akshay.bhat at timesys.com (Akshay Bhat)
Date: Thu, 4 Feb 2016 18:57:44 -0500
Subject: [PATCH v7 4/7] ARM: dts: imx: Add support for Advantech/GE Bx50v3
In-Reply-To: <20160203145256.GR8307@tiger>
References: <1454109558-22800-1-git-send-email-akshay.bhat@timesys.com>
 <1454109558-22800-5-git-send-email-akshay.bhat@timesys.com>
 <20160203145256.GR8307@tiger>
Message-ID: <56B3E578.2080209@timesys.com>



On 02/03/2016 09:52 AM, Shawn Guo wrote:
> On Fri, Jan 29, 2016 at 06:19:15PM -0500, Akshay Bhat wrote:
>> From: Justin Waters <justin.waters at timesys.com>
>>
>> Advantech has 3 carrier boards (B450v3, B650v3, B850v3) which use
>> the Advantech BA-16 module (based on iMX6D). This file has the
>> devicetree entries that are common to all 3 boards.
>>
>> Signed-off-by: Akshay Bhat <akshay.bhat at timesys.com>
>> Signed-off-by: Justin Waters <justin.waters at timesys.com>
>> ---
>>   arch/arm/boot/dts/imx6q-bx50v3.dtsi | 239 ++++++++++++++++++++++++++++++++++++
>>   1 file changed, 239 insertions(+)
>>   create mode 100644 arch/arm/boot/dts/imx6q-bx50v3.dtsi
>>
>> diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
>> new file mode 100644
>> index 0000000..a44b074
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
>> @@ -0,0 +1,239 @@
>> +/*
>> + * Copyright 2015 Timesys Corporation.
>> + * Copyright 2015 General Electric Company
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This file is free software; you can redistribute it and/or
>> + *     modify it under the terms of the GNU General Public License
>> + *     version 2 as published by the Free Software Foundation.
>> + *
>> + *     This file is distributed in the hope that it will be useful
>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *     GNU General Public License for more details.
>> + *
>> + * Or, alternatively
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + *     obtaining a copy of this software and associated documentation
>> + *     files (the "Software"), to deal in the Software without
>> + *     restriction, including without limitation the rights to use
>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>> + *     sell copies of the Software, and to permit persons to whom the
>> + *     Software is furnished to do so, subject to the following
>> + *     conditions:
>> + *
>> + *     The above copyright notice and this permission notice shall be
>> + *     included in all copies or substantial portions of the Software.
>> + *
>> + *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + *     OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +#include "imx6q-ba16.dtsi"
>> +
>> +/ {
>> +	clocks {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>
> These are already specified in imx6qdl.dtsi.
>

Will fix this. Once it is removed, should I have a new line before the 
child node?
eg:

clocks {

	mclk: clock at 0 {
		compatible = "fixed-clock";
>> +
>> +		mclk: clock at 0 {
>> +			compatible = "fixed-clock";
>> +			reg = <0>;
>> +			#clock-cells = <0>;
>> +			clock-frequency = <22000000>;
>> +		};
>> +	};
>
> <snip>
>
>> +&i2c1 {
>> +	pca9547: mux at 70 {
>> +		compatible = "nxp,pca9547";
>> +		reg = <0x70>;
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		mux1_i2c1: i2c at 0 {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <0x0>;
>> +
>> +			ads7830: ads7830 at 48 {
>> +				compatible = "ti,ads7830";
>> +				reg = <0x48>;
>> +			};
>> +
>> +			mma8453: mma8453 at 1c {
>> +				compatible = "fsl,mma8453";
>> +				reg = <0x1c>;
>> +			};
>> +		};
>> +
>> +		mux1_i2c2: i2c at 1 {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <0x1>;
>> +
>> +			eeprom: eeprom at 50 {
>> +				compatible = "atmel,24c08";
>> +				reg = <0x50>;
>> +			};
>> +
>> +			mpl3115: mpl3115 at 60 {
>> +				compatible = "fsl,mpl3115";
>> +				reg = <0x60>;
>> +			};
>> +		};
>> +
>> +		mux1_i2c3: i2c at 2 {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <0x2>;
>> +		};
>> +
>> +		mux1_i2c4: i2c at 3 {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +			reg = <0x3>;
>> +
>> +			codec: sgtl5000 at 0a {
>
> I think the naming schema below matches DT convention better, i.e. the
> node name should be generic.
>
> 			sgtl5000: codec at 0a {
>

Will update the naming.

>> +				compatible = "fsl,sgtl5000";
>> +				reg = <0x0a>;
>> +				clocks = <&mclk>;
>> +				VDDA-supply = <&reg_1p8v>;
>> +				VDDIO-supply = <&reg_3p3v>;
>> +			};
>> +		};
>
> <snip>
>
>> +&usdhc4 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pinctrl_usdhc4>;
>> +	bus-width = <4>;
>> +	vmmc-supply = <&reg_wl18xx_vmmc>;
>> +	no-1-8-v;
>> +	non-removable;
>> +	wakeup-source;
>> +	keep-power-in-suspend;
>> +	cap-power-off-card;
>> +	max-frequency = <25000000>;
>> +	status = "okay";
>> +
>
> Drop this new line and have 'status' be the last property.
>

Will update the same.

>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>
> I'm not sure why this and a 'reg' property in sub-nodes are necessary at
> all, but ...
>

Most other devicetrees that use ti wlcore had the above properties along 
with a 'reg' property in the sub-node. So I used them as reference. 
Since there is a single child node here, is it preferred to change this to:

&usdhc4 {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_usdhc4>;
	bus-width = <4>;
	vmmc-supply = <&reg_wl18xx_vmmc>;
	no-1-8-v;
	non-removable;
	wakeup-source;
	keep-power-in-suspend;
	cap-power-off-card;
	max-frequency = <25000000>;
	status = "okay";

	wlcore {
		compatible = "ti,wl1837";
		interrupt-parent = <&gpio2>;
		interrupts = <6 IRQ_TYPE_LEVEL_HIGH>;
		tcxo-clock-frequency = <26000000>;
	};	
};

>> +
>> +	wlcore: wlcore at 0 {
>> +		compatible = "ti,wl1837";
>> +		reg = <2>;
>
> ... at least the 'reg' property should match the unit-address after node
> name.
>
> Shawn
>
Will fix this.

Thanks,
Akshay

>> +		interrupt-parent = <&gpio2>;
>> +		interrupts = <6 IRQ_TYPE_LEVEL_HIGH>;
>> +		tcxo-clock-frequency = <26000000>;
>> +	};
>> +};
>> --
>> 2.7.0
>>
>>


From helgaas at kernel.org  Thu Feb  4 16:04:52 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Thu, 4 Feb 2016 18:04:52 -0600
Subject: [PATCH v4 2/2] pci, pci-thunder-pem: Add PCIe host driver for
 ThunderX processors.
In-Reply-To: <1453844781-24380-3-git-send-email-ddaney.cavm@gmail.com>
References: <1453844781-24380-1-git-send-email-ddaney.cavm@gmail.com>
 <1453844781-24380-3-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <20160205000452.GI7031@localhost>

Hi David,

Looks good, a few trival questions below.

On Tue, Jan 26, 2016 at 01:46:21PM -0800, David Daney wrote:
> From: David Daney <david.daney at cavium.com>
> 
> Some Cavium ThunderX processors require quirky access methods for the
> config space of the PCIe bridge.  Add a driver to provide these config
> space accessor functions.  The pci-host-common code is used to
> configure the PCI machinery.
> 
> Signed-off-by: David Daney <david.daney at cavium.com>
> Acked-by: Rob Herring <robh at kernel.org>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  .../devicetree/bindings/pci/pci-thunder-pem.txt    |  43 ++++
>  MAINTAINERS                                        |   8 +
>  drivers/pci/host/Kconfig                           |   7 +
>  drivers/pci/host/Makefile                          |   1 +
>  drivers/pci/host/pci-thunder-pem.c                 | 283 +++++++++++++++++++++

What's the significance of the "pem" part of the name?  I'm wondering
if we can shorten the filenames and function names by dropping it and
referring to this simply as "thunder" or "thunderx".

>  5 files changed, 342 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-pem.txt
>  create mode 100644 drivers/pci/host/pci-thunder-pem.c
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci-thunder-pem.txt b/Documentation/devicetree/bindings/pci/pci-thunder-pem.txt
> new file mode 100644
> index 0000000..f131fae
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/pci-thunder-pem.txt
> @@ -0,0 +1,43 @@
> +* ThunderX PEM PCIe host controller
> +
> +Firmware-initialized PCI host controller found on some Cavium
> +ThunderX processors.
> +
> +The properties and their meanings are identical to those described in
> +host-generic-pci.txt except as listed below.
> +
> +Properties of the host controller node that differ from
> +host-generic-pci.txt:
> +
> +- compatible     : Must be "cavium,pci-host-thunder-pem"
> +
> +- reg            : Two entries: First the configuration space for down
> +                   stream devices base address and size, as accessed
> +                   from the parent bus. Second, the register bank of
> +                   the PEM device PCIe bridge.
> +
> +Example:
> +
> +    pci at 87e0,c2000000 {
> +	compatible = "cavium,pci-host-thunder-pem";
> +	device_type = "pci";
> +	msi-parent = <&its>;
> +	msi-map = <0 &its 0x10000 0x10000>;
> +	bus-range = <0x8f 0xc7>;
> +	#size-cells = <2>;
> +	#address-cells = <3>;
> +
> +	reg = <0x8880 0x8f000000 0x0 0x39000000>,  /* Configuration space */
> +	      <0x87e0 0xc2000000 0x0 0x00010000>; /* PEM space */
> +	ranges = <0x01000000 0x00 0x00020000 0x88b0 0x00020000 0x00 0x00010000>, /* I/O */
> +		 <0x03000000 0x00 0x10000000 0x8890 0x10000000 0x0f 0xf0000000>, /* mem64 */
> +		 <0x43000000 0x10 0x00000000 0x88a0 0x00000000 0x10 0x00000000>, /* mem64-pref */
> +		 <0x03000000 0x87e0 0xc2f00000 0x87e0 0xc2000000 0x00 0x00100000>; /* mem64 PEM BAR4 */
> +
> +	#interrupt-cells = <1>;
> +	interrupt-map-mask = <0 0 0 7>;
> +	interrupt-map = <0 0 0 1 &gic0 0 0 0 24 4>, /* INTA */
> +			<0 0 0 2 &gic0 0 0 0 25 4>, /* INTB */
> +			<0 0 0 3 &gic0 0 0 0 26 4>, /* INTC */
> +			<0 0 0 4 &gic0 0 0 0 27 4>; /* INTD */
> +    };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 73c5bde..1aa8f82 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8419,6 +8419,14 @@ L:     linux-arm-msm at vger.kernel.org
>  S:     Maintained
>  F:     drivers/pci/host/*qcom*
>  
> +PCIE DRIVER FOR CAVIUM THUNDERX
> +M:	David Daney <david.daney at cavium.com>
> +L:	linux-pci at vger.kernel.org
> +L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +S:	Supported
> +F:	Documentation/devicetree/bindings/pci/pci-thunder-*
> +F:	drivers/pci/host/pci-thunder-*
> +
>  PCMCIA SUBSYSTEM
>  P:	Linux PCMCIA Team
>  L:	linux-pcmcia at lists.infradead.org
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 65709b4..184df22 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -195,4 +195,11 @@ config PCIE_QCOM
>  	  PCIe controller uses the Designware core plus Qualcomm-specific
>  	  hardware wrappers.
>  
> +config PCI_HOST_THUNDER_PEM
> +	bool "Cavium Thunder PCIe controller to off-chip devices"
> +	depends on OF && ARM64
> +	select PCI_HOST_COMMON
> +	help
> +	  Say Y here if you want PCIe support for CN88XX Cavium Thunder SoCs.
> +
>  endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 3b24af8..8903172 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -23,3 +23,4 @@ obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
>  obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
>  obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
>  obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
> +obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
> diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
> new file mode 100644
> index 0000000..43fa6f5
> --- /dev/null
> +++ b/drivers/pci/host/pci-thunder-pem.c
> @@ -0,0 +1,283 @@
> +/*
> + * 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/>.
> + *
> + * Copyright (C) 2015 Cavium, Inc.
> + *
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_pci.h>
> +#include <linux/platform_device.h>
> +
> +#include "pci-host-common.h"
> +
> +#define PEM_CFG_WR 0x28
> +#define PEM_CFG_RD 0x30
> +
> +struct thunder_pem_pci {
> +	struct gen_pci	gen_pci;
> +	u32		ea_entry[3];
> +	void __iomem	*pem_reg_base;
> +};
> +
> +static int thunder_pem_config_read(struct pci_bus *bus, unsigned int devfn,
> +				   int where, int size, u32 *val)
> +{
> +	int r;
> +	struct thunder_pem_pci *pem_pci;
> +	struct gen_pci *pci = bus->sysdata;
> +
> +	pem_pci = container_of(pci, struct thunder_pem_pci, gen_pci);
> +
> +	/*
> +	 * The first device on the bus in the PEM PCIe bridge.
> +	 * Special case its config access.
> +	 */
> +	if (bus->number == pci->cfg.bus_range->start) {
> +		u64 read_val;
> +
> +		if (devfn != 0 || where >= 2048) {
> +			*val = ~0;
> +			return PCIBIOS_DEVICE_NOT_FOUND;
> +		}
> +
> +		/*
> +		 * 32-bit accesses only.  Write the address to the low
> +		 * order bits of PEM_CFG_RD, then trigger the read by
> +		 * reading back.  The config data lands in the upper
> +		 * 32-bits of PEM_CFG_RD.
> +		 */
> +		read_val = where & ~3ull;
> +		writeq(read_val, pem_pci->pem_reg_base + PEM_CFG_RD);
> +		read_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
> +		read_val >>= 32;
> +
> +		/*
> +		 * The config space contains some garbage, fix it up.
> +		 * Also synthesize an EA capability for the BAR used
> +		 * by MSI-X.
> +		 */
> +		switch (where & ~3u) {
> +		case 0x40:
> +			read_val &= 0xffff00ff;
> +			read_val |= 0x00007000; /* Skip MSI CAP */
> +			break;
> +		case 0x70: /* Express Cap */
> +			/* PME interrupt on vector 2*/
> +			read_val |= (2u << 25);
> +			break;
> +		case 0xb0: /* MSI-X Cap */
> +			/* TableSize=4, Next Cap is EA */
> +			read_val &= 0xc00000ff;
> +			read_val |= 0x0003bc00;
> +			break;
> +		case 0xb4:
> +			/* Table offset=0, BIR=0 */
> +			read_val = 0x00000000;
> +			break;
> +		case 0xb8:
> +			/* BPA offset=0xf0000, BIR=0 */
> +			read_val = 0x000f0000;
> +			break;
> +		case 0xbc:
> +			/* EA, 1 entry, no next Cap */
> +			read_val = 0x00010014;
> +			break;
> +		case 0xc0:
> +			/* DW2 for type-1 */
> +			read_val = 0x00000000;
> +			break;
> +		case 0xc4:
> +			/* Entry BEI=0, PP=0x00, SP=0xff, ES=3 */
> +			read_val = 0x80ff0003;
> +			break;
> +		case 0xc8:
> +			read_val = pem_pci->ea_entry[0];
> +			break;
> +		case 0xcc:
> +			read_val = pem_pci->ea_entry[1];
> +			break;
> +		case 0xd0:
> +			read_val = pem_pci->ea_entry[2];
> +			break;
> +		default:
> +			break;
> +		}
> +		read_val >>= (8 * (where & 3));
> +		switch (size) {
> +		case 1:
> +			read_val &= 0xff;
> +			break;
> +		case 2:
> +			read_val &= 0xffff;
> +			break;
> +		default:
> +			break;
> +		}
> +		*val = read_val;
> +		return PCIBIOS_SUCCESSFUL;
> +	}
> +	if (bus->number < pci->cfg.bus_range->start ||
> +	    bus->number > pci->cfg.bus_range->end)
> +		return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +	r = pci_generic_config_read(bus, devfn, where, size, val);
> +	return r;
> +}
> +
> +static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
> +				    int where, int size, u32 val)
> +{
> +	struct gen_pci *pci = bus->sysdata;
> +	struct thunder_pem_pci *pem_pci;
> +
> +	pem_pci = container_of(pci, struct thunder_pem_pci, gen_pci);
> +
> +	/*
> +	 * The first device on the bus in the PEM PCIe bridge.
> +	 * Special case its config access.
> +	 */
> +	if (bus->number == pci->cfg.bus_range->start) {
> +		u64 write_val, read_val;
> +
> +		if (devfn != 0 || where >= 2048)
> +			return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +		/*
> +		 * 32-bit accesses only.  If the write is for a size
> +		 * smaller than 32-bits, we must first read the 32-bit
> +		 * value and merge in the desired bits and then write
> +		 * the whole 32-bits back out.
> +		 */

Ugh.  Another device that only supports 32-bit writes.  I guess this
only affects this single device, and maybe you "know" that it has no
registers where RW1C bits may be corrupted.  Although I suppose this
device has the standard status registers (Status at 0x06, Secondary
Status at 0x1e, Device Status in PCIe capability, etc.), which do
contain RW1C bits.

We need to print a warning at probe-time so we know to consider the
possibility of corruption when debugging.

> +		switch (size) {
> +		case 1:
> +			read_val = where & ~3ull;
> +			writeq(read_val, pem_pci->pem_reg_base + PEM_CFG_RD);
> +			read_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
> +			read_val >>= 32;
> +			read_val &= ~(0xff << (8 * (where & 3)));
> +			val = (val & 0xff) << (8 * (where & 3));
> +			val |= (u32)read_val;
> +			break;
> +		case 2:
> +			read_val = where & ~3ull;
> +			writeq(read_val, pem_pci->pem_reg_base + PEM_CFG_RD);
> +			read_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
> +			read_val >>= 32;
> +			read_val &= ~(0xffff << (8 * (where & 3)));
> +			val = (val & 0xffff) << (8 * (where & 3));
> +			val |= (u32)read_val;
> +			break;
> +		default:
> +			break;
> +
> +		}
> +		/*
> +		 * Low order bits are the config address, the high
> +		 * order 32 bits are the data to be written.
> +		 */
> +		write_val = where & ~3ull;
> +		write_val |= (((u64)val) << 32);
> +		writeq(write_val, pem_pci->pem_reg_base + PEM_CFG_WR);
> +		return PCIBIOS_SUCCESSFUL;
> +	}
> +	if (bus->number < pci->cfg.bus_range->start ||
> +	    bus->number > pci->cfg.bus_range->end)
> +		return PCIBIOS_DEVICE_NOT_FOUND;
> +	return pci_generic_config_write(bus, devfn, where, size, val);
> +}
> +
> +static void __iomem *map_cfg_bus_thunder_pem(struct pci_bus *bus,
> +					     unsigned int devfn,
> +					     int where)
> +{
> +	struct gen_pci *pci = bus->sysdata;
> +	resource_size_t idx = bus->number - pci->cfg.bus_range->start;
> +
> +	return pci->cfg.win[idx] + ((devfn << 16) | where);
> +}
> +
> +static struct gen_pci_cfg_bus_ops thunder_pem_bus_ops = {
> +	.bus_shift	= 24,
> +	.ops		= {
> +		.map_bus	= map_cfg_bus_thunder_pem,

How about "thunder_pem_map_bus"?

> +		.read		= thunder_pem_config_read,
> +		.write		= thunder_pem_config_write,
> +	}
> +};
> +
> +static const struct of_device_id thunder_pem_of_match[] = {
> +	{ .compatible = "cavium,pci-host-thunder-pem",
> +	  .data = &thunder_pem_bus_ops },
> +
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, thunder_pem_of_match);
> +
> +static int thunder_pem_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	const struct of_device_id *of_id;
> +	resource_size_t bar4_start;
> +	struct resource *res_pem;
> +	struct thunder_pem_pci *pem_pci;
> +
> +	pem_pci = devm_kzalloc(dev, sizeof(*pem_pci), GFP_KERNEL);
> +	if (!pem_pci)
> +		return -ENOMEM;
> +
> +	of_id = of_match_node(thunder_pem_of_match, dev->of_node);
> +	pem_pci->gen_pci.cfg.ops = (struct gen_pci_cfg_bus_ops *)of_id->data;
> +
> +	/*
> +	 * The second register range is the PEM bridge to the PCIe
> +	 * bus.  It has a different config access method than those
> +	 * devices behind the bridge.
> +	 */
> +	res_pem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +	if (!res_pem) {
> +		dev_err(dev, "missing \"reg[1]\"property\n");
> +		return -EINVAL;
> +	}
> +
> +	pem_pci->pem_reg_base = devm_ioremap(dev, res_pem->start, 0x10000);
> +	if (!pem_pci->pem_reg_base)
> +		return -ENOMEM;
> +
> +	/*
> +	 * The MSI-X BAR for the PEM and AER interrupts is located at
> +	 * a fixed offset from the PEM register base.  Generate a
> +	 * fragment of the synthesized Enhanced Allocation capability
> +	 * structure here for the BAR.
> +	 */
> +	bar4_start = res_pem->start + 0xf00000;
> +	pem_pci->ea_entry[0] = (u32)bar4_start | 2;
> +	pem_pci->ea_entry[1] = (u32)(res_pem->end - bar4_start) & ~3u;
> +	pem_pci->ea_entry[2] = (u32)(bar4_start >> 32);
> +
> +	return pci_host_common_probe(pdev, &pem_pci->gen_pci);
> +}
> +
> +static struct platform_driver thunder_pem_driver = {
> +	.driver = {
> +		.name = KBUILD_MODNAME,
> +		.of_match_table = thunder_pem_of_match,
> +	},
> +	.probe = thunder_pem_probe,
> +};
> +module_platform_driver(thunder_pem_driver);
> +
> +MODULE_DESCRIPTION("Thunder PEM PCIe host driver");
> +MODULE_LICENSE("GPL v2");
> -- 
> 1.8.3.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From akpm at linux-foundation.org  Thu Feb  4 16:14:38 2016
From: akpm at linux-foundation.org (Andrew Morton)
Date: Thu, 4 Feb 2016 16:14:38 -0800
Subject: [PATCH v8] kernel: add kcov code coverage
In-Reply-To: <1454600441-70701-1-git-send-email-dvyukov@google.com>
References: <1454600441-70701-1-git-send-email-dvyukov@google.com>
Message-ID: <20160204161438.a6c7fb568a00a42c179a20de@linux-foundation.org>

On Thu,  4 Feb 2016 16:40:41 +0100 Dmitry Vyukov <dvyukov at google.com> wrote:

> kcov provides code coverage collection for coverage-guided fuzzing
> (randomized testing).

# make allmodconfig
# make
Makefile:679: Cannot use CONFIG_KCOV: -fsanitize-coverage=trace-pc is not supported by compiler
scripts/kconfig/conf  --silentoldconfig Kconfig
Makefile:679: Cannot use CONFIG_KCOV: -fsanitize-coverage=trace-pc is not supported by compiler
  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CC      arch/x86/purgatory/purgatory.o
gcc: error: unrecognized command line option '-fsanitize-coverage=trace-pc'
make[1]: *** [arch/x86/purgatory/purgatory.o] Error 1
make: *** [archprepare] Error 2


We can't break allmodconfig and allyesconfig!

I did this:

--- a/Makefile~kernel-add-kcov-code-coverage-fix-2
+++ a/Makefile
@@ -678,6 +678,7 @@ ifdef CONFIG_KCOV
   ifeq ($(call cc-option, $(CFLAGS_KCOV)),)
     $(warning Cannot use CONFIG_KCOV: \
              -fsanitize-coverage=trace-pc is not supported by compiler)
+    CFLAGS_KCOV =
   endif
 endif
 
but hopefully there's a better way: it's a bit silly to build in the
kcov code but to not have the compiler-generated instrumentation which
calls it.



From k.kozlowski at samsung.com  Thu Feb  4 16:18:21 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 05 Feb 2016 09:18:21 +0900
Subject: [rtc-linux] Re: [PATCH v4 00/10] rtc: max77686: Extend driver and
 add max77802 support
In-Reply-To: <20160204225655.GE4782@piout.net>
References: <1453865806-4661-1-git-send-email-javier@osg.samsung.com>
 <20160131120525.GM20165@piout.net> <56ADF9D4.2050208@samsung.com>
 <20160204225655.GE4782@piout.net>
Message-ID: <56B3EA4D.4010801@samsung.com>

On 05.02.2016 07:56, Alexandre Belloni wrote:
> On 31/01/2016 at 21:11:00 +0900, Krzysztof Kozlowski wrote :
>> W dniu 31.01.2016 o 21:05, Alexandre Belloni pisze:
>>> Hi,
>>>
>>> On 27/01/2016 at 00:36:36 -0300, Javier Martinez Canillas wrote :
>>>> Hello,
>>>>
>>>> On a recent disussion [0] with Krzysztof Kozlowski and Laxman Dewangan,
>>>> we came to the conclusion that the max77686 and max77802 RTC are almost
>>>> the same with only a few differences so there shouldn't be two separate
>>>> drivers and is better to extend max77686 driver and delete rtc-max77802.
>>>>
>>>> By making the driver more generic, other RTC IP blocks from Maxim PMICs
>>>> could be supported as well like the max77620.
>>>>
>>>> This is a v4 of a series that do this, that address issues pointed out
>>>> in the latest version. The v1, v2 and v3 can be found at [1], [2], [3].
>>>>
>>>> I've tested this patch-set on an Exynos5800 Peach Pi Chromebook that has
>>>> a max77802 PMIC and the RTC was working correctly. Krzysztof Kozlowski
>>>> tested v3 on an max77686 but this version only has cosmetic changes so
>>>> it should not cause any functionality changes.
>>>>
>>>> [0]: http://www.spinics.net/lists/devicetree/msg110348.html
>>>> [1]: https://lwn.net/Articles/672568/
>>>> [2]: https://lkml.org/lkml/2016/1/25/767
>>>> [3]: https://lkml.org/lkml/2016/1/26/787
>>>>
>>>
>>> I've applied patches 1 to 8 and I'll discussed with Arnd and Olof about
>>> what I should do with the defconfig changes.
>>
>> To avoid conflicts they could go through samsung-soc tree. I could pick
>> them if you provide me a tag with rest of patchset (dependencies).
>>
>> Would that be okay for you?
>>
> 
> Let's do that, I've prepared a tag, rtc-max77686-4.6 with all the
> max77686 material collected until now.  If I need to rebase rtc-next,
> I'll rebase on top of that.

Thanks, I pulled the tag, applied patches #9 and #10 and pushed out to
the for-next.

Best regards,
Krzysztof



From helgaas at kernel.org  Thu Feb  4 16:19:07 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Thu, 4 Feb 2016 18:19:07 -0600
Subject: [PATCH v7 5/5] PCI: ACPI: Add a generic ACPI based host controller
In-Reply-To: <1454058340-7904-6-git-send-email-jchandra@broadcom.com>
References: <1454058340-7904-1-git-send-email-jchandra@broadcom.com>
 <1454058340-7904-6-git-send-email-jchandra@broadcom.com>
Message-ID: <20160205001907.GJ7031@localhost>

Hi Jayachandran,

On Fri, Jan 29, 2016 at 02:35:40PM +0530, Jayachandran C wrote:
> Add a simple ACPI based PCI host controller under config option
> ACPI_PCI_HOST_GENERIC. This is done by providing an implementation
> of pci_acpi_scan_root().
> 
> The pci_mmcfg_list handling is done by the ACPI code, so we keep a
> reference to the pci_mmcfg_region in sysdata. The ECAM region will
> be already mapped, so map_bus can be implemented by using the
> virt pointer for the pci_mmcfg_region. pci_generic_config_read
> and pci_generic_config_write are used for config space read/write.
> 
> Also, we provide implementations of raw_pci_read and raw_pci_write
> hat are needed by ACPI based on the pci_mmcfg_list.
> 
> pci_acpi_set_companion() and acpi_pci_get_segment() are defined
> using sysdata of generic ACPI host controller so that PCI domain
> and ACPI companion are set in PCI code rather than platform code.
> 
> This code is currently enabled only for ARM64.
> 
> Signed-off-by: Jayachandran C <jchandra at broadcom.com>
> ---
>  drivers/acpi/Kconfig         |   8 ++
>  drivers/acpi/Makefile        |   1 +
>  drivers/acpi/pci_host_acpi.c | 186 +++++++++++++++++++++++++++++++++++++++++++
>  include/linux/pci-acpi.h     |  17 ++++
>  4 files changed, 212 insertions(+)
>  create mode 100644 drivers/acpi/pci_host_acpi.c

I'm speaking a little bit out of turn here, because this is ACPI code,
but I'm confused about pci_host_acpi.c.  We already have pci_root.c,
which is *supposed* to be arch-independent.  I know pci_root.c is
crufty and could be improved, but it does work today on x86 and ia64,
and it handles some generic things that pci_host_acpi.c does not,
e.g., _OSC, NUMA, host bridge hotplug, etc.

I'd really like to see pci_root.c improved so it could work on x86,
ia64, and arm64.  I'm sure that was probably the first thing you
tried, so likely there are issues there.  Are they insurmountable?

Bjorn

> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 82b96ee..65fb483 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -294,6 +294,14 @@ config ACPI_NUMA
>  	depends on (X86 || IA64)
>  	default y if IA64_GENERIC || IA64_SGI_SN2
>  
> +config ACPI_PCI_HOST_GENERIC
> +	bool "Generic ACPI PCI host controller"
> +	depends on ARM64 && ACPI
> +	help
> +	  Say Y here if you want to support a simple generic ACPI PCI host
> +	  controller.
> +
> +
>  config ACPI_CUSTOM_DSDT_FILE
>  	string "Custom DSDT Table file to include"
>  	default ""
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 74976f1..346101c 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -41,6 +41,7 @@ acpi-y				+= ec.o
>  acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
>  acpi-y				+= pci_root.o pci_link.o pci_irq.o
>  acpi-$(CONFIG_PCI_MMCONFIG)	+= pci_mcfg.o
> +acpi-$(CONFIG_ACPI_PCI_HOST_GENERIC) += pci_host_acpi.o
>  acpi-y				+= acpi_lpss.o acpi_apd.o
>  acpi-y				+= acpi_platform.o
>  acpi-y				+= acpi_pnp.o
> diff --git a/drivers/acpi/pci_host_acpi.c b/drivers/acpi/pci_host_acpi.c
> new file mode 100644
> index 0000000..9dbdd81
> --- /dev/null
> +++ b/drivers/acpi/pci_host_acpi.c
> @@ -0,0 +1,186 @@
> +/*
> + * Generic PCI host controller driver for ACPI based systems
> + *
> + * 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/>.
> + *
> + * Copyright (c) 2015 Broadcom Corporation
> + *
> + * Based on drivers/pci/host/pci-host-generic.c
> + * Copyright (C) 2014 ARM Limited
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/pci.h>
> +#include <linux/acpi.h>
> +#include <linux/pci-acpi.h>
> +#include <linux/sfi_acpi.h>
> +#include <linux/slab.h>
> +
> +#define PREFIX			"pci-host-acpi:"
> +
> +/* sysdata pointer is ->root_info */
> +struct gen_acpi_root_info {
> +	struct acpi_pci_root_info	common;
> +	struct pci_mmcfg_region		*mcfg;
> +	bool				mcfg_added;
> +};
> +
> +/* find mapping of a MCFG area */
> +static void __iomem *gen_acpi_map_cfg_bus(struct pci_bus *bus,
> +			unsigned int devfn, int where)
> +{
> +	struct gen_acpi_root_info *pci = bus->sysdata;
> +	struct pci_mmcfg_region *mcfg = pci->mcfg;
> +
> +	if (bus->number < mcfg->start_bus || bus->number > mcfg->end_bus)
> +		return NULL;
> +
> +	return mcfg->virt +
> +		PCI_MMCFG_OFFSET(bus->number - mcfg->start_bus, devfn) +
> +		where;
> +}
> +
> +static struct pci_ops gen_acpi_pci_ops = {
> +	.map_bus	= gen_acpi_map_cfg_bus,
> +	.read		= pci_generic_config_read,
> +	.write		= pci_generic_config_write,
> +};
> +
> +/* Insert the ECFG area for a root bus */
> +static int pci_acpi_root_init_info(struct acpi_pci_root_info *ci)
> +{
> +	struct gen_acpi_root_info *info;
> +	struct acpi_pci_root *root = ci->root;
> +	struct device *dev = &ci->bridge->dev;
> +	int err;
> +
> +	info = container_of(ci, struct gen_acpi_root_info, common);
> +	err = pci_mmconfig_insert(dev, root->segment, root->secondary.start,
> +			root->secondary.end, root->mcfg_addr);
> +	if (err && err != -EEXIST)
> +		return err;
> +
> +	info->mcfg = pci_mmconfig_lookup(root->segment, root->secondary.start);
> +	WARN_ON(info->mcfg == NULL);
> +	info->mcfg_added = (err == -EEXIST);
> +	return 0;
> +}
> +
> +static void pci_acpi_root_release_info(struct acpi_pci_root_info *ci)
> +{
> +	struct gen_acpi_root_info *info;
> +	struct acpi_pci_root *root = ci->root;
> +
> +	info = container_of(ci, struct gen_acpi_root_info, common);
> +	if (info->mcfg_added)
> +		pci_mmconfig_delete(root->segment, root->secondary.start,
> +					root->secondary.end);
> +	info->mcfg = NULL;
> +}
> +
> +static struct acpi_pci_root_ops pci_acpi_root_ops = {
> +	.pci_ops = &gen_acpi_pci_ops,
> +	.init_info = pci_acpi_root_init_info,
> +	.release_info = pci_acpi_root_release_info,
> +};
> +
> +struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> +{
> +	struct acpi_device *device = root->device;
> +	struct gen_acpi_root_info *ri;
> +	struct pci_bus *bus, *child;
> +
> +	/* allocate acpi_info/sysdata */
> +	ri = devm_kzalloc(&device->dev, sizeof(*ri), GFP_KERNEL);
> +	if (!ri) {
> +		dev_err(&device->dev,
> +			"pci_bus %04x:%02x: ignored (out of memory)\n",
> +			root->segment, (int)root->secondary.start);
> +		return NULL;
> +	}
> +
> +	bus =  acpi_pci_root_create(root, &pci_acpi_root_ops,
> +					&ri->common, ri);
> +	if (!bus) {
> +		dev_err(&device->dev, "Scanning rootbus failed");
> +		return NULL;
> +	}
> +
> +	pci_bus_size_bridges(bus);
> +	pci_bus_assign_resources(bus);
> +	list_for_each_entry(child, &bus->children, node)
> +		pcie_bus_configure_settings(child);
> +
> +	return bus;
> +}
> +
> +int raw_pci_read(unsigned int seg, unsigned int bus,
> +		  unsigned int devfn, int reg, int len, u32 *val)
> +{
> +	struct pci_mmcfg_region *mcfg;
> +	void __iomem *addr;
> +	int err = -EINVAL;
> +
> +	rcu_read_lock();
> +	mcfg = pci_mmconfig_lookup(seg, bus);
> +	if (!mcfg || !mcfg->virt)
> +		goto err;
> +
> +	addr = mcfg->virt + PCI_MMCFG_OFFSET(bus, devfn);
> +	switch (len) {
> +	case 1:
> +		*val = readb(addr + reg);
> +		break;
> +	case 2:
> +		*val = readw(addr + reg);
> +		break;
> +	case 4:
> +		*val = readl(addr + reg);
> +		break;
> +	}
> +	err = 0;
> +err:
> +	rcu_read_unlock();
> +	return err;
> +}
> +
> +int raw_pci_write(unsigned int seg, unsigned int bus,
> +		unsigned int devfn, int reg, int len, u32 val)
> +{
> +	struct pci_mmcfg_region *mcfg;
> +	void __iomem *addr;
> +	int err = -EINVAL;
> +
> +	rcu_read_lock();
> +	mcfg = pci_mmconfig_lookup(seg, bus);
> +	if (!mcfg || !mcfg->virt)
> +		goto err;
> +
> +	addr = mcfg->virt + PCI_MMCFG_OFFSET(bus, devfn);
> +	switch (len) {
> +	case 1:
> +		writeb(val, addr + reg);
> +		break;
> +	case 2:
> +		writew(val, addr + reg);
> +		break;
> +	case 4:
> +		writel(val, addr + reg);
> +		break;
> +	}
> +	err = 0;
> +err:
> +	rcu_read_unlock();
> +	return err;
> +}
> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
> index d410885..f8d62e3 100644
> --- a/include/linux/pci-acpi.h
> +++ b/include/linux/pci-acpi.h
> @@ -143,6 +143,22 @@ static inline void acpi_pci_add_bus(struct pci_bus *bus) { }
>  static inline void acpi_pci_remove_bus(struct pci_bus *bus) { }
>  #endif	/* CONFIG_ACPI */
>  
> +#if defined(CONFIG_ACPI) && defined(CONFIG_ACPI_PCI_HOST_GENERIC)
> +static inline void pci_acpi_set_companion(struct pci_host_bridge *bridge)
> +{
> +	struct pci_bus *b = bridge->bus;
> +	struct acpi_pci_root_info *ci = (struct acpi_pci_root_info *)b->sysdata;
> +
> +	ACPI_COMPANION_SET(&bridge->dev, ci->bridge);
> +}
> +
> +static inline u16 acpi_pci_get_segment(void *sysdata)
> +{
> +	struct acpi_pci_root_info *ci = (struct acpi_pci_root_info *)sysdata;
> +
> +	return ci->root->segment;
> +}
> +#else
>  static inline void pci_acpi_set_companion(struct pci_host_bridge *bridge)
>  {
>  	/* leave it to the platform for now */
> @@ -152,6 +168,7 @@ static inline u16 acpi_pci_get_segment(void *sysdata)
>  {
>  	return 0;
>  }
> +#endif
>  
>  #ifdef CONFIG_ACPI_APEI
>  extern bool aer_acpi_firmware_first(void);
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From ddaney at caviumnetworks.com  Thu Feb  4 16:28:29 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Thu, 4 Feb 2016 16:28:29 -0800
Subject: [PATCH v4 2/2] pci, pci-thunder-pem: Add PCIe host driver for
 ThunderX processors.
In-Reply-To: <20160205000452.GI7031@localhost>
References: <1453844781-24380-1-git-send-email-ddaney.cavm@gmail.com>
 <1453844781-24380-3-git-send-email-ddaney.cavm@gmail.com>
 <20160205000452.GI7031@localhost>
Message-ID: <56B3ECAD.4050605@caviumnetworks.com>

On 02/04/2016 04:04 PM, Bjorn Helgaas wrote:
> Hi David,
>
> Looks good, a few trival questions below.
>
> On Tue, Jan 26, 2016 at 01:46:21PM -0800, David Daney wrote:
>> From: David Daney <david.daney at cavium.com>
>>
>> Some Cavium ThunderX processors require quirky access methods for the
>> config space of the PCIe bridge.  Add a driver to provide these config
>> space accessor functions.  The pci-host-common code is used to
>> configure the PCI machinery.
>>
>> Signed-off-by: David Daney <david.daney at cavium.com>
>> Acked-by: Rob Herring <robh at kernel.org>
>> Acked-by: Arnd Bergmann <arnd at arndb.de>
>> ---
>>   .../devicetree/bindings/pci/pci-thunder-pem.txt    |  43 ++++
>>   MAINTAINERS                                        |   8 +
>>   drivers/pci/host/Kconfig                           |   7 +
>>   drivers/pci/host/Makefile                          |   1 +
>>   drivers/pci/host/pci-thunder-pem.c                 | 283 +++++++++++++++++++++
>
> What's the significance of the "pem" part of the name?  I'm wondering
> if we can shorten the filenames and function names by dropping it and
> referring to this simply as "thunder" or "thunderx".

PEM == PCI Express MAC, Essentially the circuitry related to off-chip 
PCI devices.  This differentiates it from the internal on-chip devices 
which are connected to internal buses we refer to as "ECAMs"

See also the follow on patch, from me, that adds the pci-thunder-ecam.c 
driver.

Since PEM and ECAM are terminology used in the hardware manuals that 
have specific meanings relative to the Thunder SoC family, I think it is 
not too inconvenient to carry them over into the file names.

>
>>   5 files changed, 342 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-pem.txt
>>   create mode 100644 drivers/pci/host/pci-thunder-pem.c
>>

>> +
>> +static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
>> +				    int where, int size, u32 val)
>> +{
>> +	struct gen_pci *pci = bus->sysdata;
>> +	struct thunder_pem_pci *pem_pci;
>> +
>> +	pem_pci = container_of(pci, struct thunder_pem_pci, gen_pci);
>> +
>> +	/*
>> +	 * The first device on the bus in the PEM PCIe bridge.
>> +	 * Special case its config access.
>> +	 */
>> +	if (bus->number == pci->cfg.bus_range->start) {
>> +		u64 write_val, read_val;
>> +
>> +		if (devfn != 0 || where >= 2048)
>> +			return PCIBIOS_DEVICE_NOT_FOUND;
>> +
>> +		/*
>> +		 * 32-bit accesses only.  If the write is for a size
>> +		 * smaller than 32-bits, we must first read the 32-bit
>> +		 * value and merge in the desired bits and then write
>> +		 * the whole 32-bits back out.
>> +		 */
>
> Ugh.  Another device that only supports 32-bit writes.  I guess this
> only affects this single device, and maybe you "know" that it has no
> registers where RW1C bits may be corrupted.  Although I suppose this
> device has the standard status registers (Status at 0x06, Secondary
> Status at 0x1e, Device Status in PCIe capability, etc.), which do
> contain RW1C bits.

This device is exactly the specific PCIe host bridge implementation, 
present on these SoCs.  The only sane way to access its config space is 
via 32-bit operations.  We know that it presents the appropriate Class 
and other registers to be recognized as, and operate as, a standard PCIe 
bridge.

>
> We need to print a warning at probe-time so we know to consider the
> possibility of corruption when debugging.

If you really want it, I suppose I can add that, but I am somewhat hesitant.

>
[...]
>> +
>> +static struct gen_pci_cfg_bus_ops thunder_pem_bus_ops = {
>> +	.bus_shift	= 24,
>> +	.ops		= {
>> +		.map_bus	= map_cfg_bus_thunder_pem,
>
> How about "thunder_pem_map_bus"?

That would be better.  Actually, I wonder how I came up with that crappy 
name in the first place...

>
>> +		.read		= thunder_pem_config_read,
>> +		.write		= thunder_pem_config_write,
>> +	}
>> +};
>> +

I will wait a day to see if you have any response, and then send a new 
version of the patch set.

Thanks,
David Daney



From tony at atomide.com  Thu Feb  4 17:08:11 2016
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Feb 2016 17:08:11 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFrMZYdeun67FBXdWL16DBOuO16qqOxRsks3QBJhNB8SoQ@mail.gmail.com>
References: <CAPDyKFpRnmn+h_VH3jtC3u-BOf7-00nbzD30omaxaaZOOAK8Gg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602041702550.1515-100000@iolanthe.rowland.org>
 <CAPDyKFrMZYdeun67FBXdWL16DBOuO16qqOxRsks3QBJhNB8SoQ@mail.gmail.com>
Message-ID: <20160205010810.GR19432@atomide.com>

* Ulf Hansson <ulf.hansson at linaro.org> [160204 14:35]:
> On 4 February 2016 at 23:09, Alan Stern <stern at rowland.harvard.edu> wrote:
> > On Thu, 4 Feb 2016, Ulf Hansson wrote:
> >
> >> I am really not questioning the autosuspend feature at all, it's a
> >> really great feature!
> >>
> >> Now, I question the minor benefit we actually gain from having the
> >> runtime PM core to update the mark in rpm_resume().
> >
> > As Tony pointed out, it prevents some devices from going to sleep right
> > away.
> 
> Because their drivers don't care to update the last busy mark!?

Nope. Without that devices may never resume at all so the drivers
can't do anything about it.

Regards,

Tony


From k.kozlowski at samsung.com  Thu Feb  4 17:36:20 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 05 Feb 2016 10:36:20 +0900
Subject: [PATCH v2] arm64: defconfig: Enable samsung MFD and related
 configs
In-Reply-To: <56B2CD46.6070607@samsung.com>
References: <1446787654-18306-1-git-send-email-alim.akhtar@samsung.com>
 <CAJKOXPeWerSTi2QedEwyHRVN4xA0vWM2CSOvb5v9SWUmOSPe7Q@mail.gmail.com>
 <20151106163743.GA7637@e104818-lin.cambridge.arm.com>
 <56B2CD46.6070607@samsung.com>
Message-ID: <56B3FC94.9090205@samsung.com>

On 04.02.2016 13:02, Alim Akhtar wrote:
> On 11/06/2015 10:07 PM, Catalin Marinas wrote:
>> On Fri, Nov 06, 2015 at 02:47:12PM +0900, Krzysztof Kozlowski wrote:
>>> 2015-11-06 14:27 GMT+09:00 Alim Akhtar <alim.akhtar at samsung.com>:
>>>> Exynos7 based espresso board uses S2MPS15, a multifunction device.
>>>> This patch enables S2MPS1X regulator, pmic-clk and rtc drivers
>>>> utilized by
>>>> the same.
>>>>
>>>> Signed-off-by: Alim Akhtar <alim.akhtar at samsung.com>
>>>> ---
>>>> Changes since v1:
>>>> * updated the comment message to describe which platfrom uses it.
>>>> * enable COMMON_CLK_S2MPS11 which is needed to enable pmic-clk block.
>>>>
>>>>   arch/arm64/configs/defconfig |    4 ++++
>>>>   1 file changed, 4 insertions(+)
>>>
>>> Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
>>>
>>> Catalin,
>>>
>>> Are you usually taking such arm64 defconfig changes or should they go
>>> through arm-soc?
>>
>> Usually arm-soc but I don't mind either way.
>>
> Looks like this patch is not merged...because of this 4.5-rc1 on
> exynos7-esspreso does not boot to user space.
> Do I need to resend this patch?

Yes, please resend.
I reviewed it on the list archives (from different email) but for
applying I need to get the patch delivered to my mail box. Unfortunately
you didn't put Samsung SoC guys on recipients list and at the same time
patchwork does not work in company network.

Best regards,
Krzysztof



From tiffany.lin at mediatek.com  Thu Feb  4 17:44:47 2016
From: tiffany.lin at mediatek.com (tiffany lin)
Date: Fri, 5 Feb 2016 09:44:47 +0800
Subject: [PATCH v3 1/8] dt-bindings: Add a binding for Mediatek Video
 Processor
In-Reply-To: <CAL_JsqJqQ+QRgg6HGQeGk0=rBEwQq7i-ZfoDahZwXLuvMC-=_A@mail.gmail.com>
References: <1451902316-55931-1-git-send-email-tiffany.lin@mediatek.com>
 <1451902316-55931-2-git-send-email-tiffany.lin@mediatek.com>
 <20160104141506.GA22801@rob-hp-laptop> <1454586583.7571.3.camel@mtksdaap41>
 <CAL_JsqJqQ+QRgg6HGQeGk0=rBEwQq7i-ZfoDahZwXLuvMC-=_A@mail.gmail.com>
Message-ID: <1454636687.24985.2.camel@mtksdaap41>

Hi Rob,


On Thu, 2016-02-04 at 12:04 -0600, Rob Herring wrote:
> On Thu, Feb 4, 2016 at 5:49 AM, tiffany lin <tiffany.lin at mediatek.com> wrote:
> > Hi Rob,
> >
> >
> >
> >
> > On Mon, 2016-01-04 at 22:15 +0800, Rob Herring wrote:
> >> On Mon, Jan 04, 2016 at 06:11:49PM +0800, Tiffany Lin wrote:
> >> > From: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
> >> >
> >> > Add a DT binding documentation of Video Processor Unit for the
> >> > MT8173 SoC from Mediatek.
> >> >
> >> > Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
> >> > Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
> >>
> >> Please add acks when sending new versions as I already acked the last
> >> version.
> >>
> > Since we remove iommu attach and add 4GB support for VPU.
> > We send the new device tree and binding document.
> > We do not add Acked-by in v4 patches.
> 
> Okay, then you should explain that in the patch.
> 
Got it. I explained that in cover-letter "[PATCH v4 0/8] Add MT8173
Video Encoder Driver and VPU Driver", I will explain it in the patch in
next version.

> Rob




From xuejiancheng at huawei.com  Thu Feb  4 18:31:08 2016
From: xuejiancheng at huawei.com (Jiancheng Xue)
Date: Fri, 5 Feb 2016 10:31:08 +0800
Subject: [RESEND PATCH v8 2/6] ARM: hisi: add compatible string for Hi3519 soc
In-Reply-To: <1454639472-17373-1-git-send-email-xuejiancheng@huawei.com>
References: <1454639472-17373-1-git-send-email-xuejiancheng@huawei.com>
Message-ID: <1454639472-17373-3-git-send-email-xuejiancheng@huawei.com>

add compatible string for Hi3519 soc.

Signed-off-by: Jiancheng Xue <xuejiancheng at huawei.com>
---
 arch/arm/mach-hisi/hisilicon.c | 23 ++++-------------------
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c
index 8cc6215..00dae89 100644
--- a/arch/arm/mach-hisi/hisilicon.c
+++ b/arch/arm/mach-hisi/hisilicon.c
@@ -54,30 +54,15 @@ DT_MACHINE_START(HI3620, "Hisilicon Hi3620 (Flattened Device Tree)")
 	.dt_compat	= hi3xxx_compat,
 MACHINE_END
 
-static const char *const hix5hd2_compat[] __initconst = {
+static const char *const hisilicon_compat[] __initconst = {
 	"hisilicon,hix5hd2",
-	NULL,
-};
-
-DT_MACHINE_START(HIX5HD2_DT, "Hisilicon HIX5HD2 (Flattened Device Tree)")
-	.dt_compat	= hix5hd2_compat,
-MACHINE_END
-
-static const char *const hip04_compat[] __initconst = {
 	"hisilicon,hip04-d01",
-	NULL,
-};
-
-DT_MACHINE_START(HIP04, "Hisilicon HiP04 (Flattened Device Tree)")
-	.dt_compat	= hip04_compat,
-MACHINE_END
-
-static const char *const hip01_compat[] __initconst = {
 	"hisilicon,hip01",
 	"hisilicon,hip01-ca9x2",
+	"hisilicon,hi3519",
 	NULL,
 };
 
-DT_MACHINE_START(HIP01, "Hisilicon HIP01 (Flattened Device Tree)")
-	.dt_compat      = hip01_compat,
+DT_MACHINE_START(HISILICON_DT, "HiSilicon Soc")
+	.dt_compat	= hisilicon_compat,
 MACHINE_END
-- 
1.9.1



From xuejiancheng at huawei.com  Thu Feb  4 18:31:10 2016
From: xuejiancheng at huawei.com (Jiancheng Xue)
Date: Fri, 5 Feb 2016 10:31:10 +0800
Subject: [RESEND PATCH v8 4/6] ARM: debug: add hi3519 debug uart
In-Reply-To: <1454639472-17373-1-git-send-email-xuejiancheng@huawei.com>
References: <1454639472-17373-1-git-send-email-xuejiancheng@huawei.com>
Message-ID: <1454639472-17373-5-git-send-email-xuejiancheng@huawei.com>

add hi3519 debug uart

Signed-off-by: Jiancheng Xue <xuejiancheng at huawei.com>
---
 arch/arm/Kconfig.debug | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index c6b6175..edd3fbe 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -260,6 +260,14 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on Cortina Gemini based platforms.
 
+	config DEBUG_HI3519_UART
+		bool "Hisilicon HI3519 Debug UART"
+		depends on ARCH_HISI
+		select DEBUG_UART_PL01X
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on HI3519 UART.
+
 	config DEBUG_HI3620_UART
 		bool "Hisilicon HI3620 Debug UART"
 		depends on ARCH_HI3xxx
@@ -1451,6 +1459,7 @@ config DEBUG_UART_PHYS
 	default 0x11002000 if DEBUG_MT8127_UART0
 	default 0x11006000 if DEBUG_MT6589_UART0
 	default 0x11009000 if DEBUG_MT8135_UART3
+	default 0x12100000 if DEBUG_HI3519_UART
 	default 0x16000000 if DEBUG_INTEGRATOR
 	default 0x18000300 if DEBUG_BCM_5301X
 	default 0x18010000 if DEBUG_SIRFATLAS7_UART0
@@ -1619,6 +1628,7 @@ config DEBUG_UART_VIRT
 	default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART
 	default 0xfee82340 if ARCH_IOP13XX
 	default 0xfef00000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
+	default 0xfef00000 if DEBUG_HI3519_UART
 	default 0xfef00003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
 	default 0xfef36000 if DEBUG_HIGHBANK_UART
 	default 0xfefb0000 if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
-- 
1.9.1



From xuejiancheng at huawei.com  Thu Feb  4 18:31:11 2016
From: xuejiancheng at huawei.com (Jiancheng Xue)
Date: Fri, 5 Feb 2016 10:31:11 +0800
Subject: [RESEND PATCH v8 5/6] ARM: dt-bindings: add device tree bindings for
 Hi3519 sysctrl
In-Reply-To: <1454639472-17373-1-git-send-email-xuejiancheng@huawei.com>
References: <1454639472-17373-1-git-send-email-xuejiancheng@huawei.com>
Message-ID: <1454639472-17373-6-git-send-email-xuejiancheng@huawei.com>

Add device tree bindings for Hi3519 system controller.

Signed-off-by: Jiancheng Xue <xuejiancheng at huawei.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt   | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt b/Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt
new file mode 100644
index 0000000..115c5be
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt
@@ -0,0 +1,14 @@
+* Hisilicon Hi3519 System Controller Block
+
+This bindings use the following binding:
+Documentation/devicetree/bindings/mfd/syscon.txt
+
+Required properties:
+- compatible: "hisilicon,hi3519-sysctrl".
+- reg: the register region of this block
+
+Examples:
+sysctrl: system-controller at 12010000 {
+	compatible = "hisilicon,hi3519-sysctrl", "syscon";
+	reg = <0x12010000 0x1000>;
+};
-- 
1.9.1



From xuejiancheng at huawei.com  Thu Feb  4 18:31:09 2016
From: xuejiancheng at huawei.com (Jiancheng Xue)
Date: Fri, 5 Feb 2016 10:31:09 +0800
Subject: [RESEND PATCH v8 3/6] ARM: config: hisi: enable
 CONFIG_RESET_CONTROLLER
In-Reply-To: <1454639472-17373-1-git-send-email-xuejiancheng@huawei.com>
References: <1454639472-17373-1-git-send-email-xuejiancheng@huawei.com>
Message-ID: <1454639472-17373-4-git-send-email-xuejiancheng@huawei.com>

enable CONFIG_RESET_CONTROLLER in hisi_defconfig

Signed-off-by: Jiancheng Xue <xuejiancheng at huawei.com>
---
 arch/arm/configs/hisi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig
index b2e340b..ba62c07 100644
--- a/arch/arm/configs/hisi_defconfig
+++ b/arch/arm/configs/hisi_defconfig
@@ -75,6 +75,7 @@ CONFIG_DMADEVICES=y
 CONFIG_DW_DMAC=y
 CONFIG_PL330_DMA=y
 CONFIG_PWM=y
+CONFIG_RESET_CONTROLLER=y
 CONFIG_PHY_HIX5HD2_SATA=y
 CONFIG_EXT4_FS=y
 CONFIG_TMPFS=y
-- 
1.9.1



From xuejiancheng at huawei.com  Thu Feb  4 18:31:12 2016
From: xuejiancheng at huawei.com (Jiancheng Xue)
Date: Fri, 5 Feb 2016 10:31:12 +0800
Subject: [RESEND PATCH v8 6/6] ARM: dts: add dts files for Hi3519
In-Reply-To: <1454639472-17373-1-git-send-email-xuejiancheng@huawei.com>
References: <1454639472-17373-1-git-send-email-xuejiancheng@huawei.com>
Message-ID: <1454639472-17373-7-git-send-email-xuejiancheng@huawei.com>

add dts files for Hi3519

Signed-off-by: Jiancheng Xue <xuejiancheng at huawei.com>
---
 arch/arm/boot/dts/Makefile        |   2 +
 arch/arm/boot/dts/hi3519-demb.dts |  42 +++++++++
 arch/arm/boot/dts/hi3519.dtsi     | 187 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 231 insertions(+)
 create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
 create mode 100644 arch/arm/boot/dts/hi3519.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..3ce36ff 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -141,6 +141,8 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
 	exynos5800-peach-pi.dtb
 dtb-$(CONFIG_ARCH_HI3xxx) += \
 	hi3620-hi4511.dtb
+dtb-$(CONFIG_ARCH_HISI) += \
+	hi3519-demb.dtb
 dtb-$(CONFIG_ARCH_HIX5HD2) += \
 	hisi-x5hd2-dkb.dtb
 dtb-$(CONFIG_ARCH_HIGHBANK) += \
diff --git a/arch/arm/boot/dts/hi3519-demb.dts b/arch/arm/boot/dts/hi3519-demb.dts
new file mode 100644
index 0000000..6991ab6
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519-demb.dts
@@ -0,0 +1,42 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+/dts-v1/;
+#include "hi3519.dtsi"
+
+/ {
+	model = "HiSilicon HI3519 DEMO Board";
+	compatible = "hisilicon,hi3519";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x40000000>;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&dual_timer0 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/hi3519.dtsi b/arch/arm/boot/dts/hi3519.dtsi
new file mode 100644
index 0000000..5729ecf
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519.dtsi
@@ -0,0 +1,187 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * 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 <dt-bindings/clock/hi3519-clock.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+/ {
+	#address-cells = <1>;
+	#size-cells = <1>;
+	chosen { };
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0>;
+		};
+	};
+
+	gic: interrupt-controller at 10300000 {
+		compatible = "arm,cortex-a7-gic";
+		#interrupt-cells = <3>;
+		interrupt-controller;
+		reg = <0x10301000 0x1000>, <0x10302000 0x1000>;
+	};
+
+	clk_3m: clk_3m {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <3000000>;
+	};
+
+	crg: clock-reset-controller at 12010000 {
+		compatible = "hisilicon,hi3519-crg";
+		#clock-cells = <1>;
+		#reset-cells = <2>;
+		reg = <0x12010000 0x10000>;
+	};
+
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		interrupt-parent = <&gic>;
+		ranges;
+
+		uart0: serial at 12100000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x12100000 0x1000>;
+			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_UART0_CLK>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		uart1: serial at 12101000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x12101000 0x1000>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_UART1_CLK>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		uart2: serial at 12102000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x12102000 0x1000>;
+			interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_UART2_CLK>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		uart3: serial at 12103000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x12103000 0x1000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_UART3_CLK>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		uart4: serial at 12104000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x12104000 0x1000>;
+			interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_UART4_CLK>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		dual_timer0: timer at 12000000 {
+			compatible = "arm,sp804", "arm,primecell";
+			interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
+			reg = <0x12000000 0x1000>;
+			clocks = <&clk_3m>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		dual_timer1: timer at 12001000 {
+			compatible = "arm,sp804", "arm,primecell";
+			interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
+			reg = <0x12001000 0x1000>;
+			clocks = <&clk_3m>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		dual_timer2: timer at 12002000 {
+			compatible = "arm,sp804", "arm,primecell";
+			interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
+			reg = <0x12002000 0x1000>;
+			clocks = <&clk_3m>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		spi_bus0: spi at 12120000 {
+			compatible = "arm,pl022", "arm,primecell";
+			reg = <0x12120000 0x1000>;
+			interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_SPI0_CLK>;
+			clock-names = "apb_pclk";
+			num-cs = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disable";
+		};
+
+		spi_bus1: spi at 12121000 {
+			compatible = "arm,pl022", "arm,primecell";
+			reg = <0x12121000 0x1000>;
+			interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_SPI1_CLK>;
+			clock-names = "apb_pclk";
+			num-cs = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disable";
+		};
+
+		spi_bus2: spi at 12122000 {
+			compatible = "arm,pl022", "arm,primecell";
+			reg = <0x12122000 0x1000>;
+			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_SPI2_CLK>;
+			clock-names = "apb_pclk";
+			num-cs = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disable";
+		};
+
+		sysctrl: system-controller at 12020000 {
+			compatible = "hisilicon,hi3519-sysctrl", "syscon";
+			reg = <0x12020000 0x1000>;
+		};
+
+		reboot {
+			compatible = "syscon-reboot";
+			regmap = <&sysctrl>;
+			offset = <0x4>;
+			mask = <0xdeadbeef>;
+		};
+	};
+};
-- 
1.9.1



From xuejiancheng at huawei.com  Thu Feb  4 18:31:07 2016
From: xuejiancheng at huawei.com (Jiancheng Xue)
Date: Fri, 5 Feb 2016 10:31:07 +0800
Subject: [RESEND PATCH v8 1/6] clk: hisilicon: add CRG driver for hi3519 soc
In-Reply-To: <1454639472-17373-1-git-send-email-xuejiancheng@huawei.com>
References: <1454639472-17373-1-git-send-email-xuejiancheng@huawei.com>
Message-ID: <1454639472-17373-2-git-send-email-xuejiancheng@huawei.com>

The CRG(Clock and Reset Generator) block provides clock
and reset signals for other modules in hi3519 soc.

Signed-off-by: Jiancheng Xue <xuejiancheng at huawei.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/clock/hi3519-crg.txt       |  46 +++++++
This binding file is already acked by Rob Herring.
 drivers/clk/hisilicon/Kconfig                      |   7 ++
 drivers/clk/hisilicon/Makefile                     |   2 +
 drivers/clk/hisilicon/clk-hi3519.c                 | 133 +++++++++++++++++++++
 drivers/clk/hisilicon/clk.c                        |  23 ++--
 drivers/clk/hisilicon/clk.h                        |  14 +--
 drivers/clk/hisilicon/reset.c                      | 130 ++++++++++++++++++++
 drivers/clk/hisilicon/reset.h                      |  32 +++++
 include/dt-bindings/clock/hi3519-clock.h           |  40 +++++++
 9 files changed, 412 insertions(+), 15 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
 create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
 create mode 100644 drivers/clk/hisilicon/reset.c
 create mode 100644 drivers/clk/hisilicon/reset.h
 create mode 100644 include/dt-bindings/clock/hi3519-clock.h

diff --git a/Documentation/devicetree/bindings/clock/hi3519-crg.txt b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
new file mode 100644
index 0000000..2d23950
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
@@ -0,0 +1,46 @@
+* Hisilicon Hi3519 Clock and Reset Generator(CRG)
+
+The Hi3519 CRG module provides clock and reset signals to various
+controllers within the SoC.
+
+This binding uses the following bindings:
+    Documentation/devicetree/bindings/clock/clock-bindings.txt
+    Documentation/devicetree/bindings/reset/reset.txt
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "hisilicon,hi3519-crg" - controller compatible with Hi3519 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in <dt-bindings/clock/hi3519-clock.h>.
+
+- #reset-cells: should be 2.
+
+A reset signal can be controlled by writing a bit register in the CRG module.
+The reset specifier consists of two cells. The first cell represents the
+register offset relative to the base address. The second cell represents the
+bit index in the register.
+
+Example: CRG nodes
+CRG: clock-reset-controller at 12010000 {
+	compatible = "hisilicon,hi3519-crg";
+        reg = <0x12010000 0x10000>;
+        #clock-cells = <1>;
+        #reset-cells = <2>;
+};
+
+Example: consumer nodes
+i2c0: i2c at 12110000 {
+	compatible = "hisilicon,hi3519-i2c";
+        reg = <0x12110000 0x1000>;
+        clocks = <&CRG HI3519_I2C0_RST>;*/
+        resets = <&CRG 0xe4 0>;
+};
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
index e434854..2128899 100644
--- a/drivers/clk/hisilicon/Kconfig
+++ b/drivers/clk/hisilicon/Kconfig
@@ -1,3 +1,10 @@
+config COMMON_CLK_HI3519
+	tristate "Hi3519 Clock Driver"
+	depends on ARCH_HISI
+	default y
+	help
+	  Build the clock driver for hi3519.
+
 config COMMON_CLK_HI6220
 	bool "Hi6220 Clock Driver"
 	depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
index 74dba31..3f57b09 100644
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -4,8 +4,10 @@
 
 obj-y	+= clk.o clkgate-separated.o clkdivider-hi6220.o
 
+obj-$(CONFIG_RESET_CONTROLLER)	+= reset.o
 obj-$(CONFIG_ARCH_HI3xxx)	+= clk-hi3620.o
 obj-$(CONFIG_ARCH_HIP04)	+= clk-hip04.o
 obj-$(CONFIG_ARCH_HIX5HD2)	+= clk-hix5hd2.o
 obj-$(CONFIG_COMMON_CLK_HI6220)	+= clk-hi6220.o
 obj-$(CONFIG_STUB_CLK_HI6220)	+= clk-hi6220-stub.o
+obj-$(CONFIG_COMMON_CLK_HI3519)	+= clk-hi3519.o
diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
new file mode 100644
index 0000000..ed983af
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi3519.c
@@ -0,0 +1,133 @@
+/*
+ * Hi3519 Clock Driver
+ *
+ * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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 <dt-bindings/clock/hi3519-clock.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include "clk.h"
+#include "reset.h"
+
+#define HI3519_INNER_CLK_OFFSET	64
+#define HI3519_FIXED_24M	65
+#define HI3519_FIXED_50M	66
+#define HI3519_FIXED_75M	67
+#define HI3519_FIXED_125M	68
+#define HI3519_FIXED_150M	69
+#define HI3519_FIXED_200M	70
+#define HI3519_FIXED_250M	71
+#define HI3519_FIXED_300M	72
+#define HI3519_FIXED_400M	73
+#define HI3519_FMC_MUX		74
+
+#define HI3519_NR_CLKS		128
+
+static const struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] = {
+	{ HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
+	{ HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
+	{ HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
+	{ HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
+	{ HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
+	{ HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
+	{ HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
+	{ HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
+	{ HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
+};
+
+static const char *const fmc_mux_p[] = {
+		"24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
+static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
+
+static const struct hisi_mux_clock hi3519_mux_clks[] = {
+	{ HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
+		CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
+};
+
+static const struct hisi_gate_clock hi3519_gate_clks[] = {
+	{ HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
+		CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
+	{ HI3519_UART0_CLK, "clk_uart0", "24m",
+		CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
+	{ HI3519_UART1_CLK, "clk_uart1", "24m",
+		CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
+	{ HI3519_UART2_CLK, "clk_uart2", "24m",
+		CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
+	{ HI3519_UART3_CLK, "clk_uart3", "24m",
+		CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
+	{ HI3519_UART4_CLK, "clk_uart4", "24m",
+		CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
+	{ HI3519_SPI0_CLK, "clk_spi0", "50m",
+		CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
+	{ HI3519_SPI1_CLK, "clk_spi1", "50m",
+		CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
+	{ HI3519_SPI2_CLK, "clk_spi2", "50m",
+		CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
+};
+
+static int hi3519_clk_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct hisi_clock_data *clk_data;
+
+	clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
+	if (!clk_data)
+		return -ENODEV;
+
+	hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
+				     ARRAY_SIZE(hi3519_fixed_rate_clks),
+				     clk_data);
+	hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
+					clk_data);
+	hisi_clk_register_gate(hi3519_gate_clks,
+			ARRAY_SIZE(hi3519_gate_clks), clk_data);
+
+	return hisi_reset_init(np);
+}
+
+static const struct of_device_id hi3519_clk_match_table[] = {
+	{ .compatible = "hisilicon,hi3519-crg" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, hi3519_clk_match_table);
+
+static struct platform_driver hi3519_clk_driver = {
+	.probe          = hi3519_clk_probe,
+	.driver         = {
+		.name   = "hi3519-clk",
+		.of_match_table = hi3519_clk_match_table,
+	},
+};
+
+static int __init hi3519_clk_init(void)
+{
+	return platform_driver_register(&hi3519_clk_driver);
+}
+core_initcall(hi3519_clk_init);
+
+static void __exit hi3519_clk_exit(void)
+{
+	platform_driver_unregister(&hi3519_clk_driver);
+}
+module_exit(hi3519_clk_exit);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("HiSilicon Hi3519 Clock Driver");
diff --git a/drivers/clk/hisilicon/clk.c b/drivers/clk/hisilicon/clk.c
index 9f8e766..06ec3fe 100644
--- a/drivers/clk/hisilicon/clk.c
+++ b/drivers/clk/hisilicon/clk.c
@@ -37,7 +37,7 @@
 
 static DEFINE_SPINLOCK(hisi_clk_lock);
 
-struct hisi_clock_data __init *hisi_clk_init(struct device_node *np,
+struct hisi_clock_data *hisi_clk_init(struct device_node *np,
 					     int nr_clks)
 {
 	struct hisi_clock_data *clk_data;
@@ -71,8 +71,9 @@ err_data:
 err:
 	return NULL;
 }
+EXPORT_SYMBOL(hisi_clk_init);
 
-void __init hisi_clk_register_fixed_rate(struct hisi_fixed_rate_clock *clks,
+void hisi_clk_register_fixed_rate(const struct hisi_fixed_rate_clock *clks,
 					 int nums, struct hisi_clock_data *data)
 {
 	struct clk *clk;
@@ -91,8 +92,9 @@ void __init hisi_clk_register_fixed_rate(struct hisi_fixed_rate_clock *clks,
 		data->clk_data.clks[clks[i].id] = clk;
 	}
 }
+EXPORT_SYMBOL(hisi_clk_register_fixed_rate);
 
-void __init hisi_clk_register_fixed_factor(struct hisi_fixed_factor_clock *clks,
+void hisi_clk_register_fixed_factor(const struct hisi_fixed_factor_clock *clks,
 					   int nums,
 					   struct hisi_clock_data *data)
 {
@@ -112,8 +114,9 @@ void __init hisi_clk_register_fixed_factor(struct hisi_fixed_factor_clock *clks,
 		data->clk_data.clks[clks[i].id] = clk;
 	}
 }
+EXPORT_SYMBOL(hisi_clk_register_fixed_factor);
 
-void __init hisi_clk_register_mux(struct hisi_mux_clock *clks,
+void hisi_clk_register_mux(const struct hisi_mux_clock *clks,
 				  int nums, struct hisi_clock_data *data)
 {
 	struct clk *clk;
@@ -141,8 +144,9 @@ void __init hisi_clk_register_mux(struct hisi_mux_clock *clks,
 		data->clk_data.clks[clks[i].id] = clk;
 	}
 }
+EXPORT_SYMBOL(hisi_clk_register_mux);
 
-void __init hisi_clk_register_divider(struct hisi_divider_clock *clks,
+void hisi_clk_register_divider(const struct hisi_divider_clock *clks,
 				      int nums, struct hisi_clock_data *data)
 {
 	struct clk *clk;
@@ -170,8 +174,9 @@ void __init hisi_clk_register_divider(struct hisi_divider_clock *clks,
 		data->clk_data.clks[clks[i].id] = clk;
 	}
 }
+EXPORT_SYMBOL(hisi_clk_register_divider);
 
-void __init hisi_clk_register_gate(struct hisi_gate_clock *clks,
+void hisi_clk_register_gate(const struct hisi_gate_clock *clks,
 				       int nums, struct hisi_clock_data *data)
 {
 	struct clk *clk;
@@ -198,8 +203,9 @@ void __init hisi_clk_register_gate(struct hisi_gate_clock *clks,
 		data->clk_data.clks[clks[i].id] = clk;
 	}
 }
+EXPORT_SYMBOL(hisi_clk_register_gate);
 
-void __init hisi_clk_register_gate_sep(struct hisi_gate_clock *clks,
+void hisi_clk_register_gate_sep(const struct hisi_gate_clock *clks,
 				       int nums, struct hisi_clock_data *data)
 {
 	struct clk *clk;
@@ -226,8 +232,9 @@ void __init hisi_clk_register_gate_sep(struct hisi_gate_clock *clks,
 		data->clk_data.clks[clks[i].id] = clk;
 	}
 }
+EXPORT_SYMBOL(hisi_clk_register_gate_sep);
 
-void __init hi6220_clk_register_divider(struct hi6220_divider_clock *clks,
+void __init hi6220_clk_register_divider(const struct hi6220_divider_clock *clks,
 					int nums, struct hisi_clock_data *data)
 {
 	struct clk *clk;
diff --git a/drivers/clk/hisilicon/clk.h b/drivers/clk/hisilicon/clk.h
index b56fbc1..20d64af 100644
--- a/drivers/clk/hisilicon/clk.h
+++ b/drivers/clk/hisilicon/clk.h
@@ -111,18 +111,18 @@ struct clk *hi6220_register_clkdiv(struct device *dev, const char *name,
 	u8 shift, u8 width, u32 mask_bit, spinlock_t *lock);
 
 struct hisi_clock_data *hisi_clk_init(struct device_node *, int);
-void hisi_clk_register_fixed_rate(struct hisi_fixed_rate_clock *,
+void hisi_clk_register_fixed_rate(const struct hisi_fixed_rate_clock *,
 				int, struct hisi_clock_data *);
-void hisi_clk_register_fixed_factor(struct hisi_fixed_factor_clock *,
+void hisi_clk_register_fixed_factor(const struct hisi_fixed_factor_clock *,
 				int, struct hisi_clock_data *);
-void hisi_clk_register_mux(struct hisi_mux_clock *, int,
+void hisi_clk_register_mux(const struct hisi_mux_clock *, int,
 				struct hisi_clock_data *);
-void hisi_clk_register_divider(struct hisi_divider_clock *,
+void hisi_clk_register_divider(const struct hisi_divider_clock *,
 				int, struct hisi_clock_data *);
-void hisi_clk_register_gate(struct hisi_gate_clock *,
+void hisi_clk_register_gate(const struct hisi_gate_clock *,
 				int, struct hisi_clock_data *);
-void hisi_clk_register_gate_sep(struct hisi_gate_clock *,
+void hisi_clk_register_gate_sep(const struct hisi_gate_clock *,
 				int, struct hisi_clock_data *);
-void hi6220_clk_register_divider(struct hi6220_divider_clock *,
+void hi6220_clk_register_divider(const struct hi6220_divider_clock *,
 				int, struct hisi_clock_data *);
 #endif	/* __HISI_CLK_H */
diff --git a/drivers/clk/hisilicon/reset.c b/drivers/clk/hisilicon/reset.c
new file mode 100644
index 0000000..4fc7c8f
--- /dev/null
+++ b/drivers/clk/hisilicon/reset.c
@@ -0,0 +1,130 @@
+/*
+ * Hisilicon Reset Controller Driver
+ *
+ * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+#define	HISI_RESET_BIT_MASK	0x1f
+#define	HISI_RESET_OFFSET_SHIFT	8
+#define	HISI_RESET_OFFSET_MASK	0xffff00
+
+struct hisi_reset_controller {
+	spinlock_t	lock;
+	void __iomem	*membase;
+	struct reset_controller_dev	rcdev;
+};
+
+
+#define to_hisi_reset_controller(rcdev)  \
+	container_of(rcdev, struct hisi_reset_controller, rcdev)
+
+static int hisi_reset_of_xlate(struct reset_controller_dev *rcdev,
+			const struct of_phandle_args *reset_spec)
+{
+	u32 offset;
+	u8 bit;
+
+	if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
+		return -EINVAL;
+
+	offset = (reset_spec->args[0] << HISI_RESET_OFFSET_SHIFT)
+		& HISI_RESET_OFFSET_MASK;
+	bit = reset_spec->args[1] & HISI_RESET_BIT_MASK;
+	return (offset | bit);
+}
+
+static int hisi_reset_assert(struct reset_controller_dev *rcdev,
+			      unsigned long id)
+{
+	struct hisi_reset_controller *rstc = to_hisi_reset_controller(rcdev);
+	unsigned long flags;
+	u32 offset, reg;
+	u8 bit;
+
+	offset = (id & HISI_RESET_OFFSET_MASK) >> HISI_RESET_OFFSET_SHIFT;
+	bit = id & HISI_RESET_BIT_MASK;
+
+	spin_lock_irqsave(&rstc->lock, flags);
+
+	reg = readl(rstc->membase + offset);
+	writel(reg | BIT(bit), rstc->membase + offset);
+
+	spin_unlock_irqrestore(&rstc->lock, flags);
+
+	return 0;
+}
+
+static int hisi_reset_deassert(struct reset_controller_dev *rcdev,
+				unsigned long id)
+{
+	struct hisi_reset_controller *rstc = to_hisi_reset_controller(rcdev);
+	unsigned long flags;
+	u32 offset, reg;
+	u8 bit;
+
+	offset = (id & HISI_RESET_OFFSET_MASK) >> HISI_RESET_OFFSET_SHIFT;
+	bit = id & HISI_RESET_BIT_MASK;
+
+	spin_lock_irqsave(&rstc->lock, flags);
+
+	reg = readl(rstc->membase + offset);
+	writel(reg & ~BIT(bit), rstc->membase + offset);
+
+	spin_unlock_irqrestore(&rstc->lock, flags);
+
+	return 0;
+}
+
+static struct reset_control_ops hisi_reset_ops = {
+	.assert		= hisi_reset_assert,
+	.deassert	= hisi_reset_deassert,
+};
+
+int hisi_reset_init(struct device_node *np)
+{
+	struct hisi_reset_controller *rstc;
+
+	rstc = kzalloc(sizeof(*rstc), GFP_KERNEL);
+	if (!rstc)
+		return -ENOMEM;
+
+	rstc->membase = of_iomap(np, 0);
+	if (!rstc->membase)
+		return -EINVAL;
+
+	spin_lock_init(&rstc->lock);
+
+	rstc->rcdev.owner = THIS_MODULE;
+	rstc->rcdev.ops = &hisi_reset_ops;
+	rstc->rcdev.of_node = np;
+	rstc->rcdev.of_reset_n_cells = 2;
+	rstc->rcdev.of_xlate = hisi_reset_of_xlate;
+
+	return reset_controller_register(&rstc->rcdev);
+}
+EXPORT_SYMBOL(hisi_reset_init);
diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
new file mode 100644
index 0000000..ffad4d7
--- /dev/null
+++ b/drivers/clk/hisilicon/reset.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef	__HISI_RESET_H
+#define	__HISI_RESET_H
+
+struct device_node;
+
+#ifdef CONFIG_RESET_CONTROLLER
+int hisi_reset_init(struct device_node *np);
+#else
+static inline int hisi_reset_init(struct device_node *np)
+{
+	return 0;
+}
+#endif
+
+#endif	/* __HISI_RESET_H */
diff --git a/include/dt-bindings/clock/hi3519-clock.h b/include/dt-bindings/clock/hi3519-clock.h
new file mode 100644
index 0000000..4989c80
--- /dev/null
+++ b/include/dt-bindings/clock/hi3519-clock.h
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __DTS_HI3519_CLOCK_H
+#define __DTS_HI3519_CLOCK_H
+
+#define HI3519_FMC_CLK			1
+#define HI3519_USB2_BUS_CLK		2
+#define HI3519_USB2_PORT_CLK		3
+#define HI3519_USB3_CLK			4
+#define HI3519_ETH_PHY_CLK		5
+#define HI3519_ETH_MAC_CLK		6
+#define HI3519_ETH_MACIF_CLK		7
+#define HI3519_PWM_CLK			8
+#define HI3519_DMA_CLK			9
+#define HI3519_SPI0_CLK			10
+#define HI3519_SPI1_CLK			11
+#define HI3519_SPI2_CLK			12
+#define HI3519_IR_CLK			13
+#define HI3519_UART0_CLK		14
+#define HI3519_UART1_CLK		15
+#define HI3519_UART2_CLK		16
+#define HI3519_UART3_CLK		17
+#define HI3519_UART4_CLK		18
+
+#endif	/* __DTS_HI3519_CLOCK_H */
-- 
1.9.1



From xuejiancheng at huawei.com  Thu Feb  4 18:31:06 2016
From: xuejiancheng at huawei.com (Jiancheng Xue)
Date: Fri, 5 Feb 2016 10:31:06 +0800
Subject: [RESEND PATCH v8 0/6] ARM: hisi: Add initial support including clock
 driver for Hi3519 soc.
Message-ID: <1454639472-17373-1-git-send-email-xuejiancheng@huawei.com>

Hello,

Hi3519 soc is mainly used for ip camera and sport DV solutions. This patchset adds initial support
for Hi3519 soc. It includes clock driver, arch configuration, debug uart configuration and device tree.
It has been tested on hi3519 reference board.

Any comments will be appreciated!

Thanks!

Change Log
----------
v8:
--Made hi3519 clock driver can be compiled as a module
--Fixed an issue in arch/arm/Kconfig.debug

v7:
--Rebase to v4.5-rc1

v6:
-Change clock driver to a real platform driver

v5:
-Adjust clock and reset controller driver code

v4:
-Rebase to v4.4-rc7
-Divide patches according to Rob's comments
-Add spi nodes in hi3519-demb.dts

v3:
-Rebase to v4.4-rc4
-Adjust according to Arnd's comments
-Remove ARCH_HI3519, using ARCH_HISI directly

v2:
-Rebase to v4.4-rc3
-Put dt-binding doc and header file in a separate patch.
-Delete unused clocks definitions.
-Adjust the ARCH_xxx order in Kconfig file
-Rename ARCH_HI3xxx to ARCH_36xx

Jiancheng Xue (6):
  clk: hisilicon: add CRG driver for hi3519 soc
  ARM: hisi: add compatible string for Hi3519 soc
  ARM: config: hisi: enable CONFIG_RESET_CONTROLLER
  ARM: debug: add hi3519 debug uart
  ARM: dt-bindings: add device tree bindings for Hi3519 sysctrl
  ARM: dts: add dts files for Hi3519

 .../bindings/arm/hisilicon/hi3519-sysctrl.txt      |  14 ++
 .../devicetree/bindings/clock/hi3519-crg.txt       |  46 +++++
 arch/arm/Kconfig.debug                             |  10 ++
 arch/arm/boot/dts/Makefile                         |   2 +
 arch/arm/boot/dts/hi3519-demb.dts                  |  42 +++++
 arch/arm/boot/dts/hi3519.dtsi                      | 187 +++++++++++++++++++++
 arch/arm/configs/hisi_defconfig                    |   1 +
 arch/arm/mach-hisi/hisilicon.c                     |  23 +--
 drivers/clk/hisilicon/Kconfig                      |   7 +
 drivers/clk/hisilicon/Makefile                     |   2 +
 drivers/clk/hisilicon/clk-hi3519.c                 | 133 +++++++++++++++
 drivers/clk/hisilicon/clk.c                        |  23 ++-
 drivers/clk/hisilicon/clk.h                        |  14 +-
 drivers/clk/hisilicon/reset.c                      | 130 ++++++++++++++
 drivers/clk/hisilicon/reset.h                      |  32 ++++
 include/dt-bindings/clock/hi3519-clock.h           |  40 +++++
 16 files changed, 672 insertions(+), 34 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt
 create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
 create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
 create mode 100644 arch/arm/boot/dts/hi3519.dtsi
 create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
 create mode 100644 drivers/clk/hisilicon/reset.c
 create mode 100644 drivers/clk/hisilicon/reset.h
 create mode 100644 include/dt-bindings/clock/hi3519-clock.h

-- 
1.9.1



From zhaoshenglong at huawei.com  Thu Feb  4 19:05:40 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:40 +0800
Subject: [PATCH v4 05/17] xen: memory : Add new XENMAPSPACE type
 XENMAPSPACE_dev_mmio
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-6-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Add a new type of Xen map space for Dom0 to map device's MMIO region.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
---
 include/xen/interface/memory.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index 2ecfe4f..9aa8988 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -160,6 +160,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
 #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
 				    * XENMEM_add_to_physmap_range only.
 				    */
+#define XENMAPSPACE_dev_mmio     5 /* device mmio region */
 
 /*
  * Sets the GPFN at which a particular page appears in the specified guest's
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 19:05:42 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:42 +0800
Subject: [PATCH v4 07/17] Xen: ARM: Add support for mapping AMBA device mmio
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-8-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Add a bus_notifier for AMBA bus device in order to map the device
mmio regions when DOM0 booting with ACPI.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 drivers/xen/arm-device.c | 43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
index 76e26e5..3854043 100644
--- a/drivers/xen/arm-device.c
+++ b/drivers/xen/arm-device.c
@@ -139,3 +139,46 @@ static int __init register_xen_platform_notifier(void)
 }
 
 arch_initcall(register_xen_platform_notifier);
+
+#ifdef CONFIG_ARM_AMBA
+#include <linux/amba/bus.h>
+
+static int xen_amba_notifier(struct notifier_block *nb,
+			     unsigned long action, void *data)
+{
+	struct amba_device *adev = to_amba_device(data);
+	int r = 0;
+
+	switch (action) {
+	case BUS_NOTIFY_ADD_DEVICE:
+		r = xen_map_device_mmio(&adev->res, 1);
+		break;
+	case BUS_NOTIFY_DEL_DEVICE:
+		r = xen_unmap_device_mmio(&adev->res, 1);
+		break;
+	default:
+		return NOTIFY_DONE;
+	}
+	if (r)
+		dev_err(&adev->dev, "AMBA: Failed to %s device %s MMIO!\n",
+			action == BUS_NOTIFY_ADD_DEVICE ? "map" :
+			(action == BUS_NOTIFY_DEL_DEVICE ? "unmap" : "?"),
+			adev->dev.init_name);
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block amba_device_nb = {
+	.notifier_call = xen_amba_notifier,
+};
+
+static int __init register_xen_amba_notifier(void)
+{
+	if (!xen_initial_domain() || acpi_disabled)
+		return 0;
+
+	return bus_register_notifier(&amba_bustype, &amba_device_nb);
+}
+
+arch_initcall(register_xen_amba_notifier);
+#endif
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 19:05:39 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:39 +0800
Subject: [PATCH v4 04/17] arm/xen: Use xen_xlate_map_ballooned_pages to setup
 grant table
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-5-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Use xen_xlate_map_ballooned_pages to setup grant table. Then it doesn't
rely on DT or ACPI to pass the start address and size of grant table.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/xen/enlighten.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..d94f726 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -282,18 +282,10 @@ static int __init xen_guest_init(void)
 {
 	struct xen_add_to_physmap xatp;
 	struct shared_info *shared_info_page = NULL;
-	struct resource res;
-	phys_addr_t grant_frames;
 
 	if (!xen_domain())
 		return 0;
 
-	if (of_address_to_resource(xen_node, GRANT_TABLE_PHYSADDR, &res)) {
-		pr_err("Xen grant table base address not found\n");
-		return -ENODEV;
-	}
-	grant_frames = res.start;
-
 	xen_events_irq = irq_of_parse_and_map(xen_node, 0);
 	if (!xen_events_irq) {
 		pr_err("Xen event channel interrupt not found\n");
@@ -328,7 +320,10 @@ static int __init xen_guest_init(void)
 	if (xen_vcpu_info == NULL)
 		return -ENOMEM;
 
-	if (gnttab_setup_auto_xlat_frames(grant_frames)) {
+	xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+	if (xen_xlate_map_ballooned_pages(&xen_auto_xlat_grant_frames.pfn,
+					  &xen_auto_xlat_grant_frames.vaddr,
+					  xen_auto_xlat_grant_frames.count)) {
 		free_percpu(xen_vcpu_info);
 		return -ENOMEM;
 	}
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 19:05:41 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:41 +0800
Subject: [PATCH v4 06/17] Xen: ARM: Add support for mapping platform device
 mmio
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-7-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Add a bus_notifier for platform bus device in order to map the device
mmio regions when DOM0 booting with ACPI.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 drivers/xen/Makefile     |   1 +
 drivers/xen/arm-device.c | 141 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 142 insertions(+)
 create mode 100644 drivers/xen/arm-device.c

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 9b7a35c..415f286 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -9,6 +9,7 @@ CFLAGS_features.o			:= $(nostackp)
 
 CFLAGS_efi.o				+= -fshort-wchar
 
+dom0-$(CONFIG_ARM64) += arm-device.o
 dom0-$(CONFIG_PCI) += pci.o
 dom0-$(CONFIG_USB_SUPPORT) += dbgp.o
 dom0-$(CONFIG_XEN_ACPI) += acpi.o $(xen-pad-y)
diff --git a/drivers/xen/arm-device.c b/drivers/xen/arm-device.c
new file mode 100644
index 0000000..76e26e5
--- /dev/null
+++ b/drivers/xen/arm-device.c
@@ -0,0 +1,141 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * 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/platform_device.h>
+#include <linux/acpi.h>
+#include <xen/xen.h>
+#include <xen/page.h>
+#include <xen/interface/memory.h>
+#include <asm/xen/hypervisor.h>
+#include <asm/xen/hypercall.h>
+
+static int xen_unmap_device_mmio(struct resource *resource, unsigned int count)
+{
+	unsigned int i, j, nr;
+	int rc = 0;
+	struct resource *r;
+	struct xen_remove_from_physmap xrp;
+
+	for (i = 0; i < count; i++) {
+		r = &resource[i];
+		nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+		if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+			continue;
+
+		for (j = 0; j < nr; j++) {
+			xrp.domid = DOMID_SELF;
+			xrp.gpfn = XEN_PFN_DOWN(r->start) + j;
+			rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap,
+						  &xrp);
+			if (rc)
+				return rc;
+		}
+	}
+
+	return rc;
+}
+
+static int xen_map_device_mmio(struct resource *resource, unsigned int count)
+{
+	unsigned int i, j, nr;
+	int rc = 0;
+	struct resource *r;
+	xen_pfn_t *gpfns;
+	xen_ulong_t *idxs;
+	int *errs;
+	struct xen_add_to_physmap_range xatp;
+
+	for (i = 0; i < count; i++) {
+		r = &resource[i];
+		nr = DIV_ROUND_UP(resource_size(r), XEN_PAGE_SIZE);
+		if ((resource_type(r) != IORESOURCE_MEM) || (nr == 0))
+			continue;
+
+		gpfns = kzalloc(sizeof(xen_pfn_t) * nr, GFP_KERNEL);
+		idxs = kzalloc(sizeof(xen_ulong_t) * nr, GFP_KERNEL);
+		errs = kzalloc(sizeof(int) * nr, GFP_KERNEL);
+		if (!gpfns || !idxs || !errs) {
+			kfree(gpfns);
+			kfree(idxs);
+			kfree(errs);
+			return -ENOMEM;
+		}
+
+		for (j = 0; j < nr; j++) {
+			gpfns[j] = XEN_PFN_DOWN(r->start) + j;
+			idxs[j] = XEN_PFN_DOWN(r->start) + j;
+		}
+
+		xatp.domid = DOMID_SELF;
+		xatp.size = nr;
+		xatp.space = XENMAPSPACE_dev_mmio;
+
+		set_xen_guest_handle(xatp.gpfns, gpfns);
+		set_xen_guest_handle(xatp.idxs, idxs);
+		set_xen_guest_handle(xatp.errs, errs);
+
+		rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
+		kfree(gpfns);
+		kfree(idxs);
+		kfree(errs);
+		if (rc)
+			return rc;
+	}
+
+	return rc;
+}
+
+static int xen_platform_notifier(struct notifier_block *nb,
+				 unsigned long action, void *data)
+{
+	struct platform_device *pdev = to_platform_device(data);
+	int r = 0;
+
+	if (pdev->num_resources == 0 || pdev->resource == NULL)
+		return NOTIFY_OK;
+
+	switch (action) {
+	case BUS_NOTIFY_ADD_DEVICE:
+		r = xen_map_device_mmio(pdev->resource, pdev->num_resources);
+		break;
+	case BUS_NOTIFY_DEL_DEVICE:
+		r = xen_unmap_device_mmio(pdev->resource, pdev->num_resources);
+		break;
+	default:
+		return NOTIFY_DONE;
+	}
+	if (r)
+		dev_err(&pdev->dev, "Platform: Failed to %s device %s MMIO!\n",
+			action == BUS_NOTIFY_ADD_DEVICE ? "map" :
+			(action == BUS_NOTIFY_DEL_DEVICE ? "unmap" : "?"),
+			pdev->name);
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block platform_device_nb = {
+	.notifier_call = xen_platform_notifier,
+};
+
+static int __init register_xen_platform_notifier(void)
+{
+	if (!xen_initial_domain() || acpi_disabled)
+		return 0;
+
+	return bus_register_notifier(&platform_bus_type, &platform_device_nb);
+}
+
+arch_initcall(register_xen_platform_notifier);
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 19:05:37 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:37 +0800
Subject: [PATCH v4 02/17] xen/grant-table: Move xlated_setup_gnttab_pages to
 common place
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-3-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Move xlated_setup_gnttab_pages to common place, so it can be reused by
ARM to setup grant table.

Rename it to xen_xlate_map_ballooned_pages.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/x86/xen/grant-table.c | 57 +++++--------------------------------------
 drivers/xen/xlate_mmu.c    | 61 ++++++++++++++++++++++++++++++++++++++++++++++
 include/xen/xen-ops.h      |  2 ++
 3 files changed, 69 insertions(+), 51 deletions(-)

diff --git a/arch/x86/xen/grant-table.c b/arch/x86/xen/grant-table.c
index e079500..de4144c 100644
--- a/arch/x86/xen/grant-table.c
+++ b/arch/x86/xen/grant-table.c
@@ -111,63 +111,18 @@ int arch_gnttab_init(unsigned long nr_shared)
 }
 
 #ifdef CONFIG_XEN_PVH
-#include <xen/balloon.h>
 #include <xen/events.h>
-#include <linux/slab.h>
-static int __init xlated_setup_gnttab_pages(void)
-{
-	struct page **pages;
-	xen_pfn_t *pfns;
-	void *vaddr;
-	int rc;
-	unsigned int i;
-	unsigned long nr_grant_frames = gnttab_max_grant_frames();
-
-	BUG_ON(nr_grant_frames == 0);
-	pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
-	if (!pages)
-		return -ENOMEM;
-
-	pfns = kcalloc(nr_grant_frames, sizeof(pfns[0]), GFP_KERNEL);
-	if (!pfns) {
-		kfree(pages);
-		return -ENOMEM;
-	}
-	rc = alloc_xenballooned_pages(nr_grant_frames, pages);
-	if (rc) {
-		pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
-			nr_grant_frames, rc);
-		kfree(pages);
-		kfree(pfns);
-		return rc;
-	}
-	for (i = 0; i < nr_grant_frames; i++)
-		pfns[i] = page_to_pfn(pages[i]);
-
-	vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
-	if (!vaddr) {
-		pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
-			nr_grant_frames, rc);
-		free_xenballooned_pages(nr_grant_frames, pages);
-		kfree(pages);
-		kfree(pfns);
-		return -ENOMEM;
-	}
-	kfree(pages);
-
-	xen_auto_xlat_grant_frames.pfn = pfns;
-	xen_auto_xlat_grant_frames.count = nr_grant_frames;
-	xen_auto_xlat_grant_frames.vaddr = vaddr;
-
-	return 0;
-}
-
+#include <xen/xen-ops.h>
 static int __init xen_pvh_gnttab_setup(void)
 {
 	if (!xen_pvh_domain())
 		return -ENODEV;
 
-	return xlated_setup_gnttab_pages();
+	xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
+
+	return xen_xlate_map_ballooned_pages(&xen_auto_xlat_grant_frames.pfn,
+					     &xen_auto_xlat_grant_frames.vaddr,
+					     xen_auto_xlat_grant_frames.count);
 }
 /* Call it _before_ __gnttab_init as we need to initialize the
  * xen_auto_xlat_grant_frames first. */
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 5063c5e..9692656 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -29,6 +29,8 @@
  */
 #include <linux/kernel.h>
 #include <linux/mm.h>
+#include <linux/slab.h>
+#include <linux/vmalloc.h>
 
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
@@ -37,6 +39,7 @@
 #include <xen/page.h>
 #include <xen/interface/xen.h>
 #include <xen/interface/memory.h>
+#include <xen/balloon.h>
 
 typedef void (*xen_gfn_fn_t)(unsigned long gfn, void *data);
 
@@ -185,3 +188,61 @@ int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
 	return 0;
 }
 EXPORT_SYMBOL_GPL(xen_xlate_unmap_gfn_range);
+
+/**
+ * xen_xlate_map_ballooned_pages - map a new set of ballooned pages
+ * @gfns: returns the array of corresponding GFNs
+ * @virt: returns the virtual address of the mapped region
+ * @nr_grant_frames: number of GFNs
+ * @return 0 on success, error otherwise
+ *
+ * This allocates a set of ballooned pages and maps them into the
+ * kernel's address space.
+ */
+int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
+					 unsigned long nr_grant_frames)
+{
+	struct page **pages;
+	xen_pfn_t *pfns;
+	void *vaddr;
+	int rc;
+	unsigned int i;
+
+	BUG_ON(nr_grant_frames == 0);
+	pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
+	if (!pages)
+		return -ENOMEM;
+
+	pfns = kcalloc(nr_grant_frames, sizeof(pfns[0]), GFP_KERNEL);
+	if (!pfns) {
+		kfree(pages);
+		return -ENOMEM;
+	}
+	rc = alloc_xenballooned_pages(nr_grant_frames, pages);
+	if (rc) {
+		pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
+			nr_grant_frames, rc);
+		kfree(pages);
+		kfree(pfns);
+		return rc;
+	}
+	for (i = 0; i < nr_grant_frames; i++)
+		pfns[i] = page_to_pfn(pages[i]);
+
+	vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
+	if (!vaddr) {
+		pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
+			nr_grant_frames, rc);
+		free_xenballooned_pages(nr_grant_frames, pages);
+		kfree(pages);
+		kfree(pfns);
+		return -ENOMEM;
+	}
+	kfree(pages);
+
+	*gfns = pfns;
+	*virt = vaddr;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xen_xlate_map_ballooned_pages);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 86abe07..072be1c 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -85,6 +85,8 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
 			      struct page **pages);
 int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
 			      int nr, struct page **pages);
+int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
+				  unsigned long nr_grant_frames);
 
 bool xen_running_on_version_or_later(unsigned int major, unsigned int minor);
 
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 19:05:35 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:35 +0800
Subject: [PATCH v4 00/17] Add ACPI support for Xen Dom0 on ARM64
Message-ID: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen
ACPI on ARM64 design document could be found from [1].

This patch set adds a new FDT node "uefi" under /hypervisor to pass UEFI
information. Introduce a bus notifier of AMBA and Platform bus to map
the new added device's MMIO space. Make Xen domain use
xlated_setup_gnttab_pages to setup grant table and a new hypercall to
get event-channel irq.

Regarding the initialization flow of Linux kernel, it needs to move
xen_early_init() before efi_init(). Then xen_early_init() will check
whether it runs on Xen through the /hypervisor node and efi_init() will
call a new function fdt_find_xen_uefi_params(), to parse those
xen,uefi-* parameters just like the existing efi_get_fdt_params().

And in arm64_enable_runtime_services() it will check whether it runs on
Xen and call another new function xen_efi_runtime_setup() to setup
runtime service instead of efi_native_runtime_setup(). The
xen_efi_runtime_setup() will assign the runtime function pointers with
the functions of driver/xen/efi.c.

And since we pass a /hypervisor node and a /chosen node to Dom0, it
needs to check whether the DTS only contains a /hypervisor node and a
/chosen node in acpi_boot_table_init().

Patches are tested on FVP base model. The corresponding Xen patches can
be fetched from [2].

Thanks,
Shannon

[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html
[2] http://git.linaro.org/people/shannon.zhao/xen.git  ACPI_XEN_ARM_V4

Changes since v3:
* rebase on linux master
* print a warning when there is no SPCR table
* rephase the commit message of PATCH 3
* rephase the words of PATCH 13
* use strcmp and factor the function in PATCH 16
* Add several ACKs and RBs, thanks a lot


Changes since v2:
* Use 0 to check if it should ignore the UART
* Fix the use of page_to_xen_pfn
* Factor ACPI and DT parts in xen_guest_init
* Check "uefi" node by full path
* Fix the statement of Documentation/devicetree/bindings/arm/xen.txt

Changes since v1:
* Rebase on linux mainline and wallclock patch from Stefano
* Refactor AMBA and platform device MMIO map to one file
* Use EFI_PARAVIRT to check if it supports XEN EFI
* Refactor Xen EFI codes
* Address other comments

Shannon Zhao (17):
  Xen: ACPI: Hide UART used by Xen
  xen/grant-table: Move xlated_setup_gnttab_pages to common place
  Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
  arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
  xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
  Xen: ARM: Add support for mapping platform device mmio
  Xen: ARM: Add support for mapping AMBA device mmio
  Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
  xen/hvm/params: Add a new delivery type for event-channel in
    HVM_PARAM_CALLBACK_IRQ
  arm/xen: Get event-channel irq through HVM_PARAM when booting with
    ACPI
  ARM: XEN: Move xen_early_init() before efi_init()
  ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
  ARM: Xen: Document UEFI support on Xen ARM virtual platforms
  XEN: EFI: Move x86 specific codes to architecture directory
  ARM64: XEN: Add a function to initialize Xen specific UEFI runtime
    services
  FDT: Add a helper to get specified name subnode
  Xen: EFI: Parse DT parameters for Xen specific UEFI

 Documentation/devicetree/bindings/arm/xen.txt |  33 +++++
 arch/arm/include/asm/xen/xen-ops.h            |   6 +
 arch/arm/xen/Makefile                         |   1 +
 arch/arm/xen/efi.c                            |  40 ++++++
 arch/arm/xen/enlighten.c                      | 109 +++++++++++----
 arch/arm64/include/asm/xen/xen-ops.h          |   6 +
 arch/arm64/kernel/acpi.c                      |  12 +-
 arch/arm64/kernel/setup.c                     |   2 +-
 arch/arm64/xen/Makefile                       |   1 +
 arch/x86/xen/efi.c                            | 112 ++++++++++++++++
 arch/x86/xen/grant-table.c                    |  57 +-------
 drivers/acpi/bus.c                            |  38 +++++-
 drivers/firmware/efi/arm-runtime.c            |  17 ++-
 drivers/firmware/efi/efi.c                    |  45 ++++++-
 drivers/of/fdt.c                              |  25 ++++
 drivers/xen/Kconfig                           |   2 +-
 drivers/xen/Makefile                          |   1 +
 drivers/xen/arm-device.c                      | 184 ++++++++++++++++++++++++++
 drivers/xen/efi.c                             | 174 +++++-------------------
 drivers/xen/xlate_mmu.c                       |  67 ++++++++++
 include/linux/of_fdt.h                        |   2 +
 include/xen/interface/hvm/params.h            |  36 ++++-
 include/xen/interface/memory.h                |   1 +
 include/xen/xen-ops.h                         |  32 +++--
 24 files changed, 755 insertions(+), 248 deletions(-)
 create mode 100644 arch/arm/include/asm/xen/xen-ops.h
 create mode 100644 arch/arm/xen/efi.c
 create mode 100644 arch/arm64/include/asm/xen/xen-ops.h
 create mode 100644 drivers/xen/arm-device.c

-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 19:05:47 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:47 +0800
Subject: [PATCH v4 12/17] ARM64: ACPI: Check if it runs on Xen to enable or
 disable ACPI
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-13-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
a /hypervisor node in DT. So check if it needs to enable ACPI.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Acked-by: Hanjun Guo <hanjun.guo at linaro.org>
---
CC: Hanjun Guo <hanjun.guo at linaro.org>
---
 arch/arm64/kernel/acpi.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2..4e92be0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -67,10 +67,13 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
 {
 	/*
 	 * Return 1 as soon as we encounter a node at depth 1 that is
-	 * not the /chosen node.
+	 * not the /chosen node, or /hypervisor node when running on Xen.
 	 */
-	if (depth == 1 && (strcmp(uname, "chosen") != 0))
-		return 1;
+	if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
+		if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
+			return 1;
+	}
+
 	return 0;
 }
 
@@ -184,7 +187,8 @@ void __init acpi_boot_table_init(void)
 	/*
 	 * Enable ACPI instead of device tree unless
 	 * - ACPI has been disabled explicitly (acpi=off), or
-	 * - the device tree is not empty (it has more than just a /chosen node)
+	 * - the device tree is not empty (it has more than just a /chosen node,
+	 *   and a /hypervisor node when running on Xen)
 	 *   and ACPI has not been force enabled (acpi=force)
 	 */
 	if (param_acpi_off ||
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 19:05:44 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:44 +0800
Subject: [PATCH v4 09/17] xen/hvm/params: Add a new delivery type for
 event-channel in HVM_PARAM_CALLBACK_IRQ
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-10-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Add a new delivery type:
val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI.
To the flag, bit 0 stands the interrupt mode is edge(1) or level(0) and
bit 1 stands the interrupt polarity is active low(1) or high(0).

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 include/xen/interface/hvm/params.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
index 70ad208..5dd629f 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -53,6 +53,15 @@
  * if this delivery method is available.
  */
 
+#define HVM_PARAM_CALLBACK_TYPE_EVENT    3
+/*
+ * val[15:8] is flag of event-channel interrupt:
+ *  bit 0: interrupt is edge(1) or level(0) triggered
+ *  bit 1: interrupt is active low(1) or high(0)
+ * val[7:0] is PPI number used by event-channel.
+ * This is only used by ARM/ARM64.
+ */
+
 #define HVM_PARAM_STORE_PFN    1
 #define HVM_PARAM_STORE_EVTCHN 2
 
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 19:05:43 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:43 +0800
Subject: [PATCH v4 08/17] Xen: public/hvm: sync changes of
 HVM_PARAM_CALLBACK_VIA ABI from Xen
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-9-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Sync the changes of HVM_PARAM_CALLBACK_VIA ABI introduced by
Xen commit <ca5c54b6ff05> (public/hvm: export the HVM_PARAM_CALLBACK_VIA
ABI in the API).

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 include/xen/interface/hvm/params.h | 27 +++++++++++++++++++++------
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
index a6c7991..70ad208 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -27,16 +27,31 @@
  * Parameter space for HVMOP_{set,get}_param.
  */
 
+#define HVM_PARAM_CALLBACK_IRQ 0
 /*
  * How should CPU0 event-channel notifications be delivered?
- * val[63:56] == 0: val[55:0] is a delivery GSI (Global System Interrupt).
- * val[63:56] == 1: val[55:0] is a delivery PCI INTx line, as follows:
- *                  Domain = val[47:32], Bus  = val[31:16],
- *                  DevFn  = val[15: 8], IntX = val[ 1: 0]
- * val[63:56] == 2: val[7:0] is a vector number.
+ *
  * If val == 0 then CPU0 event-channel notifications are not delivered.
+ * If val != 0, val[63:56] encodes the type, as follows:
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_GSI      0
+/*
+ * val[55:0] is a delivery GSI.  GSI 0 cannot be used, as it aliases val == 0,
+ * and disables all notifications.
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_PCI_INTX 1
+/*
+ * val[55:0] is a delivery PCI INTx line:
+ * Domain = val[47:32], Bus = val[31:16] DevFn = val[15:8], IntX = val[1:0]
+ */
+
+#define HVM_PARAM_CALLBACK_TYPE_VECTOR   2
+/*
+ * val[7:0] is a vector number.  Check for XENFEAT_hvm_callback_vector to know
+ * if this delivery method is available.
  */
-#define HVM_PARAM_CALLBACK_IRQ 0
 
 #define HVM_PARAM_STORE_PFN    1
 #define HVM_PARAM_STORE_EVTCHN 2
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 19:05:45 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:45 +0800
Subject: [PATCH v4 10/17] arm/xen: Get event-channel irq through HVM_PARAM
 when booting with ACPI
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-11-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When booting with ACPI, it could get the event-channel irq through
HVM_PARAM_CALLBACK_IRQ.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/xen/enlighten.c | 36 +++++++++++++++++++++++++++++++++++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index d94f726..807a93e 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -30,6 +30,7 @@
 #include <linux/time64.h>
 #include <linux/timekeeping.h>
 #include <linux/timekeeper_internal.h>
+#include <linux/acpi.h>
 
 #include <linux/mm.h>
 
@@ -278,6 +279,35 @@ void __init xen_early_init(void)
 		add_preferred_console("hvc", 0, NULL);
 }
 
+static void __init xen_acpi_guest_init(void)
+{
+#ifdef CONFIG_ACPI
+	struct xen_hvm_param a;
+	int interrupt, trigger, polarity;
+
+	a.domid = DOMID_SELF;
+	a.index = HVM_PARAM_CALLBACK_IRQ;
+	xen_events_irq = 0;
+
+	if (!HYPERVISOR_hvm_op(HVMOP_get_param, &a)) {
+		if ((a.value >> 56) == HVM_PARAM_CALLBACK_TYPE_EVENT) {
+			interrupt = a.value & 0xff;
+			trigger = ((a.value >> 8) & 0x1) ? ACPI_EDGE_SENSITIVE
+							 : ACPI_LEVEL_SENSITIVE;
+			polarity = ((a.value >> 8) & 0x2) ? ACPI_ACTIVE_LOW
+							  : ACPI_ACTIVE_HIGH;
+			xen_events_irq = acpi_register_gsi(NULL, interrupt,
+							   trigger, polarity);
+		}
+	}
+#endif
+}
+
+static void __init xen_dt_guest_init(void)
+{
+	xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+}
+
 static int __init xen_guest_init(void)
 {
 	struct xen_add_to_physmap xatp;
@@ -286,7 +316,11 @@ static int __init xen_guest_init(void)
 	if (!xen_domain())
 		return 0;
 
-	xen_events_irq = irq_of_parse_and_map(xen_node, 0);
+	if (!acpi_disabled)
+		xen_acpi_guest_init();
+	else
+		xen_dt_guest_init();
+
 	if (!xen_events_irq) {
 		pr_err("Xen event channel interrupt not found\n");
 		return -ENODEV;
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 19:05:50 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:50 +0800
Subject: [PATCH v4 15/17] ARM64: XEN: Add a function to initialize Xen
 specific UEFI runtime services
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-16-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When running on Xen hypervisor, runtime services are supported through
hypercall. Add a Xen specific function to initialize runtime services.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/include/asm/xen/xen-ops.h   |  6 ++++++
 arch/arm/xen/Makefile                |  1 +
 arch/arm/xen/efi.c                   | 40 ++++++++++++++++++++++++++++++++++++
 arch/arm64/include/asm/xen/xen-ops.h |  6 ++++++
 arch/arm64/xen/Makefile              |  1 +
 drivers/xen/Kconfig                  |  2 +-
 6 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/asm/xen/xen-ops.h
 create mode 100644 arch/arm/xen/efi.c
 create mode 100644 arch/arm64/include/asm/xen/xen-ops.h

diff --git a/arch/arm/include/asm/xen/xen-ops.h b/arch/arm/include/asm/xen/xen-ops.h
new file mode 100644
index 0000000..ec154e7
--- /dev/null
+++ b/arch/arm/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index 1296952..2279521 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1,2 @@
 obj-y		:= enlighten.o hypercall.o grant-table.o p2m.o mm.o
+obj-$(CONFIG_XEN_EFI) += efi.o
diff --git a/arch/arm/xen/efi.c b/arch/arm/xen/efi.c
new file mode 100644
index 0000000..16db419
--- /dev/null
+++ b/arch/arm/xen/efi.c
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2015, Linaro Limited, Shannon Zhao
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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/efi.h>
+#include <xen/xen-ops.h>
+#include <asm/xen/xen-ops.h>
+
+/* Set XEN EFI runtime services function pointers. Other fields of struct efi,
+ * e.g. efi.systab, will be set like normal EFI.
+ */
+void __init xen_efi_runtime_setup(void)
+{
+	efi.get_time                 = xen_efi_get_time;
+	efi.set_time                 = xen_efi_set_time;
+	efi.get_wakeup_time          = xen_efi_get_wakeup_time;
+	efi.set_wakeup_time          = xen_efi_set_wakeup_time;
+	efi.get_variable             = xen_efi_get_variable;
+	efi.get_next_variable        = xen_efi_get_next_variable;
+	efi.set_variable             = xen_efi_set_variable;
+	efi.query_variable_info      = xen_efi_query_variable_info;
+	efi.update_capsule           = xen_efi_update_capsule;
+	efi.query_capsule_caps       = xen_efi_query_capsule_caps;
+	efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
+	efi.reset_system             = NULL; /* Functionality provided by Xen. */
+}
+EXPORT_SYMBOL_GPL(xen_efi_runtime_setup);
diff --git a/arch/arm64/include/asm/xen/xen-ops.h b/arch/arm64/include/asm/xen/xen-ops.h
new file mode 100644
index 0000000..ec154e7
--- /dev/null
+++ b/arch/arm64/include/asm/xen/xen-ops.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_XEN_OPS_H
+#define _ASM_XEN_OPS_H
+
+void xen_efi_runtime_setup(void);
+
+#endif /* _ASM_XEN_OPS_H */
diff --git a/arch/arm64/xen/Makefile b/arch/arm64/xen/Makefile
index 74a8d87..8ff8aa9 100644
--- a/arch/arm64/xen/Makefile
+++ b/arch/arm64/xen/Makefile
@@ -1,2 +1,3 @@
 xen-arm-y	+= $(addprefix ../../arm/xen/, enlighten.o grant-table.o p2m.o mm.o)
 obj-y		:= xen-arm.o hypercall.o
+obj-$(CONFIG_XEN_EFI) += $(addprefix ../../arm/xen/, efi.o)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 73708ac..d50571c 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -268,7 +268,7 @@ config XEN_HAVE_PVMMU
 
 config XEN_EFI
 	def_bool y
-	depends on X86_64 && EFI
+	depends on (ARM || ARM64 || X86_64) && EFI
 
 config XEN_AUTO_XLATE
 	def_bool y
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 19:05:48 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:48 +0800
Subject: [PATCH v4 13/17] ARM: Xen: Document UEFI support on Xen ARM virtual
 platforms
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-14-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
scan this to get the UEFI information.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Rob Herring <robh at kernel.org>
---
CC: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/arm/xen.txt | 33 +++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
index 0f7b9c2..6f83f76 100644
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -15,6 +15,26 @@ the following properties:
 - interrupts: the interrupt used by Xen to inject event notifications.
   A GIC node is also required.
 
+To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
+under /hypervisor with following parameters:
+
+________________________________________________________________________________
+Name                      | Size   | Description
+================================================================================
+xen,uefi-system-table     | 64-bit | Guest physical address of the UEFI System
+			  |	   | Table.
+--------------------------------------------------------------------------------
+xen,uefi-mmap-start       | 64-bit | Guest physical address of the UEFI memory
+			  |	   | map.
+--------------------------------------------------------------------------------
+xen,uefi-mmap-size        | 32-bit | Size in bytes of the UEFI memory map
+                          |        | pointed to in previous entry.
+--------------------------------------------------------------------------------
+xen,uefi-mmap-desc-size   | 32-bit | Size in bytes of each entry in the UEFI
+                          |        | memory map.
+--------------------------------------------------------------------------------
+xen,uefi-mmap-desc-ver    | 32-bit | Version of the mmap descriptor format.
+--------------------------------------------------------------------------------
 
 Example (assuming #address-cells = <2> and #size-cells = <2>):
 
@@ -22,4 +42,17 @@ hypervisor {
 	compatible = "xen,xen-4.3", "xen,xen";
 	reg = <0 0xb0000000 0 0x20000>;
 	interrupts = <1 15 0xf08>;
+	uefi {
+		xen,uefi-system-table = <0xXXXXXXXX>;
+		xen,uefi-mmap-start = <0xXXXXXXXX>;
+		xen,uefi-mmap-size = <0xXXXXXXXX>;
+		xen,uefi-mmap-desc-size = <0xXXXXXXXX>;
+		xen,uefi-mmap-desc-ver = <0xXXXXXXXX>;
+        };
 };
+
+The format and meaning of the "xen,uefi-*" parameters are similar to those in
+Documentation/arm/uefi.txt, which are provided by the regular UEFI stub. However
+they differ because they are provided by the Xen hypervisor, together with a set
+of UEFI runtime services implemented via hypercalls, see
+http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
-- 
2.0.4




From friesendrywall at gmail.com  Thu Feb  4 19:08:35 2016
From: friesendrywall at gmail.com (Erik Friesen)
Date: Thu, 4 Feb 2016 22:08:35 -0500
Subject: SGTL5000 misc
In-Reply-To: <CAOMZO5BxFRzi3qJAK=xDGger_MK9GZhuM00ugo836PHK_zJKjQ@mail.gmail.com>
References: <CAEuupiuhPR48Upo=8f0zV8cxf0Vefgx3qA+vC+QDWAOV4n-e3Q@mail.gmail.com>
 <CAOMZO5BPNc1ncz6J8yhcBYywCVuTxKYMYhiNUt_Jq3LZsKdi+A@mail.gmail.com>
 <CAEuupiszxAj7JkJu-5ozqgEnTWkz9FQEpxN8dmEN+KtaV-76ww@mail.gmail.com>
 <CAOMZO5DhrzdVyTVPB3FNquV4rDQ8a0MQrsJMosVsUQN63hj1Ww@mail.gmail.com>
 <CAEuupiuoB7nMSc8Fbyort1rJd=ZhYc0zfJNkd=ckUYk1qd8Z7Q@mail.gmail.com>
 <CAOMZO5C4QUHnJr=pisnYWCYZ0zUt+7HO846aPQui0zcLyX0N-Q@mail.gmail.com>
 <CAEuupivdftoopCOX3f7KRbV9poKdjdD3s9hfcbgB2TYjHmrjvw@mail.gmail.com>
 <CAEuupit8pVdnehkZkZPmq1QBHaS0sUG4NFuVFX37dKHn18j7DQ@mail.gmail.com>
 <CAOMZO5BxFRzi3qJAK=xDGger_MK9GZhuM00ugo836PHK_zJKjQ@mail.gmail.com>
Message-ID: <CAEuupium67HD-sz+ViPx8-L4S0TsS-C8ZrX3po382r=E-9QYgw@mail.gmail.com>

There is another issue here, but when I have this connected to
external power, it won't start the card on every other boot.

With the code below, it seems to start every time.  If I don't skip,
it dies on #8, which is the write of 0x7060 to CHIP_ANA_POWER

This embeddedarm board supposedly power cycles the regulators, don't
know if that is a factor or not.  The board finishes powerup 0x4060,
but comes back on reboot at the reset value of 0x7060

static int sgtl5000_fill_defaults(struct sgtl5000_priv *sgtl5000)
{
  int i, ret, val, index;
  int reg;
  for (i = 0; i < ARRAY_SIZE(sgtl5000_reg_defaults); i++) {
    val = sgtl5000_reg_defaults[i].def;
    index = sgtl5000_reg_defaults[i].reg;
    ret = regmap_read(sgtl5000->regmap, index, &reg);
    if (reg != val) {
      ret = regmap_write(sgtl5000->regmap, index, val);
    } else {
     printk(KERN_INFO "SGTL5000 probe skipped at %i with OE val of
%x\n", i, reg);
    }
  if (ret) {
    printk(KERN_WARNING "SGTL5000 probe failed at %i with OE val of
%x\n", i, reg);
    return ret;
    }
  }

  return 0;
}

On Wed, Feb 3, 2016 at 5:20 PM, Fabio Estevam <festevam at gmail.com> wrote:
> On Wed, Feb 3, 2016 at 8:05 PM, Erik Friesen <friesendrywall at gmail.com> wrote:
>> Anyway, I think something like this should be added to sgtl5000.c
>
> Yes, please send a formal patch for it.


From zhaoshenglong at huawei.com  Thu Feb  4 19:05:52 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:52 +0800
Subject: [PATCH v4 17/17] Xen: EFI: Parse DT parameters for Xen specific UEFI
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-18-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Add a new function to parse DT parameters for Xen specific UEFI just
like the way for normal UEFI. Then it could reuse the existing codes.

If Xen supports EFI, initialize runtime services.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Matt Fleming <matt at codeblueprint.co.uk>
Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
CC: Matt Fleming <matt at codeblueprint.co.uk>
---
 arch/arm/xen/enlighten.c           |  6 +++++
 drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
 drivers/firmware/efi/efi.c         | 45 ++++++++++++++++++++++++++++++++------
 3 files changed, 56 insertions(+), 12 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 0e542b8..026b5a7 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -261,6 +261,12 @@ static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
 	    !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
 		hyper_node.version = s + strlen(hyper_node.prefix);
 
+	if (IS_ENABLED(CONFIG_XEN_EFI)) {
+		/* Check if Xen supports EFI */
+		if (of_get_flat_dt_subnode_by_name(node, "uefi") > 0)
+			set_bit(EFI_PARAVIRT, &efi.flags);
+	}
+
 	return 0;
 }
 
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 6ae21e4..ac609b9 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -27,6 +27,7 @@
 #include <asm/mmu.h>
 #include <asm/pgalloc.h>
 #include <asm/pgtable.h>
+#include <asm/xen/xen-ops.h>
 
 extern u64 efi_system_table;
 
@@ -107,13 +108,19 @@ static int __init arm_enable_runtime_services(void)
 	}
 	set_bit(EFI_SYSTEM_TABLES, &efi.flags);
 
-	if (!efi_virtmap_init()) {
-		pr_err("No UEFI virtual mapping was installed -- runtime services will not be available\n");
-		return -ENOMEM;
+	if (IS_ENABLED(CONFIG_XEN_EFI) && efi_enabled(EFI_PARAVIRT)) {
+		/* Set up runtime services function pointers for Xen Dom0 */
+		xen_efi_runtime_setup();
+	} else {
+		if (!efi_virtmap_init()) {
+			pr_err("No UEFI virtual mapping was installed -- runtime services will not be available\n");
+			return -ENOMEM;
+		}
+
+		/* Set up runtime services function pointers */
+		efi_native_runtime_setup();
 	}
 
-	/* Set up runtime services function pointers */
-	efi_native_runtime_setup();
 	set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
 
 	efi.runtime_version = efi.systab->hdr.revision;
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37da..1328cb7 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -500,12 +500,14 @@ device_initcall(efi_load_efivars);
 		FIELD_SIZEOF(struct efi_fdt_params, field) \
 	}
 
-static __initdata struct {
+struct params {
 	const char name[32];
 	const char propname[32];
 	int offset;
 	int size;
-} dt_params[] = {
+};
+
+static struct params fdt_params[] __initdata = {
 	UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
 	UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
 	UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
@@ -513,24 +515,45 @@ static __initdata struct {
 	UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
 };
 
+static struct params xen_fdt_params[] __initdata = {
+	UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
+	UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
+	UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
+	UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
+	UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
+};
+
 struct param_info {
 	int found;
 	void *params;
+	struct params *dt_params;
+	int size;
 };
 
 static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
 				       int depth, void *data)
 {
 	struct param_info *info = data;
+	struct params *dt_params = info->dt_params;
 	const void *prop;
 	void *dest;
 	u64 val;
-	int i, len;
+	int i, len, offset;
 
-	if (depth != 1 || strcmp(uname, "chosen") != 0)
-		return 0;
+	if (efi_enabled(EFI_PARAVIRT)) {
+		if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+			return 0;
 
-	for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+		offset = of_get_flat_dt_subnode_by_name(node, "uefi");
+		if (offset < 0)
+			return 0;
+		node = offset;
+	} else {
+		if (depth != 1 || strcmp(uname, "chosen") != 0)
+			return 0;
+	}
+
+	for (i = 0; i < info->size; i++) {
 		prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
 		if (!prop)
 			return 0;
@@ -561,12 +584,20 @@ int __init efi_get_fdt_params(struct efi_fdt_params *params)
 	info.found = 0;
 	info.params = params;
 
+	if (efi_enabled(EFI_PARAVIRT)) {
+		info.dt_params = xen_fdt_params;
+		info.size = ARRAY_SIZE(xen_fdt_params);
+	} else {
+		info.dt_params = fdt_params;
+		info.size = ARRAY_SIZE(fdt_params);
+	}
+
 	ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
 	if (!info.found)
 		pr_info("UEFI not found.\n");
 	else if (!ret)
 		pr_err("Can't find '%s' in device tree!\n",
-		       dt_params[info.found].name);
+		       info.dt_params[info.found].name);
 
 	return ret;
 }
-- 
2.0.4




From helgaas at kernel.org  Thu Feb  4 19:10:42 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Thu, 4 Feb 2016 21:10:42 -0600
Subject: [PATCH v4 2/2] pci, pci-thunder-pem: Add PCIe host driver for
 ThunderX processors.
In-Reply-To: <56B3ECAD.4050605@caviumnetworks.com>
References: <1453844781-24380-1-git-send-email-ddaney.cavm@gmail.com>
 <1453844781-24380-3-git-send-email-ddaney.cavm@gmail.com>
 <20160205000452.GI7031@localhost>
 <56B3ECAD.4050605@caviumnetworks.com>
Message-ID: <20160205031042.GA31722@localhost>

On Thu, Feb 04, 2016 at 04:28:29PM -0800, David Daney wrote:
> On 02/04/2016 04:04 PM, Bjorn Helgaas wrote:
> >On Tue, Jan 26, 2016 at 01:46:21PM -0800, David Daney wrote:
> >>From: David Daney <david.daney at cavium.com>
> >>
> >>Some Cavium ThunderX processors require quirky access methods for the
> >>config space of the PCIe bridge.  Add a driver to provide these config
> >>space accessor functions.  The pci-host-common code is used to
> >>configure the PCI machinery.
> >>
> >>Signed-off-by: David Daney <david.daney at cavium.com>
> >>Acked-by: Rob Herring <robh at kernel.org>
> >>Acked-by: Arnd Bergmann <arnd at arndb.de>
> >>---
> >>  .../devicetree/bindings/pci/pci-thunder-pem.txt    |  43 ++++
> >>  MAINTAINERS                                        |   8 +
> >>  drivers/pci/host/Kconfig                           |   7 +
> >>  drivers/pci/host/Makefile                          |   1 +
> >>  drivers/pci/host/pci-thunder-pem.c                 | 283 +++++++++++++++++++++
> >
> >What's the significance of the "pem" part of the name?  I'm wondering
> >if we can shorten the filenames and function names by dropping it and
> >referring to this simply as "thunder" or "thunderx".
> 
> PEM == PCI Express MAC, Essentially the circuitry related to
> off-chip PCI devices.  This differentiates it from the internal
> on-chip devices which are connected to internal buses we refer to as
> "ECAMs"

That's an unusual and confusing usage of ECAM, since the PCIe spec
uses ECAM for "Enhanced Configuration Access Mechanism", which is not
a bus.

> See also the follow on patch, from me, that adds the
> pci-thunder-ecam.c driver.

OK.  In PCIe spec terms, I guess your PEM and ECAM are two separate
root complexes?  The spec defines a way to build a logical topology
and doesn't really care whether the devices are on-chip or off-chip.

> Since PEM and ECAM are terminology used in the hardware manuals that
> have specific meanings relative to the Thunder SoC family, I think
> it is not too inconvenient to carry them over into the file names.

As long as PEM and ECAM are really two distinct root complexes that
are unrelated, I guess this is OK.

I was imagining that PEM devices and ECAM devices would be in the same
hierarchy, in the same domain, in the same bus number space, but with
different ways of accessing their config space.  If that were the
case, you could have a single driver with config accessors that were
smart enough to figure out which method to use.  But if they're truly
separate and unrelated, then I guess it makes sense to have two
drivers.

Maybe a concrete example would make this clearer to me.  Can you share
a dmesg log and lspci output showing both PEM and ECAM devices?

> >>  5 files changed, 342 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-pem.txt
> >>  create mode 100644 drivers/pci/host/pci-thunder-pem.c
> >>
> 
> >>+
> >>+static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
> >>+				    int where, int size, u32 val)
> >>+{
> >>+	struct gen_pci *pci = bus->sysdata;
> >>+	struct thunder_pem_pci *pem_pci;
> >>+
> >>+	pem_pci = container_of(pci, struct thunder_pem_pci, gen_pci);
> >>+
> >>+	/*
> >>+	 * The first device on the bus in the PEM PCIe bridge.
> >>+	 * Special case its config access.
> >>+	 */
> >>+	if (bus->number == pci->cfg.bus_range->start) {
> >>+		u64 write_val, read_val;
> >>+
> >>+		if (devfn != 0 || where >= 2048)
> >>+			return PCIBIOS_DEVICE_NOT_FOUND;
> >>+
> >>+		/*
> >>+		 * 32-bit accesses only.  If the write is for a size
> >>+		 * smaller than 32-bits, we must first read the 32-bit
> >>+		 * value and merge in the desired bits and then write
> >>+		 * the whole 32-bits back out.
> >>+		 */
> >
> >Ugh.  Another device that only supports 32-bit writes.  I guess this
> >only affects this single device, and maybe you "know" that it has no
> >registers where RW1C bits may be corrupted.  Although I suppose this
> >device has the standard status registers (Status at 0x06, Secondary
> >Status at 0x1e, Device Status in PCIe capability, etc.), which do
> >contain RW1C bits.
> 
> This device is exactly the specific PCIe host bridge implementation,
> present on these SoCs.  The only sane way to access its config space
> is via 32-bit operations.  We know that it presents the appropriate
> Class and other registers to be recognized as, and operate as, a
> standard PCIe bridge.

The only sane way to manage spec-conformant 16-bit Command and Status
Registers is to use 16-bit accesses.  Using a 32-bit read/modify/write
cycle to emulate a 16-bit write to the Command register means that we
inadvertently clear any RW1C bits that happened to be set in the
adjacent Status register.

Note that these are generic PCI-defined registers, and the code doing
16-bit accesses to them may be in the PCI core or possibly in a
driver.  They're not ThunderX-specific registers, and it's not
ThunderX-specific code.

> >We need to print a warning at probe-time so we know to consider the
> >possibility of corruption when debugging.
> 
> If you really want it, I suppose I can add that, but I am somewhat hesitant.

I think this is a serious quality of implementation issue, and I do
not want to debug status bits that mysteriously get cleared when
nothing in the PCI core code even touches them.  I at least want a
hint.

We have a warning in pcie-hisi.c already, and I intend to do something
similar in tegra, xgene, and iproc, which use
pci_generic_config_write32().  There are probably others that roll
their own.  I'm thinking something along the lines of
dev_warn("sub-32-bit writes may corrupt adjacent RW1C bits").

I don't really like this either, so I'm open to better ideas.  I
considered a one-time warning in pci_generic_config_write32(), but
that would associate the message with the PCI device when the problem
is in the host bridge, and obviously it wouldn't help for ThunderX
anyway.

Bjorn


From xinliang.liu at linaro.org  Thu Feb  4 19:10:30 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri,  5 Feb 2016 11:10:30 +0800
Subject: [PATCH v2] drm: Clean up drm Makefile
Message-ID: <1454641830-19307-1-git-send-email-xinliang.liu@linaro.org>

This patch cleans up the Makefile of drm root directory.
Make core and device drivers configuration list sorted Alphabetically.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
Reviewed-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
Reviewed-by: Yifan Liu <liu_fanyi at 163.com>
---
 drivers/gpu/drm/Makefile | 102 ++++++++++++++++++++++++-----------------------
 1 file changed, 52 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 61766dec6a8d..23e57948f68f 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -2,6 +2,9 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
+CFLAGS_drm_trace_points.o := -I$(src)
+
+# core. Please keep this list sorted alphabetically
 drm-y       :=	drm_auth.o drm_bufs.o drm_cache.o \
 		drm_context.o drm_dma.o \
 		drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
@@ -13,64 +16,63 @@ drm-y       :=	drm_auth.o drm_bufs.o drm_cache.o \
 		drm_trace_points.o drm_global.o drm_prime.o \
 		drm_rect.o drm_vma_manager.o drm_flip_work.o \
 		drm_modeset_lock.o drm_atomic.o drm_bridge.o
-
-drm-$(CONFIG_COMPAT) += drm_ioc32.o
-drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 drm-$(CONFIG_PCI) += ati_pcigart.o
-drm-$(CONFIG_DRM_PANEL) += drm_panel.o
-drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o
+drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
+drm-$(CONFIG_COMPAT) += drm_ioc32.o
+drm-$(CONFIG_OF) += drm_of.o
+drm-$(CONFIG_DRM_PANEL) += drm_panel.o
+obj-$(CONFIG_DRM)	+= drm.o
+
+obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
 
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
 		drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
-drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
-
+drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
 obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
 
-CFLAGS_drm_trace_points.o := -I$(src)
+obj-$(CONFIG_DRM_TTM) += ttm/
 
-obj-$(CONFIG_DRM)	+= drm.o
-obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
-obj-$(CONFIG_DRM_TTM)	+= ttm/
-obj-$(CONFIG_DRM_TDFX)	+= tdfx/
-obj-$(CONFIG_DRM_R128)	+= r128/
-obj-$(CONFIG_HSA_AMD) += amd/amdkfd/
-obj-$(CONFIG_DRM_RADEON)+= radeon/
-obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
-obj-$(CONFIG_DRM_MGA)	+= mga/
-obj-$(CONFIG_DRM_I810)	+= i810/
-obj-$(CONFIG_DRM_I915)  += i915/
-obj-$(CONFIG_DRM_MGAG200) += mgag200/
-obj-$(CONFIG_DRM_VC4)  += vc4/
-obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
-obj-$(CONFIG_DRM_SIS)   += sis/
-obj-$(CONFIG_DRM_SAVAGE)+= savage/
-obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
-obj-$(CONFIG_DRM_VIA)	+=via/
-obj-$(CONFIG_DRM_VGEM)	+= vgem/
-obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
-obj-$(CONFIG_DRM_EXYNOS) +=exynos/
-obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
-obj-$(CONFIG_DRM_GMA500) += gma500/
-obj-$(CONFIG_DRM_UDL) += udl/
-obj-$(CONFIG_DRM_AST) += ast/
-obj-$(CONFIG_DRM_ARMADA) += armada/
+# device drivers. Please keep this list sorted alphabetically
+obj-$(CONFIG_HSA_AMD)		+= amd/amdkfd/
+obj-$(CONFIG_DRM_AMDGPU)	+= amd/amdgpu/
+obj-$(CONFIG_DRM_ARMADA)	+= armada/
+obj-$(CONFIG_DRM_AST)		+= ast/
 obj-$(CONFIG_DRM_ATMEL_HLCDC)	+= atmel-hlcdc/
-obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
-obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
-obj-y			+= omapdrm/
-obj-y			+= tilcdc/
-obj-$(CONFIG_DRM_QXL) += qxl/
-obj-$(CONFIG_DRM_BOCHS) += bochs/
-obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio/
-obj-$(CONFIG_DRM_MSM) += msm/
-obj-$(CONFIG_DRM_TEGRA) += tegra/
-obj-$(CONFIG_DRM_STI) += sti/
-obj-$(CONFIG_DRM_IMX) += imx/
-obj-y			+= i2c/
-obj-y			+= panel/
-obj-y			+= bridge/
-obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
-obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
+obj-$(CONFIG_DRM_BOCHS)		+= bochs/
+obj-y				+= bridge/
+obj-$(CONFIG_DRM_CIRRUS_QEMU)	+= cirrus/
+obj-$(CONFIG_DRM_ETNAVIV)	+= etnaviv/
+obj-$(CONFIG_DRM_EXYNOS)	+= exynos/
+obj-$(CONFIG_DRM_FSL_DCU)	+= fsl-dcu/
+obj-$(CONFIG_DRM_GMA500)	+= gma500/
+obj-y				+= i2c/
+obj-$(CONFIG_DRM_I810)		+= i810/
+obj-$(CONFIG_DRM_I915)		+= i915/
+obj-$(CONFIG_DRM_IMX)		+= imx/
+obj-$(CONFIG_DRM_MGA)		+= mga/
+obj-$(CONFIG_DRM_MGAG200)	+= mgag200/
+obj-$(CONFIG_DRM_MSM)		+= msm/
+obj-$(CONFIG_DRM_NOUVEAU)	+= nouveau/
+obj-y				+= omapdrm/
+obj-y				+= panel/
+obj-$(CONFIG_DRM_QXL)		+= qxl/
+obj-$(CONFIG_DRM_R128)		+= r128/
+obj-$(CONFIG_DRM_RADEON)	+= radeon/
+obj-$(CONFIG_DRM_RCAR_DU)	+= rcar-du/
+obj-$(CONFIG_DRM_ROCKCHIP)	+= rockchip/
+obj-$(CONFIG_DRM_SAVAGE)	+= savage/
+obj-$(CONFIG_DRM_SHMOBILE)	+= shmobile/
+obj-$(CONFIG_DRM_SIS)		+= sis/
+obj-$(CONFIG_DRM_STI)		+= sti/
+obj-$(CONFIG_DRM_TDFX)		+= tdfx/
+obj-$(CONFIG_DRM_TEGRA)		+= tegra/
+obj-y				+= tilcdc/
+obj-$(CONFIG_DRM_UDL)		+= udl/
+obj-$(CONFIG_DRM_VC4)		+= vc4/
+obj-$(CONFIG_DRM_VGEM)		+= vgem/
+obj-$(CONFIG_DRM_VIA)		+= via/
+obj-$(CONFIG_DRM_VIRTIO_GPU)	+= virtio/
+obj-$(CONFIG_DRM_VMWGFX)	+= vmwgfx/
-- 
1.9.1



From zhaoshenglong at huawei.com  Thu Feb  4 19:05:46 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:46 +0800
Subject: [PATCH v4 11/17] ARM: XEN: Move xen_early_init() before efi_init()
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-12-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Move xen_early_init() before efi_init(), then when calling efi_init()
could initialize Xen specific UEFI.

Check if it runs on Xen hypervisor through the flat dts.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/arm/xen/enlighten.c  | 56 ++++++++++++++++++++++++++++++++++-------------
 arch/arm64/kernel/setup.c |  2 +-
 2 files changed, 42 insertions(+), 16 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 807a93e..0e542b8 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -20,6 +20,7 @@
 #include <linux/irqreturn.h>
 #include <linux/module.h>
 #include <linux/of.h>
+#include <linux/of_fdt.h>
 #include <linux/of_irq.h>
 #include <linux/of_address.h>
 #include <linux/cpuidle.h>
@@ -53,8 +54,6 @@ struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 
 static __read_mostly unsigned int xen_events_irq;
 
-static __initdata struct device_node *xen_node;
-
 int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
 			       unsigned long addr,
 			       xen_pfn_t *gfn, int nr,
@@ -238,6 +237,33 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
 	return IRQ_HANDLED;
 }
 
+static __initdata struct {
+	const char *compat;
+	const char *prefix;
+	const char *version;
+	bool found;
+} hyper_node = {"xen,xen", "xen,xen-", NULL, false};
+
+static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
+				      int depth, void *data)
+{
+	const void *s = NULL;
+	int len;
+
+	if (depth != 1 || strcmp(uname, "hypervisor") != 0)
+		return 0;
+
+	if (of_flat_dt_is_compatible(node, hyper_node.compat))
+		hyper_node.found = true;
+
+	s = of_get_flat_dt_prop(node, "compatible", &len);
+	if (strlen(hyper_node.prefix) + 3  < len &&
+	    !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
+		hyper_node.version = s + strlen(hyper_node.prefix);
+
+	return 0;
+}
+
 /*
  * see Documentation/devicetree/bindings/arm/xen.txt for the
  * documentation of the Xen Device Tree format.
@@ -245,26 +271,18 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
 #define GRANT_TABLE_PHYSADDR 0
 void __init xen_early_init(void)
 {
-	int len;
-	const char *s = NULL;
-	const char *version = NULL;
-	const char *xen_prefix = "xen,xen-";
-
-	xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
-	if (!xen_node) {
+	of_scan_flat_dt(fdt_find_hyper_node, NULL);
+	if (!hyper_node.found) {
 		pr_debug("No Xen support\n");
 		return;
 	}
-	s = of_get_property(xen_node, "compatible", &len);
-	if (strlen(xen_prefix) + 3  < len &&
-			!strncmp(xen_prefix, s, strlen(xen_prefix)))
-		version = s + strlen(xen_prefix);
-	if (version == NULL) {
+
+	if (hyper_node.version == NULL) {
 		pr_debug("Xen version not found\n");
 		return;
 	}
 
-	pr_info("Xen %s support found\n", version);
+	pr_info("Xen %s support found\n", hyper_node.version);
 
 	xen_domain_type = XEN_HVM_DOMAIN;
 
@@ -305,6 +323,14 @@ static void __init xen_acpi_guest_init(void)
 
 static void __init xen_dt_guest_init(void)
 {
+	struct device_node *xen_node;
+
+	xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
+	if (!xen_node) {
+		pr_err("Xen support was detected before, but it has disappeared\n");
+		return;
+	}
+
 	xen_events_irq = irq_of_parse_and_map(xen_node, 0);
 }
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479..a4a2878 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
 	 */
 	local_async_enable();
 
+	xen_early_init();
 	efi_init();
 	arm64_memblock_init();
 
@@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
 	} else {
 		psci_acpi_init();
 	}
-	xen_early_init();
 
 	cpu_read_bootcpu_ops();
 	smp_init_cpus();
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 19:05:36 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:36 +0800
Subject: [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-2-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
CC: "Rafael J. Wysocki" <rjw at rjwysocki.net> (supporter:ACPI)
CC: Len Brown <lenb at kernel.org> (supporter:ACPI)
CC: linux-acpi at vger.kernel.org (open list:ACPI)
---
 drivers/acpi/bus.c | 38 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 891c42d..5b5433d 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -46,6 +46,7 @@ ACPI_MODULE_NAME("bus");
 struct acpi_device *acpi_root;
 struct proc_dir_entry *acpi_root_dir;
 EXPORT_SYMBOL(acpi_root_dir);
+static u64 spcr_uart_addr;
 
 #ifdef CONFIG_X86
 #ifdef CONFIG_ACPI_CUSTOM_DSDT
@@ -105,6 +106,22 @@ acpi_status acpi_bus_get_status_handle(acpi_handle handle,
 	return status;
 }
 
+static bool acpi_check_device_is_ignored(acpi_handle handle)
+{
+	acpi_status status;
+	u64 addr;
+
+	/* Check if it should ignore the UART device */
+	if (spcr_uart_addr != 0) {
+		status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL,
+					       &addr);
+		if (ACPI_SUCCESS(status) && addr == spcr_uart_addr)
+			return true;
+	}
+
+	return false;
+}
+
 int acpi_bus_get_status(struct acpi_device *device)
 {
 	acpi_status status;
@@ -114,7 +131,8 @@ int acpi_bus_get_status(struct acpi_device *device)
 	if (ACPI_FAILURE(status))
 		return -ENODEV;
 
-	acpi_set_device_status(device, sta);
+	if (!acpi_check_device_is_ignored(device->handle))
+		acpi_set_device_status(device, sta);
 
 	if (device->status.functional && !device->status.present) {
 		ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device [%s] status [%08x]: "
@@ -1070,6 +1088,8 @@ EXPORT_SYMBOL_GPL(acpi_kobj);
 static int __init acpi_init(void)
 {
 	int result;
+	acpi_status status;
+	struct acpi_table_stao *stao_ptr;
 
 	if (acpi_disabled) {
 		printk(KERN_INFO PREFIX "Interpreter disabled.\n");
@@ -1082,6 +1102,22 @@ static int __init acpi_init(void)
 		acpi_kobj = NULL;
 	}
 
+	/* If there is STAO table, check whether it needs to ignore the UART
+	 * device in SPCR table.
+	 */
+	status = acpi_get_table(ACPI_SIG_STAO, 0,
+				(struct acpi_table_header **)&stao_ptr);
+	if (ACPI_SUCCESS(status) && stao_ptr->ignore_uart) {
+		struct acpi_table_spcr *spcr_ptr;
+
+		status = acpi_get_table(ACPI_SIG_SPCR, 0,
+					(struct acpi_table_header **)&spcr_ptr);
+		if (ACPI_SUCCESS(status))
+			spcr_uart_addr = spcr_ptr->serial_port.address;
+		else
+			printk(KERN_WARNING "STAO table present, but SPCR is missing.\n");
+	}
+
 	init_acpi_device_notify();
 	result = acpi_bus_init();
 	if (result) {
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 19:05:51 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:51 +0800
Subject: [PATCH v4 16/17] FDT: Add a helper to get specified name subnode
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-17-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Sometimes it needs to check if there is a node in FDT by full path.
Introduce this helper to get the specified name subnode if it exists.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
---
CC: Rob Herring <robh at kernel.org>
---
 drivers/of/fdt.c       | 25 +++++++++++++++++++++++++
 include/linux/of_fdt.h |  2 ++
 2 files changed, 27 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79d..eacb188 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -645,6 +645,31 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,
 }
 
 /**
+ * of_get_flat_dt_subnode_by_name - get subnode of specified node by name
+ *
+ * @node: the parent node
+ * @uname: the name of subnode
+ * @return offset of the subnode, or -FDT_ERR_NOTFOUND if there is none
+ */
+
+int of_get_flat_dt_subnode_by_name(unsigned long node, const char *uname)
+{
+	const void *blob = initial_boot_params;
+	int offset;
+	const char *pathp;
+
+	for (offset = fdt_first_subnode(blob, node);
+	     offset >= 0;
+	     offset = fdt_next_subnode(blob, offset)) {
+		pathp = fdt_get_name(blob, offset, NULL);
+		if (strcmp(pathp, uname) == 0)
+			return offset;
+	}
+
+	return -FDT_ERR_NOTFOUND;
+}
+
+/**
  * of_get_flat_dt_root - find the root node in the flat blob
  */
 unsigned long __init of_get_flat_dt_root(void)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef38..fc28162 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -52,6 +52,8 @@ extern char __dtb_end[];
 extern int of_scan_flat_dt(int (*it)(unsigned long node, const char *uname,
 				     int depth, void *data),
 			   void *data);
+extern int of_get_flat_dt_subnode_by_name(unsigned long node,
+					  const char *uname);
 extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
 				       int *size);
 extern int of_flat_dt_is_compatible(unsigned long node, const char *name);
-- 
2.0.4




From zhang.chunyan at linaro.org  Thu Feb  4 19:18:41 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Fri, 5 Feb 2016 11:18:41 +0800
Subject: [PATCH V2 2/6] stm class: adds a loop to extract the first valid
 STM device name
In-Reply-To: <871t8se62k.fsf@ashishki-desk.ger.corp.intel.com>
References: <1454487337-30184-3-git-send-email-zhang.chunyan@linaro.org>
 <1454576179-27224-1-git-send-email-zhang.chunyan@linaro.org>
 <871t8se62k.fsf@ashishki-desk.ger.corp.intel.com>
Message-ID: <CAG2=9p_JACdQrrwqUaU6uqY9JzsO_xHjz7W0MXBP6Ss5B-AExA@mail.gmail.com>

On Fri, Feb 5, 2016 at 1:30 AM, Alexander Shishkin
<alexander.shishkin at linux.intel.com> wrote:
> Chunyan Zhang <zhang.chunyan at linaro.org> writes:
>
> I few comments below:
>
>> The node name of STM master management policy is a concatenation of an
>> STM device name to which this policy applies and following an arbitrary
>> string, these two strings are concatenated with a dot.
>
> This is true.
>
>> This patch adds a loop for extracting the STM device name when an
>> arbitrary number of dot(s) are found in this STM device name.
>
> It's not very easy to tell what's going on here from this
> description. The reader be left curious as to why an arbitrary number of
> dots is a reason to run a loop. When in doubt, try to imagine as if
> you're seeing this patch for the first time and ask yourself, does the
> message give a clear explanation of what's going on in it.
>
>> Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
>> ---
>>  drivers/hwtracing/stm/policy.c | 27 ++++++++++++++++-----------
>>  1 file changed, 16 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
>> index 11ab6d0..691686e 100644
>> --- a/drivers/hwtracing/stm/policy.c
>> +++ b/drivers/hwtracing/stm/policy.c
>> @@ -321,21 +321,26 @@ stp_policies_make(struct config_group *group, const char *name)
>>       /*
>>        * node must look like <device_name>.<policy_name>, where
>>        * <device_name> is the name of an existing stm device and
>> -      * <policy_name> is an arbitrary string
>> +      * <policy_name> is an arbitrary string, when an arbitrary
>> +      * number of dot(s) are found in the <device_name>, the
>> +      * first matched STM device name would be extracted.
>>        */
>
> This leaves room for a number of suspicious situations. What if both
> "xyz" and "xyz.0" are stm devices, how would you create a policy for the
> latter, for example?
>
> The rules should be such that you can tell exactly what the intended stm
> device is from a policy directory name, otherwise it's just asking for
> trouble.
>
>> -     p = strchr(devname, '.');
>> -     if (!p) {
>> -             kfree(devname);
>> -             return ERR_PTR(-EINVAL);
>> -     }
>> +     for (p = devname; ; p++) {
>> +             p = strchr(p, '.');
>> +             if (!p) {
>> +                     kfree(devname);
>> +                     return ERR_PTR(-EINVAL);
>> +             }
>>
>> -     *p++ = '\0';
>> +             *p = '\0';
>>
>> -     stm = stm_find_device(devname);
>> -     kfree(devname);
>> +             stm = stm_find_device(devname);
>> +             if (stm)
>> +                     break;
>> +             *p = '.';
>> +     }
>>
>> -     if (!stm)
>> -             return ERR_PTR(-ENODEV);
>> +     kfree(devname);
>
> In the existing code there is a clear distinction between -ENODEV, which
> is to say "we didn't find the device" and -EINVAL, "directory name
> breaks rules/is badly formatted". After the change, it's all -EINVAL,
> which also becomes "we tried everything, sorry".
>
> So, having said all that, does the following patch solve your problem:

Yes, I originally modified as well like your following patch, but at
that moment, I didn't get your agreement that the policy name (i.e. an
arbitrary string) cannot contain dots, so I had to consider the case.
Whatever, there isn't a panacea.  I'm very good with your patch.  Many
thanks for your review and providing the patch.


Chunyan

>
> From 870dc5fefa5623c39552511d31e0fa0da984d581 Mon Sep 17 00:00:00 2001
> From: Alexander Shishkin <alexander.shishkin at linux.intel.com>
> Date: Thu, 4 Feb 2016 18:56:34 +0200
> Subject: [PATCH] stm class: Support devices with multiple instances
>
> By convention, the name of the stm policy directory in configfs consists of
> the device name to which it applies and the actual policy name, separated
> by a dot. Now, some devices already have dots in their names that separate
> name of the actual device from its instance identifier. Such devices will
> result in two (or more, who can tell) dots in the policy directory name.
>
> Existing policy code, however, will treat the first dot as the one that
> separates device name from policy name, therefore failing the above case.
>
> This patch makes the last dot in the directory name be the separator, thus
> prohibiting dots from being used in policy names.
>
> Suggested-by: Chunyan Zhang <zhang.chunyan at linaro.org>
> Signed-off-by: Alexander Shishkin <alexander.shishkin at linux.intel.com>
> ---
>  drivers/hwtracing/stm/policy.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
> index 94d3abfb73..1db189657b 100644
> --- a/drivers/hwtracing/stm/policy.c
> +++ b/drivers/hwtracing/stm/policy.c
> @@ -332,10 +332,11 @@ stp_policies_make(struct config_group *group, const char *name)
>
>         /*
>          * node must look like <device_name>.<policy_name>, where
> -        * <device_name> is the name of an existing stm device and
> -        * <policy_name> is an arbitrary string
> +        * <device_name> is the name of an existing stm device; may
> +        *               contain dots;
> +        * <policy_name> is an arbitrary string; may not contain dots
>          */
> -       p = strchr(devname, '.');
> +       p = strrchr(devname, '.');
>         if (!p) {
>                 kfree(devname);
>                 return ERR_PTR(-EINVAL);
> --
> 2.7.0
>


From zhaoshenglong at huawei.com  Thu Feb  4 19:05:49 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:49 +0800
Subject: [PATCH v4 14/17] XEN: EFI: Move x86 specific codes to architecture
 directory
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-15-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Move x86 specific codes to architecture directory and export those EFI
runtime service functions. This will be useful for initializing runtime
service on ARM later.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 arch/x86/xen/efi.c    | 112 ++++++++++++++++++++++++++++++++
 drivers/xen/efi.c     | 174 ++++++++++----------------------------------------
 include/xen/xen-ops.h |  30 ++++++---
 3 files changed, 168 insertions(+), 148 deletions(-)

diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
index be14cc3..86527f1 100644
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -20,10 +20,122 @@
 #include <linux/init.h>
 #include <linux/string.h>
 
+#include <xen/xen.h>
 #include <xen/xen-ops.h>
+#include <xen/interface/platform.h>
 
 #include <asm/page.h>
 #include <asm/setup.h>
+#include <asm/xen/hypercall.h>
+
+static efi_char16_t vendor[100] __initdata;
+
+static efi_system_table_t efi_systab_xen __initdata = {
+	.hdr = {
+		.signature	= EFI_SYSTEM_TABLE_SIGNATURE,
+		.revision	= 0, /* Initialized later. */
+		.headersize	= 0, /* Ignored by Linux Kernel. */
+		.crc32		= 0, /* Ignored by Linux Kernel. */
+		.reserved	= 0
+	},
+	.fw_vendor	= EFI_INVALID_TABLE_ADDR, /* Initialized later. */
+	.fw_revision	= 0,			  /* Initialized later. */
+	.con_in_handle	= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+	.con_in		= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+	.con_out_handle	= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+	.con_out	= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+	.stderr_handle	= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+	.stderr		= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
+	.runtime	= (efi_runtime_services_t *)EFI_INVALID_TABLE_ADDR,
+						  /* Not used under Xen. */
+	.boottime	= (efi_boot_services_t *)EFI_INVALID_TABLE_ADDR,
+						  /* Not used under Xen. */
+	.nr_tables	= 0,			  /* Initialized later. */
+	.tables		= EFI_INVALID_TABLE_ADDR  /* Initialized later. */
+};
+
+static const struct efi efi_xen __initconst = {
+	.systab                   = NULL, /* Initialized later. */
+	.runtime_version	  = 0,    /* Initialized later. */
+	.mps                      = EFI_INVALID_TABLE_ADDR,
+	.acpi                     = EFI_INVALID_TABLE_ADDR,
+	.acpi20                   = EFI_INVALID_TABLE_ADDR,
+	.smbios                   = EFI_INVALID_TABLE_ADDR,
+	.smbios3                  = EFI_INVALID_TABLE_ADDR,
+	.sal_systab               = EFI_INVALID_TABLE_ADDR,
+	.boot_info                = EFI_INVALID_TABLE_ADDR,
+	.hcdp                     = EFI_INVALID_TABLE_ADDR,
+	.uga                      = EFI_INVALID_TABLE_ADDR,
+	.uv_systab                = EFI_INVALID_TABLE_ADDR,
+	.fw_vendor                = EFI_INVALID_TABLE_ADDR,
+	.runtime                  = EFI_INVALID_TABLE_ADDR,
+	.config_table             = EFI_INVALID_TABLE_ADDR,
+	.get_time                 = xen_efi_get_time,
+	.set_time                 = xen_efi_set_time,
+	.get_wakeup_time          = xen_efi_get_wakeup_time,
+	.set_wakeup_time          = xen_efi_set_wakeup_time,
+	.get_variable             = xen_efi_get_variable,
+	.get_next_variable        = xen_efi_get_next_variable,
+	.set_variable             = xen_efi_set_variable,
+	.query_variable_info      = xen_efi_query_variable_info,
+	.update_capsule           = xen_efi_update_capsule,
+	.query_capsule_caps       = xen_efi_query_capsule_caps,
+	.get_next_high_mono_count = xen_efi_get_next_high_mono_count,
+	.reset_system             = NULL, /* Functionality provided by Xen. */
+	.set_virtual_address_map  = NULL, /* Not used under Xen. */
+	.memmap                   = NULL, /* Not used under Xen. */
+	.flags			  = 0     /* Initialized later. */
+};
+
+static efi_system_table_t __init *xen_efi_probe(void)
+{
+	struct xen_platform_op op = {
+		.cmd = XENPF_firmware_info,
+		.u.firmware_info = {
+			.type = XEN_FW_EFI_INFO,
+			.index = XEN_FW_EFI_CONFIG_TABLE
+		}
+	};
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	if (!xen_initial_domain() || HYPERVISOR_platform_op(&op) < 0)
+		return NULL;
+
+	/* Here we know that Xen runs on EFI platform. */
+
+	efi = efi_xen;
+
+	efi_systab_xen.tables = info->cfg.addr;
+	efi_systab_xen.nr_tables = info->cfg.nent;
+
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+	op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
+	info->vendor.bufsz = sizeof(vendor);
+	set_xen_guest_handle(info->vendor.name, vendor);
+
+	if (HYPERVISOR_platform_op(&op) == 0) {
+		efi_systab_xen.fw_vendor = __pa_symbol(vendor);
+		efi_systab_xen.fw_revision = info->vendor.revision;
+	} else
+		efi_systab_xen.fw_vendor = __pa_symbol(L"UNKNOWN");
+
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+	op.u.firmware_info.index = XEN_FW_EFI_VERSION;
+
+	if (HYPERVISOR_platform_op(&op) == 0)
+		efi_systab_xen.hdr.revision = info->version;
+
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+	op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION;
+
+	if (HYPERVISOR_platform_op(&op) == 0)
+		efi.runtime_version = info->version;
+
+	return &efi_systab_xen;
+}
 
 void __init xen_efi_init(void)
 {
diff --git a/drivers/xen/efi.c b/drivers/xen/efi.c
index be7e56a..22f71ff 100644
--- a/drivers/xen/efi.c
+++ b/drivers/xen/efi.c
@@ -38,7 +38,7 @@
 
 #define efi_data(op)	(op.u.efi_runtime_call)
 
-static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
+efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
 {
 	struct xen_platform_op op = INIT_EFI_OP(get_time);
 
@@ -59,8 +59,9 @@ static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
 
 	return efi_data(op).status;
 }
+EXPORT_SYMBOL_GPL(xen_efi_get_time);
 
-static efi_status_t xen_efi_set_time(efi_time_t *tm)
+efi_status_t xen_efi_set_time(efi_time_t *tm)
 {
 	struct xen_platform_op op = INIT_EFI_OP(set_time);
 
@@ -72,10 +73,10 @@ static efi_status_t xen_efi_set_time(efi_time_t *tm)
 
 	return efi_data(op).status;
 }
+EXPORT_SYMBOL_GPL(xen_efi_set_time);
 
-static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled,
-					    efi_bool_t *pending,
-					    efi_time_t *tm)
+efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, efi_bool_t *pending,
+				     efi_time_t *tm)
 {
 	struct xen_platform_op op = INIT_EFI_OP(get_wakeup_time);
 
@@ -95,8 +96,9 @@ static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled,
 
 	return efi_data(op).status;
 }
+EXPORT_SYMBOL_GPL(xen_efi_get_wakeup_time);
 
-static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
+efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
 {
 	struct xen_platform_op op = INIT_EFI_OP(set_wakeup_time);
 
@@ -113,12 +115,11 @@ static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm)
 
 	return efi_data(op).status;
 }
+EXPORT_SYMBOL_GPL(xen_efi_set_wakeup_time);
 
-static efi_status_t xen_efi_get_variable(efi_char16_t *name,
-					 efi_guid_t *vendor,
-					 u32 *attr,
-					 unsigned long *data_size,
-					 void *data)
+efi_status_t xen_efi_get_variable(efi_char16_t *name, efi_guid_t *vendor,
+				  u32 *attr, unsigned long *data_size,
+				  void *data)
 {
 	struct xen_platform_op op = INIT_EFI_OP(get_variable);
 
@@ -138,10 +139,11 @@ static efi_status_t xen_efi_get_variable(efi_char16_t *name,
 
 	return efi_data(op).status;
 }
+EXPORT_SYMBOL_GPL(xen_efi_get_variable);
 
-static efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
-					      efi_char16_t *name,
-					      efi_guid_t *vendor)
+efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
+				       efi_char16_t *name,
+				       efi_guid_t *vendor)
 {
 	struct xen_platform_op op = INIT_EFI_OP(get_next_variable_name);
 
@@ -161,12 +163,11 @@ static efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
 
 	return efi_data(op).status;
 }
+EXPORT_SYMBOL_GPL(xen_efi_get_next_variable);
 
-static efi_status_t xen_efi_set_variable(efi_char16_t *name,
-					 efi_guid_t *vendor,
-					 u32 attr,
-					 unsigned long data_size,
-					 void *data)
+efi_status_t xen_efi_set_variable(efi_char16_t *name, efi_guid_t *vendor,
+				 u32 attr, unsigned long data_size,
+				 void *data)
 {
 	struct xen_platform_op op = INIT_EFI_OP(set_variable);
 
@@ -183,11 +184,11 @@ static efi_status_t xen_efi_set_variable(efi_char16_t *name,
 
 	return efi_data(op).status;
 }
+EXPORT_SYMBOL_GPL(xen_efi_set_variable);
 
-static efi_status_t xen_efi_query_variable_info(u32 attr,
-						u64 *storage_space,
-						u64 *remaining_space,
-						u64 *max_variable_size)
+efi_status_t xen_efi_query_variable_info(u32 attr, u64 *storage_space,
+					 u64 *remaining_space,
+					 u64 *max_variable_size)
 {
 	struct xen_platform_op op = INIT_EFI_OP(query_variable_info);
 
@@ -205,8 +206,9 @@ static efi_status_t xen_efi_query_variable_info(u32 attr,
 
 	return efi_data(op).status;
 }
+EXPORT_SYMBOL_GPL(xen_efi_query_variable_info);
 
-static efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
+efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
 {
 	struct xen_platform_op op = INIT_EFI_OP(get_next_high_monotonic_count);
 
@@ -217,10 +219,10 @@ static efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
 
 	return efi_data(op).status;
 }
+EXPORT_SYMBOL_GPL(xen_efi_get_next_high_mono_count);
 
-static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
-					   unsigned long count,
-					   unsigned long sg_list)
+efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
+				    unsigned long count, unsigned long sg_list)
 {
 	struct xen_platform_op op = INIT_EFI_OP(update_capsule);
 
@@ -237,11 +239,11 @@ static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
 
 	return efi_data(op).status;
 }
+EXPORT_SYMBOL_GPL(xen_efi_update_capsule);
 
-static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
-					       unsigned long count,
-					       u64 *max_size,
-					       int *reset_type)
+efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
+					unsigned long count, u64 *max_size,
+					int *reset_type)
 {
 	struct xen_platform_op op = INIT_EFI_OP(query_capsule_capabilities);
 
@@ -260,112 +262,4 @@ static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
 
 	return efi_data(op).status;
 }
-
-static efi_char16_t vendor[100] __initdata;
-
-static efi_system_table_t efi_systab_xen __initdata = {
-	.hdr = {
-		.signature	= EFI_SYSTEM_TABLE_SIGNATURE,
-		.revision	= 0, /* Initialized later. */
-		.headersize	= 0, /* Ignored by Linux Kernel. */
-		.crc32		= 0, /* Ignored by Linux Kernel. */
-		.reserved	= 0
-	},
-	.fw_vendor	= EFI_INVALID_TABLE_ADDR, /* Initialized later. */
-	.fw_revision	= 0,			  /* Initialized later. */
-	.con_in_handle	= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
-	.con_in		= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
-	.con_out_handle	= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
-	.con_out	= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
-	.stderr_handle	= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
-	.stderr		= EFI_INVALID_TABLE_ADDR, /* Not used under Xen. */
-	.runtime	= (efi_runtime_services_t *)EFI_INVALID_TABLE_ADDR,
-						  /* Not used under Xen. */
-	.boottime	= (efi_boot_services_t *)EFI_INVALID_TABLE_ADDR,
-						  /* Not used under Xen. */
-	.nr_tables	= 0,			  /* Initialized later. */
-	.tables		= EFI_INVALID_TABLE_ADDR  /* Initialized later. */
-};
-
-static const struct efi efi_xen __initconst = {
-	.systab                   = NULL, /* Initialized later. */
-	.runtime_version	  = 0,    /* Initialized later. */
-	.mps                      = EFI_INVALID_TABLE_ADDR,
-	.acpi                     = EFI_INVALID_TABLE_ADDR,
-	.acpi20                   = EFI_INVALID_TABLE_ADDR,
-	.smbios                   = EFI_INVALID_TABLE_ADDR,
-	.smbios3                  = EFI_INVALID_TABLE_ADDR,
-	.sal_systab               = EFI_INVALID_TABLE_ADDR,
-	.boot_info                = EFI_INVALID_TABLE_ADDR,
-	.hcdp                     = EFI_INVALID_TABLE_ADDR,
-	.uga                      = EFI_INVALID_TABLE_ADDR,
-	.uv_systab                = EFI_INVALID_TABLE_ADDR,
-	.fw_vendor                = EFI_INVALID_TABLE_ADDR,
-	.runtime                  = EFI_INVALID_TABLE_ADDR,
-	.config_table             = EFI_INVALID_TABLE_ADDR,
-	.get_time                 = xen_efi_get_time,
-	.set_time                 = xen_efi_set_time,
-	.get_wakeup_time          = xen_efi_get_wakeup_time,
-	.set_wakeup_time          = xen_efi_set_wakeup_time,
-	.get_variable             = xen_efi_get_variable,
-	.get_next_variable        = xen_efi_get_next_variable,
-	.set_variable             = xen_efi_set_variable,
-	.query_variable_info      = xen_efi_query_variable_info,
-	.update_capsule           = xen_efi_update_capsule,
-	.query_capsule_caps       = xen_efi_query_capsule_caps,
-	.get_next_high_mono_count = xen_efi_get_next_high_mono_count,
-	.reset_system             = NULL, /* Functionality provided by Xen. */
-	.set_virtual_address_map  = NULL, /* Not used under Xen. */
-	.memmap                   = NULL, /* Not used under Xen. */
-	.flags			  = 0     /* Initialized later. */
-};
-
-efi_system_table_t __init *xen_efi_probe(void)
-{
-	struct xen_platform_op op = {
-		.cmd = XENPF_firmware_info,
-		.u.firmware_info = {
-			.type = XEN_FW_EFI_INFO,
-			.index = XEN_FW_EFI_CONFIG_TABLE
-		}
-	};
-	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
-
-	if (!xen_initial_domain() || HYPERVISOR_platform_op(&op) < 0)
-		return NULL;
-
-	/* Here we know that Xen runs on EFI platform. */
-
-	efi = efi_xen;
-
-	efi_systab_xen.tables = info->cfg.addr;
-	efi_systab_xen.nr_tables = info->cfg.nent;
-
-	op.cmd = XENPF_firmware_info;
-	op.u.firmware_info.type = XEN_FW_EFI_INFO;
-	op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
-	info->vendor.bufsz = sizeof(vendor);
-	set_xen_guest_handle(info->vendor.name, vendor);
-
-	if (HYPERVISOR_platform_op(&op) == 0) {
-		efi_systab_xen.fw_vendor = __pa_symbol(vendor);
-		efi_systab_xen.fw_revision = info->vendor.revision;
-	} else
-		efi_systab_xen.fw_vendor = __pa_symbol(L"UNKNOWN");
-
-	op.cmd = XENPF_firmware_info;
-	op.u.firmware_info.type = XEN_FW_EFI_INFO;
-	op.u.firmware_info.index = XEN_FW_EFI_VERSION;
-
-	if (HYPERVISOR_platform_op(&op) == 0)
-		efi_systab_xen.hdr.revision = info->version;
-
-	op.cmd = XENPF_firmware_info;
-	op.u.firmware_info.type = XEN_FW_EFI_INFO;
-	op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION;
-
-	if (HYPERVISOR_platform_op(&op) == 0)
-		efi.runtime_version = info->version;
-
-	return &efi_systab_xen;
-}
+EXPORT_SYMBOL_GPL(xen_efi_query_capsule_caps);
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 072be1c..3491582 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -90,14 +90,28 @@ int xen_xlate_map_ballooned_pages(xen_pfn_t **pfns, void **vaddr,
 
 bool xen_running_on_version_or_later(unsigned int major, unsigned int minor);
 
-#ifdef CONFIG_XEN_EFI
-extern efi_system_table_t *xen_efi_probe(void);
-#else
-static inline efi_system_table_t __init *xen_efi_probe(void)
-{
-	return NULL;
-}
-#endif
+efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc);
+efi_status_t xen_efi_set_time(efi_time_t *tm);
+efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, efi_bool_t *pending,
+				     efi_time_t *tm);
+efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm);
+efi_status_t xen_efi_get_variable(efi_char16_t *name, efi_guid_t *vendor,
+				  u32 *attr, unsigned long *data_size,
+				  void *data);
+efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
+				       efi_char16_t *name, efi_guid_t *vendor);
+efi_status_t xen_efi_set_variable(efi_char16_t *name, efi_guid_t *vendor,
+				  u32 attr, unsigned long data_size,
+				  void *data);
+efi_status_t xen_efi_query_variable_info(u32 attr, u64 *storage_space,
+					 u64 *remaining_space,
+					 u64 *max_variable_size);
+efi_status_t xen_efi_get_next_high_mono_count(u32 *count);
+efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
+				    unsigned long count, unsigned long sg_list);
+efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules,
+					unsigned long count, u64 *max_size,
+					int *reset_type);
 
 #ifdef CONFIG_PREEMPT
 
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 19:05:38 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 11:05:38 +0800
Subject: [PATCH v4 03/17] Xen: xlate: Use page_to_xen_pfn instead of
 page_to_pfn
In-Reply-To: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454641552-12576-4-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Make xen_xlate_map_ballooned_pages work with 64K pages. In that case
Kernel pages are 64K in size but Xen pages remain 4K in size. Xen pfns
refer to 4K pages.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
---
 drivers/xen/xlate_mmu.c | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 9692656..28f728b 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -207,9 +207,12 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
 	void *vaddr;
 	int rc;
 	unsigned int i;
+	unsigned long nr_pages;
+	xen_pfn_t xen_pfn = 0;
 
 	BUG_ON(nr_grant_frames == 0);
-	pages = kcalloc(nr_grant_frames, sizeof(pages[0]), GFP_KERNEL);
+	nr_pages = DIV_ROUND_UP(nr_grant_frames, XEN_PFN_PER_PAGE);
+	pages = kcalloc(nr_pages, sizeof(pages[0]), GFP_KERNEL);
 	if (!pages)
 		return -ENOMEM;
 
@@ -218,22 +221,25 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns, void **virt,
 		kfree(pages);
 		return -ENOMEM;
 	}
-	rc = alloc_xenballooned_pages(nr_grant_frames, pages);
+	rc = alloc_xenballooned_pages(nr_pages, pages);
 	if (rc) {
-		pr_warn("%s Couldn't balloon alloc %ld pfns rc:%d\n", __func__,
-			nr_grant_frames, rc);
+		pr_warn("%s Couldn't balloon alloc %ld pages rc:%d\n", __func__,
+			nr_pages, rc);
 		kfree(pages);
 		kfree(pfns);
 		return rc;
 	}
-	for (i = 0; i < nr_grant_frames; i++)
-		pfns[i] = page_to_pfn(pages[i]);
+	for (i = 0; i < nr_grant_frames; i++) {
+		if ((i % XEN_PFN_PER_PAGE) == 0)
+			xen_pfn = page_to_xen_pfn(pages[i / XEN_PFN_PER_PAGE]);
+		pfns[i] = pfn_to_gfn(xen_pfn++);
+	}
 
-	vaddr = vmap(pages, nr_grant_frames, 0, PAGE_KERNEL);
+	vaddr = vmap(pages, nr_pages, 0, PAGE_KERNEL);
 	if (!vaddr) {
-		pr_warn("%s Couldn't map %ld pfns rc:%d\n", __func__,
-			nr_grant_frames, rc);
-		free_xenballooned_pages(nr_grant_frames, pages);
+		pr_warn("%s Couldn't map %ld pages rc:%d\n", __func__,
+			nr_pages, rc);
+		free_xenballooned_pages(nr_pages, pages);
 		kfree(pages);
 		kfree(pfns);
 		return -ENOMEM;
-- 
2.0.4




From wenyou.yang at atmel.com  Thu Feb  4 19:36:28 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Fri, 5 Feb 2016 11:36:28 +0800
Subject: [PATCH v10 0/2] mfd: act8945a: add Active-semi ACT8945A PMIC MFD
 driver
Message-ID: <1454643390-16910-1-git-send-email-wenyou.yang@atmel.com>

This patch set adds support for the Active-semi ACT8945A PMIC
MFD driver. It is a Multi Function Device with the following
subdevices:
 - Regulator
 - Charger

It is interfaced to the host controller using I2C interface,
ACT8945A is a child device of the I2C.

Changes in v10:
 - remove the mfd cell .of_compatible.
 - update the example, due to the subdevices are not regarded as
   a child node.

Changes in v9:
 - remove unneeded struct act8945a_dev structure.
 - collect Acked from Lee.
 - collect Acked from Peter.

Changes in v8:
 - change the subdevice's name "act8945a-pmic" to "act8945a-regulator".

Changes in v7:
 - remove struct act8945a_dev to .c file.
 - remove unused .h file.
 - collect Acked-by from Lee Jones

Changes in v6:
 - change MFD_ACT8945A type from bool to tristate.
 - revert depends on to 'I2C'.
 - change the regulator name.

Changes in v5:
 - change depends on to 'I2C=y'.

Changes in v4:
 - add a space before .compatible.
 - collect Reviewed-by from Krzysztof Kozlowski.

Changes in v3:
 - fix the tabbing errors in Example.
 - use "pmic at 5b" label, not "act8945a at 5b" in Example.
 - collect Acked-by from Rob.

Changes in v2:
 - add more help information in Kconfig.
 - update the file header with short version license and author line.
 - remove unused structure members (dev, i2c_client) of stuct act8945a_dev.
 - use define "PLATFORM_DEVID_NONE" for mfd_add_devices(), instead of '-1'.
 - use more explicit info to indicate the failure to add sub devices.
 - remove the unnecessary print out.
 - substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").
 - use more specific label in Example.
 - add pmic and charger nodes in Example.

Wenyou Yang (2):
  mfd: act8945a: add Active-semi ACT8945A PMIC MFD driver
  mfd: add documentation for ACT8945A DT bindings

 Documentation/devicetree/bindings/mfd/act8945a.txt |   76 +++++++++++++++
 drivers/mfd/Kconfig                                |   11 +++
 drivers/mfd/Makefile                               |    1 +
 drivers/mfd/act8945a.c                             |  102 ++++++++++++++++++++
 4 files changed, 190 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/act8945a.txt
 create mode 100644 drivers/mfd/act8945a.c

-- 
1.7.9.5



From wenyou.yang at atmel.com  Thu Feb  4 19:36:29 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Fri, 5 Feb 2016 11:36:29 +0800
Subject: [PATCH v10 1/2] mfd: act8945a: add Active-semi ACT8945A PMIC MFD
 driver
In-Reply-To: <1454643390-16910-1-git-send-email-wenyou.yang@atmel.com>
References: <1454643390-16910-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1454643390-16910-2-git-send-email-wenyou.yang@atmel.com>

This patch adds support for the Active-semi ACT8945A PMIC.
It is a Multi Function Device with the following subdevices:
 - Regulator
 - Charger

It is interfaced to the host controller using I2C interface,
ACT8945A is a child device of the I2C.

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
Acked-by: Lee Jones <lee.jones at linaro.org>
Acked-by: Peter Korsgaard <peter at korsgaard.com>
---

Changes in v10:
 - remove the mfd cell .of_compatible.

Changes in v9:
 - remove unneeded struct act8945a_dev structure.
 - collect Acked from Lee.
 - collect Acked from Peter.

Changes in v8:
 - change the subdevice's name "act8945a-pmic" to "act8945a-regulator".

Changes in v7:
 - remove struct act8945a_dev to .c file.
 - remove unused .h file.

Changes in v6:
 - change MFD_ACT8945A type from bool to tristate.
 - revert depends on to 'I2C'.

Changes in v5:
 - change depends on to 'I2C=y'.

Changes in v4:
 - add a space before .compatible.
 - collect Reviewed-by from Krzysztof Kozlowski.

Changes in v3: None
Changes in v2:
 - add more help information in Kconfig.
 - update the file header with short version license and author line.
 - remove unused structure members (dev, i2c_client) of stuct act8945a_dev.
 - use define "PLATFORM_DEVID_NONE" for mfd_add_devices(), instead of '-1'.
 - use more explicit info to indicate the failure to add sub devices.
 - remove the unnecessary print out.
 - substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").

 drivers/mfd/Kconfig    |   11 ++++++
 drivers/mfd/Makefile   |    1 +
 drivers/mfd/act8945a.c |  102 ++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 114 insertions(+)
 create mode 100644 drivers/mfd/act8945a.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6c4ebd9..38994bb 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -18,6 +18,17 @@ config MFD_CS5535
 	  This is the core driver for CS5535/CS5536 MFD functions.  This is
           necessary for using the board's GPIO and MFGPT functionality.
 
+config MFD_ACT8945A
+	tristate "Active-semi ACT8945A"
+	select MFD_CORE
+	select REGMAP_I2C
+	depends on I2C && OF
+	help
+	  Support for the ACT8945A PMIC from Active-semi. This device
+	  features three step-down DC/DC converters and four low-dropout
+	  linear regulators, along with a complete ActivePath battery
+	  charger.
+
 config MFD_AS3711
 	bool "AMS AS3711"
 	select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 0f230a6..2f1ca82 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -6,6 +6,7 @@
 obj-$(CONFIG_MFD_88PM860X)	+= 88pm860x.o
 obj-$(CONFIG_MFD_88PM800)	+= 88pm800.o 88pm80x.o
 obj-$(CONFIG_MFD_88PM805)	+= 88pm805.o 88pm80x.o
+obj-$(CONFIG_MFD_ACT8945A)	+= act8945a.o
 obj-$(CONFIG_MFD_SM501)		+= sm501.o
 obj-$(CONFIG_MFD_ASIC3)		+= asic3.o tmio_core.o
 obj-$(CONFIG_MFD_BCM590XX)	+= bcm590xx.o
diff --git a/drivers/mfd/act8945a.c b/drivers/mfd/act8945a.c
new file mode 100644
index 0000000..525b546
--- /dev/null
+++ b/drivers/mfd/act8945a.c
@@ -0,0 +1,102 @@
+/*
+ * MFD driver for Active-semi ACT8945a PMIC
+ *
+ * Copyright (C) 2015 Atmel Corporation.
+ *
+ * Author: Wenyou Yang <wenyou.yang at atmel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under  the terms of the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/i2c.h>
+#include <linux/mfd/core.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+
+static const struct mfd_cell act8945a_devs[] = {
+	{
+		.name = "act8945a-regulator",
+	},
+	{
+		.name = "act8945a-charger",
+	},
+};
+
+static const struct regmap_config act8945a_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+};
+
+static int act8945a_i2c_probe(struct i2c_client *i2c,
+			      const struct i2c_device_id *id)
+{
+	int ret;
+	struct regmap *regmap;
+
+	regmap = devm_regmap_init_i2c(i2c, &act8945a_regmap_config);
+	if (IS_ERR(regmap)) {
+		ret = PTR_ERR(regmap);
+		dev_err(&i2c->dev, "regmap init failed: %d\n", ret);
+		return ret;
+	}
+
+	i2c_set_clientdata(i2c, regmap);
+
+	ret = mfd_add_devices(&i2c->dev, PLATFORM_DEVID_NONE, act8945a_devs,
+			      ARRAY_SIZE(act8945a_devs), NULL, 0, NULL);
+	if (ret) {
+		dev_err(&i2c->dev, "Failed to add sub devices\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static int act8945a_i2c_remove(struct i2c_client *i2c)
+{
+	mfd_remove_devices(&i2c->dev);
+
+	return 0;
+}
+
+static const struct i2c_device_id act8945a_i2c_id[] = {
+	{ "act8945a", 0 },
+	{}
+};
+MODULE_DEVICE_TABLE(i2c, act8945a_i2c_id);
+
+static const struct of_device_id act8945a_of_match[] = {
+	{ .compatible = "active-semi,act8945a", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, act8945a_of_match);
+
+static struct i2c_driver act8945a_i2c_driver = {
+	.driver = {
+		   .name = "act8945a",
+		   .of_match_table = of_match_ptr(act8945a_of_match),
+	},
+	.probe = act8945a_i2c_probe,
+	.remove = act8945a_i2c_remove,
+	.id_table = act8945a_i2c_id,
+};
+
+static int __init act8945a_i2c_init(void)
+{
+	return i2c_add_driver(&act8945a_i2c_driver);
+}
+subsys_initcall(act8945a_i2c_init);
+
+static void __exit act8945a_i2c_exit(void)
+{
+	i2c_del_driver(&act8945a_i2c_driver);
+}
+module_exit(act8945a_i2c_exit);
+
+MODULE_DESCRIPTION("ACT8945A PMIC multi-function driver");
+MODULE_AUTHOR("Wenyou Yang <wenyou.yang at atmel.com>");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5



From wenyou.yang at atmel.com  Thu Feb  4 19:36:30 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Fri, 5 Feb 2016 11:36:30 +0800
Subject: [PATCH v10 2/2] mfd: add documentation for ACT8945A DT bindings
In-Reply-To: <1454643390-16910-1-git-send-email-wenyou.yang@atmel.com>
References: <1454643390-16910-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1454643390-16910-3-git-send-email-wenyou.yang@atmel.com>

The Active-semi ACT8945A PMIC is a Multi-Function Device, it has
two subdevices:
 - Regulator
 - Charger

This patch adds documentation for ACT8945A DT bindings.

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
Acked-by: Rob Herring <robh at kernel.org>
Acked-by: Lee Jones <lee.jones at linaro.org>
---

Changes in v10:
 - update the example, due to the subdevices are not regarded as
   a child node.

Changes in v9: None
Changes in v8: None
Changes in v7:
 - collect Acked-by from Lee Jones

Changes in v6:
 - change the regulator name.

Changes in v5: None
Changes in v4: None
Changes in v3:
 - fix the tabbing errors in Example.
 - use "pmic at 5b" label, not "act8945a at 5b" in Example.
 - collect Acked-by from Rob.

Changes in v2:
 - use more specific label in Example.
 - add pmic and charger nodes in Example.

 Documentation/devicetree/bindings/mfd/act8945a.txt |   76 ++++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/act8945a.txt

diff --git a/Documentation/devicetree/bindings/mfd/act8945a.txt b/Documentation/devicetree/bindings/mfd/act8945a.txt
new file mode 100644
index 0000000..f712830
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/act8945a.txt
@@ -0,0 +1,76 @@
+Device-Tree bindings for Active-semi ACT8945A MFD driver
+
+Required properties:
+ - compatible: "active-semi,act8945a".
+ - reg: the I2C slave address for the ACT8945A chip
+
+The chip exposes two subdevices:
+ - a regulators: see ../regulator/act8945a-regulator.txt
+ - a charger: see ../power/act8945a-charger.txt
+
+Example:
+	pmic at 5b {
+		compatible = "active-semi,act8945a";
+		reg = <0x5b>;
+		status = "okay";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_charger_chglev>;
+		active-semi,chglev-gpio = <&pioA 12 GPIO_ACTIVE_HIGH>;
+		active-semi,input-voltage-threshold-microvolt = <6600>;
+		active-semi,precondition-timeout = <40>;
+		active-semi,total-timeout = <3>;
+
+		active-semi,vsel-high;
+
+		regulators {
+			vdd_1v35_reg: REG_DCDC1 {
+				regulator-name = "VDD_1V35";
+				regulator-min-microvolt = <1350000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-always-on;
+			};
+
+			vdd_1v2_reg: REG_DCDC2 {
+				regulator-name = "VDD_1V2";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1300000>;
+				regulator-always-on;
+			};
+
+			vdd_3v3_reg: REG_DCDC3 {
+				regulator-name = "VDD_3V3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vdd_fuse_reg: REG_LDO1 {
+				regulator-name = "VDD_FUSE";
+				regulator-min-microvolt = <2500000>;
+				regulator-max-microvolt = <2500000>;
+				regulator-always-on;
+			};
+
+			vdd_3v3_lp_reg: REG_LDO2 {
+				regulator-name = "VDD_3V3_LP";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vdd_led_reg: REG_LDO3 {
+				regulator-name = "VDD_LED";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vdd_sdhc_1v8_reg: REG_LDO4 {
+				regulator-name = "VDD_SDHC_1V8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-always-on;
+			};
+		};
+	};
-- 
1.7.9.5



From kishon at ti.com  Thu Feb  4 20:19:55 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 5 Feb 2016 09:49:55 +0530
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <56B087AD.4000505@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
Message-ID: <56B422EB.5000603@ti.com>

Hi Paul,

On Tuesday 02 February 2016 04:10 PM, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Friday 29 January 2016 12:01 AM, Tony Lindgren wrote:
>> * Suman Anna <s-anna at ti.com> [160127 15:17]:
>>> On 01/27/2016 12:56 PM, Tony Lindgren wrote:
>>>> * Suman Anna <s-anna at ti.com> [160127 10:17]:
>>>>> On 01/27/2016 11:31 AM, Tony Lindgren wrote:
>>>>>> Why do you need another reset here? Can't you just implement PM runtime
>>>>>> in the driver and do the usual pm_runtime_put_sync followed by
>>>>>> pm_runtime_disable?
>>>>>
>>>>> The omap_hwmod_enable/disable code does not deal with hardresets (PRCM
>>>>> reset lines) and so the pm_runtime_get_sync/put_sync only end up dealing
>>>>> with clocks, and we need to invoke the reset functions separately.
>>>>> Modules with softresets in SYSCONFIG are ok, as they are dealt with
>>>>> properly.
>>>>
>>>> Hmm _reset() in omap_hwmod.c has this to call _assert_hardreset:
>>>>
>>>> 	if (oh->class->reset) {
>>>> 		r = oh->class->reset(oh);
>>>> 	} else {
>>>> 		if (oh->rst_lines_cnt > 0) {
>>>> 			for (i = 0; i < oh->rst_lines_cnt; i++)
>>>> 				_assert_hardreset(oh, oh->rst_lines[i].name);
>>>> 			return 0;
>>>> 		} else {
>>>> 			r = _ocp_softreset(oh);
>>>> 			if (r == -ENOENT)
>>>> 				r = 0;
>>>> 		}
>>>> 	}
>>>
>>> Right, hwmod code does the initial reset.
>>>
>>>> Care to explain what exactly the problem with the hwmod code not doing
>>>> the reset on init?
>>>
>>> And we only need to deassert the reset in probe. Technically, we don't
>>> need to assert first and deassert in probe, and that was a design choice
>>> made by Kishon.
>>
>> OK so if hwmod code has already done the reset, then why would you need
>> to deassert reset in the device driver probe?
> 
> The hwmod code only asserts the reset lines and that is not enough to access
> the PCI registers. The reset lines must be de-asserted before accessing the
> PCIe registers.
>>
>>>> And why do you need to do another reset in dra7xx_pcie_remove()?
>>>
>>> Primarily to restore the reset state back to what it was after the
>>> driver remove gets called. We cannot call deassert twice without calling
>>> a assert in between. Kishon had originally added the assert and deassert
>>> only in probe, but nothing in remove, they ought to be deassert in probe
>>> and assert in remove to match initial hardware state, and to also make
>>> it work across multiple probe/remove.
> 
> right. I thought if some program like the bootloader requires the reset lines
> to be in initial hw state, then it might break on 'reboot'. So restored it back
> to the initial hw state.
>>
>> I don't understand this part either.. Usually you just power up and init
>> the registers to a sane state in a device driver probe and on exit just
>> power down the device.
>>
>>>>>> Basically I'm wondering how come we need these platform data callbacks
>>>>>> at all.
>>>>>
>>>>> The hardresets are controlled through the
>>>>> omap_device_assert(deassert)_hardreset functions, and since these are
>>>>> limited to mach-omap2, we are invoking them through platform data callbacks.
>>>>
>>>> Right.. But I'm wondering about the why you need to do this in the
>>>> driver at all part :)
>>>
>>> The initial reset at init time is okay, but hwmod _enable() bails out if
>>> the resets lines are asserted. This was a change made long time back, I
>>> believe to deal with the problems around the DSP enabling sequences. As
>>> such, pm_runtime_get_sync() and put_sync() do not deassert and assert
>>> the resets.
>>
>> OK if the hwmod code does not deassert reset lines properly on enable,
>> then that sounds like a bug that should be fixed instead of adding
>> device specific work arounds.
> 
> I think some devices require the reset lines to be asserted and some devices
> require it to be de-asserted and hwmod was designed when there was only the
> first type of devices. I'm not sure though.
>>
>> Sorry to keep dragging this on a bit longer, but I think we need to
>> hear Paul's comments on this one.
> 
> I agree.
> Paul, what do you think is the best way forward to perform reset?

Can you give your feedback as we are at the risk of PCIe driver being removed?

Thanks
Kishon

> 
> Thanks
> Kishon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From wenyou.yang at atmel.com  Thu Feb  4 20:26:06 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Fri, 5 Feb 2016 12:26:06 +0800
Subject: [PATCH v8 0/2] power: act8945a: add charger driver for the sub-device
 of ACT8945A MFD
Message-ID: <1454646368-18193-1-git-send-email-wenyou.yang@atmel.com>

The ACT8945A is a Multi Function Device with the following subdevices:
 - Regulator
 - Charger

This patch set is to add regulator driver for ACT8945A.
It is based on the patch set:
	http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/405258.html

Changes in v8:
 - remove the OF table.
 - due to the mfd cell .of_compatible removal, use the platform
   device's parent of_node to read the property and assign it
   to the psy_cfg.of_node.
 - fix the typo.
 - due the mfd cell .of_compatible removal, update the compatibe
   description and example.

Changes in v7:
 - use the helper dev_get_regmap(pdev->dev.parent, NULL) to get regmap.
 - remove *act8945a_dev member from struct act8945a_charger.
 - remove *psy member from struct act8945a_charger.
 - merge _parse_dt() and _charger_config() functions, remove relevent
   members from struct act8945a_charger.
 - remove unused platform_set_drvdata(pdev, charger) statement.

Changes in v6:
 - change the type value to unsigned int.

Changes in v5:
 - remove spare spaces after #define.
 - add OF match table.
 - collect Reviewed-by from Krzysztof.

Changes in v4:
 - use spaces after #define, not tabs.
 - use BIT(n) macros to substitute (0x01 << x).
 - change dt properties with more legible name.
 - change the properties with more legible name, clearer description.

Changes in v3:
 - update the file header with short version license and author line.
 - remove unused member of struct act8945a_charger, dev.
 - action due to removing the member of stuct act8945a_dev, dev.
 - remove the unnecessary print out.
 - remove the unnecessary act8945a_charger_remove().
 - fix align of the code-style.

Changes in v2:
 1./ Substitute of_property_read_bool() for of_get_property().
 2./ Substitute devm_power_supply_register() for power_supply_register().
 3./ Use module_platform_driver(), instead of subsys_initcall().
 4./ Substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").

Wenyou Yang (2):
  power: act8945a: add charger driver for ACT8945A
  power: add documentation for ACT8945A's charger DT bindings

 .../devicetree/bindings/power/act8945a-charger.txt |   35 ++
 drivers/power/Kconfig                              |    7 +
 drivers/power/Makefile                             |    1 +
 drivers/power/act8945a_charger.c                   |  355 ++++++++++++++++++++
 4 files changed, 398 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/act8945a-charger.txt
 create mode 100644 drivers/power/act8945a_charger.c

-- 
1.7.9.5



From wenyou.yang at atmel.com  Thu Feb  4 20:26:07 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Fri, 5 Feb 2016 12:26:07 +0800
Subject: [PATCH v8 1/2] power: act8945a: add charger driver for ACT8945A
In-Reply-To: <1454646368-18193-1-git-send-email-wenyou.yang@atmel.com>
References: <1454646368-18193-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1454646368-18193-2-git-send-email-wenyou.yang@atmel.com>

This patch adds new driver for Active-semi ACT8945A ActivePath
charger (part of ACT8945A MFD driver) providing power supply class
information to userspace.

The driver can be configured through DT (such as, total timer,
precondition timer and input over-voltage threshold).

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---

Changes in v8:
 - remove the OF table.
 - due to the mfd cell .of_compatible removal, use the platform
   device's parent of_node to read the property and assign it
   to the psy_cfg.of_node.
 - fix the typo.

Changes in v7:
 - use the helper dev_get_regmap(pdev->dev.parent, NULL) to get regmap.
 - remove *act8945a_dev member from struct act8945a_charger.
 - remove *psy member from struct act8945a_charger.
 - merge _parse_dt() and _charger_config() functions, remove relevent
   members from struct act8945a_charger.
 - remove unused platform_set_drvdata(pdev, charger) statement.

Changes in v6:
 - change the type value to unsigned int.

Changes in v5:
 - remove spare spaces after #define.
 - add OF match table.

Changes in v4:
 - use spaces after #define, not tabs.
 - use BIT(n) macros to substitute (0x01 << x).
 - change dt properties with more legible name.

Changes in v3:
 - update the file header with short version license and author line.
 - remove unused member of struct act8945a_charger, dev.
 - action due to removing the member of stuct act8945a_dev, dev.
 - remove the unnecessary print out.
 - remove the unnecessary act8945a_charger_remove().
 - fix align of the code-style.

Changes in v2:
 1./ Substitute of_property_read_bool() for of_get_property().
 2./ Substitute devm_power_supply_register() for power_supply_register().
 3./ Use module_platform_driver(), instead of subsys_initcall().
 4./ Substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").

 drivers/power/Kconfig            |    7 +
 drivers/power/Makefile           |    1 +
 drivers/power/act8945a_charger.c |  355 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 363 insertions(+)
 create mode 100644 drivers/power/act8945a_charger.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 1ddd13c..ae75211 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -75,6 +75,13 @@ config BATTERY_88PM860X
 	help
 	  Say Y here to enable battery monitor for Marvell 88PM860x chip.
 
+config BATTERY_ACT8945A
+	tristate "Active-semi ACT8945A charger driver"
+	depends on MFD_ACT8945A
+	help
+	  Say Y here to enable support for power supply provided by
+	  Active-semi ActivePath ACT8945A charger.
+
 config BATTERY_DS2760
 	tristate "DS2760 battery driver (HP iPAQ & others)"
 	depends on W1 && W1_SLAVE_DS2760
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 0e4eab5..e46b75d 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_WM8350_POWER)	+= wm8350_power.o
 obj-$(CONFIG_TEST_POWER)	+= test_power.o
 
 obj-$(CONFIG_BATTERY_88PM860X)	+= 88pm860x_battery.o
+obj-$(CONFIG_BATTERY_ACT8945A)	+= act8945a_charger.o
 obj-$(CONFIG_BATTERY_DS2760)	+= ds2760_battery.o
 obj-$(CONFIG_BATTERY_DS2780)	+= ds2780_battery.o
 obj-$(CONFIG_BATTERY_DS2781)	+= ds2781_battery.o
diff --git a/drivers/power/act8945a_charger.c b/drivers/power/act8945a_charger.c
new file mode 100644
index 0000000..0da0ea5
--- /dev/null
+++ b/drivers/power/act8945a_charger.c
@@ -0,0 +1,355 @@
+/*
+ * Power supply driver for the Active-semi ACT8945A PMIC
+ *
+ * Copyright (C) 2015 Atmel Corporation
+ *
+ * Author: Wenyou Yang <wenyou.yang at atmel.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.
+ *
+ */
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/power_supply.h>
+#include <linux/regmap.h>
+
+static const char *act8945a_charger_model = "ACT8945A";
+static const char *act8945a_charger_manufacturer = "Active-semi";
+
+/**
+ * ACT8945A Charger Register Map
+ */
+
+/* 0x70: Reserved */
+#define ACT8945A_APCH_CFG		0x71
+#define ACT8945A_APCH_STATUS		0x78
+#define ACT8945A_APCH_CTRL		0x79
+#define ACT8945A_APCH_STATE		0x7A
+
+/* ACT8945A_APCH_CFG */
+#define APCH_CFG_OVPSET			(0x3 << 0)
+#define APCH_CFG_OVPSET_6V6		(0x0 << 0)
+#define APCH_CFG_OVPSET_7V		(0x1 << 0)
+#define APCH_CFG_OVPSET_7V5		(0x2 << 0)
+#define APCH_CFG_OVPSET_8V		(0x3 << 0)
+#define APCH_CFG_PRETIMO		(0x3 << 2)
+#define APCH_CFG_PRETIMO_40_MIN		(0x0 << 2)
+#define APCH_CFG_PRETIMO_60_MIN		(0x1 << 2)
+#define APCH_CFG_PRETIMO_80_MIN		(0x2 << 2)
+#define APCH_CFG_PRETIMO_DISABLED	(0x3 << 2)
+#define APCH_CFG_TOTTIMO		(0x3 << 4)
+#define APCH_CFG_TOTTIMO_3_HOUR		(0x0 << 4)
+#define APCH_CFG_TOTTIMO_4_HOUR		(0x1 << 4)
+#define APCH_CFG_TOTTIMO_5_HOUR		(0x2 << 4)
+#define APCH_CFG_TOTTIMO_DISABLED	(0x3 << 4)
+#define APCH_CFG_SUSCHG			(0x1 << 7)
+
+#define APCH_STATUS_CHGDAT		BIT(0)
+#define APCH_STATUS_INDAT		BIT(1)
+#define APCH_STATUS_TEMPDAT		BIT(2)
+#define APCH_STATUS_TIMRDAT		BIT(3)
+#define APCH_STATUS_CHGSTAT		BIT(4)
+#define APCH_STATUS_INSTAT		BIT(5)
+#define APCH_STATUS_TEMPSTAT		BIT(6)
+#define APCH_STATUS_TIMRSTAT		BIT(7)
+
+#define APCH_CTRL_CHGEOCOUT		BIT(0)
+#define APCH_CTRL_INDIS			BIT(1)
+#define APCH_CTRL_TEMPOUT		BIT(2)
+#define APCH_CTRL_TIMRPRE		BIT(3)
+#define APCH_CTRL_CHGEOCIN		BIT(4)
+#define APCH_CTRL_INCON			BIT(5)
+#define APCH_CTRL_TEMPIN		BIT(6)
+#define APCH_CTRL_TIMRTOT		BIT(7)
+
+#define APCH_STATE_ACINSTAT		(0x1 << 1)
+#define APCH_STATE_CSTATE		(0x3 << 4)
+#define APCH_STATE_CSTATE_SHIFT		4
+#define APCH_STATE_CSTATE_DISABLED	0x00
+#define APCH_STATE_CSTATE_EOC		0x01
+#define APCH_STATE_CSTATE_FAST		0x02
+#define APCH_STATE_CSTATE_PRE		0x03
+
+struct act8945a_charger {
+	struct regmap *regmap;
+	bool battery_temperature;
+};
+
+static int act8945a_get_charger_state(struct regmap *regmap, int *val)
+{
+	int ret;
+	unsigned int status, state;
+
+	ret = regmap_read(regmap, ACT8945A_APCH_STATUS, &status);
+	if (ret < 0)
+		return ret;
+
+	ret = regmap_read(regmap, ACT8945A_APCH_STATE, &state);
+	if (ret < 0)
+		return ret;
+
+	state &= APCH_STATE_CSTATE;
+	state >>= APCH_STATE_CSTATE_SHIFT;
+
+	if (state == APCH_STATE_CSTATE_EOC) {
+		if (status & APCH_STATUS_CHGDAT)
+			*val = POWER_SUPPLY_STATUS_FULL;
+		else
+			*val = POWER_SUPPLY_STATUS_NOT_CHARGING;
+	} else if ((state == APCH_STATE_CSTATE_FAST) ||
+		   (state == APCH_STATE_CSTATE_PRE)) {
+		*val = POWER_SUPPLY_STATUS_CHARGING;
+	} else {
+		*val = POWER_SUPPLY_STATUS_NOT_CHARGING;
+	}
+
+	return 0;
+}
+
+static int act8945a_get_charge_type(struct regmap *regmap, int *val)
+{
+	int ret;
+	unsigned int state;
+
+	ret = regmap_read(regmap, ACT8945A_APCH_STATE, &state);
+	if (ret < 0)
+		return ret;
+
+	state &= APCH_STATE_CSTATE;
+	state >>= APCH_STATE_CSTATE_SHIFT;
+
+	switch (state) {
+	case APCH_STATE_CSTATE_PRE:
+		*val = POWER_SUPPLY_CHARGE_TYPE_TRICKLE;
+		break;
+	case APCH_STATE_CSTATE_FAST:
+		*val = POWER_SUPPLY_CHARGE_TYPE_FAST;
+		break;
+	case APCH_STATE_CSTATE_EOC:
+	case APCH_STATE_CSTATE_DISABLED:
+	default:
+		*val = POWER_SUPPLY_CHARGE_TYPE_NONE;
+	}
+
+	return 0;
+}
+
+static int act8945a_get_battery_health(struct act8945a_charger *charger,
+				       struct regmap *regmap, int *val)
+{
+	int ret;
+	unsigned int status;
+
+	ret = regmap_read(regmap, ACT8945A_APCH_STATUS, &status);
+	if (ret < 0)
+		return ret;
+
+	if (charger->battery_temperature && !(status & APCH_STATUS_TEMPDAT))
+		*val = POWER_SUPPLY_HEALTH_OVERHEAT;
+	else if (!(status & APCH_STATUS_INDAT))
+		*val = POWER_SUPPLY_HEALTH_OVERVOLTAGE;
+	else if (status & APCH_STATUS_TIMRDAT)
+		*val = POWER_SUPPLY_HEALTH_SAFETY_TIMER_EXPIRE;
+	else
+		*val = POWER_SUPPLY_HEALTH_GOOD;
+
+	return 0;
+}
+
+static enum power_supply_property act8945a_charger_props[] = {
+	POWER_SUPPLY_PROP_STATUS,
+	POWER_SUPPLY_PROP_CHARGE_TYPE,
+	POWER_SUPPLY_PROP_TECHNOLOGY,
+	POWER_SUPPLY_PROP_HEALTH,
+	POWER_SUPPLY_PROP_MODEL_NAME,
+	POWER_SUPPLY_PROP_MANUFACTURER
+};
+
+static int act8945a_charger_get_property(struct power_supply *psy,
+					 enum power_supply_property prop,
+					 union power_supply_propval *val)
+{
+	struct act8945a_charger *charger = power_supply_get_drvdata(psy);
+	struct regmap *regmap = charger->regmap;
+	int ret = 0;
+
+	switch (prop) {
+	case POWER_SUPPLY_PROP_STATUS:
+		ret = act8945a_get_charger_state(regmap, &val->intval);
+		break;
+	case POWER_SUPPLY_PROP_CHARGE_TYPE:
+		ret = act8945a_get_charge_type(regmap, &val->intval);
+		break;
+	case POWER_SUPPLY_PROP_TECHNOLOGY:
+		val->intval = POWER_SUPPLY_TECHNOLOGY_LION;
+		break;
+	case POWER_SUPPLY_PROP_HEALTH:
+		ret = act8945a_get_battery_health(charger,
+						  regmap, &val->intval);
+		break;
+	case POWER_SUPPLY_PROP_MODEL_NAME:
+		val->strval = act8945a_charger_model;
+		break;
+	case POWER_SUPPLY_PROP_MANUFACTURER:
+		val->strval = act8945a_charger_manufacturer;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return ret;
+}
+
+static const struct power_supply_desc act8945a_charger_desc = {
+	.name		= "act8945a-charger",
+	.type		= POWER_SUPPLY_TYPE_BATTERY,
+	.get_property	= act8945a_charger_get_property,
+	.properties	= act8945a_charger_props,
+	.num_properties	= ARRAY_SIZE(act8945a_charger_props),
+};
+
+#define DEFAULT_TOTAL_TIME_OUT		3
+#define DEFAULT_PRE_TIME_OUT		40
+#define DEFAULT_INPUT_OVP_THRESHOLD	6600
+
+static int act8945a_charger_config(struct device *dev,
+				   struct act8945a_charger *charger)
+{
+	struct device_node *np = dev->of_node;
+	enum of_gpio_flags flags;
+	struct regmap *regmap = charger->regmap;
+
+	u32 total_time_out;
+	u32 pre_time_out;
+	u32 input_voltage_threshold;
+	int chglev_pin;
+
+	unsigned int value = 0;
+
+	if (!np) {
+		dev_err(dev, "no charger of node\n");
+		return -EINVAL;
+	}
+
+	charger->battery_temperature = of_property_read_bool(np,
+				"active-semi,check-battery-temperature");
+
+	chglev_pin = of_get_named_gpio_flags(np,
+				"active-semi,chglev-gpios", 0, &flags);
+
+	if (gpio_is_valid(chglev_pin)) {
+		gpio_set_value(chglev_pin,
+			       ((flags == OF_GPIO_ACTIVE_LOW) ? 0 : 1));
+	}
+
+	if (of_property_read_u32(np,
+				 "active-semi,input-voltage-threshold-microvolt",
+				 &input_voltage_threshold))
+		input_voltage_threshold = DEFAULT_INPUT_OVP_THRESHOLD;
+
+	if (of_property_read_u32(np,
+				 "active-semi,precondition-timeout",
+				 &pre_time_out))
+		pre_time_out = DEFAULT_PRE_TIME_OUT;
+
+	if (of_property_read_u32(np, "active-semi,total-timeout",
+				 &total_time_out))
+		total_time_out = DEFAULT_TOTAL_TIME_OUT;
+
+	switch (input_voltage_threshold) {
+	case 8000:
+		value |= APCH_CFG_OVPSET_8V;
+		break;
+	case 7500:
+		value |= APCH_CFG_OVPSET_7V5;
+		break;
+	case 7000:
+		value |= APCH_CFG_OVPSET_7V;
+		break;
+	case 6600:
+	default:
+		value |= APCH_CFG_OVPSET_6V6;
+		break;
+	}
+
+	switch (pre_time_out) {
+	case 60:
+		value |= APCH_CFG_PRETIMO_60_MIN;
+		break;
+	case 80:
+		value |= APCH_CFG_PRETIMO_80_MIN;
+		break;
+	case 0:
+		value |= APCH_CFG_PRETIMO_DISABLED;
+		break;
+	case 40:
+	default:
+		value |= APCH_CFG_PRETIMO_40_MIN;
+		break;
+	}
+
+	switch (total_time_out) {
+	case 4:
+		value |= APCH_CFG_TOTTIMO_4_HOUR;
+		break;
+	case 5:
+		value |= APCH_CFG_TOTTIMO_5_HOUR;
+		break;
+	case 0:
+		value |= APCH_CFG_TOTTIMO_DISABLED;
+		break;
+	case 3:
+	default:
+		value |= APCH_CFG_TOTTIMO_3_HOUR;
+		break;
+	}
+
+	return regmap_write(regmap, ACT8945A_APCH_CFG, value);
+}
+
+static int act8945a_charger_probe(struct platform_device *pdev)
+{
+	struct act8945a_charger *charger;
+	struct power_supply *psy;
+	struct power_supply_config psy_cfg = {};
+	int ret;
+
+	charger = devm_kzalloc(&pdev->dev, sizeof(*charger), GFP_KERNEL);
+	if (!charger)
+		return -ENOMEM;
+
+	charger->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+
+	ret = act8945a_charger_config(pdev->dev.parent, charger);
+	if (ret)
+		return ret;
+
+	psy_cfg.of_node	= pdev->dev.parent->of_node;
+	psy_cfg.drv_data = charger;
+
+	psy = devm_power_supply_register(&pdev->dev,
+					 &act8945a_charger_desc,
+					 &psy_cfg);
+	if (IS_ERR(psy)) {
+		dev_err(&pdev->dev, "failed to register power supply\n");
+		return PTR_ERR(psy);
+	}
+
+	return 0;
+}
+
+static struct platform_driver act8945a_charger_driver = {
+	.driver	= {
+		.name = "act8945a-charger",
+	},
+	.probe	= act8945a_charger_probe,
+};
+module_platform_driver(act8945a_charger_driver);
+
+MODULE_DESCRIPTION("Active-semi ACT8945A ActivePath charger driver");
+MODULE_AUTHOR("Wenyou Yang <wenyou.yang at atmel.com>");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5



From wenyou.yang at atmel.com  Thu Feb  4 20:26:08 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Fri, 5 Feb 2016 12:26:08 +0800
Subject: [PATCH v8 2/2] power: add documentation for ACT8945A's charger DT
 bindings
In-Reply-To: <1454646368-18193-1-git-send-email-wenyou.yang@atmel.com>
References: <1454646368-18193-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1454646368-18193-3-git-send-email-wenyou.yang@atmel.com>

This patch adds documentation for the DT bindings of the charger
subdevice of ACT8945A MFD.

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---

Changes in v8:
 - due the mfd cell .of_compatible removal, update the compatibe
   description and example.

Changes in v7: None
Changes in v6: None
Changes in v5:
 - collect Reviewed-by from Krzysztof.

Changes in v4:
 - change the properties with more legible name, clearer description.

Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/power/act8945a-charger.txt |   35 ++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/act8945a-charger.txt

diff --git a/Documentation/devicetree/bindings/power/act8945a-charger.txt b/Documentation/devicetree/bindings/power/act8945a-charger.txt
new file mode 100644
index 0000000..bea254c
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/act8945a-charger.txt
@@ -0,0 +1,35 @@
+Device-Tree bindings for charger of Active-semi ACT8945A Multi-Function Device
+
+Required properties:
+ - compatible: "active-semi,act8945a", please refer to ../mfd/act8945a.txt.
+ - active-semi,chglev-gpios: charge current level phandle with args
+   as described in ../gpio/gpio.txt.
+
+Optional properties:
+ - active-semi,check-battery-temperature: boolean to check the battery
+   temperature or not.
+ - active-semi,input-voltage-threshold-microvolt: unit: mV;
+   Specifies the charger's input over-voltage threshold value;
+   The value can be: 6600, 7000, 7500, 8000; default: 6600
+ - active-semi,precondition-timeout: unit: minutes;
+   Specifies the charger's PRECONDITION safety timer setting value;
+   The value can be: 40, 60, 80, 0; If 0, it means to disable this timer;
+   default: 40.
+ - active-semi,total-timeout: unit: hours;
+   Specifies the charger's total safety timer setting value;
+   The value can be: 3, 4, 5, 0; If 0, it means to disable this timer;
+   default: 3.
+
+Example:
+	pmic at 5b {
+		compatible = "active-semi,act8945a";
+		reg = <0x5b>;
+		status = "okay";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_charger_chglev>;
+		active-semi,chglev-gpios = <&pioA 12 GPIO_ACTIVE_HIGH>;
+		active-semi,input-voltage-threshold-microvolt = <6600>;
+		active-semi,precondition-timeout = <40>;
+		active-semi,total-timeout = <3>;
+	};
-- 
1.7.9.5



From okaya at codeaurora.org  Thu Feb  4 20:34:32 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Thu,  4 Feb 2016 23:34:32 -0500
Subject: [PATCH V14 1/9] dma: qcom_bam_dma: move to qcom directory
In-Reply-To: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
References: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
Message-ID: <1454646882-24369-2-git-send-email-okaya@codeaurora.org>

Creating a QCOM directory for all QCOM DMA source files.

Signed-off-by: Sinan Kaya <okaya at codeaurora.org>
Reviewed-by: Andy Gross <agross at codeaurora.org>
---
 drivers/dma/Kconfig                            | 11 ++---------
 drivers/dma/Makefile                           |  2 +-
 drivers/dma/qcom/Kconfig                       |  8 ++++++++
 drivers/dma/qcom/Makefile                      |  1 +
 drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} |  4 ++--
 5 files changed, 14 insertions(+), 12 deletions(-)
 create mode 100644 drivers/dma/qcom/Kconfig
 create mode 100644 drivers/dma/qcom/Makefile
 rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 79b1390..245b061 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -408,15 +408,6 @@ config PXA_DMA
 	  16 to 32 channels for peripheral to memory or memory to memory
 	  transfers.
 
-config QCOM_BAM_DMA
-	tristate "QCOM BAM DMA support"
-	depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
-	select DMA_ENGINE
-	select DMA_VIRTUAL_CHANNELS
-	---help---
-	  Enable support for the QCOM BAM DMA controller.  This controller
-	  provides DMA capabilities for a variety of on-chip devices.
-
 config SIRF_DMA
 	tristate "CSR SiRFprimaII/SiRFmarco DMA support"
 	depends on ARCH_SIRF
@@ -539,6 +530,8 @@ config ZX_DMA
 # driver files
 source "drivers/dma/bestcomm/Kconfig"
 
+source "drivers/dma/qcom/Kconfig"
+
 source "drivers/dma/dw/Kconfig"
 
 source "drivers/dma/hsu/Kconfig"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 2dd0a067..6084127 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_PCH_DMA) += pch_dma.o
 obj-$(CONFIG_PL330_DMA) += pl330.o
 obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
 obj-$(CONFIG_PXA_DMA) += pxa_dma.o
-obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
 obj-$(CONFIG_RENESAS_DMA) += sh/
 obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
 obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
@@ -67,4 +66,5 @@ obj-$(CONFIG_TI_EDMA) += edma.o
 obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
 
+obj-y += qcom/
 obj-y += xilinx/
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
new file mode 100644
index 0000000..f17c272
--- /dev/null
+++ b/drivers/dma/qcom/Kconfig
@@ -0,0 +1,8 @@
+config QCOM_BAM_DMA
+	tristate "QCOM BAM DMA support"
+	depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+	select DMA_ENGINE
+	select DMA_VIRTUAL_CHANNELS
+	---help---
+	  Enable support for the QCOM BAM DMA controller.  This controller
+	  provides DMA capabilities for a variety of on-chip devices.
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
new file mode 100644
index 0000000..f612ae3
--- /dev/null
+++ b/drivers/dma/qcom/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom/bam_dma.c
similarity index 99%
rename from drivers/dma/qcom_bam_dma.c
rename to drivers/dma/qcom/bam_dma.c
index 5a250cd..b6f053d 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -49,8 +49,8 @@
 #include <linux/clk.h>
 #include <linux/dmaengine.h>
 
-#include "dmaengine.h"
-#include "virt-dma.h"
+#include "../dmaengine.h"
+#include "../virt-dma.h"
 
 struct bam_desc_hw {
 	u32 addr;		/* Buffer physical address */
-- 
1.8.2.1



From okaya at codeaurora.org  Thu Feb  4 20:34:31 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Thu,  4 Feb 2016 23:34:31 -0500
Subject: [PATCH V14 0/9] dma: add Qualcomm Technologies HIDMA driver
Message-ID: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>

The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design.

1. HIDMA Management driver
2. HIDMA Channel driver

Each HIDMA HW consists of multiple channels. These channels
share some set of common parameters. These parameters are
initialized by the management driver during power up.
Same management driver is used for monitoring the execution
of the channels. Management driver can change the performance
behavior dynamically such as bandwidth allocation and
prioritization in the future.

The management driver is executed in host context and
is the main management entity for all channels provided by
the device.

------------------------
What's new
------------------------
- Add back default number of descriptors.
- Fix compilation error in VFIO ACPI support.
- Merge the event-channel patch back to DTS and channel driver.

------------------------
Git repos
------------------------
QEMU Support
https://www.codeaurora.org/cgit/quic/qemu/qemu/log/?h=v2.5.0-sriov

------------------------
History of Changes
------------------------
dma: hidma: Add Device Tree Binding
Changes from V13: (https://lkml.org/lkml/2016/1/29/672)
* merged event-channel change.

dma: add Qualcomm Technologies HIDMA channel driver
Changes from V13: (https://lkml.org/lkml/2016/1/29/685)
* add back default descriptor count
* merged event-channel change.

dma: qcom_hidma: add support for object hierarchy
Changes from V13: (https://lkml.org/lkml/2016/1/29/680)
* initialize platform info data structure.
* configure DMA by calling of_dma_configure. DMA mask was not set when
* IOMMU driver is not present for the children devices.

vfio, platform: add support for ACPI while detecting the reset driver
Changes from V13: (https://lkml.org/lkml/2016/1/29/679)
* add forgotten pointer during merge
* clarify the driver loading rules in commit message

------------------------
FAQ
------------------------
- This doesn't seem to tie into KVM or VFIO, and as far as I can tell
  there's no mechanism for associating channels with a particular virtual
  address space (i.e. no configuration of an external or internal IOMMU),
  nor pinning of guest pages to allow for DMA to occur safely.

   I'm using VFIO platform driver for this purpose. VFIO platform driver is
   capable of assigning any platform device to a guest machine with this
   driver.

- Are there additional patches, or do you have some userspace that works
  with this in some limited configuration?

   No, these are the only patches. We have one patch for the QEMU but from
   kernel perspective this is it. I just rely on the platform VFIO driver
   to do the work.

- How do host and guest communicate, what is the infrastructure, how is
  HIDMA meant to be used?

   They don't. Guest machine uses HIDMA channel driver to offload DMA
   operations in isolation. The guest machine owns the HW registers for the
   channel. It doesn't need to trap to host for register read/writes etc.

   All guest machine pages used are assumed to be pinned similar to VFIO
   PCI. The reason is performance. The IOMMU takes care of the address
   translation for me.

- How do host and guest communicate?
   They don't.

- How is the integration performed in the hypervisor?

   Hypervisor has a bunch of channel resources. For each guest machine, the
   channel gets unbound from the hypervisor. Channels get bind to each VFIO
   platform device and then control is given to the guest machine.

   Once the guest machine is shutdown, VFIO driver still owns the channel
   device. It can assign the device to another guest machine.

- Does the HYP side requires any context switch (and how is that done)?

   No communication is needed.

- What makes it safe?
   No communication is needed.

- Does the HYP side requires any context switch (and how is that done)?

   I don't believe this requires any context-switch -- it's the same as
   assigning any other platform device other than additional proeprties
   being controlled in the managament interface.

- I'm concerned with how this is safe, and with the userspace interface.
  e.g. if the user wants to up the QoS for a VM, how to they find the
  right channel in sysfs  to alter?

   The HW supports changing the QoS values on the flight. In order to
   locate the object, I'm exporting a chid attribute in sysfs.

   Each management object has one priority and weight file per channel that
   is indexed by the channel id read from the DMA object.
   /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority
   /sys/devices/platform/QCOM8060:*/chanops/chan*/priority

- So what is that hypervisor code used for? Is that your reset driver?

   The HIDMA "management" driver which runs at the hypervisor owns the
   management HW. Management driver serves two purposes.

   1. Common bus parameter configuration (could be called reset driver).
   2. Fine tuning the HW resources on the flight.

Sinan Kaya (9):
  dma: qcom_bam_dma: move to qcom directory
  dma: hidma: Add Device Tree binding
  dma: add Qualcomm Technologies HIDMA management driver
  dma: add Qualcomm Technologies HIDMA channel driver
  dma: qcom_hidma: implement lower level hardware interface
  dma: qcom_hidma: add debugfs hooks
  dma: qcom_hidma: add support for object hierarchy
  vfio, platform: add support for ACPI while detecting the reset driver
  vfio, platform: add QTI HIDMA reset driver

 Documentation/ABI/testing/sysfs-platform-hidma     |   9 +
 .../ABI/testing/sysfs-platform-hidma-mgmt          |  97 +++
 .../devicetree/bindings/dma/qcom_hidma_mgmt.txt    |  89 ++
 drivers/dma/Kconfig                                |  11 +-
 drivers/dma/Makefile                               |   2 +-
 drivers/dma/qcom/Kconfig                           |  29 +
 drivers/dma/qcom/Makefile                          |   5 +
 drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c}     |   4 +-
 drivers/dma/qcom/hidma.c                           | 746 +++++++++++++++++
 drivers/dma/qcom/hidma.h                           | 162 ++++
 drivers/dma/qcom/hidma_dbg.c                       | 219 +++++
 drivers/dma/qcom/hidma_ll.c                        | 927 +++++++++++++++++++++
 drivers/dma/qcom/hidma_mgmt.c                      | 407 +++++++++
 drivers/dma/qcom/hidma_mgmt.h                      |  39 +
 drivers/dma/qcom/hidma_mgmt_sys.c                  | 295 +++++++
 drivers/vfio/platform/reset/Kconfig                |   9 +
 drivers/vfio/platform/reset/Makefile               |   2 +
 .../vfio/platform/reset/vfio_platform_amdxgbe.c    |   3 +-
 .../platform/reset/vfio_platform_calxedaxgmac.c    |   3 +-
 .../vfio/platform/reset/vfio_platform_qcomhidma.c  |  99 +++
 drivers/vfio/platform/vfio_platform_common.c       |  80 +-
 drivers/vfio/platform/vfio_platform_private.h      |  41 +-
 22 files changed, 3235 insertions(+), 43 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma
 create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt
 create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
 create mode 100644 drivers/dma/qcom/Kconfig
 create mode 100644 drivers/dma/qcom/Makefile
 rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
 create mode 100644 drivers/dma/qcom/hidma.c
 create mode 100644 drivers/dma/qcom/hidma.h
 create mode 100644 drivers/dma/qcom/hidma_dbg.c
 create mode 100644 drivers/dma/qcom/hidma_ll.c
 create mode 100644 drivers/dma/qcom/hidma_mgmt.c
 create mode 100644 drivers/dma/qcom/hidma_mgmt.h
 create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
 create mode 100644 drivers/vfio/platform/reset/vfio_platform_qcomhidma.c

-- 
1.8.2.1



From okaya at codeaurora.org  Thu Feb  4 20:34:33 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Thu,  4 Feb 2016 23:34:33 -0500
Subject: [PATCH V14 2/9] dma: hidma: Add Device Tree binding
In-Reply-To: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
References: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
Message-ID: <1454646882-24369-3-git-send-email-okaya@codeaurora.org>

Add documentation for the Qualcomm Technologies HIDMA binding.

Signed-off-by: Sinan Kaya <okaya at codeaurora.org>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/dma/qcom_hidma_mgmt.txt    | 89 ++++++++++++++++++++++
 1 file changed, 89 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt

diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
new file mode 100644
index 0000000..fd5618b
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -0,0 +1,89 @@
+Qualcomm Technologies HIDMA Management interface
+
+Qualcomm Technologies HIDMA is a high speed DMA device. It only supports
+memcpy and memset capabilities. It has been designed for virtualized
+environments.
+
+Each HIDMA HW instance consists of multiple DMA channels. These channels
+share the same bandwidth. The bandwidth utilization can be parititioned
+among channels based on the priority and weight assignments.
+
+There are only two priority levels and 15 weigh assignments possible.
+
+Other parameters here determine how much of the system bus this HIDMA
+instance can use like maximum read/write request and and number of bytes to
+read/write in a single burst.
+
+Main node required properties:
+- compatible: "qcom,hidma-mgmt-1.0";
+- reg: Address range for DMA device
+- dma-channels: Number of channels supported by this DMA controller.
+- max-write-burst-bytes: Maximum write burst in bytes that HIDMA can
+  occupy the bus for in a single transaction. A memcpy requested is
+  fragmented to multiples of this amount. This parameter is used while
+  writing into destination memory. Setting this value incorrectly can
+  starve other peripherals in the system.
+- max-read-burst-bytes: Maximum read burst in bytes that HIDMA can
+  occupy the bus for in a single transaction. A memcpy request is
+  fragmented to multiples of this amount. This parameter is used while
+  reading the source memory. Setting this value incorrectly can starve
+  other peripherals in the system.
+- max-write-transactions: This value is how many times a write burst is
+  applied back to back while writing to the destination before yielding
+  the bus.
+- max-read-transactions: This value is how many times a read burst is
+  applied back to back while reading the source before yielding the bus.
+- channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC.
+  Once a reset is applied to the HW, HW starts a timer for reset operation
+  to confirm. If reset is not completed within this time, HW reports reset
+  failure.
+
+Sub-nodes:
+
+HIDMA has one or more DMA channels that are used to move data from one
+memory location to another.
+
+When the OS is not in control of the management interface (i.e. it's a guest),
+the channel nodes appear on their own, not under a management node.
+
+Required properties:
+- compatible: must contain "qcom,hidma-1.0"
+- reg: Addresses for the transfer and event channel
+- interrupts: Should contain the event interrupt
+- desc-count: Number of asynchronous requests this channel can handle
+- iommus: required a iommu node
+
+Example:
+
+Hypervisor OS configuration:
+
+	hidma-mgmt at f9984000 = {
+		compatible = "qcom,hidma-mgmt-1.0";
+		reg = <0xf9984000 0x15000>;
+		dma-channels = <6>;
+		max-write-burst-bytes = <1024>;
+		max-read-burst-bytes = <1024>;
+		max-write-transactions = <31>;
+		max-read-transactions = <31>;
+		channel-reset-timeout-cycles = <0x500>;
+
+		hidma_24: dma-controller at 0x5c050000 {
+			compatible = "qcom,hidma-1.0";
+			reg = <0 0x5c050000 0x0 0x1000>,
+			      <0 0x5c0b0000 0x0 0x1000>;
+			interrupts = <0 389 0>;
+			desc-count = <10>;
+			iommus = <&system_mmu>;
+		};
+	};
+
+Guest OS configuration:
+
+	hidma_24: dma-controller at 0x5c050000 {
+		compatible = "qcom,hidma-1.0";
+		reg = <0 0x5c050000 0x0 0x1000>,
+		      <0 0x5c0b0000 0x0 0x1000>;
+		interrupts = <0 389 0>;
+		desc-count = <10>;
+		iommus = <&system_mmu>;
+	};
-- 
1.8.2.1



From robh at kernel.org  Thu Feb  4 20:35:07 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 4 Feb 2016 22:35:07 -0600
Subject: [PATCH v3 1/4] dt-bindings: power: reset: add document for
 reboot-mode driver
In-Reply-To: <CALAqxLVyznpLd2MLgGr28TDECpLZ=RpmhxH-SHqntXfBsctcmQ@mail.gmail.com>
References: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
 <1454407151-4751-1-git-send-email-andy.yan@rock-chips.com>
 <20160204230814.GA4847@rob-hp-laptop>
 <CALAqxLVyznpLd2MLgGr28TDECpLZ=RpmhxH-SHqntXfBsctcmQ@mail.gmail.com>
Message-ID: <20160205043507.GB4847@rob-hp-laptop>

On Thu, Feb 04, 2016 at 03:46:15PM -0800, John Stultz wrote:
> On Thu, Feb 4, 2016 at 3:08 PM, Rob Herring <robh at kernel.org> wrote:
> > On Tue, Feb 02, 2016 at 05:59:11PM +0800, Andy Yan wrote:
> >> add device tree bindings document for reboot-mode driver
> >>
> >> Signed-off-by: Andy Yan <andy.yan at rock-chips.com>
> >>
> >> ---
> >>
> >> Changes in v3:
> >> - descirbe all reboot mode as properity instead of subnode
> >>
> >> Changes in v2: None
> >> Changes in v1: None
> >>
> >>  .../bindings/power/reset/reboot-mode.txt           | 26 ++++++++++++++++
> >>  .../bindings/power/reset/syscon-reboot-mode.txt    | 36 ++++++++++++++++++++++
> >>  2 files changed, 62 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/power/reset/reboot-mode.txt
> >>  create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/power/reset/reboot-mode.txt b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
> >> new file mode 100644
> >> index 0000000..517080f
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
> >> @@ -0,0 +1,26 @@
> >> +Generic reboot mode core map driver
> >> +
> >> +This driver get reboot mode arguments and call the write
> >> +interface to stores the magic value in special register
> >> +or ram . Then the bootloader can read it and take different
> >> +action according the argument stored.
> >> +
> >> +All mode properties are vendor specific, it is a indication to tell
> >
> > The values should be vendor specific. The property names should not. We
> > can allow vendor specific ones, but we need to have a common set.
> >
> >> +the bootloder what to do when the system reboot, and should be named
> >> +as mode-xxx = <magic> (xxx is mode name).
> >> +
> >> +- mode-normal: Normal reboot mode, system reboot with command "reboot".
> >> +- mode-recovery: Android Recovery mode, it is a mode to format the device or update a new image.
> >> +- mode-fastboot: Android fastboot mode, it's a mode to  re-flash partitions on the device.
> >> +- mode-loader: A bootloader mode, it's a mode used to download image on Rockchip platform,
> >> +            usually used in development.
> >> +- mode-maskrom: It's a mode to download bootloader on Rockchip platform.
> >> +
> >> +Example:
> >> +     reboot-mode {
> >> +             mode-normal = <BOOT_NORMAL>;
> >> +             mode-recovery = <BOOT_RECOVERY>;
> >> +             mode-fastboot = <BOOT_FASTBOOT>;
> >
> > I tend to agree with John on calling this mode-bootloader.
> >
> > OTOH, fastboot is more specific about what the mode is. The name in DT
> > and the userspace name don't necessarily have to be the same.
> 
> Wait. This is a bit confusing. The utility of adding a property name
> and using that name be the reboot command parsed for made sense
> (compared to earlier versions which had command strings) as it made
> the dts more terse.   But it sounds here like you're suggesting we
> should have some logic in the driver that translates "reboot fastboot"
> to mode-bootloader or vice versa.

I said early on the DT names and kernel-userspace names should not 
necessarily be linked. They can be, but we shouldn't require that.

My concern with mode-bootloader is what if you can boot into multiple 
bootloader modes. Say USB mass storage is one option. "bootloader" is 
not real specific.

> >> +             mode-loader = <BOOT_LOADER>;
> >
> > This one needs a better name. Maybe it should be 'rockchip,mode-loader'
> > as it is vendor specific. Either way, loader is vague. Perhaps
> > rockchip,mode-bl-download?
> 
> Hrm. So how what reboot command do you expect to trigger that?

Whatever your OS has defined to map to that.

We could just decide the kernel will strip <vendor> and 'mode-' and 
match commands against what remains.

> Though I do like the vendor specific prefix here, as it clarifies how
> universal the command is (and its easy add standard commands if they
> become more established and remap things in the future).
> 
> >
> >> +             mode-maskrom = <BOOT_MASKROM>;
> >
> > I think this should be "mode-rom-download".
> 
> I think one of the difficult things here is that there's no real
> standards for all bios/bootloader modes. So they are somewhat
> firmware/bootloader/device specific, and thus we need something that
> is flexible enough to allow lots of different modes to be easily
> specified.  That said, this does expose a userspace interface (though
> one could argue kernel ABI doesn't cross reboots :) so we should try
> to have some consistency so the same userspace can work on various
> devices.

There is: UEFI. Boot mode efivars are standard. But then they are pretty 
much PC oriented though. It is more which device to boot off of, but 
there is network boot or boot to bios setup.

> I do think the "bootloader" and "recovery" arguments are somewhat
> defacto standards, well established on most android devices.

Yes, otherwise I'd be completely against "mode-bootloader" as the 
property.

> I think here the concern is rockchip probably has some userspace that
> is already using "reboot maskrom" or "reboot loader" for their own
> uses. And its a bit of a pain to ask that userspace to be reworked to

Perhaps those are only for development and change would not be so 
painful.

> use "reboot rom-download" or "reboot rockchip,rom-download" depending
> on how we try to deal with these.  (Granted, non-upstream interfaces
> aren't official, so that is their risk somewhat, but we avoid being
> smug about that :)

Or vendor specific modes require vendor specific translation in the 
kernel. 

To some extent we need to design what is right and worry about future 
devices rather than cater to past devices. There's always some 
compromise. What would you design ignoring the existing conditions. 
Start there and then figure out how to make it work with current 
designs.

> Another part of the issue is there isn't really a way to probe for
> reboot cmd capability here. As much as I'd rather not complicate
> things, one couldn't easily extend existing userspace to work with
> current kernels as well as future kernels, since the reboot with an
> invalid command won't fail. The machine still resets. So you can't try
> one and fallback to the other.

Well, that's nice. Maybe we should change that? Or we're stuck with 
that ABI?

> Maybe there needs to be a sysfs entry with the list of the supported commands?

You can just read the DT. Although, the problem then is what happens 
when we move to the next firmware interface. We see that some with 
devices having userspace dependencies on ATAGS.

Rob


From okaya at codeaurora.org  Thu Feb  4 20:34:34 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Thu,  4 Feb 2016 23:34:34 -0500
Subject: [PATCH V14 3/9] dma: add Qualcomm Technologies HIDMA management driver
In-Reply-To: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
References: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
Message-ID: <1454646882-24369-4-git-send-email-okaya@codeaurora.org>

The Qualcomm Technologies HIDMA device has been designed to support
virtualization technology. The driver has been divided into two to follow
the hardware design.

1. HIDMA Management driver
2. HIDMA Channel driver

Each HIDMA HW consists of multiple channels. These channels share some set
of common parameters. These parameters are initialized by the management
driver during power up. Same management driver is used for monitoring the
execution of the channels. Management driver can change the performance
behavior dynamically such as bandwidth allocation and prioritization.

The management driver is executed in host context and is the main
management entity for all channels provided by the device.

Signed-off-by: Sinan Kaya <okaya at codeaurora.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko at gmail.com>
---
 .../ABI/testing/sysfs-platform-hidma-mgmt          |  97 +++++++
 drivers/dma/qcom/Kconfig                           |  11 +
 drivers/dma/qcom/Makefile                          |   2 +
 drivers/dma/qcom/hidma_mgmt.c                      | 302 +++++++++++++++++++++
 drivers/dma/qcom/hidma_mgmt.h                      |  39 +++
 drivers/dma/qcom/hidma_mgmt_sys.c                  | 295 ++++++++++++++++++++
 6 files changed, 746 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt
 create mode 100644 drivers/dma/qcom/hidma_mgmt.c
 create mode 100644 drivers/dma/qcom/hidma_mgmt.h
 create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c

diff --git a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
new file mode 100644
index 0000000..c2fb5d0
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
@@ -0,0 +1,97 @@
+What:		/sys/devices/platform/hidma-mgmt*/chanops/chan*/priority
+		/sys/devices/platform/QCOM8060:*/chanops/chan*/priority
+Date:		Nov 2015
+KernelVersion:	4.4
+Contact:	"Sinan Kaya <okaya at cudeaurora.org>"
+Description:
+		Contains either 0 or 1 and indicates if the DMA channel is a
+		low priority (0) or high priority (1) channel.
+
+What:		/sys/devices/platform/hidma-mgmt*/chanops/chan*/weight
+		/sys/devices/platform/QCOM8060:*/chanops/chan*/weight
+Date:		Nov 2015
+KernelVersion:	4.4
+Contact:	"Sinan Kaya <okaya at cudeaurora.org>"
+Description:
+		Contains 0..15 and indicates the weight of the channel among
+		equal priority channels during round robin scheduling.
+
+What:		/sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles
+		/sys/devices/platform/QCOM8060:*/chreset_timeout_cycles
+Date:		Nov 2015
+KernelVersion:	4.4
+Contact:	"Sinan Kaya <okaya at cudeaurora.org>"
+Description:
+		Contains the platform specific cycle value to wait after a
+		reset command is issued. If the value is chosen too short,
+		then the HW will issue a reset failure interrupt. The value
+		is platform specific and should not be changed without
+		consultance.
+
+What:		/sys/devices/platform/hidma-mgmt*/dma_channels
+		/sys/devices/platform/QCOM8060:*/dma_channels
+Date:		Nov 2015
+KernelVersion:	4.4
+Contact:	"Sinan Kaya <okaya at cudeaurora.org>"
+Description:
+		Contains the number of dma channels supported by one instance
+		of HIDMA hardware. The value may change from chip to chip.
+
+What:		/sys/devices/platform/hidma-mgmt*/hw_version_major
+		/sys/devices/platform/QCOM8060:*/hw_version_major
+Date:		Nov 2015
+KernelVersion:	4.4
+Contact:	"Sinan Kaya <okaya at cudeaurora.org>"
+Description:
+		Version number major for the hardware.
+
+What:		/sys/devices/platform/hidma-mgmt*/hw_version_minor
+		/sys/devices/platform/QCOM8060:*/hw_version_minor
+Date:		Nov 2015
+KernelVersion:	4.4
+Contact:	"Sinan Kaya <okaya at cudeaurora.org>"
+Description:
+		Version number minor for the hardware.
+
+What:		/sys/devices/platform/hidma-mgmt*/max_rd_xactions
+		/sys/devices/platform/QCOM8060:*/max_rd_xactions
+Date:		Nov 2015
+KernelVersion:	4.4
+Contact:	"Sinan Kaya <okaya at cudeaurora.org>"
+Description:
+		Contains a value between 0 and 31. Maximum number of
+		read transactions that can be issued back to back.
+		Choosing a higher number gives better performance but
+		can also cause performance reduction to other peripherals
+		sharing the same bus.
+
+What:		/sys/devices/platform/hidma-mgmt*/max_read_request
+		/sys/devices/platform/QCOM8060:*/max_read_request
+Date:		Nov 2015
+KernelVersion:	4.4
+Contact:	"Sinan Kaya <okaya at cudeaurora.org>"
+Description:
+		Size of each read request. The value needs to be a power
+		of two and can be between 128 and 1024.
+
+What:		/sys/devices/platform/hidma-mgmt*/max_wr_xactions
+		/sys/devices/platform/QCOM8060:*/max_wr_xactions
+Date:		Nov 2015
+KernelVersion:	4.4
+Contact:	"Sinan Kaya <okaya at cudeaurora.org>"
+Description:
+		Contains a value between 0 and 31. Maximum number of
+		write transactions that can be issued back to back.
+		Choosing a higher number gives better performance but
+		can also cause performance reduction to other peripherals
+		sharing the same bus.
+
+
+What:		/sys/devices/platform/hidma-mgmt*/max_write_request
+		/sys/devices/platform/QCOM8060:*/max_write_request
+Date:		Nov 2015
+KernelVersion:	4.4
+Contact:	"Sinan Kaya <okaya at cudeaurora.org>"
+Description:
+		Size of each write request. The value needs to be a power
+		of two and can be between 128 and 1024.
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index f17c272..c975b11 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -6,3 +6,14 @@ config QCOM_BAM_DMA
 	---help---
 	  Enable support for the QCOM BAM DMA controller.  This controller
 	  provides DMA capabilities for a variety of on-chip devices.
+
+config QCOM_HIDMA_MGMT
+	tristate "Qualcomm Technologies HIDMA Management support"
+	select DMA_ENGINE
+	help
+	  Enable support for the Qualcomm Technologies HIDMA Management.
+	  Each DMA device requires one management interface driver
+	  for basic initialization before QCOM_HIDMA channel driver can
+	  start managing the channels. In a virtualized environment,
+	  the guest OS would run QCOM_HIDMA channel driver and the
+	  host would run the QCOM_HIDMA_MGMT management driver.
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index f612ae3..bfea699 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1 +1,3 @@
 obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
+obj-$(CONFIG_QCOM_HIDMA_MGMT) += hdma_mgmt.o
+hdma_mgmt-objs	 := hidma_mgmt.o hidma_mgmt_sys.o
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
new file mode 100644
index 0000000..ef491b8
--- /dev/null
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -0,0 +1,302 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine Management interface
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/dmaengine.h>
+#include <linux/acpi.h>
+#include <linux/of.h>
+#include <linux/property.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/uaccess.h>
+#include <linux/slab.h>
+#include <linux/pm_runtime.h>
+#include <linux/bitops.h>
+
+#include "hidma_mgmt.h"
+
+#define HIDMA_QOS_N_OFFSET		0x300
+#define HIDMA_CFG_OFFSET		0x400
+#define HIDMA_MAX_BUS_REQ_LEN_OFFSET	0x41C
+#define HIDMA_MAX_XACTIONS_OFFSET	0x420
+#define HIDMA_HW_VERSION_OFFSET	0x424
+#define HIDMA_CHRESET_TIMEOUT_OFFSET	0x418
+
+#define HIDMA_MAX_WR_XACTIONS_MASK	GENMASK(4, 0)
+#define HIDMA_MAX_RD_XACTIONS_MASK	GENMASK(4, 0)
+#define HIDMA_WEIGHT_MASK		GENMASK(6, 0)
+#define HIDMA_MAX_BUS_REQ_LEN_MASK	GENMASK(15, 0)
+#define HIDMA_CHRESET_TIMEOUT_MASK	GENMASK(19, 0)
+
+#define HIDMA_MAX_WR_XACTIONS_BIT_POS	16
+#define HIDMA_MAX_BUS_WR_REQ_BIT_POS	16
+#define HIDMA_WRR_BIT_POS		8
+#define HIDMA_PRIORITY_BIT_POS		15
+
+#define HIDMA_AUTOSUSPEND_TIMEOUT	2000
+#define HIDMA_MAX_CHANNEL_WEIGHT	15
+
+int hidma_mgmt_setup(struct hidma_mgmt_dev *mgmtdev)
+{
+	unsigned int i;
+	u32 val;
+
+	if (!is_power_of_2(mgmtdev->max_write_request) ||
+	    (mgmtdev->max_write_request < 128) ||
+	    (mgmtdev->max_write_request > 1024)) {
+		dev_err(&mgmtdev->pdev->dev, "invalid write request %d\n",
+			mgmtdev->max_write_request);
+		return -EINVAL;
+	}
+
+	if (!is_power_of_2(mgmtdev->max_read_request) ||
+	    (mgmtdev->max_read_request < 128) ||
+	    (mgmtdev->max_read_request > 1024)) {
+		dev_err(&mgmtdev->pdev->dev, "invalid read request %d\n",
+			mgmtdev->max_read_request);
+		return -EINVAL;
+	}
+
+	if (mgmtdev->max_wr_xactions > HIDMA_MAX_WR_XACTIONS_MASK) {
+		dev_err(&mgmtdev->pdev->dev,
+			"max_wr_xactions cannot be bigger than %ld\n",
+			HIDMA_MAX_WR_XACTIONS_MASK);
+		return -EINVAL;
+	}
+
+	if (mgmtdev->max_rd_xactions > HIDMA_MAX_RD_XACTIONS_MASK) {
+		dev_err(&mgmtdev->pdev->dev,
+			"max_rd_xactions cannot be bigger than %ld\n",
+			HIDMA_MAX_RD_XACTIONS_MASK);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < mgmtdev->dma_channels; i++) {
+		if (mgmtdev->priority[i] > 1) {
+			dev_err(&mgmtdev->pdev->dev,
+				"priority can be 0 or 1\n");
+			return -EINVAL;
+		}
+
+		if (mgmtdev->weight[i] > HIDMA_MAX_CHANNEL_WEIGHT) {
+			dev_err(&mgmtdev->pdev->dev,
+				"max value of weight can be %d.\n",
+				HIDMA_MAX_CHANNEL_WEIGHT);
+			return -EINVAL;
+		}
+
+		/* weight needs to be at least one */
+		if (mgmtdev->weight[i] == 0)
+			mgmtdev->weight[i] = 1;
+	}
+
+	pm_runtime_get_sync(&mgmtdev->pdev->dev);
+	val = readl(mgmtdev->virtaddr + HIDMA_MAX_BUS_REQ_LEN_OFFSET);
+	val &= ~(HIDMA_MAX_BUS_REQ_LEN_MASK << HIDMA_MAX_BUS_WR_REQ_BIT_POS);
+	val |= mgmtdev->max_write_request << HIDMA_MAX_BUS_WR_REQ_BIT_POS;
+	val &= ~HIDMA_MAX_BUS_REQ_LEN_MASK;
+	val |= mgmtdev->max_read_request;
+	writel(val, mgmtdev->virtaddr + HIDMA_MAX_BUS_REQ_LEN_OFFSET);
+
+	val = readl(mgmtdev->virtaddr + HIDMA_MAX_XACTIONS_OFFSET);
+	val &= ~(HIDMA_MAX_WR_XACTIONS_MASK << HIDMA_MAX_WR_XACTIONS_BIT_POS);
+	val |= mgmtdev->max_wr_xactions << HIDMA_MAX_WR_XACTIONS_BIT_POS;
+	val &= ~HIDMA_MAX_RD_XACTIONS_MASK;
+	val |= mgmtdev->max_rd_xactions;
+	writel(val, mgmtdev->virtaddr + HIDMA_MAX_XACTIONS_OFFSET);
+
+	mgmtdev->hw_version =
+	    readl(mgmtdev->virtaddr + HIDMA_HW_VERSION_OFFSET);
+	mgmtdev->hw_version_major = (mgmtdev->hw_version >> 28) & 0xF;
+	mgmtdev->hw_version_minor = (mgmtdev->hw_version >> 16) & 0xF;
+
+	for (i = 0; i < mgmtdev->dma_channels; i++) {
+		u32 weight = mgmtdev->weight[i];
+		u32 priority = mgmtdev->priority[i];
+
+		val = readl(mgmtdev->virtaddr + HIDMA_QOS_N_OFFSET + (4 * i));
+		val &= ~(1 << HIDMA_PRIORITY_BIT_POS);
+		val |= (priority & 0x1) << HIDMA_PRIORITY_BIT_POS;
+		val &= ~(HIDMA_WEIGHT_MASK << HIDMA_WRR_BIT_POS);
+		val |= (weight & HIDMA_WEIGHT_MASK) << HIDMA_WRR_BIT_POS;
+		writel(val, mgmtdev->virtaddr + HIDMA_QOS_N_OFFSET + (4 * i));
+	}
+
+	val = readl(mgmtdev->virtaddr + HIDMA_CHRESET_TIMEOUT_OFFSET);
+	val &= ~HIDMA_CHRESET_TIMEOUT_MASK;
+	val |= mgmtdev->chreset_timeout_cycles & HIDMA_CHRESET_TIMEOUT_MASK;
+	writel(val, mgmtdev->virtaddr + HIDMA_CHRESET_TIMEOUT_OFFSET);
+
+	pm_runtime_mark_last_busy(&mgmtdev->pdev->dev);
+	pm_runtime_put_autosuspend(&mgmtdev->pdev->dev);
+	return 0;
+}
+EXPORT_SYMBOL_GPL(hidma_mgmt_setup);
+
+static int hidma_mgmt_probe(struct platform_device *pdev)
+{
+	struct hidma_mgmt_dev *mgmtdev;
+	struct resource *res;
+	void __iomem *virtaddr;
+	int irq;
+	int rc;
+	u32 val;
+
+	pm_runtime_set_autosuspend_delay(&pdev->dev, HIDMA_AUTOSUSPEND_TIMEOUT);
+	pm_runtime_use_autosuspend(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+	pm_runtime_get_sync(&pdev->dev);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	virtaddr = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(virtaddr)) {
+		rc = -ENOMEM;
+		goto out;
+	}
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "irq resources not found\n");
+		rc = irq;
+		goto out;
+	}
+
+	mgmtdev = devm_kzalloc(&pdev->dev, sizeof(*mgmtdev), GFP_KERNEL);
+	if (!mgmtdev) {
+		rc = -ENOMEM;
+		goto out;
+	}
+
+	mgmtdev->pdev = pdev;
+	mgmtdev->addrsize = resource_size(res);
+	mgmtdev->virtaddr = virtaddr;
+
+	rc = device_property_read_u32(&pdev->dev, "dma-channels",
+				      &mgmtdev->dma_channels);
+	if (rc) {
+		dev_err(&pdev->dev, "number of channels missing\n");
+		goto out;
+	}
+
+	rc = device_property_read_u32(&pdev->dev,
+				      "channel-reset-timeout-cycles",
+				      &mgmtdev->chreset_timeout_cycles);
+	if (rc) {
+		dev_err(&pdev->dev, "channel reset timeout missing\n");
+		goto out;
+	}
+
+	rc = device_property_read_u32(&pdev->dev, "max-write-burst-bytes",
+				      &mgmtdev->max_write_request);
+	if (rc) {
+		dev_err(&pdev->dev, "max-write-burst-bytes missing\n");
+		goto out;
+	}
+
+	rc = device_property_read_u32(&pdev->dev, "max-read-burst-bytes",
+				      &mgmtdev->max_read_request);
+	if (rc) {
+		dev_err(&pdev->dev, "max-read-burst-bytes missing\n");
+		goto out;
+	}
+
+	rc = device_property_read_u32(&pdev->dev, "max-write-transactions",
+				      &mgmtdev->max_wr_xactions);
+	if (rc) {
+		dev_err(&pdev->dev, "max-write-transactions missing\n");
+		goto out;
+	}
+
+	rc = device_property_read_u32(&pdev->dev, "max-read-transactions",
+				      &mgmtdev->max_rd_xactions);
+	if (rc) {
+		dev_err(&pdev->dev, "max-read-transactions missing\n");
+		goto out;
+	}
+
+	mgmtdev->priority = devm_kcalloc(&pdev->dev,
+					 mgmtdev->dma_channels,
+					 sizeof(*mgmtdev->priority),
+					 GFP_KERNEL);
+	if (!mgmtdev->priority) {
+		rc = -ENOMEM;
+		goto out;
+	}
+
+	mgmtdev->weight = devm_kcalloc(&pdev->dev,
+				       mgmtdev->dma_channels,
+				       sizeof(*mgmtdev->weight), GFP_KERNEL);
+	if (!mgmtdev->weight) {
+		rc = -ENOMEM;
+		goto out;
+	}
+
+	rc = hidma_mgmt_setup(mgmtdev);
+	if (rc) {
+		dev_err(&pdev->dev, "setup failed\n");
+		goto out;
+	}
+
+	/* start the HW */
+	val = readl(mgmtdev->virtaddr + HIDMA_CFG_OFFSET);
+	val |= 1;
+	writel(val, mgmtdev->virtaddr + HIDMA_CFG_OFFSET);
+
+	rc = hidma_mgmt_init_sys(mgmtdev);
+	if (rc) {
+		dev_err(&pdev->dev, "sysfs setup failed\n");
+		goto out;
+	}
+
+	dev_info(&pdev->dev,
+		 "HW rev: %d.%d @ %pa with %d physical channels\n",
+		 mgmtdev->hw_version_major, mgmtdev->hw_version_minor,
+		 &res->start, mgmtdev->dma_channels);
+
+	platform_set_drvdata(pdev, mgmtdev);
+	pm_runtime_mark_last_busy(&pdev->dev);
+	pm_runtime_put_autosuspend(&pdev->dev);
+	return 0;
+out:
+	pm_runtime_put_sync_suspend(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+	return rc;
+}
+
+#if IS_ENABLED(CONFIG_ACPI)
+static const struct acpi_device_id hidma_mgmt_acpi_ids[] = {
+	{"QCOM8060"},
+	{},
+};
+#endif
+
+static const struct of_device_id hidma_mgmt_match[] = {
+	{.compatible = "qcom,hidma-mgmt-1.0",},
+	{},
+};
+MODULE_DEVICE_TABLE(of, hidma_mgmt_match);
+
+static struct platform_driver hidma_mgmt_driver = {
+	.probe = hidma_mgmt_probe,
+	.driver = {
+		   .name = "hidma-mgmt",
+		   .of_match_table = hidma_mgmt_match,
+		   .acpi_match_table = ACPI_PTR(hidma_mgmt_acpi_ids),
+	},
+};
+
+module_platform_driver(hidma_mgmt_driver);
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/dma/qcom/hidma_mgmt.h b/drivers/dma/qcom/hidma_mgmt.h
new file mode 100644
index 0000000..f7daf33
--- /dev/null
+++ b/drivers/dma/qcom/hidma_mgmt.h
@@ -0,0 +1,39 @@
+/*
+ * Qualcomm Technologies HIDMA Management common header
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+struct hidma_mgmt_dev {
+	u8 hw_version_major;
+	u8 hw_version_minor;
+
+	u32 max_wr_xactions;
+	u32 max_rd_xactions;
+	u32 max_write_request;
+	u32 max_read_request;
+	u32 dma_channels;
+	u32 chreset_timeout_cycles;
+	u32 hw_version;
+	u32 *priority;
+	u32 *weight;
+
+	/* Hardware device constants */
+	void __iomem *virtaddr;
+	resource_size_t addrsize;
+
+	struct kobject **chroots;
+	struct platform_device *pdev;
+};
+
+int hidma_mgmt_init_sys(struct hidma_mgmt_dev *dev);
+int hidma_mgmt_setup(struct hidma_mgmt_dev *mgmtdev);
diff --git a/drivers/dma/qcom/hidma_mgmt_sys.c b/drivers/dma/qcom/hidma_mgmt_sys.c
new file mode 100644
index 0000000..d61f106
--- /dev/null
+++ b/drivers/dma/qcom/hidma_mgmt_sys.c
@@ -0,0 +1,295 @@
+/*
+ * Qualcomm Technologies HIDMA Management SYS interface
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/sysfs.h>
+#include <linux/platform_device.h>
+
+#include "hidma_mgmt.h"
+
+struct hidma_chan_attr {
+	struct hidma_mgmt_dev *mdev;
+	int index;
+	struct kobj_attribute attr;
+};
+
+struct hidma_mgmt_fileinfo {
+	char *name;
+	int mode;
+	int (*get)(struct hidma_mgmt_dev *mdev);
+	int (*set)(struct hidma_mgmt_dev *mdev, u64 val);
+};
+
+#define IMPLEMENT_GETSET(name)					\
+static int get_##name(struct hidma_mgmt_dev *mdev)		\
+{								\
+	return mdev->name;					\
+}								\
+static int set_##name(struct hidma_mgmt_dev *mdev, u64 val)	\
+{								\
+	u64 tmp;						\
+	int rc;							\
+								\
+	tmp = mdev->name;					\
+	mdev->name = val;					\
+	rc = hidma_mgmt_setup(mdev);				\
+	if (rc)							\
+		mdev->name = tmp;				\
+	return rc;						\
+}
+
+#define DECLARE_ATTRIBUTE(name, mode)				\
+	{#name, mode, get_##name, set_##name}
+
+IMPLEMENT_GETSET(hw_version_major)
+IMPLEMENT_GETSET(hw_version_minor)
+IMPLEMENT_GETSET(max_wr_xactions)
+IMPLEMENT_GETSET(max_rd_xactions)
+IMPLEMENT_GETSET(max_write_request)
+IMPLEMENT_GETSET(max_read_request)
+IMPLEMENT_GETSET(dma_channels)
+IMPLEMENT_GETSET(chreset_timeout_cycles)
+
+static int set_priority(struct hidma_mgmt_dev *mdev, unsigned int i, u64 val)
+{
+	u64 tmp;
+	int rc;
+
+	if (i >= mdev->dma_channels)
+		return -EINVAL;
+
+	tmp = mdev->priority[i];
+	mdev->priority[i] = val;
+	rc = hidma_mgmt_setup(mdev);
+	if (rc)
+		mdev->priority[i] = tmp;
+	return rc;
+}
+
+static int set_weight(struct hidma_mgmt_dev *mdev, unsigned int i, u64 val)
+{
+	u64 tmp;
+	int rc;
+
+	if (i >= mdev->dma_channels)
+		return -EINVAL;
+
+	tmp = mdev->weight[i];
+	mdev->weight[i] = val;
+	rc = hidma_mgmt_setup(mdev);
+	if (rc)
+		mdev->weight[i] = tmp;
+	return rc;
+}
+
+static struct hidma_mgmt_fileinfo hidma_mgmt_files[] = {
+	DECLARE_ATTRIBUTE(hw_version_major, S_IRUGO),
+	DECLARE_ATTRIBUTE(hw_version_minor, S_IRUGO),
+	DECLARE_ATTRIBUTE(dma_channels, S_IRUGO),
+	DECLARE_ATTRIBUTE(chreset_timeout_cycles, S_IRUGO),
+	DECLARE_ATTRIBUTE(max_wr_xactions, S_IRUGO),
+	DECLARE_ATTRIBUTE(max_rd_xactions, S_IRUGO),
+	DECLARE_ATTRIBUTE(max_write_request, S_IRUGO),
+	DECLARE_ATTRIBUTE(max_read_request, S_IRUGO),
+};
+
+static ssize_t show_values(struct device *dev, struct device_attribute *attr,
+			   char *buf)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct hidma_mgmt_dev *mdev = platform_get_drvdata(pdev);
+	unsigned int i;
+
+	buf[0] = 0;
+
+	for (i = 0; i < ARRAY_SIZE(hidma_mgmt_files); i++) {
+		if (strcmp(attr->attr.name, hidma_mgmt_files[i].name) == 0) {
+			sprintf(buf, "%d\n", hidma_mgmt_files[i].get(mdev));
+			break;
+		}
+	}
+	return strlen(buf);
+}
+
+static ssize_t set_values(struct device *dev, struct device_attribute *attr,
+			  const char *buf, size_t count)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct hidma_mgmt_dev *mdev = platform_get_drvdata(pdev);
+	unsigned long tmp;
+	unsigned int i;
+	int rc;
+
+	rc = kstrtoul(buf, 0, &tmp);
+	if (rc)
+		return rc;
+
+	for (i = 0; i < ARRAY_SIZE(hidma_mgmt_files); i++) {
+		if (strcmp(attr->attr.name, hidma_mgmt_files[i].name) == 0) {
+			rc = hidma_mgmt_files[i].set(mdev, tmp);
+			if (rc)
+				return rc;
+
+			break;
+		}
+	}
+	return count;
+}
+
+static ssize_t show_values_channel(struct kobject *kobj,
+				   struct kobj_attribute *attr, char *buf)
+{
+	struct hidma_chan_attr *chattr;
+	struct hidma_mgmt_dev *mdev;
+
+	buf[0] = 0;
+	chattr = container_of(attr, struct hidma_chan_attr, attr);
+	mdev = chattr->mdev;
+	if (strcmp(attr->attr.name, "priority") == 0)
+		sprintf(buf, "%d\n", mdev->priority[chattr->index]);
+	else if (strcmp(attr->attr.name, "weight") == 0)
+		sprintf(buf, "%d\n", mdev->weight[chattr->index]);
+
+	return strlen(buf);
+}
+
+static ssize_t set_values_channel(struct kobject *kobj,
+				  struct kobj_attribute *attr, const char *buf,
+				  size_t count)
+{
+	struct hidma_chan_attr *chattr;
+	struct hidma_mgmt_dev *mdev;
+	unsigned long tmp;
+	int rc;
+
+	chattr = container_of(attr, struct hidma_chan_attr, attr);
+	mdev = chattr->mdev;
+
+	rc = kstrtoul(buf, 0, &tmp);
+	if (rc)
+		return rc;
+
+	if (strcmp(attr->attr.name, "priority") == 0) {
+		rc = set_priority(mdev, chattr->index, tmp);
+		if (rc)
+			return rc;
+	} else if (strcmp(attr->attr.name, "weight") == 0) {
+		rc = set_weight(mdev, chattr->index, tmp);
+		if (rc)
+			return rc;
+	}
+	return count;
+}
+
+static int create_sysfs_entry(struct hidma_mgmt_dev *dev, char *name, int mode)
+{
+	struct device_attribute *attrs;
+	char *name_copy;
+
+	attrs = devm_kmalloc(&dev->pdev->dev,
+			     sizeof(struct device_attribute), GFP_KERNEL);
+	if (!attrs)
+		return -ENOMEM;
+
+	name_copy = devm_kstrdup(&dev->pdev->dev, name, GFP_KERNEL);
+	if (!name_copy)
+		return -ENOMEM;
+
+	attrs->attr.name = name_copy;
+	attrs->attr.mode = mode;
+	attrs->show = show_values;
+	attrs->store = set_values;
+	sysfs_attr_init(&attrs->attr);
+
+	return device_create_file(&dev->pdev->dev, attrs);
+}
+
+static int create_sysfs_entry_channel(struct hidma_mgmt_dev *mdev, char *name,
+				      int mode, int index,
+				      struct kobject *parent)
+{
+	struct hidma_chan_attr *chattr;
+	char *name_copy;
+
+	chattr = devm_kmalloc(&mdev->pdev->dev, sizeof(*chattr), GFP_KERNEL);
+	if (!chattr)
+		return -ENOMEM;
+
+	name_copy = devm_kstrdup(&mdev->pdev->dev, name, GFP_KERNEL);
+	if (!name_copy)
+		return -ENOMEM;
+
+	chattr->mdev = mdev;
+	chattr->index = index;
+	chattr->attr.attr.name = name_copy;
+	chattr->attr.attr.mode = mode;
+	chattr->attr.show = show_values_channel;
+	chattr->attr.store = set_values_channel;
+	sysfs_attr_init(&chattr->attr.attr);
+
+	return sysfs_create_file(parent, &chattr->attr.attr);
+}
+
+int hidma_mgmt_init_sys(struct hidma_mgmt_dev *mdev)
+{
+	unsigned int i;
+	int rc;
+	int required;
+	struct kobject *chanops;
+
+	required = sizeof(*mdev->chroots) * mdev->dma_channels;
+	mdev->chroots = devm_kmalloc(&mdev->pdev->dev, required, GFP_KERNEL);
+	if (!mdev->chroots)
+		return -ENOMEM;
+
+	chanops = kobject_create_and_add("chanops", &mdev->pdev->dev.kobj);
+	if (!chanops)
+		return -ENOMEM;
+
+	/* create each channel directory here */
+	for (i = 0; i < mdev->dma_channels; i++) {
+		char name[20];
+
+		snprintf(name, sizeof(name), "chan%d", i);
+		mdev->chroots[i] = kobject_create_and_add(name, chanops);
+		if (!mdev->chroots[i])
+			return -ENOMEM;
+	}
+
+	/* populate common parameters */
+	for (i = 0; i < ARRAY_SIZE(hidma_mgmt_files); i++) {
+		rc = create_sysfs_entry(mdev, hidma_mgmt_files[i].name,
+					hidma_mgmt_files[i].mode);
+		if (rc)
+			return rc;
+	}
+
+	/* populate parameters that are per channel */
+	for (i = 0; i < mdev->dma_channels; i++) {
+		rc = create_sysfs_entry_channel(mdev, "priority",
+						(S_IRUGO | S_IWUGO), i,
+						mdev->chroots[i]);
+		if (rc)
+			return rc;
+
+		rc = create_sysfs_entry_channel(mdev, "weight",
+						(S_IRUGO | S_IWUGO), i,
+						mdev->chroots[i]);
+		if (rc)
+			return rc;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(hidma_mgmt_init_sys);
-- 
1.8.2.1



From okaya at codeaurora.org  Thu Feb  4 20:34:38 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Thu,  4 Feb 2016 23:34:38 -0500
Subject: [PATCH V14 7/9] dma: qcom_hidma: add support for object hierarchy
In-Reply-To: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
References: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
Message-ID: <1454646882-24369-8-git-send-email-okaya@codeaurora.org>

In order to create a relationship model between the channels and the
management object, we are adding support for object hierarchy to the
drivers. This patch simplifies the userspace application development.
We will not have to traverse different firmware paths based on device
tree or ACPI baed kernels.

No matter what flavor of kernel is used, objects will be represented as
platform devices.

The new layout is as follows:

hidmam_10: hidma-mgmt at 0x5A000000 {
	compatible = "qcom,hidma-mgmt-1.0";
	...

	hidma_10: hidma at 0x5a010000 {
			compatible = "qcom,hidma-1.0";
			...
	}
}

The hidma_mgmt_init detects each instance of the hidma-mgmt-1.0 objects
in device tree and calls into the channel driver to create platform devices
for each child of the management object.

Signed-off-by: Sinan Kaya <okaya at codeaurora.org>
---
 Documentation/ABI/testing/sysfs-platform-hidma |   9 ++
 drivers/dma/qcom/hidma.c                       |  39 ++++++++-
 drivers/dma/qcom/hidma_mgmt.c                  | 111 ++++++++++++++++++++++++-
 3 files changed, 155 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma

diff --git a/Documentation/ABI/testing/sysfs-platform-hidma b/Documentation/ABI/testing/sysfs-platform-hidma
new file mode 100644
index 0000000..d364415
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-hidma
@@ -0,0 +1,9 @@
+What:		/sys/devices/platform/hidma-*/chid
+		/sys/devices/platform/QCOM8061:*/chid
+Date:		Dec 2015
+KernelVersion:	4.4
+Contact:	"Sinan Kaya <okaya at cudeaurora.org>"
+Description:
+		Contains the ID of the channel within the HIDMA instance.
+		It is used to associate a given HIDMA channel with the
+		priority and weight calls in the management interface.
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index c0832c7..58e128c 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -530,6 +530,43 @@ static irqreturn_t hidma_chirq_handler(int chirq, void *arg)
 	return hidma_ll_inthandler(chirq, lldev);
 }
 
+static ssize_t hidma_show_values(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct hidma_dev *mdev = platform_get_drvdata(pdev);
+
+	buf[0] = 0;
+
+	if (strcmp(attr->attr.name, "chid") == 0)
+		sprintf(buf, "%d\n", mdev->chidx);
+
+	return strlen(buf);
+}
+
+static int hidma_create_sysfs_entry(struct hidma_dev *dev, char *name,
+				    int mode)
+{
+	struct device_attribute *attrs;
+	char *name_copy;
+
+	attrs = devm_kmalloc(dev->ddev.dev, sizeof(struct device_attribute),
+			     GFP_KERNEL);
+	if (!attrs)
+		return -ENOMEM;
+
+	name_copy = devm_kstrdup(dev->ddev.dev, name, GFP_KERNEL);
+	if (!name_copy)
+		return -ENOMEM;
+
+	attrs->attr.name = name_copy;
+	attrs->attr.mode = mode;
+	attrs->show = hidma_show_values;
+	sysfs_attr_init(&attrs->attr);
+
+	return device_create_file(dev->ddev.dev, attrs);
+}
+
 static int hidma_probe(struct platform_device *pdev)
 {
 	struct hidma_dev *dmadev;
@@ -645,6 +682,7 @@ static int hidma_probe(struct platform_device *pdev)
 	dmadev->irq = chirq;
 	tasklet_init(&dmadev->task, hidma_issue_task, (unsigned long)dmadev);
 	hidma_debug_init(dmadev);
+	hidma_create_sysfs_entry(dmadev, "chid", S_IRUGO);
 	dev_info(&pdev->dev, "HI-DMA engine driver registration complete\n");
 	platform_set_drvdata(pdev, dmadev);
 	pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -692,7 +730,6 @@ static const struct of_device_id hidma_match[] = {
 	{.compatible = "qcom,hidma-1.0",},
 	{},
 };
-
 MODULE_DEVICE_TABLE(of, hidma_match);
 
 static struct platform_driver hidma_driver = {
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index ef491b8..143acdd 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -17,13 +17,14 @@
 #include <linux/acpi.h>
 #include <linux/of.h>
 #include <linux/property.h>
-#include <linux/interrupt.h>
-#include <linux/platform_device.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
 #include <linux/module.h>
 #include <linux/uaccess.h>
 #include <linux/slab.h>
 #include <linux/pm_runtime.h>
 #include <linux/bitops.h>
+#include <linux/dma-mapping.h>
 
 #include "hidma_mgmt.h"
 
@@ -298,5 +299,109 @@ static struct platform_driver hidma_mgmt_driver = {
 	},
 };
 
-module_platform_driver(hidma_mgmt_driver);
+#if defined(CONFIG_OF) && defined(CONFIG_OF_IRQ)
+static int object_counter;
+
+static int __init hidma_mgmt_of_populate_channels(struct device_node *np)
+{
+	struct platform_device *pdev_parent = of_find_device_by_node(np);
+	struct platform_device_info pdevinfo;
+	struct of_phandle_args out_irq;
+	struct device_node *child;
+	struct resource *res;
+	const __be32 *cell;
+	int ret = 0, size, i, num;
+	u64 addr, addr_size;
+
+	for_each_available_child_of_node(np, child) {
+		struct resource *res_iter;
+		struct platform_device *new_pdev;
+
+		cell = of_get_property(child, "reg", &size);
+		if (!cell) {
+			ret = -EINVAL;
+			goto out;
+		}
+
+		size /= sizeof(*cell);
+		num = size /
+			(of_n_addr_cells(child) + of_n_size_cells(child)) + 1;
+
+		/* allocate a resource array */
+		res = kcalloc(num, sizeof(*res), GFP_KERNEL);
+		if (!res) {
+			ret = -ENOMEM;
+			goto out;
+		}
+
+		/* read each reg value */
+		i = 0;
+		res_iter = res;
+		while (i < size) {
+			addr = of_read_number(&cell[i],
+					      of_n_addr_cells(child));
+			i += of_n_addr_cells(child);
+
+			addr_size = of_read_number(&cell[i],
+						   of_n_size_cells(child));
+			i += of_n_size_cells(child);
+
+			res_iter->start = addr;
+			res_iter->end = res_iter->start + addr_size - 1;
+			res_iter->flags = IORESOURCE_MEM;
+			res_iter++;
+		}
+
+		ret = of_irq_parse_one(child, 0, &out_irq);
+		if (ret)
+			goto out;
+
+		res_iter->start = irq_create_of_mapping(&out_irq);
+		res_iter->name = "hidma event irq";
+		res_iter->flags = IORESOURCE_IRQ;
+
+		memset(&pdevinfo, 0, sizeof(pdevinfo));
+		pdevinfo.fwnode = &child->fwnode;
+		pdevinfo.parent = pdev_parent ? &pdev_parent->dev : NULL;
+		pdevinfo.name = child->name;
+		pdevinfo.id = object_counter++;
+		pdevinfo.res = res;
+		pdevinfo.num_res = num;
+		pdevinfo.data = NULL;
+		pdevinfo.size_data = 0;
+		pdevinfo.dma_mask = DMA_BIT_MASK(64);
+		new_pdev = platform_device_register_full(&pdevinfo);
+		if (!new_pdev) {
+			ret = -ENODEV;
+			goto out;
+		}
+		of_dma_configure(&new_pdev->dev, new_pdev->dev.of_node);
+
+		kfree(res);
+		res = NULL;
+	}
+out:
+	kfree(res);
+
+	return ret;
+}
+#endif
+
+static int __init hidma_mgmt_init(void)
+{
+#if defined(CONFIG_OF) && defined(CONFIG_OF_IRQ)
+	struct device_node *child;
+
+	for (child = of_find_matching_node(NULL, hidma_mgmt_match); child;
+	     child = of_find_matching_node(child, hidma_mgmt_match)) {
+		/* device tree based firmware here */
+		hidma_mgmt_of_populate_channels(child);
+		of_node_put(child);
+	}
+#endif
+	platform_driver_register(&hidma_mgmt_driver);
+
+	return 0;
+}
+module_init(hidma_mgmt_init);
 MODULE_LICENSE("GPL v2");
-- 
1.8.2.1



From okaya at codeaurora.org  Thu Feb  4 20:34:39 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Thu,  4 Feb 2016 23:34:39 -0500
Subject: [PATCH V14 8/9] vfio,
 platform: add support for ACPI while detecting the reset driver
In-Reply-To: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
References: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
Message-ID: <1454646882-24369-9-git-send-email-okaya@codeaurora.org>

The code is using the compatible DT string to associate a reset driver with
the actual device itself. The compatible string does not exist on ACPI
based systems. HID is the unique identifier for a device driver instead.
The change allows a driver to register with DT compatible string or ACPI
HID and then match the object with one of these conditions.

Rules for loading the reset driver are as follow:
- ACPI HID needs match for ACPI systems
- DT compat needs to match for OF systems

Tested-by: Eric Auger <eric.auger at linaro.org> (device tree only)
Tested-by: Shanker Donthineni <shankerd at codeaurora.org> (ACPI only)
Signed-off-by: Sinan Kaya <okaya at codeaurora.org>
---
 .../vfio/platform/reset/vfio_platform_amdxgbe.c    |  3 +-
 .../platform/reset/vfio_platform_calxedaxgmac.c    |  3 +-
 drivers/vfio/platform/vfio_platform_common.c       | 80 +++++++++++++++++++---
 drivers/vfio/platform/vfio_platform_private.h      | 41 ++++++-----
 4 files changed, 96 insertions(+), 31 deletions(-)

diff --git a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
index d4030d0..cc5b4fa 100644
--- a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
+++ b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
@@ -119,7 +119,8 @@ int vfio_platform_amdxgbe_reset(struct vfio_platform_device *vdev)
 	return 0;
 }
 
-module_vfio_reset_handler("amd,xgbe-seattle-v1a", vfio_platform_amdxgbe_reset);
+module_vfio_reset_handler("amd,xgbe-seattle-v1a", NULL,
+			  vfio_platform_amdxgbe_reset);
 
 MODULE_VERSION("0.1");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
index e3d3d94..0e57529 100644
--- a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
+++ b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
@@ -77,7 +77,8 @@ int vfio_platform_calxedaxgmac_reset(struct vfio_platform_device *vdev)
 	return 0;
 }
 
-module_vfio_reset_handler("calxeda,hb-xgmac", vfio_platform_calxedaxgmac_reset);
+module_vfio_reset_handler("calxeda,hb-xgmac", NULL,
+			  vfio_platform_calxedaxgmac_reset);
 
 MODULE_VERSION(DRIVER_VERSION);
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/vfio/platform/vfio_platform_common.c b/drivers/vfio/platform/vfio_platform_common.c
index 418cdd9..5b42e93 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -13,6 +13,7 @@
  */
 
 #include <linux/device.h>
+#include <linux/acpi.h>
 #include <linux/iommu.h>
 #include <linux/module.h>
 #include <linux/mutex.h>
@@ -31,14 +32,22 @@ static LIST_HEAD(reset_list);
 static DEFINE_MUTEX(driver_lock);
 
 static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char *compat,
-					struct module **module)
+				  const char *acpihid, struct module **module)
 {
 	struct vfio_platform_reset_node *iter;
 	vfio_platform_reset_fn_t reset_fn = NULL;
 
 	mutex_lock(&driver_lock);
 	list_for_each_entry(iter, &reset_list, link) {
-		if (!strcmp(iter->compat, compat) &&
+		if (acpihid && iter->acpihid &&
+		    !strcmp(iter->acpihid, acpihid) &&
+			try_module_get(iter->owner)) {
+			*module = iter->owner;
+			reset_fn = iter->reset;
+			break;
+		}
+		if (compat && iter->compat &&
+		    !strcmp(iter->compat, compat) &&
 			try_module_get(iter->owner)) {
 			*module = iter->owner;
 			reset_fn = iter->reset;
@@ -51,11 +60,12 @@ static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char *compat,
 
 static void vfio_platform_get_reset(struct vfio_platform_device *vdev)
 {
-	vdev->reset = vfio_platform_lookup_reset(vdev->compat,
-						&vdev->reset_module);
+	vdev->reset = vfio_platform_lookup_reset(vdev->compat, vdev->acpihid,
+						 &vdev->reset_module);
 	if (!vdev->reset) {
 		request_module("vfio-reset:%s", vdev->compat);
 		vdev->reset = vfio_platform_lookup_reset(vdev->compat,
+							 vdev->acpihid,
 							 &vdev->reset_module);
 	}
 }
@@ -541,6 +551,46 @@ static const struct vfio_device_ops vfio_platform_ops = {
 	.mmap		= vfio_platform_mmap,
 };
 
+#ifdef CONFIG_ACPI
+int vfio_platform_probe_acpi(struct vfio_platform_device *vdev,
+			     struct device *dev)
+{
+	struct acpi_device *adev = ACPI_COMPANION(dev);
+
+	if (!adev)
+		return -EINVAL;
+
+	vdev->acpihid = acpi_device_hid(adev);
+	if (!vdev->acpihid) {
+		pr_err("VFIO: cannot find ACPI HID for %s\n",
+		       vdev->name);
+		return -EINVAL;
+	}
+	return 0;
+}
+#else
+int vfio_platform_probe_acpi(struct vfio_platform_device *vdev,
+			     struct device *dev)
+{
+	return -EINVAL;
+}
+#endif
+
+int vfio_platform_probe_of(struct vfio_platform_device *vdev,
+			   struct device *dev)
+{
+	int ret;
+
+	ret = device_property_read_string(dev, "compatible",
+					  &vdev->compat);
+	if (ret) {
+		pr_err("VFIO: cannot retrieve compat for %s\n",
+			vdev->name);
+		return -EINVAL;
+	}
+	return 0;
+}
+
 int vfio_platform_probe_common(struct vfio_platform_device *vdev,
 			       struct device *dev)
 {
@@ -550,14 +600,14 @@ int vfio_platform_probe_common(struct vfio_platform_device *vdev,
 	if (!vdev)
 		return -EINVAL;
 
-	ret = device_property_read_string(dev, "compatible", &vdev->compat);
-	if (ret) {
-		pr_err("VFIO: cannot retrieve compat for %s\n", vdev->name);
-		return -EINVAL;
-	}
+	ret = vfio_platform_probe_acpi(vdev, dev);
+	if (ret)
+		ret = vfio_platform_probe_of(vdev, dev);
 
-	vdev->device = dev;
+	if (ret)
+		return ret;
 
+	vdev->device = dev;
 	group = iommu_group_get(dev);
 	if (!group) {
 		pr_err("VFIO: No IOMMU group for device %s\n", vdev->name);
@@ -602,13 +652,21 @@ void __vfio_platform_register_reset(struct vfio_platform_reset_node *node)
 EXPORT_SYMBOL_GPL(__vfio_platform_register_reset);
 
 void vfio_platform_unregister_reset(const char *compat,
+				    const char *acpihid,
 				    vfio_platform_reset_fn_t fn)
 {
 	struct vfio_platform_reset_node *iter, *temp;
 
 	mutex_lock(&driver_lock);
 	list_for_each_entry_safe(iter, temp, &reset_list, link) {
-		if (!strcmp(iter->compat, compat) && (iter->reset == fn)) {
+		if (acpihid && iter->acpihid &&
+		    !strcmp(iter->acpihid, acpihid) && (iter->reset == fn)) {
+			list_del(&iter->link);
+			break;
+		}
+
+		if (compat && iter->compat &&
+		    !strcmp(iter->compat, compat) && (iter->reset == fn)) {
 			list_del(&iter->link);
 			break;
 		}
diff --git a/drivers/vfio/platform/vfio_platform_private.h b/drivers/vfio/platform/vfio_platform_private.h
index 42816dd..32feba3 100644
--- a/drivers/vfio/platform/vfio_platform_private.h
+++ b/drivers/vfio/platform/vfio_platform_private.h
@@ -58,6 +58,7 @@ struct vfio_platform_device {
 	struct mutex			igate;
 	struct module			*parent_module;
 	const char			*compat;
+	const char			*acpihid;
 	struct module			*reset_module;
 	struct device			*device;
 
@@ -79,6 +80,7 @@ typedef int (*vfio_platform_reset_fn_t)(struct vfio_platform_device *vdev);
 struct vfio_platform_reset_node {
 	struct list_head link;
 	char *compat;
+	char *acpihid;
 	struct module *owner;
 	vfio_platform_reset_fn_t reset;
 };
@@ -98,27 +100,30 @@ extern int vfio_platform_set_irqs_ioctl(struct vfio_platform_device *vdev,
 
 extern void __vfio_platform_register_reset(struct vfio_platform_reset_node *n);
 extern void vfio_platform_unregister_reset(const char *compat,
+					   const char *acpihid,
 					   vfio_platform_reset_fn_t fn);
-#define vfio_platform_register_reset(__compat, __reset)		\
-static struct vfio_platform_reset_node __reset ## _node = {	\
-	.owner = THIS_MODULE,					\
-	.compat = __compat,					\
-	.reset = __reset,					\
-};								\
+
+#define vfio_platform_register_reset(__compat, __acpihid, __reset)	\
+static struct vfio_platform_reset_node __reset ## _node = {		\
+	.owner = THIS_MODULE,						\
+	.compat = __compat,						\
+	.acpihid = __acpihid,						\
+	.reset = __reset,						\
+};									\
 __vfio_platform_register_reset(&__reset ## _node)
 
-#define module_vfio_reset_handler(compat, reset)		\
-MODULE_ALIAS("vfio-reset:" compat);				\
-static int __init reset ## _module_init(void)			\
-{								\
-	vfio_platform_register_reset(compat, reset);		\
-	return 0;						\
-};								\
-static void __exit reset ## _module_exit(void)			\
-{								\
-	vfio_platform_unregister_reset(compat, reset);		\
-};								\
-module_init(reset ## _module_init);				\
+#define module_vfio_reset_handler(compat, acpihid, reset)		\
+MODULE_ALIAS("vfio-reset:" compat);					\
+static int __init reset ## _module_init(void)				\
+{									\
+	vfio_platform_register_reset(compat, acpihid, reset);		\
+	return 0;							\
+};									\
+static void __exit reset ## _module_exit(void)				\
+{									\
+	vfio_platform_unregister_reset(compat, acpihid, reset);		\
+};									\
+module_init(reset ## _module_init);					\
 module_exit(reset ## _module_exit)
 
 #endif /* VFIO_PLATFORM_PRIVATE_H */
-- 
1.8.2.1



From okaya at codeaurora.org  Thu Feb  4 20:34:37 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Thu,  4 Feb 2016 23:34:37 -0500
Subject: [PATCH V14 6/9] dma: qcom_hidma: add debugfs hooks
In-Reply-To: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
References: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
Message-ID: <1454646882-24369-7-git-send-email-okaya@codeaurora.org>

Add debugfs hooks for debugging the execution behavior of the DMA
channel. The debugfs hooks get initialized by the probe function and
uninitialized by the remove function.

A stats file is created in debugfs. The stats file will show the
information about each HIDMA channel as well as each asynchronous job
queued and completed at a given time.

Signed-off-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/dma/qcom/Makefile    |   2 +-
 drivers/dma/qcom/hidma.c     |   3 +
 drivers/dma/qcom/hidma.h     |   2 +
 drivers/dma/qcom/hidma_dbg.c | 219 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 225 insertions(+), 1 deletion(-)
 create mode 100644 drivers/dma/qcom/hidma_dbg.c

diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 6bf9267..4bfc38b 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -2,4 +2,4 @@ obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
 obj-$(CONFIG_QCOM_HIDMA_MGMT) += hdma_mgmt.o
 hdma_mgmt-objs	 := hidma_mgmt.o hidma_mgmt_sys.o
 obj-$(CONFIG_QCOM_HIDMA) +=  hdma.o
-hdma-objs        := hidma_ll.o hidma.o
+hdma-objs        := hidma_ll.o hidma.o hidma_dbg.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 83006dd..c0832c7 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -644,6 +644,7 @@ static int hidma_probe(struct platform_device *pdev)
 
 	dmadev->irq = chirq;
 	tasklet_init(&dmadev->task, hidma_issue_task, (unsigned long)dmadev);
+	hidma_debug_init(dmadev);
 	dev_info(&pdev->dev, "HI-DMA engine driver registration complete\n");
 	platform_set_drvdata(pdev, dmadev);
 	pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -651,6 +652,7 @@ static int hidma_probe(struct platform_device *pdev)
 	return 0;
 
 uninit:
+	hidma_debug_uninit(dmadev);
 	hidma_ll_uninit(dmadev->lldev);
 dmafree:
 	if (dmadev)
@@ -668,6 +670,7 @@ static int hidma_remove(struct platform_device *pdev)
 	pm_runtime_get_sync(dmadev->ddev.dev);
 	dma_async_device_unregister(&dmadev->ddev);
 	devm_free_irq(dmadev->ddev.dev, dmadev->irq, dmadev->lldev);
+	hidma_debug_uninit(dmadev);
 	hidma_ll_uninit(dmadev->lldev);
 	hidma_free(dmadev);
 
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index 1e09d7c..c6b3ae0 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -157,4 +157,6 @@ int hidma_ll_uninit(struct hidma_lldev *llhndl);
 irqreturn_t hidma_ll_inthandler(int irq, void *arg);
 void hidma_cleanup_pending_tre(struct hidma_lldev *llhndl, u8 err_info,
 				u8 err_code);
+int hidma_debug_init(struct hidma_dev *dmadev);
+void hidma_debug_uninit(struct hidma_dev *dmadev);
 #endif
diff --git a/drivers/dma/qcom/hidma_dbg.c b/drivers/dma/qcom/hidma_dbg.c
new file mode 100644
index 0000000..fe35002
--- /dev/null
+++ b/drivers/dma/qcom/hidma_dbg.c
@@ -0,0 +1,219 @@
+/*
+ * Qualcomm Technologies HIDMA debug file
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/debugfs.h>
+#include <linux/device.h>
+#include <linux/list.h>
+#include <linux/pm_runtime.h>
+
+#include "hidma.h"
+
+static void hidma_ll_chstats(struct seq_file *s, void *llhndl, u32 tre_ch)
+{
+	struct hidma_lldev *lldev = llhndl;
+	struct hidma_tre *tre;
+	u32 length;
+	dma_addr_t src_start;
+	dma_addr_t dest_start;
+	u32 *tre_local;
+
+	if (tre_ch >= lldev->nr_tres) {
+		dev_err(lldev->dev, "invalid TRE number in chstats:%d", tre_ch);
+		return;
+	}
+	tre = &lldev->trepool[tre_ch];
+	seq_printf(s, "------Channel %d -----\n", tre_ch);
+	seq_printf(s, "allocated=%d\n", atomic_read(&tre->allocated));
+	seq_printf(s, "queued = 0x%x\n", tre->queued);
+	seq_printf(s, "err_info = 0x%x\n",
+		   lldev->tx_status_list[tre->idx].err_info);
+	seq_printf(s, "err_code = 0x%x\n",
+		   lldev->tx_status_list[tre->idx].err_code);
+	seq_printf(s, "status = 0x%x\n", tre->status);
+	seq_printf(s, "idx = 0x%x\n", tre->idx);
+	seq_printf(s, "dma_sig = 0x%x\n", tre->dma_sig);
+	seq_printf(s, "dev_name=%s\n", tre->dev_name);
+	seq_printf(s, "callback=%p\n", tre->callback);
+	seq_printf(s, "data=%p\n", tre->data);
+	seq_printf(s, "tre_index = 0x%x\n", tre->tre_index);
+
+	tre_local = &tre->tre_local[0];
+	src_start = tre_local[TRE_SRC_LOW_IDX];
+	src_start = ((u64) (tre_local[TRE_SRC_HI_IDX]) << 32) + src_start;
+	dest_start = tre_local[TRE_DEST_LOW_IDX];
+	dest_start += ((u64) (tre_local[TRE_DEST_HI_IDX]) << 32);
+	length = tre_local[TRE_LEN_IDX];
+
+	seq_printf(s, "src=%pap\n", &src_start);
+	seq_printf(s, "dest=%pap\n", &dest_start);
+	seq_printf(s, "length = 0x%x\n", length);
+}
+
+static void hidma_ll_devstats(struct seq_file *s, void *llhndl)
+{
+	struct hidma_lldev *lldev = llhndl;
+
+	seq_puts(s, "------Device -----\n");
+	seq_printf(s, "lldev init = 0x%x\n", lldev->initialized);
+	seq_printf(s, "trch_state = 0x%x\n", lldev->trch_state);
+	seq_printf(s, "evch_state = 0x%x\n", lldev->evch_state);
+	seq_printf(s, "chidx = 0x%x\n", lldev->chidx);
+	seq_printf(s, "nr_tres = 0x%x\n", lldev->nr_tres);
+	seq_printf(s, "trca=%p\n", lldev->trca);
+	seq_printf(s, "tre_ring=%p\n", lldev->tre_ring);
+	seq_printf(s, "tre_ring_handle=%pap\n", &lldev->tre_ring_handle);
+	seq_printf(s, "tre_ring_size = 0x%x\n", lldev->tre_ring_size);
+	seq_printf(s, "tre_processed_off = 0x%x\n", lldev->tre_processed_off);
+	seq_printf(s, "pending_tre_count=%d\n", lldev->pending_tre_count);
+	seq_printf(s, "evca=%p\n", lldev->evca);
+	seq_printf(s, "evre_ring=%p\n", lldev->evre_ring);
+	seq_printf(s, "evre_ring_handle=%pap\n", &lldev->evre_ring_handle);
+	seq_printf(s, "evre_ring_size = 0x%x\n", lldev->evre_ring_size);
+	seq_printf(s, "evre_processed_off = 0x%x\n", lldev->evre_processed_off);
+	seq_printf(s, "tre_write_offset = 0x%x\n", lldev->tre_write_offset);
+}
+
+/*
+ * hidma_chan_stats: display HIDMA channel statistics
+ *
+ * Display the statistics for the current HIDMA virtual channel device.
+ */
+static int hidma_chan_stats(struct seq_file *s, void *unused)
+{
+	struct hidma_chan *mchan = s->private;
+	struct hidma_desc *mdesc;
+	struct hidma_dev *dmadev = mchan->dmadev;
+
+	pm_runtime_get_sync(dmadev->ddev.dev);
+	seq_printf(s, "paused=%u\n", mchan->paused);
+	seq_printf(s, "dma_sig=%u\n", mchan->dma_sig);
+	seq_puts(s, "prepared\n");
+	list_for_each_entry(mdesc, &mchan->prepared, node)
+		hidma_ll_chstats(s, mchan->dmadev->lldev, mdesc->tre_ch);
+
+	seq_puts(s, "active\n");
+	list_for_each_entry(mdesc, &mchan->active, node)
+		hidma_ll_chstats(s, mchan->dmadev->lldev, mdesc->tre_ch);
+
+	seq_puts(s, "completed\n");
+	list_for_each_entry(mdesc, &mchan->completed, node)
+		hidma_ll_chstats(s, mchan->dmadev->lldev, mdesc->tre_ch);
+
+	hidma_ll_devstats(s, mchan->dmadev->lldev);
+	pm_runtime_mark_last_busy(dmadev->ddev.dev);
+	pm_runtime_put_autosuspend(dmadev->ddev.dev);
+	return 0;
+}
+
+/*
+ * hidma_dma_info: display HIDMA device info
+ *
+ * Display the info for the current HIDMA device.
+ */
+static int hidma_dma_info(struct seq_file *s, void *unused)
+{
+	struct hidma_dev *dmadev = s->private;
+	resource_size_t sz;
+
+	seq_printf(s, "nr_descriptors=%d\n", dmadev->nr_descriptors);
+	seq_printf(s, "dev_trca=%p\n", &dmadev->dev_trca);
+	seq_printf(s, "dev_trca_phys=%pa\n", &dmadev->trca_resource->start);
+	sz = resource_size(dmadev->trca_resource);
+	seq_printf(s, "dev_trca_size=%pa\n", &sz);
+	seq_printf(s, "dev_evca=%p\n", &dmadev->dev_evca);
+	seq_printf(s, "dev_evca_phys=%pa\n", &dmadev->evca_resource->start);
+	sz = resource_size(dmadev->evca_resource);
+	seq_printf(s, "dev_evca_size=%pa\n", &sz);
+	return 0;
+}
+
+static int hidma_chan_stats_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, hidma_chan_stats, inode->i_private);
+}
+
+static int hidma_dma_info_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, hidma_dma_info, inode->i_private);
+}
+
+static const struct file_operations hidma_chan_fops = {
+	.open = hidma_chan_stats_open,
+	.read = seq_read,
+	.llseek = seq_lseek,
+	.release = single_release,
+};
+
+static const struct file_operations hidma_dma_fops = {
+	.open = hidma_dma_info_open,
+	.read = seq_read,
+	.llseek = seq_lseek,
+	.release = single_release,
+};
+
+void hidma_debug_uninit(struct hidma_dev *dmadev)
+{
+	debugfs_remove_recursive(dmadev->debugfs);
+	debugfs_remove_recursive(dmadev->stats);
+}
+
+int hidma_debug_init(struct hidma_dev *dmadev)
+{
+	int rc = 0;
+	int chidx = 0;
+	struct list_head *position = NULL;
+
+	dmadev->debugfs = debugfs_create_dir(dev_name(dmadev->ddev.dev), NULL);
+	if (!dmadev->debugfs) {
+		rc = -ENODEV;
+		return rc;
+	}
+
+	/* walk through the virtual channel list */
+	list_for_each(position, &dmadev->ddev.channels) {
+		struct hidma_chan *chan;
+
+		chan = list_entry(position, struct hidma_chan,
+				  chan.device_node);
+		sprintf(chan->dbg_name, "chan%d", chidx);
+		chan->debugfs = debugfs_create_dir(chan->dbg_name,
+						   dmadev->debugfs);
+		if (!chan->debugfs) {
+			rc = -ENOMEM;
+			goto cleanup;
+		}
+		chan->stats = debugfs_create_file("stats", S_IRUGO,
+						  chan->debugfs, chan,
+						  &hidma_chan_fops);
+		if (!chan->stats) {
+			rc = -ENOMEM;
+			goto cleanup;
+		}
+		chidx++;
+	}
+
+	dmadev->stats = debugfs_create_file("stats", S_IRUGO,
+					    dmadev->debugfs, dmadev,
+					    &hidma_dma_fops);
+	if (!dmadev->stats) {
+		rc = -ENOMEM;
+		goto cleanup;
+	}
+
+	return 0;
+cleanup:
+	hidma_debug_uninit(dmadev);
+	return rc;
+}
-- 
1.8.2.1



From okaya at codeaurora.org  Thu Feb  4 20:34:36 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Thu,  4 Feb 2016 23:34:36 -0500
Subject: [PATCH V14 5/9] dma: qcom_hidma: implement lower level hardware
 interface
In-Reply-To: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
References: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
Message-ID: <1454646882-24369-6-git-send-email-okaya@codeaurora.org>

This patch implements the hardware hooks for the HIDMA channel driver.

The main functions of interest are:
- hidma_ll_init
- hidma_ll_request
- hidma_ll_queue_request
- hidma_ll_hw_start

OS layer calls the hidma_ll_init function during probe to set up the
hardware. At this moment, the number of supported descriptors are also
given. On each request, a descriptor is allocated from the free pool and
filled in with the transfer parameters. Multiple requests can be queued
into the hardware via the OS interface. When client is ready for requests
to be executed, start method is called.

Completions are delivered via callbacks via tasklet.

Signed-off-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/dma/qcom/Makefile   |   2 +
 drivers/dma/qcom/hidma.h    |   2 +-
 drivers/dma/qcom/hidma_ll.c | 927 ++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 930 insertions(+), 1 deletion(-)
 create mode 100644 drivers/dma/qcom/hidma_ll.c

diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index bfea699..6bf9267 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,3 +1,5 @@
 obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
 obj-$(CONFIG_QCOM_HIDMA_MGMT) += hdma_mgmt.o
 hdma_mgmt-objs	 := hidma_mgmt.o hidma_mgmt_sys.o
+obj-$(CONFIG_QCOM_HIDMA) +=  hdma.o
+hdma-objs        := hidma_ll.o hidma.o
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index 231e306..1e09d7c 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -37,7 +37,7 @@ struct hidma_tre {
 	atomic_t allocated;		/* if this channel is allocated	    */
 	bool queued;			/* flag whether this is pending     */
 	u16 status;			/* status			    */
-	u32 chidx;			/* index of the tre		    */
+	u32 idx;			/* index of the tre		    */
 	u32 dma_sig;			/* signature of the tre		    */
 	const char *dev_name;		/* name of the device		    */
 	void (*callback)(void *data);	/* requester callback		    */
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
new file mode 100644
index 0000000..c343bf7
--- /dev/null
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -0,0 +1,927 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine low level code
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/dmaengine.h>
+#include <linux/slab.h>
+#include <linux/interrupt.h>
+#include <linux/mm.h>
+#include <linux/highmem.h>
+#include <linux/dma-mapping.h>
+#include <linux/delay.h>
+#include <linux/atomic.h>
+#include <linux/iopoll.h>
+#include <linux/kfifo.h>
+#include <linux/bitops.h>
+
+#include "hidma.h"
+
+#define EVRE_SIZE			16	/* each EVRE is 16 bytes */
+
+#define TRCA_CTRLSTS_OFFSET		0x000
+#define TRCA_RING_LOW_OFFSET		0x008
+#define TRCA_RING_HIGH_OFFSET		0x00C
+#define TRCA_RING_LEN_OFFSET		0x010
+#define TRCA_READ_PTR_OFFSET		0x018
+#define TRCA_WRITE_PTR_OFFSET		0x020
+#define TRCA_DOORBELL_OFFSET		0x400
+
+#define EVCA_CTRLSTS_OFFSET		0x000
+#define EVCA_INTCTRL_OFFSET		0x004
+#define EVCA_RING_LOW_OFFSET		0x008
+#define EVCA_RING_HIGH_OFFSET		0x00C
+#define EVCA_RING_LEN_OFFSET		0x010
+#define EVCA_READ_PTR_OFFSET		0x018
+#define EVCA_WRITE_PTR_OFFSET		0x020
+#define EVCA_DOORBELL_OFFSET		0x400
+
+#define EVCA_IRQ_STAT_OFFSET		0x100
+#define EVCA_IRQ_CLR_OFFSET		0x108
+#define EVCA_IRQ_EN_OFFSET		0x110
+
+#define EVRE_CFG_IDX			0
+#define EVRE_LEN_IDX			1
+#define EVRE_DEST_LOW_IDX		2
+#define EVRE_DEST_HI_IDX		3
+
+#define EVRE_ERRINFO_BIT_POS		24
+#define EVRE_CODE_BIT_POS		28
+
+#define EVRE_ERRINFO_MASK		GENMASK(3, 0)
+#define EVRE_CODE_MASK			GENMASK(3, 0)
+
+#define CH_CONTROL_MASK		GENMASK(7, 0)
+#define CH_STATE_MASK			GENMASK(7, 0)
+#define CH_STATE_BIT_POS		0x8
+
+#define IRQ_EV_CH_EOB_IRQ_BIT_POS	0
+#define IRQ_EV_CH_WR_RESP_BIT_POS	1
+#define IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS 9
+#define IRQ_TR_CH_DATA_RD_ER_BIT_POS	10
+#define IRQ_TR_CH_DATA_WR_ER_BIT_POS	11
+#define IRQ_TR_CH_INVALID_TRE_BIT_POS	14
+
+#define	ENABLE_IRQS (BIT(IRQ_EV_CH_EOB_IRQ_BIT_POS)	| \
+		BIT(IRQ_EV_CH_WR_RESP_BIT_POS)		| \
+		BIT(IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS)	| \
+		BIT(IRQ_TR_CH_DATA_RD_ER_BIT_POS)	| \
+		BIT(IRQ_TR_CH_DATA_WR_ER_BIT_POS)	| \
+		BIT(IRQ_TR_CH_INVALID_TRE_BIT_POS))
+
+#define HIDMA_INCREMENT_ITERATOR(iter, size, ring_size)	\
+do {								\
+	iter += size;						\
+	if (iter >= ring_size)					\
+		iter -= ring_size;				\
+} while (0)
+
+#define HIDMA_CH_STATE(val)	\
+	((val >> CH_STATE_BIT_POS) & CH_STATE_MASK)
+
+enum ch_command {
+	CH_DISABLE = 0,
+	CH_ENABLE = 1,
+	CH_SUSPEND = 2,
+	CH_RESET = 9,
+};
+
+enum ch_state {
+	CH_DISABLED = 0,
+	CH_ENABLED = 1,
+	CH_RUNNING = 2,
+	CH_SUSPENDED = 3,
+	CH_STOPPED = 4,
+	CH_ERROR = 5,
+	CH_IN_RESET = 9,
+};
+
+enum tre_type {
+	TRE_MEMCPY = 3,
+	TRE_MEMSET = 4,
+};
+
+enum evre_type {
+	EVRE_DMA_COMPLETE = 0x23,
+	EVRE_IMM_DATA = 0x24,
+};
+
+enum err_code {
+	EVRE_STATUS_COMPLETE = 1,
+	EVRE_STATUS_ERROR = 4,
+};
+
+void hidma_ll_free(struct hidma_lldev *lldev, u32 tre_ch)
+{
+	struct hidma_tre *tre;
+
+	if (tre_ch >= lldev->nr_tres) {
+		dev_err(lldev->dev, "invalid TRE number in free:%d", tre_ch);
+		return;
+	}
+
+	tre = &lldev->trepool[tre_ch];
+	if (atomic_read(&tre->allocated) != true) {
+		dev_err(lldev->dev, "trying to free an unused TRE:%d", tre_ch);
+		return;
+	}
+
+	atomic_set(&tre->allocated, 0);
+}
+
+int hidma_ll_request(struct hidma_lldev *lldev, u32 dma_sig,
+		     const char *dev_name,
+		     void (*callback)(void *data), void *data, u32 *tre_ch)
+{
+	unsigned int i;
+	struct hidma_tre *tre;
+	u32 *tre_local;
+
+	if (!tre_ch || !lldev)
+		return -EINVAL;
+
+	/* need to have at least one empty spot in the queue */
+	for (i = 0; i < lldev->nr_tres - 1; i++) {
+		if (atomic_add_unless(&lldev->trepool[i].allocated, 1, 1))
+			break;
+	}
+
+	if (i == (lldev->nr_tres - 1))
+		return -ENOMEM;
+
+	tre = &lldev->trepool[i];
+	tre->dma_sig = dma_sig;
+	tre->dev_name = dev_name;
+	tre->callback = callback;
+	tre->data = data;
+	tre->idx = i;
+	tre->status = 0;
+	tre->queued = 0;
+	lldev->tx_status_list[i].err_code = 0;
+	tre->lldev = lldev;
+	tre_local = &tre->tre_local[0];
+	tre_local[TRE_CFG_IDX] = TRE_MEMCPY;
+	tre_local[TRE_CFG_IDX] |= (lldev->chidx & 0xFF) << 8;
+	tre_local[TRE_CFG_IDX] |= BIT(16);	/* set IEOB */
+	*tre_ch = i;
+	if (callback)
+		callback(data);
+	return 0;
+}
+
+/*
+ * Multiple TREs may be queued and waiting in the
+ * pending queue.
+ */
+static void hidma_ll_tre_complete(unsigned long arg)
+{
+	struct hidma_lldev *lldev = (struct hidma_lldev *)arg;
+	struct hidma_tre *tre;
+
+	while (kfifo_out(&lldev->handoff_fifo, &tre, 1)) {
+		/* call the user if it has been read by the hardware */
+		if (tre->callback)
+			tre->callback(tre->data);
+	}
+}
+
+/*
+ * Called to handle the interrupt for the channel.
+ * Return a positive number if TRE or EVRE were consumed on this run.
+ * Return a positive number if there are pending TREs or EVREs.
+ * Return 0 if there is nothing to consume or no pending TREs/EVREs found.
+ */
+static int hidma_handle_tre_completion(struct hidma_lldev *lldev)
+{
+	struct hidma_tre *tre;
+	u32 evre_write_off;
+	u32 evre_ring_size = lldev->evre_ring_size;
+	u32 tre_ring_size = lldev->tre_ring_size;
+	u32 num_completed = 0, tre_iterator, evre_iterator;
+	unsigned long flags;
+
+	evre_write_off = readl_relaxed(lldev->evca + EVCA_WRITE_PTR_OFFSET);
+	tre_iterator = lldev->tre_processed_off;
+	evre_iterator = lldev->evre_processed_off;
+
+	if ((evre_write_off > evre_ring_size) ||
+	    ((evre_write_off % EVRE_SIZE) != 0)) {
+		dev_err(lldev->dev, "HW reports invalid EVRE write offset\n");
+		return 0;
+	}
+
+	/*
+	 * By the time control reaches here the number of EVREs and TREs
+	 * may not match. Only consume the ones that hardware told us.
+	 */
+	while ((evre_iterator != evre_write_off)) {
+		u32 *current_evre = lldev->evre_ring + evre_iterator;
+		u32 cfg;
+		u8 err_info;
+
+		spin_lock_irqsave(&lldev->lock, flags);
+		tre = lldev->pending_tre_list[tre_iterator / TRE_SIZE];
+		if (!tre) {
+			spin_unlock_irqrestore(&lldev->lock, flags);
+			dev_warn(lldev->dev,
+				 "tre_index [%d] and tre out of sync\n",
+				 tre_iterator / TRE_SIZE);
+			HIDMA_INCREMENT_ITERATOR(tre_iterator, TRE_SIZE,
+						 tre_ring_size);
+			HIDMA_INCREMENT_ITERATOR(evre_iterator, EVRE_SIZE,
+						 evre_ring_size);
+			continue;
+		}
+		lldev->pending_tre_list[tre->tre_index] = NULL;
+
+		/*
+		 * Keep track of pending TREs that SW is expecting to receive
+		 * from HW. We got one now. Decrement our counter.
+		 */
+		lldev->pending_tre_count--;
+		if (lldev->pending_tre_count < 0) {
+			dev_warn(lldev->dev,
+				 "tre count mismatch on completion");
+			lldev->pending_tre_count = 0;
+		}
+
+		spin_unlock_irqrestore(&lldev->lock, flags);
+
+		cfg = current_evre[EVRE_CFG_IDX];
+		err_info = cfg >> EVRE_ERRINFO_BIT_POS;
+		err_info &= EVRE_ERRINFO_MASK;
+		lldev->tx_status_list[tre->idx].err_info = err_info;
+		lldev->tx_status_list[tre->idx].err_code =
+		    (cfg >> EVRE_CODE_BIT_POS) & EVRE_CODE_MASK;
+		tre->queued = 0;
+
+		kfifo_put(&lldev->handoff_fifo, tre);
+		tasklet_schedule(&lldev->task);
+
+		HIDMA_INCREMENT_ITERATOR(tre_iterator, TRE_SIZE,
+					 tre_ring_size);
+		HIDMA_INCREMENT_ITERATOR(evre_iterator, EVRE_SIZE,
+					 evre_ring_size);
+
+		/*
+		 * Read the new event descriptor written by the HW.
+		 * As we are processing the delivered events, other events
+		 * get queued to the SW for processing.
+		 */
+		evre_write_off =
+		    readl_relaxed(lldev->evca + EVCA_WRITE_PTR_OFFSET);
+		num_completed++;
+	}
+
+	if (num_completed) {
+		u32 evre_read_off = (lldev->evre_processed_off +
+				     EVRE_SIZE * num_completed);
+		u32 tre_read_off = (lldev->tre_processed_off +
+				    TRE_SIZE * num_completed);
+
+		evre_read_off = evre_read_off % evre_ring_size;
+		tre_read_off = tre_read_off % tre_ring_size;
+
+		writel(evre_read_off, lldev->evca + EVCA_DOORBELL_OFFSET);
+
+		/* record the last processed tre offset */
+		lldev->tre_processed_off = tre_read_off;
+		lldev->evre_processed_off = evre_read_off;
+	}
+
+	return num_completed;
+}
+
+void hidma_cleanup_pending_tre(struct hidma_lldev *lldev, u8 err_info,
+			       u8 err_code)
+{
+	u32 tre_iterator;
+	struct hidma_tre *tre;
+	u32 tre_ring_size = lldev->tre_ring_size;
+	int num_completed = 0;
+	u32 tre_read_off;
+	unsigned long flags;
+
+	tre_iterator = lldev->tre_processed_off;
+	while (lldev->pending_tre_count) {
+		int tre_index = tre_iterator / TRE_SIZE;
+
+		spin_lock_irqsave(&lldev->lock, flags);
+		tre = lldev->pending_tre_list[tre_index];
+		if (!tre) {
+			spin_unlock_irqrestore(&lldev->lock, flags);
+			HIDMA_INCREMENT_ITERATOR(tre_iterator, TRE_SIZE,
+						 tre_ring_size);
+			continue;
+		}
+		lldev->pending_tre_list[tre_index] = NULL;
+		lldev->pending_tre_count--;
+		if (lldev->pending_tre_count < 0) {
+			dev_warn(lldev->dev,
+				 "tre count mismatch on completion");
+			lldev->pending_tre_count = 0;
+		}
+		spin_unlock_irqrestore(&lldev->lock, flags);
+
+		lldev->tx_status_list[tre->idx].err_info = err_info;
+		lldev->tx_status_list[tre->idx].err_code = err_code;
+		tre->queued = 0;
+
+		kfifo_put(&lldev->handoff_fifo, tre);
+		tasklet_schedule(&lldev->task);
+
+		HIDMA_INCREMENT_ITERATOR(tre_iterator, TRE_SIZE,
+					 tre_ring_size);
+		num_completed++;
+	}
+	tre_read_off = (lldev->tre_processed_off + TRE_SIZE * num_completed);
+
+	tre_read_off = tre_read_off % tre_ring_size;
+
+	/* record the last processed tre offset */
+	lldev->tre_processed_off = tre_read_off;
+}
+
+static int hidma_ll_reset(struct hidma_lldev *lldev)
+{
+	u32 val;
+	int ret;
+
+	val = readl(lldev->trca + TRCA_CTRLSTS_OFFSET);
+	val &= ~(CH_CONTROL_MASK << 16);
+	val |= CH_RESET << 16;
+	writel(val, lldev->trca + TRCA_CTRLSTS_OFFSET);
+
+	/*
+	 * Delay 10ms after reset to allow DMA logic to quiesce.
+	 * Do a polled read up to 1ms and 10ms maximum.
+	 */
+	ret = readl_poll_timeout(lldev->trca + TRCA_CTRLSTS_OFFSET, val,
+				 HIDMA_CH_STATE(val) == CH_DISABLED, 1000,
+				 10000);
+	if (ret) {
+		dev_err(lldev->dev, "transfer channel did not reset\n");
+		return ret;
+	}
+
+	val = readl(lldev->evca + EVCA_CTRLSTS_OFFSET);
+	val &= ~(CH_CONTROL_MASK << 16);
+	val |= CH_RESET << 16;
+	writel(val, lldev->evca + EVCA_CTRLSTS_OFFSET);
+
+	/*
+	 * Delay 10ms after reset to allow DMA logic to quiesce.
+	 * Do a polled read up to 1ms and 10ms maximum.
+	 */
+	ret = readl_poll_timeout(lldev->evca + EVCA_CTRLSTS_OFFSET, val,
+				 HIDMA_CH_STATE(val) == CH_DISABLED, 1000,
+				 10000);
+	if (ret)
+		return ret;
+
+	lldev->trch_state = CH_DISABLED;
+	lldev->evch_state = CH_DISABLED;
+	return 0;
+}
+
+static void hidma_ll_enable_irq(struct hidma_lldev *lldev, u32 irq_bits)
+{
+	writel(irq_bits, lldev->evca + EVCA_IRQ_EN_OFFSET);
+}
+
+/*
+ * The interrupt handler for HIDMA will try to consume as many pending
+ * EVRE from the event queue as possible. Each EVRE has an associated
+ * TRE that holds the user interface parameters. EVRE reports the
+ * result of the transaction. Hardware guarantees ordering between EVREs
+ * and TREs. We use last processed offset to figure out which TRE is
+ * associated with which EVRE. If two TREs are consumed by HW, the EVREs
+ * are in order in the event ring.
+ *
+ * This handler will do a one pass for consuming EVREs. Other EVREs may
+ * be delivered while we are working. It will try to consume incoming
+ * EVREs one more time and return.
+ *
+ * For unprocessed EVREs, hardware will trigger another interrupt until
+ * all the interrupt bits are cleared.
+ *
+ * Hardware guarantees that by the time interrupt is observed, all data
+ * transactions in flight are delivered to their respective places and
+ * are visible to the CPU.
+ *
+ * On demand paging for IOMMU is only supported for PCIe via PRI
+ * (Page Request Interface) not for HIDMA. All other hardware instances
+ * including HIDMA work on pinned DMA addresses.
+ *
+ * HIDMA is not aware of IOMMU presence since it follows the DMA API. All
+ * IOMMU latency will be built into the data movement time. By the time
+ * interrupt happens, IOMMU lookups + data movement has already taken place.
+ *
+ * While the first read in a typical PCI endpoint ISR flushes all outstanding
+ * requests traditionally to the destination, this concept does not apply
+ * here for this HW.
+ */
+static void hidma_ll_int_handler_internal(struct hidma_lldev *lldev)
+{
+	u32 status;
+	u32 enable;
+	u32 cause;
+	int repeat = 2;
+	unsigned long timeout;
+
+	/*
+	 * Fine tuned for this HW...
+	 *
+	 * This ISR has been designed for this particular hardware. Relaxed
+	 * read and write accessors are used for performance reasons due to
+	 * interrupt delivery guarantees. Do not copy this code blindly and
+	 * expect that to work.
+	 */
+	status = readl_relaxed(lldev->evca + EVCA_IRQ_STAT_OFFSET);
+	enable = readl_relaxed(lldev->evca + EVCA_IRQ_EN_OFFSET);
+	cause = status & enable;
+
+	if ((cause & (BIT(IRQ_TR_CH_INVALID_TRE_BIT_POS))) ||
+	    (cause & BIT(IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS)) ||
+	    (cause & BIT(IRQ_EV_CH_WR_RESP_BIT_POS)) ||
+	    (cause & BIT(IRQ_TR_CH_DATA_RD_ER_BIT_POS)) ||
+	    (cause & BIT(IRQ_TR_CH_DATA_WR_ER_BIT_POS))) {
+		u8 err_code = EVRE_STATUS_ERROR;
+		u8 err_info = 0xFF;
+
+		/* Clear out pending interrupts */
+		writel(cause, lldev->evca + EVCA_IRQ_CLR_OFFSET);
+
+		dev_err(lldev->dev, "error 0x%x, resetting...\n", cause);
+
+		hidma_cleanup_pending_tre(lldev, err_info, err_code);
+
+		/* reset the channel for recovery */
+		if (hidma_ll_setup(lldev)) {
+			dev_err(lldev->dev,
+				"channel reinitialize failed after error\n");
+			return;
+		}
+		hidma_ll_enable_irq(lldev, ENABLE_IRQS);
+		return;
+	}
+
+	/*
+	 * Try to consume as many EVREs as possible.
+	 * skip this loop if the interrupt is spurious.
+	 */
+	while (cause && repeat) {
+		unsigned long start = jiffies;
+
+		/* This timeout should be sufficent for core to finish */
+		timeout = start + msecs_to_jiffies(500);
+
+		while (lldev->pending_tre_count) {
+			hidma_handle_tre_completion(lldev);
+			if (time_is_before_jiffies(timeout)) {
+				dev_warn(lldev->dev,
+					 "ISR timeout %lx-%lx from %lx [%d]\n",
+					 jiffies, timeout, start,
+					 lldev->pending_tre_count);
+				break;
+			}
+		}
+
+		/* We consumed TREs or there are pending TREs or EVREs. */
+		writel_relaxed(cause, lldev->evca + EVCA_IRQ_CLR_OFFSET);
+
+		/*
+		 * Another interrupt might have arrived while we are
+		 * processing this one. Read the new cause.
+		 */
+		status = readl_relaxed(lldev->evca + EVCA_IRQ_STAT_OFFSET);
+		enable = readl_relaxed(lldev->evca + EVCA_IRQ_EN_OFFSET);
+		cause = status & enable;
+
+		repeat--;
+	}
+}
+
+static int hidma_ll_enable(struct hidma_lldev *lldev)
+{
+	u32 val;
+	int ret;
+
+	val = readl(lldev->evca + EVCA_CTRLSTS_OFFSET);
+	val &= ~(CH_CONTROL_MASK << 16);
+	val |= CH_ENABLE << 16;
+	writel(val, lldev->evca + EVCA_CTRLSTS_OFFSET);
+
+	ret = readl_poll_timeout(lldev->evca + EVCA_CTRLSTS_OFFSET, val,
+				 (HIDMA_CH_STATE(val) == CH_ENABLED) ||
+				 (HIDMA_CH_STATE(val) == CH_RUNNING), 1000,
+				 10000);
+	if (ret) {
+		dev_err(lldev->dev, "event channel did not get enabled\n");
+		return ret;
+	}
+
+	val = readl(lldev->trca + TRCA_CTRLSTS_OFFSET);
+	val &= ~(CH_CONTROL_MASK << 16);
+	val |= CH_ENABLE << 16;
+	writel(val, lldev->trca + TRCA_CTRLSTS_OFFSET);
+
+	ret = readl_poll_timeout(lldev->trca + TRCA_CTRLSTS_OFFSET, val,
+				 (HIDMA_CH_STATE(val) == CH_ENABLED) ||
+				 (HIDMA_CH_STATE(val) == CH_RUNNING), 1000,
+				 10000);
+	if (ret) {
+		dev_err(lldev->dev, "transfer channel did not get enabled\n");
+		return ret;
+	}
+
+	lldev->trch_state = CH_ENABLED;
+	lldev->evch_state = CH_ENABLED;
+
+	return 0;
+}
+
+int hidma_ll_resume(struct hidma_lldev *lldev)
+{
+	return hidma_ll_enable(lldev);
+}
+
+static void hidma_ll_hw_start(struct hidma_lldev *lldev)
+{
+	unsigned long irqflags;
+
+	spin_lock_irqsave(&lldev->lock, irqflags);
+	writel(lldev->tre_write_offset, lldev->trca + TRCA_DOORBELL_OFFSET);
+	spin_unlock_irqrestore(&lldev->lock, irqflags);
+}
+
+bool hidma_ll_isenabled(struct hidma_lldev *lldev)
+{
+	u32 val;
+
+	val = readl(lldev->trca + TRCA_CTRLSTS_OFFSET);
+	lldev->trch_state = HIDMA_CH_STATE(val);
+	val = readl(lldev->evca + EVCA_CTRLSTS_OFFSET);
+	lldev->evch_state = HIDMA_CH_STATE(val);
+
+	/* both channels have to be enabled before calling this function */
+	if (((lldev->trch_state == CH_ENABLED) ||
+	     (lldev->trch_state == CH_RUNNING)) &&
+	    ((lldev->evch_state == CH_ENABLED) ||
+	     (lldev->evch_state == CH_RUNNING)))
+		return true;
+
+	return false;
+}
+
+void hidma_ll_queue_request(struct hidma_lldev *lldev, u32 tre_ch)
+{
+	struct hidma_tre *tre;
+	unsigned long flags;
+
+	tre = &lldev->trepool[tre_ch];
+
+	/* copy the TRE into its location in the TRE ring */
+	spin_lock_irqsave(&lldev->lock, flags);
+	tre->tre_index = lldev->tre_write_offset / TRE_SIZE;
+	lldev->pending_tre_list[tre->tre_index] = tre;
+	memcpy(lldev->tre_ring + lldev->tre_write_offset, &tre->tre_local[0],
+	       TRE_SIZE);
+	lldev->tx_status_list[tre->idx].err_code = 0;
+	lldev->tx_status_list[tre->idx].err_info = 0;
+	tre->queued = 1;
+	lldev->pending_tre_count++;
+	lldev->tre_write_offset = (lldev->tre_write_offset + TRE_SIZE)
+	    % lldev->tre_ring_size;
+	spin_unlock_irqrestore(&lldev->lock, flags);
+}
+
+void hidma_ll_start(struct hidma_lldev *lldev)
+{
+	hidma_ll_hw_start(lldev);
+}
+
+/*
+ * Note that even though we stop this channel
+ * if there is a pending transaction in flight
+ * it will complete and follow the callback.
+ * This request will prevent further requests
+ * to be made.
+ */
+int hidma_ll_pause(struct hidma_lldev *lldev)
+{
+	u32 val;
+	int ret;
+
+	val = readl(lldev->evca + EVCA_CTRLSTS_OFFSET);
+	lldev->evch_state = HIDMA_CH_STATE(val);
+	val = readl(lldev->trca + TRCA_CTRLSTS_OFFSET);
+	lldev->trch_state = HIDMA_CH_STATE(val);
+
+	/* already suspended by this OS */
+	if ((lldev->trch_state == CH_SUSPENDED) ||
+	    (lldev->evch_state == CH_SUSPENDED))
+		return 0;
+
+	/* already stopped by the manager */
+	if ((lldev->trch_state == CH_STOPPED) ||
+	    (lldev->evch_state == CH_STOPPED))
+		return 0;
+
+	val = readl(lldev->trca + TRCA_CTRLSTS_OFFSET);
+	val &= ~(CH_CONTROL_MASK << 16);
+	val |= CH_SUSPEND << 16;
+	writel(val, lldev->trca + TRCA_CTRLSTS_OFFSET);
+
+	/*
+	 * Start the wait right after the suspend is confirmed.
+	 * Do a polled read up to 1ms and 10ms maximum.
+	 */
+	ret = readl_poll_timeout(lldev->trca + TRCA_CTRLSTS_OFFSET, val,
+				 HIDMA_CH_STATE(val) == CH_SUSPENDED, 1000,
+				 10000);
+	if (ret)
+		return ret;
+
+	val = readl(lldev->evca + EVCA_CTRLSTS_OFFSET);
+	val &= ~(CH_CONTROL_MASK << 16);
+	val |= CH_SUSPEND << 16;
+	writel(val, lldev->evca + EVCA_CTRLSTS_OFFSET);
+
+	/*
+	 * Start the wait right after the suspend is confirmed
+	 * Delay up to 10ms after reset to allow DMA logic to quiesce.
+	 */
+	ret = readl_poll_timeout(lldev->evca + EVCA_CTRLSTS_OFFSET, val,
+				 HIDMA_CH_STATE(val) == CH_SUSPENDED, 1000,
+				 10000);
+	if (ret)
+		return ret;
+
+	lldev->trch_state = CH_SUSPENDED;
+	lldev->evch_state = CH_SUSPENDED;
+	return 0;
+}
+
+void hidma_ll_set_transfer_params(struct hidma_lldev *lldev, u32 tre_ch,
+				  dma_addr_t src, dma_addr_t dest, u32 len,
+				  u32 flags)
+{
+	struct hidma_tre *tre;
+	u32 *tre_local;
+
+	if (tre_ch >= lldev->nr_tres) {
+		dev_err(lldev->dev,
+			"invalid TRE number in transfer params:%d", tre_ch);
+		return;
+	}
+
+	tre = &lldev->trepool[tre_ch];
+	if (atomic_read(&tre->allocated) != true) {
+		dev_err(lldev->dev,
+			"trying to set params on an unused TRE:%d", tre_ch);
+		return;
+	}
+
+	tre_local = &tre->tre_local[0];
+	tre_local[TRE_LEN_IDX] = len;
+	tre_local[TRE_SRC_LOW_IDX] = lower_32_bits(src);
+	tre_local[TRE_SRC_HI_IDX] = upper_32_bits(src);
+	tre_local[TRE_DEST_LOW_IDX] = lower_32_bits(dest);
+	tre_local[TRE_DEST_HI_IDX] = upper_32_bits(dest);
+	tre->int_flags = flags;
+}
+
+/*
+ * Called during initialization and after an error condition
+ * to restore hardware state.
+ */
+int hidma_ll_setup(struct hidma_lldev *lldev)
+{
+	int rc;
+	u64 addr;
+	u32 val;
+	u32 nr_tres = lldev->nr_tres;
+
+	lldev->pending_tre_count = 0;
+	lldev->tre_processed_off = 0;
+	lldev->evre_processed_off = 0;
+	lldev->tre_write_offset = 0;
+
+	/* disable interrupts */
+	hidma_ll_enable_irq(lldev, 0);
+
+	/* clear all pending interrupts */
+	val = readl(lldev->evca + EVCA_IRQ_STAT_OFFSET);
+	writel(val, lldev->evca + EVCA_IRQ_CLR_OFFSET);
+
+	rc = hidma_ll_reset(lldev);
+	if (rc)
+		return rc;
+
+	/*
+	 * Clear all pending interrupts again.
+	 * Otherwise, we observe reset complete interrupts.
+	 */
+	val = readl(lldev->evca + EVCA_IRQ_STAT_OFFSET);
+	writel(val, lldev->evca + EVCA_IRQ_CLR_OFFSET);
+
+	/* disable interrupts again after reset */
+	hidma_ll_enable_irq(lldev, 0);
+
+	addr = lldev->tre_ring_handle;
+	writel(lower_32_bits(addr), lldev->trca + TRCA_RING_LOW_OFFSET);
+	writel(upper_32_bits(addr), lldev->trca + TRCA_RING_HIGH_OFFSET);
+	writel(lldev->tre_ring_size, lldev->trca + TRCA_RING_LEN_OFFSET);
+
+	addr = lldev->evre_ring_handle;
+	writel(lower_32_bits(addr), lldev->evca + EVCA_RING_LOW_OFFSET);
+	writel(upper_32_bits(addr), lldev->evca + EVCA_RING_HIGH_OFFSET);
+	writel(EVRE_SIZE * nr_tres, lldev->evca + EVCA_RING_LEN_OFFSET);
+
+	/* support IRQ only for now */
+	val = readl(lldev->evca + EVCA_INTCTRL_OFFSET);
+	val &= ~0xF;
+	val |= 0x1;
+	writel(val, lldev->evca + EVCA_INTCTRL_OFFSET);
+
+	/* clear all pending interrupts and enable them */
+	writel(ENABLE_IRQS, lldev->evca + EVCA_IRQ_CLR_OFFSET);
+	hidma_ll_enable_irq(lldev, ENABLE_IRQS);
+
+	rc = hidma_ll_enable(lldev);
+	if (rc)
+		return rc;
+
+	return rc;
+}
+
+struct hidma_lldev *hidma_ll_init(struct device *dev, u32 nr_tres,
+				  void __iomem *trca, void __iomem *evca,
+				  u8 chidx)
+{
+	u32 required_bytes;
+	struct hidma_lldev *lldev;
+	int rc;
+
+	if (!trca || !evca || !dev || !nr_tres)
+		return NULL;
+
+	/* need at least four TREs */
+	if (nr_tres < 4)
+		return NULL;
+
+	/* need an extra space */
+	nr_tres += 1;
+
+	lldev = devm_kzalloc(dev, sizeof(struct hidma_lldev), GFP_KERNEL);
+	if (!lldev)
+		return NULL;
+
+	lldev->evca = evca;
+	lldev->trca = trca;
+	lldev->dev = dev;
+	lldev->trepool = devm_kcalloc(lldev->dev, nr_tres,
+				      sizeof(struct hidma_tre), GFP_KERNEL);
+	if (!lldev->trepool)
+		return NULL;
+
+	required_bytes = sizeof(lldev->pending_tre_list[0]);
+	lldev->pending_tre_list = devm_kcalloc(dev, nr_tres, required_bytes,
+					       GFP_KERNEL);
+	if (!lldev->pending_tre_list)
+		return NULL;
+
+	lldev->tx_status_list = devm_kcalloc(dev, nr_tres,
+					     sizeof(lldev->tx_status_list[0]),
+					     GFP_KERNEL);
+	if (!lldev->tx_status_list)
+		return NULL;
+
+	lldev->tre_ring = dmam_alloc_coherent(dev, (TRE_SIZE + 1) * nr_tres,
+					      &lldev->tre_ring_handle,
+					      GFP_KERNEL);
+	if (!lldev->tre_ring)
+		return NULL;
+
+	memset(lldev->tre_ring, 0, (TRE_SIZE + 1) * nr_tres);
+	lldev->tre_ring_size = TRE_SIZE * nr_tres;
+	lldev->nr_tres = nr_tres;
+
+	/* the TRE ring has to be TRE_SIZE aligned */
+	if (!IS_ALIGNED(lldev->tre_ring_handle, TRE_SIZE)) {
+		u8 tre_ring_shift;
+
+		tre_ring_shift = lldev->tre_ring_handle % TRE_SIZE;
+		tre_ring_shift = TRE_SIZE - tre_ring_shift;
+		lldev->tre_ring_handle += tre_ring_shift;
+		lldev->tre_ring += tre_ring_shift;
+	}
+
+	lldev->evre_ring = dmam_alloc_coherent(dev, (EVRE_SIZE + 1) * nr_tres,
+					       &lldev->evre_ring_handle,
+					       GFP_KERNEL);
+	if (!lldev->evre_ring)
+		return NULL;
+
+	memset(lldev->evre_ring, 0, (EVRE_SIZE + 1) * nr_tres);
+	lldev->evre_ring_size = EVRE_SIZE * nr_tres;
+
+	/* the EVRE ring has to be EVRE_SIZE aligned */
+	if (!IS_ALIGNED(lldev->evre_ring_handle, EVRE_SIZE)) {
+		u8 evre_ring_shift;
+
+		evre_ring_shift = lldev->evre_ring_handle % EVRE_SIZE;
+		evre_ring_shift = EVRE_SIZE - evre_ring_shift;
+		lldev->evre_ring_handle += evre_ring_shift;
+		lldev->evre_ring += evre_ring_shift;
+	}
+	lldev->nr_tres = nr_tres;
+	lldev->chidx = chidx;
+
+	rc = kfifo_alloc(&lldev->handoff_fifo,
+			 nr_tres * sizeof(struct hidma_tre *), GFP_KERNEL);
+	if (rc)
+		return NULL;
+
+	rc = hidma_ll_setup(lldev);
+	if (rc)
+		return NULL;
+
+	spin_lock_init(&lldev->lock);
+	tasklet_init(&lldev->task, hidma_ll_tre_complete, (unsigned long)lldev);
+	lldev->initialized = 1;
+	hidma_ll_enable_irq(lldev, ENABLE_IRQS);
+	return lldev;
+}
+
+int hidma_ll_uninit(struct hidma_lldev *lldev)
+{
+	int rc = 0;
+	u32 val;
+
+	if (!lldev)
+		return -ENODEV;
+
+	if (lldev->initialized) {
+		u32 required_bytes;
+
+		lldev->initialized = 0;
+
+		required_bytes = sizeof(struct hidma_tre) * lldev->nr_tres;
+		tasklet_kill(&lldev->task);
+		memset(lldev->trepool, 0, required_bytes);
+		lldev->trepool = NULL;
+		lldev->pending_tre_count = 0;
+		lldev->tre_write_offset = 0;
+
+		rc = hidma_ll_reset(lldev);
+
+		/*
+		 * Clear all pending interrupts again.
+		 * Otherwise, we observe reset complete interrupts.
+		 */
+		val = readl(lldev->evca + EVCA_IRQ_STAT_OFFSET);
+		writel(val, lldev->evca + EVCA_IRQ_CLR_OFFSET);
+		hidma_ll_enable_irq(lldev, 0);
+	}
+	return rc;
+}
+
+irqreturn_t hidma_ll_inthandler(int chirq, void *arg)
+{
+	struct hidma_lldev *lldev = arg;
+
+	hidma_ll_int_handler_internal(lldev);
+	return IRQ_HANDLED;
+}
+
+enum dma_status hidma_ll_status(struct hidma_lldev *lldev, u32 tre_ch)
+{
+	enum dma_status ret = DMA_ERROR;
+	unsigned long flags;
+	u8 err_code;
+
+	spin_lock_irqsave(&lldev->lock, flags);
+	err_code = lldev->tx_status_list[tre_ch].err_code;
+
+	if (err_code & EVRE_STATUS_COMPLETE)
+		ret = DMA_COMPLETE;
+	else if (err_code & EVRE_STATUS_ERROR)
+		ret = DMA_ERROR;
+	else
+		ret = DMA_IN_PROGRESS;
+	spin_unlock_irqrestore(&lldev->lock, flags);
+
+	return ret;
+}
-- 
1.8.2.1



From okaya at codeaurora.org  Thu Feb  4 20:34:35 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Thu,  4 Feb 2016 23:34:35 -0500
Subject: [PATCH V14 4/9] dma: add Qualcomm Technologies HIDMA channel driver
In-Reply-To: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
References: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
Message-ID: <1454646882-24369-5-git-send-email-okaya@codeaurora.org>

This patch adds support for hidma engine. The driver consists of two
logical blocks. The DMA engine interface and the low-level interface.
The hardware only supports memcpy/memset and this driver only support
memcpy interface. HW and driver doesn't support slave interface.

Signed-off-by: Sinan Kaya <okaya at codeaurora.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko at gmail.com>
---
 drivers/dma/qcom/Kconfig |  10 +
 drivers/dma/qcom/hidma.c | 706 +++++++++++++++++++++++++++++++++++++++++++++++
 drivers/dma/qcom/hidma.h | 160 +++++++++++
 3 files changed, 876 insertions(+)
 create mode 100644 drivers/dma/qcom/hidma.c
 create mode 100644 drivers/dma/qcom/hidma.h

diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index c975b11..a7761c4 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -17,3 +17,13 @@ config QCOM_HIDMA_MGMT
 	  start managing the channels. In a virtualized environment,
 	  the guest OS would run QCOM_HIDMA channel driver and the
 	  host would run the QCOM_HIDMA_MGMT management driver.
+
+config QCOM_HIDMA
+	tristate "Qualcomm Technologies HIDMA Channel support"
+	select DMA_ENGINE
+	help
+	  Enable support for the Qualcomm Technologies HIDMA controller.
+	  The HIDMA controller supports optimized buffer copies
+	  (user to kernel, kernel to kernel, etc.).  It only supports
+	  memcpy interface. The core is not intended for general
+	  purpose slave DMA.
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
new file mode 100644
index 0000000..83006dd
--- /dev/null
+++ b/drivers/dma/qcom/hidma.c
@@ -0,0 +1,706 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine interface
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
+ * Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2014
+ *
+ * Written by Piotr Ziecik <kosmo at semihalf.com>. Hardware description
+ * (defines, structures and comments) was taken from MPC5121 DMA driver
+ * written by Hongjun Chen <hong-jun.chen at freescale.com>.
+ *
+ * Approved as OSADL project by a majority of OSADL members and funded
+ * by OSADL membership fees in 2009;  for details see www.osadl.org.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * The full GNU General Public License is included in this distribution in the
+ * file called COPYING.
+ */
+
+/* Linux Foundation elects GPLv2 license only. */
+
+#include <linux/dmaengine.h>
+#include <linux/dma-mapping.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/of_dma.h>
+#include <linux/property.h>
+#include <linux/delay.h>
+#include <linux/acpi.h>
+#include <linux/irq.h>
+#include <linux/atomic.h>
+#include <linux/pm_runtime.h>
+
+#include "../dmaengine.h"
+#include "hidma.h"
+
+/*
+ * Default idle time is 2 seconds. This parameter can
+ * be overridden by changing the following
+ * /sys/bus/platform/devices/QCOM8061:<xy>/power/autosuspend_delay_ms
+ * during kernel boot.
+ */
+#define HIDMA_AUTOSUSPEND_TIMEOUT		2000
+#define HIDMA_ERR_INFO_SW			0xFF
+#define HIDMA_ERR_CODE_UNEXPECTED_TERMINATE	0x0
+#define HIDMA_NR_DEFAULT_DESC			10
+
+static inline struct hidma_dev *to_hidma_dev(struct dma_device *dmadev)
+{
+	return container_of(dmadev, struct hidma_dev, ddev);
+}
+
+static inline
+struct hidma_dev *to_hidma_dev_from_lldev(struct hidma_lldev **_lldevp)
+{
+	return container_of(_lldevp, struct hidma_dev, lldev);
+}
+
+static inline struct hidma_chan *to_hidma_chan(struct dma_chan *dmach)
+{
+	return container_of(dmach, struct hidma_chan, chan);
+}
+
+static inline
+struct hidma_desc *to_hidma_desc(struct dma_async_tx_descriptor *t)
+{
+	return container_of(t, struct hidma_desc, desc);
+}
+
+static void hidma_free(struct hidma_dev *dmadev)
+{
+	INIT_LIST_HEAD(&dmadev->ddev.channels);
+}
+
+static unsigned int nr_desc_prm;
+module_param(nr_desc_prm, uint, 0644);
+MODULE_PARM_DESC(nr_desc_prm, "number of descriptors (default: 0)");
+
+
+/* process completed descriptors */
+static void hidma_process_completed(struct hidma_chan *mchan)
+{
+	struct dma_device *ddev = mchan->chan.device;
+	struct hidma_dev *mdma = to_hidma_dev(ddev);
+	struct dma_async_tx_descriptor *desc;
+	dma_cookie_t last_cookie;
+	struct hidma_desc *mdesc;
+	unsigned long irqflags;
+	struct list_head list;
+
+	INIT_LIST_HEAD(&list);
+
+	/* Get all completed descriptors */
+	spin_lock_irqsave(&mchan->lock, irqflags);
+	list_splice_tail_init(&mchan->completed, &list);
+	spin_unlock_irqrestore(&mchan->lock, irqflags);
+
+	/* Execute callbacks and run dependencies */
+	list_for_each_entry(mdesc, &list, node) {
+		enum dma_status llstat;
+
+		desc = &mdesc->desc;
+
+		spin_lock_irqsave(&mchan->lock, irqflags);
+		dma_cookie_complete(desc);
+		spin_unlock_irqrestore(&mchan->lock, irqflags);
+
+		llstat = hidma_ll_status(mdma->lldev, mdesc->tre_ch);
+		if (desc->callback && (llstat == DMA_COMPLETE))
+			desc->callback(desc->callback_param);
+
+		last_cookie = desc->cookie;
+		dma_run_dependencies(desc);
+	}
+
+	/* Free descriptors */
+	spin_lock_irqsave(&mchan->lock, irqflags);
+	list_splice_tail_init(&list, &mchan->free);
+	spin_unlock_irqrestore(&mchan->lock, irqflags);
+
+}
+
+/*
+ * Called once for each submitted descriptor.
+ * PM is locked once for each descriptor that is currently
+ * in execution.
+ */
+static void hidma_callback(void *data)
+{
+	struct hidma_desc *mdesc = data;
+	struct hidma_chan *mchan = to_hidma_chan(mdesc->desc.chan);
+	struct dma_device *ddev = mchan->chan.device;
+	struct hidma_dev *dmadev = to_hidma_dev(ddev);
+	unsigned long irqflags;
+	bool queued = false;
+
+	spin_lock_irqsave(&mchan->lock, irqflags);
+	if (mdesc->node.next) {
+		/* Delete from the active list, add to completed list */
+		list_move_tail(&mdesc->node, &mchan->completed);
+		queued = true;
+
+		/* calculate the next running descriptor */
+		mchan->running = list_first_entry(&mchan->active,
+						  struct hidma_desc, node);
+	}
+	spin_unlock_irqrestore(&mchan->lock, irqflags);
+
+	hidma_process_completed(mchan);
+
+	if (queued) {
+		pm_runtime_mark_last_busy(dmadev->ddev.dev);
+		pm_runtime_put_autosuspend(dmadev->ddev.dev);
+	}
+}
+
+static int hidma_chan_init(struct hidma_dev *dmadev, u32 dma_sig)
+{
+	struct hidma_chan *mchan;
+	struct dma_device *ddev;
+
+	mchan = devm_kzalloc(dmadev->ddev.dev, sizeof(*mchan), GFP_KERNEL);
+	if (!mchan)
+		return -ENOMEM;
+
+	ddev = &dmadev->ddev;
+	mchan->dma_sig = dma_sig;
+	mchan->dmadev = dmadev;
+	mchan->chan.device = ddev;
+	dma_cookie_init(&mchan->chan);
+
+	INIT_LIST_HEAD(&mchan->free);
+	INIT_LIST_HEAD(&mchan->prepared);
+	INIT_LIST_HEAD(&mchan->active);
+	INIT_LIST_HEAD(&mchan->completed);
+
+	spin_lock_init(&mchan->lock);
+	list_add_tail(&mchan->chan.device_node, &ddev->channels);
+	dmadev->ddev.chancnt++;
+	return 0;
+}
+
+static void hidma_issue_task(unsigned long arg)
+{
+	struct hidma_dev *dmadev = (struct hidma_dev *)arg;
+
+	pm_runtime_get_sync(dmadev->ddev.dev);
+	hidma_ll_start(dmadev->lldev);
+}
+
+static void hidma_issue_pending(struct dma_chan *dmach)
+{
+	struct hidma_chan *mchan = to_hidma_chan(dmach);
+	struct hidma_dev *dmadev = mchan->dmadev;
+	unsigned long flags;
+	int status;
+
+	spin_lock_irqsave(&mchan->lock, flags);
+	if (!mchan->running) {
+		struct hidma_desc *desc = list_first_entry(&mchan->active,
+							   struct hidma_desc,
+							   node);
+		mchan->running = desc;
+	}
+	spin_unlock_irqrestore(&mchan->lock, flags);
+
+	/* PM will be released in hidma_callback function. */
+	status = pm_runtime_get(dmadev->ddev.dev);
+	if (status < 0)
+		tasklet_schedule(&dmadev->task);
+	else
+		hidma_ll_start(dmadev->lldev);
+}
+
+static enum dma_status hidma_tx_status(struct dma_chan *dmach,
+				       dma_cookie_t cookie,
+				       struct dma_tx_state *txstate)
+{
+	struct hidma_chan *mchan = to_hidma_chan(dmach);
+	enum dma_status ret;
+
+	ret = dma_cookie_status(dmach, cookie, txstate);
+	if (ret == DMA_COMPLETE)
+		return ret;
+
+	if (mchan->paused && (ret == DMA_IN_PROGRESS)) {
+		unsigned long flags;
+		dma_cookie_t runcookie;
+
+		spin_lock_irqsave(&mchan->lock, flags);
+		if (mchan->running)
+			runcookie = mchan->running->desc.cookie;
+		else
+			runcookie = -EINVAL;
+
+		if (runcookie == cookie)
+			ret = DMA_PAUSED;
+
+		spin_unlock_irqrestore(&mchan->lock, flags);
+	}
+
+	return ret;
+}
+
+/*
+ * Submit descriptor to hardware.
+ * Lock the PM for each descriptor we are sending.
+ */
+static dma_cookie_t hidma_tx_submit(struct dma_async_tx_descriptor *txd)
+{
+	struct hidma_chan *mchan = to_hidma_chan(txd->chan);
+	struct hidma_dev *dmadev = mchan->dmadev;
+	struct hidma_desc *mdesc;
+	unsigned long irqflags;
+	dma_cookie_t cookie;
+
+	pm_runtime_get_sync(dmadev->ddev.dev);
+	if (!hidma_ll_isenabled(dmadev->lldev)) {
+		pm_runtime_mark_last_busy(dmadev->ddev.dev);
+		pm_runtime_put_autosuspend(dmadev->ddev.dev);
+		return -ENODEV;
+	}
+
+	mdesc = container_of(txd, struct hidma_desc, desc);
+	spin_lock_irqsave(&mchan->lock, irqflags);
+
+	/* Move descriptor to active */
+	list_move_tail(&mdesc->node, &mchan->active);
+
+	/* Update cookie */
+	cookie = dma_cookie_assign(txd);
+
+	hidma_ll_queue_request(dmadev->lldev, mdesc->tre_ch);
+	spin_unlock_irqrestore(&mchan->lock, irqflags);
+
+	return cookie;
+}
+
+static int hidma_alloc_chan_resources(struct dma_chan *dmach)
+{
+	struct hidma_chan *mchan = to_hidma_chan(dmach);
+	struct hidma_dev *dmadev = mchan->dmadev;
+	struct hidma_desc *mdesc, *tmp;
+	unsigned long irqflags;
+	LIST_HEAD(descs);
+	unsigned int i;
+	int rc = 0;
+
+	if (mchan->allocated)
+		return 0;
+
+	/* Alloc descriptors for this channel */
+	for (i = 0; i < dmadev->nr_descriptors; i++) {
+		mdesc = kzalloc(sizeof(struct hidma_desc), GFP_NOWAIT);
+		if (!mdesc) {
+			rc = -ENOMEM;
+			break;
+		}
+		dma_async_tx_descriptor_init(&mdesc->desc, dmach);
+		mdesc->desc.tx_submit = hidma_tx_submit;
+
+		rc = hidma_ll_request(dmadev->lldev, mchan->dma_sig,
+				      "DMA engine", hidma_callback, mdesc,
+				      &mdesc->tre_ch);
+		if (rc) {
+			dev_err(dmach->device->dev,
+				"channel alloc failed at %u\n", i);
+			kfree(mdesc);
+			break;
+		}
+		list_add_tail(&mdesc->node, &descs);
+	}
+
+	if (rc) {
+		/* return the allocated descriptors */
+		list_for_each_entry_safe(mdesc, tmp, &descs, node) {
+			hidma_ll_free(dmadev->lldev, mdesc->tre_ch);
+			kfree(mdesc);
+		}
+		return rc;
+	}
+
+	spin_lock_irqsave(&mchan->lock, irqflags);
+	list_splice_tail_init(&descs, &mchan->free);
+	mchan->allocated = true;
+	spin_unlock_irqrestore(&mchan->lock, irqflags);
+	return 1;
+}
+
+static struct dma_async_tx_descriptor *
+hidma_prep_dma_memcpy(struct dma_chan *dmach, dma_addr_t dest, dma_addr_t src,
+		size_t len, unsigned long flags)
+{
+	struct hidma_chan *mchan = to_hidma_chan(dmach);
+	struct hidma_desc *mdesc = NULL;
+	struct hidma_dev *mdma = mchan->dmadev;
+	unsigned long irqflags;
+
+	/* Get free descriptor */
+	spin_lock_irqsave(&mchan->lock, irqflags);
+	if (!list_empty(&mchan->free)) {
+		mdesc = list_first_entry(&mchan->free, struct hidma_desc, node);
+		list_del(&mdesc->node);
+	}
+	spin_unlock_irqrestore(&mchan->lock, irqflags);
+
+	if (!mdesc)
+		return NULL;
+
+	hidma_ll_set_transfer_params(mdma->lldev, mdesc->tre_ch,
+				     src, dest, len, flags);
+
+	/* Place descriptor in prepared list */
+	spin_lock_irqsave(&mchan->lock, irqflags);
+	list_add_tail(&mdesc->node, &mchan->prepared);
+	spin_unlock_irqrestore(&mchan->lock, irqflags);
+
+	return &mdesc->desc;
+}
+
+static int hidma_terminate_channel(struct dma_chan *chan)
+{
+	struct hidma_chan *mchan = to_hidma_chan(chan);
+	struct hidma_dev *dmadev = to_hidma_dev(mchan->chan.device);
+	struct hidma_desc *tmp, *mdesc;
+	unsigned long irqflags;
+	LIST_HEAD(list);
+	int rc;
+
+	pm_runtime_get_sync(dmadev->ddev.dev);
+	/* give completed requests a chance to finish */
+	hidma_process_completed(mchan);
+
+	spin_lock_irqsave(&mchan->lock, irqflags);
+	list_splice_init(&mchan->active, &list);
+	list_splice_init(&mchan->prepared, &list);
+	list_splice_init(&mchan->completed, &list);
+	spin_unlock_irqrestore(&mchan->lock, irqflags);
+
+	/* this suspends the existing transfer */
+	rc = hidma_ll_pause(dmadev->lldev);
+	if (rc) {
+		dev_err(dmadev->ddev.dev, "channel did not pause\n");
+		goto out;
+	}
+
+	/* return all user requests */
+	list_for_each_entry_safe(mdesc, tmp, &list, node) {
+		struct dma_async_tx_descriptor *txd = &mdesc->desc;
+		dma_async_tx_callback callback = mdesc->desc.callback;
+		void *param = mdesc->desc.callback_param;
+
+		dma_descriptor_unmap(txd);
+
+		if (callback)
+			callback(param);
+
+		dma_run_dependencies(txd);
+
+		/* move myself to free_list */
+		list_move(&mdesc->node, &mchan->free);
+	}
+
+	rc = hidma_ll_resume(dmadev->lldev);
+out:
+	pm_runtime_mark_last_busy(dmadev->ddev.dev);
+	pm_runtime_put_autosuspend(dmadev->ddev.dev);
+	return rc;
+}
+
+static int hidma_terminate_all(struct dma_chan *chan)
+{
+	struct hidma_chan *mchan = to_hidma_chan(chan);
+	struct hidma_dev *dmadev = to_hidma_dev(mchan->chan.device);
+	int rc;
+
+	rc = hidma_terminate_channel(chan);
+	if (rc)
+		return rc;
+
+	/* reinitialize the hardware */
+	pm_runtime_get_sync(dmadev->ddev.dev);
+	rc = hidma_ll_setup(dmadev->lldev);
+	pm_runtime_mark_last_busy(dmadev->ddev.dev);
+	pm_runtime_put_autosuspend(dmadev->ddev.dev);
+	return rc;
+}
+
+static void hidma_free_chan_resources(struct dma_chan *dmach)
+{
+	struct hidma_chan *mchan = to_hidma_chan(dmach);
+	struct hidma_dev *mdma = mchan->dmadev;
+	struct hidma_desc *mdesc, *tmp;
+	unsigned long irqflags;
+	LIST_HEAD(descs);
+
+	/* terminate running transactions and free descriptors */
+	hidma_terminate_channel(dmach);
+
+	spin_lock_irqsave(&mchan->lock, irqflags);
+
+	/* Move data */
+	list_splice_tail_init(&mchan->free, &descs);
+
+	/* Free descriptors */
+	list_for_each_entry_safe(mdesc, tmp, &descs, node) {
+		hidma_ll_free(mdma->lldev, mdesc->tre_ch);
+		list_del(&mdesc->node);
+		kfree(mdesc);
+	}
+
+	mchan->allocated = 0;
+	spin_unlock_irqrestore(&mchan->lock, irqflags);
+}
+
+static int hidma_pause(struct dma_chan *chan)
+{
+	struct hidma_chan *mchan;
+	struct hidma_dev *dmadev;
+
+	mchan = to_hidma_chan(chan);
+	dmadev = to_hidma_dev(mchan->chan.device);
+	if (!mchan->paused) {
+		pm_runtime_get_sync(dmadev->ddev.dev);
+		if (hidma_ll_pause(dmadev->lldev))
+			dev_warn(dmadev->ddev.dev, "channel did not stop\n");
+		mchan->paused = true;
+		pm_runtime_mark_last_busy(dmadev->ddev.dev);
+		pm_runtime_put_autosuspend(dmadev->ddev.dev);
+	}
+	return 0;
+}
+
+static int hidma_resume(struct dma_chan *chan)
+{
+	struct hidma_chan *mchan;
+	struct hidma_dev *dmadev;
+	int rc = 0;
+
+	mchan = to_hidma_chan(chan);
+	dmadev = to_hidma_dev(mchan->chan.device);
+	if (mchan->paused) {
+		pm_runtime_get_sync(dmadev->ddev.dev);
+		rc = hidma_ll_resume(dmadev->lldev);
+		if (!rc)
+			mchan->paused = false;
+		else
+			dev_err(dmadev->ddev.dev,
+				"failed to resume the channel");
+		pm_runtime_mark_last_busy(dmadev->ddev.dev);
+		pm_runtime_put_autosuspend(dmadev->ddev.dev);
+	}
+	return rc;
+}
+
+static irqreturn_t hidma_chirq_handler(int chirq, void *arg)
+{
+	struct hidma_lldev *lldev = arg;
+
+	/*
+	 * All interrupts are request driven.
+	 * HW doesn't send an interrupt by itself.
+	 */
+	return hidma_ll_inthandler(chirq, lldev);
+}
+
+static int hidma_probe(struct platform_device *pdev)
+{
+	struct hidma_dev *dmadev;
+	struct resource *trca_resource;
+	struct resource *evca_resource;
+	int chirq;
+	void __iomem *evca;
+	void __iomem *trca;
+	int rc;
+
+	pm_runtime_set_autosuspend_delay(&pdev->dev, HIDMA_AUTOSUSPEND_TIMEOUT);
+	pm_runtime_use_autosuspend(&pdev->dev);
+	pm_runtime_set_active(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+
+	trca_resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	trca = devm_ioremap_resource(&pdev->dev, trca_resource);
+	if (IS_ERR(trca)) {
+		rc = -ENOMEM;
+		goto bailout;
+	}
+
+	evca_resource = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	evca = devm_ioremap_resource(&pdev->dev, evca_resource);
+	if (IS_ERR(evca)) {
+		rc = -ENOMEM;
+		goto bailout;
+	}
+
+	/*
+	 * This driver only handles the channel IRQs.
+	 * Common IRQ is handled by the management driver.
+	 */
+	chirq = platform_get_irq(pdev, 0);
+	if (chirq < 0) {
+		rc = -ENODEV;
+		goto bailout;
+	}
+
+	dmadev = devm_kzalloc(&pdev->dev, sizeof(*dmadev), GFP_KERNEL);
+	if (!dmadev) {
+		rc = -ENOMEM;
+		goto bailout;
+	}
+
+	INIT_LIST_HEAD(&dmadev->ddev.channels);
+	spin_lock_init(&dmadev->lock);
+	dmadev->ddev.dev = &pdev->dev;
+	pm_runtime_get_sync(dmadev->ddev.dev);
+
+	dma_cap_set(DMA_MEMCPY, dmadev->ddev.cap_mask);
+	if (WARN_ON(!pdev->dev.dma_mask)) {
+		rc = -ENXIO;
+		goto dmafree;
+	}
+
+	dmadev->dev_evca = evca;
+	dmadev->evca_resource = evca_resource;
+	dmadev->dev_trca = trca;
+	dmadev->trca_resource = trca_resource;
+	dmadev->ddev.device_prep_dma_memcpy = hidma_prep_dma_memcpy;
+	dmadev->ddev.device_alloc_chan_resources = hidma_alloc_chan_resources;
+	dmadev->ddev.device_free_chan_resources = hidma_free_chan_resources;
+	dmadev->ddev.device_tx_status = hidma_tx_status;
+	dmadev->ddev.device_issue_pending = hidma_issue_pending;
+	dmadev->ddev.device_pause = hidma_pause;
+	dmadev->ddev.device_resume = hidma_resume;
+	dmadev->ddev.device_terminate_all = hidma_terminate_all;
+	dmadev->ddev.copy_align = 8;
+
+	device_property_read_u32(&pdev->dev, "desc-count",
+				 &dmadev->nr_descriptors);
+
+	if (!dmadev->nr_descriptors && nr_desc_prm)
+		dmadev->nr_descriptors = nr_desc_prm;
+
+	if (!dmadev->nr_descriptors)
+		dmadev->nr_descriptors = HIDMA_NR_DEFAULT_DESC;
+
+	dmadev->chidx = readl(dmadev->dev_trca + 0x28);
+
+	/* Set DMA mask to 64 bits. */
+	rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
+	if (rc) {
+		dev_warn(&pdev->dev, "unable to set coherent mask to 64");
+		rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+		if (rc)
+			goto dmafree;
+	}
+
+	dmadev->lldev = hidma_ll_init(dmadev->ddev.dev,
+				      dmadev->nr_descriptors, dmadev->dev_trca,
+				      dmadev->dev_evca, dmadev->chidx);
+	if (!dmadev->lldev) {
+		rc = -EPROBE_DEFER;
+		goto dmafree;
+	}
+
+	rc = devm_request_irq(&pdev->dev, chirq, hidma_chirq_handler, 0,
+			      "qcom-hidma", dmadev->lldev);
+	if (rc)
+		goto uninit;
+
+	INIT_LIST_HEAD(&dmadev->ddev.channels);
+	rc = hidma_chan_init(dmadev, 0);
+	if (rc)
+		goto uninit;
+
+	rc = dma_async_device_register(&dmadev->ddev);
+	if (rc)
+		goto uninit;
+
+	dmadev->irq = chirq;
+	tasklet_init(&dmadev->task, hidma_issue_task, (unsigned long)dmadev);
+	dev_info(&pdev->dev, "HI-DMA engine driver registration complete\n");
+	platform_set_drvdata(pdev, dmadev);
+	pm_runtime_mark_last_busy(dmadev->ddev.dev);
+	pm_runtime_put_autosuspend(dmadev->ddev.dev);
+	return 0;
+
+uninit:
+	hidma_ll_uninit(dmadev->lldev);
+dmafree:
+	if (dmadev)
+		hidma_free(dmadev);
+bailout:
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+	return rc;
+}
+
+static int hidma_remove(struct platform_device *pdev)
+{
+	struct hidma_dev *dmadev = platform_get_drvdata(pdev);
+
+	pm_runtime_get_sync(dmadev->ddev.dev);
+	dma_async_device_unregister(&dmadev->ddev);
+	devm_free_irq(dmadev->ddev.dev, dmadev->irq, dmadev->lldev);
+	hidma_ll_uninit(dmadev->lldev);
+	hidma_free(dmadev);
+
+	dev_info(&pdev->dev, "HI-DMA engine removed\n");
+	pm_runtime_put_sync_suspend(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+
+	return 0;
+}
+
+#if IS_ENABLED(CONFIG_ACPI)
+static const struct acpi_device_id hidma_acpi_ids[] = {
+	{"QCOM8061"},
+	{},
+};
+#endif
+
+static const struct of_device_id hidma_match[] = {
+	{.compatible = "qcom,hidma-1.0",},
+	{},
+};
+
+MODULE_DEVICE_TABLE(of, hidma_match);
+
+static struct platform_driver hidma_driver = {
+	.probe = hidma_probe,
+	.remove = hidma_remove,
+	.driver = {
+		   .name = "hidma",
+		   .of_match_table = hidma_match,
+		   .acpi_match_table = ACPI_PTR(hidma_acpi_ids),
+	},
+};
+
+module_platform_driver(hidma_driver);
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
new file mode 100644
index 0000000..231e306
--- /dev/null
+++ b/drivers/dma/qcom/hidma.h
@@ -0,0 +1,160 @@
+/*
+ * Qualcomm Technologies HIDMA data structures
+ *
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef QCOM_HIDMA_H
+#define QCOM_HIDMA_H
+
+#include <linux/kfifo.h>
+#include <linux/interrupt.h>
+#include <linux/dmaengine.h>
+
+#define TRE_SIZE			32 /* each TRE is 32 bytes  */
+#define TRE_CFG_IDX			0
+#define TRE_LEN_IDX			1
+#define TRE_SRC_LOW_IDX		2
+#define TRE_SRC_HI_IDX			3
+#define TRE_DEST_LOW_IDX		4
+#define TRE_DEST_HI_IDX		5
+
+struct hidma_tx_status {
+	u8 err_info;			/* error record in this transfer    */
+	u8 err_code;			/* completion code		    */
+};
+
+struct hidma_tre {
+	atomic_t allocated;		/* if this channel is allocated	    */
+	bool queued;			/* flag whether this is pending     */
+	u16 status;			/* status			    */
+	u32 chidx;			/* index of the tre		    */
+	u32 dma_sig;			/* signature of the tre		    */
+	const char *dev_name;		/* name of the device		    */
+	void (*callback)(void *data);	/* requester callback		    */
+	void *data;			/* Data associated with this channel*/
+	struct hidma_lldev *lldev;	/* lldma device pointer		    */
+	u32 tre_local[TRE_SIZE / sizeof(u32) + 1]; /* TRE local copy        */
+	u32 tre_index;			/* the offset where this was written*/
+	u32 int_flags;			/* interrupt flags		    */
+};
+
+struct hidma_lldev {
+	bool initialized;		/* initialized flag               */
+	u8 trch_state;			/* trch_state of the device	  */
+	u8 evch_state;			/* evch_state of the device	  */
+	u8 chidx;			/* channel index in the core	  */
+	u32 nr_tres;			/* max number of configs          */
+	spinlock_t lock;		/* reentrancy                     */
+	struct hidma_tre *trepool;	/* trepool of user configs */
+	struct device *dev;		/* device			  */
+	void __iomem *trca;		/* Transfer Channel address       */
+	void __iomem *evca;		/* Event Channel address          */
+	struct hidma_tre
+		**pending_tre_list;	/* Pointers to pending TREs	  */
+	struct hidma_tx_status
+		*tx_status_list;	/* Pointers to pending TREs status*/
+	s32 pending_tre_count;		/* Number of TREs pending	  */
+
+	void *tre_ring;			/* TRE ring			  */
+	dma_addr_t tre_ring_handle;	/* TRE ring to be shared with HW  */
+	u32 tre_ring_size;		/* Byte size of the ring	  */
+	u32 tre_processed_off;		/* last processed TRE		  */
+
+	void *evre_ring;		/* EVRE ring			   */
+	dma_addr_t evre_ring_handle;	/* EVRE ring to be shared with HW  */
+	u32 evre_ring_size;		/* Byte size of the ring	   */
+	u32 evre_processed_off;		/* last processed EVRE		   */
+
+	u32 tre_write_offset;           /* TRE write location              */
+	struct tasklet_struct task;	/* task delivering notifications   */
+	DECLARE_KFIFO_PTR(handoff_fifo,
+		struct hidma_tre *);    /* pending TREs FIFO               */
+};
+
+struct hidma_desc {
+	struct dma_async_tx_descriptor	desc;
+	/* link list node for this channel*/
+	struct list_head		node;
+	u32				tre_ch;
+};
+
+struct hidma_chan {
+	bool				paused;
+	bool				allocated;
+	char				dbg_name[16];
+	u32				dma_sig;
+
+	/*
+	 * active descriptor on this channel
+	 * It is used by the DMA complete notification to
+	 * locate the descriptor that initiated the transfer.
+	 */
+	struct dentry			*debugfs;
+	struct dentry			*stats;
+	struct hidma_dev		*dmadev;
+	struct hidma_desc		*running;
+
+	struct dma_chan			chan;
+	struct list_head		free;
+	struct list_head		prepared;
+	struct list_head		active;
+	struct list_head		completed;
+
+	/* Lock for this structure */
+	spinlock_t			lock;
+};
+
+struct hidma_dev {
+	int				irq;
+	int				chidx;
+	u32				nr_descriptors;
+
+	struct hidma_lldev		*lldev;
+	void				__iomem *dev_trca;
+	struct resource			*trca_resource;
+	void				__iomem *dev_evca;
+	struct resource			*evca_resource;
+
+	/* used to protect the pending channel list*/
+	spinlock_t			lock;
+	struct dma_device		ddev;
+
+	struct dentry			*debugfs;
+	struct dentry			*stats;
+
+	/* Task delivering issue_pending */
+	struct tasklet_struct		task;
+};
+
+int hidma_ll_request(struct hidma_lldev *llhndl, u32 dev_id,
+			const char *dev_name,
+			void (*callback)(void *data), void *data, u32 *tre_ch);
+
+void hidma_ll_free(struct hidma_lldev *llhndl, u32 tre_ch);
+enum dma_status hidma_ll_status(struct hidma_lldev *llhndl, u32 tre_ch);
+bool hidma_ll_isenabled(struct hidma_lldev *llhndl);
+void hidma_ll_queue_request(struct hidma_lldev *llhndl, u32 tre_ch);
+void hidma_ll_start(struct hidma_lldev *llhndl);
+int hidma_ll_pause(struct hidma_lldev *llhndl);
+int hidma_ll_resume(struct hidma_lldev *llhndl);
+void hidma_ll_set_transfer_params(struct hidma_lldev *llhndl, u32 tre_ch,
+	dma_addr_t src, dma_addr_t dest, u32 len, u32 flags);
+int hidma_ll_setup(struct hidma_lldev *lldev);
+struct hidma_lldev *hidma_ll_init(struct device *dev, u32 max_channels,
+			void __iomem *trca, void __iomem *evca,
+			u8 chidx);
+int hidma_ll_uninit(struct hidma_lldev *llhndl);
+irqreturn_t hidma_ll_inthandler(int irq, void *arg);
+void hidma_cleanup_pending_tre(struct hidma_lldev *llhndl, u8 err_info,
+				u8 err_code);
+#endif
-- 
1.8.2.1



From okaya at codeaurora.org  Thu Feb  4 20:34:40 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Thu,  4 Feb 2016 23:34:40 -0500
Subject: [PATCH V14 9/9] vfio, platform: add QTI HIDMA reset driver
In-Reply-To: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
References: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
Message-ID: <1454646882-24369-10-git-send-email-okaya@codeaurora.org>

In situations where the userspace driver is stopped abnormally and the
VFIO platform device is released, the assigned HW device currently is
left running. As a consequence the HW device might continue issuing IRQs
and performing DMA accesses.

This patch is implementing a reset driver for HIDMA platform driver.
This gets called by the VFIO platform reset interface.

Signed-off-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/vfio/platform/reset/Kconfig                |  9 ++
 drivers/vfio/platform/reset/Makefile               |  2 +
 .../vfio/platform/reset/vfio_platform_qcomhidma.c  | 99 ++++++++++++++++++++++
 3 files changed, 110 insertions(+)
 create mode 100644 drivers/vfio/platform/reset/vfio_platform_qcomhidma.c

diff --git a/drivers/vfio/platform/reset/Kconfig b/drivers/vfio/platform/reset/Kconfig
index 70cccc5..d02b3b5 100644
--- a/drivers/vfio/platform/reset/Kconfig
+++ b/drivers/vfio/platform/reset/Kconfig
@@ -13,3 +13,12 @@ config VFIO_PLATFORM_AMDXGBE_RESET
 	  Enables the VFIO platform driver to handle reset for AMD XGBE
 
 	  If you don't know what to do here, say N.
+
+config VFIO_PLATFORM_QCOMHIDMA_RESET
+	tristate "VFIO support for Qualcomm Technologies HIDMA reset"
+	depends on VFIO_PLATFORM
+	help
+	  Enables the VFIO platform driver to handle reset for Qualcomm Technologies
+	  HIDMA Channel.
+
+	  If you don't know what to do here, say N.
diff --git a/drivers/vfio/platform/reset/Makefile b/drivers/vfio/platform/reset/Makefile
index 93f4e23..ec7748a 100644
--- a/drivers/vfio/platform/reset/Makefile
+++ b/drivers/vfio/platform/reset/Makefile
@@ -1,7 +1,9 @@
 vfio-platform-calxedaxgmac-y := vfio_platform_calxedaxgmac.o
 vfio-platform-amdxgbe-y := vfio_platform_amdxgbe.o
+vfio-platform-qcomhidma-y := vfio_platform_qcomhidma.o
 
 ccflags-y += -Idrivers/vfio/platform
 
 obj-$(CONFIG_VFIO_PLATFORM_CALXEDAXGMAC_RESET) += vfio-platform-calxedaxgmac.o
+obj-$(CONFIG_VFIO_PLATFORM_QCOMHIDMA_RESET) += vfio-platform-qcomhidma.o
 obj-$(CONFIG_VFIO_PLATFORM_AMDXGBE_RESET) += vfio-platform-amdxgbe.o
diff --git a/drivers/vfio/platform/reset/vfio_platform_qcomhidma.c b/drivers/vfio/platform/reset/vfio_platform_qcomhidma.c
new file mode 100644
index 0000000..70d7eed
--- /dev/null
+++ b/drivers/vfio/platform/reset/vfio_platform_qcomhidma.c
@@ -0,0 +1,99 @@
+/*
+ * Qualcomm Technologies HIDMA VFIO Reset Driver
+ *
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/device.h>
+#include <linux/iopoll.h>
+
+#include "vfio_platform_private.h"
+
+#define TRCA_CTRLSTS_OFFSET		0x000
+#define EVCA_CTRLSTS_OFFSET		0x000
+
+#define CH_CONTROL_MASK		GENMASK(7, 0)
+#define CH_STATE_MASK			GENMASK(7, 0)
+#define CH_STATE_BIT_POS		0x8
+
+#define HIDMA_CH_STATE(val)	\
+	((val >> CH_STATE_BIT_POS) & CH_STATE_MASK)
+
+#define EVCA_IRQ_EN_OFFSET		0x110
+
+#define CH_RESET			9
+#define CH_DISABLED			0
+
+int vfio_platform_qcomhidma_reset(struct vfio_platform_device *vdev)
+{
+	struct vfio_platform_region *trreg;
+	struct vfio_platform_region *evreg;
+	u32 val;
+	int ret;
+
+	if (vdev->num_regions != 2)
+		return -ENODEV;
+
+	trreg = &vdev->regions[0];
+	if (!trreg->ioaddr) {
+		trreg->ioaddr =
+			ioremap_nocache(trreg->addr, trreg->size);
+		if (!trreg->ioaddr)
+			return -ENOMEM;
+	}
+
+	evreg = &vdev->regions[1];
+	if (!evreg->ioaddr) {
+		evreg->ioaddr =
+			ioremap_nocache(evreg->addr, evreg->size);
+		if (!evreg->ioaddr)
+			return -ENOMEM;
+	}
+
+	/* disable IRQ */
+	writel(0, evreg->ioaddr + EVCA_IRQ_EN_OFFSET);
+
+	/* reset both transfer and event channels */
+	val = readl(trreg->ioaddr + TRCA_CTRLSTS_OFFSET);
+	val &= ~(CH_CONTROL_MASK << 16);
+	val |= CH_RESET << 16;
+	writel(val, trreg->ioaddr + TRCA_CTRLSTS_OFFSET);
+
+	ret = readl_poll_timeout(trreg->ioaddr + TRCA_CTRLSTS_OFFSET, val,
+				 HIDMA_CH_STATE(val) == CH_DISABLED, 1000,
+				 10000);
+	if (ret)
+		return ret;
+
+	val = readl(evreg->ioaddr + EVCA_CTRLSTS_OFFSET);
+	val &= ~(CH_CONTROL_MASK << 16);
+	val |= CH_RESET << 16;
+	writel(val, evreg->ioaddr + EVCA_CTRLSTS_OFFSET);
+
+	ret = readl_poll_timeout(evreg->ioaddr + EVCA_CTRLSTS_OFFSET, val,
+				 HIDMA_CH_STATE(val) == CH_DISABLED, 1000,
+				 10000);
+	if (ret)
+		return ret;
+
+	pr_info("HIDMA channel reset\n");
+	return 0;
+}
+module_vfio_reset_handler("qcom,hidma-1.0", "QCOM8061",
+			  vfio_platform_qcomhidma_reset);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Reset support for Qualcomm Technologies HIDMA device");
-- 
1.8.2.1



From wenyou.yang at atmel.com  Thu Feb  4 20:33:29 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Fri, 5 Feb 2016 12:33:29 +0800
Subject: [PATCH v5 0/2] regulator: act8945a: add regulator driver for the
 sub-device of ACT8945A MFD
Message-ID: <1454646811-19472-1-git-send-email-wenyou.yang@atmel.com>

The ACT8945A is a Multi Function Device with the following subdevices:
 - Regulator
 - Charger

This patch set is to add regulator driver for ACT8945A.
It is based on the patch set:
	http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/405258.html

Changes in v5:
 - remove the OF table.
 - due to the mfd cell .of_compatible removal, use the platform
   device's parent of_node to read the property and assign it
   to the config.dev->of_node.
 - move the config assignment out of the for loop.
 - due the mfd cell .of_compatible removal, update the compatibe
   description and example

Changes in v4:
 - change the name "act8945a-pmic" to "act8945a-regulator"
   to align mfd subdevice's name.

Changes in v3:
 - use the core regulators_node and of_match implementation,
   remove the redundant code.
 - use the core dev_get_regmap(dev->parent) code, remove
   the redundant code.
 - change the regulator name to easily implement macro.
 - use a space after #define, not tabs.
 - add OF match table.

Changes in v2:
 - add more help information in Kconfig.
 - update the file header with short version license and author line.
 - remove unused structure, struct act8945a_pmic.
 - substitute of_property_read_bool() for of_get_property().
 - due to removing the member of stuct act8945a_dev, dev.
 - remove the unnecessary print out.
 - use module_platform_driver(), instead of subsys_initcall().
 - substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").
 - add Acked-by Rob Herring.

Wenyou Yang (2):
  regulator: act8945a: add regulator driver for ACT8945A
  regulator: add documentation for ACT8945A's regulator DT bindings

 .../bindings/regulator/act8945a-regulator.txt      |   80 ++++++++++
 drivers/regulator/Kconfig                          |    9 ++
 drivers/regulator/Makefile                         |    1 +
 drivers/regulator/act8945a-regulator.c             |  165 ++++++++++++++++++++
 4 files changed, 255 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/act8945a-regulator.txt
 create mode 100644 drivers/regulator/act8945a-regulator.c

-- 
1.7.9.5



From wenyou.yang at atmel.com  Thu Feb  4 20:33:30 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Fri, 5 Feb 2016 12:33:30 +0800
Subject: [PATCH v5 1/2] regulator: act8945a: add regulator driver for ACT8945A
In-Reply-To: <1454646811-19472-1-git-send-email-wenyou.yang@atmel.com>
References: <1454646811-19472-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1454646811-19472-2-git-send-email-wenyou.yang@atmel.com>

This patch adds new regulator driver to support ACT8945A MFD
chip's regulators.

The ACT8945A has three step-down DC/DC converters and four
low-dropout regulators.

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---

Changes in v5:
 - remove the OF table.
 - due to the mfd cell .of_compatible removal, use the platform
   device's parent of_node to read the property and assign it
   to the config.dev->of_node.
 - move the config assignment out of the for loop.

Changes in v4:
 - change the name "act8945a-pmic" to "act8945a-regulator"
   to align mfd subdevice's name.

Changes in v3:
 - use the core regulators_node and of_match implementation,
   remove the redundant code.
 - use the core dev_get_regmap(dev->parent) code, remove
   the redundant code.
 - change the regulator name to easily implement macro.
 - use a space after #define, not tabs.
 - add OF match table.

Changes in v2:
 - add more help information in Kconfig.
 - update the file header with short version license and author line.
 - remove unused structure, struct act8945a_pmic.
 - substitute of_property_read_bool() for of_get_property().
 - due to removing the member of stuct act8945a_dev, dev.
 - remove the unnecessary print out.
 - use module_platform_driver(), instead of subsys_initcall().
 - substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").

 drivers/regulator/Kconfig              |    9 ++
 drivers/regulator/Makefile             |    1 +
 drivers/regulator/act8945a-regulator.c |  165 ++++++++++++++++++++++++++++++++
 3 files changed, 175 insertions(+)
 create mode 100644 drivers/regulator/act8945a-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 8155e80..74a6354 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -78,6 +78,15 @@ config REGULATOR_ACT8865
 	  This driver controls a active-semi act8865 voltage output
 	  regulator via I2C bus.
 
+config REGULATOR_ACT8945A
+	tristate "Active-semi ACT8945A voltage regulator"
+	depends on MFD_ACT8945A
+	help
+	  This driver controls a active-semi ACT8945A voltage regulator
+	  via I2C bus. The ACT8945A features three step-down DC/DC converters
+	  and four low-dropout linear regulators, along with a ActivePath
+	  battery charger.
+
 config REGULATOR_AD5398
 	tristate "Analog Devices AD5398/AD5821 regulators"
 	depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 980b194..348cfd7 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_REGULATOR_AAT2870) += aat2870-regulator.o
 obj-$(CONFIG_REGULATOR_AB3100) += ab3100.o
 obj-$(CONFIG_REGULATOR_AB8500)	+= ab8500-ext.o ab8500.o
 obj-$(CONFIG_REGULATOR_ACT8865) += act8865-regulator.o
+obj-$(CONFIG_REGULATOR_ACT8945A) += act8945a-regulator.o
 obj-$(CONFIG_REGULATOR_AD5398) += ad5398.o
 obj-$(CONFIG_REGULATOR_ANATOP) += anatop-regulator.o
 obj-$(CONFIG_REGULATOR_ARIZONA) += arizona-micsupp.o arizona-ldo1.o
diff --git a/drivers/regulator/act8945a-regulator.c b/drivers/regulator/act8945a-regulator.c
new file mode 100644
index 0000000..441864b
--- /dev/null
+++ b/drivers/regulator/act8945a-regulator.c
@@ -0,0 +1,165 @@
+/*
+ * Voltage regulation driver for active-semi ACT8945A PMIC
+ *
+ * Copyright (C) 2015 Atmel Corporation
+ *
+ * Author: Wenyou Yang <wenyou.yang at atmel.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+
+/**
+ * ACT8945A Global Register Map.
+ */
+#define ACT8945A_SYS_MODE	0x00
+#define ACT8945A_SYS_CTRL	0x01
+#define ACT8945A_DCDC1_VSET1	0x20
+#define ACT8945A_DCDC1_VSET2	0x21
+#define ACT8945A_DCDC1_CTRL	0x22
+#define ACT8945A_DCDC2_VSET1	0x30
+#define ACT8945A_DCDC2_VSET2	0x31
+#define ACT8945A_DCDC2_CTRL	0x32
+#define ACT8945A_DCDC3_VSET1	0x40
+#define ACT8945A_DCDC3_VSET2	0x41
+#define ACT8945A_DCDC3_CTRL	0x42
+#define ACT8945A_LDO1_VSET	0x50
+#define ACT8945A_LDO1_CTRL	0x51
+#define ACT8945A_LDO2_VSET	0x54
+#define ACT8945A_LDO2_CTRL	0x55
+#define ACT8945A_LDO3_VSET	0x60
+#define ACT8945A_LDO3_CTRL	0x61
+#define ACT8945A_LDO4_VSET	0x64
+#define ACT8945A_LDO4_CTRL	0x65
+
+/**
+ * Field Definitions.
+ */
+#define ACT8945A_ENA		0x80	/* ON - [7] */
+#define ACT8945A_VSEL_MASK	0x3F	/* VSET - [5:0] */
+
+/**
+ * ACT8945A Voltage Number
+ */
+#define ACT8945A_VOLTAGE_NUM	64
+
+enum {
+	ACT8945A_ID_DCDC1,
+	ACT8945A_ID_DCDC2,
+	ACT8945A_ID_DCDC3,
+	ACT8945A_ID_LDO1,
+	ACT8945A_ID_LDO2,
+	ACT8945A_ID_LDO3,
+	ACT8945A_ID_LDO4,
+	ACT8945A_REG_NUM,
+};
+
+static const struct regulator_linear_range act8945a_voltage_ranges[] = {
+	REGULATOR_LINEAR_RANGE(600000, 0, 23, 25000),
+	REGULATOR_LINEAR_RANGE(1200000, 24, 47, 50000),
+	REGULATOR_LINEAR_RANGE(2400000, 48, 63, 100000),
+};
+
+static struct regulator_ops act8945a_ops = {
+	.list_voltage		= regulator_list_voltage_linear_range,
+	.map_voltage		= regulator_map_voltage_linear_range,
+	.get_voltage_sel	= regulator_get_voltage_sel_regmap,
+	.set_voltage_sel	= regulator_set_voltage_sel_regmap,
+	.enable			= regulator_enable_regmap,
+	.disable		= regulator_disable_regmap,
+	.is_enabled		= regulator_is_enabled_regmap,
+};
+
+#define ACT89xx_REG(_name, _family, _id, _vsel_reg, _supply)		\
+	[_family##_ID_##_id] = {					\
+		.name			= _name,			\
+		.supply_name		= _supply,			\
+		.of_match		= of_match_ptr("REG_"#_id),	\
+		.regulators_node	= of_match_ptr("regulators"),	\
+		.id			= _family##_ID_##_id,		\
+		.type			= REGULATOR_VOLTAGE,		\
+		.ops			= &act8945a_ops,		\
+		.n_voltages		= ACT8945A_VOLTAGE_NUM,		\
+		.linear_ranges		= act8945a_voltage_ranges,	\
+		.n_linear_ranges	= ARRAY_SIZE(act8945a_voltage_ranges), \
+		.vsel_reg		= _family##_##_id##_##_vsel_reg, \
+		.vsel_mask		= ACT8945A_VSEL_MASK,		\
+		.enable_reg		= _family##_##_id##_CTRL,	\
+		.enable_mask		= ACT8945A_ENA,			\
+		.owner			= THIS_MODULE,			\
+	}
+
+static const struct regulator_desc act8945a_regulators[] = {
+	ACT89xx_REG("DCDC_REG1", ACT8945A, DCDC1, VSET1, "vp1"),
+	ACT89xx_REG("DCDC_REG2", ACT8945A, DCDC2, VSET1, "vp2"),
+	ACT89xx_REG("DCDC_REG3", ACT8945A, DCDC3, VSET1, "vp3"),
+	ACT89xx_REG("LDO_REG1", ACT8945A, LDO1, VSET, "inl45"),
+	ACT89xx_REG("LDO_REG2", ACT8945A, LDO2, VSET, "inl45"),
+	ACT89xx_REG("LDO_REG3", ACT8945A, LDO3, VSET, "inl67"),
+	ACT89xx_REG("LDO_REG4", ACT8945A, LDO4, VSET, "inl67"),
+};
+
+static const struct regulator_desc act8945a_alt_regulators[] = {
+	ACT89xx_REG("DCDC_REG1", ACT8945A, DCDC1, VSET2, "vp1"),
+	ACT89xx_REG("DCDC_REG2", ACT8945A, DCDC2, VSET2, "vp2"),
+	ACT89xx_REG("DCDC_REG3", ACT8945A, DCDC3, VSET2, "vp3"),
+	ACT89xx_REG("LDO_REG1", ACT8945A, LDO1, VSET, "inl45"),
+	ACT89xx_REG("LDO_REG2", ACT8945A, LDO2, VSET, "inl45"),
+	ACT89xx_REG("LDO_REG3", ACT8945A, LDO3, VSET, "inl67"),
+	ACT89xx_REG("LDO_REG4", ACT8945A, LDO4, VSET, "inl67"),
+};
+
+static int act8945a_pmic_probe(struct platform_device *pdev)
+{
+	struct regulator_config config = { };
+	const struct regulator_desc *regulators;
+	struct regulator_dev *rdev;
+	int i, num_regulators;
+	bool voltage_select;
+
+	voltage_select = of_property_read_bool(pdev->dev.parent->of_node,
+					       "active-semi,vsel-high");
+
+	if (voltage_select) {
+		regulators = act8945a_alt_regulators;
+		num_regulators = ARRAY_SIZE(act8945a_alt_regulators);
+	} else {
+		regulators = act8945a_regulators;
+		num_regulators = ARRAY_SIZE(act8945a_regulators);
+	}
+
+	config.dev = &pdev->dev;
+	config.dev->of_node = pdev->dev.parent->of_node;
+	for (i = 0; i < num_regulators; i++) {
+		rdev = devm_regulator_register(&pdev->dev, &regulators[i], &config);
+		if (IS_ERR(rdev)) {
+			dev_err(&pdev->dev,
+				"failed to register %s regulator\n",
+				regulators[i].name);
+			return PTR_ERR(rdev);
+		}
+	}
+
+	return 0;
+}
+
+static struct platform_driver act8945a_pmic_driver = {
+	.driver = {
+		.name = "act8945a-regulator",
+	},
+	.probe = act8945a_pmic_probe,
+};
+module_platform_driver(act8945a_pmic_driver);
+
+MODULE_DESCRIPTION("Active-semi ACT8945A voltage regulator driver");
+MODULE_AUTHOR("Wenyou Yang <wenyou.yang at atmel.com>");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5



From wenyou.yang at atmel.com  Thu Feb  4 20:33:31 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Fri, 5 Feb 2016 12:33:31 +0800
Subject: [PATCH v5 2/2] regulator: add documentation for ACT8945A's regulator
 DT bindings
In-Reply-To: <1454646811-19472-1-git-send-email-wenyou.yang@atmel.com>
References: <1454646811-19472-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1454646811-19472-3-git-send-email-wenyou.yang@atmel.com>

This patch adds documentation for the DT bindings of the regulator
subdevice of ACT8945A MFD.

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
Acked-by: Rob Herring <robh at kernel.org>
---

Changes in v5:
 - due the mfd cell .of_compatible removal, update the compatibe
   description and example

Changes in v4: None
Changes in v3: None
Changes in v2:
 - add Acked-by Rob Herring.

 .../bindings/regulator/act8945a-regulator.txt      |   80 ++++++++++++++++++++
 1 file changed, 80 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/act8945a-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/act8945a-regulator.txt b/Documentation/devicetree/bindings/regulator/act8945a-regulator.txt
new file mode 100644
index 0000000..5c80a77
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/act8945a-regulator.txt
@@ -0,0 +1,80 @@
+Device-Tree bindings for regulators of Active-semi ACT8945A Multi-Function Device
+
+Required properties:
+ - compatible: "active-semi,act8945a", please refer to ../mfd/act8945a.txt.
+
+Optional properties:
+- active-semi,vsel-high: Indicates if the VSEL pin is set to logic-high.
+  If this property is missing, assume the VSEL pin is set to logic-low.
+
+Optional input supply properties:
+  - vp1-supply: The input supply for REG_DCDC1
+  - vp2-supply: The input supply for REG_DCDC2
+  - vp3-supply: The input supply for REG_DCDC3
+  - inl45-supply: The input supply for REG_LDO1 and REG_LDO2
+  - inl67-supply: The input supply for REG_LDO3 and REG_LDO4
+
+Any standard regulator properties can be used to configure the single regulator.
+
+The valid names for regulators are:
+	REG_DCDC1, REG_DCDC2, REG_DCDC3, REG_LDO1, REG_LDO2, REG_LDO3, REG_LDO4.
+
+Example:
+	pmic at 5b {
+		compatible = "active-semi,act8945a";
+		reg = <0x5b>;
+		status = "okay";
+
+		active-semi,vsel-high;
+
+		regulators {
+			vdd_1v35_reg: REG_DCDC1 {
+				regulator-name = "VDD_1V35";
+				regulator-min-microvolt = <1350000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-always-on;
+			};
+
+			vdd_1v2_reg: REG_DCDC2 {
+				regulator-name = "VDD_1V2";
+				regulator-min-microvolt = <1100000>;
+				regulator-max-microvolt = <1300000>;
+				regulator-always-on;
+			};
+
+			vdd_3v3_reg: REG_DCDC3 {
+				regulator-name = "VDD_3V3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vdd_fuse_reg: REG_LDO1 {
+				regulator-name = "VDD_FUSE";
+				regulator-min-microvolt = <2500000>;
+				regulator-max-microvolt = <2500000>;
+				regulator-always-on;
+			};
+
+			vdd_3v3_lp_reg: REG_LDO2 {
+				regulator-name = "VDD_3V3_LP";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vdd_led_reg: REG_LDO3 {
+				regulator-name = "VDD_LED";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+			};
+
+			vdd_sdhc_1v8_reg: REG_LDO4 {
+				regulator-name = "VDD_SDHC_1V8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-always-on;
+			};
+		};
+	};
-- 
1.7.9.5



From fijam at archlinux.us  Thu Feb  4 21:01:18 2016
From: fijam at archlinux.us (JM)
Date: Fri, 5 Feb 2016 06:01:18 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
Message-ID: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>

Hi,

I am testing marvell_cesa on a kirkwood device (QNAP TS-212p, Marvell
Kirkwood 88F6282, dts: http://pastebin.com/Gk95KFHf ).
As of kernel 4.4 (4.4.0-trunk-kirkwood #1 Debian 4.4-1~exp1) it fails
in the following way:

modprobe marvell_cesa allhwsupport=1
dmesg | tail -n 1
[ 1057.855091] marvell-cesa: probe of f1030000.crypto failed with error -12

or:

modprobe marvell_cesa
dmesg | tail -n 1
[ 9178.399357] marvell-cesa: probe of f1030000.crypto failed with error -524

With kernel 4.3 it would fail with error -22 on that hardware. There
are scattered reports from other users experiencing the same issue
(1,2,3)

I wonder if this is a result of an invalid definition of the
crypto-sram in the dts of this SoC, or perhaps some other problem
(PEBKAC included).

I can provide SSH access to the affected device if needed.

Best regards,
Jan

[1] http://archlinuxarm.org/forum/viewtopic.php?f=53&t=9249&start=30#p49373
[2] http://www.dd-wrt.com/phpBB2/viewtopic.php?p=1003189&sid=43aea81e160fffefe21c7bd64e2de958
[3] http://forum.doozan.com/read.php?2,12096,24409#msg-24409


From john.stultz at linaro.org  Thu Feb  4 21:03:44 2016
From: john.stultz at linaro.org (John Stultz)
Date: Thu, 4 Feb 2016 21:03:44 -0800
Subject: [PATCH v3 1/4] dt-bindings: power: reset: add document for
 reboot-mode driver
In-Reply-To: <20160205043507.GB4847@rob-hp-laptop>
References: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
 <1454407151-4751-1-git-send-email-andy.yan@rock-chips.com>
 <20160204230814.GA4847@rob-hp-laptop>
 <CALAqxLVyznpLd2MLgGr28TDECpLZ=RpmhxH-SHqntXfBsctcmQ@mail.gmail.com>
 <20160205043507.GB4847@rob-hp-laptop>
Message-ID: <CALAqxLUnbFHjTuJXYXSruV3W0JJ09Fxz=KBe69tZDTd_3_+rxw@mail.gmail.com>

On Thu, Feb 4, 2016 at 8:35 PM, Rob Herring <robh at kernel.org> wrote:
> On Thu, Feb 04, 2016 at 03:46:15PM -0800, John Stultz wrote:
>> On Thu, Feb 4, 2016 at 3:08 PM, Rob Herring <robh at kernel.org> wrote:
>> > On Tue, Feb 02, 2016 at 05:59:11PM +0800, Andy Yan wrote:
>> >> +Example:
>> >> +     reboot-mode {
>> >> +             mode-normal = <BOOT_NORMAL>;
>> >> +             mode-recovery = <BOOT_RECOVERY>;
>> >> +             mode-fastboot = <BOOT_FASTBOOT>;
>> >
>> > I tend to agree with John on calling this mode-bootloader.
>> >
>> > OTOH, fastboot is more specific about what the mode is. The name in DT
>> > and the userspace name don't necessarily have to be the same.
>>
>> Wait. This is a bit confusing. The utility of adding a property name
>> and using that name be the reboot command parsed for made sense
>> (compared to earlier versions which had command strings) as it made
>> the dts more terse.   But it sounds here like you're suggesting we
>> should have some logic in the driver that translates "reboot fastboot"
>> to mode-bootloader or vice versa.
>
> I said early on the DT names and kernel-userspace names should not
> necessarily be linked. They can be, but we shouldn't require that.

Sigh. Ok. It seemed it was due to earlier comments (maybe from others,
but I thought it was you), that we moved from specifying a command
string, to using the label. But if you think the label name and the
commands shouldn't be linked, it seems like we should re-introduce
that. No?

Unless your thinking we need some sort of static in-kernel mapping of
commands to label names? But that just seems painfully indirect for
little gain ("Its obvious! For that mode, you use this term here, and
that different term over there!").

> My concern with mode-bootloader is what if you can boot into multiple
> bootloader modes. Say USB mass storage is one option. "bootloader" is
> not real specific.

True. But as I think we agreed below, "bootloader" and "recovery" are
basically defacto standards, and I think it would be a bad idea to try
to declare all the existing android tooling and docs wrong just
because the command is vague, technically.


>> >> +             mode-loader = <BOOT_LOADER>;
>> >
>> > This one needs a better name. Maybe it should be 'rockchip,mode-loader'
>> > as it is vendor specific. Either way, loader is vague. Perhaps
>> > rockchip,mode-bl-download?
>>
>> Hrm. So how what reboot command do you expect to trigger that?
>
> Whatever your OS has defined to map to that.
>
> We could just decide the kernel will strip <vendor> and 'mode-' and
> match commands against what remains.

That part sounds sane, although I do think having vendor prefixes are
reasonable for actual commands as well.


>> I think one of the difficult things here is that there's no real
>> standards for all bios/bootloader modes. So they are somewhat
>> firmware/bootloader/device specific, and thus we need something that
>> is flexible enough to allow lots of different modes to be easily
>> specified.  That said, this does expose a userspace interface (though
>> one could argue kernel ABI doesn't cross reboots :) so we should try
>> to have some consistency so the same userspace can work on various
>> devices.
>
> There is: UEFI. Boot mode efivars are standard. But then they are pretty
> much PC oriented though. It is more which device to boot off of, but
> there is network boot or boot to bios setup.

Well, there's a partial standard there.  I'm told for android on x86,
there is no UEFI standard way to communicate rebooting to fastboot or
recovery. Every device does its own device specific driver.


>> I do think the "bootloader" and "recovery" arguments are somewhat
>> defacto standards, well established on most android devices.
>
> Yes, otherwise I'd be completely against "mode-bootloader" as the
> property.

Ok.

>> I think here the concern is rockchip probably has some userspace that
>> is already using "reboot maskrom" or "reboot loader" for their own
>> uses. And its a bit of a pain to ask that userspace to be reworked to
>
> Perhaps those are only for development and change would not be so
> painful.

Andy: Can you comment here? How critical are the specific commands
you've used here for your userspace?


>> use "reboot rom-download" or "reboot rockchip,rom-download" depending
>> on how we try to deal with these.  (Granted, non-upstream interfaces
>> aren't official, so that is their risk somewhat, but we avoid being
>> smug about that :)
>
> Or vendor specific modes require vendor specific translation in the
> kernel.

True.


> To some extent we need to design what is right and worry about future
> devices rather than cater to past devices. There's always some
> compromise. What would you design ignoring the existing conditions.
> Start there and then figure out how to make it work with current
> designs.

Fair enough. I just want to make sure we're not getting too caught up
with design purity and are willing the meet the world where it is.

>> Another part of the issue is there isn't really a way to probe for
>> reboot cmd capability here. As much as I'd rather not complicate
>> things, one couldn't easily extend existing userspace to work with
>> current kernels as well as future kernels, since the reboot with an
>> invalid command won't fail. The machine still resets. So you can't try
>> one and fallback to the other.
>
> Well, that's nice. Maybe we should change that? Or we're stuck with
> that ABI?

Maybe? I'm not sure what might have trouble with reboot failing if it
sticks any extra noise in the reboot command.
I'd probably lean towards sticking with the existing behavior.

>> Maybe there needs to be a sysfs entry with the list of the supported commands?
>
> You can just read the DT. Although, the problem then is what happens
> when we move to the next firmware interface. We see that some with
> devices having userspace dependencies on ATAGS.

Heh. I guess. Thought I suspect "Just read the DT to sort out the
available reboot modes" is probably not what most userspace wants to
hear. :)

thanks
-john


From bhupesh.sharma at nxp.com  Thu Feb  4 21:36:28 2016
From: bhupesh.sharma at nxp.com (Bhupesh Sharma)
Date: Fri, 5 Feb 2016 05:36:28 +0000
Subject: [PATCH] PCI: layerscape: add ls2085a compatible
In-Reply-To: <56B3E386.8010002@linaro.org>
References: <1453915925-19198-1-git-send-email-yang.shi@linaro.org>
 <56A906F4.3050809@linaro.org> <20160204223711.GE7031@localhost>
 <56B3E386.8010002@linaro.org>
Message-ID: <VI1PR04MB1230AA5CAEEEE0D4AD8E3DF288D20@VI1PR04MB1230.eurprd04.prod.outlook.com>

> From: Shi, Yang
> Sent: Friday, February 05, 2016 5:19 AM
> 
> On 2/4/2016 2:37 PM, Bjorn Helgaas wrote:
> > On Wed, Jan 27, 2016 at 10:05:40AM -0800, Shi, Yang wrote:
> >> Correct FSL folks email address to nxp.com, sorry for the
> inconvenience.
> >
> > Do we need some MAINTAINERS updates in addition to the ack for this
> patch?
> > I see a bunch of @freescale.com addresses in MAINTAINERS.
> 
> I guess so if the @freescale.com address is not valid anymore.

All @freescale.com address have shifted to @nxp.com.

Leo, Minghuan - can you kindly review this patch.

Shawn - can you take this through your tree, once Leo and Minghuan have reviewed the code.

Regards,
Bhupesh
 
> 
> >
> >> On 1/27/2016 9:32 AM, Yang Shi wrote:
> >>> The layerscape PCI host driver needs recognize ls2085a compatible
> >>> when using firmware with ls2085a compatible property, otherwise the
> >>> PCI bus won't be detected even though ls2085a compatible is included
> by the dts.
> >>>
> >>> Signed-off-by: Yang Shi <yang.shi at linaro.org>
> >>> ---
> >>>   drivers/pci/host/pci-layerscape.c | 1 +
> >>>   1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/drivers/pci/host/pci-layerscape.c
> >>> b/drivers/pci/host/pci-layerscape.c
> >>> index 3923bed..c40d8b2 100644
> >>> --- a/drivers/pci/host/pci-layerscape.c
> >>> +++ b/drivers/pci/host/pci-layerscape.c
> >>> @@ -203,6 +203,7 @@ static const struct of_device_id
> ls_pcie_of_match[] = {
> >>>   	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata
> },
> >>>   	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata
> },
> >>>   	{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata
> },
> >>> +	{ .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },
> >>>   	{ },
> >>>   };
> >>>   MODULE_DEVICE_TABLE(of, ls_pcie_of_match);
> >>>
> >>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html


From lokeshvutla at ti.com  Thu Feb  4 21:42:29 2016
From: lokeshvutla at ti.com (Lokesh Vutla)
Date: Fri, 5 Feb 2016 11:12:29 +0530
Subject: [PATCH v4 0/3] ARM: OMAP2+: hwmod: RTC: Add lock and unlock hooks
Message-ID: <1454650952-20154-1-git-send-email-lokeshvutla@ti.com>

This series implements lock and unlock functions for RTC and hooks
the same to DRA7 and AMx3xx hwmod.

Tested RTC functionality on:
DRA74-EVM: http://pastebin.ubuntu.com/14885542/
BeagleBoard-X15: http://pastebin.ubuntu.com/14885568/
AM437x-GP EVM: http://pastebin.ubuntu.com/14885589/
AM335x BeagleBoneBlack: http://pastebin.ubuntu.com/14885600/

Changes since v3:
- Rebased on top of latest Mainline.
Link to v3 series: https://www.mail-archive.com/linux-omap%40vger.kernel.org/msg118342.html

Lokesh Vutla (3):
  ARM: hwmod: RTC: Add lock and unlock functions
  ARM: DRA7: RTC: Add lock and unlock functions
  ARM: AMx3xx: RTC: Add lock and unlock functions

 arch/arm/mach-omap2/omap_hwmod.h                   |  2 +
 .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |  2 +
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c          |  2 +
 arch/arm/mach-omap2/omap_hwmod_reset.c             | 65 ++++++++++++++++++++++
 4 files changed, 71 insertions(+)

-- 
2.1.4



From lokeshvutla at ti.com  Thu Feb  4 21:42:30 2016
From: lokeshvutla at ti.com (Lokesh Vutla)
Date: Fri, 5 Feb 2016 11:12:30 +0530
Subject: [PATCH v4 1/3] ARM: hwmod: RTC: Add lock and unlock functions
In-Reply-To: <1454650952-20154-1-git-send-email-lokeshvutla@ti.com>
References: <1454650952-20154-1-git-send-email-lokeshvutla@ti.com>
Message-ID: <1454650952-20154-2-git-send-email-lokeshvutla@ti.com>

RTC IP have kicker feature which prevents spurious writes to its registers.
In order to write into any of the RTC registers, KICK values has to be
written to KICK registers.
Introduce omap_hwmod_rtc_unlock/lock functions, which  writes into these
KICK registers inorder to lock and unlock RTC registers.

Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.h       |  2 ++
 arch/arm/mach-omap2/omap_hwmod_reset.c | 65 ++++++++++++++++++++++++++++++++++
 2 files changed, 67 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 76bce11..649576e 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -751,6 +751,8 @@ const char *omap_hwmod_get_main_clk(struct omap_hwmod *oh);
  */
 
 extern int omap_hwmod_aess_preprogram(struct omap_hwmod *oh);
+void omap_hwmod_rtc_unlock(struct omap_hwmod *oh);
+void omap_hwmod_rtc_lock(struct omap_hwmod *oh);
 
 /*
  * Chip variant-specific hwmod init routines - XXX should be converted
diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c b/arch/arm/mach-omap2/omap_hwmod_reset.c
index 65e186c..0e21daa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_reset.c
+++ b/arch/arm/mach-omap2/omap_hwmod_reset.c
@@ -29,6 +29,16 @@
 #include <sound/aess.h>
 
 #include "omap_hwmod.h"
+#include "common.h"
+
+#define OMAP_RTC_STATUS_REG	0x44
+#define OMAP_RTC_KICK0_REG	0x6c
+#define OMAP_RTC_KICK1_REG	0x70
+
+#define OMAP_RTC_KICK0_VALUE	0x83E70B13
+#define OMAP_RTC_KICK1_VALUE	0x95A4F1E0
+#define OMAP_RTC_STATUS_BUSY	BIT(0)
+#define OMAP_RTC_MAX_READY_TIME	50
 
 /**
  * omap_hwmod_aess_preprogram - enable AESS internal autogating
@@ -51,3 +61,58 @@ int omap_hwmod_aess_preprogram(struct omap_hwmod *oh)
 
 	return 0;
 }
+
+/**
+ * omap_rtc_wait_not_busy - Wait for the RTC BUSY flag
+ * @oh: struct omap_hwmod *
+ *
+ * For updating certain RTC registers, the MPU must wait
+ * for the BUSY status in OMAP_RTC_STATUS_REG to become zero.
+ * Once the BUSY status is zero, there is a 15-?s access
+ * period in which the MPU can program.
+ */
+static void omap_rtc_wait_not_busy(struct omap_hwmod *oh)
+{
+	int i;
+
+	/* BUSY may stay active for 1/32768 second (~30 usec) */
+	omap_test_timeout(omap_hwmod_read(oh, OMAP_RTC_STATUS_REG)
+			  & OMAP_RTC_STATUS_REG, OMAP_RTC_MAX_READY_TIME, i);
+	/* now we have ~15 usec to read/write various registers */
+}
+
+/**
+ * omap_hwmod_rtc_unlock - Unlock the Kicker mechanism.
+ * @oh: struct omap_hwmod *
+ *
+ * RTC IP have kicker feature. This prevents spurious writes to its registers.
+ * In order to write into any of the RTC registers, KICK values has te be
+ * written in respective KICK registers. This is needed for hwmod to write into
+ * sysconfig register.
+ */
+void omap_hwmod_rtc_unlock(struct omap_hwmod *oh)
+{
+	local_irq_disable();
+	omap_rtc_wait_not_busy(oh);
+	omap_hwmod_write(OMAP_RTC_KICK0_VALUE, oh, OMAP_RTC_KICK0_REG);
+	omap_hwmod_write(OMAP_RTC_KICK1_VALUE, oh, OMAP_RTC_KICK1_REG);
+	local_irq_enable();
+}
+
+/**
+ * omap_hwmod_rtc_lock - Lock the Kicker mechanism.
+ * @oh: struct omap_hwmod *
+ *
+ * RTC IP have kicker feature. This prevents spurious writes to its registers.
+ * Once the RTC registers are written, KICK mechanism needs to be locked,
+ * in order to prevent any spurious writes. This function locks back the RTC
+ * registers once hwmod completes its write into sysconfig register.
+ */
+void omap_hwmod_rtc_lock(struct omap_hwmod *oh)
+{
+	local_irq_disable();
+	omap_rtc_wait_not_busy(oh);
+	omap_hwmod_write(0x0, oh, OMAP_RTC_KICK0_REG);
+	omap_hwmod_write(0x0, oh, OMAP_RTC_KICK1_REG);
+	local_irq_enable();
+}
-- 
2.1.4



From lokeshvutla at ti.com  Thu Feb  4 21:42:32 2016
From: lokeshvutla at ti.com (Lokesh Vutla)
Date: Fri, 5 Feb 2016 11:12:32 +0530
Subject: [PATCH v4 3/3] ARM: AMx3xx: RTC: Add lock and unlock functions
In-Reply-To: <1454650952-20154-1-git-send-email-lokeshvutla@ti.com>
References: <1454650952-20154-1-git-send-email-lokeshvutla@ti.com>
Message-ID: <1454650952-20154-4-git-send-email-lokeshvutla@ti.com>

Hook omap_hwmod_rtc_unlock/lock functions into RTC hwmod,
so that SYSCONFIG register is updated properly.

Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index 907a452b..aed3362 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -918,6 +918,8 @@ static struct omap_hwmod_class_sysconfig am33xx_rtc_sysc = {
 static struct omap_hwmod_class am33xx_rtc_hwmod_class = {
 	.name		= "rtc",
 	.sysc		= &am33xx_rtc_sysc,
+	.unlock		= &omap_hwmod_rtc_unlock,
+	.lock		= &omap_hwmod_rtc_lock,
 };
 
 struct omap_hwmod am33xx_rtc_hwmod = {
-- 
2.1.4



From lokeshvutla at ti.com  Thu Feb  4 21:42:31 2016
From: lokeshvutla at ti.com (Lokesh Vutla)
Date: Fri, 5 Feb 2016 11:12:31 +0530
Subject: [PATCH v4 2/3] ARM: DRA7: RTC: Add lock and unlock functions
In-Reply-To: <1454650952-20154-1-git-send-email-lokeshvutla@ti.com>
References: <1454650952-20154-1-git-send-email-lokeshvutla@ti.com>
Message-ID: <1454650952-20154-3-git-send-email-lokeshvutla@ti.com>

Hook omap_hwmod_rtc_unlock/lock functions into RTC hwmod,
so that SYSCONFIG register is updated properly

Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 848356e..6625650 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1609,6 +1609,8 @@ static struct omap_hwmod_class_sysconfig dra7xx_rtcss_sysc = {
 static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = {
 	.name	= "rtcss",
 	.sysc	= &dra7xx_rtcss_sysc,
+	.unlock	= &omap_hwmod_rtc_unlock,
+	.lock	= &omap_hwmod_rtc_lock,
 };
 
 /* rtcss */
-- 
2.1.4



From dawei.chien at mediatek.com  Thu Feb  4 21:47:38 2016
From: dawei.chien at mediatek.com (Dawei Chien)
Date: Fri, 5 Feb 2016 13:47:38 +0800
Subject: [PATCH] arm64: dts: mt8173: add node for thermal calibration
Message-ID: <1454651258-41990-1-git-send-email-dawei.chien@mediatek.com>

Add this for supporting thermal calibration by e-fuse data.

Signed-off-by: Dawei Chien <dawei.chien at mediatek.com>
---
Because MTK thermal/efuse patches hadn't landed on mainline, this patch
must base on following patchset:
https://lkml.org/lkml/2015/11/17/251
https://lkml.org/lkml/2015/11/19/169
https://lkml.org/lkml/2015/11/30/239
https://lkml.org/lkml/2015/12/16/195
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index ffcca66..0c9d17e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -391,6 +391,11 @@
 		efuse: efuse at 10206000 {
 			compatible = "mediatek,mt8173-efuse";
 			reg = <0 0x10206000 0 0x1000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			thermal_calibration: calib at 528 {
+				reg = <0x528 0xc>;
+			};
 		};
 
 		apmixedsys: clock-controller at 10209000 {
@@ -744,6 +749,8 @@
 			resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
 			mediatek,auxadc = <&auxadc>;
 			mediatek,apmixedsys = <&apmixedsys>;
+			nvmem-cells = <&thermal_calibration>;
+			nvmem-cell-names = "calibration-data";
 		};
 	};
 };
-- 
1.7.9.5



From alim.akhtar at samsung.com  Thu Feb  4 22:04:29 2016
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Fri, 05 Feb 2016 11:34:29 +0530
Subject: [PATCH v3] arm64: defconfig: Enable samsung MFD and related configs
Message-ID: <1454652269-6100-1-git-send-email-alim.akhtar@samsung.com>

Exynos7 based espresso board uses S2MPS15, a multifunction device.
This patch enables S2MPS1X regulator, pmic-clk and rtc drivers utilized by
the same.

Signed-off-by: Alim Akhtar <alim.akhtar at samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---
Changes since v2:
* Added Reviewed-by from Krzysztof
* rebased on next-20160204

Changes since v1:
* updated the comment message to describe which platfrom uses it.
* enable COMMON_CLK_S2MPS11 which is needed to enable pmic-clk block.

 arch/arm64/configs/defconfig |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 86581f7..2fd2264 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -151,9 +151,11 @@ CONFIG_GPIO_XGENE=y
 CONFIG_POWER_RESET_XGENE=y
 CONFIG_POWER_RESET_SYSCON=y
 # CONFIG_HWMON is not set
+CONFIG_MFD_SEC_CORE=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_QCOM_SMD_RPM=y
+CONFIG_REGULATOR_S2MPS11=y
 CONFIG_FB=y
 CONFIG_FB_ARMCLCD=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
@@ -188,6 +190,7 @@ CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_LEDS_TRIGGER_CPU=y
 CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_S5M=y
 CONFIG_RTC_DRV_EFI=y
 CONFIG_RTC_DRV_PL031=y
 CONFIG_RTC_DRV_XGENE=y
-- 
1.7.10.4



From minghuan.lian at nxp.com  Thu Feb  4 22:07:10 2016
From: minghuan.lian at nxp.com (Minghuan Lian)
Date: Fri, 5 Feb 2016 06:07:10 +0000
Subject: [PATCH] PCI: layerscape: add ls2085a compatible
In-Reply-To: <VI1PR04MB1230AA5CAEEEE0D4AD8E3DF288D20@VI1PR04MB1230.eurprd04.prod.outlook.com>
References: <1453915925-19198-1-git-send-email-yang.shi@linaro.org>
 <56A906F4.3050809@linaro.org> <20160204223711.GE7031@localhost>
 <56B3E386.8010002@linaro.org>
 <VI1PR04MB1230AA5CAEEEE0D4AD8E3DF288D20@VI1PR04MB1230.eurprd04.prod.outlook.com>
Message-ID: <VI1PR04MB16155E4265922D6659B439C1E8D20@VI1PR04MB1615.eurprd04.prod.outlook.com>

The patch is ok to me.

Thanks,
Minghuan

> -----Original Message-----
> From: Bhupesh Sharma
> Sent: Friday, February 05, 2016 1:36 PM
> To: Shi, Yang <yang.shi at linaro.org>; Bjorn Helgaas <helgaas at kernel.org>;
> Yang-Leo Li <leoyang.li at nxp.com>; shawn.guo at linaro.org
> Cc: Mingkai Hu <mingkai.hu at nxp.com>; Minghuan Lian
> <minghuan.lian at nxp.com>; bhelgaas at google.com; linux-pci at vger.kernel.org;
> linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linaro-kernel at lists.linaro.org
> Subject: RE: [PATCH] PCI: layerscape: add ls2085a compatible
> 
> > From: Shi, Yang
> > Sent: Friday, February 05, 2016 5:19 AM
> >
> > On 2/4/2016 2:37 PM, Bjorn Helgaas wrote:
> > > On Wed, Jan 27, 2016 at 10:05:40AM -0800, Shi, Yang wrote:
> > >> Correct FSL folks email address to nxp.com, sorry for the
> > inconvenience.
> > >
> > > Do we need some MAINTAINERS updates in addition to the ack for this
> > patch?
> > > I see a bunch of @freescale.com addresses in MAINTAINERS.
> >
> > I guess so if the @freescale.com address is not valid anymore.
> 
> All @freescale.com address have shifted to @nxp.com.
> 
> Leo, Minghuan - can you kindly review this patch.
> 
> Shawn - can you take this through your tree, once Leo and Minghuan have
> reviewed the code.
> 
> Regards,
> Bhupesh
> 
> >
> > >
> > >> On 1/27/2016 9:32 AM, Yang Shi wrote:
> > >>> The layerscape PCI host driver needs recognize ls2085a compatible
> > >>> when using firmware with ls2085a compatible property, otherwise
> > >>> the PCI bus won't be detected even though ls2085a compatible is
> > >>> included
> > by the dts.
> > >>>
> > >>> Signed-off-by: Yang Shi <yang.shi at linaro.org>
> > >>> ---
> > >>>   drivers/pci/host/pci-layerscape.c | 1 +
> > >>>   1 file changed, 1 insertion(+)
> > >>>
> > >>> diff --git a/drivers/pci/host/pci-layerscape.c
> > >>> b/drivers/pci/host/pci-layerscape.c
> > >>> index 3923bed..c40d8b2 100644
> > >>> --- a/drivers/pci/host/pci-layerscape.c
> > >>> +++ b/drivers/pci/host/pci-layerscape.c
> > >>> @@ -203,6 +203,7 @@ static const struct of_device_id
> > ls_pcie_of_match[] = {
> > >>>   	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata
> > },
> > >>>   	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata
> > },
> > >>>   	{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata
> > },
> > >>> +	{ .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },
> > >>>   	{ },
> > >>>   };
> > >>>   MODULE_DEVICE_TABLE(of, ls_pcie_of_match);
> > >>>
> > >>
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci"
> > in the body of a message to majordomo at vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html

From tony at atomide.com  Thu Feb  4 22:10:21 2016
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 4 Feb 2016 22:10:21 -0800
Subject: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
In-Reply-To: <56B22FC3.3050900@gmail.com>
References: <20160108022619.GS12777@atomide.com> <568F4596.8020206@gmail.com>
 <20160108075913.GN11364@pali> <569052FE.1040008@gmail.com>
 <20160121091437.GT7192@pali> <56B077D4.3030902@gmail.com>
 <20160202233911.GB19432@atomide.com>
 <20160203000045.GE19432@atomide.com> <56B1A654.1060905@gmail.com>
 <56B22FC3.3050900@gmail.com>
Message-ID: <20160205061021.GS19432@atomide.com>

* Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com> [160203 08:51]:
> - flashed maemo rootfs
> 
> sudo flasher-3.5 -f -F RX-51_2009SE_20.2010.36-2_PR_COMBINED_MR0_ARM.bin
> --flash-only=rootfs -R
> 
> - booted to maemo and powered the device off
> 
> sudo flasher-3.5 -k zImage  -l -b"init=/sbin/preinit ubi.mtd=rootfs
> root=ubi0:rootfs rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc rw
> mtdoops.mtddev=log  omapfb_vram=7M omapfb.mode=lcd:848x480-16
> nokia-modem.pm=0"

This seems to fix things here for legacy booting and booting the
maemo zImage after dts image. Care to give it a try?

Basically onenand after reset is in wrong state, have not looked
up the bits yet. Will post a better patch when I get a chance
over next few days.

Regards,

Tony

8< -----------
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -104,6 +104,7 @@ static void set_onenand_cfg(void __iomem *onenand_base)
 	u32 reg;
 
 	reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
+	reg = 0x06c0;
 	reg &= ~((0x7 << ONENAND_SYS_CFG1_BRL_SHIFT) | (0x7 << 9));
 	reg |=	(latency << ONENAND_SYS_CFG1_BRL_SHIFT) |
 		ONENAND_SYS_CFG1_BL_16;
@@ -289,6 +290,7 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base)
 		}
 	}
 
+	onenand_async.sync_write = true;
 	omap2_onenand_calc_async_timings(&t);
 
 	ret = gpmc_cs_program_settings(gpmc_onenand_data->cs, &onenand_async);


From hzpeterchen at gmail.com  Thu Feb  4 22:11:25 2016
From: hzpeterchen at gmail.com (Peter Chen)
Date: Fri, 5 Feb 2016 14:11:25 +0800
Subject: [PATCH v4 1/1] USB: core: let USB device know device node
In-Reply-To: <1454582690.3356.18.camel@pengutronix.de>
References: <1453706679-18948-1-git-send-email-peter.chen@freescale.com>
 <1454582690.3356.18.camel@pengutronix.de>
Message-ID: <20160205061124.GB1858@shlinux2>

On Thu, Feb 04, 2016 at 11:44:50AM +0100, Philipp Zabel wrote:
> Hi Peter,
> 
> Am Montag, den 25.01.2016, 15:24 +0800 schrieb Peter Chen:
> > Although most of USB devices are hot-plug's, there are still some devices
> > are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
> > If these kinds of USB devices are multiple functions, and they can supply
> > other interfaces like i2c, gpios for other devices, we may need to
> > describe these at device tree.
> > 
> > In this commit, it uses "reg" in dts as physical port number to match
> > the phyiscal port number decided by USB core, if they are the same,
> > then the device node is for the device we are creating for USB core.
> > 
> > Signed-off-by: Peter Chen <peter.chen at freescale.com>
> > ---
> > Changes for v4:
> > - The range of "reg" should be 1-31, changing device node address
> >   style as in lower case hexadecimal with leading zeroes suppressed
> >   [binding doc, usb-device.txt]
> > - Improve the example at binding doc, it describes node from the top
> >   (the controller)
> > - Delete the struct of_node * within struct usb_device
> > - Using usb_hcd_find_raw_port_number to get raw port number under root
> >   hub port
> > 
> > Changes for v3:
> > - typo: s/descirbe/describe/
> > 
> > Changes for v2:
> > - Fix build error reported by kbuild robot, lack of "static" for
> >   inline usb_of_get_child_node
> > - Fix typo, "devcie_node" -> "device_node"
> > - Add kernel-doc for of_node at struct usb_device
> > 
> > Changes from RFC:
> > - Fix the error address for binding doc, and add compatible for binding doc
> > - Change get child node API from "usb_of_find_node" to
> >   "usb_of_get_child_node"
> > - Delete unecessary header files
> > - One typo
> > 
> >  .../devicetree/bindings/usb/usb-device.txt         | 25 ++++++++++++
> >  drivers/usb/core/Makefile                          |  2 +-
> >  drivers/usb/core/of.c                              | 47 ++++++++++++++++++++++
> >  drivers/usb/core/usb.c                             | 14 ++++++-
> >  include/linux/usb/of.h                             |  7 ++++
> >  5 files changed, 92 insertions(+), 3 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/usb/usb-device.txt
> >  create mode 100644 drivers/usb/core/of.c
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt b/Documentation/devicetree/bindings/usb/usb-device.txt
> > new file mode 100644
> > index 0000000..c702885
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/usb-device.txt
> > @@ -0,0 +1,25 @@
> > +Generic USB Device Properties
> > +
> > +Usually, we only use device tree for hard wired USB device.
> > +The reference binding doc is from:
> > +http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
> > +
> > +Required properties:
> > +- compatible: usbVID,PID
> 
> The reference recommendation states that for single-configuration USB
> devices the compatible should contain all of the applicable strings from
> the list starting with 2) "usbVID,PID.REV" and ending with 11)
> "usb,device". Are we going to ignore this?
> 

I have not seen benefits if we write several compatibles in dts,
the information of compatibles listed in doc can be got during
the enumeration.

I suggest we use the simple pattern for this compatible, in that
case, every one can be easy to follow it, and will not be confused
which compatibles should be used, and the style can be unify.

> The document also states that "the textual representation of VID, PID
> [...] shall be in lower case hexadecimal with leading zeroes
> suppressed". This should be documented here.

I will change.

> 
> > +- reg: the port number which this device is connecting to, the range
> > +  is 1-31.
> > +
> > +
> > +Example:
> > +
> > +&usb1 {
> > +	status = "okay";
> > +
> > +	#address-cells = <1>;
> > +	#size-cells = <0>;
> > +
> > +	hub: genesys at 1 {
> 
> There are node names specified for hubs and mass storage devices:
> "hub", "storage", "cdrom", "tape", "solid-state", and "device" for
> everything else. Should we follow this recommendation?

I agree.

> 
> > +		compatible = "usb05e3,0608";
> > +		reg = <0x1>;
> > +	};
> 
> I'd have written this node as:
> 
> 	hub: hub at 1 {
> 		compatible = "usb5e3,608", "usb5e3,class9",
> 			     "usb,class9", "usb,device";
> 		reg = <1>;
> 	};

The reg should be hexadecimal, do we need to add "0x" before the value?

> As another example, I'd like to introduce the USB WLAN Adapter soldered
> onto the imx6q-gk802 board to its power enable GPIO via the device tree:
> 
> /* Internal USB port (USBH1) */
> &usbh1 {
> 	#address-cells = <1>;
> 	#size-cells = <0>;
> 	status = "okay";
> 
> 	/* RTL8192CU 802.11n WLAN Adapter */
> 	device at 1 {
> 		compatible = "usbbda,8176.200", "usbbda,8176",
> 			     "usb,device";
> 		reg = <1>;
> 
> 		enable-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
> 	};
> };
> 

It is okay to use your example, but I still insist like below:

/* Internal USB port (USBH1) */
&usbh1 {
	#address-cells = <1>;
	#size-cells = <0>;
	status = "okay";

	/* RTL8192CU 802.11n WLAN Adapter */
	device at 1 {
		compatible = "usbbda,8176";
		reg = <1>;

		enable-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
	};
};


-- 

Best Regards,
Peter Chen


From ulf.hansson at linaro.org  Thu Feb  4 22:54:04 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Fri, 5 Feb 2016 07:54:04 +0100
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <20160205010810.GR19432@atomide.com>
References: <CAPDyKFpRnmn+h_VH3jtC3u-BOf7-00nbzD30omaxaaZOOAK8Gg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602041702550.1515-100000@iolanthe.rowland.org>
 <CAPDyKFrMZYdeun67FBXdWL16DBOuO16qqOxRsks3QBJhNB8SoQ@mail.gmail.com>
 <20160205010810.GR19432@atomide.com>
Message-ID: <CAPDyKFoawbrj3w_+2p5ugjByrwxwmA1S2God1VAvkRbh2rUtjg@mail.gmail.com>

On 5 February 2016 at 02:08, Tony Lindgren <tony at atomide.com> wrote:
> * Ulf Hansson <ulf.hansson at linaro.org> [160204 14:35]:
>> On 4 February 2016 at 23:09, Alan Stern <stern at rowland.harvard.edu> wrote:
>> > On Thu, 4 Feb 2016, Ulf Hansson wrote:
>> >
>> >> I am really not questioning the autosuspend feature at all, it's a
>> >> really great feature!
>> >>
>> >> Now, I question the minor benefit we actually gain from having the
>> >> runtime PM core to update the mark in rpm_resume().
>> >
>> > As Tony pointed out, it prevents some devices from going to sleep right
>> > away.
>>
>> Because their drivers don't care to update the last busy mark!?
>
> Nope. Without that devices may never resume at all so the drivers
> can't do anything about it.

I don't get it. Why not? Because of another abuse of the runtime PM API?

Or we should probably continue to focus on fixing the regression. :-)

Kind regards
Uffe


From zhaoshenglong at huawei.com  Thu Feb  4 23:13:56 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:13:56 +0800
Subject: [PATCH v11 01/21] ARM64: Move PMU register related defines to
 asm/pmu.h
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-2-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

To use the ARMv8 PMU related register defines from the KVM code,
we move the relevant definitions to asm/pmu.h header file.

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/pmu.h   | 67 ++++++++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/perf_event.c | 36 +----------------------
 2 files changed, 68 insertions(+), 35 deletions(-)
 create mode 100644 arch/arm64/include/asm/pmu.h

diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
new file mode 100644
index 0000000..4406184
--- /dev/null
+++ b/arch/arm64/include/asm/pmu.h
@@ -0,0 +1,67 @@
+/*
+ * PMU support
+ *
+ * Copyright (C) 2012 ARM Limited
+ * Author: Will Deacon <will.deacon at arm.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/>.
+ */
+#ifndef __ASM_PMU_H
+#define __ASM_PMU_H
+
+#define ARMV8_MAX_COUNTERS      32
+#define ARMV8_COUNTER_MASK      (ARMV8_MAX_COUNTERS - 1)
+
+/*
+ * Per-CPU PMCR: config reg
+ */
+#define ARMV8_PMCR_E		(1 << 0) /* Enable all counters */
+#define ARMV8_PMCR_P		(1 << 1) /* Reset all counters */
+#define ARMV8_PMCR_C		(1 << 2) /* Cycle counter reset */
+#define ARMV8_PMCR_D		(1 << 3) /* CCNT counts every 64th cpu cycle */
+#define ARMV8_PMCR_X		(1 << 4) /* Export to ETM */
+#define ARMV8_PMCR_DP		(1 << 5) /* Disable CCNT if non-invasive debug*/
+#define	ARMV8_PMCR_N_SHIFT	11	 /* Number of counters supported */
+#define	ARMV8_PMCR_N_MASK	0x1f
+#define	ARMV8_PMCR_MASK		0x3f	 /* Mask for writable bits */
+
+/*
+ * PMCNTEN: counters enable reg
+ */
+#define	ARMV8_CNTEN_MASK	0xffffffff	/* Mask for writable bits */
+
+/*
+ * PMINTEN: counters interrupt enable reg
+ */
+#define	ARMV8_INTEN_MASK	0xffffffff	/* Mask for writable bits */
+
+/*
+ * PMOVSR: counters overflow flag status reg
+ */
+#define	ARMV8_OVSR_MASK		0xffffffff	/* Mask for writable bits */
+#define	ARMV8_OVERFLOWED_MASK	ARMV8_OVSR_MASK
+
+/*
+ * PMXEVTYPER: Event selection reg
+ */
+#define	ARMV8_EVTYPE_MASK	0xc80003ff	/* Mask for writable bits */
+#define	ARMV8_EVTYPE_EVENT	0x3ff		/* Mask for EVENT bits */
+
+/*
+ * Event filters for PMUv3
+ */
+#define	ARMV8_EXCLUDE_EL1	(1 << 31)
+#define	ARMV8_EXCLUDE_EL0	(1 << 30)
+#define	ARMV8_INCLUDE_EL2	(1 << 27)
+
+#endif /* __ASM_PMU_H */
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index f7ab14c..8fad83d 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -24,6 +24,7 @@
 #include <linux/of.h>
 #include <linux/perf/arm_pmu.h>
 #include <linux/platform_device.h>
+#include <asm/pmu.h>
 
 /*
  * ARMv8 PMUv3 Performance Events handling code.
@@ -333,9 +334,6 @@ static const struct attribute_group *armv8_pmuv3_attr_groups[] = {
 #define	ARMV8_IDX_COUNTER_LAST(cpu_pmu) \
 	(ARMV8_IDX_CYCLE_COUNTER + cpu_pmu->num_events - 1)
 
-#define	ARMV8_MAX_COUNTERS	32
-#define	ARMV8_COUNTER_MASK	(ARMV8_MAX_COUNTERS - 1)
-
 /*
  * ARMv8 low level PMU access
  */
@@ -346,38 +344,6 @@ static const struct attribute_group *armv8_pmuv3_attr_groups[] = {
 #define	ARMV8_IDX_TO_COUNTER(x)	\
 	(((x) - ARMV8_IDX_COUNTER0) & ARMV8_COUNTER_MASK)
 
-/*
- * Per-CPU PMCR: config reg
- */
-#define ARMV8_PMCR_E		(1 << 0) /* Enable all counters */
-#define ARMV8_PMCR_P		(1 << 1) /* Reset all counters */
-#define ARMV8_PMCR_C		(1 << 2) /* Cycle counter reset */
-#define ARMV8_PMCR_D		(1 << 3) /* CCNT counts every 64th cpu cycle */
-#define ARMV8_PMCR_X		(1 << 4) /* Export to ETM */
-#define ARMV8_PMCR_DP		(1 << 5) /* Disable CCNT if non-invasive debug*/
-#define	ARMV8_PMCR_N_SHIFT	11	 /* Number of counters supported */
-#define	ARMV8_PMCR_N_MASK	0x1f
-#define	ARMV8_PMCR_MASK		0x3f	 /* Mask for writable bits */
-
-/*
- * PMOVSR: counters overflow flag status reg
- */
-#define	ARMV8_OVSR_MASK		0xffffffff	/* Mask for writable bits */
-#define	ARMV8_OVERFLOWED_MASK	ARMV8_OVSR_MASK
-
-/*
- * PMXEVTYPER: Event selection reg
- */
-#define	ARMV8_EVTYPE_MASK	0xc80003ff	/* Mask for writable bits */
-#define	ARMV8_EVTYPE_EVENT	0x3ff		/* Mask for EVENT bits */
-
-/*
- * Event filters for PMUv3
- */
-#define	ARMV8_EXCLUDE_EL1	(1 << 31)
-#define	ARMV8_EXCLUDE_EL0	(1 << 30)
-#define	ARMV8_INCLUDE_EL2	(1 << 27)
-
 static inline u32 armv8pmu_pmcr_read(void)
 {
 	u32 val;
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:13:58 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:13:58 +0800
Subject: [PATCH v11 03/21] KVM: ARM64: Add offset defines for PMU registers
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-4-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

We are about to trap and emulate accesses to each PMU register
individually. This adds the context offsets for the AArch64 PMU
registers.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/kvm_host.h | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 6f0241f..6bab7fb 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -115,6 +115,21 @@ enum vcpu_sysreg {
 	MDSCR_EL1,	/* Monitor Debug System Control Register */
 	MDCCINT_EL1,	/* Monitor Debug Comms Channel Interrupt Enable Reg */
 
+	/* Performance Monitors Registers */
+	PMCR_EL0,	/* Control Register */
+	PMOVSSET_EL0,	/* Overflow Flag Status Set Register */
+	PMSELR_EL0,	/* Event Counter Selection Register */
+	PMEVCNTR0_EL0,	/* Event Counter Register (0-30) */
+	PMEVCNTR30_EL0 = PMEVCNTR0_EL0 + 30,
+	PMCCNTR_EL0,	/* Cycle Counter Register */
+	PMEVTYPER0_EL0,	/* Event Type Register (0-30) */
+	PMEVTYPER30_EL0 = PMEVTYPER0_EL0 + 30,
+	PMCCFILTR_EL0,	/* Cycle Count Filter Register */
+	PMCNTENSET_EL0,	/* Count Enable Set Register */
+	PMINTENSET_EL1,	/* Interrupt Enable Set Register */
+	PMUSERENR_EL0,	/* User Enable Register */
+	PMSWINC_EL0,	/* Software Increment Register */
+
 	/* 32bit specific registers. Keep them at the end of the range */
 	DACR32_EL2,	/* Domain Access Control Register */
 	IFSR32_EL2,	/* Instruction Fault Status Register */
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:14 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:14 +0800
Subject: [PATCH v11 19/21] KVM: ARM64: Add a new feature bit for PMUv3
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-20-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

To support guest PMUv3, use one bit of the VCPU INIT feature array.
Initialize the PMU when initialzing the vcpu with that bit and PMU
overflow interrupt set.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Peter Maydell <peter.maydell at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
CC: Peter Maydell <peter.maydell at linaro.org>
---
 Documentation/virtual/kvm/api.txt | 2 ++
 arch/arm64/include/asm/kvm_host.h | 2 +-
 arch/arm64/include/uapi/asm/kvm.h | 1 +
 arch/arm64/kvm/reset.c            | 3 +++
 include/kvm/arm_pmu.h             | 2 ++
 include/uapi/linux/kvm.h          | 1 +
 virt/kvm/arm/pmu.c                | 9 +++++++++
 7 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 07e4cdf..9684f8d 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2577,6 +2577,8 @@ Possible features:
 	  Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
 	- KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 for the CPU.
 	  Depends on KVM_CAP_ARM_PSCI_0_2.
+	- KVM_ARM_VCPU_PMU_V3: Emulate PMUv3 for the CPU.
+	  Depends on KVM_CAP_ARM_PMU_V3.
 
 
 4.83 KVM_ARM_PREFERRED_TARGET
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 6bab7fb..cb220b7 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -40,7 +40,7 @@
 
 #define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
 
-#define KVM_VCPU_MAX_FEATURES 3
+#define KVM_VCPU_MAX_FEATURES 4
 
 int __attribute_const__ kvm_target_cpu(void);
 int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 2d4ca4b..6aedbe3 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -94,6 +94,7 @@ struct kvm_regs {
 #define KVM_ARM_VCPU_POWER_OFF		0 /* CPU is started in OFF state */
 #define KVM_ARM_VCPU_EL1_32BIT		1 /* CPU running a 32bit VM */
 #define KVM_ARM_VCPU_PSCI_0_2		2 /* CPU uses PSCI v0.2 */
+#define KVM_ARM_VCPU_PMU_V3		3 /* Support guest PMUv3 */
 
 struct kvm_vcpu_init {
 	__u32 target;
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index dfbce78..cf4f28a 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
 	case KVM_CAP_GUEST_DEBUG_HW_WPS:
 		r = get_num_wrps();
 		break;
+	case KVM_CAP_ARM_PMU_V3:
+		r = kvm_arm_support_pmu_v3();
+		break;
 	case KVM_CAP_SET_GUEST_DEBUG:
 		r = 1;
 		break;
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index d73cb97..5f86e1d 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -51,6 +51,7 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
+bool kvm_arm_support_pmu_v3(void);
 #else
 struct kvm_pmu {
 };
@@ -77,6 +78,7 @@ static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
+static inline bool kvm_arm_support_pmu_v3(void) { return false; }
 #endif
 
 #endif
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 9da9051..dc16d30 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -850,6 +850,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_IOEVENTFD_ANY_LENGTH 122
 #define KVM_CAP_HYPERV_SYNIC 123
 #define KVM_CAP_S390_RI 124
+#define KVM_CAP_ARM_PMU_V3 125
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 6b525df..2467d62 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -384,3 +384,12 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 
 	pmc->perf_event = event;
 }
+
+bool kvm_arm_support_pmu_v3(void)
+{
+	/* Check if HW_PERF_EVENTS are supported by checking the number of
+	 * hardware performance counters. This could ensure physical PMU and
+	 * PERF_EVENT driver existing.
+	 */
+	return (perf_num_counters() > 0);
+}
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:12 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:12 +0800
Subject: [PATCH v11 17/21] KVM: ARM64: Reset PMU state when resetting vcpu
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-18-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When resetting vcpu, it needs to reset the PMU state to initial status.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/kvm/reset.c |  3 +++
 include/kvm/arm_pmu.h  |  2 ++
 virt/kvm/arm/pmu.c     | 17 +++++++++++++++++
 3 files changed, 22 insertions(+)

diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index f34745c..dfbce78 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -120,6 +120,9 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 	/* Reset system registers */
 	kvm_reset_sys_regs(vcpu);
 
+	/* Reset PMU */
+	kvm_pmu_vcpu_reset(vcpu);
+
 	/* Reset timer */
 	return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
 }
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 44a3c75..191908c 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -41,6 +41,7 @@ struct kvm_pmu {
 u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
 void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
+void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
@@ -65,6 +66,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 {
 	return 0;
 }
+static inline void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu) {}
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 5f983cb..3ea9a89 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -84,6 +84,23 @@ static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
 	}
 }
 
+/**
+ * kvm_pmu_vcpu_reset - reset pmu state for cpu
+ * @vcpu: The vcpu pointer
+ *
+ */
+void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu)
+{
+	int i;
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+	for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+		kvm_pmu_stop_counter(vcpu, &pmu->pmc[i]);
+		pmu->pmc[i].idx = i;
+		pmu->pmc[i].bitmask = 0xffffffffUL;
+	}
+}
+
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 {
 	u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMCR_N_SHIFT;
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:13:57 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:13:57 +0800
Subject: [PATCH v11 02/21] KVM: ARM64: Define PMU data structure for each vcpu
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-3-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Here we plan to support virtual PMU for guest by full software
emulation, so define some basic structs and functions preparing for
futher steps. Define struct kvm_pmc for performance monitor counter and
struct kvm_pmu for performance monitor unit for each vcpu. According to
ARMv8 spec, the PMU contains at most 32(ARMV8_MAX_COUNTERS) counters.

Since this only supports ARM64 (or PMUv3), add a separate config symbol
for it.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/kvm_host.h |  2 ++
 arch/arm64/kvm/Kconfig            |  7 +++++++
 include/kvm/arm_pmu.h             | 42 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 51 insertions(+)
 create mode 100644 include/kvm/arm_pmu.h

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 689d4c9..6f0241f 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -36,6 +36,7 @@
 
 #include <kvm/arm_vgic.h>
 #include <kvm/arm_arch_timer.h>
+#include <kvm/arm_pmu.h>
 
 #define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
 
@@ -211,6 +212,7 @@ struct kvm_vcpu_arch {
 	/* VGIC state */
 	struct vgic_cpu vgic_cpu;
 	struct arch_timer_cpu timer_cpu;
+	struct kvm_pmu pmu;
 
 	/*
 	 * Anything that is not used directly from assembly code goes
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index a5272c0..de7450d 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -36,6 +36,7 @@ config KVM
 	select HAVE_KVM_EVENTFD
 	select HAVE_KVM_IRQFD
 	select KVM_ARM_VGIC_V3
+	select KVM_ARM_PMU if HW_PERF_EVENTS
 	---help---
 	  Support hosting virtualized guest machines.
 	  We don't support KVM with 16K page tables yet, due to the multiple
@@ -48,6 +49,12 @@ config KVM_ARM_HOST
 	---help---
 	  Provides host support for ARM processors.
 
+config KVM_ARM_PMU
+	bool
+	---help---
+	  Adds support for a virtual Performance Monitoring Unit (PMU) in
+	  virtual machines.
+
 source drivers/vhost/Kconfig
 
 endif # VIRTUALIZATION
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
new file mode 100644
index 0000000..be220ee
--- /dev/null
+++ b/include/kvm/arm_pmu.h
@@ -0,0 +1,42 @@
+/*
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Shannon Zhao <shannon.zhao at linaro.org>
+ *
+ * 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/>.
+ */
+
+#ifndef __ASM_ARM_KVM_PMU_H
+#define __ASM_ARM_KVM_PMU_H
+
+#ifdef CONFIG_KVM_ARM_PMU
+
+#include <linux/perf_event.h>
+#include <asm/pmu.h>
+
+struct kvm_pmc {
+	u8 idx;/* index into the pmu->pmc array */
+	struct perf_event *perf_event;
+	u64 bitmask;
+};
+
+struct kvm_pmu {
+	int irq_num;
+	struct kvm_pmc pmc[ARMV8_MAX_COUNTERS];
+	bool ready;
+};
+#else
+struct kvm_pmu {
+};
+#endif
+
+#endif
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:15 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:15 +0800
Subject: [PATCH v11 20/21] KVM: ARM: Introduce per-vcpu kvm device controls
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-21-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

In some cases it needs to get/set attributes specific to a vcpu and so
needs something else than ONE_REG.

Let's copy the KVM_DEVICE approach, and define the respective ioctls
for the vcpu file descriptor.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
Acked-by: Peter Maydell <peter.maydell at linaro.org>
---
CC: Peter Maydell <peter.maydell at linaro.org>
---
 Documentation/virtual/kvm/api.txt          | 10 +++---
 Documentation/virtual/kvm/devices/vcpu.txt |  8 +++++
 arch/arm/kvm/arm.c                         | 55 ++++++++++++++++++++++++++++++
 arch/arm64/kvm/reset.c                     |  1 +
 include/uapi/linux/kvm.h                   |  1 +
 5 files changed, 71 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/virtual/kvm/devices/vcpu.txt

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 9684f8d..cb2ef0b 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2507,8 +2507,9 @@ struct kvm_create_device {
 
 4.80 KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR
 
-Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device
-Type: device ioctl, vm ioctl
+Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device,
+  KVM_CAP_VCPU_ATTRIBUTES for vcpu device
+Type: device ioctl, vm ioctl, vcpu ioctl
 Parameters: struct kvm_device_attr
 Returns: 0 on success, -1 on error
 Errors:
@@ -2533,8 +2534,9 @@ struct kvm_device_attr {
 
 4.81 KVM_HAS_DEVICE_ATTR
 
-Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device
-Type: device ioctl, vm ioctl
+Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device,
+  KVM_CAP_VCPU_ATTRIBUTES for vcpu device
+Type: device ioctl, vm ioctl, vcpu ioctl
 Parameters: struct kvm_device_attr
 Returns: 0 on success, -1 on error
 Errors:
diff --git a/Documentation/virtual/kvm/devices/vcpu.txt b/Documentation/virtual/kvm/devices/vcpu.txt
new file mode 100644
index 0000000..3cc59c5
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/vcpu.txt
@@ -0,0 +1,8 @@
+Generic vcpu interface
+====================================
+
+The virtual cpu "device" also accepts the ioctls KVM_SET_DEVICE_ATTR,
+KVM_GET_DEVICE_ATTR, and KVM_HAS_DEVICE_ATTR. The interface uses the same struct
+kvm_device_attr as other devices, but targets VCPU-wide settings and controls.
+
+The groups and attributes per virtual cpu, if any, are architecture specific.
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index d2c2cc3..34d7395 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -826,11 +826,51 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu,
 	return 0;
 }
 
+static int kvm_arm_vcpu_set_attr(struct kvm_vcpu *vcpu,
+				 struct kvm_device_attr *attr)
+{
+	int ret = -ENXIO;
+
+	switch (attr->group) {
+	default:
+		break;
+	}
+
+	return ret;
+}
+
+static int kvm_arm_vcpu_get_attr(struct kvm_vcpu *vcpu,
+				 struct kvm_device_attr *attr)
+{
+	int ret = -ENXIO;
+
+	switch (attr->group) {
+	default:
+		break;
+	}
+
+	return ret;
+}
+
+static int kvm_arm_vcpu_has_attr(struct kvm_vcpu *vcpu,
+				 struct kvm_device_attr *attr)
+{
+	int ret = -ENXIO;
+
+	switch (attr->group) {
+	default:
+		break;
+	}
+
+	return ret;
+}
+
 long kvm_arch_vcpu_ioctl(struct file *filp,
 			 unsigned int ioctl, unsigned long arg)
 {
 	struct kvm_vcpu *vcpu = filp->private_data;
 	void __user *argp = (void __user *)arg;
+	struct kvm_device_attr attr;
 
 	switch (ioctl) {
 	case KVM_ARM_VCPU_INIT: {
@@ -873,6 +913,21 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
 			return -E2BIG;
 		return kvm_arm_copy_reg_indices(vcpu, user_list->reg);
 	}
+	case KVM_SET_DEVICE_ATTR: {
+		if (copy_from_user(&attr, argp, sizeof(attr)))
+			return -EFAULT;
+		return kvm_arm_vcpu_set_attr(vcpu, &attr);
+	}
+	case KVM_GET_DEVICE_ATTR: {
+		if (copy_from_user(&attr, argp, sizeof(attr)))
+			return -EFAULT;
+		return kvm_arm_vcpu_get_attr(vcpu, &attr);
+	}
+	case KVM_HAS_DEVICE_ATTR: {
+		if (copy_from_user(&attr, argp, sizeof(attr)))
+			return -EFAULT;
+		return kvm_arm_vcpu_has_attr(vcpu, &attr);
+	}
 	default:
 		return -EINVAL;
 	}
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index cf4f28a..9677bf0 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -81,6 +81,7 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
 		r = kvm_arm_support_pmu_v3();
 		break;
 	case KVM_CAP_SET_GUEST_DEBUG:
+	case KVM_CAP_VCPU_ATTRIBUTES:
 		r = 1;
 		break;
 	default:
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index dc16d30..50f44a2 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -851,6 +851,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_HYPERV_SYNIC 123
 #define KVM_CAP_S390_RI 124
 #define KVM_CAP_ARM_PMU_V3 125
+#define KVM_CAP_VCPU_ATTRIBUTES 126
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:06 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:06 +0800
Subject: [PATCH v11 11/21] KVM: ARM64: Add access handler for PMINTENSET and
 PMINTENCLR register
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-12-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Since the reset value of PMINTENSET and PMINTENCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMINTENSET or PMINTENCLR register.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/kvm/sys_regs.c | 32 ++++++++++++++++++++++++++++----
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index ef8012a..bf8d170 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -626,6 +626,30 @@ static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			   const struct sys_reg_desc *r)
+{
+	u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write) {
+		u64 val = p->regval & mask;
+
+		if (r->Op2 & 0x1)
+			/* accessing PMINTENSET_EL1 */
+			vcpu_sys_reg(vcpu, PMINTENSET_EL1) |= val;
+		else
+			/* accessing PMINTENCLR_EL1 */
+			vcpu_sys_reg(vcpu, PMINTENSET_EL1) &= ~val;
+	} else {
+		p->regval = vcpu_sys_reg(vcpu, PMINTENSET_EL1) & mask;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -784,10 +808,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 
 	/* PMINTENSET_EL1 */
 	{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b001),
-	  trap_raz_wi },
+	  access_pminten, reset_unknown, PMINTENSET_EL1 },
 	/* PMINTENCLR_EL1 */
 	{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b010),
-	  trap_raz_wi },
+	  access_pminten, NULL, PMINTENSET_EL1 },
 
 	/* MAIR_EL1 */
 	{ Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0010), Op2(0b000),
@@ -1182,8 +1206,8 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
+	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
 
 	{ Op1( 0), CRn(10), CRm( 2), Op2( 0), access_vm_reg, NULL, c10_PRRR },
 	{ Op1( 0), CRn(10), CRm( 2), Op2( 1), access_vm_reg, NULL, c10_NMRR },
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:03 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:03 +0800
Subject: [PATCH v11 08/21] KVM: ARM64: Add access handler for event type
 register
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-9-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
which is mapped to PMEVTYPERn or PMCCFILTR.

The access handler translates all aarch32 register offsets to aarch64
ones and uses vcpu_sys_reg() to access their values to avoid taking care
of big endian.

When writing to these registers, create a perf_event for the selected
event type.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/kvm/sys_regs.c | 140 +++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 138 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 06257e2..298ae94 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -513,6 +513,54 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
+{
+	u64 pmcr, val;
+
+	pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
+	val = (pmcr >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
+	if (idx >= val && idx != ARMV8_CYCLE_IDX)
+		return false;
+
+	return true;
+}
+
+static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			       const struct sys_reg_desc *r)
+{
+	u64 idx, reg;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (r->CRn == 9 && r->CRm == 13 && r->Op2 == 1) {
+		/* PMXEVTYPER_EL0 */
+		idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
+		reg = PMEVTYPER0_EL0 + idx;
+	} else if (r->CRn == 14 && (r->CRm & 12) == 12) {
+		idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+		if (idx == ARMV8_CYCLE_IDX)
+			reg = PMCCFILTR_EL0;
+		else
+			/* PMEVTYPERn_EL0 */
+			reg = PMEVTYPER0_EL0 + idx;
+	} else {
+		BUG();
+	}
+
+	if (!pmu_counter_idx_valid(vcpu, idx))
+		return false;
+
+	if (p->is_write) {
+		kvm_pmu_set_counter_event_type(vcpu, p->regval, idx);
+		vcpu_sys_reg(vcpu, reg) = p->regval & ARMV8_EVTYPE_MASK;
+	} else {
+		p->regval = vcpu_sys_reg(vcpu, reg) & ARMV8_EVTYPE_MASK;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -528,6 +576,13 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	{ Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111),	\
 	  trap_wcr, reset_wcr, n, 0,  get_wcr, set_wcr }
 
+/* Macro to expand the PMEVTYPERn_EL0 register */
+#define PMU_PMEVTYPER_EL0(n)						\
+	/* PMEVTYPERn_EL0 */						\
+	{ Op0(0b11), Op1(0b011), CRn(0b1110),				\
+	  CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)),		\
+	  access_pmu_evtyper, reset_unknown, (PMEVTYPER0_EL0 + n), }
+
 /*
  * Architected system registers.
  * Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
@@ -724,7 +779,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  trap_raz_wi },
 	/* PMXEVTYPER_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
-	  trap_raz_wi },
+	  access_pmu_evtyper },
 	/* PMXEVCNTR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
 	  trap_raz_wi },
@@ -742,6 +797,45 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
 	  NULL, reset_unknown, TPIDRRO_EL0 },
 
+	/* PMEVTYPERn_EL0 */
+	PMU_PMEVTYPER_EL0(0),
+	PMU_PMEVTYPER_EL0(1),
+	PMU_PMEVTYPER_EL0(2),
+	PMU_PMEVTYPER_EL0(3),
+	PMU_PMEVTYPER_EL0(4),
+	PMU_PMEVTYPER_EL0(5),
+	PMU_PMEVTYPER_EL0(6),
+	PMU_PMEVTYPER_EL0(7),
+	PMU_PMEVTYPER_EL0(8),
+	PMU_PMEVTYPER_EL0(9),
+	PMU_PMEVTYPER_EL0(10),
+	PMU_PMEVTYPER_EL0(11),
+	PMU_PMEVTYPER_EL0(12),
+	PMU_PMEVTYPER_EL0(13),
+	PMU_PMEVTYPER_EL0(14),
+	PMU_PMEVTYPER_EL0(15),
+	PMU_PMEVTYPER_EL0(16),
+	PMU_PMEVTYPER_EL0(17),
+	PMU_PMEVTYPER_EL0(18),
+	PMU_PMEVTYPER_EL0(19),
+	PMU_PMEVTYPER_EL0(20),
+	PMU_PMEVTYPER_EL0(21),
+	PMU_PMEVTYPER_EL0(22),
+	PMU_PMEVTYPER_EL0(23),
+	PMU_PMEVTYPER_EL0(24),
+	PMU_PMEVTYPER_EL0(25),
+	PMU_PMEVTYPER_EL0(26),
+	PMU_PMEVTYPER_EL0(27),
+	PMU_PMEVTYPER_EL0(28),
+	PMU_PMEVTYPER_EL0(29),
+	PMU_PMEVTYPER_EL0(30),
+	/* PMCCFILTR_EL0
+	 * This register resets as unknown in 64bit mode while it resets as zero
+	 * in 32bit mode. Here we choose to reset it as zero for consistency.
+	 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1110), CRm(0b1111), Op2(0b111),
+	  access_pmu_evtyper, reset_val, PMCCFILTR_EL0, 0 },
+
 	/* DACR32_EL2 */
 	{ Op0(0b11), Op1(0b100), CRn(0b0011), CRm(0b0000), Op2(0b000),
 	  NULL, reset_unknown, DACR32_EL2 },
@@ -931,6 +1025,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
 	{ Op1( 0), CRm( 2), .access = trap_raz_wi },
 };
 
+/* Macro to expand the PMEVTYPERn register */
+#define PMU_PMEVTYPER(n)						\
+	/* PMEVTYPERn */						\
+	{ Op1(0), CRn(0b1110),						\
+	  CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)),		\
+	  access_pmu_evtyper }
+
 /*
  * Trapped cp15 registers. TTBR0/TTBR1 get a double encoding,
  * depending on the way they are accessed (as a 32bit or a 64bit
@@ -967,7 +1068,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
@@ -982,6 +1083,41 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn(12), CRm(12), Op2( 5), trap_raz_wi },
 
 	{ Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
+
+	/* PMEVTYPERn */
+	PMU_PMEVTYPER(0),
+	PMU_PMEVTYPER(1),
+	PMU_PMEVTYPER(2),
+	PMU_PMEVTYPER(3),
+	PMU_PMEVTYPER(4),
+	PMU_PMEVTYPER(5),
+	PMU_PMEVTYPER(6),
+	PMU_PMEVTYPER(7),
+	PMU_PMEVTYPER(8),
+	PMU_PMEVTYPER(9),
+	PMU_PMEVTYPER(10),
+	PMU_PMEVTYPER(11),
+	PMU_PMEVTYPER(12),
+	PMU_PMEVTYPER(13),
+	PMU_PMEVTYPER(14),
+	PMU_PMEVTYPER(15),
+	PMU_PMEVTYPER(16),
+	PMU_PMEVTYPER(17),
+	PMU_PMEVTYPER(18),
+	PMU_PMEVTYPER(19),
+	PMU_PMEVTYPER(20),
+	PMU_PMEVTYPER(21),
+	PMU_PMEVTYPER(22),
+	PMU_PMEVTYPER(23),
+	PMU_PMEVTYPER(24),
+	PMU_PMEVTYPER(25),
+	PMU_PMEVTYPER(26),
+	PMU_PMEVTYPER(27),
+	PMU_PMEVTYPER(28),
+	PMU_PMEVTYPER(29),
+	PMU_PMEVTYPER(30),
+	/* PMCCFILTR */
+	{ Op1(0), CRn(14), CRm(15), Op2(7), access_pmu_evtyper },
 };
 
 static const struct sys_reg_desc cp15_64_regs[] = {
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:05 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:05 +0800
Subject: [PATCH v11 10/21] KVM: ARM64: Add access handler for PMCNTENSET and
 PMCNTENCLR register
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-11-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Since the reset value of PMCNTENSET and PMCNTENCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMCNTENSET or PMCNTENCLR register.

When writing to PMCNTENSET, call perf_event_enable to enable the perf
event. When writing to PMCNTENCLR, call perf_event_disable to disable
the perf event.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
---
 arch/arm64/kvm/sys_regs.c | 35 ++++++++++++++++++++++---
 include/kvm/arm_pmu.h     |  9 +++++++
 virt/kvm/arm/pmu.c        | 66 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 106 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 0304c99..ef8012a 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -599,6 +599,33 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
 	return true;
 }
 
+static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			   const struct sys_reg_desc *r)
+{
+	u64 val, mask;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	mask = kvm_pmu_valid_counter_mask(vcpu);
+	if (p->is_write) {
+		val = p->regval & mask;
+		if (r->Op2 & 0x1) {
+			/* accessing PMCNTENSET_EL0 */
+			vcpu_sys_reg(vcpu, PMCNTENSET_EL0) |= val;
+			kvm_pmu_enable_counter(vcpu, val);
+		} else {
+			/* accessing PMCNTENCLR_EL0 */
+			vcpu_sys_reg(vcpu, PMCNTENSET_EL0) &= ~val;
+			kvm_pmu_disable_counter(vcpu, val);
+		}
+	} else {
+		p->regval = vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & mask;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -800,10 +827,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmcr, reset_pmcr, },
 	/* PMCNTENSET_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
-	  trap_raz_wi },
+	  access_pmcnten, reset_unknown, PMCNTENSET_EL0 },
 	/* PMCNTENCLR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b010),
-	  trap_raz_wi },
+	  access_pmcnten, NULL, PMCNTENSET_EL0 },
 	/* PMOVSCLR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
 	  trap_raz_wi },
@@ -1145,8 +1172,8 @@ static const struct sys_reg_desc cp15_regs[] = {
 
 	/* PMU */
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 8e57243..cda9d06 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -40,6 +40,9 @@ struct kvm_pmu {
 #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
 u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
 void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
+u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
+void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 #else
@@ -54,6 +57,12 @@ static inline u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu,
 }
 static inline void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu,
 					     u64 select_idx, u64 val) {}
+static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
+{
+	return 0;
+}
+static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 0d8a732..82ee8a26 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -83,6 +83,72 @@ static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
 	}
 }
 
+u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
+{
+	u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMCR_N_SHIFT;
+
+	val &= ARMV8_PMCR_N_MASK;
+	if (val == 0)
+		return BIT(ARMV8_CYCLE_IDX);
+	else
+		return GENMASK(val - 1, 0) | BIT(ARMV8_CYCLE_IDX);
+}
+
+/**
+ * kvm_pmu_enable_counter - enable selected PMU counter
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCNTENSET register
+ *
+ * Call perf_event_enable to start counting the perf event
+ */
+void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val)
+{
+	int i;
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_pmc *pmc;
+
+	if (!(vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) || !val)
+		return;
+
+	for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+		if (!(val & BIT(i)))
+			continue;
+
+		pmc = &pmu->pmc[i];
+		if (pmc->perf_event) {
+			perf_event_enable(pmc->perf_event);
+			if (pmc->perf_event->state != PERF_EVENT_STATE_ACTIVE)
+				kvm_debug("fail to enable perf event\n");
+		}
+	}
+}
+
+/**
+ * kvm_pmu_disable_counter - disable selected PMU counter
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCNTENCLR register
+ *
+ * Call perf_event_disable to stop counting the perf event
+ */
+void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
+{
+	int i;
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_pmc *pmc;
+
+	if (!val)
+		return;
+
+	for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+		if (!(val & BIT(i)))
+			continue;
+
+		pmc = &pmu->pmc[i];
+		if (pmc->perf_event)
+			perf_event_disable(pmc->perf_event);
+	}
+}
+
 static bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu, u64 select_idx)
 {
 	return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) &&
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:04 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:04 +0800
Subject: [PATCH v11 09/21] KVM: ARM64: Add access handler for event counter
 register
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-10-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

These kind of registers include PMEVCNTRn, PMCCNTR and PMXEVCNTR which
is mapped to PMEVCNTRn.

The access handler translates all aarch32 register offsets to aarch64
ones and uses vcpu_sys_reg() to access their values to avoid taking care
of big endian.

When reading these registers, return the sum of register value and the
value perf event counts.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/kvm/sys_regs.c | 125 ++++++++++++++++++++++++++++++++++++++++++++--
 include/kvm/arm_pmu.h     |   3 ++
 virt/kvm/arm/pmu.c        |  15 ++++++
 3 files changed, 139 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 298ae94..0304c99 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -561,6 +561,44 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
+			      struct sys_reg_params *p,
+			      const struct sys_reg_desc *r)
+{
+	u64 idx;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (r->CRn == 9 && r->CRm == 13) {
+		if (r->Op2 == 2) {
+			/* PMXEVCNTR_EL0 */
+			idx = vcpu_sys_reg(vcpu, PMSELR_EL0)
+			      & ARMV8_COUNTER_MASK;
+		} else if (r->Op2 == 0) {
+			/* PMCCNTR_EL0 */
+			idx = ARMV8_CYCLE_IDX;
+		} else {
+			BUG();
+		}
+	} else if (r->CRn == 14 && (r->CRm & 12) == 8) {
+		/* PMEVCNTRn_EL0 */
+		idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+	} else {
+		BUG();
+	}
+
+	if (!pmu_counter_idx_valid(vcpu, idx))
+		return false;
+
+	if (p->is_write)
+		kvm_pmu_set_counter_value(vcpu, idx, p->regval);
+	else
+		p->regval = kvm_pmu_get_counter_value(vcpu, idx);
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -576,6 +614,13 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	{ Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111),	\
 	  trap_wcr, reset_wcr, n, 0,  get_wcr, set_wcr }
 
+/* Macro to expand the PMEVCNTRn_EL0 register */
+#define PMU_PMEVCNTR_EL0(n)						\
+	/* PMEVCNTRn_EL0 */						\
+	{ Op0(0b11), Op1(0b011), CRn(0b1110),				\
+	  CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)),		\
+	  access_pmu_evcntr, reset_unknown, (PMEVCNTR0_EL0 + n), }
+
 /* Macro to expand the PMEVTYPERn_EL0 register */
 #define PMU_PMEVTYPER_EL0(n)						\
 	/* PMEVTYPERn_EL0 */						\
@@ -776,13 +821,13 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmceid },
 	/* PMCCNTR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
-	  trap_raz_wi },
+	  access_pmu_evcntr, reset_unknown, PMCCNTR_EL0 },
 	/* PMXEVTYPER_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
 	  access_pmu_evtyper },
 	/* PMXEVCNTR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
-	  trap_raz_wi },
+	  access_pmu_evcntr },
 	/* PMUSERENR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
 	  trap_raz_wi },
@@ -797,6 +842,38 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
 	  NULL, reset_unknown, TPIDRRO_EL0 },
 
+	/* PMEVCNTRn_EL0 */
+	PMU_PMEVCNTR_EL0(0),
+	PMU_PMEVCNTR_EL0(1),
+	PMU_PMEVCNTR_EL0(2),
+	PMU_PMEVCNTR_EL0(3),
+	PMU_PMEVCNTR_EL0(4),
+	PMU_PMEVCNTR_EL0(5),
+	PMU_PMEVCNTR_EL0(6),
+	PMU_PMEVCNTR_EL0(7),
+	PMU_PMEVCNTR_EL0(8),
+	PMU_PMEVCNTR_EL0(9),
+	PMU_PMEVCNTR_EL0(10),
+	PMU_PMEVCNTR_EL0(11),
+	PMU_PMEVCNTR_EL0(12),
+	PMU_PMEVCNTR_EL0(13),
+	PMU_PMEVCNTR_EL0(14),
+	PMU_PMEVCNTR_EL0(15),
+	PMU_PMEVCNTR_EL0(16),
+	PMU_PMEVCNTR_EL0(17),
+	PMU_PMEVCNTR_EL0(18),
+	PMU_PMEVCNTR_EL0(19),
+	PMU_PMEVCNTR_EL0(20),
+	PMU_PMEVCNTR_EL0(21),
+	PMU_PMEVCNTR_EL0(22),
+	PMU_PMEVCNTR_EL0(23),
+	PMU_PMEVCNTR_EL0(24),
+	PMU_PMEVCNTR_EL0(25),
+	PMU_PMEVCNTR_EL0(26),
+	PMU_PMEVCNTR_EL0(27),
+	PMU_PMEVCNTR_EL0(28),
+	PMU_PMEVCNTR_EL0(29),
+	PMU_PMEVCNTR_EL0(30),
 	/* PMEVTYPERn_EL0 */
 	PMU_PMEVTYPER_EL0(0),
 	PMU_PMEVTYPER_EL0(1),
@@ -1025,6 +1102,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
 	{ Op1( 0), CRm( 2), .access = trap_raz_wi },
 };
 
+/* Macro to expand the PMEVCNTRn register */
+#define PMU_PMEVCNTR(n)							\
+	/* PMEVCNTRn */							\
+	{ Op1(0), CRn(0b1110),						\
+	  CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)),		\
+	  access_pmu_evcntr }
+
 /* Macro to expand the PMEVTYPERn register */
 #define PMU_PMEVTYPER(n)						\
 	/* PMEVTYPERn */						\
@@ -1067,9 +1151,9 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
-	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), access_pmu_evcntr },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
-	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), trap_raz_wi },
@@ -1084,6 +1168,38 @@ static const struct sys_reg_desc cp15_regs[] = {
 
 	{ Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
 
+	/* PMEVCNTRn */
+	PMU_PMEVCNTR(0),
+	PMU_PMEVCNTR(1),
+	PMU_PMEVCNTR(2),
+	PMU_PMEVCNTR(3),
+	PMU_PMEVCNTR(4),
+	PMU_PMEVCNTR(5),
+	PMU_PMEVCNTR(6),
+	PMU_PMEVCNTR(7),
+	PMU_PMEVCNTR(8),
+	PMU_PMEVCNTR(9),
+	PMU_PMEVCNTR(10),
+	PMU_PMEVCNTR(11),
+	PMU_PMEVCNTR(12),
+	PMU_PMEVCNTR(13),
+	PMU_PMEVCNTR(14),
+	PMU_PMEVCNTR(15),
+	PMU_PMEVCNTR(16),
+	PMU_PMEVCNTR(17),
+	PMU_PMEVCNTR(18),
+	PMU_PMEVCNTR(19),
+	PMU_PMEVCNTR(20),
+	PMU_PMEVCNTR(21),
+	PMU_PMEVCNTR(22),
+	PMU_PMEVCNTR(23),
+	PMU_PMEVCNTR(24),
+	PMU_PMEVCNTR(25),
+	PMU_PMEVCNTR(26),
+	PMU_PMEVCNTR(27),
+	PMU_PMEVCNTR(28),
+	PMU_PMEVCNTR(29),
+	PMU_PMEVCNTR(30),
 	/* PMEVTYPERn */
 	PMU_PMEVTYPER(0),
 	PMU_PMEVTYPER(1),
@@ -1122,6 +1238,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 
 static const struct sys_reg_desc cp15_64_regs[] = {
 	{ Op1( 0), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR0 },
+	{ Op1( 0), CRn( 0), CRm( 9), Op2( 0), access_pmu_evcntr },
 	{ Op1( 0), CRn( 0), CRm(12), Op2( 0), access_gic_sgi },
 	{ Op1( 1), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR1 },
 };
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 0295d4f..8e57243 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -39,6 +39,7 @@ struct kvm_pmu {
 
 #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
 u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
+void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 #else
@@ -51,6 +52,8 @@ static inline u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu,
 {
 	return 0;
 }
+static inline void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu,
+					     u64 select_idx, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index df36120..0d8a732 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -48,6 +48,21 @@ u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
 }
 
 /**
+ * kvm_pmu_set_counter_value - set PMU counter value
+ * @vcpu: The vcpu pointer
+ * @select_idx: The counter index
+ * @val: The counter value
+ */
+void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val)
+{
+	u64 reg;
+
+	reg = (select_idx == ARMV8_CYCLE_IDX)
+	      ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + select_idx;
+	vcpu_sys_reg(vcpu, reg) += (s64)val - kvm_pmu_get_counter_value(vcpu, select_idx);
+}
+
+/**
  * kvm_pmu_stop_counter - stop PMU counter
  * @pmc: The PMU counter pointer
  *
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:16 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:16 +0800
Subject: [PATCH v11 21/21] KVM: ARM64: Add a new vcpu device control group for
 PMUv3
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-22-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

To configure the virtual PMUv3 overflow interrupt number, we use the
vcpu kvm_device ioctl, encapsulating the KVM_ARM_VCPU_PMU_V3_IRQ
attribute within the KVM_ARM_VCPU_PMU_V3_CTRL group.

After configuring the PMUv3, call the vcpu ioctl with attribute
KVM_ARM_VCPU_PMU_V3_INIT to initialize the PMUv3.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Peter Maydell <peter.maydell at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
CC: Peter Maydell <peter.maydell at linaro.org>
---
 Documentation/virtual/kvm/devices/vcpu.txt |  24 ++++++
 arch/arm/include/asm/kvm_host.h            |  15 ++++
 arch/arm/kvm/arm.c                         |   3 +
 arch/arm64/include/asm/kvm_host.h          |   6 ++
 arch/arm64/include/uapi/asm/kvm.h          |   5 ++
 arch/arm64/kvm/guest.c                     |  51 ++++++++++++
 include/kvm/arm_pmu.h                      |  23 ++++++
 virt/kvm/arm/pmu.c                         | 128 +++++++++++++++++++++++++++++
 8 files changed, 255 insertions(+)

diff --git a/Documentation/virtual/kvm/devices/vcpu.txt b/Documentation/virtual/kvm/devices/vcpu.txt
index 3cc59c5..d626237 100644
--- a/Documentation/virtual/kvm/devices/vcpu.txt
+++ b/Documentation/virtual/kvm/devices/vcpu.txt
@@ -6,3 +6,27 @@ KVM_GET_DEVICE_ATTR, and KVM_HAS_DEVICE_ATTR. The interface uses the same struct
 kvm_device_attr as other devices, but targets VCPU-wide settings and controls.
 
 The groups and attributes per virtual cpu, if any, are architecture specific.
+
+1. GROUP: KVM_ARM_VCPU_PMU_V3_CTRL
+Architectures: ARM64
+
+1.1. ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_IRQ
+Parameters: in kvm_device_attr.addr the address for PMU overflow interrupt
+Returns: -EBUSY: The PMU overflow interrupt is already set
+         -ENXIO: The overflow interrupt not set when attempting to get it
+         -ENODEV: PMUv3 not supported
+         -EINVAL: Invalid PMU overflow interrupt number supplied
+
+A value describing the PMUv3 (Performance Monitor Unit v3) overflow interrupt
+number for this vcpu. This interrupt could be a PPI or SPI, but the interrupt
+type must be same for each vcpu. As a PPI, the interrupt number is same for all
+vcpus, while as an SPI it must be different for each vcpu.
+
+1.2 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_INIT
+Parameters: no additional parameter in kvm_device_attr.addr
+Returns: -ENODEV: PMUv3 not supported
+         -ENXIO: PMUv3 not properly configured as required prior to calling this
+                 attribute
+         -EBUSY: PMUv3 already initialized
+
+Request the initialization of the PMUv3.
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index f9f2779..6dd0992 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -242,5 +242,20 @@ static inline void kvm_arm_init_debug(void) {}
 static inline void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) {}
 static inline void kvm_arm_clear_debug(struct kvm_vcpu *vcpu) {}
 static inline void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu) {}
+static inline int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
+					     struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
+static inline int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
+					     struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
+static inline int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
+					     struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
 
 #endif /* __ARM_KVM_HOST_H__ */
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 34d7395..dc8644f 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -833,6 +833,7 @@ static int kvm_arm_vcpu_set_attr(struct kvm_vcpu *vcpu,
 
 	switch (attr->group) {
 	default:
+		ret = kvm_arm_vcpu_arch_set_attr(vcpu, attr);
 		break;
 	}
 
@@ -846,6 +847,7 @@ static int kvm_arm_vcpu_get_attr(struct kvm_vcpu *vcpu,
 
 	switch (attr->group) {
 	default:
+		ret = kvm_arm_vcpu_arch_get_attr(vcpu, attr);
 		break;
 	}
 
@@ -859,6 +861,7 @@ static int kvm_arm_vcpu_has_attr(struct kvm_vcpu *vcpu,
 
 	switch (attr->group) {
 	default:
+		ret = kvm_arm_vcpu_arch_has_attr(vcpu, attr);
 		break;
 	}
 
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index cb220b7..a855a30 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -359,5 +359,11 @@ void kvm_arm_init_debug(void);
 void kvm_arm_setup_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_clear_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu);
+int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr);
+int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr);
+int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr);
 
 #endif /* __ARM64_KVM_HOST_H__ */
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 6aedbe3..f209ea1 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -205,6 +205,11 @@ struct kvm_arch_memory_slot {
 #define KVM_DEV_ARM_VGIC_GRP_CTRL	4
 #define   KVM_DEV_ARM_VGIC_CTRL_INIT	0
 
+/* Device Control API on vcpu fd */
+#define KVM_ARM_VCPU_PMU_V3_CTRL	0
+#define   KVM_ARM_VCPU_PMU_V3_IRQ	0
+#define   KVM_ARM_VCPU_PMU_V3_INIT	1
+
 /* KVM_IRQ_LINE irq field index values */
 #define KVM_ARM_IRQ_TYPE_SHIFT		24
 #define KVM_ARM_IRQ_TYPE_MASK		0xff
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index fcb7788..dbe45c3 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -380,3 +380,54 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
 	}
 	return 0;
 }
+
+int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr)
+{
+	int ret;
+
+	switch (attr->group) {
+	case KVM_ARM_VCPU_PMU_V3_CTRL:
+		ret = kvm_arm_pmu_v3_set_attr(vcpu, attr);
+		break;
+	default:
+		ret = -ENXIO;
+		break;
+	}
+
+	return ret;
+}
+
+int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr)
+{
+	int ret;
+
+	switch (attr->group) {
+	case KVM_ARM_VCPU_PMU_V3_CTRL:
+		ret = kvm_arm_pmu_v3_get_attr(vcpu, attr);
+		break;
+	default:
+		ret = -ENXIO;
+		break;
+	}
+
+	return ret;
+}
+
+int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr)
+{
+	int ret;
+
+	switch (attr->group) {
+	case KVM_ARM_VCPU_PMU_V3_CTRL:
+		ret = kvm_arm_pmu_v3_has_attr(vcpu, attr);
+		break;
+	default:
+		ret = -ENXIO;
+		break;
+	}
+
+	return ret;
+}
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 5f86e1d..f09abf6 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -38,6 +38,7 @@ struct kvm_pmu {
 };
 
 #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
+#define kvm_arm_pmu_irq_initialized(v)	((v)->arch.pmu.irq_num >= VGIC_NR_SGIS)
 u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
 void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
@@ -52,11 +53,18 @@ void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 bool kvm_arm_support_pmu_v3(void);
+int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu,
+			    struct kvm_device_attr *attr);
+int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu,
+			    struct kvm_device_attr *attr);
+int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu,
+			    struct kvm_device_attr *attr);
 #else
 struct kvm_pmu {
 };
 
 #define kvm_arm_pmu_v3_ready(v)		(false)
+#define kvm_arm_pmu_irq_initialized(v)	(false)
 static inline u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu,
 					    u64 select_idx)
 {
@@ -79,6 +87,21 @@ static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 static inline bool kvm_arm_support_pmu_v3(void) { return false; }
+static inline int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu,
+					  struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
+static inline int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu,
+					  struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
+static inline int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu,
+					  struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
 #endif
 
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 2467d62..06b7cb3 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -19,6 +19,7 @@
 #include <linux/kvm.h>
 #include <linux/kvm_host.h>
 #include <linux/perf_event.h>
+#include <linux/uaccess.h>
 #include <asm/kvm_emulate.h>
 #include <kvm/arm_pmu.h>
 #include <kvm/arm_vgic.h>
@@ -393,3 +394,130 @@ bool kvm_arm_support_pmu_v3(void)
 	 */
 	return (perf_num_counters() > 0);
 }
+
+static int kvm_arm_pmu_v3_init(struct kvm_vcpu *vcpu)
+{
+	if (!kvm_arm_support_pmu_v3())
+		return -ENODEV;
+
+	if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features) ||
+	    !kvm_arm_pmu_irq_initialized(vcpu))
+		return -ENXIO;
+
+	if (kvm_arm_pmu_v3_ready(vcpu))
+		return -EBUSY;
+
+	kvm_pmu_vcpu_reset(vcpu);
+	vcpu->arch.pmu.ready = true;
+
+	return 0;
+}
+
+static int kvm_arm_pmu_irq_access(struct kvm_vcpu *vcpu,
+				  struct kvm_device_attr *attr,
+				  int *irq, bool is_set)
+{
+	if (!is_set) {
+		if (!kvm_arm_pmu_irq_initialized(vcpu))
+			return -ENXIO;
+
+		*irq = vcpu->arch.pmu.irq_num;
+	} else {
+		if (kvm_arm_pmu_irq_initialized(vcpu))
+			return -EBUSY;
+
+		kvm_debug("Set kvm ARM PMU irq: %d\n", *irq);
+		vcpu->arch.pmu.irq_num = *irq;
+	}
+
+	return 0;
+}
+
+static bool irq_is_valid(struct kvm *kvm, int irq, bool is_ppi)
+{
+	int i;
+	struct kvm_vcpu *vcpu;
+
+	kvm_for_each_vcpu(i, vcpu, kvm) {
+		if (!kvm_arm_pmu_irq_initialized(vcpu))
+			continue;
+
+		if (is_ppi) {
+			if (vcpu->arch.pmu.irq_num != irq)
+				return false;
+		} else {
+			if (vcpu->arch.pmu.irq_num == irq)
+				return false;
+		}
+	}
+
+	return true;
+}
+
+
+int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
+{
+	switch (attr->attr) {
+	case KVM_ARM_VCPU_PMU_V3_IRQ: {
+		int __user *uaddr = (int __user *)(long)attr->addr;
+		int reg;
+
+		if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
+			return -ENODEV;
+
+		if (get_user(reg, uaddr))
+			return -EFAULT;
+
+		/*
+		 * The PMU overflow interrupt could be a PPI or SPI, but for one
+		 * VM the interrupt type must be same for each vcpu. As a PPI,
+		 * the interrupt number is same for all vcpus, while as an SPI
+		 * it must be different for each vcpu.
+		 */
+		if (reg < VGIC_NR_SGIS || reg >= vcpu->kvm->arch.vgic.nr_irqs ||
+		    !irq_is_valid(vcpu->kvm, reg, reg < VGIC_NR_PRIVATE_IRQS))
+			return -EINVAL;
+
+		return kvm_arm_pmu_irq_access(vcpu, attr, &reg, true);
+	}
+	case KVM_ARM_VCPU_PMU_V3_INIT:
+		return kvm_arm_pmu_v3_init(vcpu);
+	}
+
+	return -ENXIO;
+}
+
+int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
+{
+	int ret;
+
+	switch (attr->attr) {
+	case KVM_ARM_VCPU_PMU_V3_IRQ: {
+		int __user *uaddr = (int __user *)(long)attr->addr;
+		int reg = -1;
+
+		if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
+			return -ENODEV;
+
+		ret = kvm_arm_pmu_irq_access(vcpu, attr, &reg, false);
+		if (ret)
+			return ret;
+		return put_user(reg, uaddr);
+	}
+	}
+
+	return -ENXIO;
+}
+
+int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
+{
+	switch (attr->attr) {
+	case KVM_ARM_VCPU_PMU_V3_IRQ:
+	case KVM_ARM_VCPU_PMU_V3_INIT:
+		if (kvm_arm_support_pmu_v3() &&
+		    test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
+			return 0;
+	}
+
+	return -ENXIO;
+}
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:07 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:07 +0800
Subject: [PATCH v11 12/21] KVM: ARM64: Add access handler for PMOVSSET and
 PMOVSCLR register
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-13-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Since the reset value of PMOVSSET and PMOVSCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMOVSSET or PMOVSCLR register.

When writing non-zero value to PMOVSSET, the counter and its interrupt
is enabled, kick this vcpu to sync PMU interrupt.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/kvm/sys_regs.c | 29 ++++++++++++++++++++++++++---
 include/kvm/arm_pmu.h     |  2 ++
 virt/kvm/arm/pmu.c        | 30 ++++++++++++++++++++++++++++++
 3 files changed, 58 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index bf8d170..2ee4f1e 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -650,6 +650,28 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			 const struct sys_reg_desc *r)
+{
+	u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write) {
+		if (r->CRm & 0x2)
+			/* accessing PMOVSSET_EL0 */
+			kvm_pmu_overflow_set(vcpu, p->regval & mask);
+		else
+			/* accessing PMOVSCLR_EL0 */
+			vcpu_sys_reg(vcpu, PMOVSSET_EL0) &= ~(p->regval & mask);
+	} else {
+		p->regval = vcpu_sys_reg(vcpu, PMOVSSET_EL0) & mask;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -857,7 +879,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmcnten, NULL, PMCNTENSET_EL0 },
 	/* PMOVSCLR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
-	  trap_raz_wi },
+	  access_pmovs, NULL, PMOVSSET_EL0 },
 	/* PMSWINC_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
 	  trap_raz_wi },
@@ -884,7 +906,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  trap_raz_wi },
 	/* PMOVSSET_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
-	  trap_raz_wi },
+	  access_pmovs, reset_unknown, PMOVSSET_EL0 },
 
 	/* TPIDR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b010),
@@ -1198,7 +1220,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
@@ -1208,6 +1230,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
+	{ Op1( 0), CRn( 9), CRm(14), Op2( 3), access_pmovs },
 
 	{ Op1( 0), CRn(10), CRm( 2), Op2( 0), access_vm_reg, NULL, c10_PRRR },
 	{ Op1( 0), CRn(10), CRm( 2), Op2( 1), access_vm_reg, NULL, c10_NMRR },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index cda9d06..967175a 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -43,6 +43,7 @@ void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 #else
@@ -63,6 +64,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 }
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 82ee8a26..f6e45af 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -149,6 +149,36 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
 	}
 }
 
+static u64 kvm_pmu_overflow_status(struct kvm_vcpu *vcpu)
+{
+	u64 reg;
+
+	reg = vcpu_sys_reg(vcpu, PMOVSSET_EL0);
+	reg &= vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
+	reg &= vcpu_sys_reg(vcpu, PMINTENSET_EL1);
+	reg &= kvm_pmu_valid_counter_mask(vcpu);
+
+	return reg;
+}
+
+/**
+ * kvm_pmu_overflow_set - set PMU overflow interrupt
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMOVSSET register
+ */
+void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
+{
+	u64 reg;
+
+	if (val == 0)
+		return;
+
+	vcpu_sys_reg(vcpu, PMOVSSET_EL0) |= val;
+	reg = kvm_pmu_overflow_status(vcpu);
+	if (reg != 0)
+		kvm_vcpu_kick(vcpu);
+}
+
 static bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu, u64 select_idx)
 {
 	return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) &&
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:09 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:09 +0800
Subject: [PATCH v11 14/21] KVM: ARM64: Add helper to handle PMCR register bits
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-15-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

According to ARMv8 spec, when writing 1 to PMCR.E, all counters are
enabled by PMCNTENSET, while writing 0 to PMCR.E, all counters are
disabled. When writing 1 to PMCR.P, reset all event counters, not
including PMCCNTR, to zero. When writing 1 to PMCR.C, reset PMCCNTR to
zero.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/sys_regs.c |  1 +
 include/kvm/arm_pmu.h     |  2 ++
 virt/kvm/arm/pmu.c        | 34 ++++++++++++++++++++++++++++++++++
 3 files changed, 37 insertions(+)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index ab8e86a..c792b56 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -467,6 +467,7 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 		val &= ~ARMV8_PMCR_MASK;
 		val |= p->regval & ARMV8_PMCR_MASK;
 		vcpu_sys_reg(vcpu, PMCR_EL0) = val;
+		kvm_pmu_handle_pmcr(vcpu, val);
 	} else {
 		/* PMCR.P & PMCR.C are RAZ */
 		val = vcpu_sys_reg(vcpu, PMCR_EL0)
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index e4bd068..1f4bfa2 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -45,6 +45,7 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 #else
@@ -67,6 +68,7 @@ static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 2bba792..c8ea825 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -208,6 +208,40 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
 	}
 }
 
+/**
+ * kvm_pmu_handle_pmcr - handle PMCR register
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCR register
+ */
+void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val)
+{
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_pmc *pmc;
+	u64 mask;
+	int i;
+
+	mask = kvm_pmu_valid_counter_mask(vcpu);
+	if (val & ARMV8_PMCR_E) {
+		kvm_pmu_enable_counter(vcpu,
+				vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & mask);
+	} else {
+		kvm_pmu_disable_counter(vcpu, mask);
+	}
+
+	if (val & ARMV8_PMCR_C)
+		kvm_pmu_set_counter_value(vcpu, ARMV8_CYCLE_IDX, 0);
+
+	if (val & ARMV8_PMCR_P) {
+		for (i = 0; i < ARMV8_CYCLE_IDX; i++)
+			kvm_pmu_set_counter_value(vcpu, i, 0);
+	}
+
+	if (val & ARMV8_PMCR_LC) {
+		pmc = &pmu->pmc[ARMV8_CYCLE_IDX];
+		pmc->bitmask = 0xffffffffffffffffUL;
+	}
+}
+
 static bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu, u64 select_idx)
 {
 	return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) &&
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:01 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:01 +0800
Subject: [PATCH v11 06/21] KVM: ARM64: Add access handler for PMCEID0 and
 PMCEID1 register
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-7-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Add access handler which gets host value of PMCEID0 or PMCEID1 when
guest access these registers. Writing action to PMCEID0 or PMCEID1 is
UNDEFINED.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
---
 arch/arm64/kvm/sys_regs.c | 29 +++++++++++++++++++++++++----
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index fc60041..06257e2 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -492,6 +492,27 @@ static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			  const struct sys_reg_desc *r)
+{
+	u64 pmceid;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write)
+		return false;
+
+	if (!(p->Op2 & 1))
+		asm volatile("mrs %0, pmceid0_el0\n" : "=r" (pmceid));
+	else
+		asm volatile("mrs %0, pmceid1_el0\n" : "=r" (pmceid));
+
+	p->regval = pmceid;
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -694,10 +715,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmselr, reset_unknown, PMSELR_EL0 },
 	/* PMCEID0_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
-	  trap_raz_wi },
+	  access_pmceid },
 	/* PMCEID1_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b111),
-	  trap_raz_wi },
+	  access_pmceid },
 	/* PMCCNTR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
 	  trap_raz_wi },
@@ -943,8 +964,8 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:08 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:08 +0800
Subject: [PATCH v11 13/21] KVM: ARM64: Add access handler for PMSWINC register
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-14-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Add access handler which emulates writing and reading PMSWINC
register and add support for creating software increment event.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/pmu.h |  2 ++
 arch/arm64/kvm/sys_regs.c    | 20 +++++++++++++++++++-
 include/kvm/arm_pmu.h        |  2 ++
 virt/kvm/arm/pmu.c           | 33 +++++++++++++++++++++++++++++++++
 4 files changed, 56 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
index e6b9e32..478f77e 100644
--- a/arch/arm64/include/asm/pmu.h
+++ b/arch/arm64/include/asm/pmu.h
@@ -59,6 +59,8 @@
 #define	ARMV8_EVTYPE_MASK	0xc80003ff	/* Mask for writable bits */
 #define	ARMV8_EVTYPE_EVENT	0x3ff		/* Mask for EVENT bits */
 
+#define ARMV8_EVTYPE_EVENT_SW_INCR	0	/* Software increment event */
+
 /*
  * Event filters for PMUv3
  */
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 2ee4f1e..ab8e86a 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -672,6 +672,23 @@ static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			   const struct sys_reg_desc *r)
+{
+	u64 mask;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write) {
+		mask = kvm_pmu_valid_counter_mask(vcpu);
+		kvm_pmu_software_increment(vcpu, p->regval & mask);
+		return true;
+	}
+
+	return false;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -882,7 +899,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmovs, NULL, PMOVSSET_EL0 },
 	/* PMSWINC_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
-	  trap_raz_wi },
+	  access_pmswinc, reset_unknown, PMSWINC_EL0 },
 	/* PMSELR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
 	  access_pmselr, reset_unknown, PMSELR_EL0 },
@@ -1221,6 +1238,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 4), access_pmswinc },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 967175a..e4bd068 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -44,6 +44,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 #else
@@ -65,6 +66,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index f6e45af..2bba792 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -179,6 +179,35 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
 		kvm_vcpu_kick(vcpu);
 }
 
+/**
+ * kvm_pmu_software_increment - do software increment
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMSWINC register
+ */
+void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
+{
+	int i;
+	u64 type, enable, reg;
+
+	if (val == 0)
+		return;
+
+	enable = vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
+	for (i = 0; i < ARMV8_CYCLE_IDX; i++) {
+		if (!(val & BIT(i)))
+			continue;
+		type = vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i)
+		       & ARMV8_EVTYPE_EVENT;
+		if ((type == ARMV8_EVTYPE_EVENT_SW_INCR) && (enable & BIT(i))) {
+			reg = vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
+			reg = lower_32_bits(reg);
+			vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = reg;
+			if (!reg)
+				kvm_pmu_overflow_set(vcpu, BIT(i));
+		}
+	}
+}
+
 static bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu, u64 select_idx)
 {
 	return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) &&
@@ -207,6 +236,10 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 	kvm_pmu_stop_counter(vcpu, pmc);
 	eventsel = data & ARMV8_EVTYPE_EVENT;
 
+	/* Software increment event does't need to be backed by a perf event */
+	if (eventsel == ARMV8_EVTYPE_EVENT_SW_INCR)
+		return;
+
 	memset(&attr, 0, sizeof(struct perf_event_attr));
 	attr.type = PERF_TYPE_RAW;
 	attr.size = sizeof(attr);
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:10 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:10 +0800
Subject: [PATCH v11 15/21] KVM: ARM64: Add access handler for PMUSERENR
 register
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-16-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

This register resets as unknown in 64bit mode while it resets as zero
in 32bit mode. Here we choose to reset it as zero for consistency.

PMUSERENR_EL0 holds some bits which decide whether PMU registers can be
accessed from EL0. Add some check helpers to handle the access from EL0.

When these bits are zero, only reading PMUSERENR will trap to EL2 and
writing PMUSERENR or reading/writing other PMU registers will trap to
EL1 other than EL2 when HCR.TGE==0. To current KVM configuration
(HCR.TGE==0) there is no way to get these traps. Here we write 0xf to
physical PMUSERENR register on VM entry, so that it will trap PMU access
from EL0 to EL2. Within the register access handler we check the real
value of guest PMUSERENR register to decide whether this access is
allowed. If not allowed, return false to inject UND to guest.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
---
 arch/arm64/include/asm/pmu.h |   9 ++++
 arch/arm64/kvm/hyp/hyp.h     |   1 +
 arch/arm64/kvm/hyp/switch.c  |   3 ++
 arch/arm64/kvm/sys_regs.c    | 100 ++++++++++++++++++++++++++++++++++++++++---
 4 files changed, 107 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
index 478f77e..c6b384c 100644
--- a/arch/arm64/include/asm/pmu.h
+++ b/arch/arm64/include/asm/pmu.h
@@ -68,4 +68,13 @@
 #define	ARMV8_EXCLUDE_EL0	(1 << 30)
 #define	ARMV8_INCLUDE_EL2	(1 << 27)
 
+/*
+ * PMUSERENR: user enable reg
+ */
+#define ARMV8_USERENR_MASK	0xf		/* Mask for writable bits */
+#define ARMV8_USERENR_EN	(1 << 0) /* PMU regs can be accessed at EL0 */
+#define ARMV8_USERENR_SW	(1 << 1) /* PMSWINC can be written at EL0 */
+#define ARMV8_USERENR_CR	(1 << 2) /* Cycle counter can be read at EL0 */
+#define ARMV8_USERENR_ER	(1 << 3) /* Event counter can be read at EL0 */
+
 #endif /* __ASM_PMU_H */
diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
index fb27517..9a28b7bd8 100644
--- a/arch/arm64/kvm/hyp/hyp.h
+++ b/arch/arm64/kvm/hyp/hyp.h
@@ -22,6 +22,7 @@
 #include <linux/kvm_host.h>
 #include <asm/kvm_mmu.h>
 #include <asm/sysreg.h>
+#include <asm/pmu.h>
 
 #define __hyp_text __section(.hyp.text) notrace
 
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index ca8f5a5..1a7d679 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -37,6 +37,8 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
 	/* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
 	write_sysreg(1 << 15, hstr_el2);
 	write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
+	/* Make sure we trap PMU access from EL0 to EL2 */
+	write_sysreg(ARMV8_USERENR_MASK, pmuserenr_el0);
 	write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
 }
 
@@ -45,6 +47,7 @@ static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
 	write_sysreg(HCR_RW, hcr_el2);
 	write_sysreg(0, hstr_el2);
 	write_sysreg(read_sysreg(mdcr_el2) & MDCR_EL2_HPMN_MASK, mdcr_el2);
+	write_sysreg(0, pmuserenr_el0);
 	write_sysreg(0, cptr_el2);
 }
 
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index c792b56..fa0690d 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -453,6 +453,37 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
 	vcpu_sys_reg(vcpu, PMCR_EL0) = val;
 }
 
+static bool pmu_access_el0_disabled(struct kvm_vcpu *vcpu)
+{
+	u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+	return !((reg & ARMV8_USERENR_EN) || vcpu_mode_priv(vcpu));
+}
+
+static bool pmu_write_swinc_el0_disabled(struct kvm_vcpu *vcpu)
+{
+	u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+	return !((reg & (ARMV8_USERENR_SW | ARMV8_USERENR_EN))
+		 || vcpu_mode_priv(vcpu));
+}
+
+static bool pmu_access_cycle_counter_el0_disabled(struct kvm_vcpu *vcpu)
+{
+	u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+	return !((reg & (ARMV8_USERENR_CR | ARMV8_USERENR_EN))
+		 || vcpu_mode_priv(vcpu));
+}
+
+static bool pmu_access_event_counter_el0_disabled(struct kvm_vcpu *vcpu)
+{
+	u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+	return !((reg & (ARMV8_USERENR_ER | ARMV8_USERENR_EN))
+		 || vcpu_mode_priv(vcpu));
+}
+
 static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 			const struct sys_reg_desc *r)
 {
@@ -461,6 +492,9 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_access_el0_disabled(vcpu))
+		return false;
+
 	if (p->is_write) {
 		/* Only update writeable bits of PMCR */
 		val = vcpu_sys_reg(vcpu, PMCR_EL0);
@@ -484,6 +518,9 @@ static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_access_event_counter_el0_disabled(vcpu))
+		return false;
+
 	if (p->is_write)
 		vcpu_sys_reg(vcpu, PMSELR_EL0) = p->regval;
 	else
@@ -501,7 +538,7 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
-	if (p->is_write)
+	if (p->is_write || pmu_access_el0_disabled(vcpu))
 		return false;
 
 	if (!(p->Op2 & 1))
@@ -534,6 +571,9 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_access_el0_disabled(vcpu))
+		return false;
+
 	if (r->CRn == 9 && r->CRm == 13 && r->Op2 == 1) {
 		/* PMXEVTYPER_EL0 */
 		idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
@@ -574,16 +614,25 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
 	if (r->CRn == 9 && r->CRm == 13) {
 		if (r->Op2 == 2) {
 			/* PMXEVCNTR_EL0 */
+			if (pmu_access_event_counter_el0_disabled(vcpu))
+				return false;
+
 			idx = vcpu_sys_reg(vcpu, PMSELR_EL0)
 			      & ARMV8_COUNTER_MASK;
 		} else if (r->Op2 == 0) {
 			/* PMCCNTR_EL0 */
+			if (pmu_access_cycle_counter_el0_disabled(vcpu))
+				return false;
+
 			idx = ARMV8_CYCLE_IDX;
 		} else {
 			BUG();
 		}
 	} else if (r->CRn == 14 && (r->CRm & 12) == 8) {
 		/* PMEVCNTRn_EL0 */
+		if (pmu_access_event_counter_el0_disabled(vcpu))
+			return false;
+
 		idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
 	} else {
 		BUG();
@@ -592,10 +641,14 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
 	if (!pmu_counter_idx_valid(vcpu, idx))
 		return false;
 
-	if (p->is_write)
+	if (p->is_write) {
+		if (pmu_access_el0_disabled(vcpu))
+			return false;
+
 		kvm_pmu_set_counter_value(vcpu, idx, p->regval);
-	else
+	} else {
 		p->regval = kvm_pmu_get_counter_value(vcpu, idx);
+	}
 
 	return true;
 }
@@ -608,6 +661,9 @@ static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_access_el0_disabled(vcpu))
+		return false;
+
 	mask = kvm_pmu_valid_counter_mask(vcpu);
 	if (p->is_write) {
 		val = p->regval & mask;
@@ -635,6 +691,9 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (!vcpu_mode_priv(vcpu))
+		return false;
+
 	if (p->is_write) {
 		u64 val = p->regval & mask;
 
@@ -659,6 +718,9 @@ static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_access_el0_disabled(vcpu))
+		return false;
+
 	if (p->is_write) {
 		if (r->CRm & 0x2)
 			/* accessing PMOVSSET_EL0 */
@@ -681,6 +743,9 @@ static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_write_swinc_el0_disabled(vcpu))
+		return false;
+
 	if (p->is_write) {
 		mask = kvm_pmu_valid_counter_mask(vcpu);
 		kvm_pmu_software_increment(vcpu, p->regval & mask);
@@ -690,6 +755,26 @@ static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return false;
 }
 
+static bool access_pmuserenr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			     const struct sys_reg_desc *r)
+{
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write) {
+		if (!vcpu_mode_priv(vcpu))
+			return false;
+
+		vcpu_sys_reg(vcpu, PMUSERENR_EL0) = p->regval
+						    & ARMV8_USERENR_MASK;
+	} else {
+		p->regval = vcpu_sys_reg(vcpu, PMUSERENR_EL0)
+			    & ARMV8_USERENR_MASK;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -919,9 +1004,12 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	/* PMXEVCNTR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
 	  access_pmu_evcntr },
-	/* PMUSERENR_EL0 */
+	/* PMUSERENR_EL0
+	 * This register resets as unknown in 64bit mode while it resets as zero
+	 * in 32bit mode. Here we choose to reset it as zero for consistency.
+	 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
-	  trap_raz_wi },
+	  access_pmuserenr, reset_val, PMUSERENR_EL0, 0 },
 	/* PMOVSSET_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
 	  access_pmovs, reset_unknown, PMOVSSET_EL0 },
@@ -1246,7 +1334,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), access_pmu_evcntr },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
-	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), access_pmuserenr },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 3), access_pmovs },
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:02 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:02 +0800
Subject: [PATCH v11 07/21] KVM: ARM64: PMU: Add perf event map and introduce
 perf event creating function
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-8-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When we use tools like perf on host, perf passes the event type and the
id of this event type category to kernel, then kernel will map them to
hardware event number and write this number to PMU PMEVTYPER<n>_EL0
register. When getting the event number in KVM, directly use raw event
type to create a perf_event for it.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/pmu.h |   2 +
 arch/arm64/kvm/Makefile      |   1 +
 include/kvm/arm_pmu.h        |  12 +++++
 virt/kvm/arm/pmu.c           | 122 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 137 insertions(+)
 create mode 100644 virt/kvm/arm/pmu.c

diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
index 4406184..e6b9e32 100644
--- a/arch/arm64/include/asm/pmu.h
+++ b/arch/arm64/include/asm/pmu.h
@@ -31,6 +31,8 @@
 #define ARMV8_PMCR_D		(1 << 3) /* CCNT counts every 64th cpu cycle */
 #define ARMV8_PMCR_X		(1 << 4) /* Export to ETM */
 #define ARMV8_PMCR_DP		(1 << 5) /* Disable CCNT if non-invasive debug*/
+/* Determines which PMCCNTR_EL0 bit generates an overflow */
+#define ARMV8_PMCR_LC		(1 << 6)
 #define	ARMV8_PMCR_N_SHIFT	11	 /* Number of counters supported */
 #define	ARMV8_PMCR_N_MASK	0x1f
 #define	ARMV8_PMCR_MASK		0x3f	 /* Mask for writable bits */
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index caee9ee..122cff4 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -26,3 +26,4 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v2-emul.o
 kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3.o
 kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3-emul.o
 kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
+kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 32fee2d..0295d4f 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -23,6 +23,8 @@
 #include <linux/perf_event.h>
 #include <asm/pmu.h>
 
+#define ARMV8_CYCLE_IDX		(ARMV8_MAX_COUNTERS - 1)
+
 struct kvm_pmc {
 	u8 idx;/* index into the pmu->pmc array */
 	struct perf_event *perf_event;
@@ -36,11 +38,21 @@ struct kvm_pmu {
 };
 
 #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
+u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
+void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
+				    u64 select_idx);
 #else
 struct kvm_pmu {
 };
 
 #define kvm_arm_pmu_v3_ready(v)		(false)
+static inline u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu,
+					    u64 select_idx)
+{
+	return 0;
+}
+static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
+						  u64 data, u64 select_idx) {}
 #endif
 
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
new file mode 100644
index 0000000..df36120
--- /dev/null
+++ b/virt/kvm/arm/pmu.c
@@ -0,0 +1,122 @@
+/*
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Shannon Zhao <shannon.zhao at linaro.org>
+ *
+ * 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/cpu.h>
+#include <linux/kvm.h>
+#include <linux/kvm_host.h>
+#include <linux/perf_event.h>
+#include <asm/kvm_emulate.h>
+#include <kvm/arm_pmu.h>
+
+/**
+ * kvm_pmu_get_counter_value - get PMU counter value
+ * @vcpu: The vcpu pointer
+ * @select_idx: The counter index
+ */
+u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
+{
+	u64 counter, reg, enabled, running;
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_pmc *pmc = &pmu->pmc[select_idx];
+
+	reg = (select_idx == ARMV8_CYCLE_IDX)
+	      ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + select_idx;
+	counter = vcpu_sys_reg(vcpu, reg);
+
+	/* The real counter value is equal to the value of counter register plus
+	 * the value perf event counts.
+	 */
+	if (pmc->perf_event)
+		counter += perf_event_read_value(pmc->perf_event, &enabled,
+						 &running);
+
+	return counter & pmc->bitmask;
+}
+
+/**
+ * kvm_pmu_stop_counter - stop PMU counter
+ * @pmc: The PMU counter pointer
+ *
+ * If this counter has been configured to monitor some event, release it here.
+ */
+static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
+{
+	u64 counter, reg;
+
+	if (pmc->perf_event) {
+		counter = kvm_pmu_get_counter_value(vcpu, pmc->idx);
+		reg = (pmc->idx == ARMV8_CYCLE_IDX)
+		       ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + pmc->idx;
+		vcpu_sys_reg(vcpu, reg) = counter;
+		perf_event_disable(pmc->perf_event);
+		perf_event_release_kernel(pmc->perf_event);
+		pmc->perf_event = NULL;
+	}
+}
+
+static bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu, u64 select_idx)
+{
+	return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E) &&
+	       (vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & BIT(select_idx));
+}
+
+/**
+ * kvm_pmu_set_counter_event_type - set selected counter to monitor some event
+ * @vcpu: The vcpu pointer
+ * @data: The data guest writes to PMXEVTYPER_EL0
+ * @select_idx: The number of selected counter
+ *
+ * When OS accesses PMXEVTYPER_EL0, that means it wants to set a PMC to count an
+ * event with given hardware event number. Here we call perf_event API to
+ * emulate this action and create a kernel perf event for it.
+ */
+void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
+				    u64 select_idx)
+{
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_pmc *pmc = &pmu->pmc[select_idx];
+	struct perf_event *event;
+	struct perf_event_attr attr;
+	u64 eventsel, counter;
+
+	kvm_pmu_stop_counter(vcpu, pmc);
+	eventsel = data & ARMV8_EVTYPE_EVENT;
+
+	memset(&attr, 0, sizeof(struct perf_event_attr));
+	attr.type = PERF_TYPE_RAW;
+	attr.size = sizeof(attr);
+	attr.pinned = 1;
+	attr.disabled = !kvm_pmu_counter_is_enabled(vcpu, select_idx);
+	attr.exclude_user = data & ARMV8_EXCLUDE_EL0 ? 1 : 0;
+	attr.exclude_kernel = data & ARMV8_EXCLUDE_EL1 ? 1 : 0;
+	attr.exclude_hv = 1; /* Don't count EL2 events */
+	attr.exclude_host = 1; /* Don't count host events */
+	attr.config = eventsel;
+
+	counter = kvm_pmu_get_counter_value(vcpu, select_idx);
+	/* The initial sample period (overflow count) of an event. */
+	attr.sample_period = (-counter) & pmc->bitmask;
+
+	event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
+	if (IS_ERR(event)) {
+		pr_err_once("kvm: pmu event creation failed %ld\n",
+			    PTR_ERR(event));
+		return;
+	}
+
+	pmc->perf_event = event;
+}
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:13 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:13 +0800
Subject: [PATCH v11 18/21] KVM: ARM64: Free perf event of PMU when destroying
 vcpu
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-19-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When KVM frees VCPU, it needs to free the perf_event of PMU.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm/kvm/arm.c    |  1 +
 include/kvm/arm_pmu.h |  2 ++
 virt/kvm/arm/pmu.c    | 21 +++++++++++++++++++++
 3 files changed, 24 insertions(+)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index f54264c..d2c2cc3 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -266,6 +266,7 @@ void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
 	kvm_mmu_free_memory_caches(vcpu);
 	kvm_timer_vcpu_terminate(vcpu);
 	kvm_vgic_vcpu_destroy(vcpu);
+	kvm_pmu_vcpu_destroy(vcpu);
 	kmem_cache_free(kvm_vcpu_cache, vcpu);
 }
 
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 191908c..d73cb97 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -42,6 +42,7 @@ u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
 void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
 void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu);
+void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
@@ -67,6 +68,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 	return 0;
 }
 static inline void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu) {}
+static inline void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu) {}
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 3ea9a89..6b525df 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -101,6 +101,27 @@ void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu)
 	}
 }
 
+/**
+ * kvm_pmu_vcpu_destroy - free perf event of PMU for cpu
+ * @vcpu: The vcpu pointer
+ *
+ */
+void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu)
+{
+	int i;
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+	for (i = 0; i < ARMV8_MAX_COUNTERS; i++) {
+		struct kvm_pmc *pmc = &pmu->pmc[i];
+
+		if (pmc->perf_event) {
+			perf_event_disable(pmc->perf_event);
+			perf_event_release_kernel(pmc->perf_event);
+			pmc->perf_event = NULL;
+		}
+	}
+}
+
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 {
 	u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMCR_N_SHIFT;
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:13:55 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:13:55 +0800
Subject: [PATCH v11 00/21] KVM: ARM64: Add guest PMU support
Message-ID: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

This patchset adds guest PMU support for KVM on ARM64. It takes
trap-and-emulate approach. When guest wants to monitor one event, it
will be trapped by KVM and KVM will call perf_event API to create a perf
event and call relevant perf_event APIs to get the count value of event.

Use perf to test this patchset in guest. When using "perf list", it
shows the list of the hardware events and hardware cache events perf
supports. Then use "perf stat -e EVENT" to monitor some event. For
example, use "perf stat -e cycles" to count cpu cycles and
"perf stat -e cache-misses" to count cache misses.

Below are the outputs of "perf stat -r 5 sleep 5" when running in host
and guest.

Host:
 Performance counter stats for 'sleep 5' (5 runs):

          0.529248      task-clock (msec)         #    0.000 CPUs utilized            ( +-  1.65% )
                 1      context-switches          #    0.002 M/sec
                 0      cpu-migrations            #    0.000 K/sec
                49      page-faults               #    0.092 M/sec                    ( +-  1.05% )
           1104279      cycles                    #    2.087 GHz                      ( +-  1.65% )
   <not supported>      stalled-cycles-frontend
   <not supported>      stalled-cycles-backend
            528112      instructions              #    0.48  insns per cycle          ( +-  1.12% )
   <not supported>      branches
              9579      branch-misses             #   18.099 M/sec                    ( +-  2.40% )

       5.000851904 seconds time elapsed                                          ( +-  0.00% )

Guest:
 Performance counter stats for 'sleep 5' (5 runs):

          0.695412      task-clock (msec)         #    0.000 CPUs utilized            ( +-  1.26% )
                 1      context-switches          #    0.001 M/sec
                 0      cpu-migrations            #    0.000 K/sec
                49      page-faults               #    0.070 M/sec                    ( +-  1.29% )
           1430471      cycles                    #    2.057 GHz                      ( +-  1.25% )
   <not supported>      stalled-cycles-frontend
   <not supported>      stalled-cycles-backend
            659173      instructions              #    0.46  insns per cycle          ( +-  2.64% )
   <not supported>      branches
             10893      branch-misses             #   15.664 M/sec                    ( +-  1.23% )

       5.001277044 seconds time elapsed                                          ( +-  0.00% )

Have a cycle counter read test like below in guest and host:

static void test(void)
{
	unsigned long count, count1, count2;
	count1 = read_cycles();
	count++;
	count2 = read_cycles();
}

Host:
count1: 3046505444
count2: 3046505575
delta: 131

Guest:
count1: 5932773531
count2: 5932773668
delta: 137

The gap between guest and host is very small. One reason for this I
think is that it doesn't count the cycles in EL2 and host since we add
exclude_hv = 1. So the cycles spent to store/restore registers which
happens at EL2 are not included.

This patchset can be fetched from [1] and the relevant QEMU version for
test can be fetched from [2].

The results of 'perf test' can be found from [3][4].
The results of perf_event_tests test suite can be found from [5][6].

Also, I have tested "perf top" in two VMs and host at the same time. It
works well.

Thanks,
Shannon

[1] https://git.linaro.org/people/shannon.zhao/linux-mainline.git  KVM_ARM64_PMU_v11
[2] https://git.linaro.org/people/shannon.zhao/qemu.git  PMU
[3] http://people.linaro.org/~shannon.zhao/PMU/perf-test-host.txt
[4] http://people.linaro.org/~shannon.zhao/PMU/perf-test-guest.txt
[5] http://people.linaro.org/~shannon.zhao/PMU/perf_event_tests-host.txt
[6] http://people.linaro.org/~shannon.zhao/PMU/perf_event_tests-guest.txt

Changes since v10:
* Check if PMCR.N is zero before using GENMASK
* Fix attr.disabled
* use same way to reset counter's value in PATCH 14

Changes since v9:
* Change kvm_arm_support_pmu_v3 to a bool function [PATCH 19/21]
* Fix several typoes, change checking logic of kvm_arm_pmu_v3_init and
  change irq_is_invalid to irq_is_valid [PATCH 21/21]
* Add Acks and Rb from Peter and Andrew, thanks a lot

Changes since v8:
* Fix the wrong use of r->reg in register accessors for 32bit part
* Rewrite the handle of PMUSERENR based on the new inject UND patch
* Drop the inline attribute
* Introduce SET/GET/HAS_DEVICE_ATTR for vcpu iotcl and set the PMU
  overflow interrupt via this API
* Use one feature bit for PMUv3

Changes since v7:
* Rebase on kvm-arm next
* Fix the handler of PMUSERENR and add a helper to forward trap to guest
  EL1
* Fix some small bugs found by Marc

Changes since v6:
* Rebase on v4.4-rc5
* Drop access_pmu_cp15_regs() so that it could use same handler for both
  arch64 and arch32. And it could drop the definitions of CP15 register
  offsets, also avoid same codes added twice
* Use vcpu_sys_reg() when accessing PMU registers to avoid endian things
* Add handler for PMUSERENR and some checkers for other registers
* Add kvm_arm_pmu_get_attr()

Changes since v5:
* Rebase on new linux kernel mainline
* Remove state duplications and drop PMOVSCLR, PMCNTENCLR, PMINTENCLR,
  PMXEVCNTR, PMXEVTYPER
* Add a helper to check if vPMU is already initialized
* remove kvm_vcpu from kvm_pmc

Changes since v4:
* Rebase on new linux kernel mainline 
* Drop the reset handler of CP15 registers
* Fix a compile failure on arch ARM due to lack of asm/pmu.h
* Refactor the interrupt injecting flow according to Marc's suggestion
* Check the value of PMSELR register
* Calculate the attr.disabled according to PMCR.E and PMCNTENSET/CLR
* Fix some coding style
* Document the vPMU irq range

Changes since v3:
* Rebase on new linux kernel mainline 
* Use ARMV8_MAX_COUNTERS instead of 32
* Reset PMCR.E to zero.
* Trigger overflow for software increment.
* Optimize PMU interrupt inject logic.
* Add handler for E,C,P bits of PMCR
* Fix the overflow bug found by perf_event_tests
* Run 'perf test', 'perf top' and perf_event_tests test suite
* Add exclude_hv = 1 configuration to not count in EL2

Changes since v2:
* Directly use perf raw event type to create perf_event in KVM
* Add a helper vcpu_sysreg_write
* remove unrelated header file

Changes since v1:
* Use switch...case for registers access handler instead of adding
  alone handler for each register
* Try to use the sys_regs to store the register value instead of adding
  new variables in struct kvm_pmc
* Fix the handle of cp15 regs
* Create a new kvm device vPMU, then userspace could choose whether to
  create PMU
* Fix the handle of PMU overflow interrupt

Shannon Zhao (21):
  ARM64: Move PMU register related defines to asm/pmu.h
  KVM: ARM64: Define PMU data structure for each vcpu
  KVM: ARM64: Add offset defines for PMU registers
  KVM: ARM64: Add access handler for PMCR register
  KVM: ARM64: Add access handler for PMSELR register
  KVM: ARM64: Add access handler for PMCEID0 and PMCEID1 register
  KVM: ARM64: PMU: Add perf event map and introduce perf event creating
    function
  KVM: ARM64: Add access handler for event type register
  KVM: ARM64: Add access handler for event counter register
  KVM: ARM64: Add access handler for PMCNTENSET and PMCNTENCLR register
  KVM: ARM64: Add access handler for PMINTENSET and PMINTENCLR register
  KVM: ARM64: Add access handler for PMOVSSET and PMOVSCLR register
  KVM: ARM64: Add access handler for PMSWINC register
  KVM: ARM64: Add helper to handle PMCR register bits
  KVM: ARM64: Add access handler for PMUSERENR register
  KVM: ARM64: Add PMU overflow interrupt routing
  KVM: ARM64: Reset PMU state when resetting vcpu
  KVM: ARM64: Free perf event of PMU when destroying vcpu
  KVM: ARM64: Add a new feature bit for PMUv3
  KVM: ARM: Introduce per-vcpu kvm device controls
  KVM: ARM64: Add a new vcpu device control group for PMUv3

 Documentation/virtual/kvm/api.txt          |  12 +-
 Documentation/virtual/kvm/devices/vcpu.txt |  32 ++
 arch/arm/include/asm/kvm_host.h            |  15 +
 arch/arm/kvm/arm.c                         |  61 ++++
 arch/arm64/include/asm/kvm_host.h          |  25 +-
 arch/arm64/include/asm/pmu.h               |  80 ++++
 arch/arm64/include/uapi/asm/kvm.h          |   6 +
 arch/arm64/kernel/perf_event.c             |  36 +-
 arch/arm64/kvm/Kconfig                     |   7 +
 arch/arm64/kvm/Makefile                    |   1 +
 arch/arm64/kvm/guest.c                     |  51 +++
 arch/arm64/kvm/hyp/hyp.h                   |   1 +
 arch/arm64/kvm/hyp/switch.c                |   3 +
 arch/arm64/kvm/reset.c                     |   7 +
 arch/arm64/kvm/sys_regs.c                  | 566 +++++++++++++++++++++++++++--
 include/kvm/arm_pmu.h                      | 107 ++++++
 include/uapi/linux/kvm.h                   |   2 +
 virt/kvm/arm/pmu.c                         | 523 ++++++++++++++++++++++++++
 18 files changed, 1466 insertions(+), 69 deletions(-)
 create mode 100644 Documentation/virtual/kvm/devices/vcpu.txt
 create mode 100644 arch/arm64/include/asm/pmu.h
 create mode 100644 include/kvm/arm_pmu.h
 create mode 100644 virt/kvm/arm/pmu.c

-- 
2.0.4




From boris.brezillon at free-electrons.com  Thu Feb  4 23:35:18 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 5 Feb 2016 08:35:18 +0100
Subject: [PATCH v2 05/51] mtd: add mtd_ooblayout_xxx() helper functions
In-Reply-To: <1454580434-32078-6-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
 <1454580434-32078-6-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <20160205083518.7b54e9a7@bbrezillon>

On Thu,  4 Feb 2016 11:06:28 +0100
Boris Brezillon <boris.brezillon at free-electrons.com> wrote:

> In order to make the ecclayout definition completely dynamic we need to
> rework the way the OOB layout are defined and iterated.
> 
> Create a few mtd_ooblayout_xxx() helpers to ease OOB bytes manipulation
> and hide ecclayout internals to their users.
> 
> Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
> ---
>  drivers/mtd/mtdcore.c   | 401 ++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/mtd/mtd.h |  33 ++++
>  2 files changed, 434 insertions(+)
> 
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 3096251..14e46ca 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c

[...]

> +
> +/**
> + * mtd_ooblayout_count_bytes - count the number of bytes in a OOB category
> + * @mtd: mtd info structure
> + * @iter: category iterator
> + *
> + * Count the number of bytes in a given category.
> + *
> + * Returns a positive value on success, a negative error code otherwise.
> + */
> +static int mtd_ooblayout_count_bytes(struct mtd_info *mtd,
> +				int (*iter)(struct mtd_info *,
> +					    int section,
> +					    struct mtd_oob_region *oobregion))
> +{
> +	struct mtd_oob_region oobregion = { };
> +	int section = 0, ret, nbytes = 0;
> +
> +	while (1) {
> +		ret = iter(mtd, section, &oobregion);

				^ section++

Oops, will fix that in next version.

> +		if (ret) {
> +			if (ret == -ERANGE)
> +				ret = nbytes;
> +			break;
> +		}
> +
> +		nbytes += oobregion.length;
> +	}
> +
> +	return ret;
> +}


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


From zhaoshenglong at huawei.com  Thu Feb  4 23:14:11 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:11 +0800
Subject: [PATCH v11 16/21] KVM: ARM64: Add PMU overflow interrupt routing
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-17-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When calling perf_event_create_kernel_counter to create perf_event,
assign a overflow handler. Then when the perf event overflows, set the
corresponding bit of guest PMOVSSET register. If this counter is enabled
and its interrupt is enabled as well, kick the vcpu to sync the
interrupt.

On VM entry, if there is counter overflowed, inject the interrupt with
the level set to 1. Otherwise, inject the interrupt with the level set
to 0.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm/kvm/arm.c    |  2 ++
 include/kvm/arm_pmu.h |  2 ++
 virt/kvm/arm/pmu.c    | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dda1959..f54264c 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -28,6 +28,7 @@
 #include <linux/sched.h>
 #include <linux/kvm.h>
 #include <trace/events/kvm.h>
+#include <kvm/arm_pmu.h>
 
 #define CREATE_TRACE_POINTS
 #include "trace.h"
@@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
 		 * non-preemptible context.
 		 */
 		preempt_disable();
+		kvm_pmu_flush_hwstate(vcpu);
 		kvm_timer_flush_hwstate(vcpu);
 		kvm_vgic_flush_hwstate(vcpu);
 
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 1f4bfa2..44a3c75 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -44,6 +44,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
 void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
@@ -67,6 +68,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
 static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index c8ea825..5f983cb 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -21,6 +21,7 @@
 #include <linux/perf_event.h>
 #include <asm/kvm_emulate.h>
 #include <kvm/arm_pmu.h>
+#include <kvm/arm_vgic.h>
 
 /**
  * kvm_pmu_get_counter_value - get PMU counter value
@@ -180,6 +181,52 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
 }
 
 /**
+ * kvm_pmu_flush_hwstate - flush pmu state to cpu
+ * @vcpu: The vcpu pointer
+ *
+ * Inject virtual PMU IRQ if IRQ is pending for this cpu.
+ */
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
+{
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	u64 overflow;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return;
+
+	if (!(vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E))
+		return;
+
+	overflow = kvm_pmu_overflow_status(vcpu);
+	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id, pmu->irq_num, !!overflow);
+}
+
+static inline struct kvm_vcpu *kvm_pmc_to_vcpu(struct kvm_pmc *pmc)
+{
+	struct kvm_pmu *pmu;
+	struct kvm_vcpu_arch *vcpu_arch;
+
+	pmc -= pmc->idx;
+	pmu = container_of(pmc, struct kvm_pmu, pmc[0]);
+	vcpu_arch = container_of(pmu, struct kvm_vcpu_arch, pmu);
+	return container_of(vcpu_arch, struct kvm_vcpu, arch);
+}
+
+/**
+ * When perf event overflows, call kvm_pmu_overflow_set to set overflow status.
+ */
+static void kvm_pmu_perf_overflow(struct perf_event *perf_event,
+				  struct perf_sample_data *data,
+				  struct pt_regs *regs)
+{
+	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+	struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
+	int idx = pmc->idx;
+
+	kvm_pmu_overflow_set(vcpu, BIT(idx));
+}
+
+/**
  * kvm_pmu_software_increment - do software increment
  * @vcpu: The vcpu pointer
  * @val: the value guest writes to PMSWINC register
@@ -289,7 +336,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 	/* The initial sample period (overflow count) of an event. */
 	attr.sample_period = (-counter) & pmc->bitmask;
 
-	event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
+	event = perf_event_create_kernel_counter(&attr, -1, current,
+						 kvm_pmu_perf_overflow, pmc);
 	if (IS_ERR(event)) {
 		pr_err_once("kvm: pmu event creation failed %ld\n",
 			    PTR_ERR(event));
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:13:59 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:13:59 +0800
Subject: [PATCH v11 04/21] KVM: ARM64: Add access handler for PMCR register
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-5-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Add reset handler which gets host value of PMCR_EL0 and make writable
bits architecturally UNKNOWN except PMCR.E which is zero. Add an access
handler for PMCR.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/kvm/sys_regs.c | 42 ++++++++++++++++++++++++++++++++++++++++--
 include/kvm/arm_pmu.h     |  4 ++++
 2 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index eec3598..97fea84 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -34,6 +34,7 @@
 #include <asm/kvm_emulate.h>
 #include <asm/kvm_host.h>
 #include <asm/kvm_mmu.h>
+#include <asm/pmu.h>
 
 #include <trace/events/kvm.h>
 
@@ -439,6 +440,43 @@ static void reset_mpidr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
 	vcpu_sys_reg(vcpu, MPIDR_EL1) = (1ULL << 31) | mpidr;
 }
 
+static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
+{
+	u64 pmcr, val;
+
+	asm volatile("mrs %0, pmcr_el0\n" : "=r" (pmcr));
+	/* Writable bits of PMCR_EL0 (ARMV8_PMCR_MASK) is reset to UNKNOWN
+	 * except PMCR.E resetting to zero.
+	 */
+	val = ((pmcr & ~ARMV8_PMCR_MASK) | (ARMV8_PMCR_MASK & 0xdecafbad))
+	      & (~ARMV8_PMCR_E);
+	vcpu_sys_reg(vcpu, PMCR_EL0) = val;
+}
+
+static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			const struct sys_reg_desc *r)
+{
+	u64 val;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write) {
+		/* Only update writeable bits of PMCR */
+		val = vcpu_sys_reg(vcpu, PMCR_EL0);
+		val &= ~ARMV8_PMCR_MASK;
+		val |= p->regval & ARMV8_PMCR_MASK;
+		vcpu_sys_reg(vcpu, PMCR_EL0) = val;
+	} else {
+		/* PMCR.P & PMCR.C are RAZ */
+		val = vcpu_sys_reg(vcpu, PMCR_EL0)
+		      & ~(ARMV8_PMCR_P | ARMV8_PMCR_C);
+		p->regval = val;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -623,7 +661,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 
 	/* PMCR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b000),
-	  trap_raz_wi },
+	  access_pmcr, reset_pmcr, },
 	/* PMCNTENSET_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
 	  trap_raz_wi },
@@ -885,7 +923,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 7), CRm(14), Op2( 2), access_dcsw },
 
 	/* PMU */
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 0), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index be220ee..32fee2d 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -34,9 +34,13 @@ struct kvm_pmu {
 	struct kvm_pmc pmc[ARMV8_MAX_COUNTERS];
 	bool ready;
 };
+
+#define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
 #else
 struct kvm_pmu {
 };
+
+#define kvm_arm_pmu_v3_ready(v)		(false)
 #endif
 
 #endif
-- 
2.0.4




From zhaoshenglong at huawei.com  Thu Feb  4 23:14:00 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 5 Feb 2016 15:14:00 +0800
Subject: [PATCH v11 05/21] KVM: ARM64: Add access handler for PMSELR register
In-Reply-To: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1454656456-11640-6-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Since the reset value of PMSELR_EL0 is UNKNOWN, use reset_unknown for
its reset handler. When reading PMSELR, return the PMSELR.SEL field to
guest.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/kvm/sys_regs.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 97fea84..fc60041 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -477,6 +477,21 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			  const struct sys_reg_desc *r)
+{
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write)
+		vcpu_sys_reg(vcpu, PMSELR_EL0) = p->regval;
+	else
+		/* return PMSELR.SEL field */
+		p->regval = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_COUNTER_MASK;
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -676,7 +691,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  trap_raz_wi },
 	/* PMSELR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
-	  trap_raz_wi },
+	  access_pmselr, reset_unknown, PMSELR_EL0 },
 	/* PMCEID0_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
 	  trap_raz_wi },
@@ -927,7 +942,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
-- 
2.0.4




From sricharan at codeaurora.org  Fri Feb  5 00:00:25 2016
From: sricharan at codeaurora.org (Sricharan)
Date: Fri, 5 Feb 2016 13:30:25 +0530
Subject: [PATCH V7 3/6] i2c: qup: Transfer each i2c_msg in i2c_msgs
 without a stop bit
In-Reply-To: <20160204200903.GE1958@tetsubishi>
References: <1453197766-18976-1-git-send-email-sricharan@codeaurora.org>
 <1453197766-18976-4-git-send-email-sricharan@codeaurora.org>
 <20160124112915.GA1775@katana>
 <001401d15988$59f6dcf0$0de496d0$@codeaurora.org>
 <20160204200903.GE1958@tetsubishi>
Message-ID: <006e01d15feb$4a08d0a0$de1a71e0$@codeaurora.org>

Hi Wolfram,

> -----Original Message-----
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> bounces at lists.infradead.org] On Behalf Of Wolfram Sang
> Sent: Friday, February 05, 2016 1:39 AM
> To: Sricharan
> Cc: devicetree at vger.kernel.org; architt at codeaurora.org; linux-arm-
> msm at vger.kernel.org; ntelkar at codeaurora.org; galak at codeaurora.org;
> linux-kernel at vger.kernel.org; andy.gross at linaro.org; linux-
> i2c at vger.kernel.org; iivanov at mm-sol.com; agross at codeaurora.org;
> dmaengine at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH V7 3/6] i2c: qup: Transfer each i2c_msg in i2c_msgs
> without a stop bit
> 
> Hi,
> 
> > Ah, so what I meant above is there is no 'STOP' bit between each msg
> > in i2c_msgs, but 'REAPEATED_START' still holds true.  We are sending
> > 'START' bit for each msg.
> > So these is how each msg in i2c_msg is sent,
> >
> > |------MSG1--------|-----MSG2---------|------MSG3------------|
> >
> >   |START|DATA|------|START|DATA|---|START|DATA|STOP|
> >
> > If my commit text does not make this clear, I  can reword that ?
> 
> OK, now this looks to me perfectly fine: A number of *messages*
> concatenated into one *transfer* by repeated start. That's the way it
should
> be.
> 
> So, I'd simply remove these words:
> 
> "The QUP i2c hardware has no way to inform that there should not be a
> 'STOP' at the end of transaction. The only way to implement this is to
> coalesce all the i2c_msg in i2c_msgs in to one transaction and transfer
them."
> 
> This sounded like the HW needed a special handling, so I was under the
> impression REP_START was broken. However, unless I misunderstood
> something again, this now sounds like the standard case and we can keep
> the commit message simple. If you are okay with that, I can update it
here,
> no need to resend.
> 
      Yes the above modified commit text looks perfect to be updated and
thanks
      for the update as well.

Regards,
 Sricharan



From jayachandran.chandrashekaran at broadcom.com  Fri Feb  5 00:35:37 2016
From: jayachandran.chandrashekaran at broadcom.com (Jayachandran Chandrashekaran Nair)
Date: Fri, 5 Feb 2016 14:05:37 +0530
Subject: [PATCH v7 5/5] PCI: ACPI: Add a generic ACPI based host controller
In-Reply-To: <20160205001907.GJ7031@localhost>
References: <1454058340-7904-1-git-send-email-jchandra@broadcom.com>
 <1454058340-7904-6-git-send-email-jchandra@broadcom.com>
 <20160205001907.GJ7031@localhost>
Message-ID: <CAKc_7PXYtFt1MQE-UGO0O5vvQ+xFKa2b5=F8wXB=EN-JUJVzZw@mail.gmail.com>

Hi Bjorn,

On Fri, Feb 5, 2016 at 5:49 AM, Bjorn Helgaas <helgaas at kernel.org> wrote:
> Hi Jayachandran,
>
> On Fri, Jan 29, 2016 at 02:35:40PM +0530, Jayachandran C wrote:
>> Add a simple ACPI based PCI host controller under config option
>> ACPI_PCI_HOST_GENERIC. This is done by providing an implementation
>> of pci_acpi_scan_root().
>>
>> The pci_mmcfg_list handling is done by the ACPI code, so we keep a
>> reference to the pci_mmcfg_region in sysdata. The ECAM region will
>> be already mapped, so map_bus can be implemented by using the
>> virt pointer for the pci_mmcfg_region. pci_generic_config_read
>> and pci_generic_config_write are used for config space read/write.
>>
>> Also, we provide implementations of raw_pci_read and raw_pci_write
>> hat are needed by ACPI based on the pci_mmcfg_list.
>>
>> pci_acpi_set_companion() and acpi_pci_get_segment() are defined
>> using sysdata of generic ACPI host controller so that PCI domain
>> and ACPI companion are set in PCI code rather than platform code.
>>
>> This code is currently enabled only for ARM64.
>>
>> Signed-off-by: Jayachandran C <jchandra at broadcom.com>
>> ---
>>  drivers/acpi/Kconfig         |   8 ++
>>  drivers/acpi/Makefile        |   1 +
>>  drivers/acpi/pci_host_acpi.c | 186 +++++++++++++++++++++++++++++++++++++++++++
>>  include/linux/pci-acpi.h     |  17 ++++
>>  4 files changed, 212 insertions(+)
>>  create mode 100644 drivers/acpi/pci_host_acpi.c
>
> I'm speaking a little bit out of turn here, because this is ACPI code,
> but I'm confused about pci_host_acpi.c.  We already have pci_root.c,
> which is *supposed* to be arch-independent.  I know pci_root.c is
> crufty and could be improved, but it does work today on x86 and ia64,
> and it handles some generic things that pci_host_acpi.c does not,
> e.g., _OSC, NUMA, host bridge hotplug, etc.
>
> I'd really like to see pci_root.c improved so it could work on x86,
> ia64, and arm64.  I'm sure that was probably the first thing you
> tried, so likely there are issues there.  Are they insurmountable?

pci_root.c leaves the implementation of pci_acpi_scan_root() to the
architecture. Implementing pci_acpi_scan_root needs a
pci_acpi_root_ops instance and a pci_ops instance and related functions.
The architecture is also expected to implement raw_pci_read and
raw_pci_write.

pci_host_acpi.c is a generic implementation of these using a sysdata
pointing to acpi_pci_root_info, and using a pointer to the pci_mmcfg_region
to access ECAM area, Maybe I can rename this file to
pci_acpi_host_generic.c to reflect this better.

arm64 is the only user of this generic implementation now. The config
option CONFIG_ACPI_PCI_HOST_GENERIC has to be set on the
architecture that chooses to use this generic code instead of its own
implementation.

JC.
{Sorry if the formatting is wrong, using webmail due to internal IT changes]


From maxime.ripard at free-electrons.com  Fri Feb  5 00:50:26 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 5 Feb 2016 09:50:26 +0100
Subject: [PATCH 10/11] arm64: dts: add Allwinner A64 SoC .dtsi
In-Reply-To: <1454348370-3816-11-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-11-git-send-email-andre.przywara@arm.com>
Message-ID: <20160205085026.GA1139@lukather>

Hi Andre,

On Mon, Feb 01, 2016 at 05:39:29PM +0000, Andre Przywara wrote:
> The Allwinner A64 SoC is low-cost SoC with 4 ARM Cortex-A53 cores
> and the typical tablet / TV box peripherals.
> The Soc is based on the (32-bit) Allwinner H3 chip, sharing most of
> the peripherals and the memory map.
> Although the cores are proper 64-bit ones, the whole SoC is actually
> limited to 4GB (including all the supported DRAM), so we use 32-bit
> address and size cells. This has the nice feature of us being able to
> reuse the DT for 32-bit kernels as well.
> This .dtsi lists the hardware that we support so far.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  Documentation/devicetree/bindings/arm/sunxi.txt   |   1 +
>  Documentation/devicetree/bindings/clock/sunxi.txt |   1 +
>  arch/arm64/boot/dts/allwinner/a64.dtsi            | 583 ++++++++++++++++++++++
>  3 files changed, 585 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/a64.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
> index 980e065..4a83853 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -14,6 +14,7 @@ using one of the following compatible strings:
>    allwinner,sun8i-a83t
>    allwinner,sun8i-h3
>    allwinner,sun9i-a80
> +  allwinner,a64
>  
>  For Allwinner SoCs without any specific needs the generic fallback value of:
>    allwinner,sunxi
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index e59f57b..44b0c6c 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -77,6 +77,7 @@ Required properties:
>  	"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
>  	"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
>  	"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
> +	"allwinner,a64-bus-gates-clk" - for the A64 multi-parent bus gates clock
>  
>  Required properties for all clocks:
>  - reg : shall be the control register address for the clock.
> diff --git a/arch/arm64/boot/dts/allwinner/a64.dtsi b/arch/arm64/boot/dts/allwinner/a64.dtsi
> new file mode 100644
> index 0000000..8dce10f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/a64.dtsi
> @@ -0,0 +1,583 @@
> +/*
> + * Copyright (C) 2016 ARM Ltd.
> + * based on the Allwinner H3 dtsi:
> + *    Copyright (C) 2015 Jens Kuske <jenskuske at gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This file is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +
> +/ {
> +	compatible = "allwinner,a64", "allwinner,sunxi";
> +	interrupt-parent = <&gic>;
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +
> +	aliases {
> +		serial0 = &uart0;
> +		serial1 = &uart1;
> +		serial2 = &uart2;
> +		serial3 = &uart3;
> +		serial4 = &uart4;
> +	};

The aliases are usually per-board, as it will vary depending on what
the board enables.

> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu at 0 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <0>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu at 1 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <1>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu at 2 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <2>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu at 3 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <3>;
> +			enable-method = "psci";
> +		};
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-0.2", "arm,psci";
> +		method = "smc";
> +		cpu_suspend = <0xc4000001>;
> +		cpu_off = <0x84000002>;
> +		cpu_on = <0xc4000003>;
> +	};

I thought that the function IDs were not needed anymore with PSCI 0.2?


> +	memory {
> +		device_type = "memory";
> +		reg = <0x40000000 0>;
> +	};

I'm guessing u-boot fixes that, can we just remove it entirely?

> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts = <GIC_PPI 13
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 14
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 11
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 10
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> +	};
> +
> +	clocks {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		osc24M: osc24M_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-clock";
> +			clock-frequency = <24000000>;
> +			clock-output-names = "osc24M";
> +		};
> +
> +		osc32k: osc32k_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-clock";
> +			clock-frequency = <32768>;
> +			clock-output-names = "osc32k";
> +		};
> +
> +		pll1: clk at 01c20000 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun8i-a23-pll1-clk";
> +			reg = <0x01c20000 0x4>;
> +			clocks = <&osc24M>;
> +			clock-output-names = "pll1";
> +		};
> +
> +		pll6: clk at 01c20028 {
> +			#clock-cells = <1>;
> +			compatible = "allwinner,sun6i-a31-pll6-clk";
> +			reg = <0x01c20028 0x4>;
> +			clocks = <&osc24M>;
> +			clock-output-names = "pll6", "pll6x2";

The output names have changed, and it doesn't take an argument
anymore.

> +		};
> +
> +		pll6d2: pll6d2_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-factor-clock";
> +			clock-div = <2>;
> +			clock-mult = <1>;
> +			clocks = <&pll6 0>;
> +			clock-output-names = "pll6d2";
> +		};
> +
> +		/* dummy clock until pll6 can be reused */
> +		pll8: pll8_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-clock";
> +			clock-frequency = <1>;
> +			clock-output-names = "pll8";
> +		};
> +
> +		cpu: cpu_clk at 01c20050 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-a10-cpu-clk";
> +			reg = <0x01c20050 0x4>;
> +			clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
> +			clock-output-names = "cpu";
> +			critical-clocks = <0>;
> +		};
> +
> +		axi: axi_clk at 01c20050 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-a10-axi-clk";
> +			reg = <0x01c20050 0x4>;
> +			clocks = <&cpu>;
> +			clock-output-names = "axi";
> +		};
> +
> +		ahb1: ahb1_clk at 01c20054 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun6i-a31-ahb1-clk";
> +			reg = <0x01c20054 0x4>;
> +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
> +			clock-output-names = "ahb1";
> +		};
> +
> +		ahb2: ahb2_clk at 01c2005c {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun8i-h3-ahb2-clk";
> +			reg = <0x01c2005c 0x4>;
> +			clocks = <&ahb1>, <&pll6d2>;
> +			clock-output-names = "ahb2";
> +		};
> +
> +		apb1: apb1_clk at 01c20054 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-a10-apb0-clk";
> +			reg = <0x01c20054 0x4>;
> +			clocks = <&ahb1>;
> +			clock-output-names = "apb1";
> +		};
> +
> +		apb2: apb2_clk at 01c20058 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-a10-apb1-clk";
> +			reg = <0x01c20058 0x4>;
> +			clocks = <&osc32k>, <&osc24M>, <&pll6 1>, <&pll6 1>;
> +			clock-output-names = "apb2";
> +		};
> +
> +		bus_gates: clk at 01c20060 {
> +			#clock-cells = <1>;
> +			compatible = "allwinner,a64-bus-gates-clk",
> +				     "allwinner,sunxi-multi-bus-gates-clk";
> +			reg = <0x01c20060 0x14>;
> +			ahb1_parent {
> +				clocks = <&ahb1>;
> +				clock-indices = <1>, <5>,
> +						<6>, <8>,
> +						<9>, <10>,
> +						<13>, <14>,
> +						<18>, <19>,
> +						<20>, <21>,
> +						<23>, <24>,
> +						<25>, <28>,
> +						<32>, <35>,
> +						<36>, <37>,
> +						<40>, <43>,
> +						<44>, <52>,
> +						<53>, <54>,
> +						<135>;
> +				clock-output-names = "bus_mipidsi", "bus_ce",
> +						"bus_dma", "bus_mmc0",
> +						"bus_mmc1", "bus_mmc2",
> +						"bus_nand", "bus_sdram",
> +						"bus_ts", "bus_hstimer",
> +						"bus_spi0", "bus_spi1",
> +						"bus_otg", "bus_otg_ehci0",
> +						"bus_ehci0", "bus_otg_ohci0",
> +						"bus_ve", "bus_lcd0",
> +						"bus_lcd1", "bus_deint",
> +						"bus_csi", "bus_hdmi",
> +						"bus_de", "bus_gpu",
> +						"bus_msgbox", "bus_spinlock",
> +						"bus_dbg";
> +			};
> +			ahb2_parent {
> +				clocks = <&ahb2>;
> +				clock-indices = <17>, <29>;
> +				clock-output-names = "bus_gmac", "bus_ohci0";
> +			};
> +			apb1_parent {
> +				clocks = <&apb1>;
> +				clock-indices = <64>, <65>,
> +						<69>, <72>,
> +						<76>, <77>,
> +						<78>;
> +				clock-output-names = "bus_codec", "bus_spdif",
> +						"bus_pio", "bus_ths",
> +						"bus_i2s0", "bus_i2s1",
> +						"bus_i2s2";
> +			};
> +			abp2_parent {
> +				clocks = <&apb2>;
> +				clock-indices = <96>, <97>,
> +						<98>, <101>,
> +						<112>, <113>,
> +						<114>, <115>,
> +						<116>;
> +				clock-output-names = "bus_i2c0", "bus_i2c1",
> +						"bus_i2c2", "bus_scr",
> +						"bus_uart0", "bus_uart1",
> +						"bus_uart2", "bus_uart3",
> +						"bus_uart4";
> +			};
> +		};

As I've already told you I'm not really fond of this one, for two main
topics.

The first one is about the DT bindings itself which is quite exotic,
especially the fact that you define clocks using clocks, clock-indices
and clock-output-names in nodes that are not the one referred to by
consumer, which goes against both the clock bindings documentation and
the usage.

The second one is pretty much the same one than for the discussion we
had about pinctrl. There is SoCs where we simply don't have that
information, or at least are not really sure about what to put where
(namely, the A83t). In such a case, we would knowingly put invalid
information in the DT, which is already quite bad in itself. The worst
part is, when we will identify issues and fix them (hopefully), there
will be no way to fix the current DT users. And it just became a pain
to maintain in the long run.

On the opposite side, having something like the H3 bus gates driver
address all these concerns and is easily extensible, which is why we
ended up merging it.

So please use it.

> +		mmc0_clk: clk at 01c20088 {
> +			#clock-cells = <1>;
> +			compatible = "allwinner,sun4i-a10-mmc-clk";
> +			reg = <0x01c20088 0x4>;
> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
> +			clock-output-names = "mmc0",
> +					     "mmc0_output",
> +					     "mmc0_sample";
> +		};
> +
> +		mmc1_clk: clk at 01c2008c {
> +			#clock-cells = <1>;
> +			compatible = "allwinner,sun4i-a10-mmc-clk";
> +			reg = <0x01c2008c 0x4>;
> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
> +			clock-output-names = "mmc1",
> +					     "mmc1_output",
> +					     "mmc1_sample";
> +		};
> +
> +		mmc2_clk: clk at 01c20090 {
> +			#clock-cells = <1>;
> +			compatible = "allwinner,sun4i-a10-mmc-clk";
> +			reg = <0x01c20090 0x4>;
> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
> +			clock-output-names = "mmc2",
> +					     "mmc2_output",
> +					     "mmc2_sample";
> +		};
> +	};
> +
> +	regulators {
> +		reg_vcc3v3: vcc3v3 {
> +			compatible = "regulator-fixed";
> +			regulator-name = "vcc3v3";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +		};
> +	};
> +
> +	soc {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		mmc0: mmc at 01c0f000 {
> +			compatible = "allwinner,sun5i-a13-mmc";
> +			reg = <0x01c0f000 0x1000>;
> +			clocks = <&bus_gates 8>,
> +				 <&mmc0_clk 0>,
> +				 <&mmc0_clk 1>,
> +				 <&mmc0_clk 2>;
> +			clock-names = "ahb",
> +				      "mmc",
> +				      "output",
> +				      "sample";
> +			resets = <&ahb_rst 8>;
> +			reset-names = "ahb";
> +			interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		mmc1: mmc at 01c10000 {
> +			compatible = "allwinner,sun5i-a13-mmc";
> +			reg = <0x01c10000 0x1000>;
> +			clocks = <&bus_gates 9>,
> +				 <&mmc1_clk 0>,
> +				 <&mmc1_clk 1>,
> +				 <&mmc1_clk 2>;
> +			clock-names = "ahb",
> +				      "mmc",
> +				      "output",
> +				      "sample";
> +			resets = <&ahb_rst 9>;
> +			reset-names = "ahb";
> +			interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		mmc2: mmc at 01c11000 {
> +			compatible = "allwinner,sun5i-a13-mmc";
> +			reg = <0x01c11000 0x1000>;
> +			clocks = <&bus_gates 10>,
> +				 <&mmc2_clk 0>,
> +				 <&mmc2_clk 1>,
> +				 <&mmc2_clk 2>;
> +			clock-names = "ahb",
> +				      "mmc",
> +				      "output",
> +				      "sample";
> +			resets = <&ahb_rst 10>;
> +			reset-names = "ahb";
> +			interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		pio: pinctrl at 01c20800 {
> +			compatible = "allwinner,a64-pinctrl";
> +			reg = <0x01c20800 0x400>;
> +			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&bus_gates 69>;
> +			gpio-controller;
> +			#gpio-cells = <3>;
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +
> +			uart0_pins_a: uart0 at 0 {
> +				allwinner,pins = "PB8", "PB9";
> +				allwinner,function = "uart0";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart0_pins_b: uart0 at 1 {
> +				allwinner,pins = "PF2", "PF3";
> +				allwinner,function = "uart0";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart1_pins: uart1 at 0 {
> +				allwinner,pins = "PG6", "PG7", "PG8", "PG9";
> +				allwinner,function = "uart1";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart2_pins: uart2 at 0 {
> +				allwinner,pins = "PB0", "PB1", "PB2", "PB3";
> +				allwinner,function = "uart2";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart3_pins_a: uart3 at 0 {
> +				allwinner,pins = "PD0", "PD1";
> +				allwinner,function = "uart3";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart3_pins_b: uart3 at 1 {
> +				allwinner,pins = "PH4", "PH5", "PH6", "PH7";
> +				allwinner,function = "uart3";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};

You have several options for all these controllers, which is why we
have the _a or _b suffices.

Usually, the uart pins we had were only using RX and TX, I guess you
could add a separate node for the RTS / CTS pins if some board want to
use them.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160205/46492fa2/attachment.sig>

From fu.wei at linaro.org  Fri Feb  5 00:52:55 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Fri, 5 Feb 2016 16:52:55 +0800
Subject: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <56B38079.10607@roeck-us.net>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-5-git-send-email-fu.wei@linaro.org>
 <20160204163101.GH17257@arm.com> <56B37E52.300@codeaurora.org>
 <56B38079.10607@roeck-us.net>
Message-ID: <CADyBb7u1rN9f8A+eeC4-BgLyjnhYbgyQfepRDy0OmMmMWxD6sQ@mail.gmail.com>

Hi

On 5 February 2016 at 00:46, Guenter Roeck <linux at roeck-us.net> wrote:
> On 02/04/2016 08:37 AM, Timur Tabi wrote:
>>
>> Will Deacon wrote:
>>>>
>>>> +static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
>>>> >+{
>>>> >+    struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
>>>> >+
>>>> >+    /*
>>>> >+    * Writing WRR for an explicit watchdog refresh.
>>>> >+    * You can write anyting(like 0xc0ffee).
>>>> >+    */
>>>> >+    writel(0xc0ffee, gwdt->refresh_base + SBSA_GWDT_WRR);
>>>> >+
>>>> >+    return 0;
>>>> >+}
>>>
>>> You might get in trouble for that. 0xd09f00d is probably less poisonous.
>>>
>>> http://www.petpoisonhelpline.com/poison/caffeine/
>>
>>
>> Any reason why we can't just keep it simple and write 0?
>
>
> +1

yes, we can, just "0" would be fine, will do.

Thanks :-)

>
> Guenter
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From wens at csie.org  Fri Feb  5 00:55:06 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 5 Feb 2016 16:55:06 +0800
Subject: [linux-sunxi] [PATCH 10/11] arm64: dts: add Allwinner A64 SoC
 .dtsi
In-Reply-To: <56B0DD67.3060802@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-11-git-send-email-andre.przywara@arm.com>
 <56B0D83E.5090604@gmail.com> <56B0DD67.3060802@arm.com>
Message-ID: <CAGb2v664eH23JEK5prT-z3joPesdUf+FGYQEdnX1TBs9+SUWRA@mail.gmail.com>

On Wed, Feb 3, 2016 at 12:46 AM, Andre Przywara <andre.przywara at arm.com> wrote:
> Hi Jens,
>
> thanks for having such an elaborate look!
>
> On 02/02/16 16:24, Jens Kuske wrote:
>> Hi,
>>
>> On 01/02/16 18:39, Andre Przywara wrote:
>>> The Allwinner A64 SoC is low-cost SoC with 4 ARM Cortex-A53 cores
>>> and the typical tablet / TV box peripherals.
>>> The Soc is based on the (32-bit) Allwinner H3 chip, sharing most of
>>> the peripherals and the memory map.
>>> Although the cores are proper 64-bit ones, the whole SoC is actually
>>> limited to 4GB (including all the supported DRAM), so we use 32-bit
>>> address and size cells. This has the nice feature of us being able to
>>> reuse the DT for 32-bit kernels as well.
>>> This .dtsi lists the hardware that we support so far.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/sunxi.txt   |   1 +
>>>  Documentation/devicetree/bindings/clock/sunxi.txt |   1 +
>>>  arch/arm64/boot/dts/allwinner/a64.dtsi            | 583 ++++++++++++++++++++++
>>>  3 files changed, 585 insertions(+)
>>>  create mode 100644 arch/arm64/boot/dts/allwinner/a64.dtsi
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
>>> index 980e065..4a83853 100644
>>> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
>>> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
>>> @@ -14,6 +14,7 @@ using one of the following compatible strings:
>>>    allwinner,sun8i-a83t
>>>    allwinner,sun8i-h3
>>>    allwinner,sun9i-a80
>>> +  allwinner,a64
>>>
>>>  For Allwinner SoCs without any specific needs the generic fallback value of:
>>>    allwinner,sunxi
>>> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
>>> index e59f57b..44b0c6c 100644
>>> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
>>> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
>>> @@ -77,6 +77,7 @@ Required properties:
>>>      "allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
>>>      "allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
>>>      "allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
>>> +    "allwinner,a64-bus-gates-clk" - for the A64 multi-parent bus gates clock
>>>
>>>  Required properties for all clocks:
>>>  - reg : shall be the control register address for the clock.
>>> diff --git a/arch/arm64/boot/dts/allwinner/a64.dtsi b/arch/arm64/boot/dts/allwinner/a64.dtsi
>>> new file mode 100644
>>> index 0000000..8dce10f
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/allwinner/a64.dtsi
>>> @@ -0,0 +1,583 @@
>>> +/*
>>> + * Copyright (C) 2016 ARM Ltd.
>>> + * based on the Allwinner H3 dtsi:
>>> + *    Copyright (C) 2015 Jens Kuske <jenskuske at gmail.com>
>>> + *
>>> + * This file is dual-licensed: you can use it either under the terms
>>> + * of the GPL or the X11 license, at your option. Note that this dual
>>> + * licensing only applies to this file, and not this project as a
>>> + * whole.
>>> + *
>>> + *  a) This file is free software; you can redistribute it and/or
>>> + *     modify it under the terms of the GNU General Public License as
>>> + *     published by the Free Software Foundation; either version 2 of the
>>> + *     License, or (at your option) any later version.
>>> + *
>>> + *     This file is distributed in the hope that it will be useful,
>>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + *     GNU General Public License for more details.
>>> + *
>>> + * Or, alternatively,
>>> + *
>>> + *  b) Permission is hereby granted, free of charge, to any person
>>> + *     obtaining a copy of this software and associated documentation
>>> + *     files (the "Software"), to deal in the Software without
>>> + *     restriction, including without limitation the rights to use,
>>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>>> + *     sell copies of the Software, and to permit persons to whom the
>>> + *     Software is furnished to do so, subject to the following
>>> + *     conditions:
>>> + *
>>> + *     The above copyright notice and this permission notice shall be
>>> + *     included in all copies or substantial portions of the Software.
>>> + *
>>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>>> + *     OTHER DEALINGS IN THE SOFTWARE.
>>> + */
>>> +
>>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>>> +
>>> +/ {
>>> +    compatible = "allwinner,a64", "allwinner,sunxi";
>>> +    interrupt-parent = <&gic>;
>>> +    #address-cells = <1>;
>>> +    #size-cells = <1>;
>>> +
>>> +    aliases {
>>> +            serial0 = &uart0;
>>> +            serial1 = &uart1;
>>> +            serial2 = &uart2;
>>> +            serial3 = &uart3;
>>> +            serial4 = &uart4;
>>> +    };
>>> +
>>> +    cpus {
>>> +            #address-cells = <1>;
>>> +            #size-cells = <0>;
>>> +
>>> +            cpu at 0 {
>>> +                    compatible = "arm,cortex-a53", "arm,armv8";
>>> +                    device_type = "cpu";
>>> +                    reg = <0>;
>>> +                    enable-method = "psci";
>>> +            };
>>> +
>>> +            cpu at 1 {
>>> +                    compatible = "arm,cortex-a53", "arm,armv8";
>>> +                    device_type = "cpu";
>>> +                    reg = <1>;
>>> +                    enable-method = "psci";
>>> +            };
>>> +
>>> +            cpu at 2 {
>>> +                    compatible = "arm,cortex-a53", "arm,armv8";
>>> +                    device_type = "cpu";
>>> +                    reg = <2>;
>>> +                    enable-method = "psci";
>>> +            };
>>> +
>>> +            cpu at 3 {
>>> +                    compatible = "arm,cortex-a53", "arm,armv8";
>>> +                    device_type = "cpu";
>>> +                    reg = <3>;
>>> +                    enable-method = "psci";
>>> +            };
>>> +    };
>>> +
>>> +    psci {
>>> +            compatible = "arm,psci-0.2", "arm,psci";
>>> +            method = "smc";
>>> +            cpu_suspend = <0xc4000001>;
>>> +            cpu_off = <0x84000002>;
>>> +            cpu_on = <0xc4000003>;
>>> +    };
>>> +
>>> +    memory {
>>> +            device_type = "memory";
>>> +            reg = <0x40000000 0>;
>>> +    };
>>> +
>>> +    timer {
>>> +            compatible = "arm,armv8-timer";
>>> +            interrupts = <GIC_PPI 13
>>> +                    (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>>> +                         <GIC_PPI 14
>>> +                    (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>>> +                         <GIC_PPI 11
>>> +                    (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>>> +                         <GIC_PPI 10
>>> +                    (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>>> +    };
>>> +
>>> +    clocks {
>>> +            #address-cells = <1>;
>>> +            #size-cells = <1>;
>>> +            ranges;
>>> +
>>> +            osc24M: osc24M_clk {
>>> +                    #clock-cells = <0>;
>>> +                    compatible = "fixed-clock";
>>> +                    clock-frequency = <24000000>;
>>> +                    clock-output-names = "osc24M";
>>> +            };
>>> +
>>> +            osc32k: osc32k_clk {
>>> +                    #clock-cells = <0>;
>>> +                    compatible = "fixed-clock";
>>> +                    clock-frequency = <32768>;
>>> +                    clock-output-names = "osc32k";
>>> +            };
>>> +
>>> +            pll1: clk at 01c20000 {
>>> +                    #clock-cells = <0>;
>>> +                    compatible = "allwinner,sun8i-a23-pll1-clk";
>>> +                    reg = <0x01c20000 0x4>;
>>> +                    clocks = <&osc24M>;
>>> +                    clock-output-names = "pll1";
>>> +            };
>>> +
>>> +            pll6: clk at 01c20028 {
>>> +                    #clock-cells = <1>;
>>> +                    compatible = "allwinner,sun6i-a31-pll6-clk";
>>> +                    reg = <0x01c20028 0x4>;
>>> +                    clocks = <&osc24M>;
>>> +                    clock-output-names = "pll6", "pll6x2";
>>> +            };
>>> +
>>> +            pll6d2: pll6d2_clk {
>>> +                    #clock-cells = <0>;
>>> +                    compatible = "fixed-factor-clock";
>>> +                    clock-div = <2>;
>>> +                    clock-mult = <1>;
>>> +                    clocks = <&pll6 0>;
>>> +                    clock-output-names = "pll6d2";
>>> +            };
>>> +
>>> +            /* dummy clock until pll6 can be reused */
>>> +            pll8: pll8_clk {
>>> +                    #clock-cells = <0>;
>>> +                    compatible = "fixed-clock";
>>> +                    clock-frequency = <1>;
>>> +                    clock-output-names = "pll8";
>>> +            };
>
> Since I have you (as the original author ;-) in the loop: What was again
> the reason for this dummy clock? Can't it be modelled with the existing
> clock drivers in Linux?

The driver for "allwinner,sun6i-a31-pll6-clk" has it's name hard coded,
which means it's not reusable for other clocks. The placeholder is there
to provide a proper representation of the clock tree. It works because
nothing is clocked from pll8 by default.

>>> +
>>> +            cpu: cpu_clk at 01c20050 {
>>> +                    #clock-cells = <0>;
>>> +                    compatible = "allwinner,sun4i-a10-cpu-clk";
>>> +                    reg = <0x01c20050 0x4>;
>>> +                    clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
>>> +                    clock-output-names = "cpu";
>>> +                    critical-clocks = <0>;
>>> +            };
>>> +
>>> +            axi: axi_clk at 01c20050 {
>>> +                    #clock-cells = <0>;
>>> +                    compatible = "allwinner,sun4i-a10-axi-clk";
>>> +                    reg = <0x01c20050 0x4>;
>>> +                    clocks = <&cpu>;
>>> +                    clock-output-names = "axi";
>>> +            };
>>> +
>>> +            ahb1: ahb1_clk at 01c20054 {
>>> +                    #clock-cells = <0>;
>>> +                    compatible = "allwinner,sun6i-a31-ahb1-clk";
>>> +                    reg = <0x01c20054 0x4>;
>>> +                    clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
>>> +                    clock-output-names = "ahb1";
>>> +            };
>>> +
>>> +            ahb2: ahb2_clk at 01c2005c {
>>> +                    #clock-cells = <0>;
>>> +                    compatible = "allwinner,sun8i-h3-ahb2-clk";
>>> +                    reg = <0x01c2005c 0x4>;
>>> +                    clocks = <&ahb1>, <&pll6d2>;
>>> +                    clock-output-names = "ahb2";
>>> +            };
>>> +
>>> +            apb1: apb1_clk at 01c20054 {
>>> +                    #clock-cells = <0>;
>>> +                    compatible = "allwinner,sun4i-a10-apb0-clk";
>>> +                    reg = <0x01c20054 0x4>;
>>> +                    clocks = <&ahb1>;
>>> +                    clock-output-names = "apb1";
>>> +            };
>>> +
>>> +            apb2: apb2_clk at 01c20058 {
>>> +                    #clock-cells = <0>;
>>> +                    compatible = "allwinner,sun4i-a10-apb1-clk";
>>> +                    reg = <0x01c20058 0x4>;
>>> +                    clocks = <&osc32k>, <&osc24M>, <&pll6 1>, <&pll6 1>;
>>> +                    clock-output-names = "apb2";
>>> +            };
>>> +
>>> +            bus_gates: clk at 01c20060 {
>>> +                    #clock-cells = <1>;
>>> +                    compatible = "allwinner,a64-bus-gates-clk",
>>> +                                 "allwinner,sunxi-multi-bus-gates-clk";
>>> +                    reg = <0x01c20060 0x14>;
>>> +                    ahb1_parent {
>>> +                            clocks = <&ahb1>;
>>> +                            clock-indices = <1>, <5>,
>>> +                                            <6>, <8>,
>>> +                                            <9>, <10>,
>>> +                                            <13>, <14>,
>>> +                                            <18>, <19>,
>>> +                                            <20>, <21>,
>>> +                                            <23>, <24>,
>>> +                                            <25>, <28>,
>>> +                                            <32>, <35>,
>>> +                                            <36>, <37>,
>>> +                                            <40>, <43>,
>>> +                                            <44>, <52>,
>>> +                                            <53>, <54>,
>>> +                                            <135>;
>>> +                            clock-output-names = "bus_mipidsi", "bus_ce",
>>> +                                            "bus_dma", "bus_mmc0",
>>> +                                            "bus_mmc1", "bus_mmc2",
>>> +                                            "bus_nand", "bus_sdram",
>>> +                                            "bus_ts", "bus_hstimer",
>>> +                                            "bus_spi0", "bus_spi1",
>>> +                                            "bus_otg", "bus_otg_ehci0",
>>> +                                            "bus_ehci0", "bus_otg_ohci0",
>>> +                                            "bus_ve", "bus_lcd0",
>>> +                                            "bus_lcd1", "bus_deint",
>>> +                                            "bus_csi", "bus_hdmi",
>>> +                                            "bus_de", "bus_gpu",
>>> +                                            "bus_msgbox", "bus_spinlock",
>>> +                                            "bus_dbg";
>>> +                    };
>>> +                    ahb2_parent {
>>> +                            clocks = <&ahb2>;
>>> +                            clock-indices = <17>, <29>;
>>> +                            clock-output-names = "bus_gmac", "bus_ohci0";
>>> +                    };
>>> +                    apb1_parent {
>>> +                            clocks = <&apb1>;
>>> +                            clock-indices = <64>, <65>,
>>> +                                            <69>, <72>,
>>> +                                            <76>, <77>,
>>> +                                            <78>;
>>> +                            clock-output-names = "bus_codec", "bus_spdif",
>>> +                                            "bus_pio", "bus_ths",
>>> +                                            "bus_i2s0", "bus_i2s1",
>>> +                                            "bus_i2s2";
>>> +                    };
>>> +                    abp2_parent {
>>> +                            clocks = <&apb2>;
>>> +                            clock-indices = <96>, <97>,
>>> +                                            <98>, <101>,
>>> +                                            <112>, <113>,
>>> +                                            <114>, <115>,
>>> +                                            <116>;
>>> +                            clock-output-names = "bus_i2c0", "bus_i2c1",
>>> +                                            "bus_i2c2", "bus_scr",
>>> +                                            "bus_uart0", "bus_uart1",
>>> +                                            "bus_uart2", "bus_uart3",
>>> +                                            "bus_uart4";
>>> +                    };
>>> +            };
>>> +
>>> +            mmc0_clk: clk at 01c20088 {
>>> +                    #clock-cells = <1>;
>>> +                    compatible = "allwinner,sun4i-a10-mmc-clk";
>>
>> The A64 MMC clocks don't seem to be fully compatible to A10. The output
>> and sample phase control has been moved to the MMC module itself.
>> The dividers are the same, but the additional special "outputs" are gone.
>
> So from comparing the H3 and the A64 datasheet I see that this is one of
> the rare deviations of the A64 from the H3?

Without the extra phase delay clocks, this is now just a mod0 clock.

>>> +                    reg = <0x01c20088 0x4>;
>>> +                    clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>>
>> Parents are PLL6(2x) and PLL8(2x) according to manual.
>
> Indeed, thanks for pointing this out! So do we need a proper pll8 clock?

You could add a pll8x2 fixed-factor-clk for now, until Maxime's clk series
is worked out.

>
>>
>>> +                    clock-output-names = "mmc0",
>>> +                                         "mmc0_output",
>>> +                                         "mmc0_sample";
>>> +            };
>>> +
>>> +            mmc1_clk: clk at 01c2008c {
>>> +                    #clock-cells = <1>;
>>> +                    compatible = "allwinner,sun4i-a10-mmc-clk";
>>> +                    reg = <0x01c2008c 0x4>;
>>> +                    clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>>> +                    clock-output-names = "mmc1",
>>> +                                         "mmc1_output",
>>> +                                         "mmc1_sample";
>>> +            };
>>> +
>>> +            mmc2_clk: clk at 01c20090 {
>>> +                    #clock-cells = <1>;
>>> +                    compatible = "allwinner,sun4i-a10-mmc-clk";
>>> +                    reg = <0x01c20090 0x4>;
>>> +                    clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>>> +                    clock-output-names = "mmc2",
>>> +                                         "mmc2_output",
>>> +                                         "mmc2_sample";
>>> +            };
>>> +    };
>>> +
>>> +    regulators {
>>> +            reg_vcc3v3: vcc3v3 {
>>> +                    compatible = "regulator-fixed";
>>> +                    regulator-name = "vcc3v3";
>>> +                    regulator-min-microvolt = <3300000>;
>>> +                    regulator-max-microvolt = <3300000>;
>>> +            };

Why is this in the .dtsi?

>>> +    };
>>> +
>>> +    soc {
>>> +            compatible = "simple-bus";
>>> +            #address-cells = <1>;
>>> +            #size-cells = <1>;
>>> +            ranges;
>>> +
>>> +            mmc0: mmc at 01c0f000 {
>>> +                    compatible = "allwinner,sun5i-a13-mmc";
>>> +                    reg = <0x01c0f000 0x1000>;
>>> +                    clocks = <&bus_gates 8>,
>>> +                             <&mmc0_clk 0>,
>>
>> Consequently, the MMC driver now has to control the output/sample phase
>> with registers 0x140-0x148 instead of
>>> +                             <&mmc0_clk 1>,
>>> +                             <&mmc0_clk 2>;
>
> OK, good point. I was just briefly browsing over the register
> descriptions and missed that.
> So it looks like I need to change the driver. Interestingly it seems to
> work anyways ...

The default delay values probably are good enough. Or they included routing
tolerances in the design notes. :)

You should still check Allwinner's kernel for new delay values though.

>> And there seems to be some new clock divider somewhere which I haven't
>> found in the manual yet. The clock measured at the CLK pin is always
>> half the expected rate (even with 24MHz as MMC clock parent, so no
>> PLL6*2 problem).
>
> Mmh, I heard about that mysterious clock doubling / halving already. Was
> that actually causing any issues?

On the A83T there was this "new timing mode" feature in the mmc clocks and
controller, which halved the card clock. I don't see any mention of it on
A64 though.

>>
>>> +                    clock-names = "ahb",
>>> +                                  "mmc",
>>> +                                  "output",
>>> +                                  "sample";
>>> +                    resets = <&ahb_rst 8>;
>>> +                    reset-names = "ahb";
>>> +                    interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
>>> +                    status = "disabled";
>>> +                    #address-cells = <1>;
>>> +                    #size-cells = <0>;
>>> +            };
>>> +
>>> +            mmc1: mmc at 01c10000 {
>>> +                    compatible = "allwinner,sun5i-a13-mmc";
>>> +                    reg = <0x01c10000 0x1000>;
>>> +                    clocks = <&bus_gates 9>,
>>> +                             <&mmc1_clk 0>,
>>> +                             <&mmc1_clk 1>,
>>> +                             <&mmc1_clk 2>;
>>> +                    clock-names = "ahb",
>>> +                                  "mmc",
>>> +                                  "output",
>>> +                                  "sample";
>>> +                    resets = <&ahb_rst 9>;
>>> +                    reset-names = "ahb";
>>> +                    interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
>>> +                    status = "disabled";
>>> +                    #address-cells = <1>;
>>> +                    #size-cells = <0>;
>>> +            };
>>> +
>>> +            mmc2: mmc at 01c11000 {
>>> +                    compatible = "allwinner,sun5i-a13-mmc";
>>> +                    reg = <0x01c11000 0x1000>;
>>> +                    clocks = <&bus_gates 10>,
>>> +                             <&mmc2_clk 0>,
>>> +                             <&mmc2_clk 1>,
>>> +                             <&mmc2_clk 2>;
>>> +                    clock-names = "ahb",
>>> +                                  "mmc",
>>> +                                  "output",
>>> +                                  "sample";
>>> +                    resets = <&ahb_rst 10>;
>>> +                    reset-names = "ahb";
>>> +                    interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
>>> +                    status = "disabled";
>>> +                    #address-cells = <1>;
>>> +                    #size-cells = <0>;
>>> +            };
>>> +
>>> +            pio: pinctrl at 01c20800 {
>>> +                    compatible = "allwinner,a64-pinctrl";
>>> +                    reg = <0x01c20800 0x400>;
>>> +                    interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
>>> +                                 <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
>>> +                                 <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
>>> +                    clocks = <&bus_gates 69>;
>>> +                    gpio-controller;
>>> +                    #gpio-cells = <3>;
>>> +                    interrupt-controller;
>>> +                    #interrupt-cells = <2>;
>>> +
>>> +                    uart0_pins_a: uart0 at 0 {
>>> +                            allwinner,pins = "PB8", "PB9";
>>> +                            allwinner,function = "uart0";
>>> +                            allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>> +                            allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>> +                    };
>>> +
>>> +                    uart0_pins_b: uart0 at 1 {
>>> +                            allwinner,pins = "PF2", "PF3";
>>> +                            allwinner,function = "uart0";
>>> +                            allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>> +                            allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>> +                    };
>>> +
>>> +                    uart1_pins: uart1 at 0 {
>>> +                            allwinner,pins = "PG6", "PG7", "PG8", "PG9";
>>> +                            allwinner,function = "uart1";
>>> +                            allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>> +                            allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>> +                    };
>>> +
>>> +                    uart2_pins: uart2 at 0 {
>>> +                            allwinner,pins = "PB0", "PB1", "PB2", "PB3";
>>> +                            allwinner,function = "uart2";
>>> +                            allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>> +                            allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>> +                    };
>>> +
>>> +                    uart3_pins_a: uart3 at 0 {
>>> +                            allwinner,pins = "PD0", "PD1";
>>> +                            allwinner,function = "uart3";
>>> +                            allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>> +                            allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>> +                    };
>>> +
>>> +                    uart3_pins_b: uart3 at 1 {
>>> +                            allwinner,pins = "PH4", "PH5", "PH6", "PH7";
>>> +                            allwinner,function = "uart3";
>>> +                            allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>> +                            allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>> +                    };
>>> +
>>> +                    uart4_pins: uart4 at 0 {
>>> +                            allwinner,pins = "PD2", "PD3", "PD4", "PD5";
>>> +                            allwinner,function = "uart4";
>>> +                            allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>> +                            allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>> +                    };

We normally don't add these until someone uses them.
And one could choose to use 2 pins instead of 4. :|

>>> +
>>> +                    mmc0_pins: mmc0 at 0 {
>>> +                            allwinner,pins = "PF0", "PF1", "PF2", "PF3",
>>> +                                             "PF4", "PF5";
>>> +                            allwinner,function = "mmc0";
>>> +                            allwinner,drive = <SUN4I_PINCTRL_30_MA>;
>>> +                            allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>> +                    };
>>> +
>>> +                    mmc0_default_cd_pin: mmc0_cd_pin at 0 {
>>> +                            allwinner,pins = "PF6";
>>> +                            allwinner,function = "gpio_in";
>>> +                            allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>> +                            allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>>> +                    };
>>> +
>>> +                    mmc1_pins: mmc1 at 0 {
>>> +                            allwinner,pins = "PG0", "PG1", "PG2", "PG3",
>>> +                                             "PG4", "PG5";
>>> +                            allwinner,function = "mmc1";
>>> +                            allwinner,drive = <SUN4I_PINCTRL_30_MA>;
>>> +                            allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>> +                    };
>>> +
>>> +                    mmc2_pins: mmc2 at 0 {
>>> +                            allwinner,pins = "PC1", "PC5", "PC6", "PC8",
>>> +                                             "PC9", "PC10";
>>> +                            allwinner,function = "mmc2";
>>> +                            allwinner,drive = <SUN4I_PINCTRL_30_MA>;
>>> +                            allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>> +                    };
>>> +            };
>>> +
>>> +            ahb_rst: reset at 01c202c0 {
>>> +                    #reset-cells = <1>;
>>> +                    compatible = "allwinner,sun6i-a31-ahb1-reset";
>>> +                    reg = <0x01c202c0 0xc>;
>>> +            };
>>> +
>>> +            apb1_rst: reset at 01c202d0 {
>>> +                    #reset-cells = <1>;
>>> +                    compatible = "allwinner,sun6i-a31-clock-reset";
>>> +                    reg = <0x01c202d0 0x4>;
>>> +            };
>>> +
>>> +            apb2_rst: reset at 01c202d8 {
>>> +                    #reset-cells = <1>;
>>> +                    compatible = "allwinner,sun6i-a31-clock-reset";
>>> +                    reg = <0x01c202d8 0x4>;
>>> +            };
>>> +
>>> +            uart0: serial at 01c28000 {
>>> +                    compatible = "snps,dw-apb-uart";
>>> +                    reg = <0x01c28000 0x400>;
>>> +                    interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
>>> +                    reg-shift = <2>;
>>> +                    reg-io-width = <4>;
>>> +                    clocks = <&bus_gates 112>;
>>> +                    resets = <&apb2_rst 16>;
>>> +                    reset-names = "apb2";
>>
>> Do we need reset-names here (and below)?
>
> Probably not, in fact I was wondering about that already. Actually I
> just copied them from some other DT ;-)

Nope. Not needed.


Regards
ChenYu

>>> +                    status = "disabled";
>>> +            };
>>> +
>>> +            uart1: serial at 01c28400 {
>>> +                    compatible = "snps,dw-apb-uart";
>>> +                    reg = <0x01c28400 0x400>;
>>> +                    interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
>>> +                    reg-shift = <2>;
>>> +                    reg-io-width = <4>;
>>> +                    clocks = <&bus_gates 113>;
>>> +                    resets = <&apb2_rst 17>;
>>> +                    reset-names = "apb2";
>>> +                    status = "disabled";
>>> +            };
>>> +
>>> +            uart2: serial at 01c28800 {
>>> +                    compatible = "snps,dw-apb-uart";
>>> +                    reg = <0x01c28800 0x400>;
>>> +                    interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
>>> +                    reg-shift = <2>;
>>> +                    reg-io-width = <4>;
>>> +                    clocks = <&bus_gates 114>;
>>> +                    resets = <&apb2_rst 18>;
>>> +                    reset-names = "apb2";
>>> +                    status = "disabled";
>>> +            };
>>> +
>>> +            uart3: serial at 01c28c00 {
>>> +                    compatible = "snps,dw-apb-uart";
>>> +                    reg = <0x01c28c00 0x400>;
>>> +                    interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
>>> +                    reg-shift = <2>;
>>> +                    reg-io-width = <4>;
>>> +                    clocks = <&bus_gates 115>;
>>> +                    resets = <&apb2_rst 19>;
>>> +                    reset-names = "apb2";
>>> +                    status = "disabled";
>>> +            };
>>> +
>>> +            uart4: serial at 01c29000 {
>>> +                    compatible = "snps,dw-apb-uart";
>>> +                    reg = <0x01c29000 0x400>;
>>> +                    interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
>>> +                    reg-shift = <2>;
>>> +                    reg-io-width = <4>;
>>> +                    clocks = <&bus_gates 116>;
>>> +                    resets = <&apb2_rst 20>;
>>> +                    reset-names = "apb2";
>>> +                    status = "disabled";
>>> +            };
>>> +
>>> +            rtc: rtc at 01f00000 {
>>> +                    compatible = "allwinner,sun6i-a31-rtc";
>>> +                    reg = <0x01f00000 0x54>;
>>> +                    interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
>>> +                                 <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
>>> +            };
>>> +    };
>>> +
>>> +    gic: interrupt-controller@{
>>> +            compatible = "arm,gic-400";
>>> +            interrupt-controller;
>>> +            #interrupt-cells = <3>;
>>> +            #address-cells = <0>;
>>> +
>>> +            reg = <0x01C81000 0x1000>,
>>> +                  <0x01C82000 0x2000>,
>>> +                  <0x01C84000 0x2000>,
>>> +                  <0x01C86000 0x2000>;
>>
>> Maybe lowercase hex here too.
>
> Yes.
>
>
> Thanks for actually going through this!
>
> Cheers,
> Andre.
>
>>> +            interrupts = <GIC_PPI 9
>>> +                  (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>>> +    };
>>> +};
>>>
>>
>> Regards,
>> Jens
>>
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


From marc.zyngier at arm.com  Fri Feb  5 00:56:00 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 5 Feb 2016 08:56:00 +0000
Subject: [PATCH v3 00/23] arm64: Virtualization Host Extension support
In-Reply-To: <20160204192641.GJ13974@cbox>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <20160204192641.GJ13974@cbox>
Message-ID: <56B463A0.7010801@arm.com>

On 04/02/16 19:26, Christoffer Dall wrote:
> On Wed, Feb 03, 2016 at 05:59:53PM +0000, Marc Zyngier wrote:
>> ARMv8.1 comes with the "Virtualization Host Extension" (VHE for
>> short), which enables simpler support of Type-2 hypervisors.
>>
>> This extension allows the kernel to directly run at EL2, and
>> significantly reduces the number of system registers shared between
>> host and guest, reducing the overhead of virtualization.
>>
>> In order to have the same kernel binary running on all versions of the
>> architecture, this series makes heavy use of runtime code patching.
>>
>> The first 22 patches massage the KVM code to deal with VHE and enable
>> Linux to run at EL2. The last patch catches an ugly case when VHE
>> capable CPUs are paired with some of their less capable siblings. This
>> should never happen, but hey...
>>
>> I have deliberately left out some of the more "advanced"
>> optimizations, as they are likely to distract the reviewer from the
>> core infrastructure, which is what I care about at the moment.
>>
>> Note: GDB is currently busted on VHE systems, as it checks for version
>>       6 on the debug architecture, while VHE is version 7. The
>>       binutils people are on the case.
>>
>> This has been tested on the FVP_Base_SLV-V8-A model, and based on
>> v4.5-rc2. I've put a branch out on:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/vhe
>>
> 
> You can have my reviewed-by on all patches that I didn't already review
> or ack explicitly.

Thanks for the review, much appreciated.

> Only exception is the debug stuff where I didn't manage to page in the
> context, so hopefully familiar with that code can have a look.

I think this will have to be Mr Deacon.

Thanks again,

	M.
-- 
Jazz is not dead. It just smells funny...


From fu.wei at linaro.org  Fri Feb  5 01:01:55 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Fri, 5 Feb 2016 17:01:55 +0800
Subject: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <CANLsYkzQpEHa4hnO4D1E0+P-i961+ak=Hr_RPPrOxd-+VMhLSQ@mail.gmail.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-5-git-send-email-fu.wei@linaro.org>
 <CANLsYkzQpEHa4hnO4D1E0+P-i961+ak=Hr_RPPrOxd-+VMhLSQ@mail.gmail.com>
Message-ID: <CADyBb7tjoTPj2uAS23Rpqzfq3tyfSTxq4t7rAxivj64W9Xx4kg@mail.gmail.com>

On 5 February 2016 at 00:25, Mathieu Poirier <mathieu.poirier at linaro.org> wrote:
> On 3 February 2016 at 10:18,  <fu.wei at linaro.org> wrote:
>> From: Fu Wei <fu.wei at linaro.org>
>>
>> According to Server Base System Architecture (SBSA) specification,
>> the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0)
>> is for alerting the system by interrupt, the second one (WS1) is a real
>> hardware reset.
>>
>> This patch initially implements a simple single stage watchdog driver:
>> when the timeout is reached, your system will be reset by the second
>> signal (WS1).
>> The first signal (WS0) is ignored in this driver.
>>
>> This driver bases on linux kernel watchdog framework, so it can get
>> timeout from module parameter and FDT at the driver init stage.
>>
>> Signed-off-by: Fu Wei <fu.wei at linaro.org>
>> Reviewed-by: Graeme Gregory <graeme.gregory at linaro.org>
>> Tested-by: Pratyush Anand <panand at redhat.com>
>> ---
>>  drivers/watchdog/Kconfig     |  17 +++
>>  drivers/watchdog/Makefile    |   1 +
>>  drivers/watchdog/sbsa_gwdt.c | 322 +++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 340 insertions(+)
>>
>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>> index 4f0e7be..4ab1b05 100644
>> --- a/drivers/watchdog/Kconfig
>> +++ b/drivers/watchdog/Kconfig
>> @@ -201,6 +201,23 @@ config ARM_SP805_WATCHDOG
>>           ARM Primecell SP805 Watchdog timer. This will reboot your system when
>>           the timeout is reached.
>>
>> +config ARM_SBSA_WATCHDOG
>> +       tristate "ARM SBSA Generic Watchdog"
>> +       depends on ARM64
>> +       depends on ARM_ARCH_TIMER
>> +       select WATCHDOG_CORE
>> +       help
>> +         ARM SBSA Generic Watchdog has two stage timeouts:
>> +         the first signal (WS0) is for alerting the system by interrupt,
>> +         the second one (WS1) is a real hardware reset.
>> +         More details: ARM DEN0029B - Server Base System Architecture (SBSA)
>> +
>> +         This is a simple single stage driver: when the timeout is reached,
>> +         your system will be reset by WS1. The first signal (WS0) is ignored.
>> +
>> +         To compile this driver as module, choose M here: The module
>> +         will be called sbsa_gwdt.
>> +
>>  config ASM9260_WATCHDOG
>>         tristate "Alphascale ASM9260 watchdog"
>>         depends on MACH_ASM9260
>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
>> index f566753..f9826d4 100644
>> --- a/drivers/watchdog/Makefile
>> +++ b/drivers/watchdog/Makefile
>> @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
>>
>>  # ARM Architecture
>>  obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
>> +obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
>>  obj-$(CONFIG_ASM9260_WATCHDOG) += asm9260_wdt.o
>>  obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
>>  obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
>> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
>> new file mode 100644
>> index 0000000..5a2dba3
>> --- /dev/null
>> +++ b/drivers/watchdog/sbsa_gwdt.c
>> @@ -0,0 +1,322 @@
>> +/*
>> + * SBSA(Server Base System Architecture) Generic Watchdog driver
>> + *
>> + * Copyright (c) 2015, Linaro Ltd.
>> + * Author: Fu Wei <fu.wei at linaro.org>
>> + *         Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
>> + *         Al Stone <al.stone at linaro.org>
>> + *         Timur Tabi <timur at codeaurora.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License 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.
>> + *
>> + * This SBSA Generic watchdog driver is a single stage timeout version.
>> + * Since this watchdog timer has two stages, and each stage is determined
>> + * by WOR. So the timeout is (WOR * 2).
>> + * When first timeout is reached, WS0 is triggered, the interrupt
>> + * triggered by WS0 will be ignored, then the second watch period starts;
>> + * when second timeout is reached, then WS1 is triggered, system reset.
>> + *
>> + * More details about the hardware specification of this device:
>> + * ARM DEN0029B - Server Base System Architecture (SBSA)
>> + *
>> + * SBSA GWDT: |--------WOR-------WS0--------WOR-------WS1
>> + *            |----------------timeout----------------reset
>> + *
>> + */
>> +
>> +#include <linux/io.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/module.h>
>> +#include <linux/moduleparam.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/uaccess.h>
>> +#include <linux/watchdog.h>
>> +#include <asm/arch_timer.h>
>> +
>> +/* SBSA Generic Watchdog register definitions */
>> +/* refresh frame */
>> +#define SBSA_GWDT_WRR                          0x000
>> +
>> +/* control frame */
>> +#define SBSA_GWDT_WCS                          0x000
>> +#define SBSA_GWDT_WOR                          0x008
>> +#define SBSA_GWDT_WCV                          0x010
>> +
>> +/* refresh/control frame */
>> +#define SBSA_GWDT_W_IIDR                       0xfcc
>> +#define SBSA_GWDT_IDR                          0xfd0
>> +
>> +/* Watchdog Control and Status Register */
>> +#define SBSA_GWDT_WCS_EN                       BIT(0)
>> +#define SBSA_GWDT_WCS_WS0                      BIT(1)
>> +#define SBSA_GWDT_WCS_WS1                      BIT(2)
>> +
>> +/**
>> + * struct sbsa_gwdt - Internal representation of the SBSA GWDT
>> + * @wdd:               kernel watchdog_device structure
>> + * @clk:               store the System Counter clock frequency, in Hz.
>> + * @refresh_base:      Virtual address of the watchdog refresh frame
>> + * @control_base:      Virtual address of the watchdog control frame
>> + */
>> +struct sbsa_gwdt {
>> +       struct watchdog_device  wdd;
>> +       u32                     clk;
>> +       void __iomem            *refresh_base;
>> +       void __iomem            *control_base;
>> +};
>> +
>> +#define to_sbsa_gwdt(e) container_of(e, struct sbsa_gwdt, wdd)
>> +
>> +#define DEFAULT_TIMEOUT                20 /* seconds, the 1st + 2nd watch periods*/
>> +
>> +static unsigned int timeout;
>> +module_param(timeout, uint, 0);
>> +MODULE_PARM_DESC(timeout,
>> +                "Watchdog timeout in seconds. (>=0, default="
>> +                __MODULE_STRING(DEFAULT_TIMEOUT) ")");
>> +
>> +static bool nowayout = WATCHDOG_NOWAYOUT;
>> +module_param(nowayout, bool, S_IRUGO);
>> +MODULE_PARM_DESC(nowayout,
>> +                "Watchdog cannot be stopped once started (default="
>> +                __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
>> +
>> +/*
>> + * watchdog operation functions
>> + */
>> +static int sbsa_gwdt_set_timeout(struct watchdog_device *wdd,
>> +                                unsigned int timeout)
>> +{
>> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
>> +
>> +       wdd->timeout = timeout;
>> +       writel(timeout / 2 * gwdt->clk, gwdt->control_base + SBSA_GWDT_WOR);
>> +
>> +       return 0;
>> +}
>> +
>> +static unsigned int sbsa_gwdt_get_timeleft(struct watchdog_device *wdd)
>> +{
>> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
>> +       u64 timeleft = readq(gwdt->control_base + SBSA_GWDT_WCV) -
>> +                      arch_counter_get_cntvct();
>> +
>> +       do_div(timeleft, gwdt->clk);
>> +
>> +       if (readl(gwdt->control_base + SBSA_GWDT_WCS) & SBSA_GWDT_WCS_WS0)
>> +               return timeleft;
>> +
>> +       return timeleft + wdd->timeout / 2;
>
> It would be great to have a comment whenever hard coded values are
> used.  That way people understand why things were set this way.  The
> same applies for the rest of this patch.

OK, will do , thanks

>
>> +}
>> +
>> +static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
>> +{
>> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
>> +
>> +       /*
>> +       * Writing WRR for an explicit watchdog refresh.
>> +       * You can write anyting(like 0xc0ffee).
>> +       */
>> +       writel(0xc0ffee, gwdt->refresh_base + SBSA_GWDT_WRR);
>> +
>> +       return 0;
>> +}
>> +
>> +static unsigned int sbsa_gwdt_status(struct watchdog_device *wdd)
>> +{
>> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
>> +       u32 status = readl(gwdt->control_base + SBSA_GWDT_WCS);
>> +
>> +       /* is the watchdog timer running? */
>> +       return (status & SBSA_GWDT_WCS_EN) << WDOG_ACTIVE;
>> +}
>> +
>> +static int sbsa_gwdt_start(struct watchdog_device *wdd)
>> +{
>> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
>> +
>> +       /* writing WCS will cause an explicit watchdog refresh */
>> +       writel(SBSA_GWDT_WCS_EN, gwdt->control_base + SBSA_GWDT_WCS);
>> +
>> +       return sbsa_gwdt_keepalive(wdd);
>> +}
>> +
>> +static int sbsa_gwdt_stop(struct watchdog_device *wdd)
>> +{
>> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
>> +
>> +       writel(0, gwdt->control_base + SBSA_GWDT_WCS);
>> +
>> +       return 0;
>> +}
>> +
>> +static struct watchdog_info sbsa_gwdt_info = {
>> +       .identity       = "SBSA Generic Watchdog",
>> +       .options        = WDIOF_SETTIMEOUT |
>> +                         WDIOF_KEEPALIVEPING |
>> +                         WDIOF_MAGICCLOSE |
>> +                         WDIOF_CARDRESET,
>> +};
>> +
>> +static struct watchdog_ops sbsa_gwdt_ops = {
>> +       .owner          = THIS_MODULE,
>> +       .start          = sbsa_gwdt_start,
>> +       .stop           = sbsa_gwdt_stop,
>> +       .status         = sbsa_gwdt_status,
>> +       .ping           = sbsa_gwdt_keepalive,
>> +       .set_timeout    = sbsa_gwdt_set_timeout,
>> +       .get_timeleft   = sbsa_gwdt_get_timeleft,
>> +};
>> +
>> +static int sbsa_gwdt_probe(struct platform_device *pdev)
>> +{
>> +       void __iomem *rf_base, *cf_base;
>> +       struct device *dev = &pdev->dev;
>> +       struct watchdog_device *wdd;
>> +       struct sbsa_gwdt *gwdt;
>> +       struct resource *res;
>> +       u32 status;
>> +       int ret;
>> +
>> +       gwdt = devm_kzalloc(dev, sizeof(*gwdt), GFP_KERNEL);
>> +       if (!gwdt)
>> +               return -ENOMEM;
>> +       platform_set_drvdata(pdev, gwdt);
>> +
>> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +       cf_base = devm_ioremap_resource(dev, res);
>> +       if (IS_ERR(cf_base))
>> +               return PTR_ERR(cf_base);
>> +
>> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>> +       rf_base = devm_ioremap_resource(dev, res);
>> +       if (IS_ERR(rf_base))
>> +               return PTR_ERR(rf_base);
>> +
>> +       /*
>> +        * Get the frequency of system counter from the cp15 interface of ARM
>> +        * Generic timer. We don't need to check it, because if it returns "0",
>> +        * system would panic in very early stage.
>> +        */
>> +       gwdt->clk = arch_timer_get_cntfrq();
>> +       gwdt->refresh_base = rf_base;
>> +       gwdt->control_base = cf_base;
>> +
>> +       wdd = &gwdt->wdd;
>> +       wdd->parent = dev;
>> +       wdd->info = &sbsa_gwdt_info;
>> +       wdd->ops = &sbsa_gwdt_ops;
>> +       watchdog_set_drvdata(wdd, gwdt);
>> +       watchdog_set_nowayout(wdd, nowayout);
>> +
>> +       wdd->min_timeout = 2;
>> +       wdd->max_timeout = U32_MAX / gwdt->clk * 2;
>> +       wdd->timeout = DEFAULT_TIMEOUT;
>> +       watchdog_init_timeout(wdd, timeout, dev);
>> +
>> +       status = readl(gwdt->control_base + SBSA_GWDT_WCS);
>> +       if (status & SBSA_GWDT_WCS_WS1) {
>> +               dev_warn(dev, "System reset by WDT.\n");
>> +               wdd->bootstatus |= WDIOF_CARDRESET;
>> +       }
>> +
>> +       ret = watchdog_register_device(wdd);
>> +       if (ret)
>> +               return ret;
>> +
>> +       /*
>> +        * Update timeout to WOR.
>> +        * Because of the explicit watchdog refresh mechanism,
>> +        * it's also a ping, if watchdog is enabled.
>> +        */
>> +       sbsa_gwdt_set_timeout(wdd, wdd->timeout);
>> +
>> +       dev_info(dev, "Initialized with %ds timeout @ %u Hz%s\n", wdd->timeout,
>> +                gwdt->clk, status & SBSA_GWDT_WCS_EN ? " [enabled]" : "");
>> +
>> +       return 0;
>> +}
>> +
>> +static void sbsa_gwdt_shutdown(struct platform_device *pdev)
>> +{
>> +       struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
>> +
>> +       sbsa_gwdt_stop(&gwdt->wdd);
>> +}
>> +
>> +static int sbsa_gwdt_remove(struct platform_device *pdev)
>> +{
>> +       struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
>> +
>> +       watchdog_unregister_device(&gwdt->wdd);
>> +
>> +       return 0;
>> +}
>> +
>> +/* Disable watchdog if it is active during suspend */
>> +static int __maybe_unused sbsa_gwdt_suspend(struct device *dev)
>> +{
>> +       struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
>> +
>> +       if (watchdog_active(&gwdt->wdd))
>> +               sbsa_gwdt_stop(&gwdt->wdd);
>> +
>> +       return 0;
>> +}
>> +
>> +/* Enable watchdog and configure it if necessary */
>> +static int __maybe_unused sbsa_gwdt_resume(struct device *dev)
>> +{
>> +       struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
>> +
>> +       if (watchdog_active(&gwdt->wdd))
>> +               sbsa_gwdt_start(&gwdt->wdd);
>> +
>> +       return 0;
>> +}
>> +
>> +static const struct dev_pm_ops sbsa_gwdt_pm_ops = {
>> +       SET_SYSTEM_SLEEP_PM_OPS(sbsa_gwdt_suspend, sbsa_gwdt_resume)
>> +};
>> +
>> +static const struct of_device_id sbsa_gwdt_of_match[] = {
>> +       { .compatible = "arm,sbsa-gwdt", },
>> +       {},
>> +};
>> +MODULE_DEVICE_TABLE(of, sbsa_gwdt_of_match);
>> +
>> +static const struct platform_device_id sbsa_gwdt_pdev_match[] = {
>> +       { .name = "sbsa-gwdt", },
>> +       {},
>> +};
>> +MODULE_DEVICE_TABLE(platform, sbsa_gwdt_pdev_match);
>> +
>> +static struct platform_driver sbsa_gwdt_driver = {
>> +       .driver = {
>> +               .name = "sbsa-gwdt",
>> +               .pm = &sbsa_gwdt_pm_ops,
>> +               .of_match_table = sbsa_gwdt_of_match,
>> +       },
>> +       .probe = sbsa_gwdt_probe,
>> +       .remove = sbsa_gwdt_remove,
>> +       .shutdown = sbsa_gwdt_shutdown,
>> +       .id_table = sbsa_gwdt_pdev_match,
>> +};
>> +
>> +module_platform_driver(sbsa_gwdt_driver);
>> +
>> +MODULE_DESCRIPTION("SBSA Generic Watchdog Driver");
>> +MODULE_AUTHOR("Fu Wei <fu.wei at linaro.org>");
>> +MODULE_AUTHOR("Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>");
>> +MODULE_AUTHOR("Al Stone <al.stone at linaro.org>");
>> +MODULE_AUTHOR("Timur Tabi <timur at codeaurora.org>");
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.5.0
>>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From marc.zyngier at arm.com  Fri Feb  5 01:02:39 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 5 Feb 2016 09:02:39 +0000
Subject: [PATCH v3 20/23] arm64: perf: Count EL2 events if the kernel is
 running in HYP
In-Reply-To: <20160204192301.GG13974@cbox>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-21-git-send-email-marc.zyngier@arm.com>
 <20160204192301.GG13974@cbox>
Message-ID: <56B4652F.4030407@arm.com>

On 04/02/16 19:23, Christoffer Dall wrote:
> On Wed, Feb 03, 2016 at 06:00:13PM +0000, Marc Zyngier wrote:
>> When the kernel is running in HYP (with VHE), it is necessary to
>> include EL2 events if the user requests counting kernel or
>> hypervisor events.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kernel/perf_event.c | 14 ++++++++++----
>>  1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
>> index f7ab14c..6013a38 100644
>> --- a/arch/arm64/kernel/perf_event.c
>> +++ b/arch/arm64/kernel/perf_event.c
>> @@ -20,6 +20,7 @@
>>   */
>>  
>>  #include <asm/irq_regs.h>
>> +#include <asm/virt.h>
>>  
>>  #include <linux/of.h>
>>  #include <linux/perf/arm_pmu.h>
>> @@ -693,10 +694,15 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
>>  		return -EPERM;
>>  	if (attr->exclude_user)
>>  		config_base |= ARMV8_EXCLUDE_EL0;
>> -	if (attr->exclude_kernel)
>> -		config_base |= ARMV8_EXCLUDE_EL1;
>> -	if (!attr->exclude_hv)
>> -		config_base |= ARMV8_INCLUDE_EL2;
>> +	if (is_kernel_in_hyp_mode()) {
>> +		if (!attr->exclude_kernel || !attr->exclude_hv)
>> +			config_base |= ARMV8_INCLUDE_EL2;
> 
> is exclude_hv a perf generic construct?

Yes. It seems to be universally used on all architectures.

> is it really correct to count everything the host kernel does (even
> unrelated to running VMs) when counting hypervisor events?

With VHE, the roles are blurred, and the PMU can only count events
occurring when at a given exception level. It has no notion of context.

> Other than my ignorance in this area, this patch looks fine to me.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From andrew at lunn.ch  Fri Feb  5 01:02:46 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 5 Feb 2016 10:02:46 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
Message-ID: <20160205090246.GE32272@lunn.ch>

On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
> Hi,
> 
> I am testing marvell_cesa on a kirkwood device (QNAP TS-212p, Marvell
> Kirkwood 88F6282, dts: http://pastebin.com/Gk95KFHf ).
> As of kernel 4.4 (4.4.0-trunk-kirkwood #1 Debian 4.4-1~exp1) it fails
> in the following way:
> 
> modprobe marvell_cesa allhwsupport=1
> dmesg | tail -n 1
> [ 1057.855091] marvell-cesa: probe of f1030000.crypto failed with error -12
> 
> or:
> 
> modprobe marvell_cesa
> dmesg | tail -n 1
> [ 9178.399357] marvell-cesa: probe of f1030000.crypto failed with error -524
> 
> With kernel 4.3 it would fail with error -22 on that hardware. There
> are scattered reports from other users experiencing the same issue
> (1,2,3)
> 
> I wonder if this is a result of an invalid definition of the
> crypto-sram in the dts of this SoC, or perhaps some other problem
> (PEBKAC included).

Hi Jan

Do you have SRAM enabled in your kernel configuration. The
mvebu_v5_defconfig does not have it, which is a bug really.

	   Andrew


From maxime.ripard at free-electrons.com  Fri Feb  5 01:03:37 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 5 Feb 2016 10:03:37 +0100
Subject: [PATCH 11/11] arm64: dts: add Pine64 support
In-Reply-To: <1454348370-3816-12-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-12-git-send-email-andre.przywara@arm.com>
Message-ID: <20160205090337.GB1139@lukather>

Hi,

On Mon, Feb 01, 2016 at 05:39:30PM +0000, Andre Przywara wrote:
> The Pine64 is a cost-efficient development board based on the
> Allwinner A64 SoC.
> There are three models: the basic version with Fast Ethernet and
> 512 MB of DRAM (Pine64) and two Pine64+ versions, which both
> feature Gigabit Ethernet and additional connectors for touchscreens
> and a camera. Or as my son put it: "Those are smaller and these are
> missing." ;-)
> The two Pine64+ models just differ in the amount of DRAM
> (1GB vs. 2GB). Since U-Boot will figure out the right size for us and
> patches the DT accordingly we just need to provide one DT for the
> Pine64+.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>  arch/arm64/boot/dts/Makefile                       |  1 +
>  arch/arm64/boot/dts/allwinner/Makefile             |  5 ++
>  arch/arm64/boot/dts/allwinner/pine64.dts           | 58 +++++++++++++++++
>  arch/arm64/boot/dts/allwinner/pine64_common.dtsi   | 76 ++++++++++++++++++++++
>  arch/arm64/boot/dts/allwinner/pine64_plus.dts      | 59 +++++++++++++++++
>  6 files changed, 200 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
>  create mode 100644 arch/arm64/boot/dts/allwinner/pine64.dts
>  create mode 100644 arch/arm64/boot/dts/allwinner/pine64_common.dtsi
>  create mode 100644 arch/arm64/boot/dts/allwinner/pine64_plus.dts
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 72e2c5a..0c22fa9 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -175,6 +175,7 @@ parade	Parade Technologies Inc.
>  pericom	Pericom Technology Inc.
>  phytec	PHYTEC Messtechnik GmbH
>  picochip	Picochip Ltd
> +pine64	Pine64
>  plathome	Plat'Home Co., Ltd.
>  plda	PLDA
>  pixcir  PIXCIR MICROELECTRONICS Co., Ltd

Please make a separate patch for this one.

> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index f832b8a..3b7428a 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -1,3 +1,4 @@
> +dts-dirs += allwinner

Could you also add a patch to add this path to MAINTAINERS too?

>  dts-dirs += altera
>  dts-dirs += amd
>  dts-dirs += apm
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> new file mode 100644
> index 0000000..65f4e24
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -0,0 +1,5 @@
> +dtb-$(CONFIG_ARCH_SUNXI) += pine64_plus.dtb pine64.dtb
> +
> +always		:= $(dtb-y)
> +subdir-y	:= $(dts-dirs)
> +clean-files	:= *.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/pine64.dts b/arch/arm64/boot/dts/allwinner/pine64.dts
> new file mode 100644
> index 0000000..ebea5dd
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/pine64.dts
> @@ -0,0 +1,58 @@
> +/*
> + * Copyright (c) 2016 ARM Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This library is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "pine64_common.dtsi"
> +
> +/ {
> +	model = "Pine64";
> +	compatible = "pine64,pine64", "allwinner,a64", "allwinner,sunxi";
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	memory {
> +		reg = <0x40000000 0x20000000>;
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/pine64_common.dtsi b/arch/arm64/boot/dts/allwinner/pine64_common.dtsi
> new file mode 100644
> index 0000000..d968d76
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/pine64_common.dtsi
> @@ -0,0 +1,76 @@
> +/*
> + * Copyright (c) 2016 ARM Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This library is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "a64.dtsi"
> +
> +&mmc0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mmc0_pins>, <&mmc0_default_cd_pin>;
> +	vmmc-supply = <&reg_vcc3v3>;
> +	cd-gpios = <&pio 5 6 0>;
> +	cd-inverted;
> +	status = "okay";
> +};
> +
> +&uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_pins_a>;
> +	status = "okay";
> +};
> +
> +&uart2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart2_pins>;
> +	status = "okay";
> +};
> +
> +&uart3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart3_pins_a>;
> +	status = "okay";
> +};
> +
> +&uart4 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart4_pins>;
> +	status = "okay";
> +};

Our policy for boards with "open" pin headers the user can plug
anything he wants is that unless the pin is explicitly dedicated to
that usage, we simply leave them aside so that we don't enforce
anything.

From the quick look at the schematics, I guess only the UART0 on the
10-pin expansion header is elligible.

> diff --git a/arch/arm64/boot/dts/allwinner/pine64_plus.dts b/arch/arm64/boot/dts/allwinner/pine64_plus.dts
> new file mode 100644
> index 0000000..344752e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/pine64_plus.dts
> @@ -0,0 +1,59 @@
> +/*
> + * Copyright (c) 2016 ARM Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This library is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "pine64_common.dtsi"
> +
> +/ {
> +	model = "Pine64+";
> +	compatible = "pine64,pine64_plus", "allwinner,a64", "allwinner,sunxi";

The usual separator in the compatibles is a dash and not an underscore.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160205/232729b4/attachment.sig>

From u.kleine-koenig at pengutronix.de  Fri Feb  5 01:05:45 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Fri, 5 Feb 2016 10:05:45 +0100
Subject: [PATCH v2 2/3] Input: rotary-encoder - move configuration data
 to driver data
In-Reply-To: <20160204211842.GA40137@dtor-ws>
References: <1454408678-6011-1-git-send-email-u.kleine-koenig@pengutronix.de>
 <1454408678-6011-3-git-send-email-u.kleine-koenig@pengutronix.de>
 <56B09CAB.5020600@zonque.org>
 <20160203093527.GD13664@pengutronix.de>
 <20160204211842.GA40137@dtor-ws>
Message-ID: <20160205090545.GM13664@pengutronix.de>

Hello Dmitry,

On Thu, Feb 04, 2016 at 01:18:42PM -0800, Dmitry Torokhov wrote:
> On Wed, Feb 03, 2016 at 10:35:27AM +0100, Uwe Kleine-K?nig wrote:
> > Hello,
> > 
> > On Tue, Feb 02, 2016 at 01:10:19PM +0100, Daniel Mack wrote:
> > > On 02/02/2016 11:24 AM, Uwe Kleine-K?nig wrote:
> > > > This is a preparation for the next patche. There is no change in
> > > > behaviour intended.
> > > 
> > > This one looks good to me, but it clashes with Dmitry's latest patch
> > > sets (which I haven't found the time to test yet, sorry!).
> > 
> > There is nothing in next-20160203, so I assume Dmitry either fixes this
> > up when applying my patches or tells me when I should rebase.
> 
> Please take a look at my rotary-encoder branch. I am waiting to merge it
> into next until I can get some testers. If you have raumfild device that
> would be awesome.

I don't have a raumfeld device. I did a similar conversion and the only
relevant difference is that I used

	.dev_id = "rotary_encoder.0",

while you used

	.dev_id = "rotary-encoder",

in raumfeld_rotary_gpios_table.
I think a mixture of these is the right thing, i.e.

	.dev_id = "rotary-encoder.0",

Your series obsoletes my first two patches, so I will port my third
patch on top of your branch and retest there.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From ard.biesheuvel at linaro.org  Fri Feb  5 01:05:57 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 5 Feb 2016 10:05:57 +0100
Subject: [PATCH] ARM: remove duplicate definitions of __vectors_start and
 __stubs_start
In-Reply-To: <alpine.LFD.2.20.1602041148050.17825@knanqh.ubzr>
References: <1454574705-15109-1-git-send-email-ard.biesheuvel@linaro.org>
 <alpine.LFD.2.20.1602041148050.17825@knanqh.ubzr>
Message-ID: <CAKv+Gu9tbU2wuuxzA=Na1SGH-Au+_Fz+zfu0oTYhWWVsd6=qpw@mail.gmail.com>

On 4 February 2016 at 17:49, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> On Thu, 4 Feb 2016, Ard Biesheuvel wrote:
>
>> Commit b9b32bf70f2f ("ARM: use linker magic for vectors and vector stubs")
>> introduced new global definitions of __vectors_start and __stubs_start,
>> and changed the existing ones to have internal linkage only. However, these
>> symbols are still visible to kallsyms, and due to the way the .vectors and
>> .stubs sections are emitted at the base of the VMA space, these duplicate
>> definitions have conflicting values.
>>
>>   $ nm -n vmlinux |grep -E __vectors\|__stubs
>>   00000000 t __vectors_start
>>   00001000 t __stubs_start
>>   c0e77000 T __vectors_start
>>   c0e77020 T __stubs_start
>>
>> This is completely harmless by itself, since the wrong values are local
>> symbols that cannot be referenced by other object files directly. However,
>> since these symbols are also listed in the kallsyms symbol table in some
>> cases (i.e., CONFIG_KALLSYMS_ALL=y and CONFIG_XIP_KERNEL=y), having these
>> conflicting values can be confusing. So either remove them, or make them
>> strictly local.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>
> Acked-by: Nicolas Pitre <nico at linaro.org>
>

Thanks. Submitted as  8514/1


From p.zabel at pengutronix.de  Fri Feb  5 01:08:24 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 05 Feb 2016 10:08:24 +0100
Subject: [PATCH v3 3/3] reset: Add support for shared reset controls
In-Reply-To: <1453918516-3078-4-git-send-email-hdegoede@redhat.com>
References: <1453918516-3078-1-git-send-email-hdegoede@redhat.com>
 <1453918516-3078-4-git-send-email-hdegoede@redhat.com>
Message-ID: <1454663304.6406.3.camel@pengutronix.de>

Am Mittwoch, den 27.01.2016, 19:15 +0100 schrieb Hans de Goede:
[...]
> @@ -94,9 +99,16 @@ EXPORT_SYMBOL_GPL(reset_controller_unregister);
>  /**
>   * reset_control_reset - reset the controlled device
>   * @rstc: reset controller
> + *
> + * Calling this on a shared reset controller is an error.
>   */
>  int reset_control_reset(struct reset_control *rstc)
>  {
> +	if (rstc->shared) {
> +		WARN_ON(1);
> +		return -EINVAL;

Occurrences of
	if (condition) {
		WARN_ON(1);
		...
	}
could be changed to
	if (WARN_ON(condition)) {
		...
	}

regards
Philipp



From arnd at arndb.de  Fri Feb  5 01:18:33 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 05 Feb 2016 10:18:33 +0100
Subject: [PATCH v4 1/1] USB: core: let USB device know device node
In-Reply-To: <20160205061124.GB1858@shlinux2>
References: <1453706679-18948-1-git-send-email-peter.chen@freescale.com>
 <1454582690.3356.18.camel@pengutronix.de> <20160205061124.GB1858@shlinux2>
Message-ID: <11643765.fRmuASojtz@wuerfel>

On Friday 05 February 2016 14:11:25 Peter Chen wrote:
> On Thu, Feb 04, 2016 at 11:44:50AM +0100, Philipp Zabel wrote:
> > Am Montag, den 25.01.2016, 15:24 +0800 schrieb Peter Chen:
> > > diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt b/Documentation/devicetree/bindings/usb/usb-device.txt
> > > new file mode 100644
> > > index 0000000..c702885
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/usb/usb-device.txt
> > > @@ -0,0 +1,25 @@
> > > +Generic USB Device Properties
> > > +
> > > +Usually, we only use device tree for hard wired USB device.
> > > +The reference binding doc is from:
> > > +http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
> > > +
> > > +Required properties:
> > > +- compatible: usbVID,PID
> > 
> > The reference recommendation states that for single-configuration USB
> > devices the compatible should contain all of the applicable strings from
> > the list starting with 2) "usbVID,PID.REV" and ending with 11)
> > "usb,device". Are we going to ignore this?
> > 
> 
> I have not seen benefits if we write several compatibles in dts,
> the information of compatibles listed in doc can be got during
> the enumeration.
> 
> I suggest we use the simple pattern for this compatible, in that
> case, every one can be easy to follow it, and will not be confused
> which compatibles should be used, and the style can be unify.

It seems fine, as we don't expect any OS to ever use the compatible
strings for binding to the driver. I think you should add a sentence
to explain this, and maybe clarify that the compatible strings from
the standard binding may also be used, but that a device adhering
to this binding may leave out all except for usbVID,PID

> > 
> > > +		compatible = "usb05e3,0608";
> > > +		reg = <0x1>;
> > > +	};
> > 
> > I'd have written this node as:
> > 
> > 	hub: hub at 1 {
> > 		compatible = "usb5e3,608", "usb5e3,class9",
> > 			     "usb,class9", "usb,device";
> > 		reg = <1>;
> > 	};
> 
> The reg should be hexadecimal, do we need to add "0x" before the value?

The formatting of the numbers in properties is not normative, either
one works and has the same meaning. I would leave out the leading 0x
here too, as we are just enumerating the ports.

I don't think that any USB hub has more than 9 ports, so it's not
ambiguous to the reader.

	Arnd


From fu.wei at linaro.org  Fri Feb  5 01:20:29 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Fri, 5 Feb 2016 17:20:29 +0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <56B37FA0.5000209@codeaurora.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <CANLsYkyLBfSKFM6CCyPP+Eaua2B+n80wL2hnQVSvfUNMPd3OdQ@mail.gmail.com>
 <56B37FA0.5000209@codeaurora.org>
Message-ID: <CADyBb7uUK-vTpm9gtxNqtbS6gxbpZdKNKspqzX8wGTNHbdH_HQ@mail.gmail.com>

On 5 February 2016 at 00:43, Timur Tabi <timur at codeaurora.org> wrote:
> Mathieu Poirier wrote:
>>>
>>> >+#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
>>> >+       irq = platform_get_irq(pdev, 0);
>>> >+       if (irq < 0) {
>>> >+               dev_err(dev, "unable to get ws0 interrupt.\n");
>>> >+               return irq;
>>> >+       }
>>> >+#endif
>>> >+
>>
>> Can't the driver revert to single stage mode if platform_get_irq()
>> fails?  That way the value of 'irq' can be tested throughout the
>> _probe() function and the #ifdefs removed.
>
>
> I like that idea.  The same can be done with the devm_request_irq() call.
> It should definitely still display a warning if the command-line option is
> set but no interrupt is available.

Yes, I agree with that too, brilliant idea, this will be in v11 patchset



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From arnd at arndb.de  Fri Feb  5 01:20:21 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri,  5 Feb 2016 10:20:21 +0100
Subject: [PATCH] netfilter: tee: select NF_DUP_IPV6 unconditionally
Message-ID: <1454664040-1344109-1-git-send-email-arnd@arndb.de>

The NETFILTER_XT_TARGET_TEE option selects NF_DUP_IPV6 whenever
IP6_NF_IPTABLES is enabled, and it ensures that it cannot be
builtin itself if NF_CONNTRACK is a loadable module, as that
is a dependency for NF_DUP_IPV6.

However, NF_DUP_IPV6 can be enabled even if IP6_NF_IPTABLES is
turned off, and it only really depends on IPV6. With the current
check in tee_tg6, we call nf_dup_ipv6() whenever NF_DUP_IPV6
is enabled. This can however be a loadable module which is
unreachable from a built-in xt_TEE:

net/built-in.o: In function `tee_tg6':
:(.text+0x67728): undefined reference to `nf_dup_ipv6'

The bug was originally introduced in the split of the xt_TEE module
into separate modules for ipv4 and ipv6, and two patches tried
to fix it unsuccessfully afterwards.

This is a revert of the the first incorrect attempt to fix it,
going back to depending on IPV6 as the dependency, and we
adapt the 'select' condition accordingly.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: bbde9fc1824a ("netfilter: factor out packet duplication for IPv4/IPv6")
Fixes: 116984a316c3 ("netfilter: xt_TEE: use IS_ENABLED(CONFIG_NF_DUP_IPV6)")
Fixes: 74ec4d55c4d2 ("netfilter: fix xt_TEE and xt_TPROXY dependencies")
---
 net/netfilter/Kconfig  | 2 +-
 net/netfilter/xt_TEE.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 8c067e6663a1..95e757c377f9 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -891,7 +891,7 @@ config NETFILTER_XT_TARGET_TEE
 	depends on IPV6 || IPV6=n
 	depends on !NF_CONNTRACK || NF_CONNTRACK
 	select NF_DUP_IPV4
-	select NF_DUP_IPV6 if IP6_NF_IPTABLES != n
+	select NF_DUP_IPV6 if IPV6
 	---help---
 	This option adds a "TEE" target with which a packet can be cloned and
 	this clone be rerouted to another nexthop.
diff --git a/net/netfilter/xt_TEE.c b/net/netfilter/xt_TEE.c
index 3eff7b67cdf2..6e57a3966dc5 100644
--- a/net/netfilter/xt_TEE.c
+++ b/net/netfilter/xt_TEE.c
@@ -38,7 +38,7 @@ tee_tg4(struct sk_buff *skb, const struct xt_action_param *par)
 	return XT_CONTINUE;
 }
 
-#if IS_ENABLED(CONFIG_NF_DUP_IPV6)
+#if IS_ENABLED(CONFIG_IPV6)
 static unsigned int
 tee_tg6(struct sk_buff *skb, const struct xt_action_param *par)
 {
@@ -131,7 +131,7 @@ static struct xt_target tee_tg_reg[] __read_mostly = {
 		.destroy    = tee_tg_destroy,
 		.me         = THIS_MODULE,
 	},
-#if IS_ENABLED(CONFIG_NF_DUP_IPV6)
+#if IS_ENABLED(CONFIG_IPV6)
 	{
 		.name       = "TEE",
 		.revision   = 1,
-- 
2.7.0



From boris.brezillon at free-electrons.com  Fri Feb  5 01:27:10 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 5 Feb 2016 10:27:10 +0100
Subject: [PATCH v2 05/51] mtd: add mtd_ooblayout_xxx() helper functions
In-Reply-To: <1454580434-32078-6-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
 <1454580434-32078-6-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <20160205102710.39fa4244@bbrezillon>

On Thu,  4 Feb 2016 11:06:28 +0100
Boris Brezillon <boris.brezillon at free-electrons.com> wrote:

> In order to make the ecclayout definition completely dynamic we need to
> rework the way the OOB layout are defined and iterated.
> 
> Create a few mtd_ooblayout_xxx() helpers to ease OOB bytes manipulation
> and hide ecclayout internals to their users.
> 
> Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
> ---
>  drivers/mtd/mtdcore.c   | 401 ++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/mtd/mtd.h |  33 ++++
>  2 files changed, 434 insertions(+)
> 
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 3096251..14e46ca 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -997,6 +997,407 @@ int mtd_read_oob(struct mtd_info *mtd, loff_t from, struct mtd_oob_ops *ops)
>  }
>  EXPORT_SYMBOL_GPL(mtd_read_oob);
>  
> +/**
> + * mtd_ooblayout_ecc - Get the OOB region definition of a specific ECC section
> + * @mtd: MTD device structure
> + * @section: ECC section. Depending on the layout you may have all the ECC
> + *	     bytes stored in a single contiguous section, or one section
> + *	     per ECC chunk (and sometime several sections for a single ECC
> + *	     ECC chunk)
> + * @oobecc: OOB region struct filled with the appropriate ECC position
> + *	    information
> + *
> + * This functions return ECC section information in the OOB area. I you want
> + * to get all the ECC bytes information, then you should call
> + * mtd_ooblayout_ecc(mtd, section++, oobecc) until it returns -ERANGE.
> + *
> + * Returns zero on success, a negative error code otherwise.
> + */
> +int mtd_ooblayout_ecc(struct mtd_info *mtd, int section,
> +		      struct mtd_oob_region *oobecc)
> +{
> +	int eccbyte = 0, cursection = 0, length = 0, eccpos = 0;
> +
> +	memset(oobecc, 0, sizeof(*oobecc));
> +
> +	if (!mtd || section < 0)
> +		return -EINVAL;
> +
> +	if (!mtd->ecclayout)
> +		return -ENOTSUPP;
> +
> +	if (mtd->ecclayout->eccbytes < 1)
> +		return -ERANGE;
> +
> +	/*
> +	 * This logic allows us to reuse the ->ecclayout information and
> +	 * expose them as ECC regions (as done for the OOB free regions).
> +	 *
> +	 * TODO: this should be dropped as soon as we get rid of the
> +	 * ->ecclayout field.
> +	 */
> +	for (eccbyte = 0; eccbyte < mtd->ecclayout->eccbytes; eccbyte++) {
> +		eccpos = mtd->ecclayout->eccpos[eccbyte];
> +
> +		if (eccbyte < mtd->ecclayout->eccbytes - 1) {
> +			int neccpos = mtd->ecclayout->eccpos[eccbyte + 1];
> +
> +			if (eccpos + 1 == neccpos) {
> +				length++;
> +				continue;
> +			}
> +		}
> +
> +		if (section == cursection)
> +			break;
> +
> +		length = 0;
> +		cursection++;
> +	}
> +
> +	if (cursection != section)

Should be
	if (cursection != section ||
	    eccbyte >= mtd->ecclayout->eccbytes)

Will fix that too.

> +		return -ERANGE;
> +
> +	oobecc->length = length + 1;
> +	oobecc->offset = eccpos - length;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(mtd_ooblayout_ecc);


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


From maxime.ripard at free-electrons.com  Fri Feb  5 01:27:39 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 5 Feb 2016 10:27:39 +0100
Subject: [PATCH v4 2/2] ASoC: sunxi: Add support for the SPDIF block
In-Reply-To: <1454584162-32449-3-git-send-email-codekipper@gmail.com>
References: <1454584162-32449-1-git-send-email-codekipper@gmail.com>
 <1454584162-32449-3-git-send-email-codekipper@gmail.com>
Message-ID: <20160205092739.GE1139@lukather>

Hi,

On Thu, Feb 04, 2016 at 12:09:22PM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
> 
> The sun4i, sun5i and sun7i SoC families have an SPDIF
> block which is capable of playback and capture.
> 
> This patch enables the playback of this block for
> the sun4i families.
> 
> Signed-off-by: Marcus Cooper <codekipper at gmail.com>
> ---
>  sound/soc/sunxi/Kconfig       |   8 +
>  sound/soc/sunxi/Makefile      |   1 +
>  sound/soc/sunxi/sun4i-spdif.c | 561 ++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 570 insertions(+)
>  create mode 100644 sound/soc/sunxi/sun4i-spdif.c
> 
> diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
> index 84c72ec..6af7224 100644
> --- a/sound/soc/sunxi/Kconfig
> +++ b/sound/soc/sunxi/Kconfig
> @@ -8,4 +8,12 @@ config SND_SUN4I_CODEC
>  	  Select Y or M to add support for the Codec embedded in the Allwinner
>  	  A10 and affiliated SoCs.
>  
> +config SND_SUN4I_SPDIF
> +        tristate "Allwinner A10 SPDIF Support"
> +	depends on OF

The indentation looks off.

> +        select SND_SOC_GENERIC_DMAENGINE_PCM
> +        select REGMAP_MMIO
> +        help
> +          Say Y or M to add support for the S/PDIF audio block in the Allwinner
> +	  A10 and affiliated SoCs.

Here as well.

>  endmenu
> diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
> index ea8a08c..8f5e889 100644
> --- a/sound/soc/sunxi/Makefile
> +++ b/sound/soc/sunxi/Makefile
> @@ -1,2 +1,3 @@
>  obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
>  
> +obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o
> diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
> new file mode 100644
> index 0000000..bb32344
> --- /dev/null
> +++ b/sound/soc/sunxi/sun4i-spdif.c
> @@ -0,0 +1,561 @@
> +/*
> + * ALSA SoC SPDIF Audio Layer
> + *
> + * Copyright 2015 Andrea Venturi <be17068 at iperbole.bo.it>
> + * Copyright 2015 Marcus Cooper <codekipper at gmail.com>
> + *
> + * Based on the Allwinner SDK driver, released under the GPL.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/regmap.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/ioport.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <sound/dmaengine_pcm.h>
> +#include <sound/pcm_params.h>
> +#include <sound/soc.h>
> +
> +#define	SUN4I_SPDIF_CTL		(0x00)
> +	#define SUN4I_SPDIF_CTL_MCLKDIV(v)		((v) << 4) /* v even */
> +	#define SUN4I_SPDIF_CTL_MCLKOUTEN		BIT(2)
> +	#define SUN4I_SPDIF_CTL_GEN			BIT(1)
> +	#define SUN4I_SPDIF_CTL_RESET			BIT(0)
> +
> +#define SUN4I_SPDIF_TXCFG	(0x04)
> +	#define SUN4I_SPDIF_TXCFG_SINGLEMOD		BIT(31)
> +	#define SUN4I_SPDIF_TXCFG_ASS			BIT(17)
> +	#define SUN4I_SPDIF_TXCFG_NONAUDIO		BIT(16)
> +	#define SUN4I_SPDIF_TXCFG_TXRATIO(v)		((v) << 4)
> +	#define SUN4I_SPDIF_TXCFG_TXRATIO_MASK		GENMASK(8, 4)
> +	#define SUN4I_SPDIF_TXCFG_FMTRVD		GENMASK(3, 2)
> +	#define SUN4I_SPDIF_TXCFG_FMT16BIT		(0 << 2)
> +	#define SUN4I_SPDIF_TXCFG_FMT20BIT		(1 << 2)
> +	#define SUN4I_SPDIF_TXCFG_FMT24BIT		(2 << 2)
> +	#define SUN4I_SPDIF_TXCFG_CHSTMODE		BIT(1)
> +	#define SUN4I_SPDIF_TXCFG_TXEN			BIT(0)
> +
> +#define SUN4I_SPDIF_RXCFG	(0x08)
> +	#define SUN4I_SPDIF_RXCFG_LOCKFLAG		BIT(4)
> +	#define SUN4I_SPDIF_RXCFG_CHSTSRC		BIT(3)
> +	#define SUN4I_SPDIF_RXCFG_CHSTCP		BIT(1)
> +	#define SUN4I_SPDIF_RXCFG_RXEN			BIT(0)
> +
> +#define SUN4I_SPDIF_TXFIFO	(0x0C)
> +
> +#define SUN4I_SPDIF_RXFIFO	(0x10)
> +
> +#define SUN4I_SPDIF_FCTL	(0x14)
> +	#define SUN4I_SPDIF_FCTL_FIFOSRC		BIT(31)
> +	#define SUN4I_SPDIF_FCTL_FTX			BIT(17)
> +	#define SUN4I_SPDIF_FCTL_FRX			BIT(16)
> +	#define SUN4I_SPDIF_FCTL_TXTL(v)		((v) << 8)
> +	#define SUN4I_SPDIF_FCTL_TXTL_MASK		GENMASK(12, 8)
> +	#define SUN4I_SPDIF_FCTL_RXTL(v)		((v) << 3)
> +	#define SUN4I_SPDIF_FCTL_RXTL_MASK		GENMASK(7, 3)
> +	#define SUN4I_SPDIF_FCTL_TXIM			BIT(2)
> +	#define SUN4I_SPDIF_FCTL_RXOM(v)		((v) << 0)
> +	#define SUN4I_SPDIF_FCTL_RXOM_MASK		GENMASK(1, 0)
> +
> +#define SUN4I_SPDIF_FSTA	(0x18)
> +	#define SUN4I_SPDIF_FSTA_TXE			BIT(14)
> +	#define SUN4I_SPDIF_FSTA_TXECNTSHT		(8)
> +	#define SUN4I_SPDIF_FSTA_RXA			BIT(6)
> +	#define SUN4I_SPDIF_FSTA_RXACNTSHT		(0)
> +
> +#define SUN4I_SPDIF_INT		(0x1C)
> +	#define SUN4I_SPDIF_INT_RXLOCKEN		BIT(18)
> +	#define SUN4I_SPDIF_INT_RXUNLOCKEN		BIT(17)
> +	#define SUN4I_SPDIF_INT_RXPARERREN		BIT(16)
> +	#define SUN4I_SPDIF_INT_TXDRQEN			BIT(7)
> +	#define SUN4I_SPDIF_INT_TXUIEN			BIT(6)
> +	#define SUN4I_SPDIF_INT_TXOIEN			BIT(5)
> +	#define SUN4I_SPDIF_INT_TXEIEN			BIT(4)
> +	#define SUN4I_SPDIF_INT_RXDRQEN			BIT(2)
> +	#define SUN4I_SPDIF_INT_RXOIEN			BIT(1)
> +	#define SUN4I_SPDIF_INT_RXAIEN			BIT(0)
> +
> +#define SUN4I_SPDIF_ISTA	(0x20)
> +	#define SUN4I_SPDIF_ISTA_RXLOCKSTA		BIT(18)
> +	#define SUN4I_SPDIF_ISTA_RXUNLOCKSTA		BIT(17)
> +	#define SUN4I_SPDIF_ISTA_RXPARERRSTA		BIT(16)
> +	#define SUN4I_SPDIF_ISTA_TXUSTA			BIT(6)
> +	#define SUN4I_SPDIF_ISTA_TXOSTA			BIT(5)
> +	#define SUN4I_SPDIF_ISTA_TXESTA			BIT(4)
> +	#define SUN4I_SPDIF_ISTA_RXOSTA			BIT(1)
> +	#define SUN4I_SPDIF_ISTA_RXASTA			BIT(0)
> +
> +#define SUN4I_SPDIF_TXCNT	(0x24)
> +
> +#define SUN4I_SPDIF_RXCNT	(0x28)
> +
> +#define SUN4I_SPDIF_TXCHSTA0	(0x2C)
> +	#define SUN4I_SPDIF_TXCHSTA0_CLK(v)		((v) << 28)
> +	#define SUN4I_SPDIF_TXCHSTA0_SAMFREQ(v)		((v) << 24)
> +	#define SUN4I_SPDIF_TXCHSTA0_SAMFREQ_MASK	GENMASK(27, 24)
> +	#define SUN4I_SPDIF_TXCHSTA0_CHNUM(v)		((v) << 20)
> +	#define SUN4I_SPDIF_TXCHSTA0_CHNUM_MASK		GENMASK(23, 20)
> +	#define SUN4I_SPDIF_TXCHSTA0_SRCNUM(v)		((v) << 16)
> +	#define SUN4I_SPDIF_TXCHSTA0_CATACOD(v)		((v) << 8)
> +	#define SUN4I_SPDIF_TXCHSTA0_MODE(v)		((v) << 6)
> +	#define SUN4I_SPDIF_TXCHSTA0_EMPHASIS(v)	((v) << 3)
> +	#define SUN4I_SPDIF_TXCHSTA0_CP			BIT(2)
> +	#define SUN4I_SPDIF_TXCHSTA0_AUDIO		BIT(1)
> +	#define SUN4I_SPDIF_TXCHSTA0_PRO		BIT(0)
> +
> +#define SUN4I_SPDIF_TXCHSTA1	(0x30)
> +	#define SUN4I_SPDIF_TXCHSTA1_CGMSA(v)		((v) << 8)
> +	#define SUN4I_SPDIF_TXCHSTA1_ORISAMFREQ(v)	((v) << 4)
> +	#define SUN4I_SPDIF_TXCHSTA1_ORISAMFREQ_MASK	GENMASK(7, 4)
> +	#define SUN4I_SPDIF_TXCHSTA1_SAMWORDLEN(v)	((v) << 1)
> +	#define SUN4I_SPDIF_TXCHSTA1_MAXWORDLEN		BIT(0)
> +
> +#define SUN4I_SPDIF_RXCHSTA0	(0x34)
> +	#define SUN4I_SPDIF_RXCHSTA0_CLK(v)		((v) << 28)
> +	#define SUN4I_SPDIF_RXCHSTA0_SAMFREQ(v)		((v) << 24)
> +	#define SUN4I_SPDIF_RXCHSTA0_CHNUM(v)		((v) << 20)
> +	#define SUN4I_SPDIF_RXCHSTA0_SRCNUM(v)		((v) << 16)
> +	#define SUN4I_SPDIF_RXCHSTA0_CATACOD(v)		((v) << 8)
> +	#define SUN4I_SPDIF_RXCHSTA0_MODE(v)		((v) << 6)
> +	#define SUN4I_SPDIF_RXCHSTA0_EMPHASIS(v)	((v) << 3)
> +	#define SUN4I_SPDIF_RXCHSTA0_CP			BIT(2)
> +	#define SUN4I_SPDIF_RXCHSTA0_AUDIO		BIT(1)
> +	#define SUN4I_SPDIF_RXCHSTA0_PRO		BIT(0)
> +
> +#define SUN4I_SPDIF_RXCHSTA1	(0x38)
> +	#define SUN4I_SPDIF_RXCHSTA1_CGMSA(v)		((v) << 8)
> +	#define SUN4I_SPDIF_RXCHSTA1_ORISAMFREQ(v)	((v) << 4)
> +	#define SUN4I_SPDIF_RXCHSTA1_SAMWORDLEN(v)	((v) << 1)
> +	#define SUN4I_SPDIF_RXCHSTA1_MAXWORDLEN		BIT(0)
> +
> +/* Defines for Sampling Frequency */
> +#define SUN4I_SPDIF_SAMFREQ_44_1KHZ		0x0
> +#define SUN4I_SPDIF_SAMFREQ_NOT_INDICATED	0x1
> +#define SUN4I_SPDIF_SAMFREQ_48KHZ		0x2
> +#define SUN4I_SPDIF_SAMFREQ_32KHZ		0x3
> +#define SUN4I_SPDIF_SAMFREQ_22_05KHZ		0x4
> +#define SUN4I_SPDIF_SAMFREQ_24KHZ		0x6
> +#define SUN4I_SPDIF_SAMFREQ_88_2KHZ		0x8
> +#define SUN4I_SPDIF_SAMFREQ_76_8KHZ		0x9
> +#define SUN4I_SPDIF_SAMFREQ_96KHZ		0xa
> +#define SUN4I_SPDIF_SAMFREQ_176_4KHZ		0xc
> +#define SUN4I_SPDIF_SAMFREQ_192KHZ		0xe
> +
> +/*
> + * Original sampling frequency can be represented by inverting the value of the
> + * sampling frequency.
> + */
> +#define ORIGINAL(v) ((~v) & 0xf)

You're not using that macro anywhere.

> +
> +struct sun4i_spdif_dev {
> +	struct platform_device *pdev;
> +	struct clk *spdif_clk;
> +	struct clk *apb_clk;
> +	struct snd_soc_dai_driver cpu_dai_drv;
> +	struct regmap *regmap;
> +	struct snd_dmaengine_dai_dma_data dma_params_tx;
> +};
> +
> +static void sun4i_spdif_configure(struct sun4i_spdif_dev *host)
> +{
> +	/* soft reset SPDIF */
> +	regmap_write(host->regmap, SUN4I_SPDIF_CTL, SUN4I_SPDIF_CTL_RESET);
> +
> +	/* flush TX FIFO */
> +	regmap_update_bits(host->regmap, SUN4I_SPDIF_FCTL,
> +			   SUN4I_SPDIF_FCTL_FTX, SUN4I_SPDIF_FCTL_FTX);
> +
> +	/* clear TX counter */
> +	regmap_write(host->regmap, SUN4I_SPDIF_TXCNT, 0);
> +}
> +
> +static void sun4i_snd_txctrl_on(struct snd_pcm_substream *substream,
> +				struct sun4i_spdif_dev *host)
> +{
> +	if (substream->runtime->channels == 1)
> +		regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
> +				   SUN4I_SPDIF_TXCFG_SINGLEMOD,
> +				   SUN4I_SPDIF_TXCFG_SINGLEMOD);
> +
> +	/* SPDIF TX ENABLE */
> +	regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
> +			   SUN4I_SPDIF_TXCFG_TXEN, SUN4I_SPDIF_TXCFG_TXEN);
> +
> +	/* DRQ ENABLE */
> +	regmap_update_bits(host->regmap, SUN4I_SPDIF_INT,
> +			   SUN4I_SPDIF_INT_TXDRQEN, SUN4I_SPDIF_INT_TXDRQEN);
> +
> +	/* Global enable */
> +	regmap_update_bits(host->regmap, SUN4I_SPDIF_CTL,
> +			   SUN4I_SPDIF_CTL_GEN, SUN4I_SPDIF_CTL_GEN);
> +}
> +
> +static void sun4i_snd_txctrl_off(struct snd_pcm_substream *substream,
> +				 struct sun4i_spdif_dev *host)
> +{
> +	/* SPDIF TX DISABLE */
> +	regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
> +			   SUN4I_SPDIF_TXCFG_TXEN, 0);
> +
> +	/* DRQ DISABLE */
> +	regmap_update_bits(host->regmap, SUN4I_SPDIF_INT,
> +			   SUN4I_SPDIF_INT_TXDRQEN, 0);
> +
> +	/* Global disable */
> +	regmap_update_bits(host->regmap, SUN4I_SPDIF_CTL,
> +			   SUN4I_SPDIF_CTL_GEN, 0);
> +}
> +
> +static int sun4i_spdif_startup(struct snd_pcm_substream *substream,
> +			       struct snd_soc_dai *cpu_dai)
> +{
> +	struct snd_soc_pcm_runtime *rtd = substream->private_data;
> +	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(rtd->cpu_dai);
> +
> +	if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK)
> +		return -EINVAL;
> +
> +	sun4i_spdif_configure(host);
> +
> +	return 0;
> +}
> +
> +static int sun4i_spdif_hw_params(struct snd_pcm_substream *substream,
> +				 struct snd_pcm_hw_params *params,
> +				 struct snd_soc_dai *cpu_dai)
> +{
> +	int ret = 0;
> +	int fmt;
> +	unsigned long rate = params_rate(params);
> +	u32 mclk_div = 0;
> +	unsigned int mclk = 0;
> +	u32 reg_val;
> +	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
> +	struct platform_device *pdev = host->pdev;
> +
> +	/* Add the PCM and raw data select interface */
> +	switch (params_channels(params)) {
> +	case 1: /* PCM mode */
> +	case 2:
> +		fmt = 0;
> +		break;
> +	case 4: /* raw data mode */
> +		fmt = SUN4I_SPDIF_TXCFG_NONAUDIO;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	switch (params_format(params)) {
> +	case SNDRV_PCM_FORMAT_S16_LE:
> +		fmt |= SUN4I_SPDIF_TXCFG_FMT16BIT;
> +		break;
> +	case SNDRV_PCM_FORMAT_S20_3LE:
> +		fmt |= SUN4I_SPDIF_TXCFG_FMT20BIT;
> +		break;
> +	case SNDRV_PCM_FORMAT_S24_LE:
> +		fmt |= SUN4I_SPDIF_TXCFG_FMT24BIT;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	switch (rate) {
> +	case 22050:
> +	case 44100:
> +	case 88200:
> +	case 176400:
> +		mclk = 22579200;
> +		break;
> +	case 24000:
> +	case 32000:
> +	case 48000:
> +	case 96000:
> +	case 192000:
> +		mclk = 24576000;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	ret = clk_set_rate(host->spdif_clk, mclk);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev,
> +			"Setting SPDIF clock rate for %d Hz failed!\n", mclk);
> +		return ret;
> +	}
> +
> +	regmap_update_bits(host->regmap, SUN4I_SPDIF_FCTL,
> +			   SUN4I_SPDIF_FCTL_TXIM, SUN4I_SPDIF_FCTL_TXIM);
> +
> +	switch (rate) {
> +	case 22050:
> +	case 24000:
> +		mclk_div = 8;
> +		break;
> +	case 32000:
> +		mclk_div = 6;
> +		break;
> +	case 44100:
> +	case 48000:
> +		mclk_div = 4;
> +		break;
> +	case 88200:
> +	case 96000:
> +		mclk_div = 2;
> +		break;
> +	case 176400:
> +	case 192000:
> +		mclk_div = 1;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	reg_val = 0;
> +	reg_val |= SUN4I_SPDIF_TXCFG_ASS;
> +	reg_val |= fmt; /* set non audio and bit depth */
> +	reg_val |= SUN4I_SPDIF_TXCFG_CHSTMODE;
> +	reg_val |= SUN4I_SPDIF_TXCFG_TXRATIO(mclk_div - 1);
> +	regmap_write(host->regmap, SUN4I_SPDIF_TXCFG, reg_val);
> +
> +	return 0;
> +}
> +
> +static int sun4i_spdif_trigger(struct snd_pcm_substream *substream, int cmd,
> +			       struct snd_soc_dai *dai)
> +{
> +	int ret = 0;
> +	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(dai);
> +
> +	if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK)
> +		return -EINVAL;
> +
> +	switch (cmd) {
> +	case SNDRV_PCM_TRIGGER_START:
> +	case SNDRV_PCM_TRIGGER_RESUME:
> +	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> +		sun4i_snd_txctrl_on(substream, host);
> +		break;
> +
> +	case SNDRV_PCM_TRIGGER_STOP:
> +	case SNDRV_PCM_TRIGGER_SUSPEND:
> +	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> +		sun4i_snd_txctrl_off(substream, host);
> +		break;
> +
> +	default:
> +		ret = -EINVAL;
> +		break;
> +	}
> +	return ret;
> +}
> +
> +static int sun4i_spdif_soc_dai_probe(struct snd_soc_dai *dai)
> +{
> +	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(dai);
> +
> +	snd_soc_dai_init_dma_data(dai, &host->dma_params_tx, NULL);
> +	return 0;
> +}
> +
> +static const struct snd_soc_dai_ops sun4i_spdif_dai_ops = {
> +	.startup	= sun4i_spdif_startup,
> +	.trigger	= sun4i_spdif_trigger,
> +	.hw_params	= sun4i_spdif_hw_params,
> +};
> +
> +static const struct regmap_config sun4i_spdif_regmap_config = {
> +	.reg_bits = 32,
> +	.reg_stride = 4,
> +	.val_bits = 32,
> +	.max_register = SUN4I_SPDIF_RXCHSTA1,
> +};
> +
> +#define SUN4I_RATES	SNDRV_PCM_RATE_8000_192000
> +
> +#define SUN4I_FORMATS	(SNDRV_PCM_FORMAT_S16_LE | \
> +				SNDRV_PCM_FORMAT_S20_3LE | \
> +				SNDRV_PCM_FORMAT_S24_LE)
> +
> +static struct snd_soc_dai_driver sun4i_spdif_dai = {
> +	.playback = {
> +		.channels_min = 1,
> +		.channels_max = 2,
> +		.rates = SUN4I_RATES,
> +		.formats = SUN4I_FORMATS,
> +	},
> +	.probe = sun4i_spdif_soc_dai_probe,
> +	.ops = &sun4i_spdif_dai_ops,
> +	.name = "spdif",
> +};
> +
> +static const struct snd_soc_dapm_widget dit_widgets[] = {
> +	SND_SOC_DAPM_OUTPUT("spdif-out"),
> +};
> +
> +static const struct snd_soc_dapm_route dit_routes[] = {
> +	{ "spdif-out", NULL, "Playback" },
> +};
> +
> +static const struct of_device_id sun4i_spdif_of_match[] = {
> +	{ .compatible = "allwinner,sun4i-a10-spdif", },
> +	{ /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, sun4i_spdif_of_match);
> +
> +static const struct snd_soc_component_driver sun4i_spdif_component = {
> +	.name		= "sun4i-spdif",
> +};
> +
> +static int sun4i_spdif_runtime_suspend(struct device *dev)
> +{
> +	struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
> +
> +	clk_disable_unprepare(host->spdif_clk);
> +	clk_disable_unprepare(host->apb_clk);
> +
> +	return 0;
> +}
> +
> +static int sun4i_spdif_runtime_resume(struct device *dev)
> +{
> +	struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
> +
> +	clk_prepare_enable(host->spdif_clk);
> +	clk_prepare_enable(host->apb_clk);
> +
> +	return 0;
> +}
> +
> +static int sun4i_spdif_probe(struct platform_device *pdev)
> +{
> +	struct sun4i_spdif_dev *host;
> +	struct resource *res;
> +	int ret;
> +	void __iomem *base;
> +
> +	dev_dbg(&pdev->dev, "Entered %s\n", __func__);
> +
> +	host = devm_kzalloc(&pdev->dev, sizeof(*host), GFP_KERNEL);
> +	if (!host)
> +		return -ENOMEM;
> +
> +	host->pdev = pdev;
> +
> +	/* Initialize this copy of the CPU DAI driver structure */
> +	memcpy(&host->cpu_dai_drv, &sun4i_spdif_dai, sizeof(sun4i_spdif_dai));
> +	host->cpu_dai_drv.name = dev_name(&pdev->dev);
> +
> +	/* Get the addresses */
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	base = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(base))
> +		return PTR_ERR(base);
> +
> +	host->regmap = devm_regmap_init_mmio(&pdev->dev, base,
> +						&sun4i_spdif_regmap_config);
> +
> +	/* Clocks */
> +	host->apb_clk = devm_clk_get(&pdev->dev, "apb");
> +	if (IS_ERR(host->apb_clk)) {
> +		dev_err(&pdev->dev, "failed to get a apb clock.\n");
> +		return PTR_ERR(host->apb_clk);
> +	}
> +
> +	ret = clk_prepare_enable(host->apb_clk);
> +	if (ret) {
> +		dev_err(&pdev->dev, "try to enable apb_spdif_clk failed\n");
> +		return ret;
> +	}

You don't need to enable it anymore.

> +
> +	host->spdif_clk = devm_clk_get(&pdev->dev, "spdif");
> +	if (IS_ERR(host->spdif_clk)) {
> +		dev_err(&pdev->dev, "failed to get a spdif clock.\n");
> +		goto err_disable_apb_clk;
> +	}
> +
> +	host->dma_params_tx.addr = res->start + SUN4I_SPDIF_TXFIFO;
> +	host->dma_params_tx.maxburst = 4;
> +	host->dma_params_tx.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
> +
> +	platform_set_drvdata(pdev, host);
> +
> +	ret = devm_snd_soc_register_component(&pdev->dev,
> +				&sun4i_spdif_component, &sun4i_spdif_dai, 1);
> +	if (ret)
> +		goto err_disable_apb_clk;
> +
> +	pm_runtime_enable(&pdev->dev);
> +	if (!pm_runtime_enabled(&pdev->dev)) {
> +		ret = sun4i_spdif_runtime_resume(&pdev->dev);
> +		if (ret)
> +			goto err_unregister;
> +	}
> +
> +	ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
> +	if (ret)
> +		goto err_suspend;
> +	return 0;
> +err_suspend:
> +	if (!pm_runtime_status_suspended(&pdev->dev))
> +		sun4i_spdif_runtime_suspend(&pdev->dev);
> +err_unregister:
> +	pm_runtime_disable(&pdev->dev);
> +	snd_soc_unregister_component(&pdev->dev);
> +err_disable_apb_clk:
> +	clk_disable_unprepare(host->apb_clk);
> +	return ret;
> +}
> +
> +static int sun4i_spdif_remove(struct platform_device *pdev)
> +{
> +	pm_runtime_disable(&pdev->dev);
> +	if (!pm_runtime_status_suspended(&pdev->dev))
> +		sun4i_spdif_runtime_suspend(&pdev->dev);
> +
> +	snd_soc_unregister_platform(&pdev->dev);
> +	snd_soc_unregister_component(&pdev->dev);
> +
> +	return 0;
> +}
> +
> +static const struct dev_pm_ops sun4i_spdif_pm = {
> +	SET_RUNTIME_PM_OPS(sun4i_spdif_runtime_suspend,
> +			   sun4i_spdif_runtime_resume, NULL)
> +};
> +
> +static struct platform_driver sun4i_spdif_driver = {
> +	.driver		= {
> +		.name	= "sun4i-spdif",
> +		.of_match_table = of_match_ptr(sun4i_spdif_of_match),
> +		.pm	= &sun4i_spdif_pm,
> +	},
> +	.probe		= sun4i_spdif_probe,
> +	.remove		= sun4i_spdif_remove,
> +};
> +
> +module_platform_driver(sun4i_spdif_driver);
> +
> +MODULE_AUTHOR("Marcus Cooper <codekipper at gmail.com>");
> +MODULE_AUTHOR("Andrea Venturi <be17068 at iperbole.bo.it>");
> +MODULE_DESCRIPTION("Allwinner sun4i SPDIF SoC Interface");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:sun4i-spdif");
> -- 
> 2.7.0
> 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160205/1cdd834b/attachment-0001.sig>

From juri.lelli at arm.com  Fri Feb  5 01:30:40 2016
From: juri.lelli at arm.com (Juri Lelli)
Date: Fri, 5 Feb 2016 09:30:40 +0000
Subject: [PATCH v3 2/6] drivers/cpufreq: implement
 init_cpu_capacity_default()
In-Reply-To: <CAKfTPtD4jTmUZoShGBm3oAFywizjp8jsEukmkeZU+x+zk-KZRA@mail.gmail.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <1454500799-18451-3-git-send-email-juri.lelli@arm.com>
 <CAKfTPtDGk5BC25WqHdhDYDOBgUsuidAMhrXS=eDi6wJPZjfrwA@mail.gmail.com>
 <20160204093559.GA14099@e105550-lin.cambridge.arm.com>
 <CAKfTPtB4G3bP5N0hU6zWXJTddO34x3RnyGpp-4_otc8O=Wq2hw@mail.gmail.com>
 <20160204121620.GB29586@e106622-lin>
 <CAKfTPtDVasamRtG2kLxP0HsohmVQTPrXRgx36e+jb3gozDoo6g@mail.gmail.com>
 <20160204141345.GD29586@e106622-lin>
 <CAKfTPtDWP-AgqXsSuxCfVj33dh+i7oqDTkL=gUy7n-AB1anoow@mail.gmail.com>
 <CAKfTPtD4jTmUZoShGBm3oAFywizjp8jsEukmkeZU+x+zk-KZRA@mail.gmail.com>
Message-ID: <20160205093040.GG29586@e106622-lin>

On 04/02/16 16:46, Vincent Guittot wrote:
> On 4 February 2016 at 16:44, Vincent Guittot <vincent.guittot at linaro.org> wrote:
> > On 4 February 2016 at 15:13, Juri Lelli <juri.lelli at arm.com> wrote:
> >> On 04/02/16 13:35, Vincent Guittot wrote:
> >>> On 4 February 2016 at 13:16, Juri Lelli <juri.lelli at arm.com> wrote:
> >>> > Hi Vincent,
> >>> >
> >>> > On 04/02/16 13:03, Vincent Guittot wrote:
> >>> >> On 4 February 2016 at 10:36, Morten Rasmussen <morten.rasmussen at arm.com> wrote:
> >>> >> > On Wed, Feb 03, 2016 at 10:04:37PM +0100, Vincent Guittot wrote:
> >>> >> >> On 3 February 2016 at 12:59, Juri Lelli <juri.lelli at arm.com> wrote:
> >>> >>
> >>> >> [snip]
> >>> >>
> >>> >> >> > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> >>> >> >> > index 9e63fb1..c4025fd 100644
> >>> >> >> > --- a/drivers/cpufreq/Makefile
> >>> >> >> > +++ b/drivers/cpufreq/Makefile
> >>> >> >> > @@ -1,5 +1,5 @@
> >>> >> >> >  # CPUfreq core
> >>> >> >> > -obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o
> >>> >> >> > +obj-$(CONFIG_CPU_FREQ)                 += cpufreq.o freq_table.o cpufreq_capacity.o
> >>> >> >>
> >>> >> >> Do you really want to have the calibration of capacity dependent of
> >>> >> >> cpufreq ? It means that we can't use it without a cpufreq driver.
> >>> >> >> IMHO, this creates a unnecessary dependency. I understand that you
> >>> >> >> must ensure that core runs at max fequency if a driver is present but
> >>> >> >> you should be able to calibrate the capacity if cpufreq is not
> >>> >> >> available but you have different capacity because micro architecture
> >>> >> >
> >>> >> > We could remove the dependency on cpufreq, but it would make things more
> >>> >> > complicated for systems which do have frequency scaling as we would have
> >>> >> > to either:
> >>> >> >
> >>> >> > 1) Run the calibration again once cpufreq has been initialized.
> >>> >>
> >>> >> or wait and let time for a driver to initialize and trig the
> >>> >> calibration. If calibration has not been done at the end of the boot,
> >>> >> you can force a calibration. If the cpufeq driver is a module and is
> >>> >> loaded far later for any good or bad reason, we will have to run the
> >>> >> calibration once again but at least the capacity will reflect he
> >>> >> current capacity of the CPUs.
> >>> >> I'm mainly worried that the compilation of the calibration is
> >>> >> dependent of CONFIG_CPU_FREQ not that cpufreq can trig the calibration
> >>> >> sequence
> >>> >>
> >>> >
> >>> > Yes, I guess we can make this work in some way. Out of curiosity,
> >>> > though, are out there heterogenous platforms that don't use cpufreq?
> >>>
> >>> At least, you can find several heterogeneous platforms without OPP
> >>> table for CPUs in the kernel. That's probably a temporary situation
> >>> but which can become a permanent one. It means that we can't calibrate
> >>> the CPUs for these platforms.
> >>>
> >>
> >> Sorry, can you make some examples so that I'm sure I understand what you
> >> are referring to?
> >
> > As an example, the uniphier arm64 Soc doesn't have a cpufreq driver so far
> >
> >>
> >> Anyway, don't these platform still make use of cpufreq (even if without
> >> an OPP table) so that we can still control policy->max and min?
> >
> > AFAICT, They don't have a dedicated cpufreq driver.
> >
> > More generally speaking, it can take time before having
> 
> email sent before the ne d of the sentence ...
> 
> More generally speaking, it can take time before having a cpufreq
> driver whereas we want to run and test scheduler behavior of these
> heterogenous platform
> 

I'm not familiar with this platform, but from what you are saying and
what I could find online, it looks like full Linux support is not
finished yet. Can we consider that as still in development? And if we
can do that, maybe is fair enough that we use the sysfs interface to
play with that platform until support is complete.

Do others have any opinion on this point?

Thanks,

- Juri


From boris.brezillon at free-electrons.com  Fri Feb  5 01:31:06 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 5 Feb 2016 10:31:06 +0100
Subject: [PATCH v2 07/51] mtd: nand: core: use mtd_ooblayout_xxx()
 helpers where appropriate
In-Reply-To: <1454580434-32078-8-git-send-email-boris.brezillon@free-electrons.com>
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
 <1454580434-32078-8-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <20160205103106.53710c48@bbrezillon>

On Thu,  4 Feb 2016 11:06:30 +0100
Boris Brezillon <boris.brezillon at free-electrons.com> wrote:

> The mtd_ooblayout_xxx() helper functions have been added to avoid direct
> accesses to the ecclayout field, and thus ease for future reworks.
> Use these helpers in all places where the oobfree[] and eccpos[] arrays
> where directly accessed.
> 
> Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
> ---
>  drivers/mtd/nand/nand_base.c | 169 ++++++++++++++++++-------------------------
>  drivers/mtd/nand/nand_bch.c  |   3 +-
>  2 files changed, 74 insertions(+), 98 deletions(-)
> 
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 572369d..e01a9b5 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c

[...]

> @@ -4116,7 +4092,6 @@ static bool nand_ecc_strength_good(struct mtd_info *mtd)
>   */
>  int nand_scan_tail(struct mtd_info *mtd)
>  {
> -	int i;
>  	struct nand_chip *chip = mtd_to_nand(mtd);
>  	struct nand_ecc_ctrl *ecc = &chip->ecc;
>  	struct nand_buffers *nbuf;
> @@ -4315,9 +4290,9 @@ int nand_scan_tail(struct mtd_info *mtd)
>  	 * The number of bytes available for a client to place data into
>  	 * the out of band area.
>  	 */
> -	mtd->oobavail = 0;
> -	for (i = 0; ecc->layout->oobfree[i].length; i++)
> -		mtd->oobavail += ecc->layout->oobfree[i].length;
> +	mtd->oobavail = mtd_ooblayout_count_freebytes(mtd);

We should call that after setting the mtd->ecclayout field.

> +	if (mtd->oobavail < 0)
> +		mtd->oobavail = 0;
>  
>  	/* ECC sanity check: warn if it's too weak */
>  	if (!nand_ecc_strength_good(mtd))



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


From p.zabel at pengutronix.de  Fri Feb  5 01:37:00 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 05 Feb 2016 10:37:00 +0100
Subject: [PATCH v4 1/1] USB: core: let USB device know device node
In-Reply-To: <20160205061124.GB1858@shlinux2>
References: <1453706679-18948-1-git-send-email-peter.chen@freescale.com>
 <1454582690.3356.18.camel@pengutronix.de> <20160205061124.GB1858@shlinux2>
Message-ID: <1454665020.6406.21.camel@pengutronix.de>

Am Freitag, den 05.02.2016, 14:11 +0800 schrieb Peter Chen:
[...]
> > The reference recommendation states that for single-configuration USB
> > devices the compatible should contain all of the applicable strings from
> > the list starting with 2) "usbVID,PID.REV" and ending with 11)
> > "usb,device". Are we going to ignore this?
>
> I have not seen benefits if we write several compatibles in dts,
> the information of compatibles listed in doc can be got during
> the enumeration.
> 
> I suggest we use the simple pattern for this compatible, in that
> case, every one can be easy to follow it, and will not be confused
> which compatibles should be used, and the style can be unify.

Just pointing it out, a comment why this differs from the recommendation
would be nice to avoid confusion.

[...]
> > > +		compatible = "usb05e3,0608";
> > > +		reg = <0x1>;
> > > +	};
> > 
> > I'd have written this node as:
> > 
> > 	hub: hub at 1 {
> > 		compatible = "usb5e3,608", "usb5e3,class9",
> > 			     "usb,class9", "usb,device";
> > 		reg = <1>;
> > 	};
> 
> The reg should be hexadecimal, do we need to add "0x" before the value?

The unit-address name part should be hexadecimal, the reg property value
doesn't have to be. As long as the value is < 10 I don't see a problem.

> > As another example, I'd like to introduce the USB WLAN Adapter soldered
> > onto the imx6q-gk802 board to its power enable GPIO via the device tree:
> > 
> > /* Internal USB port (USBH1) */
> > &usbh1 {
> > 	#address-cells = <1>;
> > 	#size-cells = <0>;
> > 	status = "okay";
> > 
> > 	/* RTL8192CU 802.11n WLAN Adapter */
> > 	device at 1 {
> > 		compatible = "usbbda,8176.200", "usbbda,8176",
> > 			     "usb,device";
> > 		reg = <1>;
> > 
> > 		enable-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
> > 	};
> > };
> > 
> 
> It is okay to use your example, but I still insist like below:

Sorry for being imprecise. The hub example is fine for the
documentation. I just wanted to illustrate how and why I am interested
in this discussion.

best regards
Philipp



From jamesjj.liao at mediatek.com  Fri Feb  5 01:37:23 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Fri, 5 Feb 2016 17:37:23 +0800
Subject: [PATCH v6 0/7] Add clock support for Mediatek MT2701
Message-ID: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>

This series is based on 4.5-rc1 and [1], add clock and reset controller
support for Mediatek MT2701.

This series also refined makefile and Kconfig to support configurable
multiple SoC clock support.

changes since v5:
- Rebase to v4.5-rc1 and [1].
- Enable critical clocks for MT2701
- Refine dt-binding documents, add reset controller support for hifsys.

changes since v4:
- Rebase to v4.5-rc1.
- Remove CLK_SET_RATE_PARENT from divider flags.
- Add img_jpgdec_smi clock.
- Move clk/mediatek/Kconfig into menu section in clk/Kconfig.

changes since v3:
- Change the parent of mm_mdp_bls_26m from clk26m to pwm_sel.

changes since v2:
- Fix ethsys definition.
- Replace read-modify-write with regmap_update_bits() in clock operations.
- Move mt2701-resets.h to include/dt-bindings/reset/.
- Add hifsys reset patch from John Crispin.

changes since v1:
- Document MT2701 compatible strings.

[1] https://patchwork.kernel.org/patch/8147901/

James Liao (3):
  clk: mediatek: Refine the makefile to support multiple clock drivers
  dt-bindings: ARM: Mediatek: Document bindings for MT2701
  clk: mediatek: Enable critical clocks for MT2701

Shunli Wang (4):
  clk: mediatek: Add dt-bindings for MT2701 clocks
  clk: mediatek: Add MT2701 clock support
  reset: mediatek: Add MT2701 reset controller dt-binding file
  reset: mediatek: Add MT2701 reset driver

 .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |    3 +-
 .../bindings/arm/mediatek/mediatek,bdpsys.txt      |   22 +
 .../bindings/arm/mediatek/mediatek,ethsys.txt      |   22 +
 .../bindings/arm/mediatek/mediatek,hifsys.txt      |   24 +
 .../bindings/arm/mediatek/mediatek,imgsys.txt      |    3 +-
 .../bindings/arm/mediatek/mediatek,infracfg.txt    |    3 +-
 .../bindings/arm/mediatek/mediatek,mmsys.txt       |    3 +-
 .../bindings/arm/mediatek/mediatek,pericfg.txt     |    3 +-
 .../bindings/arm/mediatek/mediatek,topckgen.txt    |    3 +-
 .../bindings/arm/mediatek/mediatek,vdecsys.txt     |    3 +-
 drivers/clk/Kconfig                                |    1 +
 drivers/clk/mediatek/Kconfig                       |   31 +
 drivers/clk/mediatek/Makefile                      |    7 +-
 drivers/clk/mediatek/clk-gate.c                    |   52 +
 drivers/clk/mediatek/clk-gate.h                    |    2 +
 drivers/clk/mediatek/clk-mt2701.c                  | 1236 ++++++++++++++++++++
 drivers/clk/mediatek/clk-mtk.c                     |   25 +
 drivers/clk/mediatek/clk-mtk.h                     |   34 +-
 include/dt-bindings/clock/mt2701-clk.h             |  482 ++++++++
 include/dt-bindings/reset/mt2701-resets.h          |   83 ++
 20 files changed, 2029 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
 create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
 create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt
 create mode 100644 drivers/clk/mediatek/Kconfig
 create mode 100644 drivers/clk/mediatek/clk-mt2701.c
 create mode 100644 include/dt-bindings/clock/mt2701-clk.h
 create mode 100644 include/dt-bindings/reset/mt2701-resets.h

--
1.9.1



From jamesjj.liao at mediatek.com  Fri Feb  5 01:37:25 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Fri, 5 Feb 2016 17:37:25 +0800
Subject: [PATCH v6 2/7] dt-bindings: ARM: Mediatek: Document bindings for
 MT2701
In-Reply-To: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
References: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <1454665050-37776-3-git-send-email-jamesjj.liao@mediatek.com>

This patch adds the binding documentation for apmixedsys, bdpsys,
ethsys, hifsys, imgsys, infracfg, mmsys, pericfg, topckgen and
vdecsys for Mediatek MT2701.

Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
Tested-by: John Crispin <blogic at openwrt.org>
---
 .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |  3 ++-
 .../bindings/arm/mediatek/mediatek,bdpsys.txt      | 22 ++++++++++++++++++++
 .../bindings/arm/mediatek/mediatek,ethsys.txt      | 22 ++++++++++++++++++++
 .../bindings/arm/mediatek/mediatek,hifsys.txt      | 24 ++++++++++++++++++++++
 .../bindings/arm/mediatek/mediatek,imgsys.txt      |  3 ++-
 .../bindings/arm/mediatek/mediatek,infracfg.txt    |  3 ++-
 .../bindings/arm/mediatek/mediatek,mmsys.txt       |  3 ++-
 .../bindings/arm/mediatek/mediatek,pericfg.txt     |  3 ++-
 .../bindings/arm/mediatek/mediatek,topckgen.txt    |  3 ++-
 .../bindings/arm/mediatek/mediatek,vdecsys.txt     |  3 ++-
 10 files changed, 82 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
 create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
 create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
index 936166f..cb0054a 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
@@ -5,7 +5,8 @@ The Mediatek apmixedsys controller provides the PLLs to the system.
 
 Required Properties:
 
-- compatible: Should be:
+- compatible: Should be one of:
+	- "mediatek,mt2701-apmixedsys"
 	- "mediatek,mt8135-apmixedsys"
 	- "mediatek,mt8173-apmixedsys"
 - #clock-cells: Must be 1
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
new file mode 100644
index 0000000..4137196
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
@@ -0,0 +1,22 @@
+Mediatek bdpsys controller
+============================
+
+The Mediatek bdpsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+	- "mediatek,mt2701-bdpsys", "syscon"
+- #clock-cells: Must be 1
+
+The bdpsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+bdpsys: clock-controller at 1c000000 {
+	compatible = "mediatek,mt2701-bdpsys", "syscon";
+	reg = <0 0x1c000000 0 0x1000>;
+	#clock-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
new file mode 100644
index 0000000..768f3a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
@@ -0,0 +1,22 @@
+Mediatek ethsys controller
+============================
+
+The Mediatek ethsys controller provides various clocks to the system.
+
+Required Properties:
+
+- compatible: Should be:
+	- "mediatek,mt2701-ethsys", "syscon"
+- #clock-cells: Must be 1
+
+The ethsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+ethsys: clock-controller at 1b000000 {
+	compatible = "mediatek,mt2701-ethsys", "syscon";
+	reg = <0 0x1b000000 0 0x1000>;
+	#clock-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt
new file mode 100644
index 0000000..beed7b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt
@@ -0,0 +1,24 @@
+Mediatek hifsys controller
+============================
+
+The Mediatek hifsys controller provides various clocks and reset
+outputs to the system.
+
+Required Properties:
+
+- compatible: Should be:
+	- "mediatek,mt2701-hifsys", "syscon"
+- #clock-cells: Must be 1
+
+The hifsys controller uses the common clk binding from
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The available clocks are defined in dt-bindings/clock/mt*-clk.h.
+
+Example:
+
+hifsys: clock-controller at 1a000000 {
+	compatible = "mediatek,mt2701-hifsys", "syscon";
+	reg = <0 0x1a000000 0 0x1000>;
+	#clock-cells = <1>;
+	#reset-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
index b1f2ce1..f6a9166 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
@@ -5,7 +5,8 @@ The Mediatek imgsys controller provides various clocks to the system.
 
 Required Properties:
 
-- compatible: Should be:
+- compatible: Should be one of:
+	- "mediatek,mt2701-imgsys", "syscon"
 	- "mediatek,mt8173-imgsys", "syscon"
 - #clock-cells: Must be 1
 
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
index aaf8d14..1620ec2 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
@@ -6,7 +6,8 @@ outputs to the system.
 
 Required Properties:
 
-- compatible: Should be:
+- compatible: Should be one of:
+	- "mediatek,mt2701-infracfg", "syscon"
 	- "mediatek,mt8135-infracfg", "syscon"
 	- "mediatek,mt8173-infracfg", "syscon"
 - #clock-cells: Must be 1
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
index 4385946..67dd2e4 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
@@ -5,7 +5,8 @@ The Mediatek mmsys controller provides various clocks to the system.
 
 Required Properties:
 
-- compatible: Should be:
+- compatible: Should be one of:
+	- "mediatek,mt2701-mmsys", "syscon"
 	- "mediatek,mt8173-mmsys", "syscon"
 - #clock-cells: Must be 1
 
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
index 2f6ff86..e494366 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pericfg.txt
@@ -6,7 +6,8 @@ outputs to the system.
 
 Required Properties:
 
-- compatible: Should be:
+- compatible: Should be one of:
+	- "mediatek,mt2701-pericfg", "syscon"
 	- "mediatek,mt8135-pericfg", "syscon"
 	- "mediatek,mt8173-pericfg", "syscon"
 - #clock-cells: Must be 1
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
index f9e9179..9f2fe78 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
@@ -5,7 +5,8 @@ The Mediatek topckgen controller provides various clocks to the system.
 
 Required Properties:
 
-- compatible: Should be:
+- compatible: Should be one of:
+	- "mediatek,mt2701-topckgen"
 	- "mediatek,mt8135-topckgen"
 	- "mediatek,mt8173-topckgen"
 - #clock-cells: Must be 1
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
index 1faacf1..2440f73 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
@@ -5,7 +5,8 @@ The Mediatek vdecsys controller provides various clocks to the system.
 
 Required Properties:
 
-- compatible: Should be:
+- compatible: Should be one of:
+	- "mediatek,mt2701-vdecsys", "syscon"
 	- "mediatek,mt8173-vdecsys", "syscon"
 - #clock-cells: Must be 1
 
-- 
1.9.1



From jamesjj.liao at mediatek.com  Fri Feb  5 01:37:24 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Fri, 5 Feb 2016 17:37:24 +0800
Subject: [PATCH v6 1/7] clk: mediatek: Refine the makefile to support multiple
 clock drivers
In-Reply-To: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
References: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <1454665050-37776-2-git-send-email-jamesjj.liao@mediatek.com>

Add a Kconfig to define clock configuration for each SoC, and
modify the Makefile to build drivers that only selected in config.

Signed-off-by: Shunli Wang <shunli.wang at mediatek.com>
Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
Tested-by: John Crispin <blogic at openwrt.org>
---
 drivers/clk/Kconfig           |  1 +
 drivers/clk/mediatek/Kconfig  | 23 +++++++++++++++++++++++
 drivers/clk/mediatek/Makefile |  6 +++---
 3 files changed, 27 insertions(+), 3 deletions(-)
 create mode 100644 drivers/clk/mediatek/Kconfig

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index de707b2..d333863 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -202,6 +202,7 @@ config COMMON_CLK_CDCE706
 
 source "drivers/clk/bcm/Kconfig"
 source "drivers/clk/hisilicon/Kconfig"
+source "drivers/clk/mediatek/Kconfig"
 source "drivers/clk/mvebu/Kconfig"
 source "drivers/clk/qcom/Kconfig"
 source "drivers/clk/samsung/Kconfig"
diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
new file mode 100644
index 0000000..dc224e6
--- /dev/null
+++ b/drivers/clk/mediatek/Kconfig
@@ -0,0 +1,23 @@
+#
+# MediaTek SoC drivers
+#
+config COMMON_CLK_MEDIATEK
+	bool
+	---help---
+	  Mediatek SoCs' clock support.
+
+config COMMON_CLK_MT8135
+	bool "Clock driver for Mediatek MT8135"
+	depends on COMMON_CLK
+	select COMMON_CLK_MEDIATEK
+	default ARCH_MEDIATEK
+	---help---
+	  This driver supports Mediatek MT8135 clocks.
+
+config COMMON_CLK_MT8173
+	bool "Clock driver for Mediatek MT8173"
+	depends on COMMON_CLK
+	select COMMON_CLK_MEDIATEK
+	default ARCH_MEDIATEK
+	---help---
+	  This driver supports Mediatek MT8173 clocks.
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 95fdfac..32e7222 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,4 +1,4 @@
-obj-y += clk-mtk.o clk-pll.o clk-gate.o clk-apmixed.o
+obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o clk-apmixed.o
 obj-$(CONFIG_RESET_CONTROLLER) += reset.o
-obj-y += clk-mt8135.o
-obj-y += clk-mt8173.o
+obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o
+obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173.o
-- 
1.9.1



From jamesjj.liao at mediatek.com  Fri Feb  5 01:37:29 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Fri, 5 Feb 2016 17:37:29 +0800
Subject: [PATCH v6 6/7] reset: mediatek: Add MT2701 reset driver
In-Reply-To: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
References: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <1454665050-37776-7-git-send-email-jamesjj.liao@mediatek.com>

From: Shunli Wang <shunli.wang at mediatek.com>

In infrasys and perifsys, there are many reset
control bits for kinds of modules. These bits are
used as actual reset controllers to be registered
into kernel's generic reset controller framework.

Signed-off-by: Shunli Wang <shunli.wang at mediatek.com>
Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
Tested-by: John Crispin <blogic at openwrt.org>
Acked-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 drivers/clk/mediatek/clk-mt2701.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/clk/mediatek/clk-mt2701.c b/drivers/clk/mediatek/clk-mt2701.c
index 0ac45fc..01722e0 100644
--- a/drivers/clk/mediatek/clk-mt2701.c
+++ b/drivers/clk/mediatek/clk-mt2701.c
@@ -665,6 +665,8 @@ static void __init mtk_infrasys_init(struct device_node *node)
 	if (r)
 		pr_err("%s(): could not register clock provider: %d\n",
 			__func__, r);
+
+	mtk_register_reset_controller(node, 2, 0x30);
 }
 CLK_OF_DECLARE(mtk_infrasys, "mediatek,mt2701-infracfg", mtk_infrasys_init);
 
@@ -782,6 +784,8 @@ static void __init mtk_pericfg_init(struct device_node *node)
 	if (r)
 		pr_err("%s(): could not register clock provider: %d\n",
 			__func__, r);
+
+	mtk_register_reset_controller(node, 2, 0x0);
 }
 CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt2701-pericfg", mtk_pericfg_init);
 
@@ -997,6 +1001,8 @@ static void __init mtk_hifsys_init(struct device_node *node)
 	if (r)
 		pr_err("%s(): could not register clock provider: %d\n",
 			__func__, r);
+
+	mtk_register_reset_controller(node, 1, 0x34);
 }
 CLK_OF_DECLARE(mtk_hifsys, "mediatek,mt2701-hifsys", mtk_hifsys_init);
 
-- 
1.9.1



From jamesjj.liao at mediatek.com  Fri Feb  5 01:37:28 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Fri, 5 Feb 2016 17:37:28 +0800
Subject: [PATCH v6 5/7] reset: mediatek: Add MT2701 reset controller
 dt-binding file
In-Reply-To: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
References: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <1454665050-37776-6-git-send-email-jamesjj.liao@mediatek.com>

From: Shunli Wang <shunli.wang at mediatek.com>

Dt-binding file about reset controller is used to provide
kinds of definition, which is referenced by dts file and
IC-specified reset controller driver code.

Signed-off-by: Shunli Wang <shunli.wang at mediatek.com>
Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
Tested-by: John Crispin <blogic at openwrt.org>
Acked-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 include/dt-bindings/reset/mt2701-resets.h | 83 +++++++++++++++++++++++++++++++
 1 file changed, 83 insertions(+)
 create mode 100644 include/dt-bindings/reset/mt2701-resets.h

diff --git a/include/dt-bindings/reset/mt2701-resets.h b/include/dt-bindings/reset/mt2701-resets.h
new file mode 100644
index 0000000..aaf0305
--- /dev/null
+++ b/include/dt-bindings/reset/mt2701-resets.h
@@ -0,0 +1,83 @@
+/*
+ * Copyright (c) 2015 MediaTek, Shunli Wang <shunli.wang at mediatek.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.
+ */
+
+#ifndef _DT_BINDINGS_RESET_CONTROLLER_MT2701
+#define _DT_BINDINGS_RESET_CONTROLLER_MT2701
+
+/* INFRACFG resets */
+#define MT2701_INFRA_EMI_REG_RST		0
+#define MT2701_INFRA_DRAMC0_A0_RST		1
+#define MT2701_INFRA_FHCTL_RST			2
+#define MT2701_INFRA_APCIRQ_EINT_RST		3
+#define MT2701_INFRA_APXGPT_RST			4
+#define MT2701_INFRA_SCPSYS_RST			5
+#define MT2701_INFRA_KP_RST			6
+#define MT2701_INFRA_PMIC_WRAP_RST		7
+#define MT2701_INFRA_MIPI_RST			8
+#define MT2701_INFRA_IRRX_RST			9
+#define MT2701_INFRA_CEC_RST			10
+#define MT2701_INFRA_EMI_RST			32
+#define MT2701_INFRA_DRAMC0_RST			34
+#define MT2701_INFRA_TRNG_RST			37
+#define MT2701_INFRA_SYSIRQ_RST			38
+
+/*  PERICFG resets */
+#define MT2701_PERI_UART0_SW_RST		0
+#define MT2701_PERI_UART1_SW_RST		1
+#define MT2701_PERI_UART2_SW_RST		2
+#define MT2701_PERI_UART3_SW_RST		3
+#define MT2701_PERI_GCPU_SW_RST			5
+#define MT2701_PERI_BTIF_SW_RST			6
+#define MT2701_PERI_PWM_SW_RST			8
+#define MT2701_PERI_AUXADC_SW_RST		10
+#define MT2701_PERI_DMA_SW_RST			11
+#define MT2701_PERI_NFI_SW_RST			14
+#define MT2701_PERI_NLI_SW_RST			15
+#define MT2701_PERI_THERM_SW_RST		16
+#define MT2701_PERI_MSDC2_SW_RST		17
+#define MT2701_PERI_MSDC0_SW_RST		19
+#define MT2701_PERI_MSDC1_SW_RST		20
+#define MT2701_PERI_I2C0_SW_RST			22
+#define MT2701_PERI_I2C1_SW_RST			23
+#define MT2701_PERI_I2C2_SW_RST			24
+#define MT2701_PERI_I2C3_SW_RST			25
+#define MT2701_PERI_USB_SW_RST			28
+#define MT2701_PERI_ETH_SW_RST			29
+#define MT2701_PERI_SPI0_SW_RST			33
+
+/* TOPRGU resets */
+#define MT2701_TOPRGU_INFRA_RST			0
+#define MT2701_TOPRGU_MM_RST			1
+#define MT2701_TOPRGU_MFG_RST			2
+#define MT2701_TOPRGU_ETHDMA_RST		3
+#define MT2701_TOPRGU_VDEC_RST			4
+#define MT2701_TOPRGU_VENC_IMG_RST		5
+#define MT2701_TOPRGU_DDRPHY_RST		6
+#define MT2701_TOPRGU_MD_RST			7
+#define MT2701_TOPRGU_INFRA_AO_RST		8
+#define MT2701_TOPRGU_CONN_RST			9
+#define MT2701_TOPRGU_APMIXED_RST		10
+#define MT2701_TOPRGU_HIFSYS_RST		11
+#define MT2701_TOPRGU_CONN_MCU_RST		12
+#define MT2701_TOPRGU_BDP_DISP_RST		13
+
+/* HIFSYS resets */
+#define MT2701_HIFSYS_UHOST0_RST		3
+#define MT2701_HIFSYS_UHOST1_RST		4
+#define MT2701_HIFSYS_UPHY0_RST			21
+#define MT2701_HIFSYS_UPHY1_RST			22
+#define MT2701_HIFSYS_PCIE0_RST			24
+#define MT2701_HIFSYS_PCIE1_RST			25
+#define MT2701_HIFSYS_PCIE2_RST			26
+
+#endif  /* _DT_BINDINGS_RESET_CONTROLLER_MT2701 */
-- 
1.9.1



From jamesjj.liao at mediatek.com  Fri Feb  5 01:37:26 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Fri, 5 Feb 2016 17:37:26 +0800
Subject: [PATCH v6 3/7] clk: mediatek: Add dt-bindings for MT2701 clocks
In-Reply-To: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
References: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <1454665050-37776-4-git-send-email-jamesjj.liao@mediatek.com>

From: Shunli Wang <shunli.wang at mediatek.com>

Add MT2701 clock dt-bindings, include topckgen, apmixedsys,
infracfg, pericfg and subsystem clocks.

Signed-off-by: Shunli Wang <shunli.wang at mediatek.com>
Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
Tested-by: John Crispin <blogic at openwrt.org>
---
 include/dt-bindings/clock/mt2701-clk.h | 482 +++++++++++++++++++++++++++++++++
 1 file changed, 482 insertions(+)
 create mode 100644 include/dt-bindings/clock/mt2701-clk.h

diff --git a/include/dt-bindings/clock/mt2701-clk.h b/include/dt-bindings/clock/mt2701-clk.h
new file mode 100644
index 0000000..cc65ec6
--- /dev/null
+++ b/include/dt-bindings/clock/mt2701-clk.h
@@ -0,0 +1,482 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Shunli Wang <shunli.wang at mediatek.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.
+ */
+
+#ifndef _DT_BINDINGS_CLK_MT2701_H
+#define _DT_BINDINGS_CLK_MT2701_H
+
+/* TOPCKGEN */
+#define CLK_TOP_SYSPLL				1
+#define CLK_TOP_SYSPLL_D2			2
+#define CLK_TOP_SYSPLL_D3			3
+#define CLK_TOP_SYSPLL_D5			4
+#define CLK_TOP_SYSPLL_D7			5
+#define CLK_TOP_SYSPLL1_D2			6
+#define CLK_TOP_SYSPLL1_D4			7
+#define CLK_TOP_SYSPLL1_D8			8
+#define CLK_TOP_SYSPLL1_D16			9
+#define CLK_TOP_SYSPLL2_D2			10
+#define CLK_TOP_SYSPLL2_D4			11
+#define CLK_TOP_SYSPLL2_D8			12
+#define CLK_TOP_SYSPLL3_D2			13
+#define CLK_TOP_SYSPLL3_D4			14
+#define CLK_TOP_SYSPLL4_D2			15
+#define CLK_TOP_SYSPLL4_D4			16
+#define CLK_TOP_UNIVPLL				17
+#define CLK_TOP_UNIVPLL_D2			18
+#define CLK_TOP_UNIVPLL_D3			19
+#define CLK_TOP_UNIVPLL_D5			20
+#define CLK_TOP_UNIVPLL_D7			21
+#define CLK_TOP_UNIVPLL_D26			22
+#define CLK_TOP_UNIVPLL_D52			23
+#define CLK_TOP_UNIVPLL_D108			24
+#define CLK_TOP_USB_PHY48M			25
+#define CLK_TOP_UNIVPLL1_D2			26
+#define CLK_TOP_UNIVPLL1_D4			27
+#define CLK_TOP_UNIVPLL1_D8			28
+#define CLK_TOP_UNIVPLL2_D2			29
+#define CLK_TOP_UNIVPLL2_D4			30
+#define CLK_TOP_UNIVPLL2_D8			31
+#define CLK_TOP_UNIVPLL2_D16			32
+#define CLK_TOP_UNIVPLL2_D32			33
+#define CLK_TOP_UNIVPLL3_D2			34
+#define CLK_TOP_UNIVPLL3_D4			35
+#define CLK_TOP_UNIVPLL3_D8			36
+#define CLK_TOP_MSDCPLL				37
+#define CLK_TOP_MSDCPLL_D2			38
+#define CLK_TOP_MSDCPLL_D4			39
+#define CLK_TOP_MSDCPLL_D8			40
+#define CLK_TOP_MMPLL				41
+#define CLK_TOP_MMPLL_D2			42
+#define CLK_TOP_DMPLL				43
+#define CLK_TOP_DMPLL_D2			44
+#define CLK_TOP_DMPLL_D4			45
+#define CLK_TOP_DMPLL_X2			46
+#define CLK_TOP_TVDPLL				47
+#define CLK_TOP_TVDPLL_D2			48
+#define CLK_TOP_TVDPLL_D4			49
+#define CLK_TOP_TVD2PLL				50
+#define CLK_TOP_TVD2PLL_D2			51
+#define CLK_TOP_HADDS2PLL_98M			52
+#define CLK_TOP_HADDS2PLL_294M			53
+#define CLK_TOP_HADDS2_FB			54
+#define CLK_TOP_MIPIPLL_D2			55
+#define CLK_TOP_MIPIPLL_D4			56
+#define CLK_TOP_HDMIPLL				57
+#define CLK_TOP_HDMIPLL_D2			58
+#define CLK_TOP_HDMIPLL_D3			59
+#define CLK_TOP_HDMI_SCL_RX			60
+#define CLK_TOP_HDMI_0_PIX340M			61
+#define CLK_TOP_HDMI_0_DEEP340M			62
+#define CLK_TOP_HDMI_0_PLL340M			63
+#define CLK_TOP_AUD1PLL_98M			64
+#define CLK_TOP_AUD2PLL_90M			65
+#define CLK_TOP_AUDPLL				66
+#define CLK_TOP_AUDPLL_D4			67
+#define CLK_TOP_AUDPLL_D8			68
+#define CLK_TOP_AUDPLL_D16			69
+#define CLK_TOP_AUDPLL_D24			70
+#define CLK_TOP_ETHPLL_500M			71
+#define CLK_TOP_VDECPLL				72
+#define CLK_TOP_VENCPLL				73
+#define CLK_TOP_MIPIPLL				74
+#define CLK_TOP_ARMPLL_1P3G			75
+
+#define CLK_TOP_MM_SEL				76
+#define CLK_TOP_DDRPHYCFG_SEL			77
+#define CLK_TOP_MEM_SEL				78
+#define CLK_TOP_AXI_SEL				79
+#define CLK_TOP_CAMTG_SEL			80
+#define CLK_TOP_MFG_SEL				81
+#define CLK_TOP_VDEC_SEL			82
+#define CLK_TOP_PWM_SEL				83
+#define CLK_TOP_MSDC30_0_SEL			84
+#define CLK_TOP_USB20_SEL			85
+#define CLK_TOP_SPI0_SEL			86
+#define CLK_TOP_UART_SEL			87
+#define CLK_TOP_AUDINTBUS_SEL			88
+#define CLK_TOP_AUDIO_SEL			89
+#define CLK_TOP_MSDC30_2_SEL			90
+#define CLK_TOP_MSDC30_1_SEL			91
+#define CLK_TOP_DPI1_SEL			92
+#define CLK_TOP_DPI0_SEL			93
+#define CLK_TOP_SCP_SEL				94
+#define CLK_TOP_PMICSPI_SEL			95
+#define CLK_TOP_APLL_SEL			96
+#define CLK_TOP_HDMI_SEL			97
+#define CLK_TOP_TVE_SEL				98
+#define CLK_TOP_EMMC_HCLK_SEL			99
+#define CLK_TOP_NFI2X_SEL			100
+#define CLK_TOP_RTC_SEL				101
+#define CLK_TOP_OSD_SEL				102
+#define CLK_TOP_NR_SEL				103
+#define CLK_TOP_DI_SEL				104
+#define CLK_TOP_FLASH_SEL			105
+#define CLK_TOP_ASM_M_SEL			106
+#define CLK_TOP_ASM_I_SEL			107
+#define CLK_TOP_INTDIR_SEL			108
+#define CLK_TOP_HDMIRX_BIST_SEL			109
+#define CLK_TOP_ETHIF_SEL			110
+#define CLK_TOP_MS_CARD_SEL			111
+#define CLK_TOP_ASM_H_SEL			112
+#define CLK_TOP_SPI1_SEL			113
+#define CLK_TOP_CMSYS_SEL			114
+#define CLK_TOP_MSDC30_3_SEL			115
+#define CLK_TOP_HDMIRX26_24_SEL			116
+#define CLK_TOP_AUD2DVD_SEL			117
+#define CLK_TOP_8BDAC_SEL			118
+#define CLK_TOP_SPI2_SEL			119
+#define CLK_TOP_AUD_MUX1_SEL			120
+#define CLK_TOP_AUD_MUX2_SEL			121
+#define CLK_TOP_AUDPLL_MUX_SEL			122
+#define CLK_TOP_AUD_K1_SRC_SEL			123
+#define CLK_TOP_AUD_K2_SRC_SEL			124
+#define CLK_TOP_AUD_K3_SRC_SEL			125
+#define CLK_TOP_AUD_K4_SRC_SEL			126
+#define CLK_TOP_AUD_K5_SRC_SEL			127
+#define CLK_TOP_AUD_K6_SRC_SEL			128
+#define CLK_TOP_PADMCLK_SEL			129
+#define CLK_TOP_AUD_EXTCK1_DIV			130
+#define CLK_TOP_AUD_EXTCK2_DIV			131
+#define CLK_TOP_AUD_MUX1_DIV			132
+#define CLK_TOP_AUD_MUX2_DIV			133
+#define CLK_TOP_AUD_K1_SRC_DIV			134
+#define CLK_TOP_AUD_K2_SRC_DIV			135
+#define CLK_TOP_AUD_K3_SRC_DIV			136
+#define CLK_TOP_AUD_K4_SRC_DIV			137
+#define CLK_TOP_AUD_K5_SRC_DIV			138
+#define CLK_TOP_AUD_K6_SRC_DIV			139
+#define CLK_TOP_AUD_I2S1_MCLK			140
+#define CLK_TOP_AUD_I2S2_MCLK			141
+#define CLK_TOP_AUD_I2S3_MCLK			142
+#define CLK_TOP_AUD_I2S4_MCLK			143
+#define CLK_TOP_AUD_I2S5_MCLK			144
+#define CLK_TOP_AUD_I2S6_MCLK			145
+#define CLK_TOP_AUD_48K_TIMING			146
+#define CLK_TOP_AUD_44K_TIMING			147
+
+#define CLK_TOP_32K_INTERNAL			148
+#define CLK_TOP_32K_EXTERNAL			149
+#define CLK_TOP_CLK26M_D8			150
+#define CLK_TOP_8BDAC				151
+#define CLK_TOP_WBG_DIG_416M			152
+#define CLK_TOP_DPI				153
+#define CLK_TOP_HDMITX_CLKDIG_CTS		154
+#define CLK_TOP_NR				155
+
+/* APMIXEDSYS */
+
+#define CLK_APMIXED_ARMPLL			1
+#define CLK_APMIXED_MAINPLL			2
+#define CLK_APMIXED_UNIVPLL			3
+#define CLK_APMIXED_MMPLL			4
+#define CLK_APMIXED_MSDCPLL			5
+#define CLK_APMIXED_TVDPLL			6
+#define CLK_APMIXED_AUD1PLL			7
+#define CLK_APMIXED_TRGPLL			8
+#define CLK_APMIXED_ETHPLL			9
+#define CLK_APMIXED_VDECPLL			10
+#define CLK_APMIXED_HADDS2PLL			11
+#define CLK_APMIXED_AUD2PLL			12
+#define CLK_APMIXED_TVD2PLL			13
+#define CLK_APMIXED_NR				14
+
+/* DDRPHY */
+
+#define CLK_DDRPHY_VENCPLL			1
+#define CLK_DDRPHY_NR				2
+
+/* INFRACFG */
+
+#define CLK_INFRA_DBG				1
+#define CLK_INFRA_SMI				2
+#define CLK_INFRA_QAXI_CM4			3
+#define CLK_INFRA_AUD_SPLIN_B			4
+#define CLK_INFRA_AUDIO				5
+#define CLK_INFRA_EFUSE				6
+#define CLK_INFRA_L2C_SRAM			7
+#define CLK_INFRA_M4U				8
+#define CLK_INFRA_CONNMCU			9
+#define CLK_INFRA_TRNG				10
+#define CLK_INFRA_RAMBUFIF			11
+#define CLK_INFRA_CPUM				12
+#define CLK_INFRA_KP				13
+#define CLK_INFRA_CEC				14
+#define CLK_INFRA_IRRX				15
+#define CLK_INFRA_PMICSPI			16
+#define CLK_INFRA_PMICWRAP			17
+#define CLK_INFRA_DDCCI				18
+#define CLK_INFRA_CLK_13M			19
+#define CLK_INFRA_NR				20
+
+/* PERICFG */
+
+#define CLK_PERI_NFI				1
+#define CLK_PERI_THERM				2
+#define CLK_PERI_PWM1				3
+#define CLK_PERI_PWM2				4
+#define CLK_PERI_PWM3				5
+#define CLK_PERI_PWM4				6
+#define CLK_PERI_PWM5				7
+#define CLK_PERI_PWM6				8
+#define CLK_PERI_PWM7				9
+#define CLK_PERI_PWM				10
+#define CLK_PERI_USB0				11
+#define CLK_PERI_USB1				12
+#define CLK_PERI_AP_DMA				13
+#define CLK_PERI_MSDC30_0			14
+#define CLK_PERI_MSDC30_1			15
+#define CLK_PERI_MSDC30_2			16
+#define CLK_PERI_MSDC30_3			17
+#define CLK_PERI_MSDC50_3			18
+#define CLK_PERI_NLI				19
+#define CLK_PERI_UART0				20
+#define CLK_PERI_UART1				21
+#define CLK_PERI_UART2				22
+#define CLK_PERI_UART3				23
+#define CLK_PERI_BTIF				24
+#define CLK_PERI_I2C0				25
+#define CLK_PERI_I2C1				26
+#define CLK_PERI_I2C2				27
+#define CLK_PERI_I2C3				28
+#define CLK_PERI_AUXADC				29
+#define CLK_PERI_SPI0				30
+#define CLK_PERI_ETH				31
+#define CLK_PERI_USB0_MCU			32
+
+#define CLK_PERI_USB1_MCU			33
+#define CLK_PERI_USB_SLV			34
+#define CLK_PERI_GCPU				35
+#define CLK_PERI_NFI_ECC			36
+#define CLK_PERI_NFI_PAD			37
+#define CLK_PERI_FLASH				38
+#define CLK_PERI_HOST89_INT			39
+#define CLK_PERI_HOST89_SPI			40
+#define CLK_PERI_HOST89_DVD			41
+#define CLK_PERI_SPI1				42
+#define CLK_PERI_SPI2				43
+#define CLK_PERI_FCI				44
+
+#define CLK_PERI_UART0_SEL			45
+#define CLK_PERI_UART1_SEL			46
+#define CLK_PERI_UART2_SEL			47
+#define CLK_PERI_UART3_SEL			48
+#define CLK_PERI_NR				49
+
+/* AUDIO */
+
+#define CLK_AUD_AFE				1
+#define CLK_AUD_LRCK_DETECT			2
+#define CLK_AUD_I2S				3
+#define CLK_AUD_APLL_TUNER			4
+#define CLK_AUD_HDMI				5
+#define CLK_AUD_SPDF				6
+#define CLK_AUD_SPDF2				7
+#define CLK_AUD_APLL				8
+#define CLK_AUD_TML				9
+#define CLK_AUD_AHB_IDLE_EXT			10
+#define CLK_AUD_AHB_IDLE_INT			11
+
+#define CLK_AUD_I2SIN1				12
+#define CLK_AUD_I2SIN2				13
+#define CLK_AUD_I2SIN3				14
+#define CLK_AUD_I2SIN4				15
+#define CLK_AUD_I2SIN5				16
+#define CLK_AUD_I2SIN6				17
+#define CLK_AUD_I2SO1				18
+#define CLK_AUD_I2SO2				19
+#define CLK_AUD_I2SO3				20
+#define CLK_AUD_I2SO4				21
+#define CLK_AUD_I2SO5				22
+#define CLK_AUD_I2SO6				23
+#define CLK_AUD_ASRCI1				24
+#define CLK_AUD_ASRCI2				25
+#define CLK_AUD_ASRCO1				26
+#define CLK_AUD_ASRCO2				27
+#define CLK_AUD_ASRC11				28
+#define CLK_AUD_ASRC12				29
+#define CLK_AUD_HDMIRX				30
+#define CLK_AUD_INTDIR				31
+#define CLK_AUD_A1SYS				32
+#define CLK_AUD_A2SYS				33
+#define CLK_AUD_AFE_CONN			34
+#define CLK_AUD_AFE_PCMIF			35
+#define CLK_AUD_AFE_MRGIF			36
+
+#define CLK_AUD_MMIF_UL1			37
+#define CLK_AUD_MMIF_UL2			38
+#define CLK_AUD_MMIF_UL3			39
+#define CLK_AUD_MMIF_UL4			40
+#define CLK_AUD_MMIF_UL5			41
+#define CLK_AUD_MMIF_UL6			42
+#define CLK_AUD_MMIF_DL1			43
+#define CLK_AUD_MMIF_DL2			44
+#define CLK_AUD_MMIF_DL3			45
+#define CLK_AUD_MMIF_DL4			46
+#define CLK_AUD_MMIF_DL5			47
+#define CLK_AUD_MMIF_DL6			48
+#define CLK_AUD_MMIF_DLMCH			49
+#define CLK_AUD_MMIF_ARB1			50
+#define CLK_AUD_MMIF_AWB1			51
+#define CLK_AUD_MMIF_AWB2			52
+#define CLK_AUD_MMIF_DAI			53
+
+#define CLK_AUD_DMIC1				54
+#define CLK_AUD_DMIC2				55
+#define CLK_AUD_ASRCI3				56
+#define CLK_AUD_ASRCI4				57
+#define CLK_AUD_ASRCI5				58
+#define CLK_AUD_ASRCI6				59
+#define CLK_AUD_ASRCO3				60
+#define CLK_AUD_ASRCO4				61
+#define CLK_AUD_ASRCO5				62
+#define CLK_AUD_ASRCO6				63
+#define CLK_AUD_MEM_ASRC1			64
+#define CLK_AUD_MEM_ASRC2			65
+#define CLK_AUD_MEM_ASRC3			66
+#define CLK_AUD_MEM_ASRC4			67
+#define CLK_AUD_MEM_ASRC5			68
+#define CLK_AUD_DSD_ENC				69
+#define CLK_AUD_ASRC_BRG			70
+#define CLK_AUD_NR				71
+
+/* MMSYS */
+
+#define CLK_MM_SMI_COMMON			1
+#define CLK_MM_SMI_LARB0			2
+#define CLK_MM_CMDQ				3
+#define CLK_MM_MUTEX				4
+#define CLK_MM_DISP_COLOR			5
+#define CLK_MM_DISP_BLS				6
+#define CLK_MM_DISP_WDMA			7
+#define CLK_MM_DISP_RDMA			8
+#define CLK_MM_DISP_OVL				9
+#define CLK_MM_MDP_TDSHP			10
+#define CLK_MM_MDP_WROT				11
+#define CLK_MM_MDP_WDMA				12
+#define CLK_MM_MDP_RSZ1				13
+#define CLK_MM_MDP_RSZ0				14
+#define CLK_MM_MDP_RDMA				15
+#define CLK_MM_MDP_BLS_26M			16
+#define CLK_MM_CAM_MDP				17
+#define CLK_MM_FAKE_ENG				18
+#define CLK_MM_MUTEX_32K			19
+#define CLK_MM_DISP_RDMA1			20
+#define CLK_MM_DISP_UFOE			21
+
+#define CLK_MM_DSI_ENGINE			22
+#define CLK_MM_DSI_DIG				23
+#define CLK_MM_DPI_DIGL				24
+#define CLK_MM_DPI_ENGINE			25
+#define CLK_MM_DPI1_DIGL			26
+#define CLK_MM_DPI1_ENGINE			27
+#define CLK_MM_TVE_OUTPUT			28
+#define CLK_MM_TVE_INPUT			29
+#define CLK_MM_HDMI_PIXEL			30
+#define CLK_MM_HDMI_PLL				31
+#define CLK_MM_HDMI_AUDIO			32
+#define CLK_MM_HDMI_SPDIF			33
+#define CLK_MM_TVE_FMM				34
+#define CLK_MM_NR				35
+
+/* IMGSYS */
+
+#define CLK_IMG_SMI_COMM			1
+#define CLK_IMG_RESZ				2
+#define CLK_IMG_JPGDEC_SMI			3
+#define CLK_IMG_JPGDEC				4
+#define CLK_IMG_VENC_LT				5
+#define CLK_IMG_VENC				6
+#define CLK_IMG_NR				7
+
+/* VDEC */
+
+#define CLK_VDEC_CKGEN				1
+#define CLK_VDEC_LARB				2
+#define CLK_VDEC_NR				3
+
+/* HIFSYS */
+
+#define CLK_HIFSYS_USB0PHY			1
+#define CLK_HIFSYS_USB1PHY			2
+#define CLK_HIFSYS_PCIE0			3
+#define CLK_HIFSYS_PCIE1			4
+#define CLK_HIFSYS_PCIE2			5
+#define CLK_HIFSYS_NR				6
+
+/* ETHSYS */
+#define CLK_ETHSYS_HSDMA			1
+#define CLK_ETHSYS_ESW				2
+#define CLK_ETHSYS_GP2				3
+#define CLK_ETHSYS_GP1				4
+#define CLK_ETHSYS_PCM				5
+#define CLK_ETHSYS_GDMA				6
+#define CLK_ETHSYS_I2S				7
+#define CLK_ETHSYS_CRYPTO			8
+#define CLK_ETHSYS_NR				9
+
+/* BDP */
+
+#define CLK_BDP_BRG_BA				1
+#define CLK_BDP_BRG_DRAM			2
+#define CLK_BDP_LARB_DRAM			3
+#define CLK_BDP_WR_VDI_PXL			4
+#define CLK_BDP_WR_VDI_DRAM			5
+#define CLK_BDP_WR_B				6
+#define CLK_BDP_DGI_IN				7
+#define CLK_BDP_DGI_OUT				8
+#define CLK_BDP_FMT_MAST_27			9
+#define CLK_BDP_FMT_B				10
+#define CLK_BDP_OSD_B				11
+#define CLK_BDP_OSD_DRAM			12
+#define CLK_BDP_OSD_AGENT			13
+#define CLK_BDP_OSD_PXL				14
+#define CLK_BDP_RLE_B				15
+#define CLK_BDP_RLE_AGENT			16
+#define CLK_BDP_RLE_DRAM			17
+#define CLK_BDP_F27M				18
+#define CLK_BDP_F27M_VDOUT			19
+#define CLK_BDP_F27_74_74			20
+#define CLK_BDP_F2FS				21
+#define CLK_BDP_F2FS74_148			22
+#define CLK_BDP_FB				23
+#define CLK_BDP_VDO_DRAM			24
+#define CLK_BDP_VDO_2FS				25
+#define CLK_BDP_VDO_B				26
+#define CLK_BDP_WR_DI_PXL			27
+#define CLK_BDP_WR_DI_DRAM			28
+#define CLK_BDP_WR_DI_B				29
+#define CLK_BDP_NR_PXL				30
+#define CLK_BDP_NR_DRAM				31
+#define CLK_BDP_NR_B				32
+
+#define CLK_BDP_RX_F				33
+#define CLK_BDP_RX_X				34
+#define CLK_BDP_RXPDT				35
+#define CLK_BDP_RX_CSCL_N			36
+#define CLK_BDP_RX_CSCL				37
+#define CLK_BDP_RX_DDCSCL_N			38
+#define CLK_BDP_RX_DDCSCL			39
+#define CLK_BDP_RX_VCO				40
+#define CLK_BDP_RX_DP				41
+#define CLK_BDP_RX_P				42
+#define CLK_BDP_RX_M				43
+#define CLK_BDP_RX_PLL				44
+#define CLK_BDP_BRG_RT_B			45
+#define CLK_BDP_BRG_RT_DRAM			46
+#define CLK_BDP_LARBRT_DRAM			47
+#define CLK_BDP_TMDS_SYN			48
+#define CLK_BDP_HDMI_MON			49
+#define CLK_BDP_NR				50
+
+#endif /* _DT_BINDINGS_CLK_MT2701_H */
-- 
1.9.1



From jamesjj.liao at mediatek.com  Fri Feb  5 01:37:30 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Fri, 5 Feb 2016 17:37:30 +0800
Subject: [PATCH v6 7/7] clk: mediatek: Enable critical clocks for MT2701
In-Reply-To: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
References: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <1454665050-37776-8-git-send-email-jamesjj.liao@mediatek.com>

Some system clocks should be turned on by default on MT2701.
This patch enable these clocks when related clocks have
been registered.

Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
---
 drivers/clk/mediatek/clk-mt2701.c | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt2701.c b/drivers/clk/mediatek/clk-mt2701.c
index 01722e0..f7b4d52 100644
--- a/drivers/clk/mediatek/clk-mt2701.c
+++ b/drivers/clk/mediatek/clk-mt2701.c
@@ -573,6 +573,21 @@ static const struct mtk_gate top_clks[] __initconst = {
 	GATE_TOP_AUD(CLK_TOP_AUD_I2S6_MCLK, "aud_i2s6_mclk", "aud_k6_src_div", 28),
 };
 
+static struct clk_onecell_data *top_clk_data __initdata;
+static struct clk_onecell_data *pll_clk_data __initdata;
+
+static void __init mtk_clk_enable_critical(void)
+{
+	if (!top_clk_data || !pll_clk_data)
+		return;
+
+	clk_prepare_enable(pll_clk_data->clks[CLK_APMIXED_ARMPLL]);
+	clk_prepare_enable(top_clk_data->clks[CLK_TOP_AXI_SEL]);
+	clk_prepare_enable(top_clk_data->clks[CLK_TOP_MEM_SEL]);
+	clk_prepare_enable(top_clk_data->clks[CLK_TOP_DDRPHYCFG_SEL]);
+	clk_prepare_enable(top_clk_data->clks[CLK_TOP_RTC_SEL]);
+}
+
 static void __init mtk_topckgen_init(struct device_node *node)
 {
 	struct clk_onecell_data *clk_data;
@@ -585,7 +600,7 @@ static void __init mtk_topckgen_init(struct device_node *node)
 		return;
 	}
 
-	clk_data = mtk_alloc_clk_data(CLK_TOP_NR);
+	top_clk_data = clk_data = mtk_alloc_clk_data(CLK_TOP_NR);
 
 	mtk_clk_register_fixed_clks(top_fixed_clks, ARRAY_SIZE(top_fixed_clks),
 								clk_data);
@@ -606,6 +621,8 @@ static void __init mtk_topckgen_init(struct device_node *node)
 	if (r)
 		pr_err("%s(): could not register clock provider: %d\n",
 			__func__, r);
+
+	mtk_clk_enable_critical();
 }
 CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt2701-topckgen", mtk_topckgen_init);
 
@@ -1201,7 +1218,7 @@ static void __init mtk_apmixedsys_init(struct device_node *node)
 	struct clk_onecell_data *clk_data;
 	int r;
 
-	clk_data = mtk_alloc_clk_data(ARRAY_SIZE(apmixed_plls));
+	pll_clk_data = clk_data = mtk_alloc_clk_data(ARRAY_SIZE(apmixed_plls));
 	if (!clk_data)
 		return;
 
@@ -1212,6 +1229,8 @@ static void __init mtk_apmixedsys_init(struct device_node *node)
 	if (r)
 		pr_err("%s(): could not register clock provider: %d\n",
 			__func__, r);
+
+	mtk_clk_enable_critical();
 }
 CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt2701-apmixedsys",
 							mtk_apmixedsys_init);
-- 
1.9.1



From jamesjj.liao at mediatek.com  Fri Feb  5 01:37:27 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Fri, 5 Feb 2016 17:37:27 +0800
Subject: [PATCH v6 4/7] clk: mediatek: Add MT2701 clock support
In-Reply-To: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
References: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <1454665050-37776-5-git-send-email-jamesjj.liao@mediatek.com>

From: Shunli Wang <shunli.wang at mediatek.com>

Add MT2701 clock support, include topckgen, apmixedsys,
infracfg, pericfg and subsystem clocks.

Signed-off-by: Shunli Wang <shunli.wang at mediatek.com>
Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
Tested-by: John Crispin <blogic at openwrt.org>
---
 drivers/clk/mediatek/Kconfig      |    8 +
 drivers/clk/mediatek/Makefile     |    1 +
 drivers/clk/mediatek/clk-gate.c   |   52 ++
 drivers/clk/mediatek/clk-gate.h   |    2 +
 drivers/clk/mediatek/clk-mt2701.c | 1211 +++++++++++++++++++++++++++++++++++++
 drivers/clk/mediatek/clk-mtk.c    |   25 +
 drivers/clk/mediatek/clk-mtk.h    |   34 +-
 7 files changed, 1330 insertions(+), 3 deletions(-)
 create mode 100644 drivers/clk/mediatek/clk-mt2701.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index dc224e6..1e56000 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -6,6 +6,14 @@ config COMMON_CLK_MEDIATEK
 	---help---
 	  Mediatek SoCs' clock support.
 
+config COMMON_CLK_MT2701
+	bool "Clock driver for Mediatek MT2701"
+	depends on COMMON_CLK
+	select COMMON_CLK_MEDIATEK
+	default ARCH_MEDIATEK
+	---help---
+	  This driver supports Mediatek MT2701 clocks.
+
 config COMMON_CLK_MT8135
 	bool "Clock driver for Mediatek MT8135"
 	depends on COMMON_CLK
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 32e7222..5b2b91b 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o clk-apmixed.o
 obj-$(CONFIG_RESET_CONTROLLER) += reset.o
+obj-$(CONFIG_COMMON_CLK_MT2701) += clk-mt2701.o
 obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o
 obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173.o
diff --git a/drivers/clk/mediatek/clk-gate.c b/drivers/clk/mediatek/clk-gate.c
index 576bdb7..6a68058 100644
--- a/drivers/clk/mediatek/clk-gate.c
+++ b/drivers/clk/mediatek/clk-gate.c
@@ -61,6 +61,22 @@ static void mtk_cg_clr_bit(struct clk_hw *hw)
 	regmap_write(cg->regmap, cg->clr_ofs, BIT(cg->bit));
 }
 
+static void mtk_cg_set_bit_no_setclr(struct clk_hw *hw)
+{
+	struct mtk_clk_gate *cg = to_clk_gate(hw);
+	u32 cgbit = BIT(cg->bit);
+
+	regmap_update_bits(cg->regmap, cg->sta_ofs, cgbit, cgbit);
+}
+
+static void mtk_cg_clr_bit_no_setclr(struct clk_hw *hw)
+{
+	struct mtk_clk_gate *cg = to_clk_gate(hw);
+	u32 cgbit = BIT(cg->bit);
+
+	regmap_update_bits(cg->regmap, cg->sta_ofs, cgbit, 0);
+}
+
 static int mtk_cg_enable(struct clk_hw *hw)
 {
 	mtk_cg_clr_bit(hw);
@@ -85,6 +101,30 @@ static void mtk_cg_disable_inv(struct clk_hw *hw)
 	mtk_cg_clr_bit(hw);
 }
 
+static int mtk_cg_enable_no_setclr(struct clk_hw *hw)
+{
+	mtk_cg_clr_bit_no_setclr(hw);
+
+	return 0;
+}
+
+static void mtk_cg_disable_no_setclr(struct clk_hw *hw)
+{
+	mtk_cg_set_bit_no_setclr(hw);
+}
+
+static int mtk_cg_enable_inv_no_setclr(struct clk_hw *hw)
+{
+	mtk_cg_set_bit_no_setclr(hw);
+
+	return 0;
+}
+
+static void mtk_cg_disable_inv_no_setclr(struct clk_hw *hw)
+{
+	mtk_cg_clr_bit_no_setclr(hw);
+}
+
 const struct clk_ops mtk_clk_gate_ops_setclr = {
 	.is_enabled	= mtk_cg_bit_is_cleared,
 	.enable		= mtk_cg_enable,
@@ -97,6 +137,18 @@ const struct clk_ops mtk_clk_gate_ops_setclr_inv = {
 	.disable	= mtk_cg_disable_inv,
 };
 
+const struct clk_ops mtk_clk_gate_ops_no_setclr = {
+	.is_enabled	= mtk_cg_bit_is_cleared,
+	.enable		= mtk_cg_enable_no_setclr,
+	.disable	= mtk_cg_disable_no_setclr,
+};
+
+const struct clk_ops mtk_clk_gate_ops_no_setclr_inv = {
+	.is_enabled	= mtk_cg_bit_is_set,
+	.enable		= mtk_cg_enable_inv_no_setclr,
+	.disable	= mtk_cg_disable_inv_no_setclr,
+};
+
 struct clk * __init mtk_clk_register_gate(
 		const char *name,
 		const char *parent_name,
diff --git a/drivers/clk/mediatek/clk-gate.h b/drivers/clk/mediatek/clk-gate.h
index 11e25c9..7f7ef34 100644
--- a/drivers/clk/mediatek/clk-gate.h
+++ b/drivers/clk/mediatek/clk-gate.h
@@ -36,6 +36,8 @@ static inline struct mtk_clk_gate *to_clk_gate(struct clk_hw *hw)
 
 extern const struct clk_ops mtk_clk_gate_ops_setclr;
 extern const struct clk_ops mtk_clk_gate_ops_setclr_inv;
+extern const struct clk_ops mtk_clk_gate_ops_no_setclr;
+extern const struct clk_ops mtk_clk_gate_ops_no_setclr_inv;
 
 struct clk *mtk_clk_register_gate(
 		const char *name,
diff --git a/drivers/clk/mediatek/clk-mt2701.c b/drivers/clk/mediatek/clk-mt2701.c
new file mode 100644
index 0000000..0ac45fc
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt2701.c
@@ -0,0 +1,1211 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Shunli Wang <shunli.wang at mediatek.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.
+ */
+
+#include <linux/clk.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+#include "clk-mtk.h"
+#include "clk-gate.h"
+
+#include <dt-bindings/clock/mt2701-clk.h>
+
+static DEFINE_SPINLOCK(lock);
+
+static const struct mtk_fixed_clk top_fixed_clks[] __initconst = {
+	FIXED_CLK(CLK_TOP_DPI, "dpi_ck", "clk26m", 108 * MHZ),
+	FIXED_CLK(CLK_TOP_DMPLL, "dmpll_ck", "clk26m", 400 * MHZ),
+	FIXED_CLK(CLK_TOP_VENCPLL, "vencpll_ck", "clk26m", 295750000),
+	FIXED_CLK(CLK_TOP_HDMI_0_PIX340M, "hdmi_0_pix340m", "clk26m", 340 * MHZ),
+	FIXED_CLK(CLK_TOP_HDMI_0_DEEP340M, "hdmi_0_deep340m", "clk26m", 340 * MHZ),
+	FIXED_CLK(CLK_TOP_HDMI_0_PLL340M, "hdmi_0_pll340m", "clk26m", 340 * MHZ),
+	FIXED_CLK(CLK_TOP_HDMITX_CLKDIG_CTS, "hdmitx_dig_cts", "clk26m", 300 * MHZ),
+	FIXED_CLK(CLK_TOP_HADDS2_FB, "hadds2_fbclk", "clk26m", 27 * MHZ),
+	FIXED_CLK(CLK_TOP_WBG_DIG_416M, "wbg_dig_ck_416m", "clk26m", 416 * MHZ),
+};
+
+static const struct mtk_fixed_factor top_fixed_divs[] __initconst = {
+	FACTOR(CLK_TOP_SYSPLL, "syspll_ck", "mainpll", 1, 1),
+	FACTOR(CLK_TOP_SYSPLL_D2, "syspll_d2", "mainpll", 1, 2),
+	FACTOR(CLK_TOP_SYSPLL_D3, "syspll_d3", "mainpll", 1, 3),
+	FACTOR(CLK_TOP_SYSPLL_D5, "syspll_d5", "mainpll", 1, 5),
+	FACTOR(CLK_TOP_SYSPLL_D7, "syspll_d7", "mainpll", 1, 7),
+	FACTOR(CLK_TOP_SYSPLL1_D2, "syspll1_d2", "syspll_d2", 1, 2),
+	FACTOR(CLK_TOP_SYSPLL1_D4, "syspll1_d4", "syspll_d2", 1, 4),
+	FACTOR(CLK_TOP_SYSPLL1_D8, "syspll1_d8", "syspll_d2", 1, 8),
+	FACTOR(CLK_TOP_SYSPLL1_D16, "syspll1_d16", "syspll_d2", 1, 16),
+	FACTOR(CLK_TOP_SYSPLL2_D2, "syspll2_d2", "syspll_d3", 1, 2),
+	FACTOR(CLK_TOP_SYSPLL2_D4, "syspll2_d4", "syspll_d3", 1, 4),
+	FACTOR(CLK_TOP_SYSPLL2_D8, "syspll2_d8", "syspll_d3", 1, 8),
+	FACTOR(CLK_TOP_SYSPLL3_D2, "syspll3_d2", "syspll_d5", 1, 2),
+	FACTOR(CLK_TOP_SYSPLL3_D4, "syspll3_d4", "syspll_d5", 1, 4),
+	FACTOR(CLK_TOP_SYSPLL4_D2, "syspll4_d2", "syspll_d7", 1, 2),
+	FACTOR(CLK_TOP_SYSPLL4_D4, "syspll4_d4", "syspll_d7", 1, 4),
+
+	FACTOR(CLK_TOP_UNIVPLL, "univpll_ck", "univpll", 1, 1),
+	FACTOR(CLK_TOP_UNIVPLL_D2, "univpll_d2", "univpll", 1, 2),
+	FACTOR(CLK_TOP_UNIVPLL_D3, "univpll_d3", "univpll", 1, 3),
+	FACTOR(CLK_TOP_UNIVPLL_D5, "univpll_d5", "univpll", 1, 5),
+	FACTOR(CLK_TOP_UNIVPLL_D7, "univpll_d7", "univpll", 1, 7),
+	FACTOR(CLK_TOP_UNIVPLL_D26, "univpll_d26", "univpll", 1, 26),
+	FACTOR(CLK_TOP_UNIVPLL_D52, "univpll_d52", "univpll", 1, 52),
+	FACTOR(CLK_TOP_UNIVPLL_D108, "univpll_d108", "univpll", 1, 108),
+	FACTOR(CLK_TOP_USB_PHY48M, "USB_PHY48M_CK", "univpll", 1, 26),
+	FACTOR(CLK_TOP_UNIVPLL1_D2, "univpll1_d2", "univpll_d2", 1, 2),
+	FACTOR(CLK_TOP_UNIVPLL1_D4, "univpll1_d4", "univpll_d2", 1, 4),
+	FACTOR(CLK_TOP_UNIVPLL1_D8, "univpll1_d8", "univpll_d2", 1, 8),
+	FACTOR(CLK_TOP_8BDAC, "8bdac_ck", "univpll_d2", 1, 1),
+	FACTOR(CLK_TOP_UNIVPLL2_D2, "univpll2_d2", "univpll_d3", 1, 2),
+	FACTOR(CLK_TOP_UNIVPLL2_D4, "univpll2_d4", "univpll_d3", 1, 4),
+	FACTOR(CLK_TOP_UNIVPLL2_D8, "univpll2_d8", "univpll_d3", 1, 8),
+	FACTOR(CLK_TOP_UNIVPLL2_D16, "univpll2_d16", "univpll_d3", 1, 16),
+	FACTOR(CLK_TOP_UNIVPLL2_D32, "univpll2_d32", "univpll_d3", 1, 32),
+	FACTOR(CLK_TOP_UNIVPLL3_D2, "univpll3_d2", "univpll_d5", 1, 2),
+	FACTOR(CLK_TOP_UNIVPLL3_D4, "univpll3_d4", "univpll_d5", 1, 4),
+	FACTOR(CLK_TOP_UNIVPLL3_D8, "univpll3_d8", "univpll_d5", 1, 8),
+
+	FACTOR(CLK_TOP_MSDCPLL, "msdcpll_ck", "msdcpll", 1, 1),
+	FACTOR(CLK_TOP_MSDCPLL_D2, "msdcpll_d2", "msdcpll", 1, 2),
+	FACTOR(CLK_TOP_MSDCPLL_D4, "msdcpll_d4", "msdcpll", 1, 4),
+	FACTOR(CLK_TOP_MSDCPLL_D8, "msdcpll_d8", "msdcpll", 1, 8),
+
+	FACTOR(CLK_TOP_MMPLL, "mmpll_ck", "mmpll", 1, 1),
+	FACTOR(CLK_TOP_MMPLL_D2, "mmpll_d2", "mmpll", 1, 2),
+
+	FACTOR(CLK_TOP_DMPLL_D2, "dmpll_d2", "dmpll_ck", 1, 2),
+	FACTOR(CLK_TOP_DMPLL_D4, "dmpll_d4", "dmpll_ck", 1, 4),
+	FACTOR(CLK_TOP_DMPLL_X2, "dmpll_x2", "dmpll_ck", 1, 1),
+
+	FACTOR(CLK_TOP_TVDPLL, "tvdpll_ck", "tvdpll", 1, 1),
+	FACTOR(CLK_TOP_TVDPLL_D2, "tvdpll_d2", "tvdpll", 1, 2),
+	FACTOR(CLK_TOP_TVDPLL_D4, "tvdpll_d4", "tvdpll", 1, 4),
+
+	FACTOR(CLK_TOP_VDECPLL, "vdecpll_ck", "vdecpll", 1, 1),
+	FACTOR(CLK_TOP_TVD2PLL, "tvd2pll_ck", "tvd2pll", 1, 1),
+	FACTOR(CLK_TOP_TVD2PLL_D2, "tvd2pll_d2", "tvd2pll", 1, 2),
+
+	FACTOR(CLK_TOP_MIPIPLL, "mipipll", "dpi_ck", 1, 1),
+	FACTOR(CLK_TOP_MIPIPLL_D2, "mipipll_d2", "dpi_ck", 1, 2),
+	FACTOR(CLK_TOP_MIPIPLL_D4, "mipipll_d4", "dpi_ck", 1, 4),
+
+	FACTOR(CLK_TOP_HDMIPLL, "hdmipll_ck", "hdmitx_dig_cts", 1, 1),
+	FACTOR(CLK_TOP_HDMIPLL_D2, "hdmipll_d2", "hdmitx_dig_cts", 1, 2),
+	FACTOR(CLK_TOP_HDMIPLL_D3, "hdmipll_d3", "hdmitx_dig_cts", 1, 3),
+
+	FACTOR(CLK_TOP_ARMPLL_1P3G, "armpll_1p3g_ck", "armpll", 1, 1),
+
+	FACTOR(CLK_TOP_AUDPLL, "audpll", "audpll_sel", 1, 1),
+	FACTOR(CLK_TOP_AUDPLL_D4, "audpll_d4", "audpll_sel", 1, 4),
+	FACTOR(CLK_TOP_AUDPLL_D8, "audpll_d8", "audpll_sel", 1, 8),
+	FACTOR(CLK_TOP_AUDPLL_D16, "audpll_d16", "audpll_sel", 1, 16),
+	FACTOR(CLK_TOP_AUDPLL_D24, "audpll_d24", "audpll_sel", 1, 24),
+
+	FACTOR(CLK_TOP_AUD1PLL_98M, "aud1pll_98m_ck", "aud1pll", 1, 3),
+	FACTOR(CLK_TOP_AUD2PLL_90M, "aud2pll_90m_ck", "aud2pll", 1, 3),
+	FACTOR(CLK_TOP_HADDS2PLL_98M, "hadds2pll_98m", "hadds2pll", 1, 3),
+	FACTOR(CLK_TOP_HADDS2PLL_294M, "hadds2pll_294m", "hadds2pll", 1, 1),
+	FACTOR(CLK_TOP_ETHPLL_500M, "ethpll_500m_ck", "ethpll", 1, 1),
+	FACTOR(CLK_TOP_CLK26M_D8, "clk26m_d8", "clk26m", 1, 8),
+	FACTOR(CLK_TOP_32K_INTERNAL, "32k_internal", "clk26m", 1, 793),
+	FACTOR(CLK_TOP_32K_EXTERNAL, "32k_external", "rtc32k", 1, 1),
+};
+
+static const char * const axi_parents[] __initconst = {
+	"clk26m",
+	"syspll1_d2",
+	"syspll_d5",
+	"syspll1_d4",
+	"univpll_d5",
+	"univpll2_d2",
+	"mmpll_d2",
+	"dmpll_d2"
+};
+
+static const char * const mem_parents[] __initconst = {
+	"clk26m",
+	"dmpll_ck"
+};
+
+static const char * const ddrphycfg_parents[] __initconst = {
+	"clk26m",
+	"syspll1_d8"
+};
+
+static const char * const mm_parents[] __initconst = {
+	"clk26m",
+	"vencpll_ck",
+	"syspll1_d2",
+	"syspll1_d4",
+	"univpll_d5",
+	"univpll1_d2",
+	"univpll2_d2",
+	"dmpll_ck"
+};
+
+static const char * const pwm_parents[] __initconst = {
+	"clk26m",
+	"univpll2_d4",
+	"univpll3_d2",
+	"univpll1_d4",
+};
+
+static const char * const vdec_parents[] __initconst = {
+	"clk26m",
+	"vdecpll_ck",
+	"syspll_d5",
+	"syspll1_d4",
+	"univpll_d5",
+	"univpll2_d2",
+	"vencpll_ck",
+	"msdcpll_d2",
+	"mmpll_d2"
+};
+
+static const char * const mfg_parents[] __initconst = {
+	"clk26m",
+	"mmpll_ck",
+	"dmpll_x2_ck",
+	"msdcpll_ck",
+	"clk26m",
+	"syspll_d3",
+	"univpll_d3",
+	"univpll1_d2"
+};
+
+static const char * const camtg_parents[] __initconst = {
+	"clk26m",
+	"univpll_d26",
+	"univpll2_d2",
+	"syspll3_d2",
+	"syspll3_d4",
+	"msdcpll_d2",
+	"mmpll_d2"
+};
+
+static const char * const uart_parents[] __initconst = {
+	"clk26m",
+	"univpll2_d8"
+};
+
+static const char * const spi_parents[] __initconst = {
+	"clk26m",
+	"syspll3_d2",
+	"syspll4_d2",
+	"univpll2_d4",
+	"univpll1_d8"
+};
+
+static const char * const usb20_parents[] __initconst = {
+	"clk26m",
+	"univpll1_d8",
+	"univpll3_d4"
+};
+
+static const char * const msdc30_parents[] __initconst = {
+	"clk26m",
+	"msdcpll_d2",
+	"syspll2_d2",
+	"syspll1_d4",
+	"univpll1_d4",
+	"univpll2_d4"
+};
+
+static const char * const audio_parents[] __initconst = {
+	"clk26m",
+	"syspll1_d16"
+};
+
+static const char * const aud_intbus_parents[] __initconst = {
+	"clk26m",
+	"syspll1_d4",
+	"syspll3_d2",
+	"syspll4_d2",
+	"univpll3_d2",
+	"univpll2_d4"
+};
+
+static const char * const pmicspi_parents[] __initconst = {
+	"clk26m",
+	"syspll1_d8",
+	"syspll2_d4",
+	"syspll4_d2",
+	"syspll3_d4",
+	"syspll2_d8",
+	"syspll1_d16",
+	"univpll3_d4",
+	"univpll_d26",
+	"dmpll_d2",
+	"dmpll_d4"
+};
+
+static const char * const scp_parents[] __initconst = {
+	"clk26m",
+	"syspll1_d8",
+	"dmpll_d2",
+	"dmpll_d4"
+};
+
+static const char * const dpi0_parents[] __initconst = {
+	"clk26m",
+	"mipipll",
+	"mipipll_d2",
+	"mipipll_d4",
+	"clk26m",
+	"tvdpll_ck",
+	"tvdpll_d2",
+	"tvdpll_d4"
+};
+
+static const char * const dpi1_parents[] __initconst = {
+	"clk26m",
+	"tvdpll_ck",
+	"tvdpll_d2",
+	"tvdpll_d4"
+};
+
+static const char * const tve_parents[] __initconst = {
+	"clk26m",
+	"mipipll",
+	"mipipll_d2",
+	"mipipll_d4",
+	"clk26m",
+	"tvdpll_ck",
+	"tvdpll_d2",
+	"tvdpll_d4"
+};
+
+static const char * const hdmi_parents[] __initconst = {
+	"clk26m",
+	"hdmipll_ck",
+	"hdmipll_d2",
+	"hdmipll_d3"
+};
+
+static const char * const apll_parents[] __initconst = {
+	"clk26m",
+	"audpll",
+	"audpll_d4",
+	"audpll_d8",
+	"audpll_d16",
+	"audpll_d24",
+	"clk26m",
+	"clk26m"
+};
+
+static const char * const rtc_parents[] __initconst = {
+	"32k_internal",
+	"32k_external",
+	"clk26m",
+	"univpll3_d8"
+};
+
+static const char * const nfi2x_parents[] __initconst = {
+	"clk26m",
+	"syspll2_d2",
+	"syspll_d7",
+	"univpll3_d2",
+	"syspll2_d4",
+	"univpll3_d4",
+	"syspll4_d4",
+	"clk26m"
+};
+
+static const char * const emmc_hclk_parents[] __initconst = {
+	"clk26m",
+	"syspll1_d2",
+	"syspll1_d4",
+	"syspll2_d2"
+};
+
+static const char * const flash_parents[] __initconst = {
+	"clk26m_d8",
+	"clk26m",
+	"syspll2_d8",
+	"syspll3_d4",
+	"univpll3_d4",
+	"syspll4_d2",
+	"syspll2_d4",
+	"univpll2_d4"
+};
+
+static const char * const di_parents[] __initconst = {
+	"clk26m",
+	"tvd2pll_ck",
+	"tvd2pll_d2",
+	"clk26m"
+};
+
+static const char * const nr_osd_parents[] __initconst = {
+	"clk26m",
+	"vencpll_ck",
+	"syspll1_d2",
+	"syspll1_d4",
+	"univpll_d5",
+	"univpll1_d2",
+	"univpll2_d2",
+	"dmpll_ck"
+};
+
+static const char * const hdmirx_bist_parents[] __initconst = {
+	"clk26m",
+	"syspll_d3",
+	"clk26m",
+	"syspll1_d16",
+	"syspll4_d2",
+	"syspll1_d4",
+	"vencpll_ck",
+	"clk26m"
+};
+
+static const char * const intdir_parents[] __initconst = {
+	"clk26m",
+	"mmpll_ck",
+	"syspll_d2",
+	"univpll_d2"
+};
+
+static const char * const asm_parents[] __initconst = {
+	"clk26m",
+	"univpll2_d4",
+	"univpll2_d2",
+	"syspll_d5"
+};
+
+static const char * const ms_card_parents[] __initconst = {
+	"clk26m",
+	"univpll3_d8",
+	"syspll4_d4"
+};
+
+static const char * const ethif_parents[] __initconst = {
+	"clk26m",
+	"syspll1_d2",
+	"syspll_d5",
+	"syspll1_d4",
+	"univpll_d5",
+	"univpll1_d2",
+	"dmpll_ck",
+	"dmpll_d2"
+};
+
+static const char * const hdmirx_parents[] __initconst = {
+	"clk26m",
+	"univpll_d52"
+};
+
+static const char * const cmsys_parents[] __initconst = {
+	"clk26m",
+	"syspll1_d2",
+	"univpll1_d2",
+	"univpll_d5",
+	"syspll_d5",
+	"syspll2_d2",
+	"syspll1_d4",
+	"syspll3_d2",
+	"syspll2_d4",
+	"syspll1_d8",
+	"clk26m",
+	"clk26m",
+	"clk26m",
+	"clk26m",
+	"clk26m"
+};
+
+static const char * const clk_8bdac_parents[] __initconst = {
+	"clkrtc_int",
+	"8bdac_ck_pre",
+	"clk26m",
+	"clk26m"
+};
+
+static const char * const aud2dvd_parents[] __initconst = {
+	"a1sys_hp_ck",
+	"a2sys_hp_ck"
+};
+
+static const char * const padmclk_parents[] __initconst = {
+	"clk26m",
+	"univpll_d26",
+	"univpll_d52",
+	"univpll_d108",
+	"univpll2_d8",
+	"univpll2_d16",
+	"univpll2_d32"
+};
+
+static const char * const aud_mux_parents[] __initconst = {
+	"clk26m",
+	"aud1pll_98m_ck",
+	"aud2pll_90m_ck",
+	"hadds2pll_98m",
+	"audio_ext1_ck",
+	"audio_ext2_ck"
+};
+
+static const char * const aud_src_parents[] __initconst = {
+	"aud_mux1_sel",
+	"aud_mux2_sel"
+};
+
+static const char * const cpu_parents[] __initconst = {
+	"clk26m",
+	"armpll",
+	"mainpll",
+	"mmpll"
+};
+
+static const struct mtk_composite top_muxes[] __initconst = {
+	MUX_GATE(CLK_TOP_AXI_SEL, "axi_sel", axi_parents,
+		0x0040, 0, 3, INVALID_MUX_GATE_BIT),
+	MUX_GATE(CLK_TOP_MEM_SEL, "mem_sel", mem_parents, 0x0040, 8, 1, 15),
+	MUX_GATE(CLK_TOP_DDRPHYCFG_SEL, "ddrphycfg_sel", ddrphycfg_parents, 0x0040, 16, 1, 23),
+	MUX_GATE(CLK_TOP_MM_SEL, "mm_sel", mm_parents, 0x0040, 24, 3, 31),
+
+	MUX_GATE(CLK_TOP_PWM_SEL, "pwm_sel", pwm_parents, 0x0050, 0, 2, 7),
+	MUX_GATE(CLK_TOP_VDEC_SEL, "vdec_sel", vdec_parents, 0x0050, 8, 4, 15),
+	MUX_GATE(CLK_TOP_MFG_SEL, "mfg_sel", mfg_parents, 0x0050, 16, 3, 23),
+	MUX_GATE(CLK_TOP_CAMTG_SEL, "camtg_sel", camtg_parents, 0x0050, 24, 3, 31),
+	MUX_GATE(CLK_TOP_UART_SEL, "uart_sel", uart_parents, 0x0060, 0, 1, 7),
+
+	MUX_GATE(CLK_TOP_SPI0_SEL, "spi0_sel", spi_parents, 0x0060, 8, 3, 15),
+	MUX_GATE(CLK_TOP_USB20_SEL, "usb20_sel", usb20_parents, 0x0060, 16, 2, 23),
+	MUX_GATE(CLK_TOP_MSDC30_0_SEL, "msdc30_0_sel", msdc30_parents, 0x0060, 24, 3, 31),
+
+	MUX_GATE(CLK_TOP_MSDC30_1_SEL, "msdc30_1_sel", msdc30_parents, 0x0070, 0, 3, 7),
+	MUX_GATE(CLK_TOP_MSDC30_2_SEL, "msdc30_2_sel", msdc30_parents, 0x0070, 8, 3, 15),
+	MUX_GATE(CLK_TOP_AUDIO_SEL, "audio_sel", msdc30_parents, 0x0070, 16, 1, 23),
+	MUX_GATE(CLK_TOP_AUDINTBUS_SEL, "aud_intbus_sel", aud_intbus_parents, 0x0070, 24, 3, 31),
+
+	MUX_GATE(CLK_TOP_PMICSPI_SEL, "pmicspi_sel", pmicspi_parents, 0x0080, 0, 4, 7),
+	MUX_GATE(CLK_TOP_SCP_SEL, "scp_sel", scp_parents, 0x0080, 8, 2, 15),
+	MUX_GATE(CLK_TOP_DPI0_SEL, "dpi0_sel", dpi0_parents, 0x0080, 16, 3, 23),
+	MUX_GATE(CLK_TOP_DPI1_SEL, "dpi1_sel", dpi1_parents, 0x0080, 24, 2, 31),
+
+	MUX_GATE(CLK_TOP_TVE_SEL, "tve_sel", tve_parents, 0x0090, 0, 3, 7),
+	MUX_GATE(CLK_TOP_HDMI_SEL, "hdmi_sel", hdmi_parents, 0x0090, 8, 2, 15),
+	MUX_GATE(CLK_TOP_APLL_SEL, "apll_sel", apll_parents, 0x0090, 16, 3, 23),
+
+	MUX_GATE(CLK_TOP_RTC_SEL, "rtc_sel", rtc_parents, 0x00A0, 0, 2, 7),
+	MUX_GATE(CLK_TOP_NFI2X_SEL, "nfi2x_sel", nfi2x_parents, 0x00A0, 8, 3, 15),
+	MUX_GATE(CLK_TOP_EMMC_HCLK_SEL, "emmc_hclk_sel", emmc_hclk_parents, 0x00A0, 24, 2, 31),
+
+	MUX_GATE(CLK_TOP_FLASH_SEL, "flash_sel", flash_parents, 0x00B0, 0, 3, 7),
+	MUX_GATE(CLK_TOP_DI_SEL, "di_sel", di_parents, 0x00B0, 8, 2, 15),
+	MUX_GATE(CLK_TOP_NR_SEL, "nr_sel", nr_osd_parents, 0x00B0, 16, 3, 23),
+	MUX_GATE(CLK_TOP_OSD_SEL, "osd_sel", nr_osd_parents, 0x00B0, 24, 3, 31),
+
+	MUX_GATE(CLK_TOP_HDMIRX_BIST_SEL, "hdmirx_bist_sel", hdmirx_bist_parents, 0x00C0, 0, 3, 7),
+	MUX_GATE(CLK_TOP_INTDIR_SEL, "intdir_sel", intdir_parents, 0x00C0, 8, 2, 15),
+	MUX_GATE(CLK_TOP_ASM_I_SEL, "asm_i_sel", asm_parents, 0x00C0, 16, 2, 23),
+	MUX_GATE(CLK_TOP_ASM_M_SEL, "asm_m_sel", asm_parents, 0x00C0, 24, 3, 31),
+
+	MUX_GATE(CLK_TOP_ASM_H_SEL, "asm_h_sel", asm_parents, 0x00D0, 0, 2, 7),
+	MUX_GATE(CLK_TOP_MS_CARD_SEL, "ms_card_sel", ms_card_parents, 0x00D0, 16, 2, 23),
+	MUX_GATE(CLK_TOP_ETHIF_SEL, "ethif_sel", ethif_parents, 0x00D0, 24, 3, 31),
+
+	MUX_GATE(CLK_TOP_HDMIRX26_24_SEL, "hdmirx26_24_sel", hdmirx_parents, 0x00E0, 0, 1, 7),
+	MUX_GATE(CLK_TOP_MSDC30_3_SEL, "msdc30_3_sel", msdc30_parents, 0x00E0, 8, 3, 15),
+	MUX_GATE(CLK_TOP_CMSYS_SEL, "cmsys_sel", cmsys_parents, 0x00E0, 16, 4, 23),
+
+	MUX_GATE(CLK_TOP_SPI1_SEL, "spi2_sel", spi_parents, 0x00E0, 24, 3, 31),
+	MUX_GATE(CLK_TOP_SPI2_SEL, "spi1_sel", spi_parents, 0x00F0, 0, 3, 7),
+	MUX_GATE(CLK_TOP_8BDAC_SEL, "8bdac_sel", clk_8bdac_parents, 0x00F0, 8, 2, 15),
+	MUX_GATE(CLK_TOP_AUD2DVD_SEL, "aud2dvd_sel", aud2dvd_parents, 0x00F0, 16, 1, 23),
+
+	MUX(CLK_TOP_PADMCLK_SEL, "padmclk_sel", padmclk_parents, 0x0100, 0, 3),
+
+	MUX(CLK_TOP_AUD_MUX1_SEL, "aud_mux1_sel", aud_mux_parents, 0x012c, 0, 3),
+	MUX(CLK_TOP_AUD_MUX2_SEL, "aud_mux2_sel", aud_mux_parents, 0x012c, 3, 3),
+	MUX(CLK_TOP_AUDPLL_MUX_SEL, "audpll_sel", aud_mux_parents, 0x012c, 6, 3),
+	MUX_GATE(CLK_TOP_AUD_K1_SRC_SEL, "aud_k1_src_sel", aud_src_parents, 0x012c, 15, 1, 23),
+	MUX_GATE(CLK_TOP_AUD_K2_SRC_SEL, "aud_k2_src_sel", aud_src_parents, 0x012c, 16, 1, 24),
+	MUX_GATE(CLK_TOP_AUD_K3_SRC_SEL, "aud_k3_src_sel", aud_src_parents, 0x012c, 17, 1, 25),
+	MUX_GATE(CLK_TOP_AUD_K4_SRC_SEL, "aud_k4_src_sel", aud_src_parents, 0x012c, 18, 1, 26),
+	MUX_GATE(CLK_TOP_AUD_K5_SRC_SEL, "aud_k5_src_sel", aud_src_parents, 0x012c, 19, 1, 27),
+	MUX_GATE(CLK_TOP_AUD_K6_SRC_SEL, "aud_k6_src_sel", aud_src_parents, 0x012c, 20, 1, 28),
+};
+
+static const struct mtk_clk_divider top_adj_divs[] __initconst = {
+	DIV_ADJ(CLK_TOP_AUD_EXTCK1_DIV, "audio_ext1_ck", "aud_ext_ck1", 0x0120, 0, 8),
+	DIV_ADJ(CLK_TOP_AUD_EXTCK2_DIV, "audio_ext2_ck", "aud_ext_ck2", 0x0120, 8, 8),
+	DIV_ADJ(CLK_TOP_AUD_MUX1_DIV, "aud_mux1_div", "aud_mux1_sel", 0x0120, 16, 8),
+	DIV_ADJ(CLK_TOP_AUD_MUX2_DIV, "aud_mux2_div", "aud_mux2_sel", 0x0120, 24, 8),
+	DIV_ADJ(CLK_TOP_AUD_K1_SRC_DIV, "aud_k1_src_div", "aud_k1_src_sel", 0x0124, 0, 8),
+	DIV_ADJ(CLK_TOP_AUD_K2_SRC_DIV, "aud_k2_src_div", "aud_k2_src_sel", 0x0124, 8, 8),
+	DIV_ADJ(CLK_TOP_AUD_K3_SRC_DIV, "aud_k3_src_div", "aud_k3_src_sel", 0x0124, 16, 8),
+	DIV_ADJ(CLK_TOP_AUD_K4_SRC_DIV, "aud_k4_src_div", "aud_k4_src_sel", 0x0124, 24, 8),
+	DIV_ADJ(CLK_TOP_AUD_K5_SRC_DIV, "aud_k5_src_div", "aud_k5_src_sel", 0x0128, 0, 8),
+	DIV_ADJ(CLK_TOP_AUD_K6_SRC_DIV, "aud_k6_src_div", "aud_k6_src_sel", 0x0128, 8, 8),
+};
+
+static const struct mtk_gate_regs top_aud_cg_regs __initconst = {
+	.sta_ofs = 0x012C,
+};
+
+#define GATE_TOP_AUD(_id, _name, _parent, _shift) {	\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &top_aud_cg_regs,		\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_no_setclr,	\
+	}
+
+static const struct mtk_gate top_clks[] __initconst = {
+	GATE_TOP_AUD(CLK_TOP_AUD_48K_TIMING, "a1sys_hp_ck", "aud_mux1_div", 21),
+	GATE_TOP_AUD(CLK_TOP_AUD_44K_TIMING, "a2sys_hp_ck", "aud_mux2_div", 22),
+	GATE_TOP_AUD(CLK_TOP_AUD_I2S1_MCLK, "aud_i2s1_mclk", "aud_k1_src_div", 23),
+	GATE_TOP_AUD(CLK_TOP_AUD_I2S2_MCLK, "aud_i2s2_mclk", "aud_k2_src_div", 24),
+	GATE_TOP_AUD(CLK_TOP_AUD_I2S3_MCLK, "aud_i2s3_mclk", "aud_k3_src_div", 25),
+	GATE_TOP_AUD(CLK_TOP_AUD_I2S4_MCLK, "aud_i2s4_mclk", "aud_k4_src_div", 26),
+	GATE_TOP_AUD(CLK_TOP_AUD_I2S5_MCLK, "aud_i2s5_mclk", "aud_k5_src_div", 27),
+	GATE_TOP_AUD(CLK_TOP_AUD_I2S6_MCLK, "aud_i2s6_mclk", "aud_k6_src_div", 28),
+};
+
+static void __init mtk_topckgen_init(struct device_node *node)
+{
+	struct clk_onecell_data *clk_data;
+	void __iomem *base;
+	int r;
+
+	base = of_iomap(node, 0);
+	if (!base) {
+		pr_err("%s(): ioremap failed\n", __func__);
+		return;
+	}
+
+	clk_data = mtk_alloc_clk_data(CLK_TOP_NR);
+
+	mtk_clk_register_fixed_clks(top_fixed_clks, ARRAY_SIZE(top_fixed_clks),
+								clk_data);
+
+	mtk_clk_register_factors(top_fixed_divs, ARRAY_SIZE(top_fixed_divs),
+								clk_data);
+
+	mtk_clk_register_composites(top_muxes, ARRAY_SIZE(top_muxes),
+				base, &lock, clk_data);
+
+	mtk_clk_register_dividers(top_adj_divs, ARRAY_SIZE(top_adj_divs),
+				base, &lock, clk_data);
+
+	mtk_clk_register_gates(node, top_clks, ARRAY_SIZE(top_clks),
+						clk_data);
+
+	r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+	if (r)
+		pr_err("%s(): could not register clock provider: %d\n",
+			__func__, r);
+}
+CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt2701-topckgen", mtk_topckgen_init);
+
+static const struct mtk_gate_regs infra_cg_regs __initconst = {
+	.set_ofs = 0x0040,
+	.clr_ofs = 0x0044,
+	.sta_ofs = 0x0048,
+};
+
+#define GATE_ICG(_id, _name, _parent, _shift) {		\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &infra_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_setclr,	\
+	}
+
+static const struct mtk_gate infra_clks[] __initconst = {
+	GATE_ICG(CLK_INFRA_DBG, "dbgclk", "axi_sel", 0),
+	GATE_ICG(CLK_INFRA_SMI, "smi_ck", "mm_sel", 1),
+	GATE_ICG(CLK_INFRA_QAXI_CM4, "cm4_ck", "axi_sel", 2),
+	GATE_ICG(CLK_INFRA_AUD_SPLIN_B, "audio_splin_bck", "hadds2_294m_ck", 4),
+	GATE_ICG(CLK_INFRA_AUDIO, "audio_ck", "clk_null", 5),
+	GATE_ICG(CLK_INFRA_EFUSE, "efuse_ck", "clk26m", 6),
+	GATE_ICG(CLK_INFRA_L2C_SRAM, "l2c_sram_ck", "mm_sel", 7),
+	GATE_ICG(CLK_INFRA_M4U, "m4u_ck", "mem_sel", 8),
+	GATE_ICG(CLK_INFRA_CONNMCU, "connsys_bus", "wbg_dig_ck_416m", 12),
+	GATE_ICG(CLK_INFRA_TRNG, "trng_ck", "axi_sel", 13),
+	GATE_ICG(CLK_INFRA_RAMBUFIF, "rambufif_ck", "mem_sel", 14),
+	GATE_ICG(CLK_INFRA_CPUM, "cpum_ck", "mem_sel", 15),
+	GATE_ICG(CLK_INFRA_KP, "kp_ck", "axi_sel", 16),
+	GATE_ICG(CLK_INFRA_CEC, "cec_ck", "rtc_sel", 18),
+	GATE_ICG(CLK_INFRA_IRRX, "irrx_ck", "axi_sel", 19),
+	GATE_ICG(CLK_INFRA_PMICSPI, "pmicspi_ck", "pmicspi_sel", 22),
+	GATE_ICG(CLK_INFRA_PMICWRAP, "pmicwrap_ck", "axi_sel", 23),
+	GATE_ICG(CLK_INFRA_DDCCI, "ddcci_ck", "axi_sel", 24),
+};
+
+static const struct mtk_fixed_factor infra_fixed_divs[] __initconst = {
+	FACTOR(CLK_INFRA_CLK_13M, "clk13m", "clk26m", 1, 2),
+};
+
+static void __init mtk_infrasys_init(struct device_node *node)
+{
+	struct clk_onecell_data *clk_data;
+	int r;
+
+	clk_data = mtk_alloc_clk_data(CLK_INFRA_NR);
+
+	mtk_clk_register_gates(node, infra_clks, ARRAY_SIZE(infra_clks),
+						clk_data);
+	mtk_clk_register_factors(infra_fixed_divs, ARRAY_SIZE(infra_fixed_divs),
+						clk_data);
+
+	r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+	if (r)
+		pr_err("%s(): could not register clock provider: %d\n",
+			__func__, r);
+}
+CLK_OF_DECLARE(mtk_infrasys, "mediatek,mt2701-infracfg", mtk_infrasys_init);
+
+static const struct mtk_gate_regs peri0_cg_regs __initconst = {
+	.set_ofs = 0x0008,
+	.clr_ofs = 0x0010,
+	.sta_ofs = 0x0018,
+};
+
+static const struct mtk_gate_regs peri1_cg_regs __initconst = {
+	.set_ofs = 0x000c,
+	.clr_ofs = 0x0014,
+	.sta_ofs = 0x001c,
+};
+
+#define GATE_PERI0(_id, _name, _parent, _shift) {	\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &peri0_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_setclr,	\
+	}
+
+#define GATE_PERI1(_id, _name, _parent, _shift) {	\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &peri1_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_setclr,	\
+	}
+
+static const struct mtk_gate peri_clks[] __initconst = {
+	GATE_PERI1(CLK_PERI_USB0_MCU, "usb0_mcu_ck", "axi_sel", 31),
+	GATE_PERI1(CLK_PERI_ETH, "eth_ck", "clk26m", 30),
+	GATE_PERI1(CLK_PERI_SPI0, "spi0_ck", "spi0_sel", 29),
+	GATE_PERI1(CLK_PERI_AUXADC, "auxadc_ck", "clk26m", 28),
+	GATE_PERI0(CLK_PERI_I2C3, "i2c3_ck", "clk26m", 27),
+	GATE_PERI0(CLK_PERI_I2C2, "i2c2_ck", "axi_sel", 26),
+	GATE_PERI0(CLK_PERI_I2C1, "i2c1_ck", "axi_sel", 25),
+	GATE_PERI0(CLK_PERI_I2C0, "i2c0_ck", "axi_sel", 24),
+	GATE_PERI0(CLK_PERI_BTIF, "bitif_ck", "axi_sel", 23),
+	GATE_PERI0(CLK_PERI_UART3, "uart3_ck", "axi_sel", 22),
+	GATE_PERI0(CLK_PERI_UART2, "uart2_ck", "axi_sel", 21),
+	GATE_PERI0(CLK_PERI_UART1, "uart1_ck", "axi_sel", 20),
+	GATE_PERI0(CLK_PERI_UART0, "uart0_ck", "axi_sel", 19),
+	GATE_PERI0(CLK_PERI_NLI, "nli_ck", "axi_sel", 18),
+	GATE_PERI0(CLK_PERI_MSDC50_3, "msdc50_3_ck", "emmc_hclk_sel", 17),
+	GATE_PERI0(CLK_PERI_MSDC30_3, "msdc30_3_ck", "msdc30_3_sel", 16),
+	GATE_PERI0(CLK_PERI_MSDC30_2, "msdc30_2_ck", "msdc30_2_sel", 15),
+	GATE_PERI0(CLK_PERI_MSDC30_1, "msdc30_1_ck", "msdc30_1_sel", 14),
+	GATE_PERI0(CLK_PERI_MSDC30_0, "msdc30_0_ck", "msdc30_0_sel", 13),
+	GATE_PERI0(CLK_PERI_AP_DMA, "ap_dma_ck", "axi_sel", 12),
+	GATE_PERI0(CLK_PERI_USB1, "usb1_ck", "usb20_sel", 11),
+	GATE_PERI0(CLK_PERI_USB0, "usb0_ck", "usb20_sel", 10),
+	GATE_PERI0(CLK_PERI_PWM, "pwm_ck", "axi_sel", 9),
+	GATE_PERI0(CLK_PERI_PWM7, "pwm7_ck", "axi_sel", 8),
+	GATE_PERI0(CLK_PERI_PWM6, "pwm6_ck", "axi_sel", 7),
+	GATE_PERI0(CLK_PERI_PWM5, "pwm5_ck", "axi_sel", 6),
+	GATE_PERI0(CLK_PERI_PWM4, "pwm4_ck", "axi_sel", 5),
+	GATE_PERI0(CLK_PERI_PWM3, "pwm3_ck", "axi_sel", 4),
+	GATE_PERI0(CLK_PERI_PWM2, "pwm2_ck", "axi_sel", 3),
+	GATE_PERI0(CLK_PERI_PWM1, "pwm1_ck", "axi_sel", 2),
+	GATE_PERI0(CLK_PERI_THERM, "therm_ck", "axi_sel", 1),
+	GATE_PERI0(CLK_PERI_NFI, "nfi_ck", "nfi2x_sel", 0),
+
+	GATE_PERI1(CLK_PERI_FCI, "fci_ck", "ms_card", 11),
+	GATE_PERI1(CLK_PERI_SPI2, "spi2_ck", "spi2_sel", 10),
+	GATE_PERI1(CLK_PERI_SPI1, "spi1_ck", "spi1_sel", 9),
+	GATE_PERI1(CLK_PERI_HOST89_DVD, "host89_dvd_ck", "aud2dvd_sel", 8),
+	GATE_PERI1(CLK_PERI_HOST89_SPI, "host89_spi_ck", "spi0_sel", 7),
+	GATE_PERI1(CLK_PERI_HOST89_INT, "host89_int_ck", "axi_sel", 6),
+	GATE_PERI1(CLK_PERI_FLASH, "flash_ck", "nfi2x_sel", 5),
+	GATE_PERI1(CLK_PERI_NFI_PAD, "nfi_pad_ck", "nfi_sel", 4),
+	GATE_PERI1(CLK_PERI_NFI_ECC, "nfi_ecc_ck", "nfi_sel", 3),
+	GATE_PERI1(CLK_PERI_GCPU, "gcpu_ck", "axi_sel", 2),
+	GATE_PERI1(CLK_PERI_USB_SLV, "usbslv_ck", "axi_sel", 1),
+	GATE_PERI1(CLK_PERI_USB1_MCU, "usb1_mcu_ck", "axi_sel", 0),
+};
+
+static const char * const uart_ck_sel_parents[] __initconst = {
+	"clk26m",
+	"uart_sel",
+};
+
+static const struct mtk_composite peri_muxs[] __initconst = {
+	MUX(CLK_PERI_UART0_SEL, "uart0_ck_sel", uart_ck_sel_parents, 0x40c, 0, 1),
+	MUX(CLK_PERI_UART1_SEL, "uart1_ck_sel", uart_ck_sel_parents, 0x40c, 1, 1),
+	MUX(CLK_PERI_UART2_SEL, "uart2_ck_sel", uart_ck_sel_parents, 0x40c, 2, 1),
+	MUX(CLK_PERI_UART3_SEL, "uart3_ck_sel", uart_ck_sel_parents, 0x40c, 3, 1),
+};
+
+static void __init mtk_pericfg_init(struct device_node *node)
+{
+	struct clk_onecell_data *clk_data;
+	void __iomem *base;
+	int r;
+
+	base = of_iomap(node, 0);
+	if (!base) {
+		pr_err("%s(): ioremap failed\n", __func__);
+		return;
+	}
+
+	clk_data = mtk_alloc_clk_data(CLK_PERI_NR);
+
+	mtk_clk_register_gates(node, peri_clks, ARRAY_SIZE(peri_clks),
+						clk_data);
+
+	mtk_clk_register_composites(peri_muxs, ARRAY_SIZE(peri_muxs), base,
+			&lock, clk_data);
+
+	r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+	if (r)
+		pr_err("%s(): could not register clock provider: %d\n",
+			__func__, r);
+}
+CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt2701-pericfg", mtk_pericfg_init);
+
+static const struct mtk_gate_regs disp0_cg_regs __initconst = {
+	.set_ofs = 0x0104,
+	.clr_ofs = 0x0108,
+	.sta_ofs = 0x0100,
+};
+
+static const struct mtk_gate_regs disp1_cg_regs __initconst = {
+	.set_ofs = 0x0114,
+	.clr_ofs = 0x0118,
+	.sta_ofs = 0x0110,
+};
+
+#define GATE_DISP0(_id, _name, _parent, _shift) {	\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &disp0_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_setclr,	\
+	}
+
+#define GATE_DISP1(_id, _name, _parent, _shift) {	\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &disp1_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_setclr,	\
+	}
+
+static const struct mtk_gate mm_clks[] __initconst = {
+	GATE_DISP0(CLK_MM_SMI_COMMON, "mm_smi_comm", "mm_sel", 0),
+	GATE_DISP0(CLK_MM_SMI_LARB0, "mm_smi_larb0", "mm_sel", 1),
+	GATE_DISP0(CLK_MM_CMDQ, "mm_cmdq", "mm_sel", 2),
+	GATE_DISP0(CLK_MM_MUTEX, "mm_mutex", "mm_sel", 3),
+	GATE_DISP0(CLK_MM_DISP_COLOR, "mm_disp_color", "mm_sel", 4),
+	GATE_DISP0(CLK_MM_DISP_BLS, "mm_disp_bls", "mm_sel", 5),
+	GATE_DISP0(CLK_MM_DISP_WDMA, "mm_disp_wdma", "mm_sel", 6),
+	GATE_DISP0(CLK_MM_DISP_RDMA, "mm_disp_rdma", "mm_sel", 7),
+	GATE_DISP0(CLK_MM_DISP_OVL, "mm_disp_ovl", "mm_sel", 8),
+	GATE_DISP0(CLK_MM_MDP_TDSHP, "mm_mdp_tdshp", "mm_sel", 9),
+	GATE_DISP0(CLK_MM_MDP_WROT, "mm_mdp_wrot", "mm_sel", 10),
+	GATE_DISP0(CLK_MM_MDP_WDMA, "mm_mdp_wdma", "mm_sel", 11),
+	GATE_DISP0(CLK_MM_MDP_RSZ1, "mm_mdp_rsz1", "mm_sel", 12),
+	GATE_DISP0(CLK_MM_MDP_RSZ0, "mm_mdp_rsz0", "mm_sel", 13),
+	GATE_DISP0(CLK_MM_MDP_RDMA, "mm_mdp_rdma", "mm_sel", 14),
+	GATE_DISP0(CLK_MM_MDP_BLS_26M, "mm_mdp_bls_26m", "pwm_sel", 15),
+	GATE_DISP0(CLK_MM_CAM_MDP, "mm_cam_mdp", "mm_sel", 16),
+	GATE_DISP0(CLK_MM_FAKE_ENG, "mm_fake_eng", "mm_sel", 17),
+	GATE_DISP0(CLK_MM_MUTEX_32K, "mm_mutex_32k", "rtc_sel", 18),
+	GATE_DISP0(CLK_MM_DISP_RDMA1, "mm_disp_rdma1", "mm_sel", 19),
+	GATE_DISP0(CLK_MM_DISP_UFOE, "mm_disp_ufoe", "mm_sel", 20),
+	GATE_DISP1(CLK_MM_DSI_ENGINE, "mm_dsi_eng", "mm_sel", 0),
+	GATE_DISP1(CLK_MM_DSI_DIG, "mm_dsi_dig", "dsio_lntc_dsiclk", 1),
+	GATE_DISP1(CLK_MM_DPI_DIGL, "mm_dpi_digl", "dpi0_sel", 2),
+	GATE_DISP1(CLK_MM_DPI_ENGINE, "mm_dpi_eng", "mm_sel", 3),
+	GATE_DISP1(CLK_MM_DPI1_DIGL, "mm_dpi1_digl", "dpi1_sel", 4),
+	GATE_DISP1(CLK_MM_DPI1_ENGINE, "mm_dpi1_eng", "mm_sel", 5),
+	GATE_DISP1(CLK_MM_TVE_OUTPUT, "mm_tve_output", "tve_sel", 6),
+	GATE_DISP1(CLK_MM_TVE_INPUT, "mm_tve_input", "dpi0_sel", 7),
+	GATE_DISP1(CLK_MM_HDMI_PIXEL, "mm_hdmi_pixel", "dpi1_sel", 8),
+	GATE_DISP1(CLK_MM_HDMI_PLL, "mm_hdmi_pll", "hdmi_sel", 9),
+	GATE_DISP1(CLK_MM_HDMI_AUDIO, "mm_hdmi_audio", "apll_sel", 10),
+	GATE_DISP1(CLK_MM_HDMI_SPDIF, "mm_hdmi_spdif", "apll_sel", 11),
+	GATE_DISP1(CLK_MM_TVE_FMM, "mm_tve_fmm", "mm_sel", 14),
+};
+
+static void __init mtk_mmsys_init(struct device_node *node)
+{
+	struct clk_onecell_data *clk_data;
+	int r;
+
+	clk_data = mtk_alloc_clk_data(CLK_MM_NR);
+
+	mtk_clk_register_gates(node, mm_clks, ARRAY_SIZE(mm_clks),
+						clk_data);
+
+	r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+	if (r)
+		pr_err("%s(): could not register clock provider: %d\n",
+			__func__, r);
+}
+CLK_OF_DECLARE(mtk_mmsys, "mediatek,mt2701-mmsys", mtk_mmsys_init);
+
+static const struct mtk_gate_regs img_cg_regs __initconst = {
+	.set_ofs = 0x0004,
+	.clr_ofs = 0x0008,
+	.sta_ofs = 0x0000,
+};
+
+#define GATE_IMG(_id, _name, _parent, _shift) {		\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &img_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_setclr,	\
+	}
+
+static const struct mtk_gate img_clks[] __initconst = {
+	GATE_IMG(CLK_IMG_SMI_COMM, "img_smi_comm", "mm_sel", 0),
+	GATE_IMG(CLK_IMG_RESZ, "img_resz", "mm_sel", 1),
+	GATE_IMG(CLK_IMG_JPGDEC_SMI, "img_jpgdec_smi", "mm_sel", 5),
+	GATE_IMG(CLK_IMG_JPGDEC, "img_jpgdec", "mm_sel", 6),
+	GATE_IMG(CLK_IMG_VENC_LT, "img_venc_lt", "mm_sel", 8),
+	GATE_IMG(CLK_IMG_VENC, "img_venc", "mm_sel", 9),
+};
+
+static void __init mtk_imgsys_init(struct device_node *node)
+{
+	struct clk_onecell_data *clk_data;
+	int r;
+
+	clk_data = mtk_alloc_clk_data(CLK_IMG_NR);
+
+	mtk_clk_register_gates(node, img_clks, ARRAY_SIZE(img_clks),
+						clk_data);
+
+	r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+	if (r)
+		pr_err("%s(): could not register clock provider: %d\n",
+			__func__, r);
+}
+CLK_OF_DECLARE(mtk_imgsys, "mediatek,mt2701-imgsys", mtk_imgsys_init);
+
+static const struct mtk_gate_regs vdec0_cg_regs __initconst = {
+	.set_ofs = 0x0000,
+	.clr_ofs = 0x0004,
+	.sta_ofs = 0x0000,
+};
+
+static const struct mtk_gate_regs vdec1_cg_regs __initconst = {
+	.set_ofs = 0x0008,
+	.clr_ofs = 0x000c,
+	.sta_ofs = 0x0008,
+};
+
+#define GATE_VDEC0(_id, _name, _parent, _shift) {	\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &vdec0_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_setclr_inv,	\
+	}
+
+#define GATE_VDEC1(_id, _name, _parent, _shift) {	\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &vdec1_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_setclr_inv,	\
+	}
+
+static const struct mtk_gate vdec_clks[] __initconst = {
+	GATE_VDEC0(CLK_VDEC_CKGEN, "vdec_cken", "vdec_sel", 0),
+	GATE_VDEC1(CLK_VDEC_LARB, "vdec_larb_cken", "mm_sel", 0),
+};
+
+static void __init mtk_vdecsys_init(struct device_node *node)
+{
+	struct clk_onecell_data *clk_data;
+	int r;
+
+	clk_data = mtk_alloc_clk_data(CLK_VDEC_NR);
+
+	mtk_clk_register_gates(node, vdec_clks, ARRAY_SIZE(vdec_clks),
+						clk_data);
+
+	r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+	if (r)
+		pr_err("%s(): could not register clock provider: %d\n",
+			__func__, r);
+}
+CLK_OF_DECLARE(mtk_vdecsys, "mediatek,mt2701-vdecsys", mtk_vdecsys_init);
+
+static const struct mtk_gate_regs hif_cg_regs __initconst = {
+	.sta_ofs = 0x0008,
+};
+
+#define GATE_HIF(_id, _name, _parent, _shift) {		\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &hif_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,	\
+	}
+
+static const struct mtk_gate hif_clks[] __initconst = {
+	GATE_HIF(CLK_HIFSYS_USB0PHY, "usb0_phy_clk", "ethpll_500m_ck", 21),
+	GATE_HIF(CLK_HIFSYS_USB1PHY, "usb1_phy_clk", "ethpll_500m_ck", 22),
+	GATE_HIF(CLK_HIFSYS_PCIE0, "pcie0_clk", "ethpll_500m_ck", 24),
+	GATE_HIF(CLK_HIFSYS_PCIE1, "pcie1_clk", "ethpll_500m_ck", 25),
+	GATE_HIF(CLK_HIFSYS_PCIE2, "pcie2_clk", "ethpll_500m_ck", 26),
+};
+
+static void __init mtk_hifsys_init(struct device_node *node)
+{
+	struct clk_onecell_data *clk_data;
+	int r;
+
+	clk_data = mtk_alloc_clk_data(CLK_HIFSYS_NR);
+
+	mtk_clk_register_gates(node, hif_clks, ARRAY_SIZE(hif_clks),
+						clk_data);
+
+	r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+	if (r)
+		pr_err("%s(): could not register clock provider: %d\n",
+			__func__, r);
+}
+CLK_OF_DECLARE(mtk_hifsys, "mediatek,mt2701-hifsys", mtk_hifsys_init);
+
+static const struct mtk_gate_regs eth_cg_regs __initconst = {
+	.sta_ofs = 0x0030,
+};
+
+#define GATE_ETH(_id, _name, _parent, _shift) {		\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &eth_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_no_setclr_inv,	\
+	}
+
+static const struct mtk_gate eth_clks[] __initconst = {
+	GATE_ETH(CLK_ETHSYS_HSDMA, "hsdma_clk", "ethif_sel", 5),
+	GATE_ETH(CLK_ETHSYS_ESW, "esw_clk", "ethpll_500m_ck", 6),
+	GATE_ETH(CLK_ETHSYS_GP2, "gp2_clk", "trgpll", 7),
+	GATE_ETH(CLK_ETHSYS_GP1, "gp1_clk", "ethpll_500m_ck", 8),
+	GATE_ETH(CLK_ETHSYS_PCM, "pcm_clk", "ethif_sel", 11),
+	GATE_ETH(CLK_ETHSYS_GDMA, "gdma_clk", "ethif_sel", 14),
+	GATE_ETH(CLK_ETHSYS_I2S, "i2s_clk", "ethif_sel", 17),
+	GATE_ETH(CLK_ETHSYS_CRYPTO, "crypto_clk", "ethif_sel", 29),
+};
+
+static void __init mtk_ethsys_init(struct device_node *node)
+{
+	struct clk_onecell_data *clk_data;
+	int r;
+
+	clk_data = mtk_alloc_clk_data(CLK_ETHSYS_NR);
+
+	mtk_clk_register_gates(node, eth_clks, ARRAY_SIZE(eth_clks),
+						clk_data);
+
+	r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+	if (r)
+		pr_err("%s(): could not register clock provider: %d\n",
+			__func__, r);
+}
+CLK_OF_DECLARE(mtk_ethsys, "mediatek,mt2701-ethsys", mtk_ethsys_init);
+
+static const struct mtk_gate_regs bdp0_cg_regs __initconst = {
+	.set_ofs = 0x0104,
+	.clr_ofs = 0x0108,
+	.sta_ofs = 0x0100,
+};
+
+static const struct mtk_gate_regs bdp1_cg_regs __initconst = {
+	.set_ofs = 0x0114,
+	.clr_ofs = 0x0118,
+	.sta_ofs = 0x0110,
+};
+
+#define GATE_BDP0(_id, _name, _parent, _shift) {	\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &bdp0_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_setclr_inv,	\
+	}
+
+#define GATE_BDP1(_id, _name, _parent, _shift) {	\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &bdp1_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_setclr_inv,	\
+	}
+
+static const struct mtk_gate bdp_clks[] __initconst = {
+	GATE_BDP0(CLK_BDP_BRG_BA, "brg_baclk", "mm_sel", 0),
+	GATE_BDP0(CLK_BDP_BRG_DRAM, "brg_dram", "mm_sel", 1),
+	GATE_BDP0(CLK_BDP_LARB_DRAM, "larb_dram", "mm_sel", 2),
+	GATE_BDP0(CLK_BDP_WR_VDI_PXL, "wr_vdi_pxl", "hdmi_0_deep340m", 3),
+	GATE_BDP0(CLK_BDP_WR_VDI_DRAM, "wr_vdi_dram", "mm_sel", 4),
+	GATE_BDP0(CLK_BDP_WR_B, "wr_bclk", "mm_sel", 5),
+	GATE_BDP0(CLK_BDP_DGI_IN, "dgi_in", "dpi1_sel", 6),
+	GATE_BDP0(CLK_BDP_DGI_OUT, "dgi_out", "dpi_sel", 7),
+	GATE_BDP0(CLK_BDP_FMT_MAST_27, "fmt_mast_27", "dpi1_sel", 8),
+	GATE_BDP0(CLK_BDP_FMT_B, "fmt_bclk", "mm_sel", 9),
+	GATE_BDP0(CLK_BDP_OSD_B, "osd_bclk", "mm_sel", 10),
+	GATE_BDP0(CLK_BDP_OSD_DRAM, "osd_dram", "mm_sel", 11),
+	GATE_BDP0(CLK_BDP_OSD_AGENT, "osd_agent", "osd_sel", 12),
+	GATE_BDP0(CLK_BDP_OSD_PXL, "osd_pxl", "dpi1_sel", 13),
+	GATE_BDP0(CLK_BDP_RLE_B, "rle_bclk", "mm_sel", 14),
+	GATE_BDP0(CLK_BDP_RLE_AGENT, "rle_agent", "mm_sel", 15),
+	GATE_BDP0(CLK_BDP_RLE_DRAM, "rle_dram", "mm_sel", 16),
+	GATE_BDP0(CLK_BDP_F27M, "f27m", "di_sel", 17),
+	GATE_BDP0(CLK_BDP_F27M_VDOUT, "f27m_vdout", "di_sel", 18),
+	GATE_BDP0(CLK_BDP_F27_74_74, "f27_74_74", "di_sel", 19),
+	GATE_BDP0(CLK_BDP_F2FS, "f2fs", "di_sel", 20),
+	GATE_BDP0(CLK_BDP_F2FS74_148, "f2fs74_148", "di_sel", 21),
+	GATE_BDP0(CLK_BDP_FB, "fbclk", "mm_sel", 22),
+	GATE_BDP0(CLK_BDP_VDO_DRAM, "vdo_dram", "mm_sel", 23),
+	GATE_BDP0(CLK_BDP_VDO_2FS, "vdo_2fs", "di_sel", 24),
+	GATE_BDP0(CLK_BDP_VDO_B, "vdo_bclk", "mm_sel", 25),
+	GATE_BDP0(CLK_BDP_WR_DI_PXL, "wr_di_pxl", "di_sel", 26),
+	GATE_BDP0(CLK_BDP_WR_DI_DRAM, "wr_di_dram", "mm_sel", 27),
+	GATE_BDP0(CLK_BDP_WR_DI_B, "wr_di_bclk", "mm_sel", 28),
+	GATE_BDP0(CLK_BDP_NR_PXL, "nr_pxl", "nr_sel", 29),
+	GATE_BDP0(CLK_BDP_NR_DRAM, "nr_dram", "mm_sel", 30),
+	GATE_BDP0(CLK_BDP_NR_B, "nr_bclk", "mm_sel", 31),
+	GATE_BDP1(CLK_BDP_RX_F, "rx_fclk", "hadds2_fbclk", 0),
+	GATE_BDP1(CLK_BDP_RX_X, "rx_xclk", "clk26m", 1),
+	GATE_BDP1(CLK_BDP_RXPDT, "rxpdtclk", "hdmi_0_pix340m", 2),
+	GATE_BDP1(CLK_BDP_RX_CSCL_N, "rx_cscl_n", "clk26m", 3),
+	GATE_BDP1(CLK_BDP_RX_CSCL, "rx_cscl", "clk26m", 4),
+	GATE_BDP1(CLK_BDP_RX_DDCSCL_N, "rx_ddcscl_n", "hdmi_scl_rx", 5),
+	GATE_BDP1(CLK_BDP_RX_DDCSCL, "rx_ddcscl", "hdmi_scl_rx", 6),
+	GATE_BDP1(CLK_BDP_RX_VCO, "rx_vcoclk", "hadds2pll_294m", 7),
+	GATE_BDP1(CLK_BDP_RX_DP, "rx_dpclk", "hdmi_0_pll340m", 8),
+	GATE_BDP1(CLK_BDP_RX_P, "rx_pclk", "hdmi_0_pll340m", 9),
+	GATE_BDP1(CLK_BDP_RX_M, "rx_mclk", "hadds2pll_294m", 10),
+	GATE_BDP1(CLK_BDP_RX_PLL, "rx_pllclk", "hdmi_0_pix340m", 11),
+	GATE_BDP1(CLK_BDP_BRG_RT_B, "brg_rt_bclk", "mm_sel", 12),
+	GATE_BDP1(CLK_BDP_BRG_RT_DRAM, "brg_rt_dram", "mm_sel", 13),
+	GATE_BDP1(CLK_BDP_LARBRT_DRAM, "larbrt_dram", "mm_sel", 14),
+	GATE_BDP1(CLK_BDP_TMDS_SYN, "tmds_syn", "hdmi_0_pll340m", 15),
+	GATE_BDP1(CLK_BDP_HDMI_MON, "hdmi_mon", "hdmi_0_mon", 16),
+};
+
+static void __init mtk_bdpsys_init(struct device_node *node)
+{
+	struct clk_onecell_data *clk_data;
+	int r;
+
+	clk_data = mtk_alloc_clk_data(CLK_BDP_NR);
+
+	mtk_clk_register_gates(node, bdp_clks, ARRAY_SIZE(bdp_clks),
+						clk_data);
+
+	r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+	if (r)
+		pr_err("%s(): could not register clock provider: %d\n",
+			__func__, r);
+}
+CLK_OF_DECLARE(mtk_bdpsys, "mediatek,mt2701-bdpsys", mtk_bdpsys_init);
+
+#define MT8590_PLL_FMAX		(2000 * MHZ)
+#define CON0_MT8590_RST_BAR	BIT(27)
+
+#define PLL(_id, _name, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, _pd_reg, \
+			_pd_shift, _tuner_reg, _pcw_reg, _pcw_shift) {	\
+		.id = _id,						\
+		.name = _name,						\
+		.reg = _reg,						\
+		.pwr_reg = _pwr_reg,					\
+		.en_mask = _en_mask,					\
+		.flags = _flags,					\
+		.rst_bar_mask = CON0_MT8590_RST_BAR,			\
+		.fmax = MT8590_PLL_FMAX,				\
+		.pcwbits = _pcwbits,					\
+		.pd_reg = _pd_reg,					\
+		.pd_shift = _pd_shift,					\
+		.tuner_reg = _tuner_reg,				\
+		.pcw_reg = _pcw_reg,					\
+		.pcw_shift = _pcw_shift,				\
+	}
+
+static const struct mtk_pll_data apmixed_plls[] = {
+	PLL(CLK_APMIXED_ARMPLL, "armpll", 0x200, 0x20c, 0x80000001, 0,
+				21, 0x204, 24, 0x0, 0x204, 0),
+	PLL(CLK_APMIXED_MAINPLL, "mainpll", 0x210, 0x21c, 0xf0000001,
+		  HAVE_RST_BAR, 21, 0x210, 4, 0x0, 0x214, 0),
+	PLL(CLK_APMIXED_UNIVPLL, "univpll", 0x220, 0x22c, 0xf3000001,
+		  HAVE_RST_BAR, 7, 0x220, 4, 0x0, 0x224, 14),
+	PLL(CLK_APMIXED_MMPLL, "mmpll", 0x230, 0x23c, 0x00000001, 0,
+				21, 0x230, 4, 0x0, 0x234, 0),
+	PLL(CLK_APMIXED_MSDCPLL, "msdcpll", 0x240, 0x24c, 0x00000001, 0,
+				21, 0x240, 4, 0x0, 0x244, 0),
+	PLL(CLK_APMIXED_TVDPLL, "tvdpll", 0x250, 0x25c, 0x00000001, 0,
+				21, 0x250, 4, 0x0, 0x254, 0),
+	PLL(CLK_APMIXED_AUD1PLL, "aud1pll", 0x270, 0x27c, 0x00000001, 0,
+				31, 0x270, 4, 0x0, 0x274, 0),
+	PLL(CLK_APMIXED_TRGPLL, "trgpll", 0x280, 0x28c, 0x00000001, 0,
+				31, 0x280, 4, 0x0, 0x284, 0),
+	PLL(CLK_APMIXED_ETHPLL, "ethpll", 0x290, 0x29c, 0x00000001, 0,
+				31, 0x290, 4, 0x0, 0x294, 0),
+	PLL(CLK_APMIXED_VDECPLL, "vdecpll", 0x2a0, 0x2ac, 0x00000001, 0,
+				31, 0x2a0, 4, 0x0, 0x2a4, 0),
+	PLL(CLK_APMIXED_HADDS2PLL, "hadds2pll", 0x2b0, 0x2bc, 0x00000001, 0,
+				31, 0x2b0, 4, 0x0, 0x2b4, 0),
+	PLL(CLK_APMIXED_AUD2PLL, "aud2pll", 0x2c0, 0x2cc, 0x00000001, 0,
+				31, 0x2c0, 4, 0x0, 0x2c4, 0),
+	PLL(CLK_APMIXED_TVD2PLL, "tvd2pll", 0x2d0, 0x2dc, 0x00000001, 0,
+				21, 0x2d0, 4, 0x0, 0x2d4, 0),
+};
+
+static void __init mtk_apmixedsys_init(struct device_node *node)
+{
+	struct clk_onecell_data *clk_data;
+	int r;
+
+	clk_data = mtk_alloc_clk_data(ARRAY_SIZE(apmixed_plls));
+	if (!clk_data)
+		return;
+
+	mtk_clk_register_plls(node, apmixed_plls, ARRAY_SIZE(apmixed_plls),
+								clk_data);
+
+	r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+	if (r)
+		pr_err("%s(): could not register clock provider: %d\n",
+			__func__, r);
+}
+CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt2701-apmixedsys",
+							mtk_apmixedsys_init);
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index cf08db6..be19a41 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -242,3 +242,28 @@ void __init mtk_clk_register_composites(const struct mtk_composite *mcs,
 			clk_data->clks[mc->id] = clk;
 	}
 }
+
+void __init mtk_clk_register_dividers(const struct mtk_clk_divider *mcds,
+			int num, void __iomem *base, spinlock_t *lock,
+				struct clk_onecell_data *clk_data)
+{
+	struct clk *clk;
+	int i;
+
+	for (i = 0; i <  num; i++) {
+		const struct mtk_clk_divider *mcd = &mcds[i];
+
+		clk = clk_register_divider(NULL, mcd->name, mcd->parent_name,
+			mcd->flags, base +  mcd->div_reg, mcd->div_shift,
+			mcd->div_width, mcd->clk_divider_flags, lock);
+
+		if (IS_ERR(clk)) {
+			pr_err("Failed to register clk %s: %ld\n",
+				mcd->name, PTR_ERR(clk));
+			continue;
+		}
+
+		if (clk_data)
+			clk_data->clks[mcd->id] = clk;
+	}
+}
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 32d2e45..8796acc 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -110,7 +110,8 @@ struct mtk_composite {
 		.flags = CLK_SET_RATE_PARENT,				\
 	}
 
-#define DIV_GATE(_id, _name, _parent, _gate_reg, _gate_shift, _div_reg, _div_width, _div_shift) {	\
+#define DIV_GATE(_id, _name, _parent, _gate_reg, _gate_shift, _div_reg,	\
+					_div_width, _div_shift) {	\
 		.id = _id,						\
 		.parent = _parent,					\
 		.name = _name,						\
@@ -145,8 +146,35 @@ struct mtk_gate {
 	const struct clk_ops *ops;
 };
 
-int mtk_clk_register_gates(struct device_node *node, const struct mtk_gate *clks,
-		int num, struct clk_onecell_data *clk_data);
+int mtk_clk_register_gates(struct device_node *node,
+			const struct mtk_gate *clks, int num,
+			struct clk_onecell_data *clk_data);
+
+struct mtk_clk_divider {
+	int id;
+	const char *name;
+	const char *parent_name;
+	unsigned long flags;
+
+	uint32_t div_reg;
+	unsigned char div_shift;
+	unsigned char div_width;
+	unsigned char clk_divider_flags;
+	const struct clk_div_table *clk_div_table;
+};
+
+#define DIV_ADJ(_id, _name, _parent, _reg, _shift, _width) {	\
+		.id = _id,					\
+		.name = _name,					\
+		.parent_name = _parent,				\
+		.div_reg = _reg,				\
+		.div_shift = _shift,				\
+		.div_width = _width,				\
+}
+
+void mtk_clk_register_dividers(const struct mtk_clk_divider *mcds,
+			int num, void __iomem *base, spinlock_t *lock,
+				struct clk_onecell_data *clk_data);
 
 struct clk_onecell_data *mtk_alloc_clk_data(unsigned int clk_num);
 
-- 
1.9.1



From maxime.ripard at free-electrons.com  Fri Feb  5 01:39:15 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 5 Feb 2016 10:39:15 +0100
Subject: [PATCH v4 1/2] clk: sunxi: Add sun6i/8i video support
In-Reply-To: <3c0e2cdea659e9e682f80ecf42b252c740095f15.1454435944.git.moinejf@free.fr>
References: <cover.1454435944.git.moinejf@free.fr>
 <3c0e2cdea659e9e682f80ecf42b252c740095f15.1454435944.git.moinejf@free.fr>
Message-ID: <20160205093915.GF1139@lukather>

Hi,

On Tue, Feb 02, 2016 at 06:35:10PM +0100, Jean-Francois Moine wrote:
> Add the clock types which are used by the sun6i/8i families for video.
> 
> Signed-off-by: Jean-Francois Moine <moinejf at free.fr>
> ---
> v4:
> 	- drivers/clk/sunxi/Makefile was missing (Emil Velikov)
> v3: (no change)
> v2:
> 	- remarks from Chen-Yu Tsai
> 	- DT documentation added
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt |   2 +
>  drivers/clk/sunxi/Makefile                        |   2 +
>  drivers/clk/sunxi/clk-sun6i-display.c             | 106 +++++++++++++
>  drivers/clk/sunxi/clk-sun6i-pll3.c                | 174 ++++++++++++++++++++++
>  4 files changed, 284 insertions(+)
>  create mode 100644 drivers/clk/sunxi/clk-sun6i-display.c
>  create mode 100644 drivers/clk/sunxi/clk-sun6i-pll3.c
> 
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index e59f57b..a22b92f 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -11,6 +11,7 @@ Required properties:
>  	"allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
>  	"allwinner,sun8i-a23-pll1-clk" - for the main PLL clock on A23
>  	"allwinner,sun9i-a80-pll4-clk" - for the peripheral PLLs on A80
> +	"allwinner,sun6i-pll3-clk" - for the video PLLs clock

sun6i-a31

>  	"allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock
>  	"allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock
>  	"allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
> @@ -77,6 +78,7 @@ Required properties:
>  	"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
>  	"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
>  	"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
> +	"allwinner,sun6i-display-clk" - for the display clocks

Ditto

>  Required properties for all clocks:
>  - reg : shall be the control register address for the clock.
> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> index 3fd7901..6fe336f 100644
> --- a/drivers/clk/sunxi/Makefile
> +++ b/drivers/clk/sunxi/Makefile
> @@ -11,6 +11,8 @@ obj-y += clk-a10-ve.o
>  obj-y += clk-a20-gmac.o
>  obj-y += clk-mod0.o
>  obj-y += clk-simple-gates.o
> +obj-y += clk-sun6i-display.o
> +obj-y += clk-sun6i-pll3.o
>  obj-y += clk-sun8i-bus-gates.o
>  obj-y += clk-sun8i-mbus.o
>  obj-y += clk-sun9i-core.o
> diff --git a/drivers/clk/sunxi/clk-sun6i-display.c b/drivers/clk/sunxi/clk-sun6i-display.c
> new file mode 100644
> index 0000000..48356e3
> --- /dev/null
> +++ b/drivers/clk/sunxi/clk-sun6i-display.c
> @@ -0,0 +1,106 @@
> +/*
> + * Copyright 2016 Jean-Francois Moine <moinejf at free.fr>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/of_address.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +#include <linux/rational.h>
> +#include <linux/delay.h>
> +
> +static DEFINE_SPINLOCK(sun6i_display_lock);
> +
> +#define SUN6I_DISPLAY_GATE_BIT	31
> +#define SUN6I_DISPLAY_SEL_SHIFT	24
> +#define SUN6I_DISPLAY_SEL_MASK	GENMASK(2, 0)
> +#define SUN6I_DISPLAY_MSHIFT	0
> +#define SUN6I_DISPLAY_MWIDTH	4
> +
> +static void __init sun6i_display_setup(struct device_node *node)
> +{
> +	const char *clk_name = node->name;
> +	const char *parents[8];
> +	struct clk_mux *mux = NULL;
> +	struct clk_divider *div;
> +	struct clk_gate *gate;
> +	struct resource res;
> +	void __iomem *mmio;
> +	struct clk *clk;
> +	int n;
> +
> +	of_property_read_string(node, "clock-output-names", &clk_name);
> +
> +	mmio = of_io_request_and_map(node, 0, of_node_full_name(node));
> +	if (IS_ERR(mmio)) {
> +		pr_err("%s: Could not map the clock registers\n", clk_name);
> +		return;
> +	}
> +
> +	n = of_clk_parent_fill(node, parents, ARRAY_SIZE(parents));
> +
> +	if (n > 1) {				/* many possible sources */
> +		mux = kzalloc(sizeof(*mux), GFP_KERNEL);
> +		if (!mux)
> +			goto free_io;
> +		mux->reg = mmio;
> +		mux->shift = SUN6I_DISPLAY_SEL_SHIFT;
> +		mux->mask = SUN6I_DISPLAY_SEL_MASK;
> +		mux->lock = &sun6i_display_lock;
> +	}
> +
> +	gate = kzalloc(sizeof(*gate), GFP_KERNEL);
> +	if (!gate)
> +		goto free_mux;
> +
> +	gate->reg = mmio;
> +	gate->bit_idx = SUN6I_DISPLAY_GATE_BIT;
> +	gate->lock = &sun6i_display_lock;
> +
> +	div = kzalloc(sizeof(*div), GFP_KERNEL);
> +	if (!div)
> +		goto free_gate;
> +
> +	div->reg = mmio;
> +	div->shift = SUN6I_DISPLAY_MSHIFT;
> +	div->width = SUN6I_DISPLAY_MWIDTH;
> +	div->lock = &sun6i_display_lock;
> +
> +	clk = clk_register_composite(NULL, clk_name,
> +				     parents, n,
> +				     mux ? &mux->hw : NULL, &clk_mux_ops,
> +				     &div->hw, &clk_divider_ops,
> +				     &gate->hw, &clk_gate_ops,
> +				     0);
> +	if (IS_ERR(clk)) {
> +		pr_err("%s: Couldn't register the clock\n", clk_name);
> +		goto free_div;
> +	}
> +
> +	of_clk_add_provider(node, of_clk_src_simple_get, clk);
> +
> +	return;
> +
> +free_div:
> +	kfree(div);
> +free_gate:
> +	kfree(gate);
> +free_mux:
> +	kfree(mux);
> +free_io:
> +	iounmap(mmio);
> +	of_address_to_resource(node, 0, &res);
> +	release_mem_region(res.start, resource_size(&res));
> +}
> +
> +CLK_OF_DECLARE(sun6i_display, "allwinner,sun6i-display-clk", sun6i_display_setup);

Please use the display driver from my DRM serie, it covers everything
you need here.

> diff --git a/drivers/clk/sunxi/clk-sun6i-pll3.c b/drivers/clk/sunxi/clk-sun6i-pll3.c
> new file mode 100644
> index 0000000..3c128a4
> --- /dev/null
> +++ b/drivers/clk/sunxi/clk-sun6i-pll3.c
> @@ -0,0 +1,174 @@
> +/*
> + * Allwinner video PLL clocks
> + *
> + * Copyright 2016 Jean-Francois Moine <moinejf at free.fr>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/of_address.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +#include <linux/rational.h>
> +#include <linux/iopoll.h>
> +
> +static DEFINE_SPINLOCK(sun6i_pll3_lock);
> +
> +struct clk_fact {
> +	struct clk_hw hw;
> +	void __iomem *reg;
> +};
> +#define to_clk_fact(_hw) container_of(_hw, struct clk_fact, hw)
> +
> +#define SUN6I_PLL3_MSHIFT	0
> +#define SUN6I_PLL3_MMASK	GENMASK(3, 0)
> +#define SUN6I_PLL3_NSHIFT	8
> +#define SUN6I_PLL3_NMASK	GENMASK(7, 0)
> +#define SUN6I_PLL3_MODE_SEL	BIT(24)
> +#define SUN6I_PLL3_FRAC_CLK	BIT(25)
> +#define SUN6I_PLL3_LOCK_BIT	28
> +#define SUN6I_PLL3_GATE_BIT	31
> +
> +static u32 sun6i_pll3_get_fact(unsigned long rate,
> +			unsigned long parent_rate,
> +			unsigned long *n, unsigned long *m)
> +{
> +	if (rate == 297000000)
> +		return SUN6I_PLL3_FRAC_CLK;
> +	if (rate == 270000000)
> +		return 0;
> +	rational_best_approximation(rate, parent_rate,
> +				SUN6I_PLL3_NMASK + 1, SUN6I_PLL3_MMASK + 1,
> +				n, m);
> +	return SUN6I_PLL3_MODE_SEL;
> +}
> +
> +static unsigned long sun6i_pll3_recalc_rate(struct clk_hw *hw,
> +					unsigned long parent_rate)
> +{
> +	struct clk_fact *fact = to_clk_fact(hw);
> +	u32 reg;
> +	u32 n, m;
> +
> +	reg = readl(fact->reg);
> +	if (reg & SUN6I_PLL3_MODE_SEL) {
> +		n = (reg >> SUN6I_PLL3_NSHIFT) & SUN6I_PLL3_NMASK;
> +		m = (reg >> SUN6I_PLL3_MSHIFT) & SUN6I_PLL3_MMASK;
> +		return parent_rate / (m + 1) * (n + 1);
> +	}
> +	if (reg & SUN6I_PLL3_FRAC_CLK)
> +		return 297000000;
> +	return 270000000;
> +}
> +
> +static long sun6i_pll3_round_rate(struct clk_hw *hw, unsigned long rate,
> +				unsigned long *parent_rate)
> +{
> +	u32 frac;
> +	unsigned long n, m;
> +
> +	frac = sun6i_pll3_get_fact(rate, *parent_rate, &n, &m);
> +	if (frac & SUN6I_PLL3_MODE_SEL)
> +		return *parent_rate / m * n;
> +	if (frac & SUN6I_PLL3_FRAC_CLK)
> +		return 297000000;
> +	return 270000000;
> +}
> +
> +static int sun6i_pll3_set_rate(struct clk_hw *hw, unsigned long rate,
> +			unsigned long parent_rate)
> +{
> +	struct clk_fact *fact = to_clk_fact(hw);
> +	u32 reg;
> +	unsigned long n, m;
> +
> +	reg = readl(fact->reg) &
> +			~(SUN6I_PLL3_MODE_SEL |
> +			  SUN6I_PLL3_FRAC_CLK |
> +			  (SUN6I_PLL3_NMASK << SUN6I_PLL3_NSHIFT) |
> +			  (SUN6I_PLL3_MMASK << SUN6I_PLL3_MSHIFT));
> +
> +	reg |= sun6i_pll3_get_fact(rate, parent_rate, &n, &m);
> +	if (reg & SUN6I_PLL3_MODE_SEL)
> +		reg |= ((n - 1) << SUN6I_PLL3_NSHIFT) |
> +			((m - 1) << SUN6I_PLL3_MSHIFT);
> +
> +	writel(reg, fact->reg);
> +
> +	readl_poll_timeout(fact->reg, reg, reg & SUN6I_PLL3_LOCK_BIT, 10, 500);
> +
> +	return 0;
> +}
> +
> +static const struct clk_ops clk_sun6i_pll3_fact_ops = {
> +	.recalc_rate = sun6i_pll3_recalc_rate,
> +	.round_rate = sun6i_pll3_round_rate,
> +	.set_rate = sun6i_pll3_set_rate,
> +};
> +
> +static void __init sun6i_pll3_setup(struct device_node *node)
> +{
> +	const char *clk_name, *parent;
> +	void __iomem *mmio;
> +	struct clk_fact *fact;
> +	struct clk_gate *gate;
> +	struct resource res;
> +	struct clk *clk;
> +
> +	mmio = of_io_request_and_map(node, 0, of_node_full_name(node));
> +	if (IS_ERR(mmio)) {
> +		pr_err("%s: Could not map the clock registers\n", clk_name);
> +		return;
> +	}
> +
> +	gate = kzalloc(sizeof(*gate), GFP_KERNEL);
> +	if (!gate)
> +		goto free_mmio;
> +	gate->reg = mmio;
> +	gate->bit_idx = SUN6I_PLL3_GATE_BIT;
> +	gate->lock = &sun6i_pll3_lock;
> +
> +	fact = kzalloc(sizeof(*fact), GFP_KERNEL);
> +	if (!fact)
> +		goto free_gate;
> +	fact->reg = mmio;
> +
> +	parent = of_clk_get_parent_name(node, 0);
> +
> +	of_property_read_string(node, "clock-output-names", &clk_name);
> +
> +	clk = clk_register_composite(NULL, clk_name,
> +				     &parent, 1,
> +				     NULL, NULL,
> +				     &fact->hw, &clk_sun6i_pll3_fact_ops,
> +				     &gate->hw, &clk_gate_ops,
> +				     0);
> +	if (IS_ERR(clk)) {
> +		pr_err("%s: Couldn't register the clock\n", clk_name);
> +		goto free_fact;
> +	}
> +
> +	of_clk_add_provider(node, of_clk_src_simple_get, clk);
> +
> +	return;
> +
> +free_fact:
> +	kfree(fact);
> +free_gate:
> +	kfree(gate);
> +free_mmio:
> +	iounmap(mmio);
> +	of_address_to_resource(node, 0, &res);
> +	release_mem_region(res.start, resource_size(&res));
> +}
> +
> +CLK_OF_DECLARE(sun6i_pll3, "allwinner,sun6i-pll3-clk", sun6i_pll3_setup);

And please use the clk-factors code here.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160205/067edc6a/attachment.sig>

From wens at csie.org  Fri Feb  5 01:44:08 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 5 Feb 2016 17:44:08 +0800
Subject: [PATCH v3 3/5] pinctrl: sunxi: Add H3 R_PIO controller support
In-Reply-To: <1454542430-16572-4-git-send-email-k@japko.eu>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-4-git-send-email-k@japko.eu>
Message-ID: <CAGb2v66tGnL7QZyn+Jwjc2SQBMnBgpkChSbJyY--NBPd2_sSvQ@mail.gmail.com>

On Thu, Feb 4, 2016 at 7:33 AM, Krzysztof Adamski <k at japko.eu> wrote:
> H3 has additional PIO controller similar to what we can find on A23.
> It's a 12 pin port, described in H3 Datasheet rev 1.1, pages 345-350.
>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

Acked-by: Chen-Yu Tsai <wens at csie.org>

(resent as my mail setup failed to deliver)


From wens at csie.org  Fri Feb  5 01:45:12 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 5 Feb 2016 17:45:12 +0800
Subject: [PATCH v3 5/5] pinctrl: sunxi: Use pin number when calling
 sunxi_pmx_set
In-Reply-To: <1454542430-16572-6-git-send-email-k@japko.eu>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-6-git-send-email-k@japko.eu>
Message-ID: <CAGb2v67Wd_ZSJEdKm7b6dRzqAzGO3i61c1akVH+62xYnRF8Sfw@mail.gmail.com>

On Thu, Feb 4, 2016 at 7:33 AM, Krzysztof Adamski <k at japko.eu> wrote:
> sunxi_pmx_set accepts pin number and then calculates offset by
> subtracting pin_base from it. sunxi_pinctrl_gpio_get, on the other hand,
> gets offset so we have to convert it to pin number so we won't get
> negative value in sunxi_pmx_set.
>
> This was only used on A10 so far, where there is only one GPIO chip with
> pin_base set to 0 so it didn't matter. However H3 also requires this
> workaround but have two pinmux sections, triggering problem for PL port.
>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

Acked-by: Chen-Yu Tsai <wens at csie.org>

(resent as my mail setup failed to deliver)


From lorenzo.pieralisi at arm.com  Fri Feb  5 01:47:40 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 5 Feb 2016 09:47:40 +0000
Subject: [PATCH v7 5/5] PCI: ACPI: Add a generic ACPI based host controller
In-Reply-To: <CAKc_7PXYtFt1MQE-UGO0O5vvQ+xFKa2b5=F8wXB=EN-JUJVzZw@mail.gmail.com>
References: <1454058340-7904-1-git-send-email-jchandra@broadcom.com>
 <1454058340-7904-6-git-send-email-jchandra@broadcom.com>
 <20160205001907.GJ7031@localhost>
 <CAKc_7PXYtFt1MQE-UGO0O5vvQ+xFKa2b5=F8wXB=EN-JUJVzZw@mail.gmail.com>
Message-ID: <20160205094740.GA31547@red-moon>

On Fri, Feb 05, 2016 at 02:05:37PM +0530, Jayachandran Chandrashekaran Nair wrote:

[...]

> pci_host_acpi.c is a generic implementation of these using a sysdata
> pointing to acpi_pci_root_info, and using a pointer to the pci_mmcfg_region
> to access ECAM area, Maybe I can rename this file to
> pci_acpi_host_generic.c to reflect this better.

Maybe you should stop sending this series and work with Tomasz to
get this done, you are confusing everyone and I am really really
annoyed about this.

Do you realize there is no point in having two patch series doing
the same thing and wasting everyone's review time ?

Do you realize he started this work long before you and went through
several rounds of review already (I told you before but in case you
forgot) ?

Tomasz posted a version yesterday, integrating comments following months
of review and testing and I think it is ready to get upstream:

https://lkml.org/lkml/2016/2/4/646

Did you even consider reviewing his code or helping him instead of
churning out more patches doing the *SAME* thing ?

Do you want all of us to go through your code and re-fix what has
already been fixed in Tomasz's series with the end result of missing
yet another merge window ?

This is really annoying, stop it please, really.

Thank you,
Lorenzo


From maxime.ripard at free-electrons.com  Fri Feb  5 01:46:51 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 5 Feb 2016 10:46:51 +0100
Subject: [PATCH v3 3/5] pinctrl: sunxi: Add H3 R_PIO controller support
In-Reply-To: <1454542430-16572-4-git-send-email-k@japko.eu>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-4-git-send-email-k@japko.eu>
Message-ID: <20160205094651.GG1139@lukather>

On Thu, Feb 04, 2016 at 12:33:48AM +0100, Krzysztof Adamski wrote:
> H3 has additional PIO controller similar to what we can find on A23.
> It's a 12 pin port, described in H3 Datasheet rev 1.1, pages 345-350.
> 
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160205/31e319eb/attachment-0001.sig>

From wens at csie.org  Fri Feb  5 01:46:32 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 5 Feb 2016 17:46:32 +0800
Subject: [PATCH v3 4/5] ARM: dts: sun8i-h3: Add R_PIO controller node to
 the dtsi
In-Reply-To: <1454542430-16572-5-git-send-email-k@japko.eu>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-5-git-send-email-k@japko.eu>
Message-ID: <CAGb2v67ftGhjPHjHKQ0iYnOeRbi5qcqyT2P1gePW=UoMm5QRig@mail.gmail.com>

On Thu, Feb 4, 2016 at 7:33 AM, Krzysztof Adamski <k at japko.eu> wrote:
> Add the corresponding device node for R_PIO on H3 to the dtsi. Support
> for the controller was added in earlier commit.
>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index bb37f52..f618a95 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -517,5 +517,17 @@
>                         compatible = "allwinner,sun6i-a31-clock-reset";
>                         #reset-cells = <1>;
>                 };
> +
> +               r_pio: pinctrl at 01f02c00 {
> +                       compatible = "allwinner,sun8i-h3-r-pinctrl";
> +                       reg = <0x01f02c00 0x400>;
> +                       interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
> +                       clocks = <&apb0_gates 0>;
> +                       resets = <&apb0_reset 0>;
> +                       gpio-controller;
> +                       #gpio-cells = <3>;
> +                       interrupt-controller;
> +                       #interrupt-cells = <2>;

This should be 3: bank number + pin number + flags.
The rest looks good.

(resent as my mail setup failed to deliver)

> +               };
>         };
>  };
> --
> 2.1.4
>


From wens at csie.org  Fri Feb  5 01:49:45 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 5 Feb 2016 17:49:45 +0800
Subject: [PATCH v2 10/26] ARM: sun5i: a13: Add display and TCON clocks
In-Reply-To: <20160203203120.GF3327@lukather>
References: <1452785109-6172-1-git-send-email-maxime.ripard@free-electrons.com>
 <1452785109-6172-11-git-send-email-maxime.ripard@free-electrons.com>
 <CAGb2v67fqMUQsG-+zVxfgE3UzY7uyomBkwxgNHeXbqA1pwM8pA@mail.gmail.com>
 <20160203203120.GF3327@lukather>
Message-ID: <CAGb2v64QJJ07_ej5Jk8zY=i33yxtJebuF0S0-SwnQDmG0P5jMA@mail.gmail.com>

On Thu, Feb 4, 2016 at 4:31 AM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> Hi,
>
> On Sun, Jan 17, 2016 at 01:06:07AM +0800, Chen-Yu Tsai wrote:
>> > +                       compatible = "allwinner,sun4i-a10-tcon-ch0-clk";
>> > +                       reg = <0x01c20118 0x4>;
>> > +                       clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
>> > +                       clock-output-names = "tcon-ch0-sclk";
>> > +               };
>> > +
>> > +               tcon_ch1_clk: clk at 01c2012c {
>> > +                       #clock-cells = <0>;
>> > +                       compatible = "allwinner,sun4i-a10-tcon-ch1-clk";
>> > +                       reg = <0x01c2012c 0x4>;
>> > +                       clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
>> > +                       clock-output-names = "tcon-ch1-sclk";
>> > +               };
>>
>> I suggest moving these to sun5i.dtsi, as they are shared amongst them.
>
> Eventually, yes, but I don't have an a10s board handy, and I couldn't
> test the clocks that needs to be taken by simplefb.
>
> Once properly tested, they can definitely be moved to sun5i.dtsi.

Acked-by: Chen-Yu Tsai <wens at csie.org>


From fu.wei at linaro.org  Fri Feb  5 01:51:52 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Fri, 5 Feb 2016 17:51:52 +0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <56B2DEE4.7060901@roeck-us.net>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
 <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
 <56B2DEE4.7060901@roeck-us.net>
Message-ID: <CADyBb7unAHEOMfruWS82RkHK6uwPAWCxUx9jqzSkiHU4LHDSeA@mail.gmail.com>

Hi Guenter,

On 4 February 2016 at 13:17, Guenter Roeck <linux at roeck-us.net> wrote:
> On 02/03/2016 03:00 PM, Fu Wei wrote:
>>
>> On 4 February 2016 at 02:45, Timur Tabi <timur at codeaurora.org> wrote:
>>>
>>> Fu Wei wrote:
>>>>
>>>>
>>>> As you know I have made the pre-timeout support patch, If people like
>>>> it, i am happy to go on upstream it separately.
>>>>
>>>> If we want to use pre-timeout here, user only can use get_pretimeout
>>>> and disable panic by setting pretimeout to 0
>>>> but user can not really set pretimeout, because "pre-timeout  ==
>>>> timeout / 2 (always)".
>>>> if user want to change pretimeout, he/she has to set_time instead.
>>>
>>>
>>>
>>> Ok, I think patches 4 and 5 should be combined, and I think the Kconfig
>>> entry should be removed and just use panic_enabled.
>
>
> Agreed.

np, will do

>>
>>
>> NP, will update this patchset like that ,  thanks :-)
>>
>
> Also, if panic is enabled, the timeout needs to be adjusted accordingly
> (to only panic after the entire timeout period has expired, not after
> half of it). We can not panic the system after timeout / 2.

OK, my thought is

if panic is enabled :
|--------WOR-------WS0--------WOR-------WS1
|------timeout------(panic)------timeout-----reset

if panic is disabled .
|--------WOR-------WS0--------WOR-------WS1
|---------------------timeout---------------------reset

 panic_enabled only can be configured when module is loaded by module parameter

But user should know that max_timeout(panic_enable) =
max_timeout(panic_disable) / 2

>
> I am not too happy with the parameter name (panic_enabled). How about
> "action", to match machzwd ?

yes, makes sense. Maybe we can do something  like this:

/*
 * action refers to action taken when watchdog gets WS0
 * 0 = SKIP
 * 1 = PANIC
 * defaults to SKIP (0)
 */
static int action;
module_param(action, int, 0);
MODULE_PARM_DESC(action, "after watchdog gets WS0 interrupt, do: "
"0 = SKIP(*)  1 = PANIC");


>
> Thanks,
> Guenter
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From horms at verge.net.au  Fri Feb  5 01:54:45 2016
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Feb 2016 10:54:45 +0100
Subject: [PATCH v2] arm64: dts: r8a7795: pmu: switch to Cortex specific
 device nodes
In-Reply-To: <56B236F4.4090409@gmail.com>
References: <1452953636-4995-1-git-send-email-dirk.behme@gmail.com>
 <56B236F4.4090409@gmail.com>
Message-ID: <20160205095445.GD16556@verge.net.au>

[CC shiny new linux-renesas-soc ML]

On Wed, Feb 03, 2016 at 06:20:52PM +0100, Dirk Behme wrote:
> On 16.01.2016 15:13, Dirk Behme wrote:
> >Instead of using the generic armv8-pmuv3 compatibility use the more
> >specific Cortex A57 compatibility.
> >
> >Signed-off-by: Dirk Behme <dirk.behme at gmail.com>
> >---
> >Changes in v2: Drop the not yet merged Cortex A53 part.
> >
> >  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> >diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> >index 266c5de..a82bce8 100644
> >--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> >+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> >@@ -247,8 +247,8 @@
> >  			power-domains = <&cpg>;
> >  		};
> >
> >-		pmu {
> >-			compatible = "arm,armv8-pmuv3";
> >+		pmu_a57 {
> >+			compatible = "arm,cortex-a57-pmu";
> >  			interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
> >  				     <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
> >  				     <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
> >
> 
> 
> Any further comments to this? If not, could this be applied?

Hi Dirk,

I apologise for loosing track of this one.

Does this change work? I saw some discussion about using arm,cortex-a57-pmu
not working correctly on the r8a7795 in an earlier thread.


From horms at verge.net.au  Fri Feb  5 01:57:59 2016
From: horms at verge.net.au (Simon Horman)
Date: Fri, 5 Feb 2016 10:57:59 +0100
Subject: [PATCH v2] arm64: dts: r8a7795: Add L2 cache-controller nodes
In-Reply-To: <56B2370D.2010102@gmail.com>
References: <1452953856-5146-1-git-send-email-dirk.behme@gmail.com>
 <56B2370D.2010102@gmail.com>
Message-ID: <20160205095758.GE16556@verge.net.au>

[CC new linux-renesas-soc ML]

Hi Dirk,

On Wed, Feb 03, 2016 at 06:21:17PM +0100, Dirk Behme wrote:
> On 16.01.2016 15:17, Dirk Behme wrote:
> >From: Geert Uytterhoeven <geert+renesas at glider.be>
> >
> >Add device nodes for the L2 caches, and link the CPU node to its L2
> >cache node.
> >
> >The L2 cache for the Cortex-A57 CPU cores is 2 MiB large (organized as
> >128 KiB x 16 ways).
> >
> >Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> >Signed-off-by: Dirk Behme <dirk.behme at gmail.com>

[snip]

> Any further comments to this? If not, could this be applied?

Sorry for the delay.

This looks good; I have queued it up.

It should appear in the next (and devel) branches of my renesas tree soon.
And in linux-next whenever it includes my updated next branch.


From festevam at gmail.com  Fri Feb  5 02:00:42 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 5 Feb 2016 08:00:42 -0200
Subject: SGTL5000 misc
In-Reply-To: <CAEuupium67HD-sz+ViPx8-L4S0TsS-C8ZrX3po382r=E-9QYgw@mail.gmail.com>
References: <CAEuupiuhPR48Upo=8f0zV8cxf0Vefgx3qA+vC+QDWAOV4n-e3Q@mail.gmail.com>
 <CAOMZO5BPNc1ncz6J8yhcBYywCVuTxKYMYhiNUt_Jq3LZsKdi+A@mail.gmail.com>
 <CAEuupiszxAj7JkJu-5ozqgEnTWkz9FQEpxN8dmEN+KtaV-76ww@mail.gmail.com>
 <CAOMZO5DhrzdVyTVPB3FNquV4rDQ8a0MQrsJMosVsUQN63hj1Ww@mail.gmail.com>
 <CAEuupiuoB7nMSc8Fbyort1rJd=ZhYc0zfJNkd=ckUYk1qd8Z7Q@mail.gmail.com>
 <CAOMZO5C4QUHnJr=pisnYWCYZ0zUt+7HO846aPQui0zcLyX0N-Q@mail.gmail.com>
 <CAEuupivdftoopCOX3f7KRbV9poKdjdD3s9hfcbgB2TYjHmrjvw@mail.gmail.com>
 <CAEuupit8pVdnehkZkZPmq1QBHaS0sUG4NFuVFX37dKHn18j7DQ@mail.gmail.com>
 <CAOMZO5BxFRzi3qJAK=xDGger_MK9GZhuM00ugo836PHK_zJKjQ@mail.gmail.com>
 <CAEuupium67HD-sz+ViPx8-L4S0TsS-C8ZrX3po382r=E-9QYgw@mail.gmail.com>
Message-ID: <CAOMZO5Dos2xidZWrGffHRw33GjcJi+CvitFC5hKW3Hy0++GEmg@mail.gmail.com>

On Fri, Feb 5, 2016 at 1:08 AM, Erik Friesen <friesendrywall at gmail.com> wrote:
> There is another issue here, but when I have this connected to
> external power, it won't start the card on every other boot.
>
> With the code below, it seems to start every time.  If I don't skip,
> it dies on #8, which is the write of 0x7060 to CHIP_ANA_POWER
>
> This embeddedarm board supposedly power cycles the regulators, don't
> know if that is a factor or not.  The board finishes powerup 0x4060,
> but comes back on reboot at the reset value of 0x7060

It would be nice if you could send a patch to alsa-devel mailing list,
so that this can be properly reviewed there.


From dirk.behme at de.bosch.com  Fri Feb  5 02:03:36 2016
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Fri, 5 Feb 2016 11:03:36 +0100
Subject: [PATCH v2] arm64: dts: r8a7795: pmu: switch to Cortex specific
 device nodes
In-Reply-To: <20160205095445.GD16556@verge.net.au>
References: <1452953636-4995-1-git-send-email-dirk.behme@gmail.com>
 <56B236F4.4090409@gmail.com> <20160205095445.GD16556@verge.net.au>
Message-ID: <56B47378.3080209@de.bosch.com>

On 05.02.2016 10:54, Simon Horman wrote:
> [CC shiny new linux-renesas-soc ML]


Yes, thanks. I've to learn and remember this, too :)


> On Wed, Feb 03, 2016 at 06:20:52PM +0100, Dirk Behme wrote:
>> On 16.01.2016 15:13, Dirk Behme wrote:
>>> Instead of using the generic armv8-pmuv3 compatibility use the more
>>> specific Cortex A57 compatibility.
>>>
>>> Signed-off-by: Dirk Behme <dirk.behme at gmail.com>
>>> ---
>>> Changes in v2: Drop the not yet merged Cortex A53 part.
>>>
>>>   arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>> index 266c5de..a82bce8 100644
>>> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>> @@ -247,8 +247,8 @@
>>>   			power-domains = <&cpg>;
>>>   		};
>>>
>>> -		pmu {
>>> -			compatible = "arm,armv8-pmuv3";
>>> +		pmu_a57 {
>>> +			compatible = "arm,cortex-a57-pmu";
>>>   			interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
>>>   				     <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
>>>   				     <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
>>>
>>
>>
>> Any further comments to this? If not, could this be applied?
>
> Hi Dirk,
>
> I apologise for loosing track of this one.
>
> Does this change work? I saw some discussion about using arm,cortex-a57-pmu
> not working correctly on the r8a7795 in an earlier thread.

Yes, the A57 PMU probe is successful.

What's not working with the latest Renesas BSP is the A53, because these 
cores are disabled in the firmware coming with that BSP. But that's not 
a PMU issue, it's just because the cores are disabled. Using an older 
BSP firmware enabling all cores makes the A53 PMU probe fine, too.

Best regards

Dirk


From andre.przywara at arm.com  Fri Feb  5 02:04:01 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Fri, 5 Feb 2016 10:04:01 +0000
Subject: [PATCH 11/11] arm64: dts: add Pine64 support
In-Reply-To: <20160205090337.GB1139@lukather>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-12-git-send-email-andre.przywara@arm.com>
 <20160205090337.GB1139@lukather>
Message-ID: <56B47391.1040709@arm.com>

Hi,

On 05/02/16 09:03, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Feb 01, 2016 at 05:39:30PM +0000, Andre Przywara wrote:
>> The Pine64 is a cost-efficient development board based on the
>> Allwinner A64 SoC.
>> There are three models: the basic version with Fast Ethernet and
>> 512 MB of DRAM (Pine64) and two Pine64+ versions, which both
>> feature Gigabit Ethernet and additional connectors for touchscreens
>> and a camera. Or as my son put it: "Those are smaller and these are
>> missing." ;-)
>> The two Pine64+ models just differ in the amount of DRAM
>> (1GB vs. 2GB). Since U-Boot will figure out the right size for us and
>> patches the DT accordingly we just need to provide one DT for the
>> Pine64+.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>> ---
>>  .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>>  arch/arm64/boot/dts/Makefile                       |  1 +
>>  arch/arm64/boot/dts/allwinner/Makefile             |  5 ++
>>  arch/arm64/boot/dts/allwinner/pine64.dts           | 58 +++++++++++++++++
>>  arch/arm64/boot/dts/allwinner/pine64_common.dtsi   | 76 ++++++++++++++++++++++
>>  arch/arm64/boot/dts/allwinner/pine64_plus.dts      | 59 +++++++++++++++++
>>  6 files changed, 200 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
>>  create mode 100644 arch/arm64/boot/dts/allwinner/pine64.dts
>>  create mode 100644 arch/arm64/boot/dts/allwinner/pine64_common.dtsi
>>  create mode 100644 arch/arm64/boot/dts/allwinner/pine64_plus.dts
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 72e2c5a..0c22fa9 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -175,6 +175,7 @@ parade	Parade Technologies Inc.
>>  pericom	Pericom Technology Inc.
>>  phytec	PHYTEC Messtechnik GmbH
>>  picochip	Picochip Ltd
>> +pine64	Pine64
>>  plathome	Plat'Home Co., Ltd.
>>  plda	PLDA
>>  pixcir  PIXCIR MICROELECTRONICS Co., Ltd
> 
> Please make a separate patch for this one.
> 
>> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
>> index f832b8a..3b7428a 100644
>> --- a/arch/arm64/boot/dts/Makefile
>> +++ b/arch/arm64/boot/dts/Makefile
>> @@ -1,3 +1,4 @@
>> +dts-dirs += allwinner
> 
> Could you also add a patch to add this path to MAINTAINERS too?
> 
>>  dts-dirs += altera
>>  dts-dirs += amd
>>  dts-dirs += apm
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
>> new file mode 100644
>> index 0000000..65f4e24
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -0,0 +1,5 @@
>> +dtb-$(CONFIG_ARCH_SUNXI) += pine64_plus.dtb pine64.dtb
>> +
>> +always		:= $(dtb-y)
>> +subdir-y	:= $(dts-dirs)
>> +clean-files	:= *.dtb
>> diff --git a/arch/arm64/boot/dts/allwinner/pine64.dts b/arch/arm64/boot/dts/allwinner/pine64.dts
>> new file mode 100644
>> index 0000000..ebea5dd
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/pine64.dts
>> @@ -0,0 +1,58 @@
>> +/*
>> + * Copyright (c) 2016 ARM Ltd.
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This library is free software; you can redistribute it and/or
>> + *     modify it under the terms of the GNU General Public License as
>> + *     published by the Free Software Foundation; either version 2 of the
>> + *     License, or (at your option) any later version.
>> + *
>> + *     This library is distributed in the hope that it will be useful,
>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *     GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + *     obtaining a copy of this software and associated documentation
>> + *     files (the "Software"), to deal in the Software without
>> + *     restriction, including without limitation the rights to use,
>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>> + *     sell copies of the Software, and to permit persons to whom the
>> + *     Software is furnished to do so, subject to the following
>> + *     conditions:
>> + *
>> + *     The above copyright notice and this permission notice shall be
>> + *     included in all copies or substantial portions of the Software.
>> + *
>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + *     OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "pine64_common.dtsi"
>> +
>> +/ {
>> +	model = "Pine64";
>> +	compatible = "pine64,pine64", "allwinner,a64", "allwinner,sunxi";
>> +
>> +	chosen {
>> +		stdout-path = "serial0:115200n8";
>> +	};
>> +
>> +	memory {
>> +		reg = <0x40000000 0x20000000>;
>> +	};
>> +};
>> diff --git a/arch/arm64/boot/dts/allwinner/pine64_common.dtsi b/arch/arm64/boot/dts/allwinner/pine64_common.dtsi
>> new file mode 100644
>> index 0000000..d968d76
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/pine64_common.dtsi
>> @@ -0,0 +1,76 @@
>> +/*
>> + * Copyright (c) 2016 ARM Ltd.
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This library is free software; you can redistribute it and/or
>> + *     modify it under the terms of the GNU General Public License as
>> + *     published by the Free Software Foundation; either version 2 of the
>> + *     License, or (at your option) any later version.
>> + *
>> + *     This library is distributed in the hope that it will be useful,
>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *     GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + *     obtaining a copy of this software and associated documentation
>> + *     files (the "Software"), to deal in the Software without
>> + *     restriction, including without limitation the rights to use,
>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>> + *     sell copies of the Software, and to permit persons to whom the
>> + *     Software is furnished to do so, subject to the following
>> + *     conditions:
>> + *
>> + *     The above copyright notice and this permission notice shall be
>> + *     included in all copies or substantial portions of the Software.
>> + *
>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + *     OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +#include "a64.dtsi"
>> +
>> +&mmc0 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&mmc0_pins>, <&mmc0_default_cd_pin>;
>> +	vmmc-supply = <&reg_vcc3v3>;
>> +	cd-gpios = <&pio 5 6 0>;
>> +	cd-inverted;
>> +	status = "okay";
>> +};
>> +
>> +&uart0 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart0_pins_a>;
>> +	status = "okay";
>> +};
>> +
>> +&uart2 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart2_pins>;
>> +	status = "okay";
>> +};
>> +
>> +&uart3 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart3_pins_a>;
>> +	status = "okay";
>> +};
>> +
>> +&uart4 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart4_pins>;
>> +	status = "okay";
>> +};
> 
> Our policy for boards with "open" pin headers the user can plug
> anything he wants is that unless the pin is explicitly dedicated to
> that usage, we simply leave them aside so that we don't enforce
> anything.

Makes sense, I just wonder what a user is expected to do if she wants to
use the serial ports?
Hack the DT?
Use U-Boot to create those nodes on the fly?
Use overlays?
Directly setup serial ports from userland? (thinking of this bloody
mechanism x86 (used to?) have)

Anyway, thanks for the comments, all make sense and I will fix them.

Cheers,
Andre.

> From the quick look at the schematics, I guess only the UART0 on the
> 10-pin expansion header is elligible.
> 
>> diff --git a/arch/arm64/boot/dts/allwinner/pine64_plus.dts b/arch/arm64/boot/dts/allwinner/pine64_plus.dts
>> new file mode 100644
>> index 0000000..344752e
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/pine64_plus.dts
>> @@ -0,0 +1,59 @@
>> +/*
>> + * Copyright (c) 2016 ARM Ltd.
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This library is free software; you can redistribute it and/or
>> + *     modify it under the terms of the GNU General Public License as
>> + *     published by the Free Software Foundation; either version 2 of the
>> + *     License, or (at your option) any later version.
>> + *
>> + *     This library is distributed in the hope that it will be useful,
>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *     GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + *     obtaining a copy of this software and associated documentation
>> + *     files (the "Software"), to deal in the Software without
>> + *     restriction, including without limitation the rights to use,
>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>> + *     sell copies of the Software, and to permit persons to whom the
>> + *     Software is furnished to do so, subject to the following
>> + *     conditions:
>> + *
>> + *     The above copyright notice and this permission notice shall be
>> + *     included in all copies or substantial portions of the Software.
>> + *
>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + *     OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "pine64_common.dtsi"
>> +
>> +/ {
>> +	model = "Pine64+";
>> +	compatible = "pine64,pine64_plus", "allwinner,a64", "allwinner,sunxi";
> 
> The usual separator in the compatibles is a dash and not an underscore.
> 
> Thanks!
> Maxime
> 


From codekipper at gmail.com  Fri Feb  5 02:23:48 2016
From: codekipper at gmail.com (Code Kipper)
Date: Fri, 5 Feb 2016 11:23:48 +0100
Subject: [PATCH v4 2/2] ASoC: sunxi: Add support for the SPDIF block
In-Reply-To: <20160205092739.GE1139@lukather>
References: <1454584162-32449-1-git-send-email-codekipper@gmail.com>
 <1454584162-32449-3-git-send-email-codekipper@gmail.com>
 <20160205092739.GE1139@lukather>
Message-ID: <CAEKpxBkNY4zHwv6s4POtT8B+-b7tROWzvys3L+AzG25RGLQM=g@mail.gmail.com>

On 5 February 2016 at 10:27, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> Hi,
>
> On Thu, Feb 04, 2016 at 12:09:22PM +0100, codekipper at gmail.com wrote:
>> From: Marcus Cooper <codekipper at gmail.com>
>>
>> The sun4i, sun5i and sun7i SoC families have an SPDIF
>> block which is capable of playback and capture.
>>
>> This patch enables the playback of this block for
>> the sun4i families.
>>
>> Signed-off-by: Marcus Cooper <codekipper at gmail.com>
>> ---
>>  sound/soc/sunxi/Kconfig       |   8 +
>>  sound/soc/sunxi/Makefile      |   1 +
>>  sound/soc/sunxi/sun4i-spdif.c | 561 ++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 570 insertions(+)
>>  create mode 100644 sound/soc/sunxi/sun4i-spdif.c
>>
>> diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
>> index 84c72ec..6af7224 100644
>> --- a/sound/soc/sunxi/Kconfig
>> +++ b/sound/soc/sunxi/Kconfig
>> @@ -8,4 +8,12 @@ config SND_SUN4I_CODEC
>>         Select Y or M to add support for the Codec embedded in the Allwinner
>>         A10 and affiliated SoCs.
>>
>> +config SND_SUN4I_SPDIF
>> +        tristate "Allwinner A10 SPDIF Support"
>> +     depends on OF
>
> The indentation looks off.
ACK
>
>> +        select SND_SOC_GENERIC_DMAENGINE_PCM
>> +        select REGMAP_MMIO
>> +        help
>> +          Say Y or M to add support for the S/PDIF audio block in the Allwinner
>> +       A10 and affiliated SoCs.
>
> Here as well.
ACK
>
>>  endmenu
>> diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
>> index ea8a08c..8f5e889 100644
>> --- a/sound/soc/sunxi/Makefile
>> +++ b/sound/soc/sunxi/Makefile
>> @@ -1,2 +1,3 @@
>>  obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
>>
>> +obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o
>> diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
>> new file mode 100644
>> index 0000000..bb32344
>> --- /dev/null
>> +++ b/sound/soc/sunxi/sun4i-spdif.c
>> @@ -0,0 +1,561 @@
>> +/*
>> + * ALSA SoC SPDIF Audio Layer
>> + *
>> + * Copyright 2015 Andrea Venturi <be17068 at iperbole.bo.it>
>> + * Copyright 2015 Marcus Cooper <codekipper at gmail.com>
>> + *
>> + * Based on the Allwinner SDK driver, released under the GPL.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/device.h>
>> +#include <linux/kernel.h>
>> +#include <linux/init.h>
>> +#include <linux/regmap.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_device.h>
>> +#include <linux/ioport.h>
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pm_runtime.h>
>> +#include <sound/dmaengine_pcm.h>
>> +#include <sound/pcm_params.h>
>> +#include <sound/soc.h>
>> +
>> +#define      SUN4I_SPDIF_CTL         (0x00)
>> +     #define SUN4I_SPDIF_CTL_MCLKDIV(v)              ((v) << 4) /* v even */
>> +     #define SUN4I_SPDIF_CTL_MCLKOUTEN               BIT(2)
>> +     #define SUN4I_SPDIF_CTL_GEN                     BIT(1)
>> +     #define SUN4I_SPDIF_CTL_RESET                   BIT(0)
>> +
>> +#define SUN4I_SPDIF_TXCFG    (0x04)
>> +     #define SUN4I_SPDIF_TXCFG_SINGLEMOD             BIT(31)
>> +     #define SUN4I_SPDIF_TXCFG_ASS                   BIT(17)
>> +     #define SUN4I_SPDIF_TXCFG_NONAUDIO              BIT(16)
>> +     #define SUN4I_SPDIF_TXCFG_TXRATIO(v)            ((v) << 4)
>> +     #define SUN4I_SPDIF_TXCFG_TXRATIO_MASK          GENMASK(8, 4)
>> +     #define SUN4I_SPDIF_TXCFG_FMTRVD                GENMASK(3, 2)
>> +     #define SUN4I_SPDIF_TXCFG_FMT16BIT              (0 << 2)
>> +     #define SUN4I_SPDIF_TXCFG_FMT20BIT              (1 << 2)
>> +     #define SUN4I_SPDIF_TXCFG_FMT24BIT              (2 << 2)
>> +     #define SUN4I_SPDIF_TXCFG_CHSTMODE              BIT(1)
>> +     #define SUN4I_SPDIF_TXCFG_TXEN                  BIT(0)
>> +
>> +#define SUN4I_SPDIF_RXCFG    (0x08)
>> +     #define SUN4I_SPDIF_RXCFG_LOCKFLAG              BIT(4)
>> +     #define SUN4I_SPDIF_RXCFG_CHSTSRC               BIT(3)
>> +     #define SUN4I_SPDIF_RXCFG_CHSTCP                BIT(1)
>> +     #define SUN4I_SPDIF_RXCFG_RXEN                  BIT(0)
>> +
>> +#define SUN4I_SPDIF_TXFIFO   (0x0C)
>> +
>> +#define SUN4I_SPDIF_RXFIFO   (0x10)
>> +
>> +#define SUN4I_SPDIF_FCTL     (0x14)
>> +     #define SUN4I_SPDIF_FCTL_FIFOSRC                BIT(31)
>> +     #define SUN4I_SPDIF_FCTL_FTX                    BIT(17)
>> +     #define SUN4I_SPDIF_FCTL_FRX                    BIT(16)
>> +     #define SUN4I_SPDIF_FCTL_TXTL(v)                ((v) << 8)
>> +     #define SUN4I_SPDIF_FCTL_TXTL_MASK              GENMASK(12, 8)
>> +     #define SUN4I_SPDIF_FCTL_RXTL(v)                ((v) << 3)
>> +     #define SUN4I_SPDIF_FCTL_RXTL_MASK              GENMASK(7, 3)
>> +     #define SUN4I_SPDIF_FCTL_TXIM                   BIT(2)
>> +     #define SUN4I_SPDIF_FCTL_RXOM(v)                ((v) << 0)
>> +     #define SUN4I_SPDIF_FCTL_RXOM_MASK              GENMASK(1, 0)
>> +
>> +#define SUN4I_SPDIF_FSTA     (0x18)
>> +     #define SUN4I_SPDIF_FSTA_TXE                    BIT(14)
>> +     #define SUN4I_SPDIF_FSTA_TXECNTSHT              (8)
>> +     #define SUN4I_SPDIF_FSTA_RXA                    BIT(6)
>> +     #define SUN4I_SPDIF_FSTA_RXACNTSHT              (0)
>> +
>> +#define SUN4I_SPDIF_INT              (0x1C)
>> +     #define SUN4I_SPDIF_INT_RXLOCKEN                BIT(18)
>> +     #define SUN4I_SPDIF_INT_RXUNLOCKEN              BIT(17)
>> +     #define SUN4I_SPDIF_INT_RXPARERREN              BIT(16)
>> +     #define SUN4I_SPDIF_INT_TXDRQEN                 BIT(7)
>> +     #define SUN4I_SPDIF_INT_TXUIEN                  BIT(6)
>> +     #define SUN4I_SPDIF_INT_TXOIEN                  BIT(5)
>> +     #define SUN4I_SPDIF_INT_TXEIEN                  BIT(4)
>> +     #define SUN4I_SPDIF_INT_RXDRQEN                 BIT(2)
>> +     #define SUN4I_SPDIF_INT_RXOIEN                  BIT(1)
>> +     #define SUN4I_SPDIF_INT_RXAIEN                  BIT(0)
>> +
>> +#define SUN4I_SPDIF_ISTA     (0x20)
>> +     #define SUN4I_SPDIF_ISTA_RXLOCKSTA              BIT(18)
>> +     #define SUN4I_SPDIF_ISTA_RXUNLOCKSTA            BIT(17)
>> +     #define SUN4I_SPDIF_ISTA_RXPARERRSTA            BIT(16)
>> +     #define SUN4I_SPDIF_ISTA_TXUSTA                 BIT(6)
>> +     #define SUN4I_SPDIF_ISTA_TXOSTA                 BIT(5)
>> +     #define SUN4I_SPDIF_ISTA_TXESTA                 BIT(4)
>> +     #define SUN4I_SPDIF_ISTA_RXOSTA                 BIT(1)
>> +     #define SUN4I_SPDIF_ISTA_RXASTA                 BIT(0)
>> +
>> +#define SUN4I_SPDIF_TXCNT    (0x24)
>> +
>> +#define SUN4I_SPDIF_RXCNT    (0x28)
>> +
>> +#define SUN4I_SPDIF_TXCHSTA0 (0x2C)
>> +     #define SUN4I_SPDIF_TXCHSTA0_CLK(v)             ((v) << 28)
>> +     #define SUN4I_SPDIF_TXCHSTA0_SAMFREQ(v)         ((v) << 24)
>> +     #define SUN4I_SPDIF_TXCHSTA0_SAMFREQ_MASK       GENMASK(27, 24)
>> +     #define SUN4I_SPDIF_TXCHSTA0_CHNUM(v)           ((v) << 20)
>> +     #define SUN4I_SPDIF_TXCHSTA0_CHNUM_MASK         GENMASK(23, 20)
>> +     #define SUN4I_SPDIF_TXCHSTA0_SRCNUM(v)          ((v) << 16)
>> +     #define SUN4I_SPDIF_TXCHSTA0_CATACOD(v)         ((v) << 8)
>> +     #define SUN4I_SPDIF_TXCHSTA0_MODE(v)            ((v) << 6)
>> +     #define SUN4I_SPDIF_TXCHSTA0_EMPHASIS(v)        ((v) << 3)
>> +     #define SUN4I_SPDIF_TXCHSTA0_CP                 BIT(2)
>> +     #define SUN4I_SPDIF_TXCHSTA0_AUDIO              BIT(1)
>> +     #define SUN4I_SPDIF_TXCHSTA0_PRO                BIT(0)
>> +
>> +#define SUN4I_SPDIF_TXCHSTA1 (0x30)
>> +     #define SUN4I_SPDIF_TXCHSTA1_CGMSA(v)           ((v) << 8)
>> +     #define SUN4I_SPDIF_TXCHSTA1_ORISAMFREQ(v)      ((v) << 4)
>> +     #define SUN4I_SPDIF_TXCHSTA1_ORISAMFREQ_MASK    GENMASK(7, 4)
>> +     #define SUN4I_SPDIF_TXCHSTA1_SAMWORDLEN(v)      ((v) << 1)
>> +     #define SUN4I_SPDIF_TXCHSTA1_MAXWORDLEN         BIT(0)
>> +
>> +#define SUN4I_SPDIF_RXCHSTA0 (0x34)
>> +     #define SUN4I_SPDIF_RXCHSTA0_CLK(v)             ((v) << 28)
>> +     #define SUN4I_SPDIF_RXCHSTA0_SAMFREQ(v)         ((v) << 24)
>> +     #define SUN4I_SPDIF_RXCHSTA0_CHNUM(v)           ((v) << 20)
>> +     #define SUN4I_SPDIF_RXCHSTA0_SRCNUM(v)          ((v) << 16)
>> +     #define SUN4I_SPDIF_RXCHSTA0_CATACOD(v)         ((v) << 8)
>> +     #define SUN4I_SPDIF_RXCHSTA0_MODE(v)            ((v) << 6)
>> +     #define SUN4I_SPDIF_RXCHSTA0_EMPHASIS(v)        ((v) << 3)
>> +     #define SUN4I_SPDIF_RXCHSTA0_CP                 BIT(2)
>> +     #define SUN4I_SPDIF_RXCHSTA0_AUDIO              BIT(1)
>> +     #define SUN4I_SPDIF_RXCHSTA0_PRO                BIT(0)
>> +
>> +#define SUN4I_SPDIF_RXCHSTA1 (0x38)
>> +     #define SUN4I_SPDIF_RXCHSTA1_CGMSA(v)           ((v) << 8)
>> +     #define SUN4I_SPDIF_RXCHSTA1_ORISAMFREQ(v)      ((v) << 4)
>> +     #define SUN4I_SPDIF_RXCHSTA1_SAMWORDLEN(v)      ((v) << 1)
>> +     #define SUN4I_SPDIF_RXCHSTA1_MAXWORDLEN         BIT(0)
>> +
>> +/* Defines for Sampling Frequency */
>> +#define SUN4I_SPDIF_SAMFREQ_44_1KHZ          0x0
>> +#define SUN4I_SPDIF_SAMFREQ_NOT_INDICATED    0x1
>> +#define SUN4I_SPDIF_SAMFREQ_48KHZ            0x2
>> +#define SUN4I_SPDIF_SAMFREQ_32KHZ            0x3
>> +#define SUN4I_SPDIF_SAMFREQ_22_05KHZ         0x4
>> +#define SUN4I_SPDIF_SAMFREQ_24KHZ            0x6
>> +#define SUN4I_SPDIF_SAMFREQ_88_2KHZ          0x8
>> +#define SUN4I_SPDIF_SAMFREQ_76_8KHZ          0x9
>> +#define SUN4I_SPDIF_SAMFREQ_96KHZ            0xa
>> +#define SUN4I_SPDIF_SAMFREQ_176_4KHZ         0xc
>> +#define SUN4I_SPDIF_SAMFREQ_192KHZ           0xe
>> +
>> +/*
>> + * Original sampling frequency can be represented by inverting the value of the
>> + * sampling frequency.
>> + */
>> +#define ORIGINAL(v) ((~v) & 0xf)
>
> You're not using that macro anywhere.
Removed ACK
>
>> +
>> +struct sun4i_spdif_dev {
>> +     struct platform_device *pdev;
>> +     struct clk *spdif_clk;
>> +     struct clk *apb_clk;
>> +     struct snd_soc_dai_driver cpu_dai_drv;
>> +     struct regmap *regmap;
>> +     struct snd_dmaengine_dai_dma_data dma_params_tx;
>> +};
>> +
>> +static void sun4i_spdif_configure(struct sun4i_spdif_dev *host)
>> +{
>> +     /* soft reset SPDIF */
>> +     regmap_write(host->regmap, SUN4I_SPDIF_CTL, SUN4I_SPDIF_CTL_RESET);
>> +
>> +     /* flush TX FIFO */
>> +     regmap_update_bits(host->regmap, SUN4I_SPDIF_FCTL,
>> +                        SUN4I_SPDIF_FCTL_FTX, SUN4I_SPDIF_FCTL_FTX);
>> +
>> +     /* clear TX counter */
>> +     regmap_write(host->regmap, SUN4I_SPDIF_TXCNT, 0);
>> +}
>> +
>> +static void sun4i_snd_txctrl_on(struct snd_pcm_substream *substream,
>> +                             struct sun4i_spdif_dev *host)
>> +{
>> +     if (substream->runtime->channels == 1)
>> +             regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
>> +                                SUN4I_SPDIF_TXCFG_SINGLEMOD,
>> +                                SUN4I_SPDIF_TXCFG_SINGLEMOD);
>> +
>> +     /* SPDIF TX ENABLE */
>> +     regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
>> +                        SUN4I_SPDIF_TXCFG_TXEN, SUN4I_SPDIF_TXCFG_TXEN);
>> +
>> +     /* DRQ ENABLE */
>> +     regmap_update_bits(host->regmap, SUN4I_SPDIF_INT,
>> +                        SUN4I_SPDIF_INT_TXDRQEN, SUN4I_SPDIF_INT_TXDRQEN);
>> +
>> +     /* Global enable */
>> +     regmap_update_bits(host->regmap, SUN4I_SPDIF_CTL,
>> +                        SUN4I_SPDIF_CTL_GEN, SUN4I_SPDIF_CTL_GEN);
>> +}
>> +
>> +static void sun4i_snd_txctrl_off(struct snd_pcm_substream *substream,
>> +                              struct sun4i_spdif_dev *host)
>> +{
>> +     /* SPDIF TX DISABLE */
>> +     regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
>> +                        SUN4I_SPDIF_TXCFG_TXEN, 0);
>> +
>> +     /* DRQ DISABLE */
>> +     regmap_update_bits(host->regmap, SUN4I_SPDIF_INT,
>> +                        SUN4I_SPDIF_INT_TXDRQEN, 0);
>> +
>> +     /* Global disable */
>> +     regmap_update_bits(host->regmap, SUN4I_SPDIF_CTL,
>> +                        SUN4I_SPDIF_CTL_GEN, 0);
>> +}
>> +
>> +static int sun4i_spdif_startup(struct snd_pcm_substream *substream,
>> +                            struct snd_soc_dai *cpu_dai)
>> +{
>> +     struct snd_soc_pcm_runtime *rtd = substream->private_data;
>> +     struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(rtd->cpu_dai);
>> +
>> +     if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK)
>> +             return -EINVAL;
>> +
>> +     sun4i_spdif_configure(host);
>> +
>> +     return 0;
>> +}
>> +
>> +static int sun4i_spdif_hw_params(struct snd_pcm_substream *substream,
>> +                              struct snd_pcm_hw_params *params,
>> +                              struct snd_soc_dai *cpu_dai)
>> +{
>> +     int ret = 0;
>> +     int fmt;
>> +     unsigned long rate = params_rate(params);
>> +     u32 mclk_div = 0;
>> +     unsigned int mclk = 0;
>> +     u32 reg_val;
>> +     struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
>> +     struct platform_device *pdev = host->pdev;
>> +
>> +     /* Add the PCM and raw data select interface */
>> +     switch (params_channels(params)) {
>> +     case 1: /* PCM mode */
>> +     case 2:
>> +             fmt = 0;
>> +             break;
>> +     case 4: /* raw data mode */
>> +             fmt = SUN4I_SPDIF_TXCFG_NONAUDIO;
>> +             break;
>> +     default:
>> +             return -EINVAL;
>> +     }
>> +
>> +     switch (params_format(params)) {
>> +     case SNDRV_PCM_FORMAT_S16_LE:
>> +             fmt |= SUN4I_SPDIF_TXCFG_FMT16BIT;
>> +             break;
>> +     case SNDRV_PCM_FORMAT_S20_3LE:
>> +             fmt |= SUN4I_SPDIF_TXCFG_FMT20BIT;
>> +             break;
>> +     case SNDRV_PCM_FORMAT_S24_LE:
>> +             fmt |= SUN4I_SPDIF_TXCFG_FMT24BIT;
>> +             break;
>> +     default:
>> +             return -EINVAL;
>> +     }
>> +
>> +     switch (rate) {
>> +     case 22050:
>> +     case 44100:
>> +     case 88200:
>> +     case 176400:
>> +             mclk = 22579200;
>> +             break;
>> +     case 24000:
>> +     case 32000:
>> +     case 48000:
>> +     case 96000:
>> +     case 192000:
>> +             mclk = 24576000;
>> +             break;
>> +     default:
>> +             return -EINVAL;
>> +     }
>> +
>> +     ret = clk_set_rate(host->spdif_clk, mclk);
>> +     if (ret < 0) {
>> +             dev_err(&pdev->dev,
>> +                     "Setting SPDIF clock rate for %d Hz failed!\n", mclk);
>> +             return ret;
>> +     }
>> +
>> +     regmap_update_bits(host->regmap, SUN4I_SPDIF_FCTL,
>> +                        SUN4I_SPDIF_FCTL_TXIM, SUN4I_SPDIF_FCTL_TXIM);
>> +
>> +     switch (rate) {
>> +     case 22050:
>> +     case 24000:
>> +             mclk_div = 8;
>> +             break;
>> +     case 32000:
>> +             mclk_div = 6;
>> +             break;
>> +     case 44100:
>> +     case 48000:
>> +             mclk_div = 4;
>> +             break;
>> +     case 88200:
>> +     case 96000:
>> +             mclk_div = 2;
>> +             break;
>> +     case 176400:
>> +     case 192000:
>> +             mclk_div = 1;
>> +             break;
>> +     default:
>> +             return -EINVAL;
>> +     }
>> +
>> +     reg_val = 0;
>> +     reg_val |= SUN4I_SPDIF_TXCFG_ASS;
>> +     reg_val |= fmt; /* set non audio and bit depth */
>> +     reg_val |= SUN4I_SPDIF_TXCFG_CHSTMODE;
>> +     reg_val |= SUN4I_SPDIF_TXCFG_TXRATIO(mclk_div - 1);
>> +     regmap_write(host->regmap, SUN4I_SPDIF_TXCFG, reg_val);
>> +
>> +     return 0;
>> +}
>> +
>> +static int sun4i_spdif_trigger(struct snd_pcm_substream *substream, int cmd,
>> +                            struct snd_soc_dai *dai)
>> +{
>> +     int ret = 0;
>> +     struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(dai);
>> +
>> +     if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK)
>> +             return -EINVAL;
>> +
>> +     switch (cmd) {
>> +     case SNDRV_PCM_TRIGGER_START:
>> +     case SNDRV_PCM_TRIGGER_RESUME:
>> +     case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
>> +             sun4i_snd_txctrl_on(substream, host);
>> +             break;
>> +
>> +     case SNDRV_PCM_TRIGGER_STOP:
>> +     case SNDRV_PCM_TRIGGER_SUSPEND:
>> +     case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
>> +             sun4i_snd_txctrl_off(substream, host);
>> +             break;
>> +
>> +     default:
>> +             ret = -EINVAL;
>> +             break;
>> +     }
>> +     return ret;
>> +}
>> +
>> +static int sun4i_spdif_soc_dai_probe(struct snd_soc_dai *dai)
>> +{
>> +     struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(dai);
>> +
>> +     snd_soc_dai_init_dma_data(dai, &host->dma_params_tx, NULL);
>> +     return 0;
>> +}
>> +
>> +static const struct snd_soc_dai_ops sun4i_spdif_dai_ops = {
>> +     .startup        = sun4i_spdif_startup,
>> +     .trigger        = sun4i_spdif_trigger,
>> +     .hw_params      = sun4i_spdif_hw_params,
>> +};
>> +
>> +static const struct regmap_config sun4i_spdif_regmap_config = {
>> +     .reg_bits = 32,
>> +     .reg_stride = 4,
>> +     .val_bits = 32,
>> +     .max_register = SUN4I_SPDIF_RXCHSTA1,
>> +};
>> +
>> +#define SUN4I_RATES  SNDRV_PCM_RATE_8000_192000
>> +
>> +#define SUN4I_FORMATS        (SNDRV_PCM_FORMAT_S16_LE | \
>> +                             SNDRV_PCM_FORMAT_S20_3LE | \
>> +                             SNDRV_PCM_FORMAT_S24_LE)
>> +
>> +static struct snd_soc_dai_driver sun4i_spdif_dai = {
>> +     .playback = {
>> +             .channels_min = 1,
>> +             .channels_max = 2,
>> +             .rates = SUN4I_RATES,
>> +             .formats = SUN4I_FORMATS,
>> +     },
>> +     .probe = sun4i_spdif_soc_dai_probe,
>> +     .ops = &sun4i_spdif_dai_ops,
>> +     .name = "spdif",
>> +};
>> +
>> +static const struct snd_soc_dapm_widget dit_widgets[] = {
>> +     SND_SOC_DAPM_OUTPUT("spdif-out"),
>> +};
>> +
>> +static const struct snd_soc_dapm_route dit_routes[] = {
>> +     { "spdif-out", NULL, "Playback" },
>> +};
>> +
>> +static const struct of_device_id sun4i_spdif_of_match[] = {
>> +     { .compatible = "allwinner,sun4i-a10-spdif", },
>> +     { /* sentinel */ }
>> +};
>> +MODULE_DEVICE_TABLE(of, sun4i_spdif_of_match);
>> +
>> +static const struct snd_soc_component_driver sun4i_spdif_component = {
>> +     .name           = "sun4i-spdif",
>> +};
>> +
>> +static int sun4i_spdif_runtime_suspend(struct device *dev)
>> +{
>> +     struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
>> +
>> +     clk_disable_unprepare(host->spdif_clk);
>> +     clk_disable_unprepare(host->apb_clk);
>> +
>> +     return 0;
>> +}
>> +
>> +static int sun4i_spdif_runtime_resume(struct device *dev)
>> +{
>> +     struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
>> +
>> +     clk_prepare_enable(host->spdif_clk);
>> +     clk_prepare_enable(host->apb_clk);
>> +
>> +     return 0;
>> +}
>> +
>> +static int sun4i_spdif_probe(struct platform_device *pdev)
>> +{
>> +     struct sun4i_spdif_dev *host;
>> +     struct resource *res;
>> +     int ret;
>> +     void __iomem *base;
>> +
>> +     dev_dbg(&pdev->dev, "Entered %s\n", __func__);
>> +
>> +     host = devm_kzalloc(&pdev->dev, sizeof(*host), GFP_KERNEL);
>> +     if (!host)
>> +             return -ENOMEM;
>> +
>> +     host->pdev = pdev;
>> +
>> +     /* Initialize this copy of the CPU DAI driver structure */
>> +     memcpy(&host->cpu_dai_drv, &sun4i_spdif_dai, sizeof(sun4i_spdif_dai));
>> +     host->cpu_dai_drv.name = dev_name(&pdev->dev);
>> +
>> +     /* Get the addresses */
>> +     res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +     base = devm_ioremap_resource(&pdev->dev, res);
>> +     if (IS_ERR(base))
>> +             return PTR_ERR(base);
>> +
>> +     host->regmap = devm_regmap_init_mmio(&pdev->dev, base,
>> +                                             &sun4i_spdif_regmap_config);
>> +
>> +     /* Clocks */
>> +     host->apb_clk = devm_clk_get(&pdev->dev, "apb");
>> +     if (IS_ERR(host->apb_clk)) {
>> +             dev_err(&pdev->dev, "failed to get a apb clock.\n");
>> +             return PTR_ERR(host->apb_clk);
>> +     }
>> +
>> +     ret = clk_prepare_enable(host->apb_clk);
>> +     if (ret) {
>> +             dev_err(&pdev->dev, "try to enable apb_spdif_clk failed\n");
>> +             return ret;
>> +     }
>
> You don't need to enable it anymore.
Removed ACK
>
>> +
>> +     host->spdif_clk = devm_clk_get(&pdev->dev, "spdif");
>> +     if (IS_ERR(host->spdif_clk)) {
>> +             dev_err(&pdev->dev, "failed to get a spdif clock.\n");
>> +             goto err_disable_apb_clk;
>> +     }
>> +
>> +     host->dma_params_tx.addr = res->start + SUN4I_SPDIF_TXFIFO;
>> +     host->dma_params_tx.maxburst = 4;
>> +     host->dma_params_tx.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
>> +
>> +     platform_set_drvdata(pdev, host);
>> +
>> +     ret = devm_snd_soc_register_component(&pdev->dev,
>> +                             &sun4i_spdif_component, &sun4i_spdif_dai, 1);
>> +     if (ret)
>> +             goto err_disable_apb_clk;
>> +
>> +     pm_runtime_enable(&pdev->dev);
>> +     if (!pm_runtime_enabled(&pdev->dev)) {
>> +             ret = sun4i_spdif_runtime_resume(&pdev->dev);
>> +             if (ret)
>> +                     goto err_unregister;
>> +     }
>> +
>> +     ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
>> +     if (ret)
>> +             goto err_suspend;
>> +     return 0;
>> +err_suspend:
>> +     if (!pm_runtime_status_suspended(&pdev->dev))
>> +             sun4i_spdif_runtime_suspend(&pdev->dev);
>> +err_unregister:
>> +     pm_runtime_disable(&pdev->dev);
>> +     snd_soc_unregister_component(&pdev->dev);
>> +err_disable_apb_clk:
>> +     clk_disable_unprepare(host->apb_clk);
>> +     return ret;
>> +}
>> +
>> +static int sun4i_spdif_remove(struct platform_device *pdev)
>> +{
>> +     pm_runtime_disable(&pdev->dev);
>> +     if (!pm_runtime_status_suspended(&pdev->dev))
>> +             sun4i_spdif_runtime_suspend(&pdev->dev);
>> +
>> +     snd_soc_unregister_platform(&pdev->dev);
>> +     snd_soc_unregister_component(&pdev->dev);
>> +
>> +     return 0;
>> +}
>> +
>> +static const struct dev_pm_ops sun4i_spdif_pm = {
>> +     SET_RUNTIME_PM_OPS(sun4i_spdif_runtime_suspend,
>> +                        sun4i_spdif_runtime_resume, NULL)
>> +};
>> +
>> +static struct platform_driver sun4i_spdif_driver = {
>> +     .driver         = {
>> +             .name   = "sun4i-spdif",
>> +             .of_match_table = of_match_ptr(sun4i_spdif_of_match),
>> +             .pm     = &sun4i_spdif_pm,
>> +     },
>> +     .probe          = sun4i_spdif_probe,
>> +     .remove         = sun4i_spdif_remove,
>> +};
>> +
>> +module_platform_driver(sun4i_spdif_driver);
>> +
>> +MODULE_AUTHOR("Marcus Cooper <codekipper at gmail.com>");
>> +MODULE_AUTHOR("Andrea Venturi <be17068 at iperbole.bo.it>");
>> +MODULE_DESCRIPTION("Allwinner sun4i SPDIF SoC Interface");
>> +MODULE_LICENSE("GPL");
>> +MODULE_ALIAS("platform:sun4i-spdif");
>> --
>> 2.7.0
>>
>
> Thanks!
> Maxime
Thanks for the review...I'll leave it a day or so before sending v5.
BR,
CK
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com


From boris.brezillon at free-electrons.com  Fri Feb  5 02:29:07 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 5 Feb 2016 11:29:07 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <20160205090246.GE32272@lunn.ch>
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
 <20160205090246.GE32272@lunn.ch>
Message-ID: <20160205112907.796afb05@bbrezillon>

Jan, Andrew

On Fri, 5 Feb 2016 10:02:46 +0100
Andrew Lunn <andrew at lunn.ch> wrote:

> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
> > Hi,
> > 
> > I am testing marvell_cesa on a kirkwood device (QNAP TS-212p, Marvell
> > Kirkwood 88F6282, dts: http://pastebin.com/Gk95KFHf ).
> > As of kernel 4.4 (4.4.0-trunk-kirkwood #1 Debian 4.4-1~exp1) it fails
> > in the following way:
> > 
> > modprobe marvell_cesa allhwsupport=1
> > dmesg | tail -n 1
> > [ 1057.855091] marvell-cesa: probe of f1030000.crypto failed with error -12
> > 
> > or:
> > 
> > modprobe marvell_cesa
> > dmesg | tail -n 1
> > [ 9178.399357] marvell-cesa: probe of f1030000.crypto failed with error -524
> > 
> > With kernel 4.3 it would fail with error -22 on that hardware. There
> > are scattered reports from other users experiencing the same issue
> > (1,2,3)
> > 
> > I wonder if this is a result of an invalid definition of the
> > crypto-sram in the dts of this SoC, or perhaps some other problem
> > (PEBKAC included).
> 
> Hi Jan
> 
> Do you have SRAM enabled in your kernel configuration. The
> mvebu_v5_defconfig does not have it, which is a bug really.

Hm, the CRYPTO_DEV_MARVELL_CESA option selects the SRAM one [1].
Anyway, I also think this error is related to the SRAM (not sure why the
driver is not able to get the SRAM though).

Best Regards,

Boris

[1]http://lxr.free-electrons.com/source/drivers/crypto/Kconfig#L168


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


From ard.biesheuvel at linaro.org  Fri Feb  5 02:48:54 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 5 Feb 2016 11:48:54 +0100
Subject: [PATCH] PCI: generic: map config window in one go
In-Reply-To: <4090946.AhejVJy7MO@wuerfel>
References: <1454077035-23872-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160129142831.GF4541@arm.com>
 <CAKv+Gu_V83bUktPX0EiHd6qCDT2y0NEx=4n-uVv=P2MF9AZbMQ@mail.gmail.com>
 <4090946.AhejVJy7MO@wuerfel>
Message-ID: <CAKv+Gu8oZADs_FRN=p7_Nz0wXJVWVmzVNsxtzscyp7_cFAreAQ@mail.gmail.com>

On 29 January 2016 at 15:52, Arnd Bergmann <arnd at arndb.de> wrote:
> On Friday 29 January 2016 15:32:01 Ard Biesheuvel wrote:
>> On 29 January 2016 at 15:28, Will Deacon <will.deacon at arm.com> wrote:
>> > Hi Ard,
>> >
>> > On Fri, Jan 29, 2016 at 03:17:15PM +0100, Ard Biesheuvel wrote:
>> >> Instead of iterating over the PCI config window and performing individual
>> >> ioremap() calls on all the adjacent slices, perform a single ioremap() to
>> >> map the entire region, and divvy it up later. This not only prevents
>> >> leaving some of it mapped if we fail half way through, it also ensures that
>> >> archs that support huge-vmap can use section mappings to perform the
>> >> mapping.
>> >>
>> >> On my Seattle A0 box, this transforms 128 separate 1 MB mappings that are
>> >> mapped down to 4 KB pages into a single 128 MB mapping using 2 MB sections,
>> >> saving 512 KB worth of page tables.
>> >>
>> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> >> ---
>> >
>> > The code was written this way in response to feedback during driver review
>> > that we couldn't necessarily grab that much contiguous vmalloc space on
>> > 32-bit ARM. Unless that's changed, we probably want to to predicate this
>> > change on having a 64-bit arch.
>> >
>>
>> Ah right. How about testing for the ARCH_HAVE_HUGE_VMAP Kconfig symbol
>> explicitly?
>>
>
> Testing for 64BIT should be sufficient.
>

Does it make sense to spin a v2 for this patch? Given the discussion
we had regarding allocating only the config regions for busses that
are populated, perhaps there is a better approach here?


From maxime.ripard at free-electrons.com  Fri Feb  5 03:11:52 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 5 Feb 2016 12:11:52 +0100
Subject: [PATCH v3 1/5] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <20160204154752.4df7808be3364a98c496c030@free.fr>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-2-git-send-email-k@japko.eu>
 <20160204154752.4df7808be3364a98c496c030@free.fr>
Message-ID: <20160205111152.GA31506@lukather>

Hi,

On Thu, Feb 04, 2016 at 03:47:52PM +0100, Jean-Francois Moine wrote:
> On Thu,  4 Feb 2016 00:33:46 +0100
> Krzysztof Adamski <k at japko.eu> wrote:
> 
> > This patch adds support for APB0 in H3. It seems to be compatible with
> > earlier SOCs. apb0 gates controls R_ block peripherals (R_PIO, R_IR,
> > etc).
> > 
> > Signed-off-by: Krzysztof Adamski <k at japko.eu>
> > ---
> >  Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
> >  drivers/clk/sunxi/clk-simple-gates.c              | 2 ++
> >  2 files changed, 3 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> > index e59f57b..751c8b9f0 100644
> > --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> > +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> > @@ -45,6 +45,7 @@ Required properties:
> >  	"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
> >  	"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
> >  	"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
> > +	"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
> >  	"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
> >  	"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
> >  	"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
> > diff --git a/drivers/clk/sunxi/clk-simple-gates.c b/drivers/clk/sunxi/clk-simple-gates.c
> > index f4da52b..6753c87 100644
> > --- a/drivers/clk/sunxi/clk-simple-gates.c
> > +++ b/drivers/clk/sunxi/clk-simple-gates.c
> > @@ -130,6 +130,8 @@ CLK_OF_DECLARE(sun8i_a23_apb2, "allwinner,sun8i-a23-apb2-gates-clk",
> >  	       sunxi_simple_gates_init);
> >  CLK_OF_DECLARE(sun8i_a33_ahb1, "allwinner,sun8i-a33-ahb1-gates-clk",
> >  	       sunxi_simple_gates_init);
> > +CLK_OF_DECLARE(sun8i_h3_apb0, "allwinner,sun8i-h3-apb0-gates-clk",
> > +	       sunxi_simple_gates_init);
> >  CLK_OF_DECLARE(sun9i_a80_ahb0, "allwinner,sun9i-a80-ahb0-gates-clk",
> >  	       sunxi_simple_gates_init);
> >  CLK_OF_DECLARE(sun9i_a80_ahb1, "allwinner,sun9i-a80-ahb1-gates-clk",
> 
> It seems that the other compatible strings are there for historical
> reasons. Why do you need a new one with such a specific name?
> 
> It would have been more sensible to add a generic compatible string as
> "allwinner,apb-gates", letting the removal of the other strings for a
> later patch...

Yeah, it's a good idea, and it's probably time that we move to that.

However, I'd like to keep per-soc and per-clocks compatibles in the
DT, in case we need to protect a clock in the future. That doesn't
prevent to have two compatibles thoughe, the specific and the generic.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160205/accd1c27/attachment.sig>

From maxime.ripard at free-electrons.com  Fri Feb  5 03:14:08 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 5 Feb 2016 12:14:08 +0100
Subject: [PATCH v3 1/5] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <20160204205602.GC12071@box2.japko.eu>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-2-git-send-email-k@japko.eu>
 <20160204154752.4df7808be3364a98c496c030@free.fr>
 <20160204205602.GC12071@box2.japko.eu>
Message-ID: <20160205111408.GB31506@lukather>

Hi,

On Thu, Feb 04, 2016 at 09:56:02PM +0100, Krzysztof Adamski wrote:
> On Thu, Feb 04, 2016 at 03:47:52PM +0100, Jean-Francois Moine wrote:
> >On Thu,  4 Feb 2016 00:33:46 +0100
> >Krzysztof Adamski <k at japko.eu> wrote:
> >
> >>This patch adds support for APB0 in H3. It seems to be compatible with
> >>earlier SOCs. apb0 gates controls R_ block peripherals (R_PIO, R_IR,
> >>etc).
> >>
> >>Signed-off-by: Krzysztof Adamski <k at japko.eu>
> >>---
> >> Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
> >> drivers/clk/sunxi/clk-simple-gates.c              | 2 ++
> >> 2 files changed, 3 insertions(+)
> >>
> >>diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> >>index e59f57b..751c8b9f0 100644
> >>--- a/Documentation/devicetree/bindings/clock/sunxi.txt
> >>+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> >>@@ -45,6 +45,7 @@ Required properties:
> >> 	"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
> >> 	"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
> >> 	"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
> >>+	"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
> >> 	"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
> >> 	"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
> >> 	"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
> >>diff --git a/drivers/clk/sunxi/clk-simple-gates.c b/drivers/clk/sunxi/clk-simple-gates.c
> >>index f4da52b..6753c87 100644
> >>--- a/drivers/clk/sunxi/clk-simple-gates.c
> >>+++ b/drivers/clk/sunxi/clk-simple-gates.c
> >>@@ -130,6 +130,8 @@ CLK_OF_DECLARE(sun8i_a23_apb2, "allwinner,sun8i-a23-apb2-gates-clk",
> >> 	       sunxi_simple_gates_init);
> >> CLK_OF_DECLARE(sun8i_a33_ahb1, "allwinner,sun8i-a33-ahb1-gates-clk",
> >> 	       sunxi_simple_gates_init);
> >>+CLK_OF_DECLARE(sun8i_h3_apb0, "allwinner,sun8i-h3-apb0-gates-clk",
> >>+	       sunxi_simple_gates_init);
> >> CLK_OF_DECLARE(sun9i_a80_ahb0, "allwinner,sun9i-a80-ahb0-gates-clk",
> >> 	       sunxi_simple_gates_init);
> >> CLK_OF_DECLARE(sun9i_a80_ahb1, "allwinner,sun9i-a80-ahb1-gates-clk",
> >
> >It seems that the other compatible strings are there for historical
> >reasons. Why do you need a new one with such a specific name?
> >
> >It would have been more sensible to add a generic compatible string as
> >"allwinner,apb-gates", letting the removal of the other strings for a
> >later patch...
> 
> Seems like a good idea but is it possible to remove those binding in
> separate patch?

Yeah, you can (and should) do that as a separate patch, that can be
part of the next iteration of this set.

> I mean, wouldn't that, in theory, break ABI? Are such
> patches accepted?

It would, but it doesn't matter.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160205/b9fe039e/attachment.sig>

From maxime.ripard at free-electrons.com  Fri Feb  5 03:15:49 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 5 Feb 2016 12:15:49 +0100
Subject: [PATCH v3 5/5] pinctrl: sunxi: Use pin number when calling
 sunxi_pmx_set
In-Reply-To: <1454542430-16572-6-git-send-email-k@japko.eu>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-6-git-send-email-k@japko.eu>
Message-ID: <20160205111549.GC31506@lukather>

On Thu, Feb 04, 2016 at 12:33:50AM +0100, Krzysztof Adamski wrote:
> sunxi_pmx_set accepts pin number and then calculates offset by
> subtracting pin_base from it. sunxi_pinctrl_gpio_get, on the other hand,
> gets offset so we have to convert it to pin number so we won't get
> negative value in sunxi_pmx_set.
> 
> This was only used on A10 so far, where there is only one GPIO chip with
> pin_base set to 0 so it didn't matter. However H3 also requires this
> workaround but have two pinmux sections, triggering problem for PL port.
> 
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160205/c800d063/attachment.sig>

From k at japko.eu  Fri Feb  5 03:58:37 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Fri, 5 Feb 2016 12:58:37 +0100
Subject: [PATCH v3 1/5] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <20160205111152.GA31506@lukather>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-2-git-send-email-k@japko.eu>
 <20160204154752.4df7808be3364a98c496c030@free.fr>
 <20160205111152.GA31506@lukather>
Message-ID: <20160205115837.GD12071@box2.japko.eu>

On Fri, Feb 05, 2016 at 12:11:52PM +0100, Maxime Ripard wrote:
>Hi,
>
>On Thu, Feb 04, 2016 at 03:47:52PM +0100, Jean-Francois Moine wrote:
>> On Thu,  4 Feb 2016 00:33:46 +0100
>> Krzysztof Adamski <k at japko.eu> wrote:
>>
>> > This patch adds support for APB0 in H3. It seems to be compatible with
>> > earlier SOCs. apb0 gates controls R_ block peripherals (R_PIO, R_IR,
>> > etc).
>> >
>> > Signed-off-by: Krzysztof Adamski <k at japko.eu>
>> > ---
>> >  Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
>> >  drivers/clk/sunxi/clk-simple-gates.c              | 2 ++
>> >  2 files changed, 3 insertions(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
>> > index e59f57b..751c8b9f0 100644
>> > --- a/Documentation/devicetree/bindings/clock/sunxi.txt
>> > +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
>> > @@ -45,6 +45,7 @@ Required properties:
>> >  	"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
>> >  	"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
>> >  	"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
>> > +	"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
>> >  	"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
>> >  	"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
>> >  	"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
>> > diff --git a/drivers/clk/sunxi/clk-simple-gates.c b/drivers/clk/sunxi/clk-simple-gates.c
>> > index f4da52b..6753c87 100644
>> > --- a/drivers/clk/sunxi/clk-simple-gates.c
>> > +++ b/drivers/clk/sunxi/clk-simple-gates.c
>> > @@ -130,6 +130,8 @@ CLK_OF_DECLARE(sun8i_a23_apb2, "allwinner,sun8i-a23-apb2-gates-clk",
>> >  	       sunxi_simple_gates_init);
>> >  CLK_OF_DECLARE(sun8i_a33_ahb1, "allwinner,sun8i-a33-ahb1-gates-clk",
>> >  	       sunxi_simple_gates_init);
>> > +CLK_OF_DECLARE(sun8i_h3_apb0, "allwinner,sun8i-h3-apb0-gates-clk",
>> > +	       sunxi_simple_gates_init);
>> >  CLK_OF_DECLARE(sun9i_a80_ahb0, "allwinner,sun9i-a80-ahb0-gates-clk",
>> >  	       sunxi_simple_gates_init);
>> >  CLK_OF_DECLARE(sun9i_a80_ahb1, "allwinner,sun9i-a80-ahb1-gates-clk",
>>
>> It seems that the other compatible strings are there for historical
>> reasons. Why do you need a new one with such a specific name?
>>
>> It would have been more sensible to add a generic compatible string as
>> "allwinner,apb-gates", letting the removal of the other strings for a
>> later patch...
>
>Yeah, it's a good idea, and it's probably time that we move to that.
>
>However, I'd like to keep per-soc and per-clocks compatibles in the
>DT, in case we need to protect a clock in the future. That doesn't
>prevent to have two compatibles thoughe, the specific and the generic.
>

So now I'm not sure what you mean. You suggest that I should keep using 
specific (sun8i_h3_apb0) or change to generic (apb-gates) in my patch? 


From shameerali.kolothum.thodi at huawei.com  Fri Feb  5 04:04:02 2016
From: shameerali.kolothum.thodi at huawei.com (Shameerali Kolothum Thodi)
Date: Fri, 5 Feb 2016 12:04:02 +0000
Subject: [QUESTION ]ARM64 external L3 cache support in topology info
Message-ID: <5FC3163CFD30C246ABAA99954A238FA8172E13A4@lhreml504-mbs>

Hi,

This is a query to get the external L3 cache included in the cache
topology info. ARM64 kernel now has the cache topology info added
based on the patch here [1].

1. http://permalink.gmane.org/gmane.linux.ports.arm.kernel/383628

> 
> This patch adds support for cacheinfo on ARM64.
> 
> On ARMv8, the cache hierarchy can be identified through Cache Level ID
> (CLIDR) register while the cache geometry is provided by Cache Size ID
> (CCSIDR) register.
> 
> Since the architecture doesn't provide any way of detecting the cpus 
> sharing particular cache, device tree is used for the same purpose.

We have a ARM64 board(Hisilicon D02) and it has got an external L3 cache.
As per my understanding after talking to our SoC guys, this cache is not
integrated into the processor and is not visible in (CLIDR) register. 
But this looks to be fine as per the Programmer's Guide for ARMv8-A.

"The CLIDR register is only aware of how many levels of cache are 
integrated into the processor itself. It cannot provide information
about any caches in the external memory system. For example, if 
only L1 and L2 are integrated, CLIDR/CLIDR_EL1 identifies two levels
of cache and the processor is unaware of any external L3 cache. 
It might be necessary to take into account non-integrated caches
when performing cache maintenance, or code that is maintaining
coherency with integrated caches."

> Signed-off-by: Sudeep Holla <sudeep.holla <at> arm.com>
> Cc: Catalin Marinas <catalin.marinas <at> arm.com>
> Cc: Will Deacon <will.deacon <at> arm.com>
> Cc: Mark Rutland <mark.rutland <at> arm.com>
> Cc: linux-arm-kernel <at> lists.infradead.org
> ---
>  arch/arm64/include/asm/cachetype.h |  29 +++++++--
>  arch/arm64/kernel/Makefile         |   2 +-
>  arch/arm64/kernel/cacheinfo.c      | 128 
[....]

> +static int __populate_cache_leaves(unsigned int cpu)
> +{
> +    unsigned int level, idx;
> +    enum cache_type type;
> +    struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
> +    struct cacheinfo *this_leaf = this_cpu_ci->info_list;
> +
> +    for (idx = 0, level = 1; level <= this_cpu_ci->num_levels &&
> +         idx < this_cpu_ci->num_leaves; idx++, level++) {
> +        type = get_cache_type(level);
> +        if (type == CACHE_TYPE_SEPARATE) {
> +            ci_leaf_init(this_leaf++, CACHE_TYPE_DATA, level);
> +            ci_leaf_init(this_leaf++, CACHE_TYPE_INST, level);
> +        } else {
> +            ci_leaf_init(this_leaf++, type, level);
> +        }
> +    }
> +    return 0;
> +}
Here the cache leaves are populated on what CLIDR is reporting, and dts
entry is only used to find out the sharing info. Not sure purpose of
this patch is only to report the cache that is integrated to the processor.

In our case, the L3 cache seems to be intelligent enough and doesn't
require any additional maintenance ops. So there is no cache-controller
code for this. I am just wondering what's the best way to add this L3
cache info to the topology. Overriding the CLIDR register, if there is
a next-level-cache entry in the dts and then retrieve the cache geometry
either from dts or from cache specific registers( but this will be
implementation specific) ? Or am I missing something here? 

Thanks,
Shameer


From ard.biesheuvel at linaro.org  Fri Feb  5 04:05:19 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 5 Feb 2016 13:05:19 +0100
Subject: [PATCHv2 2/3] arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
In-Reply-To: <1454615017-24672-3-git-send-email-labbott@fedoraproject.org>
References: <1454615017-24672-1-git-send-email-labbott@fedoraproject.org>
 <1454615017-24672-3-git-send-email-labbott@fedoraproject.org>
Message-ID: <CAKv+Gu8sy4Uc6rQMcTW1qmy+z4RcFb78vERR-ZXk9-2B7t+Shg@mail.gmail.com>

Hi Laura,

On 4 February 2016 at 20:43, Laura Abbott <labbott at fedoraproject.org> wrote:
>
> ARCH_SUPPORTS_DEBUG_PAGEALLOC provides a hook to map and unmap
> pages for debugging purposes. This requires memory be mapped
> with PAGE_SIZE mappings since breaking down larger mappings
> at runtime will lead to TLB conflicts. Check if debug_pagealloc
> is enabled at runtime and if so, map everyting with PAGE_SIZE
> pages. Implement the functions to actually map/unmap the
> pages at runtime.
>
> Signed-off-by: Laura Abbott <labbott at fedoraproject.org>

This looks correct to me, but I still have a concern below.


> ---
>  arch/arm64/Kconfig       |  3 +++
>  arch/arm64/mm/mmu.c      | 25 +++++++++++++++++++++----
>  arch/arm64/mm/pageattr.c | 46 ++++++++++++++++++++++++++++++++++++----------
>  3 files changed, 60 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 8cc6228..0f33218 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -537,6 +537,9 @@ config HOTPLUG_CPU
>  source kernel/Kconfig.preempt
>  source kernel/Kconfig.hz
>
> +config ARCH_SUPPORTS_DEBUG_PAGEALLOC
> +       def_bool y
> +
>  config ARCH_HAS_HOLES_MEMORYMODEL
>         def_bool y if SPARSEMEM
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index ef0d66c..be81a59 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -180,8 +180,14 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
>         pmd = pmd_set_fixmap_offset(pud, addr);
>         do {
>                 next = pmd_addr_end(addr, end);
> -               /* try section mapping first */
> -               if (((addr | next | phys) & ~SECTION_MASK) == 0) {
> +               /*
> +                * try a section mapping first
> +                *
> +                * See comment in use_1G_block for why we need the check
> +                * for !pgtable_alloc with !debug_pagealloc
> +                */
> +               if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
> +                     (!debug_pagealloc_enabled() || !pgtable_alloc)) {
>                         pmd_t old_pmd =*pmd;
>                         set_pmd(pmd, __pmd(phys |
>                                            pgprot_val(mk_sect_prot(prot))));
> @@ -208,8 +214,19 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
>  }
>
>  static inline bool use_1G_block(unsigned long addr, unsigned long next,
> -                       unsigned long phys)
> +                       unsigned long phys, phys_addr_t (*pgtable_alloc)(void))
>  {
> +       /*
> +        * If debug_page_alloc is enabled we don't want to be using sections
> +        * since everything needs to be mapped with pages. The catch is
> +        * that we only want to force pages if we can allocate the next
> +        * layer of page tables. If there is no pgtable_alloc function,
> +        * it's too early to allocate another layer and we should use
> +        * section mappings.
> +        */
> +       if (pgtable_alloc && debug_pagealloc_enabled())
> +               return false;
> +

I would suggest you stick this comment and test in a separate function
'bool block_mappings_allowed(phys_addr_t (*pgtable_alloc)(void))' (or
a better name if you can think of one, by all means) and call it from
both sites where you need to perform the check. This keeps the
symmetry, and removes the need to change the prototype of
use_1G_block() to pass pgtable_alloc only to test it for NULL-ness

With that change:
Reviewed-by: Ard Biesheuvel <ard.biesheuvel at linaro,.org>


>         if (PAGE_SHIFT != 12)
>                 return false;
>
> @@ -241,7 +258,7 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
>                 /*
>                  * For 4K granule only, attempt to put down a 1GB block
>                  */
> -               if (use_1G_block(addr, next, phys)) {
> +               if (use_1G_block(addr, next, phys, pgtable_alloc)) {
>                         pud_t old_pud = *pud;
>                         set_pud(pud, __pud(phys |
>                                            pgprot_val(mk_sect_prot(prot))));
> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
> index 1360a02..57877af 100644
> --- a/arch/arm64/mm/pageattr.c
> +++ b/arch/arm64/mm/pageattr.c
> @@ -37,14 +37,31 @@ static int change_page_range(pte_t *ptep, pgtable_t token, unsigned long addr,
>         return 0;
>  }
>
> +/*
> + * This function assumes that the range is mapped with PAGE_SIZE pages.
> + */
> +static int __change_memory_common(unsigned long start, unsigned long size,
> +                               pgprot_t set_mask, pgprot_t clear_mask)
> +{
> +       struct page_change_data data;
> +       int ret;
> +
> +       data.set_mask = set_mask;
> +       data.clear_mask = clear_mask;
> +
> +       ret = apply_to_page_range(&init_mm, start, size, change_page_range,
> +                                       &data);
> +
> +       flush_tlb_kernel_range(start, start+size);
> +       return ret;
> +}
> +
>  static int change_memory_common(unsigned long addr, int numpages,
>                                 pgprot_t set_mask, pgprot_t clear_mask)
>  {
>         unsigned long start = addr;
>         unsigned long size = PAGE_SIZE*numpages;
>         unsigned long end = start + size;
> -       int ret;
> -       struct page_change_data data;
>         struct vm_struct *area;
>
>         if (!PAGE_ALIGNED(addr)) {
> @@ -72,14 +89,7 @@ static int change_memory_common(unsigned long addr, int numpages,
>             !(area->flags & VM_ALLOC))
>                 return -EINVAL;
>
> -       data.set_mask = set_mask;
> -       data.clear_mask = clear_mask;
> -
> -       ret = apply_to_page_range(&init_mm, start, size, change_page_range,
> -                                       &data);
> -
> -       flush_tlb_kernel_range(start, end);
> -       return ret;
> +       return __change_memory_common(start, size, set_mask, clear_mask);
>  }
>
>  int set_memory_ro(unsigned long addr, int numpages)
> @@ -111,3 +121,19 @@ int set_memory_x(unsigned long addr, int numpages)
>                                         __pgprot(PTE_PXN));
>  }
>  EXPORT_SYMBOL_GPL(set_memory_x);
> +
> +#ifdef CONFIG_DEBUG_PAGEALLOC
> +void __kernel_map_pages(struct page *page, int numpages, int enable)
> +{
> +       unsigned long addr = (unsigned long) page_address(page);
> +
> +       if (enable)
> +               __change_memory_common(addr, PAGE_SIZE*numpages,
> +                                       __pgprot(PTE_VALID),
> +                                       __pgprot(0));
> +       else
> +               __change_memory_common(addr, PAGE_SIZE*numpages,
> +                                       __pgprot(0),
> +                                       __pgprot(PTE_VALID));
> +}
> +#endif
> --
> 2.5.0
>


From ard.biesheuvel at linaro.org  Fri Feb  5 04:05:53 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 5 Feb 2016 13:05:53 +0100
Subject: [PATCHv3 3/3] arm64: ptdump: Indicate whether memory should be
 faulting
In-Reply-To: <1454615017-24672-4-git-send-email-labbott@fedoraproject.org>
References: <1454615017-24672-1-git-send-email-labbott@fedoraproject.org>
 <1454615017-24672-4-git-send-email-labbott@fedoraproject.org>
Message-ID: <CAKv+Gu_WAsRUjxbG5wCjSBBYqAHLWBpM8G7pj04snoEsgeOcUg@mail.gmail.com>

On 4 February 2016 at 20:43, Laura Abbott <labbott at fedoraproject.org> wrote:
>
> With CONFIG_DEBUG_PAGEALLOC, pages do not have the valid bit
> set when free in the buddy allocator. Add an indiciation to
> the page table dumping code that the valid bit is not set,
> 'F' for fault, to make this easier to understand.
>
> Signed-off-by: Laura Abbott <labbott at fedoraproject.org>

Reviewed-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

> ---
>  arch/arm64/mm/dump.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index 5a22a11..f381ac9 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -90,6 +90,11 @@ struct prot_bits {
>
>  static const struct prot_bits pte_bits[] = {
>         {
> +               .mask   = PTE_VALID,
> +               .val    = PTE_VALID,
> +               .set    = " ",
> +               .clear  = "F",
> +       }, {
>                 .mask   = PTE_USER,
>                 .val    = PTE_USER,
>                 .set    = "USR",
> --
> 2.5.0
>


From u.kleine-koenig at pengutronix.de  Fri Feb  5 04:08:19 2016
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri,  5 Feb 2016 13:08:19 +0100
Subject: [PATCH v3 1/3] fixup! Input: rotary_encoder - convert to use gpiod API
In-Reply-To: <1454674101-1194-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1454674101-1194-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <1454674101-1194-2-git-send-email-u.kleine-koenig@pengutronix.de>

---
 arch/arm/mach-pxa/raumfeld.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-pxa/raumfeld.c b/arch/arm/mach-pxa/raumfeld.c
index c559114431eb..77e412cd2766 100644
--- a/arch/arm/mach-pxa/raumfeld.c
+++ b/arch/arm/mach-pxa/raumfeld.c
@@ -368,7 +368,7 @@ static struct pxaohci_platform_data raumfeld_ohci_info = {
  */
 
 static struct gpiod_lookup_table raumfeld_rotary_gpios_table = {
-	.dev_id = "rotary-encoder",
+	.dev_id = "rotary-encoder.0",
 	.table = {
 		GPIO_LOOKUP_IDX("gpio-0",
 				GPIO_VOLENC_A, NULL, 0, GPIO_ACTIVE_LOW),
-- 
2.7.0



From u.kleine-koenig at pengutronix.de  Fri Feb  5 04:08:18 2016
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri,  5 Feb 2016 13:08:18 +0100
Subject: [PATCH v3 0/3] Input: rotary_encoder - Fixups for Dmitry's rework and
 support for >2 gpios
Message-ID: <1454674101-1194-1-git-send-email-u.kleine-koenig@pengutronix.de>

Hello,

This bases on top of

	git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input rotary-encoder

(currently at 557a30f2f046).

Dmitry, I assume you will squash the two fixups accordingly, otherwise
just tell me, then I create proper patches.

Also let me note that with threaded irqs I'm able to rotate my device
quicker than irq handling happens. So a quick counterclockwise rotation
might be detected as single step clockwise rotation.

Best regards
Uwe

Uwe Kleine-K?nig (3):
  fixup! Input: rotary_encoder - convert to use gpiod API
  fixup! Input: rotary_encoder - use threaded irqs
  Input: rotary-encoder - support more than 2 gpios as input

 .../devicetree/bindings/input/rotary-encoder.txt   |   2 +-
 arch/arm/mach-pxa/raumfeld.c                       |   2 +-
 drivers/input/misc/rotary_encoder.c                | 158 +++++++++------------
 3 files changed, 68 insertions(+), 94 deletions(-)

-- 
2.7.0



From u.kleine-koenig at pengutronix.de  Fri Feb  5 04:08:20 2016
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri,  5 Feb 2016 13:08:20 +0100
Subject: [PATCH v3 2/3] fixup! Input: rotary_encoder - use threaded irqs
In-Reply-To: <1454674101-1194-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1454674101-1194-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <1454674101-1194-3-git-send-email-u.kleine-koenig@pengutronix.de>

request_threaed_irq fails if handler == NULL and ONESHOT not in flags.
---
 drivers/input/misc/rotary_encoder.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/rotary_encoder.c b/drivers/input/misc/rotary_encoder.c
index 309612a6d9f5..5a4e1d69c4af 100644
--- a/drivers/input/misc/rotary_encoder.c
+++ b/drivers/input/misc/rotary_encoder.c
@@ -296,7 +296,8 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 	}
 
 	err = devm_request_threaded_irq(dev, encoder->irq_a, NULL, handler,
-				IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
+				IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING |
+				IRQF_ONESHOT,
 				DRV_NAME, encoder);
 	if (err) {
 		dev_err(dev, "unable to request IRQ %d\n", encoder->irq_a);
@@ -304,7 +305,8 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 	}
 
 	err = devm_request_threaded_irq(dev, encoder->irq_b, NULL, handler,
-				IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
+				IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING |
+				IRQF_ONESHOT,
 				DRV_NAME, encoder);
 	if (err) {
 		dev_err(dev, "unable to request IRQ %d\n", encoder->irq_b);
-- 
2.7.0



From u.kleine-koenig at pengutronix.de  Fri Feb  5 04:08:21 2016
From: u.kleine-koenig at pengutronix.de (=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?=)
Date: Fri,  5 Feb 2016 13:08:21 +0100
Subject: [PATCH v3 3/3] Input: rotary-encoder - support more than 2 gpios as
 input
In-Reply-To: <1454674101-1194-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1454674101-1194-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <1454674101-1194-4-git-send-email-u.kleine-koenig@pengutronix.de>

This changes how the used gpios are stored (i.e. a struct gpio_descs
instead of two struct gpio_desc) and as with >2 gpios the states are
numbered differently the function rotary_encoder_get_state returns
unencoded numbers instead of grey encoded numbers before. The latter has
some implications on how the returned value is used and so the change is
bigger than one might expect at first.

Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 .../devicetree/bindings/input/rotary-encoder.txt   |   2 +-
 drivers/input/misc/rotary_encoder.c                | 156 +++++++++------------
 2 files changed, 65 insertions(+), 93 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt
index de99cbbbf6da..6c9f0c8a846c 100644
--- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
+++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
@@ -1,7 +1,7 @@
 Rotary encoder DT bindings
 
 Required properties:
-- gpios: a spec for two GPIOs to be used
+- gpios: a spec for at least two GPIOs to be used, most significant first
 
 Optional properties:
 - linux,axis: the input subsystem axis to map to this rotary encoder.
diff --git a/drivers/input/misc/rotary_encoder.c b/drivers/input/misc/rotary_encoder.c
index 5a4e1d69c4af..09f6de77d1af 100644
--- a/drivers/input/misc/rotary_encoder.c
+++ b/drivers/input/misc/rotary_encoder.c
@@ -40,35 +40,42 @@ struct rotary_encoder {
 
 	unsigned int pos;
 
-	struct gpio_desc *gpio_a;
-	struct gpio_desc *gpio_b;
+	struct gpio_descs *gpios;
 
-	unsigned int irq_a;
-	unsigned int irq_b;
+	unsigned int *irq;
 
 	bool armed;
-	unsigned char dir;	/* 0 - clockwise, 1 - CCW */
+	signed char dir;	/* 1 - clockwise, -1 - CCW */
 
-	char last_stable;
+	unsigned last_stable;
 };
 
-static int rotary_encoder_get_state(struct rotary_encoder *encoder)
+static unsigned rotary_encoder_get_state(struct rotary_encoder *encoder)
 {
-	int a = !!gpiod_get_value_cansleep(encoder->gpio_a);
-	int b = !!gpiod_get_value_cansleep(encoder->gpio_b);
+	int i;
+	unsigned ret = 0;
 
-	return ((a << 1) | b);
+	for (i = 0; i < encoder->gpios->ndescs; ++i) {
+		int val = gpiod_get_value(encoder->gpios->desc[i]);
+		/* convert from gray encoding to normal */
+		if (ret & 1)
+			val = !val;
+
+		ret = ret << 1 | val;
+	}
+
+	return ret & 3;
 }
 
 static void rotary_encoder_report_event(struct rotary_encoder *encoder)
 {
 	if (encoder->relative_axis) {
 		input_report_rel(encoder->input,
-				 encoder->axis, encoder->dir ? -1 : 1);
+				 encoder->axis, encoder->dir);
 	} else {
 		unsigned int pos = encoder->pos;
 
-		if (encoder->dir) {
+		if (encoder->dir < 0) {
 			/* turning counter-clockwise */
 			if (encoder->rollover)
 				pos += encoder->steps;
@@ -93,7 +100,7 @@ static void rotary_encoder_report_event(struct rotary_encoder *encoder)
 static irqreturn_t rotary_encoder_irq(int irq, void *dev_id)
 {
 	struct rotary_encoder *encoder = dev_id;
-	int state;
+	unsigned state;
 
 	mutex_lock(&encoder->access_mutex);
 
@@ -108,12 +115,12 @@ static irqreturn_t rotary_encoder_irq(int irq, void *dev_id)
 		break;
 
 	case 0x1:
-	case 0x2:
+	case 0x3:
 		if (encoder->armed)
-			encoder->dir = state - 1;
+			encoder->dir = 2 - state;
 		break;
 
-	case 0x3:
+	case 0x2:
 		encoder->armed = true;
 		break;
 	}
@@ -126,25 +133,19 @@ static irqreturn_t rotary_encoder_irq(int irq, void *dev_id)
 static irqreturn_t rotary_encoder_half_period_irq(int irq, void *dev_id)
 {
 	struct rotary_encoder *encoder = dev_id;
-	int state;
+	unsigned int state;
 
 	mutex_lock(&encoder->access_mutex);
 
 	state = rotary_encoder_get_state(encoder);
 
-	switch (state) {
-	case 0x00:
-	case 0x03:
+	if (state & 1) {
+		encoder->dir = ((encoder->last_stable - state + 1) % 4) - 1;
+	} else {
 		if (state != encoder->last_stable) {
 			rotary_encoder_report_event(encoder);
 			encoder->last_stable = state;
 		}
-		break;
-
-	case 0x01:
-	case 0x02:
-		encoder->dir = (encoder->last_stable + state) & 0x01;
-		break;
 	}
 
 	mutex_unlock(&encoder->access_mutex);
@@ -155,46 +156,18 @@ static irqreturn_t rotary_encoder_half_period_irq(int irq, void *dev_id)
 static irqreturn_t rotary_encoder_quarter_period_irq(int irq, void *dev_id)
 {
 	struct rotary_encoder *encoder = dev_id;
-	unsigned char sum;
-	int state;
+	unsigned int state;
 
 	mutex_lock(&encoder->access_mutex);
 
 	state = rotary_encoder_get_state(encoder);
 
-	/*
-	 * We encode the previous and the current state using a byte.
-	 * The previous state in the MSB nibble, the current state in the LSB
-	 * nibble. Then use a table to decide the direction of the turn.
-	 */
-	sum = (encoder->last_stable << 4) + state;
-	switch (sum) {
-	case 0x31:
-	case 0x10:
-	case 0x02:
-	case 0x23:
-		encoder->dir = 0; /* clockwise */
-		break;
-
-	case 0x13:
-	case 0x01:
-	case 0x20:
-	case 0x32:
-		encoder->dir = 1; /* counter-clockwise */
-		break;
-
-	default:
-		/*
-		 * Ignore all other values. This covers the case when the
-		 * state didn't change (a spurious interrupt) and the
-		 * cases where the state changed by two steps, making it
-		 * impossible to tell the direction.
-		 *
-		 * In either case, don't report any event and save the
-		 * state for later.
-		 */
+	if ((encoder->last_stable + 1) % 4 == state)
+		encoder->dir = 1;
+	else if (encoder->last_stable == (state + 1) % 4)
+		encoder->dir = -1;
+	else
 		goto out;
-	}
 
 	rotary_encoder_report_event(encoder);
 
@@ -213,6 +186,7 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 	irq_handler_t handler;
 	u32 steps_per_period;
 	int err;
+	unsigned i;
 
 	encoder = devm_kzalloc(dev, sizeof(struct rotary_encoder), GFP_KERNEL);
 	if (!encoder)
@@ -243,24 +217,16 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 	encoder->relative_axis =
 		device_property_read_bool(dev, "rotary-encoder,relative-axis");
 
-	encoder->gpio_a = devm_gpiod_get_index(dev, NULL, 0, GPIOD_IN);
-	if (IS_ERR(encoder->gpio_a)) {
-		err = PTR_ERR(encoder->gpio_a);
-		dev_err(dev, "unable to get GPIO at index 0: %d\n", err);
-		return err;
+	encoder->gpios = devm_gpiod_get_array(dev, NULL, GPIOD_IN);
+	if (IS_ERR(encoder->gpios)) {
+		dev_err(dev, "unable to get gpios\n");
+		return PTR_ERR(encoder->gpios);
 	}
-
-	encoder->irq_a = gpiod_to_irq(encoder->gpio_a);
-
-	encoder->gpio_b = devm_gpiod_get_index(dev, NULL, 1, GPIOD_IN);
-	if (IS_ERR(encoder->gpio_b)) {
-		err = PTR_ERR(encoder->gpio_b);
-		dev_err(dev, "unable to get GPIO at index 1: %d\n", err);
-		return err;
+	if (encoder->gpios->ndescs < 2) {
+		dev_err(dev, "not enough gpios found\n");
+		return -EINVAL;
 	}
 
-	encoder->irq_b = gpiod_to_irq(encoder->gpio_b);
-
 	input = devm_input_allocate_device(dev);
 	if (!input)
 		return -ENOMEM;
@@ -277,7 +243,7 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 		input_set_abs_params(input,
 				     encoder->axis, 0, encoder->steps, 0, 1);
 
-	switch (steps_per_period) {
+	switch (steps_per_period >> (encoder->gpios->ndescs - 2)) {
 	case 4:
 		handler = &rotary_encoder_quarter_period_irq;
 		encoder->last_stable = rotary_encoder_get_state(encoder);
@@ -295,22 +261,26 @@ static int rotary_encoder_probe(struct platform_device *pdev)
 		return -EINVAL;
 	}
 
-	err = devm_request_threaded_irq(dev, encoder->irq_a, NULL, handler,
-				IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING |
-				IRQF_ONESHOT,
-				DRV_NAME, encoder);
-	if (err) {
-		dev_err(dev, "unable to request IRQ %d\n", encoder->irq_a);
-		return err;
-	}
+	encoder->irq =
+		devm_kzalloc(dev,
+			     sizeof(*encoder->irq) * encoder->gpios->ndescs,
+			     GFP_KERNEL);
+	if (!encoder->irq)
+		return -ENOMEM;
 
-	err = devm_request_threaded_irq(dev, encoder->irq_b, NULL, handler,
+	for (i = 0; i < encoder->gpios->ndescs; ++i) {
+		encoder->irq[i] = gpiod_to_irq(encoder->gpios->desc[i]);
+
+		err = devm_request_threaded_irq(dev, encoder->irq[i],
+				NULL, handler,
 				IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING |
 				IRQF_ONESHOT,
 				DRV_NAME, encoder);
-	if (err) {
-		dev_err(dev, "unable to request IRQ %d\n", encoder->irq_b);
-		return err;
+		if (err) {
+			dev_err(dev, "unable to request IRQ %d (gpio#%d)\n",
+				encoder->irq[i], i);
+			return err;
+		}
 	}
 
 	err = input_register_device(input);
@@ -332,8 +302,9 @@ static int __maybe_unused rotary_encoder_suspend(struct device *dev)
 	struct rotary_encoder *encoder = dev_get_drvdata(dev);
 
 	if (device_may_wakeup(dev)) {
-		enable_irq_wake(encoder->irq_a);
-		enable_irq_wake(encoder->irq_b);
+		unsigned int i;
+		for (i = 0; i < encoder->gpios->ndescs; ++i)
+			enable_irq_wake(encoder->irq[i]);
 	}
 
 	return 0;
@@ -344,8 +315,9 @@ static int __maybe_unused rotary_encoder_resume(struct device *dev)
 	struct rotary_encoder *encoder = dev_get_drvdata(dev);
 
 	if (device_may_wakeup(dev)) {
-		disable_irq_wake(encoder->irq_a);
-		disable_irq_wake(encoder->irq_b);
+		unsigned int i;
+		for (i = 0; i < encoder->gpios->ndescs; ++i)
+			disable_irq_wake(encoder->irq[i]);
 	}
 
 	return 0;
-- 
2.7.0



From cyrille.pitchen at atmel.com  Fri Feb  5 04:45:11 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Fri, 5 Feb 2016 13:45:11 +0100
Subject: [PATCH 0/2] crypto: atmel-sha - fix resource management
Message-ID: <cover.1454675769.git.cyrille.pitchen@atmel.com>

Hi all,

these two small patches fix resource release and clock management in
atomic context.

Best regards,

Cyrille

Cyrille Pitchen (2):
  crypto: atmel-sha: fix atmel_sha_remove()
  crypto: atmel-sha - remove calls of clk_prepare() from atomic contexts

 drivers/crypto/atmel-sha.c | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Fri Feb  5 04:45:12 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Fri, 5 Feb 2016 13:45:12 +0100
Subject: [PATCH 1/2] crypto: atmel-sha: fix atmel_sha_remove()
In-Reply-To: <cover.1454675769.git.cyrille.pitchen@atmel.com>
References: <cover.1454675769.git.cyrille.pitchen@atmel.com>
Message-ID: <0ded195da1a7c7e84f959eff0cdd65ddc39c8d51.1454675769.git.cyrille.pitchen@atmel.com>

Since atmel_sha_probe() uses devm_xxx functions to allocate resources,
atmel_sha_remove() should no longer explicitly release them.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
Fixes: b0e8b3417a62 ("crypto: atmel - use devm_xxx() managed function")
---
 drivers/crypto/atmel-sha.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel-sha.c
index 63b09e01075c..b827c99b17c1 100644
--- a/drivers/crypto/atmel-sha.c
+++ b/drivers/crypto/atmel-sha.c
@@ -1611,13 +1611,6 @@ static int atmel_sha_remove(struct platform_device *pdev)
 	if (sha_dd->caps.has_dma)
 		atmel_sha_dma_cleanup(sha_dd);
 
-	iounmap(sha_dd->io_base);
-
-	clk_put(sha_dd->iclk);
-
-	if (sha_dd->irq >= 0)
-		free_irq(sha_dd->irq, sha_dd);
-
 	return 0;
 }
 
-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Fri Feb  5 04:45:13 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Fri, 5 Feb 2016 13:45:13 +0100
Subject: [PATCH 2/2] crypto: atmel-sha - remove calls of clk_prepare() from
 atomic contexts
In-Reply-To: <cover.1454675769.git.cyrille.pitchen@atmel.com>
References: <cover.1454675769.git.cyrille.pitchen@atmel.com>
Message-ID: <6b343599db251a8f00820939e01c5e35cc359686.1454675769.git.cyrille.pitchen@atmel.com>

clk_prepare()/clk_unprepare() must not be called within atomic context.

This patch calls clk_prepare() once for all from atmel_sha_probe() and
clk_unprepare() from atmel_sha_remove().

Then calls of clk_prepare_enable()/clk_disable_unprepare() were replaced
by calls of clk_enable()/clk_disable().

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
Reported-by: Matthias Mayr <matthias.mayr at student.kit.edu>
---
 drivers/crypto/atmel-sha.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel-sha.c
index b827c99b17c1..f8407dc7dd38 100644
--- a/drivers/crypto/atmel-sha.c
+++ b/drivers/crypto/atmel-sha.c
@@ -846,7 +846,7 @@ static void atmel_sha_finish_req(struct ahash_request *req, int err)
 	dd->flags &= ~(SHA_FLAGS_BUSY | SHA_FLAGS_FINAL | SHA_FLAGS_CPU |
 			SHA_FLAGS_DMA_READY | SHA_FLAGS_OUTPUT_READY);
 
-	clk_disable_unprepare(dd->iclk);
+	clk_disable(dd->iclk);
 
 	if (req->base.complete)
 		req->base.complete(&req->base, err);
@@ -859,7 +859,7 @@ static int atmel_sha_hw_init(struct atmel_sha_dev *dd)
 {
 	int err;
 
-	err = clk_prepare_enable(dd->iclk);
+	err = clk_enable(dd->iclk);
 	if (err)
 		return err;
 
@@ -886,7 +886,7 @@ static void atmel_sha_hw_version_init(struct atmel_sha_dev *dd)
 	dev_info(dd->dev,
 			"version: 0x%x\n", dd->hw_version);
 
-	clk_disable_unprepare(dd->iclk);
+	clk_disable(dd->iclk);
 }
 
 static int atmel_sha_handle_queue(struct atmel_sha_dev *dd,
@@ -1536,6 +1536,10 @@ static int atmel_sha_probe(struct platform_device *pdev)
 		goto res_err;
 	}
 
+	err = clk_prepare(sha_dd->iclk);
+	if (err)
+		goto res_err;
+
 	atmel_sha_hw_version_init(sha_dd);
 
 	atmel_sha_get_cap(sha_dd);
@@ -1547,12 +1551,12 @@ static int atmel_sha_probe(struct platform_device *pdev)
 			if (IS_ERR(pdata)) {
 				dev_err(&pdev->dev, "platform data not available\n");
 				err = PTR_ERR(pdata);
-				goto res_err;
+				goto iclk_unprepare;
 			}
 		}
 		if (!pdata->dma_slave) {
 			err = -ENXIO;
-			goto res_err;
+			goto iclk_unprepare;
 		}
 		err = atmel_sha_dma_init(sha_dd, pdata);
 		if (err)
@@ -1583,6 +1587,8 @@ err_algs:
 	if (sha_dd->caps.has_dma)
 		atmel_sha_dma_cleanup(sha_dd);
 err_sha_dma:
+iclk_unprepare:
+	clk_unprepare(sha_dd->iclk);
 res_err:
 	tasklet_kill(&sha_dd->queue_task);
 	tasklet_kill(&sha_dd->done_task);
@@ -1611,6 +1617,8 @@ static int atmel_sha_remove(struct platform_device *pdev)
 	if (sha_dd->caps.has_dma)
 		atmel_sha_dma_cleanup(sha_dd);
 
+	clk_unprepare(sha_dd->iclk);
+
 	return 0;
 }
 
-- 
1.8.2.2



From alexander.shishkin at linux.intel.com  Fri Feb  5 04:52:10 2016
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Fri, 05 Feb 2016 14:52:10 +0200
Subject: [PATCH V2 3/6] stm class: provision for statically assigned
 masterIDs
In-Reply-To: <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
 <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com>

Chunyan Zhang <zhang.chunyan at linaro.org> writes:

> From: Mathieu Poirier <mathieu.poirier at linaro.org>
>
> Some architecture like ARM assign masterIDs statically at the HW design
> phase, making masterID manipulation in the generic STM core irrelevant.
>
> This patch adds a new 'mstatic' flag to struct stm_data that tells the
> core that this specific STM device doesn't need explicit masterID
> management.

So why do we need this patch? If your STM only has master 42 allocated
for software sources, simply set sw_start = 42, sw_end = 42 and you're
good to go, software will have exactly one channel to choose from. See
also the comment from <linux/stm.h>:

 * @sw_start:           first STP master available to software
 * @sw_end:             last STP master available to software

particularly the "available to software" part. Any other kinds of
masters the STM class code doesn't care about (yet).

> In the core sw_start/end of masterID are set to '1',
> i.e there is only one masterID to deal with.

This is also a completely arbitrary and unnecessary requirement. Again,
you can set both to 42 and it will still work.

> Also this patch depends on [1], so that the number of masterID
> is '1' too.
>
> Finally the lower and upper bound for masterIDs as presented
> in ($SYSFS)/class/stm/XYZ.stm/masters and
> ($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
> are set to '-1'.  That way users can't confuse them with
> architecture where masterID management is required (where any
> other value would be valid).

Why is this a good idea? Having the actual master there will allow
software to know what it is and also tell the decoding side what it is
(assuming you have more than one source in the STP stream, it might not
be easy to figure out, unless you know it in advance).

I don't see how one master statically assigned to software sources is
different from two masters or 32 masters. And I don't see any benefit of
hiding the master id from userspace. Am I missing something?

Regards,
--
Alex


From alexander.shishkin at linux.intel.com  Fri Feb  5 04:55:31 2016
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Fri, 05 Feb 2016 14:55:31 +0200
Subject: [PATCH V2 1/6] stm class: Add ioctl get_options interface
In-Reply-To: <1454487337-30184-2-git-send-email-zhang.chunyan@linaro.org>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
 <1454487337-30184-2-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <87k2mj5nb0.fsf@ashishki-desk.ger.corp.intel.com>

Chunyan Zhang <zhang.chunyan at linaro.org> writes:

> There is already an interface of set_options, but no get_options yet.
> Before setting any options, one would may want to see the current
> status of that option by means of get_options interface. This
> interface has been used in CoreSight STM driver.
>
> Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
> ---
>  drivers/hwtracing/stm/core.c | 11 +++++++++++
>  include/linux/stm.h          |  3 +++
>  include/uapi/linux/stm.h     |  1 +
>  3 files changed, 15 insertions(+)
>
> diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
> index b6445d9..86bb4e3 100644
> --- a/drivers/hwtracing/stm/core.c
> +++ b/drivers/hwtracing/stm/core.c
> @@ -571,6 +571,17 @@ stm_char_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
>  						    options);
>  
>  		break;
> +
> +	case STP_GET_OPTIONS:
> +		if (stm_data->get_options)
> +			err = stm_data->get_options(stm_data,
> +						    stmf->output.master,
> +						    stmf->output.channel,
> +						    stmf->output.nr_chans,
> +						    &options);
> +
> +		return copy_to_user((void __user *)arg, &options, sizeof(u64));

The return value of copy_to_user() is not what you assume it is.

Regards,
--
Alex


From hzpeterchen at gmail.com  Fri Feb  5 04:55:55 2016
From: hzpeterchen at gmail.com (Peter Chen)
Date: Fri, 5 Feb 2016 20:55:55 +0800
Subject: [PATCH v4 1/1] USB: core: let USB device know device node
In-Reply-To: <Pine.LNX.4.44L0.1602041130590.1515-100000@iolanthe.rowland.org>
References: <20160204015928.GA11158@shlinux2>
 <Pine.LNX.4.44L0.1602041130590.1515-100000@iolanthe.rowland.org>
Message-ID: <CAL411-oOgSYJy_cLVkGWkLbzBewKtj1jgfQqxCsjE_-3NLYcTA@mail.gmail.com>

On Fri, Feb 5, 2016 at 12:36 AM, Alan Stern <stern at rowland.harvard.edu> wrote:
> On Thu, 4 Feb 2016, Peter Chen wrote:
>
>> On Mon, Jan 25, 2016 at 03:24:39PM +0800, Peter Chen wrote:
>> > Although most of USB devices are hot-plug's, there are still some devices
>> > are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
>> > If these kinds of USB devices are multiple functions, and they can supply
>> > other interfaces like i2c, gpios for other devices, we may need to
>> > describe these at device tree.
>> >
>> > In this commit, it uses "reg" in dts as physical port number to match
>> > the phyiscal port number decided by USB core, if they are the same,
>> > then the device node is for the device we are creating for USB core.
>> >
>> > Signed-off-by: Peter Chen <peter.chen at freescale.com>
>> > ---
>> > Changes for v4:
>> > - The range of "reg" should be 1-31, changing device node address
>> >   style as in lower case hexadecimal with leading zeroes suppressed
>> >   [binding doc, usb-device.txt]
>> > - Improve the example at binding doc, it describes node from the top
>> >   (the controller)
>> > - Delete the struct of_node * within struct usb_device
>> > - Using usb_hcd_find_raw_port_number to get raw port number under root
>> >   hub port
>> >
>>
>> Hi Alan, Arnd, and others, would you please give Ack for it if you
>> are OK with this patch? I am not sure if Greg will queue it or not
>> if no one Acks it, thanks.
>
>
>> > @@ -508,11 +509,20 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
>> >     dev->connect_time = jiffies;
>> >     dev->active_duration = -jiffies;
>> >  #endif
>> > -   if (root_hub)   /* Root hub always ok [and always wired] */
>> > +   if (root_hub) { /* Root hub always ok [and always wired] */
>> >             dev->authorized = 1;
>> > -   else {
>> > +           dev->dev.of_node = bus->controller->of_node;
>> > +   } else {
>> >             dev->authorized = !!HCD_DEV_AUTHORIZED(usb_hcd);
>> >             dev->wusb = usb_bus_is_wusb(bus) ? 1 : 0;
>> > +
>> > +           if (dev->dev.parent->parent == bus->controller)
>> > +                   /* device under root hub's port */
>> > +                   port1 = usb_hcd_find_raw_port_number(usb_hcd,
>> > +                           port1);
>
> I would change the test to "if (!parent->parent)" and add {} around the
> body (since it's 3 lines long).  Also, although this doesn't really
> matter, you could consider putting the new code inside the previous big
> "if" statement instead of down here at the end of the function.
>

Sorry, Alan, I can understand using (!parent->parent) to stands for
the device connects to the root hub port, others I can't understand.

-- 
BR,
Peter Chen


From thomas.petazzoni at free-electrons.com  Fri Feb  5 05:02:59 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 5 Feb 2016 14:02:59 +0100
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half
 timeout panic support
In-Reply-To: <CADyBb7unAHEOMfruWS82RkHK6uwPAWCxUx9jqzSkiHU4LHDSeA@mail.gmail.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
 <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
 <56B2DEE4.7060901@roeck-us.net>
 <CADyBb7unAHEOMfruWS82RkHK6uwPAWCxUx9jqzSkiHU4LHDSeA@mail.gmail.com>
Message-ID: <20160205140259.72a33699@free-electrons.com>

Hello,

On Fri, 5 Feb 2016 17:51:52 +0800, Fu Wei wrote:

> OK, my thought is
> 
> if panic is enabled :
> |--------WOR-------WS0--------WOR-------WS1
> |------timeout------(panic)------timeout-----reset

I'm quite certainly missing something completely obvious here, but how
can you get the WS1 interrupt *after* raising a panic? Aren't all
interrupts disabled and the system fully halted once you get a panic(),
especially when raised from an interrupt handler? If that's the case,
how can the system continue to do things, such as receiving the WS1
interrupt and resetting ?

Again, I'm probably missing something obvious, but I'm interested to
understand the reasoning here.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From hzpeterchen at gmail.com  Fri Feb  5 05:03:43 2016
From: hzpeterchen at gmail.com (Peter Chen)
Date: Fri, 5 Feb 2016 21:03:43 +0800
Subject: [PATCH v4 1/1] USB: core: let USB device know device node
In-Reply-To: <1454665020.6406.21.camel@pengutronix.de>
References: <1453706679-18948-1-git-send-email-peter.chen@freescale.com>
 <1454582690.3356.18.camel@pengutronix.de> <20160205061124.GB1858@shlinux2>
 <1454665020.6406.21.camel@pengutronix.de>
Message-ID: <CAL411-rEqqQA=mJ64eqqawWOXTJ3FK6nKjGu=09RmofvOnz4Lw@mail.gmail.com>

On Fri, Feb 5, 2016 at 5:37 PM, Philipp Zabel <p.zabel at pengutronix.de> wrote:
> Am Freitag, den 05.02.2016, 14:11 +0800 schrieb Peter Chen:
> [...]
>> > The reference recommendation states that for single-configuration USB
>> > devices the compatible should contain all of the applicable strings from
>> > the list starting with 2) "usbVID,PID.REV" and ending with 11)
>> > "usb,device". Are we going to ignore this?
>>
>> I have not seen benefits if we write several compatibles in dts,
>> the information of compatibles listed in doc can be got during
>> the enumeration.
>>
>> I suggest we use the simple pattern for this compatible, in that
>> case, every one can be easy to follow it, and will not be confused
>> which compatibles should be used, and the style can be unify.
>
> Just pointing it out, a comment why this differs from the recommendation
> would be nice to avoid confusion.
>

Thanks, I will.

> [...]
>> > > +         compatible = "usb05e3,0608";
>> > > +         reg = <0x1>;
>> > > + };
>> >
>> > I'd have written this node as:
>> >
>> >     hub: hub at 1 {
>> >             compatible = "usb5e3,608", "usb5e3,class9",
>> >                          "usb,class9", "usb,device";
>> >             reg = <1>;
>> >     };
>>
>> The reg should be hexadecimal, do we need to add "0x" before the value?
>
> The unit-address name part should be hexadecimal, the reg property value
> doesn't have to be. As long as the value is < 10 I don't see a problem.
>

I see.

>> > As another example, I'd like to introduce the USB WLAN Adapter soldered
>> > onto the imx6q-gk802 board to its power enable GPIO via the device tree:
>> >
>> > /* Internal USB port (USBH1) */
>> > &usbh1 {
>> >     #address-cells = <1>;
>> >     #size-cells = <0>;
>> >     status = "okay";
>> >
>> >     /* RTL8192CU 802.11n WLAN Adapter */
>> >     device at 1 {
>> >             compatible = "usbbda,8176.200", "usbbda,8176",
>> >                          "usb,device";
>> >             reg = <1>;
>> >
>> >             enable-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
>> >     };
>> > };
>> >
>>
>> It is okay to use your example, but I still insist like below:
>
> Sorry for being imprecise. The hub example is fine for the
> documentation. I just wanted to illustrate how and why I am interested
> in this discussion.
>

Thanks for commenting it.

I will be in Chinese New Year holiday, will send next version after Feb 15th.

-- 
BR,
Peter Chen


From wens at csie.org  Fri Feb  5 05:03:40 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 5 Feb 2016 21:03:40 +0800
Subject: [PATCH RFC 10/11] clk: sunxi: rewrite sun6i-ar100 using factors
 clk
In-Reply-To: <CAP=VYLosgmUbk3hmeTkodZoVhZX6e74aG28HSgLVKaD4mR3W+A@mail.gmail.com>
References: <1453727747-23307-1-git-send-email-wens@csie.org>
 <1453727747-23307-11-git-send-email-wens@csie.org>
 <CAP=VYLosgmUbk3hmeTkodZoVhZX6e74aG28HSgLVKaD4mR3W+A@mail.gmail.com>
Message-ID: <CAGb2v65cTW+z5xnO0eikh=nF+4LnrZVJ6jCJ0K-65qQdTmSvCg@mail.gmail.com>

On Mon, Feb 1, 2016 at 12:59 AM, Paul Gortmaker
<paul.gortmaker at windriver.com> wrote:
> On Mon, Jan 25, 2016 at 8:15 AM, Chen-Yu Tsai <wens at csie.org> wrote:
>> sun6i's AR100 clock is a classic factors clk case:
>>
>> AR100 = ((parent mux) >> p) / (m + 1)
>>
>> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
>
> This patch adds a ".remove" function to a driver that is controlled by
> a bool Kconfig, and hence the remove code can't be called unless
> one explicitly goes into sysfs and muddles with the unbind as root
> (which normally has no sane use case for builtin, non-modular code).
>
> Since I'm trying to cut back on the amount of dead code we have
> in .remove functions for built in drivers, is there a valid use case
> for this one here, or can I just stage a delete commit for it too?

It's just there to balance the probe code. I thought it was missing.
But what you said makes sense. Go ahead.

> Normally I've set the set the disallow-unbind flag when deleting
> a .remove function to make it clear there is no sane use case
> for wandering into sysfs and unhooking the builtin driver.

Cool.

Thanks
ChenYu

>
> Thanks,
> Paul.
> --
>
>> ---
>>  drivers/clk/sunxi/clk-sun6i-ar100.c | 235 ++++++++++--------------------------
>>  1 file changed, 61 insertions(+), 174 deletions(-)
>>
>> diff --git a/drivers/clk/sunxi/clk-sun6i-ar100.c b/drivers/clk/sunxi/clk-sun6i-ar100.c
>> index 20887686bdbe..a7f5777834eb 100644
>> --- a/drivers/clk/sunxi/clk-sun6i-ar100.c
>> +++ b/drivers/clk/sunxi/clk-sun6i-ar100.c
>> @@ -8,211 +8,97 @@
>>   *
>>   */
>>
>> +#include <linux/bitops.h>
>>  #include <linux/clk-provider.h>
>>  #include <linux/module.h>
>>  #include <linux/of.h>
>>  #include <linux/platform_device.h>
>> +#include <linux/spinlock.h>
>>
>> -#define SUN6I_AR100_MAX_PARENTS                4
>> -#define SUN6I_AR100_SHIFT_MASK         0x3
>> -#define SUN6I_AR100_SHIFT_MAX          SUN6I_AR100_SHIFT_MASK
>> -#define SUN6I_AR100_SHIFT_SHIFT                4
>> -#define SUN6I_AR100_DIV_MASK           0x1f
>> -#define SUN6I_AR100_DIV_MAX            (SUN6I_AR100_DIV_MASK + 1)
>> -#define SUN6I_AR100_DIV_SHIFT          8
>> -#define SUN6I_AR100_MUX_MASK           0x3
>> -#define SUN6I_AR100_MUX_SHIFT          16
>> -
>> -struct ar100_clk {
>> -       struct clk_hw hw;
>> -       void __iomem *reg;
>> -};
>> -
>> -static inline struct ar100_clk *to_ar100_clk(struct clk_hw *hw)
>> -{
>> -       return container_of(hw, struct ar100_clk, hw);
>> -}
>> -
>> -static unsigned long ar100_recalc_rate(struct clk_hw *hw,
>> -                                      unsigned long parent_rate)
>> -{
>> -       struct ar100_clk *clk = to_ar100_clk(hw);
>> -       u32 val = readl(clk->reg);
>> -       int shift = (val >> SUN6I_AR100_SHIFT_SHIFT) & SUN6I_AR100_SHIFT_MASK;
>> -       int div = (val >> SUN6I_AR100_DIV_SHIFT) & SUN6I_AR100_DIV_MASK;
>> -
>> -       return (parent_rate >> shift) / (div + 1);
>> -}
>> -
>> -static int ar100_determine_rate(struct clk_hw *hw,
>> -                               struct clk_rate_request *req)
>> -{
>> -       int nparents = clk_hw_get_num_parents(hw);
>> -       long best_rate = -EINVAL;
>> -       int i;
>> -
>> -       req->best_parent_hw = NULL;
>> -
>> -       for (i = 0; i < nparents; i++) {
>> -               unsigned long parent_rate;
>> -               unsigned long tmp_rate;
>> -               struct clk_hw *parent;
>> -               unsigned long div;
>> -               int shift;
>> -
>> -               parent = clk_hw_get_parent_by_index(hw, i);
>> -               parent_rate = clk_hw_get_rate(parent);
>> -               div = DIV_ROUND_UP(parent_rate, req->rate);
>> -
>> -               /*
>> -                * The AR100 clk contains 2 divisors:
>> -                * - one power of 2 divisor
>> -                * - one regular divisor
>> -                *
>> -                * First check if we can safely shift (or divide by a power
>> -                * of 2) without losing precision on the requested rate.
>> -                */
>> -               shift = ffs(div) - 1;
>> -               if (shift > SUN6I_AR100_SHIFT_MAX)
>> -                       shift = SUN6I_AR100_SHIFT_MAX;
>> -
>> -               div >>= shift;
>> -
>> -               /*
>> -                * Then if the divisor is still bigger than what the HW
>> -                * actually supports, use a bigger shift (or power of 2
>> -                * divider) value and accept to lose some precision.
>> -                */
>> -               while (div > SUN6I_AR100_DIV_MAX) {
>> -                       shift++;
>> -                       div >>= 1;
>> -                       if (shift > SUN6I_AR100_SHIFT_MAX)
>> -                               break;
>> -               }
>> -
>> -               /*
>> -                * If the shift value (or power of 2 divider) is bigger
>> -                * than what the HW actually support, skip this parent.
>> -                */
>> -               if (shift > SUN6I_AR100_SHIFT_MAX)
>> -                       continue;
>> -
>> -               tmp_rate = (parent_rate >> shift) / div;
>> -               if (!req->best_parent_hw || tmp_rate > best_rate) {
>> -                       req->best_parent_hw = parent;
>> -                       req->best_parent_rate = parent_rate;
>> -                       best_rate = tmp_rate;
>> -               }
>> -       }
>> -
>> -       if (best_rate < 0)
>> -               return best_rate;
>> -
>> -       req->rate = best_rate;
>> -
>> -       return 0;
>> -}
>> -
>> -static int ar100_set_parent(struct clk_hw *hw, u8 index)
>> -{
>> -       struct ar100_clk *clk = to_ar100_clk(hw);
>> -       u32 val = readl(clk->reg);
>> -
>> -       if (index >= SUN6I_AR100_MAX_PARENTS)
>> -               return -EINVAL;
>> -
>> -       val &= ~(SUN6I_AR100_MUX_MASK << SUN6I_AR100_MUX_SHIFT);
>> -       val |= (index << SUN6I_AR100_MUX_SHIFT);
>> -       writel(val, clk->reg);
>> -
>> -       return 0;
>> -}
>> +#include "clk-factors.h"
>>
>> -static u8 ar100_get_parent(struct clk_hw *hw)
>> -{
>> -       struct ar100_clk *clk = to_ar100_clk(hw);
>> -       return (readl(clk->reg) >> SUN6I_AR100_MUX_SHIFT) &
>> -              SUN6I_AR100_MUX_MASK;
>> -}
>> -
>> -static int ar100_set_rate(struct clk_hw *hw, unsigned long rate,
>> -                         unsigned long parent_rate)
>> +/**
>> + * sun6i_get_ar100_factors - Calculates factors p, m for AR100
>> + *
>> + * AR100 rate is calculated as follows
>> + * rate = (parent_rate >> p) / (m + 1);
>> + */
>> +static void sun6i_get_ar100_factors(struct factors_request *req)
>>  {
>> -       unsigned long div = parent_rate / rate;
>> -       struct ar100_clk *clk = to_ar100_clk(hw);
>> -       u32 val = readl(clk->reg);
>> +       unsigned long div;
>>         int shift;
>>
>> -       if (parent_rate % rate)
>> -               return -EINVAL;
>> +       /* clock only divides */
>> +       if (req->rate > req->parent_rate)
>> +               req->rate = req->parent_rate;
>>
>> -       shift = ffs(div) - 1;
>> -       if (shift > SUN6I_AR100_SHIFT_MAX)
>> -               shift = SUN6I_AR100_SHIFT_MAX;
>> +       div = DIV_ROUND_UP(req->parent_rate, req->rate);
>>
>> -       div >>= shift;
>> +       if (div < 32)
>> +               shift = 0;
>> +       else if (div >> 1 < 32)
>> +               shift = 1;
>> +       else if (div >> 2 < 32)
>> +               shift = 2;
>> +       else
>> +               shift = 3;
>>
>> -       if (div > SUN6I_AR100_DIV_MAX)
>> -               return -EINVAL;
>> +       div >>= shift;
>>
>> -       val &= ~((SUN6I_AR100_SHIFT_MASK << SUN6I_AR100_SHIFT_SHIFT) |
>> -                (SUN6I_AR100_DIV_MASK << SUN6I_AR100_DIV_SHIFT));
>> -       val |= (shift << SUN6I_AR100_SHIFT_SHIFT) |
>> -              (div << SUN6I_AR100_DIV_SHIFT);
>> -       writel(val, clk->reg);
>> +       if (div > 32)
>> +               div = 32;
>>
>> -       return 0;
>> +       req->rate = (req->parent_rate >> shift) / div;
>> +       req->m = div - 1;
>> +       req->p = shift;
>>  }
>>
>> -static struct clk_ops ar100_ops = {
>> -       .recalc_rate = ar100_recalc_rate,
>> -       .determine_rate = ar100_determine_rate,
>> -       .set_parent = ar100_set_parent,
>> -       .get_parent = ar100_get_parent,
>> -       .set_rate = ar100_set_rate,
>> +static const struct clk_factors_config sun6i_ar100_config = {
>> +       .mwidth = 5,
>> +       .mshift = 8,
>> +       .pwidth = 2,
>> +       .pshift = 4,
>>  };
>>
>> +static const struct factors_data sun6i_ar100_data __initconst = {
>> +       .mux = 16,
>> +       .muxmask = GENMASK(1, 0),
>> +       .table = &sun6i_ar100_config,
>> +       .getter = sun6i_get_ar100_factors,
>> +};
>> +
>> +static DEFINE_SPINLOCK(sun6i_ar100_lock);
>> +
>>  static int sun6i_a31_ar100_clk_probe(struct platform_device *pdev)
>>  {
>> -       const char *parents[SUN6I_AR100_MAX_PARENTS];
>>         struct device_node *np = pdev->dev.of_node;
>> -       const char *clk_name = np->name;
>> -       struct clk_init_data init;
>> -       struct ar100_clk *ar100;
>>         struct resource *r;
>> +       void __iomem *reg;
>>         struct clk *clk;
>> -       int nparents;
>> -
>> -       ar100 = devm_kzalloc(&pdev->dev, sizeof(*ar100), GFP_KERNEL);
>> -       if (!ar100)
>> -               return -ENOMEM;
>>
>>         r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> -       ar100->reg = devm_ioremap_resource(&pdev->dev, r);
>> -       if (IS_ERR(ar100->reg))
>> -               return PTR_ERR(ar100->reg);
>> +       reg = devm_ioremap_resource(&pdev->dev, r);
>> +       if (IS_ERR(reg))
>> +               return PTR_ERR(reg);
>>
>> -       nparents = of_clk_get_parent_count(np);
>> -       if (nparents > SUN6I_AR100_MAX_PARENTS)
>> -               nparents = SUN6I_AR100_MAX_PARENTS;
>> -
>> -       of_clk_parent_fill(np, parents, nparents);
>> +       clk = sunxi_factors_register(np, &sun6i_ar100_data, &sun6i_ar100_lock,
>> +                                    reg);
>> +       if (!clk)
>> +               return -ENOMEM;
>>
>> -       of_property_read_string(np, "clock-output-names", &clk_name);
>> +       platform_set_drvdata(pdev, clk);
>>
>> -       init.name = clk_name;
>> -       init.ops = &ar100_ops;
>> -       init.parent_names = parents;
>> -       init.num_parents = nparents;
>> -       init.flags = 0;
>> +       return 0;
>> +}
>>
>> -       ar100->hw.init = &init;
>> +static int sun6i_a31_ar100_clk_remove(struct platform_device *pdev)
>> +{
>> +       struct device_node *np = pdev->dev.of_node;
>> +       struct clk *clk = platform_get_drvdata(pdev);
>>
>> -       clk = clk_register(&pdev->dev, &ar100->hw);
>> -       if (IS_ERR(clk))
>> -               return PTR_ERR(clk);
>> +       sunxi_factors_unregister(np, clk);
>>
>> -       return of_clk_add_provider(np, of_clk_src_simple_get, clk);
>> +       return 0;
>>  }
>>
>>  static const struct of_device_id sun6i_a31_ar100_clk_dt_ids[] = {
>> @@ -227,6 +113,7 @@ static struct platform_driver sun6i_a31_ar100_clk_driver = {
>>                 .of_match_table = sun6i_a31_ar100_clk_dt_ids,
>>         },
>>         .probe = sun6i_a31_ar100_clk_probe,
>> +       .remove = sun6i_a31_ar100_clk_remove,
>>  };
>>  module_platform_driver(sun6i_a31_ar100_clk_driver);
>>
>> --
>> 2.7.0
>>


From alexander.shishkin at linux.intel.com  Fri Feb  5 05:06:20 2016
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Fri, 05 Feb 2016 15:06:20 +0200
Subject: [PATCH V2 6/6] coresight-stm: adding driver for CoreSight STM
 component
In-Reply-To: <1454487337-30184-7-git-send-email-zhang.chunyan@linaro.org>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
 <1454487337-30184-7-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <87h9hn5msz.fsf@ashishki-desk.ger.corp.intel.com>

Chunyan Zhang <zhang.chunyan at linaro.org> writes:

> +#ifndef CONFIG_64BIT
> +static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
> +{
> +	asm volatile("strd %1, %0"
> +		     : "+Qo" (*(volatile u64 __force *)addr)
> +		     : "r" (val));
> +}

Is it really ok to do this for all !64bit arms, inside a driver, just
like that? I'm not an expert, but I'm pretty sure there's more to it.

Regards,
--
Alex


From timur at codeaurora.org  Fri Feb  5 05:08:23 2016
From: timur at codeaurora.org (Timur Tabi)
Date: Fri, 5 Feb 2016 07:08:23 -0600
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <20160205140259.72a33699@free-electrons.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
 <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
 <56B2DEE4.7060901@roeck-us.net>
 <CADyBb7unAHEOMfruWS82RkHK6uwPAWCxUx9jqzSkiHU4LHDSeA@mail.gmail.com>
 <20160205140259.72a33699@free-electrons.com>
Message-ID: <56B49EC7.4050306@codeaurora.org>

Thomas Petazzoni wrote:
>> if panic is enabled :
>> >|--------WOR-------WS0--------WOR-------WS1
>> >|------timeout------(panic)------timeout-----reset

> I'm quite certainly missing something completely obvious here, but how
> can you get the WS1 interrupt*after*  raising a panic? Aren't all
> interrupts disabled and the system fully halted once you get a panic(),
> especially when raised from an interrupt handler? If that's the case,
> how can the system continue to do things, such as receiving the WS1
> interrupt and resetting ?

Typically, WS1 is not an interrupt.  Instead, it's a hard system-level 
reset.

The hardware is capable of generating an interrupt for both WS0 and WS1. 
  However, the ACPI table only contains one interrupt value, and it's 
not clear whether that's supposed to be the WS0 interrupt or the WS1 
interrupts.

So this whole thing does assume a specfic watchdog configuration.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.


From nsekhar at ti.com  Fri Feb  5 05:20:29 2016
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 5 Feb 2016 18:50:29 +0530
Subject: [PATCH 4/4] ARM: davinci: make I2C support optional
In-Reply-To: <1454358962-640598-5-git-send-email-arnd@arndb.de>
References: <1454358962-640598-1-git-send-email-arnd@arndb.de>
 <1454358962-640598-5-git-send-email-arnd@arndb.de>
Message-ID: <56B4A19D.4060307@ti.com>

On Tuesday 02 February 2016 02:05 AM, Arnd Bergmann wrote:
> The davinci platform has tried to get support for the EEPROM right,
> but failed to get a clean build so far. At the moment, we get
> a warning whenever CONFIG_SYSFS is disabled, as that is needed by
> EEPROM_AT24:
> 
> warning: (MACH_DAVINCI_EVM && MACH_SFFSDR && MACH_DAVINCI_DM6467_EVM && MACH_DAVINCI_DM365_EVM && MACH_DAVINCI_DA830_EVM && MACH_MITYOMAPL138 && MACH_MINI2440) selects EEPROM_AT24 which has unmet direct dependencies (I2C && SYSFS)
> 
> Kevin Hilman initially added the 'select' to ensure that EEPROM_AT24
> is always enabled in machines that really want it for normal operation
> (i.e. for reading the MAC address). This broke when I2C was disabled,
> and Russell King followed up with another patch to select that as
> well.
> 
> I now see that the SYSFS dependency is still missing, which leaves
> us with three options:
> 
> a) add 'select SYSFS' in addition to the others
> b) change AT24_EEPPROM to work without sysfs (should be possible)
> c) remove all those selects again and get the files to build when
>    I2C is disabled.
> 
> I would really hate to do a) because adding select statements that
> hardwire user-selectable symbols is generally a bad idea. I first
> tried b) but then ended up redoing the patch from scratch to approach
> c), so we can also remove the other selects.
> 
> I checked that CONFIG_I2C is still enabled with davinci_all_defconfig,
> so that does not have to change.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 45b146d746ea ("ARM: Davinci: Fix I2C build errors")
> Fixes: 22ca466847ad ("davinci: kconfig: select at24 eeprom for selected boards")

This looks good to me. The #ifdefs in the middle of davinci_evm_init()
are an eyesore, but getting rid of the selects is a big plus.

Thanks,
Sekhar


From thomas.petazzoni at free-electrons.com  Fri Feb  5 05:33:18 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 5 Feb 2016 14:33:18 +0100
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half
 timeout panic support
In-Reply-To: <56B49EC7.4050306@codeaurora.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
 <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
 <56B2DEE4.7060901@roeck-us.net>
 <CADyBb7unAHEOMfruWS82RkHK6uwPAWCxUx9jqzSkiHU4LHDSeA@mail.gmail.com>
 <20160205140259.72a33699@free-electrons.com>
 <56B49EC7.4050306@codeaurora.org>
Message-ID: <20160205143318.2de2815c@free-electrons.com>

Hello,

On Fri, 5 Feb 2016 07:08:23 -0600, Timur Tabi wrote:

> > I'm quite certainly missing something completely obvious here, but how
> > can you get the WS1 interrupt*after*  raising a panic? Aren't all
> > interrupts disabled and the system fully halted once you get a panic(),
> > especially when raised from an interrupt handler? If that's the case,
> > how can the system continue to do things, such as receiving the WS1
> > interrupt and resetting ?
> 
> Typically, WS1 is not an interrupt.  Instead, it's a hard system-level 
> reset.

Ah, right, true. I missed that aspect because on my HW, triggering a
system-level reset on WS1 is optional. I can actually get an interrupt
on both WS0 and WS1, and no reset at all.

But a normal configuration indeed involves having the WS1 event
configured in HW to be a system-level reset.

So, OK, it makes sense. Thanks for the clarification!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From arnd at arndb.de  Fri Feb  5 05:37:44 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 05 Feb 2016 14:37:44 +0100
Subject: [PATCH] PCI: generic: map config window in one go
In-Reply-To: <CAKv+Gu8oZADs_FRN=p7_Nz0wXJVWVmzVNsxtzscyp7_cFAreAQ@mail.gmail.com>
References: <1454077035-23872-1-git-send-email-ard.biesheuvel@linaro.org>
 <4090946.AhejVJy7MO@wuerfel>
 <CAKv+Gu8oZADs_FRN=p7_Nz0wXJVWVmzVNsxtzscyp7_cFAreAQ@mail.gmail.com>
Message-ID: <1507671.sEYIrU8dv6@wuerfel>

On Friday 05 February 2016 11:48:54 Ard Biesheuvel wrote:
> On 29 January 2016 at 15:52, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Friday 29 January 2016 15:32:01 Ard Biesheuvel wrote:
> >> On 29 January 2016 at 15:28, Will Deacon <will.deacon at arm.com> wrote:
> >> > Hi Ard,
> >> >
> >> > On Fri, Jan 29, 2016 at 03:17:15PM +0100, Ard Biesheuvel wrote:
> >> >> Instead of iterating over the PCI config window and performing individual
> >> >> ioremap() calls on all the adjacent slices, perform a single ioremap() to
> >> >> map the entire region, and divvy it up later. This not only prevents
> >> >> leaving some of it mapped if we fail half way through, it also ensures that
> >> >> archs that support huge-vmap can use section mappings to perform the
> >> >> mapping.
> >> >>
> >> >> On my Seattle A0 box, this transforms 128 separate 1 MB mappings that are
> >> >> mapped down to 4 KB pages into a single 128 MB mapping using 2 MB sections,
> >> >> saving 512 KB worth of page tables.
> >> >>
> >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >> >> ---
> >> >
> >> > The code was written this way in response to feedback during driver review
> >> > that we couldn't necessarily grab that much contiguous vmalloc space on
> >> > 32-bit ARM. Unless that's changed, we probably want to to predicate this
> >> > change on having a 64-bit arch.
> >> >
> >>
> >> Ah right. How about testing for the ARCH_HAVE_HUGE_VMAP Kconfig symbol
> >> explicitly?
> >>
> >
> > Testing for 64BIT should be sufficient.
> >
> 
> Does it make sense to spin a v2 for this patch? Given the discussion
> we had regarding allocating only the config regions for busses that
> are populated, perhaps there is a better approach here?

Allocating only the config regions that are actually used would
be ideal, the problem is that you need to access the config space
in order to know which ones are, so this is certainly a bit tricky.

Are there any downsides to the x86 approach of using fixmap to
map each patch separately during the access? It's probably a bit
slower per access, but we don't do a lot of those accesses after
the system is booted.

	Arnd


From linus.walleij at linaro.org  Fri Feb  5 05:39:23 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 5 Feb 2016 14:39:23 +0100
Subject: [PATCH v2] pinctrl: sunxi: H3 requires irq_read_needs_mux
In-Reply-To: <20160203075713.GA23312@box2.japko.eu>
References: <20160203075713.GA23312@box2.japko.eu>
Message-ID: <CACRpkdbVtLYRku03bbnT=f7Ex1FoJqBv4Z6nY7pWkHy6wvHUfg@mail.gmail.com>

On Wed, Feb 3, 2016 at 8:57 AM, Krzysztof Adamski <k at japko.eu> wrote:

> It seems that on H3, just like on A10, when GPIOs are configured as
> external interrupt data registers does not contain their value.  When
> value is read, GPIO function must be temporary switched to input for
> reads.
>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

1. Waiting for Maxime's ACK on this patch.

2. Is this a regression that need to go in to fixes?

Yours,
Linus Walleij


From k at japko.eu  Fri Feb  5 05:43:18 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Fri, 5 Feb 2016 14:43:18 +0100
Subject: [PATCH v2] pinctrl: sunxi: H3 requires irq_read_needs_mux
In-Reply-To: <CACRpkdbVtLYRku03bbnT=f7Ex1FoJqBv4Z6nY7pWkHy6wvHUfg@mail.gmail.com>
References: <20160203075713.GA23312@box2.japko.eu>
 <CACRpkdbVtLYRku03bbnT=f7Ex1FoJqBv4Z6nY7pWkHy6wvHUfg@mail.gmail.com>
Message-ID: <20160205134317.GE12071@box2.japko.eu>

On Fri, Feb 05, 2016 at 02:39:23PM +0100, Linus Walleij wrote:
>On Wed, Feb 3, 2016 at 8:57 AM, Krzysztof Adamski <k at japko.eu> wrote:
>
>> It seems that on H3, just like on A10, when GPIOs are configured as
>> external interrupt data registers does not contain their value.  When
>> value is read, GPIO function must be temporary switched to input for
>> reads.
>>
>> Signed-off-by: Krzysztof Adamski <k at japko.eu>
>
>2. Is this a regression that need to go in to fixes?

Not sure what you mean by that. H3 support was added recently without 
this flag so it never worked properly on this SoC.  With this patch it 
does. So it's just a normal bug fix, not a regression.

Best regards,
Krzysztof Adamski


From wens at csie.org  Fri Feb  5 05:51:56 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 5 Feb 2016 21:51:56 +0800
Subject: [PATCH v2] pinctrl: sunxi: H3 requires irq_read_needs_mux
In-Reply-To: <CACRpkdbVtLYRku03bbnT=f7Ex1FoJqBv4Z6nY7pWkHy6wvHUfg@mail.gmail.com>
References: <20160203075713.GA23312@box2.japko.eu>
 <CACRpkdbVtLYRku03bbnT=f7Ex1FoJqBv4Z6nY7pWkHy6wvHUfg@mail.gmail.com>
Message-ID: <CAGb2v65ZTBQZhFvesHPdwXDbwuVWcOQ+KUu82DWae6K8ycAxMA@mail.gmail.com>

On Fri, Feb 5, 2016 at 9:39 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Wed, Feb 3, 2016 at 8:57 AM, Krzysztof Adamski <k at japko.eu> wrote:
>
>> It seems that on H3, just like on A10, when GPIOs are configured as
>> external interrupt data registers does not contain their value.  When
>> value is read, GPIO function must be temporary switched to input for
>> reads.
>>
>> Signed-off-by: Krzysztof Adamski <k at japko.eu>
>
> 1. Waiting for Maxime's ACK on this patch.

Maxime already acked v1.

Acked-by: Chen-Yu Tsai <wens at csie.org>

> 2. Is this a regression that need to go in to fixes?

This driver was introduced in 4.5-rc1. It'd be nice if this fix could make
it in 4.5. :)


Thanks
ChenYu


From linus.walleij at linaro.org  Fri Feb  5 05:52:59 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 5 Feb 2016 14:52:59 +0100
Subject: [PATCH 1/2] pinctrl: mediatek: fix direction control issue
In-Reply-To: <1454555015.4618.10.camel@mussux00>
References: <1454462686-770-1-git-send-email-biao.huang@mediatek.com>
 <1454462686-770-2-git-send-email-biao.huang@mediatek.com>
 <1454555015.4618.10.camel@mussux00>
Message-ID: <CACRpkdZb2-TX1eY7eyK5qCqOg66MP1e4+OO287roJdP=RB6-Fg@mail.gmail.com>

On Thu, Feb 4, 2016 at 4:03 AM, Hongzhou Yang
<hongzhou.yang at mediatek.com> wrote:
> On Wed, 2016-02-03 at 09:24 +0800, Biao Huang wrote:
>> Since input-enable/disable and input-schmitt-enable/disable are
>> workable when gpio direction is input, so add direction setting
>> when do input-enable/disable and input-schmitt-enable/disable
>> properties.
>>
>> Signed-off-by: Biao Huang <biao.huang at mediatek.com>
>> ---
>>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c |    2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
>> index 8cac73d..6eb01c9 100644
>> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
>> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
>> @@ -352,6 +352,7 @@ static int mtk_pconf_parse_conf(struct pinctrl_dev *pctldev,
>>               ret = mtk_pconf_set_pull_select(pctl, pin, true, false, arg);
>>               break;
>>       case PIN_CONFIG_INPUT_ENABLE:
>> +             mtk_pmx_gpio_set_direction(pctldev, NULL, pin, true);
>>               ret = mtk_pconf_set_ies_smt(pctl, pin, arg, param);
>
> Hi Linus,
>
> From pinctrl-bindings.txt, 'input-enable' property defined as following:
> input-enable        - enable input on pin (no effect on output)
>
> Since input enable and input direction are two different settings on our
> SOC,

What does this mean? How can input have a "direction"?

Isn't the direction of an input always inbound, into the SoC?

Please elaborate.

> could you tell me the exact meaning of this property? Input enable
> only? Or set input direction at the same time?

This was added in commit 8ba3f4d00078e7a49c60c0bd6298f29402c3a0a0
"pinctrl: Adds slew-rate, input-enable/disable"
by Sherman Yin so let's ask him first.

I interpret it as if there is a single bit setting a pin to input, these
two boolean flags toggle that bit, so it would be the first setting
on your SoC in that case.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Fri Feb  5 05:56:07 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 5 Feb 2016 14:56:07 +0100
Subject: [PATCH 1/2] pinctrl: mediatek: fix direction control issue
In-Reply-To: <1454462686-770-2-git-send-email-biao.huang@mediatek.com>
References: <1454462686-770-1-git-send-email-biao.huang@mediatek.com>
 <1454462686-770-2-git-send-email-biao.huang@mediatek.com>
Message-ID: <CACRpkdY5e-1mTOzPVUvPEJyxLBVxZRQw6Gqui1pAno96_RWq8g@mail.gmail.com>

On Wed, Feb 3, 2016 at 2:24 AM, Biao Huang <biao.huang at mediatek.com> wrote:

> Since input-enable/disable and input-schmitt-enable/disable are
> workable when gpio direction is input, so add direction setting
> when do input-enable/disable and input-schmitt-enable/disable
> properties.
>
> Signed-off-by: Biao Huang <biao.huang at mediatek.com>

This patch applied for fixes. I see now that it was part of the
mt2701 patch set, so sorry for missing it...

Yours,
Linus Walleij


From linus.walleij at linaro.org  Fri Feb  5 05:58:28 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 5 Feb 2016 14:58:28 +0100
Subject: [PATCH 2/2] pinctrl: mediatek: Add gpio_request_enable support
In-Reply-To: <1454462686-770-3-git-send-email-biao.huang@mediatek.com>
References: <1454462686-770-1-git-send-email-biao.huang@mediatek.com>
 <1454462686-770-3-git-send-email-biao.huang@mediatek.com>
Message-ID: <CACRpkdZPTOPfsqx34yr9-bSyg4-N_dR+beqAXjJc1NjK2xh4Jw@mail.gmail.com>

On Wed, Feb 3, 2016 at 2:24 AM, Biao Huang <biao.huang at mediatek.com> wrote:

> Implement the .gpio_request_enable() callbacks in struct pinmux_ops
> in mediatek pinctrl driver. Make sure that when gpio_request is called,
> GPIO on the pin is enabled.
>
> Signed-off-by: Biao Huang <biao.huang at mediatek.com>

Patch applied to my devel-mt2701 branch.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Fri Feb  5 05:59:30 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 5 Feb 2016 14:59:30 +0100
Subject: [PATCH v4 0/5] pinctrl: mediatek: add pinctrl/GPIO/EINT driver
 for mt2701
In-Reply-To: <1454018920.14802.41.camel@mhfsdcap03>
References: <1453857883-28436-1-git-send-email-biao.huang@mediatek.com>
 <CACRpkdbxpc19bdzGDUDoqseTA-TW3V8dAA4Oe+G860qTsHd-dQ@mail.gmail.com>
 <1454018920.14802.41.camel@mhfsdcap03>
Message-ID: <CACRpkdYrU3cz_Kh2J3Z=iptwmZO_nOEpweK0rDXkACDmL+eDtQ@mail.gmail.com>

On Thu, Jan 28, 2016 at 11:08 PM, biao huang <biao.huang at mediatek.com> wrote:

> Hi Linus,
>         [PATCH v4 1/5] pinctrl: mediatek: fix direction control issue
>         this patch is also a pinctrl patch, and it seems not merged in
> devel-mt2701 branch.

Sorry I screwed up.

Applied this for fixes.

Yours,
Linus Walleij


From stern at rowland.harvard.edu  Fri Feb  5 06:06:44 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Fri, 5 Feb 2016 09:06:44 -0500 (EST)
Subject: [PATCH v4 1/1] USB: core: let USB device know device node
In-Reply-To: <CAL411-oOgSYJy_cLVkGWkLbzBewKtj1jgfQqxCsjE_-3NLYcTA@mail.gmail.com>
Message-ID: <Pine.LNX.4.44L0.1602050904300.20600-100000@netrider.rowland.org>

On Fri, 5 Feb 2016, Peter Chen wrote:

> >> > @@ -508,11 +509,20 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
> >> >     dev->connect_time = jiffies;
> >> >     dev->active_duration = -jiffies;
> >> >  #endif
> >> > -   if (root_hub)   /* Root hub always ok [and always wired] */
> >> > +   if (root_hub) { /* Root hub always ok [and always wired] */
> >> >             dev->authorized = 1;
> >> > -   else {
> >> > +           dev->dev.of_node = bus->controller->of_node;
> >> > +   } else {
> >> >             dev->authorized = !!HCD_DEV_AUTHORIZED(usb_hcd);
> >> >             dev->wusb = usb_bus_is_wusb(bus) ? 1 : 0;
> >> > +
> >> > +           if (dev->dev.parent->parent == bus->controller)
> >> > +                   /* device under root hub's port */
> >> > +                   port1 = usb_hcd_find_raw_port_number(usb_hcd,
> >> > +                           port1);
> >
> > I would change the test to "if (!parent->parent)" and add {} around the
> > body (since it's 3 lines long).  Also, although this doesn't really
> > matter, you could consider putting the new code inside the previous big
> > "if" statement instead of down here at the end of the function.
> >
> 
> Sorry, Alan, I can understand using (!parent->parent) to stands for
> the device connects to the root hub port, others I can't understand.

Change it to

+		if (!parent->parent) {
+			/* device under root hub's port */
+			port1 = usb_hcd_find_raw_port_number(usb_hcd,
+				port1);
+		}

That is, add braces { }.
          
If you look at the whole usb_alloc_dev() function, you'll see it has
one big "if" statement and then a small "if" statement near the end.  
You added your new code to the small "if" statement; I'm suggesting you
add it into the big "if" statement instead.

Alan Stern



From ard.biesheuvel at linaro.org  Fri Feb  5 06:09:49 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 5 Feb 2016 15:09:49 +0100
Subject: [PATCH] PCI: generic: map config window in one go
In-Reply-To: <1507671.sEYIrU8dv6@wuerfel>
References: <1454077035-23872-1-git-send-email-ard.biesheuvel@linaro.org>
 <4090946.AhejVJy7MO@wuerfel>
 <CAKv+Gu8oZADs_FRN=p7_Nz0wXJVWVmzVNsxtzscyp7_cFAreAQ@mail.gmail.com>
 <1507671.sEYIrU8dv6@wuerfel>
Message-ID: <CAKv+Gu8aw0NepDSp_mQAuGK+2u5q40K2XGJBWhGyr4nA2E5uxw@mail.gmail.com>

On 5 February 2016 at 14:37, Arnd Bergmann <arnd at arndb.de> wrote:
> On Friday 05 February 2016 11:48:54 Ard Biesheuvel wrote:
>> On 29 January 2016 at 15:52, Arnd Bergmann <arnd at arndb.de> wrote:
>> > On Friday 29 January 2016 15:32:01 Ard Biesheuvel wrote:
>> >> On 29 January 2016 at 15:28, Will Deacon <will.deacon at arm.com> wrote:
>> >> > Hi Ard,
>> >> >
>> >> > On Fri, Jan 29, 2016 at 03:17:15PM +0100, Ard Biesheuvel wrote:
>> >> >> Instead of iterating over the PCI config window and performing individual
>> >> >> ioremap() calls on all the adjacent slices, perform a single ioremap() to
>> >> >> map the entire region, and divvy it up later. This not only prevents
>> >> >> leaving some of it mapped if we fail half way through, it also ensures that
>> >> >> archs that support huge-vmap can use section mappings to perform the
>> >> >> mapping.
>> >> >>
>> >> >> On my Seattle A0 box, this transforms 128 separate 1 MB mappings that are
>> >> >> mapped down to 4 KB pages into a single 128 MB mapping using 2 MB sections,
>> >> >> saving 512 KB worth of page tables.
>> >> >>
>> >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> >> >> ---
>> >> >
>> >> > The code was written this way in response to feedback during driver review
>> >> > that we couldn't necessarily grab that much contiguous vmalloc space on
>> >> > 32-bit ARM. Unless that's changed, we probably want to to predicate this
>> >> > change on having a 64-bit arch.
>> >> >
>> >>
>> >> Ah right. How about testing for the ARCH_HAVE_HUGE_VMAP Kconfig symbol
>> >> explicitly?
>> >>
>> >
>> > Testing for 64BIT should be sufficient.
>> >
>>
>> Does it make sense to spin a v2 for this patch? Given the discussion
>> we had regarding allocating only the config regions for busses that
>> are populated, perhaps there is a better approach here?
>
> Allocating only the config regions that are actually used would
> be ideal, the problem is that you need to access the config space
> in order to know which ones are, so this is certainly a bit tricky.
>
> Are there any downsides to the x86 approach of using fixmap to
> map each patch separately during the access? It's probably a bit
> slower per access, but we don't do a lot of those accesses after
> the system is booted.
>

Yes, I guess that makes a lot more sense than ioremapping 10s to 100s
of MBs and hardly ever using them.


From sergei.shtylyov at cogentembedded.com  Fri Feb  5 06:12:40 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 5 Feb 2016 17:12:40 +0300
Subject: [PATCH v3 1/3] libahci: Implement the capability to override the
 generic ahci interrupt handler.
In-Reply-To: <1454620826-22554-2-git-send-email-stripathi@apm.com>
References: <1454620826-22554-1-git-send-email-stripathi@apm.com>
 <1454620826-22554-2-git-send-email-stripathi@apm.com>
Message-ID: <56B4ADD8.1020008@cogentembedded.com>

Hello.

On 02/05/2016 12:20 AM, suman Tripathi wrote:

> From: Suman Tripathi <stripathi at apm.com>
>
> This patch implements the capability to override the generic
> ahci interrupt handler so that the LDD drivers can implement

    AHCI.

> there own custom interrupt handler routines.

    s/there/their/.

> Signed-off-by: Suman Tripathi <stripathi at apm.com>
> ---
>   drivers/ata/ahci.h    |    2 ++
>   drivers/ata/libahci.c |   32 +++++++++++++++++++++++---------
>   2 files changed, 25 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
> index a4faa43..3d883ee 100644
> --- a/drivers/ata/ahci.h
> +++ b/drivers/ata/ahci.h
> @@ -360,6 +360,7 @@ struct ahci_host_priv {
>   	 * be overridden anytime before the host is activated.
>   	 */
>   	void			(*start_engine)(struct ata_port *ap);
> +	irqreturn_t 		(*ahci_irq_intr)(int irq, void *dev_instance);

    The 'ahci_irq_intr' name is somewhat tautological.


[...]
> diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
> index eda3cf2..5d3035a 100644
> --- a/drivers/ata/libahci.c
> +++ b/drivers/ata/libahci.c
[...]
> @@ -2504,15 +2505,28 @@ int ahci_host_activate(struct ata_host *host, struct scsi_host_template *sht)
>   	struct ahci_host_priv *hpriv = host->private_data;
>   	int irq = hpriv->irq;
>   	int rc;
> +	irqreturn_t (*ahci_irq_handler)(int irq, void *dev_instance);
>
> -	if (hpriv->flags & (AHCI_HFLAG_MULTI_MSI | AHCI_HFLAG_MULTI_MSIX))
> -		rc = ahci_host_activate_multi_irqs(host, sht);
> -	else if (hpriv->flags & AHCI_HFLAG_EDGE_IRQ)
> -		rc = ata_host_activate(host, irq, ahci_single_edge_irq_intr,
> -				       IRQF_SHARED, sht);
> -	else
> -		rc = ata_host_activate(host, irq, ahci_single_level_irq_intr,
> -				       IRQF_SHARED, sht);
> +	ahci_irq_handler = hpriv->ahci_irq_intr;
> +
> +	if (hpriv->flags & (AHCI_HFLAG_MULTI_MSI | AHCI_HFLAG_MULTI_MSIX)) {
> +		if (!ahci_irq_handler)
> +			rc = ahci_host_activate_multi_irqs(host, sht);
> +		else
> +			dev_warn(host->dev, "both AHCI_HFLAG_MULTI_MSI flag set \
> +				 and custom irq handler implemented\n");
> +
> +	} else {
> +		if (!ahci_irq_handler) {

    Why not *else* *if* on a single line?

[...]

MBR, Sergei



From arnd at arndb.de  Fri Feb  5 06:15:16 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 05 Feb 2016 15:15:16 +0100
Subject: [PATCH 4/4] ARM: davinci: make I2C support optional
In-Reply-To: <56B4A19D.4060307@ti.com>
References: <1454358962-640598-1-git-send-email-arnd@arndb.de>
 <1454358962-640598-5-git-send-email-arnd@arndb.de> <56B4A19D.4060307@ti.com>
Message-ID: <5475182.6SLDQGvbZt@wuerfel>

On Friday 05 February 2016 18:50:29 Sekhar Nori wrote:
> > I checked that CONFIG_I2C is still enabled with davinci_all_defconfig,
> > so that does not have to change.
> > 
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > Fixes: 45b146d746ea ("ARM: Davinci: Fix I2C build errors")
> > Fixes: 22ca466847ad ("davinci: kconfig: select at24 eeprom for selected boards")
> 
> This looks good to me. The #ifdefs in the middle of davinci_evm_init()
> are an eyesore, but getting rid of the selects is a big plus.
> 

I agree on the eyesore. I had an earlier version using "if (IS_BUILTIN(CONFIG_I2C))"
checks that was much nicer, but it didn't work because all the declarations
in include/linux/i2c.h are hidden behind an #ifdef.

I thought about sending a patch for that file too, but I think it has come up
before and was nacked then.

	Arnd


From stefano.stabellini at eu.citrix.com  Fri Feb  5 06:15:18 2016
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 5 Feb 2016 14:15:18 +0000
Subject: [PATCH v4 16/17] FDT: Add a helper to get specified name subnode
In-Reply-To: <1454641552-12576-17-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
 <1454641552-12576-17-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <alpine.DEB.2.02.1602051415120.27008@kaball.uk.xensource.com>

On Fri, 5 Feb 2016, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
> 
> Sometimes it needs to check if there is a node in FDT by full path.
> Introduce this helper to get the specified name subnode if it exists.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>

Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>


> CC: Rob Herring <robh at kernel.org>
> ---
>  drivers/of/fdt.c       | 25 +++++++++++++++++++++++++
>  include/linux/of_fdt.h |  2 ++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 655f79d..eacb188 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -645,6 +645,31 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,
>  }
>  
>  /**
> + * of_get_flat_dt_subnode_by_name - get subnode of specified node by name
> + *
> + * @node: the parent node
> + * @uname: the name of subnode
> + * @return offset of the subnode, or -FDT_ERR_NOTFOUND if there is none
> + */
> +
> +int of_get_flat_dt_subnode_by_name(unsigned long node, const char *uname)
> +{
> +	const void *blob = initial_boot_params;
> +	int offset;
> +	const char *pathp;
> +
> +	for (offset = fdt_first_subnode(blob, node);
> +	     offset >= 0;
> +	     offset = fdt_next_subnode(blob, offset)) {
> +		pathp = fdt_get_name(blob, offset, NULL);
> +		if (strcmp(pathp, uname) == 0)
> +			return offset;
> +	}
> +
> +	return -FDT_ERR_NOTFOUND;
> +}
> +
> +/**
>   * of_get_flat_dt_root - find the root node in the flat blob
>   */
>  unsigned long __init of_get_flat_dt_root(void)
> diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
> index df9ef38..fc28162 100644
> --- a/include/linux/of_fdt.h
> +++ b/include/linux/of_fdt.h
> @@ -52,6 +52,8 @@ extern char __dtb_end[];
>  extern int of_scan_flat_dt(int (*it)(unsigned long node, const char *uname,
>  				     int depth, void *data),
>  			   void *data);
> +extern int of_get_flat_dt_subnode_by_name(unsigned long node,
> +					  const char *uname);
>  extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
>  				       int *size);
>  extern int of_flat_dt_is_compatible(unsigned long node, const char *name);
> -- 
> 2.0.4
> 
> 


From james.morse at arm.com  Fri Feb  5 06:18:18 2016
From: james.morse at arm.com (James Morse)
Date: Fri, 05 Feb 2016 14:18:18 +0000
Subject: [PATCH v4 00/13] arm64: kernel: Add support for
 hibernate/suspend-to-disk
In-Reply-To: <7hmvrid3pv.fsf@baylibre.com>
References: <1453977766-20907-1-git-send-email-james.morse@arm.com>	<7hvb6chv5e.fsf@baylibre.com>
 <56AF1D07.3000604@arm.com> <7hmvrid3pv.fsf@baylibre.com>
Message-ID: <56B4AF2A.2070503@arm.com>

Hi Kevin,

On 03/02/16 00:42, Kevin Hilman wrote:
> James Morse <james.morse at arm.com> writes:
>> On 29/01/16 22:34, Kevin Hilman wrote:
>>> James Morse <james.morse at arm.com> writes:
>>> I'd like to help in testing this so I'm just curious which platforms
>>> you've been testing this on.  I'm assuming a Juno (r2?), anything else?
>>
>> That would be great - thanks!
>>
>> I've done most of the testing on a Juno r1, but also gave it a spin on a
>> stray Seattle.
> 
> OK, I'm using a very recently arrived Juno R2, and I did get it
> working.  I have a few other arm64 boards around that ar part of
> kernelci.org and will try those as well.

Great,
It would be good to have a Tested-by if it works to your satisfaction...


Thanks,

James


From mark.rutland at arm.com  Fri Feb  5 06:20:30 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 5 Feb 2016 14:20:30 +0000
Subject: [PATCHv2 2/3] arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
In-Reply-To: <1454615017-24672-3-git-send-email-labbott@fedoraproject.org>
References: <1454615017-24672-1-git-send-email-labbott@fedoraproject.org>
 <1454615017-24672-3-git-send-email-labbott@fedoraproject.org>
Message-ID: <20160205142029.GC19614@leverpostej>

On Thu, Feb 04, 2016 at 11:43:36AM -0800, Laura Abbott wrote:
> 
> ARCH_SUPPORTS_DEBUG_PAGEALLOC provides a hook to map and unmap
> pages for debugging purposes. This requires memory be mapped
> with PAGE_SIZE mappings since breaking down larger mappings
> at runtime will lead to TLB conflicts. Check if debug_pagealloc
> is enabled at runtime and if so, map everyting with PAGE_SIZE
> pages. Implement the functions to actually map/unmap the
> pages at runtime.
> 
> Signed-off-by: Laura Abbott <labbott at fedoraproject.org>

I've given this a spin on Juno, with and without the config option
selected, and with and without the command line option. I've also given
it a spin on Seattle with inline KASAN also enabled.

I wasn't sure how to deliberately trigger a failure, but those all
booted fine, and the dumepd page tables looks right, so FWIW:

Tested-by: Mark Rutland <mark.rutland at arm.com>

I have a few minor comments below, and with those fixed up:

Reviewed-by: Mark Rutland <mark.rutland at arm.com>

> ---
>  arch/arm64/Kconfig       |  3 +++
>  arch/arm64/mm/mmu.c      | 25 +++++++++++++++++++++----
>  arch/arm64/mm/pageattr.c | 46 ++++++++++++++++++++++++++++++++++++----------
>  3 files changed, 60 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 8cc6228..0f33218 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -537,6 +537,9 @@ config HOTPLUG_CPU
>  source kernel/Kconfig.preempt
>  source kernel/Kconfig.hz
>  
> +config ARCH_SUPPORTS_DEBUG_PAGEALLOC
> +	def_bool y
> +
>  config ARCH_HAS_HOLES_MEMORYMODEL
>  	def_bool y if SPARSEMEM
>  
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index ef0d66c..be81a59 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -180,8 +180,14 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
>  	pmd = pmd_set_fixmap_offset(pud, addr);
>  	do {
>  		next = pmd_addr_end(addr, end);
> -		/* try section mapping first */
> -		if (((addr | next | phys) & ~SECTION_MASK) == 0) {
> +		/*
> +		 * try a section mapping first
> +		 *
> +		 * See comment in use_1G_block for why we need the check
> +		 * for !pgtable_alloc with !debug_pagealloc
> +		 */
> +		if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
> +		      (!debug_pagealloc_enabled() || !pgtable_alloc)) {
>  			pmd_t old_pmd =*pmd;
>  			set_pmd(pmd, __pmd(phys |
>  					   pgprot_val(mk_sect_prot(prot))));
> @@ -208,8 +214,19 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
>  }
>  
>  static inline bool use_1G_block(unsigned long addr, unsigned long next,
> -			unsigned long phys)
> +			unsigned long phys, phys_addr_t (*pgtable_alloc)(void))
>  {
> +	/*
> +	 * If debug_page_alloc is enabled we don't want to be using sections
> +	 * since everything needs to be mapped with pages. The catch is
> +	 * that we only want to force pages if we can allocate the next
> +	 * layer of page tables. If there is no pgtable_alloc function,
> +	 * it's too early to allocate another layer and we should use
> +	 * section mappings.
> +	 */

I'm not sure this quite captures the rationale, as we only care about
the linear map using pages (AFAIK), and the earliness only matters
w.r.t. the DTB mapping. How about:

	/*
	 * If debug_page_alloc is enabled we must map the linear map
	 * using pages. However, other mappings created by
	 * create_mapping_noalloc must use sections in some cases. Allow
	 * sections to be used in those cases, where no pgtable_alloc
	 * function is provided.
	 */

Does that sound ok to you?

As a future optimisation, I think we can allow sections when mapping
permanent kernel chunks (.e.g .rodata and .text), as these shouldn't
contain pages available for dynamic allocation. That would require using
something other than the presence of pgtable_alloc to determine when we
should force page usage.

> +	if (pgtable_alloc && debug_pagealloc_enabled())
> +		return false;
> +
>  	if (PAGE_SHIFT != 12)
>  		return false;
>  
> @@ -241,7 +258,7 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
>  		/*
>  		 * For 4K granule only, attempt to put down a 1GB block
>  		 */
> -		if (use_1G_block(addr, next, phys)) {
> +		if (use_1G_block(addr, next, phys, pgtable_alloc)) {
>  			pud_t old_pud = *pud;
>  			set_pud(pud, __pud(phys |
>  					   pgprot_val(mk_sect_prot(prot))));
> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
> index 1360a02..57877af 100644
> --- a/arch/arm64/mm/pageattr.c
> +++ b/arch/arm64/mm/pageattr.c
> @@ -37,14 +37,31 @@ static int change_page_range(pte_t *ptep, pgtable_t token, unsigned long addr,
>  	return 0;
>  }
>  
> +/*
> + * This function assumes that the range is mapped with PAGE_SIZE pages.
> + */
> +static int __change_memory_common(unsigned long start, unsigned long size,
> +				pgprot_t set_mask, pgprot_t clear_mask)
> +{
> +	struct page_change_data data;
> +	int ret;
> +
> +	data.set_mask = set_mask;
> +	data.clear_mask = clear_mask;
> +
> +	ret = apply_to_page_range(&init_mm, start, size, change_page_range,
> +					&data);
> +
> +	flush_tlb_kernel_range(start, start+size);

Nit: spaces around '+' please.

> +	return ret;
> +}
> +
>  static int change_memory_common(unsigned long addr, int numpages,
>  				pgprot_t set_mask, pgprot_t clear_mask)
>  {
>  	unsigned long start = addr;
>  	unsigned long size = PAGE_SIZE*numpages;
>  	unsigned long end = start + size;
> -	int ret;
> -	struct page_change_data data;
>  	struct vm_struct *area;
>  
>  	if (!PAGE_ALIGNED(addr)) {
> @@ -72,14 +89,7 @@ static int change_memory_common(unsigned long addr, int numpages,
>  	    !(area->flags & VM_ALLOC))
>  		return -EINVAL;
>  
> -	data.set_mask = set_mask;
> -	data.clear_mask = clear_mask;
> -
> -	ret = apply_to_page_range(&init_mm, start, size, change_page_range,
> -					&data);
> -
> -	flush_tlb_kernel_range(start, end);
> -	return ret;
> +	return __change_memory_common(start, size, set_mask, clear_mask);
>  }
>  
>  int set_memory_ro(unsigned long addr, int numpages)
> @@ -111,3 +121,19 @@ int set_memory_x(unsigned long addr, int numpages)
>  					__pgprot(PTE_PXN));
>  }
>  EXPORT_SYMBOL_GPL(set_memory_x);
> +
> +#ifdef CONFIG_DEBUG_PAGEALLOC
> +void __kernel_map_pages(struct page *page, int numpages, int enable)
> +{
> +	unsigned long addr = (unsigned long) page_address(page);
> +
> +	if (enable)
> +		__change_memory_common(addr, PAGE_SIZE*numpages,
> +					__pgprot(PTE_VALID),
> +					__pgprot(0));
> +	else
> +		__change_memory_common(addr, PAGE_SIZE*numpages,
> +					__pgprot(0),
> +					__pgprot(PTE_VALID));

Nit: spaces around each '*' here, please.

Thanks,
Mark.

> +}
> +#endif
> -- 
> 2.5.0
> 


From sudeep.holla at arm.com  Fri Feb  5 06:30:18 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Fri, 5 Feb 2016 14:30:18 +0000
Subject: [QUESTION ]ARM64 external L3 cache support in topology info
In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA8172E13A4@lhreml504-mbs>
References: <5FC3163CFD30C246ABAA99954A238FA8172E13A4@lhreml504-mbs>
Message-ID: <56B4B1FA.5030309@arm.com>



On 05/02/16 12:04, Shameerali Kolothum Thodi wrote:
> Hi,
>
> This is a query to get the external L3 cache included in the cache
> topology info. ARM64 kernel now has the cache topology info added
> based on the patch here [1].
>
> 1. http://permalink.gmane.org/gmane.linux.ports.arm.kernel/383628
>

[..]

>
> We have a ARM64 board(Hisilicon D02) and it has got an external L3 cache.
> As per my understanding after talking to our SoC guys, this cache is not
> integrated into the processor and is not visible in (CLIDR) register.
> But this looks to be fine as per the Programmer's Guide for ARMv8-A.
>
> "The CLIDR register is only aware of how many levels of cache are
> integrated into the processor itself. It cannot provide information
> about any caches in the external memory system. For example, if
> only L1 and L2 are integrated, CLIDR/CLIDR_EL1 identifies two levels
> of cache and the processor is unaware of any external L3 cache.
> It might be necessary to take into account non-integrated caches
> when performing cache maintenance, or code that is maintaining
> coherency with integrated caches."
>

Understood.

[..]

>
> In our case, the L3 cache seems to be intelligent enough and doesn't
> require any additional maintenance ops. So there is no cache-controller
> code for this. I am just wondering what's the best way to add this L3
> cache info to the topology. Overriding the CLIDR register, if there is
> a next-level-cache entry in the dts and then retrieve the cache geometry
> either from dts or from cache specific registers( but this will be
> implementation specific) ? Or am I missing something here?
>

Recent discussion on this [1] made it clear that we need to support
overriding cache properties using DT for some designs. I will consider
this "transparent" external/system level cache when I look into moving
PPC DT code in generic cacheinfo. I am not sure if it's OK to support
mixed information source for a platform(all internal caches via CLIDR
and external ones via DT), but we can pick up discussion once we I have
the patch.

-- 
Regards,
Sudeep

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/381758.html


From arnd at arndb.de  Fri Feb  5 06:30:19 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 05 Feb 2016 15:30:19 +0100
Subject: [PATCH V2 6/6] coresight-stm: adding driver for CoreSight STM
 component
In-Reply-To: <87h9hn5msz.fsf@ashishki-desk.ger.corp.intel.com>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
 <1454487337-30184-7-git-send-email-zhang.chunyan@linaro.org>
 <87h9hn5msz.fsf@ashishki-desk.ger.corp.intel.com>
Message-ID: <1481791.6NqBhgWcKU@wuerfel>

On Friday 05 February 2016 15:06:20 Alexander Shishkin wrote:
> Chunyan Zhang <zhang.chunyan at linaro.org> writes:
> 
> > +#ifndef CONFIG_64BIT
> > +static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
> > +{
> > +     asm volatile("strd %1, %0"
> > +                  : "+Qo" (*(volatile u64 __force *)addr)
> > +                  : "r" (val));
> > +}
> 
> Is it really ok to do this for all !64bit arms, inside a driver, just
> like that? I'm not an expert, but I'm pretty sure there's more to it.

It's normally device dependent whether this works or not, on 32-bit
architectures, a 64-bit access to an I/O bus tends to get split into
two 32 bit accesses and the order might not be the as what was
intended.

We have functions in include/linux/io-64-nonatomic-hi-lo.h
and include/linux/io-64-nonatomic-lo-hi.h that are meant to
do this right. Maybe the driver can be changed to use whichever
one is correct for it.

	Arnd


From maxime.ripard at free-electrons.com  Fri Feb  5 06:33:28 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Fri, 5 Feb 2016 15:33:28 +0100
Subject: [PATCH v2 1/2] regulator: Add coupled regulator
In-Reply-To: <20160121162802.GL6588@sirena.org.uk>
References: <1452605842-9317-1-git-send-email-maxime.ripard@free-electrons.com>
 <1452605842-9317-2-git-send-email-maxime.ripard@free-electrons.com>
 <20160112143100.GA14628@rob-hp-laptop>
 <20160115085734.GG4581@lukather>
 <20160117000434.GB7774@rob-hp-laptop>
 <20160118162538.GH6588@sirena.org.uk>
 <20160121154649.GE3997@lukather>
 <20160121162802.GL6588@sirena.org.uk>
Message-ID: <20160205143328.GD31506@lukather>

Hi Mark,

On Thu, Jan 21, 2016 at 04:28:02PM +0000, Mark Brown wrote:
> On Thu, Jan 21, 2016 at 04:46:49PM +0100, Maxime Ripard wrote:
> 
> > I guess a separate driver would make it easier to deal with cases like
> > the one you suggested (shutting down when the load is going to be
> > lower). I don't see how we could have a good DT representation of that
> > if we're going to use lists.
> 
> We can have a driver regardless of what the DT looks like, it's a
> question of how things get instantiated.
> 
> > Anyway, I'm fine with both approaches, just let me know what you
> > prefer.
> 
> Without seeing an implementation of the lists it's hard to say.

Just to make sure we're on the same page: you want to keep the
regulator, but instead of giving the parent through vinX-supplies
properties, you want to have a single *-supply property, with a list
of regulators, right?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160205/72f96a81/attachment.sig>

From mark.rutland at arm.com  Fri Feb  5 06:34:04 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 5 Feb 2016 14:34:04 +0000
Subject: [PATCHv3 3/3] arm64: ptdump: Indicate whether memory should be
 faulting
In-Reply-To: <1454615017-24672-4-git-send-email-labbott@fedoraproject.org>
References: <1454615017-24672-1-git-send-email-labbott@fedoraproject.org>
 <1454615017-24672-4-git-send-email-labbott@fedoraproject.org>
Message-ID: <20160205143403.GD19614@leverpostej>

On Thu, Feb 04, 2016 at 11:43:37AM -0800, Laura Abbott wrote:
> 
> With CONFIG_DEBUG_PAGEALLOC, pages do not have the valid bit
> set when free in the buddy allocator. Add an indiciation to
> the page table dumping code that the valid bit is not set,
> 'F' for fault, to make this easier to understand.
> 
> Signed-off-by: Laura Abbott <labbott at fedoraproject.org>

This looks sensible to me, and worked in testing.

Reviewed-by: Mark Rutland <mark.rutland at arm.com>
Tested-by: Mark Rutland <mark.rutland at arm.com>

Mark.

> ---
>  arch/arm64/mm/dump.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index 5a22a11..f381ac9 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -90,6 +90,11 @@ struct prot_bits {
>  
>  static const struct prot_bits pte_bits[] = {
>  	{
> +		.mask	= PTE_VALID,
> +		.val	= PTE_VALID,
> +		.set	= " ",
> +		.clear	= "F",
> +	}, {
>  		.mask	= PTE_USER,
>  		.val	= PTE_USER,
>  		.set	= "USR",
> -- 
> 2.5.0
> 


From ivo.g.dimitrov.75 at gmail.com  Fri Feb  5 06:37:08 2016
From: ivo.g.dimitrov.75 at gmail.com (Ivaylo Dimitrov)
Date: Fri,  5 Feb 2016 16:37:08 +0200
Subject: [PATCH] ARM: OMAP2+: Fix onenand initialization to avoid filesystem
 corruption
In-Reply-To: <linux-kernel@vger.kernel.org>
References: <linux-kernel@vger.kernel.org>
Message-ID: <1454683028-4193-1-git-send-email-ivo.g.dimitrov.75@gmail.com>

Commit <e7b11dc7b77bfce0a351230a5feeadc1d0bba997> ("ARM: OMAP2+: Fix
onenand rate detection to avoid filesystem corruption") partially fixed
onenand configuration when GPMC module is reset. Finish the job by also
providing the correct values in ONENAND_REG_SYS_CFG1 register.

Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com>
---
 arch/arm/mach-omap2/gpmc-onenand.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
index 7b76ce0..8633c70 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -101,10 +101,8 @@ static void omap2_onenand_set_async_mode(void __iomem *onenand_base)
 
 static void set_onenand_cfg(void __iomem *onenand_base)
 {
-	u32 reg;
+	u32 reg = ONENAND_SYS_CFG1_RDY | ONENAND_SYS_CFG1_INT;
 
-	reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
-	reg &= ~((0x7 << ONENAND_SYS_CFG1_BRL_SHIFT) | (0x7 << 9));
 	reg |=	(latency << ONENAND_SYS_CFG1_BRL_SHIFT) |
 		ONENAND_SYS_CFG1_BL_16;
 	if (onenand_flags & ONENAND_FLAG_SYNCREAD)
@@ -123,6 +121,7 @@ static void set_onenand_cfg(void __iomem *onenand_base)
 		reg |= ONENAND_SYS_CFG1_VHF;
 	else
 		reg &= ~ONENAND_SYS_CFG1_VHF;
+
 	writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
 }
 
@@ -289,6 +288,7 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base)
 		}
 	}
 
+	onenand_async.sync_write = true;
 	omap2_onenand_calc_async_timings(&t);
 
 	ret = gpmc_cs_program_settings(gpmc_onenand_data->cs, &onenand_async);
-- 
1.9.1



From linux at roeck-us.net  Fri Feb  5 06:42:42 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Fri, 5 Feb 2016 06:42:42 -0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <CADyBb7unAHEOMfruWS82RkHK6uwPAWCxUx9jqzSkiHU4LHDSeA@mail.gmail.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
 <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
 <56B2DEE4.7060901@roeck-us.net>
 <CADyBb7unAHEOMfruWS82RkHK6uwPAWCxUx9jqzSkiHU4LHDSeA@mail.gmail.com>
Message-ID: <56B4B4E2.40105@roeck-us.net>

On 02/05/2016 01:51 AM, Fu Wei wrote:
> Hi Guenter,
>
> On 4 February 2016 at 13:17, Guenter Roeck <linux at roeck-us.net> wrote:
>> On 02/03/2016 03:00 PM, Fu Wei wrote:
>>>
>>> On 4 February 2016 at 02:45, Timur Tabi <timur at codeaurora.org> wrote:
>>>>
>>>> Fu Wei wrote:
>>>>>
>>>>>
>>>>> As you know I have made the pre-timeout support patch, If people like
>>>>> it, i am happy to go on upstream it separately.
>>>>>
>>>>> If we want to use pre-timeout here, user only can use get_pretimeout
>>>>> and disable panic by setting pretimeout to 0
>>>>> but user can not really set pretimeout, because "pre-timeout  ==
>>>>> timeout / 2 (always)".
>>>>> if user want to change pretimeout, he/she has to set_time instead.
>>>>
>>>>
>>>>
>>>> Ok, I think patches 4 and 5 should be combined, and I think the Kconfig
>>>> entry should be removed and just use panic_enabled.
>>
>>
>> Agreed.
>
> np, will do
>
>>>
>>>
>>> NP, will update this patchset like that ,  thanks :-)
>>>
>>
>> Also, if panic is enabled, the timeout needs to be adjusted accordingly
>> (to only panic after the entire timeout period has expired, not after
>> half of it). We can not panic the system after timeout / 2.
>
> OK, my thought is
>
> if panic is enabled :
> |--------WOR-------WS0--------WOR-------WS1
> |------timeout------(panic)------timeout-----reset
>
> if panic is disabled .
> |--------WOR-------WS0--------WOR-------WS1
> |---------------------timeout---------------------reset
>
>   panic_enabled only can be configured when module is loaded by module parameter
>
> But user should know that max_timeout(panic_enable) =
> max_timeout(panic_disable) / 2
>

That means you'll have to update max_timeout accordingly.

>>
>> I am not too happy with the parameter name (panic_enabled). How about
>> "action", to match machzwd ?
>
> yes, makes sense. Maybe we can do something  like this:
>
> /*
>   * action refers to action taken when watchdog gets WS0
>   * 0 = SKIP
>   * 1 = PANIC
>   * defaults to SKIP (0)
>   */
> static int action;
> module_param(action, int, 0);
> MODULE_PARM_DESC(action, "after watchdog gets WS0 interrupt, do: "
> "0 = SKIP(*)  1 = PANIC");
>
Yes, though I would suggest to use lower case letters.

Thanks,
Guenter



From ivo.g.dimitrov.75 at gmail.com  Fri Feb  5 06:43:54 2016
From: ivo.g.dimitrov.75 at gmail.com (Ivaylo Dimitrov)
Date: Fri, 5 Feb 2016 16:43:54 +0200
Subject: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
In-Reply-To: <20160205061021.GS19432@atomide.com>
References: <20160108022619.GS12777@atomide.com> <568F4596.8020206@gmail.com>
 <20160108075913.GN11364@pali> <569052FE.1040008@gmail.com>
 <20160121091437.GT7192@pali> <56B077D4.3030902@gmail.com>
 <20160202233911.GB19432@atomide.com> <20160203000045.GE19432@atomide.com>
 <56B1A654.1060905@gmail.com> <56B22FC3.3050900@gmail.com>
 <20160205061021.GS19432@atomide.com>
Message-ID: <56B4B52A.4060102@gmail.com>



On  5.02.2016 08:10, Tony Lindgren wrote:

> This seems to fix things here for legacy booting and booting the
> maemo zImage after dts image. Care to give it a try?
>
> Basically onenand after reset is in wrong state, have not looked
> up the bits yet. Will post a better patch when I get a chance
> over next few days.
>
> Regards,
>
> Tony

Yep, that looks to fix the things, I submitted a patch "[PATCH] ARM: 
OMAP2+: Fix onenand initialization to avoid filesystem corruption" (it 
was supposed to be a reply to this mail, but my git-send-mail-fu failed 
on me as always :) )

Thanks,
Ivo


From linus.walleij at linaro.org  Fri Feb  5 06:44:42 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 5 Feb 2016 15:44:42 +0100
Subject: [PATCH 3/3] thermal: allow u8500-thermal driver to be a module
In-Reply-To: <1453740264-1972562-4-git-send-email-arnd@arndb.de>
References: <1453740264-1972562-1-git-send-email-arnd@arndb.de>
 <1453740264-1972562-4-git-send-email-arnd@arndb.de>
Message-ID: <CACRpkdYUERZwbEi6cP=heVk+nzcsrG=evE=AsrOL7onf7bYX-A@mail.gmail.com>

On Mon, Jan 25, 2016 at 5:44 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> When the thermal subsystem is a loadable module, the u8500 driver
> fails to build:
>
> drivers/thermal/built-in.o: In function `db8500_thermal_probe':
> db8500_thermal.c:(.text+0x96c): undefined reference to `thermal_zone_device_register'
> drivers/thermal/built-in.o: In function `db8500_thermal_work':
> db8500_thermal.c:(.text+0xab4): undefined reference to `thermal_zone_device_update'
>
> This changes the symbol to a tristate, so Kconfig can track the
> dependency correctly.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From slash.tmp at free.fr  Fri Feb  5 06:49:33 2016
From: slash.tmp at free.fr (Mason)
Date: Fri, 5 Feb 2016 15:49:33 +0100
Subject: Common/typical fractional divider HW API
Message-ID: <56B4B67D.2080707@free.fr>

Hello,

AFAICT, the clk-fractional-divider driver implements the following
hardware API:

  M and N are two fields in the same register.
  DIV = M / N

Is this HW API common/typical in the embedded world?
in the PC world?


My hardware uses a slightly weird (to me) API:

  I = 0-255 (8 bits)
  F = 0-15  (4 bits)

  I = 0 => DIV = +INF
  I = 1 => DIV = 1 + F/(32-F)
  I > 1 => DIV = I + F/16

Is this HW API common/typical in the embedded world?
(Perhaps just the linear part for I > 1)

I see two downsides to this API:

1) I = 1 is a special case
2) A lot of the value space is wasted on large values.

For example, when I = 250, we don't really care about 250.0625, 250.125,
etc, or even nearby integer values, for that matter.

I think it's better to have a distribution with high density in small
values, and low density in high values (sort of like floating point).

For example:

  I = 0-15  (4 bits)
  F = 0-255 (8 bits)
  DIV = 2^I * (1 + F/256)

(We could probably even shave 2-4 bits on F.)

Are there downsides to this HW API?
Is this HW API common/typical in the embedded world?

Regards.


From kernel at tekno-soft.it  Fri Feb  5 06:59:21 2016
From: kernel at tekno-soft.it (Roberto Fichera)
Date: Fri, 5 Feb 2016 15:59:21 +0100
Subject: XIO2001 PCIe-to-PCI bridge is not detected on custom iMX6Q board
Message-ID: <56B4B8C9.8000505@tekno-soft.it>

Hi All,

I'm trying to get my custom board, based on iMX6Q SoC, to detect a TI XIO2001 PCIe-to-PCI bridge without
success up to now. PCI Kernel configuration looks

CONFIG_PCI_QUIRKS=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCI_DOMAINS_GENERIC=y
CONFIG_PCI_SYSCALL=y
CONFIG_PCI_MSI=y
CONFIG_PCI_ATS=y
CONFIG_PCI_PRI=y
CONFIG_PCI_PASID=y
CONFIG_PCIE_DW=y
CONFIG_PCI_IMX6=y
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
CONFIG_PCIEAER_INJECT=y
CONFIG_PCIEASPM=y
CONFIG_PCIEASPM_DEFAULT=y
CONFIG_PCIE_PME=y

I'm getting the log below when booting a kernel v4.4
 
[    0.236822] PCI host bridge /soc/pcie at 0x01000000 ranges:
[    0.236844]   No bus range found for /soc/pcie at 0x01000000, using [bus 00-ff]
[    0.236891]   err 0x01f00000..0x01f7ffff -> 0x01f00000
[    0.236929]    IO 0x01f80000..0x01f8ffff -> 0x00000000
[    0.237016]   MEM 0x01000000..0x01efffff -> 0x01000000
[    0.557284] *imx6q-pcie 1ffc000.pcie: phy link never came up*
[    0.557874] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[    0.557902] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.557920] pci_bus 0000:00: root bus resource [??? 0x01f00000-0x01f7ffff flags 0x0]
[    0.557995] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    0.558012] pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
[    0.558137] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[    0.558209] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[    0.558248] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[    0.558448] pci 0000:00:00.0: supports D1
[    0.558463] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[    0.559240] PCI: bus0: Fast back to back transfers disabled
[    0.559574] PCI: bus1: Fast back to back transfers enabled
[    0.559736] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
[    0.559764] pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
[    0.559786] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.560561] pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt
[    0.560591] pcie_pme 0000:00:00.0:pcie01: service driver pcie_pme loaded
[    0.561007] aer 0000:00:00.0:pcie02: service driver aer loaded
 
root at voneus-janas-imx6q:~# lspci -vvv
00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 290
        Region 0: Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        I/O behind bridge: 0000f000-00000fff
        Memory behind bridge: fff00000-000fffff
        Prefetchable memory behind bridge: fff00000-000fffff
        Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
        [virtual] Expansion ROM at 01100000 [disabled] [size=64K]
        BridgeCtl: Parity+ SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
                PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable+ 64bit+
                Address: 000000007d8b2000  Data: 0000
                Masking: 00000000  Pending: 00000000
        Capabilities: [70] Express (v2) Root Port (Slot-), MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0
                        ExtTag- RBE+
                DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <1us, L1 <8us
                        ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
                RootCap: CRSVisible-
                RootSta: PME ReqID 0000, PMEStatus- PMEPending-
                DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
                LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
        Capabilities: [100 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
        Capabilities: [140 v1] Virtual Channel
                Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
                Arb:    Fixed- WRR32- WRR64- WRR128-
                Ctrl:   ArbSelect=Fixed
                Status: InProgress-
                VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
                        Status: NegoPending+ InProgress-
        Kernel driver in use: pcieport
 
Do you have any suggestion how to solve this?

Thanks in advance,
Roberto Fichera.


From james.morse at arm.com  Fri Feb  5 06:58:45 2016
From: james.morse at arm.com (James Morse)
Date: Fri,  5 Feb 2016 14:58:45 +0000
Subject: [PATCH v2 0/5] arm64: kernel: Add support for User Access Override
Message-ID: <1454684330-892-1-git-send-email-james.morse@arm.com>

This series adds support for User Access Override (UAO; part of the ARMv8.2
Extensions[0]). When enabled, this causes the get_user() accessors to use
the unprivileged load/store instructions. When addr_limit is set to
KERNEL_DS, we set the override bit allowing privileged access.

Because the unprivileged instructions don't trip PAN, the last patch changes
which 'alternative' values are swapped in, allowing PAN to be left enabled
during get_user() and friends.

This series can be retrieved from:
git://linux-arm.org/linux-jm.git -b uao/v2

Comments welcome,

James

Since v1:
 * Moved id register definition into the boiler-plate patch.
 * Moved cpu_enable_uao() into mm/fault.c


[0] https://community.arm.com/groups/processors/blog/2016/01/05/armv8-a-architecture-evolution
[v1] https://lwn.net/Articles/674445/

James Morse (5):
  arm64: cpufeature: Change read_cpuid() to use sysreg's mrs_s macro
  arm64: add ARMv8.2 id_aa64mmfr2 boiler plate
  arm64: kernel: Add support for User Access Override
  arm64: cpufeature: Test 'matches' pointer to find the end of the list
  arm64: kernel: Don't toggle PAN on systems with UAO

 arch/arm64/Kconfig                   |  21 +++++++
 arch/arm64/include/asm/alternative.h |  72 +++++++++++++++++++++++
 arch/arm64/include/asm/cpu.h         |   1 +
 arch/arm64/include/asm/cpufeature.h  |   6 +-
 arch/arm64/include/asm/cputype.h     |  20 ++++---
 arch/arm64/include/asm/processor.h   |   1 +
 arch/arm64/include/asm/sysreg.h      |   7 +++
 arch/arm64/include/asm/thread_info.h |   6 ++
 arch/arm64/include/asm/uaccess.h     |  52 +++++++++++------
 arch/arm64/include/uapi/asm/ptrace.h |   1 +
 arch/arm64/kernel/cpufeature.c       | 107 +++++++++++++++++++++++------------
 arch/arm64/kernel/cpuinfo.c          |  55 +++++++++---------
 arch/arm64/kernel/process.c          |  20 +++++++
 arch/arm64/lib/clear_user.S          |  12 ++--
 arch/arm64/lib/copy_from_user.S      |  12 ++--
 arch/arm64/lib/copy_in_user.S        |  20 +++----
 arch/arm64/lib/copy_to_user.S        |  12 ++--
 arch/arm64/mm/context.c              |   2 +-
 arch/arm64/mm/fault.c                |  34 +++++++++--
 19 files changed, 337 insertions(+), 124 deletions(-)

-- 
2.6.2



From james.morse at arm.com  Fri Feb  5 06:58:46 2016
From: james.morse at arm.com (James Morse)
Date: Fri,  5 Feb 2016 14:58:46 +0000
Subject: [PATCH v2 1/5] arm64: cpufeature: Change read_cpuid() to use sysreg's
 mrs_s macro
In-Reply-To: <1454684330-892-1-git-send-email-james.morse@arm.com>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
Message-ID: <1454684330-892-2-git-send-email-james.morse@arm.com>

Older assemblers may not have support for newer feature registers. To get
round this, sysreg.h provides a 'mrs_s' macro that takes a register
encoding and generates the raw instruction.

Change read_cpuid() to use mrs_s in all cases so that new registers
don't have to be a special case. Including sysreg.h means we need to move
the include and definition of read_cpuid() after the #ifndef __ASSEMBLY__
to avoid syntax errors in vmlinux.lds.

Signed-off-by: James Morse <james.morse at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm64/include/asm/cpufeature.h |  2 +-
 arch/arm64/include/asm/cputype.h    | 20 +++++++------
 arch/arm64/kernel/cpufeature.c      | 58 ++++++++++++++++++-------------------
 arch/arm64/kernel/cpuinfo.c         | 54 +++++++++++++++++-----------------
 arch/arm64/mm/context.c             |  2 +-
 5 files changed, 69 insertions(+), 67 deletions(-)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 8f271b83f910..d28e8b27ee59 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -176,7 +176,7 @@ u64 read_system_reg(u32 id);
 
 static inline bool cpu_supports_mixed_endian_el0(void)
 {
-	return id_aa64mmfr0_mixed_endian_el0(read_cpuid(ID_AA64MMFR0_EL1));
+	return id_aa64mmfr0_mixed_endian_el0(read_cpuid(SYS_ID_AA64MMFR0_EL1));
 }
 
 static inline bool system_supports_mixed_endian_el0(void)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 1a5949364ed0..71eecd3c5b4e 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -32,12 +32,6 @@
 #define MPIDR_AFFINITY_LEVEL(mpidr, level) \
 	((mpidr >> MPIDR_LEVEL_SHIFT(level)) & MPIDR_LEVEL_MASK)
 
-#define read_cpuid(reg) ({						\
-	u64 __val;							\
-	asm("mrs	%0, " #reg : "=r" (__val));			\
-	__val;								\
-})
-
 #define MIDR_REVISION_MASK	0xf
 #define MIDR_REVISION(midr)	((midr) & MIDR_REVISION_MASK)
 #define MIDR_PARTNUM_SHIFT	4
@@ -77,6 +71,14 @@
 
 #ifndef __ASSEMBLY__
 
+#include <asm/sysreg.h>
+
+#define read_cpuid(reg) ({						\
+	u64 __val;							\
+	asm("mrs_s	%0, " __stringify(reg) : "=r" (__val));		\
+	__val;								\
+})
+
 /*
  * The CPU ID never changes at run time, so we might as well tell the
  * compiler that it's constant.  Use this function to read the CPU ID
@@ -84,12 +86,12 @@
  */
 static inline u32 __attribute_const__ read_cpuid_id(void)
 {
-	return read_cpuid(MIDR_EL1);
+	return read_cpuid(SYS_MIDR_EL1);
 }
 
 static inline u64 __attribute_const__ read_cpuid_mpidr(void)
 {
-	return read_cpuid(MPIDR_EL1);
+	return read_cpuid(SYS_MPIDR_EL1);
 }
 
 static inline unsigned int __attribute_const__ read_cpuid_implementor(void)
@@ -104,7 +106,7 @@ static inline unsigned int __attribute_const__ read_cpuid_part_number(void)
 
 static inline u32 __attribute_const__ read_cpuid_cachetype(void)
 {
-	return read_cpuid(CTR_EL0);
+	return read_cpuid(SYS_CTR_EL0);
 }
 #endif /* __ASSEMBLY__ */
 
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 5c90aa490a2b..a84febc40db2 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -791,35 +791,35 @@ static inline void set_sys_caps_initialised(void)
 static u64 __raw_read_system_reg(u32 sys_id)
 {
 	switch (sys_id) {
-	case SYS_ID_PFR0_EL1:		return (u64)read_cpuid(ID_PFR0_EL1);
-	case SYS_ID_PFR1_EL1:		return (u64)read_cpuid(ID_PFR1_EL1);
-	case SYS_ID_DFR0_EL1:		return (u64)read_cpuid(ID_DFR0_EL1);
-	case SYS_ID_MMFR0_EL1:		return (u64)read_cpuid(ID_MMFR0_EL1);
-	case SYS_ID_MMFR1_EL1:		return (u64)read_cpuid(ID_MMFR1_EL1);
-	case SYS_ID_MMFR2_EL1:		return (u64)read_cpuid(ID_MMFR2_EL1);
-	case SYS_ID_MMFR3_EL1:		return (u64)read_cpuid(ID_MMFR3_EL1);
-	case SYS_ID_ISAR0_EL1:		return (u64)read_cpuid(ID_ISAR0_EL1);
-	case SYS_ID_ISAR1_EL1:		return (u64)read_cpuid(ID_ISAR1_EL1);
-	case SYS_ID_ISAR2_EL1:		return (u64)read_cpuid(ID_ISAR2_EL1);
-	case SYS_ID_ISAR3_EL1:		return (u64)read_cpuid(ID_ISAR3_EL1);
-	case SYS_ID_ISAR4_EL1:		return (u64)read_cpuid(ID_ISAR4_EL1);
-	case SYS_ID_ISAR5_EL1:		return (u64)read_cpuid(ID_ISAR4_EL1);
-	case SYS_MVFR0_EL1:		return (u64)read_cpuid(MVFR0_EL1);
-	case SYS_MVFR1_EL1:		return (u64)read_cpuid(MVFR1_EL1);
-	case SYS_MVFR2_EL1:		return (u64)read_cpuid(MVFR2_EL1);
-
-	case SYS_ID_AA64PFR0_EL1:	return (u64)read_cpuid(ID_AA64PFR0_EL1);
-	case SYS_ID_AA64PFR1_EL1:	return (u64)read_cpuid(ID_AA64PFR0_EL1);
-	case SYS_ID_AA64DFR0_EL1:	return (u64)read_cpuid(ID_AA64DFR0_EL1);
-	case SYS_ID_AA64DFR1_EL1:	return (u64)read_cpuid(ID_AA64DFR0_EL1);
-	case SYS_ID_AA64MMFR0_EL1:	return (u64)read_cpuid(ID_AA64MMFR0_EL1);
-	case SYS_ID_AA64MMFR1_EL1:	return (u64)read_cpuid(ID_AA64MMFR1_EL1);
-	case SYS_ID_AA64ISAR0_EL1:	return (u64)read_cpuid(ID_AA64ISAR0_EL1);
-	case SYS_ID_AA64ISAR1_EL1:	return (u64)read_cpuid(ID_AA64ISAR1_EL1);
-
-	case SYS_CNTFRQ_EL0:		return (u64)read_cpuid(CNTFRQ_EL0);
-	case SYS_CTR_EL0:		return (u64)read_cpuid(CTR_EL0);
-	case SYS_DCZID_EL0:		return (u64)read_cpuid(DCZID_EL0);
+	case SYS_ID_PFR0_EL1:		return read_cpuid(SYS_ID_PFR0_EL1);
+	case SYS_ID_PFR1_EL1:		return read_cpuid(SYS_ID_PFR1_EL1);
+	case SYS_ID_DFR0_EL1:		return read_cpuid(SYS_ID_DFR0_EL1);
+	case SYS_ID_MMFR0_EL1:		return read_cpuid(SYS_ID_MMFR0_EL1);
+	case SYS_ID_MMFR1_EL1:		return read_cpuid(SYS_ID_MMFR1_EL1);
+	case SYS_ID_MMFR2_EL1:		return read_cpuid(SYS_ID_MMFR2_EL1);
+	case SYS_ID_MMFR3_EL1:		return read_cpuid(SYS_ID_MMFR3_EL1);
+	case SYS_ID_ISAR0_EL1:		return read_cpuid(SYS_ID_ISAR0_EL1);
+	case SYS_ID_ISAR1_EL1:		return read_cpuid(SYS_ID_ISAR1_EL1);
+	case SYS_ID_ISAR2_EL1:		return read_cpuid(SYS_ID_ISAR2_EL1);
+	case SYS_ID_ISAR3_EL1:		return read_cpuid(SYS_ID_ISAR3_EL1);
+	case SYS_ID_ISAR4_EL1:		return read_cpuid(SYS_ID_ISAR4_EL1);
+	case SYS_ID_ISAR5_EL1:		return read_cpuid(SYS_ID_ISAR4_EL1);
+	case SYS_MVFR0_EL1:		return read_cpuid(SYS_MVFR0_EL1);
+	case SYS_MVFR1_EL1:		return read_cpuid(SYS_MVFR1_EL1);
+	case SYS_MVFR2_EL1:		return read_cpuid(SYS_MVFR2_EL1);
+
+	case SYS_ID_AA64PFR0_EL1:	return read_cpuid(SYS_ID_AA64PFR0_EL1);
+	case SYS_ID_AA64PFR1_EL1:	return read_cpuid(SYS_ID_AA64PFR0_EL1);
+	case SYS_ID_AA64DFR0_EL1:	return read_cpuid(SYS_ID_AA64DFR0_EL1);
+	case SYS_ID_AA64DFR1_EL1:	return read_cpuid(SYS_ID_AA64DFR0_EL1);
+	case SYS_ID_AA64MMFR0_EL1:	return read_cpuid(SYS_ID_AA64MMFR0_EL1);
+	case SYS_ID_AA64MMFR1_EL1:	return read_cpuid(SYS_ID_AA64MMFR1_EL1);
+	case SYS_ID_AA64ISAR0_EL1:	return read_cpuid(SYS_ID_AA64ISAR0_EL1);
+	case SYS_ID_AA64ISAR1_EL1:	return read_cpuid(SYS_ID_AA64ISAR1_EL1);
+
+	case SYS_CNTFRQ_EL0:		return read_cpuid(SYS_CNTFRQ_EL0);
+	case SYS_CTR_EL0:		return read_cpuid(SYS_CTR_EL0);
+	case SYS_DCZID_EL0:		return read_cpuid(SYS_DCZID_EL0);
 	default:
 		BUG();
 		return 0;
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 212ae6361d8b..76df22272804 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -201,35 +201,35 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
 {
 	info->reg_cntfrq = arch_timer_get_cntfrq();
 	info->reg_ctr = read_cpuid_cachetype();
-	info->reg_dczid = read_cpuid(DCZID_EL0);
+	info->reg_dczid = read_cpuid(SYS_DCZID_EL0);
 	info->reg_midr = read_cpuid_id();
 
-	info->reg_id_aa64dfr0 = read_cpuid(ID_AA64DFR0_EL1);
-	info->reg_id_aa64dfr1 = read_cpuid(ID_AA64DFR1_EL1);
-	info->reg_id_aa64isar0 = read_cpuid(ID_AA64ISAR0_EL1);
-	info->reg_id_aa64isar1 = read_cpuid(ID_AA64ISAR1_EL1);
-	info->reg_id_aa64mmfr0 = read_cpuid(ID_AA64MMFR0_EL1);
-	info->reg_id_aa64mmfr1 = read_cpuid(ID_AA64MMFR1_EL1);
-	info->reg_id_aa64pfr0 = read_cpuid(ID_AA64PFR0_EL1);
-	info->reg_id_aa64pfr1 = read_cpuid(ID_AA64PFR1_EL1);
-
-	info->reg_id_dfr0 = read_cpuid(ID_DFR0_EL1);
-	info->reg_id_isar0 = read_cpuid(ID_ISAR0_EL1);
-	info->reg_id_isar1 = read_cpuid(ID_ISAR1_EL1);
-	info->reg_id_isar2 = read_cpuid(ID_ISAR2_EL1);
-	info->reg_id_isar3 = read_cpuid(ID_ISAR3_EL1);
-	info->reg_id_isar4 = read_cpuid(ID_ISAR4_EL1);
-	info->reg_id_isar5 = read_cpuid(ID_ISAR5_EL1);
-	info->reg_id_mmfr0 = read_cpuid(ID_MMFR0_EL1);
-	info->reg_id_mmfr1 = read_cpuid(ID_MMFR1_EL1);
-	info->reg_id_mmfr2 = read_cpuid(ID_MMFR2_EL1);
-	info->reg_id_mmfr3 = read_cpuid(ID_MMFR3_EL1);
-	info->reg_id_pfr0 = read_cpuid(ID_PFR0_EL1);
-	info->reg_id_pfr1 = read_cpuid(ID_PFR1_EL1);
-
-	info->reg_mvfr0 = read_cpuid(MVFR0_EL1);
-	info->reg_mvfr1 = read_cpuid(MVFR1_EL1);
-	info->reg_mvfr2 = read_cpuid(MVFR2_EL1);
+	info->reg_id_aa64dfr0 = read_cpuid(SYS_ID_AA64DFR0_EL1);
+	info->reg_id_aa64dfr1 = read_cpuid(SYS_ID_AA64DFR1_EL1);
+	info->reg_id_aa64isar0 = read_cpuid(SYS_ID_AA64ISAR0_EL1);
+	info->reg_id_aa64isar1 = read_cpuid(SYS_ID_AA64ISAR1_EL1);
+	info->reg_id_aa64mmfr0 = read_cpuid(SYS_ID_AA64MMFR0_EL1);
+	info->reg_id_aa64mmfr1 = read_cpuid(SYS_ID_AA64MMFR1_EL1);
+	info->reg_id_aa64pfr0 = read_cpuid(SYS_ID_AA64PFR0_EL1);
+	info->reg_id_aa64pfr1 = read_cpuid(SYS_ID_AA64PFR1_EL1);
+
+	info->reg_id_dfr0 = read_cpuid(SYS_ID_DFR0_EL1);
+	info->reg_id_isar0 = read_cpuid(SYS_ID_ISAR0_EL1);
+	info->reg_id_isar1 = read_cpuid(SYS_ID_ISAR1_EL1);
+	info->reg_id_isar2 = read_cpuid(SYS_ID_ISAR2_EL1);
+	info->reg_id_isar3 = read_cpuid(SYS_ID_ISAR3_EL1);
+	info->reg_id_isar4 = read_cpuid(SYS_ID_ISAR4_EL1);
+	info->reg_id_isar5 = read_cpuid(SYS_ID_ISAR5_EL1);
+	info->reg_id_mmfr0 = read_cpuid(SYS_ID_MMFR0_EL1);
+	info->reg_id_mmfr1 = read_cpuid(SYS_ID_MMFR1_EL1);
+	info->reg_id_mmfr2 = read_cpuid(SYS_ID_MMFR2_EL1);
+	info->reg_id_mmfr3 = read_cpuid(SYS_ID_MMFR3_EL1);
+	info->reg_id_pfr0 = read_cpuid(SYS_ID_PFR0_EL1);
+	info->reg_id_pfr1 = read_cpuid(SYS_ID_PFR1_EL1);
+
+	info->reg_mvfr0 = read_cpuid(SYS_MVFR0_EL1);
+	info->reg_mvfr1 = read_cpuid(SYS_MVFR1_EL1);
+	info->reg_mvfr2 = read_cpuid(SYS_MVFR2_EL1);
 
 	cpuinfo_detect_icache_policy(info);
 
diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index e87f53ff5f58..7275628ba59f 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -187,7 +187,7 @@ switch_mm_fastpath:
 
 static int asids_init(void)
 {
-	int fld = cpuid_feature_extract_field(read_cpuid(ID_AA64MMFR0_EL1), 4);
+	int fld = cpuid_feature_extract_field(read_cpuid(SYS_ID_AA64MMFR0_EL1), 4);
 
 	switch (fld) {
 	default:
-- 
2.6.2



From james.morse at arm.com  Fri Feb  5 06:58:47 2016
From: james.morse at arm.com (James Morse)
Date: Fri,  5 Feb 2016 14:58:47 +0000
Subject: [PATCH v2 2/5] arm64: add ARMv8.2 id_aa64mmfr2 boiler plate
In-Reply-To: <1454684330-892-1-git-send-email-james.morse@arm.com>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
Message-ID: <1454684330-892-3-git-send-email-james.morse@arm.com>

ARMv8.2 adds a new feature register id_aa64mmfr2. This patch adds the
cpu feature boiler plate used by the actual features in later patches.

Signed-off-by: James Morse <james.morse at arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/include/asm/cpu.h    |  1 +
 arch/arm64/include/asm/sysreg.h |  4 ++++
 arch/arm64/kernel/cpufeature.c  | 10 ++++++++++
 arch/arm64/kernel/cpuinfo.c     |  1 +
 4 files changed, 16 insertions(+)

diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
index b5e9cee4b5f8..13a6103130cd 100644
--- a/arch/arm64/include/asm/cpu.h
+++ b/arch/arm64/include/asm/cpu.h
@@ -36,6 +36,7 @@ struct cpuinfo_arm64 {
 	u64		reg_id_aa64isar1;
 	u64		reg_id_aa64mmfr0;
 	u64		reg_id_aa64mmfr1;
+	u64		reg_id_aa64mmfr2;
 	u64		reg_id_aa64pfr0;
 	u64		reg_id_aa64pfr1;
 
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 4aeebec3d882..4ef294ec49cc 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -72,6 +72,7 @@
 
 #define SYS_ID_AA64MMFR0_EL1		sys_reg(3, 0, 0, 7, 0)
 #define SYS_ID_AA64MMFR1_EL1		sys_reg(3, 0, 0, 7, 1)
+#define SYS_ID_AA64MMFR2_EL1		sys_reg(3, 0, 0, 7, 2)
 
 #define SYS_CNTFRQ_EL0			sys_reg(3, 3, 14, 0, 0)
 #define SYS_CTR_EL0			sys_reg(3, 3, 0, 0, 1)
@@ -137,6 +138,9 @@
 #define ID_AA64MMFR1_VMIDBITS_SHIFT	4
 #define ID_AA64MMFR1_HADBS_SHIFT	0
 
+/* id_aa64mmfr2 */
+#define ID_AA64MMFR2_UAO_SHIFT		4
+
 /* id_aa64dfr0 */
 #define ID_AA64DFR0_CTX_CMPS_SHIFT	28
 #define ID_AA64DFR0_WRPS_SHIFT		20
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index a84febc40db2..5b8bc98105c1 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -123,6 +123,11 @@ static struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
 	ARM64_FTR_END,
 };
 
+static struct arm64_ftr_bits ftr_id_aa64mmfr2[] = {
+	ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64MMFR2_UAO_SHIFT, 4, 0),
+	ARM64_FTR_END,
+};
+
 static struct arm64_ftr_bits ftr_ctr[] = {
 	U_ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 31, 1, 1),	/* RAO */
 	ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 28, 3, 0),
@@ -284,6 +289,7 @@ static struct arm64_ftr_reg arm64_ftr_regs[] = {
 	/* Op1 = 0, CRn = 0, CRm = 7 */
 	ARM64_FTR_REG(SYS_ID_AA64MMFR0_EL1, ftr_id_aa64mmfr0),
 	ARM64_FTR_REG(SYS_ID_AA64MMFR1_EL1, ftr_id_aa64mmfr1),
+	ARM64_FTR_REG(SYS_ID_AA64MMFR2_EL1, ftr_id_aa64mmfr2),
 
 	/* Op1 = 3, CRn = 0, CRm = 0 */
 	ARM64_FTR_REG(SYS_CTR_EL0, ftr_ctr),
@@ -408,6 +414,7 @@ void __init init_cpu_features(struct cpuinfo_arm64 *info)
 	init_cpu_ftr_reg(SYS_ID_AA64ISAR1_EL1, info->reg_id_aa64isar1);
 	init_cpu_ftr_reg(SYS_ID_AA64MMFR0_EL1, info->reg_id_aa64mmfr0);
 	init_cpu_ftr_reg(SYS_ID_AA64MMFR1_EL1, info->reg_id_aa64mmfr1);
+	init_cpu_ftr_reg(SYS_ID_AA64MMFR2_EL1, info->reg_id_aa64mmfr2);
 	init_cpu_ftr_reg(SYS_ID_AA64PFR0_EL1, info->reg_id_aa64pfr0);
 	init_cpu_ftr_reg(SYS_ID_AA64PFR1_EL1, info->reg_id_aa64pfr1);
 	init_cpu_ftr_reg(SYS_ID_DFR0_EL1, info->reg_id_dfr0);
@@ -517,6 +524,8 @@ void update_cpu_features(int cpu,
 				      info->reg_id_aa64mmfr0, boot->reg_id_aa64mmfr0);
 	taint |= check_update_ftr_reg(SYS_ID_AA64MMFR1_EL1, cpu,
 				      info->reg_id_aa64mmfr1, boot->reg_id_aa64mmfr1);
+	taint |= check_update_ftr_reg(SYS_ID_AA64MMFR2_EL1, cpu,
+				      info->reg_id_aa64mmfr2, boot->reg_id_aa64mmfr2);
 
 	/*
 	 * EL3 is not our concern.
@@ -814,6 +823,7 @@ static u64 __raw_read_system_reg(u32 sys_id)
 	case SYS_ID_AA64DFR1_EL1:	return read_cpuid(SYS_ID_AA64DFR0_EL1);
 	case SYS_ID_AA64MMFR0_EL1:	return read_cpuid(SYS_ID_AA64MMFR0_EL1);
 	case SYS_ID_AA64MMFR1_EL1:	return read_cpuid(SYS_ID_AA64MMFR1_EL1);
+	case SYS_ID_AA64MMFR2_EL1:	return read_cpuid(SYS_ID_AA64MMFR2_EL1);
 	case SYS_ID_AA64ISAR0_EL1:	return read_cpuid(SYS_ID_AA64ISAR0_EL1);
 	case SYS_ID_AA64ISAR1_EL1:	return read_cpuid(SYS_ID_AA64ISAR1_EL1);
 
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 76df22272804..966fbd52550b 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -210,6 +210,7 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
 	info->reg_id_aa64isar1 = read_cpuid(SYS_ID_AA64ISAR1_EL1);
 	info->reg_id_aa64mmfr0 = read_cpuid(SYS_ID_AA64MMFR0_EL1);
 	info->reg_id_aa64mmfr1 = read_cpuid(SYS_ID_AA64MMFR1_EL1);
+	info->reg_id_aa64mmfr2 = read_cpuid(SYS_ID_AA64MMFR2_EL1);
 	info->reg_id_aa64pfr0 = read_cpuid(SYS_ID_AA64PFR0_EL1);
 	info->reg_id_aa64pfr1 = read_cpuid(SYS_ID_AA64PFR1_EL1);
 
-- 
2.6.2



From james.morse at arm.com  Fri Feb  5 06:58:48 2016
From: james.morse at arm.com (James Morse)
Date: Fri,  5 Feb 2016 14:58:48 +0000
Subject: [PATCH v2 3/5] arm64: kernel: Add support for User Access Override
In-Reply-To: <1454684330-892-1-git-send-email-james.morse@arm.com>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
Message-ID: <1454684330-892-4-git-send-email-james.morse@arm.com>

'User Access Override' is a new ARMv8.2 feature which allows the
unprivileged load and store instructions to be overridden to behave in
the normal way.

This patch converts {get,put}_user() and friends to use ldtr*/sttr*
instructions - so that they can only access EL0 memory, then enables
UAO when fs==KERNEL_DS so that these functions can access kernel memory.

This allows user space's read/write permissions to be checked against the
page tables, instead of testing addr<USER_DS, then using the kernel's
read/write permissions.

Signed-off-by: James Morse <james.morse at arm.com>
---
 arch/arm64/Kconfig                   | 21 +++++++++++
 arch/arm64/include/asm/alternative.h | 72 ++++++++++++++++++++++++++++++++++++
 arch/arm64/include/asm/cpufeature.h  |  3 +-
 arch/arm64/include/asm/processor.h   |  1 +
 arch/arm64/include/asm/sysreg.h      |  3 ++
 arch/arm64/include/asm/thread_info.h |  6 +++
 arch/arm64/include/asm/uaccess.h     | 44 ++++++++++++++++------
 arch/arm64/include/uapi/asm/ptrace.h |  1 +
 arch/arm64/kernel/cpufeature.c       | 11 ++++++
 arch/arm64/kernel/process.c          | 20 ++++++++++
 arch/arm64/lib/clear_user.S          |  8 ++--
 arch/arm64/lib/copy_from_user.S      |  8 ++--
 arch/arm64/lib/copy_in_user.S        | 16 ++++----
 arch/arm64/lib/copy_to_user.S        |  8 ++--
 arch/arm64/mm/fault.c                | 31 +++++++++++++---
 15 files changed, 214 insertions(+), 39 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc62289a63e..63f2cca9e0ea 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -752,6 +752,27 @@ config ARM64_LSE_ATOMICS
 
 endmenu
 
+config ARM64_UAO
+	bool "Enable support for User Access Override (UAO)"
+	default y
+	help
+	 User Access Override (UAO; part of the ARMv8.2 Extensions)
+	 causes the 'unprivileged' variant of the load/store instructions to
+	 be overriden to be privileged.
+
+	 This option changes get_user() and friends to use the 'unprivileged'
+	 variant of the load/store instructions. This ensures that user-space
+	 really did have access to the supplied memory. When addr_limit is
+	 set to kernel memory the UAO bit will be set, allowing privileged
+	 access to kernel memory.
+
+	 Choosing this option will cause copy_to_user() et al to use user-space
+	 memory permissions.
+
+	 The feature is detected at runtime, the kernel will use the
+	 regular load/store instructions if the cpu does not implement the
+	 feature.
+
 endmenu
 
 menu "Boot options"
diff --git a/arch/arm64/include/asm/alternative.h b/arch/arm64/include/asm/alternative.h
index e4962f04201e..a9fc24ec1aa9 100644
--- a/arch/arm64/include/asm/alternative.h
+++ b/arch/arm64/include/asm/alternative.h
@@ -1,6 +1,8 @@
 #ifndef __ASM_ALTERNATIVE_H
 #define __ASM_ALTERNATIVE_H
 
+#include <asm/cpufeature.h>
+
 #ifndef __ASSEMBLY__
 
 #include <linux/init.h>
@@ -63,6 +65,8 @@ void apply_alternatives(void *start, size_t length);
 
 #else
 
+#include <asm/assembler.h>
+
 .macro altinstruction_entry orig_offset alt_offset feature orig_len alt_len
 	.word \orig_offset - .
 	.word \alt_offset - .
@@ -136,6 +140,74 @@ void apply_alternatives(void *start, size_t length);
 	alternative_insn insn1, insn2, cap, IS_ENABLED(cfg)
 
 
+/*
+ * Generate the assembly for UAO alternatives with exception table entries.
+ * This is complicated as there is no post-increment or pair versions of the
+ * unprivileged instructions, and USER() only works for single instructions.
+ */
+#ifdef CONFIG_ARM64_UAO
+	.macro uao_ldp l, reg1, reg2, addr, post_inc
+		alternative_if_not ARM64_HAS_UAO
+8888:			ldp	\reg1, \reg2, [\addr], \post_inc;
+8889:			nop;
+			nop;
+		alternative_else
+			ldtr	\reg1, [\addr];
+			ldtr	\reg2, [\addr, #8];
+			add	\addr, \addr, \post_inc;
+		alternative_endif
+
+		.section __ex_table,"a";
+		.align	3;
+		.quad	8888b,\l;
+		.quad	8889b,\l;
+		.previous;
+	.endm
+
+	.macro uao_stp l, reg1, reg2, addr, post_inc
+		alternative_if_not ARM64_HAS_UAO
+8888:			stp	\reg1, \reg2, [\addr], \post_inc;
+8889:			nop;
+			nop;
+		alternative_else
+			sttr	\reg1, [\addr];
+			sttr	\reg2, [\addr, #8];
+			add	\addr, \addr, \post_inc;
+		alternative_endif
+
+		.section __ex_table,"a";
+		.align	3;
+		.quad	8888b,\l;
+		.quad	8889b,\l;
+		.previous
+	.endm
+
+	.macro uao_user_alternative l, inst, alt_inst, reg, addr, post_inc
+		alternative_if_not ARM64_HAS_UAO
+8888:			\inst	\reg, [\addr], \post_inc;
+			nop;
+		alternative_else
+			\alt_inst	\reg, [\addr];
+			add		\addr, \addr, \post_inc;
+		alternative_endif
+
+		.section __ex_table,"a";
+		.align	3;
+		.quad	8888b,\l;
+		.previous
+	.endm
+#else
+	.macro uao_ldp l, reg1, reg2, addr, post_inc
+		USER(\l, ldp \reg1, \reg2, [\addr], \post_inc)
+	.endm
+	.macro uao_stp l, reg1, reg2, addr, post_inc
+		USER(\l, stp \reg1, \reg2, [\addr], \post_inc)
+	.endm
+	.macro uao_user_alternative l, inst, alt_inst, reg, addr, post_inc
+		USER(\l, \inst \reg, [\addr], \post_inc)
+	.endm
+#endif
+
 #endif  /*  __ASSEMBLY__  */
 
 /*
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index d28e8b27ee59..349e8203d16e 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -30,8 +30,9 @@
 #define ARM64_HAS_LSE_ATOMICS			5
 #define ARM64_WORKAROUND_CAVIUM_23154		6
 #define ARM64_WORKAROUND_834220			7
+#define ARM64_HAS_UAO				8
 
-#define ARM64_NCAPS				8
+#define ARM64_NCAPS				9
 
 #ifndef __ASSEMBLY__
 
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 4acb7ca94fcd..611ee4e5c89d 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -187,5 +187,6 @@ static inline void spin_lock_prefetch(const void *x)
 #endif
 
 void cpu_enable_pan(void *__unused);
+void cpu_enable_uao(void *__unused);
 
 #endif /* __ASM_PROCESSOR_H */
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 4ef294ec49cc..11378a92e50b 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -79,9 +79,12 @@
 #define SYS_DCZID_EL0			sys_reg(3, 3, 0, 0, 7)
 
 #define REG_PSTATE_PAN_IMM		sys_reg(0, 0, 4, 0, 4)
+#define REG_PSTATE_UAO_IMM		sys_reg(0, 0, 4, 0, 3)
 
 #define SET_PSTATE_PAN(x) __inst_arm(0xd5000000 | REG_PSTATE_PAN_IMM |\
 				     (!!x)<<8 | 0x1f)
+#define SET_PSTATE_UAO(x) __inst_arm(0xd5000000 | REG_PSTATE_UAO_IMM |\
+				     (!!x)<<8 | 0x1f)
 
 /* SCTLR_EL1 */
 #define SCTLR_EL1_CP15BEN	(0x1 << 5)
diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
index abd64bd1f6d9..eba8db6838af 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -85,6 +85,12 @@ static inline struct thread_info *current_thread_info(void)
 	return (struct thread_info *)sp_el0;
 }
 
+/* Access struct thread_info of another thread */
+static inline struct thread_info *get_thread_info(unsigned long thread_stack)
+{
+	return (struct thread_info *)(thread_stack & ~(THREAD_SIZE - 1));
+}
+
 #define thread_saved_pc(tsk)	\
 	((unsigned long)(tsk->thread.cpu_context.pc))
 #define thread_saved_sp(tsk)	\
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index b2ede967fe7d..f973bdce8410 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -64,6 +64,16 @@ extern int fixup_exception(struct pt_regs *regs);
 static inline void set_fs(mm_segment_t fs)
 {
 	current_thread_info()->addr_limit = fs;
+
+	/*
+	 * Enable/disable UAO so that copy_to_user() etc can access
+	 * kernel memory with the unprivileged instructions.
+	 */
+	if (IS_ENABLED(CONFIG_ARM64_UAO) && fs == KERNEL_DS)
+		asm(ALTERNATIVE("nop", SET_PSTATE_UAO(1), ARM64_HAS_UAO));
+	else
+		asm(ALTERNATIVE("nop", SET_PSTATE_UAO(0), ARM64_HAS_UAO,
+				CONFIG_ARM64_UAO));
 }
 
 #define segment_eq(a, b)	((a) == (b))
@@ -113,9 +123,10 @@ static inline void set_fs(mm_segment_t fs)
  * The "__xxx_error" versions set the third argument to -EFAULT if an error
  * occurs, and leave it unchanged on success.
  */
-#define __get_user_asm(instr, reg, x, addr, err)			\
+#define __get_user_asm(instr, alt_instr, reg, x, addr, err, feature)	\
 	asm volatile(							\
-	"1:	" instr "	" reg "1, [%2]\n"			\
+	"1:"ALTERNATIVE(instr "     " reg "1, [%2]\n",			\
+			alt_instr " " reg "1, [%2]\n", feature)		\
 	"2:\n"								\
 	"	.section .fixup, \"ax\"\n"				\
 	"	.align	2\n"						\
@@ -138,16 +149,20 @@ do {									\
 			CONFIG_ARM64_PAN));				\
 	switch (sizeof(*(ptr))) {					\
 	case 1:								\
-		__get_user_asm("ldrb", "%w", __gu_val, (ptr), (err));	\
+		__get_user_asm("ldrb", "ldtrb", "%w", __gu_val, (ptr),  \
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	case 2:								\
-		__get_user_asm("ldrh", "%w", __gu_val, (ptr), (err));	\
+		__get_user_asm("ldrh", "ldtrh", "%w", __gu_val, (ptr),  \
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	case 4:								\
-		__get_user_asm("ldr", "%w", __gu_val, (ptr), (err));	\
+		__get_user_asm("ldr", "ldtr", "%w", __gu_val, (ptr),	\
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	case 8:								\
-		__get_user_asm("ldr", "%",  __gu_val, (ptr), (err));	\
+		__get_user_asm("ldr", "ldtr", "%",  __gu_val, (ptr),	\
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	default:							\
 		BUILD_BUG();						\
@@ -181,9 +196,10 @@ do {									\
 		((x) = 0, -EFAULT);					\
 })
 
-#define __put_user_asm(instr, reg, x, addr, err)			\
+#define __put_user_asm(instr, alt_instr, reg, x, addr, err, feature)	\
 	asm volatile(							\
-	"1:	" instr "	" reg "1, [%2]\n"			\
+	"1:"ALTERNATIVE(instr "     " reg "1, [%2]\n",			\
+			alt_instr " " reg "1, [%2]\n", feature)		\
 	"2:\n"								\
 	"	.section .fixup,\"ax\"\n"				\
 	"	.align	2\n"						\
@@ -205,16 +221,20 @@ do {									\
 			CONFIG_ARM64_PAN));				\
 	switch (sizeof(*(ptr))) {					\
 	case 1:								\
-		__put_user_asm("strb", "%w", __pu_val, (ptr), (err));	\
+		__put_user_asm("strb", "sttrb", "%w", __pu_val, (ptr),	\
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	case 2:								\
-		__put_user_asm("strh", "%w", __pu_val, (ptr), (err));	\
+		__put_user_asm("strh", "sttrh", "%w", __pu_val, (ptr),	\
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	case 4:								\
-		__put_user_asm("str",  "%w", __pu_val, (ptr), (err));	\
+		__put_user_asm("str", "sttr", "%w", __pu_val, (ptr),	\
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	case 8:								\
-		__put_user_asm("str",  "%", __pu_val, (ptr), (err));	\
+		__put_user_asm("str", "sttr", "%", __pu_val, (ptr),	\
+			       (err), ARM64_HAS_UAO);			\
 		break;							\
 	default:							\
 		BUILD_BUG();						\
diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
index 208db3df135a..b5c3933ed441 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -45,6 +45,7 @@
 #define PSR_A_BIT	0x00000100
 #define PSR_D_BIT	0x00000200
 #define PSR_PAN_BIT	0x00400000
+#define PSR_UAO_BIT	0x00800000
 #define PSR_Q_BIT	0x08000000
 #define PSR_V_BIT	0x10000000
 #define PSR_C_BIT	0x20000000
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 5b8bc98105c1..06bdcd019bd6 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -660,6 +660,17 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.min_field_value = 2,
 	},
 #endif /* CONFIG_AS_LSE && CONFIG_ARM64_LSE_ATOMICS */
+#ifdef CONFIG_ARM64_UAO
+	{
+		.desc = "User Access Override",
+		.capability = ARM64_HAS_UAO,
+		.matches = has_cpuid_feature,
+		.sys_reg = SYS_ID_AA64MMFR2_EL1,
+		.field_pos = ID_AA64MMFR2_UAO_SHIFT,
+		.min_field_value = 1,
+		.enable = cpu_enable_uao,
+	},
+#endif /* CONFIG_ARM64_UAO */
 	{},
 };
 
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 88d742ba19d5..8fcf582c18d7 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -46,6 +46,7 @@
 #include <linux/notifier.h>
 #include <trace/events/power.h>
 
+#include <asm/alternative.h>
 #include <asm/compat.h>
 #include <asm/cacheflush.h>
 #include <asm/fpsimd.h>
@@ -280,6 +281,9 @@ int copy_thread(unsigned long clone_flags, unsigned long stack_start,
 	} else {
 		memset(childregs, 0, sizeof(struct pt_regs));
 		childregs->pstate = PSR_MODE_EL1h;
+		if (IS_ENABLED(CONFIG_ARM64_UAO) &&
+		    cpus_have_cap(ARM64_HAS_UAO))
+			childregs->pstate |= PSR_UAO_BIT;
 		p->thread.cpu_context.x19 = stack_start;
 		p->thread.cpu_context.x20 = stk_sz;
 	}
@@ -308,6 +312,20 @@ static void tls_thread_switch(struct task_struct *next)
 	: : "r" (tpidr), "r" (tpidrro));
 }
 
+/* Restore the UAO state depending on next's addr_limit */
+static void uao_thread_switch(struct task_struct *next)
+{
+	unsigned long next_sp = next->thread.cpu_context.sp;
+
+	if (IS_ENABLED(CONFIG_ARM64_UAO) &&
+	    get_thread_info(next_sp)->addr_limit == KERNEL_DS)
+		asm(ALTERNATIVE("nop", SET_PSTATE_UAO(1), ARM64_HAS_UAO,
+			        CONFIG_ARM64_UAO));
+	else
+		asm(ALTERNATIVE("nop", SET_PSTATE_UAO(0), ARM64_HAS_UAO,
+				CONFIG_ARM64_UAO));
+}
+
 /*
  * Thread switching.
  */
@@ -327,6 +345,8 @@ struct task_struct *__switch_to(struct task_struct *prev,
 	 */
 	dsb(ish);
 
+	uao_thread_switch(next);
+
 	/* the actual thread switch */
 	last = cpu_switch_to(prev, next);
 
diff --git a/arch/arm64/lib/clear_user.S b/arch/arm64/lib/clear_user.S
index a9723c71c52b..3f950b677c07 100644
--- a/arch/arm64/lib/clear_user.S
+++ b/arch/arm64/lib/clear_user.S
@@ -39,20 +39,20 @@ ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
 	subs	x1, x1, #8
 	b.mi	2f
 1:
-USER(9f, str	xzr, [x0], #8	)
+uao_user_alternative 9f, str, sttr, xzr, x0, 8
 	subs	x1, x1, #8
 	b.pl	1b
 2:	adds	x1, x1, #4
 	b.mi	3f
-USER(9f, str	wzr, [x0], #4	)
+uao_user_alternative 9f, str, sttr, wzr, x0, 4
 	sub	x1, x1, #4
 3:	adds	x1, x1, #2
 	b.mi	4f
-USER(9f, strh	wzr, [x0], #2	)
+uao_user_alternative 9f, strh, sttrh, wzr, x0, 2
 	sub	x1, x1, #2
 4:	adds	x1, x1, #1
 	b.mi	5f
-USER(9f, strb	wzr, [x0]	)
+uao_user_alternative 9f, strb, sttrb, wzr, x0, 0
 5:	mov	x0, #0
 ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
 	    CONFIG_ARM64_PAN)
diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
index 4699cd74f87e..1d982d64f1a7 100644
--- a/arch/arm64/lib/copy_from_user.S
+++ b/arch/arm64/lib/copy_from_user.S
@@ -34,7 +34,7 @@
  */
 
 	.macro ldrb1 ptr, regB, val
-	USER(9998f, ldrb  \ptr, [\regB], \val)
+	uao_user_alternative 9998f, ldrb, ldtrb, \ptr, \regB, \val
 	.endm
 
 	.macro strb1 ptr, regB, val
@@ -42,7 +42,7 @@
 	.endm
 
 	.macro ldrh1 ptr, regB, val
-	USER(9998f, ldrh  \ptr, [\regB], \val)
+	uao_user_alternative 9998f, ldrh, ldtrh, \ptr, \regB, \val
 	.endm
 
 	.macro strh1 ptr, regB, val
@@ -50,7 +50,7 @@
 	.endm
 
 	.macro ldr1 ptr, regB, val
-	USER(9998f, ldr \ptr, [\regB], \val)
+	uao_user_alternative 9998f, ldr, ldtr, \ptr, \regB, \val
 	.endm
 
 	.macro str1 ptr, regB, val
@@ -58,7 +58,7 @@
 	.endm
 
 	.macro ldp1 ptr, regB, regC, val
-	USER(9998f, ldp \ptr, \regB, [\regC], \val)
+	uao_ldp 9998f, \ptr, \regB, \regC, \val
 	.endm
 
 	.macro stp1 ptr, regB, regC, val
diff --git a/arch/arm64/lib/copy_in_user.S b/arch/arm64/lib/copy_in_user.S
index 81c8fc93c100..feaad1520dc1 100644
--- a/arch/arm64/lib/copy_in_user.S
+++ b/arch/arm64/lib/copy_in_user.S
@@ -35,35 +35,35 @@
  *	x0 - bytes not copied
  */
 	.macro ldrb1 ptr, regB, val
-	USER(9998f, ldrb  \ptr, [\regB], \val)
+	uao_user_alternative 9998f, ldrb, ldtrb, \ptr, \regB, \val
 	.endm
 
 	.macro strb1 ptr, regB, val
-	USER(9998f, strb \ptr, [\regB], \val)
+	uao_user_alternative 9998f, strb, sttrb, \ptr, \regB, \val
 	.endm
 
 	.macro ldrh1 ptr, regB, val
-	USER(9998f, ldrh  \ptr, [\regB], \val)
+	uao_user_alternative 9998f, ldrh, ldtrh, \ptr, \regB, \val
 	.endm
 
 	.macro strh1 ptr, regB, val
-	USER(9998f, strh \ptr, [\regB], \val)
+	uao_user_alternative 9998f, strh, sttrh, \ptr, \regB, \val
 	.endm
 
 	.macro ldr1 ptr, regB, val
-	USER(9998f, ldr \ptr, [\regB], \val)
+	uao_user_alternative 9998f, ldr, ldtr, \ptr, \regB, \val
 	.endm
 
 	.macro str1 ptr, regB, val
-	USER(9998f, str \ptr, [\regB], \val)
+	uao_user_alternative 9998f, str, sttr, \ptr, \regB, \val
 	.endm
 
 	.macro ldp1 ptr, regB, regC, val
-	USER(9998f, ldp \ptr, \regB, [\regC], \val)
+	uao_ldp 9998f, \ptr, \regB, \regC, \val
 	.endm
 
 	.macro stp1 ptr, regB, regC, val
-	USER(9998f, stp \ptr, \regB, [\regC], \val)
+	uao_stp 9998f, \ptr, \regB, \regC, \val
 	.endm
 
 end	.req	x5
diff --git a/arch/arm64/lib/copy_to_user.S b/arch/arm64/lib/copy_to_user.S
index 7512bbbc07ac..2dae2cd2c481 100644
--- a/arch/arm64/lib/copy_to_user.S
+++ b/arch/arm64/lib/copy_to_user.S
@@ -37,7 +37,7 @@
 	.endm
 
 	.macro strb1 ptr, regB, val
-	USER(9998f, strb \ptr, [\regB], \val)
+	uao_user_alternative 9998f, strb, sttrb, \ptr, \regB, \val
 	.endm
 
 	.macro ldrh1 ptr, regB, val
@@ -45,7 +45,7 @@
 	.endm
 
 	.macro strh1 ptr, regB, val
-	USER(9998f, strh \ptr, [\regB], \val)
+	uao_user_alternative 9998f, strh, sttrh, \ptr, \regB, \val
 	.endm
 
 	.macro ldr1 ptr, regB, val
@@ -53,7 +53,7 @@
 	.endm
 
 	.macro str1 ptr, regB, val
-	USER(9998f, str \ptr, [\regB], \val)
+	uao_user_alternative 9998f, str, sttr, \ptr, \regB, \val
 	.endm
 
 	.macro ldp1 ptr, regB, regC, val
@@ -61,7 +61,7 @@
 	.endm
 
 	.macro stp1 ptr, regB, regC, val
-	USER(9998f, stp \ptr, \regB, [\regC], \val)
+	uao_stp 9998f, \ptr, \regB, \regC, \val
 	.endm
 
 end	.req	x5
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 92ddac1e8ca2..820d47353cf0 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -192,6 +192,14 @@ out:
 	return fault;
 }
 
+static inline int permission_fault(unsigned int esr)
+{
+	unsigned int ec       = (esr & ESR_ELx_EC_MASK) >> ESR_ELx_EC_SHIFT;
+	unsigned int fsc_type = esr & ESR_ELx_FSC_TYPE;
+
+	return (ec == ESR_ELx_EC_DABT_CUR && fsc_type == ESR_ELx_FSC_PERM);
+}
+
 static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
 				   struct pt_regs *regs)
 {
@@ -225,12 +233,10 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
 		mm_flags |= FAULT_FLAG_WRITE;
 	}
 
-	/*
-	 * PAN bit set implies the fault happened in kernel space, but not
-	 * in the arch's user access functions.
-	 */
-	if (IS_ENABLED(CONFIG_ARM64_PAN) && (regs->pstate & PSR_PAN_BIT))
-		goto no_context;
+	if (permission_fault(esr) && (addr < USER_DS)) {
+		if (!search_exception_tables(regs->pc))
+			panic("Accessing user space memory outside uaccess.h routines");
+	}
 
 	/*
 	 * As per x86, we may deadlock here. However, since the kernel only
@@ -561,3 +567,16 @@ void cpu_enable_pan(void *__unused)
 	config_sctlr_el1(SCTLR_EL1_SPAN, 0);
 }
 #endif /* CONFIG_ARM64_PAN */
+
+#ifdef CONFIG_ARM64_UAO
+/*
+ * Kernel threads have fs=KERNEL_DS by default, and don't need to call
+ * set_fs(), devtmpfs in particular relies on this behaviour.
+ * We need to enable the feature at runtime (instead of adding it to
+ * PSR_MODE_EL1h) as the feature may not be implemented by the cpu.
+ */
+void cpu_enable_uao(void *__unused)
+{
+	asm(SET_PSTATE_UAO(1));
+}
+#endif /* CONFIG_ARM64_UAO */
-- 
2.6.2



From james.morse at arm.com  Fri Feb  5 06:58:49 2016
From: james.morse at arm.com (James Morse)
Date: Fri,  5 Feb 2016 14:58:49 +0000
Subject: [PATCH v2 4/5] arm64: cpufeature: Test 'matches' pointer to find the
 end of the list
In-Reply-To: <1454684330-892-1-git-send-email-james.morse@arm.com>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
Message-ID: <1454684330-892-5-git-send-email-james.morse@arm.com>

CPU feature code uses the desc field as a test to find the end of the list,
this means every entry must have a description. This generates noise for
entries in the list that aren't really features, but combinations of them.
e.g.
> CPU features: detected feature: Privileged Access Never
> CPU features: detected feature: PAN and not UAO

These combination features are needed for corner cases with alternatives,
where cpu features interact.

Change all walkers of the arm64_features[] and arm64_hwcaps[] lists to test
'matches' not 'desc', and only print 'desc' if it is non-NULL.

Signed-off-by: James Morse <james.morse at arm.com>
Reviewed-by : Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/kernel/cpufeature.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 06bdcd019bd6..c717c3d78f5e 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -754,7 +754,7 @@ static void __init setup_cpu_hwcaps(void)
 	int i;
 	const struct arm64_cpu_capabilities *hwcaps = arm64_hwcaps;
 
-	for (i = 0; hwcaps[i].desc; i++)
+	for (i = 0; hwcaps[i].matches; i++)
 		if (hwcaps[i].matches(&hwcaps[i]))
 			cap_set_hwcap(&hwcaps[i]);
 }
@@ -764,11 +764,11 @@ void update_cpu_capabilities(const struct arm64_cpu_capabilities *caps,
 {
 	int i;
 
-	for (i = 0; caps[i].desc; i++) {
+	for (i = 0; caps[i].matches; i++) {
 		if (!caps[i].matches(&caps[i]))
 			continue;
 
-		if (!cpus_have_cap(caps[i].capability))
+		if (!cpus_have_cap(caps[i].capability) && caps[i].desc)
 			pr_info("%s %s\n", info, caps[i].desc);
 		cpus_set_cap(caps[i].capability);
 	}
@@ -783,7 +783,7 @@ enable_cpu_capabilities(const struct arm64_cpu_capabilities *caps)
 {
 	int i;
 
-	for (i = 0; caps[i].desc; i++)
+	for (i = 0; caps[i].matches; i++)
 		if (caps[i].enable && cpus_have_cap(caps[i].capability))
 			on_each_cpu(caps[i].enable, NULL, true);
 }
@@ -890,7 +890,7 @@ void verify_local_cpu_capabilities(void)
 		return;
 
 	caps = arm64_features;
-	for (i = 0; caps[i].desc; i++) {
+	for (i = 0; caps[i].matches; i++) {
 		if (!cpus_have_cap(caps[i].capability) || !caps[i].sys_reg)
 			continue;
 		/*
@@ -903,7 +903,7 @@ void verify_local_cpu_capabilities(void)
 			caps[i].enable(NULL);
 	}
 
-	for (i = 0, caps = arm64_hwcaps; caps[i].desc; i++) {
+	for (i = 0, caps = arm64_hwcaps; caps[i].matches; i++) {
 		if (!cpus_have_hwcap(&caps[i]))
 			continue;
 		if (!feature_matches(__raw_read_system_reg(caps[i].sys_reg), &caps[i]))
-- 
2.6.2



From james.morse at arm.com  Fri Feb  5 06:58:50 2016
From: james.morse at arm.com (James Morse)
Date: Fri,  5 Feb 2016 14:58:50 +0000
Subject: [PATCH v2 5/5] arm64: kernel: Don't toggle PAN on systems with UAO
In-Reply-To: <1454684330-892-1-git-send-email-james.morse@arm.com>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
Message-ID: <1454684330-892-6-git-send-email-james.morse@arm.com>

If a CPU supports both Privileged Access Never (PAN) and User Access
Override (UAO), we don't need to disable/re-enable PAN round all
copy_to_user() like calls.

UAO alternatives cause these calls to use the 'unprivileged' load/store
instructions, which are overridden to be the privileged kind when
fs==KERNEL_DS.

This patch changes the copy_to_user() calls to have their PAN toggling
depend on a new composite 'feature' ARM64_ALT_PAN_NOT_UAO.

If both features are detected, PAN will be enabled, but the copy_to_user()
alternatives will not be applied. This means PAN will be enabled all the
time for these functions. If only PAN is detected, the toggling will be
enabled as normal.

This will save the time taken to disable/re-enable PAN, and allow us to
catch copy_to_user() accesses that occur with fs==KERNEL_DS.

Futex and swp-emulation code continue to hang their PAN toggling code on
ARM64_HAS_PAN.

Signed-off-by: James Morse <james.morse at arm.com>
---
 arch/arm64/include/asm/cpufeature.h |  3 ++-
 arch/arm64/include/asm/uaccess.h    |  8 ++++----
 arch/arm64/kernel/cpufeature.c      | 16 ++++++++++++++++
 arch/arm64/lib/clear_user.S         |  4 ++--
 arch/arm64/lib/copy_from_user.S     |  4 ++--
 arch/arm64/lib/copy_in_user.S       |  4 ++--
 arch/arm64/lib/copy_to_user.S       |  4 ++--
 arch/arm64/mm/fault.c               |  3 +++
 8 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 349e8203d16e..7ae0d90a21ed 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -31,8 +31,9 @@
 #define ARM64_WORKAROUND_CAVIUM_23154		6
 #define ARM64_WORKAROUND_834220			7
 #define ARM64_HAS_UAO				8
+#define ARM64_ALT_PAN_NOT_UAO			9
 
-#define ARM64_NCAPS				9
+#define ARM64_NCAPS				10
 
 #ifndef __ASSEMBLY__
 
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index f973bdce8410..16ba0d5c9740 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -145,7 +145,7 @@ static inline void set_fs(mm_segment_t fs)
 do {									\
 	unsigned long __gu_val;						\
 	__chk_user_ptr(ptr);						\
-	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), ARM64_HAS_PAN,	\
+	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), ARM64_ALT_PAN_NOT_UAO,\
 			CONFIG_ARM64_PAN));				\
 	switch (sizeof(*(ptr))) {					\
 	case 1:								\
@@ -168,7 +168,7 @@ do {									\
 		BUILD_BUG();						\
 	}								\
 	(x) = (__force __typeof__(*(ptr)))__gu_val;			\
-	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN,	\
+	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_ALT_PAN_NOT_UAO,\
 			CONFIG_ARM64_PAN));				\
 } while (0)
 
@@ -217,7 +217,7 @@ do {									\
 do {									\
 	__typeof__(*(ptr)) __pu_val = (x);				\
 	__chk_user_ptr(ptr);						\
-	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), ARM64_HAS_PAN,	\
+	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), ARM64_ALT_PAN_NOT_UAO,\
 			CONFIG_ARM64_PAN));				\
 	switch (sizeof(*(ptr))) {					\
 	case 1:								\
@@ -239,7 +239,7 @@ do {									\
 	default:							\
 		BUILD_BUG();						\
 	}								\
-	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN,	\
+	asm(ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_ALT_PAN_NOT_UAO,\
 			CONFIG_ARM64_PAN));				\
 } while (0)
 
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c717c3d78f5e..7ac60350eb08 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -67,6 +67,10 @@ DECLARE_BITMAP(cpu_hwcaps, ARM64_NCAPS);
 		.width = 0,				\
 	}
 
+/* meta feature for alternatives */
+static bool __maybe_unused
+cpufeature_pan_not_uao(const struct arm64_cpu_capabilities *entry);
+
 static struct arm64_ftr_bits ftr_id_aa64isar0[] = {
 	ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 32, 32, 0),
 	ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64ISAR0_RDM_SHIFT, 4, 0),
@@ -671,6 +675,12 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.enable = cpu_enable_uao,
 	},
 #endif /* CONFIG_ARM64_UAO */
+#ifdef CONFIG_ARM64_PAN
+	{
+		.capability = ARM64_ALT_PAN_NOT_UAO,
+		.matches = cpufeature_pan_not_uao,
+	},
+#endif /* CONFIG_ARM64_PAN */
 	{},
 };
 
@@ -949,3 +959,9 @@ void __init setup_cpu_features(void)
 		pr_warn("L1_CACHE_BYTES smaller than the Cache Writeback Granule (%d < %d)\n",
 			L1_CACHE_BYTES, cls);
 }
+
+static bool __maybe_unused
+cpufeature_pan_not_uao(const struct arm64_cpu_capabilities *entry)
+{
+	return (cpus_have_cap(ARM64_HAS_PAN) && !cpus_have_cap(ARM64_HAS_UAO));
+}
diff --git a/arch/arm64/lib/clear_user.S b/arch/arm64/lib/clear_user.S
index 3f950b677c07..5d1cad3ce6d6 100644
--- a/arch/arm64/lib/clear_user.S
+++ b/arch/arm64/lib/clear_user.S
@@ -33,7 +33,7 @@
  * Alignment fixed up by hardware.
  */
 ENTRY(__clear_user)
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	mov	x2, x1			// save the size for fixup return
 	subs	x1, x1, #8
@@ -54,7 +54,7 @@ uao_user_alternative 9f, strh, sttrh, wzr, x0, 2
 	b.mi	5f
 uao_user_alternative 9f, strb, sttrb, wzr, x0, 0
 5:	mov	x0, #0
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	ret
 ENDPROC(__clear_user)
diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
index 1d982d64f1a7..17e8306dca29 100644
--- a/arch/arm64/lib/copy_from_user.S
+++ b/arch/arm64/lib/copy_from_user.S
@@ -67,11 +67,11 @@
 
 end	.req	x5
 ENTRY(__copy_from_user)
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	add	end, x0, x2
 #include "copy_template.S"
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	mov	x0, #0				// Nothing to copy
 	ret
diff --git a/arch/arm64/lib/copy_in_user.S b/arch/arm64/lib/copy_in_user.S
index feaad1520dc1..f7292dd08c84 100644
--- a/arch/arm64/lib/copy_in_user.S
+++ b/arch/arm64/lib/copy_in_user.S
@@ -68,11 +68,11 @@
 
 end	.req	x5
 ENTRY(__copy_in_user)
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	add	end, x0, x2
 #include "copy_template.S"
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	mov	x0, #0
 	ret
diff --git a/arch/arm64/lib/copy_to_user.S b/arch/arm64/lib/copy_to_user.S
index 2dae2cd2c481..21faae60f988 100644
--- a/arch/arm64/lib/copy_to_user.S
+++ b/arch/arm64/lib/copy_to_user.S
@@ -66,11 +66,11 @@
 
 end	.req	x5
 ENTRY(__copy_to_user)
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	add	end, x0, x2
 #include "copy_template.S"
-ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_HAS_PAN, \
+ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(1)), ARM64_ALT_PAN_NOT_UAO, \
 	    CONFIG_ARM64_PAN)
 	mov	x0, #0
 	ret
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 820d47353cf0..d0762a729d01 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -234,6 +234,9 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
 	}
 
 	if (permission_fault(esr) && (addr < USER_DS)) {
+		if (get_thread_info(regs->sp)->addr_limit == KERNEL_DS)
+			panic("Accessing user space memory with fs=KERNEL_DS");
+
 		if (!search_exception_tables(regs->pc))
 			panic("Accessing user space memory outside uaccess.h routines");
 	}
-- 
2.6.2



From fijam at archlinux.us  Fri Feb  5 07:00:49 2016
From: fijam at archlinux.us (JM)
Date: Fri, 5 Feb 2016 16:00:49 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <20160205112907.796afb05@bbrezillon>
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
 <20160205090246.GE32272@lunn.ch> <20160205112907.796afb05@bbrezillon>
Message-ID: <CAKzmTe20fT8BcRaDaf2gz92KMAK0kEUkaD-kPq_cPF1WKBdroA@mail.gmail.com>

On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
<boris.brezillon at free-electrons.com> wrote:
> Jan, Andrew
>
> On Fri, 5 Feb 2016 10:02:46 +0100
> Andrew Lunn <andrew at lunn.ch> wrote:
>
>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>> > Hi,
>> >
>> > I am testing marvell_cesa on a kirkwood device (QNAP TS-212p, Marvell
>> > Kirkwood 88F6282, dts: http://pastebin.com/Gk95KFHf ).
>> > As of kernel 4.4 (4.4.0-trunk-kirkwood #1 Debian 4.4-1~exp1) it fails
>> > in the following way:
>> >
>> > modprobe marvell_cesa allhwsupport=1
>> > dmesg | tail -n 1
>> > [ 1057.855091] marvell-cesa: probe of f1030000.crypto failed with error -12
>> >
>> > or:
>> >
>> > modprobe marvell_cesa
>> > dmesg | tail -n 1
>> > [ 9178.399357] marvell-cesa: probe of f1030000.crypto failed with error -524
>> >
>> > With kernel 4.3 it would fail with error -22 on that hardware. There
>> > are scattered reports from other users experiencing the same issue
>> > (1,2,3)
>> >
>> > I wonder if this is a result of an invalid definition of the
>> > crypto-sram in the dts of this SoC, or perhaps some other problem
>> > (PEBKAC included).
>>
>> Hi Jan
>>
>> Do you have SRAM enabled in your kernel configuration. The
>> mvebu_v5_defconfig does not have it, which is a bug really.
>
> Hm, the CRYPTO_DEV_MARVELL_CESA option selects the SRAM one [1].
> Anyway, I also think this error is related to the SRAM (not sure why the
> driver is not able to get the SRAM though).
>
> Best Regards,
>
> Boris
>
> [1]http://lxr.free-electrons.com/source/drivers/crypto/Kconfig#L168
>
>
> --
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Hi,

Thanks for getting back to me. Indeed, CONFIG_SRAM is enabled, I put
the complete .config here: http://pastebin.com/40eKMJqE

If there is anything I can do to help squish this bug, please let me know.

Best regards,
Jan


From andriy.shevchenko at linux.intel.com  Fri Feb  5 07:05:58 2016
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 05 Feb 2016 17:05:58 +0200
Subject: Common/typical fractional divider HW API
In-Reply-To: <56B4B67D.2080707@free.fr>
References: <56B4B67D.2080707@free.fr>
Message-ID: <1454684758.31169.77.camel@linux.intel.com>

On Fri, 2016-02-05 at 15:49 +0100, Mason wrote:
> Hello,
> 
> AFAICT, the clk-fractional-divider driver implements the following
> hardware API:
> 
> ? M and N are two fields in the same register.
> ? DIV = M / N
> 
> Is this HW API common/typical in the embedded world?
> in the PC world?
> 

At least all new Intel SoCs have it, besides that there is one more
user of the struct clk_fractional_divider, but I have no idea if they
have something similar to this.

> 
> My hardware uses a slightly weird (to me) API:
> 
> ? I = 0-255 (8 bits)
> ? F = 0-15??(4 bits)

This part is okay.

> 
> ? I = 0 => DIV = +INF

On Intel we recognize this as an absence of the divider.

> ? I = 1 => DIV = 1 + F/(32-F)

Weird part, indeed. But seems it doubles a precision in a range
[1 .. 1 + 1/2]

> ? I > 1 => DIV = I + F/16

This just normal operation.

> 
> Is this HW API common/typical in the embedded world?
> (Perhaps just the linear part for I > 1)

I saw similar approach in few UART drivers, but they do not use CLK
framework.

So, I could consider this one is more popular / wider, than what we
have in Intel SoCs.

> 
> I see two downsides to this API:
> 
> 1) I = 1 is a special case

> 2) A lot of the value space is wasted on large values.
> 
> For example, when I = 250, we don't really care about 250.0625,
> 250.125,
> etc, or even nearby integer values, for that matter.
> 
> I think it's better to have a distribution with high density in small
> values, and low density in high values (sort of like floating point).
> 
> For example:
> 
> ? I = 0-15??(4 bits)
> ? F = 0-255 (8 bits)
> ? DIV = 2^I * (1 + F/256)
> 
> (We could probably even shave 2-4 bits on F.)
> 
> Are there downsides to this HW API?
> Is this HW API common/typical in the embedded world?

So, what is your intention? If you would like to use CLK framework you
might consider existing providers and users and might implement a
specific one for similar cases.

Also it's possible to convert clock providers for, e.g., UARTs to use
this kind of divider.

-- 
Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Intel Finland Oy



From arnd at arndb.de  Fri Feb  5 07:21:50 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri,  5 Feb 2016 16:21:50 +0100
Subject: [PATCH] staging: wilc1000: fix compilation without CONFIG_PM
Message-ID: <1454685729-3663377-1-git-send-email-arnd@arndb.de>

After the addition of the wakeup code in wilc1000, it no longer
builds when CONFIG_PM is disabled:

drivers/staging/wilc1000/wilc_wfi_cfgoperations.c: In function 'wilc_create_wiphy':
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2632:13: error: 'struct wiphy' has no member named 'wowlan'
  wdev->wiphy->wowlan = &wowlan_support;

This marks the wowlan_support variable as __maybe_unused and hides
the reference when CONFIG_PM is disabled to avoid the build error.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 73584a40d748 ("staging: wilc1000: add ops resuem/suspend/wakeup in cfg80211")
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 4eede2b4e661..7e6262026070 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -74,7 +74,7 @@ static const struct ieee80211_txrx_stypes
 	}
 };
 
-static const struct wiphy_wowlan_support wowlan_support = {
+static const struct wiphy_wowlan_support wowlan_support __maybe_unused = {
 	.flags = WIPHY_WOWLAN_ANY
 };
 
@@ -2629,7 +2629,9 @@ struct wireless_dev *wilc_create_wiphy(struct net_device *net, struct device *de
 	sema_init(&(priv->SemHandleUpdateStats), 1);
 	priv->wdev = wdev;
 	wdev->wiphy->max_scan_ssids = MAX_NUM_PROBED_SSID;
+#ifdef CONFIG_PM
 	wdev->wiphy->wowlan = &wowlan_support;
+#endif
 	wdev->wiphy->max_num_pmkids = WILC_MAX_NUM_PMKIDS;
 	PRINT_INFO(CFG80211_DBG, "Max number of PMKIDs = %d\n", wdev->wiphy->max_num_pmkids);
 
-- 
2.7.0



From robin.murphy at arm.com  Fri Feb  5 07:29:12 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Fri, 5 Feb 2016 15:29:12 +0000
Subject: [PATCH v2] clocksource/arm_arch_timer: Enable and verify MMIO
 access
In-Reply-To: <20160201195816.GL4848@codeaurora.org>
References: <71bf617f4083b116b2aeab24f13fc5fed99a816f.1454327031.git.robin.murphy@arm.com>
 <20160201195816.GL4848@codeaurora.org>
Message-ID: <56B4BFC8.6050201@arm.com>

On 01/02/16 19:58, Stephen Boyd wrote:
> On 02/01, Robin Murphy wrote:
>> So far, we have been blindly assuming that having access to a
>> memory-mapped timer frame implies that the individual elements of that
>> frame frame are already enabled. Whilst it's the firmware's job to give
>> us non-secure access to frames in the first place, we should not rely
>> on implementations always being generous enough to also configure CNTACR
>> for those non-secure frames (e.g. [1]).
>>
>> Explicitly enable feature-level access per-frame, and verify that the
>> access we want is really implemented before trying to make use of it.
>>
>> [1]:https://github.com/ARM-software/tf-issues/issues/170
>>
>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>> ---
>
> Reviewed-by: Stephen Boyd <sboyd at codeaurora.org>
> Tested-by: Stephen Boyd <sboyd at codeaurora.org>

Great, thanks!

Daniel, am I right in hoping this is something you'll pick up, or should 
I be resending it to arm-soc?

Thanks,
Robin.



From daniel.lezcano at linaro.org  Fri Feb  5 07:32:02 2016
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Fri, 5 Feb 2016 16:32:02 +0100
Subject: [PATCH v2] clocksource/arm_arch_timer: Enable and verify MMIO
 access
In-Reply-To: <56B4BFC8.6050201@arm.com>
References: <71bf617f4083b116b2aeab24f13fc5fed99a816f.1454327031.git.robin.murphy@arm.com>
 <20160201195816.GL4848@codeaurora.org> <56B4BFC8.6050201@arm.com>
Message-ID: <56B4C072.3040409@linaro.org>

On 02/05/2016 04:29 PM, Robin Murphy wrote:
> On 01/02/16 19:58, Stephen Boyd wrote:
>> On 02/01, Robin Murphy wrote:
>>> So far, we have been blindly assuming that having access to a
>>> memory-mapped timer frame implies that the individual elements of that
>>> frame frame are already enabled. Whilst it's the firmware's job to give
>>> us non-secure access to frames in the first place, we should not rely
>>> on implementations always being generous enough to also configure CNTACR
>>> for those non-secure frames (e.g. [1]).
>>>
>>> Explicitly enable feature-level access per-frame, and verify that the
>>> access we want is really implemented before trying to make use of it.
>>>
>>> [1]:https://github.com/ARM-software/tf-issues/issues/170
>>>
>>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>>> ---
>>
>> Reviewed-by: Stephen Boyd <sboyd at codeaurora.org>
>> Tested-by: Stephen Boyd <sboyd at codeaurora.org>
>
> Great, thanks!
>
> Daniel, am I right in hoping this is something you'll pick up, or should
> I be resending it to arm-soc?

I will be reviewing timers patches next week. I will take care of this one.

Thanks
   -- Daniel



-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From broonie at kernel.org  Fri Feb  5 07:32:58 2016
From: broonie at kernel.org (Mark Brown)
Date: Fri, 5 Feb 2016 15:32:58 +0000
Subject: [PATCH v2 1/2] regulator: Add coupled regulator
In-Reply-To: <20160205143328.GD31506@lukather>
References: <1452605842-9317-1-git-send-email-maxime.ripard@free-electrons.com>
 <1452605842-9317-2-git-send-email-maxime.ripard@free-electrons.com>
 <20160112143100.GA14628@rob-hp-laptop>
 <20160115085734.GG4581@lukather>
 <20160117000434.GB7774@rob-hp-laptop>
 <20160118162538.GH6588@sirena.org.uk>
 <20160121154649.GE3997@lukather>
 <20160121162802.GL6588@sirena.org.uk>
 <20160205143328.GD31506@lukather>
Message-ID: <20160205153258.GW4455@sirena.org.uk>

On Fri, Feb 05, 2016 at 03:33:28PM +0100, Maxime Ripard wrote:
> On Thu, Jan 21, 2016 at 04:28:02PM +0000, Mark Brown wrote:
> > On Thu, Jan 21, 2016 at 04:46:49PM +0100, Maxime Ripard wrote:

> > > Anyway, I'm fine with both approaches, just let me know what you
> > > prefer.

> > Without seeing an implementation of the lists it's hard to say.

> Just to make sure we're on the same page: you want to keep the
> regulator, but instead of giving the parent through vinX-supplies
> properties, you want to have a single *-supply property, with a list
> of regulators, right?

Either that or an explicit regulator describing the merge.  Rob wants
the list I think but I really don't care.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160205/d5a0c1d4/attachment.sig>

From shameerali.kolothum.thodi at huawei.com  Fri Feb  5 07:33:55 2016
From: shameerali.kolothum.thodi at huawei.com (Shameerali Kolothum Thodi)
Date: Fri, 5 Feb 2016 15:33:55 +0000
Subject: [QUESTION ]ARM64 external L3 cache support in topology info
In-Reply-To: <56B4B1FA.5030309@arm.com>
References: <5FC3163CFD30C246ABAA99954A238FA8172E13A4@lhreml504-mbs>
 <56B4B1FA.5030309@arm.com>
Message-ID: <5FC3163CFD30C246ABAA99954A238FA8172E1638@lhreml504-mbs>



> -----Original Message-----
> From: Sudeep Holla [mailto:sudeep.holla at arm.com]
> Sent: Friday, February 05, 2016 2:30 PM
> To: Shameerali Kolothum Thodi; linux-arm-kernel at lists.infradead.org
> Cc: Sudeep Holla
> Subject: Re: [QUESTION ]ARM64 external L3 cache support in topology
> info
> 
> [..]
> 
> >
> > In our case, the L3 cache seems to be intelligent enough and doesn't
> > require any additional maintenance ops. So there is no cache-
> controller
> > code for this. I am just wondering what's the best way to add this L3
> > cache info to the topology. Overriding the CLIDR register, if there
> is
> > a next-level-cache entry in the dts and then retrieve the cache
> geometry
> > either from dts or from cache specific registers( but this will be
> > implementation specific) ? Or am I missing something here?
> >
> 
> Recent discussion on this [1] made it clear that we need to support
> overriding cache properties using DT for some designs. I will consider
> this "transparent" external/system level cache when I look into moving
> PPC DT code in generic cacheinfo. I am not sure if it's OK to support
> mixed information source for a platform(all internal caches via CLIDR
> and external ones via DT), but we can pick up discussion once we I have
> the patch.

Ok. Will wait for that then. Thanks.

> --
> Regards,
> Sudeep
> 
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-
> October/381758.html


From robin.murphy at arm.com  Fri Feb  5 07:34:54 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Fri, 5 Feb 2016 15:34:54 +0000
Subject: [PATCH v2] clocksource/arm_arch_timer: Enable and verify MMIO
 access
In-Reply-To: <56B4C072.3040409@linaro.org>
References: <71bf617f4083b116b2aeab24f13fc5fed99a816f.1454327031.git.robin.murphy@arm.com>
 <20160201195816.GL4848@codeaurora.org> <56B4BFC8.6050201@arm.com>
 <56B4C072.3040409@linaro.org>
Message-ID: <56B4C11E.1040702@arm.com>

On 05/02/16 15:32, Daniel Lezcano wrote:
> On 02/05/2016 04:29 PM, Robin Murphy wrote:
>> On 01/02/16 19:58, Stephen Boyd wrote:
>>> On 02/01, Robin Murphy wrote:
>>>> So far, we have been blindly assuming that having access to a
>>>> memory-mapped timer frame implies that the individual elements of that
>>>> frame frame are already enabled. Whilst it's the firmware's job to give
>>>> us non-secure access to frames in the first place, we should not rely
>>>> on implementations always being generous enough to also configure
>>>> CNTACR
>>>> for those non-secure frames (e.g. [1]).
>>>>
>>>> Explicitly enable feature-level access per-frame, and verify that the
>>>> access we want is really implemented before trying to make use of it.
>>>>
>>>> [1]:https://github.com/ARM-software/tf-issues/issues/170
>>>>
>>>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>>>> ---
>>>
>>> Reviewed-by: Stephen Boyd <sboyd at codeaurora.org>
>>> Tested-by: Stephen Boyd <sboyd at codeaurora.org>
>>
>> Great, thanks!
>>
>> Daniel, am I right in hoping this is something you'll pick up, or should
>> I be resending it to arm-soc?
>
> I will be reviewing timers patches next week. I will take care of this one.

Cool, thanks for the confirmation.

Robin.

>
> Thanks
>    -- Daniel
>
>
>



From arnd at arndb.de  Fri Feb  5 07:40:54 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 05 Feb 2016 16:40:54 +0100
Subject: [PATCH v2 0/5] arm64: kernel: Add support for User Access Override
In-Reply-To: <1454684330-892-1-git-send-email-james.morse@arm.com>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
Message-ID: <13475776.5b1DTHhHh9@wuerfel>

On Friday 05 February 2016 14:58:45 James Morse wrote:
> This series adds support for User Access Override (UAO; part of the ARMv8.2
> Extensions[0]). When enabled, this causes the get_user() accessors to use
> the unprivileged load/store instructions. When addr_limit is set to
> KERNEL_DS, we set the override bit allowing privileged access.
> 
> Because the unprivileged instructions don't trip PAN, the last patch changes
> which 'alternative' values are swapped in, allowing PAN to be left enabled
> during get_user() and friends.
> 
> This series can be retrieved from:
> git://linux-arm.org/linux-jm.git -b uao/v2
> 

Looks very nice. I have no complaints about the implementations, but two questions:

* There was recently some work in reducing the number of set_fs() calls in
  the compat_ioctl, which further reduces the attack surface. Should we try to
  continue that effort in other syscalls?

* Do we expect to handle this using live patching indefinitely? I can imagine
  that at some point in the future, ARMv8.2+ systems will be the vast majority,
  so it might be nice to support enabling it unconditionally (same for any
  of the alternative bits really). Is there a long-term strategy?

	Arnd


From catalin.marinas at arm.com  Fri Feb  5 07:42:34 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 5 Feb 2016 15:42:34 +0000
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <CAKv+Gu9n=bmsZ=UOBiLWzaG2JSsbdC8k1mB7yFbH0czrbXS-1g@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160204151303.GB6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu9n=bmsZ=UOBiLWzaG2JSsbdC8k1mB7yFbH0czrbXS-1g@mail.gmail.com>
Message-ID: <20160205154234.GF6076@e104818-lin.cambridge.arm.com>

On Thu, Feb 04, 2016 at 04:31:59PM +0100, Ard Biesheuvel wrote:
> On 4 February 2016 at 16:13, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
> >> This adds support for emitting PLTs at module load time for relative
> >> branches that are out of range. This is a prerequisite for KASLR, which
> >> may place the kernel and the modules anywhere in the vmalloc area,
> >> making it more likely that branch target offsets exceed the maximum
> >> range of +/- 128 MB.
> >
> > Any downside to trying to keep the kernel+modules coupled together so
> > that we avoid the PLT?
> 
> First of all, note that it is unlikely that the PLTs are ever required
> in practice, considering that either
> a) the kernel is loaded at the default location right at the base of
> the vmalloc range, and in this case, the module space is reserved for
> modules only, or
> b) the kernel is loaded at some random offset in the 240+ GB vmalloc
> space, and it is unlikely that all VMA space around the kernel happens
> to be given out to non-randomized vmalloc/ioremap allocations

My worry is that we merge some code that's rarely tested.

> So the bottom line is that it may be possible, but it is unlikely to
> be worth the effort imo

The alternative of having our own allocator for modules isn't that
appealing either, so let's stick with the PLTs.

-- 
Catalin


From gregory.clement at free-electrons.com  Fri Feb  5 07:45:44 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 05 Feb 2016 16:45:44 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <CAKzmTe20fT8BcRaDaf2gz92KMAK0kEUkaD-kPq_cPF1WKBdroA@mail.gmail.com>
 (JM's message of "Fri, 5 Feb 2016 16:00:49 +0100")
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
 <20160205090246.GE32272@lunn.ch> <20160205112907.796afb05@bbrezillon>
 <CAKzmTe20fT8BcRaDaf2gz92KMAK0kEUkaD-kPq_cPF1WKBdroA@mail.gmail.com>
Message-ID: <87vb632maf.fsf@free-electrons.com>

Hi JM,
 
 On ven., f?vr. 05 2016, JM <fijam at archlinux.us> wrote:

> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
> <boris.brezillon at free-electrons.com> wrote:
>> Jan, Andrew
>>
>> On Fri, 5 Feb 2016 10:02:46 +0100
>> Andrew Lunn <andrew at lunn.ch> wrote:
>>
>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>>> > Hi,
>>> >
>>> > I am testing marvell_cesa on a kirkwood device (QNAP TS-212p, Marvell
>>> > Kirkwood 88F6282, dts: http://pastebin.com/Gk95KFHf ).
>>> > As of kernel 4.4 (4.4.0-trunk-kirkwood #1 Debian 4.4-1~exp1) it fails
>>> > in the following way:
>>> >
>>> > modprobe marvell_cesa allhwsupport=1
>>> > dmesg | tail -n 1
>>> > [ 1057.855091] marvell-cesa: probe of f1030000.crypto failed with error -12
>>> >
>>> > or:
>>> >
>>> > modprobe marvell_cesa
>>> > dmesg | tail -n 1
>>> > [ 9178.399357] marvell-cesa: probe of f1030000.crypto failed with error -524
>>> >
>>> > With kernel 4.3 it would fail with error -22 on that hardware. There
>>> > are scattered reports from other users experiencing the same issue
>>> > (1,2,3)
>>> >
>>> > I wonder if this is a result of an invalid definition of the
>>> > crypto-sram in the dts of this SoC, or perhaps some other problem
>>> > (PEBKAC included).
>>>
>>> Hi Jan
>>>
>>> Do you have SRAM enabled in your kernel configuration. The
>>> mvebu_v5_defconfig does not have it, which is a bug really.
>>
>> Hm, the CRYPTO_DEV_MARVELL_CESA option selects the SRAM one [1].
>> Anyway, I also think this error is related to the SRAM (not sure why the
>> driver is not able to get the SRAM though).
>>
>> Best Regards,
>>
>> Boris
>>
>> [1]http://lxr.free-electrons.com/source/drivers/crypto/Kconfig#L168
>>
>>
>> --
>> Boris Brezillon, Free Electrons
>> Embedded Linux and Kernel engineering
>> http://free-electrons.com
>
> Hi,
>
> Thanks for getting back to me. Indeed, CONFIG_SRAM is enabled, I put
> the complete .config here: http://pastebin.com/40eKMJqE
>
> If there is anything I can do to help squish this bug, please let me
> know.

How do you get your dts?
it seems that you generated it from your dtb (or from /proc).

I tried to do the same from arch/arm/boot/dts/kirkwood-ts219-6282.dtb,
but the resulting dts is too different for an easy comparison.

Could you also provide your dtb, maybe by using the same dtc with the
option -s I will manage to get the something easier to compare.

Gregory


>
> Best regards,
> Jan
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From ard.biesheuvel at linaro.org  Fri Feb  5 07:53:10 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 5 Feb 2016 16:53:10 +0100
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <20160205154234.GF6076@e104818-lin.cambridge.arm.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160204151303.GB6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu9n=bmsZ=UOBiLWzaG2JSsbdC8k1mB7yFbH0czrbXS-1g@mail.gmail.com>
 <20160205154234.GF6076@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu-poQiuc7+O38n93Xt2o-SYi3kYD0k_9+-6T0=FXV9uXA@mail.gmail.com>

On 5 February 2016 at 16:42, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Thu, Feb 04, 2016 at 04:31:59PM +0100, Ard Biesheuvel wrote:
>> On 4 February 2016 at 16:13, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
>> >> This adds support for emitting PLTs at module load time for relative
>> >> branches that are out of range. This is a prerequisite for KASLR, which
>> >> may place the kernel and the modules anywhere in the vmalloc area,
>> >> making it more likely that branch target offsets exceed the maximum
>> >> range of +/- 128 MB.
>> >
>> > Any downside to trying to keep the kernel+modules coupled together so
>> > that we avoid the PLT?
>>
>> First of all, note that it is unlikely that the PLTs are ever required
>> in practice, considering that either
>> a) the kernel is loaded at the default location right at the base of
>> the vmalloc range, and in this case, the module space is reserved for
>> modules only, or
>> b) the kernel is loaded at some random offset in the 240+ GB vmalloc
>> space, and it is unlikely that all VMA space around the kernel happens
>> to be given out to non-randomized vmalloc/ioremap allocations
>
> My worry is that we merge some code that's rarely tested.
>

I understand. But unfortunately, having corner cases that are unlikely
but not impossible comes with the territory of randomization.

Alternatively, we could take the performance hit if KASLR is in effect
and allocate each module completely randomly as well. This way, the
code is always exercised (for now), and we can always backpedal later
if the performance is measurably worse.

>> So the bottom line is that it may be possible, but it is unlikely to
>> be worth the effort imo
>
> The alternative of having our own allocator for modules isn't that
> appealing either, so let's stick with the PLTs.
>
> --
> Catalin


From helgaas at kernel.org  Fri Feb  5 07:54:12 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Fri, 5 Feb 2016 09:54:12 -0600
Subject: [PATCH] PCI: layerscape: add ls2085a compatible
In-Reply-To: <VI1PR04MB16155E4265922D6659B439C1E8D20@VI1PR04MB1615.eurprd04.prod.outlook.com>
References: <1453915925-19198-1-git-send-email-yang.shi@linaro.org>
 <56A906F4.3050809@linaro.org> <20160204223711.GE7031@localhost>
 <56B3E386.8010002@linaro.org>
 <VI1PR04MB1230AA5CAEEEE0D4AD8E3DF288D20@VI1PR04MB1230.eurprd04.prod.outlook.com>
 <VI1PR04MB16155E4265922D6659B439C1E8D20@VI1PR04MB1615.eurprd04.prod.outlook.com>
Message-ID: <20160205155412.GB29306@localhost>

On Fri, Feb 05, 2016 at 06:07:10AM +0000, Minghuan Lian wrote:
> The patch is ok to me.

Thanks, I'll transform that into an ack.

Who's going to post a patch to update MAINTAINERS to fix the
@freescale.com addresses?  If we can get that in for v4.5, it will
save some hassle.

> > -----Original Message-----
> > From: Bhupesh Sharma
> > Sent: Friday, February 05, 2016 1:36 PM
> > To: Shi, Yang <yang.shi at linaro.org>; Bjorn Helgaas <helgaas at kernel.org>;
> > Yang-Leo Li <leoyang.li at nxp.com>; shawn.guo at linaro.org
> > Cc: Mingkai Hu <mingkai.hu at nxp.com>; Minghuan Lian
> > <minghuan.lian at nxp.com>; bhelgaas at google.com; linux-pci at vger.kernel.org;
> > linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > linaro-kernel at lists.linaro.org
> > Subject: RE: [PATCH] PCI: layerscape: add ls2085a compatible
> > 
> > > From: Shi, Yang
> > > Sent: Friday, February 05, 2016 5:19 AM
> > >
> > > On 2/4/2016 2:37 PM, Bjorn Helgaas wrote:
> > > > On Wed, Jan 27, 2016 at 10:05:40AM -0800, Shi, Yang wrote:
> > > >> Correct FSL folks email address to nxp.com, sorry for the
> > > inconvenience.
> > > >
> > > > Do we need some MAINTAINERS updates in addition to the ack for this
> > > patch?
> > > > I see a bunch of @freescale.com addresses in MAINTAINERS.
> > >
> > > I guess so if the @freescale.com address is not valid anymore.
> > 
> > All @freescale.com address have shifted to @nxp.com.
> > 
> > Leo, Minghuan - can you kindly review this patch.
> > 
> > Shawn - can you take this through your tree, once Leo and Minghuan have
> > reviewed the code.
> > 
> > Regards,
> > Bhupesh
> > 
> > >
> > > >
> > > >> On 1/27/2016 9:32 AM, Yang Shi wrote:
> > > >>> The layerscape PCI host driver needs recognize ls2085a compatible
> > > >>> when using firmware with ls2085a compatible property, otherwise
> > > >>> the PCI bus won't be detected even though ls2085a compatible is
> > > >>> included
> > > by the dts.
> > > >>>
> > > >>> Signed-off-by: Yang Shi <yang.shi at linaro.org>
> > > >>> ---
> > > >>>   drivers/pci/host/pci-layerscape.c | 1 +
> > > >>>   1 file changed, 1 insertion(+)
> > > >>>
> > > >>> diff --git a/drivers/pci/host/pci-layerscape.c
> > > >>> b/drivers/pci/host/pci-layerscape.c
> > > >>> index 3923bed..c40d8b2 100644
> > > >>> --- a/drivers/pci/host/pci-layerscape.c
> > > >>> +++ b/drivers/pci/host/pci-layerscape.c
> > > >>> @@ -203,6 +203,7 @@ static const struct of_device_id
> > > ls_pcie_of_match[] = {
> > > >>>   	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata
> > > },
> > > >>>   	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata
> > > },
> > > >>>   	{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata
> > > },
> > > >>> +	{ .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },
> > > >>>   	{ },
> > > >>>   };
> > > >>>   MODULE_DEVICE_TABLE(of, ls_pcie_of_match);
> > > >>>
> > > >>
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-pci"
> > > in the body of a message to majordomo at vger.kernel.org More majordomo
> > > info at http://vger.kernel.org/majordomo-info.html


From festevam at gmail.com  Fri Feb  5 07:58:23 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Fri, 5 Feb 2016 13:58:23 -0200
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
Message-ID: <CAOMZO5AkyVnfCnaOp=tNo3xe3HL7YMWgcJCNQqD0+jK3jBs5sQ@mail.gmail.com>

On Fri, Feb 5, 2016 at 3:01 AM, JM <fijam at archlinux.us> wrote:
> Hi,
>
> I am testing marvell_cesa on a kirkwood device (QNAP TS-212p, Marvell
> Kirkwood 88F6282, dts: http://pastebin.com/Gk95KFHf ).
> As of kernel 4.4 (4.4.0-trunk-kirkwood #1 Debian 4.4-1~exp1) it fails
> in the following way:
>
> modprobe marvell_cesa allhwsupport=1
> dmesg | tail -n 1
> [ 1057.855091] marvell-cesa: probe of f1030000.crypto failed with error -12

It seems like this is the similar issue I saw with the sahara driver.

Could you try a fix like this?
http://www.spinics.net/lists/linux-crypto/msg18393.html


From catalin.marinas at arm.com  Fri Feb  5 08:00:54 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 5 Feb 2016 16:00:54 +0000
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <CAKv+Gu-poQiuc7+O38n93Xt2o-SYi3kYD0k_9+-6T0=FXV9uXA@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160204151303.GB6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu9n=bmsZ=UOBiLWzaG2JSsbdC8k1mB7yFbH0czrbXS-1g@mail.gmail.com>
 <20160205154234.GF6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-poQiuc7+O38n93Xt2o-SYi3kYD0k_9+-6T0=FXV9uXA@mail.gmail.com>
Message-ID: <20160205160054.GG6076@e104818-lin.cambridge.arm.com>

On Fri, Feb 05, 2016 at 04:53:10PM +0100, Ard Biesheuvel wrote:
> On 5 February 2016 at 16:42, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Thu, Feb 04, 2016 at 04:31:59PM +0100, Ard Biesheuvel wrote:
> >> On 4 February 2016 at 16:13, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> > On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
> >> >> This adds support for emitting PLTs at module load time for relative
> >> >> branches that are out of range. This is a prerequisite for KASLR, which
> >> >> may place the kernel and the modules anywhere in the vmalloc area,
> >> >> making it more likely that branch target offsets exceed the maximum
> >> >> range of +/- 128 MB.
> >> >
> >> > Any downside to trying to keep the kernel+modules coupled together so
> >> > that we avoid the PLT?
> >>
> >> First of all, note that it is unlikely that the PLTs are ever required
> >> in practice, considering that either
> >> a) the kernel is loaded at the default location right at the base of
> >> the vmalloc range, and in this case, the module space is reserved for
> >> modules only, or
> >> b) the kernel is loaded at some random offset in the 240+ GB vmalloc
> >> space, and it is unlikely that all VMA space around the kernel happens
> >> to be given out to non-randomized vmalloc/ioremap allocations
> >
> > My worry is that we merge some code that's rarely tested.
> 
> I understand. But unfortunately, having corner cases that are unlikely
> but not impossible comes with the territory of randomization.
> 
> Alternatively, we could take the performance hit if KASLR is in effect
> and allocate each module completely randomly as well. This way, the
> code is always exercised (for now), and we can always backpedal later
> if the performance is measurably worse.

I'm fine with this. You can post it as a separate patch that we can
easily revert/modify later (like turning it into a config option).

-- 
Catalin


From fijam at archlinux.us  Fri Feb  5 08:01:45 2016
From: fijam at archlinux.us (JM)
Date: Fri, 5 Feb 2016 17:01:45 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <87vb632maf.fsf@free-electrons.com>
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
 <20160205090246.GE32272@lunn.ch> <20160205112907.796afb05@bbrezillon>
 <CAKzmTe20fT8BcRaDaf2gz92KMAK0kEUkaD-kPq_cPF1WKBdroA@mail.gmail.com>
 <87vb632maf.fsf@free-electrons.com>
Message-ID: <CAKzmTe1AqNQwjcsAULotd010NXuk1AYjj5p6UoqT_Zu=BCHdcw@mail.gmail.com>

On Fri, Feb 5, 2016 at 4:45 PM, Gregory CLEMENT
<gregory.clement at free-electrons.com> wrote:
> Hi JM,
>
>  On ven., f?vr. 05 2016, JM <fijam at archlinux.us> wrote:
>
>> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
>> <boris.brezillon at free-electrons.com> wrote:
>>> Jan, Andrew
>>>
>>> On Fri, 5 Feb 2016 10:02:46 +0100
>>> Andrew Lunn <andrew at lunn.ch> wrote:
>>>
>>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>>>> > Hi,
>>>> >
>>>> > I am testing marvell_cesa on a kirkwood device (QNAP TS-212p, Marvell
>>>> > Kirkwood 88F6282, dts: http://pastebin.com/Gk95KFHf ).
>>>> > As of kernel 4.4 (4.4.0-trunk-kirkwood #1 Debian 4.4-1~exp1) it fails
>>>> > in the following way:
>>>> >
>>>> > modprobe marvell_cesa allhwsupport=1
>>>> > dmesg | tail -n 1
>>>> > [ 1057.855091] marvell-cesa: probe of f1030000.crypto failed with error -12
>>>> >
>>>> > or:
>>>> >
>>>> > modprobe marvell_cesa
>>>> > dmesg | tail -n 1
>>>> > [ 9178.399357] marvell-cesa: probe of f1030000.crypto failed with error -524
>>>> >
>>>> > With kernel 4.3 it would fail with error -22 on that hardware. There
>>>> > are scattered reports from other users experiencing the same issue
>>>> > (1,2,3)
>>>> >
>>>> > I wonder if this is a result of an invalid definition of the
>>>> > crypto-sram in the dts of this SoC, or perhaps some other problem
>>>> > (PEBKAC included).
>>>>
>>>> Hi Jan
>>>>
>>>> Do you have SRAM enabled in your kernel configuration. The
>>>> mvebu_v5_defconfig does not have it, which is a bug really.
>>>
>>> Hm, the CRYPTO_DEV_MARVELL_CESA option selects the SRAM one [1].
>>> Anyway, I also think this error is related to the SRAM (not sure why the
>>> driver is not able to get the SRAM though).
>>>
>>> Best Regards,
>>>
>>> Boris
>>>
>>> [1]http://lxr.free-electrons.com/source/drivers/crypto/Kconfig#L168
>>>
>>>
>>> --
>>> Boris Brezillon, Free Electrons
>>> Embedded Linux and Kernel engineering
>>> http://free-electrons.com
>>
>> Hi,
>>
>> Thanks for getting back to me. Indeed, CONFIG_SRAM is enabled, I put
>> the complete .config here: http://pastebin.com/40eKMJqE
>>
>> If there is anything I can do to help squish this bug, please let me
>> know.
>
> How do you get your dts?
> it seems that you generated it from your dtb (or from /proc).
>
> I tried to do the same from arch/arm/boot/dts/kirkwood-ts219-6282.dtb,
> but the resulting dts is too different for an easy comparison.
>
> Could you also provide your dtb, maybe by using the same dtc with the
> option -s I will manage to get the something easier to compare.
>
> Gregory
>
>
>>
>> Best regards,
>> Jan
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> --
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

Hi,

Yes, I simply used dtc -I fs /proc/device-tree to obtain the dts.

Here is the relevant .dtb file : http://heap.ovh/files/kirkwood-ts219-6282.dtb

Best regards,
Jan


From slash.tmp at free.fr  Fri Feb  5 08:01:57 2016
From: slash.tmp at free.fr (Mason)
Date: Fri, 5 Feb 2016 17:01:57 +0100
Subject: Common/typical fractional divider HW API
In-Reply-To: <1454684758.31169.77.camel@linux.intel.com>
References: <56B4B67D.2080707@free.fr>
 <1454684758.31169.77.camel@linux.intel.com>
Message-ID: <56B4C775.50808@free.fr>

On 05/02/2016 16:05, Andy Shevchenko wrote:

> On Fri, 2016-02-05 at 15:49 +0100, Mason wrote:
>
>> AFAICT, the clk-fractional-divider driver implements the following
>> hardware API:
>>
>>   M and N are two fields in the same register.
>>   DIV = M / N
>>
>> Is this HW API common/typical in the embedded world?
>> in the PC world?
> 
> At least all new Intel SoCs have it, besides that there is one more
> user of the struct clk_fractional_divider, but I have no idea if they
> have something similar to this.
> 
>> My hardware uses a slightly weird (to me) API:
>>
>>   I = 0-255 (8 bits)
>>   F = 0-15  (4 bits)
> 
> This part is okay.
> 
>>   I = 0 => DIV = +INF
> 
> On Intel we recognize this as an absence of the divider.
> 
>>   I = 1 => DIV = 1 + F/(32-F)
> 
> Weird part, indeed. But seems it doubles a precision in a range
> [1 .. 1 + 1/2]
> 
>>   I > 1 => DIV = I + F/16
> 
> This just normal operation.
> 
>> Is this HW API common/typical in the embedded world?
>> (Perhaps just the linear part for I > 1)
> 
> I saw similar approach in few UART drivers, but they do not use CLK
> framework.
> 
> So, I could consider this one is more popular / wider, than what we
> have in Intel SoCs.
> 
>> I see two downsides to this API:
>>
>> 1) I = 1 is a special case
>> 
>> 2) A lot of the value space is wasted on large values.
>>
>> For example, when I = 250, we don't really care about 250.0625,
>> 250.125,
>> etc, or even nearby integer values, for that matter.
>>
>> I think it's better to have a distribution with high density in small
>> values, and low density in high values (sort of like floating point).
>>
>> For example:
>>
>>   I = 0-15  (4 bits)
>>   F = 0-255 (8 bits)
>>   DIV = 2^I * (1 + F/256)
>>
>> (We could probably even shave 2-4 bits on F.)
>>
>> Are there downsides to this HW API?
>> Is this HW API common/typical in the embedded world?
> 
> So, what is your intention? If you would like to use CLK framework you
> might consider existing providers and users and might implement a
> specific one for similar cases.

Right now, I'm using the clk-divider driver (integer divider).
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/clk-tango4.c

I was trying to avoid writing any code, but it looks like I would
need a specific driver if I want to support the hardware's fractional
divider logic.

Once I started looking at the HW API, I was thinking that it
could be improved (and perhaps the HW engineers would agree
to make the change) but I wanted to get feedback from seasoned
devs with respect to the proposed HW API.

So, do you agree that

  DIV = 2^I * (1 + F/256)

gives a more useful DIV distribution than

  DIV = I + F/16

> Also it's possible to convert clock providers for, e.g., UARTs to use
> this kind of divider.

I'm not sure how to parse that. I'm using the divider driver
for a CPU clock, to do D(V)FS in cpufreq.

Regards.



From boris.brezillon at free-electrons.com  Fri Feb  5 08:02:40 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 5 Feb 2016 17:02:40 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <CAOMZO5AkyVnfCnaOp=tNo3xe3HL7YMWgcJCNQqD0+jK3jBs5sQ@mail.gmail.com>
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
 <CAOMZO5AkyVnfCnaOp=tNo3xe3HL7YMWgcJCNQqD0+jK3jBs5sQ@mail.gmail.com>
Message-ID: <20160205170240.3e0dc1fd@bbrezillon>

On Fri, 5 Feb 2016 13:58:23 -0200
Fabio Estevam <festevam at gmail.com> wrote:

> On Fri, Feb 5, 2016 at 3:01 AM, JM <fijam at archlinux.us> wrote:
> > Hi,
> >
> > I am testing marvell_cesa on a kirkwood device (QNAP TS-212p, Marvell
> > Kirkwood 88F6282, dts: http://pastebin.com/Gk95KFHf ).
> > As of kernel 4.4 (4.4.0-trunk-kirkwood #1 Debian 4.4-1~exp1) it fails
> > in the following way:
> >
> > modprobe marvell_cesa allhwsupport=1
> > dmesg | tail -n 1
> > [ 1057.855091] marvell-cesa: probe of f1030000.crypto failed with error -12
> 
> It seems like this is the similar issue I saw with the sahara driver.
> 
> Could you try a fix like this?
> http://www.spinics.net/lists/linux-crypto/msg18393.html

Hm, this should be fixed in 4.4, and Jan reports an ENOMEM error not
EINVAL (note that getting ENOTSUPP if allhwsupport is not set to 1 is
expected).

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


From gregory.clement at free-electrons.com  Fri Feb  5 08:03:23 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 05 Feb 2016 17:03:23 +0100
Subject: [PATCH v2 08/12] devicetree: bindings: add DT binding for the
 Marvell Armada 3700 SoC family
In-Reply-To: <20160203213825.4fa6a0ef@free-electrons.com> (Thomas Petazzoni's
 message of "Wed, 3 Feb 2016 21:38:25 +0100")
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
 <1454524889-9207-9-git-send-email-gregory.clement@free-electrons.com>
 <20160203213825.4fa6a0ef@free-electrons.com>
Message-ID: <87r3gr2lh0.fsf@free-electrons.com>

Hi Thomas,
 
 On mer., f?vr. 03 2016, Thomas Petazzoni <thomas.petazzoni at free-electrons.com> wrote:

> Hello,
>
> On Wed,  3 Feb 2016 19:41:25 +0100, Gregory CLEMENT wrote:
>> The Marvell Armada 3700 is a family of ARMv8 CA53 SoCs. This commit
>> introduces the Device Tree binding that documents the top-level
>> compatible strings for Armada 3700 based platforms.
>> 
>> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
>> ---
>>  .../devicetree/bindings/arm/marvell/armada-37xx.txt      | 16 ++++++++++++++++
>>  1 file changed, 16 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
>> new file mode 100644
>> index 000000000000..17e90e8b5f76
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
>> @@ -0,0 +1,16 @@
>> +Marvell Armada 37xx Platforms Device Tree Bindings
>> +--------------------------------------------------
>> +
>> +Boards using a SoC of the Marvell Armada 37xx family must carry the
>> +following root node property:
>> +
>> + - compatible: must contain "marvell,armada3710"
>
> Are we sure at this point that the 3720 is a strict super-set of the
> 3710 ?

I think we are in the same situation with the Armada 380 with the other
Armada 38x. At this point the 3720 is a super-set of the 3710.

>
> If that's not the case, then it would be somewhat weird for a platform
> using the 3720 platform to carry the marvell,armada3710 compatible
> string, no?

Actually, we only said that the 3720 is compatible with the 3710 not
really a strict super-set. More over, for a 3720 we must use
marvell,armada3720 _and_ marvell,armada3710, and in case of conflict
marvell,armada3720 must be used.

I really prefer using marvell,armada3710 as common compatible for all
the Armada 3700 SoCs, that having no common compatible at all.

Thanks,

Gregory

>
> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From gregory.clement at free-electrons.com  Fri Feb  5 08:09:34 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 05 Feb 2016 17:09:34 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <CAKzmTe1AqNQwjcsAULotd010NXuk1AYjj5p6UoqT_Zu=BCHdcw@mail.gmail.com>
 (JM's message of "Fri, 5 Feb 2016 17:01:45 +0100")
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
 <20160205090246.GE32272@lunn.ch> <20160205112907.796afb05@bbrezillon>
 <CAKzmTe20fT8BcRaDaf2gz92KMAK0kEUkaD-kPq_cPF1WKBdroA@mail.gmail.com>
 <87vb632maf.fsf@free-electrons.com>
 <CAKzmTe1AqNQwjcsAULotd010NXuk1AYjj5p6UoqT_Zu=BCHdcw@mail.gmail.com>
Message-ID: <87mvrf2l6p.fsf@free-electrons.com>

Hi JM,
 
 On ven., f?vr. 05 2016, JM <fijam at archlinux.us> wrote:

> On Fri, Feb 5, 2016 at 4:45 PM, Gregory CLEMENT
> <gregory.clement at free-electrons.com> wrote:
>> Hi JM,
>>
>>  On ven., f?vr. 05 2016, JM <fijam at archlinux.us> wrote:
>>
>>> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
>>> <boris.brezillon at free-electrons.com> wrote:
>>>> Jan, Andrew
>>>>
>>>> On Fri, 5 Feb 2016 10:02:46 +0100
>>>> Andrew Lunn <andrew at lunn.ch> wrote:
>>>>
>>>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I am testing marvell_cesa on a kirkwood device (QNAP TS-212p, Marvell
>>>>> > Kirkwood 88F6282, dts: http://pastebin.com/Gk95KFHf ).
>>>>> > As of kernel 4.4 (4.4.0-trunk-kirkwood #1 Debian 4.4-1~exp1) it fails
>>>>> > in the following way:
>>>>> >
>>>>> > modprobe marvell_cesa allhwsupport=1
>>>>> > dmesg | tail -n 1
>>>>> > [ 1057.855091] marvell-cesa: probe of f1030000.crypto failed with error -12
>>>>> >
>>>>> > or:
>>>>> >
>>>>> > modprobe marvell_cesa
>>>>> > dmesg | tail -n 1
>>>>> > [ 9178.399357] marvell-cesa: probe of f1030000.crypto failed with error -524
>>>>> >
>>>>> > With kernel 4.3 it would fail with error -22 on that hardware. There
>>>>> > are scattered reports from other users experiencing the same issue
>>>>> > (1,2,3)
>>>>> >
>>>>> > I wonder if this is a result of an invalid definition of the
>>>>> > crypto-sram in the dts of this SoC, or perhaps some other problem
>>>>> > (PEBKAC included).
>>>>>
>>>>> Hi Jan
>>>>>
>>>>> Do you have SRAM enabled in your kernel configuration. The
>>>>> mvebu_v5_defconfig does not have it, which is a bug really.
>>>>
>>>> Hm, the CRYPTO_DEV_MARVELL_CESA option selects the SRAM one [1].
>>>> Anyway, I also think this error is related to the SRAM (not sure why the
>>>> driver is not able to get the SRAM though).
>>>>
>>>> Best Regards,
>>>>
>>>> Boris
>>>>
>>>> [1]http://lxr.free-electrons.com/source/drivers/crypto/Kconfig#L168
>>>>
>>>>
>>>> --
>>>> Boris Brezillon, Free Electrons
>>>> Embedded Linux and Kernel engineering
>>>> http://free-electrons.com
>>>
>>> Hi,
>>>
>>> Thanks for getting back to me. Indeed, CONFIG_SRAM is enabled, I put
>>> the complete .config here: http://pastebin.com/40eKMJqE
>>>
>>> If there is anything I can do to help squish this bug, please let me
>>> know.
>>
>> How do you get your dts?
>> it seems that you generated it from your dtb (or from /proc).
>>
>> I tried to do the same from arch/arm/boot/dts/kirkwood-ts219-6282.dtb,
>> but the resulting dts is too different for an easy comparison.
>>
>> Could you also provide your dtb, maybe by using the same dtc with the
>> option -s I will manage to get the something easier to compare.
>

> Yes, I simply used dtc -I fs /proc/device-tree to obtain the dts.
>
> Here is the relevant .dtb file : http://heap.ovh/files/kirkwood-ts219-6282.dtb
>

OK so this dtb is exacly the one from the mainline. As most of the CESU
stuff is set in te dtis, we will be able to compare it on the other
kirkwood based board.

Gregory

> Best regards,
> Jan

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From marcel.ziswiler at toradex.com  Fri Feb  5 08:12:19 2016
From: marcel.ziswiler at toradex.com (Marcel Ziswiler)
Date: Fri,  5 Feb 2016 17:12:19 +0100
Subject: [PATCH v5 0/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D
 SoM/Ixora carrier board
Message-ID: <1454688741-4238-1-git-send-email-marcel.ziswiler@toradex.com>


This patch series adds support for Toradex Apalis iMX6Q/D SoM module [1] and
Ixora carrier board [2].

Petr ?tetiar has simply taken content of DTSes from Toradex's Git tree [3],
removed not mainlined stuff and fixed all errors returned by checkpatch script.

Please note that RESET_MOCI# used as mini-PCIe PERST# is not directly
GPIO1_IO28 but rather inverted (e.g. active-high and ored with RESETBMCU coming
off the PMIC but that is not relevant in this context). As changing the
reset-gpio polarity wasn't previously supported Petr ?tetiar's
"PCI: imx6: Fix reset-gpio to work with active low GPIO" fix [4] is needed.

1. https://www.toradex.com/computer-on-modules/apalis-arm-family/freescale-imx-6
2. https://www.toradex.com/products/carrier-boards/ixora-carrier-board
3. https://git.toradex.com/cgit/linux-toradex.git/log/?h=toradex_imx_3.14.28_1.0.0_ga
4. https://patchwork.ozlabs.org/patch/552886/

Changes in v5:
- finally get rid of regulators simple bus as suggested by Lucas, Petr and Shawn
- use reg_xxx: regulator-xxx naming scheme as suggested by Shawn
- get rid of disabled hdmi node as suggested by Shawn
- have a new line between properties and sub-node as suggested by Shawn
- get rid of disabled usbh1 node as suggested by Shawn
- drop iomux/pinctrl function container nodes as suggested by Shawn
- added new lines between nodes as suggested by Shawn
- use consistent pinctrl group node naming schema xxxgrp as suggested by Shawn
- further clean-up and re-order iomux/pinctrl stuff
- configure eMMC reset as required once fast boot mode is used
- properly set usdhc1, usdhc2 and usdhc3 vqmmc-supply rather than vmmc-supply we previously set leading to wrong signal voltage being reported
- drop iomux/pinctrl function container node as suggested by Shawn
- added new line between nodes as suggested by Shawn
- use consistent pinctrl group node naming schema xxxgrp as suggested by Shawn
- replace the gpio-key,wakeup property with the generic wakeup-source one as suggested by Shawn
- drop regulators function container node and use simple label reference to enable USB VBUS' as suggested by Shawn

Changes in v4:
- integrated review feedback from Fabio

Changes in v3:
- integrated review feedback from Petr
- integrated review feedback from Stefan
- move I2C DDC enablement and assignement handling into carrier board DTS where it belongs
- move CAN nodes up a little to keep the alphabetical order
- added an explanatory comment about PWR_I2C usage
- integrated review feedback from Petr
- integrated review feedback from Stefan
- fix comment concerning Apalis GPIO usage as GPIO7 is only used for PCIe switch reset on Apalis Evaluation board
- move I2C DDC handling into carrier board DTS where it belongs
- simplify RTC alias

Changes in v2:
- clarify exact Apalis iMX6Q/D SoM type in cover letter
- clarify exact Apalis iMX6Q/D module type and Ixora carrier board in model
  node
- got rid of obsolete mmc aliases
- working SGTL5000 audio/sound integration
- working STMPE811 touch screen controller integration
- integrated review feedback from Lucas
- left and even added some more comments as I don't see why putting any
  explanatory comments in dts' should be such a bad thing to do
- completely got rid of the memory node as that is something typically filled
  in by the boot loader e.g. U-Boot
- without the regulators simple-bus it no longer boots
- even though we supposedly shipped a few hundred V1.0a modules drop DCE UART
  support for now and simplify file layout
- replaced obsolete no-1-8-v by mainline supported voltage-ranges = <3300 3300>
  usdhc property and yes card detects are indeed active low (;-p)
- integrated review feedback from Stefan
- fixed Ethernet PHY reset & interrupt (requires Micrel PHY driver to be
  enabled)
- fixed HDMI DDC (requires GPIO-based bitbanging I2C to be enabled)
- fixed SPDIF
- clarify exact Apalis iMX6Q/D SoM type in cover letter
- clarify exact Apalis iMX6Q/D module type and Ixora carrier board in model
  node
- got rid of obsolete mmc aliases
- working SGTL5000 audio/sound integration
- working STMPE811 touch screen controller integration
- integrated review feedback from Lucas
- left and even added some more comments as I don't see why putting any
  explanatory comments in dts' should be such a bad thing to do
- completely got rid of the memory node as that is something typically filled
  in by the boot loader e.g. U-Boot
- without the regulators simple-bus it no longer boots
- even though we supposedly shipped a few hundred V1.0a modules drop DCE UART
  support for now and simplify file layout
- replaced obsolete no-1-8-v by mainline supported voltage-ranges = <3300 3300>
  usdhc property and yes card detects are indeed active low (;-p)
- integrated review feedback from Stefan
- fixed Ethernet PHY reset & interrupt (requires Micrel PHY driver to be
  enabled)
- fixed HDMI DDC (requires GPIO-based bitbanging I2C to be enabled)
- fixed SPDIF

Petr ?tetiar (2):
  ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM
  ARM: dts: imx6: Add support for Toradex Ixora carrier board

 arch/arm/boot/dts/Makefile               |   1 +
 arch/arm/boot/dts/imx6q-apalis-ixora.dts | 272 +++++++++
 arch/arm/boot/dts/imx6qdl-apalis.dtsi    | 984 +++++++++++++++++++++++++++++++
 3 files changed, 1257 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-apalis-ixora.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-apalis.dtsi

-- 
2.5.0



From marcel.ziswiler at toradex.com  Fri Feb  5 08:12:21 2016
From: marcel.ziswiler at toradex.com (Marcel Ziswiler)
Date: Fri,  5 Feb 2016 17:12:21 +0100
Subject: [PATCH v5 2/2] ARM: dts: imx6: Add support for Toradex Ixora carrier
 board
In-Reply-To: <1454688741-4238-1-git-send-email-marcel.ziswiler@toradex.com>
References: <1454688741-4238-1-git-send-email-marcel.ziswiler@toradex.com>
Message-ID: <1454688741-4238-3-git-send-email-marcel.ziswiler@toradex.com>

From: Petr ?tetiar <ynezz at true.cz>

Signed-off-by: Marcel Ziswiler <marcel.ziswiler at toradex.com>
Signed-off-by: Petr ?tetiar <ynezz at true.cz>
Reviewed-by: Stefan Agner <stefan at agner.ch>
---

Changes in v5:
- drop iomux/pinctrl function container node as suggested by Shawn
- added new line between nodes as suggested by Shawn
- use consistent pinctrl group node naming schema xxxgrp as suggested by Shawn
- replace the gpio-key,wakeup property with the generic wakeup-source one as suggested by Shawn
- drop regulators function container node and use simple label reference to enable USB VBUS' as suggested by Shawn

Changes in v4: None
Changes in v3:
- integrated review feedback from Petr
- integrated review feedback from Stefan
- fix comment concerning Apalis GPIO usage as GPIO7 is only used for PCIe switch reset on Apalis Evaluation board
- move I2C DDC handling into carrier board DTS where it belongs
- simplify RTC alias

Changes in v2:
- clarify exact Apalis iMX6Q/D SoM type in cover letter
- clarify exact Apalis iMX6Q/D module type and Ixora carrier board in model
  node
- got rid of obsolete mmc aliases
- working SGTL5000 audio/sound integration
- working STMPE811 touch screen controller integration
- integrated review feedback from Lucas
- left and even added some more comments as I don't see why putting any
  explanatory comments in dts' should be such a bad thing to do
- completely got rid of the memory node as that is something typically filled
  in by the boot loader e.g. U-Boot
- without the regulators simple-bus it no longer boots
- even though we supposedly shipped a few hundred V1.0a modules drop DCE UART
  support for now and simplify file layout
- replaced obsolete no-1-8-v by mainline supported voltage-ranges = <3300 3300>
  usdhc property and yes card detects are indeed active low (;-p)
- integrated review feedback from Stefan
- fixed Ethernet PHY reset & interrupt (requires Micrel PHY driver to be
  enabled)
- fixed HDMI DDC (requires GPIO-based bitbanging I2C to be enabled)
- fixed SPDIF

 arch/arm/boot/dts/Makefile               |   1 +
 arch/arm/boot/dts/imx6q-apalis-ixora.dts | 272 +++++++++++++++++++++++++++++++
 2 files changed, 273 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-apalis-ixora.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 150f801..4cc9adf 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -321,6 +321,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
 	imx6dl-udoo.dtb \
 	imx6dl-wandboard.dtb \
 	imx6dl-wandboard-revb1.dtb \
+	imx6q-apalis-ixora.dtb \
 	imx6q-apf6dev.dtb \
 	imx6q-arm2.dtb \
 	imx6q-cm-fx6.dtb \
diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
new file mode 100644
index 0000000..2cba82d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
@@ -0,0 +1,272 @@
+/*
+ * Copyright 2014-2016 Toradex AG
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License
+ *     version 2 as published by the Free Software Foundation.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "imx6q.dtsi"
+#include "imx6qdl-apalis.dtsi"
+
+/ {
+	model = "Toradex Apalis iMX6Q/D Module on Ixora Carrier Board";
+	compatible = "toradex,apalis_imx6q-ixora", "toradex,apalis_imx6q",
+		     "fsl,imx6q";
+
+	aliases {
+		i2c0 = &i2cddc;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+	};
+
+	aliases {
+		rtc0 = &rtc_i2c;
+		rtc1 = &snvs_rtc;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_gpio_keys>;
+
+		wakeup {
+			label = "Wake-Up";
+			gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_WAKEUP>;
+			debounce-interval = <10>;
+			wakeup-source;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_leds_ixora>;
+
+		led4-green {
+			label = "LED_4_GREEN";
+			gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
+		};
+
+		led4-red {
+			label = "LED_4_RED";
+			gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
+		};
+
+		led5-green {
+			label = "LED_5_GREEN";
+			gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
+		};
+
+		led5-red {
+			label = "LED_5_RED";
+			gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	pwmleds {
+		compatible = "pwm-leds";
+
+		ledpwm1 {
+			label = "PWM1";
+			pwms = <&pwm1 0 50000>;
+			max-brightness = <255>;
+		};
+
+		ledpwm2 {
+			label = "PWM2";
+			pwms = <&pwm2 0 50000>;
+			max-brightness = <255>;
+		};
+
+		ledpwm3 {
+			label = "PWM3";
+			pwms = <&pwm3 0 50000>;
+			max-brightness = <255>;
+		};
+	};
+};
+
+&backlight {
+	brightness-levels = <0 127 191 223 239 247 251 255>;
+	default-brightness-level = <1>;
+	status = "okay";
+};
+
+&can1 {
+	status = "okay";
+};
+
+&can2 {
+	status = "okay";
+};
+
+&hdmi {
+	ddc-i2c-bus = <&i2cddc>;
+	status = "okay";
+};
+
+&i2cddc {
+	status = "okay";
+};
+
+/* GEN1_I2C: I2C1_SDA/SCL on MXM3 209/211 (e.g. RTC on carrier board) */
+&i2c1 {
+	status = "okay";
+
+	eeprom at 50 {
+		compatible = "atmel,24c02";
+		reg = <0x50>;
+	};
+
+	/* M41T0M6 real time clock on carrier board */
+	rtc_i2c: rtc at 68 {
+		compatible = "st,m41t00";
+		reg = <0x68>;
+	};
+};
+
+&ldb {
+	status = "okay";
+};
+
+&pcie {
+	/* active-low meaning opposite of regular PERST# active-low polarity */
+	reset-gpio = <&gpio1 28 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+&pwm1 {
+	status = "okay";
+};
+
+&pwm2 {
+	status = "okay";
+};
+
+&pwm3 {
+	status = "okay";
+};
+
+&pwm4 {
+	status = "okay";
+};
+
+&reg_usb_otg_vbus {
+	status = "okay";
+};
+
+&reg_usb_host_vbus {
+	status = "okay";
+};
+
+&sata {
+	status = "okay";
+};
+
+&sound_spdif {
+	status = "okay";
+};
+
+&spdif {
+	status = "okay";
+};
+
+&uart1 {
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&uart4 {
+	status = "okay";
+};
+
+&uart5 {
+	status = "okay";
+};
+
+&usbh1 {
+	vbus-supply = <&reg_usb_host_vbus>;
+	status = "okay";
+};
+
+&usbotg {
+	vbus-supply = <&reg_usb_otg_vbus>;
+	status = "okay";
+};
+
+/* SD1 */
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_sd_cd>;
+	cd-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>;
+	status = "okay";
+};
+
+&iomuxc {
+	/*
+	 * Mux the Apalis GPIOs
+	 * GPIO5, 6 used by optional fusion_F0710A kernel module
+	 */
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_apalis_gpio1 &pinctrl_apalis_gpio2
+		     &pinctrl_apalis_gpio3 &pinctrl_apalis_gpio4
+		     &pinctrl_apalis_gpio5 &pinctrl_apalis_gpio6
+		     &pinctrl_apalis_gpio7 &pinctrl_apalis_gpio8
+		    >;
+
+	pinctrl_leds_ixora: ledsixoragrp {
+		fsl,pins = <
+			MX6QDL_PAD_SD1_DAT1__GPIO1_IO17 0x1b0b0
+			MX6QDL_PAD_SD1_DAT3__GPIO1_IO21 0x1b0b0
+			MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x1b0b0
+			MX6QDL_PAD_NANDF_D2__GPIO2_IO02 0x1b0b0
+		>;
+	};
+};
-- 
2.5.0



From marcel.ziswiler at toradex.com  Fri Feb  5 08:12:20 2016
From: marcel.ziswiler at toradex.com (Marcel Ziswiler)
Date: Fri,  5 Feb 2016 17:12:20 +0100
Subject: [PATCH v5 1/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D
 SoM
In-Reply-To: <1454688741-4238-1-git-send-email-marcel.ziswiler@toradex.com>
References: <1454688741-4238-1-git-send-email-marcel.ziswiler@toradex.com>
Message-ID: <1454688741-4238-2-git-send-email-marcel.ziswiler@toradex.com>

From: Petr ?tetiar <ynezz at true.cz>

Signed-off-by: Marcel Ziswiler <marcel.ziswiler at toradex.com>
Signed-off-by: Petr ?tetiar <ynezz at true.cz>
Reviewed-by: Stefan Agner <stefan at agner.ch>
---

Changes in v5:
- finally get rid of regulators simple bus as suggested by Lucas, Petr and Shawn
- use reg_xxx: regulator-xxx naming scheme as suggested by Shawn
- get rid of disabled hdmi node as suggested by Shawn
- have a new line between properties and sub-node as suggested by Shawn
- get rid of disabled usbh1 node as suggested by Shawn
- drop iomux/pinctrl function container nodes as suggested by Shawn
- added new lines between nodes as suggested by Shawn
- use consistent pinctrl group node naming schema xxxgrp as suggested by Shawn
- further clean-up and re-order iomux/pinctrl stuff
- configure eMMC reset as required once fast boot mode is used
- properly set usdhc1, usdhc2 and usdhc3 vqmmc-supply rather than vmmc-supply we previously set leading to wrong signal voltage being reported

Changes in v4:
- integrated review feedback from Fabio

Changes in v3:
- integrated review feedback from Petr
- integrated review feedback from Stefan
- move I2C DDC enablement and assignement handling into carrier board DTS where it belongs
- move CAN nodes up a little to keep the alphabetical order
- added an explanatory comment about PWR_I2C usage

Changes in v2:
- clarify exact Apalis iMX6Q/D SoM type in cover letter
- clarify exact Apalis iMX6Q/D module type and Ixora carrier board in model
  node
- got rid of obsolete mmc aliases
- working SGTL5000 audio/sound integration
- working STMPE811 touch screen controller integration
- integrated review feedback from Lucas
- left and even added some more comments as I don't see why putting any
  explanatory comments in dts' should be such a bad thing to do
- completely got rid of the memory node as that is something typically filled
  in by the boot loader e.g. U-Boot
- without the regulators simple-bus it no longer boots
- even though we supposedly shipped a few hundred V1.0a modules drop DCE UART
  support for now and simplify file layout
- replaced obsolete no-1-8-v by mainline supported voltage-ranges = <3300 3300>
  usdhc property and yes card detects are indeed active low (;-p)
- integrated review feedback from Stefan
- fixed Ethernet PHY reset & interrupt (requires Micrel PHY driver to be
  enabled)
- fixed HDMI DDC (requires GPIO-based bitbanging I2C to be enabled)
- fixed SPDIF

 arch/arm/boot/dts/imx6qdl-apalis.dtsi | 984 ++++++++++++++++++++++++++++++++++
 1 file changed, 984 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6qdl-apalis.dtsi

diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
new file mode 100644
index 0000000..b33e5a9
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
@@ -0,0 +1,984 @@
+/*
+ * Copyright 2014-2016 Toradex AG
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License
+ *     version 2 as published by the Free Software Foundation.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	model = "Toradex Apalis iMX6Q/D Module";
+	compatible = "toradex,apalis_imx6q", "fsl,imx6q";
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&pwm4 0 5000000>;
+		status = "disabled";
+	};
+
+	/* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
+	i2cddc: i2c at 0 {
+		compatible = "i2c-gpio";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_i2c_ddc>;
+		gpios = <&gpio3 16 GPIO_ACTIVE_HIGH /* sda */
+			 &gpio2 30 GPIO_ACTIVE_HIGH /* scl */
+			>;
+		i2c-gpio,delay-us = <2>;	/* ~100 kHz */
+		status = "disabled";
+	};
+
+	reg_1p8v: regulator-1p8v {
+		compatible = "regulator-fixed";
+		regulator-name = "1P8V";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-always-on;
+	};
+
+	reg_2p5v: regulator-2p5v {
+		compatible = "regulator-fixed";
+		regulator-name = "2P5V";
+		regulator-min-microvolt = <2500000>;
+		regulator-max-microvolt = <2500000>;
+		regulator-always-on;
+	};
+
+	reg_3p3v: regulator-3p3v {
+		compatible = "regulator-fixed";
+		regulator-name = "3P3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
+	reg_usb_otg_vbus: regulator-usb-otg-vbus {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_regulator_usbotg_pwr>;
+		regulator-name = "usb_otg_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		status = "disabled";
+	};
+
+	/* on module USB hub */
+	reg_usb_host_vbus_hub: regulator-usb-host-vbus-hub {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_regulator_usbhub_pwr>;
+		regulator-name = "usb_host_vbus_hub";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpio = <&gpio3 28 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <2000>;
+		enable-active-high;
+		status = "okay";
+	};
+
+	reg_usb_host_vbus: regulator-usb-host-vbus {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_regulator_usbh_pwr>;
+		regulator-name = "usb_host_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpio =  <&gpio1 0 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		vin-supply = <&reg_usb_host_vbus_hub>;
+		status = "disabled";
+	};
+
+	sound {
+		compatible = "fsl,imx-audio-sgtl5000";
+		model = "imx6q-apalis-sgtl5000";
+		ssi-controller = <&ssi1>;
+		audio-codec = <&codec>;
+		audio-routing =
+			"LINE_IN", "Line In Jack",
+			"MIC_IN", "Mic Jack",
+			"Mic Jack", "Mic Bias",
+			"Headphone Jack", "HP_OUT";
+		mux-int-port = <1>;
+		mux-ext-port = <4>;
+	};
+
+	sound_spdif: sound-spdif {
+		compatible = "fsl,imx-audio-spdif";
+		model = "imx-spdif";
+		spdif-controller = <&spdif>;
+		spdif-in;
+		spdif-out;
+		status = "disabled";
+	};
+};
+
+&audmux {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_audmux>;
+	status = "okay";
+};
+
+&can1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan1>;
+	status = "disabled";
+};
+
+&can2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan2>;
+	status = "disabled";
+};
+
+/* Apalis SPI1 */
+&ecspi1 {
+	fsl,spi-num-chipselects = <1>;
+	cs-gpios = <&gpio5 25 GPIO_ACTIVE_HIGH>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi1>;
+	status = "disabled";
+};
+
+/* Apalis SPI2 */
+&ecspi2 {
+	fsl,spi-num-chipselects = <1>;
+	cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi2>;
+	status = "disabled";
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet>;
+	phy-mode = "rgmii";
+	phy-handle = <&ethphy>;
+	phy-reset-duration = <10>;
+	phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ethphy: ethernet-phy at 7 {
+			interrupt-parent = <&gpio1>;
+			interrupts = <30 IRQ_TYPE_LEVEL_LOW>;
+			reg = <7>;
+		};
+	};
+};
+
+/*
+ * GEN1_I2C: I2C1_SDA/SCL on MXM3 209/211 (e.g. RTC on carrier
+ * board)
+ */
+&i2c1 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1>;
+	status = "disabled";
+};
+
+/*
+ * PWR_I2C: power I2C to audio codec, PMIC, temperature sensor and
+ * touch screen controller
+ */
+&i2c2 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+
+	pmic: pfuze100 at 08 {
+		compatible = "fsl,pfuze100";
+		reg = <0x08>;
+
+		regulators {
+			sw1a_reg: sw1ab {
+				regulator-min-microvolt = <300000>;
+				regulator-max-microvolt = <1875000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw1c_reg: sw1c {
+				regulator-min-microvolt = <300000>;
+				regulator-max-microvolt = <1875000>;
+				regulator-boot-on;
+				regulator-always-on;
+				regulator-ramp-delay = <6250>;
+			};
+
+			sw3a_reg: sw3a {
+				regulator-min-microvolt = <400000>;
+				regulator-max-microvolt = <1975000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			swbst_reg: swbst {
+				regulator-min-microvolt = <5000000>;
+				regulator-max-microvolt = <5150000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			snvs_reg: vsnvs {
+				regulator-min-microvolt = <1000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vref_reg: vrefddr {
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vgen1_reg: vgen1 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1550000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vgen2_reg: vgen2 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1550000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vgen3_reg: vgen3 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vgen4_reg: vgen4 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vgen5_reg: vgen5 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+
+			vgen6_reg: vgen6 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-boot-on;
+				regulator-always-on;
+			};
+		};
+	};
+
+	codec: sgtl5000 at 0a {
+		compatible = "fsl,sgtl5000";
+		reg = <0x0a>;
+		clocks = <&clks 201>;
+		VDDA-supply = <&reg_2p5v>;
+		VDDIO-supply = <&reg_3p3v>;
+	};
+
+	/* STMPE811 touch screen controller */
+	stmpe811 at 41 {
+		compatible = "st,stmpe811";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_touch_int>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x41>;
+		interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-parent = <&gpio4>;
+		interrupt-controller;
+		id = <0>;
+		blocks = <0x5>;
+		irq-trigger = <0x1>;
+
+		stmpe_touchscreen {
+			compatible = "st,stmpe-ts";
+			reg = <0>;
+			/* 3.25 MHz ADC clock speed */
+			st,adc-freq = <1>;
+			/* 8 sample average control */
+			st,ave-ctrl = <3>;
+			/* 7 length fractional part in z */
+			st,fraction-z = <7>;
+			/*
+			 * 50 mA typical 80 mA max touchscreen drivers
+			 * current limit value
+			 */
+			st,i-drive = <1>;
+			/* 12-bit ADC */
+			st,mod-12b = <1>;
+			/* internal ADC reference */
+			st,ref-sel = <0>;
+			/* ADC converstion time: 80 clocks */
+			st,sample-time = <4>;
+			/* 1 ms panel driver settling time */
+			st,settling = <3>;
+			/* 5 ms touch detect interrupt delay */
+			st,touch-det-delay = <5>;
+		};
+	};
+};
+
+/*
+ * GEN2_I2C, CAM: I2C3_SDA/SCL on MXM3 201/203 (unused)
+ */
+&i2c3 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default", "recovery";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	pinctrl-1 = <&pinctrl_i2c3_recovery>;
+	scl-gpios = <&gpio3 17 GPIO_ACTIVE_HIGH>;
+	sda-gpios = <&gpio3 18 GPIO_ACTIVE_HIGH>;
+	status = "disabled";
+};
+
+&pwm1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pwm1>;
+	status = "disabled";
+};
+
+&pwm2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pwm2>;
+	status = "disabled";
+};
+
+&pwm3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pwm3>;
+	status = "disabled";
+};
+
+&pwm4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pwm4>;
+	status = "disabled";
+};
+
+&spdif {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_spdif>;
+	status = "disabled";
+};
+
+&ssi1 {
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1_dte &pinctrl_uart1_ctrl>;
+	fsl,dte-mode;
+	fsl,uart-has-rtscts;
+	status = "disabled";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2_dte>;
+	fsl,dte-mode;
+	fsl,uart-has-rtscts;
+	status = "disabled";
+};
+
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart4_dte>;
+	fsl,dte-mode;
+	status = "disabled";
+};
+
+&uart5 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart5_dte>;
+	fsl,dte-mode;
+	status = "disabled";
+};
+
+&usbotg {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbotg>;
+	disable-over-current;
+	status = "disabled";
+};
+
+/* MMC1 */
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	vqmmc-supply = <&reg_3p3v>;
+	bus-width = <8>;
+	voltage-ranges = <3300 3300>;
+	status = "disabled";
+};
+
+/* SD1 */
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2>;
+	vqmmc-supply = <&reg_3p3v>;
+	bus-width = <4>;
+	voltage-ranges = <3300 3300>;
+	status = "disabled";
+};
+
+/* eMMC */
+&usdhc3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc3>;
+	vqmmc-supply = <&reg_3p3v>;
+	bus-width = <8>;
+	voltage-ranges = <3300 3300>;
+	non-removable;
+	status = "okay";
+};
+
+&weim {
+	status = "disabled";
+};
+
+&iomuxc {
+	/* pins used on module */
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_reset_moci>;
+
+	pinctrl_apalis_gpio1: gpio2io04grp {
+		fsl,pins = <
+			MX6QDL_PAD_NANDF_D4__GPIO2_IO04 0x130b0
+		>;
+	};
+
+	pinctrl_apalis_gpio2: gpio2io05grp {
+		fsl,pins = <
+			MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x130b0
+		>;
+	};
+
+	pinctrl_apalis_gpio3: gpio2io06grp {
+		fsl,pins = <
+			MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x130b0
+		>;
+	};
+
+	pinctrl_apalis_gpio4: gpio2io07grp {
+		fsl,pins = <
+			MX6QDL_PAD_NANDF_D7__GPIO2_IO07 0x130b0
+		>;
+	};
+
+	pinctrl_apalis_gpio5: gpio6io10grp {
+		fsl,pins = <
+			MX6QDL_PAD_NANDF_RB0__GPIO6_IO10 0x130b0
+		>;
+	};
+
+	pinctrl_apalis_gpio6: gpio6io09grp {
+		fsl,pins = <
+			MX6QDL_PAD_NANDF_WP_B__GPIO6_IO09 0x130b0
+		>;
+	};
+
+	pinctrl_apalis_gpio7: gpio1io02grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x130b0
+		>;
+	};
+
+	pinctrl_apalis_gpio8: gpio1io06grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x130b0
+		>;
+	};
+
+	pinctrl_audmux: audmuxgrp {
+		fsl,pins = <
+			MX6QDL_PAD_DISP0_DAT20__AUD4_TXC	0x130b0
+			MX6QDL_PAD_DISP0_DAT21__AUD4_TXD	0x130b0
+			MX6QDL_PAD_DISP0_DAT22__AUD4_TXFS	0x130b0
+			MX6QDL_PAD_DISP0_DAT23__AUD4_RXD	0x130b0
+			/* SGTL5000 sys_mclk */
+			MX6QDL_PAD_GPIO_5__CCM_CLKO1		0x130b0
+		>;
+	};
+
+	pinctrl_cam_mclk: cammclkgrp {
+		fsl,pins = <
+			/* CAM sys_mclk */
+			MX6QDL_PAD_NANDF_CS2__CCM_CLKO2 0x00b0
+		>;
+	};
+
+	pinctrl_ecspi1: ecspi1grp {
+		fsl,pins = <
+			MX6QDL_PAD_CSI0_DAT6__ECSPI1_MISO 0x100b1
+			MX6QDL_PAD_CSI0_DAT5__ECSPI1_MOSI 0x100b1
+			MX6QDL_PAD_CSI0_DAT4__ECSPI1_SCLK 0x100b1
+			/* SPI1 cs */
+			MX6QDL_PAD_CSI0_DAT7__GPIO5_IO25 0x000b1
+		>;
+	};
+
+	pinctrl_ecspi2: ecspi2grp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_OE__ECSPI2_MISO 0x100b1
+			MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI 0x100b1
+			MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK 0x100b1
+			/* SPI2 cs */
+			MX6QDL_PAD_EIM_RW__GPIO2_IO26 0x000b1
+		>;
+	};
+
+	pinctrl_enet: enetgrp {
+		fsl,pins = <
+			MX6QDL_PAD_ENET_MDIO__ENET_MDIO		0x100b0
+			MX6QDL_PAD_ENET_MDC__ENET_MDC		0x100b0
+			MX6QDL_PAD_RGMII_TXC__RGMII_TXC		0x100b0
+			MX6QDL_PAD_RGMII_TD0__RGMII_TD0		0x100b0
+			MX6QDL_PAD_RGMII_TD1__RGMII_TD1		0x100b0
+			MX6QDL_PAD_RGMII_TD2__RGMII_TD2		0x100b0
+			MX6QDL_PAD_RGMII_TD3__RGMII_TD3		0x100b0
+			MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL	0x100b0
+			MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK	0x100b0
+			MX6QDL_PAD_RGMII_RXC__RGMII_RXC		0x1b0b0
+			MX6QDL_PAD_RGMII_RD0__RGMII_RD0		0x1b0b0
+			MX6QDL_PAD_RGMII_RD1__RGMII_RD1		0x1b0b0
+			MX6QDL_PAD_RGMII_RD2__RGMII_RD2		0x1b0b0
+			MX6QDL_PAD_RGMII_RD3__RGMII_RD3		0x1b0b0
+			MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL	0x1b0b0
+			/* Ethernet PHY reset */
+			MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25	0x000b0
+			/* Ethernet PHY interrupt */
+			MX6QDL_PAD_ENET_TXD0__GPIO1_IO30	0x000b1
+		>;
+	};
+
+	pinctrl_flexcan1: flexcan1grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_7__FLEXCAN1_TX 0x1b0b0
+			MX6QDL_PAD_GPIO_8__FLEXCAN1_RX 0x1b0b0
+		>;
+	};
+
+	pinctrl_flexcan2: flexcan2grp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x1b0b0
+			MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x1b0b0
+		>;
+	};
+
+	pinctrl_gpio_keys: gpio1io04grp {
+		fsl,pins = <
+			/* Power button */
+			MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x1b0b0
+		>;
+	};
+
+	pinctrl_hdmi_cec: hdmicecgrp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
+		>;
+	};
+
+	pinctrl_i2c_ddc: gpioi2cddcgrp {
+		fsl,pins = <
+			/* DDC bitbang */
+			MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
+			MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x1b0b0
+		>;
+	};
+
+	pinctrl_i2c1: i2c1grp {
+		fsl,pins = <
+			MX6QDL_PAD_CSI0_DAT8__I2C1_SDA 0x4001b8b1
+			MX6QDL_PAD_CSI0_DAT9__I2C1_SCL 0x4001b8b1
+		>;
+	};
+
+	pinctrl_i2c2: i2c2grp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+			MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+		>;
+	};
+
+	pinctrl_i2c3: i2c3grp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_D17__I2C3_SCL 0x4001b8b1
+			MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
+		>;
+	};
+
+	pinctrl_i2c3_recovery: i2c3recoverygrp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_D17__GPIO3_IO17 0x4001b8b1
+			MX6QDL_PAD_EIM_D18__GPIO3_IO18 0x4001b8b1
+		>;
+	};
+
+	pinctrl_ipu1_csi0: ipu1csi0grp { /* parallel camera */
+		fsl,pins = <
+			MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12  0xb0b1
+			MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13  0xb0b1
+			MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14  0xb0b1
+			MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15  0xb0b1
+			MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16  0xb0b1
+			MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17  0xb0b1
+			MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18  0xb0b1
+			MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19  0xb0b1
+			MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0xb0b1
+			MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC    0xb0b1
+			MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC   0xb0b1
+		>;
+	};
+
+	pinctrl_ipu1_lcdif: ipu1lcdifgrp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_A16__IPU1_DI1_DISP_CLK	0x61
+			/* DE */
+			MX6QDL_PAD_EIM_DA10__IPU1_DI1_PIN15	0x61
+			/* HSync */
+			MX6QDL_PAD_EIM_DA11__IPU1_DI1_PIN02	0x61
+			/* VSync */
+			MX6QDL_PAD_EIM_DA12__IPU1_DI1_PIN03	0x61
+			MX6QDL_PAD_EIM_DA9__IPU1_DISP1_DATA00	0x61
+			MX6QDL_PAD_EIM_DA8__IPU1_DISP1_DATA01	0x61
+			MX6QDL_PAD_EIM_DA7__IPU1_DISP1_DATA02	0x61
+			MX6QDL_PAD_EIM_DA6__IPU1_DISP1_DATA03	0x61
+			MX6QDL_PAD_EIM_DA5__IPU1_DISP1_DATA04	0x61
+			MX6QDL_PAD_EIM_DA4__IPU1_DISP1_DATA05	0x61
+			MX6QDL_PAD_EIM_DA3__IPU1_DISP1_DATA06	0x61
+			MX6QDL_PAD_EIM_DA2__IPU1_DISP1_DATA07	0x61
+			MX6QDL_PAD_EIM_DA1__IPU1_DISP1_DATA08	0x61
+			MX6QDL_PAD_EIM_DA0__IPU1_DISP1_DATA09	0x61
+			MX6QDL_PAD_EIM_EB1__IPU1_DISP1_DATA10	0x61
+			MX6QDL_PAD_EIM_EB0__IPU1_DISP1_DATA11	0x61
+			MX6QDL_PAD_EIM_A17__IPU1_DISP1_DATA12	0x61
+			MX6QDL_PAD_EIM_A18__IPU1_DISP1_DATA13	0x61
+			MX6QDL_PAD_EIM_A19__IPU1_DISP1_DATA14	0x61
+			MX6QDL_PAD_EIM_A20__IPU1_DISP1_DATA15	0x61
+			MX6QDL_PAD_EIM_A21__IPU1_DISP1_DATA16	0x61
+			MX6QDL_PAD_EIM_A22__IPU1_DISP1_DATA17	0x61
+			MX6QDL_PAD_EIM_A23__IPU1_DISP1_DATA18	0x61
+			MX6QDL_PAD_EIM_A24__IPU1_DISP1_DATA19	0x61
+			MX6QDL_PAD_EIM_D31__IPU1_DISP1_DATA20	0x61
+			MX6QDL_PAD_EIM_D30__IPU1_DISP1_DATA21	0x61
+			MX6QDL_PAD_EIM_D26__IPU1_DISP1_DATA22	0x61
+			MX6QDL_PAD_EIM_D27__IPU1_DISP1_DATA23	0x61
+		>;
+	};
+
+	pinctrl_ipu2_vdac: ipu2vdacgrp {
+		fsl,pins = <
+			MX6QDL_PAD_DI0_DISP_CLK__IPU2_DI0_DISP_CLK 0xd1
+			MX6QDL_PAD_DI0_PIN15__IPU2_DI0_PIN15       0xd1
+			MX6QDL_PAD_DI0_PIN2__IPU2_DI0_PIN02        0xd1
+			MX6QDL_PAD_DI0_PIN3__IPU2_DI0_PIN03        0xd1
+			MX6QDL_PAD_DISP0_DAT0__IPU2_DISP0_DATA00   0xf9
+			MX6QDL_PAD_DISP0_DAT1__IPU2_DISP0_DATA01   0xf9
+			MX6QDL_PAD_DISP0_DAT2__IPU2_DISP0_DATA02   0xf9
+			MX6QDL_PAD_DISP0_DAT3__IPU2_DISP0_DATA03   0xf9
+			MX6QDL_PAD_DISP0_DAT4__IPU2_DISP0_DATA04   0xf9
+			MX6QDL_PAD_DISP0_DAT5__IPU2_DISP0_DATA05   0xf9
+			MX6QDL_PAD_DISP0_DAT6__IPU2_DISP0_DATA06   0xf9
+			MX6QDL_PAD_DISP0_DAT7__IPU2_DISP0_DATA07   0xf9
+			MX6QDL_PAD_DISP0_DAT8__IPU2_DISP0_DATA08   0xf9
+			MX6QDL_PAD_DISP0_DAT9__IPU2_DISP0_DATA09   0xf9
+			MX6QDL_PAD_DISP0_DAT10__IPU2_DISP0_DATA10  0xf9
+			MX6QDL_PAD_DISP0_DAT11__IPU2_DISP0_DATA11  0xf9
+			MX6QDL_PAD_DISP0_DAT12__IPU2_DISP0_DATA12  0xf9
+			MX6QDL_PAD_DISP0_DAT13__IPU2_DISP0_DATA13  0xf9
+			MX6QDL_PAD_DISP0_DAT14__IPU2_DISP0_DATA14  0xf9
+			MX6QDL_PAD_DISP0_DAT15__IPU2_DISP0_DATA15  0xf9
+		>;
+	};
+
+	pinctrl_mmc_cd: gpiommccdgrp {
+		fsl,pins = <
+			 /* MMC1 CD */
+			MX6QDL_PAD_DI0_PIN4__GPIO4_IO20 0x000b0
+		>;
+	};
+
+	pinctrl_pwm1: pwm1grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_9__PWM1_OUT 0x1b0b1
+		>;
+	};
+
+	pinctrl_pwm2: pwm2grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_1__PWM2_OUT 0x1b0b1
+		>;
+	};
+
+	pinctrl_pwm3: pwm3grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
+		>;
+	};
+
+	pinctrl_pwm4: pwm4grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD4_DAT2__PWM4_OUT 0x1b0b1
+		>;
+	};
+
+	pinctrl_regulator_usbh_pwr: gpioregusbhpwrgrp {
+		fsl,pins = <
+			/* USBH_EN */
+			MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x0f058
+		>;
+	};
+
+	pinctrl_regulator_usbhub_pwr: gpioregusbhubpwrgrp {
+		fsl,pins = <
+			/* USBH_HUB_EN */
+			MX6QDL_PAD_EIM_D28__GPIO3_IO28 0x0f058
+		>;
+	};
+
+	pinctrl_regulator_usbotg_pwr: gpioregusbotgpwrgrp {
+		fsl,pins = <
+			/* USBO1 power en */
+			MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x0f058
+		>;
+	};
+
+	pinctrl_reset_moci: gpioresetmocigrp {
+		fsl,pins = <
+			/* RESET_MOCI control */
+			MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28 0x0f058
+		>;
+	};
+
+	pinctrl_sd_cd: gpiosdcdgrp {
+		fsl,pins = <
+			/* SD1 CD */
+			MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x000b0
+		>;
+	};
+
+	pinctrl_spdif: spdifgrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_16__SPDIF_IN  0x1b0b0
+			MX6QDL_PAD_GPIO_17__SPDIF_OUT 0x1b0b0
+		>;
+	};
+
+	pinctrl_touch_int: gpiotouchintgrp {
+		fsl,pins = <
+			/* STMPE811 interrupt */
+			MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
+		>;
+	};
+
+	pinctrl_uart1_dce: uart1dcegrp {
+		fsl,pins = <
+			MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
+			MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
+		>;
+	};
+
+	/* DTE mode */
+	pinctrl_uart1_dte: uart1dtegrp {
+		fsl,pins = <
+			MX6QDL_PAD_CSI0_DAT10__UART1_RX_DATA 0x1b0b1
+			MX6QDL_PAD_CSI0_DAT11__UART1_TX_DATA 0x1b0b1
+			MX6QDL_PAD_EIM_D19__UART1_RTS_B 0x1b0b1
+			MX6QDL_PAD_EIM_D20__UART1_CTS_B 0x1b0b1
+		>;
+	};
+
+	/* Additional DTR, DSR, DCD */
+	pinctrl_uart1_ctrl: uart1ctrlgrp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_D23__UART1_DCD_B 0x1b0b0
+			MX6QDL_PAD_EIM_D24__UART1_DTR_B 0x1b0b0
+			MX6QDL_PAD_EIM_D25__UART1_DSR_B 0x1b0b0
+		>;
+	};
+
+	pinctrl_uart2_dce: uart2dcegrp {
+		fsl,pins = <
+			MX6QDL_PAD_SD4_DAT4__UART2_RX_DATA	0x1b0b1
+			MX6QDL_PAD_SD4_DAT7__UART2_TX_DATA	0x1b0b1
+		>;
+	};
+
+	/* DTE mode */
+	pinctrl_uart2_dte: uart2dtegrp {
+		fsl,pins = <
+			MX6QDL_PAD_SD4_DAT4__UART2_TX_DATA	0x1b0b1
+			MX6QDL_PAD_SD4_DAT7__UART2_RX_DATA	0x1b0b1
+			MX6QDL_PAD_SD4_DAT6__UART2_RTS_B	0x1b0b1
+			MX6QDL_PAD_SD4_DAT5__UART2_CTS_B	0x1b0b1
+		>;
+	};
+
+	pinctrl_uart4_dce: uart4dcegrp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
+			MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
+		>;
+	};
+
+	/* DTE mode */
+	pinctrl_uart4_dte: uart4dtegrp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL0__UART4_RX_DATA 0x1b0b1
+			MX6QDL_PAD_KEY_ROW0__UART4_TX_DATA 0x1b0b1
+		>;
+	};
+
+	pinctrl_uart5_dce: uart5dcegrp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL1__UART5_TX_DATA 0x1b0b1
+			MX6QDL_PAD_KEY_ROW1__UART5_RX_DATA 0x1b0b1
+		>;
+	};
+
+	/* DTE mode */
+	pinctrl_uart5_dte: uart5dtegrp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL1__UART5_RX_DATA 0x1b0b1
+			MX6QDL_PAD_KEY_ROW1__UART5_TX_DATA 0x1b0b1
+		>;
+	};
+
+	pinctrl_usbotg: usbotggrp {
+		fsl,pins = <
+			MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID 0x17059
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD1_CMD__SD1_CMD    0x17071
+			MX6QDL_PAD_SD1_CLK__SD1_CLK    0x10071
+			MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17071
+			MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17071
+			MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17071
+			MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17071
+			MX6QDL_PAD_NANDF_D0__SD1_DATA4 0x17071
+			MX6QDL_PAD_NANDF_D1__SD1_DATA5 0x17071
+			MX6QDL_PAD_NANDF_D2__SD1_DATA6 0x17071
+			MX6QDL_PAD_NANDF_D3__SD1_DATA7 0x17071
+		>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD2_CMD__SD2_CMD    0x17071
+			MX6QDL_PAD_SD2_CLK__SD2_CLK    0x10071
+			MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17071
+			MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17071
+			MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17071
+			MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17071
+		>;
+	};
+
+	pinctrl_usdhc3: usdhc3grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD3_CMD__SD3_CMD    0x17059
+			MX6QDL_PAD_SD3_CLK__SD3_CLK    0x10059
+			MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+			MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+			MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+			MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+			MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
+			MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
+			MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
+			MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
+			/* eMMC reset */
+			MX6QDL_PAD_SD3_RST__SD3_RESET  0x17059
+		>;
+	};
+
+	pinctrl_usdhc3_100mhz: usdhc3100mhzgrp {
+		fsl,pins = <
+			MX6QDL_PAD_SD3_CMD__SD3_CMD    0x170b9
+			MX6QDL_PAD_SD3_CLK__SD3_CLK    0x100b9
+			MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x170b9
+			MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x170b9
+			MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x170b9
+			MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x170b9
+			MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x170b9
+			MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x170b9
+			MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x170b9
+			MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x170b9
+			/* eMMC reset */
+			MX6QDL_PAD_SD3_RST__SD3_RESET  0x170b9
+		>;
+	};
+
+	pinctrl_usdhc3_200mhz: usdhc3200mhzgrp {
+		fsl,pins = <
+			MX6QDL_PAD_SD3_CMD__SD3_CMD    0x170f9
+			MX6QDL_PAD_SD3_CLK__SD3_CLK    0x100f9
+			MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x170f9
+			MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x170f9
+			MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x170f9
+			MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x170f9
+			MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x170f9
+			MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x170f9
+			MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x170f9
+			MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x170f9
+			/* eMMC reset */
+			MX6QDL_PAD_SD3_RST__SD3_RESET  0x170f9
+		>;
+	};
+};
-- 
2.5.0



From andriy.shevchenko at linux.intel.com  Fri Feb  5 08:12:09 2016
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 05 Feb 2016 18:12:09 +0200
Subject: Common/typical fractional divider HW API
In-Reply-To: <56B4C775.50808@free.fr>
References: <56B4B67D.2080707@free.fr>
 <1454684758.31169.77.camel@linux.intel.com> <56B4C775.50808@free.fr>
Message-ID: <1454688729.31169.87.camel@linux.intel.com>

On Fri, 2016-02-05 at 17:01 +0100, Mason wrote:

> So, do you agree that
> 
> ? DIV = 2^I * (1 + F/256)
> 
> gives a more useful DIV distribution than
> 
> ? DIV = I + F/16

If you can change hardware why not to use any existing approach which
suits better to your device?

I don't remember any existing, though I didn't check much, divider
register which takes something like that.

> > Also it's possible to convert clock providers for, e.g., UARTs to
> > use
> > this kind of divider.
> 
> I'm not sure how to parse that. I'm using the divider driver
> for a CPU clock, to do D(V)FS in cpufreq.

If you are using custom stuff for custom hardware, I hope it's okay.
But if we are talking about generic solutions (like clk-fractional-
divider), I would suggest to consider existing users / hardware.

What I saw is mostly about

I [0 .. 2^n - 1]
F [0 .. 2^k - 1]
n + k < 32

And I + 1 / (2^k - F) as a formula.

-- 
Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Intel Finland Oy



From ard.biesheuvel at linaro.org  Fri Feb  5 08:20:14 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 5 Feb 2016 17:20:14 +0100
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <20160205160054.GG6076@e104818-lin.cambridge.arm.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160204151303.GB6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu9n=bmsZ=UOBiLWzaG2JSsbdC8k1mB7yFbH0czrbXS-1g@mail.gmail.com>
 <20160205154234.GF6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-poQiuc7+O38n93Xt2o-SYi3kYD0k_9+-6T0=FXV9uXA@mail.gmail.com>
 <20160205160054.GG6076@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu8g7FHHZgmbFww_XZjf5J1utmigwBiNqCg8a3crfB4xFA@mail.gmail.com>

On 5 February 2016 at 17:00, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Fri, Feb 05, 2016 at 04:53:10PM +0100, Ard Biesheuvel wrote:
>> On 5 February 2016 at 16:42, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > On Thu, Feb 04, 2016 at 04:31:59PM +0100, Ard Biesheuvel wrote:
>> >> On 4 February 2016 at 16:13, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> >> > On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
>> >> >> This adds support for emitting PLTs at module load time for relative
>> >> >> branches that are out of range. This is a prerequisite for KASLR, which
>> >> >> may place the kernel and the modules anywhere in the vmalloc area,
>> >> >> making it more likely that branch target offsets exceed the maximum
>> >> >> range of +/- 128 MB.
>> >> >
>> >> > Any downside to trying to keep the kernel+modules coupled together so
>> >> > that we avoid the PLT?
>> >>
>> >> First of all, note that it is unlikely that the PLTs are ever required
>> >> in practice, considering that either
>> >> a) the kernel is loaded at the default location right at the base of
>> >> the vmalloc range, and in this case, the module space is reserved for
>> >> modules only, or
>> >> b) the kernel is loaded at some random offset in the 240+ GB vmalloc
>> >> space, and it is unlikely that all VMA space around the kernel happens
>> >> to be given out to non-randomized vmalloc/ioremap allocations
>> >
>> > My worry is that we merge some code that's rarely tested.
>>
>> I understand. But unfortunately, having corner cases that are unlikely
>> but not impossible comes with the territory of randomization.
>>
>> Alternatively, we could take the performance hit if KASLR is in effect
>> and allocate each module completely randomly as well. This way, the
>> code is always exercised (for now), and we can always backpedal later
>> if the performance is measurably worse.
>
> I'm fine with this. You can post it as a separate patch that we can
> easily revert/modify later (like turning it into a config option).
>

OK, I will hack something up


From arnd at arndb.de  Fri Feb  5 08:20:48 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri,  5 Feb 2016 17:20:48 +0100
Subject: [PATCH 1/3] ARM: ixp4xx: use normal prototype for {read, write}s{b, w,
 l}
Message-ID: <1454689262-613421-1-git-send-email-arnd@arndb.de>

ixp4xx defines the arguments to its __indirect_writesb() and other
functions as pointers to fixed-size data. This is not necessarily
wrong, and it works most of the time, but it causes warnings in
at least one driver:

drivers/net/ethernet/smsc/smc91x.c: In function 'smc_rcv':
drivers/net/ethernet/smsc/smc91x.c:495:21: error: passing argument 2 of '__indirect_readsw' from incompatible pointer type [-Werror=incompatible-pointer-types]
   SMC_PULL_DATA(lp, data, packet_len - 4);

All other definitions of the same functions pass void pointers,
so doing the same here avoids the warnings.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-ixp4xx/include/mach/io.h | 23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/include/mach/io.h b/arch/arm/mach-ixp4xx/include/mach/io.h
index 7a0c13bf4269..d04d3ec97ac0 100644
--- a/arch/arm/mach-ixp4xx/include/mach/io.h
+++ b/arch/arm/mach-ixp4xx/include/mach/io.h
@@ -95,8 +95,10 @@ static inline void __indirect_writeb(u8 value, volatile void __iomem *p)
 }
 
 static inline void __indirect_writesb(volatile void __iomem *bus_addr,
-				      const u8 *vaddr, int count)
+				      const void *p, int count)
 {
+	const u8 *vaddr = p;
+
 	while (count--)
 		writeb(*vaddr++, bus_addr);
 }
@@ -118,8 +120,10 @@ static inline void __indirect_writew(u16 value, volatile void __iomem *p)
 }
 
 static inline void __indirect_writesw(volatile void __iomem *bus_addr,
-				      const u16 *vaddr, int count)
+				      const void *p, int count)
 {
+	const u16 *vaddr = p;
+
 	while (count--)
 		writew(*vaddr++, bus_addr);
 }
@@ -137,8 +141,9 @@ static inline void __indirect_writel(u32 value, volatile void __iomem *p)
 }
 
 static inline void __indirect_writesl(volatile void __iomem *bus_addr,
-				      const u32 *vaddr, int count)
+				      const void *p, int count)
 {
+	const u32 *vaddr = p;
 	while (count--)
 		writel(*vaddr++, bus_addr);
 }
@@ -160,8 +165,10 @@ static inline u8 __indirect_readb(const volatile void __iomem *p)
 }
 
 static inline void __indirect_readsb(const volatile void __iomem *bus_addr,
-				     u8 *vaddr, u32 count)
+				     void *p, u32 count)
 {
+	u8 *vaddr = p;
+
 	while (count--)
 		*vaddr++ = readb(bus_addr);
 }
@@ -183,8 +190,10 @@ static inline u16 __indirect_readw(const volatile void __iomem *p)
 }
 
 static inline void __indirect_readsw(const volatile void __iomem *bus_addr,
-				     u16 *vaddr, u32 count)
+				     void *p, u32 count)
 {
+	u16 *vaddr = p;
+
 	while (count--)
 		*vaddr++ = readw(bus_addr);
 }
@@ -204,8 +213,10 @@ static inline u32 __indirect_readl(const volatile void __iomem *p)
 }
 
 static inline void __indirect_readsl(const volatile void __iomem *bus_addr,
-				     u32 *vaddr, u32 count)
+				     void *p, u32 count)
 {
+	u32 *vaddr = p;
+
 	while (count--)
 		*vaddr++ = readl(bus_addr);
 }
-- 
2.7.0



From arnd at arndb.de  Fri Feb  5 08:20:49 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri,  5 Feb 2016 17:20:49 +0100
Subject: [PATCH 2/3] ARM: ixp4xx: avoid warning about ioport_map() macro
 argument processing
In-Reply-To: <1454689262-613421-1-git-send-email-arnd@arndb.de>
References: <1454689262-613421-1-git-send-email-arnd@arndb.de>
Message-ID: <1454689262-613421-2-git-send-email-arnd@arndb.de>

We get a harmless compiler warning when building the cs89x0 driver
for ixp4xx:

drivers/net/ethernet/cirrus/cs89x0.c: In function 'cs89x0_ioport_probe':
drivers/net/ethernet/cirrus/cs89x0.c:1602:28: warning: suggest parentheses around '+' in operand of '&' [-Wparentheses]
  io_mem = ioport_map(ioport & ~3, NETCARD_IO_EXTENT);

Simply adding parentheses in the macro avoids the warning

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-ixp4xx/include/mach/io.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-ixp4xx/include/mach/io.h b/arch/arm/mach-ixp4xx/include/mach/io.h
index d04d3ec97ac0..d8c2a4dc54d7 100644
--- a/arch/arm/mach-ixp4xx/include/mach/io.h
+++ b/arch/arm/mach-ixp4xx/include/mach/io.h
@@ -534,7 +534,7 @@ static inline void iowrite32_rep(void __iomem *addr, const void *vaddr,
 #endif
 }
 
-#define	ioport_map(port, nr)		((void __iomem*)(port + PIO_OFFSET))
+#define	ioport_map(port, nr)		((void __iomem*)((port) + PIO_OFFSET))
 #define	ioport_unmap(addr)
 #endif /* CONFIG_PCI */
 
-- 
2.7.0



From arnd at arndb.de  Fri Feb  5 08:20:50 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri,  5 Feb 2016 17:20:50 +0100
Subject: [PATCH 3/3] ARM: ixp4xx: move indirect I/O into common-pci.c
In-Reply-To: <1454689262-613421-1-git-send-email-arnd@arndb.de>
References: <1454689262-613421-1-git-send-email-arnd@arndb.de>
Message-ID: <1454689262-613421-3-git-send-email-arnd@arndb.de>

The pointer comparison in is_pci_memory() confuses gcc, so it
starts throwing bogus warnings about the use of possibly uninitialized
variables:

drivers/ata/ahci_qoriq.c: In function 'ahci_qoriq_hardreset':
arch/arm/include/asm/io.h:101:2: error: 'px_is' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/crypto/ixp4xx_crypto.c: In function 'aead_perform':
drivers/crypto/ixp4xx_crypto.c:1072:5: error: 'lastlen' may be used uninitialized in this function [-Werror=maybe-uninitialized]

The code is that gets warned about is correct, and we should not warn
about this. Moving the code into a .c file makes the object files
smaller and avoids the warnings.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-ixp4xx/common-pci.c      | 98 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-ixp4xx/include/mach/io.h | 95 +++-----------------------------
 2 files changed, 104 insertions(+), 89 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/common-pci.c b/arch/arm/mach-ixp4xx/common-pci.c
index 4977296f0c78..6f5d92f88062 100644
--- a/arch/arm/mach-ixp4xx/common-pci.c
+++ b/arch/arm/mach-ixp4xx/common-pci.c
@@ -166,6 +166,104 @@ int ixp4xx_pci_write(u32 addr, u32 cmd, u32 data)
 	return retval;
 }
 
+#ifdef CONFIG_IXP4XX_INDIRECT_PCI
+void __indirect_writeb(u8 value, volatile void __iomem *p)
+{
+	u32 addr = (u32)p;
+	u32 n, byte_enables, data;
+
+	if (!is_pci_memory(addr)) {
+		__raw_writeb(value, p);
+		return;
+	}
+
+	n = addr % 4;
+	byte_enables = (0xf & ~BIT(n)) << IXP4XX_PCI_NP_CBE_BESL;
+	data = value << (8*n);
+	ixp4xx_pci_write(addr, byte_enables | NP_CMD_MEMWRITE, data);
+}
+EXPORT_SYMBOL(__indirect_writeb);
+
+void __indirect_writew(u16 value, volatile void __iomem *p)
+{
+	u32 addr = (u32)p;
+	u32 n, byte_enables, data;
+
+	if (!is_pci_memory(addr)) {
+		__raw_writew(value, p);
+		return;
+	}
+
+	n = addr % 4;
+	byte_enables = (0xf & ~(BIT(n) | BIT(n+1))) << IXP4XX_PCI_NP_CBE_BESL;
+	data = value << (8*n);
+	ixp4xx_pci_write(addr, byte_enables | NP_CMD_MEMWRITE, data);
+}
+EXPORT_SYMBOL(__indirect_writew);
+
+void __indirect_writel(u32 value, volatile void __iomem *p)
+{
+	u32 addr = (__force u32)p;
+
+	if (!is_pci_memory(addr)) {
+		__raw_writel(value, p);
+		return;
+	}
+
+	ixp4xx_pci_write(addr, NP_CMD_MEMWRITE, value);
+}
+EXPORT_SYMBOL(__indirect_writel);
+
+u8 __indirect_readb(const volatile void __iomem *p)
+{
+	u32 addr = (u32)p;
+	u32 n, byte_enables, data;
+
+	if (!is_pci_memory(addr))
+		return __raw_readb(p);
+
+	n = addr % 4;
+	byte_enables = (0xf & ~BIT(n)) << IXP4XX_PCI_NP_CBE_BESL;
+	if (ixp4xx_pci_read(addr, byte_enables | NP_CMD_MEMREAD, &data))
+		return 0xff;
+
+	return data >> (8*n);
+}
+EXPORT_SYMBOL(__indirect_readb);
+
+u16 __indirect_readw(const volatile void __iomem *p)
+{
+	u32 addr = (u32)p;
+	u32 n, byte_enables, data;
+
+	if (!is_pci_memory(addr))
+		return __raw_readw(p);
+
+	n = addr % 4;
+	byte_enables = (0xf & ~(BIT(n) | BIT(n+1))) << IXP4XX_PCI_NP_CBE_BESL;
+	if (ixp4xx_pci_read(addr, byte_enables | NP_CMD_MEMREAD, &data))
+		return 0xffff;
+
+	return data>>(8*n);
+}
+EXPORT_SYMBOL(__indirect_readw);
+
+u32 __indirect_readl(const volatile void __iomem *p)
+{
+	u32 addr = (__force u32)p;
+	u32 data;
+
+	if (!is_pci_memory(addr))
+		return __raw_readl(p);
+
+	if (ixp4xx_pci_read(addr, NP_CMD_MEMREAD, &data))
+		return 0xffffffff;
+
+	return data;
+}
+EXPORT_SYMBOL(__indirect_readl);
+#endif
+
 static u32 ixp4xx_config_addr(u8 bus_num, u16 devfn, int where)
 {
 	u32 addr;
diff --git a/arch/arm/mach-ixp4xx/include/mach/io.h b/arch/arm/mach-ixp4xx/include/mach/io.h
index d8c2a4dc54d7..e770858b490a 100644
--- a/arch/arm/mach-ixp4xx/include/mach/io.h
+++ b/arch/arm/mach-ixp4xx/include/mach/io.h
@@ -78,21 +78,12 @@ static inline int is_pci_memory(u32 addr)
 #define readsw(p, v, l)			__indirect_readsw(p, v, l)
 #define readsl(p, v, l)			__indirect_readsl(p, v, l)
 
-static inline void __indirect_writeb(u8 value, volatile void __iomem *p)
-{
-	u32 addr = (u32)p;
-	u32 n, byte_enables, data;
-
-	if (!is_pci_memory(addr)) {
-		__raw_writeb(value, p);
-		return;
-	}
-
-	n = addr % 4;
-	byte_enables = (0xf & ~BIT(n)) << IXP4XX_PCI_NP_CBE_BESL;
-	data = value << (8*n);
-	ixp4xx_pci_write(addr, byte_enables | NP_CMD_MEMWRITE, data);
-}
+void __indirect_writeb(u8 value, volatile void __iomem *p);
+void __indirect_writew(u16 value, volatile void __iomem *p);
+void __indirect_writel(u32 value, volatile void __iomem *p);
+u8 __indirect_readb(const volatile void __iomem *p);
+u16 __indirect_readw(const volatile void __iomem *p);
+u32 __indirect_readl(const volatile void __iomem *p);
 
 static inline void __indirect_writesb(volatile void __iomem *bus_addr,
 				      const void *p, int count)
@@ -103,22 +94,6 @@ static inline void __indirect_writesb(volatile void __iomem *bus_addr,
 		writeb(*vaddr++, bus_addr);
 }
 
-static inline void __indirect_writew(u16 value, volatile void __iomem *p)
-{
-	u32 addr = (u32)p;
-	u32 n, byte_enables, data;
-
-	if (!is_pci_memory(addr)) {
-		__raw_writew(value, p);
-		return;
-	}
-
-	n = addr % 4;
-	byte_enables = (0xf & ~(BIT(n) | BIT(n+1))) << IXP4XX_PCI_NP_CBE_BESL;
-	data = value << (8*n);
-	ixp4xx_pci_write(addr, byte_enables | NP_CMD_MEMWRITE, data);
-}
-
 static inline void __indirect_writesw(volatile void __iomem *bus_addr,
 				      const void *p, int count)
 {
@@ -128,18 +103,6 @@ static inline void __indirect_writesw(volatile void __iomem *bus_addr,
 		writew(*vaddr++, bus_addr);
 }
 
-static inline void __indirect_writel(u32 value, volatile void __iomem *p)
-{
-	u32 addr = (__force u32)p;
-
-	if (!is_pci_memory(addr)) {
-		__raw_writel(value, p);
-		return;
-	}
-
-	ixp4xx_pci_write(addr, NP_CMD_MEMWRITE, value);
-}
-
 static inline void __indirect_writesl(volatile void __iomem *bus_addr,
 				      const void *p, int count)
 {
@@ -148,22 +111,6 @@ static inline void __indirect_writesl(volatile void __iomem *bus_addr,
 		writel(*vaddr++, bus_addr);
 }
 
-static inline u8 __indirect_readb(const volatile void __iomem *p)
-{
-	u32 addr = (u32)p;
-	u32 n, byte_enables, data;
-
-	if (!is_pci_memory(addr))
-		return __raw_readb(p);
-
-	n = addr % 4;
-	byte_enables = (0xf & ~BIT(n)) << IXP4XX_PCI_NP_CBE_BESL;
-	if (ixp4xx_pci_read(addr, byte_enables | NP_CMD_MEMREAD, &data))
-		return 0xff;
-
-	return data >> (8*n);
-}
-
 static inline void __indirect_readsb(const volatile void __iomem *bus_addr,
 				     void *p, u32 count)
 {
@@ -173,22 +120,6 @@ static inline void __indirect_readsb(const volatile void __iomem *bus_addr,
 		*vaddr++ = readb(bus_addr);
 }
 
-static inline u16 __indirect_readw(const volatile void __iomem *p)
-{
-	u32 addr = (u32)p;
-	u32 n, byte_enables, data;
-
-	if (!is_pci_memory(addr))
-		return __raw_readw(p);
-
-	n = addr % 4;
-	byte_enables = (0xf & ~(BIT(n) | BIT(n+1))) << IXP4XX_PCI_NP_CBE_BESL;
-	if (ixp4xx_pci_read(addr, byte_enables | NP_CMD_MEMREAD, &data))
-		return 0xffff;
-
-	return data>>(8*n);
-}
-
 static inline void __indirect_readsw(const volatile void __iomem *bus_addr,
 				     void *p, u32 count)
 {
@@ -198,20 +129,6 @@ static inline void __indirect_readsw(const volatile void __iomem *bus_addr,
 		*vaddr++ = readw(bus_addr);
 }
 
-static inline u32 __indirect_readl(const volatile void __iomem *p)
-{
-	u32 addr = (__force u32)p;
-	u32 data;
-
-	if (!is_pci_memory(addr))
-		return __raw_readl(p);
-
-	if (ixp4xx_pci_read(addr, NP_CMD_MEMREAD, &data))
-		return 0xffffffff;
-
-	return data;
-}
-
 static inline void __indirect_readsl(const volatile void __iomem *bus_addr,
 				     void *p, u32 count)
 {
-- 
2.7.0



From lorenzo.pieralisi at arm.com  Fri Feb  5 08:26:17 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 5 Feb 2016 16:26:17 +0000
Subject: [PATCH v4 07/13] arm64: Change cpu_resume() to enable mmu early
 then access sleep_sp by va
In-Reply-To: <1453977766-20907-8-git-send-email-james.morse@arm.com>
References: <1453977766-20907-1-git-send-email-james.morse@arm.com>
 <1453977766-20907-8-git-send-email-james.morse@arm.com>
Message-ID: <20160205162617.GD31547@red-moon>

Hi James,

On Thu, Jan 28, 2016 at 10:42:40AM +0000, James Morse wrote:
> By enabling the MMU early in cpu_resume(), the sleep_save_sp and stack can
> be accessed by VA, which avoids the need to convert-addresses and clean to
> PoC on the suspend path.
> 
> MMU setup is shared with the boot path, meaning the swapper_pg_dir is
> restored directly: ttbr1_el1 is no longer saved/restored.
> 
> struct sleep_save_sp is removed, replacing it with a single array of
> pointers.
> 
> cpu_do_{suspend,resume} could be further reduced to not restore: cpacr_el1,
> mdscr_el1, tcr_el1, vbar_el1 and sctlr_el1, all of which are set by
> __cpu_setup(). However these values all contain res0 bits that may be used
> to enable future features.

This patch is a very nice clean-up, a comment below.

I think that for registers like tcr_el1 and sctlr_el1 we should define
a restore mask (to avoid overwriting bits set-up by __cpu_setup), eg
current code that restores the tcr_el1 seems wrong to me, see below.

[...]

> -/*
>   * This hook is provided so that cpu_suspend code can restore HW
>   * breakpoints as early as possible in the resume path, before reenabling
>   * debug exceptions. Code cannot be run from a CPU PM notifier since by the
>  {
>  	/*
> -	 * We are resuming from reset with TTBR0_EL1 set to the
> -	 * idmap to enable the MMU; set the TTBR0 to the reserved
> -	 * page tables to prevent speculative TLB allocations, flush
> -	 * the local tlb and set the default tcr_el1.t0sz so that
> -	 * the TTBR0 address space set-up is properly restored.
> -	 * If the current active_mm != &init_mm we entered cpu_suspend
> -	 * with mappings in TTBR0 that must be restored, so we switch
> -	 * them back to complete the address space configuration
> -	 * restoration before returning.
> +	 * We resume from suspend directly into the swapper_pg_dir. We may
> +	 * also need to load user-space page tables.
>  	 */
> -	cpu_set_reserved_ttbr0();
> -	local_flush_tlb_all();
> -	cpu_set_default_tcr_t0sz();

You remove the code above since you restore tcr_el1 in cpu_do_resume(),
but this is not the way it should be done, ie the restore should be done
with the code sequence above otherwise it is not safe.

>  	if (mm != &init_mm)
>  		cpu_switch_mm(mm->pgd, mm);
>  
> @@ -149,22 +114,17 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
>  	return ret;
>  }
>  
> -struct sleep_save_sp sleep_save_sp;
> +unsigned long *sleep_save_stash;
>  
>  static int __init cpu_suspend_init(void)
>  {
> -	void *ctx_ptr;
> -
>  	/* ctx_ptr is an array of physical addresses */
> -	ctx_ptr = kcalloc(mpidr_hash_size(), sizeof(phys_addr_t), GFP_KERNEL);
> +	sleep_save_stash = kcalloc(mpidr_hash_size(), sizeof(*sleep_save_stash),
> +				   GFP_KERNEL);
>  
> -	if (WARN_ON(!ctx_ptr))
> +	if (WARN_ON(!sleep_save_stash))
>  		return -ENOMEM;
>  
> -	sleep_save_sp.save_ptr_stash = ctx_ptr;
> -	sleep_save_sp.save_ptr_stash_phys = virt_to_phys(ctx_ptr);
> -	__flush_dcache_area(&sleep_save_sp, sizeof(struct sleep_save_sp));
> -
>  	return 0;
>  }
>  early_initcall(cpu_suspend_init);
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index 3c7d170de822..a755108aaa75 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -61,62 +61,45 @@ ENTRY(cpu_do_suspend)
>  	mrs	x2, tpidr_el0
>  	mrs	x3, tpidrro_el0
>  	mrs	x4, contextidr_el1
> -	mrs	x5, mair_el1
>  	mrs	x6, cpacr_el1
> -	mrs	x7, ttbr1_el1
>  	mrs	x8, tcr_el1
>  	mrs	x9, vbar_el1
>  	mrs	x10, mdscr_el1
>  	mrs	x11, oslsr_el1
>  	mrs	x12, sctlr_el1
>  	stp	x2, x3, [x0]
> -	stp	x4, x5, [x0, #16]
> -	stp	x6, x7, [x0, #32]
> -	stp	x8, x9, [x0, #48]
> -	stp	x10, x11, [x0, #64]
> -	str	x12, [x0, #80]
> +	stp	x4, xzr, [x0, #16]
> +	stp	x6, x8, [x0, #32]
> +	stp	x9, x10, [x0, #48]
> +	stp	x11, x12, [x0, #64]
>  	ret
>  ENDPROC(cpu_do_suspend)
>  
>  /**
>   * cpu_do_resume - restore CPU register context
>   *
> - * x0: Physical address of context pointer
> - * x1: ttbr0_el1 to be restored
> - *
> - * Returns:
> - *	sctlr_el1 value in x0
> + * x0: Address of context pointer
>   */
>  ENTRY(cpu_do_resume)
> -	/*
> -	 * Invalidate local tlb entries before turning on MMU
> -	 */
> -	tlbi	vmalle1
>  	ldp	x2, x3, [x0]
>  	ldp	x4, x5, [x0, #16]
> -	ldp	x6, x7, [x0, #32]
> -	ldp	x8, x9, [x0, #48]
> -	ldp	x10, x11, [x0, #64]
> -	ldr	x12, [x0, #80]
> +	ldp	x6, x8, [x0, #32]
> +	ldp	x9, x10, [x0, #48]
> +	ldp	x11, x12, [x0, #64]
>  	msr	tpidr_el0, x2
>  	msr	tpidrro_el0, x3
>  	msr	contextidr_el1, x4
> -	msr	mair_el1, x5
>  	msr	cpacr_el1, x6
> -	msr	ttbr0_el1, x1
> -	msr	ttbr1_el1, x7
> -	tcr_set_idmap_t0sz x8, x7
>  	msr	tcr_el1, x8

I do not think that's correct. You restore tcr_el1 here, but this has
side effect of "restoring" t0sz too and that's not correct since this
has to be done with the sequence you removed above.

I'd rather not touch t0sz at all (use a mask) and restore t0sz in
__cpu_suspend_exit() as it is done at present using:

cpu_set_reserved_ttbr0();
local_flush_tlb_all();
cpu_set_default_tcr_t0sz();

That's the only safe way of doing it.

Other than that the patch seems fine to me.

Thanks,
Lorenzo

>  	msr	vbar_el1, x9
>  	msr	mdscr_el1, x10
> +	msr	sctlr_el1, x12
>  	/*
>  	 * Restore oslsr_el1 by writing oslar_el1
>  	 */
>  	ubfx	x11, x11, #1, #1
>  	msr	oslar_el1, x11
>  	msr	pmuserenr_el0, xzr		// Disable PMU access from EL0
> -	mov	x0, x12
> -	dsb	nsh		// Make sure local tlb invalidation completed
>  	isb
>  	ret
>  ENDPROC(cpu_do_resume)
> -- 
> 2.6.2
> 


From gregory.clement at free-electrons.com  Fri Feb  5 08:28:42 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 05 Feb 2016 17:28:42 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <87mvrf2l6p.fsf@free-electrons.com> (Gregory CLEMENT's message of
 "Fri, 05 Feb 2016 17:09:34 +0100")
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
 <20160205090246.GE32272@lunn.ch> <20160205112907.796afb05@bbrezillon>
 <CAKzmTe20fT8BcRaDaf2gz92KMAK0kEUkaD-kPq_cPF1WKBdroA@mail.gmail.com>
 <87vb632maf.fsf@free-electrons.com>
 <CAKzmTe1AqNQwjcsAULotd010NXuk1AYjj5p6UoqT_Zu=BCHdcw@mail.gmail.com>
 <87mvrf2l6p.fsf@free-electrons.com>
Message-ID: <87io232kat.fsf@free-electrons.com>

Hi,

+cc Arnaud
 
 On ven., f?vr. 05 2016, Gregory CLEMENT <gregory.clement at free-electrons.com> wrote:

> Hi JM,
>  
>  On ven., f?vr. 05 2016, JM <fijam at archlinux.us> wrote:
>
>> On Fri, Feb 5, 2016 at 4:45 PM, Gregory CLEMENT
>> <gregory.clement at free-electrons.com> wrote:
>>> Hi JM,
>>>
>>>  On ven., f?vr. 05 2016, JM <fijam at archlinux.us> wrote:
>>>
>>>> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
>>>> <boris.brezillon at free-electrons.com> wrote:
>>>>> Jan, Andrew
>>>>>
>>>>> On Fri, 5 Feb 2016 10:02:46 +0100
>>>>> Andrew Lunn <andrew at lunn.ch> wrote:
>>>>>
>>>>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > I am testing marvell_cesa on a kirkwood device (QNAP TS-212p, Marvell
>>>>>> > Kirkwood 88F6282, dts: http://pastebin.com/Gk95KFHf ).
>>>>>> > As of kernel 4.4 (4.4.0-trunk-kirkwood #1 Debian 4.4-1~exp1) it fails
>>>>>> > in the following way:
>>>>>> >
>>>>>> > modprobe marvell_cesa allhwsupport=1
>>>>>> > dmesg | tail -n 1
>>>>>> > [ 1057.855091] marvell-cesa: probe of f1030000.crypto failed with error -12
>>>>>> >
>>>>>> > or:
>>>>>> >
>>>>>> > modprobe marvell_cesa
>>>>>> > dmesg | tail -n 1
>>>>>> > [ 9178.399357] marvell-cesa: probe of f1030000.crypto failed with error -524
>>>>>> >
>>>>>> > With kernel 4.3 it would fail with error -22 on that hardware. There
>>>>>> > are scattered reports from other users experiencing the same issue
>>>>>> > (1,2,3)
>>>>>> >
>>>>>> > I wonder if this is a result of an invalid definition of the
>>>>>> > crypto-sram in the dts of this SoC, or perhaps some other problem
>>>>>> > (PEBKAC included).
>>>>>>
>>>>>> Hi Jan
>>>>>>
>>>>>> Do you have SRAM enabled in your kernel configuration. The
>>>>>> mvebu_v5_defconfig does not have it, which is a bug really.
>>>>>
>>>>> Hm, the CRYPTO_DEV_MARVELL_CESA option selects the SRAM one [1].
>>>>> Anyway, I also think this error is related to the SRAM (not sure why the
>>>>> driver is not able to get the SRAM though).
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Boris
>>>>>
>>>>> [1]http://lxr.free-electrons.com/source/drivers/crypto/Kconfig#L168
>>>>>
>>>>>
>>>>> --
>>>>> Boris Brezillon, Free Electrons
>>>>> Embedded Linux and Kernel engineering
>>>>> http://free-electrons.com
>>>>
>>>> Hi,
>>>>
>>>> Thanks for getting back to me. Indeed, CONFIG_SRAM is enabled, I put
>>>> the complete .config here: http://pastebin.com/40eKMJqE
>>>>
>>>> If there is anything I can do to help squish this bug, please let me
>>>> know.
>>>
>>> How do you get your dts?
>>> it seems that you generated it from your dtb (or from /proc).
>>>
>>> I tried to do the same from arch/arm/boot/dts/kirkwood-ts219-6282.dtb,
>>> but the resulting dts is too different for an easy comparison.
>>>
>>> Could you also provide your dtb, maybe by using the same dtc with the
>>> option -s I will manage to get the something easier to compare.
>>
>
>> Yes, I simply used dtc -I fs /proc/device-tree to obtain the dts.
>>
>> Here is the relevant .dtb file : http://heap.ovh/files/kirkwood-ts219-6282.dtb
>>
>
> OK so this dtb is exacly the one from the mainline. As most of the CESU
> stuff is set in te dtis, we will be able to compare it on the other
> kirkwood based board.
>
> Gregory

So with the help of Boris we checked the ranges propreties, the reg
property and the clock too. Everyting seems OK.

Arnaud,

as you are the on who tested the cesa on kirkwood, do you remember if
you needed to add specific Kconfig or to made some change in the dts?

Thanks,

Gregory


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From boris.brezillon at free-electrons.com  Fri Feb  5 08:28:56 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 5 Feb 2016 17:28:56 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <CAKzmTe1AqNQwjcsAULotd010NXuk1AYjj5p6UoqT_Zu=BCHdcw@mail.gmail.com>
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
 <20160205090246.GE32272@lunn.ch>
 <20160205112907.796afb05@bbrezillon>
 <CAKzmTe20fT8BcRaDaf2gz92KMAK0kEUkaD-kPq_cPF1WKBdroA@mail.gmail.com>
 <87vb632maf.fsf@free-electrons.com>
 <CAKzmTe1AqNQwjcsAULotd010NXuk1AYjj5p6UoqT_Zu=BCHdcw@mail.gmail.com>
Message-ID: <20160205172856.2923d938@bbrezillon>

On Fri, 5 Feb 2016 17:01:45 +0100
JM <fijam at archlinux.us> wrote:

> On Fri, Feb 5, 2016 at 4:45 PM, Gregory CLEMENT
> <gregory.clement at free-electrons.com> wrote:
> > Hi JM,
> >
> >  On ven., f?vr. 05 2016, JM <fijam at archlinux.us> wrote:
> >
> >> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
> >> <boris.brezillon at free-electrons.com> wrote:
> >>> Jan, Andrew
> >>>
> >>> On Fri, 5 Feb 2016 10:02:46 +0100
> >>> Andrew Lunn <andrew at lunn.ch> wrote:
> >>>
> >>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
> >>>> > Hi,
> >>>> >
> >>>> > I am testing marvell_cesa on a kirkwood device (QNAP TS-212p, Marvell
> >>>> > Kirkwood 88F6282, dts: http://pastebin.com/Gk95KFHf ).
> >>>> > As of kernel 4.4 (4.4.0-trunk-kirkwood #1 Debian 4.4-1~exp1) it fails
> >>>> > in the following way:
> >>>> >
> >>>> > modprobe marvell_cesa allhwsupport=1
> >>>> > dmesg | tail -n 1
> >>>> > [ 1057.855091] marvell-cesa: probe of f1030000.crypto failed with error -12
> >>>> >
> >>>> > or:
> >>>> >
> >>>> > modprobe marvell_cesa
> >>>> > dmesg | tail -n 1
> >>>> > [ 9178.399357] marvell-cesa: probe of f1030000.crypto failed with error -524
> >>>> >
> >>>> > With kernel 4.3 it would fail with error -22 on that hardware. There
> >>>> > are scattered reports from other users experiencing the same issue
> >>>> > (1,2,3)
> >>>> >
> >>>> > I wonder if this is a result of an invalid definition of the
> >>>> > crypto-sram in the dts of this SoC, or perhaps some other problem
> >>>> > (PEBKAC included).
> >>>>
> >>>> Hi Jan
> >>>>
> >>>> Do you have SRAM enabled in your kernel configuration. The
> >>>> mvebu_v5_defconfig does not have it, which is a bug really.
> >>>
> >>> Hm, the CRYPTO_DEV_MARVELL_CESA option selects the SRAM one [1].
> >>> Anyway, I also think this error is related to the SRAM (not sure why the
> >>> driver is not able to get the SRAM though).
> >>>
> >>> Best Regards,
> >>>
> >>> Boris
> >>>
> >>> [1]http://lxr.free-electrons.com/source/drivers/crypto/Kconfig#L168
> >>>
> >>>
> >>> --
> >>> Boris Brezillon, Free Electrons
> >>> Embedded Linux and Kernel engineering
> >>> http://free-electrons.com
> >>
> >> Hi,
> >>
> >> Thanks for getting back to me. Indeed, CONFIG_SRAM is enabled, I put
> >> the complete .config here: http://pastebin.com/40eKMJqE
> >>
> >> If there is anything I can do to help squish this bug, please let me
> >> know.
> >
> > How do you get your dts?
> > it seems that you generated it from your dtb (or from /proc).
> >
> > I tried to do the same from arch/arm/boot/dts/kirkwood-ts219-6282.dtb,
> > but the resulting dts is too different for an easy comparison.
> >
> > Could you also provide your dtb, maybe by using the same dtc with the
> > option -s I will manage to get the something easier to compare.
> >
> > Gregory
> >
> >
> >>
> >> Best regards,
> >> Jan
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> > --
> > Gregory Clement, Free Electrons
> > Kernel, drivers, real-time and embedded Linux
> > development, consulting, training and support.
> > http://free-electrons.com
> 
> Hi,
> 
> Yes, I simply used dtc -I fs /proc/device-tree to obtain the dts.
> 
> Here is the relevant .dtb file : http://heap.ovh/files/kirkwood-ts219-6282.dtb

Can you try to apply this patch [1], and let me know where it fails?

[1]http://code.bulix.org/qnuq8m-90700




-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


From slash.tmp at free.fr  Fri Feb  5 08:29:35 2016
From: slash.tmp at free.fr (Mason)
Date: Fri, 5 Feb 2016 17:29:35 +0100
Subject: Common/typical fractional divider HW API
In-Reply-To: <1454688729.31169.87.camel@linux.intel.com>
References: <56B4B67D.2080707@free.fr>
 <1454684758.31169.77.camel@linux.intel.com> <56B4C775.50808@free.fr>
 <1454688729.31169.87.camel@linux.intel.com>
Message-ID: <56B4CDEF.3080606@free.fr>

On 05/02/2016 17:12, Andy Shevchenko wrote:

> On Fri, 2016-02-05 at 17:01 +0100, Mason wrote:
> 
>> So, do you agree that
>>
>>   DIV = 2^I * (1 + F/256)
>>
>> gives a more useful DIV distribution than
>>
>>   DIV = I + F/16
> 
> If you can change hardware why not to use any existing approach which
> suits better to your device?

Sorry, I don't understand the question.

In this part of my message, I was trying to argue that one HW API
"2^I * (1 + F/256)" seemed better than another one "I + F/16" on
any hardware.

> I don't remember any existing, though I didn't check much, divider
> register which takes something like that.

IIUC, you are saying that you've never seen hardware use the
"2^I * (1 + F/256)" formula, is that correct?

>> I'm not sure how to parse that. I'm using the divider driver
>> for a CPU clock, to do D(V)FS in cpufreq.
> 
> If you are using custom stuff for custom hardware, I hope it's okay.
> But if we are talking about generic solutions (like clk-fractional-
> divider), I would suggest to consider existing users / hardware.

Are you saying that I could use the clk-fractional-divider with
hardware that computes "I + F/16" ?

Maybe the clk-fractional-divider could be made more generic by having
the register update part done in a call-back function?

Regards.



From rogershimizu at gmail.com  Fri Feb  5 08:33:15 2016
From: rogershimizu at gmail.com (Roger Shimizu)
Date: Sat,  6 Feb 2016 01:33:15 +0900
Subject: [PATCH 0/3] fix and new support for orion5x based linkstation
Message-ID: <1454689998-9579-1-git-send-email-rogershimizu@gmail.com>

Dear Orion5x Maintainer,

Here're fix and new support for orion5x based linkstation devices.

Firstly, it add the missing mtd flash support, which I consider a fix
and can be backported to stable kernels, so I made the patch explicit.

Second, like the changes I made for kirkwood based linkstation DT,
I split the orion5x-linkstation-lswtgl.dts file into common and device
specific part, in order to support more devices.

Third, so there's a new device.

Hope this can be kindly accepted. Thank you!

Cheers,
Roger

Roger Shimizu (3):
  ARM: dts: orion5x: fix the missing mtd flash on linkstation lswtgl
  ARM: dts: orion5x: split linkstation lswtgl into common and device
    parts
  ARM: dts: orion5x: add device tree for buffalo linkstation ls-gl

 arch/arm/boot/dts/Makefile                       |   1 +
 arch/arm/boot/dts/linkstation-fan.dtsi           |  72 ++++++++
 arch/arm/boot/dts/linkstation-gpio-simple.dtsi   | 105 +++++++++++
 arch/arm/boot/dts/orion5x-linkstation-lsgl.dts   |  87 +++++++++
 arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts | 214 +++++------------------
 arch/arm/boot/dts/orion5x-linkstation.dtsi       | 180 +++++++++++++++++++
 6 files changed, 491 insertions(+), 168 deletions(-)
 create mode 100644 arch/arm/boot/dts/linkstation-fan.dtsi
 create mode 100644 arch/arm/boot/dts/linkstation-gpio-simple.dtsi
 create mode 100644 arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
 create mode 100644 arch/arm/boot/dts/orion5x-linkstation.dtsi

-- 
2.1.4



From rogershimizu at gmail.com  Fri Feb  5 08:33:16 2016
From: rogershimizu at gmail.com (Roger Shimizu)
Date: Sat,  6 Feb 2016 01:33:16 +0900
Subject: [PATCH 1/3] ARM: dts: orion5x: fix the missing mtd flash on
 linkstation lswtgl
In-Reply-To: <1454689998-9579-1-git-send-email-rogershimizu@gmail.com>
References: <1454689998-9579-1-git-send-email-rogershimizu@gmail.com>
Message-ID: <1454689998-9579-2-git-send-email-rogershimizu@gmail.com>

MTD flash stores u-boot and u-boot environment on linkstation lswtgl.
The latter one can be easily read/write by u-boot-tools package in Debian.

Signed-off-by: Roger Shimizu <rogershimizu at gmail.com>
---
 arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts | 31 ++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts b/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
index 420788229e6f..aae8a7aceab7 100644
--- a/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
+++ b/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
@@ -228,6 +228,37 @@
 	};
 };
 
+&devbus_bootcs {
+	status = "okay";
+	devbus,keep-config;
+
+	flash at 0 {
+		compatible = "jedec-flash";
+		reg = <0 0x40000>;
+		bank-width = <1>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			header at 0 {
+				reg = <0 0x30000>;
+				read-only;
+			};
+
+			uboot at 30000 {
+				reg = <0x30000 0xF000>;
+				read-only;
+			};
+
+			uboot_env at 3F000 {
+				reg = <0x3F000 0x1000>;
+			};
+		};
+	};
+};
+
 &mdio {
 	status = "okay";
 
-- 
2.1.4



From rogershimizu at gmail.com  Fri Feb  5 08:33:17 2016
From: rogershimizu at gmail.com (Roger Shimizu)
Date: Sat,  6 Feb 2016 01:33:17 +0900
Subject: [PATCH 2/3] ARM: dts: orion5x: split linkstation lswtgl into common
 and device parts
In-Reply-To: <1454689998-9579-1-git-send-email-rogershimizu@gmail.com>
References: <1454689998-9579-1-git-send-email-rogershimizu@gmail.com>
Message-ID: <1454689998-9579-3-git-send-email-rogershimizu@gmail.com>

In order to support more linkstation devices, common part of current
.dts file goes into .dtsi file. Some .dtsi are not with "orion5x" prefix
because other kirkwood based linkstation devices are in this shape, and
will be migrated some time later.
  - orion5x-linkstation.dtsi
  - linkstation-gpio-simple.dtsi
  - linkstation-fan.dtsi
while all rest part remains in device specific .dts file:
  - orion5x-linkstation-lswtgl.dts

Signed-off-by: Roger Shimizu <rogershimizu at gmail.com>
---
 arch/arm/boot/dts/linkstation-fan.dtsi           |  72 +++++++
 arch/arm/boot/dts/linkstation-gpio-simple.dtsi   | 105 ++++++++++
 arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts | 243 +++++------------------
 arch/arm/boot/dts/orion5x-linkstation.dtsi       | 180 +++++++++++++++++
 4 files changed, 402 insertions(+), 198 deletions(-)
 create mode 100644 arch/arm/boot/dts/linkstation-fan.dtsi
 create mode 100644 arch/arm/boot/dts/linkstation-gpio-simple.dtsi
 create mode 100644 arch/arm/boot/dts/orion5x-linkstation.dtsi

diff --git a/arch/arm/boot/dts/linkstation-fan.dtsi b/arch/arm/boot/dts/linkstation-fan.dtsi
new file mode 100644
index 000000000000..e211a3c47a76
--- /dev/null
+++ b/arch/arm/boot/dts/linkstation-fan.dtsi
@@ -0,0 +1,72 @@
+/*
+ * Device Tree common file for gpio-fan on Buffalo Linkstation
+ *
+ * Copyright (C) 2015, 2016
+ * Roger Shimizu <rogershimizu at gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/ {
+	gpio_fan {
+		compatible = "gpio-fan";
+		pinctrl-0 = <&pmx_fan_low &pmx_fan_high &pmx_fan_lock>;
+		pinctrl-names = "default";
+
+		gpio-fan,speed-map =
+			<0		3
+			1500	2
+			3250	1
+			5000	0>;
+	};
+};
+
+&pinctrl {
+	pmx_fan_low: pmx-fan-low {
+		marvell,function = "gpio";
+	};
+
+	pmx_fan_high: pmx-fan-high {
+		marvell,function = "gpio";
+	};
+
+	pmx_fan_lock: pmx-fan-lock {
+		marvell,function = "gpio";
+	};
+};
diff --git a/arch/arm/boot/dts/linkstation-gpio-simple.dtsi b/arch/arm/boot/dts/linkstation-gpio-simple.dtsi
new file mode 100644
index 000000000000..68d75e79a360
--- /dev/null
+++ b/arch/arm/boot/dts/linkstation-gpio-simple.dtsi
@@ -0,0 +1,105 @@
+/*
+ * Device Tree common file for gpio-{keys,leds} on Buffalo Linkstation
+ *
+ * Copyright (C) 2015, 2016
+ * Roger Shimizu <rogershimizu at gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/input/input.h>
+
+/ {
+	gpio_keys {
+		compatible = "gpio-keys";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		pinctrl-0 = <&pmx_power_switch>;
+		pinctrl-names = "default";
+
+		power-on-switch {
+			label = "Power-on Switch";
+			linux,code = <KEY_RESERVED>;
+			linux,input-type = <5>;
+		};
+
+		power-auto-switch {
+			label = "Power-auto Switch";
+			linux,code = <KEY_ESC>;
+			linux,input-type = <5>;
+		};
+	};
+
+	gpio_leds {
+		compatible = "gpio-leds";
+		pinctrl-0 = <&pmx_led_power &pmx_led_alarm &pmx_led_info>;
+		pinctrl-names = "default";
+
+		blue-power-led {
+			label = "linkstation:blue:power";
+			default-state = "keep";
+		};
+
+		red-alarm-led {
+			label = "linkstation:red:alarm";
+		};
+
+		amber-info-led {
+			label = "linkstation:amber:info";
+		};
+	};
+};
+
+&pinctrl {
+	pmx_power_switch: pmx-power-switch {
+		marvell,function = "gpio";
+	};
+
+	pmx_led_power: pmx-leds {
+		marvell,function = "gpio";
+	};
+
+	pmx_led_alarm: pmx-leds {
+		marvell,function = "gpio";
+	};
+
+	pmx_led_info: pmx-leds {
+		marvell,function = "gpio";
+	};
+};
diff --git a/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts b/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
index aae8a7aceab7..60dbac41c525 100644
--- a/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
+++ b/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
@@ -45,9 +45,10 @@
 
 /dts-v1/;
 
+#include "orion5x-linkstation.dtsi"
+#include "linkstation-gpio-simple.dtsi"
+#include "linkstation-fan.dtsi"
 #include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/input/input.h>
-#include "orion5x-mv88f5182.dtsi"
 
 / {
 	model = "Buffalo Linkstation LS-WTGL";
@@ -58,247 +59,93 @@
 		reg = <0x00000000 0x4000000>;
 	};
 
-	chosen {
-		bootargs = "console=ttyS0,115200n8 earlyprintk";
-		linux,stdout-path = &uart0;
-	};
-
-	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>,
-		         <MBUS_ID(0x09, 0x00) 0 0xf2200000 0x800>,
-			 <MBUS_ID(0x01, 0x0f) 0 0xf4000000 0x40000>;
-
-		internal-regs {
-			pinctrl: pinctrl at 10000 {
-				pinctrl-names = "default";
-
-				pmx_led_power: pmx-leds {
-					marvell,pins = "mpp0";
-					marvell,function = "gpio";
-				};
-
-				pmx_led_alarm: pmx-leds {
-					marvell,pins = "mpp2";
-					marvell,function = "gpio";
-				};
-
-				pmx_led_info: pmx-leds {
-					marvell,pins = "mpp3";
-					marvell,function = "gpio";
-				};
-
-				pmx_power_hdd: pmx-power-hdd {
-					marvell,pins = "mpp1";
-					marvell,function = "gpio";
-				};
-
-				pmx_usb_power: pmx-usb-power {
-					marvell,pins = "mpp9";
-					marvell,function = "gpio";
-				};
-
-				pmx_sata0: pmx-sata0 {
-					marvell,pins = "mpp12";
-					marvell,function = "sata0";
-				};
-
-				pmx_sata1: pmx-sata1 {
-					marvell,pins = "mpp13";
-					marvell,function = "sata1";
-				};
-
-				pmx_fan_high: pmx-fan-high {
-					marvell,pins = "mpp14";
-					marvell,function = "gpio";
-				};
-
-				pmx_fan_low: pmx-fan-low {
-					marvell,pins = "mpp17";
-					marvell,function = "gpio";
-				};
-
-				pmx_fan_lock: pmx-fan-lock {
-					marvell,pins = "mpp6";
-					marvell,function = "gpio";
-				};
-
-				pmx_power_switch: pmx-power-switch {
-					marvell,pins = "mpp8", "mpp10";
-					marvell,function = "gpio";
-				};
-			};
-		};
-	};
-
 	gpio_keys {
-		compatible = "gpio-keys";
-		#address-cells = <1>;
-		#size-cells = <0>;
-		pinctrl-0 = <&pmx_power_switch>;
-		pinctrl-names = "default";
-
-		button at 1 {
-			label = "Power-on Switch";
-			linux,code = <KEY_RESERVED>;
-			linux,input-type = <5>;
+		power-on-switch {
 			gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
 		};
 
-		button at 2 {
-			label = "Power-auto Switch";
-			linux,code = <KEY_ESC>;
-			linux,input-type = <5>;
+		power-auto-switch {
 			gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
 		};
 	};
 
 	gpio_leds {
-		compatible = "gpio-leds";
-		pinctrl-0 = <&pmx_led_power &pmx_led_alarm
-			     &pmx_led_info>;
-		pinctrl-names = "default";
-
-		led at 1 {
-			label = "lswtgl:blue:power";
+		blue-power-led {
 			gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
-			default-state = "keep";
 		};
 
-		led at 2 {
-			label = "lswtgl:red:alarm";
+		red-alarm-led {
 			gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
 		};
 
-		led at 3 {
-			label = "lswtgl:amber:info";
+		amber-info-led {
 			gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
 		};
 	};
 
 	gpio_fan {
-		compatible = "gpio-fan";
-		pinctrl-0 = <&pmx_fan_low &pmx_fan_high &pmx_fan_lock>;
-		pinctrl-names = "default";
-
 		gpios = <&gpio0 14 GPIO_ACTIVE_LOW
 			 &gpio0 17 GPIO_ACTIVE_LOW>;
 
-		gpio-fan,speed-map = <0 3
-				1500 2
-				3250 1
-				5000 0>;
-
 		alarm-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
 	};
+};
 
-	restart_poweroff {
-		compatible = "restart-poweroff";
+&pinctrl {
+	pmx_led_power: pmx-leds {
+		marvell,pins = "mpp0";
+		marvell,function = "gpio";
 	};
 
-	regulators {
-		compatible = "simple-bus";
-		#address-cells = <1>;
-		#size-cells = <0>;
-		pinctrl-0 = <&pmx_power_hdd &pmx_usb_power>;
-		pinctrl-names = "default";
-
-		usb_power: regulator at 1 {
-			compatible = "regulator-fixed";
-			reg = <1>;
-			regulator-name = "USB Power";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			enable-active-high;
-			regulator-always-on;
-			regulator-boot-on;
-			gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
-		};
-
-		hdd_power: regulator at 2 {
-			compatible = "regulator-fixed";
-			reg = <2>;
-			regulator-name = "HDD Power";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			enable-active-high;
-			regulator-always-on;
-			regulator-boot-on;
-			gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
-		};
+	pmx_power_hdd: pmx-power-hdd {
+		marvell,pins = "mpp1";
+		marvell,function = "gpio";
 	};
-};
-
-&devbus_bootcs {
-	status = "okay";
-	devbus,keep-config;
 
-	flash at 0 {
-		compatible = "jedec-flash";
-		reg = <0 0x40000>;
-		bank-width = <1>;
-
-		partitions {
-			compatible = "fixed-partitions";
-			#address-cells = <1>;
-			#size-cells = <1>;
-
-			header at 0 {
-				reg = <0 0x30000>;
-				read-only;
-			};
-
-			uboot at 30000 {
-				reg = <0x30000 0xF000>;
-				read-only;
-			};
+	pmx_led_alarm: pmx-leds {
+		marvell,pins = "mpp2";
+		marvell,function = "gpio";
+	};
 
-			uboot_env at 3F000 {
-				reg = <0x3F000 0x1000>;
-			};
-		};
+	pmx_led_info: pmx-leds {
+		marvell,pins = "mpp3";
+		marvell,function = "gpio";
 	};
-};
 
-&mdio {
-	status = "okay";
+	pmx_fan_lock: pmx-fan-lock {
+		marvell,pins = "mpp6";
+		marvell,function = "gpio";
+	};
 
-	ethphy: ethernet-phy {
-		reg = <8>;
+	pmx_power_switch: pmx-power-switch {
+		marvell,pins = "mpp8", "mpp10";
+		marvell,function = "gpio";
 	};
-};
 
-&eth {
-	status = "okay";
+	pmx_power_usb: pmx-power-usb {
+		marvell,pins = "mpp9";
+		marvell,function = "gpio";
+	};
 
-	ethernet-port at 0 {
-		phy-handle = <&ethphy>;
+	pmx_fan_high: pmx-fan-high {
+		marvell,pins = "mpp14";
+		marvell,function = "gpio";
 	};
-};
 
-&ehci0 {
-	status = "okay";
+	pmx_fan_low: pmx-fan-low {
+		marvell,pins = "mpp17";
+		marvell,function = "gpio";
+	};
 };
 
-&i2c {
-	status = "okay";
-
-	rtc {
-		compatible = "ricoh,rs5c372a";
-		reg = <0x32>;
-	};
+&hdd_power {
+	gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
 };
 
-&wdt {
-	status = "disabled";
+&usb_power {
+	gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
 };
 
 &sata {
-	pinctrl-0 = <&pmx_sata0 &pmx_sata1>;
-	pinctrl-names = "default";
-	status = "okay";
 	nr-ports = <2>;
 };
-
-&uart0 {
-	status = "okay";
-};
diff --git a/arch/arm/boot/dts/orion5x-linkstation.dtsi b/arch/arm/boot/dts/orion5x-linkstation.dtsi
new file mode 100644
index 000000000000..ed456ab35fd8
--- /dev/null
+++ b/arch/arm/boot/dts/orion5x-linkstation.dtsi
@@ -0,0 +1,180 @@
+/*
+ * Device Tree common file for orion5x based Buffalo Linkstation
+ *
+ * Copyright (C) 2015, 2016
+ * Roger Shimizu <rogershimizu at gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "orion5x-mv88f5182.dtsi"
+
+/ {
+	chosen {
+		bootargs = "console=ttyS0,115200n8 earlyprintk";
+		linux,stdout-path = &uart0;
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>,
+				 <MBUS_ID(0x09, 0x00) 0 0xf2200000 0x800>,
+				 <MBUS_ID(0x01, 0x0f) 0 0xf4000000 0x40000>;
+	};
+
+	restart_poweroff {
+		compatible = "restart-poweroff";
+	};
+
+	regulators {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		pinctrl-0 = <&pmx_power_usb &pmx_power_hdd>;
+		pinctrl-names = "default";
+
+		usb_power: regulator at 1 {
+			compatible = "regulator-fixed";
+			reg = <1>;
+			regulator-name = "USB Power";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			enable-active-high;
+			regulator-always-on;
+			regulator-boot-on;
+		};
+
+		hdd_power: regulator at 2 {
+			compatible = "regulator-fixed";
+			reg = <2>;
+			regulator-name = "HDD Power";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			enable-active-high;
+			regulator-always-on;
+			regulator-boot-on;
+		};
+	};
+};
+
+&pinctrl {
+	pmx_power_hdd: pmx-power-hdd {
+		marvell,function = "gpio";
+	};
+
+	pmx_power_usb: pmx-power-usb {
+		marvell,function = "gpio";
+	};
+};
+
+&devbus_bootcs {
+	status = "okay";
+	devbus,keep-config;
+
+	flash at 0 {
+		compatible = "jedec-flash";
+		reg = <0 0x40000>;
+		bank-width = <1>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			header at 0 {
+				reg = <0 0x30000>;
+				read-only;
+			};
+
+			uboot at 30000 {
+				reg = <0x30000 0xF000>;
+				read-only;
+			};
+
+			uboot_env at 3F000 {
+				reg = <0x3F000 0x1000>;
+			};
+		};
+	};
+};
+
+&mdio {
+	status = "okay";
+
+	ethphy: ethernet-phy {
+		reg = <8>;
+	};
+};
+
+&eth {
+	status = "okay";
+
+	ethernet-port at 0 {
+		phy-handle = <&ethphy>;
+	};
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&i2c {
+	status = "okay";
+
+	rtc {
+		compatible = "ricoh,rs5c372a";
+		reg = <0x32>;
+	};
+};
+
+&wdt {
+	status = "disabled";
+};
+
+&sata {
+	status = "okay";
+	nr-ports = <1>;
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart1 {
+	status = "okay";
+};
-- 
2.1.4



From rogershimizu at gmail.com  Fri Feb  5 08:33:18 2016
From: rogershimizu at gmail.com (Roger Shimizu)
Date: Sat,  6 Feb 2016 01:33:18 +0900
Subject: [PATCH 3/3] ARM: dts: orion5x: add device tree for buffalo
 linkstation ls-gl
In-Reply-To: <1454689998-9579-1-git-send-email-rogershimizu@gmail.com>
References: <1454689998-9579-1-git-send-email-rogershimizu@gmail.com>
Message-ID: <1454689998-9579-4-git-send-email-rogershimizu@gmail.com>

Add dts file to support Buffalo Linkstation LS-GL
(a.k.a Buffalo Linkstation Pro/Live), which is marvell orion5x based
3.5" HDD NAS.

Product info:
  - (JPN) http://buffalo.jp/products/catalog/item/l/ls-gl/
  - (ENG) http://www.buffalotech.com/products/network-storage/linkstation/linkstation-pro

This device tree is based on the board file:
  arch/arm/mach-orion5x/kurobox_pro-setup.c
However, that board file also support Kurobox Pro, which is not supported by
device tree yet. So the board file is not removed.

Signed-off-by: Roger Shimizu <rogershimizu at gmail.com>
---
 arch/arm/boot/dts/Makefile                     |  1 +
 arch/arm/boot/dts/orion5x-linkstation-lsgl.dts | 87 ++++++++++++++++++++++++++
 2 files changed, 88 insertions(+)
 create mode 100644 arch/arm/boot/dts/orion5x-linkstation-lsgl.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 68625754f398..15a52c1be78a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -496,6 +496,7 @@ dtb-$(CONFIG_SOC_DRA7XX) += \
 dtb-$(CONFIG_ARCH_ORION5X) += \
 	orion5x-lacie-d2-network.dtb \
 	orion5x-lacie-ethernet-disk-mini-v2.dtb \
+	orion5x-linkstation-lsgl.dtb \
 	orion5x-linkstation-lswtgl.dtb \
 	orion5x-lswsgl.dtb \
 	orion5x-maxtor-shared-storage-2.dtb \
diff --git a/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts b/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
new file mode 100644
index 000000000000..1cf644bfd7ea
--- /dev/null
+++ b/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
@@ -0,0 +1,87 @@
+/*
+ * Device Tree file for Buffalo Linkstation LS-GL
+ *       (also known as Buffalo Linkstation Pro/Live)
+ *
+ * Copyright (C) 2016
+ * Roger Shimizu <rogershimizu at gmail.com>
+ *
+ * Based on the board file arch/arm/mach-orion5x/kurobox_pro-setup.c
+ * Copyright (C) Ronen Shitrit <rshitrit at marvell.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "orion5x-linkstation.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	model = "Buffalo Linkstation Pro/Live";
+	compatible = "buffalo,lsgl", "marvell,orion5x-88f5182", "marvell,orion5x";
+
+	memory { /* 128 MB */
+		device_type = "memory";
+		reg = <0x00000000 0x8000000>;
+	};
+};
+
+&pinctrl {
+	pmx_power_hdd: pmx-power-hdd {
+		marvell,pins = "mpp1";
+		marvell,function = "gpio";
+	};
+
+	pmx_power_usb: pmx-power-usb {
+		marvell,pins = "mpp9";
+		marvell,function = "gpio";
+	};
+};
+
+&hdd_power {
+	gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
+};
+
+&usb_power {
+	gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
+};
+
+&ehci1 {
+	status = "okay";
+};
-- 
2.1.4



From Mike.Leach at arm.com  Fri Feb  5 08:31:32 2016
From: Mike.Leach at arm.com (Mike Leach)
Date: Fri, 5 Feb 2016 16:31:32 +0000
Subject: [PATCH V2 3/6] stm class: provision for statically assigned
 masterIDs
In-Reply-To: <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
 <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org>
 <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com>
Message-ID: <DB3PR08MB0041B8843C61FCEB049B2BB58CD20@DB3PR08MB0041.eurprd08.prod.outlook.com>

Hi,

I think a quick clarification of the ARM hardware STM architecture may be of value here.

The ARM hardware STM, when implemented as recommend in a hardware design, the master IDs are not under driver control, but have a hardwire association with source devices in the system. The master IDs are hardwired to individual cores and core security states, and there could be other IDs associated with hardware trace sources requiring output via the hardware STM. (an example of this is the ARM Juno development board).

Therefore in multi-core systems many masters may be associated with a single software STM stream. A user-space application running on Core 1, may have a master ID of 0x11 in the STPv2 trace stream, but if this application is context switched and later continues running on Core 2, then master ID could change to 0x21.  Masters identify a hardware source in this scheme, the precise values used will be implementation dependent.

So the number of masters "available to the software" depends on your interpretation of the phrase.
If you mean "master IDs on which software trace will appear" then that will be many - it depends on which core is running the application. However as described above, this is not predictable by any decoder, and the master set used may not be contiguous.
If you mean "master IDs selectable/allocated by the driver" then that will be 0 - the driver has no control, and possibly no knowledge of which master is associated with the current execution context. (this is of course system dependent - it may well be possible to have some configuration database associating cores with hardware IDs, but this will be implementation and board support dependant).

Therefore, there is a requirement to tell both the user-space STM client and decoder that not only is master ID management not needed - it is in fact not possible and the key to identify the software source for a given STM packet is the channel alone. In addition we have a nominal single Master ID "available to the software", to satisfy the requirements of the generic ST module API.

So on Juno for example, while we do have 128 masters, each with 65536 channels, the master allocation is not visible to system software - each core sees a single master with 65536 channels. Therefore differentiation between software sources in the STM trace is by channel number allocations only.

Best Regards

Mike.

----------------------------------------------------------------
Mike Leach                           +44 (0)1254 893911 (Direct)
Principal Engineer                   +44 (0)1254 893900 (Main)
Arm Blackburn Design Centre          +44 (0)1254 893901 (Fax)
Belthorn House
Walker Rd                            mailto:mike.leach at arm.com
Guide
Blackburn
BB1 2QE
----------------------------------------------------------------


> -----Original Message-----
> From: Alexander Shishkin [mailto:alexander.shishkin at linux.intel.com]
> Sent: 05 February 2016 12:52
> To: Chunyan Zhang; mathieu.poirier at linaro.org
> Cc: robh at kernel.org; broonie at kernel.org; pratikp at codeaurora.org;
> nicolas.guion at st.com; corbet at lwn.net; Mark Rutland; Mike Leach;
> tor at ti.com; Al Grant; zhang.lyra at gmail.com; linux-kernel at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org; linux-api at vger.kernel.org; linux-
> doc at vger.kernel.org
> Subject: Re: [PATCH V2 3/6] stm class: provision for statically assigned
> masterIDs
>
> Chunyan Zhang <zhang.chunyan at linaro.org> writes:
>
> > From: Mathieu Poirier <mathieu.poirier at linaro.org>
> >
> > Some architecture like ARM assign masterIDs statically at the HW design
> > phase, making masterID manipulation in the generic STM core irrelevant.
> >
> > This patch adds a new 'mstatic' flag to struct stm_data that tells the
> > core that this specific STM device doesn't need explicit masterID
> > management.
>
> So why do we need this patch? If your STM only has master 42 allocated
> for software sources, simply set sw_start = 42, sw_end = 42 and you're
> good to go, software will have exactly one channel to choose from. See
> also the comment from <linux/stm.h>:
>
>  * @sw_start:           first STP master available to software
>  * @sw_end:             last STP master available to software
>
> particularly the "available to software" part. Any other kinds of
> masters the STM class code doesn't care about (yet).
>
> > In the core sw_start/end of masterID are set to '1',
> > i.e there is only one masterID to deal with.
>
> This is also a completely arbitrary and unnecessary requirement. Again,
> you can set both to 42 and it will still work.
>
> > Also this patch depends on [1], so that the number of masterID
> > is '1' too.
> >
> > Finally the lower and upper bound for masterIDs as presented
> > in ($SYSFS)/class/stm/XYZ.stm/masters and
> > ($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
> > are set to '-1'.  That way users can't confuse them with
> > architecture where masterID management is required (where any
> > other value would be valid).
>
> Why is this a good idea? Having the actual master there will allow
> software to know what it is and also tell the decoding side what it is
> (assuming you have more than one source in the STP stream, it might not
> be easy to figure out, unless you know it in advance).
>
> I don't see how one master statically assigned to software sources is
> different from two masters or 32 masters. And I don't see any benefit of
> hiding the master id from userspace. Am I missing something?
>
> Regards,
> --
> Alex

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.



From nm at ti.com  Fri Feb  5 08:34:03 2016
From: nm at ti.com (Nishanth Menon)
Date: Fri, 5 Feb 2016 10:34:03 -0600
Subject: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager
In-Reply-To: <1454690044-2560-1-git-send-email-nm@ti.com>
References: <1454690044-2560-1-git-send-email-nm@ti.com>
Message-ID: <1454690044-2560-2-git-send-email-nm@ti.com>

Message Manager is a hardware block used to communicate with various
processor systems within certain Texas Instrument's Keystone
generation SoCs.

This hardware engine is used to transfer messages from various compute
entities(or processors) within the SoC. It is designed to be self
contained without needing software initialization for operation.

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 .../bindings/mailbox/ti,message-manager.txt        | 72 ++++++++++++++++++++++
 1 file changed, 72 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/ti,message-manager.txt

diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
new file mode 100644
index 000000000000..f3d73b0b3c66
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
@@ -0,0 +1,72 @@
+Texas Instruments' Message Manager Driver
+========================================
+
+The Texas Instruments' Message Manager is a mailbox controller that has
+configurable queues selectable at SoC(System on Chip) integration. The Message
+manager is broken up into queues in different address regions that are called
+"proxies" - each instance is unidirectional and is instantiated at SoC
+integration level to indicate receive or transmit path.
+
+Message Manager Device Node:
+===========================
+
+Required properties:
+--------------------
+- compatible:		Shall be:
+				"ti,k2g-message-manager"
+				"ti,message-manager"
+- reg-names 		queue_proxy_region - Map the queue Proxy region
+			queue_state_debug_region - Map the queue state debug
+			region.
+- reg:			Contains the register map per reg-names
+- #mbox-cells		Shall be 1
+
+Child Nodes:
+============
+A child node is used for representing the actual queue device that is
+used for the communication between the host processor and a remote processor.
+Each child node should have a unique node name across all the different
+message manager device nodes.
+
+Required Properties:
+--------------------
+- ti,queue-id:		Indicates the queue number this node represents
+- ti,proxy-id:		Proxy ID representing the processor in the SoC.
+
+Optional Properties:
+--------------------
+- interrupt-names:	'rx' - indicates a receive interrupt (mandatory ONLY if
+			this is a receive queue)
+- interrupts:		Contains the interrupt information corresponding to
+			interrupt-names property.
+
+Example:
+--------
+
+	msgmgr: msgmgr at 02a00000 {
+		compatible = "ti,k2g-message-manager", "ti,message-manager";
+		#mbox-cells = <1>;
+		reg-names = "queue_proxy_region", "queue_state_debug_region";
+		reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
+
+		msgmgr_proxy_pmmc_tx_prio0: pmmc_tx_prio0 {
+			ti,queue-id = <0>;
+			ti,proxy-id = <0>;
+		};
+
+		msgmgr_proxy_pmmc_rx: pmmc_rx {
+			ti,queue-id = <5>;
+			ti,proxy-id = <2>;
+			interrupt-names = "rx";
+			interrupts = <GIC_SPI 324 IRQ_TYPE_EDGE_RISING>;
+		};
+	};
+
+...
+	pmmc {
+		...
+		mbox-names = "tx", "rx";
+		mboxes = <&msgmgr &msgmgr_proxy_pmmc_tx>
+			 <&msgmgr &msgmgr_proxy_pmmc_rx>;
+		...
+	};
-- 
2.7.0



From nm at ti.com  Fri Feb  5 08:34:02 2016
From: nm at ti.com (Nishanth Menon)
Date: Fri, 5 Feb 2016 10:34:02 -0600
Subject: [PATCH 0/2] mailbox: Introduce Texas Instrument's message manager
 driver
Message-ID: <1454690044-2560-1-git-send-email-nm@ti.com>

Hi,

The following series provides a base driver for the support of TI's
message manager hardware block which facilitates communication
between multiple compute engines(or processors) with a central system
controller (called PMMC in K2G SoC). Keystone family of TI processors
incorporate this solution starting with K2G[1].

The hardware specification is available here:
http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf Chapter 8.1 (Message
Manager).

Starting with K2G SoC, TI Keystone architecture is moving towards an
architecture similar to ARM Juno platform with a centralized system
controller where all system control takes place - all power management
and system control functions are now centralized in this system
controller. A protocol called TI-SCI (TI System Control Interface)
is built on top of this mailbox driver providing for communication
protocol (similar to SCPI drivers/firmware/arm_scpi.c) Follow on
patches (once the message manager is accepted) will enable the same.
However, an 4.1 kernel based vendor kernel implementation is available
at [2].

The following series is functional in TI vendor kernel, however, was
tested on K2G EVM using the following test patch:
http://pastebin.ubuntu.com/14872857/
Boot log: http://pastebin.ubuntu.com/14872879/

baseline: v4.5-rc1

This could potentially be a targetted for v4.6-rc1 kernel.

Nishanth Menon (2):
  Documentation: dt: mailbox: Add TI Message Manager
  mailbox: Introduce TI message manager driver

 .../bindings/mailbox/ti,message-manager.txt        |  72 +++
 drivers/mailbox/Kconfig                            |  11 +
 drivers/mailbox/Makefile                           |   2 +
 drivers/mailbox/ti-msgmgr.c                        | 603 +++++++++++++++++++++
 include/linux/ti-msgmgr.h                          |  35 ++
 5 files changed, 723 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
 create mode 100644 drivers/mailbox/ti-msgmgr.c
 create mode 100644 include/linux/ti-msgmgr.h

[1] K2G support
https://patchwork.kernel.org/patch/8196481/
https://patchwork.kernel.org/patch/8196491/
https://patchwork.kernel.org/patch/8196471/

[2] TISCI support(for reference): (mailbox client driver)
http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-lsk-linux-4.1.y/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-lsk-linux-4.1.y/drivers/firmware/ti_sci.c
http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-lsk-linux-4.1.y/drivers/firmware/ti_sci.h
http://git.ti.com/ti-linux-kernel/ti-linux-kernel/blobs/ti-lsk-linux-4.1.y/include/linux/ti_sci_protocol.h
The above protocol is used for clock, generic powerdomain, reset etc..

-- 
2.7.0



From nm at ti.com  Fri Feb  5 08:34:04 2016
From: nm at ti.com (Nishanth Menon)
Date: Fri, 5 Feb 2016 10:34:04 -0600
Subject: [PATCH 2/2] mailbox: Introduce TI message manager driver
In-Reply-To: <1454690044-2560-1-git-send-email-nm@ti.com>
References: <1454690044-2560-1-git-send-email-nm@ti.com>
Message-ID: <1454690044-2560-3-git-send-email-nm@ti.com>

Support for TI Message Manager Module. This hardware block manages a
bunch of hardware queues meant for communication between processor
entities.

Clients sitting on top of this would manage the required protocol
for communicating with the counterpart entities.

For more details on TI Message Manager hardware block, see documentation
that is available here: http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf
Chapter 8.1(Message Manager)

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 drivers/mailbox/Kconfig     |  11 +
 drivers/mailbox/Makefile    |   2 +
 drivers/mailbox/ti-msgmgr.c | 603 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/ti-msgmgr.h   |  35 +++
 4 files changed, 651 insertions(+)
 create mode 100644 drivers/mailbox/ti-msgmgr.c
 create mode 100644 include/linux/ti-msgmgr.h

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 546d05f4358a..5da85ae48a59 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -78,6 +78,17 @@ config STI_MBOX
 	  Mailbox implementation for STMicroelectonics family chips with
 	  hardware for interprocessor communication.
 
+config TI_MESSAGE_MANAGER
+	tristate "Texas Instruments Message Manager Driver"
+	depends on ARCH_KEYSTONE
+	help
+	  An implementation of Message Manager slave driver for Keystone
+	  architecture SoCs from Texas Instruments. Message Manager is a
+	  communication entity found on few of Texas Instrument's keystone
+	  architecture SoCs. These may be used for communication between
+	  multiple processors within the SoC. Select this driver if your
+	  platform has support for the hardware block.
+
 config MAILBOX_TEST
 	tristate "Mailbox Test Client"
 	depends on OF
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 92435ef11f26..a9c2899e44ff 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -17,3 +17,5 @@ obj-$(CONFIG_ALTERA_MBOX)	+= mailbox-altera.o
 obj-$(CONFIG_BCM2835_MBOX)	+= bcm2835-mailbox.o
 
 obj-$(CONFIG_STI_MBOX)		+= mailbox-sti.o
+
+obj-$(CONFIG_TI_MESSAGE_MANAGER) += ti-msgmgr.o
diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c
new file mode 100644
index 000000000000..46f1b0adbedd
--- /dev/null
+++ b/drivers/mailbox/ti-msgmgr.c
@@ -0,0 +1,603 @@
+/*
+ * Texas Instruments' Message Manager Driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *	Nishanth Menon
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt) "%s: " fmt, __func__
+
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+#include <linux/ti-msgmgr.h>
+
+#define Q_DATA_OFFSET(proxy, queue, reg)	\
+		     ((0x10000 * (proxy)) + (0x80 * (queue)) + ((reg) * 4))
+#define Q_STATE_OFFSET(queue)			((queue) * 0x4)
+#define Q_STATE_ENTRY_COUNT_MASK		(0xFFF000)
+
+/**
+ * struct ti_msgmgr_desc - Description of message manager integration
+ * @queue_count:	Number of Queues
+ * @max_message_size:	Message size in bytes
+ * @max_messages:	Number of messages
+ * @q_slices:		Number of queue engines
+ * @q_proxies:		Number of queue proxies per page
+ * @data_first_reg:	First data register for proxy data region
+ * @data_last_reg:	Last data register for proxy data region
+ * @tx_polled:		Do I need to use polled mechanism for tx
+ * @tx_poll_timeout_ms: Timeout in ms if polled
+ *
+ * This structure is used in of match data to describe how integration
+ * for a specific compatible SoC is done.
+ */
+struct ti_msgmgr_desc {
+	u8 queue_count;
+	u8 max_message_size;
+	u8 max_messages;
+	u8 q_slices;
+	u8 q_proxies;
+	u8 data_first_reg;
+	u8 data_last_reg;
+	bool tx_polled;
+	int tx_poll_timeout_ms;
+};
+
+/**
+ * struct ti_queue_inst - Description of a queue instance
+ * @name:	Queue Name
+ * @queue_id:	Queue Identifier as mapped on SoC
+ * @proxy_id:	Proxy Identifier as mapped on SoC
+ * @irq:	IRQ for Rx Queue
+ * @is_tx:	'true' if transmit queue, else, 'false'
+ * @queue_buff_start: First register of Data Buffer
+ * @queue_buff_end: Last (or confirmation) register of Data buffer
+ * @queue_state: Queue status register
+ * @chan:	Mailbox channel
+ * @rx_buff:	Receive buffer pointer allocated at probe, max_message_size
+ */
+struct ti_queue_inst {
+	const char *name;
+	u32 queue_id;
+	u32 proxy_id;
+	int irq;
+	bool is_tx;
+	void __iomem *queue_buff_start;
+	void __iomem *queue_buff_end;
+	void __iomem *queue_state;
+	struct mbox_chan *chan;
+	u32 *rx_buff;
+};
+
+/**
+ * struct ti_msgmgr_inst - Description of a Message Manager Instance
+ * @dev:	device pointer corresponding to the Message Manager instance
+ * @desc:	Description of the SoC integration
+ * @queue_proxy_region:	Queue proxy region where queue buffers are located
+ * @queue_state_debug_region:	Queue status register regions
+ * @num_valid_queues:	Number of valid queues defined for the processor
+ *		Note: other queues are probably reserved for other processors
+ *		in the SoC.
+ * @qinsts:	Array of valid Queue Instances for the Processor
+ * @mbox:	Mailbox Controller
+ * @chans:	Array for channels corresponding to the Queue Instances.
+ */
+struct ti_msgmgr_inst {
+	struct device *dev;
+	const struct ti_msgmgr_desc *desc;
+	void __iomem *queue_proxy_region;
+	void __iomem *queue_state_debug_region;
+	u8 num_valid_queues;
+	struct ti_queue_inst *qinsts;
+	struct mbox_controller mbox;
+	struct mbox_chan *chans;
+};
+
+/**
+ * ti_msgmgr_queue_get_num_messages() - Get the number of pending messages
+ * @qinst:	Queue instance for which we check the number of pending messages
+ *
+ * Return: number of messages pending in the queue (0 == no pending messages)
+ */
+static inline int ti_msgmgr_queue_get_num_messages(struct ti_queue_inst *qinst)
+{
+	u32 val;
+
+	/*
+	 * We cannot use relaxed operation here - update may happen
+	 * real-time.
+	 */
+	val = readl(qinst->queue_state) & Q_STATE_ENTRY_COUNT_MASK;
+	val >>= __ffs(Q_STATE_ENTRY_COUNT_MASK);
+
+	return val;
+}
+
+/**
+ * ti_msgmgr_queue_rx_interrupt() - Interrupt handler for receive Queue
+ * @irq:	Interrupt number
+ * @p:		Channel Pointer
+ *
+ * Return: -EINVAL if there is no instance
+ * IRQ_NONE if the interrupt is not ours.
+ * IRQ_HANDLED if the rx interrupt was successfully handled.
+ */
+static irqreturn_t ti_msgmgr_queue_rx_interrupt(int irq, void *p)
+{
+	struct mbox_chan *chan = p;
+	struct device *dev = chan->mbox->dev;
+	struct ti_msgmgr_inst *inst = dev_get_drvdata(dev);
+	struct ti_queue_inst *qinst = chan->con_priv;
+	const struct ti_msgmgr_desc *desc;
+	int msg_count, num_words;
+	struct ti_msgmgr_message message;
+	void __iomem *data_reg;
+	u32 *word_data;
+
+	if (WARN_ON(!inst)) {
+		dev_err(dev, "no platform drv data??\n");
+		return -EINVAL;
+	}
+
+	/* Do I have an invalid interrupt source? */
+	if (qinst->is_tx) {
+		dev_err(dev, "Cannot handle rx interrupt on tx channel %s\n",
+			qinst->name);
+		return IRQ_NONE;
+	}
+
+	/* Do I actually have messages to read? */
+	msg_count = ti_msgmgr_queue_get_num_messages(qinst);
+	if (!msg_count) {
+		dev_dbg(dev, "Spurious event - 0 pending data!\n");
+		return IRQ_NONE;
+	}
+
+	/*
+	 * I have no idea about the protocol being used to communicate with the
+	 * remote producer - 0 is valid data, so I wont make a judgement of how
+	 * many bytes I should be reading. Let the client figure this out.. I
+	 * just read the full message and pass it on..
+	 */
+	desc = inst->desc;
+	message.len = desc->max_message_size;
+	message.buf = (u8 *)qinst->rx_buff;
+
+	/*
+	 * NOTE about register access involved here:
+	 * the hardware block is implemented with 32bit access operations and no
+	 * support for data splitting.  We don't want the hardware to misbehave
+	 * with sub 32bit access - For example: if the last register read is
+	 * split into byte wise access, it can result in the queue getting
+	 * stuck or indeterminate behavior. Hence, we do not use memcpy_fromio
+	 * here.
+	 * Also note that the final register read automatically marks the
+	 * queue message as read.
+	 */
+	for (data_reg = qinst->queue_buff_start, word_data = qinst->rx_buff,
+	     num_words = (desc->max_message_size / sizeof(u32));
+	     num_words; num_words--, data_reg += sizeof(u32), word_data++)
+		*word_data = readl(data_reg);
+
+	/*
+	 * Last register read automatically clears the IRQ if only 1 message
+	 * is pending - so send the data up the stack..
+	 * NOTE: Client is expected to be as optimal as possible, since
+	 * we invoke the handler in IRQ context.
+	 */
+	mbox_chan_received_data(chan, (void *)&message);
+
+	return IRQ_HANDLED;
+}
+
+/**
+ * ti_msgmgr_queue_peek_data() - Peek to see if there are any rx messages.
+ * @chan:	Channel Pointer
+ *
+ * Return: 'true' if there is pending rx data, 'false' if there is none.
+ */
+static bool ti_msgmgr_queue_peek_data(struct mbox_chan *chan)
+{
+	struct ti_queue_inst *qinst = chan->con_priv;
+	int msg_count;
+
+	if (qinst->is_tx)
+		return false;
+
+	msg_count = ti_msgmgr_queue_get_num_messages(qinst);
+
+	return msg_count ? true : false;
+}
+
+/**
+ * ti_msgmgr_last_tx_done() - See if all the tx messages are sent
+ * @chan:	Channel pointer
+ *
+ * Return: 'true' is no pending tx data, 'false' if there are any.
+ */
+static bool ti_msgmgr_last_tx_done(struct mbox_chan *chan)
+{
+	struct ti_queue_inst *qinst = chan->con_priv;
+	int msg_count;
+
+	if (!qinst->is_tx)
+		return false;
+
+	msg_count = ti_msgmgr_queue_get_num_messages(qinst);
+
+	/* if we have any messages pending.. */
+	return msg_count ? false : true;
+}
+
+/**
+ * ti_msgmgr_send_data() - Send data
+ * @chan:	Channel Pointer
+ * @data:	ti_msgmgr_message * Message Pointer
+ *
+ * Return: 0 if all goes good, else appropriate error messages.
+ */
+static int ti_msgmgr_send_data(struct mbox_chan *chan, void *data)
+{
+	struct device *dev = chan->mbox->dev;
+	struct ti_msgmgr_inst *inst = dev_get_drvdata(dev);
+	const struct ti_msgmgr_desc *desc;
+	struct ti_queue_inst *qinst = chan->con_priv;
+	int msg_count, num_words, trail_bytes;
+	struct ti_msgmgr_message *message = data;
+	void __iomem *data_reg;
+	u32 *word_data;
+
+	if (WARN_ON(!inst)) {
+		dev_err(dev, "no platform drv data??\n");
+		return -EINVAL;
+	}
+	desc = inst->desc;
+
+	if (desc->max_message_size < message->len) {
+		dev_err(dev, "Queue %s message length %d > max %d\n",
+			qinst->name, message->len, desc->max_message_size);
+		return -EINVAL;
+	}
+
+	/* Are we able to send this or not? */
+	msg_count = ti_msgmgr_queue_get_num_messages(qinst);
+	if (msg_count >= desc->max_messages) {
+		dev_warn(dev, "Queue %s is full (%d messages)\n", qinst->name,
+			 msg_count);
+		return -EBUSY;
+	}
+
+	/*
+	 * NOTE about register access involved here:
+	 * the hardware block is implemented with 32bit access operations and no
+	 * support for data splitting.  We don't want the hardware to misbehave
+	 * with sub 32bit access - For example: if the last register write is
+	 * split into byte wise access, it can result in the queue getting
+	 * stuck or dummy messages being transmitted or indeterminate behavior.
+	 * Hence, we do not use memcpy_toio here.
+	 */
+	for (data_reg = qinst->queue_buff_start,
+	     num_words = message->len / sizeof(u32),
+	     word_data = (u32 *)message->buf;
+	     num_words; num_words--, data_reg += sizeof(u32), word_data++)
+		writel(*word_data, data_reg);
+
+	trail_bytes = message->len % sizeof(u32);
+	if (trail_bytes) {
+		u32 data_trail = *word_data;
+
+		/* Ensure all unused data is 0 */
+		data_trail &= 0xFFFFFFFF >> (8 * (sizeof(u32) - trail_bytes));
+		writel(data_trail, data_reg);
+		data_reg++;
+	}
+	/*
+	 * 'data_reg' indicates next register to write. If we did not already
+	 * write on tx complete reg(last reg), we must do so for transmit
+	 */
+	if (data_reg <= qinst->queue_buff_end)
+		writel(0, qinst->queue_buff_end);
+
+	return 0;
+}
+
+/**
+ * ti_msgmgr_queue_startup() - Startup queue
+ * @chan:	Channel pointer
+ *
+ * Return: 0 if all goes good, else return corresponding error message
+ */
+static int ti_msgmgr_queue_startup(struct mbox_chan *chan)
+{
+	struct ti_queue_inst *qinst = chan->con_priv;
+	struct device *dev = chan->mbox->dev;
+	int ret;
+
+	if (!qinst->is_tx) {
+		/*
+		 * With the expectation that the IRQ might be shared in
+		 * future
+		 */
+		ret = request_irq(qinst->irq, ti_msgmgr_queue_rx_interrupt,
+				  IRQF_SHARED, qinst->name, chan);
+		if (ret) {
+			dev_err(dev, "Unable to get IRQ %d on %s(res=%d)\n",
+				qinst->irq, qinst->name, ret);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+/**
+ * ti_msgmgr_queue_shutdown() - Shutdown the queue
+ * @chan:	Channel pointer
+ */
+static void ti_msgmgr_queue_shutdown(struct mbox_chan *chan)
+{
+	struct ti_queue_inst *qinst = chan->con_priv;
+
+	if (!qinst->is_tx)
+		free_irq(qinst->irq, chan);
+}
+
+/**
+ * ti_msgmgr_of_xlate() - Translation of phandle to queue
+ * @mbox:	Mailbox controller
+ * @p:		phandle pointer
+ *
+ * Return: Mailbox channel corresponding to the queue, else return error
+ * pointer.
+ */
+static struct mbox_chan *ti_msgmgr_of_xlate(struct mbox_controller *mbox,
+					    const struct of_phandle_args *p)
+{
+	struct ti_msgmgr_inst *inst;
+	struct device_node *np;
+	phandle phandle = p->args[0];
+	struct ti_queue_inst *qinst;
+	int i;
+	struct mbox_chan *chan = ERR_PTR(-ENOENT);
+
+	inst = container_of(mbox, struct ti_msgmgr_inst, mbox);
+	if (WARN_ON(!inst))
+		return ERR_PTR(-EINVAL);
+
+	np = of_find_node_by_phandle(phandle);
+	if (!np) {
+		dev_err(inst->dev, "Unable to find phandle %p\n", p);
+		return ERR_PTR(-ENODEV);
+	}
+
+	for (qinst = inst->qinsts, i = 0; i < inst->num_valid_queues;
+	     i++, qinst++) {
+		/* not using strncmp: What could be a valid length here?? */
+		if (!strcmp(qinst->name, np->name)) {
+			chan = qinst->chan;
+			break;
+		}
+	}
+	of_node_put(np);
+
+	return chan;
+}
+
+/* Queue operations */
+static const struct mbox_chan_ops ti_msgmgr_chan_ops = {
+	.startup = ti_msgmgr_queue_startup,
+	.shutdown = ti_msgmgr_queue_shutdown,
+	.peek_data = ti_msgmgr_queue_peek_data,
+	.last_tx_done = ti_msgmgr_last_tx_done,
+	.send_data = ti_msgmgr_send_data,
+};
+
+/* Keystone K2G SoC integration details */
+static const struct ti_msgmgr_desc k2g_desc = {
+	.queue_count = 64,
+	.max_message_size = 64,
+	.max_messages = 128,
+	.q_slices = 1,
+	.q_proxies = 1,
+	.data_first_reg = 16,
+	.data_last_reg = 31,
+	.tx_polled = false,
+};
+
+static const struct of_device_id ti_msgmgr_of_match[] = {
+	{.compatible = "ti,k2g-message-manager", .data = &k2g_desc},
+	{.compatible = "ti,message-manager", .data = &k2g_desc},
+	{ /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, ti_msgmgr_of_match);
+
+static int ti_msgmgr_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	const struct of_device_id *of_id;
+	struct device_node *np, *child;
+	struct resource *res;
+	const struct ti_msgmgr_desc *desc;
+	struct ti_msgmgr_inst *inst;
+	struct ti_queue_inst *qinst;
+	struct mbox_controller *mbox;
+	struct mbox_chan *chans;
+	int queue_count;
+	int i;
+	int ret = -EINVAL;
+
+	if (!dev->of_node) {
+		dev_err(dev, "no OF information\n");
+		return -EINVAL;
+	}
+	np = dev->of_node;
+
+	of_id = of_match_device(ti_msgmgr_of_match, dev);
+	if (!of_id) {
+		dev_err(dev, "OF data missing\n");
+		return -EINVAL;
+	}
+	desc = of_id->data;
+
+	inst = devm_kzalloc(dev, sizeof(*inst), GFP_KERNEL);
+	if (!inst)
+		return -ENOMEM;
+
+	inst->dev = dev;
+	inst->desc = desc;
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+					   "queue_proxy_region");
+	inst->queue_proxy_region = devm_ioremap_resource(dev, res);
+	if (IS_ERR(inst->queue_proxy_region))
+		return PTR_ERR(inst->queue_proxy_region);
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+					   "queue_state_debug_region");
+	inst->queue_state_debug_region = devm_ioremap_resource(dev, res);
+	if (IS_ERR(inst->queue_state_debug_region))
+		return PTR_ERR(inst->queue_state_debug_region);
+
+	dev_dbg(dev, "proxy region=%p, queue_state=%p\n",
+		inst->queue_proxy_region, inst->queue_state_debug_region);
+
+	queue_count = of_get_available_child_count(np);
+	if (!queue_count) {
+		dev_err(dev, "No child nodes representing queues\n");
+		return -EINVAL;
+	}
+	if (queue_count > desc->queue_count) {
+		dev_err(dev, "Number of queues %d > max %d\n",
+			queue_count, desc->queue_count);
+		return -ERANGE;
+	}
+	inst->num_valid_queues = queue_count;
+
+	qinst = devm_kzalloc(dev, sizeof(*qinst) * queue_count, GFP_KERNEL);
+	if (!qinst)
+		return -ENOMEM;
+	inst->qinsts = qinst;
+
+	chans = devm_kzalloc(dev, sizeof(*chans) * queue_count, GFP_KERNEL);
+	if (!chans)
+		return -ENOMEM;
+	inst->chans = chans;
+
+	for (i = 0, child = NULL; i < queue_count; i++, qinst++, chans++) {
+		child = of_get_next_available_child(np, child);
+		ret = of_property_read_u32(child, "ti,queue-id",
+					   &qinst->queue_id);
+		if (ret) {
+			dev_err(dev, "Child node %s[idx=%d] has no queue-id\n",
+				child->name, i);
+			return -EINVAL;
+		}
+		if (qinst->queue_id > desc->queue_count) {
+			dev_err(dev, "Child node %s[idx=%d] queuid %d > %d\n",
+				child->name, i, qinst->queue_id,
+				desc->queue_count);
+			return -ERANGE;
+		}
+
+		ret = of_property_read_u32(child, "ti,proxy-id",
+					   &qinst->proxy_id);
+		if (ret) {
+			dev_err(dev, "Child node %s[idx=%d] has no proxy-id\n",
+				child->name, i);
+			return -EINVAL;
+		}
+
+		qinst->irq = of_irq_get_byname(child, "rx");
+		/* TX queues don't have IRQ numbers */
+		if (qinst->irq < 0) {
+			qinst->irq = -1;
+			qinst->is_tx = true;
+		}
+
+		qinst->queue_buff_start = inst->queue_proxy_region +
+		    Q_DATA_OFFSET(qinst->proxy_id, qinst->queue_id,
+				  desc->data_first_reg);
+		qinst->queue_buff_end = inst->queue_proxy_region +
+		    Q_DATA_OFFSET(qinst->proxy_id, qinst->queue_id,
+				  desc->data_last_reg);
+		qinst->queue_state = inst->queue_state_debug_region +
+		    Q_STATE_OFFSET(qinst->queue_id);
+		qinst->name = child->name;
+		qinst->chan = chans;
+
+		/* Allocate usage buffer for rx */
+		if (!qinst->is_tx) {
+			qinst->rx_buff = devm_kzalloc(dev,
+						      desc->max_message_size,
+						      GFP_KERNEL);
+			if (!qinst->rx_buff)
+				return -ENOMEM;
+		}
+
+		chans->con_priv = qinst;
+
+		dev_dbg(dev, "[%d] qidx=%d pidx=%d irq=%d q_s=%p q_e = %p\n",
+			i, qinst->queue_id, qinst->proxy_id, qinst->irq,
+			qinst->queue_buff_start, qinst->queue_buff_end);
+	}
+
+	mbox = &inst->mbox;
+	mbox->dev = dev;
+	mbox->ops = &ti_msgmgr_chan_ops;
+	mbox->chans = inst->chans;
+	mbox->num_chans = inst->num_valid_queues;
+	mbox->txdone_irq = false;
+	mbox->txdone_poll = desc->tx_polled;
+	if (desc->tx_polled)
+		mbox->txpoll_period = desc->tx_poll_timeout_ms;
+	mbox->of_xlate = ti_msgmgr_of_xlate;
+
+	platform_set_drvdata(pdev, inst);
+	ret = mbox_controller_register(mbox);
+	if (ret)
+		dev_err(dev, "Failed to register mbox_controller(%d)\n", ret);
+
+	return ret;
+}
+
+static int ti_msgmgr_remove(struct platform_device *pdev)
+{
+	struct ti_msgmgr_inst *inst;
+
+	inst = platform_get_drvdata(pdev);
+	mbox_controller_unregister(&inst->mbox);
+
+	return 0;
+}
+
+static struct platform_driver ti_msgmgr_driver = {
+	.probe = ti_msgmgr_probe,
+	.remove = ti_msgmgr_remove,
+	.driver = {
+		   .name = "ti-msgmgr",
+		   .of_match_table = of_match_ptr(ti_msgmgr_of_match),
+	},
+};
+module_platform_driver(ti_msgmgr_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("TI message manager driver");
+MODULE_AUTHOR("Nishanth Menon");
+MODULE_ALIAS("platform:ti-msgmgr");
diff --git a/include/linux/ti-msgmgr.h b/include/linux/ti-msgmgr.h
new file mode 100644
index 000000000000..2c6a01850028
--- /dev/null
+++ b/include/linux/ti-msgmgr.h
@@ -0,0 +1,35 @@
+/*
+ * Texas Instruments' Message Manager
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *	Nishanth Menon
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef TI_MSGMGR_H
+#define TI_MSGMGR_H
+
+/**
+ * struct ti_msgmgr_message - Message Manager structure
+ * @len: Length of data in the Buffer
+ * @buf: Buffer pointer
+ *
+ * This is the structure for data used in mbox_send_message
+ * the length of data buffer used depends on the SoC integration
+ * parameters - each message may be 64, 128 bytes long depending
+ * on SoC. Client is supposed to be aware of this.
+ */
+struct ti_msgmgr_message {
+	size_t len;
+	u8 *buf;
+};
+
+#endif /* TI_MSGMGR_H */
-- 
2.7.0



From tj at kernel.org  Fri Feb  5 08:41:22 2016
From: tj at kernel.org (Tejun Heo)
Date: Fri, 5 Feb 2016 11:41:22 -0500
Subject: [PATCH v3 1/3] libahci: Implement the capability to override the
 generic ahci interrupt handler.
In-Reply-To: <1454620826-22554-2-git-send-email-stripathi@apm.com>
References: <1454620826-22554-1-git-send-email-stripathi@apm.com>
 <1454620826-22554-2-git-send-email-stripathi@apm.com>
Message-ID: <20160205164122.GB4401@htj.duckdns.org>

Hello,

On Fri, Feb 05, 2016 at 02:50:24AM +0530, suman Tripathi wrote:
...
> @@ -2504,15 +2505,28 @@ int ahci_host_activate(struct ata_host *host, struct scsi_host_template *sht)
>  	struct ahci_host_priv *hpriv = host->private_data;
>  	int irq = hpriv->irq;
>  	int rc;
> +	irqreturn_t (*ahci_irq_handler)(int irq, void *dev_instance);
> 
> +	ahci_irq_handler = hpriv->ahci_irq_intr;
> +
> +	if (hpriv->flags & (AHCI_HFLAG_MULTI_MSI | AHCI_HFLAG_MULTI_MSIX)) {
> +		if (!ahci_irq_handler)
> +			rc = ahci_host_activate_multi_irqs(host, sht);
> +		else
> +			dev_warn(host->dev, "both AHCI_HFLAG_MULTI_MSI flag set \
> +				 and custom irq handler implemented\n");
> +
> +	} else {
> +		if (!ahci_irq_handler) {
> +			ahci_irq_handler = (hpriv->flags & AHCI_HFLAG_EDGE_IRQ ?
> +			 		    ahci_single_edge_irq_intr :
> +					    ahci_single_level_irq_intr);
> +		}
> +	}

I wrote this before but can't we do this in save_initial_config the
same way ->start_engine override is handled?

-- 
tejun


From andriy.shevchenko at linux.intel.com  Fri Feb  5 08:43:19 2016
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Fri, 05 Feb 2016 18:43:19 +0200
Subject: Common/typical fractional divider HW API
In-Reply-To: <56B4CDEF.3080606@free.fr>
References: <56B4B67D.2080707@free.fr>
 <1454684758.31169.77.camel@linux.intel.com> <56B4C775.50808@free.fr>
 <1454688729.31169.87.camel@linux.intel.com> <56B4CDEF.3080606@free.fr>
Message-ID: <1454690599.31169.103.camel@linux.intel.com>

On Fri, 2016-02-05 at 17:29 +0100, Mason wrote:
> On 05/02/2016 17:12, Andy Shevchenko wrote:
> 
> > On Fri, 2016-02-05 at 17:01 +0100, Mason wrote:
> > 
> > > So, do you agree that
> > > 
> > > ? DIV = 2^I * (1 + F/256)
> > > 
> > > gives a more useful DIV distribution than
> > > 
> > > ? DIV = I + F/16
> > 
> > If you can change hardware why not to use any existing approach
> > which
> > suits better to your device?
> 
> Sorry, I don't understand the question.
> 

There are plenty of implementations of the divider. You might consider
to use one than inventing new one:

https://xkcd.com/927/

> In this part of my message, I was trying to argue that one HW API
> "2^I * (1 + F/256)" seemed better than another one "I + F/16" on
> any hardware.

I disagree in a part 2^I.

> 
> > I don't remember any existing, though I didn't check much, divider
> > register which takes something like that.
> 
> IIUC, you are saying that you've never seen hardware use the
> "2^I * (1 + F/256)" formula, is that correct?

Yep, though it doesn't mean there is no such.

> I'm not sure how to parse that. I'm using the divider driver
> > > for a CPU clock, to do D(V)FS in cpufreq.
> > 
> > If you are using custom stuff for custom hardware, I hope it's
> > okay.
> > But if we are talking about generic solutions (like clk-fractional-
> > divider), I would suggest to consider existing users / hardware.
> 
> Are you saying that I could use the clk-fractional-divider with
> hardware that computes "I + F/16" ?

No.

> Maybe the clk-fractional-divider could be made more generic by having
> the register update part done in a call-back function?

Why do you need to touch that module at all if your hardware doesn't
suit it?

-- 
Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Intel Finland Oy



From catalin.marinas at arm.com  Fri Feb  5 08:46:48 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 5 Feb 2016 16:46:48 +0000
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <CAKv+Gu8g7FHHZgmbFww_XZjf5J1utmigwBiNqCg8a3crfB4xFA@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160204151303.GB6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu9n=bmsZ=UOBiLWzaG2JSsbdC8k1mB7yFbH0czrbXS-1g@mail.gmail.com>
 <20160205154234.GF6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-poQiuc7+O38n93Xt2o-SYi3kYD0k_9+-6T0=FXV9uXA@mail.gmail.com>
 <20160205160054.GG6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu8g7FHHZgmbFww_XZjf5J1utmigwBiNqCg8a3crfB4xFA@mail.gmail.com>
Message-ID: <20160205164648.GH6076@e104818-lin.cambridge.arm.com>

On Fri, Feb 05, 2016 at 05:20:14PM +0100, Ard Biesheuvel wrote:
> On 5 February 2016 at 17:00, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Fri, Feb 05, 2016 at 04:53:10PM +0100, Ard Biesheuvel wrote:
> >> On 5 February 2016 at 16:42, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> > On Thu, Feb 04, 2016 at 04:31:59PM +0100, Ard Biesheuvel wrote:
> >> >> On 4 February 2016 at 16:13, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> >> > On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
> >> >> >> This adds support for emitting PLTs at module load time for relative
> >> >> >> branches that are out of range. This is a prerequisite for KASLR, which
> >> >> >> may place the kernel and the modules anywhere in the vmalloc area,
> >> >> >> making it more likely that branch target offsets exceed the maximum
> >> >> >> range of +/- 128 MB.
> >> >> >
> >> >> > Any downside to trying to keep the kernel+modules coupled together so
> >> >> > that we avoid the PLT?
> >> >>
> >> >> First of all, note that it is unlikely that the PLTs are ever required
> >> >> in practice, considering that either
> >> >> a) the kernel is loaded at the default location right at the base of
> >> >> the vmalloc range, and in this case, the module space is reserved for
> >> >> modules only, or
> >> >> b) the kernel is loaded at some random offset in the 240+ GB vmalloc
> >> >> space, and it is unlikely that all VMA space around the kernel happens
> >> >> to be given out to non-randomized vmalloc/ioremap allocations
> >> >
> >> > My worry is that we merge some code that's rarely tested.
> >>
> >> I understand. But unfortunately, having corner cases that are unlikely
> >> but not impossible comes with the territory of randomization.
> >>
> >> Alternatively, we could take the performance hit if KASLR is in effect
> >> and allocate each module completely randomly as well. This way, the
> >> code is always exercised (for now), and we can always backpedal later
> >> if the performance is measurably worse.
> >
> > I'm fine with this. You can post it as a separate patch that we can
> > easily revert/modify later (like turning it into a config option).
> 
> OK, I will hack something up

If it's simpler, you can just add a config option but defaulting to the
full vmalloc space for modules.

-- 
Catalin


From ard.biesheuvel at linaro.org  Fri Feb  5 08:54:46 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 5 Feb 2016 17:54:46 +0100
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <20160205164648.GH6076@e104818-lin.cambridge.arm.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160204151303.GB6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu9n=bmsZ=UOBiLWzaG2JSsbdC8k1mB7yFbH0czrbXS-1g@mail.gmail.com>
 <20160205154234.GF6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-poQiuc7+O38n93Xt2o-SYi3kYD0k_9+-6T0=FXV9uXA@mail.gmail.com>
 <20160205160054.GG6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu8g7FHHZgmbFww_XZjf5J1utmigwBiNqCg8a3crfB4xFA@mail.gmail.com>
 <20160205164648.GH6076@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu-W_zKYEz0yKVevtO2b2A8+TEEXfX+iGG8PLcV7M63JYw@mail.gmail.com>

On 5 February 2016 at 17:46, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Fri, Feb 05, 2016 at 05:20:14PM +0100, Ard Biesheuvel wrote:
>> On 5 February 2016 at 17:00, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > On Fri, Feb 05, 2016 at 04:53:10PM +0100, Ard Biesheuvel wrote:
>> >> On 5 February 2016 at 16:42, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> >> > On Thu, Feb 04, 2016 at 04:31:59PM +0100, Ard Biesheuvel wrote:
>> >> >> On 4 February 2016 at 16:13, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> >> >> > On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
>> >> >> >> This adds support for emitting PLTs at module load time for relative
>> >> >> >> branches that are out of range. This is a prerequisite for KASLR, which
>> >> >> >> may place the kernel and the modules anywhere in the vmalloc area,
>> >> >> >> making it more likely that branch target offsets exceed the maximum
>> >> >> >> range of +/- 128 MB.
>> >> >> >
>> >> >> > Any downside to trying to keep the kernel+modules coupled together so
>> >> >> > that we avoid the PLT?
>> >> >>
>> >> >> First of all, note that it is unlikely that the PLTs are ever required
>> >> >> in practice, considering that either
>> >> >> a) the kernel is loaded at the default location right at the base of
>> >> >> the vmalloc range, and in this case, the module space is reserved for
>> >> >> modules only, or
>> >> >> b) the kernel is loaded at some random offset in the 240+ GB vmalloc
>> >> >> space, and it is unlikely that all VMA space around the kernel happens
>> >> >> to be given out to non-randomized vmalloc/ioremap allocations
>> >> >
>> >> > My worry is that we merge some code that's rarely tested.
>> >>
>> >> I understand. But unfortunately, having corner cases that are unlikely
>> >> but not impossible comes with the territory of randomization.
>> >>
>> >> Alternatively, we could take the performance hit if KASLR is in effect
>> >> and allocate each module completely randomly as well. This way, the
>> >> code is always exercised (for now), and we can always backpedal later
>> >> if the performance is measurably worse.
>> >
>> > I'm fine with this. You can post it as a separate patch that we can
>> > easily revert/modify later (like turning it into a config option).
>>
>> OK, I will hack something up
>
> If it's simpler, you can just add a config option but defaulting to the
> full vmalloc space for modules.
>

What would be the simplest is to randomize the 128 MB module region as
a whole, and either put it close to the kernel (which is what I am
doing now), or put it at a random offset inside the vmalloc space, in
which case all branches will be resolved via PLTs. My suggestion to
randomize each module_alloc() call separately is actually not that
straight-forward.

So what I propose now is to keep a single module_load_offset that
randomizes the base of the region, and add a default-n config option
that shrinks the interval it is chosen from so that PLTs are usually
not needed.

-- 
Ard.


From slash.tmp at free.fr  Fri Feb  5 08:58:38 2016
From: slash.tmp at free.fr (Mason)
Date: Fri, 5 Feb 2016 17:58:38 +0100
Subject: [PATCH RFC] Add cpufreq support
Message-ID: <56B4D4BE.2040008@free.fr>

I'm throwing this out there to ask:
Is this the right way to enable cpufreq on my platform?
---
 arch/arm/boot/dts/tango4-common.dtsi  | 4 ++++
 arch/arm/boot/dts/tango4-smp8758.dtsi | 2 ++
 arch/arm/mach-tango/setup.c           | 7 +++++++
 3 files changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/tango4-common.dtsi b/arch/arm/boot/dts/tango4-common.dtsi
index 41dff0a93419..557cb67d183f 100644
--- a/arch/arm/boot/dts/tango4-common.dtsi
+++ b/arch/arm/boot/dts/tango4-common.dtsi
@@ -193,3 +193,7 @@
 		};
 	};
 };
+
+&cpu0 {
+	clocks = <&clkgen CPU_CLK>;
+};
diff --git a/arch/arm/boot/dts/tango4-smp8758.dtsi b/arch/arm/boot/dts/tango4-smp8758.dtsi
index 7ed88ee629fb..0db290a8334d 100644
--- a/arch/arm/boot/dts/tango4-smp8758.dtsi
+++ b/arch/arm/boot/dts/tango4-smp8758.dtsi
@@ -11,6 +11,8 @@
 			next-level-cache = <&l2cc>;
 			device_type = "cpu";
 			reg = <0>;
+			clock-latency = <300000>;
+			operating-points = <1215000 0 607500 0 405000 0 243000 0 135000 0>;
 		};
 
 		cpu1: cpu at 1 {
diff --git a/arch/arm/mach-tango/setup.c b/arch/arm/mach-tango/setup.c
index a796841c039b..0e8f90f70e85 100644
--- a/arch/arm/mach-tango/setup.c
+++ b/arch/arm/mach-tango/setup.c
@@ -1,6 +1,7 @@
 #include <asm/mach/map.h>
 #include <asm/mach/arch.h>
 #include <asm/hardware/cache-l2x0.h>
+#include <linux/platform_device.h>
 #include "smc.h"
 
 static struct map_desc tango_map_desc[] __initdata = {
@@ -23,6 +24,11 @@ static void tango_l2c_write(unsigned long val, unsigned int reg)
 		tango_set_l2_control(val);
 }
 
+static void __init tango_init_late(void)
+{
+	platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+}
+
 static const char *const tango_dt_compat[] = { "sigma,tango4", NULL };
 
 DT_MACHINE_START(TANGO_DT, "Sigma Tango DT")
@@ -30,4 +36,5 @@ DT_MACHINE_START(TANGO_DT, "Sigma Tango DT")
 	.l2c_aux_mask	= ~0,
 	.l2c_write_sec	= tango_l2c_write,
 	.map_io		= tango_map_io,
+	.init_late	= tango_init_late,
 MACHINE_END


From tj at kernel.org  Fri Feb  5 09:04:23 2016
From: tj at kernel.org (Tejun Heo)
Date: Fri, 5 Feb 2016 12:04:23 -0500
Subject: [PATCH] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <1454539065-16891-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1454539065-16891-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <20160205170423.GE4401@htj.duckdns.org>

Hello, Tirumalesh.

On Wed, Feb 03, 2016 at 02:37:45PM -0800, tchalamarla at caviumnetworks.com wrote:
> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> 
> Due to Errata in some versions of ThunderX,
> HOST_IRQ_STAT is neither EDGE nor LEVEL,
> ThunderX needs a special sequence for handling interrupt.
> The patch attempts to satisfy the need.

Please take a look at the following patchset and coordinate with
Suman.

 http://lkml.kernel.org/g/1454620826-22554-2-git-send-email-stripathi at apm.com

Thanks.

-- 
tejun


From ddaney at caviumnetworks.com  Fri Feb  5 09:12:50 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Fri, 5 Feb 2016 09:12:50 -0800
Subject: [PATCH v4 2/2] pci, pci-thunder-pem: Add PCIe host driver for
 ThunderX processors.
In-Reply-To: <20160205031042.GA31722@localhost>
References: <1453844781-24380-1-git-send-email-ddaney.cavm@gmail.com>
 <1453844781-24380-3-git-send-email-ddaney.cavm@gmail.com>
 <20160205000452.GI7031@localhost> <56B3ECAD.4050605@caviumnetworks.com>
 <20160205031042.GA31722@localhost>
Message-ID: <56B4D812.7080106@caviumnetworks.com>

On 02/04/2016 07:10 PM, Bjorn Helgaas wrote:
> On Thu, Feb 04, 2016 at 04:28:29PM -0800, David Daney wrote:
>> On 02/04/2016 04:04 PM, Bjorn Helgaas wrote:
>>> On Tue, Jan 26, 2016 at 01:46:21PM -0800, David Daney wrote:
>>>> From: David Daney <david.daney at cavium.com>
>>>>
>>>> Some Cavium ThunderX processors require quirky access methods for the
>>>> config space of the PCIe bridge.  Add a driver to provide these config
>>>> space accessor functions.  The pci-host-common code is used to
>>>> configure the PCI machinery.
>>>>
>>>> Signed-off-by: David Daney <david.daney at cavium.com>
>>>> Acked-by: Rob Herring <robh at kernel.org>
>>>> Acked-by: Arnd Bergmann <arnd at arndb.de>
>>>> ---
>>>>   .../devicetree/bindings/pci/pci-thunder-pem.txt    |  43 ++++
>>>>   MAINTAINERS                                        |   8 +
>>>>   drivers/pci/host/Kconfig                           |   7 +
>>>>   drivers/pci/host/Makefile                          |   1 +
>>>>   drivers/pci/host/pci-thunder-pem.c                 | 283 +++++++++++++++++++++
>>>
>>> What's the significance of the "pem" part of the name?  I'm wondering
>>> if we can shorten the filenames and function names by dropping it and
>>> referring to this simply as "thunder" or "thunderx".
>>
>> PEM == PCI Express MAC, Essentially the circuitry related to
>> off-chip PCI devices.  This differentiates it from the internal
>> on-chip devices which are connected to internal buses we refer to as
>> "ECAMs"
>
> That's an unusual and confusing usage of ECAM, since the PCIe spec
> uses ECAM for "Enhanced Configuration Access Mechanism", which is not
> a bus.
>
>> See also the follow on patch, from me, that adds the
>> pci-thunder-ecam.c driver.
>
> OK.  In PCIe spec terms, I guess your PEM and ECAM are two separate
> root complexes?

Correct.

> The spec defines a way to build a logical topology
> and doesn't really care whether the devices are on-chip or off-chip.
>

Yes, I know this.

The different names were chosen as a way to differentiate the two types 
of root complexes.  If we temporarily suspend our knowledge of the 
meaning of the term "ECAM" with respect to the PCI specifications, we 
can think of them as random names:

PEM: Root complex type for access to external PCIe connections.

ECAM: Root complex type for access to on-chip devices.


>> Since PEM and ECAM are terminology used in the hardware manuals that
>> have specific meanings relative to the Thunder SoC family, I think
>> it is not too inconvenient to carry them over into the file names.
>
> As long as PEM and ECAM are really two distinct root complexes that
> are unrelated, I guess this is OK.

They are, see above.

>
> I was imagining that PEM devices and ECAM devices would be in the same
> hierarchy, in the same domain, in the same bus number space, but with
> different ways of accessing their config space.  If that were the
> case, you could have a single driver with config accessors that were
> smart enough to figure out which method to use.  But if they're truly
> separate and unrelated, then I guess it makes sense to have two
> drivers.
>

The, somewhat unfortunate, fact is that due to the hardware design of 
the first generation of Thunder SoCs, There really are two separate 
types of config access methods for these things.  The result is two 
separate drivers.


> Maybe a concrete example would make this clearer to me.  Can you share
> a dmesg log and lspci output showing both PEM and ECAM devices?

As system with the maximum configuration would be a two node NUMA system 
with 4 "ECAM" and 6 "PEM" type root complexes per node for a total of 20 
root complexes in the system.

Here is the output from a simpler system with *only*  4 "ECAM" and 2 
"PEM" configured:
.
.
.
[    4.557825] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    4.563423] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    4.570128] PCI host bridge /soc at 0/pci at 8480,00000000 ranges:
[    4.575808]   MEM 0x801000000000..0x807fffffffff -> 0x801000000000
[    4.581993]   MEM 0x838000000000..0x841fffffffff -> 0x838000000000
[    4.588179]   MEM 0x846000000000..0x847fffffffff -> 0x846000000000
[    4.594363]   MEM 0x868000000000..0x87e023ffffff -> 0x868000000000
[    4.600546]   MEM 0x87e026000000..0x87e0bfffffff -> 0x87e026000000
[    4.606728]   MEM 0x87e0c6000000..0x87ffffffffff -> 0x87e0c6000000
[    4.613198] pci-host-generic 848000000000.pci: PCI host bridge to bus 
0000:00
[    4.620340] pci_bus 0000:00: root bus resource [bus 00-1f]
[    4.625822] pci_bus 0000:00: root bus resource [mem 
0x801000000000-0x807fffffffff]
[    4.633388] pci_bus 0000:00: root bus resource [mem 
0x838000000000-0x841fffffffff]
[    4.640951] pci_bus 0000:00: root bus resource [mem 
0x846000000000-0x847fffffffff]
[    4.648514] pci_bus 0000:00: root bus resource [mem 
0x868000000000-0x87e023ffffff]
[    4.656077] pci_bus 0000:00: root bus resource [mem 
0x87e026000000-0x87e0bfffffff]
[    4.663639] pci_bus 0000:00: root bus resource [mem 
0x87e0c6000000-0x87ffffffffff]
[    4.671448] iommu: Adding device 0000:00:01.0 to group 6
[    4.677031] iommu: Adding device 0000:00:06.0 to group 7
[    5.683787] pci 0000:00:09.0: VF(n) BAR0 space: [mem 
0x840000800000-0x8400008fffff 64bit] (contains BAR0 for 1 VFs)
[    5.694395] iommu: Adding device 0000:00:09.0 to group 8
[    5.699986] iommu: Adding device 0000:00:10.0 to group 9
[    5.705564] iommu: Adding device 0000:00:11.0 to group 10
[    5.711199] iommu: Adding device 0000:00:14.0 to group 11
[    5.716834] iommu: Adding device 0000:00:15.0 to group 12
[    5.722470] iommu: Adding device 0000:00:16.0 to group 13
[    5.728279] iommu: Adding device 0000:01:00.0 to group 6
[    5.733844] iommu: Adding device 0000:01:00.1 to group 6
[    5.739411] iommu: Adding device 0000:01:00.5 to group 6
[    5.744978] iommu: Adding device 0000:01:01.3 to group 6
[    5.750547] iommu: Adding device 0000:01:06.0 to group 6
[    5.756115] iommu: Adding device 0000:01:06.1 to group 6
[    5.761680] iommu: Adding device 0000:01:06.2 to group 6
[    5.767243] iommu: Adding device 0000:01:06.3 to group 6
[    5.772808] iommu: Adding device 0000:01:06.4 to group 6
[    5.778373] iommu: Adding device 0000:01:06.5 to group 6
[    5.783947] iommu: Adding device 0000:01:06.6 to group 6
[    5.789511] iommu: Adding device 0000:01:06.7 to group 6
[    5.795076] iommu: Adding device 0000:01:07.0 to group 6
[    5.800640] iommu: Adding device 0000:01:07.1 to group 6
[    5.806206] iommu: Adding device 0000:01:07.2 to group 6
[    5.815374] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe device. 
  You can enable it with 'pcie_aspm=force'
[    5.825766] iommu: Adding device 0000:02:00.0 to group 11
[    5.831182] pci 0000:02:00.0: disabling ASPM on pre-1.1 PCIe device. 
  You can enable it with 'pcie_aspm=force'
[    5.841533] iommu: Adding device 0000:03:00.0 to group 12
[    5.846949] pci 0000:03:00.0: disabling ASPM on pre-1.1 PCIe device. 
  You can enable it with 'pcie_aspm=force'
[    5.857297] iommu: Adding device 0000:04:00.0 to group 13
[    5.862712] pci 0000:04:00.0: disabling ASPM on pre-1.1 PCIe device. 
  You can enable it with 'pcie_aspm=force'
[    5.873315] pci 0000:00:01.0: PCI bridge to [bus 01]
[    5.878291] pci 0000:00:14.0: PCI bridge to [bus 02]
[    5.883257] pci 0000:00:15.0: PCI bridge to [bus 03]
[    5.888222] pci 0000:00:16.0: PCI bridge to [bus 04]
[    5.893758] PCI host bridge /soc at 0/pci at 8490,00000000 ranges:
[    5.899426]   MEM 0x810000000000..0x817fffffffff -> 0x810000000000
[    5.905882] pci-host-generic 849000000000.pci: PCI host bridge to bus 
0001:00
[    5.913017] pci_bus 0001:00: root bus resource [bus 00-1f]
[    5.918497] pci_bus 0001:00: root bus resource [mem 
0x810000000000-0x817fffffffff]
[    5.926371] iommu: Adding device 0001:00:04.0 to group 14
[    5.932094] iommu: Adding device 0001:00:05.0 to group 15
[    5.937811] iommu: Adding device 0001:00:06.0 to group 16
[    5.943540] iommu: Adding device 0001:00:07.0 to group 17
[    5.949582] PCI host bridge /soc at 0/pci at 84a0,00000000 ranges:
[    5.955249]   MEM 0x842000000000..0x843fffffffff -> 0x842000000000
[    5.961693] pci-host-generic 84a000000000.pci: PCI host bridge to bus 
0002:00
[    5.968828] pci_bus 0002:00: root bus resource [bus 00-1f]
[    5.974308] pci_bus 0002:00: root bus resource [mem 
0x842000000000-0x843fffffffff]
[    5.982150] iommu: Adding device 0002:00:02.0 to group 18
[    5.987890] iommu: Adding device 0002:00:03.0 to group 19
[    6.995785] pci 0002:01:00.0: VF(n) BAR0 space: [mem 
0x8430a0000000-0x8430afffffff 64bit] (contains BAR0 for 128 VFs)
[    7.006397] pci 0002:01:00.0: VF(n) BAR4 space: [mem 
0x8430e0000000-0x8430efffffff 64bit] (contains BAR4 for 128 VFs)
[    7.017331] iommu: Adding device 0002:01:00.0 to group 18
[    7.022746] pci 0002:01:00.0: disabling ASPM on pre-1.1 PCIe device. 
  You can enable it with 'pcie_aspm=force'
[    7.033334] pci 0002:00:02.0: PCI bridge to [bus 01]
[    7.038398] PCI host bridge /soc at 0/pci at 84b0,00000000 ranges:
[    7.044066]   MEM 0x818000000000..0x81ffffffffff -> 0x818000000000
[    7.050512] pci-host-generic 84b000000000.pci: PCI host bridge to bus 
0003:00
[    7.057647] pci_bus 0003:00: root bus resource [bus 00-1f]
[    7.063127] pci_bus 0003:00: root bus resource [mem 
0x818000000000-0x81ffffffffff]
[    7.071425] PCI host bridge /soc at 0/pci at 87e0,c2000000 ranges:
[    7.077095]    IO 0x88b000020000..0x88b00002ffff -> 0x00020000
[    7.082933]   MEM 0x889010000000..0x889fffffffff -> 0x10000000
[    7.088769]   MEM 0x88a000000000..0x88afffffffff -> 0x1000000000
[    7.094774]   MEM 0x87e0c2000000..0x87e0c2ffffff -> 0x87e0c2000000
[    7.101906] pci_thunder_pem 88808f000000.pci: PCI host bridge to bus 
0004:8f
[    7.108954] pci_bus 0004:8f: root bus resource [bus 8f-c7]
[    7.114435] pci_bus 0004:8f: root bus resource [io  0x0000-0xffff] 
(bus address [0x20000-0x2ffff])
[    7.123387] pci_bus 0004:8f: root bus resource [mem 
0x889010000000-0x889fffffffff] (bus address [0x10000000-0xfffffffff])
[    7.134335] pci_bus 0004:8f: root bus resource [mem 
0x88a000000000-0x88afffffffff pref] (bus address 
[0x1000000000-0x1fffffffff])
[    7.146009] pci_bus 0004:8f: root bus resource [mem 
0x87e0c2000000-0x87e0c2ffffff]
[    7.153949] iommu: Adding device 0004:8f:00.0 to group 20
[    7.159396] pci 0004:8f:00.0: Primary bus is hard wired to 0
[    7.165241] pci 0004:90:00.0: Max Payload Size set to 256 (was 128, 
max 2048)
[    7.172713] iommu: Adding device 0004:90:00.0 to group 20
[    7.183967] pci 0004:91:00.0: Max Payload Size set to 256 (was 128, 
max 2048)
[    7.191391] iommu: Adding device 0004:91:00.0 to group 20
[    7.196864] pci 0004:91:08.0: Max Payload Size set to 256 (was 128, 
max 2048)
[    7.204283] iommu: Adding device 0004:91:08.0 to group 20
[    7.209747] pci 0004:91:09.0: Max Payload Size set to 256 (was 128, 
max 2048)
[    7.217184] iommu: Adding device 0004:91:09.0 to group 20
[    7.222649] pci 0004:91:08.0: bridge configuration invalid ([bus 
00-00]), reconfiguring
[    7.230656] pci 0004:91:09.0: bridge configuration invalid ([bus 
00-00]), reconfiguring
[    7.238796] pci 0004:92:00.0: reg 0x10: initial BAR value 0x00000000 
invalid
[    7.245855] pci 0004:92:00.0: reg 0x14: initial BAR value 
0x889010100000 invalid
[    7.253277] pci 0004:92:00.0: Max Payload Size set to 256 (was 128, 
max 4096)
[    7.260535] pci 0004:92:00.0: VF(n) BAR0 space: [mem 
0x00000000-0x000fffff 64bit] (contains BAR0 for 16 VFs)
[    7.270592] iommu: Adding device 0004:92:00.0 to group 20
[    7.284074] pci 0004:94:00.0: reg 0x10: initial BAR value 0x00000000 
invalid
[    7.291168] pci 0004:94:00.0: Max Payload Size set to 256 (was 128, 
max 4096)
[    7.298426] pci 0004:94:00.0: VF(n) BAR0 space: [mem 
0x00000000-0x000fffff 64bit] (contains BAR0 for 16 VFs)
[    7.308498] iommu: Adding device 0004:94:00.0 to group 20
[    7.320615] pci 0004:8f:00.0: BAR 14: assigned [mem 
0x889010000000-0x8890106fffff]
[    7.328183] pci 0004:8f:00.0: BAR 15: assigned [mem 
0x88a000000000-0x88a0003fffff 64bit pref]
[    7.336702] pci 0004:8f:00.0: BAR 6: assigned [mem 
0x889010700000-0x88901070ffff pref]
[    7.344612] pci 0004:8f:00.0: BAR 13: assigned [io  0x1000-0x2fff]
[    7.350793] pci 0004:90:00.0: BAR 14: assigned [mem 
0x889010000000-0x8890105fffff]
[    7.358357] pci 0004:90:00.0: BAR 15: assigned [mem 
0x88a000000000-0x88a0003fffff 64bit pref]
[    7.366875] pci 0004:90:00.0: BAR 0: assigned [mem 
0x889010600000-0x88901063ffff]
[    7.374354] pci 0004:90:00.0: BAR 13: assigned [io  0x1000-0x2fff]
[    7.380536] pci 0004:91:00.0: BAR 14: assigned [mem 
0x889010000000-0x8890102fffff]
[    7.388100] pci 0004:91:00.0: BAR 15: assigned [mem 
0x88a000000000-0x88a0001fffff 64bit pref]
[    7.396618] pci 0004:91:09.0: BAR 14: assigned [mem 
0x889010300000-0x8890105fffff]
[    7.404181] pci 0004:91:09.0: BAR 15: assigned [mem 
0x88a000200000-0x88a0003fffff 64bit pref]
[    7.412698] pci 0004:91:00.0: BAR 13: assigned [io  0x1000-0x1fff]
[    7.418872] pci 0004:91:09.0: BAR 13: assigned [io  0x2000-0x2fff]
[    7.425053] pci 0004:92:00.0: BAR 6: assigned [mem 
0x889010000000-0x8890100fffff pref]
[    7.432964] pci 0004:92:00.0: BAR 1: assigned [mem 
0x889010100000-0x88901010ffff 64bit]
[    7.440967] pci 0004:92:00.0: BAR 7: assigned [mem 
0x889010110000-0x88901020ffff 64bit]
[    7.448968] pci 0004:92:00.0: BAR 0: assigned [io  0x1000-0x10ff]
[    7.455058] pci 0004:91:00.0: PCI bridge to [bus 92]
[    7.460018] pci 0004:91:00.0:   bridge window [io  0x1000-0x1fff]
[    7.466106] pci 0004:91:00.0:   bridge window [mem 
0x889010000000-0x8890102fffff]
[    7.473582] pci 0004:91:00.0:   bridge window [mem 
0x88a000000000-0x88a0001fffff 64bit pref]
[    7.482013] pci 0004:91:08.0: PCI bridge to [bus 93]
[    7.486981] pci 0004:94:00.0: BAR 6: assigned [mem 
0x889010300000-0x8890103fffff pref]
[    7.494892] pci 0004:94:00.0: BAR 1: assigned [mem 
0x889010400000-0x88901040ffff 64bit]
[    7.502895] pci 0004:94:00.0: BAR 7: assigned [mem 
0x889010410000-0x88901050ffff 64bit]
[    7.510896] pci 0004:94:00.0: BAR 0: assigned [io  0x2000-0x20ff]
[    7.516987] pci 0004:91:09.0: PCI bridge to [bus 94]
[    7.521946] pci 0004:91:09.0:   bridge window [io  0x2000-0x2fff]
[    7.528033] pci 0004:91:09.0:   bridge window [mem 
0x889010300000-0x8890105fffff]
[    7.535509] pci 0004:91:09.0:   bridge window [mem 
0x88a000200000-0x88a0003fffff 64bit pref]
[    7.543940] pci 0004:90:00.0: PCI bridge to [bus 91-94]
[    7.549160] pci 0004:90:00.0:   bridge window [io  0x1000-0x2fff]
[    7.555247] pci 0004:90:00.0:   bridge window [mem 
0x889010000000-0x8890105fffff]
[    7.562724] pci 0004:90:00.0:   bridge window [mem 
0x88a000000000-0x88a0003fffff 64bit pref]
[    7.571155] pci 0004:8f:00.0: PCI bridge to [bus 90-94]
[    7.576374] pci 0004:8f:00.0:   bridge window [io  0x1000-0x2fff]
[    7.582462] pci 0004:8f:00.0:   bridge window [mem 
0x889010000000-0x8890106fffff]
[    7.589938] pci 0004:8f:00.0:   bridge window [mem 
0x88a000000000-0x88a0003fffff 64bit pref]
[    7.598403] pcieport 0004:8f:00.0: enabling device (0506 -> 0507)
[    7.604893] pcieport 0004:8f:00.0: Signaling PME through PCIe PME 
interrupt
[    7.611862] pci 0004:90:00.0: Signaling PME through PCIe PME interrupt
[    7.618384] pci 0004:91:00.0: Signaling PME through PCIe PME interrupt
[    7.624908] pci 0004:92:00.0: Signaling PME through PCIe PME interrupt
[    7.631438] pci 0004:91:08.0: Signaling PME through PCIe PME interrupt
[    7.637958] pci 0004:91:09.0: Signaling PME through PCIe PME interrupt
[    7.644478] pci 0004:94:00.0: Signaling PME through PCIe PME interrupt
[    7.651672] pciehp 0004:91:00.0:pcie24: Slot #64 AttnBtn+ PwrCtrl+ 
MRL+ AttnInd+ PwrInd+ HotPlug+ Surprise- Interlock- NoCompl- LLActRep+
[    7.664702] pcieport 0004:91:09.0: enabling device (0000 -> 0003)
[    7.670996] pciehp 0004:91:09.0:pcie24: Slot #73 AttnBtn+ PwrCtrl+ 
MRL+ AttnInd+ PwrInd+ HotPlug+ Surprise- Interlock- NoCompl- LLActRep+
[    7.683786] PCI host bridge /soc at 0/pci at 87e0,c5000000 ranges:
[    7.689454]    IO 0x89b000050000..0x89b00005ffff -> 0x00050000
[    7.695292]   MEM 0x899010000000..0x899fffffffff -> 0x10000000
[    7.701129]   MEM 0x89a000000000..0x89afffffffff -> 0x1000000000
[    7.707134]   MEM 0x87e0c5000000..0x87e0c5ffffff -> 0x87e0c5000000
[    7.714262] pci_thunder_pem 89808f000000.pci: PCI host bridge to bus 
0005:8f
[    7.721311] pci_bus 0005:8f: root bus resource [bus 8f-c7]
[    7.726792] pci_bus 0005:8f: root bus resource [io  0x10000-0x1ffff] 
(bus address [0x50000-0x5ffff])
[    7.735917] pci_bus 0005:8f: root bus resource [mem 
0x899010000000-0x899fffffffff] (bus address [0x10000000-0xfffffffff])
[    7.746866] pci_bus 0005:8f: root bus resource [mem 
0x89a000000000-0x89afffffffff pref] (bus address 
[0x1000000000-0x1fffffffff])
[    7.758508] pci_bus 0005:8f: root bus resource [mem 
0x87e0c5000000-0x87e0c5ffffff]
[    7.766445] iommu: Adding device 0005:8f:00.0 to group 21
[    7.771891] pci 0005:8f:00.0: Primary bus is hard wired to 0
[    7.777715] pci 0005:90:00.0: reg 0x14: initial BAR value 
0x899020000000 invalid
[    7.785123] pci 0005:90:00.0: reg 0x1c: initial BAR value 
0x899030000000 invalid
[    7.792543] pci 0005:90:00.0: can't set Max Payload Size to 256; if 
necessary, use "pci=pcie_bus_safe" and report a bug
[    7.803569] iommu: Adding device 0005:90:00.0 to group 21
[    7.808970] vgaarb: device added: 
PCI:0005:90:00.0,decodes=io+mem,owns=none,locks=none
[    7.816973] pci 0005:90:00.1: can't set Max Payload Size to 256; if 
necessary, use "pci=pcie_bus_safe" and report a bug
[    7.827992] iommu: Adding device 0005:90:00.1 to group 21
[    7.840658] pci 0005:8f:00.0: BAR 15: assigned [mem 
0x89a000000000-0x89a017ffffff 64bit pref]
[    7.849181] pci 0005:8f:00.0: BAR 14: assigned [mem 
0x899010000000-0x8990117fffff]
[    7.856745] pci 0005:8f:00.0: BAR 6: assigned [mem 
0x899011800000-0x89901180ffff pref]
[    7.864655] pci 0005:8f:00.0: BAR 13: assigned [io  0x10000-0x10fff]
[    7.871012] pci 0005:90:00.0: BAR 1: assigned [mem 
0x89a000000000-0x89a00fffffff 64bit pref]
[    7.879450] pci 0005:90:00.0: BAR 3: assigned [mem 
0x89a010000000-0x89a011ffffff 64bit pref]
[    7.887886] pci 0005:90:00.0: BAR 0: assigned [mem 
0x899010000000-0x899010ffffff]
[    7.895364] pci 0005:90:00.0: BAR 6: assigned [mem 
0x899011000000-0x89901107ffff pref]
[    7.903275] pci 0005:90:00.1: BAR 0: assigned [mem 
0x899011080000-0x899011083fff]
[    7.910752] pci 0005:90:00.0: BAR 5: assigned [io  0x10000-0x1007f]
[    7.917018] pci 0005:8f:00.0: PCI bridge to [bus 90]
[    7.921977] pci 0005:8f:00.0:   bridge window [io  0x10000-0x10fff]
[    7.928238] pci 0005:8f:00.0:   bridge window [mem 
0x899010000000-0x8990117fffff]
[    7.935714] pci 0005:8f:00.0:   bridge window [mem 
0x89a000000000-0x89a017ffffff 64bit pref]
[    7.944179] pcieport 0005:8f:00.0: enabling device (0506 -> 0507)
[    7.950649] pcieport 0005:8f:00.0: Signaling PME through PCIe PME 
interrupt
[    7.957618] pci 0005:90:00.0: Signaling PME through PCIe PME interrupt
[    7.964140] pci 0005:90:00.1: Signaling PME through PCIe PME interrupt
.
.
.
# lspci -t
-+-[0005:8f]---00.0-[90]--+-00.0
  |                        \-00.1
  +-[0004:8f]---00.0-[90-94]----00.0-[91-94]--+-00.0-[92]----00.0
  |                                           +-08.0-[93]--
  |                                           \-09.0-[94]----00.0
  +-[0002:00]-+-02.0-[01]--+-00.0
  |           |            +-00.1
  |           |            +-00.2
  |           |            +-00.3
  |           |            +-00.4
  |           |            +-00.5
  |           |            +-00.6
  |           |            +-00.7
  |           |            +-01.0
  |           |            +-01.1
  |           |            +-01.2
  |           |            +-01.3
  |           |            +-01.4
  |           |            +-01.5
  |           |            +-01.6
  |           |            +-01.7
  |           |            +-02.0
  |           |            +-02.1
  |           |            +-02.2
  |           |            +-02.3
  |           |            +-02.4
  |           |            +-02.5
  |           |            +-02.6
  |           |            +-02.7
  |           |            \-03.0
  |           \-03.0
  +-[0001:00]-+-04.0
  |           +-05.0
  |           +-06.0
  |           \-07.0
  \-[0000:00]-+-01.0-[01]--+-00.0
              |            +-00.1
              |            +-00.5
              |            +-01.3
              |            +-06.0
              |            +-06.1
              |            +-06.2
              |            +-06.3
              |            +-06.4
              |            +-06.5
              |            +-06.6
              |            +-06.7
              |            +-07.0
              |            +-07.1
              |            +-07.2
              |            +-07.3
              |            +-07.4
              |            +-07.5
              |            +-07.6
              |            +-07.7
              |            +-09.0
              |            +-09.1
              |            +-09.2
              |            +-09.3
              |            +-09.4
              |            +-09.5
              |            +-0a.0
              |            +-0a.1
              |            +-0a.2
              |            +-0a.3
              |            \-10.0
              +-06.0
              +-09.0
              +-10.0
              +-11.0
              +-14.0-[02]----00.0
              +-15.0-[03]----00.0
              \-16.0-[04]----00.0


# lspci
0000:00:01.0 PCI bridge: Cavium, Inc. THUNDERX PCC Bridge (rev 08)
0000:00:06.0 System peripheral: Cavium, Inc. THUNDERX GPIO Controller 
(rev 08)
0000:00:09.0 Processing accelerators: Cavium, Inc. THUNDERX Random 
Number Generator (rev 08)
0000:00:10.0 USB controller: Cavium, Inc. THUNDERX xHCI USB Controller 
(rev 08)
0000:00:11.0 USB controller: Cavium, Inc. THUNDERX xHCI USB Controller 
(rev 08)
0000:00:14.0 PCI bridge: Cavium, Inc. THUNDERX PCC Bridge (rev 08)
0000:00:15.0 PCI bridge: Cavium, Inc. THUNDERX PCC Bridge (rev 08)
0000:00:16.0 PCI bridge: Cavium, Inc. THUNDERX PCC Bridge (rev 08)
0000:01:00.0 System peripheral: Cavium, Inc. THUNDERX MRML Bridge (rev 08)
0000:01:00.1 System peripheral: Cavium, Inc. THUNDERX Reset Controller 
(rev 08)
0000:01:00.5 System peripheral: Cavium, Inc. THUNDERX CCPI (Multi-node 
connect) (rev 08)
0000:01:01.3 Serial bus controller [0c80]: Cavium, Inc. THUNDERX SMI / 
MDIO Controller (rev 08)
0000:01:06.0 Memory controller: Cavium, Inc. THUNDERX L2C-TAD (rev 08)
0000:01:06.1 Memory controller: Cavium, Inc. THUNDERX L2C-TAD (rev 08)
0000:01:06.2 Memory controller: Cavium, Inc. THUNDERX L2C-TAD (rev 08)
0000:01:06.3 Memory controller: Cavium, Inc. THUNDERX L2C-TAD (rev 08)
0000:01:06.4 Memory controller: Cavium, Inc. THUNDERX L2C-TAD (rev 08)
0000:01:06.5 Memory controller: Cavium, Inc. THUNDERX L2C-TAD (rev 08)
0000:01:06.6 Memory controller: Cavium, Inc. THUNDERX L2C-TAD (rev 08)
0000:01:06.7 Memory controller: Cavium, Inc. THUNDERX L2C-TAD (rev 08)
0000:01:07.0 Memory controller: Cavium, Inc. THUNDERX L2C-CBC (rev 08)
0000:01:07.1 Memory controller: Cavium, Inc. THUNDERX L2C-CBC (rev 08)
0000:01:07.2 Memory controller: Cavium, Inc. THUNDERX L2C-CBC (rev 08)
0000:01:07.3 Memory controller: Cavium, Inc. THUNDERX L2C-CBC (rev 08)
0000:01:07.4 Memory controller: Cavium, Inc. THUNDERX L2C-MCI (rev 08)
0000:01:07.5 Memory controller: Cavium, Inc. THUNDERX L2C-MCI (rev 08)
0000:01:07.6 Memory controller: Cavium, Inc. THUNDERX L2C-MCI (rev 08)
0000:01:07.7 Memory controller: Cavium, Inc. THUNDERX L2C-MCI (rev 08)
0000:01:09.0 Serial bus controller [0c80]: Cavium, Inc. THUNDERX TWSI / 
I2C Controller (rev 08)
0000:01:09.1 Serial bus controller [0c80]: Cavium, Inc. THUNDERX TWSI / 
I2C Controller (rev 08)
0000:01:09.2 Serial bus controller [0c80]: Cavium, Inc. THUNDERX TWSI / 
I2C Controller (rev 08)
0000:01:09.3 Serial bus controller [0c80]: Cavium, Inc. THUNDERX TWSI / 
I2C Controller (rev 08)
0000:01:09.4 Serial bus controller [0c80]: Cavium, Inc. THUNDERX TWSI / 
I2C Controller (rev 08)
0000:01:09.5 Serial bus controller [0c80]: Cavium, Inc. THUNDERX TWSI / 
I2C Controller (rev 08)
0000:01:0a.0 Memory controller: Cavium, Inc. THUNDERX LMC (DRAM 
Controller) (rev 08)
0000:01:0a.1 Memory controller: Cavium, Inc. THUNDERX LMC (DRAM 
Controller) (rev 08)
0000:01:0a.2 Memory controller: Cavium, Inc. THUNDERX LMC (DRAM 
Controller) (rev 08)
0000:01:0a.3 Memory controller: Cavium, Inc. THUNDERX LMC (DRAM 
Controller) (rev 08)
0000:01:10.0 Network controller: Cavium, Inc. THUNDERX BGX (Common 
Ethernet Interface) (rev 08)
0000:02:00.0 RAID bus controller: Cavium, Inc. THUNDERX RAID Coprocessor 
(rev 08)
0000:03:00.0 Processing accelerators: Cavium, Inc. THUNDERX Zip 
Coprocessor (rev 08)
0000:04:00.0 Processing accelerators: Cavium, Inc. THUNDERX DFA (rev 08)
0001:00:04.0 SATA controller: Cavium, Inc. THUNDERX AHCI SATA Controller 
(rev 08)
0001:00:05.0 SATA controller: Cavium, Inc. THUNDERX AHCI SATA Controller 
(rev 08)
0001:00:06.0 SATA controller: Cavium, Inc. THUNDERX AHCI SATA Controller 
(rev 08)
0001:00:07.0 SATA controller: Cavium, Inc. THUNDERX AHCI SATA Controller 
(rev 08)
0002:00:02.0 PCI bridge: Cavium, Inc. THUNDERX PCC Bridge (rev 08)
0002:00:03.0 Network controller: Cavium, Inc. THUNDERX Traffic Network 
Switch (rev 08)
0002:01:00.0 Ethernet controller: Cavium, Inc. THUNDERX Network 
Interface Controller (rev 08)
0002:01:00.1 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:00.2 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:00.3 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:00.4 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:00.5 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:00.6 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:00.7 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:01.0 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:01.1 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:01.2 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:01.3 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:01.4 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:01.5 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:01.6 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:01.7 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:02.0 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:02.1 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:02.2 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:02.3 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:02.4 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:02.5 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:02.6 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:02.7 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0002:01:03.0 Ethernet controller: Cavium, Inc. Device a034 (rev 08)
0004:8f:00.0 PCI bridge: Cavium, Inc. Device a100 (rev 08)
0004:90:00.0 PCI bridge: PLX Technology, Inc. Device 8724 (rev ca)
0004:91:00.0 PCI bridge: PLX Technology, Inc. Device 8724 (rev ca)
0004:91:08.0 PCI bridge: PLX Technology, Inc. Device 8724 (rev ca)
0004:91:09.0 PCI bridge: PLX Technology, Inc. Device 8724 (rev ca)
0004:92:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic 
SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02)
0004:94:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic 
SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02)
0005:8f:00.0 PCI bridge: Cavium, Inc. Device a100 (rev 08)
0005:90:00.0 VGA compatible controller: NVIDIA Corporation GT218 
[GeForce 210] (rev a2)
0005:90:00.1 Audio device: NVIDIA Corporation High Definition Audio 
Controller (rev a1)

>
>>>>   5 files changed, 342 insertions(+)
>>>>   create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-pem.txt
>>>>   create mode 100644 drivers/pci/host/pci-thunder-pem.c
>>>>
>>
>>>> +
>>>> +static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
>>>> +				    int where, int size, u32 val)
>>>> +{
>>>> +	struct gen_pci *pci = bus->sysdata;
>>>> +	struct thunder_pem_pci *pem_pci;
>>>> +
>>>> +	pem_pci = container_of(pci, struct thunder_pem_pci, gen_pci);
>>>> +
>>>> +	/*
>>>> +	 * The first device on the bus in the PEM PCIe bridge.
>>>> +	 * Special case its config access.
>>>> +	 */
>>>> +	if (bus->number == pci->cfg.bus_range->start) {
>>>> +		u64 write_val, read_val;
>>>> +
>>>> +		if (devfn != 0 || where >= 2048)
>>>> +			return PCIBIOS_DEVICE_NOT_FOUND;
>>>> +
>>>> +		/*
>>>> +		 * 32-bit accesses only.  If the write is for a size
>>>> +		 * smaller than 32-bits, we must first read the 32-bit
>>>> +		 * value and merge in the desired bits and then write
>>>> +		 * the whole 32-bits back out.
>>>> +		 */
>>>
>>> Ugh.  Another device that only supports 32-bit writes.  I guess this
>>> only affects this single device, and maybe you "know" that it has no
>>> registers where RW1C bits may be corrupted.  Although I suppose this
>>> device has the standard status registers (Status at 0x06, Secondary
>>> Status at 0x1e, Device Status in PCIe capability, etc.), which do
>>> contain RW1C bits.
>>
>> This device is exactly the specific PCIe host bridge implementation,
>> present on these SoCs.  The only sane way to access its config space
>> is via 32-bit operations.  We know that it presents the appropriate
>> Class and other registers to be recognized as, and operate as, a
>> standard PCIe bridge.
>
> The only sane way to manage spec-conformant 16-bit Command and Status
> Registers is to use 16-bit accesses.  Using a 32-bit read/modify/write
> cycle to emulate a 16-bit write to the Command register means that we
> inadvertently clear any RW1C bits that happened to be set in the
> adjacent Status register.
>
> Note that these are generic PCI-defined registers, and the code doing
> 16-bit accesses to them may be in the PCI core or possibly in a
> driver.  They're not ThunderX-specific registers, and it's not
> ThunderX-specific code.
>
>>> We need to print a warning at probe-time so we know to consider the
>>> possibility of corruption when debugging.
>>
>> If you really want it, I suppose I can add that, but I am somewhat hesitant.
>
> I think this is a serious quality of implementation issue, and I do
> not want to debug status bits that mysteriously get cleared when
> nothing in the PCI core code even touches them.  I at least want a
> hint.
>
> We have a warning in pcie-hisi.c already, and I intend to do something
> similar in tegra, xgene, and iproc, which use
> pci_generic_config_write32().  There are probably others that roll
> their own.  I'm thinking something along the lines of
> dev_warn("sub-32-bit writes may corrupt adjacent RW1C bits").
>
> I don't really like this either, so I'm open to better ideas.  I
> considered a one-time warning in pci_generic_config_write32(), but
> that would associate the message with the PCI device when the problem
> is in the host bridge, and obviously it wouldn't help for ThunderX
> anyway.
>

I will add a WARN_ONCE or similar. and send a new patch set.

FWIW, I think I have been able to get the message through to the 
hardware architects that building root complexes that are not exposed as 
PCI standard ECAMs makes things very difficult.  This was the original 
intention, but turned out not to be possible when we looked more closely 
at the hardware implementation.  I am optimistic that subsequent 
generations of Thunder will be much improved in this area.

Thanks for taking the time to look at the patches,
David Daney



From catalin.marinas at arm.com  Fri Feb  5 09:21:17 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 5 Feb 2016 17:21:17 +0000
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <CAKv+Gu-W_zKYEz0yKVevtO2b2A8+TEEXfX+iGG8PLcV7M63JYw@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160204151303.GB6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu9n=bmsZ=UOBiLWzaG2JSsbdC8k1mB7yFbH0czrbXS-1g@mail.gmail.com>
 <20160205154234.GF6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-poQiuc7+O38n93Xt2o-SYi3kYD0k_9+-6T0=FXV9uXA@mail.gmail.com>
 <20160205160054.GG6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu8g7FHHZgmbFww_XZjf5J1utmigwBiNqCg8a3crfB4xFA@mail.gmail.com>
 <20160205164648.GH6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-W_zKYEz0yKVevtO2b2A8+TEEXfX+iGG8PLcV7M63JYw@mail.gmail.com>
Message-ID: <20160205172117.GI6076@e104818-lin.cambridge.arm.com>

On Fri, Feb 05, 2016 at 05:54:46PM +0100, Ard Biesheuvel wrote:
> On 5 February 2016 at 17:46, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Fri, Feb 05, 2016 at 05:20:14PM +0100, Ard Biesheuvel wrote:
> >> On 5 February 2016 at 17:00, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> > On Fri, Feb 05, 2016 at 04:53:10PM +0100, Ard Biesheuvel wrote:
> >> >> On 5 February 2016 at 16:42, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> >> > On Thu, Feb 04, 2016 at 04:31:59PM +0100, Ard Biesheuvel wrote:
> >> >> >> On 4 February 2016 at 16:13, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> >> >> > On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
> >> >> >> >> This adds support for emitting PLTs at module load time for relative
> >> >> >> >> branches that are out of range. This is a prerequisite for KASLR, which
> >> >> >> >> may place the kernel and the modules anywhere in the vmalloc area,
> >> >> >> >> making it more likely that branch target offsets exceed the maximum
> >> >> >> >> range of +/- 128 MB.
> >> >> >> >
> >> >> >> > Any downside to trying to keep the kernel+modules coupled together so
> >> >> >> > that we avoid the PLT?
> >> >> >>
> >> >> >> First of all, note that it is unlikely that the PLTs are ever required
> >> >> >> in practice, considering that either
> >> >> >> a) the kernel is loaded at the default location right at the base of
> >> >> >> the vmalloc range, and in this case, the module space is reserved for
> >> >> >> modules only, or
> >> >> >> b) the kernel is loaded at some random offset in the 240+ GB vmalloc
> >> >> >> space, and it is unlikely that all VMA space around the kernel happens
> >> >> >> to be given out to non-randomized vmalloc/ioremap allocations
> >> >> >
> >> >> > My worry is that we merge some code that's rarely tested.
> >> >>
> >> >> I understand. But unfortunately, having corner cases that are unlikely
> >> >> but not impossible comes with the territory of randomization.
> >> >>
> >> >> Alternatively, we could take the performance hit if KASLR is in effect
> >> >> and allocate each module completely randomly as well. This way, the
> >> >> code is always exercised (for now), and we can always backpedal later
> >> >> if the performance is measurably worse.
> >> >
> >> > I'm fine with this. You can post it as a separate patch that we can
> >> > easily revert/modify later (like turning it into a config option).
> >>
> >> OK, I will hack something up
> >
> > If it's simpler, you can just add a config option but defaulting to the
> > full vmalloc space for modules.
> 
> What would be the simplest is to randomize the 128 MB module region as
> a whole, and either put it close to the kernel (which is what I am
> doing now), or put it at a random offset inside the vmalloc space, in
> which case all branches will be resolved via PLTs. My suggestion to
> randomize each module_alloc() call separately is actually not that
> straight-forward.
> 
> So what I propose now is to keep a single module_load_offset that
> randomizes the base of the region, and add a default-n config option
> that shrinks the interval it is chosen from so that PLTs are usually
> not needed.

Sounds fine.

-- 
Catalin


From fijam at archlinux.us  Fri Feb  5 09:21:58 2016
From: fijam at archlinux.us (JM)
Date: Fri, 5 Feb 2016 18:21:58 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <20160205172856.2923d938@bbrezillon>
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
 <20160205090246.GE32272@lunn.ch> <20160205112907.796afb05@bbrezillon>
 <CAKzmTe20fT8BcRaDaf2gz92KMAK0kEUkaD-kPq_cPF1WKBdroA@mail.gmail.com>
 <87vb632maf.fsf@free-electrons.com>
 <CAKzmTe1AqNQwjcsAULotd010NXuk1AYjj5p6UoqT_Zu=BCHdcw@mail.gmail.com>
 <20160205172856.2923d938@bbrezillon>
Message-ID: <CAKzmTe0wvwkyBAe6S6syRpK13pMDxpiUAK75xb-FW=YNFy3jRg@mail.gmail.com>

On Fri, Feb 5, 2016 at 5:28 PM, Boris Brezillon
<boris.brezillon at free-electrons.com> wrote:
> On Fri, 5 Feb 2016 17:01:45 +0100
> JM <fijam at archlinux.us> wrote:
>
>> On Fri, Feb 5, 2016 at 4:45 PM, Gregory CLEMENT
>> <gregory.clement at free-electrons.com> wrote:
>> > Hi JM,
>> >
>> >  On ven., f?vr. 05 2016, JM <fijam at archlinux.us> wrote:
>> >
>> >> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
>> >> <boris.brezillon at free-electrons.com> wrote:
>> >>> Jan, Andrew
>> >>>
>> >>> On Fri, 5 Feb 2016 10:02:46 +0100
>> >>> Andrew Lunn <andrew at lunn.ch> wrote:
>> >>>
>> >>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>> >>>> > Hi,
>> >>>> >
>> >>>> > I am testing marvell_cesa on a kirkwood device (QNAP TS-212p, Marvell
>> >>>> > Kirkwood 88F6282, dts: http://pastebin.com/Gk95KFHf ).
>> >>>> > As of kernel 4.4 (4.4.0-trunk-kirkwood #1 Debian 4.4-1~exp1) it fails
>> >>>> > in the following way:
>> >>>> >
>> >>>> > modprobe marvell_cesa allhwsupport=1
>> >>>> > dmesg | tail -n 1
>> >>>> > [ 1057.855091] marvell-cesa: probe of f1030000.crypto failed with error -12
>> >>>> >
>> >>>> > or:
>> >>>> >
>> >>>> > modprobe marvell_cesa
>> >>>> > dmesg | tail -n 1
>> >>>> > [ 9178.399357] marvell-cesa: probe of f1030000.crypto failed with error -524
>> >>>> >
>> >>>> > With kernel 4.3 it would fail with error -22 on that hardware. There
>> >>>> > are scattered reports from other users experiencing the same issue
>> >>>> > (1,2,3)
>> >>>> >
>> >>>> > I wonder if this is a result of an invalid definition of the
>> >>>> > crypto-sram in the dts of this SoC, or perhaps some other problem
>> >>>> > (PEBKAC included).
>> >>>>
>> >>>> Hi Jan
>> >>>>
>> >>>> Do you have SRAM enabled in your kernel configuration. The
>> >>>> mvebu_v5_defconfig does not have it, which is a bug really.
>> >>>
>> >>> Hm, the CRYPTO_DEV_MARVELL_CESA option selects the SRAM one [1].
>> >>> Anyway, I also think this error is related to the SRAM (not sure why the
>> >>> driver is not able to get the SRAM though).
>> >>>
>> >>> Best Regards,
>> >>>
>> >>> Boris
>> >>>
>> >>> [1]http://lxr.free-electrons.com/source/drivers/crypto/Kconfig#L168
>> >>>
>> >>>
>> >>> --
>> >>> Boris Brezillon, Free Electrons
>> >>> Embedded Linux and Kernel engineering
>> >>> http://free-electrons.com
>> >>
>> >> Hi,
>> >>
>> >> Thanks for getting back to me. Indeed, CONFIG_SRAM is enabled, I put
>> >> the complete .config here: http://pastebin.com/40eKMJqE
>> >>
>> >> If there is anything I can do to help squish this bug, please let me
>> >> know.
>> >
>> > How do you get your dts?
>> > it seems that you generated it from your dtb (or from /proc).
>> >
>> > I tried to do the same from arch/arm/boot/dts/kirkwood-ts219-6282.dtb,
>> > but the resulting dts is too different for an easy comparison.
>> >
>> > Could you also provide your dtb, maybe by using the same dtc with the
>> > option -s I will manage to get the something easier to compare.
>> >
>> > Gregory
>> >
>> >
>> >>
>> >> Best regards,
>> >> Jan
>> >>
>> >> _______________________________________________
>> >> linux-arm-kernel mailing list
>> >> linux-arm-kernel at lists.infradead.org
>> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> >
>> > --
>> > Gregory Clement, Free Electrons
>> > Kernel, drivers, real-time and embedded Linux
>> > development, consulting, training and support.
>> > http://free-electrons.com
>>
>> Hi,
>>
>> Yes, I simply used dtc -I fs /proc/device-tree to obtain the dts.
>>
>> Here is the relevant .dtb file : http://heap.ovh/files/kirkwood-ts219-6282.dtb
>
> Can you try to apply this patch [1], and let me know where it fails?
>
> [1]http://code.bulix.org/qnuq8m-90700
>
>
>
>
> --
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Hello again,

With the patch applied (I had to add struct device *dev = cesa->dev;
under static int mv_cesa_get_sram or I'd get error: ?dev? undeclared
during compilation, hope that's correct)
I am getting the following:

[53595.279886] marvell-cesa f1030000.crypto: failed get SRAM region
[53595.289485] marvell-cesa: probe of f1030000.crypto failed with error -12

Best regards,
Jan


From dietmar.eggemann at arm.com  Fri Feb  5 09:19:11 2016
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Fri, 5 Feb 2016 17:19:11 +0000
Subject: [PATCH v3 6/6] arm64: add sysfs cpu_capacity attribute
In-Reply-To: <1454500799-18451-7-git-send-email-juri.lelli@arm.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <1454500799-18451-7-git-send-email-juri.lelli@arm.com>
Message-ID: <56B4D98F.3090103@arm.com>

Hi Juri,

On 03/02/16 11:59, Juri Lelli wrote:
> Add a sysfs cpu_capacity attribute with which it is possible to read and
> write (thus over-writing default values) CPUs capacity. This might be
> useful in situation where there is no way to get proper default values
> at boot time.
> 
> The new attribute shows up as:
> 
>  /sys/devices/system/cpu/cpu*/cpu_capacity
> 
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Mark Brown <broonie at linaro.org>
> Cc: Sudeep Holla <sudeep.holla at arm.com>
> Signed-off-by: Juri Lelli <juri.lelli at arm.com>
> ---
>  arch/arm64/kernel/topology.c | 68 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 68 insertions(+)
> 
> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> index f2513a6..f05cc07 100644
> --- a/arch/arm64/kernel/topology.c
> +++ b/arch/arm64/kernel/topology.c
> @@ -40,6 +40,74 @@ bool arch_wants_init_cpu_capacity(void)
>  	return true;
>  }
>  
> +#ifdef CONFIG_PROC_SYSCTL
> +#include <asm/cpu.h>
> +#include <linux/string.h>
> +static ssize_t show_cpu_capacity(struct device *dev,
> +				 struct device_attribute *attr,
> +				 char *buf)
> +{
> +	struct cpu *cpu = container_of(dev, struct cpu, dev);
> +	ssize_t rc;
> +	int cpunum = cpu->dev.id;
> +	unsigned long capacity = arch_scale_cpu_capacity(NULL, cpunum);

Gives me an implicit declaration of function ?arch_scale_cpu_capacity?
error [without the commit fbc899610e1a ("arm64: Update
arch_scale_cpu_capacity() to reflect change to define") on your
git://linux-arm.org/linux-jl.git upstream/default_caps_v3 branch].

Why don't you just return cpu_scale

@@ -49,10 +49,8 @@ static ssize_t show_cpu_capacity(struct device *dev,
 {
        struct cpu *cpu = container_of(dev, struct cpu, dev);
        ssize_t rc;
-       int cpunum = cpu->dev.id;
-       unsigned long capacity = arch_scale_cpu_capacity(NULL, cpunum);

-       rc = sprintf(buf, "%lu\n", capacity);
+       rc = sprintf(buf, "%lu\n", per_cpu(cpu_scale, cpu->dev.id));

        return rc;
 }

to get rid of this dependency?

-- Dietmar

[...]


From catalin.marinas at arm.com  Fri Feb  5 09:32:48 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 5 Feb 2016 17:32:48 +0000
Subject: [PATCH v5sub2 0/8] arm64: implement virtual KASLR
In-Reply-To: <CAKv+Gu-AhLcatkDsQVeoFGJ+pTEwaW1Hy9M-fY1-VWvRc_E47w@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <CAKv+Gu-AhLcatkDsQVeoFGJ+pTEwaW1Hy9M-fY1-VWvRc_E47w@mail.gmail.com>
Message-ID: <20160205173248.GJ6076@e104818-lin.cambridge.arm.com>

On Mon, Feb 01, 2016 at 02:35:03PM +0100, Ard Biesheuvel wrote:
> On 1 February 2016 at 14:09, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> > At the request of Catalin, this series has been split off from my series
> > 'arm64: implement support for KASLR v4' [1]. This sub-series deals with
> > creating a relocatable binary, and randomizing the virtual placement of
> > the kernel itself, the modules and the linear region based on entropy
> > supplied by the bootloader in the /chosen/kaslr-seed DT property.
> >
> > Changes since v4:
> > - add randomization of the linear region, i.e., if the linear region is
> >   substantially larger than the space spanned by RAM, the mapping of RAM
> >   is moved to a random offset inside the linear region.
> > - dropped the CRC check in kaslr_early_init(), since the only code that may
> >   modify .data through __fixmap_remap_fdt() is instrumentation that should
> >   deal with that correctly (For instance, the branch profiling records taken
> >   branches in structs allocated in .data, and these counts will not be reset
> >   to 0 between the first and the second call to __mmap_switched())
> > - add Mark's ack to patch #4
> >
> 
> NOTE: I have omitted the relative kallsyms and relative extable
> patches, since they already queued in akpm's tree. However, while the
> kallsyms patch is merely an optimization, the extable patches are in
> fact required for correct operation, since the build time sorting does
> not work on absolute extables (this is due to the fact that the
> resolution of the relocations is deferred until runtime, and so the
> extable addresses are all zero at sorting time)
> 
> http://ozlabs.org/~akpm/mmotm/broken-out/extable-add-support-for-relative-extables-to-search-and-sort-routines.patch
> http://ozlabs.org/~akpm/mmotm/broken-out/arm64-switch-to-relative-exception-tables.patch

I'm still trying to get my head around how we merge those. Since I
assume akpm will push them during the merging window, part of your code
cannot be tested before.

Can we deselect CONFIG_BUILDTIME_EXTABLE_SORT temporarily while we use
absolute extable addresses? We patch them at boot-time and sort them
at run-time. Once the above patches go in, we can revert to build-time
extable sorting.

-- 
Catalin


From yamada.masahiro at socionext.com  Fri Feb  5 09:36:48 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Sat,  6 Feb 2016 02:36:48 +0900
Subject: [PATCH] ARM: drop unused Makefile.boot of Multiplatform SoCs
Message-ID: <1454693808-13081-1-git-send-email-yamada.masahiro@socionext.com>

The variable "MACHINE" is empty if CONFIG_ARCH_MULTIPLATFORM=y,
so these Makefile.boot files are never included.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/mach-cns3xxx/Makefile.boot    | 3 ---
 arch/arm/mach-exynos/Makefile.boot     | 2 --
 arch/arm/mach-integrator/Makefile.boot | 4 ----
 arch/arm/mach-keystone/Makefile.boot   | 1 -
 arch/arm/mach-mmp/Makefile.boot        | 1 -
 arch/arm/mach-mv78xx0/Makefile.boot    | 3 ---
 arch/arm/mach-nspire/Makefile.boot     | 0
 arch/arm/mach-omap2/Makefile.boot      | 3 ---
 arch/arm/mach-orion5x/Makefile.boot    | 3 ---
 arch/arm/mach-prima2/Makefile.boot     | 3 ---
 arch/arm/mach-realview/Makefile.boot   | 9 ---------
 arch/arm/mach-s3c64xx/Makefile.boot    | 2 --
 arch/arm/mach-spear/Makefile.boot      | 3 ---
 arch/arm/mach-u300/Makefile.boot       | 4 ----
 arch/arm/mach-ux500/Makefile.boot      | 3 ---
 arch/arm/mach-zynq/Makefile.boot       | 3 ---
 16 files changed, 47 deletions(-)
 delete mode 100644 arch/arm/mach-cns3xxx/Makefile.boot
 delete mode 100644 arch/arm/mach-exynos/Makefile.boot
 delete mode 100644 arch/arm/mach-integrator/Makefile.boot
 delete mode 100644 arch/arm/mach-keystone/Makefile.boot
 delete mode 100644 arch/arm/mach-mmp/Makefile.boot
 delete mode 100644 arch/arm/mach-mv78xx0/Makefile.boot
 delete mode 100644 arch/arm/mach-nspire/Makefile.boot
 delete mode 100644 arch/arm/mach-omap2/Makefile.boot
 delete mode 100644 arch/arm/mach-orion5x/Makefile.boot
 delete mode 100644 arch/arm/mach-prima2/Makefile.boot
 delete mode 100644 arch/arm/mach-realview/Makefile.boot
 delete mode 100644 arch/arm/mach-s3c64xx/Makefile.boot
 delete mode 100644 arch/arm/mach-spear/Makefile.boot
 delete mode 100644 arch/arm/mach-u300/Makefile.boot
 delete mode 100644 arch/arm/mach-ux500/Makefile.boot
 delete mode 100644 arch/arm/mach-zynq/Makefile.boot

diff --git a/arch/arm/mach-cns3xxx/Makefile.boot b/arch/arm/mach-cns3xxx/Makefile.boot
deleted file mode 100644
index d079de0..0000000
--- a/arch/arm/mach-cns3xxx/Makefile.boot
+++ /dev/null
@@ -1,3 +0,0 @@
-   zreladdr-y	+= 0x00008000
-params_phys-y	:= 0x00000100
-initrd_phys-y	:= 0x00C00000
diff --git a/arch/arm/mach-exynos/Makefile.boot b/arch/arm/mach-exynos/Makefile.boot
deleted file mode 100644
index b9862e2..0000000
--- a/arch/arm/mach-exynos/Makefile.boot
+++ /dev/null
@@ -1,2 +0,0 @@
-   zreladdr-y	+= 0x40008000
-params_phys-y	:= 0x40000100
diff --git a/arch/arm/mach-integrator/Makefile.boot b/arch/arm/mach-integrator/Makefile.boot
deleted file mode 100644
index ff0a4b5..0000000
--- a/arch/arm/mach-integrator/Makefile.boot
+++ /dev/null
@@ -1,4 +0,0 @@
-   zreladdr-y	+= 0x00008000
-params_phys-y	:= 0x00000100
-initrd_phys-y	:= 0x00800000
-
diff --git a/arch/arm/mach-keystone/Makefile.boot b/arch/arm/mach-keystone/Makefile.boot
deleted file mode 100644
index f3835c4..0000000
--- a/arch/arm/mach-keystone/Makefile.boot
+++ /dev/null
@@ -1 +0,0 @@
-zreladdr-y	:= 0x80008000
diff --git a/arch/arm/mach-mmp/Makefile.boot b/arch/arm/mach-mmp/Makefile.boot
deleted file mode 100644
index 5edf03e..0000000
--- a/arch/arm/mach-mmp/Makefile.boot
+++ /dev/null
@@ -1 +0,0 @@
-   zreladdr-y	+= 0x00008000
diff --git a/arch/arm/mach-mv78xx0/Makefile.boot b/arch/arm/mach-mv78xx0/Makefile.boot
deleted file mode 100644
index 760a0ef..0000000
--- a/arch/arm/mach-mv78xx0/Makefile.boot
+++ /dev/null
@@ -1,3 +0,0 @@
-   zreladdr-y	+= 0x00008000
-params_phys-y	:= 0x00000100
-initrd_phys-y	:= 0x00800000
diff --git a/arch/arm/mach-nspire/Makefile.boot b/arch/arm/mach-nspire/Makefile.boot
deleted file mode 100644
index e69de29..0000000
diff --git a/arch/arm/mach-omap2/Makefile.boot b/arch/arm/mach-omap2/Makefile.boot
deleted file mode 100644
index b03e562..0000000
--- a/arch/arm/mach-omap2/Makefile.boot
+++ /dev/null
@@ -1,3 +0,0 @@
-  zreladdr-y		+= 0x80008000
-params_phys-y		:= 0x80000100
-initrd_phys-y		:= 0x80800000
diff --git a/arch/arm/mach-orion5x/Makefile.boot b/arch/arm/mach-orion5x/Makefile.boot
deleted file mode 100644
index 760a0ef..0000000
--- a/arch/arm/mach-orion5x/Makefile.boot
+++ /dev/null
@@ -1,3 +0,0 @@
-   zreladdr-y	+= 0x00008000
-params_phys-y	:= 0x00000100
-initrd_phys-y	:= 0x00800000
diff --git a/arch/arm/mach-prima2/Makefile.boot b/arch/arm/mach-prima2/Makefile.boot
deleted file mode 100644
index c77a488..0000000
--- a/arch/arm/mach-prima2/Makefile.boot
+++ /dev/null
@@ -1,3 +0,0 @@
-zreladdr-y		+= 0x00008000
-params_phys-y		:= 0x00000100
-initrd_phys-y		:= 0x00800000
diff --git a/arch/arm/mach-realview/Makefile.boot b/arch/arm/mach-realview/Makefile.boot
deleted file mode 100644
index d2c3d78..0000000
--- a/arch/arm/mach-realview/Makefile.boot
+++ /dev/null
@@ -1,9 +0,0 @@
-ifeq ($(CONFIG_REALVIEW_HIGH_PHYS_OFFSET),y)
-   zreladdr-y	+= 0x70008000
-params_phys-y	:= 0x70000100
-initrd_phys-y	:= 0x70800000
-else
-   zreladdr-y	+= 0x00008000
-params_phys-y	:= 0x00000100
-initrd_phys-y	:= 0x00800000
-endif
diff --git a/arch/arm/mach-s3c64xx/Makefile.boot b/arch/arm/mach-s3c64xx/Makefile.boot
deleted file mode 100644
index c642333..0000000
--- a/arch/arm/mach-s3c64xx/Makefile.boot
+++ /dev/null
@@ -1,2 +0,0 @@
-   zreladdr-y	+= 0x50008000
-params_phys-y	:= 0x50000100
diff --git a/arch/arm/mach-spear/Makefile.boot b/arch/arm/mach-spear/Makefile.boot
deleted file mode 100644
index 4674a4c..0000000
--- a/arch/arm/mach-spear/Makefile.boot
+++ /dev/null
@@ -1,3 +0,0 @@
-zreladdr-y	+= 0x00008000
-params_phys-y	:= 0x00000100
-initrd_phys-y	:= 0x00800000
diff --git a/arch/arm/mach-u300/Makefile.boot b/arch/arm/mach-u300/Makefile.boot
deleted file mode 100644
index 87811de..0000000
--- a/arch/arm/mach-u300/Makefile.boot
+++ /dev/null
@@ -1,4 +0,0 @@
-   zreladdr-y	+= 0x48008000
-params_phys-y	:= 0x48000100
-# This isn't used.
-#initrd_phys-y	:= 0x48800000
diff --git a/arch/arm/mach-ux500/Makefile.boot b/arch/arm/mach-ux500/Makefile.boot
deleted file mode 100644
index 760a0ef..0000000
--- a/arch/arm/mach-ux500/Makefile.boot
+++ /dev/null
@@ -1,3 +0,0 @@
-   zreladdr-y	+= 0x00008000
-params_phys-y	:= 0x00000100
-initrd_phys-y	:= 0x00800000
diff --git a/arch/arm/mach-zynq/Makefile.boot b/arch/arm/mach-zynq/Makefile.boot
deleted file mode 100644
index 760a0ef..0000000
--- a/arch/arm/mach-zynq/Makefile.boot
+++ /dev/null
@@ -1,3 +0,0 @@
-   zreladdr-y	+= 0x00008000
-params_phys-y	:= 0x00000100
-initrd_phys-y	:= 0x00800000
-- 
1.9.1



From ard.biesheuvel at linaro.org  Fri Feb  5 09:38:33 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 5 Feb 2016 18:38:33 +0100
Subject: [PATCH v5sub2 0/8] arm64: implement virtual KASLR
In-Reply-To: <20160205173248.GJ6076@e104818-lin.cambridge.arm.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <CAKv+Gu-AhLcatkDsQVeoFGJ+pTEwaW1Hy9M-fY1-VWvRc_E47w@mail.gmail.com>
 <20160205173248.GJ6076@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu_v1sXM7sivz+Uu86ZG3=Th7wqqh7M1N8wF7Ess4NdTZQ@mail.gmail.com>

On 5 February 2016 at 18:32, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 01, 2016 at 02:35:03PM +0100, Ard Biesheuvel wrote:
>> On 1 February 2016 at 14:09, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>> > At the request of Catalin, this series has been split off from my series
>> > 'arm64: implement support for KASLR v4' [1]. This sub-series deals with
>> > creating a relocatable binary, and randomizing the virtual placement of
>> > the kernel itself, the modules and the linear region based on entropy
>> > supplied by the bootloader in the /chosen/kaslr-seed DT property.
>> >
>> > Changes since v4:
>> > - add randomization of the linear region, i.e., if the linear region is
>> >   substantially larger than the space spanned by RAM, the mapping of RAM
>> >   is moved to a random offset inside the linear region.
>> > - dropped the CRC check in kaslr_early_init(), since the only code that may
>> >   modify .data through __fixmap_remap_fdt() is instrumentation that should
>> >   deal with that correctly (For instance, the branch profiling records taken
>> >   branches in structs allocated in .data, and these counts will not be reset
>> >   to 0 between the first and the second call to __mmap_switched())
>> > - add Mark's ack to patch #4
>> >
>>
>> NOTE: I have omitted the relative kallsyms and relative extable
>> patches, since they already queued in akpm's tree. However, while the
>> kallsyms patch is merely an optimization, the extable patches are in
>> fact required for correct operation, since the build time sorting does
>> not work on absolute extables (this is due to the fact that the
>> resolution of the relocations is deferred until runtime, and so the
>> extable addresses are all zero at sorting time)
>>
>> http://ozlabs.org/~akpm/mmotm/broken-out/extable-add-support-for-relative-extables-to-search-and-sort-routines.patch
>> http://ozlabs.org/~akpm/mmotm/broken-out/arm64-switch-to-relative-exception-tables.patch
>
> I'm still trying to get my head around how we merge those. Since I
> assume akpm will push them during the merging window, part of your code
> cannot be tested before.
>

Actually, my original idea was for akpm to take them as a late merge
after rebasing to -rc1, since they touch a variety of architectures,
but I am not sure if that came across.

You could always take the series through your tree instead, I guess?

> Can we deselect CONFIG_BUILDTIME_EXTABLE_SORT temporarily while we use
> absolute extable addresses? We patch them at boot-time and sort them
> at run-time. Once the above patches go in, we can revert to build-time
> extable sorting.
>

I suppose that would be possible, but I simply haven't tried. I
noticed that ppc does not use build time extable sorting, that is why
they don't need to scripts/extable patch while they do use PIE
binaries.


From yamada.masahiro at socionext.com  Fri Feb  5 09:38:40 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Sat,  6 Feb 2016 02:38:40 +0900
Subject: [PATCH] ARM: integrator: remove redundant select in Kconfig
Message-ID: <1454693920-14794-1-git-send-email-yamada.masahiro@socionext.com>

All of these are already select'ed by ARCH_MULTIPLATFORM.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/mach-integrator/Kconfig | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/arch/arm/mach-integrator/Kconfig b/arch/arm/mach-integrator/Kconfig
index b01bdc9..b2a85ba 100644
--- a/arch/arm/mach-integrator/Kconfig
+++ b/arch/arm/mach-integrator/Kconfig
@@ -2,22 +2,16 @@ menuconfig ARCH_INTEGRATOR
 	bool "ARM Ltd. Integrator family"
 	depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V6
 	select ARM_AMBA
-	select ARM_PATCH_PHYS_VIRT if MMU
-	select AUTO_ZRELADDR
-	select COMMON_CLK
 	select COMMON_CLK_VERSATILE
-	select GENERIC_CLOCKEVENTS
 	select HAVE_TCM
 	select ICST
 	select MFD_SYSCON
-	select MULTI_IRQ_HANDLER
 	select PLAT_VERSATILE
 	select POWER_RESET
 	select POWER_RESET_VERSATILE
 	select POWER_SUPPLY
 	select SOC_INTEGRATOR_CM
 	select SPARSE_IRQ
-	select USE_OF
 	select VERSATILE_FPGA_IRQ
 	help
 	  Support for ARM's Integrator platform.
-- 
1.9.1



From yamada.masahiro at socionext.com  Fri Feb  5 09:40:41 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Sat,  6 Feb 2016 02:40:41 +0900
Subject: [PATCH] ARM: keystone: remove redundant depends on ARM_PATCH_PHYS_VIRT
Message-ID: <1454694041-14990-1-git-send-email-yamada.masahiro@socionext.com>

KeyStone is Multi-platform.  ARM_PATCH_PHYS_VIRT is already select'ed
by ARCH_MULTIPLATFORM.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/mach-keystone/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index ea955f6db..75bcb7f 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -1,7 +1,6 @@
 config ARCH_KEYSTONE
 	bool "Texas Instruments Keystone Devices"
 	depends on ARCH_MULTI_V7
-	depends on ARM_PATCH_PHYS_VIRT
 	select ARM_GIC
 	select HAVE_ARM_ARCH_TIMER
 	select CLKSRC_MMIO
-- 
1.9.1



From yamada.masahiro at socionext.com  Fri Feb  5 09:43:17 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Sat,  6 Feb 2016 02:43:17 +0900
Subject: [PATCH] ARM: netx: remove redundant "depends on ARCH_NETX"
Message-ID: <1454694197-15200-1-git-send-email-yamada.masahiro@socionext.com>

These options already reside inside the ARCH_NETX-dependent menu.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/mach-netx/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-netx/Kconfig b/arch/arm/mach-netx/Kconfig
index 3d90ef1..2da8e5d 100644
--- a/arch/arm/mach-netx/Kconfig
+++ b/arch/arm/mach-netx/Kconfig
@@ -3,20 +3,17 @@ menu "NetX Implementations"
 
 config MACH_NXDKN
 	bool "Enable Hilscher nxdkn Eval Board support"
-	depends on ARCH_NETX
 	help
 	  Board support for the Hilscher NetX Eval Board
 
 config MACH_NXDB500
 	bool "Enable Hilscher nxdb500 Eval Board support"
-	depends on ARCH_NETX
 	select ARM_AMBA
 	help
 	  Board support for the Hilscher nxdb500 Eval Board
 
 config MACH_NXEB500HMI
 	bool "Enable Hilscher nxeb500hmi Eval Board support"
-	depends on ARCH_NETX
 	select ARM_AMBA
 	help
 	  Board support for the Hilscher nxeb500hmi Eval Board
-- 
1.9.1



From catalin.marinas at arm.com  Fri Feb  5 09:46:49 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 5 Feb 2016 17:46:49 +0000
Subject: [PATCH v5sub2 0/8] arm64: implement virtual KASLR
In-Reply-To: <CAKv+Gu_v1sXM7sivz+Uu86ZG3=Th7wqqh7M1N8wF7Ess4NdTZQ@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <CAKv+Gu-AhLcatkDsQVeoFGJ+pTEwaW1Hy9M-fY1-VWvRc_E47w@mail.gmail.com>
 <20160205173248.GJ6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_v1sXM7sivz+Uu86ZG3=Th7wqqh7M1N8wF7Ess4NdTZQ@mail.gmail.com>
Message-ID: <20160205174649.GK6076@e104818-lin.cambridge.arm.com>

On Fri, Feb 05, 2016 at 06:38:33PM +0100, Ard Biesheuvel wrote:
> On 5 February 2016 at 18:32, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Mon, Feb 01, 2016 at 02:35:03PM +0100, Ard Biesheuvel wrote:
> >> On 1 February 2016 at 14:09, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> >> > At the request of Catalin, this series has been split off from my series
> >> > 'arm64: implement support for KASLR v4' [1]. This sub-series deals with
> >> > creating a relocatable binary, and randomizing the virtual placement of
> >> > the kernel itself, the modules and the linear region based on entropy
> >> > supplied by the bootloader in the /chosen/kaslr-seed DT property.
> >> >
> >> > Changes since v4:
> >> > - add randomization of the linear region, i.e., if the linear region is
> >> >   substantially larger than the space spanned by RAM, the mapping of RAM
> >> >   is moved to a random offset inside the linear region.
> >> > - dropped the CRC check in kaslr_early_init(), since the only code that may
> >> >   modify .data through __fixmap_remap_fdt() is instrumentation that should
> >> >   deal with that correctly (For instance, the branch profiling records taken
> >> >   branches in structs allocated in .data, and these counts will not be reset
> >> >   to 0 between the first and the second call to __mmap_switched())
> >> > - add Mark's ack to patch #4
> >> >
> >>
> >> NOTE: I have omitted the relative kallsyms and relative extable
> >> patches, since they already queued in akpm's tree. However, while the
> >> kallsyms patch is merely an optimization, the extable patches are in
> >> fact required for correct operation, since the build time sorting does
> >> not work on absolute extables (this is due to the fact that the
> >> resolution of the relocations is deferred until runtime, and so the
> >> extable addresses are all zero at sorting time)
> >>
> >> http://ozlabs.org/~akpm/mmotm/broken-out/extable-add-support-for-relative-extables-to-search-and-sort-routines.patch
> >> http://ozlabs.org/~akpm/mmotm/broken-out/arm64-switch-to-relative-exception-tables.patch
> >
> > I'm still trying to get my head around how we merge those. Since I
> > assume akpm will push them during the merging window, part of your code
> > cannot be tested before.
> 
> Actually, my original idea was for akpm to take them as a late merge
> after rebasing to -rc1, since they touch a variety of architectures,
> but I am not sure if that came across.
> 
> You could always take the series through your tree instead, I guess?

They all have acks from maintainers, so that's an option.

> > Can we deselect CONFIG_BUILDTIME_EXTABLE_SORT temporarily while we use
> > absolute extable addresses? We patch them at boot-time and sort them
> > at run-time. Once the above patches go in, we can revert to build-time
> > extable sorting.
> 
> I suppose that would be possible, but I simply haven't tried. I
> noticed that ppc does not use build time extable sorting, that is why
> they don't need to scripts/extable patch while they do use PIE
> binaries.

I did a quick check with:

--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -22,7 +22,7 @@ config ARM64
 	select ARM_GIC_V3
 	select ARM_GIC_V3_ITS if PCI_MSI
 	select ARM_PSCI_FW
-	select BUILDTIME_EXTABLE_SORT
+	select BUILDTIME_EXTABLE_SORT if !RELOCATABLE
 	select CLONE_BACKWARDS
 	select COMMON_CLK
 	select CPU_PM if (SUSPEND || CPU_IDLE)

and it seems that extable entries end up in the relocation symbols but I
haven't fully checked the patching/sorting yet (it will probably be on
Monday).

-- 
Catalin


From juri.lelli at arm.com  Fri Feb  5 09:49:44 2016
From: juri.lelli at arm.com (Juri Lelli)
Date: Fri, 5 Feb 2016 17:49:44 +0000
Subject: [PATCH v3 6/6] arm64: add sysfs cpu_capacity attribute
In-Reply-To: <56B4D98F.3090103@arm.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <1454500799-18451-7-git-send-email-juri.lelli@arm.com>
 <56B4D98F.3090103@arm.com>
Message-ID: <20160205174944.GG11415@e106622-lin>

Hi,

On 05/02/16 17:19, Dietmar Eggemann wrote:
> Hi Juri,
> 
> On 03/02/16 11:59, Juri Lelli wrote:
> > Add a sysfs cpu_capacity attribute with which it is possible to read and
> > write (thus over-writing default values) CPUs capacity. This might be
> > useful in situation where there is no way to get proper default values
> > at boot time.
> > 
> > The new attribute shows up as:
> > 
> >  /sys/devices/system/cpu/cpu*/cpu_capacity
> > 
> > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > Cc: Will Deacon <will.deacon at arm.com>
> > Cc: Mark Brown <broonie at linaro.org>
> > Cc: Sudeep Holla <sudeep.holla at arm.com>
> > Signed-off-by: Juri Lelli <juri.lelli at arm.com>
> > ---
> >  arch/arm64/kernel/topology.c | 68 ++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 68 insertions(+)
> > 
> > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> > index f2513a6..f05cc07 100644
> > --- a/arch/arm64/kernel/topology.c
> > +++ b/arch/arm64/kernel/topology.c
> > @@ -40,6 +40,74 @@ bool arch_wants_init_cpu_capacity(void)
> >  	return true;
> >  }
> >  
> > +#ifdef CONFIG_PROC_SYSCTL
> > +#include <asm/cpu.h>
> > +#include <linux/string.h>
> > +static ssize_t show_cpu_capacity(struct device *dev,
> > +				 struct device_attribute *attr,
> > +				 char *buf)
> > +{
> > +	struct cpu *cpu = container_of(dev, struct cpu, dev);
> > +	ssize_t rc;
> > +	int cpunum = cpu->dev.id;
> > +	unsigned long capacity = arch_scale_cpu_capacity(NULL, cpunum);
> 
> Gives me an implicit declaration of function ?arch_scale_cpu_capacity?
> error [without the commit fbc899610e1a ("arm64: Update
> arch_scale_cpu_capacity() to reflect change to define") on your
> git://linux-arm.org/linux-jl.git upstream/default_caps_v3 branch].
> 
> Why don't you just return cpu_scale
> 
> @@ -49,10 +49,8 @@ static ssize_t show_cpu_capacity(struct device *dev,
>  {
>         struct cpu *cpu = container_of(dev, struct cpu, dev);
>         ssize_t rc;
> -       int cpunum = cpu->dev.id;
> -       unsigned long capacity = arch_scale_cpu_capacity(NULL, cpunum);
> 
> -       rc = sprintf(buf, "%lu\n", capacity);
> +       rc = sprintf(buf, "%lu\n", per_cpu(cpu_scale, cpu->dev.id));
> 
>         return rc;
>  }
> 
> to get rid of this dependency?
> 

Right! I'll fix this in the next version.

Thanks,

- Juri


From apinski at caviumnetworks.com  Fri Feb  5 09:53:48 2016
From: apinski at caviumnetworks.com (Andrew Pinski)
Date: Fri, 5 Feb 2016 09:53:48 -0800
Subject: [PATCH 0/4] copy_page improvements
In-Reply-To: <1454417186-21828-1-git-send-email-will.deacon@arm.com>
References: <1454417186-21828-1-git-send-email-will.deacon@arm.com>
Message-ID: <56B4E1AC.6030301@caviumnetworks.com>

On 2/2/2016 4:46 AM, Will Deacon wrote:
> Hi all,
>
> This patch series aims to improve our copy_page implementation on both
> CPUs with and without hardware prefetchers. It is inspired by a previous
> patch series from Andrew, and one of the patches is lifted directly from
> there:
>
>    http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399132.html
>
> Changes from that series:
>
>    * Applies on top of mainline
>    * Inverted the capability to the more generic ARM64_HAS_NO_HW_PREFETCH
>    * Re-jigged the MIDR detection to try to keep it simple
>
> I've left copy_template alone for now, since the template really deals
> with 64 bytes per iteration, which would need changing.

Right, I had looked at doing that also for newlib/glibc but the code is 
too complex.
>
> Andrew -- it would be helpful if you could take this for a spin on
> ThunderX to make sure it didn't screw anything up.

Yes it works and I get the needed prefetch in copy_page.

Tested-by: Andrew Pinski  <apinski at cavium.com>

Thanks,
Andrew

>
> Cheers,
>
> Will
>
> --->8
>
> Andrew Pinski (1):
>    arm64: lib: patch in prfm for copy_page if requested
>
> Will Deacon (3):
>    arm64: prefetch: don't provide spin_lock_prefetch with LSE
>    arm64: prefetch: add alternative pattern for CPUs without a prefetcher
>    arm64: lib: improve copy_page to deal with 128 bytes at a time
>
>   arch/arm64/include/asm/cpufeature.h |  3 +-
>   arch/arm64/include/asm/cputype.h    | 17 +++++++++-
>   arch/arm64/include/asm/processor.h  |  7 +++--
>   arch/arm64/kernel/cpu_errata.c      | 18 ++---------
>   arch/arm64/kernel/cpufeature.c      | 17 ++++++++++
>   arch/arm64/lib/copy_page.S          | 63 ++++++++++++++++++++++++++++++++-----
>   6 files changed, 98 insertions(+), 27 deletions(-)
>



From santosh.shilimkar at oracle.com  Fri Feb  5 09:56:39 2016
From: santosh.shilimkar at oracle.com (santosh shilimkar)
Date: Fri, 5 Feb 2016 09:56:39 -0800
Subject: [PATCH] ARM: keystone: remove redundant depends on
 ARM_PATCH_PHYS_VIRT
In-Reply-To: <1454694041-14990-1-git-send-email-yamada.masahiro@socionext.com>
References: <1454694041-14990-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <56B4E257.5050308@oracle.com>

On 2/5/2016 9:40 AM, Masahiro Yamada wrote:
> KeyStone is Multi-platform.  ARM_PATCH_PHYS_VIRT is already select'ed
> by ARCH_MULTIPLATFORM.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
> ---
>
There is also Keystone config so its nit redundant as you think.

P.S: arch/arm/configs/keystone_defconfig

Regards,
Santosh


From michal.simek at xilinx.com  Fri Feb  5 09:58:08 2016
From: michal.simek at xilinx.com (Michal Simek)
Date: Fri, 5 Feb 2016 18:58:08 +0100
Subject: [PATCH] ARM: drop unused Makefile.boot of Multiplatform SoCs
In-Reply-To: <1454693808-13081-1-git-send-email-yamada.masahiro@socionext.com>
References: <1454693808-13081-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <56B4E2B0.8060808@xilinx.com>

On 5.2.2016 18:36, Masahiro Yamada wrote:
> The variable "MACHINE" is empty if CONFIG_ARCH_MULTIPLATFORM=y,
> so these Makefile.boot files are never included.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
> ---
> 
>  arch/arm/mach-cns3xxx/Makefile.boot    | 3 ---
>  arch/arm/mach-exynos/Makefile.boot     | 2 --
>  arch/arm/mach-integrator/Makefile.boot | 4 ----
>  arch/arm/mach-keystone/Makefile.boot   | 1 -
>  arch/arm/mach-mmp/Makefile.boot        | 1 -
>  arch/arm/mach-mv78xx0/Makefile.boot    | 3 ---
>  arch/arm/mach-nspire/Makefile.boot     | 0
>  arch/arm/mach-omap2/Makefile.boot      | 3 ---
>  arch/arm/mach-orion5x/Makefile.boot    | 3 ---
>  arch/arm/mach-prima2/Makefile.boot     | 3 ---
>  arch/arm/mach-realview/Makefile.boot   | 9 ---------
>  arch/arm/mach-s3c64xx/Makefile.boot    | 2 --
>  arch/arm/mach-spear/Makefile.boot      | 3 ---
>  arch/arm/mach-u300/Makefile.boot       | 4 ----
>  arch/arm/mach-ux500/Makefile.boot      | 3 ---
>  arch/arm/mach-zynq/Makefile.boot       | 3 ---

Acked-by: Michal Simek <michal.simek at xilinx.com> (for Zynq)

Thanks,
Michal




From andre.przywara at arm.com  Fri Feb  5 09:59:23 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Fri, 5 Feb 2016 17:59:23 +0000
Subject: [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused
In-Reply-To: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <56B4E2FB.3050703@arm.com>

Hi Maxime,

just found this while looking at your current git branch, so sorry for
the late reply.

CC:ing DT people, since you touch both existing DTs(!) and the binding doc.

On 01/02/16 20:20, Maxime Ripard wrote:
> Remove the fixed dividers from the PLL6 driver to be able to have a
> reusable driver that can be used across several SoCs that share the same
> controller, but don't have the same set of dividers for this clock, and to
> also be reused multiple times in the same SoC, since we're droping the
> clock name.
> 
> Acked-by: Chen-Yu Tsai <wens at csie.org>
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> ---
> 
> Changes from v3:
>   - Fixed the documentation
>   - Added pll6d2 back
> 
> Changes from v2:
>   - Rebased and converted over to the new factors refactoring. Fixed the
>     retrieved rate
> 
>  Documentation/devicetree/bindings/clock/sunxi.txt |  2 +-
>  arch/arm/boot/dts/sun6i-a31.dtsi                  | 36 +++++++++++-----------
>  arch/arm/boot/dts/sun8i-a23-a33.dtsi              | 25 ++++++++++-----
>  arch/arm/boot/dts/sun8i-a23.dtsi                  |  2 +-
>  arch/arm/boot/dts/sun8i-a33.dtsi                  |  4 +--
>  arch/arm/boot/dts/sun8i-h3.dtsi                   | 37 ++++++++++++++---------

So are you really breaking all those systems by changing the DT and the
driver in an incompatible way?
Please correct me if this assessment is wrong, but to me it looks like
any user out there is either stuck with 4.5 at best _or_ will only be
able to run 4.6 and later (depending on which version of the DT she is
using)? And no, switching DTs along with the kernel is _not_ an option.
That is not how I understand DT.
Also this totally ignores any other DT user (U-Boot, FreeBSD, you name it).

I actually appreciate this rework, it's more flexible now and looks
better, but you really can't do this in a way to breaks compatibility
with existing DTs.

Jean-Francois came up with another solution for the pll8 clock [1], so
could this be considered at least?
I think changing the H3 PLL8 clock from dummy to something real is a
different story in terms of compatibility (since it never really worked
before and this wouldn't change for any old-DT user).

Cheers,
Andre.

[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/405104.html

>  drivers/clk/sunxi/clk-sunxi.c                     | 32 ++++++++++----------
>  7 files changed, 78 insertions(+), 60 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index e59f57b24777..f82850c0f6a5 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -86,7 +86,7 @@ Required properties for all clocks:
>  - #clock-cells : from common clock binding; shall be set to 0 except for
>  	the following compatibles where it shall be set to 1:
>  	"allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk",
> -	"allwinner,sun4i-pll6-clk", "allwinner,sun6i-a31-pll6-clk",
> +	"allwinner,sun4i-pll6-clk",
>  	"allwinner,*-usb-clk", "allwinner,*-mmc-clk",
>  	"allwinner,*-mmc-config-clk"
>  - clock-output-names : shall be the corresponding names of the outputs.
> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
> index b6ad7850fac6..05fe3d1aa328 100644
> --- a/arch/arm/boot/dts/sun6i-a31.dtsi
> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
> @@ -65,7 +65,7 @@
>  			compatible = "allwinner,simple-framebuffer",
>  				     "simple-framebuffer";
>  			allwinner,pipeline = "de_be0-lcd0-hdmi";
> -			clocks = <&pll6 0>;
> +			clocks = <&pll6>;
>  			status = "disabled";
>  		};
>  
> @@ -73,7 +73,7 @@
>  			compatible = "allwinner,simple-framebuffer",
>  				     "simple-framebuffer";
>  			allwinner,pipeline = "de_be0-lcd0";
> -			clocks = <&pll6 0>;
> +			clocks = <&pll6>;
>  			status = "disabled";
>  		};
>  	};
> @@ -201,11 +201,11 @@
>  		};
>  
>  		pll6: clk at 01c20028 {
> -			#clock-cells = <1>;
> +			#clock-cells = <0>;
>  			compatible = "allwinner,sun6i-a31-pll6-clk";
>  			reg = <0x01c20028 0x4>;
>  			clocks = <&osc24M>;
> -			clock-output-names = "pll6", "pll6x2";
> +			clock-output-names = "pll6";
>  		};
>  
>  		cpu: cpu at 01c20050 {
> @@ -235,7 +235,7 @@
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun6i-a31-ahb1-clk";
>  			reg = <0x01c20054 0x4>;
> -			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
> +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
>  			clock-output-names = "ahb1";
>  
>  			/*
> @@ -244,7 +244,7 @@
>  			 * controller requires AHB1 clocked from PLL6.
>  			 */
>  			assigned-clocks = <&ahb1>;
> -			assigned-clock-parents = <&pll6 0>;
> +			assigned-clock-parents = <&pll6>;
>  		};
>  
>  		ahb1_gates: clk at 01c20060 {
> @@ -307,7 +307,7 @@
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun4i-a10-apb1-clk";
>  			reg = <0x01c20058 0x4>;
> -			clocks = <&osc32k>, <&osc24M>, <&pll6 0>, <&pll6 0>;
> +			clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
>  			clock-output-names = "apb2";
>  		};
>  
> @@ -331,7 +331,7 @@
>  			#clock-cells = <1>;
>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>  			reg = <0x01c20088 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>;
> +			clocks = <&osc24M>, <&pll6>;
>  			clock-output-names = "mmc0",
>  					     "mmc0_output",
>  					     "mmc0_sample";
> @@ -341,7 +341,7 @@
>  			#clock-cells = <1>;
>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>  			reg = <0x01c2008c 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>;
> +			clocks = <&osc24M>, <&pll6>;
>  			clock-output-names = "mmc1",
>  					     "mmc1_output",
>  					     "mmc1_sample";
> @@ -351,7 +351,7 @@
>  			#clock-cells = <1>;
>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>  			reg = <0x01c20090 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>;
> +			clocks = <&osc24M>, <&pll6>;
>  			clock-output-names = "mmc2",
>  					     "mmc2_output",
>  					     "mmc2_sample";
> @@ -361,7 +361,7 @@
>  			#clock-cells = <1>;
>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>  			reg = <0x01c20094 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>;
> +			clocks = <&osc24M>, <&pll6>;
>  			clock-output-names = "mmc3",
>  					     "mmc3_output",
>  					     "mmc3_sample";
> @@ -371,7 +371,7 @@
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun4i-a10-mod0-clk";
>  			reg = <0x01c2009c 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>;
> +			clocks = <&osc24M>, <&pll6>;
>  			clock-output-names = "ss";
>  		};
>  
> @@ -379,7 +379,7 @@
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun4i-a10-mod0-clk";
>  			reg = <0x01c200a0 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>;
> +			clocks = <&osc24M>, <&pll6>;
>  			clock-output-names = "spi0";
>  		};
>  
> @@ -387,7 +387,7 @@
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun4i-a10-mod0-clk";
>  			reg = <0x01c200a4 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>;
> +			clocks = <&osc24M>, <&pll6>;
>  			clock-output-names = "spi1";
>  		};
>  
> @@ -395,7 +395,7 @@
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun4i-a10-mod0-clk";
>  			reg = <0x01c200a8 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>;
> +			clocks = <&osc24M>, <&pll6>;
>  			clock-output-names = "spi2";
>  		};
>  
> @@ -403,7 +403,7 @@
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun4i-a10-mod0-clk";
>  			reg = <0x01c200ac 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>;
> +			clocks = <&osc24M>, <&pll6>;
>  			clock-output-names = "spi3";
>  		};
>  
> @@ -1042,8 +1042,8 @@
>  			ar100: ar100_clk {
>  				compatible = "allwinner,sun6i-a31-ar100-clk";
>  				#clock-cells = <0>;
> -				clocks = <&osc32k>, <&osc24M>, <&pll6 0>,
> -					 <&pll6 0>;
> +				clocks = <&osc32k>, <&osc24M>, <&pll6>,
> +					 <&pll6>;
>  				clock-output-names = "ar100";
>  			};
>  
> diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> index 6f88fb0ddbc7..edc85eeaf365 100644
> --- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> @@ -60,7 +60,7 @@
>  			compatible = "allwinner,simple-framebuffer",
>  				     "simple-framebuffer";
>  			allwinner,pipeline = "de_be0-lcd0";
> -			clocks = <&pll6 0>;
> +			clocks = <&pll6>;
>  			status = "disabled";
>  		};
>  	};
> @@ -129,11 +129,20 @@
>  		};
>  
>  		pll6: clk at 01c20028 {
> -			#clock-cells = <1>;
> +			#clock-cells = <0>;
>  			compatible = "allwinner,sun6i-a31-pll6-clk";
>  			reg = <0x01c20028 0x4>;
>  			clocks = <&osc24M>;
> -			clock-output-names = "pll6", "pll6x2";
> +			clock-output-names = "pll6";
> +		};
> +
> +                pll6x2: pll6x2_clk {
> +			compatible = "fixed-factor-clock";
> +			#clock-cells = <0>;
> +			clock-div = <1>;
> +			clock-mult = <2>;
> +			clocks = <&pll6>;
> +			clock-output-names = "pll6-2x";
>  		};
>  
>  		cpu: cpu_clk at 01c20050 {
> @@ -163,7 +172,7 @@
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun6i-a31-ahb1-clk";
>  			reg = <0x01c20054 0x4>;
> -			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
> +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
>  			clock-output-names = "ahb1";
>  		};
>  
> @@ -190,7 +199,7 @@
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun4i-a10-apb1-clk";
>  			reg = <0x01c20058 0x4>;
> -			clocks = <&osc32k>, <&osc24M>, <&pll6 0>, <&pll6 0>;
> +			clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
>  			clock-output-names = "apb2";
>  		};
>  
> @@ -213,7 +222,7 @@
>  			#clock-cells = <1>;
>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>  			reg = <0x01c20088 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>;
> +			clocks = <&osc24M>, <&pll6>;
>  			clock-output-names = "mmc0",
>  					     "mmc0_output",
>  					     "mmc0_sample";
> @@ -223,7 +232,7 @@
>  			#clock-cells = <1>;
>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>  			reg = <0x01c2008c 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>;
> +			clocks = <&osc24M>, <&pll6>;
>  			clock-output-names = "mmc1",
>  					     "mmc1_output",
>  					     "mmc1_sample";
> @@ -233,7 +242,7 @@
>  			#clock-cells = <1>;
>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>  			reg = <0x01c20090 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>;
> +			clocks = <&osc24M>, <&pll6>;
>  			clock-output-names = "mmc2",
>  					     "mmc2_output",
>  					     "mmc2_sample";
> diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/sun8i-a23.dtsi
> index 92e6616979ea..5e589c1ddda9 100644
> --- a/arch/arm/boot/dts/sun8i-a23.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a23.dtsi
> @@ -79,7 +79,7 @@
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun8i-a23-mbus-clk";
>  			reg = <0x01c2015c 0x4>;
> -			clocks = <&osc24M>, <&pll6 1>, <&pll5>;
> +			clocks = <&osc24M>, <&pll6x2>, <&pll5>;
>  			clock-output-names = "mbus";
>  		};
>  	};
> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
> index 001d8402ca18..f3eb618bcfa7 100644
> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
> @@ -103,7 +103,7 @@
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun4i-a10-mod0-clk";
>  			reg = <0x01c2009c 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>;
> +			clocks = <&osc24M>, <&pll6>;
>  			clock-output-names = "ss";
>  		};
>  
> @@ -111,7 +111,7 @@
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun8i-a23-mbus-clk";
>  			reg = <0x01c2015c 0x4>;
> -			clocks = <&osc24M>, <&pll6 1>, <&pll5>, <&pll11>;
> +			clocks = <&osc24M>, <&pll6x2>, <&pll5>, <&pll11>;
>  			clock-output-names = "mbus";
>  		};
>  	};
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 1524130e43c9..6f6b4e469ac9 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -121,11 +121,11 @@
>  		};
>  
>  		pll6: clk at 01c20028 {
> -			#clock-cells = <1>;
> +			#clock-cells = <0>;
>  			compatible = "allwinner,sun6i-a31-pll6-clk";
>  			reg = <0x01c20028 0x4>;
>  			clocks = <&osc24M>;
> -			clock-output-names = "pll6", "pll6x2";
> +			clock-output-names = "pll6";
>  		};
>  
>  		pll6d2: pll6d2_clk {
> @@ -133,15 +133,24 @@
>  			compatible = "fixed-factor-clock";
>  			clock-div = <2>;
>  			clock-mult = <1>;
> -			clocks = <&pll6 0>;
> -			clock-output-names = "pll6d2";
> +			clocks = <&pll6>;
> +			clock-output-names = "pll6-d2";
>  		};
>  
> -		/* dummy clock until pll6 can be reused */
> -		pll8: pll8_clk {
> +		pll6x2: pll6x2_clk {
>  			#clock-cells = <0>;
> -			compatible = "fixed-clock";
> -			clock-frequency = <1>;
> +			compatible = "fixed-factor-clock";
> +			clock-div = <1>;
> +			clock-mult = <2>;
> +			clocks = <&pll6>;
> +			clock-output-names = "pll6-2x";
> +		};
> +
> +		pll8: clk at 01c20044 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun6i-a31-pll6-clk";
> +			reg = <0x01c20044 0x4>;
> +			clocks = <&osc24M>;
>  			clock-output-names = "pll8";
>  		};
>  
> @@ -165,7 +174,7 @@
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun6i-a31-ahb1-clk";
>  			reg = <0x01c20054 0x4>;
> -			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
> +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
>  			clock-output-names = "ahb1";
>  		};
>  
> @@ -189,7 +198,7 @@
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun4i-a10-apb1-clk";
>  			reg = <0x01c20058 0x4>;
> -			clocks = <&osc32k>, <&osc24M>, <&pll6 0>, <&pll6 0>;
> +			clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
>  			clock-output-names = "apb2";
>  		};
>  
> @@ -243,7 +252,7 @@
>  			#clock-cells = <1>;
>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>  			reg = <0x01c20088 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
> +			clocks = <&osc24M>, <&pll6>, <&pll8>;
>  			clock-output-names = "mmc0",
>  					     "mmc0_output",
>  					     "mmc0_sample";
> @@ -253,7 +262,7 @@
>  			#clock-cells = <1>;
>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>  			reg = <0x01c2008c 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
> +			clocks = <&osc24M>, <&pll6>, <&pll8>;
>  			clock-output-names = "mmc1",
>  					     "mmc1_output",
>  					     "mmc1_sample";
> @@ -263,7 +272,7 @@
>  			#clock-cells = <1>;
>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>  			reg = <0x01c20090 0x4>;
> -			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
> +			clocks = <&osc24M>, <&pll6>, <&pll8>;
>  			clock-output-names = "mmc2",
>  					     "mmc2_output",
>  					     "mmc2_sample";
> @@ -273,7 +282,7 @@
>  			#clock-cells = <0>;
>  			compatible = "allwinner,sun8i-a23-mbus-clk";
>  			reg = <0x01c2015c 0x4>;
> -			clocks = <&osc24M>, <&pll6 1>, <&pll5>;
> +			clocks = <&osc24M>, <&pll6x2>, <&pll5>;
>  			clock-output-names = "mbus";
>  		};
>  	};
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index da15f2b12ab2..4de800e379d3 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -227,9 +227,9 @@ static void sun4i_get_pll5_factors(struct factors_request *req)
>  }
>  
>  /**
> - * sun6i_a31_get_pll6_factors() - calculates n, k factors for A31 PLL6x2
> - * PLL6x2 rate is calculated as follows
> - * rate = parent_rate * (n + 1) * (k + 1)
> + * sun6i_a31_get_pll6_factors() - calculates n, k factors for A31 PLL6
> + * PLL6 rate is calculated as follows
> + * rate = parent_rate * (n + 1) * (k + 1) / 2
>   * parent_rate is always 24Mhz
>   */
>  
> @@ -238,8 +238,8 @@ static void sun6i_a31_get_pll6_factors(struct factors_request *req)
>  	u8 div;
>  
>  	/* Normalize value to a parent_rate multiple (24M) */
> -	div = req->rate / req->parent_rate;
> -	req->rate = req->parent_rate * div;
> +	div = req->rate / (req->parent_rate / 2);
> +	req->rate = (req->parent_rate / 2) * div;
>  
>  	req->k = div / 32;
>  	if (req->k > 3)
> @@ -248,6 +248,15 @@ static void sun6i_a31_get_pll6_factors(struct factors_request *req)
>  	req->n = DIV_ROUND_UP(div, (req->k + 1)) - 1;
>  }
>  
> +static void sun6i_a31_pll6_recalc(struct factors_request *req)
> +{
> +	req->rate = req->parent_rate;
> +
> +	req->rate *= req->n + 1;
> +	req->rate *= req->k + 1;
> +	req->rate /= 2;
> +}
> +
>  /**
>   * sun5i_a13_get_ahb_factors() - calculates m, p factors for AHB
>   * AHB rate is calculated as follows
> @@ -537,7 +546,7 @@ static const struct factors_data sun6i_a31_pll6_data __initconst = {
>  	.enable = 31,
>  	.table = &sun6i_a31_pll6_config,
>  	.getter = sun6i_a31_get_pll6_factors,
> -	.name = "pll6x2",
> +	.recalc = sun6i_a31_pll6_recalc,
>  };
>  
>  static const struct factors_data sun5i_a13_ahb_data __initconst = {
> @@ -788,15 +797,6 @@ static const struct divs_data pll6_divs_data __initconst = {
>  	}
>  };
>  
> -static const struct divs_data sun6i_a31_pll6_divs_data __initconst = {
> -	.factors = &sun6i_a31_pll6_data,
> -	.ndivs = 2,
> -	.div = {
> -		{ .fixed = 2 }, /* normal output */
> -		{ .self = 1 }, /* base factor clock, 2x */
> -	}
> -};
> -
>  /**
>   * sunxi_divs_clk_setup() - Setup function for leaf divisors on clocks
>   *
> @@ -938,6 +938,7 @@ free_clkdata:
>  static const struct of_device_id clk_factors_match[] __initconst = {
>  	{.compatible = "allwinner,sun4i-a10-pll1-clk", .data = &sun4i_pll1_data,},
>  	{.compatible = "allwinner,sun6i-a31-pll1-clk", .data = &sun6i_a31_pll1_data,},
> +	{.compatible = "allwinner,sun6i-a31-pll6-clk", .data = &sun6i_a31_pll6_data,},
>  	{.compatible = "allwinner,sun8i-a23-pll1-clk", .data = &sun8i_a23_pll1_data,},
>  	{.compatible = "allwinner,sun7i-a20-pll4-clk", .data = &sun7i_a20_pll4_data,},
>  	{.compatible = "allwinner,sun5i-a13-ahb-clk", .data = &sun5i_a13_ahb_data,},
> @@ -959,7 +960,6 @@ static const struct of_device_id clk_div_match[] __initconst = {
>  static const struct of_device_id clk_divs_match[] __initconst = {
>  	{.compatible = "allwinner,sun4i-a10-pll5-clk", .data = &pll5_divs_data,},
>  	{.compatible = "allwinner,sun4i-a10-pll6-clk", .data = &pll6_divs_data,},
> -	{.compatible = "allwinner,sun6i-a31-pll6-clk", .data = &sun6i_a31_pll6_divs_data,},
>  	{}
>  };
>  
> 


From stripathi at apm.com  Fri Feb  5 10:06:35 2016
From: stripathi at apm.com (Suman Tripathi)
Date: Fri, 5 Feb 2016 10:06:35 -0800
Subject: [PATCH v3 1/3] libahci: Implement the capability to override the
 generic ahci interrupt handler.
In-Reply-To: <20160205164122.GB4401@htj.duckdns.org>
References: <1454620826-22554-1-git-send-email-stripathi@apm.com>
 <1454620826-22554-2-git-send-email-stripathi@apm.com>
 <20160205164122.GB4401@htj.duckdns.org>
Message-ID: <CAOHikRDeuyjT_OOBhivZiqVKFgHJAvEXsdcTtqYvjV6PSW+ZLA@mail.gmail.com>

On Fri, Feb 5, 2016 at 8:41 AM, Tejun Heo <tj at kernel.org> wrote:
> Hello,
>
> On Fri, Feb 05, 2016 at 02:50:24AM +0530, suman Tripathi wrote:
> ...
>> @@ -2504,15 +2505,28 @@ int ahci_host_activate(struct ata_host *host, struct scsi_host_template *sht)
>>       struct ahci_host_priv *hpriv = host->private_data;
>>       int irq = hpriv->irq;
>>       int rc;
>> +     irqreturn_t (*ahci_irq_handler)(int irq, void *dev_instance);
>>
>> +     ahci_irq_handler = hpriv->ahci_irq_intr;
>> +
>> +     if (hpriv->flags & (AHCI_HFLAG_MULTI_MSI | AHCI_HFLAG_MULTI_MSIX)) {
>> +             if (!ahci_irq_handler)
>> +                     rc = ahci_host_activate_multi_irqs(host, sht);
>> +             else
>> +                     dev_warn(host->dev, "both AHCI_HFLAG_MULTI_MSI flag set \
>> +                              and custom irq handler implemented\n");
>> +
>> +     } else {
>> +             if (!ahci_irq_handler) {
>> +                     ahci_irq_handler = (hpriv->flags & AHCI_HFLAG_EDGE_IRQ ?
>> +                                         ahci_single_edge_irq_intr :
>> +                                         ahci_single_level_irq_intr);
>> +             }
>> +     }
>
> I wrote this before but can't we do this in save_initial_config the
> same way ->start_engine override is handled?

Sorry missed that out.
>
> --
> tejun



-- 
Thanks,
with regards,
Suman Tripathi


From mathieu.poirier at linaro.org  Fri Feb  5 10:08:14 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Fri, 5 Feb 2016 11:08:14 -0700
Subject: [PATCH V2 3/6] stm class: provision for statically assigned
 masterIDs
In-Reply-To: <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
 <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org>
 <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com>
Message-ID: <CANLsYky2twQ98u241YyHD=atYRp1N56YVHUQNY2E2Ljsq0cseA@mail.gmail.com>

On 5 February 2016 at 05:52, Alexander Shishkin
<alexander.shishkin at linux.intel.com> wrote:
> Chunyan Zhang <zhang.chunyan at linaro.org> writes:
>
>> From: Mathieu Poirier <mathieu.poirier at linaro.org>
>>
>> Some architecture like ARM assign masterIDs statically at the HW design
>> phase, making masterID manipulation in the generic STM core irrelevant.
>>
>> This patch adds a new 'mstatic' flag to struct stm_data that tells the
>> core that this specific STM device doesn't need explicit masterID
>> management.
>
> So why do we need this patch? If your STM only has master 42 allocated
> for software sources, simply set sw_start = 42, sw_end = 42 and you're
> good to go, software will have exactly one channel to choose from. See
> also the comment from <linux/stm.h>:

On ARM each source, i.e entity capable of accessing STM channels, has
a different master ID set in HW.  We can't assume the IDs are
contiguous and from a SW point of view there is no way to probe the
values.

>
>  * @sw_start:           first STP master available to software
>  * @sw_end:             last STP master available to software
>
> particularly the "available to software" part. Any other kinds of
> masters the STM class code doesn't care about (yet).
>
>> In the core sw_start/end of masterID are set to '1',
>> i.e there is only one masterID to deal with.
>
> This is also a completely arbitrary and unnecessary requirement. Again,
> you can set both to 42 and it will still work.

True - any value will do. The important thing to remember is that on
ARM, there is only one masterID channel (from an STM core point of
view).  But we could also proceed differently, see below for more
details.

>
>> Also this patch depends on [1], so that the number of masterID
>> is '1' too.
>>
>> Finally the lower and upper bound for masterIDs as presented
>> in ($SYSFS)/class/stm/XYZ.stm/masters and
>> ($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
>> are set to '-1'.  That way users can't confuse them with
>> architecture where masterID management is required (where any
>> other value would be valid).
>
> Why is this a good idea? Having the actual master there will allow
> software to know what it is and also tell the decoding side what it is
> (assuming you have more than one source in the STP stream, it might not
> be easy to figure out, unless you know it in advance).

In the ARM world masterIDs are irrelevant so why bother with them?
Writing a '-1' simply highlight this reality.

Another way of approaching the problem would be to change sw_start/end
to a bitfield that represent the valid masterIDs but in my opinion, it
is a lot of code churn for information that isn't used outside of the
decoder.

Thanks,
Mathieu

>
> I don't see how one master statically assigned to software sources is
> different from two masters or 32 masters. And I don't see any benefit of
> hiding the master id from userspace. Am I missing something?
>
> Regards,
> --
> Alex


From yamada.masahiro at socionext.com  Fri Feb  5 10:13:37 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Sat, 6 Feb 2016 03:13:37 +0900
Subject: [PATCH] ARM: keystone: remove redundant depends on
 ARM_PATCH_PHYS_VIRT
In-Reply-To: <56B4E257.5050308@oracle.com>
References: <1454694041-14990-1-git-send-email-yamada.masahiro@socionext.com>
 <56B4E257.5050308@oracle.com>
Message-ID: <CAK7LNAQQ-fT38pg2S7QmbuZ3dmpy6qE6viQD87ec=QMNnUx6zQ@mail.gmail.com>

2016-02-06 2:56 GMT+09:00 santosh shilimkar <santosh.shilimkar at oracle.com>:
> On 2/5/2016 9:40 AM, Masahiro Yamada wrote:
>>
>> KeyStone is Multi-platform.  ARM_PATCH_PHYS_VIRT is already select'ed
>> by ARCH_MULTIPLATFORM.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
>> ---
>>
> There is also Keystone config so its nit redundant as you think.
>
> P.S: arch/arm/configs/keystone_defconfig
>

It *is* redundant.

keystone_defconfig also creates Multiplatform configuration.


-- 
Best Regards
Masahiro Yamada


From ivo.g.dimitrov.75 at gmail.com  Fri Feb  5 10:15:02 2016
From: ivo.g.dimitrov.75 at gmail.com (Ivaylo Dimitrov)
Date: Fri,  5 Feb 2016 20:15:02 +0200
Subject: [PATCH] ARM: RX51: Set system_rev from ATAGS
In-Reply-To: <3663322.UyrB2OmX6o@wuerfel>
References: <3663322.UyrB2OmX6o@wuerfel>
Message-ID: <1454696102-2214-1-git-send-email-ivo.g.dimitrov.75@gmail.com>

Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com>
---
 arch/arm/mach-omap2/board-generic.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 8098272..b91fabe 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -18,6 +18,7 @@
 
 #include <asm/setup.h>
 #include <asm/mach/arch.h>
+#include <asm/system_info.h>
 
 #include "common.h"
 
@@ -77,12 +78,31 @@ static const char *const n900_boards_compat[] __initconst = {
 	NULL,
 };
 
+/* Set system_rev from atags */
+static void __init rx51_system_rev(const struct tag *tags)
+{
+	const struct tag *tag;
+
+	if (tags->hdr.tag != ATAG_CORE)
+		return;
+
+	for_each_tag(tag, tags) {
+		if (tag->hdr.tag == ATAG_REVISION) {
+			system_rev = tag->u.revision.rev;
+			break;
+		}
+	}
+}
+
 /* Legacy userspace on Nokia N900 needs ATAGS exported in /proc/atags,
  * save them while the data is still not overwritten
  */
 static void __init rx51_reserve(void)
 {
-	save_atags((const struct tag *)(PAGE_OFFSET + 0x100));
+	const struct tag *tags = (const struct tag *)(PAGE_OFFSET + 0x100);
+
+	save_atags(tags);
+	rx51_system_rev(tags);
 	omap_reserve();
 }
 
-- 
1.9.1



From alex.williamson at redhat.com  Fri Feb  5 10:17:00 2016
From: alex.williamson at redhat.com (Alex Williamson)
Date: Fri, 5 Feb 2016 11:17:00 -0700
Subject: ARM PCI/MSI KVM passthrough with GICv2M
In-Reply-To: <56B4DC97.60904@linaro.org>
References: <1453813968-2024-1-git-send-email-eric.auger@linaro.org>
 <1454017899.23148.0.camel@redhat.com> <56AB78B1.2030202@linaro.org>
 <1454096004.9301.1.camel@redhat.com> <56ABD8E0.6080409@linaro.org>
 <20160201140351.GE6828@arm.com> <20160203125047.GB13974@cbox>
 <20160203131057.GA20217@arm.com> <20160203153606.GC13974@cbox>
 <56B4DC97.60904@linaro.org>
Message-ID: <20160205111700.726ac061@t450s.home>

On Fri, 5 Feb 2016 18:32:07 +0100
Eric Auger <eric.auger at linaro.org> wrote:

> Hi Alex,
> 
> I tried to sketch a proposal for guaranteeing the IRQ integrity when
> doing ARM PCI/MSI passthrough with ARM GICv2M msi-controller. This is
> based on extended VFIO group viability control, as detailed below.
> 
> As opposed to ARM GICv3 ITS, this MSI controller does *not* support IRQ
> remapping. It can expose 1 or more 4kB MSI frame. Each frame contains a
> single register where the msi data is written.
> 
> I would be grateful to you if you could tell me whether it makes any sense.
> 
> Thanks in advance
> 
> Best Regards
> 
> Eric
> 
> 
> 1) GICv2m with a single 4kB single frame
>    all devices having this msi-controller as msi-parent share this
>    single MSI frame. Those devices can work on behalf of the host
>    or work on behalf of 1 or more guests (KVM assigned devices). We
>    must make sure either the host only or 1 single VM can access to the
>    single frame to guarantee interrupt integrity: a device assigned
>    to 1 VM should not be able to trigger MSI targeted to the host
>    or another VM.
> 
>    I would propose to extend the VFIO notion of group viability.
>    Currently a VFIO group is viable if:
>    all devices belonging to the same group are bound to a VFIO driver
>    or unbound.
> 
>    Let's imagine we extend the viability check as follows:
> 
>    0) keep the current viable check: all the devices belonging to
>       the group must be vfio bound or unbound.
>    1) retrieve the MSI parent of the device and list all the
>       other devices using that MSI controller as MSI-parent (does not
>       look straightforward):
>    2) they must be VFIO driver bound or unbound as well (meaning
>       they are not used by the host). If not, reject device attachment
>    - in case they are VFIO bound (a VFIO group is set):
>      x if all VFIO containers are the same as the one of the device's
>        we try to attach, that's OK. This means the other devices
>        use different IOMMU mappings, eventually will target the
>        MSI frame but they all work for the same user space client/VM.
>      x 1 or more devices has a different container than the device
>        under attachment:
>        It works on behalf of a different user space client/VM,
>        we can't attach the new device. I think there is a case however
>        where severals containers can be opened by a single QEMU.
> 
> Of course the dynamic aspects, ie a new device showing up or an unbind
> event bring significant complexity.
> 
> 2) GICv2M with multiple 4kB frames
>    Each msi-frame is enumerated as msi-controller. The device tree
>    statically defines which device is attached to each msi frame.
>    In case devices are assigned we cannot change this attachment
>    anyway since there might be physical contraints behind.
>    So devices likely to be assigned to guests should be linked to a
>    different MSI frame than devices that are not.
> 
>    I think extended viability concept can be used as well.
> 
>    This model still is not ideal: in case we have a SR-IOV device
>    plugged onto an host bridge attached to a single MSI parent you won't
>    be able anyway to have 1 Virtual Function working for host and 1 VF
>    working for a guest. Only Interrupt translation (ITS) will bring that
>    feature.
> 
> 3) GICv3 ITS
>    This one supports interrupt translation service ~ Intel
>    IRQ remapping.
>    This means a single frame can be used by all devices. A deviceID is
>    used exclusively by the host or a guest. I assume the ITS driver
>    allocates/populates deviceid interrupt translation table featuring
>    separate LPI spaces ie by construction different ITT cannot feature
>    same LPIs. So no need to do the extended viability test.
> 
>    The MSI controller should have a property telling whether
>    it supports interrupt translation. This kind of property currently
>    exists on IOMMU side for INTEL remapping.
> 

Hi Eric,

Would anyone be terribly upset if we simply assume the worst case
scenario on GICv2m/M, have the IOMMU not claim IOMMU_CAP_INTR_REMAP, and
require the user to opt-in via the allow_unsafe_interrupts on the
vfio_iommu_type1 module?  That would make it very compatible with what
we already do on x86, where it really is all or nothing.  My assumption
is that GICv2 would be phased out in favor of GICv3, so there's always
a hardware upgrade path to having more complete isolation, but the
return on investment for figuring out whether a given device really has
this sort of isolation seems pretty low.  Often users already have some
degree of trust in the VMs they use for device assignment anyway.  An
especially prudent user can still look at the hardware specs for their
specific system to understand whether any devices are fully isolated
and only make use of those for device assignment.  Does that seem like
a reasonable alternative?  Thanks,

Alex


From fu.wei at linaro.org  Fri Feb  5 10:21:04 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Sat, 6 Feb 2016 02:21:04 +0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <56B4B4E2.40105@roeck-us.net>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
 <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
 <56B2DEE4.7060901@roeck-us.net>
 <CADyBb7unAHEOMfruWS82RkHK6uwPAWCxUx9jqzSkiHU4LHDSeA@mail.gmail.com>
 <56B4B4E2.40105@roeck-us.net>
Message-ID: <CADyBb7sP=d+BWOdmNEAs38yRcmXVjYsFX=XNffNpGqfybpxTfQ@mail.gmail.com>

On 5 February 2016 at 22:42, Guenter Roeck <linux at roeck-us.net> wrote:
> On 02/05/2016 01:51 AM, Fu Wei wrote:
>>
>> Hi Guenter,
>>
>> On 4 February 2016 at 13:17, Guenter Roeck <linux at roeck-us.net> wrote:
>>>
>>> On 02/03/2016 03:00 PM, Fu Wei wrote:
>>>>
>>>>
>>>> On 4 February 2016 at 02:45, Timur Tabi <timur at codeaurora.org> wrote:
>>>>>
>>>>>
>>>>> Fu Wei wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> As you know I have made the pre-timeout support patch, If people like
>>>>>> it, i am happy to go on upstream it separately.
>>>>>>
>>>>>> If we want to use pre-timeout here, user only can use get_pretimeout
>>>>>> and disable panic by setting pretimeout to 0
>>>>>> but user can not really set pretimeout, because "pre-timeout  ==
>>>>>> timeout / 2 (always)".
>>>>>> if user want to change pretimeout, he/she has to set_time instead.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Ok, I think patches 4 and 5 should be combined, and I think the Kconfig
>>>>> entry should be removed and just use panic_enabled.
>>>
>>>
>>>
>>> Agreed.
>>
>>
>> np, will do
>>
>>>>
>>>>
>>>> NP, will update this patchset like that ,  thanks :-)
>>>>
>>>
>>> Also, if panic is enabled, the timeout needs to be adjusted accordingly
>>> (to only panic after the entire timeout period has expired, not after
>>> half of it). We can not panic the system after timeout / 2.
>>
>>
>> OK, my thought is
>>
>> if panic is enabled :
>> |--------WOR-------WS0--------WOR-------WS1
>> |------timeout------(panic)------timeout-----reset
>>
>> if panic is disabled .
>> |--------WOR-------WS0--------WOR-------WS1
>> |---------------------timeout---------------------reset
>>
>>   panic_enabled only can be configured when module is loaded by module
>> parameter
>>
>> But user should know that max_timeout(panic_enable) =
>> max_timeout(panic_disable) / 2
>>
>
> That means you'll have to update max_timeout accordingly.

panic_enabled only can be configured when module is loaded, so we
don't need to update it.

max_timeout will only be set up in the init stage.

Does it make sense ? :-)

>
>>>
>>> I am not too happy with the parameter name (panic_enabled). How about
>>> "action", to match machzwd ?
>>
>>
>> yes, makes sense. Maybe we can do something  like this:
>>
>> /*
>>   * action refers to action taken when watchdog gets WS0
>>   * 0 = SKIP
>>   * 1 = PANIC
>>   * defaults to SKIP (0)
>>   */
>> static int action;
>> module_param(action, int, 0);
>> MODULE_PARM_DESC(action, "after watchdog gets WS0 interrupt, do: "
>> "0 = SKIP(*)  1 = PANIC");
>>
> Yes, though I would suggest to use lower case letters.

yes,  NP, will do , Thanks :-)

>
> Thanks,
> Guenter
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From hdegoede at redhat.com  Fri Feb  5 10:28:45 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Fri, 5 Feb 2016 19:28:45 +0100
Subject: [PATCH v3 3/3] reset: Add support for shared reset controls
In-Reply-To: <1454663304.6406.3.camel@pengutronix.de>
References: <1453918516-3078-1-git-send-email-hdegoede@redhat.com>
 <1453918516-3078-4-git-send-email-hdegoede@redhat.com>
 <1454663304.6406.3.camel@pengutronix.de>
Message-ID: <56B4E9DD.3060000@redhat.com>

Hi,

On 05-02-16 10:08, Philipp Zabel wrote:
> Am Mittwoch, den 27.01.2016, 19:15 +0100 schrieb Hans de Goede:
> [...]
>> @@ -94,9 +99,16 @@ EXPORT_SYMBOL_GPL(reset_controller_unregister);
>>   /**
>>    * reset_control_reset - reset the controlled device
>>    * @rstc: reset controller
>> + *
>> + * Calling this on a shared reset controller is an error.
>>    */
>>   int reset_control_reset(struct reset_control *rstc)
>>   {
>> +	if (rstc->shared) {
>> +		WARN_ON(1);
>> +		return -EINVAL;
>
> Occurrences of
> 	if (condition) {
> 		WARN_ON(1);
> 		...
> 	}
> could be changed to
> 	if (WARN_ON(condition)) {
> 		...
> 	}

Good one, will fix for v4 (v2 of the second attempt at this).

Regards,

Hans


From hdegoede at redhat.com  Fri Feb  5 10:30:30 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Fri, 5 Feb 2016 19:30:30 +0100
Subject: [PATCH v3 1/3] reset: Make [of_]reset_control_get[_foo] functions
 wrappers
In-Reply-To: <1454604866.3356.78.camel@pengutronix.de>
References: <1453918516-3078-1-git-send-email-hdegoede@redhat.com>
 <1453918516-3078-2-git-send-email-hdegoede@redhat.com>
 <1454604866.3356.78.camel@pengutronix.de>
Message-ID: <56B4EA46.7060905@redhat.com>

Hi,

On 04-02-16 17:54, Philipp Zabel wrote:
> Hi Hans,
>
> Am Mittwoch, den 27.01.2016, 19:15 +0100 schrieb Hans de Goede:
> [...]
>> +/**
>> + * reset_control_get - Lookup and obtain a reference to a reset controller.
>> + * @dev: device to be reset by the controller
>> + * @id: reset line name
>> + *
>> + * Returns a struct reset_control or IS_ERR() condition containing errno.
>> + *
>> + * Use of id names is optional.
>> + */
>> +static inline struct reset_control *__must_check reset_control_get(
>>   					struct device *dev, const char *id)
>>   {
>> -	return ERR_PTR(-ENOTSUPP);
>> +#ifndef CONFIG_RESET_CONTROLLER
>> +	WARN_ON(1);
>> +#endif
>> +	return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0);
>
> Even though we are device tree only at this point, I'd prefer to keep an
> exported function that takes a struct device argument, for example:
>
> 	return __reset_control_get(dev, id, 0);

I don't really see a reason to do this, this is not userspace abi or some-such
we can always later re-introduce an exported function which takes a device
argument. But if you insist, you're the boss :)  Let me know if you really
want me to make this change for the next version, and I'll add it to v4 of this
set.

Regards,

Hans


From santosh.shilimkar at oracle.com  Fri Feb  5 10:31:20 2016
From: santosh.shilimkar at oracle.com (santosh shilimkar)
Date: Fri, 5 Feb 2016 10:31:20 -0800
Subject: [PATCH] ARM: keystone: remove redundant depends on
 ARM_PATCH_PHYS_VIRT
In-Reply-To: <CAK7LNAQQ-fT38pg2S7QmbuZ3dmpy6qE6viQD87ec=QMNnUx6zQ@mail.gmail.com>
References: <1454694041-14990-1-git-send-email-yamada.masahiro@socionext.com>
 <56B4E257.5050308@oracle.com>
 <CAK7LNAQQ-fT38pg2S7QmbuZ3dmpy6qE6viQD87ec=QMNnUx6zQ@mail.gmail.com>
Message-ID: <56B4EA78.6050203@oracle.com>

On 2/5/2016 10:13 AM, Masahiro Yamada wrote:
> 2016-02-06 2:56 GMT+09:00 santosh shilimkar <santosh.shilimkar at oracle.com>:
>> On 2/5/2016 9:40 AM, Masahiro Yamada wrote:
>>>
>>> KeyStone is Multi-platform.  ARM_PATCH_PHYS_VIRT is already select'ed
>>> by ARCH_MULTIPLATFORM.
>>>
>>> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
>>> ---
>>>
>> There is also Keystone config so its nit redundant as you think.
>>
>> P.S: arch/arm/configs/keystone_defconfig
>>
>
> It *is* redundant.
>
> keystone_defconfig also creates Multiplatform configuration.
>
Fair enough. Should I checked it.
For patch,
Acked-by: Santosh Shilimkar<ssantosh at kernel.org>



From santosh.shilimkar at oracle.com  Fri Feb  5 10:42:40 2016
From: santosh.shilimkar at oracle.com (santosh shilimkar)
Date: Fri, 5 Feb 2016 10:42:40 -0800
Subject: [PATCH 0/3] Add initial support for TI's K2G SOC
In-Reply-To: <56B142E8.4090301@oracle.com>
References: <1454455517-7360-1-git-send-email-fcooper@ti.com>
 <56B142E8.4090301@oracle.com>
Message-ID: <56B4ED20.8030004@oracle.com>

On 2/2/2016 3:59 PM, santosh shilimkar wrote:
> On 2/2/2016 3:25 PM, Franklin S Cooper Jr wrote:
>> This patchset provides initial support for K2G the latest addition to
>> Texas
>> Instruments Keystone 2 product family. These patches are built on top of
>> the latest 4.5-rc2 commit.
>>
>> K2G is a A15 + C66x DSP processor built to address the needs of
>> industrial
>> communication and control, automotive and performance audio applications.
>>
>> Supported peripherals include MMC,USB2.0,DCAN,DSS,McASP and PCIe SS.
>>
>> The technical reference manual for K2G can be found here:
>> http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf
>>
>> This patchset provides the ability to boot K2G's general purpose evm
>> using
>> a ramfs filesystem.
>>
>> Additional patches will follow this series that will add support for new
>> drivers that will enable additional peripherals and features
>>
>> K2G Bootlog on 4.5-rc2:
>> http://pastebin.ubuntu.com/14861580/
>>
> Quick scan of the series looks fine to me. I will wait for others to
> come back for a week or so and then add to 4.6 queue.
>
> Thanks for the series !!
>
You should start seeing the patches in linux-next build soon.

Reagrds,
Santosh


From contact at paulk.fr  Fri Feb  5 10:42:17 2016
From: contact at paulk.fr (Paul Kocialkowski)
Date: Fri,  5 Feb 2016 19:42:17 +0100
Subject: [PATCH v2 0/6] LG Optimus Black (P970) codename sniper support and
 lp872x improvements
Message-ID: <1454697741-8687-1-git-send-email-contact@paulk.fr>

Changes since v1:
* Remove lp872x patches that were accepted already from the series
* Explain why removing the invalid DVS GPIO warning is enough
* Update copyright notice on omap3-sniper.dts
* Rename the devicetree property for the enable GPIO to enable-gpios
* Rename function to enable GPIO to lp872x_hw_enable
* Add enable delays after requesting the enable GPIO
* Use IOPAD macros for pinmux description
* Mux the dp3t uart selection pins to gpio
* Restrict not-reset gpio controllers to only avoid reset when needed

This series introduces support for the LG Optimus Black, as described in the
patch adding devicetree support for the device.

In order to power the external mmc (mmc1), the lp872x regulator is used.
Its code had to be improved a bit to work on the device.

Note that the patch adding devicetree support for the device requires the
changes applied to the lp872x regulator, so all this is sent in one series
despite the fact they're different parts of the code.



From contact at paulk.fr  Fri Feb  5 10:42:18 2016
From: contact at paulk.fr (Paul Kocialkowski)
Date: Fri,  5 Feb 2016 19:42:18 +0100
Subject: [PATCH v2 1/4] regulator: lp872x: Remove warning about invalid DVS
 GPIO
In-Reply-To: <1454697741-8687-1-git-send-email-contact@paulk.fr>
References: <1454697741-8687-1-git-send-email-contact@paulk.fr>
Message-ID: <1454697741-8687-2-git-send-email-contact@paulk.fr>

Some devices don't hook the DVS pin to a GPIO but to ground or VCC.
In those cases, it is not a problem to have no DVS GPIO provided, as the current
code will already switch to software-only DVS selection:

When the DVS GPIO is invalid, lp872x_init_dvs jumps to the set_default_dvs_mode
label, which instructs the chip not to use the DVS pin at all and do it all in
software instead (by clearing the LP8720_EXT_DVS_M bit in the
LP872X_GENERAL_CFG register).

That is reflected later in the code, when setting the bucks (the DVS pin only
applies to the bucks) by checking for the LP8720_EXT_DVS_M bit on the
LP872X_GENERAL_CFG register (in lp872x_select_buck_vout_addr) to decide whether
to use software or hardware DVS selection.

Thus, there is no need to print a warning when the DVS GPIO is invalid.

Signed-off-by: Paul Kocialkowski <contact at paulk.fr>
---
 drivers/regulator/lp872x.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
index 19d7584..21c49d8 100644
--- a/drivers/regulator/lp872x.c
+++ b/drivers/regulator/lp872x.c
@@ -738,10 +738,8 @@ static int lp872x_init_dvs(struct lp872x *lp)
 		goto set_default_dvs_mode;
 
 	gpio = dvs->gpio;
-	if (!gpio_is_valid(gpio)) {
-		dev_warn(lp->dev, "invalid gpio: %d\n", gpio);
+	if (!gpio_is_valid(gpio))
 		goto set_default_dvs_mode;
-	}
 
 	pinstate = dvs->init_state;
 	ret = devm_gpio_request_one(lp->dev, gpio, pinstate, "LP872X DVS");
-- 
1.9.1



From contact at paulk.fr  Fri Feb  5 10:42:19 2016
From: contact at paulk.fr (Paul Kocialkowski)
Date: Fri,  5 Feb 2016 19:42:19 +0100
Subject: [PATCH v2 2/4] regulator: lp872x: Add enable GPIO pin support
In-Reply-To: <1454697741-8687-1-git-send-email-contact@paulk.fr>
References: <1454697741-8687-1-git-send-email-contact@paulk.fr>
Message-ID: <1454697741-8687-3-git-send-email-contact@paulk.fr>

LP872x regulators are made active via the EN pin, which might be hooked to a
GPIO. This adds support for driving the GPIO high when the driver is in use.

Signed-off-by: Paul Kocialkowski <contact at paulk.fr>
---
 .../devicetree/bindings/regulator/lp872x.txt       |  1 +
 drivers/regulator/lp872x.c                         | 34 ++++++++++++++++++++++
 include/linux/regulator/lp872x.h                   |  5 ++++
 3 files changed, 40 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/lp872x.txt b/Documentation/devicetree/bindings/regulator/lp872x.txt
index 7818318..ca58a68 100644
--- a/Documentation/devicetree/bindings/regulator/lp872x.txt
+++ b/Documentation/devicetree/bindings/regulator/lp872x.txt
@@ -28,6 +28,7 @@ Optional properties:
   - ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x devices.
   - ti,dvs-vsel: DVS selector. 0 = SEL_V1, 1 = SEL_V2.
   - ti,dvs-state: initial DVS pin state. 0 = DVS_LOW, 1 = DVS_HIGH.
+  - enable-gpios: GPIO specifier for EN pin control of LP872x devices.
 
   Sub nodes for regulator_init_data
     LP8720 has maximum 6 nodes. (child name: ldo1 ~ 5 and buck)
diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
index 21c49d8..3899211 100644
--- a/drivers/regulator/lp872x.c
+++ b/drivers/regulator/lp872x.c
@@ -15,6 +15,7 @@
 #include <linux/regmap.h>
 #include <linux/err.h>
 #include <linux/gpio.h>
+#include <linux/delay.h>
 #include <linux/regulator/lp872x.h>
 #include <linux/regulator/driver.h>
 #include <linux/platform_device.h>
@@ -757,6 +758,33 @@ set_default_dvs_mode:
 				default_dvs_mode[lp->chipid]);
 }
 
+static int lp872x_hw_enable(struct lp872x *lp)
+{
+	int ret, gpio;
+
+	if (!lp->pdata)
+		return -EINVAL;
+
+	gpio = lp->pdata->enable_gpio;
+	if (!gpio_is_valid(gpio))
+		return 0;
+
+	/* Always set enable GPIO high. */
+	ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, "LP872X EN");
+	if (ret) {
+		dev_err(lp->dev, "gpio request err: %d\n", ret);
+		return ret;
+	}
+
+	/* Each chip has a different enable delay. */
+	if (lp->chipid == LP8720)
+		usleep_range(LP8720_ENABLE_DELAY, 1.5 * LP8720_ENABLE_DELAY);
+	else
+		usleep_range(LP8725_ENABLE_DELAY, 1.5 * LP8725_ENABLE_DELAY);
+
+	return 0;
+}
+
 static int lp872x_config(struct lp872x *lp)
 {
 	struct lp872x_platform_data *pdata = lp->pdata;
@@ -875,6 +903,8 @@ static struct lp872x_platform_data
 	of_property_read_u8(np, "ti,dvs-state", &dvs_state);
 	pdata->dvs->init_state = dvs_state ? DVS_HIGH : DVS_LOW;
 
+	pdata->enable_gpio = of_get_named_gpio(np, "enable-gpios", 0);
+
 	if (of_get_child_count(np) == 0)
 		goto out;
 
@@ -948,6 +978,10 @@ static int lp872x_probe(struct i2c_client *cl, const struct i2c_device_id *id)
 	lp->chipid = id->driver_data;
 	i2c_set_clientdata(cl, lp);
 
+	ret = lp872x_hw_enable(lp);
+	if (ret)
+		return ret;
+
 	ret = lp872x_config(lp);
 	if (ret)
 		return ret;
diff --git a/include/linux/regulator/lp872x.h b/include/linux/regulator/lp872x.h
index 132e05c..6029279 100644
--- a/include/linux/regulator/lp872x.h
+++ b/include/linux/regulator/lp872x.h
@@ -18,6 +18,9 @@
 
 #define LP872X_MAX_REGULATORS		9
 
+#define LP8720_ENABLE_DELAY		200
+#define LP8725_ENABLE_DELAY		30000
+
 enum lp872x_regulator_id {
 	LP8720_ID_BASE,
 	LP8720_ID_LDO1 = LP8720_ID_BASE,
@@ -79,12 +82,14 @@ struct lp872x_regulator_data {
  * @update_config     : if LP872X_GENERAL_CFG register is updated, set true
  * @regulator_data    : platform regulator id and init data
  * @dvs               : dvs data for buck voltage control
+ * @enable_gpio       : gpio pin number for enable control
  */
 struct lp872x_platform_data {
 	u8 general_config;
 	bool update_config;
 	struct lp872x_regulator_data regulator_data[LP872X_MAX_REGULATORS];
 	struct lp872x_dvs *dvs;
+	int enable_gpio;
 };
 
 #endif
-- 
1.9.1



From contact at paulk.fr  Fri Feb  5 10:42:20 2016
From: contact at paulk.fr (Paul Kocialkowski)
Date: Fri,  5 Feb 2016 19:42:20 +0100
Subject: [PATCH v2 3/4] ARM: LG Optimus Black (P970) codename sniper support,
 with basic features
In-Reply-To: <1454697741-8687-1-git-send-email-contact@paulk.fr>
References: <1454697741-8687-1-git-send-email-contact@paulk.fr>
Message-ID: <1454697741-8687-4-git-send-email-contact@paulk.fr>

The LG Optimus Black (P970) codename sniper is a smartphone that was designed
and manufactured by LG Electronics (LGE) and released back in 2011.
It is using an OMAP3630 SoC, GP version.

This adds devicetree support for the device, with only a few basic features
supported, such as debug uart, i2c, internal emmc and external mmc.

Signed-off-by: Paul Kocialkowski <contact at paulk.fr>
---
 arch/arm/boot/dts/Makefile         |   1 +
 arch/arm/boot/dts/omap3-sniper.dts | 215 +++++++++++++++++++++++++++++++++++++
 2 files changed, 216 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap3-sniper.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..7314cf8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -460,6 +460,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += \
 	omap3-sbc-t3517.dtb \
 	omap3-sbc-t3530.dtb \
 	omap3-sbc-t3730.dtb \
+	omap3-sniper.dtb \
 	omap3-thunder.dtb \
 	omap3-zoom3.dtb
 dtb-$(CONFIG_SOC_TI81XX) += \
diff --git a/arch/arm/boot/dts/omap3-sniper.dts b/arch/arm/boot/dts/omap3-sniper.dts
new file mode 100644
index 0000000..24bcd82
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-sniper.dts
@@ -0,0 +1,215 @@
+/*
+ * Copyright (C) 2015-2016 Paul Kocialkowski <contact at paulk.fr>
+ *
+ * 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.
+ */
+/dts-v1/;
+
+#include "omap36xx.dtsi"
+
+/ {
+	model = "LG Optimus Black (P970)";
+	compatible = "lge,omap3-sniper", "ti,omap36xx", "ti,omap3";
+
+	cpus {
+		cpu at 0 {
+			cpu0-supply = <&vcc>;
+		};
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x20000000>; /* 512 MB */
+	};
+};
+
+&omap3_pmx_core {
+	pinctrl-names = "default";
+
+	uart3_pins: pinmux_uart3_pins {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | MUX_MODE0)	/* uart3_rx_irrx */
+			OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0)	/* uart3_tx_irtx */
+		>;
+	};
+
+	dp3t_sel_pins: pinmux_dp3t_sel_pins {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x2196, PIN_OUTPUT | MUX_MODE4)	/* gpio_161 */
+			OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE4)	/* gpio_162 */
+		>;
+	};
+
+	i2c1_pins: pinmux_i2c1_pins {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0)	/* i2c1_scl */
+			OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0)	/* i2c1_sda */
+		>;
+	};
+
+	i2c2_pins: pinmux_i2c2_pins {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x21be, PIN_INPUT | MUX_MODE0)	/* i2c2_scl */
+			OMAP3_CORE1_IOPAD(0x21c0, PIN_INPUT | MUX_MODE0)	/* i2c2_sda */
+		>;
+	};
+
+	i2c3_pins: pinmux_i2c3_pins {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x21c2, PIN_INPUT | MUX_MODE0)	/* i2c3_scl */
+			OMAP3_CORE1_IOPAD(0x21c4, PIN_INPUT | MUX_MODE0)	/* i2c3_sda */
+		>;
+	};
+
+	lp8720_en_pin: pinmux_lp8720_en_pin {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x2080, PIN_OUTPUT | MUX_MODE4)	/* gpio_37 */
+		>;
+	};
+
+	mmc1_pins: pinmux_mmc1_pins {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT | MUX_MODE0)	/* sdmmc1_clk */
+			OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT | MUX_MODE0)	/* sdmmc1_cmd */
+			OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT | MUX_MODE0)	/* sdmmc1_dat0 */
+			OMAP3_CORE1_IOPAD(0x214a, PIN_INPUT | MUX_MODE0)	/* sdmmc1_dat1 */
+			OMAP3_CORE1_IOPAD(0x214c, PIN_INPUT | MUX_MODE0)	/* sdmmc1_dat2 */
+			OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT | MUX_MODE0)	/* sdmmc1_dat3 */
+		>;
+	};
+
+	mmc2_pins: pinmux_mmc2_pins {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT | MUX_MODE0)	/* sdmmc2_clk */
+			OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT | MUX_MODE0)	/* sdmmc2_cmd */
+			OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat0 */
+			OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat1 */
+			OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat2 */
+			OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat3 */
+			OMAP3_CORE1_IOPAD(0x2164, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat4 */
+			OMAP3_CORE1_IOPAD(0x2166, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat5 */
+			OMAP3_CORE1_IOPAD(0x2168, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat6 */
+			OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat7 */
+		>;
+	};
+};
+
+&omap3_pmx_wkup {
+	pinctrl-names = "default";
+
+	mmc1_cd_pin: pinmux_mmc1_cd_pin {
+		pinctrl-single,pins = <
+			OMAP3_WKUP_IOPAD(0x2a1a, PIN_INPUT | MUX_MODE4)		/* gpio_10 */
+		>;
+	};
+};
+
+&gpio2 {
+	ti,no-reset-on-init;
+};
+
+&gpio5 {
+	ti,no-reset-on-init;
+};
+
+&gpio6 {
+	ti,no-reset-on-init;
+};
+
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart3_pins &dp3t_sel_pins>;
+
+	interrupts-extended = <&intc 74 &omap3_pmx_core OMAP3_UART3_RX>;
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins>;
+
+	clock-frequency = <2600000>;
+
+	twl: twl at 48 {
+		reg = <0x48>;
+		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+		interrupt-parent = <&intc>;
+
+		twl_power: power {
+			compatible = "ti,twl4030-power";
+			ti,use_poweroff;
+		};
+	};
+};
+
+#include "twl4030.dtsi"
+#include "twl4030_omap3.dtsi"
+
+&i2c2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c2_pins>;
+
+	clock-frequency = <400000>;
+};
+
+&i2c3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c3_pins>;
+
+	clock-frequency = <400000>;
+
+	lp8720 at 7d {
+		pinctrl-names = "default";
+		pinctrl-0 = <&lp8720_en_pin>;
+
+		compatible = "ti,lp8720";
+		reg = <0x7d>;
+
+		enable-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* gpio_37 */
+
+		lp8720_ldo1: ldo1 {
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3000000>;
+		};
+	};
+};
+
+&mmc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_pins &mmc1_cd_pin>;
+	vmmc-supply = <&lp8720_ldo1>;
+	cd-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>; /* gpio 10 */
+	bus-width = <4>;
+};
+
+&mmc2 {
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc2_pins>;
+	vmmc-supply = <&vmmc2>;
+	ti,non-removable;
+	bus-width = <8>;
+};
+
+&mmc3 {
+	status = "disabled";
+};
+
+/*
+ * The TWL4030 VAUX2 and VDAC regulators power sensors that are slaves on I2C3.
+ * When not powered, these sensors cause the I2C3 clock to stay low at all times,
+ * making it impossible to reach other devices on I2C3.
+ */
+
+&vaux2 {
+	regulator-min-microvolt = <2800000>;
+	regulator-max-microvolt = <2800000>;
+	regulator-always-on;
+};
+
+&vdac {
+	regulator-min-microvolt = <1800000>;
+	regulator-max-microvolt = <1800000>;
+	regulator-always-on;
+};
-- 
1.9.1



From contact at paulk.fr  Fri Feb  5 10:42:21 2016
From: contact at paulk.fr (Paul Kocialkowski)
Date: Fri,  5 Feb 2016 19:42:21 +0100
Subject: [PATCH v2 4/4] ARM: multi_v7_defconfig: Enable LP872x regulator
 support
In-Reply-To: <1454697741-8687-1-git-send-email-contact@paulk.fr>
References: <1454697741-8687-1-git-send-email-contact@paulk.fr>
Message-ID: <1454697741-8687-5-git-send-email-contact@paulk.fr>

The LP872x regulator is used in the LG Optimus Black (P970) codename sniper
to supply the external mmc card.

Signed-off-by: Paul Kocialkowski <contact at paulk.fr>
---
 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 314f6be..bc44876 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -467,6 +467,7 @@ CONFIG_REGULATOR_RK808=y
 CONFIG_REGULATOR_GPIO=y
 CONFIG_MFD_SYSCON=y
 CONFIG_POWER_RESET_SYSCON=y
+CONFIG_REGULATOR_LP872X=y
 CONFIG_REGULATOR_MAX14577=m
 CONFIG_REGULATOR_MAX8907=y
 CONFIG_REGULATOR_MAX8973=y
-- 
1.9.1



From tchalamarla at caviumnetworks.com  Fri Feb  5 10:47:07 2016
From: tchalamarla at caviumnetworks.com (tchalamarla at caviumnetworks.com)
Date: Fri, 5 Feb 2016 10:47:07 -0800
Subject: [PATCH] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
Message-ID: <1454698027-20911-1-git-send-email-tchalamarla@caviumnetworks.com>

From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>

An issue exists whereby the Linux kernel requires that ASIDs are a
unique namespace per SMMU.  That ASID-local choice conflicts with the
CN88xx SMMU, where only shared ASID namespaces are supported;
specifically within a given node SMMU0 and SMMU1 share, as does SMMU2
and SMMU3. CN88xx SMMU also requires global VMIDs.

This patch tries to address these issuee by supplying asid and vmid
transformations from devicetree.

Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
---
 .../devicetree/bindings/iommu/arm,smmu.txt         | 16 ++++++
 drivers/iommu/arm-smmu.c                           | 59 ++++++++++++++++++----
 2 files changed, 65 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index 7180745..eef06d0 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -55,6 +55,22 @@ conditions.
                   aliases of secure registers have to be used during
                   SMMU configuration.
 
+- thunderx,smmu-asid-transform	: Enable proper handling for buggy
+		  implementations that require special transformations
+		  for smmu asid. if this property exists asid-transform
+		  property must be present.
+
+- thunderx,smmu-vmid-transform	: Enable proper handling for buggy
+		  implementations that require special transformations
+		  for smmu vmid. if this property exists vmid-transform
+		  property must be present.
+
+- asid-transform 	: Transform mask that needs to be applied to asid.
+			This property has to be specified as '/bits/ 8' value.
+
+- vmid-transform 	: Transform mask that needs to be applied to vmid.
+			This property has to be specified as '/bits/ 8' value.
+
 Example:
 
         smmu {
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 59ee4b8..8047834 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -300,8 +300,12 @@ struct arm_smmu_device {
 	u32				features;
 
 #define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
+#define ARM_SMMU_OPT_TRANSFORM_ASID	(1 << 1)
+#define ARM_SMMU_OPT_TRANSFORM_VMID	(1 << 2)
 	u32				options;
 	enum arm_smmu_arch_version	version;
+	u8				asid_transform;
+	u8				vmid_transform;
 
 	u32				num_context_banks;
 	u32				num_s2_context_banks;
@@ -330,8 +334,25 @@ struct arm_smmu_cfg {
 };
 #define INVALID_IRPTNDX			0xff
 
-#define ARM_SMMU_CB_ASID(cfg)		((cfg)->cbndx)
-#define ARM_SMMU_CB_VMID(cfg)		((cfg)->cbndx + 1)
+/*
+ * ThunderX has a unique requirement because of ERRATA#27704
+ * An issue exists whereby the Linux kernel requires that ASIDs are a
+ * unique namespace per SMMU.  That ASID-local choice conflicts with the
+ * CN88xx SMMU, where only shared ASID namespaces are supported;
+ * specifically within a given node SMMU0 and SMMU1 share, as does SMMU2
+ * and SMMU3.
+ * CN88xx SMMU also requires global VMIDs.
+ */
+
+#define ARM_SMMU_CB_ASID(smmu, cfg)					\
+		(((smmu)->options & ARM_SMMU_OPT_TRANSFORM_ASID)	\
+		? ((cfg)->cbndx | (smmu)->asid_transform)		\
+		: ((cfg)->cbndx))
+
+#define ARM_SMMU_CB_VMID(smmu, cfg)					\
+		(((smmu)->options & ARM_SMMU_OPT_TRANSFORM_VMID)	\
+		? (((cfg)->cbndx + 1) | (smmu)->vmid_transform)		\
+		: ((cfg)->cbndx + 1))
 
 enum arm_smmu_domain_stage {
 	ARM_SMMU_DOMAIN_S1 = 0,
@@ -361,6 +382,8 @@ struct arm_smmu_option_prop {
 
 static struct arm_smmu_option_prop arm_smmu_options[] = {
 	{ ARM_SMMU_OPT_SECURE_CFG_ACCESS, "calxeda,smmu-secure-config-access" },
+	{ ARM_SMMU_OPT_TRANSFORM_ASID, "thunderx,smmu-asid-transform" },
+	{ ARM_SMMU_OPT_TRANSFORM_VMID, "thunderx,smmu-vmid-transform" },
 	{ 0, NULL},
 };
 
@@ -570,11 +593,11 @@ static void arm_smmu_tlb_inv_context(void *cookie)
 
 	if (stage1) {
 		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
-		writel_relaxed(ARM_SMMU_CB_ASID(cfg),
+		writel_relaxed(ARM_SMMU_CB_ASID(smmu, cfg),
 			       base + ARM_SMMU_CB_S1_TLBIASID);
 	} else {
 		base = ARM_SMMU_GR0(smmu);
-		writel_relaxed(ARM_SMMU_CB_VMID(cfg),
+		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg),
 			       base + ARM_SMMU_GR0_TLBIVMID);
 	}
 
@@ -596,7 +619,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
 
 		if (!IS_ENABLED(CONFIG_64BIT) || smmu->version == ARM_SMMU_V1) {
 			iova &= ~12UL;
-			iova |= ARM_SMMU_CB_ASID(cfg);
+			iova |= ARM_SMMU_CB_ASID(smmu, cfg);
 			do {
 				writel_relaxed(iova, reg);
 				iova += granule;
@@ -604,7 +627,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
 #ifdef CONFIG_64BIT
 		} else {
 			iova >>= 12;
-			iova |= (u64)ARM_SMMU_CB_ASID(cfg) << 48;
+			iova |= (u64)ARM_SMMU_CB_ASID(smmu, cfg) << 48;
 			do {
 				writeq_relaxed(iova, reg);
 				iova += granule >> 12;
@@ -624,7 +647,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
 #endif
 	} else {
 		reg = ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_TLBIVMID;
-		writel_relaxed(ARM_SMMU_CB_VMID(cfg), reg);
+		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg), reg);
 	}
 }
 
@@ -752,7 +775,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 		reg |= (CBAR_S1_BPSHCFG_NSH << CBAR_S1_BPSHCFG_SHIFT) |
 			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
 	} else {
-		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
+		reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBAR_VMID_SHIFT;
 	}
 	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
 
@@ -760,11 +783,11 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 	if (stage1) {
 		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
 
-		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
+		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
 		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR0);
 
 		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
-		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
+		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
 		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR1);
 	} else {
 		reg64 = pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
@@ -1793,6 +1816,22 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 
 	parse_driver_options(smmu);
 
+	if (smmu->options & ARM_SMMU_OPT_TRANSFORM_ASID) {
+		if (of_property_read_u8(dev->of_node, "#asid-transform",
+					 &smmu->asid_transform)) {
+			dev_err(dev, "missing #asid-transform property\n");
+			return -ENODEV;
+		}
+	}
+
+	if (smmu->options & ARM_SMMU_OPT_TRANSFORM_VMID) {
+		if (of_property_read_u8(dev->of_node, "#vmid-transform",
+					 &smmu->vmid_transform)) {
+			dev_err(dev, "missing #vmid-transform property\n");
+			return -ENODEV;
+		}
+	}
+
 	if (smmu->version > ARM_SMMU_V1 &&
 	    smmu->num_context_banks != smmu->num_context_irqs) {
 		dev_err(dev,
-- 
2.1.0



From contact at paulk.fr  Fri Feb  5 10:48:10 2016
From: contact at paulk.fr (Paul Kocialkowski)
Date: Fri, 05 Feb 2016 19:48:10 +0100
Subject: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support
In-Reply-To: <20160118163248.GI6588@sirena.org.uk>
References: <5681D7A8.2030101@ti.com> <1451387613.18148.9.camel@collins>
 <568323B7.7080101@ti.com> <1451464521.2531.4.camel@collins>
 <20151230163307.GW16023@sirena.org.uk> <1451500639.14341.6.camel@collins>
 <20151231214007.GC16023@sirena.org.uk> <1451599146.9673.2.camel@collins>
 <20151231221407.GF16023@sirena.org.uk> <1452929533.2520.1.camel@collins>
 <20160118163248.GI6588@sirena.org.uk>
Message-ID: <1454698090.2623.3.camel@collins>

Hi,

Le lundi 18 janvier 2016 ? 16:32 +0000, Mark Brown a ?crit :
> On Sat, Jan 16, 2016 at 08:32:13AM +0100, Paul Kocialkowski wrote:
> 
> > Is there some git tree I can work with that has regulator runtime PM
> > support at this point? I'll certainly end up handling the GPIO in the
> > driver otherwise.
> 
> No, the last week was much more busy than I was expecting.  I'm hoping
> for this week (or you could have a go at implementing it, it'd be adding
> the PM operations in _regulator_enable() or _regulator_do_enable() if a
> flag was set in the regulator_desc).

I decided to go with a function simply requesting the GPIO for v2.
Support for runtime PM can be added later. I'll get back to you on this
on the thread related to your patches, since it appears to be somewhat
broken for now.

Thanks!
-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: https://www.replicant.us/
Blog: https://blog.replicant.us/
Wiki/tracker/forums: https://redmine.replicant.us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160205/b35e9556/attachment.sig>

From contact at paulk.fr  Fri Feb  5 10:48:53 2016
From: contact at paulk.fr (Paul Kocialkowski)
Date: Fri, 05 Feb 2016 19:48:53 +0100
Subject: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support
In-Reply-To: <CAL_JsqLiuNR_MQ+eX_TQVMDtn85hUTweNRL2Q+7Z8Tq-HJhx2g@mail.gmail.com>
References: <1450868319-20513-1-git-send-email-contact@paulk.fr>
 <1450868319-20513-5-git-send-email-contact@paulk.fr>
 <20151229200244.GA27426@rob-hp-laptop> <1451424412.13576.1.camel@collins>
 <CAL_JsqLiuNR_MQ+eX_TQVMDtn85hUTweNRL2Q+7Z8Tq-HJhx2g@mail.gmail.com>
Message-ID: <1454698133.2623.4.camel@collins>

Hi,

Le mardi 29 d?cembre 2015 ? 15:55 -0600, Rob Herring a ?crit :
> On Tue, Dec 29, 2015 at 3:26 PM, Paul Kocialkowski <contact at paulk.fr> wrote:
> > Le mardi 29 d?cembre 2015 ? 14:02 -0600, Rob Herring a ?crit :
> >> On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote:
> >> > LP872x regulators are made active via the EN pin, which might be hooked to a
> >> > GPIO. This adds support for driving the GPIO high when the driver is in use.
> >> >
> >> > Signed-off-by: Paul Kocialkowski <contact at paulk.fr>
> >> > ---
> >> >  .../devicetree/bindings/regulator/lp872x.txt       |  1 +
> >> >  drivers/regulator/lp872x.c                         | 33 ++++++++++++++++++++--
> >> >  include/linux/regulator/lp872x.h                   |  2 ++
> >> >  3 files changed, 33 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/regulator/lp872x.txt b/Documentation/devicetree/bindings/regulator/lp872x.txt
> >> > index 7818318..0559c25 100644
> >> > --- a/Documentation/devicetree/bindings/regulator/lp872x.txt
> >> > +++ b/Documentation/devicetree/bindings/regulator/lp872x.txt
> >> > @@ -28,6 +28,7 @@ Optional properties:
> >> >    - ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x devices.
> >> >    - ti,dvs-vsel: DVS selector. 0 = SEL_V1, 1 = SEL_V2.
> >> >    - ti,dvs-state: initial DVS pin state. 0 = DVS_LOW, 1 = DVS_HIGH.
> >> > +  - ti,enable-gpio: GPIO specifier for EN pin control of LP872x devices.
> >>
> >> Should be "-gpios" instead of "-gpio".

Thanks for the review Rob, I have just submitted v2 with those
suggestions integrated.

> > Care to comment why? There is only one GPIO that can be used here, since
> > there is only one single EN pin. I thought this matched what is done
> > already with "ti,dvs-gpio".
> 
> To be consistent. We use "clocks" and "interrupts" always whether one
> or more for example.
> 
> -gpio is documented as deprecated now.
> 
> Rob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160205/6e237f9c/attachment.sig>

From contact at paulk.fr  Fri Feb  5 10:49:12 2016
From: contact at paulk.fr (Paul Kocialkowski)
Date: Fri, 05 Feb 2016 19:49:12 +0100
Subject: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support
In-Reply-To: <5680839E.4080800@ti.com>
References: <1450868319-20513-1-git-send-email-contact@paulk.fr>
 <1450868319-20513-5-git-send-email-contact@paulk.fr>
 <5680839E.4080800@ti.com>
Message-ID: <1454698152.2623.5.camel@collins>

Le lundi 28 d?cembre 2015 ? 09:34 +0900, Milo Kim a ?crit :
> Hi Paul,
> 
> Thanks for the patches. Please see my comments below.

Thanks for the review Milo, I have just submitted v2 with those
suggestions integrated.

> On 23/12/15 19:58, Paul Kocialkowski wrote:
> > LP872x regulators are made active via the EN pin, which might be hooked to a
> > GPIO. This adds support for driving the GPIO high when the driver is in use.
> 
> EN pin is used for enabling HW logic like I2C block. It's not regulator 
> enable pin. Please check the block diagram in the datasheet.
> 
> All regulators of LP8720 and LP8725 are controlled through I2C 
> registers. Additionally, LP8725 provides external pin control for LDO3 
> and BUCK2. In this case, you can use 'regulator_config.ena_gpio' when a 
> regulator is registered.
> 
> >
> > Signed-off-by: Paul Kocialkowski <contact at paulk.fr>
> > ---
> >   .../devicetree/bindings/regulator/lp872x.txt       |  1 +
> >   drivers/regulator/lp872x.c                         | 33 ++++++++++++++++++++--
> >   include/linux/regulator/lp872x.h                   |  2 ++
> >   3 files changed, 33 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/regulator/lp872x.txt b/Documentation/devicetree/bindings/regulator/lp872x.txt
> > index 7818318..0559c25 100644
> > --- a/Documentation/devicetree/bindings/regulator/lp872x.txt
> > +++ b/Documentation/devicetree/bindings/regulator/lp872x.txt
> > @@ -28,6 +28,7 @@ Optional properties:
> >     - ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x devices.
> >     - ti,dvs-vsel: DVS selector. 0 = SEL_V1, 1 = SEL_V2.
> >     - ti,dvs-state: initial DVS pin state. 0 = DVS_LOW, 1 = DVS_HIGH.
> > +  - ti,enable-gpio: GPIO specifier for EN pin control of LP872x devices.
> 
> Please use general property, "enable-gpios" instead of "ti,enable-gpio".
> 
> >
> >     Sub nodes for regulator_init_data
> >       LP8720 has maximum 6 nodes. (child name: ldo1 ~ 5 and buck)
> > diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
> > index 21c49d8..c8855f3 100644
> > --- a/drivers/regulator/lp872x.c
> > +++ b/drivers/regulator/lp872x.c
> > @@ -726,6 +726,27 @@ static struct regulator_desc lp8725_regulator_desc[] = {
> >   	},
> >   };
> >
> > +static int lp872x_init_enable(struct lp872x *lp)
> 
> lp872x_enable_hw() would be better.
> 
> > +{
> > +	int ret, gpio;
> > +
> > +	if (!lp->pdata)
> > +		return -EINVAL;
> > +
> > +	gpio = lp->pdata->enable_gpio;
> > +	if (!gpio_is_valid(gpio))
> > +		return 0;
> > +
> > +	/* Always set enable GPIO high. */
> > +	ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, "LP872X EN");
> > +	if (ret) {
> > +		dev_err(lp->dev, "gpio request err: %d\n", ret);
> > +		return ret;
> > +	}
> 
> LP8720 device needs max 200usec for startup time.
> LP8725 also requires enable time about 30ms.
> Please use usleep_range() after EN pin control.
> 
> > +
> > +	return 0;
> > +}
> > +
> >   static int lp872x_init_dvs(struct lp872x *lp)
> >   {
> >   	int ret, gpio;
> > @@ -763,14 +784,18 @@ static int lp872x_config(struct lp872x *lp)
> >   	int ret;
> >
> >   	if (!pdata || !pdata->update_config)
> > -		goto init_dvs;
> > +		goto init_dvs_enable;
> >
> >   	ret = lp872x_write_byte(lp, LP872X_GENERAL_CFG, pdata->general_config);
> >   	if (ret)
> >   		return ret;
> >
> > -init_dvs:
> > -	return lp872x_init_dvs(lp);
> > +init_dvs_enable:
> > +	ret = lp872x_init_dvs(lp);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return lp872x_init_enable(lp);
> >   }
> 
> Logic should be enabled prior to DVS configuration. And please call 
> lp872x_enable_hw() in _probe().
> 
> >
> >   static struct regulator_init_data
> > @@ -875,6 +900,8 @@ static struct lp872x_platform_data
> >   	of_property_read_u8(np, "ti,dvs-state", &dvs_state);
> >   	pdata->dvs->init_state = dvs_state ? DVS_HIGH : DVS_LOW;
> >
> > +	pdata->enable_gpio = of_get_named_gpio(np, "ti,enable-gpio", 0);
> > +
> 
> Please replace "ti,enable-gpio" with "enable-gpios".
> 
> Best regards,
> Milo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160205/61f2595c/attachment.sig>

From srinivas.kandagatla at linaro.org  Fri Feb  5 11:00:19 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Fri,  5 Feb 2016 19:00:19 +0000
Subject: [PATCH 0/6] arm64: dts: apq8016 dt patches.
Message-ID: <1454698819-13885-1-git-send-email-srinivas.kandagatla@linaro.org>

Hi Andy, 

Here are few more dt patches which enables usb and lpass.
I have tested these patches with few changes to defconfig on DB410C.

Thanks,
srini


Srinivas Kandagatla (6):
  arm64: dts: qcom: add manual pullup setting to otg.
  arm64: dts: qcom: apq8016-sbc: add usb support
  arm64: dts: qcom: add audio pinctrls
  arm64: dts: qcom: add lpass node
  arm64: dts: qcom: apq8016-sbc: enable lpass on DB410c
  arm64: dts: qcom: fix usb digital voltage levels

 arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi |  15 ++
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi          |  39 ++++
 arch/arm64/boot/dts/qcom/msm8916-pins.dtsi         | 216 +++++++++++++++++++++
 arch/arm64/boot/dts/qcom/msm8916.dtsi              |  29 ++-
 4 files changed, 298 insertions(+), 1 deletion(-)

-- 
1.9.1



From srinivas.kandagatla at linaro.org  Fri Feb  5 11:00:47 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Fri,  5 Feb 2016 19:00:47 +0000
Subject: [PATCH 1/6] arm64: dts: qcom: add manual pullup setting to otg.
In-Reply-To: <1454698819-13885-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1454698819-13885-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1454698847-13929-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds manual pull up setting for usb otg indicating that the
vbus is vbus is not routed to USB controller/phy therefore enables
pull-up explicitly before starting controller.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index ff7ca44..c1592d4 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -399,6 +399,7 @@
 			qcom,phy-init-sequence = <0x44 0x6B 0x24 0x13>;
 			dr_mode = "peripheral";
 			qcom,otg-control = <2>; // PMIC
+			qcom,manual-pullup;
 
 			clocks = <&gcc GCC_USB_HS_AHB_CLK>,
 				 <&gcc GCC_USB_HS_SYSTEM_CLK>,
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Fri Feb  5 11:01:20 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Fri,  5 Feb 2016 19:01:20 +0000
Subject: [PATCH 2/6] arm64: dts: qcom: apq8016-sbc: add usb support
In-Reply-To: <1454698819-13885-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1454698819-13885-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1454698880-13973-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds usb otg support on DB410C.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi | 15 ++++++++++
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi          | 35 ++++++++++++++++++++++
 2 files changed, 50 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
index cbeee0b..4a79dd9 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
@@ -10,4 +10,19 @@
 			output-low;
 		};
 	};
+
+	usb_id_default: usb_id_default {
+		pinmux {
+			function = "gpio";
+			pins = "gpio121";
+		};
+
+		pinconf {
+			pins = "gpio121";
+			function = "gpio";
+			drive-strength = <8>;
+			input-enable;
+			bias-pull-up;
+		};
+	};
 };
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 9a6c595..e80bdc2 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -151,6 +151,41 @@
 			cd-gpios = <&msmgpio 38 0x1>;
 			status = "okay";
 		};
+
+		usb at 78d9000 {
+			extcon = <&usb_id>, <&usb_id>;
+			status = "okay";
+		};
+
+		usb2513 {
+			compatible = "smsc,usb3503";
+			reset-gpios = <&pm8916_gpios 3 GPIO_ACTIVE_LOW>;
+			initial-mode = <1>;
+		};
+
+		usb_id: usb-id {
+			interrupt-parent = <&msmgpio>;
+			compatible = "linux,extcon-usb-gpio";
+			id-gpio = <&msmgpio 121 GPIO_ACTIVE_HIGH>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&usb_id_default>;
+		};
+
+		ehci at 78d9000 {
+			status = "okay";
+		};
+
+		phy at 78d9000 {
+			v1p8-supply = <&pm8916_l7>;
+			v3p3-supply = <&pm8916_l13>;
+			vddcx-supply = <&pm8916_s1>;
+			extcon = <&usb_id>, <&usb_id>;
+			dr_mode = "otg";
+			status = "okay";
+			switch-gpio = <&pm8916_gpios 4 GPIO_ACTIVE_HIGH>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&usb_sw_sel_pm>;
+		};
 	};
 };
 
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Fri Feb  5 11:01:29 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Fri,  5 Feb 2016 19:01:29 +0000
Subject: [PATCH 3/6] arm64: dts: qcom: add audio pinctrls
In-Reply-To: <1454698819-13885-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1454698819-13885-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1454698889-14015-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds pinctrls required for digital and analog audio via lpass.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 216 +++++++++++++++++++++++++++++
 1 file changed, 216 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index 8d05005..e9ea5ca 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -504,4 +504,220 @@
 			};
 		};
 	};
+
+	ext-codec-lines {
+		ext_codec_lines_act: lines_on {
+			pinmux {
+				function = "gpio";
+				pins = "gpio67";
+			};
+			pinconf {
+				pins = "gpio67";
+				drive-strength = <8>;
+				bias-disable;
+				output-high;
+			};
+		};
+		ext_codec_lines_sus: lines_off {
+			pinmux {
+				function = "gpio";
+				pins = "gpio67";
+			};
+			pinconf {
+				pins = "gpio67";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	cdc-pdm-lines {
+		cdc_pdm_lines_act: pdm_lines_on {
+			pinmux {
+				function = "cdc_pdm0";
+				pins = "gpio63", "gpio64", "gpio65", "gpio66",
+				       "gpio67", "gpio68";
+			};
+			pinconf {
+				pins = "gpio63", "gpio64", "gpio65", "gpio66",
+				       "gpio67", "gpio68";
+				drive-strength = <8>;
+				bias-pull-none;
+			};
+		};
+		cdc_pdm_lines_sus: pdm_lines_off {
+			pinmux {
+				function = "cdc_pdm0";
+				pins = "gpio63", "gpio64", "gpio65", "gpio66",
+				       "gpio67", "gpio68";
+			};
+			pinconf {
+				pins = "gpio63", "gpio64", "gpio65", "gpio66",
+				       "gpio67", "gpio68";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	ext-pri-tlmm-lines {
+		ext_pri_tlmm_lines_act: ext_pa_on {
+			pinmux {
+				function = "pri_mi2s";
+				pins = "gpio113", "gpio114", "gpio115",
+				       "gpio116";
+			};
+			pinconf {
+				pins = "gpio113", "gpio114", "gpio115",
+				       "gpio116";
+				drive-strength = <8>;
+				bias-pull-none;
+			};
+		};
+
+		ext_pri_tlmm_lines_sus: ext_pa_off {
+			pinmux {
+				function = "pri_mi2s";
+				pins = "gpio113", "gpio114", "gpio115",
+				       "gpio116";
+			};
+			pinconf {
+				pins = "gpio113", "gpio114", "gpio115",
+				       "gpio116";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	ext-pri-ws-line {
+		ext_pri_ws_act: ext_pa_on {
+			pinmux {
+				function = "pri_mi2s_ws";
+				pins = "gpio110";
+			};
+			pinconf {
+				pins = "gpio110";
+				drive-strength = <8>;
+				bias-pull-none;
+			};
+		};
+
+		ext_pri_ws_sus: ext_pa_off {
+			pinmux {
+				function = "pri_mi2s_ws";
+				pins = "gpio110";
+			};
+			pinconf {
+				pins = "gpio110";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	ext-mclk-tlmm-lines {
+		ext_mclk_tlmm_lines_act: mclk_lines_on {
+			pinmux {
+				function = "pri_mi2s";
+				pins = "gpio116";
+			};
+			pinconf {
+				pins = "gpio116";
+				drive-strength = <8>;
+				bias-pull-none;
+			};
+		};
+		ext_mclk_tlmm_lines_sus: mclk_lines_off {
+			pinmux {
+				function = "pri_mi2s";
+				pins = "gpio116";
+			};
+			pinconf {
+				pins = "gpio116";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	/* secondary Mi2S */
+	ext-sec-tlmm-lines {
+		ext_sec_tlmm_lines_act: tlmm_lines_on {
+			pinmux {
+				function = "sec_mi2s";
+				pins = "gpio112", "gpio117", "gpio118",
+				       "gpio119";
+			};
+			pinconf {
+				pins = "gpio112", "gpio117", "gpio118",
+					"gpio119";
+				drive-strength = <8>;
+				bias-pull-none;
+			};
+		};
+		ext_sec_tlmm_lines_sus: tlmm_lines_off {
+			pinmux {
+				function = "sec_mi2s";
+				pins = "gpio112", "gpio117", "gpio118",
+				       "gpio119";
+			};
+			pinconf {
+				pins = "gpio112", "gpio117", "gpio118",
+					"gpio119";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	cdc-dmic-lines {
+		cdc_dmic_lines_act: dmic_lines_on {
+			pinmux_dmic0_clk {
+				function = "dmic0_clk";
+				pins = "gpio0";
+			};
+			pinmux_dmic0_data {
+				function = "dmic0_data";
+				pins = "gpio1";
+			};
+			pinconf {
+				pins = "gpio0", "gpio1";
+				drive-strength = <8>;
+			};
+		};
+		cdc_dmic_lines_sus: dmic_lines_off {
+			pinconf {
+				pins = "gpio0", "gpio1";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	cross-conn-det {
+		cross_conn_det_act: lines_on {
+			pinmux {
+				function = "gpio";
+				pins = "gpio120";
+			};
+			pinconf {
+				pins = "gpio120";
+				drive-strength = <8>;
+				output-low;
+				bias-pull-down;
+			};
+		};
+		cross_conn_det_sus: lines_off {
+			pinmux {
+				function = "gpio";
+				pins = "gpio120";
+			};
+			pinconf {
+				pins = "gpio120";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
 };
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Fri Feb  5 11:01:36 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Fri,  5 Feb 2016 19:01:36 +0000
Subject: [PATCH 4/6] arm64: dts: qcom: add lpass node
In-Reply-To: <1454698819-13885-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1454698819-13885-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1454698896-14058-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds lpass node to the SOC.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index c1592d4..cdda026 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -343,6 +343,32 @@
 			status = "disabled";
 		};
 
+		lpass: lpass at 07700000 {
+			status = "disabled";
+			compatible = "qcom,lpass-cpu-apq8016";
+			clocks = <&gcc GCC_ULTAUDIO_AHBFABRIC_IXFABRIC_CLK>,
+				 <&gcc GCC_ULTAUDIO_PCNOC_MPORT_CLK>,
+				 <&gcc GCC_ULTAUDIO_PCNOC_SWAY_CLK>,
+				 <&gcc GCC_ULTAUDIO_LPAIF_PRI_I2S_CLK>,
+				 <&gcc GCC_ULTAUDIO_LPAIF_SEC_I2S_CLK>,
+				 <&gcc GCC_ULTAUDIO_LPAIF_SEC_I2S_CLK>,
+				 <&gcc GCC_ULTAUDIO_LPAIF_AUX_I2S_CLK>;
+
+			clock-names = "ahbix-clk",
+					"pcnoc-mport-clk",
+					"pcnoc-sway-clk",
+					"mi2s-bit-clk0",
+					"mi2s-bit-clk1",
+					"mi2s-bit-clk2",
+					"mi2s-bit-clk3";
+			#sound-dai-cells = <1>;
+
+			interrupts = <0 160 0>;
+			interrupt-names = "lpass-irq-lpaif";
+			reg = <0x07708000 0x10000>;
+			reg-names = "lpass-lpaif";
+		};
+
 		sdhc_1: sdhci at 07824000 {
 			compatible = "qcom,sdhci-msm-v4";
 			reg = <0x07824900 0x11c>, <0x07824000 0x800>;
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Fri Feb  5 11:01:44 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Fri,  5 Feb 2016 19:01:44 +0000
Subject: [PATCH 5/6] arm64: dts: qcom: apq8016-sbc: enable lpass on DB410c
In-Reply-To: <1454698819-13885-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1454698819-13885-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1454698904-14100-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch enables the lpass on DB410C. LPASS is used as cpu dai for
both analog and digital audio.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index e80bdc2..cb52afb 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -186,6 +186,10 @@
 			pinctrl-names = "default";
 			pinctrl-0 = <&usb_sw_sel_pm>;
 		};
+
+		lpass at 07700000 {
+			status = "okay";
+		};
 	};
 };
 
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Fri Feb  5 11:01:50 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Fri,  5 Feb 2016 19:01:50 +0000
Subject: [PATCH 6/6] arm64: dts: qcom: fix usb digital voltage levels
In-Reply-To: <1454698819-13885-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1454698819-13885-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1454698910-14142-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch updates the digital voltage levels from corner values to
microvolts as we are going to use s1 regulator directly for vddcx
instead of s1_corner.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index cdda026..cb82f4f 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -421,7 +421,7 @@
 			interrupts = <GIC_SPI 134 IRQ_TYPE_EDGE_BOTH>,
 				     <GIC_SPI 140 IRQ_TYPE_EDGE_RISING>;
 
-			qcom,vdd-levels = <1 5 7>;
+			qcom,vdd-levels = <500000 1000000 1320000>;
 			qcom,phy-init-sequence = <0x44 0x6B 0x24 0x13>;
 			dr_mode = "peripheral";
 			qcom,otg-control = <2>; // PMIC
-- 
1.9.1



From tony at atomide.com  Fri Feb  5 11:10:42 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 5 Feb 2016 11:10:42 -0800
Subject: PM regression with commit 5de85b9d57ab PM runtime re-init in
 v4.5-rc1
In-Reply-To: <CAPDyKFoawbrj3w_+2p5ugjByrwxwmA1S2God1VAvkRbh2rUtjg@mail.gmail.com>
References: <CAPDyKFpRnmn+h_VH3jtC3u-BOf7-00nbzD30omaxaaZOOAK8Gg@mail.gmail.com>
 <Pine.LNX.4.44L0.1602041702550.1515-100000@iolanthe.rowland.org>
 <CAPDyKFrMZYdeun67FBXdWL16DBOuO16qqOxRsks3QBJhNB8SoQ@mail.gmail.com>
 <20160205010810.GR19432@atomide.com>
 <CAPDyKFoawbrj3w_+2p5ugjByrwxwmA1S2God1VAvkRbh2rUtjg@mail.gmail.com>
Message-ID: <20160205191042.GT19432@atomide.com>

* Ulf Hansson <ulf.hansson at linaro.org> [160204 22:55]:
> On 5 February 2016 at 02:08, Tony Lindgren <tony at atomide.com> wrote:
> > * Ulf Hansson <ulf.hansson at linaro.org> [160204 14:35]:
> >> On 4 February 2016 at 23:09, Alan Stern <stern at rowland.harvard.edu> wrote:
> >> > On Thu, 4 Feb 2016, Ulf Hansson wrote:
> >> >
> >> >> I am really not questioning the autosuspend feature at all, it's a
> >> >> really great feature!
> >> >>
> >> >> Now, I question the minor benefit we actually gain from having the
> >> >> runtime PM core to update the mark in rpm_resume().
> >> >
> >> > As Tony pointed out, it prevents some devices from going to sleep right
> >> > away.
> >>
> >> Because their drivers don't care to update the last busy mark!?
> >
> > Nope. Without that devices may never resume at all so the drivers
> > can't do anything about it.
> 
> I don't get it. Why not? Because of another abuse of the runtime PM API?

I think you should be able to test this case in your test driver by
calling pm_runtime_resume() for your test driver after your
test drive has autosuspended. Probably you need some delayed_work to
do this in your test driver unless you have some test bus to go with it.

> Or we should probably continue to focus on fixing the regression. :-)

Naturally we should fix up things yeah :) Having a test driver
that works on any architecture sure makes things easier to verify.

Regards,

Tony


From tbaicar at codeaurora.org  Fri Feb  5 11:13:22 2016
From: tbaicar at codeaurora.org (Tyler Baicar)
Date: Fri,  5 Feb 2016 12:13:22 -0700
Subject: [PATCH V1 0/6] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64
Message-ID: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>

Add support for Generic Hardware Error Source (GHES) v2, which introduces the
capability for the OS to acknowledge the consumption of the error record
generated by the Reliability, Availability and Serviceability (RAS) controller.
This eliminates potential race conditions between the OS and the RAS controller.

Add support for the timestamp field added to the Generic Error Data Entry v3,
allowing the OS to log the time that the error is generated by the firmware,
rather than the time the error is consumed. This improves the correctness of
event sequences when analyzing error logs. The timestamp is added in
ACPI 6.1, reference Table 18-343 Generic Error Data Entry.

Add support for ARMv8 Common Platform Error Record (CPER) per UEFI 2.6
specification. ARMv8 specific processor error information is reported as part of
the CPER records.  This provides more detail on for processor error logs.

Synchronous External Abort (SEA) represents a specific processor error condition
in ARM systems. A handler is added to recognize SEA errors, and a notifier is
added to parse and report the errors before the process is killed. Refer to
section N.2.1.1 in the Common Platform Error Record appendix of the UEFI 2.6
specification.

Depends on: [PATCH v5] acpi, apei, arm64: APEI initial support for aarch64.
            https://lkml.org/lkml/2015/12/10/131

Tyler Baicar (6):
  acpi: apei: read ack upon ghes record consumption
  ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1
  efi: parse ARMv8 processor error
  arm64: exception: handle Synchronous External Abort
  arm64: exception: handle instruction abort at current EL
  acpi: apei: handle SEA notification type for ARMv8

 arch/arm64/Kconfig                   |   1 +
 arch/arm64/include/asm/system_misc.h |  13 ++
 arch/arm64/kernel/entry.S            |  19 +++
 arch/arm64/mm/fault.c                |  58 +++++++--
 drivers/acpi/apei/Kconfig            |  13 ++
 drivers/acpi/apei/ghes.c             | 159 ++++++++++++++++++++++-
 drivers/acpi/apei/hest.c             |   7 +-
 drivers/firmware/efi/cper.c          | 244 ++++++++++++++++++++++++++++++++---
 include/acpi/actbl1.h                |  46 ++++++-
 include/acpi/ghes.h                  |   1 +
 include/linux/cper.h                 |  72 +++++++++++
 11 files changed, 599 insertions(+), 34 deletions(-)

-- 
1.8.2.1



From tbaicar at codeaurora.org  Fri Feb  5 11:13:23 2016
From: tbaicar at codeaurora.org (Tyler Baicar)
Date: Fri,  5 Feb 2016 12:13:23 -0700
Subject: [PATCH V1 1/6] acpi: apei: read ack upon ghes record consumption
In-Reply-To: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
References: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
Message-ID: <1454699608-22760-2-git-send-email-tbaicar@codeaurora.org>

A RAS (Reliability, Availability, Serviceability) controller
may be a separate processor running in parallel with OS
execution, and may generate error records for consumption by
the OS. If the RAS controller produces multiple error records,
then they may be overwritten before the OS has consumed them.

The Generic Hardware Error Source (GHES) v2 structure
introduces the capability for the OS to acknowledge the
consumption of the error record generated by the RAS
controller. A RAS controller supporting GHESv2 shall wait for
the acknowledgment before writing a new error record, thus
eliminating the race condition.

Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang at codeaurora.org>
Signed-off-by: Richard Ruigrok <rruigrok at codeaurora.org>
Signed-off-by: Tyler Baicar <tbaicar at codeaurora.org>
Signed-off-by: Naveen Kaje <nkaje at codeaurora.org>
---
 drivers/acpi/apei/ghes.c | 41 +++++++++++++++++++++++++++++++++++++++++
 drivers/acpi/apei/hest.c |  7 +++++--
 include/acpi/actbl1.h    | 21 ++++++++++++++++++++-
 include/acpi/ghes.h      |  1 +
 4 files changed, 67 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 3dd9c46..db67711 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -45,6 +45,7 @@
 #include <linux/aer.h>
 #include <linux/nmi.h>
 
+#include <acpi/actbl1.h>
 #include <acpi/ghes.h>
 #include <acpi/apei.h>
 #include <asm/tlbflush.h>
@@ -239,10 +240,22 @@ static struct ghes *ghes_new(struct acpi_hest_generic *generic)
 	struct ghes *ghes;
 	unsigned int error_block_length;
 	int rc;
+	struct acpi_hest_header *hest_hdr;
 
 	ghes = kzalloc(sizeof(*ghes), GFP_KERNEL);
 	if (!ghes)
 		return ERR_PTR(-ENOMEM);
+
+	hest_hdr = (struct acpi_hest_header *)generic;
+	if (hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR_V2) {
+		ghes->generic_v2 = (struct acpi_hest_generic_v2 *)generic;
+		rc = apei_map_generic_address(
+			&ghes->generic_v2->read_ack_reg_address);
+		if (rc)
+			goto err_unmap;
+	} else
+		ghes->generic_v2 = NULL;
+
 	ghes->generic = generic;
 	rc = apei_map_generic_address(&generic->error_status_address);
 	if (rc)
@@ -265,6 +278,9 @@ static struct ghes *ghes_new(struct acpi_hest_generic *generic)
 
 err_unmap:
 	apei_unmap_generic_address(&generic->error_status_address);
+	if (ghes->generic_v2)
+		apei_unmap_generic_address(
+			&ghes->generic_v2->read_ack_reg_address);
 err_free:
 	kfree(ghes);
 	return ERR_PTR(rc);
@@ -274,6 +290,9 @@ static void ghes_fini(struct ghes *ghes)
 {
 	kfree(ghes->estatus);
 	apei_unmap_generic_address(&ghes->generic->error_status_address);
+	if (ghes->generic_v2)
+		apei_unmap_generic_address(
+			&ghes->generic_v2->error_status_address);
 }
 
 static inline int ghes_severity(int severity)
@@ -643,6 +662,22 @@ static void ghes_estatus_cache_add(
 	rcu_read_unlock();
 }
 
+static int ghes_do_read_ack(struct acpi_hest_generic_v2 *generic_v2)
+{
+	int rc;
+	u64 val = 0;
+
+	rc = apei_read(&val, &generic_v2->read_ack_reg_address);
+	if (rc)
+		return rc;
+	val &= generic_v2->read_ack_preserve <<
+		generic_v2->read_ack_reg_address.bit_offset;
+	val |= generic_v2->read_ack_write;
+	rc = apei_write(val, &generic_v2->read_ack_reg_address);
+
+	return rc;
+}
+
 static int ghes_proc(struct ghes *ghes)
 {
 	int rc;
@@ -655,6 +690,12 @@ static int ghes_proc(struct ghes *ghes)
 			ghes_estatus_cache_add(ghes->generic, ghes->estatus);
 	}
 	ghes_do_proc(ghes, ghes->estatus);
+
+	if (ghes->generic_v2) {
+		rc = ghes_do_read_ack(ghes->generic_v2);
+		if (rc)
+			return rc;
+	}
 out:
 	ghes_clear_estatus(ghes);
 	return 0;
diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
index c708c95..ae43468 100644
--- a/drivers/acpi/apei/hest.c
+++ b/drivers/acpi/apei/hest.c
@@ -52,6 +52,7 @@ static const int hest_esrc_len_tab[ACPI_HEST_TYPE_RESERVED] = {
 	[ACPI_HEST_TYPE_AER_ENDPOINT] = sizeof(struct acpi_hest_aer),
 	[ACPI_HEST_TYPE_AER_BRIDGE] = sizeof(struct acpi_hest_aer_bridge),
 	[ACPI_HEST_TYPE_GENERIC_ERROR] = sizeof(struct acpi_hest_generic),
+	[ACPI_HEST_TYPE_GENERIC_ERROR_V2] = sizeof(struct acpi_hest_generic_v2),
 };
 
 static int hest_esrc_len(struct acpi_hest_header *hest_hdr)
@@ -147,7 +148,8 @@ static int __init hest_parse_ghes_count(struct acpi_hest_header *hest_hdr, void
 {
 	int *count = data;
 
-	if (hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR)
+	if (hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR ||
+	    hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR_V2)
 		(*count)++;
 	return 0;
 }
@@ -158,7 +160,8 @@ static int __init hest_parse_ghes(struct acpi_hest_header *hest_hdr, void *data)
 	struct ghes_arr *ghes_arr = data;
 	int rc, i;
 
-	if (hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR)
+	if (hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR &&
+	    hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR_V2)
 		return 0;
 
 	if (!((struct acpi_hest_generic *)hest_hdr)->enabled)
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 16e0136..82695c9 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -427,7 +427,8 @@ enum acpi_hest_types {
 	ACPI_HEST_TYPE_AER_ENDPOINT = 7,
 	ACPI_HEST_TYPE_AER_BRIDGE = 8,
 	ACPI_HEST_TYPE_GENERIC_ERROR = 9,
-	ACPI_HEST_TYPE_RESERVED = 10	/* 10 and greater are reserved */
+	ACPI_HEST_TYPE_GENERIC_ERROR_V2 = 10,
+	ACPI_HEST_TYPE_RESERVED = 11	/* 11 and greater are reserved */
 };
 
 /*
@@ -603,6 +604,24 @@ struct acpi_hest_generic {
 	u32 error_block_length;
 };
 
+/* 10: Generic Hardware Error Source V2*/
+
+struct acpi_hest_generic_v2 {
+	struct acpi_hest_header header;
+	u16 related_source_id;
+	u8 reserved;
+	u8 enabled;
+	u32 records_to_preallocate;
+	u32 max_sections_per_record;
+	u32 max_raw_data_length;
+	struct acpi_generic_address error_status_address;
+	struct acpi_hest_notify notify;
+	u32 error_block_length;
+	struct acpi_generic_address read_ack_reg_address;
+	u64 read_ack_preserve;
+	u64 read_ack_write;
+};
+
 /* Generic Error Status block */
 
 struct acpi_hest_generic_status {
diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
index 720446c..d0108b6 100644
--- a/include/acpi/ghes.h
+++ b/include/acpi/ghes.h
@@ -14,6 +14,7 @@
 
 struct ghes {
 	struct acpi_hest_generic *generic;
+	struct acpi_hest_generic_v2 *generic_v2;
 	struct acpi_hest_generic_status *estatus;
 	u64 buffer_paddr;
 	unsigned long flags;
-- 
1.8.2.1



From tbaicar at codeaurora.org  Fri Feb  5 11:13:24 2016
From: tbaicar at codeaurora.org (Tyler Baicar)
Date: Fri,  5 Feb 2016 12:13:24 -0700
Subject: [PATCH V1 2/6] ras: acpi/apei: cper: generic error data entry v3 per
 ACPI 6.1
In-Reply-To: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
References: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
Message-ID: <1454699608-22760-3-git-send-email-tbaicar@codeaurora.org>

Currently when a RAS error is reported it is not timestamped.
The ACPI 6.1 spec adds the timestamp field to the generic error
data entry v3 structure. The timestamp of when the firmware
generated the error is now being reported.

Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang at codeaurora.org>
Signed-off-by: Richard Ruigrok <rruigrok at codeaurora.org>
Signed-off-by: Tyler Baicar <tbaicar at codeaurora.org>
Signed-off-by: Naveen Kaje <nkaje at codeaurora.org>
---
 drivers/acpi/apei/ghes.c    |  35 ++++++++++++--
 drivers/firmware/efi/cper.c | 108 +++++++++++++++++++++++++++++++++++++-------
 include/acpi/actbl1.h       |  19 ++++++++
 3 files changed, 142 insertions(+), 20 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index db67711..6c68100 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -414,7 +414,15 @@ static void ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, int
 	int flags = -1;
 	int sec_sev = ghes_severity(gdata->error_severity);
 	struct cper_sec_mem_err *mem_err;
-	mem_err = (struct cper_sec_mem_err *)(gdata + 1);
+	struct acpi_hest_generic_data_v3 *gdata_v3 = NULL;
+
+	if ((gdata->revision >> 8) >= 0x03)
+		gdata_v3 = (struct acpi_hest_generic_data_v3 *)gdata;
+
+	if (gdata_v3)
+		mem_err = (struct cper_sec_mem_err *)(gdata_v3 + 1);
+	else
+		mem_err = (struct cper_sec_mem_err *)(gdata + 1);
 
 	if (!(mem_err->validation_bits & CPER_MEM_VALID_PA))
 		return;
@@ -444,14 +452,27 @@ static void ghes_do_proc(struct ghes *ghes,
 {
 	int sev, sec_sev;
 	struct acpi_hest_generic_data *gdata;
+	struct acpi_hest_generic_data_v3 *gdata_v3 = NULL;
+	uuid_le sec_type;
 
 	sev = ghes_severity(estatus->error_severity);
 	apei_estatus_for_each_section(estatus, gdata) {
 		sec_sev = ghes_severity(gdata->error_severity);
-		if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
+		sec_type = *(uuid_le *)gdata->section_type;
+
+		if ((gdata->revision >> 8) >= 0x03)
+			gdata_v3 = (struct acpi_hest_generic_data_v3 *)gdata;
+
+		if (!uuid_le_cmp(sec_type,
 				 CPER_SEC_PLATFORM_MEM)) {
 			struct cper_sec_mem_err *mem_err;
-			mem_err = (struct cper_sec_mem_err *)(gdata+1);
+
+			if (gdata_v3)
+				mem_err = (struct cper_sec_mem_err *)
+					  (gdata_v3 + 1);
+			else
+				mem_err = (struct cper_sec_mem_err *)
+					  (gdata + 1);
 			ghes_edac_report_mem_error(ghes, sev, mem_err);
 
 			arch_apei_report_mem_error(sev, mem_err);
@@ -461,7 +482,13 @@ static void ghes_do_proc(struct ghes *ghes,
 		else if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
 				      CPER_SEC_PCIE)) {
 			struct cper_sec_pcie *pcie_err;
-			pcie_err = (struct cper_sec_pcie *)(gdata+1);
+
+			if (gdata_v3)
+				pcie_err = (struct cper_sec_pcie *)
+					   (gdata_v3 + 1);
+			else
+				pcie_err = (struct cper_sec_pcie *)
+					   (gdata + 1);
 			if (sev == GHES_SEV_RECOVERABLE &&
 			    sec_sev == GHES_SEV_RECOVERABLE &&
 			    pcie_err->validation_bits & CPER_PCIE_VALID_DEVICE_ID &&
diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index d425374..accd351 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -32,6 +32,8 @@
 #include <linux/acpi.h>
 #include <linux/pci.h>
 #include <linux/aer.h>
+#include <linux/printk.h>
+#include <linux/bcd.h>
 
 #define INDENT_SP	" "
 
@@ -392,6 +394,10 @@ static void cper_estatus_print_section(
 	uuid_le *sec_type = (uuid_le *)gdata->section_type;
 	__u16 severity;
 	char newpfx[64];
+	struct acpi_hest_generic_data_v3 *gdata_v3 = NULL;
+
+	if ((gdata->revision >> 8) >= 0x03)
+		gdata_v3 = (struct acpi_hest_generic_data_v3 *)gdata;
 
 	severity = gdata->error_severity;
 	printk("%s""Error %d, type: %s\n", pfx, sec_no,
@@ -403,14 +409,24 @@ static void cper_estatus_print_section(
 
 	snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
 	if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_GENERIC)) {
-		struct cper_sec_proc_generic *proc_err = (void *)(gdata + 1);
+		struct cper_sec_proc_generic *proc_err;
+
+		if (gdata_v3)
+			proc_err = (void *)(gdata_v3 + 1);
+		else
+			proc_err = (void *)(gdata + 1);
 		printk("%s""section_type: general processor error\n", newpfx);
 		if (gdata->error_data_length >= sizeof(*proc_err))
 			cper_print_proc_generic(newpfx, proc_err);
 		else
 			goto err_section_too_small;
 	} else if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
-		struct cper_sec_mem_err *mem_err = (void *)(gdata + 1);
+		struct cper_sec_mem_err *mem_err;
+
+		if (gdata_v3)
+			mem_err = (void *)(gdata_v3 + 1);
+		else
+			mem_err = (void *)(gdata + 1);
 		printk("%s""section_type: memory error\n", newpfx);
 		if (gdata->error_data_length >=
 		    sizeof(struct cper_sec_mem_err_old))
@@ -419,7 +435,12 @@ static void cper_estatus_print_section(
 		else
 			goto err_section_too_small;
 	} else if (!uuid_le_cmp(*sec_type, CPER_SEC_PCIE)) {
-		struct cper_sec_pcie *pcie = (void *)(gdata + 1);
+		struct cper_sec_pcie *pcie;
+
+		if (gdata_v3)
+			pcie = (void *)(gdata_v3 + 1);
+		else
+			pcie = (void *)(gdata + 1);
 		printk("%s""section_type: PCIe error\n", newpfx);
 		if (gdata->error_data_length >= sizeof(*pcie))
 			cper_print_pcie(newpfx, pcie, gdata);
@@ -434,10 +455,36 @@ err_section_too_small:
 	pr_err(FW_WARN "error section length is too small\n");
 }
 
+static void cper_estatus_print_section_v3(const char *pfx,
+	const struct acpi_hest_generic_data_v3 *gdata, int sec_no)
+{
+	__u8 hour, min, sec, day, mon, *timestamp;
+	__u16 year;
+
+		if (gdata->gdata_v2.validation_bits & GED_VALID_TIMESTAMP) {
+			timestamp = (__u8 *)&(gdata->timestamp);
+			memcpy(&sec, timestamp, 1);
+			memcpy(&min, timestamp + 1, 1);
+			memcpy(&hour, timestamp + 2, 1);
+			memcpy(&day, timestamp + 4, 1);
+			memcpy(&mon, timestamp + 5, 1);
+			memcpy(&year, timestamp + 6, 2);
+			printk("%stime: ", pfx);
+			printk("%7s", 0x01 & *(timestamp + 3) ? "precise" : "");
+			printk(" %02d:%02d:%02d %04d-%02d-%02d\n",
+				bcd2bin(hour), bcd2bin(min), bcd2bin(sec),
+				year, bcd2bin(mon),
+				bcd2bin(day));
+		}
+
+	cper_estatus_print_section(pfx, &(gdata->gdata_v2), sec_no);
+}
+
 void cper_estatus_print(const char *pfx,
 			const struct acpi_hest_generic_status *estatus)
 {
 	struct acpi_hest_generic_data *gdata;
+	struct acpi_hest_generic_data_v3 *gdata_v3 = NULL;
 	unsigned int data_len, gedata_len;
 	int sec_no = 0;
 	char newpfx[64];
@@ -451,13 +498,27 @@ void cper_estatus_print(const char *pfx,
 	printk("%s""event severity: %s\n", pfx, cper_severity_str(severity));
 	data_len = estatus->data_length;
 	gdata = (struct acpi_hest_generic_data *)(estatus + 1);
+	if ((gdata->revision >> 8) >= 0x03)
+		gdata_v3 = (struct acpi_hest_generic_data_v3 *)gdata;
+
 	snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
-	while (data_len >= sizeof(*gdata)) {
-		gedata_len = gdata->error_data_length;
-		cper_estatus_print_section(newpfx, gdata, sec_no);
-		data_len -= gedata_len + sizeof(*gdata);
-		gdata = (void *)(gdata + 1) + gedata_len;
-		sec_no++;
+
+	if (gdata_v3) {
+		while (data_len >= sizeof(*gdata_v3)) {
+			gedata_len = gdata_v3->gdata_v2.error_data_length;
+			cper_estatus_print_section_v3(newpfx, gdata_v3, sec_no);
+			data_len -= gedata_len + sizeof(*gdata_v3);
+			gdata_v3 = (void *)(gdata_v3 + 1) + gedata_len;
+			sec_no++;
+		}
+	} else {
+		while (data_len >= sizeof(*gdata)) {
+			gedata_len = gdata->error_data_length;
+			cper_estatus_print_section(newpfx, gdata, sec_no);
+			data_len -= gedata_len + sizeof(*gdata);
+			gdata = (void *)(gdata + 1) + gedata_len;
+			sec_no++;
+		}
 	}
 }
 EXPORT_SYMBOL_GPL(cper_estatus_print);
@@ -478,6 +539,7 @@ EXPORT_SYMBOL_GPL(cper_estatus_check_header);
 int cper_estatus_check(const struct acpi_hest_generic_status *estatus)
 {
 	struct acpi_hest_generic_data *gdata;
+	struct acpi_hest_generic_data_v3 *gdata_v3 = NULL;
 	unsigned int data_len, gedata_len;
 	int rc;
 
@@ -486,15 +548,29 @@ int cper_estatus_check(const struct acpi_hest_generic_status *estatus)
 		return rc;
 	data_len = estatus->data_length;
 	gdata = (struct acpi_hest_generic_data *)(estatus + 1);
-	while (data_len >= sizeof(*gdata)) {
-		gedata_len = gdata->error_data_length;
-		if (gedata_len > data_len - sizeof(*gdata))
+
+	if ((gdata->revision >> 8) >= 0x03) {
+		gdata_v3 = (struct acpi_hest_generic_data_v3 *)gdata;
+		while (data_len >= sizeof(*gdata_v3)) {
+			gedata_len = gdata_v3->gdata_v2.error_data_length;
+			if (gedata_len > data_len - sizeof(*gdata_v3))
+				return -EINVAL;
+			data_len -= gedata_len + sizeof(*gdata_v3);
+			gdata_v3 = (void *)(gdata_v3 + 1) + gedata_len;
+		}
+		if (data_len)
+			return -EINVAL;
+	} else {
+		while (data_len >= sizeof(*gdata)) {
+			gedata_len = gdata->error_data_length;
+			if (gedata_len > data_len - sizeof(*gdata))
+				return -EINVAL;
+			data_len -= gedata_len + sizeof(*gdata);
+			gdata = (void *)(gdata + 1) + gedata_len;
+		}
+		if (data_len)
 			return -EINVAL;
-		data_len -= gedata_len + sizeof(*gdata);
-		gdata = (void *)(gdata + 1) + gedata_len;
 	}
-	if (data_len)
-		return -EINVAL;
 
 	return 0;
 }
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 82695c9..231ae1e 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -653,6 +653,25 @@ struct acpi_hest_generic_data {
 	u8 fru_text[20];
 };
 
+/* Generic Error Data entry version 3 as defined by ACPI 6.1 spec */
+
+struct acpi_hest_generic_data_v3 {
+	struct acpi_hest_generic_data gdata_v2;
+	__u64                         timestamp;
+};
+
+/*
+ * Validation bits definition for validation_bits in struct
+ * acpi_hest_generic_data[_v3]. If set, corresponding fields in
+ * the struct contain valid information.
+ */
+/* corresponds fru_id */
+#define GED_VALID_FRU_ID                  0x0001
+/* corresponds fru_text */
+#define GED_VALID_FRU_TEXT                0x0002
+/* corresponds timestamp */
+#define GED_VALID_TIMESTAMP               0x0004
+
 /*******************************************************************************
  *
  * MADT - Multiple APIC Description Table
-- 
1.8.2.1



From tbaicar at codeaurora.org  Fri Feb  5 11:13:25 2016
From: tbaicar at codeaurora.org (Tyler Baicar)
Date: Fri,  5 Feb 2016 12:13:25 -0700
Subject: [PATCH V1 3/6] efi: parse ARMv8 processor error
In-Reply-To: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
References: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
Message-ID: <1454699608-22760-4-git-send-email-tbaicar@codeaurora.org>

Add support for ARMv8 Common Platform Error Record (CPER).
UEFI 2.6 specification adds support for ARMv8 specific
processor error information to be reported as part of the
CPER records. This provides more detail on for processor error logs.

Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang at codeaurora.org>
Signed-off-by: Tyler Baicar <tbaicar at codeaurora.org>
Signed-off-by: Naveen Kaje <nkaje at codeaurora.org>
---
 drivers/firmware/efi/cper.c | 136 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/cper.h        |  72 +++++++++++++++++++++++
 2 files changed, 208 insertions(+)

diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index accd351..ca803fc 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -109,12 +109,15 @@ void cper_print_bits(const char *pfx, unsigned int bits,
 static const char * const proc_type_strs[] = {
 	"IA32/X64",
 	"IA64",
+	"ARMv8",
 };
 
 static const char * const proc_isa_strs[] = {
 	"IA32",
 	"IA64",
 	"X64",
+	"ARM A32/T32",
+	"ARM A64",
 };
 
 static const char * const proc_error_type_strs[] = {
@@ -183,6 +186,127 @@ static void cper_print_proc_generic(const char *pfx,
 		printk("%s""IP: 0x%016llx\n", pfx, proc->ip);
 }
 
+static void cper_print_proc_armv8(const char *pfx,
+				  const struct cper_sec_proc_armv8 *proc)
+{
+	int i, len;
+	struct cper_armv8_err_info *err_info;
+	__u64 *qword = NULL;
+	char newpfx[64];
+
+	printk("%ssection length: %d\n", pfx, proc->section_length);
+	printk("%sMIDR: 0x%016llx\n", pfx, proc->midr);
+
+	len = proc->section_length - (sizeof(*proc) +
+		proc->err_info_num * (sizeof(*err_info)));
+	if (len < 0) {
+		printk("%ssection length is too small.\n", pfx);
+		printk("%sERR_INFO_NUM is %d.\n", pfx, proc->err_info_num);
+		return;
+	}
+
+	if (proc->validation_bits & CPER_ARMV8_VALID_MPIDR)
+		printk("%sMPIDR: 0x%016llx\n", pfx, proc->mpidr);
+	if (proc->validation_bits & CPER_ARMV8_VALID_AFFINITY_LEVEL)
+		printk("%serror affinity level: %d\n", pfx,
+			proc->affinity_level);
+	if (proc->validation_bits & CPER_ARMV8_VALID_RUNNING_STATE)
+		printk("%srunning state: %d\n", pfx, proc->running_state);
+
+	snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
+
+	err_info = (struct cper_armv8_err_info *)(proc + 1);
+	for (i = 0; i < proc->err_info_num; i++) {
+		printk("%sError info structure %d:\n", pfx, i);
+		printk("%sversion:%d\n", newpfx, err_info->version);
+		printk("%slength:%d\n", newpfx, err_info->length);
+		if (err_info->validation_bits &
+		    CPER_ARMV8_INFO_VALID_MULTI_ERR) {
+			if (err_info->multiple_error == 0)
+				printk("%ssingle error.\n", newpfx);
+			else if (err_info->multiple_error == 1)
+				printk("%smultiple errors.\n", newpfx);
+			else
+				printk("%smultiple errors count:%d.\n",
+				newpfx, err_info->multiple_error);
+		}
+		if (err_info->validation_bits & CPER_ARMV8_INFO_VALID_FLAGS) {
+			if (err_info->flags & CPER_ARMV8_INFO_FLAGS_FIRST)
+				printk("%sfirst error captured.\n", newpfx);
+			if (err_info->flags & CPER_ARMV8_INFO_FLAGS_LAST)
+				printk("%slast error captured.\n", newpfx);
+			if (err_info->flags & CPER_ARMV8_INFO_FLAGS_PROPAGATED)
+				printk("%spropagated error captured.\n",
+				       newpfx);
+		}
+		printk("%serror_type: %d, %s\n", newpfx, err_info->type,
+			err_info->type < ARRAY_SIZE(proc_error_type_strs) ?
+			proc_error_type_strs[err_info->type] : "unknown");
+		printk("%serror_info: 0x%016llx\n", newpfx,
+		       err_info->error_info);
+		if (err_info->validation_bits & CPER_ARMV8_INFO_VALID_VIRT_ADDR)
+			printk("%svirtual fault address: 0x%016llx\n",
+				newpfx, err_info->virt_fault_addr);
+		if (err_info->validation_bits &
+		    CPER_ARMV8_INFO_VALID_PHYSICAL_ADDR)
+			printk("%sphysical fault address: 0x%016llx\n",
+				newpfx, err_info->physical_fault_addr);
+		err_info += 1;
+	}
+
+	if (len < sizeof(*qword) && proc->context_info_num > 0) {
+		printk("%ssection length is too small.\n", pfx);
+		printk("%sCTX_INFO_NUM is %d.\n", pfx, proc->context_info_num);
+		return;
+	}
+	for (i = 0; i < proc->context_info_num; i++) {
+		qword = (__u64 *)err_info;
+		printk("%sProcessor context info structure %d:\n", pfx, i);
+		printk("%sException level %d.\n", newpfx,
+		       (int)((*qword & CPER_ARMV8_CTX_EL_MASK)
+				>> CPER_ARMV8_CTX_EL_SHIFT));
+		printk("%sSecure bit: %d.\n", newpfx,
+		       (int)((*qword & CPER_ARMV8_CTX_NS_MASK)
+				>> CPER_ARMV8_CTX_NS_SHIFT));
+		if ((*qword & CPER_ARMV8_CTX_TYPE_MASK) == 0) {
+			if (len < CPER_AARCH32_CTX_LEN) {
+				printk("%ssection length is too small.\n", pfx);
+				printk("%sremaining length is %d.\n", pfx, len);
+				return;
+			}
+			printk("%sAArch32 execution context.\n", newpfx);
+			qword++;
+			print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4,
+				qword, CPER_AARCH32_CTX_LEN - sizeof(*qword),
+				0);
+			len -= CPER_AARCH32_CTX_LEN;
+		} else if ((*qword & CPER_ARMV8_CTX_TYPE_MASK) == 1) {
+			if (len < CPER_AARCH64_CTX_LEN) {
+				printk("%ssection length is too small.\n", pfx);
+				printk("%sremaining length is %d.\n", pfx, len);
+				return;
+			}
+			printk("%sAArch64 execution context.\n", newpfx);
+			qword++;
+			print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4,
+				qword, CPER_AARCH64_CTX_LEN - sizeof(*qword),
+				0);
+			len -= CPER_AARCH64_CTX_LEN;
+		} else {
+			printk("%scontext type is incorrect 0x%016llx.\n",
+			pfx, *qword);
+			return;
+		}
+	}
+
+	if (len > 0) {
+		printk("%sVendor specific error info has %d bytes.\n", pfx,
+		       len);
+		print_hex_dump(pfx, "", DUMP_PREFIX_OFFSET, 16, 4, qword, len,
+			0);
+	}
+}
+
 static const char * const mem_err_type_strs[] = {
 	"unknown",
 	"no error",
@@ -446,6 +570,18 @@ static void cper_estatus_print_section(
 			cper_print_pcie(newpfx, pcie, gdata);
 		else
 			goto err_section_too_small;
+	} else if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_ARMV8)) {
+		struct cper_sec_proc_armv8 *armv8_err;
+
+		if (gdata_v3)
+			armv8_err = (void *)(gdata_v3 + 1);
+		else
+			armv8_err = (void *)(gdata + 1);
+		printk("%ssection_type: ARMv8 processor error\n", newpfx);
+		if (gdata->error_data_length >= sizeof(*armv8_err))
+			cper_print_proc_armv8(newpfx, armv8_err);
+		else
+			goto err_section_too_small;
 	} else
 		printk("%s""section type: unknown, %pUl\n", newpfx, sec_type);
 
diff --git a/include/linux/cper.h b/include/linux/cper.h
index dcacb1a..d1efbef 100644
--- a/include/linux/cper.h
+++ b/include/linux/cper.h
@@ -162,6 +162,11 @@ enum {
  * corrective action before the data is consumed
  */
 #define CPER_SEC_LATENT_ERROR			0x0020
+/*
+ * If set, the section contains an error that is propagated. The error
+ * did not originate from the hardware associated with this section.
+ */
+#define CPER_SEC_PROPAGATED			0x0040
 
 /*
  * Section type definitions, used in section_type field in struct
@@ -180,6 +185,10 @@ enum {
 #define CPER_SEC_PROC_IPF						\
 	UUID_LE(0xE429FAF1, 0x3CB7, 0x11D4, 0x0B, 0xCA, 0x07, 0x00,	\
 		0x80, 0xC7, 0x3C, 0x88, 0x81)
+/* Processor Specific: ARMv8 */
+#define CPER_SEC_PROC_ARMV8						\
+	UUID_LE(0xE19E3D16, 0xBC11, 0x11E4, 0x9C, 0xAA, 0xC2, 0x05,	\
+		0x1D, 0x5D, 0x46, 0xB0)
 /* Platform Memory */
 #define CPER_SEC_PLATFORM_MEM						\
 	UUID_LE(0xA5BC1114, 0x6F64, 0x4EDE, 0xB8, 0x63, 0x3E, 0x83,	\
@@ -255,6 +264,34 @@ enum {
 
 #define CPER_PCIE_SLOT_SHIFT			3
 
+#define CPER_ARMV8_ERR_INFO_NUM_MASK		0x00000000000000FF
+#define CPER_ARMV8_CTX_INFO_NUM_MASK		0x0000000000FFFF00
+#define CPER_ARMV8_CTX_INFO_NUM_SHIFT		8
+
+#define CPER_ARMV8_VALID_MPIDR			0x00000001
+#define CPER_ARMV8_VALID_AFFINITY_LEVEL		0x00000002
+#define CPER_ARMV8_VALID_RUNNING_STATE		0x00000004
+#define CPER_ARMV8_VALID_VENDOR_INFO		0x00000008
+
+#define CPER_ARMV8_INFO_VALID_MULTI_ERR		0x0001
+#define CPER_ARMV8_INFO_VALID_FLAGS		0x0002
+#define CPER_ARMV8_INFO_VALID_ERR_INFO		0x0004
+#define CPER_ARMV8_INFO_VALID_VIRT_ADDR		0x0008
+#define CPER_ARMV8_INFO_VALID_PHYSICAL_ADDR	0x0010
+
+#define CPER_ARMV8_INFO_FLAGS_FIRST		0x0001
+#define CPER_ARMV8_INFO_FLAGS_LAST		0x0002
+#define CPER_ARMV8_INFO_FLAGS_PROPAGATED	0x0004
+
+#define CPER_AARCH64_CTX_LEN			368
+#define CPER_AARCH32_CTX_LEN			256
+
+#define CPER_ARMV8_CTX_TYPE_MASK		0x000000000000000F
+#define CPER_ARMV8_CTX_EL_MASK			0x0000000000000070
+#define CPER_ARMV8_CTX_NS_MASK			0x0000000000000080
+#define CPER_ARMV8_CTX_EL_SHIFT			4
+#define CPER_ARMV8_CTX_NS_SHIFT			7
+
 /*
  * All tables and structs must be byte-packed to match CPER
  * specification, since the tables are provided by the system BIOS
@@ -340,6 +377,41 @@ struct cper_ia_proc_ctx {
 	__u64	mm_reg_addr;
 };
 
+/* ARMv8 Processor Error Section */
+struct cper_sec_proc_armv8 {
+	__u32	validation_bits;
+	__u16	err_info_num; /* Number of Processor Error Info */
+	__u16	context_info_num; /* Number of Processor Context Info Records*/
+	__u32	section_length;
+	__u8	affinity_level;
+	__u8	reserved[3];	/* must be zero */
+	__u64	mpidr;
+	__u64	midr;
+	__u32	running_state; /* Bit 0 set - Processor running. PSCI = 0 */
+	__u32	psci_state;
+};
+
+/* ARMv8 Processor Error Information Structure */
+struct cper_armv8_err_info {
+	__u8	version;
+	__u8	length;
+	__u16	validation_bits;
+	__u8	type;
+	__u16	multiple_error;
+	__u8	flags;
+	__u64	error_info;
+	__u64	virt_fault_addr;
+	__u64	physical_fault_addr;
+};
+
+/* ARMv8 AARCH64 Processor Context Information Structure */
+struct cper_armv8_aarch64_ctx {
+	__u8	type_el_ns;
+	__u8	reserved[7];	/* must be zero */
+	__u8	gpr[288];
+	__u8	spr[68];
+};
+
 /* Old Memory Error Section UEFI 2.1, 2.2 */
 struct cper_sec_mem_err_old {
 	__u64	validation_bits;
-- 
1.8.2.1



From tbaicar at codeaurora.org  Fri Feb  5 11:13:27 2016
From: tbaicar at codeaurora.org (Tyler Baicar)
Date: Fri,  5 Feb 2016 12:13:27 -0700
Subject: [PATCH V1 5/6] arm64: exception: handle instruction abort at current
 EL
In-Reply-To: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
References: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
Message-ID: <1454699608-22760-6-git-send-email-tbaicar@codeaurora.org>

Add a handler for instruction aborts at the current EL
(ESR_ELx_EC_IABT_CUR) so they are no longer handled in el1_inv.
This allows firmware first handling for possible SEA
(Synchronous External Abort) caused instruction abort at
current EL.

Signed-off-by: Tyler Baicar <tbaicar at codeaurora.org>
Signed-off-by: Naveen Kaje <nkaje at codeaurora.org>
---
 arch/arm64/kernel/entry.S | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 1f7f5a2..6b7fb14 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -336,6 +336,8 @@ el1_sync:
 	lsr	x24, x1, #ESR_ELx_EC_SHIFT	// exception class
 	cmp	x24, #ESR_ELx_EC_DABT_CUR	// data abort in EL1
 	b.eq	el1_da
+	cmp	x24, #ESR_ELx_EC_IABT_CUR	// instruction abort in EL1
+	b.eq	el1_ia
 	cmp	x24, #ESR_ELx_EC_SYS64		// configurable trap
 	b.eq	el1_undef
 	cmp	x24, #ESR_ELx_EC_SP_ALIGN	// stack alignment exception
@@ -363,6 +365,23 @@ el1_da:
 	// disable interrupts before pulling preserved data off the stack
 	disable_irq
 	kernel_exit 1
+el1_ia:
+	/*
+	 * Instruction abort handling
+	 */
+	mrs	x0, far_el1
+	enable_dbg
+	// re-enable interrupts if they were enabled in the aborted context
+	tbnz	x23, #7, 1f			// PSR_I_BIT
+	enable_irq
+1:
+	orr	x1, x1, #1 << 24		// use reserved ISS bit for instruction aborts
+	mov	x2, sp				// struct pt_regs
+	bl	do_mem_abort
+
+	// disable interrupts before pulling preserved data off the stack
+	disable_irq
+	kernel_exit 1
 el1_sp_pc:
 	/*
 	 * Stack or PC alignment exception handling
-- 
1.8.2.1



From tbaicar at codeaurora.org  Fri Feb  5 11:13:26 2016
From: tbaicar at codeaurora.org (Tyler Baicar)
Date: Fri,  5 Feb 2016 12:13:26 -0700
Subject: [PATCH V1 4/6] arm64: exception: handle Synchronous External Abort
In-Reply-To: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
References: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
Message-ID: <1454699608-22760-5-git-send-email-tbaicar@codeaurora.org>

SEA exceptions are often caused by an uncorrected hardware
error and are handled when data abort and instruction abort
exception classes have specific values for their Fault Status
Code.

When SEA occurs, before killing the process, go through
the handlers registered in the notification list.

Update fault_info[] with specific SEA faults so that the
new SEA handler is used.

Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang at codeaurora.org>
Signed-off-by: Tyler Baicar <tbaicar at codeaurora.org>
Signed-off-by: Naveen Kaje <nkaje at codeaurora.org>
---
 arch/arm64/include/asm/system_misc.h | 13 ++++++++
 arch/arm64/mm/fault.c                | 58 +++++++++++++++++++++++++++++-------
 2 files changed, 61 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
index 57f110b..90daf4a 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -64,4 +64,17 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
 
 #endif	/* __ASSEMBLY__ */
 
+/*
+ * The functions below are used to register and unregister callbacks
+ * that are to be invoked when a Synchronous External Abort (SEA)
+ * occurs. An SEA is raised by certain fault status codes that have
+ * either data or instruction abort as the exception class, and
+ * callbacks may be registered to parse or handle such hardware errors.
+ *
+ * Registered callbacks are run in an interrupt/atomic context. They
+ * are not allowed to block or sleep.
+ */
+int sea_register_handler_chain(struct notifier_block *nb);
+void sea_unregister_handler_chain(struct notifier_block *nb);
+
 #endif	/* __ASM_SYSTEM_MISC_H */
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 92ddac1..d6fa691 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -39,6 +39,22 @@
 #include <asm/pgtable.h>
 #include <asm/tlbflush.h>
 
+/*
+ * GHES SEA handler code may register a notifier call here to
+ * handle HW error record passed from platform.
+ */
+static ATOMIC_NOTIFIER_HEAD(sea_handler_chain);
+
+int sea_register_handler_chain(struct notifier_block *nb)
+{
+	return atomic_notifier_chain_register(&sea_handler_chain, nb);
+}
+
+void sea_unregister_handler_chain(struct notifier_block *nb)
+{
+	atomic_notifier_chain_unregister(&sea_handler_chain, nb);
+}
+
 static const char *fault_name(unsigned int esr);
 
 /*
@@ -379,6 +395,28 @@ static int do_bad(unsigned long addr, unsigned int esr, struct pt_regs *regs)
 	return 1;
 }
 
+/*
+ * This abort handler deals with Synchronous External Abort.
+ * It calls notifiers, and then returns "fault".
+ */
+static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
+{
+	struct siginfo info;
+
+	atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
+
+	pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
+		 fault_name(esr), esr, addr);
+
+	info.si_signo = SIGBUS;
+	info.si_errno = 0;
+	info.si_code  = 0;
+	info.si_addr  = (void __user *)addr;
+	arm64_notify_die("", regs, &info, esr);
+
+	return 0;
+}
+
 static struct fault_info {
 	int	(*fn)(unsigned long addr, unsigned int esr, struct pt_regs *regs);
 	int	sig;
@@ -401,22 +439,22 @@ static struct fault_info {
 	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 1 permission fault"	},
 	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 2 permission fault"	},
 	{ do_page_fault,	SIGSEGV, SEGV_ACCERR,	"level 3 permission fault"	},
-	{ do_bad,		SIGBUS,  0,		"synchronous external abort"	},
+	{ do_sea,		SIGBUS,  0,		"synchronous external abort"	},
 	{ do_bad,		SIGBUS,  0,		"unknown 17"			},
 	{ do_bad,		SIGBUS,  0,		"unknown 18"			},
 	{ do_bad,		SIGBUS,  0,		"unknown 19"			},
-	{ do_bad,		SIGBUS,  0,		"synchronous abort (translation table walk)" },
-	{ do_bad,		SIGBUS,  0,		"synchronous abort (translation table walk)" },
-	{ do_bad,		SIGBUS,  0,		"synchronous abort (translation table walk)" },
-	{ do_bad,		SIGBUS,  0,		"synchronous abort (translation table walk)" },
-	{ do_bad,		SIGBUS,  0,		"synchronous parity error"	},
+	{ do_sea,		SIGBUS,  0,		"level 0 SEA (trans tbl walk)"	},
+	{ do_sea,		SIGBUS,  0,		"level 1 SEA (trans tbl walk)"	},
+	{ do_sea,		SIGBUS,  0,		"level 2 SEA (trans tbl walk)"	},
+	{ do_sea,		SIGBUS,  0,		"level 3 SEA (trans tbl walk)"	},
+	{ do_sea,		SIGBUS,  0,		"synchronous parity or ECC err" },
 	{ do_bad,		SIGBUS,  0,		"unknown 25"			},
 	{ do_bad,		SIGBUS,  0,		"unknown 26"			},
 	{ do_bad,		SIGBUS,  0,		"unknown 27"			},
-	{ do_bad,		SIGBUS,  0,		"synchronous parity error (translation table walk)" },
-	{ do_bad,		SIGBUS,  0,		"synchronous parity error (translation table walk)" },
-	{ do_bad,		SIGBUS,  0,		"synchronous parity error (translation table walk)" },
-	{ do_bad,		SIGBUS,  0,		"synchronous parity error (translation table walk)" },
+	{ do_sea,		SIGBUS,  0,		"level 0 synch parity error"	},
+	{ do_sea,		SIGBUS,  0,		"level 1 synch parity error"	},
+	{ do_sea,		SIGBUS,  0,		"level 2 synch parity error"	},
+	{ do_sea,		SIGBUS,  0,		"level 3 synch parity error"	},
 	{ do_bad,		SIGBUS,  0,		"unknown 32"			},
 	{ do_bad,		SIGBUS,  BUS_ADRALN,	"alignment fault"		},
 	{ do_bad,		SIGBUS,  0,		"unknown 34"			},
-- 
1.8.2.1



From tbaicar at codeaurora.org  Fri Feb  5 11:13:28 2016
From: tbaicar at codeaurora.org (Tyler Baicar)
Date: Fri,  5 Feb 2016 12:13:28 -0700
Subject: [PATCH V1 6/6] acpi: apei: handle SEA notification type for ARMv8
In-Reply-To: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
References: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
Message-ID: <1454699608-22760-7-git-send-email-tbaicar@codeaurora.org>

ARM APEI extension proposal added SEA (Synchrounous External
Abort) notification type for ARMv8.

Add a new GHES error source handling function for SEA. If an error
source's notification type is SEA, then this function can be registered
into the SEA exception handler. That way GHES will parse and report
SEA exceptions when they occur.

Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang at codeaurora.org>
Signed-off-by: Tyler Baicar <tbaicar at codeaurora.org>
Signed-off-by: Naveen Kaje <nkaje at codeaurora.org>
---
 arch/arm64/Kconfig        |  1 +
 drivers/acpi/apei/Kconfig | 13 ++++++++
 drivers/acpi/apei/ghes.c  | 83 +++++++++++++++++++++++++++++++++++++++++++++++
 include/acpi/actbl1.h     |  6 +++-
 4 files changed, 102 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6e4a4f4..236f398 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -6,6 +6,7 @@ config ARM64
 	select ACPI_REDUCED_HARDWARE_ONLY if ACPI
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select HAVE_ACPI_APEI if ACPI
+	select HAVE_ACPI_APEI_SEA if ACPI
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
index a60bb00..bfcbb9e 100644
--- a/drivers/acpi/apei/Kconfig
+++ b/drivers/acpi/apei/Kconfig
@@ -7,6 +7,19 @@ config HAVE_ACPI_APEI_NMI
 config HAVE_ACPI_APEI_HEST_IA32
 	bool
 
+config HAVE_ACPI_APEI_SEA
+	bool "APEI Synchronous External Abort logging/recovering support"
+	help
+	  This option should be enabled if the system supports
+	  firmware first handling of SEA (Synchronous External Abort).
+	  SEA happens with certain faults of data abort or instruction
+	  abort synchronous exceptions on ARMv8 systems. If a system
+	  supports firmware first handling of SEA, the platform analyzes
+	  and handles hardware error notifications with SEA, and it may then
+	  form a HW error record for the OS to parse and handle. This
+	  option allows the OS to look for such HW error record, and
+	  take appropriate action.
+
 config ACPI_APEI
 	bool "ACPI Platform Error Interface (APEI)"
 	select MISC_FILESYSTEMS
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 6c68100..ed64b97 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -50,6 +50,10 @@
 #include <acpi/apei.h>
 #include <asm/tlbflush.h>
 
+#ifdef CONFIG_HAVE_ACPI_APEI_SEA
+#include <asm/system_misc.h>
+#endif
+
 #include "apei-internal.h"
 
 #define GHES_PFX	"GHES: "
@@ -784,6 +788,62 @@ static struct notifier_block ghes_notifier_sci = {
 	.notifier_call = ghes_notify_sci,
 };
 
+#ifdef CONFIG_HAVE_ACPI_APEI_SEA
+static LIST_HEAD(ghes_sea);
+
+static int ghes_notify_sea(struct notifier_block *this,
+				  unsigned long event, void *data)
+{
+	struct ghes *ghes;
+	int ret = NOTIFY_DONE;
+
+	rcu_read_lock();
+	list_for_each_entry_rcu(ghes, &ghes_sea, list) {
+		if (!ghes_proc(ghes))
+			ret = NOTIFY_OK;
+	}
+	rcu_read_unlock();
+
+	return ret;
+}
+
+static struct notifier_block ghes_notifier_sea = {
+	.notifier_call = ghes_notify_sea,
+};
+
+static int ghes_sea_add(struct ghes *ghes)
+{
+	mutex_lock(&ghes_list_mutex);
+	if (list_empty(&ghes_sea))
+		sea_register_handler_chain(&ghes_notifier_sea);
+	list_add_rcu(&ghes->list, &ghes_sea);
+	mutex_unlock(&ghes_list_mutex);
+	return 0;
+}
+
+static void ghes_sea_remove(struct ghes *ghes)
+{
+	mutex_lock(&ghes_list_mutex);
+	list_del_rcu(&ghes->list);
+	if (list_empty(&ghes_sea))
+		sea_unregister_handler_chain(&ghes_notifier_sea);
+	mutex_unlock(&ghes_list_mutex);
+}
+#else /* CONFIG_HAVE_ACPI_APEI_SEA */
+static inline int ghes_sea_add(struct ghes *ghes)
+{
+	pr_err(GHES_PFX "ID: %d, trying to add SEA notification which is not supported\n",
+	       ghes->generic->header.source_id);
+	return -ENOTSUPP;
+}
+
+static inline void ghes_sea_remove(struct ghes *ghes)
+{
+	pr_err(GHES_PFX "ID: %d, trying to remove SEA notification which is not supported\n",
+	       ghes->generic->header.source_id);
+}
+#endif /* CONFIG_HAVE_ACPI_APEI_SEA */
+
 #ifdef CONFIG_HAVE_ACPI_APEI_NMI
 /*
  * printk is not safe in NMI context.  So in NMI handler, we allocate
@@ -1028,6 +1088,14 @@ static int ghes_probe(struct platform_device *ghes_dev)
 	case ACPI_HEST_NOTIFY_EXTERNAL:
 	case ACPI_HEST_NOTIFY_SCI:
 		break;
+	case ACPI_HEST_NOTIFY_SEA:
+		if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_SEA)) {
+			pr_warn(GHES_PFX "Generic hardware error source: %d notified via SEA is not supported\n",
+				generic->header.source_id);
+			rc = -ENOTSUPP;
+			goto err;
+		}
+		break;
 	case ACPI_HEST_NOTIFY_NMI:
 		if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
 			pr_warn(GHES_PFX "Generic hardware error source: %d notified via NMI interrupt is not supported!\n",
@@ -1039,6 +1107,13 @@ static int ghes_probe(struct platform_device *ghes_dev)
 		pr_warning(GHES_PFX "Generic hardware error source: %d notified via local interrupt is not supported!\n",
 			   generic->header.source_id);
 		goto err;
+	case ACPI_HEST_NOTIFY_GPIO:
+	case ACPI_HEST_NOTIFY_SEI:
+	case ACPI_HEST_NOTIFY_GSIV:
+		pr_warn(GHES_PFX "Generic hardware error source: %d notified via notification type %u is not supported\n",
+			generic->header.source_id, generic->header.source_id);
+		rc = -ENOTSUPP;
+		goto err;
 	default:
 		pr_warning(FW_WARN GHES_PFX "Unknown notification type: %u for generic hardware error source: %d\n",
 			   generic->notify.type, generic->header.source_id);
@@ -1093,6 +1168,11 @@ static int ghes_probe(struct platform_device *ghes_dev)
 		list_add_rcu(&ghes->list, &ghes_sci);
 		mutex_unlock(&ghes_list_mutex);
 		break;
+	case ACPI_HEST_NOTIFY_SEA:
+		rc = ghes_sea_add(ghes);
+		if (rc)
+			goto err_edac_unreg;
+		break;
 	case ACPI_HEST_NOTIFY_NMI:
 		ghes_nmi_add(ghes);
 		break;
@@ -1135,6 +1215,9 @@ static int ghes_remove(struct platform_device *ghes_dev)
 			unregister_acpi_hed_notifier(&ghes_notifier_sci);
 		mutex_unlock(&ghes_list_mutex);
 		break;
+	case ACPI_HEST_NOTIFY_SEA:
+		ghes_sea_remove(ghes);
+		break;
 	case ACPI_HEST_NOTIFY_NMI:
 		ghes_nmi_remove(ghes);
 		break;
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 231ae1e..e5118fb 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -507,7 +507,11 @@ enum acpi_hest_notify_types {
 	ACPI_HEST_NOTIFY_NMI = 4,
 	ACPI_HEST_NOTIFY_CMCI = 5,	/* ACPI 5.0 */
 	ACPI_HEST_NOTIFY_MCE = 6,	/* ACPI 5.0 */
-	ACPI_HEST_NOTIFY_RESERVED = 7	/* 7 and greater are reserved */
+	ACPI_HEST_NOTIFY_GPIO = 7,	/* ACPI 5.0 */
+	ACPI_HEST_NOTIFY_SEA = 8,	/* ACPI 6.x */
+	ACPI_HEST_NOTIFY_SEI = 9,	/* ACPI 6.x */
+	ACPI_HEST_NOTIFY_GSIV = 10,	/* ACPI 6.x */
+	ACPI_HEST_NOTIFY_RESERVED = 11	/* 11 and greater are reserved */
 };
 
 /* Values for config_write_enable bitfield above */
-- 
1.8.2.1



From tchalamarla at caviumnetworks.com  Fri Feb  5 11:28:16 2016
From: tchalamarla at caviumnetworks.com (tchalamarla at caviumnetworks.com)
Date: Fri, 5 Feb 2016 11:28:16 -0800
Subject: [PATCH] arm64: KVM: Add 48bit PA support for EL2  translations
Message-ID: <1454700496-21221-1-git-send-email-tchalamarla@caviumnetworks.com>

From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>

Systems where RAM is at higher address and MultiNode systems
whith higher address RAM, 39 bit max PA for EL2 translations
is not sufficient.

This patch sets max possible PA(48bit) for EL2 translations.

Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
---
 arch/arm64/include/asm/kvm_arm.h | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 738a95f..3fc38a4 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -98,7 +98,12 @@
 #define TCR_EL2_RES1	((1 << 31) | (1 << 23))
 #define TCR_EL2_TBI	(1 << 20)
 #define TCR_EL2_PS	(7 << 16)
+#define TCR_EL2_PS_32B	(0 << 16)
+#define TCR_EL2_PS_36B	(1 << 16)
 #define TCR_EL2_PS_40B	(2 << 16)
+#define TCR_EL2_PS_42B	(3 << 16)
+#define TCR_EL2_PS_44B	(4 << 16)
+#define TCR_EL2_PS_48B	(5 << 16)
 #define TCR_EL2_TG0	(1 << 14)
 #define TCR_EL2_SH0	(3 << 12)
 #define TCR_EL2_ORGN0	(3 << 10)
@@ -107,7 +112,10 @@
 #define TCR_EL2_MASK	(TCR_EL2_TG0 | TCR_EL2_SH0 | \
 			 TCR_EL2_ORGN0 | TCR_EL2_IRGN0 | TCR_EL2_T0SZ)
 
-#define TCR_EL2_FLAGS	(TCR_EL2_RES1 | TCR_EL2_PS_40B)
+/*
+ * Assign the highest possible PS.
+ */
+#define TCR_EL2_FLAGS	(TCR_EL2_RES1 | TCR_EL2_PS_48B)
 
 /* VTCR_EL2 Registers bits */
 #define VTCR_EL2_RES1		(1 << 31)
-- 
2.1.0



From leoyang.li at nxp.com  Fri Feb  5 11:36:50 2016
From: leoyang.li at nxp.com (Yang-Leo Li)
Date: Fri, 5 Feb 2016 19:36:50 +0000
Subject: [PATCH] PCI: layerscape: add ls2085a compatible
In-Reply-To: <20160205155412.GB29306@localhost>
References: <1453915925-19198-1-git-send-email-yang.shi@linaro.org>
 <56A906F4.3050809@linaro.org> <20160204223711.GE7031@localhost>
 <56B3E386.8010002@linaro.org>
 <VI1PR04MB1230AA5CAEEEE0D4AD8E3DF288D20@VI1PR04MB1230.eurprd04.prod.outlook.com>
 <VI1PR04MB16155E4265922D6659B439C1E8D20@VI1PR04MB1615.eurprd04.prod.outlook.com>
 <20160205155412.GB29306@localhost>
Message-ID: <AM2PR04MB0770FD6ED4FD45AFE600C6DB8FD20@AM2PR04MB0770.eurprd04.prod.outlook.com>

> On Fri, Feb 05, 2016 at 06:07:10AM +0000, Minghuan Lian wrote:
> > The patch is ok to me.
> 
> Thanks, I'll transform that into an ack.

Also
Acked-by: Li Yang <leoyang.li at nxp.com>

> 
> Who's going to post a patch to update MAINTAINERS to fix the @freescale.com
> addresses?  If we can get that in for v4.5, it will save some hassle.

The @freescale.com address can still reach us for some time(not sure how long though).  I don't know if all the people want to change to an NXP company email address in MAINTAINERS or just update to a personal email address as some already did.

Regards,
Leo

> 
> > > -----Original Message-----
> > > From: Bhupesh Sharma
> > > Sent: Friday, February 05, 2016 1:36 PM
> > > To: Shi, Yang <yang.shi at linaro.org>; Bjorn Helgaas
> > > <helgaas at kernel.org>; Yang-Leo Li <leoyang.li at nxp.com>;
> > > shawn.guo at linaro.org
> > > Cc: Mingkai Hu <mingkai.hu at nxp.com>; Minghuan Lian
> > > <minghuan.lian at nxp.com>; bhelgaas at google.com;
> > > linux-pci at vger.kernel.org; linux-kernel at vger.kernel.org;
> > > linux-arm-kernel at lists.infradead.org;
> > > linaro-kernel at lists.linaro.org
> > > Subject: RE: [PATCH] PCI: layerscape: add ls2085a compatible
> > >
> > > > From: Shi, Yang
> > > > Sent: Friday, February 05, 2016 5:19 AM
> > > >
> > > > On 2/4/2016 2:37 PM, Bjorn Helgaas wrote:
> > > > > On Wed, Jan 27, 2016 at 10:05:40AM -0800, Shi, Yang wrote:
> > > > >> Correct FSL folks email address to nxp.com, sorry for the
> > > > inconvenience.
> > > > >
> > > > > Do we need some MAINTAINERS updates in addition to the ack for
> > > > > this
> > > > patch?
> > > > > I see a bunch of @freescale.com addresses in MAINTAINERS.
> > > >
> > > > I guess so if the @freescale.com address is not valid anymore.
> > >
> > > All @freescale.com address have shifted to @nxp.com.
> > >
> > > Leo, Minghuan - can you kindly review this patch.
> > >
> > > Shawn - can you take this through your tree, once Leo and Minghuan
> > > have reviewed the code.
> > >
> > > Regards,
> > > Bhupesh
> > >
> > > >
> > > > >
> > > > >> On 1/27/2016 9:32 AM, Yang Shi wrote:
> > > > >>> The layerscape PCI host driver needs recognize ls2085a
> > > > >>> compatible when using firmware with ls2085a compatible
> > > > >>> property, otherwise the PCI bus won't be detected even though
> > > > >>> ls2085a compatible is included
> > > > by the dts.
> > > > >>>
> > > > >>> Signed-off-by: Yang Shi <yang.shi at linaro.org>
> > > > >>> ---
> > > > >>>   drivers/pci/host/pci-layerscape.c | 1 +
> > > > >>>   1 file changed, 1 insertion(+)
> > > > >>>
> > > > >>> diff --git a/drivers/pci/host/pci-layerscape.c
> > > > >>> b/drivers/pci/host/pci-layerscape.c
> > > > >>> index 3923bed..c40d8b2 100644
> > > > >>> --- a/drivers/pci/host/pci-layerscape.c
> > > > >>> +++ b/drivers/pci/host/pci-layerscape.c
> > > > >>> @@ -203,6 +203,7 @@ static const struct of_device_id
> > > > ls_pcie_of_match[] = {
> > > > >>>   	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata
> > > > },
> > > > >>>   	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata
> > > > },
> > > > >>>   	{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata
> > > > },
> > > > >>> +	{ .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata
> > > > >>> +},
> > > > >>>   	{ },
> > > > >>>   };
> > > > >>>   MODULE_DEVICE_TABLE(of, ls_pcie_of_match);
> > > > >>>
> > > > >>
> > > >
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-pci"
> > > > in the body of a message to majordomo at vger.kernel.org More
> > > > majordomo info at http://vger.kernel.org/majordomo-info.html


From contact at paulk.fr  Fri Feb  5 11:39:00 2016
From: contact at paulk.fr (Paul Kocialkowski)
Date: Fri, 05 Feb 2016 20:39:00 +0100
Subject: [PATCH v2 3/4] ARM: LG Optimus Black (P970) codename sniper
 support, with basic features
In-Reply-To: <1454697741-8687-4-git-send-email-contact@paulk.fr>
References: <1454697741-8687-1-git-send-email-contact@paulk.fr>
 <1454697741-8687-4-git-send-email-contact@paulk.fr>
Message-ID: <1454701140.2623.12.camel@collins>

Hi,

Le vendredi 05 f?vrier 2016 ? 19:42 +0100, Paul Kocialkowski a ?crit :
> The LG Optimus Black (P970) codename sniper is a smartphone that was designed
> and manufactured by LG Electronics (LGE) and released back in 2011.
> It is using an OMAP3630 SoC, GP version.
> 
> This adds devicetree support for the device, with only a few basic features
> supported, such as debug uart, i2c, internal emmc and external mmc.
> 
> Signed-off-by: Paul Kocialkowski <contact at paulk.fr>
> ---
>  arch/arm/boot/dts/Makefile         |   1 +
>  arch/arm/boot/dts/omap3-sniper.dts | 215 +++++++++++++++++++++++++++++++++++++
>  2 files changed, 216 insertions(+)
>  create mode 100644 arch/arm/boot/dts/omap3-sniper.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index a4a6d70..7314cf8 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -460,6 +460,7 @@ dtb-$(CONFIG_ARCH_OMAP3) += \
>  	omap3-sbc-t3517.dtb \
>  	omap3-sbc-t3530.dtb \
>  	omap3-sbc-t3730.dtb \
> +	omap3-sniper.dtb \
>  	omap3-thunder.dtb \
>  	omap3-zoom3.dtb
>  dtb-$(CONFIG_SOC_TI81XX) += \
> diff --git a/arch/arm/boot/dts/omap3-sniper.dts b/arch/arm/boot/dts/omap3-sniper.dts
> new file mode 100644
> index 0000000..24bcd82
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap3-sniper.dts
> @@ -0,0 +1,215 @@
> +/*
> + * Copyright (C) 2015-2016 Paul Kocialkowski <contact at paulk.fr>
> + *
> + * 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.
> + */
> +/dts-v1/;
> +
> +#include "omap36xx.dtsi"
> +
> +/ {
> +	model = "LG Optimus Black (P970)";
> +	compatible = "lge,omap3-sniper", "ti,omap36xx", "ti,omap3";
> +
> +	cpus {
> +		cpu at 0 {
> +			cpu0-supply = <&vcc>;
> +		};
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x80000000 0x20000000>; /* 512 MB */
> +	};
> +};
> +
> +&omap3_pmx_core {
> +	pinctrl-names = "default";
> +
> +	uart3_pins: pinmux_uart3_pins {
> +		pinctrl-single,pins = <
> +			OMAP3_CORE1_IOPAD(0x219e, PIN_INPUT | MUX_MODE0)	/* uart3_rx_irrx */
> +			OMAP3_CORE1_IOPAD(0x21a0, PIN_OUTPUT | MUX_MODE0)	/* uart3_tx_irtx */
> +		>;
> +	};
> +
> +	dp3t_sel_pins: pinmux_dp3t_sel_pins {
> +		pinctrl-single,pins = <
> +			OMAP3_CORE1_IOPAD(0x2196, PIN_OUTPUT | MUX_MODE4)	/* gpio_161 */
> +			OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE4)	/* gpio_162 */
> +		>;
> +	};
> +
> +	i2c1_pins: pinmux_i2c1_pins {
> +		pinctrl-single,pins = <
> +			OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0)	/* i2c1_scl */
> +			OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0)	/* i2c1_sda */
> +		>;
> +	};
> +
> +	i2c2_pins: pinmux_i2c2_pins {
> +		pinctrl-single,pins = <
> +			OMAP3_CORE1_IOPAD(0x21be, PIN_INPUT | MUX_MODE0)	/* i2c2_scl */
> +			OMAP3_CORE1_IOPAD(0x21c0, PIN_INPUT | MUX_MODE0)	/* i2c2_sda */
> +		>;
> +	};
> +
> +	i2c3_pins: pinmux_i2c3_pins {
> +		pinctrl-single,pins = <
> +			OMAP3_CORE1_IOPAD(0x21c2, PIN_INPUT | MUX_MODE0)	/* i2c3_scl */
> +			OMAP3_CORE1_IOPAD(0x21c4, PIN_INPUT | MUX_MODE0)	/* i2c3_sda */
> +		>;
> +	};
> +
> +	lp8720_en_pin: pinmux_lp8720_en_pin {
> +		pinctrl-single,pins = <
> +			OMAP3_CORE1_IOPAD(0x2080, PIN_OUTPUT | MUX_MODE4)	/* gpio_37 */
> +		>;
> +	};
> +
> +	mmc1_pins: pinmux_mmc1_pins {
> +		pinctrl-single,pins = <
> +			OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT | MUX_MODE0)	/* sdmmc1_clk */
> +			OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT | MUX_MODE0)	/* sdmmc1_cmd */
> +			OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT | MUX_MODE0)	/* sdmmc1_dat0 */
> +			OMAP3_CORE1_IOPAD(0x214a, PIN_INPUT | MUX_MODE0)	/* sdmmc1_dat1 */
> +			OMAP3_CORE1_IOPAD(0x214c, PIN_INPUT | MUX_MODE0)	/* sdmmc1_dat2 */
> +			OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT | MUX_MODE0)	/* sdmmc1_dat3 */
> +		>;
> +	};
> +
> +	mmc2_pins: pinmux_mmc2_pins {
> +		pinctrl-single,pins = <
> +			OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT | MUX_MODE0)	/* sdmmc2_clk */
> +			OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT | MUX_MODE0)	/* sdmmc2_cmd */
> +			OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat0 */
> +			OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat1 */
> +			OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat2 */
> +			OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat3 */
> +			OMAP3_CORE1_IOPAD(0x2164, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat4 */
> +			OMAP3_CORE1_IOPAD(0x2166, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat5 */
> +			OMAP3_CORE1_IOPAD(0x2168, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat6 */
> +			OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT | MUX_MODE0)	/* sdmmc2_dat7 */
> +		>;
> +	};
> +};
> +
> +&omap3_pmx_wkup {
> +	pinctrl-names = "default";
> +
> +	mmc1_cd_pin: pinmux_mmc1_cd_pin {
> +		pinctrl-single,pins = <
> +			OMAP3_WKUP_IOPAD(0x2a1a, PIN_INPUT | MUX_MODE4)		/* gpio_10 */
> +		>;
> +	};
> +};
> +
> +&gpio2 {
> +	ti,no-reset-on-init;
> +};
> +
> +&gpio5 {
> +	ti,no-reset-on-init;
> +};
> +
> +&gpio6 {
> +	ti,no-reset-on-init;
> +};
> +
> +&uart3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart3_pins &dp3t_sel_pins>;
> +
> +	interrupts-extended = <&intc 74 &omap3_pmx_core OMAP3_UART3_RX>;
> +};
> +
> +&i2c1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c1_pins>;
> +
> +	clock-frequency = <2600000>;
> +
> +	twl: twl at 48 {
> +		reg = <0x48>;
> +		interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> +		interrupt-parent = <&intc>;
> +
> +		twl_power: power {
> +			compatible = "ti,twl4030-power";
> +			ti,use_poweroff;
> +		};
> +	};
> +};
> +
> +#include "twl4030.dtsi"
> +#include "twl4030_omap3.dtsi"
> +
> +&i2c2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c2_pins>;
> +
> +	clock-frequency = <400000>;
> +};
> +
> +&i2c3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c3_pins>;
> +
> +	clock-frequency = <400000>;
> +
> +	lp8720 at 7d {
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&lp8720_en_pin>;
> +
> +		compatible = "ti,lp8720";
> +		reg = <0x7d>;
> +
> +		enable-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* gpio_37 */
> +
> +		lp8720_ldo1: ldo1 {
> +			regulator-min-microvolt = <3000000>;
> +			regulator-max-microvolt = <3000000>;
> +		};
> +	};
> +};
> +
> +&mmc1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mmc1_pins &mmc1_cd_pin>;
> +	vmmc-supply = <&lp8720_ldo1>;
> +	cd-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>; /* gpio 10 */
> +	bus-width = <4>;
> +};
> +
> +&mmc2 {
> +

Please discard this newline in case v2 gets merged.

> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mmc2_pins>;
> +	vmmc-supply = <&vmmc2>;
> +	ti,non-removable;
> +	bus-width = <8>;
> +};
> +
> +&mmc3 {
> +	status = "disabled";
> +};
> +
> +/*
> + * The TWL4030 VAUX2 and VDAC regulators power sensors that are slaves on I2C3.
> + * When not powered, these sensors cause the I2C3 clock to stay low at all times,
> + * making it impossible to reach other devices on I2C3.
> + */
> +
> +&vaux2 {
> +	regulator-min-microvolt = <2800000>;
> +	regulator-max-microvolt = <2800000>;
> +	regulator-always-on;
> +};
> +
> +&vdac {
> +	regulator-min-microvolt = <1800000>;
> +	regulator-max-microvolt = <1800000>;
> +	regulator-always-on;
> +};

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160205/5a66aaca/attachment.sig>

From helgaas at kernel.org  Fri Feb  5 11:49:27 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Fri, 5 Feb 2016 13:49:27 -0600
Subject: [PATCH v4 2/2] pci, pci-thunder-pem: Add PCIe host driver for
 ThunderX processors.
In-Reply-To: <56B4D812.7080106@caviumnetworks.com>
References: <1453844781-24380-1-git-send-email-ddaney.cavm@gmail.com>
 <1453844781-24380-3-git-send-email-ddaney.cavm@gmail.com>
 <20160205000452.GI7031@localhost>
 <56B3ECAD.4050605@caviumnetworks.com>
 <20160205031042.GA31722@localhost>
 <56B4D812.7080106@caviumnetworks.com>
Message-ID: <20160205194927.GA6581@localhost>

On Fri, Feb 05, 2016 at 09:12:50AM -0800, David Daney wrote:
> On 02/04/2016 07:10 PM, Bjorn Helgaas wrote:
> >On Thu, Feb 04, 2016 at 04:28:29PM -0800, David Daney wrote:
> >>On 02/04/2016 04:04 PM, Bjorn Helgaas wrote:
> >>>On Tue, Jan 26, 2016 at 01:46:21PM -0800, David Daney wrote:
> >>>>From: David Daney <david.daney at cavium.com>
> >>>>
> >>>>Some Cavium ThunderX processors require quirky access methods for the
> >>>>config space of the PCIe bridge.  Add a driver to provide these config
> >>>>space accessor functions.  The pci-host-common code is used to
> >>>>configure the PCI machinery.
> >>>>
> >>>>Signed-off-by: David Daney <david.daney at cavium.com>
> >>>>Acked-by: Rob Herring <robh at kernel.org>
> >>>>Acked-by: Arnd Bergmann <arnd at arndb.de>
> >>>>---
> >>>>  .../devicetree/bindings/pci/pci-thunder-pem.txt    |  43 ++++
> >>>>  MAINTAINERS                                        |   8 +
> >>>>  drivers/pci/host/Kconfig                           |   7 +
> >>>>  drivers/pci/host/Makefile                          |   1 +
> >>>>  drivers/pci/host/pci-thunder-pem.c                 | 283 +++++++++++++++++++++
> >>>
> >>>What's the significance of the "pem" part of the name?  I'm wondering
> >>>if we can shorten the filenames and function names by dropping it and
> >>>referring to this simply as "thunder" or "thunderx".
> ...

> >>Since PEM and ECAM are terminology used in the hardware manuals that
> >>have specific meanings relative to the Thunder SoC family, I think
> >>it is not too inconvenient to carry them over into the file names.
> >
> >As long as PEM and ECAM are really two distinct root complexes that
> >are unrelated, I guess this is OK.
> 
> They are, see above.

OK, I'm convinced.

> >>>>+		/*
> >>>>+		 * 32-bit accesses only.  If the write is for a size
> >>>>+		 * smaller than 32-bits, we must first read the 32-bit
> >>>>+		 * value and merge in the desired bits and then write
> >>>>+		 * the whole 32-bits back out.
> >>>>+		 */
> >>>
> >>>Ugh.  Another device that only supports 32-bit writes.  I guess this
> >>>only affects this single device, and maybe you "know" that it has no
> >>>registers where RW1C bits may be corrupted.  Although I suppose this
> >>>device has the standard status registers (Status at 0x06, Secondary
> >>>Status at 0x1e, Device Status in PCIe capability, etc.), which do
> >>>contain RW1C bits.
> ...

> I will add a WARN_ONCE or similar. and send a new patch set.
> 
> FWIW, I think I have been able to get the message through to the
> hardware architects that building root complexes that are not
> exposed as PCI standard ECAMs makes things very difficult.  This was
> the original intention, but turned out not to be possible when we
> looked more closely at the hardware implementation.  I am optimistic
> that subsequent generations of Thunder will be much improved in this
> area.

Great!  Since there's apparently only one ThunderX device (devfn == 0
on the root bus) that has this problem, and you know exactly what that
device is and where all its RW1C bits are, you *could* fix this in the
*_config_write() functions by clearing any RW1C bits before the
"modify/write" part of any read/modify/write cycle.

BTW, minor nit, when you repost these, can you reorder the
map_bus/read/write functions in that order so they match the order
they're declared in struct pci_ops?  I think both pem and ecam
versions could benefit from this.

Bjorn


From drivshin.allworx at gmail.com  Fri Feb  5 11:51:46 2016
From: drivshin.allworx at gmail.com (David Rivshin (Allworx))
Date: Fri, 5 Feb 2016 14:51:46 -0500
Subject: [PATCH 4/4] pwm: omap-dmtimer: add dev_dbg() message for
 effective period and duty cycle
In-Reply-To: <20160203141454.GC9650@ulmo>
References: <1454128014-22866-1-git-send-email-drivshin.allworx@gmail.com>
 <1454128014-22866-5-git-send-email-drivshin.allworx@gmail.com>
 <CAA3gFWvSsctXtds6_SEtYY1yUdWJDR1XjznGS6qjdrGW5Dbw=A@mail.gmail.com>
 <20160201132228.2634b72e.drivshin.allworx@gmail.com>
 <20160201185952.GN19432@atomide.com> <20160202162330.GA4918@ulmo>
 <20160202184443.1e1b0bf5.drivshin.allworx@gmail.com>
 <20160203141454.GC9650@ulmo>
Message-ID: <20160205145146.34ec4eb9.drivshin.allworx@gmail.com>

On Wed, 3 Feb 2016 15:14:54 +0100
Thierry Reding <thierry.reding at gmail.com> wrote:

> On Tue, Feb 02, 2016 at 06:44:43PM -0500, David Rivshin (Allworx)
> wrote:
> > On Tue, 2 Feb 2016 17:23:30 +0100
> > Thierry Reding <thierry.reding at gmail.com> wrote:
> >   
> > > On Mon, Feb 01, 2016 at 10:59:52AM -0800, Tony Lindgren wrote:  
> > > > Hi,
> > > > 
> > > > * David Rivshin (Allworx) <drivshin.allworx at gmail.com> [160201
> > > > 10:23]:    
> > > > > On Sat, 30 Jan 2016 15:51:06 +0100
> > > > > Neil Armstrong <narmstrong at baylibre.com> wrote:
> > > > >     
> > > > > > 2016-01-30 5:26 GMT+01:00 David Rivshin (Allworx)
> > > > > > <drivshin.allworx at gmail.com>:    
> > > > > > > From: David Rivshin <drivshin at allworx.com>
> > > > > > >
> > > > > > > After going through the math and constraints checking to
> > > > > > > compute load and match values, it is helpful to know what
> > > > > > > the resultant period and duty cycle are.
> > > > > > >
> > > > > > > Signed-off-by: David Rivshin <drivshin at allworx.com>
> > > > > > > ---
> > > > > > >
> > > > > > > I found this helpful while testing the other changes, so I
> > > > > > > included it in case it may be of use to someone in the
> > > > > > > future. I would have no issues with dropping this if it's
> > > > > > > not considered worthwhile.      
> > > > > > 
> > > > > > It's useful, but converting it as a sysfs attribute would be
> > > > > > great !    
> > > > > 
> > > > > Hrm, yes that is an interesting thought. I imagine that many
> > > > > PWM devices have similar constraints, so perhaps that would
> > > > > be best handled generically in the pwm core? Maybe as new
> > > > > optional get_*() ops, a modification to the config() op to
> > > > > add output params, or just updating new fields in the struct
> > > > > pwm directly?    
> > > > 
> > > > Yeah for /sys entry it should be Linux generic. The other option
> > > > is to use debugfs for driver specific things.    
> > > 
> > > Let's go with debugfs for this one. This is used for diagnostic  
> > 
> > I had looked at using the dbg_show() op to add some additional
> > data. One thing that discouraged me from going down that path was
> > that it replaced the call to pwm_dbg_show() for that chip. I
> > wouldn't want to loose the existing output, as it is useful, but
> > also didn't like the thought of duplicating the logic/formatting. I
> > think some way to have both the standard output and add extra
> > output somewhere (e.g. same line, line after each pwm_device, block
> > after all pwm_devices on the chip) would make that path more
> > attractive.
> > 
> > Or were you thinking of a separate (per-chip) debugfs file for this 
> > type of information?   
> 
> Yes, generally I'd prefer a separate, chip-specific debugfs file for

Makes sense.

> extra information. To be honest I'm not entirely sure of the
> usefulness of the pwm_dbg_show() or letting drivers override it. But

I did notice that no (in-tree) drivers were currently using 
pwm_dbg_show()...

> that's slightly off-topic. However...
> 
> > > purposes and not typically needed when configuring a PWM. While
> > > other drivers may compute similar hardware-specific values,
> > > there's nothing generic to them. The period and duty cycle are
> > > the generic input values and those are already exposed via
> > > sysfs.  
> > 
> > Just to clarify, what I was thinking of as generic was the concept
> > that "period/duty I asked for" and "period/duty I got" may be
> > different, sometimes to a substantial degree. I could imagine 
> > userspace wanting to know the latter, which is what I think Neil 
> > was suggesting.
> > 
> > For the sake of an example, the input clock for a dmtimer is
> > sometimes (often?) 32768Hz, which means that the real period and
> > duty_cycle output are limited to being a multiple of ~61035.2ns
> > (16384Hz). So an attempt to set a period of 100000ns (10KHz) would
> > result in either 61035.2ns, or 122070.4ns (8192Hz), depending on
> > the implementation of the driver (and patch 2 changes behavior from
> > the former to the latter). You can also have cases where you
> > desired a 33% duty cycle, but got a 25% duty cycle instead.
> > 
> > In a quick look, I see substantially similar calculations (i.e. 
> > clk_rate*period_ns/10^9) in most of the other pwm drivers, which
> > makes sense for any that are programmed in terms of some input
> > clock. This type of calculation almost guarantees that requested
> > and actual period/ duty_cycle are going to be different to some
> > degree. Some drivers look like they have even more complicated
> > behavior, apparently due to other hardware constraints. For
> > instance, fsl-ftm (among others) looks to be using a power-of-2
> > prescaler to fit the period_cycles into a 16bit field.
> > 
> > Of course if the input clock rate for these types of devices is 
> > sufficiently high (enough that the desired period is many input
> > clock cycles), then the difference between "desired" and "actual"
> > is probably small enough that noone cares. I'm not sure how common
> > it is that
> >   a) there is a substantial difference, and
> >   b) userspace cares about it, and
> >   c) userspace didn't carefully select an achievable value already
> > If noone has brought it up before, then I'd guess the answer is
> > "not very".  
> 
> ... I think perhaps a better way yet would be to have drivers update
> the period and duty cycle to the actual values. That way there won't
> be a delta between what's really being programmed to hardware and
> what shows up in sysfs. It would also give users a chance to check if
> what's been programmed is within an acceptable range or not.

From a userspace ABI point of view, I was unsure whether it was 
considered OK for a R/W sysfs attribute of this nature to read back 
differently than it was set. To follow the previous example:
	# echo 100000 > period
	# cat period
        122070
I didn't find any obvious precedents for that. Would it potentially 
confuse userspace? Is the answer different for new drivers vs 
existing ones? The obvious alternative would be a separate file (e.g. 
"actual_period", or somesuch name), which avoids those questions, but 
I can see how that could be considered less clean. I don't have any 
preference either way.

If just updating the existing period/duty_cycle files with the
actual values is the way to go, then there is a second question:
should the struct pwm_device track both requested and actual 
values in separate fields for kernel-internal users? Or should
the existing period/duty_cycle fields just be modified to hold
the actual values?

Either way, I think any changes along these lines would probably be 
cleaner ontop of the atomic update work (assuming some form of that 
gets merged). And since it would also be outside the scope of this 
patchset, you may still want to consider the simple debug message 
in this patch as at least an interim state.



From sboyd at codeaurora.org  Fri Feb  5 11:54:19 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 5 Feb 2016 11:54:19 -0800
Subject: [PATCH 2/6] arm64: dts: qcom: apq8016-sbc: add usb support
In-Reply-To: <1454698880-13973-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1454698819-13885-1-git-send-email-srinivas.kandagatla@linaro.org>
 <1454698880-13973-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <56B4FDEB.2080202@codeaurora.org>

On 02/05/2016 11:01 AM, Srinivas Kandagatla wrote:
> +
> +		usb2513 {
> +			compatible = "smsc,usb3503";
> +			reset-gpios = <&pm8916_gpios 3 GPIO_ACTIVE_LOW>;
> +			initial-mode = <1>;
> +		};
> +
> +		usb_id: usb-id {
> +			interrupt-parent = <&msmgpio>;
> +			compatible = "linux,extcon-usb-gpio";
> +			id-gpio = <&msmgpio 121 GPIO_ACTIVE_HIGH>;
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&usb_id_default>;
> +		};

These are not on the SoC bus. Please move them to root.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project



From sboyd at codeaurora.org  Fri Feb  5 11:55:14 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 5 Feb 2016 11:55:14 -0800
Subject: [PATCH 4/6] arm64: dts: qcom: add lpass node
In-Reply-To: <1454698896-14058-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1454698819-13885-1-git-send-email-srinivas.kandagatla@linaro.org>
 <1454698896-14058-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <56B4FE22.8030403@codeaurora.org>

On 02/05/2016 11:01 AM, Srinivas Kandagatla wrote:
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index c1592d4..cdda026 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -343,6 +343,32 @@
>  			status = "disabled";
>  		};
>  
> +		lpass: lpass at 07700000 {
[..]
> +			reg = <0x07708000 0x10000>;

Unit address and reg don't match. Please make them the same.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project



From mark.rutland at arm.com  Fri Feb  5 12:02:09 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 5 Feb 2016 20:02:09 +0000
Subject: [PATCH] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <1454698027-20911-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1454698027-20911-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <20160205200142.GA8647@leverpostej>

On Fri, Feb 05, 2016 at 10:47:07AM -0800, tchalamarla at caviumnetworks.com wrote:
> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> 
> An issue exists whereby the Linux kernel requires that ASIDs are a
> unique namespace per SMMU.  

The SMMU architecture requires this, and Linux relies on hardware
following the architecture.

Please describe the problem correctly. i.e. that the hardware
erroneously shares TLBs between SMMU instances.

> That ASID-local choice conflicts with the
> CN88xx SMMU, where only shared ASID namespaces are supported;
> specifically within a given node SMMU0 and SMMU1 share, as does SMMU2
> and SMMU3. CN88xx SMMU also requires global VMIDs.
> 
> This patch tries to address these issuee by supplying asid and vmid
> transformations from devicetree.
> 
> Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> ---
>  .../devicetree/bindings/iommu/arm,smmu.txt         | 16 ++++++
>  drivers/iommu/arm-smmu.c                           | 59 ++++++++++++++++++----
>  2 files changed, 65 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index 7180745..eef06d0 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -55,6 +55,22 @@ conditions.
>                    aliases of secure registers have to be used during
>                    SMMU configuration.
>  
> +- thunderx,smmu-asid-transform	: Enable proper handling for buggy
> +		  implementations that require special transformations
> +		  for smmu asid. if this property exists asid-transform
> +		  property must be present.
> +
> +- thunderx,smmu-vmid-transform	: Enable proper handling for buggy
> +		  implementations that require special transformations
> +		  for smmu vmid. if this property exists vmid-transform
> +		  property must be present.
> +
> +- asid-transform 	: Transform mask that needs to be applied to asid.
> +			This property has to be specified as '/bits/ 8' value.
> +
> +- vmid-transform 	: Transform mask that needs to be applied to vmid.
> +			This property has to be specified as '/bits/ 8' value.

Don't bother with /bits/ 8. It saves no space in the DTB and only adds
to confusion. Use a full cell, and of_property_read_u32, and validate
that the value is in range.

Having two properties for each seems redundant. The presence of a mask
should be sufficient to make it clear that the use of the mask is
required.

These properties aren't sufficiently described. How is the mask
"applied", and what is it applied to? What constraints does it impose
on the OS's selection of ASIDs/VMIDs?

>From the looks of the patch, it's ANDed into the value Linux has
selected, so it sounds like an OS must avoid using any bits set in any
mask on any SMMU instance. That sounds very difficult to ensure in
general, and very fragile.

Mark.

> +
>  Example:
>  
>          smmu {
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 59ee4b8..8047834 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -300,8 +300,12 @@ struct arm_smmu_device {
>  	u32				features;
>  
>  #define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
> +#define ARM_SMMU_OPT_TRANSFORM_ASID	(1 << 1)
> +#define ARM_SMMU_OPT_TRANSFORM_VMID	(1 << 2)
>  	u32				options;
>  	enum arm_smmu_arch_version	version;
> +	u8				asid_transform;
> +	u8				vmid_transform;
>  
>  	u32				num_context_banks;
>  	u32				num_s2_context_banks;
> @@ -330,8 +334,25 @@ struct arm_smmu_cfg {
>  };
>  #define INVALID_IRPTNDX			0xff
>  
> -#define ARM_SMMU_CB_ASID(cfg)		((cfg)->cbndx)
> -#define ARM_SMMU_CB_VMID(cfg)		((cfg)->cbndx + 1)
> +/*
> + * ThunderX has a unique requirement because of ERRATA#27704
> + * An issue exists whereby the Linux kernel requires that ASIDs are a
> + * unique namespace per SMMU.  That ASID-local choice conflicts with the
> + * CN88xx SMMU, where only shared ASID namespaces are supported;
> + * specifically within a given node SMMU0 and SMMU1 share, as does SMMU2
> + * and SMMU3.
> + * CN88xx SMMU also requires global VMIDs.
> + */
> +
> +#define ARM_SMMU_CB_ASID(smmu, cfg)					\
> +		(((smmu)->options & ARM_SMMU_OPT_TRANSFORM_ASID)	\
> +		? ((cfg)->cbndx | (smmu)->asid_transform)		\
> +		: ((cfg)->cbndx))
> +
> +#define ARM_SMMU_CB_VMID(smmu, cfg)					\
> +		(((smmu)->options & ARM_SMMU_OPT_TRANSFORM_VMID)	\
> +		? (((cfg)->cbndx + 1) | (smmu)->vmid_transform)		\
> +		: ((cfg)->cbndx + 1))
>  
>  enum arm_smmu_domain_stage {
>  	ARM_SMMU_DOMAIN_S1 = 0,
> @@ -361,6 +382,8 @@ struct arm_smmu_option_prop {
>  
>  static struct arm_smmu_option_prop arm_smmu_options[] = {
>  	{ ARM_SMMU_OPT_SECURE_CFG_ACCESS, "calxeda,smmu-secure-config-access" },
> +	{ ARM_SMMU_OPT_TRANSFORM_ASID, "thunderx,smmu-asid-transform" },
> +	{ ARM_SMMU_OPT_TRANSFORM_VMID, "thunderx,smmu-vmid-transform" },
>  	{ 0, NULL},
>  };
>  
> @@ -570,11 +593,11 @@ static void arm_smmu_tlb_inv_context(void *cookie)
>  
>  	if (stage1) {
>  		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
> -		writel_relaxed(ARM_SMMU_CB_ASID(cfg),
> +		writel_relaxed(ARM_SMMU_CB_ASID(smmu, cfg),
>  			       base + ARM_SMMU_CB_S1_TLBIASID);
>  	} else {
>  		base = ARM_SMMU_GR0(smmu);
> -		writel_relaxed(ARM_SMMU_CB_VMID(cfg),
> +		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg),
>  			       base + ARM_SMMU_GR0_TLBIVMID);
>  	}
>  
> @@ -596,7 +619,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>  
>  		if (!IS_ENABLED(CONFIG_64BIT) || smmu->version == ARM_SMMU_V1) {
>  			iova &= ~12UL;
> -			iova |= ARM_SMMU_CB_ASID(cfg);
> +			iova |= ARM_SMMU_CB_ASID(smmu, cfg);
>  			do {
>  				writel_relaxed(iova, reg);
>  				iova += granule;
> @@ -604,7 +627,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>  #ifdef CONFIG_64BIT
>  		} else {
>  			iova >>= 12;
> -			iova |= (u64)ARM_SMMU_CB_ASID(cfg) << 48;
> +			iova |= (u64)ARM_SMMU_CB_ASID(smmu, cfg) << 48;
>  			do {
>  				writeq_relaxed(iova, reg);
>  				iova += granule >> 12;
> @@ -624,7 +647,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>  #endif
>  	} else {
>  		reg = ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_TLBIVMID;
> -		writel_relaxed(ARM_SMMU_CB_VMID(cfg), reg);
> +		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg), reg);
>  	}
>  }
>  
> @@ -752,7 +775,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>  		reg |= (CBAR_S1_BPSHCFG_NSH << CBAR_S1_BPSHCFG_SHIFT) |
>  			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
>  	} else {
> -		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
> +		reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBAR_VMID_SHIFT;
>  	}
>  	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
>  
> @@ -760,11 +783,11 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>  	if (stage1) {
>  		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>  
> -		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
> +		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
>  		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR0);
>  
>  		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
> -		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
> +		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
>  		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR1);
>  	} else {
>  		reg64 = pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
> @@ -1793,6 +1816,22 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
>  
>  	parse_driver_options(smmu);
>  
> +	if (smmu->options & ARM_SMMU_OPT_TRANSFORM_ASID) {
> +		if (of_property_read_u8(dev->of_node, "#asid-transform",
> +					 &smmu->asid_transform)) {
> +			dev_err(dev, "missing #asid-transform property\n");
> +			return -ENODEV;
> +		}
> +	}
> +
> +	if (smmu->options & ARM_SMMU_OPT_TRANSFORM_VMID) {
> +		if (of_property_read_u8(dev->of_node, "#vmid-transform",
> +					 &smmu->vmid_transform)) {
> +			dev_err(dev, "missing #vmid-transform property\n");
> +			return -ENODEV;
> +		}
> +	}
> +
`  	if (smmu->version > ARM_SMMU_V1 &&
>  	    smmu->num_context_banks != smmu->num_context_irqs) {
>  		dev_err(dev,
> -- 
> 2.1.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From mark.rutland at arm.com  Fri Feb  5 12:15:32 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 5 Feb 2016 20:15:32 +0000
Subject: [PATCH] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <20160205200142.GA8647@leverpostej>
References: <1454698027-20911-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160205200142.GA8647@leverpostej>
Message-ID: <20160205201532.GA10389@leverpostej>

On Fri, Feb 05, 2016 at 08:02:09PM +0000, Mark Rutland wrote:
> On Fri, Feb 05, 2016 at 10:47:07AM -0800, tchalamarla at caviumnetworks.com wrote:
> > From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> > 
> > An issue exists whereby the Linux kernel requires that ASIDs are a
> > unique namespace per SMMU.  
> 
> The SMMU architecture requires this, and Linux relies on hardware
> following the architecture.
> 
> Please describe the problem correctly. i.e. that the hardware
> erroneously shares TLBs between SMMU instances.
> 
> > That ASID-local choice conflicts with the
> > CN88xx SMMU, where only shared ASID namespaces are supported;
> > specifically within a given node SMMU0 and SMMU1 share, as does SMMU2
> > and SMMU3. CN88xx SMMU also requires global VMIDs.
> > 
> > This patch tries to address these issuee by supplying asid and vmid
> > transformations from devicetree.
> > 
> > Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
> > Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> > ---
> >  .../devicetree/bindings/iommu/arm,smmu.txt         | 16 ++++++
> >  drivers/iommu/arm-smmu.c                           | 59 ++++++++++++++++++----
> >  2 files changed, 65 insertions(+), 10 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > index 7180745..eef06d0 100644
> > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> > @@ -55,6 +55,22 @@ conditions.
> >                    aliases of secure registers have to be used during
> >                    SMMU configuration.
> >  
> > +- thunderx,smmu-asid-transform	: Enable proper handling for buggy
> > +		  implementations that require special transformations
> > +		  for smmu asid. if this property exists asid-transform
> > +		  property must be present.
> > +
> > +- thunderx,smmu-vmid-transform	: Enable proper handling for buggy
> > +		  implementations that require special transformations
> > +		  for smmu vmid. if this property exists vmid-transform
> > +		  property must be present.
> > +
> > +- asid-transform 	: Transform mask that needs to be applied to asid.
> > +			This property has to be specified as '/bits/ 8' value.
> > +
> > +- vmid-transform 	: Transform mask that needs to be applied to vmid.
> > +			This property has to be specified as '/bits/ 8' value.
> 
> Don't bother with /bits/ 8. It saves no space in the DTB and only adds
> to confusion. Use a full cell, and of_property_read_u32, and validate
> that the value is in range.
> 
> Having two properties for each seems redundant. The presence of a mask
> should be sufficient to make it clear that the use of the mask is
> required.
> 
> These properties aren't sufficiently described. How is the mask
> "applied", and what is it applied to? What constraints does it impose
> on the OS's selection of ASIDs/VMIDs?
> 
> From the looks of the patch, it's ANDed into the value Linux has
> selected, so it sounds like an OS must avoid using any bits set in any
> mask on any SMMU instance. That sounds very difficult to ensure in
> general, and very fragile.

A much better approach would be to have something like:

valid-asid-range : two u32 cells describing the minimum and maximum
                   ASIDs that may be used on this SMMU instance. The OS
		   must allocate ASIDs in the interval [minimum,
		   maximum].

That way the OS can prevent itself from allocating conflicting ASIDs,
which is not possible with a single base value as you have with your
asid-transform property.

Mark.


From Tirumalesh.Chalamarla at caviumnetworks.com  Fri Feb  5 12:29:19 2016
From: Tirumalesh.Chalamarla at caviumnetworks.com (Chalamarla, Tirumalesh)
Date: Fri, 5 Feb 2016 20:29:19 +0000
Subject: [PATCH] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <20160205201532.GA10389@leverpostej>
References: <1454698027-20911-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160205200142.GA8647@leverpostej> <20160205201532.GA10389@leverpostej>
Message-ID: <9A2E9B16-A69C-456B-8DBD-75F0A2C3FA02@caviumnetworks.com>






On 2/5/16, 12:15 PM, "Mark Rutland" <mark.rutland at arm.com> wrote:

>On Fri, Feb 05, 2016 at 08:02:09PM +0000, Mark Rutland wrote:
>> On Fri, Feb 05, 2016 at 10:47:07AM -0800, tchalamarla at caviumnetworks.com wrote:
>> > From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>> > 
>> > An issue exists whereby the Linux kernel requires that ASIDs are a
>> > unique namespace per SMMU.  
>> 
>> The SMMU architecture requires this, and Linux relies on hardware
>> following the architecture.
>> 
>> Please describe the problem correctly. i.e. that the hardware
>> erroneously shares TLBs between SMMU instances.
>> 
>> > That ASID-local choice conflicts with the
>> > CN88xx SMMU, where only shared ASID namespaces are supported;
>> > specifically within a given node SMMU0 and SMMU1 share, as does SMMU2
>> > and SMMU3. CN88xx SMMU also requires global VMIDs.
>> > 
>> > This patch tries to address these issuee by supplying asid and vmid
>> > transformations from devicetree.
>> > 
>> > Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
>> > Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>> > ---
>> >  .../devicetree/bindings/iommu/arm,smmu.txt         | 16 ++++++
>> >  drivers/iommu/arm-smmu.c                           | 59 ++++++++++++++++++----
>> >  2 files changed, 65 insertions(+), 10 deletions(-)
>> > 
>> > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> > index 7180745..eef06d0 100644
>> > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> > @@ -55,6 +55,22 @@ conditions.
>> >                    aliases of secure registers have to be used during
>> >                    SMMU configuration.
>> >  
>> > +- thunderx,smmu-asid-transform	: Enable proper handling for buggy
>> > +		  implementations that require special transformations
>> > +		  for smmu asid. if this property exists asid-transform
>> > +		  property must be present.
>> > +
>> > +- thunderx,smmu-vmid-transform	: Enable proper handling for buggy
>> > +		  implementations that require special transformations
>> > +		  for smmu vmid. if this property exists vmid-transform
>> > +		  property must be present.
>> > +
>> > +- asid-transform 	: Transform mask that needs to be applied to asid.
>> > +			This property has to be specified as '/bits/ 8' value.
>> > +
>> > +- vmid-transform 	: Transform mask that needs to be applied to vmid.
>> > +			This property has to be specified as '/bits/ 8' value.
>> 
>> Don't bother with /bits/ 8. It saves no space in the DTB and only adds
>> to confusion. Use a full cell, and of_property_read_u32, and validate
>> that the value is in range.
>> 
>> Having two properties for each seems redundant. The presence of a mask
>> should be sufficient to make it clear that the use of the mask is
>> required.
>> 
>> These properties aren't sufficiently described. How is the mask
>> "applied", and what is it applied to? What constraints does it impose
>> on the OS's selection of ASIDs/VMIDs?
>> 
>> From the looks of the patch, it's ANDed into the value Linux has
>> selected, so it sounds like an OS must avoid using any bits set in any
>> mask on any SMMU instance. That sounds very difficult to ensure in
>> general, and very fragile.
>
>A much better approach would be to have something like:
>
>valid-asid-range : two u32 cells describing the minimum and maximum
>                   ASIDs that may be used on this SMMU instance. The OS
>		   must allocate ASIDs in the interval [minimum,
>		   maximum].
>
>That way the OS can prevent itself from allocating conflicting ASIDs,
>which is not possible with a single base value as you have with your
>asid-transform property.

The problem is, Will don?t want this to be part of general change, he want to treat it as Errata. 
>
>Mark.

From Tirumalesh.Chalamarla at caviumnetworks.com  Fri Feb  5 12:32:00 2016
From: Tirumalesh.Chalamarla at caviumnetworks.com (Chalamarla, Tirumalesh)
Date: Fri, 5 Feb 2016 20:32:00 +0000
Subject: [PATCH] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <20160205200142.GA8647@leverpostej>
References: <1454698027-20911-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160205200142.GA8647@leverpostej>
Message-ID: <812E9BBE-CFA6-4B90-A38F-2CA27FE04752@caviumnetworks.com>






On 2/5/16, 12:02 PM, "Mark Rutland" <mark.rutland at arm.com> wrote:

>On Fri, Feb 05, 2016 at 10:47:07AM -0800, tchalamarla at caviumnetworks.com wrote:
>> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>> 
>> An issue exists whereby the Linux kernel requires that ASIDs are a
>> unique namespace per SMMU.  
>
>The SMMU architecture requires this, and Linux relies on hardware
>following the architecture.
>
>Please describe the problem correctly. i.e. that the hardware
>erroneously shares TLBs between SMMU instances.
>
>> That ASID-local choice conflicts with the
>> CN88xx SMMU, where only shared ASID namespaces are supported;
>> specifically within a given node SMMU0 and SMMU1 share, as does SMMU2
>> and SMMU3. CN88xx SMMU also requires global VMIDs.
>> 
>> This patch tries to address these issuee by supplying asid and vmid
>> transformations from devicetree.
>> 
>> Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
>> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>> ---
>>  .../devicetree/bindings/iommu/arm,smmu.txt         | 16 ++++++
>>  drivers/iommu/arm-smmu.c                           | 59 ++++++++++++++++++----
>>  2 files changed, 65 insertions(+), 10 deletions(-)
>> 
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> index 7180745..eef06d0 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> @@ -55,6 +55,22 @@ conditions.
>>                    aliases of secure registers have to be used during
>>                    SMMU configuration.
>>  
>> +- thunderx,smmu-asid-transform	: Enable proper handling for buggy
>> +		  implementations that require special transformations
>> +		  for smmu asid. if this property exists asid-transform
>> +		  property must be present.
>> +
>> +- thunderx,smmu-vmid-transform	: Enable proper handling for buggy
>> +		  implementations that require special transformations
>> +		  for smmu vmid. if this property exists vmid-transform
>> +		  property must be present.
>> +
>> +- asid-transform 	: Transform mask that needs to be applied to asid.
>> +			This property has to be specified as '/bits/ 8' value.
>> +
>> +- vmid-transform 	: Transform mask that needs to be applied to vmid.
>> +			This property has to be specified as '/bits/ 8' value.
>
>Don't bother with /bits/ 8. It saves no space in the DTB and only adds
>to confusion. Use a full cell, and of_property_read_u32, and validate
>that the value is in range.
>
>Having two properties for each seems redundant. The presence of a mask
>should be sufficient to make it clear that the use of the mask is
>required.

Sure. 
>
>These properties aren't sufficiently described. How is the mask
>"applied", and what is it applied to? What constraints does it impose
>on the OS's selection of ASIDs/VMIDs?
>
>From the looks of the patch, it's ANDed into the value Linux has
>selected, so it sounds like an OS must avoid using any bits set in any
>mask on any SMMU instance. That sounds very difficult to ensure in
>general, and very fragile.

For now it is only specific to ThunderX errata, its not a general requirement.
So ThunderX DTS will make sure it defined proper values. 

If all agree to make it a general requirement, I am happy to re write it with ASID and VMID coming from
DTS. 
>
>Mark.
>
>> +
>>  Example:
>>  
>>          smmu {
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 59ee4b8..8047834 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -300,8 +300,12 @@ struct arm_smmu_device {
>>  	u32				features;
>>  
>>  #define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
>> +#define ARM_SMMU_OPT_TRANSFORM_ASID	(1 << 1)
>> +#define ARM_SMMU_OPT_TRANSFORM_VMID	(1 << 2)
>>  	u32				options;
>>  	enum arm_smmu_arch_version	version;
>> +	u8				asid_transform;
>> +	u8				vmid_transform;
>>  
>>  	u32				num_context_banks;
>>  	u32				num_s2_context_banks;
>> @@ -330,8 +334,25 @@ struct arm_smmu_cfg {
>>  };
>>  #define INVALID_IRPTNDX			0xff
>>  
>> -#define ARM_SMMU_CB_ASID(cfg)		((cfg)->cbndx)
>> -#define ARM_SMMU_CB_VMID(cfg)		((cfg)->cbndx + 1)
>> +/*
>> + * ThunderX has a unique requirement because of ERRATA#27704
>> + * An issue exists whereby the Linux kernel requires that ASIDs are a
>> + * unique namespace per SMMU.  That ASID-local choice conflicts with the
>> + * CN88xx SMMU, where only shared ASID namespaces are supported;
>> + * specifically within a given node SMMU0 and SMMU1 share, as does SMMU2
>> + * and SMMU3.
>> + * CN88xx SMMU also requires global VMIDs.
>> + */
>> +
>> +#define ARM_SMMU_CB_ASID(smmu, cfg)					\
>> +		(((smmu)->options & ARM_SMMU_OPT_TRANSFORM_ASID)	\
>> +		? ((cfg)->cbndx | (smmu)->asid_transform)		\
>> +		: ((cfg)->cbndx))
>> +
>> +#define ARM_SMMU_CB_VMID(smmu, cfg)					\
>> +		(((smmu)->options & ARM_SMMU_OPT_TRANSFORM_VMID)	\
>> +		? (((cfg)->cbndx + 1) | (smmu)->vmid_transform)		\
>> +		: ((cfg)->cbndx + 1))
>>  
>>  enum arm_smmu_domain_stage {
>>  	ARM_SMMU_DOMAIN_S1 = 0,
>> @@ -361,6 +382,8 @@ struct arm_smmu_option_prop {
>>  
>>  static struct arm_smmu_option_prop arm_smmu_options[] = {
>>  	{ ARM_SMMU_OPT_SECURE_CFG_ACCESS, "calxeda,smmu-secure-config-access" },
>> +	{ ARM_SMMU_OPT_TRANSFORM_ASID, "thunderx,smmu-asid-transform" },
>> +	{ ARM_SMMU_OPT_TRANSFORM_VMID, "thunderx,smmu-vmid-transform" },
>>  	{ 0, NULL},
>>  };
>>  
>> @@ -570,11 +593,11 @@ static void arm_smmu_tlb_inv_context(void *cookie)
>>  
>>  	if (stage1) {
>>  		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
>> -		writel_relaxed(ARM_SMMU_CB_ASID(cfg),
>> +		writel_relaxed(ARM_SMMU_CB_ASID(smmu, cfg),
>>  			       base + ARM_SMMU_CB_S1_TLBIASID);
>>  	} else {
>>  		base = ARM_SMMU_GR0(smmu);
>> -		writel_relaxed(ARM_SMMU_CB_VMID(cfg),
>> +		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg),
>>  			       base + ARM_SMMU_GR0_TLBIVMID);
>>  	}
>>  
>> @@ -596,7 +619,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>>  
>>  		if (!IS_ENABLED(CONFIG_64BIT) || smmu->version == ARM_SMMU_V1) {
>>  			iova &= ~12UL;
>> -			iova |= ARM_SMMU_CB_ASID(cfg);
>> +			iova |= ARM_SMMU_CB_ASID(smmu, cfg);
>>  			do {
>>  				writel_relaxed(iova, reg);
>>  				iova += granule;
>> @@ -604,7 +627,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>>  #ifdef CONFIG_64BIT
>>  		} else {
>>  			iova >>= 12;
>> -			iova |= (u64)ARM_SMMU_CB_ASID(cfg) << 48;
>> +			iova |= (u64)ARM_SMMU_CB_ASID(smmu, cfg) << 48;
>>  			do {
>>  				writeq_relaxed(iova, reg);
>>  				iova += granule >> 12;
>> @@ -624,7 +647,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>>  #endif
>>  	} else {
>>  		reg = ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_TLBIVMID;
>> -		writel_relaxed(ARM_SMMU_CB_VMID(cfg), reg);
>> +		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg), reg);
>>  	}
>>  }
>>  
>> @@ -752,7 +775,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>>  		reg |= (CBAR_S1_BPSHCFG_NSH << CBAR_S1_BPSHCFG_SHIFT) |
>>  			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
>>  	} else {
>> -		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
>> +		reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBAR_VMID_SHIFT;
>>  	}
>>  	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
>>  
>> @@ -760,11 +783,11 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>>  	if (stage1) {
>>  		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>>  
>> -		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
>> +		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
>>  		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR0);
>>  
>>  		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
>> -		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
>> +		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
>>  		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR1);
>>  	} else {
>>  		reg64 = pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
>> @@ -1793,6 +1816,22 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
>>  
>>  	parse_driver_options(smmu);
>>  
>> +	if (smmu->options & ARM_SMMU_OPT_TRANSFORM_ASID) {
>> +		if (of_property_read_u8(dev->of_node, "#asid-transform",
>> +					 &smmu->asid_transform)) {
>> +			dev_err(dev, "missing #asid-transform property\n");
>> +			return -ENODEV;
>> +		}
>> +	}
>> +
>> +	if (smmu->options & ARM_SMMU_OPT_TRANSFORM_VMID) {
>> +		if (of_property_read_u8(dev->of_node, "#vmid-transform",
>> +					 &smmu->vmid_transform)) {
>> +			dev_err(dev, "missing #vmid-transform property\n");
>> +			return -ENODEV;
>> +		}
>> +	}
>> +
>`  	if (smmu->version > ARM_SMMU_V1 &&
>>  	    smmu->num_context_banks != smmu->num_context_irqs) {
>>  		dev_err(dev,
>> -- 
>> 2.1.0
>> 
>> 
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> 

From helgaas at kernel.org  Fri Feb  5 12:38:58 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Fri, 5 Feb 2016 14:38:58 -0600
Subject: [PATCH] PCI: layerscape: add ls2085a compatible
In-Reply-To: <1453915925-19198-1-git-send-email-yang.shi@linaro.org>
References: <1453915925-19198-1-git-send-email-yang.shi@linaro.org>
Message-ID: <20160205203858.GA11780@localhost>

[+cc Rob, et al]

On Wed, Jan 27, 2016 at 09:32:05AM -0800, Yang Shi wrote:
> The layerscape PCI host driver needs recognize ls2085a compatible when using
> firmware with ls2085a compatible property, otherwise the PCI bus won't be
> detected even though ls2085a compatible is included by the dts.
> 
> Signed-off-by: Yang Shi <yang.shi at linaro.org>
> ---
>  drivers/pci/host/pci-layerscape.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
> index 3923bed..c40d8b2 100644
> --- a/drivers/pci/host/pci-layerscape.c
> +++ b/drivers/pci/host/pci-layerscape.c
> @@ -203,6 +203,7 @@ static const struct of_device_id ls_pcie_of_match[] = {
>  	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
>  	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
>  	{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
> +	{ .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },

Hmm, "fsl,ls2085a-pcie" doesn't appear in
Documentation/devicetree/bindings/pci/.  

Aren't we supposed to add these strings to the bindings before or at
the same time we add them to drivers?

checkpatch doesn't complain though, so maybe I'm wrong about this.

>  	{ },
>  };
>  MODULE_DEVICE_TABLE(of, ls_pcie_of_match);
> -- 
> 2.0.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From keescook at chromium.org  Fri Feb  5 12:39:56 2016
From: keescook at chromium.org (Kees Cook)
Date: Fri, 5 Feb 2016 12:39:56 -0800
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <CAKv+Gu-W_zKYEz0yKVevtO2b2A8+TEEXfX+iGG8PLcV7M63JYw@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160204151303.GB6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu9n=bmsZ=UOBiLWzaG2JSsbdC8k1mB7yFbH0czrbXS-1g@mail.gmail.com>
 <20160205154234.GF6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-poQiuc7+O38n93Xt2o-SYi3kYD0k_9+-6T0=FXV9uXA@mail.gmail.com>
 <20160205160054.GG6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu8g7FHHZgmbFww_XZjf5J1utmigwBiNqCg8a3crfB4xFA@mail.gmail.com>
 <20160205164648.GH6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-W_zKYEz0yKVevtO2b2A8+TEEXfX+iGG8PLcV7M63JYw@mail.gmail.com>
Message-ID: <CAGXu5j+1rcScYedzQ5o0aaGZJWPCBGk-gai0D8jY8Huc-VuG7A@mail.gmail.com>

On Fri, Feb 5, 2016 at 8:54 AM, Ard Biesheuvel
<ard.biesheuvel at linaro.org> wrote:
> On 5 February 2016 at 17:46, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> On Fri, Feb 05, 2016 at 05:20:14PM +0100, Ard Biesheuvel wrote:
>>> On 5 February 2016 at 17:00, Catalin Marinas <catalin.marinas at arm.com> wrote:
>>> > On Fri, Feb 05, 2016 at 04:53:10PM +0100, Ard Biesheuvel wrote:
>>> >> On 5 February 2016 at 16:42, Catalin Marinas <catalin.marinas at arm.com> wrote:
>>> >> > On Thu, Feb 04, 2016 at 04:31:59PM +0100, Ard Biesheuvel wrote:
>>> >> >> On 4 February 2016 at 16:13, Catalin Marinas <catalin.marinas at arm.com> wrote:
>>> >> >> > On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
>>> >> >> >> This adds support for emitting PLTs at module load time for relative
>>> >> >> >> branches that are out of range. This is a prerequisite for KASLR, which
>>> >> >> >> may place the kernel and the modules anywhere in the vmalloc area,
>>> >> >> >> making it more likely that branch target offsets exceed the maximum
>>> >> >> >> range of +/- 128 MB.
>>> >> >> >
>>> >> >> > Any downside to trying to keep the kernel+modules coupled together so
>>> >> >> > that we avoid the PLT?
>>> >> >>
>>> >> >> First of all, note that it is unlikely that the PLTs are ever required
>>> >> >> in practice, considering that either
>>> >> >> a) the kernel is loaded at the default location right at the base of
>>> >> >> the vmalloc range, and in this case, the module space is reserved for
>>> >> >> modules only, or
>>> >> >> b) the kernel is loaded at some random offset in the 240+ GB vmalloc
>>> >> >> space, and it is unlikely that all VMA space around the kernel happens
>>> >> >> to be given out to non-randomized vmalloc/ioremap allocations
>>> >> >
>>> >> > My worry is that we merge some code that's rarely tested.
>>> >>
>>> >> I understand. But unfortunately, having corner cases that are unlikely
>>> >> but not impossible comes with the territory of randomization.
>>> >>
>>> >> Alternatively, we could take the performance hit if KASLR is in effect
>>> >> and allocate each module completely randomly as well. This way, the
>>> >> code is always exercised (for now), and we can always backpedal later
>>> >> if the performance is measurably worse.
>>> >
>>> > I'm fine with this. You can post it as a separate patch that we can
>>> > easily revert/modify later (like turning it into a config option).
>>>
>>> OK, I will hack something up
>>
>> If it's simpler, you can just add a config option but defaulting to the
>> full vmalloc space for modules.
>>
>
> What would be the simplest is to randomize the 128 MB module region as
> a whole, and either put it close to the kernel (which is what I am
> doing now), or put it at a random offset inside the vmalloc space, in
> which case all branches will be resolved via PLTs. My suggestion to
> randomize each module_alloc() call separately is actually not that
> straight-forward.

FWIW, it also turns out that this ends up not being very random in a
limited address range. It ends up turning into a greedy-allocation
hole-filling routine, and for a given system ends up being pretty
deterministic.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security


From andrew at lunn.ch  Fri Feb  5 12:40:40 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 5 Feb 2016 21:40:40 +0100
Subject: [PATCH 1/3] ARM: dts: orion5x: fix the missing mtd flash on
 linkstation lswtgl
In-Reply-To: <1454689998-9579-2-git-send-email-rogershimizu@gmail.com>
References: <1454689998-9579-1-git-send-email-rogershimizu@gmail.com>
 <1454689998-9579-2-git-send-email-rogershimizu@gmail.com>
Message-ID: <20160205204040.GB8063@lunn.ch>

On Sat, Feb 06, 2016 at 01:33:16AM +0900, Roger Shimizu wrote:
> MTD flash stores u-boot and u-boot environment on linkstation lswtgl.
> The latter one can be easily read/write by u-boot-tools package in Debian.
> 
> Signed-off-by: Roger Shimizu <rogershimizu at gmail.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

Thanks for using the partitions node.

       Andrew

> ---
>  arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts | 31 ++++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts b/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
> index 420788229e6f..aae8a7aceab7 100644
> --- a/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
> +++ b/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
> @@ -228,6 +228,37 @@
>  	};
>  };
>  
> +&devbus_bootcs {
> +	status = "okay";
> +	devbus,keep-config;
> +
> +	flash at 0 {
> +		compatible = "jedec-flash";
> +		reg = <0 0x40000>;
> +		bank-width = <1>;
> +
> +		partitions {
> +			compatible = "fixed-partitions";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +
> +			header at 0 {
> +				reg = <0 0x30000>;
> +				read-only;
> +			};
> +
> +			uboot at 30000 {
> +				reg = <0x30000 0xF000>;
> +				read-only;
> +			};
> +
> +			uboot_env at 3F000 {
> +				reg = <0x3F000 0x1000>;
> +			};
> +		};
> +	};
> +};
> +
>  &mdio {
>  	status = "okay";
>  
> -- 
> 2.1.4
> 


From arno at natisbad.org  Fri Feb  5 12:41:09 2016
From: arno at natisbad.org (Arnaud Ebalard)
Date: Fri, 05 Feb 2016 21:41:09 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <87io232kat.fsf@free-electrons.com> (Gregory CLEMENT's message of
 "Fri, 05 Feb 2016 17:28:42 +0100")
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
 <20160205090246.GE32272@lunn.ch> <20160205112907.796afb05@bbrezillon>
 <CAKzmTe20fT8BcRaDaf2gz92KMAK0kEUkaD-kPq_cPF1WKBdroA@mail.gmail.com>
 <87vb632maf.fsf@free-electrons.com>
 <CAKzmTe1AqNQwjcsAULotd010NXuk1AYjj5p6UoqT_Zu=BCHdcw@mail.gmail.com>
 <87mvrf2l6p.fsf@free-electrons.com>
 <87io232kat.fsf@free-electrons.com>
Message-ID: <8760y2vqje.fsf@natisbad.org>

Hi guys,

Gregory CLEMENT <gregory.clement at free-electrons.com> writes:

> Hi,
>
> +cc Arnaud
>  
>  On ven., f?vr. 05 2016, Gregory CLEMENT <gregory.clement at free-electrons.com> wrote:
>
>> Hi JM,
>>  
>>  On ven., f?vr. 05 2016, JM <fijam at archlinux.us> wrote:
>>
>>> On Fri, Feb 5, 2016 at 4:45 PM, Gregory CLEMENT
>>> <gregory.clement at free-electrons.com> wrote:
>>>> Hi JM,
>>>>
>>>>  On ven., f?vr. 05 2016, JM <fijam at archlinux.us> wrote:
>>>>
>>>>> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
>>>>> <boris.brezillon at free-electrons.com> wrote:
>>>>>> Jan, Andrew
>>>>>>
>>>>>> On Fri, 5 Feb 2016 10:02:46 +0100
>>>>>> Andrew Lunn <andrew at lunn.ch> wrote:
>>>>>>
>>>>>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>>>>>>> > Hi,
>>>>>>> >
>>>>>>> > I am testing marvell_cesa on a kirkwood device (QNAP TS-212p, Marvell
>>>>>>> > Kirkwood 88F6282, dts: http://pastebin.com/Gk95KFHf ).
>>>>>>> > As of kernel 4.4 (4.4.0-trunk-kirkwood #1 Debian 4.4-1~exp1) it fails
>>>>>>> > in the following way:
>>>>>>> >
>>>>>>> > modprobe marvell_cesa allhwsupport=1
>>>>>>> > dmesg | tail -n 1
>>>>>>> > [ 1057.855091] marvell-cesa: probe of f1030000.crypto failed with error -12
>>>>>>> >
>>>>>>> > or:
>>>>>>> >
>>>>>>> > modprobe marvell_cesa
>>>>>>> > dmesg | tail -n 1
>>>>>>> > [ 9178.399357] marvell-cesa: probe of f1030000.crypto failed with error -524
>>>>>>> >
>>>>>>> > With kernel 4.3 it would fail with error -22 on that hardware. There
>>>>>>> > are scattered reports from other users experiencing the same issue
>>>>>>> > (1,2,3)
>>>>>>> >
>>>>>>> > I wonder if this is a result of an invalid definition of the
>>>>>>> > crypto-sram in the dts of this SoC, or perhaps some other problem
>>>>>>> > (PEBKAC included).
>>>>>>>
>>>>>>> Hi Jan
>>>>>>>
>>>>>>> Do you have SRAM enabled in your kernel configuration. The
>>>>>>> mvebu_v5_defconfig does not have it, which is a bug really.
>>>>>>
>>>>>> Hm, the CRYPTO_DEV_MARVELL_CESA option selects the SRAM one [1].
>>>>>> Anyway, I also think this error is related to the SRAM (not sure why the
>>>>>> driver is not able to get the SRAM though).
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Boris
>>>>>>
>>>>>> [1]http://lxr.free-electrons.com/source/drivers/crypto/Kconfig#L168
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Boris Brezillon, Free Electrons
>>>>>> Embedded Linux and Kernel engineering
>>>>>> http://free-electrons.com
>>>>>
>>>>> Hi,
>>>>>
>>>>> Thanks for getting back to me. Indeed, CONFIG_SRAM is enabled, I put
>>>>> the complete .config here: http://pastebin.com/40eKMJqE
>>>>>
>>>>> If there is anything I can do to help squish this bug, please let me
>>>>> know.
>>>>
>>>> How do you get your dts?
>>>> it seems that you generated it from your dtb (or from /proc).
>>>>
>>>> I tried to do the same from arch/arm/boot/dts/kirkwood-ts219-6282.dtb,
>>>> but the resulting dts is too different for an easy comparison.
>>>>
>>>> Could you also provide your dtb, maybe by using the same dtc with the
>>>> option -s I will manage to get the something easier to compare.
>>>
>>
>>> Yes, I simply used dtc -I fs /proc/device-tree to obtain the dts.
>>>
>>> Here is the relevant .dtb file : http://heap.ovh/files/kirkwood-ts219-6282.dtb
>>>
>>
>> OK so this dtb is exacly the one from the mainline. As most of the CESU
>> stuff is set in te dtis, we will be able to compare it on the other
>> kirkwood based board.
>>
>> Gregory
>
> So with the help of Boris we checked the ranges propreties, the reg
> property and the clock too. Everyting seems OK.
>
> Arnaud,
>
> as you are the on who tested the cesa on kirkwood, do you remember if
> you needed to add specific Kconfig or to made some change in the dts?

Here is the result I get on my ReadyNAS Duo v2 (88F6282, see below) w/ a
stock 4.4 kernel I just cross-compiled w/ a gcc 4.9.2. The kernel has no
modules and uses an appended DTB (u-boot on the platform is pretyy old):

root at mood:~# dmesg | grep -i cesa
[    3.306135] marvell-cesa f1030000.crypto: CESA device successfully registered

root at mood:~# uname -a
Linux mood 4.4.0.duov2 #1 Fri Feb 5 21:11:25 CET 2016 armv5tel GNU/Linux

root at mood:~# cat /proc/cpuinfo 
processor       : 0
model name      : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 1594.16
Features        : swp half thumb fastmult edsp 
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

Hardware        : Marvell Kirkwood (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000

I'll try and do the same now w/ CESA support compiled as module to see
what I get. I'll keep you posted.

As a side note, a simple grep on the .config file you provided at
http://pastebin.com/40eKMJqE makes me wonder why it has some
grsec options residue. Did you test on a stock 4.4 kernel or on
something w/ additional patches? If the latter, could you check what a
stock kernel gives?

Cheers,

a+


From keescook at chromium.org  Fri Feb  5 12:42:30 2016
From: keescook at chromium.org (Kees Cook)
Date: Fri, 5 Feb 2016 12:42:30 -0800
Subject: [PATCH v5sub2 0/8] arm64: implement virtual KASLR
In-Reply-To: <CAKv+Gu_v1sXM7sivz+Uu86ZG3=Th7wqqh7M1N8wF7Ess4NdTZQ@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <CAKv+Gu-AhLcatkDsQVeoFGJ+pTEwaW1Hy9M-fY1-VWvRc_E47w@mail.gmail.com>
 <20160205173248.GJ6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_v1sXM7sivz+Uu86ZG3=Th7wqqh7M1N8wF7Ess4NdTZQ@mail.gmail.com>
Message-ID: <CAGXu5j+JpwRrVy1b_h+LJ4sCzsT7BV9RdcD0CvR-4aVJQhCpvg@mail.gmail.com>

On Fri, Feb 5, 2016 at 9:38 AM, Ard Biesheuvel
<ard.biesheuvel at linaro.org> wrote:
> On 5 February 2016 at 18:32, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> I'm still trying to get my head around how we merge those. Since I
>> assume akpm will push them during the merging window, part of your code
>> cannot be tested before.
>
> Actually, my original idea was for akpm to take them as a late merge
> after rebasing to -rc1, since they touch a variety of architectures,
> but I am not sure if that came across.
>
> You could always take the series through your tree instead, I guess?

Traditionally akpm will de-duplicate patches he's carrying that appear
in another tree. I think it should be okay to carry them in both
places. (Though I'm CCing akpm just to see if I'm talking crazy.)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security


From yang.shi at linaro.org  Fri Feb  5 12:45:25 2016
From: yang.shi at linaro.org (Shi, Yang)
Date: Fri, 5 Feb 2016 12:45:25 -0800
Subject: [PATCH] PCI: layerscape: add ls2085a compatible
In-Reply-To: <20160205203858.GA11780@localhost>
References: <1453915925-19198-1-git-send-email-yang.shi@linaro.org>
 <20160205203858.GA11780@localhost>
Message-ID: <56B509E5.2050602@linaro.org>

On 2/5/2016 12:38 PM, Bjorn Helgaas wrote:
> [+cc Rob, et al]
>
> On Wed, Jan 27, 2016 at 09:32:05AM -0800, Yang Shi wrote:
>> The layerscape PCI host driver needs recognize ls2085a compatible when using
>> firmware with ls2085a compatible property, otherwise the PCI bus won't be
>> detected even though ls2085a compatible is included by the dts.
>>
>> Signed-off-by: Yang Shi <yang.shi at linaro.org>
>> ---
>>   drivers/pci/host/pci-layerscape.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
>> index 3923bed..c40d8b2 100644
>> --- a/drivers/pci/host/pci-layerscape.c
>> +++ b/drivers/pci/host/pci-layerscape.c
>> @@ -203,6 +203,7 @@ static const struct of_device_id ls_pcie_of_match[] = {
>>   	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
>>   	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
>>   	{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
>> +	{ .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },
>
> Hmm, "fsl,ls2085a-pcie" doesn't appear in
> Documentation/devicetree/bindings/pci/.
>
> Aren't we supposed to add these strings to the bindings before or at
> the same time we add them to drivers?

The below patch will add it into dts and binding doc. I should mentioned 
this in the commit log.

https://patchwork.kernel.org/patch/7767061/

Thanks,
Yang

>
> checkpatch doesn't complain though, so maybe I'm wrong about this.
>
>>   	{ },
>>   };
>>   MODULE_DEVICE_TABLE(of, ls_pcie_of_match);
>> --
>> 2.0.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From andrew at lunn.ch  Fri Feb  5 12:48:09 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 5 Feb 2016 21:48:09 +0100
Subject: [PATCH 2/3] ARM: dts: orion5x: split linkstation lswtgl into
 common and device parts
In-Reply-To: <1454689998-9579-3-git-send-email-rogershimizu@gmail.com>
References: <1454689998-9579-1-git-send-email-rogershimizu@gmail.com>
 <1454689998-9579-3-git-send-email-rogershimizu@gmail.com>
Message-ID: <20160205204809.GC8063@lunn.ch>

On Sat, Feb 06, 2016 at 01:33:17AM +0900, Roger Shimizu wrote:
> In order to support more linkstation devices, common part of current
> .dts file goes into .dtsi file. Some .dtsi are not with "orion5x" prefix
> because other kirkwood based linkstation devices are in this shape, and
> will be migrated some time later.
>   - orion5x-linkstation.dtsi
>   - linkstation-gpio-simple.dtsi
>   - linkstation-fan.dtsi

Hi Roger

I would prefer these have an mvebu- prefix. That then covers orion5x
and kirkwood.

Otherwise these look O.K.

	  Andrew


From andrew at lunn.ch  Fri Feb  5 12:49:26 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Fri, 5 Feb 2016 21:49:26 +0100
Subject: [PATCH 3/3] ARM: dts: orion5x: add device tree for buffalo
 linkstation ls-gl
In-Reply-To: <1454689998-9579-4-git-send-email-rogershimizu@gmail.com>
References: <1454689998-9579-1-git-send-email-rogershimizu@gmail.com>
 <1454689998-9579-4-git-send-email-rogershimizu@gmail.com>
Message-ID: <20160205204926.GD8063@lunn.ch>

On Sat, Feb 06, 2016 at 01:33:18AM +0900, Roger Shimizu wrote:
> Add dts file to support Buffalo Linkstation LS-GL
> (a.k.a Buffalo Linkstation Pro/Live), which is marvell orion5x based
> 3.5" HDD NAS.
> 
> Product info:
>   - (JPN) http://buffalo.jp/products/catalog/item/l/ls-gl/
>   - (ENG) http://www.buffalotech.com/products/network-storage/linkstation/linkstation-pro
> 
> This device tree is based on the board file:
>   arch/arm/mach-orion5x/kurobox_pro-setup.c
> However, that board file also support Kurobox Pro, which is not supported by
> device tree yet. So the board file is not removed.
> 
> Signed-off-by: Roger Shimizu <rogershimizu at gmail.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

Thanks
	Andrew

> ---
>  arch/arm/boot/dts/Makefile                     |  1 +
>  arch/arm/boot/dts/orion5x-linkstation-lsgl.dts | 87 ++++++++++++++++++++++++++
>  2 files changed, 88 insertions(+)
>  create mode 100644 arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 68625754f398..15a52c1be78a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -496,6 +496,7 @@ dtb-$(CONFIG_SOC_DRA7XX) += \
>  dtb-$(CONFIG_ARCH_ORION5X) += \
>  	orion5x-lacie-d2-network.dtb \
>  	orion5x-lacie-ethernet-disk-mini-v2.dtb \
> +	orion5x-linkstation-lsgl.dtb \
>  	orion5x-linkstation-lswtgl.dtb \
>  	orion5x-lswsgl.dtb \
>  	orion5x-maxtor-shared-storage-2.dtb \
> diff --git a/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts b/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
> new file mode 100644
> index 000000000000..1cf644bfd7ea
> --- /dev/null
> +++ b/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
> @@ -0,0 +1,87 @@
> +/*
> + * Device Tree file for Buffalo Linkstation LS-GL
> + *       (also known as Buffalo Linkstation Pro/Live)
> + *
> + * Copyright (C) 2016
> + * Roger Shimizu <rogershimizu at gmail.com>
> + *
> + * Based on the board file arch/arm/mach-orion5x/kurobox_pro-setup.c
> + * Copyright (C) Ronen Shitrit <rshitrit at marvell.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This file is distributed in the hope that it will be useful
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "orion5x-linkstation.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> +	model = "Buffalo Linkstation Pro/Live";
> +	compatible = "buffalo,lsgl", "marvell,orion5x-88f5182", "marvell,orion5x";
> +
> +	memory { /* 128 MB */
> +		device_type = "memory";
> +		reg = <0x00000000 0x8000000>;
> +	};
> +};
> +
> +&pinctrl {
> +	pmx_power_hdd: pmx-power-hdd {
> +		marvell,pins = "mpp1";
> +		marvell,function = "gpio";
> +	};
> +
> +	pmx_power_usb: pmx-power-usb {
> +		marvell,pins = "mpp9";
> +		marvell,function = "gpio";
> +	};
> +};
> +
> +&hdd_power {
> +	gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&usb_power {
> +	gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&ehci1 {
> +	status = "okay";
> +};
> -- 
> 2.1.4
> 


From arno at natisbad.org  Fri Feb  5 13:04:44 2016
From: arno at natisbad.org (Arnaud Ebalard)
Date: Fri, 05 Feb 2016 22:04:44 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <8760y2vqje.fsf@natisbad.org> (Arnaud Ebalard's message of "Fri, 
 05 Feb 2016 21:41:09 +0100")
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
 <20160205090246.GE32272@lunn.ch> <20160205112907.796afb05@bbrezillon>
 <CAKzmTe20fT8BcRaDaf2gz92KMAK0kEUkaD-kPq_cPF1WKBdroA@mail.gmail.com>
 <87vb632maf.fsf@free-electrons.com>
 <CAKzmTe1AqNQwjcsAULotd010NXuk1AYjj5p6UoqT_Zu=BCHdcw@mail.gmail.com>
 <87mvrf2l6p.fsf@free-electrons.com>
 <87io232kat.fsf@free-electrons.com> <8760y2vqje.fsf@natisbad.org>
Message-ID: <87twlmdg2b.fsf@natisbad.org>

Hi,

> I'll try and do the same now w/ CESA support compiled as module to see
> what I get. I'll keep you posted.

root at mood:~# insmod /tmp/marvell-cesa.ko 
[  573.897977] marvell-cesa f1030000.crypto: CESA device successfully registered

root at mood:~# uname -a
Linux mood 4.4.0.duov2 #2 Fri Feb 5 21:42:49 CET 2016 armv5tel GNU/Linux

root at mood:~# zcat /proc/config.gz | grep -i CESA
# CONFIG_CRYPTO_DEV_MV_CESA is not set
CONFIG_CRYPTO_DEV_MARVELL_CESA=m

Cheers,

a+

ps: my config is temporarily at http://natisbad.org/config-duov2-cesa


From heiko at sntech.de  Fri Feb  5 13:20:18 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  5 Feb 2016 22:20:18 +0100
Subject: [PATCH 5/5] arm64: dts: rockchip: add rk3368 iodomains
In-Reply-To: <1454707218-23676-1-git-send-email-heiko@sntech.de>
References: <1454707218-23676-1-git-send-email-heiko@sntech.de>
Message-ID: <1454707218-23676-6-git-send-email-heiko@sntech.de>

Add the supply-links according to the R88 schematics.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 arch/arm64/boot/dts/rockchip/rk3368-r88.dts | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
index 104cbee..e6e2a1f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
@@ -211,6 +211,18 @@
 	status = "ok";
 };
 
+&grf {
+	io-domains {
+		compatible = "rockchip,rk3368-io-voltage-domain";
+
+		audio-supply = <&vcc_io>;
+		gpio30-supply = <&vcc_io>;
+		gpio1830-supply = <&vcc_io>;
+		sdcard-supply = <&vccio_sd>;
+		wifi-supply = <&vccio_wl>;
+	};
+};
+
 &i2c0 {
 	status = "okay";
 
@@ -331,6 +343,16 @@
 	};
 };
 
+&pmugrf {
+	io-domains {
+		compatible = "rockchip,rk3368-pmu-io-voltage-domain";
+		rockchip,grf = <&pmugrf>;
+
+		pmu-supply = <&vcc_io>;
+		vop-supply = <&vcc_io>;
+	};
+};
+
 &saradc {
 	vref-supply = <&vcc_18>;
 	status = "okay";
-- 
2.6.4



From heiko at sntech.de  Fri Feb  5 13:20:13 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  5 Feb 2016 22:20:13 +0100
Subject: [PATCH 0/5] ARM: rockchip: move io-domains under GRF
Message-ID: <1454707218-23676-1-git-send-email-heiko@sntech.de>

The GRF contains both individual settings-bits as well as somewhat more
fully blocks like different phy-controls and also the io-voltage selection.
Similar to the power-domains living under the pmu, things like said
io-voltage selection should live under the grf instead of separate
nodes higher up.

This is even more important now that socs like the rk3368 and probably
more future socs seem to contain more than one GRF-area (a second one
under the PMU power-domain) with each containing a part of the voltage
selection. So having that in the correct place also prevents confusion.


Ideally patch1 would go into 4.6 through the power or avs tree and the
devicetree-related things should wait until after the next merge window
due to the updated binding, which I can then simply apply to my dts
branches.


Heiko Stuebner (5):
  PM / AVS: rockchip-io: make io-domains a child of the GRF
  ARM: dts: rockchip: make rk3288-grf a simple-mfd
  ARM: dts: rockchip: move rk3288 io-domain nodes to the grf
  arm64: dts: rockchip: make rk3368 grf syscons simple-mfds as well
  arm64: dts: rockchip: add rk3368 iodomains

 .../bindings/power/rockchip-io-domain.txt          |  4 ++-
 arch/arm/boot/dts/rk3288-firefly.dtsi              | 33 +++++++++++----------
 arch/arm/boot/dts/rk3288-popmetal.dts              | 34 ++++++++++++----------
 arch/arm/boot/dts/rk3288-rock2-som.dtsi            | 34 ++++++++++++----------
 arch/arm/boot/dts/rk3288-veyron.dtsi               | 28 +++++++++---------
 arch/arm/boot/dts/rk3288.dtsi                      |  2 +-
 arch/arm64/boot/dts/rockchip/rk3368-r88.dts        | 22 ++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3368.dtsi           |  4 +--
 drivers/power/avs/rockchip-io-domain.c             | 10 ++++++-
 9 files changed, 105 insertions(+), 66 deletions(-)

-- 
2.6.4



From heiko at sntech.de  Fri Feb  5 13:20:15 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  5 Feb 2016 22:20:15 +0100
Subject: [PATCH 2/5] ARM: dts: rockchip: make rk3288-grf a simple-mfd
In-Reply-To: <1454707218-23676-1-git-send-email-heiko@sntech.de>
References: <1454707218-23676-1-git-send-email-heiko@sntech.de>
Message-ID: <1454707218-23676-3-git-send-email-heiko@sntech.de>

Similar to the pmu, the general register files contain a lot of different
setting bits grouped into general registers, but also some somewhat special
entities like the controls for some phy-blocks or the io-voltage control.
To be able to move these blocks under the grf node where they actually
belong, make it a simple-mfd.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 arch/arm/boot/dts/rk3288.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 3d46327..8e49c17 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -748,7 +748,7 @@
 	};
 
 	grf: syscon at ff770000 {
-		compatible = "rockchip,rk3288-grf", "syscon";
+		compatible = "rockchip,rk3288-grf", "syscon", "simple-mfd";
 		reg = <0xff770000 0x1000>;
 	};
 
-- 
2.6.4



From heiko at sntech.de  Fri Feb  5 13:20:17 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  5 Feb 2016 22:20:17 +0100
Subject: [PATCH 4/5] arm64: dts: rockchip: make rk3368 grf syscons simple-mfds
 as well
In-Reply-To: <1454707218-23676-1-git-send-email-heiko@sntech.de>
References: <1454707218-23676-1-git-send-email-heiko@sntech.de>
Message-ID: <1454707218-23676-5-git-send-email-heiko@sntech.de>

The general register files do contain a lot of separate functions and
while some really are only registers with a lot of different 1-bit
settings, there are also a lot of them containing some bigger function
blocks. To be able to define these as sub-devices, make them simple-mfds.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 49d1191..6029310 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -556,7 +556,7 @@
 	};
 
 	pmugrf: syscon at ff738000 {
-		compatible = "rockchip,rk3368-pmugrf", "syscon";
+		compatible = "rockchip,rk3368-pmugrf", "syscon", "simple-mfd";
 		reg = <0x0 0xff738000 0x0 0x1000>;
 	};
 
@@ -569,7 +569,7 @@
 	};
 
 	grf: syscon at ff770000 {
-		compatible = "rockchip,rk3368-grf", "syscon";
+		compatible = "rockchip,rk3368-grf", "syscon", "simple-mfd";
 		reg = <0x0 0xff770000 0x0 0x1000>;
 	};
 
-- 
2.6.4



From heiko at sntech.de  Fri Feb  5 13:20:14 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  5 Feb 2016 22:20:14 +0100
Subject: [PATCH 1/5] PM / AVS: rockchip-io: make io-domains a child of the GRF
In-Reply-To: <1454707218-23676-1-git-send-email-heiko@sntech.de>
References: <1454707218-23676-1-git-send-email-heiko@sntech.de>
Message-ID: <1454707218-23676-2-git-send-email-heiko@sntech.de>

IO-domain handling is part of the general register files, so should live
under the grf directly. This change allows the grf to be a simple-mfd and
the io-domains fetching the syscon regmap from that parent-node.

The old binding is of course preserved, though deprecated.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 Documentation/devicetree/bindings/power/rockchip-io-domain.txt |  4 +++-
 drivers/power/avs/rockchip-io-domain.c                         | 10 +++++++++-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/power/rockchip-io-domain.txt b/Documentation/devicetree/bindings/power/rockchip-io-domain.txt
index b8627e7..7ed5518 100644
--- a/Documentation/devicetree/bindings/power/rockchip-io-domain.txt
+++ b/Documentation/devicetree/bindings/power/rockchip-io-domain.txt
@@ -35,8 +35,10 @@ Required properties:
   - "rockchip,rk3288-io-voltage-domain" for rk3288
   - "rockchip,rk3368-io-voltage-domain" for rk3368
   - "rockchip,rk3368-pmu-io-voltage-domain" for rk3368 pmu-domains
-- rockchip,grf: phandle to the syscon managing the "general register files"
 
+Deprecated properties:
+- rockchip,grf: phandle to the syscon managing the "general register files"
+    Systems should move the io-domains to a sub-node of the grf simple-mfd.
 
 You specify supplies using the standard regulator bindings by including
 a phandle the relevant regulator.  All specified supplies must be able
diff --git a/drivers/power/avs/rockchip-io-domain.c b/drivers/power/avs/rockchip-io-domain.c
index 8099456..a5a07d8 100644
--- a/drivers/power/avs/rockchip-io-domain.c
+++ b/drivers/power/avs/rockchip-io-domain.c
@@ -278,6 +278,7 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
 	struct device_node *np = pdev->dev.of_node;
 	const struct of_device_id *match;
 	struct rockchip_iodomain *iod;
+	struct device *parent;
 	int i, ret = 0;
 
 	if (!np)
@@ -293,7 +294,14 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
 	match = of_match_node(rockchip_iodomain_match, np);
 	iod->soc_data = (struct rockchip_iodomain_soc_data *)match->data;
 
-	iod->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+	parent = pdev->dev.parent;
+	if (parent && parent->of_node) {
+		iod->grf = syscon_node_to_regmap(parent->of_node);
+	} else {
+		dev_dbg(&pdev->dev, "falling back to old binding\n");
+		iod->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+	}
+
 	if (IS_ERR(iod->grf)) {
 		dev_err(&pdev->dev, "couldn't find grf regmap\n");
 		return PTR_ERR(iod->grf);
-- 
2.6.4



From heiko at sntech.de  Fri Feb  5 13:20:16 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri,  5 Feb 2016 22:20:16 +0100
Subject: [PATCH 3/5] ARM: dts: rockchip: move rk3288 io-domain nodes to the grf
In-Reply-To: <1454707218-23676-1-git-send-email-heiko@sntech.de>
References: <1454707218-23676-1-git-send-email-heiko@sntech.de>
Message-ID: <1454707218-23676-4-git-send-email-heiko@sntech.de>

io-voltage control is actually part of the grf, so move the node under the
newly available grf simple-mfd.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 arch/arm/boot/dts/rk3288-firefly.dtsi   | 33 ++++++++++++++++----------------
 arch/arm/boot/dts/rk3288-popmetal.dts   | 34 +++++++++++++++++----------------
 arch/arm/boot/dts/rk3288-rock2-som.dtsi | 34 +++++++++++++++++----------------
 arch/arm/boot/dts/rk3288-veyron.dtsi    | 28 ++++++++++++++-------------
 4 files changed, 68 insertions(+), 61 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi b/arch/arm/boot/dts/rk3288-firefly.dtsi
index 49ec20d..f219389 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -63,22 +63,6 @@
 		clock-output-names = "ext_gmac";
 	};
 
-	io_domains: io-domains {
-		compatible = "rockchip,rk3288-io-voltage-domain";
-		rockchip,grf = <&grf>;
-
-		audio-supply = <&vcca_33>;
-		bb-supply = <&vcc_io>;
-		dvp-supply = <&dovdd_1v8>;
-		flash0-supply = <&vcc_flash>;
-		flash1-supply = <&vcc_lan>;
-		gpio30-supply = <&vcc_io>;
-		gpio1830-supply = <&vcc_io>;
-		lcdc-supply = <&vcc_io>;
-		sdcard-supply = <&vccio_sd>;
-		wifi-supply = <&vccio_wl>;
-	};
-
 	ir: ir-receiver {
 		compatible = "gpio-ir-receiver";
 		pinctrl-names = "default";
@@ -237,6 +221,23 @@
 	status = "ok";
 };
 
+&grf {
+	io_domains: io-domains {
+		compatible = "rockchip,rk3288-io-voltage-domain";
+
+		audio-supply = <&vcca_33>;
+		bb-supply = <&vcc_io>;
+		dvp-supply = <&dovdd_1v8>;
+		flash0-supply = <&vcc_flash>;
+		flash1-supply = <&vcc_lan>;
+		gpio30-supply = <&vcc_io>;
+		gpio1830-supply = <&vcc_io>;
+		lcdc-supply = <&vcc_io>;
+		sdcard-supply = <&vccio_sd>;
+		wifi-supply = <&vccio_wl>;
+	};
+};
+
 &hdmi {
 	ddc-i2c-bus = <&i2c5>;
 	status = "okay";
diff --git a/arch/arm/boot/dts/rk3288-popmetal.dts b/arch/arm/boot/dts/rk3288-popmetal.dts
index 65c4756..4d434f7 100644
--- a/arch/arm/boot/dts/rk3288-popmetal.dts
+++ b/arch/arm/boot/dts/rk3288-popmetal.dts
@@ -79,22 +79,6 @@
 		};
 	};
 
-	io_domains: io-domains {
-		compatible = "rockchip,rk3288-io-voltage-domain";
-		rockchip,grf = <&grf>;
-
-		audio-supply = <&vcca_33>;
-		bb-supply = <&vcc_io>;
-		dvp-supply = <&vcc18_dvp>;
-		flash0-supply = <&vcc_flash>;
-		flash1-supply = <&vcc_lan>;
-		gpio30-supply = <&vcc_io>;
-		gpio1830-supply = <&vcc_io>;
-		lcdc-supply = <&vcc_io>;
-		sdcard-supply = <&vccio_sd>;
-		wifi-supply = <&vccio_wl>;
-	};
-
 	ir: ir-receiver {
 		compatible = "gpio-ir-receiver";
 		gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
@@ -205,6 +189,24 @@
 	status = "ok";
 };
 
+&grf {
+	io_domains: io-domains {
+		compatible = "rockchip,rk3288-io-voltage-domain";
+		rockchip,grf = <&grf>;
+
+		audio-supply = <&vcca_33>;
+		bb-supply = <&vcc_io>;
+		dvp-supply = <&vcc18_dvp>;
+		flash0-supply = <&vcc_flash>;
+		flash1-supply = <&vcc_lan>;
+		gpio30-supply = <&vcc_io>;
+		gpio1830-supply = <&vcc_io>;
+		lcdc-supply = <&vcc_io>;
+		sdcard-supply = <&vccio_sd>;
+		wifi-supply = <&vccio_wl>;
+	};
+};
+
 &hdmi {
 	ddc-i2c-bus = <&i2c5>;
 	status = "okay";
diff --git a/arch/arm/boot/dts/rk3288-rock2-som.dtsi b/arch/arm/boot/dts/rk3288-rock2-som.dtsi
index e1ee9f9..8660b8a 100644
--- a/arch/arm/boot/dts/rk3288-rock2-som.dtsi
+++ b/arch/arm/boot/dts/rk3288-rock2-som.dtsi
@@ -61,22 +61,6 @@
 		clock-output-names = "ext_gmac";
 	};
 
-	io_domains: io-domains {
-		compatible = "rockchip,rk3288-io-voltage-domain";
-		rockchip,grf = <&grf>;
-
-		audio-supply = <&vcc_io>;
-		bb-supply = <&vcc_io>;
-		dvp-supply = <&vcc_18>;
-		flash0-supply = <&vcc_flash>;
-		flash1-supply = <&vccio_pmu>;
-		gpio30-supply = <&vccio_pmu>;
-		gpio1830 = <&vcc_io>;
-		lcdc-supply = <&vcc_io>;
-		sdcard-supply = <&vccio_sd>;
-		wifi-supply = <&vcc_18>;
-	};
-
 	vcc_flash: flash-regulator {
 		compatible = "regulator-fixed";
 		regulator-name = "vcc_sys";
@@ -129,6 +113,24 @@
 	tx_delay = <0x30>;
 };
 
+&grf {
+	io_domains: io-domains {
+		compatible = "rockchip,rk3288-io-voltage-domain";
+		rockchip,grf = <&grf>;
+
+		audio-supply = <&vcc_io>;
+		bb-supply = <&vcc_io>;
+		dvp-supply = <&vcc_18>;
+		flash0-supply = <&vcc_flash>;
+		flash1-supply = <&vccio_pmu>;
+		gpio30-supply = <&vccio_pmu>;
+		gpio1830 = <&vcc_io>;
+		lcdc-supply = <&vcc_io>;
+		sdcard-supply = <&vccio_sd>;
+		wifi-supply = <&vcc_18>;
+	};
+};
+
 &i2c0 {
 	status = "okay";
 
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 0a43e21..fd55697 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -83,19 +83,6 @@
 		reset-gpios = <&gpio2 9 GPIO_ACTIVE_HIGH>;
 	};
 
-	io_domains: io-domains {
-		compatible = "rockchip,rk3288-io-voltage-domain";
-		rockchip,grf = <&grf>;
-
-		bb-supply = <&vcc33_io>;
-		dvp-supply = <&vcc_18>;
-		flash0-supply = <&vcc18_flashio>;
-		gpio1830-supply = <&vcc33_io>;
-		gpio30-supply = <&vcc33_io>;
-		lcdc-supply = <&vcc33_lcd>;
-		wifi-supply = <&vcc18_wl>;
-	};
-
 	sdio_pwrseq: sdio-pwrseq {
 		compatible = "mmc-pwrseq-simple";
 		clocks = <&rk808 RK808_CLKOUT1>;
@@ -159,6 +146,21 @@
 	pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_bus8>;
 };
 
+&grf {
+	io_domains: io-domains {
+		compatible = "rockchip,rk3288-io-voltage-domain";
+		rockchip,grf = <&grf>;
+
+		bb-supply = <&vcc33_io>;
+		dvp-supply = <&vcc_18>;
+		flash0-supply = <&vcc18_flashio>;
+		gpio1830-supply = <&vcc33_io>;
+		gpio30-supply = <&vcc33_io>;
+		lcdc-supply = <&vcc33_lcd>;
+		wifi-supply = <&vcc18_wl>;
+	};
+};
+
 &hdmi {
 	ddc-i2c-bus = <&i2c5>;
 	status = "okay";
-- 
2.6.4



From yang.shi at linaro.org  Fri Feb  5 13:25:47 2016
From: yang.shi at linaro.org (Shi, Yang)
Date: Fri, 5 Feb 2016 13:25:47 -0800
Subject: [PATCH] arm64: reenable interrupt when handling ptrace breakpoint
In-Reply-To: <56969312.7070309@linaro.org>
References: <1450225088-2456-1-git-send-email-yang.shi@linaro.org>
 <20151216111316.GD4308@arm.com> <5671CD5B.9030907@linaro.org>
 <20151221104818.GF23092@arm.com> <alpine.DEB.2.11.1512211749180.28591@nanos>
 <20151221170028.GT23092@arm.com> <56955B3A.5010303@linaro.org>
 <20160113102622.GC25458@arm.com> <569686BA.6050703@linaro.org>
 <20160113172303.GH25458@arm.com> <56969312.7070309@linaro.org>
Message-ID: <56B5135B.3050801@linaro.org>

On 1/13/2016 10:10 AM, Shi, Yang wrote:
> On 1/13/2016 9:23 AM, Will Deacon wrote:
>> On Wed, Jan 13, 2016 at 09:17:46AM -0800, Shi, Yang wrote:
>>> On 1/13/2016 2:26 AM, Will Deacon wrote:
>>>> On Tue, Jan 12, 2016 at 11:59:54AM -0800, Shi, Yang wrote:
>>>>> This might be buried in email storm during the holiday. Just want
>>>>> to double
>>>>> check the status. I'm supposed there is no objection for getting it
>>>>> merged
>>>>> in upstream?
>>>>
>>>> Sorry, when you replied with:
>>>>
>>>>> I think we could just extend the "signal delay send" approach from
>>>>> x86-64
>>>>> to arm64, which is currently used by x86-64 on -rt kernel only.
>>>>
>>>> I understood that you were going to fix -rt, so I dropped this pending
>>>> anything more from you.
>>>>
>>>> What's the plan?
>>>
>>> Sorry for the confusion. The "signal delay send" approach used by
>>> x86-64 -rt
>>> should be not necessary for arm64 right now. Reenabling interrupt is
>>> still
>>> the preferred approach.
>>>
>>> Since x86-64 has per-CPU IST exception stack, so preemption has to be
>>> disabled all the time. However, it is not applicable to other
>>> architectures
>>> for now, including arm64.
>>
>> Actually, we grew support for a separate IRQ stack in the recent merge
>> window. Does that change things here, or are you referring to something
>> else?
>
> Had a quick look at the patches, it looks the irq stack is not nestable
> and it switches back to the original stack as long as irq handler is
> done before preempt happens. So, it sounds it won't change things here.


Just had a quick test on 4.5-rc1. It survives with kgdbts, ptrace and 
ltp. So, it sounds safe with the "separate IRQ stack" change.

Thanks,
Yang

>
> Thanks.,
> Yang
>
>>
>> Will
>>
>



From keescook at chromium.org  Fri Feb  5 13:48:38 2016
From: keescook at chromium.org (Kees Cook)
Date: Fri, 5 Feb 2016 13:48:38 -0800
Subject: [PATCH v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA
In-Reply-To: <20160104220743.GP19062@n2100.arm.linux.org.uk>
References: <20151202202725.GA794@www.outflux.net>
 <20151223195129.GP2793@atomide.com> <567B04AB.6010906@redhat.com>
 <20151223212911.GR2793@atomide.com>
 <alpine.LFD.2.20.1512231637110.3603@knanqh.ubzr>
 <20151224001121.GS2793@atomide.com>
 <20151224003406.GA8644@n2100.arm.linux.org.uk>
 <CAGXu5j+MrX-OvnVTYH0hqF2XgZW10PQOviyN=e5heejLsXewVA@mail.gmail.com>
 <20160104220743.GP19062@n2100.arm.linux.org.uk>
Message-ID: <CAGXu5jJTOZL5yQfj5KuRjVO00mnNL3yd=7ONacYK96yLAOtgKg@mail.gmail.com>

On Mon, Jan 4, 2016 at 2:07 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Mon, Jan 04, 2016 at 12:34:28PM -0800, Kees Cook wrote:
>> On Wed, Dec 23, 2015 at 4:34 PM, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>> > On Wed, Dec 23, 2015 at 04:11:22PM -0800, Tony Lindgren wrote:
>> >> * Nicolas Pitre <nicolas.pitre at linaro.org> [151223 13:45]:
>> >> > We fixed a bunch of similar issues where code was located in the .data
>> >> > section for ease of use from assembly code.  See commit b4e61537 and
>> >> > d0776aff for example.
>> >>
>> >> Thanks hey some assembly fun for the holidays :) I also need to check what
>> >> all gets relocated to SRAM here.
>> >>
>> >> In any case, seems like the $subject patch is too intrusive for v4.5 at
>> >> this point.
>> >
>> > Given Christmas and an unknown time between that and the merge window
>> > actually opening, I decided Tuesday would be the last day I take any
>> > patches into my tree - and today would be the day that I drop anything
>> > that causes problems.
>> >
>> > So, I've already dropped this, so tomorrow's linux-next should not have
>> > this change.
>> >
>> > You'll still see breakage if people enable RODATA though, but that's no
>> > different from previous kernels.
>>
>> Ugh, sorry for the breakage.
>>
>> Should this patch stay as-is and people will fix their various RODATA
>> failures during the next devel window, or should I remove the "default
>> y if CPU_V7"?
>
> I think we'll keep it as-is, and have another go with it at -rc1 time,
> when people have ample chance to then queue up fixes.
>
> They'll have had notice of it, so there's no excuse folk can't work on
> the problem in the mean time.  (But, of course, they won't...)

Hi,

Just checking on this -- I resent it to the patch tracker at -rc1
time. Is this waiting for the other fixes to land first, or is there
something I should be doing?

Thanks!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security


From troy.kisky at boundarydevices.com  Fri Feb  5 13:52:42 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Fri,  5 Feb 2016 14:52:42 -0700
Subject: [PATCH net-next V2 0/8] net: fec: cleanup/fixes
Message-ID: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>


V2 is a rebase on top of johannes endian-safe patch and
is only the 1st eight patches.
The testing for this series was done on a nitrogen6x.
The base commit was
commit b45efa30a626e915192a6c548cd8642379cd47cc
    Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

Testing showed no change in performance.
Testing used imx_v6_v7_defconfig + CONFIG_MICREL_PHY.
The processor was running at 996Mhz.
The following commands were used to get the transfer rates.

On an x86 ubunto system,
iperf -s -i.5 -u


On a nitrogen6x board, running via SD Card.
I first stopped some background processes

stop cron
stop upstart-file-bridge
stop upstart-socket-bridge
stop upstart-udev-bridge
stop rsyslog
stop dbus
killall dhclient
echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

taskset 0x2 iperf -c 192.168.0.201 -u -t60 -b500M -r

There is a branch available on github with this series, and the rest of
my fec patches, for those who would like to test it.
https://github.com:boundarydevices/linux-imx6.git branch net-next_master



Troy Kisky (8):
SDCard
 TX/RX
378/405  before any patches
379/407  net: fec: stop the "rcv is not +last, " error messages
378/405  net: fec: fix rx error counts
379/396  net: fec: fix fec_enet_get_free_txdesc_num
379/403  net: fec: add struct bufdesc_prop
390/396  net: fec: add variable reg_desc_active to speed things up
388/396  net: fec: don't disable FEC_ENET_TS_TIMER interrupt
382/403  net: fec: don't transfer ownership until descriptor write is complete
378/403  net: fec: improve error handling

 drivers/net/ethernet/freescale/fec.h      |  38 ++-
 drivers/net/ethernet/freescale/fec_main.c | 396 ++++++++++++++----------------
 2 files changed, 196 insertions(+), 238 deletions(-)

-- 
2.5.0



From troy.kisky at boundarydevices.com  Fri Feb  5 13:52:43 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Fri,  5 Feb 2016 14:52:43 -0700
Subject: [PATCH net-next V2 1/8] net: fec: stop the "rcv is not +last,
 " error messages
In-Reply-To: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1454709170-19527-2-git-send-email-troy.kisky@boundarydevices.com>

Setting the FTRL register will stop the fec from
trying to use multiple receive buffers.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec.h      | 1 +
 drivers/net/ethernet/freescale/fec_main.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 2106d72..cc9677a 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -64,6 +64,7 @@
 #define FEC_R_FIFO_RSEM		0x194 /* Receive FIFO section empty threshold */
 #define FEC_R_FIFO_RAEM		0x198 /* Receive FIFO almost empty threshold */
 #define FEC_R_FIFO_RAFL		0x19c /* Receive FIFO almost full threshold */
+#define FEC_FTRL		0x1b0 /* Frame truncation receive length*/
 #define FEC_RACC		0x1c4 /* Receive Accelerator function */
 #define FEC_RCMR_1		0x1c8 /* Receive classification match ring 1 */
 #define FEC_RCMR_2		0x1cc /* Receive classification match ring 2 */
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 41c81f6..3e5b24a 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -988,6 +988,7 @@ fec_restart(struct net_device *ndev)
 			val &= ~FEC_RACC_OPTIONS;
 		writel(val, fep->hwp + FEC_RACC);
 	}
+	writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_FTRL);
 #endif
 
 	/*
-- 
2.5.0



From troy.kisky at boundarydevices.com  Fri Feb  5 13:52:44 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Fri,  5 Feb 2016 14:52:44 -0700
Subject: [PATCH net-next V2 2/8] net: fec: fix rx error counts
In-Reply-To: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1454709170-19527-3-git-send-email-troy.kisky@boundarydevices.com>

On an overrun, the other flags are not
valid, so don't check them.

Also, don't pass bad frames up the stack.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 36 +++++++++++++------------------
 1 file changed, 15 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 3e5b24a..162fa59 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1408,37 +1408,31 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
 			break;
 		pkt_received++;
 
-		/* Since we have allocated space to hold a complete frame,
-		 * the last indicator should be set.
-		 */
-		if ((status & BD_ENET_RX_LAST) == 0)
-			netdev_err(ndev, "rcv is not +last\n");
-
 		writel(FEC_ENET_RXF, fep->hwp + FEC_IEVENT);
 
 		/* Check for errors. */
+		status ^= BD_ENET_RX_LAST;
 		if (status & (BD_ENET_RX_LG | BD_ENET_RX_SH | BD_ENET_RX_NO |
-			   BD_ENET_RX_CR | BD_ENET_RX_OV)) {
+			   BD_ENET_RX_CR | BD_ENET_RX_OV | BD_ENET_RX_LAST |
+			   BD_ENET_RX_CL)) {
 			ndev->stats.rx_errors++;
-			if (status & (BD_ENET_RX_LG | BD_ENET_RX_SH)) {
+			if (status & BD_ENET_RX_OV) {
+				/* FIFO overrun */
+				ndev->stats.rx_fifo_errors++;
+				goto rx_processing_done;
+			}
+			if (status & (BD_ENET_RX_LG | BD_ENET_RX_SH
+						| BD_ENET_RX_LAST)) {
 				/* Frame too long or too short. */
 				ndev->stats.rx_length_errors++;
+				if (status & BD_ENET_RX_LAST)
+					netdev_err(ndev, "rcv is not +last\n");
 			}
-			if (status & BD_ENET_RX_NO)	/* Frame alignment */
-				ndev->stats.rx_frame_errors++;
 			if (status & BD_ENET_RX_CR)	/* CRC Error */
 				ndev->stats.rx_crc_errors++;
-			if (status & BD_ENET_RX_OV)	/* FIFO overrun */
-				ndev->stats.rx_fifo_errors++;
-		}
-
-		/* Report late collisions as a frame error.
-		 * On this error, the BD is closed, but we don't know what we
-		 * have in the buffer.  So, just drop this frame on the floor.
-		 */
-		if (status & BD_ENET_RX_CL) {
-			ndev->stats.rx_errors++;
-			ndev->stats.rx_frame_errors++;
+			/* Report late collisions as a frame error. */
+			if (status & (BD_ENET_RX_NO | BD_ENET_RX_CL))
+				ndev->stats.rx_frame_errors++;
 			goto rx_processing_done;
 		}
 
-- 
2.5.0



From troy.kisky at boundarydevices.com  Fri Feb  5 13:52:45 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Fri,  5 Feb 2016 14:52:45 -0700
Subject: [PATCH net-next V2 3/8] net: fec: fix fec_enet_get_free_txdesc_num
In-Reply-To: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1454709170-19527-4-git-send-email-troy.kisky@boundarydevices.com>

When first initialized, cur_tx points to the 1st
entry in the queue, and dirty_tx points to the last.
At this point, fec_enet_get_free_txdesc_num will
return tx_ring_size -2. If tx_ring_size -2 entries
are now queued, then fec_enet_get_free_txdesc_num
should return 0, but it returns tx_ring_size instead.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 162fa59..adbddfd 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -296,7 +296,7 @@ static int fec_enet_get_free_txdesc_num(struct fec_enet_private *fep,
 	entries = ((const char *)txq->dirty_tx -
 			(const char *)txq->cur_tx) / fep->bufdesc_size - 1;
 
-	return entries > 0 ? entries : entries + txq->tx_ring_size;
+	return entries >= 0 ? entries : entries + txq->tx_ring_size;
 }
 
 static void swap_buffer(void *bufaddr, int len)
-- 
2.5.0



From troy.kisky at boundarydevices.com  Fri Feb  5 13:52:46 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Fri,  5 Feb 2016 14:52:46 -0700
Subject: [PATCH net-next V2 4/8] net: fec: add struct bufdesc_prop
In-Reply-To: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1454709170-19527-5-git-send-email-troy.kisky@boundarydevices.com>

This reduces code and gains speed.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec.h      |  29 ++-
 drivers/net/ethernet/freescale/fec_main.c | 288 ++++++++++++------------------
 2 files changed, 132 insertions(+), 185 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index cc9677a..53ec04f 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -448,33 +448,34 @@ struct bufdesc_ex {
 /* Controller supports RACC register */
 #define FEC_QUIRK_HAS_RACC		(1 << 12)
 
+struct bufdesc_prop {
+	int qid;
+	/* Address of Rx and Tx buffers */
+	struct bufdesc	*base;
+	struct bufdesc	*last;
+	struct bufdesc	*cur;
+	dma_addr_t	dma;
+	unsigned short ring_size;
+	unsigned char dsize;
+	unsigned char dsize_log2;
+};
+
 struct fec_enet_priv_tx_q {
-	int index;
+	struct bufdesc_prop bd;
 	unsigned char *tx_bounce[TX_RING_SIZE];
 	struct  sk_buff *tx_skbuff[TX_RING_SIZE];
 
-	dma_addr_t	bd_dma;
-	struct bufdesc	*tx_bd_base;
-	uint tx_ring_size;
-
 	unsigned short tx_stop_threshold;
 	unsigned short tx_wake_threshold;
 
-	struct bufdesc	*cur_tx;
 	struct bufdesc	*dirty_tx;
 	char *tso_hdrs;
 	dma_addr_t tso_hdrs_dma;
 };
 
 struct fec_enet_priv_rx_q {
-	int index;
+	struct bufdesc_prop bd;
 	struct  sk_buff *rx_skbuff[RX_RING_SIZE];
-
-	dma_addr_t	bd_dma;
-	struct bufdesc	*rx_bd_base;
-	uint rx_ring_size;
-
-	struct bufdesc	*cur_rx;
 };
 
 /* The FEC buffer descriptors track the ring buffers.  The rx_bd_base and
@@ -514,8 +515,6 @@ struct fec_enet_private {
 	unsigned long work_ts;
 	unsigned long work_mdio;
 
-	unsigned short bufdesc_size;
-
 	struct	platform_device *pdev;
 
 	int	dev_id;
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index adbddfd..b039288 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -217,86 +217,38 @@ MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
 
 #define IS_TSO_HEADER(txq, addr) \
 	((addr >= txq->tso_hdrs_dma) && \
-	(addr < txq->tso_hdrs_dma + txq->tx_ring_size * TSO_HEADER_SIZE))
+	(addr < txq->tso_hdrs_dma + txq->bd.ring_size * TSO_HEADER_SIZE))
 
 static int mii_cnt;
 
-static inline
-struct bufdesc *fec_enet_get_nextdesc(struct bufdesc *bdp,
-				      struct fec_enet_private *fep,
-				      int queue_id)
-{
-	struct bufdesc *new_bd = bdp + 1;
-	struct bufdesc_ex *ex_new_bd = (struct bufdesc_ex *)bdp + 1;
-	struct fec_enet_priv_tx_q *txq = fep->tx_queue[queue_id];
-	struct fec_enet_priv_rx_q *rxq = fep->rx_queue[queue_id];
-	struct bufdesc_ex *ex_base;
-	struct bufdesc *base;
-	int ring_size;
-
-	if (bdp >= txq->tx_bd_base) {
-		base = txq->tx_bd_base;
-		ring_size = txq->tx_ring_size;
-		ex_base = (struct bufdesc_ex *)txq->tx_bd_base;
-	} else {
-		base = rxq->rx_bd_base;
-		ring_size = rxq->rx_ring_size;
-		ex_base = (struct bufdesc_ex *)rxq->rx_bd_base;
-	}
-
-	if (fep->bufdesc_ex)
-		return (struct bufdesc *)((ex_new_bd >= (ex_base + ring_size)) ?
-			ex_base : ex_new_bd);
-	else
-		return (new_bd >= (base + ring_size)) ?
-			base : new_bd;
-}
-
-static inline
-struct bufdesc *fec_enet_get_prevdesc(struct bufdesc *bdp,
-				      struct fec_enet_private *fep,
-				      int queue_id)
-{
-	struct bufdesc *new_bd = bdp - 1;
-	struct bufdesc_ex *ex_new_bd = (struct bufdesc_ex *)bdp - 1;
-	struct fec_enet_priv_tx_q *txq = fep->tx_queue[queue_id];
-	struct fec_enet_priv_rx_q *rxq = fep->rx_queue[queue_id];
-	struct bufdesc_ex *ex_base;
-	struct bufdesc *base;
-	int ring_size;
-
-	if (bdp >= txq->tx_bd_base) {
-		base = txq->tx_bd_base;
-		ring_size = txq->tx_ring_size;
-		ex_base = (struct bufdesc_ex *)txq->tx_bd_base;
-	} else {
-		base = rxq->rx_bd_base;
-		ring_size = rxq->rx_ring_size;
-		ex_base = (struct bufdesc_ex *)rxq->rx_bd_base;
-	}
+static struct bufdesc *fec_enet_get_nextdesc(struct bufdesc *bdp,
+					     struct bufdesc_prop *bd)
+{
+	return (bdp >= bd->last) ? bd->base
+			: (struct bufdesc *)(((unsigned)bdp) + bd->dsize);
+}
 
-	if (fep->bufdesc_ex)
-		return (struct bufdesc *)((ex_new_bd < ex_base) ?
-			(ex_new_bd + ring_size) : ex_new_bd);
-	else
-		return (new_bd < base) ? (new_bd + ring_size) : new_bd;
+static struct bufdesc *fec_enet_get_prevdesc(struct bufdesc *bdp,
+					     struct bufdesc_prop *bd)
+{
+	return (bdp <= bd->base) ? bd->last
+			: (struct bufdesc *)(((unsigned)bdp) - bd->dsize);
 }
 
-static int fec_enet_get_bd_index(struct bufdesc *base, struct bufdesc *bdp,
-				struct fec_enet_private *fep)
+static int fec_enet_get_bd_index(struct bufdesc *bdp,
+				 struct bufdesc_prop *bd)
 {
-	return ((const char *)bdp - (const char *)base) / fep->bufdesc_size;
+	return ((const char *)bdp - (const char *)bd->base) >> bd->dsize_log2;
 }
 
-static int fec_enet_get_free_txdesc_num(struct fec_enet_private *fep,
-					struct fec_enet_priv_tx_q *txq)
+static int fec_enet_get_free_txdesc_num(struct fec_enet_priv_tx_q *txq)
 {
 	int entries;
 
-	entries = ((const char *)txq->dirty_tx -
-			(const char *)txq->cur_tx) / fep->bufdesc_size - 1;
+	entries = (((const char *)txq->dirty_tx -
+			(const char *)txq->bd.cur) >> txq->bd.dsize_log2) - 1;
 
-	return entries >= 0 ? entries : entries + txq->tx_ring_size;
+	return entries >= 0 ? entries : entries + txq->bd.ring_size;
 }
 
 static void swap_buffer(void *bufaddr, int len)
@@ -329,20 +281,20 @@ static void fec_dump(struct net_device *ndev)
 	pr_info("Nr     SC     addr       len  SKB\n");
 
 	txq = fep->tx_queue[0];
-	bdp = txq->tx_bd_base;
+	bdp = txq->bd.base;
 
 	do {
 		pr_info("%3u %c%c 0x%04x 0x%08x %4u %p\n",
 			index,
-			bdp == txq->cur_tx ? 'S' : ' ',
+			bdp == txq->bd.cur ? 'S' : ' ',
 			bdp == txq->dirty_tx ? 'H' : ' ',
 			fec16_to_cpu(bdp->cbd_sc),
 			fec32_to_cpu(bdp->cbd_bufaddr),
 			fec16_to_cpu(bdp->cbd_datlen),
 			txq->tx_skbuff[index]);
-		bdp = fec_enet_get_nextdesc(bdp, fep, 0);
+		bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
 		index++;
-	} while (bdp != txq->tx_bd_base);
+	} while (bdp != txq->bd.base);
 }
 
 static inline bool is_ipv4_pkt(struct sk_buff *skb)
@@ -373,7 +325,7 @@ fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
 			     struct net_device *ndev)
 {
 	struct fec_enet_private *fep = netdev_priv(ndev);
-	struct bufdesc *bdp = txq->cur_tx;
+	struct bufdesc *bdp = txq->bd.cur;
 	struct bufdesc_ex *ebdp;
 	int nr_frags = skb_shinfo(skb)->nr_frags;
 	unsigned short queue = skb_get_queue_mapping(skb);
@@ -388,7 +340,7 @@ fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
 
 	for (frag = 0; frag < nr_frags; frag++) {
 		this_frag = &skb_shinfo(skb)->frags[frag];
-		bdp = fec_enet_get_nextdesc(bdp, fep, queue);
+		bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
 		ebdp = (struct bufdesc_ex *)bdp;
 
 		status = fec16_to_cpu(bdp->cbd_sc);
@@ -418,7 +370,7 @@ fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
 
 		bufaddr = page_address(this_frag->page.p) + this_frag->page_offset;
 
-		index = fec_enet_get_bd_index(txq->tx_bd_base, bdp, fep);
+		index = fec_enet_get_bd_index(bdp, &txq->bd);
 		if (((unsigned long) bufaddr) & fep->tx_align ||
 			fep->quirks & FEC_QUIRK_SWAP_FRAME) {
 			memcpy(txq->tx_bounce[index], bufaddr, frag_len);
@@ -444,9 +396,9 @@ fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
 
 	return bdp;
 dma_mapping_error:
-	bdp = txq->cur_tx;
+	bdp = txq->bd.cur;
 	for (i = 0; i < frag; i++) {
-		bdp = fec_enet_get_nextdesc(bdp, fep, queue);
+		bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
 		dma_unmap_single(&fep->pdev->dev, fec32_to_cpu(bdp->cbd_bufaddr),
 				 fec16_to_cpu(bdp->cbd_datlen), DMA_TO_DEVICE);
 	}
@@ -468,7 +420,7 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 	unsigned int index;
 	int entries_free;
 
-	entries_free = fec_enet_get_free_txdesc_num(fep, txq);
+	entries_free = fec_enet_get_free_txdesc_num(txq);
 	if (entries_free < MAX_SKB_FRAGS + 1) {
 		dev_kfree_skb_any(skb);
 		if (net_ratelimit())
@@ -483,7 +435,7 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 	}
 
 	/* Fill in a Tx ring entry */
-	bdp = txq->cur_tx;
+	bdp = txq->bd.cur;
 	last_bdp = bdp;
 	status = fec16_to_cpu(bdp->cbd_sc);
 	status &= ~BD_ENET_TX_STATS;
@@ -493,7 +445,7 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 	buflen = skb_headlen(skb);
 
 	queue = skb_get_queue_mapping(skb);
-	index = fec_enet_get_bd_index(txq->tx_bd_base, bdp, fep);
+	index = fec_enet_get_bd_index(bdp, &txq->bd);
 	if (((unsigned long) bufaddr) & fep->tx_align ||
 		fep->quirks & FEC_QUIRK_SWAP_FRAME) {
 		memcpy(txq->tx_bounce[index], skb->data, buflen);
@@ -544,7 +496,7 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 		ebdp->cbd_esc = cpu_to_fec32(estatus);
 	}
 
-	index = fec_enet_get_bd_index(txq->tx_bd_base, last_bdp, fep);
+	index = fec_enet_get_bd_index(last_bdp, &txq->bd);
 	/* Save skb pointer */
 	txq->tx_skbuff[index] = skb;
 
@@ -558,15 +510,15 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 	bdp->cbd_sc = cpu_to_fec16(status);
 
 	/* If this was the last BD in the ring, start at the beginning again. */
-	bdp = fec_enet_get_nextdesc(last_bdp, fep, queue);
+	bdp = fec_enet_get_nextdesc(last_bdp, &txq->bd);
 
 	skb_tx_timestamp(skb);
 
 	/* Make sure the update to bdp and tx_skbuff are performed before
-	 * cur_tx.
+	 * txq->bd.cur.
 	 */
 	wmb();
-	txq->cur_tx = bdp;
+	txq->bd.cur = bdp;
 
 	/* Trigger transmission start */
 	writel(0, fep->hwp + FEC_X_DES_ACTIVE(queue));
@@ -697,13 +649,13 @@ static int fec_enet_txq_submit_tso(struct fec_enet_priv_tx_q *txq,
 	struct fec_enet_private *fep = netdev_priv(ndev);
 	int hdr_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
 	int total_len, data_left;
-	struct bufdesc *bdp = txq->cur_tx;
+	struct bufdesc *bdp = txq->bd.cur;
 	unsigned short queue = skb_get_queue_mapping(skb);
 	struct tso_t tso;
 	unsigned int index = 0;
 	int ret;
 
-	if (tso_count_descs(skb) >= fec_enet_get_free_txdesc_num(fep, txq)) {
+	if (tso_count_descs(skb) >= fec_enet_get_free_txdesc_num(txq)) {
 		dev_kfree_skb_any(skb);
 		if (net_ratelimit())
 			netdev_err(ndev, "NOT enough BD for TSO!\n");
@@ -723,7 +675,7 @@ static int fec_enet_txq_submit_tso(struct fec_enet_priv_tx_q *txq,
 	while (total_len > 0) {
 		char *hdr;
 
-		index = fec_enet_get_bd_index(txq->tx_bd_base, bdp, fep);
+		index = fec_enet_get_bd_index(bdp, &txq->bd);
 		data_left = min_t(int, skb_shinfo(skb)->gso_size, total_len);
 		total_len -= data_left;
 
@@ -738,9 +690,8 @@ static int fec_enet_txq_submit_tso(struct fec_enet_priv_tx_q *txq,
 			int size;
 
 			size = min_t(int, tso.size, data_left);
-			bdp = fec_enet_get_nextdesc(bdp, fep, queue);
-			index = fec_enet_get_bd_index(txq->tx_bd_base,
-						      bdp, fep);
+			bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
+			index = fec_enet_get_bd_index(bdp, &txq->bd);
 			ret = fec_enet_txq_put_data_tso(txq, skb, ndev,
 							bdp, index,
 							tso.data, size,
@@ -753,14 +704,14 @@ static int fec_enet_txq_submit_tso(struct fec_enet_priv_tx_q *txq,
 			tso_build_data(skb, &tso, size);
 		}
 
-		bdp = fec_enet_get_nextdesc(bdp, fep, queue);
+		bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
 	}
 
 	/* Save skb pointer */
 	txq->tx_skbuff[index] = skb;
 
 	skb_tx_timestamp(skb);
-	txq->cur_tx = bdp;
+	txq->bd.cur = bdp;
 
 	/* Trigger transmission start */
 	if (!(fep->quirks & FEC_QUIRK_ERR007885) ||
@@ -798,7 +749,7 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
 	if (ret)
 		return ret;
 
-	entries_free = fec_enet_get_free_txdesc_num(fep, txq);
+	entries_free = fec_enet_get_free_txdesc_num(txq);
 	if (entries_free <= txq->tx_stop_threshold)
 		netif_tx_stop_queue(nq);
 
@@ -819,32 +770,32 @@ static void fec_enet_bd_init(struct net_device *dev)
 	for (q = 0; q < fep->num_rx_queues; q++) {
 		/* Initialize the receive buffer descriptors. */
 		rxq = fep->rx_queue[q];
-		bdp = rxq->rx_bd_base;
+		bdp = rxq->bd.base;
 
-		for (i = 0; i < rxq->rx_ring_size; i++) {
+		for (i = 0; i < rxq->bd.ring_size; i++) {
 
 			/* Initialize the BD for every fragment in the page. */
 			if (bdp->cbd_bufaddr)
 				bdp->cbd_sc = cpu_to_fec16(BD_ENET_RX_EMPTY);
 			else
 				bdp->cbd_sc = cpu_to_fec16(0);
-			bdp = fec_enet_get_nextdesc(bdp, fep, q);
+			bdp = fec_enet_get_nextdesc(bdp, &rxq->bd);
 		}
 
 		/* Set the last buffer to wrap */
-		bdp = fec_enet_get_prevdesc(bdp, fep, q);
+		bdp = fec_enet_get_prevdesc(bdp, &rxq->bd);
 		bdp->cbd_sc |= cpu_to_fec16(BD_SC_WRAP);
 
-		rxq->cur_rx = rxq->rx_bd_base;
+		rxq->bd.cur = rxq->bd.base;
 	}
 
 	for (q = 0; q < fep->num_tx_queues; q++) {
 		/* ...and the same for transmit */
 		txq = fep->tx_queue[q];
-		bdp = txq->tx_bd_base;
-		txq->cur_tx = bdp;
+		bdp = txq->bd.base;
+		txq->bd.cur = bdp;
 
-		for (i = 0; i < txq->tx_ring_size; i++) {
+		for (i = 0; i < txq->bd.ring_size; i++) {
 			/* Initialize the BD for every fragment in the page. */
 			bdp->cbd_sc = cpu_to_fec16(0);
 			if (txq->tx_skbuff[i]) {
@@ -852,11 +803,11 @@ static void fec_enet_bd_init(struct net_device *dev)
 				txq->tx_skbuff[i] = NULL;
 			}
 			bdp->cbd_bufaddr = cpu_to_fec32(0);
-			bdp = fec_enet_get_nextdesc(bdp, fep, q);
+			bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
 		}
 
 		/* Set the last buffer to wrap */
-		bdp = fec_enet_get_prevdesc(bdp, fep, q);
+		bdp = fec_enet_get_prevdesc(bdp, &txq->bd);
 		bdp->cbd_sc |= cpu_to_fec16(BD_SC_WRAP);
 		txq->dirty_tx = bdp;
 	}
@@ -880,7 +831,7 @@ static void fec_enet_enable_ring(struct net_device *ndev)
 
 	for (i = 0; i < fep->num_rx_queues; i++) {
 		rxq = fep->rx_queue[i];
-		writel(rxq->bd_dma, fep->hwp + FEC_R_DES_START(i));
+		writel(rxq->bd.dma, fep->hwp + FEC_R_DES_START(i));
 		writel(PKT_MAXBLR_SIZE, fep->hwp + FEC_R_BUFF_SIZE(i));
 
 		/* enable DMA1/2 */
@@ -891,7 +842,7 @@ static void fec_enet_enable_ring(struct net_device *ndev)
 
 	for (i = 0; i < fep->num_tx_queues; i++) {
 		txq = fep->tx_queue[i];
-		writel(txq->bd_dma, fep->hwp + FEC_X_DES_START(i));
+		writel(txq->bd.dma, fep->hwp + FEC_X_DES_START(i));
 
 		/* enable DMA1/2 */
 		if (i)
@@ -909,7 +860,7 @@ static void fec_enet_reset_skb(struct net_device *ndev)
 	for (i = 0; i < fep->num_tx_queues; i++) {
 		txq = fep->tx_queue[i];
 
-		for (j = 0; j < txq->tx_ring_size; j++) {
+		for (j = 0; j < txq->bd.ring_size; j++) {
 			if (txq->tx_skbuff[j]) {
 				dev_kfree_skb_any(txq->tx_skbuff[j]);
 				txq->tx_skbuff[j] = NULL;
@@ -1222,16 +1173,16 @@ fec_enet_tx_queue(struct net_device *ndev, u16 queue_id)
 	bdp = txq->dirty_tx;
 
 	/* get next bdp of dirty_tx */
-	bdp = fec_enet_get_nextdesc(bdp, fep, queue_id);
+	bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
 
-	while (bdp != READ_ONCE(txq->cur_tx)) {
-		/* Order the load of cur_tx and cbd_sc */
+	while (bdp != READ_ONCE(txq->bd.cur)) {
+		/* Order the load of bd.cur and cbd_sc */
 		rmb();
 		status = fec16_to_cpu(READ_ONCE(bdp->cbd_sc));
 		if (status & BD_ENET_TX_READY)
 			break;
 
-		index = fec_enet_get_bd_index(txq->tx_bd_base, bdp, fep);
+		index = fec_enet_get_bd_index(bdp, &txq->bd);
 
 		skb = txq->tx_skbuff[index];
 		txq->tx_skbuff[index] = NULL;
@@ -1242,7 +1193,7 @@ fec_enet_tx_queue(struct net_device *ndev, u16 queue_id)
 					 DMA_TO_DEVICE);
 		bdp->cbd_bufaddr = cpu_to_fec32(0);
 		if (!skb) {
-			bdp = fec_enet_get_nextdesc(bdp, fep, queue_id);
+			bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
 			continue;
 		}
 
@@ -1291,19 +1242,19 @@ fec_enet_tx_queue(struct net_device *ndev, u16 queue_id)
 		txq->dirty_tx = bdp;
 
 		/* Update pointer to next buffer descriptor to be transmitted */
-		bdp = fec_enet_get_nextdesc(bdp, fep, queue_id);
+		bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
 
 		/* Since we have freed up a buffer, the ring is no longer full
 		 */
 		if (netif_queue_stopped(ndev)) {
-			entries_free = fec_enet_get_free_txdesc_num(fep, txq);
+			entries_free = fec_enet_get_free_txdesc_num(txq);
 			if (entries_free >= txq->tx_wake_threshold)
 				netif_tx_wake_queue(nq);
 		}
 	}
 
 	/* ERR006538: Keep the transmitter going */
-	if (bdp != txq->cur_tx &&
+	if (bdp != txq->bd.cur &&
 	    readl(fep->hwp + FEC_X_DES_ACTIVE(queue_id)) == 0)
 		writel(0, fep->hwp + FEC_X_DES_ACTIVE(queue_id));
 }
@@ -1367,7 +1318,7 @@ static bool fec_enet_copybreak(struct net_device *ndev, struct sk_buff **skb,
 	return true;
 }
 
-/* During a receive, the cur_rx points to the current incoming buffer.
+/* During a receive, the bd_rx.cur points to the current incoming buffer.
  * When we update through the ring, if the next incoming buffer has
  * not been given to the system, we just set the empty indicator,
  * effectively tossing the packet.
@@ -1400,7 +1351,7 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
 	/* First, grab all of the stats for the incoming packet.
 	 * These get messed up if we get called due to a busy condition.
 	 */
-	bdp = rxq->cur_rx;
+	bdp = rxq->bd.cur;
 
 	while (!((status = fec16_to_cpu(bdp->cbd_sc)) & BD_ENET_RX_EMPTY)) {
 
@@ -1441,7 +1392,7 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
 		pkt_len = fec16_to_cpu(bdp->cbd_datlen);
 		ndev->stats.rx_bytes += pkt_len;
 
-		index = fec_enet_get_bd_index(rxq->rx_bd_base, bdp, fep);
+		index = fec_enet_get_bd_index(bdp, &rxq->bd);
 		skb = rxq->rx_skbuff[index];
 
 		/* The packet length includes FCS, but we don't want to
@@ -1541,7 +1492,7 @@ rx_processing_done:
 		}
 
 		/* Update BD pointer to next entry */
-		bdp = fec_enet_get_nextdesc(bdp, fep, queue_id);
+		bdp = fec_enet_get_nextdesc(bdp, &rxq->bd);
 
 		/* Doing this here will keep the FEC running while we process
 		 * incoming frames.  On a heavily loaded network, we should be
@@ -1549,7 +1500,7 @@ rx_processing_done:
 		 */
 		writel(0, fep->hwp + FEC_R_DES_ACTIVE(queue_id));
 	}
-	rxq->cur_rx = bdp;
+	rxq->bd.cur = bdp;
 	return pkt_received;
 }
 
@@ -2658,8 +2609,8 @@ static void fec_enet_free_buffers(struct net_device *ndev)
 
 	for (q = 0; q < fep->num_rx_queues; q++) {
 		rxq = fep->rx_queue[q];
-		bdp = rxq->rx_bd_base;
-		for (i = 0; i < rxq->rx_ring_size; i++) {
+		bdp = rxq->bd.base;
+		for (i = 0; i < rxq->bd.ring_size; i++) {
 			skb = rxq->rx_skbuff[i];
 			rxq->rx_skbuff[i] = NULL;
 			if (skb) {
@@ -2669,14 +2620,14 @@ static void fec_enet_free_buffers(struct net_device *ndev)
 						 DMA_FROM_DEVICE);
 				dev_kfree_skb(skb);
 			}
-			bdp = fec_enet_get_nextdesc(bdp, fep, q);
+			bdp = fec_enet_get_nextdesc(bdp, &rxq->bd);
 		}
 	}
 
 	for (q = 0; q < fep->num_tx_queues; q++) {
 		txq = fep->tx_queue[q];
-		bdp = txq->tx_bd_base;
-		for (i = 0; i < txq->tx_ring_size; i++) {
+		bdp = txq->bd.base;
+		for (i = 0; i < txq->bd.ring_size; i++) {
 			kfree(txq->tx_bounce[i]);
 			txq->tx_bounce[i] = NULL;
 			skb = txq->tx_skbuff[i];
@@ -2696,7 +2647,7 @@ static void fec_enet_free_queue(struct net_device *ndev)
 		if (fep->tx_queue[i] && fep->tx_queue[i]->tso_hdrs) {
 			txq = fep->tx_queue[i];
 			dma_free_coherent(NULL,
-					  txq->tx_ring_size * TSO_HEADER_SIZE,
+					  txq->bd.ring_size * TSO_HEADER_SIZE,
 					  txq->tso_hdrs,
 					  txq->tso_hdrs_dma);
 		}
@@ -2722,15 +2673,15 @@ static int fec_enet_alloc_queue(struct net_device *ndev)
 		}
 
 		fep->tx_queue[i] = txq;
-		txq->tx_ring_size = TX_RING_SIZE;
-		fep->total_tx_ring_size += fep->tx_queue[i]->tx_ring_size;
+		txq->bd.ring_size = TX_RING_SIZE;
+		fep->total_tx_ring_size += fep->tx_queue[i]->bd.ring_size;
 
 		txq->tx_stop_threshold = FEC_MAX_SKB_DESCS;
 		txq->tx_wake_threshold =
-				(txq->tx_ring_size - txq->tx_stop_threshold) / 2;
+			(txq->bd.ring_size - txq->tx_stop_threshold) / 2;
 
 		txq->tso_hdrs = dma_alloc_coherent(NULL,
-					txq->tx_ring_size * TSO_HEADER_SIZE,
+					txq->bd.ring_size * TSO_HEADER_SIZE,
 					&txq->tso_hdrs_dma,
 					GFP_KERNEL);
 		if (!txq->tso_hdrs) {
@@ -2747,8 +2698,8 @@ static int fec_enet_alloc_queue(struct net_device *ndev)
 			goto alloc_failed;
 		}
 
-		fep->rx_queue[i]->rx_ring_size = RX_RING_SIZE;
-		fep->total_rx_ring_size += fep->rx_queue[i]->rx_ring_size;
+		fep->rx_queue[i]->bd.ring_size = RX_RING_SIZE;
+		fep->total_rx_ring_size += fep->rx_queue[i]->bd.ring_size;
 	}
 	return ret;
 
@@ -2767,8 +2718,8 @@ fec_enet_alloc_rxq_buffers(struct net_device *ndev, unsigned int queue)
 	struct fec_enet_priv_rx_q *rxq;
 
 	rxq = fep->rx_queue[queue];
-	bdp = rxq->rx_bd_base;
-	for (i = 0; i < rxq->rx_ring_size; i++) {
+	bdp = rxq->bd.base;
+	for (i = 0; i < rxq->bd.ring_size; i++) {
 		skb = netdev_alloc_skb(ndev, FEC_ENET_RX_FRSIZE);
 		if (!skb)
 			goto err_alloc;
@@ -2786,11 +2737,11 @@ fec_enet_alloc_rxq_buffers(struct net_device *ndev, unsigned int queue)
 			ebdp->cbd_esc = cpu_to_fec32(BD_ENET_RX_INT);
 		}
 
-		bdp = fec_enet_get_nextdesc(bdp, fep, queue);
+		bdp = fec_enet_get_nextdesc(bdp, &rxq->bd);
 	}
 
 	/* Set the last buffer to wrap. */
-	bdp = fec_enet_get_prevdesc(bdp, fep, queue);
+	bdp = fec_enet_get_prevdesc(bdp, &rxq->bd);
 	bdp->cbd_sc |= cpu_to_fec16(BD_SC_WRAP);
 	return 0;
 
@@ -2808,8 +2759,8 @@ fec_enet_alloc_txq_buffers(struct net_device *ndev, unsigned int queue)
 	struct fec_enet_priv_tx_q *txq;
 
 	txq = fep->tx_queue[queue];
-	bdp = txq->tx_bd_base;
-	for (i = 0; i < txq->tx_ring_size; i++) {
+	bdp = txq->bd.base;
+	for (i = 0; i < txq->bd.ring_size; i++) {
 		txq->tx_bounce[i] = kmalloc(FEC_ENET_TX_FRSIZE, GFP_KERNEL);
 		if (!txq->tx_bounce[i])
 			goto err_alloc;
@@ -2822,11 +2773,11 @@ fec_enet_alloc_txq_buffers(struct net_device *ndev, unsigned int queue)
 			ebdp->cbd_esc = cpu_to_fec32(BD_ENET_TX_INT);
 		}
 
-		bdp = fec_enet_get_nextdesc(bdp, fep, queue);
+		bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
 	}
 
 	/* Set the last buffer to wrap. */
-	bdp = fec_enet_get_prevdesc(bdp, fep, queue);
+	bdp = fec_enet_get_prevdesc(bdp, &txq->bd);
 	bdp->cbd_sc |= cpu_to_fec16(BD_SC_WRAP);
 
 	return 0;
@@ -3117,13 +3068,15 @@ static const struct net_device_ops fec_netdev_ops = {
 static int fec_enet_init(struct net_device *ndev)
 {
 	struct fec_enet_private *fep = netdev_priv(ndev);
-	struct fec_enet_priv_tx_q *txq;
-	struct fec_enet_priv_rx_q *rxq;
 	struct bufdesc *cbd_base;
 	dma_addr_t bd_dma;
 	int bd_size;
 	unsigned int i;
+	unsigned dsize = fep->bufdesc_ex ? sizeof(struct bufdesc_ex) :
+			sizeof(struct bufdesc);
+	unsigned dsize_log2 = __fls(dsize);
 
+	WARN_ON(dsize != (1 << dsize_log2));
 #if defined(CONFIG_ARM)
 	fep->rx_align = 0xf;
 	fep->tx_align = 0xf;
@@ -3134,12 +3087,7 @@ static int fec_enet_init(struct net_device *ndev)
 
 	fec_enet_alloc_queue(ndev);
 
-	if (fep->bufdesc_ex)
-		fep->bufdesc_size = sizeof(struct bufdesc_ex);
-	else
-		fep->bufdesc_size = sizeof(struct bufdesc);
-	bd_size = (fep->total_tx_ring_size + fep->total_rx_ring_size) *
-			fep->bufdesc_size;
+	bd_size = (fep->total_tx_ring_size + fep->total_rx_ring_size) * dsize;
 
 	/* Allocate memory for buffer descriptors. */
 	cbd_base = dmam_alloc_coherent(&fep->pdev->dev, bd_size, &bd_dma,
@@ -3157,33 +3105,33 @@ static int fec_enet_init(struct net_device *ndev)
 
 	/* Set receive and transmit descriptor base. */
 	for (i = 0; i < fep->num_rx_queues; i++) {
-		rxq = fep->rx_queue[i];
-		rxq->index = i;
-		rxq->rx_bd_base = (struct bufdesc *)cbd_base;
-		rxq->bd_dma = bd_dma;
-		if (fep->bufdesc_ex) {
-			bd_dma += sizeof(struct bufdesc_ex) * rxq->rx_ring_size;
-			cbd_base = (struct bufdesc *)
-				(((struct bufdesc_ex *)cbd_base) + rxq->rx_ring_size);
-		} else {
-			bd_dma += sizeof(struct bufdesc) * rxq->rx_ring_size;
-			cbd_base += rxq->rx_ring_size;
-		}
+		struct fec_enet_priv_rx_q *rxq = fep->rx_queue[i];
+		unsigned size = dsize * rxq->bd.ring_size;
+
+		rxq->bd.qid = i;
+		rxq->bd.base = cbd_base;
+		rxq->bd.cur = cbd_base;
+		rxq->bd.dma = bd_dma;
+		rxq->bd.dsize = dsize;
+		rxq->bd.dsize_log2 = dsize_log2;
+		bd_dma += size;
+		cbd_base = (struct bufdesc *)(((void *)cbd_base) + size);
+		rxq->bd.last = (struct bufdesc *)(((void *)cbd_base) - dsize);
 	}
 
 	for (i = 0; i < fep->num_tx_queues; i++) {
-		txq = fep->tx_queue[i];
-		txq->index = i;
-		txq->tx_bd_base = (struct bufdesc *)cbd_base;
-		txq->bd_dma = bd_dma;
-		if (fep->bufdesc_ex) {
-			bd_dma += sizeof(struct bufdesc_ex) * txq->tx_ring_size;
-			cbd_base = (struct bufdesc *)
-			 (((struct bufdesc_ex *)cbd_base) + txq->tx_ring_size);
-		} else {
-			bd_dma += sizeof(struct bufdesc) * txq->tx_ring_size;
-			cbd_base += txq->tx_ring_size;
-		}
+		struct fec_enet_priv_tx_q *txq = fep->tx_queue[i];
+		unsigned size = dsize * txq->bd.ring_size;
+
+		txq->bd.qid = i;
+		txq->bd.base = cbd_base;
+		txq->bd.cur = cbd_base;
+		txq->bd.dma = bd_dma;
+		txq->bd.dsize = dsize;
+		txq->bd.dsize_log2 = dsize_log2;
+		bd_dma += size;
+		cbd_base = (struct bufdesc *)(((void *)cbd_base) + size);
+		txq->bd.last = (struct bufdesc *)(((void *)cbd_base) - dsize);
 	}
 
 
-- 
2.5.0



From troy.kisky at boundarydevices.com  Fri Feb  5 13:52:48 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Fri,  5 Feb 2016 14:52:48 -0700
Subject: [PATCH net-next V2 6/8] net: fec: don't disable FEC_ENET_TS_TIMER
 interrupt
In-Reply-To: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1454709170-19527-7-git-send-email-troy.kisky@boundarydevices.com>

Only the interrupt routine processes this condition.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec.h      | 1 +
 drivers/net/ethernet/freescale/fec_main.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index bedd28a..195122e 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -375,6 +375,7 @@ struct bufdesc_ex {
 #define FEC_ENET_TS_TIMER       ((uint)0x00008000)
 
 #define FEC_DEFAULT_IMASK (FEC_ENET_TXF | FEC_ENET_RXF | FEC_ENET_MII | FEC_ENET_TS_TIMER)
+#define FEC_NAPI_IMASK	(FEC_ENET_MII | FEC_ENET_TS_TIMER)
 #define FEC_RX_DISABLED_IMASK (FEC_DEFAULT_IMASK & (~FEC_ENET_RXF))
 
 /* ENET interrupt coalescing macro define */
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 712e3bb..ca2708d 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1553,7 +1553,7 @@ fec_enet_interrupt(int irq, void *dev_id)
 
 		if (napi_schedule_prep(&fep->napi)) {
 			/* Disable the NAPI interrupts */
-			writel(FEC_ENET_MII, fep->hwp + FEC_IMASK);
+			writel(FEC_NAPI_IMASK, fep->hwp + FEC_IMASK);
 			__napi_schedule(&fep->napi);
 		}
 	}
-- 
2.5.0



From troy.kisky at boundarydevices.com  Fri Feb  5 13:52:47 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Fri,  5 Feb 2016 14:52:47 -0700
Subject: [PATCH net-next V2 5/8] net: fec: add variable reg_desc_active to
 speed things up
In-Reply-To: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1454709170-19527-6-git-send-email-troy.kisky@boundarydevices.com>

There is no need for complex macros every time we need to activate
a queue. Also, no need to call skb_get_queue_mapping when we already
know which queue it is using.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec.h      |  7 +----
 drivers/net/ethernet/freescale/fec_main.c | 44 +++++++++++++++++--------------
 2 files changed, 25 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 53ec04f..bedd28a 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -310,12 +310,6 @@ struct bufdesc_ex {
 #define FEC_R_BUFF_SIZE(X)	(((X) == 1) ? FEC_R_BUFF_SIZE_1 : \
 				(((X) == 2) ? \
 					FEC_R_BUFF_SIZE_2 : FEC_R_BUFF_SIZE_0))
-#define FEC_R_DES_ACTIVE(X)	(((X) == 1) ? FEC_R_DES_ACTIVE_1 : \
-				(((X) == 2) ? \
-				   FEC_R_DES_ACTIVE_2 : FEC_R_DES_ACTIVE_0))
-#define FEC_X_DES_ACTIVE(X)	(((X) == 1) ? FEC_X_DES_ACTIVE_1 : \
-				(((X) == 2) ? \
-				   FEC_X_DES_ACTIVE_2 : FEC_X_DES_ACTIVE_0))
 
 #define FEC_DMA_CFG(X)		(((X) == 2) ? FEC_DMA_CFG_2 : FEC_DMA_CFG_1)
 
@@ -454,6 +448,7 @@ struct bufdesc_prop {
 	struct bufdesc	*base;
 	struct bufdesc	*last;
 	struct bufdesc	*cur;
+	void __iomem	*reg_desc_active;
 	dma_addr_t	dma;
 	unsigned short ring_size;
 	unsigned char dsize;
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index b039288..712e3bb 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -328,7 +328,6 @@ fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
 	struct bufdesc *bdp = txq->bd.cur;
 	struct bufdesc_ex *ebdp;
 	int nr_frags = skb_shinfo(skb)->nr_frags;
-	unsigned short queue = skb_get_queue_mapping(skb);
 	int frag, frag_len;
 	unsigned short status;
 	unsigned int estatus = 0;
@@ -361,7 +360,7 @@ fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
 
 		if (fep->bufdesc_ex) {
 			if (fep->quirks & FEC_QUIRK_HAS_AVB)
-				estatus |= FEC_TX_BD_FTYPE(queue);
+				estatus |= FEC_TX_BD_FTYPE(txq->bd.qid);
 			if (skb->ip_summed == CHECKSUM_PARTIAL)
 				estatus |= BD_ENET_TX_PINS | BD_ENET_TX_IINS;
 			ebdp->cbd_bdu = 0;
@@ -415,7 +414,6 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 	dma_addr_t addr;
 	unsigned short status;
 	unsigned short buflen;
-	unsigned short queue;
 	unsigned int estatus = 0;
 	unsigned int index;
 	int entries_free;
@@ -444,7 +442,6 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 	bufaddr = skb->data;
 	buflen = skb_headlen(skb);
 
-	queue = skb_get_queue_mapping(skb);
 	index = fec_enet_get_bd_index(bdp, &txq->bd);
 	if (((unsigned long) bufaddr) & fep->tx_align ||
 		fep->quirks & FEC_QUIRK_SWAP_FRAME) {
@@ -487,7 +484,7 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 			skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
 
 		if (fep->quirks & FEC_QUIRK_HAS_AVB)
-			estatus |= FEC_TX_BD_FTYPE(queue);
+			estatus |= FEC_TX_BD_FTYPE(txq->bd.qid);
 
 		if (skb->ip_summed == CHECKSUM_PARTIAL)
 			estatus |= BD_ENET_TX_PINS | BD_ENET_TX_IINS;
@@ -521,7 +518,7 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 	txq->bd.cur = bdp;
 
 	/* Trigger transmission start */
-	writel(0, fep->hwp + FEC_X_DES_ACTIVE(queue));
+	writel(0, txq->bd.reg_desc_active);
 
 	return 0;
 }
@@ -534,7 +531,6 @@ fec_enet_txq_put_data_tso(struct fec_enet_priv_tx_q *txq, struct sk_buff *skb,
 {
 	struct fec_enet_private *fep = netdev_priv(ndev);
 	struct bufdesc_ex *ebdp = container_of(bdp, struct bufdesc_ex, desc);
-	unsigned short queue = skb_get_queue_mapping(skb);
 	unsigned short status;
 	unsigned int estatus = 0;
 	dma_addr_t addr;
@@ -566,7 +562,7 @@ fec_enet_txq_put_data_tso(struct fec_enet_priv_tx_q *txq, struct sk_buff *skb,
 
 	if (fep->bufdesc_ex) {
 		if (fep->quirks & FEC_QUIRK_HAS_AVB)
-			estatus |= FEC_TX_BD_FTYPE(queue);
+			estatus |= FEC_TX_BD_FTYPE(txq->bd.qid);
 		if (skb->ip_summed == CHECKSUM_PARTIAL)
 			estatus |= BD_ENET_TX_PINS | BD_ENET_TX_IINS;
 		ebdp->cbd_bdu = 0;
@@ -595,7 +591,6 @@ fec_enet_txq_put_hdr_tso(struct fec_enet_priv_tx_q *txq,
 	struct fec_enet_private *fep = netdev_priv(ndev);
 	int hdr_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
 	struct bufdesc_ex *ebdp = container_of(bdp, struct bufdesc_ex, desc);
-	unsigned short queue = skb_get_queue_mapping(skb);
 	void *bufaddr;
 	unsigned long dmabuf;
 	unsigned short status;
@@ -630,7 +625,7 @@ fec_enet_txq_put_hdr_tso(struct fec_enet_priv_tx_q *txq,
 
 	if (fep->bufdesc_ex) {
 		if (fep->quirks & FEC_QUIRK_HAS_AVB)
-			estatus |= FEC_TX_BD_FTYPE(queue);
+			estatus |= FEC_TX_BD_FTYPE(txq->bd.qid);
 		if (skb->ip_summed == CHECKSUM_PARTIAL)
 			estatus |= BD_ENET_TX_PINS | BD_ENET_TX_IINS;
 		ebdp->cbd_bdu = 0;
@@ -650,7 +645,6 @@ static int fec_enet_txq_submit_tso(struct fec_enet_priv_tx_q *txq,
 	int hdr_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
 	int total_len, data_left;
 	struct bufdesc *bdp = txq->bd.cur;
-	unsigned short queue = skb_get_queue_mapping(skb);
 	struct tso_t tso;
 	unsigned int index = 0;
 	int ret;
@@ -715,11 +709,11 @@ static int fec_enet_txq_submit_tso(struct fec_enet_priv_tx_q *txq,
 
 	/* Trigger transmission start */
 	if (!(fep->quirks & FEC_QUIRK_ERR007885) ||
-	    !readl(fep->hwp + FEC_X_DES_ACTIVE(queue)) ||
-	    !readl(fep->hwp + FEC_X_DES_ACTIVE(queue)) ||
-	    !readl(fep->hwp + FEC_X_DES_ACTIVE(queue)) ||
-	    !readl(fep->hwp + FEC_X_DES_ACTIVE(queue)))
-		writel(0, fep->hwp + FEC_X_DES_ACTIVE(queue));
+	    !readl(txq->bd.reg_desc_active) ||
+	    !readl(txq->bd.reg_desc_active) ||
+	    !readl(txq->bd.reg_desc_active) ||
+	    !readl(txq->bd.reg_desc_active))
+		writel(0, txq->bd.reg_desc_active);
 
 	return 0;
 
@@ -819,7 +813,7 @@ static void fec_enet_active_rxring(struct net_device *ndev)
 	int i;
 
 	for (i = 0; i < fep->num_rx_queues; i++)
-		writel(0, fep->hwp + FEC_R_DES_ACTIVE(i));
+		writel(0, fep->rx_queue[i]->bd.reg_desc_active);
 }
 
 static void fec_enet_enable_ring(struct net_device *ndev)
@@ -1255,8 +1249,8 @@ fec_enet_tx_queue(struct net_device *ndev, u16 queue_id)
 
 	/* ERR006538: Keep the transmitter going */
 	if (bdp != txq->bd.cur &&
-	    readl(fep->hwp + FEC_X_DES_ACTIVE(queue_id)) == 0)
-		writel(0, fep->hwp + FEC_X_DES_ACTIVE(queue_id));
+	    readl(txq->bd.reg_desc_active) == 0)
+		writel(0, txq->bd.reg_desc_active);
 }
 
 static void
@@ -1498,7 +1492,7 @@ rx_processing_done:
 		 * incoming frames.  On a heavily loaded network, we should be
 		 * able to keep up at the expense of system resources.
 		 */
-		writel(0, fep->hwp + FEC_R_DES_ACTIVE(queue_id));
+		writel(0, rxq->bd.reg_desc_active);
 	}
 	rxq->bd.cur = bdp;
 	return pkt_received;
@@ -3061,6 +3055,14 @@ static const struct net_device_ops fec_netdev_ops = {
 	.ndo_set_features	= fec_set_features,
 };
 
+static const unsigned short offset_des_active_rxq[] = {
+	FEC_R_DES_ACTIVE_0, FEC_R_DES_ACTIVE_1, FEC_R_DES_ACTIVE_2
+};
+
+static const unsigned short offset_des_active_txq[] = {
+	FEC_X_DES_ACTIVE_0, FEC_X_DES_ACTIVE_1, FEC_X_DES_ACTIVE_2
+};
+
  /*
   * XXX:  We need to clean up on failure exits here.
   *
@@ -3114,6 +3116,7 @@ static int fec_enet_init(struct net_device *ndev)
 		rxq->bd.dma = bd_dma;
 		rxq->bd.dsize = dsize;
 		rxq->bd.dsize_log2 = dsize_log2;
+		rxq->bd.reg_desc_active = fep->hwp + offset_des_active_rxq[i];
 		bd_dma += size;
 		cbd_base = (struct bufdesc *)(((void *)cbd_base) + size);
 		rxq->bd.last = (struct bufdesc *)(((void *)cbd_base) - dsize);
@@ -3129,6 +3132,7 @@ static int fec_enet_init(struct net_device *ndev)
 		txq->bd.dma = bd_dma;
 		txq->bd.dsize = dsize;
 		txq->bd.dsize_log2 = dsize_log2;
+		txq->bd.reg_desc_active = fep->hwp + offset_des_active_txq[i];
 		bd_dma += size;
 		cbd_base = (struct bufdesc *)(((void *)cbd_base) + size);
 		txq->bd.last = (struct bufdesc *)(((void *)cbd_base) - dsize);
-- 
2.5.0



From troy.kisky at boundarydevices.com  Fri Feb  5 13:52:49 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Fri,  5 Feb 2016 14:52:49 -0700
Subject: [PATCH net-next V2 7/8] net: fec: don't transfer ownership until
 descriptor write is complete
In-Reply-To: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1454709170-19527-8-git-send-email-troy.kisky@boundarydevices.com>

If you don't own it, you shouldn't write to it.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index ca2708d..97ca72a 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -390,6 +390,10 @@ fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
 
 		bdp->cbd_bufaddr = cpu_to_fec32(addr);
 		bdp->cbd_datlen = cpu_to_fec16(frag_len);
+		/* Make sure the updates to rest of the descriptor are
+		 * performed before transferring ownership.
+		 */
+		wmb();
 		bdp->cbd_sc = cpu_to_fec16(status);
 	}
 
@@ -499,6 +503,10 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 
 	bdp->cbd_datlen = cpu_to_fec16(buflen);
 	bdp->cbd_bufaddr = cpu_to_fec32(addr);
+	/* Make sure the updates to rest of the descriptor are performed before
+	 * transferring ownership.
+	 */
+	wmb();
 
 	/* Send it on its way.  Tell FEC it's ready, interrupt when done,
 	 * it's the last BD of the frame, and to put the CRC on the end.
@@ -1475,7 +1483,6 @@ rx_processing_done:
 
 		/* Mark the buffer empty */
 		status |= BD_ENET_RX_EMPTY;
-		bdp->cbd_sc = cpu_to_fec16(status);
 
 		if (fep->bufdesc_ex) {
 			struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp;
@@ -1484,6 +1491,11 @@ rx_processing_done:
 			ebdp->cbd_prot = 0;
 			ebdp->cbd_bdu = 0;
 		}
+		/* Make sure the updates to rest of the descriptor are
+		 * performed before transferring ownership.
+		 */
+		wmb();
+		bdp->cbd_sc = cpu_to_fec16(status);
 
 		/* Update BD pointer to next entry */
 		bdp = fec_enet_get_nextdesc(bdp, &rxq->bd);
-- 
2.5.0



From troy.kisky at boundarydevices.com  Fri Feb  5 13:52:50 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Fri,  5 Feb 2016 14:52:50 -0700
Subject: [PATCH net-next V2 8/8] net: fec: improve error handling
In-Reply-To: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1454709170-19527-9-git-send-email-troy.kisky@boundarydevices.com>

Unmap initial buffer on error.
Don't free skb until it has been unmapped.
Move cbd_bufaddr assignment closer to the mapping function.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 97ca72a..ef18ca5 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -382,7 +382,6 @@ fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
 		addr = dma_map_single(&fep->pdev->dev, bufaddr, frag_len,
 				      DMA_TO_DEVICE);
 		if (dma_mapping_error(&fep->pdev->dev, addr)) {
-			dev_kfree_skb_any(skb);
 			if (net_ratelimit())
 				netdev_err(ndev, "Tx DMA memory map failed\n");
 			goto dma_mapping_error;
@@ -467,8 +466,12 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 
 	if (nr_frags) {
 		last_bdp = fec_enet_txq_submit_frag_skb(txq, skb, ndev);
-		if (IS_ERR(last_bdp))
+		if (IS_ERR(last_bdp)) {
+			dma_unmap_single(&fep->pdev->dev, addr,
+					 buflen, DMA_TO_DEVICE);
+			dev_kfree_skb_any(skb);
 			return NETDEV_TX_OK;
+		}
 	} else {
 		status |= (BD_ENET_TX_INTR | BD_ENET_TX_LAST);
 		if (fep->bufdesc_ex) {
@@ -478,6 +481,8 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 				estatus |= BD_ENET_TX_TS;
 		}
 	}
+	bdp->cbd_bufaddr = cpu_to_fec32(addr);
+	bdp->cbd_datlen = cpu_to_fec16(buflen);
 
 	if (fep->bufdesc_ex) {
 
@@ -501,8 +506,6 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 	/* Save skb pointer */
 	txq->tx_skbuff[index] = skb;
 
-	bdp->cbd_datlen = cpu_to_fec16(buflen);
-	bdp->cbd_bufaddr = cpu_to_fec32(addr);
 	/* Make sure the updates to rest of the descriptor are performed before
 	 * transferring ownership.
 	 */
-- 
2.5.0



From arnd at arndb.de  Fri Feb  5 14:24:35 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 05 Feb 2016 23:24:35 +0100
Subject: [PATCH RFC] Add cpufreq support
In-Reply-To: <56B4D4BE.2040008@free.fr>
References: <56B4D4BE.2040008@free.fr>
Message-ID: <3308645.nrPBoahQ2V@wuerfel>

On Friday 05 February 2016 17:58:38 Mason wrote:
> I'm throwing this out there to ask:
> Is this the right way to enable cpufreq on my platform?
> ---

> @@ -23,6 +24,11 @@ static void tango_l2c_write(unsigned long val, unsigned int reg)
>  		tango_set_l2_control(val);
>  }
>  
> +static void __init tango_init_late(void)
> +{
> +	platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
> +}
> +
>  static const char *const tango_dt_compat[] = { "sigma,tango4", NULL };
>  
>  DT_MACHINE_START(TANGO_DT, "Sigma Tango DT")
> @@ -30,4 +36,5 @@ DT_MACHINE_START(TANGO_DT, "Sigma Tango DT")
>  	.l2c_aux_mask	= ~0,
>  	.l2c_write_sec	= tango_l2c_write,
>  	.map_io		= tango_map_io,
> +	.init_late	= tango_init_late,
>  MACHINE_END
> 

We no longer call platform_device_register_simple() from platform code, at least
for new platforms, and we should probably remove the code from the existing
platforms that still do it. I forget what the replacement was, but I'm not
going to take this version. Viresh should be able to help you do it the right
way.

	Arnd


From helgaas at kernel.org  Fri Feb  5 14:25:25 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Fri, 5 Feb 2016 16:25:25 -0600
Subject: [PATCH] PCI: layerscape: add ls2085a compatible
In-Reply-To: <56B509E5.2050602@linaro.org>
References: <1453915925-19198-1-git-send-email-yang.shi@linaro.org>
 <20160205203858.GA11780@localhost> <56B509E5.2050602@linaro.org>
Message-ID: <20160205222525.GA16238@localhost>

On Fri, Feb 05, 2016 at 12:45:25PM -0800, Shi, Yang wrote:
> On 2/5/2016 12:38 PM, Bjorn Helgaas wrote:
> >[+cc Rob, et al]
> >
> >On Wed, Jan 27, 2016 at 09:32:05AM -0800, Yang Shi wrote:
> >>The layerscape PCI host driver needs recognize ls2085a compatible when using
> >>firmware with ls2085a compatible property, otherwise the PCI bus won't be
> >>detected even though ls2085a compatible is included by the dts.
> >>
> >>Signed-off-by: Yang Shi <yang.shi at linaro.org>
> >>---
> >>  drivers/pci/host/pci-layerscape.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >>diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
> >>index 3923bed..c40d8b2 100644
> >>--- a/drivers/pci/host/pci-layerscape.c
> >>+++ b/drivers/pci/host/pci-layerscape.c
> >>@@ -203,6 +203,7 @@ static const struct of_device_id ls_pcie_of_match[] = {
> >>  	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
> >>  	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
> >>  	{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
> >>+	{ .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },
> >
> >Hmm, "fsl,ls2085a-pcie" doesn't appear in
> >Documentation/devicetree/bindings/pci/.
> >
> >Aren't we supposed to add these strings to the bindings before or at
> >the same time we add them to drivers?
> 
> The below patch will add it into dts and binding doc. I should
> mentioned this in the commit log.
> 
> https://patchwork.kernel.org/patch/7767061/

OK.  This is really annoying as a reviewer.  To me, adding
"fsl,ls2085a-pcie" to:

  - the binding in Documentation/devicetree/bindings/pci/layerscape-pci.txt
  - the DT in arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
  - the driver in drivers/pci/host/pci-layerscape.c

are all logically related, and it would make sense to have them all in
a single patch.

But whatever.  I applied this to pci/host-layerscape for v4.6.

> >checkpatch doesn't complain though, so maybe I'm wrong about this.
> >
> >>  	{ },
> >>  };
> >>  MODULE_DEVICE_TABLE(of, ls_pcie_of_match);
> >>--
> >>2.0.2
> >>
> >>--
> >>To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >>the body of a message to majordomo at vger.kernel.org
> >>More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From helgaas at kernel.org  Fri Feb  5 14:36:58 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Fri, 5 Feb 2016 16:36:58 -0600
Subject: [PATCH 0/5] Clean up warnings (part 2, asm/pci-bridge.h)
In-Reply-To: <20160202193026.9258.7573.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20160202193026.9258.7573.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <20160205223658.GC16238@localhost>

On Tue, Feb 02, 2016 at 01:38:26PM -0600, Bjorn Helgaas wrote:
> We've had some non-arch-specific stuff (pci_has_flag() and associated
> definitions like PCI_PROBE_ONLY) in asm/pci-bridge.h.  This leads to
> warnings like:
> 
>   drivers/pci/host/pcie-designware.c:562:20: error: 'PCI_PROBE_ONLY' undeclared (first use in this function)
>   drivers/pci/host/pcie-designware.c:562:7: error: implicit declaration of function 'pci_has_flag' [-Werror=implicit-function-declaration]
> 
> because arches don't consistently supply asm/pci-bridge.h, and several
> drivers include it when they shouldn't.
> 
> This series moves the generic stuff to linux/pci.h, so it's the same for
> everybody, and removes the now-empty asm-generic/pci-bridge.h.
> 
> There still a few arches that provide asm/pci-bridge.h (microblaze,
> powerpc, and xtensa), but now they contain truly arch-dependent things like
> struct pci_controller definitions, and they're only included by
> arch-specific files.
> 
> ---
> 
> Bjorn Helgaas (5):
>       PCI: Move pci_set_flags() from asm-generic/pci-bridge.h to linux/pci.h
>       PCI: Remove includes of empty asm-generic/pci-bridge.h
>       ARM64: PCI: Remove generated include of asm-generic/pci-bridge.h
>       PCI: Remove empty asm-generic/pci-bridge.h
>       PCI: Remove includes of asm/pci-bridge.h

I applied these, with Will's ack on the arm64 parts, to pci/misc
for v4.6.

>  arch/alpha/include/asm/pci.h               |    1 
>  arch/arm/include/asm/pci.h                 |    3 -
>  arch/arm64/include/asm/Kbuild              |    3 -
>  arch/arm64/include/asm/pci.h               |    1 
>  arch/arm64/kernel/pci.c                    |    2 -
>  arch/mips/include/asm/pci.h                |    1 
>  arch/powerpc/include/asm/pci-bridge.h      |    1 
>  arch/unicore32/include/asm/pci.h           |    2 -
>  arch/x86/pci/common.c                      |    1 
>  drivers/ata/pata_macio.c                   |    2 -
>  drivers/char/agp/uninorth-agp.c            |    1 
>  drivers/gpu/drm/radeon/radeon_combios.c    |    1 
>  drivers/ide/pdc202xx_new.c                 |    1 
>  drivers/ide/pmac.c                         |    1 
>  drivers/macintosh/macio_asic.c             |    1 
>  drivers/misc/cxl/pci.c                     |    1 
>  drivers/net/ethernet/sun/sungem.c          |    1 
>  drivers/net/ethernet/toshiba/spider_net.c  |    1 
>  drivers/of/of_pci.c                        |    1 
>  drivers/pci/pci.c                          |    1 
>  drivers/pci/probe.c                        |    8 +++
>  drivers/pci/setup-bus.c                    |    1 
>  drivers/scsi/mac53c94.c                    |    2 -
>  drivers/scsi/mesh.c                        |    2 -
>  drivers/usb/core/hcd-pci.c                 |    1 
>  drivers/video/fbdev/aty/aty128fb.c         |    1 
>  drivers/video/fbdev/aty/radeon_base.c      |    1 
>  drivers/video/fbdev/imsttfb.c              |    1 
>  drivers/video/fbdev/matrox/matroxfb_base.h |    1 
>  drivers/video/fbdev/offb.c                 |    4 --
>  include/asm-generic/pci-bridge.h           |   74 ----------------------------
>  include/linux/pci.h                        |   22 ++++++++
>  sound/ppc/pmac.c                           |    1 
>  33 files changed, 32 insertions(+), 114 deletions(-)
>  delete mode 100644 include/asm-generic/pci-bridge.h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From jonmason at broadcom.com  Fri Feb  5 14:43:19 2016
From: jonmason at broadcom.com (Jon Mason)
Date: Fri,  5 Feb 2016 17:43:19 -0500
Subject: [PATCH 0/5] ARM: dts: NSP: DT Updates 
Message-ID: <1454712204-30419-1-git-send-email-jonmason@broadcom.com>

Northstar Plus device tree changes.  The first 2 are bug fixes that
probably should go in ASAP.  The other 3 enable new hardware and can be
pushed into the next merge window.

Thanks,
Jon

Jon Mason (5):
  ARM: dts: NSP: Fix PCIE DT issue
  ARM: dts: NSP: Fix CPU DT issue
  ARM: dts: NSP: Add PMU Support to DT
  ARM: dts: NSP: Add SP805 Support to DT
  ARM: dts: NSP: Add SP804 Support to DT

 arch/arm/boot/dts/bcm-nsp.dtsi | 193 +++++++++++++++++++++++------------------
 1 file changed, 107 insertions(+), 86 deletions(-)

-- 
1.9.1



From jonmason at broadcom.com  Fri Feb  5 14:43:21 2016
From: jonmason at broadcom.com (Jon Mason)
Date: Fri,  5 Feb 2016 17:43:21 -0500
Subject: [PATCH 2/5] ARM: dts: NSP: Fix CPU DT issue
In-Reply-To: <1454712204-30419-1-git-send-email-jonmason@broadcom.com>
References: <1454712204-30419-1-git-send-email-jonmason@broadcom.com>
Message-ID: <1454712204-30419-3-git-send-email-jonmason@broadcom.com>

There is a double definition of the CPUs present in the device tree.
Remove unnecessary cpu device tree definition.

Signed-off-by: Jon Mason <jonmason at broadcom.com>
---
 arch/arm/boot/dts/bcm-nsp.dtsi | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index c5b0c09c..c37778e 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -68,18 +68,6 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 
-		cpus {
-			#address-cells = <1>;
-			#size-cells = <0>;
-
-			cpu at 0 {
-				device_type = "cpu";
-				compatible = "arm,cortex-a9";
-				next-level-cache = <&L2>;
-				reg = <0x0>;
-			};
-		};
-
 		a9pll: arm_clk at 00000 {
 			#clock-cells = <0>;
 			compatible = "brcm,nsp-armpll";
-- 
1.9.1



From jonmason at broadcom.com  Fri Feb  5 14:43:23 2016
From: jonmason at broadcom.com (Jon Mason)
Date: Fri,  5 Feb 2016 17:43:23 -0500
Subject: [PATCH 4/5] ARM: dts: NSP: Add SP805 Support to DT
In-Reply-To: <1454712204-30419-1-git-send-email-jonmason@broadcom.com>
References: <1454712204-30419-1-git-send-email-jonmason@broadcom.com>
Message-ID: <1454712204-30419-5-git-send-email-jonmason@broadcom.com>

Add support for the ARM SP805 Watchdog timer to the Northstar Plus
device tree.

Signed-off-by: Jon Mason <jonmason at broadcom.com>
---
 arch/arm/boot/dts/bcm-nsp.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 415a0a6..0e8cb6e 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -203,6 +203,14 @@
 			clock-frequency = <100000>;
 		};
 
+		wdt at 39000 {
+			compatible = "arm,sp805", "arm,primecell";
+			reg = <0x39000 0x1000>;
+			interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&iprocslow>, <&iprocslow>;
+			clock-names = "wdogclk", "apb_pclk";
+		};
+
 		lcpll0: lcpll0 at 3f100 {
 			#clock-cells = <1>;
 			compatible = "brcm,nsp-lcpll0";
-- 
1.9.1



From jonmason at broadcom.com  Fri Feb  5 14:43:22 2016
From: jonmason at broadcom.com (Jon Mason)
Date: Fri,  5 Feb 2016 17:43:22 -0500
Subject: [PATCH 3/5] ARM: dts: NSP: Add PMU Support to DT
In-Reply-To: <1454712204-30419-1-git-send-email-jonmason@broadcom.com>
References: <1454712204-30419-1-git-send-email-jonmason@broadcom.com>
Message-ID: <1454712204-30419-4-git-send-email-jonmason@broadcom.com>

Add support for the ARM Performance Monitor Unit to the Northstar Plus
device tree.

Signed-off-by: Jon Mason <jonmason at broadcom.com>
---
 arch/arm/boot/dts/bcm-nsp.dtsi | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index c37778e..415a0a6 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -45,14 +45,14 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		cpu at 0 {
+		cpu0: cpu at 0 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a9";
 			next-level-cache = <&L2>;
 			reg = <0x0>;
 		};
 
-		cpu at 1 {
+		cpu1: cpu at 1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a9";
 			next-level-cache = <&L2>;
@@ -62,6 +62,13 @@
 		};
 	};
 
+	pmu {
+		compatible = "arm,cortex-a9-pmu";
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu0>, <&cpu1>;
+	};
+
 	mpcore {
 		compatible = "simple-bus";
 		ranges = <0x00000000 0x19000000 0x00023000>;
-- 
1.9.1



From jonmason at broadcom.com  Fri Feb  5 14:43:20 2016
From: jonmason at broadcom.com (Jon Mason)
Date: Fri,  5 Feb 2016 17:43:20 -0500
Subject: [PATCH 1/5] ARM: dts: NSP: Fix PCIE DT issue
In-Reply-To: <1454712204-30419-1-git-send-email-jonmason@broadcom.com>
References: <1454712204-30419-1-git-send-email-jonmason@broadcom.com>
Message-ID: <1454712204-30419-2-git-send-email-jonmason@broadcom.com>

Adding the ranges value is preventing the PCI nodes from working.
Pulling them out outside makes them work again (and makes it similar to
the NS2 device tree).

Signed-off-by: Jon Mason <jonmason at broadcom.com>
---
 arch/arm/boot/dts/bcm-nsp.dtsi | 144 ++++++++++++++++++++---------------------
 1 file changed, 72 insertions(+), 72 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 10bdef5..c5b0c09c 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -185,78 +185,6 @@
 			status = "disabled";
 		};
 
-		pcie0: pcie at 12000 {
-			compatible = "brcm,iproc-pcie";
-			reg = <0x12000 0x1000>;
-
-			#interrupt-cells = <1>;
-			interrupt-map-mask = <0 0 0 0>;
-			interrupt-map = <0 0 0 0 &gic GIC_SPI 131 IRQ_TYPE_NONE>;
-
-			linux,pci-domain = <0>;
-
-			bus-range = <0x00 0xff>;
-
-			#address-cells = <3>;
-			#size-cells = <2>;
-			device_type = "pci";
-
-			/* Note: The HW does not support I/O resources.  So,
-			 * only the memory resource range is being specified.
-			 */
-			ranges = <0x82000000 0 0x08000000 0x08000000 0 0x8000000>;
-
-			status = "disabled";
-		};
-
-		pcie1: pcie at 13000 {
-			compatible = "brcm,iproc-pcie";
-			reg = <0x13000 0x1000>;
-
-			#interrupt-cells = <1>;
-			interrupt-map-mask = <0 0 0 0>;
-			interrupt-map = <0 0 0 0 &gic GIC_SPI 137 IRQ_TYPE_NONE>;
-
-			linux,pci-domain = <1>;
-
-			bus-range = <0x00 0xff>;
-
-			#address-cells = <3>;
-			#size-cells = <2>;
-			device_type = "pci";
-
-			/* Note: The HW does not support I/O resources.  So,
-			 * only the memory resource range is being specified.
-			 */
-			ranges = <0x82000000 0 0x40000000 0x40000000 0 0x8000000>;
-
-			status = "disabled";
-		};
-
-		pcie2: pcie at 14000 {
-			compatible = "brcm,iproc-pcie";
-			reg = <0x14000 0x1000>;
-
-			#interrupt-cells = <1>;
-			interrupt-map-mask = <0 0 0 0>;
-			interrupt-map = <0 0 0 0 &gic GIC_SPI 143 IRQ_TYPE_NONE>;
-
-			linux,pci-domain = <2>;
-
-			bus-range = <0x00 0xff>;
-
-			#address-cells = <3>;
-			#size-cells = <2>;
-			device_type = "pci";
-
-			/* Note: The HW does not support I/O resources.  So,
-			 * only the memory resource range is being specified.
-			 */
-			ranges = <0x82000000 0 0x48000000 0x48000000 0 0x8000000>;
-
-			status = "disabled";
-		};
-
 		nand: nand at 26000 {
 			compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
 			reg = <0x026000 0x600>,
@@ -306,4 +234,76 @@
 			      <0x3f408 0x04>;
 		};
 	};
+
+	pcie0: pcie at 18012000 {
+		compatible = "brcm,iproc-pcie";
+		reg = <0x18012000 0x1000>;
+
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &gic GIC_SPI 131 IRQ_TYPE_NONE>;
+
+		linux,pci-domain = <0>;
+
+		bus-range = <0x00 0xff>;
+
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+
+		/* Note: The HW does not support I/O resources.  So,
+		 * only the memory resource range is being specified.
+		 */
+		ranges = <0x82000000 0 0x08000000 0x08000000 0 0x8000000>;
+
+		status = "disabled";
+	};
+
+	pcie1: pcie at 18013000 {
+		compatible = "brcm,iproc-pcie";
+		reg = <0x18013000 0x1000>;
+
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &gic GIC_SPI 137 IRQ_TYPE_NONE>;
+
+		linux,pci-domain = <1>;
+
+		bus-range = <0x00 0xff>;
+
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+
+		/* Note: The HW does not support I/O resources.  So,
+		 * only the memory resource range is being specified.
+		 */
+		ranges = <0x82000000 0 0x40000000 0x40000000 0 0x8000000>;
+
+		status = "disabled";
+	};
+
+	pcie2: pcie at 18014000 {
+		compatible = "brcm,iproc-pcie";
+		reg = <0x18014000 0x1000>;
+
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &gic GIC_SPI 143 IRQ_TYPE_NONE>;
+
+		linux,pci-domain = <2>;
+
+		bus-range = <0x00 0xff>;
+
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+
+		/* Note: The HW does not support I/O resources.  So,
+		 * only the memory resource range is being specified.
+		 */
+		ranges = <0x82000000 0 0x48000000 0x48000000 0 0x8000000>;
+
+		status = "disabled";
+	};
 };
-- 
1.9.1



From jonmason at broadcom.com  Fri Feb  5 14:43:24 2016
From: jonmason at broadcom.com (Jon Mason)
Date: Fri,  5 Feb 2016 17:43:24 -0500
Subject: [PATCH 5/5] ARM: dts: NSP: Add SP804 Support to DT
In-Reply-To: <1454712204-30419-1-git-send-email-jonmason@broadcom.com>
References: <1454712204-30419-1-git-send-email-jonmason@broadcom.com>
Message-ID: <1454712204-30419-6-git-send-email-jonmason@broadcom.com>

Add support for the ARM SP804 timer to the Northstar Plus device tree.

Signed-off-by: Jon Mason <jonmason at broadcom.com>
---
 arch/arm/boot/dts/bcm-nsp.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 0e8cb6e..06a242e 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -194,6 +194,24 @@
 			brcm,nand-has-wp;
 		};
 
+		ccbtimer0: timer at 34000 {
+			compatible = "arm,sp804";
+			reg = <0x34000 0x1000>;
+			interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&iprocslow>;
+			clock-names = "apb_pclk";
+		};
+
+		ccbtimer1: timer at 35000 {
+			compatible = "arm,sp804";
+			reg = <0x35000 0x1000>;
+			interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&iprocslow>;
+			clock-names = "apb_pclk";
+		};
+
 		i2c0: i2c at 38000 {
 			compatible = "brcm,iproc-i2c";
 			reg = <0x38000 0x50>;
-- 
1.9.1



From khilman at baylibre.com  Fri Feb  5 14:47:08 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Fri, 05 Feb 2016 14:47:08 -0800
Subject: [PATCH 1/5] PM / AVS: rockchip-io: make io-domains a child of the
 GRF
In-Reply-To: <1454707218-23676-2-git-send-email-heiko@sntech.de> (Heiko
 Stuebner's message of "Fri, 5 Feb 2016 22:20:14 +0100")
References: <1454707218-23676-1-git-send-email-heiko@sntech.de>
 <1454707218-23676-2-git-send-email-heiko@sntech.de>
Message-ID: <7hio22bwr7.fsf@baylibre.com>

Heiko Stuebner <heiko at sntech.de> writes:

> IO-domain handling is part of the general register files, so should live
> under the grf directly. This change allows the grf to be a simple-mfd and
> the io-domains fetching the syscon regmap from that parent-node.
>
> The old binding is of course preserved, though deprecated.
>
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>

Acked-by: Kevin Hilman <khilman at baylibre.com>

> ---
>  Documentation/devicetree/bindings/power/rockchip-io-domain.txt |  4 +++-
>  drivers/power/avs/rockchip-io-domain.c                         | 10 +++++++++-
>  2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/power/rockchip-io-domain.txt b/Documentation/devicetree/bindings/power/rockchip-io-domain.txt
> index b8627e7..7ed5518 100644
> --- a/Documentation/devicetree/bindings/power/rockchip-io-domain.txt
> +++ b/Documentation/devicetree/bindings/power/rockchip-io-domain.txt
> @@ -35,8 +35,10 @@ Required properties:
>    - "rockchip,rk3288-io-voltage-domain" for rk3288
>    - "rockchip,rk3368-io-voltage-domain" for rk3368
>    - "rockchip,rk3368-pmu-io-voltage-domain" for rk3368 pmu-domains
> -- rockchip,grf: phandle to the syscon managing the "general register files"
>  
> +Deprecated properties:
> +- rockchip,grf: phandle to the syscon managing the "general register files"
> +    Systems should move the io-domains to a sub-node of the grf simple-mfd.
>  
>  You specify supplies using the standard regulator bindings by including
>  a phandle the relevant regulator.  All specified supplies must be able
> diff --git a/drivers/power/avs/rockchip-io-domain.c b/drivers/power/avs/rockchip-io-domain.c
> index 8099456..a5a07d8 100644
> --- a/drivers/power/avs/rockchip-io-domain.c
> +++ b/drivers/power/avs/rockchip-io-domain.c
> @@ -278,6 +278,7 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
>  	struct device_node *np = pdev->dev.of_node;
>  	const struct of_device_id *match;
>  	struct rockchip_iodomain *iod;
> +	struct device *parent;
>  	int i, ret = 0;
>  
>  	if (!np)
> @@ -293,7 +294,14 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
>  	match = of_match_node(rockchip_iodomain_match, np);
>  	iod->soc_data = (struct rockchip_iodomain_soc_data *)match->data;
>  
> -	iod->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
> +	parent = pdev->dev.parent;
> +	if (parent && parent->of_node) {
> +		iod->grf = syscon_node_to_regmap(parent->of_node);
> +	} else {
> +		dev_dbg(&pdev->dev, "falling back to old binding\n");
> +		iod->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
> +	}
> +
>  	if (IS_ERR(iod->grf)) {
>  		dev_err(&pdev->dev, "couldn't find grf regmap\n");
>  		return PTR_ERR(iod->grf);


From linus.walleij at linaro.org  Fri Feb  5 14:49:28 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri,  5 Feb 2016 23:49:28 +0100
Subject: [PATCH] pinctrl: stm32: fix compile error and modernize
Message-ID: <1454712568-6301-1-git-send-email-linus.walleij@linaro.org>

- Fix the dev->parent assignment compile error
- Use gpiochip_get_data() to get the data pointer for the
  banks

Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
Cc: Patrice Chotard <patrice.chotard at st.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
I don't even know how to compile test this, I hope it works,
Maxime can you verify?
---
 drivers/pinctrl/stm32/pinctrl-stm32.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c
index d25d4a064bad..9a08222ecb72 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -6,7 +6,7 @@
  * Heavily based on Mediatek's pinctrl driver
  */
 #include <linux/clk.h>
-#include <linux/gpio.h>
+#include <linux/gpio/driver.h>
 #include <linux/io.h>
 #include <linux/module.h>
 #include <linux/of.h>
@@ -46,9 +46,6 @@
 #define gpio_range_to_bank(chip) \
 		container_of(chip, struct stm32_gpio_bank, range)
 
-#define gpio_chip_to_bank(chip) \
-		container_of(chip, struct stm32_gpio_bank, gpio_chip)
-
 static const char * const stm32_gpio_functions[] = {
 	"gpio", "af0", "af1",
 	"af2", "af3", "af4",
@@ -144,7 +141,7 @@ static void stm32_gpio_free(struct gpio_chip *chip, unsigned offset)
 
 static int stm32_gpio_get(struct gpio_chip *chip, unsigned offset)
 {
-	struct stm32_gpio_bank *bank = gpio_chip_to_bank(chip);
+	struct stm32_gpio_bank *bank = gpiochip_get_data(chip);
 	int ret;
 
 	clk_enable(bank->clk);
@@ -158,7 +155,7 @@ static int stm32_gpio_get(struct gpio_chip *chip, unsigned offset)
 
 static void stm32_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
 {
-	struct stm32_gpio_bank *bank = gpio_chip_to_bank(chip);
+	struct stm32_gpio_bank *bank = gpiochip_get_data(chip);
 
 	__stm32_gpio_set(bank, offset, value);
 }
@@ -171,7 +168,7 @@ static int stm32_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
 static int stm32_gpio_direction_output(struct gpio_chip *chip,
 	unsigned offset, int value)
 {
-	struct stm32_gpio_bank *bank = gpio_chip_to_bank(chip);
+	struct stm32_gpio_bank *bank = gpiochip_get_data(chip);
 
 	__stm32_gpio_set(bank, offset, value);
 	pinctrl_gpio_direction_output(chip->base + offset);
@@ -689,7 +686,7 @@ static int stm32_gpiolib_register_bank(struct stm32_pinctrl *pctl,
 	bank->gpio_chip.base = bank_nr * STM32_GPIO_PINS_PER_BANK;
 	bank->gpio_chip.ngpio = npins;
 	bank->gpio_chip.of_node = np;
-	bank->gpio_chip.dev = dev;
+	bank->gpio_chip.parent = dev;
 	spin_lock_init(&bank->lock);
 
 	of_property_read_string(np, "st,bank-name", &range->name);
@@ -699,7 +696,7 @@ static int stm32_gpiolib_register_bank(struct stm32_pinctrl *pctl,
 	range->pin_base = range->base = range->id * STM32_GPIO_PINS_PER_BANK;
 	range->npins = bank->gpio_chip.ngpio;
 	range->gc = &bank->gpio_chip;
-	err  = gpiochip_add(&bank->gpio_chip);
+	err = gpiochip_add_data(&bank->gpio_chip, bank);
 	if (err) {
 		dev_err(dev, "Failed to add gpiochip(%d)!\n", bank_nr);
 		return err;
-- 
2.4.3



From linus.walleij at linaro.org  Fri Feb  5 14:50:23 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 5 Feb 2016 23:50:23 +0100
Subject: [PATCH v4 0/9] Add STM32 pinctrl/GPIO driver
In-Reply-To: <56A92FB0.7080907@gmail.com>
References: <1452773795-24216-1-git-send-email-mcoquelin.stm32@gmail.com>
 <CACRpkdYGQ1xObWfka2CN9au6YMGhpu4qcTZpu72bzuJjO38tog@mail.gmail.com>
 <56A92FB0.7080907@gmail.com>
Message-ID: <CACRpkdY81TqbOpP35i=+-x5fHbui+iZ6-bWnwRCZUZfz2-J+rw@mail.gmail.com>

On Wed, Jan 27, 2016 at 9:59 PM, Maxime Coquelin
<mcoquelin.stm32 at gmail.com> wrote:

> How do you prefer to proceed?
> Should I send a fix on top of your devel branch, or you will fix it
> directly?

I fixed it now and also got rid of the surplus container_of
static inline. Sorry for the delay.

Yours,
Linus Walleij


From fijam at archlinux.us  Fri Feb  5 14:57:32 2016
From: fijam at archlinux.us (JM)
Date: Fri, 5 Feb 2016 23:57:32 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <8760y2vqje.fsf@natisbad.org>
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
 <20160205090246.GE32272@lunn.ch> <20160205112907.796afb05@bbrezillon>
 <CAKzmTe20fT8BcRaDaf2gz92KMAK0kEUkaD-kPq_cPF1WKBdroA@mail.gmail.com>
 <87vb632maf.fsf@free-electrons.com>
 <CAKzmTe1AqNQwjcsAULotd010NXuk1AYjj5p6UoqT_Zu=BCHdcw@mail.gmail.com>
 <87mvrf2l6p.fsf@free-electrons.com> <87io232kat.fsf@free-electrons.com>
 <8760y2vqje.fsf@natisbad.org>
Message-ID: <CAKzmTe2Lx4t49MBn0uSnMfu_HZ1b95p_j-pxZ1TY0HHg=eZy9A@mail.gmail.com>

On Fri, Feb 5, 2016 at 9:41 PM, Arnaud Ebalard <arno at natisbad.org> wrote:
> Hi guys,
>
> Gregory CLEMENT <gregory.clement at free-electrons.com> writes:
>
>> Hi,
>>
>> +cc Arnaud
>>
>>  On ven., f?vr. 05 2016, Gregory CLEMENT <gregory.clement at free-electrons.com> wrote:
>>
>>> Hi JM,
>>>
>>>  On ven., f?vr. 05 2016, JM <fijam at archlinux.us> wrote:
>>>
>>>> On Fri, Feb 5, 2016 at 4:45 PM, Gregory CLEMENT
>>>> <gregory.clement at free-electrons.com> wrote:
>>>>> Hi JM,
>>>>>
>>>>>  On ven., f?vr. 05 2016, JM <fijam at archlinux.us> wrote:
>>>>>
>>>>>> On Fri, Feb 5, 2016 at 11:29 AM, Boris Brezillon
>>>>>> <boris.brezillon at free-electrons.com> wrote:
>>>>>>> Jan, Andrew
>>>>>>>
>>>>>>> On Fri, 5 Feb 2016 10:02:46 +0100
>>>>>>> Andrew Lunn <andrew at lunn.ch> wrote:
>>>>>>>
>>>>>>>> On Fri, Feb 05, 2016 at 06:01:18AM +0100, JM wrote:
>>>>>>>> > Hi,
>>>>>>>> >
>>>>>>>> > I am testing marvell_cesa on a kirkwood device (QNAP TS-212p, Marvell
>>>>>>>> > Kirkwood 88F6282, dts: http://pastebin.com/Gk95KFHf ).
>>>>>>>> > As of kernel 4.4 (4.4.0-trunk-kirkwood #1 Debian 4.4-1~exp1) it fails
>>>>>>>> > in the following way:
>>>>>>>> >
>>>>>>>> > modprobe marvell_cesa allhwsupport=1
>>>>>>>> > dmesg | tail -n 1
>>>>>>>> > [ 1057.855091] marvell-cesa: probe of f1030000.crypto failed with error -12
>>>>>>>> >
>>>>>>>> > or:
>>>>>>>> >
>>>>>>>> > modprobe marvell_cesa
>>>>>>>> > dmesg | tail -n 1
>>>>>>>> > [ 9178.399357] marvell-cesa: probe of f1030000.crypto failed with error -524
>>>>>>>> >
>>>>>>>> > With kernel 4.3 it would fail with error -22 on that hardware. There
>>>>>>>> > are scattered reports from other users experiencing the same issue
>>>>>>>> > (1,2,3)
>>>>>>>> >
>>>>>>>> > I wonder if this is a result of an invalid definition of the
>>>>>>>> > crypto-sram in the dts of this SoC, or perhaps some other problem
>>>>>>>> > (PEBKAC included).
>>>>>>>>
>>>>>>>> Hi Jan
>>>>>>>>
>>>>>>>> Do you have SRAM enabled in your kernel configuration. The
>>>>>>>> mvebu_v5_defconfig does not have it, which is a bug really.
>>>>>>>
>>>>>>> Hm, the CRYPTO_DEV_MARVELL_CESA option selects the SRAM one [1].
>>>>>>> Anyway, I also think this error is related to the SRAM (not sure why the
>>>>>>> driver is not able to get the SRAM though).
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Boris
>>>>>>>
>>>>>>> [1]http://lxr.free-electrons.com/source/drivers/crypto/Kconfig#L168
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Boris Brezillon, Free Electrons
>>>>>>> Embedded Linux and Kernel engineering
>>>>>>> http://free-electrons.com
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Thanks for getting back to me. Indeed, CONFIG_SRAM is enabled, I put
>>>>>> the complete .config here: http://pastebin.com/40eKMJqE
>>>>>>
>>>>>> If there is anything I can do to help squish this bug, please let me
>>>>>> know.
>>>>>
>>>>> How do you get your dts?
>>>>> it seems that you generated it from your dtb (or from /proc).
>>>>>
>>>>> I tried to do the same from arch/arm/boot/dts/kirkwood-ts219-6282.dtb,
>>>>> but the resulting dts is too different for an easy comparison.
>>>>>
>>>>> Could you also provide your dtb, maybe by using the same dtc with the
>>>>> option -s I will manage to get the something easier to compare.
>>>>
>>>
>>>> Yes, I simply used dtc -I fs /proc/device-tree to obtain the dts.
>>>>
>>>> Here is the relevant .dtb file : http://heap.ovh/files/kirkwood-ts219-6282.dtb
>>>>
>>>
>>> OK so this dtb is exacly the one from the mainline. As most of the CESU
>>> stuff is set in te dtis, we will be able to compare it on the other
>>> kirkwood based board.
>>>
>>> Gregory
>>
>> So with the help of Boris we checked the ranges propreties, the reg
>> property and the clock too. Everyting seems OK.
>>
>> Arnaud,
>>
>> as you are the on who tested the cesa on kirkwood, do you remember if
>> you needed to add specific Kconfig or to made some change in the dts?
>
> Here is the result I get on my ReadyNAS Duo v2 (88F6282, see below) w/ a
> stock 4.4 kernel I just cross-compiled w/ a gcc 4.9.2. The kernel has no
> modules and uses an appended DTB (u-boot on the platform is pretyy old):
>
> root at mood:~# dmesg | grep -i cesa
> [    3.306135] marvell-cesa f1030000.crypto: CESA device successfully registered
>
> root at mood:~# uname -a
> Linux mood 4.4.0.duov2 #1 Fri Feb 5 21:11:25 CET 2016 armv5tel GNU/Linux
>
> root at mood:~# cat /proc/cpuinfo
> processor       : 0
> model name      : Feroceon 88FR131 rev 1 (v5l)
> BogoMIPS        : 1594.16
> Features        : swp half thumb fastmult edsp
> CPU implementer : 0x56
> CPU architecture: 5TE
> CPU variant     : 0x2
> CPU part        : 0x131
> CPU revision    : 1
>
> Hardware        : Marvell Kirkwood (Flattened Device Tree)
> Revision        : 0000
> Serial          : 0000000000000000
>
> I'll try and do the same now w/ CESA support compiled as module to see
> what I get. I'll keep you posted.
>
> As a side note, a simple grep on the .config file you provided at
> http://pastebin.com/40eKMJqE makes me wonder why it has some
> grsec options residue. Did you test on a stock 4.4 kernel or on
> something w/ additional patches? If the latter, could you check what a
> stock kernel gives?
>
> Cheers,
>
> a+

Thanks for the reply. Your cpuinfo is exactly the same as mine. I am
using the kernel as shipped by Debian (4.4 from experimental). I was
directed from a Debian ARM mailing list to report to upstream, but
perhaps it is a distribution-specific bug. I will try to build a
vanilla kernel, although that will take me some time (no
cross-compilation environment at hand). I will keep you posted.

Best regards,
Jan


From rjw at rjwysocki.net  Fri Feb  5 15:26:37 2016
From: rjw at rjwysocki.net (Rafael J. Wysocki)
Date: Sat, 06 Feb 2016 00:26:37 +0100
Subject: [PATCH v7 5/5] PCI: ACPI: Add a generic ACPI based host controller
In-Reply-To: <20160205094740.GA31547@red-moon>
References: <1454058340-7904-1-git-send-email-jchandra@broadcom.com>
 <CAKc_7PXYtFt1MQE-UGO0O5vvQ+xFKa2b5=F8wXB=EN-JUJVzZw@mail.gmail.com>
 <20160205094740.GA31547@red-moon>
Message-ID: <3576289.1ltj0IceQ5@vostro.rjw.lan>

On Friday, February 05, 2016 09:47:40 AM Lorenzo Pieralisi wrote:
> On Fri, Feb 05, 2016 at 02:05:37PM +0530, Jayachandran Chandrashekaran Nair wrote:
> 
> [...]
> 
> > pci_host_acpi.c is a generic implementation of these using a sysdata
> > pointing to acpi_pci_root_info, and using a pointer to the pci_mmcfg_region
> > to access ECAM area, Maybe I can rename this file to
> > pci_acpi_host_generic.c to reflect this better.
> 
> Maybe you should stop sending this series and work with Tomasz to
> get this done, you are confusing everyone and I am really really
> annoyed about this.
> 
> Do you realize there is no point in having two patch series doing
> the same thing and wasting everyone's review time ?
> 
> Do you realize he started this work long before you and went through
> several rounds of review already (I told you before but in case you
> forgot) ?
> 
> Tomasz posted a version yesterday, integrating comments following months
> of review and testing and I think it is ready to get upstream:
> 
> https://lkml.org/lkml/2016/2/4/646
> 
> Did you even consider reviewing his code or helping him instead of
> churning out more patches doing the *SAME* thing ?
> 
> Do you want all of us to go through your code and re-fix what has
> already been fixed in Tomasz's series with the end result of missing
> yet another merge window ?
> 
> This is really annoying, stop it please, really.

OK, so to be crystal clear here.

I'm going to ignore the series the $subject patch belongs to going forward.

Thanks,
Rafael



From yang.shi at linaro.org  Fri Feb  5 15:04:47 2016
From: yang.shi at linaro.org (Yang Shi)
Date: Fri,  5 Feb 2016 15:04:47 -0800
Subject: [PATCH] arm64: disable kasan when accessing frame->fp in unwind_frame
Message-ID: <1454713487-5239-1-git-send-email-yang.shi@linaro.org>

When boot arm64 kernel with KASAN enabled, the below error is reported by
kasan:

BUG: KASAN: out-of-bounds in unwind_frame+0xec/0x260 at addr ffffffc064d57ba0
Read of size 8 by task pidof/499
page:ffffffbdc39355c0 count:0 mapcount:0 mapping:          (null) index:0x0
flags: 0x0()
page dumped because: kasan: bad access detected
CPU: 2 PID: 499 Comm: pidof Not tainted 4.5.0-rc1 #119
Hardware name: Freescale Layerscape 2085a RDB Board (DT)
Call trace:
[<ffffffc00008d078>] dump_backtrace+0x0/0x290
[<ffffffc00008d32c>] show_stack+0x24/0x30
[<ffffffc0006a981c>] dump_stack+0x8c/0xd8
[<ffffffc0002e4400>] kasan_report_error+0x558/0x588
[<ffffffc0002e4958>] kasan_report+0x60/0x70
[<ffffffc0002e3188>] __asan_load8+0x60/0x78
[<ffffffc00008c92c>] unwind_frame+0xec/0x260
[<ffffffc000087e60>] get_wchan+0x110/0x160
[<ffffffc0003b647c>] do_task_stat+0xb44/0xb68
[<ffffffc0003b7730>] proc_tgid_stat+0x40/0x50
[<ffffffc0003ac840>] proc_single_show+0x88/0xd8
[<ffffffc000345be8>] seq_read+0x370/0x770
[<ffffffc00030aba0>] __vfs_read+0xc8/0x1d8
[<ffffffc00030c0ec>] vfs_read+0x94/0x168
[<ffffffc00030d458>] SyS_read+0xb8/0x128
[<ffffffc000086530>] el0_svc_naked+0x24/0x28
Memory state around the buggy address:
 ffffffc064d57a80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4
 ffffffc064d57b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffffc064d57b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                                  ^
 ffffffc064d57c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffffc064d57c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Since the shadow byte pointed by the report is 0, so it may mean it is just hit
oob in non-current task. So, disable the instrumentation here.

Signed-off-by: Yang Shi <yang.shi at linaro.org>
---
 arch/arm64/kernel/stacktrace.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 4fad978..88278c2 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -20,6 +20,7 @@
 #include <linux/ftrace.h>
 #include <linux/sched.h>
 #include <linux/stacktrace.h>
+#include <linux/kasan.h>
 
 #include <asm/irq.h>
 #include <asm/stacktrace.h>
@@ -64,7 +65,9 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
 		return -EINVAL;
 
 	frame->sp = fp + 0x10;
+	kasan_disable_current();
 	frame->fp = *(unsigned long *)(fp);
+	kasan_enable_current();
 	frame->pc = *(unsigned long *)(fp + 8);
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
-- 
2.0.2



From ddaney.cavm at gmail.com  Fri Feb  5 15:41:12 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri,  5 Feb 2016 15:41:12 -0800
Subject: [PATCH v5 0/3] Add host controller drivers for Cavium ThunderX PCI
Message-ID: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>

From: David Daney <david.daney at cavium.com>

Some Cavium ThunderX processors require quirky access methods for the
config space of the PCIe bridge.

There are now three patches:

1) Refactor code in pci-host-generic so that it can more easily be
   used by other drivers.  This splits the driver for CAM and ECAM
   access methods to a separate file from the common host driver code.

2) Add the ThunderX PCIe driver to external PCIe buses, which
   leverages the code in pci-host-generic

3) Add ThunderX PCI driver for internel SoC buses used on early
   ThunderX chip revisions.

Changes from v4: Added patch 3/3.  Stylistic changes to 2/3 suggested
by Bjorn Helgaas.  When expanding config write width to 32-bits, mask
out unintened writes to W1C bits, also suggested by Bjorn Helgaas.

Changes from v3: Add some Acked-by, rebased to v4.5.0-rc1

Changes from v2: Improve device tree binding example as noted by Rob
Herring.  Rename pcie-thunder-pem.* to pci-thunder-pem.* for better
consistency.  Update MAINTAINERS to reflect the changes.

Changes from v1: Split CAM and ECAM code from common driver code as
suggested by Arnd Bergmann.  Fix spelling errors in
pcie-thunder-pem.txt

David Daney (3):
  PCI: generic: Refactor code to enable reuse by other drivers.
  pci, pci-thunder-pem: Add PCIe host driver for ThunderX processors.
  pci, pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices

 .../devicetree/bindings/pci/pci-thunder-ecam.txt   |  30 ++
 .../devicetree/bindings/pci/pci-thunder-pem.txt    |  43 +++
 MAINTAINERS                                        |   9 +
 drivers/pci/host/Kconfig                           |  18 ++
 drivers/pci/host/Makefile                          |   3 +
 drivers/pci/host/pci-host-common.c                 | 194 +++++++++++
 drivers/pci/host/pci-host-common.h                 |  47 +++
 drivers/pci/host/pci-host-generic.c                | 181 +----------
 drivers/pci/host/pci-thunder-ecam.c                | 358 +++++++++++++++++++++
 drivers/pci/host/pci-thunder-pem.c                 | 332 +++++++++++++++++++
 10 files changed, 1038 insertions(+), 177 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt
 create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-pem.txt
 create mode 100644 drivers/pci/host/pci-host-common.c
 create mode 100644 drivers/pci/host/pci-host-common.h
 create mode 100644 drivers/pci/host/pci-thunder-ecam.c
 create mode 100644 drivers/pci/host/pci-thunder-pem.c

-- 
1.8.3.1



From ddaney.cavm at gmail.com  Fri Feb  5 15:41:13 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri,  5 Feb 2016 15:41:13 -0800
Subject: [PATCH v5 1/3] PCI: generic: Refactor code to enable reuse by other
 drivers.
In-Reply-To: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1454715675-17512-2-git-send-email-ddaney.cavm@gmail.com>

From: David Daney <david.daney at cavium.com>

No change in functionality.

Move structure definitions into a separate header file.  Move common
code to new file with Kconfig machinery to build it.  Split probe
function in to two parts:

   - a small driver specific probe function (gen_pci_probe)

   - a common probe that can be used by other drivers
     (pci_host_common_probe)

Signed-off-by: David Daney <david.daney at cavium.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Will Deacon <will.deacon at arm.com>
---
 MAINTAINERS                         |   1 +
 drivers/pci/host/Kconfig            |   4 +
 drivers/pci/host/Makefile           |   1 +
 drivers/pci/host/pci-host-common.c  | 194 ++++++++++++++++++++++++++++++++++++
 drivers/pci/host/pci-host-common.h  |  47 +++++++++
 drivers/pci/host/pci-host-generic.c | 181 +--------------------------------
 6 files changed, 251 insertions(+), 177 deletions(-)
 create mode 100644 drivers/pci/host/pci-host-common.c
 create mode 100644 drivers/pci/host/pci-host-common.h

diff --git a/MAINTAINERS b/MAINTAINERS
index a9010d9..9287929 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8367,6 +8367,7 @@ L:	linux-pci at vger.kernel.org
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
 S:	Maintained
 F:	Documentation/devicetree/bindings/pci/host-generic-pci.txt
+F:	drivers/pci/host/pci-host-common.c
 F:	drivers/pci/host/pci-host-generic.c
 
 PCI DRIVER FOR INTEL VOLUME MANAGEMENT DEVICE (VMD)
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 75a6054..65709b4 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -53,9 +53,13 @@ config PCI_RCAR_GEN2_PCIE
 	help
 	  Say Y here if you want PCIe controller support on R-Car Gen2 SoCs.
 
+config PCI_HOST_COMMON
+	bool
+
 config PCI_HOST_GENERIC
 	bool "Generic PCI host controller"
 	depends on (ARM || ARM64) && OF
+	select PCI_HOST_COMMON
 	help
 	  Say Y here if you want to support a simple generic PCI host
 	  controller, such as the one emulated by kvmtool.
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 7b2f20c..3b24af8 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
 obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
 obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
 obj-$(CONFIG_PCI_RCAR_GEN2_PCIE) += pcie-rcar.o
+obj-$(CONFIG_PCI_HOST_COMMON) += pci-host-common.o
 obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
 obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
 obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
diff --git a/drivers/pci/host/pci-host-common.c b/drivers/pci/host/pci-host-common.c
new file mode 100644
index 0000000..e9f850f
--- /dev/null
+++ b/drivers/pci/host/pci-host-common.c
@@ -0,0 +1,194 @@
+/*
+ * 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/>.
+ *
+ * Copyright (C) 2014 ARM Limited
+ *
+ * Author: Will Deacon <will.deacon at arm.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_pci.h>
+#include <linux/platform_device.h>
+
+#include "pci-host-common.h"
+
+static void gen_pci_release_of_pci_ranges(struct gen_pci *pci)
+{
+	pci_free_resource_list(&pci->resources);
+}
+
+static int gen_pci_parse_request_of_pci_ranges(struct gen_pci *pci)
+{
+	int err, res_valid = 0;
+	struct device *dev = pci->host.dev.parent;
+	struct device_node *np = dev->of_node;
+	resource_size_t iobase;
+	struct resource_entry *win;
+
+	err = of_pci_get_host_bridge_resources(np, 0, 0xff, &pci->resources,
+					       &iobase);
+	if (err)
+		return err;
+
+	resource_list_for_each_entry(win, &pci->resources) {
+		struct resource *parent, *res = win->res;
+
+		switch (resource_type(res)) {
+		case IORESOURCE_IO:
+			parent = &ioport_resource;
+			err = pci_remap_iospace(res, iobase);
+			if (err) {
+				dev_warn(dev, "error %d: failed to map resource %pR\n",
+					 err, res);
+				continue;
+			}
+			break;
+		case IORESOURCE_MEM:
+			parent = &iomem_resource;
+			res_valid |= !(res->flags & IORESOURCE_PREFETCH);
+			break;
+		case IORESOURCE_BUS:
+			pci->cfg.bus_range = res;
+		default:
+			continue;
+		}
+
+		err = devm_request_resource(dev, parent, res);
+		if (err)
+			goto out_release_res;
+	}
+
+	if (!res_valid) {
+		dev_err(dev, "non-prefetchable memory resource required\n");
+		err = -EINVAL;
+		goto out_release_res;
+	}
+
+	return 0;
+
+out_release_res:
+	gen_pci_release_of_pci_ranges(pci);
+	return err;
+}
+
+static int gen_pci_parse_map_cfg_windows(struct gen_pci *pci)
+{
+	int err;
+	u8 bus_max;
+	resource_size_t busn;
+	struct resource *bus_range;
+	struct device *dev = pci->host.dev.parent;
+	struct device_node *np = dev->of_node;
+	u32 sz = 1 << pci->cfg.ops->bus_shift;
+
+	err = of_address_to_resource(np, 0, &pci->cfg.res);
+	if (err) {
+		dev_err(dev, "missing \"reg\" property\n");
+		return err;
+	}
+
+	/* Limit the bus-range to fit within reg */
+	bus_max = pci->cfg.bus_range->start +
+		  (resource_size(&pci->cfg.res) >> pci->cfg.ops->bus_shift) - 1;
+	pci->cfg.bus_range->end = min_t(resource_size_t,
+					pci->cfg.bus_range->end, bus_max);
+
+	pci->cfg.win = devm_kcalloc(dev, resource_size(pci->cfg.bus_range),
+				    sizeof(*pci->cfg.win), GFP_KERNEL);
+	if (!pci->cfg.win)
+		return -ENOMEM;
+
+	/* Map our Configuration Space windows */
+	if (!devm_request_mem_region(dev, pci->cfg.res.start,
+				     resource_size(&pci->cfg.res),
+				     "Configuration Space"))
+		return -ENOMEM;
+
+	bus_range = pci->cfg.bus_range;
+	for (busn = bus_range->start; busn <= bus_range->end; ++busn) {
+		u32 idx = busn - bus_range->start;
+
+		pci->cfg.win[idx] = devm_ioremap(dev,
+						 pci->cfg.res.start + idx * sz,
+						 sz);
+		if (!pci->cfg.win[idx])
+			return -ENOMEM;
+	}
+
+	return 0;
+}
+
+int pci_host_common_probe(struct platform_device *pdev,
+			  struct gen_pci *pci)
+{
+	int err;
+	const char *type;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct pci_bus *bus, *child;
+
+	type = of_get_property(np, "device_type", NULL);
+	if (!type || strcmp(type, "pci")) {
+		dev_err(dev, "invalid \"device_type\" %s\n", type);
+		return -EINVAL;
+	}
+
+	of_pci_check_probe_only();
+
+	pci->host.dev.parent = dev;
+	INIT_LIST_HEAD(&pci->host.windows);
+	INIT_LIST_HEAD(&pci->resources);
+
+	/* Parse our PCI ranges and request their resources */
+	err = gen_pci_parse_request_of_pci_ranges(pci);
+	if (err)
+		return err;
+
+	/* Parse and map our Configuration Space windows */
+	err = gen_pci_parse_map_cfg_windows(pci);
+	if (err) {
+		gen_pci_release_of_pci_ranges(pci);
+		return err;
+	}
+
+	/* Do not reassign resources if probe only */
+	if (!pci_has_flag(PCI_PROBE_ONLY))
+		pci_add_flags(PCI_REASSIGN_ALL_RSRC | PCI_REASSIGN_ALL_BUS);
+
+
+	bus = pci_scan_root_bus(dev, pci->cfg.bus_range->start,
+				&pci->cfg.ops->ops, pci, &pci->resources);
+	if (!bus) {
+		dev_err(dev, "Scanning rootbus failed");
+		return -ENODEV;
+	}
+
+	pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
+
+	if (!pci_has_flag(PCI_PROBE_ONLY)) {
+		pci_bus_size_bridges(bus);
+		pci_bus_assign_resources(bus);
+
+		list_for_each_entry(child, &bus->children, node)
+			pcie_bus_configure_settings(child);
+	}
+
+	pci_bus_add_devices(bus);
+	return 0;
+}
+
+MODULE_DESCRIPTION("Generic PCI host driver common code");
+MODULE_AUTHOR("Will Deacon <will.deacon at arm.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/pci/host/pci-host-common.h b/drivers/pci/host/pci-host-common.h
new file mode 100644
index 0000000..09f3fa0
--- /dev/null
+++ b/drivers/pci/host/pci-host-common.h
@@ -0,0 +1,47 @@
+/*
+ * 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/>.
+ *
+ * Copyright (C) 2014 ARM Limited
+ *
+ * Author: Will Deacon <will.deacon at arm.com>
+ */
+
+#ifndef _PCI_HOST_COMMON_H
+#define _PCI_HOST_COMMON_H
+
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+
+struct gen_pci_cfg_bus_ops {
+	u32 bus_shift;
+	struct pci_ops ops;
+};
+
+struct gen_pci_cfg_windows {
+	struct resource				res;
+	struct resource				*bus_range;
+	void __iomem				**win;
+
+	struct gen_pci_cfg_bus_ops		*ops;
+};
+
+struct gen_pci {
+	struct pci_host_bridge			host;
+	struct gen_pci_cfg_windows		cfg;
+	struct list_head			resources;
+};
+
+int pci_host_common_probe(struct platform_device *pdev,
+			  struct gen_pci *pci);
+
+#endif /* _PCI_HOST_COMMON_H */
diff --git a/drivers/pci/host/pci-host-generic.c b/drivers/pci/host/pci-host-generic.c
index 1652bc7..e8aa78f 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -25,24 +25,7 @@
 #include <linux/of_pci.h>
 #include <linux/platform_device.h>
 
-struct gen_pci_cfg_bus_ops {
-	u32 bus_shift;
-	struct pci_ops ops;
-};
-
-struct gen_pci_cfg_windows {
-	struct resource				res;
-	struct resource				*bus_range;
-	void __iomem				**win;
-
-	struct gen_pci_cfg_bus_ops		*ops;
-};
-
-struct gen_pci {
-	struct pci_host_bridge			host;
-	struct gen_pci_cfg_windows		cfg;
-	struct list_head			resources;
-};
+#include "pci-host-common.h"
 
 static void __iomem *gen_pci_map_cfg_bus_cam(struct pci_bus *bus,
 					     unsigned int devfn,
@@ -93,175 +76,19 @@ static const struct of_device_id gen_pci_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, gen_pci_of_match);
 
-static void gen_pci_release_of_pci_ranges(struct gen_pci *pci)
-{
-	pci_free_resource_list(&pci->resources);
-}
-
-static int gen_pci_parse_request_of_pci_ranges(struct gen_pci *pci)
-{
-	int err, res_valid = 0;
-	struct device *dev = pci->host.dev.parent;
-	struct device_node *np = dev->of_node;
-	resource_size_t iobase;
-	struct resource_entry *win;
-
-	err = of_pci_get_host_bridge_resources(np, 0, 0xff, &pci->resources,
-					       &iobase);
-	if (err)
-		return err;
-
-	resource_list_for_each_entry(win, &pci->resources) {
-		struct resource *parent, *res = win->res;
-
-		switch (resource_type(res)) {
-		case IORESOURCE_IO:
-			parent = &ioport_resource;
-			err = pci_remap_iospace(res, iobase);
-			if (err) {
-				dev_warn(dev, "error %d: failed to map resource %pR\n",
-					 err, res);
-				continue;
-			}
-			break;
-		case IORESOURCE_MEM:
-			parent = &iomem_resource;
-			res_valid |= !(res->flags & IORESOURCE_PREFETCH);
-			break;
-		case IORESOURCE_BUS:
-			pci->cfg.bus_range = res;
-		default:
-			continue;
-		}
-
-		err = devm_request_resource(dev, parent, res);
-		if (err)
-			goto out_release_res;
-	}
-
-	if (!res_valid) {
-		dev_err(dev, "non-prefetchable memory resource required\n");
-		err = -EINVAL;
-		goto out_release_res;
-	}
-
-	return 0;
-
-out_release_res:
-	gen_pci_release_of_pci_ranges(pci);
-	return err;
-}
-
-static int gen_pci_parse_map_cfg_windows(struct gen_pci *pci)
-{
-	int err;
-	u8 bus_max;
-	resource_size_t busn;
-	struct resource *bus_range;
-	struct device *dev = pci->host.dev.parent;
-	struct device_node *np = dev->of_node;
-	u32 sz = 1 << pci->cfg.ops->bus_shift;
-
-	err = of_address_to_resource(np, 0, &pci->cfg.res);
-	if (err) {
-		dev_err(dev, "missing \"reg\" property\n");
-		return err;
-	}
-
-	/* Limit the bus-range to fit within reg */
-	bus_max = pci->cfg.bus_range->start +
-		  (resource_size(&pci->cfg.res) >> pci->cfg.ops->bus_shift) - 1;
-	pci->cfg.bus_range->end = min_t(resource_size_t,
-					pci->cfg.bus_range->end, bus_max);
-
-	pci->cfg.win = devm_kcalloc(dev, resource_size(pci->cfg.bus_range),
-				    sizeof(*pci->cfg.win), GFP_KERNEL);
-	if (!pci->cfg.win)
-		return -ENOMEM;
-
-	/* Map our Configuration Space windows */
-	if (!devm_request_mem_region(dev, pci->cfg.res.start,
-				     resource_size(&pci->cfg.res),
-				     "Configuration Space"))
-		return -ENOMEM;
-
-	bus_range = pci->cfg.bus_range;
-	for (busn = bus_range->start; busn <= bus_range->end; ++busn) {
-		u32 idx = busn - bus_range->start;
-
-		pci->cfg.win[idx] = devm_ioremap(dev,
-						 pci->cfg.res.start + idx * sz,
-						 sz);
-		if (!pci->cfg.win[idx])
-			return -ENOMEM;
-	}
-
-	return 0;
-}
-
 static int gen_pci_probe(struct platform_device *pdev)
 {
-	int err;
-	const char *type;
-	const struct of_device_id *of_id;
 	struct device *dev = &pdev->dev;
-	struct device_node *np = dev->of_node;
+	const struct of_device_id *of_id;
 	struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
-	struct pci_bus *bus, *child;
 
 	if (!pci)
 		return -ENOMEM;
 
-	type = of_get_property(np, "device_type", NULL);
-	if (!type || strcmp(type, "pci")) {
-		dev_err(dev, "invalid \"device_type\" %s\n", type);
-		return -EINVAL;
-	}
-
-	of_pci_check_probe_only();
-
-	of_id = of_match_node(gen_pci_of_match, np);
+	of_id = of_match_node(gen_pci_of_match, dev->of_node);
 	pci->cfg.ops = (struct gen_pci_cfg_bus_ops *)of_id->data;
-	pci->host.dev.parent = dev;
-	INIT_LIST_HEAD(&pci->host.windows);
-	INIT_LIST_HEAD(&pci->resources);
-
-	/* Parse our PCI ranges and request their resources */
-	err = gen_pci_parse_request_of_pci_ranges(pci);
-	if (err)
-		return err;
-
-	/* Parse and map our Configuration Space windows */
-	err = gen_pci_parse_map_cfg_windows(pci);
-	if (err) {
-		gen_pci_release_of_pci_ranges(pci);
-		return err;
-	}
-
-	/* Do not reassign resources if probe only */
-	if (!pci_has_flag(PCI_PROBE_ONLY))
-		pci_add_flags(PCI_REASSIGN_ALL_RSRC | PCI_REASSIGN_ALL_BUS);
-
-
-	bus = pci_scan_root_bus(dev, pci->cfg.bus_range->start,
-				&pci->cfg.ops->ops, pci, &pci->resources);
-	if (!bus) {
-		dev_err(dev, "Scanning rootbus failed");
-		return -ENODEV;
-	}
-
-	pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
-
-	if (!pci_has_flag(PCI_PROBE_ONLY)) {
-		pci_bus_size_bridges(bus);
-		pci_bus_assign_resources(bus);
-
-		list_for_each_entry(child, &bus->children, node)
-			pcie_bus_configure_settings(child);
-	}
 
-	pci_bus_add_devices(bus);
-	return 0;
+	return pci_host_common_probe(pdev, pci);
 }
 
 static struct platform_driver gen_pci_driver = {
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Fri Feb  5 15:41:14 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri,  5 Feb 2016 15:41:14 -0800
Subject: [PATCH v5 2/3] pci,
 pci-thunder-pem: Add PCIe host driver for ThunderX processors.
In-Reply-To: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1454715675-17512-3-git-send-email-ddaney.cavm@gmail.com>

From: David Daney <david.daney at cavium.com>

The root complexes used to access off-chip PCIe devices (called PEM
units in the hardware manuals) on some Cavium ThunderX processors
require quirky access methods for the config space of the PCIe bridge.
Add a driver to provide these config space accessor functions.  The
pci-host-common code is used to configure the PCI machinery.

Signed-off-by: David Daney <david.daney at cavium.com>
Acked-by: Rob Herring <robh at kernel.org>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 .../devicetree/bindings/pci/pci-thunder-pem.txt    |  43 +++
 MAINTAINERS                                        |   8 +
 drivers/pci/host/Kconfig                           |   7 +
 drivers/pci/host/Makefile                          |   1 +
 drivers/pci/host/pci-thunder-pem.c                 | 332 +++++++++++++++++++++
 5 files changed, 391 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-pem.txt
 create mode 100644 drivers/pci/host/pci-thunder-pem.c

diff --git a/Documentation/devicetree/bindings/pci/pci-thunder-pem.txt b/Documentation/devicetree/bindings/pci/pci-thunder-pem.txt
new file mode 100644
index 0000000..f131fae
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pci-thunder-pem.txt
@@ -0,0 +1,43 @@
+* ThunderX PEM PCIe host controller
+
+Firmware-initialized PCI host controller found on some Cavium
+ThunderX processors.
+
+The properties and their meanings are identical to those described in
+host-generic-pci.txt except as listed below.
+
+Properties of the host controller node that differ from
+host-generic-pci.txt:
+
+- compatible     : Must be "cavium,pci-host-thunder-pem"
+
+- reg            : Two entries: First the configuration space for down
+                   stream devices base address and size, as accessed
+                   from the parent bus. Second, the register bank of
+                   the PEM device PCIe bridge.
+
+Example:
+
+    pci at 87e0,c2000000 {
+	compatible = "cavium,pci-host-thunder-pem";
+	device_type = "pci";
+	msi-parent = <&its>;
+	msi-map = <0 &its 0x10000 0x10000>;
+	bus-range = <0x8f 0xc7>;
+	#size-cells = <2>;
+	#address-cells = <3>;
+
+	reg = <0x8880 0x8f000000 0x0 0x39000000>,  /* Configuration space */
+	      <0x87e0 0xc2000000 0x0 0x00010000>; /* PEM space */
+	ranges = <0x01000000 0x00 0x00020000 0x88b0 0x00020000 0x00 0x00010000>, /* I/O */
+		 <0x03000000 0x00 0x10000000 0x8890 0x10000000 0x0f 0xf0000000>, /* mem64 */
+		 <0x43000000 0x10 0x00000000 0x88a0 0x00000000 0x10 0x00000000>, /* mem64-pref */
+		 <0x03000000 0x87e0 0xc2f00000 0x87e0 0xc2000000 0x00 0x00100000>; /* mem64 PEM BAR4 */
+
+	#interrupt-cells = <1>;
+	interrupt-map-mask = <0 0 0 7>;
+	interrupt-map = <0 0 0 1 &gic0 0 0 0 24 4>, /* INTA */
+			<0 0 0 2 &gic0 0 0 0 25 4>, /* INTB */
+			<0 0 0 3 &gic0 0 0 0 26 4>, /* INTC */
+			<0 0 0 4 &gic0 0 0 0 27 4>; /* INTD */
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index 9287929..ff5c367 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8413,6 +8413,14 @@ L:     linux-arm-msm at vger.kernel.org
 S:     Maintained
 F:     drivers/pci/host/*qcom*
 
+PCIE DRIVER FOR CAVIUM THUNDERX
+M:	David Daney <david.daney at cavium.com>
+L:	linux-pci at vger.kernel.org
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S:	Supported
+F:	Documentation/devicetree/bindings/pci/pci-thunder-*
+F:	drivers/pci/host/pci-thunder-*
+
 PCMCIA SUBSYSTEM
 P:	Linux PCMCIA Team
 L:	linux-pcmcia at lists.infradead.org
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 65709b4..184df22 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -195,4 +195,11 @@ config PCIE_QCOM
 	  PCIe controller uses the Designware core plus Qualcomm-specific
 	  hardware wrappers.
 
+config PCI_HOST_THUNDER_PEM
+	bool "Cavium Thunder PCIe controller to off-chip devices"
+	depends on OF && ARM64
+	select PCI_HOST_COMMON
+	help
+	  Say Y here if you want PCIe support for CN88XX Cavium Thunder SoCs.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 3b24af8..8903172 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
 obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
+obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
new file mode 100644
index 0000000..e3a6554
--- /dev/null
+++ b/drivers/pci/host/pci-thunder-pem.c
@@ -0,0 +1,332 @@
+/*
+ * 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/>.
+ *
+ * Copyright (C) 2015 - 2016 Cavium, Inc.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_pci.h>
+#include <linux/platform_device.h>
+
+#include "pci-host-common.h"
+
+#define PEM_CFG_WR 0x28
+#define PEM_CFG_RD 0x30
+
+struct thunder_pem_pci {
+	struct gen_pci	gen_pci;
+	u32		ea_entry[3];
+	void __iomem	*pem_reg_base;
+};
+
+static void __iomem *thunder_pem_map_bus(struct pci_bus *bus,
+					 unsigned int devfn, int where)
+{
+	struct gen_pci *pci = bus->sysdata;
+	resource_size_t idx = bus->number - pci->cfg.bus_range->start;
+
+	return pci->cfg.win[idx] + ((devfn << 16) | where);
+}
+
+static int thunder_pem_config_read(struct pci_bus *bus, unsigned int devfn,
+				   int where, int size, u32 *val)
+{
+	int r;
+	struct thunder_pem_pci *pem_pci;
+	struct gen_pci *pci = bus->sysdata;
+
+	pem_pci = container_of(pci, struct thunder_pem_pci, gen_pci);
+
+	/*
+	 * The first device on the bus in the PEM PCIe bridge.
+	 * Special case its config access.
+	 */
+	if (bus->number == pci->cfg.bus_range->start) {
+		u64 read_val;
+
+		if (devfn != 0 || where >= 2048) {
+			*val = ~0;
+			return PCIBIOS_DEVICE_NOT_FOUND;
+		}
+
+		/*
+		 * 32-bit accesses only.  Write the address to the low
+		 * order bits of PEM_CFG_RD, then trigger the read by
+		 * reading back.  The config data lands in the upper
+		 * 32-bits of PEM_CFG_RD.
+		 */
+		read_val = where & ~3ull;
+		writeq(read_val, pem_pci->pem_reg_base + PEM_CFG_RD);
+		read_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
+		read_val >>= 32;
+
+		/*
+		 * The config space contains some garbage, fix it up.
+		 * Also synthesize an EA capability for the BAR used
+		 * by MSI-X.
+		 */
+		switch (where & ~3u) {
+		case 0x40:
+			read_val &= 0xffff00ff;
+			read_val |= 0x00007000; /* Skip MSI CAP */
+			break;
+		case 0x70: /* Express Cap */
+			/* PME interrupt on vector 2*/
+			read_val |= (2u << 25);
+			break;
+		case 0xb0: /* MSI-X Cap */
+			/* TableSize=4, Next Cap is EA */
+			read_val &= 0xc00000ff;
+			read_val |= 0x0003bc00;
+			break;
+		case 0xb4:
+			/* Table offset=0, BIR=0 */
+			read_val = 0x00000000;
+			break;
+		case 0xb8:
+			/* BPA offset=0xf0000, BIR=0 */
+			read_val = 0x000f0000;
+			break;
+		case 0xbc:
+			/* EA, 1 entry, no next Cap */
+			read_val = 0x00010014;
+			break;
+		case 0xc0:
+			/* DW2 for type-1 */
+			read_val = 0x00000000;
+			break;
+		case 0xc4:
+			/* Entry BEI=0, PP=0x00, SP=0xff, ES=3 */
+			read_val = 0x80ff0003;
+			break;
+		case 0xc8:
+			read_val = pem_pci->ea_entry[0];
+			break;
+		case 0xcc:
+			read_val = pem_pci->ea_entry[1];
+			break;
+		case 0xd0:
+			read_val = pem_pci->ea_entry[2];
+			break;
+		default:
+			break;
+		}
+		read_val >>= (8 * (where & 3));
+		switch (size) {
+		case 1:
+			read_val &= 0xff;
+			break;
+		case 2:
+			read_val &= 0xffff;
+			break;
+		default:
+			break;
+		}
+		*val = read_val;
+		return PCIBIOS_SUCCESSFUL;
+	}
+	if (bus->number < pci->cfg.bus_range->start ||
+	    bus->number > pci->cfg.bus_range->end)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	r = pci_generic_config_read(bus, devfn, where, size, val);
+	return r;
+}
+
+static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
+				    int where, int size, u32 val)
+{
+	struct gen_pci *pci = bus->sysdata;
+	struct thunder_pem_pci *pem_pci;
+
+	pem_pci = container_of(pci, struct thunder_pem_pci, gen_pci);
+
+	/*
+	 * The first device on the bus in the PEM PCIe bridge.
+	 * Special case its config access.
+	 */
+	if (bus->number == pci->cfg.bus_range->start) {
+		u64 write_val, read_val;
+		u32 mask = 0;
+
+		if (devfn != 0 || where >= 2048)
+			return PCIBIOS_DEVICE_NOT_FOUND;
+
+		/*
+		 * 32-bit accesses only.  If the write is for a size
+		 * smaller than 32-bits, we must first read the 32-bit
+		 * value and merge in the desired bits and then write
+		 * the whole 32-bits back out.
+		 */
+		switch (size) {
+		case 1:
+			read_val = where & ~3ull;
+			writeq(read_val, pem_pci->pem_reg_base + PEM_CFG_RD);
+			read_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
+			read_val >>= 32;
+			mask = ~(0xff << (8 * (where & 3)));
+			read_val &= mask;
+			val = (val & 0xff) << (8 * (where & 3));
+			val |= (u32)read_val;
+			break;
+		case 2:
+			read_val = where & ~3ull;
+			writeq(read_val, pem_pci->pem_reg_base + PEM_CFG_RD);
+			read_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
+			read_val >>= 32;
+			mask = ~(0xffff << (8 * (where & 3)));
+			read_val &= mask;
+			val = (val & 0xffff) << (8 * (where & 3));
+			val |= (u32)read_val;
+			break;
+		default:
+			break;
+
+		}
+
+		if (mask) {
+			/*
+			 * By expanding the write width to 32 bits, we
+			 * may inadvertently hit some W1C bits that
+			 * were not intended to be written.  Mask
+			 * these out.
+			 *
+			 * Some of the w1c_bits below also include
+			 * read-only or non-writable reserved bits,
+			 * this makes the code simpler and is OK as
+			 * the bits are not affected by writing zeros
+			 * to them.
+			 */
+			u32 w1c_bits = 0;
+
+			switch (where & 3) {
+			case 0x04: /* Command/Status */
+			case 0x1c: /* Base and I/O Limit/Secondary Status */
+				w1c_bits = 0xff000000;
+				break;
+			case 0x44: /* Power Management Control and Status */
+				w1c_bits = 0xfffffe00;
+				break;
+			case 0x78: /* Device Control/Device Status */
+			case 0x80: /* Link Control/Link Status */
+			case 0x88: /* Slot Control/Slot Status */
+			case 0x90: /* Root Status */
+			case 0xa0: /* Link Control 2 Registers/Link Status 2 */
+				w1c_bits = 0xffff0000;
+				break;
+			case 0x104: /* Uncorrectable Error Status */
+			case 0x110: /* Correctable Error Status */
+			case 0x130: /* Error Status */
+			case 0x160: /* Link Control 4 */
+				w1c_bits = 0xffffffff;
+				break;
+			default:
+				break;
+
+			}
+			if (w1c_bits) {
+				mask &= w1c_bits;
+				val &= ~mask;
+			}
+		}
+
+		/*
+		 * Low order bits are the config address, the high
+		 * order 32 bits are the data to be written.
+		 */
+		write_val = where & ~3ull;
+		write_val |= (((u64)val) << 32);
+		writeq(write_val, pem_pci->pem_reg_base + PEM_CFG_WR);
+		return PCIBIOS_SUCCESSFUL;
+	}
+	if (bus->number < pci->cfg.bus_range->start ||
+	    bus->number > pci->cfg.bus_range->end)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	return pci_generic_config_write(bus, devfn, where, size, val);
+}
+
+static struct gen_pci_cfg_bus_ops thunder_pem_bus_ops = {
+	.bus_shift	= 24,
+	.ops		= {
+		.map_bus	= thunder_pem_map_bus,
+		.read		= thunder_pem_config_read,
+		.write		= thunder_pem_config_write,
+	}
+};
+
+static const struct of_device_id thunder_pem_of_match[] = {
+	{ .compatible = "cavium,pci-host-thunder-pem",
+	  .data = &thunder_pem_bus_ops },
+
+	{ },
+};
+MODULE_DEVICE_TABLE(of, thunder_pem_of_match);
+
+static int thunder_pem_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	const struct of_device_id *of_id;
+	resource_size_t bar4_start;
+	struct resource *res_pem;
+	struct thunder_pem_pci *pem_pci;
+
+	pem_pci = devm_kzalloc(dev, sizeof(*pem_pci), GFP_KERNEL);
+	if (!pem_pci)
+		return -ENOMEM;
+
+	of_id = of_match_node(thunder_pem_of_match, dev->of_node);
+	pem_pci->gen_pci.cfg.ops = (struct gen_pci_cfg_bus_ops *)of_id->data;
+
+	/*
+	 * The second register range is the PEM bridge to the PCIe
+	 * bus.  It has a different config access method than those
+	 * devices behind the bridge.
+	 */
+	res_pem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	if (!res_pem) {
+		dev_err(dev, "missing \"reg[1]\"property\n");
+		return -EINVAL;
+	}
+
+	pem_pci->pem_reg_base = devm_ioremap(dev, res_pem->start, 0x10000);
+	if (!pem_pci->pem_reg_base)
+		return -ENOMEM;
+
+	/*
+	 * The MSI-X BAR for the PEM and AER interrupts is located at
+	 * a fixed offset from the PEM register base.  Generate a
+	 * fragment of the synthesized Enhanced Allocation capability
+	 * structure here for the BAR.
+	 */
+	bar4_start = res_pem->start + 0xf00000;
+	pem_pci->ea_entry[0] = (u32)bar4_start | 2;
+	pem_pci->ea_entry[1] = (u32)(res_pem->end - bar4_start) & ~3u;
+	pem_pci->ea_entry[2] = (u32)(bar4_start >> 32);
+
+	return pci_host_common_probe(pdev, &pem_pci->gen_pci);
+}
+
+static struct platform_driver thunder_pem_driver = {
+	.driver = {
+		.name = KBUILD_MODNAME,
+		.of_match_table = thunder_pem_of_match,
+	},
+	.probe = thunder_pem_probe,
+};
+module_platform_driver(thunder_pem_driver);
+
+MODULE_DESCRIPTION("Thunder PEM PCIe host driver");
+MODULE_LICENSE("GPL v2");
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Fri Feb  5 15:41:15 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri,  5 Feb 2016 15:41:15 -0800
Subject: [PATCH v5 3/3] pci,
 pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices
In-Reply-To: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1454715675-17512-4-git-send-email-ddaney.cavm@gmail.com>

From: David Daney <david.daney at cavium.com>

The cavium,pci-thunder-ecam devices are exactly ECAM based PCI root
complexes.  These root complexes (loosely referred to as ECAM units in
the hardware manuals) are used to access the Thunder on-chips devices.
They are special in that all the BARs on devices behind these root
complexes are at fixed addresses.  To handle this in a manner
compatible with the core PCI code, we have the config access functions
synthesize Enhanced Allocation (EA) capability entries for each BAR.

Since this EA synthesis is needed for exactly one chip model, we can
hard code some assumptions about the device topology and the
properties of specific DEVFNs in the driver.

Signed-off-by: David Daney <david.daney at cavium.com>
---
 .../devicetree/bindings/pci/pci-thunder-ecam.txt   |  30 ++
 drivers/pci/host/Kconfig                           |   7 +
 drivers/pci/host/Makefile                          |   1 +
 drivers/pci/host/pci-thunder-ecam.c                | 358 +++++++++++++++++++++
 4 files changed, 396 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt
 create mode 100644 drivers/pci/host/pci-thunder-ecam.c

diff --git a/Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt b/Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt
new file mode 100644
index 0000000..34658f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt
@@ -0,0 +1,30 @@
+* ThunderX PCI host controller for pass-1.x silicon
+
+Firmware-initialized PCI host controller to on-chip devices found on
+some Cavium ThunderX processors.  These devices have ECAM based config
+access, but the BARs are all at fixed addresses.  We handle the fixed
+addresses by synthesizing Enhanced Allocation (EA) capabilities for
+these devices.
+
+The properties and their meanings are identical to those described in
+host-generic-pci.txt except as listed below.
+
+Properties of the host controller node that differ from
+host-generic-pci.txt:
+
+- compatible     : Must be "cavium,pci-host-thunder-ecam"
+
+Example:
+
+	pci at 84b0,00000000 {
+		compatible = "cavium,pci-host-thunder-ecam";
+		device_type = "pci";
+		msi-parent = <&its>;
+		msi-map = <0 &its 0x30000 0x10000>;
+		bus-range = <0 31>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		#stream-id-cells = <1>;
+		reg = <0x84b0 0x00000000 0 0x02000000>;  /* Configuration space */
+		ranges = <0x03000000 0x8180 0x00000000 0x8180 0x00000000 0x80 0x00000000>; /* mem ranges */
+	};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 184df22..f8912c6 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -202,4 +202,11 @@ config PCI_HOST_THUNDER_PEM
 	help
 	  Say Y here if you want PCIe support for CN88XX Cavium Thunder SoCs.
 
+config PCI_HOST_THUNDER_ECAM
+	bool "Cavium Thunder ECAMe controller to on-chip devices on pass-1.x silicon"
+	depends on OF && ARM64
+	select PCI_HOST_COMMON
+	help
+	  Say Y here if you want ECAM support for CN88XX-Pass-1.x Cavium Thunder SoCs.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 8903172..d6af3ba 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -23,4 +23,5 @@ obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
 obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
+obj-$(CONFIG_PCI_HOST_THUNDER_ECAM) += pci-thunder-ecam.o
 obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
diff --git a/drivers/pci/host/pci-thunder-ecam.c b/drivers/pci/host/pci-thunder-ecam.c
new file mode 100644
index 0000000..83ee590
--- /dev/null
+++ b/drivers/pci/host/pci-thunder-ecam.c
@@ -0,0 +1,358 @@
+/*
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2015 Cavium, Inc.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/ioport.h>
+#include <linux/of_pci.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#include "pci-host-common.h"
+
+/* Mapping is standard ECAM */
+static void __iomem *thunder_ecam_map_bus(struct pci_bus *bus,
+					  unsigned int devfn,
+					  int where)
+{
+	struct gen_pci *pci = bus->sysdata;
+	resource_size_t idx = bus->number - pci->cfg.bus_range->start;
+
+	return pci->cfg.win[idx] + ((devfn << 12) | where);
+}
+
+static void set_val(u32 v, int where, int size, u32 *val)
+{
+	int shift = (where & 3) * 8;
+
+	pr_debug("set_val %04x: %08x\n", (unsigned)(where & ~3), v);
+	v >>= shift;
+	if (size == 1)
+		v &= 0xff;
+	else if (size == 2)
+		v &= 0xffff;
+	*val = v;
+}
+
+static int handle_ea_bar(u32 e0, int bar, struct pci_bus *bus,
+			 unsigned int devfn, int where, int size, u32 *val)
+{
+	void __iomem *addr;
+	u32 v;
+	/*
+	 * Each entry is 16-byte aligned bits[2,3] select which word
+	 * in the entry
+	 */
+	int where_a = where & 0xc;
+
+	if (where_a == 0) {
+		set_val(e0, where, size, val);
+		return PCIBIOS_SUCCESSFUL;
+	}
+	if (where_a == 0x4) {
+		addr = bus->ops->map_bus(bus, devfn, bar); /* BAR 0 */
+		if (!addr) {
+			*val = ~0;
+			return PCIBIOS_DEVICE_NOT_FOUND;
+		}
+		v = readl(addr);
+		v &= ~0xf;
+		v |= 2; /* EA entry-1. Base-L */
+		set_val(v, where, size, val);
+		return PCIBIOS_SUCCESSFUL;
+	}
+	if (where_a == 0x8) {
+		u32 barl_orig;
+		u32 barl_rb;
+
+		addr = bus->ops->map_bus(bus, devfn, bar); /* BAR 0 */
+		if (!addr) {
+			*val = ~0;
+			return PCIBIOS_DEVICE_NOT_FOUND;
+		}
+		barl_orig = readl(addr + 0);
+		writel(0xffffffff, addr + 0);
+		barl_rb = readl(addr + 0);
+		writel(barl_orig, addr + 0);
+		/* zeros in unsettable bits. */
+		v = ~barl_rb & ~3;
+		v |= 0xc; /* EA entry-2. Offset-L */
+		set_val(v, where, size, val);
+		return PCIBIOS_SUCCESSFUL;
+	}
+	if (where_a == 0xc) {
+		addr = bus->ops->map_bus(bus, devfn, bar + 4); /* BAR 1 */
+		if (!addr) {
+			*val = ~0;
+			return PCIBIOS_DEVICE_NOT_FOUND;
+		}
+		v = readl(addr); /* EA entry-3. Base-H */
+		set_val(v, where, size, val);
+		return PCIBIOS_SUCCESSFUL;
+	}
+	return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
+static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
+				    int where, int size, u32 *val)
+{
+	u32 v;
+	u32 vendor_device;
+	void __iomem *addr;
+	int cfg_type;
+	int where_a = where & ~3;
+
+
+	addr = bus->ops->map_bus(bus, devfn, 0xc);
+	if (!addr) {
+		*val = ~0;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	v = readl(addr);
+
+	/* Check for non type-00 header. */
+	cfg_type = (v >> 16) & 0x7f;
+
+	/*
+	 * All BARs have fixed addresses specified by the EA
+	 * capability, they must return zero on read.
+	 */
+	if (cfg_type == 0 &&
+	    ((where >= 0x10 && where < 0x2c) ||
+	     (where >= 0x1a4 && where < 0x1bc))) {
+		/* BAR or SRIOV BAR */
+		*val = 0;
+		return PCIBIOS_SUCCESSFUL;
+	}
+
+	addr = bus->ops->map_bus(bus, devfn, 0);
+	if (!addr) {
+		*val = ~0;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	vendor_device = readl(addr);
+	if (vendor_device == 0xffffffff)
+		goto no_emulation;
+
+	addr = bus->ops->map_bus(bus, devfn, 8);
+	if (!addr) {
+		*val = ~0;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	v = readl(addr);
+	if (v == 0xffffffff)
+		goto no_emulation;
+
+	pr_debug("%04x:%04x - Fix pass#: %08x, where: %03x, devfn: %03x\n",
+		 vendor_device & 0xffff, vendor_device >> 16, v,
+		 (unsigned) where, devfn);
+
+	/* Check for non type-00 header. */
+	if (cfg_type == 0) {
+		bool has_msix;
+		bool is_nic = (vendor_device == 0xa01e177d);
+		bool is_tns = (vendor_device == 0xa01f177d);
+
+		addr = bus->ops->map_bus(bus, devfn, 0x70);
+		if (!addr) {
+			*val = ~0;
+			return PCIBIOS_DEVICE_NOT_FOUND;
+		}
+		/* E_CAP */
+		v = readl(addr);
+		has_msix = (v & 0xff00) != 0;
+
+		if (!has_msix && where_a == 0x70) {
+			v |= 0xbc00; /* next capability is EA at 0xbc */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xb0) {
+			addr = bus->ops->map_bus(bus, devfn, where_a);
+			if (!addr) {
+				*val = ~0;
+				return PCIBIOS_DEVICE_NOT_FOUND;
+			}
+			v = readl(addr);
+			if (v & 0xff00)
+				pr_err("Bad MSIX cap header: %08x\n", v);
+			v |= 0xbc00; /* next capability is EA at 0xbc */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xbc) {
+			if (is_nic)
+				v = 0x40014; /* EA last in chain, 4 entries. */
+			else if (is_tns)
+				v = 0x30014; /* EA last in chain, 3 entries. */
+			else if (has_msix)
+				v = 0x20014; /* EA last in chain, 2 entries. */
+			else
+				v = 0x10014; /* EA last in chain, 1 entry. */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a >= 0xc0 && where_a < 0xd0)
+			/* EA entry-0. PP=0, BAR0 Size:3 */
+			return handle_ea_bar(0x80ff0003,
+					     0x10, bus, devfn, where,
+					     size, val);
+		if (where_a >= 0xd0 && where_a < 0xe0 && has_msix)
+			 /* EA entry-1. PP=0, BAR4 Size:3 */
+			return handle_ea_bar(0x80ff0043,
+					     0x20, bus, devfn, where,
+					     size, val);
+		if (where_a >= 0xe0 && where_a < 0xf0 && is_tns)
+			/* EA entry-2. PP=0, BAR2, Size:3 */
+			return handle_ea_bar(0x80ff0023,
+					     0x18, bus, devfn, where,
+					     size, val);
+		if (where_a >= 0xe0 && where_a < 0xf0 && is_nic)
+			/* EA entry-2. PP=4, VF_BAR0 (9), Size:3 */
+			return handle_ea_bar(0x80ff0493,
+					     0x1a4, bus, devfn, where,
+					     size, val);
+		if (where_a >= 0xf0 && where_a < 0x100 && is_nic)
+			/* EA entry-3. PP=4, VF_BAR4 (d), Size:3 */
+			return handle_ea_bar(0x80ff04d3,
+					     0x1b4, bus, devfn, where,
+					     size, val);
+	} else if (cfg_type == 1) {
+		bool is_rsl_bridge = devfn == 0x08;
+		bool is_rad_bridge = devfn == 0xa0;
+		bool is_zip_bridge = devfn == 0xa8;
+		bool is_dfa_bridge = devfn == 0xb0;
+		bool is_nic_bridge = devfn == 0x10;
+
+		if (where_a == 0x70) {
+			addr = bus->ops->map_bus(bus, devfn, where_a);
+			if (!addr) {
+				*val = ~0;
+				return PCIBIOS_DEVICE_NOT_FOUND;
+			}
+			v = readl(addr);
+			if (v & 0xff00)
+				pr_err("Bad PCIe cap header: %08x\n", v);
+			v |= 0xbc00; /* next capability is EA at 0xbc */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xbc) {
+			if (is_nic_bridge)
+				v = 0x10014; /* EA last in chain, 1 entry */
+			else
+				v = 0x00014; /* EA last in chain, no entries */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xc0) {
+			if (is_rsl_bridge || is_nic_bridge)
+				v = 0x0101; /* subordinate:secondary = 1:1 */
+			else if (is_rad_bridge)
+				v = 0x0202; /* subordinate:secondary = 2:2 */
+			else if (is_zip_bridge)
+				v = 0x0303; /* subordinate:secondary = 3:3 */
+			else if (is_dfa_bridge)
+				v = 0x0404; /* subordinate:secondary = 4:4 */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xc4 && is_nic_bridge) {
+			/* Enabled, not-Write, SP=ff, PP=05, BEI=6, ES=4 */
+			v = 0x80ff0564;
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xc8 && is_nic_bridge) {
+			v = 0x00000002; /* Base-L 64-bit */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xcc && is_nic_bridge) {
+			v = 0xfffffffe; /* MaxOffset-L 64-bit */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xd0 && is_nic_bridge) {
+			v = 0x00008430; /* NIC Base-H */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xd4 && is_nic_bridge) {
+			v = 0x0000000f; /* MaxOffset-H */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+	}
+no_emulation:
+	return pci_generic_config_read(bus, devfn, where, size, val);
+}
+
+static int thunder_ecam_config_write(struct pci_bus *bus, unsigned int devfn,
+				     int where, int size, u32 val)
+{
+	/*
+	 * All BARs have fixed addresses, ignore BAR writes so they
+	 * don't get corrupted.
+	 */
+	if ((where >= 0x10 && where < 0x2c) ||
+	    (where >= 0x1a4 && where < 0x1bc))
+		/* BAR or SRIOV BAR */
+		return PCIBIOS_SUCCESSFUL;
+
+	return pci_generic_config_write(bus, devfn, where, size, val);
+}
+
+static struct gen_pci_cfg_bus_ops thunder_ecam_bus_ops = {
+	.bus_shift	= 20,
+	.ops		= {
+		.map_bus        = thunder_ecam_map_bus,
+		.read           = thunder_ecam_config_read,
+		.write          = thunder_ecam_config_write,
+	}
+};
+
+static const struct of_device_id thunder_ecam_of_match[] = {
+	{ .compatible = "cavium,pci-host-thunder-ecam",
+	  .data = &thunder_ecam_bus_ops },
+
+	{ },
+};
+MODULE_DEVICE_TABLE(of, thunder_ecam_of_match);
+
+static int thunder_ecam_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	const struct of_device_id *of_id;
+	struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
+
+	if (!pci)
+		return -ENOMEM;
+
+	of_id = of_match_node(thunder_ecam_of_match, dev->of_node);
+	pci->cfg.ops = (struct gen_pci_cfg_bus_ops *)of_id->data;
+
+	return pci_host_common_probe(pdev, pci);
+}
+
+static struct platform_driver thunder_ecam_driver = {
+	.driver = {
+		.name = KBUILD_MODNAME,
+		.of_match_table = thunder_ecam_of_match,
+	},
+	.probe = thunder_ecam_probe,
+};
+module_platform_driver(thunder_ecam_driver);
+
+MODULE_DESCRIPTION("Thunder ECAM PCI host driver");
+MODULE_LICENSE("GPL v2");
-- 
1.8.3.1



From linux at roeck-us.net  Fri Feb  5 15:54:37 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Fri, 5 Feb 2016 15:54:37 -0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <CADyBb7sP=d+BWOdmNEAs38yRcmXVjYsFX=XNffNpGqfybpxTfQ@mail.gmail.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
 <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
 <56B2DEE4.7060901@roeck-us.net>
 <CADyBb7unAHEOMfruWS82RkHK6uwPAWCxUx9jqzSkiHU4LHDSeA@mail.gmail.com>
 <56B4B4E2.40105@roeck-us.net>
 <CADyBb7sP=d+BWOdmNEAs38yRcmXVjYsFX=XNffNpGqfybpxTfQ@mail.gmail.com>
Message-ID: <56B5363D.20200@roeck-us.net>

On 02/05/2016 10:21 AM, Fu Wei wrote:
> On 5 February 2016 at 22:42, Guenter Roeck <linux at roeck-us.net> wrote:
>> On 02/05/2016 01:51 AM, Fu Wei wrote:
>>>
>>> Hi Guenter,
>>>
>>> On 4 February 2016 at 13:17, Guenter Roeck <linux at roeck-us.net> wrote:
>>>>
>>>> On 02/03/2016 03:00 PM, Fu Wei wrote:
>>>>>
>>>>>
>>>>> On 4 February 2016 at 02:45, Timur Tabi <timur at codeaurora.org> wrote:
>>>>>>
>>>>>>
>>>>>> Fu Wei wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As you know I have made the pre-timeout support patch, If people like
>>>>>>> it, i am happy to go on upstream it separately.
>>>>>>>
>>>>>>> If we want to use pre-timeout here, user only can use get_pretimeout
>>>>>>> and disable panic by setting pretimeout to 0
>>>>>>> but user can not really set pretimeout, because "pre-timeout  ==
>>>>>>> timeout / 2 (always)".
>>>>>>> if user want to change pretimeout, he/she has to set_time instead.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ok, I think patches 4 and 5 should be combined, and I think the Kconfig
>>>>>> entry should be removed and just use panic_enabled.
>>>>
>>>>
>>>>
>>>> Agreed.
>>>
>>>
>>> np, will do
>>>
>>>>>
>>>>>
>>>>> NP, will update this patchset like that ,  thanks :-)
>>>>>
>>>>
>>>> Also, if panic is enabled, the timeout needs to be adjusted accordingly
>>>> (to only panic after the entire timeout period has expired, not after
>>>> half of it). We can not panic the system after timeout / 2.
>>>
>>>
>>> OK, my thought is
>>>
>>> if panic is enabled :
>>> |--------WOR-------WS0--------WOR-------WS1
>>> |------timeout------(panic)------timeout-----reset
>>>
>>> if panic is disabled .
>>> |--------WOR-------WS0--------WOR-------WS1
>>> |---------------------timeout---------------------reset
>>>
>>>    panic_enabled only can be configured when module is loaded by module
>>> parameter
>>>
>>> But user should know that max_timeout(panic_enable) =
>>> max_timeout(panic_disable) / 2
>>>
>>
>> That means you'll have to update max_timeout accordingly.
>
> panic_enabled only can be configured when module is loaded, so we
> don't need to update it.
>
> max_timeout will only be set up in the init stage.
>
> Does it make sense ? :-)
>
Not sure I understand your problem or question.

max_timeout will have to reflect the correct maximum timeout, under
all circumstances. It will have to be set to the correct value before
the watchdog driver is registered.

Guenter



From labbott at redhat.com  Fri Feb  5 16:08:05 2016
From: labbott at redhat.com (Laura Abbott)
Date: Fri, 5 Feb 2016 16:08:05 -0800
Subject: [PATCHv2 2/3] arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
In-Reply-To: <20160205142029.GC19614@leverpostej>
References: <1454615017-24672-1-git-send-email-labbott@fedoraproject.org>
 <1454615017-24672-3-git-send-email-labbott@fedoraproject.org>
 <20160205142029.GC19614@leverpostej>
Message-ID: <56B53965.1080201@redhat.com>

On 02/05/2016 06:20 AM, Mark Rutland wrote:
> On Thu, Feb 04, 2016 at 11:43:36AM -0800, Laura Abbott wrote:
>>
>> ARCH_SUPPORTS_DEBUG_PAGEALLOC provides a hook to map and unmap
>> pages for debugging purposes. This requires memory be mapped
>> with PAGE_SIZE mappings since breaking down larger mappings
>> at runtime will lead to TLB conflicts. Check if debug_pagealloc
>> is enabled at runtime and if so, map everyting with PAGE_SIZE
>> pages. Implement the functions to actually map/unmap the
>> pages at runtime.
>>
>> Signed-off-by: Laura Abbott <labbott at fedoraproject.org>
>
> I've given this a spin on Juno, with and without the config option
> selected, and with and without the command line option. I've also given
> it a spin on Seattle with inline KASAN also enabled.
>
> I wasn't sure how to deliberately trigger a failure, but those all
> booted fine, and the dumepd page tables looks right, so FWIW:
>

I wrote a test that does a write after free on an allocated page
for my testing. Might be worth it to look into adding a test to
the lkdtm module.

I also did testing with 64K pages but couldn't test on 16K due
to lack of hardware and QEMU running off into the weeds.
  
> Tested-by: Mark Rutland <mark.rutland at arm.com>
>
> I have a few minor comments below, and with those fixed up:
>
> Reviewed-by: Mark Rutland <mark.rutland at arm.com>
>
>> ---
>>   arch/arm64/Kconfig       |  3 +++
>>   arch/arm64/mm/mmu.c      | 25 +++++++++++++++++++++----
>>   arch/arm64/mm/pageattr.c | 46 ++++++++++++++++++++++++++++++++++++----------
>>   3 files changed, 60 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 8cc6228..0f33218 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -537,6 +537,9 @@ config HOTPLUG_CPU
>>   source kernel/Kconfig.preempt
>>   source kernel/Kconfig.hz
>>
>> +config ARCH_SUPPORTS_DEBUG_PAGEALLOC
>> +	def_bool y
>> +
>>   config ARCH_HAS_HOLES_MEMORYMODEL
>>   	def_bool y if SPARSEMEM
>>
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index ef0d66c..be81a59 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -180,8 +180,14 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
>>   	pmd = pmd_set_fixmap_offset(pud, addr);
>>   	do {
>>   		next = pmd_addr_end(addr, end);
>> -		/* try section mapping first */
>> -		if (((addr | next | phys) & ~SECTION_MASK) == 0) {
>> +		/*
>> +		 * try a section mapping first
>> +		 *
>> +		 * See comment in use_1G_block for why we need the check
>> +		 * for !pgtable_alloc with !debug_pagealloc
>> +		 */
>> +		if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
>> +		      (!debug_pagealloc_enabled() || !pgtable_alloc)) {
>>   			pmd_t old_pmd =*pmd;
>>   			set_pmd(pmd, __pmd(phys |
>>   					   pgprot_val(mk_sect_prot(prot))));
>> @@ -208,8 +214,19 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
>>   }
>>
>>   static inline bool use_1G_block(unsigned long addr, unsigned long next,
>> -			unsigned long phys)
>> +			unsigned long phys, phys_addr_t (*pgtable_alloc)(void))
>>   {
>> +	/*
>> +	 * If debug_page_alloc is enabled we don't want to be using sections
>> +	 * since everything needs to be mapped with pages. The catch is
>> +	 * that we only want to force pages if we can allocate the next
>> +	 * layer of page tables. If there is no pgtable_alloc function,
>> +	 * it's too early to allocate another layer and we should use
>> +	 * section mappings.
>> +	 */
>
> I'm not sure this quite captures the rationale, as we only care about
> the linear map using pages (AFAIK), and the earliness only matters
> w.r.t. the DTB mapping. How about:
>
> 	/*
> 	 * If debug_page_alloc is enabled we must map the linear map
> 	 * using pages. However, other mappings created by
> 	 * create_mapping_noalloc must use sections in some cases. Allow
> 	 * sections to be used in those cases, where no pgtable_alloc
> 	 * function is provided.
> 	 */
>
> Does that sound ok to you?
>
> As a future optimisation, I think we can allow sections when mapping
> permanent kernel chunks (.e.g .rodata and .text), as these shouldn't
> contain pages available for dynamic allocation. That would require using
> something other than the presence of pgtable_alloc to determine when we
> should force page usage.
>
>> +	if (pgtable_alloc && debug_pagealloc_enabled())
>> +		return false;
>> +
>>   	if (PAGE_SHIFT != 12)
>>   		return false;
>>
>> @@ -241,7 +258,7 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
>>   		/*
>>   		 * For 4K granule only, attempt to put down a 1GB block
>>   		 */
>> -		if (use_1G_block(addr, next, phys)) {
>> +		if (use_1G_block(addr, next, phys, pgtable_alloc)) {
>>   			pud_t old_pud = *pud;
>>   			set_pud(pud, __pud(phys |
>>   					   pgprot_val(mk_sect_prot(prot))));
>> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
>> index 1360a02..57877af 100644
>> --- a/arch/arm64/mm/pageattr.c
>> +++ b/arch/arm64/mm/pageattr.c
>> @@ -37,14 +37,31 @@ static int change_page_range(pte_t *ptep, pgtable_t token, unsigned long addr,
>>   	return 0;
>>   }
>>
>> +/*
>> + * This function assumes that the range is mapped with PAGE_SIZE pages.
>> + */
>> +static int __change_memory_common(unsigned long start, unsigned long size,
>> +				pgprot_t set_mask, pgprot_t clear_mask)
>> +{
>> +	struct page_change_data data;
>> +	int ret;
>> +
>> +	data.set_mask = set_mask;
>> +	data.clear_mask = clear_mask;
>> +
>> +	ret = apply_to_page_range(&init_mm, start, size, change_page_range,
>> +					&data);
>> +
>> +	flush_tlb_kernel_range(start, start+size);
>
> Nit: spaces around '+' please.
>
>> +	return ret;
>> +}
>> +
>>   static int change_memory_common(unsigned long addr, int numpages,
>>   				pgprot_t set_mask, pgprot_t clear_mask)
>>   {
>>   	unsigned long start = addr;
>>   	unsigned long size = PAGE_SIZE*numpages;
>>   	unsigned long end = start + size;
>> -	int ret;
>> -	struct page_change_data data;
>>   	struct vm_struct *area;
>>
>>   	if (!PAGE_ALIGNED(addr)) {
>> @@ -72,14 +89,7 @@ static int change_memory_common(unsigned long addr, int numpages,
>>   	    !(area->flags & VM_ALLOC))
>>   		return -EINVAL;
>>
>> -	data.set_mask = set_mask;
>> -	data.clear_mask = clear_mask;
>> -
>> -	ret = apply_to_page_range(&init_mm, start, size, change_page_range,
>> -					&data);
>> -
>> -	flush_tlb_kernel_range(start, end);
>> -	return ret;
>> +	return __change_memory_common(start, size, set_mask, clear_mask);
>>   }
>>
>>   int set_memory_ro(unsigned long addr, int numpages)
>> @@ -111,3 +121,19 @@ int set_memory_x(unsigned long addr, int numpages)
>>   					__pgprot(PTE_PXN));
>>   }
>>   EXPORT_SYMBOL_GPL(set_memory_x);
>> +
>> +#ifdef CONFIG_DEBUG_PAGEALLOC
>> +void __kernel_map_pages(struct page *page, int numpages, int enable)
>> +{
>> +	unsigned long addr = (unsigned long) page_address(page);
>> +
>> +	if (enable)
>> +		__change_memory_common(addr, PAGE_SIZE*numpages,
>> +					__pgprot(PTE_VALID),
>> +					__pgprot(0));
>> +	else
>> +		__change_memory_common(addr, PAGE_SIZE*numpages,
>> +					__pgprot(0),
>> +					__pgprot(PTE_VALID));
>
> Nit: spaces around each '*' here, please.
>
> Thanks,
> Mark.
>
>> +}
>> +#endif
>> --
>> 2.5.0
>>



From yang.shi at linaro.org  Fri Feb  5 15:50:18 2016
From: yang.shi at linaro.org (Yang Shi)
Date: Fri,  5 Feb 2016 15:50:18 -0800
Subject: [PATCH] arm64: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL
Message-ID: <1454716218-4918-1-git-send-email-yang.shi@linaro.org>

To enable UBSAN on arm64, ARCH_HAS_UBSAN_SANITIZE_ALL need to be selected.

Basic kernel bootup test is passed on arm64 with CONFIG_UBSAN_SANITIZE_ALL
enabled.

Signed-off-by: Yang Shi <yang.shi at linaro.org>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc6228..1c29e20 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -14,6 +14,7 @@ config ARM64
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
 	select ARCH_WANT_FRAME_POINTERS
+	select ARCH_HAS_UBSAN_SANITIZE_ALL
 	select ARM_AMBA
 	select ARM_ARCH_TIMER
 	select ARM_GIC
-- 
2.0.2



From labbott at fedoraproject.org  Fri Feb  5 16:24:45 2016
From: labbott at fedoraproject.org (Laura Abbott)
Date: Fri,  5 Feb 2016 16:24:45 -0800
Subject: [PATCHv4 0/3] ARCH_SUPPORTS_DEBUG_PAGEALLOC for arm64
Message-ID: <1454718288-31374-1-git-send-email-labbott@fedoraproject.org>

Hi,

This is hopefully the last update to add proper ARCH_SUPPORTS_DEBUG_PAGEALLOC
support for arm64.

Changes since v3:
- More acks
- Pulled out block check into a separate function
- Style fixups
- Comment tweaking

Laura Abbott (3):
  arm64: Drop alloc function from create_mapping
  arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
  arm64: ptdump: Indicate whether memory should be faulting

 arch/arm64/Kconfig       |  3 +++
 arch/arm64/mm/dump.c     |  5 +++++
 arch/arm64/mm/mmu.c      | 48 +++++++++++++++++++++++++++++++++++++-----------
 arch/arm64/mm/pageattr.c | 46 ++++++++++++++++++++++++++++++++++++----------
 4 files changed, 81 insertions(+), 21 deletions(-)

-- 
2.5.0



From labbott at fedoraproject.org  Fri Feb  5 16:24:48 2016
From: labbott at fedoraproject.org (Laura Abbott)
Date: Fri,  5 Feb 2016 16:24:48 -0800
Subject: [PATCHv4 3/3] arm64: ptdump: Indicate whether memory should be
 faulting
In-Reply-To: <1454718288-31374-1-git-send-email-labbott@fedoraproject.org>
References: <1454718288-31374-1-git-send-email-labbott@fedoraproject.org>
Message-ID: <1454718288-31374-4-git-send-email-labbott@fedoraproject.org>



With CONFIG_DEBUG_PAGEALLOC, pages do not have the valid bit
set when free in the buddy allocator. Add an indiciation to
the page table dumping code that the valid bit is not set,
'F' for fault, to make this easier to understand.

Reviewed-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Reviewed-by: Mark Rutland <mark.rutland at arm.com>
Tested-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Laura Abbott <labbott at fedoraproject.org>
---
 arch/arm64/mm/dump.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index 5a22a11..f381ac9 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -90,6 +90,11 @@ struct prot_bits {
 
 static const struct prot_bits pte_bits[] = {
 	{
+		.mask	= PTE_VALID,
+		.val	= PTE_VALID,
+		.set	= " ",
+		.clear	= "F",
+	}, {
 		.mask	= PTE_USER,
 		.val	= PTE_USER,
 		.set	= "USR",
-- 
2.5.0



From labbott at fedoraproject.org  Fri Feb  5 16:24:47 2016
From: labbott at fedoraproject.org (Laura Abbott)
Date: Fri,  5 Feb 2016 16:24:47 -0800
Subject: [PATCHv4 2/3] arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
In-Reply-To: <1454718288-31374-1-git-send-email-labbott@fedoraproject.org>
References: <1454718288-31374-1-git-send-email-labbott@fedoraproject.org>
Message-ID: <1454718288-31374-3-git-send-email-labbott@fedoraproject.org>



ARCH_SUPPORTS_DEBUG_PAGEALLOC provides a hook to map and unmap
pages for debugging purposes. This requires memory be mapped
with PAGE_SIZE mappings since breaking down larger mappings
at runtime will lead to TLB conflicts. Check if debug_pagealloc
is enabled at runtime and if so, map everyting with PAGE_SIZE
pages. Implement the functions to actually map/unmap the
pages at runtime.

Reviewed-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Reviewed-by: Mark Rutland <mark.rutland at arm.com>
Tested-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Laura Abbott <labbott at fedoraproject.org>
---
 arch/arm64/Kconfig       |  3 +++
 arch/arm64/mm/mmu.c      | 19 +++++++++++++++++--
 arch/arm64/mm/pageattr.c | 46 ++++++++++++++++++++++++++++++++++++----------
 3 files changed, 56 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc6228..0f33218 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -537,6 +537,9 @@ config HOTPLUG_CPU
 source kernel/Kconfig.preempt
 source kernel/Kconfig.hz
 
+config ARCH_SUPPORTS_DEBUG_PAGEALLOC
+	def_bool y
+
 config ARCH_HAS_HOLES_MEMORYMODEL
 	def_bool y if SPARSEMEM
 
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index ef0d66c..29dcc83 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -149,6 +149,19 @@ static void split_pud(pud_t *old_pud, pmd_t *pmd)
 	} while (pmd++, i++, i < PTRS_PER_PMD);
 }
 
+bool block_mappings_allowed(phys_addr_t (*pgtable_alloc)(void))
+{
+
+	/*
+	 * If debug_page_alloc is enabled we must map the linear map
+	 * using pages. However, other mappings created by
+	 * create_mapping_noalloc must use sections in some cases. Allow
+	 * sections to be used in those cases, where no pgtable_alloc
+	 * function is provided.
+	 */
+	return !pgtable_alloc || !debug_pagealloc_enabled();
+}
+
 static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
 				  phys_addr_t phys, pgprot_t prot,
 				  phys_addr_t (*pgtable_alloc)(void))
@@ -181,7 +194,8 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
 	do {
 		next = pmd_addr_end(addr, end);
 		/* try section mapping first */
-		if (((addr | next | phys) & ~SECTION_MASK) == 0) {
+		if (((addr | next | phys) & ~SECTION_MASK) == 0 &&
+		      block_mappings_allowed(pgtable_alloc)) {
 			pmd_t old_pmd =*pmd;
 			set_pmd(pmd, __pmd(phys |
 					   pgprot_val(mk_sect_prot(prot))));
@@ -241,7 +255,8 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
 		/*
 		 * For 4K granule only, attempt to put down a 1GB block
 		 */
-		if (use_1G_block(addr, next, phys)) {
+		if (use_1G_block(addr, next, phys) &&
+		    block_mappings_allowed(pgtable_alloc)) {
 			pud_t old_pud = *pud;
 			set_pud(pud, __pud(phys |
 					   pgprot_val(mk_sect_prot(prot))));
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index 1360a02..7ba87c4 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -37,14 +37,31 @@ static int change_page_range(pte_t *ptep, pgtable_t token, unsigned long addr,
 	return 0;
 }
 
+/*
+ * This function assumes that the range is mapped with PAGE_SIZE pages.
+ */
+static int __change_memory_common(unsigned long start, unsigned long size,
+				pgprot_t set_mask, pgprot_t clear_mask)
+{
+	struct page_change_data data;
+	int ret;
+
+	data.set_mask = set_mask;
+	data.clear_mask = clear_mask;
+
+	ret = apply_to_page_range(&init_mm, start, size, change_page_range,
+					&data);
+
+	flush_tlb_kernel_range(start, start + size);
+	return ret;
+}
+
 static int change_memory_common(unsigned long addr, int numpages,
 				pgprot_t set_mask, pgprot_t clear_mask)
 {
 	unsigned long start = addr;
 	unsigned long size = PAGE_SIZE*numpages;
 	unsigned long end = start + size;
-	int ret;
-	struct page_change_data data;
 	struct vm_struct *area;
 
 	if (!PAGE_ALIGNED(addr)) {
@@ -72,14 +89,7 @@ static int change_memory_common(unsigned long addr, int numpages,
 	    !(area->flags & VM_ALLOC))
 		return -EINVAL;
 
-	data.set_mask = set_mask;
-	data.clear_mask = clear_mask;
-
-	ret = apply_to_page_range(&init_mm, start, size, change_page_range,
-					&data);
-
-	flush_tlb_kernel_range(start, end);
-	return ret;
+	return __change_memory_common(start, size, set_mask, clear_mask);
 }
 
 int set_memory_ro(unsigned long addr, int numpages)
@@ -111,3 +121,19 @@ int set_memory_x(unsigned long addr, int numpages)
 					__pgprot(PTE_PXN));
 }
 EXPORT_SYMBOL_GPL(set_memory_x);
+
+#ifdef CONFIG_DEBUG_PAGEALLOC
+void __kernel_map_pages(struct page *page, int numpages, int enable)
+{
+	unsigned long addr = (unsigned long) page_address(page);
+
+	if (enable)
+		__change_memory_common(addr, PAGE_SIZE * numpages,
+					__pgprot(PTE_VALID),
+					__pgprot(0));
+	else
+		__change_memory_common(addr, PAGE_SIZE * numpages,
+					__pgprot(0),
+					__pgprot(PTE_VALID));
+}
+#endif
-- 
2.5.0



From labbott at fedoraproject.org  Fri Feb  5 16:24:46 2016
From: labbott at fedoraproject.org (Laura Abbott)
Date: Fri,  5 Feb 2016 16:24:46 -0800
Subject: [PATCHv4 1/3] arm64: Drop alloc function from create_mapping
In-Reply-To: <1454718288-31374-1-git-send-email-labbott@fedoraproject.org>
References: <1454718288-31374-1-git-send-email-labbott@fedoraproject.org>
Message-ID: <1454718288-31374-2-git-send-email-labbott@fedoraproject.org>



create_mapping is only used in fixmap_remap_fdt. All the create_mapping
calls need to happen on existing translation table pages without
additional allocations. Rather than have an alloc function be called
and fail, just set it to NULL and catch its use. Also change
the name to create_mapping_noalloc to better capture what exactly is
going on.

Reviewed-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Reviewed-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Laura Abbott <labbott at fedoraproject.org>
---
 arch/arm64/mm/mmu.c | 29 ++++++++++++++++++++---------
 1 file changed, 20 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 7711554..ef0d66c 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -116,7 +116,9 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
 	pte_t *pte;
 
 	if (pmd_none(*pmd) || pmd_sect(*pmd)) {
-		phys_addr_t pte_phys = pgtable_alloc();
+		phys_addr_t pte_phys;
+		BUG_ON(!pgtable_alloc);
+		pte_phys = pgtable_alloc();
 		pte = pte_set_fixmap(pte_phys);
 		if (pmd_sect(*pmd))
 			split_pmd(pmd, pte);
@@ -158,7 +160,9 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
 	 * Check for initial section mappings in the pgd/pud and remove them.
 	 */
 	if (pud_none(*pud) || pud_sect(*pud)) {
-		phys_addr_t pmd_phys = pgtable_alloc();
+		phys_addr_t pmd_phys;
+		BUG_ON(!pgtable_alloc);
+		pmd_phys = pgtable_alloc();
 		pmd = pmd_set_fixmap(pmd_phys);
 		if (pud_sect(*pud)) {
 			/*
@@ -223,7 +227,9 @@ static void alloc_init_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
 	unsigned long next;
 
 	if (pgd_none(*pgd)) {
-		phys_addr_t pud_phys = pgtable_alloc();
+		phys_addr_t pud_phys;
+		BUG_ON(!pgtable_alloc);
+		pud_phys = pgtable_alloc();
 		__pgd_populate(pgd, pud_phys, PUD_TYPE_TABLE);
 	}
 	BUG_ON(pgd_bad(*pgd));
@@ -312,7 +318,12 @@ static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
 	init_pgd(pgd_offset_raw(pgdir, virt), phys, virt, size, prot, alloc);
 }
 
-static void __init create_mapping(phys_addr_t phys, unsigned long virt,
+/*
+ * This function can only be used to modify existing table entries,
+ * without allocating new levels of table. Note that this permits the
+ * creation of new section or page entries.
+ */
+static void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
 				  phys_addr_t size, pgprot_t prot)
 {
 	if (virt < VMALLOC_START) {
@@ -321,7 +332,7 @@ static void __init create_mapping(phys_addr_t phys, unsigned long virt,
 		return;
 	}
 	__create_pgd_mapping(init_mm.pgd, phys, virt, size, prot,
-			     early_pgtable_alloc);
+			     NULL);
 }
 
 void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
@@ -680,7 +691,7 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
 	/*
 	 * Make sure that the FDT region can be mapped without the need to
 	 * allocate additional translation table pages, so that it is safe
-	 * to call create_mapping() this early.
+	 * to call create_mapping_noalloc() this early.
 	 *
 	 * On 64k pages, the FDT will be mapped using PTEs, so we need to
 	 * be in the same PMD as the rest of the fixmap.
@@ -696,8 +707,8 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
 	dt_virt = (void *)dt_virt_base + offset;
 
 	/* map the first chunk so we can read the size from the header */
-	create_mapping(round_down(dt_phys, SWAPPER_BLOCK_SIZE), dt_virt_base,
-		       SWAPPER_BLOCK_SIZE, prot);
+	create_mapping_noalloc(round_down(dt_phys, SWAPPER_BLOCK_SIZE),
+			dt_virt_base, SWAPPER_BLOCK_SIZE, prot);
 
 	if (fdt_check_header(dt_virt) != 0)
 		return NULL;
@@ -707,7 +718,7 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
 		return NULL;
 
 	if (offset + size > SWAPPER_BLOCK_SIZE)
-		create_mapping(round_down(dt_phys, SWAPPER_BLOCK_SIZE), dt_virt_base,
+		create_mapping_noalloc(round_down(dt_phys, SWAPPER_BLOCK_SIZE), dt_virt_base,
 			       round_up(offset + size, SWAPPER_BLOCK_SIZE), prot);
 
 	memblock_reserve(dt_phys, size);
-- 
2.5.0



From stillcompiling at gmail.com  Fri Feb  5 17:03:47 2016
From: stillcompiling at gmail.com (Joshua Clayton)
Date: Fri, 5 Feb 2016 17:03:47 -0800
Subject: [PATCH net-next V2 7/8] net: fec: don't transfer ownership
 until descriptor write is complete
In-Reply-To: <1454709170-19527-8-git-send-email-troy.kisky@boundarydevices.com>
References: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
 <1454709170-19527-8-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <20160205170347.45a91314@jclayton-pc>

On Fri,  5 Feb 2016 14:52:49 -0700
Troy Kisky <troy.kisky at boundarydevices.com> wrote:

> If you don't own it, you shouldn't write to it.
> 
> Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
> ---
>  drivers/net/ethernet/freescale/fec_main.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c index ca2708d..97ca72a
> 100644 --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -390,6 +390,10 @@ fec_enet_txq_submit_frag_skb(struct
> fec_enet_priv_tx_q *txq, 
>  		bdp->cbd_bufaddr = cpu_to_fec32(addr);
>  		bdp->cbd_datlen = cpu_to_fec16(frag_len);
> +		/* Make sure the updates to rest of the descriptor
> are
> +		 * performed before transferring ownership.
> +		 */
> +		wmb();
>  		bdp->cbd_sc = cpu_to_fec16(status);
You use almost exactly the same code in each place.
I'd prefer to have wmb(); bdp->cbd_sc = cpu_to_fec16(status) wrapped in
a function or function like macro, and put the comment in one place.

e.g.

/* Make sure the updates to rest of the descriptor
 * performed before transferring ownership.
 */
#define fec_enet_xfr_ownership(status) \
	do { \
		wmb();
		bdp->cbd_sc = cpu_to_fec16(status);
	} while (0)

(I don't know if thats the right macro name, I'm just basing it off
your comment)

>  	}
>  
> @@ -499,6 +503,10 @@ static int fec_enet_txq_submit_skb(struct
> fec_enet_priv_tx_q *txq, 
>  	bdp->cbd_datlen = cpu_to_fec16(buflen);
>  	bdp->cbd_bufaddr = cpu_to_fec32(addr);
> +	/* Make sure the updates to rest of the descriptor are
> performed before
> +	 * transferring ownership.
> +	 */
> +	wmb();
>  
>  	/* Send it on its way.  Tell FEC it's ready, interrupt when
> done,
>  	 * it's the last BD of the frame, and to put the CRC on the
> end. @@ -1475,7 +1483,6 @@ rx_processing_done:
>  
>  		/* Mark the buffer empty */
>  		status |= BD_ENET_RX_EMPTY;
> -		bdp->cbd_sc = cpu_to_fec16(status);
>  
>  		if (fep->bufdesc_ex) {
>  			struct bufdesc_ex *ebdp = (struct bufdesc_ex
> *)bdp; @@ -1484,6 +1491,11 @@ rx_processing_done:
>  			ebdp->cbd_prot = 0;
>  			ebdp->cbd_bdu = 0;
>  		}
> +		/* Make sure the updates to rest of the descriptor
> are
> +		 * performed before transferring ownership.
> +		 */
> +		wmb();
> +		bdp->cbd_sc = cpu_to_fec16(status);
>  
>  		/* Update BD pointer to next entry */
>  		bdp = fec_enet_get_nextdesc(bdp, &rxq->bd);



From xinliang.liu at linaro.org  Fri Feb  5 19:24:47 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Sat,  6 Feb 2016 11:24:47 +0800
Subject: [PATCH v4 00/11] Add DRM Driver for HiSilicon Kirin hi6220 SoC
Message-ID: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>

This patch set adds a new drm driver for HiSilicon Kirin hi6220 SoC.
Current testing and support board is Hikey board which is one of Linaro
96boards. It is an arm64 open source board. For more information about
this board, please access https://www.96boards.org.

Hardware Detail
---------------
  The display subsystem of Hi6220 SoC is shown as bellow:
 +-----+       +----------+     +-----+     +-------------+
 |     |       |          |     |     |     |             |             	
 | FB  |------>|   ADE    |---->| DSI |---->|   External  |
 |     |       |          |     |     |     |  HDMI/panel |
 +-----+       +----------+     +-----+     +-------------+

- ADE(Advanced Display Engine) is the display controller. It contains 7
channels, 3 overlay compositors and a LDI.
  - A channel looks like: DMA-->clip-->scale-->ctrans(or called csc).
  - Overlay compositor is response to compose planes which come from 7
  channels and pass composed image to LDI.
  - LDI is response to generate timings and RGB data stream.
- DSI converts the RGB data stream from ADE to DSI packets.
- External HDMI/panel module is connected with DSI bus. Now Hikey use a
  ADI's ADV7533 external HDMI chip.

Change History
-------------
Changes in v4:
- Describe more specific of clocks and ports of binding docs.
- Fix indentation of binding docs.

Changes in v3:
- Move and rename all the files to kirin sub-directory.
  So that we could separate different seires SoCs' driver.
- Make ade as the drm master node.
- Replace drm_platform_init, load, unload implementation.
- Use assigned-clocks to set clock rate.
- Use ports to connect display relavant nodes.
- Rename hisi_drm_dsi.c to dw_drm_dsi.c
- Make encoder type as DRM_MODE_ENCODER_DSI.
- A few cleanup on regs and code.

Changes in v2:
- Remove abtraction layer of plane/crtc/encoder/connector.
- Refactor atomic implementation according to Daniel Vetter's guides:
http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html
http://blog.ffwll.ch/2015/09/xdc-2015-atomic-modesetting-for-drivers.html
http://blog.ffwll.ch/2015/08/atomic-modesetting-design-overview.html
- Use bridge instead of slave encoder to connect external HDMI.
- Move dt binding docs to bindings/display/hisilicon directory. 

Xinliang Liu (11):
  drm/hisilicon: Add device tree binding for hi6220 display subsystem
  drm/hisilicon: Add hisilicon kirin drm master driver
  drm/hisilicon: Add crtc driver for ADE
  drm/hisilicon: Add plane driver for ADE
  drm/hisilicon: Add vblank driver for ADE
  drm/hisilicon: Add cma fbdev and hotplug
  drm/hisilicon: Add designware dsi encoder driver
  drm/hisilicon: Add designware dsi host driver
  drm/hisilicon: Add support for external bridge
  MAINTAINERS: Add maintainer for hisilicon DRM driver
  arm64: dts: hisilicon: Add display subsystem DT nodes for hi6220

 .../bindings/display/hisilicon/dw-dsi.txt          |   77 ++
 .../bindings/display/hisilicon/hisi-ade.txt        |   69 ++
 MAINTAINERS                                        |   10 +
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts     |   44 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi          |   53 +
 drivers/gpu/drm/Kconfig                            |    2 +
 drivers/gpu/drm/Makefile                           |    1 +
 drivers/gpu/drm/hisilicon/Kconfig                  |    5 +
 drivers/gpu/drm/hisilicon/Makefile                 |    5 +
 drivers/gpu/drm/hisilicon/kirin/Kconfig            |   10 +
 drivers/gpu/drm/hisilicon/kirin/Makefile           |    5 +
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c       |  845 ++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h       |   83 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h    |  280 ++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c    | 1053 ++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c    |  382 +++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h    |   31 +
 17 files changed, 2955 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
 create mode 100644 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h

-- 
1.9.1



From xinliang.liu at linaro.org  Fri Feb  5 19:24:48 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Sat,  6 Feb 2016 11:24:48 +0800
Subject: [PATCH v4 01/11] drm/hisilicon: Add device tree binding for hi6220
 display subsystem
In-Reply-To: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1454729098-79807-2-git-send-email-xinliang.liu@linaro.org>

Add ADE display controller binding doc.
Add DesignWare DSI Host Controller v1.20a binding doc.

v4:
- Describe more specific of clocks and ports.
- Fix indentation.
v3:
- Make ade as the drm master node.
- Use assigned-clocks to set clock rate.
- Use ports to connect display relavant nodes.
v2:
- Move dt binding docs to bindings/display/hisilicon directory.

Signed-off-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 .../bindings/display/hisilicon/dw-dsi.txt          | 77 ++++++++++++++++++++++
 .../bindings/display/hisilicon/hisi-ade.txt        | 69 +++++++++++++++++++
 2 files changed, 146 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
 create mode 100644 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt

diff --git a/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
new file mode 100644
index 000000000000..af6d702f3282
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
@@ -0,0 +1,77 @@
+Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
+
+A DSI Host Controller resides in the middle of display controller and external
+HDMI converter.
+
+Required properties:
+- compatible: value should be "hisilicon,hi6220-dsi".
+- reg: physical base address and length of dsi controller's registers.
+- clocks: the clocks needed.
+- clock-names: the name of the clocks.
+- ports: contains DSI controller input and output sub port.
+  The input port connects to ADE output port with the reg value "0".
+  The output port with the reg value "1", it could connect to panel or
+  any other bridge endpoints. And the reg value for bridge endpoint is "0",
+  other values for panel endpoint.
+  See Documentation/devicetree/bindings/graph.txt for more device graph info.
+
+A example of HiKey board hi6220 SoC and board specific DT entry:
+Example:
+
+SoC specific:
+	dsi: dsi at f4107800 {
+		compatible = "hisilicon,hi6220-dsi";
+		reg = <0x0 0xf4107800 0x0 0x100>;
+		clocks = <&media_ctrl  HI6220_DSI_PCLK>;
+		clock-names = "pclk_dsi";
+		status = "disabled";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			/* 0 for input port */
+			port at 0 {
+				reg = <0>;
+				dsi_in: endpoint {
+					remote-endpoint = <&ade_out>;
+				};
+			};
+		};
+	};
+
+
+Board specific:
+	&dsi {
+		status = "ok";
+
+		ports {
+			/* 1 for output port */
+			port at 1 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <1>;
+
+				/* 0 for bridge, other value for panel */
+				dsi_out0: endpoint at 0 {
+					reg = <0>;
+					remote-endpoint = <&adv7533_in>;
+				};
+			};
+		};
+	};
+
+	&i2c2 {
+		...
+
+		adv7533: adv7533 at 39 {
+			...
+
+			port {
+				adv7533_in: endpoint {
+					remote-endpoint = <&dsi_out0>;
+				};
+			};
+		};
+	};
+
diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
new file mode 100644
index 000000000000..1eff5a41b98d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
@@ -0,0 +1,69 @@
+Device-Tree bindings for hisilicon ADE display controller driver
+
+ADE (Advanced Display Engine) is the display controller which grab image
+data from memory, do composition, do post image processing, generate RGB
+timing stream and transfer to DSI.
+
+Required properties:
+- compatible: value should be "hisilicon,hi6220-ade".
+- reg: physical base address and length of the controller's registers.
+  Three reg ranges are used in ADE driver:
+  ADE reg range, value should be "<0x0 0xf4100000 0x0 0x7800>";
+  media subsystem reg range, value should be "<0x0 0xf4410000 0x0 0x1000>";
+  media subsystem NOC QoS reg range, value should be "<0x0 0xf4520000 0x0
+  0x1000>".
+- reg-names: name of physical base.Valuse should be "ade_base",	"media_base"
+  and "media_noc_base".
+- interrupt: the ldi vblank interrupt number used.
+- clocks: the clocks needed. Three clocks are used in ADE driver:
+  ADE core clock, value should be "<&media_ctrl HI6220_ADE_CORE>";
+  ADE pixel clok, value should be "<&media_ctrl HI6220_ADE_PIX_SRC>";
+  media NOC QoS clock, value should be "<&media_ctrl HI6220_CODEC_JPEG>".
+- clock-names: the name of the clocks. Values should be "clk_ade_core",
+  "clk_codec_jpeg" and "clk_ade_pix".
+- assigned-clocks: clocks to be assigned rate.
+- assigned-clock-rates: clock rates which are assigned to assigned-clocks.
+  The rate of <&media_ctrl HI6220_ADE_CORE> could be "360000000" or
+  "180000000";
+  The rate of <&media_ctrl HI6220_CODEC_JPEG> could be less than "1440000000".
+- port: the output port. This contains one endpoint subnode, with its
+  remote-endpoint set to the phandle of the connected DSI input endpoint.
+  See Documentation/devicetree/bindings/graph.txt for more device graph info.
+
+Optional properties:
+- dma-coherent: Present if dma operations are coherent.
+
+
+A example of HiKey board hi6220 SoC specific DT entry:
+Example:
+
+	ade: ade at f4100000 {
+		compatible = "hisilicon,hi6220-ade";
+		reg = <0x0 0xf4100000 0x0 0x7800>,
+		      <0x0 0xf4410000 0x0 0x1000>,
+		      <0x0 0xf4520000 0x0 0x1000>;
+		reg-names = "ade_base",
+			    "media_base",
+			    "media_noc_base";
+
+		interrupts = <0 115 4>; /* ldi interrupt */
+
+		clocks = <&media_ctrl HI6220_ADE_CORE>,
+			 <&media_ctrl HI6220_CODEC_JPEG>,
+			 <&media_ctrl HI6220_ADE_PIX_SRC>;
+		/*clock name*/
+		clock-names  = "clk_ade_core",
+			       "clk_codec_jpeg",
+			       "clk_ade_pix";
+
+		assigned-clocks = <&media_ctrl HI6220_ADE_CORE>,
+			<&media_ctrl HI6220_CODEC_JPEG>;
+		assigned-clock-rates = <360000000>, <288000000>;
+		dma-coherent;
+
+		port {
+			ade_out: endpoint {
+				remote-endpoint = <&dsi_in>;
+			};
+		};
+	};
-- 
1.9.1



From xinliang.liu at linaro.org  Fri Feb  5 19:24:49 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Sat,  6 Feb 2016 11:24:49 +0800
Subject: [PATCH v4 02/11] drm/hisilicon: Add hisilicon kirin drm master driver
In-Reply-To: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1454729098-79807-3-git-send-email-xinliang.liu@linaro.org>

Add kirin DRM master driver for hi6220 SoC which used in HiKey board.
Add dumb buffer feature.
Add prime dmabuf feature.

v4: None.
v3:
- Move and rename all the files to kirin sub-directory.
  So that we could separate different seires SoCs' driver.
- Replace drm_platform_init, load, unload implementation.
v2:
- Remove abtraction layer.

Signed-off-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/Kconfig                         |   2 +
 drivers/gpu/drm/Makefile                        |   1 +
 drivers/gpu/drm/hisilicon/Kconfig               |   5 +
 drivers/gpu/drm/hisilicon/Makefile              |   5 +
 drivers/gpu/drm/hisilicon/kirin/Kconfig         |   9 +
 drivers/gpu/drm/hisilicon/kirin/Makefile        |   3 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 321 ++++++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  20 ++
 8 files changed, 366 insertions(+)
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b50ae60f5f50..f5c5656e2547 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -277,3 +277,5 @@ source "drivers/gpu/drm/imx/Kconfig"
 source "drivers/gpu/drm/vc4/Kconfig"
 
 source "drivers/gpu/drm/etnaviv/Kconfig"
+
+source "drivers/gpu/drm/hisilicon/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 61766dec6a8d..60554832079c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -74,3 +74,4 @@ obj-y			+= panel/
 obj-y			+= bridge/
 obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
+obj-y			+= hisilicon/
diff --git a/drivers/gpu/drm/hisilicon/Kconfig b/drivers/gpu/drm/hisilicon/Kconfig
new file mode 100644
index 000000000000..558c61b1b8e8
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/Kconfig
@@ -0,0 +1,5 @@
+#
+# hisilicon drm device configuration.
+# Please keep this list sorted alphabetically
+
+source "drivers/gpu/drm/hisilicon/kirin/Kconfig"
diff --git a/drivers/gpu/drm/hisilicon/Makefile b/drivers/gpu/drm/hisilicon/Makefile
new file mode 100644
index 000000000000..e3f6d493c996
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for hisilicon drm drivers.
+# Please keep this list sorted alphabetically
+
+obj-$(CONFIG_DRM_HISI_KIRIN) += kirin/
diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig b/drivers/gpu/drm/hisilicon/kirin/Kconfig
new file mode 100644
index 000000000000..3ac4b8edeac1
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
@@ -0,0 +1,9 @@
+config DRM_HISI_KIRIN
+	tristate "DRM Support for Hisilicon Kirin series SoCs Platform"
+	depends on DRM
+	select DRM_KMS_HELPER
+	select DRM_GEM_CMA_HELPER
+	select DRM_KMS_CMA_HELPER
+	help
+	  Choose this option if you have a hisilicon Kirin chipsets(hi6220).
+	  If M is selected the module will be called kirin-drm.
diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile b/drivers/gpu/drm/hisilicon/kirin/Makefile
new file mode 100644
index 000000000000..cb346de47d48
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -0,0 +1,3 @@
+kirin-drm-y := kirin_drm_drv.o
+
+obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
new file mode 100644
index 000000000000..789ebd1f5922
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -0,0 +1,321 @@
+/*
+ * Hisilicon Kirin SoCs drm master driver
+ *
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * Author:
+ *	Xinliang Liu <z.liuxinliang at hisilicon.com>
+ *	Xinliang Liu <xinliang.liu at linaro.org>
+ *	Xinwei Kong <kong.kongxinwei at hisilicon.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.
+ *
+ */
+
+#include <linux/of_platform.h>
+#include <linux/component.h>
+#include <linux/of_graph.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_gem_cma_helper.h>
+#include <drm/drm_fb_cma_helper.h>
+#include <drm/drm_atomic_helper.h>
+
+#include "kirin_drm_drv.h"
+
+static struct kirin_dc_ops *dc_ops;
+
+static int kirin_drm_kms_cleanup(struct drm_device *dev)
+{
+	dc_ops->cleanup(dev);
+	drm_mode_config_cleanup(dev);
+
+	return 0;
+}
+
+static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
+	.fb_create = drm_fb_cma_create,
+	.atomic_check = drm_atomic_helper_check,
+	.atomic_commit = drm_atomic_helper_commit,
+};
+
+static void kirin_drm_mode_config_init(struct drm_device *dev)
+{
+	dev->mode_config.min_width = 0;
+	dev->mode_config.min_height = 0;
+
+	dev->mode_config.max_width = 2048;
+	dev->mode_config.max_height = 2048;
+
+	dev->mode_config.funcs = &kirin_drm_mode_config_funcs;
+}
+
+static int kirin_drm_kms_init(struct drm_device *dev)
+{
+	int ret;
+
+	dev_set_drvdata(dev->dev, dev);
+
+	/* dev->mode_config initialization */
+	drm_mode_config_init(dev);
+	kirin_drm_mode_config_init(dev);
+
+	/* display controller init */
+	ret = dc_ops->init(dev);
+	if (ret)
+		goto err_mode_config_cleanup;
+
+	/* bind and init sub drivers */
+	ret = component_bind_all(dev->dev, dev);
+	if (ret) {
+		DRM_ERROR("failed to bind all component.\n");
+		goto err_dc_cleanup;
+	}
+
+	/* reset all the states of crtc/plane/encoder/connector */
+	drm_mode_config_reset(dev);
+
+	return 0;
+
+err_dc_cleanup:
+	dc_ops->cleanup(dev);
+err_mode_config_cleanup:
+	drm_mode_config_cleanup(dev);
+
+	return ret;
+}
+
+static const struct file_operations kirin_drm_fops = {
+	.owner		= THIS_MODULE,
+	.open		= drm_open,
+	.release	= drm_release,
+	.unlocked_ioctl	= drm_ioctl,
+#ifdef CONFIG_COMPAT
+	.compat_ioctl	= drm_compat_ioctl,
+#endif
+	.poll		= drm_poll,
+	.read		= drm_read,
+	.llseek		= no_llseek,
+	.mmap		= drm_gem_cma_mmap,
+};
+
+static int kirin_gem_cma_dumb_create(struct drm_file *file,
+				     struct drm_device *dev,
+				     struct drm_mode_create_dumb *args)
+{
+	return drm_gem_cma_dumb_create_internal(file, dev, args);
+}
+
+static struct drm_driver kirin_drm_driver = {
+	.driver_features	= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
+				  DRIVER_ATOMIC,
+	.fops			= &kirin_drm_fops,
+	.set_busid		= drm_platform_set_busid,
+
+	.gem_free_object	= drm_gem_cma_free_object,
+	.gem_vm_ops		= &drm_gem_cma_vm_ops,
+	.dumb_create		= kirin_gem_cma_dumb_create,
+	.dumb_map_offset	= drm_gem_cma_dumb_map_offset,
+	.dumb_destroy		= drm_gem_dumb_destroy,
+
+	.prime_handle_to_fd	= drm_gem_prime_handle_to_fd,
+	.prime_fd_to_handle	= drm_gem_prime_fd_to_handle,
+	.gem_prime_export	= drm_gem_prime_export,
+	.gem_prime_import	= drm_gem_prime_import,
+	.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
+	.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
+	.gem_prime_vmap		= drm_gem_cma_prime_vmap,
+	.gem_prime_vunmap	= drm_gem_cma_prime_vunmap,
+	.gem_prime_mmap		= drm_gem_cma_prime_mmap,
+
+	.name			= "kirin",
+	.desc			= "Hisilicon Kirin SoCs' DRM Driver",
+	.date			= "20150718",
+	.major			= 1,
+	.minor			= 0,
+};
+
+static int compare_of(struct device *dev, void *data)
+{
+	return dev->of_node == data;
+}
+
+static int kirin_drm_connectors_register(struct drm_device *dev)
+{
+	struct drm_connector *connector;
+	struct drm_connector *failed_connector;
+	int ret;
+
+	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+		ret = drm_connector_register(connector);
+		if (ret) {
+			failed_connector = connector;
+			goto err;
+		}
+	}
+
+	return 0;
+
+err:
+	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+		if (failed_connector == connector)
+			break;
+		drm_connector_unregister(connector);
+	}
+
+	return ret;
+}
+
+static int kirin_drm_bind(struct device *dev)
+{
+	struct drm_driver *driver = &kirin_drm_driver;
+	struct drm_device *drm_dev;
+	int ret;
+
+	drm_dev = drm_dev_alloc(driver, dev);
+	if (!drm_dev)
+		return -ENOMEM;
+
+	drm_dev->platformdev = to_platform_device(dev);
+
+	ret = kirin_drm_kms_init(drm_dev);
+	if (ret)
+		goto err_drm_dev_unref;
+
+	ret = drm_dev_register(drm_dev, 0);
+	if (ret)
+		goto err_kms_cleanup;
+
+	/* connectors should be registered after drm device register */
+	ret = kirin_drm_connectors_register(drm_dev);
+	if (ret)
+		goto err_drm_dev_unregister;
+
+	DRM_INFO("Initialized %s %d.%d.%d %s on minor %d\n",
+		 driver->name, driver->major, driver->minor, driver->patchlevel,
+		 driver->date, drm_dev->primary->index);
+
+	return 0;
+
+err_drm_dev_unregister:
+	drm_dev_unregister(drm_dev);
+err_kms_cleanup:
+	kirin_drm_kms_cleanup(drm_dev);
+err_drm_dev_unref:
+	drm_dev_unref(drm_dev);
+
+	return ret;
+}
+
+static void kirin_drm_unbind(struct device *dev)
+{
+	drm_put_dev(dev_get_drvdata(dev));
+}
+
+static const struct component_master_ops kirin_drm_ops = {
+	.bind = kirin_drm_bind,
+	.unbind = kirin_drm_unbind,
+};
+
+static const struct of_device_id kirin_drm_dt_ids[] = {
+	{ /* end node */ },
+};
+MODULE_DEVICE_TABLE(of, kirin_drm_dt_ids);
+
+static int kirin_get_dc_ops(struct device_node *np)
+{
+	const struct of_device_id *match_id;
+
+	match_id = of_match_node(kirin_drm_dt_ids, np);
+	if (!match_id) {
+		DRM_ERROR("failed to match dt id\n");
+		return -EINVAL;
+	}
+
+	dc_ops = (struct kirin_dc_ops *)match_id->data;
+	if (!dc_ops) {
+		DRM_ERROR("dt id data is null\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static struct device_node *kirin_get_remote_node(struct device_node *np)
+{
+	struct device_node *endpoint, *remote;
+
+	/* get the first endpoint, in our case only one remote node
+	 * is connected to display controller.
+	 */
+	endpoint = of_graph_get_next_endpoint(np, NULL);
+	if (!endpoint) {
+		DRM_ERROR("no valid endpoint node\n");
+		return ERR_PTR(-ENODEV);
+	}
+	of_node_put(endpoint);
+
+	remote = of_graph_get_remote_port_parent(endpoint);
+	if (!remote) {
+		DRM_ERROR("no valid remote node\n");
+		return ERR_PTR(-ENODEV);
+	}
+	of_node_put(remote);
+
+	if (!of_device_is_available(remote)) {
+		DRM_ERROR("not available for remote node\n");
+		return ERR_PTR(-ENODEV);
+	}
+
+	return remote;
+}
+
+static int kirin_drm_platform_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct component_match *match = NULL;
+	struct device_node *remote;
+	int ret;
+
+	ret = kirin_get_dc_ops(np);
+	if (ret)
+		return ret;
+
+	remote = kirin_get_remote_node(np);
+	if (IS_ERR(remote))
+		return PTR_ERR(remote);
+
+	component_match_add(dev, &match, compare_of, remote);
+
+	return component_master_add_with_match(dev, &kirin_drm_ops, match);
+
+	return 0;
+}
+
+static int kirin_drm_platform_remove(struct platform_device *pdev)
+{
+	component_master_del(&pdev->dev, &kirin_drm_ops);
+	dc_ops = NULL;
+	return 0;
+}
+
+static struct platform_driver kirin_drm_platform_driver = {
+	.probe = kirin_drm_platform_probe,
+	.remove = kirin_drm_platform_remove,
+	.driver = {
+		.name = "kirin-drm",
+		.of_match_table = kirin_drm_dt_ids,
+	},
+};
+
+module_platform_driver(kirin_drm_platform_driver);
+
+MODULE_AUTHOR("Xinliang Liu <xinliang.liu at linaro.org>");
+MODULE_AUTHOR("Xinliang Liu <z.liuxinliang at hisilicon.com>");
+MODULE_AUTHOR("Xinwei Kong <kong.kongxinwei at hisilicon.com>");
+MODULE_DESCRIPTION("hisilicon Kirin SoCs' DRM master driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
new file mode 100644
index 000000000000..75e9d82356d4
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -0,0 +1,20 @@
+/*
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __KIRIN_DRM_DRV_H__
+#define __KIRIN_DRM_DRV_H__
+
+/* display controller init/cleanup ops */
+struct kirin_dc_ops {
+	int (*init)(struct drm_device *dev);
+	void (*cleanup)(struct drm_device *dev);
+};
+
+#endif /* __KIRIN_DRM_DRV_H__ */
-- 
1.9.1



From xinliang.liu at linaro.org  Fri Feb  5 19:24:50 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Sat,  6 Feb 2016 11:24:50 +0800
Subject: [PATCH v4 03/11] drm/hisilicon: Add crtc driver for ADE
In-Reply-To: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1454729098-79807-4-git-send-email-xinliang.liu@linaro.org>

Add crtc funcs and helper funcs for ADE.

v4: None.
v3:
- Make ade as the master driver.
- Use port to connect with encoder.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/Makefile        |   3 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 280 +++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 458 ++++++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  15 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |   8 +
 5 files changed, 763 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c

diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile b/drivers/gpu/drm/hisilicon/kirin/Makefile
index cb346de47d48..2a61ab006ddb 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Makefile
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -1,3 +1,4 @@
-kirin-drm-y := kirin_drm_drv.o
+kirin-drm-y := kirin_drm_drv.o \
+	       kirin_drm_ade.o
 
 obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
new file mode 100644
index 000000000000..78020747abfe
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
@@ -0,0 +1,280 @@
+/*
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __KIRIN_ADE_REG_H__
+#define __KIRIN_ADE_REG_H__
+
+/*
+ * ADE Registers
+ */
+#define MASK(x)				(BIT(x) - 1)
+
+#define ADE_CTRL			0x0004
+#define FRM_END_START_OFST		0
+#define FRM_END_START_MASK		MASK(2)
+#define ADE_CTRL1			0x008C
+#define AUTO_CLK_GATE_EN_OFST		0
+#define AUTO_CLK_GATE_EN		BIT(0)
+#define ADE_ROT_SRC_CFG			0x0010
+#define ADE_DISP_SRC_CFG		0x0018
+#define ADE_WDMA2_SRC_CFG		0x001C
+#define ADE_SEC_OVLY_SRC_CFG		0x0020
+#define ADE_WDMA3_SRC_CFG		0x0024
+#define ADE_OVLY1_TRANS_CFG		0x002C
+#define ADE_EN				0x0100
+#define ADE_DISABLE			0
+#define ADE_ENABLE			1
+#define INTR_MASK_CPU(x)		(0x0C10 + (x) * 0x4)
+#define ADE_FRM_DISGARD_CTRL		0x00A4
+/* reset and reload regs */
+#define ADE_SOFT_RST_SEL(x)		(0x0078 + (x) * 0x4)
+#define ADE_RELOAD_DIS(x)		(0x00AC + (x) * 0x4)
+#define RDMA_OFST			0
+#define CLIP_OFST			15
+#define SCL_OFST			21
+#define CTRAN_OFST			24
+#define OVLY_OFST			37 /* 32+5 */
+/* channel regs */
+#define RD_CH_PE(x)			(0x1000 + (x) * 0x80)
+#define RD_CH_CTRL(x)			(0x1004 + (x) * 0x80)
+#define RD_CH_ADDR(x)			(0x1008 + (x) * 0x80)
+#define RD_CH_SIZE(x)			(0x100C + (x) * 0x80)
+#define RD_CH_STRIDE(x)			(0x1010 + (x) * 0x80)
+#define RD_CH_SPACE(x)			(0x1014 + (x) * 0x80)
+#define RD_CH_PARTIAL_SIZE(x)		(0x1018 + (x) * 0x80)
+#define RD_CH_PARTIAL_SPACE(x)		(0x101C + (x) * 0x80)
+#define RD_CH_EN(x)			(0x1020 + (x) * 0x80)
+#define RD_CH_STATUS(x)			(0x1024 + (x) * 0x80)
+#define RD_CH_DISP_CTRL			0x1404
+#define RD_CH_DISP_ADDR			0x1408
+#define RD_CH_DISP_SIZE			0x140C
+#define RD_CH_DISP_STRIDE		0x1410
+#define RD_CH_DISP_SPACE		0x1414
+#define RD_CH_DISP_EN			0x142C
+/* clip regs */
+#define ADE_CLIP_DISABLE(x)		(0x6800 + (x) * 0x100)
+#define ADE_CLIP_SIZE0(x)		(0x6804 + (x) * 0x100)
+#define ADE_CLIP_SIZE1(x)		(0x6808 + (x) * 0x100)
+#define ADE_CLIP_SIZE2(x)		(0x680C + (x) * 0x100)
+#define ADE_CLIP_CFG_OK(x)		(0x6810 + (x) * 0x100)
+/* scale regs */
+#define ADE_SCL1_MUX_CFG		0x000C
+#define ADE_SCL2_SRC_CFG		0x0014
+#define ADE_SCL3_MUX_CFG		0x0008
+#define ADE_SCL_CTRL(x)			(0x3000 + (x) * 0x800)
+#define ADE_SCL_HSP(x)			(0x3004 + (x) * 0x800)
+#define ADE_SCL_UV_HSP(x)		(0x3008 + (x) * 0x800)
+#define ADE_SCL_VSP(x)			(0x300C + (x) * 0x800)
+#define ADE_SCL_UV_VSP(x)		(0x3010 + (x) * 0x800)
+#define ADE_SCL_ORES(x)			(0x3014 + (x) * 0x800)
+#define ADE_SCL_IRES(x)			(0x3018 + (x) * 0x800)
+#define ADE_SCL_START(x)		(0x301C + (x) * 0x800)
+#define ADE_SCL_ERR(x)			(0x3020 + (x) * 0x800)
+#define ADE_SCL_PIX_OFST(x)		(0x3024 + (x) * 0x800)
+#define ADE_SCL_UV_PIX_OFST(x)		(0x3028 + (x) * 0x800)
+#define ADE_SCL_COEF_CLR(x)		(0x3030 + (x) * 0x800)
+#define ADE_SCL_HCOEF(x, m, n)		(0x3100 + (x) * 0x800 + \
+					12 * (m) + 4 * (n))
+#define ADE_SCL_VCOEF(x, i, j)		(0x340C + (x) * 0x800 + \
+					12 * (i) + 4 * (j))
+/* ctran regs */
+#define ADE_CTRAN5_TRANS_CFG		0x0040
+#define ADE_CTRAN_DIS(x)		(0x5004 + (x) * 0x100)
+#define CTRAN_BYPASS_ON			1
+#define CTRAN_BYPASS_OFF		0
+#define ADE_CTRAN_MODE_CHOOSE(x)	(0x5008 + (x) * 0x100)
+#define ADE_CTRAN_STAT(x)		(0x500C + (x) * 0x100)
+#define ADE_CTRAN_CHDC0(x)		(0x5010 + (x) * 0x100)
+#define ADE_CTRAN_CHDC1(x)		(0x5014 + (x) * 0x100)
+#define ADE_CTRAN_CHDC2(x)		(0x5018 + (x) * 0x100)
+#define ADE_CTRAN_CHDC3(x)		(0x501C + (x) * 0x100)
+#define ADE_CTRAN_CHDC4(x)		(0x5020 + (x) * 0x100)
+#define ADE_CTRAN_CHDC5(x)		(0x5024 + (x) * 0x100)
+#define ADE_CTRAN_CSC0(x)		(0x5028 + (x) * 0x100)
+#define ADE_CTRAN_CSC1(x)		(0x502C + (x) * 0x100)
+#define ADE_CTRAN_CSC2(x)		(0x5030 + (x) * 0x100)
+#define ADE_CTRAN_CSC3(x)		(0x5034 + (x) * 0x100)
+#define ADE_CTRAN_CSC4(x)		(0x5038 + (x) * 0x100)
+#define ADE_CTRAN_IMAGE_SIZE(x)		(0x503C + (x) * 0x100)
+#define ADE_CTRAN_CFG_OK(x)		(0x5040 + (x) * 0x100)
+/* overlay regs */
+#define ADE_OVLY_ALPHA_ST		0x2000
+#define ADE_OVLY_CH_XY0(x)		(0x2004 + (x) * 4)
+#define ADE_OVLY_CH_XY1(x)		(0x2024 + (x) * 4)
+#define ADE_OVLY_CH_CTL(x)		(0x204C + (x) * 4)
+#define ADE_OVLY_OUTPUT_SIZE(x)		(0x2070 + (x) * 8)
+#define OUTPUT_XSIZE_OFST		16
+#define ADE_OVLY_BASE_COLOR(x)		(0x2074 + (x) * 8)
+#define ADE_OVLYX_CTL(x)		(0x209C + (x) * 4)
+#define ADE_OVLY_CTL			0x0098
+#define CH_OVLY_SEL_OFST(x)		((x) * 4)
+#define CH_OVLY_SEL_MASK		MASK(2)
+#define CH_OVLY_SEL_VAL(x)		((x) + 1)
+#define CH_ALP_MODE_OFST		0
+#define CH_ALP_SEL_OFST			2
+#define CH_UNDER_ALP_SEL_OFST		4
+#define CH_EN_OFST			6
+#define CH_ALP_GBL_OFST			15
+#define CH_SEL_OFST			28
+
+/*
+ * LDI Registers
+ */
+#define LDI_HRZ_CTRL0			0x7400
+#define HBP_OFST			20
+#define LDI_HRZ_CTRL1			0x7404
+#define LDI_VRT_CTRL0			0x7408
+#define VBP_OFST			20
+#define LDI_VRT_CTRL1			0x740C
+#define LDI_PLR_CTRL			0x7410
+#define FLAG_NVSYNC			BIT(0)
+#define FLAG_NHSYNC			BIT(1)
+#define FLAG_NPIXCLK			BIT(2)
+#define FLAG_NDE			BIT(3)
+#define LDI_DSP_SIZE			0x7414
+#define VSIZE_OFST			20
+#define LDI_INT_EN			0x741C
+#define FRAME_END_INT_EN_OFST		1
+#define LDI_CTRL			0x7420
+#define BPP_OFST			3
+#define DATA_GATE_EN			BIT(2)
+#define LDI_EN				BIT(0)
+#define LDI_ORG_INT			0x7424
+#define LDI_MSK_INT			0x7428
+#define LDI_INT_CLR			0x742C
+#define LDI_WORK_MODE			0x7430
+#define LDI_DE_SPACE_LOW		0x7438
+#define LDI_MCU_INTS			0x7450
+#define LDI_MCU_INTE			0x7454
+#define LDI_MCU_INTC			0x7458
+#define LDI_HDMI_DSI_GT			0x7434
+
+/*
+ * media regs
+ */
+#define SC_MEDIA_RSTDIS				0x0530
+#define SC_MEDIA_RSTEN				0x052C
+#define NOC_ADE0_QOSGENERATOR_MODE		0x010C
+#define NOC_ADE0_QOSGENERATOR_EXTCONTROL	0x0118
+#define NOC_ADE1_QOSGENERATOR_MODE		0x020C
+#define NOC_ADE1_QOSGENERATOR_EXTCONTROL	0x0218
+
+/*
+ * ADE regs relevant enums
+ */
+enum frame_end_start {
+	/* regs take effective in every vsync */
+	REG_EFFECTIVE_IN_VSYNC = 0,
+	/* regs take effective in fist ade en and every frame end */
+	REG_EFFECTIVE_IN_ADEEN_FRMEND,
+	/* regs take effective in ade en immediately */
+	REG_EFFECTIVE_IN_ADEEN,
+	/* regs take effective in first vsync and every frame end */
+	REG_EFFECTIVE_IN_VSYNC_FRMEND
+};
+
+enum ade_fb_format {
+	ADE_RGB_565 = 0,
+	ADE_BGR_565,
+	ADE_XRGB_8888,
+	ADE_XBGR_8888,
+	ADE_ARGB_8888,
+	ADE_ABGR_8888,
+	ADE_RGBA_8888,
+	ADE_BGRA_8888,
+	ADE_RGB_888,
+	ADE_BGR_888 = 9,
+	ADE_FORMAT_NOT_SUPPORT = 800
+};
+
+enum ade_channel {
+	ADE_CH1 = 0,	/* channel 1 for primary plane */
+	ADE_CH_NUM
+};
+
+enum ade_scale {
+	ADE_SCL1 = 0,
+	ADE_SCL2,
+	ADE_SCL3,
+	ADE_SCL_NUM
+};
+
+enum ade_ctran {
+	ADE_CTRAN1 = 0,
+	ADE_CTRAN2,
+	ADE_CTRAN3,
+	ADE_CTRAN4,
+	ADE_CTRAN5,
+	ADE_CTRAN6,
+	ADE_CTRAN_NUM
+};
+
+enum ade_overlay {
+	ADE_OVLY1 = 0,
+	ADE_OVLY2,
+	ADE_OVLY3,
+	ADE_OVLY_NUM
+};
+
+enum ade_alpha_mode {
+	ADE_ALP_GLOBAL = 0,
+	ADE_ALP_PIXEL,
+	ADE_ALP_PIXEL_AND_GLB
+};
+
+enum ade_alpha_blending_mode {
+	ADE_ALP_MUL_COEFF_0 = 0,	/* alpha */
+	ADE_ALP_MUL_COEFF_1,		/* 1-alpha */
+	ADE_ALP_MUL_COEFF_2,		/* 0 */
+	ADE_ALP_MUL_COEFF_3		/* 1 */
+};
+
+/*
+ * LDI regs relevant enums
+ */
+enum dsi_pclk_en {
+	DSI_PCLK_ON = 0,
+	DSI_PCLK_OFF
+};
+
+enum ldi_output_format {
+	LDI_OUT_RGB_565 = 0,
+	LDI_OUT_RGB_666,
+	LDI_OUT_RGB_888
+};
+
+enum ldi_work_mode {
+	TEST_MODE = 0,
+	NORMAL_MODE
+};
+
+enum ldi_input_source {
+	DISP_SRC_NONE = 0,
+	DISP_SRC_OVLY2,
+	DISP_SRC_DISP,
+	DISP_SRC_ROT,
+	DISP_SRC_SCL2
+};
+
+/*
+ * Register Write/Read Helper functions
+ */
+static inline void ade_update_bits(void __iomem *addr, u32 bit_start,
+				   u32 mask, u32 val)
+{
+	u32 tmp, orig;
+
+	orig = readl(addr);
+	tmp = orig & ~(mask << bit_start);
+	tmp |= (val & mask) << bit_start;
+	writel(tmp, addr);
+}
+
+#endif
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
new file mode 100644
index 000000000000..b45149616716
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -0,0 +1,458 @@
+/*
+ * Hisilicon Hi6220 SoC ADE(Advanced Display Engine)'s crtc&plane driver
+ *
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * Author:
+ *	Xinliang Liu <z.liuxinliang at hisilicon.com>
+ *	Xinliang Liu <xinliang.liu at linaro.org>
+ *	Xinwei Kong <kong.kongxinwei at hisilicon.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.
+ *
+ */
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <video/display_timing.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_crtc.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_atomic.h>
+#include <drm/drm_atomic_helper.h>
+
+#include "kirin_drm_drv.h"
+#include "kirin_ade_reg.h"
+
+#define to_ade_crtc(crtc) \
+	container_of(crtc, struct ade_crtc, base)
+
+struct ade_hw_ctx {
+	void __iomem  *base;
+	void __iomem  *media_base;
+	void __iomem  *media_noc_base;
+	int irq;
+	struct clk *ade_core_clk;
+	struct clk *media_noc_clk;
+	struct clk *ade_pix_clk;
+	bool power_on;
+};
+
+struct ade_crtc {
+	struct drm_crtc base;
+	struct ade_hw_ctx *ctx;
+	bool enable;
+	u32 out_format;
+};
+
+struct ade_data {
+	struct ade_crtc acrtc;
+	struct ade_hw_ctx ctx;
+};
+
+static void ade_update_reload_bit(void __iomem *base, u32 bit_num, u32 val)
+{
+	u32 bit_ofst, reg_num;
+
+	bit_ofst = bit_num % 32;
+	reg_num = bit_num / 32;
+
+	ade_update_bits(base + ADE_RELOAD_DIS(reg_num), bit_ofst,
+			MASK(1), !!val);
+}
+
+static u32 ade_read_reload_bit(void __iomem *base, u32 bit_num)
+{
+	u32 tmp, bit_ofst, reg_num;
+
+	bit_ofst = bit_num % 32;
+	reg_num = bit_num / 32;
+
+	tmp = readl(base + ADE_RELOAD_DIS(reg_num));
+	return !!(BIT(bit_ofst) & tmp);
+}
+
+static void ade_init(struct ade_hw_ctx *ctx)
+{
+	void __iomem *base = ctx->base;
+
+	/* enable clk gate */
+	ade_update_bits(base + ADE_CTRL1, AUTO_CLK_GATE_EN_OFST,
+			AUTO_CLK_GATE_EN, ADE_ENABLE);
+	/* clear overlay */
+	writel(0, base + ADE_OVLY1_TRANS_CFG);
+	writel(0, base + ADE_OVLY_CTL);
+	writel(0, base + ADE_OVLYX_CTL(ADE_OVLY2));
+	/* clear reset and reload regs */
+	writel(MASK(32), base + ADE_SOFT_RST_SEL(0));
+	writel(MASK(32), base + ADE_SOFT_RST_SEL(1));
+	writel(MASK(32), base + ADE_RELOAD_DIS(0));
+	writel(MASK(32), base + ADE_RELOAD_DIS(1));
+	/* for video mode, that ade registers
+	 * became effective at frame end
+	 */
+	ade_update_bits(base + ADE_CTRL, FRM_END_START_OFST,
+			FRM_END_START_MASK, REG_EFFECTIVE_IN_ADEEN_FRMEND);
+}
+
+static void ade_ldi_set_mode(struct ade_crtc *acrtc,
+			     struct drm_display_mode *mode,
+			     struct drm_display_mode *adj_mode)
+{
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->base;
+	u32 width = mode->hdisplay;
+	u32 height = mode->vdisplay;
+	u32 hfp, hbp, hsw, vfp, vbp, vsw;
+	u32 plr_flags;
+	int ret;
+
+	plr_flags = (mode->flags & DRM_MODE_FLAG_NVSYNC) ? FLAG_NVSYNC : 0;
+	plr_flags |= (mode->flags & DRM_MODE_FLAG_NHSYNC) ? FLAG_NHSYNC : 0;
+	hfp = mode->hsync_start - mode->hdisplay;
+	hbp = mode->htotal - mode->hsync_end;
+	hsw = mode->hsync_end - mode->hsync_start;
+	vfp = mode->vsync_start - mode->vdisplay;
+	vbp = mode->vtotal - mode->vsync_end;
+	vsw = mode->vsync_end - mode->vsync_start;
+	if (vsw > 15) {
+		DRM_DEBUG_DRIVER("vsw exceeded 15\n");
+		vsw = 15;
+	}
+
+	writel((hbp << HBP_OFST) | hfp, base + LDI_HRZ_CTRL0);
+	 /* the configured value is actual value - 1 */
+	writel(hsw - 1, base + LDI_HRZ_CTRL1);
+	writel((vbp << VBP_OFST) | vfp, base + LDI_VRT_CTRL0);
+	 /* the configured value is actual value - 1 */
+	writel(vsw - 1, base + LDI_VRT_CTRL1);
+	 /* the configured value is actual value - 1 */
+	writel(((height - 1) << VSIZE_OFST) | (width - 1),
+	       base + LDI_DSP_SIZE);
+	writel(plr_flags, base + LDI_PLR_CTRL);
+
+	/* Success should be guaranteed in mode_valid call back,
+	 * so failer shouldn't happen here
+	 */
+	ret = clk_set_rate(ctx->ade_pix_clk, mode->clock * 1000);
+	if (ret)
+		DRM_ERROR("failed to set pixel clk %dHz (%d)\n",
+			  mode->clock * 1000, ret);
+	adj_mode->clock = clk_get_rate(ctx->ade_pix_clk) / 1000;
+
+	/* ctran6 setting */
+	writel(CTRAN_BYPASS_ON, base + ADE_CTRAN_DIS(ADE_CTRAN6));
+	 /* the configured value is actual value - 1 */
+	writel(width * height - 1, base + ADE_CTRAN_IMAGE_SIZE(ADE_CTRAN6));
+	ade_update_reload_bit(base, CTRAN_OFST + ADE_CTRAN6, 0);
+
+	DRM_DEBUG_DRIVER("set mode: %dx%d\n", width, height);
+}
+
+static int ade_power_up(struct ade_hw_ctx *ctx)
+{
+	void __iomem *media_base = ctx->media_base;
+	int ret;
+
+	ret = clk_prepare_enable(ctx->media_noc_clk);
+	if (ret) {
+		DRM_ERROR("failed to enable media_noc_clk (%d)\n", ret);
+		return ret;
+	}
+
+	writel(0x20, media_base + SC_MEDIA_RSTDIS);
+
+	ret = clk_prepare_enable(ctx->ade_core_clk);
+	if (ret) {
+		DRM_ERROR("failed to enable ade_core_clk (%d)\n", ret);
+		return ret;
+	}
+
+	ade_init(ctx);
+	ctx->power_on = true;
+	return 0;
+}
+
+static void ade_power_down(struct ade_hw_ctx *ctx)
+{
+	void __iomem *base = ctx->base;
+	void __iomem *media_base = ctx->media_base;
+
+	writel(ADE_DISABLE, base + LDI_CTRL);
+	/* dsi pixel off */
+	writel(DSI_PCLK_OFF, base + LDI_HDMI_DSI_GT);
+
+	clk_disable_unprepare(ctx->ade_core_clk);
+	writel(0x20, media_base + SC_MEDIA_RSTEN);
+	clk_disable_unprepare(ctx->media_noc_clk);
+	ctx->power_on = false;
+}
+
+static void ade_set_medianoc_qos(struct ade_crtc *acrtc)
+{
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->media_noc_base;
+	void __iomem *reg;
+	u32 val;
+
+	reg = base + NOC_ADE0_QOSGENERATOR_MODE;
+	val = (readl(reg) & 0xfffffffc) | 0x2;
+	writel(val, reg);
+
+	reg = base + NOC_ADE0_QOSGENERATOR_EXTCONTROL;
+	val = readl(reg) | 0x1;
+	writel(val, reg);
+
+	reg = base + NOC_ADE1_QOSGENERATOR_MODE;
+	val = (readl(reg) & 0xfffffffc) | 0x2;
+	writel(val, reg);
+
+	reg = base + NOC_ADE1_QOSGENERATOR_EXTCONTROL;
+	val = readl(reg) | 0x1;
+	writel(val, reg);
+}
+
+static void ade_display_enable(struct ade_crtc *acrtc)
+{
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->base;
+	u32 out_fmt = acrtc->out_format;
+
+	/* display source setting */
+	writel(DISP_SRC_OVLY2, base + ADE_DISP_SRC_CFG);
+
+	/* enable ade */
+	writel(ADE_ENABLE, base + ADE_EN);
+	/* enable ldi */
+	writel(NORMAL_MODE, base + LDI_WORK_MODE);
+	writel((out_fmt << BPP_OFST) | DATA_GATE_EN | LDI_EN,
+	       base + LDI_CTRL);
+	/* dsi pixel on */
+	writel(DSI_PCLK_ON, base + LDI_HDMI_DSI_GT);
+}
+
+static void ade_crtc_enable(struct drm_crtc *crtc)
+{
+	struct ade_crtc *acrtc = to_ade_crtc(crtc);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	int ret;
+
+	if (acrtc->enable)
+		return;
+
+	if (!ctx->power_on) {
+		ret = ade_power_up(ctx);
+		if (ret)
+			return;
+	}
+
+	ade_set_medianoc_qos(acrtc);
+	ade_display_enable(acrtc);
+	acrtc->enable = true;
+}
+
+static void ade_crtc_disable(struct drm_crtc *crtc)
+{
+	struct ade_crtc *acrtc = to_ade_crtc(crtc);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+
+	if (!acrtc->enable)
+		return;
+
+	ade_power_down(ctx);
+	acrtc->enable = false;
+}
+
+static int ade_crtc_atomic_check(struct drm_crtc *crtc,
+				 struct drm_crtc_state *state)
+{
+	/* do nothing */
+	return 0;
+}
+
+static void ade_crtc_mode_set_nofb(struct drm_crtc *crtc)
+{
+	struct ade_crtc *acrtc = to_ade_crtc(crtc);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	struct drm_display_mode *mode = &crtc->state->mode;
+	struct drm_display_mode *adj_mode = &crtc->state->adjusted_mode;
+
+	if (!ctx->power_on)
+		(void)ade_power_up(ctx);
+	ade_ldi_set_mode(acrtc, mode, adj_mode);
+}
+
+static void ade_crtc_atomic_begin(struct drm_crtc *crtc,
+				  struct drm_crtc_state *old_state)
+{
+	struct ade_crtc *acrtc = to_ade_crtc(crtc);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+
+	if (!ctx->power_on)
+		(void)ade_power_up(ctx);
+}
+
+static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
+				  struct drm_crtc_state *old_state)
+
+{
+	struct ade_crtc *acrtc = to_ade_crtc(crtc);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->base;
+
+	/* only crtc is eanbled regs take effect */
+	if (acrtc->enable) {
+		/* flush ade regitsters */
+		writel(ADE_ENABLE, base + ADE_EN);
+	}
+}
+
+static const struct drm_crtc_helper_funcs ade_crtc_helper_funcs = {
+	.enable		= ade_crtc_enable,
+	.disable	= ade_crtc_disable,
+	.atomic_check	= ade_crtc_atomic_check,
+	.mode_set_nofb	= ade_crtc_mode_set_nofb,
+	.atomic_begin	= ade_crtc_atomic_begin,
+	.atomic_flush	= ade_crtc_atomic_flush,
+};
+
+static const struct drm_crtc_funcs ade_crtc_funcs = {
+	.destroy	= drm_crtc_cleanup,
+	.set_config	= drm_atomic_helper_set_config,
+	.page_flip	= drm_atomic_helper_page_flip,
+	.reset		= drm_atomic_helper_crtc_reset,
+	.set_property = drm_atomic_helper_crtc_set_property,
+	.atomic_duplicate_state	= drm_atomic_helper_crtc_duplicate_state,
+	.atomic_destroy_state	= drm_atomic_helper_crtc_destroy_state,
+};
+
+static int ade_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
+			 struct drm_plane *plane)
+{
+	struct kirin_drm_private *priv = dev->dev_private;
+	struct device_node *port;
+	int ret;
+
+	/* set crtc port so that
+	 * drm_of_find_possible_crtcs call works
+	 */
+	port = of_get_child_by_name(dev->dev->of_node, "port");
+	if (!port) {
+		DRM_ERROR("no port node found in %s\n",
+			  dev->dev->of_node->full_name);
+		return -EINVAL;
+	}
+	of_node_put(port);
+	crtc->port = port;
+
+	ret = drm_crtc_init_with_planes(dev, crtc, plane, NULL,
+					&ade_crtc_funcs, NULL);
+	if (ret) {
+		DRM_ERROR("failed to init crtc.\n");
+		return ret;
+	}
+
+	drm_crtc_helper_add(crtc, &ade_crtc_helper_funcs);
+	priv->crtc[drm_crtc_index(crtc)] = crtc;
+
+	return 0;
+}
+
+static int ade_dts_parse(struct platform_device *pdev, struct ade_hw_ctx *ctx)
+{
+	struct resource *res;
+	struct device *dev = &pdev->dev;
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ade_base");
+	ctx->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(ctx->base)) {
+		DRM_ERROR("failed to remap ade io base\n");
+		return  PTR_ERR(ctx->base);
+	}
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "media_base");
+	ctx->media_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(ctx->media_base)) {
+		DRM_ERROR("failed to remap media io base\n");
+		return PTR_ERR(ctx->media_base);
+	}
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+					   "media_noc_base");
+	ctx->media_noc_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(ctx->media_noc_base)) {
+		DRM_ERROR("failed to remap media noc base\n");
+		return PTR_ERR(ctx->media_noc_base);
+	}
+
+	ctx->irq = platform_get_irq(pdev, 0);
+	if (ctx->irq < 0) {
+		DRM_ERROR("failed to get irq\n");
+		return -ENODEV;
+	}
+
+	ctx->ade_core_clk = devm_clk_get(dev, "clk_ade_core");
+	if (!ctx->ade_core_clk) {
+		DRM_ERROR("failed to parse clk ADE_CORE\n");
+		return -ENODEV;
+	}
+
+	ctx->media_noc_clk = devm_clk_get(dev, "clk_codec_jpeg");
+	if (!ctx->media_noc_clk) {
+		DRM_ERROR("failed to parse clk CODEC_JPEG\n");
+	    return -ENODEV;
+	}
+
+	ctx->ade_pix_clk = devm_clk_get(dev, "clk_ade_pix");
+	if (!ctx->ade_pix_clk) {
+		DRM_ERROR("failed to parse clk ADE_PIX\n");
+	    return -ENODEV;
+	}
+
+	return 0;
+}
+
+int ade_drm_init(struct drm_device *dev)
+{
+	struct platform_device *pdev = dev->platformdev;
+	struct ade_data *ade;
+	struct ade_hw_ctx *ctx;
+	struct ade_crtc *acrtc;
+	int ret;
+
+	ade = devm_kzalloc(dev->dev, sizeof(*ade), GFP_KERNEL);
+	if (!ade) {
+		DRM_ERROR("failed to alloc ade_data\n");
+		return -ENOMEM;
+	}
+	platform_set_drvdata(pdev, ade);
+
+	ctx = &ade->ctx;
+	acrtc = &ade->acrtc;
+	acrtc->ctx = ctx;
+	acrtc->out_format = LDI_OUT_RGB_888;
+
+	ret = ade_dts_parse(pdev, ctx);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+void ade_drm_cleanup(struct drm_device *dev)
+{
+	struct platform_device *pdev = dev->platformdev;
+	struct ade_data *ade = platform_get_drvdata(pdev);
+	struct drm_crtc *crtc = &ade->acrtc.base;
+
+	drm_crtc_cleanup(crtc);
+}
+
+const struct kirin_dc_ops ade_dc_ops = {
+	.init = ade_drm_init,
+	.cleanup = ade_drm_cleanup
+};
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 789ebd1f5922..055729c1889c 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -30,8 +30,12 @@ static struct kirin_dc_ops *dc_ops;
 
 static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
+	struct kirin_drm_private *priv = dev->dev_private;
+
 	dc_ops->cleanup(dev);
 	drm_mode_config_cleanup(dev);
+	devm_kfree(dev->dev, priv);
+	dev->dev_private = NULL;
 
 	return 0;
 }
@@ -55,8 +59,14 @@ static void kirin_drm_mode_config_init(struct drm_device *dev)
 
 static int kirin_drm_kms_init(struct drm_device *dev)
 {
+	struct kirin_drm_private *priv;
 	int ret;
 
+	priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	dev->dev_private = priv;
 	dev_set_drvdata(dev->dev, dev);
 
 	/* dev->mode_config initialization */
@@ -84,6 +94,8 @@ err_dc_cleanup:
 	dc_ops->cleanup(dev);
 err_mode_config_cleanup:
 	drm_mode_config_cleanup(dev);
+	devm_kfree(dev->dev, priv);
+	dev->dev_private = NULL;
 
 	return ret;
 }
@@ -221,6 +233,9 @@ static const struct component_master_ops kirin_drm_ops = {
 };
 
 static const struct of_device_id kirin_drm_dt_ids[] = {
+	{ .compatible = "hisilicon,hi6220-ade",
+	  .data = &ade_dc_ops,
+	},
 	{ /* end node */ },
 };
 MODULE_DEVICE_TABLE(of, kirin_drm_dt_ids);
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 75e9d82356d4..5a05ad6a81db 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -11,10 +11,18 @@
 #ifndef __KIRIN_DRM_DRV_H__
 #define __KIRIN_DRM_DRV_H__
 
+#define MAX_CRTC	2
+
 /* display controller init/cleanup ops */
 struct kirin_dc_ops {
 	int (*init)(struct drm_device *dev);
 	void (*cleanup)(struct drm_device *dev);
 };
 
+struct kirin_drm_private {
+	struct drm_crtc *crtc[MAX_CRTC];
+};
+
+extern const struct kirin_dc_ops ade_dc_ops;
+
 #endif /* __KIRIN_DRM_DRV_H__ */
-- 
1.9.1



From xinliang.liu at linaro.org  Fri Feb  5 19:24:51 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Sat,  6 Feb 2016 11:24:51 +0800
Subject: [PATCH v4 04/11] drm/hisilicon: Add plane driver for ADE
In-Reply-To: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1454729098-79807-5-git-send-email-xinliang.liu@linaro.org>

Add plane funcs and helper funcs for ADE.

v4: None.
v3:
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 535 +++++++++++++++++++++++-
 1 file changed, 534 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index b45149616716..ff70f1c3dd78 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -24,13 +24,23 @@
 #include <drm/drm_crtc_helper.h>
 #include <drm/drm_atomic.h>
 #include <drm/drm_atomic_helper.h>
+#include <drm/drm_plane_helper.h>
+#include <drm/drm_gem_cma_helper.h>
+#include <drm/drm_fb_cma_helper.h>
 
 #include "kirin_drm_drv.h"
 #include "kirin_ade_reg.h"
 
+#define PRIMARY_CH	ADE_CH1 /* primary plane */
+#define OUT_OVLY	ADE_OVLY2 /* output overlay compositor */
+#define ADE_DEBUG	1
+
 #define to_ade_crtc(crtc) \
 	container_of(crtc, struct ade_crtc, base)
 
+#define to_ade_plane(plane) \
+	container_of(plane, struct ade_plane, base)
+
 struct ade_hw_ctx {
 	void __iomem  *base;
 	void __iomem  *media_base;
@@ -49,11 +59,76 @@ struct ade_crtc {
 	u32 out_format;
 };
 
+struct ade_plane {
+	struct drm_plane base;
+	void *ctx;
+	u8 ch; /* channel */
+};
+
 struct ade_data {
 	struct ade_crtc acrtc;
+	struct ade_plane aplane[ADE_CH_NUM];
 	struct ade_hw_ctx ctx;
 };
 
+/* ade-format info: */
+struct ade_format {
+	u32 pixel_format;
+	enum ade_fb_format ade_format;
+};
+
+static const struct ade_format ade_formats[] = {
+	/* 16bpp RGB: */
+	{ DRM_FORMAT_RGB565, ADE_RGB_565 },
+	{ DRM_FORMAT_BGR565, ADE_BGR_565 },
+	/* 24bpp RGB: */
+	{ DRM_FORMAT_RGB888, ADE_RGB_888 },
+	{ DRM_FORMAT_BGR888, ADE_BGR_888 },
+	/* 32bpp [A]RGB: */
+	{ DRM_FORMAT_XRGB8888, ADE_XRGB_8888 },
+	{ DRM_FORMAT_XBGR8888, ADE_XBGR_8888 },
+	{ DRM_FORMAT_RGBA8888, ADE_RGBA_8888 },
+	{ DRM_FORMAT_BGRA8888, ADE_BGRA_8888 },
+	{ DRM_FORMAT_ARGB8888, ADE_ARGB_8888 },
+	{ DRM_FORMAT_ABGR8888, ADE_ABGR_8888 },
+};
+
+static const u32 channel_formats1[] = {
+	/* channel 1,2,3,4 */
+	DRM_FORMAT_RGB565, DRM_FORMAT_BGR565, DRM_FORMAT_RGB888,
+	DRM_FORMAT_BGR888, DRM_FORMAT_XRGB8888, DRM_FORMAT_XBGR8888,
+	DRM_FORMAT_RGBA8888, DRM_FORMAT_BGRA8888, DRM_FORMAT_ARGB8888,
+	DRM_FORMAT_ABGR8888
+};
+
+u32 ade_get_channel_formats(u8 ch, const u32 **formats)
+{
+	switch (ch) {
+	case ADE_CH1:
+		*formats = channel_formats1;
+		return ARRAY_SIZE(channel_formats1);
+	default:
+		DRM_ERROR("no this channel %d\n", ch);
+		*formats = NULL;
+		return 0;
+	}
+}
+
+/* convert from fourcc format to ade format */
+static u32 ade_get_format(u32 pixel_format)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(ade_formats); i++)
+		if (ade_formats[i].pixel_format == pixel_format)
+			return ade_formats[i].ade_format;
+
+	/* not found */
+	DRM_ERROR("Not found pixel format!!fourcc_format= %d\n",
+		  pixel_format);
+	return ADE_FORMAT_NOT_SUPPORT;
+}
+
 static void ade_update_reload_bit(void __iomem *base, u32 bit_num, u32 val)
 {
 	u32 bit_ofst, reg_num;
@@ -86,7 +161,7 @@ static void ade_init(struct ade_hw_ctx *ctx)
 	/* clear overlay */
 	writel(0, base + ADE_OVLY1_TRANS_CFG);
 	writel(0, base + ADE_OVLY_CTL);
-	writel(0, base + ADE_OVLYX_CTL(ADE_OVLY2));
+	writel(0, base + ADE_OVLYX_CTL(OUT_OVLY));
 	/* clear reset and reload regs */
 	writel(MASK(32), base + ADE_SOFT_RST_SEL(0));
 	writel(MASK(32), base + ADE_SOFT_RST_SEL(1));
@@ -144,6 +219,10 @@ static void ade_ldi_set_mode(struct ade_crtc *acrtc,
 			  mode->clock * 1000, ret);
 	adj_mode->clock = clk_get_rate(ctx->ade_pix_clk) / 1000;
 
+	/* set overlay compositor output size */
+	writel(((width - 1) << OUTPUT_XSIZE_OFST) | (height - 1),
+	       base + ADE_OVLY_OUTPUT_SIZE(OUT_OVLY));
+
 	/* ctran6 setting */
 	writel(CTRAN_BYPASS_ON, base + ADE_CTRAN_DIS(ADE_CTRAN6));
 	 /* the configured value is actual value - 1 */
@@ -222,6 +301,10 @@ static void ade_display_enable(struct ade_crtc *acrtc)
 	void __iomem *base = ctx->base;
 	u32 out_fmt = acrtc->out_format;
 
+	/* enable output overlay compositor */
+	writel(ADE_ENABLE, base + ADE_OVLYX_CTL(OUT_OVLY));
+	ade_update_reload_bit(base, OVLY_OFST + OUT_OVLY, 0);
+
 	/* display source setting */
 	writel(DISP_SRC_OVLY2, base + ADE_DISP_SRC_CFG);
 
@@ -235,6 +318,97 @@ static void ade_display_enable(struct ade_crtc *acrtc)
 	writel(DSI_PCLK_ON, base + LDI_HDMI_DSI_GT);
 }
 
+#if ADE_DEBUG
+static void ade_rdma_dump_regs(void __iomem *base, u32 ch)
+{
+	u32 reg_ctrl, reg_addr, reg_size, reg_stride, reg_space, reg_en;
+	u32 val;
+
+	reg_ctrl = RD_CH_CTRL(ch);
+	reg_addr = RD_CH_ADDR(ch);
+	reg_size = RD_CH_SIZE(ch);
+	reg_stride = RD_CH_STRIDE(ch);
+	reg_space = RD_CH_SPACE(ch);
+	reg_en = RD_CH_EN(ch);
+
+	val = ade_read_reload_bit(base, RDMA_OFST + ch);
+	DRM_DEBUG_DRIVER("[rdma%d]: reload(%d)\n", ch + 1, val);
+	val = readl(base + reg_ctrl);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_ctrl(0x%08x)\n", ch + 1, val);
+	val = readl(base + reg_addr);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_addr(0x%08x)\n", ch + 1, val);
+	val = readl(base + reg_size);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_size(0x%08x)\n", ch + 1, val);
+	val = readl(base + reg_stride);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_stride(0x%08x)\n", ch + 1, val);
+	val = readl(base + reg_space);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_space(0x%08x)\n", ch + 1, val);
+	val = readl(base + reg_en);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_en(0x%08x)\n", ch + 1, val);
+}
+
+static void ade_clip_dump_regs(void __iomem *base, u32 ch)
+{
+	u32 val;
+
+	val = ade_read_reload_bit(base, CLIP_OFST + ch);
+	DRM_DEBUG_DRIVER("[clip%d]: reload(%d)\n", ch + 1, val);
+	val = readl(base + ADE_CLIP_DISABLE(ch));
+	DRM_DEBUG_DRIVER("[clip%d]: reg_clip_disable(0x%08x)\n", ch + 1, val);
+	val = readl(base + ADE_CLIP_SIZE0(ch));
+	DRM_DEBUG_DRIVER("[clip%d]: reg_clip_size0(0x%08x)\n", ch + 1, val);
+	val = readl(base + ADE_CLIP_SIZE1(ch));
+	DRM_DEBUG_DRIVER("[clip%d]: reg_clip_size1(0x%08x)\n", ch + 1, val);
+}
+
+static void ade_compositor_routing_dump_regs(void __iomem *base, u32 ch)
+{
+	u8 ovly_ch = 0; /* TODO: Only primary plane now */
+	u32 val;
+
+	val = readl(base + ADE_OVLY_CH_XY0(ovly_ch));
+	DRM_DEBUG_DRIVER("[overlay ch%d]: reg_ch_xy0(0x%08x)\n", ovly_ch, val);
+	val = readl(base + ADE_OVLY_CH_XY1(ovly_ch));
+	DRM_DEBUG_DRIVER("[overlay ch%d]: reg_ch_xy1(0x%08x)\n", ovly_ch, val);
+	val = readl(base + ADE_OVLY_CH_CTL(ovly_ch));
+	DRM_DEBUG_DRIVER("[overlay ch%d]: reg_ch_ctl(0x%08x)\n", ovly_ch, val);
+}
+
+static void ade_dump_overlay_compositor_regs(void __iomem *base, u32 comp)
+{
+	u32 val;
+
+	val = ade_read_reload_bit(base, OVLY_OFST + comp);
+	DRM_DEBUG_DRIVER("[overlay%d]: reload(%d)\n", comp + 1, val);
+	writel(ADE_ENABLE, base + ADE_OVLYX_CTL(comp));
+	DRM_DEBUG_DRIVER("[overlay%d]: reg_ctl(0x%08x)\n", comp + 1, val);
+	val = readl(base + ADE_OVLY_CTL);
+	DRM_DEBUG_DRIVER("ovly_ctl(0x%08x)\n", val);
+}
+
+static void ade_dump_regs(void __iomem *base)
+{
+	u32 i;
+
+	/* dump channel regs */
+	for (i = 0; i < ADE_CH_NUM; i++) {
+		/* dump rdma regs */
+		ade_rdma_dump_regs(base, i);
+
+		/* dump clip regs */
+		ade_clip_dump_regs(base, i);
+
+		/* dump compositor routing regs */
+		ade_compositor_routing_dump_regs(base, i);
+	}
+
+	/* dump overlay compositor regs */
+	ade_dump_overlay_compositor_regs(base, OUT_OVLY);
+}
+#else
+static void ade_dump_regs(void __iomem *base) { }
+#endif
+
 static void ade_crtc_enable(struct drm_crtc *crtc)
 {
 	struct ade_crtc *acrtc = to_ade_crtc(crtc);
@@ -252,6 +426,7 @@ static void ade_crtc_enable(struct drm_crtc *crtc)
 
 	ade_set_medianoc_qos(acrtc);
 	ade_display_enable(acrtc);
+	ade_dump_regs(ctx->base);
 	acrtc->enable = true;
 }
 
@@ -306,6 +481,7 @@ static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
 
 	/* only crtc is eanbled regs take effect */
 	if (acrtc->enable) {
+		ade_dump_regs(base);
 		/* flush ade regitsters */
 		writel(ADE_ENABLE, base + ADE_EN);
 	}
@@ -362,6 +538,338 @@ static int ade_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
 	return 0;
 }
 
+static void ade_rdma_set(void __iomem *base, struct drm_framebuffer *fb,
+			 u32 ch, u32 y, u32 in_h, u32 fmt)
+{
+	struct drm_gem_cma_object *obj = drm_fb_cma_get_gem_obj(fb, 0);
+	u32 reg_ctrl, reg_addr, reg_size, reg_stride, reg_space, reg_en;
+	u32 stride = fb->pitches[0];
+	u32 addr = (u32)obj->paddr + y * stride;
+
+	DRM_DEBUG_DRIVER("rdma%d: (y=%d, height=%d), stride=%d, paddr=0x%x\n",
+			 ch + 1, y, in_h, stride, (u32)obj->paddr);
+	DRM_DEBUG_DRIVER("addr=0x%x, fb:%dx%d, pixel_format=%d(%s)\n",
+			 addr, fb->width, fb->height, fmt,
+			 drm_get_format_name(fb->pixel_format));
+
+	/* get reg offset */
+	reg_ctrl = RD_CH_CTRL(ch);
+	reg_addr = RD_CH_ADDR(ch);
+	reg_size = RD_CH_SIZE(ch);
+	reg_stride = RD_CH_STRIDE(ch);
+	reg_space = RD_CH_SPACE(ch);
+	reg_en = RD_CH_EN(ch);
+
+	/*
+	 * TODO: set rotation
+	 */
+	writel((fmt << 16) & 0x1f0000, base + reg_ctrl);
+	writel(addr, base + reg_addr);
+	writel((in_h << 16) | stride, base + reg_size);
+	writel(stride, base + reg_stride);
+	writel(in_h * stride, base + reg_space);
+	writel(ADE_ENABLE, base + reg_en);
+	ade_update_reload_bit(base, RDMA_OFST + ch, 0);
+}
+
+static void ade_rdma_disable(void __iomem *base, u32 ch)
+{
+	u32 reg_en;
+
+	/* get reg offset */
+	reg_en = RD_CH_EN(ch);
+	writel(0, base + reg_en);
+	ade_update_reload_bit(base, RDMA_OFST + ch, 1);
+}
+
+static void ade_clip_set(void __iomem *base, u32 ch, u32 fb_w, u32 x,
+			 u32 in_w, u32 in_h)
+{
+	u32 disable_val;
+	u32 clip_left;
+	u32 clip_right;
+
+	/*
+	 * clip width, no need to clip height
+	 */
+	if (fb_w == in_w) { /* bypass */
+		disable_val = 1;
+		clip_left = 0;
+		clip_right = 0;
+	} else {
+		disable_val = 0;
+		clip_left = x;
+		clip_right = fb_w - (x + in_w) - 1;
+	}
+
+	DRM_DEBUG_DRIVER("clip%d: clip_left=%d, clip_right=%d\n",
+			 ch + 1, clip_left, clip_right);
+
+	writel(disable_val, base + ADE_CLIP_DISABLE(ch));
+	writel((fb_w - 1) << 16 | (in_h - 1), base + ADE_CLIP_SIZE0(ch));
+	writel(clip_left << 16 | clip_right, base + ADE_CLIP_SIZE1(ch));
+	ade_update_reload_bit(base, CLIP_OFST + ch, 0);
+}
+
+static void ade_clip_disable(void __iomem *base, u32 ch)
+{
+	writel(1, base + ADE_CLIP_DISABLE(ch));
+	ade_update_reload_bit(base, CLIP_OFST + ch, 1);
+}
+
+static bool has_Alpha_channel(int format)
+{
+	switch (format) {
+	case ADE_ARGB_8888:
+	case ADE_ABGR_8888:
+	case ADE_RGBA_8888:
+	case ADE_BGRA_8888:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static void ade_get_blending_params(u32 fmt, u8 glb_alpha, u8 *alp_mode,
+				    u8 *alp_sel, u8 *under_alp_sel)
+{
+	bool has_alpha = has_Alpha_channel(fmt);
+
+	/*
+	 * get alp_mode
+	 */
+	if (has_alpha && glb_alpha < 255)
+		*alp_mode = ADE_ALP_PIXEL_AND_GLB;
+	else if (has_alpha)
+		*alp_mode = ADE_ALP_PIXEL;
+	else
+		*alp_mode = ADE_ALP_GLOBAL;
+
+	/*
+	 * get alp sel
+	 */
+	*alp_sel = ADE_ALP_MUL_COEFF_3; /* 1 */
+	*under_alp_sel = ADE_ALP_MUL_COEFF_2; /* 0 */
+}
+
+static void ade_compositor_routing_set(void __iomem *base, u8 ch,
+				       u32 x0, u32 y0,
+				       u32 in_w, u32 in_h, u32 fmt)
+{
+	u8 ovly_ch = 0; /* TODO: This is the zpos, only one plane now */
+	u8 glb_alpha = 255;
+	u32 x1 = x0 + in_w - 1;
+	u32 y1 = y0 + in_h - 1;
+	u32 val;
+	u8 alp_sel;
+	u8 under_alp_sel;
+	u8 alp_mode;
+
+	ade_get_blending_params(fmt, glb_alpha, &alp_mode, &alp_sel,
+				&under_alp_sel);
+
+	/* overlay routing setting
+	 */
+	writel(x0 << 16 | y0, base + ADE_OVLY_CH_XY0(ovly_ch));
+	writel(x1 << 16 | y1, base + ADE_OVLY_CH_XY1(ovly_ch));
+	val = (ch + 1) << CH_SEL_OFST | BIT(CH_EN_OFST) |
+		alp_sel << CH_ALP_SEL_OFST |
+		under_alp_sel << CH_UNDER_ALP_SEL_OFST |
+		glb_alpha << CH_ALP_GBL_OFST |
+		alp_mode << CH_ALP_MODE_OFST;
+	writel(val, base + ADE_OVLY_CH_CTL(ovly_ch));
+	/* connect this plane/channel to overlay2 compositor */
+	ade_update_bits(base + ADE_OVLY_CTL, CH_OVLY_SEL_OFST(ovly_ch),
+			CH_OVLY_SEL_MASK, CH_OVLY_SEL_VAL(OUT_OVLY));
+}
+
+static void ade_compositor_routing_disable(void __iomem *base, u32 ch)
+{
+	u8 ovly_ch = 0; /* TODO: Only primary plane now */
+
+	/* disable this plane/channel */
+	ade_update_bits(base + ADE_OVLY_CH_CTL(ovly_ch), CH_EN_OFST,
+			MASK(1), 0);
+	/* dis-connect this plane/channel of overlay2 compositor */
+	ade_update_bits(base + ADE_OVLY_CTL, CH_OVLY_SEL_OFST(ovly_ch),
+			CH_OVLY_SEL_MASK, 0);
+}
+
+/*
+ * Typicaly, a channel looks like: DMA-->clip-->scale-->ctrans-->compositor
+ */
+static void ade_update_channel(struct ade_plane *aplane,
+			       struct drm_framebuffer *fb, int crtc_x,
+			       int crtc_y, unsigned int crtc_w,
+			       unsigned int crtc_h, u32 src_x,
+			       u32 src_y, u32 src_w, u32 src_h)
+{
+	struct ade_hw_ctx *ctx = aplane->ctx;
+	void __iomem *base = ctx->base;
+	u32 fmt = ade_get_format(fb->pixel_format);
+	u32 ch = aplane->ch;
+	u32 in_w;
+	u32 in_h;
+
+	DRM_DEBUG_DRIVER("channel%d: src:(%d, %d)-%dx%d, crtc:(%d, %d)-%dx%d",
+			 ch + 1, src_x, src_y, src_w, src_h,
+			 crtc_x, crtc_y, crtc_w, crtc_h);
+
+	/* 1) DMA setting */
+	in_w = src_w;
+	in_h = src_h;
+	ade_rdma_set(base, fb, ch, src_y, in_h, fmt);
+
+	/* 2) clip setting */
+	ade_clip_set(base, ch, fb->width, src_x, in_w, in_h);
+
+	/* 3) TODO: scale setting for overlay planes */
+
+	/* 4) TODO: ctran/csc setting for overlay planes */
+
+	/* 5) compositor routing setting */
+	ade_compositor_routing_set(base, ch, crtc_x, crtc_y, in_w, in_h, fmt);
+}
+
+static void ade_disable_channel(struct ade_plane *aplane)
+{
+	struct ade_hw_ctx *ctx = aplane->ctx;
+	void __iomem *base = ctx->base;
+	u32 ch = aplane->ch;
+
+	DRM_DEBUG_DRIVER("disable channel%d\n", ch + 1);
+
+	/* disable read DMA */
+	ade_rdma_disable(base, ch);
+
+	/* disable clip */
+	ade_clip_disable(base, ch);
+
+	/* disable compositor routing */
+	ade_compositor_routing_disable(base, ch);
+}
+
+static int ade_plane_prepare_fb(struct drm_plane *plane,
+				const struct drm_plane_state *new_state)
+{
+	/* do nothing */
+	return 0;
+}
+
+static void ade_plane_cleanup_fb(struct drm_plane *plane,
+				 const struct drm_plane_state *old_state)
+{
+	/* do nothing */
+}
+
+static int ade_plane_atomic_check(struct drm_plane *plane,
+				  struct drm_plane_state *state)
+{
+	struct drm_framebuffer *fb = state->fb;
+	struct drm_crtc *crtc = state->crtc;
+	struct drm_crtc_state *crtc_state;
+	u32 src_x = state->src_x >> 16;
+	u32 src_y = state->src_y >> 16;
+	u32 src_w = state->src_w >> 16;
+	u32 src_h = state->src_h >> 16;
+	int crtc_x = state->crtc_x;
+	int crtc_y = state->crtc_y;
+	u32 crtc_w = state->crtc_w;
+	u32 crtc_h = state->crtc_h;
+	u32 fmt;
+
+	if (!crtc || !fb)
+		return 0;
+
+	fmt = ade_get_format(fb->pixel_format);
+	if (fmt == ADE_FORMAT_NOT_SUPPORT)
+		return -EINVAL;
+
+	crtc_state = drm_atomic_get_crtc_state(state->state, crtc);
+	if (IS_ERR(crtc_state))
+		return PTR_ERR(crtc_state);
+
+	if (src_w != crtc_w || src_h != crtc_h) {
+		DRM_ERROR("Scale not support!!!\n");
+		return -EINVAL;
+	}
+
+	if (src_x + src_w > fb->width ||
+	    src_y + src_h > fb->height)
+		return -EINVAL;
+
+	if (crtc_x < 0 || crtc_y < 0)
+		return -EINVAL;
+
+	if (crtc_x + crtc_w > crtc_state->adjusted_mode.hdisplay ||
+	    crtc_y + crtc_h > crtc_state->adjusted_mode.vdisplay)
+		return -EINVAL;
+
+	return 0;
+}
+
+static void ade_plane_atomic_update(struct drm_plane *plane,
+				    struct drm_plane_state *old_state)
+{
+	struct drm_plane_state	*state	= plane->state;
+	struct ade_plane *aplane = to_ade_plane(plane);
+
+	ade_update_channel(aplane, state->fb, state->crtc_x, state->crtc_y,
+			   state->crtc_w, state->crtc_h,
+			   state->src_x >> 16, state->src_y >> 16,
+			   state->src_w >> 16, state->src_h >> 16);
+}
+
+static void ade_plane_atomic_disable(struct drm_plane *plane,
+				     struct drm_plane_state *old_state)
+{
+	struct ade_plane *aplane = to_ade_plane(plane);
+
+	ade_disable_channel(aplane);
+}
+
+static const struct drm_plane_helper_funcs ade_plane_helper_funcs = {
+	.prepare_fb = ade_plane_prepare_fb,
+	.cleanup_fb = ade_plane_cleanup_fb,
+	.atomic_check = ade_plane_atomic_check,
+	.atomic_update = ade_plane_atomic_update,
+	.atomic_disable = ade_plane_atomic_disable,
+};
+
+static struct drm_plane_funcs ade_plane_funcs = {
+	.update_plane	= drm_atomic_helper_update_plane,
+	.disable_plane	= drm_atomic_helper_disable_plane,
+	.set_property = drm_atomic_helper_plane_set_property,
+	.destroy = drm_plane_cleanup,
+	.reset = drm_atomic_helper_plane_reset,
+	.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
+};
+
+static int ade_plane_init(struct drm_device *dev, struct ade_plane *aplane,
+			  enum drm_plane_type type)
+{
+	const u32 *fmts;
+	u32 fmts_cnt;
+	int ret = 0;
+
+	/* get  properties */
+	fmts_cnt = ade_get_channel_formats(aplane->ch, &fmts);
+	if (ret)
+		return ret;
+
+	ret = drm_universal_plane_init(dev, &aplane->base, 1, &ade_plane_funcs,
+				       fmts, fmts_cnt, type, NULL);
+	if (ret) {
+		DRM_ERROR("fail to init plane, ch=%d\n", aplane->ch);
+		return ret;
+	}
+
+	drm_plane_helper_add(&aplane->base, &ade_plane_helper_funcs);
+
+	return 0;
+}
+
 static int ade_dts_parse(struct platform_device *pdev, struct ade_hw_ctx *ctx)
 {
 	struct resource *res;
@@ -422,7 +930,10 @@ int ade_drm_init(struct drm_device *dev)
 	struct ade_data *ade;
 	struct ade_hw_ctx *ctx;
 	struct ade_crtc *acrtc;
+	struct ade_plane *aplane;
+	enum drm_plane_type type;
 	int ret;
+	int i;
 
 	ade = devm_kzalloc(dev->dev, sizeof(*ade), GFP_KERNEL);
 	if (!ade) {
@@ -440,6 +951,28 @@ int ade_drm_init(struct drm_device *dev)
 	if (ret)
 		return ret;
 
+	/*
+	 * plane init
+	 * TODO: Now only support primary plane, overlay planes
+	 * need to do.
+	 */
+	for (i = 0; i < ADE_CH_NUM; i++) {
+		aplane = &ade->aplane[i];
+		aplane->ch = i;
+		aplane->ctx = ctx;
+		type = i == PRIMARY_CH ? DRM_PLANE_TYPE_PRIMARY :
+			DRM_PLANE_TYPE_OVERLAY;
+
+		ret = ade_plane_init(dev, aplane, type);
+		if (ret)
+			return ret;
+	}
+
+	/* crtc init */
+	ret = ade_crtc_init(dev, &acrtc->base, &ade->aplane[PRIMARY_CH].base);
+	if (ret)
+		return ret;
+
 	return 0;
 }
 
-- 
1.9.1



From xinliang.liu at linaro.org  Fri Feb  5 19:24:52 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Sat,  6 Feb 2016 11:24:52 +0800
Subject: [PATCH v4 05/11] drm/hisilicon: Add vblank driver for ADE
In-Reply-To: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1454729098-79807-6-git-send-email-xinliang.liu@linaro.org>

Add vblank irq handle.

v4: None.
v3:
- Remove hisi_get_crtc_from_index func.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 62 +++++++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 14 +++++-
 2 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index ff70f1c3dd78..2a12e14ea6ab 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -295,6 +295,59 @@ static void ade_set_medianoc_qos(struct ade_crtc *acrtc)
 	writel(val, reg);
 }
 
+static int ade_enable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+	struct kirin_drm_private *priv = dev->dev_private;
+	struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->base;
+
+	if (!ctx->power_on)
+		(void)ade_power_up(ctx);
+
+	ade_update_bits(base + LDI_INT_EN, FRAME_END_INT_EN_OFST,
+			MASK(1), 1);
+
+	return 0;
+}
+
+static void ade_disable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+	struct kirin_drm_private *priv = dev->dev_private;
+	struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->base;
+
+	if (!ctx->power_on) {
+		DRM_ERROR("power is down! vblank disable fail\n");
+		return;
+	}
+
+	ade_update_bits(base + LDI_INT_EN, FRAME_END_INT_EN_OFST,
+			MASK(1), 0);
+}
+
+static irqreturn_t ade_irq_handler(int irq, void *data)
+{
+	struct ade_crtc *acrtc = data;
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	struct drm_crtc *crtc = &acrtc->base;
+	void __iomem *base = ctx->base;
+	u32 status;
+
+	status = readl(base + LDI_MSK_INT);
+	DRM_DEBUG_VBL("LDI IRQ: status=0x%X\n", status);
+
+	/* vblank irq */
+	if (status & BIT(FRAME_END_INT_EN_OFST)) {
+		ade_update_bits(base + LDI_INT_CLR, FRAME_END_INT_EN_OFST,
+				MASK(1), 1);
+		drm_crtc_handle_vblank(crtc);
+	}
+
+	return IRQ_HANDLED;
+}
+
 static void ade_display_enable(struct ade_crtc *acrtc)
 {
 	struct ade_hw_ctx *ctx = acrtc->ctx;
@@ -973,6 +1026,15 @@ int ade_drm_init(struct drm_device *dev)
 	if (ret)
 		return ret;
 
+	/* vblank irq init */
+	ret = devm_request_irq(dev->dev, ctx->irq, ade_irq_handler,
+			       DRIVER_IRQ_SHARED, dev->driver->name, acrtc);
+	if (ret)
+		return ret;
+	dev->driver->get_vblank_counter = drm_vblank_no_hw_counter;
+	dev->driver->enable_vblank = ade_enable_vblank;
+	dev->driver->disable_vblank = ade_disable_vblank;
+
 	return 0;
 }
 
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 055729c1889c..723888feb760 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -32,6 +32,7 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
 	struct kirin_drm_private *priv = dev->dev_private;
 
+	drm_vblank_cleanup(dev);
 	dc_ops->cleanup(dev);
 	drm_mode_config_cleanup(dev);
 	devm_kfree(dev->dev, priv);
@@ -85,11 +86,22 @@ static int kirin_drm_kms_init(struct drm_device *dev)
 		goto err_dc_cleanup;
 	}
 
+	/* vblank init */
+	ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
+	if (ret) {
+		DRM_ERROR("failed to initialize vblank.\n");
+		goto err_unbind_all;
+	}
+	/* with irq_enabled = true, we can use the vblank feature. */
+	dev->irq_enabled = true;
+
 	/* reset all the states of crtc/plane/encoder/connector */
 	drm_mode_config_reset(dev);
 
 	return 0;
 
+err_unbind_all:
+	component_unbind_all(dev->dev, dev);
 err_dc_cleanup:
 	dc_ops->cleanup(dev);
 err_mode_config_cleanup:
@@ -123,7 +135,7 @@ static int kirin_gem_cma_dumb_create(struct drm_file *file,
 
 static struct drm_driver kirin_drm_driver = {
 	.driver_features	= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
-				  DRIVER_ATOMIC,
+				  DRIVER_ATOMIC | DRIVER_HAVE_IRQ,
 	.fops			= &kirin_drm_fops,
 	.set_busid		= drm_platform_set_busid,
 
-- 
1.9.1



From xinliang.liu at linaro.org  Fri Feb  5 19:24:53 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Sat,  6 Feb 2016 11:24:53 +0800
Subject: [PATCH v4 06/11] drm/hisilicon: Add cma fbdev and hotplug
In-Reply-To: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1454729098-79807-7-git-send-email-xinliang.liu@linaro.org>

Add cma Fbdev, Fbdev is legency and optional, you can enable/disable it by
configuring DRM_FBDEV_EMULATION.
Add hotplug.

v4: None.
v3: None.
v2:
- Use CONFIG_DRM_FBDEV_EMULATION instead of CONFIG_DRM_HISI_FBDEV.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 34 +++++++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  3 +++
 2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 723888feb760..d57b9fa0ce3e 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -23,6 +23,7 @@
 #include <drm/drm_gem_cma_helper.h>
 #include <drm/drm_fb_cma_helper.h>
 #include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc_helper.h>
 
 #include "kirin_drm_drv.h"
 
@@ -32,6 +33,13 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
 	struct kirin_drm_private *priv = dev->dev_private;
 
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+	if (priv->fbdev) {
+		drm_fbdev_cma_fini(priv->fbdev);
+		priv->fbdev = NULL;
+	}
+#endif
+	drm_kms_helper_poll_fini(dev);
 	drm_vblank_cleanup(dev);
 	dc_ops->cleanup(dev);
 	drm_mode_config_cleanup(dev);
@@ -41,8 +49,28 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 	return 0;
 }
 
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+static void kirin_fbdev_output_poll_changed(struct drm_device *dev)
+{
+	struct kirin_drm_private *priv = dev->dev_private;
+
+	if (priv->fbdev) {
+		drm_fbdev_cma_hotplug_event(priv->fbdev);
+	} else {
+		priv->fbdev = drm_fbdev_cma_init(dev, 32,
+				dev->mode_config.num_crtc,
+				dev->mode_config.num_connector);
+		if (IS_ERR(priv->fbdev))
+			priv->fbdev = NULL;
+	}
+}
+#endif
+
 static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
 	.fb_create = drm_fb_cma_create,
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+	.output_poll_changed = kirin_fbdev_output_poll_changed,
+#endif
 	.atomic_check = drm_atomic_helper_check,
 	.atomic_commit = drm_atomic_helper_commit,
 };
@@ -98,6 +126,12 @@ static int kirin_drm_kms_init(struct drm_device *dev)
 	/* reset all the states of crtc/plane/encoder/connector */
 	drm_mode_config_reset(dev);
 
+	/* init kms poll for handling hpd */
+	drm_kms_helper_poll_init(dev);
+
+	/* force detection after connectors init */
+	(void)drm_helper_hpd_irq_event(dev);
+
 	return 0;
 
 err_unbind_all:
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 5a05ad6a81db..1a07caf8e7f4 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -21,6 +21,9 @@ struct kirin_dc_ops {
 
 struct kirin_drm_private {
 	struct drm_crtc *crtc[MAX_CRTC];
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+	struct drm_fbdev_cma *fbdev;
+#endif
 };
 
 extern const struct kirin_dc_ops ade_dc_ops;
-- 
1.9.1



From xinliang.liu at linaro.org  Fri Feb  5 19:24:54 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Sat,  6 Feb 2016 11:24:54 +0800
Subject: [PATCH v4 07/11] drm/hisilicon: Add designware dsi encoder driver
In-Reply-To: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1454729098-79807-8-git-send-email-xinliang.liu@linaro.org>

Add DesignWare MIPI DSI Host Controller v1.02 encoder driver
for hi6220 SoC.

v4: None.
v3:
- Rename file name to dw_drm_dsi.c
- Make encoder type as DRM_MODE_ENCODER_DSI.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
Signed-off-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
Signed-off-by: Andy Green <andy.green at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/Kconfig      |   1 +
 drivers/gpu/drm/hisilicon/kirin/Makefile     |   3 +-
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 743 +++++++++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h |  83 +++
 4 files changed, 829 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h

diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig b/drivers/gpu/drm/hisilicon/kirin/Kconfig
index 3ac4b8edeac1..de0d454c5c13 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Kconfig
+++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
@@ -4,6 +4,7 @@ config DRM_HISI_KIRIN
 	select DRM_KMS_HELPER
 	select DRM_GEM_CMA_HELPER
 	select DRM_KMS_CMA_HELPER
+	select DRM_MIPI_DSI
 	help
 	  Choose this option if you have a hisilicon Kirin chipsets(hi6220).
 	  If M is selected the module will be called kirin-drm.
diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile b/drivers/gpu/drm/hisilicon/kirin/Makefile
index 2a61ab006ddb..5dcd0d4328b6 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Makefile
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -1,4 +1,5 @@
 kirin-drm-y := kirin_drm_drv.o \
-	       kirin_drm_ade.o
+	       kirin_drm_ade.o \
+	       dw_drm_dsi.o
 
 obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
new file mode 100644
index 000000000000..7c9423537b71
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -0,0 +1,743 @@
+/*
+ * DesignWare MIPI DSI Host Controller v1.02 driver
+ *
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * Author:
+ *	Xinliang Liu <z.liuxinliang at hisilicon.com>
+ *	Xinliang Liu <xinliang.liu at linaro.org>
+ *	Xinwei Kong <kong.kongxinwei at hisilicon.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.
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/component.h>
+#include <linux/of_graph.h>
+
+#include <drm/drm_of.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_encoder_slave.h>
+#include <drm/drm_atomic_helper.h>
+
+#include "dw_dsi_reg.h"
+
+#define MAX_TX_ESC_CLK		   (10)
+#define ROUND(x, y) ((x) / (y) + ((x) % (y) * 10 / (y) >= 5 ? 1 : 0))
+#define PHY_REF_CLK_RATE   19200000
+#define PHY_REF_CLK_PERIOD_PS (1000000000 / (PHY_REF_CLK_RATE / 1000))
+
+#define encoder_to_dsi(encoder) \
+	container_of(encoder, struct dw_dsi, encoder)
+#define host_to_dsi(host) \
+	container_of(host, struct dw_dsi, host)
+
+struct mipi_phy_params {
+	u32 clk_t_lpx;
+	u32 clk_t_hs_prepare;
+	u32 clk_t_hs_zero;
+	u32 clk_t_hs_trial;
+	u32 clk_t_wakeup;
+	u32 data_t_lpx;
+	u32 data_t_hs_prepare;
+	u32 data_t_hs_zero;
+	u32 data_t_hs_trial;
+	u32 data_t_ta_go;
+	u32 data_t_ta_get;
+	u32 data_t_wakeup;
+	u32 hstx_ckg_sel;
+	u32 pll_fbd_div5f;
+	u32 pll_fbd_div1f;
+	u32 pll_fbd_2p;
+	u32 pll_enbwt;
+	u32 pll_fbd_p;
+	u32 pll_fbd_s;
+	u32 pll_pre_div1p;
+	u32 pll_pre_p;
+	u32 pll_vco_750M;
+	u32 pll_lpf_rs;
+	u32 pll_lpf_cs;
+	u32 clklp2hs_time;
+	u32 clkhs2lp_time;
+	u32 lp2hs_time;
+	u32 hs2lp_time;
+	u32 clk_to_data_delay;
+	u32 data_to_clk_delay;
+	u32 lane_byte_clk_kHz;
+	u32 clk_division;
+};
+
+struct dsi_hw_ctx {
+	void __iomem *base;
+	struct clk *dsi_cfg_clk;
+};
+
+struct dw_dsi {
+	struct drm_encoder encoder;
+	struct drm_display_mode cur_mode;
+	struct dsi_hw_ctx *ctx;
+	struct mipi_phy_params phy;
+
+	u32 lanes;
+	enum mipi_dsi_pixel_format format;
+	unsigned long mode_flags;
+	bool enable;
+};
+
+struct dsi_data {
+	struct dw_dsi dsi;
+	struct dsi_hw_ctx ctx;
+};
+
+struct dsi_phy_range {
+	u32 min_range_kHz;
+	u32 max_range_kHz;
+	u32 pll_vco_750M;
+	u32 hstx_ckg_sel;
+};
+
+static const struct dsi_phy_range dphy_range_info[] = {
+	{   46875,    62500,   1,    7 },
+	{   62500,    93750,   0,    7 },
+	{   93750,   125000,   1,    6 },
+	{  125000,   187500,   0,    6 },
+	{  187500,   250000,   1,    5 },
+	{  250000,   375000,   0,    5 },
+	{  375000,   500000,   1,    4 },
+	{  500000,   750000,   0,    4 },
+	{  750000,  1000000,   1,    0 },
+	{ 1000000,  1500000,   0,    0 }
+};
+
+static void dsi_get_phy_params(u32 phy_freq_kHz,
+			       struct mipi_phy_params *phy)
+{
+	u32 ui = 0;
+	u32 cfg_clk_ps = PHY_REF_CLK_PERIOD_PS;
+	u32 i = 0;
+	u32 q_pll = 1;
+	u32 m_pll = 0;
+	u32 n_pll = 0;
+	u32 r_pll = 1;
+	u32 m_n = 0;
+	u32 m_n_int = 0;
+	u64 f_kHz;
+	u64 temp;
+	u64 tmp_kHz = phy_freq_kHz;
+
+	do {
+		f_kHz = tmp_kHz;
+
+		/* Find the PLL clock range from the table */
+		for (i = 0; i < ARRAY_SIZE(dphy_range_info); i++)
+			if (f_kHz >= dphy_range_info[i].min_range_kHz &&
+			    f_kHz <= dphy_range_info[i].max_range_kHz)
+				break;
+
+		if (i == ARRAY_SIZE(dphy_range_info)) {
+			DRM_ERROR("%lldkHz out of range\n", f_kHz);
+			return;
+		}
+
+		phy->pll_vco_750M = dphy_range_info[i].pll_vco_750M;
+		phy->hstx_ckg_sel = dphy_range_info[i].hstx_ckg_sel;
+
+		if (phy->hstx_ckg_sel <= 7 &&
+		    phy->hstx_ckg_sel >= 4)
+			q_pll = 0x10 >> (7 - phy->hstx_ckg_sel);
+
+		temp = f_kHz * (u64)q_pll * (u64)cfg_clk_ps;
+		m_n_int = temp / (u64)1000000000;
+		m_n = (temp % (u64)1000000000) / (u64)100000000;
+
+		if (m_n_int % 2 == 0) {
+			if (m_n * 6 >= 50) {
+				n_pll = 2;
+				m_pll = (m_n_int + 1) * n_pll;
+			} else if (m_n * 6 >= 30) {
+				n_pll = 3;
+				m_pll = m_n_int * n_pll + 2;
+			} else {
+				n_pll = 1;
+				m_pll = m_n_int * n_pll;
+			}
+		} else {
+			if (m_n * 6 >= 50) {
+				n_pll = 1;
+				m_pll = (m_n_int + 1) * n_pll;
+			} else if (m_n * 6 >= 30) {
+				n_pll = 1;
+				m_pll = (m_n_int + 1) * n_pll;
+			} else if (m_n * 6 >= 10) {
+				n_pll = 3;
+				m_pll = m_n_int * n_pll + 1;
+			} else {
+				n_pll = 2;
+				m_pll = m_n_int * n_pll;
+			}
+		}
+
+		if (n_pll == 1) {
+			phy->pll_fbd_p = 0;
+			phy->pll_pre_div1p = 1;
+		} else {
+			phy->pll_fbd_p = n_pll;
+			phy->pll_pre_div1p = 0;
+		}
+
+		if (phy->pll_fbd_2p <= 7 && phy->pll_fbd_2p >= 4)
+			r_pll = 0x10 >> (7 - phy->pll_fbd_2p);
+
+		if (m_pll == 2) {
+			phy->pll_pre_p = 0;
+			phy->pll_fbd_s = 0;
+			phy->pll_fbd_div1f = 0;
+			phy->pll_fbd_div5f = 1;
+		} else if (m_pll >= 2 * 2 * r_pll && m_pll <= 2 * 4 * r_pll) {
+			phy->pll_pre_p = m_pll / (2 * r_pll);
+			phy->pll_fbd_s = 0;
+			phy->pll_fbd_div1f = 1;
+			phy->pll_fbd_div5f = 0;
+		} else if (m_pll >= 2 * 5 * r_pll && m_pll <= 2 * 150 * r_pll) {
+			if (((m_pll / (2 * r_pll)) % 2) == 0) {
+				phy->pll_pre_p =
+					(m_pll / (2 * r_pll)) / 2 - 1;
+				phy->pll_fbd_s =
+					(m_pll / (2 * r_pll)) % 2 + 2;
+			} else {
+				phy->pll_pre_p =
+					(m_pll / (2 * r_pll)) / 2;
+				phy->pll_fbd_s =
+					(m_pll / (2 * r_pll)) % 2;
+			}
+			phy->pll_fbd_div1f = 0;
+			phy->pll_fbd_div5f = 0;
+		} else {
+			phy->pll_pre_p = 0;
+			phy->pll_fbd_s = 0;
+			phy->pll_fbd_div1f = 0;
+			phy->pll_fbd_div5f = 1;
+		}
+
+		f_kHz = (u64)1000000000 * (u64)m_pll /
+			((u64)cfg_clk_ps * (u64)n_pll * (u64)q_pll);
+
+		if (f_kHz >= phy_freq_kHz)
+			break;
+
+		tmp_kHz += 10;
+
+	} while (1);
+
+	ui = 1000000 / f_kHz;
+
+	phy->clk_t_lpx = ROUND(50, 8 * ui);
+	phy->clk_t_hs_prepare = ROUND(133, 16 * ui) - 1;
+
+	phy->clk_t_hs_zero = ROUND(262, 8 * ui);
+	phy->clk_t_hs_trial = 2 * (ROUND(60, 8 * ui) - 1);
+	phy->clk_t_wakeup = ROUND(1000000, (cfg_clk_ps / 1000) - 1);
+	if (phy->clk_t_wakeup > 0xff)
+		phy->clk_t_wakeup = 0xff;
+	phy->data_t_wakeup = phy->clk_t_wakeup;
+	phy->data_t_lpx = phy->clk_t_lpx;
+	phy->data_t_hs_prepare = ROUND(125 + 10 * ui, 16 * ui) - 1;
+	phy->data_t_hs_zero = ROUND(105 + 6 * ui, 8 * ui);
+	phy->data_t_hs_trial = 2 * (ROUND(60 + 4 * ui, 8 * ui) - 1);
+	phy->data_t_ta_go = 3;
+	phy->data_t_ta_get = 4;
+
+	phy->pll_enbwt = 1;
+	phy->clklp2hs_time = ROUND(407, 8 * ui) + 12;
+	phy->clkhs2lp_time = ROUND(105 + 12 * ui, 8 * ui);
+	phy->lp2hs_time = ROUND(240 + 12 * ui, 8 * ui) + 1;
+	phy->hs2lp_time = phy->clkhs2lp_time;
+	phy->clk_to_data_delay = 1 + phy->clklp2hs_time;
+	phy->data_to_clk_delay = ROUND(60 + 52 * ui, 8 * ui) +
+				phy->clkhs2lp_time;
+
+	phy->lane_byte_clk_kHz = f_kHz / 8;
+	phy->clk_division = phy->lane_byte_clk_kHz / MAX_TX_ESC_CLK;
+	if (phy->lane_byte_clk_kHz % MAX_TX_ESC_CLK)
+		phy->clk_division++;
+}
+
+static u32 dsi_get_dpi_color_coding(enum mipi_dsi_pixel_format format)
+{
+	u32 val;
+
+	/* TODO: only support RGB888 now, to support more */
+	switch (format) {
+	case MIPI_DSI_FMT_RGB888:
+		val = DSI_24BITS_1;
+		break;
+	default:
+		val = DSI_24BITS_1;
+		break;
+	}
+
+	return val;
+}
+
+/*
+ * dsi phy reg write function
+ */
+static void dsi_phy_tst_set(void __iomem *base, u32 reg, u32 val)
+{
+	writel(reg, base + PHY_TST_CTRL1);
+	/* reg addr written at first */
+	wmb();
+	writel(0x02, base + PHY_TST_CTRL0);
+	/* cmd1 sent for write */
+	wmb();
+	writel(0x00, base + PHY_TST_CTRL0);
+	/* cmd2 sent for write */
+	wmb();
+	writel(val, base + PHY_TST_CTRL1);
+	/* Then write data */
+	wmb();
+	writel(0x02, base + PHY_TST_CTRL0);
+	/* cmd2 sent for write */
+	wmb();
+	writel(0x00, base + PHY_TST_CTRL0);
+}
+
+static void dsi_set_mipi_phy(void __iomem *base,
+			     struct mipi_phy_params *phy,
+			     u32 lanes)
+{
+	u32 delay_count;
+	u32 val;
+	u32 i;
+
+	/* set lanes value */
+	val = (lanes - 1) | (PHY_STOP_WAIT_TIME << 8);
+	writel(val, base + PHY_IF_CFG);
+
+	/* set phy clk division */
+	val = readl(base + CLKMGR_CFG) | phy->clk_division;
+	writel(val, base + CLKMGR_CFG);
+
+	/* clean up phy set param */
+	writel(0, base + PHY_RSTZ);
+	writel(0, base + PHY_TST_CTRL0);
+	writel(1, base + PHY_TST_CTRL0);
+	writel(0, base + PHY_TST_CTRL0);
+
+	/* clock lane Timing control - TLPX */
+	dsi_phy_tst_set(base, 0x10010, phy->clk_t_lpx);
+
+	/* clock lane Timing control - THS-PREPARE */
+	dsi_phy_tst_set(base, 0x10011, phy->clk_t_hs_prepare);
+
+	/* clock lane Timing control - THS-ZERO */
+	dsi_phy_tst_set(base, 0x10012, phy->clk_t_hs_zero);
+
+	/* clock lane Timing control - THS-TRAIL */
+	dsi_phy_tst_set(base, 0x10013, phy->clk_t_hs_trial);
+
+	/* clock lane Timing control - TWAKEUP */
+	dsi_phy_tst_set(base, 0x10014, phy->clk_t_wakeup);
+
+	/* data lane */
+	for (i = 0; i < lanes; i++) {
+		/* Timing control - TLPX */
+		dsi_phy_tst_set(base, 0x10020 + (i << 4), phy->data_t_lpx);
+
+		/* Timing control - THS-PREPARE */
+		dsi_phy_tst_set(base, 0x10021 + (i << 4),
+				phy->data_t_hs_prepare);
+
+		/* Timing control - THS-ZERO */
+		dsi_phy_tst_set(base, 0x10022 + (i << 4), phy->data_t_hs_zero);
+
+		/* Timing control - THS-TRAIL */
+		dsi_phy_tst_set(base, 0x10023 + (i << 4), phy->data_t_hs_trial);
+
+		/* Timing control - TTA-GO */
+		dsi_phy_tst_set(base, 0x10024 + (i << 4), phy->data_t_ta_go);
+
+		/* Timing control - TTA-GET */
+		dsi_phy_tst_set(base, 0x10025 + (i << 4), phy->data_t_ta_get);
+
+		/* Timing control - TWAKEUP */
+		dsi_phy_tst_set(base, 0x10026 + (i << 4), phy->data_t_wakeup);
+	}
+
+	/* physical configuration I */
+	dsi_phy_tst_set(base, 0x10060, phy->hstx_ckg_sel);
+
+	/* physical configuration pll II */
+	val = (phy->pll_fbd_div5f << 5) + (phy->pll_fbd_div1f << 4) +
+				(phy->pll_fbd_2p << 1) + phy->pll_enbwt;
+	dsi_phy_tst_set(base, 0x10063, val);
+
+	/* physical configuration pll II */
+	dsi_phy_tst_set(base, 0x10064, phy->pll_fbd_p);
+
+	/* physical configuration pll III */
+	dsi_phy_tst_set(base, 0x10065, phy->pll_fbd_s);
+
+	/* physical configuration pll IV */
+	val = (phy->pll_pre_div1p << 7) + phy->pll_pre_p;
+	dsi_phy_tst_set(base, 0x10066, val);
+
+	/* physical configuration pll V */
+	val = (phy->pll_vco_750M << 4) + (phy->pll_lpf_rs << 2) +
+					phy->pll_lpf_cs + BIT(5);
+	dsi_phy_tst_set(base, 0x10067, val);
+
+	writel(BIT(2), base + PHY_RSTZ);
+	udelay(1);
+	writel(BIT(2) | BIT(0), base + PHY_RSTZ);
+	udelay(1);
+	writel(BIT(2) | BIT(1) | BIT(0), base + PHY_RSTZ);
+	usleep_range(1000, 1500);
+
+	/* wait for phy's clock ready */
+	delay_count = 100;
+	while (delay_count--) {
+		val = readl(base +  PHY_STATUS);
+		if ((BIT(0) | BIT(2)) & val)
+			break;
+
+		udelay(1);
+	}
+
+	if (!delay_count)
+		DRM_INFO("phylock and phystopstateclklane is not ready.\n");
+
+	/* set lp and hs switching params
+	 */
+	dw_update_bits(base + PHY_TMR_CFG, 24, MASK(8), phy->hs2lp_time);
+	dw_update_bits(base + PHY_TMR_CFG, 16, MASK(8), phy->lp2hs_time);
+	dw_update_bits(base + PHY_TMR_LPCLK_CFG, 16, MASK(10),
+		       phy->clkhs2lp_time);
+	dw_update_bits(base + PHY_TMR_LPCLK_CFG, 0, MASK(10),
+		       phy->clklp2hs_time);
+	dw_update_bits(base + CLK_DATA_TMR_CFG, 8, MASK(8),
+		       phy->data_to_clk_delay);
+	dw_update_bits(base + CLK_DATA_TMR_CFG, 0, MASK(8),
+		       phy->clk_to_data_delay);
+}
+
+static void dsi_set_mode_timing(void __iomem *base,
+				u32 lane_byte_clk_kHz,
+				struct drm_display_mode *mode,
+				enum mipi_dsi_pixel_format format)
+{
+	u32 hfp, hbp, hsw, vfp, vbp, vsw;
+	u32 hline_time;
+	u32 hsa_time;
+	u32 hbp_time;
+	u32 pixel_clk_kHz;
+	int htot, vtot;
+	u32 val;
+	u64 tmp;
+
+	/* DSI color coding setting */
+	val = dsi_get_dpi_color_coding(format);
+	writel(val, base + DPI_COLOR_CODING);
+
+	/* DSI format and pol setting */
+	val = (mode->flags & DRM_MODE_FLAG_NHSYNC ? 1 : 0) << 2;
+	val |= (mode->flags & DRM_MODE_FLAG_NVSYNC ? 1 : 0) << 1;
+	writel(val, base +  DPI_CFG_POL);
+
+	/*
+	 * The DSI IP accepts vertical timing using lines as normal,
+	 * but horizontal timing is a mixture of pixel-clocks for the
+	 * active region and byte-lane clocks for the blanking-related
+	 * timings.  hfp is specified as the total hline_time in byte-
+	 * lane clocks minus hsa, hbp and active.
+	 */
+	pixel_clk_kHz = mode->clock;
+	htot = mode->htotal;
+	vtot = mode->vtotal;
+	hfp = mode->hsync_start - mode->hdisplay;
+	hbp = mode->htotal - mode->hsync_end;
+	hsw = mode->hsync_end - mode->hsync_start;
+	vfp = mode->vsync_start - mode->vdisplay;
+	vbp = mode->vtotal - mode->vsync_end;
+	vsw = mode->vsync_end - mode->vsync_start;
+	if (vsw > 15) {
+		DRM_DEBUG_DRIVER("vsw exceeded 15\n");
+		vsw = 15;
+	}
+
+	hsa_time = (hsw * lane_byte_clk_kHz) / pixel_clk_kHz;
+	hbp_time = (hbp * lane_byte_clk_kHz) / pixel_clk_kHz;
+	tmp = (u64)htot * (u64)lane_byte_clk_kHz;
+	hline_time = DIV_ROUND_UP(tmp, pixel_clk_kHz);
+
+	/* all specified in byte-lane clocks */
+	writel(hsa_time, base + VID_HSA_TIME);
+	writel(hbp_time, base + VID_HBP_TIME);
+	writel(hline_time, base + VID_HLINE_TIME);
+
+	writel(vsw, base + VID_VSA_LINES);
+	writel(vbp, base + VID_VBP_LINES);
+	writel(vfp, base + VID_VFP_LINES);
+	writel(mode->vdisplay, base + VID_VACTIVE_LINES);
+	writel(mode->hdisplay, base + VID_PKT_SIZE);
+
+	DRM_DEBUG_DRIVER("htot=%d, hfp=%d, hbp=%d, hsw=%d\n",
+			 htot, hfp, hbp, hsw);
+	DRM_DEBUG_DRIVER("vtol=%d, vfp=%d, vbp=%d, vsw=%d\n",
+			 vtot, vfp, vbp, vsw);
+	DRM_DEBUG_DRIVER("hsa_time=%d, hbp_time=%d, hline_time=%d\n",
+			 hsa_time, hbp_time, hline_time);
+}
+
+static void dsi_set_video_mode_type(void __iomem *base,
+				    unsigned long flags)
+{
+	u32 val;
+	u32 mode_mask = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+		MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
+	u32 non_burst_sync_pulse = MIPI_DSI_MODE_VIDEO |
+		MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
+	u32 non_burst_sync_event = MIPI_DSI_MODE_VIDEO;
+
+	/*
+	 * choose video type
+	 */
+	if ((flags & mode_mask) == non_burst_sync_pulse)
+		val = DSI_NON_BURST_SYNC_PULSES;
+	else if ((flags & mode_mask) == non_burst_sync_event)
+		val = DSI_NON_BURST_SYNC_EVENTS;
+	else
+		val = DSI_BURST_SYNC_PULSES_1;
+
+	writel(val, base + VID_MODE_CFG);
+}
+
+static void dsi_mipi_init(struct dw_dsi *dsi)
+{
+	struct dsi_hw_ctx *ctx = dsi->ctx;
+	struct mipi_phy_params *phy = &dsi->phy;
+	struct drm_display_mode *mode = &dsi->cur_mode;
+	u32 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
+	void __iomem *base = ctx->base;
+	u32 dphy_freq_kHz;
+
+	/* count phy params */
+	dphy_freq_kHz = mode->clock * bpp / dsi->lanes;
+	dsi_get_phy_params(dphy_freq_kHz, phy);
+
+	/* reset Core */
+	writel(0, base + PWR_UP);
+
+	/* set phy params */
+	dsi_set_mipi_phy(base, phy, dsi->lanes);
+
+	/* set dsi mode */
+	dsi_set_mode_timing(base, phy->lane_byte_clk_kHz, mode, dsi->format);
+
+	/* set video mode type and lp */
+	dsi_set_video_mode_type(base, dsi->mode_flags);
+
+	/* dsi wake up */
+	writel(DSI_VIDEO_MODE, base + MODE_CFG);
+	writel(BIT(0), base + LPCLK_CTRL);
+	writel(BIT(0), base + PWR_UP);
+
+	DRM_DEBUG_DRIVER("lanes=%d, pixel_clk=%d kHz, bytes_freq=%d kHz\n",
+			 dsi->lanes, mode->clock, phy->lane_byte_clk_kHz);
+}
+
+static void dsi_encoder_disable(struct drm_encoder *encoder)
+{
+	struct dw_dsi *dsi = encoder_to_dsi(encoder);
+	struct dsi_hw_ctx *ctx = dsi->ctx;
+	void __iomem *base = ctx->base;
+
+	if (!dsi->enable)
+		return;
+
+	writel(0, base + PWR_UP);
+	writel(0, base + LPCLK_CTRL);
+	writel(0, base + PHY_RSTZ);
+	clk_disable_unprepare(ctx->dsi_cfg_clk);
+
+	dsi->enable = false;
+}
+
+static void dsi_encoder_enable(struct drm_encoder *encoder)
+{
+	struct dw_dsi *dsi = encoder_to_dsi(encoder);
+	struct dsi_hw_ctx *ctx = dsi->ctx;
+	int ret;
+
+	if (dsi->enable)
+		return;
+
+	/* mipi dphy clock enable */
+	ret = clk_prepare_enable(ctx->dsi_cfg_clk);
+	if (ret) {
+		DRM_ERROR("fail to enable dsi_cfg_clk: %d\n", ret);
+		return;
+	}
+
+	dsi_mipi_init(dsi);
+
+	dsi->enable = true;
+}
+
+static void dsi_encoder_mode_set(struct drm_encoder *encoder,
+				 struct drm_display_mode *mode,
+				 struct drm_display_mode *adj_mode)
+{
+	struct dw_dsi *dsi = encoder_to_dsi(encoder);
+
+	drm_mode_copy(&dsi->cur_mode, adj_mode);
+}
+
+static int dsi_encoder_atomic_check(struct drm_encoder *encoder,
+				    struct drm_crtc_state *crtc_state,
+				    struct drm_connector_state *conn_state)
+{
+	/* do nothing */
+	return 0;
+}
+
+static const struct drm_encoder_helper_funcs dw_encoder_helper_funcs = {
+	.atomic_check	= dsi_encoder_atomic_check,
+	.mode_set	= dsi_encoder_mode_set,
+	.enable		= dsi_encoder_enable,
+	.disable	= dsi_encoder_disable
+};
+
+static const struct drm_encoder_funcs dw_encoder_funcs = {
+	.destroy = drm_encoder_cleanup,
+};
+
+static int dw_drm_encoder_init(struct device *dev,
+			       struct drm_device *drm_dev,
+			       struct drm_encoder *encoder)
+{
+	int ret;
+	u32 crtc_mask = drm_of_find_possible_crtcs(drm_dev, dev->of_node);
+
+	if (!crtc_mask) {
+		DRM_ERROR("failed to find crtc mask\n");
+		return -EINVAL;
+	}
+
+	encoder->possible_crtcs = crtc_mask;
+	ret = drm_encoder_init(drm_dev, encoder, &dw_encoder_funcs,
+			       DRM_MODE_ENCODER_DSI, NULL);
+	if (ret) {
+		DRM_ERROR("failed to init dsi encoder\n");
+		return ret;
+	}
+
+	drm_encoder_helper_add(encoder, &dw_encoder_helper_funcs);
+
+	return 0;
+}
+
+static int dsi_bind(struct device *dev, struct device *master, void *data)
+{
+	struct dsi_data *ddata = dev_get_drvdata(dev);
+	struct dw_dsi *dsi = &ddata->dsi;
+	struct drm_device *drm_dev = data;
+	int ret;
+
+	ret = dw_drm_encoder_init(dev, drm_dev, &dsi->encoder);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static void dsi_unbind(struct device *dev, struct device *master, void *data)
+{
+	/* do nothing */
+}
+
+static const struct component_ops dsi_ops = {
+	.bind	= dsi_bind,
+	.unbind	= dsi_unbind,
+};
+
+static int dsi_parse_dt(struct platform_device *pdev, struct dw_dsi *dsi)
+{
+	struct dsi_hw_ctx *ctx = dsi->ctx;
+	struct resource *res;
+
+	ctx->dsi_cfg_clk = devm_clk_get(&pdev->dev, "pclk_dsi");
+	if (IS_ERR(ctx->dsi_cfg_clk)) {
+		DRM_ERROR("failed to get dsi plck clock\n");
+		return PTR_ERR(ctx->dsi_cfg_clk);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	ctx->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(ctx->base)) {
+		DRM_ERROR("failed to remap dsi io region\n");
+		return PTR_ERR(ctx->base);
+	}
+
+	return 0;
+}
+
+static int dsi_probe(struct platform_device *pdev)
+{
+	struct dsi_data *data;
+	struct dw_dsi *dsi;
+	struct dsi_hw_ctx *ctx;
+	int ret;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		DRM_ERROR("failed to allocate dsi data.\n");
+		return -ENOMEM;
+	}
+	dsi = &data->dsi;
+	ctx = &data->ctx;
+	dsi->ctx = ctx;
+
+	ret = dsi_parse_dt(pdev, dsi);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, data);
+
+	return component_add(&pdev->dev, &dsi_ops);
+}
+
+static int dsi_remove(struct platform_device *pdev)
+{
+	component_del(&pdev->dev, &dsi_ops);
+
+	return 0;
+}
+
+static const struct of_device_id dsi_of_match[] = {
+	{.compatible = "hisilicon,hi6220-dsi"},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, dsi_of_match);
+
+static struct platform_driver dsi_driver = {
+	.probe = dsi_probe,
+	.remove = dsi_remove,
+	.driver = {
+		.name = "dw-dsi",
+		.of_match_table = dsi_of_match,
+	},
+};
+
+module_platform_driver(dsi_driver);
+
+MODULE_AUTHOR("Xinliang Liu <xinliang.liu at linaro.org>");
+MODULE_AUTHOR("Xinliang Liu <z.liuxinliang at hisilicon.com>");
+MODULE_AUTHOR("Xinwei Kong <kong.kongxinwei at hisilicon.com>");
+MODULE_DESCRIPTION("DesignWare MIPI DSI Host Controller v1.02 driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h b/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
new file mode 100644
index 000000000000..d3d44b7d2098
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
@@ -0,0 +1,83 @@
+/*
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __DW_DSI_REG_H__
+#define __DW_DSI_REG_H__
+
+#define MASK(x)				(BIT(x) - 1)
+
+/*
+ * regs
+ */
+#define  PWR_UP                  0x04  /* Core power-up */
+#define  PHY_IF_CFG              0xA4  /* D-PHY interface configuration */
+#define  CLKMGR_CFG              0x08  /* the internal clock dividers */
+#define  PHY_RSTZ                0xA0  /* D-PHY reset control */
+#define  PHY_TST_CTRL0           0xB4  /* D-PHY test interface control 0 */
+#define  PHY_TST_CTRL1           0xB8  /* D-PHY test interface control 1 */
+#define  DPI_VCID                0x0C  /* DPI virtual channel id */
+#define  DPI_COLOR_CODING        0x10  /* DPI color coding */
+#define  DPI_CFG_POL             0x14  /* DPI polarity configuration */
+#define  VID_HSA_TIME            0x48  /* Horizontal Sync Active time */
+#define  VID_HBP_TIME            0x4C  /* Horizontal Back Porch time */
+#define  VID_HLINE_TIME          0x50  /* Line time */
+#define  VID_VSA_LINES           0x54  /* Vertical Sync Active period */
+#define  VID_VBP_LINES           0x58  /* Vertical Back Porch period */
+#define  VID_VFP_LINES           0x5C  /* Vertical Front Porch period */
+#define  VID_VACTIVE_LINES       0x60  /* Vertical resolution */
+#define  VID_PKT_SIZE            0x3C  /* Video packet size */
+#define  VID_MODE_CFG            0x38  /* Video mode configuration */
+#define  DPI_LP_CMD_TIM          0x18  /* Low-power command timing config */
+#define  PHY_TMR_CFG             0x9C  /* Data lanes timing configuration */
+#define  BTA_TO_CNT              0x8C  /* Response timeout definition */
+#define  PHY_TMR_LPCLK_CFG       0x98  /* clock lane timing configuration */
+#define  CLK_DATA_TMR_CFG        0xCC
+#define  LPCLK_CTRL              0x94  /* Low-power in clock lane */
+#define  PCKHDL_CFG              0x2C  /* Packet handler configuration */
+#define  EDPI_CMD_SIZE           0x64  /* Size for eDPI packets */
+#define  MODE_CFG                0x34  /* Video or Command mode selection */
+#define  PHY_STATUS              0xB0  /* D-PHY PPI status interface */
+
+#define	PHY_STOP_WAIT_TIME       0x30
+
+/*
+ * regs relevant enum
+ */
+enum dpi_color_coding {
+	DSI_24BITS_1 = 5,
+};
+
+enum dsi_video_mode_type {
+	DSI_NON_BURST_SYNC_PULSES = 0,
+	DSI_NON_BURST_SYNC_EVENTS,
+	DSI_BURST_SYNC_PULSES_1,
+	DSI_BURST_SYNC_PULSES_2
+};
+
+enum dsi_work_mode {
+	DSI_VIDEO_MODE = 0,
+	DSI_COMMAND_MODE
+};
+
+/*
+ * Register Write/Read Helper functions
+ */
+static inline void dw_update_bits(void __iomem *addr, u32 bit_start,
+				  u32 mask, u32 val)
+{
+	u32 tmp, orig;
+
+	orig = readl(addr);
+	tmp = orig & ~(mask << bit_start);
+	tmp |= (val & mask) << bit_start;
+	writel(tmp, addr);
+}
+
+#endif /* __DW_DRM_DSI_H__ */
-- 
1.9.1



From xinliang.liu at linaro.org  Fri Feb  5 19:24:56 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Sat,  6 Feb 2016 11:24:56 +0800
Subject: [PATCH v4 09/11] drm/hisilicon: Add support for external bridge
In-Reply-To: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1454729098-79807-10-git-send-email-xinliang.liu@linaro.org>

Add support for external HDMI bridge.

v4: None.
v3:
- Fix a typo: s/exteranl/external.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 52 ++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index 2837af01e935..1342d84d7c68 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -79,6 +79,7 @@ struct dsi_hw_ctx {
 
 struct dw_dsi {
 	struct drm_encoder encoder;
+	struct drm_bridge *bridge;
 	struct mipi_dsi_host host;
 	struct drm_display_mode cur_mode;
 	struct dsi_hw_ctx *ctx;
@@ -688,6 +689,25 @@ static int dsi_host_init(struct device *dev, struct dw_dsi *dsi)
 	return 0;
 }
 
+static int dsi_bridge_init(struct drm_device *dev, struct dw_dsi *dsi)
+{
+	struct drm_encoder *encoder = &dsi->encoder;
+	struct drm_bridge *bridge = dsi->bridge;
+	int ret;
+
+	/* associate the bridge to dsi encoder */
+	encoder->bridge = bridge;
+	bridge->encoder = encoder;
+
+	ret = drm_bridge_attach(dev, bridge);
+	if (ret) {
+		DRM_ERROR("failed to attach external bridge\n");
+		return ret;
+	}
+
+	return 0;
+}
+
 static int dsi_bind(struct device *dev, struct device *master, void *data)
 {
 	struct dsi_data *ddata = dev_get_drvdata(dev);
@@ -703,6 +723,10 @@ static int dsi_bind(struct device *dev, struct device *master, void *data)
 	if (ret)
 		return ret;
 
+	ret = dsi_bridge_init(drm_dev, dsi);
+	if (ret)
+		return ret;
+
 	return 0;
 }
 
@@ -719,8 +743,36 @@ static const struct component_ops dsi_ops = {
 static int dsi_parse_dt(struct platform_device *pdev, struct dw_dsi *dsi)
 {
 	struct dsi_hw_ctx *ctx = dsi->ctx;
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *endpoint, *bridge_node;
+	struct drm_bridge *bridge;
 	struct resource *res;
 
+	/*
+	 * Get the endpoint node. In our case, dsi has one output port1
+	 * to which the external HDMI bridge is connected.
+	 */
+	endpoint = of_graph_get_endpoint_by_regs(np, 1, -1);
+	if (!endpoint) {
+		DRM_ERROR("no valid endpoint node\n");
+		return -ENODEV;
+	}
+	of_node_put(endpoint);
+
+	bridge_node = of_graph_get_remote_port_parent(endpoint);
+	if (!bridge_node) {
+		DRM_ERROR("no valid bridge node\n");
+		return -ENODEV;
+	}
+	of_node_put(bridge_node);
+
+	bridge = of_drm_find_bridge(bridge_node);
+	if (!bridge) {
+		DRM_INFO("wait for external HDMI bridge driver.\n");
+		return -EPROBE_DEFER;
+	}
+	dsi->bridge = bridge;
+
 	ctx->dsi_cfg_clk = devm_clk_get(&pdev->dev, "pclk_dsi");
 	if (IS_ERR(ctx->dsi_cfg_clk)) {
 		DRM_ERROR("failed to get dsi plck clock\n");
-- 
1.9.1



From xinliang.liu at linaro.org  Fri Feb  5 19:24:57 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Sat,  6 Feb 2016 11:24:57 +0800
Subject: [PATCH v4 10/11] MAINTAINERS: Add maintainer for hisilicon DRM driver
In-Reply-To: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1454729098-79807-11-git-send-email-xinliang.liu@linaro.org>

Add maintainer and reviewer for hisilicon DRM driver.

v4:
- Add Chen Feng <puck.chen at hisilicon.com> as Designated reviewer.
v3: First version.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 MAINTAINERS | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 30aca4aa5467..730ebc571edf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3777,6 +3777,16 @@ S:	Maintained
 F:	drivers/gpu/drm/gma500
 F:	include/drm/gma500*
 
+DRM DRIVERS FOR HISILICON
+M:	Xinliang Liu <z.liuxinliang at hisilicon.com>
+R:	Xinwei Kong <kong.kongxinwei at hisilicon.com>
+R:	Chen Feng <puck.chen at hisilicon.com>
+L:	dri-devel at lists.freedesktop.org
+T:	git git://github.com/xin3liang/linux.git
+S:	Maintained
+F:	drivers/gpu/drm/hisilicon
+F:	Documentation/devicetree/bindings/display/hisilicon
+
 DRM DRIVERS FOR NVIDIA TEGRA
 M:	Thierry Reding <thierry.reding at gmail.com>
 M:	Terje Bergstr??m <tbergstrom at nvidia.com>
-- 
1.9.1



From xinliang.liu at linaro.org  Fri Feb  5 19:24:58 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Sat,  6 Feb 2016 11:24:58 +0800
Subject: [PATCH v4 11/11] arm64: dts: hisilicon: Add display subsystem DT
 nodes for hi6220
In-Reply-To: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1454729098-79807-12-git-send-email-xinliang.liu@linaro.org>

Add ade, dsi and adv7533 DT nodes for hikey board.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 44 +++++++++++++++++++++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi      | 53 ++++++++++++++++++++++++++
 2 files changed, 97 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 818525197508..5c3557c8e59b 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -39,3 +39,47 @@
 &uart3 {
 	label = "LS-UART1";
 };
+
+&ade {
+	status = "okay";
+};
+
+&dsi {
+	status = "ok";
+
+	ports {
+		 /* 1 for output port */
+		port at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+
+			/* 0 for bridge, other value for panel */
+			dsi_out0: endpoint at 0 {
+				reg = <0>;
+				remote-endpoint = <&adv7533_in>;
+			};
+		};
+	};
+};
+
+&i2c2 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "ok";
+
+	adv7533: adv7533 at 39 {
+		compatible = "adi,adv7533";
+		reg = <0x39>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <1 2>;
+		pd-gpio = <&gpio0 4 0>;
+		adi,dsi-lanes = <4>;
+
+		port {
+			adv7533_in: endpoint {
+				remote-endpoint = <&dsi_out0>;
+			};
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index ad1f1ebcb05c..e50e81cdd242 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -209,5 +209,58 @@
 			clock-names = "uartclk", "apb_pclk";
 			status = "disabled";
 		};
+
+		ade: ade at f4100000 {
+			compatible = "hisilicon,hi6220-ade";
+			reg = <0x0 0xf4100000 0x0 0x7800>,
+			      <0x0 0xf4410000 0x0 0x1000>,
+			      <0x0 0xf4520000 0x0 0x1000>;
+			reg-names = "ade_base",
+				    "media_base",
+				    "media_noc_base";
+
+			interrupts = <0 115 4>; /* ldi interrupt */
+
+			clocks = <&media_ctrl HI6220_ADE_CORE>,
+				 <&media_ctrl HI6220_CODEC_JPEG>,
+				 <&media_ctrl HI6220_ADE_PIX_SRC>;
+			/*clock name*/
+			clock-names  = "clk_ade_core",
+				       "clk_codec_jpeg",
+				       "clk_ade_pix";
+
+			assigned-clocks = <&media_ctrl HI6220_ADE_CORE>,
+				<&media_ctrl HI6220_CODEC_JPEG>;
+			assigned-clock-rates = <360000000>, <288000000>;
+			dma-coherent;
+			status = "disabled";
+
+			port {
+				ade_out: endpoint {
+					remote-endpoint = <&dsi_in>;
+				};
+			};
+		};
+
+		dsi: dsi at f4107800 {
+			compatible = "hisilicon,hi6220-dsi";
+			reg = <0x0 0xf4107800 0x0 0x100>;
+			clocks = <&media_ctrl  HI6220_DSI_PCLK>;
+			clock-names = "pclk_dsi";
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				/* 0 for input port */
+				port at 0 {
+					reg = <0>;
+					dsi_in: endpoint {
+						remote-endpoint = <&ade_out>;
+					};
+				};
+			};
+		};
 	};
 };
-- 
1.9.1



From xinliang.liu at linaro.org  Fri Feb  5 19:24:55 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Sat,  6 Feb 2016 11:24:55 +0800
Subject: [PATCH v4 08/11] drm/hisilicon: Add designware dsi host driver
In-Reply-To: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1454729098-79807-9-git-send-email-xinliang.liu@linaro.org>

Add DesignWare dsi host driver for hi6220 SoC.

v4: None.
v3: None.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 50 ++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index 7c9423537b71..2837af01e935 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -79,6 +79,7 @@ struct dsi_hw_ctx {
 
 struct dw_dsi {
 	struct drm_encoder encoder;
+	struct mipi_dsi_host host;
 	struct drm_display_mode cur_mode;
 	struct dsi_hw_ctx *ctx;
 	struct mipi_phy_params phy;
@@ -642,6 +643,51 @@ static int dw_drm_encoder_init(struct device *dev,
 	return 0;
 }
 
+static int dsi_host_attach(struct mipi_dsi_host *host,
+			   struct mipi_dsi_device *mdsi)
+{
+	struct dw_dsi *dsi = host_to_dsi(host);
+
+	if (mdsi->lanes < 1 || mdsi->lanes > 4) {
+		DRM_ERROR("dsi device params invalid\n");
+		return -EINVAL;
+	}
+
+	dsi->lanes = mdsi->lanes;
+	dsi->format = mdsi->format;
+	dsi->mode_flags = mdsi->mode_flags;
+
+	return 0;
+}
+
+static int dsi_host_detach(struct mipi_dsi_host *host,
+			   struct mipi_dsi_device *mdsi)
+{
+	/* do nothing */
+	return 0;
+}
+
+static const struct mipi_dsi_host_ops dsi_host_ops = {
+	.attach = dsi_host_attach,
+	.detach = dsi_host_detach,
+};
+
+static int dsi_host_init(struct device *dev, struct dw_dsi *dsi)
+{
+	struct mipi_dsi_host *host = &dsi->host;
+	int ret;
+
+	host->dev = dev;
+	host->ops = &dsi_host_ops;
+	ret = mipi_dsi_host_register(host);
+	if (ret) {
+		DRM_ERROR("failed to register dsi host\n");
+		return ret;
+	}
+
+	return 0;
+}
+
 static int dsi_bind(struct device *dev, struct device *master, void *data)
 {
 	struct dsi_data *ddata = dev_get_drvdata(dev);
@@ -653,6 +699,10 @@ static int dsi_bind(struct device *dev, struct device *master, void *data)
 	if (ret)
 		return ret;
 
+	ret = dsi_host_init(dev, dsi);
+	if (ret)
+		return ret;
+
 	return 0;
 }
 
-- 
1.9.1



From rogershimizu at gmail.com  Fri Feb  5 21:59:50 2016
From: rogershimizu at gmail.com (Roger Shimizu)
Date: Sat,  6 Feb 2016 14:59:50 +0900
Subject: [PATCH v2 0/3] fix and new support for orion5x based linkstation
In-Reply-To: <1454689998-9579-1-git-send-email-rogershimizu@gmail.com>
References: <1454689998-9579-1-git-send-email-rogershimizu@gmail.com>
Message-ID: <1454738393-14114-1-git-send-email-rogershimizu@gmail.com>

Dear Orion5x Maintainer,

Here're fix and new support for orion5x based linkstation devices.

Firstly, it add the missing mtd flash support, which I consider a fix
and can be backported to stable kernels, so I made the patch explicit.

Second, like the changes I made for kirkwood based linkstation DT,
I split the orion5x-linkstation-lswtgl.dts file into common and device
specific part, in order to support more devices.

Third, so there's a new device.

Hope this can be kindly accepted. Thank you!

Changes in v2:
- add "Fixes" tag for patch 1/3
- add "mvebu-" prefix to common .dtsi file to share between orion5x
  and kirkwood, which address comment from Andrew Lunn
- add "Reviewed-by" tag from Andrew Lunn for all 3 patches

Cheers,
Roger

Roger Shimizu (3):
  ARM: dts: orion5x: fix the missing mtd flash on linkstation lswtgl
  ARM: dts: orion5x: split linkstation lswtgl into common and device
    parts
  ARM: dts: orion5x: add device tree for buffalo linkstation ls-gl

 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/mvebu-linkstation-fan.dtsi       |  72 +++++++
 .../boot/dts/mvebu-linkstation-gpio-simple.dtsi    | 105 ++++++++++
 arch/arm/boot/dts/orion5x-linkstation-lsgl.dts     |  87 +++++++++
 arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts   | 214 +++++----------------
 arch/arm/boot/dts/orion5x-linkstation.dtsi         | 180 +++++++++++++++++
 6 files changed, 491 insertions(+), 168 deletions(-)
 create mode 100644 arch/arm/boot/dts/mvebu-linkstation-fan.dtsi
 create mode 100644 arch/arm/boot/dts/mvebu-linkstation-gpio-simple.dtsi
 create mode 100644 arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
 create mode 100644 arch/arm/boot/dts/orion5x-linkstation.dtsi

-- 
2.1.4



From rogershimizu at gmail.com  Fri Feb  5 21:59:51 2016
From: rogershimizu at gmail.com (Roger Shimizu)
Date: Sat,  6 Feb 2016 14:59:51 +0900
Subject: [PATCH v2 1/3] ARM: dts: orion5x: fix the missing mtd flash on
 linkstation lswtgl
In-Reply-To: <1454738393-14114-1-git-send-email-rogershimizu@gmail.com>
References: <1454738393-14114-1-git-send-email-rogershimizu@gmail.com>
Message-ID: <1454738393-14114-2-git-send-email-rogershimizu@gmail.com>

MTD flash stores u-boot and u-boot environment on linkstation lswtgl.
The latter one can be easily read/write by u-boot-tools package in Debian.

Fixes: dc57844a736f ("ARM: dts: orion5x: add buffalo linkstation ls-wtgl")
Signed-off-by: Roger Shimizu <rogershimizu at gmail.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
---
 arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts | 31 ++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts b/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
index 420788229e6f..aae8a7aceab7 100644
--- a/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
+++ b/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
@@ -228,6 +228,37 @@
 	};
 };
 
+&devbus_bootcs {
+	status = "okay";
+	devbus,keep-config;
+
+	flash at 0 {
+		compatible = "jedec-flash";
+		reg = <0 0x40000>;
+		bank-width = <1>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			header at 0 {
+				reg = <0 0x30000>;
+				read-only;
+			};
+
+			uboot at 30000 {
+				reg = <0x30000 0xF000>;
+				read-only;
+			};
+
+			uboot_env at 3F000 {
+				reg = <0x3F000 0x1000>;
+			};
+		};
+	};
+};
+
 &mdio {
 	status = "okay";
 
-- 
2.1.4



From rogershimizu at gmail.com  Fri Feb  5 21:59:52 2016
From: rogershimizu at gmail.com (Roger Shimizu)
Date: Sat,  6 Feb 2016 14:59:52 +0900
Subject: [PATCH v2 2/3] ARM: dts: orion5x: split linkstation lswtgl into
 common and device parts
In-Reply-To: <1454738393-14114-1-git-send-email-rogershimizu@gmail.com>
References: <1454738393-14114-1-git-send-email-rogershimizu@gmail.com>
Message-ID: <1454738393-14114-3-git-send-email-rogershimizu@gmail.com>

In order to support more linkstation devices, common part of current
.dts file goes into .dtsi file. Some .dtsi start with "mvebu-" prefix
because other kirkwood based linkstation devices are similar, and
will be migrated to use these .dtsi some time later.
  - orion5x-linkstation.dtsi
  - mvebu-linkstation-fan.dtsi
  - mvebu-linkstation-gpio-simple.dtsi
while all rest part remains in device specific .dts file:
  - orion5x-linkstation-lswtgl.dts

Signed-off-by: Roger Shimizu <rogershimizu at gmail.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
---
 arch/arm/boot/dts/mvebu-linkstation-fan.dtsi       |  72 ++++++
 .../boot/dts/mvebu-linkstation-gpio-simple.dtsi    | 105 +++++++++
 arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts   | 243 ++++-----------------
 arch/arm/boot/dts/orion5x-linkstation.dtsi         | 180 +++++++++++++++
 4 files changed, 402 insertions(+), 198 deletions(-)
 create mode 100644 arch/arm/boot/dts/mvebu-linkstation-fan.dtsi
 create mode 100644 arch/arm/boot/dts/mvebu-linkstation-gpio-simple.dtsi
 create mode 100644 arch/arm/boot/dts/orion5x-linkstation.dtsi

diff --git a/arch/arm/boot/dts/mvebu-linkstation-fan.dtsi b/arch/arm/boot/dts/mvebu-linkstation-fan.dtsi
new file mode 100644
index 000000000000..e211a3c47a76
--- /dev/null
+++ b/arch/arm/boot/dts/mvebu-linkstation-fan.dtsi
@@ -0,0 +1,72 @@
+/*
+ * Device Tree common file for gpio-fan on Buffalo Linkstation
+ *
+ * Copyright (C) 2015, 2016
+ * Roger Shimizu <rogershimizu at gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/ {
+	gpio_fan {
+		compatible = "gpio-fan";
+		pinctrl-0 = <&pmx_fan_low &pmx_fan_high &pmx_fan_lock>;
+		pinctrl-names = "default";
+
+		gpio-fan,speed-map =
+			<0		3
+			1500	2
+			3250	1
+			5000	0>;
+	};
+};
+
+&pinctrl {
+	pmx_fan_low: pmx-fan-low {
+		marvell,function = "gpio";
+	};
+
+	pmx_fan_high: pmx-fan-high {
+		marvell,function = "gpio";
+	};
+
+	pmx_fan_lock: pmx-fan-lock {
+		marvell,function = "gpio";
+	};
+};
diff --git a/arch/arm/boot/dts/mvebu-linkstation-gpio-simple.dtsi b/arch/arm/boot/dts/mvebu-linkstation-gpio-simple.dtsi
new file mode 100644
index 000000000000..68d75e79a360
--- /dev/null
+++ b/arch/arm/boot/dts/mvebu-linkstation-gpio-simple.dtsi
@@ -0,0 +1,105 @@
+/*
+ * Device Tree common file for gpio-{keys,leds} on Buffalo Linkstation
+ *
+ * Copyright (C) 2015, 2016
+ * Roger Shimizu <rogershimizu at gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/input/input.h>
+
+/ {
+	gpio_keys {
+		compatible = "gpio-keys";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		pinctrl-0 = <&pmx_power_switch>;
+		pinctrl-names = "default";
+
+		power-on-switch {
+			label = "Power-on Switch";
+			linux,code = <KEY_RESERVED>;
+			linux,input-type = <5>;
+		};
+
+		power-auto-switch {
+			label = "Power-auto Switch";
+			linux,code = <KEY_ESC>;
+			linux,input-type = <5>;
+		};
+	};
+
+	gpio_leds {
+		compatible = "gpio-leds";
+		pinctrl-0 = <&pmx_led_power &pmx_led_alarm &pmx_led_info>;
+		pinctrl-names = "default";
+
+		blue-power-led {
+			label = "linkstation:blue:power";
+			default-state = "keep";
+		};
+
+		red-alarm-led {
+			label = "linkstation:red:alarm";
+		};
+
+		amber-info-led {
+			label = "linkstation:amber:info";
+		};
+	};
+};
+
+&pinctrl {
+	pmx_power_switch: pmx-power-switch {
+		marvell,function = "gpio";
+	};
+
+	pmx_led_power: pmx-leds {
+		marvell,function = "gpio";
+	};
+
+	pmx_led_alarm: pmx-leds {
+		marvell,function = "gpio";
+	};
+
+	pmx_led_info: pmx-leds {
+		marvell,function = "gpio";
+	};
+};
diff --git a/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts b/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
index aae8a7aceab7..0eead400f427 100644
--- a/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
+++ b/arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts
@@ -45,9 +45,10 @@
 
 /dts-v1/;
 
+#include "orion5x-linkstation.dtsi"
+#include "mvebu-linkstation-gpio-simple.dtsi"
+#include "mvebu-linkstation-fan.dtsi"
 #include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/input/input.h>
-#include "orion5x-mv88f5182.dtsi"
 
 / {
 	model = "Buffalo Linkstation LS-WTGL";
@@ -58,247 +59,93 @@
 		reg = <0x00000000 0x4000000>;
 	};
 
-	chosen {
-		bootargs = "console=ttyS0,115200n8 earlyprintk";
-		linux,stdout-path = &uart0;
-	};
-
-	soc {
-		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>,
-		         <MBUS_ID(0x09, 0x00) 0 0xf2200000 0x800>,
-			 <MBUS_ID(0x01, 0x0f) 0 0xf4000000 0x40000>;
-
-		internal-regs {
-			pinctrl: pinctrl at 10000 {
-				pinctrl-names = "default";
-
-				pmx_led_power: pmx-leds {
-					marvell,pins = "mpp0";
-					marvell,function = "gpio";
-				};
-
-				pmx_led_alarm: pmx-leds {
-					marvell,pins = "mpp2";
-					marvell,function = "gpio";
-				};
-
-				pmx_led_info: pmx-leds {
-					marvell,pins = "mpp3";
-					marvell,function = "gpio";
-				};
-
-				pmx_power_hdd: pmx-power-hdd {
-					marvell,pins = "mpp1";
-					marvell,function = "gpio";
-				};
-
-				pmx_usb_power: pmx-usb-power {
-					marvell,pins = "mpp9";
-					marvell,function = "gpio";
-				};
-
-				pmx_sata0: pmx-sata0 {
-					marvell,pins = "mpp12";
-					marvell,function = "sata0";
-				};
-
-				pmx_sata1: pmx-sata1 {
-					marvell,pins = "mpp13";
-					marvell,function = "sata1";
-				};
-
-				pmx_fan_high: pmx-fan-high {
-					marvell,pins = "mpp14";
-					marvell,function = "gpio";
-				};
-
-				pmx_fan_low: pmx-fan-low {
-					marvell,pins = "mpp17";
-					marvell,function = "gpio";
-				};
-
-				pmx_fan_lock: pmx-fan-lock {
-					marvell,pins = "mpp6";
-					marvell,function = "gpio";
-				};
-
-				pmx_power_switch: pmx-power-switch {
-					marvell,pins = "mpp8", "mpp10";
-					marvell,function = "gpio";
-				};
-			};
-		};
-	};
-
 	gpio_keys {
-		compatible = "gpio-keys";
-		#address-cells = <1>;
-		#size-cells = <0>;
-		pinctrl-0 = <&pmx_power_switch>;
-		pinctrl-names = "default";
-
-		button at 1 {
-			label = "Power-on Switch";
-			linux,code = <KEY_RESERVED>;
-			linux,input-type = <5>;
+		power-on-switch {
 			gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
 		};
 
-		button at 2 {
-			label = "Power-auto Switch";
-			linux,code = <KEY_ESC>;
-			linux,input-type = <5>;
+		power-auto-switch {
 			gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
 		};
 	};
 
 	gpio_leds {
-		compatible = "gpio-leds";
-		pinctrl-0 = <&pmx_led_power &pmx_led_alarm
-			     &pmx_led_info>;
-		pinctrl-names = "default";
-
-		led at 1 {
-			label = "lswtgl:blue:power";
+		blue-power-led {
 			gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
-			default-state = "keep";
 		};
 
-		led at 2 {
-			label = "lswtgl:red:alarm";
+		red-alarm-led {
 			gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
 		};
 
-		led at 3 {
-			label = "lswtgl:amber:info";
+		amber-info-led {
 			gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
 		};
 	};
 
 	gpio_fan {
-		compatible = "gpio-fan";
-		pinctrl-0 = <&pmx_fan_low &pmx_fan_high &pmx_fan_lock>;
-		pinctrl-names = "default";
-
 		gpios = <&gpio0 14 GPIO_ACTIVE_LOW
 			 &gpio0 17 GPIO_ACTIVE_LOW>;
 
-		gpio-fan,speed-map = <0 3
-				1500 2
-				3250 1
-				5000 0>;
-
 		alarm-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
 	};
+};
 
-	restart_poweroff {
-		compatible = "restart-poweroff";
+&pinctrl {
+	pmx_led_power: pmx-leds {
+		marvell,pins = "mpp0";
+		marvell,function = "gpio";
 	};
 
-	regulators {
-		compatible = "simple-bus";
-		#address-cells = <1>;
-		#size-cells = <0>;
-		pinctrl-0 = <&pmx_power_hdd &pmx_usb_power>;
-		pinctrl-names = "default";
-
-		usb_power: regulator at 1 {
-			compatible = "regulator-fixed";
-			reg = <1>;
-			regulator-name = "USB Power";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			enable-active-high;
-			regulator-always-on;
-			regulator-boot-on;
-			gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
-		};
-
-		hdd_power: regulator at 2 {
-			compatible = "regulator-fixed";
-			reg = <2>;
-			regulator-name = "HDD Power";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			enable-active-high;
-			regulator-always-on;
-			regulator-boot-on;
-			gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
-		};
+	pmx_power_hdd: pmx-power-hdd {
+		marvell,pins = "mpp1";
+		marvell,function = "gpio";
 	};
-};
-
-&devbus_bootcs {
-	status = "okay";
-	devbus,keep-config;
 
-	flash at 0 {
-		compatible = "jedec-flash";
-		reg = <0 0x40000>;
-		bank-width = <1>;
-
-		partitions {
-			compatible = "fixed-partitions";
-			#address-cells = <1>;
-			#size-cells = <1>;
-
-			header at 0 {
-				reg = <0 0x30000>;
-				read-only;
-			};
-
-			uboot at 30000 {
-				reg = <0x30000 0xF000>;
-				read-only;
-			};
+	pmx_led_alarm: pmx-leds {
+		marvell,pins = "mpp2";
+		marvell,function = "gpio";
+	};
 
-			uboot_env at 3F000 {
-				reg = <0x3F000 0x1000>;
-			};
-		};
+	pmx_led_info: pmx-leds {
+		marvell,pins = "mpp3";
+		marvell,function = "gpio";
 	};
-};
 
-&mdio {
-	status = "okay";
+	pmx_fan_lock: pmx-fan-lock {
+		marvell,pins = "mpp6";
+		marvell,function = "gpio";
+	};
 
-	ethphy: ethernet-phy {
-		reg = <8>;
+	pmx_power_switch: pmx-power-switch {
+		marvell,pins = "mpp8", "mpp10";
+		marvell,function = "gpio";
 	};
-};
 
-&eth {
-	status = "okay";
+	pmx_power_usb: pmx-power-usb {
+		marvell,pins = "mpp9";
+		marvell,function = "gpio";
+	};
 
-	ethernet-port at 0 {
-		phy-handle = <&ethphy>;
+	pmx_fan_high: pmx-fan-high {
+		marvell,pins = "mpp14";
+		marvell,function = "gpio";
 	};
-};
 
-&ehci0 {
-	status = "okay";
+	pmx_fan_low: pmx-fan-low {
+		marvell,pins = "mpp17";
+		marvell,function = "gpio";
+	};
 };
 
-&i2c {
-	status = "okay";
-
-	rtc {
-		compatible = "ricoh,rs5c372a";
-		reg = <0x32>;
-	};
+&hdd_power {
+	gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
 };
 
-&wdt {
-	status = "disabled";
+&usb_power {
+	gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
 };
 
 &sata {
-	pinctrl-0 = <&pmx_sata0 &pmx_sata1>;
-	pinctrl-names = "default";
-	status = "okay";
 	nr-ports = <2>;
 };
-
-&uart0 {
-	status = "okay";
-};
diff --git a/arch/arm/boot/dts/orion5x-linkstation.dtsi b/arch/arm/boot/dts/orion5x-linkstation.dtsi
new file mode 100644
index 000000000000..ed456ab35fd8
--- /dev/null
+++ b/arch/arm/boot/dts/orion5x-linkstation.dtsi
@@ -0,0 +1,180 @@
+/*
+ * Device Tree common file for orion5x based Buffalo Linkstation
+ *
+ * Copyright (C) 2015, 2016
+ * Roger Shimizu <rogershimizu at gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "orion5x-mv88f5182.dtsi"
+
+/ {
+	chosen {
+		bootargs = "console=ttyS0,115200n8 earlyprintk";
+		linux,stdout-path = &uart0;
+	};
+
+	soc {
+		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>,
+				 <MBUS_ID(0x09, 0x00) 0 0xf2200000 0x800>,
+				 <MBUS_ID(0x01, 0x0f) 0 0xf4000000 0x40000>;
+	};
+
+	restart_poweroff {
+		compatible = "restart-poweroff";
+	};
+
+	regulators {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		pinctrl-0 = <&pmx_power_usb &pmx_power_hdd>;
+		pinctrl-names = "default";
+
+		usb_power: regulator at 1 {
+			compatible = "regulator-fixed";
+			reg = <1>;
+			regulator-name = "USB Power";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			enable-active-high;
+			regulator-always-on;
+			regulator-boot-on;
+		};
+
+		hdd_power: regulator at 2 {
+			compatible = "regulator-fixed";
+			reg = <2>;
+			regulator-name = "HDD Power";
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			enable-active-high;
+			regulator-always-on;
+			regulator-boot-on;
+		};
+	};
+};
+
+&pinctrl {
+	pmx_power_hdd: pmx-power-hdd {
+		marvell,function = "gpio";
+	};
+
+	pmx_power_usb: pmx-power-usb {
+		marvell,function = "gpio";
+	};
+};
+
+&devbus_bootcs {
+	status = "okay";
+	devbus,keep-config;
+
+	flash at 0 {
+		compatible = "jedec-flash";
+		reg = <0 0x40000>;
+		bank-width = <1>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			header at 0 {
+				reg = <0 0x30000>;
+				read-only;
+			};
+
+			uboot at 30000 {
+				reg = <0x30000 0xF000>;
+				read-only;
+			};
+
+			uboot_env at 3F000 {
+				reg = <0x3F000 0x1000>;
+			};
+		};
+	};
+};
+
+&mdio {
+	status = "okay";
+
+	ethphy: ethernet-phy {
+		reg = <8>;
+	};
+};
+
+&eth {
+	status = "okay";
+
+	ethernet-port at 0 {
+		phy-handle = <&ethphy>;
+	};
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&i2c {
+	status = "okay";
+
+	rtc {
+		compatible = "ricoh,rs5c372a";
+		reg = <0x32>;
+	};
+};
+
+&wdt {
+	status = "disabled";
+};
+
+&sata {
+	status = "okay";
+	nr-ports = <1>;
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart1 {
+	status = "okay";
+};
-- 
2.1.4



From rogershimizu at gmail.com  Fri Feb  5 21:59:53 2016
From: rogershimizu at gmail.com (Roger Shimizu)
Date: Sat,  6 Feb 2016 14:59:53 +0900
Subject: [PATCH v2 3/3] ARM: dts: orion5x: add device tree for buffalo
 linkstation ls-gl
In-Reply-To: <1454738393-14114-1-git-send-email-rogershimizu@gmail.com>
References: <1454738393-14114-1-git-send-email-rogershimizu@gmail.com>
Message-ID: <1454738393-14114-4-git-send-email-rogershimizu@gmail.com>

Add dts file to support Buffalo Linkstation LS-GL
(a.k.a Buffalo Linkstation Pro/Live), which is marvell orion5x based
3.5" HDD NAS.

Product info:
  - (JPN) http://buffalo.jp/products/catalog/item/l/ls-gl/
  - (ENG) http://www.buffalotech.com/products/network-storage/linkstation/linkstation-pro

This device tree is based on the board file:
  arch/arm/mach-orion5x/kurobox_pro-setup.c
However, that board file also support Kurobox Pro, which is not supported by
device tree yet. So the board file is not removed.

Signed-off-by: Roger Shimizu <rogershimizu at gmail.com>
Reviewed-by: Andrew Lunn <andrew at lunn.ch>
---
 arch/arm/boot/dts/Makefile                     |  1 +
 arch/arm/boot/dts/orion5x-linkstation-lsgl.dts | 87 ++++++++++++++++++++++++++
 2 files changed, 88 insertions(+)
 create mode 100644 arch/arm/boot/dts/orion5x-linkstation-lsgl.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 68625754f398..15a52c1be78a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -496,6 +496,7 @@ dtb-$(CONFIG_SOC_DRA7XX) += \
 dtb-$(CONFIG_ARCH_ORION5X) += \
 	orion5x-lacie-d2-network.dtb \
 	orion5x-lacie-ethernet-disk-mini-v2.dtb \
+	orion5x-linkstation-lsgl.dtb \
 	orion5x-linkstation-lswtgl.dtb \
 	orion5x-lswsgl.dtb \
 	orion5x-maxtor-shared-storage-2.dtb \
diff --git a/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts b/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
new file mode 100644
index 000000000000..1cf644bfd7ea
--- /dev/null
+++ b/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
@@ -0,0 +1,87 @@
+/*
+ * Device Tree file for Buffalo Linkstation LS-GL
+ *       (also known as Buffalo Linkstation Pro/Live)
+ *
+ * Copyright (C) 2016
+ * Roger Shimizu <rogershimizu at gmail.com>
+ *
+ * Based on the board file arch/arm/mach-orion5x/kurobox_pro-setup.c
+ * Copyright (C) Ronen Shitrit <rshitrit at marvell.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "orion5x-linkstation.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	model = "Buffalo Linkstation Pro/Live";
+	compatible = "buffalo,lsgl", "marvell,orion5x-88f5182", "marvell,orion5x";
+
+	memory { /* 128 MB */
+		device_type = "memory";
+		reg = <0x00000000 0x8000000>;
+	};
+};
+
+&pinctrl {
+	pmx_power_hdd: pmx-power-hdd {
+		marvell,pins = "mpp1";
+		marvell,function = "gpio";
+	};
+
+	pmx_power_usb: pmx-power-usb {
+		marvell,pins = "mpp9";
+		marvell,function = "gpio";
+	};
+};
+
+&hdd_power {
+	gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
+};
+
+&usb_power {
+	gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
+};
+
+&ehci1 {
+	status = "okay";
+};
-- 
2.1.4



From srinivas.kandagatla at linaro.org  Fri Feb  5 23:07:33 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Sat,  6 Feb 2016 07:07:33 +0000
Subject: [PATCH] arm64: defconfig: add spmi and usb related configs
Message-ID: <1454742453-24157-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds kconfigs for spmi bus support, pinctrl drivers and usb
related to get USB working on Qualcomm DB410C board.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/configs/defconfig | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8c6f05f..ad26a53 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -144,7 +144,9 @@ CONFIG_I2C_RCAR=y
 CONFIG_SPI=y
 CONFIG_SPI_PL022=y
 CONFIG_SPI_QUP=y
+CONFIG_SPMI=y
 CONFIG_PINCTRL_MSM8916=y
+CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
 CONFIG_GPIO_PL061=y
 CONFIG_GPIO_RCAR=y
 CONFIG_GPIO_XGENE=y
@@ -152,9 +154,11 @@ CONFIG_POWER_RESET_MSM=y
 CONFIG_POWER_RESET_XGENE=y
 CONFIG_POWER_RESET_SYSCON=y
 # CONFIG_HWMON is not set
+CONFIG_MFD_SPMI_PMIC=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_QCOM_SMD_RPM=y
+CONFIG_REGULATOR_QCOM_SPMI=y
 CONFIG_FB=y
 CONFIG_FB_ARMCLCD=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
@@ -167,13 +171,21 @@ CONFIG_SND_SOC=y
 CONFIG_SND_SOC_RCAR=y
 CONFIG_SND_SOC_AK4613=y
 CONFIG_USB=y
+CONFIG_USB_OTG=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_MSM=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
 CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_HCD_PLATFORM=y
 CONFIG_USB_STORAGE=y
+CONFIG_USB_CHIPIDEA=y
+CONFIG_USB_CHIPIDEA_UDC=y
+CONFIG_USB_CHIPIDEA_HOST=y
 CONFIG_USB_ISP1760=y
+CONFIG_USB_HSIC_USB3503=y
+CONFIG_USB_MSM_OTG=y
 CONFIG_USB_ULPI=y
+CONFIG_USB_GADGET=y
 CONFIG_MMC=y
 CONFIG_MMC_BLOCK_MINORS=32
 CONFIG_MMC_ARMMMCI=y
@@ -216,6 +228,7 @@ CONFIG_QCOM_SMD_RPM=y
 CONFIG_ARCH_TEGRA_132_SOC=y
 CONFIG_ARCH_TEGRA_210_SOC=y
 CONFIG_HISILICON_IRQ_MBIGEN=y
+CONFIG_EXTCON_USB_GPIO=y
 CONFIG_PHY_XGENE=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
-- 
1.9.1



From herbert at gondor.apana.org.au  Fri Feb  5 23:46:17 2016
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Sat, 6 Feb 2016 15:46:17 +0800
Subject: [PATCH 02/11] crypto: sunxi-ss: prevent compilation on 64-bit
In-Reply-To: <1454348370-3816-3-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-3-git-send-email-andre.przywara@arm.com>
Message-ID: <20160206074617.GB22220@gondor.apana.org.au>

On Mon, Feb 01, 2016 at 05:39:21PM +0000, Andre Przywara wrote:
> The driver for the sunxi-ss crypto engine is not entirely 64-bit safe,
> compilation on arm64 spits some warnings.
> The proper fix was deemed to involved [1], so since 64-bit SoCs won't
> have this IP block we just disable this driver for 64-bit.
> 
> [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399988.html
>      (and the reply)
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>

Applied.
-- 
Email: Herbert Xu <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From herbert at gondor.apana.org.au  Fri Feb  5 23:49:21 2016
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Sat, 6 Feb 2016 15:49:21 +0800
Subject: [PATCH 0/2] crypto: atmel-sha - fix resource management
In-Reply-To: <cover.1454675769.git.cyrille.pitchen@atmel.com>
References: <cover.1454675769.git.cyrille.pitchen@atmel.com>
Message-ID: <20160206074921.GK22220@gondor.apana.org.au>

On Fri, Feb 05, 2016 at 01:45:11PM +0100, Cyrille Pitchen wrote:
> Hi all,
> 
> these two small patches fix resource release and clock management in
> atomic context.

Applied to crypto.
-- 
Email: Herbert Xu <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From moinejf at free.fr  Sat Feb  6 01:37:51 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Sat, 6 Feb 2016 10:37:51 +0100
Subject: [PATCH v4 1/2] clk: sunxi: Add sun6i/8i video support
In-Reply-To: <20160205093915.GF1139@lukather>
References: <cover.1454435944.git.moinejf@free.fr>
 <3c0e2cdea659e9e682f80ecf42b252c740095f15.1454435944.git.moinejf@free.fr>
 <20160205093915.GF1139@lukather>
Message-ID: <20160206103751.eb21edf56ddc6ef7c27907f0@free.fr>

On Fri, 5 Feb 2016 10:39:15 +0100
Maxime Ripard <maxime.ripard at free-electrons.com> wrote:

> > +CLK_OF_DECLARE(sun6i_display, "allwinner,sun6i-display-clk", sun6i_display_setup);
> 
> Please use the display driver from my DRM serie, it covers everything
> you need here.

If you give me a pointer, I will have a look.

> > +CLK_OF_DECLARE(sun6i_pll3, "allwinner,sun6i-pll3-clk", sun6i_pll3_setup);
> 
> And please use the clk-factors code here.

I don't see how I can get direct 297MHz and 270MHz in fractional mode
with that code.

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/



From wens at csie.org  Sat Feb  6 01:56:00 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Sat, 6 Feb 2016 17:56:00 +0800
Subject: [PATCH v4 1/2] clk: sunxi: Add sun6i/8i video support
In-Reply-To: <20160206103751.eb21edf56ddc6ef7c27907f0@free.fr>
References: <cover.1454435944.git.moinejf@free.fr>
 <3c0e2cdea659e9e682f80ecf42b252c740095f15.1454435944.git.moinejf@free.fr>
 <20160205093915.GF1139@lukather>
 <20160206103751.eb21edf56ddc6ef7c27907f0@free.fr>
Message-ID: <CAGb2v640YWtdT7Rhz2jP7gnQ1U6HJe9POU40HCp==7GrZxDz0A@mail.gmail.com>

On Sat, Feb 6, 2016 at 5:37 PM, Jean-Francois Moine <moinejf at free.fr> wrote:
> On Fri, 5 Feb 2016 10:39:15 +0100
> Maxime Ripard <maxime.ripard at free-electrons.com> wrote:
>
>> > +CLK_OF_DECLARE(sun6i_display, "allwinner,sun6i-display-clk", sun6i_display_setup);
>>
>> Please use the display driver from my DRM serie, it covers everything
>> you need here.
>
> If you give me a pointer, I will have a look.
>
>> > +CLK_OF_DECLARE(sun6i_pll3, "allwinner,sun6i-pll3-clk", sun6i_pll3_setup);
>>
>> And please use the clk-factors code here.
>
> I don't see how I can get direct 297MHz and 270MHz in fractional mode
> with that code.

clk-factors now supports a custom .recalc callback. Along with get_factors,
you can support pretty much any clock that has four variables, not including
the mux and clock gate.

So for this you'd have the div as factor m, and the integer mode bit as p,
and the fraction bit as n, and recalc would be somewhat like this:

if (p) {
        rate = parent_rate / (m + 1);
} else if (n) {
        rate = 297000000;
} else {
        rate = 270000000;
}

get_factors should be easy enough to figure out.

Regards
ChenYu


From jayachandran.chandrashekaran at broadcom.com  Sat Feb  6 01:58:26 2016
From: jayachandran.chandrashekaran at broadcom.com (Jayachandran Chandrashekaran Nair)
Date: Sat, 6 Feb 2016 15:28:26 +0530
Subject: [PATCH v7 5/5] PCI: ACPI: Add a generic ACPI based host controller
In-Reply-To: <3576289.1ltj0IceQ5@vostro.rjw.lan>
References: <1454058340-7904-1-git-send-email-jchandra@broadcom.com>
 <CAKc_7PXYtFt1MQE-UGO0O5vvQ+xFKa2b5=F8wXB=EN-JUJVzZw@mail.gmail.com>
 <20160205094740.GA31547@red-moon> <3576289.1ltj0IceQ5@vostro.rjw.lan>
Message-ID: <CAKc_7PV69xZ-+yeq+fVAMykuQ53HsjpACz9yH9LpJE-=X5xggA@mail.gmail.com>

Hi Rafael,

On Sat, Feb 6, 2016 at 4:56 AM, Rafael J. Wysocki <rjw at rjwysocki.net> wrote:
> On Friday, February 05, 2016 09:47:40 AM Lorenzo Pieralisi wrote:
>> On Fri, Feb 05, 2016 at 02:05:37PM +0530, Jayachandran Chandrashekaran Nair wrote:
>>
>> [...]
>>
>> > pci_host_acpi.c is a generic implementation of these using a sysdata
>> > pointing to acpi_pci_root_info, and using a pointer to the pci_mmcfg_region
>> > to access ECAM area, Maybe I can rename this file to
>> > pci_acpi_host_generic.c to reflect this better.
>>
>> Maybe you should stop sending this series and work with Tomasz to
>> get this done, you are confusing everyone and I am really really
>> annoyed about this.
>>
>> Do you realize there is no point in having two patch series doing
>> the same thing and wasting everyone's review time ?
>>
>> Do you realize he started this work long before you and went through
>> several rounds of review already (I told you before but in case you
>> forgot) ?
>>
>> Tomasz posted a version yesterday, integrating comments following months
>> of review and testing and I think it is ready to get upstream:
>>
>> https://lkml.org/lkml/2016/2/4/646
>>
>> Did you even consider reviewing his code or helping him instead of
>> churning out more patches doing the *SAME* thing ?
>>
>> Do you want all of us to go through your code and re-fix what has
>> already been fixed in Tomasz's series with the end result of missing
>> yet another merge window ?
>>
>> This is really annoying, stop it please, really.
>
> OK, so to be crystal clear here.
>
> I'm going to ignore the series the $subject patch belongs to going forward.

It looks like you can already reviewed Tomasz's patchset and as Lorenzo
says thinks that it can be merged.

When I first posted the patchset the state of arm64 ACPI/PCI was not that
clear - and I thought an alternative will help. Ideally I would expect
maintainers to look at technical merit, but in this case any working solution
merged will be great news.

Thanks,
JC.


From rafael at kernel.org  Sat Feb  6 02:23:07 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Sat, 6 Feb 2016 11:23:07 +0100
Subject: [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen
In-Reply-To: <1454641552-12576-2-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
 <1454641552-12576-2-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <CAJZ5v0id-035AtyQ_SccPuCxD7+pa6GCgj3WBAojM+rFqssGQQ@mail.gmail.com>

On Fri, Feb 5, 2016 at 4:05 AM, Shannon Zhao <zhaoshenglong at huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
>
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>

Well, this doesn't look right to me.

We need to find a nicer way to achieve what you want.

Thanks,
Rafael


From moinejf at free.fr  Sat Feb  6 02:26:05 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Sat, 6 Feb 2016 11:26:05 +0100
Subject: [PATCH v3 1/5] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <20160205111152.GA31506@lukather>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-2-git-send-email-k@japko.eu>
 <20160204154752.4df7808be3364a98c496c030@free.fr>
 <20160205111152.GA31506@lukather>
Message-ID: <20160206112605.4005784d1d0962c8adfe58a0@free.fr>

On Fri, 5 Feb 2016 12:11:52 +0100
Maxime Ripard <maxime.ripard at free-electrons.com> wrote:

> However, I'd like to keep per-soc and per-clocks compatibles in the
> DT, in case we need to protect a clock in the future.

What do you mean by "protect a clock"?

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/



From zhang.chunyan at linaro.org  Sat Feb  6 03:04:26 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Sat,  6 Feb 2016 19:04:26 +0800
Subject: [PATCH V3 0/6] Introduce CoreSight STM support
Message-ID: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>

This patchset adds support for CoreSight STM IP block. It also makes
a little modification to the generic STM framework to cover the
CoreSight STM requirements. Full description follows the changelog.

Changes from v1:
 - Added a definition of coresight_simple_func() in CS-STM driver to
   avoid the kbuild test robot error for the time being.  This
   modification will be removed when merging the code in which the
   coresight_simple_func() has been moved to the header file.
 - Calculate the channel number according to the channel memory space size.

Changes from V2:
 - Changed to return -EFAULT if failed on the command STP_GET_OPTIONS.
 - Used Alex's patch [1] instead of the last 2/6.
 - Removed the while loop from stm_send(), since the packet size passed
   to it isn't larger than 4 bytes on 32-bit system and 8 bytes on
   64-bit system.
 - Removed stm_send_64bit(), since the process of packets on 64-bit
   CS-STM should be basically the same with on 32-bit system, except the 
   maximum length of writing STM at a time.
 - Removed the support of writing 64-bit to CoreSight STM buffer at a time
   on 32-bit ARM architecture according to an ARM engineer suggestion.  As
   he said that the STM might receive a 64-bit write, or might receive a
   pair of 32-bit writes to the two addressed words in either order.
   So 64-bit write isn't guaranteed to work on the ARM 32-bit architecture.

Thanks,
Chunyan

[1] https://lkml.org/lkml/2016/2/4/652

Alexander Shishkin (1):
  stm class: Support devices with multiple instances

Chunyan Zhang (2):
  stm class: Add ioctl get_options interface
  Documentations: Add explanations of the case for non-configurable
    masters

Mathieu Poirier (2):
  stm class: provision for statically assigned masterIDs
  coresight-stm: Bindings for System Trace Macrocell

Pratik Patel (1):
  coresight-stm: adding driver for CoreSight STM component

 .../ABI/testing/sysfs-bus-coresight-devices-stm    |  53 ++
 .../devicetree/bindings/arm/coresight.txt          |  28 +
 Documentation/trace/coresight.txt                  |  37 +-
 Documentation/trace/stm.txt                        |   6 +
 drivers/hwtracing/coresight/Kconfig                |  11 +
 drivers/hwtracing/coresight/Makefile               |   1 +
 drivers/hwtracing/coresight/coresight-stm.c        | 928 +++++++++++++++++++++
 drivers/hwtracing/stm/core.c                       |  30 +-
 drivers/hwtracing/stm/policy.c                     |  25 +-
 include/linux/coresight-stm.h                      |   6 +
 include/linux/stm.h                                |  11 +
 include/uapi/linux/coresight-stm.h                 |  12 +
 include/uapi/linux/stm.h                           |   1 +
 13 files changed, 1140 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
 create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
 create mode 100644 include/linux/coresight-stm.h
 create mode 100644 include/uapi/linux/coresight-stm.h

-- 
1.9.1



From zhang.chunyan at linaro.org  Sat Feb  6 03:04:27 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Sat,  6 Feb 2016 19:04:27 +0800
Subject: [PATCH V3 1/6] stm class: Add ioctl get_options interface
In-Reply-To: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454756672-12790-2-git-send-email-zhang.chunyan@linaro.org>

There is already an interface of set_options, but no get_options yet.
Before setting any options, one would may want to see the current
status of that option by means of get_options interface. This
interface has been used in CoreSight STM driver.

Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 drivers/hwtracing/stm/core.c | 12 ++++++++++++
 include/linux/stm.h          |  3 +++
 include/uapi/linux/stm.h     |  1 +
 3 files changed, 16 insertions(+)

diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index b6445d9..854a16d 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -571,6 +571,18 @@ stm_char_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 						    options);
 
 		break;
+
+	case STP_GET_OPTIONS:
+		if (stm_data->get_options)
+			err = stm_data->get_options(stm_data,
+						    stmf->output.master,
+						    stmf->output.channel,
+						    stmf->output.nr_chans,
+						    &options);
+
+		if (copy_to_user((void __user *)arg, &options, sizeof(u64)))
+			return -EFAULT;
+
 	default:
 		break;
 	}
diff --git a/include/linux/stm.h b/include/linux/stm.h
index 9d0083d..f351d62 100644
--- a/include/linux/stm.h
+++ b/include/linux/stm.h
@@ -88,6 +88,9 @@ struct stm_data {
 	long			(*set_options)(struct stm_data *, unsigned int,
 					       unsigned int, unsigned int,
 					       unsigned long);
+	long			(*get_options)(struct stm_data *, unsigned int,
+					       unsigned int, unsigned int,
+					       u64 *);
 };
 
 int stm_register_device(struct device *parent, struct stm_data *stm_data,
diff --git a/include/uapi/linux/stm.h b/include/uapi/linux/stm.h
index 626a8d3..0dab16e 100644
--- a/include/uapi/linux/stm.h
+++ b/include/uapi/linux/stm.h
@@ -46,5 +46,6 @@ struct stp_policy_id {
 #define STP_POLICY_ID_SET	_IOWR('%', 0, struct stp_policy_id)
 #define STP_POLICY_ID_GET	_IOR('%', 1, struct stp_policy_id)
 #define STP_SET_OPTIONS		_IOW('%', 2, __u64)
+#define STP_GET_OPTIONS		_IOR('%', 3, __u64)
 
 #endif /* _UAPI_LINUX_STM_H */
-- 
1.9.1



From zhang.chunyan at linaro.org  Sat Feb  6 03:04:28 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Sat,  6 Feb 2016 19:04:28 +0800
Subject: [PATCH V3 2/6] stm class: Support devices with multiple instances
In-Reply-To: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454756672-12790-3-git-send-email-zhang.chunyan@linaro.org>

From: Alexander Shishkin <alexander.shishkin at linux.intel.com>

By convention, the name of the stm policy directory in configfs consists of
the device name to which it applies and the actual policy name, separated
by a dot. Now, some devices already have dots in their names that separate
name of the actual device from its instance identifier. Such devices will
result in two (or more, who can tell) dots in the policy directory name.

Existing policy code, however, will treat the first dot as the one that
separates device name from policy name, therefore failing the above case.

This patch makes the last dot in the directory name be the separator, thus
prohibiting dots from being used in policy names.

Suggested-by: Chunyan Zhang <zhang.chunyan at linaro.org>
Signed-off-by: Alexander Shishkin <alexander.shishkin at linux.intel.com>
---
 drivers/hwtracing/stm/policy.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
index 11ab6d0..17a1416 100644
--- a/drivers/hwtracing/stm/policy.c
+++ b/drivers/hwtracing/stm/policy.c
@@ -320,10 +320,11 @@ stp_policies_make(struct config_group *group, const char *name)
 
 	/*
 	 * node must look like <device_name>.<policy_name>, where
-	 * <device_name> is the name of an existing stm device and
-	 * <policy_name> is an arbitrary string
+	 * <device_name> is the name of an existing stm device; may
+	 *               contain dots;
+	 * <policy_name> is an arbitrary string; may not contain dots
 	 */
-	p = strchr(devname, '.');
+	p = strrchr(devname, '.');
 	if (!p) {
 		kfree(devname);
 		return ERR_PTR(-EINVAL);
-- 
1.9.1



From zhang.chunyan at linaro.org  Sat Feb  6 03:04:29 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Sat,  6 Feb 2016 19:04:29 +0800
Subject: [PATCH V3 3/6] stm class: provision for statically assigned masterIDs
In-Reply-To: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454756672-12790-4-git-send-email-zhang.chunyan@linaro.org>

From: Mathieu Poirier <mathieu.poirier at linaro.org>

Some architecture like ARM assign masterIDs statically at the HW design
phase, making masterID manipulation in the generic STM core irrelevant.

This patch adds a new 'mstatic' flag to struct stm_data that tells the
core that this specific STM device doesn't need explicit masterID
management.  In the core sw_start/end of masterID are set to '1',
i.e there is only one masterID to deal with.

Also this patch depends on [1], so that the number of masterID
is '1' too.

Finally the lower and upper bound for masterIDs as presented
in ($SYSFS)/class/stm/XYZ.stm/masters and
($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
are set to '-1'.  That way users can't confuse them with
architecture where masterID management is required (where any
other value would be valid).

[1] https://lkml.org/lkml/2015/12/22/348

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 drivers/hwtracing/stm/core.c   | 18 ++++++++++++++++--
 drivers/hwtracing/stm/policy.c | 18 ++++++++++++++++--
 include/linux/stm.h            |  8 ++++++++
 3 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 854a16d..d344ae7 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -44,9 +44,15 @@ static ssize_t masters_show(struct device *dev,
 			    char *buf)
 {
 	struct stm_device *stm = to_stm_device(dev);
-	int ret;
+	int ret, sw_start, sw_end;
+
+	sw_start = stm->data->sw_start;
+	sw_end = stm->data->sw_end;
 
-	ret = sprintf(buf, "%u %u\n", stm->data->sw_start, stm->data->sw_end);
+	if (stm->data->mstatic)
+		sw_start = sw_end = STM_STATIC_MASTERID;
+
+	ret = sprintf(buf, "%d %d\n", sw_start, sw_end);
 
 	return ret;
 }
@@ -630,7 +636,15 @@ int stm_register_device(struct device *parent, struct stm_data *stm_data,
 	if (!stm_data->packet || !stm_data->sw_nchannels)
 		return -EINVAL;
 
+	/*
+	 * MasterIDs are statically set in HW. As such the core is
+	 * using a single master for interaction with this device.
+	 */
+	if (stm_data->mstatic)
+		stm_data->sw_start = stm_data->sw_end = 1;
+
 	nmasters = stm_data->sw_end - stm_data->sw_start;
+
 	stm = kzalloc(sizeof(*stm) + nmasters * sizeof(void *), GFP_KERNEL);
 	if (!stm)
 		return -ENOMEM;
diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
index 17a1416..c874dea 100644
--- a/drivers/hwtracing/stm/policy.c
+++ b/drivers/hwtracing/stm/policy.c
@@ -80,10 +80,17 @@ static ssize_t
 stp_policy_node_masters_show(struct config_item *item, char *page)
 {
 	struct stp_policy_node *policy_node = to_stp_policy_node(item);
+	struct stm_device *stm = policy_node->policy->stm;
+	int first_master, last_master;
 	ssize_t count;
 
-	count = sprintf(page, "%u %u\n", policy_node->first_master,
-			policy_node->last_master);
+	first_master = policy_node->first_master;
+	last_master = policy_node->last_master;
+
+	if (stm && stm->data->mstatic)
+		first_master = last_master = STM_STATIC_MASTERID;
+
+	count = sprintf(page, "%d %d\n", first_master, last_master);
 
 	return count;
 }
@@ -106,6 +113,13 @@ stp_policy_node_masters_store(struct config_item *item, const char *page,
 	if (!stm)
 		goto unlock;
 
+	/*
+	 * masterIDs are statically allocated in HW, no point in trying to
+	 * change their values.
+	 */
+	if (stm->data->mstatic)
+		goto unlock;
+
 	/* must be within [sw_start..sw_end], which is an inclusive range */
 	if (first > INT_MAX || last > INT_MAX || first > last ||
 	    first < stm->data->sw_start ||
diff --git a/include/linux/stm.h b/include/linux/stm.h
index f351d62..c9712a7 100644
--- a/include/linux/stm.h
+++ b/include/linux/stm.h
@@ -18,6 +18,11 @@
 #include <linux/device.h>
 
 /**
+ * The masterIDs are statically set in hardware and can't be queried
+ */
+#define STM_STATIC_MASTERID -1
+
+/**
  * enum stp_packet_type - STP packets that an STM driver sends
  */
 enum stp_packet_type {
@@ -46,6 +51,8 @@ struct stm_device;
  * struct stm_data - STM device description and callbacks
  * @name:		device name
  * @stm:		internal structure, only used by stm class code
+ * @mstatic:		true if masterIDs are assigned in HW.  If so @sw_start
+ *			and @sw_end are set to '1' by the core.
  * @sw_start:		first STP master available to software
  * @sw_end:		last STP master available to software
  * @sw_nchannels:	number of STP channels per master
@@ -71,6 +78,7 @@ struct stm_device;
 struct stm_data {
 	const char		*name;
 	struct stm_device	*stm;
+	bool			mstatic;
 	unsigned int		sw_start;
 	unsigned int		sw_end;
 	unsigned int		sw_nchannels;
-- 
1.9.1



From zhang.chunyan at linaro.org  Sat Feb  6 03:04:30 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Sat,  6 Feb 2016 19:04:30 +0800
Subject: [PATCH V3 4/6] Documentations: Add explanations of the case for
 non-configurable masters
In-Reply-To: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454756672-12790-5-git-send-email-zhang.chunyan@linaro.org>

For some STM hardware (e.g. ARM CoreSight STM), the masterID associated
to a source is set at the hardware level and not user configurable.
Since the masterID information isn't available to SW, introducing
a new value of -1 to reflect this reality.

Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 Documentation/trace/stm.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/trace/stm.txt b/Documentation/trace/stm.txt
index ea035f9..f03bc2b 100644
--- a/Documentation/trace/stm.txt
+++ b/Documentation/trace/stm.txt
@@ -47,6 +47,12 @@ through 127 in it. Now, any producer (trace source) identifying itself
 with "user" identification string will be allocated a master and
 channel from within these ranges.
 
+$ cat /config/stp-policy/dummy_stm.my-policy/user/masters
+-1 -1
+
+Would indicate the masters for this rule are set in hardware and
+not configurable in user space.
+
 These rules can be nested, for example, one can define a rule "dummy"
 under "user" directory from the example above and this new rule will
 be used for trace sources with the id string of "user/dummy".
-- 
1.9.1



From zhang.chunyan at linaro.org  Sat Feb  6 03:04:31 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Sat,  6 Feb 2016 19:04:31 +0800
Subject: [PATCH V3 5/6] coresight-stm: Bindings for System Trace Macrocell
In-Reply-To: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454756672-12790-6-git-send-email-zhang.chunyan@linaro.org>

From: Mathieu Poirier <mathieu.poirier at linaro.org>

The System Trace Macrocell (STM) is an IP block falling under the
CoreSight umbrella.  It's main purpose it so expose stimulus channels
to any system component for the purpose of information logging.

Bindings for this IP block adds a couple of items to the current
mandatory definition for CoreSight components.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 .../devicetree/bindings/arm/coresight.txt          | 28 ++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
index 62938eb..93147c0c 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -19,6 +19,7 @@ its hardware characteristcs.
 		- "arm,coresight-etm3x", "arm,primecell";
 		- "arm,coresight-etm4x", "arm,primecell";
 		- "qcom,coresight-replicator1x", "arm,primecell";
+		- "arm,coresight-stm", "arm,primecell"; [1]
 
 	* reg: physical base address and length of the register
 	  set(s) of the component.
@@ -36,6 +37,14 @@ its hardware characteristcs.
 	  layout using the generic DT graph presentation found in
 	  "bindings/graph.txt".
 
+* Additional required properties for System Trace Macrocells (STM):
+	* reg: along with the physical base address and length of the register
+	  set as described above, another entry is required to describe the
+	  mapping of the extended stimulus port area.
+
+	* reg-names: the only acceptable values are "stm-base" and
+	  "stm-stimulus-base", each corresponding to the areas defined in "reg".
+
 * Required properties for devices that don't show up on the AMBA bus, such as
   non-configurable replicators:
 
@@ -202,3 +211,22 @@ Example:
 			};
 		};
 	};
+
+4. STM
+	stm at 20100000 {
+		compatible = "arm,coresight-stm", "arm,primecell";
+		reg = <0 0x20100000 0 0x1000>,
+		      <0 0x28000000 0 0x180000>;
+		reg-names = "stm-base", "stm-stimulus-base";
+
+		clocks = <&soc_smc50mhz>;
+		clock-names = "apb_pclk";
+		port {
+			stm_out_port: endpoint {
+				remote-endpoint = <&main_funnel_in_port2>;
+			};
+		};
+	};
+
+[1]. There is currently two version of STM: STM32 and STM500.  Both
+have the same HW interface and as such don't need an explicit binding name.
-- 
1.9.1



From zhang.chunyan at linaro.org  Sat Feb  6 03:04:32 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Sat,  6 Feb 2016 19:04:32 +0800
Subject: [PATCH V3 6/6] coresight-stm: adding driver for CoreSight STM
 component
In-Reply-To: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <1454756672-12790-7-git-send-email-zhang.chunyan@linaro.org>

From: Pratik Patel <pratikp at codeaurora.org>

This driver adds support for the STM CoreSight IP block, allowing any
system compoment (HW or SW) to log and aggregate messages via a
single entity.

The CoreSight STM exposes an application defined number of channels
called stimulus port.  Configuration is done using entries in sysfs
and channels made available to userspace via configfs.

Signed-off-by: Pratik Patel <pratikp at codeaurora.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
---
 .../ABI/testing/sysfs-bus-coresight-devices-stm    |  53 ++
 Documentation/trace/coresight.txt                  |  37 +-
 drivers/hwtracing/coresight/Kconfig                |  11 +
 drivers/hwtracing/coresight/Makefile               |   1 +
 drivers/hwtracing/coresight/coresight-stm.c        | 928 +++++++++++++++++++++
 include/linux/coresight-stm.h                      |   6 +
 include/uapi/linux/coresight-stm.h                 |  12 +
 7 files changed, 1046 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
 create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
 create mode 100644 include/linux/coresight-stm.h
 create mode 100644 include/uapi/linux/coresight-stm.h

diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
new file mode 100644
index 0000000..a1d7022
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
@@ -0,0 +1,53 @@
+What:		/sys/bus/coresight/devices/<memory_map>.stm/enable_source
+Date:		February 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Enable/disable tracing on this specific trace macrocell.
+		Enabling the trace macrocell implies it has been configured
+		properly and a sink has been identidifed for it.  The path
+		of coresight components linking the source to the sink is
+		configured and managed automatically by the coresight framework.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/hwevent_enable
+Date:		February 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Provides access to the HW event enable register, used in
+		conjunction with HW event bank select register.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/hwevent_select
+Date:		February 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Gives access to the HW event block select register
+		(STMHEBSR) in order to configure up to 256 channels.  Used in
+		conjunction with "hwevent_enable" register as described above.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/port_enable
+Date:		February 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Provides access to the stimlus port enable register
+		(STMSPER).  Used in conjunction with "port_select" described
+		below.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/port_select
+Date:		February 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Used to determine which bank of stimulus port bit in
+		register STMSPER (see above) apply to.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/status
+Date:		February 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(R) List various control and status registers.  The specific
+		layout and content is driver specific.
+
+What:		/sys/bus/coresight/devices/<memory_map>.stm/traceid
+Date:		February 2016
+KernelVersion:	4.5
+Contact:	Mathieu Poirier <mathieu.poirier at linaro.org>
+Description:	(RW) Holds the trace ID that will appear in the trace stream
+		coming from this trace entity.
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
index 0a5c329..a33c88c 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -190,8 +190,8 @@ expected to be accessed and controlled using those entries.
 Last but not least, "struct module *owner" is expected to be set to reflect
 the information carried in "THIS_MODULE".
 
-How to use
-----------
+How to use the tracer modules
+-----------------------------
 
 Before trace collection can start, a coresight sink needs to be identify.
 There is no limit on the amount of sinks (nor sources) that can be enabled at
@@ -297,3 +297,36 @@ Info                                    Tracing enabled
 Instruction     13570831        0x8026B584      E28DD00C        false   ADD      sp,sp,#0xc
 Instruction     0       0x8026B588      E8BD8000        true    LDM      sp!,{pc}
 Timestamp                                       Timestamp: 17107041535
+
+How to use the STM module
+-------------------------
+
+Using the System Trace Macrocell module is the same as the tracers - the only
+difference is that clients are driving the trace capture rather
+than the program flow through the code.
+
+As with any other CoreSight component, specifics about the STM tracer can be
+found in sysfs with more information on each entry being found in [1]:
+
+root at genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
+enable_source   hwevent_select  port_enable     subsystem       uevent
+hwevent_enable  mgmt            port_select     traceid
+root at genericarmv8:~#
+
+Like any other source a sink needs to be identified and the STM enabled before
+being used:
+
+root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
+root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
+
+From there user space applications can request and use channels using the devfs
+interface provided for that purpose by the generic STM API:
+
+root at genericarmv8:~# ls -l /dev/20100000.stm
+crw-------    1 root     root       10,  61 Jan  3 18:11 /dev/20100000.stm
+root at genericarmv8:~#
+
+Details on how to use the generic STM API can be found here [2].
+
+[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
+[2]. Documentation/trace/stm.txt
diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
index c85935f..f4a8bfa 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -77,4 +77,15 @@ config CORESIGHT_QCOM_REPLICATOR
 	  programmable ATB replicator sends the ATB trace stream from the
 	  ETB/ETF to the TPIUi and ETR.
 
+config CORESIGHT_STM
+	bool "CoreSight System Trace Macrocell driver"
+	depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) || ARM64
+	select CORESIGHT_LINKS_AND_SINKS
+	select STM
+	help
+	  This driver provides support for hardware assisted software
+	  instrumentation based tracing. This is primarily used for
+	  logging useful software events or data coming from various entities
+	  in the system, possibly running different OSs
+
 endif
diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 99f8e5f..1f6eaec 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_CORESIGHT_LINKS_AND_SINKS) += coresight-funnel.o \
 obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o coresight-etm-cp14.o
 obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
 obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
+obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
new file mode 100644
index 0000000..01b3521
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -0,0 +1,928 @@
+/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Initial implementation by Pratik Patel
+ * (C) 2014-2015 Pratik Patel <pratikp at codeaurora.org>
+ *
+ * Serious refactoring, code cleanup and upgrading to the Coresight upstream
+ * framework by Mathieu Poirier
+ * (C) 2015-2016 Mathieu Poirier <mathieu.poirier at linaro.org>
+ *
+ * Guaranteed timing and support for various packet type coming from the
+ * generic STM API by Chunyan Zhang
+ * (C) 2015-2016 Chunyan Zhang <zhang.chunyan at linaro.org>
+ */
+#include <linux/amba/bus.h>
+#include <linux/bitmap.h>
+#include <linux/clk.h>
+#include <linux/coresight.h>
+#include <linux/coresight-stm.h>
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/pm_runtime.h>
+#include <linux/stm.h>
+
+#include "coresight-priv.h"
+
+#define STMDMASTARTR			0xc04
+#define STMDMASTOPR			0xc08
+#define STMDMASTATR			0xc0c
+#define STMDMACTLR			0xc10
+#define STMDMAIDR			0xcfc
+#define STMHEER				0xd00
+#define STMHETER			0xd20
+#define STMHEBSR			0xd60
+#define STMHEMCR			0xd64
+#define STMHEMASTR			0xdf4
+#define STMHEFEAT1R			0xdf8
+#define STMHEIDR			0xdfc
+#define STMSPER				0xe00
+#define STMSPTER			0xe20
+#define STMPRIVMASKR			0xe40
+#define STMSPSCR			0xe60
+#define STMSPMSCR			0xe64
+#define STMSPOVERRIDER			0xe68
+#define STMSPMOVERRIDER			0xe6c
+#define STMSPTRIGCSR			0xe70
+#define STMTCSR				0xe80
+#define STMTSSTIMR			0xe84
+#define STMTSFREQR			0xe8c
+#define STMSYNCR			0xe90
+#define STMAUXCR			0xe94
+#define STMSPFEAT1R			0xea0
+#define STMSPFEAT2R			0xea4
+#define STMSPFEAT3R			0xea8
+#define STMITTRIGGER			0xee8
+#define STMITATBDATA0			0xeec
+#define STMITATBCTR2			0xef0
+#define STMITATBID			0xef4
+#define STMITATBCTR0			0xef8
+
+#define STM_32_CHANNEL			32
+#define BYTES_PER_CHANNEL		256
+#define STM_TRACE_BUF_SIZE		4096
+#define STM_SW_MASTER_END		127
+
+/* Register bit definition */
+#define STMTCSR_BUSY_BIT		23
+/* Reserve the first 10 channels for kernel usage */
+#define STM_CHANNEL_OFFSET		0
+
+enum stm_pkt_type {
+	STM_PKT_TYPE_DATA	= 0x98,
+	STM_PKT_TYPE_FLAG	= 0xE8,
+	STM_PKT_TYPE_TRIG	= 0xF8,
+};
+
+#define stm_channel_addr(drvdata, ch)	(drvdata->chs.base +	\
+					(ch * BYTES_PER_CHANNEL))
+#define stm_channel_off(type, opts)	(type & ~opts)
+
+static int boot_nr_channel;
+
+module_param_named(
+	boot_nr_channel, boot_nr_channel, int, S_IRUGO
+);
+
+/**
+ * struct channel_space - central management entity for extended ports
+ * @base:		memory mapped base address where channels start.
+ * @guaraneed:		is the channel delivery guaranteed.
+ */
+struct channel_space {
+	void __iomem		*base;
+	unsigned long		*guaranteed;
+};
+
+/**
+ * struct stm_drvdata - specifics associated to an STM component
+ * @base:		memory mapped base address for this component.
+ * @dev:		the device entity associated to this component.
+ * @atclk:		optional clock for the core parts of the STM.
+ * @csdev:		component vitals needed by the framework.
+ * @spinlock:		only one at a time pls.
+ * @chs:		the channels accociated to this STM.
+ * @stm:		structure associated to the generic STM interface.
+ * @enable:		this STM is being used.
+ * @traceid:		value of the current ID for this component.
+ * @write_max:	        Maximus bytes this STM can write at a time.
+ * @write_64bit:	whether this STM supports 64 bit access.
+ * @stmsper:		settings for register STMSPER.
+ * @stmspscr:		settings for register STMSPSCR.
+ * @numsp:		the total number of stimulus port support by this STM.
+ * @stmheer:		settings for register STMHEER.
+ * @stmheter:		settings for register STMHETER.
+ * @stmhebsr:		settings for register STMHEBSR.
+ */
+struct stm_drvdata {
+	void __iomem		*base;
+	struct device		*dev;
+	struct clk		*atclk;
+	struct coresight_device	*csdev;
+	spinlock_t		spinlock;
+	struct channel_space	chs;
+	struct stm_data		stm;
+	bool			enable;
+	u8			traceid;
+	u8			write_max;
+	u32			write_64bit;
+	u32			stmsper;
+	u32			stmspscr;
+	u32			numsp;
+	u32			stmheer;
+	u32			stmheter;
+	u32			stmhebsr;
+};
+
+static void stm_hwevent_enable_hw(struct stm_drvdata *drvdata)
+{
+	CS_UNLOCK(drvdata->base);
+
+	writel_relaxed(drvdata->stmhebsr, drvdata->base + STMHEBSR);
+	writel_relaxed(drvdata->stmheter, drvdata->base + STMHETER);
+	writel_relaxed(drvdata->stmheer, drvdata->base + STMHEER);
+	writel_relaxed(0x01 |	/* Enable HW event tracing */
+		       0x04,	/* Error detection on event tracing */
+		       drvdata->base + STMHEMCR);
+
+	CS_LOCK(drvdata->base);
+}
+
+static void stm_port_enable_hw(struct stm_drvdata *drvdata)
+{
+	CS_UNLOCK(drvdata->base);
+	/* ATB trigger enable on direct writes to TRIG locations */
+	writel_relaxed(0x10,
+		       drvdata->base + STMSPTRIGCSR);
+	writel_relaxed(drvdata->stmspscr, drvdata->base + STMSPSCR);
+	writel_relaxed(drvdata->stmsper, drvdata->base + STMSPER);
+
+	CS_LOCK(drvdata->base);
+}
+
+static void stm_enable_hw(struct stm_drvdata *drvdata)
+{
+	if (drvdata->stmheer)
+		stm_hwevent_enable_hw(drvdata);
+
+	stm_port_enable_hw(drvdata);
+
+	CS_UNLOCK(drvdata->base);
+
+	/* 4096 byte between synchronisation packets */
+	writel_relaxed(0xFFF, drvdata->base + STMSYNCR);
+	writel_relaxed((drvdata->traceid << 16 | /* trace id */
+			0x02 |			 /* timestamp enable */
+			0x01),			 /* global STM enable */
+			drvdata->base + STMTCSR);
+
+	CS_LOCK(drvdata->base);
+}
+
+static int stm_enable(struct coresight_device *csdev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	pm_runtime_get_sync(drvdata->dev);
+
+	spin_lock(&drvdata->spinlock);
+	stm_enable_hw(drvdata);
+	drvdata->enable = true;
+	spin_unlock(&drvdata->spinlock);
+
+	dev_info(drvdata->dev, "STM tracing enabled\n");
+	return 0;
+}
+
+static void stm_hwevent_disable_hw(struct stm_drvdata *drvdata)
+{
+	CS_UNLOCK(drvdata->base);
+
+	writel_relaxed(0x0, drvdata->base + STMHEMCR);
+	writel_relaxed(0x0, drvdata->base + STMHEER);
+	writel_relaxed(0x0, drvdata->base + STMHETER);
+
+	CS_LOCK(drvdata->base);
+}
+
+static void stm_port_disable_hw(struct stm_drvdata *drvdata)
+{
+	CS_UNLOCK(drvdata->base);
+
+	writel_relaxed(0x0, drvdata->base + STMSPER);
+	writel_relaxed(0x0, drvdata->base + STMSPTRIGCSR);
+
+	CS_LOCK(drvdata->base);
+}
+
+static void stm_disable_hw(struct stm_drvdata *drvdata)
+{
+	u32 val;
+
+	CS_UNLOCK(drvdata->base);
+
+	val = readl_relaxed(drvdata->base + STMTCSR);
+	val &= ~0x1; /* clear global STM enable [0] */
+	writel_relaxed(val, drvdata->base + STMTCSR);
+
+	CS_LOCK(drvdata->base);
+
+	stm_port_disable_hw(drvdata);
+	if (drvdata->stmheer)
+		stm_hwevent_disable_hw(drvdata);
+}
+
+static void stm_disable(struct coresight_device *csdev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	spin_lock(&drvdata->spinlock);
+	stm_disable_hw(drvdata);
+	drvdata->enable = false;
+	spin_unlock(&drvdata->spinlock);
+
+	/* Wait until the engine has completely stopped */
+	coresight_timeout(drvdata, STMTCSR, STMTCSR_BUSY_BIT, 0);
+
+	pm_runtime_put(drvdata->dev);
+
+	dev_info(drvdata->dev, "STM tracing disabled\n");
+}
+
+static int stm_trace_id(struct coresight_device *csdev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	return drvdata->traceid;
+}
+
+static const struct coresight_ops_source stm_source_ops = {
+	.trace_id	= stm_trace_id,
+	.enable		= stm_enable,
+	.disable	= stm_disable,
+};
+
+static const struct coresight_ops stm_cs_ops = {
+	.source_ops	= &stm_source_ops,
+};
+
+static inline bool stm_addr_unaligned(const void *addr, u8 max)
+{
+	return ((unsigned long)addr & (max - 1));
+}
+
+static int stm_send(void *addr, const void *data, u32 size, u8 max)
+{
+	u32 len = size;
+	u8 paload[8];
+
+	if (stm_addr_unaligned(data, max)) {
+		memcpy(paload, data, size);
+		data = paload;
+	}
+
+	/* now we are 64bit/32bit aligned */
+#ifdef CONFIG_64BIT
+	if (size == 8)
+		writeq_relaxed(*(u64 *)data, addr);
+#endif
+	if (size >= 4) {
+		writel_relaxed(*(u32 *)data, addr);
+		data += 4;
+		size -= 4;
+	}
+
+	if (size >= 2) {
+		writew_relaxed(*(u16 *)data, addr);
+		data += 2;
+		size -= 2;
+	}
+
+	if (size == 1)
+		writeb_relaxed(*(u8 *)data, addr);
+
+	return len;
+}
+
+static int stm_generic_link(struct stm_data *stm_data,
+			    unsigned int master,  unsigned int channel)
+{
+	struct stm_drvdata *drvdata = container_of(stm_data,
+						   struct stm_drvdata, stm);
+	if (!drvdata || !drvdata->csdev)
+		return -EINVAL;
+
+	return coresight_enable(drvdata->csdev);
+}
+
+static void stm_generic_unlink(struct stm_data *stm_data,
+			       unsigned int master,  unsigned int channel)
+{
+	struct stm_drvdata *drvdata = container_of(stm_data,
+						   struct stm_drvdata, stm);
+	if (!drvdata || !drvdata->csdev)
+		return;
+
+	stm_disable(drvdata->csdev);
+}
+
+static long stm_generic_set_options(struct stm_data *stm_data,
+				    unsigned int master,
+				    unsigned int channel,
+				    unsigned int nr_chans,
+				    unsigned long options)
+{
+	struct stm_drvdata *drvdata = container_of(stm_data,
+						   struct stm_drvdata, stm);
+	if (!(drvdata && drvdata->enable))
+		return -EINVAL;
+
+	if (channel >= drvdata->numsp)
+		return -EINVAL;
+
+	switch (options) {
+	case STM_OPTION_GUARANTEED:
+		set_bit(channel, drvdata->chs.guaranteed);
+		break;
+
+	case STM_OPTION_INVARIANT:
+		clear_bit(channel, drvdata->chs.guaranteed);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static long stm_generic_get_options(struct stm_data *stm_data,
+				    unsigned int master,
+				    unsigned int channel,
+				    unsigned int nr_chans,
+				    u64 *options)
+{
+	struct stm_drvdata *drvdata = container_of(stm_data,
+						   struct stm_drvdata, stm);
+	if (!(drvdata && drvdata->enable))
+		return -EINVAL;
+
+	if (channel >= drvdata->numsp)
+		return -EINVAL;
+
+	switch (*options) {
+	case STM_OPTION_GUARANTEED:
+		*options = test_bit(channel, drvdata->chs.guaranteed);
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static ssize_t stm_generic_packet(struct stm_data *stm_data,
+				  unsigned int master,
+				  unsigned int channel,
+				  unsigned int packet,
+				  unsigned int flags,
+				  unsigned int size,
+				  const unsigned char *payload)
+{
+	unsigned long ch_addr;
+	struct stm_drvdata *drvdata = container_of(stm_data,
+						   struct stm_drvdata, stm);
+
+	if (!(drvdata && drvdata->enable))
+		return 0;
+
+	if (channel >= drvdata->numsp)
+		return 0;
+
+	ch_addr = (unsigned long)stm_channel_addr(drvdata, channel);
+
+	flags = (flags == STP_PACKET_TIMESTAMPED) ? STM_FLAG_TIMESTAMPED : 0;
+	flags |= test_bit(channel, drvdata->chs.guaranteed) ?
+			   STM_FLAG_GUARANTEED : 0;
+
+	if (size > drvdata->write_max)
+		size = drvdata->write_max;
+
+	switch (packet) {
+	case STP_PACKET_FLAG:
+		ch_addr |= stm_channel_off(STM_PKT_TYPE_FLAG, flags);
+
+		/* the generic STM API set a size of zero on flag packets. */
+		size = 1;
+		break;
+
+	case STP_PACKET_DATA:
+		ch_addr |= stm_channel_off(STM_PKT_TYPE_DATA, flags);
+		break;
+
+	default:
+		return 0;
+	}
+
+	return stm_send((void *)ch_addr, payload, size, drvdata->write_max);
+}
+
+static ssize_t hwevent_enable_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val = drvdata->stmheer;
+
+	return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
+}
+
+static ssize_t hwevent_enable_store(struct device *dev,
+				    struct device_attribute *attr,
+				    const char *buf, size_t size)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val;
+	int ret = 0;
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return -EINVAL;
+
+	drvdata->stmheer = val;
+	/* HW event enable and trigger go hand in hand */
+	drvdata->stmheter = val;
+
+	return size;
+}
+static DEVICE_ATTR_RW(hwevent_enable);
+
+static ssize_t hwevent_select_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val = drvdata->stmhebsr;
+
+	return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
+}
+
+static ssize_t hwevent_select_store(struct device *dev,
+				    struct device_attribute *attr,
+				    const char *buf, size_t size)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val;
+	int ret = 0;
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return -EINVAL;
+
+	drvdata->stmhebsr = val;
+
+	return size;
+}
+static DEVICE_ATTR_RW(hwevent_select);
+
+static ssize_t port_select_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val;
+
+	if (!drvdata->enable) {
+		val = drvdata->stmspscr;
+	} else {
+		spin_lock(&drvdata->spinlock);
+		val = readl_relaxed(drvdata->base + STMSPSCR);
+		spin_unlock(&drvdata->spinlock);
+	}
+
+	return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
+}
+
+static ssize_t port_select_store(struct device *dev,
+				 struct device_attribute *attr,
+				 const char *buf, size_t size)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val, stmsper;
+	int ret = 0;
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->stmspscr = val;
+
+	if (drvdata->enable) {
+		CS_UNLOCK(drvdata->base);
+		/* Process as per ARM's TRM recommendation */
+		stmsper = readl_relaxed(drvdata->base + STMSPER);
+		writel_relaxed(0x0, drvdata->base + STMSPER);
+		writel_relaxed(drvdata->stmspscr, drvdata->base + STMSPSCR);
+		writel_relaxed(stmsper, drvdata->base + STMSPER);
+		CS_LOCK(drvdata->base);
+	}
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(port_select);
+
+static ssize_t port_enable_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val;
+
+	if (!drvdata->enable) {
+		val = drvdata->stmsper;
+	} else {
+		spin_lock(&drvdata->spinlock);
+		val = readl_relaxed(drvdata->base + STMSPER);
+		spin_unlock(&drvdata->spinlock);
+	}
+
+	return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
+}
+
+static ssize_t port_enable_store(struct device *dev,
+				 struct device_attribute *attr,
+				 const char *buf, size_t size)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	unsigned long val;
+	int ret = 0;
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->stmsper = val;
+
+	if (drvdata->enable) {
+		CS_UNLOCK(drvdata->base);
+		writel_relaxed(drvdata->stmsper, drvdata->base + STMSPER);
+		CS_LOCK(drvdata->base);
+	}
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(port_enable);
+
+static ssize_t traceid_show(struct device *dev,
+			    struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->traceid;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t traceid_store(struct device *dev,
+			     struct device_attribute *attr,
+			     const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	/* traceid field is 7bit wide on STM32 */
+	drvdata->traceid = val & 0x7f;
+	return size;
+}
+static DEVICE_ATTR_RW(traceid);
+
+#define coresight_simple_func(type, name, offset)			\
+static ssize_t name##_show(struct device *_dev,				\
+			   struct device_attribute *attr, char *buf)	\
+{									\
+	type *drvdata = dev_get_drvdata(_dev->parent);			\
+	return scnprintf(buf, PAGE_SIZE, "0x%08x\n",			\
+			 readl_relaxed(drvdata->base + offset));	\
+}									\
+DEVICE_ATTR_RO(name)
+
+#define coresight_stm_simple_func(name, offset)	\
+	coresight_simple_func(struct stm_drvdata, name, offset)
+
+coresight_stm_simple_func(tcsr, STMTCSR);
+coresight_stm_simple_func(tsfreqr, STMTSFREQR);
+coresight_stm_simple_func(syncr, STMSYNCR);
+coresight_stm_simple_func(sper, STMSPER);
+coresight_stm_simple_func(spter, STMSPTER);
+coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
+coresight_stm_simple_func(spscr, STMSPSCR);
+coresight_stm_simple_func(spmscr, STMSPMSCR);
+coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
+coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
+coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
+coresight_stm_simple_func(devid, CORESIGHT_DEVID);
+
+static struct attribute *coresight_stm_attrs[] = {
+	&dev_attr_hwevent_enable.attr,
+	&dev_attr_hwevent_select.attr,
+	&dev_attr_port_enable.attr,
+	&dev_attr_port_select.attr,
+	&dev_attr_traceid.attr,
+	NULL,
+};
+
+static struct attribute *coresight_stm_mgmt_attrs[] = {
+	&dev_attr_tcsr.attr,
+	&dev_attr_tsfreqr.attr,
+	&dev_attr_syncr.attr,
+	&dev_attr_sper.attr,
+	&dev_attr_spter.attr,
+	&dev_attr_privmaskr.attr,
+	&dev_attr_spscr.attr,
+	&dev_attr_spmscr.attr,
+	&dev_attr_spfeat1r.attr,
+	&dev_attr_spfeat2r.attr,
+	&dev_attr_spfeat3r.attr,
+	&dev_attr_devid.attr,
+	NULL,
+};
+
+static const struct attribute_group coresight_stm_group = {
+	.attrs = coresight_stm_attrs,
+};
+
+static const struct attribute_group coresight_stm_mgmt_group = {
+	.attrs = coresight_stm_mgmt_attrs,
+	.name = "mgmt",
+};
+
+static const struct attribute_group *coresight_stm_groups[] = {
+	&coresight_stm_group,
+	&coresight_stm_mgmt_group,
+	NULL,
+};
+
+static int stm_get_resource_byname(struct device_node *np,
+				   char *ch_base, struct resource *res)
+{
+	const char *name = NULL;
+	int index = 0, found = 0;
+
+	while (!of_property_read_string_index(np, "reg-names", index, &name)) {
+		if (strcmp(ch_base, name)) {
+			index++;
+			continue;
+		}
+
+		/* We have a match and @index is where it's at */
+		found = 1;
+		break;
+	}
+
+	if (!found)
+		return -EINVAL;
+
+	return of_address_to_resource(np, index, res);
+}
+
+static u32 stm_fundamental_data_size(struct stm_drvdata *drvdata)
+{
+	u32 stmspfeat2r;
+
+	stmspfeat2r = readl_relaxed(drvdata->base + STMSPFEAT2R);
+	return BMVAL(stmspfeat2r, 12, 15);
+}
+
+static u32 stm_num_stimulus_port(struct stm_drvdata *drvdata)
+{
+	u32 numsp;
+
+	numsp = readl_relaxed(drvdata->base + CORESIGHT_DEVID);
+	/*
+	 * NUMPS in STMDEVID is 17 bit long and if equal to 0x0,
+	 * 32 stimulus ports are supported.
+	 */
+	numsp &= 0x1ffff;
+	if (!numsp)
+		numsp = STM_32_CHANNEL;
+	return numsp;
+}
+
+static void stm_init_default_data(struct stm_drvdata *drvdata)
+{
+	/* Don't use port selection */
+	drvdata->stmspscr = 0x0;
+	/*
+	 * Enable all channel regardless of their number.  When port
+	 * selection isn't used (see above) STMSPER applies to all
+	 * 32 channel group available, hence setting all 32 bits to 1
+	 */
+	drvdata->stmsper = ~0x0;
+
+	/*
+	 * Select arbitrary value to start with.  If there is a conflict
+	 * with other tracers the framework will deal with it.
+	 */
+	drvdata->traceid = 0x20;
+
+	/* Set invariant transaction timing on all channels */
+	bitmap_clear(drvdata->chs.guaranteed, 0, drvdata->numsp);
+}
+
+static void stm_init_generic_data(struct stm_drvdata *drvdata)
+{
+	drvdata->stm.name = dev_name(drvdata->dev);
+	drvdata->stm.mstatic = true;
+	drvdata->stm.sw_nchannels = drvdata->numsp;
+	drvdata->stm.packet = stm_generic_packet;
+	drvdata->stm.link = stm_generic_link;
+	drvdata->stm.unlink = stm_generic_unlink;
+	drvdata->stm.set_options = stm_generic_set_options;
+	drvdata->stm.get_options = stm_generic_get_options;
+}
+
+static int stm_probe(struct amba_device *adev, const struct amba_id *id)
+{
+	int ret;
+	void __iomem *base;
+	unsigned long *guaranteed;
+	struct device *dev = &adev->dev;
+	struct coresight_platform_data *pdata = NULL;
+	struct stm_drvdata *drvdata;
+	struct resource *res = &adev->res;
+	struct resource ch_res;
+	size_t res_size, bitmap_size;
+	struct coresight_desc *desc;
+	struct device_node *np = adev->dev.of_node;
+
+	if (np) {
+		pdata = of_get_coresight_platform_data(dev, np);
+		if (IS_ERR(pdata))
+			return PTR_ERR(pdata);
+		adev->dev.platform_data = pdata;
+	}
+	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+
+	drvdata->dev = &adev->dev;
+	drvdata->atclk = devm_clk_get(&adev->dev, "atclk"); /* optional */
+	if (!IS_ERR(drvdata->atclk)) {
+		ret = clk_prepare_enable(drvdata->atclk);
+		if (ret)
+			return ret;
+	}
+	dev_set_drvdata(dev, drvdata);
+
+	base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+	drvdata->base = base;
+
+	ret = stm_get_resource_byname(np, "stm-stimulus-base", &ch_res);
+	if (ret)
+		return ret;
+
+	base = devm_ioremap_resource(dev, &ch_res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+	drvdata->chs.base = base;
+
+	drvdata->write_max = sizeof(u32);
+	drvdata->write_64bit = stm_fundamental_data_size(drvdata);
+
+#ifndef CONFIG_64BIT
+	if (drvdata->write_64bit)
+		drvdata->write_max = sizeof(u64);
+#endif
+
+	if (boot_nr_channel) {
+		drvdata->numsp = boot_nr_channel;
+		res_size = min((resource_size_t)(boot_nr_channel *
+				  BYTES_PER_CHANNEL), resource_size(res));
+	} else {
+		drvdata->numsp = stm_num_stimulus_port(drvdata);
+		res_size = min((resource_size_t)(drvdata->numsp *
+				 BYTES_PER_CHANNEL), resource_size(res));
+	}
+	bitmap_size = BITS_TO_LONGS(drvdata->numsp) * sizeof(long);
+
+	guaranteed = devm_kzalloc(dev, bitmap_size, GFP_KERNEL);
+	if (!guaranteed)
+		return -ENOMEM;
+	drvdata->chs.guaranteed = guaranteed;
+
+	spin_lock_init(&drvdata->spinlock);
+
+	stm_init_default_data(drvdata);
+	stm_init_generic_data(drvdata);
+
+	if (stm_register_device(dev, &drvdata->stm, THIS_MODULE)) {
+		dev_info(dev,
+			 "stm_register_device failed, probing deffered\n");
+		return -EPROBE_DEFER;
+	}
+
+	desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
+	if (!desc) {
+		ret = -ENOMEM;
+		goto stm_unregister;
+	}
+
+	desc->type = CORESIGHT_DEV_TYPE_SOURCE;
+	desc->subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE;
+	desc->ops = &stm_cs_ops;
+	desc->pdata = pdata;
+	desc->dev = dev;
+	desc->groups = coresight_stm_groups;
+	drvdata->csdev = coresight_register(desc);
+	if (IS_ERR(drvdata->csdev)) {
+		ret = PTR_ERR(drvdata->csdev);
+		goto stm_unregister;
+	}
+
+	pm_runtime_put(&adev->dev);
+
+	dev_info(dev, "%s initialized\n", (char *)id->data);
+	return 0;
+
+stm_unregister:
+	stm_unregister_device(&drvdata->stm);
+	return ret;
+}
+
+static int stm_remove(struct amba_device *adev)
+{
+	struct stm_drvdata *drvdata = amba_get_drvdata(adev);
+
+	stm_unregister_device(&drvdata->stm);
+	coresight_unregister(drvdata->csdev);
+	return 0;
+}
+
+#ifdef CONFIG_PM
+static int stm_runtime_suspend(struct device *dev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev);
+
+	if (drvdata && !IS_ERR(drvdata->atclk))
+		clk_disable_unprepare(drvdata->atclk);
+
+	return 0;
+}
+
+static int stm_runtime_resume(struct device *dev)
+{
+	struct stm_drvdata *drvdata = dev_get_drvdata(dev);
+
+	if (drvdata && !IS_ERR(drvdata->atclk))
+		clk_prepare_enable(drvdata->atclk);
+
+	return 0;
+}
+#endif
+
+static const struct dev_pm_ops stm_dev_pm_ops = {
+	SET_RUNTIME_PM_OPS(stm_runtime_suspend, stm_runtime_resume, NULL)
+};
+
+static struct amba_id stm_ids[] = {
+	{
+		.id     = 0x0003b962,
+		.mask   = 0x0003ffff,
+		.data	= "STM32",
+	},
+	{ 0, 0},
+};
+
+static struct amba_driver stm_driver = {
+	.drv = {
+		.name   = "coresight-stm",
+		.owner	= THIS_MODULE,
+		.pm	= &stm_dev_pm_ops,
+	},
+	.probe          = stm_probe,
+	.remove         = stm_remove,
+	.id_table	= stm_ids,
+};
+
+module_amba_driver(stm_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("CoreSight System Trace Macrocell driver");
diff --git a/include/linux/coresight-stm.h b/include/linux/coresight-stm.h
new file mode 100644
index 0000000..a978bb8
--- /dev/null
+++ b/include/linux/coresight-stm.h
@@ -0,0 +1,6 @@
+#ifndef __LINUX_CORESIGHT_STM_H_
+#define __LINUX_CORESIGHT_STM_H_
+
+#include <uapi/linux/coresight-stm.h>
+
+#endif
diff --git a/include/uapi/linux/coresight-stm.h b/include/uapi/linux/coresight-stm.h
new file mode 100644
index 0000000..fa35f0b
--- /dev/null
+++ b/include/uapi/linux/coresight-stm.h
@@ -0,0 +1,12 @@
+#ifndef __UAPI_CORESIGHT_STM_H_
+#define __UAPI_CORESIGHT_STM_H_
+
+#define STM_FLAG_TIMESTAMPED   BIT(3)
+#define STM_FLAG_GUARANTEED    BIT(7)
+
+enum {
+	STM_OPTION_GUARANTEED = 0,
+	STM_OPTION_INVARIANT,
+};
+
+#endif
-- 
1.9.1



From xypron.glpk at gmx.de  Sat Feb  6 03:30:26 2016
From: xypron.glpk at gmx.de (Heinrich Schuchardt)
Date: Sat,  6 Feb 2016 12:30:26 +0100
Subject: [PATCH 1/1] imx6q-wandboard-revb1.dts: use unique machine name
Message-ID: <1454758226-4561-1-git-send-email-xypron.glpk@gmx.de>

Downstream packages like Debian flash-install use
/proc/device-tree/model
to determine which dtb file to install.

Hence each dts in the Linux kernel should provide a unique model identifier.

https://lkml.org/lkml/2014/7/8/579 created the new file
imx6q-wandboard-revb1.dts but used the same model identifier
as in imx6q-wandboard.dts.

This patch provides a unique model identifier for revision B1 of
the Wandboard Quad.

Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
---
 arch/arm/boot/dts/imx6q-wandboard-revb1.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6q-wandboard-revb1.dts b/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
index 20bf3c2..9207d80 100644
--- a/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
+++ b/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
@@ -13,7 +13,7 @@
 #include "imx6qdl-wandboard-revb1.dtsi"
 
 / {
-	model = "Wandboard i.MX6 Quad Board";
+	model = "Wandboard i.MX6 Quad Board rev B1";
 	compatible = "wand,imx6q-wandboard", "fsl,imx6q";
 
 	memory {
-- 
2.1.4



From sergei.shtylyov at cogentembedded.com  Sat Feb  6 03:52:12 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 6 Feb 2016 14:52:12 +0300
Subject: [PATCH net-next V2 7/8] net: fec: don't transfer ownership until
 descriptor write is complete
In-Reply-To: <1454709170-19527-8-git-send-email-troy.kisky@boundarydevices.com>
References: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
 <1454709170-19527-8-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <56B5DE6C.9080407@cogentembedded.com>

Hello.

On 2/6/2016 12:52 AM, Troy Kisky wrote:

> If you don't own it, you shouldn't write to it.
>
> Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
> ---
>   drivers/net/ethernet/freescale/fec_main.c | 14 +++++++++++++-
>   1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
> index ca2708d..97ca72a 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -390,6 +390,10 @@ fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
>
>   		bdp->cbd_bufaddr = cpu_to_fec32(addr);
>   		bdp->cbd_datlen = cpu_to_fec16(frag_len);
> +		/* Make sure the updates to rest of the descriptor are
> +		 * performed before transferring ownership.
> +		 */
> +		wmb();
>   		bdp->cbd_sc = cpu_to_fec16(status);
>   	}
>
> @@ -499,6 +503,10 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
>
>   	bdp->cbd_datlen = cpu_to_fec16(buflen);
>   	bdp->cbd_bufaddr = cpu_to_fec32(addr);
> +	/* Make sure the updates to rest of the descriptor are performed before
> +	 * transferring ownership.
> +	 */
> +	wmb();
>
>   	/* Send it on its way.  Tell FEC it's ready, interrupt when done,
>   	 * it's the last BD of the frame, and to put the CRC on the end.
[...]
> @@ -1484,6 +1491,11 @@ rx_processing_done:
>   			ebdp->cbd_prot = 0;
>   			ebdp->cbd_bdu = 0;
>   		}
> +		/* Make sure the updates to rest of the descriptor are
> +		 * performed before transferring ownership.
> +		 */
> +		wmb();
> +		bdp->cbd_sc = cpu_to_fec16(status);

    I think you can use "ligter" dma_wmb() in this case.

[...]

MBR, Sergei



From kvalo at codeaurora.org  Sat Feb  6 03:59:45 2016
From: kvalo at codeaurora.org (Kalle Valo)
Date: Sat,  6 Feb 2016 11:59:45 +0000 (UTC)
Subject: [v2] hostap: avoid uninitialized variable use in hfa384x_get_rid
In-Reply-To: <18181682.hKPVvnQWXk@wuerfel>
Message-ID: <20160206115945.2A872604F6@smtp.codeaurora.org>


> The driver reads a value from hfa384x_from_bap(), which may fail,
> and then assigns the value to a local variable. gcc detects that
> in in the failure case, the 'rlen' variable now contains
> uninitialized data:
> 
> In file included from ../drivers/net/wireless/intersil/hostap/hostap_pci.c:220:0:
> drivers/net/wireless/intersil/hostap/hostap_hw.c: In function 'hfa384x_get_rid':
> drivers/net/wireless/intersil/hostap/hostap_hw.c:842:5: warning: 'rec' may be used uninitialized in this function [-Wmaybe-uninitialized]
>   if (le16_to_cpu(rec.len) == 0) {
> 
> This restructures the function as suggested by Russell King, to
> make it more readable and get more reliable error handling, by
> handling each failure mode using a goto.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Thanks, applied to wireless-drivers-next.git.

Kalle Valo


From marc.zyngier at arm.com  Sat Feb  6 04:05:24 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Sat, 6 Feb 2016 12:05:24 +0000
Subject: [PATCH] arm64: KVM: Add 48bit PA support for EL2  translations
In-Reply-To: <1454700496-21221-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1454700496-21221-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <20160206120524.09b9f893@arm.com>

Tirumalesh,

On Fri, 5 Feb 2016 11:28:16 -0800
<tchalamarla at caviumnetworks.com> wrote:

> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> 
> Systems where RAM is at higher address and MultiNode systems

What influence a "MultiNode" (for whatever definition of node you have)
system has on the memory map?

> whith higher address RAM, 39 bit max PA for EL2 translations
> is not sufficient.

I read it as 40 bits, not 39.

> 
> This patch sets max possible PA(48bit) for EL2 translations.

From the ARM ARM:

"If {I}PS is programmed to a value larger than the implemented physical
address size, then the PE behaves as if programmed with the implemented
physical address size, but software must not rely on this behavior.
That is, the output address size is never larger than the implemented
physical address size."

> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> ---
>  arch/arm64/include/asm/kvm_arm.h | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 738a95f..3fc38a4 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -98,7 +98,12 @@
>  #define TCR_EL2_RES1	((1 << 31) | (1 << 23))
>  #define TCR_EL2_TBI	(1 << 20)
>  #define TCR_EL2_PS	(7 << 16)
> +#define TCR_EL2_PS_32B	(0 << 16)
> +#define TCR_EL2_PS_36B	(1 << 16)
>  #define TCR_EL2_PS_40B	(2 << 16)
> +#define TCR_EL2_PS_42B	(3 << 16)
> +#define TCR_EL2_PS_44B	(4 << 16)
> +#define TCR_EL2_PS_48B	(5 << 16)
>  #define TCR_EL2_TG0	(1 << 14)
>  #define TCR_EL2_SH0	(3 << 12)
>  #define TCR_EL2_ORGN0	(3 << 10)
> @@ -107,7 +112,10 @@
>  #define TCR_EL2_MASK	(TCR_EL2_TG0 | TCR_EL2_SH0 | \
>  			 TCR_EL2_ORGN0 | TCR_EL2_IRGN0 | TCR_EL2_T0SZ)
>  
> -#define TCR_EL2_FLAGS	(TCR_EL2_RES1 | TCR_EL2_PS_40B)
> +/*
> + * Assign the highest possible PS.
> + */
> +#define TCR_EL2_FLAGS	(TCR_EL2_RES1 | TCR_EL2_PS_48B)
>  
>  /* VTCR_EL2 Registers bits */
>  #define VTCR_EL2_RES1		(1 << 31)

So this is a NAK. If you want to address this problem, do it properly
(hint: look at how we deal with VTCR_EL2).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.


From xypron.glpk at gmx.de  Sat Feb  6 04:06:59 2016
From: xypron.glpk at gmx.de (Heinrich Schuchardt)
Date: Sat,  6 Feb 2016 13:06:59 +0100
Subject: [PATCH 1/1 v2] imx6q-wandboard-revb1.dts: use unique machine name
In-Reply-To: <1454758226-4561-1-git-send-email-xypron.glpk@gmx.de>
References: <1454758226-4561-1-git-send-email-xypron.glpk@gmx.de>
Message-ID: <1454760419-4822-1-git-send-email-xypron.glpk@gmx.de>

Downstream packages like Debian flash-kernel use
/proc/device-tree/model
to determine which dtb file to install.

Hence each dts in the Linux kernel should provide a unique model identifier.

https://lkml.org/lkml/2014/7/8/579 created the new file
imx6q-wandboard-revb1.dts but used the same model identifier
as in imx6q-wandboard.dts.

This patch provides a unique model identifier for revision B1 of
the Wandboard Quad.

v2:
	correct name of referenced Debian package

Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
---
 arch/arm/boot/dts/imx6q-wandboard-revb1.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6q-wandboard-revb1.dts b/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
index 20bf3c2..9207d80 100644
--- a/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
+++ b/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
@@ -13,7 +13,7 @@
 #include "imx6qdl-wandboard-revb1.dtsi"
 
 / {
-	model = "Wandboard i.MX6 Quad Board";
+	model = "Wandboard i.MX6 Quad Board rev B1";
 	compatible = "wand,imx6q-wandboard", "fsl,imx6q";
 
 	memory {
-- 
2.1.4



From dvyukov at google.com  Sat Feb  6 04:30:18 2016
From: dvyukov at google.com (Dmitry Vyukov)
Date: Sat, 6 Feb 2016 13:30:18 +0100
Subject: [PATCH v8] kernel: add kcov code coverage
In-Reply-To: <20160204143007.674a7e847b4c8fed957bba7c@linux-foundation.org>
References: <1454600441-70701-1-git-send-email-dvyukov@google.com>
 <20160204143007.674a7e847b4c8fed957bba7c@linux-foundation.org>
Message-ID: <CACT4Y+YLOK0+T9n6bZuqoFZpMyn+z-PxHCRufdhXMjPEPfavPw@mail.gmail.com>

On Thu, Feb 4, 2016 at 11:30 PM, Andrew Morton
<akpm at linux-foundation.org> wrote:
> On Thu,  4 Feb 2016 16:40:41 +0100 Dmitry Vyukov <dvyukov at google.com> wrote:
>
>> kcov provides code coverage collection for coverage-guided fuzzing
>> (randomized testing). Coverage-guided fuzzing is a testing technique
>> that uses coverage feedback to determine new interesting inputs to a
>> system. A notable user-space example is AFL
>> (http://lcamtuf.coredump.cx/afl/). However, this technique is not
>> widely used for kernel testing due to missing compiler and kernel
>> support.
>>
>> kcov does not aim to collect as much coverage as possible. It aims
>> to collect more or less stable coverage that is function of syscall
>> inputs. To achieve this goal it does not collect coverage in
>> soft/hard interrupts and instrumentation of some inherently
>> non-deterministic or non-interesting parts of kernel is disbled
>> (e.g. scheduler, locking).
>>
>> Currently there is a single coverage collection mode (tracing),
>> but the API anticipates additional collection modes.
>> Initially I also implemented a second mode which exposes
>> coverage in a fixed-size hash table of counters (what Quentin
>> used in his original patch). I've dropped the second mode for
>> simplicity.
>>
>> This patch adds the necessary support on kernel side.
>> The complimentary compiler support was added in gcc revision 231296.
>>
>> We've used this support to build syzkaller system call fuzzer,
>> which has found 90 kernel bugs in just 2 months:
>> https://github.com/google/syzkaller/wiki/Found-Bugs
>> We've also found 30+ bugs in our internal systems with syzkaller.
>> Another (yet unexplored) direction where kcov coverage would greatly
>> help is more traditional "blob mutation". For example, mounting
>> a random blob as a filesystem, or receiving a random blob over wire.
>>
>> Why not gcov. Typical fuzzing loop looks as follows: (1) reset
>> coverage, (2) execute a bit of code, (3) collect coverage, repeat.
>> A typical coverage can be just a dozen of basic blocks (e.g. an
>> invalid input). In such context gcov becomes prohibitively expensive
>> as reset/collect coverage steps depend on total number of basic
>> blocks/edges in program (in case of kernel it is about 2M). Cost of
>> kcov depends only on number of executed basic blocks/edges. On top of
>> that, kernel requires per-thread coverage because there are
>> always background threads and unrelated processes that also produce
>> coverage. With inlined gcov instrumentation per-thread coverage is not
>> possible.
>>
>> kcov exposes kernel PCs and control flow to user-space which
>> is insecure. But debugfs should not be mapped as user accessible.
>
> So the proposed user interface is ioctls against /sys/kernel/debug/kcov.
>
> I guess that's OK.  We could just add sys_kcov() - syscalls are cheap
> enough.  But we store state within the fd, don't we?  So sys_kcov()
> would take an fd argument.
>
>> Based on a patch by Quentin Casasnovas.
>> Signed-off-by: Dmitry Vyukov <dvyukov at google.com>
>> Reviewed-by: Kees Cook <keescook at chromium.org>
>> ---
>> Anticipating reasonable questions regarding usage of this feature.
>> Quentin Casasnovas and Vegard Nossum also plan to use kcov for
>> coverage-guided fuzzing. Currently they use a custom kernel patch
>> for their fuzzer and found several dozens of bugs.
>> There is also interest from Intel 0-DAY kernel test infrastructure.
>>
>> ...
>>
>> --- a/include/linux/sched.h
>> +++ b/include/linux/sched.h
>> @@ -1811,6 +1811,16 @@ struct task_struct {
>>       /* bitmask and counter of trace recursion */
>>       unsigned long trace_recursion;
>>  #endif /* CONFIG_TRACING */
>> +#ifdef CONFIG_KCOV
>> +     /* Coverage collection mode enabled for this task (0 if disabled). */
>> +     int             kcov_mode;
>
> Should really be enum kcov_mode.  We could move it into <linux/kcov.h>:
>
> --- a/include/linux/kcov.h~kernel-add-kcov-code-coverage-fix
> +++ a/include/linux/kcov.h
> @@ -10,6 +10,14 @@ struct task_struct;
>  void kcov_task_init(struct task_struct *t);
>  void kcov_task_exit(struct task_struct *t);
>
> +enum kcov_mode {
> +       /*
> +        * Tracing coverage collection mode.
> +        * Covered PCs are collected in a per-task buffer.
> +        */
> +       KCOV_MODE_TRACE = 1,
> +};
> +
>  #else
>
>  static inline void kcov_task_init(struct task_struct *t) {}
> --- a/include/linux/sched.h~kernel-add-kcov-code-coverage-fix
> +++ a/include/linux/sched.h
> @@ -51,6 +51,7 @@ struct sched_param {
>  #include <linux/resource.h>
>  #include <linux/timer.h>
>  #include <linux/hrtimer.h>
> +#include <linux/kcov.h>
>  #include <linux/task_io_accounting.h>
>  #include <linux/latencytop.h>
>  #include <linux/cred.h>
> @@ -1814,7 +1815,7 @@ struct task_struct {
>  #endif /* CONFIG_TRACING */
>  #ifdef CONFIG_KCOV
>         /* Coverage collection mode enabled for this task (0 if disabled). */
> -       int             kcov_mode;
> +       enum kcov_mode kcov_mode;
>         /* Size of the kcov_area. */
>         unsigned        kcov_size;
>         /* Buffer for coverage collection. */
> --- a/kernel/kcov.c~kernel-add-kcov-code-coverage-fix
> +++ a/kernel/kcov.c
> @@ -13,14 +13,6 @@
>  #include <linux/uaccess.h>
>  #include <linux/kcov.h>
>
> -enum kcov_mode {
> -       /*
> -        * Tracing coverage collection mode.
> -        * Covered PCs are collected in a per-task buffer.
> -        */
> -       KCOV_MODE_TRACE = 1,
> -};
> -
>  /*
>   * kcov descriptor (one per opened debugfs file).
>   * State transitions of the descriptor:
>
>>
>> ...
>>
>> +/*
>> + * kcov descriptor (one per opened debugfs file).
>> + * State transitions of the descriptor:
>> + * - initial state after open()
>> + * - then there must be a single ioctl(KCOV_INIT_TRACE) call
>> + * - then, mmap() call (several calls are allowed but not useful)
>> + * - then, repeated enable/disable for a task (only one task a time allowed)
>> + */
>> +struct kcov {
>> + /*
>> + * Reference counter.  We keep one for:
>> + * - opened file descriptor
>> + * - task with enabled coverage (we can't unwire it from another task)
>> + */
>> +     atomic_t rc;
>
> "rc" usually means "return code".  Calling this "refcount" would cause
> less surprise.


Thanks for the fixes, Andrew. I will be OOO next week, but I will send
cleanup patch the week after next.


From wens at csie.org  Sat Feb  6 04:42:24 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Sat, 6 Feb 2016 20:42:24 +0800
Subject: [PATCH 07/11] ARM: dts: sunxi: Add dtsi file for AXP809 PMIC
In-Reply-To: <20160202121733.GO4455@sirena.org.uk>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-8-git-send-email-wens@csie.org>
 <20160202121733.GO4455@sirena.org.uk>
Message-ID: <CAGb2v657zYT30KbuK0fyVOmhv0kzJjj9gTsTFRaS4i3d6YhiHQ@mail.gmail.com>

On Tue, Feb 2, 2016 at 8:17 PM, Mark Brown <broonie at kernel.org> wrote:
> On Tue, Feb 02, 2016 at 06:27:40PM +0800, Chen-Yu Tsai wrote:
>
>> +             reg_dcdc1: dcdc1 {
>> +                     regulator-name = "dcdc1";
>> +             };
>
> Why is this generic DTS include specifying regulator names?

My intent is to provide better looking names by default.
I just realized I could do this in the driver by replacing
a few fields.

But I still might need to do this for the AXP806, which
is a slave PMIC also used with A80 SoCs. The names overlap
with the AXP809. Allwinner gets around this by adding a
"s_" prefix to them. I suppose that works too.

Mark, may I assume you are OK with this DTS include listing
the regulators, even if their sections are empty?

>
>> +             reg_rtc_ldo: rtc_ldo {
>> +                     /* RTC_LDO is a fixed, always-on regulator */
>> +                     regulator-always-on;
>> +                     regulator-min-microvolt = <1800000>;
>> +                     regulator-max-microvolt = <1800000>;
>
> If the regulator itself is limited in this way there is no need to
> specify this in the DTS.

Will remove.

Thanks
ChenYu


From sergei.shtylyov at cogentembedded.com  Sat Feb  6 04:49:15 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 6 Feb 2016 15:49:15 +0300
Subject: [PATCH 4/5] ARM: dts: NSP: Add SP805 Support to DT
In-Reply-To: <1454712204-30419-5-git-send-email-jonmason@broadcom.com>
References: <1454712204-30419-1-git-send-email-jonmason@broadcom.com>
 <1454712204-30419-5-git-send-email-jonmason@broadcom.com>
Message-ID: <56B5EBCB.4080305@cogentembedded.com>

Hello.

On 2/6/2016 1:43 AM, Jon Mason wrote:

> Add support for the ARM SP805 Watchdog timer to the Northstar Plus
> device tree.
>
> Signed-off-by: Jon Mason <jonmason at broadcom.com>
> ---
>   arch/arm/boot/dts/bcm-nsp.dtsi | 8 ++++++++
>   1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
> index 415a0a6..0e8cb6e 100644
> --- a/arch/arm/boot/dts/bcm-nsp.dtsi
> +++ b/arch/arm/boot/dts/bcm-nsp.dtsi
> @@ -203,6 +203,14 @@
>   			clock-frequency = <100000>;
>   		};
>
> +		wdt at 39000 {

    Should be "watchdog at 39000", according to ePAPR.

[...]

MBR, Sergei



From weiyj_lk at 163.com  Sat Feb  6 06:24:19 2016
From: weiyj_lk at 163.com (weiyj_lk at 163.com)
Date: Sat,  6 Feb 2016 22:24:19 +0800
Subject: [PATCH] MIPS: pci-mt7620: Fix return value check in mt7620_pci_probe()
Message-ID: <1454768659-32720-1-git-send-email-weiyj_lk@163.com>

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

In case of error, the function devm_ioremap_resource() returns
ERR_PTR() and never returns NULL. The NULL test in the return
value check should be replaced with IS_ERR().

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
 arch/mips/pci/pci-mt7620.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/mips/pci/pci-mt7620.c b/arch/mips/pci/pci-mt7620.c
index a009ee4..044c1cd 100644
--- a/arch/mips/pci/pci-mt7620.c
+++ b/arch/mips/pci/pci-mt7620.c
@@ -297,12 +297,12 @@ static int mt7620_pci_probe(struct platform_device *pdev)
 		return PTR_ERR(rstpcie0);
 
 	bridge_base = devm_ioremap_resource(&pdev->dev, bridge_res);
-	if (!bridge_base)
-		return -ENOMEM;
+	if (IS_ERR(bridge_base))
+		return PTR_ERR(bridge_base);
 
 	pcie_base = devm_ioremap_resource(&pdev->dev, pcie_res);
-	if (!pcie_base)
-		return -ENOMEM;
+	if (IS_ERR(pcie_base))
+		return PTR_ERR(pcie_base);
 
 	iomem_resource.start = 0;
 	iomem_resource.end = ~0;



From weiyj_lk at 163.com  Sat Feb  6 06:24:56 2016
From: weiyj_lk at 163.com (weiyj_lk at 163.com)
Date: Sat,  6 Feb 2016 22:24:56 +0800
Subject: [PATCH] ARM: zx: Fix return value check in zx296702_pd_probe()
Message-ID: <1454768696-340-1-git-send-email-weiyj_lk@163.com>

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

In case of error, the function devm_ioremap_resource() returns
ERR_PTR() and never returns NULL. The NULL test in the return
value check should be replaced with IS_ERR().

Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
---
 arch/arm/mach-zx/zx296702-pm-domain.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-zx/zx296702-pm-domain.c b/arch/arm/mach-zx/zx296702-pm-domain.c
index e08574d..2037bcb 100644
--- a/arch/arm/mach-zx/zx296702-pm-domain.c
+++ b/arch/arm/mach-zx/zx296702-pm-domain.c
@@ -169,9 +169,9 @@ static int zx296702_pd_probe(struct platform_device *pdev)
 	}
 
 	pcubase = devm_ioremap_resource(&pdev->dev, res);
-	if (!pcubase) {
+	if (IS_ERR(pcubase)) {
 		dev_err(&pdev->dev, "ioremap fail.\n");
-		return -EIO;
+		return PTR_ERR(pcubase);
 	}
 
 	for (i = 0; i < ARRAY_SIZE(zx296702_pm_domains); ++i)



From fijam at archlinux.us  Sat Feb  6 07:14:49 2016
From: fijam at archlinux.us (JM)
Date: Sat, 6 Feb 2016 16:14:49 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <87twlmdg2b.fsf@natisbad.org>
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
 <20160205090246.GE32272@lunn.ch> <20160205112907.796afb05@bbrezillon>
 <CAKzmTe20fT8BcRaDaf2gz92KMAK0kEUkaD-kPq_cPF1WKBdroA@mail.gmail.com>
 <87vb632maf.fsf@free-electrons.com>
 <CAKzmTe1AqNQwjcsAULotd010NXuk1AYjj5p6UoqT_Zu=BCHdcw@mail.gmail.com>
 <87mvrf2l6p.fsf@free-electrons.com> <87io232kat.fsf@free-electrons.com>
 <8760y2vqje.fsf@natisbad.org> <87twlmdg2b.fsf@natisbad.org>
Message-ID: <CAKzmTe24iz1Ka7Kkke=ZTVbDGZxxDjBH0m2iEVCQOGuuEpi4Gg@mail.gmail.com>

On Fri, Feb 5, 2016 at 10:04 PM, Arnaud Ebalard <arno at natisbad.org> wrote:
> Hi,
>
>> I'll try and do the same now w/ CESA support compiled as module to see
>> what I get. I'll keep you posted.
>
> root at mood:~# insmod /tmp/marvell-cesa.ko
> [  573.897977] marvell-cesa f1030000.crypto: CESA device successfully registered
>
> root at mood:~# uname -a
> Linux mood 4.4.0.duov2 #2 Fri Feb 5 21:42:49 CET 2016 armv5tel GNU/Linux
>
> root at mood:~# zcat /proc/config.gz | grep -i CESA
> # CONFIG_CRYPTO_DEV_MV_CESA is not set
> CONFIG_CRYPTO_DEV_MARVELL_CESA=m
>
> Cheers,
>
> a+
>
> ps: my config is temporarily at http://natisbad.org/config-duov2-cesa

I've built a vanilla 4.4.1 kernel image without any debian-specific
patches but using the same oldconfig
(http://heap.ovh/files/config-4.4.1.vanilla).

# uname -a
Linux yukikaze 4.4.1.vanilla #1 Sat Feb 6 14:18:19 CET 2016 armv5tel GNU/Linux

# modprobe marvell_cesa allhwsupport=1

# dmesg | tail -n1
[  116.972828] marvell-cesa: probe of f1030000.crypto failed with error -12

The dtb hasn't changed:
# diff -s kirkwood-ts219-6282.dtb dtb-4.4.1.vanilla
Files kirkwood-ts219-6282.dtb and dtb-4.4.1.vanilla are identical

I am also attaching lsmod: http://heap.ovh/files/lsmod-vanilla-4.4.1
and full dmesg: http://heap.ovh/files/dmesg-vanilla-4.4.1

Perhaps I am missing something obvious? I suppose the next step would
be to build a minimal kernel based on the config for the duov2?

Best regards,
Jan


From blogic at openwrt.org  Sat Feb  6 07:40:03 2016
From: blogic at openwrt.org (John Crispin)
Date: Sat, 6 Feb 2016 16:40:03 +0100
Subject: [PATCH] MIPS: pci-mt7620: Fix return value check in
 mt7620_pci_probe()
In-Reply-To: <1454768659-32720-1-git-send-email-weiyj_lk@163.com>
References: <1454768659-32720-1-git-send-email-weiyj_lk@163.com>
Message-ID: <56B613D3.2070709@openwrt.org>


On 06/02/2016 15:24, weiyj_lk at 163.com wrote:
> From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
> 
> In case of error, the function devm_ioremap_resource() returns
> ERR_PTR() and never returns NULL. The NULL test in the return
> value check should be replaced with IS_ERR().
> 
> Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>

Hi,

thanks for the fix.

Acked-by: John Crispin <blogic at openwrt.org>

@Ralf: can you merge this via LMO with the next PR please ?

@mbgg: ignore the patch please it is for the legacy MIPS SoCs

	John

> ---
>  arch/mips/pci/pci-mt7620.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/mips/pci/pci-mt7620.c b/arch/mips/pci/pci-mt7620.c
> index a009ee4..044c1cd 100644
> --- a/arch/mips/pci/pci-mt7620.c
> +++ b/arch/mips/pci/pci-mt7620.c
> @@ -297,12 +297,12 @@ static int mt7620_pci_probe(struct platform_device *pdev)
>  		return PTR_ERR(rstpcie0);
>  
>  	bridge_base = devm_ioremap_resource(&pdev->dev, bridge_res);
> -	if (!bridge_base)
> -		return -ENOMEM;
> +	if (IS_ERR(bridge_base))
> +		return PTR_ERR(bridge_base);
>  
>  	pcie_base = devm_ioremap_resource(&pdev->dev, pcie_res);
> -	if (!pcie_base)
> -		return -ENOMEM;
> +	if (IS_ERR(pcie_base))
> +		return PTR_ERR(pcie_base);
>  
>  	iomem_resource.start = 0;
>  	iomem_resource.end = ~0;
> 
> 
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
> 


From wens at csie.org  Sat Feb  6 07:53:45 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Sat,  6 Feb 2016 23:53:45 +0800
Subject: [PATCH 2/6] ARM: sunxi_defconfig: Enable A10 audio codec driver
In-Reply-To: <1454774029-10469-1-git-send-email-wens@csie.org>
References: <1454774029-10469-1-git-send-email-wens@csie.org>
Message-ID: <1454774029-10469-3-git-send-email-wens@csie.org>

The A10 audio codec driver supports the on-chip audio codec found on
Allwinner A10, A10s, A13, A20 SoCs.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/configs/sunxi_defconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 7d2e7bf81a47..efa12c88fe1c 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -100,6 +100,10 @@ CONFIG_FB=y
 CONFIG_FB_SIMPLE=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_SOC=y
+CONFIG_SND_SUN4I_CODEC=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
-- 
2.7.0



From wens at csie.org  Sat Feb  6 07:53:43 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Sat,  6 Feb 2016 23:53:43 +0800
Subject: [PATCH 0/6] ARM: defconfig: Enable recently merged drivers for sunxi
Message-ID: <1454774029-10469-1-git-send-email-wens@csie.org>

Hi everyone,

This series enables drivers for devices that are likely to be used on sunxi.
This includes the IR receiver, audio codec, USB OTG, and also enabling input
device interface in userspace so the power button works.

The patches are self-explanatory.

MUSB for USB OTG is enabled only now because it used to require USB gadget
drivers as modules to work reliably. It was an issue of probe ordering. This
has since been fixed (or worked around) in 4.5-rc1.

The IR receiver driver isn't enabled for multi_v7_defconfig, as I didn't see
any others enabled. On the other hand, MUSB is enabled, because for tablets
this is likely the only option for external USB peripherals.

Regards
ChenYu


Chen-Yu Tsai (6):
  ARM: sunxi_defconfig: Enable sunxi IR driver
  ARM: sunxi_defconfig: Enable A10 audio codec driver
  ARM: sunxi_defconfig: Enable MUSB HDRC driver with Allwinner glue
  ARM: sunxi_defconfig: Enable INPUT_EVDEV so axp20x-pek can be used
  ARM: multi_v7_defconfig: Enable A10 audio codec driver as module
  ARM: multi_v7_defconfig: Enable MUSB HDRC driver with Allwinner glue

 arch/arm/configs/multi_v7_defconfig |  3 +++
 arch/arm/configs/sunxi_defconfig    | 14 ++++++++++++++
 2 files changed, 17 insertions(+)

-- 
2.7.0



From wens at csie.org  Sat Feb  6 07:53:48 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Sat,  6 Feb 2016 23:53:48 +0800
Subject: [PATCH 5/6] ARM: multi_v7_defconfig: Enable A10 audio codec driver as
 module
In-Reply-To: <1454774029-10469-1-git-send-email-wens@csie.org>
References: <1454774029-10469-1-git-send-email-wens@csie.org>
Message-ID: <1454774029-10469-6-git-send-email-wens@csie.org>

The A10 audio codec driver supports the on-chip audio codec found on
Allwinner A10, A10s, A13, A20 SoCs.

Build it as a module, since it is not critical.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 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 314f6be2dca2..03703b7ea530 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -559,6 +559,7 @@ CONFIG_SND_SOC_ROCKCHIP_RT5645=m
 CONFIG_SND_SOC_SH4_FSI=m
 CONFIG_SND_SOC_RCAR=m
 CONFIG_SND_SOC_RSRC_CARD=m
+CONFIG_SND_SUN4I_CODEC=m
 CONFIG_SND_SOC_SAMSUNG=m
 CONFIG_SND_SOC_SNOW=m
 CONFIG_SND_SOC_ODROIDX2=m
-- 
2.7.0



From wens at csie.org  Sat Feb  6 07:53:44 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Sat,  6 Feb 2016 23:53:44 +0800
Subject: [PATCH 1/6] ARM: sunxi_defconfig: Enable sunxi IR driver
In-Reply-To: <1454774029-10469-1-git-send-email-wens@csie.org>
References: <1454774029-10469-1-git-send-email-wens@csie.org>
Message-ID: <1454774029-10469-2-git-send-email-wens@csie.org>

A consumer IR receiver is commonly found on Allwinner SoC based
development boards and set top boxes. The driver has been available
for some time. Enable it by default.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/configs/sunxi_defconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index a9a81a714be4..7d2e7bf81a47 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -92,6 +92,10 @@ CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_AXP20X=y
 CONFIG_REGULATOR_GPIO=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_RC_SUPPORT=y
+CONFIG_RC_DEVICES=y
+CONFIG_IR_SUNXI=y
 CONFIG_FB=y
 CONFIG_FB_SIMPLE=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
-- 
2.7.0



From wens at csie.org  Sat Feb  6 07:53:46 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Sat,  6 Feb 2016 23:53:46 +0800
Subject: [PATCH 3/6] ARM: sunxi_defconfig: Enable MUSB HDRC driver with
 Allwinner glue
In-Reply-To: <1454774029-10469-1-git-send-email-wens@csie.org>
References: <1454774029-10469-1-git-send-email-wens@csie.org>
Message-ID: <1454774029-10469-4-git-send-email-wens@csie.org>

Allwinner SoCs typically have a Mentor Graphics Inventra MUSB dual role
controller for USB OTG.

Now that the issue with MUSB and USB gadget registration order has been
resolved, we can enable this driver in dual role mode. This requires the
NOP USB transceiver driver, which is also enabled.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/configs/sunxi_defconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index efa12c88fe1c..e29b81694184 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -109,6 +109,11 @@ CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
 CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_HCD_PLATFORM=y
+CONFIG_USB_MUSB_HDRC=y
+CONFIG_USB_MUSB_SUNXI=y
+CONFIG_NOP_USB_XCEIV=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_CDC_COMPOSITE=y
 CONFIG_MMC=y
 CONFIG_MMC_SUNXI=y
 CONFIG_NEW_LEDS=y
-- 
2.7.0



From wens at csie.org  Sat Feb  6 07:53:47 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Sat,  6 Feb 2016 23:53:47 +0800
Subject: [PATCH 4/6] ARM: sunxi_defconfig: Enable INPUT_EVDEV so axp20x-pek
 can be used
In-Reply-To: <1454774029-10469-1-git-send-email-wens@csie.org>
References: <1454774029-10469-1-git-send-email-wens@csie.org>
Message-ID: <1454774029-10469-5-git-send-email-wens@csie.org>

sunxi_defconfig already enables INPUT_AXP20X_PEK, but the device is not
exposed to userspace. Enable INPUT_EVDEV so it is.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/configs/sunxi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index e29b81694184..a3a27e830ef9 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -58,6 +58,7 @@ CONFIG_STMMAC_ETH=y
 # CONFIG_NET_VENDOR_WIZNET is not set
 # CONFIG_WLAN is not set
 # CONFIG_INPUT_MOUSEDEV is not set
+CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_SUN4I_LRADC=y
 # CONFIG_INPUT_MOUSE is not set
 CONFIG_INPUT_TOUCHSCREEN=y
-- 
2.7.0



From wens at csie.org  Sat Feb  6 07:53:49 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Sat,  6 Feb 2016 23:53:49 +0800
Subject: [PATCH 6/6] ARM: multi_v7_defconfig: Enable MUSB HDRC driver with
 Allwinner glue
In-Reply-To: <1454774029-10469-1-git-send-email-wens@csie.org>
References: <1454774029-10469-1-git-send-email-wens@csie.org>
Message-ID: <1454774029-10469-7-git-send-email-wens@csie.org>

Allwinner SoCs typically have a Mentor Graphics Inventra MUSB high speed
dual role controller for USB OTG.

Now that the issue with MUSB and USB gadget registration order has been
resolved, we can enable this driver in dual role mode.

This patch only enables the driver core and Allwinner platform support.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/configs/multi_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 03703b7ea530..b500f18d0c35 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -592,6 +592,8 @@ CONFIG_USB_OHCI_EXYNOS=m
 CONFIG_USB_R8A66597_HCD=m
 CONFIG_USB_RENESAS_USBHS=m
 CONFIG_USB_STORAGE=y
+CONFIG_USB_MUSB_HDRC=m
+CONFIG_USB_MUSB_SUNXI=m
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC2=m
 CONFIG_USB_CHIPIDEA=y
-- 
2.7.0



From helgaas at kernel.org  Sat Feb  6 08:01:30 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Sat, 6 Feb 2016 10:01:30 -0600
Subject: [PATCH v5 2/3] pci, pci-thunder-pem: Add PCIe host driver for
 ThunderX processors.
In-Reply-To: <1454715675-17512-3-git-send-email-ddaney.cavm@gmail.com>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
 <1454715675-17512-3-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <20160206160130.GC22119@localhost>

Hi David,

I don't have time today to look at this thoroughly, but I think I did
see one actual bug and a possible way to make this more readable.  I
think reading difficulty increases as at least the square of the
maximum indent level :)

Bjorn

On Fri, Feb 05, 2016 at 03:41:14PM -0800, David Daney wrote:
> ...
> +static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
> +				    int where, int size, u32 val)
> +{
> +	struct gen_pci *pci = bus->sysdata;
> +	struct thunder_pem_pci *pem_pci;
> +
> +	pem_pci = container_of(pci, struct thunder_pem_pci, gen_pci);
> +
> +	/*
> +	 * The first device on the bus in the PEM PCIe bridge.
> +	 * Special case its config access.
> +	 */
> +	if (bus->number == pci->cfg.bus_range->start) {
> +		u64 write_val, read_val;
> +		u32 mask = 0;
> +
> +		if (devfn != 0 || where >= 2048)
> +			return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +		/*
> +		 * 32-bit accesses only.  If the write is for a size
> +		 * smaller than 32-bits, we must first read the 32-bit
> +		 * value and merge in the desired bits and then write
> +		 * the whole 32-bits back out.
> +		 */
> +		switch (size) {
> +		case 1:
> +			read_val = where & ~3ull;
> +			writeq(read_val, pem_pci->pem_reg_base + PEM_CFG_RD);
> +			read_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
> +			read_val >>= 32;
> +			mask = ~(0xff << (8 * (where & 3)));
> +			read_val &= mask;
> +			val = (val & 0xff) << (8 * (where & 3));
> +			val |= (u32)read_val;
> +			break;
> +		case 2:
> +			read_val = where & ~3ull;
> +			writeq(read_val, pem_pci->pem_reg_base + PEM_CFG_RD);
> +			read_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
> +			read_val >>= 32;
> +			mask = ~(0xffff << (8 * (where & 3)));
> +			read_val &= mask;
> +			val = (val & 0xffff) << (8 * (where & 3));
> +			val |= (u32)read_val;
> +			break;
> +		default:
> +			break;
> +
> +		}

I think it would make this easier to read if the root bus case were
split to a different function, e.g.,

  static u32 thunder_pem_root_w1c_bits(...)
  {
    ...
  }

  static int thunder_pem_root_config_write(...)
  {
    u32 mask[2] = {0xff, 0xffff};

    if (devfn != 0 || where >= 2048)
      return PCIBIOS_DEVICE_NOT_FOUND;

    if (size != 1 && size != 2 && size != 4)
      return PCIBIOS_BAD_REGISTER_NUMBER;

    /* 32-bit accesses supported natively */
    if (size == 4) {
      write_val = where & ~3ull;
      write_val |= (((u64)val) << 32);
      writeq(write_val, pem_pci->pem_reg_base + PEM_CFG_WR);
      return PCIBIOS_SUCCESSFUL;
    }

    /* smaller accesses require read/modify/write */
    read_val = where & ~3ull;
    writeq(read_val, pem_pci->pem_reg_base + PEM_CFG_RD);
    read_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
    read_val >>= 32;

    /* mask W1C bits so we don't clear them inadvertently */
    write_val = read_val & ~thunder_pem_root_w1c_bits(...);

    /* deposit new write data (which may intentionally write W1C bits) */
    val &= mask[size];
    shift = 8 * (where & 3);

    write_val &= ~(mask[size] << shift);
    write_val |= val << shift;

    write_val = where & ~3ull;
    write_val |= (((u64)val) << 32);
    writeq(write_val, pem_pci->pem_reg_base + PEM_CFG_WR);
    return PCIBIOS_SUCCESSFUL;
  }

  static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
				    int where, int size, u32 val)
  {
    ...
    if (bus->number < pci->cfg.bus_range->start ||
        bus->number > pci->cfg.bus_range->end)
      return PCIBIOS_DEVICE_NOT_FOUND;

    if (bus->number == pci->cfg.bus_range->start)
      return thunder_pem_root_config_write(...);

    return pci_generic_config_write(bus, devfn, where, size, val);
  }

> +
> +		if (mask) {
> +			/*
> +			 * By expanding the write width to 32 bits, we
> +			 * may inadvertently hit some W1C bits that
> +			 * were not intended to be written.  Mask
> +			 * these out.
> +			 *
> +			 * Some of the w1c_bits below also include
> +			 * read-only or non-writable reserved bits,
> +			 * this makes the code simpler and is OK as
> +			 * the bits are not affected by writing zeros
> +			 * to them.
> +			 */
> +			u32 w1c_bits = 0;
> +
> +			switch (where & 3) {
> +			case 0x04: /* Command/Status */
> +			case 0x1c: /* Base and I/O Limit/Secondary Status */
> +				w1c_bits = 0xff000000;
> +				break;
> +			case 0x44: /* Power Management Control and Status */
> +				w1c_bits = 0xfffffe00;
> +				break;
> +			case 0x78: /* Device Control/Device Status */
> +			case 0x80: /* Link Control/Link Status */
> +			case 0x88: /* Slot Control/Slot Status */
> +			case 0x90: /* Root Status */
> +			case 0xa0: /* Link Control 2 Registers/Link Status 2 */
> +				w1c_bits = 0xffff0000;
> +				break;
> +			case 0x104: /* Uncorrectable Error Status */
> +			case 0x110: /* Correctable Error Status */
> +			case 0x130: /* Error Status */
> +			case 0x160: /* Link Control 4 */

"where & 3" can never match any of these cases.  I suppose you meant
"where & ~3"?

> +				w1c_bits = 0xffffffff;
> +				break;
> +			default:
> +				break;
> +
> +			}
> +			if (w1c_bits) {
> +				mask &= w1c_bits;
> +				val &= ~mask;
> +			}
> +		}
> +
> +		/*
> +		 * Low order bits are the config address, the high
> +		 * order 32 bits are the data to be written.
> +		 */
> +		write_val = where & ~3ull;
> +		write_val |= (((u64)val) << 32);
> +		writeq(write_val, pem_pci->pem_reg_base + PEM_CFG_WR);
> +		return PCIBIOS_SUCCESSFUL;
> +	}
> +	if (bus->number < pci->cfg.bus_range->start ||
> +	    bus->number > pci->cfg.bus_range->end)
> +		return PCIBIOS_DEVICE_NOT_FOUND;
> +	return pci_generic_config_write(bus, devfn, where, size, val);
> +}


From friesendrywall at gmail.com  Sat Feb  6 09:22:35 2016
From: friesendrywall at gmail.com (Erik Friesen)
Date: Sat, 6 Feb 2016 12:22:35 -0500
Subject: SGTL5000 misc
In-Reply-To: <CAOMZO5Dos2xidZWrGffHRw33GjcJi+CvitFC5hKW3Hy0++GEmg@mail.gmail.com>
References: <CAEuupiuhPR48Upo=8f0zV8cxf0Vefgx3qA+vC+QDWAOV4n-e3Q@mail.gmail.com>
 <CAOMZO5BPNc1ncz6J8yhcBYywCVuTxKYMYhiNUt_Jq3LZsKdi+A@mail.gmail.com>
 <CAEuupiszxAj7JkJu-5ozqgEnTWkz9FQEpxN8dmEN+KtaV-76ww@mail.gmail.com>
 <CAOMZO5DhrzdVyTVPB3FNquV4rDQ8a0MQrsJMosVsUQN63hj1Ww@mail.gmail.com>
 <CAEuupiuoB7nMSc8Fbyort1rJd=ZhYc0zfJNkd=ckUYk1qd8Z7Q@mail.gmail.com>
 <CAOMZO5C4QUHnJr=pisnYWCYZ0zUt+7HO846aPQui0zcLyX0N-Q@mail.gmail.com>
 <CAEuupivdftoopCOX3f7KRbV9poKdjdD3s9hfcbgB2TYjHmrjvw@mail.gmail.com>
 <CAEuupit8pVdnehkZkZPmq1QBHaS0sUG4NFuVFX37dKHn18j7DQ@mail.gmail.com>
 <CAOMZO5BxFRzi3qJAK=xDGger_MK9GZhuM00ugo836PHK_zJKjQ@mail.gmail.com>
 <CAEuupium67HD-sz+ViPx8-L4S0TsS-C8ZrX3po382r=E-9QYgw@mail.gmail.com>
 <CAOMZO5Dos2xidZWrGffHRw33GjcJi+CvitFC5hKW3Hy0++GEmg@mail.gmail.com>
Message-ID: <CAEuupiti=Z9CeQpgUyvyQcfWEE_ReS4RpY9sHtY=OdN3YFjZQw@mail.gmail.com>

Well, I have posted a thing or two there, not sure if the mailing list
is even working, as I haven't received any replies.

On Fri, Feb 5, 2016 at 5:00 AM, Fabio Estevam <festevam at gmail.com> wrote:
> On Fri, Feb 5, 2016 at 1:08 AM, Erik Friesen <friesendrywall at gmail.com> wrote:
>> There is another issue here, but when I have this connected to
>> external power, it won't start the card on every other boot.
>>
>> With the code below, it seems to start every time.  If I don't skip,
>> it dies on #8, which is the write of 0x7060 to CHIP_ANA_POWER
>>
>> This embeddedarm board supposedly power cycles the regulators, don't
>> know if that is a factor or not.  The board finishes powerup 0x4060,
>> but comes back on reboot at the reset value of 0x7060
>
> It would be nice if you could send a patch to alsa-devel mailing list,
> so that this can be properly reviewed there.


From festevam at gmail.com  Sat Feb  6 09:33:51 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Sat, 6 Feb 2016 15:33:51 -0200
Subject: SGTL5000 misc
In-Reply-To: <CAEuupiti=Z9CeQpgUyvyQcfWEE_ReS4RpY9sHtY=OdN3YFjZQw@mail.gmail.com>
References: <CAEuupiuhPR48Upo=8f0zV8cxf0Vefgx3qA+vC+QDWAOV4n-e3Q@mail.gmail.com>
 <CAOMZO5BPNc1ncz6J8yhcBYywCVuTxKYMYhiNUt_Jq3LZsKdi+A@mail.gmail.com>
 <CAEuupiszxAj7JkJu-5ozqgEnTWkz9FQEpxN8dmEN+KtaV-76ww@mail.gmail.com>
 <CAOMZO5DhrzdVyTVPB3FNquV4rDQ8a0MQrsJMosVsUQN63hj1Ww@mail.gmail.com>
 <CAEuupiuoB7nMSc8Fbyort1rJd=ZhYc0zfJNkd=ckUYk1qd8Z7Q@mail.gmail.com>
 <CAOMZO5C4QUHnJr=pisnYWCYZ0zUt+7HO846aPQui0zcLyX0N-Q@mail.gmail.com>
 <CAEuupivdftoopCOX3f7KRbV9poKdjdD3s9hfcbgB2TYjHmrjvw@mail.gmail.com>
 <CAEuupit8pVdnehkZkZPmq1QBHaS0sUG4NFuVFX37dKHn18j7DQ@mail.gmail.com>
 <CAOMZO5BxFRzi3qJAK=xDGger_MK9GZhuM00ugo836PHK_zJKjQ@mail.gmail.com>
 <CAEuupium67HD-sz+ViPx8-L4S0TsS-C8ZrX3po382r=E-9QYgw@mail.gmail.com>
 <CAOMZO5Dos2xidZWrGffHRw33GjcJi+CvitFC5hKW3Hy0++GEmg@mail.gmail.com>
 <CAEuupiti=Z9CeQpgUyvyQcfWEE_ReS4RpY9sHtY=OdN3YFjZQw@mail.gmail.com>
Message-ID: <CAOMZO5BaYKuTrWvopJn5RbvoJqEt4dQt1vmB7QCHLPaKD-ohLQ@mail.gmail.com>

On Sat, Feb 6, 2016 at 3:22 PM, Erik Friesen <friesendrywall at gmail.com> wrote:
> Well, I have posted a thing or two there, not sure if the mailing list
> is even working, as I haven't received any replies.

I haven't seen your patches there. You need to subscribe to alsa-devel first.


From jonmason at broadcom.com  Sat Feb  6 09:53:39 2016
From: jonmason at broadcom.com (Jon Mason)
Date: Sat,  6 Feb 2016 12:53:39 -0500
Subject: [PATCH v2 4/5] ARM: dts: NSP: Add SP804 Support to DT
Message-ID: <1454781219-2640-1-git-send-email-jonmason@broadcom.com>

Add support for the ARM SP804 timer to the Northstar Plus device tree.

Signed-off-by: Jon Mason <jonmason at broadcom.com>
---
 arch/arm/boot/dts/bcm-nsp.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index ee03bee..63a0a53 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -194,6 +194,24 @@
 			brcm,nand-has-wp;
 		};
 
+		ccbtimer0: timer at 34000 {
+			compatible = "arm,sp804";
+			reg = <0x34000 0x1000>;
+			interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&iprocslow>;
+			clock-names = "apb_pclk";
+		};
+
+		ccbtimer1: timer at 35000 {
+			compatible = "arm,sp804";
+			reg = <0x35000 0x1000>;
+			interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&iprocslow>;
+			clock-names = "apb_pclk";
+		};
+
 		i2c0: i2c at 38000 {
 			compatible = "brcm,iproc-i2c";
 			reg = <0x38000 0x50>;
-- 
1.9.1



From fu.wei at linaro.org  Sat Feb  6 10:02:12 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Sun, 7 Feb 2016 02:02:12 +0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <56B5363D.20200@roeck-us.net>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
 <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
 <56B2DEE4.7060901@roeck-us.net>
 <CADyBb7unAHEOMfruWS82RkHK6uwPAWCxUx9jqzSkiHU4LHDSeA@mail.gmail.com>
 <56B4B4E2.40105@roeck-us.net>
 <CADyBb7sP=d+BWOdmNEAs38yRcmXVjYsFX=XNffNpGqfybpxTfQ@mail.gmail.com>
 <56B5363D.20200@roeck-us.net>
Message-ID: <CADyBb7vRKjDoeOfH=3Uwz+D0xyXaC9cM4ZSEO+MwL8Gw5T-Umg@mail.gmail.com>

Hi Guenter,

On 6 February 2016 at 07:54, Guenter Roeck <linux at roeck-us.net> wrote:
> On 02/05/2016 10:21 AM, Fu Wei wrote:
>>
>> On 5 February 2016 at 22:42, Guenter Roeck <linux at roeck-us.net> wrote:
>>>
>>> On 02/05/2016 01:51 AM, Fu Wei wrote:
>>>>
>>>>
>>>> Hi Guenter,
>>>>
>>>> On 4 February 2016 at 13:17, Guenter Roeck <linux at roeck-us.net> wrote:
>>>>>
>>>>>
>>>>> On 02/03/2016 03:00 PM, Fu Wei wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4 February 2016 at 02:45, Timur Tabi <timur at codeaurora.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Fu Wei wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> As you know I have made the pre-timeout support patch, If people
>>>>>>>> like
>>>>>>>> it, i am happy to go on upstream it separately.
>>>>>>>>
>>>>>>>> If we want to use pre-timeout here, user only can use get_pretimeout
>>>>>>>> and disable panic by setting pretimeout to 0
>>>>>>>> but user can not really set pretimeout, because "pre-timeout  ==
>>>>>>>> timeout / 2 (always)".
>>>>>>>> if user want to change pretimeout, he/she has to set_time instead.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Ok, I think patches 4 and 5 should be combined, and I think the
>>>>>>> Kconfig
>>>>>>> entry should be removed and just use panic_enabled.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Agreed.
>>>>
>>>>
>>>>
>>>> np, will do
>>>>
>>>>>>
>>>>>>
>>>>>> NP, will update this patchset like that ,  thanks :-)
>>>>>>
>>>>>
>>>>> Also, if panic is enabled, the timeout needs to be adjusted accordingly
>>>>> (to only panic after the entire timeout period has expired, not after
>>>>> half of it). We can not panic the system after timeout / 2.
>>>>
>>>>
>>>>
>>>> OK, my thought is
>>>>
>>>> if panic is enabled :
>>>> |--------WOR-------WS0--------WOR-------WS1
>>>> |------timeout------(panic)------timeout-----reset
>>>>
>>>> if panic is disabled .
>>>> |--------WOR-------WS0--------WOR-------WS1
>>>> |---------------------timeout---------------------reset
>>>>
>>>>    panic_enabled only can be configured when module is loaded by module
>>>> parameter
>>>>
>>>> But user should know that max_timeout(panic_enable) =
>>>> max_timeout(panic_disable) / 2
>>>>
>>>
>>> That means you'll have to update max_timeout accordingly.
>>
>>
>> panic_enabled only can be configured when module is loaded, so we
>> don't need to update it.
>>
>> max_timeout will only be set up in the init stage.
>>
>> Does it make sense ? :-)
>>
> Not sure I understand your problem or question.
>
> max_timeout will have to reflect the correct maximum timeout, under
> all circumstances. It will have to be set to the correct value before
> the watchdog driver is registered.

yes, understood,  my thought is :

in  static int sbsa_gwdt_probe(struct platform_device *pdev)

if (action) {
        wdd->min_timeout = 1;
        wdd->max_timeout = U32_MAX / gwdt->clk;
} else {
        wdd->min_timeout = 2;
        wdd->max_timeout = U32_MAX / gwdt->clk * 2;
}



>
> Guenter
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From swarren at wwwdotorg.org  Sat Feb  6 10:03:45 2016
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Sat,  6 Feb 2016 11:03:45 -0700
Subject: [PATCH 2/3] ARM: bcm2835_defconfig: disable DEBUG_LL
In-Reply-To: <1454781826-10571-1-git-send-email-swarren@wwwdotorg.org>
References: <1454781826-10571-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1454781826-10571-2-git-send-email-swarren@wwwdotorg.org>

This way the kernel works on both RPi0/1 and RPi2 even with earlyprintk
in the kernel cmdline; the two hardware platforms use different physical
addresses for peripherals, so the same DEBUG_LL configuration won't work
on both. If someone needs DEBUG_LL support, they can enable it locally.

Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>
---
 arch/arm/configs/bcm2835_defconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index e95dcb16d65d..4a1fb17eebf6 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -142,7 +142,5 @@ CONFIG_TEST_KSTRTOX=y
 CONFIG_KGDB=y
 CONFIG_KGDB_KDB=y
 CONFIG_STRICT_DEVMEM=y
-CONFIG_DEBUG_LL=y
-CONFIG_EARLY_PRINTK=y
 # CONFIG_XZ_DEC_ARM is not set
 # CONFIG_XZ_DEC_ARMTHUMB is not set
-- 
1.9.1



From swarren at wwwdotorg.org  Sat Feb  6 10:03:46 2016
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Sat,  6 Feb 2016 11:03:46 -0700
Subject: [PATCH 3/3] ARM: bcm2835_defconfig: enable ARMv7 support
In-Reply-To: <1454781826-10571-1-git-send-email-swarren@wwwdotorg.org>
References: <1454781826-10571-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <1454781826-10571-3-git-send-email-swarren@wwwdotorg.org>

This makes the RPi2 work; it has an ARMv7 CPU.

Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>
---
 arch/arm/configs/bcm2835_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 4a1fb17eebf6..7c20a0bc2722 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -26,7 +26,6 @@ CONFIG_OPROFILE=y
 CONFIG_JUMP_LABEL=y
 CONFIG_CC_STACKPROTECTOR_REGULAR=y
 CONFIG_ARCH_MULTI_V6=y
-# CONFIG_ARCH_MULTI_V7 is not set
 CONFIG_ARCH_BCM=y
 CONFIG_ARCH_BCM2835=y
 CONFIG_PREEMPT_VOLUNTARY=y
-- 
1.9.1



From swarren at wwwdotorg.org  Sat Feb  6 10:03:44 2016
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Sat,  6 Feb 2016 11:03:44 -0700
Subject: [PATCH 1/3] ARM: bcm2835_defconfig: rebuild on next-20160205
Message-ID: <1454781826-10571-1-git-send-email-swarren@wwwdotorg.org>

This separates explicit changes desired in later patches from "automatic"
or irrelevant changes caused solely by Kconfig changes.

make ARCH=arm bcm2835_defconfig
make ARCH=arm savedefconfig
mv defconfig arch/arm/configs/bcm2835_defconfig

Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>
---
This series is based on top of next-20160205.

You may want to squash all 3 commits together when applying to reduce
the number of defconfig patches; that's fine by me.

 arch/arm/configs/bcm2835_defconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 72def201c4fd..e95dcb16d65d 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -6,13 +6,13 @@ CONFIG_HIGH_RES_TIMERS=y
 CONFIG_BSD_PROCESS_ACCT=y
 CONFIG_BSD_PROCESS_ACCT_V3=y
 CONFIG_LOG_BUF_SHIFT=18
+CONFIG_CFS_BANDWIDTH=y
+CONFIG_RT_GROUP_SCHED=y
 CONFIG_CGROUP_FREEZER=y
-CONFIG_CGROUP_DEVICE=y
 CONFIG_CPUSETS=y
+CONFIG_CGROUP_DEVICE=y
 CONFIG_CGROUP_CPUACCT=y
 CONFIG_CGROUP_PERF=y
-CONFIG_CFS_BANDWIDTH=y
-CONFIG_RT_GROUP_SCHED=y
 CONFIG_NAMESPACES=y
 CONFIG_SCHED_AUTOGROUP=y
 CONFIG_RELAY=y
-- 
1.9.1



From thomas at schloeter.net  Sat Feb  6 10:24:50 2016
From: thomas at schloeter.net (=?utf-8?Q?Thomas_Schl=C3=B6ter?=)
Date: Sat, 6 Feb 2016 19:24:50 +0100
Subject: net: mv643xx: interface does not transmit after some time
Message-ID: <E4F9E0D0-9DA8-4E33-9F89-B49E47F11CE0@schloeter.net>

Hello,

I am using mainline kernel 4.4 on a QNAP TS-412 (Marvell Kirkwood Feroceon 6281). The network interface mv643xx loses connection after a few minutes to some hours. Only bringing the interface down and up again helps.

Now I have a serial console for debugging. When I ping the dead interface and run ?watch ifconfig eth0? on the serial console, I can see the RX packets counting up while TX packets stays unchanged. Log files only show a message of some services showing a timeout or ?if_sendrawpacket: No buffer space available?.

How can I figure out what is wrong?

Regards,
Thomas

From andrew at lunn.ch  Sat Feb  6 10:34:14 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Sat, 6 Feb 2016 19:34:14 +0100
Subject: net: mv643xx: interface does not transmit after some time
In-Reply-To: <E4F9E0D0-9DA8-4E33-9F89-B49E47F11CE0@schloeter.net>
References: <E4F9E0D0-9DA8-4E33-9F89-B49E47F11CE0@schloeter.net>
Message-ID: <20160206183414.GD17218@lunn.ch>

> How can I figure out what is wrong?

Hi Thomas

Can you find an easily way to reproduce it? iperf, or scp a big file
etc.

If you have a simple and reliable way to reproduce it, i would suggest
doing a git bisect to find out which change broke it.

      Andrew


From jic23 at kernel.org  Sat Feb  6 10:38:54 2016
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sat, 6 Feb 2016 18:38:54 +0000
Subject: [PATCH] iio: chemical: select IRQ_WORK for ATLAS ph sensor
In-Reply-To: <CAKzfze8b7Q4ZHyXW=wq4K2ETFoMrfERpTci2dSAzSgCCrWpnzg@mail.gmail.com>
References: <5127664.OXcBoKUPQO@wuerfel>
 <CAKzfze8b7Q4ZHyXW=wq4K2ETFoMrfERpTci2dSAzSgCCrWpnzg@mail.gmail.com>
Message-ID: <56B63DBE.8040507@kernel.org>

On 03/02/16 07:55, Matt Ranostay wrote:
> Reviewed-by: Matt Ranostay <mranostay at gmail.com>
> 
> On Tue, Feb 2, 2016 at 6:36 AM, Arnd Bergmann <arnd at arndb.de> wrote:
>> The newly added atlas-ph-sensor driver uses irq_work_queue, which
>> may not always be enabled:
>>
>> ERROR: "irq_work_queue" [drivers/iio/chemical/atlas-ph-sensor.ko] undefined!
>>
>> This adds a 'select' statement to Kconfig to ensure it's there
>> when we need it.
>>
>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>> Fixes: 27dec00ecf2d ("iio: chemical: add Atlas pH-SM sensor support")
>>
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to fail to spot and IRQ_WORK related issues ;)

Thanks,

Jonathan
>> diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
>> index ce7cd1370f74..f73290f84c90 100644
>> --- a/drivers/iio/chemical/Kconfig
>> +++ b/drivers/iio/chemical/Kconfig
>> @@ -10,6 +10,7 @@ config ATLAS_PH_SENSOR
>>         select REGMAP_I2C
>>         select IIO_BUFFER
>>         select IIO_TRIGGERED_BUFFER
>> +       select IRQ_WORK
>>         help
>>          Say Y here to build I2C interface support for the Atlas
>>          Scientific OEM pH-SM sensor.
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



From timur at codeaurora.org  Sat Feb  6 10:55:37 2016
From: timur at codeaurora.org (Timur Tabi)
Date: Sat, 6 Feb 2016 12:55:37 -0600
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <CADyBb7vRKjDoeOfH=3Uwz+D0xyXaC9cM4ZSEO+MwL8Gw5T-Umg@mail.gmail.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
 <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
 <56B2DEE4.7060901@roeck-us.net>
 <CADyBb7unAHEOMfruWS82RkHK6uwPAWCxUx9jqzSkiHU4LHDSeA@mail.gmail.com>
 <56B4B4E2.40105@roeck-us.net>
 <CADyBb7sP=d+BWOdmNEAs38yRcmXVjYsFX=XNffNpGqfybpxTfQ@mail.gmail.com>
 <56B5363D.20200@roeck-us.net>
 <CADyBb7vRKjDoeOfH=3Uwz+D0xyXaC9cM4ZSEO+MwL8Gw5T-Umg@mail.gmail.com>
Message-ID: <56B641A9.3040801@codeaurora.org>

Fu Wei wrote:
> if (action) {
>          wdd->min_timeout = 1;
>          wdd->max_timeout = U32_MAX / gwdt->clk;
> } else {
>          wdd->min_timeout = 2;
>          wdd->max_timeout = U32_MAX / gwdt->clk * 2;
> }

Why would the minimum timeout be 2?  You can program WOR to timeout in 
half a second, can't you?

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.


From linux at roeck-us.net  Sat Feb  6 10:57:48 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Sat, 6 Feb 2016 10:57:48 -0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <CADyBb7vRKjDoeOfH=3Uwz+D0xyXaC9cM4ZSEO+MwL8Gw5T-Umg@mail.gmail.com>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
 <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
 <56B2DEE4.7060901@roeck-us.net>
 <CADyBb7unAHEOMfruWS82RkHK6uwPAWCxUx9jqzSkiHU4LHDSeA@mail.gmail.com>
 <56B4B4E2.40105@roeck-us.net>
 <CADyBb7sP=d+BWOdmNEAs38yRcmXVjYsFX=XNffNpGqfybpxTfQ@mail.gmail.com>
 <56B5363D.20200@roeck-us.net>
 <CADyBb7vRKjDoeOfH=3Uwz+D0xyXaC9cM4ZSEO+MwL8Gw5T-Umg@mail.gmail.com>
Message-ID: <56B6422C.7070302@roeck-us.net>

On 02/06/2016 10:02 AM, Fu Wei wrote:
> Hi Guenter,
>
> On 6 February 2016 at 07:54, Guenter Roeck <linux at roeck-us.net> wrote:
>> On 02/05/2016 10:21 AM, Fu Wei wrote:
>>>
>>> On 5 February 2016 at 22:42, Guenter Roeck <linux at roeck-us.net> wrote:
>>>>
>>>> On 02/05/2016 01:51 AM, Fu Wei wrote:
>>>>>
>>>>>
>>>>> Hi Guenter,
>>>>>
>>>>> On 4 February 2016 at 13:17, Guenter Roeck <linux at roeck-us.net> wrote:
>>>>>>
>>>>>>
>>>>>> On 02/03/2016 03:00 PM, Fu Wei wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 4 February 2016 at 02:45, Timur Tabi <timur at codeaurora.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Fu Wei wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As you know I have made the pre-timeout support patch, If people
>>>>>>>>> like
>>>>>>>>> it, i am happy to go on upstream it separately.
>>>>>>>>>
>>>>>>>>> If we want to use pre-timeout here, user only can use get_pretimeout
>>>>>>>>> and disable panic by setting pretimeout to 0
>>>>>>>>> but user can not really set pretimeout, because "pre-timeout  ==
>>>>>>>>> timeout / 2 (always)".
>>>>>>>>> if user want to change pretimeout, he/she has to set_time instead.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Ok, I think patches 4 and 5 should be combined, and I think the
>>>>>>>> Kconfig
>>>>>>>> entry should be removed and just use panic_enabled.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Agreed.
>>>>>
>>>>>
>>>>>
>>>>> np, will do
>>>>>
>>>>>>>
>>>>>>>
>>>>>>> NP, will update this patchset like that ,  thanks :-)
>>>>>>>
>>>>>>
>>>>>> Also, if panic is enabled, the timeout needs to be adjusted accordingly
>>>>>> (to only panic after the entire timeout period has expired, not after
>>>>>> half of it). We can not panic the system after timeout / 2.
>>>>>
>>>>>
>>>>>
>>>>> OK, my thought is
>>>>>
>>>>> if panic is enabled :
>>>>> |--------WOR-------WS0--------WOR-------WS1
>>>>> |------timeout------(panic)------timeout-----reset
>>>>>
>>>>> if panic is disabled .
>>>>> |--------WOR-------WS0--------WOR-------WS1
>>>>> |---------------------timeout---------------------reset
>>>>>
>>>>>     panic_enabled only can be configured when module is loaded by module
>>>>> parameter
>>>>>
>>>>> But user should know that max_timeout(panic_enable) =
>>>>> max_timeout(panic_disable) / 2
>>>>>
>>>>
>>>> That means you'll have to update max_timeout accordingly.
>>>
>>>
>>> panic_enabled only can be configured when module is loaded, so we
>>> don't need to update it.
>>>
>>> max_timeout will only be set up in the init stage.
>>>
>>> Does it make sense ? :-)
>>>
>> Not sure I understand your problem or question.
>>
>> max_timeout will have to reflect the correct maximum timeout, under
>> all circumstances. It will have to be set to the correct value before
>> the watchdog driver is registered.
>
> yes, understood,  my thought is :
>
> in  static int sbsa_gwdt_probe(struct platform_device *pdev)
>
> if (action) {
>          wdd->min_timeout = 1;
>          wdd->max_timeout = U32_MAX / gwdt->clk;
> } else {
>          wdd->min_timeout = 2;
>          wdd->max_timeout = U32_MAX / gwdt->clk * 2;

Pretty much, though you would also have to adjust all calculations
using gwdt->clk, in both set_timeout() and get_timeout(). Wonder if
you could adjust gwdt->clk instead.

Does min_timeout really have to be 2 if panic is disabled ?
The only reason seems to be the calculation in sbsa_gwdt_set_timeout().

	writel(timeout / 2 * gwdt->clk, gwdt->control_base + SBSA_GWDT_WOR);

Maybe you could use something like

	writel(timeout * (gwdt->clk / 2), ...);

instead. Or, as mentioned above, adjust the value of gwdt->clk
to include the factor.

Thanks,
Guenter



From friesendrywall at gmail.com  Sat Feb  6 11:29:45 2016
From: friesendrywall at gmail.com (Erik Friesen)
Date: Sat, 6 Feb 2016 14:29:45 -0500
Subject: SGTL5000 misc
In-Reply-To: <CAOMZO5BaYKuTrWvopJn5RbvoJqEt4dQt1vmB7QCHLPaKD-ohLQ@mail.gmail.com>
References: <CAEuupiuhPR48Upo=8f0zV8cxf0Vefgx3qA+vC+QDWAOV4n-e3Q@mail.gmail.com>
 <CAOMZO5BPNc1ncz6J8yhcBYywCVuTxKYMYhiNUt_Jq3LZsKdi+A@mail.gmail.com>
 <CAEuupiszxAj7JkJu-5ozqgEnTWkz9FQEpxN8dmEN+KtaV-76ww@mail.gmail.com>
 <CAOMZO5DhrzdVyTVPB3FNquV4rDQ8a0MQrsJMosVsUQN63hj1Ww@mail.gmail.com>
 <CAEuupiuoB7nMSc8Fbyort1rJd=ZhYc0zfJNkd=ckUYk1qd8Z7Q@mail.gmail.com>
 <CAOMZO5C4QUHnJr=pisnYWCYZ0zUt+7HO846aPQui0zcLyX0N-Q@mail.gmail.com>
 <CAEuupivdftoopCOX3f7KRbV9poKdjdD3s9hfcbgB2TYjHmrjvw@mail.gmail.com>
 <CAEuupit8pVdnehkZkZPmq1QBHaS0sUG4NFuVFX37dKHn18j7DQ@mail.gmail.com>
 <CAOMZO5BxFRzi3qJAK=xDGger_MK9GZhuM00ugo836PHK_zJKjQ@mail.gmail.com>
 <CAEuupium67HD-sz+ViPx8-L4S0TsS-C8ZrX3po382r=E-9QYgw@mail.gmail.com>
 <CAOMZO5Dos2xidZWrGffHRw33GjcJi+CvitFC5hKW3Hy0++GEmg@mail.gmail.com>
 <CAEuupiti=Z9CeQpgUyvyQcfWEE_ReS4RpY9sHtY=OdN3YFjZQw@mail.gmail.com>
 <CAOMZO5BaYKuTrWvopJn5RbvoJqEt4dQt1vmB7QCHLPaKD-ohLQ@mail.gmail.com>
Message-ID: <CAEuupis2WSckA+QQd0A6kw=MFuGowOQX-GFvrs=8TegBcP2Xiw@mail.gmail.com>

I am subscribed and getting emails from the list, not sure what is up.

On Sat, Feb 6, 2016 at 12:33 PM, Fabio Estevam <festevam at gmail.com> wrote:
> On Sat, Feb 6, 2016 at 3:22 PM, Erik Friesen <friesendrywall at gmail.com> wrote:
>> Well, I have posted a thing or two there, not sure if the mailing list
>> is even working, as I haven't received any replies.
>
> I haven't seen your patches there. You need to subscribe to alsa-devel first.


From gary.bisson at boundarydevices.com  Sat Feb  6 11:54:28 2016
From: gary.bisson at boundarydevices.com (Gary Bisson)
Date: Sat, 6 Feb 2016 20:54:28 +0100
Subject: [PATCH 1/2] ARM: dts: mx53qsb: Enable VPU support
In-Reply-To: <1372683396.4971.35.camel@pizza.hi.pengutronix.de>
References: <1372459759-10488-1-git-send-email-festevam@gmail.com>
 <1372683396.4971.35.camel@pizza.hi.pengutronix.de>
Message-ID: <20160206195428.GA10316@x240.lan>

Hi Philipp,

On Mon, Jul 01, 2013 at 02:56:36PM +0200, Philipp Zabel wrote:
> Hi Fabio,
> 
> Am Freitag, den 28.06.2013, 19:49 -0300 schrieb Fabio Estevam:
> > From: Fabio Estevam <fabio.estevam at freescale.com>
> > 
> > Enable Video Processing Unit (VPU) support.
> > 
> > Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
> > ---
> > Depends on Philipp Zabel's patch:
> > [PATCH] ARM: dts: add sram for imx53 and imx6q
> > 
> > Philipp,
> > 
> > I tried using the original mx53 vpu firmware that comes with the FSL BSP, but it
> > failed to load:
> > 
> > coda 63ff4000.vpu: firmware get command error                                   
> > coda 63ff4000.vpu: HW initialization failed  
> > 
> > Any suggestions?
> > 
> > Thanks!
> 
> /*
>  * The CODA driver needs the raw firmware without header in memory order.
>  * This is how I converted vpu_fw_imx53.bin from the Freescale BSP into
>  * v4l2-coda7541-imx53.bin:
>  */

Sorry to revive an old thread but I was wondering if that firmware
conversion tool is available somewhere on a git repo?

Regards,
Gary


From sergei.shtylyov at cogentembedded.com  Sat Feb  6 13:37:39 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sun, 7 Feb 2016 00:37:39 +0300
Subject: [PATCH 4/5] ARM: dts: NSP: Add SP805 Support to DT
In-Reply-To: <CA+JzhdJa9juORA73TRjWbM=p4dZ1wbO=+RmkyOt9h8_MUU_FZw@mail.gmail.com>
References: <1454712204-30419-1-git-send-email-jonmason@broadcom.com>
 <1454712204-30419-5-git-send-email-jonmason@broadcom.com>
 <56B5EBCB.4080305@cogentembedded.com>
 <CAC3K-4p9kMALwg-Y355c-u06sAT-HLLY04=XMUer+R71OJLdcQ@mail.gmail.com>
 <CA+JzhdJa9juORA73TRjWbM=p4dZ1wbO=+RmkyOt9h8_MUU_FZw@mail.gmail.com>
Message-ID: <56B667A3.8010200@cogentembedded.com>

On 02/06/2016 11:47 PM, Scott Branden wrote:

>             Add support for the ARM SP805 Watchdog timer to the Northstar Plus
>             device tree.
>
>             Signed-off-by: Jon Mason <jonmason at broadcom.com
>             <mailto:jonmason at broadcom.com>>
>             ---
>                arch/arm/boot/dts/bcm-nsp.dtsi | 8 ++++++++
>                1 file changed, 8 insertions(+)
>
>             diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi
>             b/arch/arm/boot/dts/bcm-nsp.dtsi
>             index 415a0a6..0e8cb6e 100644
>             --- a/arch/arm/boot/dts/bcm-nsp.dtsi
>             +++ b/arch/arm/boot/dts/bcm-nsp.dtsi
>             @@ -203,6 +203,14 @@
>                                      clock-frequency = <100000>;
>                              };
>
>             +               wdt at 39000 {
>
>
>             Should be "watchdog at 39000", according to ePAPR.
>
>
>     Thanks, I'll fix it and send it right out.

> I didn't know ePAPR was a requirement for a linux dtb?  We haven't done this
> with the wtd in other dts files.  Is this described somewhere?

    Nobody reads the docs. Like this:

http://www.devicetree.org/Device_Tree_Usage

    That page refers to the ePAPR 1.0 (not the most recent).

MBR, Sergei



From robert.jarzmik at free.fr  Sat Feb  6 13:46:00 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat, 06 Feb 2016 22:46:00 +0100
Subject: [PATCH] ARM: pxa: fix irq initialization for pxa3xx devicetree
In-Reply-To: <1454274354-4381-1-git-send-email-robert.jarzmik@free.fr> (Robert
 Jarzmik's message of "Sun, 31 Jan 2016 22:05:54 +0100")
References: <1454274354-4381-1-git-send-email-robert.jarzmik@free.fr>
Message-ID: <877fih4inb.fsf@belgarion.home>

Robert Jarzmik <robert.jarzmik at free.fr> writes:

> The initialization of interrupt controller for devicetree platform was
> done for pxa2xx platforms, but not for pxa3xx ones.
>
> Fix this my adding the missing initialization call.
>
> Fixes: 089d03629b04 ("ARM: pxa: add devicetree code for irq handling")
> Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
No, this is incorrect.

The reason behind is that it relies on a patch not yet upstreamed, which was
breaking exactly this init_irq.

Let's drop this and replace it with the good patch.

Cheers.

--
Robert


From robert.jarzmik at free.fr  Sat Feb  6 13:48:35 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat,  6 Feb 2016 22:48:35 +0100
Subject: [PATCH] ARM: pxa: pxa3xx device-tree support cleanup
Message-ID: <1454795315-11294-1-git-send-email-robert.jarzmik@free.fr>

Clocks, timer and several other drivers have well defined and working
device-tree bindings. Clean-up the code to leave only the strict
minimum. The final goal will be to remove the lookup array.

Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
 arch/arm/mach-pxa/pxa-dt.c | 24 ------------------------
 1 file changed, 24 deletions(-)

diff --git a/arch/arm/mach-pxa/pxa-dt.c b/arch/arm/mach-pxa/pxa-dt.c
index 8e0e62ccdced..f128133a8f30 100644
--- a/arch/arm/mach-pxa/pxa-dt.c
+++ b/arch/arm/mach-pxa/pxa-dt.c
@@ -19,42 +19,18 @@
 #include "generic.h"
 
 #ifdef CONFIG_PXA3xx
-static const struct of_dev_auxdata const pxa3xx_auxdata_lookup[] __initconst = {
-	OF_DEV_AUXDATA("mrvl,pxa-uart",		0x40100000, "pxa2xx-uart.0", NULL),
-	OF_DEV_AUXDATA("mrvl,pxa-uart",		0x40200000, "pxa2xx-uart.1", NULL),
-	OF_DEV_AUXDATA("mrvl,pxa-uart",		0x40700000, "pxa2xx-uart.2", NULL),
-	OF_DEV_AUXDATA("mrvl,pxa-uart",		0x41600000, "pxa2xx-uart.3", NULL),
-	OF_DEV_AUXDATA("marvell,pxa-mmc",	0x41100000, "pxa2xx-mci.0", NULL),
-	OF_DEV_AUXDATA("intel,pxa3xx-gpio",	0x40e00000, "pxa3xx-gpio", NULL),
-	OF_DEV_AUXDATA("marvell,pxa-ohci",	0x4c000000, "pxa27x-ohci", NULL),
-	OF_DEV_AUXDATA("mrvl,pxa-i2c",		0x40301680, "pxa2xx-i2c.0", NULL),
-	OF_DEV_AUXDATA("mrvl,pwri2c",		0x40f500c0, "pxa3xx-i2c.1", NULL),
-	OF_DEV_AUXDATA("marvell,pxa3xx-nand",	0x43100000, "pxa3xx-nand", NULL),
-	{}
-};
-
-static void __init pxa3xx_dt_init(void)
-{
-	of_platform_populate(NULL, of_default_bus_match_table,
-			     pxa3xx_auxdata_lookup, NULL);
-}
-
 static const char *const pxa3xx_dt_board_compat[] __initconst = {
 	"marvell,pxa300",
 	"marvell,pxa310",
 	"marvell,pxa320",
 	NULL,
 };
-#endif
 
-#ifdef CONFIG_PXA3xx
 DT_MACHINE_START(PXA_DT, "Marvell PXA3xx (Device Tree Support)")
 	.map_io		= pxa3xx_map_io,
 	.init_irq	= pxa3xx_dt_init_irq,
 	.handle_irq	= pxa3xx_handle_irq,
-	.init_time	= pxa_timer_init,
 	.restart	= pxa_restart,
-	.init_machine	= pxa3xx_dt_init,
 	.dt_compat	= pxa3xx_dt_board_compat,
 MACHINE_END
 #endif
-- 
2.1.4



From robert.jarzmik at free.fr  Sat Feb  6 13:55:05 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat, 06 Feb 2016 22:55:05 +0100
Subject: [PATCH v2 18/51] mtd: docg3: use mtd_set_ecclayout() where
 appropriate
In-Reply-To: <1454580434-32078-19-git-send-email-boris.brezillon@free-electrons.com>
 (Boris Brezillon's message of "Thu, 4 Feb 2016 11:06:41 +0100")
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
 <1454580434-32078-19-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <8737t54i86.fsf@belgarion.home>

Boris Brezillon <boris.brezillon at free-electrons.com> writes:

> Use the mtd_set_ecclayout() helper instead of directly assigning the
> mtd->ecclayout field.
>
> Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
Acked-by: Robert Jarzmik <robert.jarzmik at free.fr>

Cheers.

--
Robert


From arno at natisbad.org  Sat Feb  6 13:57:04 2016
From: arno at natisbad.org (Arnaud Ebalard)
Date: Sat, 06 Feb 2016 22:57:04 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <CAKzmTe24iz1Ka7Kkke=ZTVbDGZxxDjBH0m2iEVCQOGuuEpi4Gg@mail.gmail.com>
 (JM's message of "Sat, 6 Feb 2016 16:14:49 +0100")
References: <CAKzmTe0mvZD5UwqM47uXbM7Z7oAJpE4g4BVMba1hkzqNu+Zbgw@mail.gmail.com>
 <20160205090246.GE32272@lunn.ch> <20160205112907.796afb05@bbrezillon>
 <CAKzmTe20fT8BcRaDaf2gz92KMAK0kEUkaD-kPq_cPF1WKBdroA@mail.gmail.com>
 <87vb632maf.fsf@free-electrons.com>
 <CAKzmTe1AqNQwjcsAULotd010NXuk1AYjj5p6UoqT_Zu=BCHdcw@mail.gmail.com>
 <87mvrf2l6p.fsf@free-electrons.com>
 <87io232kat.fsf@free-electrons.com> <8760y2vqje.fsf@natisbad.org>
 <87twlmdg2b.fsf@natisbad.org>
 <CAKzmTe24iz1Ka7Kkke=ZTVbDGZxxDjBH0m2iEVCQOGuuEpi4Gg@mail.gmail.com>
Message-ID: <87y4axy027.fsf@natisbad.org>

Hi,

JM <fijam at archlinux.us> writes:

> On Fri, Feb 5, 2016 at 10:04 PM, Arnaud Ebalard <arno at natisbad.org> wrote:
>> Hi,
>>
>>> I'll try and do the same now w/ CESA support compiled as module to see
>>> what I get. I'll keep you posted.
>>
>> root at mood:~# insmod /tmp/marvell-cesa.ko
>> [  573.897977] marvell-cesa f1030000.crypto: CESA device successfully registered
>>
>> root at mood:~# uname -a
>> Linux mood 4.4.0.duov2 #2 Fri Feb 5 21:42:49 CET 2016 armv5tel GNU/Linux
>>
>> root at mood:~# zcat /proc/config.gz | grep -i CESA
>> # CONFIG_CRYPTO_DEV_MV_CESA is not set
>> CONFIG_CRYPTO_DEV_MARVELL_CESA=m
>>
>> Cheers,
>>
>> a+
>>
>> ps: my config is temporarily at http://natisbad.org/config-duov2-cesa
>
> I've built a vanilla 4.4.1 kernel image without any debian-specific
> patches but using the same oldconfig
> (http://heap.ovh/files/config-4.4.1.vanilla).
>
> # uname -a
> Linux yukikaze 4.4.1.vanilla #1 Sat Feb 6 14:18:19 CET 2016 armv5tel GNU/Linux
>
> # modprobe marvell_cesa allhwsupport=1
>
> # dmesg | tail -n1
> [  116.972828] marvell-cesa: probe of f1030000.crypto failed with error -12
>
> The dtb hasn't changed:
> # diff -s kirkwood-ts219-6282.dtb dtb-4.4.1.vanilla
> Files kirkwood-ts219-6282.dtb and dtb-4.4.1.vanilla are identical
>
> I am also attaching lsmod: http://heap.ovh/files/lsmod-vanilla-4.4.1
> and full dmesg: http://heap.ovh/files/dmesg-vanilla-4.4.1
>
> Perhaps I am missing something obvious? I suppose the next step would
> be to build a minimal kernel based on the config for the duov2?

I must confess your problem is interesting ;-)

I did a diff between your .config and mine for the Duo v2 and then tried
to enable/disable the most promising options you had and the one I had
not but I cannot reproduce the what you get, i.e. marvell_cesa module
always loads as expectec. 

So, I also think the best path would be to use my Duo v2 file w/ your dtb
and run it on your device.

Last (unrelated) remark/question: looking at the .dts for your ts219, I
noticed one thing I am curious about:

        memory {
                device_type = "memory";
                reg = <0x00000000 0x20000000>;
        };

        ...

        ocp at f1000000 {
                pinctrl: pin-controller at 10000 {

                        pinctrl-0 = <&pmx_ram_size &pmx_board_id>;
                        pinctrl-names = "default";

                        pmx_ram_size: pmx-ram-size {
                                /* RAM: 0: 256 MB, 1: 512 MB */
                                marvell,pins = "mpp36";
                                marvell,function = "gpio";
                        };

It seems 512MB are declared for all TS219 devices but the level
available on mpp36 provides the real amount of RAM in the device.
Who/What is expected to do the adjustment on platform w/ only 256MB, if
any?

Cheers,

a+




From robert.jarzmik at free.fr  Sat Feb  6 13:57:39 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat, 06 Feb 2016 22:57:39 +0100
Subject: [PATCH v2 20/51] mtd: docg3: switch to mtd_ooblayout_ops
In-Reply-To: <1454580434-32078-21-git-send-email-boris.brezillon@free-electrons.com>
 (Boris Brezillon's message of "Thu, 4 Feb 2016 11:06:43 +0100")
References: <1454580434-32078-1-git-send-email-boris.brezillon@free-electrons.com>
 <1454580434-32078-21-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <87y4ax33jg.fsf@belgarion.home>

Boris Brezillon <boris.brezillon at free-electrons.com> writes:

> Replace the nand_ecclayout definition by the equivalent mtd_ooblayout_ops
> definition.
>
> Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
Acked-by: Robert Jarzmik <robert.jarzmik at free.fr>

Cheers.

--
Robert


From stefan.wahren at i2se.com  Sat Feb  6 14:01:07 2016
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat,  6 Feb 2016 22:01:07 +0000
Subject: [PATCH 0/2] ARM: bcm2835_defconfig: Enable RPi power domain driver
Message-ID: <1454796069-26830-1-git-send-email-stefan.wahren@i2se.com>

This patch series allow us to enable power domains on the Raspberry Pi
in the defconfig.

This requires Stephen Warren's latest series ("ARM: bcm2835_defconfig:
rebuild on next-20160205") applied first.

Stefan Wahren (2):
  ARM: bcm2835_defconfig: Enable RPi firmware driver
  ARM: bcm2835_defconfig: Enable RPi power domain driver

 arch/arm/configs/bcm2835_defconfig |    2 ++
 1 file changed, 2 insertions(+)

-- 
1.7.9.5



From stefan.wahren at i2se.com  Sat Feb  6 14:01:08 2016
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat,  6 Feb 2016 22:01:08 +0000
Subject: [PATCH 1/2] ARM: bcm2835_defconfig: Enable RPi firmware driver
In-Reply-To: <1454796069-26830-1-git-send-email-stefan.wahren@i2se.com>
References: <1454796069-26830-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1454796069-26830-2-git-send-email-stefan.wahren@i2se.com>

This enables the Raspberry Pi driver for GPU specific features.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 arch/arm/configs/bcm2835_defconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 7c20a0b..9377f1b 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -108,6 +108,7 @@ CONFIG_BCM2835_MBOX=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_PWM=y
 CONFIG_PWM_BCM2835=y
+CONFIG_RASPBERRYPI_FIRMWARE=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT2_FS_POSIX_ACL=y
-- 
1.7.9.5



From stefan.wahren at i2se.com  Sat Feb  6 14:01:09 2016
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat,  6 Feb 2016 22:01:09 +0000
Subject: [PATCH 2/2] ARM: bcm2835_defconfig: Enable RPi power domain driver
In-Reply-To: <1454796069-26830-1-git-send-email-stefan.wahren@i2se.com>
References: <1454796069-26830-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <1454796069-26830-3-git-send-email-stefan.wahren@i2se.com>

After enabling the Raspberry Pi firmware driver which allow us to handle
power domains for USB or graphics.

Signed-off-by: Stefan Wahren <stefan.wahren at i2se.com>
---
 arch/arm/configs/bcm2835_defconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 9377f1b..1ef69fc 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -106,6 +106,7 @@ CONFIG_STAGING=y
 CONFIG_MAILBOX=y
 CONFIG_BCM2835_MBOX=y
 # CONFIG_IOMMU_SUPPORT is not set
+CONFIG_RASPBERRYPI_POWER=y
 CONFIG_PWM=y
 CONFIG_PWM_BCM2835=y
 CONFIG_RASPBERRYPI_FIRMWARE=y
-- 
1.7.9.5



From Tirumalesh.Chalamarla at caviumnetworks.com  Sat Feb  6 14:31:38 2016
From: Tirumalesh.Chalamarla at caviumnetworks.com (Chalamarla, Tirumalesh)
Date: Sat, 6 Feb 2016 22:31:38 +0000
Subject: [PATCH] arm64: KVM: Add 48bit PA support for EL2  translations
In-Reply-To: <20160206120524.09b9f893@arm.com>
References: <1454700496-21221-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160206120524.09b9f893@arm.com>
Message-ID: <8A2DF702-D040-487F-BE38-EE94006FC3A7@caviumnetworks.com>






On 2/6/16, 4:05 AM, "Marc Zyngier" <marc.zyngier at arm.com> wrote:

>Tirumalesh,
>
>On Fri, 5 Feb 2016 11:28:16 -0800
><tchalamarla at caviumnetworks.com> wrote:
>
>> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>> 
>> Systems where RAM is at higher address and MultiNode systems
>
>What influence a "MultiNode" (for whatever definition of node you have)
>system has on the memory map?
>
>> whith higher address RAM, 39 bit max PA for EL2 translations
>> is not sufficient.
>
>I read it as 40 bits, not 39.
My bad.
>
>> 
>> This patch sets max possible PA(48bit) for EL2 translations.
>
>From the ARM ARM:
>
>"If {I}PS is programmed to a value larger than the implemented physical
>address size, then the PE behaves as if programmed with the implemented
>physical address size, but software must not rely on this behavior.
>That is, the output address size is never larger than the implemented
>physical address size."
>
>> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>> ---
>>  arch/arm64/include/asm/kvm_arm.h | 10 +++++++++-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>> 
>> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
>> index 738a95f..3fc38a4 100644
>> --- a/arch/arm64/include/asm/kvm_arm.h
>> +++ b/arch/arm64/include/asm/kvm_arm.h
>> @@ -98,7 +98,12 @@
>>  #define TCR_EL2_RES1	((1 << 31) | (1 << 23))
>>  #define TCR_EL2_TBI	(1 << 20)
>>  #define TCR_EL2_PS	(7 << 16)
>> +#define TCR_EL2_PS_32B	(0 << 16)
>> +#define TCR_EL2_PS_36B	(1 << 16)
>>  #define TCR_EL2_PS_40B	(2 << 16)
>> +#define TCR_EL2_PS_42B	(3 << 16)
>> +#define TCR_EL2_PS_44B	(4 << 16)
>> +#define TCR_EL2_PS_48B	(5 << 16)
>>  #define TCR_EL2_TG0	(1 << 14)
>>  #define TCR_EL2_SH0	(3 << 12)
>>  #define TCR_EL2_ORGN0	(3 << 10)
>> @@ -107,7 +112,10 @@
>>  #define TCR_EL2_MASK	(TCR_EL2_TG0 | TCR_EL2_SH0 | \
>>  			 TCR_EL2_ORGN0 | TCR_EL2_IRGN0 | TCR_EL2_T0SZ)
>>  
>> -#define TCR_EL2_FLAGS	(TCR_EL2_RES1 | TCR_EL2_PS_40B)
>> +/*
>> + * Assign the highest possible PS.
>> + */
>> +#define TCR_EL2_FLAGS	(TCR_EL2_RES1 | TCR_EL2_PS_48B)
>>  
>>  /* VTCR_EL2 Registers bits */
>>  #define VTCR_EL2_RES1		(1 << 31)
>
>So this is a NAK. If you want to address this problem, do it properly
>(hint: look at how we deal with VTCR_EL2).
Sure, will reimplement it. 
>
>Thanks,
>
>	M.
>-- 
>Jazz is not dead. It just smells funny.

From tbm at cyrius.com  Sat Feb  6 15:19:35 2016
From: tbm at cyrius.com (Martin Michlmayr)
Date: Sat, 6 Feb 2016 15:19:35 -0800
Subject: net: mv643xx: interface does not transmit after some time
In-Reply-To: <20160206183414.GD17218@lunn.ch>
References: <E4F9E0D0-9DA8-4E33-9F89-B49E47F11CE0@schloeter.net>
 <20160206183414.GD17218@lunn.ch>
Message-ID: <20160206231935.GA30734@jirafa.cyrius.com>

* Andrew Lunn <andrew at lunn.ch> [2016-02-06 19:34]:
> Can you find an easily way to reproduce it? iperf, or scp a big file
> etc.

FWIW, we had a similar bug report in Debian recently:
https://lists.debian.org/debian-arm/2016/01/msg00098.html

Turning off TCP RX and TX offloading make it go away:
https://lists.debian.org/debian-arm/2016/01/msg00100.html

Hopefully Thomas can do a bisect.

-- 
Martin Michlmayr
http://www.cyrius.com/


From fu.wei at linaro.org  Sat Feb  6 18:02:09 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Sun, 7 Feb 2016 10:02:09 +0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <56B641A9.3040801@codeaurora.org>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
 <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
 <56B2DEE4.7060901@roeck-us.net>
 <CADyBb7unAHEOMfruWS82RkHK6uwPAWCxUx9jqzSkiHU4LHDSeA@mail.gmail.com>
 <56B4B4E2.40105@roeck-us.net>
 <CADyBb7sP=d+BWOdmNEAs38yRcmXVjYsFX=XNffNpGqfybpxTfQ@mail.gmail.com>
 <56B5363D.20200@roeck-us.net>
 <CADyBb7vRKjDoeOfH=3Uwz+D0xyXaC9cM4ZSEO+MwL8Gw5T-Umg@mail.gmail.com>
 <56B641A9.3040801@codeaurora.org>
Message-ID: <CADyBb7vDUpUHtU13A8C-hkBP=oo=KN_HTARJ0FKVVET9gnwtWQ@mail.gmail.com>

On 7 February 2016 at 02:55, Timur Tabi <timur at codeaurora.org> wrote:
> Fu Wei wrote:
>>
>> if (action) {
>>          wdd->min_timeout = 1;
>>          wdd->max_timeout = U32_MAX / gwdt->clk;
>> } else {
>>          wdd->min_timeout = 2;
>>          wdd->max_timeout = U32_MAX / gwdt->clk * 2;
>> }
>
>
> Why would the minimum timeout be 2?  You can program WOR to timeout in half
> a second, can't you?

Yes, I think we can.
you are right, will fix that.

>
>
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the
> Code Aurora Forum, hosted by The Linux Foundation.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From fu.wei at linaro.org  Sat Feb  6 18:12:12 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Sun, 7 Feb 2016 10:12:12 +0800
Subject: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout
 panic support
In-Reply-To: <56B6422C.7070302@roeck-us.net>
References: <1454519923-25230-1-git-send-email-fu.wei@linaro.org>
 <1454519923-25230-6-git-send-email-fu.wei@linaro.org>
 <56B23883.7000501@codeaurora.org>
 <CADyBb7sxPg-QUjTbeHFtYkctKc_g7D8O=+jqbXN+DCCoCEnFqA@mail.gmail.com>
 <56B23E99.1030604@codeaurora.org>
 <CADyBb7s4opxfPFuX=1-qEE6uhsaMXgofAJPbHUQHrng2AUwqNA@mail.gmail.com>
 <56B2423B.1020109@codeaurora.org>
 <CADyBb7uULCn97ea19zH8dB4QX1QA8=AXL94d6gXgFxXM8haBNA@mail.gmail.com>
 <56B24642.8090105@codeaurora.org>
 <CADyBb7s_QeU=pYqN9G+5WMtx-L+=QC6uZR6N6ZWPOixnkHzPjw@mail.gmail.com>
 <56B24AB5.3070001@codeaurora.org>
 <CADyBb7usPpY=YLjecXce63zY5e1tniPLmNsVY=8CJHJsCqBgQw@mail.gmail.com>
 <56B2DEE4.7060901@roeck-us.net>
 <CADyBb7unAHEOMfruWS82RkHK6uwPAWCxUx9jqzSkiHU4LHDSeA@mail.gmail.com>
 <56B4B4E2.40105@roeck-us.net>
 <CADyBb7sP=d+BWOdmNEAs38yRcmXVjYsFX=XNffNpGqfybpxTfQ@mail.gmail.com>
 <56B5363D.20200@roeck-us.net>
 <CADyBb7vRKjDoeOfH=3Uwz+D0xyXaC9cM4ZSEO+MwL8Gw5T-Umg@mail.gmail.com>
 <56B6422C.7070302@roeck-us.net>
Message-ID: <CADyBb7vTeamcE68FJ6G8X-VKww-AAbfptvB9jcKLg9oRTzVcLg@mail.gmail.com>

On 7 February 2016 at 02:57, Guenter Roeck <linux at roeck-us.net> wrote:
> On 02/06/2016 10:02 AM, Fu Wei wrote:
>>
>> Hi Guenter,
>>
>> On 6 February 2016 at 07:54, Guenter Roeck <linux at roeck-us.net> wrote:
>>>
>>> On 02/05/2016 10:21 AM, Fu Wei wrote:
>>>>
>>>>
>>>> On 5 February 2016 at 22:42, Guenter Roeck <linux at roeck-us.net> wrote:
>>>>>
>>>>>
>>>>> On 02/05/2016 01:51 AM, Fu Wei wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Guenter,
>>>>>>
>>>>>> On 4 February 2016 at 13:17, Guenter Roeck <linux at roeck-us.net> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 02/03/2016 03:00 PM, Fu Wei wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4 February 2016 at 02:45, Timur Tabi <timur at codeaurora.org>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Fu Wei wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> As you know I have made the pre-timeout support patch, If people
>>>>>>>>>> like
>>>>>>>>>> it, i am happy to go on upstream it separately.
>>>>>>>>>>
>>>>>>>>>> If we want to use pre-timeout here, user only can use
>>>>>>>>>> get_pretimeout
>>>>>>>>>> and disable panic by setting pretimeout to 0
>>>>>>>>>> but user can not really set pretimeout, because "pre-timeout  ==
>>>>>>>>>> timeout / 2 (always)".
>>>>>>>>>> if user want to change pretimeout, he/she has to set_time instead.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ok, I think patches 4 and 5 should be combined, and I think the
>>>>>>>>> Kconfig
>>>>>>>>> entry should be removed and just use panic_enabled.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Agreed.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> np, will do
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> NP, will update this patchset like that ,  thanks :-)
>>>>>>>>
>>>>>>>
>>>>>>> Also, if panic is enabled, the timeout needs to be adjusted
>>>>>>> accordingly
>>>>>>> (to only panic after the entire timeout period has expired, not after
>>>>>>> half of it). We can not panic the system after timeout / 2.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> OK, my thought is
>>>>>>
>>>>>> if panic is enabled :
>>>>>> |--------WOR-------WS0--------WOR-------WS1
>>>>>> |------timeout------(panic)------timeout-----reset
>>>>>>
>>>>>> if panic is disabled .
>>>>>> |--------WOR-------WS0--------WOR-------WS1
>>>>>> |---------------------timeout---------------------reset
>>>>>>
>>>>>>     panic_enabled only can be configured when module is loaded by
>>>>>> module
>>>>>> parameter
>>>>>>
>>>>>> But user should know that max_timeout(panic_enable) =
>>>>>> max_timeout(panic_disable) / 2
>>>>>>
>>>>>
>>>>> That means you'll have to update max_timeout accordingly.
>>>>
>>>>
>>>>
>>>> panic_enabled only can be configured when module is loaded, so we
>>>> don't need to update it.
>>>>
>>>> max_timeout will only be set up in the init stage.
>>>>
>>>> Does it make sense ? :-)
>>>>
>>> Not sure I understand your problem or question.
>>>
>>> max_timeout will have to reflect the correct maximum timeout, under
>>> all circumstances. It will have to be set to the correct value before
>>> the watchdog driver is registered.
>>
>>
>> yes, understood,  my thought is :
>>
>> in  static int sbsa_gwdt_probe(struct platform_device *pdev)
>>
>> if (action) {
>>          wdd->min_timeout = 1;
>>          wdd->max_timeout = U32_MAX / gwdt->clk;
>> } else {
>>          wdd->min_timeout = 2;
>>          wdd->max_timeout = U32_MAX / gwdt->clk * 2;
>
>
> Pretty much, though you would also have to adjust all calculations
> using gwdt->clk, in both set_timeout() and get_timeout(). Wonder if
> you could adjust gwdt->clk instead.
>
> Does min_timeout really have to be 2 if panic is disabled ?
> The only reason seems to be the calculation in sbsa_gwdt_set_timeout().
>
>         writel(timeout / 2 * gwdt->clk, gwdt->control_base + SBSA_GWDT_WOR);
>
> Maybe you could use something like
>
>         writel(timeout * (gwdt->clk / 2), ...);
>
> instead. Or, as mentioned above, adjust the value of gwdt->clk
> to include the factor.

yes,  Thanks for pointing it out.
I will fix that following your suggestion.

>
> Thanks,
> Guenter
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From gregkh at linuxfoundation.org  Sat Feb  6 22:03:54 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Sat, 6 Feb 2016 22:03:54 -0800
Subject: [PATCH] staging: wilc1000: fix compilation without CONFIG_PM
In-Reply-To: <1454685729-3663377-1-git-send-email-arnd@arndb.de>
References: <1454685729-3663377-1-git-send-email-arnd@arndb.de>
Message-ID: <20160207060354.GA2714@kroah.com>

On Fri, Feb 05, 2016 at 04:21:50PM +0100, Arnd Bergmann wrote:
> After the addition of the wakeup code in wilc1000, it no longer
> builds when CONFIG_PM is disabled:
> 
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c: In function 'wilc_create_wiphy':
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:2632:13: error: 'struct wiphy' has no member named 'wowlan'
>   wdev->wiphy->wowlan = &wowlan_support;
> 
> This marks the wowlan_support variable as __maybe_unused and hides
> the reference when CONFIG_PM is disabled to avoid the build error.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 73584a40d748 ("staging: wilc1000: add ops resuem/suspend/wakeup in cfg80211")
> ---
>  drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

A different patch was sent just before yours.  Actually 2 different
ones...

thanks,

greg k-h


From gregkh at linuxfoundation.org  Sat Feb  6 23:11:54 2016
From: gregkh at linuxfoundation.org (Greg KH)
Date: Sat, 6 Feb 2016 23:11:54 -0800
Subject: [PATCH v2 04/10] serial: mps2-uart: add MPS2 UART driver
In-Reply-To: <1454413199-26573-5-git-send-email-vladimir.murzin@arm.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
 <1454413199-26573-5-git-send-email-vladimir.murzin@arm.com>
Message-ID: <20160207071154.GA32017@kroah.com>

On Tue, Feb 02, 2016 at 11:39:53AM +0000, Vladimir Murzin wrote:
> This driver adds support to the UART controller found on ARM MPS2
> platform.
> 
> Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
> ---
>  drivers/tty/serial/Kconfig       |   12 +
>  drivers/tty/serial/Makefile      |    1 +
>  drivers/tty/serial/mps2-uart.c   |  584 ++++++++++++++++++++++++++++++++++++++
>  include/uapi/linux/serial_core.h |    3 +
>  4 files changed, 600 insertions(+)
>  create mode 100644 drivers/tty/serial/mps2-uart.c
> 
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 39721ec..3a248be 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1450,6 +1450,18 @@ config SERIAL_EFM32_UART
>  	  This driver support the USART and UART ports on
>  	  Energy Micro's efm32 SoCs.
>  
> +config SERIAL_MPS2_UART_CONSOLE
> +	bool "MPS2 UART console support"
> +	depends on SERIAL_MPS2_UART
> +	select SERIAL_CORE_CONSOLE
> +
> +config SERIAL_MPS2_UART
> +	bool "MPS2 UART port"
> +	depends on ARM || COMPILE_TEST
> +	select SERIAL_CORE
> +	help
> +	  This driver support the UART ports on ARM MPS2.
> +
>  config SERIAL_EFM32_UART_CONSOLE
>  	bool "EFM32 UART/USART console support"
>  	depends on SERIAL_EFM32_UART=y
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index b391c9b..1062503 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -91,6 +91,7 @@ obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
>  obj-$(CONFIG_SERIAL_MEN_Z135)	+= men_z135_uart.o
>  obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
>  obj-$(CONFIG_SERIAL_STM32)	+= stm32-usart.o
> +obj-$(CONFIG_SERIAL_MPS2_UART)	+= mps2-uart.o
>  
>  # GPIOLIB helpers for modem control lines
>  obj-$(CONFIG_SERIAL_MCTRL_GPIO)	+= serial_mctrl_gpio.o
> diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
> new file mode 100644
> index 0000000..4d113ec
> --- /dev/null
> +++ b/drivers/tty/serial/mps2-uart.c
> @@ -0,0 +1,584 @@
> +/*
> + * Copyright (C) 2015 ARM Limited
> + *
> + * Author: Vladimir Murzin <vladimir.murzin at arm.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.
> + *
> + * TODO: support for SysRq
> + */
> +
> +#define pr_fmt(fmt)	KBUILD_MODNAME ": " fmt
> +
> +#include <linux/bitops.h>
> +#include <linux/clk.h>
> +#include <linux/console.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/serial_core.h>
> +#include <linux/tty_flip.h>
> +#include <linux/types.h>
> +
> +#define SERIAL_NAME "ttyS"

You can't be "ttyS", there's already a serial port named that, please
use a unique name and a new major/minor number (dynamic ideally).

thanks,

greg k-h


From gregkh at linuxfoundation.org  Sat Feb  6 23:17:47 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Sat, 6 Feb 2016 23:17:47 -0800
Subject: [PATCH v2 03/12] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <1454524889-9207-4-git-send-email-gregory.clement@free-electrons.com>
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
 <1454524889-9207-4-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160207071747.GA14010@kroah.com>

On Wed, Feb 03, 2016 at 07:41:20PM +0100, Gregory CLEMENT wrote:
> +static struct console mvebu_uart_console = {
> +	.name	= "ttyS",

You aren't ttyS, that's a reserved name for a different chip, please use
a new name and major/minor numbers.

thanks,

greg k-h


From lkp at intel.com  Sun Feb  7 00:40:19 2016
From: lkp at intel.com (kbuild test robot)
Date: Sun, 7 Feb 2016 16:40:19 +0800
Subject: [PATCH v10 8/8] numa, mm, cleanup: remove redundant NODE_DATA
 macro from asm header files.
In-Reply-To: <1454407763-1017-9-git-send-email-gkulkarni@caviumnetworks.com>
Message-ID: <201602071624.1Td35yi4%fengguang.wu@intel.com>

Hi Ganapatrao,

[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.5-rc2 next-20160205]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Ganapatrao-Kulkarni/arm64-numa-adding-numa-support-for-arm64-platforms/20160202-181522
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux for-next/core
config: i386-randconfig-sb0-02030124 (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/gfp.h:5:0,
                    from include/linux/slab.h:14,
                    from include/linux/crypto.h:24,
                    from arch/x86/kernel/asm-offsets.c:8:
   arch/x86/include/asm/mmzone_32.h: In function 'pfn_valid':
>> include/linux/mmzone.h:704:41: error: implicit declaration of function 'NODE_DATA' [-Werror=implicit-function-declaration]
    #define node_end_pfn(nid) pgdat_end_pfn(NODE_DATA(nid))
                                            ^
>> arch/x86/include/asm/mmzone_32.h:42:17: note: in expansion of macro 'node_end_pfn'
      return (pfn < node_end_pfn(nid));
                    ^
>> include/linux/mmzone.h:704:41: warning: passing argument 1 of 'pgdat_end_pfn' makes pointer from integer without a cast [-Wint-conversion]
    #define node_end_pfn(nid) pgdat_end_pfn(NODE_DATA(nid))
                                            ^
>> arch/x86/include/asm/mmzone_32.h:42:17: note: in expansion of macro 'node_end_pfn'
      return (pfn < node_end_pfn(nid));
                    ^
   include/linux/mmzone.h:706:29: note: expected 'pg_data_t * {aka struct pglist_data *}' but argument is of type 'int'
    static inline unsigned long pgdat_end_pfn(pg_data_t *pgdat)
                                ^
   cc1: some warnings being treated as errors
   make[2]: *** [arch/x86/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +/NODE_DATA +704 include/linux/mmzone.h

d41dee369 Andy Whitcroft    2005-06-23  698  #else
d41dee369 Andy Whitcroft    2005-06-23  699  #define pgdat_page_nr(pgdat, pagenr)	pfn_to_page((pgdat)->node_start_pfn + (pagenr))
d41dee369 Andy Whitcroft    2005-06-23  700  #endif
408fde81c Dave Hansen       2005-06-23  701  #define nid_page_nr(nid, pagenr) 	pgdat_page_nr(NODE_DATA(nid),(pagenr))
^1da177e4 Linus Torvalds    2005-04-16  702  
c6830c226 KAMEZAWA Hiroyuki 2011-06-16  703  #define node_start_pfn(nid)	(NODE_DATA(nid)->node_start_pfn)
da3649e13 Cody P Schafer    2013-02-22 @704  #define node_end_pfn(nid) pgdat_end_pfn(NODE_DATA(nid))
c6830c226 KAMEZAWA Hiroyuki 2011-06-16  705  
da3649e13 Cody P Schafer    2013-02-22  706  static inline unsigned long pgdat_end_pfn(pg_data_t *pgdat)
da3649e13 Cody P Schafer    2013-02-22  707  {

:::::: The code at line 704 was first introduced by commit
:::::: da3649e133948d8b7d8c57b05a33faf62ac2cc7e mmzone: add pgdat_{end_pfn,is_empty}() helpers & consolidate.

:::::: TO: Cody P Schafer <cody at linux.vnet.ibm.com>
:::::: CC: Linus Torvalds <torvalds at linux-foundation.org>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 26716 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160207/0fbad0fa/attachment-0001.obj>

From yamada.masahiro at socionext.com  Sun Feb  7 01:56:43 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Sun,  7 Feb 2016 18:56:43 +0900
Subject: [PATCH] ARM: remove 'i' and 'zi' targets
Message-ID: <1454839003-4342-1-git-send-email-yamada.masahiro@socionext.com>

These two were introduced by commit 13d5fadf45d1 ("[ARM] Make 'i' and
'zi' targets work") to short-circuit the dependencies for 'install'
and 'zinstall'.

After that, commit 19514fc665ff ('arm, kbuild: make "make install"
not depend on vmlinux') eventually made "make (z)install" equivalent
to "make (z)i".

It is true that 'i' and 'zi' might be still useful as shorthands
but the original intention had been already lost.

They do not even show up in "make ARCH=arm help", so I hope this
deletion does not have much impact.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/Makefile      | 1 -
 arch/arm/boot/Makefile | 8 --------
 2 files changed, 9 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index cd21135..1e83a45 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -353,7 +353,6 @@ archclean:
 
 # My testing targets (bypasses dependencies)
 bp:;	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/bootpImage
-i zi:;	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
 
 
 define archhelp
diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index ba73a20..48fab15 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -107,12 +107,4 @@ uinstall:
 	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
 	$(obj)/uImage System.map "$(INSTALL_PATH)"
 
-zi:
-	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
-	$(obj)/zImage System.map "$(INSTALL_PATH)"
-
-i:
-	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
-	$(obj)/Image System.map "$(INSTALL_PATH)"
-
 subdir-	    := bootp compressed dts
-- 
1.9.1



From yamada.masahiro at socionext.com  Sun Feb  7 01:59:34 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Sun,  7 Feb 2016 18:59:34 +0900
Subject: [PATCH] ARM: drop redundant "PHONY += FORCE"
Message-ID: <1454839174-5464-1-git-send-email-yamada.masahiro@socionext.com>

"PHONY += FORCE" is already cared by scripts/Makefile.build,
which this file is included from.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index 9eca7ae..ba73a20 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -88,7 +88,7 @@ $(obj)/bootpImage: $(obj)/bootp/bootp FORCE
 	$(call if_changed,objcopy)
 	@$(kecho) '  Kernel: $@ is ready'
 
-PHONY += initrd FORCE
+PHONY += initrd
 initrd:
 	@test "$(INITRD_PHYS)" != "" || \
 	(echo This machine does not support INITRD; exit -1)
-- 
1.9.1



From lkp at intel.com  Sun Feb  7 02:27:19 2016
From: lkp at intel.com (kbuild test robot)
Date: Sun, 7 Feb 2016 18:27:19 +0800
Subject: [PATCH v7 2/4] tee: generic TEE subsystem
In-Reply-To: <1454318140-7962-3-git-send-email-jens.wiklander@linaro.org>
Message-ID: <201602071853.LXR6JlCz%fengguang.wu@intel.com>

Hi Jens,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.5-rc2 next-20160205]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Jens-Wiklander/generic-TEE-subsystem/20160201-172318
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: x86_64-randconfig-x012-02041016 (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `pool_res_mem_destroy':
>> tee_shm_pool.c:(.text+0x2941a6): undefined reference to `gen_pool_destroy'
   tee_shm_pool.c:(.text+0x2941af): undefined reference to `gen_pool_destroy'
   drivers/built-in.o: In function `pool_res_mem_mgr_init':
>> tee_shm_pool.c:(.text+0x29420b): undefined reference to `gen_pool_create'
>> tee_shm_pool.c:(.text+0x294221): undefined reference to `gen_pool_best_fit'
>> tee_shm_pool.c:(.text+0x294229): undefined reference to `gen_pool_set_algo'
>> tee_shm_pool.c:(.text+0x294240): undefined reference to `gen_pool_add_virt'
   tee_shm_pool.c:(.text+0x29424e): undefined reference to `gen_pool_destroy'
   drivers/built-in.o: In function `tee_shm_pool_alloc_res_mem':
>> (.text+0x294303): undefined reference to `gen_pool_destroy'
   drivers/built-in.o: In function `pool_op_gen_free':
>> tee_shm_pool.c:(.text+0x294335): undefined reference to `gen_pool_free'
   drivers/built-in.o: In function `pool_op_gen_alloc':
>> tee_shm_pool.c:(.text+0x294387): undefined reference to `gen_pool_alloc'
>> tee_shm_pool.c:(.text+0x2943a0): undefined reference to `gen_pool_virt_to_phys'

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 23391 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160207/6e29d231/attachment-0001.obj>

From blogic at openwrt.org  Sun Feb  7 02:42:47 2016
From: blogic at openwrt.org (John Crispin)
Date: Sun,  7 Feb 2016 11:42:47 +0100
Subject: [PATCH V5 00/11] soc: mediatek: PMIC wrap: add MT6323/2701/7623
 support
Message-ID: <1454841778-35529-1-git-send-email-blogic@openwrt.org>

This series adds support for a new PMIC (MT6323) and 2 new SoCs
(MT2701/7623) to the pmic-wrap driver.


John Crispin (11):
  dt-bindings: ARM: Mediatek: add MT2701/7623 string to the PMIC
    wrapper doc
  soc: mediatek: PMIC wrap: don't duplicate the wrapper data
  soc: mediatek: PMIC wrap: add wrapper callbacks for init_reg_clock
  soc: mediatek: PMIC wrap: split SoC specific init into callback
  soc: mediatek: PMIC wrap: WRAP_INT_EN needs a different bitmask for
    MT2701/7623
  soc: mediatek: PMIC wrap: SPI_WRITE needs a different bitmask for
    MT2701/7623
  soc: mediatek: PMIC wrap: move wdt_src into the pmic_wrapper_type
    struct
  soc: mediatek: PMIC wrap: remove pwrap_is_mt8135() and
    pwrap_is_mt8173()
  soc: mediatek: PMIC wrap: add a slave specific struct
  soc: mediatek: PMIC wrap: add mt6323 slave support
  soc: mediatek: PMIC wrap: add MT2701/7623 support

 .../devicetree/bindings/soc/mediatek/pwrap.txt     |    1 +
 drivers/soc/mediatek/mtk-pmic-wrap.c               |  554 +++++++++++++++-----
 2 files changed, 424 insertions(+), 131 deletions(-)

-- 
1.7.10.4


From blogic at openwrt.org  Sun Feb  7 02:42:48 2016
From: blogic at openwrt.org (John Crispin)
Date: Sun,  7 Feb 2016 11:42:48 +0100
Subject: [PATCH V5 01/11] dt-bindings: ARM: Mediatek: add MT2701/7623 string
 to the PMIC wrapper doc
In-Reply-To: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
Message-ID: <1454841778-35529-2-git-send-email-blogic@openwrt.org>

Signed-off-by: John Crispin <blogic at openwrt.org>
Acked-by: Rob Herring <robh at kernel.org>
Cc: devicetree at vger.kernel.org
---
 Documentation/devicetree/bindings/soc/mediatek/pwrap.txt |    1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
index ddeb5b6..107700d 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
@@ -18,6 +18,7 @@ IP Pairing
 
 Required properties in pwrap device node.
 - compatible:
+	"mediatek,mt2701-pwrap" for MT2701/7623 SoCs
 	"mediatek,mt8135-pwrap" for MT8135 SoCs
 	"mediatek,mt8173-pwrap" for MT8173 SoCs
 - interrupts: IRQ for pwrap in SOC
-- 
1.7.10.4


From blogic at openwrt.org  Sun Feb  7 02:42:49 2016
From: blogic at openwrt.org (John Crispin)
Date: Sun,  7 Feb 2016 11:42:49 +0100
Subject: [PATCH V5 02/11] soc: mediatek: PMIC wrap: don't duplicate the
 wrapper data
In-Reply-To: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
Message-ID: <1454841778-35529-3-git-send-email-blogic@openwrt.org>

As we add support for more devices struct pmic_wrapper_type will grow and
we do not really want to start duplicating all the elements in
struct pmic_wrapper.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
 drivers/soc/mediatek/mtk-pmic-wrap.c |   22 ++++++++--------------
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 0d9b19a..340c4b5 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -376,9 +376,7 @@ struct pmic_wrapper {
 	struct device *dev;
 	void __iomem *base;
 	struct regmap *regmap;
-	int *regs;
-	enum pwrap_type type;
-	u32 arb_en_all;
+	const struct pmic_wrapper_type *master;
 	struct clk *clk_spi;
 	struct clk *clk_wrap;
 	struct reset_control *rstc;
@@ -389,22 +387,22 @@ struct pmic_wrapper {
 
 static inline int pwrap_is_mt8135(struct pmic_wrapper *wrp)
 {
-	return wrp->type == PWRAP_MT8135;
+	return wrp->master->type == PWRAP_MT8135;
 }
 
 static inline int pwrap_is_mt8173(struct pmic_wrapper *wrp)
 {
-	return wrp->type == PWRAP_MT8173;
+	return wrp->master->type == PWRAP_MT8173;
 }
 
 static u32 pwrap_readl(struct pmic_wrapper *wrp, enum pwrap_regs reg)
 {
-	return readl(wrp->base + wrp->regs[reg]);
+	return readl(wrp->base + wrp->master->regs[reg]);
 }
 
 static void pwrap_writel(struct pmic_wrapper *wrp, u32 val, enum pwrap_regs reg)
 {
-	writel(val, wrp->base + wrp->regs[reg]);
+	writel(val, wrp->base + wrp->master->regs[reg]);
 }
 
 static bool pwrap_is_fsm_idle(struct pmic_wrapper *wrp)
@@ -697,7 +695,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 
 	pwrap_writel(wrp, 1, PWRAP_WRAP_EN);
 
-	pwrap_writel(wrp, wrp->arb_en_all, PWRAP_HIPRIO_ARB_EN);
+	pwrap_writel(wrp, wrp->master->arb_en_all, PWRAP_HIPRIO_ARB_EN);
 
 	pwrap_writel(wrp, 1, PWRAP_WACS2_EN);
 
@@ -742,7 +740,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, 0x1, PWRAP_CRC_EN);
 	pwrap_writel(wrp, 0x0, PWRAP_SIG_MODE);
 	pwrap_writel(wrp, PWRAP_DEW_CRC_VAL, PWRAP_SIG_ADR);
-	pwrap_writel(wrp, wrp->arb_en_all, PWRAP_HIPRIO_ARB_EN);
+	pwrap_writel(wrp, wrp->master->arb_en_all, PWRAP_HIPRIO_ARB_EN);
 
 	if (pwrap_is_mt8135(wrp))
 		pwrap_writel(wrp, 0x7, PWRAP_RRARB_EN);
@@ -836,7 +834,6 @@ static int pwrap_probe(struct platform_device *pdev)
 	struct device_node *np = pdev->dev.of_node;
 	const struct of_device_id *of_id =
 		of_match_device(of_pwrap_match_tbl, &pdev->dev);
-	const struct pmic_wrapper_type *type;
 	struct resource *res;
 
 	wrp = devm_kzalloc(&pdev->dev, sizeof(*wrp), GFP_KERNEL);
@@ -845,10 +842,7 @@ static int pwrap_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, wrp);
 
-	type = of_id->data;
-	wrp->regs = type->regs;
-	wrp->type = type->type;
-	wrp->arb_en_all = type->arb_en_all;
+	wrp->master = of_id->data;
 	wrp->dev = &pdev->dev;
 
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pwrap");
-- 
1.7.10.4


From blogic at openwrt.org  Sun Feb  7 02:42:50 2016
From: blogic at openwrt.org (John Crispin)
Date: Sun,  7 Feb 2016 11:42:50 +0100
Subject: [PATCH V5 03/11] soc: mediatek: PMIC wrap: add wrapper callbacks for
 init_reg_clock
In-Reply-To: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
Message-ID: <1454841778-35529-4-git-send-email-blogic@openwrt.org>

Split init_reg_clock up into SoC specific callbacks. The patch also
reorders the code to avoid the need for callback function prototypes.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
 drivers/soc/mediatek/mtk-pmic-wrap.c |   70 ++++++++++++++++++----------------
 1 file changed, 38 insertions(+), 32 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 340c4b5..b22b664 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -354,24 +354,6 @@ enum pwrap_type {
 	PWRAP_MT8173,
 };
 
-struct pmic_wrapper_type {
-	int *regs;
-	enum pwrap_type type;
-	u32 arb_en_all;
-};
-
-static struct pmic_wrapper_type pwrap_mt8135 = {
-	.regs = mt8135_regs,
-	.type = PWRAP_MT8135,
-	.arb_en_all = 0x1ff,
-};
-
-static struct pmic_wrapper_type pwrap_mt8173 = {
-	.regs = mt8173_regs,
-	.type = PWRAP_MT8173,
-	.arb_en_all = 0x3f,
-};
-
 struct pmic_wrapper {
 	struct device *dev;
 	void __iomem *base;
@@ -385,6 +367,13 @@ struct pmic_wrapper {
 	void __iomem *bridge_base;
 };
 
+struct pmic_wrapper_type {
+	int *regs;
+	enum pwrap_type type;
+	u32 arb_en_all;
+	int (*init_reg_clock)(struct pmic_wrapper *wrp);
+};
+
 static inline int pwrap_is_mt8135(struct pmic_wrapper *wrp)
 {
 	return wrp->master->type == PWRAP_MT8135;
@@ -578,20 +567,23 @@ static int pwrap_init_sidly(struct pmic_wrapper *wrp)
 	return 0;
 }
 
-static int pwrap_init_reg_clock(struct pmic_wrapper *wrp)
+static int pwrap_mt8135_init_reg_clock(struct pmic_wrapper *wrp)
 {
-	if (pwrap_is_mt8135(wrp)) {
-		pwrap_writel(wrp, 0x4, PWRAP_CSHEXT);
-		pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_WRITE);
-		pwrap_writel(wrp, 0x4, PWRAP_CSHEXT_READ);
-		pwrap_writel(wrp, 0x0, PWRAP_CSLEXT_START);
-		pwrap_writel(wrp, 0x0, PWRAP_CSLEXT_END);
-	} else {
-		pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_WRITE);
-		pwrap_writel(wrp, 0x4, PWRAP_CSHEXT_READ);
-		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_START);
-		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_END);
-	}
+	pwrap_writel(wrp, 0x4, PWRAP_CSHEXT);
+	pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_WRITE);
+	pwrap_writel(wrp, 0x4, PWRAP_CSHEXT_READ);
+	pwrap_writel(wrp, 0x0, PWRAP_CSLEXT_START);
+	pwrap_writel(wrp, 0x0, PWRAP_CSLEXT_END);
+
+	return 0;
+}
+
+static int pwrap_mt8173_init_reg_clock(struct pmic_wrapper *wrp)
+{
+	pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_WRITE);
+	pwrap_writel(wrp, 0x4, PWRAP_CSHEXT_READ);
+	pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_START);
+	pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_END);
 
 	return 0;
 }
@@ -699,7 +691,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 
 	pwrap_writel(wrp, 1, PWRAP_WACS2_EN);
 
-	ret = pwrap_init_reg_clock(wrp);
+	ret = wrp->master->init_reg_clock(wrp);
 	if (ret)
 		return ret;
 
@@ -814,6 +806,20 @@ static const struct regmap_config pwrap_regmap_config = {
 	.max_register = 0xffff,
 };
 
+static struct pmic_wrapper_type pwrap_mt8135 = {
+	.regs = mt8135_regs,
+	.type = PWRAP_MT8135,
+	.arb_en_all = 0x1ff,
+	.init_reg_clock = pwrap_mt8135_init_reg_clock,
+};
+
+static struct pmic_wrapper_type pwrap_mt8173 = {
+	.regs = mt8173_regs,
+	.type = PWRAP_MT8173,
+	.arb_en_all = 0x3f,
+	.init_reg_clock = pwrap_mt8173_init_reg_clock,
+};
+
 static struct of_device_id of_pwrap_match_tbl[] = {
 	{
 		.compatible = "mediatek,mt8135-pwrap",
-- 
1.7.10.4


From blogic at openwrt.org  Sun Feb  7 02:42:51 2016
From: blogic at openwrt.org (John Crispin)
Date: Sun,  7 Feb 2016 11:42:51 +0100
Subject: [PATCH V5 04/11] soc: mediatek: PMIC wrap: split SoC specific init
 into callback
In-Reply-To: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
Message-ID: <1454841778-35529-5-git-send-email-blogic@openwrt.org>

This patch moves the SoC specific wrapper init code into separate callback
to avoid pwrap_init() getting too large.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
Changes in V5
* only check the return code of init_special() if the function is
  actually called

 drivers/soc/mediatek/mtk-pmic-wrap.c |   67 +++++++++++++++++++++-------------
 1 file changed, 42 insertions(+), 25 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index b22b664..e3bbee5 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -372,6 +372,7 @@ struct pmic_wrapper_type {
 	enum pwrap_type type;
 	u32 arb_en_all;
 	int (*init_reg_clock)(struct pmic_wrapper *wrp);
+	int (*init_special)(struct pmic_wrapper *wrp);
 };
 
 static inline int pwrap_is_mt8135(struct pmic_wrapper *wrp)
@@ -665,6 +666,41 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
 	return 0;
 }
 
+static int pwrap_mt8135_init_special(struct pmic_wrapper *wrp)
+{
+	/* enable pwrap events and pwrap bridge in AP side */
+	pwrap_writel(wrp, 0x1, PWRAP_EVENT_IN_EN);
+	pwrap_writel(wrp, 0xffff, PWRAP_EVENT_DST_EN);
+	writel(0x7f, wrp->bridge_base + PWRAP_MT8135_BRIDGE_IORD_ARB_EN);
+	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS3_EN);
+	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS4_EN);
+	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_UNIT);
+	writel(0xffff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_SRC_EN);
+	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_TIMER_EN);
+	writel(0x7ff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INT_EN);
+
+	/* enable PMIC event out and sources */
+	if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
+		pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
+		dev_err(wrp->dev, "enable dewrap fail\n");
+		return -EFAULT;
+	}
+
+	return 0;
+}
+
+static int pwrap_mt8173_init_special(struct pmic_wrapper *wrp)
+{
+	/* PMIC_DEWRAP enables */
+	if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
+		pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
+		dev_err(wrp->dev, "enable dewrap fail\n");
+		return -EFAULT;
+	}
+
+	return 0;
+}
+
 static int pwrap_init(struct pmic_wrapper *wrp)
 {
 	int ret;
@@ -743,31 +779,10 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, 0x5, PWRAP_STAUPD_PRD);
 	pwrap_writel(wrp, 0xff, PWRAP_STAUPD_GRPEN);
 
-	if (pwrap_is_mt8135(wrp)) {
-		/* enable pwrap events and pwrap bridge in AP side */
-		pwrap_writel(wrp, 0x1, PWRAP_EVENT_IN_EN);
-		pwrap_writel(wrp, 0xffff, PWRAP_EVENT_DST_EN);
-		writel(0x7f, wrp->bridge_base + PWRAP_MT8135_BRIDGE_IORD_ARB_EN);
-		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS3_EN);
-		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS4_EN);
-		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_UNIT);
-		writel(0xffff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_SRC_EN);
-		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_TIMER_EN);
-		writel(0x7ff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INT_EN);
-
-		/* enable PMIC event out and sources */
-		if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
-				pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
-			dev_err(wrp->dev, "enable dewrap fail\n");
-			return -EFAULT;
-		}
-	} else {
-		/* PMIC_DEWRAP enables */
-		if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
-				pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
-			dev_err(wrp->dev, "enable dewrap fail\n");
-			return -EFAULT;
-		}
+	if (wrp->master->init_special) {
+		ret = wrp->master->init_special(wrp);
+		if (ret)
+			return ret;
 	}
 
 	/* Setup the init done registers */
@@ -811,6 +826,7 @@ static struct pmic_wrapper_type pwrap_mt8135 = {
 	.type = PWRAP_MT8135,
 	.arb_en_all = 0x1ff,
 	.init_reg_clock = pwrap_mt8135_init_reg_clock,
+	.init_special = pwrap_mt8135_init_special,
 };
 
 static struct pmic_wrapper_type pwrap_mt8173 = {
@@ -818,6 +834,7 @@ static struct pmic_wrapper_type pwrap_mt8173 = {
 	.type = PWRAP_MT8173,
 	.arb_en_all = 0x3f,
 	.init_reg_clock = pwrap_mt8173_init_reg_clock,
+	.init_special = pwrap_mt8173_init_special,
 };
 
 static struct of_device_id of_pwrap_match_tbl[] = {
-- 
1.7.10.4


From blogic at openwrt.org  Sun Feb  7 02:42:54 2016
From: blogic at openwrt.org (John Crispin)
Date: Sun,  7 Feb 2016 11:42:54 +0100
Subject: [PATCH V5 07/11] soc: mediatek: PMIC wrap: move wdt_src into the
 pmic_wrapper_type struct
In-Reply-To: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
Message-ID: <1454841778-35529-8-git-send-email-blogic@openwrt.org>

Make the handling of wdt_src consitent with the rest of the code.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
 drivers/soc/mediatek/mtk-pmic-wrap.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 1653e64..7193d04 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -373,6 +373,7 @@ struct pmic_wrapper_type {
 	u32 arb_en_all;
 	u32 int_en_all;
 	u32 spi_w;
+	u32 wdt_src;
 	int (*init_reg_clock)(struct pmic_wrapper *wrp);
 	int (*init_special)(struct pmic_wrapper *wrp);
 };
@@ -829,6 +830,7 @@ static struct pmic_wrapper_type pwrap_mt8135 = {
 	.arb_en_all = 0x1ff,
 	.int_en_all = ~(BIT(31) | BIT(1)),
 	.spi_w = PWRAP_MAN_CMD_SPI_WRITE,
+	.wdt_src = PWRAP_WDT_SRC_MASK_ALL,
 	.init_reg_clock = pwrap_mt8135_init_reg_clock,
 	.init_special = pwrap_mt8135_init_special,
 };
@@ -839,6 +841,7 @@ static struct pmic_wrapper_type pwrap_mt8173 = {
 	.arb_en_all = 0x3f,
 	.int_en_all = ~(BIT(31) | BIT(1)),
 	.spi_w = PWRAP_MAN_CMD_SPI_WRITE,
+	.wdt_src = PWRAP_WDT_SRC_MASK_NO_STAUPD,
 	.init_reg_clock = pwrap_mt8173_init_reg_clock,
 	.init_special = pwrap_mt8173_init_special,
 };
@@ -858,7 +861,7 @@ MODULE_DEVICE_TABLE(of, of_pwrap_match_tbl);
 
 static int pwrap_probe(struct platform_device *pdev)
 {
-	int ret, irq, wdt_src;
+	int ret, irq;
 	struct pmic_wrapper *wrp;
 	struct device_node *np = pdev->dev.of_node;
 	const struct of_device_id *of_id =
@@ -948,9 +951,7 @@ static int pwrap_probe(struct platform_device *pdev)
 	 * Since STAUPD was not used on mt8173 platform,
 	 * so STAUPD of WDT_SRC which should be turned off
 	 */
-	wdt_src = pwrap_is_mt8173(wrp) ?
-			PWRAP_WDT_SRC_MASK_NO_STAUPD : PWRAP_WDT_SRC_MASK_ALL;
-	pwrap_writel(wrp, wdt_src, PWRAP_WDT_SRC_EN);
+	pwrap_writel(wrp, wrp->master->wdt_src, PWRAP_WDT_SRC_EN);
 	pwrap_writel(wrp, 0x1, PWRAP_TIMER_EN);
 	pwrap_writel(wrp, wrp->master->int_en_all, PWRAP_INT_EN);
 
-- 
1.7.10.4


From blogic at openwrt.org  Sun Feb  7 02:42:56 2016
From: blogic at openwrt.org (John Crispin)
Date: Sun,  7 Feb 2016 11:42:56 +0100
Subject: [PATCH V5 09/11] soc: mediatek: PMIC wrap: add a slave specific struct
In-Reply-To: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
Message-ID: <1454841778-35529-10-git-send-email-blogic@openwrt.org>

This patch adds a new struct pwrap_slv_type that we use to store the slave
specific data. The patch adds 2 new helper functions to access the dew
registers. The slave type is looked up via the wrappers child node.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
Changes in V5
* drop the dew i/o wrappers

Changed in V4
* drop unused MT8173 specifc variable declarations

 drivers/soc/mediatek/mtk-pmic-wrap.c |  157 ++++++++++++++++++++++++----------
 1 file changed, 110 insertions(+), 47 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index fbf94e4..2628271 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -69,33 +69,52 @@
 					  PWRAP_WDT_SRC_EN_HARB_STAUPD_DLE | \
 					  PWRAP_WDT_SRC_EN_HARB_STAUPD_ALE)
 
-/* macro for slave device wrapper registers */
-#define PWRAP_DEW_BASE			0xbc00
-#define PWRAP_DEW_EVENT_OUT_EN		(PWRAP_DEW_BASE + 0x0)
-#define PWRAP_DEW_DIO_EN		(PWRAP_DEW_BASE + 0x2)
-#define PWRAP_DEW_EVENT_SRC_EN		(PWRAP_DEW_BASE + 0x4)
-#define PWRAP_DEW_EVENT_SRC		(PWRAP_DEW_BASE + 0x6)
-#define PWRAP_DEW_EVENT_FLAG		(PWRAP_DEW_BASE + 0x8)
-#define PWRAP_DEW_READ_TEST		(PWRAP_DEW_BASE + 0xa)
-#define PWRAP_DEW_WRITE_TEST		(PWRAP_DEW_BASE + 0xc)
-#define PWRAP_DEW_CRC_EN		(PWRAP_DEW_BASE + 0xe)
-#define PWRAP_DEW_CRC_VAL		(PWRAP_DEW_BASE + 0x10)
-#define PWRAP_DEW_MON_GRP_SEL		(PWRAP_DEW_BASE + 0x12)
-#define PWRAP_DEW_MON_FLAG_SEL		(PWRAP_DEW_BASE + 0x14)
-#define PWRAP_DEW_EVENT_TEST		(PWRAP_DEW_BASE + 0x16)
-#define PWRAP_DEW_CIPHER_KEY_SEL	(PWRAP_DEW_BASE + 0x18)
-#define PWRAP_DEW_CIPHER_IV_SEL		(PWRAP_DEW_BASE + 0x1a)
-#define PWRAP_DEW_CIPHER_LOAD		(PWRAP_DEW_BASE + 0x1c)
-#define PWRAP_DEW_CIPHER_START		(PWRAP_DEW_BASE + 0x1e)
-#define PWRAP_DEW_CIPHER_RDY		(PWRAP_DEW_BASE + 0x20)
-#define PWRAP_DEW_CIPHER_MODE		(PWRAP_DEW_BASE + 0x22)
-#define PWRAP_DEW_CIPHER_SWRST		(PWRAP_DEW_BASE + 0x24)
-#define PWRAP_MT8173_DEW_CIPHER_IV0	(PWRAP_DEW_BASE + 0x26)
-#define PWRAP_MT8173_DEW_CIPHER_IV1	(PWRAP_DEW_BASE + 0x28)
-#define PWRAP_MT8173_DEW_CIPHER_IV2	(PWRAP_DEW_BASE + 0x2a)
-#define PWRAP_MT8173_DEW_CIPHER_IV3	(PWRAP_DEW_BASE + 0x2c)
-#define PWRAP_MT8173_DEW_CIPHER_IV4	(PWRAP_DEW_BASE + 0x2e)
-#define PWRAP_MT8173_DEW_CIPHER_IV5	(PWRAP_DEW_BASE + 0x30)
+/* defines for slave device wrapper registers */
+enum dew_regs {
+	PWRAP_DEW_BASE,
+	PWRAP_DEW_EVENT_OUT_EN,
+	PWRAP_DEW_DIO_EN,
+	PWRAP_DEW_EVENT_SRC_EN,
+	PWRAP_DEW_EVENT_SRC,
+	PWRAP_DEW_EVENT_FLAG,
+	PWRAP_DEW_READ_TEST,
+	PWRAP_DEW_WRITE_TEST,
+	PWRAP_DEW_CRC_EN,
+	PWRAP_DEW_CRC_VAL,
+	PWRAP_DEW_MON_GRP_SEL,
+	PWRAP_DEW_MON_FLAG_SEL,
+	PWRAP_DEW_EVENT_TEST,
+	PWRAP_DEW_CIPHER_KEY_SEL,
+	PWRAP_DEW_CIPHER_IV_SEL,
+	PWRAP_DEW_CIPHER_LOAD,
+	PWRAP_DEW_CIPHER_START,
+	PWRAP_DEW_CIPHER_RDY,
+	PWRAP_DEW_CIPHER_MODE,
+	PWRAP_DEW_CIPHER_SWRST,
+};
+
+static const u32 mt6397_regs[] = {
+	[PWRAP_DEW_BASE] =		0xbc00,
+	[PWRAP_DEW_EVENT_OUT_EN] =	0xbc00,
+	[PWRAP_DEW_DIO_EN] =		0xbc02,
+	[PWRAP_DEW_EVENT_SRC_EN] =	0xbc04,
+	[PWRAP_DEW_EVENT_SRC] =		0xbc06,
+	[PWRAP_DEW_EVENT_FLAG] =	0xbc08,
+	[PWRAP_DEW_READ_TEST] =		0xbc0a,
+	[PWRAP_DEW_WRITE_TEST] =	0xbc0c,
+	[PWRAP_DEW_CRC_EN] =		0xbc0e,
+	[PWRAP_DEW_CRC_VAL] =		0xbc10,
+	[PWRAP_DEW_MON_GRP_SEL] =	0xbc12,
+	[PWRAP_DEW_MON_FLAG_SEL] =	0xbc14,
+	[PWRAP_DEW_EVENT_TEST] =	0xbc16,
+	[PWRAP_DEW_CIPHER_KEY_SEL] =	0xbc18,
+	[PWRAP_DEW_CIPHER_IV_SEL] =	0xbc1a,
+	[PWRAP_DEW_CIPHER_LOAD] =	0xbc1c,
+	[PWRAP_DEW_CIPHER_START] =	0xbc1e,
+	[PWRAP_DEW_CIPHER_RDY] =	0xbc20,
+	[PWRAP_DEW_CIPHER_MODE] =	0xbc22,
+	[PWRAP_DEW_CIPHER_SWRST] =	0xbc24,
+};
 
 enum pwrap_regs {
 	PWRAP_MUX_SEL,
@@ -349,16 +368,26 @@ static int mt8135_regs[] = {
 	[PWRAP_DCM_DBC_PRD] =		0x160,
 };
 
+enum pmic_type {
+	PMIC_MT6397,
+};
+
 enum pwrap_type {
 	PWRAP_MT8135,
 	PWRAP_MT8173,
 };
 
+struct pwrap_slv_type {
+	const u32 *dew_regs;
+	enum pmic_type type;
+};
+
 struct pmic_wrapper {
 	struct device *dev;
 	void __iomem *base;
 	struct regmap *regmap;
 	const struct pmic_wrapper_type *master;
+	const struct pwrap_slv_type *slave;
 	struct clk *clk_spi;
 	struct clk *clk_wrap;
 	struct reset_control *rstc;
@@ -544,7 +573,8 @@ static int pwrap_init_sidly(struct pmic_wrapper *wrp)
 
 	for (i = 0; i < 4; i++) {
 		pwrap_writel(wrp, i, PWRAP_SIDLY);
-		pwrap_read(wrp, PWRAP_DEW_READ_TEST, &rdata);
+		pwrap_read(wrp, wrp->slave->dew_regs[PWRAP_DEW_READ_TEST],
+			   &rdata);
 		if (rdata == PWRAP_DEW_READ_TEST_VAL) {
 			dev_dbg(wrp->dev, "[Read Test] pass, SIDLY=%x\n", i);
 			pass |= 1 << i;
@@ -593,7 +623,8 @@ static bool pwrap_is_pmic_cipher_ready(struct pmic_wrapper *wrp)
 	u32 rdata;
 	int ret;
 
-	ret = pwrap_read(wrp, PWRAP_DEW_CIPHER_RDY, &rdata);
+	ret = pwrap_read(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_RDY],
+			 &rdata);
 	if (ret)
 		return 0;
 
@@ -621,12 +652,12 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
 	}
 
 	/* Config cipher mode @PMIC */
-	pwrap_write(wrp, PWRAP_DEW_CIPHER_SWRST, 0x1);
-	pwrap_write(wrp, PWRAP_DEW_CIPHER_SWRST, 0x0);
-	pwrap_write(wrp, PWRAP_DEW_CIPHER_KEY_SEL, 0x1);
-	pwrap_write(wrp, PWRAP_DEW_CIPHER_IV_SEL, 0x2);
-	pwrap_write(wrp, PWRAP_DEW_CIPHER_LOAD, 0x1);
-	pwrap_write(wrp, PWRAP_DEW_CIPHER_START, 0x1);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_SWRST], 0x1);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_SWRST], 0x0);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_KEY_SEL], 0x1);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_IV_SEL], 0x2);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_LOAD], 0x1);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_START], 0x1);
 
 	/* wait for cipher data ready at AP */
 	ret = pwrap_wait_for_state(wrp, pwrap_is_cipher_ready);
@@ -643,7 +674,7 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
 	}
 
 	/* wait for cipher mode idle */
-	pwrap_write(wrp, PWRAP_DEW_CIPHER_MODE, 0x1);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_MODE], 0x1);
 	ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle_and_sync_idle);
 	if (ret) {
 		dev_err(wrp->dev, "cipher mode idle fail, ret=%d\n", ret);
@@ -653,9 +684,11 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, 1, PWRAP_CIPHER_MODE);
 
 	/* Write Test */
-	if (pwrap_write(wrp, PWRAP_DEW_WRITE_TEST, PWRAP_DEW_WRITE_TEST_VAL) ||
-	    pwrap_read(wrp, PWRAP_DEW_WRITE_TEST, &rdata) ||
-			(rdata != PWRAP_DEW_WRITE_TEST_VAL)) {
+	if (pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_WRITE_TEST],
+			PWRAP_DEW_WRITE_TEST_VAL) ||
+	    pwrap_read(wrp, wrp->slave->dew_regs[PWRAP_DEW_WRITE_TEST],
+		       &rdata) ||
+	    (rdata != PWRAP_DEW_WRITE_TEST_VAL)) {
 		dev_err(wrp->dev, "rdata=0x%04X\n", rdata);
 		return -EFAULT;
 	}
@@ -677,8 +710,10 @@ static int pwrap_mt8135_init_special(struct pmic_wrapper *wrp)
 	writel(0x7ff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INT_EN);
 
 	/* enable PMIC event out and sources */
-	if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
-		pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
+	if (pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_EVENT_OUT_EN],
+			0x1) ||
+	    pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_EVENT_SRC_EN],
+			0xffff)) {
 		dev_err(wrp->dev, "enable dewrap fail\n");
 		return -EFAULT;
 	}
@@ -689,8 +724,10 @@ static int pwrap_mt8135_init_special(struct pmic_wrapper *wrp)
 static int pwrap_mt8173_init_special(struct pmic_wrapper *wrp)
 {
 	/* PMIC_DEWRAP enables */
-	if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
-		pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
+	if (pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_EVENT_OUT_EN],
+			0x1) ||
+	    pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_EVENT_SRC_EN],
+			0xffff)) {
 		dev_err(wrp->dev, "enable dewrap fail\n");
 		return -EFAULT;
 	}
@@ -734,7 +771,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 		return ret;
 
 	/* Enable dual IO mode */
-	pwrap_write(wrp, PWRAP_DEW_DIO_EN, 1);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_DIO_EN], 1);
 
 	/* Check IDLE & INIT_DONE in advance */
 	ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle_and_sync_idle);
@@ -746,7 +783,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, 1, PWRAP_DIO_EN);
 
 	/* Read Test */
-	pwrap_read(wrp, PWRAP_DEW_READ_TEST, &rdata);
+	pwrap_read(wrp, wrp->slave->dew_regs[PWRAP_DEW_READ_TEST], &rdata);
 	if (rdata != PWRAP_DEW_READ_TEST_VAL) {
 		dev_err(wrp->dev, "Read test failed after switch to DIO mode: 0x%04x != 0x%04x\n",
 				PWRAP_DEW_READ_TEST_VAL, rdata);
@@ -759,12 +796,13 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 		return ret;
 
 	/* Signature checking - using CRC */
-	if (pwrap_write(wrp, PWRAP_DEW_CRC_EN, 0x1))
+	if (pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CRC_EN], 0x1))
 		return -EFAULT;
 
 	pwrap_writel(wrp, 0x1, PWRAP_CRC_EN);
 	pwrap_writel(wrp, 0x0, PWRAP_SIG_MODE);
-	pwrap_writel(wrp, PWRAP_DEW_CRC_VAL, PWRAP_SIG_ADR);
+	pwrap_writel(wrp, wrp->slave->dew_regs[PWRAP_DEW_CRC_VAL],
+		     PWRAP_SIG_ADR);
 	pwrap_writel(wrp, wrp->master->arb_en_all, PWRAP_HIPRIO_ARB_EN);
 
 	if (wrp->master->type == PWRAP_MT8135)
@@ -818,6 +856,21 @@ static const struct regmap_config pwrap_regmap_config = {
 	.max_register = 0xffff,
 };
 
+static const struct pwrap_slv_type pmic_mt6397 = {
+	.dew_regs = mt6397_regs,
+	.type = PMIC_MT6397,
+};
+
+static const struct of_device_id of_slave_match_tbl[] = {
+	{
+		.compatible = "mediatek,mt6397",
+		.data = &pmic_mt6397,
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, of_slave_match_tbl);
+
 static struct pmic_wrapper_type pwrap_mt8135 = {
 	.regs = mt8135_regs,
 	.type = PWRAP_MT8135,
@@ -862,8 +915,17 @@ static int pwrap_probe(struct platform_device *pdev)
 	struct device_node *np = pdev->dev.of_node;
 	const struct of_device_id *of_id =
 		of_match_device(of_pwrap_match_tbl, &pdev->dev);
+	const struct of_device_id *of_slave_id = NULL;
 	struct resource *res;
 
+	if (pdev->dev.of_node->child)
+		of_slave_id = of_match_node(of_slave_match_tbl,
+					    pdev->dev.of_node->child);
+	if (!of_slave_id) {
+		dev_dbg(&pdev->dev, "slave pmic should be defined in dts\n");
+		return -EINVAL;
+	}
+
 	wrp = devm_kzalloc(&pdev->dev, sizeof(*wrp), GFP_KERNEL);
 	if (!wrp)
 		return -ENOMEM;
@@ -871,6 +933,7 @@ static int pwrap_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, wrp);
 
 	wrp->master = of_id->data;
+	wrp->slave = of_slave_id->data;
 	wrp->dev = &pdev->dev;
 
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pwrap");
-- 
1.7.10.4


From blogic at openwrt.org  Sun Feb  7 02:42:53 2016
From: blogic at openwrt.org (John Crispin)
Date: Sun,  7 Feb 2016 11:42:53 +0100
Subject: [PATCH V5 06/11] soc: mediatek: PMIC wrap: SPI_WRITE needs a
 different bitmask for MT2701/7623
In-Reply-To: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
Message-ID: <1454841778-35529-7-git-send-email-blogic@openwrt.org>

MT2701 and MT7623 use a different bitmask for the SPI_WRITE command.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
Changes in V4
* fix typo in the subject

 drivers/soc/mediatek/mtk-pmic-wrap.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 2fd795f..1653e64 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -372,6 +372,7 @@ struct pmic_wrapper_type {
 	enum pwrap_type type;
 	u32 arb_en_all;
 	u32 int_en_all;
+	u32 spi_w;
 	int (*init_reg_clock)(struct pmic_wrapper *wrp);
 	int (*init_special)(struct pmic_wrapper *wrp);
 };
@@ -511,15 +512,15 @@ static int pwrap_reset_spislave(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, 1, PWRAP_MAN_EN);
 	pwrap_writel(wrp, 0, PWRAP_DIO_EN);
 
-	pwrap_writel(wrp, PWRAP_MAN_CMD_SPI_WRITE | PWRAP_MAN_CMD_OP_CSL,
+	pwrap_writel(wrp, wrp->master->spi_w | PWRAP_MAN_CMD_OP_CSL,
 			PWRAP_MAN_CMD);
-	pwrap_writel(wrp, PWRAP_MAN_CMD_SPI_WRITE | PWRAP_MAN_CMD_OP_OUTS,
+	pwrap_writel(wrp, wrp->master->spi_w | PWRAP_MAN_CMD_OP_OUTS,
 			PWRAP_MAN_CMD);
-	pwrap_writel(wrp, PWRAP_MAN_CMD_SPI_WRITE | PWRAP_MAN_CMD_OP_CSH,
+	pwrap_writel(wrp, wrp->master->spi_w | PWRAP_MAN_CMD_OP_CSH,
 			PWRAP_MAN_CMD);
 
 	for (i = 0; i < 4; i++)
-		pwrap_writel(wrp, PWRAP_MAN_CMD_SPI_WRITE | PWRAP_MAN_CMD_OP_OUTS,
+		pwrap_writel(wrp, wrp->master->spi_w | PWRAP_MAN_CMD_OP_OUTS,
 				PWRAP_MAN_CMD);
 
 	ret = pwrap_wait_for_state(wrp, pwrap_is_sync_idle);
@@ -827,6 +828,7 @@ static struct pmic_wrapper_type pwrap_mt8135 = {
 	.type = PWRAP_MT8135,
 	.arb_en_all = 0x1ff,
 	.int_en_all = ~(BIT(31) | BIT(1)),
+	.spi_w = PWRAP_MAN_CMD_SPI_WRITE,
 	.init_reg_clock = pwrap_mt8135_init_reg_clock,
 	.init_special = pwrap_mt8135_init_special,
 };
@@ -836,6 +838,7 @@ static struct pmic_wrapper_type pwrap_mt8173 = {
 	.type = PWRAP_MT8173,
 	.arb_en_all = 0x3f,
 	.int_en_all = ~(BIT(31) | BIT(1)),
+	.spi_w = PWRAP_MAN_CMD_SPI_WRITE,
 	.init_reg_clock = pwrap_mt8173_init_reg_clock,
 	.init_special = pwrap_mt8173_init_special,
 };
-- 
1.7.10.4


From blogic at openwrt.org  Sun Feb  7 02:42:52 2016
From: blogic at openwrt.org (John Crispin)
Date: Sun,  7 Feb 2016 11:42:52 +0100
Subject: [PATCH V5 05/11] soc: mediatek: PMIC wrap: WRAP_INT_EN needs a
 different bitmask for MT2701/7623
In-Reply-To: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
Message-ID: <1454841778-35529-6-git-send-email-blogic@openwrt.org>

MT2701 and MT7623 use a different bitmask for PWRAP_INT_EN.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
Changes in V5
* move the logic invert from call to declaration

 drivers/soc/mediatek/mtk-pmic-wrap.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index e3bbee5..2fd795f 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -371,6 +371,7 @@ struct pmic_wrapper_type {
 	int *regs;
 	enum pwrap_type type;
 	u32 arb_en_all;
+	u32 int_en_all;
 	int (*init_reg_clock)(struct pmic_wrapper *wrp);
 	int (*init_special)(struct pmic_wrapper *wrp);
 };
@@ -825,6 +826,7 @@ static struct pmic_wrapper_type pwrap_mt8135 = {
 	.regs = mt8135_regs,
 	.type = PWRAP_MT8135,
 	.arb_en_all = 0x1ff,
+	.int_en_all = ~(BIT(31) | BIT(1)),
 	.init_reg_clock = pwrap_mt8135_init_reg_clock,
 	.init_special = pwrap_mt8135_init_special,
 };
@@ -833,6 +835,7 @@ static struct pmic_wrapper_type pwrap_mt8173 = {
 	.regs = mt8173_regs,
 	.type = PWRAP_MT8173,
 	.arb_en_all = 0x3f,
+	.int_en_all = ~(BIT(31) | BIT(1)),
 	.init_reg_clock = pwrap_mt8173_init_reg_clock,
 	.init_special = pwrap_mt8173_init_special,
 };
@@ -946,7 +949,7 @@ static int pwrap_probe(struct platform_device *pdev)
 			PWRAP_WDT_SRC_MASK_NO_STAUPD : PWRAP_WDT_SRC_MASK_ALL;
 	pwrap_writel(wrp, wdt_src, PWRAP_WDT_SRC_EN);
 	pwrap_writel(wrp, 0x1, PWRAP_TIMER_EN);
-	pwrap_writel(wrp, ~((1 << 31) | (1 << 1)), PWRAP_INT_EN);
+	pwrap_writel(wrp, wrp->master->int_en_all, PWRAP_INT_EN);
 
 	irq = platform_get_irq(pdev, 0);
 	ret = devm_request_irq(wrp->dev, irq, pwrap_interrupt, IRQF_TRIGGER_HIGH,
-- 
1.7.10.4


From blogic at openwrt.org  Sun Feb  7 02:42:55 2016
From: blogic at openwrt.org (John Crispin)
Date: Sun,  7 Feb 2016 11:42:55 +0100
Subject: [PATCH V5 08/11] soc: mediatek: PMIC wrap: remove pwrap_is_mt8135()
 and pwrap_is_mt8173()
In-Reply-To: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
Message-ID: <1454841778-35529-9-git-send-email-blogic@openwrt.org>

With more SoCs being added the list of helper functions like these would
grow. While at it also add a new flag "has_bridge" and use that instead of
pwrap_is_mt8173() where appropriate.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
Changed in V4
* fix 2 typos in the description
* used a bitfiled for the new has_bridge flag

 drivers/soc/mediatek/mtk-pmic-wrap.c |   28 ++++++++++++----------------
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 7193d04..fbf94e4 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -374,20 +374,11 @@ struct pmic_wrapper_type {
 	u32 int_en_all;
 	u32 spi_w;
 	u32 wdt_src;
+	int has_bridge:1;
 	int (*init_reg_clock)(struct pmic_wrapper *wrp);
 	int (*init_special)(struct pmic_wrapper *wrp);
 };
 
-static inline int pwrap_is_mt8135(struct pmic_wrapper *wrp)
-{
-	return wrp->master->type == PWRAP_MT8135;
-}
-
-static inline int pwrap_is_mt8173(struct pmic_wrapper *wrp)
-{
-	return wrp->master->type == PWRAP_MT8173;
-}
-
 static u32 pwrap_readl(struct pmic_wrapper *wrp, enum pwrap_regs reg)
 {
 	return readl(wrp->base + wrp->master->regs[reg]);
@@ -619,11 +610,14 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, 0x1, PWRAP_CIPHER_KEY_SEL);
 	pwrap_writel(wrp, 0x2, PWRAP_CIPHER_IV_SEL);
 
-	if (pwrap_is_mt8135(wrp)) {
+	switch (wrp->master->type) {
+	case PWRAP_MT8135:
 		pwrap_writel(wrp, 1, PWRAP_CIPHER_LOAD);
 		pwrap_writel(wrp, 1, PWRAP_CIPHER_START);
-	} else {
+		break;
+	case PWRAP_MT8173:
 		pwrap_writel(wrp, 1, PWRAP_CIPHER_EN);
+		break;
 	}
 
 	/* Config cipher mode @PMIC */
@@ -713,7 +707,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 	if (wrp->rstc_bridge)
 		reset_control_reset(wrp->rstc_bridge);
 
-	if (pwrap_is_mt8173(wrp)) {
+	if (wrp->master->type == PWRAP_MT8173) {
 		/* Enable DCM */
 		pwrap_writel(wrp, 3, PWRAP_DCM_EN);
 		pwrap_writel(wrp, 0, PWRAP_DCM_DBC_PRD);
@@ -773,7 +767,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, PWRAP_DEW_CRC_VAL, PWRAP_SIG_ADR);
 	pwrap_writel(wrp, wrp->master->arb_en_all, PWRAP_HIPRIO_ARB_EN);
 
-	if (pwrap_is_mt8135(wrp))
+	if (wrp->master->type == PWRAP_MT8135)
 		pwrap_writel(wrp, 0x7, PWRAP_RRARB_EN);
 
 	pwrap_writel(wrp, 0x1, PWRAP_WACS0_EN);
@@ -793,7 +787,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, 1, PWRAP_INIT_DONE0);
 	pwrap_writel(wrp, 1, PWRAP_INIT_DONE1);
 
-	if (pwrap_is_mt8135(wrp)) {
+	if (wrp->master->has_bridge) {
 		writel(1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INIT_DONE3);
 		writel(1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INIT_DONE4);
 	}
@@ -831,6 +825,7 @@ static struct pmic_wrapper_type pwrap_mt8135 = {
 	.int_en_all = ~(BIT(31) | BIT(1)),
 	.spi_w = PWRAP_MAN_CMD_SPI_WRITE,
 	.wdt_src = PWRAP_WDT_SRC_MASK_ALL,
+	.has_bridge = 1,
 	.init_reg_clock = pwrap_mt8135_init_reg_clock,
 	.init_special = pwrap_mt8135_init_special,
 };
@@ -842,6 +837,7 @@ static struct pmic_wrapper_type pwrap_mt8173 = {
 	.int_en_all = ~(BIT(31) | BIT(1)),
 	.spi_w = PWRAP_MAN_CMD_SPI_WRITE,
 	.wdt_src = PWRAP_WDT_SRC_MASK_NO_STAUPD,
+	.has_bridge = 0,
 	.init_reg_clock = pwrap_mt8173_init_reg_clock,
 	.init_special = pwrap_mt8173_init_special,
 };
@@ -889,7 +885,7 @@ static int pwrap_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	if (pwrap_is_mt8135(wrp)) {
+	if (wrp->master->has_bridge) {
 		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
 				"pwrap-bridge");
 		wrp->bridge_base = devm_ioremap_resource(wrp->dev, res);
-- 
1.7.10.4


From blogic at openwrt.org  Sun Feb  7 02:42:57 2016
From: blogic at openwrt.org (John Crispin)
Date: Sun,  7 Feb 2016 11:42:57 +0100
Subject: [PATCH V5 10/11] soc: mediatek: PMIC wrap: add mt6323 slave support
In-Reply-To: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
Message-ID: <1454841778-35529-11-git-send-email-blogic@openwrt.org>

Add support for MT6323 slaves. This PMIC can be found on MT2701 and MT7623
EVB. The only function that we need to touch is pwrap_init_cipher().

Signed-off-by: John Crispin <blogic at openwrt.org>
---
 drivers/soc/mediatek/mtk-pmic-wrap.c |   47 ++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 2628271..5fbdd5c 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -91,6 +91,31 @@ enum dew_regs {
 	PWRAP_DEW_CIPHER_RDY,
 	PWRAP_DEW_CIPHER_MODE,
 	PWRAP_DEW_CIPHER_SWRST,
+
+	/* MT6323 only regs */
+	PWRAP_DEW_CRC_SWRST,
+	PWRAP_DEW_CIPHER_EN,
+	PWRAP_DEW_RDDMY_NO,
+	PWRAP_DEW_RDATA_DLY_SEL,
+};
+
+static const u32 mt6323_regs[] = {
+	[PWRAP_DEW_BASE] =		0x0000,
+	[PWRAP_DEW_DIO_EN] =		0x018a,
+	[PWRAP_DEW_READ_TEST] =		0x018c,
+	[PWRAP_DEW_WRITE_TEST] =	0x018e,
+	[PWRAP_DEW_CRC_SWRST] =		0x0190,
+	[PWRAP_DEW_CRC_EN] =		0x0192,
+	[PWRAP_DEW_CRC_VAL] =		0x0194,
+	[PWRAP_DEW_MON_GRP_SEL] =	0x0196,
+	[PWRAP_DEW_CIPHER_KEY_SEL] =	0x0198,
+	[PWRAP_DEW_CIPHER_IV_SEL] =	0x019a,
+	[PWRAP_DEW_CIPHER_EN] =		0x019c,
+	[PWRAP_DEW_CIPHER_RDY] =	0x019e,
+	[PWRAP_DEW_CIPHER_MODE] =	0x01a0,
+	[PWRAP_DEW_CIPHER_SWRST] =	0x01a2,
+	[PWRAP_DEW_RDDMY_NO] =		0x01a4,
+	[PWRAP_DEW_RDATA_DLY_SEL] =	0x01a6,
 };
 
 static const u32 mt6397_regs[] = {
@@ -369,6 +394,7 @@ static int mt8135_regs[] = {
 };
 
 enum pmic_type {
+	PMIC_MT6323,
 	PMIC_MT6397,
 };
 
@@ -659,6 +685,19 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
 	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_LOAD], 0x1);
 	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_START], 0x1);
 
+	switch (wrp->slave->type) {
+	case PMIC_MT6397:
+		pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_LOAD],
+			    0x1);
+		pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_START],
+			    0x1);
+		break;
+	case PMIC_MT6323:
+		pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_EN],
+			    0x1);
+		break;
+	}
+
 	/* wait for cipher data ready at AP */
 	ret = pwrap_wait_for_state(wrp, pwrap_is_cipher_ready);
 	if (ret) {
@@ -856,6 +895,11 @@ static const struct regmap_config pwrap_regmap_config = {
 	.max_register = 0xffff,
 };
 
+static const struct pwrap_slv_type pmic_mt6323 = {
+	.dew_regs = mt6323_regs,
+	.type = PMIC_MT6323,
+};
+
 static const struct pwrap_slv_type pmic_mt6397 = {
 	.dew_regs = mt6397_regs,
 	.type = PMIC_MT6397,
@@ -863,6 +907,9 @@ static const struct pwrap_slv_type pmic_mt6397 = {
 
 static const struct of_device_id of_slave_match_tbl[] = {
 	{
+		.compatible = "mediatek,mt6323",
+		.data = &pmic_mt6323,
+	}, {
 		.compatible = "mediatek,mt6397",
 		.data = &pmic_mt6397,
 	}, {
-- 
1.7.10.4


From blogic at openwrt.org  Sun Feb  7 02:42:58 2016
From: blogic at openwrt.org (John Crispin)
Date: Sun,  7 Feb 2016 11:42:58 +0100
Subject: [PATCH V5 11/11] soc: mediatek: PMIC wrap: add MT2701/7623 support
In-Reply-To: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
Message-ID: <1454841778-35529-12-git-send-email-blogic@openwrt.org>

Add the registers, callbacks and data structures required to make the
wrapper work on MT2701 and MT7623.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
 drivers/soc/mediatek/mtk-pmic-wrap.c |  162 ++++++++++++++++++++++++++++++++++
 1 file changed, 162 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 5fbdd5c..ee6d917 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -52,6 +52,7 @@
 #define PWRAP_DEW_WRITE_TEST_VAL	0xa55a
 
 /* macro for manual command */
+#define PWRAP_MAN_CMD_SPI_WRITE_NEW	(1 << 14)
 #define PWRAP_MAN_CMD_SPI_WRITE		(1 << 13)
 #define PWRAP_MAN_CMD_OP_CSH		(0x0 << 8)
 #define PWRAP_MAN_CMD_OP_CSL		(0x1 << 8)
@@ -202,6 +203,17 @@ enum pwrap_regs {
 	PWRAP_DCM_EN,
 	PWRAP_DCM_DBC_PRD,
 
+	/* MT2701 only regs */
+	PWRAP_OP_TYPE,
+	PWRAP_MSB_FIRST,
+	PWRAP_GPS_STA,
+	PWRAP_ADC_CMD_ADDR,
+	PWRAP_PWRAP_ADC_CMD,
+	PWRAP_ADC_RDY_ADDR,
+	PWRAP_ADC_RDATA_ADDR1,
+	PWRAP_ADC_RDATA_ADDR2,
+	PWRAP_ADC_WRAP_SEL,
+
 	/* MT8135 only regs */
 	PWRAP_CSHEXT,
 	PWRAP_EVENT_IN_EN,
@@ -238,6 +250,96 @@ enum pwrap_regs {
 	PWRAP_CIPHER_EN,
 };
 
+static int mt2701_regs[] = {
+	[PWRAP_MUX_SEL] =		0x0,
+	[PWRAP_WRAP_EN] =		0x4,
+	[PWRAP_DIO_EN] =		0x8,
+	[PWRAP_SIDLY] =			0xc,
+	[PWRAP_OP_TYPE] =		0x10,
+	[PWRAP_MSB_FIRST] =		0x14,
+	[PWRAP_RDDMY] =			0x18,
+	[PWRAP_SI_CK_CON] =		0x1c,
+	[PWRAP_CSHEXT_WRITE] =		0x20,
+	[PWRAP_CSHEXT_READ] =		0x24,
+	[PWRAP_CSLEXT_START] =		0x28,
+	[PWRAP_CSLEXT_END] =		0x2c,
+	[PWRAP_STAUPD_PRD] =		0x30,
+	[PWRAP_STAUPD_GRPEN] =		0x34,
+	[PWRAP_STAUPD_MAN_TRIG] =	0x38,
+	[PWRAP_STAUPD_STA] =		0x3c,
+	[PWRAP_GPS_STA] =		0x40,
+	[PWRAP_WRAP_STA] =		0x44,
+	[PWRAP_HARB_INIT] =		0x48,
+	[PWRAP_HARB_HPRIO] =		0x4c,
+	[PWRAP_HIPRIO_ARB_EN] =		0x50,
+	[PWRAP_HARB_STA0] =		0x54,
+	[PWRAP_HARB_STA1] =		0x58,
+	[PWRAP_MAN_EN] =		0x5c,
+	[PWRAP_MAN_CMD] =		0x60,
+	[PWRAP_MAN_RDATA] =		0x64,
+	[PWRAP_MAN_VLDCLR] =		0x68,
+	[PWRAP_WACS0_EN] =		0x6c,
+	[PWRAP_INIT_DONE0] =		0x70,
+	[PWRAP_WACS0_CMD] =		0x74,
+	[PWRAP_WACS0_RDATA] =		0x78,
+	[PWRAP_WACS0_VLDCLR] =		0x7c,
+	[PWRAP_WACS1_EN] =		0x80,
+	[PWRAP_INIT_DONE1] =		0x84,
+	[PWRAP_WACS1_CMD] =		0x88,
+	[PWRAP_WACS1_RDATA] =		0x8c,
+	[PWRAP_WACS1_VLDCLR] =		0x90,
+	[PWRAP_WACS2_EN] =		0x94,
+	[PWRAP_INIT_DONE2] =		0x98,
+	[PWRAP_WACS2_CMD] =		0x9c,
+	[PWRAP_WACS2_RDATA] =		0xa0,
+	[PWRAP_WACS2_VLDCLR] =		0xa4,
+	[PWRAP_INT_EN] =		0xa8,
+	[PWRAP_INT_FLG_RAW] =		0xac,
+	[PWRAP_INT_FLG] =		0xb0,
+	[PWRAP_INT_CLR] =		0xb4,
+	[PWRAP_SIG_ADR] =		0xb8,
+	[PWRAP_SIG_MODE] =		0xbc,
+	[PWRAP_SIG_VALUE] =		0xc0,
+	[PWRAP_SIG_ERRVAL] =		0xc4,
+	[PWRAP_CRC_EN] =		0xc8,
+	[PWRAP_TIMER_EN] =		0xcc,
+	[PWRAP_TIMER_STA] =		0xd0,
+	[PWRAP_WDT_UNIT] =		0xd4,
+	[PWRAP_WDT_SRC_EN] =		0xd8,
+	[PWRAP_WDT_FLG] =		0xdc,
+	[PWRAP_DEBUG_INT_SEL] =		0xe0,
+	[PWRAP_DVFS_ADR0] =		0xe4,
+	[PWRAP_DVFS_WDATA0] =		0xe8,
+	[PWRAP_DVFS_ADR1] =		0xec,
+	[PWRAP_DVFS_WDATA1] =		0xf0,
+	[PWRAP_DVFS_ADR2] =		0xf4,
+	[PWRAP_DVFS_WDATA2] =		0xf8,
+	[PWRAP_DVFS_ADR3] =		0xfc,
+	[PWRAP_DVFS_WDATA3] =		0x100,
+	[PWRAP_DVFS_ADR4] =		0x104,
+	[PWRAP_DVFS_WDATA4] =		0x108,
+	[PWRAP_DVFS_ADR5] =		0x10c,
+	[PWRAP_DVFS_WDATA5] =		0x110,
+	[PWRAP_DVFS_ADR6] =		0x114,
+	[PWRAP_DVFS_WDATA6] =		0x118,
+	[PWRAP_DVFS_ADR7] =		0x11c,
+	[PWRAP_DVFS_WDATA7] =		0x120,
+	[PWRAP_CIPHER_KEY_SEL] =	0x124,
+	[PWRAP_CIPHER_IV_SEL] =		0x128,
+	[PWRAP_CIPHER_EN] =		0x12c,
+	[PWRAP_CIPHER_RDY] =		0x130,
+	[PWRAP_CIPHER_MODE] =		0x134,
+	[PWRAP_CIPHER_SWRST] =		0x138,
+	[PWRAP_DCM_EN] =		0x13c,
+	[PWRAP_DCM_DBC_PRD] =		0x140,
+	[PWRAP_ADC_CMD_ADDR] =		0x144,
+	[PWRAP_PWRAP_ADC_CMD] =		0x148,
+	[PWRAP_ADC_RDY_ADDR] =		0x14c,
+	[PWRAP_ADC_RDATA_ADDR1] =	0x150,
+	[PWRAP_ADC_RDATA_ADDR2] =	0x154,
+	[PWRAP_ADC_WRAP_SEL] =		0x184,
+};
+
 static int mt8173_regs[] = {
 	[PWRAP_MUX_SEL] =		0x0,
 	[PWRAP_WRAP_EN] =		0x4,
@@ -399,6 +501,7 @@ enum pmic_type {
 };
 
 enum pwrap_type {
+	PWRAP_MT2701,
 	PWRAP_MT8135,
 	PWRAP_MT8173,
 };
@@ -639,6 +742,31 @@ static int pwrap_mt8173_init_reg_clock(struct pmic_wrapper *wrp)
 	return 0;
 }
 
+static int pwrap_mt2701_init_reg_clock(struct pmic_wrapper *wrp)
+{
+	switch (wrp->slave->type) {
+	case PMIC_MT6397:
+		pwrap_writel(wrp, 0xc, PWRAP_RDDMY);
+		pwrap_writel(wrp, 0x4, PWRAP_CSHEXT_WRITE);
+		pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_READ);
+		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_START);
+		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_END);
+		break;
+
+	case PMIC_MT6323:
+		pwrap_writel(wrp, 0x8, PWRAP_RDDMY);
+		pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_RDDMY_NO],
+			    0x8);
+		pwrap_writel(wrp, 0x5, PWRAP_CSHEXT_WRITE);
+		pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_READ);
+		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_START);
+		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_END);
+		break;
+	}
+
+	return 0;
+}
+
 static bool pwrap_is_cipher_ready(struct pmic_wrapper *wrp)
 {
 	return pwrap_readl(wrp, PWRAP_CIPHER_RDY) & 1;
@@ -672,6 +800,7 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
 		pwrap_writel(wrp, 1, PWRAP_CIPHER_LOAD);
 		pwrap_writel(wrp, 1, PWRAP_CIPHER_START);
 		break;
+	case PWRAP_MT2701:
 	case PWRAP_MT8173:
 		pwrap_writel(wrp, 1, PWRAP_CIPHER_EN);
 		break;
@@ -774,6 +903,24 @@ static int pwrap_mt8173_init_special(struct pmic_wrapper *wrp)
 	return 0;
 }
 
+static int pwrap_mt2701_init_special(struct pmic_wrapper *wrp)
+{
+	/* GPS_INTF initialization */
+	switch (wrp->slave->type) {
+	case PMIC_MT6323:
+		pwrap_writel(wrp, 0x076c, PWRAP_ADC_CMD_ADDR);
+		pwrap_writel(wrp, 0x8000, PWRAP_PWRAP_ADC_CMD);
+		pwrap_writel(wrp, 0x072c, PWRAP_ADC_RDY_ADDR);
+		pwrap_writel(wrp, 0x072e, PWRAP_ADC_RDATA_ADDR1);
+		pwrap_writel(wrp, 0x0730, PWRAP_ADC_RDATA_ADDR2);
+		break;
+	default:
+		break;
+	}
+
+	return 0;
+}
+
 static int pwrap_init(struct pmic_wrapper *wrp)
 {
 	int ret;
@@ -918,6 +1065,18 @@ static const struct of_device_id of_slave_match_tbl[] = {
 };
 MODULE_DEVICE_TABLE(of, of_slave_match_tbl);
 
+static const struct pmic_wrapper_type pwrap_mt2701 = {
+	.regs = mt2701_regs,
+	.type = PWRAP_MT2701,
+	.arb_en_all = 0x3f,
+	.int_en_all = ~(BIT(31) | BIT(2)),
+	.spi_w = PWRAP_MAN_CMD_SPI_WRITE_NEW,
+	.wdt_src = PWRAP_WDT_SRC_MASK_ALL,
+	.has_bridge = 0,
+	.init_reg_clock = pwrap_mt2701_init_reg_clock,
+	.init_special = pwrap_mt2701_init_special,
+};
+
 static struct pmic_wrapper_type pwrap_mt8135 = {
 	.regs = mt8135_regs,
 	.type = PWRAP_MT8135,
@@ -944,6 +1103,9 @@ static struct pmic_wrapper_type pwrap_mt8173 = {
 
 static struct of_device_id of_pwrap_match_tbl[] = {
 	{
+		.compatible = "mediatek,mt2701-pwrap",
+		.data = &pwrap_mt2701,
+	}, {
 		.compatible = "mediatek,mt8135-pwrap",
 		.data = &pwrap_mt8135,
 	}, {
-- 
1.7.10.4


From gregory.clement at free-electrons.com  Sun Feb  7 03:16:55 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Sun, 07 Feb 2016 12:16:55 +0100
Subject: [PATCH v2 03/12] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <20160207071747.GA14010@kroah.com> (Greg Kroah-Hartman's message
 of "Sat, 6 Feb 2016 23:17:47 -0800")
References: <1454524889-9207-1-git-send-email-gregory.clement@free-electrons.com>
 <1454524889-9207-4-git-send-email-gregory.clement@free-electrons.com>
 <20160207071747.GA14010@kroah.com>
Message-ID: <87a8nc3h3s.fsf@free-electrons.com>

Hi Greg,
 
 On dim., f?vr. 07 2016, Greg Kroah-Hartman <gregkh at linuxfoundation.org> wrote:

> On Wed, Feb 03, 2016 at 07:41:20PM +0100, Gregory CLEMENT wrote:
>> +static struct console mvebu_uart_console = {
>> +	.name	= "ttyS",
>
> You aren't ttyS, that's a reserved name for a different chip, please use
> a new name and major/minor numbers.

Oh sorry, I changed the ttyS to ttyMV in the uart_driver struct but I
forgot the console. I will fix it in next version.

Thanks,

Gregory

>
> thanks,
>
> greg k-h

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From viresh.kumar at linaro.org  Sun Feb  7 04:22:12 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Sun, 7 Feb 2016 17:52:12 +0530
Subject: [PATCH RFC] Add cpufreq support
In-Reply-To: <3308645.nrPBoahQ2V@wuerfel>
References: <56B4D4BE.2040008@free.fr>
 <3308645.nrPBoahQ2V@wuerfel>
Message-ID: <20160207122212.GA3808@vireshk>

On 05-02-16, 23:24, Arnd Bergmann wrote:
> We no longer call platform_device_register_simple() from platform code, at least
> for new platforms, and we should probably remove the code from the existing
> platforms that still do it. I forget what the replacement was, but I'm not
> going to take this version. Viresh should be able to help you do it the right
> way.

We thought initially that opp-v2's compatible string can be used to probe the
drivers, but that was denied later and all we do today is add platform devices
for cpufreq.

What do you have in mind Arnd ?

-- 
viresh


From lkp at intel.com  Sun Feb  7 05:30:25 2016
From: lkp at intel.com (kbuild test robot)
Date: Sun, 7 Feb 2016 21:30:25 +0800
Subject: [PATCH v3 6/6] kvm: arm64: Add ACPI support for virt arch timer
In-Reply-To: <1454358418-5157-7-git-send-email-fu.wei@linaro.org>
Message-ID: <201602072148.KCt0P2NE%fengguang.wu@intel.com>

Hi Fu,

[auto build test ERROR on tip/timers/core]
[also build test ERROR on v4.5-rc2 next-20160205]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/fu-wei-linaro-org/acpi-clocksource-kvm-add-GTDT-and-ARM-memory-mapped-timer-support/20160202-043111
config: arm64-allyesconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c: In function 'kvm_timer_get_ppi':
>> arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:404:2: error: implicit declaration of function 'gtdt_arch_timer_data_init' [-Werror=implicit-function-declaration]
     if (!*ppi && !gtdt_arch_timer_data_init(NULL, &data))
     ^
   cc1: some warnings being treated as errors

vim +/gtdt_arch_timer_data_init +404 arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c

   398	
   399		*ppi = irq_of_parse_and_map(np, VIRT_PPI);
   400		of_node_put(np);
   401	
   402	skip_of:
   403	#ifdef CONFIG_ACPI_GTDT
 > 404		if (!*ppi && !gtdt_arch_timer_data_init(NULL, &data))
   405			*ppi = data.virt_ppi;
   406	#endif
   407	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 48152 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160207/e26b4b75/attachment-0001.obj>

From g.liakhovetski at gmx.de  Sun Feb  7 05:48:42 2016
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Sun, 7 Feb 2016 14:48:42 +0100 (CET)
Subject: [PATCH] [media] mx3_camera: use %pad format string for dma_ddr_t
In-Reply-To: <1527735.0V0q3NFh2C@wuerfel>
References: <1527735.0V0q3NFh2C@wuerfel>
Message-ID: <Pine.LNX.4.64.1602071446310.11458@axis700.grange>

Hi Arnd,

On Mon, 1 Feb 2016, Arnd Bergmann wrote:

> The mx3_camera driver prints DMA addresses using the "%x" format
> string, which is wrong when using a 64-bit dma_addr_t definition:
> 
> media/platform/soc_camera/mx3_camera.c: In function 'mx3_cam_dma_done':
> media/platform/soc_camera/mx3_camera.c:149:125: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=]
> media/platform/soc_camera/mx3_camera.c: In function 'mx3_videobuf_queue':
> media/platform/soc_camera/mx3_camera.c:317:119: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=]
> media/platform/soc_camera/mx3_camera.c: In function 'mx3_videobuf_release':
> media/platform/soc_camera/mx3_camera.c:346:119: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=]
> 
> This changes the code to use the special %pad format string, which
> always does the right thing.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Thanks for the patch. I'll queue it for 4.6.

Guennadi

> ---
> Another old bug that only rarely shows up in ARM randconfigs.
> 
> diff --git a/drivers/media/platform/soc_camera/mx3_camera.c b/drivers/media/platform/soc_camera/mx3_camera.c
> index 169ed1150226..aa39e9569b1a 100644
> --- a/drivers/media/platform/soc_camera/mx3_camera.c
> +++ b/drivers/media/platform/soc_camera/mx3_camera.c
> @@ -146,8 +146,8 @@ static void mx3_cam_dma_done(void *arg)
>  	struct idmac_channel *ichannel = to_idmac_chan(chan);
>  	struct mx3_camera_dev *mx3_cam = ichannel->client;
>  
> -	dev_dbg(chan->device->dev, "callback cookie %d, active DMA 0x%08x\n",
> -		desc->txd.cookie, mx3_cam->active ? sg_dma_address(&mx3_cam->active->sg) : 0);
> +	dev_dbg(chan->device->dev, "callback cookie %d, active DMA %pad\n",
> +		desc->txd.cookie, mx3_cam->active ? &sg_dma_address(&mx3_cam->active->sg) : NULL);
>  
>  	spin_lock(&mx3_cam->lock);
>  	if (mx3_cam->active) {
> @@ -314,8 +314,8 @@ static void mx3_videobuf_queue(struct vb2_buffer *vb)
>  	spin_unlock_irq(&mx3_cam->lock);
>  
>  	cookie = txd->tx_submit(txd);
> -	dev_dbg(icd->parent, "Submitted cookie %d DMA 0x%08x\n",
> -		cookie, sg_dma_address(&buf->sg));
> +	dev_dbg(icd->parent, "Submitted cookie %d DMA %pad\n",
> +		cookie, &sg_dma_address(&buf->sg));
>  
>  	if (cookie >= 0)
>  		return;
> @@ -344,8 +344,8 @@ static void mx3_videobuf_release(struct vb2_buffer *vb)
>  	unsigned long flags;
>  
>  	dev_dbg(icd->parent,
> -		"Release%s DMA 0x%08x, queue %sempty\n",
> -		mx3_cam->active == buf ? " active" : "", sg_dma_address(&buf->sg),
> +		"Release%s DMA %pad, queue %sempty\n",
> +		mx3_cam->active == buf ? " active" : "", &sg_dma_address(&buf->sg),
>  		list_empty(&buf->queue) ? "" : "not ");
>  
>  	spin_lock_irqsave(&mx3_cam->lock, flags);
> 


From amazon at baker-net.org.uk  Sun Feb  7 06:57:23 2016
From: amazon at baker-net.org.uk (Adam Baker)
Date: Sun, 7 Feb 2016 14:57:23 +0000
Subject: nsa3xx-hwmon mainline patch
In-Reply-To: <56AFDE4F.5060507@gmail.com>
References: <CAPEAnwBtW9QS=6Wp7WH2sNzwERFB_YXByyg-pF+36SwB0Cijpg@mail.gmail.com>
 <56A67820.60802@googlemail.com> <56A96534.4040407@baker-net.org.uk>
 <56A9EA4D.2020108@awi.de> <56AE986E.8090400@baker-net.org.uk>
 <56AFDE4F.5060507@gmail.com>
Message-ID: <56B75B53.8070600@baker-net.org.uk>

Sebastian,

Thanks for the review. Now that I have confirmation no-one else wants to 
claim copyright on this I've added the linux-arm list to the 
distribution so the review comments end up in a public archive.

On 01/02/16 22:38, Sebastian Hesselbarth wrote:
> On 01.02.2016 00:27, Adam Baker wrote:
>> Having concluded that the SPI GPIO driver doesn't support introducing
>> the delays that this driver would need (and modifications to make it do
>> so touch hot paths so are unlikely to be acceptable) I've made a further
>> clean up of the original variant, removing all of the now useless board
>> file support and migrating it to use the new GPIO descriptor syntax.
>>
>> I think this is close to being ready to post to the arm kernel and
>> lm-sensors lists for wider comment but before I do, do any of you want
>> your names added to the list of authors and do you want your email
>> addresses on the CC when posting publicly.
> I do not claim any authorship on the drivers. Feel free to
> reuse anything I provided (or did not provide ;)).
>
>> Hopefully Thunderbird hasn't munged this too much, I'll use git to post
>> it publicly to ensure a clean version.
> If you post to LAKML and others, make sure to use git format-patch
> and possibly also git send-email.
>
> Sending a non-conformant email will just slow your review down ...
>
> And while at it, below is your first review..
>
>> diff --git a/Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt
>> b/Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt
>> new file mode 100644
>> index 0000000..7899d6c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt
>> @@ -0,0 +1,21 @@
>> +Bindings for the fan / temperature monitor microcontroller used on
>> +the Zyxel NSA 320 and several subsequent models.
>> +
>> +Required properties:
>> +- compatible    : "zyxel,nsa320-mcu"
>> +- data-gpios    : The GPIO pin connected to the data line on the MCU
>> +- clk-gpios    : The GPIO pin connected to the clock line on the MCU
>> +- act-gpios    : The GPIO pin connected to the active line on the MCU
>> +
>> +Example:
>> +
>> +    nsa3xx-hwmon {
> just use hwmon { above.
done
>> +        compatible = "zyxel,nsa320-mcu";
>> +        pinctrl-0 = <&pmx_mcu_data &pmx_mcu_clk &pmx_mcu_act>;
>> +        pinctrl-names = "default";
>> +
>> +        data-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
>> +        clk-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
>> +        act-gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>;
> If act is really ACTIVE_HIGH, then SPI would have a problem.
> Can you double-check that mcu is accessed when act is _high_?
It is active low as per the DTS file below, example corrected
>> +    };
>> +
>> diff --git a/arch/arm/boot/dts/kirkwood-nsa320.dts
>> b/arch/arm/boot/dts/kirkwood-nsa320.dts
>> index 24f686d..b663bd7 100644
>> --- a/arch/arm/boot/dts/kirkwood-nsa320.dts
>> +++ b/arch/arm/boot/dts/kirkwood-nsa320.dts
>> @@ -193,10 +193,19 @@
>>           };
>>       };
>>
>> +    nsa3xx-hwmon {
> Just "hwmon" again.
Done
>> +        compatible = "zyxel,nsa320-mcu";
>> +        pinctrl-0 = <&pmx_mcu_data &pmx_mcu_clk &pmx_mcu_act>;
>> +        pinctrl-names = "default";
>> +
>> +        data-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
>> +        clk-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
>> +        act-gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
> Ah, look. here it is ACTIVE_LOW. You should get both into sync.
>
>> +    };
>> +
>>       /* The following pins are currently not assigned to a driver,
>>          some of them should be configured as inputs.
>> -    pinctrl-0 = <&pmx_mcu_data &pmx_mcu_clk &pmx_mcu_act
>> -             &pmx_htp &pmx_vid_b1
>> +    pinctrl-0 = <&pmx_htp &pmx_vid_b1
>>                &pmx_power_resume_data &pmx_power_resume_clk>; */
>>   };
>>
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>> index 80a73bf..8801b78 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -1757,6 +1757,19 @@ config SENSORS_ULTRA45
>>         This driver provides support for the Ultra45 workstation
>> environmental
>>         sensors.
>>
>> +config SENSORS_NSA3XX
>> +    tristate "ZyXEL NSA3xx fan speed and temperature sensors"
> I heard of NSA3xx versions not using the SPI interface and
> a different protocol? Is the driver generic enough to support
> all NSA3-series devices?
I believe that there are at least 3 models that use this MCU (the 
NSA320, NSA325 and some variants of the NSA310). As I only own an NSA320 
that's all I've tested but I've seen references to the board file driver 
this is based on working unchanged on the other two. Some of the NSA310 
variants and the NSA320S use an off the shelf I2C based monitoring chip 
that already has drivers
>> +    depends on GPIOLIB && OF
>> +    help
>> +      If you say yes here you get support for hardware monitoring
>> +      for the ZyXEL NSA3XX Media Servers.
>> +
>> +      The sensor data is taken from a Holtek HT46R065 microcontroller
>> +      connected to GPIO lines.
>> +
>> +      This driver can also be built as a module. If so, the module
>> +      will be called nsa3xx-hwmon.
>> +
>>   if ACPI
>>
>>   comment "ACPI drivers"
>> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
>> index 12a3239..e85414a 100644
>> --- a/drivers/hwmon/Makefile
>> +++ b/drivers/hwmon/Makefile
>> @@ -118,6 +118,7 @@ obj-$(CONFIG_SENSORS_MAX6650)    += max6650.o
>>   obj-$(CONFIG_SENSORS_MAX6697)    += max6697.o
>>   obj-$(CONFIG_SENSORS_MAX31790)    += max31790.o
>>   obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
>> +obj-$(CONFIG_SENSORS_NSA3XX)    += nsa3xx-hwmon.o
>>   obj-$(CONFIG_SENSORS_MCP3021)    += mcp3021.o
>>   obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o
>>   obj-$(CONFIG_SENSORS_NCT6683)    += nct6683.o
>> diff --git a/drivers/hwmon/nsa3xx-hwmon.c b/drivers/hwmon/nsa3xx-hwmon.c
>> new file mode 100644
>> index 0000000..11fd5e3
>> --- /dev/null
>> +++ b/drivers/hwmon/nsa3xx-hwmon.c
>> @@ -0,0 +1,267 @@
>> +/*
>> + * drivers/hwmon/nsa3xx-hwmon.c
>> + *
>> + * ZyXEL NSA3xx Media Servers
>> + * hardware monitoring
>> + *
>> + * Copyright (C) 2012 Peter Schildmann<linux at schildmann.info>
>> + * Copyright (C) 2016 Adam Baker<linux at baker-net.org.uk>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License v2 as published by
>> the
>> + * Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but
>> WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
>> License for
>> + * more details.
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/err.h>
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/hwmon.h>
>> +#include <linux/hwmon-sysfs.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/delay.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_platform.h>
>> +
>> +#define MAGIC_NUMBER 0x55
>> +#define DRVNAME "nsa3xx-hwmon"
> is DRVNAME used at all? If you really want to have the
> define, use it _everywhere_ or even better, do not have
> the define at all.

It was only used once so I've removed it

>> +/*
>> + * The Zyxel hwmon MCU is a Holtek HT46R065 that is factory programmed
>> + * to perform temperature and fan speed monitoring. It is read by taking
>> + * the active pin low. The 32 bit output word is then clocked onto the
>> + * data line. The MSB of the data word is a magic nuber to indicate it
>> + * has been read correctly, the next byte is the fan speed (in hundreds
>> + * of RPM) and the last two bytes are the temperature (in tenths of a
>> + * degree
> Missing )
Fixed
>> + */
>> +
>> +struct nsa3xx_hwmon {
>> +    struct device        *classdev;
>> +    struct mutex        update_lock;    /* lock GPIO operations */
>> +    unsigned long        last_updated;    /* jiffies */
>> +    unsigned long        mcu_data;
> u32?
Changed
>> +    struct gpio_desc    *act;
>> +    struct gpio_desc    *clk;
>> +    struct gpio_desc    *data;
>> +};
>> +
>> +enum nsa3xx_inputs {
>> +    NSA3XX_FAN = 1,
>> +    NSA3XX_TEMP = 0,
>> +};
>> +
>> +static const char * const nsa3xx_input_names[] = {
>> +    [NSA3XX_FAN] = "Chassis Fan",
>> +    [NSA3XX_TEMP] = "System Temperature",
>> +};
>> +
>> +/* Although this protocol looks similar to SPI the long delay
>> + * between the active (aka chip select) signal and the shorter
>> + * delay between clock pulses are needed for reliable operation.
>> + * The delays provifded are taken from the manufacturer kernel,
> s/provifded/provided/
Done
>
>> + * testing suggest they probably incorporate a reasonable safety
>> + * margin (the single device tested became unreliable with delays
>> + * around 10% of the values below).
> 10% of the original values or with 10% off, i.e. 90% of the original
> value?
Reworded to make clear it is 10% of the value, not 10% off. With a 
sample size
of one I wouldn't be comfortable if it failed with a value that is 10% off.
>> + */
>> +static unsigned long nsa3xx_hwmon_update(struct device *dev)
>> +{
>> +    int i;
>> +    uint32_t mcu_data;
>> +    struct nsa3xx_hwmon *hwmon = dev_get_drvdata(dev);
>> +
>> +    mutex_lock(&hwmon->update_lock);
>> +
>> +    mcu_data = hwmon->mcu_data;
>> +
>> +    if (time_after(jiffies, hwmon->last_updated + HZ) ||
>> +                            mcu_data == 0) {
>> +
>> +        gpiod_set_value(hwmon->act, 1);
>> +        msleep(100);
>> +
>> +        for (i = 31; i >= 0; i--) {
>> +            gpiod_set_value(hwmon->clk, 0);
>> +            usleep_range(100, 200);
>> +
>> +            gpiod_set_value(hwmon->clk, 1);
>> +            usleep_range(100, 200);
>> +
>> +            mcu_data |=
>> +                 gpiod_get_value(hwmon->data) ? (1 << i) : 0;
>> +        }
> u32 mask;
>
> for (mask = BIT(31); mask; mask >>= 1) {
> 	gpiod_set_value(hwmon->clk, 0);
> 	usleep_range(100, 200);
> 	gpiod_set_value(hwmon->clk, 1);
> 	usleep_range(100, 200);
> 	if (gpiod_get_value(hwmon->data))
> 		mcu_data |= mask;
> }
Changed
>> +
>> +        gpiod_set_value(hwmon->act, 0);
>> +        dev_dbg(dev, "Read raw MCU data %08x\n", mcu_data);
>> +
>> +        if ((mcu_data & 0xff000000) != (MAGIC_NUMBER << 24)) {
> if ((mcu_data >> 24) != MAGIC_NUMBER) { ?
Changed
>> +            dev_err(dev, "Read invalid MCU data %08x\n", mcu_data);
>> +            mcu_data = 0;
>> +        }
>> +
>> +        hwmon->mcu_data = mcu_data;
>> +        hwmon->last_updated = jiffies;
>> +    }
>> +
>> +    mutex_unlock(&hwmon->update_lock);
>> +
>> +    return mcu_data;
>> +}
>> +
>> +static ssize_t show_name(struct device *dev,
>> +             struct device_attribute *attr, char *buf)
>> +{
>> +    return sprintf(buf, "nsa3xx\n");
> Shouldn't that return "nsa3xx-hwmon" or something?
I've changed the registration to use 
devm_hwmon_device_register_with_groups()
so this function has disappeared but the register with groups function 
requires
a name that doesn't have a hyphen in it.
>> +}
>> +
>> +static ssize_t show_label(struct device *dev,
>> +              struct device_attribute *attr, char *buf)
>> +{
>> +    int channel = to_sensor_dev_attr(attr)->index;
>> +
>> +    return sprintf(buf, "%s\n", nsa3xx_input_names[channel]);
>> +}
>> +
>> +static ssize_t show_value(struct device *dev,
>> +              struct device_attribute *attr, char *buf)
>> +{
>> +    int channel = to_sensor_dev_attr(attr)->index;
>> +    unsigned long mcu_data = nsa3xx_hwmon_update(dev);
>> +    unsigned long value = 0;
>> +
>> +    pr_debug("channel value 0x%02x!\n", channel);
>> +    switch (channel) {
>> +    case NSA3XX_TEMP:
>> +        value = (mcu_data & 0xffff) * 100;
>> +        break;
>> +    case NSA3XX_FAN:
>> +        value = ((mcu_data & 0xff0000) >> 16) * 100;
> That's the point: If you claim to support nsa3xx devices,
> you should move all nsa320 stuff into a single update function
> and just return pre-parsed temp and fan rpm here.
>
> If you move the mcu_data parsing to nsa320_hwmon_update()
> you have only one Board-specific function while the rest
> is still more or less generic to easily add nsa310/325/3??
> support to _nsa3xx_ hwmon driver.
>
> And that question will come for sure: How generic is nsa3xx
> hwmon? Currently, it does only support nsa320, right?
As stated above I believe the driver, including the parsing logic, is 
valid for all board variants that have an MCU on them rather than a 
standard I2C monitoring chip.

>> +        break;
>> +    }
>> +    return sprintf(buf, "%lu\n", value);
>> +}
>> +
>> +static DEVICE_ATTR(name, S_IRUGO, show_name, NULL);
>> +static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, show_label, NULL,
>> NSA3XX_TEMP);
>> +static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_value, NULL,
>> NSA3XX_TEMP);
>> +static SENSOR_DEVICE_ATTR(fan1_label, S_IRUGO, show_label, NULL,
>> NSA3XX_FAN);
>> +static SENSOR_DEVICE_ATTR(fan1_input, S_IRUGO, show_value, NULL,
>> NSA3XX_FAN);
>> +
>> +static struct attribute *nsa3xx_attributes[] = {
>> +    &dev_attr_name.attr,
>> +    &sensor_dev_attr_temp1_label.dev_attr.attr,
>> +    &sensor_dev_attr_temp1_input.dev_attr.attr,
>> +    &sensor_dev_attr_fan1_label.dev_attr.attr,
>> +    &sensor_dev_attr_fan1_input.dev_attr.attr,
>> +    NULL
>> +};
>> +
>> +/*
>> + * Look up GPIO pins in device tree
>> + */
>> +static int nsa3xx_hwmon_get_pins(struct device *dev)
>> +{
>> +    struct nsa3xx_hwmon *hwmon = dev_get_drvdata(dev);
>> +
>> +    hwmon->act = devm_gpiod_get(dev, "act", GPIOD_OUT_LOW);
>> +    hwmon->clk = devm_gpiod_get(dev, "clk", GPIOD_OUT_LOW);
>> +    hwmon->data = devm_gpiod_get(dev, "data", GPIOD_IN);
> Not really DT-specific? I guess you can move all of it in
> _probe().
Moved
>> +    if (IS_ERR(hwmon->act))
>> +        return PTR_ERR(hwmon->act);
>> +    if (IS_ERR(hwmon->clk))
>> +        return PTR_ERR(hwmon->clk);
>> +    if (IS_ERR(hwmon->data))
>> +        return PTR_ERR(hwmon->data);
>> +
>> +    return 0;
>> +
>> +}
>> +
>> +static const struct of_device_id of_nsa3xx_hwmon_match[] = {
>> +    {
>> +        .name = "nas3xx-hwmon",
> s/nas/nsa/ but get rid of .name completely.
Done
>> +        .compatible = "zyxel,nsa320-mcu",
>> +    },
>> +    { },
>> +};
>> +
>> +static const struct attribute_group nsa3xx_attr_group = {
>> +    .attrs    = nsa3xx_attributes,
>> +};
>> +
>> +static int nsa3xx_hwmon_probe(struct platform_device *pdev)
>> +{
>> +    int ret;
>> +    struct nsa3xx_hwmon *hwmon;
>> +
>> +    hwmon = devm_kzalloc(&pdev->dev, sizeof(struct nsa3xx_hwmon),
> use sizeof(*hwmon)
Done
>> +                GFP_KERNEL);
>> +    if (!hwmon)
>> +        return -ENOMEM;
>> +
>> +    platform_set_drvdata(pdev, hwmon);
>> +
>> +    ret = nsa3xx_hwmon_get_pins(&pdev->dev);
>> +    if (ret)
>> +        return ret;
>> +
>> +    mutex_init(&hwmon->update_lock);
>> +
>> +    ret = sysfs_create_group(&pdev->dev.kobj, &nsa3xx_attr_group);
>> +    if (ret)
>> +        goto err;
>> +
>> +    hwmon->classdev = hwmon_device_register(&pdev->dev);
>> +    if (IS_ERR(hwmon->classdev)) {
>> +        ret = PTR_ERR(hwmon->classdev);
>> +        goto err_sysfs;
>> +    }
>> +
>> +    dev_info(&pdev->dev, "initialized\n");
> IMHO dev_dbg is sufficient.
Changed
> Sebastian
>
>> +    return 0;
>> +
>> +err_sysfs:
>> +    sysfs_remove_group(&pdev->dev.kobj, &nsa3xx_attr_group);
>> +err:
>> +    platform_set_drvdata(pdev, NULL);
>> +    return ret;
>> +}
>> +
>> +static int nsa3xx_hwmon_remove(struct platform_device *pdev)
>> +{
>> +    struct nsa3xx_hwmon *hwmon = platform_get_drvdata(pdev);
>> +
>> +    hwmon_device_unregister(hwmon->classdev);
>> +    sysfs_remove_group(&pdev->dev.kobj, &nsa3xx_attr_group);
>> +    platform_set_drvdata(pdev, NULL);
>> +
>> +    return 0;
>> +}
>> +
>> +static struct platform_driver nsa3xx_hwmon_driver = {
>> +    .probe = nsa3xx_hwmon_probe,
>> +    .remove = nsa3xx_hwmon_remove,
>> +    .driver = {
>> +        .name = DRVNAME,
>> +        .owner = THIS_MODULE,
>> +        .of_match_table = of_match_ptr(of_nsa3xx_hwmon_match),
>> +    },
>> +};
>> +
>> +module_platform_driver(nsa3xx_hwmon_driver);
>> +
>> +MODULE_DEVICE_TABLE(of, of_nsa3xx_hwmon_match);
>> +MODULE_AUTHOR("Peter Schildmann<linux at schildmann.info>");
>> +MODULE_AUTHOR("Adam Baker<linux at baker-net.org.uk>");
>> +MODULE_DESCRIPTION("NSA3XX Hardware Monitoring");
>> +MODULE_LICENSE("GPL");
>> +MODULE_ALIAS("platform:nsa3xx-hwmon");
>>



From okaya at codeaurora.org  Sun Feb  7 07:00:31 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Sun,  7 Feb 2016 10:00:31 -0500
Subject: [PATCH V2] acpi: implement Generic Event Device
Message-ID: <1454857231-21388-1-git-send-email-okaya@codeaurora.org>

Generic Event Device described in ACPI 6.1 allows platforms to handle
platform interrupts in ACPI ASL statements. It borrows constructs like
_EVT from GPIO events. All interrupts are listed in _CRS and the handler
is written in _EVT method. Here is an example.

Device (GED0)
{

	Name (_HID, "ACPI0013")
	Name (_UID, 0)
	Name(_CRS, ResourceTemplate ()
	{
		Interrupt(ResourceConsumer, Edge, ActiveHigh, Shared, , , )
		 {123}
	})

	Method (_EVT, 1) {
		if (Lequal(123, Arg0))
		{
		}
	}
}

Wake capability has not been implemented yet.

Signed-off-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/acpi/Makefile |   1 +
 drivers/acpi/evged.c  | 156 ++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 157 insertions(+)
 create mode 100644 drivers/acpi/evged.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index e660805..9579d95 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -46,6 +46,7 @@ acpi-y				+= acpi_pnp.o
 acpi-y				+= int340x_thermal.o
 acpi-y				+= power.o
 acpi-y				+= event.o
+acpi-$(CONFIG_ACPI_REDUCED_HARDWARE_ONLY) += evged.o
 acpi-y				+= sysfs.o
 acpi-y				+= property.o
 acpi-$(CONFIG_X86)		+= acpi_cmos_rtc.o
diff --git a/drivers/acpi/evged.c b/drivers/acpi/evged.c
new file mode 100644
index 0000000..9c0a868
--- /dev/null
+++ b/drivers/acpi/evged.c
@@ -0,0 +1,156 @@
+/*
+ * Generic Event Device for ACPI.
+ *
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Generic Event Device allows platforms to handle interrupts in ACPI
+ * ASL statements. It follows very similar to  _EVT method approach
+ * from GPIO events. All interrupts are listed in _CRS and the handler
+ * is written in _EVT method. Here is an example.
+ *
+ * Device (GED0)
+ * {
+ *
+ *     Name (_HID, "ACPI0013")
+ *     Name (_UID, 0)
+ *     Method (_CRS, 0x0, Serialized)
+ *     {
+ *		Name (RBUF, ResourceTemplate ()
+ *		{
+ *		Interrupt(ResourceConsumer, Edge, ActiveHigh, Shared, , , )
+ *		{123}
+ *		}
+ *     })
+ *
+ *     Method (_EVT, 1) {
+ *             if (Lequal(123, Arg0))
+ *             {
+ *             }
+ *     }
+ * }
+ *
+ */
+
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/list.h>
+#include <linux/platform_device.h>
+#include <linux/acpi.h>
+
+#define MODULE_NAME	"acpi-ged"
+
+struct acpi_ged_event {
+	struct list_head node;
+	struct device *dev;
+	unsigned int gsi;
+	unsigned int irq;
+	acpi_handle handle;
+};
+
+static irqreturn_t acpi_ged_irq_handler(int irq, void *data)
+{
+	struct acpi_ged_event *event = data;
+	acpi_status acpi_ret;
+
+	acpi_ret = acpi_execute_simple_method(event->handle, NULL, event->gsi);
+	if (ACPI_FAILURE(acpi_ret))
+		dev_err_once(event->dev, "IRQ method execution failed\n");
+
+	return IRQ_HANDLED;
+}
+
+static acpi_status acpi_ged_request_interrupt(struct acpi_resource *ares,
+					      void *context)
+{
+	struct acpi_ged_event *event;
+	unsigned int irq;
+	unsigned int gsi;
+	unsigned int irqflags = IRQF_ONESHOT;
+	struct device *dev = context;
+	acpi_handle handle = ACPI_HANDLE(dev);
+	acpi_handle evt_handle;
+	struct resource r;
+	struct acpi_resource_irq *p = &ares->data.irq;
+	struct acpi_resource_extended_irq *pext = &ares->data.extended_irq;
+
+	if (ares->type == ACPI_RESOURCE_TYPE_END_TAG)
+		return AE_OK;
+
+	if (!acpi_dev_resource_interrupt(ares, 0, &r)) {
+		dev_err(dev, "unable to parse IRQ resource\n");
+		return AE_ERROR;
+	}
+	if (ares->type == ACPI_RESOURCE_TYPE_IRQ)
+		gsi = p->interrupts[0];
+	else
+		gsi = pext->interrupts[0];
+
+	irq = r.start;
+
+	if (ACPI_FAILURE(acpi_get_handle(handle, "_EVT", &evt_handle))) {
+		dev_err(dev, "cannot locate _EVT method\n");
+		return AE_ERROR;
+	}
+
+	dev_info(dev, "GED listening GSI %u @ IRQ %u\n", gsi, irq);
+
+	event = devm_kzalloc(dev, sizeof(*event), GFP_KERNEL);
+	if (!event)
+		return AE_ERROR;
+
+	event->gsi = gsi;
+	event->dev = dev;
+	event->irq = irq;
+	event->handle = evt_handle;
+
+	if (r.flags & IORESOURCE_IRQ_SHAREABLE)
+		irqflags |= IRQF_SHARED;
+
+	if (devm_request_threaded_irq(dev, irq, NULL, acpi_ged_irq_handler,
+				      irqflags, "ACPI:Ged", event)) {
+		dev_err(dev, "failed to setup event handler for irq %u\n", irq);
+		return AE_ERROR;
+	}
+
+	return AE_OK;
+}
+
+static int ged_probe(struct platform_device *pdev)
+{
+	acpi_status acpi_ret;
+
+	acpi_ret = acpi_walk_resources(ACPI_HANDLE(&pdev->dev), "_CRS",
+				       acpi_ged_request_interrupt, &pdev->dev);
+	if (ACPI_FAILURE(acpi_ret)) {
+		dev_err(&pdev->dev, "unable to parse the _CRS record\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static const struct acpi_device_id ged_acpi_ids[] = {
+	{"ACPI0013"},
+	{},
+};
+
+static struct platform_driver ged_driver = {
+	.probe = ged_probe,
+	.driver = {
+		.name = MODULE_NAME,
+		.acpi_match_table = ACPI_PTR(ged_acpi_ids),
+	},
+};
+
+module_platform_driver(ged_driver);
+MODULE_LICENSE("GPL v2");
-- 
1.8.2.1



From okaya at codeaurora.org  Sun Feb  7 07:04:24 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Sun, 7 Feb 2016 10:04:24 -0500
Subject: [PATCH V13 08/10] dma: qcom_hidma: read the channel id from HW
In-Reply-To: <20160203183650.GI1234@leverpostej>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-9-git-send-email-okaya@codeaurora.org>
 <20160201153542.GA20396@leverpostej> <56B247A1.20503@codeaurora.org>
 <20160203183650.GI1234@leverpostej>
Message-ID: <56B75CF8.9070709@codeaurora.org>

Hi Mark,

On 2/3/2016 1:36 PM, Mark Rutland wrote:
> Sorry, but it's going to be far easier to review with useless code
> removed, so I will wait until the next posting where this patch is
> folded in.

V14 of the patch have been posted on the mail-list where this patch has
been folder into the existing code. 

https://lkml.org/lkml/2016/2/4/1086

I have also captured the information you previously asked into the cover 
letter as you asked.

I'm looking forward to hear your other comments.
Sinan

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


From festevam at gmail.com  Sun Feb  7 07:19:55 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Sun, 7 Feb 2016 13:19:55 -0200
Subject: [PATCH 1/1 v2] imx6q-wandboard-revb1.dts: use unique machine name
In-Reply-To: <1454760419-4822-1-git-send-email-xypron.glpk@gmx.de>
References: <1454758226-4561-1-git-send-email-xypron.glpk@gmx.de>
 <1454760419-4822-1-git-send-email-xypron.glpk@gmx.de>
Message-ID: <CAOMZO5CuCqWbZakc3POzPTYVOb_7zZ3VO807W+Q1M1fhtzUpYw@mail.gmail.com>

On Sat, Feb 6, 2016 at 10:06 AM, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> Downstream packages like Debian flash-kernel use
> /proc/device-tree/model
> to determine which dtb file to install.
>
> Hence each dts in the Linux kernel should provide a unique model identifier.
>
> https://lkml.org/lkml/2014/7/8/579 created the new file
> imx6q-wandboard-revb1.dts but used the same model identifier
> as in imx6q-wandboard.dts.
>
> This patch provides a unique model identifier for revision B1 of
> the Wandboard Quad.
>
> v2:
>         correct name of referenced Debian package
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>

Reviewed-by: Fabio Estevam <fabio.estevam at nxp.com>


From contact at paulk.fr  Sun Feb  7 07:23:51 2016
From: contact at paulk.fr (Paul Kocialkowski)
Date: Sun, 07 Feb 2016 16:23:51 +0100
Subject: [PATCH v2 3/4] ARM: LG Optimus Black (P970) codename sniper
 support, with basic features
In-Reply-To: <1454701140.2623.12.camel@collins>
References: <1454697741-8687-1-git-send-email-contact@paulk.fr>
 <1454697741-8687-4-git-send-email-contact@paulk.fr>
 <1454701140.2623.12.camel@collins>
Message-ID: <1454858631.2547.7.camel@aldrin>

Hi,

Le vendredi 05 f?vrier 2016 ? 20:39 +0100, Paul Kocialkowski a ?crit :
> Le vendredi 05 f?vrier 2016 ? 19:42 +0100, Paul Kocialkowski a ?crit :
> > The LG Optimus Black (P970) codename sniper is a smartphone that was designed
> > and manufactured by LG Electronics (LGE) and released back in 2011.
> > It is using an OMAP3630 SoC, GP version.
> > 
> > This adds devicetree support for the device, with only a few basic features
> > supported, such as debug uart, i2c, internal emmc and external mmc.

[snip}

> > +&mmc2 {
> > +
> 
> Please discard this newline in case v2 gets merged.

All things considered, I'd rather not have this patch merged as-is, but
wait for the next version.

I'll wait for feedback before sending v3.

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: https://www.replicant.us/
Blog: https://blog.replicant.us/
Wiki/tracker/forums: https://redmine.replicant.us/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160207/e83bf34d/attachment.sig>

From jassisinghbrar at gmail.com  Sun Feb  7 08:05:00 2016
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Sun, 7 Feb 2016 21:35:00 +0530
Subject: [GIT PULL] Mailbox fixes for -rc3
Message-ID: <CABb+yY0Da=jRU9RMW5bJ2LHgnxjVLhs6A_AvHWg=i1+6j=k8PA@mail.gmail.com>

Hi Linus,

The following changes since commit 34229b277480f46c1e9a19f027f30b074512e68b:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
(2016-02-01 15:56:08 -0800)

are available in the git repository at:


  git://git.linaro.org/landing-teams/working/fujitsu/integration.git
mailbox-devel

for you to fetch changes up to 65d3b04a814679a31fe4d5edd19d89dd5b94fd40:

  mailbox: Fix dependencies for !HAS_IOMEM archs (2016-02-02 16:47:14 +0530)

----------------------------------------------------------------

- Fix getting element from the pcc-channels array by simply indexing into it

- Prevent building mailbox-test driver for archs that don't have IOMEM

----------------------------------------------------------------
Alexey Klimov (1):
      mailbox: pcc: fix channel calculation in get_pcc_channel()

Richard Weinberger (1):
      mailbox: Fix dependencies for !HAS_IOMEM archs

 drivers/mailbox/Kconfig | 1 +
 drivers/mailbox/pcc.c   | 8 +-------
 2 files changed, 2 insertions(+), 7 deletions(-)


From slash.tmp at free.fr  Sun Feb  7 08:04:54 2016
From: slash.tmp at free.fr (Mason)
Date: Sun, 7 Feb 2016 17:04:54 +0100
Subject: Common/typical fractional divider HW API
In-Reply-To: <1454690599.31169.103.camel@linux.intel.com>
References: <56B4B67D.2080707@free.fr>
 <1454684758.31169.77.camel@linux.intel.com> <56B4C775.50808@free.fr>
 <1454688729.31169.87.camel@linux.intel.com> <56B4CDEF.3080606@free.fr>
 <1454690599.31169.103.camel@linux.intel.com>
Message-ID: <56B76B26.4050306@free.fr>

On 05/02/2016 17:43, Andy Shevchenko wrote:

> There are plenty of implementations of the divider.

I'd be happy to read an overview on the subject, if you have
some links to share.

> You might consider to use one than inventing new one

I find it hard to believe that the interface I'm discussing
has not been used (several times) in the past. (It's merely
a trivial floating point scheme.)

As a matter of fact, the integer divider driver supports
"I" and "2^I", so extending 2^I to "2^I * (1 + F/256)"
is an obvious step.

>> In this part of my message, I was trying to argue that one HW API
>> "2^I * (1 + F/256)" seemed better than another one "I + F/16" on
>> any hardware.
> 
> I disagree in a part 2^I.

I don't know what that means. If you speak Russian, maybe you
can write in Russian, and I'll try to figure it out.

>> Maybe the clk-fractional-divider could be made more generic by having
>> the register update part done in a call-back function?
> 
> Why do you need to touch that module at all if your hardware doesn't
> suit it?

What does it mean "your hardware doesn't suit it" ?

I am saying that if the register update were moved into a call-back
function, then any scheme could be supported. Maybe you think this
is just vague hand-waving. I'll send a patch to illustrate what
I'm saying.

Regards.



From adam at baker-net.org.uk  Sun Feb  7 08:15:36 2016
From: adam at baker-net.org.uk (Adam Baker)
Date: Sun, 7 Feb 2016 16:15:36 +0000
Subject: net: mv643xx: interface does not transmit after some time
In-Reply-To: <20160206231935.GA30734@jirafa.cyrius.com>
References: <E4F9E0D0-9DA8-4E33-9F89-B49E47F11CE0@schloeter.net>
 <20160206183414.GD17218@lunn.ch> <20160206231935.GA30734@jirafa.cyrius.com>
Message-ID: <56B76DA8.3090500@baker-net.org.uk>

On 06/02/16 23:19, Martin Michlmayr wrote:
> * Andrew Lunn <andrew at lunn.ch> [2016-02-06 19:34]:
>> Can you find an easily way to reproduce it? iperf, or scp a big file
>> etc.
>
> FWIW, we had a similar bug report in Debian recently:
> https://lists.debian.org/debian-arm/2016/01/msg00098.html
>
> Turning off TCP RX and TX offloading make it go away:
> https://lists.debian.org/debian-arm/2016/01/msg00100.html
>
> Hopefully Thomas can do a bisect.
>

I observed a similar issue when performing a large NFSv4 transfer with a 
kirkwood based server. Unfortunately I'd just jumped from 3.14 to 4.4 so 
I could do with a better starting point to bisect from.

It failed several times while transferring a 4GB file over NFS but is 
stable in normal use.

Regards

Adam


From andrew at lunn.ch  Sun Feb  7 10:04:51 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Sun, 7 Feb 2016 19:04:51 +0100
Subject: net: mv643xx: interface does not transmit after some time
In-Reply-To: <56B76DA8.3090500@baker-net.org.uk>
References: <E4F9E0D0-9DA8-4E33-9F89-B49E47F11CE0@schloeter.net>
 <20160206183414.GD17218@lunn.ch>
 <20160206231935.GA30734@jirafa.cyrius.com>
 <56B76DA8.3090500@baker-net.org.uk>
Message-ID: <20160207180451.GA27070@lunn.ch>

On Sun, Feb 07, 2016 at 04:15:36PM +0000, Adam Baker wrote:
> On 06/02/16 23:19, Martin Michlmayr wrote:
> >* Andrew Lunn <andrew at lunn.ch> [2016-02-06 19:34]:
> >>Can you find an easily way to reproduce it? iperf, or scp a big file
> >>etc.
> >
> >FWIW, we had a similar bug report in Debian recently:
> >https://lists.debian.org/debian-arm/2016/01/msg00098.html
> >
> >Turning off TCP RX and TX offloading make it go away:
> >https://lists.debian.org/debian-arm/2016/01/msg00100.html
> >
> >Hopefully Thomas can do a bisect.
> >
> 
> I observed a similar issue when performing a large NFSv4 transfer
> with a kirkwood based server. Unfortunately I'd just jumped from
> 3.14 to 4.4 so I could do with a better starting point to bisect
> from.
> 
> It failed several times while transferring a 4GB file over NFS but
> is stable in normal use.

I tried iperf, 6Gbytes, both RX and TX and it worked. This is with
4.5-rc2 net-next.

I will try again with different window sizes etc, to see if i can
trigger it.

	Andrew


From smoch at web.de  Sun Feb  7 10:34:30 2016
From: smoch at web.de (Soeren Moch)
Date: Sun,  7 Feb 2016 19:34:30 +0100
Subject: [PATCH 1/4] ARM: dts: imx6q-tbs2910: add SATA PHY configuration
Message-ID: <1454870073-6506-1-git-send-email-smoch@web.de>

Configure SATA PHY transmit level, boost, attenuation and equalizer
parameters for long wire connections. TBS2910 contains a standard SATA
connector, so devices are typically connected with (longer) SATA cables.
And explicitly configuring these parameters avoids complaints about
"not specified" values in boot messages.

Signed-off-by: Soeren Moch <smoch at web.de>
---
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Sascha Hauer <kernel at pengutronix.de>
Cc: linux-arm-kernel at lists.infradead.org
---
 arch/arm/boot/dts/imx6q-tbs2910.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/imx6q-tbs2910.dts b/arch/arm/boot/dts/imx6q-tbs2910.dts
index 5645d52..d8155d0 100644
--- a/arch/arm/boot/dts/imx6q-tbs2910.dts
+++ b/arch/arm/boot/dts/imx6q-tbs2910.dts
@@ -205,6 +205,10 @@
 };
 
 &sata {
+	fsl,transmit-level-mV = <1104>;
+	fsl,transmit-boost-mdB = <3330>;
+	fsl,transmit-atten-16ths = <16>;
+	fsl,receive-eq-mdB = <3000>;
 	status = "okay";
 };
 
-- 
1.9.1



From smoch at web.de  Sun Feb  7 10:34:31 2016
From: smoch at web.de (Soeren Moch)
Date: Sun,  7 Feb 2016 19:34:31 +0100
Subject: [PATCH 2/4] ARM: dts: imx6q-tbs2910: avoid sdhci boot warnings
In-Reply-To: <1454870073-6506-1-git-send-email-smoch@web.de>
References: <1454870073-6506-1-git-send-email-smoch@web.de>
Message-ID: <1454870073-6506-2-git-send-email-smoch@web.de>

Avoid the following warnings (example for usdhc2):
/soc/aips-bus at 02100000/usdhc at 02194000: voltage-ranges unspecified
sdhci-esdhc-imx 2194000.usdhc: could not get ultra high speed state,
                               work on normal mode
sdhci-esdhc-imx 2194000.usdhc: No vqmmc regulator found

Signed-off-by: Soeren Moch <smoch at web.de>
---
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Sascha Hauer <kernel at pengutronix.de>
Cc: linux-arm-kernel at lists.infradead.org
---
 arch/arm/boot/dts/imx6q-tbs2910.dts | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/imx6q-tbs2910.dts b/arch/arm/boot/dts/imx6q-tbs2910.dts
index d8155d0..3b4360a 100644
--- a/arch/arm/boot/dts/imx6q-tbs2910.dts
+++ b/arch/arm/boot/dts/imx6q-tbs2910.dts
@@ -257,6 +257,9 @@
 	bus-width = <4>;
 	cd-gpios = <&gpio2 2 GPIO_ACTIVE_LOW>;
 	vmmc-supply = <&reg_3p3v>;
+	vqmmc-supply = <&reg_3p3v>;
+	voltage-ranges = <3300 3300>;
+	no-1-8-v;
 	status = "okay";
 };
 
@@ -267,6 +270,9 @@
 	cd-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
 	wp-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
 	vmmc-supply = <&reg_3p3v>;
+	vqmmc-supply = <&reg_3p3v>;
+	voltage-ranges = <3300 3300>;
+	no-1-8-v;
 	status = "okay";
 };
 
@@ -274,6 +280,9 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usdhc4>;
 	bus-width = <8>;
+	vmmc-supply = <&reg_3p3v>;
+	vqmmc-supply = <&reg_3p3v>;
+	voltage-ranges = <3300 3300>;
 	non-removable;
 	no-1-8-v;
 	status = "okay";
-- 
1.9.1



From xypron.glpk at gmx.de  Sun Feb  7 10:34:26 2016
From: xypron.glpk at gmx.de (Heinrich Schuchardt)
Date: Sun,  7 Feb 2016 19:34:26 +0100
Subject: [PATCH 1/1] ARM: kirkwood-ds112.dts: use unique machine name
Message-ID: <1454870066-3353-1-git-send-email-xypron.glpk@gmx.de>

Downstream packages like Debian flash-kernel use
/proc/device-tree/model
to determine which dtb file to install.

Hence each dts in the Linux kernel should provide a unique model
identifier.

Commit 2d0a7addbd10 ("ARM: Kirkwood: Add support for many Synology NAS
devices") created the new files kirkwood-ds111.dts and kirkwood-ds112.dts
using the same model identifier.

This patch provides a unique model identifier for the
Synology DiskStation DS112.

Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
---
 arch/arm/boot/dts/kirkwood-ds112.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/kirkwood-ds112.dts b/arch/arm/boot/dts/kirkwood-ds112.dts
index bf4143c..b84af3d 100644
--- a/arch/arm/boot/dts/kirkwood-ds112.dts
+++ b/arch/arm/boot/dts/kirkwood-ds112.dts
@@ -14,7 +14,7 @@
 #include "kirkwood-synology.dtsi"
 
 / {
-	model = "Synology DS111";
+	model = "Synology DS112";
 	compatible = "synology,ds111", "marvell,kirkwood";
 
 	memory {
-- 
2.1.4



From smoch at web.de  Sun Feb  7 10:34:32 2016
From: smoch at web.de (Soeren Moch)
Date: Sun,  7 Feb 2016 19:34:32 +0100
Subject: [PATCH 3/4] ARM: dts: imx6q-tbs2910: remove unnecessary iomuxc
 container nodes
In-Reply-To: <1454870073-6506-1-git-send-email-smoch@web.de>
References: <1454870073-6506-1-git-send-email-smoch@web.de>
Message-ID: <1454870073-6506-3-git-send-email-smoch@web.de>

Remove the following unnecessary iomuxc container nodes:
imx6q-tbs2910
gpio_fan
gpio_leds

Sort the pinctrl nodes alphabetically.

Signed-off-by: Soeren Moch <smoch at web.de>
---
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Sascha Hauer <kernel at pengutronix.de>
Cc: linux-arm-kernel at lists.infradead.org
---
 arch/arm/boot/dts/imx6q-tbs2910.dts | 262 ++++++++++++++++++------------------
 1 file changed, 128 insertions(+), 134 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-tbs2910.dts b/arch/arm/boot/dts/imx6q-tbs2910.dts
index 3b4360a..b9afafc 100644
--- a/arch/arm/boot/dts/imx6q-tbs2910.dts
+++ b/arch/arm/boot/dts/imx6q-tbs2910.dts
@@ -289,157 +289,151 @@
 };
 
 &iomuxc {
-	imx6q-tbs2910 {
-		pinctrl_enet: enetgrp {
-			fsl,pins = <
-				MX6QDL_PAD_ENET_MDIO__ENET_MDIO       0x1b0b0
-				MX6QDL_PAD_ENET_MDC__ENET_MDC         0x1b0b0
-				MX6QDL_PAD_RGMII_TXC__RGMII_TXC       0x1b0b0
-				MX6QDL_PAD_RGMII_TD0__RGMII_TD0       0x1b0b0
-				MX6QDL_PAD_RGMII_TD1__RGMII_TD1       0x1b0b0
-				MX6QDL_PAD_RGMII_TD2__RGMII_TD2       0x1b0b0
-				MX6QDL_PAD_RGMII_TD3__RGMII_TD3       0x1b0b0
-				MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
-				MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK  0x1b0b0
-				MX6QDL_PAD_RGMII_RXC__RGMII_RXC       0x1b0b0
-				MX6QDL_PAD_RGMII_RD0__RGMII_RD0       0x1b0b0
-				MX6QDL_PAD_RGMII_RD1__RGMII_RD1       0x1b0b0
-				MX6QDL_PAD_RGMII_RD2__RGMII_RD2       0x1b0b0
-				MX6QDL_PAD_RGMII_RD3__RGMII_RD3       0x1b0b0
-				MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
-				MX6QDL_PAD_GPIO_16__ENET_REF_CLK      0x4001b0a8
-				MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25    0x1b059
-			>;
-		};
+	pinctrl_enet: enetgrp {
+		fsl,pins = <
+			MX6QDL_PAD_ENET_MDIO__ENET_MDIO       0x1b0b0
+			MX6QDL_PAD_ENET_MDC__ENET_MDC         0x1b0b0
+			MX6QDL_PAD_RGMII_TXC__RGMII_TXC       0x1b0b0
+			MX6QDL_PAD_RGMII_TD0__RGMII_TD0       0x1b0b0
+			MX6QDL_PAD_RGMII_TD1__RGMII_TD1       0x1b0b0
+			MX6QDL_PAD_RGMII_TD2__RGMII_TD2       0x1b0b0
+			MX6QDL_PAD_RGMII_TD3__RGMII_TD3       0x1b0b0
+			MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
+			MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK  0x1b0b0
+			MX6QDL_PAD_RGMII_RXC__RGMII_RXC       0x1b0b0
+			MX6QDL_PAD_RGMII_RD0__RGMII_RD0       0x1b0b0
+			MX6QDL_PAD_RGMII_RD1__RGMII_RD1       0x1b0b0
+			MX6QDL_PAD_RGMII_RD2__RGMII_RD2       0x1b0b0
+			MX6QDL_PAD_RGMII_RD3__RGMII_RD3       0x1b0b0
+			MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
+			MX6QDL_PAD_GPIO_16__ENET_REF_CLK      0x4001b0a8
+			MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25    0x1b059
+		>;
+	};
 
-		pinctrl_hdmi: hdmigrp {
-			fsl,pins = <
-				MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
-			>;
-		};
+	pinctrl_gpio_fan: gpiofangrp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_D28__GPIO3_IO28        0x130b1
+		>;
+	};
 
-		pinctrl_i2c1: i2c1grp {
-			fsl,pins = <
-				MX6QDL_PAD_CSI0_DAT9__I2C1_SCL        0x4001b8b1
-				MX6QDL_PAD_CSI0_DAT8__I2C1_SDA        0x4001b8b1
-			>;
-		};
+	pinctrl_gpio_leds: gpioledsgrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_2__GPIO1_IO02         0x130b1
+		>;
+	};
 
-		pinctrl_i2c2: i2c2grp {
-			fsl,pins = <
-				MX6QDL_PAD_KEY_COL3__I2C2_SCL         0x4001b8b1
-				MX6QDL_PAD_KEY_ROW3__I2C2_SDA         0x4001b8b1
-			>;
-		};
+	pinctrl_hdmi: hdmigrp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
+		>;
+	};
 
-		pinctrl_i2c3: i2c3grp {
-			fsl,pins = <
-				MX6QDL_PAD_GPIO_3__I2C3_SCL           0x4001b8b1
-				MX6QDL_PAD_GPIO_6__I2C3_SDA           0x4001b8b1
-			>;
-		};
+	pinctrl_i2c1: i2c1grp {
+		fsl,pins = <
+			MX6QDL_PAD_CSI0_DAT9__I2C1_SCL        0x4001b8b1
+			MX6QDL_PAD_CSI0_DAT8__I2C1_SDA        0x4001b8b1
+		>;
+	};
 
-		pinctrl_ir: irgrp {
-			fsl,pins = <
-				MX6QDL_PAD_EIM_D18__GPIO3_IO18        0x17059
-			>;
-		};
+	pinctrl_i2c2: i2c2grp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL3__I2C2_SCL         0x4001b8b1
+			MX6QDL_PAD_KEY_ROW3__I2C2_SDA         0x4001b8b1
+		>;
+	};
 
-		pinctrl_pcie: pciegrp {
-			fsl,pins = <
-				MX6QDL_PAD_GPIO_17__GPIO7_IO12        0x17059
-			>;
-		};
+	pinctrl_i2c3: i2c3grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_3__I2C3_SCL           0x4001b8b1
+			MX6QDL_PAD_GPIO_6__I2C3_SDA           0x4001b8b1
+		>;
+	};
 
-		pinctrl_sgtl5000: sgtl5000grp {
-			fsl,pins = <
-				MX6QDL_PAD_CSI0_DAT7__AUD3_RXD        0x130b0
-				MX6QDL_PAD_CSI0_DAT4__AUD3_TXC        0x130b0
-				MX6QDL_PAD_CSI0_DAT5__AUD3_TXD        0x110b0
-				MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS       0x130b0
-				MX6QDL_PAD_GPIO_0__CCM_CLKO1          0x130b0
-			>;
-		};
+	pinctrl_ir: irgrp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_D18__GPIO3_IO18        0x17059
+		>;
+	};
 
-		pinctrl_spdif: spdifgrp {
-			fsl,pins = <MX6QDL_PAD_GPIO_19__SPDIF_OUT     0x13091
-			>;
-		};
+	pinctrl_pcie: pciegrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_17__GPIO7_IO12        0x17059
+		>;
+	};
 
-		pinctrl_uart1: uart1grp {
-			fsl,pins = <
-				MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA  0x1b0b1
-				MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA  0x1b0b1
-			>;
-		};
+	pinctrl_sgtl5000: sgtl5000grp {
+		fsl,pins = <
+			MX6QDL_PAD_CSI0_DAT7__AUD3_RXD        0x130b0
+			MX6QDL_PAD_CSI0_DAT4__AUD3_TXC        0x130b0
+			MX6QDL_PAD_CSI0_DAT5__AUD3_TXD        0x110b0
+			MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS       0x130b0
+			MX6QDL_PAD_GPIO_0__CCM_CLKO1          0x130b0
+		>;
+	};
 
-		pinctrl_uart2: uart2grp {
-			fsl,pins = <
-				MX6QDL_PAD_EIM_D26__UART2_TX_DATA     0x1b0b1
-				MX6QDL_PAD_EIM_D27__UART2_RX_DATA     0x1b0b1
-			>;
-		};
+	pinctrl_spdif: spdifgrp {
+		fsl,pins = <MX6QDL_PAD_GPIO_19__SPDIF_OUT     0x13091
+		>;
+	};
 
-		pinctrl_usbotg: usbotggrp {
-			fsl,pins = <
-				MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID     0x17059
-			>;
-		};
+	pinctrl_uart1: uart1grp {
+		fsl,pins = <
+			MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA  0x1b0b1
+			MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA  0x1b0b1
+		>;
+	};
 
-		pinctrl_usdhc2: usdhc2grp {
-			fsl,pins = <
-				MX6QDL_PAD_SD2_CMD__SD2_CMD           0x17059
-				MX6QDL_PAD_SD2_CLK__SD2_CLK           0x10059
-				MX6QDL_PAD_SD2_DAT0__SD2_DATA0        0x17059
-				MX6QDL_PAD_SD2_DAT1__SD2_DATA1        0x17059
-				MX6QDL_PAD_SD2_DAT2__SD2_DATA2        0x17059
-				MX6QDL_PAD_SD2_DAT3__SD2_DATA3        0x17059
-				MX6QDL_PAD_NANDF_D2__GPIO2_IO02       0x17059
-			>;
-		};
+	pinctrl_uart2: uart2grp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_D26__UART2_TX_DATA     0x1b0b1
+			MX6QDL_PAD_EIM_D27__UART2_RX_DATA     0x1b0b1
+		>;
+	};
 
-		pinctrl_usdhc3: usdhc3grp {
-			fsl,pins = <
-				MX6QDL_PAD_SD3_CMD__SD3_CMD           0x17059
-				MX6QDL_PAD_SD3_CLK__SD3_CLK           0x10059
-				MX6QDL_PAD_SD3_DAT0__SD3_DATA0        0x17059
-				MX6QDL_PAD_SD3_DAT1__SD3_DATA1        0x17059
-				MX6QDL_PAD_SD3_DAT2__SD3_DATA2        0x17059
-				MX6QDL_PAD_SD3_DAT3__SD3_DATA3        0x17059
-				MX6QDL_PAD_NANDF_D0__GPIO2_IO00       0x17059
-				MX6QDL_PAD_NANDF_D1__GPIO2_IO01       0x17059
-			>;
-		};
+	pinctrl_usbotg: usbotggrp {
+		fsl,pins = <
+			MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID     0x17059
+		>;
+	};
 
-		pinctrl_usdhc4: usdhc4grp {
-			fsl,pins = <
-				MX6QDL_PAD_SD4_CMD__SD4_CMD           0x17059
-				MX6QDL_PAD_SD4_CLK__SD4_CLK           0x10059
-				MX6QDL_PAD_SD4_DAT0__SD4_DATA0        0x17059
-				MX6QDL_PAD_SD4_DAT1__SD4_DATA1        0x17059
-				MX6QDL_PAD_SD4_DAT2__SD4_DATA2        0x17059
-				MX6QDL_PAD_SD4_DAT3__SD4_DATA3        0x17059
-				MX6QDL_PAD_SD4_DAT4__SD4_DATA4        0x17059
-				MX6QDL_PAD_SD4_DAT5__SD4_DATA5        0x17059
-				MX6QDL_PAD_SD4_DAT6__SD4_DATA6        0x17059
-				MX6QDL_PAD_SD4_DAT7__SD4_DATA7        0x17059
-			>;
-		};
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD2_CMD__SD2_CMD           0x17059
+			MX6QDL_PAD_SD2_CLK__SD2_CLK           0x10059
+			MX6QDL_PAD_SD2_DAT0__SD2_DATA0        0x17059
+			MX6QDL_PAD_SD2_DAT1__SD2_DATA1        0x17059
+			MX6QDL_PAD_SD2_DAT2__SD2_DATA2        0x17059
+			MX6QDL_PAD_SD2_DAT3__SD2_DATA3        0x17059
+			MX6QDL_PAD_NANDF_D2__GPIO2_IO02       0x17059
+		>;
 	};
 
-	gpio_fan {
-		pinctrl_gpio_fan: gpiofangrp {
-			fsl,pins = <
-				MX6QDL_PAD_EIM_D28__GPIO3_IO28        0x130b1
-			>;
-		};
+	pinctrl_usdhc3: usdhc3grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD3_CMD__SD3_CMD           0x17059
+			MX6QDL_PAD_SD3_CLK__SD3_CLK           0x10059
+			MX6QDL_PAD_SD3_DAT0__SD3_DATA0        0x17059
+			MX6QDL_PAD_SD3_DAT1__SD3_DATA1        0x17059
+			MX6QDL_PAD_SD3_DAT2__SD3_DATA2        0x17059
+			MX6QDL_PAD_SD3_DAT3__SD3_DATA3        0x17059
+			MX6QDL_PAD_NANDF_D0__GPIO2_IO00       0x17059
+			MX6QDL_PAD_NANDF_D1__GPIO2_IO01       0x17059
+		>;
 	};
 
-	gpio_leds {
-		pinctrl_gpio_leds: gpioledsgrp {
-			fsl,pins = <
-				MX6QDL_PAD_GPIO_2__GPIO1_IO02         0x130b1
-			>;
-		};
+	pinctrl_usdhc4: usdhc4grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD4_CMD__SD4_CMD           0x17059
+			MX6QDL_PAD_SD4_CLK__SD4_CLK           0x10059
+			MX6QDL_PAD_SD4_DAT0__SD4_DATA0        0x17059
+			MX6QDL_PAD_SD4_DAT1__SD4_DATA1        0x17059
+			MX6QDL_PAD_SD4_DAT2__SD4_DATA2        0x17059
+			MX6QDL_PAD_SD4_DAT3__SD4_DATA3        0x17059
+			MX6QDL_PAD_SD4_DAT4__SD4_DATA4        0x17059
+			MX6QDL_PAD_SD4_DAT5__SD4_DATA5        0x17059
+			MX6QDL_PAD_SD4_DAT6__SD4_DATA6        0x17059
+			MX6QDL_PAD_SD4_DAT7__SD4_DATA7        0x17059
+		>;
 	};
 };
-- 
1.9.1



From smoch at web.de  Sun Feb  7 10:34:33 2016
From: smoch at web.de (Soeren Moch)
Date: Sun,  7 Feb 2016 19:34:33 +0100
Subject: [PATCH 4/4] ARM: dts: imx6q-tbs2910: remove artificial simple-bus for
 regulators
In-Reply-To: <1454870073-6506-1-git-send-email-smoch@web.de>
References: <1454870073-6506-1-git-send-email-smoch@web.de>
Message-ID: <1454870073-6506-4-git-send-email-smoch@web.de>

Signed-off-by: Soeren Moch <smoch at web.de>
---
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Sascha Hauer <kernel at pengutronix.de>
Cc: linux-arm-kernel at lists.infradead.org
---
 arch/arm/boot/dts/imx6q-tbs2910.dts | 43 +++++++++++++++----------------------
 1 file changed, 17 insertions(+), 26 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-tbs2910.dts b/arch/arm/boot/dts/imx6q-tbs2910.dts
index b9afafc..0da81bc 100644
--- a/arch/arm/boot/dts/imx6q-tbs2910.dts
+++ b/arch/arm/boot/dts/imx6q-tbs2910.dts
@@ -91,34 +91,25 @@
 		};
 	};
 
-	regulators {
-		compatible = "simple-bus";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		reg_2p5v: regulator at 0 {
-			compatible = "regulator-fixed";
-			reg = <0>;
-			regulator-name = "2P5V";
-			regulator-min-microvolt = <2500000>;
-			regulator-max-microvolt = <2500000>;
-		};
+	reg_2p5v: regulator-2p5v {
+		compatible = "regulator-fixed";
+		regulator-name = "2P5V";
+		regulator-min-microvolt = <2500000>;
+		regulator-max-microvolt = <2500000>;
+	};
 
-		reg_3p3v: regulator at 1 {
-			compatible = "regulator-fixed";
-			reg = <1>;
-			regulator-name = "3P3V";
-			regulator-min-microvolt = <3300000>;
-			regulator-max-microvolt = <3300000>;
-		};
+	reg_3p3v: regulator-3p3v {
+		compatible = "regulator-fixed";
+		regulator-name = "3P3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
 
-		reg_5p0v: regulator at 2 {
-			compatible = "regulator-fixed";
-			reg = <2>;
-			regulator-name = "5P0V";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-		};
+	reg_5p0v: regulator-5p0v {
+		compatible = "regulator-fixed";
+		regulator-name = "5P0V";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
 	};
 
 	sound-sgtl5000 {
-- 
1.9.1



From csotoalonso at gmail.com  Sun Feb  7 10:59:56 2016
From: csotoalonso at gmail.com (Carlos Soto)
Date: Sun, 7 Feb 2016 19:59:56 +0100
Subject: [PATCH 1/1] imx25: Fix LCD pixelclock configuration
In-Reply-To: <20160128063213.GJ9070@tiger>
References: <1450902610-27224-1-git-send-email-csotoalonso@gmail.com>
 <20160128063213.GJ9070@tiger>
Message-ID: <CAD7j7Q_=QeUGOMC0pPn5AXq50h3+vpabB8vRNV5Ac3YupwPxGQ@mail.gmail.com>

2016-01-28 7:32 GMT+01:00 Shawn Guo <shawnguo at kernel.org>:
> On Wed, Dec 23, 2015 at 09:30:10PM +0100, Carlos Soto wrote:
>> Set LCDC base clock (per_7) parent clock to UPLL clock.
>> This is needed to allow finer resolution in pixelclock
>>
>> Signed-off-by: Carlos Soto <csotoalonso at gmail.com>
>> ---
>>  drivers/clk/imx/clk-imx25.c |    6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/clk/imx/clk-imx25.c b/drivers/clk/imx/clk-imx25.c
>> index c4c141c..656340e 100644
>> --- a/drivers/clk/imx/clk-imx25.c
>> +++ b/drivers/clk/imx/clk-imx25.c
>> @@ -238,6 +238,12 @@ static int __init __mx25_clocks_init(unsigned long osc_rate,
>>       clk_set_parent(clk[per5_sel], clk[ahb]);
>>
>>       /*
>> +      * set LCDC base clock (per 7) to highest possible frequency (UPLL)
>> +      * to get best resolution for pixel clock
>> +      */
>> +     clk_set_parent(clk[per7_sel], clk[upll]);
>
> This can be done in device tree via assigned-clock-parents without the
> need of touching kernel.
>
> Shawn
>

Sorry, I was not aware of this feature. Already tested and it works fine via DT

Thanks for the help

Carlos


From andrew at lunn.ch  Sun Feb  7 11:26:32 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Sun, 7 Feb 2016 20:26:32 +0100
Subject: [PATCH 1/1] ARM: kirkwood-ds112.dts: use unique machine name
In-Reply-To: <1454870066-3353-1-git-send-email-xypron.glpk@gmx.de>
References: <1454870066-3353-1-git-send-email-xypron.glpk@gmx.de>
Message-ID: <20160207192632.GA28121@lunn.ch>

On Sun, Feb 07, 2016 at 07:34:26PM +0100, Heinrich Schuchardt wrote:
> Downstream packages like Debian flash-kernel use
> /proc/device-tree/model
> to determine which dtb file to install.
> 
> Hence each dts in the Linux kernel should provide a unique model
> identifier.
> 
> Commit 2d0a7addbd10 ("ARM: Kirkwood: Add support for many Synology NAS
> devices") created the new files kirkwood-ds111.dts and kirkwood-ds112.dts
> using the same model identifier.
> 
> This patch provides a unique model identifier for the
> Synology DiskStation DS112.
> 
> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>

Fixes: 2d0a7addbd10 ("ARM: Kirkwood: Add support for many Synology NAS devices")

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

    Thanks
	Andrew	     

> ---
>  arch/arm/boot/dts/kirkwood-ds112.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/kirkwood-ds112.dts b/arch/arm/boot/dts/kirkwood-ds112.dts
> index bf4143c..b84af3d 100644
> --- a/arch/arm/boot/dts/kirkwood-ds112.dts
> +++ b/arch/arm/boot/dts/kirkwood-ds112.dts
> @@ -14,7 +14,7 @@
>  #include "kirkwood-synology.dtsi"
>  
>  / {
> -	model = "Synology DS111";
> +	model = "Synology DS112";
>  	compatible = "synology,ds111", "marvell,kirkwood";
>  
>  	memory {
> -- 
> 2.1.4
> 


From blogic at openwrt.org  Sun Feb  7 11:40:36 2016
From: blogic at openwrt.org (John Crispin)
Date: Sun,  7 Feb 2016 20:40:36 +0100
Subject: [PATCH V5 1/2] regulator: Add document for MT6323 regulator
Message-ID: <1454874037-38905-1-git-send-email-blogic@openwrt.org>

Signed-off-by: John Crispin <blogic at openwrt.org>
Cc: devicetree at vger.kernel.org

---
Changes in V5
* regulator vs regulators

Changes in V4
* regulator is a subnode and not a property

 .../bindings/regulator/mt6323-regulator.txt        |  244 ++++++++++++++++++++
 1 file changed, 244 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/mt6323-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
new file mode 100644
index 0000000..0a8ebfe
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
@@ -0,0 +1,244 @@
+Mediatek MT6323 Regulator Driver
+
+Required properties:
+- compatible: "mediatek,mt6323-regulator"
+
+All voltage regulators are defined as subnodes of the regulators node. A list
+of regulators provided by this controller are defined as subnodes of the
+drivers node. Each regulator is named according to its regulator type,
+buck_<name> and ldo_<name>. The definition for each of these nodes is defined
+using the standard binding for regulators at
+Documentation/devicetree/bindings/regulator/regulator.txt.
+
+The valid names for regulators are::
+BUCK:
+  buck_vproc, buck_vsys, buck_vpa
+LDO:
+  ldo_vtcxo, ldo_vcn28, ldo_vcn33_bt, ldo_vcn33_wifi, ldo_va, ldo_vcama,
+  ldo_vio28, ldo_vusb, ldo_vmc, ldo_vmch, ldo_vemc3v3, ldo_vgp1, ldo_vgp2,
+  ldo_vgp3, ldo_vcn18, ldo_vsim1, ldo_vsim2, ldo_vrtc, ldo_vcamaf, ldo_vibr,
+  ldo_vrf18, ldo_vm, ldo_vio18, ldo_vcamd, ldo_vcamio
+
+Example:
+
+	pmic: mt6323 {
+		compatible = "mediatek,mt6323";
+
+		mt6323regulator: regulators {
+			compatible = "mediatek,mt6323-regulator";
+
+			mt6323_vproc_reg: buck_vproc{
+				regulator-name = "vproc";
+				regulator-min-microvolt = < 700000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <12500>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vsys_reg: buck_vsys{
+				regulator-name = "vsys";
+				regulator-min-microvolt = <1400000>;
+				regulator-max-microvolt = <2987500>;
+				regulator-ramp-delay = <25000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vpa_reg: buck_vpa{
+				regulator-name = "vpa";
+				regulator-min-microvolt = < 500000>;
+				regulator-max-microvolt = <3650000>;
+			};
+
+			mt6323_vtcxo_reg: ldo_vtcxo{
+				regulator-name = "vtcxo";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <90>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcn28_reg: ldo_vcn28{
+				regulator-name = "vcn28";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <185>;
+			};
+
+			mt6323_vcn33_bt_reg: ldo_vcn33_bt{
+				regulator-name = "vcn33_bt";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3600000>;
+				regulator-enable-ramp-delay = <185>;
+			};
+
+			mt6323_vcn33_wifi_reg: ldo_vcn33_wifi{
+				regulator-name = "vcn33_wifi";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3600000>;
+				regulator-enable-ramp-delay = <185>;
+			};
+
+			mt6323_va_reg: ldo_va{
+				regulator-name = "va";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcama_reg: ldo_vcama{
+				regulator-name = "vcama";
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vio28_reg: ldo_vio28{
+				regulator-name = "vio28";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vusb_reg: ldo_vusb{
+				regulator-name = "vusb";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-boot-on;
+			};
+
+			mt6323_vmc_reg: ldo_vmc{
+				regulator-name = "vmc";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+				regulator-boot-on;
+			};
+
+			mt6323_vmch_reg: ldo_vmch{
+				regulator-name = "vmch";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+				regulator-boot-on;
+			};
+
+			mt6323_vemc3v3_reg: ldo_vemc3v3{
+				regulator-name = "vemc3v3";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+				regulator-boot-on;
+			};
+
+			mt6323_vgp1_reg: ldo_vgp1{
+				regulator-name = "vgp1";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vgp2_reg: ldo_vgp2{
+				regulator-name = "vgp2";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vgp3_reg: ldo_vgp3{
+				regulator-name = "vgp3";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vcn18_reg: ldo_vcn18{
+				regulator-name = "vcn18";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vsim1_reg: ldo_vsim1{
+				regulator-name = "vsim1";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vsim2_reg: ldo_vsim2{
+				regulator-name = "vsim2";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vrtc_reg: ldo_vrtc{
+				regulator-name = "vrtc";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcamaf_reg: ldo_vcamaf{
+				regulator-name = "vcamaf";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vibr_reg: ldo_vibr{
+				regulator-name = "vibr";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+			};
+
+			mt6323_vrf18_reg: ldo_vrf18{
+				regulator-name = "vrf18";
+				regulator-min-microvolt = <1825000>;
+				regulator-max-microvolt = <1825000>;
+				regulator-enable-ramp-delay = <187>;
+			};
+
+			mt6323_vm_reg: ldo_vm{
+				regulator-name = "vm";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vio18_reg: ldo_vio18{
+				regulator-name = "vio18";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcamd_reg: ldo_vcamd{
+				regulator-name = "vcamd";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vcamio_reg: ldo_vcamio{
+				regulator-name = "vcamio";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+		};
+	};
-- 
1.7.10.4


From blogic at openwrt.org  Sun Feb  7 11:40:37 2016
From: blogic at openwrt.org (John Crispin)
Date: Sun,  7 Feb 2016 20:40:37 +0100
Subject: [PATCH V5 2/2] regulator: mt6323: Add support for MT6323 regulator
In-Reply-To: <1454874037-38905-1-git-send-email-blogic@openwrt.org>
References: <1454874037-38905-1-git-send-email-blogic@openwrt.org>
Message-ID: <1454874037-38905-2-git-send-email-blogic@openwrt.org>

From: Chen Zhong <chen.zhong at mediatek.com>

The MT6323 is a regulator found on boards based on MediaTek MT7623 and
probably other SoCs. It is a so called pmic and connects as a slave to
SoC using SPI, wrapped inside the pmic-wrapper.

Signed-off-by: Chen Zhong <chen.zhong at mediatek.com>
Signed-off-by: John Crispin <blogic at openwrt.org>

---
Changes in V5
* remove the code that modifies constraints
* remove the code allows mode changes

Changes in V4:
* add id_table and of_match_table
* use short GPL text
* change MODULE_LICENSE to GPL V2

Changes in V3:
* none

Changes in V2:
* send to the the proper maintainer

 drivers/regulator/Kconfig                  |    9 +
 drivers/regulator/Makefile                 |    1 +
 drivers/regulator/mt6323-regulator.c       |  370 ++++++++++++++++++++++++++++
 include/linux/regulator/mt6323-regulator.h |   52 ++++
 4 files changed, 432 insertions(+)
 create mode 100644 drivers/regulator/mt6323-regulator.c
 create mode 100644 include/linux/regulator/mt6323-regulator.h

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 8155e80..5e49568 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -462,6 +462,15 @@ config REGULATOR_MT6311
 	  This driver supports the control of different power rails of device
 	  through regulator interface.
 
+config REGULATOR_MT6323
+	tristate "MediaTek MT6323 PMIC"
+	depends on MFD_MT6397
+	help
+	  Say y here to select this option to enable the power regulator of
+	  MediaTek MT6323 PMIC.
+	  This driver supports the control of different power rails of device
+	  through regulator interface.
+
 config REGULATOR_MT6397
 	tristate "MediaTek MT6397 PMIC"
 	depends on MFD_MT6397
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 980b194..8fb55640 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
 obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
 obj-$(CONFIG_REGULATOR_MC13XXX_CORE) +=  mc13xxx-regulator-core.o
 obj-$(CONFIG_REGULATOR_MT6311) += mt6311-regulator.o
+obj-$(CONFIG_REGULATOR_MT6323)	+= mt6323-regulator.o
 obj-$(CONFIG_REGULATOR_MT6397)	+= mt6397-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
diff --git a/drivers/regulator/mt6323-regulator.c b/drivers/regulator/mt6323-regulator.c
new file mode 100644
index 0000000..fc0fd48
--- /dev/null
+++ b/drivers/regulator/mt6323-regulator.c
@@ -0,0 +1,370 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Chen Zhong <chen.zhong at mediatek.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.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/mfd/mt6397/core.h>
+#include <linux/mfd/mt6323/registers.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/mt6323-regulator.h>
+#include <linux/regulator/of_regulator.h>
+
+#define MT6323_LDO_MODE_NORMAL	0
+#define MT6323_LDO_MODE_LP	1
+
+/*
+ * MT6323 regulators' information
+ *
+ * @desc: standard fields of regulator description.
+ * @qi: Mask for query enable signal status of regulators
+ * @vselon_reg: Register sections for hardware control mode of bucks
+ * @vselctrl_reg: Register for controlling the buck control mode.
+ * @vselctrl_mask: Mask for query buck's voltage control mode.
+ */
+struct mt6323_regulator_info {
+	struct regulator_desc desc;
+	u32 qi;
+	u32 vselon_reg;
+	u32 vselctrl_reg;
+	u32 vselctrl_mask;
+	u32 modeset_reg;
+	u32 modeset_mask;
+};
+
+#define MT6323_BUCK(match, vreg, min, max, step, volt_ranges, enreg,	\
+		vosel, vosel_mask, voselon, vosel_ctrl)			\
+[MT6323_ID_##vreg] = {							\
+	.desc = {							\
+		.name = #vreg,						\
+		.of_match = of_match_ptr(match),			\
+		.ops = &mt6323_volt_range_ops,				\
+		.type = REGULATOR_VOLTAGE,				\
+		.id = MT6323_ID_##vreg,					\
+		.owner = THIS_MODULE,					\
+		.n_voltages = (max - min)/step + 1,			\
+		.linear_ranges = volt_ranges,				\
+		.n_linear_ranges = ARRAY_SIZE(volt_ranges),		\
+		.vsel_reg = vosel,					\
+		.vsel_mask = vosel_mask,				\
+		.enable_reg = enreg,					\
+		.enable_mask = BIT(0),					\
+	},								\
+	.qi = BIT(13),							\
+	.vselon_reg = voselon,						\
+	.vselctrl_reg = vosel_ctrl,					\
+	.vselctrl_mask = BIT(1),					\
+}
+
+#define MT6323_LDO(match, vreg, ldo_volt_table, enreg, enbit, vosel,	\
+		vosel_mask, _modeset_reg, _modeset_mask)		\
+[MT6323_ID_##vreg] = {							\
+	.desc = {							\
+		.name = #vreg,						\
+		.of_match = of_match_ptr(match),			\
+		.ops = &mt6323_volt_table_ops,				\
+		.type = REGULATOR_VOLTAGE,				\
+		.id = MT6323_ID_##vreg,					\
+		.owner = THIS_MODULE,					\
+		.n_voltages = ARRAY_SIZE(ldo_volt_table),		\
+		.volt_table = ldo_volt_table,				\
+		.vsel_reg = vosel,					\
+		.vsel_mask = vosel_mask,				\
+		.enable_reg = enreg,					\
+		.enable_mask = BIT(enbit),				\
+	},								\
+	.qi = BIT(15),							\
+	.modeset_reg = _modeset_reg,					\
+	.modeset_mask = _modeset_mask,					\
+}
+
+#define MT6323_REG_FIXED(match, vreg, enreg, enbit, volt,		\
+		_modeset_reg, _modeset_mask)				\
+[MT6323_ID_##vreg] = {							\
+	.desc = {							\
+		.name = #vreg,						\
+		.of_match = of_match_ptr(match),			\
+		.ops = &mt6323_volt_fixed_ops,				\
+		.type = REGULATOR_VOLTAGE,				\
+		.id = MT6323_ID_##vreg,					\
+		.owner = THIS_MODULE,					\
+		.n_voltages = 1,					\
+		.enable_reg = enreg,					\
+		.enable_mask = BIT(enbit),				\
+		.min_uV = volt,						\
+	},								\
+	.qi = BIT(15),							\
+	.modeset_reg = _modeset_reg,					\
+	.modeset_mask = _modeset_mask,					\
+}
+
+static const struct regulator_linear_range buck_volt_range1[] = {
+	REGULATOR_LINEAR_RANGE(700000, 0, 0x7f, 6250),
+};
+
+static const struct regulator_linear_range buck_volt_range2[] = {
+	REGULATOR_LINEAR_RANGE(1400000, 0, 0x7f, 12500),
+};
+
+static const struct regulator_linear_range buck_volt_range3[] = {
+	REGULATOR_LINEAR_RANGE(500000, 0, 0x3f, 50000),
+};
+
+static const u32 ldo_volt_table1[] = {
+	3300000, 3400000, 3500000, 3600000,
+};
+
+static const u32 ldo_volt_table2[] = {
+	1500000, 1800000, 2500000, 2800000,
+};
+
+static const u32 ldo_volt_table3[] = {
+	1800000, 3300000,
+};
+
+static const u32 ldo_volt_table4[] = {
+	3000000, 3300000,
+};
+
+static const u32 ldo_volt_table5[] = {
+	1200000, 1300000, 1500000, 1800000, 2000000, 2800000, 3000000, 3300000,
+};
+
+static const u32 ldo_volt_table6[] = {
+	1200000, 1300000, 1500000, 1800000, 2500000, 2800000, 3000000, 2000000,
+};
+
+static const u32 ldo_volt_table7[] = {
+	1200000, 1300000, 1500000, 1800000,
+};
+
+static const u32 ldo_volt_table8[] = {
+	1800000, 3000000,
+};
+
+static const u32 ldo_volt_table9[] = {
+	1200000, 1350000, 1500000, 1800000,
+};
+
+static const u32 ldo_volt_table10[] = {
+	1200000, 1300000, 1500000, 1800000,
+};
+
+static int mt6323_get_status(struct regulator_dev *rdev)
+{
+	int ret;
+	u32 regval;
+	struct mt6323_regulator_info *info = rdev_get_drvdata(rdev);
+
+	ret = regmap_read(rdev->regmap, info->desc.enable_reg, &regval);
+	if (ret != 0) {
+		dev_err(&rdev->dev, "Failed to get enable reg: %d\n", ret);
+		return ret;
+	}
+
+	return (regval & info->qi) ? REGULATOR_STATUS_ON : REGULATOR_STATUS_OFF;
+}
+
+static struct regulator_ops mt6323_volt_range_ops = {
+	.list_voltage = regulator_list_voltage_linear_range,
+	.map_voltage = regulator_map_voltage_linear_range,
+	.set_voltage_sel = regulator_set_voltage_sel_regmap,
+	.get_voltage_sel = regulator_get_voltage_sel_regmap,
+	.set_voltage_time_sel = regulator_set_voltage_time_sel,
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.is_enabled = regulator_is_enabled_regmap,
+	.get_status = mt6323_get_status,
+};
+
+static struct regulator_ops mt6323_volt_table_ops = {
+	.list_voltage = regulator_list_voltage_table,
+	.map_voltage = regulator_map_voltage_iterate,
+	.set_voltage_sel = regulator_set_voltage_sel_regmap,
+	.get_voltage_sel = regulator_get_voltage_sel_regmap,
+	.set_voltage_time_sel = regulator_set_voltage_time_sel,
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.is_enabled = regulator_is_enabled_regmap,
+	.get_status = mt6323_get_status,
+};
+
+static struct regulator_ops mt6323_volt_fixed_ops = {
+	.list_voltage = regulator_list_voltage_linear,
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.is_enabled = regulator_is_enabled_regmap,
+	.get_status = mt6323_get_status,
+};
+
+/* The array is indexed by id(MT6323_ID_XXX) */
+static struct mt6323_regulator_info mt6323_regulators[] = {
+	MT6323_BUCK("buck_vproc", VPROC, 700000, 1493750, 6250,
+		buck_volt_range1, MT6323_VPROC_CON7, MT6323_VPROC_CON9, 0x7f,
+		MT6323_VPROC_CON10, MT6323_VPROC_CON5),
+	MT6323_BUCK("buck_vsys", VSYS, 1400000, 2987500, 12500,
+		buck_volt_range2, MT6323_VSYS_CON7, MT6323_VSYS_CON9, 0x7f,
+		MT6323_VSYS_CON10, MT6323_VSYS_CON5),
+	MT6323_BUCK("buck_vpa", VPA, 500000, 3650000, 50000,
+		buck_volt_range3, MT6323_VPA_CON7, MT6323_VPA_CON9,
+		0x3f, MT6323_VPA_CON10, MT6323_VPA_CON5),
+	MT6323_REG_FIXED("ldo_vtcxo", VTCXO, MT6323_ANALDO_CON1, 10, 2800000,
+		MT6323_ANALDO_CON1, 0x2),
+	MT6323_REG_FIXED("ldo_vcn28", VCN28, MT6323_ANALDO_CON19, 12, 2800000,
+		MT6323_ANALDO_CON20, 0x2),
+	MT6323_LDO("ldo_vcn33_bt", VCN33_BT, ldo_volt_table1,
+		MT6323_ANALDO_CON16, 7, MT6323_ANALDO_CON16, 0xC,
+		MT6323_ANALDO_CON21, 0x2),
+	MT6323_LDO("ldo_vcn33_wifi", VCN33_WIFI, ldo_volt_table1,
+		MT6323_ANALDO_CON17, 12, MT6323_ANALDO_CON16, 0xC,
+		MT6323_ANALDO_CON21, 0x2),
+	MT6323_REG_FIXED("ldo_va", VA, MT6323_ANALDO_CON2, 14, 2800000,
+		MT6323_ANALDO_CON2, 0x2),
+	MT6323_LDO("ldo_vcama", VCAMA, ldo_volt_table2,
+		MT6323_ANALDO_CON4, 15, MT6323_ANALDO_CON10, 0x60, -1, 0),
+	MT6323_REG_FIXED("ldo_vio28", VIO28, MT6323_DIGLDO_CON0, 14, 2800000,
+		MT6323_DIGLDO_CON0, 0x2),
+	MT6323_REG_FIXED("ldo_vusb", VUSB, MT6323_DIGLDO_CON2, 14, 3300000,
+		MT6323_DIGLDO_CON2, 0x2),
+	MT6323_LDO("ldo_vmc", VMC, ldo_volt_table3,
+		MT6323_DIGLDO_CON3, 12, MT6323_DIGLDO_CON24, 0x10,
+		MT6323_DIGLDO_CON3, 0x2),
+	MT6323_LDO("ldo_vmch", VMCH, ldo_volt_table4,
+		MT6323_DIGLDO_CON5, 14, MT6323_DIGLDO_CON26, 0x80,
+		MT6323_DIGLDO_CON5, 0x2),
+	MT6323_LDO("ldo_vemc3v3", VEMC3V3, ldo_volt_table4,
+		MT6323_DIGLDO_CON6, 14, MT6323_DIGLDO_CON27, 0x80,
+		MT6323_DIGLDO_CON6, 0x2),
+	MT6323_LDO("ldo_vgp1", VGP1, ldo_volt_table5,
+		MT6323_DIGLDO_CON7, 15, MT6323_DIGLDO_CON28, 0xE0,
+		MT6323_DIGLDO_CON7, 0x2),
+	MT6323_LDO("ldo_vgp2", VGP2, ldo_volt_table6,
+		MT6323_DIGLDO_CON8, 15, MT6323_DIGLDO_CON29, 0xE0,
+		MT6323_DIGLDO_CON8, 0x2),
+	MT6323_LDO("ldo_vgp3", VGP3, ldo_volt_table7,
+		MT6323_DIGLDO_CON9, 15, MT6323_DIGLDO_CON30, 0x60,
+		MT6323_DIGLDO_CON9, 0x2),
+	MT6323_REG_FIXED("ldo_vcn18", VCN18, MT6323_DIGLDO_CON11, 14, 1800000,
+		MT6323_DIGLDO_CON11, 0x2),
+	MT6323_LDO("ldo_vsim1", VSIM1, ldo_volt_table8,
+		MT6323_DIGLDO_CON13, 15, MT6323_DIGLDO_CON34, 0x20,
+		MT6323_DIGLDO_CON13, 0x2),
+	MT6323_LDO("ldo_vsim2", VSIM2, ldo_volt_table8,
+		MT6323_DIGLDO_CON14, 15, MT6323_DIGLDO_CON35, 0x20,
+		MT6323_DIGLDO_CON14, 0x2),
+	MT6323_REG_FIXED("ldo_vrtc", VRTC, MT6323_DIGLDO_CON15, 8, 2800000,
+		-1, 0),
+	MT6323_LDO("ldo_vcamaf", VCAMAF, ldo_volt_table5,
+		MT6323_DIGLDO_CON31, 15, MT6323_DIGLDO_CON32, 0xE0,
+		MT6323_DIGLDO_CON31, 0x2),
+	MT6323_LDO("ldo_vibr", VIBR, ldo_volt_table5,
+		MT6323_DIGLDO_CON39, 15, MT6323_DIGLDO_CON40, 0xE0,
+		MT6323_DIGLDO_CON39, 0x2),
+	MT6323_REG_FIXED("ldo_vrf18", VRF18, MT6323_DIGLDO_CON45, 15, 1825000,
+		MT6323_DIGLDO_CON45, 0x2),
+	MT6323_LDO("ldo_vm", VM, ldo_volt_table9,
+		MT6323_DIGLDO_CON47, 14, MT6323_DIGLDO_CON48, 0x30,
+		MT6323_DIGLDO_CON47, 0x2),
+	MT6323_REG_FIXED("ldo_vio18", VIO18, MT6323_DIGLDO_CON49, 14, 1800000,
+		MT6323_DIGLDO_CON49, 0x2),
+	MT6323_LDO("ldo_vcamd", VCAMD, ldo_volt_table10,
+		MT6323_DIGLDO_CON51, 14, MT6323_DIGLDO_CON52, 0x60,
+		MT6323_DIGLDO_CON51, 0x2),
+	MT6323_REG_FIXED("ldo_vcamio", VCAMIO, MT6323_DIGLDO_CON53, 14, 1800000,
+		MT6323_DIGLDO_CON53, 0x2),
+};
+
+static int mt6323_set_buck_vosel_reg(struct platform_device *pdev)
+{
+	struct mt6397_chip *mt6323 = dev_get_drvdata(pdev->dev.parent);
+	int i;
+	u32 regval;
+
+	for (i = 0; i < MT6323_MAX_REGULATOR; i++) {
+		if (mt6323_regulators[i].vselctrl_reg) {
+			if (regmap_read(mt6323->regmap,
+				mt6323_regulators[i].vselctrl_reg,
+				&regval) < 0) {
+				dev_err(&pdev->dev,
+					"Failed to read buck ctrl\n");
+				return -EIO;
+			}
+
+			if (regval & mt6323_regulators[i].vselctrl_mask) {
+				mt6323_regulators[i].desc.vsel_reg =
+				mt6323_regulators[i].vselon_reg;
+			}
+		}
+	}
+
+	return 0;
+}
+
+static int mt6323_regulator_probe(struct platform_device *pdev)
+{
+	struct mt6397_chip *mt6323 = dev_get_drvdata(pdev->dev.parent);
+	struct regulator_config config = {};
+	struct regulator_dev *rdev;
+	int i;
+	u32 reg_value;
+
+	/* Query buck controller to select activated voltage register part */
+	if (mt6323_set_buck_vosel_reg(pdev))
+		return -EIO;
+
+	/* Read PMIC chip revision to update constraints and voltage table */
+	if (regmap_read(mt6323->regmap, MT6323_CID, &reg_value) < 0) {
+		dev_err(&pdev->dev, "Failed to read Chip ID\n");
+		return -EIO;
+	}
+	dev_info(&pdev->dev, "Chip ID = 0x%x\n", reg_value);
+
+	for (i = 0; i < MT6323_MAX_REGULATOR; i++) {
+		config.dev = &pdev->dev;
+		config.driver_data = &mt6323_regulators[i];
+		config.regmap = mt6323->regmap;
+		rdev = devm_regulator_register(&pdev->dev,
+				&mt6323_regulators[i].desc, &config);
+		if (IS_ERR(rdev)) {
+			dev_err(&pdev->dev, "failed to register %s\n",
+				mt6323_regulators[i].desc.name);
+			return PTR_ERR(rdev);
+		}
+	}
+	return 0;
+}
+
+static const struct platform_device_id mt6323_platform_ids[] = {
+	{"mt6323-regulator", 0},
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(platform, mt6323_platform_ids);
+
+static const struct of_device_id mt6323_of_match[] = {
+	{ .compatible = "mediatek,mt6323-regulator", },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mt6323_of_match);
+
+static struct platform_driver mt6323_regulator_driver = {
+	.driver = {
+		.name = "mt6323-regulator",
+		.of_match_table = of_match_ptr(mt6323_of_match),
+	},
+	.probe = mt6323_regulator_probe,
+	.id_table = mt6323_platform_ids,
+};
+
+module_platform_driver(mt6323_regulator_driver);
+
+MODULE_AUTHOR("Chen Zhong <chen.zhong at mediatek.com>");
+MODULE_DESCRIPTION("Regulator Driver for MediaTek MT6397 PMIC");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/regulator/mt6323-regulator.h b/include/linux/regulator/mt6323-regulator.h
new file mode 100644
index 0000000..67011cd
--- /dev/null
+++ b/include/linux/regulator/mt6323-regulator.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Chen Zhong <chen.zhong at mediatek.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.
+ */
+
+#ifndef __LINUX_REGULATOR_MT6323_H
+#define __LINUX_REGULATOR_MT6323_H
+
+enum {
+	MT6323_ID_VPROC = 0,
+	MT6323_ID_VSYS,
+	MT6323_ID_VPA,
+	MT6323_ID_VTCXO,
+	MT6323_ID_VCN28,
+	MT6323_ID_VCN33_BT,
+	MT6323_ID_VCN33_WIFI,
+	MT6323_ID_VA,
+	MT6323_ID_VCAMA,
+	MT6323_ID_VIO28 = 9,
+	MT6323_ID_VUSB,
+	MT6323_ID_VMC,
+	MT6323_ID_VMCH,
+	MT6323_ID_VEMC3V3,
+	MT6323_ID_VGP1,
+	MT6323_ID_VGP2,
+	MT6323_ID_VGP3,
+	MT6323_ID_VCN18,
+	MT6323_ID_VSIM1,
+	MT6323_ID_VSIM2,
+	MT6323_ID_VRTC,
+	MT6323_ID_VCAMAF,
+	MT6323_ID_VIBR,
+	MT6323_ID_VRF18,
+	MT6323_ID_VM,
+	MT6323_ID_VIO18,
+	MT6323_ID_VCAMD,
+	MT6323_ID_VCAMIO,
+	MT6323_ID_RG_MAX,
+};
+
+#define MT6323_MAX_REGULATOR	MT6323_ID_RG_MAX
+
+#endif /* __LINUX_REGULATOR_MT6323_H */
-- 
1.7.10.4


From andrew at lunn.ch  Sun Feb  7 12:35:45 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Sun, 7 Feb 2016 21:35:45 +0100
Subject: net: mv643xx: interface does not transmit after some time
In-Reply-To: <2ACB3A0B-DD51-43C1-A56E-E7C175645554@schloeter.net>
References: <E4F9E0D0-9DA8-4E33-9F89-B49E47F11CE0@schloeter.net>
 <20160206183414.GD17218@lunn.ch>
 <20160206231935.GA30734@jirafa.cyrius.com>
 <2ACB3A0B-DD51-43C1-A56E-E7C175645554@schloeter.net>
Message-ID: <20160207203545.GB29107@lunn.ch>

> > FWIW, we had a similar bug report in Debian recently:
> > https://lists.debian.org/debian-arm/2016/01/msg00098.html

Hi Thomas

I this thread, Ian Campbell mentions a patch. Please could you try
that patch and see if it fixes your problem.

Thanks
	Andrew


From afaerber at suse.de  Sun Feb  7 12:57:15 2016
From: afaerber at suse.de (=?UTF-8?q?Andreas=20F=C3=A4rber?=)
Date: Sun,  7 Feb 2016 21:57:15 +0100
Subject: [PATCH] tty: serial: meson: Implement earlycon support
Message-ID: <1454878635-24396-1-git-send-email-afaerber@suse.de>

Reuse the existing console write implementation for implementing
DT-based and command-line-based earlycon support.

Signed-off-by: Andreas F?rber <afaerber at suse.de>
---
 Documentation/kernel-parameters.txt |  6 ++++++
 drivers/tty/serial/meson_uart.c     | 13 +++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 602065c..90801ac 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1030,6 +1030,12 @@ Such letter suffixes can also be entirely omitted.
 			the driver will use only 32-bit accessors to read/write
 			the device registers.
 
+		meson_serial,<addr>
+			Start an early, polled-mode console on a meson serial
+			port at the specified address. The serial port must
+			already be setup and configured. Options are not yet
+			supported.
+
 		msm_serial,<addr>
 			Start an early, polled-mode console on an msm serial
 			port at the specified address. The serial port
diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
index b12a37b..6f89567 100644
--- a/drivers/tty/serial/meson_uart.c
+++ b/drivers/tty/serial/meson_uart.c
@@ -548,6 +548,19 @@ static int __init meson_serial_console_init(void)
 }
 console_initcall(meson_serial_console_init);
 
+static int __init
+meson_serial_early_console_setup(struct earlycon_device *device, const char *opt)
+{
+	if (!device->port.membase)
+		return -ENODEV;
+
+	device->con->write = meson_serial_console_write;
+	return 0;
+}
+EARLYCON_DECLARE(meson_serial, meson_serial_early_console_setup);
+OF_EARLYCON_DECLARE(meson_serial, "amlogic,meson-uart",
+		    meson_serial_early_console_setup);
+
 #define MESON_SERIAL_CONSOLE	(&meson_serial_console)
 #else
 #define MESON_SERIAL_CONSOLE	NULL
-- 
2.6.2



From thomas at schloeter.net  Sun Feb  7 13:07:32 2016
From: thomas at schloeter.net (=?utf-8?Q?Thomas_Schl=C3=B6ter?=)
Date: Sun, 7 Feb 2016 22:07:32 +0100
Subject: net: mv643xx: interface does not transmit after some time
In-Reply-To: <20160207203545.GB29107@lunn.ch>
References: <E4F9E0D0-9DA8-4E33-9F89-B49E47F11CE0@schloeter.net>
 <20160206183414.GD17218@lunn.ch> <20160206231935.GA30734@jirafa.cyrius.com>
 <2ACB3A0B-DD51-43C1-A56E-E7C175645554@schloeter.net>
 <20160207203545.GB29107@lunn.ch>
Message-ID: <A21B89D4-5826-4F97-A1C9-E62E5B724082@schloeter.net>

Am 07.02.2016 um 21:35 schrieb Andrew Lunn <andrew at lunn.ch>:
> 
>>> FWIW, we had a similar bug report in Debian recently:
>>> https://lists.debian.org/debian-arm/2016/01/msg00098.html
> 
> Hi Thomas
> 
> I this thread, Ian Campbell mentions a patch. Please could you try
> that patch and see if it fixes your problem.
> 
> Thanks
> 	Andrew

Hi Andrew,

I just applied the patch and the NAS is now running it. I?ll try to crash it tonight and keep you informed whether it worked.

Thanks
	Thomas

From thomas at schloeter.net  Sun Feb  7 13:11:57 2016
From: thomas at schloeter.net (=?utf-8?Q?Thomas_Schl=C3=B6ter?=)
Date: Sun, 7 Feb 2016 22:11:57 +0100
Subject: net: mv643xx: interface does not transmit after some time
In-Reply-To: <20160206231935.GA30734@jirafa.cyrius.com>
References: <E4F9E0D0-9DA8-4E33-9F89-B49E47F11CE0@schloeter.net>
 <20160206183414.GD17218@lunn.ch> <20160206231935.GA30734@jirafa.cyrius.com>
Message-ID: <E44E7300-840C-4773-8D8B-BADBB9E3929C@schloeter.net>

Am 07.02.2016 um 00:19 schrieb Martin Michlmayr <tbm at cyrius.com>:
> 
> * Andrew Lunn <andrew at lunn.ch> [2016-02-06 19:34]:
>> Can you find an easily way to reproduce it? iperf, or scp a big file
>> etc.
> 
> FWIW, we had a similar bug report in Debian recently:
> https://lists.debian.org/debian-arm/2016/01/msg00098.html
> 
> Turning off TCP RX and TX offloading make it go away:
> https://lists.debian.org/debian-arm/2016/01/msg00100.html

Sounds interesting. I will try that.

> Hopefully Thomas can do a bisect.

I have never used that feature before. As far as I understand, I have to mark the last known good revision good and the most recent bad. Then I try every version in between which has changef related code. Right?

Actually I don't have a last good version as I had the original QNAP fw installed before.

4.3, which I installed during my first try was bad and 4.4 did not fix it. What can I do now? Should I provide my complete kernel config file?
At the moment I am trying Ian Campbell's patch as suggested by Andrew.

Thomas

@Martin: Sorry for reposting to your address, I did not manage to send plain text mail from my iPhone.

From afaerber at suse.de  Sun Feb  7 13:13:03 2016
From: afaerber at suse.de (=?UTF-8?q?Andreas=20F=C3=A4rber?=)
Date: Sun,  7 Feb 2016 22:13:03 +0100
Subject: [PATCH] clk: meson: Fix meson_clk_register_clks() signature type
 mismatch
Message-ID: <1454879583-27036-1-git-send-email-afaerber@suse.de>

As preparation for arm64 based mesongxbb, which pulls in this code once
enabling ARCH_MESON, fix a size_t vs. unsigned int type mismatch.
The loop uses a local unsigned int variable, so adopt that type,
matching the header.

Fixes: 7a29a869434e ("clk: meson: Add support for Meson clock controller")
Signed-off-by: Andreas F?rber <afaerber at suse.de>
---
 drivers/clk/meson/clkc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/meson/clkc.c b/drivers/clk/meson/clkc.c
index c83ae1367abc..d920d410b51d 100644
--- a/drivers/clk/meson/clkc.c
+++ b/drivers/clk/meson/clkc.c
@@ -198,7 +198,7 @@ meson_clk_register_fixed_rate(const struct clk_conf *clk_conf,
 }
 
 void __init meson_clk_register_clks(const struct clk_conf *clk_confs,
-				    size_t nr_confs,
+				    unsigned int nr_confs,
 				    void __iomem *clk_base)
 {
 	unsigned int i;
-- 
2.6.2



From pavel at ucw.cz  Sun Feb  7 13:23:16 2016
From: pavel at ucw.cz (Pavel Machek)
Date: Sun, 7 Feb 2016 22:23:16 +0100
Subject: N900 sleep mode (in 4.5-rc0, if that matters)
In-Reply-To: <20160201221111.GP19432@atomide.com>
References: <20160123121022.GB12497@amd> <20160125163332.GT19432@atomide.com>
 <20160126140010.GA29723@amd> <20160126172527.GY3500@atomide.com>
 <20160130200244.GA30429@amd> <20160130201452.GC30429@amd>
 <20160130221509.GA28644@amd> <20160201181316.GM19432@atomide.com>
 <20160201211736.GA11283@amd> <20160201221111.GP19432@atomide.com>
Message-ID: <20160207212316.GA6147@amd>

Hi!

> > (I assume I have to insmod and rmmod, right? Because powersave is not
> > entered if I simply compile-out usb).
> 
> Depending on what the bootloader does and probably also if
> USB was used during the booting.. So yeah you may need to modprobe
> and then rmmod.
> 
> > Would you have commit ids for those rmmod fixes? It might be good to
> > push them into stable, and I should try again with them applied...
> 
> 055555fc459 ("usb: musb: core: Fix handling of the phy notifications")
> 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable")

Ok, with that, I can insmod and rmmod. But I still get:

00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000
ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042
0000000d 48004a28 (fa004a28) cm_idlest3_core

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From pavel at ucw.cz  Sun Feb  7 13:37:20 2016
From: pavel at ucw.cz (Pavel Machek)
Date: Sun, 7 Feb 2016 22:37:20 +0100
Subject: N900 sleep mode (in 4.5-rc0, if that matters)
In-Reply-To: <20160204053518.GP19432@atomide.com>
References: <20160125163332.GT19432@atomide.com> <20160126140010.GA29723@amd>
 <20160126172527.GY3500@atomide.com> <20160130200244.GA30429@amd>
 <20160130201452.GC30429@amd> <20160130221509.GA28644@amd>
 <20160201181316.GM19432@atomide.com> <20160201211736.GA11283@amd>
 <20160201221111.GP19432@atomide.com>
 <20160204053518.GP19432@atomide.com>
Message-ID: <20160207213720.GB6147@amd>

Hi!

> > > No, sorry, that was with 4.4. As you hit "PM regression with commit
> > > 5de85b9d57ab PM runtime re-init in v4.5-rc1", I thought I'd avoid
> > > v4.5-rc. 
> > 
> > OK
> > 
> > > (I assume I have to insmod and rmmod, right? Because powersave is not
> > > entered if I simply compile-out usb).
> > 
> > Depending on what the bootloader does and probably also if
> > USB was used during the booting.. So yeah you may need to modprobe
> > and then rmmod.
> > 
> > > Would you have commit ids for those rmmod fixes? It might be good to
> > > push them into stable, and I should try again with them applied...
> > 
> > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications")
> > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable")
> 
> Oh and looks like these two phy-twl4030-phy fixes never got
> merged from thread "[PATCH 0/2] Two phy-twl4030-usb fixes for
> unloading the module":
> 
> phy: twl4030-usb: Relase usb phy on unload
> phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload
> 
> I'll resend those. But without those again deeper idle states
> are blocked.. And it could be that n900 needs similar additional
> patches for it's USB PHY as I've tested things so far only with
> phy-twl4030-usb PHY based systems.

I don't get it. I was using

+CONFIG_USB_MUSB_OMAP2PLUS=m
+CONFIG_TWL4030_USB=m

on the n900. Are you suggesting I should be using something else on
the N900? If so, what?

Pali, do you have deeper sleep states working on 4.4 kernel? (Or
anything 4.X?)
									
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From olof at lixom.net  Sun Feb  7 14:19:59 2016
From: olof at lixom.net (Olof Johansson)
Date: Sun, 7 Feb 2016 14:19:59 -0800
Subject: [GIT PULL] ARM: SoC fixes for v4.5-rc
Message-ID: <20160207221959.GA11382@quad.lixom.net>

Hi Linus,


The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3:

  Linux 4.5-rc2 (2016-01-31 18:12:16 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes

for you to fetch changes up to 381a65c21aa1fcf4f3fafe70027b79b303bdb71d:

  ARM: multi_v7_defconfig: enable DW_WATCHDOG (2016-02-04 13:25:33 -0800)

----------------------------------------------------------------
ARM: SoC fixes for v4.5-rc

The first real batch of fixes for this release cycle, so there are a few more
than usual.

Most of these are fixes and tweaks to board support (DT bugfixes, etc). I've
also picked up a couple of small cleanups that seemed innocent enough that
there was little reason to wait (const/__initconst and Kconfig deps).

Quite a bit of the changes on OMAP were due to fixes to no longer write to
rodata from assembly when ARM_KERNMEM_PERMS was enabled, but there were also
other fixes.

Kirkwood had a bunch of gpio fixes for some boards. OMAP had RTC fixes
on OMAP5, and Nomadik had changes to MMC parameters in DT.

All in all, mostly the usual mix of various fixes.

----------------------------------------------------------------
Adam Ford (2):
      ARM: dts: Fix wl12xx missing clocks that cause hangs
      ARM: dts: LogicPD Torpedo: Revert Duplicative Entries

Alexandre Belloni (2):
      ARM: dts: at91: at91sam9n12ek: fix panel compatible string
      ARM: dts: at91: sama5d4 xplained: properly mux phy interrupt

Amitoj Kaur Chawla (1):
      bus: vexpress-config: Add missing of_node_put

Dave Gerlach (1):
      ARM: dts: AM33xx: Add ti,mbox-send-noirq to wkup_m3 mailbox

Dinh Nguyen (1):
      ARM: multi_v7_defconfig: enable DW_WATCHDOG

Dmitry Lifshitz (6):
      ARM: dts: am57xx: sbc-am57x: fix SB-SOM EEPROM I2C address
      ARM: dts: am57xx: cl-som-am57x: set HOST mode for USB2
      ARM: dts: am57xx: cl-som-am57x: update SPI Flash frequency
      ARM: dts: am57xx: sbc-am57x: fix UART3 pinmux
      ARM: dts: am57xx: cl-som-am57x: fix CPSW EMAC pinmux
      ARM: dts: am57xx: sbc-am57x: correct Eth PHY settings

Felipe Balbi (1):
      ARM: omap2plus_defconfig: enable SPLIT and DWARF4

Geert Uytterhoeven (2):
      ARM: mvebu: kirkwood: Add compatible property to "partitions" node
      ARM: mvebu: ix4-300d: Add compatible property to "partitions" node

Grygorii Strashko (2):
      ARM: dts: am4372: fix irq type for arm twd and global timer
      ARM: dts: am437x: pixcir_tangoc: use correct flags for irq types

H. Nikolaus Schaller (1):
      ARM: dts: omap5-board-common: enable rtc and charging of backup battery

Jon Hunter (1):
      ARM64: tegra: Add chosen node for tegra132 norrin

Keerthy (1):
      ARM: dts: AM4372: Add ti,mbox-send-noirq to wkup_m3 mailbox

Linus Walleij (1):
      ARM: nomadik: fix up SD/MMC DT settings

Masahiro Yamada (5):
      bus: uniphier-system-bus: revive tristate prompt
      ARM: realview: use const and __initconst for smp_operations
      ARM: tango: use const and __initconst for smp_operations
      ARM: tango: use "depends on" instead of "if" after prompt
      ARM: realview: use "depends on" instead of "if" after prompt

Mohamed Jamsheeth Hajanajubudeen (1):
      ARM: dts: at91: sama5d4: fix instance id of DBGU

Neil Armstrong (1):
      ARM: OMAP: Add PWM dmtimer platform data quirks

Nicolas Ferre (2):
      ARM: dts: at91: sama5d2 xplained: add phy address and IRQ for macb0
      ARM: dts: at91: sama5d4 xplained: fix phy0 IRQ type

Olof Johansson (4):
      Merge tag 'at91-fixes' of git://git.kernel.org/.../nferre/linux-at91 into fixes
      Merge tag 'omap-for-v4.5/fixes-rc1' of git://git.kernel.org/.../tmlind/linux-omap into fixes
      Merge tag 'mvebu-fixes-4.5-1' of git://git.infradead.org/linux-mvebu into fixes
      Merge tag 'vexpress-for-v4.5/fixes-rc2' of git://git.kernel.org/.../sudeep.holla/linux into fixes

Robin Murphy (1):
      arm64: dts: Add missing DMA Abort interrupt to Juno

Roger Shimizu (5):
      ARM: dts: kirkwood: gpio pin fixes for linkstation ls-wxl/wsxl
      ARM: dts: kirkwood: gpio pin fixes for linkstation ls-wvl/vl
      ARM: dts: kirkwood: gpio-leds fixes for linkstation ls-wxl/wsxl
      ARM: dts: kirkwood: gpio-leds fixes for linkstation ls-wvl/vl
      ARM: dts: orion5x: gpio pin fixes for linkstation lswtgl

Suman Anna (1):
      ARM: OMAP2+: Remove legacy mailbox device instantiation

Tony Lindgren (8):
      ARM: dts: Fix omap5 PMIC control lines for RTC writes
      ARM: OMAP2+: Fix wait_dll_lock_timed for rodata
      ARM: OMAP2+: Fix l2dis_3630 for rodata
      ARM: OMAP2+: Fix save_secure_ram_context for rodata
      ARM: OMAP2+: Fix l2_inv_api_params for rodata
      ARM: OMAP2+: Fix ppa_zero_params and ppa_por_params for rodata
      ARM: omap2plus_defconfig: Enable ARM_KERNMEM_PERMS and few loadable modules
      Merge branch 'enable-devices' into omap-for-v4.5/fixes

Wenyou Yang (1):
      ARM: dts: at91: sama5d4ek: add phy address and IRQ for macb0

 arch/arm/boot/dts/am33xx.dtsi                    |  1 +
 arch/arm/boot/dts/am4372.dtsi                    |  5 +-
 arch/arm/boot/dts/am437x-gp-evm.dts              |  4 +-
 arch/arm/boot/dts/am43x-epos-evm.dts             |  2 +-
 arch/arm/boot/dts/am57xx-cl-som-am57x.dts        | 12 ++---
 arch/arm/boot/dts/am57xx-sbc-am57x.dts           |  8 ++--
 arch/arm/boot/dts/armada-xp-lenovo-ix4-300d.dts  |  1 +
 arch/arm/boot/dts/at91-sama5d2_xplained.dts      | 12 ++++-
 arch/arm/boot/dts/at91-sama5d4_xplained.dts      |  8 +++-
 arch/arm/boot/dts/at91-sama5d4ek.dts             | 11 +++++
 arch/arm/boot/dts/at91sam9n12ek.dts              |  2 +-
 arch/arm/boot/dts/kirkwood-lswvl.dts             | 25 +++++-----
 arch/arm/boot/dts/kirkwood-lswxl.dts             | 31 ++++++------
 arch/arm/boot/dts/kirkwood-pogoplug-series-4.dts |  1 +
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi       |  9 +---
 arch/arm/boot/dts/omap5-board-common.dtsi        | 33 +++++++++++++
 arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts |  8 ++--
 arch/arm/boot/dts/sama5d4.dtsi                   |  2 +-
 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi       | 37 +++++++-------
 arch/arm/configs/multi_v7_defconfig              |  1 +
 arch/arm/configs/omap2plus_defconfig             | 10 ++++
 arch/arm/mach-omap2/devices.c                    | 28 -----------
 arch/arm/mach-omap2/pdata-quirks.c               | 23 +++++++++
 arch/arm/mach-omap2/sleep34xx.S                  | 61 ++++++++++++------------
 arch/arm/mach-omap2/sleep44xx.S                  | 25 ++++++----
 arch/arm/mach-realview/Kconfig                   |  3 +-
 arch/arm/mach-realview/platsmp-dt.c              |  2 +-
 arch/arm/mach-tango/Kconfig                      |  3 +-
 arch/arm/mach-tango/platsmp.c                    |  2 +-
 arch/arm64/boot/dts/arm/juno-base.dtsi           |  1 +
 arch/arm64/boot/dts/nvidia/tegra132-norrin.dts   |  2 +
 drivers/bus/Kconfig                              |  2 +-
 drivers/bus/vexpress-config.c                    |  4 +-
 33 files changed, 230 insertions(+), 149 deletions(-)


From paul at pwsan.com  Sun Feb  7 14:24:57 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Sun, 7 Feb 2016 22:24:57 +0000 (UTC)
Subject: [PATCH v4 1/3] ARM: hwmod: RTC: Add lock and unlock functions
In-Reply-To: <1454650952-20154-2-git-send-email-lokeshvutla@ti.com>
References: <1454650952-20154-1-git-send-email-lokeshvutla@ti.com>
 <1454650952-20154-2-git-send-email-lokeshvutla@ti.com>
Message-ID: <alpine.DEB.2.02.1602072209460.2182@utopia.booyaka.com>

Hi Lokesh

I apologize for the delay.

A few comments:

On Fri, 5 Feb 2016, Lokesh Vutla wrote:

> RTC IP have kicker feature which prevents spurious writes to its registers.
> In order to write into any of the RTC registers, KICK values has to be
> written to KICK registers.
> Introduce omap_hwmod_rtc_unlock/lock functions, which  writes into these
> KICK registers inorder to lock and unlock RTC registers.
> 
> Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
> ---

...

> +/**
> + * omap_rtc_wait_not_busy - Wait for the RTC BUSY flag
> + * @oh: struct omap_hwmod *
> + *
> + * For updating certain RTC registers, the MPU must wait
> + * for the BUSY status in OMAP_RTC_STATUS_REG to become zero.
> + * Once the BUSY status is zero, there is a 15-?s access

Probably best just to write out "microseconds" or "us" here to avoid the 
high-bit character problem.

> + * period in which the MPU can program.
> + */
> +static void omap_rtc_wait_not_busy(struct omap_hwmod *oh)
> +{
> +	int i;
> +
> +	/* BUSY may stay active for 1/32768 second (~30 usec) */
> +	omap_test_timeout(omap_hwmod_read(oh, OMAP_RTC_STATUS_REG)
> +			  & OMAP_RTC_STATUS_REG, OMAP_RTC_MAX_READY_TIME, i);

This test looks bogus.  Shouldn't it AND the register value with 
OMAP_RTC_STATUS_BUSY?  Right now the code is AND-ing with 0x44, which 
doesn't include the BUSY bit.  So I guess the tests that you mentioned in 
the first message of the series don't cover the BUSY case?

> +	/* now we have ~15 usec to read/write various registers */
> +}
> +
> +/**
> + * omap_hwmod_rtc_unlock - Unlock the Kicker mechanism.
> + * @oh: struct omap_hwmod *
> + *
> + * RTC IP have kicker feature. This prevents spurious writes to its registers.
> + * In order to write into any of the RTC registers, KICK values has te be
> + * written in respective KICK registers. This is needed for hwmod to write into
> + * sysconfig register.
> + */
> +void omap_hwmod_rtc_unlock(struct omap_hwmod *oh)
> +{
> +	local_irq_disable();
> +	omap_rtc_wait_not_busy(oh);
> +	omap_hwmod_write(OMAP_RTC_KICK0_VALUE, oh, OMAP_RTC_KICK0_REG);
> +	omap_hwmod_write(OMAP_RTC_KICK1_VALUE, oh, OMAP_RTC_KICK1_REG);
> +	local_irq_enable();

Finally, could you ask the IP block maintainer to confirm the 
interpretation that, for any STATUS_REG read where the BUSY bit is 0, that 
we are guaranteed to have at least 15 microseconds from that point in time 
to access the IP block?  It appears to be this way from my reading of the 
TRM; but to me, the phrasing is not explicit.  Another interpretation 
could be that the BUSY bit reflects the IP block's current status.  If 
this latter case is true, then to ensure that the IP block accesses 
complete inside the access window, we'll either need to test the BUSY bit 
after the writes to ensure that it is still 0, and otherwise repeat the 
busy test and writes; or we'll need to wait for a 0->1 BUSY transition 
before we wait for a 1->0 BUSY transition.

> +}
> +
> +/**
> + * omap_hwmod_rtc_lock - Lock the Kicker mechanism.
> + * @oh: struct omap_hwmod *
> + *
> + * RTC IP have kicker feature. This prevents spurious writes to its registers.
> + * Once the RTC registers are written, KICK mechanism needs to be locked,
> + * in order to prevent any spurious writes. This function locks back the RTC
> + * registers once hwmod completes its write into sysconfig register.
> + */
> +void omap_hwmod_rtc_lock(struct omap_hwmod *oh)
> +{
> +	local_irq_disable();
> +	omap_rtc_wait_not_busy(oh);
> +	omap_hwmod_write(0x0, oh, OMAP_RTC_KICK0_REG);
> +	omap_hwmod_write(0x0, oh, OMAP_RTC_KICK1_REG);
> +	local_irq_enable();
> +}
> -- 
> 2.1.4
> 


- Paul


From robertcnelson at gmail.com  Sun Feb  7 15:52:51 2016
From: robertcnelson at gmail.com (Robert Nelson)
Date: Sun, 7 Feb 2016 17:52:51 -0600
Subject: [PATCH 1/1 v2] imx6q-wandboard-revb1.dts: use unique machine name
In-Reply-To: <1454760419-4822-1-git-send-email-xypron.glpk@gmx.de>
References: <1454758226-4561-1-git-send-email-xypron.glpk@gmx.de>
 <1454760419-4822-1-git-send-email-xypron.glpk@gmx.de>
Message-ID: <CAOCHtYiHUgcw6Vzdp8EmD_5+d52fhpuj-oSCFwt_3J5xAncCGw@mail.gmail.com>

On Sat, Feb 6, 2016 at 6:06 AM, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> Downstream packages like Debian flash-kernel use
> /proc/device-tree/model
> to determine which dtb file to install.
>
> Hence each dts in the Linux kernel should provide a unique model identifier.
>
> https://lkml.org/lkml/2014/7/8/579 created the new file
> imx6q-wandboard-revb1.dts but used the same model identifier
> as in imx6q-wandboard.dts.
>
> This patch provides a unique model identifier for revision B1 of
> the Wandboard Quad.
>
> v2:
>         correct name of referenced Debian package
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
> ---
>  arch/arm/boot/dts/imx6q-wandboard-revb1.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx6q-wandboard-revb1.dts b/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
> index 20bf3c2..9207d80 100644
> --- a/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
> +++ b/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
> @@ -13,7 +13,7 @@
>  #include "imx6qdl-wandboard-revb1.dtsi"
>
>  / {
> -       model = "Wandboard i.MX6 Quad Board";
> +       model = "Wandboard i.MX6 Quad Board rev B1";

Okay, this seems a little silly....

The wandboard has 5 versions:

solo: imx6dl-wandboard-revb1.dts

model = "Wandboard i.MX6 Dual Lite Board";

dual rev b: imx6dl-wandboard-revb1.dts

model = "Wandboard i.MX6 Dual Lite Board";

dual rev c: imx6dl-wandboard.dts

model = "Wandboard i.MX6 Dual Lite Board";

quad rev b: imx6q-wandboard-revb1.dts
model = "Wandboard i.MX6 Quad Board"; - > model = "Wandboard i.MX6
Quad Board rev B1";

quad rev c: imx6q-wandboard.dts
model = "Wandboard i.MX6 Quad Board";


Do you guys see the issue?  Either we change them "ALL", rev b or rev c...

Or "flash-kernel" needs to learn to copy more then one dtb (in this
case 5 *.dtb's)

PS, u-boot already can boot on all these with the same SPL/u-boot
image and detect which board and load the correct device tree binary..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/


From paul.gortmaker at windriver.com  Sun Feb  7 16:00:43 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Sun, 7 Feb 2016 19:00:43 -0500
Subject: [PATCH 4/5] drivers/pci: make host/pci-keystone-dw.c modular
In-Reply-To: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
References: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
Message-ID: <1454889644-27830-5-git-send-email-paul.gortmaker@windriver.com>

Export the symbols that this driver requires in order for it to
be modular.  In addition to the one use case of a dw_pci sym, it
has many instances of its own ks_dw_pci syms that need exporting
in order to modpost w/o error.

Cc: Murali Karicheri <m-karicheri2 at ti.com>
Cc: Bjorn Helgaas <bhelgaas at google.com>
Cc: Stanimir Varbanov <svarbanov at mm-sol.com>
Cc: Geert Uytterhoeven <geert+renesas at glider.be>
Cc: Thierry Reding <thierry.reding at gmail.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: linux-pci at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
---
 drivers/pci/host/Kconfig           |  2 +-
 drivers/pci/host/pci-keystone-dw.c | 16 +++++++++++++++-
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 75a605426538..b040ad7ba44d 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -69,7 +69,7 @@ config PCIE_SPEAR13XX
 	  Say Y here if you want PCIe support on SPEAr13XX SoCs.
 
 config PCI_KEYSTONE
-	bool "TI Keystone PCIe controller"
+	tristate "TI Keystone PCIe controller"
 	depends on ARCH_KEYSTONE
 	select PCIE_DW
 	select PCIEPORTBUS
diff --git a/drivers/pci/host/pci-keystone-dw.c b/drivers/pci/host/pci-keystone-dw.c
index ed34c9520a02..f1550a8d2e29 100644
--- a/drivers/pci/host/pci-keystone-dw.c
+++ b/drivers/pci/host/pci-keystone-dw.c
@@ -76,6 +76,7 @@ phys_addr_t ks_dw_pcie_get_msi_addr(struct pcie_port *pp)
 
 	return ks_pcie->app.start + MSI_IRQ;
 }
+EXPORT_SYMBOL(ks_dw_pcie_get_msi_addr);
 
 void ks_dw_pcie_handle_msi_irq(struct keystone_pcie *ks_pcie, int offset)
 {
@@ -99,6 +100,7 @@ void ks_dw_pcie_handle_msi_irq(struct keystone_pcie *ks_pcie, int offset)
 		}
 	}
 }
+EXPORT_SYMBOL(ks_dw_pcie_handle_msi_irq);
 
 static void ks_dw_pcie_msi_irq_ack(struct irq_data *d)
 {
@@ -127,6 +129,7 @@ void ks_dw_pcie_msi_set_irq(struct pcie_port *pp, int irq)
 	writel(BIT(bit_pos),
 	       ks_pcie->va_app_base + MSI0_IRQ_ENABLE_SET + (reg_offset << 4));
 }
+EXPORT_SYMBOL(ks_dw_pcie_msi_set_irq);
 
 void ks_dw_pcie_msi_clear_irq(struct pcie_port *pp, int irq)
 {
@@ -137,6 +140,7 @@ void ks_dw_pcie_msi_clear_irq(struct pcie_port *pp, int irq)
 	writel(BIT(bit_pos),
 	       ks_pcie->va_app_base + MSI0_IRQ_ENABLE_CLR + (reg_offset << 4));
 }
+EXPORT_SYMBOL(ks_dw_pcie_msi_clear_irq);
 
 static void ks_dw_pcie_msi_irq_mask(struct irq_data *d)
 {
@@ -220,6 +224,7 @@ int ks_dw_pcie_msi_host_init(struct pcie_port *pp, struct msi_controller *chip)
 
 	return 0;
 }
+EXPORT_SYMBOL(ks_dw_pcie_msi_host_init);
 
 void ks_dw_pcie_enable_legacy_irqs(struct keystone_pcie *ks_pcie)
 {
@@ -228,6 +233,7 @@ void ks_dw_pcie_enable_legacy_irqs(struct keystone_pcie *ks_pcie)
 	for (i = 0; i < MAX_LEGACY_IRQS; i++)
 		writel(0x1, ks_pcie->va_app_base + IRQ_ENABLE_SET + (i << 4));
 }
+EXPORT_SYMBOL(ks_dw_pcie_enable_legacy_irqs);
 
 void ks_dw_pcie_handle_legacy_irq(struct keystone_pcie *ks_pcie, int offset)
 {
@@ -247,6 +253,7 @@ void ks_dw_pcie_handle_legacy_irq(struct keystone_pcie *ks_pcie, int offset)
 	/* EOI the INTx interrupt */
 	writel(offset, ks_pcie->va_app_base + IRQ_EOI);
 }
+EXPORT_SYMBOL(ks_dw_pcie_handle_legacy_irq);
 
 static void ks_dw_pcie_ack_legacy_irq(struct irq_data *d)
 {
@@ -347,6 +354,7 @@ void ks_dw_pcie_setup_rc_app_regs(struct keystone_pcie *ks_pcie)
 	writel(OB_XLAT_EN_VAL | readl(ks_pcie->va_app_base + CMD_STATUS),
 	       ks_pcie->va_app_base + CMD_STATUS);
 }
+EXPORT_SYMBOL(ks_dw_pcie_setup_rc_app_regs);
 
 /**
  * ks_pcie_cfg_setup() - Set up configuration space address for a device
@@ -400,6 +408,7 @@ int ks_dw_pcie_rd_other_conf(struct pcie_port *pp, struct pci_bus *bus,
 
 	return dw_pcie_cfg_read(addr + where, size, val);
 }
+EXPORT_SYMBOL(ks_dw_pcie_rd_other_conf);
 
 int ks_dw_pcie_wr_other_conf(struct pcie_port *pp, struct pci_bus *bus,
 			     unsigned int devfn, int where, int size, u32 val)
@@ -412,6 +421,7 @@ int ks_dw_pcie_wr_other_conf(struct pcie_port *pp, struct pci_bus *bus,
 
 	return dw_pcie_cfg_write(addr + where, size, val);
 }
+EXPORT_SYMBOL(ks_dw_pcie_wr_other_conf);
 
 /**
  * ks_dw_pcie_v3_65_scan_bus() - keystone scan_bus post initialization
@@ -437,6 +447,7 @@ void ks_dw_pcie_v3_65_scan_bus(struct pcie_port *pp)
 	  */
 	writel(ks_pcie->app.start, pp->dbi_base + PCI_BASE_ADDRESS_0);
 }
+EXPORT_SYMBOL(ks_dw_pcie_v3_65_scan_bus);
 
 /**
  * ks_dw_pcie_link_up() - Check if link up
@@ -447,6 +458,7 @@ int ks_dw_pcie_link_up(struct pcie_port *pp)
 
 	return (val & LTSSM_STATE_MASK) == LTSSM_STATE_L0;
 }
+EXPORT_SYMBOL(ks_dw_pcie_link_up);
 
 void ks_dw_pcie_initiate_link_train(struct keystone_pcie *ks_pcie)
 {
@@ -461,6 +473,7 @@ void ks_dw_pcie_initiate_link_train(struct keystone_pcie *ks_pcie)
 	val = readl(ks_pcie->va_app_base + CMD_STATUS);
 	writel(LTSSM_EN_VAL | val,  ks_pcie->va_app_base + CMD_STATUS);
 }
+EXPORT_SYMBOL(ks_dw_pcie_initiate_link_train);
 
 /**
  * ks_dw_pcie_host_init() - initialize host for v3_65 dw hardware
@@ -469,7 +482,7 @@ void ks_dw_pcie_initiate_link_train(struct keystone_pcie *ks_pcie)
  * and call dw_pcie_v3_65_host_init() API to initialize the Keystone
  * PCI host controller.
  */
-int __init ks_dw_pcie_host_init(struct keystone_pcie *ks_pcie,
+int ks_dw_pcie_host_init(struct keystone_pcie *ks_pcie,
 				struct device_node *msi_intc_np)
 {
 	struct pcie_port *pp = &ks_pcie->pp;
@@ -510,3 +523,4 @@ int __init ks_dw_pcie_host_init(struct keystone_pcie *ks_pcie,
 
 	return dw_pcie_host_init(pp);
 }
+EXPORT_SYMBOL(ks_dw_pcie_host_init);
-- 
2.6.1



From paul.gortmaker at windriver.com  Sun Feb  7 16:00:40 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Sun, 7 Feb 2016 19:00:40 -0500
Subject: [PATCH 1/5] ARM: add EXPORT_SYMBOL of hook_fault_code for PCI host
 modularization
In-Reply-To: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
References: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
Message-ID: <1454889644-27830-2-git-send-email-paul.gortmaker@windriver.com>

In a discussion of a previous patch set[1], it was suggested that
modularizing some of the PCI host support would be good to keep
multi platform bzImage sizes smaller.

Two of the files that are candidates for conversion to tristate
from bool are:

drivers/pci/host/pci-imx6.c
drivers/pci/host/pci-keystone.c

However, doing the conversion reveals that they are going to fail
at modpost time since hook_fault_code isn't currently exported.

Since we are now going to export it we also need to remove the
__init tag, as the fcn needs to be present at insmod time.

[1] https://lkml.kernel.org/r/20160108203102.GH5354 at localhost

Cc: Russell King <linux at arm.linux.org.uk>
Cc: Bjorn Helgaas <bhelgaas at google.com>
Cc: Geert Uytterhoeven <geert at linux-m68k.org>
Cc: Thierry Reding <thierry.reding at gmail.com>
Cc: Ley Foon Tan <lftan at altera.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
---
 arch/arm/mm/fault.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index daafcf121ce0..e0696a5ecc9b 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -525,7 +525,7 @@ struct fsr_info {
 #include "fsr-2level.c"
 #endif
 
-void __init
+void
 hook_fault_code(int nr, int (*fn)(unsigned long, unsigned int, struct pt_regs *),
 		int sig, int code, const char *name)
 {
@@ -537,6 +537,7 @@ hook_fault_code(int nr, int (*fn)(unsigned long, unsigned int, struct pt_regs *)
 	fsr_info[nr].code = code;
 	fsr_info[nr].name = name;
 }
+EXPORT_SYMBOL(hook_fault_code);
 
 /*
  * Dispatch a data abort to the relevant handler.
-- 
2.6.1



From paul.gortmaker at windriver.com  Sun Feb  7 16:00:39 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Sun, 7 Feb 2016 19:00:39 -0500
Subject: [PATCH 0/5] Modularize PCI_DW related drivers.
Message-ID: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>

In a recent patch series that aimed to remove code related to module
unload for PCI support that was simply non modular, the discussion
led to people wanting to keep the code and push towards taking the
steps needed to support moving it towards tristate instead[1].

Here, we take step one, which is simply making the Kconfig change
and then dealing with any build fallout or modpost fallout.  What
amounts to essentially a sanity build test.  To be clear, these
have not been runtime validated; that will need to be done by those
with access to real hardware.  However, the changes are not anything
that should disrupt any existing built-in validation, so real world
users should not be impacted by this change.

We start with a smaller family of drivers; those that actively select
PCI_DW, as a nice self contained group to test the waters and see if
everyone is still good with this approach before investing more time
on a wider scale to other pci/host/ code blocks.

As such the drivers here share a dependency on having the same group
of functions exported in order to successfully complete modpost.

In addition, we have to stray outside drivers/pci to add exports
in two places; once for an ARM fault handler, and once for an OF
variable.

The pci-keystone-dw.c instance was handled separately because it
consists of two source files that need their own group of driver
specific exports above and beyond the "shared" ones.

Then we convert the Kconfig for all remaining at once; we could have
done it on a per driver basis for ease of revert if anyone really
objects, but since it would be a one line change, that seemed like
not a real concern.

Build testing was done on the linux-next tree for arm allmodconfig.

[1] https://lkml.kernel.org/r/20160108203102.GH5354 at localhost

-- 

Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Bjorn Helgaas <bhelgaas at google.com>
Cc: devicetree at vger.kernel.org
Cc: Frank Rowand <frowand.list at gmail.com>
Cc: Geert Uytterhoeven <geert at linux-m68k.org>
Cc: Grant Likely <grant.likely at linaro.org>
Cc: Ley Foon Tan <lftan at altera.com>
Cc: Murali Karicheri <m-karicheri2 at ti.com>
Cc: Rob Herring <robh+dt at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Stanimir Varbanov <svarbanov at mm-sol.com>
Cc: Thierry Reding <thierry.reding at gmail.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-arm-msm at vger.kernel.org
Cc: linux-pci at vger.kernel.org


Paul Gortmaker (5):
  ARM: add EXPORT_SYMBOL of hook_fault_code for PCI host modularization
  drivers/of: add EXPORT_SYMBOL to of_irq_count
  drivers/pci: export dw syms enabling board specific PCI code to be
    tristate
  drivers/pci: make host/pci-keystone-dw.c modular
  drivers/pci: make most of the PCI_DW drivers modular

 arch/arm/mm/fault.c                |  3 ++-
 drivers/of/irq.c                   |  1 +
 drivers/pci/host/Kconfig           | 16 ++++++++--------
 drivers/pci/host/pci-keystone-dw.c | 16 +++++++++++++++-
 drivers/pci/host/pcie-designware.c |  7 +++++++
 5 files changed, 33 insertions(+), 10 deletions(-)

-- 
2.6.1



From xypron.glpk at gmx.de  Sun Feb  7 16:25:15 2016
From: xypron.glpk at gmx.de (Heinrich Schuchardt)
Date: Mon, 8 Feb 2016 01:25:15 +0100
Subject: [PATCH 1/1 v2] imx6q-wandboard-revb1.dts: use unique machine name
In-Reply-To: <CAOCHtYiHUgcw6Vzdp8EmD_5+d52fhpuj-oSCFwt_3J5xAncCGw@mail.gmail.com>
References: <1454758226-4561-1-git-send-email-xypron.glpk@gmx.de>
 <1454760419-4822-1-git-send-email-xypron.glpk@gmx.de>
 <CAOCHtYiHUgcw6Vzdp8EmD_5+d52fhpuj-oSCFwt_3J5xAncCGw@mail.gmail.com>
Message-ID: <56B7E06B.2060701@gmx.de>



On 08.02.2016 00:52, Robert Nelson wrote:
> On Sat, Feb 6, 2016 at 6:06 AM, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>> Downstream packages like Debian flash-kernel use
>> /proc/device-tree/model
>> to determine which dtb file to install.
>>
>> Hence each dts in the Linux kernel should provide a unique model identifier.
>>
>> https://lkml.org/lkml/2014/7/8/579 created the new file
>> imx6q-wandboard-revb1.dts but used the same model identifier
>> as in imx6q-wandboard.dts.
>>
>> This patch provides a unique model identifier for revision B1 of
>> the Wandboard Quad.
>>
>> v2:
>>         correct name of referenced Debian package
>>
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
>> ---
>>  arch/arm/boot/dts/imx6q-wandboard-revb1.dts | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/imx6q-wandboard-revb1.dts b/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
>> index 20bf3c2..9207d80 100644
>> --- a/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
>> +++ b/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
>> @@ -13,7 +13,7 @@
>>  #include "imx6qdl-wandboard-revb1.dtsi"
>>
>>  / {
>> -       model = "Wandboard i.MX6 Quad Board";
>> +       model = "Wandboard i.MX6 Quad Board rev B1";
> 
> Okay, this seems a little silly....
> 
> The wandboard has 5 versions:
> 
> solo: imx6dl-wandboard-revb1.dts
> 
> model = "Wandboard i.MX6 Dual Lite Board";
> 
> dual rev b: imx6dl-wandboard-revb1.dts
> 
> model = "Wandboard i.MX6 Dual Lite Board";
> 
> dual rev c: imx6dl-wandboard.dts
> 
> model = "Wandboard i.MX6 Dual Lite Board";
> 
> quad rev b: imx6q-wandboard-revb1.dts
> model = "Wandboard i.MX6 Quad Board"; - > model = "Wandboard i.MX6
> Quad Board rev B1";
> 
> quad rev c: imx6q-wandboard.dts
> model = "Wandboard i.MX6 Quad Board";
> 
> 
> Do you guys see the issue?  Either we change them "ALL", rev b or rev c...
> 
> Or "flash-kernel" needs to learn to copy more then one dtb (in this
> case 5 *.dtb's)
> 
> PS, u-boot already can boot on all these with the same SPL/u-boot
> image and detect which board and load the correct device tree binary..
> 
> Regards,
> 
Hello Robert,

I only see four dts files mentioned in your mail (solo using the same as
dual rev B1).

We do not know if imx6dl-wandboard.dts and imx6q-wandboard.dts
will support future revisions of the boards. So it doesn't make
much sense to mark them as restricted to revision C1.

You are right in that we should add a change to
imx6dl-wandboard-revb1.dts to the same patch.

Best regards

Heinrich Schuchardt


From julian.calaby at gmail.com  Sun Feb  7 16:55:43 2016
From: julian.calaby at gmail.com (Julian Calaby)
Date: Mon, 8 Feb 2016 11:55:43 +1100
Subject: [linux-sunxi] Re: [PATCH 11/11] arm64: dts: add Pine64 support
In-Reply-To: <56B47391.1040709@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-12-git-send-email-andre.przywara@arm.com>
 <20160205090337.GB1139@lukather> <56B47391.1040709@arm.com>
Message-ID: <CAGRGNgWTMVYExfWZceoY2UKVYq=3g6EnhYBqt9GOFk0Yh6j+4g@mail.gmail.com>

Hi Andre,

On Fri, Feb 5, 2016 at 9:04 PM, Andre Przywara <andre.przywara at arm.com> wrote:
> Hi,
>
> On 05/02/16 09:03, Maxime Ripard wrote:
>> Hi,
>>
>> On Mon, Feb 01, 2016 at 05:39:30PM +0000, Andre Przywara wrote:
>>> The Pine64 is a cost-efficient development board based on the
>>> Allwinner A64 SoC.
>>> There are three models: the basic version with Fast Ethernet and
>>> 512 MB of DRAM (Pine64) and two Pine64+ versions, which both
>>> feature Gigabit Ethernet and additional connectors for touchscreens
>>> and a camera. Or as my son put it: "Those are smaller and these are
>>> missing." ;-)
>>> The two Pine64+ models just differ in the amount of DRAM
>>> (1GB vs. 2GB). Since U-Boot will figure out the right size for us and
>>> patches the DT accordingly we just need to provide one DT for the
>>> Pine64+.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>>> ---
>>>  .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>>>  arch/arm64/boot/dts/Makefile                       |  1 +
>>>  arch/arm64/boot/dts/allwinner/Makefile             |  5 ++
>>>  arch/arm64/boot/dts/allwinner/pine64.dts           | 58 +++++++++++++++++
>>>  arch/arm64/boot/dts/allwinner/pine64_common.dtsi   | 76 ++++++++++++++++++++++
>>>  arch/arm64/boot/dts/allwinner/pine64_plus.dts      | 59 +++++++++++++++++
>>>  6 files changed, 200 insertions(+)
>>>  create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
>>>  create mode 100644 arch/arm64/boot/dts/allwinner/pine64.dts
>>>  create mode 100644 arch/arm64/boot/dts/allwinner/pine64_common.dtsi
>>>  create mode 100644 arch/arm64/boot/dts/allwinner/pine64_plus.dts
>>>
>>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>>> index 72e2c5a..0c22fa9 100644
>>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>>> @@ -175,6 +175,7 @@ parade   Parade Technologies Inc.
>>>  pericom     Pericom Technology Inc.
>>>  phytec      PHYTEC Messtechnik GmbH
>>>  picochip    Picochip Ltd
>>> +pine64      Pine64
>>>  plathome    Plat'Home Co., Ltd.
>>>  plda        PLDA
>>>  pixcir  PIXCIR MICROELECTRONICS Co., Ltd
>>
>> Please make a separate patch for this one.
>>
>>> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
>>> index f832b8a..3b7428a 100644
>>> --- a/arch/arm64/boot/dts/Makefile
>>> +++ b/arch/arm64/boot/dts/Makefile
>>> @@ -1,3 +1,4 @@
>>> +dts-dirs += allwinner
>>
>> Could you also add a patch to add this path to MAINTAINERS too?
>>
>>>  dts-dirs += altera
>>>  dts-dirs += amd
>>>  dts-dirs += apm
>>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
>>> new file mode 100644
>>> index 0000000..65f4e24
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>>> @@ -0,0 +1,5 @@
>>> +dtb-$(CONFIG_ARCH_SUNXI) += pine64_plus.dtb pine64.dtb
>>> +
>>> +always              := $(dtb-y)
>>> +subdir-y    := $(dts-dirs)
>>> +clean-files := *.dtb
>>> diff --git a/arch/arm64/boot/dts/allwinner/pine64.dts b/arch/arm64/boot/dts/allwinner/pine64.dts
>>> new file mode 100644
>>> index 0000000..ebea5dd
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/allwinner/pine64.dts
>>> @@ -0,0 +1,58 @@
>>> +/*
>>> + * Copyright (c) 2016 ARM Ltd.
>>> + *
>>> + * This file is dual-licensed: you can use it either under the terms
>>> + * of the GPL or the X11 license, at your option. Note that this dual
>>> + * licensing only applies to this file, and not this project as a
>>> + * whole.
>>> + *
>>> + *  a) This library is free software; you can redistribute it and/or
>>> + *     modify it under the terms of the GNU General Public License as
>>> + *     published by the Free Software Foundation; either version 2 of the
>>> + *     License, or (at your option) any later version.
>>> + *
>>> + *     This library is distributed in the hope that it will be useful,
>>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + *     GNU General Public License for more details.
>>> + *
>>> + * Or, alternatively,
>>> + *
>>> + *  b) Permission is hereby granted, free of charge, to any person
>>> + *     obtaining a copy of this software and associated documentation
>>> + *     files (the "Software"), to deal in the Software without
>>> + *     restriction, including without limitation the rights to use,
>>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>>> + *     sell copies of the Software, and to permit persons to whom the
>>> + *     Software is furnished to do so, subject to the following
>>> + *     conditions:
>>> + *
>>> + *     The above copyright notice and this permission notice shall be
>>> + *     included in all copies or substantial portions of the Software.
>>> + *
>>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>>> + *     OTHER DEALINGS IN THE SOFTWARE.
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +#include "pine64_common.dtsi"
>>> +
>>> +/ {
>>> +    model = "Pine64";
>>> +    compatible = "pine64,pine64", "allwinner,a64", "allwinner,sunxi";
>>> +
>>> +    chosen {
>>> +            stdout-path = "serial0:115200n8";
>>> +    };
>>> +
>>> +    memory {
>>> +            reg = <0x40000000 0x20000000>;
>>> +    };
>>> +};
>>> diff --git a/arch/arm64/boot/dts/allwinner/pine64_common.dtsi b/arch/arm64/boot/dts/allwinner/pine64_common.dtsi
>>> new file mode 100644
>>> index 0000000..d968d76
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/allwinner/pine64_common.dtsi
>>> @@ -0,0 +1,76 @@
>>> +/*
>>> + * Copyright (c) 2016 ARM Ltd.
>>> + *
>>> + * This file is dual-licensed: you can use it either under the terms
>>> + * of the GPL or the X11 license, at your option. Note that this dual
>>> + * licensing only applies to this file, and not this project as a
>>> + * whole.
>>> + *
>>> + *  a) This library is free software; you can redistribute it and/or
>>> + *     modify it under the terms of the GNU General Public License as
>>> + *     published by the Free Software Foundation; either version 2 of the
>>> + *     License, or (at your option) any later version.
>>> + *
>>> + *     This library is distributed in the hope that it will be useful,
>>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + *     GNU General Public License for more details.
>>> + *
>>> + * Or, alternatively,
>>> + *
>>> + *  b) Permission is hereby granted, free of charge, to any person
>>> + *     obtaining a copy of this software and associated documentation
>>> + *     files (the "Software"), to deal in the Software without
>>> + *     restriction, including without limitation the rights to use,
>>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>>> + *     sell copies of the Software, and to permit persons to whom the
>>> + *     Software is furnished to do so, subject to the following
>>> + *     conditions:
>>> + *
>>> + *     The above copyright notice and this permission notice shall be
>>> + *     included in all copies or substantial portions of the Software.
>>> + *
>>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>>> + *     OTHER DEALINGS IN THE SOFTWARE.
>>> + */
>>> +
>>> +#include "a64.dtsi"
>>> +
>>> +&mmc0 {
>>> +    pinctrl-names = "default";
>>> +    pinctrl-0 = <&mmc0_pins>, <&mmc0_default_cd_pin>;
>>> +    vmmc-supply = <&reg_vcc3v3>;
>>> +    cd-gpios = <&pio 5 6 0>;
>>> +    cd-inverted;
>>> +    status = "okay";
>>> +};
>>> +
>>> +&uart0 {
>>> +    pinctrl-names = "default";
>>> +    pinctrl-0 = <&uart0_pins_a>;
>>> +    status = "okay";
>>> +};
>>> +
>>> +&uart2 {
>>> +    pinctrl-names = "default";
>>> +    pinctrl-0 = <&uart2_pins>;
>>> +    status = "okay";
>>> +};
>>> +
>>> +&uart3 {
>>> +    pinctrl-names = "default";
>>> +    pinctrl-0 = <&uart3_pins_a>;
>>> +    status = "okay";
>>> +};
>>> +
>>> +&uart4 {
>>> +    pinctrl-names = "default";
>>> +    pinctrl-0 = <&uart4_pins>;
>>> +    status = "okay";
>>> +};
>>
>> Our policy for boards with "open" pin headers the user can plug
>> anything he wants is that unless the pin is explicitly dedicated to
>> that usage, we simply leave them aside so that we don't enforce
>> anything.
>
> Makes sense, I just wonder what a user is expected to do if she wants to
> use the serial ports?
> Hack the DT?
> Use U-Boot to create those nodes on the fly?
> Use overlays?
> Directly setup serial ports from userland? (thinking of this bloody
> mechanism x86 (used to?) have)

I believe that device tree overlays are the generally recommended method.

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


From xypron.glpk at gmx.de  Sun Feb  7 16:55:08 2016
From: xypron.glpk at gmx.de (Heinrich Schuchardt)
Date: Mon,  8 Feb 2016 01:55:08 +0100
Subject: [PATCH 1/1 v3] ARM: dts: imx6dlq-wandboard-revb1.dts: use unique
 model id
In-Reply-To: <56B7E06B.2060701@gmx.de>
References: <56B7E06B.2060701@gmx.de>
Message-ID: <1454892908-26975-1-git-send-email-xypron.glpk@gmx.de>

Downstream packages like Debian flash-kernel use
/proc/device-tree/model
to determine which dtb file to install.

Hence each dts in the Linux kernel should provide a unique model
identifier.

Commit 8536239e371f ("ARM: dts: Restructure imx6qdl-wandboard.dtsi for new
rev C1 board.")' created new files imx6dl-wandboard-revb1.dts and
imx6q-wandboard-revb1.dts but used the same model identifier as in
imx6dl-wandboard.dts and imx6q-wandboard.dts.

This patch provides unique model identifiers for revision B1 of
the Wandboard Dual and Wandbaord Quad.

The patch leaves imx6dl-wandboard.dts and imx6q-wandboard.dts unchanged
because it is not foreseeable if the same dts will valid for future
board revisions or not. Furthermore we should avoid unnecessary
changes.

v3:
	update imx6dl-wandboard-revb1.dts

v2:
	correct name of referenced Debian package

Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
---
 arch/arm/boot/dts/imx6dl-wandboard-revb1.dts | 2 +-
 arch/arm/boot/dts/imx6q-wandboard-revb1.dts  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl-wandboard-revb1.dts b/arch/arm/boot/dts/imx6dl-wandboard-revb1.dts
index f607d4f..8c314ee 100644
--- a/arch/arm/boot/dts/imx6dl-wandboard-revb1.dts
+++ b/arch/arm/boot/dts/imx6dl-wandboard-revb1.dts
@@ -13,7 +13,7 @@
 #include "imx6qdl-wandboard-revb1.dtsi"
 
 / {
-	model = "Wandboard i.MX6 Dual Lite Board";
+	model = "Wandboard i.MX6 Dual Lite Board rev B1";
 	compatible = "wand,imx6dl-wandboard", "fsl,imx6dl";
 
 	memory {
diff --git a/arch/arm/boot/dts/imx6q-wandboard-revb1.dts b/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
index 20bf3c2..9207d80 100644
--- a/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
+++ b/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
@@ -13,7 +13,7 @@
 #include "imx6qdl-wandboard-revb1.dtsi"
 
 / {
-	model = "Wandboard i.MX6 Quad Board";
+	model = "Wandboard i.MX6 Quad Board rev B1";
 	compatible = "wand,imx6q-wandboard", "fsl,imx6q";
 
 	memory {
-- 
2.7.0



From paul at pwsan.com  Sun Feb  7 17:21:34 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 8 Feb 2016 01:21:34 +0000 (UTC)
Subject: [PATCH] ARM: DRA7: hwmod: Fix OCP2SCP sysconfig
In-Reply-To: <56B2F36C.1070406@ti.com>
References: <1454567491-30499-1-git-send-email-kishon@ti.com>
 <56B2F36C.1070406@ti.com>
Message-ID: <alpine.DEB.2.02.1602080121250.2182@utopia.booyaka.com>

On Thu, 4 Feb 2016, Kishon Vijay Abraham I wrote:

> Hi,
> 
> On Thursday 04 February 2016 12:01 PM, Kishon Vijay Abraham I wrote:
> > OCP2SCP doesn't support smart idle wakeup according to
> > DRA72x_SR1.0_NDA_TRM_vL and DRA75x_DRA74x_SR1.1_NDA_TRM_vW.
> 
> Ignore this patch. I'll re-send the patch with a public TRM link.

OK, I'll wait for the repost.


- Paul


From paul at pwsan.com  Sun Feb  7 17:50:56 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 8 Feb 2016 01:50:56 +0000 (UTC)
Subject: [PATCH v3 1/3] ARM: DRA7: hwmod: Add reset data for PCIe
In-Reply-To: <1452780672-14339-2-git-send-email-kishon@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-2-git-send-email-kishon@ti.com>
Message-ID: <alpine.DEB.2.02.1602080150390.2182@utopia.booyaka.com>

On Thu, 14 Jan 2016, Kishon Vijay Abraham I wrote:

> Add PCIe reset data to PCIe hwmods on DRA7x.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> Signed-off-by: Sekhar Nori <nsekhar at ti.com>
> Reviewed-by: Suman Anna <s-anna at ti.com>

Thanks, queued for v4.6.


- Paul


From afaerber at suse.de  Sun Feb  7 18:17:31 2016
From: afaerber at suse.de (=?UTF-8?q?Andreas=20F=C3=A4rber?=)
Date: Mon,  8 Feb 2016 03:17:31 +0100
Subject: [PATCH v2 02/10] Documentation: devicetree: rockchip: Document GeekBox
In-Reply-To: <1454897859-7601-1-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
Message-ID: <1454897859-7601-3-git-send-email-afaerber@suse.de>

Use "geekbuying,geekbox" compatible string.

Signed-off-by: Andreas F?rber <afaerber at suse.de>
---
 v2: New (Heiko)
 
 Documentation/devicetree/bindings/arm/rockchip.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
index 078c14fcdaaa..f633595b196c 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -87,6 +87,10 @@ Rockchip platforms device tree bindings
 		     "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
 		     "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
 
+- GeekBuying GeekBox:
+    Required root node properties:
+      - compatible = "geekbuying,geekbox", "rockchip,rk3368";
+
 - Rockchip RK3368 evb:
     Required root node properties:
       - compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368";
-- 
2.6.2



From afaerber at suse.de  Sun Feb  7 18:17:29 2016
From: afaerber at suse.de (=?UTF-8?q?Andreas=20F=C3=A4rber?=)
Date: Mon,  8 Feb 2016 03:17:29 +0100
Subject: [PATCH v2 00/10] ARM64: rockchip: Initial GeekBox enablement
Message-ID: <1454897859-7601-1-git-send-email-afaerber@suse.de>

Hello,

This series adds initial support for the RK3368 based GeekBox.

v2 drops the .dtsi for the module, adds some nodes and a Landingship config.

This is pretty much the state demo'ed at FOSDEM 2016.

Regards,
Andreas

Cc: devicetree at vger.kernel.org

Andreas F?rber (10):
  Documentation: devicetree: Add vendor prefix for GeekBuying.com
  Documentation: devicetree: rockchip: Document GeekBox
  ARM64: dts: rockchip: Add GeekBox config
  ARM64: dts: rockchip: Add GMAC to GeekBox
  ARM64: dts: rockchip: Add eMMC to GeekBox
  ARM64: dts: rockchip: Add IR receiver to GeekBox
  ARM64: dts: rockchip: Add power key to GeekBox
  ARM64: dts: rockchip: Add tsadc for GeekBox
  Documentation: devicetree: rockchip: Document Landingship
  ARM64: dts: rockchip: Add Landingship config

 Documentation/devicetree/bindings/arm/rockchip.txt |   9 +
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 arch/arm64/boot/dts/rockchip/Makefile              |   2 +
 .../dts/rockchip/rk3368-geekbox-landingship.dts    |  56 ++++
 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts    | 321 +++++++++++++++++++++
 5 files changed, 389 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-geekbox-landingship.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts

-- 
2.6.2



From afaerber at suse.de  Sun Feb  7 18:17:30 2016
From: afaerber at suse.de (=?UTF-8?q?Andreas=20F=C3=A4rber?=)
Date: Mon,  8 Feb 2016 03:17:30 +0100
Subject: [PATCH v2 01/10] Documentation: devicetree: Add vendor prefix for
 GeekBuying.com
In-Reply-To: <1454897859-7601-1-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
Message-ID: <1454897859-7601-2-git-send-email-afaerber@suse.de>

Use "geekbuying".

Signed-off-by: Andreas F?rber <afaerber at suse.de>
---
 v2: New (Heiko)
 
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 72e2c5a2b327..5e6f97b7af3e 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -87,6 +87,7 @@ fcs	Fairchild Semiconductor
 firefly	Firefly
 focaltech	FocalTech Systems Co.,Ltd
 fsl	Freescale Semiconductor
+geekbuying	GeekBuying
 GEFanuc	GE Fanuc Intelligent Platforms Embedded Systems, Inc.
 gef	GE Fanuc Intelligent Platforms Embedded Systems, Inc.
 geniatech	Geniatech, Inc.
-- 
2.6.2



From afaerber at suse.de  Sun Feb  7 18:17:33 2016
From: afaerber at suse.de (=?UTF-8?q?Andreas=20F=C3=A4rber?=)
Date: Mon,  8 Feb 2016 03:17:33 +0100
Subject: [PATCH v2 04/10] ARM64: dts: rockchip: Add GMAC to GeekBox
In-Reply-To: <1454897859-7601-1-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
Message-ID: <1454897859-7601-5-git-send-email-afaerber@suse.de>

Signed-off-by: Andreas F?rber <afaerber at suse.de>
---
 v2: New
 
 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
index bc91d39758ab..a8dcf3c2b0c1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
@@ -56,6 +56,13 @@
 		reg = <0x0 0x0 0x0 0x80000000>;
 	};
 
+	ext_gmac: gmac-clk {
+		compatible = "fixed-clock";
+		clock-frequency = <125000000>;
+		clock-output-names = "ext_gmac";
+		#clock-cells = <0>;
+	};
+
 	leds: gpio-leds {
 		compatible = "gpio-leds";
 
@@ -82,6 +89,19 @@
 	};
 };
 
+&gmac {
+	status = "okay";
+	phy-supply = <&vcc_lan>;
+	phy-mode = "rgmii";
+	clock_in_out = "input";
+	assigned-clocks = <&cru SCLK_MAC>;
+	assigned-clock-parents = <&ext_gmac>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&rgmii_pins>;
+	tx_delay = <0x30>;
+	rx_delay = <0x10>;
+};
+
 &i2c0 {
 	status = "okay";
 
-- 
2.6.2



From afaerber at suse.de  Sun Feb  7 18:17:32 2016
From: afaerber at suse.de (=?UTF-8?q?Andreas=20F=C3=A4rber?=)
Date: Mon,  8 Feb 2016 03:17:32 +0100
Subject: [PATCH v2 03/10] ARM64: dts: rockchip: Add GeekBox config
In-Reply-To: <1454897859-7601-1-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
Message-ID: <1454897859-7601-4-git-send-email-afaerber@suse.de>

The GeekBox contains an MXM3 module with a Rockchip RK3368 SoC.
Some connectors are available directly on the module.

This adds initial support, namely serial and USB.

Signed-off-by: Andreas F?rber <afaerber at suse.de>
---
 v1 -> v2:
 * Dropped rk3368-geekbox.dtsi. rk3368-geekbox-landingship.dts can
   #include "rk3368-geekbox.dts" just fine, when leaving out /dts-v1/;.
 * Revisited always-on / boot-on for PMIC regulator nodes. (Heiko)
 * Switched pmic-sleep from RK_FUNC_GPIO to RK_FUNC_2. (schematics)
 
 arch/arm64/boot/dts/rockchip/Makefile           |   1 +
 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 245 ++++++++++++++++++++++++
 2 files changed, 246 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index e3f0b5f4ba4e..df37865e8ced 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
 
 always		:= $(dtb-y)
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
new file mode 100644
index 000000000000..bc91d39758ab
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
@@ -0,0 +1,245 @@
+/*
+ * Copyright (c) 2016 Andreas F?rber
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "rk3368.dtsi"
+
+/ {
+	model = "GeekBox";
+	compatible = "geekbuying,geekbox", "rockchip,rk3368";
+
+	chosen {
+		stdout-path = "serial2:115200n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x0 0x0 0x0 0x80000000>;
+	};
+
+	leds: gpio-leds {
+		compatible = "gpio-leds";
+
+		blue {
+			gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
+			label = "geekbox:blue:led";
+			default-state = "on";
+		};
+
+		red {
+			gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
+			label = "geekbox:red:led";
+			default-state = "off";
+		};
+	};
+
+	vcc_sys: vcc-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_sys";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+};
+
+&i2c0 {
+	status = "okay";
+
+	rk808: pmic at 1b {
+		compatible = "rockchip,rk808";
+		reg = <0x1b>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_int>, <&pmic_sleep>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+		rockchip,system-power-controller;
+		vcc1-supply = <&vcc_sys>;
+		vcc2-supply = <&vcc_sys>;
+		vcc3-supply = <&vcc_sys>;
+		vcc4-supply = <&vcc_sys>;
+		vcc6-supply = <&vcc_sys>;
+		vcc7-supply = <&vcc_sys>;
+		vcc8-supply = <&vcc_io>;
+		vcc9-supply = <&vcc_sys>;
+		vcc10-supply = <&vcc_sys>;
+		vcc11-supply = <&vcc_sys>;
+		vcc12-supply = <&vcc_io>;
+		clock-output-names = "xin32k", "rk808-clkout2";
+		#clock-cells = <1>;
+
+		regulators {
+			vdd_cpu: DCDC_REG1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <700000>;
+				regulator-max-microvolt = <1500000>;
+				regulator-name = "vdd_cpu";
+			};
+
+			vdd_log: DCDC_REG2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <700000>;
+				regulator-max-microvolt = <1500000>;
+				regulator-name = "vdd_log";
+			};
+
+			vcc_ddr: DCDC_REG3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vcc_ddr";
+			};
+
+			vcc_io: DCDC_REG4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc_io";
+			};
+
+			vcc18_flash: LDO_REG1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc18_flash";
+			};
+
+			vcc33_lcd: LDO_REG2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc33_lcd";
+			};
+
+			vdd_10: LDO_REG3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1000000>;
+				regulator-max-microvolt = <1000000>;
+				regulator-name = "vdd_10";
+			};
+
+			vcca_18: LDO_REG4 {
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcca_18";
+			};
+
+			vccio_sd: LDO_REG5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vccio_sd";
+			};
+
+			vdd10_lcd: LDO_REG6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1000000>;
+				regulator-max-microvolt = <1000000>;
+				regulator-name = "vdd10_lcd";
+			};
+
+			vcc_18: LDO_REG7 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_18";
+			};
+
+			vcc18_lcd: LDO_REG8 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc18_lcd";
+			};
+
+			vcc_sd: SWITCH_REG1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vcc_sd";
+			};
+
+			vcc_lan: SWITCH_REG2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vcc_lan";
+			};
+		};
+	};
+};
+
+&pinctrl {
+	pmic {
+		pmic_sleep: pmic-sleep {
+			rockchip,pins = <0 0 RK_FUNC_2 &pcfg_pull_none>;
+		};
+
+		pmic_int: pmic-int {
+			rockchip,pins = <0 5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_otg {
+	status = "okay";
+};
+
+&wdt {
+	status = "okay";
+};
-- 
2.6.2



From afaerber at suse.de  Sun Feb  7 18:17:37 2016
From: afaerber at suse.de (=?UTF-8?q?Andreas=20F=C3=A4rber?=)
Date: Mon,  8 Feb 2016 03:17:37 +0100
Subject: [PATCH v2 08/10] ARM64: dts: rockchip: Add tsadc for GeekBox
In-Reply-To: <1454897859-7601-1-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
Message-ID: <1454897859-7601-9-git-send-email-afaerber@suse.de>

Signed-off-by: Andreas F?rber <afaerber at suse.de>
---
 v2: New
 
 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
index fe5aa785cfda..7e518768f8b0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
@@ -298,6 +298,12 @@
 	};
 };
 
+&tsadc {
+	status = "okay";
+	rockchip,hw-tshut-mode = <0>; /* CRU */
+	rockchip,hw-tshut-polarity = <0>; /* low */
+};
+
 &uart2 {
 	status = "okay";
 };
-- 
2.6.2



From afaerber at suse.de  Sun Feb  7 18:17:35 2016
From: afaerber at suse.de (=?UTF-8?q?Andreas=20F=C3=A4rber?=)
Date: Mon,  8 Feb 2016 03:17:35 +0100
Subject: [PATCH v2 06/10] ARM64: dts: rockchip: Add IR receiver to GeekBox
In-Reply-To: <1454897859-7601-1-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
Message-ID: <1454897859-7601-7-git-send-email-afaerber@suse.de>

Signed-off-by: Andreas F?rber <afaerber at suse.de>
---
 v2: New
 
 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
index e4523a74050f..e84383fd6f10 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
@@ -63,6 +63,13 @@
 		#clock-cells = <0>;
 	};
 
+	ir: ir-receiver {
+		compatible = "gpio-ir-receiver";
+		gpios = <&gpio3 30 GPIO_ACTIVE_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ir_int>;
+	};
+
 	leds: gpio-leds {
 		compatible = "gpio-leds";
 
@@ -252,6 +259,12 @@
 };
 
 &pinctrl {
+	ir {
+		ir_int: ir-int {
+			rockchip,pins = <3 30 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
 	pmic {
 		pmic_sleep: pmic-sleep {
 			rockchip,pins = <0 0 RK_FUNC_2 &pcfg_pull_none>;
-- 
2.6.2



From afaerber at suse.de  Sun Feb  7 18:17:36 2016
From: afaerber at suse.de (=?UTF-8?q?Andreas=20F=C3=A4rber?=)
Date: Mon,  8 Feb 2016 03:17:36 +0100
Subject: [PATCH v2 07/10] ARM64: dts: rockchip: Add power key to GeekBox
In-Reply-To: <1454897859-7601-1-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
Message-ID: <1454897859-7601-8-git-send-email-afaerber@suse.de>

Signed-off-by: Andreas F?rber <afaerber at suse.de>
---
 v2: New
 
 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
index e84383fd6f10..fe5aa785cfda 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
@@ -70,6 +70,22 @@
 		pinctrl-0 = <&ir_int>;
 	};
 
+	keys: gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pwr_key>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		button at 0 {
+			reg = <0>;
+			gpio-key,wakeup = <1>;
+			gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+			label = "GPIO Power";
+			linux,code = <116>;
+		};
+	};
+
 	leds: gpio-leds {
 		compatible = "gpio-leds";
 
@@ -265,6 +281,12 @@
 		};
 	};
 
+	keys {
+		pwr_key: pwr-key {
+			rockchip,pins = <0 2 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
 	pmic {
 		pmic_sleep: pmic-sleep {
 			rockchip,pins = <0 0 RK_FUNC_2 &pcfg_pull_none>;
-- 
2.6.2



From afaerber at suse.de  Sun Feb  7 18:17:38 2016
From: afaerber at suse.de (=?UTF-8?q?Andreas=20F=C3=A4rber?=)
Date: Mon,  8 Feb 2016 03:17:38 +0100
Subject: [PATCH v2 09/10] Documentation: devicetree: rockchip: Document
 Landingship
In-Reply-To: <1454897859-7601-1-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
Message-ID: <1454897859-7601-10-git-send-email-afaerber@suse.de>

Use "geekbuying,landingship" compatible string, plus those of GeekBox.

Signed-off-by: Andreas F?rber <afaerber at suse.de>
---
 v2: New
 
 Documentation/devicetree/bindings/arm/rockchip.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
index f633595b196c..c6d95f202591 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -91,6 +91,11 @@ Rockchip platforms device tree bindings
     Required root node properties:
       - compatible = "geekbuying,geekbox", "rockchip,rk3368";
 
+- GeekBuying Landingship:
+    Required root node properties:
+      - compatible = "geekbuying,landingship",
+		     "geekbuying,geekbox", "rockchip,rk3368";
+
 - Rockchip RK3368 evb:
     Required root node properties:
       - compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368";
-- 
2.6.2



From afaerber at suse.de  Sun Feb  7 18:17:34 2016
From: afaerber at suse.de (=?UTF-8?q?Andreas=20F=C3=A4rber?=)
Date: Mon,  8 Feb 2016 03:17:34 +0100
Subject: [PATCH v2 05/10] ARM64: dts: rockchip: Add eMMC to GeekBox
In-Reply-To: <1454897859-7601-1-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
Message-ID: <1454897859-7601-6-git-send-email-afaerber@suse.de>

Signed-off-by: Andreas F?rber <afaerber at suse.de>
---
 v2: New
 
 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
index a8dcf3c2b0c1..e4523a74050f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
@@ -89,6 +89,21 @@
 	};
 };
 
+&emmc {
+	status = "okay";
+	bus-width = <8>;
+	cap-mmc-highspeed;
+	clock-frequency = <150000000>;
+	disable-wp;
+	keep-power-in-suspend;
+	non-removable;
+	num-slots = <1>;
+	vmmc-supply = <&vcc_io>;
+	vqmmc-supply = <&vcc18_flash>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&emmc_clk>, <&emmc_cmd>, <&emmc_bus8>;
+};
+
 &gmac {
 	status = "okay";
 	phy-supply = <&vcc_lan>;
-- 
2.6.2



From afaerber at suse.de  Sun Feb  7 18:17:39 2016
From: afaerber at suse.de (=?UTF-8?q?Andreas=20F=C3=A4rber?=)
Date: Mon,  8 Feb 2016 03:17:39 +0100
Subject: [PATCH v2 10/10] ARM64: dts: rockchip: Add Landingship config
In-Reply-To: <1454897859-7601-1-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
Message-ID: <1454897859-7601-11-git-send-email-afaerber@suse.de>

Signed-off-by: Andreas F?rber <afaerber at suse.de>
---
 v2: New - showcases inclusion of GeekBox module config
 
 arch/arm64/boot/dts/rockchip/Makefile              |  1 +
 .../dts/rockchip/rk3368-geekbox-landingship.dts    | 56 ++++++++++++++++++++++
 2 files changed, 57 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-geekbox-landingship.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index df37865e8ced..201bcd9863ce 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,5 +1,6 @@
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox-landingship.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
 
 always		:= $(dtb-y)
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox-landingship.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox-landingship.dts
new file mode 100644
index 000000000000..e4a117597a0c
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox-landingship.dts
@@ -0,0 +1,56 @@
+/*
+ * Copyright (c) 2016 Andreas F?rber
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "rk3368-geekbox.dts"
+
+/ {
+	model = "GeekBox on Landingship";
+	compatible = "geekbuying,landingship", "geekbuying,geekbox", "rockchip,rk3368";
+};
+
+&i2c1 {
+	status = "okay";
+};
+
+&i2c2 {
+	status = "okay";
+};
-- 
2.6.2



From paul at pwsan.com  Sun Feb  7 18:48:30 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 8 Feb 2016 02:48:30 +0000 (UTC)
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <56B087AD.4000505@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
Message-ID: <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>

On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:

> Paul, what do you think is the best way forward to perform reset?

Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
Those often need special reset handling to ensure that WFI/HLT-like 
instructions are executed after reset.  This special handling ensures that 
the IP blocks' bus initiator interfaces indicate that they are in standby 
to the PRCM - thus allowing power management for the rest of the chip to 
work correctly.

But that doesn't seem to be the case with PCIe - and maybe others - 
possibly some of the MMUs?  So how about just creating a new hwmod flag to 
mark all of the initiator IP blocks that require driver-based special 
handling during _enable() - i.e., most of the processor IP blocks. Then 
for the rest, like PCIe, implement a default behavior in the hwmod code to 
automatically release the IP block's hardreset lines in 
omap_hwmod.c:_enable()?  Something similar to what's enclosed at the 
bottom of this message.  I've annotated what will be needed in the 
OMAP44xx file; similar flags will be needed in any other hwmod data file 
that contains IP blocks with hard reset lines defined.

Either that - or you could write custom reset handlers for all of the 
processor IP blocks that put them into WFI/HLT.

I leave it to you TI folks to write and test the actual patches, since as 
you probably know, I don't have any DRA7xx/AM57xx boards in the testbed.  

As far as reasserting hardreset in *remove(), there's already hwmod code 
to do that in omap_hwmod.c:_shutdown().  I don't recall any more if we 
currently have code in the stack that calls it.  Ideally the device model 
code should call that during or after a .remove() call.


- Paul


---
 arch/arm/mach-omap2/omap_hwmod.c           | 16 +++++++++++-----
 arch/arm/mach-omap2/omap_hwmod.h           | 12 ++++++++++++
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  6 ++++++
 3 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e9f65fec55c0..ab66dd988709 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2077,7 +2077,7 @@ static int _enable_preprogram(struct omap_hwmod *oh)
  */
 static int _enable(struct omap_hwmod *oh)
 {
-	int r;
+	int r, i;
 	int hwsup = 0;
 
 	pr_debug("omap_hwmod: %s: enabling\n", oh->name);
@@ -2109,17 +2109,23 @@ static int _enable(struct omap_hwmod *oh)
 	}
 
 	/*
-	 * If an IP block contains HW reset lines and all of them are
-	 * asserted, we let integration code associated with that
-	 * block handle the enable.  We've received very little
+	 * If an IP block contains HW reset lines, all of them are
+	 * asserted, and the IP block is marked as requiring a custom
+	 * hardreset handler, we let integration code associated with
+	 * that block handle the enable.  We've received very little
 	 * information on what those driver authors need, and until
 	 * detailed information is provided and the driver code is
 	 * posted to the public lists, this is probably the best we
 	 * can do.
 	 */
-	if (_are_all_hardreset_lines_asserted(oh))
+	if ((oh->flags & HWMOD_CUSTOM_HARDRESET) &&
+	    _are_all_hardreset_lines_asserted(oh))
 		return 0;
 
+	/* If the IP block is an initiator, release it from hardreset */
+	for (i = 0; i < oh->rst_lines_cnt; i++)
+		_deassert_hardreset(oh, oh->rst_lines[i].name);
+
 	/* Mux pins for device runtime if populated */
 	if (oh->mux && (!oh->mux->enabled ||
 			((oh->_state == _HWMOD_STATE_IDLE) &&
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 76bce11c85a4..4198829551a4 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -525,6 +525,17 @@ struct omap_hwmod_omap4_prcm {
  *     or idled.
  * HWMOD_OPT_CLKS_NEEDED: The optional clocks are needed for the module to
  *     operate and they need to be handled at the same time as the main_clk.
+ * HWMOD_CUSTOM_HARDRESET: By default, if a hwmod has PRCM hardreset
+ *     lines associated with it (i.e., a populated .rst_lines field in
+ *     the hwmod), the hwmod code will assert the hardreset lines when
+ *     the IP block is initially reset, deassert the hardreset lines
+ *     in _enable(), and reassert them in _shutdown().  If this flag
+ *     is set, the hwmod code will not deassert the hardreset lines in
+ *     _enable(), leaving this responsibility to the driver code.  This flag may
+ *     be needed for processor IP blocks that must be put into a WFI/HLT
+ *     state after reset is deasserted, lest the processor leave its MSTANDBY
+ *     signal deasserted, thus blocking the chip from entering a system-wide
+ *     low power state.
  */
 #define HWMOD_SWSUP_SIDLE			(1 << 0)
 #define HWMOD_SWSUP_MSTANDBY			(1 << 1)
@@ -541,6 +552,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_SWSUP_SIDLE_ACT			(1 << 12)
 #define HWMOD_RECONFIG_IO_CHAIN			(1 << 13)
 #define HWMOD_OPT_CLKS_NEEDED			(1 << 14)
+#define HWMOD_CUSTOM_HARDRESET			(1 << 15)
 
 /*
  * omap_hwmod._int_flags definitions
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index dad871a4cd96..20501f0e3c6c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -553,6 +553,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
 			.modulemode   = MODULEMODE_HWCTRL,
 		},
 	},
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 };
 
 /*
@@ -1433,6 +1434,7 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
 			.modulemode   = MODULEMODE_HWCTRL,
 		},
 	},
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 };
 
 /*
@@ -1517,6 +1519,7 @@ static struct omap_hwmod omap44xx_iva_hwmod = {
 			.modulemode   = MODULEMODE_HWCTRL,
 		},
 	},
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 };
 
 /*
@@ -2115,6 +2118,7 @@ static struct omap_hwmod omap44xx_mmu_ipu_hwmod = {
 			.modulemode   = MODULEMODE_HWCTRL,
 		},
 	},
+	.flags		= HWMOD_CUSTOM_HARDRESET, /* XXX doublecheck */
 };
 
 /* mmu dsp */
@@ -2147,6 +2151,7 @@ static struct omap_hwmod omap44xx_mmu_dsp_hwmod = {
 			.modulemode   = MODULEMODE_HWCTRL,
 		},
 	},
+	.flags		= HWMOD_CUSTOM_HARDRESET, /* XXX doublecheck */
 };
 
 /*
@@ -2299,6 +2304,7 @@ static struct omap_hwmod omap44xx_prm_hwmod = {
 	.class		= &omap44xx_prcm_hwmod_class,
 	.rst_lines	= omap44xx_prm_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_prm_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 };
 
 /*
-- 
2.7.0



From paul at pwsan.com  Sun Feb  7 18:51:06 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 8 Feb 2016 02:51:06 +0000 (UTC)
Subject: OMAP baseline test results for v4.5-rc3
Message-ID: <alpine.DEB.2.02.1602080248360.2182@utopia.booyaka.com>


Here are some basic OMAP test results for Linux v4.5-rc3.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v4.5-rc3/20160207175949/


Test summary
------------

Build: uImage:
    Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only,
		  omap1_defconfig_5912osk_only

Build: uImage+dtb:
    Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone,
		  omap2plus_defconfig/omap4-panda,
		  omap2plus_defconfig/omap4-panda-es,
		  omap2plus_defconfig/omap4-var-stk-om44,
		  omap2plus_defconfig/omap3-evm-37xx,
		  omap2plus_defconfig_n800_only_a/omap2420-n800,
		  omap2plus_defconfig/omap2430-sdp,
		  omap2plus_defconfig/am3517-evm,
		  omap2plus_defconfig/omap3-beagle,
		  omap2plus_defconfig/omap3-beagle-xm,
		  omap2plus_defconfig/omap3-sbc-t3517,
		  omap2plus_defconfig/omap5-uevm,
		  omap2plus_defconfig/omap5-sbc-t54

Build: zImage:
    Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
		  omap2plus_defconfig_n800_only_a,
		  omap2plus_defconfig_n800_multi_omap2xxx,
		  omap2plus_defconfig_2430sdp_only,
		  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
		  omap2plus_defconfig_omap2_4_only,
		  omap2plus_defconfig_omap3_4_only,
		  omap2plus_defconfig_omap5_only,
		  omap2plus_defconfig_dra7xx_only,
		  omap2plus_defconfig_am43xx_only,
		  rmk_omap3430_ldp_oldconfig,
		  rmk_omap3430_ldp_allnoconfig,
		  rmk_omap4430_sdp_oldconfig,
		  rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig

Build warnings from toolchain: uImage:
    (none)

Build warnings from toolchain: uImage+dtb:
    (none)

Build warnings from toolchain: zImage:
    FAIL ( 1/17): multi_v7_defconfig

Boot to userspace:
    FAIL ( 1/18): 2430sdp
    skip ( 3/18): 5912osk, 3517evm, 5430es2sbct54
    Pass (14/18): am335xbonelt, am437xsk, am335xbone, 4430es2panda,
		  4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle,
		  3530es31beagle, 3730beaglexm, 3730es12beaglexm,
		  cmt3517, 5430es2uevm, 2420n800

Kernel warnings during boot to userspace:
    FAIL ( 1/18): cmt3517

PM: chip retention via suspend:
    FAIL ( 7/11): am335xbonelt, 4430es2panda, 4460pandaes,
		  4460varsomom, 37xxevm, 2430sdp, 5430es2uevm
    Pass ( 4/11): 3530es3beagle, 3530es31beagle, 3730beaglexm,
		  3730es12beaglexm

PM: chip retention via dynamic idle:
    FAIL ( 9/11): am335xbonelt, 4430es2panda, 4460pandaes,
		  4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle,
		  2430sdp, 5430es2uevm
    Pass ( 2/11): 3730beaglexm, 3730es12beaglexm

PM: chip off (except CORE, due to errata) via suspend:
    Pass ( 1/ 1): 3730beaglexm

PM: chip off (except CORE, due to errata) via dynamic idle:
    Pass ( 1/ 1): 3730beaglexm

PM: chip off via suspend:
    FAIL ( 2/ 4): 37xxevm, 3530es3beagle
    Pass ( 2/ 4): 3530es31beagle, 3730es12beaglexm

PM: chip off via dynamic idle:
    FAIL ( 3/ 4): 37xxevm, 3530es3beagle, 3530es31beagle
    Pass ( 1/ 4): 3730es12beaglexm

Kernel warnings during PM test:
    (none)

Obsolete Kconfig symbols:
    FAIL ( 3/20): omap1_defconfig, omap2plus_defconfig,
		  multi_v7_defconfig


vmlinux object size
(delta in bytes from test_v4.5-rc2 (36f90b0a2ddd60823fe193a85e60ff1906c2a9b3)):
   text     data      bss    total  kernel
   +797      +64        0     +861  omap1_defconfig
   +761      +64        0     +825  omap1_defconfig_1510innovator_only
   +765      +64        0     +829  omap1_defconfig_5912osk_only
  +7514     +352      +64    +7930  multi_v7_defconfig
  +6486     +416        0    +6902  omap2plus_defconfig
  +6362     +160        0    +6522  omap2plus_defconfig_2430sdp_only
  +2518     +288        0    +2806  omap2plus_defconfig_am33xx_only
  +6610     +288        0    +6898  omap2plus_defconfig_am43xx_only
  +6486     +416        0    +6902  omap2plus_defconfig_cpupm
  +6674     +288        0    +6962  omap2plus_defconfig_dra7xx_only
  +1332     +192        0    +1524  omap2plus_defconfig_n800_multi_omap2xxx
  +1324     +160        0    +1484  omap2plus_defconfig_n800_only_a
  +6678     +416        0    +7094  omap2plus_defconfig_no_pm
  +6614     +256        0    +6870  omap2plus_defconfig_omap2_4_only
  +6546     +384        0    +6930  omap2plus_defconfig_omap3_4_only
  +6610     +256        0    +6866  omap2plus_defconfig_omap5_only
   -204     +224     -148     -128  rmk_omap3430_ldp_allnoconfig
  +4684     +288        0    +4972  rmk_omap3430_ldp_oldconfig
    +20      +64     -276     -192  rmk_omap4430_sdp_allnoconfig
   +396     +160        0     +556  rmk_omap4430_sdp_oldconfig

Boot-time memory difference
(delta in bytes from test_v4.5-rc2 (36f90b0a2ddd60823fe193a85e60ff1906c2a9b3))
  avail  rsrvd   high  freed  board          kconfig
 -1952k  1952k      .   844k  2420n800       omap2plus_defconfig_n800_only_a
 -1784k  1784k      .      .  2430sdp        omap2plus_defconfig
 -1784k  1784k      .   568k  3530es31beagle omap2plus_defconfig
 -1784k  1784k      .   568k  3530es3beagle  omap2plus_defconfig
 -1784k  1784k      .   568k  3730beaglexm   omap2plus_defconfig
 -1784k  1784k      .   568k  3730es12beaglexmomap2plus_defconfig
 -1784k  1784k      .   568k  37xxevm        omap2plus_defconfig
 -1784k  1784k      .   568k  4430es2panda   omap2plus_defconfig
 -1784k  1784k      .   568k  4460pandaes    omap2plus_defconfig
 -1784k  1784k      .   568k  4460varsomom   omap2plus_defconfig
 -1784k  1784k      .   568k  5430es2uevm    omap2plus_defconfig
 -2096k  2096k      .   636k  am335xbone     omap2plus_defconfig_am33xx_only
 -1784k  1784k      .   568k  am335xbonelt   omap2plus_defconfig
 -1784k  1784k      .   568k  am437xsk       omap2plus_defconfig


Troubling.  An extra ~2MB of RAM used on all boards in an -rc series 
release?


From vinod.koul at intel.com  Sun Feb  7 19:11:34 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 8 Feb 2016 08:41:34 +0530
Subject: [PATCH v7 0/9] Fix broken DMAFLUSHP on Rockchips platform
In-Reply-To: <56AF01B6.6030204@gmail.com>
References: <1453460812-8498-1-git-send-email-wxt@rock-chips.com>
 <56AF01B6.6030204@gmail.com>
Message-ID: <20160208031134.GI2531@localhost>

On Mon, Feb 01, 2016 at 02:56:54PM +0800, Caesar Wang wrote:
> Hello Vinod,
> 
> Is there any chance apply the DMA patches?:-)

I was waiting for any ACKs on ARM patches before I merge this series.

> ? 2016?01?22? 19:06, Caesar Wang ??:
> >This series patches are apply on linus master branch.
> >Okay, this series patches verified on my github.
> >(https://github.com/Caesar-github/rockchip/commits/for-dma-tests)
> >
> >Linux version 4.4.0+ (wxt at ubuntu)  (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #14
> >SMP Fri Jan 22 18:13:12 CST 2016
> >
> >The perious version 6 from Shawn.
> >(http://www.spinics.net/lists/dmaengine/msg06606.html)
> >I pick them up to go on upstream since Shawn hasn't much time to track them.
> >----
> >
> >The purpose of the DMAFLUSHP instruction:
> >- Tell the peripheral to clear its status and control registers.
> >- Send a message to the peripheral to resend its level status.
> >
> >There are 3 timings described in PL330 Technical Reference Manual:
> >- Timing 1: Burst request, can work well without DMAFLUSHP.
> >- Timing 2: Single and burst request, DMAC will ignore the single
> >             transfer request. This timing happens if there are single
> >             and burst request.
> >- Timing 3: Single transfers for a burst request, DMAC should signals
> >             datype to request the peripheral to flush the contents of
> >             any control registers. This timing happens if there is
> >             not enough MFIFO to places the burst data.
> >
> >A peripheral may signal a DMA request during the execution of
> >DMAFLUSHP instruction, that cause DMA request being ignored by DMAC.
> >
> >But DMAC and all peripherals on RK3X SoCs DO NOT support DMAFLUSHP.
> >It can't send a message to the peripheral to resend DMA request,
> >and the peripheral can't acknowledge a flush request from DMAC.
> >So all DMA requests should NOT be ignored by DMAC, and DMAC will not
> >notify the peripheral to flush.
> >
> >To fix this problem, we need:
> >- Do NOT execute DMAFLUSHP instruction.
> >- Timing 2 and timing 3 should not happen.
> >
> >Because on RK3X SoCs, there are 6 or below  channels and 32 MFIFO depth
> >for DMAC_BUS, and 8 channels and 64 MFIFO depth for DMAC_PERI, it is
> >impossible to hit the timing 3 if burst length is equal or less than 4.
> >
> >Since the request type signal by the peripheral can only be set by
> >software. We can set Rockchip Soc's GRF_PERIDMAC_CON0[2:1] to select single
> >or burst request, if it is set b01,  all of the peripharals will signal a brust
> >request. So the timing 2 will not happen, too.
> >
> >So DMAC on RK3X can support single or burst transfer, but can't support
> >mixed transfer.
> >
> >Because burst transfer is more efficient than single transfer, this is
> >confirmed by our ASIC team, who strongly suggest to use burst transfer.
> >And this is confirmed by Addy's test on RK3288-Pink2 board, the speed of
> >spi flash burst transfer will increase about two times than single transfer.
> >Also, I have tested dw_mmc with pl330 on RK3188 platform to double confirm
> >the result. That means burst transfer is reansonable.
> >
> >So we need a quirk not to execute DMAFLUSHP instruction and to use burst
> >transfer.
> >
> >Note:
> >- The Rockchip Soc default value of GRF_PERIDMAC_CON0[2:1] is b01. To
> >   support brust transfer, these bits should not be changed in bootloader.
> >
> >Todo:
> >remove the patches releated to i2s, that will send them at later.
> >- https://patchwork.kernel.org/patch/7399581/
> >- https://patchwork.kernel.org/patch/7399671/
> >
> >
> >Changes in v7:
> >- As vinod comments, fix the subsystem name.
> >- modify the subject to be better match.
> >- fix the subsystem.
> >- fix the subject.
> >- fix the subject.
> >
> >Changes in v6:
> >- remove expose quirk and add dma max_burst caps for clients
> >- remove expose quirks and add max_burst for dmaengine
> >- remove quirks and get dma caps in order to limit burst
> >
> >Changes in v5:
> >- add Mark's tag for spi changes
> >- remove unnecessary whitespace change
> >- use switch statement for i2s quirk
> >
> >Changes in v4:
> >- remove spi & i2s dts changes and query quirk from dmaengine API
> >   suggeseted by Mark.
> >- fix typo
> >- Add dmaengine_get_quirk hook and implement it for pl330
> >
> >Changes in v3:
> >- add Sunny's tag
> >- add more rockchip drivers' changes in this patchset
> >- add Reviewed-by: Sonny Rao <sonnyrao at chromium.org>
> >- add Reviewed-by: Sonny Rao <sonnyrao at chromium.org>
> >- add Reviewed-by: Sonny Rao <sonnyrao at chromium.org>
> >
> >Changes in v2:
> >- amend the author
> >- reorder the patches suggested by Doug
> >- add Reviewed-by: Doug Anderson <dianders at chromium.org> for
> >   rk3288.dtsi patch and arm-pl330.txt patch
> >- add Reviewed-by: Doug Anderson <dianders at chromium.org>
> >- amend the author
> >- fix Olof's mail address
> >- amend the author
> >- add Reviewed-by: Doug Anderson <dianders at chromium.org>
> >- amend Olof's mail address
> >
> >Changes in v1:
> >- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
> >   by Krzysztof.
> >- add From original author.
> >- remove Sunny's tag
> >- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
> >   by Krzysztof.
> >- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
> >   by Krzysztof.
> >- remove Sunny's tag
> >- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
> >   by Krzysztof.
> >   - remove Sunny's tag
> >- rename broken-no-flushp to "arm,pl330-broken-no-flushp" suggested
> >   by Krzysztof.
> >
> >Addy Ke (3):
> >   dmaengine: pl330: add quirk for broken no flushp
> >   ARM: dts: Add arm, pl330-broken-no-flushp quirk for rk3288 platform
> >   spi: rockchip: modify DMA max burst to 1
> >
> >Boojin Kim (1):
> >   dmaengine: pl330: support burst mode for dev-to-mem and mem-to-dev
> >     transmit
> >
> >Caesar Wang (1):
> >   ARM: dts: add pl330-broken-no-flushp quirk for rk3036 SoCs
> >
> >Shawn Lin (4):
> >   dt/bindings: arm-pl330: add description of arm, pl330-broken-no-flushp
> >   ARM: dts: Add arm, pl330-broken-no-flushp quirk for rk3xxx platform
> >   dmaengine: core: expose max burst capability to clients
> >   dmaengine: pl330: add max burst for dmaengine
> >
> >  .../devicetree/bindings/dma/arm-pl330.txt          |   1 +
> >  arch/arm/boot/dts/rk3036.dtsi                      |   1 +
> >  arch/arm/boot/dts/rk3288.dtsi                      |   3 +
> >  arch/arm/boot/dts/rk3xxx.dtsi                      |   3 +
> >  drivers/dma/dmaengine.c                            |   1 +
> >  drivers/dma/pl330.c                                | 106 +++++++++++++++------
> >  drivers/spi/spi-rockchip.c                         |  12 ++-
> >  include/linux/dmaengine.h                          |   4 +
> >  8 files changed, 99 insertions(+), 32 deletions(-)
> >
> 
> 
> -- 
> Thanks,
> Caesar
> 

-- 
~Vinod


From vinod.koul at intel.com  Sun Feb  7 19:13:24 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 8 Feb 2016 08:43:24 +0530
Subject: [PATCH v4] dmaengine: edma: fix residue race for cyclic
In-Reply-To: <87k2mu2e16.fsf@linutronix.de>
References: <87k2mu2e16.fsf@linutronix.de>
Message-ID: <20160208031324.GJ2531@localhost>

On Thu, Jan 28, 2016 at 11:29:08AM +0100, John Ogness wrote:
> When retrieving the residue value, the SRC/DST fields of the
> active PaRAM are read to determine the current position of
> the DMA engine. However, the AM335x Technical Reference Manual
> states:
> 
>   11.3.3.6 Parameter Set Updates
> 
>   After the TR is read from the PaRAM (and is in the process
>   of being submitted to the EDMA3TC), the following fields are
>   updated as needed: ... SRC DST
> 
> This means SRC/DST is incremented even though the DMA transfer
> may not have started yet or is in progress. Thus if the reader
> of the residue accesses the DMA buffer too quickly, the CPU is
> misinformed about the data that has been successfully processed.
> 
> The CCSTAT.ACTV register is a boolean that is set if any TR is
> being processed by either the EMDA3CC or EDMA3TC. By polling
> this register it is possible to ensure that the residue value
> returned is valid for immediate processing. However, since the
> DMA engine may be active, polling may never hit a moment where
> no TR is being processed. To handle this, the SRC/DST is also
> polled to see if it changes. And as a last resort, a max loop
> count for the busy waiting exists to avoid an infinite loop.

Applied, thanks

-- 
~Vinod


From vinod.koul at intel.com  Sun Feb  7 19:14:03 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 8 Feb 2016 08:44:03 +0530
Subject: [PATCH 1/6] dma: enable mxs-dma for imx6ul
In-Reply-To: <20160202062314.GD8307@tiger>
References: <1453294626-17608-1-git-send-email-LW@KARO-electronics.de>
 <1453294626-17608-2-git-send-email-LW@KARO-electronics.de>
 <20160125121043.GJ11130@localhost> <20160202062314.GD8307@tiger>
Message-ID: <20160208031403.GK2531@localhost>

On Tue, Feb 02, 2016 at 02:23:16PM +0800, Shawn Guo wrote:
> On Mon, Jan 25, 2016 at 05:40:43PM +0530, Vinod Koul wrote:
> > On Wed, Jan 20, 2016 at 01:57:01PM +0100, Lothar Wa?mann wrote:
> > > The mxs-dma unit is also available on i.MX6UL. Make it possible to
> > > select it in Kconfig.
> > 
> > It should be dmaengine:xxx
> > 
> > With that
> > 
> > Acked-by: Vinod Koul <vinod.koul at intel.com>
> 
> I think this can go separately via dma tree.

Okay, pls resend :)

-- 
~Vinod


From gregkh at linuxfoundation.org  Sun Feb  7 20:03:23 2016
From: gregkh at linuxfoundation.org (Greg KH)
Date: Sun, 7 Feb 2016 20:03:23 -0800
Subject: [PATCH 1/2] Staging: rts5208: Cleanup rtsx_transport.c
In-Reply-To: <1453775248-15965-2-git-send-email-shaun.ren@linux.com>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
 <1453775248-15965-2-git-send-email-shaun.ren@linux.com>
Message-ID: <20160208040323.GA11625@kroah.com>

On Mon, Jan 25, 2016 at 06:27:27PM -0800, Shaun Ren wrote:
> This patch fixes coding style issues in rtsx_transport.c.
> 
> Signed-off-by: Shaun Ren <shaun.ren at linux.com>
> ---
>  drivers/staging/rts5208/rtsx_transport.c | 115 +++++++++++++++++--------------
>  1 file changed, 65 insertions(+), 50 deletions(-)

What coding style issues?  Please be specific, and only do one type of
cleanup per patch, otherwise it's hard to review them.

thanks,

greg k-h


From gregkh at linuxfoundation.org  Sun Feb  7 20:03:41 2016
From: gregkh at linuxfoundation.org (Greg KH)
Date: Sun, 7 Feb 2016 20:03:41 -0800
Subject: [PATCH 2/2] Staging: rts5208: Add missing dma_mapping_error
In-Reply-To: <1453775248-15965-3-git-send-email-shaun.ren@linux.com>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
 <1453775248-15965-3-git-send-email-shaun.ren@linux.com>
Message-ID: <20160208040341.GB11625@kroah.com>

On Mon, Jan 25, 2016 at 06:27:28PM -0800, Shaun Ren wrote:
> Signed-off-by: Shaun Ren <shaun.ren at linux.com>
> ---

I can't take a patch without a changelog entry, sorry.



From peter at hurleysoftware.com  Sun Feb  7 20:22:20 2016
From: peter at hurleysoftware.com (Peter Hurley)
Date: Sun, 7 Feb 2016 20:22:20 -0800
Subject: [PATCH] tty: serial: meson: Implement earlycon support
In-Reply-To: <1454878635-24396-1-git-send-email-afaerber@suse.de>
References: <1454878635-24396-1-git-send-email-afaerber@suse.de>
Message-ID: <56B817FC.4000604@hurleysoftware.com>

Hi Andreas,

On 02/07/2016 12:57 PM, Andreas F?rber wrote:
> Reuse the existing console write implementation for implementing
> DT-based and command-line-based earlycon support.
> 
> Signed-off-by: Andreas F?rber <afaerber at suse.de>
> ---
>  Documentation/kernel-parameters.txt |  6 ++++++
>  drivers/tty/serial/meson_uart.c     | 13 +++++++++++++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 602065c..90801ac 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1030,6 +1030,12 @@ Such letter suffixes can also be entirely omitted.
>  			the driver will use only 32-bit accessors to read/write
>  			the device registers.
>  
> +		meson_serial,<addr>
> +			Start an early, polled-mode console on a meson serial
> +			port at the specified address. The serial port must
> +			already be setup and configured. Options are not yet
> +			supported.
> +
>  		msm_serial,<addr>
>  			Start an early, polled-mode console on an msm serial
>  			port at the specified address. The serial port
> diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
> index b12a37b..6f89567 100644
> --- a/drivers/tty/serial/meson_uart.c
> +++ b/drivers/tty/serial/meson_uart.c
> @@ -548,6 +548,19 @@ static int __init meson_serial_console_init(void)
>  }
>  console_initcall(meson_serial_console_init);
>  
> +static int __init
> +meson_serial_early_console_setup(struct earlycon_device *device, const char *opt)
> +{
> +	if (!device->port.membase)
> +		return -ENODEV;
> +
> +	device->con->write = meson_serial_console_write;

meson_serial_console_write() is not appropriate for earlycon; it assumes the
earlycon port is the same as the driver port (it isn't).


> +	return 0;
> +}
> +EARLYCON_DECLARE(meson_serial, meson_serial_early_console_setup);
> +OF_EARLYCON_DECLARE(meson_serial, "amlogic,meson-uart",
> +		    meson_serial_early_console_setup);

With today's linux-next (or Greg's tty-next tree), it is no longer necessary to
declare separate earlycon's when you want both; OF_EARLYCON_DECLARE() declares
both a devicetree-enabled earlycon and automatically provides for a command line
earlycon of the same name.

Regards,
Peter Hurley

> +
>  #define MESON_SERIAL_CONSOLE	(&meson_serial_console)
>  #else
>  #define MESON_SERIAL_CONSOLE	NULL
> 



From yamada.masahiro at socionext.com  Sun Feb  7 21:04:58 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon,  8 Feb 2016 14:04:58 +0900
Subject: [PATCH 1/2] ARM: remove bzImage target
Message-ID: <1454907899-32101-1-git-send-email-yamada.masahiro@socionext.com>

bzImage has been just an alias for zImage for more than a decade.
It would not hurt to delete it.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/Makefile | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 46fb1ca..d6d453f 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -312,13 +312,10 @@ boot := arch/arm/boot
 archprepare:
 	$(Q)$(MAKE) $(build)=arch/arm/tools include/generated/mach-types.h
 
-# Convert bzImage to zImage
-bzImage: zImage
-
 BOOT_TARGETS	= zImage Image xipImage bootpImage uImage
 INSTALL_TARGETS	= zinstall uinstall install
 
-PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += $(BOOT_TARGETS) $(INSTALL_TARGETS)
 
 bootpImage uImage: zImage
 zImage: Image
-- 
1.9.1



From yamada.masahiro at socionext.com  Sun Feb  7 21:04:59 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon,  8 Feb 2016 14:04:59 +0900
Subject: [PATCH 2/2] ARM: descend into arch/arm/boot only once to generate
 boot images
In-Reply-To: <1454907899-32101-1-git-send-email-yamada.masahiro@socionext.com>
References: <1454907899-32101-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1454907899-32101-2-git-send-email-yamada.masahiro@socionext.com>

Commit 3939f3345050 ("ARM: 8418/1: add boot image dependencies to not
generate invalid images") fixed bad images generation in the parallel
building, but it is not efficient to descend into arch/arm/boot over
and over again.  It is also clumsy to display the same log message
"Kernel: arch/arm/boot/Image is ready" a couple of times.

  $ make ARCH=arm UIMAGE_LOADADDR=0x80208000 all uImage
      [snip]
    Kernel: arch/arm/boot/Image is ready
    Kernel: arch/arm/boot/Image is ready
    Kernel: arch/arm/boot/zImage is ready
    Building modules, stage 2.
    MODPOST 279 modules
    Kernel: arch/arm/boot/Image is ready
    Kernel: arch/arm/boot/zImage is ready
    UIMAGE  arch/arm/boot/uImage
  Image Name:   Linux-4.5.0-rc3
  Created:      Mon Feb  8 13:22:53 2016
  Image Type:   ARM Linux Kernel Image (uncompressed)
  Data Size:    6768768 Bytes = 6610.12 kB = 6.46 MB
  Load Address: 80208000
  Entry Point:  80208000
    Image arch/arm/boot/uImage is ready

This commit allows arch/arm/boot/Makefile to build boot images at once
instead of generating them one by one.  Of course, it works correctly
also in parallel building.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/Makefile | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index d6d453f..6db669e 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -315,13 +315,17 @@ archprepare:
 BOOT_TARGETS	= zImage Image xipImage bootpImage uImage
 INSTALL_TARGETS	= zinstall uinstall install
 
-PHONY += $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += $(BOOT_TARGETS) $(INSTALL_TARGETS) __build_images
 
-bootpImage uImage: zImage
-zImage: Image
+$(BOOT_TARGETS): __build_images
+	@:
 
-$(BOOT_TARGETS): vmlinux
-	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
+__build_images: vmlinux
+	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) \
+	$(addprefix $(boot)/,
+		$(sort $(filter $(BOOT_TARGETS),$(MAKECMDGOALS)) \
+			$(if $(filter all,$(MAKECMDGOALS)), $(KBUILD_IMAGE)) \
+			$(if $(MAKECMDGOALS),,$(KBUILD_IMAGE))))
 
 $(INSTALL_TARGETS):
 	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
-- 
1.9.1



From anup.patel at broadcom.com  Sun Feb  7 21:17:28 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Mon,  8 Feb 2016 10:47:28 +0530
Subject: [PATCH v2 0/4] iommu/arm-smmu: misc fixes for SMMUv1/SMMUv2
Message-ID: <1454908652-15317-1-git-send-email-anup.patel@broadcom.com>

The intention behind this patchset is to allow usage of IOMMU based
DMA mappings for 32bit devices. It is based on '4.5-rc3' tag of linux
mainline tree and Robin's SMMU patchset "[PATCH 0/4] Miscellaneous
ARM SMMU patches".

This patchset and its dependent patches are available in smmu_v2
branch of https://github.com/Broadcom/arm64-linux.git

All patches have been tested on Broadcom SoCs having SMMU-500.

Anup Patel (3):
  iommu/arm-smmu: Invoke DT probe from arm_smmu_of_setup()
  of: iommu: Increment DT node refcount in of_iommu_set_ops()
  iommu/arm-smmu: Add stub of_xlate() operation in SMMUv1/SMMUv2 driver

Sricharan R (1):
  iommu/arm-smmu: Init driver using IOMMU_OF_DECLARE

 drivers/iommu/arm-smmu.c | 52 ++++++++++++++++++++++++++++++++++++------------
 drivers/iommu/of_iommu.c |  1 +
 2 files changed, 40 insertions(+), 13 deletions(-)

-- 
1.9.1



From anup.patel at broadcom.com  Sun Feb  7 21:17:29 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Mon,  8 Feb 2016 10:47:29 +0530
Subject: [PATCH v2 1/4] iommu/arm-smmu: Init driver using IOMMU_OF_DECLARE
In-Reply-To: <1454908652-15317-1-git-send-email-anup.patel@broadcom.com>
References: <1454908652-15317-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <1454908652-15317-2-git-send-email-anup.patel@broadcom.com>

From: Sricharan R <sricharan at codeaurora.org>

This patch uses IOMMU_OF_DECLARE to register the driver
and the iommu_ops. So when master devices of the iommu are
registered, of_xlate callback can be used to add the master
configurations to the smmu driver.

Signed-off-by: Sricharan R <sricharan at codeaurora.org>
Signed-off-by: Anup Patel <anup.patel at broadcom.com>
Tested-by: Anup Patel <anup.patel at broadcom.com>
---
 drivers/iommu/arm-smmu.c | 35 ++++++++++++++++++++++-------------
 1 file changed, 22 insertions(+), 13 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index bf1895c..2c8f871 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -39,6 +39,7 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
+#include <linux/of_iommu.h>
 #include <linux/pci.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
@@ -265,6 +266,8 @@
 #define FSYNR0_WNR			(1 << 4)
 
 static int force_stage;
+static bool init_done;
+
 module_param_named(force_stage, force_stage, int, S_IRUGO);
 MODULE_PARM_DESC(force_stage,
 	"Force SMMU mappings to be installed at a particular stage of translation. A value of '1' or '2' forces the corresponding stage. All other values are ignored (i.e. no stage is forced). Note that selecting a specific stage will disable support for nested translation.");
@@ -1926,20 +1929,8 @@ static struct platform_driver arm_smmu_driver = {
 
 static int __init arm_smmu_init(void)
 {
-	struct device_node *np;
 	int ret;
 
-	/*
-	 * Play nice with systems that don't have an ARM SMMU by checking that
-	 * an ARM SMMU exists in the system before proceeding with the driver
-	 * and IOMMU bus operation registration.
-	 */
-	np = of_find_matching_node(NULL, arm_smmu_of_match);
-	if (!np)
-		return 0;
-
-	of_node_put(np);
-
 	ret = platform_driver_register(&arm_smmu_driver);
 	if (ret)
 		return ret;
@@ -1958,15 +1949,33 @@ static int __init arm_smmu_init(void)
 		bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
 #endif
 
+	init_done = true;
+
 	return 0;
 }
 
+static int __init arm_smmu_of_setup(struct device_node *np)
+{
+
+	if (!init_done)
+		arm_smmu_init();
+
+	of_iommu_set_ops(np, &arm_smmu_ops);
+
+	return 0;
+}
+
+IOMMU_OF_DECLARE(arm_smmu_v1, "arm,smmu-v1", arm_smmu_of_setup);
+IOMMU_OF_DECLARE(arm_smmu_v2, "arm,smmu-v2", arm_smmu_of_setup);
+IOMMU_OF_DECLARE(arm_smmu_400, "arm,mmu-400", arm_smmu_of_setup);
+IOMMU_OF_DECLARE(arm_smmu_401, "arm,mmu-401", arm_smmu_of_setup);
+IOMMU_OF_DECLARE(arm_smmu_500, "arm,mmu-500", arm_smmu_of_setup);
+
 static void __exit arm_smmu_exit(void)
 {
 	return platform_driver_unregister(&arm_smmu_driver);
 }
 
-subsys_initcall(arm_smmu_init);
 module_exit(arm_smmu_exit);
 
 MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
-- 
1.9.1



From anup.patel at broadcom.com  Sun Feb  7 21:17:30 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Mon,  8 Feb 2016 10:47:30 +0530
Subject: [PATCH v2 2/4] iommu/arm-smmu: Invoke DT probe from
 arm_smmu_of_setup()
In-Reply-To: <1454908652-15317-1-git-send-email-anup.patel@broadcom.com>
References: <1454908652-15317-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <1454908652-15317-3-git-send-email-anup.patel@broadcom.com>

The SMMUv1/SMMUv2 driver is initialized very early using the
IOMMU_OF_DECLARE() but the actual platform device is probed
via normal DT probing.

This patch uses of_platform_device_create() from arm_smmu_of_setup()
to ensure that SMMU platform device is probed immediately.

Signed-off-by: Anup Patel <anup.patel at broadcom.com>
---
 drivers/iommu/arm-smmu.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 2c8f871..02cd67d 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -40,6 +40,7 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_iommu.h>
+#include <linux/of_platform.h>
 #include <linux/pci.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
@@ -1956,10 +1957,15 @@ static int __init arm_smmu_init(void)
 
 static int __init arm_smmu_of_setup(struct device_node *np)
 {
+	struct platform_device *pdev;
 
 	if (!init_done)
 		arm_smmu_init();
 
+	pdev = of_platform_device_create(np, NULL, NULL);
+	if (IS_ERR(pdev))
+		return PTR_ERR(pdev);
+
 	of_iommu_set_ops(np, &arm_smmu_ops);
 
 	return 0;
-- 
1.9.1



From anup.patel at broadcom.com  Sun Feb  7 21:17:31 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Mon,  8 Feb 2016 10:47:31 +0530
Subject: [PATCH v2 3/4] of: iommu: Increment DT node refcount in
 of_iommu_set_ops()
In-Reply-To: <1454908652-15317-1-git-send-email-anup.patel@broadcom.com>
References: <1454908652-15317-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <1454908652-15317-4-git-send-email-anup.patel@broadcom.com>

We are saving pointer to iommu DT node in of_iommu_set_ops()
hence we should increment DT node ref count.

Signed-off-by: Anup Patel <anup.patel at broadcom.com>
Reviewed-by: Ray Jui <rjui at broadcom.com>
Reviewed-by: Scott Branden <sbranden at broadcom.com>
Reviewed-by: Robin Murphy <Robin.Murphy at arm.com>
---
 drivers/iommu/of_iommu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 60ba238..5fea665 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -110,6 +110,7 @@ void of_iommu_set_ops(struct device_node *np, struct iommu_ops *ops)
 	if (WARN_ON(!iommu))
 		return;
 
+	of_node_get(np);
 	INIT_LIST_HEAD(&iommu->list);
 	iommu->np = np;
 	iommu->ops = ops;
-- 
1.9.1



From anup.patel at broadcom.com  Sun Feb  7 21:17:32 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Mon,  8 Feb 2016 10:47:32 +0530
Subject: [PATCH v2 4/4] iommu/arm-smmu: Add stub of_xlate() operation in
 SMMUv1/SMMUv2 driver
In-Reply-To: <1454908652-15317-1-git-send-email-anup.patel@broadcom.com>
References: <1454908652-15317-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <1454908652-15317-5-git-send-email-anup.patel@broadcom.com>

To allow use of large memory (> 4Gb) with 32bit devices we need to use
IOMMU based DMA mappings for such 32bit devices. The IOMMU dt-bindings
allows us do this by specifying 'iommus' attribute in 32bit device DT
node. Unfortunately, specifying 'iommus' attribute does not work with
current SMMUv1/SMMUv2 driver because it requires of_xlate() operation
to be implemented by the driver.

This patch adds a stub implementation of of_xlate() in SMMUv1/SMMUv2
driver to allow usage of 'iommus' attribute in DT for 32bit devices.

Signed-off-by: Anup Patel <anup.patel at broadcom.com>
Reviewed-by: Ray Jui <rjui at broadcom.com>
Reviewed-by: Scott Branden <sbranden at broadcom.com>
---
 drivers/iommu/arm-smmu.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 02cd67d..8e090d8 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1398,6 +1398,16 @@ static int arm_smmu_init_platform_device(struct device *dev,
 	return 0;
 }
 
+int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
+{
+	/*
+	 * Nothing to do here because SMMU is already aware of all
+	 * MMU masters and their stream IDs using mmu-master attibute
+	 * SMMU DT node.
+	 */
+	return 0;
+}
+
 static int arm_smmu_add_device(struct device *dev)
 {
 	struct iommu_group *group;
@@ -1495,6 +1505,7 @@ static struct iommu_ops arm_smmu_ops = {
 	.unmap			= arm_smmu_unmap,
 	.map_sg			= default_iommu_map_sg,
 	.iova_to_phys		= arm_smmu_iova_to_phys,
+	.of_xlate		= arm_smmu_of_xlate,
 	.add_device		= arm_smmu_add_device,
 	.remove_device		= arm_smmu_remove_device,
 	.device_group		= arm_smmu_device_group,
-- 
1.9.1



From yamada.masahiro at socionext.com  Sun Feb  7 22:17:12 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon,  8 Feb 2016 15:17:12 +0900
Subject: [PATCH] ARM: mvebu: add missing of_node_put()
Message-ID: <1454912232-13169-1-git-send-email-yamada.masahiro@socionext.com>

This node pointer is returned by of_find_compatible_node() in this
function.  It should be put before exitting this function.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/mach-mvebu/platsmp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index f9597b7..46c742d 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -140,6 +140,7 @@ static void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
 		panic("Cannot find 'marvell,bootrom' compatible node");
 
 	err = of_address_to_resource(node, 0, &res);
+	of_node_put(node);
 	if (err < 0)
 		panic("Cannot get 'bootrom' node address");
 
-- 
1.9.1



From yamada.masahiro at socionext.com  Sun Feb  7 22:41:26 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon,  8 Feb 2016 15:41:26 +0900
Subject: [PATCH v2 1/2] ARM: remove bzImage target
Message-ID: <1454913687-9325-1-git-send-email-yamada.masahiro@socionext.com>

bzImage has been just an alias for zImage for more than a decade.
It would not hurt to delete it.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

Changes in v2: None

 arch/arm/Makefile | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 46fb1ca..d6d453f 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -312,13 +312,10 @@ boot := arch/arm/boot
 archprepare:
 	$(Q)$(MAKE) $(build)=arch/arm/tools include/generated/mach-types.h
 
-# Convert bzImage to zImage
-bzImage: zImage
-
 BOOT_TARGETS	= zImage Image xipImage bootpImage uImage
 INSTALL_TARGETS	= zinstall uinstall install
 
-PHONY += bzImage $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += $(BOOT_TARGETS) $(INSTALL_TARGETS)
 
 bootpImage uImage: zImage
 zImage: Image
-- 
1.9.1



From yamada.masahiro at socionext.com  Sun Feb  7 22:41:27 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon,  8 Feb 2016 15:41:27 +0900
Subject: [PATCH v2 2/2] ARM: descend into arch/arm/boot only once to generate
 boot images
In-Reply-To: <1454913687-9325-1-git-send-email-yamada.masahiro@socionext.com>
References: <1454913687-9325-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1454913687-9325-2-git-send-email-yamada.masahiro@socionext.com>

Commit 3939f3345050 ("ARM: 8418/1: add boot image dependencies to not
generate invalid images") fixed bad images generation in the parallel
building, but it is not efficient to descend into arch/arm/boot over
and over again.  It is also clumsy to display the same log message
"Kernel: arch/arm/boot/Image is ready" a couple of times.

  $ make ARCH=arm UIMAGE_LOADADDR=0x80208000 all uImage
      [snip]
    Kernel: arch/arm/boot/Image is ready
    Kernel: arch/arm/boot/Image is ready
    Kernel: arch/arm/boot/zImage is ready
    Building modules, stage 2.
    MODPOST 279 modules
    Kernel: arch/arm/boot/Image is ready
    Kernel: arch/arm/boot/zImage is ready
    UIMAGE  arch/arm/boot/uImage
  Image Name:   Linux-4.5.0-rc3
  Created:      Mon Feb  8 13:22:53 2016
  Image Type:   ARM Linux Kernel Image (uncompressed)
  Data Size:    6768768 Bytes = 6610.12 kB = 6.46 MB
  Load Address: 80208000
  Entry Point:  80208000
    Image arch/arm/boot/uImage is ready

This commit allows arch/arm/boot/Makefile to build boot images at once
instead of generating them one by one.  Of course, it works correctly
also in parallel building.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

Changes in v2:
  - Fix build error

 arch/arm/Makefile | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index d6d453f..be1e146 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -315,13 +315,17 @@ archprepare:
 BOOT_TARGETS	= zImage Image xipImage bootpImage uImage
 INSTALL_TARGETS	= zinstall uinstall install
 
-PHONY += $(BOOT_TARGETS) $(INSTALL_TARGETS)
+PHONY += $(BOOT_TARGETS) $(INSTALL_TARGETS) __build_images
 
-bootpImage uImage: zImage
-zImage: Image
+$(BOOT_TARGETS): __build_images
+	@:
 
-$(BOOT_TARGETS): vmlinux
-	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@
+__build_images: vmlinux
+	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) \
+	$(addprefix $(boot)/, \
+		$(sort $(filter $(BOOT_TARGETS),$(MAKECMDGOALS)) \
+			$(if $(filter all,$(MAKECMDGOALS)), $(KBUILD_IMAGE)) \
+			$(if $(MAKECMDGOALS),,$(KBUILD_IMAGE))))
 
 $(INSTALL_TARGETS):
 	$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
-- 
1.9.1



From gregkh at linuxfoundation.org  Sun Feb  7 22:51:42 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Sun, 7 Feb 2016 22:51:42 -0800
Subject: [PATCH v7 0/4] generic TEE subsystem
In-Reply-To: <1454318140-7962-1-git-send-email-jens.wiklander@linaro.org>
References: <1454318140-7962-1-git-send-email-jens.wiklander@linaro.org>
Message-ID: <20160208065142.GA23170@kroah.com>

On Mon, Feb 01, 2016 at 10:15:36AM +0100, Jens Wiklander wrote:
> Hi,
> 
> This patch set introduces a generic TEE subsystem. The TEE subsystem will
> contain drivers for various TEE implementations. A TEE (Trusted Execution
> Environment) is a trusted OS running in some secure environment, for
> example, TrustZone on ARM CPUs, or a separate secure co-processor etc.
> 
> Regarding use cases, TrustZone has traditionally been used for
> offloading secure tasks to the secure world. Examples include: 
> - Secure key handling where the OS may or may not have direct access to key
>   material.
> - E-commerce and payment technologies. Credentials, credit card numbers etc
>   could be stored in a more secure environment.
> - Trusted User Interface (TUI) to ensure that no-one can snoop PIN-codes
>   etc.
> - Secure boot to ensure that loaded binaries haven?t been tampered with.
>   It?s not strictly needed for secure boot, but you could enhance security
>   by leveraging a TEE during boot.
> - Digital Rights Management (DRM), the studios provides content with
>   different resolution depending on the security of the device. Higher
>   security means higher resolution.
> 
> A TEE could also be used in existing and new technologies. For example IMA
> (Integrity Measurement Architecture) which has been in the kernel for quite
> a while. Today you can enhance security by using a TPM-chip to sign the IMA
> measurement list. This is something that you also could do by leveraging a
> TEE.
> 
> Another example could be in 2-factor authentication which is becoming
> increasingly more important. FIDO (https://fidoalliance.org) for example
> are using public key cryptography in their 2-factor authentication standard
> (U2F). With FIDO, a private and public key pair will be generated for every
> site you visit and the private key should never leave the local device.
> This is an example where you could use secure storage in a TEE for the
> private key.
> 
> Today you will find a quite a few different out of tree implementations of
> TEE drivers which tends to fragment the TEE ecosystem and development. We
> think it would be a good idea to have a generic TEE driver integrated in
> the kernel which would serve as a base for several different TEE solutions,
> no matter if they are on-chip like TrustZone or if they are on a separate
> crypto co-processor.
> 
> To develop this TEE subsystem we have been using the open source TEE called
> OP-TEE (https://github.com/OP-TEE/optee_os) and therefore this would be the
> first TEE solution supported by this new subsystem. OP-TEE is a
> GlobalPlatform compliant TEE, however this TEE subsystem is not limited to
> only GlobalPlatform TEEs, instead we have tried to design it so that it
> should work with other TEE solutions also.
> 
> "tee: generic TEE subsystem" brings in the generic TEE subsystem which
> helps when writing a driver for a specific TEE, for example, OP-TEE.
> 
> "tee: add OP-TEE driver" is an OP-TEE driver which uses the subsystem to do
> its work.
> 
> This patch set has been prepared in cooperation with Javier Gonz?lez who
> proposed "Generic TrustZone Driver in Linux Kernel" patches 28 Nov 2014,
> https://lwn.net/Articles/623380/ . We've since then changed the scope to
> TEE instead of TrustZone.
> 
> We have discussed the design on tee-dev at lists.linaro.org (archive at
> https://lists.linaro.org/pipermail/tee-dev/) with people from other
> companies, including Valentin Manea <valentin.manea at huawei.com>,
> Emmanuel MICHEL <emmanuel.michel at st.com>,
> Jean-michel DELORME <jean-michel.delorme at st.com>,
> and Joakim Bech <joakim.bech at linaro.org>. Our main concern has been to
> agree on something that is generic enough to support many different
> TEEs while still keeping the interface together.
> 
> v7:
> * Rebased on v4.5-rc2
> * Moved the ARM SMC Calling Convention support into a separate patch
>   set, which is now merged

Given this breaks the build on x86-64, I can't take this :(

Please fix up and do a basic bit of build testing...



From torso.nafi at gmail.com  Sun Feb  7 23:35:55 2016
From: torso.nafi at gmail.com (=?UTF-8?B?0JjQu9GM0Y/RgSDQk9Cw0YHQsNC90L7Qsg==?=)
Date: Mon, 8 Feb 2016 10:35:55 +0300
Subject: GPIO-driven RTS on TI hardware with 8250_omap driver
In-Reply-To: <5699870E.8080804@hurleysoftware.com>
References: <CAEo2pzugEO+jnwdWrRqKR3y4Gzveh9MMaZmRrksfgYzMf6WpPA@mail.gmail.com>
 <CAHp75Vd6eTXnwErTZdug_rW51mk2sZv5=nT2800ourp=VEHY=Q@mail.gmail.com>
 <5699870E.8080804@hurleysoftware.com>
Message-ID: <CAEo2pztdP1nPZBn4nkD5gzz-QZx2YgfQdCB5iYqxeUMs6rbApA@mail.gmail.com>

Hello,

2016-01-16 2:55 GMT+03:00 Peter Hurley <peter at hurleysoftware.com>:
> Please use the helpers in serial_mctrl_gpio.c if you try this.
>
> And please build on top of Matwey's patches, as those will likely be
> the rs485 implementation for the 8250_omap driver soon.

As far as I understand, since em485 callbacks are invoked by timers,
the code is to be executed in atomic context. However certain GPIO
controllers (particularly the OMAP-based one which is used on our
AM335x) require the use of the gpio_*_cansleep() functions, and cannot
work with the atomic-friendly non-cansleep ones. Do the aforementioned
helpers in serial_mctrl_gpio.c address this issue?

Regards,
Ilyas G.


From aryabinin at virtuozzo.com  Sun Feb  7 23:52:17 2016
From: aryabinin at virtuozzo.com (Andrey Ryabinin)
Date: Mon, 8 Feb 2016 10:52:17 +0300
Subject: [PATCH] arm64: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL
In-Reply-To: <1454716218-4918-1-git-send-email-yang.shi@linaro.org>
References: <1454716218-4918-1-git-send-email-yang.shi@linaro.org>
Message-ID: <56B84931.5080407@virtuozzo.com>

On 02/06/2016 02:50 AM, Yang Shi wrote:
> To enable UBSAN on arm64, ARCH_HAS_UBSAN_SANITIZE_ALL need to be selected.
> 
> Basic kernel bootup test is passed on arm64 with CONFIG_UBSAN_SANITIZE_ALL
> enabled.
> 
> Signed-off-by: Yang Shi <yang.shi at linaro.org>
> ---


Acked-by: Andrey Ryabinin <aryabinin at virtuozzo.com>


From carlo at caione.org  Mon Feb  8 00:34:19 2016
From: carlo at caione.org (Carlo Caione)
Date: Mon, 8 Feb 2016 09:34:19 +0100
Subject: [PATCH] clk: meson: Fix meson_clk_register_clks() signature type
 mismatch
In-Reply-To: <1454879583-27036-1-git-send-email-afaerber@suse.de>
References: <1454879583-27036-1-git-send-email-afaerber@suse.de>
Message-ID: <CAOQ7t2YwHa7cJdqv4m8rPx50ZnFZJJzcU2AjtE=Q2AYEAf84hg@mail.gmail.com>

On Sun, Feb 7, 2016 at 10:13 PM, Andreas F?rber <afaerber at suse.de> wrote:
> As preparation for arm64 based mesongxbb, which pulls in this code once
> enabling ARCH_MESON, fix a size_t vs. unsigned int type mismatch.
> The loop uses a local unsigned int variable, so adopt that type,
> matching the header.
>
> Fixes: 7a29a869434e ("clk: meson: Add support for Meson clock controller")
> Signed-off-by: Andreas F?rber <afaerber at suse.de>
> ---
>  drivers/clk/meson/clkc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/meson/clkc.c b/drivers/clk/meson/clkc.c
> index c83ae1367abc..d920d410b51d 100644
> --- a/drivers/clk/meson/clkc.c
> +++ b/drivers/clk/meson/clkc.c
> @@ -198,7 +198,7 @@ meson_clk_register_fixed_rate(const struct clk_conf *clk_conf,
>  }
>
>  void __init meson_clk_register_clks(const struct clk_conf *clk_confs,
> -                                   size_t nr_confs,
> +                                   unsigned int nr_confs,
>                                     void __iomem *clk_base)
>  {
>         unsigned int i;

Nit: I'd prefer to fix declaration in drivers/clk/meson/clkc.h with
size_t since we are going to use it for array indexing.

Also please, CC linux-meson at googlegroups.com on meson related patches.

Thanks!

-- 
Carlo Caione


From k at japko.eu  Mon Feb  8 00:39:12 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Mon, 8 Feb 2016 09:39:12 +0100
Subject: [PATCH v3 4/5] ARM: dts: sun8i-h3: Add R_PIO controller node to
 the dtsi
In-Reply-To: <CAGb2v67ftGhjPHjHKQ0iYnOeRbi5qcqyT2P1gePW=UoMm5QRig@mail.gmail.com>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-5-git-send-email-k@japko.eu>
 <CAGb2v67ftGhjPHjHKQ0iYnOeRbi5qcqyT2P1gePW=UoMm5QRig@mail.gmail.com>
Message-ID: <20160208083912.GF12071@box2.japko.eu>

On Fri, Feb 05, 2016 at 05:46:32PM +0800, Chen-Yu Tsai wrote:
>On Thu, Feb 4, 2016 at 7:33 AM, Krzysztof Adamski <k at japko.eu> wrote:
>> Add the corresponding device node for R_PIO on H3 to the dtsi. Support
>> for the controller was added in earlier commit.
>>
>> Signed-off-by: Krzysztof Adamski <k at japko.eu>
>> ---
>>  arch/arm/boot/dts/sun8i-h3.dtsi | 12 ++++++++++++
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index bb37f52..f618a95 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -517,5 +517,17 @@
>>                         compatible = "allwinner,sun6i-a31-clock-reset";
>>                         #reset-cells = <1>;
>>                 };
>> +
>> +               r_pio: pinctrl at 01f02c00 {
>> +                       compatible = "allwinner,sun8i-h3-r-pinctrl";
>> +                       reg = <0x01f02c00 0x400>;
>> +                       interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
>> +                       clocks = <&apb0_gates 0>;
>> +                       resets = <&apb0_reset 0>;
>> +                       gpio-controller;
>> +                       #gpio-cells = <3>;
>> +                       interrupt-controller;
>> +                       #interrupt-cells = <2>;
>
>This should be 3: bank number + pin number + flags.
>The rest looks good.

Nicly spotted. I took it from pio description in the same file. So 
there's a bug there too.


From geert at linux-m68k.org  Mon Feb  8 00:42:55 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 8 Feb 2016 09:42:55 +0100
Subject: [PATCH v2] arm64: dts: r8a7795: Add L2 cache-controller nodes
In-Reply-To: <20160205095758.GE16556@verge.net.au>
References: <1452953856-5146-1-git-send-email-dirk.behme@gmail.com>
 <56B2370D.2010102@gmail.com> <20160205095758.GE16556@verge.net.au>
Message-ID: <CAMuHMdVRhwGh2bvfNSguX0XnMW0eEgLRTCt3Y3-+KfV0Jy9WHw@mail.gmail.com>

Hi Dirk,

On Fri, Feb 5, 2016 at 10:57 AM, Simon Horman <horms at verge.net.au> wrote:
> On Wed, Feb 03, 2016 at 06:21:17PM +0100, Dirk Behme wrote:
>> On 16.01.2016 15:17, Dirk Behme wrote:
>> >From: Geert Uytterhoeven <geert+renesas at glider.be>
>> >
>> >Add device nodes for the L2 caches, and link the CPU node to its L2
>> >cache node.
>> >
>> >The L2 cache for the Cortex-A57 CPU cores is 2 MiB large (organized as
>> >128 KiB x 16 ways).
>> >
>> >Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
>> >Signed-off-by: Dirk Behme <dirk.behme at gmail.com>
>
> [snip]
>
>> Any further comments to this? If not, could this be applied?
>
> Sorry for the delay.
>
> This looks good; I have queued it up.
>
> It should appear in the next (and devel) branches of my renesas tree soon.
> And in linux-next whenever it includes my updated next branch.

So you not only dropped the (controversial) timing related properties, but
in addition:

+               cache-unified;
+               cache-level = <2>;

At least the "cache-level" property is marked as required in ePAPR.
For "cache-unified", the wording is not that strict in ePAPR, but that property
depends on being a unified cache in the first place.

So I think these two properties should be re-added.

Sorry for not noticing before.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From linus.walleij at linaro.org  Mon Feb  8 00:49:25 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  8 Feb 2016 09:49:25 +0100
Subject: [PATCH] ARM: ICST: try other dividends than 1
Message-ID: <1454921365-4140-1-git-send-email-linus.walleij@linaro.org>

Since the dawn of time the ICST code has only supported divide
by one or hang in an eternal loop. Luckily we were always dividing
by one because the reference frequency for the systems using
the ICSTs is 24MHz and the [min,max] values for the PLL input
if [10,320] MHz for ICST307 and [6,200] for ICST525, so the loop
will always terminate immediately without assigning any divisor
for the reference frequency.

But for the code to make sense, let's insert the missing i++

Reported-by: David Binderman <dcb314 at hotmail.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: stable at vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
I ran into the mail David sent in december and looked closer at
this. It's not a regression in any deployed systems but it's
disturbing so let's fix it.
---
 arch/arm/common/icst.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/common/icst.c b/arch/arm/common/icst.c
index 2dc6da70ae59..3b3e58b7ba74 100644
--- a/arch/arm/common/icst.c
+++ b/arch/arm/common/icst.c
@@ -58,6 +58,7 @@ icst_hz_to_vco(const struct icst_params *p, unsigned long freq)
 
 		if (f > p->vco_min && f <= p->vco_max)
 			break;
+		i++;
 	} while (i < 8);
 
 	if (i >= 8)
-- 
2.4.3



From aryabinin at virtuozzo.com  Mon Feb  8 00:51:01 2016
From: aryabinin at virtuozzo.com (Andrey Ryabinin)
Date: Mon, 8 Feb 2016 11:51:01 +0300
Subject: [PATCH] arm64: disable kasan when accessing frame->fp in
 unwind_frame
In-Reply-To: <1454713487-5239-1-git-send-email-yang.shi@linaro.org>
References: <1454713487-5239-1-git-send-email-yang.shi@linaro.org>
Message-ID: <56B856F5.5080606@virtuozzo.com>



On 02/06/2016 02:04 AM, Yang Shi wrote:
>  
>  #include <asm/irq.h>
>  #include <asm/stacktrace.h>
> @@ -64,7 +65,9 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
>  		return -EINVAL;
>  
>  	frame->sp = fp + 0x10;
> +	kasan_disable_current();
>  	frame->fp = *(unsigned long *)(fp);

It would be better to use READ_ONCE_NOCHECK() here.
See f7d27c35ddff7 ("x86/mm, kasan: Silence KASAN warnings in get_wchan()") which solves the same problem for x86.

> +	kasan_enable_current();
>  	frame->pc = *(unsigned long *)(fp + 8);

Why you left frame->pc out of scope? This line could trigger kasan as well.

>  
>  #ifdef CONFIG_FUNCTION_GRAPH_TRACER
> 


From pali.rohar at gmail.com  Mon Feb  8 00:51:57 2016
From: pali.rohar at gmail.com (Pali =?utf-8?B?Um9ow6Fy?=)
Date: Mon, 8 Feb 2016 09:51:57 +0100
Subject: N900 sleep mode (in 4.5-rc0, if that matters)
In-Reply-To: <20160207213720.GB6147@amd>
References: <20160126140010.GA29723@amd> <20160126172527.GY3500@atomide.com>
 <20160130200244.GA30429@amd> <20160130201452.GC30429@amd>
 <20160130221509.GA28644@amd> <20160201181316.GM19432@atomide.com>
 <20160201211736.GA11283@amd> <20160201221111.GP19432@atomide.com>
 <20160204053518.GP19432@atomide.com> <20160207213720.GB6147@amd>
Message-ID: <20160208085157.GB30075@pali>

On Sunday 07 February 2016 22:37:20 Pavel Machek wrote:
> Pali, do you have deeper sleep states working on 4.4 kernel? (Or
> anything 4.X?)

Do not know, at least I did not play or test this part of power
management yet.

-- 
Pali Roh?r
pali.rohar at gmail.com


From dirk.behme at de.bosch.com  Mon Feb  8 00:54:04 2016
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Mon, 8 Feb 2016 09:54:04 +0100
Subject: [PATCH v2] arm64: dts: r8a7795: Add L2 cache-controller nodes
In-Reply-To: <CAMuHMdVRhwGh2bvfNSguX0XnMW0eEgLRTCt3Y3-+KfV0Jy9WHw@mail.gmail.com>
References: <1452953856-5146-1-git-send-email-dirk.behme@gmail.com>
 <56B2370D.2010102@gmail.com> <20160205095758.GE16556@verge.net.au>
 <CAMuHMdVRhwGh2bvfNSguX0XnMW0eEgLRTCt3Y3-+KfV0Jy9WHw@mail.gmail.com>
Message-ID: <56B857AC.4090701@de.bosch.com>

On 08.02.2016 09:42, Geert Uytterhoeven wrote:
> Hi Dirk,
>
> On Fri, Feb 5, 2016 at 10:57 AM, Simon Horman <horms at verge.net.au> wrote:
>> On Wed, Feb 03, 2016 at 06:21:17PM +0100, Dirk Behme wrote:
>>> On 16.01.2016 15:17, Dirk Behme wrote:
>>>> From: Geert Uytterhoeven <geert+renesas at glider.be>
>>>>
>>>> Add device nodes for the L2 caches, and link the CPU node to its L2
>>>> cache node.
>>>>
>>>> The L2 cache for the Cortex-A57 CPU cores is 2 MiB large (organized as
>>>> 128 KiB x 16 ways).
>>>>
>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
>>>> Signed-off-by: Dirk Behme <dirk.behme at gmail.com>
>>
>> [snip]
>>
>>> Any further comments to this? If not, could this be applied?
>>
>> Sorry for the delay.
>>
>> This looks good; I have queued it up.
>>
>> It should appear in the next (and devel) branches of my renesas tree soon.
>> And in linux-next whenever it includes my updated next branch.
>
> So you not only dropped the (controversial) timing related properties, but
> in addition:
>
> +               cache-unified;
> +               cache-level = <2>;
>
> At least the "cache-level" property is marked as required in ePAPR.
> For "cache-unified", the wording is not that strict in ePAPR, but that property
> depends on being a unified cache in the first place.
>
> So I think these two properties should be re-added.


If I remember correctly, first, these entries are not used at all on 
ARMv8. And second, I think it was mentioned that we therefore want to 
drop them:

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394936.html

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/devicetree/bindings/arm/l2c2x0.txt?id=0bed4b7aa02c06e05121875dc443295d55b9d91d


Best regards

Dirk



From carlo at caione.org  Mon Feb  8 00:54:46 2016
From: carlo at caione.org (Carlo Caione)
Date: Mon, 8 Feb 2016 09:54:46 +0100
Subject: [PATCH] clk: meson: Fix meson_clk_register_clks() signature type
 mismatch
In-Reply-To: <CAOQ7t2YwHa7cJdqv4m8rPx50ZnFZJJzcU2AjtE=Q2AYEAf84hg@mail.gmail.com>
References: <1454879583-27036-1-git-send-email-afaerber@suse.de>
 <CAOQ7t2YwHa7cJdqv4m8rPx50ZnFZJJzcU2AjtE=Q2AYEAf84hg@mail.gmail.com>
Message-ID: <CAOQ7t2brTxmE-snjXxZG1ZrHNYCEugj6EwORBpVtaMHME_pewQ@mail.gmail.com>

On Mon, Feb 8, 2016 at 9:34 AM, Carlo Caione <carlo at caione.org> wrote:
> On Sun, Feb 7, 2016 at 10:13 PM, Andreas F?rber <afaerber at suse.de> wrote:
>> As preparation for arm64 based mesongxbb, which pulls in this code once
>> enabling ARCH_MESON, fix a size_t vs. unsigned int type mismatch.
>> The loop uses a local unsigned int variable, so adopt that type,
>> matching the header.
>>
>> Fixes: 7a29a869434e ("clk: meson: Add support for Meson clock controller")
>> Signed-off-by: Andreas F?rber <afaerber at suse.de>
>> ---
>>  drivers/clk/meson/clkc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/meson/clkc.c b/drivers/clk/meson/clkc.c
>> index c83ae1367abc..d920d410b51d 100644
>> --- a/drivers/clk/meson/clkc.c
>> +++ b/drivers/clk/meson/clkc.c
>> @@ -198,7 +198,7 @@ meson_clk_register_fixed_rate(const struct clk_conf *clk_conf,
>>  }
>>
>>  void __init meson_clk_register_clks(const struct clk_conf *clk_confs,
>> -                                   size_t nr_confs,
>> +                                   unsigned int nr_confs,
>>                                     void __iomem *clk_base)
>>  {
>>         unsigned int i;
>
> Nit: I'd prefer to fix declaration in drivers/clk/meson/clkc.h with
> size_t since we are going to use it for array indexing.

On a second thought it's ok since we use i to cycle through clocks.

Acked-by: Carlo Caione <carlo at endlessm.com>

Cheers,

-- 
Carlo Caione


From geert at linux-m68k.org  Mon Feb  8 01:01:11 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 8 Feb 2016 10:01:11 +0100
Subject: [PATCH v2] arm64: dts: r8a7795: Add L2 cache-controller nodes
In-Reply-To: <56B857AC.4090701@de.bosch.com>
References: <1452953856-5146-1-git-send-email-dirk.behme@gmail.com>
 <56B2370D.2010102@gmail.com> <20160205095758.GE16556@verge.net.au>
 <CAMuHMdVRhwGh2bvfNSguX0XnMW0eEgLRTCt3Y3-+KfV0Jy9WHw@mail.gmail.com>
 <56B857AC.4090701@de.bosch.com>
Message-ID: <CAMuHMdUTUss=fR0Mdz+7tDD=RC6hufvkLC99Fp=PTiTgaSSGNA@mail.gmail.com>

Hi Dirk,

On Mon, Feb 8, 2016 at 9:54 AM, Dirk Behme <dirk.behme at de.bosch.com> wrote:
> On 08.02.2016 09:42, Geert Uytterhoeven wrote:
>> On Fri, Feb 5, 2016 at 10:57 AM, Simon Horman <horms at verge.net.au> wrote:
>>> On Wed, Feb 03, 2016 at 06:21:17PM +0100, Dirk Behme wrote:
>>>> On 16.01.2016 15:17, Dirk Behme wrote:
>>>>> From: Geert Uytterhoeven <geert+renesas at glider.be>
>>>>>
>>>>> Add device nodes for the L2 caches, and link the CPU node to its L2
>>>>> cache node.
>>>>>
>>>>> The L2 cache for the Cortex-A57 CPU cores is 2 MiB large (organized as
>>>>> 128 KiB x 16 ways).
>>>>>
>>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
>>>>> Signed-off-by: Dirk Behme <dirk.behme at gmail.com>
>>>
>>> [snip]
>>>
>>>> Any further comments to this? If not, could this be applied?
>>>
>>> Sorry for the delay.
>>>
>>> This looks good; I have queued it up.
>>>
>>> It should appear in the next (and devel) branches of my renesas tree
>>> soon.
>>> And in linux-next whenever it includes my updated next branch.
>>
>> So you not only dropped the (controversial) timing related properties, but
>> in addition:
>>
>> +               cache-unified;
>> +               cache-level = <2>;
>>
>> At least the "cache-level" property is marked as required in ePAPR.
>> For "cache-unified", the wording is not that strict in ePAPR, but that
>> property
>> depends on being a unified cache in the first place.
>>
>> So I think these two properties should be re-added.
>
> If I remember correctly, first, these entries are not used at all on ARMv8.
> And second, I think it was mentioned that we therefore want to drop them:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394936.html
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/devicetree/bindings/arm/l2c2x0.txt?id=0bed4b7aa02c06e05121875dc443295d55b9d91d

I believe the discussion was only about the latency properties, which are
documented in the l2c2x0 DT bindings, and deemed to not apply here
(CC Sudeep).
The DT bindings documented in ePAPR are generic, and apply to all hardware,
unless extended or overridden by more-specific DT bindings.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From james.morse at arm.com  Mon Feb  8 01:03:21 2016
From: james.morse at arm.com (James Morse)
Date: Mon, 08 Feb 2016 09:03:21 +0000
Subject: [PATCH v4 07/13] arm64: Change cpu_resume() to enable mmu early
 then access sleep_sp by va
In-Reply-To: <20160205162617.GD31547@red-moon>
References: <1453977766-20907-1-git-send-email-james.morse@arm.com>
 <1453977766-20907-8-git-send-email-james.morse@arm.com>
 <20160205162617.GD31547@red-moon>
Message-ID: <56B859D9.3080601@arm.com>

Hi Lorenzo,

On 05/02/16 16:26, Lorenzo Pieralisi wrote:
>> cpu_do_{suspend,resume} could be further reduced to not restore: cpacr_el1,
>> mdscr_el1, tcr_el1, vbar_el1 and sctlr_el1, all of which are set by
>> __cpu_setup(). However these values all contain res0 bits that may be used
>> to enable future features.
> 
> This patch is a very nice clean-up, a comment below.
> 
> I think that for registers like tcr_el1 and sctlr_el1 we should define
> a restore mask (to avoid overwriting bits set-up by __cpu_setup), eg
> current code that restores the tcr_el1 seems wrong to me, see below.

Presumably this should be two masks, one to find RES0 bits that are set, and are
assumed to have some new meaning, and another to find RES1 bits that have been
cleared.


>> -	cpu_set_reserved_ttbr0();
>> -	local_flush_tlb_all();
>> -	cpu_set_default_tcr_t0sz();
> 
> You remove the code above since you restore tcr_el1 in cpu_do_resume(),
> but this is not the way it should be done, ie the restore should be done
> with the code sequence above otherwise it is not safe.

You're right - __cpu_setup() sets a guaranteed-incompatible t0sz value.
I removed it because all this now gets executed from the swapper page tables,
not the idmap, but there is more to it than that.


Thanks,

James


From antoine.tenart at free-electrons.com  Mon Feb  8 01:11:37 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon,  8 Feb 2016 10:11:37 +0100
Subject: [PATCH 1/3] arm64: add Alpine SoC family
In-Reply-To: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1454922699-16785-2-git-send-email-antoine.tenart@free-electrons.com>

This patch introduces ARCH_ALPINE to add the support of the Alpine SoC
family for the arm64 architecture.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
---
 arch/arm64/Kconfig.platforms | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f674bde..bfbefa3e0dbe 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -1,5 +1,11 @@
 menu "Platform selection"
 
+config ARCH_ALPINE
+	bool "Annapurna Labs Alpine platform"
+	help
+	  This enables support for the Annapurna Labs Alpine
+	  Soc family.
+
 config ARCH_BCM_IPROC
 	bool "Broadcom iProc SoC Family"
 	help
-- 
2.7.0



From antoine.tenart at free-electrons.com  Mon Feb  8 01:11:36 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon,  8 Feb 2016 10:11:36 +0100
Subject: [PATCH 0/3] arm64: introduce the Alpine support
Message-ID: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>

Hi all,

This series introduces the support for the arm64 Alpine family from
Annapurna Labs, by adding a device tree for the Alpine v2 EVP. This
board has 4 Cortex A57 and a few nodes in its device tree for now.

You can find the series at:
https://github.com/atenart/linux.git 4.5-rc1/alpinev2-bringup

Antoine

Antoine Tenart (3):
  arm64: add Alpine SoC family
  arm64: dts: add the Alpine v2 EVP
  arm64: defconfig: enable the Alpine family

 arch/arm64/Kconfig.platforms             |   6 +
 arch/arm64/boot/dts/Makefile             |   1 +
 arch/arm64/boot/dts/al/Makefile          |   5 +
 arch/arm64/boot/dts/al/alpine-v2-evp.dts |  46 +++++++
 arch/arm64/boot/dts/al/alpine-v2.dtsi    | 221 +++++++++++++++++++++++++++++++
 arch/arm64/configs/defconfig             |   1 +
 6 files changed, 280 insertions(+)
 create mode 100644 arch/arm64/boot/dts/al/Makefile
 create mode 100644 arch/arm64/boot/dts/al/alpine-v2-evp.dts
 create mode 100644 arch/arm64/boot/dts/al/alpine-v2.dtsi

-- 
2.7.0



From antoine.tenart at free-electrons.com  Mon Feb  8 01:11:39 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon,  8 Feb 2016 10:11:39 +0100
Subject: [PATCH 3/3] arm64: defconfig: enable the Alpine family
In-Reply-To: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1454922699-16785-4-git-send-email-antoine.tenart@free-electrons.com>

Enable the Alpine SoC family in the arm64 defconfig.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 18ca9fb9e65f..10387947a164 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -31,6 +31,7 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_ARCH_ALPINE=y
 CONFIG_ARCH_BCM_IPROC=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_ARCH_EXYNOS7=y
-- 
2.7.0



From antoine.tenart at free-electrons.com  Mon Feb  8 01:11:38 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon,  8 Feb 2016 10:11:38 +0100
Subject: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>

This patch adds the initial support for the Alpine v2 EVP board from
Annapurna Labs (Amazon).

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Barak Wasserstrom <barak at annapurnalabs.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 arch/arm64/boot/dts/Makefile             |   1 +
 arch/arm64/boot/dts/al/Makefile          |   5 +
 arch/arm64/boot/dts/al/alpine-v2-evp.dts |  46 +++++++
 arch/arm64/boot/dts/al/alpine-v2.dtsi    | 221 +++++++++++++++++++++++++++++++
 4 files changed, 273 insertions(+)
 create mode 100644 arch/arm64/boot/dts/al/Makefile
 create mode 100644 arch/arm64/boot/dts/al/alpine-v2-evp.dts
 create mode 100644 arch/arm64/boot/dts/al/alpine-v2.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index f832b8a7453a..fd80617a9c6f 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,3 +1,4 @@
+dts-dirs += al
 dts-dirs += altera
 dts-dirs += amd
 dts-dirs += apm
diff --git a/arch/arm64/boot/dts/al/Makefile b/arch/arm64/boot/dts/al/Makefile
new file mode 100644
index 000000000000..8a6cde4f9b23
--- /dev/null
+++ b/arch/arm64/boot/dts/al/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_ALPINE)	+= alpine-v2-evp.dtb
+
+always		:= $(dtb-y)
+subdir-y	:= $(dts-dirs)
+clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/al/alpine-v2-evp.dts b/arch/arm64/boot/dts/al/alpine-v2-evp.dts
new file mode 100644
index 000000000000..3e3080fa45e4
--- /dev/null
+++ b/arch/arm64/boot/dts/al/alpine-v2-evp.dts
@@ -0,0 +1,46 @@
+/*
+ * Copyright 2016 Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ *
+ * Antoine Tenart <antoine.tenart at free-electrons.com>
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * BSD license below:
+ *
+ *     Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *      - Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *
+ *      - Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include "alpine-v2.dtsi"
+
+/ {
+	model = "Annapurna Labs Alpine v2 EVP";
+	compatible = "al,alpine-v2-evp", "al,alpine-v2";
+
+	chosen {
+		stdout-path = "console0:115200n8";
+	};
+};
+
+&uart0 { status = "okay"; };
diff --git a/arch/arm64/boot/dts/al/alpine-v2.dtsi b/arch/arm64/boot/dts/al/alpine-v2.dtsi
new file mode 100644
index 000000000000..eb7a03b71456
--- /dev/null
+++ b/arch/arm64/boot/dts/al/alpine-v2.dtsi
@@ -0,0 +1,221 @@
+/*
+ * Copyright 2016 Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ *
+ * Antoine Tenart <antoine.tenart at free-electrons.com>
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * BSD license below:
+ *
+ *     Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *      - Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *
+ *      - Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	model = "Annapurna Labs Alpine v2";
+	compatible = "al,alpine-v2";
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			compatible = "arm,cortex-a57", "arm,armv8";
+			device_type = "cpu";
+			reg = <0x0 0x0>;
+			enable-method = "psci";
+		};
+
+		cpu at 1 {
+			compatible = "arm,cortex-a57", "arm,armv8";
+			device_type = "cpu";
+			reg = <0x0 0x1>;
+			enable-method = "psci";
+		};
+
+		cpu at 2 {
+			compatible = "arm,cortex-a57", "arm,armv8";
+			device_type = "cpu";
+			reg = <0x0 0x2>;
+			enable-method = "psci";
+		};
+
+		cpu at 3 {
+			compatible = "arm,cortex-a57", "arm,armv8";
+			device_type = "cpu";
+			reg = <0x0 0x3>;
+			enable-method = "psci";
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2", "arm,psci";
+		method = "smc";
+		cpu_on = <0x84000003>;
+	};
+
+	sbclk: sbclk {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1000000>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+
+		interrupt-parent = <&gic>;
+		ranges;
+
+		timer {
+			compatible = "arm,armv8-timer";
+			interrupts = <GIC_PPI 0xd 0xff08>,
+				     <GIC_PPI 0xe 0xff08>,
+				     <GIC_PPI 0xb 0xff08>,
+				     <GIC_PPI 0xa 0xff08>;
+		};
+
+		pmu {
+			compatible = "arm,armv8-pmuv3";
+			interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		gic: gic at f0100000 {
+			compatible = "arm,gic-v3";
+			reg = <0x0 0xf0200000 0x0 0x10000>,	/* GIC Dist */
+			      <0x0 0xf0280000 0x0 0x200000>,	/* GICR */
+			      <0x0 0xf0100000 0x0 0x2000>;	/* GICC */
+			interrupt-controller;
+			#interrupt-cells = <3>;
+		};
+
+		pcie-internal at 0xfbc00000 {
+			compatible = "pci-host-ecam-generic";
+			device_type = "pci";
+			#size-cells = <2>;
+			#address-cells = <3>;
+			#interrupt-cells = <1>;
+			reg = <0x0 0xfbc00000 0x0 0x100000>;
+			interrupt-map-mask = <0xf800 0 0 7>;
+			/* add legacy interrupts for SATA only */
+			interrupt-map = <0x4000 0 0 1 &gic 0 53 4>,
+					<0x4800 0 0 1 &gic 0 54 4>;
+			/* 32 bit non prefetchable memory space */
+			ranges = <0x2000000 0x0 0xfe000000 0x0 0xfe000000 0x0 0x1000000>;
+			bus-range = <0x00 0x00>;
+		};
+
+		uart0: uart at fd883000 {
+			compatible = "ns16550a";
+			device_type = "serial";
+			reg = <0x0 0xfd883000 0x0 0x1000>;
+			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+			clock-frequency = <500000000>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			status = "disabled";
+		};
+
+		uart1: uart at fd884000 {
+			compatible = "ns16550a";
+			device_type = "serial";
+			reg = <0x0 0xfd884000 0x0 0x1000>;
+			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+			clock-frequency = <500000000>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			status = "disabled";
+		};
+
+		uart2: uart at fd885000 {
+			compatible = "ns16550a";
+			device_type = "serial";
+			reg = <0x0 0xfd885000 0x0 0x1000>;
+			interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+			clock-frequency = <500000000>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			status = "disabled";
+		};
+
+		uart3: uart at fd886000 {
+			compatible = "ns16550a";
+			device_type = "serial";
+			reg = <0x0 0xfd886000 0x0 0x1000>;
+			interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+			clock-frequency = <500000000>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			status = "disabled";
+		};
+
+		timer0: timer at fd890000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x0 0xfd890000 0x0 0x1000>;
+			interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&sbclk>;
+		};
+
+		timer1: timer at fd891000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x0 0xfd891000 0x0 0x1000>;
+			interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&sbclk>;
+			status = "disabled";
+		};
+
+		timer2: timer at fd892000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x0 0xfd892000 0x0 0x1000>;
+			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&sbclk>;
+			status = "disabled";
+		};
+
+		timer3: timer at fd893000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x0 0xfd893000 0x0 0x1000>;
+			interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&sbclk>;
+			status = "disabled";
+		};
+	};
+};
-- 
2.7.0



From linus.walleij at linaro.org  Mon Feb  8 01:13:08 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon,  8 Feb 2016 10:13:08 +0100
Subject: [PATCH 05/11 v2] video: ARM CLCD: add special board and panel hooks
 for Nomadik
Message-ID: <1454922788-10174-1-git-send-email-linus.walleij@linaro.org>

In the .board_init() callback will set up a mux register in
the Nomadik system controller. It so happens that the platform
has two display output engines, and we have to poke a bit in
a special register to make sure the right engine is muxed in
as they are mutually exclusive.

The Nomadik CLCD variant is instantiated on a platform where
it is combined with a 800x480 TPO WVGA display. In the
.panel_init() hook we will detect this display from the
compatible string and set it up. We also add .enable() and
.disable() callbacks for it as the sleep state is software
controlled.

The display is connected with a special 3-wire serial bus
(this is sadly neither I2C or SPI) using three GPIO lines that
we bitbang to detect the display and enable/disable sleep
state.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Removed unused "var" pointer variable
- Follow *endpoint, not endpoint, as that gives us a **
  rather than a *
---
 drivers/video/fbdev/Makefile            |   1 +
 drivers/video/fbdev/amba-clcd-nomadik.c | 262 ++++++++++++++++++++++++++++++++
 drivers/video/fbdev/amba-clcd-nomadik.h |  24 +++
 drivers/video/fbdev/amba-clcd.c         |   6 +-
 4 files changed, 292 insertions(+), 1 deletion(-)
 create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.c
 create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.h

diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index 65fb15075c8f..f0aec3aa213c 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_FB_ATMEL)		  += atmel_lcdfb.o
 obj-$(CONFIG_FB_PVR2)             += pvr2fb.o
 obj-$(CONFIG_FB_VOODOO1)          += sstfb.o
 obj-$(CONFIG_FB_ARMCLCD)	  += amba-clcd.o
+obj-$(CONFIG_ARCH_NOMADIK)	  += amba-clcd-nomadik.o
 obj-$(CONFIG_PLAT_VERSATILE_CLCD) += amba-clcd-versatile.o
 obj-$(CONFIG_FB_GOLDFISH)         += goldfishfb.o
 obj-$(CONFIG_FB_68328)            += 68328fb.o
diff --git a/drivers/video/fbdev/amba-clcd-nomadik.c b/drivers/video/fbdev/amba-clcd-nomadik.c
new file mode 100644
index 000000000000..863b568859b6
--- /dev/null
+++ b/drivers/video/fbdev/amba-clcd-nomadik.c
@@ -0,0 +1,262 @@
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+#include <linux/gpio/consumer.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/delay.h>
+#include <linux/bitops.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+
+#include "amba-clcd-nomadik.h"
+
+static struct gpio_desc *grestb;
+static struct gpio_desc *scen;
+static struct gpio_desc *scl;
+static struct gpio_desc *sda;
+
+static u8 tpg110_readwrite_reg(bool write, u8 address, u8 outval)
+{
+	int i;
+	u8 inval = 0;
+
+	/* Assert SCEN */
+	gpiod_set_value_cansleep(scen, 1);
+	ndelay(150);
+	/* Hammer out the address */
+	for (i = 5; i >= 0; i--) {
+		if (address & BIT(i))
+			gpiod_set_value_cansleep(sda, 1);
+		else
+			gpiod_set_value_cansleep(sda, 0);
+		ndelay(150);
+		/* Send an SCL pulse */
+		gpiod_set_value_cansleep(scl, 1);
+		ndelay(160);
+		gpiod_set_value_cansleep(scl, 0);
+		ndelay(160);
+	}
+
+	if (write) {
+		/* WRITE */
+		gpiod_set_value_cansleep(sda, 0);
+	} else {
+		/* READ */
+		gpiod_set_value_cansleep(sda, 1);
+	}
+	ndelay(150);
+	/* Send an SCL pulse */
+	gpiod_set_value_cansleep(scl, 1);
+	ndelay(160);
+	gpiod_set_value_cansleep(scl, 0);
+	ndelay(160);
+
+	if (!write)
+		/* HiZ turn-around cycle */
+		gpiod_direction_input(sda);
+	ndelay(150);
+	/* Send an SCL pulse */
+	gpiod_set_value_cansleep(scl, 1);
+	ndelay(160);
+	gpiod_set_value_cansleep(scl, 0);
+	ndelay(160);
+
+	/* Hammer in/out the data */
+	for (i = 7; i >= 0; i--) {
+		int value;
+
+		if (write) {
+			value = !!(outval & BIT(i));
+			gpiod_set_value_cansleep(sda, value);
+		} else {
+			value = gpiod_get_value(sda);
+			if (value)
+				inval |= BIT(i);
+		}
+		ndelay(150);
+		/* Send an SCL pulse */
+		gpiod_set_value_cansleep(scl, 1);
+		ndelay(160);
+		gpiod_set_value_cansleep(scl, 0);
+		ndelay(160);
+	}
+
+	gpiod_direction_output(sda, 0);
+	/* Deassert SCEN */
+	gpiod_set_value_cansleep(scen, 0);
+	/* Satisfies SCEN pulse width */
+	udelay(1);
+
+	return inval;
+}
+
+static u8 tpg110_read_reg(u8 address)
+{
+	return tpg110_readwrite_reg(false, address, 0);
+}
+
+static void tpg110_write_reg(u8 address, u8 outval)
+{
+	tpg110_readwrite_reg(true, address, outval);
+}
+
+static void tpg110_startup(struct device *dev)
+{
+	u8 val;
+
+	dev_info(dev, "TPG110 display enable\n");
+	/* De-assert the reset signal */
+	gpiod_set_value_cansleep(grestb, 0);
+	mdelay(1);
+	dev_info(dev, "de-asserted GRESTB\n");
+
+	/* Test display communication */
+	tpg110_write_reg(0x00, 0x55);
+	val = tpg110_read_reg(0x00);
+	if (val == 0x55)
+		dev_info(dev, "passed communication test\n");
+	val = tpg110_read_reg(0x01);
+	dev_info(dev, "TPG110 chip ID: %d version: %d\n",
+		val>>4, val&0x0f);
+
+	/* Show display resolution */
+	val = tpg110_read_reg(0x02);
+	val &= 7;
+	switch (val) {
+	case 0x0:
+		dev_info(dev, "IN 400x240 RGB -> OUT 800x480 RGB (dual scan)");
+		break;
+	case 0x1:
+		dev_info(dev, "IN 480x272 RGB -> OUT 800x480 RGB (dual scan)");
+		break;
+	case 0x4:
+		dev_info(dev, "480x640 RGB");
+		break;
+	case 0x5:
+		dev_info(dev, "480x272 RGB");
+		break;
+	case 0x6:
+		dev_info(dev, "640x480 RGB");
+		break;
+	case 0x7:
+		dev_info(dev, "800x480 RGB");
+		break;
+	default:
+		dev_info(dev, "ILLEGAL RESOLUTION");
+		break;
+	}
+
+	val = tpg110_read_reg(0x03);
+	dev_info(dev, "resolution is controlled by %s\n",
+		(val & BIT(7)) ? "software" : "hardware");
+}
+
+static void tpg110_enable(struct clcd_fb *fb)
+{
+	struct device *dev = &fb->dev->dev;
+	static bool startup;
+	u8 val;
+
+	if (!startup) {
+		tpg110_startup(dev);
+		startup = true;
+	}
+
+	/* Take chip out of standby */
+	val = tpg110_read_reg(0x03);
+	val |= BIT(0);
+	tpg110_write_reg(0x03, val);
+}
+
+static void tpg110_disable(struct clcd_fb *fb)
+{
+	u8 val;
+
+	dev_info(&fb->dev->dev, "TPG110 display disable\n");
+	val = tpg110_read_reg(0x03);
+	/* Put into standby */
+	val &= ~BIT(0);
+	tpg110_write_reg(0x03, val);
+}
+
+static void tpg110_init(struct device *dev, struct device_node *np,
+			struct clcd_board *board)
+{
+	dev_info(dev, "TPG110 display init\n");
+
+	grestb = devm_get_gpiod_from_child(dev, "grestb", &np->fwnode);
+	if (IS_ERR(grestb)) {
+		dev_err(dev, "no GRESTB GPIO\n");
+		return;
+	}
+	/* This asserts the GRESTB signal, putting the display into reset */
+	gpiod_direction_output(grestb, 1);
+
+	scen = devm_get_gpiod_from_child(dev, "scen", &np->fwnode);
+	if (IS_ERR(scen)) {
+		dev_err(dev, "no SCEN GPIO\n");
+		return;
+	}
+	gpiod_direction_output(scen, 0);
+	scl = devm_get_gpiod_from_child(dev, "scl", &np->fwnode);
+	if (IS_ERR(scl)) {
+		dev_err(dev, "no SCL GPIO\n");
+		return;
+	}
+	gpiod_direction_output(scl, 0);
+	sda = devm_get_gpiod_from_child(dev, "sda", &np->fwnode);
+	if (IS_ERR(sda)) {
+		dev_err(dev, "no SDA GPIO\n");
+		return;
+	}
+	gpiod_direction_output(sda, 0);
+	board->enable = tpg110_enable;
+	board->disable = tpg110_disable;
+}
+
+int nomadik_clcd_init_panel(struct clcd_fb *fb,
+			    struct device_node **endpoint)
+{
+	struct device_node *panel;
+
+	*endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node,
+					       NULL);
+	if (!*endpoint)
+		return -ENODEV;
+
+	panel = of_graph_get_remote_port_parent(*endpoint);
+	if (!panel)
+		return -ENODEV;
+
+	if (of_device_is_compatible(panel, "tpo,tpg110"))
+		tpg110_init(&fb->dev->dev, panel, fb->board);
+	else
+		dev_info(&fb->dev->dev, "unknown panel\n");
+
+	/* Unknown panel, fall through */
+	return 0;
+}
+
+#define PMU_CTRL_OFFSET 0x0000
+#define PMU_CTRL_LCDNDIF BIT(26)
+
+int nomadik_clcd_init_board(struct amba_device *adev,
+			    struct clcd_board *board)
+{
+	struct regmap *pmu_regmap;
+
+	dev_info(&adev->dev, "Nomadik CLCD board init\n");
+	pmu_regmap =
+		syscon_regmap_lookup_by_compatible("stericsson,nomadik-pmu");
+	if (IS_ERR(pmu_regmap)) {
+		dev_err(&adev->dev, "could not find PMU syscon regmap\n");
+		return PTR_ERR(pmu_regmap);
+	}
+	regmap_update_bits(pmu_regmap,
+			   PMU_CTRL_OFFSET,
+			   PMU_CTRL_LCDNDIF,
+			   0);
+	dev_info(&adev->dev, "set PMU mux to CLCD mode\n");
+
+	return 0;
+}
diff --git a/drivers/video/fbdev/amba-clcd-nomadik.h b/drivers/video/fbdev/amba-clcd-nomadik.h
new file mode 100644
index 000000000000..b34dbf3061bf
--- /dev/null
+++ b/drivers/video/fbdev/amba-clcd-nomadik.h
@@ -0,0 +1,24 @@
+#ifndef _AMBA_CLCD_NOMADIK_H
+#define _AMBA_CLCD_NOMADIK_H
+
+#include <linux/amba/bus.h>
+
+#ifdef CONFIG_ARCH_NOMADIK
+int nomadik_clcd_init_board(struct amba_device *adev,
+			     struct clcd_board *board);
+int nomadik_clcd_init_panel(struct clcd_fb *fb,
+			    struct device_node **endpoint);
+#else
+static inline int nomadik_clcd_init_board(struct amba_device *adev,
+					  struct clcd_board *board)
+{
+	return 0;
+}
+static inline int nomadik_clcd_init_panel(struct clcd_fb *fb,
+					  struct device_node **endpoint)
+{
+	return 0;
+}
+#endif
+
+#endif /* inclusion guard */
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 77fb50e00670..53c5ec31168d 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -37,6 +37,8 @@
 
 #include <asm/sizes.h>
 
+#include "amba-clcd-nomadik.h"
+
 #define to_clcd(info)	container_of(info, struct clcd_fb, fb)
 
 /* This is limited to 16 characters when displayed by X startup */
@@ -1003,7 +1005,7 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
 	if (ret)
 		goto free_fb;
 
-	ret = clcdfb_register(fb); 
+	ret = clcdfb_register(fb);
 	if (ret == 0) {
 		amba_set_drvdata(dev, fb);
 		goto out;
@@ -1047,6 +1049,8 @@ static struct clcd_vendor_data vendor_nomadik = {
 	.clock_timregs = true,
 	.packed_24_bit_pixels = true,
 	.st_bitmux_control = true,
+	.init_board = nomadik_clcd_init_board,
+	.init_panel = nomadik_clcd_init_panel,
 };
 
 static struct amba_id clcdfb_id_table[] = {
-- 
2.4.3



From antoine.tenart at free-electrons.com  Mon Feb  8 01:16:09 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon,  8 Feb 2016 10:16:09 +0100
Subject: [PATCH 4/6] ARM: dts: alpine: add the MSIX node
In-Reply-To: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1454922971-17405-5-git-send-email-antoine.tenart@free-electrons.com>

With the newly available MSIX driver for Alpine, add the corresponding
node in the Alpine device tree.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
---
 arch/arm/boot/dts/alpine.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/alpine.dtsi b/arch/arm/boot/dts/alpine.dtsi
index 9af2d60e9a7f..db8752fc480e 100644
--- a/arch/arm/boot/dts/alpine.dtsi
+++ b/arch/arm/boot/dts/alpine.dtsi
@@ -155,6 +155,16 @@
 			ranges = <0x02000000 0x0 0xfe000000 0x0 0xfe000000 0x0 0x1000000>;
 
 			bus-range = <0x00 0x00>;
+			msi-parent = <&msix>;
+		};
+
+		msix: msix at fbe00000 {
+			compatible = "al,alpine-msix";
+			reg = <0x0 0xfbe00000 0x0 0x100000>;
+			interrupt-controller;
+			msi-controller;
+			al,msi-base-spi = <96>;
+			al,msi-num-spis = <64>;
 		};
 	};
 };
-- 
2.7.0



From antoine.tenart at free-electrons.com  Mon Feb  8 01:16:05 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon,  8 Feb 2016 10:16:05 +0100
Subject: [PATCH 0/6] irqchip: introduce the Alpine MSIX driver
Message-ID: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>

Hi all,

This series introduce the Alpine MSIX driver, and enables it in both
the Alpine v1 and Alpine v2 device trees.

This series depends on "[PATCH 0/3] arm64: introduce the Alpine support":
https://lkml.org/lkml/2016/2/8/75

You can find the series at:
https://github.com/atenart/linux.git 4.5-rc1/alpinev2-msix

Antoine

Antoine Tenart (6):
  irqchip: add the Alpine MSIX interrupt controller
  Documentation: bindings: document the Alpine MSIX driver
  arm64: dts: alpine: add the MSIX node in the Alpine v2 dtsi
  ARM: dts: alpine: add the MSIX node
  arm64: alpine: select the Alpine MSI controller driver
  arm: alpine: select the Alpine MSI controller driver

 .../interrupt-controller/al,alpine-msix.txt        |  22 ++
 arch/arm/boot/dts/alpine.dtsi                      |  10 +
 arch/arm/mach-alpine/Kconfig                       |   1 +
 arch/arm64/Kconfig.platforms                       |   1 +
 arch/arm64/boot/dts/al/alpine-v2.dtsi              |  10 +
 drivers/irqchip/Kconfig                            |   6 +
 drivers/irqchip/Makefile                           |   1 +
 drivers/irqchip/irq-alpine-msi.c                   | 297 +++++++++++++++++++++
 8 files changed, 348 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
 create mode 100644 drivers/irqchip/irq-alpine-msi.c

-- 
2.7.0



From antoine.tenart at free-electrons.com  Mon Feb  8 01:16:07 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon,  8 Feb 2016 10:16:07 +0100
Subject: [PATCH 2/6] Documentation: bindings: document the Alpine MSIX driver
In-Reply-To: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1454922971-17405-3-git-send-email-antoine.tenart@free-electrons.com>

Following the addition of the Alpine MSIX driver, this patch adds the
corresponding bindings documentation.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 .../interrupt-controller/al,alpine-msix.txt        | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt

diff --git a/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt b/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
new file mode 100644
index 000000000000..a77d5a76e8d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
@@ -0,0 +1,22 @@
+Alpine MSIX controller
+
+Required properties:
+
+- compatible: should be "al,alpine-msix"
+- reg: physical base address and size of the registers
+- interrupt-controller: identifies the node as an interrupt controller
+- msi-controller: identifies the node as an PCI Message Signaled Interrupt
+		  controller
+- al,msi-base-spi: SPI base of the MSI frame
+- al,msi-num-spis: number of SPIs assigned to the MSI frame
+
+Example:
+
+msix: msix {
+	compatible = "al,alpine-msix";
+	reg = <0x0 0xfbe00000 0x0 0x100000>;
+	interrupt-controller;
+	msi-controller;
+	al,msi-base-spi = <160>;
+	al,msi-num-spis = <160>;
+};
-- 
2.7.0



From antoine.tenart at free-electrons.com  Mon Feb  8 01:16:08 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon,  8 Feb 2016 10:16:08 +0100
Subject: [PATCH 3/6] arm64: dts: alpine: add the MSIX node in the Alpine v2
 dtsi
In-Reply-To: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1454922971-17405-4-git-send-email-antoine.tenart@free-electrons.com>

Following the addition of the Alpine MSIX controller driver, add the
corresponding node in the Alpine v2 device tree.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 arch/arm64/boot/dts/al/alpine-v2.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/al/alpine-v2.dtsi b/arch/arm64/boot/dts/al/alpine-v2.dtsi
index eb7a03b71456..413062be1674 100644
--- a/arch/arm64/boot/dts/al/alpine-v2.dtsi
+++ b/arch/arm64/boot/dts/al/alpine-v2.dtsi
@@ -141,6 +141,16 @@
 			/* 32 bit non prefetchable memory space */
 			ranges = <0x2000000 0x0 0xfe000000 0x0 0xfe000000 0x0 0x1000000>;
 			bus-range = <0x00 0x00>;
+			msi-parent = <&msix>;
+		};
+
+		msix: msix at fbe00000 {
+			compatible = "al,alpine-msix";
+			reg = <0x0 0xfbe00000 0x0 0x100000>;
+			interrupt-controller;
+			msi-controller;
+			al,msi-base-spi = <160>;
+			al,msi-num-spis = <160>;
 		};
 
 		uart0: uart at fd883000 {
-- 
2.7.0



From antoine.tenart at free-electrons.com  Mon Feb  8 01:16:06 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon,  8 Feb 2016 10:16:06 +0100
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>

This patch adds the Alpine MSIX interrupt controller driver.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 drivers/irqchip/Kconfig          |   6 +
 drivers/irqchip/Makefile         |   1 +
 drivers/irqchip/irq-alpine-msi.c | 297 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 304 insertions(+)
 create mode 100644 drivers/irqchip/irq-alpine-msi.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 715923d5236c..f20e5b28eb5f 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -60,6 +60,12 @@ config ARM_VIC_NR
 	  The maximum number of VICs available in the system, for
 	  power management.
 
+config ALPINE_MSI
+	bool
+	depends on PCI && PCI_MSI
+	select GENERIC_IRQ_CHIP
+	select PCI_MSI_IRQ_DOMAIN
+
 config ATMEL_AIC_IRQ
 	bool
 	select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 18caacb60d58..57f68e0eea74 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_IRQCHIP)			+= irqchip.o
 
+obj-$(CONFIG_ALPINE_MSI)		+= irq-alpine-msi.o
 obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2835.o
 obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2836.o
 obj-$(CONFIG_ARCH_EXYNOS)		+= exynos-combiner.o
diff --git a/drivers/irqchip/irq-alpine-msi.c b/drivers/irqchip/irq-alpine-msi.c
new file mode 100644
index 000000000000..435dd4ab3626
--- /dev/null
+++ b/drivers/irqchip/irq-alpine-msi.c
@@ -0,0 +1,297 @@
+/*
+ * Annapurna Labs MSIX support services
+ *
+ * Copyright (C) 2016, Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ *
+ * Antoine Tenart <antoine.tenart at free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/irqchip.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/msi.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_pci.h>
+#include <linux/pci.h>
+#include <linux/slab.h>
+
+#include <asm/irq.h>
+#include <asm-generic/msi.h>
+
+/* MSIX message address format: local GIC target */
+#define ALPINE_MSIX_SPI_TARGET_CLUSTER0		BIT(16)
+
+struct alpine_msix_data {
+	spinlock_t msi_map_lock;
+	u32 addr_high;
+	u32 addr_low;
+	u32 spi_first;		/* The SGI number that MSIs start */
+	u32 num_spis;		/* The number of SGIs for MSIs */
+	unsigned long *msi_map;
+};
+
+static void alpine_msix_mask_msi_irq(struct irq_data *d)
+{
+	pci_msi_mask_irq(d);
+	irq_chip_mask_parent(d);
+}
+
+static void alpine_msix_unmask_msi_irq(struct irq_data *d)
+{
+	pci_msi_unmask_irq(d);
+	irq_chip_unmask_parent(d);
+}
+
+static int alpine_msix_set_affinity(struct irq_data *irq_data,
+				    const struct cpumask *mask, bool force)
+{
+	int ret;
+
+	ret = irq_chip_set_affinity_parent(irq_data, mask, force);
+	return ret == IRQ_SET_MASK_OK ? IRQ_SET_MASK_OK_DONE : ret;
+}
+
+static struct irq_chip alpine_msix_irq_chip = {
+	.name			= "MSIx",
+	.irq_mask		= alpine_msix_mask_msi_irq,
+	.irq_unmask		= alpine_msix_unmask_msi_irq,
+	.irq_eoi		= irq_chip_eoi_parent,
+	.irq_set_affinity	= alpine_msix_set_affinity,
+};
+
+static int alpine_msix_allocate_sgi(struct alpine_msix_data *priv, int num_req)
+{
+	int first, i;
+
+	spin_lock(&priv->msi_map_lock);
+
+	first = bitmap_find_next_zero_area(priv->msi_map, priv->num_spis, 0,
+					   num_req, 0);
+	if (first >= priv->num_spis) {
+		spin_unlock(&priv->msi_map_lock);
+		return -ENOSPC;
+	}
+
+	for (i = 0; i < num_req; i++)
+		set_bit(first + i, priv->msi_map);
+
+	spin_unlock(&priv->msi_map_lock);
+
+	return priv->spi_first + first;
+}
+
+static void alpine_msix_free_sgi(struct alpine_msix_data *priv, unsigned sgi,
+				 int num_req)
+{
+	int i, first;
+
+	first = sgi - priv->spi_first;
+
+	spin_lock(&priv->msi_map_lock);
+
+	for (i = 0; i < num_req; i++)
+		clear_bit(first + i, priv->msi_map);
+
+	spin_unlock(&priv->msi_map_lock);
+}
+
+static void alpine_msix_compose_msi_msg(struct irq_data *data,
+					struct msi_msg *msg)
+{
+	struct alpine_msix_data *priv = irq_data_get_irq_chip_data(data);
+
+	msg->address_hi = priv->addr_high;
+	msg->address_lo = priv->addr_low + (data->hwirq << 3);
+	msg->data = 0;
+}
+
+static struct msi_domain_info alpine_msix_domain_info = {
+	.flags	= MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+		  MSI_FLAG_PCI_MSIX,
+	.chip	= &alpine_msix_irq_chip,
+};
+
+static struct irq_chip middle_irq_chip = {
+	.name			= "alpine_msix_middle",
+	.irq_mask		= irq_chip_mask_parent,
+	.irq_unmask		= irq_chip_unmask_parent,
+	.irq_eoi		= irq_chip_eoi_parent,
+	.irq_set_affinity	= irq_chip_set_affinity_parent,
+	.irq_compose_msi_msg	= alpine_msix_compose_msi_msg,
+};
+
+static int alpine_msix_gic_domain_alloc(struct irq_domain *domain,
+					unsigned int virq, int sgi)
+{
+	struct irq_fwspec fwspec;
+	struct irq_data *d;
+	int ret;
+
+	if (!is_of_node(domain->parent->fwnode))
+		return -EINVAL;
+
+	fwspec.fwnode = domain->parent->fwnode;
+	fwspec.param_count = 3;
+	fwspec.param[0] = 0;
+	fwspec.param[1] = sgi;
+	fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
+
+	ret = irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
+	if (ret)
+		return ret;
+
+	d = irq_domain_get_irq_data(domain->parent, virq);
+	d->chip->irq_set_type(d, IRQ_TYPE_EDGE_RISING);
+
+	return 0;
+}
+
+static int alpine_msix_middle_domain_alloc(struct irq_domain *domain,
+					   unsigned int virq,
+					   unsigned int nr_irqs, void *args)
+{
+	struct alpine_msix_data *priv = domain->host_data;
+	int sgi, err, i;
+
+	sgi = alpine_msix_allocate_sgi(priv, nr_irqs);
+	if (sgi < 0)
+		return sgi;
+
+	for (i = 0; i < nr_irqs; i++) {
+		err = alpine_msix_gic_domain_alloc(domain, virq + i, sgi + i);
+		if (err)
+			goto err_sgi;
+
+		irq_domain_set_hwirq_and_chip(domain, virq + i, sgi + i,
+					      &middle_irq_chip, priv);
+	}
+
+	return 0;
+
+err_sgi:
+	while (--i >= 0)
+		irq_domain_free_irqs_parent(domain, virq, i);
+	alpine_msix_free_sgi(priv, sgi, nr_irqs);
+	return err;
+}
+
+static void alpine_msix_middle_domain_free(struct irq_domain *domain,
+					   unsigned int virq,
+					   unsigned int nr_irqs)
+{
+	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+	struct alpine_msix_data *priv = irq_data_get_irq_chip_data(d);
+
+	irq_domain_free_irqs_parent(domain, virq, nr_irqs);
+	alpine_msix_free_sgi(priv, d->hwirq, nr_irqs);
+}
+
+static const struct irq_domain_ops alpine_msix_middle_domain_ops = {
+	.alloc	= alpine_msix_middle_domain_alloc,
+	.free	= alpine_msix_middle_domain_free,
+};
+
+static int alpine_msix_init_domains(struct alpine_msix_data *priv,
+				    struct device_node *node)
+{
+	struct irq_domain *middle_domain, *msi_domain, *gic_domain;
+	struct device_node *gic_node;
+
+	gic_node = of_irq_find_parent(node);
+	if (!gic_node) {
+		pr_err("Failed to find the GIC node\n");
+		return -ENODEV;
+	}
+
+	gic_domain = irq_find_host(gic_node);
+	if (!gic_domain) {
+		pr_err("Failed to find the GIC domain\n");
+		return -ENXIO;
+	}
+
+	middle_domain = irq_domain_add_tree(NULL,
+					    &alpine_msix_middle_domain_ops,
+					    priv);
+	if (!middle_domain) {
+		pr_err("Failed to create the MSIX middle domain\n");
+		return -ENOMEM;
+	}
+
+	middle_domain->parent = gic_domain;
+
+	msi_domain = pci_msi_create_irq_domain(of_node_to_fwnode(node),
+					       &alpine_msix_domain_info,
+					       middle_domain);
+	if (!msi_domain) {
+		pr_err("Failed to create MSI domain\n");
+		irq_domain_remove(msi_domain);
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+static int alpine_msix_init(struct device_node *node,
+			    struct device_node *parent)
+{
+	struct alpine_msix_data *priv;
+	struct resource res;
+	int ret;
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	spin_lock_init(&priv->msi_map_lock);
+
+	ret = of_address_to_resource(node, 0, &res);
+	if (ret) {
+		pr_err("Failed to allocate resource\n");
+		goto err_priv;
+	}
+
+	priv->addr_high = upper_32_bits((u64)res.start);
+	priv->addr_low = lower_32_bits(res.start) + ALPINE_MSIX_SPI_TARGET_CLUSTER0;
+
+	if (of_property_read_u32(node, "al,msi-base-spi", &priv->spi_first)) {
+		pr_err("Unable to parse MSI base\n");
+		ret = -EINVAL;
+		goto err_priv;
+	}
+
+	if (of_property_read_u32(node, "al,msi-num-spis", &priv->num_spis)) {
+		pr_err("Unable to parse MSI numbers\n");
+		ret = -EINVAL;
+		goto err_priv;
+	}
+
+	priv->msi_map = kzalloc(sizeof(*priv->msi_map) * BITS_TO_LONGS(priv->num_spis),
+				GFP_KERNEL);
+	if (!priv->msi_map) {
+		ret = -ENOMEM;
+		goto err_priv;
+	}
+
+	pr_debug("Registering %d msixs, starting at %d\n",
+		 priv->num_spis, priv->spi_first);
+
+	ret = alpine_msix_init_domains(priv, node);
+	if (ret)
+		goto err_map;
+
+	return 0;
+
+err_map:
+	kfree(priv->msi_map);
+err_priv:
+	kfree(priv);
+	return ret;
+}
+IRQCHIP_DECLARE(alpine_msix, "al,alpine-msix", alpine_msix_init);
-- 
2.7.0



From antoine.tenart at free-electrons.com  Mon Feb  8 01:16:11 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon,  8 Feb 2016 10:16:11 +0100
Subject: [PATCH 6/6] arm: alpine: select the Alpine MSI controller driver
In-Reply-To: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1454922971-17405-7-git-send-email-antoine.tenart@free-electrons.com>

Select the Alpine MSI controller driver when using an Alpine platform.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 arch/arm/mach-alpine/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-alpine/Kconfig b/arch/arm/mach-alpine/Kconfig
index 5c2d54f59f53..b41838a58ae4 100644
--- a/arch/arm/mach-alpine/Kconfig
+++ b/arch/arm/mach-alpine/Kconfig
@@ -1,6 +1,7 @@
 config ARCH_ALPINE
 	bool "Annapurna Labs Alpine platform"
 	depends on ARCH_MULTI_V7
+	select ALPINE_MSI
 	select ARM_AMBA
 	select ARM_GIC
 	select GENERIC_IRQ_CHIP
-- 
2.7.0



From antoine.tenart at free-electrons.com  Mon Feb  8 01:16:10 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon,  8 Feb 2016 10:16:10 +0100
Subject: [PATCH 5/6] arm64: alpine: select the Alpine MSI controller driver
In-Reply-To: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1454922971-17405-6-git-send-email-antoine.tenart@free-electrons.com>

Select the Alpine MSI controller driver when using an Alpine platform.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index bfbefa3e0dbe..6761e12e5e13 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -2,6 +2,7 @@ menu "Platform selection"
 
 config ARCH_ALPINE
 	bool "Annapurna Labs Alpine platform"
+	select ALPINE_MSI
 	help
 	  This enables support for the Annapurna Labs Alpine
 	  Soc family.
-- 
2.7.0



From j-keerthy at ti.com  Mon Feb  8 01:16:27 2016
From: j-keerthy at ti.com (Keerthy)
Date: Mon, 8 Feb 2016 14:46:27 +0530
Subject: [PATCH 0/3] arm: dts: DRA7: Add IVA and DSPEVE thermal domain data
Message-ID: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>

OMAP5 has 3 thermal zones cpu, core and multimedia.
On the other hand DRA7 has 5 thermal zones cpu, gpu, core, dspeve
and iva. Currently cpu, core and multimedia are being added via dt
and the other 2 are getting added via kernel. Add the missing thermal
domains in dt so as give the correct trip numbers, type and temperatures.

Tested on DRA7-EVM.
 
Keerthy (3):
  arm: dts: DRA7: Add DSPEVE thermal data
  arm: dts: DRA7: Add IVA thermal data
  arm: dts: DRA7: Add missing IVA and DSPEVE thermal domain data

 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi | 27 +++++++++++++++++++++++++++
 arch/arm/boot/dts/dra7-iva-thermal.dtsi    | 27 +++++++++++++++++++++++++++
 arch/arm/boot/dts/dra7.dtsi                |  2 ++
 3 files changed, 56 insertions(+)
 create mode 100644 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi
 create mode 100644 arch/arm/boot/dts/dra7-iva-thermal.dtsi

-- 
1.9.1



From j-keerthy at ti.com  Mon Feb  8 01:16:29 2016
From: j-keerthy at ti.com (Keerthy)
Date: Mon, 8 Feb 2016 14:46:29 +0530
Subject: [PATCH 2/3] arm: dts: DRA7: Add IVA thermal data
In-Reply-To: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>
References: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>
Message-ID: <1454922990-7501-3-git-send-email-j-keerthy@ti.com>

This patch changes a dtsi file to contain the thermal data
for IVA domain. This data will enable a thermal shutdown at 125C.

Signed-off-by: Keerthy <j-keerthy at ti.com>
---
 arch/arm/boot/dts/dra7-iva-thermal.dtsi | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 arch/arm/boot/dts/dra7-iva-thermal.dtsi

diff --git a/arch/arm/boot/dts/dra7-iva-thermal.dtsi b/arch/arm/boot/dts/dra7-iva-thermal.dtsi
new file mode 100644
index 0000000..dd74a53
--- /dev/null
+++ b/arch/arm/boot/dts/dra7-iva-thermal.dtsi
@@ -0,0 +1,27 @@
+/*
+ * Device Tree Source for DRA7x SoC IVA thermal
+ *
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/thermal/thermal.h>
+
+iva_thermal: iva_thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <500>; /* milliseconds */
+
+			/* sensor       ID */
+	thermal-sensors = <&bandgap     4>;
+
+	trips {
+		iva_crit: iva_crit {
+			temperature = <125000>; /* milliCelsius */
+			hysteresis = <2000>; /* milliCelsius */
+			type = "critical";
+		};
+	};
+};
-- 
1.9.1



From j-keerthy at ti.com  Mon Feb  8 01:16:28 2016
From: j-keerthy at ti.com (Keerthy)
Date: Mon, 8 Feb 2016 14:46:28 +0530
Subject: [PATCH 1/3] arm: dts: DRA7: Add DSPEVE thermal data
In-Reply-To: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>
References: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>
Message-ID: <1454922990-7501-2-git-send-email-j-keerthy@ti.com>

This patch changes a dtsi file to contain the thermal data
for DSPEVE domain. This data will enable a thermal shutdown at 125C.

Signed-off-by: Keerthy <j-keerthy at ti.com>
---
 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi

diff --git a/arch/arm/boot/dts/dra7-dspeve-thermal.dtsi b/arch/arm/boot/dts/dra7-dspeve-thermal.dtsi
new file mode 100644
index 0000000..1c39a84
--- /dev/null
+++ b/arch/arm/boot/dts/dra7-dspeve-thermal.dtsi
@@ -0,0 +1,27 @@
+/*
+ * Device Tree Source for DRA7x SoC DSPEVE thermal
+ *
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/thermal/thermal.h>
+
+dspeve_thermal: dspeve_thermal {
+	polling-delay-passive = <250>; /* milliseconds */
+	polling-delay = <500>; /* milliseconds */
+
+			/* sensor       ID */
+	thermal-sensors = <&bandgap     3>;
+
+	trips {
+		dspeve_crit: dspeve_crit {
+			temperature = <125000>; /* milliCelsius */
+			hysteresis = <2000>; /* milliCelsius */
+			type = "critical";
+		};
+	};
+};
-- 
1.9.1



From j-keerthy at ti.com  Mon Feb  8 01:16:30 2016
From: j-keerthy at ti.com (Keerthy)
Date: Mon, 8 Feb 2016 14:46:30 +0530
Subject: [PATCH 3/3] arm: dts: DRA7: Add missing IVA and DSPEVE thermal domain
 data
In-Reply-To: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>
References: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>
Message-ID: <1454922990-7501-4-git-send-email-j-keerthy@ti.com>

OMAP5 has 3 thermal zones cpu, core and multimedia.
On the other hand DRA7 has 5 thermal zones cpu, gpu, core, dspeve
and iva. Currently cpu, core and multimedia are being added via device tree
and the other 2 are getting added via kernel. Add the missing thermal
domains in device tree so we can create the zones with the appropriate
trip numbers, type and temperatures.

Signed-off-by: Keerthy <j-keerthy at ti.com>
---
 arch/arm/boot/dts/dra7.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index c4d9175..9f65d0d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1603,6 +1603,8 @@
 		#include "omap4-cpu-thermal.dtsi"
 		#include "omap5-gpu-thermal.dtsi"
 		#include "omap5-core-thermal.dtsi"
+		#include "dra7-dspeve-thermal.dtsi"
+		#include "dra7-iva-thermal.dtsi"
 	};
 
 };
-- 
1.9.1



From horms at verge.net.au  Mon Feb  8 01:21:45 2016
From: horms at verge.net.au (Simon Horman)
Date: Mon, 8 Feb 2016 10:21:45 +0100
Subject: [PATCH v2] arm64: dts: r8a7795: pmu: switch to Cortex specific
 device nodes
In-Reply-To: <56B47378.3080209@de.bosch.com>
References: <1452953636-4995-1-git-send-email-dirk.behme@gmail.com>
 <56B236F4.4090409@gmail.com> <20160205095445.GD16556@verge.net.au>
 <56B47378.3080209@de.bosch.com>
Message-ID: <20160208092145.GA15520@verge.net.au>

On Fri, Feb 05, 2016 at 11:03:36AM +0100, Dirk Behme wrote:
> On 05.02.2016 10:54, Simon Horman wrote:
> >[CC shiny new linux-renesas-soc ML]
> 
> 
> Yes, thanks. I've to learn and remember this, too :)
> 
> 
> >On Wed, Feb 03, 2016 at 06:20:52PM +0100, Dirk Behme wrote:
> >>On 16.01.2016 15:13, Dirk Behme wrote:
> >>>Instead of using the generic armv8-pmuv3 compatibility use the more
> >>>specific Cortex A57 compatibility.
> >>>
> >>>Signed-off-by: Dirk Behme <dirk.behme at gmail.com>
> >>>---
> >>>Changes in v2: Drop the not yet merged Cortex A53 part.
> >>>
> >>>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>>diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> >>>index 266c5de..a82bce8 100644
> >>>--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> >>>+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> >>>@@ -247,8 +247,8 @@
> >>>  			power-domains = <&cpg>;
> >>>  		};
> >>>
> >>>-		pmu {
> >>>-			compatible = "arm,armv8-pmuv3";
> >>>+		pmu_a57 {
> >>>+			compatible = "arm,cortex-a57-pmu";
> >>>  			interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
> >>>  				     <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
> >>>  				     <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
> >>>
> >>
> >>
> >>Any further comments to this? If not, could this be applied?
> >
> >Hi Dirk,
> >
> >I apologise for loosing track of this one.
> >
> >Does this change work? I saw some discussion about using arm,cortex-a57-pmu
> >not working correctly on the r8a7795 in an earlier thread.
> 
> Yes, the A57 PMU probe is successful.
> 
> What's not working with the latest Renesas BSP is the A53, because these
> cores are disabled in the firmware coming with that BSP. But that's not a
> PMU issue, it's just because the cores are disabled. Using an older BSP
> firmware enabling all cores makes the A53 PMU probe fine, too.

Thanks for the explanation. I have queued up this patch.


From heiko at sntech.de  Mon Feb  8 01:27:04 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 08 Feb 2016 10:27:04 +0100
Subject: [PATCH v7 0/9] Fix broken DMAFLUSHP on Rockchips platform
In-Reply-To: <20160208031134.GI2531@localhost>
References: <1453460812-8498-1-git-send-email-wxt@rock-chips.com>
 <56AF01B6.6030204@gmail.com> <20160208031134.GI2531@localhost>
Message-ID: <3817335.PXCk0JfYDT@phil>

Hi Vinod,

Am Montag, 8. Februar 2016, 08:41:34 schrieb Vinod Koul:
> On Mon, Feb 01, 2016 at 02:56:54PM +0800, Caesar Wang wrote:
> > Hello Vinod,
> > 
> > Is there any chance apply the DMA patches?:-)
> 
> I was waiting for any ACKs on ARM patches before I merge this series.

I think the more regular way is for the driver maintainer to take the 
driver-specific stuff and the devicetree parts going through the specific arm-
tree. But if you really want to take the whole series, for patches 4,5,6

- ARM: dts: Add arm, pl330-broken-no-flushp quirk for rk3288 platform
- ARM: dts: Add arm, pl330-broken-no-flushp quirk for rk3xxx platform
- ARM: dts: add pl330-broken-no-flushp quirk for rk3036 SoCs

Acked-by: Heiko Stuebner <heiko at sntech.de>


Heiko


From k at japko.eu  Mon Feb  8 01:31:14 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Mon, 8 Feb 2016 10:31:14 +0100
Subject: [PATCH] ARM: dts: sunxi: Fix #interrupt-cells for PIO in H3
Message-ID: <20160208093113.GA6268@box2.japko.eu>

pinctrl-sunxi uses 3 cells to describe interrupt, not 2. It's bank
number, pin number and flags.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 6f6b4e4..96c899a 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -368,7 +368,7 @@
 			gpio-controller;
 			#gpio-cells = <3>;
 			interrupt-controller;
-			#interrupt-cells = <2>;
+			#interrupt-cells = <3>;
 
 			uart0_pins_a: uart0 at 0 {
 				allwinner,pins = "PA4", "PA5";
-- 
2.4.2



From andre.przywara at arm.com  Mon Feb  8 01:42:35 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 8 Feb 2016 09:42:35 +0000
Subject: [PATCH 10/11] arm64: dts: add Allwinner A64 SoC .dtsi
In-Reply-To: <20160205085026.GA1139@lukather>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-11-git-send-email-andre.przywara@arm.com>
 <20160205085026.GA1139@lukather>
Message-ID: <56B8630B.8060608@arm.com>

Hi,

On 05/02/16 08:50, Maxime Ripard wrote:
> Hi Andre,
> 
> On Mon, Feb 01, 2016 at 05:39:29PM +0000, Andre Przywara wrote:
>> The Allwinner A64 SoC is low-cost SoC with 4 ARM Cortex-A53 cores
>> and the typical tablet / TV box peripherals.
>> The Soc is based on the (32-bit) Allwinner H3 chip, sharing most of
>> the peripherals and the memory map.
>> Although the cores are proper 64-bit ones, the whole SoC is actually
>> limited to 4GB (including all the supported DRAM), so we use 32-bit
>> address and size cells. This has the nice feature of us being able to
>> reuse the DT for 32-bit kernels as well.
>> This .dtsi lists the hardware that we support so far.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>> ---
>>  Documentation/devicetree/bindings/arm/sunxi.txt   |   1 +
>>  Documentation/devicetree/bindings/clock/sunxi.txt |   1 +
>>  arch/arm64/boot/dts/allwinner/a64.dtsi            | 583 ++++++++++++++++++++++
>>  3 files changed, 585 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/allwinner/a64.dtsi
>>
>> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
>> index 980e065..4a83853 100644
>> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
>> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
>> @@ -14,6 +14,7 @@ using one of the following compatible strings:
>>    allwinner,sun8i-a83t
>>    allwinner,sun8i-h3
>>    allwinner,sun9i-a80
>> +  allwinner,a64
>>  
>>  For Allwinner SoCs without any specific needs the generic fallback value of:
>>    allwinner,sunxi
>> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
>> index e59f57b..44b0c6c 100644
>> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
>> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
>> @@ -77,6 +77,7 @@ Required properties:
>>  	"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
>>  	"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
>>  	"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
>> +	"allwinner,a64-bus-gates-clk" - for the A64 multi-parent bus gates clock
>>  
>>  Required properties for all clocks:
>>  - reg : shall be the control register address for the clock.
>> diff --git a/arch/arm64/boot/dts/allwinner/a64.dtsi b/arch/arm64/boot/dts/allwinner/a64.dtsi
>> new file mode 100644
>> index 0000000..8dce10f
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/a64.dtsi
>> @@ -0,0 +1,583 @@
>> +/*
>> + * Copyright (C) 2016 ARM Ltd.
>> + * based on the Allwinner H3 dtsi:
>> + *    Copyright (C) 2015 Jens Kuske <jenskuske at gmail.com>
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This file is free software; you can redistribute it and/or
>> + *     modify it under the terms of the GNU General Public License as
>> + *     published by the Free Software Foundation; either version 2 of the
>> + *     License, or (at your option) any later version.
>> + *
>> + *     This file is distributed in the hope that it will be useful,
>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *     GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + *     obtaining a copy of this software and associated documentation
>> + *     files (the "Software"), to deal in the Software without
>> + *     restriction, including without limitation the rights to use,
>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>> + *     sell copies of the Software, and to permit persons to whom the
>> + *     Software is furnished to do so, subject to the following
>> + *     conditions:
>> + *
>> + *     The above copyright notice and this permission notice shall be
>> + *     included in all copies or substantial portions of the Software.
>> + *
>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + *     OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>> +
>> +/ {
>> +	compatible = "allwinner,a64", "allwinner,sunxi";
>> +	interrupt-parent = <&gic>;
>> +	#address-cells = <1>;
>> +	#size-cells = <1>;
>> +
>> +	aliases {
>> +		serial0 = &uart0;
>> +		serial1 = &uart1;
>> +		serial2 = &uart2;
>> +		serial3 = &uart3;
>> +		serial4 = &uart4;
>> +	};
> 
> The aliases are usually per-board, as it will vary depending on what
> the board enables.

Sure.

> 
>> +
>> +	cpus {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +
>> +		cpu at 0 {
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			device_type = "cpu";
>> +			reg = <0>;
>> +			enable-method = "psci";
>> +		};
>> +
>> +		cpu at 1 {
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			device_type = "cpu";
>> +			reg = <1>;
>> +			enable-method = "psci";
>> +		};
>> +
>> +		cpu at 2 {
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			device_type = "cpu";
>> +			reg = <2>;
>> +			enable-method = "psci";
>> +		};
>> +
>> +		cpu at 3 {
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			device_type = "cpu";
>> +			reg = <3>;
>> +			enable-method = "psci";
>> +		};
>> +	};
>> +
>> +	psci {
>> +		compatible = "arm,psci-0.2", "arm,psci";
>> +		method = "smc";
>> +		cpu_suspend = <0xc4000001>;
>> +		cpu_off = <0x84000002>;
>> +		cpu_on = <0xc4000003>;
>> +	};
> 
> I thought that the function IDs were not needed anymore with PSCI 0.2?

The idea here was to provide compatibility with older OSes not
supporting PSCI 0.2, those would match on the "arm,psci" compatible
string and require the numbers (see bindings/arm/psci.txt).

Thinking again I realise that we require PSCI 0.2 for having reset and
shutdown, so I will drop this and just provide the 0.2 compatible string.

>> +	memory {
>> +		device_type = "memory";
>> +		reg = <0x40000000 0>;
>> +	};
> 
> I'm guessing u-boot fixes that, can we just remove it entirely?

Don't know, can we? I found it nice to have it in here to give people at
the least the idea of where DRAM starts and also making it clear that a
bootloader is expected to patch this (and having a node already makes
patching easier).

>> +	timer {
>> +		compatible = "arm,armv8-timer";
>> +		interrupts = <GIC_PPI 13
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			     <GIC_PPI 14
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			     <GIC_PPI 11
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			     <GIC_PPI 10
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>> +	};
>> +
>> +	clocks {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		ranges;
>> +
>> +		osc24M: osc24M_clk {
>> +			#clock-cells = <0>;
>> +			compatible = "fixed-clock";
>> +			clock-frequency = <24000000>;
>> +			clock-output-names = "osc24M";
>> +		};
>> +
>> +		osc32k: osc32k_clk {
>> +			#clock-cells = <0>;
>> +			compatible = "fixed-clock";
>> +			clock-frequency = <32768>;
>> +			clock-output-names = "osc32k";
>> +		};
>> +
>> +		pll1: clk at 01c20000 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun8i-a23-pll1-clk";
>> +			reg = <0x01c20000 0x4>;
>> +			clocks = <&osc24M>;
>> +			clock-output-names = "pll1";
>> +		};
>> +
>> +		pll6: clk at 01c20028 {
>> +			#clock-cells = <1>;
>> +			compatible = "allwinner,sun6i-a31-pll6-clk";
>> +			reg = <0x01c20028 0x4>;
>> +			clocks = <&osc24M>;
>> +			clock-output-names = "pll6", "pll6x2";
> 
> The output names have changed, and it doesn't take an argument
> anymore.

Would be happy to adapt to this, but we should sort this approach out
(see the other mail).

>> +		};
>> +
>> +		pll6d2: pll6d2_clk {
>> +			#clock-cells = <0>;
>> +			compatible = "fixed-factor-clock";
>> +			clock-div = <2>;
>> +			clock-mult = <1>;
>> +			clocks = <&pll6 0>;
>> +			clock-output-names = "pll6d2";
>> +		};
>> +
>> +		/* dummy clock until pll6 can be reused */
>> +		pll8: pll8_clk {
>> +			#clock-cells = <0>;
>> +			compatible = "fixed-clock";
>> +			clock-frequency = <1>;
>> +			clock-output-names = "pll8";
>> +		};
>> +
>> +		cpu: cpu_clk at 01c20050 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun4i-a10-cpu-clk";
>> +			reg = <0x01c20050 0x4>;
>> +			clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
>> +			clock-output-names = "cpu";
>> +			critical-clocks = <0>;
>> +		};
>> +
>> +		axi: axi_clk at 01c20050 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun4i-a10-axi-clk";
>> +			reg = <0x01c20050 0x4>;
>> +			clocks = <&cpu>;
>> +			clock-output-names = "axi";
>> +		};
>> +
>> +		ahb1: ahb1_clk at 01c20054 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun6i-a31-ahb1-clk";
>> +			reg = <0x01c20054 0x4>;
>> +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
>> +			clock-output-names = "ahb1";
>> +		};
>> +
>> +		ahb2: ahb2_clk at 01c2005c {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun8i-h3-ahb2-clk";
>> +			reg = <0x01c2005c 0x4>;
>> +			clocks = <&ahb1>, <&pll6d2>;
>> +			clock-output-names = "ahb2";
>> +		};
>> +
>> +		apb1: apb1_clk at 01c20054 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun4i-a10-apb0-clk";
>> +			reg = <0x01c20054 0x4>;
>> +			clocks = <&ahb1>;
>> +			clock-output-names = "apb1";
>> +		};
>> +
>> +		apb2: apb2_clk at 01c20058 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun4i-a10-apb1-clk";
>> +			reg = <0x01c20058 0x4>;
>> +			clocks = <&osc32k>, <&osc24M>, <&pll6 1>, <&pll6 1>;
>> +			clock-output-names = "apb2";
>> +		};
>> +
>> +		bus_gates: clk at 01c20060 {
>> +			#clock-cells = <1>;
>> +			compatible = "allwinner,a64-bus-gates-clk",
>> +				     "allwinner,sunxi-multi-bus-gates-clk";
>> +			reg = <0x01c20060 0x14>;
>> +			ahb1_parent {
>> +				clocks = <&ahb1>;
>> +				clock-indices = <1>, <5>,
>> +						<6>, <8>,
>> +						<9>, <10>,
>> +						<13>, <14>,
>> +						<18>, <19>,
>> +						<20>, <21>,
>> +						<23>, <24>,
>> +						<25>, <28>,
>> +						<32>, <35>,
>> +						<36>, <37>,
>> +						<40>, <43>,
>> +						<44>, <52>,
>> +						<53>, <54>,
>> +						<135>;
>> +				clock-output-names = "bus_mipidsi", "bus_ce",
>> +						"bus_dma", "bus_mmc0",
>> +						"bus_mmc1", "bus_mmc2",
>> +						"bus_nand", "bus_sdram",
>> +						"bus_ts", "bus_hstimer",
>> +						"bus_spi0", "bus_spi1",
>> +						"bus_otg", "bus_otg_ehci0",
>> +						"bus_ehci0", "bus_otg_ohci0",
>> +						"bus_ve", "bus_lcd0",
>> +						"bus_lcd1", "bus_deint",
>> +						"bus_csi", "bus_hdmi",
>> +						"bus_de", "bus_gpu",
>> +						"bus_msgbox", "bus_spinlock",
>> +						"bus_dbg";
>> +			};
>> +			ahb2_parent {
>> +				clocks = <&ahb2>;
>> +				clock-indices = <17>, <29>;
>> +				clock-output-names = "bus_gmac", "bus_ohci0";
>> +			};
>> +			apb1_parent {
>> +				clocks = <&apb1>;
>> +				clock-indices = <64>, <65>,
>> +						<69>, <72>,
>> +						<76>, <77>,
>> +						<78>;
>> +				clock-output-names = "bus_codec", "bus_spdif",
>> +						"bus_pio", "bus_ths",
>> +						"bus_i2s0", "bus_i2s1",
>> +						"bus_i2s2";
>> +			};
>> +			abp2_parent {
>> +				clocks = <&apb2>;
>> +				clock-indices = <96>, <97>,
>> +						<98>, <101>,
>> +						<112>, <113>,
>> +						<114>, <115>,
>> +						<116>;
>> +				clock-output-names = "bus_i2c0", "bus_i2c1",
>> +						"bus_i2c2", "bus_scr",
>> +						"bus_uart0", "bus_uart1",
>> +						"bus_uart2", "bus_uart3",
>> +						"bus_uart4";
>> +			};
>> +		};
> 
> As I've already told you I'm not really fond of this one, for two main
> topics.
> 
> The first one is about the DT bindings itself which is quite exotic,
> especially the fact that you define clocks using clocks, clock-indices
> and clock-output-names in nodes that are not the one referred to by
> consumer, which goes against both the clock bindings documentation and
> the usage.

You are right in one point: it is not documented. I just see that I
forgot to update the bindings doc and describe this behaviour there.

But I don't see an issue with abstracting the clock provider's internal
details by referring to the parent node and use the DT's natural tree
structure to properly represent these clock gates. I cannot read
anything in clock-bindings.txt that would prevent this.

Happy to hear from DT maintainers about it.

> The second one is pretty much the same one than for the discussion we
> had about pinctrl. There is SoCs where we simply don't have that
> information, or at least are not really sure about what to put where
> (namely, the A83t). In such a case, we would knowingly put invalid
> information in the DT, which is already quite bad in itself.

And in your case we would put knowingly invalid information into the kernel?
So what is wrong with just _not_ putting this information until we know
it? With my patch you would just enumerate the gates we know the parents
of so far. Once we learn about the other gates, we add them. If we don't
know the parent, we probably can't use it anyway, I guess.
So we do as we do with other new features: updated DTs provide new
functionality.

And also: this is about A64, not A83t.

> The worst
> part is, when we will identify issues and fix them (hopefully), there
> will be no way to fix the current DT users.

But if we have a broken DT out there where a feature never worked or had
bugs, we _can_ fix it. Interested users will upgrade their DT and are
able to use the new feature or run without bugs now. This mimics the
approach when we add features: users update. However if users are happy
with the current feature set or are not affected by the bug, they can
use the older DT.

Also from my point of view it is much harder to provide an updated
kernel to people, since every distribution would need to pick up the
changes and provide updates to their users.

> And it just became a pain to maintain in the long run.

How so?

> On the opposite side, having something like the H3 bus gates driver
> address all these concerns and is easily extensible, which is why we
> ended up merging it.

Speaking of this driver: I really dislike that it hardcodes Soc specific
information into the kernel. I consider this bad style. The clock gates
are a rather generic functionality (one bit per gate), and we provide
the SoC specific part (mapping names and bit numbers) already in the DT.
So with the parent relation in the code we hide some information from
the DT which clearly belongs there, also ending up with having something
in the kernel and something in the DT.
Also this requires to add support for each and every SoC explicitly in
the kernel.

Also please keep in mind that the DT is not just for Linux: why should
other OS developers hard code the same information over and over again
when we could have it once for everybody in the DT?

I think we should stop with supporting each and every SoC explicitly in
the kernel and go for more generic drivers, that use DTs to describe
each SoC.
That way we can eventually reach the point where we have (at least)
basic functionality for a new SoC in existing(!) kernels - like from a
LTS style distribution kernel.
New SoCs would just come with their DTs as part of their firmware, as
it's the case with many arm64 boards out there at the moment. As long as
they don't have fundamentally new IP blocks (for the basic
functionality), that could just work out of the box.

> So please use it.

I really rather would avoid doing this.

I would appreciate if other people could comment on this.

> 
>> +		mmc0_clk: clk at 01c20088 {
>> +			#clock-cells = <1>;
>> +			compatible = "allwinner,sun4i-a10-mmc-clk";
>> +			reg = <0x01c20088 0x4>;
>> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>> +			clock-output-names = "mmc0",
>> +					     "mmc0_output",
>> +					     "mmc0_sample";
>> +		};
>> +
>> +		mmc1_clk: clk at 01c2008c {
>> +			#clock-cells = <1>;
>> +			compatible = "allwinner,sun4i-a10-mmc-clk";
>> +			reg = <0x01c2008c 0x4>;
>> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>> +			clock-output-names = "mmc1",
>> +					     "mmc1_output",
>> +					     "mmc1_sample";
>> +		};
>> +
>> +		mmc2_clk: clk at 01c20090 {
>> +			#clock-cells = <1>;
>> +			compatible = "allwinner,sun4i-a10-mmc-clk";
>> +			reg = <0x01c20090 0x4>;
>> +			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>> +			clock-output-names = "mmc2",
>> +					     "mmc2_output",
>> +					     "mmc2_sample";
>> +		};
>> +	};
>> +
>> +	regulators {
>> +		reg_vcc3v3: vcc3v3 {
>> +			compatible = "regulator-fixed";
>> +			regulator-name = "vcc3v3";
>> +			regulator-min-microvolt = <3300000>;
>> +			regulator-max-microvolt = <3300000>;
>> +		};
>> +	};
>> +
>> +	soc {
>> +		compatible = "simple-bus";
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		ranges;
>> +
>> +		mmc0: mmc at 01c0f000 {
>> +			compatible = "allwinner,sun5i-a13-mmc";
>> +			reg = <0x01c0f000 0x1000>;
>> +			clocks = <&bus_gates 8>,
>> +				 <&mmc0_clk 0>,
>> +				 <&mmc0_clk 1>,
>> +				 <&mmc0_clk 2>;
>> +			clock-names = "ahb",
>> +				      "mmc",
>> +				      "output",
>> +				      "sample";
>> +			resets = <&ahb_rst 8>;
>> +			reset-names = "ahb";
>> +			interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
>> +			status = "disabled";
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +		};
>> +
>> +		mmc1: mmc at 01c10000 {
>> +			compatible = "allwinner,sun5i-a13-mmc";
>> +			reg = <0x01c10000 0x1000>;
>> +			clocks = <&bus_gates 9>,
>> +				 <&mmc1_clk 0>,
>> +				 <&mmc1_clk 1>,
>> +				 <&mmc1_clk 2>;
>> +			clock-names = "ahb",
>> +				      "mmc",
>> +				      "output",
>> +				      "sample";
>> +			resets = <&ahb_rst 9>;
>> +			reset-names = "ahb";
>> +			interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
>> +			status = "disabled";
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +		};
>> +
>> +		mmc2: mmc at 01c11000 {
>> +			compatible = "allwinner,sun5i-a13-mmc";
>> +			reg = <0x01c11000 0x1000>;
>> +			clocks = <&bus_gates 10>,
>> +				 <&mmc2_clk 0>,
>> +				 <&mmc2_clk 1>,
>> +				 <&mmc2_clk 2>;
>> +			clock-names = "ahb",
>> +				      "mmc",
>> +				      "output",
>> +				      "sample";
>> +			resets = <&ahb_rst 10>;
>> +			reset-names = "ahb";
>> +			interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
>> +			status = "disabled";
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +		};
>> +
>> +		pio: pinctrl at 01c20800 {
>> +			compatible = "allwinner,a64-pinctrl";
>> +			reg = <0x01c20800 0x400>;
>> +			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
>> +			clocks = <&bus_gates 69>;
>> +			gpio-controller;
>> +			#gpio-cells = <3>;
>> +			interrupt-controller;
>> +			#interrupt-cells = <2>;
>> +
>> +			uart0_pins_a: uart0 at 0 {
>> +				allwinner,pins = "PB8", "PB9";
>> +				allwinner,function = "uart0";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart0_pins_b: uart0 at 1 {
>> +				allwinner,pins = "PF2", "PF3";
>> +				allwinner,function = "uart0";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart1_pins: uart1 at 0 {
>> +				allwinner,pins = "PG6", "PG7", "PG8", "PG9";
>> +				allwinner,function = "uart1";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart2_pins: uart2 at 0 {
>> +				allwinner,pins = "PB0", "PB1", "PB2", "PB3";
>> +				allwinner,function = "uart2";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart3_pins_a: uart3 at 0 {
>> +				allwinner,pins = "PD0", "PD1";
>> +				allwinner,function = "uart3";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
>> +
>> +			uart3_pins_b: uart3 at 1 {
>> +				allwinner,pins = "PH4", "PH5", "PH6", "PH7";
>> +				allwinner,function = "uart3";
>> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +			};
> 
> You have several options for all these controllers, which is why we
> have the _a or _b suffices.
> 
> Usually, the uart pins we had were only using RX and TX, I guess you
> could add a separate node for the RTS / CTS pins if some board want to
> use them.

Makes sense. Do you want the RTS/CTS pins in a separate child node or
another variant (like uart3_pins_b_hwhs) with all four pins in addition
to the two-pin version?

Cheers,
Andre


From marc.zyngier at arm.com  Mon Feb  8 01:44:49 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 8 Feb 2016 09:44:49 +0000
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <56B86391.1030609@arm.com>

Hi Antoine,

On 08/02/16 09:16, Antoine Tenart wrote:
> This patch adds the Alpine MSIX interrupt controller driver.
> 
> Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
> Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
> ---
>  drivers/irqchip/Kconfig          |   6 +
>  drivers/irqchip/Makefile         |   1 +
>  drivers/irqchip/irq-alpine-msi.c | 297 +++++++++++++++++++++++++++++++++++++++
>  3 files changed, 304 insertions(+)
>  create mode 100644 drivers/irqchip/irq-alpine-msi.c
> 
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index 715923d5236c..f20e5b28eb5f 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -60,6 +60,12 @@ config ARM_VIC_NR
>  	  The maximum number of VICs available in the system, for
>  	  power management.
>  
> +config ALPINE_MSI
> +	bool
> +	depends on PCI && PCI_MSI
> +	select GENERIC_IRQ_CHIP
> +	select PCI_MSI_IRQ_DOMAIN
> +
>  config ATMEL_AIC_IRQ
>  	bool
>  	select GENERIC_IRQ_CHIP
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 18caacb60d58..57f68e0eea74 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_IRQCHIP)			+= irqchip.o
>  
> +obj-$(CONFIG_ALPINE_MSI)		+= irq-alpine-msi.o
>  obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2835.o
>  obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2836.o
>  obj-$(CONFIG_ARCH_EXYNOS)		+= exynos-combiner.o
> diff --git a/drivers/irqchip/irq-alpine-msi.c b/drivers/irqchip/irq-alpine-msi.c
> new file mode 100644
> index 000000000000..435dd4ab3626
> --- /dev/null
> +++ b/drivers/irqchip/irq-alpine-msi.c
> @@ -0,0 +1,297 @@
> +/*
> + * Annapurna Labs MSIX support services
> + *
> + * Copyright (C) 2016, Amazon.com, Inc. or its affiliates. All Rights Reserved.
> + *
> + * Antoine Tenart <antoine.tenart at free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/irqchip.h>
> +#include <linux/irqchip/arm-gic.h>
> +#include <linux/msi.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_pci.h>
> +#include <linux/pci.h>
> +#include <linux/slab.h>
> +
> +#include <asm/irq.h>
> +#include <asm-generic/msi.h>
> +
> +/* MSIX message address format: local GIC target */
> +#define ALPINE_MSIX_SPI_TARGET_CLUSTER0		BIT(16)
> +
> +struct alpine_msix_data {
> +	spinlock_t msi_map_lock;
> +	u32 addr_high;
> +	u32 addr_low;

As this looks to be a physical address, please consider using phys_addr_t.

> +	u32 spi_first;		/* The SGI number that MSIs start */
> +	u32 num_spis;		/* The number of SGIs for MSIs */
> +	unsigned long *msi_map;
> +};
> +
> +static void alpine_msix_mask_msi_irq(struct irq_data *d)
> +{
> +	pci_msi_mask_irq(d);
> +	irq_chip_mask_parent(d);
> +}
> +
> +static void alpine_msix_unmask_msi_irq(struct irq_data *d)
> +{
> +	pci_msi_unmask_irq(d);
> +	irq_chip_unmask_parent(d);
> +}
> +
> +static int alpine_msix_set_affinity(struct irq_data *irq_data,
> +				    const struct cpumask *mask, bool force)
> +{
> +	int ret;
> +
> +	ret = irq_chip_set_affinity_parent(irq_data, mask, force);
> +	return ret == IRQ_SET_MASK_OK ? IRQ_SET_MASK_OK_DONE : ret;
> +}
> +
> +static struct irq_chip alpine_msix_irq_chip = {
> +	.name			= "MSIx",
> +	.irq_mask		= alpine_msix_mask_msi_irq,
> +	.irq_unmask		= alpine_msix_unmask_msi_irq,
> +	.irq_eoi		= irq_chip_eoi_parent,
> +	.irq_set_affinity	= alpine_msix_set_affinity,
> +};
> +
> +static int alpine_msix_allocate_sgi(struct alpine_msix_data *priv, int num_req)
> +{
> +	int first, i;
> +
> +	spin_lock(&priv->msi_map_lock);
> +
> +	first = bitmap_find_next_zero_area(priv->msi_map, priv->num_spis, 0,
> +					   num_req, 0);
> +	if (first >= priv->num_spis) {
> +		spin_unlock(&priv->msi_map_lock);
> +		return -ENOSPC;
> +	}
> +
> +	for (i = 0; i < num_req; i++)
> +		set_bit(first + i, priv->msi_map);
> +
> +	spin_unlock(&priv->msi_map_lock);
> +
> +	return priv->spi_first + first;
> +}
> +
> +static void alpine_msix_free_sgi(struct alpine_msix_data *priv, unsigned sgi,
> +				 int num_req)
> +{
> +	int i, first;
> +
> +	first = sgi - priv->spi_first;
> +
> +	spin_lock(&priv->msi_map_lock);
> +
> +	for (i = 0; i < num_req; i++)
> +		clear_bit(first + i, priv->msi_map);
> +
> +	spin_unlock(&priv->msi_map_lock);
> +}
> +
> +static void alpine_msix_compose_msi_msg(struct irq_data *data,
> +					struct msi_msg *msg)
> +{
> +	struct alpine_msix_data *priv = irq_data_get_irq_chip_data(data);
> +
> +	msg->address_hi = priv->addr_high;
> +	msg->address_lo = priv->addr_low + (data->hwirq << 3);
> +	msg->data = 0;
> +}
> +
> +static struct msi_domain_info alpine_msix_domain_info = {
> +	.flags	= MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> +		  MSI_FLAG_PCI_MSIX,

You can probably add MSI_FLAG_PCI_MSI, it should work as well (MULTI_MSI
obviously won't).

> +	.chip	= &alpine_msix_irq_chip,
> +};
> +
> +static struct irq_chip middle_irq_chip = {
> +	.name			= "alpine_msix_middle",
> +	.irq_mask		= irq_chip_mask_parent,
> +	.irq_unmask		= irq_chip_unmask_parent,
> +	.irq_eoi		= irq_chip_eoi_parent,
> +	.irq_set_affinity	= irq_chip_set_affinity_parent,
> +	.irq_compose_msi_msg	= alpine_msix_compose_msi_msg,
> +};
> +
> +static int alpine_msix_gic_domain_alloc(struct irq_domain *domain,
> +					unsigned int virq, int sgi)
> +{
> +	struct irq_fwspec fwspec;
> +	struct irq_data *d;
> +	int ret;
> +
> +	if (!is_of_node(domain->parent->fwnode))
> +		return -EINVAL;
> +
> +	fwspec.fwnode = domain->parent->fwnode;
> +	fwspec.param_count = 3;
> +	fwspec.param[0] = 0;
> +	fwspec.param[1] = sgi;
> +	fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
> +
> +	ret = irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
> +	if (ret)
> +		return ret;
> +
> +	d = irq_domain_get_irq_data(domain->parent, virq);
> +	d->chip->irq_set_type(d, IRQ_TYPE_EDGE_RISING);
> +
> +	return 0;
> +}
> +
> +static int alpine_msix_middle_domain_alloc(struct irq_domain *domain,
> +					   unsigned int virq,
> +					   unsigned int nr_irqs, void *args)
> +{
> +	struct alpine_msix_data *priv = domain->host_data;
> +	int sgi, err, i;
> +
> +	sgi = alpine_msix_allocate_sgi(priv, nr_irqs);
> +	if (sgi < 0)
> +		return sgi;
> +
> +	for (i = 0; i < nr_irqs; i++) {
> +		err = alpine_msix_gic_domain_alloc(domain, virq + i, sgi + i);
> +		if (err)
> +			goto err_sgi;
> +
> +		irq_domain_set_hwirq_and_chip(domain, virq + i, sgi + i,
> +					      &middle_irq_chip, priv);
> +	}
> +
> +	return 0;
> +
> +err_sgi:
> +	while (--i >= 0)
> +		irq_domain_free_irqs_parent(domain, virq, i);
> +	alpine_msix_free_sgi(priv, sgi, nr_irqs);
> +	return err;
> +}
> +
> +static void alpine_msix_middle_domain_free(struct irq_domain *domain,
> +					   unsigned int virq,
> +					   unsigned int nr_irqs)
> +{
> +	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> +	struct alpine_msix_data *priv = irq_data_get_irq_chip_data(d);
> +
> +	irq_domain_free_irqs_parent(domain, virq, nr_irqs);
> +	alpine_msix_free_sgi(priv, d->hwirq, nr_irqs);
> +}
> +
> +static const struct irq_domain_ops alpine_msix_middle_domain_ops = {
> +	.alloc	= alpine_msix_middle_domain_alloc,
> +	.free	= alpine_msix_middle_domain_free,
> +};
> +
> +static int alpine_msix_init_domains(struct alpine_msix_data *priv,
> +				    struct device_node *node)
> +{
> +	struct irq_domain *middle_domain, *msi_domain, *gic_domain;
> +	struct device_node *gic_node;
> +
> +	gic_node = of_irq_find_parent(node);
> +	if (!gic_node) {
> +		pr_err("Failed to find the GIC node\n");
> +		return -ENODEV;
> +	}
> +
> +	gic_domain = irq_find_host(gic_node);
> +	if (!gic_domain) {
> +		pr_err("Failed to find the GIC domain\n");
> +		return -ENXIO;
> +	}
> +
> +	middle_domain = irq_domain_add_tree(NULL,
> +					    &alpine_msix_middle_domain_ops,
> +					    priv);
> +	if (!middle_domain) {
> +		pr_err("Failed to create the MSIX middle domain\n");
> +		return -ENOMEM;
> +	}
> +
> +	middle_domain->parent = gic_domain;
> +
> +	msi_domain = pci_msi_create_irq_domain(of_node_to_fwnode(node),
> +					       &alpine_msix_domain_info,
> +					       middle_domain);
> +	if (!msi_domain) {
> +		pr_err("Failed to create MSI domain\n");
> +		irq_domain_remove(msi_domain);
> +		return -ENOMEM;
> +	}
> +
> +	return 0;
> +}
> +
> +static int alpine_msix_init(struct device_node *node,
> +			    struct device_node *parent)
> +{
> +	struct alpine_msix_data *priv;
> +	struct resource res;
> +	int ret;
> +
> +	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	spin_lock_init(&priv->msi_map_lock);
> +
> +	ret = of_address_to_resource(node, 0, &res);
> +	if (ret) {
> +		pr_err("Failed to allocate resource\n");
> +		goto err_priv;
> +	}
> +
> +	priv->addr_high = upper_32_bits((u64)res.start);
> +	priv->addr_low = lower_32_bits(res.start) + ALPINE_MSIX_SPI_TARGET_CLUSTER0;

This is a bit odd. If you always set bit 16, why isn't that reflected in
the base address coming from the DT?

> +
> +	if (of_property_read_u32(node, "al,msi-base-spi", &priv->spi_first)) {
> +		pr_err("Unable to parse MSI base\n");
> +		ret = -EINVAL;
> +		goto err_priv;
> +	}
> +
> +	if (of_property_read_u32(node, "al,msi-num-spis", &priv->num_spis)) {
> +		pr_err("Unable to parse MSI numbers\n");
> +		ret = -EINVAL;
> +		goto err_priv;
> +	}
> +
> +	priv->msi_map = kzalloc(sizeof(*priv->msi_map) * BITS_TO_LONGS(priv->num_spis),
> +				GFP_KERNEL);
> +	if (!priv->msi_map) {
> +		ret = -ENOMEM;
> +		goto err_priv;
> +	}
> +
> +	pr_debug("Registering %d msixs, starting at %d\n",
> +		 priv->num_spis, priv->spi_first);
> +
> +	ret = alpine_msix_init_domains(priv, node);
> +	if (ret)
> +		goto err_map;
> +
> +	return 0;
> +
> +err_map:
> +	kfree(priv->msi_map);
> +err_priv:
> +	kfree(priv);
> +	return ret;
> +}
> +IRQCHIP_DECLARE(alpine_msix, "al,alpine-msix", alpine_msix_init);
> 

Otherwise, looks pretty good.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From j-keerthy at ti.com  Mon Feb  8 01:45:05 2016
From: j-keerthy at ti.com (Keerthy)
Date: Mon, 8 Feb 2016 15:15:05 +0530
Subject: [PATCH] arm: dts: AM57XX: Correct the thermal thresholds
Message-ID: <1454924705-8382-1-git-send-email-j-keerthy@ti.com>

The thermal threholds for am57xx are different from that of dra7.
Correcting the thresholds for the same.

Signed-off-by: Keerthy <j-keerthy at ti.com>
---

Depends on: https://lkml.org/lkml/2016/2/8/90

 arch/arm/boot/dts/am57xx-beagle-x15.dts | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

Index: linux/arch/arm/boot/dts/am57xx-beagle-x15.dts
===================================================================
--- linux.orig/arch/arm/boot/dts/am57xx-beagle-x15.dts	2016-02-08 14:57:05.514959101 +0530
+++ linux/arch/arm/boot/dts/am57xx-beagle-x15.dts	2016-02-08 14:57:05.510959168 +0530
@@ -825,3 +825,27 @@
 		status = "okay";
 	};
 };
+
+&cpu_alert0 {
+	temperature = <90000>; /* milliCelsius */
+};
+
+&cpu_crit {
+	temperature = <105000>; /* milliCelsius */
+};
+
+&gpu_crit {
+	temperature = <105000>; /* milliCelsius */
+};
+
+&core_crit {
+	temperature = <105000>; /* milliCelsius */
+};
+
+&dspeve_crit {
+	temperature = <105000>; /* milliCelsius */
+};
+
+&iva_crit {
+	temperature = <105000>; /* milliCelsius */
+};


From christoffer.dall at linaro.org  Mon Feb  8 01:48:26 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 8 Feb 2016 10:48:26 +0100
Subject: ARM PCI/MSI KVM passthrough with GICv2M
In-Reply-To: <20160205111700.726ac061@t450s.home>
References: <1454017899.23148.0.camel@redhat.com> <56AB78B1.2030202@linaro.org>
 <1454096004.9301.1.camel@redhat.com> <56ABD8E0.6080409@linaro.org>
 <20160201140351.GE6828@arm.com> <20160203125047.GB13974@cbox>
 <20160203131057.GA20217@arm.com> <20160203153606.GC13974@cbox>
 <56B4DC97.60904@linaro.org> <20160205111700.726ac061@t450s.home>
Message-ID: <20160208094826.GA620@cbox>

On Fri, Feb 05, 2016 at 11:17:00AM -0700, Alex Williamson wrote:
> On Fri, 5 Feb 2016 18:32:07 +0100
> Eric Auger <eric.auger at linaro.org> wrote:
> 
> > Hi Alex,
> > 
> > I tried to sketch a proposal for guaranteeing the IRQ integrity when
> > doing ARM PCI/MSI passthrough with ARM GICv2M msi-controller. This is
> > based on extended VFIO group viability control, as detailed below.
> > 
> > As opposed to ARM GICv3 ITS, this MSI controller does *not* support IRQ
> > remapping. It can expose 1 or more 4kB MSI frame. Each frame contains a
> > single register where the msi data is written.
> > 
> > I would be grateful to you if you could tell me whether it makes any sense.
> > 
> > Thanks in advance
> > 
> > Best Regards
> > 
> > Eric
> > 
> > 
> > 1) GICv2m with a single 4kB single frame
> >    all devices having this msi-controller as msi-parent share this
> >    single MSI frame. Those devices can work on behalf of the host
> >    or work on behalf of 1 or more guests (KVM assigned devices). We
> >    must make sure either the host only or 1 single VM can access to the
> >    single frame to guarantee interrupt integrity: a device assigned
> >    to 1 VM should not be able to trigger MSI targeted to the host
> >    or another VM.
> > 
> >    I would propose to extend the VFIO notion of group viability.
> >    Currently a VFIO group is viable if:
> >    all devices belonging to the same group are bound to a VFIO driver
> >    or unbound.
> > 
> >    Let's imagine we extend the viability check as follows:
> > 
> >    0) keep the current viable check: all the devices belonging to
> >       the group must be vfio bound or unbound.
> >    1) retrieve the MSI parent of the device and list all the
> >       other devices using that MSI controller as MSI-parent (does not
> >       look straightforward):
> >    2) they must be VFIO driver bound or unbound as well (meaning
> >       they are not used by the host). If not, reject device attachment
> >    - in case they are VFIO bound (a VFIO group is set):
> >      x if all VFIO containers are the same as the one of the device's
> >        we try to attach, that's OK. This means the other devices
> >        use different IOMMU mappings, eventually will target the
> >        MSI frame but they all work for the same user space client/VM.
> >      x 1 or more devices has a different container than the device
> >        under attachment:
> >        It works on behalf of a different user space client/VM,
> >        we can't attach the new device. I think there is a case however
> >        where severals containers can be opened by a single QEMU.
> > 
> > Of course the dynamic aspects, ie a new device showing up or an unbind
> > event bring significant complexity.
> > 
> > 2) GICv2M with multiple 4kB frames
> >    Each msi-frame is enumerated as msi-controller. The device tree
> >    statically defines which device is attached to each msi frame.
> >    In case devices are assigned we cannot change this attachment
> >    anyway since there might be physical contraints behind.
> >    So devices likely to be assigned to guests should be linked to a
> >    different MSI frame than devices that are not.
> > 
> >    I think extended viability concept can be used as well.
> > 
> >    This model still is not ideal: in case we have a SR-IOV device
> >    plugged onto an host bridge attached to a single MSI parent you won't
> >    be able anyway to have 1 Virtual Function working for host and 1 VF
> >    working for a guest. Only Interrupt translation (ITS) will bring that
> >    feature.
> > 
> > 3) GICv3 ITS
> >    This one supports interrupt translation service ~ Intel
> >    IRQ remapping.
> >    This means a single frame can be used by all devices. A deviceID is
> >    used exclusively by the host or a guest. I assume the ITS driver
> >    allocates/populates deviceid interrupt translation table featuring
> >    separate LPI spaces ie by construction different ITT cannot feature
> >    same LPIs. So no need to do the extended viability test.
> > 
> >    The MSI controller should have a property telling whether
> >    it supports interrupt translation. This kind of property currently
> >    exists on IOMMU side for INTEL remapping.
> > 
> 
> Hi Eric,
> 
> Would anyone be terribly upset if we simply assume the worst case
> scenario on GICv2m/M, have the IOMMU not claim IOMMU_CAP_INTR_REMAP, and
> require the user to opt-in via the allow_unsafe_interrupts on the
> vfio_iommu_type1 module?  That would make it very compatible with what
> we already do on x86, where it really is all or nothing.  

meaning either you allow unsafe multiplexing with passthrough in every
flavor (unsafely) or you don't allow it at all?

I didn't know such on option existed, but it seems to me that this fits
the bill exactly.


> My assumption
> is that GICv2 would be phased out in favor of GICv3, so there's always
> a hardware upgrade path to having more complete isolation, but the
> return on investment for figuring out whether a given device really has
> this sort of isolation seems pretty low.  Often users already have some
> degree of trust in the VMs they use for device assignment anyway.  An
> especially prudent user can still look at the hardware specs for their
> specific system to understand whether any devices are fully isolated
> and only make use of those for device assignment.  Does that seem like
> a reasonable alternative?
> 

It sounds good to me, that would allow us to release a GICv2m-based
solution for MSI passthrough on currently available hardware like the
Seattle.

Thanks,
-Christoffer


From thomas.petazzoni at free-electrons.com  Mon Feb  8 01:53:22 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 8 Feb 2016 10:53:22 +0100
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <56B86391.1030609@arm.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
 <56B86391.1030609@arm.com>
Message-ID: <20160208105322.78b20cba@free-electrons.com>

Hello Marc,

On Mon, 8 Feb 2016 09:44:49 +0000, Marc Zyngier wrote:

> > +static struct msi_domain_info alpine_msix_domain_info = {
> > +	.flags	= MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> > +		  MSI_FLAG_PCI_MSIX,
> 
> You can probably add MSI_FLAG_PCI_MSI, it should work as well (MULTI_MSI
> obviously won't).

Why wouldn't MULTI_MSI work? The code is using
bitmap_find_next_zero_area() in alpine_msix_allocate_sgi() precisely to
find num_req consecutive bits set to 0, in order to allocate multiple
MSIs at once. Am I missing something?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From arnd at arndb.de  Mon Feb  8 01:53:10 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 08 Feb 2016 10:53:10 +0100
Subject: [PATCH 1/5] ARM: add EXPORT_SYMBOL of hook_fault_code for PCI
 host modularization
In-Reply-To: <1454889644-27830-2-git-send-email-paul.gortmaker@windriver.com>
References: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
 <1454889644-27830-2-git-send-email-paul.gortmaker@windriver.com>
Message-ID: <2567476.SknW0BEsQJ@wuerfel>

On Sunday 07 February 2016 19:00:40 Paul Gortmaker wrote:
> In a discussion of a previous patch set[1], it was suggested that
> modularizing some of the PCI host support would be good to keep
> multi platform bzImage sizes smaller.
> 
> Two of the files that are candidates for conversion to tristate
> from bool are:
> 
> drivers/pci/host/pci-imx6.c
> drivers/pci/host/pci-keystone.c
> 
> However, doing the conversion reveals that they are going to fail
> at modpost time since hook_fault_code isn't currently exported.
> 
> Since we are now going to export it we also need to remove the
> __init tag, as the fcn needs to be present at insmod time.
> 
> [1] https://lkml.kernel.org/r/20160108203102.GH5354 at localhost
> 

If we want to make hook_fault_code() visible, we at least also need
an unhook_fault_code() function that removes the fault handler
when unloading the module, and preferably does so in a safe way.

The usage of hook_fault_code() at least in the imx driver is also
problematic, as it just ignores all "imprecise external abort"
faults, whether they come from PCI or not.

	Arnd


From p.zabel at pengutronix.de  Mon Feb  8 01:58:55 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon, 08 Feb 2016 10:58:55 +0100
Subject: [PATCH v3 1/3] reset: Make [of_]reset_control_get[_foo]
 functions wrappers
In-Reply-To: <56B4EA46.7060905@redhat.com>
References: <1453918516-3078-1-git-send-email-hdegoede@redhat.com>
 <1453918516-3078-2-git-send-email-hdegoede@redhat.com>
 <1454604866.3356.78.camel@pengutronix.de> <56B4EA46.7060905@redhat.com>
Message-ID: <1454925535.3466.8.camel@pengutronix.de>

Am Freitag, den 05.02.2016, 19:30 +0100 schrieb Hans de Goede:
[...]
> > Even though we are device tree only at this point, I'd prefer to keep an
> > exported function that takes a struct device argument, for example:
> >
> > 	return __reset_control_get(dev, id, 0);
> 
> I don't really see a reason to do this, this is not userspace abi or some-such
> we can always later re-introduce an exported function which takes a device
> argument. But if you insist, you're the boss :)

s/boss/janitor/ more like

> Let me know if you really
> want me to make this change for the next version, and I'll add it to v4 of this
> set.

Leave it as is. I have a patch to add it back, and yes it looks a bit
superfluous on its own. I'll add apply that only once its actually
needed.

regards
Philipp



From arnd at arndb.de  Mon Feb  8 01:59:26 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 08 Feb 2016 10:59:26 +0100
Subject: [PATCH 4/5] drivers/pci: make host/pci-keystone-dw.c modular
In-Reply-To: <1454889644-27830-5-git-send-email-paul.gortmaker@windriver.com>
References: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
 <1454889644-27830-5-git-send-email-paul.gortmaker@windriver.com>
Message-ID: <91848876.ZYig6qgHLq@wuerfel>

On Sunday 07 February 2016 19:00:43 Paul Gortmaker wrote:
> Export the symbols that this driver requires in order for it to
> be modular.  In addition to the one use case of a dw_pci sym, it
> has many instances of its own ks_dw_pci syms that need exporting
> in order to modpost w/o error.
> 
> Cc: Murali Karicheri <m-karicheri2 at ti.com>
> Cc: Bjorn Helgaas <bhelgaas at google.com>
> Cc: Stanimir Varbanov <svarbanov at mm-sol.com>
> Cc: Geert Uytterhoeven <geert+renesas at glider.be>
> Cc: Thierry Reding <thierry.reding at gmail.com>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: linux-pci at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> ---


Could we just have one module for the driver  instead of two?

Something like below (untested)

	Arnd

diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 7b2f20c6ccc6..0b472c680348 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -8,7 +8,8 @@ obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
 obj-$(CONFIG_PCI_RCAR_GEN2_PCIE) += pcie-rcar.o
 obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
 obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
-obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
+obj-$(CONFIG_PCI_KEYSTONE) pci-keystone-mod.o
+pci-keystone-mod-objs := pci-keystone-dw.o pci-keystone.o
 obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
 obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
 obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o



From marc.zyngier at arm.com  Mon Feb  8 02:08:02 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 8 Feb 2016 10:08:02 +0000
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <20160208105322.78b20cba@free-electrons.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
 <56B86391.1030609@arm.com> <20160208105322.78b20cba@free-electrons.com>
Message-ID: <56B86902.3090700@arm.com>

Hi Thomas,

On 08/02/16 09:53, Thomas Petazzoni wrote:
> Hello Marc,
> 
> On Mon, 8 Feb 2016 09:44:49 +0000, Marc Zyngier wrote:
> 
>>> +static struct msi_domain_info alpine_msix_domain_info = {
>>> +	.flags	= MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
>>> +		  MSI_FLAG_PCI_MSIX,
>>
>> You can probably add MSI_FLAG_PCI_MSI, it should work as well (MULTI_MSI
>> obviously won't).
> 
> Why wouldn't MULTI_MSI work? The code is using
> bitmap_find_next_zero_area() in alpine_msix_allocate_sgi() precisely to
> find num_req consecutive bits set to 0, in order to allocate multiple
> MSIs at once. Am I missing something?

The clue is in the patch:

+	msg->address_lo = priv->addr_low + (data->hwirq << 3);

Multi-MSI imposes a single doorbell address, and consecutive message
identifiers. So while the allocator deals perfectly with the consecutive
IDs part, the fact that you have to encode the message in the address
(instead of putting it in the data field) makes it completely
incompatible with Multi-MSI.

It is a bit silly that brand new HW comes out with such limitations (but
Multi-MSI is such a pain anyway...).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From architt at codeaurora.org  Mon Feb  8 02:12:04 2016
From: architt at codeaurora.org (Archit Taneja)
Date: Mon, 8 Feb 2016 15:42:04 +0530
Subject: [PATCH v7 0/5] Add mipi dsi support for rk3288
In-Reply-To: <1452053038-32098-1-git-send-email-zyw@rock-chips.com>
References: <1452053038-32098-1-git-send-email-zyw@rock-chips.com>
Message-ID: <56B869F4.6090507@codeaurora.org>

Hi,

On 01/06/2016 09:33 AM, Chris Zhong wrote:
>
> The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
> IP. This series adds support for a Synopsys DesignWare MIPI DSI host
> controller DRM driver.
>
> The MIPI DSI feature is tested on rk3288 evb board, backport them to
> chrome os kernel chrome_v3.14, and it can display normally.
>
> This patchset is base on the patchset from Ying.liu at freescale.com.
> <http://www.spinics.net/lists/dri-devel/msg77181.html>
>
> According to the suggestion from Thierry, I have get rid of the bridge,
> and register the encoder & connecter in drm/rockchip/dw-mipi-dsi.c.

I've raised this question too late, but what was the reason to not
implement the DSI block as a bridge driver?

The drm/hisilicon IP seems to use a very similar DSI Designware IP (the
register offsets seems to be the same). There is a good potential of
re-use here by different kms drivers here the way it's already done for
DW HDMI and the analogix DP driver that's in review process.

Archit

> After backport below patches from linux-next, I can merge this serial into
> Dave's drm-next branch.
>
> 94d5d6a0fbf3 clk: rockchip: add an id for rk3288 crypto clk
> c6d49fbcfcc4 clk: rockchip: add id for mipidsi sclk on rk3288
> a2f4c560f18e clk: rockchip: add mipidsi clock on rk3288
> 69c923743640 ARM: dts: rockchip: correct the name of REG8 for rk3288-evb-act8846
> 662513a14c9d ARM: dts: rockchip: add 2 regulators for rk3288-evb-act8846
> b04061e6599b ARM: dts: rockchip: move the public part to rk3288-evb common
>
>
> Changes in v7:
> - modify the config to tristate for modules build (Mark Yao)
> - Pass NULL 'name' to drm_encoder_init() to fix compile err (Mark Yao)
> - Move the lcd_en control to act8846 dts
>
> Changes in v6:
> - update the document, since the bridge device has been deleted.
> - move the mipi_en gate to ockchip_drm_crtc_mode_config
> - Remove the atomic feature check (Mark Yao)
> - Add atomic API support (Heiko St?bne)
> - Do not use bridge driver (Thierry Reding)
> - Optimization the phy init sequence
>
> Changes in v5:
> - modify the clk name to SCLK_MIPIDSI_24M
> - add a blank line befor lcd_en
>
> Changes in v4:
> - use clk_round_rate to check the clock rate in vop_crtc_mode_fixup
>
> Changes in v3:
> - move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/
>
> Chris Zhong (5):
>    drm/rockchip: return a true clock rate to adjusted_mode
>    Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver
>    drm: rockchip: Support Synopsys DW MIPI DSI
>    ARM: dts: rockchip: add rk3288 mipi_dsi nodes
>    ARM: dts: rockchip: add support mipi panel tv080wum-nl0
>
>   .../display/rockchip/dw_mipi_dsi_rockchip.txt      |   60 +
>   arch/arm/boot/dts/rk3288-evb-act8846.dts           |    2 +
>   arch/arm/boot/dts/rk3288-evb.dtsi                  |   12 +-
>   arch/arm/boot/dts/rk3288.dtsi                      |   39 +
>   drivers/gpu/drm/rockchip/Kconfig                   |   10 +
>   drivers/gpu/drm/rockchip/Makefile                  |    1 +
>   drivers/gpu/drm/rockchip/dw-mipi-dsi.c             | 1196 ++++++++++++++++++++
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c        |    8 +
>   8 files changed, 1327 insertions(+), 1 deletion(-)
>   create mode 100644 Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
>   create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c
>

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation


From ard.biesheuvel at linaro.org  Mon Feb  8 02:12:12 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon,  8 Feb 2016 11:12:12 +0100
Subject: [PATCH] arm64: allow the module region to be randomized independently
In-Reply-To: <CAGXu5j+1rcScYedzQ5o0aaGZJWPCBGk-gai0D8jY8Huc-VuG7A@mail.gmail.com>
References: <CAGXu5j+1rcScYedzQ5o0aaGZJWPCBGk-gai0D8jY8Huc-VuG7A@mail.gmail.com>
Message-ID: <1454926332-25929-1-git-send-email-ard.biesheuvel@linaro.org>

This patch applies directly onto '[PATCH v5sub2 7/8] arm64: add support for
kernel ASLR' so it can be folded in or applied separately, as desired.

As pointed out by Kees, fully randomizing each module allocation does not add
anything in terms of security, and only hurts performance even more, since it
would cause all inter-module branches to be resolved via veneers as well.

----------8<--------------
This adds the option to randomize the module region independently from the
core kernel, and enables it by default. This makes it less likely that the
location of core kernel data structures can be determined by an adversary,
but causes all function calls from modules into the core kernel to be
resolved via entries in the module PLTs.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/Kconfig              | 15 ++++++++
 arch/arm64/include/asm/module.h |  6 ++++
 arch/arm64/kernel/kaslr.c       | 36 +++++++++++++++-----
 arch/arm64/kernel/module.c      |  9 ++---
 4 files changed, 50 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e3049d5c1246..666aacc4c763 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -787,6 +787,21 @@ config RANDOMIZE_BASE
 
 	  If unsure, say N.
 
+config RANDOMIZE_MODULE_REGION_FULL
+	bool "Randomize the module region independently from the core kernel"
+	depends on RANDOMIZE_BASE
+	default y
+	help
+	  Randomizes the location of the module region without considering the
+	  location of the core kernel. This way, it is impossible for modules
+	  to leak information about the location of core kernel data structures
+	  but it does imply that function calls between modules and the core
+	  kernel will need to be resolved via veneers in the module PLT.
+
+	  When this option is not set, the module region will be randomized over
+	  a limited range that contains the [_stext, _etext] interval of the
+	  core kernel, so branch relocations are always in range.
+
 endmenu
 
 menu "Boot options"
diff --git a/arch/arm64/include/asm/module.h b/arch/arm64/include/asm/module.h
index 8652fb613304..e12af6754634 100644
--- a/arch/arm64/include/asm/module.h
+++ b/arch/arm64/include/asm/module.h
@@ -31,4 +31,10 @@ struct mod_arch_specific {
 u64 module_emit_plt_entry(struct module *mod, const Elf64_Rela *rela,
 			  Elf64_Sym *sym);
 
+#ifdef CONFIG_RANDOMIZE_BASE
+extern u64 module_alloc_base;
+#else
+#define module_alloc_base	((u64)_etext - MODULES_VSIZE)
+#endif
+
 #endif /* __ASM_MODULE_H */
diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index b0bf628ba51f..7a40aa4ba93d 100644
--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@ -20,7 +20,7 @@
 #include <asm/pgtable.h>
 #include <asm/sections.h>
 
-u32 __read_mostly module_load_offset;
+u64 __read_mostly module_alloc_base;
 
 static __init u64 get_kaslr_seed(void *fdt)
 {
@@ -126,14 +126,32 @@ u64 __init kaslr_early_init(u64 dt_phys)
 	    (((u64)_end + offset) >> SWAPPER_TABLE_SHIFT))
 		offset = (offset + (u64)(_end - _text)) & mask;
 
-	/*
-	 * Randomize the module region, by setting module_load_offset to
-	 * a PAGE_SIZE multiple in the interval [0, module_range). This
-	 * ensures that the resulting region still covers [_stext, _etext],
-	 * and that all relative branches can be resolved without veneers.
-	 */
-	module_range = MODULES_VSIZE - (u64)(_etext - _stext);
-	module_load_offset = ((module_range * (u16)seed) >> 16) & PAGE_MASK;
+	if (IS_ENABLED(CONFIG_RANDOMIZE_MODULE_REGION_FULL)) {
+		/*
+		 * Randomize the module region independently from the core
+		 * kernel. This prevents modules from leaking any information
+		 * about the address of the kernel itself, but results in
+		 * branches between modules and the core kernel that are
+		 * resolved via PLTs. (Branches between modules will be
+		 * resolved normally.)
+		 */
+		module_range = VMALLOC_END - VMALLOC_START - MODULES_VSIZE;
+		module_alloc_base = VMALLOC_START;
+	} else {
+		/*
+		 * Randomize the module region by setting module_alloc_base to
+		 * a PAGE_SIZE multiple in the range [_etext - MODULES_VSIZE,
+		 * _stext) . This guarantees that the resulting region still
+		 * covers [_stext, _etext], and that all relative branches can
+		 * be resolved without veneers.
+		 */
+		module_range = MODULES_VSIZE - (u64)(_etext - _stext);
+		module_alloc_base = (u64)_etext + offset - MODULES_VSIZE;
+	}
+
+	/* use the lower 21 bits to randomize the base of the module region */
+	module_alloc_base += (module_range * (seed & ((1 << 21) - 1))) >> 21;
+	module_alloc_base &= PAGE_MASK;
 
 	return offset;
 }
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 54702d456680..dfa1ffaa9844 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -33,14 +33,9 @@
 void *module_alloc(unsigned long size)
 {
 	void *p;
-	u64 base = (u64)_etext - MODULES_VSIZE;
 
-	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
-		extern u32 module_load_offset;
-		base += module_load_offset;
-	}
-
-	p = __vmalloc_node_range(size, MODULE_ALIGN, base, base + MODULES_VSIZE,
+	p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
+				module_alloc_base + MODULES_VSIZE,
 				GFP_KERNEL, PAGE_KERNEL_EXEC, 0,
 				NUMA_NO_NODE, __builtin_return_address(0));
 
-- 
2.5.0



From christoffer.dall at linaro.org  Mon Feb  8 02:14:32 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 8 Feb 2016 11:14:32 +0100
Subject: [PATCH V14 0/9] dma: add Qualcomm Technologies HIDMA driver
In-Reply-To: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
References: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
Message-ID: <20160208101432.GA1150@cbox>

Hi Sinan,

On Thu, Feb 04, 2016 at 11:34:31PM -0500, Sinan Kaya wrote:
> The Qualcomm Technologies HIDMA device has been designed
> to support virtualization technology. The driver has been
> divided into two to follow the hardware design.
> 
> 1. HIDMA Management driver
> 2. HIDMA Channel driver
> 
> Each HIDMA HW consists of multiple channels. These channels
> share some set of common parameters. These parameters are
> initialized by the management driver during power up.
> Same management driver is used for monitoring the execution
> of the channels. Management driver can change the performance
> behavior dynamically such as bandwidth allocation and
> prioritization in the future.
> 
> The management driver is executed in host context and
> is the main management entity for all channels provided by
> the device.

I'm not at all familiar with this kind of hardware.

Once an entity (userspace or VM) has a HIDAM channel assigned via VFIO,
how does it use it?  Is it used in relation with another device to
perform DMA on its behalf or is a HIDMA channel something that's useful
on its own?

Thanks,
-Christoffer


From antoine.tenart at free-electrons.com  Mon Feb  8 02:26:56 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon, 8 Feb 2016 11:26:56 +0100
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <56B86391.1030609@arm.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
 <56B86391.1030609@arm.com>
Message-ID: <20160208102656.GA4117@kwain>

Hi Marc,

On Mon, Feb 08, 2016 at 09:44:49AM +0000, Marc Zyngier wrote:
> On 08/02/16 09:16, Antoine Tenart wrote:
> > +
> > +/* MSIX message address format: local GIC target */
> > +#define ALPINE_MSIX_SPI_TARGET_CLUSTER0		BIT(16)
> > +
> > +struct alpine_msix_data {
> > +	spinlock_t msi_map_lock;
> > +	u32 addr_high;
> > +	u32 addr_low;
> 
> As this looks to be a physical address, please consider using phys_addr_t.

Sure.

[?]

> > +static int alpine_msix_init(struct device_node *node,
> > +			    struct device_node *parent)
> > +{
> > +	struct alpine_msix_data *priv;
> > +	struct resource res;
> > +	int ret;
> > +
> > +	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> > +	if (!priv)
> > +		return -ENOMEM;
> > +
> > +	spin_lock_init(&priv->msi_map_lock);
> > +
> > +	ret = of_address_to_resource(node, 0, &res);
> > +	if (ret) {
> > +		pr_err("Failed to allocate resource\n");
> > +		goto err_priv;
> > +	}
> > +
> > +	priv->addr_high = upper_32_bits((u64)res.start);
> > +	priv->addr_low = lower_32_bits(res.start) + ALPINE_MSIX_SPI_TARGET_CLUSTER0;
> 
> This is a bit odd. If you always set bit 16, why isn't that reflected in
> the base address coming from the DT?

The 20 least significant bits of addr_low provide direct information
regarding the interrupt destination, so I thought it would be clearer
to have this explicitly in the driver so that we know what those bits
mean.

What do you think?


Thanks for the review!

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160208/bd26f3fe/attachment-0001.sig>

From heiko at sntech.de  Mon Feb  8 02:28:22 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 08 Feb 2016 11:28:22 +0100
Subject: [PATCH v2 04/10] ARM64: dts: rockchip: Add GMAC to GeekBox
In-Reply-To: <1454897859-7601-5-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
 <1454897859-7601-5-git-send-email-afaerber@suse.de>
Message-ID: <5875277.Y7zJ7W9GkY@phil>

Hi Andreas,

Am Montag, 8. Februar 2016, 03:17:33 schrieb Andreas F?rber:
> Signed-off-by: Andreas F?rber <afaerber at suse.de>

is there some special reason that gmac, emmc, ir, etc are in separate 
patches? I guess I'll just fold them into the core patch otherwise.


Heiko

> ---
>  v2: New
> 
>  arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
> b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts index
> bc91d39758ab..a8dcf3c2b0c1 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
> @@ -56,6 +56,13 @@
>  		reg = <0x0 0x0 0x0 0x80000000>;
>  	};
> 
> +	ext_gmac: gmac-clk {
> +		compatible = "fixed-clock";
> +		clock-frequency = <125000000>;
> +		clock-output-names = "ext_gmac";
> +		#clock-cells = <0>;
> +	};
> +
>  	leds: gpio-leds {
>  		compatible = "gpio-leds";
> 
> @@ -82,6 +89,19 @@
>  	};
>  };
> 
> +&gmac {
> +	status = "okay";
> +	phy-supply = <&vcc_lan>;
> +	phy-mode = "rgmii";
> +	clock_in_out = "input";
> +	assigned-clocks = <&cru SCLK_MAC>;
> +	assigned-clock-parents = <&ext_gmac>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&rgmii_pins>;
> +	tx_delay = <0x30>;
> +	rx_delay = <0x10>;
> +};
> +
>  &i2c0 {
>  	status = "okay";



From kernel at martin.sperl.org  Mon Feb  8 02:28:47 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Mon, 8 Feb 2016 11:28:47 +0100
Subject: [PATCH V4 1/7] clk: bcm2835: the minimum clock divider is 2
In-Reply-To: <87oac03tuz.fsf@eliezer.anholt.net>
References: <1452867667-2447-1-git-send-email-kernel@martin.sperl.org>
 <1452867667-2447-2-git-send-email-kernel@martin.sperl.org>
 <87oac03tuz.fsf@eliezer.anholt.net>
Message-ID: <56B86DDF.7060904@martin.sperl.org>



On 02.02.2016 00:15, Eric Anholt wrote:
> kernel at martin.sperl.org writes:
>
>> From: Martin Sperl <kernel at martin.sperl.org>
>>
>> Testing with different clock divider values has shown
>> that (at least for the PCM clock) the clock divider
>> has to be at least 2, otherwise the clock will not
>> output a signal.
>
> For a MASH clock (PWM, PCM, SLIMBUS, but not the others), the minimum
> integer component of the divider is:
>
> mash 0: 1
> mash 1: 2
> mash 2: 3
> mash 3: 5
>

I know that that is what the datasheet says - see also the errata:
http://elinux.org/BCM2835_datasheet_errata#p105_table.

Experimentation has show that a divider between 1 and 1 + 4095 / 4096
does not provide any output PCM clock - only 2 and above does work for
mash = 0, 1, 2 or 3.

Example: Requesting 12288000Hz (=192kHz at 64bit) with the 19.2Mhz
oscillator results in a divider of: 1 + 2304 / 4096 and this does not
give a clock output.

See the report by hiassoft here:
https://github.com/raspberrypi/linux/issues/1231#issuecomment-171003182
(note that it also applies to mash = 0, but there may be no comment on
this fact in this thread)

Note that there is patch 7 that implements the above "mash" limits
for a divider and downgrades to a lower mash level if the divider
does not qualify.

Martin


From heiko at sntech.de  Mon Feb  8 02:29:30 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 08 Feb 2016 11:29:30 +0100
Subject: [PATCH v2 09/10] Documentation: devicetree: rockchip: Document
 Landingship
In-Reply-To: <1454897859-7601-10-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
 <1454897859-7601-10-git-send-email-afaerber@suse.de>
Message-ID: <6744409.i2u8076vm4@phil>

Am Montag, 8. Februar 2016, 03:17:38 schrieb Andreas F?rber:
> Use "geekbuying,landingship" compatible string, plus those of GeekBox.

I do believe this would be better as geekbuying,geekbox-landingship . They 
might reuse the landingship naming for future baseboards as well ;-)

> 
> Signed-off-by: Andreas F?rber <afaerber at suse.de>
> ---
>  v2: New
> 
>  Documentation/devicetree/bindings/arm/rockchip.txt | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> b/Documentation/devicetree/bindings/arm/rockchip.txt index
> f633595b196c..c6d95f202591 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -91,6 +91,11 @@ Rockchip platforms device tree bindings
>      Required root node properties:
>        - compatible = "geekbuying,geekbox", "rockchip,rk3368";
> 
> +- GeekBuying Landingship:
> +    Required root node properties:
> +      - compatible = "geekbuying,landingship",
> +		     "geekbuying,geekbox", "rockchip,rk3368";
> +
>  - Rockchip RK3368 evb:
>      Required root node properties:
>        - compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368";



From marc.zyngier at arm.com  Mon Feb  8 02:32:08 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 8 Feb 2016 10:32:08 +0000
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <20160208102656.GA4117@kwain>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
 <56B86391.1030609@arm.com> <20160208102656.GA4117@kwain>
Message-ID: <56B86EA8.9070306@arm.com>

On 08/02/16 10:26, Antoine Tenart wrote:
>>> +static int alpine_msix_init(struct device_node *node,
>>> +			    struct device_node *parent)
>>> +{
>>> +	struct alpine_msix_data *priv;
>>> +	struct resource res;
>>> +	int ret;
>>> +
>>> +	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>>> +	if (!priv)
>>> +		return -ENOMEM;
>>> +
>>> +	spin_lock_init(&priv->msi_map_lock);
>>> +
>>> +	ret = of_address_to_resource(node, 0, &res);
>>> +	if (ret) {
>>> +		pr_err("Failed to allocate resource\n");
>>> +		goto err_priv;
>>> +	}
>>> +
>>> +	priv->addr_high = upper_32_bits((u64)res.start);
>>> +	priv->addr_low = lower_32_bits(res.start) + ALPINE_MSIX_SPI_TARGET_CLUSTER0;
>>
>> This is a bit odd. If you always set bit 16, why isn't that reflected in
>> the base address coming from the DT?
> 
> The 20 least significant bits of addr_low provide direct information
> regarding the interrupt destination, so I thought it would be clearer
> to have this explicitly in the driver so that we know what those bits
> mean.

So what is this information? TARGET_CLUSTER0 is not very expressive, and
doesn't show what the alternatives are. Could you please elaborate a bit
on that front?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From tglx at linutronix.de  Mon Feb  8 02:31:47 2016
From: tglx at linutronix.de (Thomas Gleixner)
Date: Mon, 8 Feb 2016 11:31:47 +0100 (CET)
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <alpine.DEB.2.11.1602081125560.25254@nanos>

Antoine,

On Mon, 8 Feb 2016, Antoine Tenart wrote:
> +static int alpine_msix_set_affinity(struct irq_data *irq_data,
> +				    const struct cpumask *mask, bool force)
> +{
> +	int ret;
> +
> +	ret = irq_chip_set_affinity_parent(irq_data, mask, force);
> +	return ret == IRQ_SET_MASK_OK ? IRQ_SET_MASK_OK_DONE : ret;

What's the point of this exercise? Why can't you just set the affinity
callback to irq_chip_set_affinity_parent() ?

> +static struct irq_chip alpine_msix_irq_chip = {
> +	.name			= "MSIx",
> +	.irq_mask		= alpine_msix_mask_msi_irq,
> +	.irq_unmask		= alpine_msix_unmask_msi_irq,
> +	.irq_eoi		= irq_chip_eoi_parent,
> +	.irq_set_affinity	= alpine_msix_set_affinity,
> +};
> +
> +static int alpine_msix_allocate_sgi(struct alpine_msix_data *priv, int num_req)
> +{
> +	int first, i;
> +
> +	spin_lock(&priv->msi_map_lock);
> +
> +	first = bitmap_find_next_zero_area(priv->msi_map, priv->num_spis, 0,
> +					   num_req, 0);
> +	if (first >= priv->num_spis) {
> +		spin_unlock(&priv->msi_map_lock);
> +		return -ENOSPC;
> +	}
> +
> +	for (i = 0; i < num_req; i++)
> +		set_bit(first + i, priv->msi_map);

  bitmap_set() ??

> +
> +	spin_unlock(&priv->msi_map_lock);
> +
> +	return priv->spi_first + first;
> +}
> +
> +static void alpine_msix_free_sgi(struct alpine_msix_data *priv, unsigned sgi,
> +				 int num_req)
> +{
> +	int i, first;
> +
> +	first = sgi - priv->spi_first;
> +
> +	spin_lock(&priv->msi_map_lock);
> +
> +	for (i = 0; i < num_req; i++)
> +		clear_bit(first + i, priv->msi_map);

  bitmap_clear() ??

> +	spin_unlock(&priv->msi_map_lock);
> +}

Thanks,

	tglx


From kernel at martin.sperl.org  Mon Feb  8 02:39:49 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Mon, 8 Feb 2016 11:39:49 +0100
Subject: [PATCH V4 1/7] clk: bcm2835: the minimum clock divider is 2
In-Reply-To: <87egcv5153.fsf@eliezer.anholt.net>
References: <1452867667-2447-1-git-send-email-kernel@martin.sperl.org>
 <1452867667-2447-2-git-send-email-kernel@martin.sperl.org>
 <87oac03tuz.fsf@eliezer.anholt.net> <87egcv5153.fsf@eliezer.anholt.net>
Message-ID: <56B87075.8000304@martin.sperl.org>



On 02.02.2016 02:52, Eric Anholt wrote:
> Eric Anholt <eric at anholt.net> writes:
>
>> kernel at martin.sperl.org writes:
>>
>>> From: Martin Sperl <kernel at martin.sperl.org>
>>>
>>> Testing with different clock divider values has shown
>>> that (at least for the PCM clock) the clock divider
>>> has to be at least 2, otherwise the clock will not
>>> output a signal.
>>
>> For a MASH clock (PWM, PCM, SLIMBUS, but not the others), the minimum
>> integer component of the divider is:
>>
>> mash 0: 1
>> mash 1: 2
>> mash 2: 3
>> mash 3: 5
>
> More specific MASH list:
>
> GP0
> GP1
> (*not* gp2)
> PCM
> PWM
> SLIM
>
I got the list from the broadcom provided headers for the VC4.
and where CM_*_DIV range does not start at 12 we have a fractional
divider (also requires if CM_*_FRAC or CM_*_MASH is set)

And if CM_*_MASH is set we got a mash enabled clock:
CM_GNRICCTL_MASH
CM_GP0CTL_MASH
CM_GP1CTL_MASH
CM_PCMCTL_MASH
CM_PWMCTL_MASH
CM_SLIMCTL_MASH

And this is what can get implemented by configuring mash
in the DT - otherwise only frac (a.k.a. MASH = 1) is
used for any clock that has .frac_bits > 0.


From afaerber at suse.de  Mon Feb  8 02:40:15 2016
From: afaerber at suse.de (=?UTF-8?Q?Andreas_F=c3=a4rber?=)
Date: Mon, 8 Feb 2016 11:40:15 +0100
Subject: [PATCH v2 04/10] ARM64: dts: rockchip: Add GMAC to GeekBox
In-Reply-To: <5875277.Y7zJ7W9GkY@phil>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
 <1454897859-7601-5-git-send-email-afaerber@suse.de> <5875277.Y7zJ7W9GkY@phil>
Message-ID: <56B8708F.50802@suse.de>

Hi Heiko,

Am 08.02.2016 um 11:28 schrieb Heiko Stuebner:
> Am Montag, 8. Februar 2016, 03:17:33 schrieb Andreas F?rber:
>> Signed-off-by: Andreas F?rber <afaerber at suse.de>
> 
> is there some special reason that gmac, emmc, ir, etc are in separate 
> patches? I guess I'll just fold them into the core patch otherwise.

Yes, feel free to squash. They are separate because they were not in v1,
it makes them easier to review and I didn't want errors in them to hold
up the base .dts. :) For example, SDIO I am still fighting with.

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N?rnberg)


From architt at codeaurora.org  Mon Feb  8 02:43:34 2016
From: architt at codeaurora.org (Archit Taneja)
Date: Mon, 8 Feb 2016 16:13:34 +0530
Subject: [PATCH v4 01/11] drm/hisilicon: Add device tree binding for
 hi6220 display subsystem
In-Reply-To: <1454729098-79807-2-git-send-email-xinliang.liu@linaro.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
 <1454729098-79807-2-git-send-email-xinliang.liu@linaro.org>
Message-ID: <56B87156.1040506@codeaurora.org>

Hi,

On 02/06/2016 08:54 AM, Xinliang Liu wrote:
> Add ADE display controller binding doc.
> Add DesignWare DSI Host Controller v1.20a binding doc.
>
> v4:
> - Describe more specific of clocks and ports.
> - Fix indentation.
> v3:
> - Make ade as the drm master node.
> - Use assigned-clocks to set clock rate.
> - Use ports to connect display relavant nodes.
> v2:
> - Move dt binding docs to bindings/display/hisilicon directory.
>
> Signed-off-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
> Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
> ---
>   .../bindings/display/hisilicon/dw-dsi.txt          | 77 ++++++++++++++++++++++
>   .../bindings/display/hisilicon/hisi-ade.txt        | 69 +++++++++++++++++++
>   2 files changed, 146 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>   create mode 100644 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>
> diff --git a/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
> new file mode 100644
> index 000000000000..af6d702f3282
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
> @@ -0,0 +1,77 @@
> +Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
> +
> +A DSI Host Controller resides in the middle of display controller and external
> +HDMI converter.
> +
> +Required properties:
> +- compatible: value should be "hisilicon,hi6220-dsi".
> +- reg: physical base address and length of dsi controller's registers.
> +- clocks: the clocks needed.
> +- clock-names: the name of the clocks.
> +- ports: contains DSI controller input and output sub port.
> +  The input port connects to ADE output port with the reg value "0".
> +  The output port with the reg value "1", it could connect to panel or
> +  any other bridge endpoints. And the reg value for bridge endpoint is "0",
> +  other values for panel endpoint.
> +  See Documentation/devicetree/bindings/graph.txt for more device graph info.
> +
> +A example of HiKey board hi6220 SoC and board specific DT entry:
> +Example:
> +
> +SoC specific:
> +	dsi: dsi at f4107800 {
> +		compatible = "hisilicon,hi6220-dsi";
> +		reg = <0x0 0xf4107800 0x0 0x100>;
> +		clocks = <&media_ctrl  HI6220_DSI_PCLK>;
> +		clock-names = "pclk_dsi";
> +		status = "disabled";
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			/* 0 for input port */
> +			port at 0 {
> +				reg = <0>;
> +				dsi_in: endpoint {
> +					remote-endpoint = <&ade_out>;
> +				};
> +			};
> +		};
> +	};
> +
> +
> +Board specific:
> +	&dsi {
> +		status = "ok";
> +
> +		ports {
> +			/* 1 for output port */
> +			port at 1 {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				reg = <1>;
> +
> +				/* 0 for bridge, other value for panel */
> +				dsi_out0: endpoint at 0 {
> +					reg = <0>;
> +					remote-endpoint = <&adv7533_in>;
> +				};
> +			};
> +		};
> +	};
> +
> +	&i2c2 {
> +		...
> +
> +		adv7533: adv7533 at 39 {
> +			...
> +
> +			port {
> +				adv7533_in: endpoint {
> +					remote-endpoint = <&dsi_out0>;
> +				};
> +			};
> +		};
> +	};
> +
> diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
> new file mode 100644
> index 000000000000..1eff5a41b98d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
> @@ -0,0 +1,69 @@
> +Device-Tree bindings for hisilicon ADE display controller driver
> +
> +ADE (Advanced Display Engine) is the display controller which grab image
> +data from memory, do composition, do post image processing, generate RGB
> +timing stream and transfer to DSI.
> +
> +Required properties:
> +- compatible: value should be "hisilicon,hi6220-ade".
> +- reg: physical base address and length of the controller's registers.
> +  Three reg ranges are used in ADE driver:
> +  ADE reg range, value should be "<0x0 0xf4100000 0x0 0x7800>";
> +  media subsystem reg range, value should be "<0x0 0xf4410000 0x0 0x1000>";
> +  media subsystem NOC QoS reg range, value should be "<0x0 0xf4520000 0x0
> +  0x1000>".
> +- reg-names: name of physical base.Valuse should be "ade_base",	"media_base"
> +  and "media_noc_base".

The "media_base" and "media_noc_base" don't really look like a part of 
the ADE subsytem's MMIO region. If we need to configure these registers,
and currently don't have a driver/api to achieve this, I think it would
be better off to use syscon, because that'll at least ensure that the
registers are consistent among multiple drivers that have ioremapped
these regions. The other possibility would be to keep this out of 
mainline linux until we get drivers that support this in a proper way.

Otherwise, this looks good to me.

Archit

> +- interrupt: the ldi vblank interrupt number used.
> +- clocks: the clocks needed. Three clocks are used in ADE driver:
> +  ADE core clock, value should be "<&media_ctrl HI6220_ADE_CORE>";
> +  ADE pixel clok, value should be "<&media_ctrl HI6220_ADE_PIX_SRC>";
> +  media NOC QoS clock, value should be "<&media_ctrl HI6220_CODEC_JPEG>".
> +- clock-names: the name of the clocks. Values should be "clk_ade_core",
> +  "clk_codec_jpeg" and "clk_ade_pix".
> +- assigned-clocks: clocks to be assigned rate.
> +- assigned-clock-rates: clock rates which are assigned to assigned-clocks.
> +  The rate of <&media_ctrl HI6220_ADE_CORE> could be "360000000" or
> +  "180000000";
> +  The rate of <&media_ctrl HI6220_CODEC_JPEG> could be less than "1440000000".
> +- port: the output port. This contains one endpoint subnode, with its
> +  remote-endpoint set to the phandle of the connected DSI input endpoint.
> +  See Documentation/devicetree/bindings/graph.txt for more device graph info.
> +
> +Optional properties:
> +- dma-coherent: Present if dma operations are coherent.
> +
> +
> +A example of HiKey board hi6220 SoC specific DT entry:
> +Example:
> +
> +	ade: ade at f4100000 {
> +		compatible = "hisilicon,hi6220-ade";
> +		reg = <0x0 0xf4100000 0x0 0x7800>,
> +		      <0x0 0xf4410000 0x0 0x1000>,
> +		      <0x0 0xf4520000 0x0 0x1000>;
> +		reg-names = "ade_base",
> +			    "media_base",
> +			    "media_noc_base";
> +
> +		interrupts = <0 115 4>; /* ldi interrupt */
> +
> +		clocks = <&media_ctrl HI6220_ADE_CORE>,
> +			 <&media_ctrl HI6220_CODEC_JPEG>,
> +			 <&media_ctrl HI6220_ADE_PIX_SRC>;
> +		/*clock name*/
> +		clock-names  = "clk_ade_core",
> +			       "clk_codec_jpeg",
> +			       "clk_ade_pix";
> +
> +		assigned-clocks = <&media_ctrl HI6220_ADE_CORE>,
> +			<&media_ctrl HI6220_CODEC_JPEG>;
> +		assigned-clock-rates = <360000000>, <288000000>;
> +		dma-coherent;
> +
> +		port {
> +			ade_out: endpoint {
> +				remote-endpoint = <&dsi_in>;
> +			};
> +		};
> +	};
>

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation


From antoine.tenart at free-electrons.com  Mon Feb  8 02:44:07 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon, 8 Feb 2016 11:44:07 +0100
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <56B86EA8.9070306@arm.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
 <56B86391.1030609@arm.com> <20160208102656.GA4117@kwain>
 <56B86EA8.9070306@arm.com>
Message-ID: <20160208104407.GB4117@kwain>

On Mon, Feb 08, 2016 at 10:32:08AM +0000, Marc Zyngier wrote:
> On 08/02/16 10:26, Antoine Tenart wrote:
> >>> +static int alpine_msix_init(struct device_node *node,
> >>> +			    struct device_node *parent)
> >>> +{
> >>> +	struct alpine_msix_data *priv;
> >>> +	struct resource res;
> >>> +	int ret;
> >>> +
> >>> +	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> >>> +	if (!priv)
> >>> +		return -ENOMEM;
> >>> +
> >>> +	spin_lock_init(&priv->msi_map_lock);
> >>> +
> >>> +	ret = of_address_to_resource(node, 0, &res);
> >>> +	if (ret) {
> >>> +		pr_err("Failed to allocate resource\n");
> >>> +		goto err_priv;
> >>> +	}
> >>> +
> >>> +	priv->addr_high = upper_32_bits((u64)res.start);
> >>> +	priv->addr_low = lower_32_bits(res.start) + ALPINE_MSIX_SPI_TARGET_CLUSTER0;
> >>
> >> This is a bit odd. If you always set bit 16, why isn't that reflected in
> >> the base address coming from the DT?
> > 
> > The 20 least significant bits of addr_low provide direct information
> > regarding the interrupt destination, so I thought it would be clearer
> > to have this explicitly in the driver so that we know what those bits
> > mean.
> 
> So what is this information? TARGET_CLUSTER0 is not very expressive, and
> doesn't show what the alternatives are. Could you please elaborate a bit
> on that front?

For now lots of bits are reserved, so there aren't many alternatives.
Bits [18:17] are used to set the GIC to which to route the MSI and bit
16 must be set when this target GIC is the primary GIC (bits [18:17] set
to 0x0). There aren't other options available for now (that I'm aware
of) for the target GIC configuration.

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160208/845247f2/attachment.sig>

From afaerber at suse.de  Mon Feb  8 02:51:04 2016
From: afaerber at suse.de (=?UTF-8?Q?Andreas_F=c3=a4rber?=)
Date: Mon, 8 Feb 2016 11:51:04 +0100
Subject: [PATCH v2 09/10] Documentation: devicetree: rockchip: Document
 Landingship
In-Reply-To: <6744409.i2u8076vm4@phil>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
 <1454897859-7601-10-git-send-email-afaerber@suse.de>
 <6744409.i2u8076vm4@phil>
Message-ID: <56B87318.9020007@suse.de>

Am 08.02.2016 um 11:29 schrieb Heiko Stuebner:
> Am Montag, 8. Februar 2016, 03:17:38 schrieb Andreas F?rber:
>> Use "geekbuying,landingship" compatible string, plus those of GeekBox.
> 
> I do believe this would be better as geekbuying,geekbox-landingship . They 
> might reuse the landingship naming for future baseboards as well ;-)

Well, the question is: Is this MXM3 interface as generic as Qseven so
that it could be used as is for other modules (and baseboards from other
manufacturers could be used for the module)? Then my thought was
landingship as identifier for the baseboard and geekbox as identifier
for the contained module.

I agree that if this Landingship is specific to the GeekBox then
geekbox-landingship would be more appropriate. We could also do both.

Can you tell? Unfortunately I spot no real documentation of the MXM3
connector pins in the schematics we could compare, only an on-board
documentation of the three-row pins.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N?rnberg)


From mark.rutland at arm.com  Mon Feb  8 02:51:05 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 8 Feb 2016 10:51:05 +0000
Subject: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <20160208105104.GA12991@leverpostej>

Hi,

> +	chosen {
> +		stdout-path = "console0:115200n8";
> +	};

There is no console0 alias, so this cannot work.

Did you mean serial0?

[...]

> +	aliases {
> +		serial0 = &uart0;
> +		serial1 = &uart1;
> +		serial2 = &uart2;
> +		serial3 = &uart3;
> +	};

[...]

> +	psci {
> +		compatible = "arm,psci-0.2", "arm,psci";
> +		method = "smc";
> +		cpu_on = <0x84000003>;
> +	};

If you have PSCI 0.2, the cpu_on ID (and all other mandatory function
IDs) are implicit.

If you want to have "arm,psci" as a fallback, then please add the IDs
for functions mandatory in PSCI 0.2 which existed in the "arm,psci"
binding. Otherwise, drop "arm,psci" from the compatible list, along
with the cpu_on function ID.

THanks,
Mark.


From heiko at sntech.de  Mon Feb  8 02:52:21 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 08 Feb 2016 11:52:21 +0100
Subject: [PATCH v7 0/5] Add mipi dsi support for rk3288
In-Reply-To: <56B869F4.6090507@codeaurora.org>
References: <1452053038-32098-1-git-send-email-zyw@rock-chips.com>
 <56B869F4.6090507@codeaurora.org>
Message-ID: <5060470.dfeHX20DRa@phil>

Hi Archit,

Am Montag, 8. Februar 2016, 15:42:04 schrieb Archit Taneja:
> On 01/06/2016 09:33 AM, Chris Zhong wrote:
> > The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
> > IP. This series adds support for a Synopsys DesignWare MIPI DSI host
> > controller DRM driver.
> > 
> > The MIPI DSI feature is tested on rk3288 evb board, backport them to
> > chrome os kernel chrome_v3.14, and it can display normally.
> > 
> > This patchset is base on the patchset from Ying.liu at freescale.com.
> > <http://www.spinics.net/lists/dri-devel/msg77181.html>
> > 
> > According to the suggestion from Thierry, I have get rid of the bridge,
> > and register the encoder & connecter in drm/rockchip/dw-mipi-dsi.c.
> 
> I've raised this question too late, but what was the reason to not
> implement the DSI block as a bridge driver?

There seems to always be some sort of contention about those being bridge 
drivers - I think I remember Thierry speaking up about that. But I don't 
remember if any different solution was suggested.

Also as we have seen with current shared IPs (dw-hdmi + analogix-dp) there 
are always implementation-specific parts and deciding which needs to land 
where is difficult without the secondary user present.

The first iterations where using a bridge-driver-base for it but I guess it 
was to much hassle without seeing another user on the horizon.


> The drm/hisilicon IP seems to use a very similar DSI Designware IP (the
> register offsets seems to be the same). There is a good potential of
> re-use here by different kms drivers here the way it's already done for
> DW HDMI and the analogix DP driver that's in review process.

I guess, the second user now gets to do the generalization ;-)


Heiko



From alexander.shishkin at linux.intel.com  Mon Feb  8 02:52:57 2016
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Mon, 08 Feb 2016 12:52:57 +0200
Subject: [PATCH V2 3/6] stm class: provision for statically assigned
 masterIDs
In-Reply-To: <DB3PR08MB0041B8843C61FCEB049B2BB58CD20@DB3PR08MB0041.eurprd08.prod.outlook.com>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
 <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org>
 <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com>
 <DB3PR08MB0041B8843C61FCEB049B2BB58CD20@DB3PR08MB0041.eurprd08.prod.outlook.com>
Message-ID: <87si13cw3a.fsf@ashishki-desk.ger.corp.intel.com>

Mike Leach <Mike.Leach at arm.com> writes:

> Hi,
>
> I think a quick clarification of the ARM hardware STM architecture may be of value here.
>
> The ARM hardware STM, when implemented as recommend in a hardware design, the master IDs are not under driver control, but have a hardwire association with source devices in the system. The master IDs are hardwired to individual cores and core security states, and there could be other IDs associated with hardware trace sources requiring output via the hardware STM. (an example of this is the ARM Juno development board).
>
> Therefore in multi-core systems many masters may be associated with a single software STM stream. A user-space application running on Core 1, may have a master ID of 0x11 in the STPv2 trace stream, but if this application is context switched and later continues running on Core 2, then master ID could change to 0x21.  Masters identify a hardware source in this scheme, the precise values used will be implementation dependent.
>
> So the number of masters "available to the software" depends on your interpretation of the phrase.
> If you mean "master IDs on which software trace will appear" then that will be many - it depends on which core is running the application. However as described above, this is not predictable by any decoder, and the master set used may not be contiguous.
> If you mean "master IDs selectable/allocated by the driver" then that will be 0 - the driver has no control, and possibly no knowledge of which master is associated with the current execution context. (this is of course system dependent - it may well be possible to have some configuration database associating cores with hardware IDs, but this will be implementation and board support dependant).
>
> Therefore, there is a requirement to tell both the user-space STM client and decoder that not only is master ID management not needed - it is in fact not possible and the key to identify the software source for a given STM packet is the channel alone. In addition we have a nominal single Master ID "available to the software", to satisfy the requirements of the generic ST module API.
>
> So on Juno for example, while we do have 128 masters, each with 65536 channels, the master allocation is not visible to system software - each core sees a single master with 65536 channels. Therefore differentiation between software sources in the STM trace is by channel number allocations only.

Ok, thanks a lot for the detailed explanation. I was confused by the
"static" bit in the patch description. It looks like something along the
lines of this patch might indeed be in order.

Regards,
--
Alex


From afaerber at suse.de  Mon Feb  8 02:55:44 2016
From: afaerber at suse.de (=?UTF-8?Q?Andreas_F=c3=a4rber?=)
Date: Mon, 8 Feb 2016 11:55:44 +0100
Subject: [PATCH] clk: meson: Fix meson_clk_register_clks() signature type
 mismatch
In-Reply-To: <CAOQ7t2YwHa7cJdqv4m8rPx50ZnFZJJzcU2AjtE=Q2AYEAf84hg@mail.gmail.com>
References: <1454879583-27036-1-git-send-email-afaerber@suse.de>
 <CAOQ7t2YwHa7cJdqv4m8rPx50ZnFZJJzcU2AjtE=Q2AYEAf84hg@mail.gmail.com>
Message-ID: <56B87430.3040804@suse.de>

Am 08.02.2016 um 09:34 schrieb Carlo Caione:
> On Sun, Feb 7, 2016 at 10:13 PM, Andreas F?rber <afaerber at suse.de> wrote:
>> As preparation for arm64 based mesongxbb, which pulls in this code once
>> enabling ARCH_MESON, fix a size_t vs. unsigned int type mismatch.
>> The loop uses a local unsigned int variable, so adopt that type,
>> matching the header.
>>
>> Fixes: 7a29a869434e ("clk: meson: Add support for Meson clock controller")
>> Signed-off-by: Andreas F?rber <afaerber at suse.de>
>> ---
>>  drivers/clk/meson/clkc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
[...]
> Also please, CC linux-meson at googlegroups.com on meson related patches.

I used scripts/get_maintainer.pl --nogit-fallback on next-20160111. :)

If there is no in-flight patch I've missed, I can send a patch against
MAINTAINERS to update it with that list address.

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N?rnberg)


From marc.zyngier at arm.com  Mon Feb  8 02:56:16 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 8 Feb 2016 10:56:16 +0000
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <20160208104407.GB4117@kwain>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
 <56B86391.1030609@arm.com> <20160208102656.GA4117@kwain>
 <56B86EA8.9070306@arm.com> <20160208104407.GB4117@kwain>
Message-ID: <56B87450.1040500@arm.com>

On 08/02/16 10:44, Antoine Tenart wrote:
> On Mon, Feb 08, 2016 at 10:32:08AM +0000, Marc Zyngier wrote:
>> On 08/02/16 10:26, Antoine Tenart wrote:
>>>>> +static int alpine_msix_init(struct device_node *node,
>>>>> +			    struct device_node *parent)
>>>>> +{
>>>>> +	struct alpine_msix_data *priv;
>>>>> +	struct resource res;
>>>>> +	int ret;
>>>>> +
>>>>> +	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>>>>> +	if (!priv)
>>>>> +		return -ENOMEM;
>>>>> +
>>>>> +	spin_lock_init(&priv->msi_map_lock);
>>>>> +
>>>>> +	ret = of_address_to_resource(node, 0, &res);
>>>>> +	if (ret) {
>>>>> +		pr_err("Failed to allocate resource\n");
>>>>> +		goto err_priv;
>>>>> +	}
>>>>> +
>>>>> +	priv->addr_high = upper_32_bits((u64)res.start);
>>>>> +	priv->addr_low = lower_32_bits(res.start) + ALPINE_MSIX_SPI_TARGET_CLUSTER0;
>>>>
>>>> This is a bit odd. If you always set bit 16, why isn't that reflected in
>>>> the base address coming from the DT?
>>>
>>> The 20 least significant bits of addr_low provide direct information
>>> regarding the interrupt destination, so I thought it would be clearer
>>> to have this explicitly in the driver so that we know what those bits
>>> mean.
>>
>> So what is this information? TARGET_CLUSTER0 is not very expressive, and
>> doesn't show what the alternatives are. Could you please elaborate a bit
>> on that front?
> 
> For now lots of bits are reserved, so there aren't many alternatives.
> Bits [18:17] are used to set the GIC to which to route the MSI and bit
> 16 must be set when this target GIC is the primary GIC (bits [18:17] set
> to 0x0). There aren't other options available for now (that I'm aware
> of) for the target GIC configuration.

OK. So maybe add that as a comment, so that people know what is
happening there. And if the code gets updated to include new
functionalities, it will be easier to track the changes.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From stefano.stabellini at eu.citrix.com  Mon Feb  8 02:57:01 2016
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 8 Feb 2016 10:57:01 +0000
Subject: [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen
In-Reply-To: <CAJZ5v0id-035AtyQ_SccPuCxD7+pa6GCgj3WBAojM+rFqssGQQ@mail.gmail.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
 <1454641552-12576-2-git-send-email-zhaoshenglong@huawei.com>
 <CAJZ5v0id-035AtyQ_SccPuCxD7+pa6GCgj3WBAojM+rFqssGQQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1602081054350.27008@kaball.uk.xensource.com>

On Sat, 6 Feb 2016, Rafael J. Wysocki wrote:
> On Fri, Feb 5, 2016 at 4:05 AM, Shannon Zhao <zhaoshenglong at huawei.com> wrote:
> > From: Shannon Zhao <shannon.zhao at linaro.org>
> >
> > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > UART is used by Xen. So here it hides UART from Dom0.
> >
> > Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> > Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> 
> Well, this doesn't look right to me.
> 
> We need to find a nicer way to achieve what you want.

I take that you are talking about how to honor the STAO table in Linux.
Do you have any concrete suggestions?


From architt at codeaurora.org  Mon Feb  8 02:59:01 2016
From: architt at codeaurora.org (Archit Taneja)
Date: Mon, 8 Feb 2016 16:29:01 +0530
Subject: [PATCH v4 03/11] drm/hisilicon: Add crtc driver for ADE
In-Reply-To: <1454729098-79807-4-git-send-email-xinliang.liu@linaro.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
 <1454729098-79807-4-git-send-email-xinliang.liu@linaro.org>
Message-ID: <56B874F5.8020103@codeaurora.org>



On 02/06/2016 08:54 AM, Xinliang Liu wrote:
> Add crtc funcs and helper funcs for ADE.
>
> v4: None.
> v3:
> - Make ade as the master driver.
> - Use port to connect with encoder.
> - A few cleanup.
> v2:
> - Remove abtraction layer.
>
> Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
> ---
>   drivers/gpu/drm/hisilicon/kirin/Makefile        |   3 +-
>   drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 280 +++++++++++++++
>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 458 ++++++++++++++++++++++++
>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  15 +
>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |   8 +
>   5 files changed, 763 insertions(+), 1 deletion(-)
>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile b/drivers/gpu/drm/hisilicon/kirin/Makefile
> index cb346de47d48..2a61ab006ddb 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/Makefile
> +++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
> @@ -1,3 +1,4 @@
> -kirin-drm-y := kirin_drm_drv.o
> +kirin-drm-y := kirin_drm_drv.o \
> +	       kirin_drm_ade.o
>
>   obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
> new file mode 100644
> index 000000000000..78020747abfe
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
> @@ -0,0 +1,280 @@
> +/*
> + * Copyright (c) 2016 Linaro Limited.
> + * Copyright (c) 2014-2016 Hisilicon Limited.
> + *
> + * 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.
> + *
> + */
> +
> +#ifndef __KIRIN_ADE_REG_H__
> +#define __KIRIN_ADE_REG_H__
> +
> +/*
> + * ADE Registers
> + */
> +#define MASK(x)				(BIT(x) - 1)
> +
> +#define ADE_CTRL			0x0004
> +#define FRM_END_START_OFST		0
> +#define FRM_END_START_MASK		MASK(2)
> +#define ADE_CTRL1			0x008C
> +#define AUTO_CLK_GATE_EN_OFST		0
> +#define AUTO_CLK_GATE_EN		BIT(0)
> +#define ADE_ROT_SRC_CFG			0x0010
> +#define ADE_DISP_SRC_CFG		0x0018
> +#define ADE_WDMA2_SRC_CFG		0x001C
> +#define ADE_SEC_OVLY_SRC_CFG		0x0020
> +#define ADE_WDMA3_SRC_CFG		0x0024
> +#define ADE_OVLY1_TRANS_CFG		0x002C
> +#define ADE_EN				0x0100
> +#define ADE_DISABLE			0
> +#define ADE_ENABLE			1
> +#define INTR_MASK_CPU(x)		(0x0C10 + (x) * 0x4)
> +#define ADE_FRM_DISGARD_CTRL		0x00A4
> +/* reset and reload regs */
> +#define ADE_SOFT_RST_SEL(x)		(0x0078 + (x) * 0x4)
> +#define ADE_RELOAD_DIS(x)		(0x00AC + (x) * 0x4)
> +#define RDMA_OFST			0
> +#define CLIP_OFST			15
> +#define SCL_OFST			21
> +#define CTRAN_OFST			24
> +#define OVLY_OFST			37 /* 32+5 */
> +/* channel regs */
> +#define RD_CH_PE(x)			(0x1000 + (x) * 0x80)
> +#define RD_CH_CTRL(x)			(0x1004 + (x) * 0x80)
> +#define RD_CH_ADDR(x)			(0x1008 + (x) * 0x80)
> +#define RD_CH_SIZE(x)			(0x100C + (x) * 0x80)
> +#define RD_CH_STRIDE(x)			(0x1010 + (x) * 0x80)
> +#define RD_CH_SPACE(x)			(0x1014 + (x) * 0x80)
> +#define RD_CH_PARTIAL_SIZE(x)		(0x1018 + (x) * 0x80)
> +#define RD_CH_PARTIAL_SPACE(x)		(0x101C + (x) * 0x80)
> +#define RD_CH_EN(x)			(0x1020 + (x) * 0x80)
> +#define RD_CH_STATUS(x)			(0x1024 + (x) * 0x80)
> +#define RD_CH_DISP_CTRL			0x1404
> +#define RD_CH_DISP_ADDR			0x1408
> +#define RD_CH_DISP_SIZE			0x140C
> +#define RD_CH_DISP_STRIDE		0x1410
> +#define RD_CH_DISP_SPACE		0x1414
> +#define RD_CH_DISP_EN			0x142C
> +/* clip regs */
> +#define ADE_CLIP_DISABLE(x)		(0x6800 + (x) * 0x100)
> +#define ADE_CLIP_SIZE0(x)		(0x6804 + (x) * 0x100)
> +#define ADE_CLIP_SIZE1(x)		(0x6808 + (x) * 0x100)
> +#define ADE_CLIP_SIZE2(x)		(0x680C + (x) * 0x100)
> +#define ADE_CLIP_CFG_OK(x)		(0x6810 + (x) * 0x100)
> +/* scale regs */
> +#define ADE_SCL1_MUX_CFG		0x000C
> +#define ADE_SCL2_SRC_CFG		0x0014
> +#define ADE_SCL3_MUX_CFG		0x0008
> +#define ADE_SCL_CTRL(x)			(0x3000 + (x) * 0x800)
> +#define ADE_SCL_HSP(x)			(0x3004 + (x) * 0x800)
> +#define ADE_SCL_UV_HSP(x)		(0x3008 + (x) * 0x800)
> +#define ADE_SCL_VSP(x)			(0x300C + (x) * 0x800)
> +#define ADE_SCL_UV_VSP(x)		(0x3010 + (x) * 0x800)
> +#define ADE_SCL_ORES(x)			(0x3014 + (x) * 0x800)
> +#define ADE_SCL_IRES(x)			(0x3018 + (x) * 0x800)
> +#define ADE_SCL_START(x)		(0x301C + (x) * 0x800)
> +#define ADE_SCL_ERR(x)			(0x3020 + (x) * 0x800)
> +#define ADE_SCL_PIX_OFST(x)		(0x3024 + (x) * 0x800)
> +#define ADE_SCL_UV_PIX_OFST(x)		(0x3028 + (x) * 0x800)
> +#define ADE_SCL_COEF_CLR(x)		(0x3030 + (x) * 0x800)
> +#define ADE_SCL_HCOEF(x, m, n)		(0x3100 + (x) * 0x800 + \
> +					12 * (m) + 4 * (n))
> +#define ADE_SCL_VCOEF(x, i, j)		(0x340C + (x) * 0x800 + \
> +					12 * (i) + 4 * (j))
> +/* ctran regs */
> +#define ADE_CTRAN5_TRANS_CFG		0x0040
> +#define ADE_CTRAN_DIS(x)		(0x5004 + (x) * 0x100)
> +#define CTRAN_BYPASS_ON			1
> +#define CTRAN_BYPASS_OFF		0
> +#define ADE_CTRAN_MODE_CHOOSE(x)	(0x5008 + (x) * 0x100)
> +#define ADE_CTRAN_STAT(x)		(0x500C + (x) * 0x100)
> +#define ADE_CTRAN_CHDC0(x)		(0x5010 + (x) * 0x100)
> +#define ADE_CTRAN_CHDC1(x)		(0x5014 + (x) * 0x100)
> +#define ADE_CTRAN_CHDC2(x)		(0x5018 + (x) * 0x100)
> +#define ADE_CTRAN_CHDC3(x)		(0x501C + (x) * 0x100)
> +#define ADE_CTRAN_CHDC4(x)		(0x5020 + (x) * 0x100)
> +#define ADE_CTRAN_CHDC5(x)		(0x5024 + (x) * 0x100)
> +#define ADE_CTRAN_CSC0(x)		(0x5028 + (x) * 0x100)
> +#define ADE_CTRAN_CSC1(x)		(0x502C + (x) * 0x100)
> +#define ADE_CTRAN_CSC2(x)		(0x5030 + (x) * 0x100)
> +#define ADE_CTRAN_CSC3(x)		(0x5034 + (x) * 0x100)
> +#define ADE_CTRAN_CSC4(x)		(0x5038 + (x) * 0x100)
> +#define ADE_CTRAN_IMAGE_SIZE(x)		(0x503C + (x) * 0x100)
> +#define ADE_CTRAN_CFG_OK(x)		(0x5040 + (x) * 0x100)
> +/* overlay regs */
> +#define ADE_OVLY_ALPHA_ST		0x2000
> +#define ADE_OVLY_CH_XY0(x)		(0x2004 + (x) * 4)
> +#define ADE_OVLY_CH_XY1(x)		(0x2024 + (x) * 4)
> +#define ADE_OVLY_CH_CTL(x)		(0x204C + (x) * 4)
> +#define ADE_OVLY_OUTPUT_SIZE(x)		(0x2070 + (x) * 8)
> +#define OUTPUT_XSIZE_OFST		16
> +#define ADE_OVLY_BASE_COLOR(x)		(0x2074 + (x) * 8)
> +#define ADE_OVLYX_CTL(x)		(0x209C + (x) * 4)
> +#define ADE_OVLY_CTL			0x0098
> +#define CH_OVLY_SEL_OFST(x)		((x) * 4)
> +#define CH_OVLY_SEL_MASK		MASK(2)
> +#define CH_OVLY_SEL_VAL(x)		((x) + 1)
> +#define CH_ALP_MODE_OFST		0
> +#define CH_ALP_SEL_OFST			2
> +#define CH_UNDER_ALP_SEL_OFST		4
> +#define CH_EN_OFST			6
> +#define CH_ALP_GBL_OFST			15
> +#define CH_SEL_OFST			28
> +
> +/*
> + * LDI Registers
> + */
> +#define LDI_HRZ_CTRL0			0x7400
> +#define HBP_OFST			20
> +#define LDI_HRZ_CTRL1			0x7404
> +#define LDI_VRT_CTRL0			0x7408
> +#define VBP_OFST			20
> +#define LDI_VRT_CTRL1			0x740C
> +#define LDI_PLR_CTRL			0x7410
> +#define FLAG_NVSYNC			BIT(0)
> +#define FLAG_NHSYNC			BIT(1)
> +#define FLAG_NPIXCLK			BIT(2)
> +#define FLAG_NDE			BIT(3)
> +#define LDI_DSP_SIZE			0x7414
> +#define VSIZE_OFST			20
> +#define LDI_INT_EN			0x741C
> +#define FRAME_END_INT_EN_OFST		1
> +#define LDI_CTRL			0x7420
> +#define BPP_OFST			3
> +#define DATA_GATE_EN			BIT(2)
> +#define LDI_EN				BIT(0)
> +#define LDI_ORG_INT			0x7424
> +#define LDI_MSK_INT			0x7428
> +#define LDI_INT_CLR			0x742C
> +#define LDI_WORK_MODE			0x7430
> +#define LDI_DE_SPACE_LOW		0x7438
> +#define LDI_MCU_INTS			0x7450
> +#define LDI_MCU_INTE			0x7454
> +#define LDI_MCU_INTC			0x7458
> +#define LDI_HDMI_DSI_GT			0x7434
> +
> +/*
> + * media regs
> + */
> +#define SC_MEDIA_RSTDIS				0x0530
> +#define SC_MEDIA_RSTEN				0x052C
> +#define NOC_ADE0_QOSGENERATOR_MODE		0x010C
> +#define NOC_ADE0_QOSGENERATOR_EXTCONTROL	0x0118
> +#define NOC_ADE1_QOSGENERATOR_MODE		0x020C
> +#define NOC_ADE1_QOSGENERATOR_EXTCONTROL	0x0218
> +
> +/*
> + * ADE regs relevant enums
> + */
> +enum frame_end_start {
> +	/* regs take effective in every vsync */
> +	REG_EFFECTIVE_IN_VSYNC = 0,
> +	/* regs take effective in fist ade en and every frame end */
> +	REG_EFFECTIVE_IN_ADEEN_FRMEND,
> +	/* regs take effective in ade en immediately */
> +	REG_EFFECTIVE_IN_ADEEN,
> +	/* regs take effective in first vsync and every frame end */
> +	REG_EFFECTIVE_IN_VSYNC_FRMEND
> +};
> +
> +enum ade_fb_format {
> +	ADE_RGB_565 = 0,
> +	ADE_BGR_565,
> +	ADE_XRGB_8888,
> +	ADE_XBGR_8888,
> +	ADE_ARGB_8888,
> +	ADE_ABGR_8888,
> +	ADE_RGBA_8888,
> +	ADE_BGRA_8888,
> +	ADE_RGB_888,
> +	ADE_BGR_888 = 9,
> +	ADE_FORMAT_NOT_SUPPORT = 800
> +};
> +
> +enum ade_channel {
> +	ADE_CH1 = 0,	/* channel 1 for primary plane */
> +	ADE_CH_NUM
> +};
> +
> +enum ade_scale {
> +	ADE_SCL1 = 0,
> +	ADE_SCL2,
> +	ADE_SCL3,
> +	ADE_SCL_NUM
> +};
> +
> +enum ade_ctran {
> +	ADE_CTRAN1 = 0,
> +	ADE_CTRAN2,
> +	ADE_CTRAN3,
> +	ADE_CTRAN4,
> +	ADE_CTRAN5,
> +	ADE_CTRAN6,
> +	ADE_CTRAN_NUM
> +};
> +
> +enum ade_overlay {
> +	ADE_OVLY1 = 0,
> +	ADE_OVLY2,
> +	ADE_OVLY3,
> +	ADE_OVLY_NUM
> +};
> +
> +enum ade_alpha_mode {
> +	ADE_ALP_GLOBAL = 0,
> +	ADE_ALP_PIXEL,
> +	ADE_ALP_PIXEL_AND_GLB
> +};
> +
> +enum ade_alpha_blending_mode {
> +	ADE_ALP_MUL_COEFF_0 = 0,	/* alpha */
> +	ADE_ALP_MUL_COEFF_1,		/* 1-alpha */
> +	ADE_ALP_MUL_COEFF_2,		/* 0 */
> +	ADE_ALP_MUL_COEFF_3		/* 1 */
> +};
> +
> +/*
> + * LDI regs relevant enums
> + */
> +enum dsi_pclk_en {
> +	DSI_PCLK_ON = 0,
> +	DSI_PCLK_OFF
> +};
> +
> +enum ldi_output_format {
> +	LDI_OUT_RGB_565 = 0,
> +	LDI_OUT_RGB_666,
> +	LDI_OUT_RGB_888
> +};
> +
> +enum ldi_work_mode {
> +	TEST_MODE = 0,
> +	NORMAL_MODE
> +};
> +
> +enum ldi_input_source {
> +	DISP_SRC_NONE = 0,
> +	DISP_SRC_OVLY2,
> +	DISP_SRC_DISP,
> +	DISP_SRC_ROT,
> +	DISP_SRC_SCL2
> +};
> +
> +/*
> + * Register Write/Read Helper functions
> + */
> +static inline void ade_update_bits(void __iomem *addr, u32 bit_start,
> +				   u32 mask, u32 val)
> +{
> +	u32 tmp, orig;
> +
> +	orig = readl(addr);
> +	tmp = orig & ~(mask << bit_start);
> +	tmp |= (val & mask) << bit_start;
> +	writel(tmp, addr);
> +}
> +
> +#endif
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> new file mode 100644
> index 000000000000..b45149616716
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> @@ -0,0 +1,458 @@
> +/*
> + * Hisilicon Hi6220 SoC ADE(Advanced Display Engine)'s crtc&plane driver
> + *
> + * Copyright (c) 2016 Linaro Limited.
> + * Copyright (c) 2014-2016 Hisilicon Limited.
> + *
> + * Author:
> + *	Xinliang Liu <z.liuxinliang at hisilicon.com>
> + *	Xinliang Liu <xinliang.liu at linaro.org>
> + *	Xinwei Kong <kong.kongxinwei at hisilicon.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.
> + *
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/clk.h>
> +#include <video/display_timing.h>
> +
> +#include <drm/drmP.h>
> +#include <drm/drm_crtc.h>
> +#include <drm/drm_crtc_helper.h>
> +#include <drm/drm_atomic.h>
> +#include <drm/drm_atomic_helper.h>
> +
> +#include "kirin_drm_drv.h"
> +#include "kirin_ade_reg.h"
> +
> +#define to_ade_crtc(crtc) \
> +	container_of(crtc, struct ade_crtc, base)
> +
> +struct ade_hw_ctx {
> +	void __iomem  *base;
> +	void __iomem  *media_base;
> +	void __iomem  *media_noc_base;
> +	int irq;
> +	struct clk *ade_core_clk;
> +	struct clk *media_noc_clk;
> +	struct clk *ade_pix_clk;
> +	bool power_on;
> +};
> +
> +struct ade_crtc {
> +	struct drm_crtc base;
> +	struct ade_hw_ctx *ctx;
> +	bool enable;
> +	u32 out_format;
> +};
> +
> +struct ade_data {
> +	struct ade_crtc acrtc;
> +	struct ade_hw_ctx ctx;
> +};
> +
> +static void ade_update_reload_bit(void __iomem *base, u32 bit_num, u32 val)
> +{
> +	u32 bit_ofst, reg_num;
> +
> +	bit_ofst = bit_num % 32;
> +	reg_num = bit_num / 32;
> +
> +	ade_update_bits(base + ADE_RELOAD_DIS(reg_num), bit_ofst,
> +			MASK(1), !!val);
> +}
> +
> +static u32 ade_read_reload_bit(void __iomem *base, u32 bit_num)
> +{
> +	u32 tmp, bit_ofst, reg_num;
> +
> +	bit_ofst = bit_num % 32;
> +	reg_num = bit_num / 32;
> +
> +	tmp = readl(base + ADE_RELOAD_DIS(reg_num));
> +	return !!(BIT(bit_ofst) & tmp);
> +}
> +
> +static void ade_init(struct ade_hw_ctx *ctx)
> +{
> +	void __iomem *base = ctx->base;
> +
> +	/* enable clk gate */
> +	ade_update_bits(base + ADE_CTRL1, AUTO_CLK_GATE_EN_OFST,
> +			AUTO_CLK_GATE_EN, ADE_ENABLE);
> +	/* clear overlay */
> +	writel(0, base + ADE_OVLY1_TRANS_CFG);
> +	writel(0, base + ADE_OVLY_CTL);
> +	writel(0, base + ADE_OVLYX_CTL(ADE_OVLY2));
> +	/* clear reset and reload regs */
> +	writel(MASK(32), base + ADE_SOFT_RST_SEL(0));
> +	writel(MASK(32), base + ADE_SOFT_RST_SEL(1));
> +	writel(MASK(32), base + ADE_RELOAD_DIS(0));
> +	writel(MASK(32), base + ADE_RELOAD_DIS(1));
> +	/* for video mode, that ade registers
> +	 * became effective at frame end
> +	 */
> +	ade_update_bits(base + ADE_CTRL, FRM_END_START_OFST,
> +			FRM_END_START_MASK, REG_EFFECTIVE_IN_ADEEN_FRMEND);
> +}
> +
> +static void ade_ldi_set_mode(struct ade_crtc *acrtc,
> +			     struct drm_display_mode *mode,
> +			     struct drm_display_mode *adj_mode)
> +{
> +	struct ade_hw_ctx *ctx = acrtc->ctx;
> +	void __iomem *base = ctx->base;
> +	u32 width = mode->hdisplay;
> +	u32 height = mode->vdisplay;
> +	u32 hfp, hbp, hsw, vfp, vbp, vsw;
> +	u32 plr_flags;
> +	int ret;
> +
> +	plr_flags = (mode->flags & DRM_MODE_FLAG_NVSYNC) ? FLAG_NVSYNC : 0;
> +	plr_flags |= (mode->flags & DRM_MODE_FLAG_NHSYNC) ? FLAG_NHSYNC : 0;
> +	hfp = mode->hsync_start - mode->hdisplay;
> +	hbp = mode->htotal - mode->hsync_end;
> +	hsw = mode->hsync_end - mode->hsync_start;
> +	vfp = mode->vsync_start - mode->vdisplay;
> +	vbp = mode->vtotal - mode->vsync_end;
> +	vsw = mode->vsync_end - mode->vsync_start;
> +	if (vsw > 15) {
> +		DRM_DEBUG_DRIVER("vsw exceeded 15\n");
> +		vsw = 15;
> +	}
> +
> +	writel((hbp << HBP_OFST) | hfp, base + LDI_HRZ_CTRL0);
> +	 /* the configured value is actual value - 1 */
> +	writel(hsw - 1, base + LDI_HRZ_CTRL1);
> +	writel((vbp << VBP_OFST) | vfp, base + LDI_VRT_CTRL0);
> +	 /* the configured value is actual value - 1 */
> +	writel(vsw - 1, base + LDI_VRT_CTRL1);
> +	 /* the configured value is actual value - 1 */
> +	writel(((height - 1) << VSIZE_OFST) | (width - 1),
> +	       base + LDI_DSP_SIZE);
> +	writel(plr_flags, base + LDI_PLR_CTRL);
> +
> +	/* Success should be guaranteed in mode_valid call back,
> +	 * so failer shouldn't happen here
> +	 */
> +	ret = clk_set_rate(ctx->ade_pix_clk, mode->clock * 1000);
> +	if (ret)
> +		DRM_ERROR("failed to set pixel clk %dHz (%d)\n",
> +			  mode->clock * 1000, ret);
> +	adj_mode->clock = clk_get_rate(ctx->ade_pix_clk) / 1000;
> +
> +	/* ctran6 setting */
> +	writel(CTRAN_BYPASS_ON, base + ADE_CTRAN_DIS(ADE_CTRAN6));
> +	 /* the configured value is actual value - 1 */
> +	writel(width * height - 1, base + ADE_CTRAN_IMAGE_SIZE(ADE_CTRAN6));
> +	ade_update_reload_bit(base, CTRAN_OFST + ADE_CTRAN6, 0);
> +
> +	DRM_DEBUG_DRIVER("set mode: %dx%d\n", width, height);
> +}
> +
> +static int ade_power_up(struct ade_hw_ctx *ctx)
> +{
> +	void __iomem *media_base = ctx->media_base;
> +	int ret;
> +
> +	ret = clk_prepare_enable(ctx->media_noc_clk);
> +	if (ret) {
> +		DRM_ERROR("failed to enable media_noc_clk (%d)\n", ret);
> +		return ret;
> +	}
> +
> +	writel(0x20, media_base + SC_MEDIA_RSTDIS);

If this and the write in ade_power_down are to reset the
ADE block, they should ideally belong to clock/reset subsystem
and not touched by the driver.

> +
> +	ret = clk_prepare_enable(ctx->ade_core_clk);
> +	if (ret) {
> +		DRM_ERROR("failed to enable ade_core_clk (%d)\n", ret);
> +		return ret;
> +	}
> +
> +	ade_init(ctx);
> +	ctx->power_on = true;
> +	return 0;
> +}
> +
> +static void ade_power_down(struct ade_hw_ctx *ctx)
> +{
> +	void __iomem *base = ctx->base;
> +	void __iomem *media_base = ctx->media_base;
> +
> +	writel(ADE_DISABLE, base + LDI_CTRL);
> +	/* dsi pixel off */
> +	writel(DSI_PCLK_OFF, base + LDI_HDMI_DSI_GT);
> +
> +	clk_disable_unprepare(ctx->ade_core_clk);
> +	writel(0x20, media_base + SC_MEDIA_RSTEN);
> +	clk_disable_unprepare(ctx->media_noc_clk);
> +	ctx->power_on = false;
> +}
> +
> +static void ade_set_medianoc_qos(struct ade_crtc *acrtc)
> +{
> +	struct ade_hw_ctx *ctx = acrtc->ctx;
> +	void __iomem *base = ctx->media_noc_base;
> +	void __iomem *reg;
> +	u32 val;
> +
> +	reg = base + NOC_ADE0_QOSGENERATOR_MODE;
> +	val = (readl(reg) & 0xfffffffc) | 0x2;
> +	writel(val, reg);
> +
> +	reg = base + NOC_ADE0_QOSGENERATOR_EXTCONTROL;
> +	val = readl(reg) | 0x1;
> +	writel(val, reg);
> +
> +	reg = base + NOC_ADE1_QOSGENERATOR_MODE;
> +	val = (readl(reg) & 0xfffffffc) | 0x2;
> +	writel(val, reg);
> +
> +	reg = base + NOC_ADE1_QOSGENERATOR_EXTCONTROL;
> +	val = readl(reg) | 0x1;
> +	writel(val, reg);

We could at least try to pass these via syscon, since we
don't have a framework to configure NoC QoS stuff.

Thanks,
Archit

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation


From antoine.tenart at free-electrons.com  Mon Feb  8 03:00:36 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon, 8 Feb 2016 12:00:36 +0100
Subject: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <20160208105104.GA12991@leverpostej>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
 <20160208105104.GA12991@leverpostej>
Message-ID: <20160208110036.GC4117@kwain>

Hi Mark,

On Mon, Feb 08, 2016 at 10:51:05AM +0000, Mark Rutland wrote:
> 
> > +	chosen {
> > +		stdout-path = "console0:115200n8";
> > +	};
> 
> There is no console0 alias, so this cannot work.
> 
> Did you mean serial0?

Oops... Yes, I meant serial0. I'll fix this.

> [...]
> 
> > +	aliases {
> > +		serial0 = &uart0;
> > +		serial1 = &uart1;
> > +		serial2 = &uart2;
> > +		serial3 = &uart3;
> > +	};
> 
> [...]
> 
> > +	psci {
> > +		compatible = "arm,psci-0.2", "arm,psci";
> > +		method = "smc";
> > +		cpu_on = <0x84000003>;
> > +	};
> 
> If you have PSCI 0.2, the cpu_on ID (and all other mandatory function
> IDs) are implicit.
> 
> If you want to have "arm,psci" as a fallback, then please add the IDs
> for functions mandatory in PSCI 0.2 which existed in the "arm,psci"
> binding. Otherwise, drop "arm,psci" from the compatible list, along
> with the cpu_on function ID.

OK. I'll make some tests and update.

Thanks or the review!

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160208/98bcd677/attachment.sig>

From antoine.tenart at free-electrons.com  Mon Feb  8 03:01:51 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon, 8 Feb 2016 12:01:51 +0100
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <56B87450.1040500@arm.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
 <56B86391.1030609@arm.com> <20160208102656.GA4117@kwain>
 <56B86EA8.9070306@arm.com> <20160208104407.GB4117@kwain>
 <56B87450.1040500@arm.com>
Message-ID: <20160208110151.GD4117@kwain>

On Mon, Feb 08, 2016 at 10:56:16AM +0000, Marc Zyngier wrote:
> On 08/02/16 10:44, Antoine Tenart wrote:
> > On Mon, Feb 08, 2016 at 10:32:08AM +0000, Marc Zyngier wrote:
> >> On 08/02/16 10:26, Antoine Tenart wrote:
> >>>>> +static int alpine_msix_init(struct device_node *node,
> >>>>> +			    struct device_node *parent)
> >>>>> +{
> >>>>> +	struct alpine_msix_data *priv;
> >>>>> +	struct resource res;
> >>>>> +	int ret;
> >>>>> +
> >>>>> +	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> >>>>> +	if (!priv)
> >>>>> +		return -ENOMEM;
> >>>>> +
> >>>>> +	spin_lock_init(&priv->msi_map_lock);
> >>>>> +
> >>>>> +	ret = of_address_to_resource(node, 0, &res);
> >>>>> +	if (ret) {
> >>>>> +		pr_err("Failed to allocate resource\n");
> >>>>> +		goto err_priv;
> >>>>> +	}
> >>>>> +
> >>>>> +	priv->addr_high = upper_32_bits((u64)res.start);
> >>>>> +	priv->addr_low = lower_32_bits(res.start) + ALPINE_MSIX_SPI_TARGET_CLUSTER0;
> >>>>
> >>>> This is a bit odd. If you always set bit 16, why isn't that reflected in
> >>>> the base address coming from the DT?
> >>>
> >>> The 20 least significant bits of addr_low provide direct information
> >>> regarding the interrupt destination, so I thought it would be clearer
> >>> to have this explicitly in the driver so that we know what those bits
> >>> mean.
> >>
> >> So what is this information? TARGET_CLUSTER0 is not very expressive, and
> >> doesn't show what the alternatives are. Could you please elaborate a bit
> >> on that front?
> > 
> > For now lots of bits are reserved, so there aren't many alternatives.
> > Bits [18:17] are used to set the GIC to which to route the MSI and bit
> > 16 must be set when this target GIC is the primary GIC (bits [18:17] set
> > to 0x0). There aren't other options available for now (that I'm aware
> > of) for the target GIC configuration.
> 
> OK. So maybe add that as a comment, so that people know what is
> happening there. And if the code gets updated to include new
> functionalities, it will be easier to track the changes.

OK, I'll update.

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160208/6d946471/attachment-0001.sig>

From rogershimizu at gmail.com  Mon Feb  8 03:09:14 2016
From: rogershimizu at gmail.com (Roger Shimizu)
Date: Mon, 8 Feb 2016 20:09:14 +0900
Subject: [PATCH 1/3] ARM: dts: orion5x: fix the missing mtd flash on
 linkstation lswtgl
In-Reply-To: <20160205204040.GB8063@lunn.ch>
References: <1454689998-9579-1-git-send-email-rogershimizu@gmail.com>
 <1454689998-9579-2-git-send-email-rogershimizu@gmail.com>
 <20160205204040.GB8063@lunn.ch>
Message-ID: <CAEQ9gE=gjq5kOapphdyzGySaJQrh_PqT4XBL_H89TLNFhqm+yw@mail.gmail.com>

Dear Andrew,

On Sat, Feb 6, 2016 at 5:40 AM, Andrew Lunn <andrew at lunn.ch> wrote:
> On Sat, Feb 06, 2016 at 01:33:16AM +0900, Roger Shimizu wrote:
>> MTD flash stores u-boot and u-boot environment on linkstation lswtgl.
>> The latter one can be easily read/write by u-boot-tools package in Debian.
>>
>> Signed-off-by: Roger Shimizu <rogershimizu at gmail.com>
>
> Reviewed-by: Andrew Lunn <andrew at lunn.ch>
>
> Thanks for using the partitions node.

Since you did not comment my patch v2 yet, I'm wondering that
- My patch 1/3 is a fix, which fixes the issue since 4.3, so it will
be firstly applied to 4.5-rc branch as usual, and as I understand the
process then it will be backported to 4.4/4.3 stable branch.
- If it's the case described above, it's better not to use partitions
node, which was introduced since 4.4.
- By any case, my v2 patch 2/3 and 3/3, which uses partitions node, is fine.

If you agree, I can submit a v3 in minutes.
Thank you and looking forward to your feedback!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1


From kishon at ti.com  Mon Feb  8 03:12:18 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 8 Feb 2016 16:42:18 +0530
Subject: [PATCH 0/3] omap: hwmod: add default reset handling support
Message-ID: <1454929941-23949-1-git-send-email-kishon@ti.com>

Add a new hwmod flag to indicate custom reset handling and use it
for devices that require custom reset handling (like dsp, ipu, iva).

Tested PCIe on dra7-evm and dra72-evm.
I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
Or a way to test these cores to see if reset is not broken. Suman?

I'll post this series once again after performing these tests.

Paul Walmsley (3):
  ARM: omap2+: omap_hwmod: introduce hwmod flag for custom reset
    handling
  ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for custom reset
    handling
  ARM: OMAP2+: hwmod: Add default reset handling

 arch/arm/mach-omap2/omap_hwmod.c                   |   16 +++++++++++-----
 arch/arm/mach-omap2/omap_hwmod.h                   |   12 ++++++++++++
 arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
 .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
 10 files changed, 41 insertions(+), 5 deletions(-)

-- 
1.7.9.5



From kishon at ti.com  Mon Feb  8 03:12:19 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 8 Feb 2016 16:42:19 +0530
Subject: [PATCH 1/3] ARM: omap2+: omap_hwmod: introduce hwmod flag for custom
 reset handling
In-Reply-To: <1454929941-23949-1-git-send-email-kishon@ti.com>
References: <1454929941-23949-1-git-send-email-kishon@ti.com>
Message-ID: <1454929941-23949-2-git-send-email-kishon@ti.com>

From: Paul Walmsley <paul at pwsan.com>

Many of the IP blocks with PRM hardreset lines are processor IP blocks
and need special reset handling to ensure that WFI/HLT-like
instructions are executed after reset. Introduce a new hwmod flag
_HWMOD_CUSTOM_HARDRESET_ to indicate if the IP block requires
special reset handling.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.h |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 76bce11..4198829 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -525,6 +525,17 @@ struct omap_hwmod_omap4_prcm {
  *     or idled.
  * HWMOD_OPT_CLKS_NEEDED: The optional clocks are needed for the module to
  *     operate and they need to be handled at the same time as the main_clk.
+ * HWMOD_CUSTOM_HARDRESET: By default, if a hwmod has PRCM hardreset
+ *     lines associated with it (i.e., a populated .rst_lines field in
+ *     the hwmod), the hwmod code will assert the hardreset lines when
+ *     the IP block is initially reset, deassert the hardreset lines
+ *     in _enable(), and reassert them in _shutdown().  If this flag
+ *     is set, the hwmod code will not deassert the hardreset lines in
+ *     _enable(), leaving this responsibility to the driver code.  This flag may
+ *     be needed for processor IP blocks that must be put into a WFI/HLT
+ *     state after reset is deasserted, lest the processor leave its MSTANDBY
+ *     signal deasserted, thus blocking the chip from entering a system-wide
+ *     low power state.
  */
 #define HWMOD_SWSUP_SIDLE			(1 << 0)
 #define HWMOD_SWSUP_MSTANDBY			(1 << 1)
@@ -541,6 +552,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_SWSUP_SIDLE_ACT			(1 << 12)
 #define HWMOD_RECONFIG_IO_CHAIN			(1 << 13)
 #define HWMOD_OPT_CLKS_NEEDED			(1 << 14)
+#define HWMOD_CUSTOM_HARDRESET			(1 << 15)
 
 /*
  * omap_hwmod._int_flags definitions
-- 
1.7.9.5



From kishon at ti.com  Mon Feb  8 03:12:20 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 8 Feb 2016 16:42:20 +0530
Subject: [RFT PATCH 2/3] ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for
 custom reset handling
In-Reply-To: <1454929941-23949-1-git-send-email-kishon@ti.com>
References: <1454929941-23949-1-git-send-email-kishon@ti.com>
Message-ID: <1454929941-23949-3-git-send-email-kishon@ti.com>

From: Paul Walmsley <paul at pwsan.com>

Many of the IP blocks with PRM hardreset lines are processor IP blocks
and need special reset handling to ensure that WFI/HLT-like
instructions are executed after reset. (This special handling ensures that
the IP blocks' bus initiator interfaces indicate that they are in standby
to the PRCM - thus allowing power management for the rest of the chip to
work correctly.)
Use HWMOD_CUSTOM_HARDRESET flags in the hwmod data for IP blocks that
require special reset handling.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
 .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
 8 files changed, 18 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 65b1647..2a7e5da 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -59,6 +59,7 @@ static struct omap_hwmod omap2420_iva_hwmod = {
 	.clkdm_name	= "iva1_clkdm",
 	.rst_lines	= omap2420_iva_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap2420_iva_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "iva1_ifck",
 };
 
@@ -78,6 +79,7 @@ static struct omap_hwmod omap2420_dsp_hwmod = {
 	.clkdm_name	= "dsp_clkdm",
 	.rst_lines	= omap2420_dsp_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap2420_dsp_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "dsp_fck",
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 79127b3..7ec77ff 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -55,6 +55,7 @@ static struct omap_hwmod omap2430_iva_hwmod = {
 	.clkdm_name	= "dsp_clkdm",
 	.rst_lines	= omap2430_iva_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap2430_iva_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "dsp_fck",
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index 907a452b..d8b701a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -161,6 +161,7 @@ struct omap_hwmod am33xx_pruss_hwmod = {
 	},
 	.rst_lines	= am33xx_pruss_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(am33xx_pruss_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 };
 
 /* gfx */
@@ -185,6 +186,7 @@ struct omap_hwmod am33xx_gfx_hwmod = {
 	},
 	.rst_lines	= am33xx_gfx_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(am33xx_gfx_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 };
 
 /*
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index cc0791d..f843af6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -86,6 +86,7 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
 	},
 	.rst_lines	= am33xx_wkup_m3_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(am33xx_wkup_m3_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 };
 
 /*
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0a98532..544c53d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -120,6 +120,7 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
 	.clkdm_name	= "iva2_clkdm",
 	.rst_lines	= omap3xxx_iva_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap3xxx_iva_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "iva2_ck",
 	.prcm = {
 		.omap2 = {
@@ -2071,6 +2072,7 @@ static struct omap_hwmod omap3xxx_sad2d_hwmod = {
 	.name		= "sad2d",
 	.rst_lines	= omap3xxx_sad2d_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap3xxx_sad2d_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "sad2d_ick",
 	.prcm		= {
 		.omap2 = {
@@ -2993,6 +2995,7 @@ static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
 	.clkdm_name	= "iva2_clkdm",
 	.rst_lines	= omap3xxx_mmu_iva_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap3xxx_mmu_iva_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "iva2_ck",
 	.prcm = {
 		.omap2 = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index e97a894..72346f0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -73,6 +73,7 @@ static struct omap_hwmod am43xx_wkup_m3_hwmod = {
 	},
 	.rst_lines	= am33xx_wkup_m3_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(am33xx_wkup_m3_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 };
 
 static struct omap_hwmod am43xx_control_hwmod = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index dad871a..b38aad9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -544,6 +544,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
 	.clkdm_name	= "tesla_clkdm",
 	.rst_lines	= omap44xx_dsp_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_dsp_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "dpll_iva_m4x2_ck",
 	.prcm = {
 		.omap4 = {
@@ -1424,6 +1425,7 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
 	.clkdm_name	= "ducati_clkdm",
 	.rst_lines	= omap44xx_ipu_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_ipu_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "ducati_clk_mux_ck",
 	.prcm = {
 		.omap4 = {
@@ -1508,6 +1510,7 @@ static struct omap_hwmod omap44xx_iva_hwmod = {
 	.clkdm_name	= "ivahd_clkdm",
 	.rst_lines	= omap44xx_iva_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_iva_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "dpll_iva_m5x2_ck",
 	.prcm = {
 		.omap4 = {
@@ -2106,6 +2109,7 @@ static struct omap_hwmod omap44xx_mmu_ipu_hwmod = {
 	.clkdm_name	= "ducati_clkdm",
 	.rst_lines	= omap44xx_mmu_ipu_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_mmu_ipu_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "ducati_clk_mux_ck",
 	.prcm = {
 		.omap4 = {
@@ -2138,6 +2142,7 @@ static struct omap_hwmod omap44xx_mmu_dsp_hwmod = {
 	.clkdm_name	= "tesla_clkdm",
 	.rst_lines	= omap44xx_mmu_dsp_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_mmu_dsp_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "dpll_iva_m4x2_ck",
 	.prcm = {
 		.omap4 = {
@@ -2299,6 +2304,7 @@ static struct omap_hwmod omap44xx_prm_hwmod = {
 	.class		= &omap44xx_prcm_hwmod_class,
 	.rst_lines	= omap44xx_prm_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_prm_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 };
 
 /*
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 8cdfd9b..b1d5433 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1388,6 +1388,7 @@ static struct omap_hwmod omap54xx_mmu_dsp_hwmod = {
 	.clkdm_name	= "dsp_clkdm",
 	.rst_lines	= omap54xx_mmu_dsp_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap54xx_mmu_dsp_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "dpll_iva_h11x2_ck",
 	.prcm = {
 		.omap4 = {
@@ -1410,6 +1411,7 @@ static struct omap_hwmod omap54xx_mmu_ipu_hwmod = {
 	.clkdm_name	= "ipu_clkdm",
 	.rst_lines	= omap54xx_mmu_ipu_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap54xx_mmu_ipu_resets),
+	.flags		= HWMOD_CUSTOM_HARDRESET,
 	.main_clk	= "dpll_core_h22x2_ck",
 	.prcm = {
 		.omap4 = {
-- 
1.7.9.5



From kishon at ti.com  Mon Feb  8 03:12:21 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 8 Feb 2016 16:42:21 +0530
Subject: [PATCH 3/3] ARM: OMAP2+: hwmod: Add default reset handling
In-Reply-To: <1454929941-23949-1-git-send-email-kishon@ti.com>
References: <1454929941-23949-1-git-send-email-kishon@ti.com>
Message-ID: <1454929941-23949-4-git-send-email-kishon@ti.com>

From: Paul Walmsley <paul at pwsan.com>

Certain devices (like PCIe in DRA7xx) require default reset
handling where the reset line should be asserted and then
de-asserted. Other devices require special reset handling
and is indicated using HWMOD_CUSTOM_HARDRESET.
Add default reset handling here where the reset line is
asserted in _reset and deasserted in _enable.

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e9f65fe..ab66dd9 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2077,7 +2077,7 @@ static int _enable_preprogram(struct omap_hwmod *oh)
  */
 static int _enable(struct omap_hwmod *oh)
 {
-	int r;
+	int r, i;
 	int hwsup = 0;
 
 	pr_debug("omap_hwmod: %s: enabling\n", oh->name);
@@ -2109,17 +2109,23 @@ static int _enable(struct omap_hwmod *oh)
 	}
 
 	/*
-	 * If an IP block contains HW reset lines and all of them are
-	 * asserted, we let integration code associated with that
-	 * block handle the enable.  We've received very little
+	 * If an IP block contains HW reset lines, all of them are
+	 * asserted, and the IP block is marked as requiring a custom
+	 * hardreset handler, we let integration code associated with
+	 * that block handle the enable.  We've received very little
 	 * information on what those driver authors need, and until
 	 * detailed information is provided and the driver code is
 	 * posted to the public lists, this is probably the best we
 	 * can do.
 	 */
-	if (_are_all_hardreset_lines_asserted(oh))
+	if ((oh->flags & HWMOD_CUSTOM_HARDRESET) &&
+	    _are_all_hardreset_lines_asserted(oh))
 		return 0;
 
+	/* If the IP block is an initiator, release it from hardreset */
+	for (i = 0; i < oh->rst_lines_cnt; i++)
+		_deassert_hardreset(oh, oh->rst_lines[i].name);
+
 	/* Mux pins for device runtime if populated */
 	if (oh->mux && (!oh->mux->enabled ||
 			((oh->_state == _HWMOD_STATE_IDLE) &&
-- 
1.7.9.5



From kernel at martin.sperl.org  Mon Feb  8 03:12:44 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Mon, 8 Feb 2016 12:12:44 +0100
Subject: [PATCH V4 5/7] clk: bcm2835: add missing 22 HW-clocks.
In-Reply-To: <87h9hr517u.fsf@eliezer.anholt.net>
References: <1452867667-2447-1-git-send-email-kernel@martin.sperl.org>
 <1452867667-2447-6-git-send-email-kernel@martin.sperl.org>
 <87h9hr517u.fsf@eliezer.anholt.net>
Message-ID: <56B8782C.4060107@martin.sperl.org>



On 02.02.2016 02:51, Eric Anholt wrote:
> kernel at martin.sperl.org writes:
>
>> From: Martin Sperl <kernel at martin.sperl.org>
>>
>> There were 22 HW clocks missing from the clock driver.
>>
>> These have been included and int_bits and frac_bits
>> have been set correctly based on information extracted
>> from the broadcom videocore headers
>> (http://www.broadcom.com/docs/support/videocore/Brcm_Android_ICS_Graphics_Stack.tar.gz)
>>
>> For an extracted view of the registers please see:
>> https://github.com/msperl/rpi-registers/blob/master/md/Region_CM.md
>>
>> bcm2835_clock_per_parents has been assigned as the parent
>> clock for all new clocks, but this may not be correct
>> in all cases - documentation on this is not publicly
>> available, so some modifications may be needed in the
>> future.
>
> We need the parents to be correct if we're going to land the patch.
> I'll try to update them.
>
> I'm not a fan of this "let's just shove everything we can find in some
> header file into the .c and hope for the best."  Most of these clocks
> were left out intentionally.

Well - I wanted to get them in just in case we need them later.

If you have got access to documentation which states the correct
parent mux, then please share them so that we can implement them
correctly.

Also listing all allows us then to expose the values of the registers
via debugfs in case we need it - see separate RFC-patch 9 -  where
we expose the raw register values as well.

>> +static const struct bcm2835_clock_data bcm2835_clock_aveo_data = {
>> +	.name = "aveo",
>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>> +	.parents = bcm2835_clock_per_parents,
>> +	.ctl_reg = CM_AVEOCTL,
>> +	.div_reg = CM_AVEODIV,
>> +	.int_bits = 4,
>> +	.frac_bits = 12,
>> +};
>
> AVEO has 0 fractional bits

Correct - my issue (copy paste - I assume).

>
>> +static const struct bcm2835_clock_data bcm2835_clock_ccp2_data = {
>> +	/* this is possibly a gate */
>> +	.name = "ccp2",
>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>> +	.parents = bcm2835_clock_per_parents,
>> +	.ctl_reg = CM_CCP2CTL,
>> +	.div_reg = CM_CCP2DIV,
>> +	.int_bits = 1,
>> +	.frac_bits = 0,
>> +};
>
> CCP2 is a gate from a different clock source, so this won't work.
See comment above: please provide parent clock mux.
See also my comment about 3 clock that may be gates - this applies.

>
>> +static const struct bcm2835_clock_data bcm2835_clock_dsi0p_data = {
>> +	/* this is possibly a gate */
>> +	.name = "dsi0p",
>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>> +	.parents = bcm2835_clock_per_parents,
>> +	.ctl_reg = CM_DSI0PCTL,
>> +	.div_reg = CM_DSI0PDIV,
>> +	.int_bits = 1,
>> +	.frac_bits = 0,
>> +};
>> +
>> +static const struct bcm2835_clock_data bcm2835_clock_dsi1p_data = {
>> +	/* this is possibly a gate */
>> +	.name = "dsi1p",
>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>> +	.parents = bcm2835_clock_per_parents,
>> +	.ctl_reg = CM_DSI1PCTL,
>> +	.div_reg = CM_DSI1PDIV,
>> +	.int_bits = 1,
>> +	.frac_bits = 0,
>> +};
>
> DSI0/1 pixel clocks take different clock sources and are gates off of
> them, so these definitions don't work.
See comment above: please provide parent clock.
See also my comment about 3 clock that may be gates.

>
>> +
>> +static const struct bcm2835_clock_data bcm2835_clock_gnric_data = {
>> +	.name = "gnric",
>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>> +	.parents = bcm2835_clock_per_parents,
>> +	.ctl_reg = CM_GNRICCTL,
>> +	.div_reg = CM_GNRICDIV,
>> +	.int_bits = 12,
>> +	.frac_bits = 12,
>> +};
>
> GNRIC isn't an actual clock, it's just what's used for describing the
> overall structure of clocks.

Well - there is the corresponding register at 0x7e101000 which reads as:
ctl = 0x0000636d
div = 0x0000636d

So we could remove this one if this is really the case of a dummy -
even though I wonder why there would be space in io-space reserved for
this "description" only.

>
>> +static const struct bcm2835_clock_data bcm2835_clock_peria_data = {
>> +	.name = "peria",
>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>> +	.parents = bcm2835_clock_per_parents,
>> +	.ctl_reg = CM_PERIACTL,
>> +	.div_reg = CM_PERIADIV,
>> +	.int_bits = 12,
>> +	.frac_bits = 12,
>> +};
>
> This register doesn't do anything, because the debug bit in the power
> manager is not set.  We don't think we should expose a clock gate if it
> doesn't work, I think.
maybe we allow setting debug in the PM at a later point in time?

>
>> +static const struct bcm2835_clock_data bcm2835_clock_pulse_data = {
>> +	.name = "pulse",
>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>> +	.parents = bcm2835_clock_per_parents,
>> +	.ctl_reg = CM_PULSECTL,
>> +	.div_reg = CM_PULSEDIV,
>> +	.int_bits = 12,
>> +	.frac_bits = 0,
>> +};
>
> There's some other divider involved in this clock, won't give correct results.
See comment above: please provide parent clock.

>
>> +static const struct bcm2835_clock_data bcm2835_clock_td0_data = {
>> +	.name = "td0",
>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>> +	.parents = bcm2835_clock_per_parents,
>> +	.ctl_reg = CM_TD0CTL,
>> +	.div_reg = CM_TD0DIV,
>> +	.int_bits = 12,
>> +	.frac_bits = 12,
>> +};
>> +
>> +static const struct bcm2835_clock_data bcm2835_clock_td1_data = {
>> +	.name = "td1",
>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>> +	.parents = bcm2835_clock_per_parents,
>> +	.ctl_reg = CM_TD1CTL,
>> +	.div_reg = CM_TD1DIV,
>> +	.int_bits = 12,
>> +	.frac_bits = 12,
>> +};
>
> These are some other clock generator, not the generic or mash ones used
> elsewhere.  I wouldn't enable them without testing.

As long as they are not referenced in the DT these only are read only
and can get read via debugfs - these are disabled anyway:

root at raspcm:/build/linux# head /sys/kernel/debug/clk/td*/clk_rate
==> /sys/kernel/debug/clk/td0/clk_rate <==
0

==> /sys/kernel/debug/clk/td1/clk_rate <==
0

>
>> +static const struct bcm2835_clock_data bcm2835_clock_tec_data = {
>> +	.name = "tec",
>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>> +	.parents = bcm2835_clock_per_parents,
>> +	.ctl_reg = CM_TECCTL,
>> +	.div_reg = CM_TECDIV,
>> +	.int_bits = 6,
>> +	.frac_bits = 0,
>> +};
>
> TEC should be osc parents.
I will change that.

>
>> -/*
>> - * CM_PERIICTL (and CM_PERIACTL, CM_SYSCTL and CM_VPUCTL if
>> - * you have the debug bit set in the power manager, which we
>> - * don't bother exposing) are individual gates off of the
>> - * non-stop vpu clock.
>> - */
>>   static const struct bcm2835_gate_data bcm2835_clock_peri_image_data = {
>>   	.name = "peri_image",
>>   	.parent = "vpu",
>>   	.ctl_reg = CM_PERIICTL,
>>   };
>>
>> +static const struct bcm2835_gate_data bcm2835_clock_sys_data = {
>> +	.name = "sys",
>> +	.parent = "vpu",
>> +	.ctl_reg = CM_SYSCTL,
>> +};
>
> same concern as peria.
maybe we allow setting debug in the PM at a later point in time?

Please propose how to continue to get the clocks in.

If you want some clocks left out, then that is fine and we
can accommodate that and just leave the defines in the bindings
header for later use...

Just list them.

Martin


From vladimir.murzin at arm.com  Mon Feb  8 03:16:56 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Mon, 08 Feb 2016 11:16:56 +0000
Subject: [PATCH v2 04/10] serial: mps2-uart: add MPS2 UART driver
In-Reply-To: <20160207071154.GA32017@kroah.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
 <1454413199-26573-5-git-send-email-vladimir.murzin@arm.com>
 <20160207071154.GA32017@kroah.com>
Message-ID: <56B87928.7020803@arm.com>

On 07/02/16 07:11, Greg KH wrote:
>> +
>> +#define SERIAL_NAME "ttyS"
> 
> You can't be "ttyS", there's already a serial port named that, please
> use a unique name and a new major/minor number (dynamic ideally).
> 

Hi Greg,

I did s/ttyMPS/ttyS per your request for v1 [1]. I'm fine to change it
back if you prefer that, but I'd be glad to know what I've been missing?

[1] https://lkml.org/lkml/2015/12/13/8

Thanks
Vladimir

> thanks,
> 
> greg k-h
> 
> 



From mark.rutland at arm.com  Mon Feb  8 03:18:29 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 8 Feb 2016 11:18:29 +0000
Subject: [PATCH v2 4/4] iommu/arm-smmu: Add stub of_xlate() operation in
 SMMUv1/SMMUv2 driver
In-Reply-To: <1454908652-15317-5-git-send-email-anup.patel@broadcom.com>
References: <1454908652-15317-1-git-send-email-anup.patel@broadcom.com>
 <1454908652-15317-5-git-send-email-anup.patel@broadcom.com>
Message-ID: <20160208111829.GA13498@leverpostej>

On Mon, Feb 08, 2016 at 10:47:32AM +0530, Anup Patel wrote:
> To allow use of large memory (> 4Gb) with 32bit devices we need to use
> IOMMU based DMA mappings for such 32bit devices. The IOMMU dt-bindings
> allows us do this by specifying 'iommus' attribute in 32bit device DT
> node. Unfortunately, specifying 'iommus' attribute does not work with
> current SMMUv1/SMMUv2 driver because it requires of_xlate() operation
> to be implemented by the driver.
> 
> This patch adds a stub implementation of of_xlate() in SMMUv1/SMMUv2
> driver to allow usage of 'iommus' attribute in DT for 32bit devices.
> 
> Signed-off-by: Anup Patel <anup.patel at broadcom.com>
> Reviewed-by: Ray Jui <rjui at broadcom.com>
> Reviewed-by: Scott Branden <sbranden at broadcom.com>
> ---
>  drivers/iommu/arm-smmu.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 02cd67d..8e090d8 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1398,6 +1398,16 @@ static int arm_smmu_init_platform_device(struct device *dev,
>  	return 0;
>  }
>  
> +int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> +{
> +	/*
> +	 * Nothing to do here because SMMU is already aware of all
> +	 * MMU masters and their stream IDs using mmu-master attibute
> +	 * SMMU DT node.
> +	 */
> +	return 0;
> +}

NAK to this.

As previously mentioned by others [1], this is an abuse of the generic
iommu binding support code.

The SMMU binding currently does not define its implementation of the
generic IOMMU binding. This series did not define what an SMMU's
#iommu-cells would be nor what the contained values would represent.
Therefore it is not valid to use an SMMU node with an iommus property as
the SMMu doesn't follwo the generic IOMMU binding.

There is ongoing work to have generic iommu binding support for the
SMMU. In the absence of documentation for what this means for the
binding, I am worried that this hack harms that effort.

To use features of the generic IOMMU binding, we must properly implement
the generic IOMMU binding for the SMMU rather than bodging it onto the
side of the existing binding.

Thanks,
Mark.

> +
>  static int arm_smmu_add_device(struct device *dev)
>  {
>  	struct iommu_group *group;
> @@ -1495,6 +1505,7 @@ static struct iommu_ops arm_smmu_ops = {
>  	.unmap			= arm_smmu_unmap,
>  	.map_sg			= default_iommu_map_sg,
>  	.iova_to_phys		= arm_smmu_iova_to_phys,
> +	.of_xlate		= arm_smmu_of_xlate,
>  	.add_device		= arm_smmu_add_device,
>  	.remove_device		= arm_smmu_remove_device,
>  	.device_group		= arm_smmu_device_group,
> -- 
> 1.9.1
> 

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/402976.html


From jayachandran.chandrashekaran at broadcom.com  Mon Feb  8 03:27:46 2016
From: jayachandran.chandrashekaran at broadcom.com (Jayachandran Chandrashekaran Nair)
Date: Mon, 8 Feb 2016 16:57:46 +0530
Subject: [PATCH v7 5/5] PCI: ACPI: Add a generic ACPI based host controller
In-Reply-To: <20160205094740.GA31547@red-moon>
References: <1454058340-7904-1-git-send-email-jchandra@broadcom.com>
 <1454058340-7904-6-git-send-email-jchandra@broadcom.com>
 <20160205001907.GJ7031@localhost>
 <CAKc_7PXYtFt1MQE-UGO0O5vvQ+xFKa2b5=F8wXB=EN-JUJVzZw@mail.gmail.com>
 <20160205094740.GA31547@red-moon>
Message-ID: <CAKc_7PVNm7z8nv_+Tr9FYhrVAA+-vh4CDMB83WAyT8tdi+CHzA@mail.gmail.com>

Lorenzo,

On Fri, Feb 5, 2016 at 3:17 PM, Lorenzo Pieralisi
<lorenzo.pieralisi at arm.com> wrote:
> On Fri, Feb 05, 2016 at 02:05:37PM +0530, Jayachandran Chandrashekaran Nair wrote:
>
> [...]
>
>> pci_host_acpi.c is a generic implementation of these using a sysdata
>> pointing to acpi_pci_root_info, and using a pointer to the pci_mmcfg_region
>> to access ECAM area, Maybe I can rename this file to
>> pci_acpi_host_generic.c to reflect this better.
>
> Maybe you should stop sending this series and work with Tomasz to
> get this done, you are confusing everyone and I am really really
> annoyed about this.
>
> Do you realize there is no point in having two patch series doing
> the same thing and wasting everyone's review time ?
>
> Do you realize he started this work long before you and went through
> several rounds of review already (I told you before but in case you
> forgot) ?
>
> Tomasz posted a version yesterday, integrating comments following months
> of review and testing and I think it is ready to get upstream:
>
> https://lkml.org/lkml/2016/2/4/646
>
> Did you even consider reviewing his code or helping him instead of
> churning out more patches doing the *SAME* thing ?

This is getting ridiculous, I had replied to your earlier mails on why
my patchset is NOT doing the exact same thing. I had also explained
why helping was not feasible.

The basic point again: I am trying to give a much simpler patchset
to solve the same problem, I take it that you haven't reviewed my
patchset before writing this mail. I would have appreciated
a technical discussion rather than this pointless flamefest.

If you have reviewed it, you can see that there are just 5 patches
instead of 23, and that overall it is a much simpler approach.

> Do you want all of us to go through your code and re-fix what has
> already been fixed in Tomasz's series with the end result of missing
> yet another merge window ?

Again, as I said, the whole point of my patchset is that is much  easier
to go thru and validate and merge or drop as needed.

Anyway, if you are on target to hit this merge window, I really hope
that happens and there will no need for me to spend further time on
this.

Regards,
JC.


From stefano.stabellini at eu.citrix.com  Mon Feb  8 03:31:23 2016
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 8 Feb 2016 11:31:23 +0000
Subject: [PATCH v4 13/17] ARM: Xen: Document UEFI support on Xen ARM
 virtual platforms
In-Reply-To: <1454641552-12576-14-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
 <1454641552-12576-14-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <alpine.DEB.2.02.1602081130480.27008@kaball.uk.xensource.com>

On Fri, 5 Feb 2016, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
> 
> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
> scan this to get the UEFI information.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> Acked-by: Rob Herring <robh at kernel.org>

Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>


> CC: Rob Herring <robh at kernel.org>
> ---
>  Documentation/devicetree/bindings/arm/xen.txt | 33 +++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
> index 0f7b9c2..6f83f76 100644
> --- a/Documentation/devicetree/bindings/arm/xen.txt
> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> @@ -15,6 +15,26 @@ the following properties:
>  - interrupts: the interrupt used by Xen to inject event notifications.
>    A GIC node is also required.
>  
> +To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
> +under /hypervisor with following parameters:
> +
> +________________________________________________________________________________
> +Name                      | Size   | Description
> +================================================================================
> +xen,uefi-system-table     | 64-bit | Guest physical address of the UEFI System
> +			  |	   | Table.
> +--------------------------------------------------------------------------------
> +xen,uefi-mmap-start       | 64-bit | Guest physical address of the UEFI memory
> +			  |	   | map.
> +--------------------------------------------------------------------------------
> +xen,uefi-mmap-size        | 32-bit | Size in bytes of the UEFI memory map
> +                          |        | pointed to in previous entry.
> +--------------------------------------------------------------------------------
> +xen,uefi-mmap-desc-size   | 32-bit | Size in bytes of each entry in the UEFI
> +                          |        | memory map.
> +--------------------------------------------------------------------------------
> +xen,uefi-mmap-desc-ver    | 32-bit | Version of the mmap descriptor format.
> +--------------------------------------------------------------------------------
>  
>  Example (assuming #address-cells = <2> and #size-cells = <2>):
>  
> @@ -22,4 +42,17 @@ hypervisor {
>  	compatible = "xen,xen-4.3", "xen,xen";
>  	reg = <0 0xb0000000 0 0x20000>;
>  	interrupts = <1 15 0xf08>;
> +	uefi {
> +		xen,uefi-system-table = <0xXXXXXXXX>;
> +		xen,uefi-mmap-start = <0xXXXXXXXX>;
> +		xen,uefi-mmap-size = <0xXXXXXXXX>;
> +		xen,uefi-mmap-desc-size = <0xXXXXXXXX>;
> +		xen,uefi-mmap-desc-ver = <0xXXXXXXXX>;
> +        };
>  };
> +
> +The format and meaning of the "xen,uefi-*" parameters are similar to those in
> +Documentation/arm/uefi.txt, which are provided by the regular UEFI stub. However
> +they differ because they are provided by the Xen hypervisor, together with a set
> +of UEFI runtime services implemented via hypercalls, see
> +http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.


From bp at alien8.de  Mon Feb  8 03:39:19 2016
From: bp at alien8.de (Borislav Petkov)
Date: Mon, 8 Feb 2016 12:39:19 +0100
Subject: [PATCHv9 1/4] EDAC, altera: Add Altera L2 Cache and OCRAM EDAC
 Support
In-Reply-To: <1453911203-30202-1-git-send-email-tthayer@opensource.altera.com>
References: <1453911203-30202-1-git-send-email-tthayer@opensource.altera.com>
Message-ID: <20160208113919.GB28980@pd.tnic>

On Wed, Jan 27, 2016 at 10:13:20AM -0600, tthayer at opensource.altera.com wrote:
> From: Thor Thayer <tthayer at opensource.altera.com>
> 
> Adding L2 Cache and On-Chip RAM EDAC support for the
> Altera SoCs using the EDAC device  model. The SDRAM
> controller is using the Memory Controller model.
> 
> Each type of ECC is individually configurable.
> 
> Signed-off-by: Thor Thayer <tthayer at opensource.altera.com>
> ---
> v9: Improve device tree node release. Free managed resources
>     on error path. Fix ocram memory leak.
> v8: Remove MASK from single bit mask names.
>     s/altr,edac/altr,socfpga-ecc-manager
>     Use debugfs instead of sysfs.
>     Add chip family name to match string.
>     Fix header year.
>     Fix build dependencies & change commit accordingly.
>     s/CONFIG_EDAC_ALTERA_MC/CONFIG_EDAC_ALTERA
> v7: s/of_get_named_gen_pool/of_gen_pool_get
>     Remove #ifdef for EDAC_DEBUG
>     Use -ENODEV instead of EPROBE_DEFER
> v6: Convert to nested EDAC in device tree. Force L2 cache
>     on for L2Cache ECC & remove L2 cache syscon for checking
>     enable bit. Update year in header.
> v5: No change.
> v4: Change mask defines to use BIT().
>     Fix comment style to agree with kernel coding style.
>     Better printk description for read != write in trigger.
>     Remove SysFS debugging message.
>     Better dci->mod_name
>     Move gen_pool pointer assignment to end of function.
>     Invert logic to reduce indent in ocram depenency check.
>     Change from dev_err() to edac_printk()
>     Replace magic numbers with defines & comments.
>     Improve error injection test.
>     Change Makefile intermediary name to altr (from alt)
> v3: Move OCRAM and L2 cache EDAC functions into altera_edac.c
>     instead of separate files.
> v2: Fix L2 dependency comments.
> ---
>  drivers/edac/Kconfig       |   26 ++-
>  drivers/edac/Makefile      |    2 +-
>  drivers/edac/altera_edac.c |  487 +++++++++++++++++++++++++++++++++++++++++++-
>  3 files changed, 507 insertions(+), 8 deletions(-)

I'm still waiting for the people on CC to confirm the DT changes. A
couple of comments on the EDAC bits below.


....


> +static irqreturn_t altr_edac_device_handler(int irq, void *dev_id)
> +{
> +	struct edac_device_ctl_info *dci = dev_id;
> +	struct altr_edac_device_dev *drvdata = dci->pvt_info;
> +	const struct edac_device_prv_data *priv = drvdata->data;
> +
> +	if (irq == drvdata->sb_irq) {
> +		if (priv->ce_clear_mask)
> +			writel(priv->ce_clear_mask, drvdata->base);
> +		edac_device_handle_ce(dci, 0, 0, drvdata->edac_dev_name);
> +	}
> +	if (irq == drvdata->db_irq) {
> +		if (priv->ue_clear_mask)
> +			writel(priv->ue_clear_mask, drvdata->base);
> +		edac_device_handle_ue(dci, 0, 0, drvdata->edac_dev_name);
> +		panic("\nEDAC:ECC_DEVICE[Uncorrectable errors]\n");
> +	}

And irq is guaranteed to always be ->sb_irq or ->db_irq?

Otherwise, you can do

	else
		WARN_ON(1);

just in case.

> +
> +	return IRQ_HANDLED;
> +}

...

> +/*
> + * altr_edac_device_probe()
> + *	This is a generic EDAC device driver that will support
> + *	various Altera memory devices such as the L2 cache ECC and
> + *	OCRAM ECC as well as the memories for other peripherals.
> + *	Module specific initialization is done by passing the
> + *	function index in the device tree.
> + */
> +static int altr_edac_device_probe(struct platform_device *pdev)
> +{
> +	struct edac_device_ctl_info *dci;
> +	struct altr_edac_device_dev *drvdata;
> +	struct resource *r;
> +	int res = 0;
> +	struct device_node *np = pdev->dev.of_node;
> +	char *ecc_name = (char *)np->name;
> +	static int dev_instance;
> +	struct dentry *debugfs;
> +
> +	if (!devres_open_group(&pdev->dev, NULL, GFP_KERNEL)) {
> +		edac_printk(KERN_ERR, EDAC_DEVICE,
> +			    "Unable to open devm\n");
> +		return -ENOMEM;
> +	}
> +
> +	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!r) {
> +		edac_printk(KERN_ERR, EDAC_DEVICE,
> +			    "Unable to get mem resource\n");
> +		res = -ENODEV;
> +		goto fail;
> +	}
> +
> +	if (!devm_request_mem_region(&pdev->dev, r->start, resource_size(r),
> +				     dev_name(&pdev->dev))) {
> +		edac_printk(KERN_ERR, EDAC_DEVICE,
> +			    "%s:Error requesting mem region\n", ecc_name);
> +		res = -EBUSY;
> +		goto fail;
> +	}
> +
> +	dci = edac_device_alloc_ctl_info(sizeof(*drvdata), ecc_name,
> +					 1, ecc_name, 1, 0, NULL, 0,
> +					 dev_instance++);
> +
> +	if (!dci) {
> +		edac_printk(KERN_ERR, EDAC_DEVICE,
> +			    "%s: Unable to allocate EDAC device\n", ecc_name);
> +		res = -ENOMEM;
> +		goto fail;
> +	}
> +
> +	drvdata = dci->pvt_info;
> +	dci->dev = &pdev->dev;
> +	platform_set_drvdata(pdev, dci);
> +	drvdata->edac_dev_name = ecc_name;
> +
> +	drvdata->base = devm_ioremap(&pdev->dev, r->start, resource_size(r));
> +	if (!drvdata->base)
> +		goto fail1;
> +
> +	/* Get driver specific data for this EDAC device */
> +	drvdata->data = of_match_node(altr_edac_device_of_match, np)->data;
> +
> +	/* Check specific dependencies for the module */
> +	if (drvdata->data->setup) {
> +		res = drvdata->data->setup(pdev, drvdata->base);
> +		if (res < 0)
> +			goto fail1;
> +	}
> +
> +	drvdata->sb_irq = platform_get_irq(pdev, 0);
> +	res = devm_request_irq(&pdev->dev, drvdata->sb_irq,
> +			       altr_edac_device_handler,
> +			       0, dev_name(&pdev->dev), dci);
> +	if (res < 0)
> +		goto fail1;
> +
> +	drvdata->db_irq = platform_get_irq(pdev, 1);
> +	res = devm_request_irq(&pdev->dev, drvdata->db_irq,
> +			       altr_edac_device_handler,
> +			       0, dev_name(&pdev->dev), dci);
> +	if (res < 0)
> +		goto fail1;
> +
> +	dci->mod_name = "Altera ECC Manager";
> +	dci->dev_name = drvdata->edac_dev_name;
> +
> +	debugfs = edac_debugfs_create_dir(ecc_name);
> +	if (debugfs)
> +		altr_create_edacdev_dbgfs(dci, drvdata->data, debugfs);
> +
> +	if (edac_device_add_device(dci))

<--- if you end up here and debugfs nodes have been created, you need to
destroy them here. You probably could change edac_debugfs_exit() to call
debugfs_remove_recursive() and make sure your driver calls it.

Right now we're calling edac_debugfs_exit() in edac_exit() and I *think*
that is ok for a platform device driver as this one but I haven't
actually *verified* that.

> +		goto fail1;
> +
> +	devres_close_group(&pdev->dev, NULL);
> +
> +	return 0;
> +
> +fail1:
> +	edac_device_free_ctl_info(dci);
> +fail:
> +	devres_release_group(&pdev->dev, NULL);
> +	edac_printk(KERN_ERR, EDAC_DEVICE,
> +		    "%s:Error setting up EDAC device: %d\n", ecc_name, res);
> +
> +	return res;
> +}
> +
> +static int altr_edac_device_remove(struct platform_device *pdev)
> +{
> +	struct edac_device_ctl_info *dci = platform_get_drvdata(pdev);
> +
> +	edac_device_del_device(&pdev->dev);
> +	edac_device_free_ctl_info(dci);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver altr_edac_device_driver = {
> +	.probe =  altr_edac_device_probe,
> +	.remove = altr_edac_device_remove,
> +	.driver = {
> +		.name = "altr_edac_device",
> +		.of_match_table = altr_edac_device_of_match,
> +	},
> +};
> +module_platform_driver(altr_edac_device_driver);
> +
> +/*********************** OCRAM EDAC Device Functions *********************/
> +
> +#ifdef CONFIG_EDAC_ALTERA_OCRAM
> +
> +static void *ocram_alloc_mem(size_t size, void **other)
> +{
> +	struct device_node *np;
> +	struct gen_pool *gp;
> +	void *sram_addr;
> +
> +	np = of_find_compatible_node(NULL, NULL, "altr,socfpga-ocram-ecc");
> +	if (!np)
> +		return NULL;
> +
> +	gp = of_gen_pool_get(np, "iram", 0);
> +	of_node_put(np);
> +	if (!gp)
> +		return NULL;
> +
> +	sram_addr = (void *)gen_pool_alloc(gp, size);
> +	if (!sram_addr)
> +		return NULL;
> +
> +	memset(sram_addr, 0, size);
> +	wmb();	/* Ensure data is written out */
> +
> +	*other = gp;	/* Remember this handle for freeing  later */

Please put comments ontop of the line they're referring to. Those
side-things are cluttering the code unnecessarily.

> +
> +	return sram_addr;
> +}
> +
> +static void ocram_free_mem(void *p, size_t size, void *other)
> +{
> +	gen_pool_free((struct gen_pool *)other, (u32)p, size);
> +}
> +
> +/*
> + * altr_ocram_dependencies()
> + *	Test for OCRAM cache ECC dependencies upon entry because
> + *	platform specific startup should have initialized the
> + *	On-Chip RAM memory and enabled the ECC.
> + *	Can't turn on ECC here because accessing un-initialized
> + *	memory will cause CE/UE errors possibly causing an ABORT.
> + */
> +static int altr_ocram_dependencies(struct platform_device *pdev,

A verb in the name?

	altr_ocram_test_deps

or
	altr_ocram_check_deps

or so?

> +				   void __iomem *base)
> +{
> +	u32 control;
> +
> +	control = readl(base) & ALTR_OCR_ECC_EN;
> +	if (control)
> +		return 0;
> +
> +	edac_printk(KERN_ERR, EDAC_DEVICE,
> +		    "OCRAM: No ECC present or ECC disabled.\n");
> +	return -ENODEV;
> +}
> +
> +const struct edac_device_prv_data ocramecc_data = {
> +	.setup = altr_ocram_dependencies,
> +	.ce_clear_mask = (ALTR_OCR_ECC_EN | ALTR_OCR_ECC_SERR),
> +	.ue_clear_mask = (ALTR_OCR_ECC_EN | ALTR_OCR_ECC_DERR),
> +	.dbgfs_name = "altr_ocram_trigger",
> +	.alloc_mem = ocram_alloc_mem,
> +	.free_mem = ocram_free_mem,
> +	.ecc_enable_mask = ALTR_OCR_ECC_EN,
> +	.ce_set_mask = (ALTR_OCR_ECC_EN | ALTR_OCR_ECC_INJS),
> +	.ue_set_mask = (ALTR_OCR_ECC_EN | ALTR_OCR_ECC_INJD),
> +	.trig_alloc_sz = ALTR_TRIG_OCRAM_BYTE_SIZE,
> +};
> +
> +#endif	/* CONFIG_EDAC_ALTERA_OCRAM */
> +
> +/********************* L2 Cache EDAC Device Functions ********************/
> +
> +#ifdef CONFIG_EDAC_ALTERA_L2C
> +
> +static void *l2_alloc_mem(size_t size, void **other)
> +{
> +	struct device *dev = *other;
> +	void *ptemp = devm_kzalloc(dev, size, GFP_KERNEL);
> +
> +	if (!ptemp)
> +		return NULL;
> +
> +	/* Make sure everything is written out */
> +	wmb();

See, it reads much better with the comment ontop. :)

> +
> +	/*
> +	 * Clean all cache levels up to LoC (includes L2)
> +	 * This ensures the corrupted data is written into
> +	 * L2 cache for readback test (which causes ECC error).
> +	 */
> +	flush_cache_all();
> +
> +	return ptemp;
> +}
> +
> +static void l2_free_mem(void *p, size_t size, void *other)
> +{
> +	struct device *dev = other;
> +
> +	if (dev && p)
> +		devm_kfree(dev, p);
> +}
> +
> +/*
> + * altr_l2_dependencies()
> + *	Test for L2 cache ECC dependencies upon entry because
> + *	platform specific startup should have initialized the L2
> + *	memory and enabled the ECC.
> + *	Bail if ECC is not enabled.
> + *	Note that L2 Cache Enable is forced at build time.
> + */
> +static int altr_l2_dependencies(struct platform_device *pdev,

Here too, pls add a verb in the function name.

> +				void __iomem *base)
> +{
> +	u32 control;
> +
> +	control = readl(base) & ALTR_L2_ECC_EN;
> +	if (!control) {
> +		edac_printk(KERN_ERR, EDAC_DEVICE,
> +			    "L2: No ECC present, or ECC disabled\n");
> +		return -ENODEV;
> +	}
> +
> +	return 0;
> +}

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.


From marc.zyngier at arm.com  Mon Feb  8 03:40:16 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Feb 2016 11:40:16 +0000
Subject: [PATCH 2/8] ARM: KVM: Properly sort the invariant table
In-Reply-To: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454931622-14902-3-git-send-email-marc.zyngier@arm.com>

Not having the invariant table properly sorted is an oddity, and
may get in the way of future optimisations. Let's fix it.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/coproc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index f3d88dc..16c74f8 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -645,6 +645,9 @@ static struct coproc_reg invariant_cp15[] = {
 	{ CRn( 0), CRm( 0), Op1( 0), Op2( 3), is32, NULL, get_TLBTR },
 	{ CRn( 0), CRm( 0), Op1( 0), Op2( 6), is32, NULL, get_REVIDR },
 
+	{ CRn( 0), CRm( 0), Op1( 1), Op2( 1), is32, NULL, get_CLIDR },
+	{ CRn( 0), CRm( 0), Op1( 1), Op2( 7), is32, NULL, get_AIDR },
+
 	{ CRn( 0), CRm( 1), Op1( 0), Op2( 0), is32, NULL, get_ID_PFR0 },
 	{ CRn( 0), CRm( 1), Op1( 0), Op2( 1), is32, NULL, get_ID_PFR1 },
 	{ CRn( 0), CRm( 1), Op1( 0), Op2( 2), is32, NULL, get_ID_DFR0 },
@@ -660,9 +663,6 @@ static struct coproc_reg invariant_cp15[] = {
 	{ CRn( 0), CRm( 2), Op1( 0), Op2( 3), is32, NULL, get_ID_ISAR3 },
 	{ CRn( 0), CRm( 2), Op1( 0), Op2( 4), is32, NULL, get_ID_ISAR4 },
 	{ CRn( 0), CRm( 2), Op1( 0), Op2( 5), is32, NULL, get_ID_ISAR5 },
-
-	{ CRn( 0), CRm( 0), Op1( 1), Op2( 1), is32, NULL, get_CLIDR },
-	{ CRn( 0), CRm( 0), Op1( 1), Op2( 7), is32, NULL, get_AIDR },
 };
 
 /*
-- 
2.1.4



From marc.zyngier at arm.com  Mon Feb  8 03:40:17 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Feb 2016 11:40:17 +0000
Subject: [PATCH 3/8] ARM: KVM: Enforce sorting of all CP tables
In-Reply-To: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454931622-14902-4-git-send-email-marc.zyngier@arm.com>

Since we're obviously terrible at sorting the CP tables, make sure
we're going to do it properly (or fail to boot). arm64 has had the
same mechanism for a while, and nobody ever broke it...

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/coproc.c | 25 +++++++++++++++++--------
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index 16c74f8..03f5d14 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -381,17 +381,26 @@ static const struct coproc_reg cp15_regs[] = {
 	{ CRn(15), CRm( 0), Op1( 4), Op2( 0), is32, access_cbar},
 };
 
+static int check_reg_table(const struct coproc_reg *table, unsigned int n)
+{
+	unsigned int i;
+
+	for (i = 1; i < n; i++) {
+		if (cmp_reg(&table[i-1], &table[i]) >= 0) {
+			kvm_err("reg table %p out of order (%d)\n", table, i - 1);
+			return 1;
+		}
+	}
+
+	return 0;
+}
+
 /* Target specific emulation tables */
 static struct kvm_coproc_target_table *target_tables[KVM_ARM_NUM_TARGETS];
 
 void kvm_register_target_coproc_table(struct kvm_coproc_target_table *table)
 {
-	unsigned int i;
-
-	for (i = 1; i < table->num; i++)
-		BUG_ON(cmp_reg(&table->table[i-1],
-			       &table->table[i]) >= 0);
-
+	BUG_ON(check_reg_table(table->table, table->num));
 	target_tables[table->target] = table;
 }
 
@@ -1210,8 +1219,8 @@ void kvm_coproc_table_init(void)
 	unsigned int i;
 
 	/* Make sure tables are unique and in order. */
-	for (i = 1; i < ARRAY_SIZE(cp15_regs); i++)
-		BUG_ON(cmp_reg(&cp15_regs[i-1], &cp15_regs[i]) >= 0);
+	BUG_ON(check_reg_table(cp15_regs, ARRAY_SIZE(cp15_regs)));
+	BUG_ON(check_reg_table(invariant_cp15, ARRAY_SIZE(invariant_cp15)));
 
 	/* We abuse the reset function to overwrite the table itself. */
 	for (i = 0; i < ARRAY_SIZE(invariant_cp15); i++)
-- 
2.1.4



From marc.zyngier at arm.com  Mon Feb  8 03:40:18 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Feb 2016 11:40:18 +0000
Subject: [PATCH 4/8] ARM: KVM: Rename struct coproc_reg::is_64 to is_64bit
In-Reply-To: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454931622-14902-5-git-send-email-marc.zyngier@arm.com>

As we're going to play some tricks on the struct coproc_reg,
make sure its 64bit indicator field matches that of coproc_params.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/coproc.c | 4 ++--
 arch/arm/kvm/coproc.h | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index 03f5d14..2a67f00 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -423,7 +423,7 @@ static const struct coproc_reg *find_reg(const struct coproc_params *params,
 	for (i = 0; i < num; i++) {
 		const struct coproc_reg *r = &table[i];
 
-		if (params->is_64bit != r->is_64)
+		if (params->is_64bit != r->is_64bit)
 			continue;
 		if (params->CRn != r->CRn)
 			continue;
@@ -1105,7 +1105,7 @@ static int write_demux_regids(u64 __user *uindices)
 static u64 cp15_to_index(const struct coproc_reg *reg)
 {
 	u64 val = KVM_REG_ARM | (15 << KVM_REG_ARM_COPROC_SHIFT);
-	if (reg->is_64) {
+	if (reg->is_64bit) {
 		val |= KVM_REG_SIZE_U64;
 		val |= (reg->Op1 << KVM_REG_ARM_OPC1_SHIFT);
 		/*
diff --git a/arch/arm/kvm/coproc.h b/arch/arm/kvm/coproc.h
index 88d24a3..5acd097 100644
--- a/arch/arm/kvm/coproc.h
+++ b/arch/arm/kvm/coproc.h
@@ -37,7 +37,7 @@ struct coproc_reg {
 	unsigned long Op1;
 	unsigned long Op2;
 
-	bool is_64;
+	bool is_64bit;
 
 	/* Trapped access from guest, if non-NULL. */
 	bool (*access)(struct kvm_vcpu *,
@@ -141,7 +141,7 @@ static inline int cmp_reg(const struct coproc_reg *i1,
 		return i1->Op1 - i2->Op1;
 	if (i1->Op2 != i2->Op2)
 		return i1->Op2 - i2->Op2;
-	return i2->is_64 - i1->is_64;
+	return i2->is_64bit - i1->is_64bit;
 }
 
 
@@ -150,8 +150,8 @@ static inline int cmp_reg(const struct coproc_reg *i1,
 #define CRm64(_x)       .CRn = _x, .CRm = 0
 #define Op1(_x) 	.Op1 = _x
 #define Op2(_x) 	.Op2 = _x
-#define is64		.is_64 = true
-#define is32		.is_64 = false
+#define is64		.is_64bit = true
+#define is32		.is_64bit = false
 
 bool access_vm_reg(struct kvm_vcpu *vcpu,
 		   const struct coproc_params *p,
-- 
2.1.4



From marc.zyngier at arm.com  Mon Feb  8 03:40:15 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Feb 2016 11:40:15 +0000
Subject: [PATCH 1/8] arm64: KVM: Switch the sys_reg search to be a binary
 search
In-Reply-To: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454931622-14902-2-git-send-email-marc.zyngier@arm.com>

Our 64bit sys_reg table is about 90 entries long (so far, and the
PMU support is likely to increase this). This means that on average,
it takes 45 comparaisons to find the right entry (and actually the
full 90 if we have to search the invariant table).

Not the most efficient thing. Specially when you think that this
table is already sorted. Switching to a binary search effectively
reduces the search to about 7 comparaisons. Slightly better!

As an added bonus, the comparaison is done by comparing all the
fields at once, instead of one at a time.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/sys_regs.c | 40 ++++++++++++++++++++++------------------
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index eec3598..0035869 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -20,6 +20,7 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/bsearch.h>
 #include <linux/kvm_host.h>
 #include <linux/mm.h>
 #include <linux/uaccess.h>
@@ -942,29 +943,32 @@ static const struct sys_reg_desc *get_target_table(unsigned target,
 	}
 }
 
+#define reg_to_match_value(x)						\
+	({								\
+		unsigned long val;					\
+		val  = (x)->Op0 << 14;					\
+		val |= (x)->Op1 << 11;					\
+		val |= (x)->CRn << 7;					\
+		val |= (x)->CRm << 3;					\
+		val |= (x)->Op2;					\
+		val;							\
+	 })
+
+static int match_sys_reg(const void *key, const void *elt)
+{
+	const unsigned long pval = (unsigned long)key;
+	const struct sys_reg_desc *r = elt;
+
+	return pval - reg_to_match_value(r);
+}
+
 static const struct sys_reg_desc *find_reg(const struct sys_reg_params *params,
 					 const struct sys_reg_desc table[],
 					 unsigned int num)
 {
-	unsigned int i;
-
-	for (i = 0; i < num; i++) {
-		const struct sys_reg_desc *r = &table[i];
+	unsigned long pval = reg_to_match_value(params);
 
-		if (params->Op0 != r->Op0)
-			continue;
-		if (params->Op1 != r->Op1)
-			continue;
-		if (params->CRn != r->CRn)
-			continue;
-		if (params->CRm != r->CRm)
-			continue;
-		if (params->Op2 != r->Op2)
-			continue;
-
-		return r;
-	}
-	return NULL;
+	return bsearch((void *)pval, table, num, sizeof(table[0]), match_sys_reg);
 }
 
 int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run)
-- 
2.1.4



From marc.zyngier at arm.com  Mon Feb  8 03:40:20 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Feb 2016 11:40:20 +0000
Subject: [PATCH 6/8] KVM: arm/arm64: timer: Add active state caching
In-Reply-To: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454931622-14902-7-git-send-email-marc.zyngier@arm.com>

Programming the active state in the (re)distributor can be an
expensive operation so it makes some sense to try and reduce
the number of accesses as much as possible. So far, we
program the active state on each VM entry, but there is some
opportunity to do less.

An obvious solution is to cache the active state in memory,
and only program it in the HW when conditions change. But
because the HW can also change things under our feet (the active
state can transition from 1 to 0 when the guest does an EOI),
some precautions have to be taken, which amount to only caching
an "inactive" state, and always programing it otherwise.

With this in place, we observe a reduction of around 700 cycles
on a 2GHz GICv2 platform for a NULL hypercall.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/arm.c           |  1 +
 include/kvm/arm_arch_timer.h |  5 +++++
 virt/kvm/arm/arch_timer.c    | 31 +++++++++++++++++++++++++++++++
 3 files changed, 37 insertions(+)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dda1959..af7c1a3 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -320,6 +320,7 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
 	vcpu->cpu = -1;
 
 	kvm_arm_set_running_vcpu(NULL);
+	kvm_timer_vcpu_put(vcpu);
 }
 
 int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
index 1800227..b651aed 100644
--- a/include/kvm/arm_arch_timer.h
+++ b/include/kvm/arm_arch_timer.h
@@ -55,6 +55,9 @@ struct arch_timer_cpu {
 
 	/* VGIC mapping */
 	struct irq_phys_map		*map;
+
+	/* Active IRQ state caching */
+	bool				active_cleared_last;
 };
 
 int kvm_timer_hyp_init(void);
@@ -74,4 +77,6 @@ bool kvm_timer_should_fire(struct kvm_vcpu *vcpu);
 void kvm_timer_schedule(struct kvm_vcpu *vcpu);
 void kvm_timer_unschedule(struct kvm_vcpu *vcpu);
 
+void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu);
+
 #endif
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 69bca18..bfec447 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -34,6 +34,11 @@ static struct timecounter *timecounter;
 static struct workqueue_struct *wqueue;
 static unsigned int host_vtimer_irq;
 
+void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu)
+{
+	vcpu->arch.timer_cpu.active_cleared_last = false;
+}
+
 static cycle_t kvm_phys_timer_read(void)
 {
 	return timecounter->cc->read(timecounter->cc);
@@ -130,6 +135,7 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level)
 
 	BUG_ON(!vgic_initialized(vcpu->kvm));
 
+	timer->active_cleared_last = false;
 	timer->irq.level = new_level;
 	trace_kvm_timer_update_irq(vcpu->vcpu_id, timer->map->virt_irq,
 				   timer->irq.level);
@@ -242,10 +248,35 @@ void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu)
 	else
 		phys_active = false;
 
+	/*
+	 * We want to avoid hitting the (re)distributor as much as
+	 * possible, as this is a potentially expensive MMIO access
+	 * (not to mention locks in the irq layer), and a solution for
+	 * this is to cache the "active" state in memory.
+	 *
+	 * Things to consider: we cannot cache an "active set" state,
+	 * because the HW can change this behind our back (it becomes
+	 * "clear" in the HW). We must then restrict the caching to
+	 * the "clear" state.
+	 *
+	 * The cache is invalidated on:
+	 * - vcpu put, indicating that the HW cannot be trusted to be
+	 *   in a sane state on the next vcpu load,
+	 * - any change in the interrupt state
+	 *
+	 * Usage conditions:
+	 * - cached value is "active clear"
+	 * - value to be programmed is "active clear"
+	 */
+	if (timer->active_cleared_last && !phys_active)
+		return;
+
 	ret = irq_set_irqchip_state(timer->map->irq,
 				    IRQCHIP_STATE_ACTIVE,
 				    phys_active);
 	WARN_ON(ret);
+
+	timer->active_cleared_last = !phys_active;
 }
 
 /**
-- 
2.1.4



From marc.zyngier at arm.com  Mon Feb  8 03:40:14 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Feb 2016 11:40:14 +0000
Subject: [PATCH 0/8] KVM/ARM: Guest Entry/Exit optimizations
Message-ID: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>

I've recently been looking at our entry/exit costs, and profiling
figures did show some very low hanging fruits.

The most obvious cost is that accessing the GIC HW is slow. As in
"deadly slow", specially when GICv2 is involved. So not hammering the
HW when there is nothing to write is immediately beneficial, as this
is the most common cases (whatever people seem to think, interrupts
are a *rare* event).

Another easy thing to fix is the way we handle trapped system
registers. We do insist on (mostly) sorting them, but we do perform a
linear search on trap. We can switch to a binary search for free, and
get immediate benefits (the PMU code, being extremely trap-happy,
benefits immediately from this).

With these in place, I see an improvement of 20 to 30% (depending on
the platform) on our world-switch cycle count when running a set of
hand-crafted guests that are designed to only perform traps.

Methodology:

* NULL-hypercall guest: Perform 65536 PSCI_0_2_FN_PSCI_VERSION calls,
and then a power-off:

__start:
	mov	x19, #(1 << 16)
1:	mov	x0, #0x84000000
	hvc	#0
	sub	x19, x19, #1
	cbnz	x19, 1b
	mov	x0, #0x84000000
	add	x0, x0, #9
	hvc	#0
	b	.

* sysreg trap guest: Perform 2^20 PMSELR_EL0 accesses, and power-off:

__start:
	mov	x19, #(1 << 20)
1:	mrs	x0, PMSELR_EL0
	sub	x19, x19, #1
	cbnz	x19, 1b
	mov	x0, #0x84000000
	add	x0, x0, #9
	hvc	#0
	b	.

* These guests are profiled using perf and kvmtool:

taskset -c 1 perf stat -e cycles:kh lkvm run -c1 --kernel do_sysreg.bin 2>&1 >/dev/null| grep cycles

The result is then divided by the number of iterations (2^16 or 2^20).

These tests have been run on Seattle, Mustang, and LS2085, and shown
significant improvements in all cases. I've only touched the arm64
GIC code, but obviously the 32bit code should use it as well once
we've migrated it to C.

I've pushed out a branch (kvm-arm64/suck-less) to the usual location.

Thanks,

	M.

Marc Zyngier (8):
  arm64: KVM: Switch the sys_reg search to be a binary search
  ARM: KVM: Properly sort the invariant table
  ARM: KVM: Enforce sorting of all CP tables
  ARM: KVM: Rename struct coproc_reg::is_64 to is_64bit
  ARM: KVM: Switch the CP reg search to be a binary search
  KVM: arm/arm64: timer: Add active state caching
  KVM: arm/arm64: Avoid accessing GICH registers
  KVM: arm64: Avoid accessing ICH registers

 arch/arm/kvm/arm.c              |   1 +
 arch/arm/kvm/coproc.c           |  74 ++++++-----
 arch/arm/kvm/coproc.h           |   8 +-
 arch/arm64/kvm/hyp/vgic-v2-sr.c |  71 +++++++---
 arch/arm64/kvm/hyp/vgic-v3-sr.c | 288 ++++++++++++++++++++++++----------------
 arch/arm64/kvm/sys_regs.c       |  40 +++---
 include/kvm/arm_arch_timer.h    |   5 +
 include/kvm/arm_vgic.h          |   8 +-
 virt/kvm/arm/arch_timer.c       |  31 +++++
 virt/kvm/arm/vgic-v3.c          |   4 +-
 10 files changed, 334 insertions(+), 196 deletions(-)

-- 
2.1.4



From marc.zyngier at arm.com  Mon Feb  8 03:40:19 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Feb 2016 11:40:19 +0000
Subject: [PATCH 5/8] ARM: KVM: Switch the CP reg search to be a binary search
In-Reply-To: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454931622-14902-6-git-send-email-marc.zyngier@arm.com>

Doing a linear search is a bit silly when we can do a binary search.
Not that we trap that so many things that it has become a burden yet,
but it makes sense to align it with the arm64 code.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/coproc.c | 41 +++++++++++++++++++++++------------------
 1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index 2a67f00..4f1c869 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -16,6 +16,8 @@
  * along with this program; if not, write to the Free Software
  * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
  */
+
+#include <linux/bsearch.h>
 #include <linux/mm.h>
 #include <linux/kvm_host.h>
 #include <linux/uaccess.h>
@@ -414,29 +416,32 @@ static const struct coproc_reg *get_target_table(unsigned target, size_t *num)
 	return table->table;
 }
 
+#define reg_to_match_value(x)						\
+	({								\
+		unsigned long val;					\
+		val  = (x)->CRn << 11;					\
+		val |= (x)->CRm << 7;					\
+		val |= (x)->Op1 << 4;					\
+		val |= (x)->Op2 << 1;					\
+		val |= !(x)->is_64bit;					\
+		val;							\
+	 })
+
+static int match_reg(const void *key, const void *elt)
+{
+	const unsigned long pval = (unsigned long)key;
+	const struct coproc_reg *r = elt;
+
+	return pval - reg_to_match_value(r);
+}
+
 static const struct coproc_reg *find_reg(const struct coproc_params *params,
 					 const struct coproc_reg table[],
 					 unsigned int num)
 {
-	unsigned int i;
-
-	for (i = 0; i < num; i++) {
-		const struct coproc_reg *r = &table[i];
+	unsigned long pval = reg_to_match_value(params);
 
-		if (params->is_64bit != r->is_64bit)
-			continue;
-		if (params->CRn != r->CRn)
-			continue;
-		if (params->CRm != r->CRm)
-			continue;
-		if (params->Op1 != r->Op1)
-			continue;
-		if (params->Op2 != r->Op2)
-			continue;
-
-		return r;
-	}
-	return NULL;
+	return bsearch((void *)pval, table, num, sizeof(table[0]), match_reg);
 }
 
 static int emulate_cp15(struct kvm_vcpu *vcpu,
-- 
2.1.4



From marc.zyngier at arm.com  Mon Feb  8 03:40:21 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Feb 2016 11:40:21 +0000
Subject: [PATCH 7/8] KVM: arm/arm64: Avoid accessing GICH registers
In-Reply-To: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454931622-14902-8-git-send-email-marc.zyngier@arm.com>

GICv2 registers are *slow*. As in "terrifyingly slow". Which is bad.
But we're equaly bad, as we make a point in accessing them even if
we don't have any interrupt in flight.

A good solution is to first find out if we have anything useful to
write into the GIC, and if we don't, to simply not do it. This
involves tracking which LRs actually have something valid there.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/vgic-v2-sr.c | 71 ++++++++++++++++++++++++++++-------------
 include/kvm/arm_vgic.h          |  2 ++
 2 files changed, 51 insertions(+), 22 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vgic-v2-sr.c b/arch/arm64/kvm/hyp/vgic-v2-sr.c
index e717612..874a08d 100644
--- a/arch/arm64/kvm/hyp/vgic-v2-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v2-sr.c
@@ -38,28 +38,40 @@ void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
 
 	nr_lr = vcpu->arch.vgic_cpu.nr_lr;
 	cpu_if->vgic_vmcr = readl_relaxed(base + GICH_VMCR);
-	cpu_if->vgic_misr = readl_relaxed(base + GICH_MISR);
-	eisr0  = readl_relaxed(base + GICH_EISR0);
-	elrsr0 = readl_relaxed(base + GICH_ELRSR0);
-	if (unlikely(nr_lr > 32)) {
-		eisr1  = readl_relaxed(base + GICH_EISR1);
-		elrsr1 = readl_relaxed(base + GICH_ELRSR1);
-	} else {
-		eisr1 = elrsr1 = 0;
-	}
+
+	if (vcpu->arch.vgic_cpu.live_lrs) {
+		eisr0  = readl_relaxed(base + GICH_EISR0);
+		elrsr0 = readl_relaxed(base + GICH_ELRSR0);
+		cpu_if->vgic_misr = readl_relaxed(base + GICH_MISR);
+		cpu_if->vgic_apr    = readl_relaxed(base + GICH_APR);
+
+		if (unlikely(nr_lr > 32)) {
+			eisr1  = readl_relaxed(base + GICH_EISR1);
+			elrsr1 = readl_relaxed(base + GICH_ELRSR1);
+		} else {
+			eisr1 = elrsr1 = 0;
+		}
+
 #ifdef CONFIG_CPU_BIG_ENDIAN
-	cpu_if->vgic_eisr  = ((u64)eisr0 << 32) | eisr1;
-	cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
+		cpu_if->vgic_eisr  = ((u64)eisr0 << 32) | eisr1;
+		cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
 #else
-	cpu_if->vgic_eisr  = ((u64)eisr1 << 32) | eisr0;
-	cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
+		cpu_if->vgic_eisr  = ((u64)eisr1 << 32) | eisr0;
+		cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
 #endif
-	cpu_if->vgic_apr    = readl_relaxed(base + GICH_APR);
 
-	writel_relaxed(0, base + GICH_HCR);
+		for (i = 0; i < nr_lr; i++)
+			if (vcpu->arch.vgic_cpu.live_lrs & (1UL << i))
+				cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
 
-	for (i = 0; i < nr_lr; i++)
-		cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
+		writel_relaxed(0, base + GICH_HCR);
+
+		vcpu->arch.vgic_cpu.live_lrs = 0;
+	} else {
+		cpu_if->vgic_eisr = 0;
+		cpu_if->vgic_elrsr = ~0UL;
+		cpu_if->vgic_misr = 0;
+	}
 }
 
 /* vcpu is already in the HYP VA space */
@@ -70,15 +82,30 @@ void __hyp_text __vgic_v2_restore_state(struct kvm_vcpu *vcpu)
 	struct vgic_dist *vgic = &kvm->arch.vgic;
 	void __iomem *base = kern_hyp_va(vgic->vctrl_base);
 	int i, nr_lr;
+	u64 live_lrs = 0;
 
 	if (!base)
 		return;
 
-	writel_relaxed(cpu_if->vgic_hcr, base + GICH_HCR);
-	writel_relaxed(cpu_if->vgic_vmcr, base + GICH_VMCR);
-	writel_relaxed(cpu_if->vgic_apr, base + GICH_APR);
-
 	nr_lr = vcpu->arch.vgic_cpu.nr_lr;
+
 	for (i = 0; i < nr_lr; i++)
-		writel_relaxed(cpu_if->vgic_lr[i], base + GICH_LR0 + (i * 4));
+		if (cpu_if->vgic_lr[i] & GICH_LR_STATE)
+			live_lrs |= 1UL << i;
+
+	if (live_lrs) {
+		writel_relaxed(cpu_if->vgic_hcr, base + GICH_HCR);
+		writel_relaxed(cpu_if->vgic_apr, base + GICH_APR);
+		for (i = 0; i < nr_lr; i++) {
+			u32 val = 0;
+
+			if (live_lrs & (1UL << i))
+				val = cpu_if->vgic_lr[i];
+
+			writel_relaxed(val, base + GICH_LR0 + (i * 4));
+		}
+	}
+
+	writel_relaxed(cpu_if->vgic_vmcr, base + GICH_VMCR);
+	vcpu->arch.vgic_cpu.live_lrs = live_lrs;
 }
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 13a3d53..f473fd6 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -321,6 +321,8 @@ struct vgic_cpu {
 
 	/* Protected by the distributor's irq_phys_map_lock */
 	struct list_head	irq_phys_map_list;
+
+	u64		live_lrs;
 };
 
 #define LR_EMPTY	0xff
-- 
2.1.4



From marc.zyngier at arm.com  Mon Feb  8 03:40:22 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Feb 2016 11:40:22 +0000
Subject: [PATCH 8/8] KVM: arm64: Avoid accessing ICH registers
In-Reply-To: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1454931622-14902-9-git-send-email-marc.zyngier@arm.com>

Just like on GICv2, we're a bit hammer-happy with GICv3, and access
them more often than we should.

Adopt a policy similar to what we do for GICv2, only save/restoring
the minimal set of registers. As we don't access the registers
linearly anymore (we may skip some), the convoluted accessors become
slightly simpler, and we can drop the ugly indexing macro that
tended to confuse the reviewers.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/vgic-v3-sr.c | 288 ++++++++++++++++++++++++----------------
 include/kvm/arm_vgic.h          |   6 -
 virt/kvm/arm/vgic-v3.c          |   4 +-
 3 files changed, 176 insertions(+), 122 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
index 9142e082..d3813f5 100644
--- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
@@ -39,12 +39,104 @@
 		asm volatile("msr_s " __stringify(r) ", %0" : : "r" (__val));\
 	} while (0)
 
-/* vcpu is already in the HYP VA space */
+static u64 __hyp_text __gic_v3_get_lr(unsigned int lr)
+{
+	switch (lr & 0xf) {
+	case 0:
+		return read_gicreg(ICH_LR0_EL2);
+	case 1:
+		return read_gicreg(ICH_LR1_EL2);
+	case 2:
+		return read_gicreg(ICH_LR2_EL2);
+	case 3:
+		return read_gicreg(ICH_LR3_EL2);
+	case 4:
+		return read_gicreg(ICH_LR4_EL2);
+	case 5:
+		return read_gicreg(ICH_LR5_EL2);
+	case 6:
+		return read_gicreg(ICH_LR6_EL2);
+	case 7:
+		return read_gicreg(ICH_LR7_EL2);
+	case 8:
+		return read_gicreg(ICH_LR8_EL2);
+	case 9:
+		return read_gicreg(ICH_LR9_EL2);
+	case 10:
+		return read_gicreg(ICH_LR10_EL2);
+	case 11:
+		return read_gicreg(ICH_LR11_EL2);
+	case 12:
+		return read_gicreg(ICH_LR12_EL2);
+	case 13:
+		return read_gicreg(ICH_LR13_EL2);
+	case 14:
+		return read_gicreg(ICH_LR14_EL2);
+	case 15:
+		return read_gicreg(ICH_LR15_EL2);
+	}
+
+	unreachable();
+}
+
+static void __hyp_text __gic_v3_set_lr(u64 val, int lr)
+{
+	switch (lr & 0xf) {
+	case 0:
+		write_gicreg(val, ICH_LR0_EL2);
+		break;
+	case 1:
+		write_gicreg(val, ICH_LR1_EL2);
+		break;
+	case 2:
+		write_gicreg(val, ICH_LR2_EL2);
+		break;
+	case 3:
+		write_gicreg(val, ICH_LR3_EL2);
+		break;
+	case 4:
+		write_gicreg(val, ICH_LR4_EL2);
+		break;
+	case 5:
+		write_gicreg(val, ICH_LR5_EL2);
+		break;
+	case 6:
+		write_gicreg(val, ICH_LR6_EL2);
+		break;
+	case 7:
+		write_gicreg(val, ICH_LR7_EL2);
+		break;
+	case 8:
+		write_gicreg(val, ICH_LR8_EL2);
+		break;
+	case 9:
+		write_gicreg(val, ICH_LR9_EL2);
+		break;
+	case 10:
+		write_gicreg(val, ICH_LR10_EL2);
+		break;
+	case 11:
+		write_gicreg(val, ICH_LR11_EL2);
+		break;
+	case 12:
+		write_gicreg(val, ICH_LR12_EL2);
+		break;
+	case 13:
+		write_gicreg(val, ICH_LR13_EL2);
+		break;
+	case 14:
+		write_gicreg(val, ICH_LR14_EL2);
+		break;
+	case 15:
+		write_gicreg(val, ICH_LR15_EL2);
+		break;
+	}
+}
+
 void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
 {
 	struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
 	u64 val;
-	u32 max_lr_idx, nr_pri_bits;
 
 	/*
 	 * Make sure stores to the GIC via the memory mapped interface
@@ -53,68 +145,50 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
 	dsb(st);
 
 	cpu_if->vgic_vmcr  = read_gicreg(ICH_VMCR_EL2);
-	cpu_if->vgic_misr  = read_gicreg(ICH_MISR_EL2);
-	cpu_if->vgic_eisr  = read_gicreg(ICH_EISR_EL2);
-	cpu_if->vgic_elrsr = read_gicreg(ICH_ELSR_EL2);
 
-	write_gicreg(0, ICH_HCR_EL2);
-	val = read_gicreg(ICH_VTR_EL2);
-	max_lr_idx = vtr_to_max_lr_idx(val);
-	nr_pri_bits = vtr_to_nr_pri_bits(val);
+	if (vcpu->arch.vgic_cpu.live_lrs) {
+		int i;
+		u32 max_lr_idx, nr_pri_bits;
 
-	switch (max_lr_idx) {
-	case 15:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(15)] = read_gicreg(ICH_LR15_EL2);
-	case 14:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(14)] = read_gicreg(ICH_LR14_EL2);
-	case 13:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(13)] = read_gicreg(ICH_LR13_EL2);
-	case 12:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(12)] = read_gicreg(ICH_LR12_EL2);
-	case 11:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(11)] = read_gicreg(ICH_LR11_EL2);
-	case 10:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(10)] = read_gicreg(ICH_LR10_EL2);
-	case 9:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(9)] = read_gicreg(ICH_LR9_EL2);
-	case 8:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(8)] = read_gicreg(ICH_LR8_EL2);
-	case 7:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(7)] = read_gicreg(ICH_LR7_EL2);
-	case 6:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(6)] = read_gicreg(ICH_LR6_EL2);
-	case 5:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(5)] = read_gicreg(ICH_LR5_EL2);
-	case 4:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(4)] = read_gicreg(ICH_LR4_EL2);
-	case 3:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(3)] = read_gicreg(ICH_LR3_EL2);
-	case 2:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(2)] = read_gicreg(ICH_LR2_EL2);
-	case 1:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(1)] = read_gicreg(ICH_LR1_EL2);
-	case 0:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(0)] = read_gicreg(ICH_LR0_EL2);
-	}
+		cpu_if->vgic_misr  = read_gicreg(ICH_MISR_EL2);
+		cpu_if->vgic_eisr  = read_gicreg(ICH_EISR_EL2);
+		cpu_if->vgic_elrsr = read_gicreg(ICH_ELSR_EL2);
 
-	switch (nr_pri_bits) {
-	case 7:
-		cpu_if->vgic_ap0r[3] = read_gicreg(ICH_AP0R3_EL2);
-		cpu_if->vgic_ap0r[2] = read_gicreg(ICH_AP0R2_EL2);
-	case 6:
-		cpu_if->vgic_ap0r[1] = read_gicreg(ICH_AP0R1_EL2);
-	default:
-		cpu_if->vgic_ap0r[0] = read_gicreg(ICH_AP0R0_EL2);
-	}
+		write_gicreg(0, ICH_HCR_EL2);
+		val = read_gicreg(ICH_VTR_EL2);
+		max_lr_idx = vtr_to_max_lr_idx(val);
+		nr_pri_bits = vtr_to_nr_pri_bits(val);
 
-	switch (nr_pri_bits) {
-	case 7:
-		cpu_if->vgic_ap1r[3] = read_gicreg(ICH_AP1R3_EL2);
-		cpu_if->vgic_ap1r[2] = read_gicreg(ICH_AP1R2_EL2);
-	case 6:
-		cpu_if->vgic_ap1r[1] = read_gicreg(ICH_AP1R1_EL2);
-	default:
-		cpu_if->vgic_ap1r[0] = read_gicreg(ICH_AP1R0_EL2);
+		for (i = 0; i <= max_lr_idx; i++) {
+			if (vcpu->arch.vgic_cpu.live_lrs & (1UL << i))
+				cpu_if->vgic_lr[i] = __gic_v3_get_lr(i);
+		}
+
+		switch (nr_pri_bits) {
+		case 7:
+			cpu_if->vgic_ap0r[3] = read_gicreg(ICH_AP0R3_EL2);
+			cpu_if->vgic_ap0r[2] = read_gicreg(ICH_AP0R2_EL2);
+		case 6:
+			cpu_if->vgic_ap0r[1] = read_gicreg(ICH_AP0R1_EL2);
+		default:
+			cpu_if->vgic_ap0r[0] = read_gicreg(ICH_AP0R0_EL2);
+		}
+
+		switch (nr_pri_bits) {
+		case 7:
+			cpu_if->vgic_ap1r[3] = read_gicreg(ICH_AP1R3_EL2);
+			cpu_if->vgic_ap1r[2] = read_gicreg(ICH_AP1R2_EL2);
+		case 6:
+			cpu_if->vgic_ap1r[1] = read_gicreg(ICH_AP1R1_EL2);
+		default:
+			cpu_if->vgic_ap1r[0] = read_gicreg(ICH_AP1R0_EL2);
+		}
+
+		vcpu->arch.vgic_cpu.live_lrs = 0;
+	} else {
+		cpu_if->vgic_misr  = 0;
+		cpu_if->vgic_eisr  = 0;
+		cpu_if->vgic_elrsr = 0xffff;
 	}
 
 	val = read_gicreg(ICC_SRE_EL2);
@@ -128,6 +202,8 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
 	struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
 	u64 val;
 	u32 max_lr_idx, nr_pri_bits;
+	u16 live_lrs = 0;
+	int i;
 
 	/*
 	 * VFIQEn is RES1 if ICC_SRE_EL1.SRE is 1. This causes a
@@ -140,68 +216,51 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
 	write_gicreg(cpu_if->vgic_sre, ICC_SRE_EL1);
 	isb();
 
-	write_gicreg(cpu_if->vgic_hcr, ICH_HCR_EL2);
-	write_gicreg(cpu_if->vgic_vmcr, ICH_VMCR_EL2);
-
 	val = read_gicreg(ICH_VTR_EL2);
 	max_lr_idx = vtr_to_max_lr_idx(val);
 	nr_pri_bits = vtr_to_nr_pri_bits(val);
 
-	switch (nr_pri_bits) {
-	case 7:
-		 write_gicreg(cpu_if->vgic_ap1r[3], ICH_AP1R3_EL2);
-		 write_gicreg(cpu_if->vgic_ap1r[2], ICH_AP1R2_EL2);
-	case 6:
-		 write_gicreg(cpu_if->vgic_ap1r[1], ICH_AP1R1_EL2);
-	default:
-		 write_gicreg(cpu_if->vgic_ap1r[0], ICH_AP1R0_EL2);
-	}	 	                           
-		 	                           
-	switch (nr_pri_bits) {
-	case 7:
-		 write_gicreg(cpu_if->vgic_ap0r[3], ICH_AP0R3_EL2);
-		 write_gicreg(cpu_if->vgic_ap0r[2], ICH_AP0R2_EL2);
-	case 6:
-		 write_gicreg(cpu_if->vgic_ap0r[1], ICH_AP0R1_EL2);
-	default:
-		 write_gicreg(cpu_if->vgic_ap0r[0], ICH_AP0R0_EL2);
+	for (i = 0; i <= max_lr_idx; i++) {
+		if (cpu_if->vgic_lr[i] & ICH_LR_STATE)
+			live_lrs |= (1 << i);
 	}
 
-	switch (max_lr_idx) {
-	case 15:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(15)], ICH_LR15_EL2);
-	case 14:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(14)], ICH_LR14_EL2);
-	case 13:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(13)], ICH_LR13_EL2);
-	case 12:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(12)], ICH_LR12_EL2);
-	case 11:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(11)], ICH_LR11_EL2);
-	case 10:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(10)], ICH_LR10_EL2);
-	case 9:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(9)], ICH_LR9_EL2);
-	case 8:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(8)], ICH_LR8_EL2);
-	case 7:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(7)], ICH_LR7_EL2);
-	case 6:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(6)], ICH_LR6_EL2);
-	case 5:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(5)], ICH_LR5_EL2);
-	case 4:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(4)], ICH_LR4_EL2);
-	case 3:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(3)], ICH_LR3_EL2);
-	case 2:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(2)], ICH_LR2_EL2);
-	case 1:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(1)], ICH_LR1_EL2);
-	case 0:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(0)], ICH_LR0_EL2);
+	write_gicreg(cpu_if->vgic_vmcr, ICH_VMCR_EL2);
+
+	if (live_lrs) {
+		write_gicreg(cpu_if->vgic_hcr, ICH_HCR_EL2);
+
+		switch (nr_pri_bits) {
+		case 7:
+			write_gicreg(cpu_if->vgic_ap1r[3], ICH_AP1R3_EL2);
+			write_gicreg(cpu_if->vgic_ap1r[2], ICH_AP1R2_EL2);
+		case 6:
+			write_gicreg(cpu_if->vgic_ap1r[1], ICH_AP1R1_EL2);
+		default:
+			write_gicreg(cpu_if->vgic_ap1r[0], ICH_AP1R0_EL2);
+		}
+		 	                           
+		switch (nr_pri_bits) {
+		case 7:
+			write_gicreg(cpu_if->vgic_ap0r[3], ICH_AP0R3_EL2);
+			write_gicreg(cpu_if->vgic_ap0r[2], ICH_AP0R2_EL2);
+		case 6:
+			write_gicreg(cpu_if->vgic_ap0r[1], ICH_AP0R1_EL2);
+		default:
+			write_gicreg(cpu_if->vgic_ap0r[0], ICH_AP0R0_EL2);
+		}
+
+		for (i = 0; i <= max_lr_idx; i++) {
+			val = 0;
+
+			if (live_lrs & (1 << i))
+				val = cpu_if->vgic_lr[i];
+
+			__gic_v3_set_lr(val, i);
+		}
 	}
 
+
 	/*
 	 * Ensures that the above will have reached the
 	 * (re)distributors. This ensure the guest will read the
@@ -209,6 +268,7 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
 	 */
 	isb();
 	dsb(sy);
+	vcpu->arch.vgic_cpu.live_lrs = live_lrs;
 
 	/*
 	 * Prevent the guest from touching the GIC system registers if
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index f473fd6..281caf8 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -279,12 +279,6 @@ struct vgic_v2_cpu_if {
 	u32		vgic_lr[VGIC_V2_MAX_LRS];
 };
 
-/*
- * LRs are stored in reverse order in memory. make sure we index them
- * correctly.
- */
-#define VGIC_V3_LR_INDEX(lr)		(VGIC_V3_MAX_LRS - 1 - lr)
-
 struct vgic_v3_cpu_if {
 #ifdef CONFIG_KVM_ARM_VGIC_V3
 	u32		vgic_hcr;
diff --git a/virt/kvm/arm/vgic-v3.c b/virt/kvm/arm/vgic-v3.c
index 453eafd..11b5ff6 100644
--- a/virt/kvm/arm/vgic-v3.c
+++ b/virt/kvm/arm/vgic-v3.c
@@ -42,7 +42,7 @@ static u32 ich_vtr_el2;
 static struct vgic_lr vgic_v3_get_lr(const struct kvm_vcpu *vcpu, int lr)
 {
 	struct vgic_lr lr_desc;
-	u64 val = vcpu->arch.vgic_cpu.vgic_v3.vgic_lr[VGIC_V3_LR_INDEX(lr)];
+	u64 val = vcpu->arch.vgic_cpu.vgic_v3.vgic_lr[lr];
 
 	if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
 		lr_desc.irq = val & ICH_LR_VIRTUALID_MASK;
@@ -106,7 +106,7 @@ static void vgic_v3_set_lr(struct kvm_vcpu *vcpu, int lr,
 		lr_val |= ((u64)lr_desc.hwirq) << ICH_LR_PHYS_ID_SHIFT;
 	}
 
-	vcpu->arch.vgic_cpu.vgic_v3.vgic_lr[VGIC_V3_LR_INDEX(lr)] = lr_val;
+	vcpu->arch.vgic_cpu.vgic_v3.vgic_lr[lr] = lr_val;
 
 	if (!(lr_desc.state & LR_STATE_MASK))
 		vcpu->arch.vgic_cpu.vgic_v3.vgic_elrsr |= (1U << lr);
-- 
2.1.4



From mark.rutland at arm.com  Mon Feb  8 03:46:49 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 8 Feb 2016 11:46:49 +0000
Subject: [PATCH] arm64: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL
In-Reply-To: <1454716218-4918-1-git-send-email-yang.shi@linaro.org>
References: <1454716218-4918-1-git-send-email-yang.shi@linaro.org>
Message-ID: <20160208114649.GB13498@leverpostej>

Hi,

On Fri, Feb 05, 2016 at 03:50:18PM -0800, Yang Shi wrote:
> To enable UBSAN on arm64, ARCH_HAS_UBSAN_SANITIZE_ALL need to be selected.
> 
> Basic kernel bootup test is passed on arm64 with CONFIG_UBSAN_SANITIZE_ALL
> enabled.
> 
> Signed-off-by: Yang Shi <yang.shi at linaro.org>
> ---
>  arch/arm64/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 8cc6228..1c29e20 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -14,6 +14,7 @@ config ARM64
>  	select ARCH_WANT_OPTIONAL_GPIOLIB
>  	select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
>  	select ARCH_WANT_FRAME_POINTERS
> +	select ARCH_HAS_UBSAN_SANITIZE_ALL
>  	select ARM_AMBA
>  	select ARM_ARCH_TIMER
>  	select ARM_GIC

I gave this a go, and I got a couple of splats (included below) when
booting an Ubuntu 14.04 arm64 rootfs. I'm using Linato 15.08 GCC 5.1 to
compile an arm64 defconfig, and I see the issue with v4.5-rc2 and
v4.5-rc3.

I will dig into that and file a report shortl, unless someone has
already reported the same issue.

Did you see any failures in your testing? For reference, which kernel
version, compiler, and config were you using?

This patch itself looks good, so FWIW:

Tested-by: Mark Rutland <mark.rutland at arm.com>

Thanks,
Mark.

[    3.804750] ================================================================================
[    3.813176] UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2612:15
[    3.819431] shift exponent 4294967295 is too large for 32-bit type 'int'
[    3.826121] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc2+ #48
[    3.832463] Hardware name: AMD Overdrive/Supercharger/Default string, BIOS ROD0085E 11/23/2015
[    3.841060] Call trace:
[    3.843499] [<ffffffc00008d7b8>] dump_backtrace+0x0/0x298
[    3.848887] [<ffffffc00008da64>] show_stack+0x14/0x20
[    3.853929] [<ffffffc00056e0f0>] dump_stack+0xe0/0x178
[    3.859056] [<ffffffc0005b734c>] ubsan_epilogue+0x14/0x50
[    3.864444] [<ffffffc0005b7748>] __ubsan_handle_shift_out_of_bounds+0xe0/0x138
[    3.871655] [<ffffffc0003e1734>] ext4_mb_init+0x84c/0x920
[    3.877043] [<ffffffc0003ba294>] ext4_fill_super+0x2eac/0x4958
[    3.882866] [<ffffffc0002c1008>] mount_bdev+0x180/0x1e8
[    3.888079] [<ffffffc0003adf8c>] ext4_mount+0x14/0x20
[    3.893118] [<ffffffc0002c23f4>] mount_fs+0x44/0x1c8
[    3.898073] [<ffffffc0002ed9c0>] vfs_kern_mount+0x50/0x1a8
[    3.903547] [<ffffffc0002f3d90>] do_mount+0x240/0x1478
[    3.908673] [<ffffffc0002f54d0>] SyS_mount+0x90/0xf8
[    3.913627] [<ffffffc000eb2750>] mount_block_root+0x22c/0x3c4
[    3.919361] [<ffffffc000eb2a08>] mount_root+0x120/0x138
[    3.924574] [<ffffffc000eb2b5c>] prepare_namespace+0x13c/0x184
[    3.930396] [<ffffffc000eb21bc>] kernel_init_freeable+0x390/0x3b4
[    3.936479] [<ffffffc000bb4a78>] kernel_init+0x10/0xe0
[    3.941606] [<ffffffc000086cd0>] ret_from_fork+0x10/0x40
[    3.946905] ================================================================================

[    5.566166] ================================================================================
[    5.574596] UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1274:11
[    5.580851] shift exponent -1 is negative
[    5.584851] CPU: 4 PID: 1028 Comm: mount Not tainted 4.5.0-rc2+ #48
[    5.591105] Hardware name: AMD Overdrive/Supercharger/Default string, BIOS ROD0085E 11/23/2015
[    5.599702] Call trace:
[    5.602142] [<ffffffc00008d7b8>] dump_backtrace+0x0/0x298
[    5.607530] [<ffffffc00008da64>] show_stack+0x14/0x20
[    5.612572] [<ffffffc00056e0f0>] dump_stack+0xe0/0x178
[    5.617700] [<ffffffc0005b734c>] ubsan_epilogue+0x14/0x50
[    5.623088] [<ffffffc0005b7748>] __ubsan_handle_shift_out_of_bounds+0xe0/0x138
[    5.630300] [<ffffffc0003d2a04>] mb_find_order_for_block+0x154/0x1b0
[    5.636641] [<ffffffc0003d2b2c>] mb_find_extent+0xcc/0x548
[    5.642116] [<ffffffc0003de6a8>] ext4_mb_complex_scan_group+0xe8/0x4e8
[    5.648632] [<ffffffc0003ded7c>] ext4_mb_regular_allocator+0x2d4/0x648
[    5.655148] [<ffffffc0003e2b4c>] ext4_mb_new_blocks+0x344/0x7e0
[    5.661056] [<ffffffc0003cbf54>] ext4_ext_map_blocks+0x684/0xf68
[    5.667052] [<ffffffc000393664>] ext4_map_blocks+0x12c/0x500
[    5.672699] [<ffffffc000398df4>] ext4_writepages+0x47c/0xe38
[    5.678348] [<ffffffc00020da20>] do_writepages+0x48/0xc8
[    5.683649] [<ffffffc0001f9100>] __filemap_fdatawrite_range+0x70/0xe8
[    5.690078] [<ffffffc0001f91b0>] filemap_flush+0x18/0x20
[    5.695378] [<ffffffc000394b64>] ext4_alloc_da_blocks+0x3c/0x78
[    5.701285] [<ffffffc0003ac1c8>] ext4_rename+0x690/0xe38
[    5.706585] [<ffffffc0003ac98c>] ext4_rename2+0x1c/0x40
[    5.711800] [<ffffffc0002d0510>] vfs_rename+0x2c0/0xa90
[    5.717013] [<ffffffc0002d661c>] SyS_renameat2+0x464/0x5c0
[    5.722486] [<ffffffc0002d6788>] SyS_renameat+0x10/0x18
[    5.727700] [<ffffffc000086d30>] el0_svc_naked+0x24/0x28
[    5.732998] ================================================================================


From afaerber at suse.de  Mon Feb  8 03:50:43 2016
From: afaerber at suse.de (=?UTF-8?Q?Andreas_F=c3=a4rber?=)
Date: Mon, 8 Feb 2016 12:50:43 +0100
Subject: [PATCH] tty: serial: meson: Implement earlycon support
In-Reply-To: <56B817FC.4000604@hurleysoftware.com>
References: <1454878635-24396-1-git-send-email-afaerber@suse.de>
 <56B817FC.4000604@hurleysoftware.com>
Message-ID: <56B88113.2050800@suse.de>

Hi Peter,

Am 08.02.2016 um 05:22 schrieb Peter Hurley:
> On 02/07/2016 12:57 PM, Andreas F?rber wrote:
>> Reuse the existing console write implementation for implementing
>> DT-based and command-line-based earlycon support.
>>
>> Signed-off-by: Andreas F?rber <afaerber at suse.de>
>> ---
>>  Documentation/kernel-parameters.txt |  6 ++++++
>>  drivers/tty/serial/meson_uart.c     | 13 +++++++++++++
>>  2 files changed, 19 insertions(+)
>>
>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>> index 602065c..90801ac 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -1030,6 +1030,12 @@ Such letter suffixes can also be entirely omitted.
>>  			the driver will use only 32-bit accessors to read/write
>>  			the device registers.
>>  
>> +		meson_serial,<addr>
>> +			Start an early, polled-mode console on a meson serial
>> +			port at the specified address. The serial port must
>> +			already be setup and configured. Options are not yet
>> +			supported.
>> +
>>  		msm_serial,<addr>
>>  			Start an early, polled-mode console on an msm serial
>>  			port at the specified address. The serial port
>> diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
>> index b12a37b..6f89567 100644
>> --- a/drivers/tty/serial/meson_uart.c
>> +++ b/drivers/tty/serial/meson_uart.c
>> @@ -548,6 +548,19 @@ static int __init meson_serial_console_init(void)
>>  }
>>  console_initcall(meson_serial_console_init);
>>  
>> +static int __init
>> +meson_serial_early_console_setup(struct earlycon_device *device, const char *opt)
>> +{
>> +	if (!device->port.membase)
>> +		return -ENODEV;
>> +
>> +	device->con->write = meson_serial_console_write;
> 
> meson_serial_console_write() is not appropriate for earlycon; it assumes the
> earlycon port is the same as the driver port (it isn't).

Thanks for spotting that.

I forgot to mention that I tested this on arm64, where there is no
earlyprintk any more, seemingly successfully getting a bootconsole
uart0. Using co->data instead of co->index I now get meson_serial0
instead, doh.

This probably slipped though because another patch is necessary for
fixing the baudrate calculation on my device.

>> +	return 0;
>> +}
>> +EARLYCON_DECLARE(meson_serial, meson_serial_early_console_setup);
>> +OF_EARLYCON_DECLARE(meson_serial, "amlogic,meson-uart",
>> +		    meson_serial_early_console_setup);
> 
> With today's linux-next (or Greg's tty-next tree), it is no longer necessary to
> declare separate earlycon's when you want both; OF_EARLYCON_DECLARE() declares
> both a devicetree-enabled earlycon and automatically provides for a command line
> earlycon of the same name.

Thanks for the hint, it was based on linux-next from a couple days ago.

Is there any guidance wrt naming? I noticed that msm uses -uart in the
compatible string and _serial for earlycon, so I copied that; should it
rather be meson_uart or just meson?

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N?rnberg)


From lorenzo.pieralisi at arm.com  Mon Feb  8 03:55:52 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Mon, 8 Feb 2016 11:55:52 +0000
Subject: [PATCH v4 07/13] arm64: Change cpu_resume() to enable mmu early
 then access sleep_sp by va
In-Reply-To: <56B859D9.3080601@arm.com>
References: <1453977766-20907-1-git-send-email-james.morse@arm.com>
 <1453977766-20907-8-git-send-email-james.morse@arm.com>
 <20160205162617.GD31547@red-moon> <56B859D9.3080601@arm.com>
Message-ID: <20160208115552.GA5471@red-moon>

On Mon, Feb 08, 2016 at 09:03:21AM +0000, James Morse wrote:
> Hi Lorenzo,
> 
> On 05/02/16 16:26, Lorenzo Pieralisi wrote:
> >> cpu_do_{suspend,resume} could be further reduced to not restore: cpacr_el1,
> >> mdscr_el1, tcr_el1, vbar_el1 and sctlr_el1, all of which are set by
> >> __cpu_setup(). However these values all contain res0 bits that may be used
> >> to enable future features.
> > 
> > This patch is a very nice clean-up, a comment below.
> > 
> > I think that for registers like tcr_el1 and sctlr_el1 we should define
> > a restore mask (to avoid overwriting bits set-up by __cpu_setup), eg
> > current code that restores the tcr_el1 seems wrong to me, see below.
> 
> Presumably this should be two masks, one to find RES0 bits that are
> set, and are assumed to have some new meaning, and another to find
> RES1 bits that have been cleared.

For the time being, it is ok to just fix t0sz restore which means
that either you avoid overwriting tcr_el1.t0sz in cpu_do_resume()
or you force the t0sz value field to be whatever value is already
present in the register (ie set-up in __cpu_setup through
tcr_set_idmap_t0sz) and finally set it to correct the default value
in __cpu_suspend_exit() using the correct procedure:

- set reserved ttbr0
- flush tlb
- cpu_set_default_tcr_t0sz

Thanks,
Lorenzo


From stefano.stabellini at eu.citrix.com  Mon Feb  8 03:43:27 2016
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 8 Feb 2016 11:43:27 +0000
Subject: [PATCH v4 05/17] xen: memory : Add new XENMAPSPACE type
 XENMAPSPACE_dev_mmio
In-Reply-To: <1454641552-12576-6-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
 <1454641552-12576-6-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <alpine.DEB.2.02.1602081142360.27008@kaball.uk.xensource.com>

On Fri, 5 Feb 2016, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
> 
> Add a new type of Xen map space for Dom0 to map device's MMIO region.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> ---
>  include/xen/interface/memory.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index 2ecfe4f..9aa8988 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -160,6 +160,7 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
>  #define XENMAPSPACE_gmfn_foreign 4 /* GMFN from another dom,
>  				    * XENMEM_add_to_physmap_range only.
>  				    */
> +#define XENMAPSPACE_dev_mmio     5 /* device mmio region */
>  
>  /*
>   * Sets the GPFN at which a particular page appears in the specified guest's

This patch needs to wait at least until the corresponding Xen patch
(the one which introduces XENMAPSPACE_dev_mmio on the Xen side) is
Acked by one of the Xen maintainers.


From javier at osg.samsung.com  Mon Feb  8 04:03:36 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Mon, 8 Feb 2016 09:03:36 -0300
Subject: [PATCH] drm/exynos: dp: Fix panel and bridge lookup logic
In-Reply-To: <1454080171-23769-1-git-send-email-javier@osg.samsung.com>
References: <1454080171-23769-1-git-send-email-javier@osg.samsung.com>
Message-ID: <56B88418.7090106@osg.samsung.com>

Hello Inki,

On 01/29/2016 12:09 PM, Javier Martinez Canillas wrote:
> Commit a9fa852886fd ("drm/exynos: dp: add of_graph dt binding support
> for panel") made the Exynos DP DT binding more consistent since the OF
> graph could be used to lookup either a panel or a bridge device node.
>
> Before that commit, a panel would be looked up using a phandle and a
> bridge using the OF graph which made the DT binding not consistent.
>
> But the patch broke the later case since not finding a panel dev node
> would cause the driver's to do a probe deferral instead of attempting
> to lookup a bridge device node associated with the remote endpoint.
>
> So instead of returning a -EPROBE_DEFER if a panel is not found, check
> if there's a bridge and only do a probe deferral if both aren't found.
>
> Fixes: a9fa852886fd ("drm/exynos: dp: add of_graph dt binding support for panel")
> Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
>

Any comments about this patch? It is needed to have display working on
machines with a bridge chip again so it should be pushed to -rc ASAP.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America


From afaerber at suse.de  Mon Feb  8 04:04:03 2016
From: afaerber at suse.de (=?UTF-8?q?Andreas=20F=C3=A4rber?=)
Date: Mon,  8 Feb 2016 13:04:03 +0100
Subject: [PATCH v2] tty: serial: meson: Implement earlycon support
Message-ID: <1454933043-15351-1-git-send-email-afaerber@suse.de>

Split off the bulk of the existing meson_serial_console_write()
implementation into meson_serial_port_write() for implementing
meson_serial_early_console_write().

Signed-off-by: Andreas F?rber <afaerber at suse.de>
---
 v1 -> v2:
 * Implement meson_serial_early_console_write() instead of reusing
   meson_serial_console_write() (Peter)
 
 Documentation/kernel-parameters.txt |  6 ++++++
 drivers/tty/serial/meson_uart.c     | 42 ++++++++++++++++++++++++++++++-------
 2 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 59e15150a9d8..237f0ee20afb 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1025,6 +1025,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			the driver will use only 32-bit accessors to read/write
 			the device registers.
 
+		meson_serial,<addr>
+			Start an early, polled-mode console on a meson serial
+			port at the specified address. The serial port must
+			already be setup and configured. Options are not yet
+			supported.
+
 		msm_serial,<addr>
 			Start an early, polled-mode console on an msm serial
 			port at the specified address. The serial port
diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
index b12a37bd37b6..9efcfa2de31e 100644
--- a/drivers/tty/serial/meson_uart.c
+++ b/drivers/tty/serial/meson_uart.c
@@ -475,18 +475,13 @@ static void meson_console_putchar(struct uart_port *port, int ch)
 	writel(ch, port->membase + AML_UART_WFIFO);
 }
 
-static void meson_serial_console_write(struct console *co, const char *s,
-				       u_int count)
+static void meson_serial_port_write(struct uart_port *port, const char *s,
+				    u_int count)
 {
-	struct uart_port *port;
 	unsigned long flags;
 	int locked;
 	u32 val, tmp;
 
-	port = meson_ports[co->index];
-	if (!port)
-		return;
-
 	local_irq_save(flags);
 	if (port->sysrq) {
 		locked = 0;
@@ -510,6 +505,18 @@ static void meson_serial_console_write(struct console *co, const char *s,
 	local_irq_restore(flags);
 }
 
+static void meson_serial_console_write(struct console *co, const char *s,
+				       u_int count)
+{
+	struct uart_port *port;
+
+	port = meson_ports[co->index];
+	if (!port)
+		return;
+
+	meson_serial_port_write(port, s, count);
+}
+
 static int meson_serial_console_setup(struct console *co, char *options)
 {
 	struct uart_port *port;
@@ -548,6 +555,27 @@ static int __init meson_serial_console_init(void)
 }
 console_initcall(meson_serial_console_init);
 
+static void meson_serial_early_console_write(struct console *co,
+					     const char *s,
+					     u_int count)
+{
+	struct earlycon_device *dev = co->data;
+
+	meson_serial_port_write(&dev->port, s, count);
+}
+
+static int __init
+meson_serial_early_console_setup(struct earlycon_device *device, const char *opt)
+{
+	if (!device->port.membase)
+		return -ENODEV;
+
+	device->con->write = meson_serial_early_console_write;
+	return 0;
+}
+OF_EARLYCON_DECLARE(meson_serial, "amlogic,meson-uart",
+		    meson_serial_early_console_setup);
+
 #define MESON_SERIAL_CONSOLE	(&meson_serial_console)
 #else
 #define MESON_SERIAL_CONSOLE	NULL
-- 
2.6.2



From mark.rutland at arm.com  Mon Feb  8 04:03:17 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 8 Feb 2016 12:03:17 +0000
Subject: [PATCH v4 07/13] arm64: Change cpu_resume() to enable mmu early
 then access sleep_sp by va
In-Reply-To: <20160208115552.GA5471@red-moon>
References: <1453977766-20907-1-git-send-email-james.morse@arm.com>
 <1453977766-20907-8-git-send-email-james.morse@arm.com>
 <20160205162617.GD31547@red-moon> <56B859D9.3080601@arm.com>
 <20160208115552.GA5471@red-moon>
Message-ID: <20160208120317.GA7700@leverpostej>

On Mon, Feb 08, 2016 at 11:55:52AM +0000, Lorenzo Pieralisi wrote:
> On Mon, Feb 08, 2016 at 09:03:21AM +0000, James Morse wrote:
> > Hi Lorenzo,
> > 
> > On 05/02/16 16:26, Lorenzo Pieralisi wrote:
> > >> cpu_do_{suspend,resume} could be further reduced to not restore: cpacr_el1,
> > >> mdscr_el1, tcr_el1, vbar_el1 and sctlr_el1, all of which are set by
> > >> __cpu_setup(). However these values all contain res0 bits that may be used
> > >> to enable future features.
> > > 
> > > This patch is a very nice clean-up, a comment below.
> > > 
> > > I think that for registers like tcr_el1 and sctlr_el1 we should define
> > > a restore mask (to avoid overwriting bits set-up by __cpu_setup), eg
> > > current code that restores the tcr_el1 seems wrong to me, see below.
> > 
> > Presumably this should be two masks, one to find RES0 bits that are
> > set, and are assumed to have some new meaning, and another to find
> > RES1 bits that have been cleared.
> 
> For the time being, it is ok to just fix t0sz restore which means
> that either you avoid overwriting tcr_el1.t0sz in cpu_do_resume()
> or you force the t0sz value field to be whatever value is already
> present in the register (ie set-up in __cpu_setup through
> tcr_set_idmap_t0sz) and finally set it to correct the default value
> in __cpu_suspend_exit() using the correct procedure:
> 
> - set reserved ttbr0
> - flush tlb
> - cpu_set_default_tcr_t0sz

You can use cpu_uninstall_idmap() [1] to do that, which Catalin has
queued as part of my pagetable rework [2]. That will also install the
appropriate TTBR0 context for the current thread, if any.

Mark.

[1] https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/commit/?h=for-next/pgtable&id=7036610bbd05a5269fa1d25c1c000ad3465c2906
[2] https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=for-next/pgtable


From sunil.kovvuri at gmail.com  Mon Feb  8 04:07:46 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Mon,  8 Feb 2016 17:37:46 +0530
Subject: [PATCH 0/6] net: thunderx: Setting IRQ affinity hints and other
 optimizations
Message-ID: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>

From: Sunil Goutham <sgoutham at cavium.com>

This patch series contains changes
- To add support for virtual function's irq affinity hint
- Replace napi_schedule() with napi_schedule_irqoff()
- Reduce page allocation overhead by allocating pages
  of higher order when pagesize is 4KB.
- Add couple of stats which helps in debugging
- Some miscellaneous changes to BGX driver.


David Daney (1):
  net: thunderx: bgx: Use standard firmware node infrastructure.

Robert Richter (1):
  net: thunderx: bgx: Add log message when setting mac address

Sunil Goutham (3):
  net: thunderx: Use napi_schedule_irqoff()
  net: thunderx: Assign affinity hints to vf's interrupts
  net: thunderx: Alloc higher order pages when pagesize is small

Thanneeru Srinivasulu (1):
  net, thunderx: Add TX timeout and RX buffer alloc failure stats.

 drivers/net/ethernet/cavium/thunder/nic.h          |    4 ++
 .../net/ethernet/cavium/thunder/nicvf_ethtool.c    |    2 +
 drivers/net/ethernet/cavium/thunder/nicvf_main.c   |   40 ++++++++++++++++++-
 drivers/net/ethernet/cavium/thunder/nicvf_queues.c |    5 +-
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c  |   38 +++++++++++--------
 5 files changed, 67 insertions(+), 22 deletions(-)



From sunil.kovvuri at gmail.com  Mon Feb  8 04:07:47 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Mon,  8 Feb 2016 17:37:47 +0530
Subject: [PATCH 1/6] net,
 thunderx: Add TX timeout and RX buffer alloc failure stats.
In-Reply-To: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <1454933272-45005-2-git-send-email-sunil.kovvuri@gmail.com>

From: Thanneeru Srinivasulu <tsrinivasulu at caviumnetworks.com>

When system is low on atomic memory, too many error messages are logged.
Since this is not a total failure but a simple switch to non-atomic allocation
better to have a stat.

Also add a stat for reset, kicked due to transmit watchdog timeout.

Signed-off-by: Thanneeru Srinivasulu <tsrinivasulu at caviumnetworks.com>
Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/nic.h          |    3 +++
 .../net/ethernet/cavium/thunder/nicvf_ethtool.c    |    2 ++
 drivers/net/ethernet/cavium/thunder/nicvf_main.c   |    1 +
 drivers/net/ethernet/cavium/thunder/nicvf_queues.c |    3 +--
 4 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nic.h b/drivers/net/ethernet/cavium/thunder/nic.h
index 6888288..8af363a 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -248,10 +248,13 @@ struct nicvf_drv_stats {
 	u64 rx_frames_jumbo;
 	u64 rx_drops;
 
+	u64 rcv_buffer_alloc_failures;
+
 	/* Tx */
 	u64 tx_frames_ok;
 	u64 tx_drops;
 	u64 tx_tso;
+	u64 tx_timeout;
 	u64 txq_stop;
 	u64 txq_wake;
 };
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
index a12b2e3..d2d8ef2 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
@@ -89,9 +89,11 @@ static const struct nicvf_stat nicvf_drv_stats[] = {
 	NICVF_DRV_STAT(rx_frames_1518),
 	NICVF_DRV_STAT(rx_frames_jumbo),
 	NICVF_DRV_STAT(rx_drops),
+	NICVF_DRV_STAT(rcv_buffer_alloc_failures),
 	NICVF_DRV_STAT(tx_frames_ok),
 	NICVF_DRV_STAT(tx_tso),
 	NICVF_DRV_STAT(tx_drops),
+	NICVF_DRV_STAT(tx_timeout),
 	NICVF_DRV_STAT(txq_stop),
 	NICVF_DRV_STAT(txq_wake),
 };
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index c24cb2a..95db6b7 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -1394,6 +1394,7 @@ static void nicvf_tx_timeout(struct net_device *dev)
 		netdev_warn(dev, "%s: Transmit timed out, resetting\n",
 			    dev->name);
 
+	nic->drv_stats.tx_timeout++;
 	schedule_work(&nic->reset_task);
 }
 
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index d0d1b54..50ab6f4 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -96,8 +96,7 @@ static inline int nicvf_alloc_rcv_buffer(struct nicvf *nic, gfp_t gfp,
 		nic->rb_page = alloc_pages(gfp | __GFP_COMP | __GFP_NOWARN,
 					   order);
 		if (!nic->rb_page) {
-			netdev_err(nic->netdev,
-				   "Failed to allocate new rcv buffer\n");
+			nic->drv_stats.rcv_buffer_alloc_failures++;
 			return -ENOMEM;
 		}
 		nic->rb_page_offset = 0;
-- 
1.7.1



From sunil.kovvuri at gmail.com  Mon Feb  8 04:07:49 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Mon,  8 Feb 2016 17:37:49 +0530
Subject: [PATCH 3/6] net: thunderx: Assign affinity hints to vf's interrupts
In-Reply-To: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <1454933272-45005-4-git-send-email-sunil.kovvuri@gmail.com>

From: Sunil Goutham <sgoutham at cavium.com>

This affinity hint can be used by user space irqbalance tool to set
preferred CPU mask for irqs registered by this VF. Irqbalance needs
to be in 'exact' mode to set irq affinity same as indicated by
affinity hint.

Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/nic.h        |    1 +
 drivers/net/ethernet/cavium/thunder/nicvf_main.c |   37 ++++++++++++++++++++-
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nic.h b/drivers/net/ethernet/cavium/thunder/nic.h
index 8af363a..00cc915 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -309,6 +309,7 @@ struct nicvf {
 	struct msix_entry	msix_entries[NIC_VF_MSIX_VECTORS];
 	char			irq_name[NIC_VF_MSIX_VECTORS][20];
 	bool			irq_allocated[NIC_VF_MSIX_VECTORS];
+	cpumask_var_t		affinity_mask[NIC_VF_MSIX_VECTORS];
 
 	/* VF <-> PF mailbox communication */
 	bool			pf_acked;
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index c6f146c..90ce93e 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -899,6 +899,31 @@ static void nicvf_disable_msix(struct nicvf *nic)
 	}
 }
 
+static void nicvf_set_irq_affinity(struct nicvf *nic)
+{
+	int vec, cpu;
+	int irqnum;
+
+	for (vec = 0; vec < nic->num_vec; vec++) {
+		if (!nic->irq_allocated[vec])
+			continue;
+
+		if (!zalloc_cpumask_var(&nic->affinity_mask[vec], GFP_KERNEL))
+			return;
+		 /* CQ interrupts */
+		if (vec < NICVF_INTR_ID_SQ)
+			/* Leave CPU0 for RBDR and other interrupts */
+			cpu = nicvf_netdev_qidx(nic, vec) + 1;
+		else
+			cpu = 0;
+
+		cpumask_set_cpu(cpumask_local_spread(cpu, nic->node),
+				nic->affinity_mask[vec]);
+		irqnum = nic->msix_entries[vec].vector;
+		irq_set_affinity_hint(irqnum, nic->affinity_mask[vec]);
+	}
+}
+
 static int nicvf_register_interrupts(struct nicvf *nic)
 {
 	int irq, ret = 0;
@@ -944,8 +969,13 @@ static int nicvf_register_interrupts(struct nicvf *nic)
 	ret = request_irq(nic->msix_entries[irq].vector,
 			  nicvf_qs_err_intr_handler,
 			  0, nic->irq_name[irq], nic);
-	if (!ret)
-		nic->irq_allocated[irq] = true;
+	if (ret)
+		goto err;
+
+	nic->irq_allocated[irq] = true;
+
+	/* Set IRQ affinities */
+	nicvf_set_irq_affinity(nic);
 
 err:
 	if (ret)
@@ -963,6 +993,9 @@ static void nicvf_unregister_interrupts(struct nicvf *nic)
 		if (!nic->irq_allocated[irq])
 			continue;
 
+		irq_set_affinity_hint(nic->msix_entries[irq].vector, NULL);
+		free_cpumask_var(nic->affinity_mask[irq]);
+
 		if (irq < NICVF_INTR_ID_SQ)
 			free_irq(nic->msix_entries[irq].vector, nic->napi[irq]);
 		else
-- 
1.7.1



From sunil.kovvuri at gmail.com  Mon Feb  8 04:07:48 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Mon,  8 Feb 2016 17:37:48 +0530
Subject: [PATCH 2/6] net: thunderx: Use napi_schedule_irqoff()
In-Reply-To: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <1454933272-45005-3-git-send-email-sunil.kovvuri@gmail.com>

From: Sunil Goutham <sgoutham at cavium.com>

napi_schedule is being called from hard irq context, hence
switch to napi_schedule_irqoff which avoids unneeded call
to local_irq_save and local_irq_restore.

Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/nicvf_main.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 95db6b7..c6f146c 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -828,7 +828,7 @@ static irqreturn_t nicvf_intr_handler(int irq, void *cq_irq)
 	nicvf_disable_intr(nic, NICVF_INTR_CQ, qidx);
 
 	/* Schedule NAPI */
-	napi_schedule(&cq_poll->napi);
+	napi_schedule_irqoff(&cq_poll->napi);
 
 	/* Clear interrupt */
 	nicvf_clear_intr(nic, NICVF_INTR_CQ, qidx);
-- 
1.7.1



From sunil.kovvuri at gmail.com  Mon Feb  8 04:07:50 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Mon,  8 Feb 2016 17:37:50 +0530
Subject: [PATCH 4/6] net: thunderx: bgx: Use standard firmware node
 infrastructure.
In-Reply-To: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <1454933272-45005-5-git-send-email-sunil.kovvuri@gmail.com>

From: David Daney <david.daney at cavium.com>

In the case of OF device tree, the firmware information is attached to
the BGX device structure in the standard manner, so use the firmware
iterators and accessors where possible.

Signed-off-by: David Daney <david.daney at cavium.com>
Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c |   27 +++++++++++----------
 1 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 9df26c2..111835b 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -968,26 +968,27 @@ static int bgx_init_acpi_phy(struct bgx *bgx)
 
 static int bgx_init_of_phy(struct bgx *bgx)
 {
-	struct device_node *np;
-	struct device_node *np_child;
+	struct fwnode_handle *fwn;
 	u8 lmac = 0;
-	char bgx_sel[5];
 	const char *mac;
 
-	/* Get BGX node from DT */
-	snprintf(bgx_sel, 5, "bgx%d", bgx->bgx_id);
-	np = of_find_node_by_name(NULL, bgx_sel);
-	if (!np)
-		return -ENODEV;
+	device_for_each_child_node(&bgx->pdev->dev, fwn) {
+		struct device_node *phy_np;
+		struct device_node *node = to_of_node(fwn);
+
+		/* If it is not an OF node we cannot handle it yet, so
+		 * exit the loop.
+		 */
+		if (!node)
+			break;
 
-	for_each_child_of_node(np, np_child) {
-		struct device_node *phy_np = of_parse_phandle(np_child,
-							      "phy-handle", 0);
+		phy_np = of_parse_phandle(node, "phy-handle", 0);
 		if (!phy_np)
 			continue;
+
 		bgx->lmac[lmac].phydev = of_phy_find_device(phy_np);
 
-		mac = of_get_mac_address(np_child);
+		mac = of_get_mac_address(node);
 		if (mac)
 			ether_addr_copy(bgx->lmac[lmac].mac, mac);
 
@@ -995,7 +996,7 @@ static int bgx_init_of_phy(struct bgx *bgx)
 		bgx->lmac[lmac].lmacid = lmac;
 		lmac++;
 		if (lmac == MAX_LMAC_PER_BGX) {
-			of_node_put(np_child);
+			of_node_put(node);
 			break;
 		}
 	}
-- 
1.7.1



From sunil.kovvuri at gmail.com  Mon Feb  8 04:07:51 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Mon,  8 Feb 2016 17:37:51 +0530
Subject: [PATCH 5/6] net: thunderx: bgx: Add log message when setting mac
 address
In-Reply-To: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <1454933272-45005-6-git-send-email-sunil.kovvuri@gmail.com>

From: Robert Richter <rrichter at cavium.com>

Signed-off-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 111835b..cfee496 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -886,7 +886,8 @@ static void bgx_get_qlm_mode(struct bgx *bgx)
 
 #ifdef CONFIG_ACPI
 
-static int acpi_get_mac_address(struct acpi_device *adev, u8 *dst)
+static int acpi_get_mac_address(struct device *dev, struct acpi_device *adev,
+				u8 *dst)
 {
 	u8 mac[ETH_ALEN];
 	int ret;
@@ -897,10 +898,13 @@ static int acpi_get_mac_address(struct acpi_device *adev, u8 *dst)
 		goto out;
 
 	if (!is_valid_ether_addr(mac)) {
+		dev_warn(dev, "MAC address invalid: %pM\n", mac);
 		ret = -EINVAL;
 		goto out;
 	}
 
+	dev_info(dev, "MAC address set to: %pM\n", mac);
+
 	memcpy(dst, mac, ETH_ALEN);
 out:
 	return ret;
@@ -911,14 +915,15 @@ static acpi_status bgx_acpi_register_phy(acpi_handle handle,
 					 u32 lvl, void *context, void **rv)
 {
 	struct bgx *bgx = context;
+	struct device *dev = &bgx->pdev->dev;
 	struct acpi_device *adev;
 
 	if (acpi_bus_get_device(handle, &adev))
 		goto out;
 
-	acpi_get_mac_address(adev, bgx->lmac[bgx->lmac_count].mac);
+	acpi_get_mac_address(dev, adev, bgx->lmac[bgx->lmac_count].mac);
 
-	SET_NETDEV_DEV(&bgx->lmac[bgx->lmac_count].netdev, &bgx->pdev->dev);
+	SET_NETDEV_DEV(&bgx->lmac[bgx->lmac_count].netdev, dev);
 
 	bgx->lmac[bgx->lmac_count].lmacid = bgx->lmac_count;
 out:
-- 
1.7.1



From sunil.kovvuri at gmail.com  Mon Feb  8 04:07:52 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Mon,  8 Feb 2016 17:37:52 +0530
Subject: [PATCH 6/6] net: thunderx: Alloc higher order pages when pagesize is
 small
In-Reply-To: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <1454933272-45005-7-git-send-email-sunil.kovvuri@gmail.com>

From: Sunil Goutham <sgoutham at cavium.com>

Allocate higher order pages when pagesize is small, this will
reduce number of calls to page allocator and wastage of memory.

Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/nicvf_queues.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index 50ab6f4..5adb208 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -78,7 +78,7 @@ static void nicvf_free_q_desc_mem(struct nicvf *nic, struct q_desc_mem *dmem)
 static inline int nicvf_alloc_rcv_buffer(struct nicvf *nic, gfp_t gfp,
 					 u32 buf_len, u64 **rbuf)
 {
-	int order = get_order(buf_len);
+	int order = (PAGE_SIZE <= 4096) ?  PAGE_ALLOC_COSTLY_ORDER : 0;
 
 	/* Check if request can be accomodated in previous allocated page */
 	if (nic->rb_page) {
-- 
1.7.1



From kernel at martin.sperl.org  Mon Feb  8 04:08:00 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Mon, 8 Feb 2016 13:08:00 +0100
Subject: [PATCH V2 1/3] ASoC: bcm2835: move to use the clock framework
In-Reply-To: <87vb6dfjbu.fsf@eliezer.anholt.net>
References: <1452602149-5875-1-git-send-email-kernel@martin.sperl.org>
 <1452602149-5875-2-git-send-email-kernel@martin.sperl.org>
 <87vb6dfjbu.fsf@eliezer.anholt.net>
Message-ID: <56B88520.5060606@martin.sperl.org>



On 28.01.2016 23:08, Eric Anholt wrote:
> kernel at martin.sperl.org writes:
>
>> From: Martin Sperl <kernel at martin.sperl.org>
>>
>> Since the move to the new clock framework with commit 94cb7f76caa0
>> ("ARM: bcm2835: Switch to using the new clock driver support.")
>> this driver was no longer functional as it was manipulating the
>> clock registers locally without going true the framework.
>>
>> This patch moves to use the new clock framework and also
>> moves away from the hardcoded address offsets for DMA getting
>> the dma-address directly from the device tree.
>>
>> Note that the optimal bclk_ratio selection to avoid jitter
>> due to the use of fractional dividers, which is in the
>> current version has been removed, because not all devices
>> support these non power of 2 sized transfers, which resulted
>> in lots of (downstream) modules that use:
>>    snd_soc_dai_set_bclk_ratio(cpu_dai, sample_bits * 2);
>>
>> Signed-off-by: Martin Sperl <kernel at martin.sperl.org>
>> ---
>>   sound/soc/bcm/bcm2835-i2s.c |  284 ++++++++++---------------------------------
>>   1 file changed, 64 insertions(+), 220 deletions(-)
>>
>> diff --git a/sound/soc/bcm/bcm2835-i2s.c b/sound/soc/bcm/bcm2835-i2s.c
>> index 3303d5f..1c1f221 100644
>> --- a/sound/soc/bcm/bcm2835-i2s.c
>> +++ b/sound/soc/bcm/bcm2835-i2s.c
>
>> -	dev->i2s_regmap = regmap[0];
>> -	dev->clk_regmap = regmap[1];
>> +	/* get the clock */
>> +	dev->clk_prepared = false;
>> +	dev->clk = devm_clk_get(&pdev->dev, NULL);
>> +	if (IS_ERR(dev->clk)) {
>> +		dev_err(&pdev->dev, "could not get clk: %ld\n",
>> +			PTR_ERR(dev->clk));
>> +		return PTR_ERR(dev->clk);
>> +	}
>> +
>> +	/* Request ioarea */
>> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +	base = devm_ioremap_resource(&pdev->dev, mem);
>> +	if (IS_ERR(base))
>> +		return PTR_ERR(base);
>> +
>> +	dev->i2s_regmap = devm_regmap_init_mmio(&pdev->dev, base,
>> +				&bcm2835_regmap_config);
>> +	if (IS_ERR(dev->i2s_regmap))
>> +		return PTR_ERR(dev->i2s_regmap);
>> +
>> +	/* Set the DMA address - we have to parse DT ourselves */
>> +	addr = of_get_address(pdev->dev.of_node, 0, NULL, NULL);
>> +	if (!addr) {
>> +		dev_err(&pdev->dev, "could not get DMA-register address\n");
>> +		return -EINVAL;
>> +	}
>> +	dma_base = be32_to_cpup(addr);
>
> Why aren't we just using mem->start like before?  That seems like an
> independent change that should be justified on its own.  I'd be ready to
> ack the patch if that change is removed.
>

Problem is that we need the VC4 bus-address (0x7e203000),
which is the actual <reg> value from the device tree without any
mapping.

Not the ARM MMU visible address mappings that mem->start provides
(typically 0x20203000 or 0x3f203000 for bcm2836)

Nor the mapped address (base) available in the kernel (typically
0xdc......).

This is the only way to get it correctly and has been done the same way
with spi-bcm2835.


From christoffer.dall at linaro.org  Mon Feb  8 04:09:50 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 8 Feb 2016 13:09:50 +0100
Subject: [PATCH v11 06/21] KVM: ARM64: Add access handler for PMCEID0 and
 PMCEID1 register
In-Reply-To: <1454656456-11640-7-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
 <1454656456-11640-7-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <20160208120950.GC620@cbox>

On Fri, Feb 05, 2016 at 03:14:01PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
> 
> Add access handler which gets host value of PMCEID0 or PMCEID1 when
> guest access these registers. Writing action to PMCEID0 or PMCEID1 is
> UNDEFINED.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> ---
>  arch/arm64/kvm/sys_regs.c | 29 +++++++++++++++++++++++++----
>  1 file changed, 25 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index fc60041..06257e2 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -492,6 +492,27 @@ static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>  	return true;
>  }
>  
> +static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> +			  const struct sys_reg_desc *r)
> +{
> +	u64 pmceid;
> +
> +	if (!kvm_arm_pmu_v3_ready(vcpu))
> +		return trap_raz_wi(vcpu, p, r);
> +
> +	if (p->is_write)
> +		return false;

Isn't it really a BUG_ON(p->is_write) ?

Presumably a guest write to these registers will raise an undefined
exception in EL0/1 and we don't get here by any other path than the trap
handler, do we?

Otherwise looks good to me.

Thanks,
-Christoffer


From catalin.marinas at arm.com  Mon Feb  8 04:14:31 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 8 Feb 2016 12:14:31 +0000
Subject: [PATCH v5sub2 0/8] arm64: implement virtual KASLR
In-Reply-To: <CAGXu5j+JpwRrVy1b_h+LJ4sCzsT7BV9RdcD0CvR-4aVJQhCpvg@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <CAKv+Gu-AhLcatkDsQVeoFGJ+pTEwaW1Hy9M-fY1-VWvRc_E47w@mail.gmail.com>
 <20160205173248.GJ6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_v1sXM7sivz+Uu86ZG3=Th7wqqh7M1N8wF7Ess4NdTZQ@mail.gmail.com>
 <CAGXu5j+JpwRrVy1b_h+LJ4sCzsT7BV9RdcD0CvR-4aVJQhCpvg@mail.gmail.com>
Message-ID: <20160208121430.GL6076@e104818-lin.cambridge.arm.com>

On Fri, Feb 05, 2016 at 12:42:30PM -0800, Kees Cook wrote:
> On Fri, Feb 5, 2016 at 9:38 AM, Ard Biesheuvel
> <ard.biesheuvel at linaro.org> wrote:
> > On 5 February 2016 at 18:32, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> I'm still trying to get my head around how we merge those. Since I
> >> assume akpm will push them during the merging window, part of your code
> >> cannot be tested before.
> >
> > Actually, my original idea was for akpm to take them as a late merge
> > after rebasing to -rc1, since they touch a variety of architectures,
> > but I am not sure if that came across.
> >
> > You could always take the series through your tree instead, I guess?
> 
> Traditionally akpm will de-duplicate patches he's carrying that appear
> in another tree. I think it should be okay to carry them in both
> places. (Though I'm CCing akpm just to see if I'm talking crazy.)

For now, I'll merge this series in the arm64 tree and push it to next:

http://lkml.kernel.org/r/1452007180-27411-1-git-send-email-ard.biesheuvel at linaro.org

If there are any objections, I can drop the patches and do the
BUILDTIME_EXTABLE_SORT disabling trick until they end up in mainline.

-- 
Catalin


From lkp at intel.com  Mon Feb  8 04:14:08 2016
From: lkp at intel.com (kbuild test robot)
Date: Mon, 8 Feb 2016 20:14:08 +0800
Subject: [PATCH V4 2/2] regulator: mt6323: Add support for MT6323 regulator
In-Reply-To: <1453896059-44589-2-git-send-email-blogic@openwrt.org>
Message-ID: <201602082052.nbLmVvYd%fengguang.wu@intel.com>

Hi Chen,

[auto build test ERROR on regulator/for-next]
[also build test ERROR on v4.5-rc3 next-20160208]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/John-Crispin/regulator-Add-document-for-MT6323-regulator/20160127-200434
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
config: frv-allmodconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=frv 

All errors (new ones prefixed by >>):

>> drivers/regulator/mt6323-regulator.c:15:40: fatal error: linux/mfd/mt6323/registers.h: No such file or directory
    #include <linux/mfd/mt6323/registers.h>
                                           ^
   compilation terminated.

vim +15 drivers/regulator/mt6323-regulator.c

     9	
    10	#include <linux/module.h>
    11	#include <linux/of.h>
    12	#include <linux/platform_device.h>
    13	#include <linux/regmap.h>
    14	#include <linux/mfd/mt6397/core.h>
  > 15	#include <linux/mfd/mt6323/registers.h>
    16	#include <linux/regulator/driver.h>
    17	#include <linux/regulator/machine.h>
    18	#include <linux/regulator/mt6323-regulator.h>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 42503 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160208/c1aaa3e3/attachment-0001.obj>

From linux at arm.linux.org.uk  Mon Feb  8 04:18:11 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Feb 2016 12:18:11 +0000
Subject: [PATCH 1/2] ARM: remove bzImage target
In-Reply-To: <1454907899-32101-1-git-send-email-yamada.masahiro@socionext.com>
References: <1454907899-32101-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <20160208121810.GL10826@n2100.arm.linux.org.uk>

On Mon, Feb 08, 2016 at 02:04:58PM +0900, Masahiro Yamada wrote:
> bzImage has been just an alias for zImage for more than a decade.
> It would not hurt to delete it.

NAK.  bzImage exists for compatibility with build scripts, removing it
is likely to break people's scripts.  It does no harm to keep it.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From kernel at martin.sperl.org  Mon Feb  8 04:20:12 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Mon, 8 Feb 2016 13:20:12 +0100
Subject: [PATCH V4 2/7] clk: bcm2835: clamp clock divider to highest
 integer only
In-Reply-To: <87k2mo3tnm.fsf@eliezer.anholt.net>
References: <1452867667-2447-1-git-send-email-kernel@martin.sperl.org>
 <1452867667-2447-3-git-send-email-kernel@martin.sperl.org>
 <87k2mo3tnm.fsf@eliezer.anholt.net>
Message-ID: <56B887FC.5070001@martin.sperl.org>



On 02.02.2016 00:19, Eric Anholt wrote:
> kernel at martin.sperl.org writes:
>
>> From: Martin Sperl <kernel at martin.sperl.org>
>>
>> The clock divider calculation right now clamps the
>> divider to the highest possible fractional divider.
>> So typically (BIT(div_int_bits) - 1) + 4095 / 4096.
>>
>> As the fractional clock divider is alterating between
>> (Fosc / div_int) and (Fosc / (div_int + 1))
>> the divider will overflow for the (div_int + 1) case.
>> As with the "underflow" case we have seen for (div < 2),
>> we can assume that the same applies on the upper limit
>> as well.
>>
>> So this patch will instead clamp to the divider to the
>> max of (BIT(div_int_bits) - 1)
>
> Looks like this restriction might be necessary, though it's not quite
> spelled out in the docs.
>
> This also needs to be conditional on it being a MASH clock, and the
> limit on the divider changes in the same way based on the mash number as
> for the minimum.
>
See:
[PATCH V4 7/7] clk: bcm2835: apply limits on dividers to MASH mode.
That "downgrades" to lower mash values in case we are out of range.
Also note that it applies to MASH=1 as well.

If the other (non mash-supported) clocks support this "better" (if it 
works), then we can make that change only apply to mash enabled clocks.
But so far I doubt it works correctly so I have applied those limits to
all clocks.


From arnd at arndb.de  Mon Feb  8 04:20:40 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 08 Feb 2016 13:20:40 +0100
Subject: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <2530828.WgKqLzsO0l@wuerfel>

On Monday 08 February 2016 10:11:38 Antoine Tenart wrote:
> index 000000000000..3e3080fa45e4
> --- /dev/null
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> +	model = "Annapurna Labs Alpine v2";
> +	compatible = "al,alpine-v2";
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	aliases {
> +		serial0 = &uart0;
> +		serial1 = &uart1;
> +		serial2 = &uart2;
> +		serial3 = &uart3;
> +	};

Move the aliases to the .dts files and drop the ones that are disabled.

> +
> +		pcie-internal at 0xfbc00000 {

make this

		pci at fbc00000 {

> +			compatible = "pci-host-ecam-generic";
> +			device_type = "pci";
> +			#size-cells = <2>;
> +			#address-cells = <3>;
> +			#interrupt-cells = <1>;
> +			reg = <0x0 0xfbc00000 0x0 0x100000>;
> +			interrupt-map-mask = <0xf800 0 0 7>;
> +			/* add legacy interrupts for SATA only */
> +			interrupt-map = <0x4000 0 0 1 &gic 0 53 4>,
> +					<0x4800 0 0 1 &gic 0 54 4>;

What's wrong with the other IRQs? Not connected?

> +
> +		uart0: uart at fd883000 {

			serial at fd883000


Almost all devices are in the 0xfd000000 range. Could this be a bus in the
SoC that has all the devices attached to it? Maybe use a "ranges" property
to reflect that. In doubt, use the register numbers from the data sheet if you
have one.

	Arnd


From arnd at arndb.de  Mon Feb  8 04:24:24 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 08 Feb 2016 13:24:24 +0100
Subject: [PATCH RFC] Add cpufreq support
In-Reply-To: <20160207122212.GA3808@vireshk>
References: <56B4D4BE.2040008@free.fr> <3308645.nrPBoahQ2V@wuerfel>
 <20160207122212.GA3808@vireshk>
Message-ID: <2425296.hvcP5NDLXy@wuerfel>

On Sunday 07 February 2016 17:52:12 Viresh Kumar wrote:
> On 05-02-16, 23:24, Arnd Bergmann wrote:
> > We no longer call platform_device_register_simple() from platform code, at least
> > for new platforms, and we should probably remove the code from the existing
> > platforms that still do it. I forget what the replacement was, but I'm not
> > going to take this version. Viresh should be able to help you do it the right
> > way.
> 
> We thought initially that opp-v2's compatible string can be used to probe the
> drivers, but that was denied later and all we do today is add platform devices
> for cpufreq.
> 
> What do you have in mind Arnd ?
> 

Whatever you want to do in drivers/cpufreq that keeps this out of arch/arm/

As I have said numerous times, there is absolutely no point in having a
platform device for this, but if you insist on having one, just write one
file that has an early_initcall() function and move all the code creating
those devices in there for platforms using DT, e.g. by matching on the
root compatible string the same way the platform code does today.

For new platforms, please come up with a way to not need that and create
a generic binding that anyone can follow.

	Arnd


From christoffer.dall at linaro.org  Mon Feb  8 04:26:43 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 8 Feb 2016 13:26:43 +0100
Subject: [PATCH v11 16/21] KVM: ARM64: Add PMU overflow interrupt routing
In-Reply-To: <1454656456-11640-17-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
 <1454656456-11640-17-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <20160208122643.GD620@cbox>

On Fri, Feb 05, 2016 at 03:14:11PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
> 
> When calling perf_event_create_kernel_counter to create perf_event,
> assign a overflow handler. Then when the perf event overflows, set the
> corresponding bit of guest PMOVSSET register. If this counter is enabled
> and its interrupt is enabled as well, kick the vcpu to sync the
> interrupt.
> 
> On VM entry, if there is counter overflowed, inject the interrupt with
> the level set to 1. Otherwise, inject the interrupt with the level set
> to 0.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
> Reviewed-by: Andrew Jones <drjones at redhat.com>
> ---
>  arch/arm/kvm/arm.c    |  2 ++
>  include/kvm/arm_pmu.h |  2 ++
>  virt/kvm/arm/pmu.c    | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
>  3 files changed, 53 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index dda1959..f54264c 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -28,6 +28,7 @@
>  #include <linux/sched.h>
>  #include <linux/kvm.h>
>  #include <trace/events/kvm.h>
> +#include <kvm/arm_pmu.h>
>  
>  #define CREATE_TRACE_POINTS
>  #include "trace.h"
> @@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  		 * non-preemptible context.
>  		 */
>  		preempt_disable();
> +		kvm_pmu_flush_hwstate(vcpu);
>  		kvm_timer_flush_hwstate(vcpu);
>  		kvm_vgic_flush_hwstate(vcpu);
>  
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 1f4bfa2..44a3c75 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -44,6 +44,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
>  void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
>  void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> @@ -67,6 +68,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
>  static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
> +static inline void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
>  static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index c8ea825..5f983cb 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -21,6 +21,7 @@
>  #include <linux/perf_event.h>
>  #include <asm/kvm_emulate.h>
>  #include <kvm/arm_pmu.h>
> +#include <kvm/arm_vgic.h>
>  
>  /**
>   * kvm_pmu_get_counter_value - get PMU counter value
> @@ -180,6 +181,52 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
>  }
>  
>  /**
> + * kvm_pmu_flush_hwstate - flush pmu state to cpu
> + * @vcpu: The vcpu pointer
> + *
> + * Inject virtual PMU IRQ if IRQ is pending for this cpu.
> + */
> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
> +{
> +	struct kvm_pmu *pmu = &vcpu->arch.pmu;
> +	u64 overflow;
> +
> +	if (!kvm_arm_pmu_v3_ready(vcpu))
> +		return;
> +
> +	if (!(vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E))
> +		return;

are we modeling the PMU interrupt as level-triggered?

In that case, shouldn't we lower the interrupt line on flush when
PMCR_EL0.E == 0 ?


Thanks,
-Christoffer


From architt at codeaurora.org  Mon Feb  8 04:26:27 2016
From: architt at codeaurora.org (Archit Taneja)
Date: Mon, 8 Feb 2016 17:56:27 +0530
Subject: [PATCH v7 0/5] Add mipi dsi support for rk3288
In-Reply-To: <5060470.dfeHX20DRa@phil>
References: <1452053038-32098-1-git-send-email-zyw@rock-chips.com>
 <56B869F4.6090507@codeaurora.org> <5060470.dfeHX20DRa@phil>
Message-ID: <56B88973.6000701@codeaurora.org>



On 02/08/2016 04:22 PM, Heiko Stuebner wrote:
> Hi Archit,
>
> Am Montag, 8. Februar 2016, 15:42:04 schrieb Archit Taneja:
>> On 01/06/2016 09:33 AM, Chris Zhong wrote:
>>> The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
>>> IP. This series adds support for a Synopsys DesignWare MIPI DSI host
>>> controller DRM driver.
>>>
>>> The MIPI DSI feature is tested on rk3288 evb board, backport them to
>>> chrome os kernel chrome_v3.14, and it can display normally.
>>>
>>> This patchset is base on the patchset from Ying.liu at freescale.com.
>>> <http://www.spinics.net/lists/dri-devel/msg77181.html>
>>>
>>> According to the suggestion from Thierry, I have get rid of the bridge,
>>> and register the encoder & connecter in drm/rockchip/dw-mipi-dsi.c.
>>
>> I've raised this question too late, but what was the reason to not
>> implement the DSI block as a bridge driver?
>
> There seems to always be some sort of contention about those being bridge
> drivers - I think I remember Thierry speaking up about that. But I don't
> remember if any different solution was suggested.

Well, yeah, these can be considered as encoders too. I guess it's just
not very common to have encoder drivers outside of the kms driver, in
comparison to bridges.

The advantage of having such shared IPs as bridges is that they can be
used by kms drivers that already implement an encoder in the display
chain.

>
> Also as we have seen with current shared IPs (dw-hdmi + analogix-dp) there
> are always implementation-specific parts and deciding which needs to land
> where is difficult without the secondary user present.

Yeah, I can imagine it being hard to separate out the implementation
specific and core parts.

>
> The first iterations where using a bridge-driver-base for it but I guess it
> was to much hassle without seeing another user on the horizon.
>
>
>> The drm/hisilicon IP seems to use a very similar DSI Designware IP (the
>> register offsets seems to be the same). There is a good potential of
>> re-use here by different kms drivers here the way it's already done for
>> DW HDMI and the analogix DP driver that's in review process.
>
> I guess, the second user now gets to do the generalization ;-)

If not the generalization, then at least an assessment if it's worth the
effort or not :)

Archit

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation


From dietmar.eggemann at arm.com  Mon Feb  8 04:28:39 2016
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Mon, 8 Feb 2016 12:28:39 +0000
Subject: [PATCH v3 4/6] arm64: Enable dynamic CPU capacity initialization
In-Reply-To: <1454500799-18451-5-git-send-email-juri.lelli@arm.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <1454500799-18451-5-git-send-email-juri.lelli@arm.com>
Message-ID: <56B889F7.306@arm.com>

On 03/02/16 11:59, Juri Lelli wrote:
> Define arch_wants_init_cpu_capacity() to return true; so that
> cpufreq_init_cpu_capacity() can go ahead and profile CPU capacities
> at boot time.

[...]

>  
> +bool arch_wants_init_cpu_capacity(void)
> +{
> +	return true;

Isn't this a little bit too simple? Not every ARM/ARM64 platform is a
heterogeneous one.

You could add code to compare the cpu node 'compatible' properties
(required) and only return true if they differ, which would let you
detect uarch based heterogeneity.

In case of max. frequency based heterogeneity (clusters consisting of
same cpu types but running at different max. frequency), you're at the
mercy of cpu node 'clock-frequency' properties (optional).
We might argue that for these platforms, providing cpu node
'clock-frequency' properties is necessary.
The 'struct cpu_efficiency table_efficiency[]' based approach in ARM
already faces this problem.

> +}
> +
>  static int __init get_cpu_for_node(struct device_node *node)
>  {
>  	struct device_node *cpu_node;
> 


From christoffer.dall at linaro.org  Mon Feb  8 04:29:57 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 8 Feb 2016 13:29:57 +0100
Subject: [PATCH v11 19/21] KVM: ARM64: Add a new feature bit for PMUv3
In-Reply-To: <1454656456-11640-20-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
 <1454656456-11640-20-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <20160208122957.GE620@cbox>

On Fri, Feb 05, 2016 at 03:14:14PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
> 
> To support guest PMUv3, use one bit of the VCPU INIT feature array.
> Initialize the PMU when initialzing the vcpu with that bit and PMU
> overflow interrupt set.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> Acked-by: Peter Maydell <peter.maydell at linaro.org>
> Reviewed-by: Andrew Jones <drjones at redhat.com>
> ---
> CC: Peter Maydell <peter.maydell at linaro.org>
> ---
>  Documentation/virtual/kvm/api.txt | 2 ++
>  arch/arm64/include/asm/kvm_host.h | 2 +-
>  arch/arm64/include/uapi/asm/kvm.h | 1 +
>  arch/arm64/kvm/reset.c            | 3 +++
>  include/kvm/arm_pmu.h             | 2 ++
>  include/uapi/linux/kvm.h          | 1 +
>  virt/kvm/arm/pmu.c                | 9 +++++++++
>  7 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 07e4cdf..9684f8d 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -2577,6 +2577,8 @@ Possible features:
>  	  Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
>  	- KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 for the CPU.
>  	  Depends on KVM_CAP_ARM_PSCI_0_2.
> +	- KVM_ARM_VCPU_PMU_V3: Emulate PMUv3 for the CPU.
> +	  Depends on KVM_CAP_ARM_PMU_V3.
>  
>  
>  4.83 KVM_ARM_PREFERRED_TARGET
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 6bab7fb..cb220b7 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -40,7 +40,7 @@
>  
>  #define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
>  
> -#define KVM_VCPU_MAX_FEATURES 3
> +#define KVM_VCPU_MAX_FEATURES 4
>  
>  int __attribute_const__ kvm_target_cpu(void);
>  int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 2d4ca4b..6aedbe3 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -94,6 +94,7 @@ struct kvm_regs {
>  #define KVM_ARM_VCPU_POWER_OFF		0 /* CPU is started in OFF state */
>  #define KVM_ARM_VCPU_EL1_32BIT		1 /* CPU running a 32bit VM */
>  #define KVM_ARM_VCPU_PSCI_0_2		2 /* CPU uses PSCI v0.2 */
> +#define KVM_ARM_VCPU_PMU_V3		3 /* Support guest PMUv3 */
>  
>  struct kvm_vcpu_init {
>  	__u32 target;
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index dfbce78..cf4f28a 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
>  	case KVM_CAP_GUEST_DEBUG_HW_WPS:
>  		r = get_num_wrps();
>  		break;
> +	case KVM_CAP_ARM_PMU_V3:
> +		r = kvm_arm_support_pmu_v3();
> +		break;
>  	case KVM_CAP_SET_GUEST_DEBUG:
>  		r = 1;
>  		break;
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index d73cb97..5f86e1d 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -51,6 +51,7 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>  				    u64 select_idx);
> +bool kvm_arm_support_pmu_v3(void);
>  #else
>  struct kvm_pmu {
>  };
> @@ -77,6 +78,7 @@ static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
>  						  u64 data, u64 select_idx) {}
> +static inline bool kvm_arm_support_pmu_v3(void) { return false; }
>  #endif
>  
>  #endif
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 9da9051..dc16d30 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -850,6 +850,7 @@ struct kvm_ppc_smmu_info {
>  #define KVM_CAP_IOEVENTFD_ANY_LENGTH 122
>  #define KVM_CAP_HYPERV_SYNIC 123
>  #define KVM_CAP_S390_RI 124
> +#define KVM_CAP_ARM_PMU_V3 125
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index 6b525df..2467d62 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -384,3 +384,12 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>  
>  	pmc->perf_event = event;
>  }
> +
> +bool kvm_arm_support_pmu_v3(void)
> +{
> +	/* Check if HW_PERF_EVENTS are supported by checking the number of
> +	 * hardware performance counters. This could ensure physical PMU and
> +	 * PERF_EVENT driver existing.
> +	 */

nit: coding style, opening comment block should be on its own line

I don't understand the last sentence.  Do you mean: "This ensures the
presence of a physical PMU and that CONFIG_PERF_EVENT is selected." ?

Thanks,
-Christoffer


From viresh.kumar at linaro.org  Mon Feb  8 04:31:12 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 8 Feb 2016 18:01:12 +0530
Subject: [PATCH RFC] Add cpufreq support
In-Reply-To: <2425296.hvcP5NDLXy@wuerfel>
References: <56B4D4BE.2040008@free.fr> <3308645.nrPBoahQ2V@wuerfel>
 <20160207122212.GA3808@vireshk> <2425296.hvcP5NDLXy@wuerfel>
Message-ID: <20160208123111.GE8294@vireshk>

On 08-02-16, 13:24, Arnd Bergmann wrote:
> Whatever you want to do in drivers/cpufreq that keeps this out of arch/arm/
> 
> As I have said numerous times, there is absolutely no point in having a
> platform device for this, but if you insist on having one

No, I don't insist on that. I just hate it.

But the problem was that we never agreed to a way, by which we could
have probed cpufreq-dt. We were talking about compatible string from
'opp-v2' earlier, but that was soon discarded.

> just write one
> file that has an early_initcall() function and move all the code creating
> those devices in there for platforms using DT, e.g. by matching on the
> root compatible string the same way the platform code does today.
>
> For new platforms, please come up with a way to not need that and create
> a generic binding that anyone can follow.

Do you have any suggestions ?
- We aren't allowed to (re)use opp-v2 compatibility string
- We can't add a DT node for virtual device - cpufreq

What else can be done ?

-- 
viresh


From arnd at arndb.de  Mon Feb  8 04:34:13 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 08 Feb 2016 13:34:13 +0100
Subject: [PATCH RFC] Add cpufreq support
In-Reply-To: <20160208123111.GE8294@vireshk>
References: <56B4D4BE.2040008@free.fr> <2425296.hvcP5NDLXy@wuerfel>
 <20160208123111.GE8294@vireshk>
Message-ID: <45004963.Im3DmqJ5ez@wuerfel>

On Monday 08 February 2016 18:01:12 Viresh Kumar wrote:
> On 08-02-16, 13:24, Arnd Bergmann wrote:
> > Whatever you want to do in drivers/cpufreq that keeps this out of arch/arm/
> > 
> > As I have said numerous times, there is absolutely no point in having a
> > platform device for this, but if you insist on having one
> 
> No, I don't insist on that. I just hate it.
> 
> But the problem was that we never agreed to a way, by which we could
> have probed cpufreq-dt. We were talking about compatible string from
> 'opp-v2' earlier, but that was soon discarded.
> 
> > just write one
> > file that has an early_initcall() function and move all the code creating
> > those devices in there for platforms using DT, e.g. by matching on the
> > root compatible string the same way the platform code does today.
> >
> > For new platforms, please come up with a way to not need that and create
> > a generic binding that anyone can follow.
> 
> Do you have any suggestions ?
> - We aren't allowed to (re)use opp-v2 compatibility string
> - We can't add a DT node for virtual device - cpufreq
> 
> What else can be done ?

Maybe add a opp-v3 compatible string? I really don't care what you
match on, as long we don't need any code in arch/arm/ to create a
device we don't need.

Don't add the device to DT, we really don't want that. If there
is too much opposition to looking at the cpus nodes in the initcall,
start with a whitelist for known machines, that at least keeps the
existing behavior.

	Arnd


From m.szyprowski at samsung.com  Mon Feb  8 04:38:11 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Mon, 08 Feb 2016 13:38:11 +0100
Subject: [PATCH] drm/exynos: dp: Fix panel and bridge lookup logic
In-Reply-To: <56B88418.7090106@osg.samsung.com>
References: <1454080171-23769-1-git-send-email-javier@osg.samsung.com>
 <56B88418.7090106@osg.samsung.com>
Message-ID: <56B88C33.8060808@samsung.com>

Hi Javier,

On 2016-02-08 13:03, Javier Martinez Canillas wrote:
> Hello Inki,
>
> On 01/29/2016 12:09 PM, Javier Martinez Canillas wrote:
>> Commit a9fa852886fd ("drm/exynos: dp: add of_graph dt binding support
>> for panel") made the Exynos DP DT binding more consistent since the OF
>> graph could be used to lookup either a panel or a bridge device node.
>>
>> Before that commit, a panel would be looked up using a phandle and a
>> bridge using the OF graph which made the DT binding not consistent.
>>
>> But the patch broke the later case since not finding a panel dev node
>> would cause the driver's to do a probe deferral instead of attempting
>> to lookup a bridge device node associated with the remote endpoint.
>>
>> So instead of returning a -EPROBE_DEFER if a panel is not found, check
>> if there's a bridge and only do a probe deferral if both aren't found.
>>
>> Fixes: a9fa852886fd ("drm/exynos: dp: add of_graph dt binding support 
>> for panel")
>> Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
>>
>
> Any comments about this patch? It is needed to have display working on
> machines with a bridge chip again so it should be pushed to -rc ASAP.

Please check v4.5-rc3, this patch is already merged there.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From christoffer.dall at linaro.org  Mon Feb  8 04:40:59 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 8 Feb 2016 13:40:59 +0100
Subject: [PATCH v11 20/21] KVM: ARM: Introduce per-vcpu kvm device controls
In-Reply-To: <1454656456-11640-21-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
 <1454656456-11640-21-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <20160208124059.GF620@cbox>

On Fri, Feb 05, 2016 at 03:14:15PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
> 
> In some cases it needs to get/set attributes specific to a vcpu and so
> needs something else than ONE_REG.
> 
> Let's copy the KVM_DEVICE approach, and define the respective ioctls
> for the vcpu file descriptor.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> Reviewed-by: Andrew Jones <drjones at redhat.com>
> Acked-by: Peter Maydell <peter.maydell at linaro.org>
> ---
> CC: Peter Maydell <peter.maydell at linaro.org>

strange cc section here?
> ---
>  Documentation/virtual/kvm/api.txt          | 10 +++---
>  Documentation/virtual/kvm/devices/vcpu.txt |  8 +++++
>  arch/arm/kvm/arm.c                         | 55 ++++++++++++++++++++++++++++++
>  arch/arm64/kvm/reset.c                     |  1 +
>  include/uapi/linux/kvm.h                   |  1 +
>  5 files changed, 71 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/virtual/kvm/devices/vcpu.txt
> 
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 9684f8d..cb2ef0b 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -2507,8 +2507,9 @@ struct kvm_create_device {
>  
>  4.80 KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR
>  
> -Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device
> -Type: device ioctl, vm ioctl
> +Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device,
> +  KVM_CAP_VCPU_ATTRIBUTES for vcpu device
> +Type: device ioctl, vm ioctl, vcpu ioctl
>  Parameters: struct kvm_device_attr
>  Returns: 0 on success, -1 on error
>  Errors:
> @@ -2533,8 +2534,9 @@ struct kvm_device_attr {
>  
>  4.81 KVM_HAS_DEVICE_ATTR
>  
> -Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device
> -Type: device ioctl, vm ioctl
> +Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device,
> +  KVM_CAP_VCPU_ATTRIBUTES for vcpu device
> +Type: device ioctl, vm ioctl, vcpu ioctl
>  Parameters: struct kvm_device_attr
>  Returns: 0 on success, -1 on error
>  Errors:
> diff --git a/Documentation/virtual/kvm/devices/vcpu.txt b/Documentation/virtual/kvm/devices/vcpu.txt
> new file mode 100644
> index 0000000..3cc59c5
> --- /dev/null
> +++ b/Documentation/virtual/kvm/devices/vcpu.txt
> @@ -0,0 +1,8 @@
> +Generic vcpu interface
> +====================================
> +
> +The virtual cpu "device" also accepts the ioctls KVM_SET_DEVICE_ATTR,
> +KVM_GET_DEVICE_ATTR, and KVM_HAS_DEVICE_ATTR. The interface uses the same struct
> +kvm_device_attr as other devices, but targets VCPU-wide settings and controls.
> +
> +The groups and attributes per virtual cpu, if any, are architecture specific.
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index d2c2cc3..34d7395 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -826,11 +826,51 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu,
>  	return 0;
>  }
>  
> +static int kvm_arm_vcpu_set_attr(struct kvm_vcpu *vcpu,
> +				 struct kvm_device_attr *attr)
> +{
> +	int ret = -ENXIO;
> +
> +	switch (attr->group) {
> +	default:
> +		break;
> +	}
> +
> +	return ret;
> +}
> +
> +static int kvm_arm_vcpu_get_attr(struct kvm_vcpu *vcpu,
> +				 struct kvm_device_attr *attr)
> +{
> +	int ret = -ENXIO;
> +
> +	switch (attr->group) {
> +	default:
> +		break;
> +	}
> +
> +	return ret;
> +}
> +
> +static int kvm_arm_vcpu_has_attr(struct kvm_vcpu *vcpu,
> +				 struct kvm_device_attr *attr)
> +{
> +	int ret = -ENXIO;
> +
> +	switch (attr->group) {
> +	default:
> +		break;
> +	}
> +
> +	return ret;
> +}
> +
>  long kvm_arch_vcpu_ioctl(struct file *filp,
>  			 unsigned int ioctl, unsigned long arg)
>  {
>  	struct kvm_vcpu *vcpu = filp->private_data;
>  	void __user *argp = (void __user *)arg;
> +	struct kvm_device_attr attr;
>  
>  	switch (ioctl) {
>  	case KVM_ARM_VCPU_INIT: {
> @@ -873,6 +913,21 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>  			return -E2BIG;
>  		return kvm_arm_copy_reg_indices(vcpu, user_list->reg);
>  	}
> +	case KVM_SET_DEVICE_ATTR: {
> +		if (copy_from_user(&attr, argp, sizeof(attr)))
> +			return -EFAULT;
> +		return kvm_arm_vcpu_set_attr(vcpu, &attr);
> +	}
> +	case KVM_GET_DEVICE_ATTR: {
> +		if (copy_from_user(&attr, argp, sizeof(attr)))
> +			return -EFAULT;
> +		return kvm_arm_vcpu_get_attr(vcpu, &attr);
> +	}
> +	case KVM_HAS_DEVICE_ATTR: {
> +		if (copy_from_user(&attr, argp, sizeof(attr)))
> +			return -EFAULT;
> +		return kvm_arm_vcpu_has_attr(vcpu, &attr);
> +	}

do we share the ioctl number space across device, VM, and VCPU file
descriptors?  If not, don't these need to be specifically defined as
VCPU ioctl numbers in kvm.h ?

Thanks,
-Christoffer

>  	default:
>  		return -EINVAL;
>  	}
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index cf4f28a..9677bf0 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -81,6 +81,7 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
>  		r = kvm_arm_support_pmu_v3();
>  		break;
>  	case KVM_CAP_SET_GUEST_DEBUG:
> +	case KVM_CAP_VCPU_ATTRIBUTES:
>  		r = 1;
>  		break;
>  	default:
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index dc16d30..50f44a2 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -851,6 +851,7 @@ struct kvm_ppc_smmu_info {
>  #define KVM_CAP_HYPERV_SYNIC 123
>  #define KVM_CAP_S390_RI 124
>  #define KVM_CAP_ARM_PMU_V3 125
> +#define KVM_CAP_VCPU_ATTRIBUTES 126
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> -- 
> 2.0.4
> 
> 


From viresh.kumar at linaro.org  Mon Feb  8 04:41:27 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 8 Feb 2016 18:11:27 +0530
Subject: [PATCH RFC] Add cpufreq support
In-Reply-To: <45004963.Im3DmqJ5ez@wuerfel>
References: <56B4D4BE.2040008@free.fr> <2425296.hvcP5NDLXy@wuerfel>
 <20160208123111.GE8294@vireshk> <45004963.Im3DmqJ5ez@wuerfel>
Message-ID: <20160208124127.GF8294@vireshk>

On 08-02-16, 13:34, Arnd Bergmann wrote:
> Maybe add a opp-v3 compatible string?

How will that help?

The problem was that the compatibility string of "opp-v2" specifies
the way we need to parse the bindings and shouldn't be (ab)used to
probe a driver like cpufreq-dt. And so we got stuck.

> I really don't care what you
> match on, as long we don't need any code in arch/arm/ to create a
> device we don't need.

Sure.

> Don't add the device to DT, we really don't want that.

I agree.

> If there
> is too much opposition to looking at the cpus nodes in the initcall,

I didn't get this one, what can we do by looking at CPUs nodes ?

> start with a whitelist for known machines, that at least keeps the
> existing behavior.

That can be a valid solution I would say, but that separate driver
(cpufreq-dt-device.c) needs to be changed for every new platform.

-- 
viresh


From gabriele.paoloni at huawei.com  Mon Feb  8 04:41:01 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Mon, 8 Feb 2016 12:41:01 +0000
Subject: [RFC PATCH v2 0/3] Add ACPI support for HiSilicon PCIe Host
 Controllers
Message-ID: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>

From: gabriele paoloni <gabriele.paoloni at huawei.com>

This patchset adds ACPI support for the HiSilicon Hip05/Hip06 SoC PCIe controllers
The four patches respectively:
        - re-architect the current HiSilicon driver to make it scalable to the
          new ACPI quirks
        - rework the current HiSilicon driver to make it ECAM compliant
        - adds the HiSilicon ACPI specific quirks.

   This patchset  is based on
   https://github.com/semihalf-nowicki-tomasz/linux.git
   branch pci-acpi-v4

Changes v1 -> v2: removed the ACPI quirks dependency on Designware framework

gabriele paoloni (3):
  PCI: hisi: re-architect Hip05/Hip06 controllers driver to preapare for
    ACPI
  PCI: hisi: Make the HiSilicon PCIe host controller ECAM compliant
  PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

 MAINTAINERS                         |   3 +
 drivers/pci/host/Kconfig            |   8 ++
 drivers/pci/host/Makefile           |   3 +-
 drivers/pci/host/pcie-designware.c  |   4 +-
 drivers/pci/host/pcie-designware.h  |   2 +
 drivers/pci/host/pcie-hisi-acpi.c   | 188 ++++++++++++++++++++++++++++++++++++
 drivers/pci/host/pcie-hisi-common.c |  73 ++++++++++++++
 drivers/pci/host/pcie-hisi.c        | 144 +++++++++++++--------------
 drivers/pci/host/pcie-hisi.h        |  25 +++++
 9 files changed, 367 insertions(+), 83 deletions(-)
 create mode 100644 drivers/pci/host/pcie-hisi-acpi.c
 create mode 100644 drivers/pci/host/pcie-hisi-common.c
 create mode 100644 drivers/pci/host/pcie-hisi.h

-- 
1.9.1




From gabriele.paoloni at huawei.com  Mon Feb  8 04:41:04 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Mon, 8 Feb 2016 12:41:04 +0000
Subject: [RFC PATCH v2 3/3] PCI/ACPI: hisi: Add ACPI support for HiSilicon
 SoCs Host Controllers
In-Reply-To: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
Message-ID: <1454935264-6076-4-git-send-email-gabriele.paoloni@huawei.com>

From: gabriele paoloni <gabriele.paoloni at huawei.com>

This patch adds specific quirks for PCI config space accessors,
it uses _HID to decide whether to hook pci_ops or not.

Signed-off-by: Dongdong Liu <liudongdong3 at huawei.com>
Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
---
 MAINTAINERS                       |   1 +
 drivers/pci/host/Kconfig          |   8 ++
 drivers/pci/host/Makefile         |   1 +
 drivers/pci/host/pcie-hisi-acpi.c | 188 ++++++++++++++++++++++++++++++++++++++
 drivers/pci/host/pcie-hisi.c      |   2 -
 drivers/pci/host/pcie-hisi.h      |   2 +
 6 files changed, 200 insertions(+), 2 deletions(-)
 create mode 100644 drivers/pci/host/pcie-hisi-acpi.c

diff --git a/MAINTAINERS b/MAINTAINERS
index d69f436..f184c3e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8412,6 +8412,7 @@ F:	Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
 F:	drivers/pci/host/pcie-hisi.h
 F:	drivers/pci/host/pcie-hisi.c
 F:	drivers/pci/host/pcie-hisi-common.c
+F:	drivers/pci/host/pcie-hisi-acpi.c
 
 PCIE DRIVER FOR QUALCOMM MSM
 M:     Stanimir Varbanov <svarbanov at mm-sol.com>
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 75a6054..65b1add 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -181,6 +181,14 @@ config PCI_HISI
 	  Say Y here if you want PCIe controller support on HiSilicon
 	  Hip05 and Hip06 SoCs
 
+config PCI_HISI_ACPI
+	depends on ACPI
+	bool "HiSilicon Hip05 and Hip06 SoCs ACPI PCIe controllers"
+	select ACPI_PCI_HOST_GENERIC
+	help
+	  Say Y here if you want ACPI PCIe controller support on HiSilicon
+	  Hip05 and Hip06 SoCs
+
 config PCIE_QCOM
 	bool "Qualcomm PCIe controller"
 	depends on ARCH_QCOM && OF
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 8c93c0f..57e4379 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -21,4 +21,5 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
 obj-$(CONFIG_PCI_HISI) += pcie-hisi.o pcie-hisi-common.o
+obj-$(CONFIG_PCI_HISI_ACPI) += pcie-hisi-acpi.o pcie-hisi-common.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
diff --git a/drivers/pci/host/pcie-hisi-acpi.c b/drivers/pci/host/pcie-hisi-acpi.c
new file mode 100644
index 0000000..3605260
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi-acpi.c
@@ -0,0 +1,188 @@
+/*
+ * PCIe host controller driver for HiSilicon HipXX SoCs
+ *
+ * Copyright (C) 2016 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Dongdong Liu <liudongdong3 at huawei.com>
+ *         Gabriele Paoloni <gabriele.paoloni at huawei.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.
+ */
+#include <linux/interrupt.h>
+#include <linux/acpi.h>
+#include <linux/ecam.h>
+#include <linux/pci.h>
+#include <linux/pci-acpi.h>
+#include "pcie-hisi.h"
+
+#define GET_PCIE_LINK_STATUS  0x0
+
+/* uuid 6d30f553-836c-408e-b6ad-45bccc957949 */
+const u8 hisi_pcie_acpi_dsm_uuid[] = {
+	0x53, 0xf5, 0x30, 0x6d, 0x6c, 0x83, 0x8e, 0x40,
+	0xb6, 0xad, 0x45, 0xbc, 0xcc, 0x95, 0x79, 0x49
+};
+
+static const struct acpi_device_id hisi_pcie_ids[] = {
+	{"HISI0080", 0},
+	{"", 0},
+};
+
+static int hisi_pcie_get_addr(struct acpi_pci_root *root, const char *name,
+				void __iomem **addr)
+{
+	struct acpi_device *device;
+	u64 base;
+	u64 size;
+	u32 buf[4];
+	int ret;
+
+	device =  root->device;
+	ret = fwnode_property_read_u32_array(&device->fwnode, name,
+					buf, ARRAY_SIZE(buf));
+	if (ret) {
+		dev_err(&device->dev, "can't get %s\n", name);
+		return ret;
+	}
+
+	base = ((u64)buf[0] << 32) | buf[1];
+	size =  ((u64)buf[2] << 32) | buf[3];
+	*addr = devm_ioremap(&device->dev, base, size);
+	if (!(*addr)) {
+		dev_err(&device->dev, "error with ioremap\n");
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+
+static int hisi_pcie_link_up_acpi(struct acpi_pci_root *root)
+{
+	u32 val;
+	struct acpi_device *device;
+	union acpi_object *obj;
+
+	device = root->device;
+	obj = acpi_evaluate_dsm(device->handle,
+		hisi_pcie_acpi_dsm_uuid, 0,
+		GET_PCIE_LINK_STATUS, NULL);
+
+	if (!obj  ||  obj->type != ACPI_TYPE_INTEGER)  {
+		dev_err(&device->dev, "can't get link status from _DSM\n");
+		return 0;
+	}
+	val = obj->integer.value;
+
+	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
+
+}
+
+/*
+ * Retrieve rc_dbi base and size from _DSD
+ * Name (_DSD, Package () {
+ *	ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+ *	Package () {
+ *	Package () {"rc-dbi", Package () { 0x0, 0xb0080000, 0x0, 0x10000 }},
+ *	}
+ *	})
+ */
+static int hisi_pcie_init(struct acpi_pci_root *root)
+{
+	int ret;
+	struct acpi_device *device;
+	void __iomem *reg_base;
+
+	device =  root->device;
+	ret = hisi_pcie_get_addr(root, "rc-dbi", &reg_base);
+	if (ret) {
+		dev_err(&device->dev, "can't get rc-dbi\n");
+		return ret;
+	}
+
+	root->sysdata = reg_base;
+	return 0;
+}
+
+static int hisi_pcie_match(struct pci_mcfg_fixup *fixup,
+			struct acpi_pci_root *root)
+{
+	int ret;
+	struct acpi_device *device;
+
+	device = root->device;
+	ret = acpi_match_device_ids(device, hisi_pcie_ids);
+	if (ret)
+		return 0;
+
+	ret = hisi_pcie_init(root);
+	if (ret)
+		dev_warn(&device->dev, "hisi pcie init fail\n");
+
+	return 1;
+}
+
+static int hisi_pcie_acpi_valid_config(struct acpi_pci_root *root,
+				struct pci_bus *bus, int dev)
+{
+	/* If there is no link, then there is no device */
+	if (bus->number != root->secondary.start) {
+		if (!hisi_pcie_link_up_acpi(root))
+			return 0;
+	}
+
+	/* access only one slot on each root port */
+	if (bus->number == root->secondary.start && dev > 0)
+		return 0;
+
+	/*
+	 * do not read more than one device on the bus directly attached
+	 * to RC's (Virtual Bridge's) DS side.
+	 */
+	if (bus->primary == root->secondary.start && dev > 0)
+		return 0;
+
+	return 1;
+}
+
+static int hisi_pcie_acpi_rd_conf(struct pci_bus *bus, u32 devfn, int where,
+		int size, u32 *val)
+{
+	struct acpi_pci_root *root = bus->sysdata;
+	void __iomem *reg_base = root->sysdata;
+
+	if (hisi_pcie_acpi_valid_config(root, bus, PCI_SLOT(devfn)) == 0)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	if (bus->number == root->secondary.start)
+		return hisi_pcie_common_cfg_read(reg_base, where, size, val);
+
+	return pci_generic_config_read(bus, devfn, where, size, val);
+}
+
+static int hisi_pcie_acpi_wr_conf(struct pci_bus *bus, u32 devfn,
+		int where, int size, u32 val)
+{
+	struct acpi_pci_root *root = bus->sysdata;
+	void __iomem *reg_base = root->sysdata;
+
+	if (hisi_pcie_acpi_valid_config(root, bus, PCI_SLOT(devfn)) == 0)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	if (bus->number == root->secondary.start)
+		return hisi_pcie_common_cfg_write(reg_base, where, size, val);
+
+	return pci_generic_config_write(bus, devfn, where, size, val);
+}
+
+struct pci_ops hisi_pcie_acpi_ops = {
+	.map_bus = pci_mcfg_dev_base,
+	.read = hisi_pcie_acpi_rd_conf,
+	.write = hisi_pcie_acpi_wr_conf,
+};
+
+
+DECLARE_ACPI_MCFG_FIXUP(NULL, hisi_pcie_match, &hisi_pcie_acpi_ops,
+	PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index eb3201a..ed0b0b2 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -23,8 +23,6 @@
 #include "pcie-designware.h"
 #include "pcie-hisi.h"
 
-#define PCIE_LTSSM_LINKUP_STATE				0x11
-#define PCIE_LTSSM_STATE_MASK				0x3F
 #define PCIE_SUBCTRL_SYS_STATE4_REG			0x6818
 #define PCIE_SYS_STATE4						0x31c
 #define PCIE_HIP06_CTRL_OFF					0x1000
diff --git a/drivers/pci/host/pcie-hisi.h b/drivers/pci/host/pcie-hisi.h
index 29e0790..45cf0fd 100644
--- a/drivers/pci/host/pcie-hisi.h
+++ b/drivers/pci/host/pcie-hisi.h
@@ -14,6 +14,8 @@
 #ifndef PCIE_HISI_H_
 #define PCIE_HISI_H_
 
+#define PCIE_LTSSM_LINKUP_STATE				0x11
+#define PCIE_LTSSM_STATE_MASK				0x3F
 
 int hisi_pcie_common_cfg_read(void __iomem *reg_base, int where, int size,
 			      u32 *val);
-- 
1.9.1




From gabriele.paoloni at huawei.com  Mon Feb  8 04:41:02 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Mon, 8 Feb 2016 12:41:02 +0000
Subject: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06 controllers
 driver to preapare for ACPI
In-Reply-To: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
Message-ID: <1454935264-6076-2-git-send-email-gabriele.paoloni@huawei.com>

From: gabriele paoloni <gabriele.paoloni at huawei.com>

re-architect the Hip05/Hip06 host controllers driver to prepare
for the ACPI based driver.
The common functions used also by the ACPI driver have been grouped
into a new "common" file

Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
---
 MAINTAINERS                         |   2 +
 drivers/pci/host/Makefile           |   2 +-
 drivers/pci/host/pcie-hisi-common.c |  73 ++++++++++++++++++++++
 drivers/pci/host/pcie-hisi.c        | 119 +++++++++++-------------------------
 drivers/pci/host/pcie-hisi.h        |  23 +++++++
 5 files changed, 135 insertions(+), 84 deletions(-)
 create mode 100644 drivers/pci/host/pcie-hisi-common.c
 create mode 100644 drivers/pci/host/pcie-hisi.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 30aca4a..d69f436 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8409,7 +8409,9 @@ M:	Gabriele Paoloni <gabriele.paoloni at huawei.com>
 L:	linux-pci at vger.kernel.org
 S:	Maintained
 F:	Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
+F:	drivers/pci/host/pcie-hisi.h
 F:	drivers/pci/host/pcie-hisi.c
+F:	drivers/pci/host/pcie-hisi-common.c
 
 PCIE DRIVER FOR QUALCOMM MSM
 M:     Stanimir Varbanov <svarbanov at mm-sol.com>
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 7b2f20c..8c93c0f 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -20,5 +20,5 @@ obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
-obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
+obj-$(CONFIG_PCI_HISI) += pcie-hisi.o pcie-hisi-common.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
diff --git a/drivers/pci/host/pcie-hisi-common.c b/drivers/pci/host/pcie-hisi-common.c
new file mode 100644
index 0000000..6dfb4c3
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi-common.c
@@ -0,0 +1,73 @@
+/*
+ * PCIe host controller common functions for HiSilicon SoCs
+ *
+ * Copyright (C) 2015 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Zhou Wang <wangzhou1 at hisilicon.com>
+ *         Dacai Zhu <zhudacai at hisilicon.com>
+ *         Gabriele Paoloni <gabriele.paoloni at huawei.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.
+ */
+
+#include <linux/acpi.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of_pci.h>
+#include <linux/regmap.h>
+
+#include "pcie-designware.h"
+#include "pcie-hisi.h"
+
+/* HipXX PCIe host only supports 32-bit config access */
+int hisi_pcie_common_cfg_read(void __iomem *reg_base, int where, int size,
+			      u32 *val)
+{
+	u32 reg;
+	u32 reg_val;
+	void *walker = &reg_val;
+
+	walker += (where & 0x3);
+	reg = where & ~0x3;
+	reg_val = readl(reg_base + reg);
+
+	if (size == 1)
+		*val = *(u8 __force *) walker;
+	else if (size == 2)
+		*val = *(u16 __force *) walker;
+	else if (size == 4)
+		*val = reg_val;
+	else
+		return PCIBIOS_BAD_REGISTER_NUMBER;
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+/* HipXX PCIe host only supports 32-bit config access */
+int hisi_pcie_common_cfg_write(void __iomem *reg_base, int where, int  size,
+				u32 val)
+{
+	u32 reg_val;
+	u32 reg;
+	void *walker = &reg_val;
+
+	walker += (where & 0x3);
+	reg = where & ~0x3;
+	if (size == 4)
+		writel(val, reg_base + reg);
+	else if (size == 2) {
+		reg_val = readl(reg_base + reg);
+		*(u16 __force *) walker = val;
+		writel(val, reg_base + reg);
+	} else if (size == 1) {
+		reg_val = readl(reg_base + reg);
+		*(u8 __force *) walker = val;
+		writel(val, reg_base + reg);
+	} else
+		return PCIBIOS_BAD_REGISTER_NUMBER;
+
+	return PCIBIOS_SUCCESSFUL;
+}
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index 3e98d4e..458d0f8 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -21,6 +21,7 @@
 #include <linux/regmap.h>
 
 #include "pcie-designware.h"
+#include "pcie-hisi.h"
 
 #define PCIE_LTSSM_LINKUP_STATE				0x11
 #define PCIE_LTSSM_STATE_MASK				0x3F
@@ -30,12 +31,6 @@
 
 #define to_hisi_pcie(x)	container_of(x, struct hisi_pcie, pp)
 
-struct hisi_pcie;
-
-struct pcie_soc_ops {
-	int (*hisi_pcie_link_up)(struct hisi_pcie *pcie);
-};
-
 struct hisi_pcie {
 	struct regmap *subctrl;
 	void __iomem *reg_base;
@@ -44,87 +39,24 @@ struct hisi_pcie {
 	struct pcie_soc_ops *soc_ops;
 };
 
-static inline void hisi_pcie_apb_writel(struct hisi_pcie *pcie,
-					u32 val, u32 reg)
-{
-	writel(val, pcie->reg_base + reg);
-}
-
-static inline u32 hisi_pcie_apb_readl(struct hisi_pcie *pcie, u32 reg)
-{
-	return readl(pcie->reg_base + reg);
-}
-
-/* HipXX PCIe host only supports 32-bit config access */
-static int hisi_pcie_cfg_read(struct pcie_port *pp, int where, int size,
-			      u32 *val)
-{
-	u32 reg;
-	u32 reg_val;
-	struct hisi_pcie *pcie = to_hisi_pcie(pp);
-	void *walker = &reg_val;
-
-	walker += (where & 0x3);
-	reg = where & ~0x3;
-	reg_val = hisi_pcie_apb_readl(pcie, reg);
-
-	if (size == 1)
-		*val = *(u8 __force *) walker;
-	else if (size == 2)
-		*val = *(u16 __force *) walker;
-	else if (size == 4)
-		*val = reg_val;
-	else
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	return PCIBIOS_SUCCESSFUL;
-}
+struct pcie_soc_ops {
+	int (*hisi_pcie_link_up)(struct hisi_pcie *pcie);
+};
 
-/* HipXX PCIe host only supports 32-bit config access */
-static int hisi_pcie_cfg_write(struct pcie_port *pp, int where, int  size,
-				u32 val)
+static inline int hisi_pcie_cfg_read(struct pcie_port *pp, int where,
+		int size, u32 *val)
 {
-	u32 reg_val;
-	u32 reg;
 	struct hisi_pcie *pcie = to_hisi_pcie(pp);
-	void *walker = &reg_val;
-
-	walker += (where & 0x3);
-	reg = where & ~0x3;
-	if (size == 4)
-		hisi_pcie_apb_writel(pcie, val, reg);
-	else if (size == 2) {
-		reg_val = hisi_pcie_apb_readl(pcie, reg);
-		*(u16 __force *) walker = val;
-		hisi_pcie_apb_writel(pcie, reg_val, reg);
-	} else if (size == 1) {
-		reg_val = hisi_pcie_apb_readl(pcie, reg);
-		*(u8 __force *) walker = val;
-		hisi_pcie_apb_writel(pcie, reg_val, reg);
-	} else
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	return PCIBIOS_SUCCESSFUL;
-}
 
-static int hisi_pcie_link_up_hip05(struct hisi_pcie *hisi_pcie)
-{
-	u32 val;
-
-	regmap_read(hisi_pcie->subctrl, PCIE_SUBCTRL_SYS_STATE4_REG +
-		    0x100 * hisi_pcie->port_id, &val);
-
-	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
+	return hisi_pcie_common_cfg_read(pcie->reg_base, where, size, val);
 }
 
-static int hisi_pcie_link_up_hip06(struct hisi_pcie *hisi_pcie)
+static inline int hisi_pcie_cfg_write(struct pcie_port *pp, int where,
+		int size, u32 val)
 {
-	u32 val;
-
-	val = hisi_pcie_apb_readl(hisi_pcie, PCIE_HIP06_CTRL_OFF +
-			PCIE_SYS_STATE4);
+	struct hisi_pcie *pcie = to_hisi_pcie(pp);
 
-	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
+	return hisi_pcie_common_cfg_write(pcie->reg_base, where, size, val);
 }
 
 static int hisi_pcie_link_up(struct pcie_port *pp)
@@ -134,12 +66,13 @@ static int hisi_pcie_link_up(struct pcie_port *pp)
 	return hisi_pcie->soc_ops->hisi_pcie_link_up(hisi_pcie);
 }
 
-static struct pcie_host_ops hisi_pcie_host_ops = {
-	.rd_own_conf = hisi_pcie_cfg_read,
-	.wr_own_conf = hisi_pcie_cfg_write,
-	.link_up = hisi_pcie_link_up,
+struct pcie_host_ops hisi_pcie_host_ops = {
+		.rd_own_conf = hisi_pcie_cfg_read,
+		.wr_own_conf = hisi_pcie_cfg_write,
+		.link_up = hisi_pcie_link_up,
 };
 
+
 static int hisi_add_pcie_port(struct pcie_port *pp,
 				     struct platform_device *pdev)
 {
@@ -215,6 +148,26 @@ static int hisi_pcie_probe(struct platform_device *pdev)
 	return 0;
 }
 
+static int hisi_pcie_link_up_hip05(struct hisi_pcie *hisi_pcie)
+{
+	u32 val;
+
+	regmap_read(hisi_pcie->subctrl, PCIE_SUBCTRL_SYS_STATE4_REG +
+		    0x100 * hisi_pcie->port_id, &val);
+
+	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
+}
+
+static int hisi_pcie_link_up_hip06(struct hisi_pcie *hisi_pcie)
+{
+	u32 val;
+
+	val = readl(hisi_pcie->reg_base + PCIE_HIP06_CTRL_OFF +
+			PCIE_SYS_STATE4);
+
+	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
+}
+
 static struct pcie_soc_ops hip05_ops = {
 		&hisi_pcie_link_up_hip05
 };
diff --git a/drivers/pci/host/pcie-hisi.h b/drivers/pci/host/pcie-hisi.h
new file mode 100644
index 0000000..29e0790
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi.h
@@ -0,0 +1,23 @@
+/*
+ * PCIe host controller driver for HiSilicon SoCs
+ *
+ * Copyright (C) 2015 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Zhou Wang <wangzhou1 at hisilicon.com>
+ *         Dacai Zhu <zhudacai at hisilicon.com>
+ *         Gabriele Paoloni <gabriele.paoloni at huawei.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.
+ */
+#ifndef PCIE_HISI_H_
+#define PCIE_HISI_H_
+
+
+int hisi_pcie_common_cfg_read(void __iomem *reg_base, int where, int size,
+			      u32 *val);
+int hisi_pcie_common_cfg_write(void __iomem *reg_base, int where, int  size,
+				u32 val);
+
+#endif /* PCIE_HISI_H_ */
-- 
1.9.1




From gabriele.paoloni at huawei.com  Mon Feb  8 04:41:03 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Mon, 8 Feb 2016 12:41:03 +0000
Subject: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host controller
 ECAM compliant
In-Reply-To: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
Message-ID: <1454935264-6076-3-git-send-email-gabriele.paoloni@huawei.com>

From: gabriele paoloni <gabriele.paoloni at huawei.com>

This patch modifies the current Hip05/Hip06 PCIe host controller
driver to make it ECAM compliant. This is needed in preparation
for the ACPI based driver to allow both DT and ACPI drivers to
use the same BIOS (that configure the Designware iATUs).

Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
Signed-off-by: Dongdong Liu <liudongdong3 at huawei.com>
---
 drivers/pci/host/pcie-designware.c |  4 +---
 drivers/pci/host/pcie-designware.h |  2 ++
 drivers/pci/host/pcie-hisi.c       | 35 +++++++++++++++++++++++++++++++++++
 3 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
index 2171682..5f19ea4 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -69,8 +69,6 @@
 #define PCIE_ATU_FUNC(x)		(((x) & 0x7) << 16)
 #define PCIE_ATU_UPPER_TARGET		0x91C
 
-static struct pci_ops dw_pcie_ops;
-
 int dw_pcie_cfg_read(void __iomem *addr, int size, u32 *val)
 {
 	if ((uintptr_t)addr & (size - 1)) {
@@ -690,7 +688,7 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
 	return dw_pcie_wr_other_conf(pp, bus, devfn, where, size, val);
 }
 
-static struct pci_ops dw_pcie_ops = {
+struct pci_ops dw_pcie_ops = {
 	.read = dw_pcie_rd_conf,
 	.write = dw_pcie_wr_conf,
 };
diff --git a/drivers/pci/host/pcie-designware.h b/drivers/pci/host/pcie-designware.h
index 2356d29..3f42655 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -80,4 +80,6 @@ int dw_pcie_link_up(struct pcie_port *pp);
 void dw_pcie_setup_rc(struct pcie_port *pp);
 int dw_pcie_host_init(struct pcie_port *pp);
 
+extern struct pci_ops dw_pcie_ops;
+
 #endif /* _PCIE_DESIGNWARE_H */
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index 458d0f8..eb3201a 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -43,6 +43,18 @@ struct pcie_soc_ops {
 	int (*hisi_pcie_link_up)(struct hisi_pcie *pcie);
 };
 
+static inline int hisi_rd_other_conf(struct pcie_port *pp, struct pci_bus *bus,
+		unsigned int devfn, int where, int size, u32 *value)
+{
+	return pci_generic_config_read(bus, devfn, where, size, value);
+}
+
+static inline int hisi_wr_other_conf(struct pcie_port *pp, struct pci_bus *bus,
+		unsigned int devfn, int where, int size, u32 value)
+{
+	return pci_generic_config_write(bus, devfn, where, size, value);
+}
+
 static inline int hisi_pcie_cfg_read(struct pcie_port *pp, int where,
 		int size, u32 *val)
 {
@@ -67,11 +79,24 @@ static int hisi_pcie_link_up(struct pcie_port *pp)
 }
 
 struct pcie_host_ops hisi_pcie_host_ops = {
+		.rd_other_conf = hisi_rd_other_conf,
+		.wr_other_conf = hisi_wr_other_conf,
 		.rd_own_conf = hisi_pcie_cfg_read,
 		.wr_own_conf = hisi_pcie_cfg_write,
 		.link_up = hisi_pcie_link_up,
 };
 
+static void __iomem *hisi_pci_map_cfg_bus_cam(struct pci_bus *bus,
+					     unsigned int devfn,
+					     int where)
+{
+	void __iomem *addr;
+	struct pcie_port *pp = bus->sysdata;
+
+	addr = pp->va_cfg1_base + where;
+
+	return addr;
+}
 
 static int hisi_add_pcie_port(struct pcie_port *pp,
 				     struct platform_device *pdev)
@@ -92,6 +117,8 @@ static int hisi_add_pcie_port(struct pcie_port *pp,
 
 	pp->ops = &hisi_pcie_host_ops;
 
+	dw_pcie_ops.map_bus = hisi_pci_map_cfg_bus_cam;
+
 	ret = dw_pcie_host_init(pp);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to initialize host\n");
@@ -137,6 +164,14 @@ static int hisi_pcie_probe(struct platform_device *pdev)
 
 	hisi_pcie->pp.dbi_base = hisi_pcie->reg_base;
 
+	reg = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam-cfg");
+	hisi_pcie->pp.va_cfg0_base = devm_ioremap_resource(&pdev->dev, reg);
+	if (IS_ERR(hisi_pcie->pp.va_cfg0_base)) {
+		dev_err(pp->dev, "cannot get ecam-cfg\n");
+		return PTR_ERR(hisi_pcie->pp.va_cfg0_base);
+	}
+	hisi_pcie->pp.va_cfg1_base = hisi_pcie->pp.va_cfg0_base;
+
 	ret = hisi_add_pcie_port(pp, pdev);
 	if (ret)
 		return ret;
-- 
1.9.1




From anup.patel at broadcom.com  Mon Feb  8 04:43:11 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Mon, 8 Feb 2016 18:13:11 +0530
Subject: [PATCH v2 4/4] iommu/arm-smmu: Add stub of_xlate() operation in
 SMMUv1/SMMUv2 driver
In-Reply-To: <20160208111829.GA13498@leverpostej>
References: <1454908652-15317-1-git-send-email-anup.patel@broadcom.com>
 <1454908652-15317-5-git-send-email-anup.patel@broadcom.com>
 <20160208111829.GA13498@leverpostej>
Message-ID: <CAALAos94ZHTKF5Gvjt7b56Yq+ZhhSSCN3xLdOWEpRvsrFohW6A@mail.gmail.com>

On Mon, Feb 8, 2016 at 4:48 PM, Mark Rutland <mark.rutland at arm.com> wrote:
> On Mon, Feb 08, 2016 at 10:47:32AM +0530, Anup Patel wrote:
>> To allow use of large memory (> 4Gb) with 32bit devices we need to use
>> IOMMU based DMA mappings for such 32bit devices. The IOMMU dt-bindings
>> allows us do this by specifying 'iommus' attribute in 32bit device DT
>> node. Unfortunately, specifying 'iommus' attribute does not work with
>> current SMMUv1/SMMUv2 driver because it requires of_xlate() operation
>> to be implemented by the driver.
>>
>> This patch adds a stub implementation of of_xlate() in SMMUv1/SMMUv2
>> driver to allow usage of 'iommus' attribute in DT for 32bit devices.
>>
>> Signed-off-by: Anup Patel <anup.patel at broadcom.com>
>> Reviewed-by: Ray Jui <rjui at broadcom.com>
>> Reviewed-by: Scott Branden <sbranden at broadcom.com>
>> ---
>>  drivers/iommu/arm-smmu.c | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 02cd67d..8e090d8 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -1398,6 +1398,16 @@ static int arm_smmu_init_platform_device(struct device *dev,
>>       return 0;
>>  }
>>
>> +int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
>> +{
>> +     /*
>> +      * Nothing to do here because SMMU is already aware of all
>> +      * MMU masters and their stream IDs using mmu-master attibute
>> +      * SMMU DT node.
>> +      */
>> +     return 0;
>> +}
>
> NAK to this.

I had no intention in continuing this change if I knew some work
on generic IOMMU binding was in-progress. In fact, I had asked
about alternate options previously. (Refer,
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/403128.html)

>
> As previously mentioned by others [1], this is an abuse of the generic
> iommu binding support code.
>
> The SMMU binding currently does not define its implementation of the
> generic IOMMU binding. This series did not define what an SMMU's
> #iommu-cells would be nor what the contained values would represent.
> Therefore it is not valid to use an SMMU node with an iommus property as
> the SMMu doesn't follwo the generic IOMMU binding.
>
> There is ongoing work to have generic iommu binding support for the
> SMMU. In the absence of documentation for what this means for the
> binding, I am worried that this hack harms that effort.

Thanks for the info, I would like to try this on Broadcom SoCs.

Whats the ETA of patches for generic IOMMU binding for SMMU?

>
> To use features of the generic IOMMU binding, we must properly implement
> the generic IOMMU binding for the SMMU rather than bodging it onto the
> side of the existing binding.
>
> Thanks,
> Mark.
>

Regards,
Anup


From javier at osg.samsung.com  Mon Feb  8 04:44:32 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Mon, 8 Feb 2016 09:44:32 -0300
Subject: [PATCH] drm/exynos: dp: Fix panel and bridge lookup logic
In-Reply-To: <56B88C33.8060808@samsung.com>
References: <1454080171-23769-1-git-send-email-javier@osg.samsung.com>
 <56B88418.7090106@osg.samsung.com> <56B88C33.8060808@samsung.com>
Message-ID: <56B88DB0.3040806@osg.samsung.com>

Hello Marek,

On 02/08/2016 09:38 AM, Marek Szyprowski wrote:
> Hi Javier,
>
> On 2016-02-08 13:03, Javier Martinez Canillas wrote:
>> Hello Inki,
>>
>> On 01/29/2016 12:09 PM, Javier Martinez Canillas wrote:
>>> Commit a9fa852886fd ("drm/exynos: dp: add of_graph dt binding support
>>> for panel") made the Exynos DP DT binding more consistent since the OF
>>> graph could be used to lookup either a panel or a bridge device node.
>>>
>>> Before that commit, a panel would be looked up using a phandle and a
>>> bridge using the OF graph which made the DT binding not consistent.
>>>
>>> But the patch broke the later case since not finding a panel dev node
>>> would cause the driver's to do a probe deferral instead of attempting
>>> to lookup a bridge device node associated with the remote endpoint.
>>>
>>> So instead of returning a -EPROBE_DEFER if a panel is not found, check
>>> if there's a bridge and only do a probe deferral if both aren't found.
>>>
>>> Fixes: a9fa852886fd ("drm/exynos: dp: add of_graph dt binding support for panel")
>>> Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
>>>
>>
>> Any comments about this patch? It is needed to have display working on
>> machines with a bridge chip again so it should be pushed to -rc ASAP.
>
> Please check v4.5-rc3, this patch is already merged there.
>

My bad, I was looking at v4.5-rc2 and Inki used to answer to patches
when he picks them so I thought he didn't have time to look at it yet.

Anyways, thanks a lot for pointing it out.
  
> Best regards

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America


From afaerber at suse.de  Mon Feb  8 04:49:42 2016
From: afaerber at suse.de (=?UTF-8?q?Andreas=20F=C3=A4rber?=)
Date: Mon,  8 Feb 2016 13:49:42 +0100
Subject: [PATCH] tty: serial: meson: Add support for XTAL clock input
Message-ID: <1454935783-17027-1-git-send-email-afaerber@suse.de>

Fix the baudrate calculation for 24 MHz XTAL clock found on gxbb platforms.

Signed-off-by: Andreas F?rber <afaerber at suse.de>
---
 Forward-ported from vendor kernel. On top of my meson earlycon patch.
 
 drivers/tty/serial/meson_uart.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/meson_uart.c b/drivers/tty/serial/meson_uart.c
index 9efcfa2de31e..4415631bab17 100644
--- a/drivers/tty/serial/meson_uart.c
+++ b/drivers/tty/serial/meson_uart.c
@@ -78,6 +78,7 @@
 /* AML_UART_REG5 bits */
 #define AML_UART_BAUD_MASK		0x7fffff
 #define AML_UART_BAUD_USE		BIT(23)
+#define AML_UART_BAUD_XTAL		BIT(24)
 
 #define AML_UART_PORT_NUM		6
 #define AML_UART_DEV_NAME		"ttyAML"
@@ -299,7 +300,12 @@ static void meson_uart_change_speed(struct uart_port *port, unsigned long baud)
 
 	val = readl(port->membase + AML_UART_REG5);
 	val &= ~AML_UART_BAUD_MASK;
-	val = ((port->uartclk * 10 / (baud * 4) + 5) / 10) - 1;
+	if (port->uartclk == 24000000) {
+		val = ((port->uartclk / 3) / baud) - 1;
+		val |= AML_UART_BAUD_XTAL;
+	} else {
+		val = ((port->uartclk * 10 / (baud * 4) + 5) / 10) - 1;
+	}
 	val |= AML_UART_BAUD_USE;
 	writel(val, port->membase + AML_UART_REG5);
 }
-- 
2.6.2



From christoffer.dall at linaro.org  Mon Feb  8 04:52:47 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 8 Feb 2016 13:52:47 +0100
Subject: [PATCH v11 21/21] KVM: ARM64: Add a new vcpu device control
 group for PMUv3
In-Reply-To: <1454656456-11640-22-git-send-email-zhaoshenglong@huawei.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
 <1454656456-11640-22-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <20160208125247.GG620@cbox>

On Fri, Feb 05, 2016 at 03:14:16PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
> 
> To configure the virtual PMUv3 overflow interrupt number, we use the
> vcpu kvm_device ioctl, encapsulating the KVM_ARM_VCPU_PMU_V3_IRQ
> attribute within the KVM_ARM_VCPU_PMU_V3_CTRL group.
> 
> After configuring the PMUv3, call the vcpu ioctl with attribute
> KVM_ARM_VCPU_PMU_V3_INIT to initialize the PMUv3.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> Acked-by: Peter Maydell <peter.maydell at linaro.org>
> Reviewed-by: Andrew Jones <drjones at redhat.com>
> ---
> CC: Peter Maydell <peter.maydell at linaro.org>
> ---
>  Documentation/virtual/kvm/devices/vcpu.txt |  24 ++++++
>  arch/arm/include/asm/kvm_host.h            |  15 ++++
>  arch/arm/kvm/arm.c                         |   3 +
>  arch/arm64/include/asm/kvm_host.h          |   6 ++
>  arch/arm64/include/uapi/asm/kvm.h          |   5 ++
>  arch/arm64/kvm/guest.c                     |  51 ++++++++++++
>  include/kvm/arm_pmu.h                      |  23 ++++++
>  virt/kvm/arm/pmu.c                         | 128 +++++++++++++++++++++++++++++
>  8 files changed, 255 insertions(+)
> 
> diff --git a/Documentation/virtual/kvm/devices/vcpu.txt b/Documentation/virtual/kvm/devices/vcpu.txt
> index 3cc59c5..d626237 100644
> --- a/Documentation/virtual/kvm/devices/vcpu.txt
> +++ b/Documentation/virtual/kvm/devices/vcpu.txt
> @@ -6,3 +6,27 @@ KVM_GET_DEVICE_ATTR, and KVM_HAS_DEVICE_ATTR. The interface uses the same struct
>  kvm_device_attr as other devices, but targets VCPU-wide settings and controls.
>  
>  The groups and attributes per virtual cpu, if any, are architecture specific.
> +
> +1. GROUP: KVM_ARM_VCPU_PMU_V3_CTRL
> +Architectures: ARM64
> +
> +1.1. ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_IRQ
> +Parameters: in kvm_device_attr.addr the address for PMU overflow interrupt

so kvm_device_attr.addr is a pointer to an unsigned long or an int, or?

> +Returns: -EBUSY: The PMU overflow interrupt is already set
> +         -ENXIO: The overflow interrupt not set when attempting to get it
> +         -ENODEV: PMUv3 not supported
> +         -EINVAL: Invalid PMU overflow interrupt number supplied
> +
> +A value describing the PMUv3 (Performance Monitor Unit v3) overflow interrupt
> +number for this vcpu. This interrupt could be a PPI or SPI, but the interrupt
> +type must be same for each vcpu. As a PPI, the interrupt number is same for all

nit: s/is same/is the same/

> +vcpus, while as an SPI it must be different for each vcpu.

nit: s/it must be different for each vcpu/
       it must be a separate number per vcpu/

> +
> +1.2 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_INIT
> +Parameters: no additional parameter in kvm_device_attr.addr
> +Returns: -ENODEV: PMUv3 not supported
> +         -ENXIO: PMUv3 not properly configured as required prior to calling this
> +                 attribute
> +         -EBUSY: PMUv3 already initialized
> +
> +Request the initialization of the PMUv3.
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index f9f2779..6dd0992 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -242,5 +242,20 @@ static inline void kvm_arm_init_debug(void) {}
>  static inline void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) {}
>  static inline void kvm_arm_clear_debug(struct kvm_vcpu *vcpu) {}
>  static inline void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu) {}
> +static inline int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
> +					     struct kvm_device_attr *attr)
> +{
> +	return -ENXIO;
> +}
> +static inline int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
> +					     struct kvm_device_attr *attr)
> +{
> +	return -ENXIO;
> +}
> +static inline int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
> +					     struct kvm_device_attr *attr)
> +{
> +	return -ENXIO;
> +}
>  
>  #endif /* __ARM_KVM_HOST_H__ */
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 34d7395..dc8644f 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -833,6 +833,7 @@ static int kvm_arm_vcpu_set_attr(struct kvm_vcpu *vcpu,
>  
>  	switch (attr->group) {
>  	default:
> +		ret = kvm_arm_vcpu_arch_set_attr(vcpu, attr);
>  		break;
>  	}
>  
> @@ -846,6 +847,7 @@ static int kvm_arm_vcpu_get_attr(struct kvm_vcpu *vcpu,
>  
>  	switch (attr->group) {
>  	default:
> +		ret = kvm_arm_vcpu_arch_get_attr(vcpu, attr);
>  		break;
>  	}
>  
> @@ -859,6 +861,7 @@ static int kvm_arm_vcpu_has_attr(struct kvm_vcpu *vcpu,
>  
>  	switch (attr->group) {
>  	default:
> +		ret = kvm_arm_vcpu_arch_has_attr(vcpu, attr);
>  		break;
>  	}
>  
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index cb220b7..a855a30 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -359,5 +359,11 @@ void kvm_arm_init_debug(void);
>  void kvm_arm_setup_debug(struct kvm_vcpu *vcpu);
>  void kvm_arm_clear_debug(struct kvm_vcpu *vcpu);
>  void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu);
> +int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
> +			       struct kvm_device_attr *attr);
> +int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
> +			       struct kvm_device_attr *attr);
> +int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
> +			       struct kvm_device_attr *attr);
>  
>  #endif /* __ARM64_KVM_HOST_H__ */
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 6aedbe3..f209ea1 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -205,6 +205,11 @@ struct kvm_arch_memory_slot {
>  #define KVM_DEV_ARM_VGIC_GRP_CTRL	4
>  #define   KVM_DEV_ARM_VGIC_CTRL_INIT	0
>  
> +/* Device Control API on vcpu fd */
> +#define KVM_ARM_VCPU_PMU_V3_CTRL	0
> +#define   KVM_ARM_VCPU_PMU_V3_IRQ	0
> +#define   KVM_ARM_VCPU_PMU_V3_INIT	1
> +
>  /* KVM_IRQ_LINE irq field index values */
>  #define KVM_ARM_IRQ_TYPE_SHIFT		24
>  #define KVM_ARM_IRQ_TYPE_MASK		0xff
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> index fcb7788..dbe45c3 100644
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
> @@ -380,3 +380,54 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
>  	}
>  	return 0;
>  }
> +
> +int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
> +			       struct kvm_device_attr *attr)
> +{
> +	int ret;
> +
> +	switch (attr->group) {
> +	case KVM_ARM_VCPU_PMU_V3_CTRL:
> +		ret = kvm_arm_pmu_v3_set_attr(vcpu, attr);
> +		break;
> +	default:
> +		ret = -ENXIO;
> +		break;
> +	}
> +
> +	return ret;
> +}
> +
> +int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
> +			       struct kvm_device_attr *attr)
> +{
> +	int ret;
> +
> +	switch (attr->group) {
> +	case KVM_ARM_VCPU_PMU_V3_CTRL:
> +		ret = kvm_arm_pmu_v3_get_attr(vcpu, attr);
> +		break;
> +	default:
> +		ret = -ENXIO;
> +		break;
> +	}
> +
> +	return ret;
> +}
> +
> +int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
> +			       struct kvm_device_attr *attr)
> +{
> +	int ret;
> +
> +	switch (attr->group) {
> +	case KVM_ARM_VCPU_PMU_V3_CTRL:
> +		ret = kvm_arm_pmu_v3_has_attr(vcpu, attr);
> +		break;
> +	default:
> +		ret = -ENXIO;
> +		break;
> +	}
> +
> +	return ret;
> +}
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 5f86e1d..f09abf6 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -38,6 +38,7 @@ struct kvm_pmu {
>  };
>  
>  #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
> +#define kvm_arm_pmu_irq_initialized(v)	((v)->arch.pmu.irq_num >= VGIC_NR_SGIS)
>  u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
>  void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
>  u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
> @@ -52,11 +53,18 @@ void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>  				    u64 select_idx);
>  bool kvm_arm_support_pmu_v3(void);
> +int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu,
> +			    struct kvm_device_attr *attr);
> +int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu,
> +			    struct kvm_device_attr *attr);
> +int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu,
> +			    struct kvm_device_attr *attr);
>  #else
>  struct kvm_pmu {
>  };
>  
>  #define kvm_arm_pmu_v3_ready(v)		(false)
> +#define kvm_arm_pmu_irq_initialized(v)	(false)
>  static inline u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu,
>  					    u64 select_idx)
>  {
> @@ -79,6 +87,21 @@ static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
>  						  u64 data, u64 select_idx) {}
>  static inline bool kvm_arm_support_pmu_v3(void) { return false; }
> +static inline int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu,
> +					  struct kvm_device_attr *attr)
> +{
> +	return -ENXIO;
> +}
> +static inline int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu,
> +					  struct kvm_device_attr *attr)
> +{
> +	return -ENXIO;
> +}
> +static inline int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu,
> +					  struct kvm_device_attr *attr)
> +{
> +	return -ENXIO;
> +}
>  #endif
>  
>  #endif
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index 2467d62..06b7cb3 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -19,6 +19,7 @@
>  #include <linux/kvm.h>
>  #include <linux/kvm_host.h>
>  #include <linux/perf_event.h>
> +#include <linux/uaccess.h>
>  #include <asm/kvm_emulate.h>
>  #include <kvm/arm_pmu.h>
>  #include <kvm/arm_vgic.h>
> @@ -393,3 +394,130 @@ bool kvm_arm_support_pmu_v3(void)
>  	 */
>  	return (perf_num_counters() > 0);
>  }
> +
> +static int kvm_arm_pmu_v3_init(struct kvm_vcpu *vcpu)
> +{
> +	if (!kvm_arm_support_pmu_v3())
> +		return -ENODEV;
> +
> +	if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features) ||
> +	    !kvm_arm_pmu_irq_initialized(vcpu))
> +		return -ENXIO;
> +
> +	if (kvm_arm_pmu_v3_ready(vcpu))
> +		return -EBUSY;
> +
> +	kvm_pmu_vcpu_reset(vcpu);
> +	vcpu->arch.pmu.ready = true;
> +
> +	return 0;
> +}
> +
> +static int kvm_arm_pmu_irq_access(struct kvm_vcpu *vcpu,
> +				  struct kvm_device_attr *attr,
> +				  int *irq, bool is_set)
> +{
> +	if (!is_set) {
> +		if (!kvm_arm_pmu_irq_initialized(vcpu))
> +			return -ENXIO;
> +
> +		*irq = vcpu->arch.pmu.irq_num;
> +	} else {
> +		if (kvm_arm_pmu_irq_initialized(vcpu))
> +			return -EBUSY;
> +
> +		kvm_debug("Set kvm ARM PMU irq: %d\n", *irq);
> +		vcpu->arch.pmu.irq_num = *irq;
> +	}
> +
> +	return 0;
> +}

are you going to be reusing this function in later patches?  If not, I
don't see the benefit of having this indirection over simply including
it directly in the callers below.

> +
> +static bool irq_is_valid(struct kvm *kvm, int irq, bool is_ppi)
> +{
> +	int i;
> +	struct kvm_vcpu *vcpu;
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {
> +		if (!kvm_arm_pmu_irq_initialized(vcpu))
> +			continue;
> +
> +		if (is_ppi) {
> +			if (vcpu->arch.pmu.irq_num != irq)
> +				return false;
> +		} else {
> +			if (vcpu->arch.pmu.irq_num == irq)
> +				return false;
> +		}
> +	}
> +
> +	return true;
> +}
> +
> +
> +int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
> +{
> +	switch (attr->attr) {
> +	case KVM_ARM_VCPU_PMU_V3_IRQ: {
> +		int __user *uaddr = (int __user *)(long)attr->addr;
> +		int reg;
> +
> +		if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
> +			return -ENODEV;
> +
> +		if (get_user(reg, uaddr))
> +			return -EFAULT;
> +
> +		/*
> +		 * The PMU overflow interrupt could be a PPI or SPI, but for one
> +		 * VM the interrupt type must be same for each vcpu. As a PPI,
> +		 * the interrupt number is same for all vcpus, while as an SPI
> +		 * it must be different for each vcpu.
> +		 */
> +		if (reg < VGIC_NR_SGIS || reg >= vcpu->kvm->arch.vgic.nr_irqs ||
> +		    !irq_is_valid(vcpu->kvm, reg, reg < VGIC_NR_PRIVATE_IRQS))
> +			return -EINVAL;
> +
> +		return kvm_arm_pmu_irq_access(vcpu, attr, &reg, true);
> +	}
> +	case KVM_ARM_VCPU_PMU_V3_INIT:
> +		return kvm_arm_pmu_v3_init(vcpu);
> +	}
> +
> +	return -ENXIO;
> +}
> +
> +int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
> +{
> +	int ret;
> +
> +	switch (attr->attr) {
> +	case KVM_ARM_VCPU_PMU_V3_IRQ: {
> +		int __user *uaddr = (int __user *)(long)attr->addr;
> +		int reg = -1;
> +
> +		if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
> +			return -ENODEV;
> +
> +		ret = kvm_arm_pmu_irq_access(vcpu, attr, &reg, false);
> +		if (ret)
> +			return ret;
> +		return put_user(reg, uaddr);
> +	}
> +	}
> +
> +	return -ENXIO;
> +}
> +
> +int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
> +{
> +	switch (attr->attr) {
> +	case KVM_ARM_VCPU_PMU_V3_IRQ:
> +	case KVM_ARM_VCPU_PMU_V3_INIT:
> +		if (kvm_arm_support_pmu_v3() &&
> +		    test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
> +			return 0;
> +	}
> +
> +	return -ENXIO;
> +}
> -- 
> 2.0.4
> 
> 

Besides the style and wording comments:

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From arnd at arndb.de  Mon Feb  8 04:51:42 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  8 Feb 2016 13:51:42 +0100
Subject: [PATCH 1/2] serial: 8250: fix building mediatek with SERIAL_8250=m
Message-ID: <1454935947-2743255-1-git-send-email-arnd@arndb.de>

The Mediatek 8250 driver has a 'bool' Kconfig symbol, but that
breaks when SERIAL_8250 is a loadable module:

drivers/tty/built-in.o: In function `mtk8250_set_termios':
8250_ingenic.c:(.text+0x1bee8): undefined reference to `serial8250_do_set_termios'
8250_ingenic.c:(.text+0x1bf10): undefined reference to `uart_get_baud_rate'
8250_ingenic.c:(.text+0x1c09c): undefined reference to `uart_get_divisor'
drivers/tty/built-in.o: In function `mtk8250_do_pm':
8250_ingenic.c:(.text+0x1c0d0): undefined reference to `serial8250_do_pm'
drivers/tty/built-in.o: In function `mtk8250_probe':
8250_ingenic.c:(.text+0x1c2e4): undefined reference to `serial8250_register_8250_port'
serial/8250/8250_mtk.c:287:242: error: data definition has no type or storage class [-Werror]
serial/8250/8250_mtk.c:287:122: error: 'mtk8250_platform_driver_init' defined but not used [-Werror=unused-function]

This changes the symbol to a 'tristate', so the dependency on
SERIAL_8250 also works when that is set to 'm'.
To actually build the driver, we also need to include <linux/module.h>.

Note that the driver uses builtin_platform_driver() and implements
no .remove() callback, so unloading the module is not possible.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/tty/serial/8250/8250_mtk.c | 1 +
 drivers/tty/serial/8250/Kconfig    | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
index 9038843cadc7..7e9242a5ddfe 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -19,6 +19,7 @@
 #include <linux/init.h>
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
+#include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/serial_8250.h>
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index 67ad6b0d595b..6ae0fae4f796 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -370,7 +370,7 @@ config SERIAL_8250_LPC18XX
 	  serial port, say Y to this option. If unsure, say Y.
 
 config SERIAL_8250_MT6577
-	bool "Mediatek serial port support"
+	tristate "Mediatek serial port support"
 	depends on SERIAL_8250 && ARCH_MEDIATEK
 	help
 	  If you have a Mediatek based board and want to use the
-- 
2.7.0



From arnd at arndb.de  Mon Feb  8 04:51:43 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  8 Feb 2016 13:51:43 +0100
Subject: [PATCH 2/2] serial: 8250: fix building Ingenic with SERIAL_8250=m
In-Reply-To: <1454935947-2743255-1-git-send-email-arnd@arndb.de>
References: <1454935947-2743255-1-git-send-email-arnd@arndb.de>
Message-ID: <1454935947-2743255-2-git-send-email-arnd@arndb.de>

The Ingenic 8250 driver has a 'bool' Kconfig symbol, but that
breaks when SERIAL_8250 is a loadable module:

drivers/tty/built-in.o: In function `ingenic_uart_probe':
8250_ingenic.c:(.text+0x1c1a0): undefined reference to `serial8250_register_8250_port'

This changes the symbol to a 'tristate', plus a dependency on
SERIAL_8250, which makes it work again. Unlike the other
soc-specific backends, this one has no dependency on an
architecture or a platform. I'm adding a dependency on
MIPS || COMPILE_TEST as well here, to avoid showing the driver
on architectures that are not interested in it.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/tty/serial/8250/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index 6ae0fae4f796..13c63b14179f 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -384,8 +384,8 @@ config SERIAL_8250_UNIPHIER
 	  serial ports, say Y to this option. If unsure, say N.
 
 config SERIAL_8250_INGENIC
-	bool "Support for Ingenic SoC serial ports"
-	depends on OF_FLATTREE
+	tristate "Support for Ingenic SoC serial ports"
+	depends on SERIAL_8250 && OF_FLATTREE && (MIPS || COMPILE_TEST)
 	select LIBFDT
 	help
 	  If you have a system using an Ingenic SoC and wish to make use of
-- 
2.7.0



From arnd at arndb.de  Mon Feb  8 05:10:31 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 08 Feb 2016 14:10:31 +0100
Subject: [PATCH RFC] Add cpufreq support
In-Reply-To: <20160208124127.GF8294@vireshk>
References: <56B4D4BE.2040008@free.fr> <45004963.Im3DmqJ5ez@wuerfel>
 <20160208124127.GF8294@vireshk>
Message-ID: <22002072.L04zy0K2AP@wuerfel>

On Monday 08 February 2016 18:11:27 Viresh Kumar wrote:
> On 08-02-16, 13:34, Arnd Bergmann wrote:
> > Maybe add a opp-v3 compatible string?
> 
> How will that help?
> 
> The problem was that the compatibility string of "opp-v2" specifies
> the way we need to parse the bindings and shouldn't be (ab)used to
> probe a driver like cpufreq-dt. And so we got stuck.

I don't remember the exact discussion, but the compatible string is
exactly meant to do one thing: it tells you what you can or cannot do
with one device.

I had not realized that we don't even have a compatible string
for opp-v2, so if we are missing that, we obviously can't compare
against that string.

> > I really don't care what you
> > match on, as long we don't need any code in arch/arm/ to create a
> > device we don't need.
> 
> Sure.
> 
> > Don't add the device to DT, we really don't want that.
> 
> I agree.
> 
> > If there
> > is too much opposition to looking at the cpus nodes in the initcall,
> 
> I didn't get this one, what can we do by looking at CPUs nodes ?

I thought there was a compatible property in there that told us
whether the operating-points-v2/cooling-min-level/#cooling-cells/...
properties were considered valid.

> > start with a whitelist for known machines, that at least keeps the
> > existing behavior.
> 
> That can be a valid solution I would say, but that separate driver
> (cpufreq-dt-device.c) needs to be changed for every new platform.

Until we can agree on a way to describe in the DT whether the opp
properties are reliable or not.

	Arnd


From vinod.koul at intel.com  Mon Feb  8 05:14:19 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 8 Feb 2016 18:44:19 +0530
Subject: [PATCH v7 0/9] Fix broken DMAFLUSHP on Rockchips platform
In-Reply-To: <3817335.PXCk0JfYDT@phil>
References: <1453460812-8498-1-git-send-email-wxt@rock-chips.com>
 <56AF01B6.6030204@gmail.com> <20160208031134.GI2531@localhost>
 <3817335.PXCk0JfYDT@phil>
Message-ID: <20160208131419.GA19598@localhost>

Hi Heiko,

On Mon, Feb 08, 2016 at 10:27:04AM +0100, Heiko Stuebner wrote:
> Hi Vinod,
> 
> Am Montag, 8. Februar 2016, 08:41:34 schrieb Vinod Koul:
> > On Mon, Feb 01, 2016 at 02:56:54PM +0800, Caesar Wang wrote:
> > > Hello Vinod,
> > > 
> > > Is there any chance apply the DMA patches?:-)
> > 
> > I was waiting for any ACKs on ARM patches before I merge this series.
> 
> I think the more regular way is for the driver maintainer to take the 
> driver-specific stuff and the devicetree parts going through the specific arm-
> tree. But if you really want to take the whole series, for patches 4,5,6

Yes but that causes cross tree dependencies, which looking at this won't be
a big problem, so I can safely merge dmaengine changes and rest can go thru
ARM tree.

Typically submitter should say which tree he/she prefers, which was not
provided..

So, are all okay to merge the entire series thru dmaengine tree or
independent. I don't mind either

> - ARM: dts: Add arm, pl330-broken-no-flushp quirk for rk3288 platform
> - ARM: dts: Add arm, pl330-broken-no-flushp quirk for rk3xxx platform
> - ARM: dts: add pl330-broken-no-flushp quirk for rk3036 SoCs
> 
> Acked-by: Heiko Stuebner <heiko at sntech.de>

Thanks
-- 
~Vinod


From broonie at kernel.org  Mon Feb  8 05:13:20 2016
From: broonie at kernel.org (Mark Brown)
Date: Mon, 8 Feb 2016 13:13:20 +0000
Subject: [PATCH v3 4/6] arm64: Enable dynamic CPU capacity initialization
In-Reply-To: <56B889F7.306@arm.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <1454500799-18451-5-git-send-email-juri.lelli@arm.com>
 <56B889F7.306@arm.com>
Message-ID: <20160208131320.GA7265@sirena.org.uk>

On Mon, Feb 08, 2016 at 12:28:39PM +0000, Dietmar Eggemann wrote:
> On 03/02/16 11:59, Juri Lelli wrote:

> > +bool arch_wants_init_cpu_capacity(void)
> > +{
> > +	return true;

> Isn't this a little bit too simple? Not every ARM/ARM64 platform is a
> heterogeneous one.

Does it matter?  Is there any problem with doing the callibration and
having it say that all the CPUs performs very similarly?  My
understanding was that this was simply saying it was worth checking to
see if there was some asymmetry.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160208/48a34424/attachment.sig>

From viresh.kumar at linaro.org  Mon Feb  8 05:16:25 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 8 Feb 2016 18:46:25 +0530
Subject: [PATCH RFC] Add cpufreq support
In-Reply-To: <22002072.L04zy0K2AP@wuerfel>
References: <56B4D4BE.2040008@free.fr> <45004963.Im3DmqJ5ez@wuerfel>
 <20160208124127.GF8294@vireshk> <22002072.L04zy0K2AP@wuerfel>
Message-ID: <20160208131625.GI8294@vireshk>

On 08-02-16, 14:10, Arnd Bergmann wrote:
> I don't remember the exact discussion, but the compatible string is
> exactly meant to do one thing: it tells you what you can or cannot do
> with one device.

Yeah, and many people argued that we can't add two values to that
string like: "cpufreq-dt" and "cpufreq-big-little" for same kind of
OPP bindings, as a different compatible string should be required only
if there is a difference in the bindings.

For example, if a platform (like ST did recently) adds more
platform-specific properties, then they can define a new value of
those strings.

> I had not realized that we don't even have a compatible string
> for opp-v2, so if we are missing that, we obviously can't compare
> against that string.

The binding says that we can have a string, but its not compulsory
yet. Its only used by STM as they have some specific properties of
their own.

> I thought there was a compatible property in there that told us
> whether the operating-points-v2/cooling-min-level/#cooling-cells/...
> properties were considered valid.

Yeah, "OPP-v2" DT node can have a compatible string, which isn't
compulsory as of now, but because of the reasons mentioned earlier, we
can't use it to differentiate between drivers that use exactly same
version of bindings.

-- 
viresh


From gabriele.paoloni at huawei.com  Mon Feb  8 05:17:58 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Mon, 8 Feb 2016 13:17:58 +0000
Subject: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host
 Controllers
In-Reply-To: <1930535.mkCdtpUWq7@wuerfel>
References: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
 <76564455.dlc1WHiVY2@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1EC9EF4B@lhreml503-mbs>
 <1930535.mkCdtpUWq7@wuerfel>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECAC944@lhreml503-mbs>

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 04 February 2016 17:02
> To: Gabriele Paoloni
> Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C); Linuxarm;
> qiujiang; bhelgaas at google.com; Lorenzo.Pieralisi at arm.com;
> tn at semihalf.com; zhangjukuo; xuwei (O); Liguozhu (Kenneth); linux-
> pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> acpi at vger.kernel.org; linux-kernel at vger.kernel.org; jcm at redhat.com
> Subject: Re: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host
> Controllers
> 
> On Thursday 04 February 2016 16:44:12 Gabriele Paoloni wrote:
> > Effectively the ACPI version of the HiSilicon driver does not rely on
> > Designware as much as the DT version (that calls
> dw_pcie_host_init());
> > however in order to do what you suggest I'd need to copy and paste
> and
> > modify dw_pcie_rd_conf and dw_pcie_wr_conf.
> > Also I'd need to declare duplicate version of the functions in
> > pcie-hisi-common.c (if I do not want to split the object across
> > different paths "drivers/pci/host" and "drivers/acpi/")
> >
> > Now I can do it but I thought it was more correct to pass
> &dw_pcie_ops
> > as input pointer in DECLARE_ACPI_MCFG_FIXUP(); this is also because
> maybe in
> > future other Designware based controllers may need to support ACPI
> and it
> > would be easier for them to reuse their DT based driver functions
> >
> > Honestly I am a bit confused...
> >
> 
> I don't think you can use the dw_pcie_ops as-is anyway, as they in
> turn rely on the device driver structure, and you also don't need
> those as they seem to be written for the generic case of a 32-bit
> architecture that does not have enough space to map the entire
> config space into MMIO. Just set up all those mapping registers from
> the firmware and pass the config space base address as you'd normally
> do on ACPI.

Hi Arnd

I have now sent out patchset v2.

Now I have removed the dependency from designware but I still think
the best location for the code is in "drivers/pci/host/":
the ACPI quirks share the config read/write functions with the DT
driver, moreover for other hosts in future I think it makes sense
to stay in "drivers/pci/host/" as they could even share more init
code with their respective DT versions...

Cheers

Gab

> 
> 	Arnd


From alexander.shishkin at linux.intel.com  Mon Feb  8 05:26:48 2016
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Mon, 08 Feb 2016 15:26:48 +0200
Subject: [PATCH V2 3/6] stm class: provision for statically assigned
 masterIDs
In-Reply-To: <CANLsYky2twQ98u241YyHD=atYRp1N56YVHUQNY2E2Ljsq0cseA@mail.gmail.com>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
 <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org>
 <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com>
 <CANLsYky2twQ98u241YyHD=atYRp1N56YVHUQNY2E2Ljsq0cseA@mail.gmail.com>
Message-ID: <87twlj49k7.fsf@ashishki-desk.ger.corp.intel.com>

Mathieu Poirier <mathieu.poirier at linaro.org> writes:

> On 5 February 2016 at 05:52, Alexander Shishkin
> <alexander.shishkin at linux.intel.com> wrote:
>> Chunyan Zhang <zhang.chunyan at linaro.org> writes:
>>
>>> From: Mathieu Poirier <mathieu.poirier at linaro.org>
>>>
>>> Some architecture like ARM assign masterIDs statically at the HW design
>>> phase, making masterID manipulation in the generic STM core irrelevant.
>>>
>>> This patch adds a new 'mstatic' flag to struct stm_data that tells the
>>> core that this specific STM device doesn't need explicit masterID
>>> management.
>>
>> So why do we need this patch? If your STM only has master 42 allocated
>> for software sources, simply set sw_start = 42, sw_end = 42 and you're
>> good to go, software will have exactly one channel to choose from. See
>> also the comment from <linux/stm.h>:
>
> On ARM each source, i.e entity capable of accessing STM channels, has
> a different master ID set in HW.  We can't assume the IDs are
> contiguous and from a SW point of view there is no way to probe the
> values.

Ok, it's the 'static' word that got me confused. From Mike's explanation
it seems to me that it's the antithesis of static; the master ID
assignment is so dynamic that it's not controllable by the software and
may or may not reflect core id, power state, phase of the moon, etc.

>>> In the core sw_start/end of masterID are set to '1',
>>> i.e there is only one masterID to deal with.
>>
>> This is also a completely arbitrary and unnecessary requirement. Again,
>> you can set both to 42 and it will still work.
>
> True - any value will do. The important thing to remember is that on
> ARM, there is only one masterID channel (from an STM core point of
> view).  But we could also proceed differently, see below for more
> details.

Well, we have the masters attribute with two numbers in it that define
the range of master IDs that the software can choose from. More
specifically to this situation:

 * the number of channel ID spaces available to the SW is
   $end - $start + 1, that is, in your case, just 1;
 * the number of master IDs for the SW to choose from is $end - $start;
 * if $end==$start, their actual numeric value doesn't really matter,
   either for the policy definition or for the actual writers.

This $end==$start situation itself may be ambiguous and can be
interpreted either as having just one *static* master ID fixed for all
SW writers (what I assumed from your commit message) or as having a
floating master ID, which changes of its own accord and is not
controllable by software.

These two situations are really the same thing from the perspective of
the system under tracing. Also, both of these situations should already
work if the driver sets both sw_start and sw_end to the same
value.

Regards,
--
Alex


From eric.auger at linaro.org  Mon Feb  8 05:27:41 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Mon, 8 Feb 2016 14:27:41 +0100
Subject: ARM PCI/MSI KVM passthrough with GICv2M
In-Reply-To: <20160208094826.GA620@cbox>
References: <1454017899.23148.0.camel@redhat.com>
 <56AB78B1.2030202@linaro.org> <1454096004.9301.1.camel@redhat.com>
 <56ABD8E0.6080409@linaro.org> <20160201140351.GE6828@arm.com>
 <20160203125047.GB13974@cbox> <20160203131057.GA20217@arm.com>
 <20160203153606.GC13974@cbox> <56B4DC97.60904@linaro.org>
 <20160205111700.726ac061@t450s.home> <20160208094826.GA620@cbox>
Message-ID: <56B897CD.1000402@linaro.org>

Hi Alex, Christoffer,
On 02/08/2016 10:48 AM, Christoffer Dall wrote:
> On Fri, Feb 05, 2016 at 11:17:00AM -0700, Alex Williamson wrote:
>> On Fri, 5 Feb 2016 18:32:07 +0100
>> Eric Auger <eric.auger at linaro.org> wrote:
>>
>>> Hi Alex,
>>>
>>> I tried to sketch a proposal for guaranteeing the IRQ integrity when
>>> doing ARM PCI/MSI passthrough with ARM GICv2M msi-controller. This is
>>> based on extended VFIO group viability control, as detailed below.
>>>
>>> As opposed to ARM GICv3 ITS, this MSI controller does *not* support IRQ
>>> remapping. It can expose 1 or more 4kB MSI frame. Each frame contains a
>>> single register where the msi data is written.
>>>
>>> I would be grateful to you if you could tell me whether it makes any sense.
>>>
>>> Thanks in advance
>>>
>>> Best Regards
>>>
>>> Eric
>>>
>>>
>>> 1) GICv2m with a single 4kB single frame
>>>    all devices having this msi-controller as msi-parent share this
>>>    single MSI frame. Those devices can work on behalf of the host
>>>    or work on behalf of 1 or more guests (KVM assigned devices). We
>>>    must make sure either the host only or 1 single VM can access to the
>>>    single frame to guarantee interrupt integrity: a device assigned
>>>    to 1 VM should not be able to trigger MSI targeted to the host
>>>    or another VM.
>>>
>>>    I would propose to extend the VFIO notion of group viability.
>>>    Currently a VFIO group is viable if:
>>>    all devices belonging to the same group are bound to a VFIO driver
>>>    or unbound.
>>>
>>>    Let's imagine we extend the viability check as follows:
>>>
>>>    0) keep the current viable check: all the devices belonging to
>>>       the group must be vfio bound or unbound.
>>>    1) retrieve the MSI parent of the device and list all the
>>>       other devices using that MSI controller as MSI-parent (does not
>>>       look straightforward):
>>>    2) they must be VFIO driver bound or unbound as well (meaning
>>>       they are not used by the host). If not, reject device attachment
>>>    - in case they are VFIO bound (a VFIO group is set):
>>>      x if all VFIO containers are the same as the one of the device's
>>>        we try to attach, that's OK. This means the other devices
>>>        use different IOMMU mappings, eventually will target the
>>>        MSI frame but they all work for the same user space client/VM.
>>>      x 1 or more devices has a different container than the device
>>>        under attachment:
>>>        It works on behalf of a different user space client/VM,
>>>        we can't attach the new device. I think there is a case however
>>>        where severals containers can be opened by a single QEMU.
>>>
>>> Of course the dynamic aspects, ie a new device showing up or an unbind
>>> event bring significant complexity.
>>>
>>> 2) GICv2M with multiple 4kB frames
>>>    Each msi-frame is enumerated as msi-controller. The device tree
>>>    statically defines which device is attached to each msi frame.
>>>    In case devices are assigned we cannot change this attachment
>>>    anyway since there might be physical contraints behind.
>>>    So devices likely to be assigned to guests should be linked to a
>>>    different MSI frame than devices that are not.
>>>
>>>    I think extended viability concept can be used as well.
>>>
>>>    This model still is not ideal: in case we have a SR-IOV device
>>>    plugged onto an host bridge attached to a single MSI parent you won't
>>>    be able anyway to have 1 Virtual Function working for host and 1 VF
>>>    working for a guest. Only Interrupt translation (ITS) will bring that
>>>    feature.
>>>
>>> 3) GICv3 ITS
>>>    This one supports interrupt translation service ~ Intel
>>>    IRQ remapping.
>>>    This means a single frame can be used by all devices. A deviceID is
>>>    used exclusively by the host or a guest. I assume the ITS driver
>>>    allocates/populates deviceid interrupt translation table featuring
>>>    separate LPI spaces ie by construction different ITT cannot feature
>>>    same LPIs. So no need to do the extended viability test.
>>>
>>>    The MSI controller should have a property telling whether
>>>    it supports interrupt translation. This kind of property currently
>>>    exists on IOMMU side for INTEL remapping.
>>>
>>
>> Hi Eric,
>>
>> Would anyone be terribly upset if we simply assume the worst case
>> scenario on GICv2m/M, have the IOMMU not claim IOMMU_CAP_INTR_REMAP, and
>> require the user to opt-in via the allow_unsafe_interrupts on the
>> vfio_iommu_type1 module?  That would make it very compatible with what
>> we already do on x86, where it really is all or nothing.  
> 
> meaning either you allow unsafe multiplexing with passthrough in every
> flavor (unsafely) or you don't allow it at all?
that's my understanding. if the iommu does not expose
IOMMU_CAP_INTR_REMAP, the end-user must explicitly turn
allow_unsafe_interrupts on. On ARM we will have the handle the fact the
interrupt translation is handled on interrupt controller side and not on
iommu side though;
>
> I didn't know such on option existed, but it seems to me that this fits
> the bill exactly.
well I think the support of multiple GICv2m MSI frames was devised to
allow safe interrupts but extending the VFIO viability notion as
described above effectively seems a huge work with small benefits since
we don't have much HW featuring multiple frames I am afraid. So I think
it is a good compromise to have a minimal integration with GICv2m and
full feature with best fitted HW, ie. GICv3 ITS.
> 
> 
>> My assumption
>> is that GICv2 would be phased out in favor of GICv3, so there's always
>> a hardware upgrade path to having more complete isolation, but the
>> return on investment for figuring out whether a given device really has
>> this sort of isolation seems pretty low.  Often users already have some
>> degree of trust in the VMs they use for device assignment anyway.  An
>> especially prudent user can still look at the hardware specs for their
>> specific system to understand whether any devices are fully isolated
>> and only make use of those for device assignment.  Does that seem like
>> a reasonable alternative?
>>
> 
> It sounds good to me, that would allow us to release a GICv2m-based
> solution for MSI passthrough on currently available hardware like the
> Seattle.

Sounds good to me too. I am going to respin the kernel series according
to this discussion and previous comments.

Thanks for your comments!

Best Regards

Eric
> 
> Thanks,
> -Christoffer
> 



From sergei.shtylyov at cogentembedded.com  Mon Feb  8 05:30:37 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 8 Feb 2016 16:30:37 +0300
Subject: [PATCH 5/6] net: thunderx: bgx: Add log message when setting mac
 address
In-Reply-To: <1454933272-45005-6-git-send-email-sunil.kovvuri@gmail.com>
References: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
 <1454933272-45005-6-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <56B8987D.7000901@cogentembedded.com>

Hello.

On 2/8/2016 3:07 PM, sunil.kovvuri at gmail.com wrote:

> From: Robert Richter <rrichter at cavium.com>
>
> Signed-off-by: Robert Richter <rrichter at cavium.com>
> Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
> ---
>   drivers/net/ethernet/cavium/thunder/thunder_bgx.c |   11 ++++++++---
>   1 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> index 111835b..cfee496 100644
> --- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> +++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
[...]
> @@ -897,10 +898,13 @@ static int acpi_get_mac_address(struct acpi_device *adev, u8 *dst)
>   		goto out;
>
>   	if (!is_valid_ether_addr(mac)) {
> +		dev_warn(dev, "MAC address invalid: %pM\n", mac);

    dev_er(), maybe?

>   		ret = -EINVAL;
>   		goto out;
>   	}
>
> +	dev_info(dev, "MAC address set to: %pM\n", mac);
> +
>   	memcpy(dst, mac, ETH_ALEN);
>   out:
>   	return ret;
[...]

MBR, Sergei



From kernel at martin.sperl.org  Mon Feb  8 05:30:39 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Mon, 8 Feb 2016 14:30:39 +0100
Subject: [RFC 2/9] clk: bcm2835: add support for parent selection in DT
In-Reply-To: <20160121082642.GB13237@pengutronix.de>
References: <1453215100-2382-1-git-send-email-kernel@martin.sperl.org>
 <1453215100-2382-3-git-send-email-kernel@martin.sperl.org>
 <20160121082642.GB13237@pengutronix.de>
Message-ID: <56B8987F.1080701@martin.sperl.org>



On 21.01.2016 09:26, Sascha Hauer wrote:
> Martin,
>
> On Tue, Jan 19, 2016 at 02:51:33PM +0000, kernel at martin.sperl.org wrote:
>> From: Martin Sperl <kernel at martin.sperl.org>
>>
>> Allow for a per clock custom selection of clocks in the device tree.
>>
>> Basic setup in dt looks like this:
>>    clock at BCM2835_CLOCK_PCM {
>>      reg = <BCM2835_CLOCK_PCM>;
>>      parent-clock-names = "xosc", "plld_per", "plla_per", "pll_aux_per";
>>    };
>
> Isn't this the same as the already existing assigned-clock-parents property?
> If yes, that should be used.
It is not 100% identical, as the parent-clock-names do provide ordering
of clocks to be selected, which - under some circumstances may be
beneficial - e.g: when having a parent clock with 500MHz and 1000MHz,
then the higher clock could get given preference by switching ordering...

Also when using:
assigned-clock-parents = <&clk_osc 0>, <&clocks BCM2835_PLLD_PER>;

I get strange indexes passed when calling set_parent - so this would
need to get rewritten to support assigned-clock-parents correctly -
calculating the index on the fly...




From daniel.lezcano at linaro.org  Mon Feb  8 05:33:04 2016
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 8 Feb 2016 14:33:04 +0100
Subject: [PATCH v1] clocksource: atmel-pit: register as a sched_clock
In-Reply-To: <1454606493-15094-1-git-send-email-romain.izard.pro@gmail.com>
References: <1454606493-15094-1-git-send-email-romain.izard.pro@gmail.com>
Message-ID: <56B89910.3060305@linaro.org>

On 02/04/2016 06:21 PM, Romain Izard wrote:
> Register the counter of the Periodic Interval Timer as a possible source
> for sched_clock. This provides a better precision than the jiffies-based
> default.
>
> Signed-off-by: Romain Izard <romain.izard.pro at gmail.com>

Nicolas, Boris,

Are you ok with this patch ?

[ ... ]

-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From ian.campbell at citrix.com  Mon Feb  8 05:33:56 2016
From: ian.campbell at citrix.com (Ian Campbell)
Date: Mon, 8 Feb 2016 13:33:56 +0000
Subject: [PATCH] xen/arm: correctly handle DMA mapping of compound pages
Message-ID: <1454938450-26282-1-git-send-email-ian.campbell@citrix.com>

Currently xen_dma_map_page concludes that DMA to anything other than
the head page of a compound page must be foreign, since the PFN of the
page is that of the head.

Fix the check to instead consider the whole of a compound page to be
local if the PFN of the head passes the 1:1 check.

We can never see a compound page which is a mixture of foreign and
local sub-pages.

The comment already correctly described the intention, but fixup the
spelling and some grammar.

This fixes the various SSH protocol errors which we have been seeing
on the cubietrucks in our automated test infrastructure.

This has been broken since "xen/arm: use hypercall to flush caches in
map_page" (3567258d281b), which was in v3.19-rc1.

NB arch/arm64/.../xen/page-coherent.h also includes this file.

Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
Cc: xen-devel at lists.xenproject.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: stable at vger.kernel.org # v3.19+
---
 arch/arm/include/asm/xen/page-coherent.h | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index 0375c8c..5653739 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -35,14 +35,19 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
 	     dma_addr_t dev_addr, unsigned long offset, size_t size,
 	     enum dma_data_direction dir, struct dma_attrs *attrs)
 {
-	bool local = XEN_PFN_DOWN(dev_addr) == page_to_xen_pfn(page);
+	unsigned long page_pfn = page_to_xen_pfn(page);
+	unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
+	unsigned long compound_pages = 1<<compound_order(page);
+	bool local = page_pfn <= dev_pfn && dev_pfn - page_pfn < compound_pages;
+
 	/*
-	 * Dom0 is mapped 1:1, while the Linux page can be spanned accross
-	 * multiple Xen page, it's not possible to have a mix of local and
-	 * foreign Xen page. So if the first xen_pfn == mfn the page is local
-	 * otherwise it's a foreign page grant-mapped in dom0. If the page is
-	 * local we can safely call the native dma_ops function, otherwise we
-	 * call the xen specific function.
+	 * Dom0 is mapped 1:1, while the Linux page can span across
+	 * multiple Xen pages, it's not possible for it to contain a
+	 * mix of local and foreign Xen pages. So if the first xen_pfn
+	 * == mfn the page is local otherwise it's a foreign page
+	 * grant-mapped in dom0. If the page is local we can safely
+	 * call the native dma_ops function, otherwise we call the xen
+	 * specific function.
 	 */
 	if (local)
 		__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
-- 
2.1.4



From arnd at arndb.de  Mon Feb  8 05:36:13 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  8 Feb 2016 14:36:13 +0100
Subject: [PATCH] 8250: mediatek: mark PM functions as __maybe_unused
Message-ID: <1454938591-2743892-1-git-send-email-arnd@arndb.de>

The mtk8250_runtime_suspend function is not used when runtime PM is
disabled, so we get a warning about an unused function:

drivers/tty/serial/8250/8250_mtk.c:119:12: error: 'mtk8250_runtime_suspend' defined but not used [-Werror=unused-function]
 static int mtk8250_runtime_suspend(struct device *dev)

This marks all the PM functions as __maybe_unused to avoid the warning,
and removes the #ifdef around the PM_SLEEP functions for consistency.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/tty/serial/8250/8250_mtk.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
index 0e590b233f03..9038843cadc7 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -116,7 +116,7 @@ mtk8250_set_termios(struct uart_port *port, struct ktermios *termios,
 		tty_termios_encode_baud_rate(termios, baud, baud);
 }
 
-static int mtk8250_runtime_suspend(struct device *dev)
+static int __maybe_unused mtk8250_runtime_suspend(struct device *dev)
 {
 	struct mtk8250_data *data = dev_get_drvdata(dev);
 
@@ -126,7 +126,7 @@ static int mtk8250_runtime_suspend(struct device *dev)
 	return 0;
 }
 
-static int mtk8250_runtime_resume(struct device *dev)
+static int __maybe_unused mtk8250_runtime_resume(struct device *dev)
 {
 	struct mtk8250_data *data = dev_get_drvdata(dev);
 	int err;
@@ -245,8 +245,7 @@ static int mtk8250_probe(struct platform_device *pdev)
 	return 0;
 }
 
-#ifdef CONFIG_PM_SLEEP
-static int mtk8250_suspend(struct device *dev)
+static int __maybe_unused mtk8250_suspend(struct device *dev)
 {
 	struct mtk8250_data *data = dev_get_drvdata(dev);
 
@@ -255,7 +254,7 @@ static int mtk8250_suspend(struct device *dev)
 	return 0;
 }
 
-static int mtk8250_resume(struct device *dev)
+static int __maybe_unused mtk8250_resume(struct device *dev)
 {
 	struct mtk8250_data *data = dev_get_drvdata(dev);
 
@@ -263,7 +262,6 @@ static int mtk8250_resume(struct device *dev)
 
 	return 0;
 }
-#endif /* CONFIG_PM_SLEEP */
 
 static const struct dev_pm_ops mtk8250_pm_ops = {
 	SET_SYSTEM_SLEEP_PM_OPS(mtk8250_suspend, mtk8250_resume)
-- 
2.7.0



From dietmar.eggemann at arm.com  Mon Feb  8 05:41:25 2016
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Mon, 8 Feb 2016 13:41:25 +0000
Subject: [PATCH v3 4/6] arm64: Enable dynamic CPU capacity initialization
In-Reply-To: <20160208131320.GA7265@sirena.org.uk>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <1454500799-18451-5-git-send-email-juri.lelli@arm.com> <56B889F7.306@arm.com>
 <20160208131320.GA7265@sirena.org.uk>
Message-ID: <56B89B05.4090207@arm.com>

On 08/02/16 13:13, Mark Brown wrote:
> On Mon, Feb 08, 2016 at 12:28:39PM +0000, Dietmar Eggemann wrote:
>> On 03/02/16 11:59, Juri Lelli wrote:
> 
>>> +bool arch_wants_init_cpu_capacity(void)
>>> +{
>>> +	return true;
> 
>> Isn't this a little bit too simple? Not every ARM/ARM64 platform is a
>> heterogeneous one.
> 
> Does it matter?  Is there any problem with doing the callibration and
> having it say that all the CPUs performs very similarly?  My
> understanding was that this was simply saying it was worth checking to
> see if there was some asymmetry.
> 

No, the calibration would work on any platform. I can see your point,
you want to have this feature not depend on dt.



From mark.rutland at arm.com  Mon Feb  8 05:42:26 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 8 Feb 2016 13:42:26 +0000
Subject: [PATCH v2 4/4] iommu/arm-smmu: Add stub of_xlate() operation in
 SMMUv1/SMMUv2 driver
In-Reply-To: <CAALAos94ZHTKF5Gvjt7b56Yq+ZhhSSCN3xLdOWEpRvsrFohW6A@mail.gmail.com>
References: <1454908652-15317-1-git-send-email-anup.patel@broadcom.com>
 <1454908652-15317-5-git-send-email-anup.patel@broadcom.com>
 <20160208111829.GA13498@leverpostej>
 <CAALAos94ZHTKF5Gvjt7b56Yq+ZhhSSCN3xLdOWEpRvsrFohW6A@mail.gmail.com>
Message-ID: <20160208134225.GB7700@leverpostej>

On Mon, Feb 08, 2016 at 06:13:11PM +0530, Anup Patel wrote:
> On Mon, Feb 8, 2016 at 4:48 PM, Mark Rutland <mark.rutland at arm.com> wrote:
> > On Mon, Feb 08, 2016 at 10:47:32AM +0530, Anup Patel wrote:
> >> To allow use of large memory (> 4Gb) with 32bit devices we need to use
> >> IOMMU based DMA mappings for such 32bit devices. The IOMMU dt-bindings
> >> allows us do this by specifying 'iommus' attribute in 32bit device DT
> >> node. Unfortunately, specifying 'iommus' attribute does not work with
> >> current SMMUv1/SMMUv2 driver because it requires of_xlate() operation
> >> to be implemented by the driver.
> >>
> >> This patch adds a stub implementation of of_xlate() in SMMUv1/SMMUv2
> >> driver to allow usage of 'iommus' attribute in DT for 32bit devices.
> >>
> >> Signed-off-by: Anup Patel <anup.patel at broadcom.com>
> >> Reviewed-by: Ray Jui <rjui at broadcom.com>
> >> Reviewed-by: Scott Branden <sbranden at broadcom.com>
> >> ---
> >>  drivers/iommu/arm-smmu.c | 11 +++++++++++
> >>  1 file changed, 11 insertions(+)
> >>
> >> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> >> index 02cd67d..8e090d8 100644
> >> --- a/drivers/iommu/arm-smmu.c
> >> +++ b/drivers/iommu/arm-smmu.c
> >> @@ -1398,6 +1398,16 @@ static int arm_smmu_init_platform_device(struct device *dev,
> >>       return 0;
> >>  }
> >>
> >> +int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> >> +{
> >> +     /*
> >> +      * Nothing to do here because SMMU is already aware of all
> >> +      * MMU masters and their stream IDs using mmu-master attibute
> >> +      * SMMU DT node.
> >> +      */
> >> +     return 0;
> >> +}
> >
> > NAK to this.
> 
> I had no intention in continuing this change if I knew some work
> on generic IOMMU binding was in-progress. In fact, I had asked
> about alternate options previously. (Refer,
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/403128.html)

Ok.

To be clear, I expect the generic binding alone to be used for the case
you described, regardless of who implements that or how long it takes to
appear.

> > As previously mentioned by others [1], this is an abuse of the generic
> > iommu binding support code.
> >
> > The SMMU binding currently does not define its implementation of the
> > generic IOMMU binding. This series did not define what an SMMU's
> > #iommu-cells would be nor what the contained values would represent.
> > Therefore it is not valid to use an SMMU node with an iommus property as
> > the SMMu doesn't follwo the generic IOMMU binding.
> >
> > There is ongoing work to have generic iommu binding support for the
> > SMMU. In the absence of documentation for what this means for the
> > binding, I am worried that this hack harms that effort.
> 
> Thanks for the info, I would like to try this on Broadcom SoCs.
> 
> Whats the ETA of patches for generic IOMMU binding for SMMU?

That I do not know.

Robin, what's the state of the generic IOMMU binding support?

Thanks,
Mark.


From arnd at arndb.de  Mon Feb  8 05:48:18 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 08 Feb 2016 14:48:18 +0100
Subject: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host
 controller ECAM compliant
In-Reply-To: <1454935264-6076-3-git-send-email-gabriele.paoloni@huawei.com>
References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
 <1454935264-6076-3-git-send-email-gabriele.paoloni@huawei.com>
Message-ID: <3532826.pJr5R5Xa4c@wuerfel>

On Monday 08 February 2016 12:41:03 Gabriele Paoloni wrote:
> From: gabriele paoloni <gabriele.paoloni at huawei.com>
> 
> This patch modifies the current Hip05/Hip06 PCIe host controller
> driver to make it ECAM compliant. This is needed in preparation
> for the ACPI based driver to allow both DT and ACPI drivers to
> use the same BIOS (that configure the Designware iATUs).
> 
> Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
> Signed-off-by: Dongdong Liu <liudongdong3 at huawei.com>
> 

Doesn't this break backwards compatibility?

I think you need to use a new compatible string in the firmware
if you change the register layout, and then change the driver
to support both the old and the new layout.

	Arnd


From robert.richter at caviumnetworks.com  Mon Feb  8 05:48:35 2016
From: robert.richter at caviumnetworks.com (Robert Richter)
Date: Mon, 8 Feb 2016 14:48:35 +0100
Subject: [PATCH 5/6] net: thunderx: bgx: Add log message when setting mac
 address
In-Reply-To: <56B8987D.7000901@cogentembedded.com>
References: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
 <1454933272-45005-6-git-send-email-sunil.kovvuri@gmail.com>
 <56B8987D.7000901@cogentembedded.com>
Message-ID: <20160208134835.GX24726@rric.localdomain>

On 08.02.16 16:30:37, Sergei Shtylyov wrote:
> >@@ -897,10 +898,13 @@ static int acpi_get_mac_address(struct acpi_device *adev, u8 *dst)
> >  		goto out;
> >
> >  	if (!is_valid_ether_addr(mac)) {
> >+		dev_warn(dev, "MAC address invalid: %pM\n", mac);
> 
>    dev_er(), maybe?

Since the driver may continue, my choice was a warning only.

-Robert

> 
> >  		ret = -EINVAL;
> >  		goto out;
> >  	}
> >
> >+	dev_info(dev, "MAC address set to: %pM\n", mac);
> >+
> >  	memcpy(dst, mac, ETH_ALEN);
> >  out:
> >  	return ret;
> [...]



From bjorn at mork.no  Mon Feb  8 05:49:41 2016
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Mon, 08 Feb 2016 14:49:41 +0100
Subject: [PATCH 5/6] net: thunderx: bgx: Add log message when setting mac
 address
In-Reply-To: <56B8987D.7000901@cogentembedded.com> (Sergei Shtylyov's message
 of "Mon, 8 Feb 2016 16:30:37 +0300")
References: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
 <1454933272-45005-6-git-send-email-sunil.kovvuri@gmail.com>
 <56B8987D.7000901@cogentembedded.com>
Message-ID: <87vb5z1fd6.fsf@nemi.mork.no>

Sergei Shtylyov <sergei.shtylyov at cogentembedded.com> writes:

>    dev_er(), maybe?

I like that!

It's often hard to know whether to print something or be quiet.
pr_er(), dev_er(), netdev_er() etc would be the perfect solution to that
problem.


Bj?rn


From arnd at arndb.de  Mon Feb  8 05:45:23 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 08 Feb 2016 14:45:23 +0100
Subject: [PATCH RFC] Add cpufreq support
In-Reply-To: <20160208131625.GI8294@vireshk>
References: <56B4D4BE.2040008@free.fr> <22002072.L04zy0K2AP@wuerfel>
 <20160208131625.GI8294@vireshk>
Message-ID: <7910928.pmJjZiV1Lk@wuerfel>

On Monday 08 February 2016 18:46:25 Viresh Kumar wrote:
> On 08-02-16, 14:10, Arnd Bergmann wrote:
> > I don't remember the exact discussion, but the compatible string is
> > exactly meant to do one thing: it tells you what you can or cannot do
> > with one device.
> 
> Yeah, and many people argued that we can't add two values to that
> string like: "cpufreq-dt" and "cpufreq-big-little" for same kind of
> OPP bindings, as a different compatible string should be required only
> if there is a difference in the bindings.
> 
> For example, if a platform (like ST did recently) adds more
> platform-specific properties, then they can define a new value of
> those strings.
>
> > I had not realized that we don't even have a compatible string
> > for opp-v2, so if we are missing that, we obviously can't compare
> > against that string.
> 
> The binding says that we can have a string, but its not compulsory
> yet. Its only used by STM as they have some specific properties of
> their own.

Right, so when those properties are required for that machine,
that makes it incompatible with the generic driver, and it should
really have its own compatible string.

That's why I said we could introduce a 'v3' with the meaning
it should have had to start with: compatible means actually
compatible with the driver.

I guess we could also start a blacklist and list all machines
that are not compatible with the generic binding before falling
back to using that driver.

> > I thought there was a compatible property in there that told us
> > whether the operating-points-v2/cooling-min-level/#cooling-cells/...
> > properties were considered valid.
> 
> Yeah, "OPP-v2" DT node can have a compatible string, which isn't
> compulsory as of now, but because of the reasons mentioned earlier, we
> can't use it to differentiate between drivers that use exactly same
> version of bindings.

Right, unless we introduce a new compatible string for future machines.

	Arnd


From arnd at arndb.de  Mon Feb  8 05:50:15 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 08 Feb 2016 14:50:15 +0100
Subject: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06
 controllers driver to preapare for ACPI
In-Reply-To: <1454935264-6076-2-git-send-email-gabriele.paoloni@huawei.com>
References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
 <1454935264-6076-2-git-send-email-gabriele.paoloni@huawei.com>
Message-ID: <2409806.1aGBrN4l0X@wuerfel>

On Monday 08 February 2016 12:41:02 Gabriele Paoloni wrote:
> +
> +/* HipXX PCIe host only supports 32-bit config access */
> +int hisi_pcie_common_cfg_read(void __iomem *reg_base, int where, int size,
> +			      u32 *val)
> +{
> +	u32 reg;
> +	u32 reg_val;
> +	void *walker = &reg_val;
> +
> +	walker += (where & 0x3);
> +	reg = where & ~0x3;
> +	reg_val = readl(reg_base + reg);
> +
> +	if (size == 1)
> +		*val = *(u8 __force *) walker;
> +	else if (size == 2)
> +		*val = *(u16 __force *) walker;
> +	else if (size == 4)
> +		*val = reg_val;
> +	else
> +		return PCIBIOS_BAD_REGISTER_NUMBER;
> +
> +	return PCIBIOS_SUCCESSFUL;
> +}

Isn't this the same hack that Qualcomm are using?

	Arnd


From sergei.shtylyov at cogentembedded.com  Mon Feb  8 05:51:22 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 8 Feb 2016 16:51:22 +0300
Subject: [PATCH 5/6] net: thunderx: bgx: Add log message when setting mac
 address
In-Reply-To: <87vb5z1fd6.fsf@nemi.mork.no>
References: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
 <1454933272-45005-6-git-send-email-sunil.kovvuri@gmail.com>
 <56B8987D.7000901@cogentembedded.com> <87vb5z1fd6.fsf@nemi.mork.no>
Message-ID: <56B89D5A.8070503@cogentembedded.com>

On 02/08/2016 04:49 PM, Bj?rn Mork wrote:

>>     dev_er(), maybe?
>
> I like that!
>
> It's often hard to know whether to print something or be quiet.
> pr_er(), dev_er(), netdev_er() etc would be the perfect solution to that
> problem.

    :-D
    Sorry for the typo...

> Bj?rn

MBR, Sergei



From arnd at arndb.de  Mon Feb  8 05:55:11 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 08 Feb 2016 14:55:11 +0100
Subject: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host
 Controllers
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1ECAC944@lhreml503-mbs>
References: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
 <1930535.mkCdtpUWq7@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECAC944@lhreml503-mbs>
Message-ID: <7297343.ktGck3KQJN@wuerfel>

On Monday 08 February 2016 13:17:58 Gabriele Paoloni wrote:
> 
> Now I have removed the dependency from designware but I still think
> the best location for the code is in "drivers/pci/host/":
> the ACPI quirks share the config read/write functions with the DT
> driver, moreover for other hosts in future I think it makes sense
> to stay in "drivers/pci/host/" as they could even share more init
> code with their respective DT versions...

I haven't really followed what is going on with ACPI. Do you expect
to see future machines come out that are not just implementing SBSA
but that still need to run ACPI? I thought this was just a hack
for some early machines that only run with ACPI but are not actually
compliant.

	Arnd


From daniel.lezcano at linaro.org  Mon Feb  8 06:00:56 2016
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 8 Feb 2016 15:00:56 +0100
Subject: [PATCH v2] clocksource/arm_arch_timer: Enable and verify MMIO
 access
In-Reply-To: <71bf617f4083b116b2aeab24f13fc5fed99a816f.1454327031.git.robin.murphy@arm.com>
References: <71bf617f4083b116b2aeab24f13fc5fed99a816f.1454327031.git.robin.murphy@arm.com>
Message-ID: <56B89F98.7020909@linaro.org>

On 02/01/2016 01:00 PM, Robin Murphy wrote:
> So far, we have been blindly assuming that having access to a
> memory-mapped timer frame implies that the individual elements of that
> frame frame are already enabled. Whilst it's the firmware's job to give
> us non-secure access to frames in the first place, we should not rely
> on implementations always being generous enough to also configure CNTACR
> for those non-secure frames (e.g. [1]).
>
> Explicitly enable feature-level access per-frame, and verify that the
> access we want is really implemented before trying to make use of it.
>
> [1]:https://github.com/ARM-software/tf-issues/issues/170
>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---

Hi Marc,

can you give your opinion on this patch ?

Thanks

   -- Daniel

> Changes from v1:
> - Remove CNTACR_RFRQ check since the "no access, CNTFRQ reads as zero"
>    case can be handled the same way the driver deals with the "CNTFRQ
>    accessible, but not programmed" case.
> - Reword the commit message to make more sense.
>
>   drivers/clocksource/arm_arch_timer.c | 36 ++++++++++++++++++++++++++++--------
>   1 file changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index c64d543..7c567f0 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -32,6 +32,14 @@
>   #define CNTTIDR		0x08
>   #define CNTTIDR_VIRT(n)	(BIT(1) << ((n) * 4))
>
> +#define CNTACR(n)	(0x40 + ((n) * 4))
> +#define CNTACR_RPCT	BIT(0)
> +#define CNTACR_RVCT	BIT(1)
> +#define CNTACR_RFRQ	BIT(2)
> +#define CNTACR_RVOFF	BIT(3)
> +#define CNTACR_RWVT	BIT(4)
> +#define CNTACR_RWPT	BIT(5)
> +
>   #define CNTVCT_LO	0x08
>   #define CNTVCT_HI	0x0c
>   #define CNTFRQ		0x10
> @@ -757,7 +765,6 @@ static void __init arch_timer_mem_init(struct device_node *np)
>   	}
>
>   	cnttidr = readl_relaxed(cntctlbase + CNTTIDR);
> -	iounmap(cntctlbase);
>
>   	/*
>   	 * Try to find a virtual capable frame. Otherwise fall back to a
> @@ -765,20 +772,31 @@ static void __init arch_timer_mem_init(struct device_node *np)
>   	 */
>   	for_each_available_child_of_node(np, frame) {
>   		int n;
> +		u32 cntacr;
>
>   		if (of_property_read_u32(frame, "frame-number", &n)) {
>   			pr_err("arch_timer: Missing frame-number\n");
> -			of_node_put(best_frame);
>   			of_node_put(frame);
> -			return;
> +			goto out;
>   		}
>
> -		if (cnttidr & CNTTIDR_VIRT(n)) {
> +		/* Try enabling everything, and see what sticks */
> +		cntacr = CNTACR_RFRQ | CNTACR_RWPT | CNTACR_RPCT |
> +			 CNTACR_RWVT | CNTACR_RVOFF | CNTACR_RVCT;
> +		writel_relaxed(cntacr, cntctlbase + CNTACR(n));
> +		cntacr = readl_relaxed(cntctlbase + CNTACR(n));
> +
> +		if ((cnttidr & CNTTIDR_VIRT(n)) &&
> +		    !(~cntacr & (CNTACR_RWVT | CNTACR_RVCT))) {
>   			of_node_put(best_frame);
>   			best_frame = frame;
>   			arch_timer_mem_use_virtual = true;
>   			break;
>   		}
> +
> +		if (~cntacr & (CNTACR_RWPT | CNTACR_RPCT))
> +			continue;
> +
>   		of_node_put(best_frame);
>   		best_frame = of_node_get(frame);
>   	}
> @@ -786,24 +804,26 @@ static void __init arch_timer_mem_init(struct device_node *np)
>   	base = arch_counter_base = of_iomap(best_frame, 0);
>   	if (!base) {
>   		pr_err("arch_timer: Can't map frame's registers\n");
> -		of_node_put(best_frame);
> -		return;
> +		goto out;
>   	}
>
>   	if (arch_timer_mem_use_virtual)
>   		irq = irq_of_parse_and_map(best_frame, 1);
>   	else
>   		irq = irq_of_parse_and_map(best_frame, 0);
> -	of_node_put(best_frame);
> +
>   	if (!irq) {
>   		pr_err("arch_timer: Frame missing %s irq",
>   		       arch_timer_mem_use_virtual ? "virt" : "phys");
> -		return;
> +		goto out;
>   	}
>
>   	arch_timer_detect_rate(base, np);
>   	arch_timer_mem_register(base, irq);
>   	arch_timer_common_init();
> +out:
> +	iounmap(cntctlbase);
> +	of_node_put(best_frame);
>   }
>   CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
>   		       arch_timer_mem_init);
>


-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From broonie at kernel.org  Mon Feb  8 06:02:57 2016
From: broonie at kernel.org (Mark Brown)
Date: Mon, 8 Feb 2016 14:02:57 +0000
Subject: [PATCH v7 0/9] Fix broken DMAFLUSHP on Rockchips platform
In-Reply-To: <20160208131419.GA19598@localhost>
References: <1453460812-8498-1-git-send-email-wxt@rock-chips.com>
 <56AF01B6.6030204@gmail.com> <20160208031134.GI2531@localhost>
 <3817335.PXCk0JfYDT@phil> <20160208131419.GA19598@localhost>
Message-ID: <20160208140257.GC7265@sirena.org.uk>

On Mon, Feb 08, 2016 at 06:44:19PM +0530, Vinod Koul wrote:
> On Mon, Feb 08, 2016 at 10:27:04AM +0100, Heiko Stuebner wrote:

> > I think the more regular way is for the driver maintainer to take the 
> > driver-specific stuff and the devicetree parts going through the specific arm-
> > tree. But if you really want to take the whole series, for patches 4,5,6

> Yes but that causes cross tree dependencies, which looking at this won't be
> a big problem, so I can safely merge dmaengine changes and rest can go thru
> ARM tree.

Not for the DT stuff - since the DT is supposed to be a stable ABI there
really shouldn't be any hard dependencies on things outside the DT.

> Typically submitter should say which tree he/she prefers, which was not
> provided..

It's the norm for DT stuff.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160208/42079e83/attachment.sig>

From antoine.tenart at free-electrons.com  Mon Feb  8 06:04:29 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon, 8 Feb 2016 15:04:29 +0100
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <56B86391.1030609@arm.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
 <56B86391.1030609@arm.com>
Message-ID: <20160208140429.GF4117@kwain>

Hi Marc,

On Mon, Feb 08, 2016 at 09:44:49AM +0000, Marc Zyngier wrote:
> On 08/02/16 09:16, Antoine Tenart wrote:
> > +
> > +static struct msi_domain_info alpine_msix_domain_info = {
> > +	.flags	= MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> > +		  MSI_FLAG_PCI_MSIX,
> 
> You can probably add MSI_FLAG_PCI_MSI

Are you sure such a flag is available? (Or am I missing something
obvious?).

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160208/18f7073a/attachment.sig>

From boris.brezillon at free-electrons.com  Mon Feb  8 06:06:14 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Mon, 8 Feb 2016 15:06:14 +0100
Subject: [PATCH v1] clocksource: atmel-pit: register as a sched_clock
In-Reply-To: <56B89910.3060305@linaro.org>
References: <1454606493-15094-1-git-send-email-romain.izard.pro@gmail.com>
 <56B89910.3060305@linaro.org>
Message-ID: <20160208150614.5e87133e@bbrezillon>

+ Alexandre

Hi Daniel,

On Mon, 8 Feb 2016 14:33:04 +0100
Daniel Lezcano <daniel.lezcano at linaro.org> wrote:

> On 02/04/2016 06:21 PM, Romain Izard wrote:
> > Register the counter of the Periodic Interval Timer as a possible source
> > for sched_clock. This provides a better precision than the jiffies-based
> > default.
> >
> > Signed-off-by: Romain Izard <romain.izard.pro at gmail.com>
> 
> Nicolas, Boris,
> 
> Are you ok with this patch ?

Not sure yet :). On most platforms we are also declaring a clocksource
based on the TCB IP, and this one provides a better precision than the
PIT clocksource.
What happens if the PIT is de-activated while it's still supposed to
provide the sched_clock(). Is there a way to flag the clocksource as
still needed so that the core does not shut it down by when the TCB
clocksource comes in.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


From marc.zyngier at arm.com  Mon Feb  8 06:09:25 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 8 Feb 2016 14:09:25 +0000
Subject: [PATCH v2] clocksource/arm_arch_timer: Enable and verify MMIO
 access
In-Reply-To: <56B89F98.7020909@linaro.org>
References: <71bf617f4083b116b2aeab24f13fc5fed99a816f.1454327031.git.robin.murphy@arm.com>
 <56B89F98.7020909@linaro.org>
Message-ID: <56B8A195.2050807@arm.com>

On 08/02/16 14:00, Daniel Lezcano wrote:
> On 02/01/2016 01:00 PM, Robin Murphy wrote:
>> So far, we have been blindly assuming that having access to a
>> memory-mapped timer frame implies that the individual elements of that
>> frame frame are already enabled. Whilst it's the firmware's job to give
>> us non-secure access to frames in the first place, we should not rely
>> on implementations always being generous enough to also configure CNTACR
>> for those non-secure frames (e.g. [1]).
>>
>> Explicitly enable feature-level access per-frame, and verify that the
>> access we want is really implemented before trying to make use of it.
>>
>> [1]:https://github.com/ARM-software/tf-issues/issues/170
>>
>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>> ---
> 
> Hi Marc,
> 
> can you give your opinion on this patch ?

This seems to do the right thing, so FWIW:

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From marc.zyngier at arm.com  Mon Feb  8 06:11:31 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 8 Feb 2016 14:11:31 +0000
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <20160208140429.GF4117@kwain>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
 <56B86391.1030609@arm.com> <20160208140429.GF4117@kwain>
Message-ID: <56B8A213.2020704@arm.com>

On 08/02/16 14:04, Antoine Tenart wrote:
> Hi Marc,
> 
> On Mon, Feb 08, 2016 at 09:44:49AM +0000, Marc Zyngier wrote:
>> On 08/02/16 09:16, Antoine Tenart wrote:
>>> +
>>> +static struct msi_domain_info alpine_msix_domain_info = {
>>> +	.flags	= MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
>>> +		  MSI_FLAG_PCI_MSIX,
>>
>> You can probably add MSI_FLAG_PCI_MSI
> 
> Are you sure such a flag is available? (Or am I missing something
> obvious?).

No, I'm just confused (first patch in the morning, what did you
expect?). It looks like we consider single MSI as a given, please ignore
my rambling...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From okaya at codeaurora.org  Mon Feb  8 06:11:32 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Mon, 8 Feb 2016 09:11:32 -0500
Subject: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host
 Controllers
In-Reply-To: <7297343.ktGck3KQJN@wuerfel>
References: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
 <1930535.mkCdtpUWq7@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECAC944@lhreml503-mbs>
 <7297343.ktGck3KQJN@wuerfel>
Message-ID: <56B8A214.8040203@codeaurora.org>

On 2/8/2016 8:55 AM, Arnd Bergmann wrote:
> I haven't really followed what is going on with ACPI. Do you expect
> to see future machines come out that are not just implementing SBSA
> but that still need to run ACPI? I thought this was just a hack
> for some early machines that only run with ACPI but are not actually
> compliant.
> 
> 	Arnd

I agree. We shouldn't be playing with half-baked ACPI solutions. We have seen
two variants already that claim to be ACPI compliant yet they do not tie into
anything inside ACPICA. 

The correct route is to use Tomasz's ACPI PCI root bridge driver and use the ACPI
framework.

If a platform has quirks, Tomasz's patches allow vendors add quirks too.

The combination of PCI host bridge driver + ACPI hack is not right.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


From adrian.hunter at intel.com  Mon Feb  8 06:09:37 2016
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Mon, 8 Feb 2016 16:09:37 +0200
Subject: [PATCH v4 00/13] mmc: use sdhci_pltfm_init for private allocation
 and clean up
In-Reply-To: <CAPDyKFpFSTYsAUCG9nFnnzmVsA3zm4hAPO8+6REArt9BJtn+0Q@mail.gmail.com>
References: <1453803353-6266-1-git-send-email-jszhang@marvell.com>
 <CAPDyKFpFSTYsAUCG9nFnnzmVsA3zm4hAPO8+6REArt9BJtn+0Q@mail.gmail.com>
Message-ID: <56B8A1A1.2080408@intel.com>

On 04/02/16 12:38, Ulf Hansson wrote:
> + Adrian
> 
> On 26 January 2016 at 11:15, Jisheng Zhang <jszhang at marvell.com> wrote:
>> These patches are to complete the TODOs in Commit 0e748234293f ("mmc:
>> sdhci: Add size for caller in init+register"), I.E:
>>
>> - todo: migrate clients to using allocation this way
>> - todo: remove priv variable once migration is complete
>>
>> Since v3:
>>  - based on v4.5-rc1
>>  - add Ludovic's ack for sdhci-of-at91 changes
>>  - fix use-after-free in some drivers: some host drivers still needs to
>>    access sdhci_pltfm_host->private after sdhci_pltfm_unregister(), but
>>    the private should be already freed by sdhci_pltfm_unregister.
>>  - add patch5 to fix one clk bug in sdhci_arasan_remove(). IMHO, It's
>>    better to add this patch to fixes rather than waiting for next merge
>>    window
>>
>> Since v2:
>>  - based on mmc next tree and remove all priv usage introduced in newly
>>    commits in this tree
>>  - don't break two lines if sdhci_pltfm_init() call could be put into
>>    one line. Thank Ludovic Desroches.
>>
>> Since v1:
>>  - add new patch03 to factorise sdhci_msm_pdata outisde of sdhci_msm_host.
>>    This is to fix drivers/mmc/host/sdhci-msm.c:440:32: warning: 'msm_host'
>>    is used uninitialized in this function [-Wuninitialized]
>>  - Add Arnd's Ack for all patches except patch3 which is new in v2
>>
>>
>> Jisheng Zhang (13):
>>   mmc: sdhci-bcm2835: use sdhci_pltfm_init for private allocation
>>   mmc: sdhci-esdhc-imx: use sdhci_pltfm_init for private allocation
>>   mmc: sdhci-msm: factorise sdhci_msm_pdata outisde of sdhci_msm_host
>>   mmc: sdhci-msm: use sdhci_pltfm_init for private allocation
>>   mmc: sdhci-of-arasan: fix clk issue in sdhci_arasan_remove()
>>   mmc: sdhci-of-arasan: use sdhci_pltfm_init for private allocation
>>   mmc: sdhci-of-at91: use sdhci_pltfm_init for private allocation
>>   mmc: sdhci-of-esdhc: use sdhci_pltfm_init for private allocation
>>   mmc: sdhci-pxav3: use sdhci_pltfm_init for private allocation
>>   mmc: sdhci-st: use sdhci_pltfm_init for private allocation
>>   mmc: sdhci-tegra: use sdhci_pltfm_init for private allocation
>>   mmc: sdhci-pxav2: remove unnecessary assignment of pltfm_host->priv
>>   mmc: sdhci-pltfm: remove priv variable from sdhci_pltfm_host
>>
>>  drivers/mmc/host/sdhci-bcm2835.c   | 14 +++----------
>>  drivers/mmc/host/sdhci-esdhc-imx.c | 38 ++++++++++++++++--------------------
>>  drivers/mmc/host/sdhci-msm.c       | 25 +++++++++++-------------
>>  drivers/mmc/host/sdhci-of-arasan.c | 33 +++++++++++++++----------------
>>  drivers/mmc/host/sdhci-of-at91.c   | 33 ++++++++++++++-----------------
>>  drivers/mmc/host/sdhci-of-esdhc.c  | 19 +++++++++---------
>>  drivers/mmc/host/sdhci-pltfm.h     |  1 -
>>  drivers/mmc/host/sdhci-pxav2.c     |  1 -
>>  drivers/mmc/host/sdhci-pxav3.c     | 20 ++++++++-----------
>>  drivers/mmc/host/sdhci-st.c        | 40 +++++++++++++++++++-------------------
>>  drivers/mmc/host/sdhci-tegra.c     | 21 +++++++-------------
>>  11 files changed, 106 insertions(+), 139 deletions(-)
>>
>> --
>> 2.7.0
>>
> 
> To avoid confusions. I don't intend to pick up any further sdhci
> patches, unless they are acked by Adrian Hunter.

The patches look OK, although patch 6 doesn't apply cleanly anymore.
Nevertheless:

Acked-by: Adrian Hunter <adrian.hunter at intel.com>



From antoine.tenart at free-electrons.com  Mon Feb  8 06:17:54 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon, 8 Feb 2016 15:17:54 +0100
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <alpine.DEB.2.11.1602081125560.25254@nanos>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
 <alpine.DEB.2.11.1602081125560.25254@nanos>
Message-ID: <20160208141754.GG4117@kwain>

Thomas,

On Mon, Feb 08, 2016 at 11:31:47AM +0100, Thomas Gleixner wrote:
> On Mon, 8 Feb 2016, Antoine Tenart wrote:
> > +static int alpine_msix_set_affinity(struct irq_data *irq_data,
> > +				    const struct cpumask *mask, bool force)
> > +{
> > +	int ret;
> > +
> > +	ret = irq_chip_set_affinity_parent(irq_data, mask, force);
> > +	return ret == IRQ_SET_MASK_OK ? IRQ_SET_MASK_OK_DONE : ret;
> 
> What's the point of this exercise? Why can't you just set the affinity
> callback to irq_chip_set_affinity_parent() ?

That's what done in irq-gic-v2m.c. Besides that, I see no point. I'll
update for v2.

> > +static struct irq_chip alpine_msix_irq_chip = {
> > +	.name			= "MSIx",
> > +	.irq_mask		= alpine_msix_mask_msi_irq,
> > +	.irq_unmask		= alpine_msix_unmask_msi_irq,
> > +	.irq_eoi		= irq_chip_eoi_parent,
> > +	.irq_set_affinity	= alpine_msix_set_affinity,
> > +};
> > +
> > +static int alpine_msix_allocate_sgi(struct alpine_msix_data *priv, int num_req)
> > +{
> > +	int first, i;
> > +
> > +	spin_lock(&priv->msi_map_lock);
> > +
> > +	first = bitmap_find_next_zero_area(priv->msi_map, priv->num_spis, 0,
> > +					   num_req, 0);
> > +	if (first >= priv->num_spis) {
> > +		spin_unlock(&priv->msi_map_lock);
> > +		return -ENOSPC;
> > +	}
> > +
> > +	for (i = 0; i < num_req; i++)
> > +		set_bit(first + i, priv->msi_map);
> 
>   bitmap_set() ??

Indeed, that's better :)

> > +	spin_unlock(&priv->msi_map_lock);
> > +
> > +	return priv->spi_first + first;
> > +}
> > +
> > +static void alpine_msix_free_sgi(struct alpine_msix_data *priv, unsigned sgi,
> > +				 int num_req)
> > +{
> > +	int i, first;
> > +
> > +	first = sgi - priv->spi_first;
> > +
> > +	spin_lock(&priv->msi_map_lock);
> > +
> > +	for (i = 0; i < num_req; i++)
> > +		clear_bit(first + i, priv->msi_map);
> 
>   bitmap_clear() ??

Ditto.

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160208/9197c055/attachment.sig>

From robert.jarzmik at free.fr  Mon Feb  8 06:18:51 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Mon,  8 Feb 2016 15:18:51 +0100
Subject: [PATCH] dmaengine: pxa_dma: fix the maximum requestor line
Message-ID: <1454941131-12308-1-git-send-email-robert.jarzmik@free.fr>

The current number of requestor lines is limited to 31. This was an
error of a previous commit, as this number is platform dependent, and is
actually :
 - for pxa25x: 40 requestor lines
 - for pxa27x: 74 requestor lines
 - for pxa3xx: 100 requestor lines

As the driver doesn't need to know the exact number, but only an
absolute maximum value above which is it not using any flow control, set
the maximum to 0x8000 requestor lines, which should never be reached.

The previous testing did not reveal the faulty constant as on pxa[23]xx
platforms, only camera, MSL and USB are above requestor 32, and in these
only the camera has a driver using dma.

Fixes: e87ffbdf0697 ("dmaengine: pxa_dma: fix the no-requestor case")
Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
 drivers/dma/pxa_dma.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index ca6c088edc8a..817a2bdc423d 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -53,6 +53,7 @@
 
 #define DRCMR_MAPVLD	BIT(7)	/* Map Valid (read / write) */
 #define DRCMR_CHLNUM	0x1f	/* mask for Channel Number (read / write) */
+#define DRCMR_MAXREQST	0x7fff	/* Maximum requestor line */
 
 #define DDADR_DESCADDR	0xfffffff0	/* Address of next descriptor (mask) */
 #define DDADR_STOP	BIT(0)	/* Stop (read / write) */
@@ -473,7 +474,7 @@ static void pxad_free_phy(struct pxad_chan *chan)
 		return;
 
 	/* clear the channel mapping in DRCMR */
-	if (chan->drcmr <= DRCMR_CHLNUM) {
+	if (chan->drcmr <= DRCMR_MAXREQST) {
 		reg = pxad_drcmr(chan->drcmr);
 		writel_relaxed(0, chan->phy->base + reg);
 	}
@@ -518,7 +519,7 @@ static void phy_enable(struct pxad_phy *phy, bool misaligned)
 		"%s(); phy=%p(%d) misaligned=%d\n", __func__,
 		phy, phy->idx, misaligned);
 
-	if (phy->vchan->drcmr <= DRCMR_CHLNUM) {
+	if (phy->vchan->drcmr <= DRCMR_MAXREQST) {
 		reg = pxad_drcmr(phy->vchan->drcmr);
 		writel_relaxed(DRCMR_MAPVLD | phy->idx, phy->base + reg);
 	}
@@ -922,7 +923,7 @@ static void pxad_get_config(struct pxad_chan *chan,
 		dev_addr = chan->cfg.src_addr;
 		*dev_src = dev_addr;
 		*dcmd |= PXA_DCMD_INCTRGADDR;
-		if (chan->drcmr <= DRCMR_CHLNUM)
+		if (chan->drcmr <= DRCMR_MAXREQST)
 			*dcmd |= PXA_DCMD_FLOWSRC;
 	}
 	if (dir == DMA_MEM_TO_DEV) {
@@ -931,7 +932,7 @@ static void pxad_get_config(struct pxad_chan *chan,
 		dev_addr = chan->cfg.dst_addr;
 		*dev_dst = dev_addr;
 		*dcmd |= PXA_DCMD_INCSRCADDR;
-		if (chan->drcmr <= DRCMR_CHLNUM)
+		if (chan->drcmr <= DRCMR_MAXREQST)
 			*dcmd |= PXA_DCMD_FLOWTRG;
 	}
 	if (dir == DMA_MEM_TO_MEM)
-- 
2.1.4



From gregory.clement at free-electrons.com  Mon Feb  8 06:23:21 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 08 Feb 2016 15:23:21 +0100
Subject: [GIT PULL] ARM: mvebu: cleanup for v4.6 (#1)
Message-ID: <8760xz2sdi.fsf@free-electrons.com>

Hi,

Here is the first pull request for cleanup for mvebu for v4.6.

Gregory

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.infradead.org/linux-mvebu.git tags/mvebu-cleanup-4.6-1

for you to fetch changes up to 727c62d29c3a0b982fb72ef993db95e9d2036e07:

  ARM: mv78xx0: use "depends on" instead of "if" after prompt (2016-01-25 16:43:16 +0100)

----------------------------------------------------------------
mvebu cleanup for 4.6 (part 1)

use "depends on" instead of "if" after prompt for mv78xx0

----------------------------------------------------------------
Masahiro Yamada (1):
      ARM: mv78xx0: use "depends on" instead of "if" after prompt

 arch/arm/mach-mv78xx0/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From gregory.clement at free-electrons.com  Mon Feb  8 06:23:49 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 08 Feb 2016 15:23:49 +0100
Subject: [GIT PULL] ARM: mvebu: drivers for v4.6 (#1)
Message-ID: <874mdj2scq.fsf@free-electrons.com>

Hi,

Here is the first pull request for drivers for mvebu for v4.6.

Gregory

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.infradead.org/linux-mvebu.git tags/mvebu-drivers-4.6-1

for you to fetch changes up to 1e78dbe717b1668e1660556930d952447c7c1197:

  ARM: orion: implement ARM delay timer (2016-01-27 10:50:17 +0100)

----------------------------------------------------------------
mvebu driver for 4.6 (part 1)

implement ARM delay timer for orion

----------------------------------------------------------------
Russell King (1):
      ARM: orion: implement ARM delay timer

 arch/arm/plat-orion/time.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From okaya at codeaurora.org  Mon Feb  8 06:24:39 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Mon, 8 Feb 2016 09:24:39 -0500
Subject: [PATCH V14 0/9] dma: add Qualcomm Technologies HIDMA driver
In-Reply-To: <20160208101432.GA1150@cbox>
References: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
 <20160208101432.GA1150@cbox>
Message-ID: <56B8A527.7010206@codeaurora.org>

Hi,

On 2/8/2016 5:14 AM, Christoffer Dall wrote:
> Hi Sinan,
> 
> On Thu, Feb 04, 2016 at 11:34:31PM -0500, Sinan Kaya wrote:
>> The Qualcomm Technologies HIDMA device has been designed
>> to support virtualization technology. The driver has been
>> divided into two to follow the hardware design.
>>
>> 1. HIDMA Management driver
>> 2. HIDMA Channel driver
>>
>> Each HIDMA HW consists of multiple channels. These channels
>> share some set of common parameters. These parameters are
>> initialized by the management driver during power up.
>> Same management driver is used for monitoring the execution
>> of the channels. Management driver can change the performance
>> behavior dynamically such as bandwidth allocation and
>> prioritization in the future.
>>
>> The management driver is executed in host context and
>> is the main management entity for all channels provided by
>> the device.
> 
> I'm not at all familiar with this kind of hardware.
> 

Let me help. 

> Once an entity (userspace or VM) has a HIDAM channel assigned via VFIO,
> how does it use it?  

HIDMA is a HW accelerator for memory operations like memcpy and memset. It fits
into the DMA engine framework.

There are two classes of DMA HW. These are slave DMA and standalone DMA. Slave DMA
is generally related to another piece of HW that needs DMA for moving data. 
Standalone DMA is intended for OS/CPU consumption not HW. These can be used to offload
crypto operations (XOR) or other memory transactions (memcpy and memset) that are
lengthy. 

Once the HIDMA channel is assigned to the guest machine, guest operating system uses the
DMA channel to offload memory operations as HIDMA only supports memcpy. 

IOMMU HW provides the isolation from the rest of the host kernel or from other guest machines.

> Is it used in relation with another device to
> perform DMA on its behalf or is a HIDMA channel something that's useful
> on its own?

It is standalone only. The relationship you are referring to is known as slave DMA engine. 
HIDMA does not support slave DMA. HIDMA only supports memcpy and memset in HW and only memcpy in SW
as the memset support has been removed from the kernel long time ago.

> 
> Thanks,
> -Christoffer
> 


-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


From gregory.clement at free-electrons.com  Mon Feb  8 06:25:01 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 08 Feb 2016 15:25:01 +0100
Subject: [GIT PULL] ARM: mvebu: dt for v4.6 (#1)
Message-ID: <8737t32saq.fsf@free-electrons.com>

Hi,

Here is the first pull request for dt for mvebu for v4.6.
This one is based on v4.5-rc3 because it depends on fixes merged
previously.

Gregory

The following changes since commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95:

  Linux 4.5-rc3 (2016-02-07 15:38:30 -0800)

are available in the git repository at:

  git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-4.6-1

for you to fetch changes up to ebe1adff92de94f1ec48a46d9afa74ba967674dc:

  ARM: dts: kirkwood: add device tree for buffalo linkstation ls-qvl (2016-02-08 09:39:41 +0100)

----------------------------------------------------------------
mvebu dt for 4.6 (part 1)

- Improve Armada 388 device tree (SATA and XHCI)
- Fix SD Card and audio support for OpenRD board
- Provide template for RS-232/485 configuration for the same board
- Use a common dtsi file for linkstation boards
- Add support for Buffalo Linkstation LS-QVL

----------------------------------------------------------------
Aaro Koskinen (4):
      ARM: DTS: kirkwood-openrd: fix pin names for UART/SD selection
      ARM: DTS: kirkwood-openrd: fix SD slot default configuration
      ARM: DTS: kirkwood-openrd: provide template for RS-232/485 configuration
      ARM: DTS: kirkwood-openrd-client: fix audio

Gregory CLEMENT (2):
      ARM: mvebu: use usb-nop-xceiv PHY for the xhci nodes on Armada 388 GP
      ARM: mvebu: Update the mpp63 function in the device tree on Armada 370

Mario Lange (1):
      ARM: dts: kirkwood: add device tree for buffalo linkstation ls-qvl

Roger Shimizu (3):
      ARM: dts: kirkwood: relicense dts of ls-wvl/vl and ls-wxl/wsxl under GPLv2/X11
      ARM: dts: kirkwood: split lswxl dts to linkstation lswsxl and lswxl
      ARM: dts: kirkwood: split lswvl dts to linkstation lsvl and lswvl

Thomas Petazzoni (2):
      ARM: mvebu: adjust board name and compatible for Armada 388 GP
      ARM: mvebu: use regulator-boot-on for SATA regulators on Armada 388 GP

 .../devicetree/bindings/arm/marvell,kirkwood.txt   |   7 +-
 .../pinctrl/marvell,armada-370-pinctrl.txt         |   5 +-
 arch/arm/boot/dts/Makefile                         |   7 +-
 arch/arm/boot/dts/armada-370-mirabox.dts           |   2 +-
 arch/arm/boot/dts/armada-370-netgear-rn104.dts     |   2 +-
 arch/arm/boot/dts/armada-370-synology-ds213j.dts   |   2 +-
 arch/arm/boot/dts/armada-388-gp.dts                |  36 +--
 arch/arm/boot/dts/kirkwood-linkstation-6282.dtsi   | 192 +++++++++++++
 .../boot/dts/kirkwood-linkstation-duo-6281.dtsi    | 186 +++++++++++++
 arch/arm/boot/dts/kirkwood-linkstation-lsqvl.dts   | 135 +++++++++
 arch/arm/boot/dts/kirkwood-linkstation-lsvl.dts    |  57 ++++
 arch/arm/boot/dts/kirkwood-linkstation-lswsxl.dts  |  57 ++++
 arch/arm/boot/dts/kirkwood-linkstation-lswvl.dts   | 112 ++++++++
 arch/arm/boot/dts/kirkwood-linkstation-lswxl.dts   | 116 ++++++++
 arch/arm/boot/dts/kirkwood-linkstation.dtsi        | 202 ++++++++++++++
 arch/arm/boot/dts/kirkwood-lswvl.dts               | 302 ---------------------
 arch/arm/boot/dts/kirkwood-lswxl.dts               | 302 ---------------------
 arch/arm/boot/dts/kirkwood-openrd-client.dts       |   6 +-
 arch/arm/boot/dts/kirkwood-openrd.dtsi             |  41 ++-
 arch/arm/boot/dts/kirkwood.dtsi                    |   2 +-
 20 files changed, 1137 insertions(+), 634 deletions(-)
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation-6282.dtsi
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation-duo-6281.dtsi
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation-lsqvl.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation-lsvl.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation-lswsxl.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation-lswvl.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation-lswxl.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation.dtsi
 delete mode 100644 arch/arm/boot/dts/kirkwood-lswvl.dts
 delete mode 100644 arch/arm/boot/dts/kirkwood-lswxl.dts

--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From arnd at arndb.de  Mon Feb  8 06:24:57 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  8 Feb 2016 15:24:57 +0100
Subject: [PATCH] ARM: ks8695: fix __initdata annotation
Message-ID: <1454941509-2773774-1-git-send-email-arnd@arndb.de>

Clang complains about the __initdata section attribute being in the
wrong place in two files of ks8695:

arch/arm/mach-ks8695/cpu.c:37:31: error: '__section__' attribute only applies to functions and global variables
arch/arm/mach-ks8695/board-og.c:83:31: error: '__section__' attribute only applies to functions and global variables

This moves the attribute to the correct place.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-ks8695/board-og.c | 2 +-
 arch/arm/mach-ks8695/cpu.c      | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-ks8695/board-og.c b/arch/arm/mach-ks8695/board-og.c
index 1f4f2f4f25bb..fa1a7c2ca2bb 100644
--- a/arch/arm/mach-ks8695/board-og.c
+++ b/arch/arm/mach-ks8695/board-og.c
@@ -80,7 +80,7 @@ static void __init og_pci_bus_reset(void)
 #define	S8250_VIRT	0xf4000000
 #define	S8250_SIZE	0x00100000
 
-static struct __initdata map_desc og_io_desc[] = {
+static struct map_desc __initdata og_io_desc[] = {
 	{
 		.virtual	= S8250_VIRT,
 		.pfn		= __phys_to_pfn(S8250_PHYS),
diff --git a/arch/arm/mach-ks8695/cpu.c b/arch/arm/mach-ks8695/cpu.c
index 474a050da85b..f56937890e3a 100644
--- a/arch/arm/mach-ks8695/cpu.c
+++ b/arch/arm/mach-ks8695/cpu.c
@@ -34,7 +34,7 @@
 #include <mach/regs-misc.h>
 
 
-static struct __initdata map_desc ks8695_io_desc[] = {
+static struct map_desc __initdata ks8695_io_desc[] = {
 	{
 		.virtual	= (unsigned long)KS8695_IO_VA,
 		.pfn		= __phys_to_pfn(KS8695_IO_PA),
-- 
2.7.0



From gregory.clement at free-electrons.com  Mon Feb  8 06:25:23 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 08 Feb 2016 15:25:23 +0100
Subject: [GIT PULL] ARM: mvebu: defconfig for v4.6 (#1)
Message-ID: <871t8n2sa4.fsf@free-electrons.com>

Hi,

Here is the first pull request for defconfig for mvebu for v4.6.

Gregory

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.infradead.org/linux-mvebu.git tags/mvebu-defconfig-4.6-1

for you to fetch changes up to e1995f5586c9a60eefb188bc4ce3d4f37a6b835b:

  ARM: mvebu_v5_defconfig: Enable sound module needed for OpenRD (2016-01-26 09:40:58 +0100)

----------------------------------------------------------------
mvebu defconfig for 4.6 (part 1)

- Enable sound module needed for OpenRD in mvebu_v5_defconfig
- Add USB nop xceiv support in mvebu_v7_defconfig

----------------------------------------------------------------
Gregory CLEMENT (1):
      ARM: mvebu: Add USB nop xceiv support in mvebu_v7_defconfig

Martin Michlmayr (1):
      ARM: mvebu_v5_defconfig: Enable sound module needed for OpenRD

 arch/arm/configs/mvebu_v5_defconfig | 1 +
 arch/arm/configs/mvebu_v7_defconfig | 1 +
 2 files changed, 2 insertions(+)

--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From arnd at arndb.de  Mon Feb  8 06:25:56 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  8 Feb 2016 15:25:56 +0100
Subject: [PATCH 1/3] ARM: pass -march=armv7-a when building NEON files with
 clang
Message-ID: <1454941613-2775081-1-git-send-email-arnd@arndb.de>

clang ignores the -mfpu=neon flag when building with -march=armv6:

In file included from lib/raid6/neon1.c:27:
clang/3.8.0/include/arm_neon.h:28:2: error: "NEON support not enabled"

There is no real need to build the file with -march=armv6 in a
multi-CPU enabled kernel, as nothing in here will ever get called
on an ARMv6 CPU. Adding -march=armv7 doesn't hurt and can only
improve the code quality.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/lib/Makefile | 2 +-
 lib/raid6/Makefile    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 6c7a5b715584..5f6c7eb62cc3 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -39,7 +39,7 @@ $(obj)/csumpartialcopy.o:	$(obj)/csumpartialcopygeneric.S
 $(obj)/csumpartialcopyuser.o:	$(obj)/csumpartialcopygeneric.S
 
 ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
-  NEON_FLAGS			:= -mfloat-abi=softfp -mfpu=neon
+  NEON_FLAGS			:= -mfloat-abi=softfp -mfpu=neon -march=armv7-a
   CFLAGS_xor-neon.o		+= $(NEON_FLAGS)
   obj-$(CONFIG_XOR_BLOCKS)	+= xor-neon.o
 endif
diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
index 3b10a48fa040..4ef3e800fb39 100644
--- a/lib/raid6/Makefile
+++ b/lib/raid6/Makefile
@@ -23,7 +23,7 @@ endif
 ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
 NEON_FLAGS := -ffreestanding
 ifeq ($(ARCH),arm)
-NEON_FLAGS += -mfloat-abi=softfp -mfpu=neon
+NEON_FLAGS += -mfloat-abi=softfp -mfpu=neon -march=armv7-a
 endif
 ifeq ($(ARCH),arm64)
 CFLAGS_REMOVE_neon1.o += -mgeneral-regs-only
-- 
2.7.0



From arnd at arndb.de  Mon Feb  8 06:25:57 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  8 Feb 2016 15:25:57 +0100
Subject: [PATCH 2/3] ARM: fix copypage-*.c building with clang
In-Reply-To: <1454941613-2775081-1-git-send-email-arnd@arndb.de>
References: <1454941613-2775081-1-git-send-email-arnd@arndb.de>
Message-ID: <1454941613-2775081-2-git-send-email-arnd@arndb.de>

clang does not allow inline assembly in __naked functions to
have any register parameters and throws an error:

arch/arm/mm/copypage-v4wb.c:47:9: error: parameter references not allowed in naked functions
        : "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64));

Fortunately, all of these functions are trivial to convert to
using the registers directly.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mm/copypage-feroceon.c |  4 ++--
 arch/arm/mm/copypage-v4mc.c     | 26 +++++++++++++-------------
 arch/arm/mm/copypage-v4wb.c     |  4 ++--
 arch/arm/mm/copypage-v4wt.c     |  4 ++--
 arch/arm/mm/copypage-xsc3.c     |  4 ++--
 arch/arm/mm/copypage-xscale.c   |  4 ++--
 6 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mm/copypage-feroceon.c b/arch/arm/mm/copypage-feroceon.c
index 49ee0c1a7209..e69bf2f15f32 100644
--- a/arch/arm/mm/copypage-feroceon.c
+++ b/arch/arm/mm/copypage-feroceon.c
@@ -18,7 +18,7 @@ feroceon_copy_user_page(void *kto, const void *kfrom)
 {
 	asm("\
 	stmfd	sp!, {r4-r9, lr}		\n\
-	mov	ip, %2				\n\
+	mov	ip, %0				\n\
 1:	mov	lr, r1				\n\
 	ldmia	r1!, {r2 - r9}			\n\
 	pld	[lr, #32]			\n\
@@ -64,7 +64,7 @@ feroceon_copy_user_page(void *kto, const void *kfrom)
 	mcr	p15, 0, ip, c7, c10, 4		@ drain WB\n\
 	ldmfd	sp!, {r4-r9, pc}"
 	:
-	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE));
+	: "I" (PAGE_SIZE));
 }
 
 void feroceon_copy_user_highpage(struct page *to, struct page *from,
diff --git a/arch/arm/mm/copypage-v4mc.c b/arch/arm/mm/copypage-v4mc.c
index 1267e64133b9..ea89722c00db 100644
--- a/arch/arm/mm/copypage-v4mc.c
+++ b/arch/arm/mm/copypage-v4mc.c
@@ -45,23 +45,23 @@ mc_copy_user_page(void *from, void *to)
 {
 	asm volatile(
 	"stmfd	sp!, {r4, lr}			@ 2\n\
-	mov	r4, %2				@ 1\n\
-	ldmia	%0!, {r2, r3, ip, lr}		@ 4\n\
-1:	mcr	p15, 0, %1, c7, c6, 1		@ 1   invalidate D line\n\
-	stmia	%1!, {r2, r3, ip, lr}		@ 4\n\
-	ldmia	%0!, {r2, r3, ip, lr}		@ 4+1\n\
-	stmia	%1!, {r2, r3, ip, lr}		@ 4\n\
-	ldmia	%0!, {r2, r3, ip, lr}		@ 4\n\
-	mcr	p15, 0, %1, c7, c6, 1		@ 1   invalidate D line\n\
-	stmia	%1!, {r2, r3, ip, lr}		@ 4\n\
-	ldmia	%0!, {r2, r3, ip, lr}		@ 4\n\
+	mov	r4, %0				@ 1\n\
+	ldmia	r0!, {r2, r3, ip, lr}		@ 4\n\
+1:	mcr	p15, 0, r1, c7, c6, 1		@ 1   invalidate D line\n\
+	stmia	r1!, {r2, r3, ip, lr}		@ 4\n\
+	ldmia	r0!, {r2, r3, ip, lr}		@ 4+1\n\
+	stmia	r1!, {r2, r3, ip, lr}		@ 4\n\
+	ldmia	r0!, {r2, r3, ip, lr}		@ 4\n\
+	mcr	p15, 0, r1, c7, c6, 1		@ 1   invalidate D line\n\
+	stmia	r1!, {r2, r3, ip, lr}		@ 4\n\
+	ldmia	r0!, {r2, r3, ip, lr}		@ 4\n\
 	subs	r4, r4, #1			@ 1\n\
-	stmia	%1!, {r2, r3, ip, lr}		@ 4\n\
-	ldmneia	%0!, {r2, r3, ip, lr}		@ 4\n\
+	stmia	r1!, {r2, r3, ip, lr}		@ 4\n\
+	ldmneia	r0!, {r2, r3, ip, lr}		@ 4\n\
 	bne	1b				@ 1\n\
 	ldmfd	sp!, {r4, pc}			@ 3"
 	:
-	: "r" (from), "r" (to), "I" (PAGE_SIZE / 64));
+	: "I" (PAGE_SIZE / 64));
 }
 
 void v4_mc_copy_user_highpage(struct page *to, struct page *from,
diff --git a/arch/arm/mm/copypage-v4wb.c b/arch/arm/mm/copypage-v4wb.c
index 067d0fdd630c..7ea9cf07bd5c 100644
--- a/arch/arm/mm/copypage-v4wb.c
+++ b/arch/arm/mm/copypage-v4wb.c
@@ -27,7 +27,7 @@ v4wb_copy_user_page(void *kto, const void *kfrom)
 {
 	asm("\
 	stmfd	sp!, {r4, lr}			@ 2\n\
-	mov	r2, %2				@ 1\n\
+	mov	r2, %0				@ 1\n\
 	ldmia	r1!, {r3, r4, ip, lr}		@ 4\n\
 1:	mcr	p15, 0, r0, c7, c6, 1		@ 1   invalidate D line\n\
 	stmia	r0!, {r3, r4, ip, lr}		@ 4\n\
@@ -44,7 +44,7 @@ v4wb_copy_user_page(void *kto, const void *kfrom)
 	mcr	p15, 0, r1, c7, c10, 4		@ 1   drain WB\n\
 	ldmfd	 sp!, {r4, pc}			@ 3"
 	:
-	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64));
+	: "I" (PAGE_SIZE / 64));
 }
 
 void v4wb_copy_user_highpage(struct page *to, struct page *from,
diff --git a/arch/arm/mm/copypage-v4wt.c b/arch/arm/mm/copypage-v4wt.c
index b85c5da2e510..c742ab24efd6 100644
--- a/arch/arm/mm/copypage-v4wt.c
+++ b/arch/arm/mm/copypage-v4wt.c
@@ -25,7 +25,7 @@ v4wt_copy_user_page(void *kto, const void *kfrom)
 {
 	asm("\
 	stmfd	sp!, {r4, lr}			@ 2\n\
-	mov	r2, %2				@ 1\n\
+	mov	r2, %0				@ 1\n\
 	ldmia	r1!, {r3, r4, ip, lr}		@ 4\n\
 1:	stmia	r0!, {r3, r4, ip, lr}		@ 4\n\
 	ldmia	r1!, {r3, r4, ip, lr}		@ 4+1\n\
@@ -40,7 +40,7 @@ v4wt_copy_user_page(void *kto, const void *kfrom)
 	mcr	p15, 0, r2, c7, c7, 0		@ flush ID cache\n\
 	ldmfd	sp!, {r4, pc}			@ 3"
 	:
-	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64));
+	: "I" (PAGE_SIZE / 64));
 }
 
 void v4wt_copy_user_highpage(struct page *to, struct page *from,
diff --git a/arch/arm/mm/copypage-xsc3.c b/arch/arm/mm/copypage-xsc3.c
index 03a2042aced5..17e4e11c4612 100644
--- a/arch/arm/mm/copypage-xsc3.c
+++ b/arch/arm/mm/copypage-xsc3.c
@@ -34,7 +34,7 @@ xsc3_mc_copy_user_page(void *kto, const void *kfrom)
 {
 	asm("\
 	stmfd	sp!, {r4, r5, lr}		\n\
-	mov	lr, %2				\n\
+	mov	lr, %0				\n\
 						\n\
 	pld	[r1, #0]			\n\
 	pld	[r1, #32]			\n\
@@ -67,7 +67,7 @@ xsc3_mc_copy_user_page(void *kto, const void *kfrom)
 						\n\
 	ldmfd	sp!, {r4, r5, pc}"
 	:
-	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64 - 1));
+	: "I" (PAGE_SIZE / 64 - 1));
 }
 
 void xsc3_mc_copy_user_highpage(struct page *to, struct page *from,
diff --git a/arch/arm/mm/copypage-xscale.c b/arch/arm/mm/copypage-xscale.c
index 0fb85025344d..1034b4ce80cc 100644
--- a/arch/arm/mm/copypage-xscale.c
+++ b/arch/arm/mm/copypage-xscale.c
@@ -45,7 +45,7 @@ mc_copy_user_page(void *from, void *to)
 	 */
 	asm volatile(
 	"stmfd	sp!, {r4, r5, lr}		\n\
-	mov	lr, %2				\n\
+	mov	lr, %0				\n\
 	pld	[r0, #0]			\n\
 	pld	[r0, #32]			\n\
 	pld	[r1, #0]			\n\
@@ -81,7 +81,7 @@ mc_copy_user_page(void *from, void *to)
 	beq	2b				\n\
 	ldmfd	sp!, {r4, r5, pc}		"
 	:
-	: "r" (from), "r" (to), "I" (PAGE_SIZE / 64 - 1));
+	: "I" (PAGE_SIZE / 64 - 1));
 }
 
 void xscale_mc_copy_user_highpage(struct page *to, struct page *from,
-- 
2.7.0



From arnd at arndb.de  Mon Feb  8 06:25:58 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  8 Feb 2016 15:25:58 +0100
Subject: [PATCH 3/3] ARM: kprobes: use "I" constraint for inline assembly
 offsets
In-Reply-To: <1454941613-2775081-1-git-send-email-arnd@arndb.de>
References: <1454941613-2775081-1-git-send-email-arnd@arndb.de>
Message-ID: <1454941613-2775081-3-git-send-email-arnd@arndb.de>

build-testing with clang showed that the "J" constraint does not take
positive arguments on clang when building in for Thumb-2:

core.c:540:3: error: invalid operand for inline asm constraint 'J'

This has been reported as llvm bug https://llvm.org/bugs/show_bug.cgi?id=26061

However, looking at the source code in depth, I found that the
kernel is also wrong, and it should not use "J" at all, but should
use "I" to pass an immediate argument to the inline assembly when that
is used as an offset to an 'ldr' instruction rather than the 'sub'
argument.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/probes/kprobes/core.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
index a4ec240ee7ba..4b34b40ca917 100644
--- a/arch/arm/probes/kprobes/core.c
+++ b/arch/arm/probes/kprobes/core.c
@@ -570,10 +570,10 @@ void __kprobes jprobe_return(void)
 		:
 		: "r" (kcb->jprobe_saved_regs.ARM_sp),
 		  "I" (sizeof(struct pt_regs) * 2),
-		  "J" (offsetof(struct pt_regs, ARM_sp)),
-		  "J" (offsetof(struct pt_regs, ARM_pc)),
-		  "J" (offsetof(struct pt_regs, ARM_cpsr)),
-		  "J" (offsetof(struct pt_regs, ARM_lr))
+		  "I" (offsetof(struct pt_regs, ARM_sp)),
+		  "I" (offsetof(struct pt_regs, ARM_pc)),
+		  "I" (offsetof(struct pt_regs, ARM_cpsr)),
+		  "I" (offsetof(struct pt_regs, ARM_lr))
 		: "memory", "cc");
 }
 
-- 
2.7.0



From marc.zyngier at arm.com  Mon Feb  8 06:29:12 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 8 Feb 2016 14:29:12 +0000
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <20160208141754.GG4117@kwain>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
 <alpine.DEB.2.11.1602081125560.25254@nanos> <20160208141754.GG4117@kwain>
Message-ID: <56B8A638.1040903@arm.com>

On 08/02/16 14:17, Antoine Tenart wrote:
> Thomas,
> 
> On Mon, Feb 08, 2016 at 11:31:47AM +0100, Thomas Gleixner wrote:
>> On Mon, 8 Feb 2016, Antoine Tenart wrote:
>>> +static int alpine_msix_set_affinity(struct irq_data *irq_data,
>>> +				    const struct cpumask *mask, bool force)
>>> +{
>>> +	int ret;
>>> +
>>> +	ret = irq_chip_set_affinity_parent(irq_data, mask, force);
>>> +	return ret == IRQ_SET_MASK_OK ? IRQ_SET_MASK_OK_DONE : ret;
>>
>> What's the point of this exercise? Why can't you just set the affinity
>> callback to irq_chip_set_affinity_parent() ?
> 
> That's what done in irq-gic-v2m.c. Besides that, I see no point. I'll
> update for v2.

That's because there is no need to do another compose_msi_msg/write_msg
in msi_domain_set_affinity() once the affinity has been updated at the
GIC level. Alternatively, updating the GIC driver to always return
IRQ_SET_MASK_OK_DONE would be perfectly acceptable.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From arnd at arndb.de  Mon Feb  8 06:29:49 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  8 Feb 2016 15:29:49 +0100
Subject: [PATCH] pinctrl: coh901: fix initconst annotation
Message-ID: <1454941800-2776480-1-git-send-email-arnd@arndb.de>

Clang correctly points out that the section attribute for u300_gpio_confdata
is in the wrong place:

drivers/pinctrl/pinctrl-coh901.c:130:37: error: '__section__' attribute only applies to functions and global variables

This moves it from the type name to the variable, so it actually gets
discarded.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/pinctrl/pinctrl-coh901.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-coh901.c b/drivers/pinctrl/pinctrl-coh901.c
index cf7788df0f95..741b39eaeb8b 100644
--- a/drivers/pinctrl/pinctrl-coh901.c
+++ b/drivers/pinctrl/pinctrl-coh901.c
@@ -127,7 +127,7 @@ struct u300_gpio_confdata {
 }
 
 /* Initial configuration */
-static const struct __initconst u300_gpio_confdata
+static const struct u300_gpio_confdata __initconst
 bs335_gpio_config[U300_GPIO_NUM_PORTS][U300_GPIO_PINS_PER_PORT] = {
 	/* Port 0, pins 0-7 */
 	{
-- 
2.7.0



From ard.biesheuvel at linaro.org  Mon Feb  8 06:30:47 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 8 Feb 2016 15:30:47 +0100
Subject: [PATCH v5sub2 0/8] arm64: implement virtual KASLR
In-Reply-To: <20160208121430.GL6076@e104818-lin.cambridge.arm.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <CAKv+Gu-AhLcatkDsQVeoFGJ+pTEwaW1Hy9M-fY1-VWvRc_E47w@mail.gmail.com>
 <20160205173248.GJ6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_v1sXM7sivz+Uu86ZG3=Th7wqqh7M1N8wF7Ess4NdTZQ@mail.gmail.com>
 <CAGXu5j+JpwRrVy1b_h+LJ4sCzsT7BV9RdcD0CvR-4aVJQhCpvg@mail.gmail.com>
 <20160208121430.GL6076@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu-=RLS8Zgn_evmoUUSHqSVfaw9_hjVMgfg1FZGRDGFVag@mail.gmail.com>

On 8 February 2016 at 13:14, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Fri, Feb 05, 2016 at 12:42:30PM -0800, Kees Cook wrote:
>> On Fri, Feb 5, 2016 at 9:38 AM, Ard Biesheuvel
>> <ard.biesheuvel at linaro.org> wrote:
>> > On 5 February 2016 at 18:32, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> >> I'm still trying to get my head around how we merge those. Since I
>> >> assume akpm will push them during the merging window, part of your code
>> >> cannot be tested before.
>> >
>> > Actually, my original idea was for akpm to take them as a late merge
>> > after rebasing to -rc1, since they touch a variety of architectures,
>> > but I am not sure if that came across.
>> >
>> > You could always take the series through your tree instead, I guess?
>>
>> Traditionally akpm will de-duplicate patches he's carrying that appear
>> in another tree. I think it should be okay to carry them in both
>> places. (Though I'm CCing akpm just to see if I'm talking crazy.)
>
> For now, I'll merge this series in the arm64 tree and push it to next:
>
> http://lkml.kernel.org/r/1452007180-27411-1-git-send-email-ard.biesheuvel at linaro.org
>
> If there are any objections, I can drop the patches and do the
> BUILDTIME_EXTABLE_SORT disabling trick until they end up in mainline.
>

Latest version is here:
http://lkml.kernel.org/r/1453892123-17973-1-git-send-email-ard.biesheuvel at linaro.org
(only difference is an ack from that Alpha maintainter/supporter to
patches #1 and #2)

However, the arm64 patch (#6) now conflicts with futex.h in -rc3 after
the PAN fix, not sure how to best address that ...

-- 
Ard.


From daniel.lezcano at linaro.org  Mon Feb  8 06:30:56 2016
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Mon, 8 Feb 2016 15:30:56 +0100
Subject: [PATCH v2] clocksource/arm_arch_timer: Enable and verify MMIO
 access
In-Reply-To: <71bf617f4083b116b2aeab24f13fc5fed99a816f.1454327031.git.robin.murphy@arm.com>
References: <71bf617f4083b116b2aeab24f13fc5fed99a816f.1454327031.git.robin.murphy@arm.com>
Message-ID: <56B8A6A0.4080704@linaro.org>

On 02/01/2016 01:00 PM, Robin Murphy wrote:
> So far, we have been blindly assuming that having access to a
> memory-mapped timer frame implies that the individual elements of that
> frame frame are already enabled. Whilst it's the firmware's job to give
> us non-secure access to frames in the first place, we should not rely
> on implementations always being generous enough to also configure CNTACR
> for those non-secure frames (e.g. [1]).
>
> Explicitly enable feature-level access per-frame, and verify that the
> access we want is really implemented before trying to make use of it.
>
> [1]:https://github.com/ARM-software/tf-issues/issues/170
>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---

Applied to my tree for 4.6.

Thanks

   - Daniel



From arnd at arndb.de  Mon Feb  8 06:31:45 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  8 Feb 2016 15:31:45 +0100
Subject: [PATCH] ide: icside: remove incorrect initconst annotation
Message-ID: <1454941909-2778808-1-git-send-email-arnd@arndb.de>

The icside_probe function can be called for hotplugged devices, so
its reference to the __initconst icside_v6_port_info variable
may be invalid, as Kbuild points out:

WARNING: drivers/ide/icside.o(.text+0x338): Section mismatch in reference from the function icside_probe()
 to the (unknown reference) .init.rodata:(unknown)

Interestingly, this problem only shows up with clang but not
with gcc, which optimizes out the __initconst variable.

This removes the incorrect annotation.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/ide/icside.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ide/icside.c b/drivers/ide/icside.c
index 9f0a48e39b8a..80e933b296f6 100644
--- a/drivers/ide/icside.c
+++ b/drivers/ide/icside.c
@@ -451,7 +451,7 @@ err_free:
 	return ret;
 }
 
-static const struct ide_port_info icside_v6_port_info __initconst = {
+static const struct ide_port_info icside_v6_port_info = {
 	.init_dma		= icside_dma_off_init,
 	.port_ops		= &icside_v6_no_dma_port_ops,
 	.host_flags		= IDE_HFLAG_SERIALIZE | IDE_HFLAG_MMIO,
-- 
2.7.0



From arnd at arndb.de  Mon Feb  8 06:33:42 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  8 Feb 2016 15:33:42 +0100
Subject: [PATCH] net: am79c961a: avoid %? in inline assembly
Message-ID: <1454942025-2779812-1-git-send-email-arnd@arndb.de>

The am79c961a.c driver fails to build with clang because of an
unusual inline assembly construct:

drivers/net/ethernet/amd/am79c961a.c:53:7: error: invalid % escape in inline assembly string
 "str%?h        %1, [%2]        @ NET_RAP\n\t"

The same change has been done a decade ago in arch/arm as of
6a39dd6222dd ("[ARM] 3759/2: Remove uses of %?"), but apparently
some drivers were missed.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/net/ethernet/amd/am79c961a.c | 64 ++++++++++++++++++------------------
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/drivers/net/ethernet/amd/am79c961a.c b/drivers/net/ethernet/amd/am79c961a.c
index 87e727b921dc..fcdf5dda448f 100644
--- a/drivers/net/ethernet/amd/am79c961a.c
+++ b/drivers/net/ethernet/amd/am79c961a.c
@@ -50,8 +50,8 @@ static const char version[] =
 static void write_rreg(u_long base, u_int reg, u_int val)
 {
 	asm volatile(
-	"str%?h	%1, [%2]	@ NET_RAP\n\t"
-	"str%?h	%0, [%2, #-4]	@ NET_RDP"
+	"strh	%1, [%2]	@ NET_RAP\n\t"
+	"strh	%0, [%2, #-4]	@ NET_RDP"
 	:
 	: "r" (val), "r" (reg), "r" (ISAIO_BASE + 0x0464));
 }
@@ -60,8 +60,8 @@ static inline unsigned short read_rreg(u_long base_addr, u_int reg)
 {
 	unsigned short v;
 	asm volatile(
-	"str%?h	%1, [%2]	@ NET_RAP\n\t"
-	"ldr%?h	%0, [%2, #-4]	@ NET_RDP"
+	"strh	%1, [%2]	@ NET_RAP\n\t"
+	"ldrh	%0, [%2, #-4]	@ NET_RDP"
 	: "=r" (v)
 	: "r" (reg), "r" (ISAIO_BASE + 0x0464));
 	return v;
@@ -70,8 +70,8 @@ static inline unsigned short read_rreg(u_long base_addr, u_int reg)
 static inline void write_ireg(u_long base, u_int reg, u_int val)
 {
 	asm volatile(
-	"str%?h	%1, [%2]	@ NET_RAP\n\t"
-	"str%?h	%0, [%2, #8]	@ NET_IDP"
+	"strh	%1, [%2]	@ NET_RAP\n\t"
+	"strh	%0, [%2, #8]	@ NET_IDP"
 	:
 	: "r" (val), "r" (reg), "r" (ISAIO_BASE + 0x0464));
 }
@@ -80,8 +80,8 @@ static inline unsigned short read_ireg(u_long base_addr, u_int reg)
 {
 	u_short v;
 	asm volatile(
-	"str%?h	%1, [%2]	@ NAT_RAP\n\t"
-	"ldr%?h	%0, [%2, #8]	@ NET_IDP\n\t"
+	"strh	%1, [%2]	@ NAT_RAP\n\t"
+	"ldrh	%0, [%2, #8]	@ NET_IDP\n\t"
 	: "=r" (v)
 	: "r" (reg), "r" (ISAIO_BASE + 0x0464));
 	return v;
@@ -96,7 +96,7 @@ am_writebuffer(struct net_device *dev, u_int offset, unsigned char *buf, unsigne
 	offset = ISAMEM_BASE + (offset << 1);
 	length = (length + 1) & ~1;
 	if ((int)buf & 2) {
-		asm volatile("str%?h	%2, [%0], #4"
+		asm volatile("strh	%2, [%0], #4"
 		 : "=&r" (offset) : "0" (offset), "r" (buf[0] | (buf[1] << 8)));
 		buf += 2;
 		length -= 2;
@@ -104,20 +104,20 @@ am_writebuffer(struct net_device *dev, u_int offset, unsigned char *buf, unsigne
 	while (length > 8) {
 		register unsigned int tmp asm("r2"), tmp2 asm("r3");
 		asm volatile(
-			"ldm%?ia	%0!, {%1, %2}"
+			"ldmia	%0!, {%1, %2}"
 			: "+r" (buf), "=&r" (tmp), "=&r" (tmp2));
 		length -= 8;
 		asm volatile(
-			"str%?h	%1, [%0], #4\n\t"
-			"mov%?	%1, %1, lsr #16\n\t"
-			"str%?h	%1, [%0], #4\n\t"
-			"str%?h	%2, [%0], #4\n\t"
-			"mov%?	%2, %2, lsr #16\n\t"
-			"str%?h	%2, [%0], #4"
+			"strh	%1, [%0], #4\n\t"
+			"mov	%1, %1, lsr #16\n\t"
+			"strh	%1, [%0], #4\n\t"
+			"strh	%2, [%0], #4\n\t"
+			"mov	%2, %2, lsr #16\n\t"
+			"strh	%2, [%0], #4"
 		: "+r" (offset), "=&r" (tmp), "=&r" (tmp2));
 	}
 	while (length > 0) {
-		asm volatile("str%?h	%2, [%0], #4"
+		asm volatile("strh	%2, [%0], #4"
 		 : "=&r" (offset) : "0" (offset), "r" (buf[0] | (buf[1] << 8)));
 		buf += 2;
 		length -= 2;
@@ -132,23 +132,23 @@ am_readbuffer(struct net_device *dev, u_int offset, unsigned char *buf, unsigned
 	if ((int)buf & 2) {
 		unsigned int tmp;
 		asm volatile(
-			"ldr%?h	%2, [%0], #4\n\t"
-			"str%?b	%2, [%1], #1\n\t"
-			"mov%?	%2, %2, lsr #8\n\t"
-			"str%?b	%2, [%1], #1"
+			"ldrh	%2, [%0], #4\n\t"
+			"strb	%2, [%1], #1\n\t"
+			"mov	%2, %2, lsr #8\n\t"
+			"strb	%2, [%1], #1"
 		: "=&r" (offset), "=&r" (buf), "=r" (tmp): "0" (offset), "1" (buf));
 		length -= 2;
 	}
 	while (length > 8) {
 		register unsigned int tmp asm("r2"), tmp2 asm("r3"), tmp3;
 		asm volatile(
-			"ldr%?h	%2, [%0], #4\n\t"
-			"ldr%?h	%4, [%0], #4\n\t"
-			"ldr%?h	%3, [%0], #4\n\t"
-			"orr%?	%2, %2, %4, lsl #16\n\t"
-			"ldr%?h	%4, [%0], #4\n\t"
-			"orr%?	%3, %3, %4, lsl #16\n\t"
-			"stm%?ia	%1!, {%2, %3}"
+			"ldrh	%2, [%0], #4\n\t"
+			"ldrh	%4, [%0], #4\n\t"
+			"ldrh	%3, [%0], #4\n\t"
+			"orr	%2, %2, %4, lsl #16\n\t"
+			"ldrh	%4, [%0], #4\n\t"
+			"orr	%3, %3, %4, lsl #16\n\t"
+			"stmia	%1!, {%2, %3}"
 		: "=&r" (offset), "=&r" (buf), "=r" (tmp), "=r" (tmp2), "=r" (tmp3)
 		: "0" (offset), "1" (buf));
 		length -= 8;
@@ -156,10 +156,10 @@ am_readbuffer(struct net_device *dev, u_int offset, unsigned char *buf, unsigned
 	while (length > 0) {
 		unsigned int tmp;
 		asm volatile(
-			"ldr%?h	%2, [%0], #4\n\t"
-			"str%?b	%2, [%1], #1\n\t"
-			"mov%?	%2, %2, lsr #8\n\t"
-			"str%?b	%2, [%1], #1"
+			"ldrh	%2, [%0], #4\n\t"
+			"strb	%2, [%1], #1\n\t"
+			"mov	%2, %2, lsr #8\n\t"
+			"strb	%2, [%1], #1"
 		: "=&r" (offset), "=&r" (buf), "=r" (tmp) : "0" (offset), "1" (buf));
 		length -= 2;
 	}
-- 
2.7.0



From arnd at arndb.de  Mon Feb  8 06:34:21 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  8 Feb 2016 15:34:21 +0100
Subject: [PATCH] lkdtm: mark execute_location as noinline
Message-ID: <1454942069-2780643-1-git-send-email-arnd@arndb.de>

The kernel sometimes fails to link when lkdrm is built-in and
compiled with clang:

relocation truncated to fit: R_ARM_THM_CALL against `.bss'

The reason here is that a relocation from .text to .bss fails to
generate a trampoline because .bss is not an executable section.

Marking the function 'noinline' turns the relative branch to .bss
into an absolute branch to the function argument, and that works
fine.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/misc/lkdtm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/lkdtm.c b/drivers/misc/lkdtm.c
index 11fdadc68e53..5c1351b19029 100644
--- a/drivers/misc/lkdtm.c
+++ b/drivers/misc/lkdtm.c
@@ -335,7 +335,7 @@ static noinline void corrupt_stack(void)
 	memset((void *)data, 0, 64);
 }
 
-static void execute_location(void *dst)
+static void noinline execute_location(void *dst)
 {
 	void (*func)(void) = dst;
 
-- 
2.7.0



From arnd at arndb.de  Mon Feb  8 06:36:52 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  8 Feb 2016 15:36:52 +0100
Subject: [PATCH] locking/static_keys: avoid nested functions
Message-ID: <1454942223-2781480-1-git-send-email-arnd@arndb.de>

clang does not support nested functions inside of an array definition:

lib/test_static_keys.c:105:16: error: function definition is not allowed here
                        .test_key       = test_key_func(&old_true_key, static_key_true),
lib/test_static_keys.c:50:20: note: expanded from macro 'test_key_func'
        ({bool func(void) { return branch(key); } func; })

That code appears to have been a little too clever, so this
simplifies it a bit by defining functions outside of the array.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 lib/test_static_keys.c | 62 ++++++++++++++++++++++++++++++++++----------------
 1 file changed, 42 insertions(+), 20 deletions(-)

diff --git a/lib/test_static_keys.c b/lib/test_static_keys.c
index c61b299e367f..915d75df2086 100644
--- a/lib/test_static_keys.c
+++ b/lib/test_static_keys.c
@@ -46,8 +46,11 @@ struct test_key {
 	bool			(*test_key)(void);
 };
 
-#define test_key_func(key, branch) \
-	({bool func(void) { return branch(key); } func;	})
+#define test_key_func(key, branch)	\
+static bool key ## _ ## branch(void)	\
+{					\
+	return branch(&key);		\
+}
 
 static void invert_key(struct static_key *key)
 {
@@ -92,6 +95,25 @@ static int verify_keys(struct test_key *keys, int size, bool invert)
 	return 0;
 }
 
+test_key_func(old_true_key, static_key_true)
+test_key_func(old_false_key, static_key_false)
+test_key_func(true_key, static_branch_likely)
+test_key_func(true_key, static_branch_unlikely)
+test_key_func(false_key, static_branch_likely)
+test_key_func(false_key, static_branch_unlikely)
+test_key_func(base_old_true_key, static_key_true)
+test_key_func(base_inv_old_true_key, static_key_true)
+test_key_func(base_old_false_key, static_key_false)
+test_key_func(base_inv_old_false_key, static_key_false)
+test_key_func(base_true_key, static_branch_likely)
+test_key_func(base_true_key, static_branch_unlikely)
+test_key_func(base_inv_true_key, static_branch_likely)
+test_key_func(base_inv_true_key, static_branch_unlikely)
+test_key_func(base_false_key, static_branch_likely)
+test_key_func(base_false_key, static_branch_unlikely)
+test_key_func(base_inv_false_key, static_branch_likely)
+test_key_func(base_inv_false_key, static_branch_unlikely)
+
 static int __init test_static_key_init(void)
 {
 	int ret;
@@ -102,95 +124,95 @@ static int __init test_static_key_init(void)
 		{
 			.init_state	= true,
 			.key		= &old_true_key,
-			.test_key	= test_key_func(&old_true_key, static_key_true),
+			.test_key	= &old_true_key_static_key_true,
 		},
 		{
 			.init_state	= false,
 			.key		= &old_false_key,
-			.test_key	= test_key_func(&old_false_key, static_key_false),
+			.test_key	= &old_false_key_static_key_false,
 		},
 		/* internal keys - new keys */
 		{
 			.init_state	= true,
 			.key		= &true_key.key,
-			.test_key	= test_key_func(&true_key, static_branch_likely),
+			.test_key	= &true_key_static_branch_likely,
 		},
 		{
 			.init_state	= true,
 			.key		= &true_key.key,
-			.test_key	= test_key_func(&true_key, static_branch_unlikely),
+			.test_key	= &true_key_static_branch_unlikely,
 		},
 		{
 			.init_state	= false,
 			.key		= &false_key.key,
-			.test_key	= test_key_func(&false_key, static_branch_likely),
+			.test_key	= &false_key_static_branch_likely,
 		},
 		{
 			.init_state	= false,
 			.key		= &false_key.key,
-			.test_key	= test_key_func(&false_key, static_branch_unlikely),
+			.test_key	= &false_key_static_branch_unlikely,
 		},
 		/* external keys - old keys */
 		{
 			.init_state	= true,
 			.key		= &base_old_true_key,
-			.test_key	= test_key_func(&base_old_true_key, static_key_true),
+			.test_key	= &base_old_true_key_static_key_true,
 		},
 		{
 			.init_state	= false,
 			.key		= &base_inv_old_true_key,
-			.test_key	= test_key_func(&base_inv_old_true_key, static_key_true),
+			.test_key	= &base_inv_old_true_key_static_key_true,
 		},
 		{
 			.init_state	= false,
 			.key		= &base_old_false_key,
-			.test_key	= test_key_func(&base_old_false_key, static_key_false),
+			.test_key	= &base_old_false_key_static_key_false,
 		},
 		{
 			.init_state	= true,
 			.key		= &base_inv_old_false_key,
-			.test_key	= test_key_func(&base_inv_old_false_key, static_key_false),
+			.test_key	= &base_inv_old_false_key_static_key_false,
 		},
 		/* external keys - new keys */
 		{
 			.init_state	= true,
 			.key		= &base_true_key.key,
-			.test_key	= test_key_func(&base_true_key, static_branch_likely),
+			.test_key	= &base_true_key_static_branch_likely,
 		},
 		{
 			.init_state	= true,
 			.key		= &base_true_key.key,
-			.test_key	= test_key_func(&base_true_key, static_branch_unlikely),
+			.test_key	= &base_true_key_static_branch_unlikely,
 		},
 		{
 			.init_state	= false,
 			.key		= &base_inv_true_key.key,
-			.test_key	= test_key_func(&base_inv_true_key, static_branch_likely),
+			.test_key	= &base_inv_true_key_static_branch_likely,
 		},
 		{
 			.init_state	= false,
 			.key		= &base_inv_true_key.key,
-			.test_key	= test_key_func(&base_inv_true_key, static_branch_unlikely),
+			.test_key	= &base_inv_true_key_static_branch_unlikely,
 		},
 		{
 			.init_state	= false,
 			.key		= &base_false_key.key,
-			.test_key	= test_key_func(&base_false_key, static_branch_likely),
+			.test_key	= &base_false_key_static_branch_likely,
 		},
 		{
 			.init_state	= false,
 			.key		= &base_false_key.key,
-			.test_key	= test_key_func(&base_false_key, static_branch_unlikely),
+			.test_key	= &base_false_key_static_branch_unlikely,
 		},
 		{
 			.init_state	= true,
 			.key		= &base_inv_false_key.key,
-			.test_key	= test_key_func(&base_inv_false_key, static_branch_likely),
+			.test_key	= &base_inv_false_key_static_branch_likely,
 		},
 		{
 			.init_state	= true,
 			.key		= &base_inv_false_key.key,
-			.test_key	= test_key_func(&base_inv_false_key, static_branch_unlikely),
+			.test_key	= &base_inv_false_key_static_branch_unlikely,
 		},
 	};
 
-- 
2.7.0



From marc.zyngier at arm.com  Mon Feb  8 06:37:25 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon,  8 Feb 2016 14:37:25 +0000
Subject: [PATCH] arm/arm64: KVM: Handle out-of-RAM cache maintenance as a NOP
Message-ID: <1454942245-18452-1-git-send-email-marc.zyngier@arm.com>

So far, our handling of cache maintenance by VA has been pretty
simple: Either the access is in the guest RAM and generates a S2
fault, which results in the page being mapped RW, or we go down
the io_mem_abort() path, and nuke the guest.

The first one is fine, but the second one is extremely weird.
Treating the CM as an I/O is wrong, and nothing in the ARM ARM
indicates that we should generate a fault for something that
cannot end-up in the cache anyway (even if the guest maps it,
it will keep on faulting at stage-2 for emulation).

So let's just skip this instruction, and let the guest get away
with it.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_emulate.h   |  5 +++++
 arch/arm/kvm/mmu.c                   | 17 +++++++++++++++++
 arch/arm64/include/asm/kvm_emulate.h |  5 +++++
 3 files changed, 27 insertions(+)

diff --git a/arch/arm/include/asm/kvm_emulate.h b/arch/arm/include/asm/kvm_emulate.h
index 3095df0..f768797 100644
--- a/arch/arm/include/asm/kvm_emulate.h
+++ b/arch/arm/include/asm/kvm_emulate.h
@@ -143,6 +143,11 @@ static inline bool kvm_vcpu_dabt_iss1tw(struct kvm_vcpu *vcpu)
 	return kvm_vcpu_get_hsr(vcpu) & HSR_DABT_S1PTW;
 }
 
+static inline bool kvm_vcpu_dabt_iscm(struct kvm_vcpu *vcpu)
+{
+	return !!(kvm_vcpu_get_hsr(vcpu) & HSR_DABT_CM);
+}
+
 /* Get Access Size from a data abort */
 static inline int kvm_vcpu_dabt_get_as(struct kvm_vcpu *vcpu)
 {
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index aba61fd..1a5f2ea 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -1431,6 +1431,23 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
 		}
 
 		/*
+		 * Check for a cache maintenance operation. Since we
+		 * ended-up here, we know it is outside of any memory
+		 * slot. But we can't find out if that is for a device,
+		 * or if the guest is just being stupid (going all the
+		 * way to userspace is not an option - what would you
+		 * write?).
+		 *
+		 * So let's assume that the guest is just being
+		 * cautious, and skip the instruction.
+		 */
+		if (kvm_vcpu_dabt_iscm(vcpu)) {
+			kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
+			ret = 1;
+			goto out_unlock;
+		}
+
+		/*
 		 * The IPA is reported as [MAX:12], so we need to
 		 * complement it with the bottom 12 bits from the
 		 * faulting VA. This is always 12 bits, irrespective
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 3066328..01cdf5f 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -185,6 +185,11 @@ static inline bool kvm_vcpu_dabt_iss1tw(const struct kvm_vcpu *vcpu)
 	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_S1PTW);
 }
 
+static inline bool kvm_vcpu_dabt_iscm(const struct kvm_vcpu *vcpu)
+{
+	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_CM);
+}
+
 static inline int kvm_vcpu_dabt_get_as(const struct kvm_vcpu *vcpu)
 {
 	return 1 << ((kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SAS) >> ESR_ELx_SAS_SHIFT);
-- 
2.1.4



From krzysztof.adamski at tieto.com  Mon Feb  8 06:37:22 2016
From: krzysztof.adamski at tieto.com (Krzysztof Adamski)
Date: Mon,  8 Feb 2016 15:37:22 +0100
Subject: [PATCH] pinctrl: sunxi: set pin function as input on export
Message-ID: <1454942242-25690-1-git-send-email-krzysztof.adamski@tieto.com>

Default function of a pin in sunxi SoCs is "disabled". By default gpios
exported by sysfs are set as input and indeed, when reading "direction"
file you will get "in". The "value" pin won't return proper value,
though, confusing user of this interface.

This patch sets direction of a GPIO as input when exporting it.

Signed-off-by: Krzysztof Adamski <krzysztof.adamski at tieto.com>
---
 drivers/pinctrl/sunxi/pinctrl-sunxi.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 7a2465f..905a9fb 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -452,6 +452,16 @@ static int sunxi_pinctrl_gpio_direction_input(struct gpio_chip *chip,
 	return pinctrl_gpio_direction_input(chip->base + offset);
 }
 
+int sunxi_pinctrl_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+	int ret = pinctrl_gpio_direction_input(chip->base + offset);
+
+	if (ret)
+		return ret;
+
+	return pinctrl_request_gpio(chip->base + offset);
+}
+
 static int sunxi_pinctrl_gpio_get(struct gpio_chip *chip, unsigned offset)
 {
 	struct sunxi_pinctrl *pctl = gpiochip_get_data(chip);
@@ -946,7 +956,7 @@ int sunxi_pinctrl_init(struct platform_device *pdev,
 
 	last_pin = pctl->desc->pins[pctl->desc->npins - 1].pin.number;
 	pctl->chip->owner = THIS_MODULE;
-	pctl->chip->request = gpiochip_generic_request,
+	pctl->chip->request = sunxi_pinctrl_gpio_request,
 	pctl->chip->free = gpiochip_generic_free,
 	pctl->chip->direction_input = sunxi_pinctrl_gpio_direction_input,
 	pctl->chip->direction_output = sunxi_pinctrl_gpio_direction_output,
-- 
2.4.2



From arnd at arndb.de  Mon Feb  8 06:38:32 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  8 Feb 2016 15:38:32 +0100
Subject: [PATCH] Kbuild: provide a __UNIQUE_ID for clang
Message-ID: <1454942318-2782493-1-git-send-email-arnd@arndb.de>

The default __UNIQUE_ID macro in compiler.h fails to work for some drivers:

drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:615:1: error: redefinition of
      '__UNIQUE_ID_firmware615'
BRCMF_FW_NVRAM_DEF(4354, "brcmfmac4354-sdio.bin", "brcmfmac4354-sdio.txt");

This adds a copy of the version we use for gcc-4.3 and higher, as the same
one works with all versions of clang that I could find in svn (2.6 and higher).

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 include/linux/compiler-clang.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index d1e49d52b640..de179993e039 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -10,3 +10,8 @@
 #undef uninitialized_var
 #define uninitialized_var(x) x = *(&(x))
 #endif
+
+/* same as gcc, this was present in clang-2.6 so we can assume it works
+ * with any version that can compile the kernel
+ */
+#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
-- 
2.7.0



From arnd at arndb.de  Mon Feb  8 06:39:09 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon,  8 Feb 2016 15:39:09 +0100
Subject: [PATCH] clk: socfpga: fix __init annotation
Message-ID: <1454942356-2783135-1-git-send-email-arnd@arndb.de>

clang found a bug with the __socfpga_pll_init definition:

drivers/clk/socfpga/clk-pll-a10.c:77:15: error: '__section__' attribute only applies to functions and
      global variables

This moves the __init annotation to the right place so the function
actually gets discarded.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/clk/socfpga/clk-pll-a10.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/socfpga/clk-pll-a10.c b/drivers/clk/socfpga/clk-pll-a10.c
index 402d630bd531..35fabe1a32c3 100644
--- a/drivers/clk/socfpga/clk-pll-a10.c
+++ b/drivers/clk/socfpga/clk-pll-a10.c
@@ -74,7 +74,7 @@ static struct clk_ops clk_pll_ops = {
 	.get_parent = clk_pll_get_parent,
 };
 
-static struct __init clk * __socfpga_pll_init(struct device_node *node,
+static struct clk * __init __socfpga_pll_init(struct device_node *node,
 	const struct clk_ops *ops)
 {
 	u32 reg;
-- 
2.7.0



From catalin.marinas at arm.com  Mon Feb  8 06:41:47 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 8 Feb 2016 14:41:47 +0000
Subject: [PATCH v3 03/23] arm/arm64: Add new is_kernel_in_hyp_mode
 predicate
In-Reply-To: <1454522416-6874-4-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-4-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160208144146.GM6076@e104818-lin.cambridge.arm.com>

On Wed, Feb 03, 2016 at 05:59:56PM +0000, Marc Zyngier wrote:
> With ARMv8.1 VHE extension, it will be possible to run the kernel
> at EL2 (aka HYP mode). In order for the kernel to easily find out
> where it is running, add a new predicate that returns whether or
> not the kernel is in HYP mode.
> 
> For completeness, the 32bit code also get such a predicate (always
> returning false) so that code common to both architecture (timers,
> KVM) can use it transparently.
> 
> Acked-by: Christoffer Dall <christoffer.dall at linaro.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From catalin.marinas at arm.com  Mon Feb  8 06:42:22 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 8 Feb 2016 14:42:22 +0000
Subject: [PATCH v3 05/23] arm64: Add ARM64_HAS_VIRT_HOST_EXTN feature
In-Reply-To: <1454522416-6874-6-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-6-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160208144222.GN6076@e104818-lin.cambridge.arm.com>

On Wed, Feb 03, 2016 at 05:59:58PM +0000, Marc Zyngier wrote:
> Add a new ARM64_HAS_VIRT_HOST_EXTN features to indicate that the
> CPU has the ARMv8.1 VHE capability.
> 
> This will be used to trigger kernel patching in KVM.
> 
> Acked-by: Christoffer Dall <christoffer.dall at linaro.org>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From catalin.marinas at arm.com  Mon Feb  8 06:44:31 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 8 Feb 2016 14:44:31 +0000
Subject: [PATCH v3 19/23] arm64: KVM: Move most of the fault decoding to C
In-Reply-To: <1454522416-6874-20-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-20-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160208144430.GO6076@e104818-lin.cambridge.arm.com>

On Wed, Feb 03, 2016 at 06:00:12PM +0000, Marc Zyngier wrote:
> The fault decoding process (including computing the IPA in the case
> of a permission fault) would be much better done in C code, as we
> have a reasonable infrastructure to deal with the VHE/non-VHE
> differences.
> 
> Let's move the whole thing to C, including the workaround for
> erratum 834220, and just patch the odd ESR_EL2 access remaining
> in hyp-entry.S.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From gregory.clement at free-electrons.com  Mon Feb  8 06:48:06 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 08 Feb 2016 15:48:06 +0100
Subject: [PATCH 0/2] ARM: mvebu: network interface naming
In-Reply-To: <1453907300-28283-1-git-send-email-thomas.petazzoni@free-electrons.com>
 (Thomas Petazzoni's message of "Wed, 27 Jan 2016 16:08:18 +0100")
References: <1453907300-28283-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <87twlj1cnt.fsf@free-electrons.com>

Hi Thomas,
 
 On mer., janv. 27 2016, Thomas Petazzoni <thomas.petazzoni at free-electrons.com> wrote:

> Dear mvebu maintainers,
>
> As was discussed back in November last year, the naming of network
> interfaces on Armada 38x is very confusing. Gregory Clement suggested
> to exceptionally violate the rule of "DT nodes should be ordered by
> register address" in order to reduce the confusion.
>
> The first patch implements this proposal.
>
> The second patch is a new iteration of the patch that adds comments to
> the Armada 385 DB AP Device Tree file. The contents of the patch is
> the same (add indications of which physical connector corresponds each
> port), only the commit log is adjusted to take into account the fact
> that thanks to the first patch, the naming of the network interfaces
> visible from Linux is now a lot more sane.
>
> Thanks!
>
> Thomas
>
> Thomas Petazzoni (2):
>   ARM: mvebu: change order of ethernet DT nodes on Armada 38x
>   ARM: mvebu: add reference to ETH connectors for A385-AP
>

Even if we know that it is not perfect, I applied both pacthes on
mvebu/dt

Thanks,

Gregory

>  arch/arm/boot/dts/armada-385-db-ap.dts |  3 +++
>  arch/arm/boot/dts/armada-38x.dtsi      | 30 +++++++++++++++++++++---------
>  2 files changed, 24 insertions(+), 9 deletions(-)
>
> -- 
> 2.6.4
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From catalin.marinas at arm.com  Mon Feb  8 06:48:31 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 8 Feb 2016 14:48:31 +0000
Subject: [PATCH v3 20/23] arm64: perf: Count EL2 events if the kernel is
 running in HYP
In-Reply-To: <1454522416-6874-21-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-21-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160208144831.GP6076@e104818-lin.cambridge.arm.com>

On Wed, Feb 03, 2016 at 06:00:13PM +0000, Marc Zyngier wrote:
> When the kernel is running in HYP (with VHE), it is necessary to
> include EL2 events if the user requests counting kernel or
> hypervisor events.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From antoine.tenart at free-electrons.com  Mon Feb  8 06:48:34 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon, 8 Feb 2016 15:48:34 +0100
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <56B8A638.1040903@arm.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
 <alpine.DEB.2.11.1602081125560.25254@nanos>
 <20160208141754.GG4117@kwain> <56B8A638.1040903@arm.com>
Message-ID: <20160208144834.GH4117@kwain>

On Mon, Feb 08, 2016 at 02:29:12PM +0000, Marc Zyngier wrote:
> On 08/02/16 14:17, Antoine Tenart wrote:
> > Thomas,
> > 
> > On Mon, Feb 08, 2016 at 11:31:47AM +0100, Thomas Gleixner wrote:
> >> On Mon, 8 Feb 2016, Antoine Tenart wrote:
> >>> +static int alpine_msix_set_affinity(struct irq_data *irq_data,
> >>> +				    const struct cpumask *mask, bool force)
> >>> +{
> >>> +	int ret;
> >>> +
> >>> +	ret = irq_chip_set_affinity_parent(irq_data, mask, force);
> >>> +	return ret == IRQ_SET_MASK_OK ? IRQ_SET_MASK_OK_DONE : ret;
> >>
> >> What's the point of this exercise? Why can't you just set the affinity
> >> callback to irq_chip_set_affinity_parent() ?
> > 
> > That's what done in irq-gic-v2m.c. Besides that, I see no point. I'll
> > update for v2.
> 
> That's because there is no need to do another compose_msi_msg/write_msg
> in msi_domain_set_affinity() once the affinity has been updated at the
> GIC level. Alternatively, updating the GIC driver to always return
> IRQ_SET_MASK_OK_DONE would be perfectly acceptable.

I'm using drivers/irqchip/irq-gic-v3.c which is indeed always returning
IRQ_SET_MASK_OK. I'll make a new patch in the v2 of this series to
return IRQ_SET_MASK_OK_DONE instead in the GIC driver (and then patch
irq-gic-v2m.c).

Thanks,

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160208/eaae11f1/attachment.sig>

From broonie at kernel.org  Mon Feb  8 06:53:47 2016
From: broonie at kernel.org (Mark Brown)
Date: Mon, 8 Feb 2016 14:53:47 +0000
Subject: [PATCH 07/11] ARM: dts: sunxi: Add dtsi file for AXP809 PMIC
In-Reply-To: <CAGb2v657zYT30KbuK0fyVOmhv0kzJjj9gTsTFRaS4i3d6YhiHQ@mail.gmail.com>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-8-git-send-email-wens@csie.org>
 <20160202121733.GO4455@sirena.org.uk>
 <CAGb2v657zYT30KbuK0fyVOmhv0kzJjj9gTsTFRaS4i3d6YhiHQ@mail.gmail.com>
Message-ID: <20160208145347.GD7265@sirena.org.uk>

On Sat, Feb 06, 2016 at 08:42:24PM +0800, Chen-Yu Tsai wrote:

> Mark, may I assume you are OK with this DTS include listing
> the regulators, even if their sections are empty?

If it has no content why have it?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160208/65f9a19d/attachment.sig>

From marc.zyngier at arm.com  Mon Feb  8 06:55:57 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 8 Feb 2016 14:55:57 +0000
Subject: [PATCH 2/6] Documentation: bindings: document the Alpine MSIX
 driver
In-Reply-To: <1454922971-17405-3-git-send-email-antoine.tenart@free-electrons.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-3-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <56B8AC7D.8060102@arm.com>

On 08/02/16 09:16, Antoine Tenart wrote:
> Following the addition of the Alpine MSIX driver, this patch adds the
> corresponding bindings documentation.
> 
> Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
> Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
> ---
>  .../interrupt-controller/al,alpine-msix.txt        | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
> 
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt b/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
> new file mode 100644
> index 000000000000..a77d5a76e8d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
> @@ -0,0 +1,22 @@
> +Alpine MSIX controller
> +
> +Required properties:
> +
> +- compatible: should be "al,alpine-msix"
> +- reg: physical base address and size of the registers
> +- interrupt-controller: identifies the node as an interrupt controller
> +- msi-controller: identifies the node as an PCI Message Signaled Interrupt
> +		  controller
> +- al,msi-base-spi: SPI base of the MSI frame
> +- al,msi-num-spis: number of SPIs assigned to the MSI frame
> +
> +Example:
> +
> +msix: msix {
> +	compatible = "al,alpine-msix";
> +	reg = <0x0 0xfbe00000 0x0 0x100000>;
> +	interrupt-controller;
> +	msi-controller;
> +	al,msi-base-spi = <160>;
> +	al,msi-num-spis = <160>;
> +};
> 

This example seems to rely on an implicit interrupt-parent. You probably
want to update the example to clarify it.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From wens at csie.org  Mon Feb  8 06:56:05 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 8 Feb 2016 22:56:05 +0800
Subject: [PATCH 07/11] ARM: dts: sunxi: Add dtsi file for AXP809 PMIC
In-Reply-To: <20160208145347.GD7265@sirena.org.uk>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-8-git-send-email-wens@csie.org>
 <20160202121733.GO4455@sirena.org.uk>
 <CAGb2v657zYT30KbuK0fyVOmhv0kzJjj9gTsTFRaS4i3d6YhiHQ@mail.gmail.com>
 <20160208145347.GD7265@sirena.org.uk>
Message-ID: <CAGb2v64ySLAVbPf_XaZnzm5T=SmQLip4iO2p4cGXg=C0=51eqA@mail.gmail.com>

On Mon, Feb 8, 2016 at 10:53 PM, Mark Brown <broonie at kernel.org> wrote:
> On Sat, Feb 06, 2016 at 08:42:24PM +0800, Chen-Yu Tsai wrote:
>
>> Mark, may I assume you are OK with this DTS include listing
>> the regulators, even if their sections are empty?
>
> If it has no content why have it?

I'd like the regulator core to disable any unused ones. The core
considers regulators that don't have nodes as not having constraints,
and won't touch them.

Any other ways to do this? Or am I going about this the wrong way?

Thanks
ChenYu


From marc.zyngier at arm.com  Mon Feb  8 07:01:39 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 8 Feb 2016 15:01:39 +0000
Subject: [PATCH 1/6] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <20160208144834.GH4117@kwain>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-2-git-send-email-antoine.tenart@free-electrons.com>
 <alpine.DEB.2.11.1602081125560.25254@nanos> <20160208141754.GG4117@kwain>
 <56B8A638.1040903@arm.com> <20160208144834.GH4117@kwain>
Message-ID: <56B8ADD3.4030404@arm.com>

On 08/02/16 14:48, Antoine Tenart wrote:
> On Mon, Feb 08, 2016 at 02:29:12PM +0000, Marc Zyngier wrote:
>> On 08/02/16 14:17, Antoine Tenart wrote:
>>> Thomas,
>>>
>>> On Mon, Feb 08, 2016 at 11:31:47AM +0100, Thomas Gleixner wrote:
>>>> On Mon, 8 Feb 2016, Antoine Tenart wrote:
>>>>> +static int alpine_msix_set_affinity(struct irq_data *irq_data,
>>>>> +				    const struct cpumask *mask, bool force)
>>>>> +{
>>>>> +	int ret;
>>>>> +
>>>>> +	ret = irq_chip_set_affinity_parent(irq_data, mask, force);
>>>>> +	return ret == IRQ_SET_MASK_OK ? IRQ_SET_MASK_OK_DONE : ret;
>>>>
>>>> What's the point of this exercise? Why can't you just set the affinity
>>>> callback to irq_chip_set_affinity_parent() ?
>>>
>>> That's what done in irq-gic-v2m.c. Besides that, I see no point. I'll
>>> update for v2.
>>
>> That's because there is no need to do another compose_msi_msg/write_msg
>> in msi_domain_set_affinity() once the affinity has been updated at the
>> GIC level. Alternatively, updating the GIC driver to always return
>> IRQ_SET_MASK_OK_DONE would be perfectly acceptable.
> 
> I'm using drivers/irqchip/irq-gic-v3.c which is indeed always returning
> IRQ_SET_MASK_OK. I'll make a new patch in the v2 of this series to
> return IRQ_SET_MASK_OK_DONE instead in the GIC driver (and then patch
> irq-gic-v2m.c).

/me puzzled. GICv3, but no ITS??? WTF???

	M.
-- 
Jazz is not dead. It just smells funny...


From geert at linux-m68k.org  Mon Feb  8 07:03:29 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 8 Feb 2016 16:03:29 +0100
Subject: [PATCH 0/2] ARM: shmobile: Remove legacy machine_desc.map_io()
 callbacks
In-Reply-To: <20160202140738.GC4304@verge.net.au>
References: <1453994246-12886-1-git-send-email-geert+renesas@glider.be>
 <20160202140738.GC4304@verge.net.au>
Message-ID: <CAMuHMdVP8_9Nk8FQvHyVqfhK+Yhz2g0weE3nCxQeZ1wpeAEEUQ@mail.gmail.com>

Hi Simon,

On Tue, Feb 2, 2016 at 3:07 PM, Simon Horman <horms at verge.net.au> wrote:
> On Thu, Jan 28, 2016 at 04:17:24PM +0100, Geert Uytterhoeven wrote:
>> This patch series removes the legacy machine_desc.map_io() callback for
>> SoCs that no longer rely on it, but use ioremap() instead.
>>
>> The patch for emev2 depends on "ARM: shmobile: Consolidate SCU mapping
>> code" ("FIXME" commit ID reference to be updated).
>>
>> Thanks!
>
> Thanks, I have queued these up.

Thanks, but unfortunately it's not in renesas-devel-20160205-v4.5-rc2?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From geert at linux-m68k.org  Mon Feb  8 07:04:34 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 8 Feb 2016 16:04:34 +0100
Subject: [PATCH 0/3] ARM: shmobile: SCU cleanup and consolidation
In-Reply-To: <20160202140550.GB4304@verge.net.au>
References: <1453994012-12696-1-git-send-email-geert+renesas@glider.be>
 <20160202140550.GB4304@verge.net.au>
Message-ID: <CAMuHMdUn7=AAehQqG5ezc4wkKjytOoVz7U9HT_HvPLVj+Na7Vg@mail.gmail.com>

Hi Simon,

On Tue, Feb 2, 2016 at 3:05 PM, Simon Horman <horms at verge.net.au> wrote:
> On Thu, Jan 28, 2016 at 04:13:29PM +0100, Geert Uytterhoeven wrote:
>> This patch series contains cleanups and consolidations of the SCU code
>> for shmobile SoCs with Cortex-A9 CPU cores.
>>
>> This has been tested on emev2/kzm9d, r8a7779/marzen, and sh73a0/kzm9g.
>>
>> Thanks!
>
> Thanks, I have queued these up.

Except for the third patch?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From antoine.tenart at free-electrons.com  Mon Feb  8 07:05:01 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon, 8 Feb 2016 16:05:01 +0100
Subject: [PATCH 2/6] Documentation: bindings: document the Alpine MSIX
 driver
In-Reply-To: <56B8AC7D.8060102@arm.com>
References: <1454922971-17405-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922971-17405-3-git-send-email-antoine.tenart@free-electrons.com>
 <56B8AC7D.8060102@arm.com>
Message-ID: <20160208150501.GA19758@kwain>

On Mon, Feb 08, 2016 at 02:55:57PM +0000, Marc Zyngier wrote:
> On 08/02/16 09:16, Antoine Tenart wrote:
> > +
> > +Example:
> > +
> > +msix: msix {
> > +	compatible = "al,alpine-msix";
> > +	reg = <0x0 0xfbe00000 0x0 0x100000>;
> > +	interrupt-controller;
> > +	msi-controller;
> > +	al,msi-base-spi = <160>;
> > +	al,msi-num-spis = <160>;
> > +};
> > 
> 
> This example seems to rely on an implicit interrupt-parent. You probably
> want to update the example to clarify it.

Right. I'll add the interrupt-parent property in the required properties
and in the example msix node.

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160208/ff723db7/attachment.sig>

From andy.shevchenko at gmail.com  Mon Feb  8 07:23:02 2016
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Mon, 8 Feb 2016 17:23:02 +0200
Subject: [PATCH v4] dmaengine: edma: fix residue race for cyclic
In-Reply-To: <87k2mu2e16.fsf@linutronix.de>
References: <87k2mu2e16.fsf@linutronix.de>
Message-ID: <CAHp75Vc6th4OnvN1AhVY2Y5KrS+Agza87r6b=dBY97EGQ+p8kw@mail.gmail.com>

On Thu, Jan 28, 2016 at 12:29 PM, John Ogness <john.ogness at linutronix.de> wrote:
> When retrieving the residue value, the SRC/DST fields of the
> active PaRAM are read to determine the current position of
> the DMA engine. However, the AM335x Technical Reference Manual
> states:

> +       /*
> +        * "pos" may represent a transfer request that is still being
> +        * processed by the EDMACC or EDMATC. We will busy wait until
> +        * any one of the situations occurs:
> +        *   1. the DMA hardware is idle
> +        *   2. a new transfer request is setup
> +        *   3. we hit the loop limit
> +        */
> +       while (edma_read(echan->ecc, EDMA_CCSTAT) & EDMA_CCSTAT_ACTV) {
> +               /* check if a new transfer request is setup */
> +               if (edma_get_position(echan->ecc,
> +                                     echan->slot[0], dst) != pos) {
> +                       break;
> +               }
> +
> +               if (!--loop_count) {

More usual pattern is

while (... && --count) {
}
if (!count) {
 Timeout!
}

But since it's minor and already applied, just take into consideration
for the future.

> +                       dev_dbg_ratelimited(echan->vchan.chan.device->dev,
> +                               "%s: timeout waiting for PaRAM update\n",
> +                               __func__);
> +                       break;
> +               }
> +
> +               cpu_relax();
> +       }

-- 
With Best Regards,
Andy Shevchenko


From pbonzini at redhat.com  Mon Feb  8 07:23:07 2016
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Mon, 8 Feb 2016 16:23:07 +0100
Subject: [GIT PULL] KVM/ARM updates for 4.5-rc2
In-Reply-To: <1453977038-13516-1-git-send-email-marc.zyngier@arm.com>
References: <1453977038-13516-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <56B8B2DB.9020407@redhat.com>



On 28/01/2016 11:30, Marc Zyngier wrote:
> Hi Paolo,
> 
> Please find below the KVM/ARM updates for 4.5-rc2. Mostly fixes as a
> result of Shannon's work on PMU emulation, which has outlined a few
> nits here and there, plus a correctness fix from Dave.
> 
> Please pull!
> 
> Thanks,
> 
> 	M.
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvm-arm-for-4.5-rc2
> 
> for you to fetch changes up to 6327f35a2010c06a3bc2bfb14202a38764fb9920:
> 
>   arm64: KVM: Fix guest dead loop when register accessor returns false (2016-01-24 21:56:01 +0000)
> 
> ----------------------------------------------------------------
> KVM/ARM fixes for v4.5-rc2
> 
> A few random fixes, mostly coming from the PMU work by Shannon:
> 
> - fix for injecting faults coming from the guest's userspace
> - cleanup for our CPTR_EL2 accessors (reserved bits)
> - fix for a bug impacting perf (user/kernel discrimination)
> - fix for a 32bit sysreg handling bug
> 
> ----------------------------------------------------------------

Finally pulled, thanks.

Paolo


From codekipper at gmail.com  Mon Feb  8 07:26:05 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Mon,  8 Feb 2016 16:26:05 +0100
Subject: [PATCH v5 0/2] ASoC: Add SPDIF support for Allwinner SoCs
Message-ID: <1454945167-29324-1-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

This patch set adds support for the Allwinner SPDIF transceiver.

For now just the SPDIF transmitter has been tested on a Mele A2000(A10)
and a Itead Ibox(A20).

In order for this patch set to be functional we require an audio clock patch
which will be delivered separately. For those that are interested I've pushed
the patches here with all the required changes to get SPDIF audio out of the
device.

https://github.com/codekipper/linux-sunxi/commits/spdif_delivery

Thanks in advance,
CK

---
Changes since v4:
- corrected indentation issues
- removed old macros
- removed unnecessary enabling of apb clock

Changes since v3:
- removed code required for spdif capture
- added disable/enable of apb clk to suspend/resume.
- removed unnecessary dt checks in probe
- fixed error conditions in probe/resume
- modified pm_runtime functionality and confirmed that driver worked when PM was disabled.
- removed .owner from platform driver
- renamed bindings file

Changes since v2:
- removed sunxi-machine-spdif and replaced with simple audio card
- removed untested compatibilities from device tree documentation
- added pm_runtime and remove shutdown
- removed pll2 as it's the parent of the spdif clock
- rename clk to spdif_clk
- removed enabling of mclk output
- removed interrupts status being cleared as it's not being used
- use default fifo settings for now
- fixed alignments for wrapped lines

Changes since v1:
- Moved sunxi-machine-spdif.c to separate patch
- replaced sunxi in naming scheme with sun4i in the sun4i-spdif driver.
- split tx controller into separate enable/disable functions
- moved setclk and setfmt functionality into hw params
- added support for mono signals.
- cleaned up probe clock set up.
- removed all writes to transmit status registers.
- removed of_id
- removed power management code.
- Added support for more rates.

Marcus Cooper (2):
  dt-bindings: sunxi :add sun4i SPDIF transceiver
  ASoC: sunxi: Add support for the SPDIF block

 .../bindings/sound/sunxi,sun4i-spdif.txt           |  39 ++
 sound/soc/sunxi/Kconfig                            |   8 +
 sound/soc/sunxi/Makefile                           |   1 +
 sound/soc/sunxi/sun4i-spdif.c                      | 549 +++++++++++++++++++++
 4 files changed, 597 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
 create mode 100644 sound/soc/sunxi/sun4i-spdif.c

-- 
2.7.1



From codekipper at gmail.com  Mon Feb  8 07:26:06 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Mon,  8 Feb 2016 16:26:06 +0100
Subject: [PATCH v5 1/2] dt-bindings: sunxi :add sun4i SPDIF transceiver
In-Reply-To: <1454945167-29324-1-git-send-email-codekipper@gmail.com>
References: <1454945167-29324-1-git-send-email-codekipper@gmail.com>
Message-ID: <1454945167-29324-2-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

Add devicetree bindings for the SPDIF transceiver found on
found on Allwinners A10 and A20 SoCs.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
 .../bindings/sound/sunxi,sun4i-spdif.txt           | 39 ++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt

diff --git a/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
new file mode 100644
index 0000000..13503aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
@@ -0,0 +1,39 @@
+Allwinner Sony/Philips Digital Interface Format (S/PDIF) Controller
+
+The Allwinner S/PDIF audio block is a transceiver that allows the
+processor to receive and transmit digital audio via an coaxial cable or
+a fibre cable.
+For now only playback is supported.
+
+Required properties:
+
+  - compatible		: should be one of the following:
+    - "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC
+
+  - reg			: Offset and length of the register set for the device.
+
+  - interrupts		: Contains the spdif interrupt.
+
+  - dmas		: Generic dma devicetree binding as described in
+			  Documentation/devicetree/bindings/dma/dma.txt.
+
+  - dma-names		: Two dmas have to be defined, "tx" and "rx".
+
+  - clocks		: Contains an entry for each entry in clock-names.
+
+  - clock-names		: Includes the following entries:
+	"apb"		  clock for the spdif bus.
+	"spdif"		  clock for spdif controller.
+
+Example:
+
+spdif: spdif at 01c21000 {
+	compatible = "allwinner,sun4i-a10-spdif";
+	reg = <0x01c21000 0x40>;
+	interrupts = <13>;
+	clocks = <&apb0_gates 1>, <&spdif_clk>;
+	clock-names = "apb", "spdif";
+	dmas = <&dma 0 2>, <&dma 0 2>;
+	dma-names = "rx", "tx";
+	status = "okay";
+};
-- 
2.7.1



From cyrille.pitchen at atmel.com  Mon Feb  8 07:26:47 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Mon, 8 Feb 2016 16:26:47 +0100
Subject: [PATCH 0/2] crypto: atmel-sha - fix .import()/.export() implementation
Message-ID: <cover.1454944687.git.cyrille.pitchen@atmel.com>

This series of patches includes two fixes for the atmel-sha.c driver.

The first one fixes the implementation of the import/export hooks, which
did not pass the recent updates in testmgr.c (partial update exercise).
The new implementation now passes the tcrypt tests: tested with
next-20160208.

The second patch fixes a race condition if acquiring the hardware when it
is already busy.

Cyrille Pitchen (2):
  crypto: atmel-sha - fix .import()/.export() implementation
  crypto: atmel-sha - fix race in atmel_sha_final()

 drivers/crypto/atmel-sha.c | 68 ++++++++--------------------------------------
 1 file changed, 12 insertions(+), 56 deletions(-)

-- 
1.8.2.2



From codekipper at gmail.com  Mon Feb  8 07:26:07 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Mon,  8 Feb 2016 16:26:07 +0100
Subject: [PATCH v5 2/2] ASoC: sunxi: Add support for the SPDIF block
In-Reply-To: <1454945167-29324-1-git-send-email-codekipper@gmail.com>
References: <1454945167-29324-1-git-send-email-codekipper@gmail.com>
Message-ID: <1454945167-29324-3-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

The sun4i, sun5i and sun7i SoC families have an SPDIF
block which is capable of playback and capture.

This patch enables the playback of this block for
the sun4i families.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
 sound/soc/sunxi/Kconfig       |   8 +
 sound/soc/sunxi/Makefile      |   1 +
 sound/soc/sunxi/sun4i-spdif.c | 549 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 558 insertions(+)
 create mode 100644 sound/soc/sunxi/sun4i-spdif.c

diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
index 84c72ec..ae42294 100644
--- a/sound/soc/sunxi/Kconfig
+++ b/sound/soc/sunxi/Kconfig
@@ -8,4 +8,12 @@ config SND_SUN4I_CODEC
 	  Select Y or M to add support for the Codec embedded in the Allwinner
 	  A10 and affiliated SoCs.
 
+config SND_SUN4I_SPDIF
+	tristate "Allwinner A10 SPDIF Support"
+	depends on OF
+	select SND_SOC_GENERIC_DMAENGINE_PCM
+	select REGMAP_MMIO
+	help
+	  Say Y or M to add support for the S/PDIF audio block in the Allwinner
+	  A10 and affiliated SoCs.
 endmenu
diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
index ea8a08c..8f5e889 100644
--- a/sound/soc/sunxi/Makefile
+++ b/sound/soc/sunxi/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
 
+obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o
diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
new file mode 100644
index 0000000..85a58a7
--- /dev/null
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -0,0 +1,549 @@
+/*
+ * ALSA SoC SPDIF Audio Layer
+ *
+ * Copyright 2015 Andrea Venturi <be17068 at iperbole.bo.it>
+ * Copyright 2015 Marcus Cooper <codekipper at gmail.com>
+ *
+ * Based on the Allwinner SDK driver, released under the GPL.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/regmap.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/ioport.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <sound/dmaengine_pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+
+#define	SUN4I_SPDIF_CTL		(0x00)
+	#define SUN4I_SPDIF_CTL_MCLKDIV(v)		((v) << 4) /* v even */
+	#define SUN4I_SPDIF_CTL_MCLKOUTEN		BIT(2)
+	#define SUN4I_SPDIF_CTL_GEN			BIT(1)
+	#define SUN4I_SPDIF_CTL_RESET			BIT(0)
+
+#define SUN4I_SPDIF_TXCFG	(0x04)
+	#define SUN4I_SPDIF_TXCFG_SINGLEMOD		BIT(31)
+	#define SUN4I_SPDIF_TXCFG_ASS			BIT(17)
+	#define SUN4I_SPDIF_TXCFG_NONAUDIO		BIT(16)
+	#define SUN4I_SPDIF_TXCFG_TXRATIO(v)		((v) << 4)
+	#define SUN4I_SPDIF_TXCFG_TXRATIO_MASK		GENMASK(8, 4)
+	#define SUN4I_SPDIF_TXCFG_FMTRVD		GENMASK(3, 2)
+	#define SUN4I_SPDIF_TXCFG_FMT16BIT		(0 << 2)
+	#define SUN4I_SPDIF_TXCFG_FMT20BIT		(1 << 2)
+	#define SUN4I_SPDIF_TXCFG_FMT24BIT		(2 << 2)
+	#define SUN4I_SPDIF_TXCFG_CHSTMODE		BIT(1)
+	#define SUN4I_SPDIF_TXCFG_TXEN			BIT(0)
+
+#define SUN4I_SPDIF_RXCFG	(0x08)
+	#define SUN4I_SPDIF_RXCFG_LOCKFLAG		BIT(4)
+	#define SUN4I_SPDIF_RXCFG_CHSTSRC		BIT(3)
+	#define SUN4I_SPDIF_RXCFG_CHSTCP		BIT(1)
+	#define SUN4I_SPDIF_RXCFG_RXEN			BIT(0)
+
+#define SUN4I_SPDIF_TXFIFO	(0x0C)
+
+#define SUN4I_SPDIF_RXFIFO	(0x10)
+
+#define SUN4I_SPDIF_FCTL	(0x14)
+	#define SUN4I_SPDIF_FCTL_FIFOSRC		BIT(31)
+	#define SUN4I_SPDIF_FCTL_FTX			BIT(17)
+	#define SUN4I_SPDIF_FCTL_FRX			BIT(16)
+	#define SUN4I_SPDIF_FCTL_TXTL(v)		((v) << 8)
+	#define SUN4I_SPDIF_FCTL_TXTL_MASK		GENMASK(12, 8)
+	#define SUN4I_SPDIF_FCTL_RXTL(v)		((v) << 3)
+	#define SUN4I_SPDIF_FCTL_RXTL_MASK		GENMASK(7, 3)
+	#define SUN4I_SPDIF_FCTL_TXIM			BIT(2)
+	#define SUN4I_SPDIF_FCTL_RXOM(v)		((v) << 0)
+	#define SUN4I_SPDIF_FCTL_RXOM_MASK		GENMASK(1, 0)
+
+#define SUN4I_SPDIF_FSTA	(0x18)
+	#define SUN4I_SPDIF_FSTA_TXE			BIT(14)
+	#define SUN4I_SPDIF_FSTA_TXECNTSHT		(8)
+	#define SUN4I_SPDIF_FSTA_RXA			BIT(6)
+	#define SUN4I_SPDIF_FSTA_RXACNTSHT		(0)
+
+#define SUN4I_SPDIF_INT		(0x1C)
+	#define SUN4I_SPDIF_INT_RXLOCKEN		BIT(18)
+	#define SUN4I_SPDIF_INT_RXUNLOCKEN		BIT(17)
+	#define SUN4I_SPDIF_INT_RXPARERREN		BIT(16)
+	#define SUN4I_SPDIF_INT_TXDRQEN			BIT(7)
+	#define SUN4I_SPDIF_INT_TXUIEN			BIT(6)
+	#define SUN4I_SPDIF_INT_TXOIEN			BIT(5)
+	#define SUN4I_SPDIF_INT_TXEIEN			BIT(4)
+	#define SUN4I_SPDIF_INT_RXDRQEN			BIT(2)
+	#define SUN4I_SPDIF_INT_RXOIEN			BIT(1)
+	#define SUN4I_SPDIF_INT_RXAIEN			BIT(0)
+
+#define SUN4I_SPDIF_ISTA	(0x20)
+	#define SUN4I_SPDIF_ISTA_RXLOCKSTA		BIT(18)
+	#define SUN4I_SPDIF_ISTA_RXUNLOCKSTA		BIT(17)
+	#define SUN4I_SPDIF_ISTA_RXPARERRSTA		BIT(16)
+	#define SUN4I_SPDIF_ISTA_TXUSTA			BIT(6)
+	#define SUN4I_SPDIF_ISTA_TXOSTA			BIT(5)
+	#define SUN4I_SPDIF_ISTA_TXESTA			BIT(4)
+	#define SUN4I_SPDIF_ISTA_RXOSTA			BIT(1)
+	#define SUN4I_SPDIF_ISTA_RXASTA			BIT(0)
+
+#define SUN4I_SPDIF_TXCNT	(0x24)
+
+#define SUN4I_SPDIF_RXCNT	(0x28)
+
+#define SUN4I_SPDIF_TXCHSTA0	(0x2C)
+	#define SUN4I_SPDIF_TXCHSTA0_CLK(v)		((v) << 28)
+	#define SUN4I_SPDIF_TXCHSTA0_SAMFREQ(v)		((v) << 24)
+	#define SUN4I_SPDIF_TXCHSTA0_SAMFREQ_MASK	GENMASK(27, 24)
+	#define SUN4I_SPDIF_TXCHSTA0_CHNUM(v)		((v) << 20)
+	#define SUN4I_SPDIF_TXCHSTA0_CHNUM_MASK		GENMASK(23, 20)
+	#define SUN4I_SPDIF_TXCHSTA0_SRCNUM(v)		((v) << 16)
+	#define SUN4I_SPDIF_TXCHSTA0_CATACOD(v)		((v) << 8)
+	#define SUN4I_SPDIF_TXCHSTA0_MODE(v)		((v) << 6)
+	#define SUN4I_SPDIF_TXCHSTA0_EMPHASIS(v)	((v) << 3)
+	#define SUN4I_SPDIF_TXCHSTA0_CP			BIT(2)
+	#define SUN4I_SPDIF_TXCHSTA0_AUDIO		BIT(1)
+	#define SUN4I_SPDIF_TXCHSTA0_PRO		BIT(0)
+
+#define SUN4I_SPDIF_TXCHSTA1	(0x30)
+	#define SUN4I_SPDIF_TXCHSTA1_CGMSA(v)		((v) << 8)
+	#define SUN4I_SPDIF_TXCHSTA1_ORISAMFREQ(v)	((v) << 4)
+	#define SUN4I_SPDIF_TXCHSTA1_ORISAMFREQ_MASK	GENMASK(7, 4)
+	#define SUN4I_SPDIF_TXCHSTA1_SAMWORDLEN(v)	((v) << 1)
+	#define SUN4I_SPDIF_TXCHSTA1_MAXWORDLEN		BIT(0)
+
+#define SUN4I_SPDIF_RXCHSTA0	(0x34)
+	#define SUN4I_SPDIF_RXCHSTA0_CLK(v)		((v) << 28)
+	#define SUN4I_SPDIF_RXCHSTA0_SAMFREQ(v)		((v) << 24)
+	#define SUN4I_SPDIF_RXCHSTA0_CHNUM(v)		((v) << 20)
+	#define SUN4I_SPDIF_RXCHSTA0_SRCNUM(v)		((v) << 16)
+	#define SUN4I_SPDIF_RXCHSTA0_CATACOD(v)		((v) << 8)
+	#define SUN4I_SPDIF_RXCHSTA0_MODE(v)		((v) << 6)
+	#define SUN4I_SPDIF_RXCHSTA0_EMPHASIS(v)	((v) << 3)
+	#define SUN4I_SPDIF_RXCHSTA0_CP			BIT(2)
+	#define SUN4I_SPDIF_RXCHSTA0_AUDIO		BIT(1)
+	#define SUN4I_SPDIF_RXCHSTA0_PRO		BIT(0)
+
+#define SUN4I_SPDIF_RXCHSTA1	(0x38)
+	#define SUN4I_SPDIF_RXCHSTA1_CGMSA(v)		((v) << 8)
+	#define SUN4I_SPDIF_RXCHSTA1_ORISAMFREQ(v)	((v) << 4)
+	#define SUN4I_SPDIF_RXCHSTA1_SAMWORDLEN(v)	((v) << 1)
+	#define SUN4I_SPDIF_RXCHSTA1_MAXWORDLEN		BIT(0)
+
+/* Defines for Sampling Frequency */
+#define SUN4I_SPDIF_SAMFREQ_44_1KHZ		0x0
+#define SUN4I_SPDIF_SAMFREQ_NOT_INDICATED	0x1
+#define SUN4I_SPDIF_SAMFREQ_48KHZ		0x2
+#define SUN4I_SPDIF_SAMFREQ_32KHZ		0x3
+#define SUN4I_SPDIF_SAMFREQ_22_05KHZ		0x4
+#define SUN4I_SPDIF_SAMFREQ_24KHZ		0x6
+#define SUN4I_SPDIF_SAMFREQ_88_2KHZ		0x8
+#define SUN4I_SPDIF_SAMFREQ_76_8KHZ		0x9
+#define SUN4I_SPDIF_SAMFREQ_96KHZ		0xa
+#define SUN4I_SPDIF_SAMFREQ_176_4KHZ		0xc
+#define SUN4I_SPDIF_SAMFREQ_192KHZ		0xe
+
+struct sun4i_spdif_dev {
+	struct platform_device *pdev;
+	struct clk *spdif_clk;
+	struct clk *apb_clk;
+	struct snd_soc_dai_driver cpu_dai_drv;
+	struct regmap *regmap;
+	struct snd_dmaengine_dai_dma_data dma_params_tx;
+};
+
+static void sun4i_spdif_configure(struct sun4i_spdif_dev *host)
+{
+	/* soft reset SPDIF */
+	regmap_write(host->regmap, SUN4I_SPDIF_CTL, SUN4I_SPDIF_CTL_RESET);
+
+	/* flush TX FIFO */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_FCTL,
+			   SUN4I_SPDIF_FCTL_FTX, SUN4I_SPDIF_FCTL_FTX);
+
+	/* clear TX counter */
+	regmap_write(host->regmap, SUN4I_SPDIF_TXCNT, 0);
+}
+
+static void sun4i_snd_txctrl_on(struct snd_pcm_substream *substream,
+				struct sun4i_spdif_dev *host)
+{
+	if (substream->runtime->channels == 1)
+		regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+				   SUN4I_SPDIF_TXCFG_SINGLEMOD,
+				   SUN4I_SPDIF_TXCFG_SINGLEMOD);
+
+	/* SPDIF TX ENABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+			   SUN4I_SPDIF_TXCFG_TXEN, SUN4I_SPDIF_TXCFG_TXEN);
+
+	/* DRQ ENABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_INT,
+			   SUN4I_SPDIF_INT_TXDRQEN, SUN4I_SPDIF_INT_TXDRQEN);
+
+	/* Global enable */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_CTL,
+			   SUN4I_SPDIF_CTL_GEN, SUN4I_SPDIF_CTL_GEN);
+}
+
+static void sun4i_snd_txctrl_off(struct snd_pcm_substream *substream,
+				 struct sun4i_spdif_dev *host)
+{
+	/* SPDIF TX DISABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+			   SUN4I_SPDIF_TXCFG_TXEN, 0);
+
+	/* DRQ DISABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_INT,
+			   SUN4I_SPDIF_INT_TXDRQEN, 0);
+
+	/* Global disable */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_CTL,
+			   SUN4I_SPDIF_CTL_GEN, 0);
+}
+
+static int sun4i_spdif_startup(struct snd_pcm_substream *substream,
+			       struct snd_soc_dai *cpu_dai)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(rtd->cpu_dai);
+
+	if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK)
+		return -EINVAL;
+
+	sun4i_spdif_configure(host);
+
+	return 0;
+}
+
+static int sun4i_spdif_hw_params(struct snd_pcm_substream *substream,
+				 struct snd_pcm_hw_params *params,
+				 struct snd_soc_dai *cpu_dai)
+{
+	int ret = 0;
+	int fmt;
+	unsigned long rate = params_rate(params);
+	u32 mclk_div = 0;
+	unsigned int mclk = 0;
+	u32 reg_val;
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
+	struct platform_device *pdev = host->pdev;
+
+	/* Add the PCM and raw data select interface */
+	switch (params_channels(params)) {
+	case 1: /* PCM mode */
+	case 2:
+		fmt = 0;
+		break;
+	case 4: /* raw data mode */
+		fmt = SUN4I_SPDIF_TXCFG_NONAUDIO;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	switch (params_format(params)) {
+	case SNDRV_PCM_FORMAT_S16_LE:
+		fmt |= SUN4I_SPDIF_TXCFG_FMT16BIT;
+		break;
+	case SNDRV_PCM_FORMAT_S20_3LE:
+		fmt |= SUN4I_SPDIF_TXCFG_FMT20BIT;
+		break;
+	case SNDRV_PCM_FORMAT_S24_LE:
+		fmt |= SUN4I_SPDIF_TXCFG_FMT24BIT;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	switch (rate) {
+	case 22050:
+	case 44100:
+	case 88200:
+	case 176400:
+		mclk = 22579200;
+		break;
+	case 24000:
+	case 32000:
+	case 48000:
+	case 96000:
+	case 192000:
+		mclk = 24576000;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	ret = clk_set_rate(host->spdif_clk, mclk);
+	if (ret < 0) {
+		dev_err(&pdev->dev,
+			"Setting SPDIF clock rate for %d Hz failed!\n", mclk);
+		return ret;
+	}
+
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_FCTL,
+			   SUN4I_SPDIF_FCTL_TXIM, SUN4I_SPDIF_FCTL_TXIM);
+
+	switch (rate) {
+	case 22050:
+	case 24000:
+		mclk_div = 8;
+		break;
+	case 32000:
+		mclk_div = 6;
+		break;
+	case 44100:
+	case 48000:
+		mclk_div = 4;
+		break;
+	case 88200:
+	case 96000:
+		mclk_div = 2;
+		break;
+	case 176400:
+	case 192000:
+		mclk_div = 1;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	reg_val = 0;
+	reg_val |= SUN4I_SPDIF_TXCFG_ASS;
+	reg_val |= fmt; /* set non audio and bit depth */
+	reg_val |= SUN4I_SPDIF_TXCFG_CHSTMODE;
+	reg_val |= SUN4I_SPDIF_TXCFG_TXRATIO(mclk_div - 1);
+	regmap_write(host->regmap, SUN4I_SPDIF_TXCFG, reg_val);
+
+	return 0;
+}
+
+static int sun4i_spdif_trigger(struct snd_pcm_substream *substream, int cmd,
+			       struct snd_soc_dai *dai)
+{
+	int ret = 0;
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(dai);
+
+	if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK)
+		return -EINVAL;
+
+	switch (cmd) {
+	case SNDRV_PCM_TRIGGER_START:
+	case SNDRV_PCM_TRIGGER_RESUME:
+	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+		sun4i_snd_txctrl_on(substream, host);
+		break;
+
+	case SNDRV_PCM_TRIGGER_STOP:
+	case SNDRV_PCM_TRIGGER_SUSPEND:
+	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+		sun4i_snd_txctrl_off(substream, host);
+		break;
+
+	default:
+		ret = -EINVAL;
+		break;
+	}
+	return ret;
+}
+
+static int sun4i_spdif_soc_dai_probe(struct snd_soc_dai *dai)
+{
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(dai);
+
+	snd_soc_dai_init_dma_data(dai, &host->dma_params_tx, NULL);
+	return 0;
+}
+
+static const struct snd_soc_dai_ops sun4i_spdif_dai_ops = {
+	.startup	= sun4i_spdif_startup,
+	.trigger	= sun4i_spdif_trigger,
+	.hw_params	= sun4i_spdif_hw_params,
+};
+
+static const struct regmap_config sun4i_spdif_regmap_config = {
+	.reg_bits = 32,
+	.reg_stride = 4,
+	.val_bits = 32,
+	.max_register = SUN4I_SPDIF_RXCHSTA1,
+};
+
+#define SUN4I_RATES	SNDRV_PCM_RATE_8000_192000
+
+#define SUN4I_FORMATS	(SNDRV_PCM_FORMAT_S16_LE | \
+				SNDRV_PCM_FORMAT_S20_3LE | \
+				SNDRV_PCM_FORMAT_S24_LE)
+
+static struct snd_soc_dai_driver sun4i_spdif_dai = {
+	.playback = {
+		.channels_min = 1,
+		.channels_max = 2,
+		.rates = SUN4I_RATES,
+		.formats = SUN4I_FORMATS,
+	},
+	.probe = sun4i_spdif_soc_dai_probe,
+	.ops = &sun4i_spdif_dai_ops,
+	.name = "spdif",
+};
+
+static const struct snd_soc_dapm_widget dit_widgets[] = {
+	SND_SOC_DAPM_OUTPUT("spdif-out"),
+};
+
+static const struct snd_soc_dapm_route dit_routes[] = {
+	{ "spdif-out", NULL, "Playback" },
+};
+
+static const struct of_device_id sun4i_spdif_of_match[] = {
+	{ .compatible = "allwinner,sun4i-a10-spdif", },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sun4i_spdif_of_match);
+
+static const struct snd_soc_component_driver sun4i_spdif_component = {
+	.name		= "sun4i-spdif",
+};
+
+static int sun4i_spdif_runtime_suspend(struct device *dev)
+{
+	struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
+
+	clk_disable_unprepare(host->spdif_clk);
+	clk_disable_unprepare(host->apb_clk);
+
+	return 0;
+}
+
+static int sun4i_spdif_runtime_resume(struct device *dev)
+{
+	struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
+
+	clk_prepare_enable(host->spdif_clk);
+	clk_prepare_enable(host->apb_clk);
+
+	return 0;
+}
+
+static int sun4i_spdif_probe(struct platform_device *pdev)
+{
+	struct sun4i_spdif_dev *host;
+	struct resource *res;
+	int ret;
+	void __iomem *base;
+
+	dev_dbg(&pdev->dev, "Entered %s\n", __func__);
+
+	host = devm_kzalloc(&pdev->dev, sizeof(*host), GFP_KERNEL);
+	if (!host)
+		return -ENOMEM;
+
+	host->pdev = pdev;
+
+	/* Initialize this copy of the CPU DAI driver structure */
+	memcpy(&host->cpu_dai_drv, &sun4i_spdif_dai, sizeof(sun4i_spdif_dai));
+	host->cpu_dai_drv.name = dev_name(&pdev->dev);
+
+	/* Get the addresses */
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	host->regmap = devm_regmap_init_mmio(&pdev->dev, base,
+						&sun4i_spdif_regmap_config);
+
+	/* Clocks */
+	host->apb_clk = devm_clk_get(&pdev->dev, "apb");
+	if (IS_ERR(host->apb_clk)) {
+		dev_err(&pdev->dev, "failed to get a apb clock.\n");
+		return PTR_ERR(host->apb_clk);
+	}
+
+	host->spdif_clk = devm_clk_get(&pdev->dev, "spdif");
+	if (IS_ERR(host->spdif_clk)) {
+		dev_err(&pdev->dev, "failed to get a spdif clock.\n");
+		goto err_disable_apb_clk;
+	}
+
+	host->dma_params_tx.addr = res->start + SUN4I_SPDIF_TXFIFO;
+	host->dma_params_tx.maxburst = 4;
+	host->dma_params_tx.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
+
+	platform_set_drvdata(pdev, host);
+
+	ret = devm_snd_soc_register_component(&pdev->dev,
+				&sun4i_spdif_component, &sun4i_spdif_dai, 1);
+	if (ret)
+		goto err_disable_apb_clk;
+
+	pm_runtime_enable(&pdev->dev);
+	if (!pm_runtime_enabled(&pdev->dev)) {
+		ret = sun4i_spdif_runtime_resume(&pdev->dev);
+		if (ret)
+			goto err_unregister;
+	}
+
+	ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
+	if (ret)
+		goto err_suspend;
+	return 0;
+err_suspend:
+	if (!pm_runtime_status_suspended(&pdev->dev))
+		sun4i_spdif_runtime_suspend(&pdev->dev);
+err_unregister:
+	pm_runtime_disable(&pdev->dev);
+	snd_soc_unregister_component(&pdev->dev);
+err_disable_apb_clk:
+	clk_disable_unprepare(host->apb_clk);
+	return ret;
+}
+
+static int sun4i_spdif_remove(struct platform_device *pdev)
+{
+	pm_runtime_disable(&pdev->dev);
+	if (!pm_runtime_status_suspended(&pdev->dev))
+		sun4i_spdif_runtime_suspend(&pdev->dev);
+
+	snd_soc_unregister_platform(&pdev->dev);
+	snd_soc_unregister_component(&pdev->dev);
+
+	return 0;
+}
+
+static const struct dev_pm_ops sun4i_spdif_pm = {
+	SET_RUNTIME_PM_OPS(sun4i_spdif_runtime_suspend,
+			   sun4i_spdif_runtime_resume, NULL)
+};
+
+static struct platform_driver sun4i_spdif_driver = {
+	.driver		= {
+		.name	= "sun4i-spdif",
+		.of_match_table = of_match_ptr(sun4i_spdif_of_match),
+		.pm	= &sun4i_spdif_pm,
+	},
+	.probe		= sun4i_spdif_probe,
+	.remove		= sun4i_spdif_remove,
+};
+
+module_platform_driver(sun4i_spdif_driver);
+
+MODULE_AUTHOR("Marcus Cooper <codekipper at gmail.com>");
+MODULE_AUTHOR("Andrea Venturi <be17068 at iperbole.bo.it>");
+MODULE_DESCRIPTION("Allwinner sun4i SPDIF SoC Interface");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:sun4i-spdif");
-- 
2.7.1



From cyrille.pitchen at atmel.com  Mon Feb  8 07:26:48 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Mon, 8 Feb 2016 16:26:48 +0100
Subject: [PATCH 1/2] crypto: atmel-sha - fix .import()/.export() implementation
In-Reply-To: <cover.1454944687.git.cyrille.pitchen@atmel.com>
References: <cover.1454944687.git.cyrille.pitchen@atmel.com>
Message-ID: <f5ccc62efa50b810996632b2a584e9f8a192d3b1.1454944687.git.cyrille.pitchen@atmel.com>

Using only the digest, digcnt[], bufcnt and buffer[] fields of the
struct atmel_sha_reqctx was not enough to import/export the request state,
so now we use the whole structure.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
---
 drivers/crypto/atmel-sha.c | 44 ++++++++++----------------------------------
 1 file changed, 10 insertions(+), 34 deletions(-)

diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel-sha.c
index f8407dc7dd38..7d27f96cdf02 100644
--- a/drivers/crypto/atmel-sha.c
+++ b/drivers/crypto/atmel-sha.c
@@ -81,16 +81,9 @@ struct atmel_sha_caps {
 struct atmel_sha_dev;
 
 /*
- * .statesize = sizeof(struct atmel_sha_state) must be <= PAGE_SIZE / 8 as
+ * .statesize = sizeof(struct atmel_sha_reqctx) must be <= PAGE_SIZE / 8 as
  * tested by the ahash_prepare_alg() function.
  */
-struct atmel_sha_state {
-	u8	digest[SHA512_DIGEST_SIZE];
-	u8	buffer[SHA_BUFFER_LEN];
-	u64	digcnt[2];
-	size_t	bufcnt;
-};
-
 struct atmel_sha_reqctx {
 	struct atmel_sha_dev	*dd;
 	unsigned long	flags;
@@ -109,7 +102,7 @@ struct atmel_sha_reqctx {
 
 	size_t block_size;
 
-	u8	buffer[0] __aligned(sizeof(u32));
+	u8 buffer[SHA_BUFFER_LEN + SHA512_BLOCK_SIZE] __aligned(sizeof(u32));
 };
 
 struct atmel_sha_ctx {
@@ -1048,40 +1041,23 @@ static int atmel_sha_digest(struct ahash_request *req)
 static int atmel_sha_export(struct ahash_request *req, void *out)
 {
 	const struct atmel_sha_reqctx *ctx = ahash_request_ctx(req);
-	struct atmel_sha_state state;
-
-	memcpy(state.digest, ctx->digest, SHA512_DIGEST_SIZE);
-	memcpy(state.buffer, ctx->buffer, ctx->bufcnt);
-	state.bufcnt = ctx->bufcnt;
-	state.digcnt[0] = ctx->digcnt[0];
-	state.digcnt[1] = ctx->digcnt[1];
 
-	/* out might be unaligned. */
-	memcpy(out, &state, sizeof(state));
+	memcpy(out, ctx, sizeof(*ctx));
 	return 0;
 }
 
 static int atmel_sha_import(struct ahash_request *req, const void *in)
 {
 	struct atmel_sha_reqctx *ctx = ahash_request_ctx(req);
-	struct atmel_sha_state state;
-
-	/* in might be unaligned. */
-	memcpy(&state, in, sizeof(state));
 
-	memcpy(ctx->digest, state.digest, SHA512_DIGEST_SIZE);
-	memcpy(ctx->buffer, state.buffer, state.bufcnt);
-	ctx->bufcnt = state.bufcnt;
-	ctx->digcnt[0] = state.digcnt[0];
-	ctx->digcnt[1] = state.digcnt[1];
+	memcpy(ctx, in, sizeof(*ctx));
 	return 0;
 }
 
 static int atmel_sha_cra_init(struct crypto_tfm *tfm)
 {
 	crypto_ahash_set_reqsize(__crypto_ahash_cast(tfm),
-				 sizeof(struct atmel_sha_reqctx) +
-				 SHA_BUFFER_LEN + SHA512_BLOCK_SIZE);
+				 sizeof(struct atmel_sha_reqctx));
 
 	return 0;
 }
@@ -1097,7 +1073,7 @@ static struct ahash_alg sha_1_256_algs[] = {
 	.import		= atmel_sha_import,
 	.halg = {
 		.digestsize	= SHA1_DIGEST_SIZE,
-		.statesize	= sizeof(struct atmel_sha_state),
+		.statesize	= sizeof(struct atmel_sha_reqctx),
 		.base	= {
 			.cra_name		= "sha1",
 			.cra_driver_name	= "atmel-sha1",
@@ -1121,7 +1097,7 @@ static struct ahash_alg sha_1_256_algs[] = {
 	.import		= atmel_sha_import,
 	.halg = {
 		.digestsize	= SHA256_DIGEST_SIZE,
-		.statesize	= sizeof(struct atmel_sha_state),
+		.statesize	= sizeof(struct atmel_sha_reqctx),
 		.base	= {
 			.cra_name		= "sha256",
 			.cra_driver_name	= "atmel-sha256",
@@ -1147,7 +1123,7 @@ static struct ahash_alg sha_224_alg = {
 	.import		= atmel_sha_import,
 	.halg = {
 		.digestsize	= SHA224_DIGEST_SIZE,
-		.statesize	= sizeof(struct atmel_sha_state),
+		.statesize	= sizeof(struct atmel_sha_reqctx),
 		.base	= {
 			.cra_name		= "sha224",
 			.cra_driver_name	= "atmel-sha224",
@@ -1173,7 +1149,7 @@ static struct ahash_alg sha_384_512_algs[] = {
 	.import		= atmel_sha_import,
 	.halg = {
 		.digestsize	= SHA384_DIGEST_SIZE,
-		.statesize	= sizeof(struct atmel_sha_state),
+		.statesize	= sizeof(struct atmel_sha_reqctx),
 		.base	= {
 			.cra_name		= "sha384",
 			.cra_driver_name	= "atmel-sha384",
@@ -1197,7 +1173,7 @@ static struct ahash_alg sha_384_512_algs[] = {
 	.import		= atmel_sha_import,
 	.halg = {
 		.digestsize	= SHA512_DIGEST_SIZE,
-		.statesize	= sizeof(struct atmel_sha_state),
+		.statesize	= sizeof(struct atmel_sha_reqctx),
 		.base	= {
 			.cra_name		= "sha512",
 			.cra_driver_name	= "atmel-sha512",
-- 
1.8.2.2



From cyrille.pitchen at atmel.com  Mon Feb  8 07:26:49 2016
From: cyrille.pitchen at atmel.com (Cyrille Pitchen)
Date: Mon, 8 Feb 2016 16:26:49 +0100
Subject: [PATCH 2/2] crypto: atmel-sha - fix race in atmel_sha_final()
In-Reply-To: <cover.1454944687.git.cyrille.pitchen@atmel.com>
References: <cover.1454944687.git.cyrille.pitchen@atmel.com>
Message-ID: <bb132102ffbea635f08e583ca43e064924e11714.1454944687.git.cyrille.pitchen@atmel.com>

When (!ctx->bufcnt && !(ctx->flags & SHA_FLAGS_PAD)), the former source
code used to set the SHA_FLAGS_BUSY without checking whether this flag was
already set. If so, the hardware is already processing another hash
request so the processing of the req argument of atmel_sha_final() should
be delayed by queueing this request, the same way as done for the
(ctx->bufcnt != 0) case.

Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
---
 drivers/crypto/atmel-sha.c | 24 ++----------------------
 1 file changed, 2 insertions(+), 22 deletions(-)

diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel-sha.c
index 7d27f96cdf02..596e489a4ca9 100644
--- a/drivers/crypto/atmel-sha.c
+++ b/drivers/crypto/atmel-sha.c
@@ -979,37 +979,17 @@ static int atmel_sha_update(struct ahash_request *req)
 static int atmel_sha_final(struct ahash_request *req)
 {
 	struct atmel_sha_reqctx *ctx = ahash_request_ctx(req);
-	struct atmel_sha_ctx *tctx = crypto_tfm_ctx(req->base.tfm);
-	struct atmel_sha_dev *dd = tctx->dd;
-
-	int err = 0;
 
 	ctx->flags |= SHA_FLAGS_FINUP;
 
 	if (ctx->flags & SHA_FLAGS_ERROR)
 		return 0; /* uncompleted hash is not needed */
 
-	if (ctx->bufcnt) {
-		return atmel_sha_enqueue(req, SHA_OP_FINAL);
-	} else if (!(ctx->flags & SHA_FLAGS_PAD)) { /* add padding */
-		err = atmel_sha_hw_init(dd);
-		if (err)
-			goto err1;
-
-		dd->req = req;
-		dd->flags |= SHA_FLAGS_BUSY;
-		err = atmel_sha_final_req(dd);
-	} else {
+	if (ctx->flags & SHA_FLAGS_PAD)
 		/* copy ready hash (+ finalize hmac) */
 		return atmel_sha_finish(req);
-	}
-
-err1:
-	if (err != -EINPROGRESS)
-		/* done_task will not finish it, so do it here */
-		atmel_sha_finish_req(req, err);
 
-	return err;
+	return atmel_sha_enqueue(req, SHA_OP_FINAL);
 }
 
 static int atmel_sha_finup(struct ahash_request *req)
-- 
1.8.2.2



From marc.zyngier at arm.com  Mon Feb  8 07:29:33 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 8 Feb 2016 15:29:33 +0000
Subject: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <56B8B45D.1020902@arm.com>

On 08/02/16 09:11, Antoine Tenart wrote:
> This patch adds the initial support for the Alpine v2 EVP board from
> Annapurna Labs (Amazon).
> 
> Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
> Signed-off-by: Barak Wasserstrom <barak at annapurnalabs.com>
> Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
> ---
>  arch/arm64/boot/dts/Makefile             |   1 +
>  arch/arm64/boot/dts/al/Makefile          |   5 +
>  arch/arm64/boot/dts/al/alpine-v2-evp.dts |  46 +++++++
>  arch/arm64/boot/dts/al/alpine-v2.dtsi    | 221 +++++++++++++++++++++++++++++++
>  4 files changed, 273 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/al/Makefile
>  create mode 100644 arch/arm64/boot/dts/al/alpine-v2-evp.dts
>  create mode 100644 arch/arm64/boot/dts/al/alpine-v2.dtsi
> 
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index f832b8a7453a..fd80617a9c6f 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -1,3 +1,4 @@
> +dts-dirs += al
>  dts-dirs += altera
>  dts-dirs += amd
>  dts-dirs += apm
> diff --git a/arch/arm64/boot/dts/al/Makefile b/arch/arm64/boot/dts/al/Makefile
> new file mode 100644
> index 000000000000..8a6cde4f9b23
> --- /dev/null
> +++ b/arch/arm64/boot/dts/al/Makefile
> @@ -0,0 +1,5 @@
> +dtb-$(CONFIG_ARCH_ALPINE)	+= alpine-v2-evp.dtb
> +
> +always		:= $(dtb-y)
> +subdir-y	:= $(dts-dirs)
> +clean-files	:= *.dtb
> diff --git a/arch/arm64/boot/dts/al/alpine-v2-evp.dts b/arch/arm64/boot/dts/al/alpine-v2-evp.dts
> new file mode 100644
> index 000000000000..3e3080fa45e4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/al/alpine-v2-evp.dts
> @@ -0,0 +1,46 @@
> +/*
> + * Copyright 2016 Amazon.com, Inc. or its affiliates. All Rights Reserved.
> + *
> + * Antoine Tenart <antoine.tenart at free-electrons.com>
> + *
> + * This software is available to you under a choice of one of two
> + * licenses.  You may choose to be licensed under the terms of the GNU
> + * General Public License (GPL) Version 2, available from the file
> + * COPYING in the main directory of this source tree, or the
> + * BSD license below:
> + *
> + *     Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *      - Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *
> + *      - Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + */
> +
> +#include "alpine-v2.dtsi"
> +
> +/ {
> +	model = "Annapurna Labs Alpine v2 EVP";
> +	compatible = "al,alpine-v2-evp", "al,alpine-v2";
> +
> +	chosen {
> +		stdout-path = "console0:115200n8";
> +	};
> +};
> +
> +&uart0 { status = "okay"; };
> diff --git a/arch/arm64/boot/dts/al/alpine-v2.dtsi b/arch/arm64/boot/dts/al/alpine-v2.dtsi
> new file mode 100644
> index 000000000000..eb7a03b71456
> --- /dev/null
> +++ b/arch/arm64/boot/dts/al/alpine-v2.dtsi
> @@ -0,0 +1,221 @@
> +/*
> + * Copyright 2016 Amazon.com, Inc. or its affiliates. All Rights Reserved.
> + *
> + * Antoine Tenart <antoine.tenart at free-electrons.com>
> + *
> + * This software is available to you under a choice of one of two
> + * licenses.  You may choose to be licensed under the terms of the GNU
> + * General Public License (GPL) Version 2, available from the file
> + * COPYING in the main directory of this source tree, or the
> + * BSD license below:
> + *
> + *     Redistribution and use in source and binary forms, with or
> + *     without modification, are permitted provided that the following
> + *     conditions are met:
> + *
> + *      - Redistributions of source code must retain the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer.
> + *
> + *      - Redistributions in binary form must reproduce the above
> + *        copyright notice, this list of conditions and the following
> + *        disclaimer in the documentation and/or other materials
> + *        provided with the distribution.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> +	model = "Annapurna Labs Alpine v2";
> +	compatible = "al,alpine-v2";
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	aliases {
> +		serial0 = &uart0;
> +		serial1 = &uart1;
> +		serial2 = &uart2;
> +		serial3 = &uart3;
> +	};
> +
> +	cpus {
> +		#address-cells = <2>;
> +		#size-cells = <0>;
> +
> +		cpu at 0 {
> +			compatible = "arm,cortex-a57", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <0x0 0x0>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu at 1 {
> +			compatible = "arm,cortex-a57", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <0x0 0x1>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu at 2 {
> +			compatible = "arm,cortex-a57", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <0x0 0x2>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu at 3 {
> +			compatible = "arm,cortex-a57", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <0x0 0x3>;
> +			enable-method = "psci";
> +		};
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-0.2", "arm,psci";
> +		method = "smc";
> +		cpu_on = <0x84000003>;
> +	};
> +
> +	sbclk: sbclk {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <1000000>;
> +	};
> +
> +	soc {
> +		compatible = "simple-bus";
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +
> +		interrupt-parent = <&gic>;
> +		ranges;
> +
> +		timer {
> +			compatible = "arm,armv8-timer";
> +			interrupts = <GIC_PPI 0xd 0xff08>,
> +				     <GIC_PPI 0xe 0xff08>,
> +				     <GIC_PPI 0xb 0xff08>,
> +				     <GIC_PPI 0xa 0xff08>;
> +		};

This is not a valid interrupt specifier for GICv3, as the 3rd field
shouldn't bear this 0xff thing.

> +		gic: gic at f0100000 {
> +			compatible = "arm,gic-v3";
> +			reg = <0x0 0xf0200000 0x0 0x10000>,	/* GIC Dist */
> +			      <0x0 0xf0280000 0x0 0x200000>,	/* GICR */
> +			      <0x0 0xf0100000 0x0 0x2000>;	/* GICC */
> +			interrupt-controller;
> +			#interrupt-cells = <3>;
> +		};

Something is wrong here. Either you are missing GICH and GICV (assuming
you have legacy support), or you have an extra GICC region (which
doesn't make sense on its own).

You're also missing the maintenance interrupt.

Has Anapurna really built a GICv3 without an ITS?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From codekipper at gmail.com  Mon Feb  8 07:29:47 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Mon,  8 Feb 2016 16:29:47 +0100
Subject: [linux-sunxi][PATCH] ARM: dts: sun7i: Enable USB DRC on Olimex A20 EVB
Message-ID: <1454945387-29424-1-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

Enable the otg/drc usb controller on the Olimex A20 EVB.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
 arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
index c3c626b..93bbf26 100644
--- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
@@ -198,6 +198,10 @@
 	status = "okay";
 };
 
+&otg_sram {
+	status = "okay";
+};
+
 &pio {
 	ahci_pwr_pin_olimex_som_evb: ahci_pwr_pin at 1 {
 		allwinner,pins = "PC3";
@@ -219,6 +223,13 @@
 		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
 		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
 	};
+
+	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
+		allwinner,pins = "PH4";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
 };
 
 &reg_ahci_5v {
@@ -254,6 +265,10 @@
 	regulator-name = "avcc";
 };
 
+&reg_usb0_vbus {
+	status = "okay";
+};
+
 &reg_usb1_vbus {
 	status = "okay";
 };
@@ -268,7 +283,16 @@
 	status = "okay";
 };
 
+&usb_otg {
+	dr_mode = "otg";
+	status = "okay";
+};
+
 &usbphy {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb0_id_detect_pin>;
+	usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH04 */
+	usb0_vbus-supply = <&reg_usb0_vbus>;
 	usb1_vbus-supply = <&reg_usb1_vbus>;
 	usb2_vbus-supply = <&reg_usb2_vbus>;
 	status = "okay";
-- 
2.7.1



From marc.zyngier at arm.com  Mon Feb  8 07:31:09 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 8 Feb 2016 15:31:09 +0000
Subject: [GIT PULL] KVM/ARM updates for 4.5-rc2
In-Reply-To: <56B8B2DB.9020407@redhat.com>
References: <1453977038-13516-1-git-send-email-marc.zyngier@arm.com>
 <56B8B2DB.9020407@redhat.com>
Message-ID: <56B8B4BD.3080904@arm.com>

On 08/02/16 15:23, Paolo Bonzini wrote:
> 
> 
> On 28/01/2016 11:30, Marc Zyngier wrote:
>> Hi Paolo,
>>
>> Please find below the KVM/ARM updates for 4.5-rc2. Mostly fixes as a
>> result of Shannon's work on PMU emulation, which has outlined a few
>> nits here and there, plus a correctness fix from Dave.
>>
>> Please pull!
>>
>> Thanks,
>>
>> 	M.
>>
>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>
>>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvm-arm-for-4.5-rc2
>>
>> for you to fetch changes up to 6327f35a2010c06a3bc2bfb14202a38764fb9920:
>>
>>   arm64: KVM: Fix guest dead loop when register accessor returns false (2016-01-24 21:56:01 +0000)
>>
>> ----------------------------------------------------------------
>> KVM/ARM fixes for v4.5-rc2
>>
>> A few random fixes, mostly coming from the PMU work by Shannon:
>>
>> - fix for injecting faults coming from the guest's userspace
>> - cleanup for our CPTR_EL2 accessors (reserved bits)
>> - fix for a bug impacting perf (user/kernel discrimination)
>> - fix for a 32bit sysreg handling bug
>>
>> ----------------------------------------------------------------
> 
> Finally pulled, thanks.

Thanks Paolo. I'll send another PR in a couple of days for another fix
that landed last week.

	M.
-- 
Jazz is not dead. It just smells funny...


From geert at linux-m68k.org  Mon Feb  8 07:32:06 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 8 Feb 2016 16:32:06 +0100
Subject: [PATCH v2] clk: shmobile: r8a7795: Add SD divider support
In-Reply-To: <20160204193036.GA1958@tetsubishi>
References: <1454135639-4102-1-git-send-email-dirk.behme@gmail.com>
 <20160204193036.GA1958@tetsubishi>
Message-ID: <CAMuHMdW3Cp-Ga9NCb=TgGE7QxUTNp-PbOXsNu47Vvgcf-m0bSw@mail.gmail.com>

On Thu, Feb 4, 2016 at 8:30 PM, Wolfram Sang <wsa at the-dreams.de> wrote:
> On Sat, Jan 30, 2016 at 07:33:59AM +0100, Dirk Behme wrote:
>> This patch adds SD[0..3] clock divider support for R-Car Gen3 SoC.
>>
>> Signed-off-by: Takeshi Kihara <takeshi.kihara.df at renesas.com>
>> Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
>
> Tested-by: Wolfram Sang <wsa+renesas at sang-engineering.com>
>
> Since we don't have UHS support currently, changing the clock is not
> really exercised; but the code looks good and if it needs fixing, we can
> do it incrementally IMO. What is currently needed works fine on my
> Salvator-X for the exposed SD interfaces.

Thanks, will queue for next renesas-drivers and v4.6.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From hdegoede at redhat.com  Mon Feb  8 07:43:29 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Mon, 8 Feb 2016 16:43:29 +0100
Subject: [linux-sunxi][PATCH] ARM: dts: sun7i: Enable USB DRC on Olimex
 A20 EVB
In-Reply-To: <1454945387-29424-1-git-send-email-codekipper@gmail.com>
References: <1454945387-29424-1-git-send-email-codekipper@gmail.com>
Message-ID: <56B8B7A1.5020800@redhat.com>

Hi,

On 08-02-16 16:29, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
>
> Enable the otg/drc usb controller on the Olimex A20 EVB.

Does the A20 EVB not have some form of Vbus detect for the OTG
port hooked up ? That does not sound right. Please double check.

Regards,

Hans


>
> Signed-off-by: Marcus Cooper <codekipper at gmail.com>
> ---
>   arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 24 ++++++++++++++++++++++++
>   1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> index c3c626b..93bbf26 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> @@ -198,6 +198,10 @@
>   	status = "okay";
>   };
>
> +&otg_sram {
> +	status = "okay";
> +};
> +
>   &pio {
>   	ahci_pwr_pin_olimex_som_evb: ahci_pwr_pin at 1 {
>   		allwinner,pins = "PC3";
> @@ -219,6 +223,13 @@
>   		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>   		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>   	};
> +
> +	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
> +		allwinner,pins = "PH4";
> +		allwinner,function = "gpio_in";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +	};
>   };
>
>   &reg_ahci_5v {
> @@ -254,6 +265,10 @@
>   	regulator-name = "avcc";
>   };
>
> +&reg_usb0_vbus {
> +	status = "okay";
> +};
> +
>   &reg_usb1_vbus {
>   	status = "okay";
>   };
> @@ -268,7 +283,16 @@
>   	status = "okay";
>   };
>
> +&usb_otg {
> +	dr_mode = "otg";
> +	status = "okay";
> +};
> +
>   &usbphy {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&usb0_id_detect_pin>;
> +	usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH04 */
> +	usb0_vbus-supply = <&reg_usb0_vbus>;
>   	usb1_vbus-supply = <&reg_usb1_vbus>;
>   	usb2_vbus-supply = <&reg_usb2_vbus>;
>   	status = "okay";
>


From linux at arm.linux.org.uk  Mon Feb  8 07:45:59 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Feb 2016 15:45:59 +0000
Subject: [PATCH] net: am79c961a: avoid %? in inline assembly
In-Reply-To: <1454942025-2779812-1-git-send-email-arnd@arndb.de>
References: <1454942025-2779812-1-git-send-email-arnd@arndb.de>
Message-ID: <20160208154559.GM10826@n2100.arm.linux.org.uk>

On Mon, Feb 08, 2016 at 03:33:42PM +0100, Arnd Bergmann wrote:
> The am79c961a.c driver fails to build with clang because of an
> unusual inline assembly construct:
> 
> drivers/net/ethernet/amd/am79c961a.c:53:7: error: invalid % escape in inline assembly string
>  "str%?h        %1, [%2]        @ NET_RAP\n\t"
> 
> The same change has been done a decade ago in arch/arm as of
> 6a39dd6222dd ("[ARM] 3759/2: Remove uses of %?"), but apparently
> some drivers were missed.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>

Thanks Arnd.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From stefano.stabellini at eu.citrix.com  Mon Feb  8 07:46:04 2016
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 8 Feb 2016 15:46:04 +0000
Subject: [PATCH] xen/arm: correctly handle DMA mapping of compound
 pages
In-Reply-To: <1454938450-26282-1-git-send-email-ian.campbell@citrix.com>
References: <1454938450-26282-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1602081542410.27008@kaball.uk.xensource.com>

On Mon, 8 Feb 2016, Ian Campbell wrote:
> Currently xen_dma_map_page concludes that DMA to anything other than
> the head page of a compound page must be foreign, since the PFN of the
> page is that of the head.
> 
> Fix the check to instead consider the whole of a compound page to be
> local if the PFN of the head passes the 1:1 check.
> 
> We can never see a compound page which is a mixture of foreign and
> local sub-pages.
> 
> The comment already correctly described the intention, but fixup the
> spelling and some grammar.
> 
> This fixes the various SSH protocol errors which we have been seeing
> on the cubietrucks in our automated test infrastructure.
> 
> This has been broken since "xen/arm: use hypercall to flush caches in
> map_page" (3567258d281b), which was in v3.19-rc1.

checkpatch.pl reports a small style issue with this statement.


> NB arch/arm64/.../xen/page-coherent.h also includes this file.
> 
> Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
> Cc: xen-devel at lists.xenproject.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: stable at vger.kernel.org # v3.19+
> ---
>  arch/arm/include/asm/xen/page-coherent.h | 19 ++++++++++++-------
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
> index 0375c8c..5653739 100644
> --- a/arch/arm/include/asm/xen/page-coherent.h
> +++ b/arch/arm/include/asm/xen/page-coherent.h
> @@ -35,14 +35,19 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
>  	     dma_addr_t dev_addr, unsigned long offset, size_t size,
>  	     enum dma_data_direction dir, struct dma_attrs *attrs)
>  {
> -	bool local = XEN_PFN_DOWN(dev_addr) == page_to_xen_pfn(page);
> +	unsigned long page_pfn = page_to_xen_pfn(page);
> +	unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
> +	unsigned long compound_pages = 1<<compound_order(page);

To take care of 64k pages, this needs to be:

    unsigned long compound_pages = (1<<compound_order(page)) * XEN_PFN_PER_PAGE;


> +	bool local = page_pfn <= dev_pfn && dev_pfn - page_pfn < compound_pages;

Since you are at it, it might be worth adding brackets.


>  	/*
> -	 * Dom0 is mapped 1:1, while the Linux page can be spanned accross
> -	 * multiple Xen page, it's not possible to have a mix of local and
> -	 * foreign Xen page. So if the first xen_pfn == mfn the page is local
> -	 * otherwise it's a foreign page grant-mapped in dom0. If the page is
> -	 * local we can safely call the native dma_ops function, otherwise we
> -	 * call the xen specific function.
> +	 * Dom0 is mapped 1:1, while the Linux page can span across
> +	 * multiple Xen pages, it's not possible for it to contain a
> +	 * mix of local and foreign Xen pages. So if the first xen_pfn
> +	 * == mfn the page is local otherwise it's a foreign page
> +	 * grant-mapped in dom0. If the page is local we can safely
> +	 * call the native dma_ops function, otherwise we call the xen
> +	 * specific function.
>  	 */
>  	if (local)
>  		__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
> -- 
> 2.1.4
> 


From gregory.clement at free-electrons.com  Mon Feb  8 07:49:40 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 08 Feb 2016 16:49:40 +0100
Subject: [PATCH 0/2] ARM: mvebu: misc DT improvements
In-Reply-To: <1453908287-29557-1-git-send-email-thomas.petazzoni@free-electrons.com>
 (Thomas Petazzoni's message of "Wed, 27 Jan 2016 16:24:45 +0100")
References: <1453908287-29557-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <87pow719t7.fsf@free-electrons.com>

Hi Thomas,
 
 On mer., janv. 27 2016, Thomas Petazzoni <thomas.petazzoni at free-electrons.com> wrote:

> Hello,
>
> Here are two fixes/improvements for Marvell EBU platforms, which were
> initially sent on June 18th 2015, and never got any feedback.
>
> This new iteration is simply rebased on v4.5-rc1 with no other
> changes.

Could you send a new version taking into account the comment from
Andrew?

Thanks,

Gregory

>
> Thanks!
>
> Thomas
>
> Lior Amsalem (1):
>   ARM: mvebu: use armada-370-sata for SATA on Armada 375
>
> Thomas Petazzoni (1):
>   ARM: mvebu: add NAND description to Armada 370 DB and Armada XP DB
>
>  arch/arm/boot/dts/armada-370-db.dts | 21 +++++++++++++++++++++
>  arch/arm/boot/dts/armada-375.dtsi   |  2 +-
>  arch/arm/boot/dts/armada-xp-db.dts  | 21 +++++++++++++++++++++
>  3 files changed, 43 insertions(+), 1 deletion(-)
>
> -- 
> 2.6.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From dcb314 at hotmail.com  Mon Feb  8 07:50:50 2016
From: dcb314 at hotmail.com (David Binderman)
Date: Mon, 8 Feb 2016 15:50:50 +0000
Subject: linux-4.5-rc3/arch/arm/mach-ux500/cpu-db8500.c:89: statement after
 return ?
Message-ID: <DUB128-W6810AD43780578EF2A48789CD50@phx.gbl>

Hello there,

[linux-4.5-rc3/arch/arm/mach-ux500/cpu-db8500.c:89]: (style) Statements following return, break, continue, goto or throw will never be executed.

Source code is

??? return kasprintf(GFP_KERNEL, "%08x%08x%08x%08x%08x",
???????????? readl((u32 *)uid+0),
???????????? readl((u32 *)uid+1), readl((u32 *)uid+2),
???????????? readl((u32 *)uid+3), readl((u32 *)uid+4));
??? iounmap(uid);
}

This looks like a cut-n-paste error to me. Suggest rework.

Regards

David Binderman

 		 	   		  

From gregory.clement at free-electrons.com  Mon Feb  8 07:52:07 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 08 Feb 2016 16:52:07 +0100
Subject: [PATCH v2 0/3] fix and new support for orion5x based linkstation
In-Reply-To: <1454738393-14114-1-git-send-email-rogershimizu@gmail.com> (Roger
 Shimizu's message of "Sat, 6 Feb 2016 14:59:50 +0900")
References: <1454689998-9579-1-git-send-email-rogershimizu@gmail.com>
 <1454738393-14114-1-git-send-email-rogershimizu@gmail.com>
Message-ID: <87lh6v19p4.fsf@free-electrons.com>

Hi Roger,
 
 On sam., f?vr. 06 2016, Roger Shimizu <rogershimizu at gmail.com> wrote:

> Dear Orion5x Maintainer,
>
> Here're fix and new support for orion5x based linkstation devices.
>
> Firstly, it add the missing mtd flash support, which I consider a fix
> and can be backported to stable kernels, so I made the patch explicit.
>
> Second, like the changes I made for kirkwood based linkstation DT,
> I split the orion5x-linkstation-lswtgl.dts file into common and device
> specific part, in order to support more devices.
>
> Third, so there's a new device.
>
> Hope this can be kindly accepted. Thank you!
>
> Changes in v2:
> - add "Fixes" tag for patch 1/3
> - add "mvebu-" prefix to common .dtsi file to share between orion5x
>   and kirkwood, which address comment from Andrew Lunn
> - add "Reviewed-by" tag from Andrew Lunn for all 3 patches
>
> Cheers,
> Roger
>
> Roger Shimizu (3):
>   ARM: dts: orion5x: fix the missing mtd flash on linkstation lswtgl
>   ARM: dts: orion5x: split linkstation lswtgl into common and device
>     parts
>   ARM: dts: orion5x: add device tree for buffalo linkstation ls-gl


The 3 patches have been applied on mvebu/dt

Thanks,

Gregory


>
>  arch/arm/boot/dts/Makefile                         |   1 +
>  arch/arm/boot/dts/mvebu-linkstation-fan.dtsi       |  72 +++++++
>  .../boot/dts/mvebu-linkstation-gpio-simple.dtsi    | 105 ++++++++++
>  arch/arm/boot/dts/orion5x-linkstation-lsgl.dts     |  87 +++++++++
>  arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts   | 214 +++++----------------
>  arch/arm/boot/dts/orion5x-linkstation.dtsi         | 180 +++++++++++++++++
>  6 files changed, 491 insertions(+), 168 deletions(-)
>  create mode 100644 arch/arm/boot/dts/mvebu-linkstation-fan.dtsi
>  create mode 100644 arch/arm/boot/dts/mvebu-linkstation-gpio-simple.dtsi
>  create mode 100644 arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
>  create mode 100644 arch/arm/boot/dts/orion5x-linkstation.dtsi
>
> -- 
> 2.1.4
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From paul.gortmaker at windriver.com  Mon Feb  8 07:53:24 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Mon, 8 Feb 2016 10:53:24 -0500
Subject: [PATCH 4/5] drivers/pci: make host/pci-keystone-dw.c modular
In-Reply-To: <91848876.ZYig6qgHLq@wuerfel>
References: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
 <1454889644-27830-5-git-send-email-paul.gortmaker@windriver.com>
 <91848876.ZYig6qgHLq@wuerfel>
Message-ID: <20160208155324.GU23093@windriver.com>

[Re: [PATCH 4/5] drivers/pci: make host/pci-keystone-dw.c modular] On 08/02/2016 (Mon 10:59) Arnd Bergmann wrote:

> On Sunday 07 February 2016 19:00:43 Paul Gortmaker wrote:
> > Export the symbols that this driver requires in order for it to
> > be modular.  In addition to the one use case of a dw_pci sym, it
> > has many instances of its own ks_dw_pci syms that need exporting
> > in order to modpost w/o error.
> > 
> > Cc: Murali Karicheri <m-karicheri2 at ti.com>
> > Cc: Bjorn Helgaas <bhelgaas at google.com>
> > Cc: Stanimir Varbanov <svarbanov at mm-sol.com>
> > Cc: Geert Uytterhoeven <geert+renesas at glider.be>
> > Cc: Thierry Reding <thierry.reding at gmail.com>
> > Cc: Arnd Bergmann <arnd at arndb.de>
> > Cc: linux-pci at vger.kernel.org
> > Cc: linux-arm-kernel at lists.infradead.org
> > Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> > ---
> 
> 
> Could we just have one module for the driver  instead of two?

That thought crossed my mind, but I was considering merging the C files
and figured it might be more churn than the maintainer wanted.  If
maintainers are good with the below (assuming it works) then yes that
also seems reasonable.

P.
--

> 
> Something like below (untested)
> 
> 	Arnd
> 
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 7b2f20c6ccc6..0b472c680348 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -8,7 +8,8 @@ obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
>  obj-$(CONFIG_PCI_RCAR_GEN2_PCIE) += pcie-rcar.o
>  obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
>  obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
> -obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
> +obj-$(CONFIG_PCI_KEYSTONE) pci-keystone-mod.o
> +pci-keystone-mod-objs := pci-keystone-dw.o pci-keystone.o
>  obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
>  obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
>  obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
> 


From robh at kernel.org  Mon Feb  8 07:54:05 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 09:54:05 -0600
Subject: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
In-Reply-To: <20160204165151.GK4270@lukather>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-6-git-send-email-andre.przywara@arm.com>
 <20160201182754.GA14737@excalibur.cnev.de>
 <56AFE0EC.8080207@arm.com> <20160202100046.GM4652@lukather>
 <56B0DF26.10203@arm.com> <20160204165151.GK4270@lukather>
Message-ID: <20160208155405.GA4677@rob-hp-laptop>

On Thu, Feb 04, 2016 at 05:51:51PM +0100, Maxime Ripard wrote:
> Hi Andre,
> 
> On Tue, Feb 02, 2016 at 04:53:58PM +0000, Andre Przywara wrote:
> > > So, droping it in the filenames, why not. But I'd really like to keep
> > > the same compatible scheme.
> > 
> > And I still don't get this: in the DT compatible scheme we always have a
> > vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. core
> > or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So
> > why should we add an arbitrary and confusing sun50i naming to it (when
> > it actually should be more like "sun8i-a64").
> 
> I don't decide on their marketing names. And I know you want to start
> anew with the arm64 SoCs, but the truth is, you don't. Most of the
> compatibles in the DTSI are from earlier SoCs, and we have to keep
> that legacy and remain consistent with it. With all the good and bad
> things a legacy imply.

I have to agree. Unless there is some agreement to move to another 
naming scheme, then just follow the same pattern. If sunXi is just a 
made up name outside of Allwinner to provide some logical grouping of 
SoCs, then yes, that probably should not have been done.

Rob


From gabriele.paoloni at huawei.com  Mon Feb  8 07:55:35 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Mon, 8 Feb 2016 15:55:35 +0000
Subject: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host
 controller ECAM compliant
In-Reply-To: <3532826.pJr5R5Xa4c@wuerfel>
References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
 <1454935264-6076-3-git-send-email-gabriele.paoloni@huawei.com>
 <3532826.pJr5R5Xa4c@wuerfel>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECACF44@lhreml503-mbs>

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 08 February 2016 13:48
> To: linux-arm-kernel at lists.infradead.org
> Cc: Gabriele Paoloni; Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong
> (C); Linuxarm; qiujiang; bhelgaas at google.com;
> Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-pci at vger.kernel.org;
> linux-kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth)
> Subject: Re: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host
> controller ECAM compliant
> 
> On Monday 08 February 2016 12:41:03 Gabriele Paoloni wrote:
> > From: gabriele paoloni <gabriele.paoloni at huawei.com>
> >
> > This patch modifies the current Hip05/Hip06 PCIe host controller
> > driver to make it ECAM compliant. This is needed in preparation
> > for the ACPI based driver to allow both DT and ACPI drivers to
> > use the same BIOS (that configure the Designware iATUs).
> >
> > Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
> > Signed-off-by: Dongdong Liu <liudongdong3 at huawei.com>
> >
> 
> Doesn't this break backwards compatibility?

Well Hip05/Hip06 SoCs are used into evaluation boards
For the Estuary project.

https://github.com/hisilicon/estuary

As this new driver gets upstream we'll merge this new driver into estuary
and release a new version of the firmware to support it.

> 
> I think you need to use a new compatible string in the firmware
> if you change the register layout, and then change the driver
> to support both the old and the new layout.

You are right, for some reason in this patchset I missed the Documentation
update that I posted in the previous one, i.e.:

--- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
@@ -23,8 +23,8 @@ Optional properties:
 Hip05 Example (note that Hip06 is the same except compatible):
 	pcie at 0xb0080000 {
 		compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
-		reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0 0x2000>;
-		reg-names = "rc_dbi", "config";
+		reg = <0 0xb0080000 0 0x10000>, <0x220 0x00100000 0 0x0f00000>;
+		reg-names = "rc_dbi", "ecam-cfg";

I will fix this in v3

Thanks

Gab 


> 
> 	Arnd


From catalin.marinas at arm.com  Mon Feb  8 07:56:26 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 8 Feb 2016 15:56:26 +0000
Subject: [PATCH v3 21/23] arm64: hw_breakpoint: Allow EL2 breakpoints if
 running in HYP
In-Reply-To: <1454522416-6874-22-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-22-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160208155625.GQ6076@e104818-lin.cambridge.arm.com>

On Wed, Feb 03, 2016 at 06:00:14PM +0000, Marc Zyngier wrote:
> @@ -76,6 +59,36 @@ static inline void decode_ctrl_reg(u32 reg,
>  #define ARM_KERNEL_STEP_ACTIVE	1
>  #define ARM_KERNEL_STEP_SUSPEND	2
>  
> +#define DBG_HMC_HYP		(1 << 13)
> +#define DBG_SSC_HYP		(3 << 14)
> +
> +static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
> +{
> +	u32 val = (ctrl.len << 5) | (ctrl.type << 3) | ctrl.enabled;
> +
> +	if (is_kernel_in_hyp_mode() && ctrl.privilege == AARCH64_BREAKPOINT_EL1)
> +		val |= DBG_HMC_HYP | DBG_SSC_HYP;
> +	else
> +		val |= ctrl.privilege << 1;
> +
> +	return val;
> +}
> +
> +static inline void decode_ctrl_reg(u32 reg,
> +				   struct arch_hw_breakpoint_ctrl *ctrl)
> +{
> +	ctrl->enabled	= reg & 0x1;
> +	reg >>= 1;
> +	if (is_kernel_in_hyp_mode())
> +		ctrl->privilege = !!(reg & (DBG_HMC_HYP >> 1));

I don't particularly like this part as it's not clear just by looking at
the code that it, in fact, generates AARCH64_BREAKPOINT_EL1. I would
make this clearer:

	if (is_kernel_in_hyp_mode() && (reg & (DBG_HMC_HYP >> 1)))
		ctrl->privilege = AARCH64_BREAKPOINT_EL1;

Alternatively, you could define the PMC field value as:

#define AARCH64_BREAKPOINT_EL2	0

and change the privilege to EL1 after masking, something like:

	ctrl->privilege = reg & 0x3;
	if (ctrl->privilege == AARCH64_BREAKPOINT_EL2)
		ctrl->privilege = AARCH64_BREAKPOINT_EL1;

BTW, do we need to check is_kernel_in_hyp_mode() when decoding? Is there
anything else that could have set this SSC/HMC/PMC fields other than
encode_ctrl_reg()?

-- 
Catalin


From robh at kernel.org  Mon Feb  8 07:57:21 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 09:57:21 -0600
Subject: [PATCH 07/11] clk: sunxi: add generic allwinner,sunxi name
In-Reply-To: <1454348370-3816-8-git-send-email-andre.przywara@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-8-git-send-email-andre.przywara@arm.com>
Message-ID: <20160208155721.GB4677@rob-hp-laptop>

On Mon, Feb 01, 2016 at 05:39:26PM +0000, Andre Przywara wrote:
> The only difference between the different compatible matches at the
> end of clk-sunxi.c are the critical clocks. Two SoCs get away so far
> without any, so there is no reason to enumerate those SoCs in here
> explicitly, though we have to keep them in for compatibility reasons.
> 
> Rename the init function to highlight this generic feature and add a
> new, generic DT compatible string which can be used as a fallback value
> in the future should a particular SoC don't need any special treatment.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  Documentation/devicetree/bindings/arm/sunxi.txt |  4 ++++
>  drivers/clk/sunxi/clk-sunxi.c                   | 14 ++++++--------
>  2 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
> index 7e79fcc..980e065 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -14,3 +14,7 @@ using one of the following compatible strings:
>    allwinner,sun8i-a83t
>    allwinner,sun8i-h3
>    allwinner,sun9i-a80
> +
> +For Allwinner SoCs without any specific needs the generic fallback value of:
> +  allwinner,sunxi
> +can be used.

Perhaps "fallback" implies this, but be more specific that it can be 
used in addition to a specific string.

> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index e460a6b..efcce85 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -1052,14 +1052,12 @@ CLK_OF_DECLARE(sun8i_a23_clk_init, "allwinner,sun8i-a23", sun6i_init_clocks);
>  CLK_OF_DECLARE(sun8i_a33_clk_init, "allwinner,sun8i-a33", sun6i_init_clocks);
>  CLK_OF_DECLARE(sun8i_h3_clk_init, "allwinner,sun8i-h3", sun6i_init_clocks);
>  
> -static void __init sun8i_a83t_init_clocks(struct device_node *node)
> +static void __init sunxi_generic_init_clocks(struct device_node *node)
>  {
>  	sunxi_init_clocks(NULL, 0);
>  }
> -CLK_OF_DECLARE(sun8i_a83t_clk_init, "allwinner,sun8i-a83t", sun8i_a83t_init_clocks);
> -
> -static void __init sun9i_init_clocks(struct device_node *node)
> -{
> -	sunxi_init_clocks(NULL, 0);
> -}
> -CLK_OF_DECLARE(sun9i_a80_clk_init, "allwinner,sun9i-a80", sun9i_init_clocks);
> +CLK_OF_DECLARE(sun8i_a83t_clk_init, "allwinner,sun8i-a83t",
> +	       sunxi_generic_init_clocks);
> +CLK_OF_DECLARE(sun9i_a80_clk_init, "allwinner,sun9i-a80",
> +	       sunxi_generic_init_clocks);
> +CLK_OF_DECLARE(sunxi_clk_init, "allwinner,sunxi", sunxi_generic_init_clocks);
> -- 
> 2.6.4
> 


From catalin.marinas at arm.com  Mon Feb  8 07:58:04 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 8 Feb 2016 15:58:04 +0000
Subject: [PATCH v3 22/23] arm64: VHE: Add support for running Linux in
 EL2 mode
In-Reply-To: <1454522416-6874-23-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-23-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160208155804.GR6076@e104818-lin.cambridge.arm.com>

On Wed, Feb 03, 2016 at 06:00:15PM +0000, Marc Zyngier wrote:
> With ARMv8.1 VHE, the architecture is able to (almost) transparently
> run the kernel at EL2, despite being written for EL1.
> 
> This patch takes care of the "almost" part, mostly preventing the kernel
> from dropping from EL2 to EL1, and setting up the HYP configuration.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From andre.przywara at arm.com  Mon Feb  8 07:58:18 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 8 Feb 2016 15:58:18 +0000
Subject: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
In-Reply-To: <20160208155405.GA4677@rob-hp-laptop>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-6-git-send-email-andre.przywara@arm.com>
 <20160201182754.GA14737@excalibur.cnev.de> <56AFE0EC.8080207@arm.com>
 <20160202100046.GM4652@lukather> <56B0DF26.10203@arm.com>
 <20160204165151.GK4270@lukather> <20160208155405.GA4677@rob-hp-laptop>
Message-ID: <56B8BB1A.8010705@arm.com>

Hi,

On 08/02/16 15:54, Rob Herring wrote:
> On Thu, Feb 04, 2016 at 05:51:51PM +0100, Maxime Ripard wrote:
>> Hi Andre,
>>
>> On Tue, Feb 02, 2016 at 04:53:58PM +0000, Andre Przywara wrote:
>>>> So, droping it in the filenames, why not. But I'd really like to keep
>>>> the same compatible scheme.
>>>
>>> And I still don't get this: in the DT compatible scheme we always have a
>>> vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. core
>>> or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So
>>> why should we add an arbitrary and confusing sun50i naming to it (when
>>> it actually should be more like "sun8i-a64").
>>
>> I don't decide on their marketing names. And I know you want to start
>> anew with the arm64 SoCs, but the truth is, you don't. Most of the
>> compatibles in the DTSI are from earlier SoCs, and we have to keep
>> that legacy and remain consistent with it. With all the good and bad
>> things a legacy imply.
> 
> I have to agree. Unless there is some agreement to move to another 
> naming scheme, then just follow the same pattern. If sunXi is just a 
> made up name outside of Allwinner to provide some logical grouping of 
> SoCs, then yes, that probably should not have been done.

So I still don't like it, but will not waste my time or energy on that
front.

Maxime, do you want "allwinner,sun50i-a64" or would
"allwinner,sunxi-a64" be OK as well?

Cheers,
Andre.


From gregory.clement at free-electrons.com  Mon Feb  8 07:58:27 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 08 Feb 2016 16:58:27 +0100
Subject: [PATCH 1/1] ARM: kirkwood-ds112.dts: use unique machine name
In-Reply-To: <20160207192632.GA28121@lunn.ch> (Andrew Lunn's message of "Sun, 
 7 Feb 2016 20:26:32 +0100")
References: <1454870066-3353-1-git-send-email-xypron.glpk@gmx.de>
 <20160207192632.GA28121@lunn.ch>
Message-ID: <87h9hj19ek.fsf@free-electrons.com>

Hi Heinrich,
 
 On dim., f?vr. 07 2016, Andrew Lunn <andrew at lunn.ch> wrote:

> On Sun, Feb 07, 2016 at 07:34:26PM +0100, Heinrich Schuchardt wrote:
>> Downstream packages like Debian flash-kernel use
>> /proc/device-tree/model
>> to determine which dtb file to install.
>> 
>> Hence each dts in the Linux kernel should provide a unique model
>> identifier.
>> 
>> Commit 2d0a7addbd10 ("ARM: Kirkwood: Add support for many Synology NAS
>> devices") created the new files kirkwood-ds111.dts and kirkwood-ds112.dts
>> using the same model identifier.
>> 
>> This patch provides a unique model identifier for the
>> Synology DiskStation DS112.
>> 
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
>
> Fixes: 2d0a7addbd10 ("ARM: Kirkwood: Add support for many Synology NAS devices")
>
> Reviewed-by: Andrew Lunn <andrew at lunn.ch>

Applied on mvebu/fixes with the Fixes tag and Andrew Reviewed-by tag.

Thanks,

Gregory



>
>     Thanks
> 	Andrew	     
>
>> ---
>>  arch/arm/boot/dts/kirkwood-ds112.dts | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/arch/arm/boot/dts/kirkwood-ds112.dts b/arch/arm/boot/dts/kirkwood-ds112.dts
>> index bf4143c..b84af3d 100644
>> --- a/arch/arm/boot/dts/kirkwood-ds112.dts
>> +++ b/arch/arm/boot/dts/kirkwood-ds112.dts
>> @@ -14,7 +14,7 @@
>>  #include "kirkwood-synology.dtsi"
>>  
>>  / {
>> -	model = "Synology DS111";
>> +	model = "Synology DS112";
>>  	compatible = "synology,ds111", "marvell,kirkwood";
>>  
>>  	memory {
>> -- 
>> 2.1.4
>> 

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From codekipper at gmail.com  Mon Feb  8 07:59:27 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Mon,  8 Feb 2016 16:59:27 +0100
Subject: [linux-sunxi][PATCH] ARM: dts: sun7i: Enable USB DRC on Itead Ibox
Message-ID: <1454947167-12236-1-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

Enable the otg/drc usb controller on the Itead Ibox device.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
 arch/arm/boot/dts/sun7i-a20-itead-ibox.dts     | 14 ++++++++++++++
 arch/arm/boot/dts/sunxi-itead-core-common.dtsi |  9 +++++++++
 2 files changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
index 661c21d..a512581 100644
--- a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
+++ b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
@@ -118,8 +118,22 @@
 		allwinner,drive = <SUN4I_PINCTRL_20_MA>;
 		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
 	};
+
+	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
+		allwinner,pins = "PH4";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
 };
 
 &reg_ahci_5v {
 	status = "okay";
 };
+
+&usbphy {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb0_id_detect_pin>;
+	usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
index 2565d51..d22eea3 100644
--- a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
+++ b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
@@ -88,6 +88,10 @@
 	status = "okay";
 };
 
+&otg_sram {
+	status = "okay";
+};
+
 #include "axp209.dtsi"
 
 &reg_dcdc2 {
@@ -129,6 +133,11 @@
 	status = "okay";
 };
 
+&usb_otg {
+	dr_mode = "otg";
+	status = "okay";
+};
+
 &usbphy {
 	usb1_vbus-supply = <&reg_usb1_vbus>;
 	usb2_vbus-supply = <&reg_usb2_vbus>;
-- 
2.7.1



From ian.campbell at citrix.com  Mon Feb  8 07:59:32 2016
From: ian.campbell at citrix.com (Ian Campbell)
Date: Mon, 8 Feb 2016 15:59:32 +0000
Subject: [PATCH] xen/arm: correctly handle DMA mapping of compound pages
In-Reply-To: <alpine.DEB.2.02.1602081542410.27008@kaball.uk.xensource.com>
References: <1454938450-26282-1-git-send-email-ian.campbell@citrix.com>
 <alpine.DEB.2.02.1602081542410.27008@kaball.uk.xensource.com>
Message-ID: <1454947172.17191.4.camel@citrix.com>

On Mon, 2016-02-08 at 15:46 +0000, Stefano Stabellini wrote:
> On Mon, 8 Feb 2016, Ian Campbell wrote:
> > Currently xen_dma_map_page concludes that DMA to anything other than
> > the head page of a compound page must be foreign, since the PFN of the
> > page is that of the head.
> > 
> > Fix the check to instead consider the whole of a compound page to be
> > local if the PFN of the head passes the 1:1 check.
> > 
> > We can never see a compound page which is a mixture of foreign and
> > local sub-pages.
> > 
> > The comment already correctly described the intention, but fixup the
> > spelling and some grammar.
> > 
> > This fixes the various SSH protocol errors which we have been seeing
> > on the cubietrucks in our automated test infrastructure.
> > 
> > This has been broken since "xen/arm: use hypercall to flush caches in
> > map_page" (3567258d281b), which was in v3.19-rc1.
> 
> checkpatch.pl reports a small style issue with this statement.

Damn, I added that para after I'd already run checkpatch.

> [...]
> 
> To take care of 64k pages, this needs to be:
> 
{...]

> Since you are at it, it might be worth adding brackets.

Will do on both counts. v2 on its way.

Ian.


From ian.campbell at citrix.com  Mon Feb  8 08:02:06 2016
From: ian.campbell at citrix.com (Ian Campbell)
Date: Mon, 8 Feb 2016 16:02:06 +0000
Subject: [PATCH v2] xen/arm: correctly handle DMA mapping of compound pages
Message-ID: <1454947330-29993-1-git-send-email-ian.campbell@citrix.com>

Currently xen_dma_map_page concludes that DMA to anything other than
the head page of a compound page must be foreign, since the PFN of the
page is that of the head.

Fix the check to instead consider the whole of a compound page to be
local if the PFN of the head passes the 1:1 check.

We can never see a compound page which is a mixture of foreign and
local sub-pages.

The comment already correctly described the intention, but fixup the
spelling and some grammar.

This fixes the various SSH protocol errors which we have been seeing
on the cubietrucks in our automated test infrastructure.

This has been broken since commit 3567258d281b ("xen/arm: use
hypercall to flush caches in map_page"), which was in v3.19-rc1.

NB arch/arm64/.../xen/page-coherent.h also includes this file.

Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
Cc: xen-devel at lists.xenproject.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: stable at vger.kernel.org # v3.19+
---
v2: Placate checkpatch
    Handle 64K pages
    Add some ()s
---
 arch/arm/include/asm/xen/page-coherent.h | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index 0375c8c..9408a99 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -35,14 +35,21 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
 	     dma_addr_t dev_addr, unsigned long offset, size_t size,
 	     enum dma_data_direction dir, struct dma_attrs *attrs)
 {
-	bool local = XEN_PFN_DOWN(dev_addr) == page_to_xen_pfn(page);
+	unsigned long page_pfn = page_to_xen_pfn(page);
+	unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
+	unsigned long compound_pages =
+		(1<<compound_order(page)) * XEN_PFN_PER_PAGE;
+	bool local = (page_pfn <= dev_pfn) &&
+		(dev_pfn - page_pfn < compound_pages);
+
 	/*
-	 * Dom0 is mapped 1:1, while the Linux page can be spanned accross
-	 * multiple Xen page, it's not possible to have a mix of local and
-	 * foreign Xen page. So if the first xen_pfn == mfn the page is local
-	 * otherwise it's a foreign page grant-mapped in dom0. If the page is
-	 * local we can safely call the native dma_ops function, otherwise we
-	 * call the xen specific function.
+	 * Dom0 is mapped 1:1, while the Linux page can span across
+	 * multiple Xen pages, it's not possible for it to contain a
+	 * mix of local and foreign Xen pages. So if the first xen_pfn
+	 * == mfn the page is local otherwise it's a foreign page
+	 * grant-mapped in dom0. If the page is local we can safely
+	 * call the native dma_ops function, otherwise we call the xen
+	 * specific function.
 	 */
 	if (local)
 		__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
-- 
2.1.4



From catalin.marinas at arm.com  Mon Feb  8 08:04:46 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 8 Feb 2016 16:04:46 +0000
Subject: [PATCH v3 23/23] arm64: Panic when VHE and non VHE CPUs coexist
In-Reply-To: <1454522416-6874-24-git-send-email-marc.zyngier@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-24-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160208160445.GS6076@e104818-lin.cambridge.arm.com>

On Wed, Feb 03, 2016 at 06:00:16PM +0000, Marc Zyngier wrote:
> Having both VHE and non-VHE capable CPUs in the same system
> is likely to be a recipe for disaster.
> 
> If the boot CPU has VHE, but a secondary is not, we won't be
> able to downgrade and run the kernel at EL1. Add CPU hotplug
> to the mix, and this produces a terrifying mess.
> 
> Let's solve the problem once and for all. If you mix VHE and
> non-VHE CPUs in the same system, you deserve to loose, and this
> patch makes sure you don't get a chance.
> 
> This is implemented by storing the kernel execution level in
> a global variable. Secondaries will park themselves in a
> WFI loop if they observe a mismatch. Also, the primary CPU
> will detect that the secondary CPU has died on a mismatched
> execution level. Panic will follow.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/virt.h | 17 +++++++++++++++++
>  arch/arm64/kernel/head.S      | 20 ++++++++++++++++++++
>  arch/arm64/kernel/smp.c       |  3 +++
>  3 files changed, 40 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
> index 9f22dd6..f81a345 100644
> --- a/arch/arm64/include/asm/virt.h
> +++ b/arch/arm64/include/asm/virt.h
> @@ -36,6 +36,11 @@
>   */
>  extern u32 __boot_cpu_mode[2];
>  
> +/*
> + * __run_cpu_mode records the mode the boot CPU uses for the kernel.
> + */
> +extern u32 __run_cpu_mode[2];
> +
>  void __hyp_set_vectors(phys_addr_t phys_vector_base);
>  phys_addr_t __hyp_get_vectors(void);
>  
> @@ -60,6 +65,18 @@ static inline bool is_kernel_in_hyp_mode(void)
>  	return el == CurrentEL_EL2;
>  }
>  
> +static inline bool is_kernel_mode_mismatched(void)
> +{
> +	/*
> +	 * A mismatched CPU will have written its own CurrentEL in
> +	 * __run_cpu_mode[1] (initially set to zero) after failing to
> +	 * match the value in __run_cpu_mode[0]. Thus, a non-zero
> +	 * value in __run_cpu_mode[1] is enough to detect the
> +	 * pathological case.
> +	 */
> +	return !!ACCESS_ONCE(__run_cpu_mode[1]);
> +}
> +
>  /* The section containing the hypervisor text */
>  extern char __hyp_text_start[];
>  extern char __hyp_text_end[];
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 6f2f377..f9b6a5b 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -578,7 +578,24 @@ ENTRY(set_cpu_boot_mode_flag)
>  1:	str	w20, [x1]			// This CPU has booted in EL1
>  	dmb	sy
>  	dc	ivac, x1			// Invalidate potentially stale cache line
> +	adr_l	x1, __run_cpu_mode
> +	ldr	w0, [x1]
> +	mrs	x20, CurrentEL
> +	cbz	x0, skip_el_check
> +	cmp	x0, x20
> +	bne	mismatched_el
>  	ret
> +skip_el_check:			// Only the first CPU gets to set the rule
> +	str	w20, [x1]
> +	dmb	sy
> +	dc	ivac, x1	// Invalidate potentially stale cache line
> +	ret
> +mismatched_el:
> +	str	w20, [x1, #4]
> +	dmb	sy
> +	dc	ivac, x1	// Invalidate potentially stale cache line
> +1:	wfi
> +	b	1b
>  ENDPROC(set_cpu_boot_mode_flag)

Do we need to wait for the D-cache maintenance completion before
entering WFI (like issuing a DSB)? Same for the skip_el_check path
before the RET.

Otherwise:

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From andre.przywara at arm.com  Mon Feb  8 08:06:15 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 8 Feb 2016 16:06:15 +0000
Subject: [PATCH 07/11] clk: sunxi: add generic allwinner,sunxi name
In-Reply-To: <20160208155721.GB4677@rob-hp-laptop>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-8-git-send-email-andre.przywara@arm.com>
 <20160208155721.GB4677@rob-hp-laptop>
Message-ID: <56B8BCF7.4080701@arm.com>

Hi,

On 08/02/16 15:57, Rob Herring wrote:
> On Mon, Feb 01, 2016 at 05:39:26PM +0000, Andre Przywara wrote:
>> The only difference between the different compatible matches at the
>> end of clk-sunxi.c are the critical clocks. Two SoCs get away so far
>> without any, so there is no reason to enumerate those SoCs in here
>> explicitly, though we have to keep them in for compatibility reasons.
>>
>> Rename the init function to highlight this generic feature and add a
>> new, generic DT compatible string which can be used as a fallback value
>> in the future should a particular SoC don't need any special treatment.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>> ---
>>  Documentation/devicetree/bindings/arm/sunxi.txt |  4 ++++
>>  drivers/clk/sunxi/clk-sunxi.c                   | 14 ++++++--------
>>  2 files changed, 10 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
>> index 7e79fcc..980e065 100644
>> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
>> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
>> @@ -14,3 +14,7 @@ using one of the following compatible strings:
>>    allwinner,sun8i-a83t
>>    allwinner,sun8i-h3
>>    allwinner,sun9i-a80
>> +
>> +For Allwinner SoCs without any specific needs the generic fallback value of:
>> +  allwinner,sunxi
>> +can be used.
> 
> Perhaps "fallback" implies this, but be more specific that it can be 
> used in addition to a specific string.

Yeah, good point.

But Maxime's latest rework [1] made this patch here actually obsolete,
so we don't match on a root compatible string anymore to register the
sunxi clock drivers. Instead each clock is registered and matched on
it's own compatible string. Much nicer now, IMHO.

Thanks for having a look!
Andre.

[1]
https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git/commit/?h=sunxi/for-next&id=78e3fb4c745114b16a12458036d48aa96ea5b36d

>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>> index e460a6b..efcce85 100644
>> --- a/drivers/clk/sunxi/clk-sunxi.c
>> +++ b/drivers/clk/sunxi/clk-sunxi.c
>> @@ -1052,14 +1052,12 @@ CLK_OF_DECLARE(sun8i_a23_clk_init, "allwinner,sun8i-a23", sun6i_init_clocks);
>>  CLK_OF_DECLARE(sun8i_a33_clk_init, "allwinner,sun8i-a33", sun6i_init_clocks);
>>  CLK_OF_DECLARE(sun8i_h3_clk_init, "allwinner,sun8i-h3", sun6i_init_clocks);
>>  
>> -static void __init sun8i_a83t_init_clocks(struct device_node *node)
>> +static void __init sunxi_generic_init_clocks(struct device_node *node)
>>  {
>>  	sunxi_init_clocks(NULL, 0);
>>  }
>> -CLK_OF_DECLARE(sun8i_a83t_clk_init, "allwinner,sun8i-a83t", sun8i_a83t_init_clocks);
>> -
>> -static void __init sun9i_init_clocks(struct device_node *node)
>> -{
>> -	sunxi_init_clocks(NULL, 0);
>> -}
>> -CLK_OF_DECLARE(sun9i_a80_clk_init, "allwinner,sun9i-a80", sun9i_init_clocks);
>> +CLK_OF_DECLARE(sun8i_a83t_clk_init, "allwinner,sun8i-a83t",
>> +	       sunxi_generic_init_clocks);
>> +CLK_OF_DECLARE(sun9i_a80_clk_init, "allwinner,sun9i-a80",
>> +	       sunxi_generic_init_clocks);
>> +CLK_OF_DECLARE(sunxi_clk_init, "allwinner,sunxi", sunxi_generic_init_clocks);
>> -- 
>> 2.6.4
>>
> 


From tthayer at opensource.altera.com  Mon Feb  8 08:10:53 2016
From: tthayer at opensource.altera.com (Thor Thayer)
Date: Mon, 8 Feb 2016 10:10:53 -0600
Subject: [PATCHv9 1/4] EDAC, altera: Add Altera L2 Cache and OCRAM EDAC
 Support
In-Reply-To: <20160208113919.GB28980@pd.tnic>
References: <1453911203-30202-1-git-send-email-tthayer@opensource.altera.com>
 <20160208113919.GB28980@pd.tnic>
Message-ID: <56B8BE0D.8070000@opensource.altera.com>

Hi Boris.

On 02/08/2016 05:39 AM, Borislav Petkov wrote:
> On Wed, Jan 27, 2016 at 10:13:20AM -0600, tthayer at opensource.altera.com wrote:
>> From: Thor Thayer <tthayer at opensource.altera.com>
>>
>> Adding L2 Cache and On-Chip RAM EDAC support for the
>> Altera SoCs using the EDAC device  model. The SDRAM
>> controller is using the Memory Controller model.
>>
>> Each type of ECC is individually configurable.
>>
>> Signed-off-by: Thor Thayer <tthayer at opensource.altera.com>
>> ---
>> v9: Improve device tree node release. Free managed resources
>>      on error path. Fix ocram memory leak.
>> v8: Remove MASK from single bit mask names.
>>      s/altr,edac/altr,socfpga-ecc-manager
>>      Use debugfs instead of sysfs.
>>      Add chip family name to match string.
>>      Fix header year.
>>      Fix build dependencies & change commit accordingly.
>>      s/CONFIG_EDAC_ALTERA_MC/CONFIG_EDAC_ALTERA
>> v7: s/of_get_named_gen_pool/of_gen_pool_get
>>      Remove #ifdef for EDAC_DEBUG
>>      Use -ENODEV instead of EPROBE_DEFER
>> v6: Convert to nested EDAC in device tree. Force L2 cache
>>      on for L2Cache ECC & remove L2 cache syscon for checking
>>      enable bit. Update year in header.
>> v5: No change.
>> v4: Change mask defines to use BIT().
>>      Fix comment style to agree with kernel coding style.
>>      Better printk description for read != write in trigger.
>>      Remove SysFS debugging message.
>>      Better dci->mod_name
>>      Move gen_pool pointer assignment to end of function.
>>      Invert logic to reduce indent in ocram depenency check.
>>      Change from dev_err() to edac_printk()
>>      Replace magic numbers with defines & comments.
>>      Improve error injection test.
>>      Change Makefile intermediary name to altr (from alt)
>> v3: Move OCRAM and L2 cache EDAC functions into altera_edac.c
>>      instead of separate files.
>> v2: Fix L2 dependency comments.
>> ---
>>   drivers/edac/Kconfig       |   26 ++-
>>   drivers/edac/Makefile      |    2 +-
>>   drivers/edac/altera_edac.c |  487 +++++++++++++++++++++++++++++++++++++++++++-
>>   3 files changed, 507 insertions(+), 8 deletions(-)
>
> I'm still waiting for the people on CC to confirm the DT changes. A
> couple of comments on the EDAC bits below.
>
>

Understood. I did get a conditional ACK from Rob Herring on the DT 
portion of the patch from the last revision (as long as I made the 
changes he suggested which I did in this patch). There may be other 
comments though.

> ....
>
>
>> +static irqreturn_t altr_edac_device_handler(int irq, void *dev_id)
>> +{
>> +	struct edac_device_ctl_info *dci = dev_id;
>> +	struct altr_edac_device_dev *drvdata = dci->pvt_info;
>> +	const struct edac_device_prv_data *priv = drvdata->data;
>> +
>> +	if (irq == drvdata->sb_irq) {
>> +		if (priv->ce_clear_mask)
>> +			writel(priv->ce_clear_mask, drvdata->base);
>> +		edac_device_handle_ce(dci, 0, 0, drvdata->edac_dev_name);
>> +	}
>> +	if (irq == drvdata->db_irq) {
>> +		if (priv->ue_clear_mask)
>> +			writel(priv->ue_clear_mask, drvdata->base);
>> +		edac_device_handle_ue(dci, 0, 0, drvdata->edac_dev_name);
>> +		panic("\nEDAC:ECC_DEVICE[Uncorrectable errors]\n");
>> +	}
>
> And irq is guaranteed to always be ->sb_irq or ->db_irq?
>
> Otherwise, you can do
>
> 	else
> 		WARN_ON(1);
>
> just in case.

Those are the only cases of irq but it would be good to be alerted if 
that is not the case. I will add. Thanks!

>
>> +
>> +	return IRQ_HANDLED;
>> +}
>
> ...
>
>> +/*
>> + * altr_edac_device_probe()
>> + *	This is a generic EDAC device driver that will support
>> + *	various Altera memory devices such as the L2 cache ECC and
>> + *	OCRAM ECC as well as the memories for other peripherals.
>> + *	Module specific initialization is done by passing the
>> + *	function index in the device tree.
>> + */
>> +static int altr_edac_device_probe(struct platform_device *pdev)
>> +{

<snip>

>> +
>> +	dci->mod_name = "Altera ECC Manager";
>> +	dci->dev_name = drvdata->edac_dev_name;
>> +
>> +	debugfs = edac_debugfs_create_dir(ecc_name);
>> +	if (debugfs)
>> +		altr_create_edacdev_dbgfs(dci, drvdata->data, debugfs);
>> +
>> +	if (edac_device_add_device(dci))
>
> <--- if you end up here and debugfs nodes have been created, you need to
> destroy them here. You probably could change edac_debugfs_exit() to call
> debugfs_remove_recursive() and make sure your driver calls it.
>
> Right now we're calling edac_debugfs_exit() in edac_exit() and I *think*
> that is ok for a platform device driver as this one but I haven't
> actually *verified* that.

Yes, thanks. I was using the xgene code as an example but I missed the 
unregister (although it looks like the xgene's unregister affects sysfs 
instead of debugfs). I'm also moving the debugfs creation to the end of 
the probe since it is not critical and avoids an error path if creation 
fails.

I'll make the debugfs_remove_recursive() change as a separate patch in 
my next version.

>
>> +		goto fail1;
>> +
>> +	devres_close_group(&pdev->dev, NULL);

<snip>

>> +
>> +	memset(sram_addr, 0, size);
>> +	wmb();	/* Ensure data is written out */
>> +
>> +	*other = gp;	/* Remember this handle for freeing  later */
>
> Please put comments ontop of the line they're referring to. Those
> side-things are cluttering the code unnecessarily.
>
OK.

>> +
>> +	return sram_addr;
>> +}
>> +
>> +static void ocram_free_mem(void *p, size_t size, void *other)
>> +{
>> +	gen_pool_free((struct gen_pool *)other, (u32)p, size);
>> +}
>> +
>> +/*
>> + * altr_ocram_dependencies()
>> + *	Test for OCRAM cache ECC dependencies upon entry because
>> + *	platform specific startup should have initialized the
>> + *	On-Chip RAM memory and enabled the ECC.
>> + *	Can't turn on ECC here because accessing un-initialized
>> + *	memory will cause CE/UE errors possibly causing an ABORT.
>> + */
>> +static int altr_ocram_dependencies(struct platform_device *pdev,
>
> A verb in the name?
>
> 	altr_ocram_test_deps
>
> or
> 	altr_ocram_check_deps
>
> or so?
>

OK. Thanks.

>> +				   void __iomem *base)
>> +{
>> +	u32 control;
>> +

<snip>


>> + *	Note that L2 Cache Enable is forced at build time.
>> + */
>> +static int altr_l2_dependencies(struct platform_device *pdev,
>
> Here too, pls add a verb in the function name.
>
OK. Thanks.

>> +				void __iomem *base)
>> +{
>> +	u32 control;
>> +
>> +	control = readl(base) & ALTR_L2_ECC_EN;
>> +	if (!control) {
>> +		edac_printk(KERN_ERR, EDAC_DEVICE,
>> +			    "L2: No ECC present, or ECC disabled\n");
>> +		return -ENODEV;
>> +	}
>> +
>> +	return 0;
>> +}
>

Thanks for reviewing!


From gabriele.paoloni at huawei.com  Mon Feb  8 08:06:54 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Mon, 8 Feb 2016 16:06:54 +0000
Subject: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06
 controllers driver to preapare for ACPI
In-Reply-To: <2409806.1aGBrN4l0X@wuerfel>
References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
 <1454935264-6076-2-git-send-email-gabriele.paoloni@huawei.com>
 <2409806.1aGBrN4l0X@wuerfel>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECACFDD@lhreml503-mbs>

Hi Arnd

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 08 February 2016 13:50
> To: linux-arm-kernel at lists.infradead.org
> Cc: Gabriele Paoloni; Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong
> (C); Linuxarm; qiujiang; bhelgaas at google.com;
> Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-pci at vger.kernel.org;
> linux-kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth)
> Subject: Re: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06
> controllers driver to preapare for ACPI
> 
> On Monday 08 February 2016 12:41:02 Gabriele Paoloni wrote:
> > +
> > +/* HipXX PCIe host only supports 32-bit config access */
> > +int hisi_pcie_common_cfg_read(void __iomem *reg_base, int where, int
> size,
> > +			      u32 *val)
> > +{
> > +	u32 reg;
> > +	u32 reg_val;
> > +	void *walker = &reg_val;
> > +
> > +	walker += (where & 0x3);
> > +	reg = where & ~0x3;
> > +	reg_val = readl(reg_base + reg);
> > +
> > +	if (size == 1)
> > +		*val = *(u8 __force *) walker;
> > +	else if (size == 2)
> > +		*val = *(u16 __force *) walker;
> > +	else if (size == 4)
> > +		*val = reg_val;
> > +	else
> > +		return PCIBIOS_BAD_REGISTER_NUMBER;
> > +
> > +	return PCIBIOS_SUCCESSFUL;
> > +}
> 
> Isn't this the same hack that Qualcomm are using?

As far as I can see Qualcomm defines its own config access
mechanism only for RC config read and also it seems they're
having problems with reporting the device class...

https://github.com/torvalds/linux/blob/master/drivers/pci/host/pcie-qcom.c#L474

Our problem is that our HW can only perform 32b rd/wr accesses
So we can't use readw/readb/writew/writeb...

Thanks

Gab

> 
> 	Arnd


From gregory.clement at free-electrons.com  Mon Feb  8 08:09:38 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 08 Feb 2016 17:09:38 +0100
Subject: [PATCH v2 0/3] fix and new support for orion5x based linkstation
In-Reply-To: <87lh6v19p4.fsf@free-electrons.com> (Gregory CLEMENT's message of
 "Mon, 08 Feb 2016 16:52:07 +0100")
References: <1454689998-9579-1-git-send-email-rogershimizu@gmail.com>
 <1454738393-14114-1-git-send-email-rogershimizu@gmail.com>
 <87lh6v19p4.fsf@free-electrons.com>
Message-ID: <87d1s718vx.fsf@free-electrons.com>

Hi,
 
 On lun., f?vr. 08 2016, Gregory CLEMENT <gregory.clement at free-electrons.com> wrote:

> Hi Roger,
>  
>  On sam., f?vr. 06 2016, Roger Shimizu <rogershimizu at gmail.com> wrote:
>
>> Dear Orion5x Maintainer,
>>
>> Here're fix and new support for orion5x based linkstation devices.
>>
>> Firstly, it add the missing mtd flash support, which I consider a fix
>> and can be backported to stable kernels, so I made the patch explicit.
>>
>> Second, like the changes I made for kirkwood based linkstation DT,
>> I split the orion5x-linkstation-lswtgl.dts file into common and device
>> specific part, in order to support more devices.
>>
>> Third, so there's a new device.
>>
>> Hope this can be kindly accepted. Thank you!
>>
>> Changes in v2:
>> - add "Fixes" tag for patch 1/3
>> - add "mvebu-" prefix to common .dtsi file to share between orion5x
>>   and kirkwood, which address comment from Andrew Lunn
>> - add "Reviewed-by" tag from Andrew Lunn for all 3 patches
>>
>> Cheers,
>> Roger
>>
>> Roger Shimizu (3):
>>   ARM: dts: orion5x: fix the missing mtd flash on linkstation lswtgl
>>   ARM: dts: orion5x: split linkstation lswtgl into common and device
>>     parts
>>   ARM: dts: orion5x: add device tree for buffalo linkstation ls-gl
>
>
> The 3 patches have been applied on mvebu/dt

Humm, finally I moved the first patch to mvebu/fixes

Gregory

>
> Thanks,
>
> Gregory
>
>
>>
>>  arch/arm/boot/dts/Makefile                         |   1 +
>>  arch/arm/boot/dts/mvebu-linkstation-fan.dtsi       |  72 +++++++
>>  .../boot/dts/mvebu-linkstation-gpio-simple.dtsi    | 105 ++++++++++
>>  arch/arm/boot/dts/orion5x-linkstation-lsgl.dts     |  87 +++++++++
>>  arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts   | 214 +++++----------------
>>  arch/arm/boot/dts/orion5x-linkstation.dtsi         | 180 +++++++++++++++++
>>  6 files changed, 491 insertions(+), 168 deletions(-)
>>  create mode 100644 arch/arm/boot/dts/mvebu-linkstation-fan.dtsi
>>  create mode 100644 arch/arm/boot/dts/mvebu-linkstation-gpio-simple.dtsi
>>  create mode 100644 arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
>>  create mode 100644 arch/arm/boot/dts/orion5x-linkstation.dtsi
>>
>> -- 
>> 2.1.4
>>
>
> -- 
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From codekipper at gmail.com  Mon Feb  8 08:10:19 2016
From: codekipper at gmail.com (Code Kipper)
Date: Mon, 8 Feb 2016 17:10:19 +0100
Subject: [linux-sunxi][PATCH] ARM: dts: sun7i: Enable USB DRC on Olimex
 A20 EVB
In-Reply-To: <56B8B7A1.5020800@redhat.com>
References: <1454945387-29424-1-git-send-email-codekipper@gmail.com>
 <56B8B7A1.5020800@redhat.com>
Message-ID: <CAEKpxBnkFgfaK43f0EKQnxmCVq9Kh-_MBWSa68ZCmcRdk=ZdJA@mail.gmail.com>

On 8 February 2016 at 16:43, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
> On 08-02-16 16:29, codekipper at gmail.com wrote:
>>
>> From: Marcus Cooper <codekipper at gmail.com>
>>
>> Enable the otg/drc usb controller on the Olimex A20 EVB.
>
>
> Does the A20 EVB not have some form of Vbus detect for the OTG
> port hooked up ? That does not sound right. Please double check.
Yeah...looks like it does...PH5. I'll add that and test.
CK
>
> Regards,
>
> Hans
>
>
>
>>
>> Signed-off-by: Marcus Cooper <codekipper at gmail.com>
>> ---
>>   arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 24
>> ++++++++++++++++++++++++
>>   1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
>> b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
>> index c3c626b..93bbf26 100644
>> --- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
>> +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
>> @@ -198,6 +198,10 @@
>>         status = "okay";
>>   };
>>
>> +&otg_sram {
>> +       status = "okay";
>> +};
>> +
>>   &pio {
>>         ahci_pwr_pin_olimex_som_evb: ahci_pwr_pin at 1 {
>>                 allwinner,pins = "PC3";
>> @@ -219,6 +223,13 @@
>>                 allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>                 allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>>         };
>> +
>> +       usb0_id_detect_pin: usb0_id_detect_pin at 0 {
>> +               allwinner,pins = "PH4";
>> +               allwinner,function = "gpio_in";
>> +               allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +               allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +       };
>>   };
>>
>>   &reg_ahci_5v {
>> @@ -254,6 +265,10 @@
>>         regulator-name = "avcc";
>>   };
>>
>> +&reg_usb0_vbus {
>> +       status = "okay";
>> +};
>> +
>>   &reg_usb1_vbus {
>>         status = "okay";
>>   };
>> @@ -268,7 +283,16 @@
>>         status = "okay";
>>   };
>>
>> +&usb_otg {
>> +       dr_mode = "otg";
>> +       status = "okay";
>> +};
>> +
>>   &usbphy {
>> +       pinctrl-names = "default";
>> +       pinctrl-0 = <&usb0_id_detect_pin>;
>> +       usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH04 */
>> +       usb0_vbus-supply = <&reg_usb0_vbus>;
>>         usb1_vbus-supply = <&reg_usb1_vbus>;
>>         usb2_vbus-supply = <&reg_usb2_vbus>;
>>         status = "okay";
>>
>


From robh at kernel.org  Mon Feb  8 08:11:31 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 10:11:31 -0600
Subject: [PATCH 1/3] ARM: keystone: Create new binding for K2G SoC
In-Reply-To: <1454455517-7360-2-git-send-email-fcooper@ti.com>
References: <1454455517-7360-1-git-send-email-fcooper@ti.com>
 <1454455517-7360-2-git-send-email-fcooper@ti.com>
Message-ID: <20160208161131.GA20324@rob-hp-laptop>

On Tue, Feb 02, 2016 at 05:25:15PM -0600, Franklin S Cooper Jr wrote:
> From: Nishanth Menon <nm at ti.com>
> 
> K2G SoC family is the newest version of the Keystone family of processors.
> 
> The technical reference manual for K2G can be found here:
> http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf
> 
> Add new bindings for K2G and the K2G evm. Also document these new bindings.
> 
> Signed-off-by: Nishanth Menon <nm at ti.com>
> Signed-off-by: Franklin S Cooper Jr <fcooper at ti.com>
> ---
>  Documentation/devicetree/bindings/arm/keystone/keystone.txt | 5 +++++
>  arch/arm/mach-keystone/keystone.c                           | 1 +
>  2 files changed, 6 insertions(+)

Acked-by: Rob Herring <robh at kernel.org>


From hdegoede at redhat.com  Mon Feb  8 08:14:15 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Mon, 8 Feb 2016 17:14:15 +0100
Subject: [linux-sunxi][PATCH] ARM: dts: sun7i: Enable USB DRC on Itead Ibox
In-Reply-To: <1454947167-12236-1-git-send-email-codekipper@gmail.com>
References: <1454947167-12236-1-git-send-email-codekipper@gmail.com>
Message-ID: <56B8BED7.9030704@redhat.com>

Hi,

On 08-02-16 16:59, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
>
> Enable the otg/drc usb controller on the Itead Ibox device.
>
> Signed-off-by: Marcus Cooper <codekipper at gmail.com>

Same remark as with your Olimex A20 EVB board patch, please
also provide a vbus detect pin setting. If for some reason the
VBus detect is not wired up, or not working properly, please mention
this explicitly in the commit message.

Note that in some cases the axp209 is used for vbus detect,
rather then a gpio, see e.g. :

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/sun7i-a20-bananapi.dts?id=dcfd8443d89f593e0c667a988ab017e716b33061

Regards,

Hans



> ---
>   arch/arm/boot/dts/sun7i-a20-itead-ibox.dts     | 14 ++++++++++++++
>   arch/arm/boot/dts/sunxi-itead-core-common.dtsi |  9 +++++++++
>   2 files changed, 23 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
> index 661c21d..a512581 100644
> --- a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
> @@ -118,8 +118,22 @@
>   		allwinner,drive = <SUN4I_PINCTRL_20_MA>;
>   		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>   	};
> +
> +	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
> +		allwinner,pins = "PH4";
> +		allwinner,function = "gpio_in";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +	};
>   };
>
>   &reg_ahci_5v {
>   	status = "okay";
>   };
> +
> +&usbphy {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&usb0_id_detect_pin>;
> +	usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
> +	status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
> index 2565d51..d22eea3 100644
> --- a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
> +++ b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
> @@ -88,6 +88,10 @@
>   	status = "okay";
>   };
>
> +&otg_sram {
> +	status = "okay";
> +};
> +
>   #include "axp209.dtsi"
>
>   &reg_dcdc2 {
> @@ -129,6 +133,11 @@
>   	status = "okay";
>   };
>
> +&usb_otg {
> +	dr_mode = "otg";
> +	status = "okay";
> +};
> +
>   &usbphy {
>   	usb1_vbus-supply = <&reg_usb1_vbus>;
>   	usb2_vbus-supply = <&reg_usb2_vbus>;
>


From bp at alien8.de  Mon Feb  8 08:16:27 2016
From: bp at alien8.de (Borislav Petkov)
Date: Mon, 8 Feb 2016 17:16:27 +0100
Subject: [PATCHv9 1/4] EDAC, altera: Add Altera L2 Cache and OCRAM EDAC
 Support
In-Reply-To: <56B8BE0D.8070000@opensource.altera.com>
References: <1453911203-30202-1-git-send-email-tthayer@opensource.altera.com>
 <20160208113919.GB28980@pd.tnic>
 <56B8BE0D.8070000@opensource.altera.com>
Message-ID: <20160208161627.GH28980@pd.tnic>

On Mon, Feb 08, 2016 at 10:10:53AM -0600, Thor Thayer wrote:
> Understood. I did get a conditional ACK from Rob Herring on the DT portion
> of the patch from the last revision (as long as I made the changes he
> suggested which I did in this patch). There may be other comments though.

Ah, and I wasn't precise: there are also arch/arm/mach-socfpga/ changes
which I'm going to take through the EDAC tree *only* if ARM people ack
them.

And by "ARM people" and from looking at get_maintainer output I mean
Dinh and he's on CC ...

> Those are the only cases of irq but it would be good to be alerted if that
> is not the case. I will add. Thanks!

Yeah, it is a "just in case" thing - it might just as well be too
cautious and completely unnecessary so your decision.

> Yes, thanks. I was using the xgene code as an example but I missed the
> unregister (although it looks like the xgene's unregister affects sysfs
> instead of debugfs). I'm also moving the debugfs creation to the end of the
> probe since it is not critical and avoids an error path if creation fails.
> 
> I'll make the debugfs_remove_recursive() change as a separate patch in my
> next version.

Good, thanks!

Also, if something's not right in drivers/edac/debugfs.c wrt usability
and so on, feel free to propose changes. I've extracted it there because
I didn't want every driver to reinvent the wheel.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.


From jeremy.linton at arm.com  Mon Feb  8 08:17:09 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Mon, 8 Feb 2016 10:17:09 -0600
Subject: [RFC PATCH 0/3] arm64 initrd mapping/relocation
In-Reply-To: <CAKv+Gu__xLKxwAXXf=C3VxpLizjP3oADYyk0bQzQT1G-gTxFqQ@mail.gmail.com>
References: <1454435802-7604-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160202180622.GP10166@arm.com> <1454509367.4108.3.camel@redhat.com>
 <CAKv+Gu__xLKxwAXXf=C3VxpLizjP3oADYyk0bQzQT1G-gTxFqQ@mail.gmail.com>
Message-ID: <56B8BF85.2060407@arm.com>

On 02/03/2016 08:26 AM, Ard Biesheuvel wrote:
> On 3 February 2016 at 15:22, Mark Salter <msalter at redhat.com> wrote:
>> On Tue, 2016-02-02 at 18:06 +0000, Will Deacon wrote:
>>> On Tue, Feb 02, 2016 at 06:56:39PM +0100, Ard Biesheuvel wrote:
>>>> After discussing in linux-efi with Mark, and on #armlinux with Will, this is
>>>> a proposal for dealing with initrd memory that is potentially not covered by
>>>> the linear region.
>>>>
>>>> Note that this will look slightly differently when some of the KASLR work gets
>>>> merged, but this should only affect the way we deal with the initrd if it sits
>>>> outside of the linear region.
>>>>
>>>> Mostly intended for discussion, not tested at all.
>>>
>>> Thanks Ard, this looks like a much better approach to me. Mark -- does
>>> the general idea work for you too?
>>>
>>> Will
>>
>> Yeah, much simpler. I like it in concept but am I missing something or is it
>> adding memory to the system beyond the mem= limit?
>
> Indeed. I think it is reasonable to require that if you pass both mem=
> and initrd= *and* you need your memory limit to be honored strictly,
> it is up to you to ensure that the initrd does not live in the memory
> you are throwing away.
>
>> But even that may not be
>> a big deal. And I need to look at the KASLR work and understand the issues
>> with it and mem= if any. I'm traveling right now and can't really try it out
>> until tomorrow...
>>
>
> No worries. My estimation is that Will is not going to take this as a
> fix anyway, so we have plenty of time to test and/or discuss


I needed these patches to successfully boot a JunoR2 with a recent 
tianocore firmware.

Thanks,





From catalin.marinas at arm.com  Mon Feb  8 08:19:19 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 8 Feb 2016 16:19:19 +0000
Subject: [PATCH v5sub2 0/8] arm64: implement virtual KASLR
In-Reply-To: <CAKv+Gu-=RLS8Zgn_evmoUUSHqSVfaw9_hjVMgfg1FZGRDGFVag@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <CAKv+Gu-AhLcatkDsQVeoFGJ+pTEwaW1Hy9M-fY1-VWvRc_E47w@mail.gmail.com>
 <20160205173248.GJ6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_v1sXM7sivz+Uu86ZG3=Th7wqqh7M1N8wF7Ess4NdTZQ@mail.gmail.com>
 <CAGXu5j+JpwRrVy1b_h+LJ4sCzsT7BV9RdcD0CvR-4aVJQhCpvg@mail.gmail.com>
 <20160208121430.GL6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-=RLS8Zgn_evmoUUSHqSVfaw9_hjVMgfg1FZGRDGFVag@mail.gmail.com>
Message-ID: <20160208161918.GT6076@e104818-lin.cambridge.arm.com>

On Mon, Feb 08, 2016 at 03:30:47PM +0100, Ard Biesheuvel wrote:
> On 8 February 2016 at 13:14, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Fri, Feb 05, 2016 at 12:42:30PM -0800, Kees Cook wrote:
> >> On Fri, Feb 5, 2016 at 9:38 AM, Ard Biesheuvel
> >> <ard.biesheuvel at linaro.org> wrote:
> >> > On 5 February 2016 at 18:32, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> >> I'm still trying to get my head around how we merge those. Since I
> >> >> assume akpm will push them during the merging window, part of your code
> >> >> cannot be tested before.
> >> >
> >> > Actually, my original idea was for akpm to take them as a late merge
> >> > after rebasing to -rc1, since they touch a variety of architectures,
> >> > but I am not sure if that came across.
> >> >
> >> > You could always take the series through your tree instead, I guess?
> >>
> >> Traditionally akpm will de-duplicate patches he's carrying that appear
> >> in another tree. I think it should be okay to carry them in both
> >> places. (Though I'm CCing akpm just to see if I'm talking crazy.)
> >
> > For now, I'll merge this series in the arm64 tree and push it to next:
> >
> > http://lkml.kernel.org/r/1452007180-27411-1-git-send-email-ard.biesheuvel at linaro.org
> >
> > If there are any objections, I can drop the patches and do the
> > BUILDTIME_EXTABLE_SORT disabling trick until they end up in mainline.
> 
> Latest version is here:
> http://lkml.kernel.org/r/1453892123-17973-1-git-send-email-ard.biesheuvel at linaro.org
> (only difference is an ack from that Alpha maintainter/supporter to
> patches #1 and #2)

I applied the acks manually but I'll double-check to make sure I haven't
missed anything.

> However, the arm64 patch (#6) now conflicts with futex.h in -rc3 after
> the PAN fix, not sure how to best address that ...

I'll have a look.

-- 
Catalin


From ard.biesheuvel at linaro.org  Mon Feb  8 08:20:41 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 8 Feb 2016 17:20:41 +0100
Subject: [PATCH v5sub2 0/8] arm64: implement virtual KASLR
In-Reply-To: <20160208161918.GT6076@e104818-lin.cambridge.arm.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <CAKv+Gu-AhLcatkDsQVeoFGJ+pTEwaW1Hy9M-fY1-VWvRc_E47w@mail.gmail.com>
 <20160205173248.GJ6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_v1sXM7sivz+Uu86ZG3=Th7wqqh7M1N8wF7Ess4NdTZQ@mail.gmail.com>
 <CAGXu5j+JpwRrVy1b_h+LJ4sCzsT7BV9RdcD0CvR-4aVJQhCpvg@mail.gmail.com>
 <20160208121430.GL6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-=RLS8Zgn_evmoUUSHqSVfaw9_hjVMgfg1FZGRDGFVag@mail.gmail.com>
 <20160208161918.GT6076@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu9RmhaYBHOKwsPNynJ4Zia2kSJ6Yr3U4c6F13UHdbzFtw@mail.gmail.com>

On 8 February 2016 at 17:19, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 08, 2016 at 03:30:47PM +0100, Ard Biesheuvel wrote:
>> On 8 February 2016 at 13:14, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > On Fri, Feb 05, 2016 at 12:42:30PM -0800, Kees Cook wrote:
>> >> On Fri, Feb 5, 2016 at 9:38 AM, Ard Biesheuvel
>> >> <ard.biesheuvel at linaro.org> wrote:
>> >> > On 5 February 2016 at 18:32, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> >> >> I'm still trying to get my head around how we merge those. Since I
>> >> >> assume akpm will push them during the merging window, part of your code
>> >> >> cannot be tested before.
>> >> >
>> >> > Actually, my original idea was for akpm to take them as a late merge
>> >> > after rebasing to -rc1, since they touch a variety of architectures,
>> >> > but I am not sure if that came across.
>> >> >
>> >> > You could always take the series through your tree instead, I guess?
>> >>
>> >> Traditionally akpm will de-duplicate patches he's carrying that appear
>> >> in another tree. I think it should be okay to carry them in both
>> >> places. (Though I'm CCing akpm just to see if I'm talking crazy.)
>> >
>> > For now, I'll merge this series in the arm64 tree and push it to next:
>> >
>> > http://lkml.kernel.org/r/1452007180-27411-1-git-send-email-ard.biesheuvel at linaro.org
>> >
>> > If there are any objections, I can drop the patches and do the
>> > BUILDTIME_EXTABLE_SORT disabling trick until they end up in mainline.
>>
>> Latest version is here:
>> http://lkml.kernel.org/r/1453892123-17973-1-git-send-email-ard.biesheuvel at linaro.org
>> (only difference is an ack from that Alpha maintainter/supporter to
>> patches #1 and #2)
>
> I applied the acks manually but I'll double-check to make sure I haven't
> missed anything.
>
>> However, the arm64 patch (#6) now conflicts with futex.h in -rc3 after
>> the PAN fix, not sure how to best address that ...
>
> I'll have a look.
>

Note that the fix is trivial, but I don't know who should be carrying
the fix is all


From gabriele.paoloni at huawei.com  Mon Feb  8 08:20:55 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Mon, 8 Feb 2016 16:20:55 +0000
Subject: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host
 Controllers
In-Reply-To: <56B8A214.8040203@codeaurora.org>
References: <1454585860-60709-1-git-send-email-gabriele.paoloni@huawei.com>
 <1930535.mkCdtpUWq7@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECAC944@lhreml503-mbs>
 <7297343.ktGck3KQJN@wuerfel> <56B8A214.8040203@codeaurora.org>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECAD0C2@lhreml503-mbs>

Hi Arnd, Sinan

> -----Original Message-----
> From: Sinan Kaya [mailto:okaya at codeaurora.org]
> Sent: 08 February 2016 14:12
> To: Arnd Bergmann; linux-arm-kernel at lists.infradead.org
> Cc: Gabriele Paoloni; Lorenzo.Pieralisi at arm.com; jcm at redhat.com;
> tn at semihalf.com; linux-pci at vger.kernel.org; Linuxarm; xuwei (O); linux-
> kernel at vger.kernel.org; linux-acpi at vger.kernel.org; Wangzhou (B);
> liudongdong (C); Guohanjun (Hanjun Guo); bhelgaas at google.com;
> zhangjukuo; Liguozhu (Kenneth); qiujiang
> Subject: Re: [RFC PATCH 0/4] Add ACPI support for HiSilicon PCIe Host
> Controllers
> 
> On 2/8/2016 8:55 AM, Arnd Bergmann wrote:
> > I haven't really followed what is going on with ACPI. Do you expect
> > to see future machines come out that are not just implementing SBSA
> > but that still need to run ACPI? I thought this was just a hack
> > for some early machines that only run with ACPI but are not actually
> > compliant.

Well from our side (HiSilicon) we're trying to move away from non fully 
ECAM platforms, so from us in the long term I don't expect too many quirks,
but I don't know about the other vendors.

Obviously the reason why Tomasz implemented the quirks is to fit non 
fully ECAM HW and to allow custom HW init; this is why I thought better
to have the ACPI version in the same dir as the DT (maybe we can create 
an ACPI sub-dir in drivers/pci/host ?)


> >
> > 	Arnd
> 
> I agree. We shouldn't be playing with half-baked ACPI solutions. We
> have seen
> two variants already that claim to be ACPI compliant yet they do not
> tie into
> anything inside ACPICA.
> 
> The correct route is to use Tomasz's ACPI PCI root bridge driver and
> use the ACPI
> framework.
> 
> If a platform has quirks, Tomasz's patches allow vendors add quirks
> too.
> 
> The combination of PCI host bridge driver + ACPI hack is not right.

If you look at my patchset  you can see that I didn't do any hack,

I just used the framework provided by Tomasz patchset.

The discussion here is more about the code location for the quirks.
Since the configuration read/write and the HW init sequences can be
similar between the ACPI variant and DT variant I thought it make 
sense to have them in "drivers/pci/host"

Thanks

Gab

> 
> --
> Sinan Kaya
> Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center,
> Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project


From broonie at kernel.org  Mon Feb  8 08:22:44 2016
From: broonie at kernel.org (Mark Brown)
Date: Mon, 8 Feb 2016 16:22:44 +0000
Subject: [PATCH 07/11] ARM: dts: sunxi: Add dtsi file for AXP809 PMIC
In-Reply-To: <CAGb2v64ySLAVbPf_XaZnzm5T=SmQLip4iO2p4cGXg=C0=51eqA@mail.gmail.com>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-8-git-send-email-wens@csie.org>
 <20160202121733.GO4455@sirena.org.uk>
 <CAGb2v657zYT30KbuK0fyVOmhv0kzJjj9gTsTFRaS4i3d6YhiHQ@mail.gmail.com>
 <20160208145347.GD7265@sirena.org.uk>
 <CAGb2v64ySLAVbPf_XaZnzm5T=SmQLip4iO2p4cGXg=C0=51eqA@mail.gmail.com>
Message-ID: <20160208162244.GG7265@sirena.org.uk>

On Mon, Feb 08, 2016 at 10:56:05PM +0800, Chen-Yu Tsai wrote:
> On Mon, Feb 8, 2016 at 10:53 PM, Mark Brown <broonie at kernel.org> wrote:
> > On Sat, Feb 06, 2016 at 08:42:24PM +0800, Chen-Yu Tsai wrote:

> >> Mark, may I assume you are OK with this DTS include listing
> >> the regulators, even if their sections are empty?

> > If it has no content why have it?

> I'd like the regulator core to disable any unused ones. The core
> considers regulators that don't have nodes as not having constraints,
> and won't touch them.

> Any other ways to do this? Or am I going about this the wrong way?

The whole point with constraints is that they describe what is safe on a
given board.  This includes powering off unused regulators - it should
be something that the system integrator configures, not something that
they get as default.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160208/3ee8675a/attachment.sig>

From mark.rutland at arm.com  Mon Feb  8 08:24:03 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 8 Feb 2016 16:24:03 +0000
Subject: [PATCH v3 23/23] arm64: Panic when VHE and non VHE CPUs coexist
In-Reply-To: <20160208160445.GS6076@e104818-lin.cambridge.arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-24-git-send-email-marc.zyngier@arm.com>
 <20160208160445.GS6076@e104818-lin.cambridge.arm.com>
Message-ID: <20160208162402.GC14146@leverpostej>

On Mon, Feb 08, 2016 at 04:04:46PM +0000, Catalin Marinas wrote:
> On Wed, Feb 03, 2016 at 06:00:16PM +0000, Marc Zyngier wrote:
> > Having both VHE and non-VHE capable CPUs in the same system
> > is likely to be a recipe for disaster.
> > 
> > If the boot CPU has VHE, but a secondary is not, we won't be
> > able to downgrade and run the kernel at EL1. Add CPU hotplug
> > to the mix, and this produces a terrifying mess.
> > 
> > Let's solve the problem once and for all. If you mix VHE and
> > non-VHE CPUs in the same system, you deserve to loose, and this
> > patch makes sure you don't get a chance.
> > 
> > This is implemented by storing the kernel execution level in
> > a global variable. Secondaries will park themselves in a
> > WFI loop if they observe a mismatch. Also, the primary CPU
> > will detect that the secondary CPU has died on a mismatched
> > execution level. Panic will follow.
> > 
> > Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> > ---
> >  arch/arm64/include/asm/virt.h | 17 +++++++++++++++++
> >  arch/arm64/kernel/head.S      | 20 ++++++++++++++++++++
> >  arch/arm64/kernel/smp.c       |  3 +++
> >  3 files changed, 40 insertions(+)
> > 
> > diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
> > index 9f22dd6..f81a345 100644
> > --- a/arch/arm64/include/asm/virt.h
> > +++ b/arch/arm64/include/asm/virt.h
> > @@ -36,6 +36,11 @@
> >   */
> >  extern u32 __boot_cpu_mode[2];
> >  
> > +/*
> > + * __run_cpu_mode records the mode the boot CPU uses for the kernel.
> > + */
> > +extern u32 __run_cpu_mode[2];
> > +
> >  void __hyp_set_vectors(phys_addr_t phys_vector_base);
> >  phys_addr_t __hyp_get_vectors(void);
> >  
> > @@ -60,6 +65,18 @@ static inline bool is_kernel_in_hyp_mode(void)
> >  	return el == CurrentEL_EL2;
> >  }
> >  
> > +static inline bool is_kernel_mode_mismatched(void)
> > +{
> > +	/*
> > +	 * A mismatched CPU will have written its own CurrentEL in
> > +	 * __run_cpu_mode[1] (initially set to zero) after failing to
> > +	 * match the value in __run_cpu_mode[0]. Thus, a non-zero
> > +	 * value in __run_cpu_mode[1] is enough to detect the
> > +	 * pathological case.
> > +	 */
> > +	return !!ACCESS_ONCE(__run_cpu_mode[1]);
> > +}
> > +
> >  /* The section containing the hypervisor text */
> >  extern char __hyp_text_start[];
> >  extern char __hyp_text_end[];
> > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > index 6f2f377..f9b6a5b 100644
> > --- a/arch/arm64/kernel/head.S
> > +++ b/arch/arm64/kernel/head.S
> > @@ -578,7 +578,24 @@ ENTRY(set_cpu_boot_mode_flag)
> >  1:	str	w20, [x1]			// This CPU has booted in EL1
> >  	dmb	sy
> >  	dc	ivac, x1			// Invalidate potentially stale cache line
> > +	adr_l	x1, __run_cpu_mode
> > +	ldr	w0, [x1]
> > +	mrs	x20, CurrentEL
> > +	cbz	x0, skip_el_check
> > +	cmp	x0, x20
> > +	bne	mismatched_el
> >  	ret
> > +skip_el_check:			// Only the first CPU gets to set the rule
> > +	str	w20, [x1]
> > +	dmb	sy
> > +	dc	ivac, x1	// Invalidate potentially stale cache line
> > +	ret
> > +mismatched_el:
> > +	str	w20, [x1, #4]
> > +	dmb	sy
> > +	dc	ivac, x1	// Invalidate potentially stale cache line
> > +1:	wfi
> > +	b	1b
> >  ENDPROC(set_cpu_boot_mode_flag)
> 
> Do we need to wait for the D-cache maintenance completion before
> entering WFI (like issuing a DSB)? Same for the skip_el_check path
> before the RET.

We would need that to complete the maintenance, yes.

However, given we're going into WFI immediately afterwards, and not
signalling completion to other CPUs, what we gain is somewhat
questionable.

Perhaps it's always better to do the maintenance on the read side (for
consistency with [1]).

Regardless, we'd probably want a DSB to ensure the write had
completed...

Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/404661.html


From chauveau.julien at gmail.com  Mon Feb  8 08:26:04 2016
From: chauveau.julien at gmail.com (Julien Chauveau)
Date: Mon, 8 Feb 2016 17:26:04 +0100
Subject: [PATCH v2 07/10] ARM64: dts: rockchip: Add power key to GeekBox
In-Reply-To: <1454897859-7601-8-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
 <1454897859-7601-8-git-send-email-afaerber@suse.de>
Message-ID: <99011D31-E0AE-4F02-B769-E10617EA4F01@gmail.com>

Hello Andreas,

> Le 8 f?vr. 2016 ? 03:17, Andreas F?rber <afaerber at suse.de> a ?crit :
> 
> Signed-off-by: Andreas F?rber <afaerber at suse.de>
> ---
> v2: New
> 
> arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
> index e84383fd6f10..fe5aa785cfda 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
> @@ -70,6 +70,22 @@
> 		pinctrl-0 = <&ir_int>;
> 	};
> 
> +	keys: gpio-keys {
> +		compatible = "gpio-keys";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pwr_key>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;

I think #address-cells and #size-cells are not necessary.

> +
> +		button at 0 {
> +			reg = <0>;

reg can be removed too.

> +			gpio-key,wakeup = <1>;

You should use the new "wakeup-source ? property.

> +			gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
> +			label = "GPIO Power";
> +			linux,code = <116>;

#include <dt-bindings/input/input.h>
and use KEY_POWER instead of 116

> +		};
> +	};
> +
> 	leds: gpio-leds {
> 		compatible = "gpio-leds";
> 
> @@ -265,6 +281,12 @@
> 		};
> 	};
> 
> +	keys {
> +		pwr_key: pwr-key {
> +			rockchip,pins = <0 2 RK_FUNC_GPIO &pcfg_pull_up>;

Is there a reason you want to enable the internal pull-up resistor on this pin?

The schematic shows there's already an external pull-up resistor so the internal one should not be needed.


> +		};
> +	};
> +
> 	pmic {
> 		pmic_sleep: pmic-sleep {
> 			rockchip,pins = <0 0 RK_FUNC_2 &pcfg_pull_none>;



From gregory.clement at free-electrons.com  Mon Feb  8 08:31:20 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 08 Feb 2016 17:31:20 +0100
Subject: [PATCH] ARM: mvebu: add missing of_node_put()
In-Reply-To: <1454912232-13169-1-git-send-email-yamada.masahiro@socionext.com>
 (Masahiro Yamada's message of "Mon, 8 Feb 2016 15:17:12 +0900")
References: <1454912232-13169-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <8760xz17vr.fsf@free-electrons.com>

Hi Masahiro,
 
 On lun., f?vr. 08 2016, Masahiro Yamada <yamada.masahiro at socionext.com> wrote:

> This node pointer is returned by of_find_compatible_node() in this
> function.  It should be put before exitting this function.
>

Applied on mvebu/cleanup

Thanks,

Gregory

> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
> ---
>
>  arch/arm/mach-mvebu/platsmp.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
> index f9597b7..46c742d 100644
> --- a/arch/arm/mach-mvebu/platsmp.c
> +++ b/arch/arm/mach-mvebu/platsmp.c
> @@ -140,6 +140,7 @@ static void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
>  		panic("Cannot find 'marvell,bootrom' compatible node");
>  
>  	err = of_address_to_resource(node, 0, &res);
> +	of_node_put(node);
>  	if (err < 0)
>  		panic("Cannot get 'bootrom' node address");
>  
> -- 
> 1.9.1
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From arnd at arndb.de  Mon Feb  8 08:29:40 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 08 Feb 2016 17:29:40 +0100
Subject: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host
 controller ECAM compliant
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1ECACF44@lhreml503-mbs>
References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
 <3532826.pJr5R5Xa4c@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECACF44@lhreml503-mbs>
Message-ID: <2599997.xBRrI3qHak@wuerfel>

On Monday 08 February 2016 15:55:35 Gabriele Paoloni wrote:
> > Doesn't this break backwards compatibility?
> 
> Well Hip05/Hip06 SoCs are used into evaluation boards
> For the Estuary project.
> 
> https://github.com/hisilicon/estuary
> 
> As this new driver gets upstream we'll merge this new driver into estuary
> and release a new version of the firmware to support it.

So what happens to folks running the old firmware then?

> > I think you need to use a new compatible string in the firmware
> > if you change the register layout, and then change the driver
> > to support both the old and the new layout.
> 
> You are right, for some reason in this patchset I missed the Documentation
> update that I posted in the previous one, i.e.:
> 
> --- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> @@ -23,8 +23,8 @@ Optional properties:
>  Hip05 Example (note that Hip06 is the same except compatible):
>         pcie at 0xb0080000 {
>                 compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
> -               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0 0x2000>;
> -               reg-names = "rc_dbi", "config";
> +               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00100000 0 0x0f00000>;
> +               reg-names = "rc_dbi", "ecam-cfg";
> 

That is not the compatible string, it's an undocumented register set.
You can either define the a new compatible string that gives the "config"
registers a new meaning, or you change the binding to allow two either
a "config" or an "ecam-cfg" register set, and let the driver handle both.

	Arnd


From arnd at arndb.de  Mon Feb  8 08:32:48 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 08 Feb 2016 17:32:48 +0100
Subject: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06
 controllers driver to preapare for ACPI
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1ECACFDD@lhreml503-mbs>
References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
 <2409806.1aGBrN4l0X@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECACFDD@lhreml503-mbs>
Message-ID: <3113837.YSNyDAf4HQ@wuerfel>

On Monday 08 February 2016 16:06:54 Gabriele Paoloni wrote:
> > 
> > On Monday 08 February 2016 12:41:02 Gabriele Paoloni wrote:
> > > +
> > > +/* HipXX PCIe host only supports 32-bit config access */
> > > +int hisi_pcie_common_cfg_read(void __iomem *reg_base, int where, int
> > size,
> > > +                         u32 *val)
> > > +{
> > > +   u32 reg;
> > > +   u32 reg_val;
> > > +   void *walker = &reg_val;
> > > +
> > > +   walker += (where & 0x3);
> > > +   reg = where & ~0x3;
> > > +   reg_val = readl(reg_base + reg);
> > > +
> > > +   if (size == 1)
> > > +           *val = *(u8 __force *) walker;
> > > +   else if (size == 2)
> > > +           *val = *(u16 __force *) walker;
> > > +   else if (size == 4)
> > > +           *val = reg_val;
> > > +   else
> > > +           return PCIBIOS_BAD_REGISTER_NUMBER;
> > > +
> > > +   return PCIBIOS_SUCCESSFUL;
> > > +}
> > 
> > Isn't this the same hack that Qualcomm are using?
> 
> As far as I can see Qualcomm defines its own config access
> mechanism only for RC config read and also it seems they're
> having problems with reporting the device class...
> 
> https://github.com/torvalds/linux/blob/master/drivers/pci/host/pcie-qcom.c#L474
> 
> Our problem is that our HW can only perform 32b rd/wr accesses
> So we can't use readw/readb/writew/writeb...
> 
> 

Sorry, my mistake, I meant Cavium not Qualcomm.
See https://lkml.org/lkml/2016/2/5/689 for the patches.

	Arnd


From jonathanh at nvidia.com  Mon Feb  8 08:33:19 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Mon, 8 Feb 2016 16:33:19 +0000
Subject: [PATCH V2] ARM64: tegra: Add support for Google Pixel C
Message-ID: <1454949199-27050-1-git-send-email-jonathanh@nvidia.com>

Add initial device-tree support for Google Pixel C (a.k.a. Smaug) based
upon Tegra210 SoC with 3 GiB of LPDDR4 RAM.

Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
---
 arch/arm64/boot/dts/nvidia/Makefile           |  1 +
 arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 60 +++++++++++++++++++++++++++
 2 files changed, 61 insertions(+)
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra210-smaug.dts

diff --git a/arch/arm64/boot/dts/nvidia/Makefile b/arch/arm64/boot/dts/nvidia/Makefile
index a7e865da1005..0f7cdf3e05c1 100644
--- a/arch/arm64/boot/dts/nvidia/Makefile
+++ b/arch/arm64/boot/dts/nvidia/Makefile
@@ -2,6 +2,7 @@ dtb-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra132-norrin.dtb
 dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2371-0000.dtb
 dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2371-2180.dtb
 dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2571.dtb
+dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-smaug.dtb
 
 always		:= $(dtb-y)
 clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
new file mode 100644
index 000000000000..59acdb6b4f23
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
@@ -0,0 +1,60 @@
+/dts-v1/;
+
+#include "tegra210.dtsi"
+
+/ {
+	model = "Google Pixel C";
+	compatible = "google,smaug-rev8", "google,smaug-rev7",
+		     "google,smaug-rev6", "google,smaug-rev5",
+		     "google,smaug-rev4", "google,smaug-rev3",
+		     "google,smaug-rev1", "google,smaug", "nvidia,tegra210";
+
+	aliases {
+		serial0 = &uarta;
+	};
+
+	chosen {
+		bootargs = "earlycon";
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x0 0x80000000 0x0 0xc0000000>;
+	};
+
+	serial at 0,70006000 {
+		status = "okay";
+	};
+
+	pmc at 0,7000e400 {
+		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <0>;
+		nvidia,cpu-pwr-good-time = <0>;
+		nvidia,cpu-pwr-off-time = <0>;
+		nvidia,core-pwr-good-time = <12000 6000>;
+		nvidia,core-pwr-off-time = <39053>;
+		nvidia,core-power-req-active-high;
+		nvidia,sys-clock-req-active-high;
+		status = "okay";
+	};
+
+	sdhci at 0,700b0600 {
+		bus-width = <8>;
+		non-removable;
+		status = "okay";
+	};
+
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock at 0 {
+			compatible = "fixed-clock";
+			reg = <0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+};
-- 
2.1.4



From paul.gortmaker at windriver.com  Mon Feb  8 08:39:13 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Mon, 8 Feb 2016 11:39:13 -0500
Subject: [PATCH 1/5] ARM: add EXPORT_SYMBOL of hook_fault_code for PCI
 host modularization
In-Reply-To: <2567476.SknW0BEsQJ@wuerfel>
References: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
 <1454889644-27830-2-git-send-email-paul.gortmaker@windriver.com>
 <2567476.SknW0BEsQJ@wuerfel>
Message-ID: <20160208163913.GX23093@windriver.com>

[Re: [PATCH 1/5] ARM: add EXPORT_SYMBOL of hook_fault_code for PCI host modularization] On 08/02/2016 (Mon 10:53) Arnd Bergmann wrote:

> On Sunday 07 February 2016 19:00:40 Paul Gortmaker wrote:
> > In a discussion of a previous patch set[1], it was suggested that
> > modularizing some of the PCI host support would be good to keep
> > multi platform bzImage sizes smaller.
> > 
> > Two of the files that are candidates for conversion to tristate
> > from bool are:
> > 
> > drivers/pci/host/pci-imx6.c
> > drivers/pci/host/pci-keystone.c
> > 
> > However, doing the conversion reveals that they are going to fail
> > at modpost time since hook_fault_code isn't currently exported.
> > 
> > Since we are now going to export it we also need to remove the
> > __init tag, as the fcn needs to be present at insmod time.
> > 
> > [1] https://lkml.kernel.org/r/20160108203102.GH5354 at localhost
> > 
> 
> If we want to make hook_fault_code() visible, we at least also need
> an unhook_fault_code() function that removes the fault handler
> when unloading the module, and preferably does so in a safe way.

If it is straight forward by doing an unwind of the existing hook, then
I can look at having a go at implementing it, but again per the 0/N the
original goal here was the "step one" of making it at least buildable,
and then moving on from there, preferably by people with the platforms
and deeper knowledge of the runtime requirements and issues.

> 
> The usage of hook_fault_code() at least in the imx driver is also
> problematic, as it just ignores all "imprecise external abort"
> faults, whether they come from PCI or not.

That is definitely beyond anything I'm suitably armed to fix within the
scope of this series, and will have to be from the imx people or similar.

Paul.
--


> 
> 	Arnd


From linux at arm.linux.org.uk  Mon Feb  8 08:39:35 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Feb 2016 16:39:35 +0000
Subject: [PATCH 1/3] ARM: move .vectors and .stubs sections back into the
 kernel VMA
In-Reply-To: <CAKv+Gu8jbfs6HuzoFTQV2z-0LLiEZ9p0ZHO6eF3itE8p1LMwBA@mail.gmail.com>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454419174-21290-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160203000351.GX10826@n2100.arm.linux.org.uk>
 <CAKv+Gu_kYWczCazqgRC3y-n7s3WRTDhJXLO1RM1FE-6h1BhSUw@mail.gmail.com>
 <20160203091331.GB10826@n2100.arm.linux.org.uk>
 <CAKv+Gu8jbfs6HuzoFTQV2z-0LLiEZ9p0ZHO6eF3itE8p1LMwBA@mail.gmail.com>
Message-ID: <20160208163935.GN10826@n2100.arm.linux.org.uk>

On Wed, Feb 03, 2016 at 10:16:46AM +0100, Ard Biesheuvel wrote:
> There are 34 section headers, starting at offset 0x10a6e60:
> 
> Section Headers:
>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>   [16] .vectors          PROGBITS        00000000 a40000 000020 00  AX  0   0  2
>   [17] .stubs            PROGBITS        00001000 a41000 0002c0 00  AX  0   0 32
>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
...
> Section Headers:
>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>   [16] .stubs            PROGBITS        c0c35000 a35000 0002c0 00  AX  0   0 32
>   [17] .vectors          PROGBITS        c0c34000 a44000 000020 00  AX  0   0  2
>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32

Sorry, but I'm going to re-iterate my objection, and I believe that
because you're looking at readelf's output, you're making assumptions
when interpreting its output.

These figures do not truely describe how the file is laid out.  The
tool to use for this is objdump -h.  Let's compare:

$ readelf -S vmlinux
Section Headers:
  [Nr] Name        Type         Addr     Off    Size   ES Flg Lk Inf Al
  [13] .notes      NOTE         c093afd0 93afd0 000024 00  AX  0   0  4
  [14] .vectors    PROGBITS     00000000 940000 000020 00  AX  0   0  4
  [15] .stubs      PROGBITS     00001000 941000 0002c0 00  AX  0   0 32
  [16] .init.text  PROGBITS     c093b2e0 94b2e0 04862c 00  AX  0   0 32

$ objdump -h vmlinux
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
 12 .notes        00000024  c093afd0  c093afd0  0093afd0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 13 .vectors      00000020  00000000  c093b000  00940000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 14 .stubs        000002c0  00001000  c093b020  00941000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 15 .init.text    0004862c  c093b2e0  c093b2e0  0094b2e0  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

Note that objdump -h has one additional piece of information here: the
LMA - load memory address.  This tells us where the file contents
(offset into the ELF file at "File off") are to be loaded into memory,
as opposed to the VMA which describes where (at run time) the object is
to be found.

With this new information, we can see that .vectors is loaded to
0xc093b000, and occupies only 32 bytes in the binary memory image, even
though it occupies 4k in the ELF file.)  .stubs is loaded at 0xc093b020,
and occupies 0x2c0 bytes.  Furthermore, we can see .init.text is located
at 0xc093b2e0.

So, there is no memory wastage here - .vectors, .stubs and the init text
are all packed tightly together.  That's something which the readelf -S
output doesn't show us.

Please, replace the readelf -S output with objdump -h output so that we
can see what's /really/ going on here.

In any case, I still don't like your patch.  At least having these at 0
and 0x1000 means that (for some CPUs) they are located at the real VMA
address that they may appear at, though for modern CPUs, locating them
at 0xffff0000 and 0xffff1000 VMA would be more reasonable.  This has the
advantage that (jtag) debuggers are able to correctly parse the vmlinux
file and insert breakpoints into the vectors.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From codekipper at gmail.com  Mon Feb  8 08:40:34 2016
From: codekipper at gmail.com (Code Kipper)
Date: Mon, 8 Feb 2016 17:40:34 +0100
Subject: [PATCH v5 0/2] ASoC: Add SPDIF support for Allwinner SoCs
In-Reply-To: <1454945167-29324-1-git-send-email-codekipper@gmail.com>
References: <1454945167-29324-1-git-send-email-codekipper@gmail.com>
Message-ID: <CAEKpxBkyinCeZ_d-AYkiFoxaa48J3nTwTRtKCtC=xXBeBJhZcA@mail.gmail.com>

NAK...last bunch of changes introduced a warning which slipped
through, I'll fix that and send a new patch series.
CK

On 8 February 2016 at 16:26,  <codekipper at gmail.com> wrote:
> From: Marcus Cooper <codekipper at gmail.com>
>
> This patch set adds support for the Allwinner SPDIF transceiver.
>
> For now just the SPDIF transmitter has been tested on a Mele A2000(A10)
> and a Itead Ibox(A20).
>
> In order for this patch set to be functional we require an audio clock patch
> which will be delivered separately. For those that are interested I've pushed
> the patches here with all the required changes to get SPDIF audio out of the
> device.
>
> https://github.com/codekipper/linux-sunxi/commits/spdif_delivery
>
> Thanks in advance,
> CK
>
> ---
> Changes since v4:
> - corrected indentation issues
> - removed old macros
> - removed unnecessary enabling of apb clock
>
> Changes since v3:
> - removed code required for spdif capture
> - added disable/enable of apb clk to suspend/resume.
> - removed unnecessary dt checks in probe
> - fixed error conditions in probe/resume
> - modified pm_runtime functionality and confirmed that driver worked when PM was disabled.
> - removed .owner from platform driver
> - renamed bindings file
>
> Changes since v2:
> - removed sunxi-machine-spdif and replaced with simple audio card
> - removed untested compatibilities from device tree documentation
> - added pm_runtime and remove shutdown
> - removed pll2 as it's the parent of the spdif clock
> - rename clk to spdif_clk
> - removed enabling of mclk output
> - removed interrupts status being cleared as it's not being used
> - use default fifo settings for now
> - fixed alignments for wrapped lines
>
> Changes since v1:
> - Moved sunxi-machine-spdif.c to separate patch
> - replaced sunxi in naming scheme with sun4i in the sun4i-spdif driver.
> - split tx controller into separate enable/disable functions
> - moved setclk and setfmt functionality into hw params
> - added support for mono signals.
> - cleaned up probe clock set up.
> - removed all writes to transmit status registers.
> - removed of_id
> - removed power management code.
> - Added support for more rates.
>
> Marcus Cooper (2):
>   dt-bindings: sunxi :add sun4i SPDIF transceiver
>   ASoC: sunxi: Add support for the SPDIF block
>
>  .../bindings/sound/sunxi,sun4i-spdif.txt           |  39 ++
>  sound/soc/sunxi/Kconfig                            |   8 +
>  sound/soc/sunxi/Makefile                           |   1 +
>  sound/soc/sunxi/sun4i-spdif.c                      | 549 +++++++++++++++++++++
>  4 files changed, 597 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
>  create mode 100644 sound/soc/sunxi/sun4i-spdif.c
>
> --
> 2.7.1
>


From marc.zyngier at arm.com  Mon Feb  8 08:45:44 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 8 Feb 2016 16:45:44 +0000
Subject: [PATCH v3 21/23] arm64: hw_breakpoint: Allow EL2 breakpoints if
 running in HYP
In-Reply-To: <20160208155625.GQ6076@e104818-lin.cambridge.arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-22-git-send-email-marc.zyngier@arm.com>
 <20160208155625.GQ6076@e104818-lin.cambridge.arm.com>
Message-ID: <56B8C638.2010402@arm.com>

On 08/02/16 15:56, Catalin Marinas wrote:
> On Wed, Feb 03, 2016 at 06:00:14PM +0000, Marc Zyngier wrote:
>> @@ -76,6 +59,36 @@ static inline void decode_ctrl_reg(u32 reg,
>>  #define ARM_KERNEL_STEP_ACTIVE	1
>>  #define ARM_KERNEL_STEP_SUSPEND	2
>>  
>> +#define DBG_HMC_HYP		(1 << 13)
>> +#define DBG_SSC_HYP		(3 << 14)
>> +
>> +static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
>> +{
>> +	u32 val = (ctrl.len << 5) | (ctrl.type << 3) | ctrl.enabled;
>> +
>> +	if (is_kernel_in_hyp_mode() && ctrl.privilege == AARCH64_BREAKPOINT_EL1)
>> +		val |= DBG_HMC_HYP | DBG_SSC_HYP;
>> +	else
>> +		val |= ctrl.privilege << 1;
>> +
>> +	return val;
>> +}
>> +
>> +static inline void decode_ctrl_reg(u32 reg,
>> +				   struct arch_hw_breakpoint_ctrl *ctrl)
>> +{
>> +	ctrl->enabled	= reg & 0x1;
>> +	reg >>= 1;
>> +	if (is_kernel_in_hyp_mode())
>> +		ctrl->privilege = !!(reg & (DBG_HMC_HYP >> 1));
> 
> I don't particularly like this part as it's not clear just by looking at
> the code that it, in fact, generates AARCH64_BREAKPOINT_EL1. I would
> make this clearer:
> 
> 	if (is_kernel_in_hyp_mode() && (reg & (DBG_HMC_HYP >> 1)))
> 		ctrl->privilege = AARCH64_BREAKPOINT_EL1;
> 
> Alternatively, you could define the PMC field value as:
> 
> #define AARCH64_BREAKPOINT_EL2	0
> 
> and change the privilege to EL1 after masking, something like:
> 
> 	ctrl->privilege = reg & 0x3;
> 	if (ctrl->privilege == AARCH64_BREAKPOINT_EL2)
> 		ctrl->privilege = AARCH64_BREAKPOINT_EL1;
> 
> BTW, do we need to check is_kernel_in_hyp_mode() when decoding? Is there
> anything else that could have set this SSC/HMC/PMC fields other than
> encode_ctrl_reg()?

I was being overzealous, and your solution is clearly better. I ended up with the following:

diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
index 9732908..c872b2f 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -18,6 +18,7 @@
 
 #include <asm/cputype.h>
 #include <asm/cpufeature.h>
+#include <asm/virt.h>
 
 #ifdef __KERNEL__
 
@@ -35,24 +36,6 @@ struct arch_hw_breakpoint {
 	struct arch_hw_breakpoint_ctrl ctrl;
 };
 
-static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
-{
-	return (ctrl.len << 5) | (ctrl.type << 3) | (ctrl.privilege << 1) |
-		ctrl.enabled;
-}
-
-static inline void decode_ctrl_reg(u32 reg,
-				   struct arch_hw_breakpoint_ctrl *ctrl)
-{
-	ctrl->enabled	= reg & 0x1;
-	reg >>= 1;
-	ctrl->privilege	= reg & 0x3;
-	reg >>= 2;
-	ctrl->type	= reg & 0x3;
-	reg >>= 2;
-	ctrl->len	= reg & 0xff;
-}
-
 /* Breakpoint */
 #define ARM_BREAKPOINT_EXECUTE	0
 
@@ -62,6 +45,7 @@ static inline void decode_ctrl_reg(u32 reg,
 #define AARCH64_ESR_ACCESS_MASK	(1 << 6)
 
 /* Privilege Levels */
+#define AARCH64_BREAKPOINT_EL2	0
 #define AARCH64_BREAKPOINT_EL1	1
 #define AARCH64_BREAKPOINT_EL0	2
 
@@ -76,6 +60,35 @@ static inline void decode_ctrl_reg(u32 reg,
 #define ARM_KERNEL_STEP_ACTIVE	1
 #define ARM_KERNEL_STEP_SUSPEND	2
 
+#define DBG_HMC_HYP		(1 << 13)
+#define DBG_SSC_HYP		(3 << 14)
+
+static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
+{
+	u32 val = (ctrl.len << 5) | (ctrl.type << 3) | ctrl.enabled;
+
+	if (is_kernel_in_hyp_mode() && ctrl.privilege == AARCH64_BREAKPOINT_EL1)
+		val |= DBG_HMC_HYP | DBG_SSC_HYP;
+	else
+		val |= ctrl.privilege << 1;
+
+	return val;
+}
+
+static inline void decode_ctrl_reg(u32 reg,
+				   struct arch_hw_breakpoint_ctrl *ctrl)
+{
+	ctrl->enabled	= reg & 0x1;
+	reg >>= 1;
+	ctrl->privilege	= reg & 0x3;
+	if (ctrl->privilege == AARCH64_BREAKPOINT_EL2)
+		ctrl->privilege	= AARCH64_BREAKPOINT_EL1;
+	reg >>= 2;
+	ctrl->type	= reg & 0x3;
+	reg >>= 2;
+	ctrl->len	= reg & 0xff;
+}
+
 /*
  * Limits.
  * Changing these will require modifications to the register accessors.

Was that what you had in mind?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From paul.gortmaker at windriver.com  Mon Feb  8 08:45:44 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Mon, 8 Feb 2016 11:45:44 -0500
Subject: [PATCH 2/2] serial: 8250: fix building Ingenic with SERIAL_8250=m
In-Reply-To: <1454935947-2743255-2-git-send-email-arnd@arndb.de>
References: <1454935947-2743255-1-git-send-email-arnd@arndb.de>
 <1454935947-2743255-2-git-send-email-arnd@arndb.de>
Message-ID: <20160208164543.GY23093@windriver.com>

[[PATCH 2/2] serial: 8250: fix building Ingenic with SERIAL_8250=m] On 08/02/2016 (Mon 13:51) Arnd Bergmann wrote:

> The Ingenic 8250 driver has a 'bool' Kconfig symbol, but that
> breaks when SERIAL_8250 is a loadable module:
> 
> drivers/tty/built-in.o: In function `ingenic_uart_probe':
> 8250_ingenic.c:(.text+0x1c1a0): undefined reference to `serial8250_register_8250_port'
> 
> This changes the symbol to a 'tristate', plus a dependency on

Note that Greg just queued a patch yesterday (but sent in 2015) that
removed what was the dead modular code.

It could also depend on SERIAL_8250=y to resolve the build issue you
found, if nobody cares about having modular SOC console UART drivers.

Either way, I don't have issue with it being tristate vs bool, but if
you do go with tristate, then my patch will have to be dropped/reverted.

Paul.
--

> SERIAL_8250, which makes it work again. Unlike the other
> soc-specific backends, this one has no dependency on an
> architecture or a platform. I'm adding a dependency on
> MIPS || COMPILE_TEST as well here, to avoid showing the driver
> on architectures that are not interested in it.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/tty/serial/8250/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
> index 6ae0fae4f796..13c63b14179f 100644
> --- a/drivers/tty/serial/8250/Kconfig
> +++ b/drivers/tty/serial/8250/Kconfig
> @@ -384,8 +384,8 @@ config SERIAL_8250_UNIPHIER
>  	  serial ports, say Y to this option. If unsure, say N.
>  
>  config SERIAL_8250_INGENIC
> -	bool "Support for Ingenic SoC serial ports"
> -	depends on OF_FLATTREE
> +	tristate "Support for Ingenic SoC serial ports"
> +	depends on SERIAL_8250 && OF_FLATTREE && (MIPS || COMPILE_TEST)
>  	select LIBFDT
>  	help
>  	  If you have a system using an Ingenic SoC and wish to make use of
> -- 
> 2.7.0
> 


From catalin.marinas at arm.com  Mon Feb  8 08:46:46 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 8 Feb 2016 16:46:46 +0000
Subject: [PATCH v5sub2 0/8] arm64: implement virtual KASLR
In-Reply-To: <CAKv+Gu9RmhaYBHOKwsPNynJ4Zia2kSJ6Yr3U4c6F13UHdbzFtw@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <CAKv+Gu-AhLcatkDsQVeoFGJ+pTEwaW1Hy9M-fY1-VWvRc_E47w@mail.gmail.com>
 <20160205173248.GJ6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_v1sXM7sivz+Uu86ZG3=Th7wqqh7M1N8wF7Ess4NdTZQ@mail.gmail.com>
 <CAGXu5j+JpwRrVy1b_h+LJ4sCzsT7BV9RdcD0CvR-4aVJQhCpvg@mail.gmail.com>
 <20160208121430.GL6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-=RLS8Zgn_evmoUUSHqSVfaw9_hjVMgfg1FZGRDGFVag@mail.gmail.com>
 <20160208161918.GT6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu9RmhaYBHOKwsPNynJ4Zia2kSJ6Yr3U4c6F13UHdbzFtw@mail.gmail.com>
Message-ID: <20160208164646.GU6076@e104818-lin.cambridge.arm.com>

On Mon, Feb 08, 2016 at 05:20:41PM +0100, Ard Biesheuvel wrote:
> On 8 February 2016 at 17:19, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Mon, Feb 08, 2016 at 03:30:47PM +0100, Ard Biesheuvel wrote:
> >> However, the arm64 patch (#6) now conflicts with futex.h in -rc3 after
> >> the PAN fix, not sure how to best address that ...
> >
> > I'll have a look.
> 
> Note that the fix is trivial, but I don't know who should be carrying
> the fix is all

I'll push the arm64 for-next/core branch (including your series) out
against 4.5-rc3, so there won't be any conflict.

-- 
Catalin


From gabriele.paoloni at huawei.com  Mon Feb  8 08:51:19 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Mon, 8 Feb 2016 16:51:19 +0000
Subject: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06
 controllers driver to preapare for ACPI
In-Reply-To: <3113837.YSNyDAf4HQ@wuerfel>
References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
 <2409806.1aGBrN4l0X@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECACFDD@lhreml503-mbs>
 <3113837.YSNyDAf4HQ@wuerfel>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECAD249@lhreml503-mbs>

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 08 February 2016 16:33
> To: Gabriele Paoloni
> Cc: linux-arm-kernel at lists.infradead.org; Guohanjun (Hanjun Guo);
> Wangzhou (B); liudongdong (C); Linuxarm; qiujiang; bhelgaas at google.com;
> Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-pci at vger.kernel.org;
> linux-kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth)
> Subject: Re: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06
> controllers driver to preapare for ACPI
> 
> On Monday 08 February 2016 16:06:54 Gabriele Paoloni wrote:
> > >
> > > On Monday 08 February 2016 12:41:02 Gabriele Paoloni wrote:
> > > > +
> > > > +/* HipXX PCIe host only supports 32-bit config access */
> > > > +int hisi_pcie_common_cfg_read(void __iomem *reg_base, int where,
> int
> > > size,
> > > > +                         u32 *val)
> > > > +{
> > > > +   u32 reg;
> > > > +   u32 reg_val;
> > > > +   void *walker = &reg_val;
> > > > +
> > > > +   walker += (where & 0x3);
> > > > +   reg = where & ~0x3;
> > > > +   reg_val = readl(reg_base + reg);
> > > > +
> > > > +   if (size == 1)
> > > > +           *val = *(u8 __force *) walker;
> > > > +   else if (size == 2)
> > > > +           *val = *(u16 __force *) walker;
> > > > +   else if (size == 4)
> > > > +           *val = reg_val;
> > > > +   else
> > > > +           return PCIBIOS_BAD_REGISTER_NUMBER;
> > > > +
> > > > +   return PCIBIOS_SUCCESSFUL;
> > > > +}
> > >
> > > Isn't this the same hack that Qualcomm are using?
> >
> > As far as I can see Qualcomm defines its own config access
> > mechanism only for RC config read and also it seems they're
> > having problems with reporting the device class...
> >
> > https://github.com/torvalds/linux/blob/master/drivers/pci/host/pcie-
> qcom.c#L474
> >
> > Our problem is that our HW can only perform 32b rd/wr accesses
> > So we can't use readw/readb/writew/writeb...
> >
> >
> 
> Sorry, my mistake, I meant Cavium not Qualcomm.
> See https://lkml.org/lkml/2016/2/5/689 for the patches.

Well, looking at it Cavium seems quite different, 

On read they need to trigger the retrieval of the
config space info writing to the lower 32b of a 64b register,
then they need to read data back on the upper 64b of the
same register and adjust the content to remove the garbage...

We just use 32b accesses and adjust grab the appropriate
bytes depending on the read/write sizes...

Thanks 

Gab

> 
> 	Arnd


From catalin.marinas at arm.com  Mon Feb  8 08:52:15 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 8 Feb 2016 16:52:15 +0000
Subject: [PATCH v3 21/23] arm64: hw_breakpoint: Allow EL2 breakpoints if
 running in HYP
In-Reply-To: <56B8C638.2010402@arm.com>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-22-git-send-email-marc.zyngier@arm.com>
 <20160208155625.GQ6076@e104818-lin.cambridge.arm.com>
 <56B8C638.2010402@arm.com>
Message-ID: <20160208165214.GV6076@e104818-lin.cambridge.arm.com>

On Mon, Feb 08, 2016 at 04:45:44PM +0000, Marc Zyngier wrote:
> I was being overzealous, and your solution is clearly better. I ended up with the following:
> 
> diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
> index 9732908..c872b2f 100644
> --- a/arch/arm64/include/asm/hw_breakpoint.h
> +++ b/arch/arm64/include/asm/hw_breakpoint.h
[...]
> @@ -62,6 +45,7 @@ static inline void decode_ctrl_reg(u32 reg,
>  #define AARCH64_ESR_ACCESS_MASK	(1 << 6)
>  
>  /* Privilege Levels */
> +#define AARCH64_BREAKPOINT_EL2	0
>  #define AARCH64_BREAKPOINT_EL1	1
>  #define AARCH64_BREAKPOINT_EL0	2
>  
> @@ -76,6 +60,35 @@ static inline void decode_ctrl_reg(u32 reg,
>  #define ARM_KERNEL_STEP_ACTIVE	1
>  #define ARM_KERNEL_STEP_SUSPEND	2
>  
> +#define DBG_HMC_HYP		(1 << 13)
> +#define DBG_SSC_HYP		(3 << 14)
> +
> +static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
> +{
> +	u32 val = (ctrl.len << 5) | (ctrl.type << 3) | ctrl.enabled;
> +
> +	if (is_kernel_in_hyp_mode() && ctrl.privilege == AARCH64_BREAKPOINT_EL1)
> +		val |= DBG_HMC_HYP | DBG_SSC_HYP;

Nitpick, for completeness:

		val |= DBG_HMC_HYP | DBG_SSC_HYP | (AARCH64_BREAKPOINT_EL2 << 1);

> +	else
> +		val |= ctrl.privilege << 1;
> +
> +	return val;
> +}
> +
> +static inline void decode_ctrl_reg(u32 reg,
> +				   struct arch_hw_breakpoint_ctrl *ctrl)
> +{
> +	ctrl->enabled	= reg & 0x1;
> +	reg >>= 1;
> +	ctrl->privilege	= reg & 0x3;
> +	if (ctrl->privilege == AARCH64_BREAKPOINT_EL2)
> +		ctrl->privilege	= AARCH64_BREAKPOINT_EL1;
> +	reg >>= 2;
> +	ctrl->type	= reg & 0x3;
> +	reg >>= 2;
> +	ctrl->len	= reg & 0xff;
> +}
> +
>  /*
>   * Limits.
>   * Changing these will require modifications to the register accessors.
> 
> Was that what you had in mind?

Looks fine:

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From gregkh at linuxfoundation.org  Mon Feb  8 08:52:26 2016
From: gregkh at linuxfoundation.org (Greg KH)
Date: Mon, 8 Feb 2016 08:52:26 -0800
Subject: [PATCH v2 04/10] serial: mps2-uart: add MPS2 UART driver
In-Reply-To: <56B87928.7020803@arm.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
 <1454413199-26573-5-git-send-email-vladimir.murzin@arm.com>
 <20160207071154.GA32017@kroah.com> <56B87928.7020803@arm.com>
Message-ID: <20160208165226.GA11593@kroah.com>

On Mon, Feb 08, 2016 at 11:16:56AM +0000, Vladimir Murzin wrote:
> On 07/02/16 07:11, Greg KH wrote:
> >> +
> >> +#define SERIAL_NAME "ttyS"
> > 
> > You can't be "ttyS", there's already a serial port named that, please
> > use a unique name and a new major/minor number (dynamic ideally).
> > 
> 
> Hi Greg,
> 
> I did s/ttyMPS/ttyS per your request for v1 [1]. I'm fine to change it
> back if you prefer that, but I'd be glad to know what I've been missing?
> 
> [1] https://lkml.org/lkml/2015/12/13/8

Yeah, I was wrong, sorry about that, my fault.

greg k-h


From jonathanh at nvidia.com  Mon Feb  8 08:53:51 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Mon, 8 Feb 2016 16:53:51 +0000
Subject: Tegra baseline test results for v4.5-rc3
Message-ID: <56B8C81F.6000300@nvidia.com>

Here are some basic Tegra test results for Linux v4.5-rc3.
Logs and other details at:

    https://nvtb.github.io//linux/test_v4.5-rc3/20160208033104/


Test summary
------------

Build: zImage:
    Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig

Build: Image:
    Pass: ( 1/ 1): defconfig

Boot to userspace: defconfig:
    Pass: ( 3/ 3): qemu-vexpress64, tegra132-norrin,
		   tegra210-p2371-0000

Boot to userspace: multi_v7_defconfig:
    Pass: ( 4/ 4): tegra114-dalmore-a04, tegra124-jetson-tk1,
		   tegra20-trimslice, tegra30-beaver

Boot to userspace: tegra_defconfig:
    Pass: ( 4/ 4): tegra114-dalmore-a04, tegra124-jetson-tk1,
		   tegra20-trimslice, tegra30-beaver

PM: System suspend: multi_v7_defconfig:
    Pass: ( 4/ 4): tegra114-dalmore-a04, tegra124-jetson-tk1,
		   tegra20-trimslice, tegra30-beaver

PM: System suspend: tegra_defconfig:
    Pass: ( 4/ 4): tegra114-dalmore-a04, tegra124-jetson-tk1,
		   tegra20-trimslice, tegra30-beaver


vmlinux object size
(delta in bytes from test_v4.5-rc2 (36f90b0a2ddd60823fe193a85e60ff1906c2a9b3)):
   text     data      bss    total  kernel
  +4160   +12288     -128   +16320  defconfig
  +3754     +320      +64    +4138  multi_v7_defconfig
  +1938     +456        0    +2394  tegra_defconfig


Boot-time memory difference
(delta in bytes from test_v4.5-rc2 (36f90b0a2ddd60823fe193a85e60ff1906c2a9b3))
    avail    rsrvd     high    freed                board              kconfig                  dtb
        .        .        .        .      qemu-vexpress64            defconfig           __internal
      -8k       8k        .       4k tegra114-dalmore-a04   multi_v7_defconfig     tegra114-dalmore
      -4k       4k        .      -4k tegra114-dalmore-a04      tegra_defconfig     tegra114-dalmore
      -8k       8k        .       4k  tegra124-jetson-tk1   multi_v7_defconfig  tegra124-jetson-tk1
      -4k       4k        .      -4k  tegra124-jetson-tk1      tegra_defconfig  tegra124-jetson-tk1
        .        .        .        .      tegra132-norrin            defconfig      tegra132-norrin
      -8k       8k        .       4k    tegra20-trimslice   multi_v7_defconfig    tegra20-trimslice
      -4k       4k        .      -4k    tegra20-trimslice      tegra_defconfig    tegra20-trimslice
        .        .        .        .  tegra210-p2371-0000            defconfig  tegra210-p2371-0000
      -8k       8k        .       4k       tegra30-beaver   multi_v7_defconfig       tegra30-beaver
      -4k       4k        .      -4k       tegra30-beaver      tegra_defconfig       tegra30-beaver


From paul.gortmaker at windriver.com  Mon Feb  8 08:55:35 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Mon, 8 Feb 2016 11:55:35 -0500
Subject: [PATCH 1/2] serial: 8250: fix building mediatek with SERIAL_8250=m
In-Reply-To: <1454935947-2743255-1-git-send-email-arnd@arndb.de>
References: <1454935947-2743255-1-git-send-email-arnd@arndb.de>
Message-ID: <20160208165535.GZ23093@windriver.com>

[[PATCH 1/2] serial: 8250: fix building mediatek with SERIAL_8250=m] On 08/02/2016 (Mon 13:51) Arnd Bergmann wrote:

> The Mediatek 8250 driver has a 'bool' Kconfig symbol, but that
> breaks when SERIAL_8250 is a loadable module:
> 
> drivers/tty/built-in.o: In function `mtk8250_set_termios':
> 8250_ingenic.c:(.text+0x1bee8): undefined reference to `serial8250_do_set_termios'
> 8250_ingenic.c:(.text+0x1bf10): undefined reference to `uart_get_baud_rate'
> 8250_ingenic.c:(.text+0x1c09c): undefined reference to `uart_get_divisor'
> drivers/tty/built-in.o: In function `mtk8250_do_pm':
> 8250_ingenic.c:(.text+0x1c0d0): undefined reference to `serial8250_do_pm'
> drivers/tty/built-in.o: In function `mtk8250_probe':
> 8250_ingenic.c:(.text+0x1c2e4): undefined reference to `serial8250_register_8250_port'
> serial/8250/8250_mtk.c:287:242: error: data definition has no type or storage class [-Werror]
> serial/8250/8250_mtk.c:287:122: error: 'mtk8250_platform_driver_init' defined but not used [-Werror=unused-function]

Probably should drop the ingenic lines above ; assuming they are make -j N
related and that mtk doesn't depend on or build ingenic.

> 
> This changes the symbol to a 'tristate', so the dependency on
> SERIAL_8250 also works when that is set to 'm'.
> To actually build the driver, we also need to include <linux/module.h>.
> 
> Note that the driver uses builtin_platform_driver() and implements
> no .remove() callback, so unloading the module is not possible.

But this is due to d72d391c126e0ffd3047c06c4bef4d795853d5d5.  So again,
I'm not sure what this achives vs. just making it depend on having
SERIAL_8250=y as a trivial fix for the one build issue.

If you really see a use case for tristate, then the above should be
reverted before adding your conversion to tristate I think.

Paul.
--

> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/tty/serial/8250/8250_mtk.c | 1 +
>  drivers/tty/serial/8250/Kconfig    | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
> index 9038843cadc7..7e9242a5ddfe 100644
> --- a/drivers/tty/serial/8250/8250_mtk.c
> +++ b/drivers/tty/serial/8250/8250_mtk.c
> @@ -19,6 +19,7 @@
>  #include <linux/init.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_platform.h>
> +#include <linux/module.h>
>  #include <linux/platform_device.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/serial_8250.h>
> diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
> index 67ad6b0d595b..6ae0fae4f796 100644
> --- a/drivers/tty/serial/8250/Kconfig
> +++ b/drivers/tty/serial/8250/Kconfig
> @@ -370,7 +370,7 @@ config SERIAL_8250_LPC18XX
>  	  serial port, say Y to this option. If unsure, say Y.
>  
>  config SERIAL_8250_MT6577
> -	bool "Mediatek serial port support"
> +	tristate "Mediatek serial port support"
>  	depends on SERIAL_8250 && ARCH_MEDIATEK
>  	help
>  	  If you have a Mediatek based board and want to use the
> -- 
> 2.7.0
> 


From codekipper at gmail.com  Mon Feb  8 08:56:06 2016
From: codekipper at gmail.com (Code Kipper)
Date: Mon, 8 Feb 2016 17:56:06 +0100
Subject: [linux-sunxi][PATCH] ARM: dts: sun7i: Enable USB DRC on Itead Ibox
In-Reply-To: <56B8BED7.9030704@redhat.com>
References: <1454947167-12236-1-git-send-email-codekipper@gmail.com>
 <56B8BED7.9030704@redhat.com>
Message-ID: <CAEKpxBkXp9hx6KWpWyRBvYBFi7Sr0FgFHrD6M0nSBuJ1bV++1A@mail.gmail.com>

On 8 February 2016 at 17:14, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
> On 08-02-16 16:59, codekipper at gmail.com wrote:
>>
>> From: Marcus Cooper <codekipper at gmail.com>
>>
>> Enable the otg/drc usb controller on the Itead Ibox device.
>>
>> Signed-off-by: Marcus Cooper <codekipper at gmail.com>
>
>
> Same remark as with your Olimex A20 EVB board patch, please
> also provide a vbus detect pin setting. If for some reason the
> VBus detect is not wired up, or not working properly, please mention
> this explicitly in the commit message.
Hi Hans,
I've added vbus detect and it no longer works. It's mentioned that the
Itead Ibox is similar to the Cubieboard 2 which also doesn't include
the detect. I can see now in the commit that it states "Note this
board has the otg-vbus connected directly to the 5v-dcc of the board,
so there is no vbus0 regulator, nor vbus0-det.", I will add this to
the commit message and try and dig out a schematic to confirm.
Thanks,
CK
>
> Note that in some cases the axp209 is used for vbus detect,
> rather then a gpio, see e.g. :
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/sun7i-a20-bananapi.dts?id=dcfd8443d89f593e0c667a988ab017e716b33061
>
> Regards,
>
> Hans
>
>
>
>
>> ---
>>   arch/arm/boot/dts/sun7i-a20-itead-ibox.dts     | 14 ++++++++++++++
>>   arch/arm/boot/dts/sunxi-itead-core-common.dtsi |  9 +++++++++
>>   2 files changed, 23 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
>> b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
>> index 661c21d..a512581 100644
>> --- a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
>> +++ b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
>> @@ -118,8 +118,22 @@
>>                 allwinner,drive = <SUN4I_PINCTRL_20_MA>;
>>                 allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>         };
>> +
>> +       usb0_id_detect_pin: usb0_id_detect_pin at 0 {
>> +               allwinner,pins = "PH4";
>> +               allwinner,function = "gpio_in";
>> +               allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> +               allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> +       };
>>   };
>>
>>   &reg_ahci_5v {
>>         status = "okay";
>>   };
>> +
>> +&usbphy {
>> +       pinctrl-names = "default";
>> +       pinctrl-0 = <&usb0_id_detect_pin>;
>> +       usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
>> +       status = "okay";
>> +};
>> diff --git a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
>> b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
>> index 2565d51..d22eea3 100644
>> --- a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
>> +++ b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
>> @@ -88,6 +88,10 @@
>>         status = "okay";
>>   };
>>
>> +&otg_sram {
>> +       status = "okay";
>> +};
>> +
>>   #include "axp209.dtsi"
>>
>>   &reg_dcdc2 {
>> @@ -129,6 +133,11 @@
>>         status = "okay";
>>   };
>>
>> +&usb_otg {
>> +       dr_mode = "otg";
>> +       status = "okay";
>> +};
>> +
>>   &usbphy {
>>         usb1_vbus-supply = <&reg_usb1_vbus>;
>>         usb2_vbus-supply = <&reg_usb2_vbus>;
>>
>


From julien.grall at arm.com  Mon Feb  8 08:47:28 2016
From: julien.grall at arm.com (Julien Grall)
Date: Mon,  8 Feb 2016 16:47:28 +0000
Subject: [PATCH 4/5] irqchip/gic-v3: Parse and export virtual GIC information
In-Reply-To: <1454950049-741-1-git-send-email-julien.grall@arm.com>
References: <1454950049-741-1-git-send-email-julien.grall@arm.com>
Message-ID: <1454950049-741-5-git-send-email-julien.grall@arm.com>

Fill up the recently introduced gic_kvm_info with the virtual GIC
information.

Signed-off-by: Julien Grall <julien.grall at arm.com>
---
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier at arm.com>

 drivers/irqchip/irq-gic-v3.c           | 43 ++++++++++++++++++++++++++++++++++
 include/linux/irqchip/arm-gic-common.h |  1 +
 2 files changed, 44 insertions(+)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index d7be6dd..35f11ce 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -26,6 +26,7 @@
 #include <linux/slab.h>
 
 #include <linux/irqchip.h>
+#include <linux/irqchip/arm-gic-common.h>
 #include <linux/irqchip/arm-gic-v3.h>
 
 #include <asm/cputype.h>
@@ -53,6 +54,8 @@ struct gic_chip_data {
 static struct gic_chip_data gic_data __read_mostly;
 static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;
 
+static struct gic_kvm_info gic_v3_kvm_info;
+
 #define gic_data_rdist()		(this_cpu_ptr(gic_data.rdists.rdist))
 #define gic_data_rdist_rd_base()	(gic_data_rdist()->rd_base)
 #define gic_data_rdist_sgi_base()	(gic_data_rdist_rd_base() + SZ_64K)
@@ -811,6 +814,44 @@ static void gicv3_enable_quirks(void)
 #endif
 }
 
+static void __init gic_of_setup_kvm_info(struct device_node *node)
+{
+	int ret;
+	struct resource r;
+	u32 gicv_idx;
+	unsigned int irq;
+
+	gic_v3_kvm_info.type = GIC_V3;
+
+	irq = irq_of_parse_and_map(node, 0);
+	if (!irq)
+		gic_v3_kvm_info.maint_irq = -1;
+	else
+		gic_v3_kvm_info.maint_irq = irq;
+
+	if (of_property_read_u32(node, "#redistributor-regions",
+				 &gicv_idx))
+		gicv_idx = 1;
+
+	gicv_idx += 3;	/* Also skip GICD, GICC, GICH */
+	ret = of_address_to_resource(node, gicv_idx, &r);
+	if (!ret) {
+		if (!PAGE_ALIGNED(r.start))
+			pr_warn("GICV physical address 0x%llx not page aligned\n",
+				(unsigned long long)r.start);
+		else if (!PAGE_ALIGNED(resource_size(&r)))
+			pr_warn("GICV size 0x%llx not a multiple of page size 0x%lx\n",
+				(unsigned long long)resource_size(&r),
+				PAGE_SIZE);
+		else {
+			gic_v3_kvm_info.vcpu_base = r.start;
+			gic_v3_kvm_info.vcpu_size = resource_size(&r);
+		}
+	}
+
+	gic_set_kvm_info(&gic_v3_kvm_info);
+}
+
 static int __init gic_of_init(struct device_node *node, struct device_node *parent)
 {
 	void __iomem *dist_base;
@@ -908,6 +949,8 @@ static int __init gic_of_init(struct device_node *node, struct device_node *pare
 	gic_cpu_init();
 	gic_cpu_pm_init();
 
+	gic_of_setup_kvm_info(node);
+
 	return 0;
 
 out_free:
diff --git a/include/linux/irqchip/arm-gic-common.h b/include/linux/irqchip/arm-gic-common.h
index 30972b1..bfb10d0 100644
--- a/include/linux/irqchip/arm-gic-common.h
+++ b/include/linux/irqchip/arm-gic-common.h
@@ -14,6 +14,7 @@
 
 enum gic_type {
 	GIC_V2,
+	GIC_V3,
 };
 
 struct gic_kvm_info {
-- 
1.9.1



From julien.grall at arm.com  Mon Feb  8 08:47:27 2016
From: julien.grall at arm.com (Julien Grall)
Date: Mon,  8 Feb 2016 16:47:27 +0000
Subject: [PATCH 3/5] irqchip/gic-v2: Parse and export virtual GIC information
In-Reply-To: <1454950049-741-1-git-send-email-julien.grall@arm.com>
References: <1454950049-741-1-git-send-email-julien.grall@arm.com>
Message-ID: <1454950049-741-4-git-send-email-julien.grall@arm.com>

For now, the firmware tables are parsed 2 times: once in the GIC
drivers, the other timer when initializing the vGIC. It means code
duplication and make more tedious to add the support for another
firmware table (like ACPI).

Introduce a new structure and set of helpers to get/set the virtual GIC
information. Also fill up the structure for GICv2.

Signed-off-by: Julien Grall <julien.grall at arm.com>
---

Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier at arm.com>

 drivers/irqchip/irq-gic-common.c       | 13 ++++++
 drivers/irqchip/irq-gic-common.h       |  3 ++
 drivers/irqchip/irq-gic.c              | 78 +++++++++++++++++++++++++++++++++-
 include/linux/irqchip/arm-gic-common.h | 34 +++++++++++++++
 4 files changed, 127 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/irqchip/arm-gic-common.h

diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
index f174ce0..704caf4 100644
--- a/drivers/irqchip/irq-gic-common.c
+++ b/drivers/irqchip/irq-gic-common.c
@@ -21,6 +21,19 @@
 
 #include "irq-gic-common.h"
 
+static const struct gic_kvm_info *gic_kvm_info;
+
+const struct gic_kvm_info *gic_get_kvm_info(void)
+{
+	return gic_kvm_info;
+}
+
+void gic_set_kvm_info(const struct gic_kvm_info *info)
+{
+	WARN(gic_kvm_info != NULL, "gic_kvm_info already set\n");
+	gic_kvm_info = info;
+}
+
 void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
 		void *data)
 {
diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
index fff697d..205e5fd 100644
--- a/drivers/irqchip/irq-gic-common.h
+++ b/drivers/irqchip/irq-gic-common.h
@@ -19,6 +19,7 @@
 
 #include <linux/of.h>
 #include <linux/irqdomain.h>
+#include <linux/irqchip/arm-gic-common.h>
 
 struct gic_quirk {
 	const char *desc;
@@ -35,4 +36,6 @@ void gic_cpu_config(void __iomem *base, void (*sync_access)(void));
 void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
 		void *data);
 
+void gic_set_kvm_info(const struct gic_kvm_info *info);
+
 #endif /* _IRQ_GIC_COMMON_H */
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 911758c..d3a09a4 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -102,6 +102,8 @@ static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;
 
 static struct gic_chip_data gic_data[CONFIG_ARM_GIC_MAX_NR] __read_mostly;
 
+static struct gic_kvm_info gic_v2_kvm_info;
+
 #ifdef CONFIG_GIC_NON_BANKED
 static void __iomem *gic_get_percpu_base(union gic_base *base)
 {
@@ -1190,6 +1192,44 @@ static bool gic_check_eoimode(struct device_node *node, void __iomem **base)
 	return true;
 }
 
+static void __init gic_of_setup_kvm_info(struct device_node *node)
+{
+	int ret;
+	struct resource r;
+	unsigned int irq;
+
+	gic_v2_kvm_info.type = GIC_V2;
+
+	irq = irq_of_parse_and_map(node, 0);
+	if (!irq)
+		gic_v2_kvm_info.maint_irq = -1;
+	else
+		gic_v2_kvm_info.maint_irq = irq;
+
+	ret = of_address_to_resource(node, 2, &r);
+	if (!ret) {
+		gic_v2_kvm_info.vctrl_base = r.start;
+		gic_v2_kvm_info.vctrl_size = resource_size(&r);
+	}
+
+	ret = of_address_to_resource(node, 3, &r);
+	if (!ret) {
+		if (!PAGE_ALIGNED(r.start))
+			pr_warn("GICV physical address 0x%llx not page aligned\n",
+				(unsigned long long)r.start);
+		else if (!PAGE_ALIGNED(resource_size(&r)))
+			pr_warn("GICV size 0x%llx not a multiple of page size 0x%lx\n",
+				(unsigned long long)resource_size(&r),
+				PAGE_SIZE);
+		else {
+			gic_v2_kvm_info.vcpu_base = r.start;
+			gic_v2_kvm_info.vcpu_size = resource_size(&r);
+		}
+	}
+
+	gic_set_kvm_info(&gic_v2_kvm_info);
+}
+
 int __init
 gic_of_init(struct device_node *node, struct device_node *parent)
 {
@@ -1219,8 +1259,10 @@ gic_of_init(struct device_node *node, struct device_node *parent)
 
 	__gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset,
 			 &node->fwnode);
-	if (!gic_cnt)
+	if (!gic_cnt) {
 		gic_init_physaddr(node);
+		gic_of_setup_kvm_info(node);
+	}
 
 	if (parent) {
 		irq = irq_of_parse_and_map(node, 0);
@@ -1247,6 +1289,32 @@ IRQCHIP_DECLARE(pl390, "arm,pl390", gic_of_init);
 
 #ifdef CONFIG_ACPI
 static phys_addr_t cpu_phy_base __initdata;
+static struct
+{
+	u32 maint_irq;
+	int maint_irq_mode;
+	phys_addr_t vctrl_base;
+	phys_addr_t vcpu_base;
+} acpi_data __initdata;
+
+static void __init gic_acpi_setup_kvm_info(void)
+{
+	gic_v2_kvm_info.type = GIC_V2;
+
+	gic_v2_kvm_info.maint_irq = acpi_register_gsi(NULL,
+						      acpi_data.maint_irq,
+						      acpi_data.maint_irq_mode,
+						      ACPI_ACTIVE_HIGH);
+	gic_v2_kvm_info.vctrl_base = acpi_data.vctrl_base;
+	if (gic_v2_kvm_info.vctrl_base)
+		gic_v2_kvm_info.vctrl_size = SZ_8K;
+
+	gic_v2_kvm_info.vcpu_base = acpi_data.vcpu_base;
+	if (gic_v2_kvm_info.vcpu_base)
+		gic_v2_kvm_info.vcpu_size = SZ_8K;
+
+	gic_set_kvm_info(&gic_v2_kvm_info);
+}
 
 static int __init
 gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
@@ -1270,6 +1338,12 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
 		return -EINVAL;
 
 	cpu_phy_base = gic_cpu_base;
+	acpi_data.maint_irq = processor->vgic_interrupt;
+	acpi_data.maint_irq_mode = (processor->flags & ACPI_MADT_VGIC_IRQ_MODE) ?
+				    ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
+	acpi_data.vctrl_base = processor->gich_base_address;
+	acpi_data.vcpu_base = processor->gicv_base_address;
+
 	cpu_base_assigned = 1;
 	return 0;
 }
@@ -1357,6 +1431,8 @@ static int __init gic_v2_acpi_init(struct acpi_subtable_header *header,
 	if (IS_ENABLED(CONFIG_ARM_GIC_V2M))
 		gicv2m_init(NULL, gic_data[0].domain);
 
+	gic_acpi_setup_kvm_info();
+
 	return 0;
 }
 IRQCHIP_ACPI_DECLARE(gic_v2, ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR,
diff --git a/include/linux/irqchip/arm-gic-common.h b/include/linux/irqchip/arm-gic-common.h
new file mode 100644
index 0000000..30972b1
--- /dev/null
+++ b/include/linux/irqchip/arm-gic-common.h
@@ -0,0 +1,34 @@
+/*
+ * include/linux/irqchip/arm-gic-common.h
+ *
+ * Copyright (C) 2016 ARM Limited, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __LINUX_IRQCHIP_ARM_GIC_COMMON_H
+#define __LINUX_IRQCHIP_ARM_GIC_COMMON_H
+
+#include <linux/types.h>
+
+enum gic_type {
+	GIC_V2,
+};
+
+struct gic_kvm_info {
+	/* GIC type */
+	enum gic_type	type;
+	/* Physical address & size of virtual cpu interface */
+	phys_addr_t	vcpu_base;
+	resource_size_t	vcpu_size;
+	/* Interrupt number */
+	int		maint_irq;
+	/* Physical address & size of virtual control interface */
+	phys_addr_t	vctrl_base;
+	resource_size_t	vctrl_size;
+};
+
+const struct gic_kvm_info *gic_get_kvm_info(void);
+
+#endif /* __LINUX_IRQCHIP_ARM_GIC_COMMON_H */
-- 
1.9.1



From julien.grall at arm.com  Mon Feb  8 08:47:24 2016
From: julien.grall at arm.com (Julien Grall)
Date: Mon,  8 Feb 2016 16:47:24 +0000
Subject: [PATCH 0/5] arm64: Add support of KVM with ACPI
Message-ID: <1454950049-741-1-git-send-email-julien.grall@arm.com>

Hello,

This small series allows an ARM64 ACPI based platform to use KVM.

Currently the KVM code has to parse the firmware table to get the necessary
information to setup the virtual timer and virtual GIC.

However the parsing of those tables are already done in the GIC and arch
timer drivers.

This patch series introduces different helpers to retrieve the information
from different drivers avoiding to duplicate the parsing code.

Note there is patch series ([1] and [2]) adding support of KVM on ACPI,
although the approach chosen is completely different. The code to parse
the firmware tables are duplicated which I think make more complex to
support new firmware tables.

Regards,

[1] https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018482.html
[2] https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018355.html

Julien Grall (5):
  KVM: arm/arm64: arch_timer: Gather KVM specific information in a
    structure
  KVM: arm/arm64: arch_timer: Rely on the arch timer to parse the
    firmware tables
  irqchip/gic-v2: Parse and export virtual GIC information
  irqchip/gic-v3: Parse and export virtual GIC information
  KVM: arm/arm64: vgic: Rely on the GIC driver to parse the firmware
    tables

 drivers/clocksource/arm_arch_timer.c   | 11 +++--
 drivers/irqchip/irq-gic-common.c       | 13 ++++++
 drivers/irqchip/irq-gic-common.h       |  3 ++
 drivers/irqchip/irq-gic-v3.c           | 43 +++++++++++++++++++
 drivers/irqchip/irq-gic.c              | 78 +++++++++++++++++++++++++++++++++-
 include/clocksource/arm_arch_timer.h   | 13 +++---
 include/kvm/arm_vgic.h                 |  7 +--
 include/linux/irqchip/arm-gic-common.h | 35 +++++++++++++++
 virt/kvm/arm/arch_timer.c              | 39 +++++------------
 virt/kvm/arm/vgic-v2.c                 | 66 ++++++++++------------------
 virt/kvm/arm/vgic-v3.c                 | 45 ++++++--------------
 virt/kvm/arm/vgic.c                    | 50 ++++++++++++----------
 12 files changed, 262 insertions(+), 141 deletions(-)
 create mode 100644 include/linux/irqchip/arm-gic-common.h

-- 
1.9.1



From julien.grall at arm.com  Mon Feb  8 08:47:26 2016
From: julien.grall at arm.com (Julien Grall)
Date: Mon,  8 Feb 2016 16:47:26 +0000
Subject: [PATCH 2/5] KVM: arm/arm64: arch_timer: Rely on the arch timer to
 parse the firmware tables
In-Reply-To: <1454950049-741-1-git-send-email-julien.grall@arm.com>
References: <1454950049-741-1-git-send-email-julien.grall@arm.com>
Message-ID: <1454950049-741-3-git-send-email-julien.grall@arm.com>

The firmware table is currently parsed by the virt timer code in order
to retrieve the virtual interrupt. However, this is already done by the
arch timer driver and therefore make the parsing code duplicated twice.

Introduce an helper to get the virtual interrupt number and use it in
the virtual timer code.

With this changes, the support for ACPI is coming free.

Signed-off-by: Julien Grall <julien.grall at arm.com>
---
Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Christoffer Dall <christoffer.dall at linaro.org>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: Gleb Natapov <gleb at kernel.org>
Cc: Paolo Bonzini <pbonzini at redhat.com>

 drivers/clocksource/arm_arch_timer.c |  2 ++
 include/clocksource/arm_arch_timer.h |  1 +
 virt/kvm/arm/arch_timer.c            | 33 +++++++--------------------------
 3 files changed, 10 insertions(+), 26 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 6eb2c5d..3cdbefd 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -451,6 +451,8 @@ static struct arch_timer_kvm_info arch_timer_kvm_info;
 
 struct arch_timer_kvm_info *arch_timer_get_kvm_info(void)
 {
+	arch_timer_kvm_info.virtual_irq = arch_timer_ppi[VIRT_PPI];
+
 	return &arch_timer_kvm_info;
 }
 
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index 4d487f8..8890552 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -51,6 +51,7 @@ enum arch_timer_reg {
 
 struct arch_timer_kvm_info {
 	struct timecounter timecounter;
+	int virtual_irq;
 };
 
 #ifdef CONFIG_ARM_ARCH_TIMER
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index a669c6a..e4de549 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -17,7 +17,6 @@
  */
 
 #include <linux/cpu.h>
-#include <linux/of_irq.h>
 #include <linux/kvm.h>
 #include <linux/kvm_host.h>
 #include <linux/interrupt.h>
@@ -375,45 +374,28 @@ static struct notifier_block kvm_timer_cpu_nb = {
 	.notifier_call = kvm_timer_cpu_notify,
 };
 
-static const struct of_device_id arch_timer_of_match[] = {
-	{ .compatible	= "arm,armv7-timer",	},
-	{ .compatible	= "arm,armv8-timer",	},
-	{},
-};
-
 int kvm_timer_hyp_init(void)
 {
-	struct device_node *np;
-	unsigned int ppi;
 	struct arch_timer_kvm_info *info;
 	int err;
 
 	info = arch_timer_get_kvm_info();
 	timecounter = &info->timecounter;
 
-	np = of_find_matching_node(NULL, arch_timer_of_match);
-	if (!np) {
-		kvm_err("kvm_arch_timer: can't find DT node\n");
+	host_vtimer_irq = info->virtual_irq;
+	if (host_vtimer_irq <= 0) {
+		kvm_err("kvm_arch_timer: can't find virtual timer info or config virtual timer interrupt\n");
 		return -ENODEV;
 	}
 
-	ppi = irq_of_parse_and_map(np, 2);
-	if (!ppi) {
-		kvm_err("kvm_arch_timer: no virtual timer interrupt\n");
-		err = -EINVAL;
-		goto out;
-	}
-
-	err = request_percpu_irq(ppi, kvm_arch_timer_handler,
+	err = request_percpu_irq(host_vtimer_irq, kvm_arch_timer_handler,
 				 "kvm guest timer", kvm_get_running_vcpus());
 	if (err) {
 		kvm_err("kvm_arch_timer: can't request interrupt %d (%d)\n",
-			ppi, err);
+			host_vtimer_irq, err);
 		goto out;
 	}
 
-	host_vtimer_irq = ppi;
-
 	err = __register_cpu_notifier(&kvm_timer_cpu_nb);
 	if (err) {
 		kvm_err("Cannot register timer CPU notifier\n");
@@ -426,14 +408,13 @@ int kvm_timer_hyp_init(void)
 		goto out_free;
 	}
 
-	kvm_info("%s IRQ%d\n", np->name, ppi);
+	kvm_info("vtimer IRQ%d\n", host_vtimer_irq);
 	on_each_cpu(kvm_timer_init_interrupt, NULL, 1);
 
 	goto out;
 out_free:
-	free_percpu_irq(ppi, kvm_get_running_vcpus());
+	free_percpu_irq(host_vtimer_irq, kvm_get_running_vcpus());
 out:
-	of_node_put(np);
 	return err;
 }
 
-- 
1.9.1



From julien.grall at arm.com  Mon Feb  8 08:47:25 2016
From: julien.grall at arm.com (Julien Grall)
Date: Mon,  8 Feb 2016 16:47:25 +0000
Subject: [PATCH 1/5] KVM: arm/arm64: arch_timer: Gather KVM specific
 information in a structure
In-Reply-To: <1454950049-741-1-git-send-email-julien.grall@arm.com>
References: <1454950049-741-1-git-send-email-julien.grall@arm.com>
Message-ID: <1454950049-741-2-git-send-email-julien.grall@arm.com>

Introduce a structure which are filled up by the arch timer driver and
used by the virtual timer in KVM.

The first member of this structure will be the timecounter. More members
will be added later.

This is also dropping arch_timer_get_timecounter as it was only used by
the KVM code. Furthermore, a stub for the new helper hasn't been
introduced because KVM is requiring the arch timer for both ARM64 and
ARM32.

Signed-off-by: Julien Grall <julien.grall at arm.com>
---

Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Christoffer Dall <christoffer.dall at linaro.org>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: Gleb Natapov <gleb at kernel.org>
Cc: Paolo Bonzini <pbonzini at redhat.com>

 drivers/clocksource/arm_arch_timer.c |  9 +++++----
 include/clocksource/arm_arch_timer.h | 12 ++++++------
 virt/kvm/arm/arch_timer.c            |  6 +++---
 3 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index c64d543..6eb2c5d 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -447,11 +447,11 @@ static struct cyclecounter cyclecounter = {
 	.mask	= CLOCKSOURCE_MASK(56),
 };
 
-static struct timecounter timecounter;
+static struct arch_timer_kvm_info arch_timer_kvm_info;
 
-struct timecounter *arch_timer_get_timecounter(void)
+struct arch_timer_kvm_info *arch_timer_get_kvm_info(void)
 {
-	return &timecounter;
+	return &arch_timer_kvm_info;
 }
 
 static void __init arch_counter_register(unsigned type)
@@ -479,7 +479,8 @@ static void __init arch_counter_register(unsigned type)
 	clocksource_register_hz(&clocksource_counter, arch_timer_rate);
 	cyclecounter.mult = clocksource_counter.mult;
 	cyclecounter.shift = clocksource_counter.shift;
-	timecounter_init(&timecounter, &cyclecounter, start_count);
+	timecounter_init(&arch_timer_kvm_info.timecounter,
+			 &cyclecounter, start_count);
 
 	/* 56 bits minimum, so we assume worst case rollover */
 	sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate);
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index 25d0914..4d487f8 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -49,11 +49,16 @@ enum arch_timer_reg {
 
 #define ARCH_TIMER_EVT_STREAM_FREQ	10000	/* 100us */
 
+struct arch_timer_kvm_info {
+	struct timecounter timecounter;
+};
+
 #ifdef CONFIG_ARM_ARCH_TIMER
 
 extern u32 arch_timer_get_rate(void);
 extern u64 (*arch_timer_read_counter)(void);
-extern struct timecounter *arch_timer_get_timecounter(void);
+
+extern struct arch_timer_kvm_info *arch_timer_get_kvm_info(void);
 
 #else
 
@@ -67,11 +72,6 @@ static inline u64 arch_timer_read_counter(void)
 	return 0;
 }
 
-static inline struct timecounter *arch_timer_get_timecounter(void)
-{
-	return NULL;
-}
-
 #endif
 
 #endif
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 69bca18..a669c6a 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -385,11 +385,11 @@ int kvm_timer_hyp_init(void)
 {
 	struct device_node *np;
 	unsigned int ppi;
+	struct arch_timer_kvm_info *info;
 	int err;
 
-	timecounter = arch_timer_get_timecounter();
-	if (!timecounter)
-		return -ENODEV;
+	info = arch_timer_get_kvm_info();
+	timecounter = &info->timecounter;
 
 	np = of_find_matching_node(NULL, arch_timer_of_match);
 	if (!np) {
-- 
1.9.1



From julien.grall at arm.com  Mon Feb  8 08:47:29 2016
From: julien.grall at arm.com (Julien Grall)
Date: Mon,  8 Feb 2016 16:47:29 +0000
Subject: [PATCH 5/5] KVM: arm/arm64: vgic: Rely on the GIC driver to parse the
 firmware tables
In-Reply-To: <1454950049-741-1-git-send-email-julien.grall@arm.com>
References: <1454950049-741-1-git-send-email-julien.grall@arm.com>
Message-ID: <1454950049-741-6-git-send-email-julien.grall@arm.com>

For now, the firmware tables are parsed 2 times: once in the GIC
drivers, the other time when initializing the vGIC. It means code
duplication and make more tedious to add the support for another
firmware table (like ACPI).

Use the recently introduced helper gic_get_kvm_info() to retrieve
information about the virtual GIC.

With this change, the virtual GIC becomes agnostic to the firmware
table and KVM will be able to initialize the vGIC on ACPI.

Signed-off-by: Julien Grall <julien.grall at arm.com>
---
Cc: Christoffer Dall <christoffer.dall at linaro.org>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: Gleb Natapov <gleb at kernel.org>
Cc: Paolo Bonzini <pbonzini at redhat.com>

 include/kvm/arm_vgic.h |  7 +++---
 virt/kvm/arm/vgic-v2.c | 66 ++++++++++++++++++--------------------------------
 virt/kvm/arm/vgic-v3.c | 45 ++++++++++------------------------
 virt/kvm/arm/vgic.c    | 50 ++++++++++++++++++++------------------
 4 files changed, 67 insertions(+), 101 deletions(-)

diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 13a3d53..ed62772 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -25,6 +25,7 @@
 #include <linux/spinlock.h>
 #include <linux/types.h>
 #include <kvm/iodev.h>
+#include <linux/irqchip/arm-gic-common.h>
 
 #define VGIC_NR_IRQS_LEGACY	256
 #define VGIC_NR_SGIS		16
@@ -357,15 +358,15 @@ bool kvm_vgic_map_is_active(struct kvm_vcpu *vcpu, struct irq_phys_map *map);
 #define vgic_initialized(k)	(!!((k)->arch.vgic.nr_cpus))
 #define vgic_ready(k)		((k)->arch.vgic.ready)
 
-int vgic_v2_probe(struct device_node *vgic_node,
+int vgic_v2_probe(const struct gic_kvm_info *gic_kvm_info,
 		  const struct vgic_ops **ops,
 		  const struct vgic_params **params);
 #ifdef CONFIG_KVM_ARM_VGIC_V3
-int vgic_v3_probe(struct device_node *vgic_node,
+int vgic_v3_probe(const struct gic_kvm_info *gic_kvm_info,
 		  const struct vgic_ops **ops,
 		  const struct vgic_params **params);
 #else
-static inline int vgic_v3_probe(struct device_node *vgic_node,
+static inline int vgic_v3_probe(const struct gic_kvm_info *gic_kvm_info,
 				const struct vgic_ops **ops,
 				const struct vgic_params **params)
 {
diff --git a/virt/kvm/arm/vgic-v2.c b/virt/kvm/arm/vgic-v2.c
index ff02f08..2598a05 100644
--- a/virt/kvm/arm/vgic-v2.c
+++ b/virt/kvm/arm/vgic-v2.c
@@ -20,9 +20,6 @@
 #include <linux/kvm_host.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
 
 #include <linux/irqchip/arm-gic.h>
 
@@ -177,38 +174,37 @@ static const struct vgic_ops vgic_v2_ops = {
 static struct vgic_params vgic_v2_params;
 
 /**
- * vgic_v2_probe - probe for a GICv2 compatible interrupt controller in DT
- * @node:	pointer to the DT node
- * @ops: 	address of a pointer to the GICv2 operations
- * @params:	address of a pointer to HW-specific parameters
+ * vgic_v2_probe - probe for a GICv2 compatible interrupt controller
+ * @gic_kvm_info:	pointer to the GIC description
+ * @ops:		address of a pointer to the GICv2 operations
+ * @params:		address of a pointer to HW-specific parameters
  *
  * Returns 0 if a GICv2 has been found, with the low level operations
  * in *ops and the HW parameters in *params. Returns an error code
  * otherwise.
  */
-int vgic_v2_probe(struct device_node *vgic_node,
-		  const struct vgic_ops **ops,
-		  const struct vgic_params **params)
+int vgic_v2_probe(const struct gic_kvm_info *gic_kvm_info,
+		   const struct vgic_ops **ops,
+		   const struct vgic_params **params)
 {
 	int ret;
-	struct resource vctrl_res;
-	struct resource vcpu_res;
 	struct vgic_params *vgic = &vgic_v2_params;
 
-	vgic->maint_irq = irq_of_parse_and_map(vgic_node, 0);
-	if (!vgic->maint_irq) {
-		kvm_err("error getting vgic maintenance irq from DT\n");
+	if (gic_kvm_info->maint_irq < 0) {
+		kvm_err("error getting vgic maintenance irq\n");
 		ret = -ENXIO;
 		goto out;
 	}
+	vgic->maint_irq = gic_kvm_info->maint_irq;
 
-	ret = of_address_to_resource(vgic_node, 2, &vctrl_res);
-	if (ret) {
-		kvm_err("Cannot obtain GICH resource\n");
+	if (!gic_kvm_info->vctrl_size) {
+		kvm_err("GICH not present in the firmware table\n");
+		ret = -ENXIO;
 		goto out;
 	}
 
-	vgic->vctrl_base = of_iomap(vgic_node, 2);
+	vgic->vctrl_base = ioremap(gic_kvm_info->vctrl_base,
+				   gic_kvm_info->vctrl_size);
 	if (!vgic->vctrl_base) {
 		kvm_err("Cannot ioremap GICH\n");
 		ret = -ENOMEM;
@@ -219,30 +215,15 @@ int vgic_v2_probe(struct device_node *vgic_node,
 	vgic->nr_lr = (vgic->nr_lr & 0x3f) + 1;
 
 	ret = create_hyp_io_mappings(vgic->vctrl_base,
-				     vgic->vctrl_base + resource_size(&vctrl_res),
-				     vctrl_res.start);
+				     vgic->vctrl_base + gic_kvm_info->vctrl_size,
+				     gic_kvm_info->vctrl_base);
 	if (ret) {
-		kvm_err("Cannot map VCTRL into hyp\n");
-		goto out_unmap;
-	}
-
-	if (of_address_to_resource(vgic_node, 3, &vcpu_res)) {
-		kvm_err("Cannot obtain GICV resource\n");
-		ret = -ENXIO;
-		goto out_unmap;
-	}
-
-	if (!PAGE_ALIGNED(vcpu_res.start)) {
-		kvm_err("GICV physical address 0x%llx not page aligned\n",
-			(unsigned long long)vcpu_res.start);
-		ret = -ENXIO;
+		kvm_err("Cannot map VCTLR into hyp\n");
 		goto out_unmap;
 	}
 
-	if (!PAGE_ALIGNED(resource_size(&vcpu_res))) {
-		kvm_err("GICV size 0x%llx not a multiple of page size 0x%lx\n",
-			(unsigned long long)resource_size(&vcpu_res),
-			PAGE_SIZE);
+	if (!gic_kvm_info->vcpu_size) {
+		kvm_err("GICV not present in the firmware table\n");
 		ret = -ENXIO;
 		goto out_unmap;
 	}
@@ -250,10 +231,10 @@ int vgic_v2_probe(struct device_node *vgic_node,
 	vgic->can_emulate_gicv2 = true;
 	kvm_register_device_ops(&kvm_arm_vgic_v2_ops, KVM_DEV_TYPE_ARM_VGIC_V2);
 
-	vgic->vcpu_base = vcpu_res.start;
+	vgic->vcpu_base = gic_kvm_info->vcpu_base;
 
-	kvm_info("%s@%llx IRQ%d\n", vgic_node->name,
-		 vctrl_res.start, vgic->maint_irq);
+	kvm_info("GICH base=0x%llx, GICV base=0x%llx, IRQ=%d\n",
+		 gic_kvm_info->vctrl_base, vgic->vcpu_base, vgic->maint_irq);
 
 	vgic->type = VGIC_V2;
 	vgic->max_gic_vcpus = VGIC_V2_MAX_CPUS;
@@ -264,6 +245,5 @@ int vgic_v2_probe(struct device_node *vgic_node,
 out_unmap:
 	iounmap(vgic->vctrl_base);
 out:
-	of_node_put(vgic_node);
 	return ret;
 }
diff --git a/virt/kvm/arm/vgic-v3.c b/virt/kvm/arm/vgic-v3.c
index 453eafd..f49b661 100644
--- a/virt/kvm/arm/vgic-v3.c
+++ b/virt/kvm/arm/vgic-v3.c
@@ -20,11 +20,9 @@
 #include <linux/kvm_host.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
 
 #include <linux/irqchip/arm-gic-v3.h>
+#include <linux/irqchip/arm-gic-common.h>
 
 #include <asm/kvm_emulate.h>
 #include <asm/kvm_arm.h>
@@ -217,30 +215,28 @@ static const struct vgic_ops vgic_v3_ops = {
 static struct vgic_params vgic_v3_params;
 
 /**
- * vgic_v3_probe - probe for a GICv3 compatible interrupt controller in DT
- * @node:	pointer to the DT node
- * @ops: 	address of a pointer to the GICv3 operations
- * @params:	address of a pointer to HW-specific parameters
+ * vgic_v3_probe - probe for a GICv3 compatible interrupt controller
+ * @gic_kvm_info:	pointer to the GIC description
+ * @ops:		address of a pointer to the GICv3 operations
+ * @params:		address of a pointer to HW-specific parameters
  *
  * Returns 0 if a GICv3 has been found, with the low level operations
  * in *ops and the HW parameters in *params. Returns an error code
  * otherwise.
  */
-int vgic_v3_probe(struct device_node *vgic_node,
+int vgic_v3_probe(const struct gic_kvm_info *gic_kvm_info,
 		  const struct vgic_ops **ops,
 		  const struct vgic_params **params)
 {
 	int ret = 0;
-	u32 gicv_idx;
-	struct resource vcpu_res;
 	struct vgic_params *vgic = &vgic_v3_params;
 
-	vgic->maint_irq = irq_of_parse_and_map(vgic_node, 0);
-	if (!vgic->maint_irq) {
-		kvm_err("error getting vgic maintenance irq from DT\n");
+	if (gic_kvm_info->maint_irq < 0) {
+		kvm_err("error getting vgic maintenance irq\n");
 		ret = -ENXIO;
 		goto out;
 	}
+	vgic->maint_irq = gic_kvm_info->maint_irq;
 
 	ich_vtr_el2 = kvm_call_hyp(__vgic_v3_get_ich_vtr_el2);
 
@@ -251,24 +247,11 @@ int vgic_v3_probe(struct device_node *vgic_node,
 	vgic->nr_lr = (ich_vtr_el2 & 0xf) + 1;
 	vgic->can_emulate_gicv2 = false;
 
-	if (of_property_read_u32(vgic_node, "#redistributor-regions", &gicv_idx))
-		gicv_idx = 1;
-
-	gicv_idx += 3; /* Also skip GICD, GICC, GICH */
-	if (of_address_to_resource(vgic_node, gicv_idx, &vcpu_res)) {
+	if (!gic_kvm_info->vcpu_size) {
 		kvm_info("GICv3: no GICV resource entry\n");
 		vgic->vcpu_base = 0;
-	} else if (!PAGE_ALIGNED(vcpu_res.start)) {
-		pr_warn("GICV physical address 0x%llx not page aligned\n",
-			(unsigned long long)vcpu_res.start);
-		vgic->vcpu_base = 0;
-	} else if (!PAGE_ALIGNED(resource_size(&vcpu_res))) {
-		pr_warn("GICV size 0x%llx not a multiple of page size 0x%lx\n",
-			(unsigned long long)resource_size(&vcpu_res),
-			PAGE_SIZE);
-		vgic->vcpu_base = 0;
 	} else {
-		vgic->vcpu_base = vcpu_res.start;
+		vgic->vcpu_base = gic_kvm_info->vcpu_base;
 		vgic->can_emulate_gicv2 = true;
 		kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
 					KVM_DEV_TYPE_ARM_VGIC_V2);
@@ -281,13 +264,11 @@ int vgic_v3_probe(struct device_node *vgic_node,
 	vgic->type = VGIC_V3;
 	vgic->max_gic_vcpus = VGIC_V3_MAX_CPUS;
 
-	kvm_info("%s@%llx IRQ%d\n", vgic_node->name,
-		 vcpu_res.start, vgic->maint_irq);
-
+	kvm_info("GICV base=0x%llx, IRQ=%d\n",
+		 vgic->vcpu_base, vgic->maint_irq);
 	*ops = &vgic_v3_ops;
 	*params = vgic;
 
 out:
-	of_node_put(vgic_node);
 	return ret;
 }
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 043032c..748cb2f 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -21,9 +21,7 @@
 #include <linux/kvm_host.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
+#include <linux/irq.h>
 #include <linux/rculist.h>
 #include <linux/uaccess.h>
 
@@ -33,6 +31,7 @@
 #include <trace/events/kvm.h>
 #include <asm/kvm.h>
 #include <kvm/iodev.h>
+#include <linux/irqchip/arm-gic-common.h>
 
 #define CREATE_TRACE_POINTS
 #include "trace.h"
@@ -2389,33 +2388,38 @@ static struct notifier_block vgic_cpu_nb = {
 	.notifier_call = vgic_cpu_notify,
 };
 
-static const struct of_device_id vgic_ids[] = {
-	{ .compatible = "arm,cortex-a15-gic",	.data = vgic_v2_probe, },
-	{ .compatible = "arm,cortex-a7-gic",	.data = vgic_v2_probe, },
-	{ .compatible = "arm,gic-400",		.data = vgic_v2_probe, },
-	{ .compatible = "arm,gic-v3",		.data = vgic_v3_probe, },
-	{},
-};
-
-int kvm_vgic_hyp_init(void)
+static int kvm_vgic_probe(void)
 {
-	const struct of_device_id *matched_id;
-	const int (*vgic_probe)(struct device_node *,const struct vgic_ops **,
-				const struct vgic_params **);
-	struct device_node *vgic_node;
+	const struct gic_kvm_info *gic_kvm_info;
 	int ret;
 
-	vgic_node = of_find_matching_node_and_match(NULL,
-						    vgic_ids, &matched_id);
-	if (!vgic_node) {
-		kvm_err("error: no compatible GIC node found\n");
+	gic_kvm_info = gic_get_kvm_info();
+	if (!gic_kvm_info)
 		return -ENODEV;
+
+	switch (gic_kvm_info->type) {
+	case GIC_V2:
+		ret = vgic_v2_probe(gic_kvm_info, &vgic_ops, &vgic);
+		break;
+	case GIC_V3:
+		ret = vgic_v3_probe(gic_kvm_info, &vgic_ops, &vgic);
+		break;
+	default:
+		ret = -ENODEV;
 	}
 
-	vgic_probe = matched_id->data;
-	ret = vgic_probe(vgic_node, &vgic_ops, &vgic);
-	if (ret)
+	return ret;
+}
+
+int kvm_vgic_hyp_init(void)
+{
+	int ret;
+
+	ret = kvm_vgic_probe();
+	if (ret) {
+		kvm_err("error: KVM vGIC probing failed\n");
 		return ret;
+	}
 
 	ret = request_percpu_irq(vgic->maint_irq, vgic_maintenance_handler,
 				 "vgic", kvm_get_running_vcpus());
-- 
1.9.1



From stefano.stabellini at eu.citrix.com  Mon Feb  8 08:59:10 2016
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 8 Feb 2016 16:59:10 +0000
Subject: [PATCH v2] xen/arm: correctly handle DMA mapping of compound pages
In-Reply-To: <1454947330-29993-1-git-send-email-ian.campbell@citrix.com>
References: <1454947330-29993-1-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.02.1602081656120.27008@kaball.uk.xensource.com>

On Mon, 8 Feb 2016, Ian Campbell wrote:
> Currently xen_dma_map_page concludes that DMA to anything other than
> the head page of a compound page must be foreign, since the PFN of the
> page is that of the head.
> 
> Fix the check to instead consider the whole of a compound page to be
> local if the PFN of the head passes the 1:1 check.
> 
> We can never see a compound page which is a mixture of foreign and
> local sub-pages.
> 
> The comment already correctly described the intention, but fixup the
> spelling and some grammar.
> 
> This fixes the various SSH protocol errors which we have been seeing
> on the cubietrucks in our automated test infrastructure.
> 
> This has been broken since commit 3567258d281b ("xen/arm: use
> hypercall to flush caches in map_page"), which was in v3.19-rc1.
> 
> NB arch/arm64/.../xen/page-coherent.h also includes this file.
> 
> Signed-off-by: Ian Campbell <ian.campbell at citrix.com>
> Cc: xen-devel at lists.xenproject.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: stable at vger.kernel.org # v3.19+

Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>

I'll add it to my queue.


> v2: Placate checkpatch
>     Handle 64K pages
>     Add some ()s
> ---
>  arch/arm/include/asm/xen/page-coherent.h | 21 ++++++++++++++-------
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
> index 0375c8c..9408a99 100644
> --- a/arch/arm/include/asm/xen/page-coherent.h
> +++ b/arch/arm/include/asm/xen/page-coherent.h
> @@ -35,14 +35,21 @@ static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
>  	     dma_addr_t dev_addr, unsigned long offset, size_t size,
>  	     enum dma_data_direction dir, struct dma_attrs *attrs)
>  {
> -	bool local = XEN_PFN_DOWN(dev_addr) == page_to_xen_pfn(page);
> +	unsigned long page_pfn = page_to_xen_pfn(page);
> +	unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
> +	unsigned long compound_pages =
> +		(1<<compound_order(page)) * XEN_PFN_PER_PAGE;
> +	bool local = (page_pfn <= dev_pfn) &&
> +		(dev_pfn - page_pfn < compound_pages);
> +
>  	/*
> -	 * Dom0 is mapped 1:1, while the Linux page can be spanned accross
> -	 * multiple Xen page, it's not possible to have a mix of local and
> -	 * foreign Xen page. So if the first xen_pfn == mfn the page is local
> -	 * otherwise it's a foreign page grant-mapped in dom0. If the page is
> -	 * local we can safely call the native dma_ops function, otherwise we
> -	 * call the xen specific function.
> +	 * Dom0 is mapped 1:1, while the Linux page can span across
> +	 * multiple Xen pages, it's not possible for it to contain a
> +	 * mix of local and foreign Xen pages. So if the first xen_pfn
> +	 * == mfn the page is local otherwise it's a foreign page
> +	 * grant-mapped in dom0. If the page is local we can safely
> +	 * call the native dma_ops function, otherwise we call the xen
> +	 * specific function.
>  	 */
>  	if (local)
>  		__generic_dma_ops(hwdev)->map_page(hwdev, page, offset, size, dir, attrs);
> -- 
> 2.1.4
> 


From linux at arm.linux.org.uk  Mon Feb  8 09:00:29 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Feb 2016 17:00:29 +0000
Subject: [PATCH 1/3] ARM: move .vectors and .stubs sections back into the
 kernel VMA
In-Reply-To: <20160208163935.GN10826@n2100.arm.linux.org.uk>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454419174-21290-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160203000351.GX10826@n2100.arm.linux.org.uk>
 <CAKv+Gu_kYWczCazqgRC3y-n7s3WRTDhJXLO1RM1FE-6h1BhSUw@mail.gmail.com>
 <20160203091331.GB10826@n2100.arm.linux.org.uk>
 <CAKv+Gu8jbfs6HuzoFTQV2z-0LLiEZ9p0ZHO6eF3itE8p1LMwBA@mail.gmail.com>
 <20160208163935.GN10826@n2100.arm.linux.org.uk>
Message-ID: <20160208170029.GO10826@n2100.arm.linux.org.uk>

On Mon, Feb 08, 2016 at 04:39:35PM +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 03, 2016 at 10:16:46AM +0100, Ard Biesheuvel wrote:
> > There are 34 section headers, starting at offset 0x10a6e60:
> > 
> > Section Headers:
> >   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
> >   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
> >   [16] .vectors          PROGBITS        00000000 a40000 000020 00  AX  0   0  2
> >   [17] .stubs            PROGBITS        00001000 a41000 0002c0 00  AX  0   0 32
> >   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
> ...
> > Section Headers:
> >   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
> >   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
> >   [16] .stubs            PROGBITS        c0c35000 a35000 0002c0 00  AX  0   0 32
> >   [17] .vectors          PROGBITS        c0c34000 a44000 000020 00  AX  0   0  2
> >   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
> 
> Sorry, but I'm going to re-iterate my objection, and I believe that
> because you're looking at readelf's output, you're making assumptions
> when interpreting its output.
> 
> These figures do not truely describe how the file is laid out.  The
> tool to use for this is objdump -h.  Let's compare:
> 
> $ readelf -S vmlinux
> Section Headers:
>   [Nr] Name        Type         Addr     Off    Size   ES Flg Lk Inf Al
>   [13] .notes      NOTE         c093afd0 93afd0 000024 00  AX  0   0  4
>   [14] .vectors    PROGBITS     00000000 940000 000020 00  AX  0   0  4
>   [15] .stubs      PROGBITS     00001000 941000 0002c0 00  AX  0   0 32
>   [16] .init.text  PROGBITS     c093b2e0 94b2e0 04862c 00  AX  0   0 32
> 
> $ objdump -h vmlinux
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>  12 .notes        00000024  c093afd0  c093afd0  0093afd0  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>  13 .vectors      00000020  00000000  c093b000  00940000  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>  14 .stubs        000002c0  00001000  c093b020  00941000  2**5
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>  15 .init.text    0004862c  c093b2e0  c093b2e0  0094b2e0  2**5
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
> 
> Note that objdump -h has one additional piece of information here: the
> LMA - load memory address.  This tells us where the file contents
> (offset into the ELF file at "File off") are to be loaded into memory,
> as opposed to the VMA which describes where (at run time) the object is
> to be found.
> 
> With this new information, we can see that .vectors is loaded to
> 0xc093b000, and occupies only 32 bytes in the binary memory image, even
> though it occupies 4k in the ELF file.)  .stubs is loaded at 0xc093b020,
> and occupies 0x2c0 bytes.  Furthermore, we can see .init.text is located
> at 0xc093b2e0.
> 
> So, there is no memory wastage here - .vectors, .stubs and the init text
> are all packed tightly together.  That's something which the readelf -S
> output doesn't show us.
> 
> Please, replace the readelf -S output with objdump -h output so that we
> can see what's /really/ going on here.
> 
> In any case, I still don't like your patch.  At least having these at 0
> and 0x1000 means that (for some CPUs) they are located at the real VMA
> address that they may appear at, though for modern CPUs, locating them
> at 0xffff0000 and 0xffff1000 VMA would be more reasonable.  This has the
> advantage that (jtag) debuggers are able to correctly parse the vmlinux
> file and insert breakpoints into the vectors.

Another down-side to your patch is that you're placing the VMA of
.vectors 4096 bytes below .stubs - but we can have other symbols in
that VMA space.  That means you're creating the very real possibility
of confusing output we have real data at the location where you're
placing .vectors.

So no, I _really_ don't like this.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From ard.biesheuvel at linaro.org  Mon Feb  8 09:01:26 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 8 Feb 2016 18:01:26 +0100
Subject: [PATCH 1/3] ARM: move .vectors and .stubs sections back into the
 kernel VMA
In-Reply-To: <20160208163935.GN10826@n2100.arm.linux.org.uk>
References: <1454419174-21290-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454419174-21290-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160203000351.GX10826@n2100.arm.linux.org.uk>
 <CAKv+Gu_kYWczCazqgRC3y-n7s3WRTDhJXLO1RM1FE-6h1BhSUw@mail.gmail.com>
 <20160203091331.GB10826@n2100.arm.linux.org.uk>
 <CAKv+Gu8jbfs6HuzoFTQV2z-0LLiEZ9p0ZHO6eF3itE8p1LMwBA@mail.gmail.com>
 <20160208163935.GN10826@n2100.arm.linux.org.uk>
Message-ID: <CAKv+Gu-9=h98nwpwcXMfHBzJ8PEF=k9KG1O_HyV=bdA_PkxTfA@mail.gmail.com>

On 8 February 2016 at 17:39, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Wed, Feb 03, 2016 at 10:16:46AM +0100, Ard Biesheuvel wrote:
>> There are 34 section headers, starting at offset 0x10a6e60:
>>
>> Section Headers:
>>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
>>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>>   [16] .vectors          PROGBITS        00000000 a40000 000020 00  AX  0   0  2
>>   [17] .stubs            PROGBITS        00001000 a41000 0002c0 00  AX  0   0 32
>>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
> ...
>> Section Headers:
>>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
>>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>>   [16] .stubs            PROGBITS        c0c35000 a35000 0002c0 00  AX  0   0 32
>>   [17] .vectors          PROGBITS        c0c34000 a44000 000020 00  AX  0   0  2
>>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
>
> Sorry, but I'm going to re-iterate my objection, and I believe that
> because you're looking at readelf's output, you're making assumptions
> when interpreting its output.
>
> These figures do not truely describe how the file is laid out.  The
> tool to use for this is objdump -h.  Let's compare:
>
> $ readelf -S vmlinux
> Section Headers:
>   [Nr] Name        Type         Addr     Off    Size   ES Flg Lk Inf Al
>   [13] .notes      NOTE         c093afd0 93afd0 000024 00  AX  0   0  4
>   [14] .vectors    PROGBITS     00000000 940000 000020 00  AX  0   0  4
>   [15] .stubs      PROGBITS     00001000 941000 0002c0 00  AX  0   0 32
>   [16] .init.text  PROGBITS     c093b2e0 94b2e0 04862c 00  AX  0   0 32
>
> $ objdump -h vmlinux
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>  12 .notes        00000024  c093afd0  c093afd0  0093afd0  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>  13 .vectors      00000020  00000000  c093b000  00940000  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>  14 .stubs        000002c0  00001000  c093b020  00941000  2**5
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>  15 .init.text    0004862c  c093b2e0  c093b2e0  0094b2e0  2**5
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>
> Note that objdump -h has one additional piece of information here: the
> LMA - load memory address.  This tells us where the file contents
> (offset into the ELF file at "File off") are to be loaded into memory,
> as opposed to the VMA which describes where (at run time) the object is
> to be found.
>
> With this new information, we can see that .vectors is loaded to
> 0xc093b000, and occupies only 32 bytes in the binary memory image, even
> though it occupies 4k in the ELF file.)  .stubs is loaded at 0xc093b020,
> and occupies 0x2c0 bytes.  Furthermore, we can see .init.text is located
> at 0xc093b2e0.
>
> So, there is no memory wastage here - .vectors, .stubs and the init text
> are all packed tightly together.  That's something which the readelf -S
> output doesn't show us.
>
> Please, replace the readelf -S output with objdump -h output so that we
> can see what's /really/ going on here.
>

OK, fair enough.

Before:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
 14 .notes        00000024  c0c90030  c0c90030  00a90030  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 15 .vectors      00000020  00000000  c0c91000  00aa0000  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 16 .stubs        000002c0  00001000  c0c91020  00aa1000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 17 .init.text    0006b250  c0c912e0  c0c912e0  00aa12e0  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

and after

 14 .notes        00000024  c0c90030  c0c90030  00a90030  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 15 .stubs        000002c0  c0c91000  c0c91000  00a91000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 16 .vectors      00000020  c0c90000  c0c912c0  00aa0000  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 17 .init.text    0006b250  c0c912e0  c0c912e0  00aa12e0  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

So, apart from the fact that .vectors and .stubs are reordered,
nothing changes, and the LMA footprint is identical.

> In any case, I still don't like your patch.  At least having these at 0
> and 0x1000 means that (for some CPUs) they are located at the real VMA
> address that they may appear at, though for modern CPUs, locating them
> at 0xffff0000 and 0xffff1000 VMA would be more reasonable.  This has the
> advantage that (jtag) debuggers are able to correctly parse the vmlinux
> file and insert breakpoints into the vectors.
>

0xffff0000 and 0xffff1000 work for me. I am trying to get rid of this
dodgy workaround in scripts/link-vmlinux.sh(85):

if [ -n "${CONFIG_ARM}" ] && [ -z "${CONFIG_XIP_KERNEL}" ] && [ -n
"${CONFIG_PAGE_OFFSET}" ]; then
    kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
fi

which is there because perf does not like seeing the zero based kernel
symbol addresses, and only fixes the XIP_KERNEL=n case anyway.

Alternatively, this issue can be solved by making all stubs symbols
strictly local (or absolute), i.e., something like below. Would that
be preferable to you? It also fixes the perf issue for both
XIP_KERNEL=y and =n, but keeps .vectors and .stubs where they are.

-- 
Ard.


---------8<------------
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 788e40c1254f..c5c50c70c080 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -1027,7 +1027,7 @@ __kuser_helper_end:
  .macro vector_stub, name, mode, correction=0
  .align 5

-vector_\name:
+.Lvector_\name:
  .if \correction
  sub lr, lr, #\correction
  .endif
@@ -1056,7 +1056,7 @@ vector_\name:
  mov r0, sp
  ARM( ldr lr, [pc, lr, lsl #2] )
  movs pc, lr @ branch to handler in SVC mode
-ENDPROC(vector_\name)
+ENDPROC(.Lvector_\name)

  .align 2
  @ handler addresses follow this label
@@ -1064,14 +1064,15 @@ ENDPROC(vector_\name)
  .endm

  .section .stubs, "ax", %progbits
+.Lstubs_start:
  @ This must be the first word
  .word vector_swi

-vector_rst:
+.Lvector_rst:
  ARM( swi SYS_ERROR0 )
  THUMB( svc #0 )
  THUMB( nop )
- b vector_und
+ b .Lvector_und

 /*
  * Interrupt dispatcher
@@ -1173,8 +1174,8 @@ vector_rst:
  * (they're not supposed to happen, and won't happen in 32-bit data mode).
  */

-vector_addrexcptn:
- b vector_addrexcptn
+.Lvector_addrexcptn:
+ b .Lvector_addrexcptn

 /*=============================================================================
  * FIQ "NMI" handler
@@ -1202,18 +1203,18 @@ vector_addrexcptn:
  .long __fiq_svc @  f

  .globl vector_fiq_offset
- .equ vector_fiq_offset, vector_fiq
+ .equ vector_fiq_offset, .Lvector_fiq - .Lstubs_start + 0x1000

  .section .vectors, "ax", %progbits
 .L__vectors_start:
- W(b) vector_rst
- W(b) vector_und
+ W(b) .Lvector_rst
+ W(b) .Lvector_und
  W(ldr) pc, .L__vectors_start + 0x1000
- W(b) vector_pabt
- W(b) vector_dabt
- W(b) vector_addrexcptn
- W(b) vector_irq
- W(b) vector_fiq
+ W(b) .Lvector_pabt
+ W(b) .Lvector_dabt
+ W(b) .Lvector_addrexcptn
+ W(b) .Lvector_irq
+ W(b) .Lvector_fiq

  .data


From christoffer.dall at linaro.org  Mon Feb  8 09:00:26 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Mon, 8 Feb 2016 18:00:26 +0100
Subject: [PATCH V14 0/9] dma: add Qualcomm Technologies HIDMA driver
In-Reply-To: <56B8A527.7010206@codeaurora.org>
References: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>
 <20160208101432.GA1150@cbox> <56B8A527.7010206@codeaurora.org>
Message-ID: <20160208170026.GA23324@cbox>

On Mon, Feb 08, 2016 at 09:24:39AM -0500, Sinan Kaya wrote:
> Hi,
> 
> On 2/8/2016 5:14 AM, Christoffer Dall wrote:
> > Hi Sinan,
> > 
> > On Thu, Feb 04, 2016 at 11:34:31PM -0500, Sinan Kaya wrote:
> >> The Qualcomm Technologies HIDMA device has been designed
> >> to support virtualization technology. The driver has been
> >> divided into two to follow the hardware design.
> >>
> >> 1. HIDMA Management driver
> >> 2. HIDMA Channel driver
> >>
> >> Each HIDMA HW consists of multiple channels. These channels
> >> share some set of common parameters. These parameters are
> >> initialized by the management driver during power up.
> >> Same management driver is used for monitoring the execution
> >> of the channels. Management driver can change the performance
> >> behavior dynamically such as bandwidth allocation and
> >> prioritization in the future.
> >>
> >> The management driver is executed in host context and
> >> is the main management entity for all channels provided by
> >> the device.
> > 
> > I'm not at all familiar with this kind of hardware.
> > 
> 
> Let me help. 
> 
> > Once an entity (userspace or VM) has a HIDAM channel assigned via VFIO,
> > how does it use it?  
> 
> HIDMA is a HW accelerator for memory operations like memcpy and memset. It fits
> into the DMA engine framework.
> 
> There are two classes of DMA HW. These are slave DMA and standalone DMA. Slave DMA
> is generally related to another piece of HW that needs DMA for moving data. 
> Standalone DMA is intended for OS/CPU consumption not HW. These can be used to offload
> crypto operations (XOR) or other memory transactions (memcpy and memset) that are
> lengthy. 
> 
> Once the HIDMA channel is assigned to the guest machine, guest operating system uses the
> DMA channel to offload memory operations as HIDMA only supports memcpy. 
> 
> IOMMU HW provides the isolation from the rest of the host kernel or from other guest machines.
> 
> > Is it used in relation with another device to
> > perform DMA on its behalf or is a HIDMA channel something that's useful
> > on its own?
> 
> It is standalone only. The relationship you are referring to is known as slave DMA engine. 
> HIDMA does not support slave DMA. HIDMA only supports memcpy and memset in HW and only memcpy in SW
> as the memset support has been removed from the kernel long time ago.
> 
Thanks for the explanation.

-Christoffer


From mathieu.poirier at linaro.org  Mon Feb  8 09:05:45 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Mon, 8 Feb 2016 10:05:45 -0700
Subject: [PATCH V2 3/6] stm class: provision for statically assigned
 masterIDs
In-Reply-To: <87twlj49k7.fsf@ashishki-desk.ger.corp.intel.com>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
 <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org>
 <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com>
 <CANLsYky2twQ98u241YyHD=atYRp1N56YVHUQNY2E2Ljsq0cseA@mail.gmail.com>
 <87twlj49k7.fsf@ashishki-desk.ger.corp.intel.com>
Message-ID: <CANLsYkw=mG+ch8QzxmbwWs9o+mndVNo1MuqXcrPrNJYj_SQcHQ@mail.gmail.com>

On 8 February 2016 at 06:26, Alexander Shishkin
<alexander.shishkin at linux.intel.com> wrote:
> Mathieu Poirier <mathieu.poirier at linaro.org> writes:
>
>> On 5 February 2016 at 05:52, Alexander Shishkin
>> <alexander.shishkin at linux.intel.com> wrote:
>>> Chunyan Zhang <zhang.chunyan at linaro.org> writes:
>>>
>>>> From: Mathieu Poirier <mathieu.poirier at linaro.org>
>>>>
>>>> Some architecture like ARM assign masterIDs statically at the HW design
>>>> phase, making masterID manipulation in the generic STM core irrelevant.
>>>>
>>>> This patch adds a new 'mstatic' flag to struct stm_data that tells the
>>>> core that this specific STM device doesn't need explicit masterID
>>>> management.
>>>
>>> So why do we need this patch? If your STM only has master 42 allocated
>>> for software sources, simply set sw_start = 42, sw_end = 42 and you're
>>> good to go, software will have exactly one channel to choose from. See
>>> also the comment from <linux/stm.h>:
>>
>> On ARM each source, i.e entity capable of accessing STM channels, has
>> a different master ID set in HW.  We can't assume the IDs are
>> contiguous and from a SW point of view there is no way to probe the
>> values.
>
> Ok, it's the 'static' word that got me confused. From Mike's explanation
> it seems to me that it's the antithesis of static; the master ID
> assignment is so dynamic that it's not controllable by the software and
> may or may not reflect core id, power state, phase of the moon, etc.

Mike did write "master IDs are hardwired to individual cores and core
security states", which make assignment for one platform very static.
On the flip side those will change from one system to another.

>
>>>> In the core sw_start/end of masterID are set to '1',
>>>> i.e there is only one masterID to deal with.
>>>
>>> This is also a completely arbitrary and unnecessary requirement. Again,
>>> you can set both to 42 and it will still work.
>>
>> True - any value will do. The important thing to remember is that on
>> ARM, there is only one masterID channel (from an STM core point of
>> view).  But we could also proceed differently, see below for more
>> details.
>
> Well, we have the masters attribute with two numbers in it that define
> the range of master IDs that the software can choose from. More
> specifically to this situation:
>
>  * the number of channel ID spaces available to the SW is
>    $end - $start + 1, that is, in your case, just 1;
>  * the number of master IDs for the SW to choose from is $end - $start;
>  * if $end==$start, their actual numeric value doesn't really matter,
>    either for the policy definition or for the actual writers.
>
> This $end==$start situation itself may be ambiguous and can be
> interpreted either as having just one *static* master ID fixed for all
> SW writers (what I assumed from your commit message) or as having a
> floating master ID, which changes of its own accord and is not
> controllable by software.

Some clarification here.

On ARM from a SW point of view $end == $start and that doesn't change
(with regards to masterIDs) .  The ambiguity comes from the fact that
on other platforms where masterID configuration does change and is
important, the condition $end == $start could also be valid.

>From configFS, how do we tell users when masterIDs are set in HW?
That's what I wanted to highlight with the '-1'.  Regardless of the
solution we choose I think it is important that we inform, at the very
least, users when masterIDs don't matter.  We could also leave thing
as is, kill this patch and document things thoroughly.  With the
former things are obvious.

>
> These two situations are really the same thing from the perspective of
> the system under tracing. Also, both of these situations should already
> work if the driver sets both sw_start and sw_end to the same
> value.
>
> Regards,
> --
> Alex


From dirk.behme at gmail.com  Mon Feb  8 09:08:57 2016
From: dirk.behme at gmail.com (Dirk Behme)
Date: Mon, 8 Feb 2016 18:08:57 +0100
Subject: [PATCH v2] arm64: dts: r8a7795: Add L2 cache-controller nodes
In-Reply-To: <CAMuHMdUTUss=fR0Mdz+7tDD=RC6hufvkLC99Fp=PTiTgaSSGNA@mail.gmail.com>
References: <1452953856-5146-1-git-send-email-dirk.behme@gmail.com>
 <56B2370D.2010102@gmail.com> <20160205095758.GE16556@verge.net.au>
 <CAMuHMdVRhwGh2bvfNSguX0XnMW0eEgLRTCt3Y3-+KfV0Jy9WHw@mail.gmail.com>
 <56B857AC.4090701@de.bosch.com>
 <CAMuHMdUTUss=fR0Mdz+7tDD=RC6hufvkLC99Fp=PTiTgaSSGNA@mail.gmail.com>
Message-ID: <56B8CBA9.8@gmail.com>

Hi Geert,

On 08.02.2016 10:01, Geert Uytterhoeven wrote:
> Hi Dirk,
>
> On Mon, Feb 8, 2016 at 9:54 AM, Dirk Behme <dirk.behme at de.bosch.com> wrote:
>> On 08.02.2016 09:42, Geert Uytterhoeven wrote:
>>> On Fri, Feb 5, 2016 at 10:57 AM, Simon Horman <horms at verge.net.au> wrote:
>>>> On Wed, Feb 03, 2016 at 06:21:17PM +0100, Dirk Behme wrote:
>>>>> On 16.01.2016 15:17, Dirk Behme wrote:
>>>>>> From: Geert Uytterhoeven <geert+renesas at glider.be>
>>>>>>
>>>>>> Add device nodes for the L2 caches, and link the CPU node to its L2
>>>>>> cache node.
>>>>>>
>>>>>> The L2 cache for the Cortex-A57 CPU cores is 2 MiB large (organized as
>>>>>> 128 KiB x 16 ways).
>>>>>>
>>>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
>>>>>> Signed-off-by: Dirk Behme <dirk.behme at gmail.com>
>>>>
>>>> [snip]
>>>>
>>>>> Any further comments to this? If not, could this be applied?
>>>>
>>>> Sorry for the delay.
>>>>
>>>> This looks good; I have queued it up.
>>>>
>>>> It should appear in the next (and devel) branches of my renesas tree
>>>> soon.
>>>> And in linux-next whenever it includes my updated next branch.
>>>
>>> So you not only dropped the (controversial) timing related properties, but
>>> in addition:
>>>
>>> +               cache-unified;
>>> +               cache-level = <2>;
>>>
>>> At least the "cache-level" property is marked as required in ePAPR.
>>> For "cache-unified", the wording is not that strict in ePAPR, but that
>>> property
>>> depends on being a unified cache in the first place.
>>>
>>> So I think these two properties should be re-added.
>>
>> If I remember correctly, first, these entries are not used at all on ARMv8.
>> And second, I think it was mentioned that we therefore want to drop them:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394936.html
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/devicetree/bindings/arm/l2c2x0.txt?id=0bed4b7aa02c06e05121875dc443295d55b9d91d
>
> I believe the discussion was only about the latency properties, which are
> documented in the l2c2x0 DT bindings, and deemed to not apply here


Hmm, the two bindings cache-unified and cache-level are documented in 
bindings/arm/l2c2x0.txt, too.


> The DT bindings documented in ePAPR are generic, and apply to all hardware,
> unless extended or overridden by more-specific DT bindings.


I still can't see the benefit of adding entries to the device tree 
which are not used at all (and most probably don't make sense on that 
platform). But if anybody has a different opinion and maybe good 
arguments for it, that would be fine, too :)

Best regards

Dirk



From codekipper at gmail.com  Mon Feb  8 09:09:19 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Mon,  8 Feb 2016 18:09:19 +0100
Subject: [PATCH v6 0/2] ASoC: Add SPDIF support for Allwinner SoCs
Message-ID: <1454951361-10625-1-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

This patch set adds support for the Allwinner SPDIF transceiver.

For now just the SPDIF transmitter has been tested on a Mele A2000(A10)
and a Itead Ibox(A20).

In order for this patch set to be functional we require an audio clock patch
which will be delivered separately. For those that are interested I've pushed
the patches here with all the required changes to get SPDIF audio out of the
device.

https://github.com/codekipper/linux-sunxi/commits/spdif_delivery

Thanks in advance,
CK

---
Changes since v5:
- fixed warning that had sneaked in.'

Changes since v4:
- corrected indentation issues
- removed old macros
- removed unnecessary enabling of apb clock

Changes since v3:
- removed code required for spdif capture
- added disable/enable of apb clk to suspend/resume.
- removed unnecessary dt checks in probe
- fixed error conditions in probe/resume
- modified pm_runtime functionality and confirmed that driver worked when PM was disabled.
- removed .owner from platform driver
- renamed bindings file

Changes since v2:
- removed sunxi-machine-spdif and replaced with simple audio card
- removed untested compatibilities from device tree documentation
- added pm_runtime and remove shutdown
- removed pll2 as it's the parent of the spdif clock
- rename clk to spdif_clk
- removed enabling of mclk output
- removed interrupts status being cleared as it's not being used
- use default fifo settings for now
- fixed alignments for wrapped lines

Changes since v1:
- Moved sunxi-machine-spdif.c to separate patch
- replaced sunxi in naming scheme with sun4i in the sun4i-spdif driver.
- split tx controller into separate enable/disable functions
- moved setclk and setfmt functionality into hw params
- added support for mono signals.
- cleaned up probe clock set up.
- removed all writes to transmit status registers.
- removed of_id
- removed power management code.
- Added support for more rates.


Marcus Cooper (2):
  dt-bindings: sunxi :add sun4i SPDIF transceiver
  ASoC: sunxi: Add support for the SPDIF block

 .../bindings/sound/sunxi,sun4i-spdif.txt           |  39 ++
 sound/soc/sunxi/Kconfig                            |   8 +
 sound/soc/sunxi/Makefile                           |   1 +
 sound/soc/sunxi/sun4i-spdif.c                      | 550 +++++++++++++++++++++
 4 files changed, 598 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
 create mode 100644 sound/soc/sunxi/sun4i-spdif.c

-- 
2.7.1



From codekipper at gmail.com  Mon Feb  8 09:09:20 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Mon,  8 Feb 2016 18:09:20 +0100
Subject: [PATCH v6 1/2] dt-bindings: sunxi :add sun4i SPDIF transceiver
In-Reply-To: <1454951361-10625-1-git-send-email-codekipper@gmail.com>
References: <1454951361-10625-1-git-send-email-codekipper@gmail.com>
Message-ID: <1454951361-10625-2-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

Add devicetree bindings for the SPDIF transceiver found on
found on Allwinners A10 and A20 SoCs.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
 .../bindings/sound/sunxi,sun4i-spdif.txt           | 39 ++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt

diff --git a/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
new file mode 100644
index 0000000..13503aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
@@ -0,0 +1,39 @@
+Allwinner Sony/Philips Digital Interface Format (S/PDIF) Controller
+
+The Allwinner S/PDIF audio block is a transceiver that allows the
+processor to receive and transmit digital audio via an coaxial cable or
+a fibre cable.
+For now only playback is supported.
+
+Required properties:
+
+  - compatible		: should be one of the following:
+    - "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC
+
+  - reg			: Offset and length of the register set for the device.
+
+  - interrupts		: Contains the spdif interrupt.
+
+  - dmas		: Generic dma devicetree binding as described in
+			  Documentation/devicetree/bindings/dma/dma.txt.
+
+  - dma-names		: Two dmas have to be defined, "tx" and "rx".
+
+  - clocks		: Contains an entry for each entry in clock-names.
+
+  - clock-names		: Includes the following entries:
+	"apb"		  clock for the spdif bus.
+	"spdif"		  clock for spdif controller.
+
+Example:
+
+spdif: spdif at 01c21000 {
+	compatible = "allwinner,sun4i-a10-spdif";
+	reg = <0x01c21000 0x40>;
+	interrupts = <13>;
+	clocks = <&apb0_gates 1>, <&spdif_clk>;
+	clock-names = "apb", "spdif";
+	dmas = <&dma 0 2>, <&dma 0 2>;
+	dma-names = "rx", "tx";
+	status = "okay";
+};
-- 
2.7.1



From codekipper at gmail.com  Mon Feb  8 09:09:21 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Mon,  8 Feb 2016 18:09:21 +0100
Subject: [PATCH v6 2/2] ASoC: sunxi: Add support for the SPDIF block
In-Reply-To: <1454951361-10625-1-git-send-email-codekipper@gmail.com>
References: <1454951361-10625-1-git-send-email-codekipper@gmail.com>
Message-ID: <1454951361-10625-3-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

The sun4i, sun5i and sun7i SoC families have an SPDIF
block which is capable of playback and capture.

This patch enables the playback of this block for
the sun4i families.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
 sound/soc/sunxi/Kconfig       |   8 +
 sound/soc/sunxi/Makefile      |   1 +
 sound/soc/sunxi/sun4i-spdif.c | 550 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 559 insertions(+)
 create mode 100644 sound/soc/sunxi/sun4i-spdif.c

diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
index 84c72ec..ae42294 100644
--- a/sound/soc/sunxi/Kconfig
+++ b/sound/soc/sunxi/Kconfig
@@ -8,4 +8,12 @@ config SND_SUN4I_CODEC
 	  Select Y or M to add support for the Codec embedded in the Allwinner
 	  A10 and affiliated SoCs.
 
+config SND_SUN4I_SPDIF
+	tristate "Allwinner A10 SPDIF Support"
+	depends on OF
+	select SND_SOC_GENERIC_DMAENGINE_PCM
+	select REGMAP_MMIO
+	help
+	  Say Y or M to add support for the S/PDIF audio block in the Allwinner
+	  A10 and affiliated SoCs.
 endmenu
diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
index ea8a08c..8f5e889 100644
--- a/sound/soc/sunxi/Makefile
+++ b/sound/soc/sunxi/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
 
+obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o
diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
new file mode 100644
index 0000000..0b04fb0
--- /dev/null
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -0,0 +1,550 @@
+/*
+ * ALSA SoC SPDIF Audio Layer
+ *
+ * Copyright 2015 Andrea Venturi <be17068 at iperbole.bo.it>
+ * Copyright 2015 Marcus Cooper <codekipper at gmail.com>
+ *
+ * Based on the Allwinner SDK driver, released under the GPL.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/regmap.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/ioport.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <sound/dmaengine_pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+
+#define	SUN4I_SPDIF_CTL		(0x00)
+	#define SUN4I_SPDIF_CTL_MCLKDIV(v)		((v) << 4) /* v even */
+	#define SUN4I_SPDIF_CTL_MCLKOUTEN		BIT(2)
+	#define SUN4I_SPDIF_CTL_GEN			BIT(1)
+	#define SUN4I_SPDIF_CTL_RESET			BIT(0)
+
+#define SUN4I_SPDIF_TXCFG	(0x04)
+	#define SUN4I_SPDIF_TXCFG_SINGLEMOD		BIT(31)
+	#define SUN4I_SPDIF_TXCFG_ASS			BIT(17)
+	#define SUN4I_SPDIF_TXCFG_NONAUDIO		BIT(16)
+	#define SUN4I_SPDIF_TXCFG_TXRATIO(v)		((v) << 4)
+	#define SUN4I_SPDIF_TXCFG_TXRATIO_MASK		GENMASK(8, 4)
+	#define SUN4I_SPDIF_TXCFG_FMTRVD		GENMASK(3, 2)
+	#define SUN4I_SPDIF_TXCFG_FMT16BIT		(0 << 2)
+	#define SUN4I_SPDIF_TXCFG_FMT20BIT		(1 << 2)
+	#define SUN4I_SPDIF_TXCFG_FMT24BIT		(2 << 2)
+	#define SUN4I_SPDIF_TXCFG_CHSTMODE		BIT(1)
+	#define SUN4I_SPDIF_TXCFG_TXEN			BIT(0)
+
+#define SUN4I_SPDIF_RXCFG	(0x08)
+	#define SUN4I_SPDIF_RXCFG_LOCKFLAG		BIT(4)
+	#define SUN4I_SPDIF_RXCFG_CHSTSRC		BIT(3)
+	#define SUN4I_SPDIF_RXCFG_CHSTCP		BIT(1)
+	#define SUN4I_SPDIF_RXCFG_RXEN			BIT(0)
+
+#define SUN4I_SPDIF_TXFIFO	(0x0C)
+
+#define SUN4I_SPDIF_RXFIFO	(0x10)
+
+#define SUN4I_SPDIF_FCTL	(0x14)
+	#define SUN4I_SPDIF_FCTL_FIFOSRC		BIT(31)
+	#define SUN4I_SPDIF_FCTL_FTX			BIT(17)
+	#define SUN4I_SPDIF_FCTL_FRX			BIT(16)
+	#define SUN4I_SPDIF_FCTL_TXTL(v)		((v) << 8)
+	#define SUN4I_SPDIF_FCTL_TXTL_MASK		GENMASK(12, 8)
+	#define SUN4I_SPDIF_FCTL_RXTL(v)		((v) << 3)
+	#define SUN4I_SPDIF_FCTL_RXTL_MASK		GENMASK(7, 3)
+	#define SUN4I_SPDIF_FCTL_TXIM			BIT(2)
+	#define SUN4I_SPDIF_FCTL_RXOM(v)		((v) << 0)
+	#define SUN4I_SPDIF_FCTL_RXOM_MASK		GENMASK(1, 0)
+
+#define SUN4I_SPDIF_FSTA	(0x18)
+	#define SUN4I_SPDIF_FSTA_TXE			BIT(14)
+	#define SUN4I_SPDIF_FSTA_TXECNTSHT		(8)
+	#define SUN4I_SPDIF_FSTA_RXA			BIT(6)
+	#define SUN4I_SPDIF_FSTA_RXACNTSHT		(0)
+
+#define SUN4I_SPDIF_INT		(0x1C)
+	#define SUN4I_SPDIF_INT_RXLOCKEN		BIT(18)
+	#define SUN4I_SPDIF_INT_RXUNLOCKEN		BIT(17)
+	#define SUN4I_SPDIF_INT_RXPARERREN		BIT(16)
+	#define SUN4I_SPDIF_INT_TXDRQEN			BIT(7)
+	#define SUN4I_SPDIF_INT_TXUIEN			BIT(6)
+	#define SUN4I_SPDIF_INT_TXOIEN			BIT(5)
+	#define SUN4I_SPDIF_INT_TXEIEN			BIT(4)
+	#define SUN4I_SPDIF_INT_RXDRQEN			BIT(2)
+	#define SUN4I_SPDIF_INT_RXOIEN			BIT(1)
+	#define SUN4I_SPDIF_INT_RXAIEN			BIT(0)
+
+#define SUN4I_SPDIF_ISTA	(0x20)
+	#define SUN4I_SPDIF_ISTA_RXLOCKSTA		BIT(18)
+	#define SUN4I_SPDIF_ISTA_RXUNLOCKSTA		BIT(17)
+	#define SUN4I_SPDIF_ISTA_RXPARERRSTA		BIT(16)
+	#define SUN4I_SPDIF_ISTA_TXUSTA			BIT(6)
+	#define SUN4I_SPDIF_ISTA_TXOSTA			BIT(5)
+	#define SUN4I_SPDIF_ISTA_TXESTA			BIT(4)
+	#define SUN4I_SPDIF_ISTA_RXOSTA			BIT(1)
+	#define SUN4I_SPDIF_ISTA_RXASTA			BIT(0)
+
+#define SUN4I_SPDIF_TXCNT	(0x24)
+
+#define SUN4I_SPDIF_RXCNT	(0x28)
+
+#define SUN4I_SPDIF_TXCHSTA0	(0x2C)
+	#define SUN4I_SPDIF_TXCHSTA0_CLK(v)		((v) << 28)
+	#define SUN4I_SPDIF_TXCHSTA0_SAMFREQ(v)		((v) << 24)
+	#define SUN4I_SPDIF_TXCHSTA0_SAMFREQ_MASK	GENMASK(27, 24)
+	#define SUN4I_SPDIF_TXCHSTA0_CHNUM(v)		((v) << 20)
+	#define SUN4I_SPDIF_TXCHSTA0_CHNUM_MASK		GENMASK(23, 20)
+	#define SUN4I_SPDIF_TXCHSTA0_SRCNUM(v)		((v) << 16)
+	#define SUN4I_SPDIF_TXCHSTA0_CATACOD(v)		((v) << 8)
+	#define SUN4I_SPDIF_TXCHSTA0_MODE(v)		((v) << 6)
+	#define SUN4I_SPDIF_TXCHSTA0_EMPHASIS(v)	((v) << 3)
+	#define SUN4I_SPDIF_TXCHSTA0_CP			BIT(2)
+	#define SUN4I_SPDIF_TXCHSTA0_AUDIO		BIT(1)
+	#define SUN4I_SPDIF_TXCHSTA0_PRO		BIT(0)
+
+#define SUN4I_SPDIF_TXCHSTA1	(0x30)
+	#define SUN4I_SPDIF_TXCHSTA1_CGMSA(v)		((v) << 8)
+	#define SUN4I_SPDIF_TXCHSTA1_ORISAMFREQ(v)	((v) << 4)
+	#define SUN4I_SPDIF_TXCHSTA1_ORISAMFREQ_MASK	GENMASK(7, 4)
+	#define SUN4I_SPDIF_TXCHSTA1_SAMWORDLEN(v)	((v) << 1)
+	#define SUN4I_SPDIF_TXCHSTA1_MAXWORDLEN		BIT(0)
+
+#define SUN4I_SPDIF_RXCHSTA0	(0x34)
+	#define SUN4I_SPDIF_RXCHSTA0_CLK(v)		((v) << 28)
+	#define SUN4I_SPDIF_RXCHSTA0_SAMFREQ(v)		((v) << 24)
+	#define SUN4I_SPDIF_RXCHSTA0_CHNUM(v)		((v) << 20)
+	#define SUN4I_SPDIF_RXCHSTA0_SRCNUM(v)		((v) << 16)
+	#define SUN4I_SPDIF_RXCHSTA0_CATACOD(v)		((v) << 8)
+	#define SUN4I_SPDIF_RXCHSTA0_MODE(v)		((v) << 6)
+	#define SUN4I_SPDIF_RXCHSTA0_EMPHASIS(v)	((v) << 3)
+	#define SUN4I_SPDIF_RXCHSTA0_CP			BIT(2)
+	#define SUN4I_SPDIF_RXCHSTA0_AUDIO		BIT(1)
+	#define SUN4I_SPDIF_RXCHSTA0_PRO		BIT(0)
+
+#define SUN4I_SPDIF_RXCHSTA1	(0x38)
+	#define SUN4I_SPDIF_RXCHSTA1_CGMSA(v)		((v) << 8)
+	#define SUN4I_SPDIF_RXCHSTA1_ORISAMFREQ(v)	((v) << 4)
+	#define SUN4I_SPDIF_RXCHSTA1_SAMWORDLEN(v)	((v) << 1)
+	#define SUN4I_SPDIF_RXCHSTA1_MAXWORDLEN		BIT(0)
+
+/* Defines for Sampling Frequency */
+#define SUN4I_SPDIF_SAMFREQ_44_1KHZ		0x0
+#define SUN4I_SPDIF_SAMFREQ_NOT_INDICATED	0x1
+#define SUN4I_SPDIF_SAMFREQ_48KHZ		0x2
+#define SUN4I_SPDIF_SAMFREQ_32KHZ		0x3
+#define SUN4I_SPDIF_SAMFREQ_22_05KHZ		0x4
+#define SUN4I_SPDIF_SAMFREQ_24KHZ		0x6
+#define SUN4I_SPDIF_SAMFREQ_88_2KHZ		0x8
+#define SUN4I_SPDIF_SAMFREQ_76_8KHZ		0x9
+#define SUN4I_SPDIF_SAMFREQ_96KHZ		0xa
+#define SUN4I_SPDIF_SAMFREQ_176_4KHZ		0xc
+#define SUN4I_SPDIF_SAMFREQ_192KHZ		0xe
+
+struct sun4i_spdif_dev {
+	struct platform_device *pdev;
+	struct clk *spdif_clk;
+	struct clk *apb_clk;
+	struct snd_soc_dai_driver cpu_dai_drv;
+	struct regmap *regmap;
+	struct snd_dmaengine_dai_dma_data dma_params_tx;
+};
+
+static void sun4i_spdif_configure(struct sun4i_spdif_dev *host)
+{
+	/* soft reset SPDIF */
+	regmap_write(host->regmap, SUN4I_SPDIF_CTL, SUN4I_SPDIF_CTL_RESET);
+
+	/* flush TX FIFO */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_FCTL,
+			   SUN4I_SPDIF_FCTL_FTX, SUN4I_SPDIF_FCTL_FTX);
+
+	/* clear TX counter */
+	regmap_write(host->regmap, SUN4I_SPDIF_TXCNT, 0);
+}
+
+static void sun4i_snd_txctrl_on(struct snd_pcm_substream *substream,
+				struct sun4i_spdif_dev *host)
+{
+	if (substream->runtime->channels == 1)
+		regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+				   SUN4I_SPDIF_TXCFG_SINGLEMOD,
+				   SUN4I_SPDIF_TXCFG_SINGLEMOD);
+
+	/* SPDIF TX ENABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+			   SUN4I_SPDIF_TXCFG_TXEN, SUN4I_SPDIF_TXCFG_TXEN);
+
+	/* DRQ ENABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_INT,
+			   SUN4I_SPDIF_INT_TXDRQEN, SUN4I_SPDIF_INT_TXDRQEN);
+
+	/* Global enable */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_CTL,
+			   SUN4I_SPDIF_CTL_GEN, SUN4I_SPDIF_CTL_GEN);
+}
+
+static void sun4i_snd_txctrl_off(struct snd_pcm_substream *substream,
+				 struct sun4i_spdif_dev *host)
+{
+	/* SPDIF TX DISABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+			   SUN4I_SPDIF_TXCFG_TXEN, 0);
+
+	/* DRQ DISABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_INT,
+			   SUN4I_SPDIF_INT_TXDRQEN, 0);
+
+	/* Global disable */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_CTL,
+			   SUN4I_SPDIF_CTL_GEN, 0);
+}
+
+static int sun4i_spdif_startup(struct snd_pcm_substream *substream,
+			       struct snd_soc_dai *cpu_dai)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(rtd->cpu_dai);
+
+	if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK)
+		return -EINVAL;
+
+	sun4i_spdif_configure(host);
+
+	return 0;
+}
+
+static int sun4i_spdif_hw_params(struct snd_pcm_substream *substream,
+				 struct snd_pcm_hw_params *params,
+				 struct snd_soc_dai *cpu_dai)
+{
+	int ret = 0;
+	int fmt;
+	unsigned long rate = params_rate(params);
+	u32 mclk_div = 0;
+	unsigned int mclk = 0;
+	u32 reg_val;
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
+	struct platform_device *pdev = host->pdev;
+
+	/* Add the PCM and raw data select interface */
+	switch (params_channels(params)) {
+	case 1: /* PCM mode */
+	case 2:
+		fmt = 0;
+		break;
+	case 4: /* raw data mode */
+		fmt = SUN4I_SPDIF_TXCFG_NONAUDIO;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	switch (params_format(params)) {
+	case SNDRV_PCM_FORMAT_S16_LE:
+		fmt |= SUN4I_SPDIF_TXCFG_FMT16BIT;
+		break;
+	case SNDRV_PCM_FORMAT_S20_3LE:
+		fmt |= SUN4I_SPDIF_TXCFG_FMT20BIT;
+		break;
+	case SNDRV_PCM_FORMAT_S24_LE:
+		fmt |= SUN4I_SPDIF_TXCFG_FMT24BIT;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	switch (rate) {
+	case 22050:
+	case 44100:
+	case 88200:
+	case 176400:
+		mclk = 22579200;
+		break;
+	case 24000:
+	case 32000:
+	case 48000:
+	case 96000:
+	case 192000:
+		mclk = 24576000;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	ret = clk_set_rate(host->spdif_clk, mclk);
+	if (ret < 0) {
+		dev_err(&pdev->dev,
+			"Setting SPDIF clock rate for %d Hz failed!\n", mclk);
+		return ret;
+	}
+
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_FCTL,
+			   SUN4I_SPDIF_FCTL_TXIM, SUN4I_SPDIF_FCTL_TXIM);
+
+	switch (rate) {
+	case 22050:
+	case 24000:
+		mclk_div = 8;
+		break;
+	case 32000:
+		mclk_div = 6;
+		break;
+	case 44100:
+	case 48000:
+		mclk_div = 4;
+		break;
+	case 88200:
+	case 96000:
+		mclk_div = 2;
+		break;
+	case 176400:
+	case 192000:
+		mclk_div = 1;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	reg_val = 0;
+	reg_val |= SUN4I_SPDIF_TXCFG_ASS;
+	reg_val |= fmt; /* set non audio and bit depth */
+	reg_val |= SUN4I_SPDIF_TXCFG_CHSTMODE;
+	reg_val |= SUN4I_SPDIF_TXCFG_TXRATIO(mclk_div - 1);
+	regmap_write(host->regmap, SUN4I_SPDIF_TXCFG, reg_val);
+
+	return 0;
+}
+
+static int sun4i_spdif_trigger(struct snd_pcm_substream *substream, int cmd,
+			       struct snd_soc_dai *dai)
+{
+	int ret = 0;
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(dai);
+
+	if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK)
+		return -EINVAL;
+
+	switch (cmd) {
+	case SNDRV_PCM_TRIGGER_START:
+	case SNDRV_PCM_TRIGGER_RESUME:
+	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+		sun4i_snd_txctrl_on(substream, host);
+		break;
+
+	case SNDRV_PCM_TRIGGER_STOP:
+	case SNDRV_PCM_TRIGGER_SUSPEND:
+	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+		sun4i_snd_txctrl_off(substream, host);
+		break;
+
+	default:
+		ret = -EINVAL;
+		break;
+	}
+	return ret;
+}
+
+static int sun4i_spdif_soc_dai_probe(struct snd_soc_dai *dai)
+{
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(dai);
+
+	snd_soc_dai_init_dma_data(dai, &host->dma_params_tx, NULL);
+	return 0;
+}
+
+static const struct snd_soc_dai_ops sun4i_spdif_dai_ops = {
+	.startup	= sun4i_spdif_startup,
+	.trigger	= sun4i_spdif_trigger,
+	.hw_params	= sun4i_spdif_hw_params,
+};
+
+static const struct regmap_config sun4i_spdif_regmap_config = {
+	.reg_bits = 32,
+	.reg_stride = 4,
+	.val_bits = 32,
+	.max_register = SUN4I_SPDIF_RXCHSTA1,
+};
+
+#define SUN4I_RATES	SNDRV_PCM_RATE_8000_192000
+
+#define SUN4I_FORMATS	(SNDRV_PCM_FORMAT_S16_LE | \
+				SNDRV_PCM_FORMAT_S20_3LE | \
+				SNDRV_PCM_FORMAT_S24_LE)
+
+static struct snd_soc_dai_driver sun4i_spdif_dai = {
+	.playback = {
+		.channels_min = 1,
+		.channels_max = 2,
+		.rates = SUN4I_RATES,
+		.formats = SUN4I_FORMATS,
+	},
+	.probe = sun4i_spdif_soc_dai_probe,
+	.ops = &sun4i_spdif_dai_ops,
+	.name = "spdif",
+};
+
+static const struct snd_soc_dapm_widget dit_widgets[] = {
+	SND_SOC_DAPM_OUTPUT("spdif-out"),
+};
+
+static const struct snd_soc_dapm_route dit_routes[] = {
+	{ "spdif-out", NULL, "Playback" },
+};
+
+static const struct of_device_id sun4i_spdif_of_match[] = {
+	{ .compatible = "allwinner,sun4i-a10-spdif", },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sun4i_spdif_of_match);
+
+static const struct snd_soc_component_driver sun4i_spdif_component = {
+	.name		= "sun4i-spdif",
+};
+
+static int sun4i_spdif_runtime_suspend(struct device *dev)
+{
+	struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
+
+	clk_disable_unprepare(host->spdif_clk);
+	clk_disable_unprepare(host->apb_clk);
+
+	return 0;
+}
+
+static int sun4i_spdif_runtime_resume(struct device *dev)
+{
+	struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
+
+	clk_prepare_enable(host->spdif_clk);
+	clk_prepare_enable(host->apb_clk);
+
+	return 0;
+}
+
+static int sun4i_spdif_probe(struct platform_device *pdev)
+{
+	struct sun4i_spdif_dev *host;
+	struct resource *res;
+	int ret;
+	void __iomem *base;
+
+	dev_dbg(&pdev->dev, "Entered %s\n", __func__);
+
+	host = devm_kzalloc(&pdev->dev, sizeof(*host), GFP_KERNEL);
+	if (!host)
+		return -ENOMEM;
+
+	host->pdev = pdev;
+
+	/* Initialize this copy of the CPU DAI driver structure */
+	memcpy(&host->cpu_dai_drv, &sun4i_spdif_dai, sizeof(sun4i_spdif_dai));
+	host->cpu_dai_drv.name = dev_name(&pdev->dev);
+
+	/* Get the addresses */
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	host->regmap = devm_regmap_init_mmio(&pdev->dev, base,
+						&sun4i_spdif_regmap_config);
+
+	/* Clocks */
+	host->apb_clk = devm_clk_get(&pdev->dev, "apb");
+	if (IS_ERR(host->apb_clk)) {
+		dev_err(&pdev->dev, "failed to get a apb clock.\n");
+		return PTR_ERR(host->apb_clk);
+	}
+
+	host->spdif_clk = devm_clk_get(&pdev->dev, "spdif");
+	if (IS_ERR(host->spdif_clk)) {
+		dev_err(&pdev->dev, "failed to get a spdif clock.\n");
+		ret = PTR_ERR(host->spdif_clk);
+		goto err_disable_apb_clk;
+	}
+
+	host->dma_params_tx.addr = res->start + SUN4I_SPDIF_TXFIFO;
+	host->dma_params_tx.maxburst = 4;
+	host->dma_params_tx.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
+
+	platform_set_drvdata(pdev, host);
+
+	ret = devm_snd_soc_register_component(&pdev->dev,
+				&sun4i_spdif_component, &sun4i_spdif_dai, 1);
+	if (ret)
+		goto err_disable_apb_clk;
+
+	pm_runtime_enable(&pdev->dev);
+	if (!pm_runtime_enabled(&pdev->dev)) {
+		ret = sun4i_spdif_runtime_resume(&pdev->dev);
+		if (ret)
+			goto err_unregister;
+	}
+
+	ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
+	if (ret)
+		goto err_suspend;
+	return 0;
+err_suspend:
+	if (!pm_runtime_status_suspended(&pdev->dev))
+		sun4i_spdif_runtime_suspend(&pdev->dev);
+err_unregister:
+	pm_runtime_disable(&pdev->dev);
+	snd_soc_unregister_component(&pdev->dev);
+err_disable_apb_clk:
+	clk_disable_unprepare(host->apb_clk);
+	return ret;
+}
+
+static int sun4i_spdif_remove(struct platform_device *pdev)
+{
+	pm_runtime_disable(&pdev->dev);
+	if (!pm_runtime_status_suspended(&pdev->dev))
+		sun4i_spdif_runtime_suspend(&pdev->dev);
+
+	snd_soc_unregister_platform(&pdev->dev);
+	snd_soc_unregister_component(&pdev->dev);
+
+	return 0;
+}
+
+static const struct dev_pm_ops sun4i_spdif_pm = {
+	SET_RUNTIME_PM_OPS(sun4i_spdif_runtime_suspend,
+			   sun4i_spdif_runtime_resume, NULL)
+};
+
+static struct platform_driver sun4i_spdif_driver = {
+	.driver		= {
+		.name	= "sun4i-spdif",
+		.of_match_table = of_match_ptr(sun4i_spdif_of_match),
+		.pm	= &sun4i_spdif_pm,
+	},
+	.probe		= sun4i_spdif_probe,
+	.remove		= sun4i_spdif_remove,
+};
+
+module_platform_driver(sun4i_spdif_driver);
+
+MODULE_AUTHOR("Marcus Cooper <codekipper at gmail.com>");
+MODULE_AUTHOR("Andrea Venturi <be17068 at iperbole.bo.it>");
+MODULE_DESCRIPTION("Allwinner sun4i SPDIF SoC Interface");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:sun4i-spdif");
-- 
2.7.1



From yang.shi at linaro.org  Mon Feb  8 09:09:46 2016
From: yang.shi at linaro.org (Shi, Yang)
Date: Mon, 8 Feb 2016 09:09:46 -0800
Subject: [PATCH] arm64: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL
In-Reply-To: <20160208114649.GB13498@leverpostej>
References: <1454716218-4918-1-git-send-email-yang.shi@linaro.org>
 <20160208114649.GB13498@leverpostej>
Message-ID: <56B8CBDA.4050107@linaro.org>

On 2/8/2016 3:46 AM, Mark Rutland wrote:
> Hi,
>
> On Fri, Feb 05, 2016 at 03:50:18PM -0800, Yang Shi wrote:
>> To enable UBSAN on arm64, ARCH_HAS_UBSAN_SANITIZE_ALL need to be selected.
>>
>> Basic kernel bootup test is passed on arm64 with CONFIG_UBSAN_SANITIZE_ALL
>> enabled.
>>
>> Signed-off-by: Yang Shi <yang.shi at linaro.org>
>> ---
>>   arch/arm64/Kconfig | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 8cc6228..1c29e20 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -14,6 +14,7 @@ config ARM64
>>   	select ARCH_WANT_OPTIONAL_GPIOLIB
>>   	select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
>>   	select ARCH_WANT_FRAME_POINTERS
>> +	select ARCH_HAS_UBSAN_SANITIZE_ALL
>>   	select ARM_AMBA
>>   	select ARM_ARCH_TIMER
>>   	select ARM_GIC
>
> I gave this a go, and I got a couple of splats (included below) when
> booting an Ubuntu 14.04 arm64 rootfs. I'm using Linato 15.08 GCC 5.1 to
> compile an arm64 defconfig, and I see the issue with v4.5-rc2 and
> v4.5-rc3.
>
> I will dig into that and file a report shortl, unless someone has
> already reported the same issue.
>
> Did you see any failures in your testing? For reference, which kernel
> version, compiler, and config were you using?

Yes, I did. I'm using 4.5-rc1 with gcc 5.2. And, I got one more splat 
and was digging into it.

I saw your report to ext4 maintainers. I tried to have a quick fix, but 
it sounds not work well. And, that code does look suspicious. Let's see 
what the ext4 maintainers say.

Thanks,
Yang

>
> This patch itself looks good, so FWIW:
>
> Tested-by: Mark Rutland <mark.rutland at arm.com>
>
> Thanks,
> Mark.
>
> [    3.804750] ================================================================================
> [    3.813176] UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2612:15
> [    3.819431] shift exponent 4294967295 is too large for 32-bit type 'int'
> [    3.826121] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc2+ #48
> [    3.832463] Hardware name: AMD Overdrive/Supercharger/Default string, BIOS ROD0085E 11/23/2015
> [    3.841060] Call trace:
> [    3.843499] [<ffffffc00008d7b8>] dump_backtrace+0x0/0x298
> [    3.848887] [<ffffffc00008da64>] show_stack+0x14/0x20
> [    3.853929] [<ffffffc00056e0f0>] dump_stack+0xe0/0x178
> [    3.859056] [<ffffffc0005b734c>] ubsan_epilogue+0x14/0x50
> [    3.864444] [<ffffffc0005b7748>] __ubsan_handle_shift_out_of_bounds+0xe0/0x138
> [    3.871655] [<ffffffc0003e1734>] ext4_mb_init+0x84c/0x920
> [    3.877043] [<ffffffc0003ba294>] ext4_fill_super+0x2eac/0x4958
> [    3.882866] [<ffffffc0002c1008>] mount_bdev+0x180/0x1e8
> [    3.888079] [<ffffffc0003adf8c>] ext4_mount+0x14/0x20
> [    3.893118] [<ffffffc0002c23f4>] mount_fs+0x44/0x1c8
> [    3.898073] [<ffffffc0002ed9c0>] vfs_kern_mount+0x50/0x1a8
> [    3.903547] [<ffffffc0002f3d90>] do_mount+0x240/0x1478
> [    3.908673] [<ffffffc0002f54d0>] SyS_mount+0x90/0xf8
> [    3.913627] [<ffffffc000eb2750>] mount_block_root+0x22c/0x3c4
> [    3.919361] [<ffffffc000eb2a08>] mount_root+0x120/0x138
> [    3.924574] [<ffffffc000eb2b5c>] prepare_namespace+0x13c/0x184
> [    3.930396] [<ffffffc000eb21bc>] kernel_init_freeable+0x390/0x3b4
> [    3.936479] [<ffffffc000bb4a78>] kernel_init+0x10/0xe0
> [    3.941606] [<ffffffc000086cd0>] ret_from_fork+0x10/0x40
> [    3.946905] ================================================================================
>
> [    5.566166] ================================================================================
> [    5.574596] UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1274:11
> [    5.580851] shift exponent -1 is negative
> [    5.584851] CPU: 4 PID: 1028 Comm: mount Not tainted 4.5.0-rc2+ #48
> [    5.591105] Hardware name: AMD Overdrive/Supercharger/Default string, BIOS ROD0085E 11/23/2015
> [    5.599702] Call trace:
> [    5.602142] [<ffffffc00008d7b8>] dump_backtrace+0x0/0x298
> [    5.607530] [<ffffffc00008da64>] show_stack+0x14/0x20
> [    5.612572] [<ffffffc00056e0f0>] dump_stack+0xe0/0x178
> [    5.617700] [<ffffffc0005b734c>] ubsan_epilogue+0x14/0x50
> [    5.623088] [<ffffffc0005b7748>] __ubsan_handle_shift_out_of_bounds+0xe0/0x138
> [    5.630300] [<ffffffc0003d2a04>] mb_find_order_for_block+0x154/0x1b0
> [    5.636641] [<ffffffc0003d2b2c>] mb_find_extent+0xcc/0x548
> [    5.642116] [<ffffffc0003de6a8>] ext4_mb_complex_scan_group+0xe8/0x4e8
> [    5.648632] [<ffffffc0003ded7c>] ext4_mb_regular_allocator+0x2d4/0x648
> [    5.655148] [<ffffffc0003e2b4c>] ext4_mb_new_blocks+0x344/0x7e0
> [    5.661056] [<ffffffc0003cbf54>] ext4_ext_map_blocks+0x684/0xf68
> [    5.667052] [<ffffffc000393664>] ext4_map_blocks+0x12c/0x500
> [    5.672699] [<ffffffc000398df4>] ext4_writepages+0x47c/0xe38
> [    5.678348] [<ffffffc00020da20>] do_writepages+0x48/0xc8
> [    5.683649] [<ffffffc0001f9100>] __filemap_fdatawrite_range+0x70/0xe8
> [    5.690078] [<ffffffc0001f91b0>] filemap_flush+0x18/0x20
> [    5.695378] [<ffffffc000394b64>] ext4_alloc_da_blocks+0x3c/0x78
> [    5.701285] [<ffffffc0003ac1c8>] ext4_rename+0x690/0xe38
> [    5.706585] [<ffffffc0003ac98c>] ext4_rename2+0x1c/0x40
> [    5.711800] [<ffffffc0002d0510>] vfs_rename+0x2c0/0xa90
> [    5.717013] [<ffffffc0002d661c>] SyS_renameat2+0x464/0x5c0
> [    5.722486] [<ffffffc0002d6788>] SyS_renameat+0x10/0x18
> [    5.727700] [<ffffffc000086d30>] el0_svc_naked+0x24/0x28
> [    5.732998] ================================================================================
>



From marc.zyngier at arm.com  Mon Feb  8 09:10:00 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 8 Feb 2016 17:10:00 +0000
Subject: [PATCH v3 6/6] kvm: arm64: Add ACPI support for virt arch timer
In-Reply-To: <1454358418-5157-7-git-send-email-fu.wei@linaro.org>
References: <1454358418-5157-1-git-send-email-fu.wei@linaro.org>
 <1454358418-5157-7-git-send-email-fu.wei@linaro.org>
Message-ID: <56B8CBE8.7020305@arm.com>

On 01/02/16 20:26, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei at linaro.org>
> 
> This patch adds ACPI/GTDT support for virt arch timer
> using the API in GTDT driver.
> 
> Signed-off-by: Fu Wei <fu.wei at linaro.org>
> ---
>  virt/kvm/arm/arch_timer.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 0a279d3..4077347 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -385,6 +385,9 @@ static int kvm_timer_get_ppi(unsigned int *ppi)
>  {
>  	struct device_node *np;
>  	int ret = -EINVAL;
> +#ifdef CONFIG_ACPI_GTDT
> +	struct arch_timer_data data;
> +#endif
>  
>  	np = of_find_matching_node(NULL, arch_timer_of_match);
>  	if (!np) {
> @@ -397,6 +400,11 @@ static int kvm_timer_get_ppi(unsigned int *ppi)
>  	of_node_put(np);
>  
>  skip_of:
> +#ifdef CONFIG_ACPI_GTDT
> +	if (!*ppi && !gtdt_arch_timer_data_init(NULL, &data))
> +		*ppi = data.virt_ppi;
> +#endif
> +
>  	if (*ppi)
>  		return 0;
>  
> 

As I already pointed out in another thread hacking some KVM ACPI stuff,
this is the wrong approach.

We should have a *common* accessor in the timer code that exports the
relevant information, whatever the firmware "du jour" is.

See Julien's series, which seems to address the issue in a much more
convincing way:

https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018531.html

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From linux at arm.linux.org.uk  Mon Feb  8 09:10:10 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Feb 2016 17:10:10 +0000
Subject: [PATCH 1/2] ARM: make virt_to_idmap() return unsigned long
In-Reply-To: <56B33BAC.6020303@ti.com>
References: <E1aO8F2-00074N-E8@rmk-PC.arm.linux.org.uk>
 <56A84748.3040108@oracle.com>
 <20160201152015.GU10826@n2100.arm.linux.org.uk>
 <56AF8F54.7030805@ti.com> <56AF917F.9030505@oracle.com>
 <56B14546.4070808@oracle.com> <56B20B2E.7060408@ti.com>
 <56B2201B.7020205@ti.com>
 <20160203195905.GC10826@n2100.arm.linux.org.uk>
 <56B33BAC.6020303@ti.com>
Message-ID: <20160208171009.GP10826@n2100.arm.linux.org.uk>

On Thu, Feb 04, 2016 at 01:53:16PM +0200, Grygorii Strashko wrote:
> This patch boot/reboot tested on k2hk-evm (LPAE=y), ping works (with netcp regression fixed)
> Tested-by: Grygorii Strashko <grygorii.strashko at ti.com>

Thanks.  I've pushed /both/ patches out into linux-next, even though
no one's tested the second patch.

I'll wait for some progress on the TI side though; I'm unable to do
anything further on kexec until there's some movement on the items
I've requested (either kexec userspace tool patches, so I can test
locally, or a tested kexec kernel patch updated for these two changes.)

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From yang.shi at linaro.org  Mon Feb  8 09:12:21 2016
From: yang.shi at linaro.org (Shi, Yang)
Date: Mon, 8 Feb 2016 09:12:21 -0800
Subject: [PATCH] arm64: disable kasan when accessing frame->fp in
 unwind_frame
In-Reply-To: <56B856F5.5080606@virtuozzo.com>
References: <1454713487-5239-1-git-send-email-yang.shi@linaro.org>
 <56B856F5.5080606@virtuozzo.com>
Message-ID: <56B8CC75.1000508@linaro.org>

On 2/8/2016 12:51 AM, Andrey Ryabinin wrote:
>
>
> On 02/06/2016 02:04 AM, Yang Shi wrote:
>>
>>   #include <asm/irq.h>
>>   #include <asm/stacktrace.h>
>> @@ -64,7 +65,9 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
>>   		return -EINVAL;
>>
>>   	frame->sp = fp + 0x10;
>> +	kasan_disable_current();
>>   	frame->fp = *(unsigned long *)(fp);
>
> It would be better to use READ_ONCE_NOCHECK() here.
> See f7d27c35ddff7 ("x86/mm, kasan: Silence KASAN warnings in get_wchan()") which solves the same problem for x86.

Thanks for the suggestion, I'm going to try it soon.

>
>> +	kasan_enable_current();
>>   	frame->pc = *(unsigned long *)(fp + 8);
>
> Why you left frame->pc out of scope? This line could trigger kasan as well.

Actually, it was not reported as frequently as the first one. In my 
first a couple of boot test, it was not triggered before I came up with 
the patch. The first one is triggered every time.

It will be fixed in v2 too.

Thanks,
Yang

>
>>
>>   #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>>



From gregory.clement at free-electrons.com  Mon Feb  8 09:14:08 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  8 Feb 2016 18:14:08 +0100
Subject: [PATCH v3 00/12] Add support for the Armada 3700 SoC an mvebu ARM64
 based
Message-ID: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>

This series introduce the support of the Armada 3700 family: it is the
first ARM64 SoC of the mvebu family submitted to the mainline!

Currently there are two members of the Armada 3700 family, the only
difference is the number of core: the Armada 3710 comes with one
Cortex-A53 whereas the Armada 3720 comes with 2 Cortex-A53. In this
series we enabled only the minimum to boot, pinctrl and clock tree
will come soon.

The changes in this third version are very small (see the changelog).

The first two patches patches are here to be able to use the the
ARCH_MVEBU for the Armada 3700 SoCs. The first ones is only here to
have standalone series but it comes from Thomas Petazzoni's series:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/472625

The third patch introduces a new serial driver for the uart used on
this SoC. The driver remains simple even if the hardware is capable of
doing more.

The forth one adapts the ahci driver to support the Armada 3700 SoC.
The forth patch updates the binding documentation with the new
compatible string.

The fifth patch adds a new entry Kconfig entry for this SoC family.

I took the opportunity of this series to tidy up the Marvell related
files in the binding documentation with the seventh patch.

The eighth patch introduces the compatible string for the SoCs of the
Armada 3700 family.

The ninth patch could be considered as the bulk of this series: it
adds the device tree files for the Armada 3700 SoCs and for the
reference board.

With the introduction of this new family the MAINTAINERS file, the
Marvell README and the ARM64 defconfig files have to be updated: it is
the purpose of the last 3 patches.

The patches 3 and 4 could be taken directly by the maintainer of their
respective subsystem as there is no dependency at all with the rest of
the series. I think that the rest of the series should go through the
arm-soc maintainer but in doubt I also added the ARM64 maintainer as
suggested by get_maintainer.pl.

Thanks,

Gregory

Changelog:
v1 -> v2
- Added Rob acked-by on patches 3, 6 and 7
- Used armada3700_uart instead of mvebu_uart for the uart driver:
  suggested by Mark
- In mvebu-uart, do not use anymore TTY_MAJOR, or ttyS, but dynamic
  major and ttyMV: pointed by Alan
- Use tty_termios_copy_hw in mvebu_uart_set_termios: suggested by Alan
- Use ARCH_MVEBU instead of creating ARCH_ARMADA_3700: suggested by
  Jisheng
- Added a new irqchip pacthes to fix build on ARM64 when ARCH_MVEBU is
  selected
- Removed marvell,armada3700 from the device tree binding and directly
  used marvell,armada3710 for common feature: pointed by Rob
- Fix memory node with coorect size in armada-3720-db.dts: suggested
  by Mark

v2 -> v3
- Renamed the remaining ttyS into ttyMV: reported by Greg KH
- Fixed the order of the compatible in the example of the binding
  documentation: pointed by Rob
- Fix a typo in Kconfig entry: pointed by Thomas Petazzoni

Gregory CLEMENT (9):
  irqchip: armada-370-xp: do not enable it by default when ARCH_MVEBU is
    selected
  arm64: add mvebu architecture entry
  Documentation: dt-bindings: Add a new compatible for the Armada 3700
  Documentation: dt: Tidy up the Marvell related files
  devicetree: bindings: add DT binding for the Marvell Armada 3700 SoC
    family
  arm64: dts: add the Marvell Armada 3700 family and a development board
  MAINTAINERS: Extend dts entry for ARM64 mvebu files
  Documentation: arm: update supported Marvell EBU processors
  arm64: defconfig: enable Armada 3700 related config

Lior Amsalem (1):
  ata: ahci_mvebu: add support for Armada 3700 variant

Thomas Petazzoni (1):
  irqchip: armada-370-xp: add Kconfig option for the driver

Wilson Ding (1):
  serial: mvebu-uart: initial support for Armada-3700 serial port

 Documentation/arm/Marvell/README                   |  13 +
 .../arm/{ => marvell}/armada-370-xp-pmsu.txt       |   0
 .../bindings/arm/{ => marvell}/armada-370-xp.txt   |   0
 .../bindings/arm/{ => marvell}/armada-375.txt      |   0
 .../bindings/arm/marvell/armada-37xx.txt           |  16 +
 .../{ => marvell}/armada-380-mpcore-soc-ctrl.txt   |   0
 .../bindings/arm/{ => marvell}/armada-38x.txt      |   0
 .../bindings/arm/{ => marvell}/armada-39x.txt      |   0
 .../arm/{ => marvell}/armada-cpu-reset.txt         |   0
 .../arm/{ => marvell}/coherency-fabric.txt         |   0
 .../bindings/arm/{ => marvell}/kirkwood.txt        |   0
 .../bindings/arm/{ => marvell}/marvell,berlin.txt  |   0
 .../bindings/arm/{ => marvell}/marvell,dove.txt    |   0
 .../arm/{ => marvell}/marvell,kirkwood.txt         |   0
 .../arm/{ => marvell}/mvebu-cpu-config.txt         |   0
 .../arm/{ => marvell}/mvebu-system-controller.txt  |   0
 .../devicetree/bindings/ata/ahci-platform.txt      |   1 +
 .../devicetree/bindings/tty/serial/mvebu-uart.txt  |  13 +
 Documentation/kernel-parameters.txt                |   6 +
 MAINTAINERS                                        |   1 +
 arch/arm64/Kconfig.platforms                       |   6 +
 arch/arm64/boot/dts/marvell/Makefile               |   4 +
 arch/arm64/boot/dts/marvell/armada-371x.dtsi       |  53 ++
 arch/arm64/boot/dts/marvell/armada-3720-db.dts     |  86 +++
 arch/arm64/boot/dts/marvell/armada-372x.dtsi       |  63 ++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi       | 131 +++++
 arch/arm64/configs/defconfig                       |   5 +
 drivers/ata/ahci_mvebu.c                           |  14 +-
 drivers/irqchip/Kconfig                            |   4 +
 drivers/irqchip/Makefile                           |   2 +-
 drivers/tty/serial/Kconfig                         |  22 +
 drivers/tty/serial/Makefile                        |   1 +
 drivers/tty/serial/mvebu-uart.c                    | 650 +++++++++++++++++++++
 include/uapi/linux/serial_core.h                   |   3 +
 34 files changed, 1088 insertions(+), 6 deletions(-)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp-pmsu.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-375.txt (100%)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-380-mpcore-soc-ctrl.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-38x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-39x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-cpu-reset.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/coherency-fabric.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,berlin.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,dove.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-cpu-config.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-system-controller.txt (100%)
 create mode 100644 Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
 create mode 100644 arch/arm64/boot/dts/marvell/armada-371x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-db.dts
 create mode 100644 arch/arm64/boot/dts/marvell/armada-372x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-37xx.dtsi
 create mode 100644 drivers/tty/serial/mvebu-uart.c

-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  8 09:14:09 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  8 Feb 2016 18:14:09 +0100
Subject: [PATCH v3 01/12] irqchip: armada-370-xp: add Kconfig option for the
 driver
In-Reply-To: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454951660-13289-2-git-send-email-gregory.clement@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Instead of building the irq-armada-370-xp driver directly when
CONFIG_ARCH_MVEBU is enabled, this commit introduces an intermediate
CONFIG_ARMADA_370_XP_IRQ hidden Kconfig option.

This allows this option to select other interrupt-related Kconfig
options (which will be needed in follow-up commits) rather than having
such selects done from arch/arm/mach-<foo>/.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/irqchip/Kconfig  | 5 +++++
 drivers/irqchip/Makefile | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 715923d5236c..e2cab879d641 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -60,6 +60,11 @@ config ARM_VIC_NR
 	  The maximum number of VICs available in the system, for
 	  power management.
 
+config ARMADA_370_XP_IRQ
+	bool
+	default y if ARCH_MVEBU
+	select GENERIC_IRQ_CHIP
+
 config ATMEL_AIC_IRQ
 	bool
 	select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 18caacb60d58..30dba044d0b8 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -5,7 +5,6 @@ obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2836.o
 obj-$(CONFIG_ARCH_EXYNOS)		+= exynos-combiner.o
 obj-$(CONFIG_ARCH_HIP04)		+= irq-hip04.o
 obj-$(CONFIG_ARCH_MMP)			+= irq-mmp.o
-obj-$(CONFIG_ARCH_MVEBU)		+= irq-armada-370-xp.o
 obj-$(CONFIG_IRQ_MXS)			+= irq-mxs.o
 obj-$(CONFIG_ARCH_TEGRA)		+= irq-tegra.o
 obj-$(CONFIG_ARCH_S3C24XX)		+= irq-s3c24xx.o
@@ -28,6 +27,7 @@ obj-$(CONFIG_ARM_GIC_V3_ITS)		+= irq-gic-v3-its.o irq-gic-v3-its-pci-msi.o irq-g
 obj-$(CONFIG_HISILICON_IRQ_MBIGEN)	+= irq-mbigen.o
 obj-$(CONFIG_ARM_NVIC)			+= irq-nvic.o
 obj-$(CONFIG_ARM_VIC)			+= irq-vic.o
+obj-$(CONFIG_ARMADA_370_XP_IRQ)		+= irq-armada-370-xp.o
 obj-$(CONFIG_ATMEL_AIC_IRQ)		+= irq-atmel-aic-common.o irq-atmel-aic.o
 obj-$(CONFIG_ATMEL_AIC5_IRQ)	+= irq-atmel-aic-common.o irq-atmel-aic5.o
 obj-$(CONFIG_I8259)			+= irq-i8259.o
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  8 09:14:10 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  8 Feb 2016 18:14:10 +0100
Subject: [PATCH v3 02/12] irqchip: armada-370-xp: do not enable it by default
 when ARCH_MVEBU is selected
In-Reply-To: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454951660-13289-3-git-send-email-gregory.clement@free-electrons.com>

The irq-armada-370-xp driver can only be built for ARM 32 bits. The mvebu
family had grown with a new ARM64 SoC which will also select the
ARCH_MEVBU configuration. Since "ARM: mvebu: use the ARMADA_370_XP_IRQ
option", the ARM32 mvebu SoC directly select this new option. Selecting
it by default when ARCH_MEVBU is selected is no more needed.

This patch removes this dependency, thanks to this, a kernel for ARM64
mvebu SoC can be built without error due this driver.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/irqchip/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index e2cab879d641..b6e7e86a57e1 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -62,7 +62,6 @@ config ARM_VIC_NR
 
 config ARMADA_370_XP_IRQ
 	bool
-	default y if ARCH_MVEBU
 	select GENERIC_IRQ_CHIP
 
 config ATMEL_AIC_IRQ
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  8 09:14:11 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  8 Feb 2016 18:14:11 +0100
Subject: [PATCH v3 03/12] serial: mvebu-uart: initial support for Armada-3700
 serial port
In-Reply-To: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454951660-13289-4-git-send-email-gregory.clement@free-electrons.com>

From: Wilson Ding <dingwei at marvell.com>

Armada-3700's uart is a simple serial port, which doesn't
support. Configuring the modem control lines. The uart port has a 32
bytes Tx FIFO and a 64 bytes Rx FIFO

The uart driver implements the uart core operations. It also support the
system (early) console based on Armada-3700's serial port.

Known Issue:

The uart driver currently doesn't support clock programming, which means
the baud-rate stays with the default value configured by the bootloader
at boot time

[gregory.clement at free-electrons.com: Rewrite many part which are too long
to enumerate]

Signed-off-by: Wilson Ding <dingwei at marvell.com>
Signed-off-by: Nadav Haklai <nadavh at marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/tty/serial/mvebu-uart.txt  |  13 +
 Documentation/kernel-parameters.txt                |   6 +
 drivers/tty/serial/Kconfig                         |  22 +
 drivers/tty/serial/Makefile                        |   1 +
 drivers/tty/serial/mvebu-uart.c                    | 650 +++++++++++++++++++++
 include/uapi/linux/serial_core.h                   |   3 +
 6 files changed, 695 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
 create mode 100644 drivers/tty/serial/mvebu-uart.c

diff --git a/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
new file mode 100644
index 000000000000..6087defd9f93
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
@@ -0,0 +1,13 @@
+* Marvell UART : Non standard UART used in some of Marvell EBU SoCs (e.g., Armada-3700)
+
+Required properties:
+- compatible: "marvell,armada-3700-uart"
+- reg: offset and length of the register set for the device.
+- interrupts: device interrupt
+
+Example:
+	serial at 12000 {
+		compatible = "marvell,armada-3700-uart";
+		reg = <0x12000 0x400>;
+		interrupts = <43>;
+	};
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 87d40a72f6a1..ea0aba48d616 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1058,6 +1058,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			A valid base address must be provided, and the serial
 			port must already be setup and configured.
 
+		armada3700_uart,<addr>
+			Start an early, polled-mode console on the
+			Armada 3700 serial port at the specified
+			address. The serial port must already be setup
+			and configured. Options are not yet supported.
+
 	earlyprintk=	[X86,SH,BLACKFIN,ARM,M68k]
 			earlyprintk=vga
 			earlyprintk=efi
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 39721ec4f415..b291f934d51b 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1606,6 +1606,28 @@ config SERIAL_STM32_CONSOLE
 	depends on SERIAL_STM32=y
 	select SERIAL_CORE_CONSOLE
 
+config SERIAL_MVEBU_UART
+	bool "Marvell EBU serial port support"
+	select SERIAL_CORE
+	help
+	  This driver is for Marvell EBU SoC's UART. If you have a machine
+	  based on the Armada-3700 SoC and wish to use the on-board serial
+	  port,
+	  say 'Y' here.
+	  Otherwise, say 'N'.
+
+config SERIAL_MVEBU_CONSOLE
+	bool "Console on Marvell EBU serial port"
+	depends on SERIAL_MVEBU_UART
+	select SERIAL_CORE_CONSOLE
+	select SERIAL_EARLYCON
+	default y
+	help
+	  Say 'Y' here if you wish to use Armada-3700 UART as the system console.
+	  (the system console is the device which receives all kernel messages
+	  and warnings and which allows logins in single user mode)
+	  Otherwise, say 'N'.
+
 endmenu
 
 config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index b391c9b31960..988167595330 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
 obj-$(CONFIG_SERIAL_MEN_Z135)	+= men_z135_uart.o
 obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
 obj-$(CONFIG_SERIAL_STM32)	+= stm32-usart.o
+obj-$(CONFIG_SERIAL_MVEBU_UART)	+= mvebu-uart.o
 
 # GPIOLIB helpers for modem control lines
 obj-$(CONFIG_SERIAL_MCTRL_GPIO)	+= serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
new file mode 100644
index 000000000000..008ef0ae86d4
--- /dev/null
+++ b/drivers/tty/serial/mvebu-uart.c
@@ -0,0 +1,650 @@
+/*
+* ***************************************************************************
+* Copyright (C) 2015 Marvell International Ltd.
+* ***************************************************************************
+* This program is free software: you can redistribute it and/or modify it
+* under the terms of the GNU General Public License as published by the Free
+* Software Foundation, either version 2 of the License, or any later version.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+* GNU General Public License for more details.
+*
+* 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/clk.h>
+#include <linux/console.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/slab.h>
+#include <linux/tty.h>
+#include <linux/tty_flip.h>
+
+/* Register Map */
+#define UART_RBR		0x00
+#define  RBR_BRK_DET		BIT(15)
+#define  RBR_FRM_ERR_DET	BIT(14)
+#define  RBR_PAR_ERR_DET	BIT(13)
+#define  RBR_OVR_ERR_DET	BIT(12)
+
+#define UART_TSH		0x04
+
+#define UART_CTRL		0x08
+#define  CTRL_SOFT_RST		BIT(31)
+#define  CTRL_TXFIFO_RST	BIT(15)
+#define  CTRL_RXFIFO_RST	BIT(14)
+#define  CTRL_ST_MIRR_EN	BIT(13)
+#define  CTRL_LPBK_EN		BIT(12)
+#define  CTRL_SND_BRK_SEQ	BIT(11)
+#define  CTRL_PAR_EN		BIT(10)
+#define  CTRL_TWO_STOP		BIT(9)
+#define  CTRL_TX_HFL_INT	BIT(8)
+#define  CTRL_RX_HFL_INT	BIT(7)
+#define  CTRL_TX_EMP_INT	BIT(6)
+#define  CTRL_TX_RDY_INT	BIT(5)
+#define  CTRL_RX_RDY_INT	BIT(4)
+#define  CTRL_BRK_DET_INT	BIT(3)
+#define  CTRL_FRM_ERR_INT	BIT(2)
+#define  CTRL_PAR_ERR_INT	BIT(1)
+#define  CTRL_OVR_ERR_INT	BIT(0)
+#define  CTRL_RX_INT			(CTRL_RX_RDY_INT | CTRL_BRK_DET_INT |\
+	CTRL_FRM_ERR_INT | CTRL_PAR_ERR_INT | CTRL_OVR_ERR_INT)
+
+#define UART_STAT		0x0c
+#define  STAT_TX_FIFO_EMP	BIT(13)
+#define  STAT_RX_FIFO_EMP	BIT(12)
+#define  STAT_TX_FIFO_FUL	BIT(11)
+#define  STAT_TX_FIFO_HFL	BIT(10)
+#define  STAT_RX_TOGL		BIT(9)
+#define  STAT_RX_FIFO_FUL	BIT(8)
+#define  STAT_RX_FIFO_HFL	BIT(7)
+#define  STAT_TX_EMP		BIT(6)
+#define  STAT_TX_RDY		BIT(5)
+#define  STAT_RX_RDY		BIT(4)
+#define  STAT_BRK_DET		BIT(3)
+#define  STAT_FRM_ERR		BIT(2)
+#define  STAT_PAR_ERR		BIT(1)
+#define  STAT_OVR_ERR		BIT(0)
+#define  STAT_BRK_ERR		(STAT_BRK_DET | STAT_FRM_ERR | STAT_FRM_ERR\
+				 | STAT_PAR_ERR | STAT_OVR_ERR)
+
+#define UART_BRDV		0x10
+
+#define MVEBU_NR_UARTS		1
+
+#define MVEBU_UART_TYPE		"mvebu-uart"
+
+static struct uart_port mvebu_uart_ports[MVEBU_NR_UARTS];
+
+struct mvebu_uart_data {
+	struct uart_port *port;
+	struct clk       *clk;
+};
+
+/* Core UART Driver Operations */
+static unsigned int mvebu_uart_tx_empty(struct uart_port *port)
+{
+	unsigned long flags;
+	unsigned int st;
+
+	spin_lock_irqsave(&port->lock, flags);
+	st = readl(port->membase + UART_STAT);
+	spin_unlock_irqrestore(&port->lock, flags);
+
+	return (st & STAT_TX_FIFO_EMP) ? TIOCSER_TEMT : 0;
+}
+
+static unsigned int mvebu_uart_get_mctrl(struct uart_port *port)
+{
+	return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
+}
+
+static void mvebu_uart_set_mctrl(struct uart_port *port,
+				 unsigned int mctrl)
+{
+/*
+ * Even if we do not support configuring the modem control lines, this
+ * function must be proided to the serial core
+ */
+}
+
+static void mvebu_uart_stop_tx(struct uart_port *port)
+{
+	unsigned int ctl = readl(port->membase + UART_CTRL);
+
+	ctl &= ~CTRL_TX_RDY_INT;
+	writel(ctl, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_start_tx(struct uart_port *port)
+{
+	unsigned int ctl = readl(port->membase + UART_CTRL);
+
+	ctl |= CTRL_TX_RDY_INT;
+	writel(ctl, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_stop_rx(struct uart_port *port)
+{
+	unsigned int ctl = readl(port->membase + UART_CTRL);
+
+	ctl &= ~CTRL_RX_INT;
+	writel(ctl, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_break_ctl(struct uart_port *port, int brk)
+{
+	unsigned int ctl;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port->lock, flags);
+	ctl = readl(port->membase + UART_CTRL);
+	if (brk == -1)
+		ctl |= CTRL_SND_BRK_SEQ;
+	else
+		ctl &= ~CTRL_SND_BRK_SEQ;
+	writel(ctl, port->membase + UART_CTRL);
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static void mvebu_uart_rx_chars(struct uart_port *port, unsigned int status)
+{
+	struct tty_port *tport = &port->state->port;
+	unsigned char ch = 0;
+	char flag = 0;
+
+	do {
+		if (status & STAT_RX_RDY) {
+			ch = readl(port->membase + UART_RBR);
+			ch &= 0xff;
+			flag = TTY_NORMAL;
+			port->icount.rx++;
+
+			if (status & STAT_PAR_ERR)
+				port->icount.parity++;
+		}
+
+		if (status & STAT_BRK_DET) {
+			port->icount.brk++;
+			status &= ~(STAT_FRM_ERR | STAT_PAR_ERR);
+			if (uart_handle_break(port))
+				goto ignore_char;
+		}
+
+		if (status & STAT_OVR_ERR)
+			port->icount.overrun++;
+
+		if (status & STAT_FRM_ERR)
+			port->icount.frame++;
+
+		if (uart_handle_sysrq_char(port, ch))
+			goto ignore_char;
+
+		if (status & port->ignore_status_mask & STAT_PAR_ERR)
+			status &= ~STAT_RX_RDY;
+
+		status &= port->read_status_mask;
+
+		if (status & STAT_PAR_ERR)
+			flag = TTY_PARITY;
+
+		status &= ~port->ignore_status_mask;
+
+		if (status & STAT_RX_RDY)
+			tty_insert_flip_char(tport, ch, flag);
+
+		if (status & STAT_BRK_DET)
+			tty_insert_flip_char(tport, 0, TTY_BREAK);
+
+		if (status & STAT_FRM_ERR)
+			tty_insert_flip_char(tport, 0, TTY_FRAME);
+
+		if (status & STAT_OVR_ERR)
+			tty_insert_flip_char(tport, 0, TTY_OVERRUN);
+
+ignore_char:
+		status = readl(port->membase + UART_STAT);
+	} while (status & (STAT_RX_RDY | STAT_BRK_DET));
+
+	tty_flip_buffer_push(tport);
+}
+
+static void mvebu_uart_tx_chars(struct uart_port *port, unsigned int status)
+{
+	struct circ_buf *xmit = &port->state->xmit;
+	unsigned int count;
+	unsigned int st;
+
+	if (port->x_char) {
+		writel(port->x_char, port->membase + UART_TSH);
+		port->icount.tx++;
+		port->x_char = 0;
+		return;
+	}
+
+	if (uart_circ_empty(xmit) || uart_tx_stopped(port)) {
+		mvebu_uart_stop_tx(port);
+		return;
+	}
+
+	for (count = 0; count < port->fifosize; count++) {
+		writel(xmit->buf[xmit->tail], port->membase + UART_TSH);
+		xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+		port->icount.tx++;
+
+		if (uart_circ_empty(xmit))
+			break;
+
+		st = readl(port->membase + UART_STAT);
+		if (st & STAT_TX_FIFO_FUL)
+			break;
+	}
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+
+	if (uart_circ_empty(xmit))
+		mvebu_uart_stop_tx(port);
+}
+
+static irqreturn_t mvebu_uart_isr(int irq, void *dev_id)
+{
+	struct uart_port *port = (struct uart_port *)dev_id;
+	unsigned int st = readl(port->membase + UART_STAT);
+
+	if (st & (STAT_RX_RDY | STAT_OVR_ERR | STAT_FRM_ERR | STAT_BRK_DET))
+		mvebu_uart_rx_chars(port, st);
+
+	if (st & STAT_TX_RDY)
+		mvebu_uart_tx_chars(port, st);
+
+	return IRQ_HANDLED;
+}
+
+static int mvebu_uart_startup(struct uart_port *port)
+{
+	int ret;
+
+	writel(CTRL_TXFIFO_RST | CTRL_RXFIFO_RST,
+	       port->membase + UART_CTRL);
+	udelay(1);
+	writel(CTRL_RX_INT, port->membase + UART_CTRL);
+
+	ret = request_irq(port->irq, mvebu_uart_isr, port->irqflags, "serial",
+			  port);
+	if (ret) {
+		dev_err(port->dev, "failed to request irq\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static void mvebu_uart_shutdown(struct uart_port *port)
+{
+	writel(0, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_set_termios(struct uart_port *port,
+				   struct ktermios *termios,
+				   struct ktermios *old)
+{
+	unsigned long flags;
+	unsigned int baud;
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	port->read_status_mask = STAT_RX_RDY | STAT_OVR_ERR |
+		STAT_TX_RDY | STAT_TX_FIFO_FUL;
+
+	if (termios->c_iflag & INPCK)
+		port->read_status_mask |= STAT_FRM_ERR | STAT_PAR_ERR;
+
+	port->ignore_status_mask = 0;
+	if (termios->c_iflag & IGNPAR)
+		port->ignore_status_mask |=
+			STAT_FRM_ERR | STAT_PAR_ERR | STAT_OVR_ERR;
+
+	if ((termios->c_cflag & CREAD) == 0)
+		port->ignore_status_mask |= STAT_RX_RDY | STAT_BRK_ERR;
+
+	if (old)
+		tty_termios_copy_hw(termios, old);
+
+	baud = uart_get_baud_rate(port, termios, old, 0, 460800);
+	uart_update_timeout(port, termios->c_cflag, baud);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *mvebu_uart_type(struct uart_port *port)
+{
+	return MVEBU_UART_TYPE;
+}
+
+static void mvebu_uart_release_port(struct uart_port *port)
+{
+	/* Nothing to do here */
+}
+
+static int mvebu_uart_request_port(struct uart_port *port)
+{
+	return 0;
+}
+
+#ifdef CONFIG_CONSOLE_POLL
+static int mvebu_uart_get_poll_char(struct uart_port *port)
+{
+	unsigned int st = readl(port->membase + UART_STAT);
+
+	if (!(st & STAT_RX_RDY))
+		return NO_POLL_CHAR;
+
+	return readl(port->membase + UART_RBR);
+}
+
+static void mvebu_uart_put_poll_char(struct uart_port *port, unsigned char c)
+{
+	unsigned int st;
+
+	for (;;) {
+		st = readl(port->membase + UART_STAT);
+
+		if (!(st & STAT_TX_FIFO_FUL))
+			break;
+
+		udelay(1);
+	}
+
+	writel(c, port->membase + UART_TSH);
+}
+#endif
+
+static const struct uart_ops mvebu_uart_ops = {
+	.tx_empty	= mvebu_uart_tx_empty,
+	.set_mctrl	= mvebu_uart_set_mctrl,
+	.get_mctrl	= mvebu_uart_get_mctrl,
+	.stop_tx	= mvebu_uart_stop_tx,
+	.start_tx	= mvebu_uart_start_tx,
+	.stop_rx	= mvebu_uart_stop_rx,
+	.break_ctl	= mvebu_uart_break_ctl,
+	.startup	= mvebu_uart_startup,
+	.shutdown	= mvebu_uart_shutdown,
+	.set_termios	= mvebu_uart_set_termios,
+	.type		= mvebu_uart_type,
+	.release_port	= mvebu_uart_release_port,
+	.request_port	= mvebu_uart_request_port,
+#ifdef CONFIG_CONSOLE_POLL
+	.poll_get_char	= mvebu_uart_get_poll_char,
+	.poll_put_char	= mvebu_uart_put_poll_char,
+#endif
+};
+
+/* Console Driver Operations  */
+
+#ifdef CONFIG_SERIAL_MVEBU_CONSOLE
+/* Early Console */
+static void mvebu_uart_putc(struct uart_port *port, int c)
+{
+	unsigned int st;
+
+	for (;;) {
+		st = readl(port->membase + UART_STAT);
+		if (!(st & STAT_TX_FIFO_FUL))
+			break;
+	}
+
+	writel(c, port->membase + UART_TSH);
+
+	for (;;) {
+		st = readl(port->membase + UART_STAT);
+		if (st & STAT_TX_FIFO_EMP)
+			break;
+	}
+}
+
+static void mvebu_uart_putc_early_write(struct console *con,
+					const char *s,
+					unsigned n)
+{
+	struct earlycon_device *dev = con->data;
+
+	uart_console_write(&dev->port, s, n, mvebu_uart_putc);
+}
+
+static int __init
+mvebu_uart_early_console_setup(struct earlycon_device *device,
+			       const char *opt)
+{
+	if (!device->port.membase)
+		return -ENODEV;
+
+	device->con->write = mvebu_uart_putc_early_write;
+
+	return 0;
+}
+
+EARLYCON_DECLARE(ar3700_uart, mvebu_uart_early_console_setup);
+OF_EARLYCON_DECLARE(ar3700_uart, "marvell,armada-3700-uart",
+		    mvebu_uart_early_console_setup);
+
+static void wait_for_xmitr(struct uart_port *port)
+{
+	u32 val;
+
+	readl_poll_timeout_atomic(port->membase + UART_STAT, val,
+				  (val & STAT_TX_EMP), 1, 10000);
+}
+
+static void mvebu_uart_console_putchar(struct uart_port *port, int ch)
+{
+	wait_for_xmitr(port);
+	writel(ch, port->membase + UART_TSH);
+}
+
+static void mvebu_uart_console_write(struct console *co, const char *s,
+				     unsigned int count)
+{
+	struct uart_port *port = &mvebu_uart_ports[co->index];
+	unsigned long flags;
+	unsigned int ier;
+	int locked = 1;
+
+	if (oops_in_progress)
+		locked = spin_trylock_irqsave(&port->lock, flags);
+	else
+		spin_lock_irqsave(&port->lock, flags);
+
+	ier = readl(port->membase + UART_CTRL) &
+		(CTRL_RX_INT | CTRL_TX_RDY_INT);
+	writel(0, port->membase + UART_CTRL);
+
+	uart_console_write(port, s, count, mvebu_uart_console_putchar);
+
+	wait_for_xmitr(port);
+
+	if (ier)
+		writel(ier, port->membase + UART_CTRL);
+
+	if (locked)
+		spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static int mvebu_uart_console_setup(struct console *co, char *options)
+{
+	struct uart_port *port;
+	int baud = 9600;
+	int bits = 8;
+	int parity = 'n';
+	int flow = 'n';
+
+	if (co->index < 0 || co->index >= MVEBU_NR_UARTS)
+		return -EINVAL;
+
+	port = &mvebu_uart_ports[co->index];
+
+	if (!port->mapbase || !port->membase) {
+		pr_debug("console on ttyMV%i not present\n", co->index);
+		return -ENODEV;
+	}
+
+	if (options)
+		uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+	return uart_set_options(port, co, baud, parity, bits, flow);
+}
+
+static struct uart_driver mvebu_uart_driver;
+
+static struct console mvebu_uart_console = {
+	.name	= "ttyMV",
+	.write	= mvebu_uart_console_write,
+	.device	= uart_console_device,
+	.setup	= mvebu_uart_console_setup,
+	.flags	= CON_PRINTBUFFER,
+	.index	= -1,
+	.data	= &mvebu_uart_driver,
+};
+
+static int __init mvebu_uart_console_init(void)
+{
+	register_console(&mvebu_uart_console);
+	return 0;
+}
+
+console_initcall(mvebu_uart_console_init);
+
+
+#endif /* CONFIG_SERIAL_MVEBU_CONSOLE */
+
+static struct uart_driver mvebu_uart_driver = {
+	.owner			= THIS_MODULE,
+	.driver_name		= "serial",
+	.dev_name		= "ttyMV",
+	.nr			= MVEBU_NR_UARTS,
+#ifdef CONFIG_SERIAL_MVEBU_CONSOLE
+	.cons			= &mvebu_uart_console,
+#endif
+};
+
+static int mvebu_uart_probe(struct platform_device *pdev)
+{
+	struct resource *reg = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	struct resource *irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+	struct uart_port *port;
+	struct mvebu_uart_data *data;
+	int ret;
+
+	if (!reg || !irq) {
+		dev_err(&pdev->dev, "no registers/irq defined\n");
+		return -EINVAL;
+	}
+
+	port = &mvebu_uart_ports[0];
+
+	spin_lock_init(&port->lock);
+
+	port->dev        = &pdev->dev;
+	port->type       = PORT_MVEBU;
+	port->ops        = &mvebu_uart_ops;
+	port->regshift   = 0;
+
+	port->fifosize   = 32;
+	port->iotype     = UPIO_MEM32;
+	port->flags      = UPF_FIXED_PORT;
+	port->line       = 0; /* single port: force line number to  0 */
+
+	port->irq        = irq->start;
+	port->irqflags   = 0;
+	port->mapbase    = reg->start;
+
+	port->membase = devm_ioremap_resource(&pdev->dev, reg);
+	if (IS_ERR(port->membase))
+		return -PTR_ERR(port->membase);
+
+	data = devm_kzalloc(&pdev->dev, sizeof(struct mvebu_uart_data),
+			    GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->port = port;
+
+	port->private_data = data;
+	platform_set_drvdata(pdev, data);
+
+	ret = uart_add_one_port(&mvebu_uart_driver, port);
+	if (ret)
+		return ret;
+	return 0;
+}
+
+static int mvebu_uart_remove(struct platform_device *pdev)
+{
+	struct mvebu_uart_data *data = platform_get_drvdata(pdev);
+
+	uart_remove_one_port(&mvebu_uart_driver, data->port);
+	data->port->private_data = NULL;
+	data->port->mapbase      = 0;
+	return 0;
+}
+
+/* Match table for of_platform binding */
+static const struct of_device_id mvebu_uart_of_match[] = {
+	{ .compatible = "marvell,armada-3700-uart", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, mvebu_uart_of_match);
+
+static struct platform_driver mvebu_uart_platform_driver = {
+	.probe	= mvebu_uart_probe,
+	.remove	= mvebu_uart_remove,
+	.driver	= {
+		.owner	= THIS_MODULE,
+		.name  = "mvebu-uart",
+		.of_match_table = of_match_ptr(mvebu_uart_of_match),
+	},
+};
+
+static int __init mvebu_uart_init(void)
+{
+	int ret;
+
+	ret = uart_register_driver(&mvebu_uart_driver);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&mvebu_uart_platform_driver);
+	if (ret)
+		uart_unregister_driver(&mvebu_uart_driver);
+
+	return ret;
+}
+
+static void __exit mvebu_uart_exit(void)
+{
+	platform_driver_unregister(&mvebu_uart_platform_driver);
+	uart_unregister_driver(&mvebu_uart_driver);
+}
+
+arch_initcall(mvebu_uart_init);
+module_exit(mvebu_uart_exit);
+
+MODULE_AUTHOR("Wilson Ding <dingwei at marvell.com>");
+MODULE_DESCRIPTION("Marvell Armada-3700 Serial Driver");
+MODULE_LICENSE("GPL");
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 3e5d757407fb..e513a4ee369b 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -261,4 +261,7 @@
 /* STM32 USART */
 #define PORT_STM32	113
 
+/* MVEBU UART */
+#define PORT_MVEBU	114
+
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  8 09:14:18 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  8 Feb 2016 18:14:18 +0100
Subject: [PATCH v3 10/12] MAINTAINERS: Extend dts entry for ARM64 mvebu files
In-Reply-To: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454951660-13289-11-git-send-email-gregory.clement@free-electrons.com>

Extend the mvebu entry to ARM64 device tree sources.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 30aca4aa5467..ad49b62c5abc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1279,6 +1279,7 @@ F:	arch/arm/mach-mvebu/
 F:	drivers/rtc/rtc-armada38x.c
 F:	arch/arm/boot/dts/armada*
 F:	arch/arm/boot/dts/kirkwood*
+F:	arch/arm64/boot/dts/marvell/armada*
 
 
 ARM/Marvell Berlin SoC support
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  8 09:14:19 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  8 Feb 2016 18:14:19 +0100
Subject: [PATCH v3 11/12] Documentation: arm: update supported Marvell EBU
 processors
In-Reply-To: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454951660-13289-12-git-send-email-gregory.clement@free-electrons.com>

Now that we support Armada 37xx, let's add this family of SoC to the
Marvell documentation, and a reference to a link with more details about
those processors. As for Armda 39x, no datasheet is publicly
available at this time.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 Documentation/arm/Marvell/README | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index ae89b67d8e23..ddbc048bb467 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -118,6 +118,19 @@ EBU Armada family
   Linux kernel mach directory: arch/arm/mach-mvebu
   Linux kernel plat directory: none
 
+EBU Armada family ARMv8
+-----------------------
+
+  Armada 3710/3720 Flavors:
+	88F3710
+	88F3720
+
+  Core: ARM Cortex A53 (ARMv8)
+
+  Homepage     : http://www.marvell.com/embedded-processors/armada-3700/
+
+  Device tree descritpion located in arch/arm64/boot/dts/marvell/armada-37*
+
 Avanta family
 -------------
 
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  8 09:14:20 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  8 Feb 2016 18:14:20 +0100
Subject: [PATCH v3 12/12] arm64: defconfig: enable Armada 3700 related config
In-Reply-To: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454951660-13289-13-git-send-email-gregory.clement@free-electrons.com>

This patch enables the configuration for the Armada 3700 family and for
the related driver it uses.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm64/configs/defconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 18ca9fb9e65f..7ca2f0247ec5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -31,6 +31,7 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_ARCH_MVEBU=y
 CONFIG_ARCH_BCM_IPROC=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_ARCH_EXYNOS7=y
@@ -93,6 +94,7 @@ CONFIG_ATA=y
 CONFIG_SATA_AHCI=y
 CONFIG_SATA_AHCI_PLATFORM=y
 CONFIG_AHCI_CEVA=y
+CONFIG_AHCI_MVEBU=y
 CONFIG_AHCI_XGENE=y
 CONFIG_SATA_RCAR=y
 CONFIG_PATA_PLATFORM=y
@@ -132,6 +134,7 @@ CONFIG_SERIAL_MSM_CONSOLE=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SERIAL_XILINX_PS_UART=y
 CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
+CONFIG_SERIAL_MVEBU_UART=y
 CONFIG_VIRTIO_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 CONFIG_I2C=y
@@ -162,6 +165,8 @@ CONFIG_SND_SOC=y
 CONFIG_SND_SOC_RCAR=y
 CONFIG_SND_SOC_AK4613=y
 CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_PLATFORM=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
 CONFIG_USB_OHCI_HCD=y
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  8 09:14:14 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  8 Feb 2016 18:14:14 +0100
Subject: [PATCH v3 06/12] Documentation: dt-bindings: Add a new compatible for
 the Armada 3700
In-Reply-To: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454951660-13289-7-git-send-email-gregory.clement@free-electrons.com>

The AHCI interfaces used in the Armada 3700 has a few differences with
the one used in the Armada 38x, so it deserves its own compatible string.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/ata/ahci-platform.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index c2340eeeb97f..796e2c23e5df 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -13,6 +13,7 @@ Required properties:
   - "hisilicon,hisi-ahci"
   - "ibm,476gtr-ahci"
   - "marvell,armada-380-ahci"
+  - "marvell,armada-3700-ahci"
   - "snps,dwc-ahci"
   - "snps,exynos5440-ahci"
   - "snps,spear-ahci"
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  8 09:14:12 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  8 Feb 2016 18:14:12 +0100
Subject: [PATCH v3 04/12] ata: ahci_mvebu: add support for Armada 3700 variant
In-Reply-To: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454951660-13289-5-git-send-email-gregory.clement@free-electrons.com>

From: Lior Amsalem <alior at marvell.com>

The main difference in the new Armada 3700 is that no address
decoding needs to take place in the driver probe.

[gregory.clement at free-electrons.com: reformulate the commit log]

Signed-off-by: Lior Amsalem <alior at marvell.com>
Reviewed-by: Nadav Haklai <nadavh at marvell.com>
Tested-by: Nadav Haklai <nadavh at marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/ata/ahci_mvebu.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/ata/ahci_mvebu.c b/drivers/ata/ahci_mvebu.c
index f7a7fa81740e..de7128d81e9c 100644
--- a/drivers/ata/ahci_mvebu.c
+++ b/drivers/ata/ahci_mvebu.c
@@ -112,12 +112,15 @@ static int ahci_mvebu_probe(struct platform_device *pdev)
 	if (rc)
 		return rc;
 
-	dram = mv_mbus_dram_info();
-	if (!dram)
-		return -ENODEV;
+	if (of_device_is_compatible(pdev->dev.of_node,
+				    "marvell,armada-380-ahci")) {
+		dram = mv_mbus_dram_info();
+		if (!dram)
+			return -ENODEV;
 
-	ahci_mvebu_mbus_config(hpriv, dram);
-	ahci_mvebu_regret_option(hpriv);
+		ahci_mvebu_mbus_config(hpriv, dram);
+		ahci_mvebu_regret_option(hpriv);
+	}
 
 	rc = ahci_platform_init_host(pdev, hpriv, &ahci_mvebu_port_info,
 				     &ahci_platform_sht);
@@ -133,6 +136,7 @@ disable_resources:
 
 static const struct of_device_id ahci_mvebu_of_match[] = {
 	{ .compatible = "marvell,armada-380-ahci", },
+	{ .compatible = "marvell,armada-3700-ahci", },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, ahci_mvebu_of_match);
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  8 09:14:15 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  8 Feb 2016 18:14:15 +0100
Subject: [PATCH v3 07/12] Documentation: dt: Tidy up the Marvell related files
In-Reply-To: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454951660-13289-8-git-send-email-gregory.clement@free-electrons.com>

Over the last releases we have added more and more Marvell related binding
directly in the arm directory. It's time to have our proper directory
inside it, and move all the files in it.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/arm/{ => marvell}/armada-370-xp-pmsu.txt          | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp.txt     | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-375.txt        | 0
 .../devicetree/bindings/arm/{ => marvell}/armada-380-mpcore-soc-ctrl.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-38x.txt        | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-39x.txt        | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-cpu-reset.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/coherency-fabric.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/kirkwood.txt          | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/marvell,berlin.txt    | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/marvell,dove.txt      | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/marvell,kirkwood.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-cpu-config.txt  | 0
 .../devicetree/bindings/arm/{ => marvell}/mvebu-system-controller.txt     | 0
 14 files changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp-pmsu.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-375.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-380-mpcore-soc-ctrl.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-38x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-39x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-cpu-reset.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/coherency-fabric.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,berlin.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,dove.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-cpu-config.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-system-controller.txt (100%)

diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt b/Documentation/devicetree/bindings/arm/marvell/armada-370-xp-pmsu.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-370-xp-pmsu.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp.txt b/Documentation/devicetree/bindings/arm/marvell/armada-370-xp.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-370-xp.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-370-xp.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-375.txt b/Documentation/devicetree/bindings/arm/marvell/armada-375.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-375.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-375.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-38x.txt b/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-38x.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-39x.txt b/Documentation/devicetree/bindings/arm/marvell/armada-39x.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-39x.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-39x.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-cpu-reset.txt b/Documentation/devicetree/bindings/arm/marvell/armada-cpu-reset.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-cpu-reset.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-cpu-reset.txt
diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/marvell/coherency-fabric.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/coherency-fabric.txt
rename to Documentation/devicetree/bindings/arm/marvell/coherency-fabric.txt
diff --git a/Documentation/devicetree/bindings/arm/kirkwood.txt b/Documentation/devicetree/bindings/arm/marvell/kirkwood.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/kirkwood.txt
rename to Documentation/devicetree/bindings/arm/marvell/kirkwood.txt
diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,berlin.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/marvell,berlin.txt
rename to Documentation/devicetree/bindings/arm/marvell/marvell,berlin.txt
diff --git a/Documentation/devicetree/bindings/arm/marvell,dove.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,dove.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/marvell,dove.txt
rename to Documentation/devicetree/bindings/arm/marvell/marvell,dove.txt
diff --git a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
rename to Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.txt
diff --git a/Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt b/Documentation/devicetree/bindings/arm/marvell/mvebu-cpu-config.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt
rename to Documentation/devicetree/bindings/arm/marvell/mvebu-cpu-config.txt
diff --git a/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/mvebu-system-controller.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/mvebu-system-controller.txt
rename to Documentation/devicetree/bindings/arm/marvell/mvebu-system-controller.txt
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  8 09:14:17 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  8 Feb 2016 18:14:17 +0100
Subject: [PATCH v3 09/12] arm64: dts: add the Marvell Armada 3700 family and a
 development board
In-Reply-To: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454951660-13289-10-git-send-email-gregory.clement@free-electrons.com>

Add initial dtsi files to support Marvell Armada 3700 SoC with Cortex-A53
CPUs. There are two members in this family: the Armada 3710 (Single CPU)
and the Armada 3720 (Dual CPUs).

It also adds a dts file for the Marvell Armada 3720 DB board.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm64/boot/dts/marvell/Makefile           |   4 +
 arch/arm64/boot/dts/marvell/armada-371x.dtsi   |  53 ++++++++++
 arch/arm64/boot/dts/marvell/armada-3720-db.dts |  86 ++++++++++++++++
 arch/arm64/boot/dts/marvell/armada-372x.dtsi   |  63 ++++++++++++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   | 131 +++++++++++++++++++++++++
 5 files changed, 337 insertions(+)
 create mode 100644 arch/arm64/boot/dts/marvell/armada-371x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-db.dts
 create mode 100644 arch/arm64/boot/dts/marvell/armada-372x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-37xx.dtsi

diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index 348f4db4f313..2114af8d312d 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -1,6 +1,10 @@
+# Berlin SoC Family
 dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-dmp.dtb
 dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
 
+# Mvebu SoC Family
+dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
+
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
 clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/marvell/armada-371x.dtsi b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
new file mode 100644
index 000000000000..c9e5325b8ac3
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
@@ -0,0 +1,53 @@
+/*
+ * Device Tree Include file for Marvell Armada 371x family of SoCs
+ * (also named 88F3710)
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "armada-37xx.dtsi"
+
+/ {
+	model = "Marvell Armada 3710 SoC";
+	compatible = "marvell,armada3710", "marvell,armada3700";
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
new file mode 100644
index 000000000000..359050154511
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -0,0 +1,86 @@
+/*
+ * Device Tree file for Marvell Armada 3720 development board
+ * (DB-88F3720-DDR3)
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "armada-372x.dtsi"
+
+/ {
+	model = "Marvell Armada 3720 Development Board DB-88F3720-DDR3";
+	compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x00000000 0x00000000 0x20000000>;
+	};
+
+	soc {
+		internal-regs {
+			/*
+			* Exported on the micro USB connector CON32
+			* through an FTDI
+			*/
+			uart0: serial at 12000 {
+				status = "okay";
+			};
+
+			/* CON31 */
+			usb3 at 58000 {
+				status = "okay";
+			};
+
+			/* CON3 */
+			sata at e0000 {
+			       status = "okay";
+			};
+		};
+	};
+};
+
diff --git a/arch/arm64/boot/dts/marvell/armada-372x.dtsi b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
new file mode 100644
index 000000000000..f292a00ce97c
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
@@ -0,0 +1,63 @@
+/*
+ * Device Tree Include file for Marvell Armada 372x family of SoCs
+ * (also named 88F3720)
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "armada-37xx.dtsi"
+
+/ {
+	model = "Marvell Armada 3720 SoC";
+	compatible = "marvell,armada3720", "marvell,armada3710";
+
+	cpus {
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53","arm,armv8";
+			reg = <0x1>;
+			enable-method = "psci";
+		};
+	};
+
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
new file mode 100644
index 000000000000..ba9df7ff2a72
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -0,0 +1,131 @@
+/*
+ * Device Tree Include file for Marvell Armada 37xx family of SoCs.
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	model = "Marvell Armada 37xx SoC";
+	compatible = "marvell,armada3700";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0>;
+			enable-method = "psci";
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		internal-regs {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "simple-bus";
+			/* 32M internal register @ 0xd000_0000 */
+			ranges = <0x0 0x0 0xd0000000 0x2000000>;
+
+			uart0: serial at 12000 {
+				compatible = "marvell,armada-3700-uart";
+				reg = <0x12000 0x400>;
+				interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+				status = "disabled";
+			};
+
+			usb3 at 58000 {
+				compatible = "generic-xhci";
+				reg = <0x58000 0x4000>;
+				interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+				status = "disabled";
+			};
+
+			sata at e0000 {
+				compatible = "marvell,armada-3700-ahci";
+				reg = <0xe0000 0x2000>;
+				interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+				status = "disabled";
+			};
+
+			gic: interrupt-controller at 1d00000 {
+				compatible = "arm,gic-v3";
+				#interrupt-cells = <3>;
+				interrupt-controller;
+				reg = <0x1d00000 0x10000>, /* GICD */
+				      <0x1d40000 0x40000>; /* GICR */
+			};
+		};
+	};
+};
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  8 09:14:13 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  8 Feb 2016 18:14:13 +0100
Subject: [PATCH v3 05/12] arm64: add mvebu architecture entry
In-Reply-To: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454951660-13289-6-git-send-email-gregory.clement@free-electrons.com>

The Armada 3700 is an mvebu ARM64 SoC using one or two Cortex-A53 cores
depending of the variant.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm64/Kconfig.platforms | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f674bde..c621e69ed170 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -1,5 +1,11 @@
 menu "Platform selection"
 
+config ARCH_MVEBU
+	bool "Marvell EBU SoC Family"
+	help
+	  This enables support for Marvell EBU family such as the
+	  Armada 3700 SoC family.
+
 config ARCH_BCM_IPROC
 	bool "Broadcom iProc SoC Family"
 	help
-- 
2.5.0



From gregory.clement at free-electrons.com  Mon Feb  8 09:14:16 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon,  8 Feb 2016 18:14:16 +0100
Subject: [PATCH v3 08/12] devicetree: bindings: add DT binding for the Marvell
 Armada 3700 SoC family
In-Reply-To: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1454951660-13289-9-git-send-email-gregory.clement@free-electrons.com>

The Marvell Armada 3700 is a family of ARMv8 CA53 SoCs. This commit
introduces the Device Tree binding that documents the top-level
compatible strings for Armada 3700 based platforms.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 .../devicetree/bindings/arm/marvell/armada-37xx.txt      | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
new file mode 100644
index 000000000000..51336e5fc761
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
@@ -0,0 +1,16 @@
+Marvell Armada 37xx Platforms Device Tree Bindings
+--------------------------------------------------
+
+Boards using a SoC of the Marvell Armada 37xx family must carry the
+following root node property:
+
+ - compatible: must contain "marvell,armada3710"
+
+In addition, boards using the Marvell Armada 3720 SoC shall have the
+following property before the previous one:
+
+ - compatible: must contain "marvell,armada3720"
+
+Example:
+
+compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
-- 
2.5.0



From vladimir.murzin at arm.com  Mon Feb  8 09:17:57 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Mon, 08 Feb 2016 17:17:57 +0000
Subject: [PATCH v2 04/10] serial: mps2-uart: add MPS2 UART driver
In-Reply-To: <20160208165226.GA11593@kroah.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
 <1454413199-26573-5-git-send-email-vladimir.murzin@arm.com>
 <20160207071154.GA32017@kroah.com> <56B87928.7020803@arm.com>
 <20160208165226.GA11593@kroah.com>
Message-ID: <56B8CDC5.5010504@arm.com>

On 08/02/16 16:52, Greg KH wrote:
> On Mon, Feb 08, 2016 at 11:16:56AM +0000, Vladimir Murzin wrote:
>> On 07/02/16 07:11, Greg KH wrote:
>>>> +
>>>> +#define SERIAL_NAME "ttyS"
>>>
>>> You can't be "ttyS", there's already a serial port named that, please
>>> use a unique name and a new major/minor number (dynamic ideally).
>>>
>>
>> Hi Greg,
>>
>> I did s/ttyMPS/ttyS per your request for v1 [1]. I'm fine to change it
>> back if you prefer that, but I'd be glad to know what I've been missing?
>>
>> [1] https://lkml.org/lkml/2015/12/13/8
> 
> Yeah, I was wrong, sorry about that, my fault.
> 

I got -EDOUBT from my parser. What should I stick with "ttyS" or "ttyMPS"?

P.S.
Any chance you could look at the rest of the patch?

Cheers
Vladimir

> greg k-h
> 
> 
> 



From maxime.ripard at free-electrons.com  Mon Feb  8 09:19:42 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 8 Feb 2016 18:19:42 +0100
Subject: [PATCH] ARM: dts: sunxi: Fix #interrupt-cells for PIO in H3
In-Reply-To: <20160208093113.GA6268@box2.japko.eu>
References: <20160208093113.GA6268@box2.japko.eu>
Message-ID: <20160208171942.GI31506@lukather>

On Mon, Feb 08, 2016 at 10:31:14AM +0100, Krzysztof Adamski wrote:
> pinctrl-sunxi uses 3 cells to describe interrupt, not 2. It's bank
> number, pin number and flags.
> 
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160208/5f66310f/attachment.sig>

From gabriele.paoloni at huawei.com  Mon Feb  8 09:21:27 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Mon, 8 Feb 2016 17:21:27 +0000
Subject: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host
 controller ECAM compliant
In-Reply-To: <2599997.xBRrI3qHak@wuerfel>
References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
 <3532826.pJr5R5Xa4c@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECACF44@lhreml503-mbs>
 <2599997.xBRrI3qHak@wuerfel>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECAD436@lhreml503-mbs>

Hi Arnd

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 08 February 2016 16:30
> To: Gabriele Paoloni
> Cc: linux-arm-kernel at lists.infradead.org; Guohanjun (Hanjun Guo);
> Wangzhou (B); liudongdong (C); Linuxarm; qiujiang; bhelgaas at google.com;
> Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-pci at vger.kernel.org;
> linux-kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth)
> Subject: Re: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host
> controller ECAM compliant
> 
> On Monday 08 February 2016 15:55:35 Gabriele Paoloni wrote:
> > > Doesn't this break backwards compatibility?
> >
> > Well Hip05/Hip06 SoCs are used into evaluation boards
> > For the Estuary project.
> >
> > https://github.com/hisilicon/estuary
> >
> > As this new driver gets upstream we'll merge this new driver into
> estuary
> > and release a new version of the firmware to support it.
> 
> So what happens to folks running the old firmware then?

So far we haven't released the PCIe nodes dtsi upstream and we think
we can handle the firmware upgrade for our current users either
by pointing them to the updated Estuary branch or by internal 
channels  

> 
> > > I think you need to use a new compatible string in the firmware
> > > if you change the register layout, and then change the driver
> > > to support both the old and the new layout.
> >
> > You are right, for some reason in this patchset I missed the
> Documentation
> > update that I posted in the previous one, i.e.:
> >
> > --- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> > +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> > @@ -23,8 +23,8 @@ Optional properties:
> >  Hip05 Example (note that Hip06 is the same except compatible):
> >         pcie at 0xb0080000 {
> >                 compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
> > -               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0
> 0x2000>;
> > -               reg-names = "rc_dbi", "config";
> > +               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00100000 0
> 0x0f00000>;
> > +               reg-names = "rc_dbi", "ecam-cfg";
> >
> 
> That is not the compatible string, it's an undocumented register set.

Sorry, I misunderstood here, got it now :)

> You can either define the a new compatible string that gives the
> "config"
> registers a new meaning, or you change the binding to allow two either
> a "config" or an "ecam-cfg" register set, and let the driver handle
> both.

As per reply above I think that it would be quite easy for us to
let out current users update the BIOS so I don't think there is any
value in maintaining two version of the drivers one of which will
not be used.

What do you think?

Thanks

Gab

> 
> 	Arnd


From mcoquelin.stm32 at gmail.com  Mon Feb  8 09:23:16 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Mon, 8 Feb 2016 18:23:16 +0100
Subject: [PATCH] pinctrl: stm32: fix compile error and modernize
In-Reply-To: <1454712568-6301-1-git-send-email-linus.walleij@linaro.org>
References: <1454712568-6301-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <CALszF6CYa50SZGys4KmCxkRa0Kp6n1OHdRPUA9C+Lj7erSBjWw@mail.gmail.com>

2016-02-05 23:49 GMT+01:00 Linus Walleij <linus.walleij at linaro.org>:
> - Fix the dev->parent assignment compile error
> - Use gpiochip_get_data() to get the data pointer for the
>   banks
>
> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> Cc: Patrice Chotard <patrice.chotard at st.com>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> I don't even know how to compile test this, I hope it works,
> Maxime can you verify?

Thanks Linus, I just tested your patch with success:
Tested-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>

About the compile testing, I have identified the problem last week,
and sent a v5 of the series.
I will discard this series, and will send you a patch that fixes
compile testing,
and also unneeded dependency with DT bindings header file.

Regards,
Maxime


From linux at arm.linux.org.uk  Mon Feb  8 09:23:02 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Feb 2016 17:23:02 +0000
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <CAKzmTe24iz1Ka7Kkke=ZTVbDGZxxDjBH0m2iEVCQOGuuEpi4Gg@mail.gmail.com>
References: <20160205090246.GE32272@lunn.ch>
 <20160205112907.796afb05@bbrezillon>
 <CAKzmTe20fT8BcRaDaf2gz92KMAK0kEUkaD-kPq_cPF1WKBdroA@mail.gmail.com>
 <87vb632maf.fsf@free-electrons.com>
 <CAKzmTe1AqNQwjcsAULotd010NXuk1AYjj5p6UoqT_Zu=BCHdcw@mail.gmail.com>
 <87mvrf2l6p.fsf@free-electrons.com>
 <87io232kat.fsf@free-electrons.com> <8760y2vqje.fsf@natisbad.org>
 <87twlmdg2b.fsf@natisbad.org>
 <CAKzmTe24iz1Ka7Kkke=ZTVbDGZxxDjBH0m2iEVCQOGuuEpi4Gg@mail.gmail.com>
Message-ID: <20160208172302.GQ10826@n2100.arm.linux.org.uk>

On Sat, Feb 06, 2016 at 04:14:49PM +0100, JM wrote:
> On Fri, Feb 5, 2016 at 10:04 PM, Arnaud Ebalard <arno at natisbad.org> wrote:
> > Hi,
> >
> >> I'll try and do the same now w/ CESA support compiled as module to see
> >> what I get. I'll keep you posted.
> >
> > root at mood:~# insmod /tmp/marvell-cesa.ko
> > [  573.897977] marvell-cesa f1030000.crypto: CESA device successfully registered
> >
> > root at mood:~# uname -a
> > Linux mood 4.4.0.duov2 #2 Fri Feb 5 21:42:49 CET 2016 armv5tel GNU/Linux
> >
> > root at mood:~# zcat /proc/config.gz | grep -i CESA
> > # CONFIG_CRYPTO_DEV_MV_CESA is not set
> > CONFIG_CRYPTO_DEV_MARVELL_CESA=m
> >
> > Cheers,
> >
> > a+
> >
> > ps: my config is temporarily at http://natisbad.org/config-duov2-cesa
> 
> I've built a vanilla 4.4.1 kernel image without any debian-specific
> patches but using the same oldconfig
> (http://heap.ovh/files/config-4.4.1.vanilla).
> 
> # uname -a
> Linux yukikaze 4.4.1.vanilla #1 Sat Feb 6 14:18:19 CET 2016 armv5tel GNU/Linux
> 
> # modprobe marvell_cesa allhwsupport=1
> 
> # dmesg | tail -n1
> [  116.972828] marvell-cesa: probe of f1030000.crypto failed with error -12
> 
> The dtb hasn't changed:
> # diff -s kirkwood-ts219-6282.dtb dtb-4.4.1.vanilla
> Files kirkwood-ts219-6282.dtb and dtb-4.4.1.vanilla are identical
> 
> I am also attaching lsmod: http://heap.ovh/files/lsmod-vanilla-4.4.1
> and full dmesg: http://heap.ovh/files/dmesg-vanilla-4.4.1
> 
> Perhaps I am missing something obvious? I suppose the next step would
> be to build a minimal kernel based on the config for the duov2?

As you have built your own kernel, may I suggest that you add some
debug code into mv_cesa_dev_dma_init(), mv_cesa_get_sram(), and
mv_cesa_probe() to print which of the many locations that returns
-ENOMEM is triggering the above error.

In passing, I notice that:

        cesa->regs = devm_ioremap_resource(dev, res);
        if (IS_ERR(cesa->regs))
                return -ENOMEM;

is wrong.  devm_ioremap_resource() returns an errno-encoded pointer
which should be used to report the error number.  This should be:

        cesa->regs = devm_ioremap_resource(dev, res);
        if (IS_ERR(cesa->regs))
                return PTR_ERR(cesa->regs);

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From linux at arm.linux.org.uk  Mon Feb  8 09:27:00 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Feb 2016 17:27:00 +0000
Subject: [PATCH 1/5] ARM: add EXPORT_SYMBOL of hook_fault_code for PCI
 host modularization
In-Reply-To: <2567476.SknW0BEsQJ@wuerfel>
References: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
 <1454889644-27830-2-git-send-email-paul.gortmaker@windriver.com>
 <2567476.SknW0BEsQJ@wuerfel>
Message-ID: <20160208172700.GR10826@n2100.arm.linux.org.uk>

On Mon, Feb 08, 2016 at 10:53:10AM +0100, Arnd Bergmann wrote:
> On Sunday 07 February 2016 19:00:40 Paul Gortmaker wrote:
> > In a discussion of a previous patch set[1], it was suggested that
> > modularizing some of the PCI host support would be good to keep
> > multi platform bzImage sizes smaller.
> > 
> > Two of the files that are candidates for conversion to tristate
> > from bool are:
> > 
> > drivers/pci/host/pci-imx6.c
> > drivers/pci/host/pci-keystone.c
> > 
> > However, doing the conversion reveals that they are going to fail
> > at modpost time since hook_fault_code isn't currently exported.
> > 
> > Since we are now going to export it we also need to remove the
> > __init tag, as the fcn needs to be present at insmod time.
> > 
> > [1] https://lkml.kernel.org/r/20160108203102.GH5354 at localhost
> > 
> 
> If we want to make hook_fault_code() visible, we at least also need
> an unhook_fault_code() function that removes the fault handler
> when unloading the module, and preferably does so in a safe way.
> 
> The usage of hook_fault_code() at least in the imx driver is also
> problematic, as it just ignores all "imprecise external abort"
> faults, whether they come from PCI or not.

And that gets a NAK from me.  We can't take locks around this code
(to do so would be deadlocky due to imprecise aborts), so we can't
ever safely remove any function that has been hooked into the fault
processing.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From gregkh at linuxfoundation.org  Mon Feb  8 09:28:31 2016
From: gregkh at linuxfoundation.org (Greg KH)
Date: Mon, 8 Feb 2016 09:28:31 -0800
Subject: [PATCH v2 04/10] serial: mps2-uart: add MPS2 UART driver
In-Reply-To: <56B8CDC5.5010504@arm.com>
References: <1454413199-26573-1-git-send-email-vladimir.murzin@arm.com>
 <1454413199-26573-5-git-send-email-vladimir.murzin@arm.com>
 <20160207071154.GA32017@kroah.com> <56B87928.7020803@arm.com>
 <20160208165226.GA11593@kroah.com> <56B8CDC5.5010504@arm.com>
Message-ID: <20160208172831.GB6715@kroah.com>

On Mon, Feb 08, 2016 at 05:17:57PM +0000, Vladimir Murzin wrote:
> On 08/02/16 16:52, Greg KH wrote:
> > On Mon, Feb 08, 2016 at 11:16:56AM +0000, Vladimir Murzin wrote:
> >> On 07/02/16 07:11, Greg KH wrote:
> >>>> +
> >>>> +#define SERIAL_NAME "ttyS"
> >>>
> >>> You can't be "ttyS", there's already a serial port named that, please
> >>> use a unique name and a new major/minor number (dynamic ideally).
> >>>
> >>
> >> Hi Greg,
> >>
> >> I did s/ttyMPS/ttyS per your request for v1 [1]. I'm fine to change it
> >> back if you prefer that, but I'd be glad to know what I've been missing?
> >>
> >> [1] https://lkml.org/lkml/2015/12/13/8
> > 
> > Yeah, I was wrong, sorry about that, my fault.
> > 
> 
> I got -EDOUBT from my parser. What should I stick with "ttyS" or "ttyMPS"?

Please use ttyMPS.

> P.S.
> Any chance you could look at the rest of the patch?

It's long gone from my queue, sorry, you'll have to resend it.

thanks,

greg k-h


From mark.rutland at arm.com  Mon Feb  8 09:28:22 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 8 Feb 2016 17:28:22 +0000
Subject: [PATCH] arm64: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL
In-Reply-To: <56B8CBDA.4050107@linaro.org>
References: <1454716218-4918-1-git-send-email-yang.shi@linaro.org>
 <20160208114649.GB13498@leverpostej> <56B8CBDA.4050107@linaro.org>
Message-ID: <20160208172822.GC15443@leverpostej>

On Mon, Feb 08, 2016 at 09:09:46AM -0800, Shi, Yang wrote:
> On 2/8/2016 3:46 AM, Mark Rutland wrote:
> >Hi,
> >
> >On Fri, Feb 05, 2016 at 03:50:18PM -0800, Yang Shi wrote:
> >>To enable UBSAN on arm64, ARCH_HAS_UBSAN_SANITIZE_ALL need to be selected.
> >>
> >>Basic kernel bootup test is passed on arm64 with CONFIG_UBSAN_SANITIZE_ALL
> >>enabled.
> >>
> >>Signed-off-by: Yang Shi <yang.shi at linaro.org>
> >>---
> >>  arch/arm64/Kconfig | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >>diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> >>index 8cc6228..1c29e20 100644
> >>--- a/arch/arm64/Kconfig
> >>+++ b/arch/arm64/Kconfig
> >>@@ -14,6 +14,7 @@ config ARM64
> >>  	select ARCH_WANT_OPTIONAL_GPIOLIB
> >>  	select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
> >>  	select ARCH_WANT_FRAME_POINTERS
> >>+	select ARCH_HAS_UBSAN_SANITIZE_ALL
> >>  	select ARM_AMBA
> >>  	select ARM_ARCH_TIMER
> >>  	select ARM_GIC
> >
> >I gave this a go, and I got a couple of splats (included below) when
> >booting an Ubuntu 14.04 arm64 rootfs. I'm using Linato 15.08 GCC 5.1 to
> >compile an arm64 defconfig, and I see the issue with v4.5-rc2 and
> >v4.5-rc3.
> >
> >I will dig into that and file a report shortl, unless someone has
> >already reported the same issue.
> >
> >Did you see any failures in your testing? For reference, which kernel
> >version, compiler, and config were you using?
> 
> Yes, I did. I'm using 4.5-rc1 with gcc 5.2. And, I got one more
> splat and was digging into it.

Ok. Glad to hear it's not just me seeing it.

In future it would be best to point out issues you've spotted so that
reviewers don't confuse them for false positives.

Thanks,
Mark.


From brian.starkey at arm.com  Mon Feb  8 09:30:49 2016
From: brian.starkey at arm.com (Brian Starkey)
Date: Mon,  8 Feb 2016 17:30:49 +0000
Subject: [RESEND2 PATCH 0/3] Fix kernel panic in dma-coherent
Message-ID: <cover.1454950917.git.brian.starkey@arm.com>

Hi,

I'm resending these again to try and garner some interest. Without
this series, dma-coherent cannot be used on arm64 platforms. The
decision to add MEMREMAP_WC came out of a previous discussion with
Dan Williams and Catalin Marinas about the same problem[1].

These patches implement a MEMREMAP_WC flag for memremap(), which can
be used to obtain writecombine mappings. This is then used for setting
up dma_coherent_mem regions which use the DMA_MEMORY_MAP flag.
They apply cleanly on 4.5-rc3.

Patch 3 makes sure that the appropriate memset function is used
when zeroing coherent allocations, which fixes an alignment fault on
arm64.

Best Regards,
Brian

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390857.html

Brian Starkey (3):
  memremap: add MEMREMAP_WC flag
  drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP
  drivers: dma-coherent: use memset_io for DMA_MEMORY_IO

 drivers/base/dma-coherent.c |   25 ++++++++++++++++++++-----
 include/linux/io.h          |    1 +
 kernel/memremap.c           |   15 +++++++++++++--
 3 files changed, 34 insertions(+), 7 deletions(-)

-- 
1.7.9.5



From brian.starkey at arm.com  Mon Feb  8 09:30:50 2016
From: brian.starkey at arm.com (Brian Starkey)
Date: Mon,  8 Feb 2016 17:30:50 +0000
Subject: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag
In-Reply-To: <cover.1454950917.git.brian.starkey@arm.com>
References: <cover.1454950917.git.brian.starkey@arm.com>
Message-ID: <9085d37fa97a762a46b9d58719c085368682c64f.1454950917.git.brian.starkey@arm.com>

Add a flag to memremap() for writecombine mappings. Mappings satisfied
by this flag will not be cached, however writes may be delayed or
combined into more efficient bursts. This is most suitable for
buffers written sequentially by the CPU for use by other DMA devices.

Signed-off-by: Brian Starkey <brian.starkey at arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
---
 include/linux/io.h |    1 +
 kernel/memremap.c  |   15 +++++++++++++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/include/linux/io.h b/include/linux/io.h
index 32403b5..e2c8419 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -135,6 +135,7 @@ enum {
 	/* See memremap() kernel-doc for usage description... */
 	MEMREMAP_WB = 1 << 0,
 	MEMREMAP_WT = 1 << 1,
+	MEMREMAP_WC = 1 << 2,
 };
 
 void *memremap(resource_size_t offset, size_t size, unsigned long flags);
diff --git a/kernel/memremap.c b/kernel/memremap.c
index e517a16..3849987 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -41,11 +41,13 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
  * memremap() - remap an iomem_resource as cacheable memory
  * @offset: iomem resource start address
  * @size: size of remap
- * @flags: either MEMREMAP_WB or MEMREMAP_WT
+ * @flags: any of MEMREMAP_WB, MEMREMAP_WT and MEMREMAP_WC
  *
  * memremap() is "ioremap" for cases where it is known that the resource
  * being mapped does not have i/o side effects and the __iomem
- * annotation is not applicable.
+ * annotation is not applicable. In the case of multiple flags, the different
+ * mapping types will be attempted in the order listed below until one of
+ * them succeeds.
  *
  * MEMREMAP_WB - matches the default mapping for "System RAM" on
  * the architecture.  This is usually a read-allocate write-back cache.
@@ -57,6 +59,10 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
  * cache or are written through to memory and never exist in a
  * cache-dirty state with respect to program visibility.  Attempts to
  * map "System RAM" with this mapping type will fail.
+ *
+ * MEMREMAP_WC - establish a writecombine mapping, whereby writes may
+ * be coalesced together (e.g. in the CPU's write buffers), but is otherwise
+ * uncached. Attempts to map "System RAM" with this mapping type will fail.
  */
 void *memremap(resource_size_t offset, size_t size, unsigned long flags)
 {
@@ -101,6 +107,11 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
 		addr = ioremap_wt(offset, size);
 	}
 
+	if (!addr && (flags & MEMREMAP_WC)) {
+		flags &= ~MEMREMAP_WC;
+		addr = ioremap_wc(offset, size);
+	}
+
 	return addr;
 }
 EXPORT_SYMBOL(memremap);
-- 
1.7.9.5



From brian.starkey at arm.com  Mon Feb  8 09:30:52 2016
From: brian.starkey at arm.com (Brian Starkey)
Date: Mon,  8 Feb 2016 17:30:52 +0000
Subject: [RESEND2 PATCH 3/3] drivers: dma-coherent: use memset_io for
 DMA_MEMORY_IO mappings
In-Reply-To: <cover.1454950917.git.brian.starkey@arm.com>
References: <cover.1454950917.git.brian.starkey@arm.com>
Message-ID: <073de716b49028bbbd819fc403c2532a12992abe.1454950917.git.brian.starkey@arm.com>

Use memset_io() for DMA_MEMORY_IO mappings which are mapped as I/O
memory, and regular memset() for DMA_MEMORY_MAP mappings.

This fixes the below alignment fault on arm64 for DMA_MEMORY_IO
mappings, where memset() uses the DC ZVA instruction which is
invalid on device memory.

   Unhandled fault: alignment fault (0x96000061) at 0xffffff8000380000
   Internal error: : 96000061 [#1] PREEMPT SMP
   Modules linked in: hdlcd(+) clk_scpi
   CPU: 4 PID: 1355 Comm: systemd-udevd Not tainted 4.4.0-rc1+ #5
   Hardware name: ARM Juno development board (r0) (DT)
   task: ffffffc9763eee00 ti: ffffffc9758c4000 task.ti: ffffffc9758c4000
   PC is at __efistub_memset+0x1ac/0x200
   LR is at dma_alloc_from_coherent+0xb0/0x120
   pc : [<ffffffc00030ff2c>] lr : [<ffffffc00042a918>] pstate: 400001c5
   sp : ffffffc9758c79a0
   x29: ffffffc9758c79a0 x28: ffffffc000635cd0
   x27: 0000000000000124 x26: ffffffc000119ef4
   x25: 0000000000010000 x24: 0000000000000140
   x23: ffffffc07e9ac3a8 x22: ffffffc9758c7a58
   x21: ffffffc9758c7a68 x20: 0000000000000004
   x19: ffffffc07e9ac380 x18: 0000000000000001
   x17: 0000007fae1bbba8 x16: ffffffc0001b2d1c
   x15: ffffffffffffffff x14: 0ffffffffffffffe
   x13: 0000000000000010 x12: ffffff800837ffff
   x11: ffffff800837ffff x10: 0000000040000000
   x9 : 0000000000000000 x8 : ffffff8000380000
   x7 : 0000000000000000 x6 : 000000000000003f
   x5 : 0000000000000040 x4 : 0000000000000000
   x3 : 0000000000000004 x2 : 000000000000ffc0
   x1 : 0000000000000000 x0 : ffffff8000380000

Signed-off-by: Brian Starkey <brian.starkey at arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
---
 drivers/base/dma-coherent.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index f98359a..4e4ad30 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma-coherent.c
@@ -193,7 +193,10 @@ int dma_alloc_from_coherent(struct device *dev, ssize_t size,
 	 */
 	*dma_handle = mem->device_base + (pageno << PAGE_SHIFT);
 	*ret = mem->virt_base + (pageno << PAGE_SHIFT);
-	memset(*ret, 0, size);
+	if (mem->flags & DMA_MEMORY_MAP)
+		memset(*ret, 0, size);
+	else
+		memset_io(*ret, 0, size);
 	spin_unlock_irqrestore(&mem->spinlock, flags);
 
 	return 1;
-- 
1.7.9.5



From brian.starkey at arm.com  Mon Feb  8 09:30:51 2016
From: brian.starkey at arm.com (Brian Starkey)
Date: Mon,  8 Feb 2016 17:30:51 +0000
Subject: [RESEND2 PATCH 2/3] drivers: dma-coherent: use MEMREMAP_WC for
 DMA_MEMORY_MAP
In-Reply-To: <cover.1454950917.git.brian.starkey@arm.com>
References: <cover.1454950917.git.brian.starkey@arm.com>
Message-ID: <a85c534af867534e6693ce50a746fda096426586.1454950917.git.brian.starkey@arm.com>

When the DMA_MEMORY_MAP flag is used, memory which can be accessed
directly should be returned, so use memremap(..., MEMREMAP_WC) to
provide a writecombine mapping.

Signed-off-by: Brian Starkey <brian.starkey at arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
Acked-by: Michal Nazarewicz <mina86 at mina86.com>
---
 drivers/base/dma-coherent.c |   20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index 55b8398..f98359a 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma-coherent.c
@@ -2,6 +2,7 @@
  * Coherent per-device memory handling.
  * Borrowed from i386
  */
+#include <linux/io.h>
 #include <linux/slab.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
@@ -31,7 +32,10 @@ static int dma_init_coherent_memory(phys_addr_t phys_addr, dma_addr_t device_add
 	if (!size)
 		goto out;
 
-	mem_base = ioremap(phys_addr, size);
+	if (flags & DMA_MEMORY_MAP)
+		mem_base = memremap(phys_addr, size, MEMREMAP_WC);
+	else
+		mem_base = ioremap(phys_addr, size);
 	if (!mem_base)
 		goto out;
 
@@ -58,8 +62,12 @@ static int dma_init_coherent_memory(phys_addr_t phys_addr, dma_addr_t device_add
 
 out:
 	kfree(dma_mem);
-	if (mem_base)
-		iounmap(mem_base);
+	if (mem_base) {
+		if (flags & DMA_MEMORY_MAP)
+			memunmap(mem_base);
+		else
+			iounmap(mem_base);
+	}
 	return 0;
 }
 
@@ -67,7 +75,11 @@ static void dma_release_coherent_memory(struct dma_coherent_mem *mem)
 {
 	if (!mem)
 		return;
-	iounmap(mem->virt_base);
+
+	if (mem->flags & DMA_MEMORY_MAP)
+		memunmap(mem->virt_base);
+	else
+		iounmap(mem->virt_base);
 	kfree(mem->bitmap);
 	kfree(mem);
 }
-- 
1.7.9.5



From linux at arm.linux.org.uk  Mon Feb  8 09:34:04 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 8 Feb 2016 17:34:04 +0000
Subject: [PATCH 1/5] ARM: add EXPORT_SYMBOL of hook_fault_code for PCI
 host modularization
In-Reply-To: <1454889644-27830-2-git-send-email-paul.gortmaker@windriver.com>
References: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
 <1454889644-27830-2-git-send-email-paul.gortmaker@windriver.com>
Message-ID: <20160208173403.GS10826@n2100.arm.linux.org.uk>

On Sun, Feb 07, 2016 at 07:00:40PM -0500, Paul Gortmaker wrote:
> In a discussion of a previous patch set[1], it was suggested that
> modularizing some of the PCI host support would be good to keep
> multi platform bzImage sizes smaller.
> 
> Two of the files that are candidates for conversion to tristate
> from bool are:
> 
> drivers/pci/host/pci-imx6.c
> drivers/pci/host/pci-keystone.c
> 
> However, doing the conversion reveals that they are going to fail
> at modpost time since hook_fault_code isn't currently exported.
> 
> Since we are now going to export it we also need to remove the
> __init tag, as the fcn needs to be present at insmod time.
> 
> [1] https://lkml.kernel.org/r/20160108203102.GH5354 at localhost
> 
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Bjorn Helgaas <bhelgaas at google.com>
> Cc: Geert Uytterhoeven <geert at linux-m68k.org>
> Cc: Thierry Reding <thierry.reding at gmail.com>
> Cc: Ley Foon Tan <lftan at altera.com>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> ---
>  arch/arm/mm/fault.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> index daafcf121ce0..e0696a5ecc9b 100644
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@ -525,7 +525,7 @@ struct fsr_info {
>  #include "fsr-2level.c"
>  #endif
>  
> -void __init
> +void
>  hook_fault_code(int nr, int (*fn)(unsigned long, unsigned int, struct pt_regs *),
>  		int sig, int code, const char *name)
>  {
> @@ -537,6 +537,7 @@ hook_fault_code(int nr, int (*fn)(unsigned long, unsigned int, struct pt_regs *)
>  	fsr_info[nr].code = code;
>  	fsr_info[nr].name = name;
>  }
> +EXPORT_SYMBOL(hook_fault_code);

I'm really not a fan of this change - the hooks are supposed to remain
mostly static once the system is up and running, and should not change
at runtime (since there is no locking on these - see my previous reply.)
There's no protection (or support) for more than one function - iow, if
we have two modules trying to hook into the same fault code, the last
taker gets it (although the previous owner may get called given the
right timing.)

While it may be limited to two drivers at the moment, I'd like it to
remain that way.

If we really must have this, then please use EXPORT_SYMBOL_GPL() - I
don't want this interface to be used by code which isn't GPL compliant.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From linus.walleij at linaro.org  Mon Feb  8 09:34:29 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 8 Feb 2016 18:34:29 +0100
Subject: [PATCH V4] drivers/gpio: Switch gpio-mpc8xxx to use gpio-generic
In-Reply-To: <1454498854-33169-1-git-send-email-Gang.Liu@nxp.com>
References: <1454498854-33169-1-git-send-email-Gang.Liu@nxp.com>
Message-ID: <CACRpkdYSwSW+kd+QyvfabNoPyAXx9VDWJaYD79p3krpgmX8iOg@mail.gmail.com>

On Wed, Feb 3, 2016 at 12:27 PM, Liu Gang <Gang.Liu at nxp.com> wrote:

> The new Layerscape platforms has the same ip block/controller
> as GPIO on PowerPC platforms(MPC8XXX), but the GPIO registers
> may be big or little endian. So the code needs to get the
> endian property from DTB, then make additional functions to
> fit all the PowerPC/Layerscape GPIO register read/write
> operations.
>
> gpio-generic.c provides an universal infrastructure for both
> big and little endian register operations. So switch the
> gpio-mpc8xxx to use gpio-generic can simplify the driver and
> reduce a lot of code.
>
> The IRQ and some workaround parts in gpio-mpc8xxx.c will be
> updated with the new API interfaces but following the
> original functionalities.
>
> Signed-off-by: Liu Gang <Gang.Liu at nxp.com>
> ---
> -V4: Rebase the kernel to v4.5-rc1 for the new gpio-generic
>      infrastructure based on Linus Walleij comments.

Patch applied, I guess this also silences the compile errors I've
been getting about the be32 accessors.

Yours,
Linus Walleij


From hdegoede at redhat.com  Mon Feb  8 09:34:59 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Mon, 8 Feb 2016 18:34:59 +0100
Subject: [linux-sunxi][PATCH] ARM: dts: sun7i: Enable USB DRC on Itead Ibox
In-Reply-To: <CAEKpxBkXp9hx6KWpWyRBvYBFi7Sr0FgFHrD6M0nSBuJ1bV++1A@mail.gmail.com>
References: <1454947167-12236-1-git-send-email-codekipper@gmail.com>
 <56B8BED7.9030704@redhat.com>
 <CAEKpxBkXp9hx6KWpWyRBvYBFi7Sr0FgFHrD6M0nSBuJ1bV++1A@mail.gmail.com>
Message-ID: <56B8D1C3.809@redhat.com>

Hi,

On 08-02-16 17:56, Code Kipper wrote:
> On 8 February 2016 at 17:14, Hans de Goede <hdegoede at redhat.com> wrote:
>> Hi,
>>
>> On 08-02-16 16:59, codekipper at gmail.com wrote:
>>>
>>> From: Marcus Cooper <codekipper at gmail.com>
>>>
>>> Enable the otg/drc usb controller on the Itead Ibox device.
>>>
>>> Signed-off-by: Marcus Cooper <codekipper at gmail.com>
>>
>>
>> Same remark as with your Olimex A20 EVB board patch, please
>> also provide a vbus detect pin setting. If for some reason the
>> VBus detect is not wired up, or not working properly, please mention
>> this explicitly in the commit message.
> Hi Hans,
> I've added vbus detect and it no longer works. It's mentioned that the
> Itead Ibox is similar to the Cubieboard 2 which also doesn't include
> the detect. I can see now in the commit that it states "Note this
> board has the otg-vbus connected directly to the 5v-dcc of the board,
> so there is no vbus0 regulator, nor vbus0-det.", I will add this to
> the commit message and try and dig out a schematic to confirm.

Ok, thanks for looking into this.

Regards,

Hans


From yang.shi at linaro.org  Mon Feb  8 09:13:09 2016
From: yang.shi at linaro.org (Yang Shi)
Date: Mon,  8 Feb 2016 09:13:09 -0800
Subject: [PATCH v2] arm64: disable kasan when accessing frame->fp in
 unwind_frame
Message-ID: <1454951589-18238-1-git-send-email-yang.shi@linaro.org>

When boot arm64 kernel with KASAN enabled, the below error is reported by
kasan:

BUG: KASAN: out-of-bounds in unwind_frame+0xec/0x260 at addr ffffffc064d57ba0
Read of size 8 by task pidof/499
page:ffffffbdc39355c0 count:0 mapcount:0 mapping:          (null) index:0x0
flags: 0x0()
page dumped because: kasan: bad access detected
CPU: 2 PID: 499 Comm: pidof Not tainted 4.5.0-rc1 #119
Hardware name: Freescale Layerscape 2085a RDB Board (DT)
Call trace:
[<ffffffc00008d078>] dump_backtrace+0x0/0x290
[<ffffffc00008d32c>] show_stack+0x24/0x30
[<ffffffc0006a981c>] dump_stack+0x8c/0xd8
[<ffffffc0002e4400>] kasan_report_error+0x558/0x588
[<ffffffc0002e4958>] kasan_report+0x60/0x70
[<ffffffc0002e3188>] __asan_load8+0x60/0x78
[<ffffffc00008c92c>] unwind_frame+0xec/0x260
[<ffffffc000087e60>] get_wchan+0x110/0x160
[<ffffffc0003b647c>] do_task_stat+0xb44/0xb68
[<ffffffc0003b7730>] proc_tgid_stat+0x40/0x50
[<ffffffc0003ac840>] proc_single_show+0x88/0xd8
[<ffffffc000345be8>] seq_read+0x370/0x770
[<ffffffc00030aba0>] __vfs_read+0xc8/0x1d8
[<ffffffc00030c0ec>] vfs_read+0x94/0x168
[<ffffffc00030d458>] SyS_read+0xb8/0x128
[<ffffffc000086530>] el0_svc_naked+0x24/0x28
Memory state around the buggy address:
 ffffffc064d57a80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4
 ffffffc064d57b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffffc064d57b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                                  ^
 ffffffc064d57c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffffc064d57c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Since the shadow byte pointed by the report is 0, so it may mean it is just hit
oob in non-current task. So, disable the instrumentation to silence these
warnings.

Signed-off-by: Yang Shi <yang.shi at linaro.org>
---
v1 --> v2:
 * Replace kasan_disable{enable}_current to READ_ONCE_NOCHECK.
 * Cover the following statement too.

 arch/arm64/kernel/stacktrace.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 4fad978..12a18cb 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -64,8 +64,8 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
 		return -EINVAL;
 
 	frame->sp = fp + 0x10;
-	frame->fp = *(unsigned long *)(fp);
-	frame->pc = *(unsigned long *)(fp + 8);
+	frame->fp = READ_ONCE_NOCHECK(*(unsigned long *)(fp));
+	frame->pc = READ_ONCE_NOCHECK(*(unsigned long *)(fp + 8));
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 	if (tsk && tsk->ret_stack &&
-- 
2.0.2



From Al.Grant at arm.com  Mon Feb  8 09:44:49 2016
From: Al.Grant at arm.com (Al Grant)
Date: Mon, 8 Feb 2016 17:44:49 +0000
Subject: [PATCH V2 3/6] stm class: provision for statically assigned
 masterIDs
In-Reply-To: <CANLsYkw=mG+ch8QzxmbwWs9o+mndVNo1MuqXcrPrNJYj_SQcHQ@mail.gmail.com>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
 <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org>
 <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com>
 <CANLsYky2twQ98u241YyHD=atYRp1N56YVHUQNY2E2Ljsq0cseA@mail.gmail.com>
 <87twlj49k7.fsf@ashishki-desk.ger.corp.intel.com>
 <CANLsYkw=mG+ch8QzxmbwWs9o+mndVNo1MuqXcrPrNJYj_SQcHQ@mail.gmail.com>
Message-ID: <AM4PR08MB0785EAA2B628765D7EA3FDA086D50@AM4PR08MB0785.eurprd08.prod.outlook.com>

> Mike did write "master IDs are hardwired to individual cores and core security
> states", which make assignment for one platform very static.
> On the flip side those will change from one system to another.

It depends on your perspective.  From the perspective of a userspace
process not pinned to a core, the master id will appear to vary
dynamically and unpredictably as the thread migrates from one
core to another.  (That's actually useful if the decoder wants to know
where the thread is running at any given point, as it can find that out
for free, without the need to track migration events.)

On the other hand if you are pinned (e.g. you're the kernel on a
particular core, or you're a per-core worker thread in some thread
pooling system) then you have a fixed master id, and then you can
have one instance per core all using the same range of channel
numbers, with the master id indicating the core - this saves on
channel space compared to having to give each core its own
range of channel space.

Al
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

From mcoquelin.stm32 at gmail.com  Mon Feb  8 09:50:25 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Mon, 8 Feb 2016 18:50:25 +0100
Subject: [PATCH v5 0/9] Add STM32 pinctrl/GPIO driver
In-Reply-To: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
References: <1454497485-464-1-git-send-email-mcoquelin.stm32@gmail.com>
Message-ID: <CALszF6D_2zcg0SsV8HQ8kiSMypau1SV28L08fuz+Pziqyu8QKg@mail.gmail.com>

2016-02-03 12:04 GMT+01:00 Maxime Coquelin <mcoquelin.stm32 at gmail.com>:
> Hi Linus,
>
> This is the fifth round of STM32 pinctrl series, which is rebased on top of
> v4.5-rc1 and removes no more needed dependency between DT and driver.
>
> Also, it fixes the Makefile so that it is really built when COMPILE_TEST is
> set and not ARCH_STM32.
>
> The STM32 family has 16 pins per GPIO bank, and the number of bank varies
> depending on the model.
>
> Pins can be multiplexed either in GPIO mode, alternate function (up to 15
> functions per pin) or analog (for ADC/DAC).
>
> Changes since v4:
> -----------------
>  - Rebase on v4.5-rc1
>  - Fix compilation breakage due to gpio_chip struct .dev field renaming
>  - Move the macros from includes/dt-bindings to STM32 pinctrl driver directory
> to avoid uneeded dependency between DT and driver.
>  - Fix Makefile so that driver is built with COMPILE_TEST set

Please discard this series, the changes above are being handled on top of v4.

Regards,
Maxime


From robh at kernel.org  Mon Feb  8 09:50:38 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 11:50:38 -0600
Subject: [PATCH v2 4/4] Documentation: atmel-pmc: add DT bindings for
 fast startup
In-Reply-To: <1454571471-4434-5-git-send-email-wenyou.yang@atmel.com>
References: <1454571471-4434-1-git-send-email-wenyou.yang@atmel.com>
 <1454571471-4434-5-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20160208175038.GA10074@rob-hp-laptop>

On Thu, Feb 04, 2016 at 03:37:51PM +0800, Wenyou Yang wrote:
> Add DT bindings to configurate the PMC_FSMR and PMC_FSPR registers
> to trigger a fast restart signal to PMC.
> 
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> ---
> 
> Changes in v2:
>  - change the property name and property description.
> 
>  .../devicetree/bindings/arm/atmel-pmc.txt          |   63 ++++++++++++++++++++
>  1 file changed, 63 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/atmel-pmc.txt b/Documentation/devicetree/bindings/arm/atmel-pmc.txt
> index 795cc78..1b3833b 100644
> --- a/Documentation/devicetree/bindings/arm/atmel-pmc.txt
> +++ b/Documentation/devicetree/bindings/arm/atmel-pmc.txt
> @@ -12,3 +12,66 @@ Examples:
>  		compatible = "atmel,at91rm9200-pmc";
>  		reg = <0xfffffc00 0x100>;
>  	};
> +
> +PMC Fast Startup Signals
> +
> +The PMC Fast Start Signals are used as the wake up source to trigger the PMC
> +to wake up the system from the ULP1 mode.
> +
> +required properties:
> +- compatible: Should be "atmel,sama5d2-pmc-fast-startup".
> +
> +optional properties:
> +- atmel,wkup-trigger: boolean, WKUP input can trigger a fast restart signal.
> +- atmel,secumod-trigger: boolean, SECUMOD can trigger a fast restart signal.
> +- atmel,piobu0-trigger: boolean, PIOBU0 input can trigger a fast restart signal.
> +- atmel,piobu1-trigger: boolean, PIOBU1 input can trigger a fast restart signal.
> +- atmel,piobu2-trigger: boolean, PIOBU2 input can trigger a fast restart signal.
> +- atmel,piobu3-trigger: boolean, PIOBU3 input can trigger a fast restart signal.
> +- atmel,piobu4-trigger: boolean, PIOBU4 input can trigger a fast restart signal.
> +- atmel,piobu5-trigger: boolean, PIOBU5 input can trigger a fast restart signal.
> +- atmel,piobu6-trigger: boolean, PIOBU6 input can trigger a fast restart signal.
> +- atmel,piobu7-trigger: boolean, PIOBU7 input can trigger a fast restart signal.
> +- atmel,gmac-wol-trigger: boolean, GMAC_WOL can trigger a fast restart signal.
> +- atmel,rtc-alarm-trigger: boolean, RTC alarm can trigger a fast restart signal.
> +- atmel,usb-resume-trigger: boolean, USB resume can trigger a fast restart
> +  signal.
> +- atmel,sdmmc-cd-trigger: boolean, SDMMC card detect can trigger a fast
> +  restart signal.
> +- atmel,rxlp-match-trigger: boolean, Matching condition on RXLP can trigger
> +  a fast restart signal.
> +- atmel,acc-comparison-trigger: boolean, ACC comparison can trigger a fast
> +  restart signal.
> +
> +- atmel,wkup-trigger-level: string, defines the active polarity of the wake-up
> +  input. Supported values are: "high" or "low".

Use 0 and 1, not strings.


From mark.rutland at arm.com  Mon Feb  8 09:50:55 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 8 Feb 2016 17:50:55 +0000
Subject: [RESEND2 PATCH 0/3] Fix kernel panic in dma-coherent
In-Reply-To: <cover.1454950917.git.brian.starkey@arm.com>
References: <cover.1454950917.git.brian.starkey@arm.com>
Message-ID: <20160208175054.GD15443@leverpostej>

On Mon, Feb 08, 2016 at 05:30:49PM +0000, Brian Starkey wrote:
> Hi,
> 
> I'm resending these again to try and garner some interest. Without
> this series, dma-coherent cannot be used on arm64 platforms.

I think you need to characterize that a bit better. I see plenty of
instances of 'dma-coherent' in dts files, assuming you mean the DT
dma-coehrent property.

If not, feel free to stop reading now.

Currently dma-coherent isn't well-defined, but it's de-facto semantics
are that a device makes accesses which are coherent with data accesses
made by CPUs with Normal, Inner Shareable, Inner Write-Back Cacheable,
Outer Write-Back Cacheable attributes.

> The decision to add MEMREMAP_WC came out of a previous discussion with
> Dan Williams and Catalin Marinas about the same problem[1].

As pgprot_writecombine is Normal Non-Cacheable, this is a completely
different idea of coherency to that described by the DT dma-coherent
property.

We should not overload that to mean different things.

Thanks,
Mark.

> These patches implement a MEMREMAP_WC flag for memremap(), which can
> be used to obtain writecombine mappings. This is then used for setting
> up dma_coherent_mem regions which use the DMA_MEMORY_MAP flag.
> They apply cleanly on 4.5-rc3.
> 
> Patch 3 makes sure that the appropriate memset function is used
> when zeroing coherent allocations, which fixes an alignment fault on
> arm64.
> 
> Best Regards,
> Brian
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390857.html
> 
> Brian Starkey (3):
>   memremap: add MEMREMAP_WC flag
>   drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP
>   drivers: dma-coherent: use memset_io for DMA_MEMORY_IO
> 
>  drivers/base/dma-coherent.c |   25 ++++++++++++++++++++-----
>  include/linux/io.h          |    1 +
>  kernel/memremap.c           |   15 +++++++++++++--
>  3 files changed, 34 insertions(+), 7 deletions(-)
> 
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From matthias.bgg at gmail.com  Mon Feb  8 09:51:31 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 8 Feb 2016 18:51:31 +0100
Subject: [RFC 1/3] dt-bindings: soc: Add documentation for the MediaTek
 GCE unit
In-Reply-To: <1453433893.15298.13.camel@mtksdaap41>
References: <1453266881-16849-1-git-send-email-hs.liao@mediatek.com>
 <1453266881-16849-2-git-send-email-hs.liao@mediatek.com>
 <20160120163826.GA23400@rob-hp-laptop> <1453433893.15298.13.camel@mtksdaap41>
Message-ID: <56B8D5A3.3000506@gmail.com>



On 22/01/16 04:38, Horng-Shyang Liao wrote:
> Hi Rob,
>
> On Wed, 2016-01-20 at 10:38 -0600, Rob Herring wrote:
>> On Wed, Jan 20, 2016 at 01:14:38PM +0800, hs.liao at mediatek.com wrote:
>>> From: HS Liao <hs.liao at mediatek.com>
>>>
>>> This adds documentation for the MediaTek Global Command Engine (GCE) unit
>>> found in MT8173 SoCs.
>>>
>>> Signed-off-by: HS Liao <hs.liao at mediatek.com>
>>> ---
>>>   .../devicetree/bindings/soc/mediatek/gce.txt       |   33 ++++++++++++++++++++
>>>   1 file changed, 33 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/soc/mediatek/gce.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/soc/mediatek/gce.txt b/Documentation/devicetree/bindings/soc/mediatek/gce.txt
>>> new file mode 100644
>>> index 0000000..878b11e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/soc/mediatek/gce.txt
>>> @@ -0,0 +1,33 @@
>>> +MediaTek GCE
>>> +===============
>>> +
>>> +The Global Command Engine (GCE) is used to help read/write registers with
>>> +critical time limitation, such as updating display configuration during the
>>> +vblank. The GCE can be used to implement the Command Queue (CMDQ) driver.
>>> +Currently, the GCE only supports display related hardwares, but we expect
>>> +it can be extended to other hardwares for future requirements.
>>
>> That's a hardware limitation or just s/w is only using it for display?
>> If the latter, that's not really relevant to this binding and should be
>> removed.
>
> Just s/w is only using it for display.
> I will remove it from next patch.
>
>>> +
>>> +Required properties:
>>> +- compatible: Must be "mediatek,mt8173-gce"
>>> +- reg: Address range of the GCE unit
>>> +- interrupts: The interrupt signal from the GCE block
>>> +- clock: Clocks according to the common clock binding
>>> +- clock-names: Must be "gce" to stand for GCE clock
>>> +
>>> +Example:
>>> +
>>> +	gce: gce at 10212000 {
>>> +		compatible = "mediatek,mt8173-gce";
>>> +		reg = <0 0x10212000 0 0x1000>;
>>> +		interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_LOW>;
>>> +		clocks = <&infracfg CLK_INFRA_GCE>;
>>> +		clock-names = "gce";
>>> +	};
>>> +
>>> +	mmsys: clock-controller at 14000000 {
>>> +		compatible = "mediatek,mt8173-mmsys", "syscon";
>>> +		reg = <0 0x14000000 0 0x1000>;
>>> +		power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
>>> +		#clock-cells = <1>;
>>> +		mediatek,gce = <&gce>;
>>
>> Not documented.
>
> It's just an example about how gce is used by display mmsys.
> After I discussed with Mediatek display owner,
> we think this can be moved to display device tree document.
> Do you agree with this suggestion?
> If so, I will remove it from next patch, too.
>

The problem is that mediatek,gce is not documented, but only 
mediatek,mt8173-gce.

Regards,
Matthias


From javier at osg.samsung.com  Mon Feb  8 09:53:02 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Mon,  8 Feb 2016 14:53:02 -0300
Subject: [PATCH 2/3] ARM: omap2plus_defconfig: Enable ISP support and
 dependencies
In-Reply-To: <1454953983-8894-1-git-send-email-javier@osg.samsung.com>
References: <1454953983-8894-1-git-send-email-javier@osg.samsung.com>
Message-ID: <1454953983-8894-3-git-send-email-javier@osg.samsung.com>

The OMAP3 SoC has a Image Signal Processor (ISP) that's used to accelerate
camera images processing. The ISP driver implements V4L2, Media Controller
and V4L2 sub-dev interfaces so enable support for the driver and all these
dependencies to allow video capture to be tested using this HW IP block.

Also, disable the I2C ancillary drivers auto-select option since the media
driver does not auto-select the ancillary devices that are attached to the
bridge because this depends on what's present in the supported OMAP boards.

Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
---

 arch/arm/configs/omap2plus_defconfig | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index c53d21c30b20..792a56d5f45c 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -288,6 +288,13 @@ CONFIG_REGULATOR_TPS65217=y
 CONFIG_REGULATOR_TPS65218=y
 CONFIG_REGULATOR_TPS65910=y
 CONFIG_REGULATOR_TWL4030=y
+CONFIG_MEDIA_SUPPORT=m
+CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_MEDIA_CONTROLLER=y
+CONFIG_VIDEO_V4L2_SUBDEV_API=y
+CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_VIDEO_OMAP3=m
+# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
 CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_MODE_HELPERS=y
-- 
2.5.0



From javier at osg.samsung.com  Mon Feb  8 09:53:00 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Mon,  8 Feb 2016 14:53:00 -0300
Subject: [PATCH 0/3] ARM: omap2plus_defconfig: Enable OMAP3 ISP and
 dependencies
Message-ID: <1454953983-8894-1-git-send-email-javier@osg.samsung.com>

Hello,

This small series enables all the Kconfig symbols needed to test the
OMAP3 ISP on the IGEPv2 board. I've enabled as much as possible as a
module and only as built-in the options that are boolean.

Best regards,
Javier


Javier Martinez Canillas (3):
  ARM: omap2plus_defconfig: Enable OMAP IOMMU support
  ARM: omap2plus_defconfig: Enable ISP support and dependencies
  ARM: omap2plus_defconfig: Enable TI TVP5150 video decoder support

 arch/arm/configs/omap2plus_defconfig | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

-- 
2.5.0



From javier at osg.samsung.com  Mon Feb  8 09:53:01 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Mon,  8 Feb 2016 14:53:01 -0300
Subject: [PATCH 1/3] ARM: omap2plus_defconfig: Enable OMAP IOMMU support
In-Reply-To: <1454953983-8894-1-git-send-email-javier@osg.samsung.com>
References: <1454953983-8894-1-git-send-email-javier@osg.samsung.com>
Message-ID: <1454953983-8894-2-git-send-email-javier@osg.samsung.com>

OMAP3 media platform drivers (i.e: omap3isp) needs IOMMU support so
enable it to be able to test the OMAP3 Image Signal Processor (ISP).

Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
---

 arch/arm/configs/omap2plus_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index a7151744b85c..c53d21c30b20 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -412,7 +412,8 @@ CONFIG_RTC_DRV_OMAP=m
 CONFIG_DMADEVICES=y
 CONFIG_TI_EDMA=y
 CONFIG_DMA_OMAP=y
-# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_IOMMU_SUPPORT=y
+CONFIG_OMAP_IOMMU=y
 CONFIG_EXTCON=m
 CONFIG_EXTCON_USB_GPIO=m
 CONFIG_EXTCON_PALMAS=m
-- 
2.5.0



From javier at osg.samsung.com  Mon Feb  8 09:53:03 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Mon,  8 Feb 2016 14:53:03 -0300
Subject: [PATCH 3/3] ARM: omap2plus_defconfig: Enable TI TVP5150 video decoder
 support
In-Reply-To: <1454953983-8894-1-git-send-email-javier@osg.samsung.com>
References: <1454953983-8894-1-git-send-email-javier@osg.samsung.com>
Message-ID: <1454953983-8894-4-git-send-email-javier@osg.samsung.com>

Many OMAP3 boards have a TVP5150/1 video decoder attached to the OMAP3
ISP so enable support for its driver as a module to be able to test it.

Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>

---

 arch/arm/configs/omap2plus_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 792a56d5f45c..9fc172373aa3 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -295,6 +295,7 @@ CONFIG_VIDEO_V4L2_SUBDEV_API=y
 CONFIG_V4L_PLATFORM_DRIVERS=y
 CONFIG_VIDEO_OMAP3=m
 # CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
+CONFIG_VIDEO_TVP5150=m
 CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_MODE_HELPERS=y
-- 
2.5.0



From mcoquelin.stm32 at gmail.com  Mon Feb  8 09:57:39 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Mon,  8 Feb 2016 18:57:39 +0100
Subject: [PATCH 2/2] pinctrl: stm32: Fix compile testing selection
In-Reply-To: <1454954259-4923-1-git-send-email-mcoquelin.stm32@gmail.com>
References: <1454954259-4923-1-git-send-email-mcoquelin.stm32@gmail.com>
Message-ID: <1454954259-4923-3-git-send-email-mcoquelin.stm32@gmail.com>

While selecting the driver for compile testing seemed possible,
the driver was not compiled because the driver directory was only
added if ARCH_STM32 was selected.

This patch now makes the pinctrl Makefile to add stm32 directory if
PINCTRL_STM32 is selected.

Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
---
 drivers/pinctrl/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 8adc235..7ea62ef 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -46,7 +46,7 @@ obj-$(CONFIG_ARCH_QCOM)		+= qcom/
 obj-$(CONFIG_PINCTRL_SAMSUNG)	+= samsung/
 obj-$(CONFIG_PINCTRL_SH_PFC)	+= sh-pfc/
 obj-$(CONFIG_PINCTRL_SPEAR)	+= spear/
-obj-$(CONFIG_ARCH_STM32)	+= stm32/
+obj-$(CONFIG_PINCTRL_STM32)	+= stm32/
 obj-$(CONFIG_PINCTRL_SUNXI)	+= sunxi/
 obj-$(CONFIG_PINCTRL_UNIPHIER)	+= uniphier/
 obj-$(CONFIG_ARCH_VT8500)	+= vt8500/
-- 
1.9.1



From mcoquelin.stm32 at gmail.com  Mon Feb  8 09:57:37 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Mon,  8 Feb 2016 18:57:37 +0100
Subject: [PATCH 0/2] pinctrl: stm32;
 Fix build issue in -next and make compile-testing possible
Message-ID: <1454954259-4923-1-git-send-email-mcoquelin.stm32@gmail.com>

This two-patches series fixes two problems on stm32 pinctrl driver:
	1 - As reported by Arnd, there is a missing dependency with DT Bindings
headers on Linus' pinctrl/devel branch. This dependency is in fact not needed,
so the first patch removes it.
	2 - The driver could be selected for compile testing via menuconfig, but
the Makefile only selected stm32 driver directory if ARCH_STM32 was selected.
The second patch selects the stm32 driver if PINCTRL_STM32 is selected.

Regards,
Maxime

Maxime Coquelin (2):
  pinctrl: stm32: Remove dependency with DT bindings header files
  pinctrl: stm32: Fix compile testing selection

 drivers/pinctrl/Makefile              | 2 +-
 drivers/pinctrl/stm32/pinctrl-stm32.c | 2 --
 drivers/pinctrl/stm32/pinctrl-stm32.h | 8 ++++++++
 3 files changed, 9 insertions(+), 3 deletions(-)

-- 
1.9.1



From mcoquelin.stm32 at gmail.com  Mon Feb  8 09:57:38 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Mon,  8 Feb 2016 18:57:38 +0100
Subject: [PATCH 1/2] pinctrl: stm32: Remove dependency with DT bindings header
 files
In-Reply-To: <1454954259-4923-1-git-send-email-mcoquelin.stm32@gmail.com>
References: <1454954259-4923-1-git-send-email-mcoquelin.stm32@gmail.com>
Message-ID: <1454954259-4923-2-git-send-email-mcoquelin.stm32@gmail.com>

Some macros where defined in DT bindings headers, whereas only used
in the driver.

This patch moves these macros to the driver side.

Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
---
 drivers/pinctrl/stm32/pinctrl-stm32.c | 2 --
 drivers/pinctrl/stm32/pinctrl-stm32.h | 8 ++++++++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c
index 9a08222..8deb566 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -23,8 +23,6 @@
 #include <linux/reset.h>
 #include <linux/slab.h>
 
-#include <dt-bindings/pinctrl/pinctrl-stm32.h>
-
 #include "../core.h"
 #include "../pinconf.h"
 #include "../pinctrl-utils.h"
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.h b/drivers/pinctrl/stm32/pinctrl-stm32.h
index 1b7c369..35ebc94 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.h
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.h
@@ -9,6 +9,14 @@
 #include <linux/pinctrl/pinctrl.h>
 #include <linux/pinctrl/pinconf-generic.h>
 
+#define STM32_PIN_NO(x) ((x) << 8)
+#define STM32_GET_PIN_NO(x) ((x) >> 8)
+#define STM32_GET_PIN_FUNC(x) ((x) & 0xff)
+
+#define STM32_PIN_GPIO		0
+#define STM32_PIN_AF(x)		((x) + 1)
+#define STM32_PIN_ANALOG	(STM32_PIN_AF(15) + 1)
+
 struct stm32_desc_function {
 	const char *name;
 	const unsigned char num;
-- 
1.9.1



From robin.murphy at arm.com  Mon Feb  8 09:59:25 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Mon, 8 Feb 2016 17:59:25 +0000
Subject: [RESEND2 PATCH 0/3] Fix kernel panic in dma-coherent
In-Reply-To: <20160208175054.GD15443@leverpostej>
References: <cover.1454950917.git.brian.starkey@arm.com>
 <20160208175054.GD15443@leverpostej>
Message-ID: <56B8D77D.3050305@arm.com>

Hi Mark,

On 08/02/16 17:50, Mark Rutland wrote:
> On Mon, Feb 08, 2016 at 05:30:49PM +0000, Brian Starkey wrote:
>> Hi,
>>
>> I'm resending these again to try and garner some interest. Without
>> this series, dma-coherent cannot be used on arm64 platforms.
>
> I think you need to characterize that a bit better. I see plenty of
> instances of 'dma-coherent' in dts files, assuming you mean the DT
> dma-coehrent property.
>
> If not, feel free to stop reading now.

Terminology overload: the dma-coherent DT property is about devices 
having cache-coherent access to system memory within the linear map. The 
dma-coherent thing here is pretty much the precise opposite of that - 
namely creating CPU mappings for memory which belongs to the device 
itself and may be behind an I/O bus (e.g. a framebuffer on a video card).

> Currently dma-coherent isn't well-defined,

True dat.

Robin.

> but it's de-facto semantics
> are that a device makes accesses which are coherent with data accesses
> made by CPUs with Normal, Inner Shareable, Inner Write-Back Cacheable,
> Outer Write-Back Cacheable attributes.
>
>> The decision to add MEMREMAP_WC came out of a previous discussion with
>> Dan Williams and Catalin Marinas about the same problem[1].
>
> As pgprot_writecombine is Normal Non-Cacheable, this is a completely
> different idea of coherency to that described by the DT dma-coherent
> property.
>
> We should not overload that to mean different things.
>
> Thanks,
> Mark.
>
>> These patches implement a MEMREMAP_WC flag for memremap(), which can
>> be used to obtain writecombine mappings. This is then used for setting
>> up dma_coherent_mem regions which use the DMA_MEMORY_MAP flag.
>> They apply cleanly on 4.5-rc3.
>>
>> Patch 3 makes sure that the appropriate memset function is used
>> when zeroing coherent allocations, which fixes an alignment fault on
>> arm64.
>>
>> Best Regards,
>> Brian
>>
>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390857.html
>>
>> Brian Starkey (3):
>>    memremap: add MEMREMAP_WC flag
>>    drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP
>>    drivers: dma-coherent: use memset_io for DMA_MEMORY_IO
>>
>>   drivers/base/dma-coherent.c |   25 ++++++++++++++++++++-----
>>   include/linux/io.h          |    1 +
>>   kernel/memremap.c           |   15 +++++++++++++--
>>   3 files changed, 34 insertions(+), 7 deletions(-)
>>
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



From Suravee.Suthikulpanit at amd.com  Mon Feb  8 09:59:05 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Mon, 8 Feb 2016 11:59:05 -0600
Subject: [PATCH V2 00/12] dtb: amd: Miscelleneous Updates for AMD Seattle DTS
Message-ID: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

This patch series contains several updates for the AMD Seattle SOC DTS files.
It also adds new board files for newer Overdrive and Linaro 96boards (Husky)
platforms.

Thanks,
Suravee

Changes from V1 (https://lkml.org/lkml/2016/1/27/1251):
  * Fix duplication in MAINTAINERS file (per Martin review comment)
  * Remove the PCIe SMMU device tree node for now to rework
    (based on the discussion in the thread).

Brijesh Singh (2):
  dtb: amd: Fix GICv2 hypervisor and virtual interface sizes
  dtb: amd: Add KCS device tree node

Suravee Suthikulpanit (9):
  MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree
  dtb: amd: Fix DMA ranges in device tree
  dtb: amd: Fix typo in SPI device nodes
  dtb: amd: Misc changes for I2C device nodes
  dtb: amd: Misc changes for SATA device tree nodes
  dtb: amd: Misc changes for GPIO devices
  dtb: amd: Add PERF CCN-504 device tree node
  dtb: amd: Add support for new AMD Overdrive boards
  dtb: amd: Add support for AMD/Linaro 96Boards Enterprise Edition
    Server board

Tom Lendacky (1):
  dtb: amd: Add AMD XGBE device tree file

 MAINTAINERS                                      |   8 ++
 arch/arm64/boot/dts/amd/Makefile                 |   4 +-
 arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts |  87 +++++++++++++++++
 arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts |  91 ++++++++++++++++++
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi     | 105 +++++++++++++++++---
 arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi  | 117 +++++++++++++++++++++++
 arch/arm64/boot/dts/amd/husky.dts                |  83 ++++++++++++++++
 7 files changed, 481 insertions(+), 14 deletions(-)
 create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts
 create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts
 create mode 100644 arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi
 create mode 100644 arch/arm64/boot/dts/amd/husky.dts

-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Mon Feb  8 09:59:08 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Mon, 8 Feb 2016 11:59:08 -0600
Subject: [PATCH V2 03/12] dtb: amd: Fix DMA ranges in device tree
In-Reply-To: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1454954357-8395-4-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Fix DMA ranges of smb0 and pcie0 nodes in AMD Seattle SOC.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index fdd0c96..5c73117 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -55,8 +55,12 @@
 		#size-cells = <2>;
 		ranges;
 
-		/* DDR range is 40-bit addressing */
-		dma-ranges = <0x80 0x0 0x80 0x0 0x7f 0xffffffff>;
+		/*
+		 * dma-ranges is 40-bit address space containing:
+		 * - GICv2m MSI register is at 0xe0080000
+		 * - DRAM range [0x8000000000 to 0xffffffffff]
+		 */
+		dma-ranges = <0x0 0x0 0x0 0x0 0x100 0x0>;
 
 		/include/ "amd-seattle-clks.dtsi"
 
@@ -159,7 +163,7 @@
 				<0x1000 0x0 0x0 0x4 &gic0 0x0 0x0 0x0 0x123 0x1>;
 
 			dma-coherent;
-			dma-ranges = <0x43000000 0x80 0x0 0x80 0x0 0x7f 0xffffffff>;
+			dma-ranges = <0x43000000 0x0 0x0 0x0 0x0 0x100 0x0>;
 			ranges =
 				/* I/O Memory (size=64K) */
 				<0x01000000 0x00 0x00000000 0x00 0xefff0000 0x00 0x00010000>,
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Mon Feb  8 09:59:09 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Mon, 8 Feb 2016 11:59:09 -0600
Subject: [PATCH V2 04/12] dtb: amd: Fix typo in SPI device nodes
In-Reply-To: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1454954357-8395-5-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Remove invalid entry in the SPI device nodes.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 5c73117..c7c759a 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -91,7 +91,6 @@
 		spi0: ssp at e1020000 {
 			status = "disabled";
 			compatible = "arm,pl022", "arm,primecell";
-			#gpio-cells = <2>;
 			reg = <0 0xe1020000 0 0x1000>;
 			spi-controller;
 			interrupts = <0 330 4>;
@@ -102,7 +101,6 @@
 		spi1: ssp at e1030000 {
 			status = "disabled";
 			compatible = "arm,pl022", "arm,primecell";
-			#gpio-cells = <2>;
 			reg = <0 0xe1030000 0 0x1000>;
 			spi-controller;
 			interrupts = <0 329 4>;
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Mon Feb  8 09:59:06 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Mon, 8 Feb 2016 11:59:06 -0600
Subject: [PATCH V2 01/12] MAINTAINERS: Adding Maintainers for AMD Seattle
 Device Tree
In-Reply-To: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1454954357-8395-2-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Adding maintainers for AMD Seattle device tree.

Signed-off-by: Brijesh Singh <brijeshkumar.singh at amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com>
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7f1fa4f..e349a32 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -673,6 +673,13 @@ F:	drivers/gpu/drm/radeon/radeon_kfd.c
 F:	drivers/gpu/drm/radeon/radeon_kfd.h
 F:	include/uapi/linux/kfd_ioctl.h
 
+AMD SEATTLE DEVICE TREE SUPPORT
+M:	Brijesh Singh <brijeshkumar.singh at amd.com>
+M:	Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
+M:	Tom Lendacky <thomas.lendacky at amd.com>
+S:	Supported
+F:	arch/arm64/boot/dts/amd/
+
 AMD XGBE DRIVER
 M:	Tom Lendacky <thomas.lendacky at amd.com>
 L:	netdev at vger.kernel.org
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Mon Feb  8 09:59:10 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Mon, 8 Feb 2016 11:59:10 -0600
Subject: [PATCH V2 05/12] dtb: amd: Misc changes for I2C device nodes
In-Reply-To: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1454954357-8395-6-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Add new i2c1 device node, and fix the incorrect clock frequency.

Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index c7c759a..4be36fd 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -77,7 +77,15 @@
 			compatible = "snps,designware-i2c";
 			reg = <0 0xe1000000 0 0x1000>;
 			interrupts = <0 357 4>;
-			clocks = <&uartspiclk_100mhz>;
+			clocks = <&miscclk_250mhz>;
+		};
+
+		i2c1: i2c at e0050000 {
+			status = "disabled";
+			compatible = "snps,designware-i2c";
+			reg = <0 0xe0050000 0 0x1000>;
+			interrupts = <0 340 4>;
+			clocks = <&miscclk_250mhz>;
 		};
 
 		serial0: serial at e1010000 {
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Mon Feb  8 09:59:11 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Mon, 8 Feb 2016 11:59:11 -0600
Subject: [PATCH V2 06/12] dtb: amd: Misc changes for SATA device tree nodes
In-Reply-To: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1454954357-8395-7-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Add new SATA1 device node, and fix the register range size of SATA0.

Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 4be36fd..9f59381 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -66,12 +66,22 @@
 
 		sata0: sata at e0300000 {
 			compatible = "snps,dwc-ahci";
-			reg = <0 0xe0300000 0 0x800>;
+			reg = <0 0xe0300000 0 0xf0000>;
 			interrupts = <0 355 4>;
 			clocks = <&sataclk_333mhz>;
 			dma-coherent;
 		};
 
+		/* This is for Rev B only */
+		sata1: sata at e0d00000 {
+			status = "disabled";
+			compatible = "snps,dwc-ahci";
+			reg = <0 0xe0d00000 0 0xf0000>;
+			interrupts = <0 354 4>;
+			clocks = <&sataclk_333mhz>;
+			dma-coherent;
+		};
+
 		i2c0: i2c at e1000000 {
 			status = "disabled";
 			compatible = "snps,designware-i2c";
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Mon Feb  8 09:59:07 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Mon, 8 Feb 2016 11:59:07 -0600
Subject: [PATCH V2 02/12] dtb: amd: Fix GICv2 hypervisor and virtual interface
 sizes
In-Reply-To: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1454954357-8395-3-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Brijesh Singh <brijeshkumar.singh at amd.com>

This patch fixes incorrect sizes of the GICv2 device tree node.
This has triggered error message when booting Xen hypervisor.

Signed-off-by: Brijesh Singh <brijeshkumar.singh at amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 2874d92..fdd0c96 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -18,8 +18,8 @@
 		#size-cells = <2>;
 		reg = <0x0 0xe1110000 0 0x1000>,
 		      <0x0 0xe112f000 0 0x2000>,
-		      <0x0 0xe1140000 0 0x10000>,
-		      <0x0 0xe1160000 0 0x10000>;
+		      <0x0 0xe1140000 0 0x2000>,
+		      <0x0 0xe1160000 0 0x2000>;
 		interrupts = <1 9 0xf04>;
 		ranges = <0 0 0 0xe1100000 0 0x100000>;
 		v2m0: v2m at e0080000 {
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Mon Feb  8 09:59:12 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Mon, 8 Feb 2016 11:59:12 -0600
Subject: [PATCH V2 07/12] dtb: amd: Misc changes for GPIO devices
In-Reply-To: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1454954357-8395-8-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Add new GPIO device nodes and fix clock on gpio0.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 49 +++++++++++++++++++++++++---
 1 file changed, 45 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 9f59381..ba455d1 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -129,7 +129,7 @@
 			#size-cells = <0>;
 		};
 
-		gpio0: gpio at e1040000 {
+		gpio0: gpio at e1040000 { /* Not available to OS for B0 */
 			status = "disabled";
 			compatible = "arm,pl061", "arm,primecell";
 			#gpio-cells = <2>;
@@ -138,18 +138,59 @@
 			interrupts = <0 359 4>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
-			clocks = <&uartspiclk_100mhz>;
+			clocks = <&miscclk_250mhz>;
 			clock-names = "apb_pclk";
 		};
 
-		gpio1: gpio at e1050000 {
+		gpio1: gpio at e1050000 { /* [0:7] */
 			status = "disabled";
 			compatible = "arm,pl061", "arm,primecell";
 			#gpio-cells = <2>;
 			reg = <0 0xe1050000 0 0x1000>;
 			gpio-controller;
+			interrupt-controller;
+			#interrupt-cells = <2>;
 			interrupts = <0 358 4>;
-			clocks = <&uartspiclk_100mhz>;
+			clocks = <&miscclk_250mhz>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio2: gpio at e0020000 { /* [8:15] */
+			status = "disabled";
+			compatible = "arm,pl061", "arm,primecell";
+			#gpio-cells = <2>;
+			reg = <0 0xe0020000 0 0x1000>;
+			gpio-controller;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			interrupts = <0 366 4>;
+			clocks = <&miscclk_250mhz>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio3: gpio at e0030000 { /* [16:23] */
+			status = "disabled";
+			compatible = "arm,pl061", "arm,primecell";
+			#gpio-cells = <2>;
+			reg = <0 0xe0030000 0 0x1000>;
+			gpio-controller;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			interrupts = <0 365 4>;
+			clocks = <&miscclk_250mhz>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio4: gpio at e0080000 { /* [24] */
+			status = "disabled";
+			compatible = "arm,pl061", "arm,primecell";
+			#gpio-cells = <2>;
+			reg = <0 0xe0080000 0 0x1000>;
+			gpio-controller;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			interrupts = <0 361 4>;
+			clocks = <&miscclk_250mhz>;
 			clock-names = "apb_pclk";
 		};
 
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Mon Feb  8 09:59:13 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Mon, 8 Feb 2016 11:59:13 -0600
Subject: [PATCH V2 08/12] dtb: amd: Add PERF CCN-504 device tree node
In-Reply-To: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1454954357-8395-9-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Add PERF CCN-504 device tree node.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index ba455d1..c5461b2 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -229,5 +229,12 @@
 				/* 64-bit MMIO (size= 124G) */
 				<0x03000000 0x01 0x00000000 0x01 0x00000000 0x7f 0x00000000>;
 		};
+
+		/* Perf CCN504 PMU */
+		ccn: ccn at 0xe8000000 {
+			compatible = "arm,ccn-504";
+			reg = <0x0 0xe8000000 0 0x1000000>;
+			interrupts = <0 380 4>;
+		};
 	};
 };
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Mon Feb  8 09:59:14 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Mon, 8 Feb 2016 11:59:14 -0600
Subject: [PATCH V2 09/12] dtb: amd: Add KCS device tree node
In-Reply-To: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1454954357-8395-10-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Brijesh Singh <brijeshkumar.singh at amd.com>

Add KCS device node to support IPMI solution on Overdrive
system.

Signed-off-by: Brijesh Singh <brijeshkumar.singh at amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index c5461b2..a7fc059 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -236,5 +236,16 @@
 			reg = <0x0 0xe8000000 0 0x1000000>;
 			interrupts = <0 380 4>;
 		};
+
+		ipmi_kcs: kcs at e0010000 {
+			status = "disabled";
+			compatible = "ipmi-kcs";
+			device_type = "ipmi";
+			reg = <0x0 0xe0010000 0 0x8>;
+			interrupts = <0 389 4>;
+			interrupt-names = "ipmi_kcs";
+			reg-size = <1>;
+			reg-spacing = <4>;
+		};
 	};
 };
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Mon Feb  8 09:59:16 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Mon, 8 Feb 2016 11:59:16 -0600
Subject: [PATCH V2 11/12] dtb: amd: Add support for new AMD Overdrive boards
In-Reply-To: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1454954357-8395-12-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Add device tree files for AMD Overdrive boards which comes with
AMD Seattle Revision B0 and B1 SOCs.

Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/Makefile                 |  3 +-
 arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts | 87 ++++++++++++++++++++++
 arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts | 91 ++++++++++++++++++++++++
 3 files changed, 180 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts
 create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts

diff --git a/arch/arm64/boot/dts/amd/Makefile b/arch/arm64/boot/dts/amd/Makefile
index cfdf701..db03293 100644
--- a/arch/arm64/boot/dts/amd/Makefile
+++ b/arch/arm64/boot/dts/amd/Makefile
@@ -1,4 +1,5 @@
-dtb-$(CONFIG_ARCH_SEATTLE) += amd-overdrive.dtb
+dtb-$(CONFIG_ARCH_SEATTLE) += amd-overdrive.dtb \
+			amd-overdrive-rev-b0.dtb amd-overdrive-rev-b1.dtb
 
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
diff --git a/arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts b/arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts
new file mode 100644
index 0000000..8e3074a
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts
@@ -0,0 +1,87 @@
+/*
+ * DTS file for AMD Seattle Overdrive Development Board
+ * Note: For Seattle Rev.B0
+ *
+ * Copyright (C) 2015 Advanced Micro Devices, Inc.
+ */
+
+/dts-v1/;
+
+/include/ "amd-seattle-soc.dtsi"
+
+/ {
+	model = "AMD Seattle (Rev.B0) Development Board (Overdrive)";
+	compatible = "amd,seattle-overdrive", "amd,seattle";
+
+	chosen {
+		stdout-path = &serial0;
+	};
+
+	psci {
+		compatible   = "arm,psci-0.2";
+		method       = "smc";
+	};
+};
+
+&ccp0 {
+	status = "ok";
+	amd,zlib-support = <1>;
+};
+
+/**
+ * NOTE: In Rev.B, gpio0 is reserved.
+ */
+&gpio1 {
+	status = "ok";
+};
+
+&gpio2 {
+	status = "ok";
+};
+
+&gpio3 {
+	status = "ok";
+};
+
+&gpio4 {
+	status = "ok";
+};
+
+&i2c0 {
+	status = "ok";
+};
+
+&i2c1 {
+	status = "ok";
+};
+
+&pcie0 {
+	status = "ok";
+};
+
+&spi0 {
+	status = "ok";
+};
+
+&spi1 {
+	status = "ok";
+	sdcard0: sdcard at 0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		spi-max-frequency = <20000000>;
+		voltage-ranges = <3200 3400>;
+		pl022,hierarchy = <0>;
+		pl022,interface = <0>;
+		pl022,com-mode = <0x0>;
+		pl022,rx-level-trig = <0>;
+		pl022,tx-level-trig = <0>;
+	};
+};
+
+&ipmi_kcs {
+	status = "ok";
+};
+
+&smb0 {
+	/include/ "amd-seattle-xgbe-b.dtsi"
+};
diff --git a/arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts b/arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts
new file mode 100644
index 0000000..ed5e043
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts
@@ -0,0 +1,91 @@
+/*
+ * DTS file for AMD Seattle Overdrive Development Board
+ * Note: For Seattle Rev.B1
+ *
+ * Copyright (C) 2015 Advanced Micro Devices, Inc.
+ */
+
+/dts-v1/;
+
+/include/ "amd-seattle-soc.dtsi"
+
+/ {
+	model = "AMD Seattle (Rev.B1) Development Board (Overdrive)";
+	compatible = "amd,seattle-overdrive", "amd,seattle";
+
+	chosen {
+		stdout-path = &serial0;
+	};
+
+	psci {
+		compatible   = "arm,psci-0.2";
+		method       = "smc";
+	};
+};
+
+&ccp0 {
+	status = "ok";
+	amd,zlib-support = <1>;
+};
+
+/**
+ * NOTE: In Rev.B, gpio0 is reserved.
+ */
+&gpio1 {
+	status = "ok";
+};
+
+&gpio2 {
+	status = "ok";
+};
+
+&gpio3 {
+	status = "ok";
+};
+
+&gpio4 {
+	status = "ok";
+};
+
+&i2c0 {
+	status = "ok";
+};
+
+&i2c1 {
+	status = "ok";
+};
+
+&pcie0 {
+	status = "ok";
+};
+
+&sata1 {
+	status = "ok";
+};
+
+&spi0 {
+	status = "ok";
+};
+
+&spi1 {
+	status = "ok";
+	sdcard0: sdcard at 0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		spi-max-frequency = <20000000>;
+		voltage-ranges = <3200 3400>;
+		pl022,hierarchy = <0>;
+		pl022,interface = <0>;
+		pl022,com-mode = <0x0>;
+		pl022,rx-level-trig = <0>;
+		pl022,tx-level-trig = <0>;
+	};
+};
+
+&ipmi_kcs {
+	status = "ok";
+};
+
+&smb0 {
+	/include/ "amd-seattle-xgbe-b.dtsi"
+};
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Mon Feb  8 09:59:15 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Mon, 8 Feb 2016 11:59:15 -0600
Subject: [PATCH V2 10/12] dtb: amd: Add AMD XGBE device tree file
In-Reply-To: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1454954357-8395-11-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Tom Lendacky <thomas.lendacky at amd.com>

Add AMD XGBE device tree file, which is available in AMD Seattle RevB.

Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com>
---
 MAINTAINERS                                     |   1 +
 arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi | 117 ++++++++++++++++++++++++
 2 files changed, 118 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi

diff --git a/MAINTAINERS b/MAINTAINERS
index e349a32..9547a68 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -685,6 +685,7 @@ M:	Tom Lendacky <thomas.lendacky at amd.com>
 L:	netdev at vger.kernel.org
 S:	Supported
 F:	drivers/net/ethernet/amd/xgbe/
+F:	arch/arm64/boot/dts/amd/amd-seattle-xgbe*.dtsi
 
 AMS (Apple Motion Sensor) DRIVER
 M:	Michael Hanselmann <linux-kernel at hansmi.ch>
diff --git a/arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi
new file mode 100644
index 0000000..8e86319
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi
@@ -0,0 +1,117 @@
+/*
+ * DTS file for AMD Seattle XGBE (RevB)
+ *
+ * Copyright (C) 2015 Advanced Micro Devices, Inc.
+ */
+
+	xgmacclk0_dma_250mhz: clk250mhz_0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <250000000>;
+		clock-output-names = "xgmacclk0_dma_250mhz";
+	};
+
+	xgmacclk0_ptp_250mhz: clk250mhz_1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <250000000>;
+		clock-output-names = "xgmacclk0_ptp_250mhz";
+	};
+
+	xgmacclk1_dma_250mhz: clk250mhz_2 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <250000000>;
+		clock-output-names = "xgmacclk1_dma_250mhz";
+	};
+
+	xgmacclk1_ptp_250mhz: clk250mhz_3 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <250000000>;
+		clock-output-names = "xgmacclk1_ptp_250mhz";
+	};
+
+	xgmac0: xgmac at e0700000 {
+		compatible = "amd,xgbe-seattle-v1a";
+		reg = <0 0xe0700000 0 0x80000>,
+		      <0 0xe0780000 0 0x80000>,
+		      <0 0xe1240800 0 0x00400>, /* SERDES RX/TX0 */
+		      <0 0xe1250000 0 0x00060>, /* SERDES IR 1/2 */
+		      <0 0xe12500f8 0 0x00004>; /* SERDES IR 2/2 */
+		interrupts = <0 325 4>,
+			     <0 346 1>, <0 347 1>, <0 348 1>, <0 349 1>,
+			     <0 323 4>;
+		amd,per-channel-interrupt;
+		amd,speed-set = <0>;
+		amd,serdes-blwc = <1>, <1>, <0>;
+		amd,serdes-cdr-rate = <2>, <2>, <7>;
+		amd,serdes-pq-skew = <10>, <10>, <18>;
+		amd,serdes-tx-amp = <0>, <0>, <0>;
+		amd,serdes-dfe-tap-config = <3>, <3>, <3>;
+		amd,serdes-dfe-tap-enable = <0>, <0>, <7>;
+		mac-address = [ 02 A1 A2 A3 A4 A5 ];
+		clocks = <&xgmacclk0_dma_250mhz>, <&xgmacclk0_ptp_250mhz>;
+		clock-names = "dma_clk", "ptp_clk";
+		phy-mode = "xgmii";
+		#stream-id-cells = <16>;
+		dma-coherent;
+	};
+
+	xgmac1: xgmac at e0900000 {
+		compatible = "amd,xgbe-seattle-v1a";
+		reg = <0 0xe0900000 0 0x80000>,
+		      <0 0xe0980000 0 0x80000>,
+		      <0 0xe1240c00 0 0x00400>, /* SERDES RX/TX1 */
+		      <0 0xe1250080 0 0x00060>, /* SERDES IR 1/2 */
+		      <0 0xe12500fc 0 0x00004>; /* SERDES IR 2/2 */
+		interrupts = <0 324 4>,
+			     <0 341 1>, <0 342 1>, <0 343 1>, <0 344 1>,
+			     <0 322 4>;
+		amd,per-channel-interrupt;
+		amd,speed-set = <0>;
+		amd,serdes-blwc = <1>, <1>, <0>;
+		amd,serdes-cdr-rate = <2>, <2>, <7>;
+		amd,serdes-pq-skew = <10>, <10>, <18>;
+		amd,serdes-tx-amp = <0>, <0>, <0>;
+		amd,serdes-dfe-tap-config = <3>, <3>, <3>;
+		amd,serdes-dfe-tap-enable = <0>, <0>, <7>;
+		mac-address = [ 02 B1 B2 B3 B4 B5 ];
+		clocks = <&xgmacclk1_dma_250mhz>, <&xgmacclk1_ptp_250mhz>;
+		clock-names = "dma_clk", "ptp_clk";
+		phy-mode = "xgmii";
+		#stream-id-cells = <16>;
+		dma-coherent;
+	};
+
+	xgmac0_smmu: smmu at e0600000 {
+		 compatible = "arm,mmu-401";
+		 reg = <0 0xe0600000 0 0x10000>;
+		 #global-interrupts = <1>;
+		 interrupts = /* Uses combined intr for both
+			       * global and context
+			       */
+			      <0 336 4>,
+			      <0 336 4>;
+
+		 mmu-masters = <&xgmac0
+			  0  1  2  3  4  5  6  7
+			 16 17 18 19 20 21 22 23
+		 >;
+	 };
+
+	 xgmac1_smmu: smmu at e0800000 {
+		 compatible = "arm,mmu-401";
+		 reg = <0 0xe0800000 0 0x10000>;
+		 #global-interrupts = <1>;
+		 interrupts = /* Uses combined intr for both
+			       * global and context
+			       */
+			      <0 335 4>,
+			      <0 335 4>;
+
+		 mmu-masters = <&xgmac1
+			  0  1  2  3  4  5  6  7
+			 16 17 18 19 20 21 22 23
+		 >;
+	 };
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Mon Feb  8 09:59:17 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Mon, 8 Feb 2016 11:59:17 -0600
Subject: [PATCH V2 12/12] dtb: amd: Add support for AMD/Linaro 96Boards
 Enterprise Edition Server board
In-Reply-To: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1454954357-8395-13-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Add device tree file for AMD/Linaro 96Boards Enterprise Edition Server
(Husky) Board. This is based on the AMD Seattle Rev.B0 system

Signed-off-by: Leo Duran <leo.duran at amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/Makefile  |  3 +-
 arch/arm64/boot/dts/amd/husky.dts | 83 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 85 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/amd/husky.dts

diff --git a/arch/arm64/boot/dts/amd/Makefile b/arch/arm64/boot/dts/amd/Makefile
index db03293..ba84770 100644
--- a/arch/arm64/boot/dts/amd/Makefile
+++ b/arch/arm64/boot/dts/amd/Makefile
@@ -1,5 +1,6 @@
 dtb-$(CONFIG_ARCH_SEATTLE) += amd-overdrive.dtb \
-			amd-overdrive-rev-b0.dtb amd-overdrive-rev-b1.dtb
+			amd-overdrive-rev-b0.dtb amd-overdrive-rev-b1.dtb \
+			husky.dtb
 
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
diff --git a/arch/arm64/boot/dts/amd/husky.dts b/arch/arm64/boot/dts/amd/husky.dts
new file mode 100644
index 0000000..1381d4b
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/husky.dts
@@ -0,0 +1,83 @@
+/*
+ * DTS file for AMD/Linaro 96Boards Enterprise Edition Server (Husky) Board
+ * Note: Based-on AMD Seattle Rev.B0
+ *
+ * Copyright (C) 2015 Advanced Micro Devices, Inc.
+ */
+
+/dts-v1/;
+
+/include/ "amd-seattle-soc.dtsi"
+
+/ {
+	model = "Linaro 96Boards Enterprise Edition Server (Husky) Board";
+	compatible = "amd,seattle-overdrive", "amd,seattle";
+
+	chosen {
+		stdout-path = &serial0;
+	};
+
+	psci {
+		compatible   = "arm,psci-0.2";
+		method       = "smc";
+	};
+};
+
+&ccp0 {
+	status = "ok";
+	amd,zlib-support = <1>;
+};
+
+/**
+ * NOTE: In Rev.B, gpio0 is reserved.
+ */
+&gpio1 {
+	status = "ok";
+};
+
+&gpio2 {
+	status = "ok";
+};
+
+&gpio3 {
+	status = "ok";
+};
+
+&gpio4 {
+	status = "ok";
+};
+
+&i2c0 {
+	status = "ok";
+};
+
+&i2c1 {
+	status = "ok";
+};
+
+&pcie0 {
+	status = "ok";
+};
+
+&spi0 {
+	status = "ok";
+};
+
+&spi1 {
+	status = "ok";
+	sdcard0: sdcard at 0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		spi-max-frequency = <20000000>;
+		voltage-ranges = <3200 3400>;
+		pl022,hierarchy = <0>;
+		pl022,interface = <0>;
+		pl022,com-mode = <0x0>;
+		pl022,rx-level-trig = <0>;
+		pl022,tx-level-trig = <0>;
+	};
+};
+
+&smb0 {
+	/include/ "amd-seattle-xgbe-b.dtsi"
+};
-- 
2.5.0



From mark.rutland at arm.com  Mon Feb  8 10:04:19 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 8 Feb 2016 18:04:19 +0000
Subject: [RESEND2 PATCH 0/3] Fix kernel panic in dma-coherent
In-Reply-To: <56B8D77D.3050305@arm.com>
References: <cover.1454950917.git.brian.starkey@arm.com>
 <20160208175054.GD15443@leverpostej> <56B8D77D.3050305@arm.com>
Message-ID: <20160208180418.GE15443@leverpostej>

On Mon, Feb 08, 2016 at 05:59:25PM +0000, Robin Murphy wrote:
> Hi Mark,
> 
> On 08/02/16 17:50, Mark Rutland wrote:
> >On Mon, Feb 08, 2016 at 05:30:49PM +0000, Brian Starkey wrote:
> >>Hi,
> >>
> >>I'm resending these again to try and garner some interest. Without
> >>this series, dma-coherent cannot be used on arm64 platforms.
> >
> >I think you need to characterize that a bit better. I see plenty of
> >instances of 'dma-coherent' in dts files, assuming you mean the DT
> >dma-coehrent property.
> >
> >If not, feel free to stop reading now.
> 
> Terminology overload: the dma-coherent DT property is about devices
> having cache-coherent access to system memory within the linear map.
> The dma-coherent thing here is pretty much the precise opposite of
> that - namely creating CPU mappings for memory which belongs to the
> device itself and may be behind an I/O bus (e.g. a framebuffer on a
> video card).

Phew.

Sorry for the noise, and thanks for setting me straight!

Mark.


From catalin.marinas at arm.com  Mon Feb  8 10:13:06 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 8 Feb 2016 18:13:06 +0000
Subject: [PATCH] arm64: allow the module region to be randomized
 independently
In-Reply-To: <1454926332-25929-1-git-send-email-ard.biesheuvel@linaro.org>
References: <CAGXu5j+1rcScYedzQ5o0aaGZJWPCBGk-gai0D8jY8Huc-VuG7A@mail.gmail.com>
 <1454926332-25929-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160208181305.GW6076@e104818-lin.cambridge.arm.com>

On Mon, Feb 08, 2016 at 11:12:12AM +0100, Ard Biesheuvel wrote:
> This adds the option to randomize the module region independently from the
> core kernel, and enables it by default. This makes it less likely that the
> location of core kernel data structures can be determined by an adversary,
> but causes all function calls from modules into the core kernel to be
> resolved via entries in the module PLTs.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
>  arch/arm64/Kconfig              | 15 ++++++++
>  arch/arm64/include/asm/module.h |  6 ++++
>  arch/arm64/kernel/kaslr.c       | 36 +++++++++++++++-----
>  arch/arm64/kernel/module.c      |  9 ++---
>  4 files changed, 50 insertions(+), 16 deletions(-)

With this patch I get an unhandled paging request, coming from
kernel/module.c:2982 (the memset). The PC is wrongly attributed but it's
in arch/arm64/lib/memset.S:

[    7.140606] Unable to handle kernel paging request at virtual address 00004000
[    7.147794] pgd = ffffffc060171000
[    7.151190] [00004000] *pgd=0000000000000000, *pud=0000000000000000
[    7.157447] Internal error: Oops: 96000045 [#1] PREEMPT SMP
[    7.162962] Modules linked in:
[    7.165995] CPU: 1 PID: 875 Comm: systemd-modules Not tainted 4.5.0-rc1+ #95
[    7.172976] Hardware name: Juno (DT)
[    7.176520] task: ffffffc9760bb000 ti: ffffffc079538000 task.ti: ffffffc079538000
[    7.183939] PC is at __efistub_memset+0x1ac/0x200
[    7.188601] LR is at load_module+0xfc8/0x1df8
[    7.192912] pc : [<ffffff8008336fac>] lr : [<ffffff8008120d88>] pstate: 40000145
[    7.200233] sp : ffffffc07953bd40
[    7.203514] x29: ffffffc07953bd40 x28: 0000000000002361
[    7.208791] x27: ffffff80086bb000 x26: ffffff8008f84aa0
[    7.214054] x25: 0000000000000111 x24: 000000000000006e
[    7.219317] x23: 0000007f7bc01918 x22: ffffff8008f0e100
[    7.224580] x21: ffffff8008f4d2c0 x20: 0000000000004000
[    7.229855] x19: ffffffc07953be70 x18: 0000000000000000
[    7.235127] x17: 0000000000000000 x16: 0000000000000002
[    7.240398] x15: ffffffffffffffff x14: ffffff0000000000
[    7.245667] x13: ffffffbdc3e55340 x12: 0000000000006fff
[    7.250934] x11: ffffffc97fed46a8 x10: 0000000000000010
[    7.256198] x9 : 0000000000000000 x8 : 0000000000004000
[    7.261462] x7 : 0000000000000000 x6 : 000000000000003f
[    7.266823] x5 : 0000000000000040 x4 : 0000000000000000 [    7.271219] systemd-journald[864]: Received request to flush runtime journal from PID 1

[    7.279835]
[    7.281487] x3 : 0000000000000004 x2 : 000000000000229e
[    7.286758] x1 : 0000000000000000 x0 : 0000000000004000
[    7.292019]
[    7.293495] Process systemd-modules (pid: 875, stack limit = 0xffffffc079538020)
[    7.300822] Stack: (0xffffffc07953bd40 to 0xffffffc07953c000)
[    7.306522] bd40: ffffffc07953be40 ffffff8008121de0 0000000000000000 0000000000000005
[    7.314276] bd60: 0000007f7bc01918 0000007f7bb24ad4 0000000080000000 0000000000000015
[    7.322029] bd80: 000000000000011e 0000000000000111 ffffff80086b0000 ffffffc079538000
[    7.329781] bda0: 0000000000000000 0000000000000005 0000007f7bc01918 0000007f7bb24ad4
[    7.337536] bdc0: ffffff8008f0e288 ffffff8008f84ae0 ffffff8008f0e2d8 ffffff8008f0d000
[    7.345288] bde0: ffff81a40000000f 0000000000000001 0000000000000000 0000000000077b20
[    7.353041] be00: 0000000056b8d7f8 00000000134c2b98 0000000056b8d7f8 000000001163e398
[    7.360793] be20: 0000000056b8d7f8 000000001163e398 0000000000001000 00000000000003c0
[    7.368545] be40: 0000000000000000 ffffff8008085d30 0000000000000000 0000000000000000
[    7.376298] be60: ffffffffffffffff 0000005571c2aa60 ffffff8008f0d000 0000000000077b20
[    7.384051] be80: ffffff8008f84120 ffffff8008f4b7af ffffff8008f4d2c0 0000000000001388
[    7.391803] bea0: 0000000000001dd8 0000000000000000 0000000000000000 0000002700000026
[    7.399555] bec0: 0000000000000011 000000000000000b 0000000000000005 0000007f7bc01918
[    7.407307] bee0: 0000000000000000 0000000000000005 0000000000000000 60ceffffffffffff
[    7.415060] bf00: ffffffffffffffff ffffffffffffffff 0000000000000111 0000000000000038
[    7.422812] bf20: 0101010101010101 0000000000000001 0000000000000000 ffffffffffff0000
[    7.430565] bf40: 0000007f7bc43000 0000007f7ba626b8 0000007f7bb24ab0 0000007f7bc132d8
[    7.438317] bf60: 0000005565850710 0000005571c2a8a0 0000000000000000 0000007f7bc01918
[    7.446069] bf80: 0000005571c2a920 0000000000020000 0000000000000000 0000000000000000
[    7.453821] bfa0: 0000005571c29330 0000000000000000 0000000000000000 0000007ff3bc1e80
[    7.461575] bfc0: 0000007f7bbfa1ac 0000007ff3bc1e80 0000007f7bb24ad4 0000000080000000
[    7.469327] bfe0: 0000000000000005 0000000000000111 f712e45f3fdb5baf 5d70fcf3d73b5fa3
[    7.477075] Call trace:
[    7.479494] Exception stack(0xffffffc07953bb80 to 0xffffffc07953bca0)
[    7.485871] bb80: ffffffc07953be70 0000000000004000 ffffffc07953bd40 ffffff8008336fac
[    7.493624] bba0: 0000000000400000 00000000024000c0 ffffffc975853300 00c8000000000713
[    7.501376] bbc0: ffffff80086bb000 0000000000002361 0000000000004000 0000000000000000
[    7.509128] bbe0: ffffffc07953bc60 ffffff80081885d8 ffffffc07953bca0 ffffff8008187fb8
[    7.516880] bc00: 0000000000000003 ffffffc975853480 00000000ffffffff 00000000024002c0
[    7.524631] bc20: 0000000000004000 0000000000000000 000000000000229e 0000000000000004
[    7.532383] bc40: 0000000000000000 0000000000000040 000000000000003f 0000000000000000
[    7.540135] bc60: 0000000000004000 0000000000000000 0000000000000010 ffffffc97fed46a8
[    7.547888] bc80: 0000000000006fff ffffffbdc3e55340 ffffff0000000000 ffffffffffffffff
[    7.555646] [<ffffff8008336fac>] __efistub_memset+0x1ac/0x200
[    7.561334] [<ffffff8008121de0>] SyS_finit_module+0xb0/0xc0
[    7.566852] [<ffffff8008085d30>] el0_svc_naked+0x24/0x28
[    7.572112] Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428)
[    7.578196] ---[ end trace 13bd770b734da68a ]---

-- 
Catalin


From mmarek at suse.cz  Mon Feb  8 10:13:26 2016
From: mmarek at suse.cz (Michal Marek)
Date: Mon, 8 Feb 2016 19:13:26 +0100
Subject: [PATCH] Kbuild: provide a __UNIQUE_ID for clang
In-Reply-To: <1454942318-2782493-1-git-send-email-arnd@arndb.de>
References: <1454942318-2782493-1-git-send-email-arnd@arndb.de>
Message-ID: <20160208181326.GA3784@pobox.suse.cz>

On Mon, Feb 08, 2016 at 03:38:32PM +0100, Arnd Bergmann wrote:
> The default __UNIQUE_ID macro in compiler.h fails to work for some drivers:
> 
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:615:1: error: redefinition of
>       '__UNIQUE_ID_firmware615'
> BRCMF_FW_NVRAM_DEF(4354, "brcmfmac4354-sdio.bin", "brcmfmac4354-sdio.txt");

I applied the patch to kbuild.git#kbuild, but can you tell me with which
commit and config you get such failure. I only see a single
MODULE_FIRMWARE() call in the expansion of BRCMF_FW_NVRAM_DEF(), which
should work with line numbers as well. And I can't reproduce it with
today's linux-next. If there is some issue with code not yet in
linux-next, it needs to be worked around, because older GCCs did not
have __COUNTER__.

Michal


From catalin.marinas at arm.com  Mon Feb  8 10:15:53 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 8 Feb 2016 18:15:53 +0000
Subject: [PATCH] arm64: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL
In-Reply-To: <1454716218-4918-1-git-send-email-yang.shi@linaro.org>
References: <1454716218-4918-1-git-send-email-yang.shi@linaro.org>
Message-ID: <20160208181553.GX6076@e104818-lin.cambridge.arm.com>

On Fri, Feb 05, 2016 at 03:50:18PM -0800, Yang Shi wrote:
> To enable UBSAN on arm64, ARCH_HAS_UBSAN_SANITIZE_ALL need to be selected.
> 
> Basic kernel bootup test is passed on arm64 with CONFIG_UBSAN_SANITIZE_ALL
> enabled.
> 
> Signed-off-by: Yang Shi <yang.shi at linaro.org>

Applied. Thanks.

-- 
Catalin


From ard.biesheuvel at linaro.org  Mon Feb  8 10:29:26 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 8 Feb 2016 19:29:26 +0100
Subject: [PATCH] arm64: allow the module region to be randomized
 independently
In-Reply-To: <20160208181305.GW6076@e104818-lin.cambridge.arm.com>
References: <CAGXu5j+1rcScYedzQ5o0aaGZJWPCBGk-gai0D8jY8Huc-VuG7A@mail.gmail.com>
 <1454926332-25929-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160208181305.GW6076@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu-qKgT4VhsWs7gVDCbpi_Or6RruhQ+iRMXJFQrwithSyQ@mail.gmail.com>

On 8 February 2016 at 19:13, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 08, 2016 at 11:12:12AM +0100, Ard Biesheuvel wrote:
>> This adds the option to randomize the module region independently from the
>> core kernel, and enables it by default. This makes it less likely that the
>> location of core kernel data structures can be determined by an adversary,
>> but causes all function calls from modules into the core kernel to be
>> resolved via entries in the module PLTs.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> ---
>>  arch/arm64/Kconfig              | 15 ++++++++
>>  arch/arm64/include/asm/module.h |  6 ++++
>>  arch/arm64/kernel/kaslr.c       | 36 +++++++++++++++-----
>>  arch/arm64/kernel/module.c      |  9 ++---
>>  4 files changed, 50 insertions(+), 16 deletions(-)
>
> With this patch I get an unhandled paging request, coming from
> kernel/module.c:2982 (the memset). The PC is wrongly attributed but it's
> in arch/arm64/lib/memset.S:
>

That is quite surprising tbh. The only thing that is supposed to
happen here is that the low and high limits of the
__vmalloc_node_range() call in module_alloc() are modified. I don't
see how a successful __vmalloc_node_range() call should end up here.

I will try to reproduce tomorrow.

-- 
Ard.


> [    7.140606] Unable to handle kernel paging request at virtual address 00004000
> [    7.147794] pgd = ffffffc060171000
> [    7.151190] [00004000] *pgd=0000000000000000, *pud=0000000000000000
> [    7.157447] Internal error: Oops: 96000045 [#1] PREEMPT SMP
> [    7.162962] Modules linked in:
> [    7.165995] CPU: 1 PID: 875 Comm: systemd-modules Not tainted 4.5.0-rc1+ #95
> [    7.172976] Hardware name: Juno (DT)
> [    7.176520] task: ffffffc9760bb000 ti: ffffffc079538000 task.ti: ffffffc079538000
> [    7.183939] PC is at __efistub_memset+0x1ac/0x200
> [    7.188601] LR is at load_module+0xfc8/0x1df8
> [    7.192912] pc : [<ffffff8008336fac>] lr : [<ffffff8008120d88>] pstate: 40000145
> [    7.200233] sp : ffffffc07953bd40
> [    7.203514] x29: ffffffc07953bd40 x28: 0000000000002361
> [    7.208791] x27: ffffff80086bb000 x26: ffffff8008f84aa0
> [    7.214054] x25: 0000000000000111 x24: 000000000000006e
> [    7.219317] x23: 0000007f7bc01918 x22: ffffff8008f0e100
> [    7.224580] x21: ffffff8008f4d2c0 x20: 0000000000004000
> [    7.229855] x19: ffffffc07953be70 x18: 0000000000000000
> [    7.235127] x17: 0000000000000000 x16: 0000000000000002
> [    7.240398] x15: ffffffffffffffff x14: ffffff0000000000
> [    7.245667] x13: ffffffbdc3e55340 x12: 0000000000006fff
> [    7.250934] x11: ffffffc97fed46a8 x10: 0000000000000010
> [    7.256198] x9 : 0000000000000000 x8 : 0000000000004000
> [    7.261462] x7 : 0000000000000000 x6 : 000000000000003f
> [    7.266823] x5 : 0000000000000040 x4 : 0000000000000000 [    7.271219] systemd-journald[864]: Received request to flush runtime journal from PID 1
>
> [    7.279835]
> [    7.281487] x3 : 0000000000000004 x2 : 000000000000229e
> [    7.286758] x1 : 0000000000000000 x0 : 0000000000004000
> [    7.292019]
> [    7.293495] Process systemd-modules (pid: 875, stack limit = 0xffffffc079538020)
> [    7.300822] Stack: (0xffffffc07953bd40 to 0xffffffc07953c000)
> [    7.306522] bd40: ffffffc07953be40 ffffff8008121de0 0000000000000000 0000000000000005
> [    7.314276] bd60: 0000007f7bc01918 0000007f7bb24ad4 0000000080000000 0000000000000015
> [    7.322029] bd80: 000000000000011e 0000000000000111 ffffff80086b0000 ffffffc079538000
> [    7.329781] bda0: 0000000000000000 0000000000000005 0000007f7bc01918 0000007f7bb24ad4
> [    7.337536] bdc0: ffffff8008f0e288 ffffff8008f84ae0 ffffff8008f0e2d8 ffffff8008f0d000
> [    7.345288] bde0: ffff81a40000000f 0000000000000001 0000000000000000 0000000000077b20
> [    7.353041] be00: 0000000056b8d7f8 00000000134c2b98 0000000056b8d7f8 000000001163e398
> [    7.360793] be20: 0000000056b8d7f8 000000001163e398 0000000000001000 00000000000003c0
> [    7.368545] be40: 0000000000000000 ffffff8008085d30 0000000000000000 0000000000000000
> [    7.376298] be60: ffffffffffffffff 0000005571c2aa60 ffffff8008f0d000 0000000000077b20
> [    7.384051] be80: ffffff8008f84120 ffffff8008f4b7af ffffff8008f4d2c0 0000000000001388
> [    7.391803] bea0: 0000000000001dd8 0000000000000000 0000000000000000 0000002700000026
> [    7.399555] bec0: 0000000000000011 000000000000000b 0000000000000005 0000007f7bc01918
> [    7.407307] bee0: 0000000000000000 0000000000000005 0000000000000000 60ceffffffffffff
> [    7.415060] bf00: ffffffffffffffff ffffffffffffffff 0000000000000111 0000000000000038
> [    7.422812] bf20: 0101010101010101 0000000000000001 0000000000000000 ffffffffffff0000
> [    7.430565] bf40: 0000007f7bc43000 0000007f7ba626b8 0000007f7bb24ab0 0000007f7bc132d8
> [    7.438317] bf60: 0000005565850710 0000005571c2a8a0 0000000000000000 0000007f7bc01918
> [    7.446069] bf80: 0000005571c2a920 0000000000020000 0000000000000000 0000000000000000
> [    7.453821] bfa0: 0000005571c29330 0000000000000000 0000000000000000 0000007ff3bc1e80
> [    7.461575] bfc0: 0000007f7bbfa1ac 0000007ff3bc1e80 0000007f7bb24ad4 0000000080000000
> [    7.469327] bfe0: 0000000000000005 0000000000000111 f712e45f3fdb5baf 5d70fcf3d73b5fa3
> [    7.477075] Call trace:
> [    7.479494] Exception stack(0xffffffc07953bb80 to 0xffffffc07953bca0)
> [    7.485871] bb80: ffffffc07953be70 0000000000004000 ffffffc07953bd40 ffffff8008336fac
> [    7.493624] bba0: 0000000000400000 00000000024000c0 ffffffc975853300 00c8000000000713
> [    7.501376] bbc0: ffffff80086bb000 0000000000002361 0000000000004000 0000000000000000
> [    7.509128] bbe0: ffffffc07953bc60 ffffff80081885d8 ffffffc07953bca0 ffffff8008187fb8
> [    7.516880] bc00: 0000000000000003 ffffffc975853480 00000000ffffffff 00000000024002c0
> [    7.524631] bc20: 0000000000004000 0000000000000000 000000000000229e 0000000000000004
> [    7.532383] bc40: 0000000000000000 0000000000000040 000000000000003f 0000000000000000
> [    7.540135] bc60: 0000000000004000 0000000000000000 0000000000000010 ffffffc97fed46a8
> [    7.547888] bc80: 0000000000006fff ffffffbdc3e55340 ffffff0000000000 ffffffffffffffff
> [    7.555646] [<ffffff8008336fac>] __efistub_memset+0x1ac/0x200
> [    7.561334] [<ffffff8008121de0>] SyS_finit_module+0xb0/0xc0
> [    7.566852] [<ffffff8008085d30>] el0_svc_naked+0x24/0x28
> [    7.572112] Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428)
> [    7.578196] ---[ end trace 13bd770b734da68a ]---
>
> --
> Catalin


From gregkh at linuxfoundation.org  Mon Feb  8 10:30:06 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 8 Feb 2016 10:30:06 -0800
Subject: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag
In-Reply-To: <9085d37fa97a762a46b9d58719c085368682c64f.1454950917.git.brian.starkey@arm.com>
References: <cover.1454950917.git.brian.starkey@arm.com>
 <9085d37fa97a762a46b9d58719c085368682c64f.1454950917.git.brian.starkey@arm.com>
Message-ID: <20160208183006.GA8429@kroah.com>

On Mon, Feb 08, 2016 at 05:30:50PM +0000, Brian Starkey wrote:
> Add a flag to memremap() for writecombine mappings. Mappings satisfied
> by this flag will not be cached, however writes may be delayed or
> combined into more efficient bursts. This is most suitable for
> buffers written sequentially by the CPU for use by other DMA devices.
> 
> Signed-off-by: Brian Starkey <brian.starkey at arm.com>
> Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
> ---
>  include/linux/io.h |    1 +
>  kernel/memremap.c  |   15 +++++++++++++--
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/io.h b/include/linux/io.h
> index 32403b5..e2c8419 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -135,6 +135,7 @@ enum {
>  	/* See memremap() kernel-doc for usage description... */
>  	MEMREMAP_WB = 1 << 0,
>  	MEMREMAP_WT = 1 << 1,
> +	MEMREMAP_WC = 1 << 2,

You didn't update the documentation :(



From marc.zyngier at arm.com  Mon Feb  8 10:30:16 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 8 Feb 2016 18:30:16 +0000
Subject: [PATCH 3/5] irqchip/gic-v2: Parse and export virtual GIC
 information
In-Reply-To: <1454950049-741-4-git-send-email-julien.grall@arm.com>
References: <1454950049-741-1-git-send-email-julien.grall@arm.com>
 <1454950049-741-4-git-send-email-julien.grall@arm.com>
Message-ID: <56B8DEB8.4010509@arm.com>

Julien,

On 08/02/16 16:47, Julien Grall wrote:
> For now, the firmware tables are parsed 2 times: once in the GIC
> drivers, the other timer when initializing the vGIC. It means code
> duplication and make more tedious to add the support for another
> firmware table (like ACPI).
> 
> Introduce a new structure and set of helpers to get/set the virtual GIC
> information. Also fill up the structure for GICv2.
> 
> Signed-off-by: Julien Grall <julien.grall at arm.com>
> ---
> 
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: Marc Zyngier <marc.zyngier at arm.com>
> 
>  drivers/irqchip/irq-gic-common.c       | 13 ++++++
>  drivers/irqchip/irq-gic-common.h       |  3 ++
>  drivers/irqchip/irq-gic.c              | 78 +++++++++++++++++++++++++++++++++-
>  include/linux/irqchip/arm-gic-common.h | 34 +++++++++++++++
>  4 files changed, 127 insertions(+), 1 deletion(-)
>  create mode 100644 include/linux/irqchip/arm-gic-common.h
> 
> diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
> index f174ce0..704caf4 100644
> --- a/drivers/irqchip/irq-gic-common.c
> +++ b/drivers/irqchip/irq-gic-common.c
> @@ -21,6 +21,19 @@
>  
>  #include "irq-gic-common.h"
>  
> +static const struct gic_kvm_info *gic_kvm_info;
> +
> +const struct gic_kvm_info *gic_get_kvm_info(void)
> +{
> +	return gic_kvm_info;
> +}
> +
> +void gic_set_kvm_info(const struct gic_kvm_info *info)
> +{
> +	WARN(gic_kvm_info != NULL, "gic_kvm_info already set\n");
> +	gic_kvm_info = info;
> +}
> +
>  void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
>  		void *data)
>  {
> diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
> index fff697d..205e5fd 100644
> --- a/drivers/irqchip/irq-gic-common.h
> +++ b/drivers/irqchip/irq-gic-common.h
> @@ -19,6 +19,7 @@
>  
>  #include <linux/of.h>
>  #include <linux/irqdomain.h>
> +#include <linux/irqchip/arm-gic-common.h>
>  
>  struct gic_quirk {
>  	const char *desc;
> @@ -35,4 +36,6 @@ void gic_cpu_config(void __iomem *base, void (*sync_access)(void));
>  void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
>  		void *data);
>  
> +void gic_set_kvm_info(const struct gic_kvm_info *info);
> +
>  #endif /* _IRQ_GIC_COMMON_H */
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 911758c..d3a09a4 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -102,6 +102,8 @@ static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;
>  
>  static struct gic_chip_data gic_data[CONFIG_ARM_GIC_MAX_NR] __read_mostly;
>  
> +static struct gic_kvm_info gic_v2_kvm_info;
> +
>  #ifdef CONFIG_GIC_NON_BANKED
>  static void __iomem *gic_get_percpu_base(union gic_base *base)
>  {
> @@ -1190,6 +1192,44 @@ static bool gic_check_eoimode(struct device_node *node, void __iomem **base)
>  	return true;
>  }
>  
> +static void __init gic_of_setup_kvm_info(struct device_node *node)
> +{
> +	int ret;
> +	struct resource r;
> +	unsigned int irq;
> +
> +	gic_v2_kvm_info.type = GIC_V2;
> +
> +	irq = irq_of_parse_and_map(node, 0);
> +	if (!irq)
> +		gic_v2_kvm_info.maint_irq = -1;

Please don't do that. 0 *is* the value for an invalid interrupt, and
this is what you should expose here. Same for GICv3.

> +	else
> +		gic_v2_kvm_info.maint_irq = irq;
> +
> +	ret = of_address_to_resource(node, 2, &r);
> +	if (!ret) {
> +		gic_v2_kvm_info.vctrl_base = r.start;
> +		gic_v2_kvm_info.vctrl_size = resource_size(&r);
> +	}
> +
> +	ret = of_address_to_resource(node, 3, &r);
> +	if (!ret) {
> +		if (!PAGE_ALIGNED(r.start))
> +			pr_warn("GICV physical address 0x%llx not page aligned\n",
> +				(unsigned long long)r.start);
> +		else if (!PAGE_ALIGNED(resource_size(&r)))
> +			pr_warn("GICV size 0x%llx not a multiple of page size 0x%lx\n",
> +				(unsigned long long)resource_size(&r),
> +				PAGE_SIZE);
> +		else {
> +			gic_v2_kvm_info.vcpu_base = r.start;
> +			gic_v2_kvm_info.vcpu_size = resource_size(&r);

This tends to make me think that this should actually be a proper
resource, and not a set of arbitrary fields.

> +		}
> +	}
> +
> +	gic_set_kvm_info(&gic_v2_kvm_info);
> +}
> +
>  int __init
>  gic_of_init(struct device_node *node, struct device_node *parent)
>  {
> @@ -1219,8 +1259,10 @@ gic_of_init(struct device_node *node, struct device_node *parent)
>  
>  	__gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset,
>  			 &node->fwnode);
> -	if (!gic_cnt)
> +	if (!gic_cnt) {
>  		gic_init_physaddr(node);
> +		gic_of_setup_kvm_info(node);
> +	}
>  
>  	if (parent) {
>  		irq = irq_of_parse_and_map(node, 0);
> @@ -1247,6 +1289,32 @@ IRQCHIP_DECLARE(pl390, "arm,pl390", gic_of_init);
>  
>  #ifdef CONFIG_ACPI
>  static phys_addr_t cpu_phy_base __initdata;
> +static struct
> +{
> +	u32 maint_irq;
> +	int maint_irq_mode;
> +	phys_addr_t vctrl_base;
> +	phys_addr_t vcpu_base;
> +} acpi_data __initdata;
> +
> +static void __init gic_acpi_setup_kvm_info(void)
> +{
> +	gic_v2_kvm_info.type = GIC_V2;
> +
> +	gic_v2_kvm_info.maint_irq = acpi_register_gsi(NULL,
> +						      acpi_data.maint_irq,
> +						      acpi_data.maint_irq_mode,
> +						      ACPI_ACTIVE_HIGH);
> +	gic_v2_kvm_info.vctrl_base = acpi_data.vctrl_base;
> +	if (gic_v2_kvm_info.vctrl_base)
> +		gic_v2_kvm_info.vctrl_size = SZ_8K;
> +
> +	gic_v2_kvm_info.vcpu_base = acpi_data.vcpu_base;
> +	if (gic_v2_kvm_info.vcpu_base)
> +		gic_v2_kvm_info.vcpu_size = SZ_8K;
> +
> +	gic_set_kvm_info(&gic_v2_kvm_info);
> +}
>  
>  static int __init
>  gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
> @@ -1270,6 +1338,12 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
>  		return -EINVAL;
>  
>  	cpu_phy_base = gic_cpu_base;
> +	acpi_data.maint_irq = processor->vgic_interrupt;
> +	acpi_data.maint_irq_mode = (processor->flags & ACPI_MADT_VGIC_IRQ_MODE) ?
> +				    ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
> +	acpi_data.vctrl_base = processor->gich_base_address;
> +	acpi_data.vcpu_base = processor->gicv_base_address;
> +

Maybe you can now move all the ACPI data into this acpi_data structure?
This would allow for slightly less clutter...

>  	cpu_base_assigned = 1;
>  	return 0;
>  }
> @@ -1357,6 +1431,8 @@ static int __init gic_v2_acpi_init(struct acpi_subtable_header *header,
>  	if (IS_ENABLED(CONFIG_ARM_GIC_V2M))
>  		gicv2m_init(NULL, gic_data[0].domain);
>  
> +	gic_acpi_setup_kvm_info();
> +
>  	return 0;
>  }
>  IRQCHIP_ACPI_DECLARE(gic_v2, ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR,
> diff --git a/include/linux/irqchip/arm-gic-common.h b/include/linux/irqchip/arm-gic-common.h
> new file mode 100644
> index 0000000..30972b1
> --- /dev/null
> +++ b/include/linux/irqchip/arm-gic-common.h
> @@ -0,0 +1,34 @@
> +/*
> + * include/linux/irqchip/arm-gic-common.h
> + *
> + * Copyright (C) 2016 ARM Limited, All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef __LINUX_IRQCHIP_ARM_GIC_COMMON_H
> +#define __LINUX_IRQCHIP_ARM_GIC_COMMON_H
> +
> +#include <linux/types.h>
> +
> +enum gic_type {
> +	GIC_V2,
> +};
> +
> +struct gic_kvm_info {
> +	/* GIC type */
> +	enum gic_type	type;
> +	/* Physical address & size of virtual cpu interface */
> +	phys_addr_t	vcpu_base;
> +	resource_size_t	vcpu_size;
> +	/* Interrupt number */
> +	int		maint_irq;
> +	/* Physical address & size of virtual control interface */
> +	phys_addr_t	vctrl_base;
> +	resource_size_t	vctrl_size;
> +};
> +
> +const struct gic_kvm_info *gic_get_kvm_info(void);
> +
> +#endif /* __LINUX_IRQCHIP_ARM_GIC_COMMON_H */
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From thomas at schloeter.net  Mon Feb  8 10:49:27 2016
From: thomas at schloeter.net (=?utf-8?Q?Thomas_Schl=C3=B6ter?=)
Date: Mon, 8 Feb 2016 19:49:27 +0100
Subject: net: mv643xx: interface does not transmit after some time
In-Reply-To: <A21B89D4-5826-4F97-A1C9-E62E5B724082@schloeter.net>
References: <E4F9E0D0-9DA8-4E33-9F89-B49E47F11CE0@schloeter.net>
 <20160206183414.GD17218@lunn.ch> <20160206231935.GA30734@jirafa.cyrius.com>
 <2ACB3A0B-DD51-43C1-A56E-E7C175645554@schloeter.net>
 <20160207203545.GB29107@lunn.ch>
 <A21B89D4-5826-4F97-A1C9-E62E5B724082@schloeter.net>
Message-ID: <312E318A-CAE1-45B1-AB13-EA147B48E315@schloeter.net>


> Am 07.02.2016 um 22:07 schrieb Thomas Schl?ter <thomas at schloeter.net>:
> 
> Am 07.02.2016 um 21:35 schrieb Andrew Lunn <andrew at lunn.ch>:
>> 
>>>> FWIW, we had a similar bug report in Debian recently:
>>>> https://lists.debian.org/debian-arm/2016/01/msg00098.html
>> 
>> Hi Thomas
>> 
>> I this thread, Ian Campbell mentions a patch. Please could you try
>> that patch and see if it fixes your problem.
>> 
>> Thanks
>> 	Andrew
> 
> Hi Andrew,
> 
> I just applied the patch and the NAS is now running it. I?ll try to crash it tonight and keep you informed whether it worked.
> 
> Thanks
> 	Thomas

Hi Andrew,

the patch did not fix the problem. After 1.2 GiB RX and 950 MiB TX, the interface crashed again.

Now I switched off RX/TX offload just to make sure we are talking about the same problem. If we are, the interface should be stable without offload, right?

	Thomas

From robh at kernel.org  Mon Feb  8 10:54:09 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 12:54:09 -0600
Subject: [PATCH v4 1/8] dt-bindings: Add a binding for Mediatek Video
 Processor
In-Reply-To: <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <20160208185409.GA14017@rob-hp-laptop>

On Thu, Feb 04, 2016 at 07:34:56PM +0800, Tiffany Lin wrote:
> From: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
> 
> Add a DT binding documentation of Video Processor Unit for the
> MT8173 SoC from Mediatek.
> 
> 
> Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
> Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
> ---
>  .../devicetree/bindings/media/mediatek-vpu.txt     |   31 ++++++++++++++++++++
>  1 file changed, 31 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt

Acked-by: Rob Herring <robh at kernel.org>



From maxime.ripard at free-electrons.com  Mon Feb  8 09:20:31 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Mon, 8 Feb 2016 18:20:31 +0100
Subject: [PATCH] pinctrl: sunxi: set pin function as input on export
In-Reply-To: <1454942242-25690-1-git-send-email-krzysztof.adamski@tieto.com>
References: <1454942242-25690-1-git-send-email-krzysztof.adamski@tieto.com>
Message-ID: <20160208172031.GJ31506@lukather>

Hi,

On Mon, Feb 08, 2016 at 03:37:22PM +0100, Krzysztof Adamski wrote:
> Default function of a pin in sunxi SoCs is "disabled". By default gpios
> exported by sysfs are set as input and indeed, when reading "direction"
> file you will get "in". The "value" pin won't return proper value,
> though, confusing user of this interface.
> 
> This patch sets direction of a GPIO as input when exporting it.
> 
> Signed-off-by: Krzysztof Adamski <krzysztof.adamski at tieto.com>
> ---
>  drivers/pinctrl/sunxi/pinctrl-sunxi.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> index 7a2465f..905a9fb 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -452,6 +452,16 @@ static int sunxi_pinctrl_gpio_direction_input(struct gpio_chip *chip,
>  	return pinctrl_gpio_direction_input(chip->base + offset);
>  }
>  
> +int sunxi_pinctrl_gpio_request(struct gpio_chip *chip, unsigned offset)
> +{
> +	int ret = pinctrl_gpio_direction_input(chip->base + offset);
> +
> +	if (ret)
> +		return ret;
> +
> +	return pinctrl_request_gpio(chip->base + offset);
> +}
> +
>  static int sunxi_pinctrl_gpio_get(struct gpio_chip *chip, unsigned offset)
>  {
>  	struct sunxi_pinctrl *pctl = gpiochip_get_data(chip);
> @@ -946,7 +956,7 @@ int sunxi_pinctrl_init(struct platform_device *pdev,
>  
>  	last_pin = pctl->desc->pins[pctl->desc->npins - 1].pin.number;
>  	pctl->chip->owner = THIS_MODULE;
> -	pctl->chip->request = gpiochip_generic_request,
> +	pctl->chip->request = sunxi_pinctrl_gpio_request,
>  	pctl->chip->free = gpiochip_generic_free,
>  	pctl->chip->direction_input = sunxi_pinctrl_gpio_direction_input,
>  	pctl->chip->direction_output = sunxi_pinctrl_gpio_direction_output,
> -- 
> 2.4.2
> 

It seems to me that it's something that should be enforced in the
core, there's nothing sunxi specific here.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160208/5916f902/attachment.sig>

From robh at kernel.org  Mon Feb  8 10:56:14 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 12:56:14 -0600
Subject: [PATCH v4 4/8] dt-bindings: Add a binding for Mediatek Video
 Encoder
In-Reply-To: <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <20160208185614.GA15128@rob-hp-laptop>

On Thu, Feb 04, 2016 at 07:34:59PM +0800, Tiffany Lin wrote:
> Add a DT binding documentation of Video Encoder for the
> MT8173 SoC from Mediatek.
> 
> Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
> ---
>  .../devicetree/bindings/media/mediatek-vcodec.txt  |   59 ++++++++++++++++++++
>  1 file changed, 59 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt

Acked-by: Rob Herring <robh at kernel.org>



From dinguyen at opensource.altera.com  Mon Feb  8 11:00:44 2016
From: dinguyen at opensource.altera.com (Dinh Nguyen)
Date: Mon, 8 Feb 2016 13:00:44 -0600
Subject: [PATCHv9 3/4] ARM: socfpga: enable L2 cache ECC on startup
In-Reply-To: <1453911203-30202-3-git-send-email-tthayer@opensource.altera.com>
References: <1453911203-30202-1-git-send-email-tthayer@opensource.altera.com>
 <1453911203-30202-3-git-send-email-tthayer@opensource.altera.com>
Message-ID: <56B8E5DC.5090600@opensource.altera.com>



On 01/27/2016 10:13 AM, tthayer at opensource.altera.com wrote:
> From: Thor Thayer <tthayer at opensource.altera.com>
> 
> This patch enables the ECC for L2 cache on machine startup. The ECC has to
> be enabled before data is stored in memory otherwise the ECC will fail on
> reads.
> 
> Signed-off-by: Thor Thayer <tthayer at opensource.altera.com>
> ---
> v9: Improve node put handling.
> v8: Address community suggestions for strings. Fix string based on
>     maintainer feedback. Update year in header.
> v7: unmap locally scoped mapped_l2_edac_addr and add of_node_put(np)
> v6: Remove pr_debug() & update year in header.
> ---
>  arch/arm/mach-socfpga/Makefile   |    1 +
>  arch/arm/mach-socfpga/core.h     |    1 +
>  arch/arm/mach-socfpga/l2_cache.c |   41 ++++++++++++++++++++++++++++++++++++++
>  arch/arm/mach-socfpga/socfpga.c  |    2 ++
>  4 files changed, 45 insertions(+)
>  create mode 100644 arch/arm/mach-socfpga/l2_cache.c
> 

Acked-by: Dinh Nguyen <dinguyen at opensource.altera.com>




From dinguyen at opensource.altera.com  Mon Feb  8 11:02:09 2016
From: dinguyen at opensource.altera.com (Dinh Nguyen)
Date: Mon, 8 Feb 2016 13:02:09 -0600
Subject: [PATCHv9 4/4] ARM: socfpga: Enable OCRAM ECC on startup
In-Reply-To: <1453911203-30202-4-git-send-email-tthayer@opensource.altera.com>
References: <1453911203-30202-1-git-send-email-tthayer@opensource.altera.com>
 <1453911203-30202-4-git-send-email-tthayer@opensource.altera.com>
Message-ID: <56B8E631.8040209@opensource.altera.com>



On 01/27/2016 10:13 AM, tthayer at opensource.altera.com wrote:
> From: Thor Thayer <tthayer at opensource.altera.com>
> 
> This patch enables the ECC for On-Chip RAM on machine startup. The ECC
> has to be enabled before data is stored in memory otherwise the ECC will
> fail on reads.
> 
> Signed-off-by: Thor Thayer <tthayer at opensource.altera.com>
> ---
> v9: Improve node release handling.
> v8: Address community comments on strings. Fix match strings based
>     on maintainer feedback. Update year in header.
> v7: enable OCRAM ECC during platform init
> v6: Implement OCRAM discovery changes from community. Add
>     of_node_put(). Remove be32_to_cpup(). Use __init() which
>     allows removal of .init_machine(). Update year in header.
> ---
>  arch/arm/mach-socfpga/Makefile  |    1 +
>  arch/arm/mach-socfpga/core.h    |    1 +
>  arch/arm/mach-socfpga/ocram.c   |   49 +++++++++++++++++++++++++++++++++++++++
>  arch/arm/mach-socfpga/socfpga.c |    3 +++
>  4 files changed, 54 insertions(+)
>  create mode 100644 arch/arm/mach-socfpga/ocram.c
> 

Acked-by: Dinh Nguyen <dinguyen at opensource.altera.com>


From m-karicheri2 at ti.com  Mon Feb  8 11:03:07 2016
From: m-karicheri2 at ti.com (Murali Karicheri)
Date: Mon, 8 Feb 2016 14:03:07 -0500
Subject: [PATCH 4/5] drivers/pci: make host/pci-keystone-dw.c modular
In-Reply-To: <20160208155324.GU23093@windriver.com>
References: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
 <1454889644-27830-5-git-send-email-paul.gortmaker@windriver.com>
 <91848876.ZYig6qgHLq@wuerfel> <20160208155324.GU23093@windriver.com>
Message-ID: <56B8E66B.3060309@ti.com>

On 02/08/2016 10:53 AM, Paul Gortmaker wrote:
> [Re: [PATCH 4/5] drivers/pci: make host/pci-keystone-dw.c modular] On 08/02/2016 (Mon 10:59) Arnd Bergmann wrote:
> 
>> On Sunday 07 February 2016 19:00:43 Paul Gortmaker wrote:
>>> Export the symbols that this driver requires in order for it to
>>> be modular.  In addition to the one use case of a dw_pci sym, it
>>> has many instances of its own ks_dw_pci syms that need exporting
>>> in order to modpost w/o error.
>>>
>>> Cc: Murali Karicheri <m-karicheri2 at ti.com>
>>> Cc: Bjorn Helgaas <bhelgaas at google.com>
>>> Cc: Stanimir Varbanov <svarbanov at mm-sol.com>
>>> Cc: Geert Uytterhoeven <geert+renesas at glider.be>
>>> Cc: Thierry Reding <thierry.reding at gmail.com>
>>> Cc: Arnd Bergmann <arnd at arndb.de>
>>> Cc: linux-pci at vger.kernel.org
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
>>> ---
>>
>>
>> Could we just have one module for the driver  instead of two?

I agree. Please note that Keystone PCI is tested only as static. 
I can help test the module if this series get to the next revision,
but it might be a while before I can do the test.

Murali

> 
> That thought crossed my mind, but I was considering merging the C files
> and figured it might be more churn than the maintainer wanted.  If
> maintainers are good with the below (assuming it works) then yes that
> also seems reasonable.
> 
> P.
> --
> 
>>
>> Something like below (untested)
>>
>> 	Arnd
>>
>> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>> index 7b2f20c6ccc6..0b472c680348 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -8,7 +8,8 @@ obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
>>  obj-$(CONFIG_PCI_RCAR_GEN2_PCIE) += pcie-rcar.o
>>  obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
>>  obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
>> -obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
>> +obj-$(CONFIG_PCI_KEYSTONE) pci-keystone-mod.o
>> +pci-keystone-mod-objs := pci-keystone-dw.o pci-keystone.o
>>  obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
>>  obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
>>  obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
>>
> 


-- 
Murali Karicheri
Linux Kernel, Keystone


From jbaron at akamai.com  Mon Feb  8 11:09:13 2016
From: jbaron at akamai.com (Jason Baron)
Date: Mon, 8 Feb 2016 14:09:13 -0500
Subject: [PATCH] locking/static_keys: avoid nested functions
In-Reply-To: <1454942223-2781480-1-git-send-email-arnd@arndb.de>
References: <1454942223-2781480-1-git-send-email-arnd@arndb.de>
Message-ID: <56B8E7D9.1080301@akamai.com>

On 02/08/2016 09:36 AM, Arnd Bergmann wrote:
> clang does not support nested functions inside of an array definition:
> 
> lib/test_static_keys.c:105:16: error: function definition is not allowed here
>                         .test_key       = test_key_func(&old_true_key, static_key_true),
> lib/test_static_keys.c:50:20: note: expanded from macro 'test_key_func'
>         ({bool func(void) { return branch(key); } func; })
> 
> That code appears to have been a little too clever, so this
> simplifies it a bit by defining functions outside of the array.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  lib/test_static_keys.c | 62 ++++++++++++++++++++++++++++++++++----------------
>  1 file changed, 42 insertions(+), 20 deletions(-)
> 

Works for me.

Acked-by: Jason Baron <jbaron at akamai.com>

Thanks,

-Jason


From robh at kernel.org  Mon Feb  8 11:24:28 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 13:24:28 -0600
Subject: [PATCH v6 2/7] dt-bindings: ARM: Mediatek: Document bindings for
 MT2701
In-Reply-To: <1454665050-37776-3-git-send-email-jamesjj.liao@mediatek.com>
References: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
 <1454665050-37776-3-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <20160208192428.GA26367@rob-hp-laptop>

On Fri, Feb 05, 2016 at 05:37:25PM +0800, James Liao wrote:
> This patch adds the binding documentation for apmixedsys, bdpsys,
> ethsys, hifsys, imgsys, infracfg, mmsys, pericfg, topckgen and
> vdecsys for Mediatek MT2701.
> 
> Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
> Tested-by: John Crispin <blogic at openwrt.org>
> ---
>  .../bindings/arm/mediatek/mediatek,apmixedsys.txt  |  3 ++-
>  .../bindings/arm/mediatek/mediatek,bdpsys.txt      | 22 ++++++++++++++++++++
>  .../bindings/arm/mediatek/mediatek,ethsys.txt      | 22 ++++++++++++++++++++
>  .../bindings/arm/mediatek/mediatek,hifsys.txt      | 24 ++++++++++++++++++++++
>  .../bindings/arm/mediatek/mediatek,imgsys.txt      |  3 ++-
>  .../bindings/arm/mediatek/mediatek,infracfg.txt    |  3 ++-
>  .../bindings/arm/mediatek/mediatek,mmsys.txt       |  3 ++-
>  .../bindings/arm/mediatek/mediatek,pericfg.txt     |  3 ++-
>  .../bindings/arm/mediatek/mediatek,topckgen.txt    |  3 ++-
>  .../bindings/arm/mediatek/mediatek,vdecsys.txt     |  3 ++-
>  10 files changed, 82 insertions(+), 7 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,bdpsys.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,hifsys.txt

Acked-by: Rob Herring <robh at kernel.org>



From tony at atomide.com  Mon Feb  8 11:36:45 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Feb 2016 11:36:45 -0800
Subject: [PATCH] ARM: OMAP2+: Fix onenand initialization to avoid
 filesystem corruption
In-Reply-To: <1454683028-4193-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
References: <linux-kernel@vger.kernel.org>
 <1454683028-4193-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
Message-ID: <20160208193644.GU19432@atomide.com>

* Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com> [160205 06:38]:
> Commit <e7b11dc7b77bfce0a351230a5feeadc1d0bba997> ("ARM: OMAP2+: Fix
> onenand rate detection to avoid filesystem corruption") partially fixed
> onenand configuration when GPMC module is reset. Finish the job by also
> providing the correct values in ONENAND_REG_SYS_CFG1 register.

OK. So probably the INT or RDY polarity made the ECC not work.

Aaro, care to dump out also the nolo configured CFG1 value from
n8x0 and n9(50)?

You can do it by adding something like this to the beginning
of set_onenand_cfg():

pr_info("CFG1: 0x%04x\n", readw(onenand_base + ONENAND_REG_SYS_CFG1));

And presumably the values are the same as on n900. If not, we
should do the legacy file system flash test on all of them
before committing this fix.

Regards,

Tony

> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com>
> ---
>  arch/arm/mach-omap2/gpmc-onenand.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
> index 7b76ce0..8633c70 100644
> --- a/arch/arm/mach-omap2/gpmc-onenand.c
> +++ b/arch/arm/mach-omap2/gpmc-onenand.c
> @@ -101,10 +101,8 @@ static void omap2_onenand_set_async_mode(void __iomem *onenand_base)
>  
>  static void set_onenand_cfg(void __iomem *onenand_base)
>  {
> -	u32 reg;
> +	u32 reg = ONENAND_SYS_CFG1_RDY | ONENAND_SYS_CFG1_INT;
>  
> -	reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
> -	reg &= ~((0x7 << ONENAND_SYS_CFG1_BRL_SHIFT) | (0x7 << 9));
>  	reg |=	(latency << ONENAND_SYS_CFG1_BRL_SHIFT) |
>  		ONENAND_SYS_CFG1_BL_16;
>  	if (onenand_flags & ONENAND_FLAG_SYNCREAD)
> @@ -123,6 +121,7 @@ static void set_onenand_cfg(void __iomem *onenand_base)
>  		reg |= ONENAND_SYS_CFG1_VHF;
>  	else
>  		reg &= ~ONENAND_SYS_CFG1_VHF;
> +
>  	writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
>  }
>  
> @@ -289,6 +288,7 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base)
>  		}
>  	}
>  
> +	onenand_async.sync_write = true;
>  	omap2_onenand_calc_async_timings(&t);
>  
>  	ret = gpmc_cs_program_settings(gpmc_onenand_data->cs, &onenand_async);
> -- 
> 1.9.1
> 


From robh at kernel.org  Mon Feb  8 11:37:06 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 13:37:06 -0600
Subject: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager
In-Reply-To: <1454690044-2560-2-git-send-email-nm@ti.com>
References: <1454690044-2560-1-git-send-email-nm@ti.com>
 <1454690044-2560-2-git-send-email-nm@ti.com>
Message-ID: <20160208193706.GA333@rob-hp-laptop>

On Fri, Feb 05, 2016 at 10:34:03AM -0600, Nishanth Menon wrote:
> Message Manager is a hardware block used to communicate with various
> processor systems within certain Texas Instrument's Keystone
> generation SoCs.
> 
> This hardware engine is used to transfer messages from various compute
> entities(or processors) within the SoC. It is designed to be self
> contained without needing software initialization for operation.
> 
> Signed-off-by: Nishanth Menon <nm at ti.com>
> ---
>  .../bindings/mailbox/ti,message-manager.txt        | 72 ++++++++++++++++++++++
>  1 file changed, 72 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> 
> diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> new file mode 100644
> index 000000000000..f3d73b0b3c66
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
> @@ -0,0 +1,72 @@
> +Texas Instruments' Message Manager Driver
> +========================================
> +
> +The Texas Instruments' Message Manager is a mailbox controller that has
> +configurable queues selectable at SoC(System on Chip) integration. The Message
> +manager is broken up into queues in different address regions that are called
> +"proxies" - each instance is unidirectional and is instantiated at SoC
> +integration level to indicate receive or transmit path.
> +
> +Message Manager Device Node:
> +===========================
> +
> +Required properties:
> +--------------------
> +- compatible:		Shall be:
> +				"ti,k2g-message-manager"
> +				"ti,message-manager"

Given that queues are configurable at integration time, does a generic 
property really make sense here?

> +- reg-names 		queue_proxy_region - Map the queue Proxy region
> +			queue_state_debug_region - Map the queue state debug
> +			region.
> +- reg:			Contains the register map per reg-names
> +- #mbox-cells		Shall be 1

And the value contained is what?

> +
> +Child Nodes:
> +============
> +A child node is used for representing the actual queue device that is
> +used for the communication between the host processor and a remote processor.
> +Each child node should have a unique node name across all the different
> +message manager device nodes.
> +
> +Required Properties:
> +--------------------
> +- ti,queue-id:		Indicates the queue number this node represents
> +- ti,proxy-id:		Proxy ID representing the processor in the SoC.

What determines these values?

> +
> +Optional Properties:
> +--------------------
> +- interrupt-names:	'rx' - indicates a receive interrupt (mandatory ONLY if
> +			this is a receive queue)

Kind of pointless if there is only 1.

> +- interrupts:		Contains the interrupt information corresponding to
> +			interrupt-names property.
> +
> +Example:
> +--------
> +
> +	msgmgr: msgmgr at 02a00000 {
> +		compatible = "ti,k2g-message-manager", "ti,message-manager";
> +		#mbox-cells = <1>;
> +		reg-names = "queue_proxy_region", "queue_state_debug_region";
> +		reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
> +
> +		msgmgr_proxy_pmmc_tx_prio0: pmmc_tx_prio0 {
> +			ti,queue-id = <0>;
> +			ti,proxy-id = <0>;
> +		};
> +
> +		msgmgr_proxy_pmmc_rx: pmmc_rx {
> +			ti,queue-id = <5>;
> +			ti,proxy-id = <2>;
> +			interrupt-names = "rx";
> +			interrupts = <GIC_SPI 324 IRQ_TYPE_EDGE_RISING>;
> +		};
> +	};
> +
> +...
> +	pmmc {
> +		...
> +		mbox-names = "tx", "rx";
> +		mboxes = <&msgmgr &msgmgr_proxy_pmmc_tx>
> +			 <&msgmgr &msgmgr_proxy_pmmc_rx>;

While I guess this is valid DT, it is a bit strange having the cell 
values be phandles. Why not just make the queue and proxy ids be the 
cell values? The interrupts could be moved to the parent and the child 
nodes eliminated altogether.

The alternative would be just drop msgmgr phandle and point to the child 
nodes. I prefer getting rid of the child nodes though.

Rob


From robh at kernel.org  Mon Feb  8 11:50:28 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 13:50:28 -0600
Subject: [PATCH v2 2/4] regulator: lp872x: Add enable GPIO pin support
In-Reply-To: <1454697741-8687-3-git-send-email-contact@paulk.fr>
References: <1454697741-8687-1-git-send-email-contact@paulk.fr>
 <1454697741-8687-3-git-send-email-contact@paulk.fr>
Message-ID: <20160208195028.GA13120@rob-hp-laptop>

On Fri, Feb 05, 2016 at 07:42:19PM +0100, Paul Kocialkowski wrote:
> LP872x regulators are made active via the EN pin, which might be hooked to a
> GPIO. This adds support for driving the GPIO high when the driver is in use.
> 
> Signed-off-by: Paul Kocialkowski <contact at paulk.fr>
> ---
>  .../devicetree/bindings/regulator/lp872x.txt       |  1 +

Acked-by: Rob Herring <robh at kernel.org>

>  drivers/regulator/lp872x.c                         | 34 ++++++++++++++++++++++
>  include/linux/regulator/lp872x.h                   |  5 ++++
>  3 files changed, 40 insertions(+)


From robh at kernel.org  Mon Feb  8 11:56:42 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 13:56:42 -0600
Subject: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for
 ThunderX-pass1 on-chip devices
In-Reply-To: <1454715675-17512-4-git-send-email-ddaney.cavm@gmail.com>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
 <1454715675-17512-4-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <20160208195642.GA15103@rob-hp-laptop>

On Fri, Feb 05, 2016 at 03:41:15PM -0800, David Daney wrote:
> From: David Daney <david.daney at cavium.com>
> 
> The cavium,pci-thunder-ecam devices are exactly ECAM based PCI root
> complexes.  These root complexes (loosely referred to as ECAM units in
> the hardware manuals) are used to access the Thunder on-chips devices.
> They are special in that all the BARs on devices behind these root
> complexes are at fixed addresses.  To handle this in a manner
> compatible with the core PCI code, we have the config access functions
> synthesize Enhanced Allocation (EA) capability entries for each BAR.
> 
> Since this EA synthesis is needed for exactly one chip model, we can
> hard code some assumptions about the device topology and the
> properties of specific DEVFNs in the driver.
> 
> Signed-off-by: David Daney <david.daney at cavium.com>
> ---
>  .../devicetree/bindings/pci/pci-thunder-ecam.txt   |  30 ++
>  drivers/pci/host/Kconfig                           |   7 +
>  drivers/pci/host/Makefile                          |   1 +
>  drivers/pci/host/pci-thunder-ecam.c                | 358 +++++++++++++++++++++
>  4 files changed, 396 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt
>  create mode 100644 drivers/pci/host/pci-thunder-ecam.c
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt b/Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt
> new file mode 100644
> index 0000000..34658f2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt
> @@ -0,0 +1,30 @@
> +* ThunderX PCI host controller for pass-1.x silicon
> +
> +Firmware-initialized PCI host controller to on-chip devices found on
> +some Cavium ThunderX processors.  These devices have ECAM based config
> +access, but the BARs are all at fixed addresses.  We handle the fixed
> +addresses by synthesizing Enhanced Allocation (EA) capabilities for
> +these devices.
> +
> +The properties and their meanings are identical to those described in
> +host-generic-pci.txt except as listed below.
> +
> +Properties of the host controller node that differ from
> +host-generic-pci.txt:
> +
> +- compatible     : Must be "cavium,pci-host-thunder-ecam"
> +
> +Example:
> +
> +	pci at 84b0,00000000 {

Drop the comma, and the node name should be "pcie".

Otherwise,

Acked-by: Rob Herring <robh at kernel.org>

> +		compatible = "cavium,pci-host-thunder-ecam";
> +		device_type = "pci";
> +		msi-parent = <&its>;
> +		msi-map = <0 &its 0x30000 0x10000>;
> +		bus-range = <0 31>;
> +		#size-cells = <2>;
> +		#address-cells = <3>;
> +		#stream-id-cells = <1>;
> +		reg = <0x84b0 0x00000000 0 0x02000000>;  /* Configuration space */
> +		ranges = <0x03000000 0x8180 0x00000000 0x8180 0x00000000 0x80 0x00000000>; /* mem ranges */
> +	};


From tony at atomide.com  Mon Feb  8 11:57:04 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Feb 2016 11:57:04 -0800
Subject: [PATCH 0/3] arm: dts: DRA7: Add IVA and DSPEVE thermal domain data
In-Reply-To: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>
References: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>
Message-ID: <20160208195704.GW19432@atomide.com>

* Keerthy <j-keerthy at ti.com> [160208 01:19]:
> OMAP5 has 3 thermal zones cpu, core and multimedia.
> On the other hand DRA7 has 5 thermal zones cpu, gpu, core, dspeve
> and iva. Currently cpu, core and multimedia are being added via dt
> and the other 2 are getting added via kernel. Add the missing thermal
> domains in dt so as give the correct trip numbers, type and temperatures.
> 
> Tested on DRA7-EVM.

Are these critical fixes to have for v4.5-rc cycle or can they
wait for v4.6 merge window?

Regards,

Tony

> Keerthy (3):
>   arm: dts: DRA7: Add DSPEVE thermal data
>   arm: dts: DRA7: Add IVA thermal data
>   arm: dts: DRA7: Add missing IVA and DSPEVE thermal domain data
> 
>  arch/arm/boot/dts/dra7-dspeve-thermal.dtsi | 27 +++++++++++++++++++++++++++
>  arch/arm/boot/dts/dra7-iva-thermal.dtsi    | 27 +++++++++++++++++++++++++++
>  arch/arm/boot/dts/dra7.dtsi                |  2 ++
>  3 files changed, 56 insertions(+)
>  create mode 100644 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi
>  create mode 100644 arch/arm/boot/dts/dra7-iva-thermal.dtsi
> 
> -- 
> 1.9.1
> 


From akpm at linux-foundation.org  Mon Feb  8 12:03:17 2016
From: akpm at linux-foundation.org (Andrew Morton)
Date: Mon, 8 Feb 2016 12:03:17 -0800
Subject: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag
In-Reply-To: <9085d37fa97a762a46b9d58719c085368682c64f.1454950917.git.brian.starkey@arm.com>
References: <cover.1454950917.git.brian.starkey@arm.com>
 <9085d37fa97a762a46b9d58719c085368682c64f.1454950917.git.brian.starkey@arm.com>
Message-ID: <20160208120317.313409dc0ae7634c25d3f021@linux-foundation.org>

On Mon,  8 Feb 2016 17:30:50 +0000 Brian Starkey <brian.starkey at arm.com> wrote:

> Add a flag to memremap() for writecombine mappings. Mappings satisfied
> by this flag will not be cached, however writes may be delayed or
> combined into more efficient bursts. This is most suitable for
> buffers written sequentially by the CPU for use by other DMA devices.
> 
> ...

The patch generally looks OK to me.  It generates rejects against
linux-next because of some janitorial changes in memremap.c.


> @@ -101,6 +107,11 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
>  		addr = ioremap_wt(offset, size);
>  	}
>  
> +	if (!addr && (flags & MEMREMAP_WC)) {
> +		flags &= ~MEMREMAP_WC;
> +		addr = ioremap_wc(offset, size);
> +	}
> +
>  	return addr;
>  }

The modifications of `flags' is unneeded (and the compiler will remove
it).  And generally the modification of incoming args is a bit nasty
IMO - I find it's better to treat them as const - part of the calling
environment which can be relied upon to be unaltered as the code
evolves.



From tony at atomide.com  Mon Feb  8 12:03:24 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Feb 2016 12:03:24 -0800
Subject: [PATCH] ARM: drop unused Makefile.boot of Multiplatform SoCs
In-Reply-To: <56B4E2B0.8060808@xilinx.com>
References: <1454693808-13081-1-git-send-email-yamada.masahiro@socionext.com>
 <56B4E2B0.8060808@xilinx.com>
Message-ID: <20160208200324.GY19432@atomide.com>

* Michal Simek <michal.simek at xilinx.com> [160205 09:59]:
> On 5.2.2016 18:36, Masahiro Yamada wrote:
> > The variable "MACHINE" is empty if CONFIG_ARCH_MULTIPLATFORM=y,
> > so these Makefile.boot files are never included.
> > 
> > Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
> > ---
> > 
> >  arch/arm/mach-cns3xxx/Makefile.boot    | 3 ---
> >  arch/arm/mach-exynos/Makefile.boot     | 2 --
> >  arch/arm/mach-integrator/Makefile.boot | 4 ----
> >  arch/arm/mach-keystone/Makefile.boot   | 1 -
> >  arch/arm/mach-mmp/Makefile.boot        | 1 -
> >  arch/arm/mach-mv78xx0/Makefile.boot    | 3 ---
> >  arch/arm/mach-nspire/Makefile.boot     | 0
> >  arch/arm/mach-omap2/Makefile.boot      | 3 ---
> >  arch/arm/mach-orion5x/Makefile.boot    | 3 ---
> >  arch/arm/mach-prima2/Makefile.boot     | 3 ---
> >  arch/arm/mach-realview/Makefile.boot   | 9 ---------
> >  arch/arm/mach-s3c64xx/Makefile.boot    | 2 --
> >  arch/arm/mach-spear/Makefile.boot      | 3 ---
> >  arch/arm/mach-u300/Makefile.boot       | 4 ----
> >  arch/arm/mach-ux500/Makefile.boot      | 3 ---
> >  arch/arm/mach-zynq/Makefile.boot       | 3 ---
> 
> Acked-by: Michal Simek <michal.simek at xilinx.com> (for Zynq)

I doubt anybody wants to go back to disabling MULTIPLATFORM:

Acked-by: Tony Lindgren <tony at atomide.com>


From festevam at gmail.com  Mon Feb  8 12:07:53 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Mon,  8 Feb 2016 18:07:53 -0200
Subject: [PATCH] ARM: imx_v6_v7_defconfig: Select CONFIG_CRYPTO_DEV_SAHARA
Message-ID: <1454962073-22401-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at nxp.com>

Select the sahara crypto driver that is used on i.MX53.

Signed-off-by: Fabio Estevam <fabio.estevam at nxp.com>
---
 arch/arm/configs/imx_v6_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 25a6066..d218c27 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -367,6 +367,7 @@ CONFIG_PROVE_LOCKING=y
 # CONFIG_ARM_UNWIND is not set
 CONFIG_SECURITYFS=y
 CONFIG_CRYPTO_DEV_FSL_CAAM=y
+CONFIG_CRYPTO_DEV_SAHARA=y
 CONFIG_CRC_CCITT=m
 CONFIG_CRC_T10DIF=y
 CONFIG_CRC7=m
-- 
1.9.1



From robh at kernel.org  Mon Feb  8 12:12:46 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 14:12:46 -0600
Subject: [PATCH v4 01/11] drm/hisilicon: Add device tree binding for
 hi6220 display subsystem
In-Reply-To: <1454729098-79807-2-git-send-email-xinliang.liu@linaro.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
 <1454729098-79807-2-git-send-email-xinliang.liu@linaro.org>
Message-ID: <20160208201246.GA17459@rob-hp-laptop>

On Sat, Feb 06, 2016 at 11:24:48AM +0800, Xinliang Liu wrote:
> Add ADE display controller binding doc.
> Add DesignWare DSI Host Controller v1.20a binding doc.

One comment, otherwise:

Acked-by: Rob Herring <robh at kernel.org>

> +Board specific:
> +	&dsi {
> +		status = "ok";
> +
> +		ports {
> +			/* 1 for output port */
> +			port at 1 {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				reg = <1>;
> +
> +				/* 0 for bridge, other value for panel */

The endpoint address would not change based on bridge or panel. So you 
can drop the unit address here.

> +				dsi_out0: endpoint at 0 {
> +					reg = <0>;
> +					remote-endpoint = <&adv7533_in>;
> +				};
> +			};
> +		};
> +	};


From ivo.g.dimitrov.75 at gmail.com  Mon Feb  8 12:14:18 2016
From: ivo.g.dimitrov.75 at gmail.com (Ivaylo Dimitrov)
Date: Mon, 8 Feb 2016 22:14:18 +0200
Subject: [PATCH] ARM: OMAP2+: Fix onenand initialization to avoid
 filesystem corruption
In-Reply-To: <20160208193644.GU19432@atomide.com>
References: <linux-kernel@vger.kernel.org>
 <1454683028-4193-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
 <20160208193644.GU19432@atomide.com>
Message-ID: <56B8F71A.7090102@gmail.com>

Hi

On  8.02.2016 21:36, Tony Lindgren wrote:
>
> OK. So probably the INT or RDY polarity made the ECC not work.
>

Well, ECC disable bit (ONENAND_SYS_CFG1_NO_ECC) was set as well, so most 
probably it was the bugger :)

> Aaro, care to dump out also the nolo configured CFG1 value from
> n8x0 and n9(50)?
>
> You can do it by adding something like this to the beginning
> of set_onenand_cfg():
>

Also, do not forget to restore HWMOD_INIT_NO_RESET in gpmc_hwmod in 
question and (maybe) revert e7b11dc7b77bfce0a351230a5feeadc1d0bba997.

Regards,
Ivo



From s-anna at ti.com  Mon Feb  8 12:23:34 2016
From: s-anna at ti.com (Suman Anna)
Date: Mon, 8 Feb 2016 14:23:34 -0600
Subject: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager
In-Reply-To: <20160208193706.GA333@rob-hp-laptop>
References: <1454690044-2560-1-git-send-email-nm@ti.com>
 <1454690044-2560-2-git-send-email-nm@ti.com>
 <20160208193706.GA333@rob-hp-laptop>
Message-ID: <56B8F946.9060301@ti.com>

Hi Rob,

On 02/08/2016 01:37 PM, Rob Herring wrote:
> On Fri, Feb 05, 2016 at 10:34:03AM -0600, Nishanth Menon wrote:
>> Message Manager is a hardware block used to communicate with various
>> processor systems within certain Texas Instrument's Keystone
>> generation SoCs.
>>
>> This hardware engine is used to transfer messages from various compute
>> entities(or processors) within the SoC. It is designed to be self
>> contained without needing software initialization for operation.
>>
>> Signed-off-by: Nishanth Menon <nm at ti.com>
>> ---
>>  .../bindings/mailbox/ti,message-manager.txt        | 72 ++++++++++++++++++++++
>>  1 file changed, 72 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
>> new file mode 100644
>> index 000000000000..f3d73b0b3c66
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
>> @@ -0,0 +1,72 @@
>> +Texas Instruments' Message Manager Driver
>> +========================================
>> +
>> +The Texas Instruments' Message Manager is a mailbox controller that has
>> +configurable queues selectable at SoC(System on Chip) integration. The Message
>> +manager is broken up into queues in different address regions that are called
>> +"proxies" - each instance is unidirectional and is instantiated at SoC
>> +integration level to indicate receive or transmit path.
>> +
>> +Message Manager Device Node:
>> +===========================
>> +
>> +Required properties:
>> +--------------------
>> +- compatible:		Shall be:
>> +				"ti,k2g-message-manager"
>> +				"ti,message-manager"
> 
> Given that queues are configurable at integration time, does a generic 
> property really make sense here?
> 
>> +- reg-names 		queue_proxy_region - Map the queue Proxy region
>> +			queue_state_debug_region - Map the queue state debug
>> +			region.
>> +- reg:			Contains the register map per reg-names
>> +- #mbox-cells		Shall be 1
> 
> And the value contained is what?
> 
>> +
>> +Child Nodes:
>> +============
>> +A child node is used for representing the actual queue device that is
>> +used for the communication between the host processor and a remote processor.
>> +Each child node should have a unique node name across all the different
>> +message manager device nodes.
>> +
>> +Required Properties:
>> +--------------------
>> +- ti,queue-id:		Indicates the queue number this node represents
>> +- ti,proxy-id:		Proxy ID representing the processor in the SoC.
> 
> What determines these values?
> 
>> +
>> +Optional Properties:
>> +--------------------
>> +- interrupt-names:	'rx' - indicates a receive interrupt (mandatory ONLY if
>> +			this is a receive queue)
> 
> Kind of pointless if there is only 1.
> 
>> +- interrupts:		Contains the interrupt information corresponding to
>> +			interrupt-names property.
>> +
>> +Example:
>> +--------
>> +
>> +	msgmgr: msgmgr at 02a00000 {
>> +		compatible = "ti,k2g-message-manager", "ti,message-manager";
>> +		#mbox-cells = <1>;
>> +		reg-names = "queue_proxy_region", "queue_state_debug_region";
>> +		reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
>> +
>> +		msgmgr_proxy_pmmc_tx_prio0: pmmc_tx_prio0 {
>> +			ti,queue-id = <0>;
>> +			ti,proxy-id = <0>;
>> +		};
>> +
>> +		msgmgr_proxy_pmmc_rx: pmmc_rx {
>> +			ti,queue-id = <5>;
>> +			ti,proxy-id = <2>;
>> +			interrupt-names = "rx";
>> +			interrupts = <GIC_SPI 324 IRQ_TYPE_EDGE_RISING>;
>> +		};
>> +	};
>> +
>> +...
>> +	pmmc {
>> +		...
>> +		mbox-names = "tx", "rx";
>> +		mboxes = <&msgmgr &msgmgr_proxy_pmmc_tx>
>> +			 <&msgmgr &msgmgr_proxy_pmmc_rx>;
> 
> While I guess this is valid DT, it is a bit strange having the cell 
> values be phandles. Why not just make the queue and proxy ids be the 
> cell values? The interrupts could be moved to the parent and the child 
> nodes eliminated altogether.

The mailbox controller node (msgmgr) and its child nodes all are
registered with the mailbox core together and the client users request a
mailbox using the framework API that requires the controller node.
Usually the channels are given numbers and the request is done based on
indices, but that meant that we had to introduce a logical device id
just for the sake of the API. Instead, we just chose to go with the
phandles.

Doing a queue and proxy id as cell values requires the mailbox
controller node registration phase to parse through all the client nodes
with the matching controller node. The current approach was in-line with
how all the mailbox controller nodes are implemented today, except for
the usage of phandle instead of an index for the cell-value.

> 
> The alternative would be just drop msgmgr phandle and point to the child 
> nodes. I prefer getting rid of the child nodes though.

The 'mboxes' property is a standard property supported by the mailbox
framework core, and requires the phandle of the controller node along
with a cell-value to lookup a channel. So, we cannot use the child nodes
directly.

regards
Suman


From tony at atomide.com  Mon Feb  8 12:26:46 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Feb 2016 12:26:46 -0800
Subject: [PATCH] ARM: OMAP2+: Fix onenand initialization to avoid
 filesystem corruption
In-Reply-To: <56B8F71A.7090102@gmail.com>
References: <linux-kernel@vger.kernel.org>
 <1454683028-4193-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
 <20160208193644.GU19432@atomide.com> <56B8F71A.7090102@gmail.com>
Message-ID: <20160208202646.GA19432@atomide.com>

* Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com> [160208 12:15]:
> Hi
> 
> On  8.02.2016 21:36, Tony Lindgren wrote:
> >
> >OK. So probably the INT or RDY polarity made the ECC not work.
> >
> 
> Well, ECC disable bit (ONENAND_SYS_CFG1_NO_ECC) was set as well, so most
> probably it was the bugger :)

Oh OK that explains.

> >Aaro, care to dump out also the nolo configured CFG1 value from
> >n8x0 and n9(50)?
> >
> >You can do it by adding something like this to the beginning
> >of set_onenand_cfg():
> >
> 
> Also, do not forget to restore HWMOD_INIT_NO_RESET in gpmc_hwmod in question
> and (maybe) revert e7b11dc7b77bfce0a351230a5feeadc1d0bba997.

Probably just enabling CONFIG_OMAP_GPMC_DEBUG allows dumping
the GPMC configuration. And it sounds like it's a good idea
to have this patch enabled.

Regards,

Tony


From nm at ti.com  Mon Feb  8 12:31:40 2016
From: nm at ti.com (Nishanth Menon)
Date: Mon, 8 Feb 2016 14:31:40 -0600
Subject: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager
In-Reply-To: <20160208193706.GA333@rob-hp-laptop>
References: <1454690044-2560-1-git-send-email-nm@ti.com>
 <1454690044-2560-2-git-send-email-nm@ti.com>
 <20160208193706.GA333@rob-hp-laptop>
Message-ID: <CAGo_u6oQ3wHB9--2sZGwhM_eQa4ixNDKDVoFaaNStWYjwO2xig@mail.gmail.com>

On Mon, Feb 8, 2016 at 1:37 PM, Rob Herring <robh at kernel.org> wrote:

Thank you for reviewing the binding.

> On Fri, Feb 05, 2016 at 10:34:03AM -0600, Nishanth Menon wrote:
>> Message Manager is a hardware block used to communicate with various
>> processor systems within certain Texas Instrument's Keystone
>> generation SoCs.
>>
>> This hardware engine is used to transfer messages from various compute
>> entities(or processors) within the SoC. It is designed to be self
>> contained without needing software initialization for operation.
>>
>> Signed-off-by: Nishanth Menon <nm at ti.com>
>> ---
>>  .../bindings/mailbox/ti,message-manager.txt        | 72 ++++++++++++++++++++++
>>  1 file changed, 72 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
>> new file mode 100644
>> index 000000000000..f3d73b0b3c66
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
>> @@ -0,0 +1,72 @@
>> +Texas Instruments' Message Manager Driver
>> +========================================
>> +
>> +The Texas Instruments' Message Manager is a mailbox controller that has
>> +configurable queues selectable at SoC(System on Chip) integration. The Message
>> +manager is broken up into queues in different address regions that are called
>> +"proxies" - each instance is unidirectional and is instantiated at SoC
>> +integration level to indicate receive or transmit path.
>> +
>> +Message Manager Device Node:
>> +===========================
>> +
>> +Required properties:
>> +--------------------
>> +- compatible:                Shall be:
>> +                             "ti,k2g-message-manager"
>> +                             "ti,message-manager"
>
> Given that queues are configurable at integration time, does a generic
> property really make sense here?

True. I can drop the generic "ti,message-manager" binding.

>> +- reg-names          queue_proxy_region - Map the queue Proxy region
>> +                     queue_state_debug_region - Map the queue state debug
>> +                     region.
>> +- reg:                       Contains the register map per reg-names
>> +- #mbox-cells                Shall be 1
>
> And the value contained is what?

phandle -> I think Suman has already explained in his response.

>> +
>> +Child Nodes:
>> +============
>> +A child node is used for representing the actual queue device that is
>> +used for the communication between the host processor and a remote processor.
>> +Each child node should have a unique node name across all the different
>> +message manager device nodes.
>> +
>> +Required Properties:
>> +--------------------
>> +- ti,queue-id:               Indicates the queue number this node represents
>> +- ti,proxy-id:               Proxy ID representing the processor in the SoC.
>
> What determines these values?

This is SoC integration dependent -> Every queue, proxy combination
has it's own memory region allocated for it.

>> +
>> +Optional Properties:
>> +--------------------
>> +- interrupt-names:   'rx' - indicates a receive interrupt (mandatory ONLY if
>> +                     this is a receive queue)
>
> Kind of pointless if there is only 1.
>

This is primarily to ensure a future compatibility where we are trying
to convince the hardware team to provide an error interrupt per queue
as well for slave usage.
it would probably be pointless at that time to deal with "legacy"
binding defintions when the next hardware ip definition takes place.

>> +- interrupts:                Contains the interrupt information corresponding to
>> +                     interrupt-names property.
>> +
>> +Example:
>> +--------
>> +
>> +     msgmgr: msgmgr at 02a00000 {
>> +             compatible = "ti,k2g-message-manager", "ti,message-manager";
>> +             #mbox-cells = <1>;
>> +             reg-names = "queue_proxy_region", "queue_state_debug_region";
>> +             reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
>> +
>> +             msgmgr_proxy_pmmc_tx_prio0: pmmc_tx_prio0 {
>> +                     ti,queue-id = <0>;
>> +                     ti,proxy-id = <0>;
>> +             };
>> +
>> +             msgmgr_proxy_pmmc_rx: pmmc_rx {
>> +                     ti,queue-id = <5>;
>> +                     ti,proxy-id = <2>;
>> +                     interrupt-names = "rx";
>> +                     interrupts = <GIC_SPI 324 IRQ_TYPE_EDGE_RISING>;
>> +             };
>> +     };
>> +
>> +...
>> +     pmmc {
>> +             ...
>> +             mbox-names = "tx", "rx";
>> +             mboxes = <&msgmgr &msgmgr_proxy_pmmc_tx>
>> +                      <&msgmgr &msgmgr_proxy_pmmc_rx>;
>
> While I guess this is valid DT, it is a bit strange having the cell
> values be phandles. Why not just make the queue and proxy ids be the
> cell values? The interrupts could be moved to the parent and the child
> nodes eliminated altogether.
>
> The alternative would be just drop msgmgr phandle and point to the child
> nodes. I prefer getting rid of the child nodes though.

I see that Suman has already responded to this.

--
Regards,
Nishanth Menon


From tony at atomide.com  Mon Feb  8 12:44:46 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Feb 2016 12:44:46 -0800
Subject: [PATCH 0/3] omap: hwmod: add default reset handling support
In-Reply-To: <1454929941-23949-1-git-send-email-kishon@ti.com>
References: <1454929941-23949-1-git-send-email-kishon@ti.com>
Message-ID: <20160208204446.GC19432@atomide.com>

Hi Kishon,

* Kishon Vijay Abraham I <kishon at ti.com> [160208 03:13]:
> Add a new hwmod flag to indicate custom reset handling and use it
> for devices that require custom reset handling (like dsp, ipu, iva).
> 
> Tested PCIe on dra7-evm and dra72-evm.
> I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
> Or a way to test these cores to see if reset is not broken. Suman?
> 
> I'll post this series once again after performing these tests.

Do we also still need to patch something in the pcie driver too
or can all that be left out now?

Regards,

Tony


> Paul Walmsley (3):
>   ARM: omap2+: omap_hwmod: introduce hwmod flag for custom reset
>     handling
>   ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for custom reset
>     handling
>   ARM: OMAP2+: hwmod: Add default reset handling
> 
>  arch/arm/mach-omap2/omap_hwmod.c                   |   16 +++++++++++-----
>  arch/arm/mach-omap2/omap_hwmod.h                   |   12 ++++++++++++
>  arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
>  arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
>  .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
>  arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
>  10 files changed, 41 insertions(+), 5 deletions(-)
> 
> -- 
> 1.7.9.5
> 


From ddaney at caviumnetworks.com  Mon Feb  8 12:47:18 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Mon, 8 Feb 2016 12:47:18 -0800
Subject: [PATCH v5 3/3] pci,
 pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices
In-Reply-To: <20160208195642.GA15103@rob-hp-laptop>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
 <1454715675-17512-4-git-send-email-ddaney.cavm@gmail.com>
 <20160208195642.GA15103@rob-hp-laptop>
Message-ID: <56B8FED6.1050804@caviumnetworks.com>

On 02/08/2016 11:56 AM, Rob Herring wrote:
> On Fri, Feb 05, 2016 at 03:41:15PM -0800, David Daney wrote:
>> From: David Daney <david.daney at cavium.com>
>>
>> The cavium,pci-thunder-ecam devices are exactly ECAM based PCI root
>> complexes.  These root complexes (loosely referred to as ECAM units in
>> the hardware manuals) are used to access the Thunder on-chips devices.
>> They are special in that all the BARs on devices behind these root
>> complexes are at fixed addresses.  To handle this in a manner
>> compatible with the core PCI code, we have the config access functions
>> synthesize Enhanced Allocation (EA) capability entries for each BAR.
>>
>> Since this EA synthesis is needed for exactly one chip model, we can
>> hard code some assumptions about the device topology and the
>> properties of specific DEVFNs in the driver.
>>
>> Signed-off-by: David Daney <david.daney at cavium.com>
>> ---
>>   .../devicetree/bindings/pci/pci-thunder-ecam.txt   |  30 ++
>>   drivers/pci/host/Kconfig                           |   7 +
>>   drivers/pci/host/Makefile                          |   1 +
>>   drivers/pci/host/pci-thunder-ecam.c                | 358 +++++++++++++++++++++
>>   4 files changed, 396 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt
>>   create mode 100644 drivers/pci/host/pci-thunder-ecam.c
>>
>> diff --git a/Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt b/Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt
>> new file mode 100644
>> index 0000000..34658f2
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt
>> @@ -0,0 +1,30 @@
>> +* ThunderX PCI host controller for pass-1.x silicon
>> +
>> +Firmware-initialized PCI host controller to on-chip devices found on
>> +some Cavium ThunderX processors.  These devices have ECAM based config
>> +access, but the BARs are all at fixed addresses.  We handle the fixed
>> +addresses by synthesizing Enhanced Allocation (EA) capabilities for
>> +these devices.
>> +
>> +The properties and their meanings are identical to those described in
>> +host-generic-pci.txt except as listed below.
>> +
>> +Properties of the host controller node that differ from
>> +host-generic-pci.txt:
>> +
>> +- compatible     : Must be "cavium,pci-host-thunder-ecam"
>> +
>> +Example:
>> +
>> +	pci at 84b0,00000000 {
>
> Drop the comma,

OK...

> and the node name should be "pcie".
>

Why pcie?

There are no PCIe devices or buses reachable from this type of root 
complex.  There are however many PCI devices.

> Otherwise,
>
> Acked-by: Rob Herring <robh at kernel.org>
>
>> +		compatible = "cavium,pci-host-thunder-ecam";
>> +		device_type = "pci";
>> +		msi-parent = <&its>;
>> +		msi-map = <0 &its 0x30000 0x10000>;
>> +		bus-range = <0 31>;
>> +		#size-cells = <2>;
>> +		#address-cells = <3>;
>> +		#stream-id-cells = <1>;
>> +		reg = <0x84b0 0x00000000 0 0x02000000>;  /* Configuration space */
>> +		ranges = <0x03000000 0x8180 0x00000000 0x8180 0x00000000 0x80 0x00000000>; /* mem ranges */
>> +	};



From tony at atomide.com  Mon Feb  8 12:48:06 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 8 Feb 2016 12:48:06 -0800
Subject: [PATCH] ARM: RX51: Set system_rev from ATAGS
In-Reply-To: <1454696102-2214-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
References: <3663322.UyrB2OmX6o@wuerfel>
 <1454696102-2214-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
Message-ID: <20160208204806.GE19432@atomide.com>

* Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com> [160205 10:17]:

Can you please add the "why?" part here? Other than that looks
OK to me.

And unless people have objections, I'd like to get this merged
in as it fixes yet another legacy boot vs DT boot regression.

Regards,

Tony

> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com>
> ---
>  arch/arm/mach-omap2/board-generic.c | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index 8098272..b91fabe 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -18,6 +18,7 @@
>  
>  #include <asm/setup.h>
>  #include <asm/mach/arch.h>
> +#include <asm/system_info.h>
>  
>  #include "common.h"
>  
> @@ -77,12 +78,31 @@ static const char *const n900_boards_compat[] __initconst = {
>  	NULL,
>  };
>  
> +/* Set system_rev from atags */
> +static void __init rx51_system_rev(const struct tag *tags)
> +{
> +	const struct tag *tag;
> +
> +	if (tags->hdr.tag != ATAG_CORE)
> +		return;
> +
> +	for_each_tag(tag, tags) {
> +		if (tag->hdr.tag == ATAG_REVISION) {
> +			system_rev = tag->u.revision.rev;
> +			break;
> +		}
> +	}
> +}
> +
>  /* Legacy userspace on Nokia N900 needs ATAGS exported in /proc/atags,
>   * save them while the data is still not overwritten
>   */
>  static void __init rx51_reserve(void)
>  {
> -	save_atags((const struct tag *)(PAGE_OFFSET + 0x100));
> +	const struct tag *tags = (const struct tag *)(PAGE_OFFSET + 0x100);
> +
> +	save_atags(tags);
> +	rx51_system_rev(tags);
>  	omap_reserve();
>  }
>  
> -- 
> 1.9.1
> 


From s-anna at ti.com  Mon Feb  8 12:56:09 2016
From: s-anna at ti.com (Suman Anna)
Date: Mon, 8 Feb 2016 14:56:09 -0600
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
Message-ID: <56B900E9.9040306@ti.com>

Hi Paul,

On 02/07/2016 08:48 PM, Paul Walmsley wrote:
> On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:
> 
>> Paul, what do you think is the best way forward to perform reset?
> 
> Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
> Those often need special reset handling to ensure that WFI/HLT-like 
> instructions are executed after reset.  This special handling ensures that 
> the IP blocks' bus initiator interfaces indicate that they are in standby 
> to the PRCM - thus allowing power management for the rest of the chip to 
> work correctly.
> 
> But that doesn't seem to be the case with PCIe - and maybe others - 
> possibly some of the MMUs?  

Yeah, the sequencing between clocks and resets would still be the same
for MMUs, so, adding the custom flags for MMUs is fine.

So how about just creating a new hwmod flag to
> mark all of the initiator IP blocks that require driver-based special 
> handling during _enable() - i.e., most of the processor IP blocks. Then 
> for the rest, like PCIe, implement a default behavior in the hwmod code to 
> automatically release the IP block's hardreset lines in 
> omap_hwmod.c:_enable()?  Something similar to what's enclosed at the 
> bottom of this message.  I've annotated what will be needed in the 
> OMAP44xx file; similar flags will be needed in any other hwmod data file 
> that contains IP blocks with hard reset lines defined.
> 
> Either that - or you could write custom reset handlers for all of the 
> processor IP blocks that put them into WFI/HLT.
> 
> I leave it to you TI folks to write and test the actual patches, since as 
> you probably know, I don't have any DRA7xx/AM57xx boards in the testbed.  
> 
> As far as reasserting hardreset in *remove(), there's already hwmod code 
> to do that in omap_hwmod.c:_shutdown().  I don't recall any more if we 
> currently have code in the stack that calls it.  Ideally the device model 
> code should call that during or after a .remove() call.

Yeah, don't think there is any code that exercises
omap_hwmod_shutdown(). We used to have an omap_device_shutdown() but
that function has been removed in commit c1d1cd597fc7 ("ARM: OMAP2+:
omap_device: remove obsolete pm_lats and early_device code"). We used to
exercise this using custom pm_lats replacing idle with shutdown in the
out-of-tree processor drivers.

> 
> 
> - Paul
> 
> 
> ---
>  arch/arm/mach-omap2/omap_hwmod.c           | 16 +++++++++++-----
>  arch/arm/mach-omap2/omap_hwmod.h           | 12 ++++++++++++
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  6 ++++++
>  3 files changed, 29 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index e9f65fec55c0..ab66dd988709 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -2077,7 +2077,7 @@ static int _enable_preprogram(struct omap_hwmod *oh)
>   */
>  static int _enable(struct omap_hwmod *oh)
>  {
> -	int r;
> +	int r, i;
>  	int hwsup = 0;
>  
>  	pr_debug("omap_hwmod: %s: enabling\n", oh->name);
> @@ -2109,17 +2109,23 @@ static int _enable(struct omap_hwmod *oh)
>  	}
>  
>  	/*
> -	 * If an IP block contains HW reset lines and all of them are
> -	 * asserted, we let integration code associated with that
> -	 * block handle the enable.  We've received very little
> +	 * If an IP block contains HW reset lines, all of them are
> +	 * asserted, and the IP block is marked as requiring a custom
> +	 * hardreset handler, we let integration code associated with
> +	 * that block handle the enable.  We've received very little
>  	 * information on what those driver authors need, and until
>  	 * detailed information is provided and the driver code is
>  	 * posted to the public lists, this is probably the best we
>  	 * can do.
>  	 */
> -	if (_are_all_hardreset_lines_asserted(oh))
> +	if ((oh->flags & HWMOD_CUSTOM_HARDRESET) &&
> +	    _are_all_hardreset_lines_asserted(oh))
>  		return 0;
>  
> +	/* If the IP block is an initiator, release it from hardreset */
> +	for (i = 0; i < oh->rst_lines_cnt; i++)
> +		_deassert_hardreset(oh, oh->rst_lines[i].name);

I believe this will cause a problem as typically we release the reset
and then call pm_runtime_get_sync() to enable the clock. We are not
checking error code, but if were, I do think _deassert_hardreset would
return a failure.

regards
Suman

> +
>  	/* Mux pins for device runtime if populated */
>  	if (oh->mux && (!oh->mux->enabled ||
>  			((oh->_state == _HWMOD_STATE_IDLE) &&
> diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
> index 76bce11c85a4..4198829551a4 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.h
> +++ b/arch/arm/mach-omap2/omap_hwmod.h
> @@ -525,6 +525,17 @@ struct omap_hwmod_omap4_prcm {
>   *     or idled.
>   * HWMOD_OPT_CLKS_NEEDED: The optional clocks are needed for the module to
>   *     operate and they need to be handled at the same time as the main_clk.
> + * HWMOD_CUSTOM_HARDRESET: By default, if a hwmod has PRCM hardreset
> + *     lines associated with it (i.e., a populated .rst_lines field in
> + *     the hwmod), the hwmod code will assert the hardreset lines when
> + *     the IP block is initially reset, deassert the hardreset lines
> + *     in _enable(), and reassert them in _shutdown().  If this flag
> + *     is set, the hwmod code will not deassert the hardreset lines in
> + *     _enable(), leaving this responsibility to the driver code.  This flag may
> + *     be needed for processor IP blocks that must be put into a WFI/HLT
> + *     state after reset is deasserted, lest the processor leave its MSTANDBY
> + *     signal deasserted, thus blocking the chip from entering a system-wide
> + *     low power state.
>   */
>  #define HWMOD_SWSUP_SIDLE			(1 << 0)
>  #define HWMOD_SWSUP_MSTANDBY			(1 << 1)
> @@ -541,6 +552,7 @@ struct omap_hwmod_omap4_prcm {
>  #define HWMOD_SWSUP_SIDLE_ACT			(1 << 12)
>  #define HWMOD_RECONFIG_IO_CHAIN			(1 << 13)
>  #define HWMOD_OPT_CLKS_NEEDED			(1 << 14)
> +#define HWMOD_CUSTOM_HARDRESET			(1 << 15)
>  
>  /*
>   * omap_hwmod._int_flags definitions
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index dad871a4cd96..20501f0e3c6c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -553,6 +553,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
>  			.modulemode   = MODULEMODE_HWCTRL,
>  		},
>  	},
> +	.flags		= HWMOD_CUSTOM_HARDRESET,
>  };
>  
>  /*
> @@ -1433,6 +1434,7 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
>  			.modulemode   = MODULEMODE_HWCTRL,
>  		},
>  	},
> +	.flags		= HWMOD_CUSTOM_HARDRESET,
>  };
>  
>  /*
> @@ -1517,6 +1519,7 @@ static struct omap_hwmod omap44xx_iva_hwmod = {
>  			.modulemode   = MODULEMODE_HWCTRL,
>  		},
>  	},
> +	.flags		= HWMOD_CUSTOM_HARDRESET,
>  };
>  
>  /*
> @@ -2115,6 +2118,7 @@ static struct omap_hwmod omap44xx_mmu_ipu_hwmod = {
>  			.modulemode   = MODULEMODE_HWCTRL,
>  		},
>  	},
> +	.flags		= HWMOD_CUSTOM_HARDRESET, /* XXX doublecheck */
>  };
>  
>  /* mmu dsp */
> @@ -2147,6 +2151,7 @@ static struct omap_hwmod omap44xx_mmu_dsp_hwmod = {
>  			.modulemode   = MODULEMODE_HWCTRL,
>  		},
>  	},
> +	.flags		= HWMOD_CUSTOM_HARDRESET, /* XXX doublecheck */
>  };
>  
>  /*
> @@ -2299,6 +2304,7 @@ static struct omap_hwmod omap44xx_prm_hwmod = {
>  	.class		= &omap44xx_prcm_hwmod_class,
>  	.rst_lines	= omap44xx_prm_resets,
>  	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_prm_resets),
> +	.flags		= HWMOD_CUSTOM_HARDRESET,
>  };
>  
>  /*
> 



From s-anna at ti.com  Mon Feb  8 13:07:08 2016
From: s-anna at ti.com (Suman Anna)
Date: Mon, 8 Feb 2016 15:07:08 -0600
Subject: [PATCH 0/3] omap: hwmod: add default reset handling support
In-Reply-To: <1454929941-23949-1-git-send-email-kishon@ti.com>
References: <1454929941-23949-1-git-send-email-kishon@ti.com>
Message-ID: <56B9037C.2050203@ti.com>

On 02/08/2016 05:12 AM, Kishon Vijay Abraham I wrote:
> Add a new hwmod flag to indicate custom reset handling and use it
> for devices that require custom reset handling (like dsp, ipu, iva).
> 
> Tested PCIe on dra7-evm and dra72-evm.
> I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
> Or a way to test these cores to see if reset is not broken. Suman?

I won't be able to test this week, and have requested Dave to check on
wkup_m3_rproc driver atleast. I see one potential issue (see my commment
on the other thread), but can confirm that only after testing.

Have you tested multiple probe/removal sequences? Can you check the
return status on the _hardreset_deassert call with your PCIe driver,
believe even that one would return an error on multiple probes.

regards
Suman

> 
> I'll post this series once again after performing these tests.
> 
> Paul Walmsley (3):
>   ARM: omap2+: omap_hwmod: introduce hwmod flag for custom reset
>     handling
>   ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for custom reset
>     handling
>   ARM: OMAP2+: hwmod: Add default reset handling
> 
>  arch/arm/mach-omap2/omap_hwmod.c                   |   16 +++++++++++-----
>  arch/arm/mach-omap2/omap_hwmod.h                   |   12 ++++++++++++
>  arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
>  arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
>  .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
>  arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
>  10 files changed, 41 insertions(+), 5 deletions(-)
> 



From pali.rohar at gmail.com  Mon Feb  8 13:10:22 2016
From: pali.rohar at gmail.com (Pali =?utf-8?B?Um9ow6Fy?=)
Date: Mon, 8 Feb 2016 22:10:22 +0100
Subject: [PATCH] ARM: RX51: Set system_rev from ATAGS
In-Reply-To: <1454696102-2214-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
References: <3663322.UyrB2OmX6o@wuerfel>
 <1454696102-2214-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
Message-ID: <20160208211022.GM30075@pali>

On Friday 05 February 2016 20:15:02 Ivaylo Dimitrov wrote:
> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com>

Reviewed-by: Pali Roh?r <pali.rohar at gmail.com>
Tested-by: Pali Roh?r <pali.rohar at gmail.com>

> ---
>  arch/arm/mach-omap2/board-generic.c | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index 8098272..b91fabe 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -18,6 +18,7 @@
>  
>  #include <asm/setup.h>
>  #include <asm/mach/arch.h>
> +#include <asm/system_info.h>
>  
>  #include "common.h"
>  
> @@ -77,12 +78,31 @@ static const char *const n900_boards_compat[] __initconst = {
>  	NULL,
>  };
>  
> +/* Set system_rev from atags */
> +static void __init rx51_system_rev(const struct tag *tags)
> +{
> +	const struct tag *tag;
> +
> +	if (tags->hdr.tag != ATAG_CORE)
> +		return;
> +
> +	for_each_tag(tag, tags) {
> +		if (tag->hdr.tag == ATAG_REVISION) {
> +			system_rev = tag->u.revision.rev;
> +			break;
> +		}
> +	}
> +}
> +
>  /* Legacy userspace on Nokia N900 needs ATAGS exported in /proc/atags,
>   * save them while the data is still not overwritten
>   */
>  static void __init rx51_reserve(void)
>  {
> -	save_atags((const struct tag *)(PAGE_OFFSET + 0x100));
> +	const struct tag *tags = (const struct tag *)(PAGE_OFFSET + 0x100);
> +
> +	save_atags(tags);
> +	rx51_system_rev(tags);

Tony, if you are going to take this patch, I would suggest to rename
function name rx51_system_rev to rx51_set_system_rev as it says what
function do (set system rev :-)).

>  	omap_reserve();
>  }
>  

-- 
Pali Roh?r
pali.rohar at gmail.com


From robh at kernel.org  Mon Feb  8 13:12:23 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 15:12:23 -0600
Subject: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for
 ThunderX-pass1 on-chip devices
In-Reply-To: <56B8FED6.1050804@caviumnetworks.com>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
 <1454715675-17512-4-git-send-email-ddaney.cavm@gmail.com>
 <20160208195642.GA15103@rob-hp-laptop>
 <56B8FED6.1050804@caviumnetworks.com>
Message-ID: <CAL_JsqJNndZ59465YhpkP=dQYaijaar+LcQG4KQEJwF5e1ryLQ@mail.gmail.com>

On Mon, Feb 8, 2016 at 2:47 PM, David Daney <ddaney at caviumnetworks.com> wrote:
> On 02/08/2016 11:56 AM, Rob Herring wrote:
>>
>> On Fri, Feb 05, 2016 at 03:41:15PM -0800, David Daney wrote:
>>>
>>> From: David Daney <david.daney at cavium.com>

[...]

>>> +Properties of the host controller node that differ from
>>> +host-generic-pci.txt:
>>> +
>>> +- compatible     : Must be "cavium,pci-host-thunder-ecam"
>>> +
>>> +Example:
>>> +
>>> +       pci at 84b0,00000000 {
>>
>>
>> Drop the comma,
>
>
> OK...
>
>> and the node name should be "pcie".
>>
>
> Why pcie?
>
> There are no PCIe devices or buses reachable from this type of root complex.
> There are however many PCI devices.

I thought ECAM is a PCIe thing. If not, then nevermind.

Rob


From khilman at baylibre.com  Mon Feb  8 13:20:35 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Mon, 08 Feb 2016 13:20:35 -0800
Subject: [PATCH v4 00/13] arm64: kernel: Add support for
 hibernate/suspend-to-disk
In-Reply-To: <56B4AF2A.2070503@arm.com> (James Morse's message of "Fri, 05 Feb
 2016 14:18:18 +0000")
References: <1453977766-20907-1-git-send-email-james.morse@arm.com>
 <7hvb6chv5e.fsf@baylibre.com> <56AF1D07.3000604@arm.com>
 <7hmvrid3pv.fsf@baylibre.com> <56B4AF2A.2070503@arm.com>
Message-ID: <7h8u2uc318.fsf@baylibre.com>

James Morse <james.morse at arm.com> writes:

> Hi Kevin,
>
> On 03/02/16 00:42, Kevin Hilman wrote:
>> James Morse <james.morse at arm.com> writes:
>>> On 29/01/16 22:34, Kevin Hilman wrote:
>>>> James Morse <james.morse at arm.com> writes:
>>>> I'd like to help in testing this so I'm just curious which platforms
>>>> you've been testing this on.  I'm assuming a Juno (r2?), anything else?
>>>
>>> That would be great - thanks!
>>>
>>> I've done most of the testing on a Juno r1, but also gave it a spin on a
>>> stray Seattle.
>> 
>> OK, I'm using a very recently arrived Juno R2, and I did get it
>> working.  I have a few other arm64 boards around that ar part of
>> kernelci.org and will try those as well.
>
> Great,
> It would be good to have a Tested-by if it works to your satisfaction...

Yes, feel free to add

Tested-by: Kevin Hilman <khilman at baylibre.com> # Tested on Juno R2

I tried to also test on the qcom 96boards, but that platform doesn't
support suspend/resume yet. :(

Kevin



From robh at kernel.org  Mon Feb  8 13:24:43 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 15:24:43 -0600
Subject: [PATCH V5 1/2] regulator: Add document for MT6323 regulator
In-Reply-To: <1454874037-38905-1-git-send-email-blogic@openwrt.org>
References: <1454874037-38905-1-git-send-email-blogic@openwrt.org>
Message-ID: <20160208212443.GA32296@rob-hp-laptop>

On Sun, Feb 07, 2016 at 08:40:36PM +0100, John Crispin wrote:
> Signed-off-by: John Crispin <blogic at openwrt.org>
> Cc: devicetree at vger.kernel.org
> 
> ---
> Changes in V5
> * regulator vs regulators
> 
> Changes in V4
> * regulator is a subnode and not a property
> 
>  .../bindings/regulator/mt6323-regulator.txt        |  244 ++++++++++++++++++++
>  1 file changed, 244 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/regulator/mt6323-regulator.txt

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Mon Feb  8 13:27:38 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 15:27:38 -0600
Subject: [PATCH v2 01/10] Documentation: devicetree: Add vendor prefix
 for GeekBuying.com
In-Reply-To: <1454897859-7601-2-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
 <1454897859-7601-2-git-send-email-afaerber@suse.de>
Message-ID: <20160208212738.GA564@rob-hp-laptop>

On Mon, Feb 08, 2016 at 03:17:30AM +0100, Andreas F?rber wrote:
> Use "geekbuying".
> 
> Signed-off-by: Andreas F?rber <afaerber at suse.de>

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Mon Feb  8 13:28:07 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 15:28:07 -0600
Subject: [PATCH v2 02/10] Documentation: devicetree: rockchip: Document
 GeekBox
In-Reply-To: <1454897859-7601-3-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
 <1454897859-7601-3-git-send-email-afaerber@suse.de>
Message-ID: <20160208212807.GA2247@rob-hp-laptop>

On Mon, Feb 08, 2016 at 03:17:31AM +0100, Andreas F?rber wrote:
> Use "geekbuying,geekbox" compatible string.
> 
> Signed-off-by: Andreas F?rber <afaerber at suse.de>
> ---
>  v2: New (Heiko)
>  
>  Documentation/devicetree/bindings/arm/rockchip.txt | 4 ++++
>  1 file changed, 4 insertions(+)

Acked-by: Rob Herring <robh at kernel.org>


From ddaney at caviumnetworks.com  Mon Feb  8 13:39:21 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Mon, 8 Feb 2016 13:39:21 -0800
Subject: [PATCH v5 3/3] pci,
 pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices
In-Reply-To: <CAL_JsqJNndZ59465YhpkP=dQYaijaar+LcQG4KQEJwF5e1ryLQ@mail.gmail.com>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
 <1454715675-17512-4-git-send-email-ddaney.cavm@gmail.com>
 <20160208195642.GA15103@rob-hp-laptop> <56B8FED6.1050804@caviumnetworks.com>
 <CAL_JsqJNndZ59465YhpkP=dQYaijaar+LcQG4KQEJwF5e1ryLQ@mail.gmail.com>
Message-ID: <56B90B09.7090500@caviumnetworks.com>

On 02/08/2016 01:12 PM, Rob Herring wrote:
> On Mon, Feb 8, 2016 at 2:47 PM, David Daney <ddaney at caviumnetworks.com> wrote:
>> On 02/08/2016 11:56 AM, Rob Herring wrote:
>>>
>>> On Fri, Feb 05, 2016 at 03:41:15PM -0800, David Daney wrote:
>>>>
>>>> From: David Daney <david.daney at cavium.com>
>
> [...]
>
>>>> +Properties of the host controller node that differ from
>>>> +host-generic-pci.txt:
>>>> +
>>>> +- compatible     : Must be "cavium,pci-host-thunder-ecam"
>>>> +
>>>> +Example:
>>>> +
>>>> +       pci at 84b0,00000000 {
>>>
>>>
>>> Drop the comma,
>>
>>
>> OK...
>>
>>> and the node name should be "pcie".
>>>
>>
>> Why pcie?
>>
>> There are no PCIe devices or buses reachable from this type of root complex.
>> There are however many PCI devices.
>
> I thought ECAM is a PCIe thing. If not, then nevermind.


Well, Enhanced Configuration Access Mechanism (ECAM) is defined  the the 
PCI Express(R) base Specification, but it just defines a standard layout 
of address bits to memory map config space operations.  Since the PCI 
config space is a sub set of the PCIe config space, ECAM can also be 
used in PCI systems.

Really, it is a bit of a gray area here as we don't have any bridges to 
PCIe buses and there are multiple devices residing on each bus, so from 
that point of view it cannot be PCIe.  There are, however, devices that 
implement the PCI Express Capability structure, so does that make it 
PCIe?  It is not clear what the specifications demand here.

I choose to call it "pci" as it lacks much of what it means to be PCIe, 
and also you cannot plug things into it.

David Daney



>
> Rob
>



From arnd at arndb.de  Mon Feb  8 13:45:07 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 08 Feb 2016 22:45:07 +0100
Subject: [PATCH 2/2] serial: 8250: fix building Ingenic with SERIAL_8250=m
In-Reply-To: <20160208164543.GY23093@windriver.com>
References: <1454935947-2743255-1-git-send-email-arnd@arndb.de>
 <1454935947-2743255-2-git-send-email-arnd@arndb.de>
 <20160208164543.GY23093@windriver.com>
Message-ID: <2444356.TvhDejDUJL@wuerfel>

On Monday 08 February 2016 11:45:44 Paul Gortmaker wrote:
> [[PATCH 2/2] serial: 8250: fix building Ingenic with SERIAL_8250=m] On 08/02/2016 (Mon 13:51) Arnd Bergmann wrote:
> 
> > The Ingenic 8250 driver has a 'bool' Kconfig symbol, but that
> > breaks when SERIAL_8250 is a loadable module:
> > 
> > drivers/tty/built-in.o: In function `ingenic_uart_probe':
> > 8250_ingenic.c:(.text+0x1c1a0): undefined reference to `serial8250_register_8250_port'
> > 
> > This changes the symbol to a 'tristate', plus a dependency on
> 
> Note that Greg just queued a patch yesterday (but sent in 2015) that
> removed what was the dead modular code.
> 
> It could also depend on SERIAL_8250=y to resolve the build issue you
> found, if nobody cares about having modular SOC console UART drivers.

All other UART drivers can be modules, no need for this to be an
exception I think. Having it depend on SERIAL_8250=y would make the
driver disabled on 'allmodconfig', which is a bit counterproductive for
the purpose of allmodconfig. I don't think anyone actually cares about
the driver being runtime loaded on real hardware.

> Either way, I don't have issue with it being tristate vs bool, but if
> you do go with tristate, then my patch will have to be dropped/reverted.

Fine with me too.

I also now saw in the randconfig builds that the driver is missing an #include
<linux/module.h>, which I guess is going to be there after reverting your
patch.

I'll send a new series.

	Arnd


From Valdis.Kletnieks at vt.edu  Mon Feb  8 13:44:33 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 08 Feb 2016 16:44:33 -0500
Subject: [PATCH v12 2/4] PM / Domains: add setter for dev.pm_domain
In-Reply-To: <1783906.XctYjeUNLr@vostro.rjw.lan>
References: <1452181575-9206-1-git-send-email-tomeu.vizoso@collabora.com>
 <CAHp75VdWPUZ8F5rsGn3M1e5Pgpcg1CErBej9PE_3+ZPke5CDFA@mail.gmail.com>
 <CAHp75Vf9TS-AxJALQjiwNjMCT8ct5SBanYzrEsV9aj=DsUw-OA@mail.gmail.com>
 <1783906.XctYjeUNLr@vostro.rjw.lan>
Message-ID: <44858.1454967873@turing-police.cc.vt.edu>

On Fri, 29 Jan 2016 22:35:18 +0100, "Rafael J. Wysocki" said:
> > One more test unveils this one
> > 
> > # modprobe -r sdhci-acpi
> > [ 1289.909441] ------------[ cut here ]------------
> > [ 1289.918205] WARNING: CPU: 1 PID: 4374 at
> > /home/andy/prj/linux-otc/drivers/base/power/common.c:150
> > dev_pm_domain_set+0x51/0x60()
> > [ 1289.934681] PM domains can only be changed for unbound devices
> > [ 1289.944843] Modules linked in: sdhci_acpi(-) sdhci mmc_core
> > led_class [last unloaded: dw_dmac_core]
> > [ 1289.958802] CPU: 1 PID: 4374 Comm: modprobe Not tainted 4.5.0-rc1+ #3
> > [ 1289.969736]  ffffffff81c38330 ffff88007bb53d18 ffffffff8133162f
> > ffff88007bb53d60
> > [ 1289.981844]  ffff88007bb53d50 ffffffff8105cd12 ffff88017a007410
> > 0000000000000000
> > [ 1289.993996]  0000000000000001 0000000000000080 0000000000000000
> > ffff88007bb53db0
> > [ 1290.006123] Call Trace:
> > [ 1290.012600]  [<ffffffff8133162f>] dump_stack+0x44/0x55
> > [ 1290.022052]  [<ffffffff8105cd12>] warn_slowpath_common+0x82/0xc0
> > [ 1290.032462]  [<ffffffff8105cd9c>] warn_slowpath_fmt+0x4c/0x50
> > [ 1290.042589]  [<ffffffff814867c1>] dev_pm_domain_set+0x51/0x60

My Dell Latitude laptopi on next-20160201 is throwing a similar error
at shutdown, except the traceback continues:

mei_me_remove+0xbd/0xc0
pci_device_shutdown+0x32/0x50
device_shutdown+0xe2/0x210

(sorry, that's all I have, transcribing from one frame of video shot while
the system was shutting down....)



From rafael at kernel.org  Mon Feb  8 13:50:39 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 8 Feb 2016 22:50:39 +0100
Subject: [PATCH v12 2/4] PM / Domains: add setter for dev.pm_domain
In-Reply-To: <44858.1454967873@turing-police.cc.vt.edu>
References: <1452181575-9206-1-git-send-email-tomeu.vizoso@collabora.com>
 <CAHp75VdWPUZ8F5rsGn3M1e5Pgpcg1CErBej9PE_3+ZPke5CDFA@mail.gmail.com>
 <CAHp75Vf9TS-AxJALQjiwNjMCT8ct5SBanYzrEsV9aj=DsUw-OA@mail.gmail.com>
 <1783906.XctYjeUNLr@vostro.rjw.lan>
 <44858.1454967873@turing-police.cc.vt.edu>
Message-ID: <CAJZ5v0jUipo06fpSQsKi+5Po_32ntgc3Ns29=17SgQr2PSj+kA@mail.gmail.com>

On Mon, Feb 8, 2016 at 10:44 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Fri, 29 Jan 2016 22:35:18 +0100, "Rafael J. Wysocki" said:
>> > One more test unveils this one
>> >
>> > # modprobe -r sdhci-acpi
>> > [ 1289.909441] ------------[ cut here ]------------
>> > [ 1289.918205] WARNING: CPU: 1 PID: 4374 at
>> > /home/andy/prj/linux-otc/drivers/base/power/common.c:150
>> > dev_pm_domain_set+0x51/0x60()
>> > [ 1289.934681] PM domains can only be changed for unbound devices
>> > [ 1289.944843] Modules linked in: sdhci_acpi(-) sdhci mmc_core
>> > led_class [last unloaded: dw_dmac_core]
>> > [ 1289.958802] CPU: 1 PID: 4374 Comm: modprobe Not tainted 4.5.0-rc1+ #3
>> > [ 1289.969736]  ffffffff81c38330 ffff88007bb53d18 ffffffff8133162f
>> > ffff88007bb53d60
>> > [ 1289.981844]  ffff88007bb53d50 ffffffff8105cd12 ffff88017a007410
>> > 0000000000000000
>> > [ 1289.993996]  0000000000000001 0000000000000080 0000000000000000
>> > ffff88007bb53db0
>> > [ 1290.006123] Call Trace:
>> > [ 1290.012600]  [<ffffffff8133162f>] dump_stack+0x44/0x55
>> > [ 1290.022052]  [<ffffffff8105cd12>] warn_slowpath_common+0x82/0xc0
>> > [ 1290.032462]  [<ffffffff8105cd9c>] warn_slowpath_fmt+0x4c/0x50
>> > [ 1290.042589]  [<ffffffff814867c1>] dev_pm_domain_set+0x51/0x60
>
> My Dell Latitude laptopi on next-20160201 is throwing a similar error
> at shutdown, except the traceback continues:
>
> mei_me_remove+0xbd/0xc0
> pci_device_shutdown+0x32/0x50
> device_shutdown+0xe2/0x210
>
> (sorry, that's all I have, transcribing from one frame of video shot while
> the system was shutting down....)

This should be fixed in 4.5-rc3, so please retest.

Thanks,
Rafael


From sudeep.holla at arm.com  Mon Feb  8 13:55:12 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon,  8 Feb 2016 21:55:12 +0000
Subject: [PATCH] ARM: dts: rockchip: replace gpio-key,
 wakeup with wakeup-source property
Message-ID: <1454968512-11956-1-git-send-email-sudeep.holla@arm.com>

Keyboard driver for GPIO buttons(gpio-keys) checks for the legacy
"gpio-key,wakeup" boolean property to enable gpio buttons as wakeup
source.

Few dts files assign value "1" to gpio-key,wakeup and in one instance a
value "0" is assigned probably assuming it won't be enabled as a wakeup
source. Since the presence of the boolean property indicates it is
enabled, value of "0" have no value.

This patch replaces the legacy "gpio-key,wakeup" with the unified
"wakeup-source" property which inturn fixes the above mentioned issue.

Cc: linux-rockchip at lists.infradead.org
Reviewed-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
---
 arch/arm/boot/dts/rk3066a-bqcurie2.dts          | 3 +--
 arch/arm/boot/dts/rk3066a-rayeager.dts          | 2 +-
 arch/arm/boot/dts/rk3188-radxarock.dts          | 2 +-
 arch/arm/boot/dts/rk3288-evb.dtsi               | 2 +-
 arch/arm/boot/dts/rk3288-firefly.dtsi           | 2 +-
 arch/arm/boot/dts/rk3288-popmetal.dts           | 2 +-
 arch/arm/boot/dts/rk3288-r89.dts                | 2 +-
 arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 2 +-
 arch/arm/boot/dts/rk3288-veyron.dtsi            | 2 +-
 arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi    | 2 +-
 arch/arm64/boot/dts/rockchip/rk3368-r88.dts     | 2 +-
 11 files changed, 11 insertions(+), 12 deletions(-)

Hi Heiko,

You can reviewed this, however there are couple of ARM64 dts additions.
Also most of the other platform/SoC maintainers preferred to take it via
their tree and few of these got missed during v4.5 merge window.
Can you take it via your tree for v4.6 ?

Regards,
Sudeep

diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
index 38c91a839795..f92b46b7a6de 100644
--- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
+++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
@@ -74,7 +74,7 @@
 			linux,code = <116>;
 			label = "GPIO Key Power";
 			linux,input-type = <1>;
-			gpio-key,wakeup = <1>;
+			wakeup-source;
 			debounce-interval = <100>;
 		};
 		button at 1 {
@@ -82,7 +82,6 @@
 			linux,code = <104>;
 			label = "GPIO Key Vol-";
 			linux,input-type = <1>;
-			gpio-key,wakeup = <0>;
 			debounce-interval = <100>;
 		};
 		/* VOL+ comes somehow thru the ADC */
diff --git a/arch/arm/boot/dts/rk3066a-rayeager.dts b/arch/arm/boot/dts/rk3066a-rayeager.dts
index 341c1f87936a..3a493e407607 100644
--- a/arch/arm/boot/dts/rk3066a-rayeager.dts
+++ b/arch/arm/boot/dts/rk3066a-rayeager.dts
@@ -65,7 +65,7 @@
 		#size-cells = <0>;
 
 		button at 0 {
-			gpio-key,wakeup = <1>;
+			wakeup-source;
 			gpios = <&gpio6 2 GPIO_ACTIVE_LOW>;
 			label = "GPIO Power";
 			linux,code = <116>;
diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts b/arch/arm/boot/dts/rk3188-radxarock.dts
index 66fa87d1e2c2..0b6924c97b6b 100644
--- a/arch/arm/boot/dts/rk3188-radxarock.dts
+++ b/arch/arm/boot/dts/rk3188-radxarock.dts
@@ -63,7 +63,7 @@
 			linux,code = <116>;
 			label = "GPIO Key Power";
 			linux,input-type = <1>;
-			gpio-key,wakeup = <1>;
+			wakeup-source;
 			debounce-interval = <100>;
 		};
 	};
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi b/arch/arm/boot/dts/rk3288-evb.dtsi
index 4faabdb65868..78d47f7d2938 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -110,7 +110,7 @@
 			linux,code = <116>;
 			label = "GPIO Key Power";
 			linux,input-type = <1>;
-			gpio-key,wakeup = <1>;
+			wakeup-source;
 			debounce-interval = <100>;
 		};
 	};
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi b/arch/arm/boot/dts/rk3288-firefly.dtsi
index 4e3fd9aefe34..792ca4f2ebee 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -91,7 +91,7 @@
 		#size-cells = <0>;
 
 		button at 0 {
-			gpio-key,wakeup = <1>;
+			wakeup-source;
 			gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
 			label = "GPIO Power";
 			linux,code = <116>;
diff --git a/arch/arm/boot/dts/rk3288-popmetal.dts b/arch/arm/boot/dts/rk3288-popmetal.dts
index 65c475642d5a..2ff9689d2e1b 100644
--- a/arch/arm/boot/dts/rk3288-popmetal.dts
+++ b/arch/arm/boot/dts/rk3288-popmetal.dts
@@ -74,7 +74,7 @@
 			linux,code = <116>;
 			label = "GPIO Key Power";
 			linux,input-type = <1>;
-			gpio-key,wakeup = <1>;
+			wakeup-source;
 			debounce-interval = <100>;
 		};
 	};
diff --git a/arch/arm/boot/dts/rk3288-r89.dts b/arch/arm/boot/dts/rk3288-r89.dts
index 17f13c73fe5e..510a1d0d7abb 100644
--- a/arch/arm/boot/dts/rk3288-r89.dts
+++ b/arch/arm/boot/dts/rk3288-r89.dts
@@ -73,7 +73,7 @@
 			linux,code = <116>;
 			label = "GPIO Key Power";
 			linux,input-type = <1>;
-			gpio-key,wakeup = <1>;
+			wakeup-source;
 			debounce-interval = <100>;
 		};
 	};
diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
index 136d650dd05f..610769d99522 100644
--- a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
@@ -108,7 +108,7 @@
 	lid {
 		label = "Lid";
 		gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
-		gpio-key,wakeup;
+		wakeup-source;
 		linux,code = <0>; /* SW_LID */
 		linux,input-type = <5>; /* EV_SW */
 		debounce-interval = <1>;
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi b/arch/arm/boot/dts/rk3288-veyron.dtsi
index 9fce91ffff6f..420ba9b436a5 100644
--- a/arch/arm/boot/dts/rk3288-veyron.dtsi
+++ b/arch/arm/boot/dts/rk3288-veyron.dtsi
@@ -64,7 +64,7 @@
 			gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
 			debounce-interval = <100>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 	};
 
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi b/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi
index 8c219ccf67a3..6e27b22704df 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi
@@ -111,7 +111,7 @@
 		pinctrl-0 = <&pwr_key>;
 
 		button at 0 {
-			gpio-key,wakeup = <1>;
+			wakeup-source;
 			gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
 			label = "GPIO Power";
 			linux,code = <116>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
index 104cbee762bb..1f2b642e794a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
@@ -71,7 +71,7 @@
 		pinctrl-0 = <&pwr_key>;
 
 		button at 0 {
-			gpio-key,wakeup = <1>;
+			wakeup-source;
 			gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
 			label = "GPIO Power";
 			linux,code = <116>;
-- 
1.9.1



From sudeep.holla at arm.com  Mon Feb  8 13:55:35 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon,  8 Feb 2016 21:55:35 +0000
Subject: [PATCH] ARM: dts: spear: replace gpio-key,
 wakeup with wakeup-source property
Message-ID: <1454968535-11994-1-git-send-email-sudeep.holla@arm.com>

Keyboard driver for GPIO buttons(gpio-keys) checks for the legacy
"gpio-key,wakeup" boolean property to enable gpio buttons as wakeup
source.

Few dts files assign value "1" to gpio-key,wakeup which is incorrect.
Since the presence of the boolean property indicates it is enabled,
value of "0" or "1" have no significance.

This patch replaces the legacy "gpio-key,wakeup" with the unified
"wakeup-source" property which inturn fixes the above mentioned issue.

Reviewed-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
---
 arch/arm/boot/dts/spear1310-evb.dts | 2 +-
 arch/arm/boot/dts/spear1340-evb.dts | 2 +-
 arch/arm/boot/dts/spear320-hmi.dts  | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

Hi ARM-SoC guys,

This is the only platform which doesn't have regular pull request,
Viresh has acked it already. Can you pick this up directly for v4.6 ?

Regards,
Sudeep

diff --git a/arch/arm/boot/dts/spear1310-evb.dts b/arch/arm/boot/dts/spear1310-evb.dts
index e48857249ce7..84101e4eebbf 100644
--- a/arch/arm/boot/dts/spear1310-evb.dts
+++ b/arch/arm/boot/dts/spear1310-evb.dts
@@ -161,7 +161,7 @@
 				linux,code = <0x100>;
 				gpios = <&gpio0 7 0x4>;
 				debounce-interval = <20>;
-				gpio-key,wakeup = <1>;
+				wakeup-source;
 			};
 		};
 
diff --git a/arch/arm/boot/dts/spear1340-evb.dts b/arch/arm/boot/dts/spear1340-evb.dts
index c611f5606dfe..6565f3cb866f 100644
--- a/arch/arm/boot/dts/spear1340-evb.dts
+++ b/arch/arm/boot/dts/spear1340-evb.dts
@@ -223,7 +223,7 @@
 				linux,code = <0x100>;
 				gpios = <&gpio1 1 0x4>;
 				debounce-interval = <20>;
-				gpio-key,wakeup = <1>;
+				wakeup-source;
 			};
 		};
 
diff --git a/arch/arm/boot/dts/spear320-hmi.dts b/arch/arm/boot/dts/spear320-hmi.dts
index 0aa6fef5ce22..0d0da1f65f0e 100644
--- a/arch/arm/boot/dts/spear320-hmi.dts
+++ b/arch/arm/boot/dts/spear320-hmi.dts
@@ -141,7 +141,7 @@
 				linux,code = <0x100>;
 				gpios = <&stmpegpio 3 0x4>;
 				debounce-interval = <20>;
-				gpio-key,wakeup = <1>;
+				wakeup-source;
 			};
 
 			button at 2 {
@@ -149,7 +149,7 @@
 				linux,code = <0x200>;
 				gpios = <&stmpegpio 2 0x4>;
 				debounce-interval = <20>;
-				gpio-key,wakeup = <1>;
+				wakeup-source;
 			};
 		};
 
-- 
1.9.1



From sudeep.holla at arm.com  Mon Feb  8 13:55:43 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon,  8 Feb 2016 21:55:43 +0000
Subject: [PATCH] ARM: dts: tegra: replace legacy *,
 wakeup property with wakeup-source
Message-ID: <1454968543-12035-1-git-send-email-sudeep.holla@arm.com>

Though the keyboard and other driver will continue to support the legacy
"gpio-key,wakeup", "nvidia,wakeup-source" boolean property to enable the
wakeup source, "wakeup-source" is the new standard binding.

This patch replaces all the legacy wakeup properties with the unified
"wakeup-source" property in order to avoid any further copy-paste
duplication.

Cc: Stephen Warren <swarren at wwwdotorg.org>
Cc: Thierry Reding <thierry.reding at gmail.com>
Cc: Alexandre Courbot <gnurou at gmail.com>
Cc: linux-tegra at vger.kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
---
 arch/arm/boot/dts/tegra114-dalmore.dts         | 2 +-
 arch/arm/boot/dts/tegra114-roth.dts            | 2 +-
 arch/arm/boot/dts/tegra114-tn7.dts             | 2 +-
 arch/arm/boot/dts/tegra124-jetson-tk1.dts      | 2 +-
 arch/arm/boot/dts/tegra124-nyan.dtsi           | 4 ++--
 arch/arm/boot/dts/tegra124-venice2.dts         | 2 +-
 arch/arm/boot/dts/tegra20-harmony.dts          | 2 +-
 arch/arm/boot/dts/tegra20-paz00.dts            | 2 +-
 arch/arm/boot/dts/tegra20-seaboard.dts         | 4 ++--
 arch/arm/boot/dts/tegra20-trimslice.dts        | 2 +-
 arch/arm/boot/dts/tegra20-ventana.dts          | 2 +-
 arch/arm/boot/dts/tegra20-whistler.dts         | 2 +-
 arch/arm/boot/dts/tegra30-apalis-eval.dts      | 2 +-
 arch/arm/boot/dts/tegra30-cardhu.dtsi          | 2 +-
 arch/arm/boot/dts/tegra30-colibri-eval-v3.dts  | 2 +-
 arch/arm64/boot/dts/nvidia/tegra132-norrin.dts | 4 ++--
 16 files changed, 19 insertions(+), 19 deletions(-)

Hi Thierry/Stephen,

Most of the other platform/SoC maintainers preferred to take it via
their tree and few of these got missed during v4.5 merge window.
Can you take it via your tree for v4.6 ?

Regards,
Sudeep

diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index 8b7aa0dcdc6e..40b88051ea3e 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -1164,7 +1164,7 @@
 			label = "Power";
 			gpios = <&gpio TEGRA_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 
 		volume_down {
diff --git a/arch/arm/boot/dts/tegra114-roth.dts b/arch/arm/boot/dts/tegra114-roth.dts
index 38acf78d7815..9d868af97b8e 100644
--- a/arch/arm/boot/dts/tegra114-roth.dts
+++ b/arch/arm/boot/dts/tegra114-roth.dts
@@ -1047,7 +1047,7 @@
 			label = "Power";
 			gpios = <&gpio TEGRA_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/tegra114-tn7.dts b/arch/arm/boot/dts/tegra114-tn7.dts
index f91c2c9b2f94..89047edb5c5f 100644
--- a/arch/arm/boot/dts/tegra114-tn7.dts
+++ b/arch/arm/boot/dts/tegra114-tn7.dts
@@ -292,7 +292,7 @@
 			label = "Power";
 			gpios = <&gpio TEGRA_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 
 		volume_down {
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 66b4451eb2ca..067190532f78 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1761,7 +1761,7 @@
 			gpios = <&gpio TEGRA_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
 			debounce-interval = <10>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/tegra124-nyan.dtsi b/arch/arm/boot/dts/tegra124-nyan.dtsi
index ec1aa64ded68..c8495eb41fdd 100644
--- a/arch/arm/boot/dts/tegra124-nyan.dtsi
+++ b/arch/arm/boot/dts/tegra124-nyan.dtsi
@@ -509,7 +509,7 @@
 			linux,input-type = <5>;
 			linux,code = <KEY_RESERVED>;
 			debounce-interval = <1>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 
 		power {
@@ -517,7 +517,7 @@
 			gpios = <&gpio TEGRA_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
 			debounce-interval = <30>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
index cfbdf429b45d..4a5f23c5d893 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -975,7 +975,7 @@
 			gpios = <&gpio TEGRA_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
 			debounce-interval = <10>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index b926a07b9443..679f9c49e9f4 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -655,7 +655,7 @@
 			label = "Power";
 			gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index ed7e1009326c..fce397e3e2ce 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -521,7 +521,7 @@
 			label = "Power";
 			gpios = <&gpio TEGRA_GPIO(J, 7) GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index aea8994b35f2..a112a415ecd5 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -807,7 +807,7 @@
 			label = "Power";
 			gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 
 		lid {
@@ -816,7 +816,7 @@
 			linux,input-type = <5>; /* EV_SW */
 			linux,code = <0>; /* SW_LID */
 			debounce-interval = <1>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index d99af4ef9c64..a4aaff326f99 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -392,7 +392,7 @@
 			label = "Power";
 			gpios = <&gpio TEGRA_GPIO(X, 6) GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index 04c58e9ca490..b205935a1236 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -601,7 +601,7 @@
 			label = "Power";
 			gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/tegra20-whistler.dts b/arch/arm/boot/dts/tegra20-whistler.dts
index 340d81108df1..5564d6e975d8 100644
--- a/arch/arm/boot/dts/tegra20-whistler.dts
+++ b/arch/arm/boot/dts/tegra20-whistler.dts
@@ -508,7 +508,7 @@
 		nvidia,repeat-delay-ms = <160>;
 		nvidia,kbc-row-pins = <0 1 2>;
 		nvidia,kbc-col-pins = <16 17>;
-		nvidia,wakeup-source;
+		wakeup-source;
 		linux,keymap = <MATRIX_KEY(0x00, 0x00, KEY_POWER)
 				MATRIX_KEY(0x01, 0x00, KEY_HOME)
 				MATRIX_KEY(0x01, 0x01, KEY_BACK)
diff --git a/arch/arm/boot/dts/tegra30-apalis-eval.dts b/arch/arm/boot/dts/tegra30-apalis-eval.dts
index f2879cfcca62..3ca3b4c6975b 100644
--- a/arch/arm/boot/dts/tegra30-apalis-eval.dts
+++ b/arch/arm/boot/dts/tegra30-apalis-eval.dts
@@ -196,7 +196,7 @@
 			gpios = <&gpio TEGRA_GPIO(V, 1) GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_WAKEUP>;
 			debounce-interval = <10>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index bb1ca158273c..1714e755c3de 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -626,7 +626,7 @@
 			interrupts = <2 0>;
 			linux,code = <KEY_POWER>;
 			debounce-interval = <100>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 
 		volume-down {
diff --git a/arch/arm/boot/dts/tegra30-colibri-eval-v3.dts b/arch/arm/boot/dts/tegra30-colibri-eval-v3.dts
index 3ff019f47d00..72c79ac9a72f 100644
--- a/arch/arm/boot/dts/tegra30-colibri-eval-v3.dts
+++ b/arch/arm/boot/dts/tegra30-colibri-eval-v3.dts
@@ -142,7 +142,7 @@
 			gpios = <&gpio TEGRA_GPIO(V, 1) GPIO_ACTIVE_HIGH>;
 			linux,code = <KEY_WAKEUP>;
 			debounce-interval = <10>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 	};
 
diff --git a/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts b/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
index 7dfe1c085966..a5f365d67ca3 100644
--- a/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
@@ -971,7 +971,7 @@
 			linux,input-type = <5>;
 			linux,code = <0>;
 			debounce-interval = <1>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 
 		power {
@@ -979,7 +979,7 @@
 			gpios = <&gpio TEGRA_GPIO(Q, 0) GPIO_ACTIVE_LOW>;
 			linux,code = <KEY_POWER>;
 			debounce-interval = <10>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 	};
 
-- 
1.9.1



From sudeep.holla at arm.com  Mon Feb  8 13:55:53 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon,  8 Feb 2016 21:55:53 +0000
Subject: [PATCH] ARM: dts: am335x/am57xx: replace gpio-key,
 wakeup with wakeup-source property
Message-ID: <1454968553-12088-1-git-send-email-sudeep.holla@arm.com>

Commit 3efda00129bd ("ARM: dts: am335x: replace gpio-key,wakeup with
wakeup-source property") replaces all the legacy "gpio-key,wakeup" with
the unified  "wakeup-source" property to prevent any further copy-paste
duplication.

However couple of use of these legacy property sneaked in during the
merge window. This patch replaces them too.

Cc: "Beno?t Cousson" <bcousson at baylibre.com>
Cc: Tony Lindgren <tony at atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
---
 arch/arm/boot/dts/am335x-shc.dts          | 4 ++--
 arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

Hi Tony,

I see these files got introduced during v4.5 merge window and we could
not stop the copy-paste from the earlier versions files from which they
were copied.

Regards,
Sudeep

diff --git a/arch/arm/boot/dts/am335x-shc.dts b/arch/arm/boot/dts/am335x-shc.dts
index 1b5b044fcd91..865de8500f1c 100644
--- a/arch/arm/boot/dts/am335x-shc.dts
+++ b/arch/arm/boot/dts/am335x-shc.dts
@@ -46,7 +46,7 @@
 			gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
 			linux,code = <KEY_BACK>;
 			debounce-interval = <1000>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 
 		front_button {
@@ -54,7 +54,7 @@
 			gpios = <&gpio1 25 GPIO_ACTIVE_HIGH>;
 			linux,code = <KEY_FRONT>;
 			debounce-interval = <1000>;
-			gpio-key,wakeup;
+			wakeup-source;
 		};
 	};
 
diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index c53882643ae9..497eb07ced19 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -545,7 +545,7 @@
 		ti,debounce-tol = /bits/ 16 <10>;
 		ti,debounce-rep = /bits/ 16 <1>;
 
-		linux,wakeup;
+		wakeup-source;
 	};
 };
 
-- 
1.9.1



From sboyd at codeaurora.org  Mon Feb  8 14:01:59 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 8 Feb 2016 14:01:59 -0800
Subject: [GIT PULL] clk: tegra: Fixes for v4.5-rc3
In-Reply-To: <1454608362-8954-1-git-send-email-thierry.reding@gmail.com>
References: <1454608362-8954-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <20160208220159.GQ4848@codeaurora.org>

On 02/04, Thierry Reding wrote:
> From: Thierry Reding <treding at nvidia.com>
> 
> Hi Mike, Stephen,
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.5-clk-fixes
> 
> for you to fetch changes up to 5a1d5eff3ede4de4482015a9999336051054283f:
> 
>   clk: tegra: super: Fix sparse warnings for functions not declared as static (2016-02-02 15:49:34 +0100)
> 

Thanks, pulled.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From olof at lixom.net  Mon Feb  8 13:24:58 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Feb 2016 13:24:58 -0800
Subject: [GIT PULL] Renesas ARM Based SoC Defconfig Updates for v4.6
In-Reply-To: <cover.1454409855.git.horms+renesas@verge.net.au>
References: <cover.1454409855.git.horms+renesas@verge.net.au>
Message-ID: <20160208212458.GA25468@localhost>

On Tue, Feb 02, 2016 at 04:22:47PM +0100, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
> 
> Please consider these Renesas ARM based SoC defconfig updates for v4.6.
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-defconfig-for-v4.6
> 
> for you to fetch changes up to 20cc7dd4d03d912d28a642701f08c7dba8622436:
> 
>   ARM: multi_v7_defconfig: Enable XHCI_RCAR (2016-01-27 18:23:03 +0900)

Merged, thanks.

-Olof


From olof at lixom.net  Mon Feb  8 13:30:18 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Feb 2016 13:30:18 -0800
Subject: [PATCH] arm64: defconfig: Add Qualcomm sdhci and restart
 functionality
In-Reply-To: <1454581976-25364-1-git-send-email-georgi.djakov@linaro.org>
References: <1454581976-25364-1-git-send-email-georgi.djakov@linaro.org>
Message-ID: <20160208213018.GB25468@localhost>

On Thu, Feb 04, 2016 at 12:32:56PM +0200, Georgi Djakov wrote:
> Enable sdhci and restart functionality for devices based on msm8916 platform.
> Also increase the number of minors per block device to detect all available
> partitions.
> 
> Signed-off-by: Georgi Djakov <georgi.djakov at linaro.org>

What's this patch against? It doesn't apply on top of v4.5-rc3. Please rebase
against our next/arm64 branch and resend.


Thanks!


-Olof


From olof at lixom.net  Mon Feb  8 13:34:39 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Feb 2016 13:34:39 -0800
Subject: [PATCH] arm64: defconfig: add spmi and usb related configs
In-Reply-To: <1454742453-24157-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1454742453-24157-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <20160208213439.GC25468@localhost>

On Sat, Feb 06, 2016 at 07:07:33AM +0000, Srinivas Kandagatla wrote:
> This patch adds kconfigs for spmi bus support, pinctrl drivers and usb
> related to get USB working on Qualcomm DB410C board.
> 
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>


Applied to next/arm64, thanks.


-Olof


From olof at lixom.net  Mon Feb  8 13:36:21 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Feb 2016 13:36:21 -0800
Subject: [PATCH] ARM: drop unused Makefile.boot of Multiplatform SoCs
In-Reply-To: <20160208200324.GY19432@atomide.com>
References: <1454693808-13081-1-git-send-email-yamada.masahiro@socionext.com>
 <56B4E2B0.8060808@xilinx.com> <20160208200324.GY19432@atomide.com>
Message-ID: <20160208213621.GD25468@localhost>

On Mon, Feb 08, 2016 at 12:03:24PM -0800, Tony Lindgren wrote:
> * Michal Simek <michal.simek at xilinx.com> [160205 09:59]:
> > On 5.2.2016 18:36, Masahiro Yamada wrote:
> > > The variable "MACHINE" is empty if CONFIG_ARCH_MULTIPLATFORM=y,
> > > so these Makefile.boot files are never included.
> > > 
> > > Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
> > > ---
> > > 
> > >  arch/arm/mach-cns3xxx/Makefile.boot    | 3 ---
> > >  arch/arm/mach-exynos/Makefile.boot     | 2 --
> > >  arch/arm/mach-integrator/Makefile.boot | 4 ----
> > >  arch/arm/mach-keystone/Makefile.boot   | 1 -
> > >  arch/arm/mach-mmp/Makefile.boot        | 1 -
> > >  arch/arm/mach-mv78xx0/Makefile.boot    | 3 ---
> > >  arch/arm/mach-nspire/Makefile.boot     | 0
> > >  arch/arm/mach-omap2/Makefile.boot      | 3 ---
> > >  arch/arm/mach-orion5x/Makefile.boot    | 3 ---
> > >  arch/arm/mach-prima2/Makefile.boot     | 3 ---
> > >  arch/arm/mach-realview/Makefile.boot   | 9 ---------
> > >  arch/arm/mach-s3c64xx/Makefile.boot    | 2 --
> > >  arch/arm/mach-spear/Makefile.boot      | 3 ---
> > >  arch/arm/mach-u300/Makefile.boot       | 4 ----
> > >  arch/arm/mach-ux500/Makefile.boot      | 3 ---
> > >  arch/arm/mach-zynq/Makefile.boot       | 3 ---
> > 
> > Acked-by: Michal Simek <michal.simek at xilinx.com> (for Zynq)
> 
> I doubt anybody wants to go back to disabling MULTIPLATFORM:
> 
> Acked-by: Tony Lindgren <tony at atomide.com>

Agreed. I've applied to next/cleanup now.


-Olof


From olof at lixom.net  Mon Feb  8 13:36:45 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Feb 2016 13:36:45 -0800
Subject: [PATCH] ARM: integrator: remove redundant select in Kconfig
In-Reply-To: <1454693920-14794-1-git-send-email-yamada.masahiro@socionext.com>
References: <1454693920-14794-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <20160208213645.GE25468@localhost>

On Sat, Feb 06, 2016 at 02:38:40AM +0900, Masahiro Yamada wrote:
> All of these are already select'ed by ARCH_MULTIPLATFORM.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
> ---

Thanks, applied to next/cleanup.


-Olof


From olof at lixom.net  Mon Feb  8 13:37:05 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Feb 2016 13:37:05 -0800
Subject: [PATCH] ARM: netx: remove redundant "depends on ARCH_NETX"
In-Reply-To: <1454694197-15200-1-git-send-email-yamada.masahiro@socionext.com>
References: <1454694197-15200-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <20160208213705.GF25468@localhost>

On Sat, Feb 06, 2016 at 02:43:17AM +0900, Masahiro Yamada wrote:
> These options already reside inside the ARCH_NETX-dependent menu.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>

Thanks, applied to next/cleanup.


-Olof


From olof at lixom.net  Mon Feb  8 13:38:58 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Feb 2016 13:38:58 -0800
Subject: [PATCH V2 01/12] MAINTAINERS: Adding Maintainers for AMD Seattle
 Device Tree
In-Reply-To: <1454954357-8395-2-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
 <1454954357-8395-2-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <20160208213858.GG25468@localhost>

On Mon, Feb 08, 2016 at 11:59:06AM -0600, Suravee Suthikulpanit wrote:
> From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
> 
> Adding maintainers for AMD Seattle device tree.
> 
> Signed-off-by: Brijesh Singh <brijeshkumar.singh at amd.com>
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
> Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com>

Thanks, I've applied the series to next/dt64 now.


-Olof


From olof at lixom.net  Mon Feb  8 13:40:07 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Feb 2016 13:40:07 -0800
Subject: [GIT PULL] Renesas ARM Based SoC Cleanup for v4.6
In-Reply-To: <cover.1454595116.git.horms+renesas@verge.net.au>
References: <cover.1454595116.git.horms+renesas@verge.net.au>
Message-ID: <20160208214007.GH25468@localhost>

On Thu, Feb 04, 2016 at 03:29:34PM +0100, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
> 
> Please consider these Renesas ARM based SoC cleanup for v4.6.
> 
> These are all minor cleanups from Geert.
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-cleanup-for-v4.6
> 
> for you to fetch changes up to 2c7bdcfd8912ce47d8360017265713c5a110b9ed:
> 
>   ARM: shmobile: r8a7779: Remove remainings of removed SCU boot setup code (2016-02-02 15:06:30 +0100)


Thanks, merged into next/cleanup.


-Olof


From olof at lixom.net  Mon Feb  8 13:41:08 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Feb 2016 13:41:08 -0800
Subject: [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.6
In-Reply-To: <cover.1454595726.git.horms+renesas@verge.net.au>
References: <cover.1454595726.git.horms+renesas@verge.net.au>
Message-ID: <20160208214108.GI25468@localhost>

On Thu, Feb 04, 2016 at 03:29:44PM +0100, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
> 
> Please consider these Renesas ARM64 based SoC DT updates for v4.6.
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-dt-for-v4.6
> 
> for you to fetch changes up to a3fc85e27b7e3c29b30909929bc64737a19fd251:
> 
>   arm64: dts: salvator-x: Enable SCIF_CLK frequency and pins (2016-02-03 10:04:33 +0100)

Thanks, merged into next/dt64.


-Olof


From olof at lixom.net  Mon Feb  8 13:51:30 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Feb 2016 13:51:30 -0800
Subject: [GIT PULL] Renesas ARM Based SoC DT Updates for v4.6
In-Reply-To: <cover.1454595846.git.horms+renesas@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
Message-ID: <20160208215130.GJ25468@localhost>

Hi,

On Thu, Feb 04, 2016 at 03:30:02PM +0100, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
> 
> Please consider these Renesas ARM based SoC DT updates for v4.6.
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-for-v4.6
> 
> for you to fetch changes up to d7a11140d0a659e5c1f83627792f95b6713030a2:
> 
>   ARM: dts: silk: Enable SCIF_CLK frequency and pins (2016-02-02 14:02:28 +0100)
> 
> ----------------------------------------------------------------
> Renesas ARM Based SoC DT Updates for v4.6
> 
> * Use SCIF and USBHS fallback compatibility strings
> * Add Baud Rate Generator (BRG) support for (H)SCIF
> * Enable SCIF_CLK frequency and pins
> * Use GIC_* defines
> * Migrate to generic l2c OF initialization on r8a7740
> * Enable audio on r8a7793/gose
> * Enable HDMI vidio out on r8a7793
> * Enable i2c on r8a7793/gose
> * Enable QSPI on alt
> * Enable GPIO keys and leds on gise
> * Enable audio on porter
> * Enable DU on porter
> 
> ----------------------------------------------------------------
> Geert Uytterhoeven (22):
>       ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization
>       ARM: shmobile: r8a7740: Remove mapping of L2 cache controller registers

Hmm. Those aren't DT changes. There's also nothing for r8a7740 to convert
L2 init to DT earlier in this branch, which makes this look like it's just
a generic cleanup that should go in independently in your cleanup branch.

Or am I missing some dependency that isn't obvious? If I'm not, then please
respin this branch and move those to the place they belong (cleanup).

Thanks!



-Olof


From olof at lixom.net  Mon Feb  8 13:55:17 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Feb 2016 13:55:17 -0800
Subject: [GIT PULL] ARM: mvebu: drivers for v4.6 (#1)
In-Reply-To: <874mdj2scq.fsf@free-electrons.com>
References: <874mdj2scq.fsf@free-electrons.com>
Message-ID: <20160208215517.GM25468@localhost>

On Mon, Feb 08, 2016 at 03:23:49PM +0100, Gregory CLEMENT wrote:
> Hi,
> 
> Here is the first pull request for drivers for mvebu for v4.6.
> 
> Gregory
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/linux-mvebu.git tags/mvebu-drivers-4.6-1
> 
> for you to fetch changes up to 1e78dbe717b1668e1660556930d952447c7c1197:
> 
>   ARM: orion: implement ARM delay timer (2016-01-27 10:50:17 +0100)

Merged into next/soc.


Thanks!


-Olof


From olof at lixom.net  Mon Feb  8 13:53:53 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Feb 2016 13:53:53 -0800
Subject: [GIT PULL] ARM: mvebu: cleanup for v4.6 (#1)
In-Reply-To: <8760xz2sdi.fsf@free-electrons.com>
References: <8760xz2sdi.fsf@free-electrons.com>
Message-ID: <20160208215353.GL25468@localhost>

On Mon, Feb 08, 2016 at 03:23:21PM +0100, Gregory CLEMENT wrote:
> Hi,
> 
> Here is the first pull request for cleanup for mvebu for v4.6.
> 
> Gregory
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/linux-mvebu.git tags/mvebu-cleanup-4.6-1
> 
> for you to fetch changes up to 727c62d29c3a0b982fb72ef993db95e9d2036e07:
> 
>   ARM: mv78xx0: use "depends on" instead of "if" after prompt (2016-01-25 16:43:16 +0100)

Merged into next/cleanup. Thanks!


-Olof


From olof at lixom.net  Mon Feb  8 13:59:03 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Feb 2016 13:59:03 -0800
Subject: [GIT PULL] ARM: mvebu: dt for v4.6 (#1)
In-Reply-To: <8737t32saq.fsf@free-electrons.com>
References: <8737t32saq.fsf@free-electrons.com>
Message-ID: <20160208215903.GO25468@localhost>

Hi,

On Mon, Feb 08, 2016 at 03:25:01PM +0100, Gregory CLEMENT wrote:
> Hi,
> 
> Here is the first pull request for dt for mvebu for v4.6.
> This one is based on v4.5-rc3 because it depends on fixes merged
> previously.
> 
> Gregory
> 
> The following changes since commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95:
> 
>   Linux 4.5-rc3 (2016-02-07 15:38:30 -0800)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-4.6-1
> 
> for you to fetch changes up to ebe1adff92de94f1ec48a46d9afa74ba967674dc:
> 
>   ARM: dts: kirkwood: add device tree for buffalo linkstation ls-qvl (2016-02-08 09:39:41 +0100)
> 
> ----------------------------------------------------------------
> mvebu dt for 4.6 (part 1)
> 
> - Improve Armada 388 device tree (SATA and XHCI)
> - Fix SD Card and audio support for OpenRD board
> - Provide template for RS-232/485 configuration for the same board
> - Use a common dtsi file for linkstation boards
> - Add support for Buffalo Linkstation LS-QVL
> 
> ----------------------------------------------------------------
> Aaro Koskinen (4):
>       ARM: DTS: kirkwood-openrd: fix pin names for UART/SD selection
>       ARM: DTS: kirkwood-openrd: fix SD slot default configuration
>       ARM: DTS: kirkwood-openrd: provide template for RS-232/485 configuration
>       ARM: DTS: kirkwood-openrd-client: fix audio
> 
> Gregory CLEMENT (2):
>       ARM: mvebu: use usb-nop-xceiv PHY for the xhci nodes on Armada 388 GP
>       ARM: mvebu: Update the mpp63 function in the device tree on Armada 370
> 
> Mario Lange (1):
>       ARM: dts: kirkwood: add device tree for buffalo linkstation ls-qvl
> 
> Roger Shimizu (3):
>       ARM: dts: kirkwood: relicense dts of ls-wvl/vl and ls-wxl/wsxl under GPLv2/X11
>       ARM: dts: kirkwood: split lswxl dts to linkstation lswsxl and lswxl
>       ARM: dts: kirkwood: split lswvl dts to linkstation lsvl and lswvl
> 
> Thomas Petazzoni (2):
>       ARM: mvebu: adjust board name and compatible for Armada 388 GP
>       ARM: mvebu: use regulator-boot-on for SATA regulators on Armada 388 GP

You're using three different kind of ways to label the patches here, please use
the common one that we try to keep consistent across platforms:

ARM: dts: <platform>:...

Can you fixup and send a fresh pull request, please?


Thanks!


-Olof


From olof at lixom.net  Mon Feb  8 14:00:11 2016
From: olof at lixom.net (Olof Johansson)
Date: Mon, 8 Feb 2016 14:00:11 -0800
Subject: [GIT PULL] ARM: mvebu: defconfig for v4.6 (#1)
In-Reply-To: <871t8n2sa4.fsf@free-electrons.com>
References: <871t8n2sa4.fsf@free-electrons.com>
Message-ID: <20160208220011.GP25468@localhost>

On Mon, Feb 08, 2016 at 03:25:23PM +0100, Gregory CLEMENT wrote:
> Hi,
> 
> Here is the first pull request for defconfig for mvebu for v4.6.
> 
> Gregory
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/linux-mvebu.git tags/mvebu-defconfig-4.6-1
> 
> for you to fetch changes up to e1995f5586c9a60eefb188bc4ce3d4f37a6b835b:
> 
>   ARM: mvebu_v5_defconfig: Enable sound module needed for OpenRD (2016-01-26 09:40:58 +0100)

Applied, thanks.


-Olof


From dhdang at apm.com  Mon Feb  8 14:04:07 2016
From: dhdang at apm.com (Duc Dang)
Date: Mon,  8 Feb 2016 14:04:07 -0800
Subject: [PATCH v5 1/3] mailbox: Add support for APM X-Gene platform mailbox
 driver
In-Reply-To: <cover.1454967957.git.dhdang@apm.com>
References: <cover.1454967957.git.dhdang@apm.com>
Message-ID: <90cb13a0b4d3817c18c11c183128c08d6458bf8d.1454967957.git.dhdang@apm.com>

X-Gene mailbox controller provides 8 mailbox channels, with
each channel has a dedicated interrupt line.

Signed-off-by: Feng Kan <fkan at apm.com>
Signed-off-by: Duc Dang <dhdang at apm.com>
---
Changes since v4:
        - Rebase over v4.5-rc1
        - Fix section mistmatch warning by removing
        __init in slimpro_mbox_probe declaration
	- Correctly print channel number when
	there is no IRQ for that channel

Changes since v3:
        - Rebase over v4.4
        - Remove 'id' in slimpro_mbox_chan structure
        - Remove small functions that are only called once
        and fold them into the other callers
        - Remove void* pointer type cast
        - Relax the number of mailbox IRQs condition
        - Use subsys_initcall to guarantee mailbox driver
        will be registered before any other dependent driver
        is loaded.

 drivers/mailbox/Kconfig                 |   9 ++
 drivers/mailbox/Makefile                |   2 +
 drivers/mailbox/mailbox-xgene-slimpro.c | 264 ++++++++++++++++++++++++++++++++
 3 files changed, 275 insertions(+)
 create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 546d05f..678e434 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -85,4 +85,13 @@ config MAILBOX_TEST
 	  Test client to help with testing new Controller driver
 	  implementations.
 
+config XGENE_SLIMPRO_MBOX
+	tristate "APM SoC X-Gene SLIMpro Mailbox Controller"
+	depends on ARCH_XGENE
+	help
+	  An implementation of the APM X-Gene Interprocessor Communication
+	  Mailbox (IPCM) between the ARM 64-bit cores and SLIMpro controller.
+	  It is used to send short messages between ARM64-bit cores and
+	  the SLIMpro Management Engine, primarily for PM. Say Y here if you
+	  want to use the APM X-Gene SLIMpro IPCM support.
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 92435ef..b602ef8 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -17,3 +17,5 @@ obj-$(CONFIG_ALTERA_MBOX)	+= mailbox-altera.o
 obj-$(CONFIG_BCM2835_MBOX)	+= bcm2835-mailbox.o
 
 obj-$(CONFIG_STI_MBOX)		+= mailbox-sti.o
+
+obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c b/drivers/mailbox/mailbox-xgene-slimpro.c
new file mode 100644
index 0000000..0ea1eb8
--- /dev/null
+++ b/drivers/mailbox/mailbox-xgene-slimpro.c
@@ -0,0 +1,264 @@
+/*
+ * APM X-Gene SLIMpro MailBox Driver
+ *
+ * Copyright (c) 2015, Applied Micro Circuits Corporation
+ * Author: Feng Kan fkan at apm.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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/delay.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+
+#define MBOX_CON_NAME			"slimpro-mbox"
+#define MBOX_REG_SET_OFFSET		0x1000
+#define MBOX_CNT			8
+#define MBOX_STATUS_AVAIL_MASK		BIT(16)
+#define MBOX_STATUS_ACK_MASK		BIT(0)
+
+/* Configuration and Status Registers */
+#define REG_DB_IN		0x00
+#define REG_DB_DIN0		0x04
+#define REG_DB_DIN1		0x08
+#define REG_DB_OUT		0x10
+#define REG_DB_DOUT0		0x14
+#define REG_DB_DOUT1		0x18
+#define REG_DB_STAT		0x20
+#define REG_DB_STATMASK		0x24
+
+struct slimpro_mbox_chan {
+	struct device *dev;
+	struct mbox_chan *chan;
+	void __iomem *reg;
+	int irq;
+	u32 rx_msg[3];
+};
+
+struct slimpro_mbox {
+	struct mbox_controller mb_ctrl;
+	struct slimpro_mbox_chan mc[MBOX_CNT];
+	struct mbox_chan chans[MBOX_CNT];
+};
+
+static void mb_chan_send_msg(struct slimpro_mbox_chan *mb_chan, u32 *msg)
+{
+	writel(msg[1], mb_chan->reg + REG_DB_DOUT0);
+	writel(msg[2], mb_chan->reg + REG_DB_DOUT1);
+	writel(msg[0], mb_chan->reg + REG_DB_OUT);
+}
+
+static void mb_chan_recv_msg(struct slimpro_mbox_chan *mb_chan)
+{
+	mb_chan->rx_msg[1] = readl(mb_chan->reg + REG_DB_DIN0);
+	mb_chan->rx_msg[2] = readl(mb_chan->reg + REG_DB_DIN1);
+	mb_chan->rx_msg[0] = readl(mb_chan->reg + REG_DB_IN);
+}
+
+static int mb_chan_status_ack(struct slimpro_mbox_chan *mb_chan)
+{
+	u32 val = readl(mb_chan->reg + REG_DB_STAT);
+
+	if (val & MBOX_STATUS_ACK_MASK) {
+		writel(MBOX_STATUS_ACK_MASK, mb_chan->reg + REG_DB_STAT);
+		return 1;
+	}
+	return 0;
+}
+
+static int mb_chan_status_avail(struct slimpro_mbox_chan *mb_chan)
+{
+	u32 val = readl(mb_chan->reg + REG_DB_STAT);
+
+	if (val & MBOX_STATUS_AVAIL_MASK) {
+		mb_chan_recv_msg(mb_chan);
+		writel(MBOX_STATUS_AVAIL_MASK, mb_chan->reg + REG_DB_STAT);
+		return 1;
+	}
+	return 0;
+}
+
+static irqreturn_t slimpro_mbox_irq(int irq, void *id)
+{
+	struct slimpro_mbox_chan *mb_chan = id;
+
+	if (mb_chan_status_ack(mb_chan))
+		mbox_chan_txdone(mb_chan->chan, 0);
+
+	if (mb_chan_status_avail(mb_chan))
+		mbox_chan_received_data(mb_chan->chan, mb_chan->rx_msg);
+
+	return IRQ_HANDLED;
+}
+
+static int slimpro_mbox_send_data(struct mbox_chan *chan, void *msg)
+{
+	struct slimpro_mbox_chan *mb_chan = chan->con_priv;
+
+	mb_chan_send_msg(mb_chan, msg);
+	return 0;
+}
+
+static int slimpro_mbox_startup(struct mbox_chan *chan)
+{
+	struct slimpro_mbox_chan *mb_chan = chan->con_priv;
+	int rc;
+	u32 val;
+
+	rc = devm_request_irq(mb_chan->dev, mb_chan->irq, slimpro_mbox_irq, 0,
+			      MBOX_CON_NAME, mb_chan);
+	if (unlikely(rc)) {
+		dev_err(mb_chan->dev, "failed to register mailbox interrupt %d\n",
+			mb_chan->irq);
+		return rc;
+	}
+
+	/* Enable HW interrupt */
+	writel(MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK,
+	       mb_chan->reg + REG_DB_STAT);
+	/* Unmask doorbell status interrupt */
+	val = readl(mb_chan->reg + REG_DB_STATMASK);
+	val &= ~(MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK);
+	writel(val, mb_chan->reg + REG_DB_STATMASK);
+
+	return 0;
+}
+
+static void slimpro_mbox_shutdown(struct mbox_chan *chan)
+{
+	struct slimpro_mbox_chan *mb_chan = chan->con_priv;
+	u32 val;
+
+	/* Mask doorbell status interrupt */
+	val = readl(mb_chan->reg + REG_DB_STATMASK);
+	val |= (MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK);
+	writel(val, mb_chan->reg + REG_DB_STATMASK);
+
+	devm_free_irq(mb_chan->dev, mb_chan->irq, mb_chan);
+}
+
+static struct mbox_chan_ops slimpro_mbox_ops = {
+	.send_data = slimpro_mbox_send_data,
+	.startup = slimpro_mbox_startup,
+	.shutdown = slimpro_mbox_shutdown,
+};
+
+static int slimpro_mbox_probe(struct platform_device *pdev)
+{
+	struct slimpro_mbox *ctx;
+	struct resource *regs;
+	void __iomem *mb_base;
+	int rc;
+	int i;
+
+	ctx = devm_kzalloc(&pdev->dev, sizeof(struct slimpro_mbox), GFP_KERNEL);
+	if (IS_ERR(ctx))
+		return PTR_ERR(ctx);
+
+	platform_set_drvdata(pdev, ctx);
+
+	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mb_base = devm_ioremap(&pdev->dev, regs->start, resource_size(regs));
+	if (IS_ERR(mb_base))
+		return PTR_ERR(mb_base);
+
+	/* Setup mailbox links */
+	for (i = 0; i < MBOX_CNT; i++) {
+		ctx->mc[i].irq = platform_get_irq(pdev, i);
+		if (ctx->mc[i].irq < 0) {
+			if (i == 0) {
+				dev_err(&pdev->dev, "no available IRQ\n");
+				return -EINVAL;
+			}
+			dev_info(&pdev->dev, "no IRQ for channel %d\n", i);
+			break;
+		}
+
+		ctx->mc[i].dev = &pdev->dev;
+		ctx->mc[i].reg = mb_base + i * MBOX_REG_SET_OFFSET;
+		ctx->mc[i].chan = &ctx->chans[i];
+		ctx->chans[i].con_priv = &ctx->mc[i];
+	}
+
+	/* Setup mailbox controller */
+	ctx->mb_ctrl.dev = &pdev->dev;
+	ctx->mb_ctrl.chans = ctx->chans;
+	ctx->mb_ctrl.txdone_irq = true;
+	ctx->mb_ctrl.ops = &slimpro_mbox_ops;
+	ctx->mb_ctrl.num_chans = i;
+
+	rc = mbox_controller_register(&ctx->mb_ctrl);
+	if (rc) {
+		dev_err(&pdev->dev,
+			"APM X-Gene SLIMpro MailBox register failed:%d\n", rc);
+		return rc;
+	}
+
+	dev_info(&pdev->dev, "APM X-Gene SLIMpro MailBox registered\n");
+	return 0;
+}
+
+static int slimpro_mbox_remove(struct platform_device *pdev)
+{
+	struct slimpro_mbox *smb = platform_get_drvdata(pdev);
+
+	mbox_controller_unregister(&smb->mb_ctrl);
+	return 0;
+}
+
+static const struct of_device_id slimpro_of_match[] = {
+	{.compatible = "apm,xgene-slimpro-mbox" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, slimpro_of_match);
+
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id slimpro_acpi_ids[] = {
+	{"APMC0D01", 0},
+	{}
+};
+MODULE_DEVICE_TABLE(acpi, slimpro_acpi_ids);
+#endif
+
+static struct platform_driver slimpro_mbox_driver = {
+	.probe	= slimpro_mbox_probe,
+	.remove = slimpro_mbox_remove,
+	.driver	= {
+		.name = "xgene-slimpro-mbox",
+		.of_match_table = of_match_ptr(slimpro_of_match),
+		.acpi_match_table = ACPI_PTR(slimpro_acpi_ids)
+	},
+};
+
+static int __init slimpro_mbox_init(void)
+{
+	return platform_driver_register(&slimpro_mbox_driver);
+}
+
+static void __exit slimpro_mbox_exit(void)
+{
+	platform_driver_unregister(&slimpro_mbox_driver);
+}
+
+subsys_initcall(slimpro_mbox_init);
+module_exit(slimpro_mbox_exit);
+
+MODULE_DESCRIPTION("APM X-Gene SLIMpro Mailbox Driver");
+MODULE_LICENSE("GPL");
-- 
1.9.1



From dhdang at apm.com  Mon Feb  8 14:04:09 2016
From: dhdang at apm.com (Duc Dang)
Date: Mon,  8 Feb 2016 14:04:09 -0800
Subject: [PATCH v5 3/3] arm64: dts: mailbox device tree node for APM X-Gene
 platform.
In-Reply-To: <cover.1454967957.git.dhdang@apm.com>
References: <cover.1454967957.git.dhdang@apm.com>
Message-ID: <013f892a5bd86386dd379adc4870496dde8eb2a2.1454967957.git.dhdang@apm.com>

Mailbox device tree node for APM X-Gene platform.

Signed-off-by: Feng Kan <fkan at apm.com>
Signed-off-by: Duc Dang <dhdang at apm.com>
---
Changes since v4:
        - Rebase over v4.5-rc1
        - Change node name to mailbox at 10540000

Changes since v3:
        - Rebase over v4.4

 arch/arm64/boot/dts/apm/apm-storm.dtsi | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index fe30f76..d91338a 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -691,6 +691,20 @@
 			msi-parent = <&msi>;
 		};
 
+		mailbox: mailbox at 10540000 {
+			compatible = "apm,xgene-slimpro-mbox";
+			reg = <0x0 0x10540000 0x0 0xa000>;
+			#mbox-cells = <1>;
+			interrupts =    <0x0 0x0 0x4>,
+					<0x0 0x1 0x4>,
+					<0x0 0x2 0x4>,
+					<0x0 0x3 0x4>,
+					<0x0 0x4 0x4>,
+					<0x0 0x5 0x4>,
+					<0x0 0x6 0x4>,
+					<0x0 0x7 0x4>;
+		};
+
 		serial0: serial at 1c020000 {
 			status = "disabled";
 			device_type = "serial";
-- 
1.9.1



From dhdang at apm.com  Mon Feb  8 14:04:06 2016
From: dhdang at apm.com (Duc Dang)
Date: Mon,  8 Feb 2016 14:04:06 -0800
Subject: [PATCH v5 0/3] mailbox: Add APM X-Gene platform mailbox driver
In-Reply-To: <CABb+yY1cE152ZdfK_aeB8ufG=WfoUVB6BN8kXPphYgMBnpH-GA@mail.gmail.com>
References: <CABb+yY1cE152ZdfK_aeB8ufG=WfoUVB6BN8kXPphYgMBnpH-GA@mail.gmail.com>
Message-ID: <cover.1454967957.git.dhdang@apm.com>

APM X-Gene SoC has a mailbox controller that provides
communication mechanism for X-Gene Arm64 cores to communicate
with X-Gene SoC's Cortex M3 (SLIMpro) processor.

X-Gene mailbox controller provides 8 mailbox channels, with
each channel has a dedicated interrupt line.

Changes since v4:
        - Rebase over v4.5-rc1
        - Fix section mismatch warning during compiling
	- Correctly print channel number when there is
	no IRQ for that channel
        - Change node name to mailbox at 10540000
        - Correct the number of IRQs in documentation

Changes since v3:
        - Rebase over v4.4
        - Remove 'id' in slimpro_mbox_chan structure
        - Remove functions that are only called once
        and fold them into the other callers
        - Remove void* pointer type cast
        - Relax the number of mailbox IRQs condition
        - Fix error and address comment in documentation
        (xgene-slimpro-mailbox.txt)

Changes since v2:
        - Rebase Feng's patch set over v4.3-rc5
        - Remove uneccessary 'inline' in function definition
        - Use module_platform_driver instead of subsys_initcall
        - Minor coding stype clean up

Changes since v1:
        - Add ACPI support
        - Use defines for reg offset

Duc Dang (3):
  mailbox: Add support for APM X-Gene platform mailbox driver
  Documentation: mailbox: Add APM X-Gene SLIMpro mailbox dts
    documentation
  arm64: dts: mailbox device tree node for APM X-Gene platform.

 .../bindings/mailbox/xgene-slimpro-mailbox.txt     |  35 +++
 arch/arm64/boot/dts/apm/apm-storm.dtsi             |  14 ++
 drivers/mailbox/Kconfig                            |   9 +
 drivers/mailbox/Makefile                           |   2 +
 drivers/mailbox/mailbox-xgene-slimpro.c            | 264 +++++++++++++++++++++
 5 files changed, 324 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
 create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c

-- 
1.9.1



From dhdang at apm.com  Mon Feb  8 14:04:08 2016
From: dhdang at apm.com (Duc Dang)
Date: Mon,  8 Feb 2016 14:04:08 -0800
Subject: [PATCH v5 2/3] Documentation: mailbox: Add APM X-Gene SLIMpro mailbox
 dts documentation
In-Reply-To: <cover.1454967957.git.dhdang@apm.com>
References: <cover.1454967957.git.dhdang@apm.com>
Message-ID: <61df03dd1c014bf3b0a4a3fbef980665ce53d849.1454967957.git.dhdang@apm.com>

This adds the APM X-Gene SLIMpro mailbox device tree
node documentation.

Signed-off-by: Feng Kan <fkan at apm.com>
Signed-off-by: Duc Dang <dhdang at apm.com>
Acked-by: Rob Herring <robh at kernel.org>
---
Changes since v4:
        - Rebase over v4.5-rc1
        - Fix number of total interrupts in
        introduction text
        - Change node name to mailbox at 10540000

Changes since v3:
        - Rebase over v4.4
        - Change number of mailbox IRQs to 8
        - Fix white spaces, typos.

 .../bindings/mailbox/xgene-slimpro-mailbox.txt     | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt

diff --git a/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt b/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
new file mode 100644
index 0000000..e46451b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
@@ -0,0 +1,35 @@
+The APM X-Gene SLIMpro mailbox is used to communicate messages between
+the ARM64 processors and the Cortex M3 (dubbed SLIMpro). It uses a simple
+interrupt based door bell mechanism and can exchange simple messages using the
+internal registers.
+
+There are total of 8 interrupts in this mailbox. Each used for an individual
+door bell (or mailbox channel).
+
+Required properties:
+- compatible:	Should be as "apm,xgene-slimpro-mbox".
+
+- reg:		Contains the mailbox register address range.
+
+- interrupts:	8 interrupts must be from 0 to 7, interrupt 0 define the
+		the interrupt for mailbox channel 0 and interrupt 1 for
+		mailbox channel 1 and so likewise for the reminder.
+
+- #mbox-cells:	only one to specify the mailbox channel number.
+
+Example:
+
+Mailbox Node:
+		mailbox: mailbox at 10540000 {
+			compatible = "apm,xgene-slimpro-mbox";
+			reg = <0x0 0x10540000 0x0 0xa000>;
+			#mbox-cells = <1>;
+			interrupts =  	<0x0 0x0 0x4>,
+					<0x0 0x1 0x4>,
+					<0x0 0x2 0x4>,
+					<0x0 0x3 0x4>,
+					<0x0 0x4 0x4>,
+					<0x0 0x5 0x4>,
+					<0x0 0x6 0x4>,
+					<0x0 0x7 0x4>,
+		};
-- 
1.9.1



From helgaas at kernel.org  Mon Feb  8 14:12:04 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Mon, 8 Feb 2016 16:12:04 -0600
Subject: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for
 ThunderX-pass1 on-chip devices
In-Reply-To: <56B90B09.7090500@caviumnetworks.com>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
 <1454715675-17512-4-git-send-email-ddaney.cavm@gmail.com>
 <20160208195642.GA15103@rob-hp-laptop>
 <56B8FED6.1050804@caviumnetworks.com>
 <CAL_JsqJNndZ59465YhpkP=dQYaijaar+LcQG4KQEJwF5e1ryLQ@mail.gmail.com>
 <56B90B09.7090500@caviumnetworks.com>
Message-ID: <20160208221204.GA30821@localhost>

On Mon, Feb 08, 2016 at 01:39:21PM -0800, David Daney wrote:
> On 02/08/2016 01:12 PM, Rob Herring wrote:
> >On Mon, Feb 8, 2016 at 2:47 PM, David Daney <ddaney at caviumnetworks.com> wrote:
> >>On 02/08/2016 11:56 AM, Rob Herring wrote:
> >>>On Fri, Feb 05, 2016 at 03:41:15PM -0800, David Daney wrote:
> >>>>From: David Daney <david.daney at cavium.com>
> >
> >[...]
> >
> >>>>+Properties of the host controller node that differ from
> >>>>+host-generic-pci.txt:
> >>>>+
> >>>>+- compatible     : Must be "cavium,pci-host-thunder-ecam"
> >>>>+
> >>>>+Example:
> >>>>+
> >>>>+       pci at 84b0,00000000 {
> >>>
> >>>
> >>>Drop the comma,
> >>
> >>
> >>OK...
> >>
> >>>and the node name should be "pcie".
> >>>
> >>
> >>Why pcie?
> >>
> >>There are no PCIe devices or buses reachable from this type of root complex.
> >>There are however many PCI devices.
> >
> >I thought ECAM is a PCIe thing. If not, then nevermind.

The "ECAM" confusion bites again :)

> Well, Enhanced Configuration Access Mechanism (ECAM) is defined  the
> the PCI Express(R) base Specification, but it just defines a
> standard layout of address bits to memory map config space
> operations.  Since the PCI config space is a sub set of the PCIe
> config space, ECAM can also be used in PCI systems.
> 
> Really, it is a bit of a gray area here as we don't have any bridges
> to PCIe buses and there are multiple devices residing on each bus,
> so from that point of view it cannot be PCIe.  There are, however,
> devices that implement the PCI Express Capability structure, so does
> that make it PCIe?  It is not clear what the specifications demand
> here.

The PCI core doesn't care about the node name in the device tree.  But
it *does* care about some details of PCI/PCIe topology.  We consider
anything with a PCIe capability to be PCIe.  For example,

  - pci_cfg_space_size() thinks PCIe devices have 4K of config space

  - only_one_child() thinks a PCIe bus, i.e., a link, only has a
    single device on it

  - a PCIe device should have a PCIe Root Port or PCIe Downstream Port
    upstream from it (we did remove some of these restrictions with
    b35b1df5e6c2 ("PCI: Tolerate hierarchies with no Root Port"), but 
    it's possible we didn't get them all)

I assume your system conforms to expectations like these; I'm just
pointing them out because you mentioned buses with multiple devices on
them, which is definitely something one doesn't expect in PCIe.

Bjorn


From sboyd at codeaurora.org  Mon Feb  8 14:13:35 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 8 Feb 2016 14:13:35 -0800
Subject: [PATCH] clk: socfpga: fix __init annotation
In-Reply-To: <1454942356-2783135-1-git-send-email-arnd@arndb.de>
References: <1454942356-2783135-1-git-send-email-arnd@arndb.de>
Message-ID: <20160208221335.GS4848@codeaurora.org>

On 02/08, Arnd Bergmann wrote:
> clang found a bug with the __socfpga_pll_init definition:
> 
> drivers/clk/socfpga/clk-pll-a10.c:77:15: error: '__section__' attribute only applies to functions and
>       global variables
> 
> This moves the __init annotation to the right place so the function
> actually gets discarded.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From sboyd at codeaurora.org  Mon Feb  8 14:15:08 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 8 Feb 2016 14:15:08 -0800
Subject: [PATCH] clk: meson: Fix meson_clk_register_clks() signature type
 mismatch
In-Reply-To: <1454879583-27036-1-git-send-email-afaerber@suse.de>
References: <1454879583-27036-1-git-send-email-afaerber@suse.de>
Message-ID: <20160208221508.GT4848@codeaurora.org>

On 02/07, Andreas F?rber wrote:
> As preparation for arm64 based mesongxbb, which pulls in this code once
> enabling ARCH_MESON, fix a size_t vs. unsigned int type mismatch.
> The loop uses a local unsigned int variable, so adopt that type,
> matching the header.
> 
> Fixes: 7a29a869434e ("clk: meson: Add support for Meson clock controller")
> Signed-off-by: Andreas F?rber <afaerber at suse.de>
> ---

Applied to clk-next. It would have been nice to have the
compilation error though

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From afaerber at suse.de  Mon Feb  8 14:22:06 2016
From: afaerber at suse.de (=?UTF-8?Q?Andreas_F=c3=a4rber?=)
Date: Mon, 8 Feb 2016 23:22:06 +0100
Subject: [PATCH] clk: meson: Fix meson_clk_register_clks() signature type
 mismatch
In-Reply-To: <20160208221508.GT4848@codeaurora.org>
References: <1454879583-27036-1-git-send-email-afaerber@suse.de>
 <20160208221508.GT4848@codeaurora.org>
Message-ID: <56B9150E.5010808@suse.de>

Am 08.02.2016 um 23:15 schrieb Stephen Boyd:
> On 02/07, Andreas F?rber wrote:
>> As preparation for arm64 based mesongxbb, which pulls in this code once
>> enabling ARCH_MESON, fix a size_t vs. unsigned int type mismatch.
>> The loop uses a local unsigned int variable, so adopt that type,
>> matching the header.
>>
>> Fixes: 7a29a869434e ("clk: meson: Add support for Meson clock controller")
>> Signed-off-by: Andreas F?rber <afaerber at suse.de>
>> ---
> 
> Applied to clk-next. It would have been nice to have the
> compilation error though

Ask and you shall receive:

  CC      drivers/clk/meson/clkc.o
drivers/clk/meson/clkc.c:200:13: error: conflicting types for
'meson_clk_register_clks'
 void __init meson_clk_register_clks(const struct clk_conf *clk_confs,
             ^
In file included from drivers/clk/meson/clkc.c:22:0:
drivers/clk/meson/clkc.h:180:6: note: previous declaration of
'meson_clk_register_clks' was here
 void meson_clk_register_clks(const struct clk_conf *clk_confs,
      ^
scripts/Makefile.build:258: recipe for target 'drivers/clk/meson/clkc.o'
failed
make[3]: *** [drivers/clk/meson/clkc.o] Error 1
scripts/Makefile.build:407: recipe for target 'drivers/clk/meson' failed
make[2]: *** [drivers/clk/meson] Error 2
scripts/Makefile.build:407: recipe for target 'drivers/clk' failed
make[1]: *** [drivers/clk] Error 2
Makefile:959: recipe for target 'drivers' failed
make: *** [drivers] Error 2

Not really telling, is it. ;)

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N?rnberg)


From heiko at sntech.de  Mon Feb  8 14:21:57 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 08 Feb 2016 23:21:57 +0100
Subject: [PATCH v7 0/9] Fix broken DMAFLUSHP on Rockchips platform
In-Reply-To: <20160208131419.GA19598@localhost>
References: <1453460812-8498-1-git-send-email-wxt@rock-chips.com>
 <3817335.PXCk0JfYDT@phil> <20160208131419.GA19598@localhost>
Message-ID: <2223201.4nEkyUQu1O@phil>

Hi Vinod,

Am Montag, 8. Februar 2016, 18:44:19 schrieb Vinod Koul:
> On Mon, Feb 08, 2016 at 10:27:04AM +0100, Heiko Stuebner wrote:
> > Am Montag, 8. Februar 2016, 08:41:34 schrieb Vinod Koul:
> > > On Mon, Feb 01, 2016 at 02:56:54PM +0800, Caesar Wang wrote:
> > > > Hello Vinod,
> > > > 
> > > > Is there any chance apply the DMA patches?:-)
> > > 
> > > I was waiting for any ACKs on ARM patches before I merge this series.
> > 
> > I think the more regular way is for the driver maintainer to take the
> > driver-specific stuff and the devicetree parts going through the
> > specific arm- tree. But if you really want to take the whole series,
> > for patches 4,5,6
> Yes but that causes cross tree dependencies, which looking at this won't
> be a big problem, so I can safely merge dmaengine changes and rest can go
> thru ARM tree.
> 
> Typically submitter should say which tree he/she prefers, which was not
> provided..
> 
> So, are all okay to merge the entire series thru dmaengine tree or
> independent. I don't mind either

In general I don't mind either solution, but would prefer me taking the 3 
"ARM: dts: foo" patches, while the rest would go through your tree.

Main reason is to prevent any possible conflicts with other Rockchip 
devicetree additions also going into 4.6 .


Thanks
Heiko

> > - ARM: dts: Add arm, pl330-broken-no-flushp quirk for rk3288 platform
> > - ARM: dts: Add arm, pl330-broken-no-flushp quirk for rk3xxx platform
> > - ARM: dts: add pl330-broken-no-flushp quirk for rk3036 SoCs
> > 
> > Acked-by: Heiko Stuebner <heiko at sntech.de>
> 
> Thanks



From rjw at rjwysocki.net  Mon Feb  8 14:25:37 2016
From: rjw at rjwysocki.net (Rafael J. Wysocki)
Date: Mon, 08 Feb 2016 23:25:37 +0100
Subject: [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen
In-Reply-To: <alpine.DEB.2.02.1602081054350.27008@kaball.uk.xensource.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
 <CAJZ5v0id-035AtyQ_SccPuCxD7+pa6GCgj3WBAojM+rFqssGQQ@mail.gmail.com>
 <alpine.DEB.2.02.1602081054350.27008@kaball.uk.xensource.com>
Message-ID: <2213954.ztOe55fprN@vostro.rjw.lan>

On Monday, February 08, 2016 10:57:01 AM Stefano Stabellini wrote:
> On Sat, 6 Feb 2016, Rafael J. Wysocki wrote:
> > On Fri, Feb 5, 2016 at 4:05 AM, Shannon Zhao <zhaoshenglong at huawei.com> wrote:
> > > From: Shannon Zhao <shannon.zhao at linaro.org>
> > >
> > > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > > UART is used by Xen. So here it hides UART from Dom0.
> > >
> > > Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> > > Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> > 
> > Well, this doesn't look right to me.
> > 
> > We need to find a nicer way to achieve what you want.
> 
> I take that you are talking about how to honor the STAO table in Linux.
> Do you have any concrete suggestions?

I do.

The last hunk of the patch is likely what it needs to be, although I'm
not sure if the place it is added to is the right one.  That's a minor thing,
though.

The other part is problematic.  Not that as it doesn't work, but because of
how it works.  With these changes the device will be visible to the OS (in
fact to user space even), but will never be "present".  I'm not sure if
that's what you want?

It might be better to add a check to acpi_bus_type_and_status() that will
evaluate the "should ignore?" thing and return -ENODEV if this is true.  This
way the device won't be visible at all.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


From sboyd at codeaurora.org  Mon Feb  8 14:26:37 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 8 Feb 2016 14:26:37 -0800
Subject: [PATCH 0/2] CREG clk driver for NXP LPC18xx family
In-Reply-To: <1436651307-24098-1-git-send-email-manabian@gmail.com>
References: <1436651307-24098-1-git-send-email-manabian@gmail.com>
Message-ID: <20160208222637.GV4848@codeaurora.org>

On 07/11, Joachim Eastwood wrote:
> This patch set adds a clk driver for the low power clocks found in
> the CREG block on lpc18xx. CREG is a collection of miscellaneous
> configuration registers that can be accessed through a syscon
> regmap interface. The clk driver makes it possible to setup and
> enabled these two clocks.
> 
> This need to support peripherals like the internal RTC on the
> lpc18xx platform.
> 

I know this is many months old, but is this driver still
required? I can apply it to clk-next if so.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From ddaney at caviumnetworks.com  Mon Feb  8 14:41:41 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Mon, 8 Feb 2016 14:41:41 -0800
Subject: [PATCH v5 3/3] pci,
 pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices
In-Reply-To: <20160208221204.GA30821@localhost>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
 <1454715675-17512-4-git-send-email-ddaney.cavm@gmail.com>
 <20160208195642.GA15103@rob-hp-laptop> <56B8FED6.1050804@caviumnetworks.com>
 <CAL_JsqJNndZ59465YhpkP=dQYaijaar+LcQG4KQEJwF5e1ryLQ@mail.gmail.com>
 <56B90B09.7090500@caviumnetworks.com> <20160208221204.GA30821@localhost>
Message-ID: <56B919A5.5090000@caviumnetworks.com>

On 02/08/2016 02:12 PM, Bjorn Helgaas wrote:
> On Mon, Feb 08, 2016 at 01:39:21PM -0800, David Daney wrote:
>> On 02/08/2016 01:12 PM, Rob Herring wrote:
>>> On Mon, Feb 8, 2016 at 2:47 PM, David Daney <ddaney at caviumnetworks.com> wrote:
>>>> On 02/08/2016 11:56 AM, Rob Herring wrote:
>>>>> On Fri, Feb 05, 2016 at 03:41:15PM -0800, David Daney wrote:
>>>>>> From: David Daney <david.daney at cavium.com>
>>>
>>> [...]
>>>
>>>>>> +Properties of the host controller node that differ from
>>>>>> +host-generic-pci.txt:
>>>>>> +
>>>>>> +- compatible     : Must be "cavium,pci-host-thunder-ecam"
>>>>>> +
>>>>>> +Example:
>>>>>> +
>>>>>> +       pci at 84b0,00000000 {
>>>>>
>>>>>
>>>>> Drop the comma,
>>>>
>>>>
>>>> OK...
>>>>
>>>>> and the node name should be "pcie".
>>>>>
>>>>
>>>> Why pcie?
>>>>
>>>> There are no PCIe devices or buses reachable from this type of root complex.
>>>> There are however many PCI devices.
>>>
>>> I thought ECAM is a PCIe thing. If not, then nevermind.
>
> The "ECAM" confusion bites again :)
>
>> Well, Enhanced Configuration Access Mechanism (ECAM) is defined  the
>> the PCI Express(R) base Specification, but it just defines a
>> standard layout of address bits to memory map config space
>> operations.  Since the PCI config space is a sub set of the PCIe
>> config space, ECAM can also be used in PCI systems.
>>
>> Really, it is a bit of a gray area here as we don't have any bridges
>> to PCIe buses and there are multiple devices residing on each bus,
>> so from that point of view it cannot be PCIe.  There are, however,
>> devices that implement the PCI Express Capability structure, so does
>> that make it PCIe?  It is not clear what the specifications demand
>> here.
>
> The PCI core doesn't care about the node name in the device tree.  But
> it *does* care about some details of PCI/PCIe topology.  We consider
> anything with a PCIe capability to be PCIe.  For example,
>
>    - pci_cfg_space_size() thinks PCIe devices have 4K of config space
>
>    - only_one_child() thinks a PCIe bus, i.e., a link, only has a
>      single device on it
>
>    - a PCIe device should have a PCIe Root Port or PCIe Downstream Port
>      upstream from it (we did remove some of these restrictions with
>      b35b1df5e6c2 ("PCI: Tolerate hierarchies with no Root Port"), but
>      it's possible we didn't get them all)
>
> I assume your system conforms to expectations like these; I'm just
> pointing them out because you mentioned buses with multiple devices on
> them, which is definitely something one doesn't expect in PCIe.
>

The topology we have is currently working with the kernel's core PCI 
code.  I don't really want to get into discussing what the definition of 
PCIe is.  We have multiple devices (more than 32) on a single bus, and 
they have PCI Express and ARI Capabilities.  Is that PCIe?  I don't know.

For the purpose of naming the device tree node, I would like to stick 
with the name "pci at ..." as it is somewhat accurate, a value contemplated 
by the device tree specifications, ignored by the kernel code, and 
already implemented.

David Daney


> Bjorn
>



From sboyd at codeaurora.org  Mon Feb  8 14:43:28 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 8 Feb 2016 14:43:28 -0800
Subject: [PATCH v3 5/6] dts: ipq4019: Add support for IPQ4019 DK01 board
In-Reply-To: <1447975173-29485-6-git-send-email-mmcclint@qca.qualcomm.com>
References: <1447975173-29485-1-git-send-email-mmcclint@qca.qualcomm.com>
 <1447975173-29485-6-git-send-email-mmcclint@qca.qualcomm.com>
Message-ID: <20160208224328.GB10791@codeaurora.org>

On 11/19, Matthew McClintock wrote:
> +
> +/ {
> +	model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK01.1";
> +	compatible = "qcom,ipq4019";
> +
> +	clocks {
> +                xo: xo {
> +                        compatible = "fixed-clock";
> +                        clock-frequency = <48000000>;
> +                        #clock-cells = <0>;
> +                };
> +	};

Is there a reason the xo is here and the sleep clk is in the SoC
dtsi file? Both are board clocks so I would think they would be
added in the same place.

> +
> +	soc {
> +
> +
> +		timer {
> +			compatible = "arm,armv7-timer";
> +			interrupts = <1 2 0xf08>,
> +				     <1 3 0xf08>,
> +				     <1 4 0xf08>,
> +				     <1 1 0xf08>;
> +			clock-frequency = <48000000>;
> +		};

The timer shouldn't be part of the SoC node (it has no reg property).

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From sboyd at codeaurora.org  Mon Feb  8 14:45:03 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 8 Feb 2016 14:45:03 -0800
Subject: [PATCH v3 4/6] qcom: ipq4019: Add basic board/dts support for
 IPQ4019 SoC
In-Reply-To: <1447975173-29485-5-git-send-email-mmcclint@qca.qualcomm.com>
References: <1447975173-29485-1-git-send-email-mmcclint@qca.qualcomm.com>
 <1447975173-29485-5-git-send-email-mmcclint@qca.qualcomm.com>
Message-ID: <20160208224503.GC10791@codeaurora.org>

On 11/19, Matthew McClintock wrote:
> +
> +/ {
> +
> +	clocks {
> +		sleep_clk: sleep_clk {
> +			compatible = "fixed-clock";
> +			clock-frequency = <32768>;
> +			#clock-cells = <0>;
> +		};
> +	};

The timer should be right here in the SoC file.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From sergei.shtylyov at cogentembedded.com  Mon Feb  8 14:55:58 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 09 Feb 2016 01:55:58 +0300
Subject: [PATCH 0/5] Add R8A7794 sound DT support
Message-ID: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>

Hello.

   Here's the set of 5 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20160208-v4.5-rc3' tag. I'm adding the sound device tree support
for the R8A7794 SoC. The sound patch for the SILK board will be posted RSN. :-)

[1/5] ARM: dts: r8a7794: add audio clocks
[2/5] ARM: dts: r8a7794: add MSTP5 clocks
[3/5] ARM: dts: r8a7794: add MSTP10 clocks
[4/5] ARM: dts: r8a7794: add Audio-DMAC support
[5/5] ARM: dts: r8a7794 add sound support

WBR, Sergei



From sergei.shtylyov at cogentembedded.com  Mon Feb  8 14:57:22 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 09 Feb 2016 01:57:22 +0300
Subject: [PATCH 1/5] ARM: dts: r8a7794: add audio clocks
In-Reply-To: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>
References: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>
Message-ID: <1840385.PK7TPc1Pyy@wasted.cogentembedded.com>

Describe the external audio clocks (signals AUDIO_CLK[ABC]) required by
the sound driver. Boards that provide audio clocks need to override the
clock frequencies.

This patch is based on the commit 0d3dbde84a45 ("ARM: shmobile: r8a7791:
add  audio clock on DTSI").

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/boot/dts/r8a7794.dtsi |   24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -833,6 +833,30 @@
 			status = "disabled";
 		};
 
+		/*
+		 * The external audio clocks are configured  as 0 Hz fixed
+		 * frequency clocks by default.  Boards that provide audio
+		 * clocks should override them.
+		 */
+		audio_clka: audio_clka {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+			clock-output-names = "audio_clka";
+		};
+		audio_clkb: audio_clkb {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+			clock-output-names = "audio_clkb";
+		};
+		audio_clkc: audio_clkc {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+			clock-output-names = "audio_clkc";
+		};
+
 		/* Special CPG clocks */
 		cpg_clocks: cpg_clocks at e6150000 {
 			compatible = "renesas,r8a7794-cpg-clocks",



From sergei.shtylyov at cogentembedded.com  Mon Feb  8 14:58:20 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 09 Feb 2016 01:58:20 +0300
Subject: [PATCH 2/5] ARM: dts: r8a7794: add MSTP5 clocks
In-Reply-To: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>
References: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>
Message-ID: <5774819.Zu4cvUL4gZ@wasted.cogentembedded.com>

Add some MSTP5 clocks to R8A7794 device tree.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/boot/dts/r8a7794.dtsi            |    9 +++++++++
 include/dt-bindings/clock/r8a7794-clock.h |    1 +
 2 files changed, 10 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -1105,6 +1105,15 @@
 			clock-indices = <R8A7794_CLK_IRQC>;
 			clock-output-names = "irqc";
 		};
+		mstp5_clks: mstp5_clks at e6150144 {
+			compatible = "renesas,r8a7794-mstp-clocks", "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150144 0 4>, <0 0xe615003c 0 4>;
+			clocks = <&hp_clk>, <&extal_clk>, <&p_clk>;
+			#clock-cells = <1>;
+			clock-indices = <R8A7794_CLK_AUDIO_DMAC0
+					 R8A7794_CLK_THERMAL R8A7794_CLK_PWM>;
+			clock-output-names = "audmac0", "thermal", "pwm";
+		};
 		mstp7_clks: mstp7_clks at e615014c {
 			compatible = "renesas,r8a7794-mstp-clocks", "renesas,cpg-mstp-clocks";
 			reg = <0 0xe615014c 0 4>, <0 0xe61501c4 0 4>;
Index: renesas/include/dt-bindings/clock/r8a7794-clock.h
===================================================================
--- renesas.orig/include/dt-bindings/clock/r8a7794-clock.h
+++ renesas/include/dt-bindings/clock/r8a7794-clock.h
@@ -64,6 +64,7 @@
 #define R8A7794_CLK_IRQC		7
 
 /* MSTP5 */
+#define R8A7794_CLK_AUDIO_DMAC0		2
 #define R8A7794_CLK_THERMAL		22
 #define R8A7794_CLK_PWM			23
 



From sergei.shtylyov at cogentembedded.com  Mon Feb  8 14:59:23 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 09 Feb 2016 01:59:23 +0300
Subject: [PATCH 3/5] ARM: dts: r8a7794: add MSTP10 clocks
In-Reply-To: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>
References: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>
Message-ID: <9117518.oomsaSkM7k@wasted.cogentembedded.com>

Add MSTP10 clocks to R8A7790 device tree.

This patch is based on the commit ee9141522dcf ("ARM: shmobile: r8a7791:
add MSTP10 support on DTSI").

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/boot/dts/r8a7794.dtsi            |   53 ++++++++++++++++++++++++++++++
 include/dt-bindings/clock/r8a7794-clock.h |   28 +++++++++++++++
 2 files changed, 81 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -1165,6 +1165,59 @@
 				"gpio1", "gpio0", "qspi_mod",
 				"i2c5", "i2c4", "i2c3", "i2c2", "i2c1", "i2c0";
 		};
+		mstp10_clks: mstp10_clks at e6150998 {
+			compatible = "renesas,r8a7794-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>;
+			clocks = <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+				 <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+				 <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>;
+			#clock-cells = <1>;
+			clock-indices = <R8A7794_CLK_SSI_ALL
+					 R8A7794_CLK_SSI9 R8A7794_CLK_SSI8
+					 R8A7794_CLK_SSI7 R8A7794_CLK_SSI6
+					 R8A7794_CLK_SSI5 R8A7794_CLK_SSI4
+					 R8A7794_CLK_SSI3 R8A7794_CLK_SSI2
+					 R8A7794_CLK_SSI1 R8A7794_CLK_SSI0
+					 R8A7794_CLK_SCU_ALL
+					 R8A7794_CLK_SCU_DVC1
+					 R8A7794_CLK_SCU_DVC0
+					 R8A7794_CLK_SCU_CTU1_MIX1
+					 R8A7794_CLK_SCU_CTU0_MIX0
+					 R8A7794_CLK_SCU_SRC9
+					 R8A7794_CLK_SCU_SRC8
+					 R8A7794_CLK_SCU_SRC7
+					 R8A7794_CLK_SCU_SRC6
+					 R8A7794_CLK_SCU_SRC5
+					 R8A7794_CLK_SCU_SRC4
+					 R8A7794_CLK_SCU_SRC3
+					 R8A7794_CLK_SCU_SRC2
+					 R8A7794_CLK_SCU_SRC1
+					 R8A7794_CLK_SCU_SRC0>;
+			clock-output-names = "ssi-all", "ssi9", "ssi8", "ssi7",
+					     "ssi6", "ssi5", "ssi4", "ssi3",
+					     "ssi2", "ssi1", "ssi0",
+					     "scu-all", "scu-dvc1", "scu-dvc0",
+					     "scu-ctu1-mix1", "scu-ctu0-mix0",
+					     "scu-src9", "scu-src8", "scu-src7",
+					     "scu-src6", "scu-src5", "scu-src4",
+					     "scu-src3", "scu-src2", "scu-src1",
+					     "scu-src0";
+		};
 		mstp11_clks: mstp11_clks at e615099c {
 			compatible = "renesas,r8a7794-mstp-clocks", "renesas,cpg-mstp-clocks";
 			reg = <0 0xe615099c 0 4>, <0 0xe61509ac 0 4>;
Index: renesas/include/dt-bindings/clock/r8a7794-clock.h
===================================================================
--- renesas.orig/include/dt-bindings/clock/r8a7794-clock.h
+++ renesas/include/dt-bindings/clock/r8a7794-clock.h
@@ -103,6 +103,34 @@
 #define R8A7794_CLK_I2C1		30
 #define R8A7794_CLK_I2C0		31
 
+/* MSTP10 */
+#define R8A7794_CLK_SSI_ALL		5
+#define R8A7794_CLK_SSI9		6
+#define R8A7794_CLK_SSI8		7
+#define R8A7794_CLK_SSI7		8
+#define R8A7794_CLK_SSI6		9
+#define R8A7794_CLK_SSI5		10
+#define R8A7794_CLK_SSI4		11
+#define R8A7794_CLK_SSI3		12
+#define R8A7794_CLK_SSI2		13
+#define R8A7794_CLK_SSI1		14
+#define R8A7794_CLK_SSI0		15
+#define R8A7794_CLK_SCU_ALL		17
+#define R8A7794_CLK_SCU_DVC1		18
+#define R8A7794_CLK_SCU_DVC0		19
+#define R8A7794_CLK_SCU_CTU1_MIX1	20
+#define R8A7794_CLK_SCU_CTU0_MIX0	21
+#define R8A7794_CLK_SCU_SRC9		22
+#define R8A7794_CLK_SCU_SRC8		23
+#define R8A7794_CLK_SCU_SRC7		24
+#define R8A7794_CLK_SCU_SRC6		25
+#define R8A7794_CLK_SCU_SRC5		26
+#define R8A7794_CLK_SCU_SRC4		27
+#define R8A7794_CLK_SCU_SRC3		28
+#define R8A7794_CLK_SCU_SRC2		29
+#define R8A7794_CLK_SCU_SRC1		30
+#define R8A7794_CLK_SCU_SRC0		31
+
 /* MSTP11 */
 #define R8A7794_CLK_SCIFA3		6
 #define R8A7794_CLK_SCIFA4		7



From sergei.shtylyov at cogentembedded.com  Mon Feb  8 15:03:12 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 09 Feb 2016 02:03:12 +0300
Subject: [PATCH 4/5] ARM: dts: r8a7794: add Audio-DMAC support
In-Reply-To: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>
References: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>
Message-ID: <2262360.JfPBBBJWSV@wasted.cogentembedded.com>

Describe Audio-DMAC in the R8A7794 device tree.

This patch is loosely based on the commit 8994fff67761 ("ARM: shmobile:
r8a7791: Add Audio DMAC devices to DT").

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/boot/dts/r8a7794.dtsi |   28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -281,6 +281,34 @@
 		dma-channels = <15>;
 	};
 
+	audma0: dma-controller at ec700000 {
+		compatible = "renesas,dmac-r8a7794", "renesas,rcar-dmac";
+		reg = <0 0xec700000 0 0x10000>;
+		interrupts =	<GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "error",
+				  "ch0", "ch1", "ch2", "ch3", "ch4", "ch5",
+				  "ch6", "ch7", "ch8", "ch9", "ch10", "ch11",
+				  "ch12";
+		clocks = <&mstp5_clks R8A7794_CLK_AUDIO_DMAC0>;
+		clock-names = "fck";
+		power-domains = <&cpg_clocks>;
+		#dma-cells = <1>;
+		dma-channels = <13>;
+	};
+
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a7794",
 			     "renesas,rcar-gen2-scifa", "renesas,scifa";



From sergei.shtylyov at cogentembedded.com  Mon Feb  8 15:04:07 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 09 Feb 2016 02:04:07 +0300
Subject: [PATCH 5/5] ARM: dts: r8a7794 add sound support
In-Reply-To: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>
References: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>
Message-ID: <2179456.HznTXDfKhZ@wasted.cogentembedded.com>

Define the generic R8A7794 part of  the sound device node.
This sound device  is a complex one and comprises the Audio Clock Generator
(ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
(SSI[U]), and Audio DMAC-Peripheral-Peripheral.
It is up  to the board file to enable the device.

This patch is based on the R8A7791 sound work by Kuninori Morimoto.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/boot/dts/r8a7794.dtsi |  171 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 171 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -1309,4 +1309,175 @@
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
+
+	rcar_sound: sound at ec500000 {
+		/*
+		 * #sound-dai-cells is required
+		 *
+		 * Single DAI : #sound-dai-cells = <0>;         <&rcar_sound>;
+		 * Multi  DAI : #sound-dai-cells = <1>;         <&rcar_sound N>;
+		 */
+		compatible = "renesas,rcar_sound-r8a7794",
+			     "renesas,rcar_sound-gen2";
+		reg =	<0 0xec500000 0 0x1000>, /* SCU */
+			<0 0xec5a0000 0 0x100>,  /* ADG */
+			<0 0xec540000 0 0x1000>, /* SSIU */
+			<0 0xec541000 0 0x280>,  /* SSI */
+			<0 0xec740000 0 0x200>;  /* Audio DMAC peri peri */
+		reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
+
+		clocks = <&mstp10_clks R8A7794_CLK_SSI_ALL>,
+			 <&mstp10_clks R8A7794_CLK_SSI9>,
+			 <&mstp10_clks R8A7794_CLK_SSI8>,
+			 <&mstp10_clks R8A7794_CLK_SSI7>,
+			 <&mstp10_clks R8A7794_CLK_SSI6>,
+			 <&mstp10_clks R8A7794_CLK_SSI5>,
+			 <&mstp10_clks R8A7794_CLK_SSI4>,
+			 <&mstp10_clks R8A7794_CLK_SSI3>,
+			 <&mstp10_clks R8A7794_CLK_SSI2>,
+			 <&mstp10_clks R8A7794_CLK_SSI1>,
+			 <&mstp10_clks R8A7794_CLK_SSI0>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC9>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC8>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC7>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC6>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC5>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC4>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC3>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC2>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC1>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC0>,
+			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
+			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
+			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
+			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
+			 <&mstp10_clks R8A7794_CLK_SCU_DVC0>,
+			 <&mstp10_clks R8A7794_CLK_SCU_DVC1>,
+			 <&audio_clka>, <&audio_clkb>, <&audio_clkc>,
+			 <&m2_clk>;
+		clock-names = "ssi-all",
+			      "ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
+			      "ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0",
+			      "src.9", "src.8", "src.7", "src.6", "src.5",
+			      "src.4", "src.3", "src.2", "src.1", "src.0",
+			      "clk_a", "clk_b", "clk_c", "clk_i";
+		power-domains = <&cpg_clocks>;
+
+		status = "disabled";
+		rcar_sound,src {
+			src0: src at 0 {
+				interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x85>, <&audma0 0x9a>;
+				dma-names = "rx", "tx";
+			};
+			src1: src at 1 {
+				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x87>, <&audma0 0x9c>;
+				dma-names = "rx", "tx";
+			};
+			src2: src at 2 {
+				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x89>, <&audma0 0x9e>;
+				dma-names = "rx", "tx";
+			};
+			src3: src at 3 {
+				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
+				dma-names = "rx", "tx";
+			};
+			src4: src at 4 {
+				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
+				dma-names = "rx", "tx";
+			};
+			src5: src at 5 {
+				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
+				dma-names = "rx", "tx";
+			};
+			src6: src at 6 {
+				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x91>, <&audma0 0xb4>;
+				dma-names = "rx", "tx";
+			};
+			src7: src at 7 {
+				interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x93>, <&audma0 0xb6>;
+				dma-names = "rx", "tx";
+			};
+			src8: src at 8 {
+				interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x95>, <&audma0 0xb8>;
+				dma-names = "rx", "tx";
+			};
+			src9: src at 9 {
+				interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x97>, <&audma0 0xba>;
+				dma-names = "rx", "tx";
+			};
+		};
+
+		rcar_sound,ssi {
+			ssi0: ssi at 0 {
+				interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x01>, <&audma0 0x02>,
+				       <&audma0 0x15>, <&audma0 0x16>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi1: ssi at 1 {
+				interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x03>, <&audma0 0x04>,
+				       <&audma0 0x49>, <&audma0 0x4a>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi2: ssi at 2 {
+				interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x05>, <&audma0 0x06>,
+				       <&audma0 0x63>, <&audma0 0x64>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi3: ssi at 3 {
+				interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x07>, <&audma0 0x08>,
+				       <&audma0 0x6f>, <&audma0 0x70>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi4: ssi at 4 {
+				interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x09>, <&audma0 0x0a>,
+				       <&audma0 0x71>, <&audma0 0x72>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi5: ssi at 5 {
+				interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x0b>, <&audma0 0x0c>,
+				       <&audma0 0x73>, <&audma0 0x74>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi6: ssi at 6 {
+				interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x0d>, <&audma0 0x0e>,
+				       <&audma0 0x75>, <&audma0 0x76>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi7: ssi at 7 {
+				interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x0f>, <&audma0 0x10>,
+				       <&audma0 0x79>, <&audma0 0x7a>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi8: ssi at 8 {
+				interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x11>, <&audma0 0x12>,
+				       <&audma0 0x7b>, <&audma0 0x7c>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi9: ssi at 9 {
+				interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x13>, <&audma0 0x14>,
+				       <&audma0 0x7d>, <&audma0 0x7e>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+		};
+	};
 };



From yang.shi at linaro.org  Mon Feb  8 14:49:24 2016
From: yang.shi at linaro.org (Yang Shi)
Date: Mon,  8 Feb 2016 14:49:24 -0800
Subject: [PATCH] arm64: replace read_lock to rcu lock in call_step_hook
Message-ID: <1454971764-30720-1-git-send-email-yang.shi@linaro.org>

BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
in_atomic(): 1, irqs_disabled(): 128, pid: 383, name: sh
Preemption disabled at:[<ffff800000124c18>] kgdb_cpu_enter+0x158/0x6b8

CPU: 3 PID: 383 Comm: sh Tainted: G        W       4.1.13-rt13 #2
Hardware name: Freescale Layerscape 2085a RDB Board (DT)
Call trace:
[<ffff8000000885e8>] dump_backtrace+0x0/0x128
[<ffff800000088734>] show_stack+0x24/0x30
[<ffff80000079a7c4>] dump_stack+0x80/0xa0
[<ffff8000000bd324>] ___might_sleep+0x18c/0x1a0
[<ffff8000007a20ac>] __rt_spin_lock+0x2c/0x40
[<ffff8000007a2268>] rt_read_lock+0x40/0x58
[<ffff800000085328>] single_step_handler+0x38/0xd8
[<ffff800000082368>] do_debug_exception+0x58/0xb8
Exception stack(0xffff80834a1e7c80 to 0xffff80834a1e7da0)
7c80: ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7e40 ffff8083 001bfcc4 ffff8000
7ca0: f2000400 00000000 00000000 00000000 4a1e7d80 ffff8083 0049501c ffff8000
7cc0: 00005402 00000000 00aaa210 ffff8000 4a1e7ea0 ffff8083 000833f4 ffff8000
7ce0: ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7ea0 ffff8083 001bfcc0 ffff8000
7d00: 4a0fc400 ffff8083 00005402 00000000 4a1e7d40 ffff8083 00490324 ffff8000
7d20: ffffff9c 00000000 92c23ba0 0000ffff 000a0000 00000000 00000000 00000000
7d40: 00000008 00000000 00080000 00000000 92c23b8b 0000ffff 92c23b8e 0000ffff
7d60: 00000038 00000000 00001cb2 00000000 00000005 00000000 92d7b498 0000ffff
7d80: 01010101 01010101 92be9000 0000ffff 00000000 00000000 00000030 00000000
[<ffff8000000833f4>] el1_dbg+0x18/0x6c

This issue is similar with 62c6c61("arm64: replace read_lock to rcu lock in
call_break_hook"), but comes to single_step_handler.

This also solves kgdbts boot test silent hang issue on 4.4 -rt kernel.

Signed-off-by: Yang Shi <yang.shi at linaro.org>
---
 arch/arm64/kernel/debug-monitors.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index 8aee3ae..c1492ba 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -186,20 +186,21 @@ static void clear_regs_spsr_ss(struct pt_regs *regs)
 
 /* EL1 Single Step Handler hooks */
 static LIST_HEAD(step_hook);
-static DEFINE_RWLOCK(step_hook_lock);
+static DEFINE_SPINLOCK(step_hook_lock);
 
 void register_step_hook(struct step_hook *hook)
 {
-	write_lock(&step_hook_lock);
-	list_add(&hook->node, &step_hook);
-	write_unlock(&step_hook_lock);
+	spin_lock(&step_hook_lock);
+	list_add_rcu(&hook->node, &step_hook);
+	spin_unlock(&step_hook_lock);
 }
 
 void unregister_step_hook(struct step_hook *hook)
 {
-	write_lock(&step_hook_lock);
-	list_del(&hook->node);
-	write_unlock(&step_hook_lock);
+	spin_lock(&step_hook_lock);
+	list_del_rcu(&hook->node);
+	spin_unlock(&step_hook_lock);
+	synchronize_rcu();
 }
 
 /*
@@ -213,15 +214,15 @@ static int call_step_hook(struct pt_regs *regs, unsigned int esr)
 	struct step_hook *hook;
 	int retval = DBG_HOOK_ERROR;
 
-	read_lock(&step_hook_lock);
+	rcu_read_lock();
 
-	list_for_each_entry(hook, &step_hook, node)	{
+	list_for_each_entry_rcu(hook, &step_hook, node)	{
 		retval = hook->fn(regs, esr);
 		if (retval == DBG_HOOK_HANDLED)
 			break;
 	}
 
-	read_unlock(&step_hook_lock);
+	rcu_read_unlock();
 
 	return retval;
 }
-- 
2.0.2



From helgaas at kernel.org  Mon Feb  8 15:24:30 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Mon, 8 Feb 2016 17:24:30 -0600
Subject: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for
 ThunderX-pass1 on-chip devices
In-Reply-To: <56B919A5.5090000@caviumnetworks.com>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
 <1454715675-17512-4-git-send-email-ddaney.cavm@gmail.com>
 <20160208195642.GA15103@rob-hp-laptop>
 <56B8FED6.1050804@caviumnetworks.com>
 <CAL_JsqJNndZ59465YhpkP=dQYaijaar+LcQG4KQEJwF5e1ryLQ@mail.gmail.com>
 <56B90B09.7090500@caviumnetworks.com>
 <20160208221204.GA30821@localhost>
 <56B919A5.5090000@caviumnetworks.com>
Message-ID: <20160208232430.GA1353@localhost>

On Mon, Feb 08, 2016 at 02:41:41PM -0800, David Daney wrote:
> On 02/08/2016 02:12 PM, Bjorn Helgaas wrote:
> >On Mon, Feb 08, 2016 at 01:39:21PM -0800, David Daney wrote:
> >>On 02/08/2016 01:12 PM, Rob Herring wrote:
> >>>On Mon, Feb 8, 2016 at 2:47 PM, David Daney <ddaney at caviumnetworks.com> wrote:
> >>>>On 02/08/2016 11:56 AM, Rob Herring wrote:
> >>>>>On Fri, Feb 05, 2016 at 03:41:15PM -0800, David Daney wrote:
> >>>>>>From: David Daney <david.daney at cavium.com>
> >>>>>>+Properties of the host controller node that differ from
> >>>>>>+host-generic-pci.txt:
> >>>>>>+
> >>>>>>+- compatible     : Must be "cavium,pci-host-thunder-ecam"
> >>>>>>+
> >>>>>>+Example:
> >>>>>>+
> >>>>>>+       pci at 84b0,00000000 {
> ...
> >>>>>and the node name should be "pcie".
> >>>>
> >>>>Why pcie?
> >>>>
> >>>>There are no PCIe devices or buses reachable from this type of root complex.
> >>>>There are however many PCI devices.
> ...

> >>Really, it is a bit of a gray area here as we don't have any bridges
> >>to PCIe buses and there are multiple devices residing on each bus,
> >>so from that point of view it cannot be PCIe.  There are, however,
> >>devices that implement the PCI Express Capability structure, so does
> >>that make it PCIe?  It is not clear what the specifications demand
> >>here.
> >
> >The PCI core doesn't care about the node name in the device tree.  But
> >it *does* care about some details of PCI/PCIe topology.  We consider
> >anything with a PCIe capability to be PCIe.  For example,
> >
> >   - pci_cfg_space_size() thinks PCIe devices have 4K of config space
> >
> >   - only_one_child() thinks a PCIe bus, i.e., a link, only has a
> >     single device on it
> >
> >   - a PCIe device should have a PCIe Root Port or PCIe Downstream Port
> >     upstream from it (we did remove some of these restrictions with
> >     b35b1df5e6c2 ("PCI: Tolerate hierarchies with no Root Port"), but
> >     it's possible we didn't get them all)
> >
> >I assume your system conforms to expectations like these; I'm just
> >pointing them out because you mentioned buses with multiple devices on
> >them, which is definitely something one doesn't expect in PCIe.
> 
> The topology we have is currently working with the kernel's core PCI
> code.  I don't really want to get into discussing what the
> definition of PCIe is.  We have multiple devices (more than 32) on a
> single bus, and they have PCI Express and ARI Capabilities.  Is that
> PCIe?  I don't know.

I don't need to know the details of your topology.  As long as it
conforms to the PCIe spec, it should be fine.  If it *doesn't* conform
to the spec, but things currently seem to work, that's less fine,
because a future Linux change is liable to break something for you.

I was a little concerned about your statement that "there are multiple
devices residing on each bus, so from that point of view it cannot be
PCIe."  That made it sound like you're doing something outside the
spec.  If you're just using regular multi-function devices or ARI,
then I don't see any issue (or any reason to say it can't be PCIe).

Bjorn


From ddaney at caviumnetworks.com  Mon Feb  8 15:31:54 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Mon, 8 Feb 2016 15:31:54 -0800
Subject: [PATCH v5 3/3] pci,
 pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices
In-Reply-To: <20160208232430.GA1353@localhost>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
 <1454715675-17512-4-git-send-email-ddaney.cavm@gmail.com>
 <20160208195642.GA15103@rob-hp-laptop> <56B8FED6.1050804@caviumnetworks.com>
 <CAL_JsqJNndZ59465YhpkP=dQYaijaar+LcQG4KQEJwF5e1ryLQ@mail.gmail.com>
 <56B90B09.7090500@caviumnetworks.com> <20160208221204.GA30821@localhost>
 <56B919A5.5090000@caviumnetworks.com> <20160208232430.GA1353@localhost>
Message-ID: <56B9256A.5040106@caviumnetworks.com>

On 02/08/2016 03:24 PM, Bjorn Helgaas wrote:
> On Mon, Feb 08, 2016 at 02:41:41PM -0800, David Daney wrote:
>> On 02/08/2016 02:12 PM, Bjorn Helgaas wrote:
>>> On Mon, Feb 08, 2016 at 01:39:21PM -0800, David Daney wrote:
>>>> On 02/08/2016 01:12 PM, Rob Herring wrote:
>>>>> On Mon, Feb 8, 2016 at 2:47 PM, David Daney <ddaney at caviumnetworks.com> wrote:
>>>>>> On 02/08/2016 11:56 AM, Rob Herring wrote:
>>>>>>> On Fri, Feb 05, 2016 at 03:41:15PM -0800, David Daney wrote:
>>>>>>>> From: David Daney <david.daney at cavium.com>
>>>>>>>> +Properties of the host controller node that differ from
>>>>>>>> +host-generic-pci.txt:
>>>>>>>> +
>>>>>>>> +- compatible     : Must be "cavium,pci-host-thunder-ecam"
>>>>>>>> +
>>>>>>>> +Example:
>>>>>>>> +
>>>>>>>> +       pci at 84b0,00000000 {
>> ...
>>>>>>> and the node name should be "pcie".
>>>>>>
>>>>>> Why pcie?
>>>>>>
>>>>>> There are no PCIe devices or buses reachable from this type of root complex.
>>>>>> There are however many PCI devices.
>> ...
>
>>>> Really, it is a bit of a gray area here as we don't have any bridges
>>>> to PCIe buses and there are multiple devices residing on each bus,
>>>> so from that point of view it cannot be PCIe.  There are, however,
>>>> devices that implement the PCI Express Capability structure, so does
>>>> that make it PCIe?  It is not clear what the specifications demand
>>>> here.
>>>
>>> The PCI core doesn't care about the node name in the device tree.  But
>>> it *does* care about some details of PCI/PCIe topology.  We consider
>>> anything with a PCIe capability to be PCIe.  For example,
>>>
>>>    - pci_cfg_space_size() thinks PCIe devices have 4K of config space
>>>
>>>    - only_one_child() thinks a PCIe bus, i.e., a link, only has a
>>>      single device on it
>>>
>>>    - a PCIe device should have a PCIe Root Port or PCIe Downstream Port
>>>      upstream from it (we did remove some of these restrictions with
>>>      b35b1df5e6c2 ("PCI: Tolerate hierarchies with no Root Port"), but
>>>      it's possible we didn't get them all)
>>>
>>> I assume your system conforms to expectations like these; I'm just
>>> pointing them out because you mentioned buses with multiple devices on
>>> them, which is definitely something one doesn't expect in PCIe.
>>
>> The topology we have is currently working with the kernel's core PCI
>> code.  I don't really want to get into discussing what the
>> definition of PCIe is.  We have multiple devices (more than 32) on a
>> single bus, and they have PCI Express and ARI Capabilities.  Is that
>> PCIe?  I don't know.
>
> I don't need to know the details of your topology.  As long as it
> conforms to the PCIe spec, it should be fine.  If it *doesn't* conform
> to the spec, but things currently seem to work, that's less fine,
> because a future Linux change is liable to break something for you.
>
> I was a little concerned about your statement that "there are multiple
> devices residing on each bus, so from that point of view it cannot be
> PCIe."  That made it sound like you're doing something outside the
> spec.  If you're just using regular multi-function devices or ARI,
> then I don't see any issue (or any reason to say it can't be PCIe).

OK, I will make it "pcie at ...."

Really, ARI is the only reason.  But since ARI is defined in the PCI 
Express specification, pcie it is.

I will send revised patches today.


David Daney

>
> Bjorn
>



From gerg at uclinux.org  Mon Feb  8 15:36:00 2016
From: gerg at uclinux.org (Greg Ungerer)
Date: Tue, 9 Feb 2016 09:36:00 +1000
Subject: [PATCH] ARM: ks8695: fix __initdata annotation
In-Reply-To: <1454941509-2773774-1-git-send-email-arnd@arndb.de>
References: <1454941509-2773774-1-git-send-email-arnd@arndb.de>
Message-ID: <56B92660.8060203@uclinux.org>

On 09/02/16 00:24, Arnd Bergmann wrote:
> Clang complains about the __initdata section attribute being in the
> wrong place in two files of ks8695:
> 
> arch/arm/mach-ks8695/cpu.c:37:31: error: '__section__' attribute only applies to functions and global variables
> arch/arm/mach-ks8695/board-og.c:83:31: error: '__section__' attribute only applies to functions and global variables
> 
> This moves the attribute to the correct place.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Acked-by: Greg Ungerer <gerg at uclinux.org>

Regards
Greg


> ---
>  arch/arm/mach-ks8695/board-og.c | 2 +-
>  arch/arm/mach-ks8695/cpu.c      | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-ks8695/board-og.c b/arch/arm/mach-ks8695/board-og.c
> index 1f4f2f4f25bb..fa1a7c2ca2bb 100644
> --- a/arch/arm/mach-ks8695/board-og.c
> +++ b/arch/arm/mach-ks8695/board-og.c
> @@ -80,7 +80,7 @@ static void __init og_pci_bus_reset(void)
>  #define	S8250_VIRT	0xf4000000
>  #define	S8250_SIZE	0x00100000
>  
> -static struct __initdata map_desc og_io_desc[] = {
> +static struct map_desc __initdata og_io_desc[] = {
>  	{
>  		.virtual	= S8250_VIRT,
>  		.pfn		= __phys_to_pfn(S8250_PHYS),
> diff --git a/arch/arm/mach-ks8695/cpu.c b/arch/arm/mach-ks8695/cpu.c
> index 474a050da85b..f56937890e3a 100644
> --- a/arch/arm/mach-ks8695/cpu.c
> +++ b/arch/arm/mach-ks8695/cpu.c
> @@ -34,7 +34,7 @@
>  #include <mach/regs-misc.h>
>  
>  
> -static struct __initdata map_desc ks8695_io_desc[] = {
> +static struct map_desc __initdata ks8695_io_desc[] = {
>  	{
>  		.virtual	= (unsigned long)KS8695_IO_VA,
>  		.pfn		= __phys_to_pfn(KS8695_IO_PA),
> 



From ddaney.cavm at gmail.com  Mon Feb  8 15:55:28 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Mon,  8 Feb 2016 15:55:28 -0800
Subject: [PATCH v6 0/3] Add host controller drivers for Cavium ThunderX PCI
Message-ID: <1454975731-13618-1-git-send-email-ddaney.cavm@gmail.com>

From: David Daney <david.daney at cavium.com>

Some Cavium ThunderX processors require quirky access methods for the
config space of the PCIe bridge.

There are now three patches:

1) Refactor code in pci-host-generic so that it can more easily be
   used by other drivers.  This splits the driver for CAM and ECAM
   access methods to a separate file from the common host driver code.

2) Add the ThunderX PCIe driver to external PCIe buses, which
   leverages the code in pci-host-generic

3) Add ThunderX PCI driver for internel SoC buses used on early
   ThunderX chip revisions.

Changes from v5: Added Acked-by Rob Herring for the device tree
binding in 3/3.  Fixed typo and split large functions as suggested by
Bjorn Helgaas.

Changes from v4: Added patch 3/3.  Stylistic changes to 2/3 suggested
by Bjorn Helgaas.  When expanding config write width to 32-bits, mask
out unintened writes to W1C bits, also suggested by Bjorn Helgaas.

Changes from v3: Add some Acked-by, rebased to v4.5.0-rc1

Changes from v2: Improve device tree binding example as noted by Rob
Herring.  Rename pcie-thunder-pem.* to pci-thunder-pem.* for better
consistency.  Update MAINTAINERS to reflect the changes.

Changes from v1: Split CAM and ECAM code from common driver code as
suggested by Arnd Bergmann.  Fix spelling errors in
pcie-thunder-pem.txt

David Daney (3):
  PCI: generic: Refactor code to enable reuse by other drivers.
  pci, pci-thunder-pem: Add PCIe host driver for ThunderX processors.
  pci, pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices

 .../devicetree/bindings/pci/pci-thunder-ecam.txt   |  30 ++
 .../devicetree/bindings/pci/pci-thunder-pem.txt    |  43 +++
 MAINTAINERS                                        |   9 +
 drivers/pci/host/Kconfig                           |  18 ++
 drivers/pci/host/Makefile                          |   3 +
 drivers/pci/host/pci-host-common.c                 | 194 +++++++++++
 drivers/pci/host/pci-host-common.h                 |  47 +++
 drivers/pci/host/pci-host-generic.c                | 181 +----------
 drivers/pci/host/pci-thunder-ecam.c                | 358 +++++++++++++++++++++
 drivers/pci/host/pci-thunder-pem.c                 | 347 ++++++++++++++++++++
 10 files changed, 1053 insertions(+), 177 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt
 create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-pem.txt
 create mode 100644 drivers/pci/host/pci-host-common.c
 create mode 100644 drivers/pci/host/pci-host-common.h
 create mode 100644 drivers/pci/host/pci-thunder-ecam.c
 create mode 100644 drivers/pci/host/pci-thunder-pem.c

-- 
1.8.3.1



From ddaney.cavm at gmail.com  Mon Feb  8 15:55:31 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Mon,  8 Feb 2016 15:55:31 -0800
Subject: [PATCH v6 3/3] pci,
 pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices
In-Reply-To: <1454975731-13618-1-git-send-email-ddaney.cavm@gmail.com>
References: <1454975731-13618-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1454975731-13618-4-git-send-email-ddaney.cavm@gmail.com>

From: David Daney <david.daney at cavium.com>

The cavium,pci-thunder-ecam devices are exactly ECAM based PCI root
complexes.  These root complexes (loosely referred to as ECAM units in
the hardware manuals) are used to access the Thunder on-chips devices.
They are special in that all the BARs on devices behind these root
complexes are at fixed addresses.  To handle this in a manner
compatible with the core PCI code, we have the config access functions
synthesize Enhanced Allocation (EA) capability entries for each BAR.

Since this EA synthesis is needed for exactly one chip model, we can
hard code some assumptions about the device topology and the
properties of specific DEVFNs in the driver.

Signed-off-by: David Daney <david.daney at cavium.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/pci/pci-thunder-ecam.txt   |  30 ++
 drivers/pci/host/Kconfig                           |   7 +
 drivers/pci/host/Makefile                          |   1 +
 drivers/pci/host/pci-thunder-ecam.c                | 358 +++++++++++++++++++++
 4 files changed, 396 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt
 create mode 100644 drivers/pci/host/pci-thunder-ecam.c

diff --git a/Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt b/Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt
new file mode 100644
index 0000000..0202dd1
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt
@@ -0,0 +1,30 @@
+* ThunderX PCI host controller for pass-1.x silicon
+
+Firmware-initialized PCI host controller to on-chip devices found on
+some Cavium ThunderX processors.  These devices have ECAM based config
+access, but the BARs are all at fixed addresses.  We handle the fixed
+addresses by synthesizing Enhanced Allocation (EA) capabilities for
+these devices.
+
+The properties and their meanings are identical to those described in
+host-generic-pci.txt except as listed below.
+
+Properties of the host controller node that differ from
+host-generic-pci.txt:
+
+- compatible     : Must be "cavium,pci-host-thunder-ecam"
+
+Example:
+
+	pcie at 84b000000000 {
+		compatible = "cavium,pci-host-thunder-ecam";
+		device_type = "pci";
+		msi-parent = <&its>;
+		msi-map = <0 &its 0x30000 0x10000>;
+		bus-range = <0 31>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		#stream-id-cells = <1>;
+		reg = <0x84b0 0x00000000 0 0x02000000>;  /* Configuration space */
+		ranges = <0x03000000 0x8180 0x00000000 0x8180 0x00000000 0x80 0x00000000>; /* mem ranges */
+	};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 184df22..f8912c6 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -202,4 +202,11 @@ config PCI_HOST_THUNDER_PEM
 	help
 	  Say Y here if you want PCIe support for CN88XX Cavium Thunder SoCs.
 
+config PCI_HOST_THUNDER_ECAM
+	bool "Cavium Thunder ECAMe controller to on-chip devices on pass-1.x silicon"
+	depends on OF && ARM64
+	select PCI_HOST_COMMON
+	help
+	  Say Y here if you want ECAM support for CN88XX-Pass-1.x Cavium Thunder SoCs.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 8903172..d6af3ba 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -23,4 +23,5 @@ obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
 obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
+obj-$(CONFIG_PCI_HOST_THUNDER_ECAM) += pci-thunder-ecam.o
 obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
diff --git a/drivers/pci/host/pci-thunder-ecam.c b/drivers/pci/host/pci-thunder-ecam.c
new file mode 100644
index 0000000..83ee590
--- /dev/null
+++ b/drivers/pci/host/pci-thunder-ecam.c
@@ -0,0 +1,358 @@
+/*
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2015 Cavium, Inc.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/ioport.h>
+#include <linux/of_pci.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#include "pci-host-common.h"
+
+/* Mapping is standard ECAM */
+static void __iomem *thunder_ecam_map_bus(struct pci_bus *bus,
+					  unsigned int devfn,
+					  int where)
+{
+	struct gen_pci *pci = bus->sysdata;
+	resource_size_t idx = bus->number - pci->cfg.bus_range->start;
+
+	return pci->cfg.win[idx] + ((devfn << 12) | where);
+}
+
+static void set_val(u32 v, int where, int size, u32 *val)
+{
+	int shift = (where & 3) * 8;
+
+	pr_debug("set_val %04x: %08x\n", (unsigned)(where & ~3), v);
+	v >>= shift;
+	if (size == 1)
+		v &= 0xff;
+	else if (size == 2)
+		v &= 0xffff;
+	*val = v;
+}
+
+static int handle_ea_bar(u32 e0, int bar, struct pci_bus *bus,
+			 unsigned int devfn, int where, int size, u32 *val)
+{
+	void __iomem *addr;
+	u32 v;
+	/*
+	 * Each entry is 16-byte aligned bits[2,3] select which word
+	 * in the entry
+	 */
+	int where_a = where & 0xc;
+
+	if (where_a == 0) {
+		set_val(e0, where, size, val);
+		return PCIBIOS_SUCCESSFUL;
+	}
+	if (where_a == 0x4) {
+		addr = bus->ops->map_bus(bus, devfn, bar); /* BAR 0 */
+		if (!addr) {
+			*val = ~0;
+			return PCIBIOS_DEVICE_NOT_FOUND;
+		}
+		v = readl(addr);
+		v &= ~0xf;
+		v |= 2; /* EA entry-1. Base-L */
+		set_val(v, where, size, val);
+		return PCIBIOS_SUCCESSFUL;
+	}
+	if (where_a == 0x8) {
+		u32 barl_orig;
+		u32 barl_rb;
+
+		addr = bus->ops->map_bus(bus, devfn, bar); /* BAR 0 */
+		if (!addr) {
+			*val = ~0;
+			return PCIBIOS_DEVICE_NOT_FOUND;
+		}
+		barl_orig = readl(addr + 0);
+		writel(0xffffffff, addr + 0);
+		barl_rb = readl(addr + 0);
+		writel(barl_orig, addr + 0);
+		/* zeros in unsettable bits. */
+		v = ~barl_rb & ~3;
+		v |= 0xc; /* EA entry-2. Offset-L */
+		set_val(v, where, size, val);
+		return PCIBIOS_SUCCESSFUL;
+	}
+	if (where_a == 0xc) {
+		addr = bus->ops->map_bus(bus, devfn, bar + 4); /* BAR 1 */
+		if (!addr) {
+			*val = ~0;
+			return PCIBIOS_DEVICE_NOT_FOUND;
+		}
+		v = readl(addr); /* EA entry-3. Base-H */
+		set_val(v, where, size, val);
+		return PCIBIOS_SUCCESSFUL;
+	}
+	return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
+static int thunder_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
+				    int where, int size, u32 *val)
+{
+	u32 v;
+	u32 vendor_device;
+	void __iomem *addr;
+	int cfg_type;
+	int where_a = where & ~3;
+
+
+	addr = bus->ops->map_bus(bus, devfn, 0xc);
+	if (!addr) {
+		*val = ~0;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	v = readl(addr);
+
+	/* Check for non type-00 header. */
+	cfg_type = (v >> 16) & 0x7f;
+
+	/*
+	 * All BARs have fixed addresses specified by the EA
+	 * capability, they must return zero on read.
+	 */
+	if (cfg_type == 0 &&
+	    ((where >= 0x10 && where < 0x2c) ||
+	     (where >= 0x1a4 && where < 0x1bc))) {
+		/* BAR or SRIOV BAR */
+		*val = 0;
+		return PCIBIOS_SUCCESSFUL;
+	}
+
+	addr = bus->ops->map_bus(bus, devfn, 0);
+	if (!addr) {
+		*val = ~0;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	vendor_device = readl(addr);
+	if (vendor_device == 0xffffffff)
+		goto no_emulation;
+
+	addr = bus->ops->map_bus(bus, devfn, 8);
+	if (!addr) {
+		*val = ~0;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	v = readl(addr);
+	if (v == 0xffffffff)
+		goto no_emulation;
+
+	pr_debug("%04x:%04x - Fix pass#: %08x, where: %03x, devfn: %03x\n",
+		 vendor_device & 0xffff, vendor_device >> 16, v,
+		 (unsigned) where, devfn);
+
+	/* Check for non type-00 header. */
+	if (cfg_type == 0) {
+		bool has_msix;
+		bool is_nic = (vendor_device == 0xa01e177d);
+		bool is_tns = (vendor_device == 0xa01f177d);
+
+		addr = bus->ops->map_bus(bus, devfn, 0x70);
+		if (!addr) {
+			*val = ~0;
+			return PCIBIOS_DEVICE_NOT_FOUND;
+		}
+		/* E_CAP */
+		v = readl(addr);
+		has_msix = (v & 0xff00) != 0;
+
+		if (!has_msix && where_a == 0x70) {
+			v |= 0xbc00; /* next capability is EA at 0xbc */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xb0) {
+			addr = bus->ops->map_bus(bus, devfn, where_a);
+			if (!addr) {
+				*val = ~0;
+				return PCIBIOS_DEVICE_NOT_FOUND;
+			}
+			v = readl(addr);
+			if (v & 0xff00)
+				pr_err("Bad MSIX cap header: %08x\n", v);
+			v |= 0xbc00; /* next capability is EA at 0xbc */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xbc) {
+			if (is_nic)
+				v = 0x40014; /* EA last in chain, 4 entries. */
+			else if (is_tns)
+				v = 0x30014; /* EA last in chain, 3 entries. */
+			else if (has_msix)
+				v = 0x20014; /* EA last in chain, 2 entries. */
+			else
+				v = 0x10014; /* EA last in chain, 1 entry. */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a >= 0xc0 && where_a < 0xd0)
+			/* EA entry-0. PP=0, BAR0 Size:3 */
+			return handle_ea_bar(0x80ff0003,
+					     0x10, bus, devfn, where,
+					     size, val);
+		if (where_a >= 0xd0 && where_a < 0xe0 && has_msix)
+			 /* EA entry-1. PP=0, BAR4 Size:3 */
+			return handle_ea_bar(0x80ff0043,
+					     0x20, bus, devfn, where,
+					     size, val);
+		if (where_a >= 0xe0 && where_a < 0xf0 && is_tns)
+			/* EA entry-2. PP=0, BAR2, Size:3 */
+			return handle_ea_bar(0x80ff0023,
+					     0x18, bus, devfn, where,
+					     size, val);
+		if (where_a >= 0xe0 && where_a < 0xf0 && is_nic)
+			/* EA entry-2. PP=4, VF_BAR0 (9), Size:3 */
+			return handle_ea_bar(0x80ff0493,
+					     0x1a4, bus, devfn, where,
+					     size, val);
+		if (where_a >= 0xf0 && where_a < 0x100 && is_nic)
+			/* EA entry-3. PP=4, VF_BAR4 (d), Size:3 */
+			return handle_ea_bar(0x80ff04d3,
+					     0x1b4, bus, devfn, where,
+					     size, val);
+	} else if (cfg_type == 1) {
+		bool is_rsl_bridge = devfn == 0x08;
+		bool is_rad_bridge = devfn == 0xa0;
+		bool is_zip_bridge = devfn == 0xa8;
+		bool is_dfa_bridge = devfn == 0xb0;
+		bool is_nic_bridge = devfn == 0x10;
+
+		if (where_a == 0x70) {
+			addr = bus->ops->map_bus(bus, devfn, where_a);
+			if (!addr) {
+				*val = ~0;
+				return PCIBIOS_DEVICE_NOT_FOUND;
+			}
+			v = readl(addr);
+			if (v & 0xff00)
+				pr_err("Bad PCIe cap header: %08x\n", v);
+			v |= 0xbc00; /* next capability is EA at 0xbc */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xbc) {
+			if (is_nic_bridge)
+				v = 0x10014; /* EA last in chain, 1 entry */
+			else
+				v = 0x00014; /* EA last in chain, no entries */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xc0) {
+			if (is_rsl_bridge || is_nic_bridge)
+				v = 0x0101; /* subordinate:secondary = 1:1 */
+			else if (is_rad_bridge)
+				v = 0x0202; /* subordinate:secondary = 2:2 */
+			else if (is_zip_bridge)
+				v = 0x0303; /* subordinate:secondary = 3:3 */
+			else if (is_dfa_bridge)
+				v = 0x0404; /* subordinate:secondary = 4:4 */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xc4 && is_nic_bridge) {
+			/* Enabled, not-Write, SP=ff, PP=05, BEI=6, ES=4 */
+			v = 0x80ff0564;
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xc8 && is_nic_bridge) {
+			v = 0x00000002; /* Base-L 64-bit */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xcc && is_nic_bridge) {
+			v = 0xfffffffe; /* MaxOffset-L 64-bit */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xd0 && is_nic_bridge) {
+			v = 0x00008430; /* NIC Base-H */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+		if (where_a == 0xd4 && is_nic_bridge) {
+			v = 0x0000000f; /* MaxOffset-H */
+			set_val(v, where, size, val);
+			return PCIBIOS_SUCCESSFUL;
+		}
+	}
+no_emulation:
+	return pci_generic_config_read(bus, devfn, where, size, val);
+}
+
+static int thunder_ecam_config_write(struct pci_bus *bus, unsigned int devfn,
+				     int where, int size, u32 val)
+{
+	/*
+	 * All BARs have fixed addresses, ignore BAR writes so they
+	 * don't get corrupted.
+	 */
+	if ((where >= 0x10 && where < 0x2c) ||
+	    (where >= 0x1a4 && where < 0x1bc))
+		/* BAR or SRIOV BAR */
+		return PCIBIOS_SUCCESSFUL;
+
+	return pci_generic_config_write(bus, devfn, where, size, val);
+}
+
+static struct gen_pci_cfg_bus_ops thunder_ecam_bus_ops = {
+	.bus_shift	= 20,
+	.ops		= {
+		.map_bus        = thunder_ecam_map_bus,
+		.read           = thunder_ecam_config_read,
+		.write          = thunder_ecam_config_write,
+	}
+};
+
+static const struct of_device_id thunder_ecam_of_match[] = {
+	{ .compatible = "cavium,pci-host-thunder-ecam",
+	  .data = &thunder_ecam_bus_ops },
+
+	{ },
+};
+MODULE_DEVICE_TABLE(of, thunder_ecam_of_match);
+
+static int thunder_ecam_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	const struct of_device_id *of_id;
+	struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
+
+	if (!pci)
+		return -ENOMEM;
+
+	of_id = of_match_node(thunder_ecam_of_match, dev->of_node);
+	pci->cfg.ops = (struct gen_pci_cfg_bus_ops *)of_id->data;
+
+	return pci_host_common_probe(pdev, pci);
+}
+
+static struct platform_driver thunder_ecam_driver = {
+	.driver = {
+		.name = KBUILD_MODNAME,
+		.of_match_table = thunder_ecam_of_match,
+	},
+	.probe = thunder_ecam_probe,
+};
+module_platform_driver(thunder_ecam_driver);
+
+MODULE_DESCRIPTION("Thunder ECAM PCI host driver");
+MODULE_LICENSE("GPL v2");
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Mon Feb  8 15:55:29 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Mon,  8 Feb 2016 15:55:29 -0800
Subject: [PATCH v6 1/3] PCI: generic: Refactor code to enable reuse by other
 drivers.
In-Reply-To: <1454975731-13618-1-git-send-email-ddaney.cavm@gmail.com>
References: <1454975731-13618-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1454975731-13618-2-git-send-email-ddaney.cavm@gmail.com>

From: David Daney <david.daney at cavium.com>

No change in functionality.

Move structure definitions into a separate header file.  Move common
code to new file with Kconfig machinery to build it.  Split probe
function in to two parts:

   - a small driver specific probe function (gen_pci_probe)

   - a common probe that can be used by other drivers
     (pci_host_common_probe)

Signed-off-by: David Daney <david.daney at cavium.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Will Deacon <will.deacon at arm.com>
---
 MAINTAINERS                         |   1 +
 drivers/pci/host/Kconfig            |   4 +
 drivers/pci/host/Makefile           |   1 +
 drivers/pci/host/pci-host-common.c  | 194 ++++++++++++++++++++++++++++++++++++
 drivers/pci/host/pci-host-common.h  |  47 +++++++++
 drivers/pci/host/pci-host-generic.c | 181 +--------------------------------
 6 files changed, 251 insertions(+), 177 deletions(-)
 create mode 100644 drivers/pci/host/pci-host-common.c
 create mode 100644 drivers/pci/host/pci-host-common.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 7f1fa4f..f95ac7f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8365,6 +8365,7 @@ L:	linux-pci at vger.kernel.org
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
 S:	Maintained
 F:	Documentation/devicetree/bindings/pci/host-generic-pci.txt
+F:	drivers/pci/host/pci-host-common.c
 F:	drivers/pci/host/pci-host-generic.c
 
 PCI DRIVER FOR INTEL VOLUME MANAGEMENT DEVICE (VMD)
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 75a6054..65709b4 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -53,9 +53,13 @@ config PCI_RCAR_GEN2_PCIE
 	help
 	  Say Y here if you want PCIe controller support on R-Car Gen2 SoCs.
 
+config PCI_HOST_COMMON
+	bool
+
 config PCI_HOST_GENERIC
 	bool "Generic PCI host controller"
 	depends on (ARM || ARM64) && OF
+	select PCI_HOST_COMMON
 	help
 	  Say Y here if you want to support a simple generic PCI host
 	  controller, such as the one emulated by kvmtool.
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 7b2f20c..3b24af8 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
 obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
 obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
 obj-$(CONFIG_PCI_RCAR_GEN2_PCIE) += pcie-rcar.o
+obj-$(CONFIG_PCI_HOST_COMMON) += pci-host-common.o
 obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
 obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
 obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
diff --git a/drivers/pci/host/pci-host-common.c b/drivers/pci/host/pci-host-common.c
new file mode 100644
index 0000000..e9f850f
--- /dev/null
+++ b/drivers/pci/host/pci-host-common.c
@@ -0,0 +1,194 @@
+/*
+ * 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/>.
+ *
+ * Copyright (C) 2014 ARM Limited
+ *
+ * Author: Will Deacon <will.deacon at arm.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_pci.h>
+#include <linux/platform_device.h>
+
+#include "pci-host-common.h"
+
+static void gen_pci_release_of_pci_ranges(struct gen_pci *pci)
+{
+	pci_free_resource_list(&pci->resources);
+}
+
+static int gen_pci_parse_request_of_pci_ranges(struct gen_pci *pci)
+{
+	int err, res_valid = 0;
+	struct device *dev = pci->host.dev.parent;
+	struct device_node *np = dev->of_node;
+	resource_size_t iobase;
+	struct resource_entry *win;
+
+	err = of_pci_get_host_bridge_resources(np, 0, 0xff, &pci->resources,
+					       &iobase);
+	if (err)
+		return err;
+
+	resource_list_for_each_entry(win, &pci->resources) {
+		struct resource *parent, *res = win->res;
+
+		switch (resource_type(res)) {
+		case IORESOURCE_IO:
+			parent = &ioport_resource;
+			err = pci_remap_iospace(res, iobase);
+			if (err) {
+				dev_warn(dev, "error %d: failed to map resource %pR\n",
+					 err, res);
+				continue;
+			}
+			break;
+		case IORESOURCE_MEM:
+			parent = &iomem_resource;
+			res_valid |= !(res->flags & IORESOURCE_PREFETCH);
+			break;
+		case IORESOURCE_BUS:
+			pci->cfg.bus_range = res;
+		default:
+			continue;
+		}
+
+		err = devm_request_resource(dev, parent, res);
+		if (err)
+			goto out_release_res;
+	}
+
+	if (!res_valid) {
+		dev_err(dev, "non-prefetchable memory resource required\n");
+		err = -EINVAL;
+		goto out_release_res;
+	}
+
+	return 0;
+
+out_release_res:
+	gen_pci_release_of_pci_ranges(pci);
+	return err;
+}
+
+static int gen_pci_parse_map_cfg_windows(struct gen_pci *pci)
+{
+	int err;
+	u8 bus_max;
+	resource_size_t busn;
+	struct resource *bus_range;
+	struct device *dev = pci->host.dev.parent;
+	struct device_node *np = dev->of_node;
+	u32 sz = 1 << pci->cfg.ops->bus_shift;
+
+	err = of_address_to_resource(np, 0, &pci->cfg.res);
+	if (err) {
+		dev_err(dev, "missing \"reg\" property\n");
+		return err;
+	}
+
+	/* Limit the bus-range to fit within reg */
+	bus_max = pci->cfg.bus_range->start +
+		  (resource_size(&pci->cfg.res) >> pci->cfg.ops->bus_shift) - 1;
+	pci->cfg.bus_range->end = min_t(resource_size_t,
+					pci->cfg.bus_range->end, bus_max);
+
+	pci->cfg.win = devm_kcalloc(dev, resource_size(pci->cfg.bus_range),
+				    sizeof(*pci->cfg.win), GFP_KERNEL);
+	if (!pci->cfg.win)
+		return -ENOMEM;
+
+	/* Map our Configuration Space windows */
+	if (!devm_request_mem_region(dev, pci->cfg.res.start,
+				     resource_size(&pci->cfg.res),
+				     "Configuration Space"))
+		return -ENOMEM;
+
+	bus_range = pci->cfg.bus_range;
+	for (busn = bus_range->start; busn <= bus_range->end; ++busn) {
+		u32 idx = busn - bus_range->start;
+
+		pci->cfg.win[idx] = devm_ioremap(dev,
+						 pci->cfg.res.start + idx * sz,
+						 sz);
+		if (!pci->cfg.win[idx])
+			return -ENOMEM;
+	}
+
+	return 0;
+}
+
+int pci_host_common_probe(struct platform_device *pdev,
+			  struct gen_pci *pci)
+{
+	int err;
+	const char *type;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct pci_bus *bus, *child;
+
+	type = of_get_property(np, "device_type", NULL);
+	if (!type || strcmp(type, "pci")) {
+		dev_err(dev, "invalid \"device_type\" %s\n", type);
+		return -EINVAL;
+	}
+
+	of_pci_check_probe_only();
+
+	pci->host.dev.parent = dev;
+	INIT_LIST_HEAD(&pci->host.windows);
+	INIT_LIST_HEAD(&pci->resources);
+
+	/* Parse our PCI ranges and request their resources */
+	err = gen_pci_parse_request_of_pci_ranges(pci);
+	if (err)
+		return err;
+
+	/* Parse and map our Configuration Space windows */
+	err = gen_pci_parse_map_cfg_windows(pci);
+	if (err) {
+		gen_pci_release_of_pci_ranges(pci);
+		return err;
+	}
+
+	/* Do not reassign resources if probe only */
+	if (!pci_has_flag(PCI_PROBE_ONLY))
+		pci_add_flags(PCI_REASSIGN_ALL_RSRC | PCI_REASSIGN_ALL_BUS);
+
+
+	bus = pci_scan_root_bus(dev, pci->cfg.bus_range->start,
+				&pci->cfg.ops->ops, pci, &pci->resources);
+	if (!bus) {
+		dev_err(dev, "Scanning rootbus failed");
+		return -ENODEV;
+	}
+
+	pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
+
+	if (!pci_has_flag(PCI_PROBE_ONLY)) {
+		pci_bus_size_bridges(bus);
+		pci_bus_assign_resources(bus);
+
+		list_for_each_entry(child, &bus->children, node)
+			pcie_bus_configure_settings(child);
+	}
+
+	pci_bus_add_devices(bus);
+	return 0;
+}
+
+MODULE_DESCRIPTION("Generic PCI host driver common code");
+MODULE_AUTHOR("Will Deacon <will.deacon at arm.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/pci/host/pci-host-common.h b/drivers/pci/host/pci-host-common.h
new file mode 100644
index 0000000..09f3fa0
--- /dev/null
+++ b/drivers/pci/host/pci-host-common.h
@@ -0,0 +1,47 @@
+/*
+ * 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/>.
+ *
+ * Copyright (C) 2014 ARM Limited
+ *
+ * Author: Will Deacon <will.deacon at arm.com>
+ */
+
+#ifndef _PCI_HOST_COMMON_H
+#define _PCI_HOST_COMMON_H
+
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+
+struct gen_pci_cfg_bus_ops {
+	u32 bus_shift;
+	struct pci_ops ops;
+};
+
+struct gen_pci_cfg_windows {
+	struct resource				res;
+	struct resource				*bus_range;
+	void __iomem				**win;
+
+	struct gen_pci_cfg_bus_ops		*ops;
+};
+
+struct gen_pci {
+	struct pci_host_bridge			host;
+	struct gen_pci_cfg_windows		cfg;
+	struct list_head			resources;
+};
+
+int pci_host_common_probe(struct platform_device *pdev,
+			  struct gen_pci *pci);
+
+#endif /* _PCI_HOST_COMMON_H */
diff --git a/drivers/pci/host/pci-host-generic.c b/drivers/pci/host/pci-host-generic.c
index 1652bc7..e8aa78f 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -25,24 +25,7 @@
 #include <linux/of_pci.h>
 #include <linux/platform_device.h>
 
-struct gen_pci_cfg_bus_ops {
-	u32 bus_shift;
-	struct pci_ops ops;
-};
-
-struct gen_pci_cfg_windows {
-	struct resource				res;
-	struct resource				*bus_range;
-	void __iomem				**win;
-
-	struct gen_pci_cfg_bus_ops		*ops;
-};
-
-struct gen_pci {
-	struct pci_host_bridge			host;
-	struct gen_pci_cfg_windows		cfg;
-	struct list_head			resources;
-};
+#include "pci-host-common.h"
 
 static void __iomem *gen_pci_map_cfg_bus_cam(struct pci_bus *bus,
 					     unsigned int devfn,
@@ -93,175 +76,19 @@ static const struct of_device_id gen_pci_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, gen_pci_of_match);
 
-static void gen_pci_release_of_pci_ranges(struct gen_pci *pci)
-{
-	pci_free_resource_list(&pci->resources);
-}
-
-static int gen_pci_parse_request_of_pci_ranges(struct gen_pci *pci)
-{
-	int err, res_valid = 0;
-	struct device *dev = pci->host.dev.parent;
-	struct device_node *np = dev->of_node;
-	resource_size_t iobase;
-	struct resource_entry *win;
-
-	err = of_pci_get_host_bridge_resources(np, 0, 0xff, &pci->resources,
-					       &iobase);
-	if (err)
-		return err;
-
-	resource_list_for_each_entry(win, &pci->resources) {
-		struct resource *parent, *res = win->res;
-
-		switch (resource_type(res)) {
-		case IORESOURCE_IO:
-			parent = &ioport_resource;
-			err = pci_remap_iospace(res, iobase);
-			if (err) {
-				dev_warn(dev, "error %d: failed to map resource %pR\n",
-					 err, res);
-				continue;
-			}
-			break;
-		case IORESOURCE_MEM:
-			parent = &iomem_resource;
-			res_valid |= !(res->flags & IORESOURCE_PREFETCH);
-			break;
-		case IORESOURCE_BUS:
-			pci->cfg.bus_range = res;
-		default:
-			continue;
-		}
-
-		err = devm_request_resource(dev, parent, res);
-		if (err)
-			goto out_release_res;
-	}
-
-	if (!res_valid) {
-		dev_err(dev, "non-prefetchable memory resource required\n");
-		err = -EINVAL;
-		goto out_release_res;
-	}
-
-	return 0;
-
-out_release_res:
-	gen_pci_release_of_pci_ranges(pci);
-	return err;
-}
-
-static int gen_pci_parse_map_cfg_windows(struct gen_pci *pci)
-{
-	int err;
-	u8 bus_max;
-	resource_size_t busn;
-	struct resource *bus_range;
-	struct device *dev = pci->host.dev.parent;
-	struct device_node *np = dev->of_node;
-	u32 sz = 1 << pci->cfg.ops->bus_shift;
-
-	err = of_address_to_resource(np, 0, &pci->cfg.res);
-	if (err) {
-		dev_err(dev, "missing \"reg\" property\n");
-		return err;
-	}
-
-	/* Limit the bus-range to fit within reg */
-	bus_max = pci->cfg.bus_range->start +
-		  (resource_size(&pci->cfg.res) >> pci->cfg.ops->bus_shift) - 1;
-	pci->cfg.bus_range->end = min_t(resource_size_t,
-					pci->cfg.bus_range->end, bus_max);
-
-	pci->cfg.win = devm_kcalloc(dev, resource_size(pci->cfg.bus_range),
-				    sizeof(*pci->cfg.win), GFP_KERNEL);
-	if (!pci->cfg.win)
-		return -ENOMEM;
-
-	/* Map our Configuration Space windows */
-	if (!devm_request_mem_region(dev, pci->cfg.res.start,
-				     resource_size(&pci->cfg.res),
-				     "Configuration Space"))
-		return -ENOMEM;
-
-	bus_range = pci->cfg.bus_range;
-	for (busn = bus_range->start; busn <= bus_range->end; ++busn) {
-		u32 idx = busn - bus_range->start;
-
-		pci->cfg.win[idx] = devm_ioremap(dev,
-						 pci->cfg.res.start + idx * sz,
-						 sz);
-		if (!pci->cfg.win[idx])
-			return -ENOMEM;
-	}
-
-	return 0;
-}
-
 static int gen_pci_probe(struct platform_device *pdev)
 {
-	int err;
-	const char *type;
-	const struct of_device_id *of_id;
 	struct device *dev = &pdev->dev;
-	struct device_node *np = dev->of_node;
+	const struct of_device_id *of_id;
 	struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
-	struct pci_bus *bus, *child;
 
 	if (!pci)
 		return -ENOMEM;
 
-	type = of_get_property(np, "device_type", NULL);
-	if (!type || strcmp(type, "pci")) {
-		dev_err(dev, "invalid \"device_type\" %s\n", type);
-		return -EINVAL;
-	}
-
-	of_pci_check_probe_only();
-
-	of_id = of_match_node(gen_pci_of_match, np);
+	of_id = of_match_node(gen_pci_of_match, dev->of_node);
 	pci->cfg.ops = (struct gen_pci_cfg_bus_ops *)of_id->data;
-	pci->host.dev.parent = dev;
-	INIT_LIST_HEAD(&pci->host.windows);
-	INIT_LIST_HEAD(&pci->resources);
-
-	/* Parse our PCI ranges and request their resources */
-	err = gen_pci_parse_request_of_pci_ranges(pci);
-	if (err)
-		return err;
-
-	/* Parse and map our Configuration Space windows */
-	err = gen_pci_parse_map_cfg_windows(pci);
-	if (err) {
-		gen_pci_release_of_pci_ranges(pci);
-		return err;
-	}
-
-	/* Do not reassign resources if probe only */
-	if (!pci_has_flag(PCI_PROBE_ONLY))
-		pci_add_flags(PCI_REASSIGN_ALL_RSRC | PCI_REASSIGN_ALL_BUS);
-
-
-	bus = pci_scan_root_bus(dev, pci->cfg.bus_range->start,
-				&pci->cfg.ops->ops, pci, &pci->resources);
-	if (!bus) {
-		dev_err(dev, "Scanning rootbus failed");
-		return -ENODEV;
-	}
-
-	pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
-
-	if (!pci_has_flag(PCI_PROBE_ONLY)) {
-		pci_bus_size_bridges(bus);
-		pci_bus_assign_resources(bus);
-
-		list_for_each_entry(child, &bus->children, node)
-			pcie_bus_configure_settings(child);
-	}
 
-	pci_bus_add_devices(bus);
-	return 0;
+	return pci_host_common_probe(pdev, pci);
 }
 
 static struct platform_driver gen_pci_driver = {
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Mon Feb  8 15:55:30 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Mon,  8 Feb 2016 15:55:30 -0800
Subject: [PATCH v6 2/3] pci,
 pci-thunder-pem: Add PCIe host driver for ThunderX processors.
In-Reply-To: <1454975731-13618-1-git-send-email-ddaney.cavm@gmail.com>
References: <1454975731-13618-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1454975731-13618-3-git-send-email-ddaney.cavm@gmail.com>

From: David Daney <david.daney at cavium.com>

The root complexes used to access off-chip PCIe devices (called PEM
units in the hardware manuals) on some Cavium ThunderX processors
require quirky access methods for the config space of the PCIe bridge.
Add a driver to provide these config space accessor functions.  The
pci-host-common code is used to configure the PCI machinery.

Signed-off-by: David Daney <david.daney at cavium.com>
Acked-by: Rob Herring <robh at kernel.org>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 .../devicetree/bindings/pci/pci-thunder-pem.txt    |  43 +++
 MAINTAINERS                                        |   8 +
 drivers/pci/host/Kconfig                           |   7 +
 drivers/pci/host/Makefile                          |   1 +
 drivers/pci/host/pci-thunder-pem.c                 | 347 +++++++++++++++++++++
 5 files changed, 406 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-pem.txt
 create mode 100644 drivers/pci/host/pci-thunder-pem.c

diff --git a/Documentation/devicetree/bindings/pci/pci-thunder-pem.txt b/Documentation/devicetree/bindings/pci/pci-thunder-pem.txt
new file mode 100644
index 0000000..f131fae
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pci-thunder-pem.txt
@@ -0,0 +1,43 @@
+* ThunderX PEM PCIe host controller
+
+Firmware-initialized PCI host controller found on some Cavium
+ThunderX processors.
+
+The properties and their meanings are identical to those described in
+host-generic-pci.txt except as listed below.
+
+Properties of the host controller node that differ from
+host-generic-pci.txt:
+
+- compatible     : Must be "cavium,pci-host-thunder-pem"
+
+- reg            : Two entries: First the configuration space for down
+                   stream devices base address and size, as accessed
+                   from the parent bus. Second, the register bank of
+                   the PEM device PCIe bridge.
+
+Example:
+
+    pci at 87e0,c2000000 {
+	compatible = "cavium,pci-host-thunder-pem";
+	device_type = "pci";
+	msi-parent = <&its>;
+	msi-map = <0 &its 0x10000 0x10000>;
+	bus-range = <0x8f 0xc7>;
+	#size-cells = <2>;
+	#address-cells = <3>;
+
+	reg = <0x8880 0x8f000000 0x0 0x39000000>,  /* Configuration space */
+	      <0x87e0 0xc2000000 0x0 0x00010000>; /* PEM space */
+	ranges = <0x01000000 0x00 0x00020000 0x88b0 0x00020000 0x00 0x00010000>, /* I/O */
+		 <0x03000000 0x00 0x10000000 0x8890 0x10000000 0x0f 0xf0000000>, /* mem64 */
+		 <0x43000000 0x10 0x00000000 0x88a0 0x00000000 0x10 0x00000000>, /* mem64-pref */
+		 <0x03000000 0x87e0 0xc2f00000 0x87e0 0xc2000000 0x00 0x00100000>; /* mem64 PEM BAR4 */
+
+	#interrupt-cells = <1>;
+	interrupt-map-mask = <0 0 0 7>;
+	interrupt-map = <0 0 0 1 &gic0 0 0 0 24 4>, /* INTA */
+			<0 0 0 2 &gic0 0 0 0 25 4>, /* INTB */
+			<0 0 0 3 &gic0 0 0 0 26 4>, /* INTC */
+			<0 0 0 4 &gic0 0 0 0 27 4>; /* INTD */
+    };
diff --git a/MAINTAINERS b/MAINTAINERS
index f95ac7f..650e8f3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8411,6 +8411,14 @@ L:     linux-arm-msm at vger.kernel.org
 S:     Maintained
 F:     drivers/pci/host/*qcom*
 
+PCIE DRIVER FOR CAVIUM THUNDERX
+M:	David Daney <david.daney at cavium.com>
+L:	linux-pci at vger.kernel.org
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S:	Supported
+F:	Documentation/devicetree/bindings/pci/pci-thunder-*
+F:	drivers/pci/host/pci-thunder-*
+
 PCMCIA SUBSYSTEM
 P:	Linux PCMCIA Team
 L:	linux-pcmcia at lists.infradead.org
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 65709b4..184df22 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -195,4 +195,11 @@ config PCIE_QCOM
 	  PCIe controller uses the Designware core plus Qualcomm-specific
 	  hardware wrappers.
 
+config PCI_HOST_THUNDER_PEM
+	bool "Cavium Thunder PCIe controller to off-chip devices"
+	depends on OF && ARM64
+	select PCI_HOST_COMMON
+	help
+	  Say Y here if you want PCIe support for CN88XX Cavium Thunder SoCs.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 3b24af8..8903172 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
 obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
+obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
new file mode 100644
index 0000000..4b939c7
--- /dev/null
+++ b/drivers/pci/host/pci-thunder-pem.c
@@ -0,0 +1,347 @@
+/*
+ * 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/>.
+ *
+ * Copyright (C) 2015 - 2016 Cavium, Inc.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_pci.h>
+#include <linux/platform_device.h>
+
+#include "pci-host-common.h"
+
+#define PEM_CFG_WR 0x28
+#define PEM_CFG_RD 0x30
+
+struct thunder_pem_pci {
+	struct gen_pci	gen_pci;
+	u32		ea_entry[3];
+	void __iomem	*pem_reg_base;
+};
+
+static void __iomem *thunder_pem_map_bus(struct pci_bus *bus,
+					 unsigned int devfn, int where)
+{
+	struct gen_pci *pci = bus->sysdata;
+	resource_size_t idx = bus->number - pci->cfg.bus_range->start;
+
+	return pci->cfg.win[idx] + ((devfn << 16) | where);
+}
+
+static int thunder_pem_bridge_read(struct pci_bus *bus, unsigned int devfn,
+				   int where, int size, u32 *val)
+{
+	u64 read_val;
+	struct thunder_pem_pci *pem_pci;
+	struct gen_pci *pci = bus->sysdata;
+
+	pem_pci = container_of(pci, struct thunder_pem_pci, gen_pci);
+
+	if (devfn != 0 || where >= 2048) {
+		*val = ~0;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	/*
+	 * 32-bit accesses only.  Write the address to the low order
+	 * bits of PEM_CFG_RD, then trigger the read by reading back.
+	 * The config data lands in the upper 32-bits of PEM_CFG_RD.
+	 */
+	read_val = where & ~3ull;
+	writeq(read_val, pem_pci->pem_reg_base + PEM_CFG_RD);
+	read_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
+	read_val >>= 32;
+
+	/*
+	 * The config space contains some garbage, fix it up.  Also
+	 * synthesize an EA capability for the BAR used by MSI-X.
+	 */
+	switch (where & ~3) {
+	case 0x40:
+		read_val &= 0xffff00ff;
+		read_val |= 0x00007000; /* Skip MSI CAP */
+		break;
+	case 0x70: /* Express Cap */
+		/* PME interrupt on vector 2*/
+		read_val |= (2u << 25);
+		break;
+	case 0xb0: /* MSI-X Cap */
+		/* TableSize=4, Next Cap is EA */
+		read_val &= 0xc00000ff;
+		read_val |= 0x0003bc00;
+		break;
+	case 0xb4:
+		/* Table offset=0, BIR=0 */
+		read_val = 0x00000000;
+		break;
+	case 0xb8:
+		/* BPA offset=0xf0000, BIR=0 */
+		read_val = 0x000f0000;
+		break;
+	case 0xbc:
+		/* EA, 1 entry, no next Cap */
+		read_val = 0x00010014;
+		break;
+	case 0xc0:
+		/* DW2 for type-1 */
+		read_val = 0x00000000;
+		break;
+	case 0xc4:
+		/* Entry BEI=0, PP=0x00, SP=0xff, ES=3 */
+		read_val = 0x80ff0003;
+		break;
+	case 0xc8:
+		read_val = pem_pci->ea_entry[0];
+		break;
+	case 0xcc:
+		read_val = pem_pci->ea_entry[1];
+		break;
+	case 0xd0:
+		read_val = pem_pci->ea_entry[2];
+		break;
+	default:
+		break;
+	}
+	read_val >>= (8 * (where & 3));
+	switch (size) {
+	case 1:
+		read_val &= 0xff;
+		break;
+	case 2:
+		read_val &= 0xffff;
+		break;
+	default:
+		break;
+	}
+	*val = read_val;
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static int thunder_pem_config_read(struct pci_bus *bus, unsigned int devfn,
+				   int where, int size, u32 *val)
+{
+	struct gen_pci *pci = bus->sysdata;
+
+	if (bus->number < pci->cfg.bus_range->start ||
+	    bus->number > pci->cfg.bus_range->end)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	/*
+	 * The first device on the bus is the PEM PCIe bridge.
+	 * Special case its config access.
+	 */
+	if (bus->number == pci->cfg.bus_range->start)
+		return thunder_pem_bridge_read(bus, devfn, where, size, val);
+
+	return pci_generic_config_read(bus, devfn, where, size, val);
+}
+
+/*
+ * Some of the w1c_bits below also include read-only or non-writable
+ * reserved bits, this makes the code simpler and is OK as the bits
+ * are not affected by writing zeros to them.
+ */
+static u32 thunder_pem_bridge_w1c_bits(int where)
+{
+	u32 w1c_bits = 0;
+
+	switch (where & ~3) {
+	case 0x04: /* Command/Status */
+	case 0x1c: /* Base and I/O Limit/Secondary Status */
+		w1c_bits = 0xff000000;
+		break;
+	case 0x44: /* Power Management Control and Status */
+		w1c_bits = 0xfffffe00;
+		break;
+	case 0x78: /* Device Control/Device Status */
+	case 0x80: /* Link Control/Link Status */
+	case 0x88: /* Slot Control/Slot Status */
+	case 0x90: /* Root Status */
+	case 0xa0: /* Link Control 2 Registers/Link Status 2 */
+		w1c_bits = 0xffff0000;
+		break;
+	case 0x104: /* Uncorrectable Error Status */
+	case 0x110: /* Correctable Error Status */
+	case 0x130: /* Error Status */
+	case 0x160: /* Link Control 4 */
+		w1c_bits = 0xffffffff;
+		break;
+	default:
+		break;
+	}
+	return w1c_bits;
+}
+
+static int thunder_pem_bridge_write(struct pci_bus *bus, unsigned int devfn,
+				    int where, int size, u32 val)
+{
+	struct gen_pci *pci = bus->sysdata;
+	struct thunder_pem_pci *pem_pci;
+	u64 write_val, read_val;
+	u32 mask = 0;
+
+	pem_pci = container_of(pci, struct thunder_pem_pci, gen_pci);
+
+	if (devfn != 0 || where >= 2048)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	/*
+	 * 32-bit accesses only.  If the write is for a size smaller
+	 * than 32-bits, we must first read the 32-bit value and merge
+	 * in the desired bits and then write the whole 32-bits back
+	 * out.
+	 */
+	switch (size) {
+	case 1:
+		read_val = where & ~3ull;
+		writeq(read_val, pem_pci->pem_reg_base + PEM_CFG_RD);
+		read_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
+		read_val >>= 32;
+		mask = ~(0xff << (8 * (where & 3)));
+		read_val &= mask;
+		val = (val & 0xff) << (8 * (where & 3));
+		val |= (u32)read_val;
+		break;
+	case 2:
+		read_val = where & ~3ull;
+		writeq(read_val, pem_pci->pem_reg_base + PEM_CFG_RD);
+		read_val = readq(pem_pci->pem_reg_base + PEM_CFG_RD);
+		read_val >>= 32;
+		mask = ~(0xffff << (8 * (where & 3)));
+		read_val &= mask;
+		val = (val & 0xffff) << (8 * (where & 3));
+		val |= (u32)read_val;
+		break;
+	default:
+		break;
+	}
+
+	/*
+	 * By expanding the write width to 32 bits, we may
+	 * inadvertently hit some W1C bits that were not intended to
+	 * be written.  Calculate the mask that must be applied to the
+	 * data to be written to avoid these cases.
+	 */
+	if (mask) {
+		u32 w1c_bits = thunder_pem_bridge_w1c_bits(where);
+
+		if (w1c_bits) {
+			mask &= w1c_bits;
+			val &= ~mask;
+		}
+	}
+
+	/*
+	 * Low order bits are the config address, the high order 32
+	 * bits are the data to be written.
+	 */
+	write_val = where & ~3ull;
+	write_val |= (((u64)val) << 32);
+	writeq(write_val, pem_pci->pem_reg_base + PEM_CFG_WR);
+	return PCIBIOS_SUCCESSFUL;
+}
+
+static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn,
+				    int where, int size, u32 val)
+{
+	struct gen_pci *pci = bus->sysdata;
+
+	if (bus->number < pci->cfg.bus_range->start ||
+	    bus->number > pci->cfg.bus_range->end)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	/*
+	 * The first device on the bus is the PEM PCIe bridge.
+	 * Special case its config access.
+	 */
+	if (bus->number == pci->cfg.bus_range->start)
+		return thunder_pem_bridge_write(bus, devfn, where, size, val);
+
+
+	return pci_generic_config_write(bus, devfn, where, size, val);
+}
+
+static struct gen_pci_cfg_bus_ops thunder_pem_bus_ops = {
+	.bus_shift	= 24,
+	.ops		= {
+		.map_bus	= thunder_pem_map_bus,
+		.read		= thunder_pem_config_read,
+		.write		= thunder_pem_config_write,
+	}
+};
+
+static const struct of_device_id thunder_pem_of_match[] = {
+	{ .compatible = "cavium,pci-host-thunder-pem",
+	  .data = &thunder_pem_bus_ops },
+
+	{ },
+};
+MODULE_DEVICE_TABLE(of, thunder_pem_of_match);
+
+static int thunder_pem_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	const struct of_device_id *of_id;
+	resource_size_t bar4_start;
+	struct resource *res_pem;
+	struct thunder_pem_pci *pem_pci;
+
+	pem_pci = devm_kzalloc(dev, sizeof(*pem_pci), GFP_KERNEL);
+	if (!pem_pci)
+		return -ENOMEM;
+
+	of_id = of_match_node(thunder_pem_of_match, dev->of_node);
+	pem_pci->gen_pci.cfg.ops = (struct gen_pci_cfg_bus_ops *)of_id->data;
+
+	/*
+	 * The second register range is the PEM bridge to the PCIe
+	 * bus.  It has a different config access method than those
+	 * devices behind the bridge.
+	 */
+	res_pem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	if (!res_pem) {
+		dev_err(dev, "missing \"reg[1]\"property\n");
+		return -EINVAL;
+	}
+
+	pem_pci->pem_reg_base = devm_ioremap(dev, res_pem->start, 0x10000);
+	if (!pem_pci->pem_reg_base)
+		return -ENOMEM;
+
+	/*
+	 * The MSI-X BAR for the PEM and AER interrupts is located at
+	 * a fixed offset from the PEM register base.  Generate a
+	 * fragment of the synthesized Enhanced Allocation capability
+	 * structure here for the BAR.
+	 */
+	bar4_start = res_pem->start + 0xf00000;
+	pem_pci->ea_entry[0] = (u32)bar4_start | 2;
+	pem_pci->ea_entry[1] = (u32)(res_pem->end - bar4_start) & ~3u;
+	pem_pci->ea_entry[2] = (u32)(bar4_start >> 32);
+
+	return pci_host_common_probe(pdev, &pem_pci->gen_pci);
+}
+
+static struct platform_driver thunder_pem_driver = {
+	.driver = {
+		.name = KBUILD_MODNAME,
+		.of_match_table = thunder_pem_of_match,
+	},
+	.probe = thunder_pem_probe,
+};
+module_platform_driver(thunder_pem_driver);
+
+MODULE_DESCRIPTION("Thunder PEM PCIe host driver");
+MODULE_LICENSE("GPL v2");
-- 
1.8.3.1



From steve.muckle at linaro.org  Mon Feb  8 15:59:48 2016
From: steve.muckle at linaro.org (Steve Muckle)
Date: Mon, 8 Feb 2016 15:59:48 -0800
Subject: [PATCH v3 0/6] CPUs capacity information for heterogeneous systems
In-Reply-To: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
Message-ID: <56B92BF4.4030405@linaro.org>

Hi Juri,

On 02/03/2016 03:59 AM, Juri Lelli wrote:
>  v1: DT + sysfs [1]
> 
>  v2: Dynamic profiling at boot [2]
> 
> Third version of this patchset proposes what seems to be the solution we agreed
> upon (see [2] for reference) to the problem of how do we init CPUs original
> capacity: we run a bogus benchmark (stealing int_sqrt from lib/ we run that in
> a loop to perform some integer computation, better benchmarks are welcome)
> on the first cpu of each frequency domain (assuming no u-arch differences
> inside domains), measure time to complete a fixed number of iterations and then
> normalize results to SCHED_CAPACITY_SCALE (1024). This time around we also
> added a boot time parameter to disable profiling at boot (as it can be time
> consuming) and sysfs attributes with which default values can be overwritten.
> The proposed solution is basically putting together bits of v1 and v2 that are
> considered valuable and acceptable for mainline.

I'm still concerned that there's no way to obtain optimal boot time on a
heterogeneous system. Either the dynamic benchmarking is enabled, adding
1 sec, or the benchmarking is skipped, and task distribution on the
heterogeneous CPUs is determined by the platform's CPU numbering and
chance, potentially impacting performance nondeterministically until
userspace sets the correct capacity values via sysfs.

I believe you tested the impact on boot time of using equal capacity
values and saw little difference. I'm wondering though, what was the CPU
numbering on that target?

thanks,
Steve


From kuninori.morimoto.gx at renesas.com  Mon Feb  8 16:08:21 2016
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Tue, 9 Feb 2016 00:08:21 +0000
Subject: [PATCH 5/5] ARM: dts: r8a7794 add sound support
In-Reply-To: <2179456.HznTXDfKhZ@wasted.cogentembedded.com>
References: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>
 <2179456.HznTXDfKhZ@wasted.cogentembedded.com>
Message-ID: <87mvraoikj.wl%kuninori.morimoto.gx@renesas.com>


Hi Sergei

> Define the generic R8A7794 part of  the sound device node.
> This sound device  is a complex one and comprises the Audio Clock Generator
> (ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
> (SSI[U]), and Audio DMAC-Peripheral-Peripheral.
> It is up  to the board file to enable the device.
> 
> This patch is based on the R8A7791 sound work by Kuninori Morimoto.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
(snip)
> +		clocks = <&mstp10_clks R8A7794_CLK_SSI_ALL>,
> +			 <&mstp10_clks R8A7794_CLK_SSI9>,
> +			 <&mstp10_clks R8A7794_CLK_SSI8>,
> +			 <&mstp10_clks R8A7794_CLK_SSI7>,
> +			 <&mstp10_clks R8A7794_CLK_SSI6>,
> +			 <&mstp10_clks R8A7794_CLK_SSI5>,
> +			 <&mstp10_clks R8A7794_CLK_SSI4>,
> +			 <&mstp10_clks R8A7794_CLK_SSI3>,
> +			 <&mstp10_clks R8A7794_CLK_SSI2>,
> +			 <&mstp10_clks R8A7794_CLK_SSI1>,
> +			 <&mstp10_clks R8A7794_CLK_SSI0>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC9>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC8>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC7>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC6>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC5>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC4>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC3>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC2>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC1>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC0>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_DVC0>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_DVC1>,
> +			 <&audio_clka>, <&audio_clkb>, <&audio_clkc>,
> +			 <&m2_clk>;
> +		clock-names = "ssi-all",
> +			      "ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
> +			      "ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0",
> +			      "src.9", "src.8", "src.7", "src.6", "src.5",
> +			      "src.4", "src.3", "src.2", "src.1", "src.0",
> +			      "clk_a", "clk_b", "clk_c", "clk_i";

This patch doesn't support "CTU/MIX/DVC".
Your "clocks" includes "R8A7794_CLK_SCU_CTUx_MIXx", and "R8A7794_CLK_SCU_DVCx",
but "clock-names" doesn't include "ctu.x", "dvc.x".


From eric at anholt.net  Mon Feb  8 16:32:58 2016
From: eric at anholt.net (Eric Anholt)
Date: Mon,  8 Feb 2016 16:32:58 -0800
Subject: [GIT PULL] bcm2835 DT changes for 4.6
Message-ID: <1454977978-17491-1-git-send-email-eric@anholt.net>

Hi Florian.  Here's the first set of patches for bcm2835 for 4.6.
We've got more DT patches that are going to happen for new boards,
too, but they're still getting polished.

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git at github.com:anholt/linux.git tags/bcm2835-dt-next-2016-02-04

for you to fetch changes up to 5ec6f2cd8ec4bcd38ba199ea8711a5ec906d85e7:

  ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT. (2016-02-02 20:02:45 -0800)

----------------------------------------------------------------
This pull request covers mostly DT changes that didn't make it into
4.5 because required header files went through other trees.

----------------------------------------------------------------
Alexander Aring (1):
      ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.

Lubomir Rintel (1):
      ARM: bcm2835: dt: Add Raspberry Pi Model A

Martin Sperl (2):
      ARM: bcm2835: add the auxiliary spi1 and spi2 to the device tree
      ARM: bcm2835: follow dt uart node-naming convention

Remi Pommarel (1):
      ARM: bcm2835: Add PWM clock support to the device tree

 arch/arm/boot/dts/Makefile          |  1 +
 arch/arm/boot/dts/bcm2835-rpi-a.dts | 24 ++++++++++++++++++++++++
 arch/arm/boot/dts/bcm2835-rpi.dtsi  | 16 ++++++++++++++++
 arch/arm/boot/dts/bcm283x.dtsi      | 35 +++++++++++++++++++++++++++++++++--
 4 files changed, 74 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/boot/dts/bcm2835-rpi-a.dts


From khilman at baylibre.com  Mon Feb  8 17:18:55 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Mon, 08 Feb 2016 17:18:55 -0800
Subject: mt1873-evb: MMC failing with linux-next
Message-ID: <7hegcmadfk.fsf@baylibre.com>

Hello,

I tried getting MMC working with linux-next (next-20160208) on
mt8173-evb by enabling a few options[1] on top of the default defconfig,
and this results in a kernel that hangs as soon as it starts userspace.

The MMC driver seems to start, though has some regulator issues:

[    0.526380] sdhci: Secure Digital Host Controller Interface driver
[    0.527176] sdhci: Copyright(c) Pierre Ossman
[    0.528835] vio18: unsupportable voltage range: 3300000-1980000uV
[    0.529610] mtk-msdc 11230000.mmc: Regulator set error -22:    3300000 - 3300000
[    0.563731] mtk-msdc 11240000.mmc: Got CD GPIO
    
The driver appears to be attempting to set 3.3V but using a 1.8V
regulator (vio18), which is failing.

Then, the kernel hangs after freeing unused memory:

[    0.616386] hctosys: unable to open rtc device (rtc0)
[    0.624118] usb_vbus: disabling
[    0.624547] vusb: disabling
[    0.624929] vgp6: disabling
[    0.625635] ALSA device list:
[    0.626009]   No soundcards found.
[    0.626963] Freeing unused kernel memory: 724K (ffffffc000977000 - ffffffc000a2c000)

And nothing further here.

It boots fine when disabling the MMC driver (CONFIG_MMC_MTK=n).

Any ideas?

Kevin

[1]
CONFIG_MMC_MTK=y
CONFIG_MFD_MT6397=y
CONFIG_REGULATOR_MT6397=y
CONFIG_MTK_PMIC_WRAP=y


From shaun.ren at linux.com  Mon Feb  8 17:31:16 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon,  8 Feb 2016 17:31:16 -0800
Subject: [PATCH v2 0/9] Staging: rts5208: Coding style and dma mapping fixes
In-Reply-To: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>

This set of patches fixes the coding style issues in rtsx_transport.c, and
dds a missing call dma_mapping_error() after dma_map_single().



From shaun.ren at linux.com  Mon Feb  8 17:31:17 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon,  8 Feb 2016 17:31:17 -0800
Subject: [PATCH v2 1/9] Staging: rts5208: rtsx_transport.c: Fix comment style
 warnings
In-Reply-To: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1454981485-15686-2-git-send-email-shaun.ren@linux.com>

This patch fixes all comment style warnings in rtsx_transport.c reported by
checkpatch.pl:

WARNING: Block comments use a trailing */ on a separate line

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index f27491e..3e3f6fb 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -36,7 +36,8 @@
  * For non-scatter-gather transfers, srb->request_buffer points to the
  * transfer buffer itself and srb->request_bufflen is the buffer's length.)
  * Update the *index and *offset variables so that the next copy will
- * pick up from where this one left off. */
+ * pick up from where this one left off.
+ */
 
 unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 	unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
@@ -45,7 +46,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 	unsigned int cnt;
 
 	/* If not using scatter-gather, just transfer the data directly.
-	 * Make certain it will fit in the available buffer space. */
+	 * Make certain it will fit in the available buffer space.
+	 */
 	if (scsi_sg_count(srb) == 0) {
 		if (*offset >= scsi_bufflen(srb))
 			return 0;
@@ -64,7 +66,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 	 * in kernel-addressable memory then kmap() will return its address.
 	 * If the page is not directly accessible -- such as a user buffer
 	 * located in high memory -- then kmap() will map it to a temporary
-	 * position in the kernel's virtual address space. */
+	 * position in the kernel's virtual address space.
+	 */
 	} else {
 		struct scatterlist *sg =
 				(struct scatterlist *) scsi_sglist(srb)
@@ -73,7 +76,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 		/* This loop handles a single s-g list entry, which may
 		 * include multiple pages.  Find the initial page structure
 		 * and the starting offset within the page, and update
-		 * the *offset and *index values for the next loop. */
+		 * the *offset and *index values for the next loop.
+		 */
 		cnt = 0;
 		while (cnt < buflen && *index < scsi_sg_count(srb)) {
 			struct page *page = sg_page(sg) +
@@ -97,7 +101,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 
 			/* Transfer the data for all the pages in this
 			 * s-g entry.  For each page: call kmap(), do the
-			 * transfer, and call kunmap() immediately after. */
+			 * transfer, and call kunmap() immediately after.
+			 */
 			while (sglen > 0) {
 				unsigned int plen = min(sglen, (unsigned int)
 						PAGE_SIZE - poff);
@@ -123,7 +128,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 }
 
 /* Store the contents of buffer into srb's transfer buffer and set the
-* SCSI residue. */
+ * SCSI residue.
+ */
 void rtsx_stor_set_xfer_buf(unsigned char *buffer,
 	unsigned int buflen, struct scsi_cmnd *srb)
 {
@@ -196,7 +202,8 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 
 	/* Error and abort processing: try to resynchronize with the device
 	 * by issuing a port reset.  If that fails, try a class-specific
-	 * device reset. */
+	 * device reset.
+	 */
 Handle_Errors:
 	return;
 }
-- 
2.7.0



From shaun.ren at linux.com  Mon Feb  8 17:31:19 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon,  8 Feb 2016 17:31:19 -0800
Subject: [PATCH v2 3/9] Staging: rts5208: rtsx_transport.c: Remove spaces
 after casts
In-Reply-To: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1454981485-15686-4-git-send-email-shaun.ren@linux.com>

This patch removes all spaces after casts in rtsx_transport.c, as reported
by checkpatch.pl:

CHECK: No space is necessary after a cast

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 67162f6..8a68f64 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -56,10 +56,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 			return 0;
 		cnt = min(buflen, scsi_bufflen(srb) - *offset);
 		if (dir == TO_XFER_BUF)
-			memcpy((unsigned char *) scsi_sglist(srb) + *offset,
+			memcpy((unsigned char *)scsi_sglist(srb) + *offset,
 			       buffer, cnt);
 		else
-			memcpy(buffer, (unsigned char *) scsi_sglist(srb) +
+			memcpy(buffer, (unsigned char *)scsi_sglist(srb) +
 			       *offset, cnt);
 		*offset += cnt;
 
@@ -73,7 +73,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 	 */
 	} else {
 		struct scatterlist *sg =
-				(struct scatterlist *) scsi_sglist(srb)
+				(struct scatterlist *)scsi_sglist(srb)
 				+ *index;
 
 		/* This loop handles a single s-g list entry, which may
-- 
2.7.0



From shaun.ren at linux.com  Mon Feb  8 17:31:20 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon,  8 Feb 2016 17:31:20 -0800
Subject: [PATCH v2 4/9] Staging: rts5208: rtsx_transport.c: Add spaces around -
In-Reply-To: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1454981485-15686-5-git-send-email-shaun.ren@linux.com>

This patch fixes the following styling issue in rtsx_transport.c
as reported by checkpatch.pl:

CHECK: spaces preferred around that '-' (ctx:VxV)

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 8a68f64..901c64a 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -85,8 +85,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 		while (cnt < buflen && *index < scsi_sg_count(srb)) {
 			struct page *page = sg_page(sg) +
 					((sg->offset + *offset) >> PAGE_SHIFT);
-			unsigned int poff =
-					(sg->offset + *offset) & (PAGE_SIZE-1);
+			unsigned int poff = (sg->offset + *offset) &
+					    (PAGE_SIZE - 1);
 			unsigned int sglen = sg->length - *offset;
 
 			if (sglen > buflen - cnt) {
-- 
2.7.0



From shaun.ren at linux.com  Mon Feb  8 17:31:21 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon,  8 Feb 2016 17:31:21 -0800
Subject: [PATCH v2 5/9] Staging: rts5208: rtsx_transport.c: Remove extra
 newlines
In-Reply-To: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1454981485-15686-6-git-send-email-shaun.ren@linux.com>

This patch fixes the following issues in rtsx_transport.c as reported by
checkpatch.pl:

CHECK: Blank lines aren't necessary after an open brace '{'
CHECK: Please don't use multiple blank lines

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 901c64a..73302af 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -90,12 +90,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 			unsigned int sglen = sg->length - *offset;
 
 			if (sglen > buflen - cnt) {
-
 				/* Transfer ends within this s-g entry */
 				sglen = buflen - cnt;
 				*offset += sglen;
 			} else {
-
 				/* Transfer continues to next s-g entry */
 				*offset = 0;
 				++*index;
@@ -155,7 +153,6 @@ void rtsx_stor_get_xfer_buf(unsigned char *buffer,
 		scsi_set_resid(srb, scsi_bufflen(srb) - buflen);
 }
 
-
 /***********************************************************************
  * Transport routines
  ***********************************************************************/
-- 
2.7.0



From shaun.ren at linux.com  Mon Feb  8 17:31:18 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon,  8 Feb 2016 17:31:18 -0800
Subject: [PATCH v2 2/9] Staging: rts5208: rtsx_transport.c: Align to open
 parenthesis
In-Reply-To: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1454981485-15686-3-git-send-email-shaun.ren@linux.com>

This patch fixes the alignment issue reported by checkpatch.pl:

CHECK: Alignment should match open parenthesis

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 61 ++++++++++++++++++--------------
 1 file changed, 35 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 3e3f6fb..67162f6 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -40,8 +40,11 @@
  */
 
 unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
-	unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
-	unsigned int *offset, enum xfer_buf_dir dir)
+				       unsigned int buflen,
+				       struct scsi_cmnd *srb,
+				       unsigned int *index,
+				       unsigned int *offset,
+				     enum xfer_buf_dir dir)
 {
 	unsigned int cnt;
 
@@ -54,10 +57,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 		cnt = min(buflen, scsi_bufflen(srb) - *offset);
 		if (dir == TO_XFER_BUF)
 			memcpy((unsigned char *) scsi_sglist(srb) + *offset,
-					buffer, cnt);
+			       buffer, cnt);
 		else
 			memcpy(buffer, (unsigned char *) scsi_sglist(srb) +
-					*offset, cnt);
+			       *offset, cnt);
 		*offset += cnt;
 
 	/* Using scatter-gather.  We have to go through the list one entry
@@ -131,7 +134,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
  * SCSI residue.
  */
 void rtsx_stor_set_xfer_buf(unsigned char *buffer,
-	unsigned int buflen, struct scsi_cmnd *srb)
+			    unsigned int buflen, struct scsi_cmnd *srb)
 {
 	unsigned int index = 0, offset = 0;
 
@@ -142,7 +145,7 @@ void rtsx_stor_set_xfer_buf(unsigned char *buffer,
 }
 
 void rtsx_stor_get_xfer_buf(unsigned char *buffer,
-	unsigned int buflen, struct scsi_cmnd *srb)
+			    unsigned int buflen, struct scsi_cmnd *srb)
 {
 	unsigned int index = 0, offset = 0;
 
@@ -194,8 +197,8 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 		/* set the result so the higher layers expect this data */
 		srb->result = SAM_STAT_CHECK_CONDITION;
 		memcpy(srb->sense_buffer,
-			(unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
-			sizeof(struct sense_data_t));
+		       (unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
+		       sizeof(struct sense_data_t));
 	}
 
 	return;
@@ -209,7 +212,7 @@ Handle_Errors:
 }
 
 void rtsx_add_cmd(struct rtsx_chip *chip,
-		u8 cmd_type, u16 reg_addr, u8 mask, u8 data)
+		  u8 cmd_type, u16 reg_addr, u8 mask, u8 data)
 {
 	u32 *cb = (u32 *)(chip->host_cmds_ptr);
 	u32 val = 0;
@@ -328,9 +331,11 @@ static inline void rtsx_add_sg_tbl(
 }
 
 static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
-		struct scatterlist *sg, int num_sg, unsigned int *index,
-		unsigned int *offset, int size,
-		enum dma_data_direction dma_dir, int timeout)
+					     struct scatterlist *sg, int num_sg,
+					     unsigned int *index,
+					     unsigned int *offset, int size,
+					     enum dma_data_direction dma_dir,
+					     int timeout)
 {
 	struct rtsx_dev *rtsx = chip->rtsx;
 	struct completion trans_done;
@@ -492,8 +497,9 @@ out:
 }
 
 static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
-		struct scatterlist *sg, int num_sg,
-		enum dma_data_direction dma_dir, int timeout)
+				     struct scatterlist *sg, int num_sg,
+				     enum dma_data_direction dma_dir,
+				     int timeout)
 {
 	struct rtsx_dev *rtsx = chip->rtsx;
 	struct completion trans_done;
@@ -639,7 +645,8 @@ out:
 }
 
 static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
-		size_t len, enum dma_data_direction dma_dir, int timeout)
+			     size_t len, enum dma_data_direction dma_dir,
+			     int timeout)
 {
 	struct rtsx_dev *rtsx = chip->rtsx;
 	struct completion trans_done;
@@ -722,9 +729,9 @@ out:
 }
 
 int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
-		void *buf, size_t len, int use_sg, unsigned int *index,
-		unsigned int *offset, enum dma_data_direction dma_dir,
-		int timeout)
+			       void *buf, size_t len, int use_sg,
+			       unsigned int *index, unsigned int *offset,
+			       enum dma_data_direction dma_dir, int timeout)
 {
 	int err = 0;
 
@@ -732,11 +739,13 @@ int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
 	if (rtsx_chk_stat(chip, RTSX_STAT_ABORT))
 		return -EIO;
 
-	if (use_sg)
-		err = rtsx_transfer_sglist_adma_partial(chip, card,
-				(struct scatterlist *)buf, use_sg,
-				index, offset, (int)len, dma_dir, timeout);
-	else
+	if (use_sg) {
+		struct scatterlist *sg = (struct scatterlist *)buf;
+
+		err = rtsx_transfer_sglist_adma_partial(chip, card, sg, use_sg,
+							index, offset, (int)len,
+							dma_dir, timeout);
+	} else
 		err = rtsx_transfer_buf(chip, card,
 					buf, len, dma_dir, timeout);
 	if (err < 0) {
@@ -751,7 +760,7 @@ int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
 }
 
 int rtsx_transfer_data(struct rtsx_chip *chip, u8 card, void *buf, size_t len,
-		int use_sg, enum dma_data_direction dma_dir, int timeout)
+		       int use_sg, enum dma_data_direction dma_dir, int timeout)
 {
 	int err = 0;
 
@@ -763,8 +772,8 @@ int rtsx_transfer_data(struct rtsx_chip *chip, u8 card, void *buf, size_t len,
 
 	if (use_sg) {
 		err = rtsx_transfer_sglist_adma(chip, card,
-				(struct scatterlist *)buf,
-				use_sg, dma_dir, timeout);
+						(struct scatterlist *)buf,
+						use_sg, dma_dir, timeout);
 	} else {
 		err = rtsx_transfer_buf(chip, card, buf, len, dma_dir, timeout);
 	}
-- 
2.7.0



From shaun.ren at linux.com  Mon Feb  8 17:31:23 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon,  8 Feb 2016 17:31:23 -0800
Subject: [PATCH v2 7/9] Staging: rts5208: rtsx_transport.c: Remove unnecessary
 parentheses
In-Reply-To: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1454981485-15686-8-git-send-email-shaun.ren@linux.com>

This patch removes all unnecessary parentheses found by checkpatch.pl.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index ca209c6..fa062f6 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -194,7 +194,7 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 		/* set the result so the higher layers expect this data */
 		srb->result = SAM_STAT_CHECK_CONDITION;
 		memcpy(srb->sense_buffer,
-		       (unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
+		       (unsigned char *)&chip->sense_buffer[SCSI_LUN(srb)],
 		       sizeof(struct sense_data_t));
 	}
 
@@ -372,7 +372,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
 
 	spin_unlock_irq(&rtsx->reg_lock);
 
-	sg_cnt = dma_map_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	sg_cnt = dma_map_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	resid = size;
 	sg_ptr = sg;
@@ -485,7 +485,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
 out:
 	rtsx->done = NULL;
 	rtsx->trans_state = STATE_TRANS_NONE;
-	dma_unmap_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	dma_unmap_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	if (err < 0)
 		rtsx_stop_cmd(chip, card);
@@ -535,7 +535,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
 
 	spin_unlock_irq(&rtsx->reg_lock);
 
-	buf_cnt = dma_map_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	buf_cnt = dma_map_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	sg_ptr = sg;
 
@@ -633,7 +633,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
 out:
 	rtsx->done = NULL;
 	rtsx->trans_state = STATE_TRANS_NONE;
-	dma_unmap_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	dma_unmap_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	if (err < 0)
 		rtsx_stop_cmd(chip, card);
@@ -663,7 +663,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
 	else
 		return -ENXIO;
 
-	addr = dma_map_single(&(rtsx->pci->dev), buf, len, dma_dir);
+	addr = dma_map_single(&rtsx->pci->dev, buf, len, dma_dir);
 	if (!addr)
 		return -ENOMEM;
 
@@ -717,7 +717,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
 out:
 	rtsx->done = NULL;
 	rtsx->trans_state = STATE_TRANS_NONE;
-	dma_unmap_single(&(rtsx->pci->dev), addr, len, dma_dir);
+	dma_unmap_single(&rtsx->pci->dev, addr, len, dma_dir);
 
 	if (err < 0)
 		rtsx_stop_cmd(chip, card);
-- 
2.7.0



From shaun.ren at linux.com  Mon Feb  8 17:31:22 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon,  8 Feb 2016 17:31:22 -0800
Subject: [PATCH v2 6/9] Staging: rts5208: rtsx_transport.c: Fix label naming
 convention
In-Reply-To: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1454981485-15686-7-git-send-email-shaun.ren@linux.com>

This patch fixes the following naming convention issue in rtsx_transport.c,
as reported by checkpatch.pl:

CHECK: Avoid CamelCase: <Handle_Errors>

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 73302af..ca209c6 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -173,14 +173,14 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 	if (rtsx_chk_stat(chip, RTSX_STAT_ABORT)) {
 		dev_dbg(rtsx_dev(chip), "-- command was aborted\n");
 		srb->result = DID_ABORT << 16;
-		goto Handle_Errors;
+		goto handle_errors;
 	}
 
 	/* if there is a transport error, reset and don't auto-sense */
 	if (result == TRANSPORT_ERROR) {
 		dev_dbg(rtsx_dev(chip), "-- transport indicates error, resetting\n");
 		srb->result = DID_ERROR << 16;
-		goto Handle_Errors;
+		goto handle_errors;
 	}
 
 	srb->result = SAM_STAT_GOOD;
@@ -204,7 +204,7 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 	 * by issuing a port reset.  If that fails, try a class-specific
 	 * device reset.
 	 */
-Handle_Errors:
+handle_errors:
 	return;
 }
 
-- 
2.7.0



From shaun.ren at linux.com  Mon Feb  8 17:31:24 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon,  8 Feb 2016 17:31:24 -0800
Subject: [PATCH v2 8/9] Staging: rts5208: rtsx_transport.c: Fix comparisons to
 NULL
In-Reply-To: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1454981485-15686-9-git-send-email-shaun.ren@linux.com>

This patch changes all comparsions to NULL with !..., as reported by
checkpatch.pl.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index fa062f6..c0fd8c5 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -343,7 +343,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
 	struct scatterlist *sg_ptr;
 	u32 val = TRIG_DMA;
 
-	if ((sg == NULL) || (num_sg <= 0) || !offset || !index)
+	if (!sg || (num_sg <= 0) || !offset || !index)
 		return -EIO;
 
 	if (dma_dir == DMA_TO_DEVICE)
@@ -506,7 +506,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
 	long timeleft;
 	struct scatterlist *sg_ptr;
 
-	if ((sg == NULL) || (num_sg <= 0))
+	if (!sg || (num_sg <= 0))
 		return -EIO;
 
 	if (dma_dir == DMA_TO_DEVICE)
@@ -653,7 +653,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
 	u32 val = 1 << 31;
 	long timeleft;
 
-	if ((buf == NULL) || (len <= 0))
+	if (!buf || (len <= 0))
 		return -EIO;
 
 	if (dma_dir == DMA_TO_DEVICE)
-- 
2.7.0



From shaun.ren at linux.com  Mon Feb  8 17:31:25 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon,  8 Feb 2016 17:31:25 -0800
Subject: [PATCH v2 9/9] Staging: rts5208: Add missing dma_mapping_error
In-Reply-To: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1454981485-15686-10-git-send-email-shaun.ren@linux.com>

This patch adds a dma_mapping_error call to debug potential DMA mapping
errors after the dma_map_single call in rtsx_transport.c.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index c0fd8c5..00da7ab 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -664,7 +664,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
 		return -ENXIO;
 
 	addr = dma_map_single(&rtsx->pci->dev, buf, len, dma_dir);
-	if (!addr)
+	if (dma_mapping_error(&rtsx->pci->dev, addr))
 		return -ENOMEM;
 
 	if (card == SD_CARD)
-- 
2.7.0



From sboyd at codeaurora.org  Mon Feb  8 17:45:34 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Feb 2016 17:45:34 -0800
Subject: [PATCH 07/14] clk: gate: Add hw based registration APIs
In-Reply-To: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1454982341-22715-8-git-send-email-sboyd@codeaurora.org>

Add registration APIs in the clk gate code to return struct
clk_hw pointers instead of struct clk pointers. This way we hide
the struct clk pointer from providers unless they need to use
consumer facing APIs.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clk-gate.c       | 43 ++++++++++++++++++++++++++++++++++++-------
 include/linux/clk-provider.h |  5 +++++
 2 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index de0b322f5f58..3559a05dad15 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -112,7 +112,7 @@ const struct clk_ops clk_gate_ops = {
 EXPORT_SYMBOL_GPL(clk_gate_ops);
 
 /**
- * clk_register_gate - register a gate clock with the clock framework
+ * clk_hw_register_gate - register a gate clock with the clock framework
  * @dev: device that is registering this clock
  * @name: name of this clock
  * @parent_name: name of this clock's parent
@@ -122,14 +122,15 @@ EXPORT_SYMBOL_GPL(clk_gate_ops);
  * @clk_gate_flags: gate-specific flags for this clock
  * @lock: shared register lock for this clock
  */
-struct clk *clk_register_gate(struct device *dev, const char *name,
+struct clk_hw *clk_hw_register_gate(struct device *dev, const char *name,
 		const char *parent_name, unsigned long flags,
 		void __iomem *reg, u8 bit_idx,
 		u8 clk_gate_flags, spinlock_t *lock)
 {
 	struct clk_gate *gate;
-	struct clk *clk;
+	struct clk_hw *hw;
 	struct clk_init_data init;
+	int ret;
 
 	if (clk_gate_flags & CLK_GATE_HIWORD_MASK) {
 		if (bit_idx > 15) {
@@ -156,12 +157,29 @@ struct clk *clk_register_gate(struct device *dev, const char *name,
 	gate->lock = lock;
 	gate->hw.init = &init;
 
-	clk = clk_register(dev, &gate->hw);
-
-	if (IS_ERR(clk))
+	hw = &gate->hw;
+	ret = clk_hw_register(dev, hw);
+	if (ret) {
 		kfree(gate);
+		hw = ERR_PTR(ret);
+	}
 
-	return clk;
+	return hw;
+}
+EXPORT_SYMBOL_GPL(clk_hw_register_gate);
+
+struct clk *clk_register_gate(struct device *dev, const char *name,
+		const char *parent_name, unsigned long flags,
+		void __iomem *reg, u8 bit_idx,
+		u8 clk_gate_flags, spinlock_t *lock)
+{
+	struct clk_hw *hw;
+
+	hw = clk_hw_register_gate(dev, name, parent_name, flags, reg,
+				  bit_idx, clk_gate_flags, lock);
+	if (IS_ERR(hw))
+		return ERR_CAST(hw);
+	return hw->clk;
 }
 EXPORT_SYMBOL_GPL(clk_register_gate);
 
@@ -180,3 +198,14 @@ void clk_unregister_gate(struct clk *clk)
 	kfree(gate);
 }
 EXPORT_SYMBOL_GPL(clk_unregister_gate);
+
+void clk_hw_unregister_gate(struct clk_hw *hw)
+{
+	struct clk_gate *gate;
+
+	gate = to_clk_gate(hw);
+
+	clk_hw_unregister(hw);
+	kfree(gate);
+}
+EXPORT_SYMBOL_GPL(clk_hw_unregister_gate);
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 666462958ef2..b9a83216255b 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -322,7 +322,12 @@ struct clk *clk_register_gate(struct device *dev, const char *name,
 		const char *parent_name, unsigned long flags,
 		void __iomem *reg, u8 bit_idx,
 		u8 clk_gate_flags, spinlock_t *lock);
+struct clk_hw *clk_hw_register_gate(struct device *dev, const char *name,
+		const char *parent_name, unsigned long flags,
+		void __iomem *reg, u8 bit_idx,
+		u8 clk_gate_flags, spinlock_t *lock);
 void clk_unregister_gate(struct clk *clk);
+void clk_hw_unregister_gate(struct clk_hw *hw);
 
 struct clk_div_table {
 	unsigned int	val;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From sboyd at codeaurora.org  Mon Feb  8 17:45:28 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Feb 2016 17:45:28 -0800
Subject: [PATCH 01/14] mfd: intel_quark_i2c_gpio: Use clkdev_create()
In-Reply-To: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1454982341-22715-2-git-send-email-sboyd@codeaurora.org>

Convert this driver to use clkdev_create() instead of
clk_register_clkdevs(). The latter API is only used by this driver,
although this driver only allocates one clk to add anyway.
Furthermore, this driver allocates the clk_lookup structure with
devm, but clkdev_drop() will free that structure when passed,
leading to a double free when this driver is removed. Clean it
all up and pave the way for the removal of clk_register_clkdevs().

Cc: Lee Jones <lee.jones at linaro.org>
Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/mfd/intel_quark_i2c_gpio.c | 26 +++++++++-----------------
 1 file changed, 9 insertions(+), 17 deletions(-)

diff --git a/drivers/mfd/intel_quark_i2c_gpio.c b/drivers/mfd/intel_quark_i2c_gpio.c
index 042137465300..bdc5e27222c0 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -52,8 +52,6 @@
 /* The Quark I2C controller source clock */
 #define INTEL_QUARK_I2C_CLK_HZ	33000000
 
-#define INTEL_QUARK_I2C_NCLK	1
-
 struct intel_quark_mfd {
 	struct pci_dev		*pdev;
 	struct clk		*i2c_clk;
@@ -128,30 +126,24 @@ MODULE_DEVICE_TABLE(pci, intel_quark_mfd_ids);
 static int intel_quark_register_i2c_clk(struct intel_quark_mfd *quark_mfd)
 {
 	struct pci_dev *pdev = quark_mfd->pdev;
-	struct clk_lookup *i2c_clk_lookup;
 	struct clk *i2c_clk;
-	int ret;
-
-	i2c_clk_lookup = devm_kcalloc(&pdev->dev, INTEL_QUARK_I2C_NCLK,
-				      sizeof(*i2c_clk_lookup), GFP_KERNEL);
-	if (!i2c_clk_lookup)
-		return -ENOMEM;
-
-	i2c_clk_lookup[0].dev_id = INTEL_QUARK_I2C_CONTROLLER_CLK;
 
 	i2c_clk = clk_register_fixed_rate(&pdev->dev,
 					  INTEL_QUARK_I2C_CONTROLLER_CLK, NULL,
 					  CLK_IS_ROOT, INTEL_QUARK_I2C_CLK_HZ);
+	if (IS_ERR(i2c_clk))
+		return PTR_ERR(i2c_clk);
 
-	quark_mfd->i2c_clk_lookup = i2c_clk_lookup;
 	quark_mfd->i2c_clk = i2c_clk;
+	quark_mfd->i2c_clk_lookup = clkdev_create(i2c_clk, NULL,
+						INTEL_QUARK_I2C_CONTROLLER_CLK);
 
-	ret = clk_register_clkdevs(i2c_clk, i2c_clk_lookup,
-				   INTEL_QUARK_I2C_NCLK);
-	if (ret)
-		dev_err(&pdev->dev, "Fixed clk register failed: %d\n", ret);
+	if (!quark_mfd->i2c_clk_lookup) {
+		dev_err(&pdev->dev, "Fixed clk register failed\n");
+		return -ENOMEM;
+	}
 
-	return ret;
+	return 0;
 }
 
 static void intel_quark_unregister_i2c_clk(struct pci_dev *pdev)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From sboyd at codeaurora.org  Mon Feb  8 17:45:32 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Feb 2016 17:45:32 -0800
Subject: [PATCH 05/14] clkdev: Add clk_hw based registration APIs
In-Reply-To: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1454982341-22715-6-git-send-email-sboyd@codeaurora.org>

Now that we have a clk registration API that doesn't return
struct clks, we need to have some way to hand out struct clks via
the clk_get() APIs that doesn't involve associating struct clk
pointers with a struct clk_lookup. Luckily, clkdev already
operates on struct clk_hw pointers, except for the registration
facing APIs where it converts struct clk pointers into struct
clk_hw pointers almost immediately.

Let's add clk_hw based registration APIs so that we can skip the
conversion step and provide a way for clk provider drivers to
operate exclusively on clk_hw structs. This way we clearly
split the API between consumers and providers.

Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clkdev.c   | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/clkdev.h |  7 ++++++
 2 files changed, 67 insertions(+)

diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index ae61f2e57048..485d3b141843 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -301,6 +301,20 @@ clkdev_alloc(struct clk *clk, const char *con_id, const char *dev_fmt, ...)
 }
 EXPORT_SYMBOL(clkdev_alloc);
 
+struct clk_lookup *
+clkdev_hw_alloc(struct clk_hw *hw, const char *con_id, const char *dev_fmt, ...)
+{
+	struct clk_lookup *cl;
+	va_list ap;
+
+	va_start(ap, dev_fmt);
+	cl = vclkdev_alloc(hw, con_id, dev_fmt, ap);
+	va_end(ap);
+
+	return cl;
+}
+EXPORT_SYMBOL(clkdev_hw_alloc);
+
 /**
  * clkdev_create - allocate and add a clkdev lookup structure
  * @clk: struct clk to associate with all clk_lookups
@@ -324,6 +338,29 @@ struct clk_lookup *clkdev_create(struct clk *clk, const char *con_id,
 }
 EXPORT_SYMBOL_GPL(clkdev_create);
 
+/**
+ * clkdev_hw_create - allocate and add a clkdev lookup structure
+ * @hw: struct clk_hw to associate with all clk_lookups
+ * @con_id: connection ID string on device
+ * @dev_fmt: format string describing device name
+ *
+ * Returns a clk_lookup structure, which can be later unregistered and
+ * freed.
+ */
+struct clk_lookup *clkdev_hw_create(struct clk_hw *hw, const char *con_id,
+	const char *dev_fmt, ...)
+{
+	struct clk_lookup *cl;
+	va_list ap;
+
+	va_start(ap, dev_fmt);
+	cl = vclkdev_create(hw, con_id, dev_fmt, ap);
+	va_end(ap);
+
+	return cl;
+}
+EXPORT_SYMBOL_GPL(clkdev_hw_create);
+
 int clk_add_alias(const char *alias, const char *alias_dev_name,
 	const char *con_id, struct device *dev)
 {
@@ -383,3 +420,26 @@ int clk_register_clkdev(struct clk *clk, const char *con_id,
 	return cl ? 0 : -ENOMEM;
 }
 EXPORT_SYMBOL(clk_register_clkdev);
+
+/**
+ * clk_hw_register_clkdev - register one clock lookup for a struct clk_hw
+ * @hw: struct clk_hw to associate with all clk_lookups
+ * @con_id: connection ID string on device
+ * @dev_id: format string describing device name
+ *
+ * con_id or dev_id may be NULL as a wildcard, just as in the rest of
+ * clkdev.
+ */
+int clk_hw_register_clkdev(struct clk_hw *hw, const char *con_id,
+	const char *dev_fmt, ...)
+{
+	struct clk_lookup *cl;
+	va_list ap;
+
+	va_start(ap, dev_fmt);
+	cl = vclkdev_create(hw, con_id, dev_fmt, ap);
+	va_end(ap);
+
+	return cl ? 0 : -ENOMEM;
+}
+EXPORT_SYMBOL(clk_hw_register_clkdev);
diff --git a/include/linux/clkdev.h b/include/linux/clkdev.h
index 43a8c2e8ac29..5084295617dc 100644
--- a/include/linux/clkdev.h
+++ b/include/linux/clkdev.h
@@ -15,6 +15,7 @@
 #include <asm/clkdev.h>
 
 struct clk;
+struct clk_hw;
 struct device;
 
 struct clk_lookup {
@@ -34,18 +35,24 @@ struct clk_lookup {
 
 struct clk_lookup *clkdev_alloc(struct clk *clk, const char *con_id,
 	const char *dev_fmt, ...) __printf(3, 4);
+struct clk_lookup *clkdev_hw_alloc(struct clk_hw *hw, const char *con_id,
+	const char *dev_fmt, ...) __printf(3, 4);
 
 void clkdev_add(struct clk_lookup *cl);
 void clkdev_drop(struct clk_lookup *cl);
 
 struct clk_lookup *clkdev_create(struct clk *clk, const char *con_id,
 	const char *dev_fmt, ...) __printf(3, 4);
+struct clk_lookup *clkdev_hw_create(struct clk_hw *hw, const char *con_id,
+	const char *dev_fmt, ...) __printf(3, 4);
 
 void clkdev_add_table(struct clk_lookup *, size_t);
 int clk_add_alias(const char *, const char *, const char *, struct device *);
 
 int clk_register_clkdev(struct clk *, const char *, const char *, ...)
 	__printf(3, 4);
+int clk_hw_register_clkdev(struct clk_hw *, const char *, const char *, ...)
+	__printf(3, 4);
 
 #ifdef CONFIG_COMMON_CLK
 int __clk_get(struct clk *clk);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From sboyd at codeaurora.org  Mon Feb  8 17:45:33 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Feb 2016 17:45:33 -0800
Subject: [PATCH 06/14] clk: divider: Add hw based registration APIs
In-Reply-To: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1454982341-22715-7-git-send-email-sboyd@codeaurora.org>

Add registration APIs in the clk divider code to return struct
clk_hw pointers instead of struct clk pointers. This way we hide
the struct clk pointer from providers unless they need to use
consumer facing APIs.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clk-divider.c    | 91 ++++++++++++++++++++++++++++++++++++++++----
 include/linux/clk-provider.h | 10 +++++
 2 files changed, 93 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index ded3ff4b91b9..65ea60c32856 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -423,15 +423,16 @@ const struct clk_ops clk_divider_ops = {
 };
 EXPORT_SYMBOL_GPL(clk_divider_ops);
 
-static struct clk *_register_divider(struct device *dev, const char *name,
+static struct clk_hw *_register_divider(struct device *dev, const char *name,
 		const char *parent_name, unsigned long flags,
 		void __iomem *reg, u8 shift, u8 width,
 		u8 clk_divider_flags, const struct clk_div_table *table,
 		spinlock_t *lock)
 {
 	struct clk_divider *div;
-	struct clk *clk;
+	struct clk_hw *hw;
 	struct clk_init_data init;
+	int ret;
 
 	if (clk_divider_flags & CLK_DIVIDER_HIWORD_MASK) {
 		if (width + shift > 16) {
@@ -461,12 +462,14 @@ static struct clk *_register_divider(struct device *dev, const char *name,
 	div->table = table;
 
 	/* register the clock */
-	clk = clk_register(dev, &div->hw);
-
-	if (IS_ERR(clk))
+	hw = &div->hw;
+	ret = clk_hw_register(dev, hw);
+	if (ret) {
 		kfree(div);
+		hw = ERR_PTR(ret);
+	}
 
-	return clk;
+	return hw;
 }
 
 /**
@@ -486,12 +489,39 @@ struct clk *clk_register_divider(struct device *dev, const char *name,
 		void __iomem *reg, u8 shift, u8 width,
 		u8 clk_divider_flags, spinlock_t *lock)
 {
-	return _register_divider(dev, name, parent_name, flags, reg, shift,
+	struct clk_hw *hw;
+
+	hw =  _register_divider(dev, name, parent_name, flags, reg, shift,
 			width, clk_divider_flags, NULL, lock);
+	if (IS_ERR(hw))
+		return ERR_CAST(hw);
+	return hw->clk;
 }
 EXPORT_SYMBOL_GPL(clk_register_divider);
 
 /**
+ * clk_hw_register_divider - register a divider clock with the clock framework
+ * @dev: device registering this clock
+ * @name: name of this clock
+ * @parent_name: name of clock's parent
+ * @flags: framework-specific flags
+ * @reg: register address to adjust divider
+ * @shift: number of bits to shift the bitfield
+ * @width: width of the bitfield
+ * @clk_divider_flags: divider-specific flags for this clock
+ * @lock: shared register lock for this clock
+ */
+struct clk_hw *clk_hw_register_divider(struct device *dev, const char *name,
+		const char *parent_name, unsigned long flags,
+		void __iomem *reg, u8 shift, u8 width,
+		u8 clk_divider_flags, spinlock_t *lock)
+{
+	return _register_divider(dev, name, parent_name, flags, reg, shift,
+			width, clk_divider_flags, NULL, lock);
+}
+EXPORT_SYMBOL_GPL(clk_hw_register_divider);
+
+/**
  * clk_register_divider_table - register a table based divider clock with
  * the clock framework
  * @dev: device registering this clock
@@ -511,11 +541,41 @@ struct clk *clk_register_divider_table(struct device *dev, const char *name,
 		u8 clk_divider_flags, const struct clk_div_table *table,
 		spinlock_t *lock)
 {
-	return _register_divider(dev, name, parent_name, flags, reg, shift,
+	struct clk_hw *hw;
+
+	hw =  _register_divider(dev, name, parent_name, flags, reg, shift,
 			width, clk_divider_flags, table, lock);
+	if (IS_ERR(hw))
+		return ERR_CAST(hw);
+	return hw->clk;
 }
 EXPORT_SYMBOL_GPL(clk_register_divider_table);
 
+/**
+ * clk_hw_register_divider_table - register a table based divider clock with
+ * the clock framework
+ * @dev: device registering this clock
+ * @name: name of this clock
+ * @parent_name: name of clock's parent
+ * @flags: framework-specific flags
+ * @reg: register address to adjust divider
+ * @shift: number of bits to shift the bitfield
+ * @width: width of the bitfield
+ * @clk_divider_flags: divider-specific flags for this clock
+ * @table: array of divider/value pairs ending with a div set to 0
+ * @lock: shared register lock for this clock
+ */
+struct clk_hw *clk_hw_register_divider_table(struct device *dev,
+		const char *name, const char *parent_name, unsigned long flags,
+		void __iomem *reg, u8 shift, u8 width,
+		u8 clk_divider_flags, const struct clk_div_table *table,
+		spinlock_t *lock)
+{
+	return _register_divider(dev, name, parent_name, flags, reg, shift,
+			width, clk_divider_flags, table, lock);
+}
+EXPORT_SYMBOL_GPL(clk_hw_register_divider_table);
+
 void clk_unregister_divider(struct clk *clk)
 {
 	struct clk_divider *div;
@@ -531,3 +591,18 @@ void clk_unregister_divider(struct clk *clk)
 	kfree(div);
 }
 EXPORT_SYMBOL_GPL(clk_unregister_divider);
+
+/**
+ * clk_hw_unregister_divider - unregister a clk divider
+ * @hw: hardware-specific clock data to unregister
+ */
+void clk_hw_unregister_divider(struct clk_hw *hw)
+{
+	struct clk_divider *div;
+
+	div = to_clk_divider(hw);
+
+	clk_hw_unregister(hw);
+	kfree(div);
+}
+EXPORT_SYMBOL_GPL(clk_hw_unregister_divider);
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1af1afae05f8..666462958ef2 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -400,12 +400,22 @@ struct clk *clk_register_divider(struct device *dev, const char *name,
 		const char *parent_name, unsigned long flags,
 		void __iomem *reg, u8 shift, u8 width,
 		u8 clk_divider_flags, spinlock_t *lock);
+struct clk_hw *clk_hw_register_divider(struct device *dev, const char *name,
+		const char *parent_name, unsigned long flags,
+		void __iomem *reg, u8 shift, u8 width,
+		u8 clk_divider_flags, spinlock_t *lock);
 struct clk *clk_register_divider_table(struct device *dev, const char *name,
 		const char *parent_name, unsigned long flags,
 		void __iomem *reg, u8 shift, u8 width,
 		u8 clk_divider_flags, const struct clk_div_table *table,
 		spinlock_t *lock);
+struct clk_hw *clk_hw_register_divider_table(struct device *dev,
+		const char *name, const char *parent_name, unsigned long flags,
+		void __iomem *reg, u8 shift, u8 width,
+		u8 clk_divider_flags, const struct clk_div_table *table,
+		spinlock_t *lock);
 void clk_unregister_divider(struct clk *clk);
+void clk_hw_unregister_divider(struct clk_hw *hw);
 
 /**
  * struct clk_mux - multiplexer clock
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From sboyd at codeaurora.org  Mon Feb  8 17:45:27 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Feb 2016 17:45:27 -0800
Subject: [PATCH 00/14] clk_hw based clkdev/DT providers
Message-ID: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>

We've mostly split the clk API between consumers and providers
along struct clk and struct clk_hw, but the registration and
clkdev/DT code is still struct clk focused. This series
lays the foundation for changing that design by making
clk_register() return an int instead of a struct clk and
clkdev/DT lookups take a struct clk_hw instead of a struct clk.

After this series is applied, we can avoid using struct clk
in provider drivers entirely, unless we want to use the consumer
APIs. There are quite a few registration callers, so this change
will require converting all of them. I plan to do that gradually
over the coming weeks, but I've included a change to qcom
platforms because I could easily test it and show how things
will work.

The first two patches are cleanups to clkdev APIs that I found
while doing this work. I'd like to take those into clk-next
with the appropriate acks. They're mostly included because
they cause merge conflicts otherwise.

Cc: Lee Jones <lee.jones at linaro.org>
Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Cc: Russell King <linux at arm.linux.org.uk>

Stephen Boyd (14):
  mfd: intel_quark_i2c_gpio: Use clkdev_create()
  clkdev: Remove clk_register_clkdevs()
  clk: Add {devm_}clk_hw_{register,unregister}() APIs
  clk: Add clk_hw OF clk providers
  clkdev: Add clk_hw based registration APIs
  clk: divider: Add hw based registration APIs
  clk: gate: Add hw based registration APIs
  clk: mux: Add hw based registration APIs
  clk: fixed-factor: Add hw based registration APIs
  clk: fractional-divider: Add hw based registration APIs
  clk: composite: Add hw based registration APIs
  clk: gpio: Add hw based registration APIs
  clk: fixed-rate: Add hw based registration APIs
  clk: qcom: Migrate to clk_hw based registration and OF APIs

 Documentation/driver-model/devres.txt |   1 +
 drivers/clk/clk-composite.c           |  45 ++++++---
 drivers/clk/clk-divider.c             |  91 ++++++++++++++++--
 drivers/clk/clk-fixed-factor.c        |  41 ++++++--
 drivers/clk/clk-fixed-rate.c          |  44 +++++++--
 drivers/clk/clk-fractional-divider.c  |  40 +++++++-
 drivers/clk/clk-gate.c                |  43 +++++++--
 drivers/clk/clk-gpio.c                |  52 ++++++++---
 drivers/clk/clk-mux.c                 |  57 ++++++++++--
 drivers/clk/clk.c                     | 170 +++++++++++++++++++++++++++++++++-
 drivers/clk/clkdev.c                  |  71 ++++++++++----
 drivers/clk/qcom/clk-regmap.c         |   5 +-
 drivers/clk/qcom/clk-regmap.h         |   3 +-
 drivers/clk/qcom/common.c             |  41 ++++----
 drivers/clk/qcom/gcc-msm8996.c        |   9 +-
 drivers/clk/qcom/mmcc-msm8996.c       |   9 +-
 drivers/mfd/intel_quark_i2c_gpio.c    |  26 ++----
 include/linux/clk-provider.h          |  92 ++++++++++++++++++
 include/linux/clkdev.h                |   8 +-
 19 files changed, 706 insertions(+), 142 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From sboyd at codeaurora.org  Mon Feb  8 17:45:29 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Feb 2016 17:45:29 -0800
Subject: [PATCH 02/14] clkdev: Remove clk_register_clkdevs()
In-Reply-To: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1454982341-22715-3-git-send-email-sboyd@codeaurora.org>

Now that we've converted the only caller over to another clkdev
API, remove this one.

Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clkdev.c   | 27 ---------------------------
 include/linux/clkdev.h |  1 -
 2 files changed, 28 deletions(-)

diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 779b6ff0c7ad..ae61f2e57048 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -383,30 +383,3 @@ int clk_register_clkdev(struct clk *clk, const char *con_id,
 	return cl ? 0 : -ENOMEM;
 }
 EXPORT_SYMBOL(clk_register_clkdev);
-
-/**
- * clk_register_clkdevs - register a set of clk_lookup for a struct clk
- * @clk: struct clk to associate with all clk_lookups
- * @cl: array of clk_lookup structures with con_id and dev_id pre-initialized
- * @num: number of clk_lookup structures to register
- *
- * To make things easier for mass registration, we detect error clks
- * from a previous clk_register() call, and return the error code for
- * those.  This is to permit this function to be called immediately
- * after clk_register().
- */
-int clk_register_clkdevs(struct clk *clk, struct clk_lookup *cl, size_t num)
-{
-	unsigned i;
-
-	if (IS_ERR(clk))
-		return PTR_ERR(clk);
-
-	for (i = 0; i < num; i++, cl++) {
-		cl->clk_hw = __clk_get_hw(clk);
-		__clkdev_add(cl);
-	}
-
-	return 0;
-}
-EXPORT_SYMBOL(clk_register_clkdevs);
diff --git a/include/linux/clkdev.h b/include/linux/clkdev.h
index 08bffcc466de..43a8c2e8ac29 100644
--- a/include/linux/clkdev.h
+++ b/include/linux/clkdev.h
@@ -46,7 +46,6 @@ int clk_add_alias(const char *, const char *, const char *, struct device *);
 
 int clk_register_clkdev(struct clk *, const char *, const char *, ...)
 	__printf(3, 4);
-int clk_register_clkdevs(struct clk *, struct clk_lookup *, size_t);
 
 #ifdef CONFIG_COMMON_CLK
 int __clk_get(struct clk *clk);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From sboyd at codeaurora.org  Mon Feb  8 17:45:37 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Feb 2016 17:45:37 -0800
Subject: [PATCH 10/14] clk: fractional-divider: Add hw based registration APIs
In-Reply-To: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1454982341-22715-11-git-send-email-sboyd@codeaurora.org>

Add registration APIs in the clk fractional divider code to
return struct clk_hw pointers instead of struct clk pointers.
This way we hide the struct clk pointer from providers unless
they need to use consumer facing APIs.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clk-fractional-divider.c | 40 +++++++++++++++++++++++++++++++-----
 include/linux/clk-provider.h         |  5 +++++
 2 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/clk-fractional-divider.c b/drivers/clk/clk-fractional-divider.c
index 5c4955e33f7a..e7a315e840e6 100644
--- a/drivers/clk/clk-fractional-divider.c
+++ b/drivers/clk/clk-fractional-divider.c
@@ -118,14 +118,15 @@ const struct clk_ops clk_fractional_divider_ops = {
 };
 EXPORT_SYMBOL_GPL(clk_fractional_divider_ops);
 
-struct clk *clk_register_fractional_divider(struct device *dev,
+struct clk_hw *clk_hw_register_fractional_divider(struct device *dev,
 		const char *name, const char *parent_name, unsigned long flags,
 		void __iomem *reg, u8 mshift, u8 mwidth, u8 nshift, u8 nwidth,
 		u8 clk_divider_flags, spinlock_t *lock)
 {
 	struct clk_fractional_divider *fd;
 	struct clk_init_data init;
-	struct clk *clk;
+	struct clk_hw *hw;
+	int ret;
 
 	fd = kzalloc(sizeof(*fd), GFP_KERNEL);
 	if (!fd)
@@ -148,10 +149,39 @@ struct clk *clk_register_fractional_divider(struct device *dev,
 	fd->lock = lock;
 	fd->hw.init = &init;
 
-	clk = clk_register(dev, &fd->hw);
-	if (IS_ERR(clk))
+	hw = &fd->hw;
+	ret = clk_hw_register(dev, hw);
+	if (ret) {
 		kfree(fd);
+		hw = ERR_PTR(ret);
+	}
+
+	return hw;
+}
+EXPORT_SYMBOL_GPL(clk_hw_register_fractional_divider);
 
-	return clk;
+struct clk *clk_register_fractional_divider(struct device *dev,
+		const char *name, const char *parent_name, unsigned long flags,
+		void __iomem *reg, u8 mshift, u8 mwidth, u8 nshift, u8 nwidth,
+		u8 clk_divider_flags, spinlock_t *lock)
+{
+	struct clk_hw *hw;
+
+	hw = clk_hw_register_fractional_divider(dev, name, parent_name, flags,
+			reg, mshift, mwidth, nshift, nwidth, clk_divider_flags,
+			lock);
+	if (IS_ERR(hw))
+		return ERR_CAST(hw);
+	return hw->clk;
 }
 EXPORT_SYMBOL_GPL(clk_register_fractional_divider);
+
+void clk_hw_unregister_fractional_divider(struct clk_hw *hw)
+{
+	struct clk_fractional_divider *fd;
+
+	fd = to_clk_fd(hw);
+
+	clk_hw_unregister(hw);
+	kfree(fd);
+}
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index d4d65f60b85e..549ed3844876 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -549,6 +549,11 @@ struct clk *clk_register_fractional_divider(struct device *dev,
 		const char *name, const char *parent_name, unsigned long flags,
 		void __iomem *reg, u8 mshift, u8 mwidth, u8 nshift, u8 nwidth,
 		u8 clk_divider_flags, spinlock_t *lock);
+struct clk_hw *clk_hw_register_fractional_divider(struct device *dev,
+		const char *name, const char *parent_name, unsigned long flags,
+		void __iomem *reg, u8 mshift, u8 mwidth, u8 nshift, u8 nwidth,
+		u8 clk_divider_flags, spinlock_t *lock);
+void clk_hw_unregister_fractional_divider(struct clk_hw *hw);
 
 /**
  * struct clk_multiplier - adjustable multiplier clock
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From sboyd at codeaurora.org  Mon Feb  8 17:45:35 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Feb 2016 17:45:35 -0800
Subject: [PATCH 08/14] clk: mux: Add hw based registration APIs
In-Reply-To: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1454982341-22715-9-git-send-email-sboyd@codeaurora.org>

Add registration APIs in the clk mux code to return struct clk_hw
pointers instead of struct clk pointers. This way we hide the
struct clk pointer from providers unless they need to use
consumer facing APIs.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clk-mux.c        | 57 +++++++++++++++++++++++++++++++++++++++-----
 include/linux/clk-provider.h | 11 +++++++++
 2 files changed, 62 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 5ed03c8a8df9..6b0fcd3a4629 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -115,16 +115,17 @@ const struct clk_ops clk_mux_ro_ops = {
 };
 EXPORT_SYMBOL_GPL(clk_mux_ro_ops);
 
-struct clk *clk_register_mux_table(struct device *dev, const char *name,
+struct clk_hw *clk_hw_register_mux_table(struct device *dev, const char *name,
 		const char * const *parent_names, u8 num_parents,
 		unsigned long flags,
 		void __iomem *reg, u8 shift, u32 mask,
 		u8 clk_mux_flags, u32 *table, spinlock_t *lock)
 {
 	struct clk_mux *mux;
-	struct clk *clk;
+	struct clk_hw *hw;
 	struct clk_init_data init;
 	u8 width = 0;
+	int ret;
 
 	if (clk_mux_flags & CLK_MUX_HIWORD_MASK) {
 		width = fls(mask) - ffs(mask) + 1;
@@ -159,12 +160,31 @@ struct clk *clk_register_mux_table(struct device *dev, const char *name,
 	mux->table = table;
 	mux->hw.init = &init;
 
-	clk = clk_register(dev, &mux->hw);
-
-	if (IS_ERR(clk))
+	hw = &mux->hw;
+	ret = clk_hw_register(dev, hw);
+	if (ret) {
 		kfree(mux);
+		hw = ERR_PTR(ret);
+	}
 
-	return clk;
+	return hw;
+}
+EXPORT_SYMBOL_GPL(clk_hw_register_mux_table);
+
+struct clk *clk_register_mux_table(struct device *dev, const char *name,
+		const char * const *parent_names, u8 num_parents,
+		unsigned long flags,
+		void __iomem *reg, u8 shift, u32 mask,
+		u8 clk_mux_flags, u32 *table, spinlock_t *lock)
+{
+	struct clk_hw *hw;
+
+	hw = clk_hw_register_mux_table(dev, name, parent_names, num_parents,
+				       flags, reg, shift, mask, clk_mux_flags,
+				       table, lock);
+	if (IS_ERR(hw))
+		return ERR_CAST(hw);
+	return hw->clk;
 }
 EXPORT_SYMBOL_GPL(clk_register_mux_table);
 
@@ -182,6 +202,20 @@ struct clk *clk_register_mux(struct device *dev, const char *name,
 }
 EXPORT_SYMBOL_GPL(clk_register_mux);
 
+struct clk_hw *clk_hw_register_mux(struct device *dev, const char *name,
+		const char * const *parent_names, u8 num_parents,
+		unsigned long flags,
+		void __iomem *reg, u8 shift, u8 width,
+		u8 clk_mux_flags, spinlock_t *lock)
+{
+	u32 mask = BIT(width) - 1;
+
+	return clk_hw_register_mux_table(dev, name, parent_names, num_parents,
+				      flags, reg, shift, mask, clk_mux_flags,
+				      NULL, lock);
+}
+EXPORT_SYMBOL_GPL(clk_hw_register_mux);
+
 void clk_unregister_mux(struct clk *clk)
 {
 	struct clk_mux *mux;
@@ -197,3 +231,14 @@ void clk_unregister_mux(struct clk *clk)
 	kfree(mux);
 }
 EXPORT_SYMBOL_GPL(clk_unregister_mux);
+
+void clk_hw_unregister_mux(struct clk_hw *hw)
+{
+	struct clk_mux *mux;
+
+	mux = to_clk_mux(hw);
+
+	clk_hw_unregister(hw);
+	kfree(mux);
+}
+EXPORT_SYMBOL_GPL(clk_hw_unregister_mux);
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index b9a83216255b..df6353a086b9 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -469,14 +469,25 @@ struct clk *clk_register_mux(struct device *dev, const char *name,
 		unsigned long flags,
 		void __iomem *reg, u8 shift, u8 width,
 		u8 clk_mux_flags, spinlock_t *lock);
+struct clk_hw *clk_hw_register_mux(struct device *dev, const char *name,
+		const char * const *parent_names, u8 num_parents,
+		unsigned long flags,
+		void __iomem *reg, u8 shift, u8 width,
+		u8 clk_mux_flags, spinlock_t *lock);
 
 struct clk *clk_register_mux_table(struct device *dev, const char *name,
 		const char * const *parent_names, u8 num_parents,
 		unsigned long flags,
 		void __iomem *reg, u8 shift, u32 mask,
 		u8 clk_mux_flags, u32 *table, spinlock_t *lock);
+struct clk_hw *clk_hw_register_mux_table(struct device *dev, const char *name,
+		const char * const *parent_names, u8 num_parents,
+		unsigned long flags,
+		void __iomem *reg, u8 shift, u32 mask,
+		u8 clk_mux_flags, u32 *table, spinlock_t *lock);
 
 void clk_unregister_mux(struct clk *clk);
+void clk_hw_unregister_mux(struct clk_hw *hw);
 
 void of_fixed_factor_clk_setup(struct device_node *node);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From sboyd at codeaurora.org  Mon Feb  8 17:45:39 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Feb 2016 17:45:39 -0800
Subject: [PATCH 12/14] clk: gpio: Add hw based registration APIs
In-Reply-To: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1454982341-22715-13-git-send-email-sboyd@codeaurora.org>

Add registration APIs in the clk gpio code to return struct
clk_hw pointers instead of struct clk pointers. This way we hide
the struct clk pointer from providers unless they need to use
consumer facing APIs.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clk-gpio.c       | 52 ++++++++++++++++++++++++++++++++++----------
 include/linux/clk-provider.h |  8 +++++++
 2 files changed, 49 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 19fed65587e8..807a94486324 100644
--- a/drivers/clk/clk-gpio.c
+++ b/drivers/clk/clk-gpio.c
@@ -94,13 +94,13 @@ const struct clk_ops clk_gpio_mux_ops = {
 };
 EXPORT_SYMBOL_GPL(clk_gpio_mux_ops);
 
-static struct clk *clk_register_gpio(struct device *dev, const char *name,
+static struct clk_hw *clk_register_gpio(struct device *dev, const char *name,
 		const char * const *parent_names, u8 num_parents, unsigned gpio,
 		bool active_low, unsigned long flags,
 		const struct clk_ops *clk_gpio_ops)
 {
 	struct clk_gpio *clk_gpio;
-	struct clk *clk;
+	struct clk_hw *hw;
 	struct clk_init_data init = {};
 	unsigned long gpio_flags;
 	int err;
@@ -141,24 +141,26 @@ static struct clk *clk_register_gpio(struct device *dev, const char *name,
 	clk_gpio->gpiod = gpio_to_desc(gpio);
 	clk_gpio->hw.init = &init;
 
+	hw = &clk_gpio->hw;
 	if (dev)
-		clk = devm_clk_register(dev, &clk_gpio->hw);
+		err = devm_clk_hw_register(dev, hw);
 	else
-		clk = clk_register(NULL, &clk_gpio->hw);
+		err = clk_hw_register(NULL, hw);
 
-	if (!IS_ERR(clk))
-		return clk;
+	if (!err)
+		return hw;
 
 	if (!dev) {
 		gpiod_put(clk_gpio->gpiod);
 		kfree(clk_gpio);
 	}
 
-	return clk;
+	return ERR_PTR(err);
 }
 
 /**
- * clk_register_gpio_gate - register a gpio clock gate with the clock framework
+ * clk_hw_register_gpio_gate - register a gpio clock gate with the clock
+ * framework
  * @dev: device that is registering this clock
  * @name: name of this clock
  * @parent_name: name of this clock's parent
@@ -166,7 +168,7 @@ static struct clk *clk_register_gpio(struct device *dev, const char *name,
  * @active_low: true if gpio should be set to 0 to enable clock
  * @flags: clock flags
  */
-struct clk *clk_register_gpio_gate(struct device *dev, const char *name,
+struct clk_hw *clk_hw_register_gpio_gate(struct device *dev, const char *name,
 		const char *parent_name, unsigned gpio, bool active_low,
 		unsigned long flags)
 {
@@ -175,10 +177,24 @@ struct clk *clk_register_gpio_gate(struct device *dev, const char *name,
 			(parent_name ? 1 : 0), gpio, active_low, flags,
 			&clk_gpio_gate_ops);
 }
+EXPORT_SYMBOL_GPL(clk_hw_register_gpio_gate);
+
+struct clk *clk_register_gpio_gate(struct device *dev, const char *name,
+		const char *parent_name, unsigned gpio, bool active_low,
+		unsigned long flags)
+{
+	struct clk_hw *hw;
+
+	hw = clk_hw_register_gpio_gate(dev, name, parent_name, gpio, active_low,
+				       flags);
+	if (IS_ERR(hw))
+		return ERR_CAST(hw);
+	return hw->clk;
+}
 EXPORT_SYMBOL_GPL(clk_register_gpio_gate);
 
 /**
- * clk_register_gpio_mux - register a gpio clock mux with the clock framework
+ * clk_hw_register_gpio_mux - register a gpio clock mux with the clock framework
  * @dev: device that is registering this clock
  * @name: name of this clock
  * @parent_names: names of this clock's parents
@@ -187,7 +203,7 @@ EXPORT_SYMBOL_GPL(clk_register_gpio_gate);
  * @active_low: true if gpio should be set to 0 to enable clock
  * @flags: clock flags
  */
-struct clk *clk_register_gpio_mux(struct device *dev, const char *name,
+struct clk_hw *clk_hw_register_gpio_mux(struct device *dev, const char *name,
 		const char * const *parent_names, u8 num_parents, unsigned gpio,
 		bool active_low, unsigned long flags)
 {
@@ -199,6 +215,20 @@ struct clk *clk_register_gpio_mux(struct device *dev, const char *name,
 	return clk_register_gpio(dev, name, parent_names, num_parents,
 			gpio, active_low, flags, &clk_gpio_mux_ops);
 }
+EXPORT_SYMBOL_GPL(clk_hw_register_gpio_mux);
+
+struct clk *clk_register_gpio_mux(struct device *dev, const char *name,
+		const char * const *parent_names, u8 num_parents, unsigned gpio,
+		bool active_low, unsigned long flags)
+{
+	struct clk_hw *hw;
+
+	hw = clk_hw_register_gpio_mux(dev, name, parent_names, num_parents,
+			gpio, active_low, flags);
+	if (IS_ERR(hw))
+		return ERR_CAST(hw);
+	return hw->clk;
+}
 EXPORT_SYMBOL_GPL(clk_register_gpio_mux);
 
 #ifdef CONFIG_OF
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 64037ab95a31..148ad0dc2906 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -647,6 +647,10 @@ extern const struct clk_ops clk_gpio_gate_ops;
 struct clk *clk_register_gpio_gate(struct device *dev, const char *name,
 		const char *parent_name, unsigned gpio, bool active_low,
 		unsigned long flags);
+struct clk_hw *clk_hw_register_gpio_gate(struct device *dev, const char *name,
+		const char *parent_name, unsigned gpio, bool active_low,
+		unsigned long flags);
+void clk_hw_unregister_gpio_gate(struct clk_hw *hw);
 
 void of_gpio_clk_gate_setup(struct device_node *node);
 
@@ -664,6 +668,10 @@ extern const struct clk_ops clk_gpio_mux_ops;
 struct clk *clk_register_gpio_mux(struct device *dev, const char *name,
 		const char * const *parent_names, u8 num_parents, unsigned gpio,
 		bool active_low, unsigned long flags);
+struct clk_hw *clk_hw_register_gpio_mux(struct device *dev, const char *name,
+		const char * const *parent_names, u8 num_parents, unsigned gpio,
+		bool active_low, unsigned long flags);
+void clk_hw_unregister_gpio_mux(struct clk_hw *hw);
 
 void of_gpio_mux_clk_setup(struct device_node *node);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From sboyd at codeaurora.org  Mon Feb  8 17:45:38 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Feb 2016 17:45:38 -0800
Subject: [PATCH 11/14] clk: composite: Add hw based registration APIs
In-Reply-To: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1454982341-22715-12-git-send-email-sboyd@codeaurora.org>

Add registration APIs in the clk composite code to return struct
clk_hw pointers instead of struct clk pointers. This way we hide
the struct clk pointer from providers unless they need to use
consumer facing APIs.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clk-composite.c  | 45 ++++++++++++++++++++++++++++++++------------
 include/linux/clk-provider.h |  7 +++++++
 2 files changed, 40 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index 4735de0660cc..9c38a3563e8c 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -186,17 +186,18 @@ static void clk_composite_disable(struct clk_hw *hw)
 	gate_ops->disable(gate_hw);
 }
 
-struct clk *clk_register_composite(struct device *dev, const char *name,
+struct clk_hw *clk_hw_register_composite(struct device *dev, const char *name,
 			const char * const *parent_names, int num_parents,
 			struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
 			struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
 			struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
 			unsigned long flags)
 {
-	struct clk *clk;
+	struct clk_hw *hw;
 	struct clk_init_data init;
 	struct clk_composite *composite;
 	struct clk_ops *clk_composite_ops;
+	int ret;
 
 	composite = kzalloc(sizeof(*composite), GFP_KERNEL);
 	if (!composite)
@@ -206,12 +207,13 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
 	init.flags = flags | CLK_IS_BASIC;
 	init.parent_names = parent_names;
 	init.num_parents = num_parents;
+	hw = &composite->hw;
 
 	clk_composite_ops = &composite->ops;
 
 	if (mux_hw && mux_ops) {
 		if (!mux_ops->get_parent) {
-			clk = ERR_PTR(-EINVAL);
+			hw = ERR_PTR(-EINVAL);
 			goto err;
 		}
 
@@ -226,7 +228,7 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
 
 	if (rate_hw && rate_ops) {
 		if (!rate_ops->recalc_rate) {
-			clk = ERR_PTR(-EINVAL);
+			hw = ERR_PTR(-EINVAL);
 			goto err;
 		}
 		clk_composite_ops->recalc_rate = clk_composite_recalc_rate;
@@ -255,7 +257,7 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
 	if (gate_hw && gate_ops) {
 		if (!gate_ops->is_enabled || !gate_ops->enable ||
 		    !gate_ops->disable) {
-			clk = ERR_PTR(-EINVAL);
+			hw = ERR_PTR(-EINVAL);
 			goto err;
 		}
 
@@ -269,22 +271,41 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
 	init.ops = clk_composite_ops;
 	composite->hw.init = &init;
 
-	clk = clk_register(dev, &composite->hw);
-	if (IS_ERR(clk))
+	ret = clk_hw_register(dev, hw);
+	if (ret) {
+		hw = ERR_PTR(ret);
 		goto err;
+	}
 
 	if (composite->mux_hw)
-		composite->mux_hw->clk = clk;
+		composite->mux_hw->clk = hw->clk;
 
 	if (composite->rate_hw)
-		composite->rate_hw->clk = clk;
+		composite->rate_hw->clk = hw->clk;
 
 	if (composite->gate_hw)
-		composite->gate_hw->clk = clk;
+		composite->gate_hw->clk = hw->clk;
 
-	return clk;
+	return hw;
 
 err:
 	kfree(composite);
-	return clk;
+	return hw;
+}
+
+struct clk *clk_register_composite(struct device *dev, const char *name,
+			const char * const *parent_names, int num_parents,
+			struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
+			struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
+			struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
+			unsigned long flags)
+{
+	struct clk_hw *hw;
+
+	hw = clk_hw_register_composite(dev, name, parent_names, num_parents,
+			mux_hw, mux_ops, rate_hw, rate_ops, gate_hw, gate_ops,
+			flags);
+	if (IS_ERR(hw))
+		return ERR_CAST(hw);
+	return hw->clk;
 }
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 549ed3844876..64037ab95a31 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -620,6 +620,13 @@ struct clk *clk_register_composite(struct device *dev, const char *name,
 		struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
 		struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
 		unsigned long flags);
+struct clk_hw *clk_hw_register_composite(struct device *dev, const char *name,
+		const char * const *parent_names, int num_parents,
+		struct clk_hw *mux_hw, const struct clk_ops *mux_ops,
+		struct clk_hw *rate_hw, const struct clk_ops *rate_ops,
+		struct clk_hw *gate_hw, const struct clk_ops *gate_ops,
+		unsigned long flags);
+void clk_hw_unregister_composite(struct clk_hw *hw);
 
 /***
  * struct clk_gpio_gate - gpio gated clock
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From sboyd at codeaurora.org  Mon Feb  8 17:45:41 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Feb 2016 17:45:41 -0800
Subject: [PATCH 14/14] clk: qcom: Migrate to clk_hw based registration and OF
 APIs
In-Reply-To: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1454982341-22715-15-git-send-email-sboyd@codeaurora.org>

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/qcom/clk-regmap.c   |  5 ++---
 drivers/clk/qcom/clk-regmap.h   |  3 +--
 drivers/clk/qcom/common.c       | 41 +++++++++++++++++++----------------------
 drivers/clk/qcom/gcc-msm8996.c  |  9 ++++-----
 drivers/clk/qcom/mmcc-msm8996.c |  9 ++++-----
 5 files changed, 30 insertions(+), 37 deletions(-)

diff --git a/drivers/clk/qcom/clk-regmap.c b/drivers/clk/qcom/clk-regmap.c
index a58ba39a900c..1c856d330733 100644
--- a/drivers/clk/qcom/clk-regmap.c
+++ b/drivers/clk/qcom/clk-regmap.c
@@ -101,14 +101,13 @@ EXPORT_SYMBOL_GPL(clk_disable_regmap);
  * clk_regmap struct via this function so that the regmap is initialized
  * and so that the clock is registered with the common clock framework.
  */
-struct clk *devm_clk_register_regmap(struct device *dev,
-				     struct clk_regmap *rclk)
+int devm_clk_register_regmap(struct device *dev, struct clk_regmap *rclk)
 {
 	if (dev && dev_get_regmap(dev, NULL))
 		rclk->regmap = dev_get_regmap(dev, NULL);
 	else if (dev && dev->parent)
 		rclk->regmap = dev_get_regmap(dev->parent, NULL);
 
-	return devm_clk_register(dev, &rclk->hw);
+	return devm_clk_hw_register(dev, &rclk->hw);
 }
 EXPORT_SYMBOL_GPL(devm_clk_register_regmap);
diff --git a/drivers/clk/qcom/clk-regmap.h b/drivers/clk/qcom/clk-regmap.h
index 491a63d537df..90d95cd11ec6 100644
--- a/drivers/clk/qcom/clk-regmap.h
+++ b/drivers/clk/qcom/clk-regmap.h
@@ -39,7 +39,6 @@ struct clk_regmap {
 int clk_is_enabled_regmap(struct clk_hw *hw);
 int clk_enable_regmap(struct clk_hw *hw);
 void clk_disable_regmap(struct clk_hw *hw);
-struct clk *
-devm_clk_register_regmap(struct device *dev, struct clk_regmap *rclk);
+int devm_clk_register_regmap(struct device *dev, struct clk_regmap *rclk);
 
 #endif
diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index c112ebaba70d..16068af45f5d 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -27,8 +27,7 @@
 
 struct qcom_cc {
 	struct qcom_reset_controller reset;
-	struct clk_onecell_data data;
-	struct clk *clks[];
+	struct clk_hw_onecell_data data;
 };
 
 const
@@ -102,8 +101,8 @@ static int _qcom_cc_register_board_clk(struct device *dev, const char *path,
 	struct device_node *clocks_node;
 	struct clk_fixed_factor *factor;
 	struct clk_fixed_rate *fixed;
-	struct clk *clk;
 	struct clk_init_data init_data = { };
+	int ret;
 
 	clocks_node = of_find_node_by_path("/clocks");
 	if (clocks_node)
@@ -122,9 +121,9 @@ static int _qcom_cc_register_board_clk(struct device *dev, const char *path,
 		init_data.flags = CLK_IS_ROOT;
 		init_data.ops = &clk_fixed_rate_ops;
 
-		clk = devm_clk_register(dev, &fixed->hw);
-		if (IS_ERR(clk))
-			return PTR_ERR(clk);
+		ret = devm_clk_hw_register(dev, &fixed->hw);
+		if (ret)
+			return ret;
 	}
 	of_node_put(node);
 
@@ -142,9 +141,9 @@ static int _qcom_cc_register_board_clk(struct device *dev, const char *path,
 		init_data.flags = 0;
 		init_data.ops = &clk_fixed_factor_ops;
 
-		clk = devm_clk_register(dev, &factor->hw);
-		if (IS_ERR(clk))
-			return PTR_ERR(clk);
+		ret = devm_clk_hw_register(dev, &factor->hw);
+		if (ret)
+			return ret;
 	}
 
 	return 0;
@@ -180,36 +179,34 @@ int qcom_cc_really_probe(struct platform_device *pdev,
 {
 	int i, ret;
 	struct device *dev = &pdev->dev;
-	struct clk *clk;
-	struct clk_onecell_data *data;
-	struct clk **clks;
+	struct clk_hw_onecell_data *data;
+	struct clk_hw **hws;
 	struct qcom_reset_controller *reset;
 	struct qcom_cc *cc;
 	size_t num_clks = desc->num_clks;
 	struct clk_regmap **rclks = desc->clks;
 
-	cc = devm_kzalloc(dev, sizeof(*cc) + sizeof(*clks) * num_clks,
+	cc = devm_kzalloc(dev, sizeof(*cc) + sizeof(*hws) * num_clks,
 			  GFP_KERNEL);
 	if (!cc)
 		return -ENOMEM;
 
-	clks = cc->clks;
 	data = &cc->data;
-	data->clks = clks;
-	data->clk_num = num_clks;
+	data->num = num_clks;
+	hws = data->hws;
 
 	for (i = 0; i < num_clks; i++) {
 		if (!rclks[i]) {
-			clks[i] = ERR_PTR(-ENOENT);
+			hws[i] = ERR_PTR(-ENOENT);
 			continue;
 		}
-		clk = devm_clk_register_regmap(dev, rclks[i]);
-		if (IS_ERR(clk))
-			return PTR_ERR(clk);
-		clks[i] = clk;
+		ret = devm_clk_register_regmap(dev, rclks[i]);
+		if (ret)
+			return ret;
+		hws[i] = &rclks[i]->hw;
 	}
 
-	ret = of_clk_add_provider(dev->of_node, of_clk_src_onecell_get, data);
+	ret = of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get, data);
 	if (ret)
 		return ret;
 
diff --git a/drivers/clk/qcom/gcc-msm8996.c b/drivers/clk/qcom/gcc-msm8996.c
index 16d7c323db49..2cfd55141896 100644
--- a/drivers/clk/qcom/gcc-msm8996.c
+++ b/drivers/clk/qcom/gcc-msm8996.c
@@ -3373,9 +3373,8 @@ MODULE_DEVICE_TABLE(of, gcc_msm8996_match_table);
 
 static int gcc_msm8996_probe(struct platform_device *pdev)
 {
-	struct clk *clk;
 	struct device *dev = &pdev->dev;
-	int i;
+	int i, ret;
 	struct regmap *regmap;
 
 	regmap = qcom_cc_map(pdev, &gcc_msm8996_desc);
@@ -3389,9 +3388,9 @@ static int gcc_msm8996_probe(struct platform_device *pdev)
 	regmap_update_bits(regmap, 0x52008, BIT(21), BIT(21));
 
 	for (i = 0; i < ARRAY_SIZE(gcc_msm8996_hws); i++) {
-		clk = devm_clk_register(dev, gcc_msm8996_hws[i]);
-		if (IS_ERR(clk))
-			return PTR_ERR(clk);
+		ret = devm_clk_hw_register(dev, gcc_msm8996_hws[i]);
+		if (ret)
+			return ret;
 	}
 
 	return qcom_cc_really_probe(pdev, &gcc_msm8996_desc, regmap);
diff --git a/drivers/clk/qcom/mmcc-msm8996.c b/drivers/clk/qcom/mmcc-msm8996.c
index 064f3eaa39d0..8460daa6c567 100644
--- a/drivers/clk/qcom/mmcc-msm8996.c
+++ b/drivers/clk/qcom/mmcc-msm8996.c
@@ -3180,9 +3180,8 @@ MODULE_DEVICE_TABLE(of, mmcc_msm8996_match_table);
 
 static int mmcc_msm8996_probe(struct platform_device *pdev)
 {
-	struct clk *clk;
 	struct device *dev = &pdev->dev;
-	int i;
+	int i, ret;
 	struct regmap *regmap;
 
 	regmap = qcom_cc_map(pdev, &mmcc_msm8996_desc);
@@ -3195,9 +3194,9 @@ static int mmcc_msm8996_probe(struct platform_device *pdev)
 	regmap_update_bits(regmap, 0x5054, BIT(15), 0);
 
 	for (i = 0; i < ARRAY_SIZE(mmcc_msm8996_hws); i++) {
-		clk = devm_clk_register(dev, mmcc_msm8996_hws[i]);
-		if (IS_ERR(clk))
-			return PTR_ERR(clk);
+		ret = devm_clk_hw_register(dev, mmcc_msm8996_hws[i]);
+		if (ret)
+			return ret;
 	}
 
 	return qcom_cc_really_probe(pdev, &mmcc_msm8996_desc, regmap);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From sboyd at codeaurora.org  Mon Feb  8 17:45:36 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Feb 2016 17:45:36 -0800
Subject: [PATCH 09/14] clk: fixed-factor: Add hw based registration APIs
In-Reply-To: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1454982341-22715-10-git-send-email-sboyd@codeaurora.org>

Add registration APIs in the clk fixed-factor code to return
struct clk_hw pointers instead of struct clk pointers. This way
we hide the struct clk pointer from providers unless they need to
use consumer facing APIs.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clk-fixed-factor.c | 41 ++++++++++++++++++++++++++++++++++-------
 include/linux/clk-provider.h   |  4 ++++
 2 files changed, 38 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 83de57aeceea..c10b2eb2759f 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -70,13 +70,14 @@ const struct clk_ops clk_fixed_factor_ops = {
 };
 EXPORT_SYMBOL_GPL(clk_fixed_factor_ops);
 
-struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
-		const char *parent_name, unsigned long flags,
+struct clk_hw *clk_hw_register_fixed_factor(struct device *dev,
+		const char *name, const char *parent_name, unsigned long flags,
 		unsigned int mult, unsigned int div)
 {
 	struct clk_fixed_factor *fix;
 	struct clk_init_data init;
-	struct clk *clk;
+	struct clk_hw *hw;
+	int ret;
 
 	fix = kmalloc(sizeof(*fix), GFP_KERNEL);
 	if (!fix)
@@ -93,15 +94,41 @@ struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
 	init.parent_names = &parent_name;
 	init.num_parents = 1;
 
-	clk = clk_register(dev, &fix->hw);
-
-	if (IS_ERR(clk))
+	hw = &fix->hw;
+	ret = clk_hw_register(dev, hw);
+	if (ret) {
 		kfree(fix);
+		hw = ERR_PTR(ret);
+	}
+
+	return hw;
+}
+EXPORT_SYMBOL_GPL(clk_hw_register_fixed_factor);
+
+struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
+		const char *parent_name, unsigned long flags,
+		unsigned int mult, unsigned int div)
+{
+	struct clk_hw *hw;
 
-	return clk;
+	hw = clk_hw_register_fixed_factor(dev, name, parent_name, flags, mult,
+					  div);
+	if (IS_ERR(hw))
+		return ERR_CAST(hw);
+	return hw->clk;
 }
 EXPORT_SYMBOL_GPL(clk_register_fixed_factor);
 
+void clk_hw_unregister_fixed_factor(struct clk_hw *hw)
+{
+	struct clk_fixed_factor *fix;
+
+	fix = to_clk_fixed_factor(hw);
+
+	clk_hw_unregister(hw);
+	kfree(fix);
+}
+
 #ifdef CONFIG_OF
 /**
  * of_fixed_factor_clk_setup() - Setup function for simple fixed factor clock
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index df6353a086b9..d4d65f60b85e 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -513,6 +513,10 @@ extern const struct clk_ops clk_fixed_factor_ops;
 struct clk *clk_register_fixed_factor(struct device *dev, const char *name,
 		const char *parent_name, unsigned long flags,
 		unsigned int mult, unsigned int div);
+struct clk_hw *clk_hw_register_fixed_factor(struct device *dev,
+		const char *name, const char *parent_name, unsigned long flags,
+		unsigned int mult, unsigned int div);
+void clk_hw_unregister_fixed_factor(struct clk_hw *hw);
 
 /**
  * struct clk_fractional_divider - adjustable fractional divider clock
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From sboyd at codeaurora.org  Mon Feb  8 17:45:30 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Feb 2016 17:45:30 -0800
Subject: [PATCH 03/14] clk: Add {devm_}clk_hw_{register,unregister}() APIs
In-Reply-To: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1454982341-22715-4-git-send-email-sboyd@codeaurora.org>

We've largely split the clk consumer and provider APIs along
struct clk and struct clk_hw, but clk_register() still returns a
struct clk pointer for each struct clk_hw that's registered.
Eventually we'd like to only allocate struct clks when there's a
user, because struct clk is per-user now, so clk_register() needs
to change.

Let's add new APIs to register struct clk_hws, but this time
we'll hide the struct clk from the caller by returning an int
error code. Also add an unregistration API that takes the clk_hw
structure that was passed to the registration API. This way
provider drivers never have to deal with a struct clk pointer
unless they're using the clk consumer APIs.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 Documentation/driver-model/devres.txt |  1 +
 drivers/clk/clk.c                     | 86 +++++++++++++++++++++++++++++++++++
 include/linux/clk-provider.h          |  6 +++
 3 files changed, 93 insertions(+)

diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 831a5363f6be..600e30bf52c5 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -236,6 +236,7 @@ certainly invest a bit more effort into libata core layer).
 CLOCK
   devm_clk_get()
   devm_clk_put()
+  devm_clk_hw_register()
 
 DMA
   dmam_alloc_coherent()
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index b4db67a446c8..adaaead3639f 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2613,6 +2613,22 @@ fail_out:
 }
 EXPORT_SYMBOL_GPL(clk_register);
 
+/**
+ * clk_hw_register - register a clk_hw and return an error code
+ * @dev: device that is registering this clock
+ * @hw: link to hardware-specific clock data
+ *
+ * clk_hw_register is the primary interface for populating the clock tree with
+ * new clock nodes. It returns an integer equal to zero indicating success or
+ * less than zero indicating failure. Drivers must test for an error code after
+ * calling clk_hw_register().
+ */
+int clk_hw_register(struct device *dev, struct clk_hw *hw)
+{
+	return PTR_ERR_OR_ZERO(clk_register(dev, hw));
+}
+EXPORT_SYMBOL_GPL(clk_hw_register);
+
 /* Free memory allocated for a clock. */
 static void __clk_release(struct kref *ref)
 {
@@ -2714,11 +2730,26 @@ void clk_unregister(struct clk *clk)
 }
 EXPORT_SYMBOL_GPL(clk_unregister);
 
+/**
+ * clk_hw_unregister - unregister a currently registered clk_hw
+ * @hw: hardware-specific clock data to unregister
+ */
+void clk_hw_unregister(struct clk_hw *hw)
+{
+	clk_unregister(hw->clk);
+}
+EXPORT_SYMBOL_GPL(clk_hw_unregister);
+
 static void devm_clk_release(struct device *dev, void *res)
 {
 	clk_unregister(*(struct clk **)res);
 }
 
+static void devm_clk_hw_release(struct device *dev, void *res)
+{
+	clk_hw_unregister(*(struct clk_hw **)res);
+}
+
 /**
  * devm_clk_register - resource managed clk_register()
  * @dev: device that is registering this clock
@@ -2749,6 +2780,36 @@ struct clk *devm_clk_register(struct device *dev, struct clk_hw *hw)
 }
 EXPORT_SYMBOL_GPL(devm_clk_register);
 
+/**
+ * devm_clk_hw_register - resource managed clk_hw_register()
+ * @dev: device that is registering this clock
+ * @hw: link to hardware-specific clock data
+ *
+ * Managed clk_hw_register(). Clocks returned from this function are
+ * automatically clk_hw_unregister()ed on driver detach. See clk_hw_register()
+ * for more information.
+ */
+int devm_clk_hw_register(struct device *dev, struct clk_hw *hw)
+{
+	struct clk_hw **hwp;
+	int ret;
+
+	hwp = devres_alloc(devm_clk_hw_release, sizeof(*hwp), GFP_KERNEL);
+	if (!hwp)
+		return -ENOMEM;
+
+	ret = clk_hw_register(dev, hw);
+	if (!ret) {
+		*hwp = hw;
+		devres_add(dev, hwp);
+	} else {
+		devres_free(hwp);
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(devm_clk_hw_register);
+
 static int devm_clk_match(struct device *dev, void *res, void *data)
 {
 	struct clk *c = res;
@@ -2757,6 +2818,15 @@ static int devm_clk_match(struct device *dev, void *res, void *data)
 	return c == data;
 }
 
+static int devm_clk_hw_match(struct device *dev, void *res, void *data)
+{
+	struct clk_hw *hw = res;
+
+	if (WARN_ON(!hw))
+		return 0;
+	return hw == data;
+}
+
 /**
  * devm_clk_unregister - resource managed clk_unregister()
  * @clk: clock to unregister
@@ -2771,6 +2841,22 @@ void devm_clk_unregister(struct device *dev, struct clk *clk)
 }
 EXPORT_SYMBOL_GPL(devm_clk_unregister);
 
+/**
+ * devm_clk_hw_unregister - resource managed clk_hw_unregister()
+ * @dev: device that is unregistering the hardware-specific clock data
+ * @hw: link to hardware-specific clock data
+ *
+ * Unregister a clk_hw registered with devm_clk_hw_register(). Normally
+ * this function will not need to be called and the resource management
+ * code will ensure that the resource is freed.
+ */
+void devm_clk_hw_unregister(struct device *dev, struct clk_hw *hw)
+{
+	WARN_ON(devres_release(dev, devm_clk_hw_release, devm_clk_hw_match,
+				hw));
+}
+EXPORT_SYMBOL_GPL(devm_clk_hw_unregister);
+
 /*
  * clkdev helpers
  */
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1143e38555a4..abc16d77fb62 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -639,9 +639,15 @@ void of_gpio_mux_clk_setup(struct device_node *node);
 struct clk *clk_register(struct device *dev, struct clk_hw *hw);
 struct clk *devm_clk_register(struct device *dev, struct clk_hw *hw);
 
+int __must_check clk_hw_register(struct device *dev, struct clk_hw *hw);
+int __must_check devm_clk_hw_register(struct device *dev, struct clk_hw *hw);
+
 void clk_unregister(struct clk *clk);
 void devm_clk_unregister(struct device *dev, struct clk *clk);
 
+void clk_hw_unregister(struct clk_hw *hw);
+void devm_clk_hw_unregister(struct device *dev, struct clk_hw *hw);
+
 /* helper functions */
 const char *__clk_get_name(const struct clk *clk);
 const char *clk_hw_get_name(const struct clk_hw *hw);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From sboyd at codeaurora.org  Mon Feb  8 17:45:40 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Feb 2016 17:45:40 -0800
Subject: [PATCH 13/14] clk: fixed-rate: Add hw based registration APIs
In-Reply-To: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1454982341-22715-14-git-send-email-sboyd@codeaurora.org>

Add registration APIs in the clk fixed-rate code to return struct
clk_hw pointers instead of struct clk pointers. This way we hide
the struct clk pointer from providers unless they need to use
consumer facing APIs.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clk-fixed-rate.c | 44 ++++++++++++++++++++++++++++++++++++--------
 include/linux/clk-provider.h |  6 ++++++
 2 files changed, 42 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index f85ec8d1711f..fe9f83fc04ac 100644
--- a/drivers/clk/clk-fixed-rate.c
+++ b/drivers/clk/clk-fixed-rate.c
@@ -47,8 +47,8 @@ const struct clk_ops clk_fixed_rate_ops = {
 EXPORT_SYMBOL_GPL(clk_fixed_rate_ops);
 
 /**
- * clk_register_fixed_rate_with_accuracy - register fixed-rate clock with the
- *					   clock framework
+ * clk_hw_register_fixed_rate_with_accuracy - register fixed-rate clock with
+ * the clock framework
  * @dev: device that is registering this clock
  * @name: name of this clock
  * @parent_name: name of clock's parent
@@ -56,13 +56,14 @@ EXPORT_SYMBOL_GPL(clk_fixed_rate_ops);
  * @fixed_rate: non-adjustable clock rate
  * @fixed_accuracy: non-adjustable clock rate
  */
-struct clk *clk_register_fixed_rate_with_accuracy(struct device *dev,
+struct clk_hw *clk_hw_register_fixed_rate_with_accuracy(struct device *dev,
 		const char *name, const char *parent_name, unsigned long flags,
 		unsigned long fixed_rate, unsigned long fixed_accuracy)
 {
 	struct clk_fixed_rate *fixed;
-	struct clk *clk;
+	struct clk_hw *hw;
 	struct clk_init_data init;
+	int ret;
 
 	/* allocate fixed-rate clock */
 	fixed = kzalloc(sizeof(*fixed), GFP_KERNEL);
@@ -81,22 +82,49 @@ struct clk *clk_register_fixed_rate_with_accuracy(struct device *dev,
 	fixed->hw.init = &init;
 
 	/* register the clock */
-	clk = clk_register(dev, &fixed->hw);
-	if (IS_ERR(clk))
+	hw = &fixed->hw;
+	ret = clk_hw_register(dev, hw);
+	if (ret) {
 		kfree(fixed);
+		hw = ERR_PTR(ret);
+	}
 
-	return clk;
+	return hw;
+}
+EXPORT_SYMBOL_GPL(clk_hw_register_fixed_rate_with_accuracy);
+
+struct clk *clk_register_fixed_rate_with_accuracy(struct device *dev,
+		const char *name, const char *parent_name, unsigned long flags,
+		unsigned long fixed_rate, unsigned long fixed_accuracy)
+{
+	struct clk_hw *hw;
+
+	hw = clk_hw_register_fixed_rate_with_accuracy(dev, name, parent_name,
+			flags, fixed_rate, fixed_accuracy);
+	if (IS_ERR(hw))
+		return ERR_CAST(hw);
+	return hw->clk;
 }
 EXPORT_SYMBOL_GPL(clk_register_fixed_rate_with_accuracy);
 
 /**
- * clk_register_fixed_rate - register fixed-rate clock with the clock framework
+ * clk_hw_register_fixed_rate - register fixed-rate clock with the clock
+ * framework
  * @dev: device that is registering this clock
  * @name: name of this clock
  * @parent_name: name of clock's parent
  * @flags: framework-specific flags
  * @fixed_rate: non-adjustable clock rate
  */
+struct clk_hw *clk_hw_register_fixed_rate(struct device *dev, const char *name,
+		const char *parent_name, unsigned long flags,
+		unsigned long fixed_rate)
+{
+	return clk_hw_register_fixed_rate_with_accuracy(dev, name, parent_name,
+						     flags, fixed_rate, 0);
+}
+EXPORT_SYMBOL_GPL(clk_hw_register_fixed_rate);
+
 struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
 		const char *parent_name, unsigned long flags,
 		unsigned long fixed_rate)
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 148ad0dc2906..98fad9fb8a7d 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -280,9 +280,15 @@ extern const struct clk_ops clk_fixed_rate_ops;
 struct clk *clk_register_fixed_rate(struct device *dev, const char *name,
 		const char *parent_name, unsigned long flags,
 		unsigned long fixed_rate);
+struct clk_hw *clk_hw_register_fixed_rate(struct device *dev, const char *name,
+		const char *parent_name, unsigned long flags,
+		unsigned long fixed_rate);
 struct clk *clk_register_fixed_rate_with_accuracy(struct device *dev,
 		const char *name, const char *parent_name, unsigned long flags,
 		unsigned long fixed_rate, unsigned long fixed_accuracy);
+struct clk_hw *clk_hw_register_fixed_rate_with_accuracy(struct device *dev,
+		const char *name, const char *parent_name, unsigned long flags,
+		unsigned long fixed_rate, unsigned long fixed_accuracy);
 
 void of_fixed_clk_setup(struct device_node *np);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From sboyd at codeaurora.org  Mon Feb  8 17:45:31 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon,  8 Feb 2016 17:45:31 -0800
Subject: [PATCH 04/14] clk: Add clk_hw OF clk providers
In-Reply-To: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <1454982341-22715-5-git-send-email-sboyd@codeaurora.org>

Now that we have a clk registration API that doesn't return
struct clks, we need to have some way to hand out struct clks via
the clk_get() APIs that doesn't involve associating struct clk
pointers with an OF node. Currently we ask the OF provider to
give us a struct clk pointer for some clkspec, turn that struct
clk into a struct clk_hw and then allocate a new struct clk to
return to the caller.

Let's add a clk_hw based OF provider hook that returns a struct
clk_hw directly, so that we skip the intermediate step of
converting from struct clk to struct clk_hw. Eventually when
we've converted all OF clk providers to struct clk_hw based APIs
we can remove the struct clk based ones.

It should also be noted that we change the onecell provider to
have a flex array instead of a pointer for the array of clk_hw
pointers. This allows providers to allocate one structure of the
correct length in one step instead of two.

Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clk.c            | 84 +++++++++++++++++++++++++++++++++++++++++---
 include/linux/clk-provider.h | 30 ++++++++++++++++
 2 files changed, 110 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index adaaead3639f..a40849d0c672 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3018,6 +3018,7 @@ struct of_clk_provider {
 
 	struct device_node *node;
 	struct clk *(*get)(struct of_phandle_args *clkspec, void *data);
+	struct clk_hw *(*get_hw)(struct of_phandle_args *clkspec, void *data);
 	void *data;
 };
 
@@ -3034,6 +3035,12 @@ struct clk *of_clk_src_simple_get(struct of_phandle_args *clkspec,
 }
 EXPORT_SYMBOL_GPL(of_clk_src_simple_get);
 
+struct clk_hw *of_clk_hw_simple_get(struct of_phandle_args *clkspec, void *data)
+{
+	return data;
+}
+EXPORT_SYMBOL_GPL(of_clk_hw_simple_get);
+
 struct clk *of_clk_src_onecell_get(struct of_phandle_args *clkspec, void *data)
 {
 	struct clk_onecell_data *clk_data = data;
@@ -3048,6 +3055,21 @@ struct clk *of_clk_src_onecell_get(struct of_phandle_args *clkspec, void *data)
 }
 EXPORT_SYMBOL_GPL(of_clk_src_onecell_get);
 
+struct clk_hw *
+of_clk_hw_onecell_get(struct of_phandle_args *clkspec, void *data)
+{
+	struct clk_hw_onecell_data *hw_data = data;
+	unsigned int idx = clkspec->args[0];
+
+	if (idx >= hw_data->num) {
+		pr_err("%s: invalid index %u\n", __func__, idx);
+		return ERR_PTR(-EINVAL);
+	}
+
+	return hw_data->hws[idx];
+}
+EXPORT_SYMBOL_GPL(of_clk_hw_onecell_get);
+
 /**
  * of_clk_add_provider() - Register a clock provider for a node
  * @np: Device node pointer associated with clock provider
@@ -3084,6 +3106,40 @@ int of_clk_add_provider(struct device_node *np,
 EXPORT_SYMBOL_GPL(of_clk_add_provider);
 
 /**
+ * of_clk_add_hw_provider() - Register a clock provider for a node
+ * @np: Device node pointer associated with clock provider
+ * @get: callback for decoding clk_hw
+ * @data: context pointer for @get callback.
+ */
+int of_clk_add_hw_provider(struct device_node *np,
+			   struct clk_hw *(*get)(struct of_phandle_args *clkspec,
+						 void *data),
+			   void *data)
+{
+	struct of_clk_provider *cp;
+	int ret;
+
+	cp = kzalloc(sizeof(*cp), GFP_KERNEL);
+	if (!cp)
+		return -ENOMEM;
+
+	cp->node = of_node_get(np);
+	cp->data = data;
+	cp->get_hw = get;
+
+	mutex_lock(&of_clk_mutex);
+	list_add(&cp->link, &of_clk_providers);
+	mutex_unlock(&of_clk_mutex);
+	pr_debug("Added clk_hw provider from %s\n", np->full_name);
+
+	ret = of_clk_set_defaults(np, true);
+	if (ret < 0)
+		of_clk_del_provider(np);
+
+	return ret;
+}
+
+/**
  * of_clk_del_provider() - Remove a previously registered clock provider
  * @np: Device node pointer associated with clock provider
  */
@@ -3104,11 +3160,32 @@ void of_clk_del_provider(struct device_node *np)
 }
 EXPORT_SYMBOL_GPL(of_clk_del_provider);
 
+static struct clk_hw *
+__of_clk_get_hw_from_provider(struct of_clk_provider *provider,
+			      struct of_phandle_args *clkspec)
+{
+	struct clk *clk;
+	struct clk_hw *hw = ERR_PTR(-EPROBE_DEFER);
+
+	if (provider->get_hw) {
+		hw = provider->get_hw(clkspec, provider->data);
+	} else if (provider->get) {
+		clk = provider->get(clkspec, provider->data);
+		if (!IS_ERR(clk))
+			hw = __clk_get_hw(clk);
+		else
+			hw = ERR_CAST(clk);
+	}
+
+	return hw;
+}
+
 struct clk *__of_clk_get_from_provider(struct of_phandle_args *clkspec,
 				       const char *dev_id, const char *con_id)
 {
 	struct of_clk_provider *provider;
 	struct clk *clk = ERR_PTR(-EPROBE_DEFER);
+	struct clk_hw *hw = ERR_PTR(-EPROBE_DEFER);
 
 	if (!clkspec)
 		return ERR_PTR(-EINVAL);
@@ -3117,10 +3194,9 @@ struct clk *__of_clk_get_from_provider(struct of_phandle_args *clkspec,
 	mutex_lock(&of_clk_mutex);
 	list_for_each_entry(provider, &of_clk_providers, link) {
 		if (provider->node == clkspec->np)
-			clk = provider->get(clkspec, provider->data);
-		if (!IS_ERR(clk)) {
-			clk = __clk_create_clk(__clk_get_hw(clk), dev_id,
-					       con_id);
+			hw = __of_clk_get_hw_from_provider(provider, clkspec);
+		if (!IS_ERR(hw)) {
+			clk = __clk_create_clk(hw, dev_id, con_id);
 
 			if (!IS_ERR(clk) && !__clk_get(clk)) {
 				__clk_free_clk(clk);
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index abc16d77fb62..1af1afae05f8 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -693,6 +693,11 @@ struct clk_onecell_data {
 	unsigned int clk_num;
 };
 
+struct clk_hw_onecell_data {
+	size_t num;
+	struct clk_hw *hws[];
+};
+
 extern struct of_device_id __clk_of_table;
 
 #define CLK_OF_DECLARE(name, compat, fn) OF_DECLARE_1(clk, name, compat, fn)
@@ -702,10 +707,18 @@ int of_clk_add_provider(struct device_node *np,
 			struct clk *(*clk_src_get)(struct of_phandle_args *args,
 						   void *data),
 			void *data);
+int of_clk_add_hw_provider(struct device_node *np,
+			   struct clk_hw *(*get)(struct of_phandle_args *clkspec,
+						 void *data),
+			   void *data);
 void of_clk_del_provider(struct device_node *np);
 struct clk *of_clk_src_simple_get(struct of_phandle_args *clkspec,
 				  void *data);
+struct clk_hw *of_clk_hw_simple_get(struct of_phandle_args *clkspec,
+				    void *data);
 struct clk *of_clk_src_onecell_get(struct of_phandle_args *clkspec, void *data);
+struct clk_hw *of_clk_hw_onecell_get(struct of_phandle_args *clkspec,
+				     void *data);
 int of_clk_get_parent_count(struct device_node *np);
 int of_clk_parent_fill(struct device_node *np, const char **parents,
 		       unsigned int size);
@@ -722,17 +735,34 @@ static inline int of_clk_add_provider(struct device_node *np,
 {
 	return 0;
 }
+int of_clk_add_hw_provider(struct device_node *np,
+			   struct clk_hw *(*get)(struct of_phandle_args *clkspec,
+						 void *data),
+			   void *data)
+{
+	return 0;
+}
 static inline void of_clk_del_provider(struct device_node *np) {}
 static inline struct clk *of_clk_src_simple_get(
 	struct of_phandle_args *clkspec, void *data)
 {
 	return ERR_PTR(-ENOENT);
 }
+struct clk_hw *of_clk_hw_simple_get(struct of_phandle_args *clkspec,
+				    void *data)
+{
+	return ERR_PTR(-ENOENT);
+}
 static inline struct clk *of_clk_src_onecell_get(
 	struct of_phandle_args *clkspec, void *data)
 {
 	return ERR_PTR(-ENOENT);
 }
+struct clk_hw *of_clk_hw_onecell_get(struct of_phandle_args *clkspec,
+				     void *data)
+{
+	return ERR_PTR(-ENOENT);
+}
 static inline int of_clk_get_parent_count(struct device_node *np)
 {
 	return 0;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From stillcompiling at gmail.com  Mon Feb  8 19:05:31 2016
From: stillcompiling at gmail.com (Joshua Clayton)
Date: Mon, 08 Feb 2016 19:05:31 -0800
Subject: [PATCH v2 1/9] Staging: rts5208: rtsx_transport.c: Fix comment
 style warnings
In-Reply-To: <1454981485-15686-2-git-send-email-shaun.ren@linux.com>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-2-git-send-email-shaun.ren@linux.com>
Message-ID: <2111025.vcC3H3DjyZ@diplodocus>

Hello Shaun,
/*
 * Multiline comments (except in the net subsystem) should 
 * start with "/*" on a separate line. see Documentation/CodingStyle
 */
If you are going to fix the comments you should get both the beginning
and the end.
More comments inline. 

On Monday, February 08, 2016 05:31:17 PM Shaun Ren wrote:
> This patch fixes all comment style warnings in rtsx_transport.c reported by
> checkpatch.pl:
> 
> WARNING: Block comments use a trailing */ on a separate line
> 
> Signed-off-by: Shaun Ren <shaun.ren at linux.com>
> ---
>  drivers/staging/rts5208/rtsx_transport.c | 21 ++++++++++++++-------
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
> index f27491e..3e3f6fb 100644
> --- a/drivers/staging/rts5208/rtsx_transport.c
> +++ b/drivers/staging/rts5208/rtsx_transport.c
> @@ -36,7 +36,8 @@
>   * For non-scatter-gather transfers, srb->request_buffer points to the
>   * transfer buffer itself and srb->request_bufflen is the buffer's length.)
>   * Update the *index and *offset variables so that the next copy will
> - * pick up from where this one left off. */
> + * pick up from where this one left off.
> + */
> 
Fix the beginning too, as mentioned above.
 
>  unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
>  	unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
> @@ -45,7 +46,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
>  	unsigned int cnt;
>  
>  	/* If not using scatter-gather, just transfer the data directly.
> -	 * Make certain it will fit in the available buffer space. */
> +	 * Make certain it will fit in the available buffer space.
> +	 */

Either fix the beginning...  or better yet, get rid of the useless
(obvious) second line so it can be a single line comment.

>  	if (scsi_sg_count(srb) == 0) {
>  		if (*offset >= scsi_bufflen(srb))
>  			return 0;
> @@ -64,7 +66,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
>  	 * in kernel-addressable memory then kmap() will return its address.
>  	 * If the page is not directly accessible -- such as a user buffer
>  	 * located in high memory -- then kmap() will map it to a temporary
> -	 * position in the kernel's virtual address space. */
> +	 * position in the kernel's virtual address space.
> +	 */

Fix the beginning of this comment as well.
Also,  from "If the page is already in kernel -addressible memory..."
on is just  a description of what kmap() does.
I'd get rid of those lines. 

>  	} else {
>  		struct scatterlist *sg =
>  				(struct scatterlist *) scsi_sglist(srb)
> @@ -73,7 +76,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
>  		/* This loop handles a single s-g list entry, which may
>  		 * include multiple pages.  Find the initial page structure
>  		 * and the starting offset within the page, and update
> -		 * the *offset and *index values for the next loop. */
> +		 * the *offset and *index values for the next loop.
> +		 */

Fix the beginning of this comment.

>  		cnt = 0;
>  		while (cnt < buflen && *index < scsi_sg_count(srb)) {
>  			struct page *page = sg_page(sg) +
> @@ -97,7 +101,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
>  
>  			/* Transfer the data for all the pages in this
>  			 * s-g entry.  For each page: call kmap(), do the
> -			 * transfer, and call kunmap() immediately after. */
> +			 * transfer, and call kunmap() immediately after.
> +			 */

I'd get rid of this comment. It parrots what the code does, but does not
add any information.

>  			while (sglen > 0) {
>  				unsigned int plen = min(sglen, (unsigned int)
>  						PAGE_SIZE - poff);
> @@ -123,7 +128,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
>  }
>  
>  /* Store the contents of buffer into srb's transfer buffer and set the
> -* SCSI residue. */
> + * SCSI residue.
> + */

Fix the beginning as well.

>  void rtsx_stor_set_xfer_buf(unsigned char *buffer,
>  	unsigned int buflen, struct scsi_cmnd *srb)
>  {
> @@ -196,7 +202,8 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>  
>  	/* Error and abort processing: try to resynchronize with the device
>  	 * by issuing a port reset.  If that fails, try a class-specific
> -	 * device reset. */
> +	 * device reset.
> +	 */

This comment  describes something that does not
happen in this function. Perhaps it did at one point. 
Regardless, It should be removed.

>  Handle_Errors:
>  	return;
>  }
> 



From afaerber at suse.de  Mon Feb  8 19:08:23 2016
From: afaerber at suse.de (=?UTF-8?Q?Andreas_F=c3=a4rber?=)
Date: Tue, 9 Feb 2016 04:08:23 +0100
Subject: [PATCH v2 06/10] ARM64: dts: rockchip: Add IR receiver to GeekBox
In-Reply-To: <1454897859-7601-7-git-send-email-afaerber@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
 <1454897859-7601-7-git-send-email-afaerber@suse.de>
Message-ID: <56B95827.7060204@suse.de>

Am 08.02.2016 um 03:17 schrieb Andreas F?rber:
> Signed-off-by: Andreas F?rber <afaerber at suse.de>
> ---
>  v2: New
>  
>  arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
> index e4523a74050f..e84383fd6f10 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
> @@ -63,6 +63,13 @@
>  		#clock-cells = <0>;
>  	};
>  
> +	ir: ir-receiver {
> +		compatible = "gpio-ir-receiver";
> +		gpios = <&gpio3 30 GPIO_ACTIVE_LOW>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&ir_int>;

		status = "disabled";

Should only be enabled in the new Landingship config. Will fix.

Andreas

P.S. See Heiko, two bugs in the new nodes already, glad I have them
separate. :)

> +	};
> +
>  	leds: gpio-leds {
>  		compatible = "gpio-leds";
>  
[snip]

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N?rnberg)


From vinod.koul at intel.com  Mon Feb  8 19:21:05 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 9 Feb 2016 08:51:05 +0530
Subject: [PATCH v7 0/9] Fix broken DMAFLUSHP on Rockchips platform
In-Reply-To: <2223201.4nEkyUQu1O@phil>
References: <1453460812-8498-1-git-send-email-wxt@rock-chips.com>
 <3817335.PXCk0JfYDT@phil> <20160208131419.GA19598@localhost>
 <2223201.4nEkyUQu1O@phil>
Message-ID: <20160209032105.GD19598@localhost>

On Mon, Feb 08, 2016 at 11:21:57PM +0100, Heiko Stuebner wrote:
> Hi Vinod,
> 
> Am Montag, 8. Februar 2016, 18:44:19 schrieb Vinod Koul:
> > On Mon, Feb 08, 2016 at 10:27:04AM +0100, Heiko Stuebner wrote:
> > > Am Montag, 8. Februar 2016, 08:41:34 schrieb Vinod Koul:
> > > > On Mon, Feb 01, 2016 at 02:56:54PM +0800, Caesar Wang wrote:
> > > > > Hello Vinod,
> > > > > 
> > > > > Is there any chance apply the DMA patches?:-)
> > > > 
> > > > I was waiting for any ACKs on ARM patches before I merge this series.
> > > 
> > > I think the more regular way is for the driver maintainer to take the
> > > driver-specific stuff and the devicetree parts going through the
> > > specific arm- tree. But if you really want to take the whole series,
> > > for patches 4,5,6
> > Yes but that causes cross tree dependencies, which looking at this won't
> > be a big problem, so I can safely merge dmaengine changes and rest can go
> > thru ARM tree.
> > 
> > Typically submitter should say which tree he/she prefers, which was not
> > provided..
> > 
> > So, are all okay to merge the entire series thru dmaengine tree or
> > independent. I don't mind either
> 
> In general I don't mind either solution, but would prefer me taking the 3 
> "ARM: dts: foo" patches, while the rest would go through your tree.
> 
> Main reason is to prevent any possible conflicts with other Rockchip 
> devicetree additions also going into 4.6 .

Sounds good, will queue them up

-- 
~Vinod


From vinod.koul at intel.com  Mon Feb  8 19:34:29 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 9 Feb 2016 09:04:29 +0530
Subject: [PATCH v7 9/9] spi: rockchip: modify DMA max burst to 1
In-Reply-To: <1453460812-8498-10-git-send-email-wxt@rock-chips.com>
References: <1453460812-8498-1-git-send-email-wxt@rock-chips.com>
 <1453460812-8498-10-git-send-email-wxt@rock-chips.com>
Message-ID: <20160209033428.GJ19598@localhost>

On Fri, Jan 22, 2016 at 07:06:52PM +0800, Caesar Wang wrote:
> From: Addy Ke <addy.ke at rock-chips.com>
> 
> Generic dma controller on Rockchips' platform cannot support
> DMAFLUSHP instruction which make dma to flush the req of non-aligned
> or non-multiple of what we need. That will cause an unrecoverable
> dma bus error. The saftest way is to set dma max burst to 1.

Applied, thanks

-- 
~Vinod


From lkp at intel.com  Mon Feb  8 19:31:09 2016
From: lkp at intel.com (kbuild test robot)
Date: Tue, 9 Feb 2016 11:31:09 +0800
Subject: [PATCH 04/14] clk: Add clk_hw OF clk providers
In-Reply-To: <1454982341-22715-5-git-send-email-sboyd@codeaurora.org>
Message-ID: <201602091142.gNVJRY1Y%fengguang.wu@intel.com>

Hi Stephen,

[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.5-rc3 next-20160208]
[cannot apply to clk/clk-next]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Stephen-Boyd/clk_hw-based-clkdev-DT-providers/20160209-095211
base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: x86_64-rhel (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/clk/clk.o: In function `of_clk_hw_simple_get':
>> (.text+0x3ec0): multiple definition of `of_clk_hw_simple_get'
   drivers/clk/clkdev.o:(.text+0x3e0): first defined here
   drivers/clk/clk.o: In function `of_clk_hw_onecell_get':
>> (.text+0x3ee0): multiple definition of `of_clk_hw_onecell_get'
   drivers/clk/clkdev.o:(.text+0x400): first defined here
   drivers/clk/clk.o: In function `of_clk_add_hw_provider':
>> (.text+0x3eb0): multiple definition of `of_clk_add_hw_provider'
   drivers/clk/clkdev.o:(.text+0x3d0): first defined here
   drivers/clk/clk-divider.o: In function `of_clk_hw_simple_get':
   (.text+0xb20): multiple definition of `of_clk_hw_simple_get'
   drivers/clk/clkdev.o:(.text+0x3e0): first defined here
   drivers/clk/clk-divider.o: In function `of_clk_hw_onecell_get':
   (.text+0xb40): multiple definition of `of_clk_hw_onecell_get'
   drivers/clk/clkdev.o:(.text+0x400): first defined here
   drivers/clk/clk-divider.o: In function `of_clk_add_hw_provider':
   (.text+0xb10): multiple definition of `of_clk_add_hw_provider'
   drivers/clk/clkdev.o:(.text+0x3d0): first defined here
   drivers/clk/clk-fixed-factor.o: In function `of_clk_hw_simple_get':
   (.text+0x170): multiple definition of `of_clk_hw_simple_get'
   drivers/clk/clkdev.o:(.text+0x3e0): first defined here
   drivers/clk/clk-fixed-factor.o: In function `of_clk_hw_onecell_get':
   (.text+0x190): multiple definition of `of_clk_hw_onecell_get'
   drivers/clk/clkdev.o:(.text+0x400): first defined here
   drivers/clk/clk-fixed-factor.o: In function `of_clk_add_hw_provider':
   (.text+0x160): multiple definition of `of_clk_add_hw_provider'
   drivers/clk/clkdev.o:(.text+0x3d0): first defined here
   drivers/clk/clk-fixed-rate.o: In function `of_clk_hw_simple_get':
   (.text+0x120): multiple definition of `of_clk_hw_simple_get'
   drivers/clk/clkdev.o:(.text+0x3e0): first defined here
   drivers/clk/clk-fixed-rate.o: In function `of_clk_hw_onecell_get':
   (.text+0x140): multiple definition of `of_clk_hw_onecell_get'
   drivers/clk/clkdev.o:(.text+0x400): first defined here
   drivers/clk/clk-fixed-rate.o: In function `of_clk_add_hw_provider':
   (.text+0x110): multiple definition of `of_clk_add_hw_provider'
   drivers/clk/clkdev.o:(.text+0x3d0): first defined here
   drivers/clk/clk-gate.o: In function `of_clk_hw_simple_get':
   (.text+0x280): multiple definition of `of_clk_hw_simple_get'
   drivers/clk/clkdev.o:(.text+0x3e0): first defined here
   drivers/clk/clk-gate.o: In function `of_clk_hw_onecell_get':
   (.text+0x2a0): multiple definition of `of_clk_hw_onecell_get'
   drivers/clk/clkdev.o:(.text+0x400): first defined here
   drivers/clk/clk-gate.o: In function `of_clk_add_hw_provider':
   (.text+0x270): multiple definition of `of_clk_add_hw_provider'
   drivers/clk/clkdev.o:(.text+0x3d0): first defined here
   drivers/clk/clk-multiplier.o: In function `of_clk_hw_simple_get':
   (.text+0x2b0): multiple definition of `of_clk_hw_simple_get'
   drivers/clk/clkdev.o:(.text+0x3e0): first defined here
   drivers/clk/clk-multiplier.o: In function `of_clk_hw_onecell_get':
   (.text+0x2d0): multiple definition of `of_clk_hw_onecell_get'
   drivers/clk/clkdev.o:(.text+0x400): first defined here
   drivers/clk/clk-multiplier.o: In function `of_clk_add_hw_provider':
   (.text+0x2a0): multiple definition of `of_clk_add_hw_provider'
   drivers/clk/clkdev.o:(.text+0x3d0): first defined here
   drivers/clk/clk-mux.o: In function `of_clk_hw_simple_get':
   (.text+0x340): multiple definition of `of_clk_hw_simple_get'
   drivers/clk/clkdev.o:(.text+0x3e0): first defined here
   drivers/clk/clk-mux.o: In function `of_clk_hw_onecell_get':
   (.text+0x360): multiple definition of `of_clk_hw_onecell_get'
   drivers/clk/clkdev.o:(.text+0x400): first defined here
   drivers/clk/clk-mux.o: In function `of_clk_add_hw_provider':
   (.text+0x330): multiple definition of `of_clk_add_hw_provider'
   drivers/clk/clkdev.o:(.text+0x3d0): first defined here
   drivers/clk/clk-composite.o: In function `of_clk_add_hw_provider':
   clk-composite.c:(.text+0x3a0): multiple definition of `of_clk_add_hw_provider'
   drivers/clk/clkdev.o:(.text+0x3d0): first defined here
   drivers/clk/clk-composite.o: In function `of_clk_hw_simple_get':
   clk-composite.c:(.text+0x3b0): multiple definition of `of_clk_hw_simple_get'
   drivers/clk/clkdev.o:(.text+0x3e0): first defined here
   drivers/clk/clk-composite.o: In function `of_clk_hw_onecell_get':
   clk-composite.c:(.text+0x3d0): multiple definition of `of_clk_hw_onecell_get'
   drivers/clk/clkdev.o:(.text+0x400): first defined here
   drivers/clk/clk-fractional-divider.o: In function `of_clk_hw_simple_get':
   (.text+0x330): multiple definition of `of_clk_hw_simple_get'
   drivers/clk/clkdev.o:(.text+0x3e0): first defined here
   drivers/clk/clk-fractional-divider.o: In function `of_clk_hw_onecell_get':
   (.text+0x350): multiple definition of `of_clk_hw_onecell_get'
   drivers/clk/clkdev.o:(.text+0x400): first defined here
   drivers/clk/clk-fractional-divider.o: In function `of_clk_add_hw_provider':
   (.text+0x320): multiple definition of `of_clk_add_hw_provider'
   drivers/clk/clkdev.o:(.text+0x3d0): first defined here
   drivers/clk/clk-gpio.o: In function `of_clk_hw_simple_get':
   (.text+0x340): multiple definition of `of_clk_hw_simple_get'
   drivers/clk/clkdev.o:(.text+0x3e0): first defined here
   drivers/clk/clk-gpio.o: In function `of_clk_hw_onecell_get':
   (.text+0x360): multiple definition of `of_clk_hw_onecell_get'
   drivers/clk/clkdev.o:(.text+0x400): first defined here
   drivers/clk/clk-gpio.o: In function `of_clk_add_hw_provider':
   (.text+0x330): multiple definition of `of_clk_add_hw_provider'
   drivers/clk/clkdev.o:(.text+0x3d0): first defined here
   drivers/clk/x86/built-in.o: In function `of_clk_hw_simple_get':
   (.text+0x90): multiple definition of `of_clk_hw_simple_get'
   drivers/clk/clkdev.o:(.text+0x3e0): first defined here
   drivers/clk/x86/built-in.o: In function `of_clk_hw_onecell_get':
   (.text+0xb0): multiple definition of `of_clk_hw_onecell_get'
   drivers/clk/clkdev.o:(.text+0x400): first defined here
   drivers/clk/x86/built-in.o: In function `of_clk_add_hw_provider':
   (.text+0x80): multiple definition of `of_clk_add_hw_provider'
   drivers/clk/clkdev.o:(.text+0x3d0): first defined here

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 36062 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/4189771e/attachment-0001.obj>

From vinod.koul at intel.com  Mon Feb  8 19:36:46 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 9 Feb 2016 09:06:46 +0530
Subject: [PATCH] dmaengine: pxa_dma: fix the maximum requestor line
In-Reply-To: <1454941131-12308-1-git-send-email-robert.jarzmik@free.fr>
References: <1454941131-12308-1-git-send-email-robert.jarzmik@free.fr>
Message-ID: <20160209033646.GK19598@localhost>

On Mon, Feb 08, 2016 at 03:18:51PM +0100, Robert Jarzmik wrote:
> The current number of requestor lines is limited to 31. This was an
> error of a previous commit, as this number is platform dependent, and is
> actually :
>  - for pxa25x: 40 requestor lines
>  - for pxa27x: 74 requestor lines
>  - for pxa3xx: 100 requestor lines
> 
> As the driver doesn't need to know the exact number, but only an

and why would that be a good assumption?

Btw shouldn't this data come from DT?

> absolute maximum value above which is it not using any flow control, set
> the maximum to 0x8000 requestor lines, which should never be reached.
> 
> The previous testing did not reveal the faulty constant as on pxa[23]xx
> platforms, only camera, MSL and USB are above requestor 32, and in these
> only the camera has a driver using dma.
> 
> Fixes: e87ffbdf0697 ("dmaengine: pxa_dma: fix the no-requestor case")
> Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
> ---
>  drivers/dma/pxa_dma.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
> index ca6c088edc8a..817a2bdc423d 100644
> --- a/drivers/dma/pxa_dma.c
> +++ b/drivers/dma/pxa_dma.c
> @@ -53,6 +53,7 @@
>  
>  #define DRCMR_MAPVLD	BIT(7)	/* Map Valid (read / write) */
>  #define DRCMR_CHLNUM	0x1f	/* mask for Channel Number (read / write) */
> +#define DRCMR_MAXREQST	0x7fff	/* Maximum requestor line */
>  
>  #define DDADR_DESCADDR	0xfffffff0	/* Address of next descriptor (mask) */
>  #define DDADR_STOP	BIT(0)	/* Stop (read / write) */
> @@ -473,7 +474,7 @@ static void pxad_free_phy(struct pxad_chan *chan)
>  		return;
>  
>  	/* clear the channel mapping in DRCMR */
> -	if (chan->drcmr <= DRCMR_CHLNUM) {
> +	if (chan->drcmr <= DRCMR_MAXREQST) {
>  		reg = pxad_drcmr(chan->drcmr);
>  		writel_relaxed(0, chan->phy->base + reg);
>  	}
> @@ -518,7 +519,7 @@ static void phy_enable(struct pxad_phy *phy, bool misaligned)
>  		"%s(); phy=%p(%d) misaligned=%d\n", __func__,
>  		phy, phy->idx, misaligned);
>  
> -	if (phy->vchan->drcmr <= DRCMR_CHLNUM) {
> +	if (phy->vchan->drcmr <= DRCMR_MAXREQST) {
>  		reg = pxad_drcmr(phy->vchan->drcmr);
>  		writel_relaxed(DRCMR_MAPVLD | phy->idx, phy->base + reg);
>  	}
> @@ -922,7 +923,7 @@ static void pxad_get_config(struct pxad_chan *chan,
>  		dev_addr = chan->cfg.src_addr;
>  		*dev_src = dev_addr;
>  		*dcmd |= PXA_DCMD_INCTRGADDR;
> -		if (chan->drcmr <= DRCMR_CHLNUM)
> +		if (chan->drcmr <= DRCMR_MAXREQST)
>  			*dcmd |= PXA_DCMD_FLOWSRC;
>  	}
>  	if (dir == DMA_MEM_TO_DEV) {
> @@ -931,7 +932,7 @@ static void pxad_get_config(struct pxad_chan *chan,
>  		dev_addr = chan->cfg.dst_addr;
>  		*dev_dst = dev_addr;
>  		*dcmd |= PXA_DCMD_INCSRCADDR;
> -		if (chan->drcmr <= DRCMR_CHLNUM)
> +		if (chan->drcmr <= DRCMR_MAXREQST)
>  			*dcmd |= PXA_DCMD_FLOWTRG;
>  	}
>  	if (dir == DMA_MEM_TO_MEM)
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
~Vinod


From a0393675 at ti.com  Mon Feb  8 19:37:27 2016
From: a0393675 at ti.com (Keerthy)
Date: Tue, 9 Feb 2016 09:07:27 +0530
Subject: [PATCH 0/3] arm: dts: DRA7: Add IVA and DSPEVE thermal domain data
In-Reply-To: <20160208195704.GW19432@atomide.com>
References: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>
 <20160208195704.GW19432@atomide.com>
Message-ID: <56B95EF7.9080107@ti.com>



On Tuesday 09 February 2016 01:27 AM, Tony Lindgren wrote:
> * Keerthy <j-keerthy at ti.com> [160208 01:19]:
>> OMAP5 has 3 thermal zones cpu, core and multimedia.
>> On the other hand DRA7 has 5 thermal zones cpu, gpu, core, dspeve
>> and iva. Currently cpu, core and multimedia are being added via dt
>> and the other 2 are getting added via kernel. Add the missing thermal
>> domains in dt so as give the correct trip numbers, type and temperatures.
>>
>> Tested on DRA7-EVM.
>
> Are these critical fixes to have for v4.5-rc cycle or can they
> wait for v4.6 merge window?

Driver configures some default thresholds that are a bit higher but 
there are some thresholds already for dspeve and iva too. So guess these 
can wait if its already too late.

Regards,
Keerthy

>
> Regards,
>
> Tony
>
>> Keerthy (3):
>>    arm: dts: DRA7: Add DSPEVE thermal data
>>    arm: dts: DRA7: Add IVA thermal data
>>    arm: dts: DRA7: Add missing IVA and DSPEVE thermal domain data
>>
>>   arch/arm/boot/dts/dra7-dspeve-thermal.dtsi | 27 +++++++++++++++++++++++++++
>>   arch/arm/boot/dts/dra7-iva-thermal.dtsi    | 27 +++++++++++++++++++++++++++
>>   arch/arm/boot/dts/dra7.dtsi                |  2 ++
>>   3 files changed, 56 insertions(+)
>>   create mode 100644 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi
>>   create mode 100644 arch/arm/boot/dts/dra7-iva-thermal.dtsi
>>
>> --
>> 1.9.1
>>


From jassisinghbrar at gmail.com  Mon Feb  8 20:14:20 2016
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Tue, 9 Feb 2016 09:44:20 +0530
Subject: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager
In-Reply-To: <1454690044-2560-2-git-send-email-nm@ti.com>
References: <1454690044-2560-1-git-send-email-nm@ti.com>
 <1454690044-2560-2-git-send-email-nm@ti.com>
Message-ID: <CABb+yY3kGq_R49Xx4fK3UMqtuFiuv-pXJWvjkEFLPL9xRu5T4A@mail.gmail.com>

On Fri, Feb 5, 2016 at 10:04 PM, Nishanth Menon <nm at ti.com> wrote:
> +
> +       msgmgr: msgmgr at 02a00000 {
> +               compatible = "ti,k2g-message-manager", "ti,message-manager";
> +               #mbox-cells = <1>;
> +               reg-names = "queue_proxy_region", "queue_state_debug_region";
> +               reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
> +
> +               msgmgr_proxy_pmmc_tx_prio0: pmmc_tx_prio0 {
> +                       ti,queue-id = <0>;
> +                       ti,proxy-id = <0>;
> +               };
> +
> +               msgmgr_proxy_pmmc_rx: pmmc_rx {
> +                       ti,queue-id = <5>;
> +                       ti,proxy-id = <2>;
> +                       interrupt-names = "rx";
> +                       interrupts = <GIC_SPI 324 IRQ_TYPE_EDGE_RISING>;
> +               };
> +       };
> +
I think we should get rid of consumer specifics from the provider node...

> +...
> +       pmmc {
> +               ...
> +               mbox-names = "tx", "rx";
> +               mboxes = <&msgmgr &msgmgr_proxy_pmmc_tx>
> +                        <&msgmgr &msgmgr_proxy_pmmc_rx>;
> +               ...
> +       };
>
... and have consumers like
       pmmc {
               ...
               mbox-names = "tx", "rx";
               mboxes = <&msgmgr 0 0>
                        <&msgmgr 5 2>;
       };

I leave the IRQ for you to decide how to specify - a 'dummy' or
'valid' always provided as last cell in mboxes or some other way.
(I'll review other patches in detail later)

cheers.


From jun.nie at linaro.org  Mon Feb  8 21:02:12 2016
From: jun.nie at linaro.org (Jun Nie)
Date: Tue, 9 Feb 2016 13:02:12 +0800
Subject: [PATCH] ARM: zx: Fix return value check in zx296702_pd_probe()
In-Reply-To: <1454768696-340-1-git-send-email-weiyj_lk@163.com>
References: <1454768696-340-1-git-send-email-weiyj_lk@163.com>
Message-ID: <56B972D4.8040608@linaro.org>

On 2016?02?06? 22:24, weiyj_lk at 163.com wrote:
> From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
>
> In case of error, the function devm_ioremap_resource() returns
> ERR_PTR() and never returns NULL. The NULL test in the return
> value check should be replaced with IS_ERR().
>
> Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
> ---
>   arch/arm/mach-zx/zx296702-pm-domain.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-zx/zx296702-pm-domain.c b/arch/arm/mach-zx/zx296702-pm-domain.c
> index e08574d..2037bcb 100644
> --- a/arch/arm/mach-zx/zx296702-pm-domain.c
> +++ b/arch/arm/mach-zx/zx296702-pm-domain.c
> @@ -169,9 +169,9 @@ static int zx296702_pd_probe(struct platform_device *pdev)
>   	}
>
>   	pcubase = devm_ioremap_resource(&pdev->dev, res);
> -	if (!pcubase) {
> +	if (IS_ERR(pcubase)) {
>   		dev_err(&pdev->dev, "ioremap fail.\n");
> -		return -EIO;
> +		return PTR_ERR(pcubase);
>   	}
>
>   	for (i = 0; i < ARRAY_SIZE(zx296702_pm_domains); ++i)
>

Thanks for fixing this issue.
Reviewed-by: Jun Nie <jun.nie at linaro.org>


From robh at kernel.org  Mon Feb  8 21:04:56 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 8 Feb 2016 23:04:56 -0600
Subject: [PATCH v4 16/17] FDT: Add a helper to get specified name subnode
In-Reply-To: <1454641552-12576-17-git-send-email-zhaoshenglong@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
 <1454641552-12576-17-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <CAL_JsqK8F6PQX2kC_+CtDk1-ykKRB3YB54o4FaypsRY_tNzK5w@mail.gmail.com>

On Thu, Feb 4, 2016 at 9:05 PM, Shannon Zhao <zhaoshenglong at huawei.com> wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
>
> Sometimes it needs to check if there is a node in FDT by full path.

I'm confused. Are you searching by full path or...

> Introduce this helper to get the specified name subnode if it exists.

name of sub node?

Either way, fdt_subnode_offset or fdt_path_offset doesn't work?

>
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> ---
> CC: Rob Herring <robh at kernel.org>
> ---
>  drivers/of/fdt.c       | 25 +++++++++++++++++++++++++
>  include/linux/of_fdt.h |  2 ++
>  2 files changed, 27 insertions(+)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 655f79d..eacb188 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -645,6 +645,31 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,
>  }
>
>  /**
> + * of_get_flat_dt_subnode_by_name - get subnode of specified node by name
> + *
> + * @node: the parent node
> + * @uname: the name of subnode
> + * @return offset of the subnode, or -FDT_ERR_NOTFOUND if there is none
> + */
> +
> +int of_get_flat_dt_subnode_by_name(unsigned long node, const char *uname)
> +{
> +       const void *blob = initial_boot_params;
> +       int offset;
> +       const char *pathp;
> +
> +       for (offset = fdt_first_subnode(blob, node);
> +            offset >= 0;
> +            offset = fdt_next_subnode(blob, offset)) {
> +               pathp = fdt_get_name(blob, offset, NULL);
> +               if (strcmp(pathp, uname) == 0)
> +                       return offset;
> +       }
> +
> +       return -FDT_ERR_NOTFOUND;
> +}
> +
> +/**
>   * of_get_flat_dt_root - find the root node in the flat blob
>   */
>  unsigned long __init of_get_flat_dt_root(void)
> diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
> index df9ef38..fc28162 100644
> --- a/include/linux/of_fdt.h
> +++ b/include/linux/of_fdt.h
> @@ -52,6 +52,8 @@ extern char __dtb_end[];
>  extern int of_scan_flat_dt(int (*it)(unsigned long node, const char *uname,
>                                      int depth, void *data),
>                            void *data);
> +extern int of_get_flat_dt_subnode_by_name(unsigned long node,
> +                                         const char *uname);
>  extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
>                                        int *size);
>  extern int of_flat_dt_is_compatible(unsigned long node, const char *name);
> --
> 2.0.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From kishon at ti.com  Mon Feb  8 21:13:22 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 9 Feb 2016 10:43:22 +0530
Subject: [PATCH 0/3] omap: hwmod: add default reset handling support
In-Reply-To: <20160208204446.GC19432@atomide.com>
References: <1454929941-23949-1-git-send-email-kishon@ti.com>
 <20160208204446.GC19432@atomide.com>
Message-ID: <56B97572.6080100@ti.com>

Hi Tony,

On Tuesday 09 February 2016 02:14 AM, Tony Lindgren wrote:
> Hi Kishon,
> 
> * Kishon Vijay Abraham I <kishon at ti.com> [160208 03:13]:
>> Add a new hwmod flag to indicate custom reset handling and use it
>> for devices that require custom reset handling (like dsp, ipu, iva).
>>
>> Tested PCIe on dra7-evm and dra72-evm.
>> I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
>> Or a way to test these cores to see if reset is not broken. Suman?
>>
>> I'll post this series once again after performing these tests.
> 
> Do we also still need to patch something in the pcie driver too
> or can all that be left out now?

With this series changes in PCIe driver is not required at all.

Thanks
Kishon

> 
> Regards,
> 
> Tony
> 
> 
>> Paul Walmsley (3):
>>   ARM: omap2+: omap_hwmod: introduce hwmod flag for custom reset
>>     handling
>>   ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for custom reset
>>     handling
>>   ARM: OMAP2+: hwmod: Add default reset handling
>>
>>  arch/arm/mach-omap2/omap_hwmod.c                   |   16 +++++++++++-----
>>  arch/arm/mach-omap2/omap_hwmod.h                   |   12 ++++++++++++
>>  arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
>>  arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
>>  .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
>>  arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
>>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
>>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
>>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
>>  10 files changed, 41 insertions(+), 5 deletions(-)
>>
>> -- 
>> 1.7.9.5
>>


From kishon at ti.com  Mon Feb  8 21:17:49 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 9 Feb 2016 10:47:49 +0530
Subject: [PATCH 0/3] omap: hwmod: add default reset handling support
In-Reply-To: <56B9037C.2050203@ti.com>
References: <1454929941-23949-1-git-send-email-kishon@ti.com>
 <56B9037C.2050203@ti.com>
Message-ID: <56B9767D.7000708@ti.com>

Hi,

On Tuesday 09 February 2016 02:37 AM, Suman Anna wrote:
> On 02/08/2016 05:12 AM, Kishon Vijay Abraham I wrote:
>> Add a new hwmod flag to indicate custom reset handling and use it
>> for devices that require custom reset handling (like dsp, ipu, iva).
>>
>> Tested PCIe on dra7-evm and dra72-evm.
>> I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
>> Or a way to test these cores to see if reset is not broken. Suman?
> 
> I won't be able to test this week, and have requested Dave to check on
> wkup_m3_rproc driver atleast. I see one potential issue (see my commment
> on the other thread), but can confirm that only after testing.
> 
> Have you tested multiple probe/removal sequences? Can you check the
> return status on the _hardreset_deassert call with your PCIe driver,
> believe even that one would return an error on multiple probes.

hmm.. the PCIe driver is built-in and can't be made as module because of other
issues in PCIe core. But looks like the first deassert succeeded since I didn't
observe the boot hang because of PCIe.

Thanks
Kishon

> 
> regards
> Suman
> 
>>
>> I'll post this series once again after performing these tests.
>>
>> Paul Walmsley (3):
>>   ARM: omap2+: omap_hwmod: introduce hwmod flag for custom reset
>>     handling
>>   ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for custom reset
>>     handling
>>   ARM: OMAP2+: hwmod: Add default reset handling
>>
>>  arch/arm/mach-omap2/omap_hwmod.c                   |   16 +++++++++++-----
>>  arch/arm/mach-omap2/omap_hwmod.h                   |   12 ++++++++++++
>>  arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
>>  arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
>>  .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
>>  arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
>>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
>>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
>>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
>>  10 files changed, 41 insertions(+), 5 deletions(-)
>>
> 


From lkp at intel.com  Mon Feb  8 21:30:47 2016
From: lkp at intel.com (kbuild test robot)
Date: Tue, 9 Feb 2016 13:30:47 +0800
Subject: [PATCH 14/14] clk: qcom: Migrate to clk_hw based registration
 and OF APIs
In-Reply-To: <1454982341-22715-15-git-send-email-sboyd@codeaurora.org>
Message-ID: <201602091317.cFLg4PVI%fengguang.wu@intel.com>

Hi Stephen,

[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.5-rc3]
[cannot apply to clk/clk-next next-20160208]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Stephen-Boyd/clk_hw-based-clkdev-DT-providers/20160209-095211
base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: i386-allmodconfig (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "of_clk_add_hw_provider" undefined!

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 53452 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/22b3ed58/attachment-0001.obj>

From maitysanchayan at gmail.com  Mon Feb  8 21:26:04 2016
From: maitysanchayan at gmail.com (Sanchayan Maity)
Date: Tue,  9 Feb 2016 10:56:04 +0530
Subject: [PATCH v1 0/2] Add DAC driver support for Vybrid SoC
Message-ID: <cover.1454939346.git.maitysanchayan@gmail.com>

Hello,

This patchset adds support for the DAC peripheral on Vybrid SoC.
Patchset is based on top of shawn's for-next branch and has been
tested on a Toradex Colibri VF50 module.

I had one query as to whether my implementation under the
IIO_CHAN_INFO_SCALE correct? I am not clear on exactly on how
the voltage_scale parameter is suppose to be set and used.

Feedbacks and comments most welcome.

Thanks & Regards,
Sanchayan.


Sanchayan Maity (2):
  ARM: dts: vfxxx: Add DAC node for Vybrid SoC
  iio: dac: vf610_dac: Add IIO DAC driver for Vybrid SoC

 .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
 arch/arm/boot/dts/vfxxx.dtsi                       |  18 ++
 drivers/iio/dac/Kconfig                            |   8 +
 drivers/iio/dac/Makefile                           |   1 +
 drivers/iio/dac/vf610_dac.c                        | 302 +++++++++++++++++++++
 5 files changed, 349 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
 create mode 100644 drivers/iio/dac/vf610_dac.c

-- 
2.7.1



From maitysanchayan at gmail.com  Mon Feb  8 21:26:05 2016
From: maitysanchayan at gmail.com (Sanchayan Maity)
Date: Tue,  9 Feb 2016 10:56:05 +0530
Subject: [PATCH v1 1/2] ARM: dts: vfxxx: Add DAC node for Vybrid SoC
In-Reply-To: <cover.1454939346.git.maitysanchayan@gmail.com>
References: <cover.1454939346.git.maitysanchayan@gmail.com>
Message-ID: <537afe56ca3ceafe130604d66636bc90bc827298.1454939346.git.maitysanchayan@gmail.com>

Add a device tree node entry for DAC peripheral on Vybrid SoC.

Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
---
 arch/arm/boot/dts/vfxxx.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index a5f07e3..8238069 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -602,6 +602,24 @@
 				status = "disabled";
 			};
 
+			dac0: dac at 400cc000 {
+				compatible = "fsl,vf610-dac";
+				reg = <0x400cc000 1000>;
+				interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
+				clock-names = "dac";
+				clocks = <&clks VF610_CLK_DAC0>;
+				status = "disabled";
+			};
+
+			dac1: dac at 400cd000 {
+				compatible = "fsl,vf610-dac";
+				reg = <0x400cd000 1000>;
+				interrupts = <56 IRQ_TYPE_LEVEL_HIGH>;
+				clock-names = "dac";
+				clocks = <&clks VF610_CLK_DAC1>;
+				status = "disabled";
+			};
+
 			fec0: ethernet at 400d0000 {
 				compatible = "fsl,mvf600-fec";
 				reg = <0x400d0000 0x1000>;
-- 
2.7.1



From maitysanchayan at gmail.com  Mon Feb  8 21:26:06 2016
From: maitysanchayan at gmail.com (Sanchayan Maity)
Date: Tue,  9 Feb 2016 10:56:06 +0530
Subject: [PATCH v1 2/2] iio: dac: vf610_dac: Add IIO DAC driver for Vybrid SoC
In-Reply-To: <cover.1454939346.git.maitysanchayan@gmail.com>
References: <cover.1454939346.git.maitysanchayan@gmail.com>
Message-ID: <5a699d45c89d239f3e49fa83d16a9b467016e219.1454939346.git.maitysanchayan@gmail.com>

Add driver support for DAC peripheral on Vybrid SoC.

Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
---
 .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
 drivers/iio/dac/Kconfig                            |   8 +
 drivers/iio/dac/Makefile                           |   1 +
 drivers/iio/dac/vf610_dac.c                        | 302 +++++++++++++++++++++
 4 files changed, 331 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
 create mode 100644 drivers/iio/dac/vf610_dac.c

diff --git a/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
new file mode 100644
index 0000000..97d7a40
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
@@ -0,0 +1,20 @@
+Freescale vf610 Digital to Analog Converter bindings
+
+The devicetree bindings are for the new DAC driver written for
+vf610 SoCs from Freescale.
+
+Required properties:
+- compatible: Should contain "fsl,vf610-dac"
+- reg: Offset and length of the register set for the device
+- interrupts: Should contain the interrupt for the device
+- clocks: The clock is needed by the DAC controller
+- clock-names: Must contain "dac", matching entry in the clocks property.
+
+Example:
+dac0: dac at 400cc000 {
+	compatible = "fsl,vf610-dac";
+	reg = <0x400cc000 0x1000>;
+	interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
+	clock-names = "dac";
+	clocks = <&clks VF610_CLK_DAC0>;
+};
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index e701e28..8eb0502 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -196,4 +196,12 @@ config MCP4922
 	  To compile this driver as a module, choose M here: the module
 	  will be called mcp4922.
 
+config VF610_DAC
+	tristate "Vybrid vf610 DAC driver"
+	help
+	  Say yes here to support Vybrid board digital-to-analog converter.
+
+	  This driver can also be built as a module. If so, the module will
+	  be called vf610_dac.
+
 endmenu
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index 63ae056..93feb27 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_MAX517) += max517.o
 obj-$(CONFIG_MAX5821) += max5821.o
 obj-$(CONFIG_MCP4725) += mcp4725.o
 obj-$(CONFIG_MCP4922) += mcp4922.o
+obj-$(CONFIG_VF610_DAC) += vf610_dac.o
diff --git a/drivers/iio/dac/vf610_dac.c b/drivers/iio/dac/vf610_dac.c
new file mode 100644
index 0000000..775b349
--- /dev/null
+++ b/drivers/iio/dac/vf610_dac.c
@@ -0,0 +1,302 @@
+/*
+ * Freescale Vybrid vf610 DAC driver
+ *
+ * Copyright 2016 Toradex AG
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define DRIVER_NAME "vf610-dac"
+
+#define VF610_DACx_STATCTRL		0x20
+
+#define VF610_DAC_DACEN			BIT(15)
+#define VF610_DAC_DACRFS		BIT(14)
+#define VF610_DAC_LPEN			BIT(11)
+
+#define VF610_DAC_DAT0(x)		((x) & 0xFFF)
+
+enum conversion_mode_sel {
+	VF610_DAC_CONV_HIGH_POWER,
+	VF610_DAC_CONV_LOW_POWER,
+};
+
+struct vf610_dac {
+	struct clk *clk;
+	struct device *dev;
+	enum conversion_mode_sel conv_mode;
+	void __iomem *regs;
+	int irq;
+};
+
+static int vf610_dac_init(struct vf610_dac *info)
+{
+	int val;
+
+	info->conv_mode = VF610_DAC_CONV_LOW_POWER;
+	val = VF610_DAC_DACEN | VF610_DAC_DACRFS |
+		VF610_DAC_LPEN;
+	writel(val, info->regs + VF610_DACx_STATCTRL);
+
+	return 0;
+}
+
+static int vf610_set_conversion_mode(struct iio_dev *indio_dev,
+				const struct iio_chan_spec *chan,
+				unsigned int mode)
+{
+	struct vf610_dac *info = iio_priv(indio_dev);
+	int val;
+
+	mutex_lock(&indio_dev->mlock);
+	info->conv_mode = mode;
+	val = readl(info->regs + VF610_DACx_STATCTRL);
+	if (mode)
+		val |= VF610_DAC_LPEN;
+	else
+		val &= ~VF610_DAC_LPEN;
+	writel(val, info->regs + VF610_DACx_STATCTRL);
+	mutex_unlock(&indio_dev->mlock);
+
+	return 0;
+}
+
+static int vf610_get_conversion_mode(struct iio_dev *indio_dev,
+				const struct iio_chan_spec *chan)
+{
+	struct vf610_dac *info = iio_priv(indio_dev);
+
+	return info->conv_mode;
+}
+
+static const char * const vf610_conv_modes[] = { "high-power", "low-power"};
+
+static const struct iio_enum vf610_conversion_mode = {
+	.items = vf610_conv_modes,
+	.num_items = ARRAY_SIZE(vf610_conv_modes),
+	.get = vf610_get_conversion_mode,
+	.set = vf610_set_conversion_mode,
+};
+
+static const struct iio_chan_spec_ext_info vf610_ext_info[] = {
+	IIO_ENUM("conversion_mode", IIO_SHARED_BY_DIR,
+		&vf610_conversion_mode),
+	{},
+};
+
+#define VF610_DAC_CHAN(_chan_type) { \
+	.type = (_chan_type), \
+	.indexed = -1, \
+	.output = 1, \
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+	.ext_info = vf610_ext_info, \
+}
+
+static const struct iio_chan_spec vf610_dac_iio_channels[] = {
+	VF610_DAC_CHAN(IIO_VOLTAGE),
+};
+
+static int vf610_read_raw(struct iio_dev *indio_dev,
+			struct iio_chan_spec const *chan,
+			int *val, int *val2,
+			long mask)
+{
+	struct vf610_dac *info = iio_priv(indio_dev);
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		*val = VF610_DAC_DAT0(readl(info->regs));
+		return IIO_VAL_INT;
+	case IIO_CHAN_INFO_SCALE:
+		/*
+		 * DACRFS is always 1 for valid reference and typical
+		 * reference voltage as per Vybrid datasheet is 3.3V
+		 * from section 9.1.2.1 of Vybrid datasheet
+		 */
+		*val = 3300 /* mV */;
+		*val2 = 12;
+		return IIO_VAL_FRACTIONAL_LOG2;
+
+	default:
+		break;
+	}
+
+	return -EINVAL;
+}
+
+static int vf610_write_raw(struct iio_dev *indio_dev,
+			struct iio_chan_spec const *chan,
+			int val, int val2,
+			long mask)
+{
+	struct vf610_dac *info = iio_priv(indio_dev);
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		mutex_lock(&indio_dev->mlock);
+		writel(VF610_DAC_DAT0(val), info->regs);
+		mutex_unlock(&indio_dev->mlock);
+		return 0;
+
+	default:
+		break;
+	}
+
+	return -EINVAL;
+}
+
+static const struct iio_info vf610_dac_iio_info = {
+	.driver_module = THIS_MODULE,
+	.read_raw = &vf610_read_raw,
+	.write_raw = &vf610_write_raw,
+};
+
+static const struct of_device_id vf610_dac_match[] = {
+	{ .compatible = "fsl,vf610-dac", },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, vf610_dac_match);
+
+static int vf610_dac_probe(struct platform_device *pdev)
+{
+	struct iio_dev *indio_dev;
+	struct vf610_dac *info;
+	struct resource *mem;
+	int ret;
+
+	indio_dev = devm_iio_device_alloc(&pdev->dev,
+					sizeof(struct vf610_dac));
+	if (!indio_dev) {
+		dev_err(&pdev->dev, "Failed allocating iio device\n");
+		return -ENOMEM;
+	}
+
+	info = iio_priv(indio_dev);
+	info->dev = &pdev->dev;
+
+	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	info->regs = devm_ioremap_resource(&pdev->dev, mem);
+	if (IS_ERR(info->regs))
+		return PTR_ERR(info->regs);
+
+	info->clk = devm_clk_get(&pdev->dev, "dac");
+	if (IS_ERR(info->clk)) {
+		dev_err(&pdev->dev, "failed getting clock, err = %ld\n",
+			PTR_ERR(info->clk));
+		return PTR_ERR(info->clk);
+	}
+
+	platform_set_drvdata(pdev, indio_dev);
+
+	indio_dev->name = dev_name(&pdev->dev);
+	indio_dev->dev.parent = &pdev->dev;
+	indio_dev->dev.of_node = pdev->dev.of_node;
+	indio_dev->info = &vf610_dac_iio_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->channels = vf610_dac_iio_channels;
+	indio_dev->num_channels = ARRAY_SIZE(vf610_dac_iio_channels);
+
+	ret = clk_prepare_enable(info->clk);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"Could not prepare or enable the clock\n");
+		return ret;
+	}
+
+	ret = iio_device_register(indio_dev);
+	if (ret) {
+		dev_err(&pdev->dev, "Couldn't register the device\n");
+		goto error_iio_device_register;
+	}
+
+	vf610_dac_init(info);
+
+	return 0;
+
+error_iio_device_register:
+	clk_disable_unprepare(info->clk);
+
+	return ret;
+}
+
+static int vf610_dac_remove(struct platform_device *pdev)
+{
+	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+	struct vf610_dac *info = iio_priv(indio_dev);
+
+	iio_device_unregister(indio_dev);
+	clk_disable_unprepare(info->clk);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int vf610_dac_suspend(struct device *dev)
+{
+	struct iio_dev *indio_dev = dev_get_drvdata(dev);
+	struct vf610_dac *info = iio_priv(indio_dev);
+	int val;
+
+	val = readl(info->regs + VF610_DACx_STATCTRL);
+	val &= ~VF610_DAC_DACEN;
+	writel(val, info->regs + VF610_DACx_STATCTRL);
+
+	clk_disable_unprepare(info->clk);
+
+	return 0;
+}
+
+static int vf610_dac_resume(struct device *dev)
+{
+	struct iio_dev *indio_dev = dev_get_drvdata(dev);
+	struct vf610_dac *info = iio_priv(indio_dev);
+	int ret;
+
+	ret = clk_prepare_enable(info->clk);
+	if (ret)
+		return ret;
+
+	vf610_dac_init(info);
+
+	return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(vf610_dac_pm_ops, vf610_dac_suspend, vf610_dac_resume);
+
+static struct platform_driver vf610_dac_driver = {
+	.probe          = vf610_dac_probe,
+	.remove         = vf610_dac_remove,
+	.driver         = {
+		.name   = DRIVER_NAME,
+		.of_match_table = vf610_dac_match,
+		.pm     = &vf610_dac_pm_ops,
+	},
+};
+module_platform_driver(vf610_dac_driver);
+
+MODULE_AUTHOR("Sanchayan Maity <sanchayan.maity at toradex.com");
+MODULE_DESCRIPTION("Freescale VF610 DAC driver");
+MODULE_LICENSE("GPL v2");
-- 
2.7.1



From dave.long at linaro.org  Mon Feb  8 21:38:55 2016
From: dave.long at linaro.org (David Long)
Date: Tue,  9 Feb 2016 00:38:55 -0500
Subject: [PATCH v3 0/2] Consolidate redundant register/stack access code
Message-ID: <1454996337-7935-1-git-send-email-dave.long@linaro.org>

From: "David A. Long" <dave.long at linaro.org>

Move duplicate and functionally equivalent code for accessing registers
and stack (CONFIG_HAVE_REGS_AND_STACK_ACCESS_API) from arch subdirs into
common kernel files.

I'm sending this out again (with updated distribution list) because v2
just never got pulled in, even though I don't think there were any
outstanding issues.

Changes since v1:
	Move the REG_OFFSET_NAME and REG_OFFSET_END macros to architecture-
	independent include file.

Changes since v2:
	No material changes, just merge up to v4.5-rc2.

David A. Long (2):
  Move the pt_regs_offset struct definition from arch to common include
    file
  Consolidate redundant register/stack access code

David A. Long (2):
  Move the pt_regs_offset struct definition from arch to common include
    file
  Consolidate redundant register/stack access code

 arch/arm/include/asm/ptrace.h          |   6 --
 arch/arm/kernel/ptrace.c               |  74 +---------------
 arch/hexagon/include/uapi/asm/ptrace.h |   3 -
 arch/powerpc/include/asm/ptrace.h      |  38 --------
 arch/powerpc/kernel/ptrace.c           |  65 +++-----------
 arch/s390/include/asm/ptrace.h         |   3 -
 arch/s390/kernel/ptrace.c              |  69 +++++----------
 arch/sh/include/asm/ptrace.h           |  48 +---------
 arch/sh/kernel/Makefile                |   2 +-
 arch/sh/kernel/ptrace.c                |  33 -------
 arch/sh/kernel/ptrace_32.c             |  50 +++++------
 arch/sh/kernel/ptrace_64.c             | 154 ++++++++++++++++-----------------
 arch/x86/include/asm/ptrace.h          |  37 --------
 arch/x86/kernel/ptrace.c               |  93 ++++++--------------
 include/linux/ptrace.h                 |  54 ++++++++++++
 kernel/ptrace.c                        |  38 ++++++++
 16 files changed, 258 insertions(+), 509 deletions(-)
 delete mode 100644 arch/sh/kernel/ptrace.c

-- 
2.5.0



From dave.long at linaro.org  Mon Feb  8 21:38:56 2016
From: dave.long at linaro.org (David Long)
Date: Tue,  9 Feb 2016 00:38:56 -0500
Subject: [PATCH v3 1/2] Move the pt_regs_offset struct definition from arch to
 common include file
In-Reply-To: <1454996337-7935-1-git-send-email-dave.long@linaro.org>
References: <1454996337-7935-1-git-send-email-dave.long@linaro.org>
Message-ID: <1454996337-7935-2-git-send-email-dave.long@linaro.org>

From: "David A. Long" <dave.long at linaro.org>

The pt_regs_offset structure is used for the HAVE_REGS_AND_STACK_ACCESS_API
feature and has identical definitions in four different arch ptrace.h
include files. It seems unlikely that definition would ever need to be
changed regardless of architecture so lets move it into
include/linux/ptrace.h, along with macros commonly used to access it.

Signed-off-by: David A. Long <dave.long at linaro.org>
Acked-by: Michael Ellerman <mpe at ellerman.id.au>
---
 arch/arm/kernel/ptrace.c     |   7 +-
 arch/powerpc/kernel/ptrace.c |  31 ++++-----
 arch/sh/include/asm/ptrace.h |   9 +--
 arch/sh/kernel/ptrace_32.c   |  48 +++++++-------
 arch/sh/kernel/ptrace_64.c   | 152 +++++++++++++++++++++----------------------
 arch/x86/kernel/ptrace.c     |  59 ++++++++---------
 include/linux/ptrace.h       |  12 ++++
 7 files changed, 152 insertions(+), 166 deletions(-)

diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index ef9119f..3b5a2ba 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -59,14 +59,9 @@
 #define BREAKINST_THUMB	0xde01
 #endif
 
-struct pt_regs_offset {
-	const char *name;
-	int offset;
-};
 
 #define REG_OFFSET_NAME(r) \
 	{.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
-#define REG_OFFSET_END {.name = NULL, .offset = 0}
 
 static const struct pt_regs_offset regoffset_table[] = {
 	REG_OFFSET_NAME(r0),
@@ -87,7 +82,7 @@ static const struct pt_regs_offset regoffset_table[] = {
 	REG_OFFSET_NAME(pc),
 	REG_OFFSET_NAME(cpsr),
 	REG_OFFSET_NAME(ORIG_r0),
-	REG_OFFSET_END,
+	REGS_OFFSET_END,
 };
 
 /**
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 30a03c0..77bd4c4 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -52,17 +52,10 @@
 #define PARAMETER_SAVE_AREA_OFFSET	48  /* bytes */
 #endif
 
-struct pt_regs_offset {
-	const char *name;
-	int offset;
-};
-
 #define STR(s)	#s			/* convert to string */
-#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
 #define GPR_OFFSET_NAME(num)	\
 	{.name = STR(r##num), .offset = offsetof(struct pt_regs, gpr[num])}, \
 	{.name = STR(gpr##num), .offset = offsetof(struct pt_regs, gpr[num])}
-#define REG_OFFSET_END {.name = NULL, .offset = 0}
 
 static const struct pt_regs_offset regoffset_table[] = {
 	GPR_OFFSET_NAME(0),
@@ -97,21 +90,21 @@ static const struct pt_regs_offset regoffset_table[] = {
 	GPR_OFFSET_NAME(29),
 	GPR_OFFSET_NAME(30),
 	GPR_OFFSET_NAME(31),
-	REG_OFFSET_NAME(nip),
-	REG_OFFSET_NAME(msr),
-	REG_OFFSET_NAME(ctr),
-	REG_OFFSET_NAME(link),
-	REG_OFFSET_NAME(xer),
-	REG_OFFSET_NAME(ccr),
+	REGS_OFFSET_NAME(nip),
+	REGS_OFFSET_NAME(msr),
+	REGS_OFFSET_NAME(ctr),
+	REGS_OFFSET_NAME(link),
+	REGS_OFFSET_NAME(xer),
+	REGS_OFFSET_NAME(ccr),
 #ifdef CONFIG_PPC64
-	REG_OFFSET_NAME(softe),
+	REGS_OFFSET_NAME(softe),
 #else
-	REG_OFFSET_NAME(mq),
+	REGS_OFFSET_NAME(mq),
 #endif
-	REG_OFFSET_NAME(trap),
-	REG_OFFSET_NAME(dar),
-	REG_OFFSET_NAME(dsisr),
-	REG_OFFSET_END,
+	REGS_OFFSET_NAME(trap),
+	REGS_OFFSET_NAME(dar),
+	REGS_OFFSET_NAME(dsisr),
+	REGS_OFFSET_END,
 };
 
 /**
diff --git a/arch/sh/include/asm/ptrace.h b/arch/sh/include/asm/ptrace.h
index 2506c7d..523955f 100644
--- a/arch/sh/include/asm/ptrace.h
+++ b/arch/sh/include/asm/ptrace.h
@@ -23,17 +23,10 @@
 /*
  * kprobe-based event tracer support
  */
-struct pt_regs_offset {
-	const char *name;
-	int offset;
-};
-
-#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
-#define REGS_OFFSET_NAME(num)	\
+#define REG_OFFSET_NAME(num)	\
 	{.name = __stringify(r##num), .offset = offsetof(struct pt_regs, regs[num])}
 #define TREGS_OFFSET_NAME(num)	\
 	{.name = __stringify(tr##num), .offset = offsetof(struct pt_regs, tregs[num])}
-#define REG_OFFSET_END {.name = NULL, .offset = 0}
 
 /* Query offset/name of register from its name/offset */
 extern int regs_query_register_offset(const char *name);
diff --git a/arch/sh/kernel/ptrace_32.c b/arch/sh/kernel/ptrace_32.c
index c1a6b89..e6fe4f4 100644
--- a/arch/sh/kernel/ptrace_32.c
+++ b/arch/sh/kernel/ptrace_32.c
@@ -277,30 +277,30 @@ static int dspregs_active(struct task_struct *target,
 #endif
 
 const struct pt_regs_offset regoffset_table[] = {
-	REGS_OFFSET_NAME(0),
-	REGS_OFFSET_NAME(1),
-	REGS_OFFSET_NAME(2),
-	REGS_OFFSET_NAME(3),
-	REGS_OFFSET_NAME(4),
-	REGS_OFFSET_NAME(5),
-	REGS_OFFSET_NAME(6),
-	REGS_OFFSET_NAME(7),
-	REGS_OFFSET_NAME(8),
-	REGS_OFFSET_NAME(9),
-	REGS_OFFSET_NAME(10),
-	REGS_OFFSET_NAME(11),
-	REGS_OFFSET_NAME(12),
-	REGS_OFFSET_NAME(13),
-	REGS_OFFSET_NAME(14),
-	REGS_OFFSET_NAME(15),
-	REG_OFFSET_NAME(pc),
-	REG_OFFSET_NAME(pr),
-	REG_OFFSET_NAME(sr),
-	REG_OFFSET_NAME(gbr),
-	REG_OFFSET_NAME(mach),
-	REG_OFFSET_NAME(macl),
-	REG_OFFSET_NAME(tra),
-	REG_OFFSET_END,
+	REG_OFFSET_NAME(0),
+	REG_OFFSET_NAME(1),
+	REG_OFFSET_NAME(2),
+	REG_OFFSET_NAME(3),
+	REG_OFFSET_NAME(4),
+	REG_OFFSET_NAME(5),
+	REG_OFFSET_NAME(6),
+	REG_OFFSET_NAME(7),
+	REG_OFFSET_NAME(8),
+	REG_OFFSET_NAME(9),
+	REG_OFFSET_NAME(10),
+	REG_OFFSET_NAME(11),
+	REG_OFFSET_NAME(12),
+	REG_OFFSET_NAME(13),
+	REG_OFFSET_NAME(14),
+	REG_OFFSET_NAME(15),
+	REGS_OFFSET_NAME(pc),
+	REGS_OFFSET_NAME(pr),
+	REGS_OFFSET_NAME(sr),
+	REGS_OFFSET_NAME(gbr),
+	REGS_OFFSET_NAME(mach),
+	REGS_OFFSET_NAME(macl),
+	REGS_OFFSET_NAME(tra),
+	REGS_OFFSET_END,
 };
 
 /*
diff --git a/arch/sh/kernel/ptrace_64.c b/arch/sh/kernel/ptrace_64.c
index 5cea973..af55bb6 100644
--- a/arch/sh/kernel/ptrace_64.c
+++ b/arch/sh/kernel/ptrace_64.c
@@ -253,82 +253,82 @@ static int fpregs_active(struct task_struct *target,
 #endif
 
 const struct pt_regs_offset regoffset_table[] = {
-	REG_OFFSET_NAME(pc),
-	REG_OFFSET_NAME(sr),
-	REG_OFFSET_NAME(syscall_nr),
-	REGS_OFFSET_NAME(0),
-	REGS_OFFSET_NAME(1),
-	REGS_OFFSET_NAME(2),
-	REGS_OFFSET_NAME(3),
-	REGS_OFFSET_NAME(4),
-	REGS_OFFSET_NAME(5),
-	REGS_OFFSET_NAME(6),
-	REGS_OFFSET_NAME(7),
-	REGS_OFFSET_NAME(8),
-	REGS_OFFSET_NAME(9),
-	REGS_OFFSET_NAME(10),
-	REGS_OFFSET_NAME(11),
-	REGS_OFFSET_NAME(12),
-	REGS_OFFSET_NAME(13),
-	REGS_OFFSET_NAME(14),
-	REGS_OFFSET_NAME(15),
-	REGS_OFFSET_NAME(16),
-	REGS_OFFSET_NAME(17),
-	REGS_OFFSET_NAME(18),
-	REGS_OFFSET_NAME(19),
-	REGS_OFFSET_NAME(20),
-	REGS_OFFSET_NAME(21),
-	REGS_OFFSET_NAME(22),
-	REGS_OFFSET_NAME(23),
-	REGS_OFFSET_NAME(24),
-	REGS_OFFSET_NAME(25),
-	REGS_OFFSET_NAME(26),
-	REGS_OFFSET_NAME(27),
-	REGS_OFFSET_NAME(28),
-	REGS_OFFSET_NAME(29),
-	REGS_OFFSET_NAME(30),
-	REGS_OFFSET_NAME(31),
-	REGS_OFFSET_NAME(32),
-	REGS_OFFSET_NAME(33),
-	REGS_OFFSET_NAME(34),
-	REGS_OFFSET_NAME(35),
-	REGS_OFFSET_NAME(36),
-	REGS_OFFSET_NAME(37),
-	REGS_OFFSET_NAME(38),
-	REGS_OFFSET_NAME(39),
-	REGS_OFFSET_NAME(40),
-	REGS_OFFSET_NAME(41),
-	REGS_OFFSET_NAME(42),
-	REGS_OFFSET_NAME(43),
-	REGS_OFFSET_NAME(44),
-	REGS_OFFSET_NAME(45),
-	REGS_OFFSET_NAME(46),
-	REGS_OFFSET_NAME(47),
-	REGS_OFFSET_NAME(48),
-	REGS_OFFSET_NAME(49),
-	REGS_OFFSET_NAME(50),
-	REGS_OFFSET_NAME(51),
-	REGS_OFFSET_NAME(52),
-	REGS_OFFSET_NAME(53),
-	REGS_OFFSET_NAME(54),
-	REGS_OFFSET_NAME(55),
-	REGS_OFFSET_NAME(56),
-	REGS_OFFSET_NAME(57),
-	REGS_OFFSET_NAME(58),
-	REGS_OFFSET_NAME(59),
-	REGS_OFFSET_NAME(60),
-	REGS_OFFSET_NAME(61),
-	REGS_OFFSET_NAME(62),
-	REGS_OFFSET_NAME(63),
-	TREGS_OFFSET_NAME(0),
-	TREGS_OFFSET_NAME(1),
-	TREGS_OFFSET_NAME(2),
-	TREGS_OFFSET_NAME(3),
-	TREGS_OFFSET_NAME(4),
-	TREGS_OFFSET_NAME(5),
-	TREGS_OFFSET_NAME(6),
-	TREGS_OFFSET_NAME(7),
-	REG_OFFSET_END,
+	REGS_OFFSET_NAME(pc),
+	REGS_OFFSET_NAME(sr),
+	REGS_OFFSET_NAME(syscall_nr),
+	REG_OFFSET_NAME(0),
+	REG_OFFSET_NAME(1),
+	REG_OFFSET_NAME(2),
+	REG_OFFSET_NAME(3),
+	REG_OFFSET_NAME(4),
+	REG_OFFSET_NAME(5),
+	REG_OFFSET_NAME(6),
+	REG_OFFSET_NAME(7),
+	REG_OFFSET_NAME(8),
+	REG_OFFSET_NAME(9),
+	REG_OFFSET_NAME(10),
+	REG_OFFSET_NAME(11),
+	REG_OFFSET_NAME(12),
+	REG_OFFSET_NAME(13),
+	REG_OFFSET_NAME(14),
+	REG_OFFSET_NAME(15),
+	REG_OFFSET_NAME(16),
+	REG_OFFSET_NAME(17),
+	REG_OFFSET_NAME(18),
+	REG_OFFSET_NAME(19),
+	REG_OFFSET_NAME(20),
+	REG_OFFSET_NAME(21),
+	REG_OFFSET_NAME(22),
+	REG_OFFSET_NAME(23),
+	REG_OFFSET_NAME(24),
+	REG_OFFSET_NAME(25),
+	REG_OFFSET_NAME(26),
+	REG_OFFSET_NAME(27),
+	REG_OFFSET_NAME(28),
+	REG_OFFSET_NAME(29),
+	REG_OFFSET_NAME(30),
+	REG_OFFSET_NAME(31),
+	REG_OFFSET_NAME(32),
+	REG_OFFSET_NAME(33),
+	REG_OFFSET_NAME(34),
+	REG_OFFSET_NAME(35),
+	REG_OFFSET_NAME(36),
+	REG_OFFSET_NAME(37),
+	REG_OFFSET_NAME(38),
+	REG_OFFSET_NAME(39),
+	REG_OFFSET_NAME(40),
+	REG_OFFSET_NAME(41),
+	REG_OFFSET_NAME(42),
+	REG_OFFSET_NAME(43),
+	REG_OFFSET_NAME(44),
+	REG_OFFSET_NAME(45),
+	REG_OFFSET_NAME(46),
+	REG_OFFSET_NAME(47),
+	REG_OFFSET_NAME(48),
+	REG_OFFSET_NAME(49),
+	REG_OFFSET_NAME(50),
+	REG_OFFSET_NAME(51),
+	REG_OFFSET_NAME(52),
+	REG_OFFSET_NAME(53),
+	REG_OFFSET_NAME(54),
+	REG_OFFSET_NAME(55),
+	REG_OFFSET_NAME(56),
+	REG_OFFSET_NAME(57),
+	REG_OFFSET_NAME(58),
+	REG_OFFSET_NAME(59),
+	REG_OFFSET_NAME(60),
+	REG_OFFSET_NAME(61),
+	REG_OFFSET_NAME(62),
+	REG_OFFSET_NAME(63),
+	TREG_OFFSET_NAME(0),
+	TREG_OFFSET_NAME(1),
+	TREG_OFFSET_NAME(2),
+	TREG_OFFSET_NAME(3),
+	TREG_OFFSET_NAME(4),
+	TREG_OFFSET_NAME(5),
+	TREG_OFFSET_NAME(6),
+	TREG_OFFSET_NAME(7),
+	REGS_OFFSET_END,
 };
 
 /*
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 32e9d9c..ff3314f 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -51,45 +51,38 @@ enum x86_regset {
 	REGSET_IOPERM32,
 };
 
-struct pt_regs_offset {
-	const char *name;
-	int offset;
-};
-
-#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
-#define REG_OFFSET_END {.name = NULL, .offset = 0}
 
 static const struct pt_regs_offset regoffset_table[] = {
 #ifdef CONFIG_X86_64
-	REG_OFFSET_NAME(r15),
-	REG_OFFSET_NAME(r14),
-	REG_OFFSET_NAME(r13),
-	REG_OFFSET_NAME(r12),
-	REG_OFFSET_NAME(r11),
-	REG_OFFSET_NAME(r10),
-	REG_OFFSET_NAME(r9),
-	REG_OFFSET_NAME(r8),
+	REGS_OFFSET_NAME(r15),
+	REGS_OFFSET_NAME(r14),
+	REGS_OFFSET_NAME(r13),
+	REGS_OFFSET_NAME(r12),
+	REGS_OFFSET_NAME(r11),
+	REGS_OFFSET_NAME(r10),
+	REGS_OFFSET_NAME(r9),
+	REGS_OFFSET_NAME(r8),
 #endif
-	REG_OFFSET_NAME(bx),
-	REG_OFFSET_NAME(cx),
-	REG_OFFSET_NAME(dx),
-	REG_OFFSET_NAME(si),
-	REG_OFFSET_NAME(di),
-	REG_OFFSET_NAME(bp),
-	REG_OFFSET_NAME(ax),
+	REGS_OFFSET_NAME(bx),
+	REGS_OFFSET_NAME(cx),
+	REGS_OFFSET_NAME(dx),
+	REGS_OFFSET_NAME(si),
+	REGS_OFFSET_NAME(di),
+	REGS_OFFSET_NAME(bp),
+	REGS_OFFSET_NAME(ax),
 #ifdef CONFIG_X86_32
-	REG_OFFSET_NAME(ds),
-	REG_OFFSET_NAME(es),
-	REG_OFFSET_NAME(fs),
-	REG_OFFSET_NAME(gs),
+	REGS_OFFSET_NAME(ds),
+	REGS_OFFSET_NAME(es),
+	REGS_OFFSET_NAME(fs),
+	REGS_OFFSET_NAME(gs),
 #endif
-	REG_OFFSET_NAME(orig_ax),
-	REG_OFFSET_NAME(ip),
-	REG_OFFSET_NAME(cs),
-	REG_OFFSET_NAME(flags),
-	REG_OFFSET_NAME(sp),
-	REG_OFFSET_NAME(ss),
-	REG_OFFSET_END,
+	REGS_OFFSET_NAME(orig_ax),
+	REGS_OFFSET_NAME(ip),
+	REGS_OFFSET_NAME(cs),
+	REGS_OFFSET_NAME(flags),
+	REGS_OFFSET_NAME(sp),
+	REGS_OFFSET_NAME(ss),
+	REGS_OFFSET_END,
 };
 
 /**
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 504c98a..4e1c6fd 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -406,4 +406,16 @@ extern int task_current_syscall(struct task_struct *target, long *callno,
 				unsigned long args[6], unsigned int maxargs,
 				unsigned long *sp, unsigned long *pc);
 
+#ifdef	CONFIG_HAVE_REGS_AND_STACK_ACCESS_API
+
+#define REGS_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
+#define REGS_OFFSET_END {.name = NULL, .offset = 0}
+
+struct pt_regs_offset {
+	const char *name;
+	int offset;
+};
+
+#endif	/* CONFIG_HAVE_REGS_AND_STACK_ACCESS_API */
+
 #endif
-- 
2.5.0



From dave.long at linaro.org  Mon Feb  8 21:38:57 2016
From: dave.long at linaro.org (David Long)
Date: Tue,  9 Feb 2016 00:38:57 -0500
Subject: [PATCH v3 2/2] Consolidate redundant register/stack access code
In-Reply-To: <1454996337-7935-1-git-send-email-dave.long@linaro.org>
References: <1454996337-7935-1-git-send-email-dave.long@linaro.org>
Message-ID: <1454996337-7935-3-git-send-email-dave.long@linaro.org>

From: "David A. Long" <dave.long at linaro.org>

Several architectures have identical or functionally equivalent code
implementing parts of the HAVE_REGS_AND_STACK_ACCESS_API feature.  Move
that code out of the architecture directories.

Signed-off-by: David A. Long <dave.long at linaro.org>
---
 arch/arm/include/asm/ptrace.h          |  6 ---
 arch/arm/kernel/ptrace.c               | 67 +--------------------------------
 arch/hexagon/include/uapi/asm/ptrace.h |  3 --
 arch/powerpc/include/asm/ptrace.h      | 38 -------------------
 arch/powerpc/kernel/ptrace.c           | 34 +----------------
 arch/s390/include/asm/ptrace.h         |  3 --
 arch/s390/kernel/ptrace.c              | 69 ++++++++++------------------------
 arch/sh/include/asm/ptrace.h           | 39 -------------------
 arch/sh/kernel/Makefile                |  2 +-
 arch/sh/kernel/ptrace.c                | 33 ----------------
 arch/sh/kernel/ptrace_32.c             |  2 +-
 arch/sh/kernel/ptrace_64.c             |  2 +-
 arch/x86/include/asm/ptrace.h          | 37 ------------------
 arch/x86/kernel/ptrace.c               | 34 +----------------
 include/linux/ptrace.h                 | 42 +++++++++++++++++++++
 kernel/ptrace.c                        | 38 +++++++++++++++++++
 16 files changed, 106 insertions(+), 343 deletions(-)
 delete mode 100644 arch/sh/kernel/ptrace.c

diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
index 51622ba..84a0ea4 100644
--- a/arch/arm/include/asm/ptrace.h
+++ b/arch/arm/include/asm/ptrace.h
@@ -120,12 +120,6 @@ extern unsigned long profile_pc(struct pt_regs *regs);
 #include <linux/types.h>
 #define MAX_REG_OFFSET (offsetof(struct pt_regs, ARM_ORIG_r0))
 
-extern int regs_query_register_offset(const char *name);
-extern const char *regs_query_register_name(unsigned int offset);
-extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
-extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
-					       unsigned int n);
-
 /**
  * regs_get_register() - get register value from its offset
  * @regs:	   pt_regs from which register value is gotten
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index 3b5a2ba..f26e23b 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -63,7 +63,7 @@
 #define REG_OFFSET_NAME(r) \
 	{.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
 
-static const struct pt_regs_offset regoffset_table[] = {
+const struct pt_regs_offset regs_offset_table[] = {
 	REG_OFFSET_NAME(r0),
 	REG_OFFSET_NAME(r1),
 	REG_OFFSET_NAME(r2),
@@ -85,71 +85,6 @@ static const struct pt_regs_offset regoffset_table[] = {
 	REGS_OFFSET_END,
 };
 
-/**
- * regs_query_register_offset() - query register offset from its name
- * @name:	the name of a register
- *
- * regs_query_register_offset() returns the offset of a register in struct
- * pt_regs from its name. If the name is invalid, this returns -EINVAL;
- */
-int regs_query_register_offset(const char *name)
-{
-	const struct pt_regs_offset *roff;
-	for (roff = regoffset_table; roff->name != NULL; roff++)
-		if (!strcmp(roff->name, name))
-			return roff->offset;
-	return -EINVAL;
-}
-
-/**
- * regs_query_register_name() - query register name from its offset
- * @offset:	the offset of a register in struct pt_regs.
- *
- * regs_query_register_name() returns the name of a register from its
- * offset in struct pt_regs. If the @offset is invalid, this returns NULL;
- */
-const char *regs_query_register_name(unsigned int offset)
-{
-	const struct pt_regs_offset *roff;
-	for (roff = regoffset_table; roff->name != NULL; roff++)
-		if (roff->offset == offset)
-			return roff->name;
-	return NULL;
-}
-
-/**
- * regs_within_kernel_stack() - check the address in the stack
- * @regs:      pt_regs which contains kernel stack pointer.
- * @addr:      address which is checked.
- *
- * regs_within_kernel_stack() checks @addr is within the kernel stack page(s).
- * If @addr is within the kernel stack, it returns true. If not, returns false.
- */
-bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr)
-{
-	return ((addr & ~(THREAD_SIZE - 1))  ==
-		(kernel_stack_pointer(regs) & ~(THREAD_SIZE - 1)));
-}
-
-/**
- * regs_get_kernel_stack_nth() - get Nth entry of the stack
- * @regs:	pt_regs which contains kernel stack pointer.
- * @n:		stack entry number.
- *
- * regs_get_kernel_stack_nth() returns @n th entry of the kernel stack which
- * is specified by @regs. If the @n th entry is NOT in the kernel stack,
- * this returns 0.
- */
-unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs, unsigned int n)
-{
-	unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
-	addr += n;
-	if (regs_within_kernel_stack(regs, (unsigned long)addr))
-		return *addr;
-	else
-		return 0;
-}
-
 /*
  * this routine will get a word off of the processes privileged stack.
  * the offset is how far from the base addr as stored in the THREAD.
diff --git a/arch/hexagon/include/uapi/asm/ptrace.h b/arch/hexagon/include/uapi/asm/ptrace.h
index 065e5b3..0afb664 100644
--- a/arch/hexagon/include/uapi/asm/ptrace.h
+++ b/arch/hexagon/include/uapi/asm/ptrace.h
@@ -29,9 +29,6 @@
 #define profile_pc(regs) instruction_pointer(regs)
 
 /* kprobe-based event tracer support */
-extern int regs_query_register_offset(const char *name);
-extern const char *regs_query_register_name(unsigned int offset);
-
 #define current_pt_regs() \
 	((struct pt_regs *) \
 	 ((unsigned long)current_thread_info() + THREAD_SIZE) - 1)
diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index c0c61fa..64b9b3d 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -156,8 +156,6 @@ do {									      \
 
 #include <linux/stddef.h>
 #include <linux/thread_info.h>
-extern int regs_query_register_offset(const char *name);
-extern const char *regs_query_register_name(unsigned int offset);
 #define MAX_REG_OFFSET (offsetof(struct pt_regs, dsisr))
 
 /**
@@ -177,42 +175,6 @@ static inline unsigned long regs_get_register(struct pt_regs *regs,
 	return *(unsigned long *)((unsigned long)regs + offset);
 }
 
-/**
- * regs_within_kernel_stack() - check the address in the stack
- * @regs:      pt_regs which contains kernel stack pointer.
- * @addr:      address which is checked.
- *
- * regs_within_kernel_stack() checks @addr is within the kernel stack page(s).
- * If @addr is within the kernel stack, it returns true. If not, returns false.
- */
-
-static inline bool regs_within_kernel_stack(struct pt_regs *regs,
-						unsigned long addr)
-{
-	return ((addr & ~(THREAD_SIZE - 1))  ==
-		(kernel_stack_pointer(regs) & ~(THREAD_SIZE - 1)));
-}
-
-/**
- * regs_get_kernel_stack_nth() - get Nth entry of the stack
- * @regs:	pt_regs which contains kernel stack pointer.
- * @n:		stack entry number.
- *
- * regs_get_kernel_stack_nth() returns @n th entry of the kernel stack which
- * is specified by @regs. If the @n th entry is NOT in the kernel stack,
- * this returns 0.
- */
-static inline unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
-						      unsigned int n)
-{
-	unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
-	addr += n;
-	if (regs_within_kernel_stack(regs, (unsigned long)addr))
-		return *addr;
-	else
-		return 0;
-}
-
 #endif /* __ASSEMBLY__ */
 
 #ifndef __powerpc64__
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 77bd4c4..1f8310a 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -57,7 +57,7 @@
 	{.name = STR(r##num), .offset = offsetof(struct pt_regs, gpr[num])}, \
 	{.name = STR(gpr##num), .offset = offsetof(struct pt_regs, gpr[num])}
 
-static const struct pt_regs_offset regoffset_table[] = {
+const struct pt_regs_offset regs_offset_table[] = {
 	GPR_OFFSET_NAME(0),
 	GPR_OFFSET_NAME(1),
 	GPR_OFFSET_NAME(2),
@@ -107,38 +107,6 @@ static const struct pt_regs_offset regoffset_table[] = {
 	REGS_OFFSET_END,
 };
 
-/**
- * regs_query_register_offset() - query register offset from its name
- * @name:	the name of a register
- *
- * regs_query_register_offset() returns the offset of a register in struct
- * pt_regs from its name. If the name is invalid, this returns -EINVAL;
- */
-int regs_query_register_offset(const char *name)
-{
-	const struct pt_regs_offset *roff;
-	for (roff = regoffset_table; roff->name != NULL; roff++)
-		if (!strcmp(roff->name, name))
-			return roff->offset;
-	return -EINVAL;
-}
-
-/**
- * regs_query_register_name() - query register name from its offset
- * @offset:	the offset of a register in struct pt_regs.
- *
- * regs_query_register_name() returns the name of a register from its
- * offset in struct pt_regs. If the @offset is invalid, this returns NULL;
- */
-const char *regs_query_register_name(unsigned int offset)
-{
-	const struct pt_regs_offset *roff;
-	for (roff = regoffset_table; roff->name != NULL; roff++)
-		if (roff->offset == offset)
-			return roff->name;
-	return NULL;
-}
-
 /*
  * does not yet catch signals sent when the child dies.
  * in exit.c or in signal.c.
diff --git a/arch/s390/include/asm/ptrace.h b/arch/s390/include/asm/ptrace.h
index 99bc456..890bc54 100644
--- a/arch/s390/include/asm/ptrace.h
+++ b/arch/s390/include/asm/ptrace.h
@@ -164,10 +164,7 @@ static inline void instruction_pointer_set(struct pt_regs *regs,
 	regs->psw.addr = val;
 }
 
-int regs_query_register_offset(const char *name);
-const char *regs_query_register_name(unsigned int offset);
 unsigned long regs_get_register(struct pt_regs *regs, unsigned int offset);
-unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs, unsigned int n);
 
 static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
 {
diff --git a/arch/s390/kernel/ptrace.c b/arch/s390/kernel/ptrace.c
index 49b1c13..8e75a93 100644
--- a/arch/s390/kernel/ptrace.c
+++ b/arch/s390/kernel/ptrace.c
@@ -1430,9 +1430,26 @@ const struct user_regset_view *task_user_regset_view(struct task_struct *task)
 	return &user_s390_view;
 }
 
-static const char *gpr_names[NUM_GPRS] = {
-	"r0", "r1",  "r2",  "r3",  "r4",  "r5",  "r6",  "r7",
-	"r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15",
+#define REG_OFFSET_NAME(r) {.name = "r" #r, .offset = r}
+
+const struct pt_regs_offset regs_offset_table[NUM_GPRS+1] = {
+	REG_OFFSET_NAME(0),
+	REG_OFFSET_NAME(1),
+	REG_OFFSET_NAME(2),
+	REG_OFFSET_NAME(3),
+	REG_OFFSET_NAME(4),
+	REG_OFFSET_NAME(5),
+	REG_OFFSET_NAME(6),
+	REG_OFFSET_NAME(7),
+	REG_OFFSET_NAME(8),
+	REG_OFFSET_NAME(9),
+	REG_OFFSET_NAME(10),
+	REG_OFFSET_NAME(11),
+	REG_OFFSET_NAME(12),
+	REG_OFFSET_NAME(13),
+	REG_OFFSET_NAME(14),
+	REG_OFFSET_NAME(15),
+	REGS_OFFSET_END
 };
 
 unsigned long regs_get_register(struct pt_regs *regs, unsigned int offset)
@@ -1441,49 +1458,3 @@ unsigned long regs_get_register(struct pt_regs *regs, unsigned int offset)
 		return 0;
 	return regs->gprs[offset];
 }
-
-int regs_query_register_offset(const char *name)
-{
-	unsigned long offset;
-
-	if (!name || *name != 'r')
-		return -EINVAL;
-	if (kstrtoul(name + 1, 10, &offset))
-		return -EINVAL;
-	if (offset >= NUM_GPRS)
-		return -EINVAL;
-	return offset;
-}
-
-const char *regs_query_register_name(unsigned int offset)
-{
-	if (offset >= NUM_GPRS)
-		return NULL;
-	return gpr_names[offset];
-}
-
-static int regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr)
-{
-	unsigned long ksp = kernel_stack_pointer(regs);
-
-	return (addr & ~(THREAD_SIZE - 1)) == (ksp & ~(THREAD_SIZE - 1));
-}
-
-/**
- * regs_get_kernel_stack_nth() - get Nth entry of the stack
- * @regs:pt_regs which contains kernel stack pointer.
- * @n:stack entry number.
- *
- * regs_get_kernel_stack_nth() returns @n th entry of the kernel stack which
- * is specifined by @regs. If the @n th entry is NOT in the kernel stack,
- * this returns 0.
- */
-unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs, unsigned int n)
-{
-	unsigned long addr;
-
-	addr = kernel_stack_pointer(regs) + n * sizeof(long);
-	if (!regs_within_kernel_stack(regs, addr))
-		return 0;
-	return *(unsigned long *)addr;
-}
diff --git a/arch/sh/include/asm/ptrace.h b/arch/sh/include/asm/ptrace.h
index 523955f..8045eb4 100644
--- a/arch/sh/include/asm/ptrace.h
+++ b/arch/sh/include/asm/ptrace.h
@@ -29,10 +29,6 @@
 	{.name = __stringify(tr##num), .offset = offsetof(struct pt_regs, tregs[num])}
 
 /* Query offset/name of register from its name/offset */
-extern int regs_query_register_offset(const char *name);
-extern const char *regs_query_register_name(unsigned int offset);
-
-extern const struct pt_regs_offset regoffset_table[];
 
 /**
  * regs_get_register() - get register value from its offset
@@ -51,41 +47,6 @@ static inline unsigned long regs_get_register(struct pt_regs *regs,
 	return *(unsigned long *)((unsigned long)regs + offset);
 }
 
-/**
- * regs_within_kernel_stack() - check the address in the stack
- * @regs:	pt_regs which contains kernel stack pointer.
- * @addr:	address which is checked.
- *
- * regs_within_kernel_stack() checks @addr is within the kernel stack page(s).
- * If @addr is within the kernel stack, it returns true. If not, returns false.
- */
-static inline int regs_within_kernel_stack(struct pt_regs *regs,
-					   unsigned long addr)
-{
-	return ((addr & ~(THREAD_SIZE - 1))  ==
-		(kernel_stack_pointer(regs) & ~(THREAD_SIZE - 1)));
-}
-
-/**
- * regs_get_kernel_stack_nth() - get Nth entry of the stack
- * @regs:	pt_regs which contains kernel stack pointer.
- * @n:		stack entry number.
- *
- * regs_get_kernel_stack_nth() returns @n th entry of the kernel stack which
- * is specified by @regs. If the @n th entry is NOT in the kernel stack,
- * this returns 0.
- */
-static inline unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
-						      unsigned int n)
-{
-	unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
-	addr += n;
-	if (regs_within_kernel_stack(regs, (unsigned long)addr))
-		return *addr;
-	else
-		return 0;
-}
-
 struct perf_event;
 struct perf_sample_data;
 
diff --git a/arch/sh/kernel/Makefile b/arch/sh/kernel/Makefile
index 2ccf36c..4ae9a11 100644
--- a/arch/sh/kernel/Makefile
+++ b/arch/sh/kernel/Makefile
@@ -14,7 +14,7 @@ CFLAGS_REMOVE_return_address.o = -pg
 obj-y	:= debugtraps.o dma-nommu.o dumpstack.o 		\
 	   idle.o io.o irq.o irq_$(BITS).o kdebugfs.o			\
 	   machvec.o nmi_debug.o process.o				\
-	   process_$(BITS).o ptrace.o ptrace_$(BITS).o			\
+	   process_$(BITS).o ptrace_$(BITS).o				\
 	   reboot.o return_address.o					\
 	   setup.o signal_$(BITS).o sys_sh.o 				\
 	   syscalls_$(BITS).o time.o topology.o traps.o			\
diff --git a/arch/sh/kernel/ptrace.c b/arch/sh/kernel/ptrace.c
deleted file mode 100644
index 0a05983..0000000
--- a/arch/sh/kernel/ptrace.c
+++ /dev/null
@@ -1,33 +0,0 @@
-#include <linux/ptrace.h>
-
-/**
- * regs_query_register_offset() - query register offset from its name
- * @name:	the name of a register
- *
- * regs_query_register_offset() returns the offset of a register in struct
- * pt_regs from its name. If the name is invalid, this returns -EINVAL;
- */
-int regs_query_register_offset(const char *name)
-{
-	const struct pt_regs_offset *roff;
-	for (roff = regoffset_table; roff->name != NULL; roff++)
-		if (!strcmp(roff->name, name))
-			return roff->offset;
-	return -EINVAL;
-}
-
-/**
- * regs_query_register_name() - query register name from its offset
- * @offset:	the offset of a register in struct pt_regs.
- *
- * regs_query_register_name() returns the name of a register from its
- * offset in struct pt_regs. If the @offset is invalid, this returns NULL;
- */
-const char *regs_query_register_name(unsigned int offset)
-{
-	const struct pt_regs_offset *roff;
-	for (roff = regoffset_table; roff->name != NULL; roff++)
-		if (roff->offset == offset)
-			return roff->name;
-	return NULL;
-}
diff --git a/arch/sh/kernel/ptrace_32.c b/arch/sh/kernel/ptrace_32.c
index e6fe4f4..c5c385c 100644
--- a/arch/sh/kernel/ptrace_32.c
+++ b/arch/sh/kernel/ptrace_32.c
@@ -276,7 +276,7 @@ static int dspregs_active(struct task_struct *target,
 }
 #endif
 
-const struct pt_regs_offset regoffset_table[] = {
+const struct pt_regs_offset regs_offset_table[] = {
 	REG_OFFSET_NAME(0),
 	REG_OFFSET_NAME(1),
 	REG_OFFSET_NAME(2),
diff --git a/arch/sh/kernel/ptrace_64.c b/arch/sh/kernel/ptrace_64.c
index af55bb6..565227ef 100644
--- a/arch/sh/kernel/ptrace_64.c
+++ b/arch/sh/kernel/ptrace_64.c
@@ -252,7 +252,7 @@ static int fpregs_active(struct task_struct *target,
 }
 #endif
 
-const struct pt_regs_offset regoffset_table[] = {
+const struct pt_regs_offset regs_offset_table[] = {
 	REGS_OFFSET_NAME(pc),
 	REGS_OFFSET_NAME(sr),
 	REGS_OFFSET_NAME(syscall_nr),
diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 6271281..0f498ff 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -156,8 +156,6 @@ static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
 #include <asm-generic/ptrace.h>
 
 /* Query offset/name of register from its name/offset */
-extern int regs_query_register_offset(const char *name);
-extern const char *regs_query_register_name(unsigned int offset);
 #define MAX_REG_OFFSET (offsetof(struct pt_regs, ss))
 
 /**
@@ -186,41 +184,6 @@ static inline unsigned long regs_get_register(struct pt_regs *regs,
 	return *(unsigned long *)((unsigned long)regs + offset);
 }
 
-/**
- * regs_within_kernel_stack() - check the address in the stack
- * @regs:	pt_regs which contains kernel stack pointer.
- * @addr:	address which is checked.
- *
- * regs_within_kernel_stack() checks @addr is within the kernel stack page(s).
- * If @addr is within the kernel stack, it returns true. If not, returns false.
- */
-static inline int regs_within_kernel_stack(struct pt_regs *regs,
-					   unsigned long addr)
-{
-	return ((addr & ~(THREAD_SIZE - 1))  ==
-		(kernel_stack_pointer(regs) & ~(THREAD_SIZE - 1)));
-}
-
-/**
- * regs_get_kernel_stack_nth() - get Nth entry of the stack
- * @regs:	pt_regs which contains kernel stack pointer.
- * @n:		stack entry number.
- *
- * regs_get_kernel_stack_nth() returns @n th entry of the kernel stack which
- * is specified by @regs. If the @n th entry is NOT in the kernel stack,
- * this returns 0.
- */
-static inline unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
-						      unsigned int n)
-{
-	unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
-	addr += n;
-	if (regs_within_kernel_stack(regs, (unsigned long)addr))
-		return *addr;
-	else
-		return 0;
-}
-
 #define arch_has_single_step()	(1)
 #ifdef CONFIG_X86_DEBUGCTLMSR
 #define arch_has_block_step()	(1)
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index ff3314f..e380e3d 100644
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -52,7 +52,7 @@ enum x86_regset {
 };
 
 
-static const struct pt_regs_offset regoffset_table[] = {
+const struct pt_regs_offset regs_offset_table[] = {
 #ifdef CONFIG_X86_64
 	REGS_OFFSET_NAME(r15),
 	REGS_OFFSET_NAME(r14),
@@ -85,38 +85,6 @@ static const struct pt_regs_offset regoffset_table[] = {
 	REGS_OFFSET_END,
 };
 
-/**
- * regs_query_register_offset() - query register offset from its name
- * @name:	the name of a register
- *
- * regs_query_register_offset() returns the offset of a register in struct
- * pt_regs from its name. If the name is invalid, this returns -EINVAL;
- */
-int regs_query_register_offset(const char *name)
-{
-	const struct pt_regs_offset *roff;
-	for (roff = regoffset_table; roff->name != NULL; roff++)
-		if (!strcmp(roff->name, name))
-			return roff->offset;
-	return -EINVAL;
-}
-
-/**
- * regs_query_register_name() - query register name from its offset
- * @offset:	the offset of a register in struct pt_regs.
- *
- * regs_query_register_name() returns the name of a register from its
- * offset in struct pt_regs. If the @offset is invalid, this returns NULL;
- */
-const char *regs_query_register_name(unsigned int offset)
-{
-	const struct pt_regs_offset *roff;
-	for (roff = regoffset_table; roff->name != NULL; roff++)
-		if (roff->offset == offset)
-			return roff->name;
-	return NULL;
-}
-
 /*
  * does not yet catch signals sent when the child dies.
  * in exit.c or in signal.c.
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 4e1c6fd..08423b0 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -416,6 +416,48 @@ struct pt_regs_offset {
 	int offset;
 };
 
+extern const struct pt_regs_offset regs_offset_table[];
+
+extern int regs_query_register_offset(const char *name);
+extern const char *regs_query_register_name(unsigned int offset);
+
+/**
+ * regs_within_kernel_stack() - check the address in the stack
+ * @regs:      pt_regs which contains kernel stack pointer.
+ * @addr:      address which is checked.
+ *
+ * regs_within_kernel_stack() checks @addr is within the kernel stack page(s).
+ * If @addr is within the kernel stack, it returns true. If not, returns false.
+ */
+
+static inline bool regs_within_kernel_stack(struct pt_regs *regs,
+						unsigned long addr)
+{
+	return ((addr & ~(THREAD_SIZE - 1))  ==
+		(kernel_stack_pointer(regs) & ~(THREAD_SIZE - 1)));
+}
+
+/**
+ * regs_get_kernel_stack_nth() - get Nth entry of the stack
+ * @regs:	pt_regs which contains kernel stack pointer.
+ * @n:		stack entry number.
+ *
+ * regs_get_kernel_stack_nth() returns @n th entry of the kernel stack which
+ * is specified by @regs. If the @n th entry is NOT in the kernel stack,
+ * this returns 0.
+ */
+static inline unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
+						      unsigned int n)
+{
+	unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
+
+	addr += n;
+	if (regs_within_kernel_stack(regs, (unsigned long)addr))
+		return *addr;
+	else
+		return 0;
+}
+
 #endif	/* CONFIG_HAVE_REGS_AND_STACK_ACCESS_API */
 
 #endif
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 2341efe..f657018 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -1264,3 +1264,41 @@ COMPAT_SYSCALL_DEFINE4(ptrace, compat_long_t, request, compat_long_t, pid,
 	return ret;
 }
 #endif	/* CONFIG_COMPAT */
+
+#ifdef CONFIG_HAVE_REGS_AND_STACK_ACCESS_API
+
+/**
+ * regs_query_register_offset() - query register offset from its name
+ * @name:	the name of a register
+ *
+ * regs_query_register_offset() returns the offset of a register in struct
+ * pt_regs from its name. If the name is invalid, this returns -EINVAL;
+ */
+int regs_query_register_offset(const char *name)
+{
+	const struct pt_regs_offset *roff;
+
+	for (roff = regs_offset_table; roff->name != NULL; roff++)
+		if (!strcmp(roff->name, name))
+			return roff->offset;
+	return -EINVAL;
+}
+
+/**
+ * regs_query_register_name() - query register name from its offset
+ * @offset:	the offset of a register in struct pt_regs.
+ *
+ * regs_query_register_name() returns the name of a register from its
+ * offset in struct pt_regs. If the @offset is invalid, this returns NULL;
+ */
+const char *regs_query_register_name(unsigned int offset)
+{
+	const struct pt_regs_offset *roff;
+
+	for (roff = regs_offset_table; roff->name != NULL; roff++)
+		if (roff->offset == offset)
+			return roff->name;
+	return NULL;
+}
+
+#endif /* CONFIG_HAVE_REGS_AND_STACK_ACCESS_API */
-- 
2.5.0



From wens at csie.org  Mon Feb  8 21:41:37 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue, 9 Feb 2016 13:41:37 +0800
Subject: [PATCH 07/11] ARM: dts: sunxi: Add dtsi file for AXP809 PMIC
In-Reply-To: <20160208162244.GG7265@sirena.org.uk>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-8-git-send-email-wens@csie.org>
 <20160202121733.GO4455@sirena.org.uk>
 <CAGb2v657zYT30KbuK0fyVOmhv0kzJjj9gTsTFRaS4i3d6YhiHQ@mail.gmail.com>
 <20160208145347.GD7265@sirena.org.uk>
 <CAGb2v64ySLAVbPf_XaZnzm5T=SmQLip4iO2p4cGXg=C0=51eqA@mail.gmail.com>
 <20160208162244.GG7265@sirena.org.uk>
Message-ID: <CAGb2v66a=LLMBEbrR2qCzuYp+-fa96qLROFN10+aNvfGTtW-Zg@mail.gmail.com>

On Tue, Feb 9, 2016 at 12:22 AM, Mark Brown <broonie at kernel.org> wrote:
> On Mon, Feb 08, 2016 at 10:56:05PM +0800, Chen-Yu Tsai wrote:
>> On Mon, Feb 8, 2016 at 10:53 PM, Mark Brown <broonie at kernel.org> wrote:
>> > On Sat, Feb 06, 2016 at 08:42:24PM +0800, Chen-Yu Tsai wrote:
>
>> >> Mark, may I assume you are OK with this DTS include listing
>> >> the regulators, even if their sections are empty?
>
>> > If it has no content why have it?
>
>> I'd like the regulator core to disable any unused ones. The core
>> considers regulators that don't have nodes as not having constraints,
>> and won't touch them.
>
>> Any other ways to do this? Or am I going about this the wrong way?
>
> The whole point with constraints is that they describe what is safe on a
> given board.  This includes powering off unused regulators - it should
> be something that the system integrator configures, not something that
> they get as default.

OK. So how should one describe a regulator as unused? Just leave it out
since it's not wired to anything? Or have an empty node at the board
level? One of the regulators involved on my board is by (hardware)
default on.

Thanks
ChenYu


From pmeerw at pmeerw.net  Mon Feb  8 22:43:14 2016
From: pmeerw at pmeerw.net (Peter Meerwald-Stadler)
Date: Tue, 9 Feb 2016 07:43:14 +0100 (CET)
Subject: [PATCH v1 2/2] iio: dac: vf610_dac: Add IIO DAC driver for Vybrid
 SoC
In-Reply-To: <5a699d45c89d239f3e49fa83d16a9b467016e219.1454939346.git.maitysanchayan@gmail.com>
References: <cover.1454939346.git.maitysanchayan@gmail.com>
 <5a699d45c89d239f3e49fa83d16a9b467016e219.1454939346.git.maitysanchayan@gmail.com>
Message-ID: <alpine.DEB.2.02.1602090729130.22963@pmeerw.net>

On Tue, 9 Feb 2016, Sanchayan Maity wrote:

> Add driver support for DAC peripheral on Vybrid SoC.

comments below
 
> Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
> ---
>  .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
>  drivers/iio/dac/Kconfig                            |   8 +
>  drivers/iio/dac/Makefile                           |   1 +
>  drivers/iio/dac/vf610_dac.c                        | 302 +++++++++++++++++++++
>  4 files changed, 331 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>  create mode 100644 drivers/iio/dac/vf610_dac.c
> 
> diff --git a/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
> new file mode 100644
> index 0000000..97d7a40
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
> @@ -0,0 +1,20 @@
> +Freescale vf610 Digital to Analog Converter bindings
> +
> +The devicetree bindings are for the new DAC driver written for
> +vf610 SoCs from Freescale.
> +
> +Required properties:
> +- compatible: Should contain "fsl,vf610-dac"
> +- reg: Offset and length of the register set for the device
> +- interrupts: Should contain the interrupt for the device
> +- clocks: The clock is needed by the DAC controller
> +- clock-names: Must contain "dac", matching entry in the clocks property.

the last sentence is not quite clear; is the comma needed?

> +
> +Example:
> +dac0: dac at 400cc000 {
> +	compatible = "fsl,vf610-dac";
> +	reg = <0x400cc000 0x1000>;
> +	interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
> +	clock-names = "dac";
> +	clocks = <&clks VF610_CLK_DAC0>;
> +};
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index e701e28..8eb0502 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -196,4 +196,12 @@ config MCP4922
>  	  To compile this driver as a module, choose M here: the module
>  	  will be called mcp4922.
>  
> +config VF610_DAC
> +	tristate "Vybrid vf610 DAC driver"
> +	help
> +	  Say yes here to support Vybrid board digital-to-analog converter.
> +
> +	  This driver can also be built as a module. If so, the module will
> +	  be called vf610_dac.
> +
>  endmenu
> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> index 63ae056..93feb27 100644
> --- a/drivers/iio/dac/Makefile
> +++ b/drivers/iio/dac/Makefile
> @@ -21,3 +21,4 @@ obj-$(CONFIG_MAX517) += max517.o
>  obj-$(CONFIG_MAX5821) += max5821.o
>  obj-$(CONFIG_MCP4725) += mcp4725.o
>  obj-$(CONFIG_MCP4922) += mcp4922.o
> +obj-$(CONFIG_VF610_DAC) += vf610_dac.o
> diff --git a/drivers/iio/dac/vf610_dac.c b/drivers/iio/dac/vf610_dac.c
> new file mode 100644
> index 0000000..775b349
> --- /dev/null
> +++ b/drivers/iio/dac/vf610_dac.c
> @@ -0,0 +1,302 @@
> +/*
> + * Freescale Vybrid vf610 DAC driver
> + *
> + * Copyright 2016 Toradex AG
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/slab.h>
> +
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +
> +#define DRIVER_NAME "vf610-dac"

VF610_ prefix

> +
> +#define VF610_DACx_STATCTRL		0x20
> +
> +#define VF610_DAC_DACEN			BIT(15)
> +#define VF610_DAC_DACRFS		BIT(14)
> +#define VF610_DAC_LPEN			BIT(11)
> +
> +#define VF610_DAC_DAT0(x)		((x) & 0xFFF)
> +
> +enum conversion_mode_sel {

vf610_ prefix

> +	VF610_DAC_CONV_HIGH_POWER,
> +	VF610_DAC_CONV_LOW_POWER,
> +};
> +
> +struct vf610_dac {
> +	struct clk *clk;
> +	struct device *dev;
> +	enum conversion_mode_sel conv_mode;
> +	void __iomem *regs;
> +	int irq;
> +};
> +
> +static int vf610_dac_init(struct vf610_dac *info)

should be void, or check the return value

> +{
> +	int val;
> +
> +	info->conv_mode = VF610_DAC_CONV_LOW_POWER;
> +	val = VF610_DAC_DACEN | VF610_DAC_DACRFS |
> +		VF610_DAC_LPEN;
> +	writel(val, info->regs + VF610_DACx_STATCTRL);
> +
> +	return 0;
> +}
> +
> +static int vf610_set_conversion_mode(struct iio_dev *indio_dev,
> +				const struct iio_chan_spec *chan,
> +				unsigned int mode)

mode should be enum conversion_mode_sel?

> +{
> +	struct vf610_dac *info = iio_priv(indio_dev);
> +	int val;
> +
> +	mutex_lock(&indio_dev->mlock);
> +	info->conv_mode = mode;
> +	val = readl(info->regs + VF610_DACx_STATCTRL);
> +	if (mode)
> +		val |= VF610_DAC_LPEN;
> +	else
> +		val &= ~VF610_DAC_LPEN;
> +	writel(val, info->regs + VF610_DACx_STATCTRL);
> +	mutex_unlock(&indio_dev->mlock);
> +
> +	return 0;
> +}
> +
> +static int vf610_get_conversion_mode(struct iio_dev *indio_dev,

return of type enum conversion_mode_sel?

> +				const struct iio_chan_spec *chan)
> +{
> +	struct vf610_dac *info = iio_priv(indio_dev);
> +
> +	return info->conv_mode;
> +}
> +
> +static const char * const vf610_conv_modes[] = { "high-power", "low-power"};

this should be documented in sysfs-bus-iio-vf610; maybe high-power should 
be high-speed

probably this interface should have been exposed as a settable 
conversion rate

> +
> +static const struct iio_enum vf610_conversion_mode = {
> +	.items = vf610_conv_modes,
> +	.num_items = ARRAY_SIZE(vf610_conv_modes),
> +	.get = vf610_get_conversion_mode,
> +	.set = vf610_set_conversion_mode,
> +};
> +
> +static const struct iio_chan_spec_ext_info vf610_ext_info[] = {
> +	IIO_ENUM("conversion_mode", IIO_SHARED_BY_DIR,
> +		&vf610_conversion_mode),
> +	{},
> +};
> +
> +#define VF610_DAC_CHAN(_chan_type) { \
> +	.type = (_chan_type), \
> +	.indexed = -1, \

indexed should be 0 (or not specified) if no indexing is to be used

> +	.output = 1, \
> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> +	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> +	.ext_info = vf610_ext_info, \
> +}
> +
> +static const struct iio_chan_spec vf610_dac_iio_channels[] = {
> +	VF610_DAC_CHAN(IIO_VOLTAGE),
> +};
> +
> +static int vf610_read_raw(struct iio_dev *indio_dev,
> +			struct iio_chan_spec const *chan,
> +			int *val, int *val2,
> +			long mask)
> +{
> +	struct vf610_dac *info = iio_priv(indio_dev);
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		*val = VF610_DAC_DAT0(readl(info->regs));
> +		return IIO_VAL_INT;
> +	case IIO_CHAN_INFO_SCALE:
> +		/*
> +		 * DACRFS is always 1 for valid reference and typical
> +		 * reference voltage as per Vybrid datasheet is 3.3V
> +		 * from section 9.1.2.1 of Vybrid datasheet
> +		 */
> +		*val = 3300 /* mV */;
> +		*val2 = 12;
> +		return IIO_VAL_FRACTIONAL_LOG2;
> +
> +	default:
> +		break;

just return -EINVAL here?
and remove it below below

> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static int vf610_write_raw(struct iio_dev *indio_dev,
> +			struct iio_chan_spec const *chan,
> +			int val, int val2,
> +			long mask)
> +{
> +	struct vf610_dac *info = iio_priv(indio_dev);
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		mutex_lock(&indio_dev->mlock);
> +		writel(VF610_DAC_DAT0(val), info->regs);
> +		mutex_unlock(&indio_dev->mlock);
> +		return 0;
> +
> +	default:
> +		break;

return -EINVAL here should save two lines

> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static const struct iio_info vf610_dac_iio_info = {
> +	.driver_module = THIS_MODULE,
> +	.read_raw = &vf610_read_raw,
> +	.write_raw = &vf610_write_raw,
> +};
> +
> +static const struct of_device_id vf610_dac_match[] = {
> +	{ .compatible = "fsl,vf610-dac", },
> +	{ /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, vf610_dac_match);
> +
> +static int vf610_dac_probe(struct platform_device *pdev)
> +{
> +	struct iio_dev *indio_dev;
> +	struct vf610_dac *info;
> +	struct resource *mem;
> +	int ret;
> +
> +	indio_dev = devm_iio_device_alloc(&pdev->dev,
> +					sizeof(struct vf610_dac));
> +	if (!indio_dev) {
> +		dev_err(&pdev->dev, "Failed allocating iio device\n");
> +		return -ENOMEM;
> +	}
> +
> +	info = iio_priv(indio_dev);
> +	info->dev = &pdev->dev;
> +
> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	info->regs = devm_ioremap_resource(&pdev->dev, mem);
> +	if (IS_ERR(info->regs))
> +		return PTR_ERR(info->regs);
> +
> +	info->clk = devm_clk_get(&pdev->dev, "dac");
> +	if (IS_ERR(info->clk)) {
> +		dev_err(&pdev->dev, "failed getting clock, err = %ld\n",

"Failed getting ..."

> +			PTR_ERR(info->clk));
> +		return PTR_ERR(info->clk);
> +	}
> +
> +	platform_set_drvdata(pdev, indio_dev);
> +
> +	indio_dev->name = dev_name(&pdev->dev);
> +	indio_dev->dev.parent = &pdev->dev;
> +	indio_dev->dev.of_node = pdev->dev.of_node;
> +	indio_dev->info = &vf610_dac_iio_info;
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->channels = vf610_dac_iio_channels;
> +	indio_dev->num_channels = ARRAY_SIZE(vf610_dac_iio_channels);
> +
> +	ret = clk_prepare_enable(info->clk);
> +	if (ret) {
> +		dev_err(&pdev->dev,
> +			"Could not prepare or enable the clock\n");
> +		return ret;
> +	}
> +
> +	ret = iio_device_register(indio_dev);
> +	if (ret) {
> +		dev_err(&pdev->dev, "Couldn't register the device\n");
> +		goto error_iio_device_register;
> +	}
> +
> +	vf610_dac_init(info);

there is a race here, move _dac_init() before _register()
return value is not checked (or use void)

> +
> +	return 0;
> +
> +error_iio_device_register:
> +	clk_disable_unprepare(info->clk);
> +
> +	return ret;
> +}
> +
> +static int vf610_dac_remove(struct platform_device *pdev)
> +{
> +	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> +	struct vf610_dac *info = iio_priv(indio_dev);
> +
> +	iio_device_unregister(indio_dev);
> +	clk_disable_unprepare(info->clk);
> +
> +	return 0;
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int vf610_dac_suspend(struct device *dev)
> +{
> +	struct iio_dev *indio_dev = dev_get_drvdata(dev);
> +	struct vf610_dac *info = iio_priv(indio_dev);
> +	int val;
> +
> +	val = readl(info->regs + VF610_DACx_STATCTRL);
> +	val &= ~VF610_DAC_DACEN;
> +	writel(val, info->regs + VF610_DACx_STATCTRL);
> +
> +	clk_disable_unprepare(info->clk);
> +
> +	return 0;
> +}
> +
> +static int vf610_dac_resume(struct device *dev)
> +{
> +	struct iio_dev *indio_dev = dev_get_drvdata(dev);
> +	struct vf610_dac *info = iio_priv(indio_dev);
> +	int ret;
> +
> +	ret = clk_prepare_enable(info->clk);
> +	if (ret)
> +		return ret;
> +
> +	vf610_dac_init(info);
> +
> +	return 0;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(vf610_dac_pm_ops, vf610_dac_suspend, vf610_dac_resume);
> +
> +static struct platform_driver vf610_dac_driver = {
> +	.probe          = vf610_dac_probe,
> +	.remove         = vf610_dac_remove,
> +	.driver         = {
> +		.name   = DRIVER_NAME,
> +		.of_match_table = vf610_dac_match,
> +		.pm     = &vf610_dac_pm_ops,
> +	},
> +};
> +module_platform_driver(vf610_dac_driver);
> +
> +MODULE_AUTHOR("Sanchayan Maity <sanchayan.maity at toradex.com");
> +MODULE_DESCRIPTION("Freescale VF610 DAC driver");
> +MODULE_LICENSE("GPL v2");
> 

-- 

Peter Meerwald-Stadler
+43-664-2444418 (mobile)


From robert.jarzmik at free.fr  Mon Feb  8 23:20:05 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Tue, 09 Feb 2016 08:20:05 +0100
Subject: [PATCH] dmaengine: pxa_dma: fix the maximum requestor line
In-Reply-To: <20160209033646.GK19598@localhost> (Vinod Koul's message of "Tue, 
 9 Feb 2016 09:06:46 +0530")
References: <1454941131-12308-1-git-send-email-robert.jarzmik@free.fr>
 <20160209033646.GK19598@localhost>
Message-ID: <878u2u2vve.fsf@belgarion.home>

Vinod Koul <vinod.koul at intel.com> writes:

> On Mon, Feb 08, 2016 at 03:18:51PM +0100, Robert Jarzmik wrote:
>> The current number of requestor lines is limited to 31. This was an
>> error of a previous commit, as this number is platform dependent, and is
>> actually :
>>  - for pxa25x: 40 requestor lines
>>  - for pxa27x: 74 requestor lines
>>  - for pxa3xx: 100 requestor lines
>> 
>> As the driver doesn't need to know the exact number, but only an
>
> and why would that be a good assumption?
Well, the driver doesn't use the exact value. Would that be 128, 1000 or 10000,
it wouldn't change its behavior. The clients either pass -1UL (ie. no flow
control) or a requestor line number.

> Btw shouldn't this data come from DT?
It can if you wish, but in this case I must amend the platform data case too, ie
mmp_dma_platdata. And this has an impact on MMP architecture. I'd rather have
the simpler approach unless you really want the exact number of requestor lines
to be passed in platform_data+DT.

Cheers.

-- 
Robert


From geert at linux-m68k.org  Mon Feb  8 23:39:31 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 9 Feb 2016 08:39:31 +0100
Subject: [GIT PULL] Renesas ARM Based SoC DT Updates for v4.6
In-Reply-To: <20160208215130.GJ25468@localhost>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
 <20160208215130.GJ25468@localhost>
Message-ID: <CAMuHMdVWYVEHTvGYEZkEXpEaMzfZ_NfMAb0o8HtVcJM+GDdfmA@mail.gmail.com>

Hi Olof,

On Mon, Feb 8, 2016 at 10:51 PM, Olof Johansson <olof at lixom.net> wrote:
> On Thu, Feb 04, 2016 at 03:30:02PM +0100, Simon Horman wrote:
>> Please consider these Renesas ARM based SoC DT updates for v4.6.
>>
>>
>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>
>>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-for-v4.6
>>
>> for you to fetch changes up to d7a11140d0a659e5c1f83627792f95b6713030a2:
>>
>>   ARM: dts: silk: Enable SCIF_CLK frequency and pins (2016-02-02 14:02:28 +0100)
>>
>> ----------------------------------------------------------------
>> Renesas ARM Based SoC DT Updates for v4.6
>>
>> * Use SCIF and USBHS fallback compatibility strings
>> * Add Baud Rate Generator (BRG) support for (H)SCIF
>> * Enable SCIF_CLK frequency and pins
>> * Use GIC_* defines
>> * Migrate to generic l2c OF initialization on r8a7740
>> * Enable audio on r8a7793/gose
>> * Enable HDMI vidio out on r8a7793
>> * Enable i2c on r8a7793/gose
>> * Enable QSPI on alt
>> * Enable GPIO keys and leds on gise
>> * Enable audio on porter
>> * Enable DU on porter
>>
>> ----------------------------------------------------------------
>> Geert Uytterhoeven (22):
>>       ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization
>>       ARM: shmobile: r8a7740: Remove mapping of L2 cache controller registers
>
> Hmm. Those aren't DT changes. There's also nothing for r8a7740 to convert
> L2 init to DT earlier in this branch, which makes this look like it's just
> a generic cleanup that should go in independently in your cleanup branch.
>
> Or am I missing some dependency that isn't obvious? If I'm not, then please
> respin this branch and move those to the place they belong (cleanup).

The dependency is commit 374e70075e58acfe ("ARM: shmobile: r8a7740 dtsi: Add
L2 cache-controller node"), which has already entered mainline in v4.5-rc1.

So I agree with your comments.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From maxime.ripard at free-electrons.com  Tue Feb  9 00:01:37 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 9 Feb 2016 09:01:37 +0100
Subject: [PATCH 1/6] ARM: sunxi_defconfig: Enable sunxi IR driver
In-Reply-To: <1454774029-10469-2-git-send-email-wens@csie.org>
References: <1454774029-10469-1-git-send-email-wens@csie.org>
 <1454774029-10469-2-git-send-email-wens@csie.org>
Message-ID: <20160209080137.GK31506@lukather>

On Sat, Feb 06, 2016 at 11:53:44PM +0800, Chen-Yu Tsai wrote:
> A consumer IR receiver is commonly found on Allwinner SoC based
> development boards and set top boxes. The driver has been available
> for some time. Enable it by default.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/391a8abe/attachment-0001.sig>

From maxime.ripard at free-electrons.com  Tue Feb  9 00:01:58 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 9 Feb 2016 09:01:58 +0100
Subject: [PATCH 2/6] ARM: sunxi_defconfig: Enable A10 audio codec driver
In-Reply-To: <1454774029-10469-3-git-send-email-wens@csie.org>
References: <1454774029-10469-1-git-send-email-wens@csie.org>
 <1454774029-10469-3-git-send-email-wens@csie.org>
Message-ID: <20160209080158.GL31506@lukather>

On Sat, Feb 06, 2016 at 11:53:45PM +0800, Chen-Yu Tsai wrote:
> The A10 audio codec driver supports the on-chip audio codec found on
> Allwinner A10, A10s, A13, A20 SoCs.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/84ff6d50/attachment.sig>

From maxime.ripard at free-electrons.com  Tue Feb  9 00:02:27 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 9 Feb 2016 09:02:27 +0100
Subject: [PATCH 4/6] ARM: sunxi_defconfig: Enable INPUT_EVDEV so
 axp20x-pek can be used
In-Reply-To: <1454774029-10469-5-git-send-email-wens@csie.org>
References: <1454774029-10469-1-git-send-email-wens@csie.org>
 <1454774029-10469-5-git-send-email-wens@csie.org>
Message-ID: <20160209080227.GM31506@lukather>

On Sat, Feb 06, 2016 at 11:53:47PM +0800, Chen-Yu Tsai wrote:
> sunxi_defconfig already enables INPUT_AXP20X_PEK, but the device is not
> exposed to userspace. Enable INPUT_EVDEV so it is.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/fd736a3d/attachment.sig>

From lkp at intel.com  Tue Feb  9 00:01:24 2016
From: lkp at intel.com (kbuild test robot)
Date: Tue, 9 Feb 2016 16:01:24 +0800
Subject: [PATCH 14/14] clk: qcom: Migrate to clk_hw based registration
 and OF APIs
In-Reply-To: <1454982341-22715-15-git-send-email-sboyd@codeaurora.org>
Message-ID: <201602091500.56m6YCnX%fengguang.wu@intel.com>

Hi Stephen,

[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.5-rc3]
[cannot apply to clk/clk-next next-20160208]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Stephen-Boyd/clk_hw-based-clkdev-DT-providers/20160209-095211
base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: x86_64-allmodconfig (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "of_clk_add_hw_provider" [drivers/clk/qcom/clk-qcom.ko] undefined!

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 52114 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/66c7eadc/attachment-0001.obj>

From maxime.ripard at free-electrons.com  Tue Feb  9 00:14:20 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 9 Feb 2016 09:14:20 +0100
Subject: [PATCH 6/6] ARM: multi_v7_defconfig: Enable MUSB HDRC driver
 with Allwinner glue
In-Reply-To: <1454774029-10469-7-git-send-email-wens@csie.org>
References: <1454774029-10469-1-git-send-email-wens@csie.org>
 <1454774029-10469-7-git-send-email-wens@csie.org>
Message-ID: <20160209081420.GN31506@lukather>

On Sat, Feb 06, 2016 at 11:53:49PM +0800, Chen-Yu Tsai wrote:
> Allwinner SoCs typically have a Mentor Graphics Inventra MUSB high speed
> dual role controller for USB OTG.
> 
> Now that the issue with MUSB and USB gadget registration order has been
> resolved, we can enable this driver in dual role mode.
> 
> This patch only enables the driver core and Allwinner platform support.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/c34a9ec8/attachment.sig>

From maxime.ripard at free-electrons.com  Tue Feb  9 00:14:41 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 9 Feb 2016 09:14:41 +0100
Subject: [PATCH 5/6] ARM: multi_v7_defconfig: Enable A10 audio codec
 driver as module
In-Reply-To: <1454774029-10469-6-git-send-email-wens@csie.org>
References: <1454774029-10469-1-git-send-email-wens@csie.org>
 <1454774029-10469-6-git-send-email-wens@csie.org>
Message-ID: <20160209081441.GO31506@lukather>

On Sat, Feb 06, 2016 at 11:53:48PM +0800, Chen-Yu Tsai wrote:
> The A10 audio codec driver supports the on-chip audio codec found on
> Allwinner A10, A10s, A13, A20 SoCs.
> 
> Build it as a module, since it is not critical.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/838b56a1/attachment.sig>

From dirk.behme at de.bosch.com  Tue Feb  9 00:14:52 2016
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Tue, 9 Feb 2016 09:14:52 +0100
Subject: [PATCH] arm64: dts: r8a7795: Add GIC-400 virtual interfaces
Message-ID: <1455005692-9382-1-git-send-email-dirk.behme@de.bosch.com>

Besides the distributor and the CPU interface the GIC-400 additionally
supports the virtual interface control blocks and the virtual CPU interfaces.

Add the physical base addresses and size for these.

See

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0471b/index.html
-> 3.2. GIC-400 register map

and Linux kernel's

Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt

for more details.

Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 8f1ed23..0163967 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -130,7 +130,9 @@
 			#address-cells = <0>;
 			interrupt-controller;
 			reg = <0x0 0xf1010000 0 0x1000>,
-			      <0x0 0xf1020000 0 0x2000>;
+			      <0x0 0xf1020000 0 0x2000>,
+			      <0x0 0xf1040000 0 0x2000>,
+			      <0x0 0xf1060000 0 0x2000>;
 			interrupts = <GIC_PPI 9
 					(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
 		};
-- 
2.5.1



From maxime.ripard at free-electrons.com  Tue Feb  9 00:15:29 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 9 Feb 2016 09:15:29 +0100
Subject: [PATCH 3/6] ARM: sunxi_defconfig: Enable MUSB HDRC driver with
 Allwinner glue
In-Reply-To: <1454774029-10469-4-git-send-email-wens@csie.org>
References: <1454774029-10469-1-git-send-email-wens@csie.org>
 <1454774029-10469-4-git-send-email-wens@csie.org>
Message-ID: <20160209081529.GP31506@lukather>

Hi,

On Sat, Feb 06, 2016 at 11:53:46PM +0800, Chen-Yu Tsai wrote:
> Allwinner SoCs typically have a Mentor Graphics Inventra MUSB dual role
> controller for USB OTG.
> 
> Now that the issue with MUSB and USB gadget registration order has been
> resolved, we can enable this driver in dual role mode. This requires the
> NOP USB transceiver driver, which is also enabled.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
> ---
>  arch/arm/configs/sunxi_defconfig | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
> index efa12c88fe1c..e29b81694184 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -109,6 +109,11 @@ CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_EHCI_HCD_PLATFORM=y
>  CONFIG_USB_OHCI_HCD=y
>  CONFIG_USB_OHCI_HCD_PLATFORM=y
> +CONFIG_USB_MUSB_HDRC=y
> +CONFIG_USB_MUSB_SUNXI=y
> +CONFIG_NOP_USB_XCEIV=y
> +CONFIG_USB_GADGET=y
> +CONFIG_USB_CDC_COMPOSITE=y

I'd prefer not to have any default gadget here, just like you did on
multi_v7.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/031ab3a0/attachment.sig>

From wens at csie.org  Tue Feb  9 00:26:34 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue, 9 Feb 2016 16:26:34 +0800
Subject: [PATCH 3/6] ARM: sunxi_defconfig: Enable MUSB HDRC driver with
 Allwinner glue
In-Reply-To: <20160209081529.GP31506@lukather>
References: <1454774029-10469-1-git-send-email-wens@csie.org>
 <1454774029-10469-4-git-send-email-wens@csie.org>
 <20160209081529.GP31506@lukather>
Message-ID: <CAGb2v65bsQ9etypAH=v-pYBLtSvzLbpxKsJ2=YMJR9dahqNjbA@mail.gmail.com>

On Tue, Feb 9, 2016 at 4:15 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> Hi,
>
> On Sat, Feb 06, 2016 at 11:53:46PM +0800, Chen-Yu Tsai wrote:
>> Allwinner SoCs typically have a Mentor Graphics Inventra MUSB dual role
>> controller for USB OTG.
>>
>> Now that the issue with MUSB and USB gadget registration order has been
>> resolved, we can enable this driver in dual role mode. This requires the
>> NOP USB transceiver driver, which is also enabled.
>>
>> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
>> ---
>>  arch/arm/configs/sunxi_defconfig | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
>> index efa12c88fe1c..e29b81694184 100644
>> --- a/arch/arm/configs/sunxi_defconfig
>> +++ b/arch/arm/configs/sunxi_defconfig
>> @@ -109,6 +109,11 @@ CONFIG_USB_EHCI_HCD=y
>>  CONFIG_USB_EHCI_HCD_PLATFORM=y
>>  CONFIG_USB_OHCI_HCD=y
>>  CONFIG_USB_OHCI_HCD_PLATFORM=y
>> +CONFIG_USB_MUSB_HDRC=y
>> +CONFIG_USB_MUSB_SUNXI=y
>> +CONFIG_NOP_USB_XCEIV=y
>> +CONFIG_USB_GADGET=y
>> +CONFIG_USB_CDC_COMPOSITE=y
>
> I'd prefer not to have any default gadget here, just like you did on
> multi_v7.

FYI the default here (in Kconfig) would be CONFIG_USB_ETH
"Ethernet Gadget (with CDC Ethernet support)".

CDC_COMPOSITE (CDC Ethernet + serial) is somewhat more useful.
But I'll change it.

ChenYu


From heiko at sntech.de  Tue Feb  9 00:30:02 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 09 Feb 2016 09:30:02 +0100
Subject: [PATCH v4 09/10] arm64: dts: Add main Thermal info to rk3368.dtsi
In-Reply-To: <1447044542-30859-10-git-send-email-wxt@rock-chips.com>
References: <1447044542-30859-1-git-send-email-wxt@rock-chips.com>
 <1447044542-30859-10-git-send-email-wxt@rock-chips.com>
Message-ID: <42802946.20XC68fnyM@phil>

Hi Caesar,

Am Montag, 9. November 2015, 12:49:01 schrieb Caesar Wang:
> This patch add the thermal needed info on RK3368.
> Meanwhile, support the trips to throttle for thermal.
> 
> Signed-off-by: Caesar Wang <wxt at rock-chips.com>
> Acked-by: Eduardo Valentin <edubezval at gmail.com>

[...]

> @@ -829,6 +855,16 @@
>  			};
>  		};
> 
> +		tsadc {
> +			otp_gpio: otp-gpio {
> +				rockchip,pins = <0 10 RK_FUNC_GPIO &pcfg_pull_none>;
> +			};
> +
> +			otp_out: otp-out {
> +				rockchip,pins = <0 10 RK_FUNC_1 &pcfg_pull_none>;
> +			};
> +		};
> +
>  		uart0 {
>  			uart0_xfer: uart0-xfer {
>  				rockchip,pins = <2 24 RK_FUNC_1 &pcfg_pull_up>,

As it came up just now, these pinctrl settings seem strange. I.e. according 
to the TRM gpio0b2 [= gpio0 10] func_1 is sc_rst, which seems to be the 
smartcard controller?

It came up because it seems the Tronsmart R68 board seems to use this pin 
for controlling the vcc_host regulator instead.


Heiko


From paul at pwsan.com  Tue Feb  9 00:49:13 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 9 Feb 2016 08:49:13 +0000 (UTC)
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <56B900E9.9040306@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
Message-ID: <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>

On Mon, 8 Feb 2016, Suman Anna wrote:

> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
> > On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:
> > 
> >> Paul, what do you think is the best way forward to perform reset?
> > 
> > Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
> > Those often need special reset handling to ensure that WFI/HLT-like 
> > instructions are executed after reset.  This special handling ensures that 
> > the IP blocks' bus initiator interfaces indicate that they are in standby 
> > to the PRCM - thus allowing power management for the rest of the chip to 
> > work correctly.
> > 
> > But that doesn't seem to be the case with PCIe - and maybe others - 
> > possibly some of the MMUs?  
> 
> Yeah, the sequencing between clocks and resets would still be the same
> for MMUs, so, adding the custom flags for MMUs is fine.

I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs.  
We've stated that the main point of the custom hardreset code is to handle 
processors that need to be placed into WFI/HLT, but it doesn't seem like 
there would be an equivalent for MMUs.  Thoughts?


- Paul


From antoine.tenart at free-electrons.com  Tue Feb  9 00:56:33 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Tue, 9 Feb 2016 09:56:33 +0100
Subject: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <56B8B45D.1020902@arm.com>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
 <56B8B45D.1020902@arm.com>
Message-ID: <20160209085633.GA5388@kwain>

Hi Marc,

On Mon, Feb 08, 2016 at 03:29:33PM +0000, Marc Zyngier wrote:
> On 08/02/16 09:11, Antoine Tenart wrote:
> 
> > +		gic: gic at f0100000 {
> > +			compatible = "arm,gic-v3";
> > +			reg = <0x0 0xf0200000 0x0 0x10000>,	/* GIC Dist */
> > +			      <0x0 0xf0280000 0x0 0x200000>,	/* GICR */
> > +			      <0x0 0xf0100000 0x0 0x2000>;	/* GICC */
> > +			interrupt-controller;
> > +			#interrupt-cells = <3>;
> > +		};
> 
> Something is wrong here. Either you are missing GICH and GICV (assuming
> you have legacy support), or you have an extra GICC region (which
> doesn't make sense on its own).
> 
> You're also missing the maintenance interrupt.
> 
> Has Anapurna really built a GICv3 without an ITS?

I documented myself and Annapurna's GIC really doesn't have an ITS.

I'll add the missing regions.

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/61618e8e/attachment.sig>

From raveendra.padasalagi at broadcom.com  Tue Feb  9 00:57:54 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Tue,  9 Feb 2016 14:27:54 +0530
Subject: [PATCH 0/3] Syscon support for iProc touchscreen driver
Message-ID: <1455008277-8312-1-git-send-email-raveendra.padasalagi@broadcom.com>

This patchset is based on v4.5-rc3 tag and its tested on
Broadcom Cygnus SoC.

The patches can be fetched from iproc-tsc-v1 branch of
https://github.com/Broadcom/arm64-linux.git

Raveendra Padasalagi (3):
  input: cygnus-update touchscreen dt node document
  input: syscon support in bcm_iproc_tsc driver
  ARM: dts: use syscon in cygnus touchscreen dt node

 .../input/touchscreen/brcm,iproc-touchscreen.txt   |  18 ++-
 arch/arm/boot/dts/bcm-cygnus.dtsi                  |   9 +-
 drivers/input/touchscreen/bcm_iproc_tsc.c          | 122 +++++++++++++++------
 3 files changed, 112 insertions(+), 37 deletions(-)

-- 
1.9.1



From raveendra.padasalagi at broadcom.com  Tue Feb  9 00:57:55 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Tue,  9 Feb 2016 14:27:55 +0530
Subject: [PATCH 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <1455008277-8312-1-git-send-email-raveendra.padasalagi@broadcom.com>
References: <1455008277-8312-1-git-send-email-raveendra.padasalagi@broadcom.com>
Message-ID: <1455008277-8312-2-git-send-email-raveendra.padasalagi@broadcom.com>

Touch screen driver is modified to use syscon framework
based register read/write API's. So added syscon node and
related changes in dt file.Updating the device tree documentation
file to reflect the changes.

Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi at broadcom.com>
Reviewed-by: Ray Jui <ray.jui at broadcom.com>
Reviewed-by: Scott Branden <scott.branden at broadcom.com>
---
 .../input/touchscreen/brcm,iproc-touchscreen.txt       | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
index 34e3382..67599ae 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
@@ -2,8 +2,16 @@
 
 Required properties:
 - compatible: must be "brcm,iproc-touchscreen"
-- reg: physical base address of the controller and length of memory mapped
-  region.
+
+One of the below 2 property is mandatory.
+- ts_syscon: handler of syscon node defining physical base address
+  of the controller and length of memory mapped region.
+  If this property is selected please make sure MFD_SYSCON config
+  is enabled in the defconfig file.
+or
+- reg: physical base address of the controller and length of memory
+  mapped region.
+
 - clocks:  The clock provided by the SOC to driver the tsc
 - clock-name:  name for the clock
 - interrupts: The touchscreen controller's interrupt
@@ -54,12 +62,16 @@ Optional properties:
 - touchscreen-inverted-y: Y axis is inverted (boolean)
 
 Example:
+	ts_adc_syscon: ts_adc_syscon at 0x180a6000 {
+		compatible = "syscon";
+		reg = <0x180a6000 0xc30>;
+	};
 
 	touchscreen: tsc at 0x180A6000 {
 		compatible = "brcm,iproc-touchscreen";
 		#address-cells = <1>;
 		#size-cells = <1>;
-		reg = <0x180A6000 0x40>;
+		syscon = <&ts_adc_syscon>;
 		clocks = <&adc_clk>;
 		clock-names = "tsc_clk";
 		interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
-- 
1.9.1



From raveendra.padasalagi at broadcom.com  Tue Feb  9 00:57:57 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Tue,  9 Feb 2016 14:27:57 +0530
Subject: [PATCH 3/3] ARM: dts: use syscon in cygnus touchscreen dt node
In-Reply-To: <1455008277-8312-1-git-send-email-raveendra.padasalagi@broadcom.com>
References: <1455008277-8312-1-git-send-email-raveendra.padasalagi@broadcom.com>
Message-ID: <1455008277-8312-4-git-send-email-raveendra.padasalagi@broadcom.com>

In cygnus touch screen controller registers are shared with ADC
and flex timer. Using readl/writel could lead to race condition.
In such cases we need to support register access using syscon
framework based API's. So Added dt changes to use syscon.

Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi at broadcom.com>
Reviewed-by: Ray Jui <ray.jui at broadcom.com>
Reviewed-by: Scott Branden <scott.branden at broadcom.com>
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 3878793..9190224 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -351,9 +351,16 @@
 					<&pinctrl 142 10 1>;
 		};
 
+		ts_adc_syscon: ts_adc_syscon at 0x180a6000 {
+			compatible = "syscon";
+			reg = <0x180a6000 0xc30>;
+		};
+
 		touchscreen: tsc at 180a6000 {
 			compatible = "brcm,iproc-touchscreen";
-			reg = <0x180a6000 0x40>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ts_syscon = <&ts_adc_syscon>;
 			clocks = <&asiu_clks BCM_CYGNUS_ASIU_ADC_CLK>;
 			clock-names = "tsc_clk";
 			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
-- 
1.9.1



From raveendra.padasalagi at broadcom.com  Tue Feb  9 00:57:56 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Tue,  9 Feb 2016 14:27:56 +0530
Subject: [PATCH 2/3] input: syscon support in bcm_iproc_tsc driver
In-Reply-To: <1455008277-8312-1-git-send-email-raveendra.padasalagi@broadcom.com>
References: <1455008277-8312-1-git-send-email-raveendra.padasalagi@broadcom.com>
Message-ID: <1455008277-8312-3-git-send-email-raveendra.padasalagi@broadcom.com>

Touch screen controller registers are shared with ADC and flex timer.
Using readl/writel could lead to race condition. So in such cases
we need to support register access using syscon framework based API's.

In the platform's where touchscreen register's are not shared normal
readl/writel could be used.

Based on the dt entry "reg" or "ts_syscon" register accesses are handled.
if "reg" is provided normal readl/writel API's are used to access
register's else if "ts_syscon" is provided then syscon API's are used.

Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi at broadcom.com>
Reviewed-by: Ray Jui <ray.jui at broadcom.com>
Reviewed-by: Scott Branden <scott.branden at broadcom.com>
---
 drivers/input/touchscreen/bcm_iproc_tsc.c | 122 ++++++++++++++++++++++--------
 1 file changed, 89 insertions(+), 33 deletions(-)

diff --git a/drivers/input/touchscreen/bcm_iproc_tsc.c b/drivers/input/touchscreen/bcm_iproc_tsc.c
index ae460a5c..56c7c08 100644
--- a/drivers/input/touchscreen/bcm_iproc_tsc.c
+++ b/drivers/input/touchscreen/bcm_iproc_tsc.c
@@ -23,6 +23,8 @@
 #include <linux/io.h>
 #include <linux/clk.h>
 #include <linux/serio.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
 
 #define IPROC_TS_NAME "iproc-ts"
 
@@ -88,7 +90,7 @@
 #define TS_WIRE_MODE_BIT        BIT(1)
 
 #define dbg_reg(dev, priv, reg) \
-	dev_dbg(dev, "%20s= 0x%08x\n", #reg, readl((priv)->regs + reg))
+	dev_dbg(dev, "%20s= 0x%08x\n", #reg, iproc_reg_read(priv, reg))
 
 struct tsc_param {
 	/* Each step is 1024 us.  Valid 1-256 */
@@ -142,6 +144,7 @@ struct iproc_ts_priv {
 	struct input_dev *idev;
 
 	void __iomem *regs;
+	struct regmap *regmap;
 	struct clk *tsc_clk;
 
 	int  pen_status;
@@ -163,6 +166,41 @@ static const struct tsc_param iproc_default_config = {
 	.max_y            = Y_MAX,
 };
 
+static int iproc_reg_update_bits(struct iproc_ts_priv *priv, u32 reg,
+			   u32 mask, u32 val)
+{
+	int ret = 0;
+	u32 tmp, orig;
+
+	if (priv->regs) {
+		orig = readl(priv->regs);
+		tmp = orig & ~mask;
+		tmp |= val & mask;
+		writel(tmp, priv->regs + reg);
+	} else
+		ret = regmap_update_bits(priv->regmap, reg, mask, val);
+	return ret;
+}
+
+static void iproc_reg_write(struct iproc_ts_priv *priv, u32 reg, u32 val)
+{
+	if (priv->regs)
+		writel(val, priv->regs + reg);
+	else
+		regmap_write(priv->regmap, reg, val);
+}
+
+static u32 iproc_reg_read(struct iproc_ts_priv *priv, u32 reg)
+{
+	u32 val;
+
+	if (priv->regs)
+		val = readl(priv->regs + reg);
+	else
+		regmap_read(priv->regmap, reg, &val);
+	return val;
+}
+
 static void ts_reg_dump(struct iproc_ts_priv *priv)
 {
 	struct device *dev = &priv->pdev->dev;
@@ -196,22 +234,22 @@ static irqreturn_t iproc_touchscreen_interrupt(int irq, void *data)
 	int i;
 	bool needs_sync = false;
 
-	intr_status = readl(priv->regs + INTERRUPT_STATUS);
-	intr_status &= TS_PEN_INTR_MASK | TS_FIFO_INTR_MASK;
+	intr_status = iproc_reg_read(priv, INTERRUPT_STATUS);
+	intr_status &= (TS_PEN_INTR_MASK | TS_FIFO_INTR_MASK);
 	if (intr_status == 0)
 		return IRQ_NONE;
 
 	/* Clear all interrupt status bits, write-1-clear */
-	writel(intr_status, priv->regs + INTERRUPT_STATUS);
-
+	iproc_reg_write(priv, INTERRUPT_STATUS, intr_status);
 	/* Pen up/down */
 	if (intr_status & TS_PEN_INTR_MASK) {
-		if (readl(priv->regs + CONTROLLER_STATUS) & TS_PEN_DOWN)
+		priv->pen_status = iproc_reg_read(priv, CONTROLLER_STATUS);
+		if (priv->pen_status & TS_PEN_DOWN)
 			priv->pen_status = PEN_DOWN_STATUS;
 		else
 			priv->pen_status = PEN_UP_STATUS;
 
-		input_report_key(priv->idev, BTN_TOUCH, priv->pen_status);
+		input_report_key(priv->idev, BTN_TOUCH,	priv->pen_status);
 		needs_sync = true;
 
 		dev_dbg(&priv->pdev->dev,
@@ -221,7 +259,7 @@ static irqreturn_t iproc_touchscreen_interrupt(int irq, void *data)
 	/* coordinates in FIFO exceed the theshold */
 	if (intr_status & TS_FIFO_INTR_MASK) {
 		for (i = 0; i < priv->cfg_params.fifo_threshold; i++) {
-			raw_coordinate = readl(priv->regs + FIFO_DATA);
+			raw_coordinate = iproc_reg_read(priv, FIFO_DATA);
 			if (raw_coordinate == INVALID_COORD)
 				continue;
 
@@ -239,7 +277,7 @@ static irqreturn_t iproc_touchscreen_interrupt(int irq, void *data)
 			x = (x >> 4) & 0x0FFF;
 			y = (y >> 4) & 0x0FFF;
 
-			/* adjust x y according to lcd tsc mount angle */
+			/* Adjust x y according to LCD tsc mount angle. */
 			if (priv->cfg_params.invert_x)
 				x = priv->cfg_params.max_x - x;
 
@@ -262,9 +300,10 @@ static irqreturn_t iproc_touchscreen_interrupt(int irq, void *data)
 
 static int iproc_ts_start(struct input_dev *idev)
 {
-	struct iproc_ts_priv *priv = input_get_drvdata(idev);
 	u32 val;
+	u32 mask;
 	int error;
+	struct iproc_ts_priv *priv = input_get_drvdata(idev);
 
 	/* Enable clock */
 	error = clk_prepare_enable(priv->tsc_clk);
@@ -279,9 +318,10 @@ static int iproc_ts_start(struct input_dev *idev)
 	 *  FIFO reaches the int_th value, and pen event(up/down)
 	 */
 	val = TS_PEN_INTR_MASK | TS_FIFO_INTR_MASK;
-	writel(val, priv->regs + INTERRUPT_MASK);
+	iproc_reg_update_bits(priv, INTERRUPT_MASK, val, val);
 
-	writel(priv->cfg_params.fifo_threshold, priv->regs + INTERRUPT_THRES);
+	val = priv->cfg_params.fifo_threshold;
+	iproc_reg_write(priv, INTERRUPT_THRES, val);
 
 	/* Initialize control reg1 */
 	val = 0;
@@ -289,26 +329,23 @@ static int iproc_ts_start(struct input_dev *idev)
 	val |= priv->cfg_params.debounce_timeout << DEBOUNCE_TIMEOUT_SHIFT;
 	val |= priv->cfg_params.settling_timeout << SETTLING_TIMEOUT_SHIFT;
 	val |= priv->cfg_params.touch_timeout << TOUCH_TIMEOUT_SHIFT;
-	writel(val, priv->regs + REGCTL1);
+	iproc_reg_write(priv, REGCTL1, val);
 
 	/* Try to clear all interrupt status */
-	val = readl(priv->regs + INTERRUPT_STATUS);
-	val |= TS_FIFO_INTR_MASK | TS_PEN_INTR_MASK;
-	writel(val, priv->regs + INTERRUPT_STATUS);
+	val = TS_FIFO_INTR_MASK | TS_PEN_INTR_MASK;
+	iproc_reg_update_bits(priv, INTERRUPT_STATUS, val, val);
 
 	/* Initialize control reg2 */
-	val = readl(priv->regs + REGCTL2);
-	val |= TS_CONTROLLER_EN_BIT | TS_WIRE_MODE_BIT;
-
-	val &= ~TS_CONTROLLER_AVGDATA_MASK;
+	val = TS_CONTROLLER_EN_BIT | TS_WIRE_MODE_BIT;
 	val |= priv->cfg_params.average_data << TS_CONTROLLER_AVGDATA_SHIFT;
 
-	val &= ~(TS_CONTROLLER_PWR_LDO |	/* PWR up LDO */
+	mask = (TS_CONTROLLER_AVGDATA_MASK);
+	mask |= (TS_CONTROLLER_PWR_LDO |	/* PWR up LDO */
 		   TS_CONTROLLER_PWR_ADC |	/* PWR up ADC */
 		   TS_CONTROLLER_PWR_BGP |	/* PWR up BGP */
 		   TS_CONTROLLER_PWR_TS);	/* PWR up TS */
-
-	writel(val, priv->regs + REGCTL2);
+	mask |= val;
+	iproc_reg_update_bits(priv, REGCTL2, mask, val);
 
 	ts_reg_dump(priv);
 
@@ -320,12 +357,17 @@ static void iproc_ts_stop(struct input_dev *dev)
 	u32 val;
 	struct iproc_ts_priv *priv = input_get_drvdata(dev);
 
-	writel(0, priv->regs + INTERRUPT_MASK); /* Disable all interrupts */
+	/*
+	 * Disable FIFO int_th and pen event(up/down)Interrupts only
+	 * as the interrupt mask register is shared between ADC, TS and
+	 * flextimer.
+	 */
+	val = TS_PEN_INTR_MASK | TS_FIFO_INTR_MASK;
+	iproc_reg_update_bits(priv, INTERRUPT_MASK, val, 0);
 
 	/* Only power down touch screen controller */
-	val = readl(priv->regs + REGCTL2);
-	val |= TS_CONTROLLER_PWR_TS;
-	writel(val, priv->regs + REGCTL2);
+	val = TS_CONTROLLER_PWR_TS;
+	iproc_reg_update_bits(priv, REGCTL2, val, val);
 
 	clk_disable(priv->tsc_clk);
 }
@@ -422,13 +464,27 @@ static int iproc_ts_probe(struct platform_device *pdev)
 	if (!priv)
 		return -ENOMEM;
 
-	/* touchscreen controller memory mapped regs */
+	/* touchscreen controller memory mapped regs if provided */
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	priv->regs = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(priv->regs)) {
-		error = PTR_ERR(priv->regs);
-		dev_err(&pdev->dev, "unable to map I/O memory: %d\n", error);
-		return error;
+	if (res) {
+		priv->regs = devm_ioremap_resource(&pdev->dev, res);
+		if (IS_ERR(priv->regs)) {
+			error = PTR_ERR(priv->regs);
+			dev_err(&pdev->dev, "unable to map I/O memory:%d\n",
+				error);
+			return error;
+		}
+	} else {
+		/* touchscreen controller memory mapped regs */
+		priv->regmap = syscon_regmap_lookup_by_phandle(
+							pdev->dev.of_node,
+							"ts_syscon");
+		if (IS_ERR(priv->regmap)) {
+			error = PTR_ERR(priv->regs);
+			dev_err(&pdev->dev, "unable to map I/O memory:%d\n",
+				error);
+			return error;
+		}
 	}
 
 	priv->tsc_clk = devm_clk_get(&pdev->dev, "tsc_clk");
-- 
1.9.1



From u.kleine-koenig at pengutronix.de  Tue Feb  9 01:00:30 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Tue, 9 Feb 2016 10:00:30 +0100
Subject: [PATCH] ARM: ks8695: fix __initdata annotation
In-Reply-To: <1454941509-2773774-1-git-send-email-arnd@arndb.de>
References: <1454941509-2773774-1-git-send-email-arnd@arndb.de>
Message-ID: <20160209090030.GS13664@pengutronix.de>

On Mon, Feb 08, 2016 at 03:24:57PM +0100, Arnd Bergmann wrote:
> Clang complains about the __initdata section attribute being in the
> wrong place in two files of ks8695:
> 
> arch/arm/mach-ks8695/cpu.c:37:31: error: '__section__' attribute only applies to functions and global variables
> arch/arm/mach-ks8695/board-og.c:83:31: error: '__section__' attribute only applies to functions and global variables
> 
> This moves the attribute to the correct place.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/mach-ks8695/board-og.c | 2 +-
>  arch/arm/mach-ks8695/cpu.c      | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-ks8695/board-og.c b/arch/arm/mach-ks8695/board-og.c
> index 1f4f2f4f25bb..fa1a7c2ca2bb 100644
> --- a/arch/arm/mach-ks8695/board-og.c
> +++ b/arch/arm/mach-ks8695/board-og.c
> @@ -80,7 +80,7 @@ static void __init og_pci_bus_reset(void)
>  #define	S8250_VIRT	0xf4000000
>  #define	S8250_SIZE	0x00100000
>  
> -static struct __initdata map_desc og_io_desc[] = {
> +static struct map_desc __initdata og_io_desc[] = {

I would have expected that

+static struct map_desc og_io_desc[] __initdata = {

is the correct variant?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From antoine.tenart at free-electrons.com  Tue Feb  9 01:01:31 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Tue, 9 Feb 2016 10:01:31 +0100
Subject: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <20160209085633.GA5388@kwain>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
 <56B8B45D.1020902@arm.com> <20160209085633.GA5388@kwain>
Message-ID: <20160209090131.GB5388@kwain>

On Tue, Feb 09, 2016 at 09:56:33AM +0100, Antoine Tenart wrote:
> Hi Marc,
> 
> On Mon, Feb 08, 2016 at 03:29:33PM +0000, Marc Zyngier wrote:
> > On 08/02/16 09:11, Antoine Tenart wrote:
> > 
> > > +		gic: gic at f0100000 {
> > > +			compatible = "arm,gic-v3";
> > > +			reg = <0x0 0xf0200000 0x0 0x10000>,	/* GIC Dist */
> > > +			      <0x0 0xf0280000 0x0 0x200000>,	/* GICR */
> > > +			      <0x0 0xf0100000 0x0 0x2000>;	/* GICC */
> > > +			interrupt-controller;
> > > +			#interrupt-cells = <3>;
> > > +		};
> > 
> > Something is wrong here. Either you are missing GICH and GICV (assuming
> > you have legacy support), or you have an extra GICC region (which
> > doesn't make sense on its own).
> 
> I'll add the missing regions.

Hmm, in fact the GICC region shouldn't be there. I'll make some tests
and remove it.

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/e4c102f6/attachment.sig>

From bigeasy at linutronix.de  Tue Feb  9 01:02:19 2016
From: bigeasy at linutronix.de (Sebastian Andrzej Siewior)
Date: Tue, 9 Feb 2016 10:02:19 +0100
Subject: [PATCH] arm64: replace read_lock to rcu lock in call_step_hook
In-Reply-To: <1454971764-30720-1-git-send-email-yang.shi@linaro.org>
References: <1454971764-30720-1-git-send-email-yang.shi@linaro.org>
Message-ID: <20160209090219.GA13035@linutronix.de>

* Yang Shi | 2016-02-08 14:49:24 [-0800]:

>BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
?
>This issue is similar with 62c6c61("arm64: replace read_lock to rcu lock in
>call_break_hook"), but comes to single_step_handler.
>
>This also solves kgdbts boot test silent hang issue on 4.4 -rt kernel.

I am going to apply this for -RT.

Sebastian


From kishon at ti.com  Tue Feb  9 01:05:43 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 9 Feb 2016 14:35:43 +0530
Subject: [PATCH v2] ARM: DRA7: hwmod: Fix OCP2SCP sysconfig
Message-ID: <1455008743-21660-1-git-send-email-kishon@ti.com>

OCP2SCP doesn't support smart idle wakeup according to
Table 26-22. OCP2SCP_SYSCONFIG in AM572x TRM [1] and
Table 26-22. OCP2SCP_SYSCONFIG in AM571x TRM [2].
Remove SIDLE_SMART_WKUP from the list of supported SIDLE modes
in hwmod data.

[1] -> http://www.ti.com/lit/ug/spruhz6e/spruhz6e.pdf
[2] -> http://www.ti.com/lit/ug/spruhz7a/spruhz7a.pdf

Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
---
Changes from v1:
*) Updated commit log to use public TRM links.

 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 848356e..84c2699 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1482,8 +1482,7 @@ static struct omap_hwmod_class_sysconfig dra7xx_ocp2scp_sysc = {
 	.syss_offs	= 0x0014,
 	.sysc_flags	= (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
 			   SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
-	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
-			   SIDLE_SMART_WKUP),
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
 	.sysc_fields	= &omap_hwmod_sysc_type1,
 };
 
-- 
1.7.9.5



From marc.zyngier at arm.com  Tue Feb  9 01:09:54 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 9 Feb 2016 09:09:54 +0000
Subject: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <20160209090131.GB5388@kwain>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
 <56B8B45D.1020902@arm.com> <20160209085633.GA5388@kwain>
 <20160209090131.GB5388@kwain>
Message-ID: <56B9ACE2.1060200@arm.com>

On 09/02/16 09:01, Antoine Tenart wrote:
> On Tue, Feb 09, 2016 at 09:56:33AM +0100, Antoine Tenart wrote:
>> Hi Marc,
>>
>> On Mon, Feb 08, 2016 at 03:29:33PM +0000, Marc Zyngier wrote:
>>> On 08/02/16 09:11, Antoine Tenart wrote:
>>>
>>>> +		gic: gic at f0100000 {
>>>> +			compatible = "arm,gic-v3";
>>>> +			reg = <0x0 0xf0200000 0x0 0x10000>,	/* GIC Dist */
>>>> +			      <0x0 0xf0280000 0x0 0x200000>,	/* GICR */
>>>> +			      <0x0 0xf0100000 0x0 0x2000>;	/* GICC */
>>>> +			interrupt-controller;
>>>> +			#interrupt-cells = <3>;
>>>> +		};
>>>
>>> Something is wrong here. Either you are missing GICH and GICV (assuming
>>> you have legacy support), or you have an extra GICC region (which
>>> doesn't make sense on its own).
>>
>> I'll add the missing regions.
> 
> Hmm, in fact the GICC region shouldn't be there. I'll make some tests
> and remove it.

If you have a GICv3 with legacy support, you will probably have GICC,
GICH and GICV. Linux itself will only use GICD and GICR, but it needs at
least GICV to be able to virtualize GICv2 guests. And GICV is not
allowed to exist without GICC and GICH, so I really recommend that you
keep GICC around.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From brian.starkey at arm.com  Tue Feb  9 01:15:02 2016
From: brian.starkey at arm.com (Brian Starkey)
Date: Tue, 9 Feb 2016 09:15:02 +0000
Subject: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag
In-Reply-To: <20160208183006.GA8429@kroah.com>
References: <cover.1454950917.git.brian.starkey@arm.com>
 <9085d37fa97a762a46b9d58719c085368682c64f.1454950917.git.brian.starkey@arm.com>
 <20160208183006.GA8429@kroah.com>
Message-ID: <20160209091501.GA23507@e106950-lin.cambridge.arm.com>

Hi Greg,

On Mon, Feb 08, 2016 at 10:30:06AM -0800, Greg KH wrote:
>On Mon, Feb 08, 2016 at 05:30:50PM +0000, Brian Starkey wrote:
>> diff --git a/include/linux/io.h b/include/linux/io.h
>> index 32403b5..e2c8419 100644
>> --- a/include/linux/io.h
>> +++ b/include/linux/io.h
>> @@ -135,6 +135,7 @@ enum {
>>  	/* See memremap() kernel-doc for usage description... */
>>  	MEMREMAP_WB = 1 << 0,
>>  	MEMREMAP_WT = 1 << 1,
>> +	MEMREMAP_WC = 1 << 2,
>
>You didn't update the documentation :(
>

Maybe I missed something, but I don't think there's anything to update
here? Like the comment says, the flags are documented in the memremap()
kernel-doc (which I did update - see the next two hunks of this patch).

Thanks,

Brian


From paul at pwsan.com  Tue Feb  9 01:18:01 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 9 Feb 2016 09:18:01 +0000 (UTC)
Subject: [PATCH v2] ARM: DRA7: hwmod: Fix OCP2SCP sysconfig
In-Reply-To: <1455008743-21660-1-git-send-email-kishon@ti.com>
References: <1455008743-21660-1-git-send-email-kishon@ti.com>
Message-ID: <alpine.DEB.2.02.1602090917040.2906@utopia.booyaka.com>

On Tue, 9 Feb 2016, Kishon Vijay Abraham I wrote:

> OCP2SCP doesn't support smart idle wakeup according to
> Table 26-22. OCP2SCP_SYSCONFIG in AM572x TRM [1] and
> Table 26-22. OCP2SCP_SYSCONFIG in AM571x TRM [2].
> Remove SIDLE_SMART_WKUP from the list of supported SIDLE modes
> in hwmod data.
> 
> [1] -> http://www.ti.com/lit/ug/spruhz6e/spruhz6e.pdf
> [2] -> http://www.ti.com/lit/ug/spruhz7a/spruhz7a.pdf
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>

Thanks, queued for v4.6.  If you'd like it queued as a fix, please resend 
with a description of the regression that it fixes.


- Paul


From michal.simek at xilinx.com  Tue Feb  9 01:19:16 2016
From: michal.simek at xilinx.com (Michal Simek)
Date: Tue, 9 Feb 2016 10:19:16 +0100
Subject: [PATCH 0/2] ARM: zynq: address silent L2 cache corruption
In-Reply-To: <cover.1454465714.git.joshc@ni.com>
References: <cover.1454465714.git.joshc@ni.com>
Message-ID: <56B9AF14.3070706@xilinx.com>

On 3.2.2016 03:30, Josh Cartwright wrote:
> The Zynq has a bug where the L2 cache will return invalid data in some
> circumstances unless the L2C_RAM register is set to 0x20202 before the first
> enabling of the L2 cache.
> 
> The Xilinx-recommended solution to this problem is to ensure that early one of
> the earlier bootstages correctly initialize L2C_RAM, however, this issue wasn't
> discovered and fixed until after their EDK/SDK 14.4 release.  For systems built
> prior to that, and which lack field-upgradable bootloaders, this issue still
> exists and silent data corruption can be seen in the wild.
> 
> Fix these systems by ensuring L2C_RAM is properly initialized at the
> earliest convenient moment prior to the L2 being brought up, which is
> when the SLCR is first mapped.
> 
> Unfortunately, there isn't much public documentation on exactly what the
> L2C_RAM register is for, or how it is used, only that software is responsible
> for initializing it to the proper value prior to bringing up L2.
> 
> You can find more information about this bug in AR#54190[1].
> 
> 1: http://www.xilinx.com/support/answers/54190.html
> 
> Josh Cartwright (2):
>   ARM: zynq: initialize slcr mapping earlier
>   ARM: zynq: address L2 cache data corruption
> 
>  arch/arm/mach-zynq/common.c | 3 +--
>  arch/arm/mach-zynq/slcr.c   | 4 ++++
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 

Applied both.

Thanks,
Michal



From codekipper at gmail.com  Tue Feb  9 01:25:32 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Tue,  9 Feb 2016 10:25:32 +0100
Subject: [linux-sunxi][PATCH] ARM: dts: sun7i: Enable USB DRC on MK808C
Message-ID: <1455009932-27616-1-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

Enable the otg/drc usb controller on the MK808C.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
 arch/arm/boot/dts/sun7i-a20-mk808c.dts | 35 ++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-mk808c.dts b/arch/arm/boot/dts/sun7i-a20-mk808c.dts
index c9e648d..90ff4a2 100644
--- a/arch/arm/boot/dts/sun7i-a20-mk808c.dts
+++ b/arch/arm/boot/dts/sun7i-a20-mk808c.dts
@@ -53,6 +53,7 @@
 
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
 
 / {
 	model = "mk808c";
@@ -125,6 +126,30 @@
 	status = "okay";
 };
 
+&otg_sram {
+	status = "okay";
+};
+
+&pio {
+	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
+		allwinner,pins = "PH4";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+
+	usb0_vbus_detect_pin: usb0_vbus_detect_pin at 0 {
+		allwinner,pins = "PH5";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+};
+
+&reg_usb0_vbus {
+	status = "okay";
+};
+
 &reg_usb1_vbus {
 	status = "okay";
 };
@@ -145,7 +170,17 @@
 	status = "okay";
 };
 
+&usb_otg {
+	dr_mode = "otg";
+	status = "okay";
+};
+
 &usbphy {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
+	usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+	usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+	usb0_vbus-supply = <&reg_usb0_vbus>;
 	usb1_vbus-supply = <&reg_usb1_vbus>;
 	usb2_vbus-supply = <&reg_usb2_vbus>;
 	status = "okay";
-- 
2.7.1



From arnd at arndb.de  Tue Feb  9 01:25:33 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 10:25:33 +0100
Subject: [PATCH v5 3/3] pci,
 pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices
In-Reply-To: <20160208232430.GA1353@localhost>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
 <56B919A5.5090000@caviumnetworks.com> <20160208232430.GA1353@localhost>
Message-ID: <12842339.z2KnaZPlyO@wuerfel>

On Monday 08 February 2016 17:24:30 Bjorn Helgaas wrote:
> > >
> > >I assume your system conforms to expectations like these; I'm just
> > >pointing them out because you mentioned buses with multiple devices on
> > >them, which is definitely something one doesn't expect in PCIe.
> > 
> > The topology we have is currently working with the kernel's core PCI
> > code.  I don't really want to get into discussing what the
> > definition of PCIe is.  We have multiple devices (more than 32) on a
> > single bus, and they have PCI Express and ARI Capabilities.  Is that
> > PCIe?  I don't know.
> 
> I don't need to know the details of your topology.  As long as it
> conforms to the PCIe spec, it should be fine.  If it *doesn't* conform
> to the spec, but things currently seem to work, that's less fine,
> because a future Linux change is liable to break something for you.
> 
> I was a little concerned about your statement that "there are multiple
> devices residing on each bus, so from that point of view it cannot be
> PCIe."  That made it sound like you're doing something outside the
> spec.  If you're just using regular multi-function devices or ARI,
> then I don't see any issue (or any reason to say it can't be PCIe).

It doesn't conform to the PCIe port spec, because there are no external
ports but just integrated devices in the host bridge. For this special
case, I don't think it matters at all from the point of view of the DT
binding whether we call the node name "pci" or "pcie".

IIRC, even on real Open Firmware, the three companies that shipped
PCIe (or Hypertransport, which doesn't even have a formal binding)
based machines (Sun, IBM, Apple) were using slightly different
bindings in practice, so I wouldn't read to much into it. Any OS
that wants to run on real OF already has to support it either way.

	Arnd


From codekipper at gmail.com  Tue Feb  9 01:29:16 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Tue,  9 Feb 2016 10:29:16 +0100
Subject: [linux-sunxi][PATCH v2] ARM: dts: sun7i: Enable USB DRC on Itead Ibox
Message-ID: <1455010156-27754-1-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

Enable the otg/drc usb controller on the Itead Ibox device.

Note this board has the otg-vbus connected directly to the 5v-dcc of
the board, so there is no vbus0 regulator, nor vbus0-det.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
Changes since v1:
- Added comment concerning vbus0 regulator and detection to commit message

---
 arch/arm/boot/dts/sun7i-a20-itead-ibox.dts     | 14 ++++++++++++++
 arch/arm/boot/dts/sunxi-itead-core-common.dtsi |  9 +++++++++
 2 files changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
index 661c21d..a512581 100644
--- a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
+++ b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
@@ -118,8 +118,22 @@
 		allwinner,drive = <SUN4I_PINCTRL_20_MA>;
 		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
 	};
+
+	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
+		allwinner,pins = "PH4";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
 };
 
 &reg_ahci_5v {
 	status = "okay";
 };
+
+&usbphy {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb0_id_detect_pin>;
+	usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
index 2565d51..d22eea3 100644
--- a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
+++ b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
@@ -88,6 +88,10 @@
 	status = "okay";
 };
 
+&otg_sram {
+	status = "okay";
+};
+
 #include "axp209.dtsi"
 
 &reg_dcdc2 {
@@ -129,6 +133,11 @@
 	status = "okay";
 };
 
+&usb_otg {
+	dr_mode = "otg";
+	status = "okay";
+};
+
 &usbphy {
 	usb1_vbus-supply = <&reg_usb1_vbus>;
 	usb2_vbus-supply = <&reg_usb2_vbus>;
-- 
2.7.1



From daniel at ffwll.ch  Tue Feb  9 01:29:41 2016
From: daniel at ffwll.ch (Daniel Vetter)
Date: Tue, 9 Feb 2016 10:29:41 +0100
Subject: [RESEND PATCH v1] drm: Clean up drm Makefile
In-Reply-To: <CAFCwf120-19JKDGGPOBQ4ALg=f5ESG4pVhMeN1s=0uz3OpoFpg@mail.gmail.com>
References: <1454147777-77577-1-git-send-email-xinliang.liu@linaro.org>
 <CAFCwf120-19JKDGGPOBQ4ALg=f5ESG4pVhMeN1s=0uz3OpoFpg@mail.gmail.com>
Message-ID: <20160209092941.GE11240@phenom.ffwll.local>

On Sat, Jan 30, 2016 at 01:11:01PM +0200, Oded Gabbay wrote:
> On Sat, Jan 30, 2016 at 11:56 AM, Xinliang Liu <xinliang.liu at linaro.org> wrote:
> > This patch cleans up the Makefile of drm root directory.
> > Make core and device drivers configuration list sorted Alphabetically.
> >
> > Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
> > Reviewed-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
> > Reviewed-by: Yifan Liu <liu_fanyi at 163.com>
> > ---
> >  drivers/gpu/drm/Makefile | 102 ++++++++++++++++++++++++-----------------------
> >  1 file changed, 52 insertions(+), 50 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 61766dec6a8d..77000717305b 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -2,6 +2,9 @@
> >  # Makefile for the drm device driver.  This driver provides support for the
> >  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
> >
> > +CFLAGS_drm_trace_points.o := -I$(src)
> > +
> > +# core. Please keep this list sorted alphabetically
> >  drm-y       := drm_auth.o drm_bufs.o drm_cache.o \
> >                 drm_context.o drm_dma.o \
> >                 drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
> > @@ -13,64 +16,63 @@ drm-y       :=      drm_auth.o drm_bufs.o drm_cache.o \
> >                 drm_trace_points.o drm_global.o drm_prime.o \
> >                 drm_rect.o drm_vma_manager.o drm_flip_work.o \
> >                 drm_modeset_lock.o drm_atomic.o drm_bridge.o
> > -
> > -drm-$(CONFIG_COMPAT) += drm_ioc32.o
> > -drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
> >  drm-$(CONFIG_PCI) += ati_pcigart.o
> > -drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> > -drm-$(CONFIG_OF) += drm_of.o
> >  drm-$(CONFIG_AGP) += drm_agpsupport.o
> > +drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
> > +drm-$(CONFIG_COMPAT) += drm_ioc32.o
> > +drm-$(CONFIG_OF) += drm_of.o
> > +drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> > +obj-$(CONFIG_DRM)      += drm.o
> > +
> > +obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
> >
> >  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> >                 drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
> >  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> > -drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> >  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
> > -
> > +drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> >  obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
> >
> > -CFLAGS_drm_trace_points.o := -I$(src)
> > +obj-$(CONFIG_DRM_TTM) += ttm/
> >
> > -obj-$(CONFIG_DRM)      += drm.o
> > -obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
> > -obj-$(CONFIG_DRM_TTM)  += ttm/
> > -obj-$(CONFIG_DRM_TDFX) += tdfx/
> > -obj-$(CONFIG_DRM_R128) += r128/
> > -obj-$(CONFIG_HSA_AMD) += amd/amdkfd/
> > -obj-$(CONFIG_DRM_RADEON)+= radeon/
> > -obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
> > -obj-$(CONFIG_DRM_MGA)  += mga/
> > -obj-$(CONFIG_DRM_I810) += i810/
> > -obj-$(CONFIG_DRM_I915)  += i915/
> > -obj-$(CONFIG_DRM_MGAG200) += mgag200/
> > -obj-$(CONFIG_DRM_VC4)  += vc4/
> > -obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
> > -obj-$(CONFIG_DRM_SIS)   += sis/
> > -obj-$(CONFIG_DRM_SAVAGE)+= savage/
> > -obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
> > -obj-$(CONFIG_DRM_VIA)  +=via/
> > -obj-$(CONFIG_DRM_VGEM) += vgem/
> > -obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
> > -obj-$(CONFIG_DRM_EXYNOS) +=exynos/
> > -obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
> > -obj-$(CONFIG_DRM_GMA500) += gma500/
> > -obj-$(CONFIG_DRM_UDL) += udl/
> > -obj-$(CONFIG_DRM_AST) += ast/
> > -obj-$(CONFIG_DRM_ARMADA) += armada/
> > +# device drivers. Please keep this list sorted alphabetically
> > +obj-$(CONFIG_DRM_AMDGPU)       += amd/amdgpu/
> > +obj-$(CONFIG_HSA_AMD)          += amd/amdkfd/
> > +obj-$(CONFIG_DRM_ARMADA)       += armada/
> > +obj-$(CONFIG_DRM_AST)          += ast/
> >  obj-$(CONFIG_DRM_ATMEL_HLCDC)  += atmel-hlcdc/
> > -obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
> > -obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
> > -obj-y                  += omapdrm/
> > -obj-y                  += tilcdc/
> > -obj-$(CONFIG_DRM_QXL) += qxl/
> > -obj-$(CONFIG_DRM_BOCHS) += bochs/
> > -obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio/
> > -obj-$(CONFIG_DRM_MSM) += msm/
> > -obj-$(CONFIG_DRM_TEGRA) += tegra/
> > -obj-$(CONFIG_DRM_STI) += sti/
> > -obj-$(CONFIG_DRM_IMX) += imx/
> > -obj-y                  += i2c/
> > -obj-y                  += panel/
> > -obj-y                  += bridge/
> > -obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
> > -obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
> > +obj-$(CONFIG_DRM_BOCHS)                += bochs/
> > +obj-y                          += bridge/
> > +obj-$(CONFIG_DRM_CIRRUS_QEMU)  += cirrus/
> > +obj-$(CONFIG_DRM_ETNAVIV)      += etnaviv/
> > +obj-$(CONFIG_DRM_EXYNOS)       += exynos/
> > +obj-$(CONFIG_DRM_FSL_DCU)      += fsl-dcu/
> > +obj-$(CONFIG_DRM_GMA500)       += gma500/
> > +obj-y                          += i2c/
> > +obj-$(CONFIG_DRM_I810)         += i810/
> > +obj-$(CONFIG_DRM_I915)         += i915/
> > +obj-$(CONFIG_DRM_IMX)          += imx/
> > +obj-$(CONFIG_DRM_MGA)          += mga/
> > +obj-$(CONFIG_DRM_MGAG200)      += mgag200/
> > +obj-$(CONFIG_DRM_MSM)          += msm/
> > +obj-$(CONFIG_DRM_NOUVEAU)      += nouveau/
> > +obj-y                          += omapdrm/
> > +obj-y                          += panel/
> > +obj-$(CONFIG_DRM_QXL)          += qxl/
> > +obj-$(CONFIG_DRM_R128)         += r128/
> > +obj-$(CONFIG_DRM_RADEON)       += radeon/
> > +obj-$(CONFIG_DRM_RCAR_DU)      += rcar-du/
> > +obj-$(CONFIG_DRM_ROCKCHIP)     += rockchip/
> > +obj-$(CONFIG_DRM_SAVAGE)       += savage/
> > +obj-$(CONFIG_DRM_SHMOBILE)     += shmobile/
> > +obj-$(CONFIG_DRM_SIS)          += sis/
> > +obj-$(CONFIG_DRM_STI)          += sti/
> > +obj-$(CONFIG_DRM_TDFX)         += tdfx/
> > +obj-$(CONFIG_DRM_TEGRA)                += tegra/
> > +obj-y                          += tilcdc/
> > +obj-$(CONFIG_DRM_UDL)          += udl/
> > +obj-$(CONFIG_DRM_VC4)          += vc4/
> > +obj-$(CONFIG_DRM_VGEM)         += vgem/
> > +obj-$(CONFIG_DRM_VIA)          += via/
> > +obj-$(CONFIG_DRM_VIRTIO_GPU)   += virtio/
> > +obj-$(CONFIG_DRM_VMWGFX)       += vmwgfx/
> > --
> > 1.9.1
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> NACK, amdkfd *must* be before amdgpu *and* radeon, because it needs to
> be already loaded when amdgpu/radeon get loaded, and when all these
> drivers are compiled inside the kernel, the order is maintained by the
> linkage order in the makefile.

That's not how this is supposed to be done. If you have inter-driver
depencies like this you need to check for them, and defer the driver
loading by returngin -EPROBE_DEFER. The core kernel will then re-probe
your driver once other drivers have loaded. Handling inter-driver deps
using compile-ordering is seriously too fragile.

Please fix this up, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From marc.zyngier at arm.com  Tue Feb  9 01:30:29 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 9 Feb 2016 09:30:29 +0000
Subject: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <CABM=7knaepbyy4nw_GczVM7E_t6py7gG0ERs8ru_AYoVXvAQ+A@mail.gmail.com>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
 <56B8B45D.1020902@arm.com> <20160209085633.GA5388@kwain>
 <20160209090131.GB5388@kwain> <56B9ACE2.1060200@arm.com>
 <CABM=7knaepbyy4nw_GczVM7E_t6py7gG0ERs8ru_AYoVXvAQ+A@mail.gmail.com>
Message-ID: <56B9B1B5.5070106@arm.com>

On 09/02/16 09:14, Tsahee Zidenberg wrote:
> 
> 
> On 9 February 2016 at 11:09, Marc Zyngier <marc.zyngier at arm.com
> <mailto:marc.zyngier at arm.com>> wrote:
> 
>     On 09/02/16 09:01, Antoine Tenart wrote:
>     > On Tue, Feb 09, 2016 at 09:56:33AM +0100, Antoine Tenart wrote:
>     >> Hi Marc,
>     >>
>     >> On Mon, Feb 08, 2016 at 03:29:33PM +0000, Marc Zyngier wrote:
>     >>> On 08/02/16 09:11, Antoine Tenart wrote:
>     >>>
>     >>>> +          gic: gic at f0100000 {
>     >>>> +                  compatible = "arm,gic-v3";
>     >>>> +                  reg = <0x0 0xf0200000 0x0 0x10000>,     /* GIC Dist */
>     >>>> +                        <0x0 0xf0280000 0x0 0x200000>,    /* GICR */
>     >>>> +                        <0x0 0xf0100000 0x0 0x2000>;      /* GICC */
>     >>>> +                  interrupt-controller;
>     >>>> +                  #interrupt-cells = <3>;
>     >>>> +          };
>     >>>
>     >>> Something is wrong here. Either you are missing GICH and GICV (assuming
>     >>> you have legacy support), or you have an extra GICC region (which
>     >>> doesn't make sense on its own).
>     >>
>     >> I'll add the missing regions.
>     >
>     > Hmm, in fact the GICC region shouldn't be there. I'll make some tests
>     > and remove it.
> 
>     If you have a GICv3 with legacy support, you will probably have GICC,
>     GICH and GICV. Linux itself will only use GICD and GICR, but it needs at
>     least GICV to be able to virtualize GICv2 guests. And GICV is not
>     allowed to exist without GICC and GICH, so I really recommend that you
>     keep GICC around.
> 
> 
> We use the GIC without legacy support (we disable it in early boot
> stages), so I think removing the GICC region is the better solution.

Disabling legacy support doesn't mean that:
- the HW isn't present
- the associated regions are not useful

Here, we describe the HW, not the usage you make of it.

And unless you think that having working virtualization is completely
useless, I strongly suggest that you properly document the HW in the
device tree.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From hdegoede at redhat.com  Tue Feb  9 01:30:51 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Tue, 9 Feb 2016 10:30:51 +0100
Subject: [linux-sunxi][PATCH] ARM: dts: sun7i: Enable USB DRC on MK808C
In-Reply-To: <1455009932-27616-1-git-send-email-codekipper@gmail.com>
References: <1455009932-27616-1-git-send-email-codekipper@gmail.com>
Message-ID: <56B9B1CB.102@redhat.com>

Hi,

On 09-02-16 10:25, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
>
> Enable the otg/drc usb controller on the MK808C.
>
> Signed-off-by: Marcus Cooper <codekipper at gmail.com>

Thanks patch looks good to me:

Reviewed-by: Hans de Goede <hdegoede at redhat.com>

Regards,

Hans

> ---
>   arch/arm/boot/dts/sun7i-a20-mk808c.dts | 35 ++++++++++++++++++++++++++++++++++
>   1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-mk808c.dts b/arch/arm/boot/dts/sun7i-a20-mk808c.dts
> index c9e648d..90ff4a2 100644
> --- a/arch/arm/boot/dts/sun7i-a20-mk808c.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-mk808c.dts
> @@ -53,6 +53,7 @@
>
>   #include <dt-bindings/gpio/gpio.h>
>   #include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>
>   / {
>   	model = "mk808c";
> @@ -125,6 +126,30 @@
>   	status = "okay";
>   };
>
> +&otg_sram {
> +	status = "okay";
> +};
> +
> +&pio {
> +	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
> +		allwinner,pins = "PH4";
> +		allwinner,function = "gpio_in";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +	};
> +
> +	usb0_vbus_detect_pin: usb0_vbus_detect_pin at 0 {
> +		allwinner,pins = "PH5";
> +		allwinner,function = "gpio_in";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +	};
> +};
> +
> +&reg_usb0_vbus {
> +	status = "okay";
> +};
> +
>   &reg_usb1_vbus {
>   	status = "okay";
>   };
> @@ -145,7 +170,17 @@
>   	status = "okay";
>   };
>
> +&usb_otg {
> +	dr_mode = "otg";
> +	status = "okay";
> +};
> +
>   &usbphy {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
> +	usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
> +	usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
> +	usb0_vbus-supply = <&reg_usb0_vbus>;
>   	usb1_vbus-supply = <&reg_usb1_vbus>;
>   	usb2_vbus-supply = <&reg_usb2_vbus>;
>   	status = "okay";
>


From hdegoede at redhat.com  Tue Feb  9 01:31:01 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Tue, 9 Feb 2016 10:31:01 +0100
Subject: [linux-sunxi][PATCH v2] ARM: dts: sun7i: Enable USB DRC on Itead
 Ibox
In-Reply-To: <1455010156-27754-1-git-send-email-codekipper@gmail.com>
References: <1455010156-27754-1-git-send-email-codekipper@gmail.com>
Message-ID: <56B9B1D5.7070002@redhat.com>

Jo.

On 09-02-16 10:29, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
>
> Enable the otg/drc usb controller on the Itead Ibox device.
>
> Note this board has the otg-vbus connected directly to the 5v-dcc of
> the board, so there is no vbus0 regulator, nor vbus0-det.
>
> Signed-off-by: Marcus Cooper <codekipper at gmail.com>
> ---
> Changes since v1:
> - Added comment concerning vbus0 regulator and detection to commit message

Thanks patch looks good to me:

Reviewed-by: Hans de Goede <hdegoede at redhat.com>

Regards,

Hans


>
> ---
>   arch/arm/boot/dts/sun7i-a20-itead-ibox.dts     | 14 ++++++++++++++
>   arch/arm/boot/dts/sunxi-itead-core-common.dtsi |  9 +++++++++
>   2 files changed, 23 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
> index 661c21d..a512581 100644
> --- a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
> @@ -118,8 +118,22 @@
>   		allwinner,drive = <SUN4I_PINCTRL_20_MA>;
>   		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>   	};
> +
> +	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
> +		allwinner,pins = "PH4";
> +		allwinner,function = "gpio_in";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +	};
>   };
>
>   &reg_ahci_5v {
>   	status = "okay";
>   };
> +
> +&usbphy {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&usb0_id_detect_pin>;
> +	usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
> +	status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
> index 2565d51..d22eea3 100644
> --- a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
> +++ b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
> @@ -88,6 +88,10 @@
>   	status = "okay";
>   };
>
> +&otg_sram {
> +	status = "okay";
> +};
> +
>   #include "axp209.dtsi"
>
>   &reg_dcdc2 {
> @@ -129,6 +133,11 @@
>   	status = "okay";
>   };
>
> +&usb_otg {
> +	dr_mode = "otg";
> +	status = "okay";
> +};
> +
>   &usbphy {
>   	usb1_vbus-supply = <&reg_usb1_vbus>;
>   	usb2_vbus-supply = <&reg_usb2_vbus>;
>


From ard.biesheuvel at linaro.org  Tue Feb  9 01:30:59 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  9 Feb 2016 10:30:59 +0100
Subject: [PATCH v3 0/3] kallsyms: remove special handling for CONFIG_ARM
Message-ID: <1455010262-28894-1-git-send-email-ard.biesheuvel@linaro.org>

The kallsyms symbol address table generation contains a workaround for
CONFIG_ARM to address an issue with perf when it sees symbols whose
addresses are close to 0x0. The workaround is only enabled if XIP_KERNEL=n,
not because the issue itself only exists in that case, but because the
chosen workaround cannot deal with [_stext,_etext] living below PAGE_OFFSET.

So let's fix this properly, by emitting the stubs symbols at a more reasonable
offset, which is more likely to be the actual location of the vectors and stubs
sections at runtime, and will prevent the symbols from being mistaken for
userland symbols by perf.

Changes since v2:
- Move back to the original arrangement, where .stubs follows .vectors, and both
  are emitted outside of the ordinary kernel VMA space
- Move .vectors and .stubs sections to VMA 0xffff0000/0xffff1000, respectively.
  As Russell pointed out, this is the most reasonable value, since modern CPUs
  actually execute the vectors and stubs from there, and it fixes the kallsyms
  perf issue all the same.
- Rebased onto latest -next, which contains related ARM patch 8514/1, and
  updated kallsyms base relative patches (queued via akpm's tree)

Changes since v1:
- added Nico's ack
- use PROVIDE() for vector_fiq_offset since vector_fiq itself is not always
  defined
- put __stubs_start/_end inside the section definition so that the value of the
  start symbol equals the start of the section after alignment (fixes an issue
  on XIP spotted by Chris)

Patch #1 moves the .stubs and .vectors section back into the kernel VMA, while
preserving the guaranteed virtual offset of 4 KB. This results in all symbols
that kallsyms sees to be in a reasonable interval.

Patch #2 removes the special case for CONFIG_ARM && !CONFIG_XIP_KERNEL in the
invocation of scripts/kallsyms

Patch #3 removes the now unused --page-offset command line argument handling
from scripts/kallsyms.c

Patch #4 is included as an RFC, it removes the magic constant 0x1000 which is
the offset between the start of the .vectors section and the start of the
.stubs section.

Ard Biesheuvel (3):
  ARM: move .vectors and .stubs sections back into the kernel VMA
  kallsyms: remove special lower address limit for CONFIG_ARM
  kallsyms: remove --page-offset command line option

 arch/arm/kernel/entry-armv.S  | 3 +--
 arch/arm/kernel/vmlinux.lds.S | 6 ++++--
 scripts/kallsyms.c            | 8 --------
 scripts/link-vmlinux.sh       | 4 ----
 4 files changed, 5 insertions(+), 16 deletions(-)

-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb  9 01:31:02 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  9 Feb 2016 10:31:02 +0100
Subject: [PATCH v3 3/3] kallsyms: remove --page-offset command line option
In-Reply-To: <1455010262-28894-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455010262-28894-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455010262-28894-4-git-send-email-ard.biesheuvel@linaro.org>

The --page-offset command line option was only used for ARM, to filter
symbol addresses below CONFIG_PAGE_OFFSET. This is no longer needed, so
remove the functionality altogether.

Acked-by: Nicolas Pitre <nico at linaro.org>
Acked-by: Chris Brandt <chris.brandt at renesas.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 scripts/kallsyms.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 638b143ee60f..de9b74b083c2 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -63,7 +63,6 @@ static unsigned int table_size, table_cnt;
 static int all_symbols = 0;
 static int absolute_percpu = 0;
 static char symbol_prefix_char = '\0';
-static unsigned long long kernel_start_addr = 0;
 static int base_relative = 0;
 
 int token_profit[0x10000];
@@ -228,10 +227,6 @@ static int symbol_valid(struct sym_entry *s)
 	int i;
 	char *sym_name = (char *)s->sym + 1;
 
-
-	if (s->addr < kernel_start_addr)
-		return 0;
-
 	/* skip prefix char */
 	if (symbol_prefix_char && *sym_name == symbol_prefix_char)
 		sym_name++;
@@ -765,9 +760,6 @@ int main(int argc, char **argv)
 				if ((*p == '"' && *(p+2) == '"') || (*p == '\'' && *(p+2) == '\''))
 					p++;
 				symbol_prefix_char = *p;
-			} else if (strncmp(argv[i], "--page-offset=", 14) == 0) {
-				const char *p = &argv[i][14];
-				kernel_start_addr = strtoull(p, NULL, 16);
 			} else if (strcmp(argv[i], "--base-relative") == 0)
 				base_relative = 1;
 			else
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb  9 01:31:01 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  9 Feb 2016 10:31:01 +0100
Subject: [PATCH v3 2/3] kallsyms: remove special lower address limit for
 CONFIG_ARM
In-Reply-To: <1455010262-28894-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455010262-28894-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455010262-28894-3-git-send-email-ard.biesheuvel@linaro.org>

Now that we no longer emit .stubs symbols into a section VMA loaded
at absolute address 0x1000, we can drop the ARM-specific override that
sets a lower limit based on CONFIG_PAGE_OFFSET, below which symbols are
filtered from the kallsyms output.

Acked-by: Nicolas Pitre <nico at linaro.org>
Acked-by: Chris Brandt <chris.brandt at renesas.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 scripts/link-vmlinux.sh | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 49d61ade9425..f0f6d9d75435 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -82,10 +82,6 @@ kallsyms()
 		kallsymopt="${kallsymopt} --all-symbols"
 	fi
 
-	if [ -n "${CONFIG_ARM}" ] && [ -z "${CONFIG_XIP_KERNEL}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
-		kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
-	fi
-
 	if [ -n "${CONFIG_KALLSYMS_ABSOLUTE_PERCPU}" ]; then
 		kallsymopt="${kallsymopt} --absolute-percpu"
 	fi
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb  9 01:31:00 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  9 Feb 2016 10:31:00 +0100
Subject: [PATCH v3 1/3] ARM: move .vectors and .stubs sections back into the
 kernel VMA
In-Reply-To: <1455010262-28894-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455010262-28894-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455010262-28894-2-git-send-email-ard.biesheuvel@linaro.org>

Commit b9b32bf70f2f ("ARM: use linker magic for vectors and vector stubs")
updated the linker script to emit the .vectors and .stubs sections into a
VMA range that is zero based and disjoint from the normal static kernel
region. The reason for that was that this way, the sections can be placed
exactly 4 KB apart, while the payload of the .vectors section is only 32
bytes.

Since the symbols that are part of the .stubs section are emitted into the
kallsyms table, they appear with zero based addresses as well, e.g.,

  00001004 t vector_rst
  00001020 t vector_irq
  000010a0 t vector_dabt
  00001120 t vector_pabt
  000011a0 t vector_und
  00001220 t vector_addrexcptn
  00001240 t vector_fiq
  00001240 T vector_fiq_offset

As this confuses perf when it accesses the kallsyms tables, commit
7122c3e9154b ("scripts/link-vmlinux.sh: only filter kernel symbols for
arm") implemented a somewhat ugly special case for ARM, where the value
of CONFIG_PAGE_OFFSET is passed to scripts/kallsyms, and symbols whose
addresses are below it are filtered out. Note that this special case only
applies to CONFIG_XIP_KERNEL=n, not because the issue the patch addresses
exists only in that case, but because finding a limit below which to apply
the filtering is not entirely straightforward.

Since the .vectors and .stubs sections contain position independent code
that is never executed in place, we can emit it at its most likely runtime
VMA (for more recent CPUs), which is 0xffff0000 for the vector table and
0xffff1000 for the stubs. Not only does this fix the perf issue with
kallsyms, allowing us to drop the special case in scripts/kallsyms
entirely, it also gives debuggers a more realistic view of the address
space, and setting breakpoints or single stepping through code in the
vector table or the stubs is more likely to work as expected on CPUs that
use a high vector address. E.g.,

  00001240 A vector_fiq_offset
  ...
  c0c35000 T __init_begin
  c0c35000 T __vectors_start
  c0c35020 T __stubs_start
  c0c35020 T __vectors_end
  c0c352e0 T _sinittext
  c0c352e0 T __stubs_end
  ...
  ffff1004 t vector_rst
  ffff1020 t vector_irq
  ffff10a0 t vector_dabt
  ffff1120 t vector_pabt
  ffff11a0 t vector_und
  ffff1220 t vector_addrexcptn
  ffff1240 T vector_fiq

(Note that vector_fiq_offset is now an absolute symbol, which kallsyms
already ignores by default)

The LMA footprint is identical with or without this change, only the VMAs
are different:

  Before:
  Idx Name          Size      VMA       LMA       File off  Algn
   ...
   14 .notes        00000024  c0c34020  c0c34020  00a34020  2**2
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   15 .vectors      00000020  00000000  c0c35000  00a40000  2**1
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   16 .stubs        000002c0  00001000  c0c35020  00a41000  2**5
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   17 .init.text    0006b1b8  c0c352e0  c0c352e0  00a452e0  2**5
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   ...

  After:
  Idx Name          Size      VMA       LMA       File off  Algn
   ...
   14 .notes        00000024  c0c34020  c0c34020  00a34020  2**2
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   15 .vectors      00000020  ffff0000  c0c35000  00a40000  2**1
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   16 .stubs        000002c0  ffff1000  c0c35020  00a41000  2**5
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   17 .init.text    0006b1b8  c0c352e0  c0c352e0  00a452e0  2**5
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   ...

Acked-by: Nicolas Pitre <nico at linaro.org>
Acked-by: Chris Brandt <chris.brandt at renesas.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm/kernel/entry-armv.S  | 3 +--
 arch/arm/kernel/vmlinux.lds.S | 6 ++++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 788e40c1254f..e2550500486d 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -1201,8 +1201,7 @@ vector_addrexcptn:
 	.long	__fiq_svc			@  e
 	.long	__fiq_svc			@  f
 
-	.globl	vector_fiq_offset
-	.equ	vector_fiq_offset, vector_fiq
+	.globl	vector_fiq
 
 	.section .vectors, "ax", %progbits
 .L__vectors_start:
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 8b60fde5ce48..844187a45aa3 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -165,19 +165,21 @@ SECTIONS
 	 * only thing that matters is their relative offsets
 	 */
 	__vectors_start = .;
-	.vectors 0 : AT(__vectors_start) {
+	.vectors 0xffff0000 : AT(__vectors_start) {
 		*(.vectors)
 	}
 	. = __vectors_start + SIZEOF(.vectors);
 	__vectors_end = .;
 
 	__stubs_start = .;
-	.stubs 0x1000 : AT(__stubs_start) {
+	.stubs ADDR(.vectors) + 0x1000 : AT(__stubs_start) {
 		*(.stubs)
 	}
 	. = __stubs_start + SIZEOF(.stubs);
 	__stubs_end = .;
 
+	PROVIDE(vector_fiq_offset = vector_fiq - ADDR(.vectors));
+
 	INIT_TEXT_SECTION(8)
 	.exit.text : {
 		ARM_EXIT_KEEP(EXIT_TEXT)
-- 
2.5.0



From codekipper at gmail.com  Tue Feb  9 01:33:28 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Tue,  9 Feb 2016 10:33:28 +0100
Subject: [linux-sunxi][PATCH v2] ARM: dts: sun7i: Enable USB DRC on Olimex A20
 EVB
Message-ID: <1455010408-27896-1-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

Enable the otg/drc usb controller on the Olimex A20 EVB.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
Changes since v1:
- Added vbus0 regulator and vbus0 detection to dts 

---
 arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 32 ++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
index c3c626b..23aacce 100644
--- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
@@ -198,6 +198,10 @@
 	status = "okay";
 };
 
+&otg_sram {
+	status = "okay";
+};
+
 &pio {
 	ahci_pwr_pin_olimex_som_evb: ahci_pwr_pin at 1 {
 		allwinner,pins = "PC3";
@@ -219,6 +223,20 @@
 		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
 		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
 	};
+
+	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
+		allwinner,pins = "PH4";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+
+	usb0_vbus_detect_pin: usb0_vbus_detect_pin at 0 {
+		allwinner,pins = "PH5";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
 };
 
 &reg_ahci_5v {
@@ -254,6 +272,10 @@
 	regulator-name = "avcc";
 };
 
+&reg_usb0_vbus {
+	status = "okay";
+};
+
 &reg_usb1_vbus {
 	status = "okay";
 };
@@ -268,7 +290,17 @@
 	status = "okay";
 };
 
+&usb_otg {
+	dr_mode = "otg";
+	status = "okay";
+};
+
 &usbphy {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
+	usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH04 */
+	usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH05 */
+	usb0_vbus-supply = <&reg_usb0_vbus>;
 	usb1_vbus-supply = <&reg_usb1_vbus>;
 	usb2_vbus-supply = <&reg_usb2_vbus>;
 	status = "okay";
-- 
2.7.1



From mpe at ellerman.id.au  Tue Feb  9 01:36:40 2016
From: mpe at ellerman.id.au (Michael Ellerman)
Date: Tue, 09 Feb 2016 20:36:40 +1100
Subject: [PATCH v3 0/2] Consolidate redundant register/stack access code
In-Reply-To: <1454996337-7935-1-git-send-email-dave.long@linaro.org>
References: <1454996337-7935-1-git-send-email-dave.long@linaro.org>
Message-ID: <1455010600.13384.3.camel@ellerman.id.au>

On Tue, 2016-02-09 at 00:38 -0500, David Long wrote:

> From: "David A. Long" <dave.long at linaro.org>
>
> Move duplicate and functionally equivalent code for accessing registers
> and stack (CONFIG_HAVE_REGS_AND_STACK_ACCESS_API) from arch subdirs into
> common kernel files.
>
> I'm sending this out again (with updated distribution list) because v2
> just never got pulled in, even though I don't think there were any
> outstanding issues.

A big cross arch patch like this would often get taken by Andrew Morton, but
AFAICS you didn't CC him - so I just added him, perhaps he'll pick it up for
us :D

cheers



From mingo at kernel.org  Tue Feb  9 01:45:26 2016
From: mingo at kernel.org (Ingo Molnar)
Date: Tue, 9 Feb 2016 10:45:26 +0100
Subject: [PATCH v3 0/2] Consolidate redundant register/stack access code
In-Reply-To: <1455010600.13384.3.camel@ellerman.id.au>
References: <1454996337-7935-1-git-send-email-dave.long@linaro.org>
 <1455010600.13384.3.camel@ellerman.id.au>
Message-ID: <20160209094526.GB25268@gmail.com>


* Michael Ellerman <mpe at ellerman.id.au> wrote:

> On Tue, 2016-02-09 at 00:38 -0500, David Long wrote:
> 
> > From: "David A. Long" <dave.long at linaro.org>
> >
> > Move duplicate and functionally equivalent code for accessing registers
> > and stack (CONFIG_HAVE_REGS_AND_STACK_ACCESS_API) from arch subdirs into
> > common kernel files.
> >
> > I'm sending this out again (with updated distribution list) because v2
> > just never got pulled in, even though I don't think there were any
> > outstanding issues.
> 
> A big cross arch patch like this would often get taken by Andrew Morton, but
> AFAICS you didn't CC him - so I just added him, perhaps he'll pick it up for
> us :D

The other problem is that the second patch is commingling changes to 6 separate 
architectures:

 16 files changed, 106 insertions(+), 343 deletions(-)

that should probably be 6 separate patches. Easier to review, easier to bisect to, 
easier to revert, etc.

Thanks,

	Ingo


From will.deacon at arm.com  Tue Feb  9 01:47:08 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Feb 2016 09:47:08 +0000
Subject: [PATCH v2 0/5] arm64: kernel: Add support for User Access Override
In-Reply-To: <13475776.5b1DTHhHh9@wuerfel>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
 <13475776.5b1DTHhHh9@wuerfel>
Message-ID: <20160209094707.GA22874@arm.com>

On Fri, Feb 05, 2016 at 04:40:54PM +0100, Arnd Bergmann wrote:
> * Do we expect to handle this using live patching indefinitely? I can imagine
>   that at some point in the future, ARMv8.2+ systems will be the vast majority,
>   so it might be nice to support enabling it unconditionally (same for any
>   of the alternative bits really). Is there a long-term strategy?

Another good reason for an option turning these things on by default is
that it makes debugging *so* much easier when the vmlinux matches what's
actually running!

So yes, that's definitely something we should look at in the long-term,
but we still need the live patching for distro kernels that will assumedly
want a single Image covering ARMv8+ for a while.

Will


From linus.walleij at linaro.org  Tue Feb  9 01:49:38 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Feb 2016 10:49:38 +0100
Subject: [GIT PULL] RealView defconfig reduction
Message-ID: <CACRpkdYUPFm=s6mZbU8xTHqQBtcvmdCzaTCfSBPfBQ1qQi2f5Q@mail.gmail.com>

Hi ARM SoC folks,

this cuts the RealView SMP-specific defconfig. It is just confusing and
hard to handle now that we can do SMP on UP.

Tested on RealView PB11MPcore (SMP) and PB1176JZF-S (UP).

I don't know if people's autobuild systems are made to handled the case
where a defconfig disappears, so heads up to Kevin & Olof.

Please pull this in for this or the next kernel cycle whatever suits you
best.

Yours,
Linus Walleij

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git
tags/realview-defconfig-redux

for you to fetch changes up to 52abf1eff88d291c5ba092dc93fc8065efd94236:

  ARM: realview: enable USB storage in the defconfig (2016-02-09 10:39:38 +0100)

----------------------------------------------------------------
This makes the RealView defconfig select SMP on UP
so we only need one defconfig for RealView, then adds
USB mass storage configuration.

----------------------------------------------------------------
Linus Walleij (3):
      ARM: realview: activate SMP on the default defconfig
      ARM: realview: delete realview-smp_defconfig
      ARM: realview: enable USB storage in the defconfig

 arch/arm/configs/realview-smp_defconfig | 105 --------------------------------
 arch/arm/configs/realview_defconfig     |   5 ++
 2 files changed, 5 insertions(+), 105 deletions(-)
 delete mode 100644 arch/arm/configs/realview-smp_defconfig


From daniel at ffwll.ch  Tue Feb  9 01:50:47 2016
From: daniel at ffwll.ch (Daniel Vetter)
Date: Tue, 9 Feb 2016 10:50:47 +0100
Subject: [PATCH v2] drm: Clean up drm Makefile
In-Reply-To: <1454641830-19307-1-git-send-email-xinliang.liu@linaro.org>
References: <1454641830-19307-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <20160209095047.GK11240@phenom.ffwll.local>

On Fri, Feb 05, 2016 at 11:10:30AM +0800, Xinliang Liu wrote:
> This patch cleans up the Makefile of drm root directory.
> Make core and device drivers configuration list sorted Alphabetically.
> 
> Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
> Reviewed-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
> Reviewed-by: Yifan Liu <liu_fanyi at 163.com>
> ---
>  drivers/gpu/drm/Makefile | 102 ++++++++++++++++++++++++-----------------------
>  1 file changed, 52 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 61766dec6a8d..23e57948f68f 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -2,6 +2,9 @@
>  # Makefile for the drm device driver.  This driver provides support for the
>  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>  
> +CFLAGS_drm_trace_points.o := -I$(src)
> +
> +# core. Please keep this list sorted alphabetically
>  drm-y       :=	drm_auth.o drm_bufs.o drm_cache.o \
>  		drm_context.o drm_dma.o \
>  		drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
> @@ -13,64 +16,63 @@ drm-y       :=	drm_auth.o drm_bufs.o drm_cache.o \
>  		drm_trace_points.o drm_global.o drm_prime.o \
>  		drm_rect.o drm_vma_manager.o drm_flip_work.o \
>  		drm_modeset_lock.o drm_atomic.o drm_bridge.o
> -
> -drm-$(CONFIG_COMPAT) += drm_ioc32.o
> -drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
>  drm-$(CONFIG_PCI) += ati_pcigart.o
> -drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> -drm-$(CONFIG_OF) += drm_of.o
>  drm-$(CONFIG_AGP) += drm_agpsupport.o
> +drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
> +drm-$(CONFIG_COMPAT) += drm_ioc32.o
> +drm-$(CONFIG_OF) += drm_of.o
> +drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> +obj-$(CONFIG_DRM)	+= drm.o
> +
> +obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
>  
>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
>  		drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
>  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> -drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
>  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
> -
> +drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
>  obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
>  
> -CFLAGS_drm_trace_points.o := -I$(src)
> +obj-$(CONFIG_DRM_TTM) += ttm/
>  
> -obj-$(CONFIG_DRM)	+= drm.o
> -obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
> -obj-$(CONFIG_DRM_TTM)	+= ttm/
> -obj-$(CONFIG_DRM_TDFX)	+= tdfx/
> -obj-$(CONFIG_DRM_R128)	+= r128/
> -obj-$(CONFIG_HSA_AMD) += amd/amdkfd/
> -obj-$(CONFIG_DRM_RADEON)+= radeon/
> -obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
> -obj-$(CONFIG_DRM_MGA)	+= mga/
> -obj-$(CONFIG_DRM_I810)	+= i810/
> -obj-$(CONFIG_DRM_I915)  += i915/
> -obj-$(CONFIG_DRM_MGAG200) += mgag200/
> -obj-$(CONFIG_DRM_VC4)  += vc4/
> -obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
> -obj-$(CONFIG_DRM_SIS)   += sis/
> -obj-$(CONFIG_DRM_SAVAGE)+= savage/
> -obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
> -obj-$(CONFIG_DRM_VIA)	+=via/
> -obj-$(CONFIG_DRM_VGEM)	+= vgem/
> -obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
> -obj-$(CONFIG_DRM_EXYNOS) +=exynos/
> -obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
> -obj-$(CONFIG_DRM_GMA500) += gma500/
> -obj-$(CONFIG_DRM_UDL) += udl/
> -obj-$(CONFIG_DRM_AST) += ast/
> -obj-$(CONFIG_DRM_ARMADA) += armada/
> +# device drivers. Please keep this list sorted alphabetically
> +obj-$(CONFIG_HSA_AMD)		+= amd/amdkfd/

No mention of this exception (needs a comment), and no mention of what you
changed in v2 of the patch. Please fix and resend.
-Daniel

> +obj-$(CONFIG_DRM_AMDGPU)	+= amd/amdgpu/
> +obj-$(CONFIG_DRM_ARMADA)	+= armada/
> +obj-$(CONFIG_DRM_AST)		+= ast/
>  obj-$(CONFIG_DRM_ATMEL_HLCDC)	+= atmel-hlcdc/
> -obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
> -obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
> -obj-y			+= omapdrm/
> -obj-y			+= tilcdc/
> -obj-$(CONFIG_DRM_QXL) += qxl/
> -obj-$(CONFIG_DRM_BOCHS) += bochs/
> -obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio/
> -obj-$(CONFIG_DRM_MSM) += msm/
> -obj-$(CONFIG_DRM_TEGRA) += tegra/
> -obj-$(CONFIG_DRM_STI) += sti/
> -obj-$(CONFIG_DRM_IMX) += imx/
> -obj-y			+= i2c/
> -obj-y			+= panel/
> -obj-y			+= bridge/
> -obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
> -obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
> +obj-$(CONFIG_DRM_BOCHS)		+= bochs/
> +obj-y				+= bridge/
> +obj-$(CONFIG_DRM_CIRRUS_QEMU)	+= cirrus/
> +obj-$(CONFIG_DRM_ETNAVIV)	+= etnaviv/
> +obj-$(CONFIG_DRM_EXYNOS)	+= exynos/
> +obj-$(CONFIG_DRM_FSL_DCU)	+= fsl-dcu/
> +obj-$(CONFIG_DRM_GMA500)	+= gma500/
> +obj-y				+= i2c/
> +obj-$(CONFIG_DRM_I810)		+= i810/
> +obj-$(CONFIG_DRM_I915)		+= i915/
> +obj-$(CONFIG_DRM_IMX)		+= imx/
> +obj-$(CONFIG_DRM_MGA)		+= mga/
> +obj-$(CONFIG_DRM_MGAG200)	+= mgag200/
> +obj-$(CONFIG_DRM_MSM)		+= msm/
> +obj-$(CONFIG_DRM_NOUVEAU)	+= nouveau/
> +obj-y				+= omapdrm/
> +obj-y				+= panel/
> +obj-$(CONFIG_DRM_QXL)		+= qxl/
> +obj-$(CONFIG_DRM_R128)		+= r128/
> +obj-$(CONFIG_DRM_RADEON)	+= radeon/
> +obj-$(CONFIG_DRM_RCAR_DU)	+= rcar-du/
> +obj-$(CONFIG_DRM_ROCKCHIP)	+= rockchip/
> +obj-$(CONFIG_DRM_SAVAGE)	+= savage/
> +obj-$(CONFIG_DRM_SHMOBILE)	+= shmobile/
> +obj-$(CONFIG_DRM_SIS)		+= sis/
> +obj-$(CONFIG_DRM_STI)		+= sti/
> +obj-$(CONFIG_DRM_TDFX)		+= tdfx/
> +obj-$(CONFIG_DRM_TEGRA)		+= tegra/
> +obj-y				+= tilcdc/
> +obj-$(CONFIG_DRM_UDL)		+= udl/
> +obj-$(CONFIG_DRM_VC4)		+= vc4/
> +obj-$(CONFIG_DRM_VGEM)		+= vgem/
> +obj-$(CONFIG_DRM_VIA)		+= via/
> +obj-$(CONFIG_DRM_VIRTIO_GPU)	+= virtio/
> +obj-$(CONFIG_DRM_VMWGFX)	+= vmwgfx/
> -- 
> 1.9.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From hdegoede at redhat.com  Tue Feb  9 01:51:03 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Tue, 9 Feb 2016 10:51:03 +0100
Subject: [linux-sunxi][PATCH v2] ARM: dts: sun7i: Enable USB DRC on Olimex
 A20 EVB
In-Reply-To: <1455010408-27896-1-git-send-email-codekipper@gmail.com>
References: <1455010408-27896-1-git-send-email-codekipper@gmail.com>
Message-ID: <56B9B687.4070800@redhat.com>

Hi,

On 09-02-16 10:33, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
>
> Enable the otg/drc usb controller on the Olimex A20 EVB.
>
> Signed-off-by: Marcus Cooper <codekipper at gmail.com>
> ---
> Changes since v1:
> - Added vbus0 regulator and vbus0 detection to dts

Thanks patch looks good to me:

Reviewed-by: Hans de Goede <hdegoede at redhat.com>

Regards,

Hans


 >



>
> ---
>   arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 32 ++++++++++++++++++++++++++
>   1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> index c3c626b..23aacce 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> @@ -198,6 +198,10 @@
>   	status = "okay";
>   };
>
> +&otg_sram {
> +	status = "okay";
> +};
> +
>   &pio {
>   	ahci_pwr_pin_olimex_som_evb: ahci_pwr_pin at 1 {
>   		allwinner,pins = "PC3";
> @@ -219,6 +223,20 @@
>   		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>   		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
>   	};
> +
> +	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
> +		allwinner,pins = "PH4";
> +		allwinner,function = "gpio_in";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +	};
> +
> +	usb0_vbus_detect_pin: usb0_vbus_detect_pin at 0 {
> +		allwinner,pins = "PH5";
> +		allwinner,function = "gpio_in";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +	};
>   };
>
>   &reg_ahci_5v {
> @@ -254,6 +272,10 @@
>   	regulator-name = "avcc";
>   };
>
> +&reg_usb0_vbus {
> +	status = "okay";
> +};
> +
>   &reg_usb1_vbus {
>   	status = "okay";
>   };
> @@ -268,7 +290,17 @@
>   	status = "okay";
>   };
>
> +&usb_otg {
> +	dr_mode = "otg";
> +	status = "okay";
> +};
> +
>   &usbphy {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
> +	usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH04 */
> +	usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH05 */
> +	usb0_vbus-supply = <&reg_usb0_vbus>;
>   	usb1_vbus-supply = <&reg_usb1_vbus>;
>   	usb2_vbus-supply = <&reg_usb2_vbus>;
>   	status = "okay";
>


From davem at davemloft.net  Tue Feb  9 01:52:14 2016
From: davem at davemloft.net (David Miller)
Date: Tue, 09 Feb 2016 04:52:14 -0500 (EST)
Subject: [PATCH 0/4] Add Ethernet support on STM32F429
In-Reply-To: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
References: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <20160209.045214.805916119264070573.davem@davemloft.net>

From: Alexandre TORGUE <alexandre.torgue at gmail.com>
Date: Wed,  3 Feb 2016 15:54:31 +0100

> STM32F429 Chip embeds a Synopsys 3.50a MAC IP.
> This series:
> 	-enhance current stmmac driver to control it (code already available) and 
> 	 adds basic glue for STM32F429 chip.
> 	-Enable basic Net config in kernel.
> 
> Note that DT patches are not present because STM32 pinctrl code is not
> yet avalaible.

Looks like this needs to be respun to deal with the warnings the kbuild
robot reported.

Thanks.


From linus.walleij at linaro.org  Tue Feb  9 01:53:01 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Feb 2016 10:53:01 +0100
Subject: [PATCH 1/2] pinctrl: stm32: Remove dependency with DT bindings
 header files
In-Reply-To: <1454954259-4923-2-git-send-email-mcoquelin.stm32@gmail.com>
References: <1454954259-4923-1-git-send-email-mcoquelin.stm32@gmail.com>
 <1454954259-4923-2-git-send-email-mcoquelin.stm32@gmail.com>
Message-ID: <CACRpkdb+V8O8H1gjkWwgqSimFtgJ2rFnwdY0sCChEjFSCkOO8w@mail.gmail.com>

On Mon, Feb 8, 2016 at 6:57 PM, Maxime Coquelin
<mcoquelin.stm32 at gmail.com> wrote:

> Some macros where defined in DT bindings headers, whereas only used
> in the driver.
>
> This patch moves these macros to the driver side.
>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>

Patch applied.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Tue Feb  9 01:53:57 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 9 Feb 2016 10:53:57 +0100
Subject: [PATCH 2/2] pinctrl: stm32: Fix compile testing selection
In-Reply-To: <1454954259-4923-3-git-send-email-mcoquelin.stm32@gmail.com>
References: <1454954259-4923-1-git-send-email-mcoquelin.stm32@gmail.com>
 <1454954259-4923-3-git-send-email-mcoquelin.stm32@gmail.com>
Message-ID: <CACRpkdb87qRD9OofJgkLUvMmcQSqXcu6xFsP7X7ztPueSKzPhw@mail.gmail.com>

On Mon, Feb 8, 2016 at 6:57 PM, Maxime Coquelin
<mcoquelin.stm32 at gmail.com> wrote:

> While selecting the driver for compile testing seemed possible,
> the driver was not compiled because the driver directory was only
> added if ARCH_STM32 was selected.
>
> This patch now makes the pinctrl Makefile to add stm32 directory if
> PINCTRL_STM32 is selected.
>
> Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>

Patch applied.

Yours,
Linus Walleij


From manabian at gmail.com  Tue Feb  9 02:02:01 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Tue, 9 Feb 2016 11:02:01 +0100
Subject: [PATCH 1/2] clocksource/drivers/lpc32xx: Support periodic mode
In-Reply-To: <CAAEAJfBO5jARMZyu62ccRWjA_A69qfBfHBcWncYbqOdPkYqSMQ@mail.gmail.com>
References: <1454136379-7517-1-git-send-email-ezequiel@vanguardiasur.com.ar>
 <CAGhQ9VxO7Rsus8Js_oZDBxWzEHuUHnRyoVTVmawbtXmK7tNMcw@mail.gmail.com>
 <CAAEAJfAVTJm-PzhjkRmkdNG39sH7eHyEXaSX4q0=TCQ0468Heg@mail.gmail.com>
 <CAAEAJfD8LUV=t97RN3U4uqgzCLP89AQtHqBccKGd6-EskP9DOQ@mail.gmail.com>
 <CAGhQ9VxtqkW4PLrpQWsyZu9bgB_98mmO=WZ7gvaeN_DWQ5M3rg@mail.gmail.com>
 <CAAEAJfBO5jARMZyu62ccRWjA_A69qfBfHBcWncYbqOdPkYqSMQ@mail.gmail.com>
Message-ID: <CAGhQ9VyAtJMN70Zh6gHhUCvfzUVRYn17wOg=D4kcbZ4dWQLG3g@mail.gmail.com>

Hi Ezequiel,

On 3 February 2016 at 17:03, Ezequiel Garcia
<ezequiel at vanguardiasur.com.ar> wrote:
> Hi Joachim,
>
> (Ccing Vladimir)
>
> On 1 February 2016 at 18:55, Joachim  Eastwood <manabian at gmail.com> wrote:
>> On 1 February 2016 at 16:09, Ezequiel Garcia
>> <ezequiel at vanguardiasur.com.ar> wrote:
>>> On 31 January 2016 at 17:07, Ezequiel Garcia
>>> <ezequiel at vanguardiasur.com.ar> wrote:
>>>> On 30 January 2016 at 16:39, Joachim  Eastwood <manabian at gmail.com> wrote:
>>>>> Hi Ezequiel,
>>>>>
>>>>> On 30 January 2016 at 07:46, Ezequiel Garcia
>>>>> <ezequiel at vanguardiasur.com.ar> wrote:
>>>>>> This commit adds the support for periodic mode. This is done by not
>>>>>> setting the MR0S (Stop on TnMR0) bit on MCR, thus allowing
>>>>>> interrupts to be periodically generated on MR0 matches.
>>>>>>
>>>>>> In order to do this, move the initial configuration that is specific to
>>>>>> the one shot mode to clock_event_device.set_state_oneshot.
>>>>>>
>>> [...]
>>>>
>>>>>
>>>>> I will look more closely at the new timer setup later.
>>>>>
>>>>> btw, didn't I look through a version of this you sent me privately
>>>>> quite some time ago?
>>>>> I think I had a comment about using TIMER_PR instead of TIMER_MR0
>>>>> then. Unsure if that is still valid, though.
>>>>>
>>>>
>>>> Ah, right. It was ages ago, and forgot your previous review. Sorry about that.
>>>> Using TIMER_PR looks less invasive so I'll send a v2 using it instead.
>>>
>>> Actually, using the prescale counter and MR0 = 1 resulted in exactly
>>> half the number of interrupts that I expected (HZ / 2). Using this
>>> patch, with PR=0 and MR0=ticks_per_jiggies, I can see HZ no. of
>>> interrupts per sec.
>>>
>>> Why did you choose to use the prescale in your oneshot implementation?
>>
>> The clockevent code was copied from arch/arm/mach-lpc32xx/timer.c so
>> it's really old code.
>> I think it is a strange way to use the timer, but the logic still
>> seems good to me.
>>
>>> Did you test or measure the timer expire using the PR and MR0 = 1?
>>
>> I really can't remember. I do remember going through the timer setup
>> and it seemed like a valid, albeit slightly strange, way to use the
>> timer.
>>
>>> To be honest, I'm still trying to make some sense out of my results.
>>
>> I'll see if can find the time to do some more testing over here as well.
>>

Sorry for the late reply.

> I wrote a small test driver to toggle a GPIO on a timer event.
> One-shot usage of the timers results in the same measurements
> with either implementation.
>
> In other words, when triggering a one-shot timer (MCR_MR0S is set),
> I get the same results using the prescale counter (PR=ticks, MR0=1)
> or the timer counter (PR=0, MR0=ticks).
>
> Here's the branch in case you want to play with it:
> http://git.infradead.org/users/ezequielg/linux/shortlog/refs/heads/misc_timer_test
>
> My logic analyzer is quite crappy, but it was clear that one-shot timers
> expired correctly at the configured time, with either implementation.

Ok. That is a good thing.

> However, when configuring the timer in periodic mode (MCR_MR0S
> is cleared), the result is always ~twice the programmed value
> (as if it takes two TC cycles to complete one event).
>
> Hence, it seems the prescale counter is not suitable for periodic mode.

I see.

> How about we change the current oneshot implementation
> to not use the prescale counter at all, and so when the periodic
> mode is introduced it'll be consistent with oneshot?

Makes sense to me. I think using the match registers will make the
timer setup easier to follow too.


Hopefully Vladimir can give it a test on LPC32xx also. But afaik the
timer IP should be exactly the same.


regards,
Joachim Eastwood


From ard.biesheuvel at linaro.org  Tue Feb  9 02:03:01 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 9 Feb 2016 11:03:01 +0100
Subject: [PATCH] arm64: allow the module region to be randomized
 independently
In-Reply-To: <20160208181305.GW6076@e104818-lin.cambridge.arm.com>
References: <CAGXu5j+1rcScYedzQ5o0aaGZJWPCBGk-gai0D8jY8Huc-VuG7A@mail.gmail.com>
 <1454926332-25929-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160208181305.GW6076@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu-vxhJRUMK7sqv1saw+wkQRD5xFydpgTLbKgWhoNj5LmA@mail.gmail.com>

On 8 February 2016 at 19:13, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 08, 2016 at 11:12:12AM +0100, Ard Biesheuvel wrote:
>> This adds the option to randomize the module region independently from the
>> core kernel, and enables it by default. This makes it less likely that the
>> location of core kernel data structures can be determined by an adversary,
>> but causes all function calls from modules into the core kernel to be
>> resolved via entries in the module PLTs.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> ---
>>  arch/arm64/Kconfig              | 15 ++++++++
>>  arch/arm64/include/asm/module.h |  6 ++++
>>  arch/arm64/kernel/kaslr.c       | 36 +++++++++++++++-----
>>  arch/arm64/kernel/module.c      |  9 ++---
>>  4 files changed, 50 insertions(+), 16 deletions(-)
>
> With this patch I get an unhandled paging request, coming from
> kernel/module.c:2982 (the memset). The PC is wrongly attributed but it's
> in arch/arm64/lib/memset.S:
>

This was due to a thinko in kaslr_early_init(). Folding the following
hunk will fix it (or I can resend the patch if you prefer)

-------8<----------
diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index f8ad30160026..d7eba99ab140 100644
--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@ -82,6 +82,12 @@ u64 __init kaslr_early_init(u64 dt_phys)
        int size;

        /*
+        * Set a reasonable default for module_alloc_base in case
+        * we end up running with KASLR disabled.
+        */
+       module_alloc_base = (u64)_etext - MODULES_VSIZE;
+
+       /*
         * Try to map the FDT early. If this fails, we simply bail,
         * and proceed with KASLR disabled. We will make another
         * attempt at mapping the FDT in setup_machine()
-------8<----------


From gregory.clement at free-electrons.com  Tue Feb  9 02:04:00 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 09 Feb 2016 11:04:00 +0100
Subject: [GIT PULL] ARM: mvebu: dt for v4.6 (#1)
In-Reply-To: <20160208215903.GO25468@localhost> (Olof Johansson's message of
 "Mon, 8 Feb 2016 13:59:03 -0800")
References: <8737t32saq.fsf@free-electrons.com>
 <20160208215903.GO25468@localhost>
Message-ID: <87vb5yyzcf.fsf@free-electrons.com>

Hi Olof,
 
 On lun., f?vr. 08 2016, Olof Johansson <olof at lixom.net> wrote:

> Hi,
>
> On Mon, Feb 08, 2016 at 03:25:01PM +0100, Gregory CLEMENT wrote:
>> Hi,
>> 
>> Here is the first pull request for dt for mvebu for v4.6.
>> This one is based on v4.5-rc3 because it depends on fixes merged
>> previously.
>> 
>> Gregory
>> 
>> The following changes since commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95:
>> 
>>   Linux 4.5-rc3 (2016-02-07 15:38:30 -0800)
>> 
>> are available in the git repository at:
>> 
>>   git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-4.6-1
>> 
>> for you to fetch changes up to ebe1adff92de94f1ec48a46d9afa74ba967674dc:
>> 
>>   ARM: dts: kirkwood: add device tree for buffalo linkstation ls-qvl (2016-02-08 09:39:41 +0100)
>> 
>> ----------------------------------------------------------------
>> mvebu dt for 4.6 (part 1)
>> 
>> - Improve Armada 388 device tree (SATA and XHCI)
>> - Fix SD Card and audio support for OpenRD board
>> - Provide template for RS-232/485 configuration for the same board
>> - Use a common dtsi file for linkstation boards
>> - Add support for Buffalo Linkstation LS-QVL
>> 
>> ----------------------------------------------------------------
>> Aaro Koskinen (4):
>>       ARM: DTS: kirkwood-openrd: fix pin names for UART/SD selection
>>       ARM: DTS: kirkwood-openrd: fix SD slot default configuration
>>       ARM: DTS: kirkwood-openrd: provide template for RS-232/485 configuration
>>       ARM: DTS: kirkwood-openrd-client: fix audio
>> 
>> Gregory CLEMENT (2):
>>       ARM: mvebu: use usb-nop-xceiv PHY for the xhci nodes on Armada 388 GP
>>       ARM: mvebu: Update the mpp63 function in the device tree on Armada 370
>> 
>> Mario Lange (1):
>>       ARM: dts: kirkwood: add device tree for buffalo linkstation ls-qvl
>> 
>> Roger Shimizu (3):
>>       ARM: dts: kirkwood: relicense dts of ls-wvl/vl and ls-wxl/wsxl under GPLv2/X11
>>       ARM: dts: kirkwood: split lswxl dts to linkstation lswsxl and lswxl
>>       ARM: dts: kirkwood: split lswvl dts to linkstation lsvl and lswvl
>> 
>> Thomas Petazzoni (2):
>>       ARM: mvebu: adjust board name and compatible for Armada 388 GP
>>       ARM: mvebu: use regulator-boot-on for SATA regulators on Armada 388 GP
>
> You're using three different kind of ways to label the patches here, please use
> the common one that we try to keep consistent across platforms:
>
> ARM: dts: <platform>:...
>
> Can you fixup and send a fresh pull request, please?

Yes a second version is coming.

Gregory

>
>
> Thanks!
>
>
> -Olof

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From gregory.clement at free-electrons.com  Tue Feb  9 02:04:49 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 09 Feb 2016 11:04:49 +0100
Subject: [GIT PULL v2] ARM: mvebu: dt for v4.6 (#1)
Message-ID: <87twliyzb2.fsf@free-electrons.com>

Hi,

Here is the second version of the first pull request for dt for mvebu
for v4.6.  This one is based on v4.5-rc3 because it depends on fixes
merged previously.

As requested by Olof, I aligned the commit title.

Gregory

The following changes since commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95:

  Linux 4.5-rc3 (2016-02-07 15:38:30 -0800)

are available in the git repository at:

  git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-4.6-1

for you to fetch changes up to 5dda254d0cc5cbdcc81dbce0985c35b68dd5e3b1:

  ARM: dts: kirkwood: add device tree for buffalo linkstation ls-qvl (2016-02-09 11:00:26 +0100)

----------------------------------------------------------------
mvebu dt for 4.6 (part 1)

- Improve Armada 38x device tree (SATA and XHCI)
- Fix SD Card and audio support for OpenRD board
- Provide template for RS-232/485 configuration for the same board
- Use a common dtsi file for linkstation boards
- Add support for Buffalo Linkstation LS-QVL

----------------------------------------------------------------
Aaro Koskinen (4):
      ARM: dts: kirkwood: fix pin names for UART/SD selection for OpenRD
      ARM: dts: kirkwood: fix SD slot default configuration for OpenRD
      ARM: dts: kirkwood: provide template for RS-232/485 configuration for OpenRD
      ARM: dts: kirkwood: fix audio for OpenRD clients

Gregory CLEMENT (2):
      ARM: dts: armada-38x: use usb-nop-xceiv PHY for the xhci nodes on Armada 388 GP
      ARM: dts: armada-370: Update the mpp63 function in the device tree on Armada 370

Mario Lange (1):
      ARM: dts: kirkwood: add device tree for buffalo linkstation ls-qvl

Roger Shimizu (3):
      ARM: dts: kirkwood: relicense dts of ls-wvl/vl and ls-wxl/wsxl under GPLv2/X11
      ARM: dts: kirkwood: split lswxl dts to linkstation lswsxl and lswxl
      ARM: dts: kirkwood: split lswvl dts to linkstation lsvl and lswvl

Thomas Petazzoni (2):
      ARM: dts: armada-38x: adjust board name and compatible for Armada 388 GP
      ARM: dts: armada-38x: use regulator-boot-on for SATA regulators on Armada 388 GP

 .../devicetree/bindings/arm/marvell,kirkwood.txt   |   7 +-
 .../pinctrl/marvell,armada-370-pinctrl.txt         |   5 +-
 arch/arm/boot/dts/Makefile                         |   7 +-
 arch/arm/boot/dts/armada-370-mirabox.dts           |   2 +-
 arch/arm/boot/dts/armada-370-netgear-rn104.dts     |   2 +-
 arch/arm/boot/dts/armada-370-synology-ds213j.dts   |   2 +-
 arch/arm/boot/dts/armada-388-gp.dts                |  36 +--
 arch/arm/boot/dts/kirkwood-linkstation-6282.dtsi   | 192 +++++++++++++
 .../boot/dts/kirkwood-linkstation-duo-6281.dtsi    | 186 +++++++++++++
 arch/arm/boot/dts/kirkwood-linkstation-lsqvl.dts   | 135 +++++++++
 arch/arm/boot/dts/kirkwood-linkstation-lsvl.dts    |  57 ++++
 arch/arm/boot/dts/kirkwood-linkstation-lswsxl.dts  |  57 ++++
 arch/arm/boot/dts/kirkwood-linkstation-lswvl.dts   | 112 ++++++++
 arch/arm/boot/dts/kirkwood-linkstation-lswxl.dts   | 116 ++++++++
 arch/arm/boot/dts/kirkwood-linkstation.dtsi        | 202 ++++++++++++++
 arch/arm/boot/dts/kirkwood-lswvl.dts               | 302 ---------------------
 arch/arm/boot/dts/kirkwood-lswxl.dts               | 302 ---------------------
 arch/arm/boot/dts/kirkwood-openrd-client.dts       |   6 +-
 arch/arm/boot/dts/kirkwood-openrd.dtsi             |  41 ++-
 arch/arm/boot/dts/kirkwood.dtsi                    |   2 +-
 20 files changed, 1137 insertions(+), 634 deletions(-)
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation-6282.dtsi
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation-duo-6281.dtsi
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation-lsqvl.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation-lsvl.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation-lswsxl.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation-lswvl.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation-lswxl.dts
 create mode 100644 arch/arm/boot/dts/kirkwood-linkstation.dtsi
 delete mode 100644 arch/arm/boot/dts/kirkwood-lswvl.dts
 delete mode 100644 arch/arm/boot/dts/kirkwood-lswxl.dts


From tsahee at annapurnalabs.com  Tue Feb  9 02:13:04 2016
From: tsahee at annapurnalabs.com (Tsahee Zidenberg)
Date: Tue, 9 Feb 2016 12:13:04 +0200
Subject: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <56B9B1B5.5070106@arm.com>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
 <56B8B45D.1020902@arm.com> <20160209085633.GA5388@kwain>
 <20160209090131.GB5388@kwain> <56B9ACE2.1060200@arm.com>
 <CABM=7knaepbyy4nw_GczVM7E_t6py7gG0ERs8ru_AYoVXvAQ+A@mail.gmail.com>
 <56B9B1B5.5070106@arm.com>
Message-ID: <CABM=7k=-Y+eFB2nUMfMjd3saTSNDsEyfHyYNf-ef8qQc5jCsxA@mail.gmail.com>

On 9 February 2016 at 11:30, Marc Zyngier <marc.zyngier at arm.com> wrote:
>
> On 09/02/16 09:14, Tsahee Zidenberg wrote:
> >
> >
> > On 9 February 2016 at 11:09, Marc Zyngier <marc.zyngier at arm.com
> > <mailto:marc.zyngier at arm.com>> wrote:
> >
> >     On 09/02/16 09:01, Antoine Tenart wrote:
> >     > On Tue, Feb 09, 2016 at 09:56:33AM +0100, Antoine Tenart wrote:
> >     >> Hi Marc,
> >     >>
> >     >> On Mon, Feb 08, 2016 at 03:29:33PM +0000, Marc Zyngier wrote:
> >     >>> On 08/02/16 09:11, Antoine Tenart wrote:
> >     >>>
> >     >>>> +          gic: gic at f0100000 {
> >     >>>> +                  compatible = "arm,gic-v3";
> >     >>>> +                  reg = <0x0 0xf0200000 0x0 0x10000>,     /* GIC Dist */
> >     >>>> +                        <0x0 0xf0280000 0x0 0x200000>,    /* GICR */
> >     >>>> +                        <0x0 0xf0100000 0x0 0x2000>;      /* GICC */
> >     >>>> +                  interrupt-controller;
> >     >>>> +                  #interrupt-cells = <3>;
> >     >>>> +          };
> >     >>>
> >     >>> Something is wrong here. Either you are missing GICH and GICV (assuming
> >     >>> you have legacy support), or you have an extra GICC region (which
> >     >>> doesn't make sense on its own).
> >     >>
> >     >> I'll add the missing regions.
> >     >
> >     > Hmm, in fact the GICC region shouldn't be there. I'll make some tests
> >     > and remove it.
> >
> >     If you have a GICv3 with legacy support, you will probably have GICC,
> >     GICH and GICV. Linux itself will only use GICD and GICR, but it needs at
> >     least GICV to be able to virtualize GICv2 guests. And GICV is not
> >     allowed to exist without GICC and GICH, so I really recommend that you
> >     keep GICC around.
> >
> >
> > We use the GIC without legacy support (we disable it in early boot
> > stages), so I think removing the GICC region is the better solution.
>
> Disabling legacy support doesn't mean that:
> - the HW isn't present
> - the associated regions are not useful
>
By "disabling lecgacy support in early boot" I don't just mean that
ARE bit will be set, but it will actually be RAO/WI. There will be no
way for SW to enable it and use these registers (which, sadly, means
that there will be no way to enable gicv2 virtualization). If you
insist - I will dig up the supposed location of GICV and GICH - yet it
will be both untested and entirely unusable.

We will add an entry for the maintenance interrupt, as it really can
be used by future configurations.

> Here, we describe the HW, not the usage you make of it.
>
> And unless you think that having working virtualization is completely
> useless, I strongly suggest that you properly document the HW in the
> device tree.
>
> Thanks,
>
>         M.
> --
> Jazz is not dead. It just smells funny...


From slash.tmp at free.fr  Tue Feb  9 02:17:48 2016
From: slash.tmp at free.fr (Mason)
Date: Tue, 9 Feb 2016 11:17:48 +0100
Subject: [PATCH RFC] Add cpufreq support
In-Reply-To: <7910928.pmJjZiV1Lk@wuerfel>
References: <56B4D4BE.2040008@free.fr> <22002072.L04zy0K2AP@wuerfel>
 <20160208131625.GI8294@vireshk> <7910928.pmJjZiV1Lk@wuerfel>
Message-ID: <56B9BCCC.8060404@free.fr>

On 08/02/2016 14:45, Arnd Bergmann wrote:

> That's why I said we could introduce a 'v3' with the meaning
> it should have had to start with: compatible means actually
> compatible with the driver.

If I understand correctly, something needs to change in the
framework before I can push cpufreq support for my platform
upstream, correct?

Could you CC me if anything happens on that front?

In my local 4.4 branch, I think I should use whatever method
was recommended at the time.

Was that to define the platform's init_late method, and call
platform_device_register_simple from there? (Could you take
a quick glance at the patch, and see if it is acceptable in
the context of kernel 4.4?)

Regards.



From antoine.tenart at free-electrons.com  Tue Feb  9 02:18:33 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Tue, 9 Feb 2016 11:18:33 +0100
Subject: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <2530828.WgKqLzsO0l@wuerfel>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
 <2530828.WgKqLzsO0l@wuerfel>
Message-ID: <20160209101833.GD5388@kwain>

Hello Arnd,

On Mon, Feb 08, 2016 at 01:20:40PM +0100, Arnd Bergmann wrote:
> On Monday 08 February 2016 10:11:38 Antoine Tenart wrote:
> > index 000000000000..3e3080fa45e4
> > --- /dev/null
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > +/ {
> > +	model = "Annapurna Labs Alpine v2";
> > +	compatible = "al,alpine-v2";
> > +	#address-cells = <2>;
> > +	#size-cells = <2>;
> > +
> > +	aliases {
> > +		serial0 = &uart0;
> > +		serial1 = &uart1;
> > +		serial2 = &uart2;
> > +		serial3 = &uart3;
> > +	};
> 
> Move the aliases to the .dts files and drop the ones that are disabled.

Sure.

> > +
> > +		pcie-internal at 0xfbc00000 {
> 
> make this
> 
> 		pci at fbc00000 {

Will do.

> 
> > +			compatible = "pci-host-ecam-generic";
> > +			device_type = "pci";
> > +			#size-cells = <2>;
> > +			#address-cells = <3>;
> > +			#interrupt-cells = <1>;
> > +			reg = <0x0 0xfbc00000 0x0 0x100000>;
> > +			interrupt-map-mask = <0xf800 0 0 7>;
> > +			/* add legacy interrupts for SATA only */
> > +			interrupt-map = <0x4000 0 0 1 &gic 0 53 4>,
> > +					<0x4800 0 0 1 &gic 0 54 4>;
> 
> What's wrong with the other IRQs? Not connected?

From what I know the other IRQs are disconnected.

> > +
> > +		uart0: uart at fd883000 {
> 
> 			serial at fd883000
> 
> 
> Almost all devices are in the 0xfd000000 range. Could this be a bus in the
> SoC that has all the devices attached to it? Maybe use a "ranges" property
> to reflect that. In doubt, use the register numbers from the data sheet if you
> have one.

I'll try using a range property in the v2 of the series.

Thanks for the review!

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/4136e467/attachment.sig>

From lee.jones at linaro.org  Tue Feb  9 02:18:39 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 9 Feb 2016 10:18:39 +0000
Subject: [PATCH 02/11] mfd: axp20x: Add bindings for AXP809 PMIC
In-Reply-To: <20160202224348.GA15250@rob-hp-laptop>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-3-git-send-email-wens@csie.org>
 <20160202224348.GA15250@rob-hp-laptop>
Message-ID: <20160209101839.GA24522@x1>

On Tue, 02 Feb 2016, Rob Herring wrote:

> On Tue, Feb 02, 2016 at 06:27:35PM +0800, Chen-Yu Tsai wrote:
> > This patch adds the basic and regulator bindings for the X-Powers AXP809
> > PMIC.
> > 
> > Also update the DC-DC converter operating frequency for AXP22X/AXP80X.
> > 
> > Signed-off-by: Chen-Yu Tsai <wens at csie.org>
> > ---
> >  Documentation/devicetree/bindings/mfd/axp20x.txt | 31 ++++++++++++++++++++++--
> >  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> Acked-by: Rob Herring <robh at kernel.org>

No idea what's going on here.  Somehow I must have been in the
Reply-To, but never actually sent the patches initially.  So I have
people's replies, but not the original submission.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From manabian at gmail.com  Tue Feb  9 02:19:57 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Tue, 9 Feb 2016 11:19:57 +0100
Subject: [PATCH 0/2] CREG clk driver for NXP LPC18xx family
In-Reply-To: <20160208222637.GV4848@codeaurora.org>
References: <1436651307-24098-1-git-send-email-manabian@gmail.com>
 <20160208222637.GV4848@codeaurora.org>
Message-ID: <CAGhQ9Vy14XR+-kgACiqPgs0SPueizD6Gd2q5kaNqM5mGna0V=g@mail.gmail.com>

Hi Stephen,

On 8 February 2016 at 23:26, Stephen Boyd <sboyd at codeaurora.org> wrote:
> On 07/11, Joachim Eastwood wrote:
>> This patch set adds a clk driver for the low power clocks found in
>> the CREG block on lpc18xx. CREG is a collection of miscellaneous
>> configuration registers that can be accessed through a syscon
>> regmap interface. The clk driver makes it possible to setup and
>> enabled these two clocks.
>>
>> This need to support peripherals like the internal RTC on the
>> lpc18xx platform.
>>
>
> I know this is many months old, but is this driver still
> required? I can apply it to clk-next if so.

It is still needed for the internal RTC (rtc-lpc24xx) on lpc18xx. The
RTC uses a 1 kHz clock that is controlled in CREG (misc system regs).

Note; if you apply it you will most likely get a very trivial conflict
in drivers/clk/nxp/Makefile because clk-lpc32xx.c has been added since
these patches was sent.


regards,
Joachim Eastwood


From georgi.djakov at linaro.org  Tue Feb  9 02:19:45 2016
From: georgi.djakov at linaro.org (Georgi Djakov)
Date: Tue,  9 Feb 2016 12:19:45 +0200
Subject: [PATCH v2] arm64: defconfig: Add Qualcomm sdhci and restart
 functionality
Message-ID: <1455013185-946-1-git-send-email-georgi.djakov@linaro.org>

Enable sdhci and restart functionality for devices based on msm8916 platform.
Also increase the number of minors per block device to detect all available
partitions.

Signed-off-by: Georgi Djakov <georgi.djakov at linaro.org>
---

Changes since v1 (https://lkml.org/lkml/2016/2/4/259)
 * Rebased onto arm-soc/next/arm64

 arch/arm64/configs/defconfig |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 91ae2634cae9..ad26a53ddfe9 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -150,6 +150,7 @@ CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
 CONFIG_GPIO_PL061=y
 CONFIG_GPIO_RCAR=y
 CONFIG_GPIO_XGENE=y
+CONFIG_POWER_RESET_MSM=y
 CONFIG_POWER_RESET_XGENE=y
 CONFIG_POWER_RESET_SYSCON=y
 # CONFIG_HWMON is not set
@@ -186,10 +187,12 @@ CONFIG_USB_MSM_OTG=y
 CONFIG_USB_ULPI=y
 CONFIG_USB_GADGET=y
 CONFIG_MMC=y
+CONFIG_MMC_BLOCK_MINORS=32
 CONFIG_MMC_ARMMMCI=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_SDHCI_TEGRA=y
+CONFIG_MMC_SDHCI_MSM=y
 CONFIG_MMC_SPI=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_EXYNOS=y


From brian.starkey at arm.com  Tue Feb  9 02:23:00 2016
From: brian.starkey at arm.com (Brian Starkey)
Date: Tue, 9 Feb 2016 10:23:00 +0000
Subject: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag
In-Reply-To: <20160208120317.313409dc0ae7634c25d3f021@linux-foundation.org>
References: <cover.1454950917.git.brian.starkey@arm.com>
 <9085d37fa97a762a46b9d58719c085368682c64f.1454950917.git.brian.starkey@arm.com>
 <20160208120317.313409dc0ae7634c25d3f021@linux-foundation.org>
Message-ID: <20160209102300.GB23507@e106950-lin.cambridge.arm.com>

Hi Andrew,

Thanks for taking a look,

On Mon, Feb 08, 2016 at 12:03:17PM -0800, Andrew Morton wrote:
>On Mon,  8 Feb 2016 17:30:50 +0000 Brian Starkey <brian.starkey at arm.com> wrote:
>The patch generally looks OK to me.  It generates rejects against
>linux-next because of some janitorial changes in memremap.c.
>

Ah yeah, so it does - sorry. I was hoping this could make it into 4.5,
but I can rebase onto linux-next if that's better. Annoyingly it only
conflicts because of a couple of quotation marks.

>
>> @@ -101,6 +107,11 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
>>  		addr = ioremap_wt(offset, size);
>>  	}
>>
>> +	if (!addr && (flags & MEMREMAP_WC)) {
>> +		flags &= ~MEMREMAP_WC;
>> +		addr = ioremap_wc(offset, size);
>> +	}
>> +
>>  	return addr;
>>  }
>
>The modifications of `flags' is unneeded (and the compiler will remove
>it).  And generally the modification of incoming args is a bit nasty
>IMO - I find it's better to treat them as const - part of the calling
>environment which can be relied upon to be unaltered as the code
>evolves.
>

To be honest I was just mirroring the rest of the function. I guess
the idea was filtering the different mapping types in case one of the
'mappers' can handle multiple flags or something. I'll remove it if
you like, I just thought that extending the functionality in-keeping
with the current semantics was a better evolution - let me know.

Thanks,
Brian


From lee.jones at linaro.org  Tue Feb  9 02:35:13 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 9 Feb 2016 10:35:13 +0000
Subject: [PATCH v10 4/8] mfd: fsl imx25 Touchscreen ADC driver
In-Reply-To: <6151166.y0HMDdqtvF@adelgunde>
References: <1450101234-2191-1-git-send-email-mpa@pengutronix.de>
 <1450101234-2191-5-git-send-email-mpa@pengutronix.de>
 <20160111065441.GW3331@x1> <6151166.y0HMDdqtvF@adelgunde>
Message-ID: <20160209103513.GC24522@x1>

On Tue, 02 Feb 2016, Markus Pargmann wrote:

> Hi,
> 
> On Monday, January 11, 2016 06:54:41 AM Lee Jones wrote:
> > On Mon, 14 Dec 2015, Markus Pargmann wrote:
> > 
> > > This is the core driver for imx25 touchscreen/adc driver. The module
> > > has one shared ADC and two different conversion queues which use the
> > > ADC. The two queues are identical. Both can be used for general purpose
> > > ADC but one is meant to be used for touchscreens.
> > > 
> > > This driver is the core which manages the central components and
> > > registers of the TSC/ADC unit. It manages the IRQs and forwards them to
> > > the correct components.
> > > 
> > > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > > Signed-off-by: Denis Carikli <denis at eukrea.com>
> > > 
> > > [ensure correct ADC clock depending on the IPG clock]
> > > Signed-off-by: Juergen Borleis <jbe at pengutronix.de>
> > > Acked-by: Jonathan Cameron <jic23 at kernel.org>
> > > ---
> > > 
> > > Notes:
> > >     Changes in v7:
> > >      - Cleanup bit defines in header files to be more readable
> > >      - Fix irq check to return with an error for irq <= 0
> > >      - Add COMPILE_TEST in Kconfig file
> > >     
> > >     Changes in v5:
> > >      - Remove ifdef CONFIG_OF as this driver is only for DT usage
> > >      - Remove module owner
> > >      - Add Kconfig dependencies ARCH_MX25 and OF
> > > 
> > >  drivers/mfd/Kconfig             |   9 ++
> > >  drivers/mfd/Makefile            |   2 +
> > >  drivers/mfd/fsl-imx25-tsadc.c   | 203 ++++++++++++++++++++++++++++++++++++++++
> > >  include/linux/mfd/imx25-tsadc.h | 140 +++++++++++++++++++++++++++
> > >  4 files changed, 354 insertions(+)
> > >  create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
> > >  create mode 100644 include/linux/mfd/imx25-tsadc.h
> > 
> > For my own reference:
> >   Acked-by: Lee Jones <lee.jones at linaro.org>
> > 
> > I will apply this and sent out pull-requests to the relevant
> > maintainers once -rc1 is out.
> 
> Thanks. Do you mean just this patch or the whole series?

I will take all of the /driver patches.  The ARM patches need to go in
through ARM-SoC via the relevant sub-arch maintainer(s).

> Shall I resend the whole series to fix the commit title of the first
> patch?

No, that's fine.  I'll handle that *this time*.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From juri.lelli at arm.com  Tue Feb  9 02:37:48 2016
From: juri.lelli at arm.com (Juri Lelli)
Date: Tue, 9 Feb 2016 10:37:48 +0000
Subject: [PATCH v3 0/6] CPUs capacity information for heterogeneous systems
In-Reply-To: <56B92BF4.4030405@linaro.org>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <56B92BF4.4030405@linaro.org>
Message-ID: <20160209103748.GP11415@e106622-lin>

Hi Steve,

On 08/02/16 15:59, Steve Muckle wrote:
> Hi Juri,
> 
> On 02/03/2016 03:59 AM, Juri Lelli wrote:
> >  v1: DT + sysfs [1]
> > 
> >  v2: Dynamic profiling at boot [2]
> > 
> > Third version of this patchset proposes what seems to be the solution we agreed
> > upon (see [2] for reference) to the problem of how do we init CPUs original
> > capacity: we run a bogus benchmark (stealing int_sqrt from lib/ we run that in
> > a loop to perform some integer computation, better benchmarks are welcome)
> > on the first cpu of each frequency domain (assuming no u-arch differences
> > inside domains), measure time to complete a fixed number of iterations and then
> > normalize results to SCHED_CAPACITY_SCALE (1024). This time around we also
> > added a boot time parameter to disable profiling at boot (as it can be time
> > consuming) and sysfs attributes with which default values can be overwritten.
> > The proposed solution is basically putting together bits of v1 and v2 that are
> > considered valuable and acceptable for mainline.
> 
> I'm still concerned that there's no way to obtain optimal boot time on a
> heterogeneous system. Either the dynamic benchmarking is enabled, adding
> 1 sec, or the benchmarking is skipped, and task distribution on the
> heterogeneous CPUs is determined by the platform's CPU numbering and
> chance, potentially impacting performance nondeterministically until
> userspace sets the correct capacity values via sysfs.
> 
> I believe you tested the impact on boot time of using equal capacity
> values and saw little difference. I'm wondering though, what was the CPU
> numbering on that target?
> 

My targets (Juno and TC2) had big cluster on 1,2 and little on the
remaining cpus. Why do you think this might matter?

Anyway, IMHO boot time performance is not what we are targeting here, so
I wouldn't be too worried about this particular point.

Best,

- Juri


From bharat.kumar.gogada at xilinx.com  Tue Feb  9 02:41:56 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Tue, 9 Feb 2016 16:11:56 +0530
Subject: [PATCH V3 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver to
 work on both Zynq and Microblaze
In-Reply-To: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
References: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
Message-ID: <1455014518-8708-4-git-send-email-bharatku@xilinx.com>

Modifying Xilinx AXI PCIe Host Bridge Soft IP driver to work on both
Zynq and Microblaze Architectures.
With these modifications drivers/pci/host/pcie-xilinx.c, will
work on both Zynq and Microblaze Architectures.

Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
---
Changes:
Removed unneccessary architecture dependent number of MSI's.
Added #ifdef to pci_fixup_irqs which is ARM specific API.
---
 drivers/pci/host/pcie-xilinx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 13fec35..6cbce34 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -704,7 +704,9 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
 #endif
 	pci_scan_child_bus(bus);
 	pci_assign_unassigned_bus_resources(bus);
+#ifdef CONFIG_ARM
 	pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
+#endif
 	pci_bus_add_devices(bus);
 	platform_set_drvdata(pdev, port);
 
-- 
2.1.1



From bharat.kumar.gogada at xilinx.com  Tue Feb  9 02:41:57 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Tue, 9 Feb 2016 16:11:57 +0530
Subject: [PATCH V3 4/5] PCI: xilinx: Updating Zynq PCI binding documentation
 with Microblaze node.
In-Reply-To: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
References: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
Message-ID: <1455014518-8708-5-git-send-email-bharatku@xilinx.com>

Updated Zynq PCI binding documentation with Microblaze node.

Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>

Acked-by: Rob Herring <robh at kernel.org>
---
Changes:
Adding Microblaze device tree node Documnetation.
Made bus-range property optional for Microblaze.
---
 .../devicetree/bindings/pci/xilinx-pcie.txt        | 32 ++++++++++++++++++++--
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/xilinx-pcie.txt b/Documentation/devicetree/bindings/pci/xilinx-pcie.txt
index 02f979a..ad7c7bf 100644
--- a/Documentation/devicetree/bindings/pci/xilinx-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/xilinx-pcie.txt
@@ -17,7 +17,7 @@ Required properties:
 	Please refer to the standard PCI bus binding document for a more
 	detailed explanation
 
-Optional properties:
+Optional properties for Zynq/Microblaze:
 - bus-range: PCI bus numbers covered
 
 Interrupt controller child node
@@ -38,13 +38,13 @@ the four INTx interrupts in ISR and route them to this domain.
 
 Example:
 ++++++++
-
+Zynq:
 	pci_express: axi-pcie at 50000000 {
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
 		compatible = "xlnx,axi-pcie-host-1.00.a";
-		reg = < 0x50000000 0x10000000 >;
+		reg = < 0x50000000 0x1000000 >;
 		device_type = "pci";
 		interrupts = < 0 52 4 >;
 		interrupt-map-mask = <0 0 0 7>;
@@ -60,3 +60,29 @@ Example:
 			#interrupt-cells = <1>;
 		};
 	};
+
+
+Microblaze:
+	pci_express: axi-pcie at 10000000 {
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		compatible = "xlnx,axi-pcie-host-1.00.a";
+		reg = <0x10000000 0x4000000>;
+		device_type = "pci";
+		interrupt-parent = <&microbalze_0_intc>;
+		interrupts = <1 2>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie_intc 1>,
+				<0 0 0 2 &pcie_intc 2>,
+				<0 0 0 3 &pcie_intc 3>,
+				<0 0 0 4 &pcie_intc 4>;
+		ranges = <0x02000000 0x00000000 0x80000000 0x80000000 0x00000000 0x10000000>;
+
+		pcie_intc: interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
+			#interrupt-cells = <1>;
+		};
+
+	};
-- 
2.1.1



From bharat.kumar.gogada at xilinx.com  Tue Feb  9 02:41:53 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Tue, 9 Feb 2016 16:11:53 +0530
Subject: [PATCH V3 0/5] PCIe Xilinx generic driver for Microblaze and 
Message-ID: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>

This patch series does modifications to pcie-xilinx.c, to support common
driver on both Zynq and Microblaze architectures.
Microblaze pci-common.c has been modified to support generic driver.

Bharat Kumar Gogada (5):
  PCI: xilinx: Removing xilinx_pcie_parse_and_add_res function
  PCI: xilinx: Removing struct hw_pci structure.
  PCI: xilinx: Modifying AXI PCIe Host Bridge driver to     work on both
     Zynq and Microblaze
  PCI: xilinx: Updating Zynq PCI binding documentation     with 
    Microblaze node.
  Microblaze: Modifying microblaze PCI subsytem to     support  generic
    Xilinx  AXI PCIe Host Bridge IP driver

 .../devicetree/bindings/pci/xilinx-pcie.txt        |  32 +++-
 arch/microblaze/Kconfig                            |   3 +
 arch/microblaze/pci/pci-common.c                   |  56 ++----
 drivers/pci/host/Kconfig                           |   2 +-
 drivers/pci/host/pcie-xilinx.c                     | 191 +++------------------
 5 files changed, 66 insertions(+), 218 deletions(-)

-- 
2.1.1



From bharat.kumar.gogada at xilinx.com  Tue Feb  9 02:41:58 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Tue, 9 Feb 2016 16:11:58 +0530
Subject: [PATCH V3 5/5] Microblaze: Modifying microblaze PCI subsytem to
 support generic Xilinx AXI PCIe Host Bridge IP driver
In-Reply-To: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
References: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
Message-ID: <1455014518-8708-6-git-send-email-bharatku@xilinx.com>

This patch does required modifications to microblaze PCI subsystem, to
work with generic driver (drivers/pci/host/pcie-xilinx.c) on Microblaze
and Zynq.

Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
---
Changes:
Removed pcibios_get_phb_of_node in pci-common.c, using generic version
instead.
Modified pcibios_fixup_bus in pci-common.c, as per generic architecuture.
Modified pcibios_align_resource in pci-common.c, as per generic
architecuture, removed temporary variable.
Removed pci_domain_nr in pci-common.c, instead using generic code.
Added pcibios_add_device in pci-common.c, as per generic architecuture.
Adding Kernel configuration in arch/microblaze as required for generic PCI
domains.
Added kernel configuration for driver to support Microblaze.
---
 arch/microblaze/Kconfig          |  3 +++
 arch/microblaze/pci/pci-common.c | 56 +++++++---------------------------------
 drivers/pci/host/Kconfig         |  2 +-
 3 files changed, 14 insertions(+), 47 deletions(-)

diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 0bce820..c3702b9 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -271,6 +271,9 @@ config PCI
 config PCI_DOMAINS
 	def_bool PCI
 
+config PCI_DOMAINS_GENERIC
+	def_bool PCI_DOMAINS
+
 config PCI_SYSCALL
 	def_bool PCI
 
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index ae838ed..35654be 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -123,17 +123,6 @@ unsigned long pci_address_to_pio(phys_addr_t address)
 }
 EXPORT_SYMBOL_GPL(pci_address_to_pio);
 
-/*
- * Return the domain number for this bus.
- */
-int pci_domain_nr(struct pci_bus *bus)
-{
-	struct pci_controller *hose = pci_bus_to_host(bus);
-
-	return hose->global_number;
-}
-EXPORT_SYMBOL(pci_domain_nr);
-
 /* This routine is meant to be used early during boot, when the
  * PCI bus numbers have not yet been assigned, and you need to
  * issue PCI config cycles to an OF device.
@@ -863,26 +852,10 @@ void pcibios_setup_bus_devices(struct pci_bus *bus)
 
 void pcibios_fixup_bus(struct pci_bus *bus)
 {
-	/* When called from the generic PCI probe, read PCI<->PCI bridge
-	 * bases. This is -not- called when generating the PCI tree from
-	 * the OF device-tree.
-	 */
-	if (bus->self != NULL)
-		pci_read_bridge_bases(bus);
-
-	/* Now fixup the bus bus */
-	pcibios_setup_bus_self(bus);
-
-	/* Now fixup devices on that bus */
-	pcibios_setup_bus_devices(bus);
+	/* nothing to do */
 }
 EXPORT_SYMBOL(pcibios_fixup_bus);
 
-static int skip_isa_ioresource_align(struct pci_dev *dev)
-{
-	return 0;
-}
-
 /*
  * We need to avoid collisions with `mirrored' VGA ports
  * and other strange ISA hardware, so we always want the
@@ -899,20 +872,18 @@ static int skip_isa_ioresource_align(struct pci_dev *dev)
 resource_size_t pcibios_align_resource(void *data, const struct resource *res,
 				resource_size_t size, resource_size_t align)
 {
-	struct pci_dev *dev = data;
-	resource_size_t start = res->start;
-
-	if (res->flags & IORESOURCE_IO) {
-		if (skip_isa_ioresource_align(dev))
-			return start;
-		if (start & 0x300)
-			start = (start + 0x3ff) & ~0x3ff;
-	}
-
-	return start;
+	return res->start;
 }
 EXPORT_SYMBOL(pcibios_align_resource);
 
+int pcibios_add_device(struct pci_dev *dev)
+{
+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
+
+	return 0;
+}
+EXPORT_SYMBOL(pcibios_add_device);
+
 /*
  * Reparent resource children of pr that conflict with res
  * under res, and make res replace those children.
@@ -1333,13 +1304,6 @@ static void pcibios_setup_phb_resources(struct pci_controller *hose,
 		 (unsigned long)hose->io_base_virt - _IO_BASE);
 }
 
-struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)
-{
-	struct pci_controller *hose = bus->sysdata;
-
-	return of_node_get(hose->dn);
-}
-
 static void pcibios_scan_phb(struct pci_controller *hose)
 {
 	LIST_HEAD(resources);
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..7c56c2e 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -79,7 +79,7 @@ config PCI_KEYSTONE
 
 config PCIE_XILINX
 	bool "Xilinx AXI PCIe host bridge support"
-	depends on ARCH_ZYNQ
+	depends on ARCH_ZYNQ || MICROBLAZE
 	help
 	  Say 'Y' here if you want kernel to support the Xilinx AXI PCIe
 	  Host Bridge driver.
-- 
2.1.1



From bharat.kumar.gogada at xilinx.com  Tue Feb  9 02:41:54 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Tue, 9 Feb 2016 16:11:54 +0530
Subject: [PATCH V3 1/5] PCI: xilinx: Removing xilinx_pcie_parse_and_add_res
 function
In-Reply-To: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
References: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
Message-ID: <1455014518-8708-2-git-send-email-bharatku@xilinx.com>

Removing xilinx_pcie_parse_and_add_res function replacing with
of_pci_get_host_bridge_resources API.

Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
---
Changes:
Removing xilinx_pcie_parse_and_add_res function and replacing it
with of_pci_get_host_bridge_resources kernel API which does the same.
---
 drivers/pci/host/pcie-xilinx.c | 107 ++---------------------------------------
 1 file changed, 5 insertions(+), 102 deletions(-)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 3c7a0d5..627878d 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -94,9 +94,6 @@
 /* Number of MSI IRQs */
 #define XILINX_NUM_MSI_IRQS		128
 
-/* Number of Memory Resources */
-#define XILINX_MAX_NUM_RESOURCES	3
-
 /**
  * struct xilinx_pcie_port - PCIe port information
  * @reg_base: IO Mapped Register Base
@@ -105,7 +102,6 @@
  * @root_busno: Root Bus number
  * @dev: Device pointer
  * @irq_domain: IRQ domain pointer
- * @bus_range: Bus range
  * @resources: Bus Resources
  */
 struct xilinx_pcie_port {
@@ -659,97 +655,6 @@ static struct pci_bus *xilinx_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 }
 
 /**
- * xilinx_pcie_parse_and_add_res - Add resources by parsing ranges
- * @port: PCIe port information
- *
- * Return: '0' on success and error value on failure
- */
-static int xilinx_pcie_parse_and_add_res(struct xilinx_pcie_port *port)
-{
-	struct device *dev = port->dev;
-	struct device_node *node = dev->of_node;
-	struct resource *mem;
-	resource_size_t offset;
-	struct of_pci_range_parser parser;
-	struct of_pci_range range;
-	struct resource_entry *win;
-	int err = 0, mem_resno = 0;
-
-	/* Get the ranges */
-	if (of_pci_range_parser_init(&parser, node)) {
-		dev_err(dev, "missing \"ranges\" property\n");
-		return -EINVAL;
-	}
-
-	/* Parse the ranges and add the resources found to the list */
-	for_each_of_pci_range(&parser, &range) {
-
-		if (mem_resno >= XILINX_MAX_NUM_RESOURCES) {
-			dev_err(dev, "Maximum memory resources exceeded\n");
-			return -EINVAL;
-		}
-
-		mem = devm_kmalloc(dev, sizeof(*mem), GFP_KERNEL);
-		if (!mem) {
-			err = -ENOMEM;
-			goto free_resources;
-		}
-
-		of_pci_range_to_resource(&range, node, mem);
-
-		switch (mem->flags & IORESOURCE_TYPE_BITS) {
-		case IORESOURCE_MEM:
-			offset = range.cpu_addr - range.pci_addr;
-			mem_resno++;
-			break;
-		default:
-			err = -EINVAL;
-			break;
-		}
-
-		if (err < 0) {
-			dev_warn(dev, "Invalid resource found %pR\n", mem);
-			continue;
-		}
-
-		err = request_resource(&iomem_resource, mem);
-		if (err)
-			goto free_resources;
-
-		pci_add_resource_offset(&port->resources, mem, offset);
-	}
-
-	/* Get the bus range */
-	if (of_pci_parse_bus_range(node, &port->bus_range)) {
-		u32 val = pcie_read(port, XILINX_PCIE_REG_BIR);
-		u8 last;
-
-		last = (val & XILINX_PCIE_BIR_ECAM_SZ_MASK) >>
-			XILINX_PCIE_BIR_ECAM_SZ_SHIFT;
-
-		port->bus_range = (struct resource) {
-			.name	= node->name,
-			.start	= 0,
-			.end	= last,
-			.flags	= IORESOURCE_BUS,
-		};
-	}
-
-	/* Register bus resource */
-	pci_add_resource(&port->resources, &port->bus_range);
-
-	return 0;
-
-free_resources:
-	release_child_resources(&iomem_resource);
-	resource_list_for_each_entry(win, &port->resources)
-		devm_kfree(dev, win->res);
-	pci_free_resource_list(&port->resources);
-
-	return err;
-}
-
-/**
  * xilinx_pcie_parse_dt - Parse Device tree
  * @port: PCIe port information
  *
@@ -802,6 +707,8 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
 	struct hw_pci hw;
 	struct device *dev = &pdev->dev;
 	int err;
+	resource_size_t iobase = 0;
+	LIST_HEAD(res);
 
 	if (!dev->of_node)
 		return -ENODEV;
@@ -826,14 +733,10 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
 		return err;
 	}
 
-	/*
-	 * Parse PCI ranges, configuration bus range and
-	 * request their resources
-	 */
-	INIT_LIST_HEAD(&port->resources);
-	err = xilinx_pcie_parse_and_add_res(port);
+	err = of_pci_get_host_bridge_resources(dev->of_node, 0, 0xff, &res,
+					       &iobase);
 	if (err) {
-		dev_err(dev, "Failed adding resources\n");
+		dev_err(dev, "Getting bridge resources failed\n");
 		return err;
 	}
 
-- 
2.1.1



From bharat.kumar.gogada at xilinx.com  Tue Feb  9 02:41:55 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Tue, 9 Feb 2016 16:11:55 +0530
Subject: [PATCH V3 2/5] PCI: xilinx: Removing struct hw_pci structure.
In-Reply-To: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
References: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
Message-ID: <1455014518-8708-3-git-send-email-bharatku@xilinx.com>

Removing struct hw_pci and adding generic PCI core API's.

Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
---
Changes:
Removing architecure dependecy structure struct hw_pci which is ARM 32-bit
specific structure, and adding generic PCI core API's to register to
PCI subsytem.
Removing funtions which are not being used with generic API's.
---
 drivers/pci/host/pcie-xilinx.c | 82 +++++++++---------------------------------
 1 file changed, 16 insertions(+), 66 deletions(-)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 627878d..13fec35 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -111,17 +111,11 @@ struct xilinx_pcie_port {
 	u8 root_busno;
 	struct device *dev;
 	struct irq_domain *irq_domain;
-	struct resource bus_range;
 	struct list_head resources;
 };
 
 static DECLARE_BITMAP(msi_irq_in_use, XILINX_NUM_MSI_IRQS);
 
-static inline struct xilinx_pcie_port *sys_to_pcie(struct pci_sys_data *sys)
-{
-	return sys->private_data;
-}
-
 static inline u32 pcie_read(struct xilinx_pcie_port *port, u32 reg)
 {
 	return readl(port->reg_base + reg);
@@ -163,7 +157,7 @@ static void xilinx_pcie_clear_err_interrupts(struct xilinx_pcie_port *port)
  */
 static bool xilinx_pcie_valid_device(struct pci_bus *bus, unsigned int devfn)
 {
-	struct xilinx_pcie_port *port = sys_to_pcie(bus->sysdata);
+	struct xilinx_pcie_port *port = bus->sysdata;
 
 	/* Check if link is up when trying to access downstream ports */
 	if (bus->number != port->root_busno)
@@ -196,7 +190,7 @@ static bool xilinx_pcie_valid_device(struct pci_bus *bus, unsigned int devfn)
 static void __iomem *xilinx_pcie_map_bus(struct pci_bus *bus,
 					 unsigned int devfn, int where)
 {
-	struct xilinx_pcie_port *port = sys_to_pcie(bus->sysdata);
+	struct xilinx_pcie_port *port = bus->sysdata;
 	int relbus;
 
 	if (!xilinx_pcie_valid_device(bus, devfn))
@@ -228,7 +222,7 @@ static void xilinx_pcie_destroy_msi(unsigned int irq)
 
 	if (!test_bit(irq, msi_irq_in_use)) {
 		msi = irq_get_msi_desc(irq);
-		port = sys_to_pcie(msi_desc_to_pci_sysdata(msi));
+		port = msi_desc_to_pci_sysdata(msi);
 		dev_err(port->dev, "Trying to free unused MSI#%d\n", irq);
 	} else {
 		clear_bit(irq, msi_irq_in_use);
@@ -277,7 +271,7 @@ static int xilinx_pcie_msi_setup_irq(struct msi_controller *chip,
 				     struct pci_dev *pdev,
 				     struct msi_desc *desc)
 {
-	struct xilinx_pcie_port *port = sys_to_pcie(pdev->bus->sysdata);
+	struct xilinx_pcie_port *port = pdev->bus->sysdata;
 	unsigned int irq;
 	int hwirq;
 	struct msi_msg msg;
@@ -614,47 +608,6 @@ static void xilinx_pcie_init_port(struct xilinx_pcie_port *port)
 }
 
 /**
- * xilinx_pcie_setup - Setup memory resources
- * @nr: Bus number
- * @sys: Per controller structure
- *
- * Return: '1' on success and error value on failure
- */
-static int xilinx_pcie_setup(int nr, struct pci_sys_data *sys)
-{
-	struct xilinx_pcie_port *port = sys_to_pcie(sys);
-
-	list_splice_init(&port->resources, &sys->resources);
-
-	return 1;
-}
-
-/**
- * xilinx_pcie_scan_bus - Scan PCIe bus for devices
- * @nr: Bus number
- * @sys: Per controller structure
- *
- * Return: Valid Bus pointer on success and NULL on failure
- */
-static struct pci_bus *xilinx_pcie_scan_bus(int nr, struct pci_sys_data *sys)
-{
-	struct xilinx_pcie_port *port = sys_to_pcie(sys);
-	struct pci_bus *bus;
-
-	port->root_busno = sys->busnr;
-
-	if (IS_ENABLED(CONFIG_PCI_MSI))
-		bus = pci_scan_root_bus_msi(port->dev, sys->busnr,
-					    &xilinx_pcie_ops, sys,
-					    &sys->resources,
-					    &xilinx_pcie_msi_chip);
-	else
-		bus = pci_scan_root_bus(port->dev, sys->busnr,
-					&xilinx_pcie_ops, sys, &sys->resources);
-	return bus;
-}
-
-/**
  * xilinx_pcie_parse_dt - Parse Device tree
  * @port: PCIe port information
  *
@@ -704,8 +657,9 @@ static int xilinx_pcie_parse_dt(struct xilinx_pcie_port *port)
 static int xilinx_pcie_probe(struct platform_device *pdev)
 {
 	struct xilinx_pcie_port *port;
-	struct hw_pci hw;
 	struct device *dev = &pdev->dev;
+	struct pci_bus *bus;
+
 	int err;
 	resource_size_t iobase = 0;
 	LIST_HEAD(res);
@@ -739,24 +693,20 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
 		dev_err(dev, "Getting bridge resources failed\n");
 		return err;
 	}
-
-	platform_set_drvdata(pdev, port);
-
-	/* Register the device */
-	memset(&hw, 0, sizeof(hw));
-	hw = (struct hw_pci) {
-		.nr_controllers	= 1,
-		.private_data	= (void **)&port,
-		.setup		= xilinx_pcie_setup,
-		.map_irq	= of_irq_parse_and_map_pci,
-		.scan		= xilinx_pcie_scan_bus,
-		.ops		= &xilinx_pcie_ops,
-	};
+	bus = pci_create_root_bus(&pdev->dev, 0,
+				  &xilinx_pcie_ops, port, &res);
+	if (!bus)
+		return -ENOMEM;
 
 #ifdef CONFIG_PCI_MSI
 	xilinx_pcie_msi_chip.dev = port->dev;
+	bus->msi = &xilinx_pcie_msi_chip;
 #endif
-	pci_common_init_dev(dev, &hw);
+	pci_scan_child_bus(bus);
+	pci_assign_unassigned_bus_resources(bus);
+	pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
+	pci_bus_add_devices(bus);
+	platform_set_drvdata(pdev, port);
 
 	return 0;
 }
-- 
2.1.1



From marc.zyngier at arm.com  Tue Feb  9 02:42:47 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 9 Feb 2016 10:42:47 +0000
Subject: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <CABM=7k=-Y+eFB2nUMfMjd3saTSNDsEyfHyYNf-ef8qQc5jCsxA@mail.gmail.com>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
 <56B8B45D.1020902@arm.com> <20160209085633.GA5388@kwain>
 <20160209090131.GB5388@kwain> <56B9ACE2.1060200@arm.com>
 <CABM=7knaepbyy4nw_GczVM7E_t6py7gG0ERs8ru_AYoVXvAQ+A@mail.gmail.com>
 <56B9B1B5.5070106@arm.com>
 <CABM=7k=-Y+eFB2nUMfMjd3saTSNDsEyfHyYNf-ef8qQc5jCsxA@mail.gmail.com>
Message-ID: <56B9C2A7.4040402@arm.com>

On 09/02/16 10:13, Tsahee Zidenberg wrote:
> On 9 February 2016 at 11:30, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>
>> On 09/02/16 09:14, Tsahee Zidenberg wrote:
>>>
>>>
>>> On 9 February 2016 at 11:09, Marc Zyngier <marc.zyngier at arm.com
>>> <mailto:marc.zyngier at arm.com>> wrote:
>>>
>>>     On 09/02/16 09:01, Antoine Tenart wrote:
>>>     > On Tue, Feb 09, 2016 at 09:56:33AM +0100, Antoine Tenart wrote:
>>>     >> Hi Marc,
>>>     >>
>>>     >> On Mon, Feb 08, 2016 at 03:29:33PM +0000, Marc Zyngier wrote:
>>>     >>> On 08/02/16 09:11, Antoine Tenart wrote:
>>>     >>>
>>>     >>>> +          gic: gic at f0100000 {
>>>     >>>> +                  compatible = "arm,gic-v3";
>>>     >>>> +                  reg = <0x0 0xf0200000 0x0 0x10000>,     /* GIC Dist */
>>>     >>>> +                        <0x0 0xf0280000 0x0 0x200000>,    /* GICR */
>>>     >>>> +                        <0x0 0xf0100000 0x0 0x2000>;      /* GICC */
>>>     >>>> +                  interrupt-controller;
>>>     >>>> +                  #interrupt-cells = <3>;
>>>     >>>> +          };
>>>     >>>
>>>     >>> Something is wrong here. Either you are missing GICH and GICV (assuming
>>>     >>> you have legacy support), or you have an extra GICC region (which
>>>     >>> doesn't make sense on its own).
>>>     >>
>>>     >> I'll add the missing regions.
>>>     >
>>>     > Hmm, in fact the GICC region shouldn't be there. I'll make some tests
>>>     > and remove it.
>>>
>>>     If you have a GICv3 with legacy support, you will probably have GICC,
>>>     GICH and GICV. Linux itself will only use GICD and GICR, but it needs at
>>>     least GICV to be able to virtualize GICv2 guests. And GICV is not
>>>     allowed to exist without GICC and GICH, so I really recommend that you
>>>     keep GICC around.
>>>
>>>
>>> We use the GIC without legacy support (we disable it in early boot
>>> stages), so I think removing the GICC region is the better solution.
>>
>> Disabling legacy support doesn't mean that:
>> - the HW isn't present
>> - the associated regions are not useful
>>
> By "disabling lecgacy support in early boot" I don't just mean that
> ARE bit will be set, but it will actually be RAO/WI. There will be no
> way for SW to enable it and use these registers (which, sadly, means
> that there will be no way to enable gicv2 virtualization). If you
> insist - I will dig up the supposed location of GICV and GICH - yet it
> will be both untested and entirely unusable.

That's quite sad indeed. You are pointlessly breaking existing software.
But hey, that's your choice. At that point, I can't be bothered to care.

> We will add an entry for the maintenance interrupt, as it really can
> be used by future configurations.

Well, at least you'll be able to run GICv3 guests, assuming everything
else is usable.

	M.
-- 
Jazz is not dead. It just smells funny...


From chauveau.julien at gmail.com  Tue Feb  9 02:45:08 2016
From: chauveau.julien at gmail.com (Julien Chauveau)
Date: Tue, 09 Feb 2016 11:45:08 +0100
Subject: [PATCH v2 06/10] ARM64: dts: rockchip: Add IR receiver to
 GeekBox
In-Reply-To: <56B95827.7060204@suse.de>
References: <1454897859-7601-1-git-send-email-afaerber@suse.de>
 <1454897859-7601-7-git-send-email-afaerber@suse.de>
 <56B95827.7060204@suse.de>
Message-ID: <56B9C334.2070002@gmail.com>


Le 09/02/2016 04:08, Andreas F?rber a ?crit :
> Am 08.02.2016 um 03:17 schrieb Andreas F?rber:
>> Signed-off-by: Andreas F?rber <afaerber at suse.de>
>> ---
>>   v2: New
>>   
>>   arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 13 +++++++++++++
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
>> index e4523a74050f..e84383fd6f10 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
>> +++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts
>> @@ -63,6 +63,13 @@
>>   		#clock-cells = <0>;
>>   	};
>>   
>> +	ir: ir-receiver {
>> +		compatible = "gpio-ir-receiver";
>> +		gpios = <&gpio3 30 GPIO_ACTIVE_LOW>;
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&ir_int>;
> 		status = "disabled";
>
> Should only be enabled in the new Landingship config. Will fix.
>
> Andreas
Actually there's two IR receivers:
- one on the geekbox module (on the bottom side)
- and another one on the landingship.

Both are connected to the same GPIO pin, so you can keep it enabled in 
the main geekbox dts.

About the pinctrl, same remark as for gpio-keys: there's already 
external pull-up resistors on this pin, so it should be better to use 
pcfg_pull_none instead of pcfg_pull_up.

Julien
>
> P.S. See Heiko, two bugs in the new nodes already, glad I have them
> separate. :)
>
>> +	};
>> +
>>   	leds: gpio-leds {
>>   		compatible = "gpio-leds";
>>   
> [snip]
>



From sergei.shtylyov at cogentembedded.com  Tue Feb  9 02:52:09 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 9 Feb 2016 13:52:09 +0300
Subject: [PATCH 5/5] ARM: dts: r8a7794 add sound support
In-Reply-To: <87mvraoikj.wl%kuninori.morimoto.gx@renesas.com>
References: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>
 <2179456.HznTXDfKhZ@wasted.cogentembedded.com>
 <87mvraoikj.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <56B9C4D9.6020808@cogentembedded.com>

On 2/9/2016 3:08 AM, Kuninori Morimoto wrote:

>> Define the generic R8A7794 part of  the sound device node.
>> This sound device  is a complex one and comprises the Audio Clock Generator
>> (ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
>> (SSI[U]), and Audio DMAC-Peripheral-Peripheral.
>> It is up  to the board file to enable the device.
>>
>> This patch is based on the R8A7791 sound work by Kuninori Morimoto.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> (snip)
>> +		clocks = <&mstp10_clks R8A7794_CLK_SSI_ALL>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI9>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI8>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI7>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI6>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI5>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI4>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI3>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI2>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI1>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI0>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC9>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC8>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC7>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC6>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC5>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC4>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC3>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC2>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC1>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC0>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_DVC0>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_DVC1>,
>> +			 <&audio_clka>, <&audio_clkb>, <&audio_clkc>,
>> +			 <&m2_clk>;
>> +		clock-names = "ssi-all",
>> +			      "ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
>> +			      "ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0",
>> +			      "src.9", "src.8", "src.7", "src.6", "src.5",
>> +			      "src.4", "src.3", "src.2", "src.1", "src.0",
>> +			      "clk_a", "clk_b", "clk_c", "clk_i";
>
> This patch doesn't support "CTU/MIX/DVC".

    It doesn't.

> Your "clocks" includes "R8A7794_CLK_SCU_CTUx_MIXx", and "R8A7794_CLK_SCU_DVCx",
> but "clock-names" doesn't include "ctu.x", "dvc.x".

    Oops, thank you for noticing. Will fix.

MBR, Sergei



From kishon at ti.com  Tue Feb  9 03:02:17 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 9 Feb 2016 16:32:17 +0530
Subject: [PATCH v2] ARM: DRA7: hwmod: Fix OCP2SCP sysconfig
In-Reply-To: <alpine.DEB.2.02.1602090917040.2906@utopia.booyaka.com>
References: <1455008743-21660-1-git-send-email-kishon@ti.com>
 <alpine.DEB.2.02.1602090917040.2906@utopia.booyaka.com>
Message-ID: <56B9C739.5050103@ti.com>

Hi,

On Tuesday 09 February 2016 02:48 PM, Paul Walmsley wrote:
> On Tue, 9 Feb 2016, Kishon Vijay Abraham I wrote:
> 
>> OCP2SCP doesn't support smart idle wakeup according to
>> Table 26-22. OCP2SCP_SYSCONFIG in AM572x TRM [1] and
>> Table 26-22. OCP2SCP_SYSCONFIG in AM571x TRM [2].
>> Remove SIDLE_SMART_WKUP from the list of supported SIDLE modes
>> in hwmod data.
>>
>> [1] -> http://www.ti.com/lit/ug/spruhz6e/spruhz6e.pdf
>> [2] -> http://www.ti.com/lit/ug/spruhz7a/spruhz7a.pdf
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon at ti.com>
> 
> Thanks, queued for v4.6.  If you'd like it queued as a fix, please resend 
> with a description of the regression that it fixes.

Found this during review and as such it didn't cause any regressions. So I
think it's okay to be queued for 4.6

Thanks
Kishon


From catalin.marinas at arm.com  Tue Feb  9 02:45:33 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 9 Feb 2016 10:45:33 +0000
Subject: [PATCH] arm64: allow the module region to be randomized
 independently
In-Reply-To: <CAKv+Gu-vxhJRUMK7sqv1saw+wkQRD5xFydpgTLbKgWhoNj5LmA@mail.gmail.com>
References: <CAGXu5j+1rcScYedzQ5o0aaGZJWPCBGk-gai0D8jY8Huc-VuG7A@mail.gmail.com>
 <1454926332-25929-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160208181305.GW6076@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-vxhJRUMK7sqv1saw+wkQRD5xFydpgTLbKgWhoNj5LmA@mail.gmail.com>
Message-ID: <20160209104533.GB16122@e104818-lin.cambridge.arm.com>

On Tue, Feb 09, 2016 at 11:03:01AM +0100, Ard Biesheuvel wrote:
> On 8 February 2016 at 19:13, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Mon, Feb 08, 2016 at 11:12:12AM +0100, Ard Biesheuvel wrote:
> >> This adds the option to randomize the module region independently from the
> >> core kernel, and enables it by default. This makes it less likely that the
> >> location of core kernel data structures can be determined by an adversary,
> >> but causes all function calls from modules into the core kernel to be
> >> resolved via entries in the module PLTs.
> >>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >> ---
> >>  arch/arm64/Kconfig              | 15 ++++++++
> >>  arch/arm64/include/asm/module.h |  6 ++++
> >>  arch/arm64/kernel/kaslr.c       | 36 +++++++++++++++-----
> >>  arch/arm64/kernel/module.c      |  9 ++---
> >>  4 files changed, 50 insertions(+), 16 deletions(-)
> >
> > With this patch I get an unhandled paging request, coming from
> > kernel/module.c:2982 (the memset). The PC is wrongly attributed but it's
> > in arch/arm64/lib/memset.S:
> >
> 
> This was due to a thinko in kaslr_early_init(). Folding the following
> hunk will fix it (or I can resend the patch if you prefer)
> 
> -------8<----------
> diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
> index f8ad30160026..d7eba99ab140 100644
> --- a/arch/arm64/kernel/kaslr.c
> +++ b/arch/arm64/kernel/kaslr.c
> @@ -82,6 +82,12 @@ u64 __init kaslr_early_init(u64 dt_phys)
>         int size;
> 
>         /*
> +        * Set a reasonable default for module_alloc_base in case
> +        * we end up running with KASLR disabled.
> +        */
> +       module_alloc_base = (u64)_etext - MODULES_VSIZE;
> +
> +       /*
>          * Try to map the FDT early. If this fails, we simply bail,
>          * and proceed with KASLR disabled. We will make another
>          * attempt at mapping the FDT in setup_machine()
> -------8<----------

I'll fold the hunk in and give it a try. Thanks.

-- 
Catalin


From arnd at arndb.de  Tue Feb  9 03:04:00 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 12:04 +0100
Subject: [PATCH 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <1455008277-8312-2-git-send-email-raveendra.padasalagi@broadcom.com>
References: <1455008277-8312-1-git-send-email-raveendra.padasalagi@broadcom.com>
 <1455008277-8312-2-git-send-email-raveendra.padasalagi@broadcom.com>
Message-ID: <2631849.GeOulu78vx@wuerfel>

On Tuesday 09 February 2016 14:27:55 Raveendra Padasalagi wrote:
> +
> +One of the below 2 property is mandatory.
> +- ts_syscon: handler of syscon node defining physical base address
> +  of the controller and length of memory mapped region.
> +  If this property is selected please make sure MFD_SYSCON config
> +  is enabled in the defconfig file.
> +or
> +- reg: physical base address of the controller and length of memory
> +  mapped region.
> +
>  - clocks:  The clock provided by the SOC to driver the tsc
>  - clock-name:  name for the clock
>  - interrupts: The touchscreen controller's interrupt
> @@ -54,12 +62,16 @@ Optional properties:
>  - touchscreen-inverted-y: Y axis is inverted (boolean)
>  
>  Example:
> +       ts_adc_syscon: ts_adc_syscon at 0x180a6000 {
> +               compatible = "syscon";
> +               reg = <0x180a6000 0xc30>;
> +       };
>  
>         touchscreen: tsc at 0x180A6000 {
>                 compatible = "brcm,iproc-touchscreen";
>                 #address-cells = <1>;
>                 #size-cells = <1>;
> -               reg = <0x180A6000 0x40>;
> +               syscon = <&ts_adc_syscon>;
>                 clocks = <&adc_clk>;
>                 clock-names = "tsc_clk";
>                 interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;

This doesn't seem right: For one thing, it's an incompatible binding
change which you should try to avoid.

Worse, the syscon has a name indicating that it really has a particular
function, but the name is completely generic (just "syscon"). Please
add a specific compatible string identifying the device that owns
the registers, and put any other associated properties (clocks,
interrupts, ...) that are for that device in general rather than just
the touchscreen in there.

Your changelog text fails to describe why you do this change in
the first place, and why you can't do it in a backward-compatible
way, so please rewrite that text.

	Arnd


From robin.murphy at arm.com  Tue Feb  9 03:04:45 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue,  9 Feb 2016 11:04:45 +0000
Subject: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
Message-ID: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>

The existing msi-map code is fine for shifting the entire RID space
upwards, but attempting finer-grained remapping reveals a bug. It turns
out that we are mistakenly treating the msi-base part as an offset, not
as a new base to remap onto, so things get squiffy when rid-base is
nonzero. Fix this, and at the same time add a sanity check against
having msi-map-mask clash with a nonzero rid-base, as that's another
thing one can easily get wrong.

CC: <stable at vger.kernel.org>
Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
 drivers/of/irq.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 7ee21ae..e7bfc17 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -635,6 +635,13 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
 		msi_base = be32_to_cpup(msi_map + 2);
 		rid_len = be32_to_cpup(msi_map + 3);
 
+		if (rid_base & ~map_mask) {
+			dev_err(parent_dev,
+				"Invalid msi-map translation - msi-map-mask (0x%x) ignores rid-base (0x%x)\n",
+				map_mask, rid_base);
+			return rid_out;
+		}
+
 		msi_controller_node = of_find_node_by_phandle(phandle);
 
 		matched = (masked_rid >= rid_base &&
@@ -654,7 +661,7 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
 	if (!matched)
 		return rid_out;
 
-	rid_out = masked_rid + msi_base;
+	rid_out = masked_rid - rid_base + msi_base;
 	dev_dbg(dev,
 		"msi-map at: %s, using mask %08x, rid-base: %08x, msi-base: %08x, length: %08x, rid: %08x -> %08x\n",
 		dev_name(parent_dev), map_mask, rid_base, msi_base,
-- 
2.7.0.25.gfc10eb5.dirty



From javier at osg.samsung.com  Tue Feb  9 03:08:14 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Tue,  9 Feb 2016 08:08:14 -0300
Subject: [PATCH] rtc: mt6397: Add platform device ID table
Message-ID: <1455016095-13724-1-git-send-email-javier@osg.samsung.com>

The platform bus_type .match callback attempts to match the platform device
name with an entry on the .id_table if provided and fallbacks to match with
the driver's name if a table is not provided.

Using a platform device ID to match is more explicit, allows the driver to
support more than one device and also the MODULE_DEVICE_TABLE macro can be
used to export the module aliases information instead of the MODULE_ALIAS.

Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>

---

 drivers/rtc/rtc-mt6397.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index 06a5c52b292f..46533f11f7fc 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -404,6 +404,12 @@ static const struct of_device_id mt6397_rtc_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, mt6397_rtc_of_match);
 
+static const struct platform_device_id mt6397_rtc_id[] = {
+	{"mt6397-rtc", 0},
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(platform, mt6397_rtc_id);
+
 static struct platform_driver mtk_rtc_driver = {
 	.driver = {
 		.name = "mt6397-rtc",
@@ -412,6 +418,7 @@ static struct platform_driver mtk_rtc_driver = {
 	},
 	.probe	= mtk_rtc_probe,
 	.remove = mtk_rtc_remove,
+	.id_table = mt6397_rtc_id,
 };
 
 module_platform_driver(mtk_rtc_driver);
@@ -419,4 +426,3 @@ module_platform_driver(mtk_rtc_driver);
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Tianping Fang <tianping.fang at mediatek.com>");
 MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC");
-MODULE_ALIAS("platform:mt6397-rtc");
-- 
2.5.0



From arnd at arndb.de  Tue Feb  9 03:14:15 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 12:14:15 +0100
Subject: [PATCH] ARM: ks8695: fix __initdata annotation
In-Reply-To: <20160209090030.GS13664@pengutronix.de>
References: <1454941509-2773774-1-git-send-email-arnd@arndb.de>
 <20160209090030.GS13664@pengutronix.de>
Message-ID: <18237653.x9qPaNvtCU@wuerfel>

On Tuesday 09 February 2016 10:00:30 Uwe Kleine-K?nig wrote:
> > diff --git a/arch/arm/mach-ks8695/board-og.c b/arch/arm/mach-ks8695/board-og.c
> > index 1f4f2f4f25bb..fa1a7c2ca2bb 100644
> > --- a/arch/arm/mach-ks8695/board-og.c
> > +++ b/arch/arm/mach-ks8695/board-og.c
> > @@ -80,7 +80,7 @@ static void __init og_pci_bus_reset(void)
> >  #define      S8250_VIRT      0xf4000000
> >  #define      S8250_SIZE      0x00100000
> >  
> > -static struct __initdata map_desc og_io_desc[] = {
> > +static struct map_desc __initdata og_io_desc[] = {
> 
> I would have expected that
> 
> +static struct map_desc og_io_desc[] __initdata = {
> 
> is the correct variant?
> 

I think those two mean the exact same thing, and we have tons of examples
for either one in the kernel, unlike the one I removed. I have
verified that the resulting object files are identical.

Can you point me to some documentation that clarifies which one to use,
and why?

	Arnd


From stefano.stabellini at eu.citrix.com  Tue Feb  9 03:19:02 2016
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 9 Feb 2016 11:19:02 +0000
Subject: [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen
In-Reply-To: <2213954.ztOe55fprN@vostro.rjw.lan>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
 <CAJZ5v0id-035AtyQ_SccPuCxD7+pa6GCgj3WBAojM+rFqssGQQ@mail.gmail.com>
 <alpine.DEB.2.02.1602081054350.27008@kaball.uk.xensource.com>
 <2213954.ztOe55fprN@vostro.rjw.lan>
Message-ID: <alpine.DEB.2.02.1602091116240.27008@kaball.uk.xensource.com>

On Mon, 8 Feb 2016, Rafael J. Wysocki wrote:
> On Monday, February 08, 2016 10:57:01 AM Stefano Stabellini wrote:
> > On Sat, 6 Feb 2016, Rafael J. Wysocki wrote:
> > > On Fri, Feb 5, 2016 at 4:05 AM, Shannon Zhao <zhaoshenglong at huawei.com> wrote:
> > > > From: Shannon Zhao <shannon.zhao at linaro.org>
> > > >
> > > > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > > > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > > > UART is used by Xen. So here it hides UART from Dom0.
> > > >
> > > > Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> > > > Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> > > 
> > > Well, this doesn't look right to me.
> > > 
> > > We need to find a nicer way to achieve what you want.
> > 
> > I take that you are talking about how to honor the STAO table in Linux.
> > Do you have any concrete suggestions?
> 
> I do.
> 
> The last hunk of the patch is likely what it needs to be, although I'm
> not sure if the place it is added to is the right one.  That's a minor thing,
> though.
> 
> The other part is problematic.  Not that as it doesn't work, but because of
> how it works.  With these changes the device will be visible to the OS (in
> fact to user space even), but will never be "present".  I'm not sure if
> that's what you want?
> 
> It might be better to add a check to acpi_bus_type_and_status() that will
> evaluate the "should ignore?" thing and return -ENODEV if this is true.  This
> way the device won't be visible at all.

Something like below?  Actually your suggestion is better, thank you!

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 78d5f02..4778c51 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1455,6 +1455,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
 	if (ACPI_FAILURE(status))
 		return -ENODEV;
 
+	if (acpi_check_device_is_ignored(handle))
+		return -ENODEV;
+
 	switch (acpi_type) {
 	case ACPI_TYPE_ANY:		/* for ACPI_ROOT_OBJECT */
 	case ACPI_TYPE_DEVICE:



From julien.grall at arm.com  Tue Feb  9 03:23:55 2016
From: julien.grall at arm.com (Julien Grall)
Date: Tue, 9 Feb 2016 11:23:55 +0000
Subject: [PATCH 3/5] irqchip/gic-v2: Parse and export virtual GIC
 information
In-Reply-To: <56B8DEB8.4010509@arm.com>
References: <1454950049-741-1-git-send-email-julien.grall@arm.com>
 <1454950049-741-4-git-send-email-julien.grall@arm.com>
 <56B8DEB8.4010509@arm.com>
Message-ID: <56B9CC4B.90403@arm.com>

On 08/02/16 18:30, Marc Zyngier wrote:
> Julien,

Hi Marc,

> On 08/02/16 16:47, Julien Grall wrote:

[...]

>> +static void __init gic_of_setup_kvm_info(struct device_node *node)
>> +{
>> +	int ret;
>> +	struct resource r;
>> +	unsigned int irq;
>> +
>> +	gic_v2_kvm_info.type = GIC_V2;
>> +
>> +	irq = irq_of_parse_and_map(node, 0);
>> +	if (!irq)
>> +		gic_v2_kvm_info.maint_irq = -1;
>
> Please don't do that. 0 *is* the value for an invalid interrupt, and
> this is what you should expose here. Same for GICv3.

I decided to use -1, because the function acpi_register_gsi is returning 
a negative value when an error occurred.

AFAICT, returning 0 would be a valid value for acpi_register_gsi.

>> +	else
>> +		gic_v2_kvm_info.maint_irq = irq;
>> +
>> +	ret = of_address_to_resource(node, 2, &r);
>> +	if (!ret) {
>> +		gic_v2_kvm_info.vctrl_base = r.start;
>> +		gic_v2_kvm_info.vctrl_size = resource_size(&r);
>> +	}
>> +
>> +	ret = of_address_to_resource(node, 3, &r);
>> +	if (!ret) {
>> +		if (!PAGE_ALIGNED(r.start))
>> +			pr_warn("GICV physical address 0x%llx not page aligned\n",
>> +				(unsigned long long)r.start);
>> +		else if (!PAGE_ALIGNED(resource_size(&r)))
>> +			pr_warn("GICV size 0x%llx not a multiple of page size 0x%lx\n",
>> +				(unsigned long long)resource_size(&r),
>> +				PAGE_SIZE);
>> +		else {
>> +			gic_v2_kvm_info.vcpu_base = r.start;
>> +			gic_v2_kvm_info.vcpu_size = resource_size(&r);
>
> This tends to make me think that this should actually be a proper
> resource, and not a set of arbitrary fields.

I will give a look.

[..]

>> @@ -1270,6 +1338,12 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
>>   		return -EINVAL;
>>
>>   	cpu_phy_base = gic_cpu_base;
>> +	acpi_data.maint_irq = processor->vgic_interrupt;
>> +	acpi_data.maint_irq_mode = (processor->flags & ACPI_MADT_VGIC_IRQ_MODE) ?
>> +				    ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
>> +	acpi_data.vctrl_base = processor->gich_base_address;
>> +	acpi_data.vcpu_base = processor->gicv_base_address;
>> +
>
> Maybe you can now move all the ACPI data into this acpi_data structure?
> This would allow for slightly less clutter...

Good idea, I will do it in the next version.

[...]

>
> Thanks,

Regards,

-- 
Julien Grall


From djkurtz at chromium.org  Tue Feb  9 03:29:26 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Tue, 9 Feb 2016 19:29:26 +0800
Subject: [PATCH v4 4/8] dt-bindings: Add a binding for Mediatek Video
 Encoder
In-Reply-To: <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <CAGS+omDQW+yqhixCWPfQb9eaHeufgiEDscrvXGwBTc05+eDGCQ@mail.gmail.com>

Hi Tiffany,

On Thu, Feb 4, 2016 at 7:34 PM, Tiffany Lin <tiffany.lin at mediatek.com> wrote:
> Add a DT binding documentation of Video Encoder for the
> MT8173 SoC from Mediatek.
>
> Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
> ---
>  .../devicetree/bindings/media/mediatek-vcodec.txt  |   59 ++++++++++++++++++++
>  1 file changed, 59 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> new file mode 100644
> index 0000000..572bfdd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> @@ -0,0 +1,59 @@
> +Mediatek Video Codec
> +
> +Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
> +supports high resolution encoding functionalities.
> +
> +Required properties:
> +- compatible : "mediatek,mt8173-vcodec-enc" for encoder
> +- reg : Physical base address of the video codec registers and length of
> +  memory mapped region.
> +- interrupts : interrupt number to the cpu.
> +- mediatek,larb : must contain the local arbiters in the current Socs.
> +- clocks : list of clock specifiers, corresponding to entries in
> +  the clock-names property.
> +- clock-names: encoder must contain "vencpll_d2", "venc_sel", "univpll1_d2",
> +  "venc_lt_sel".
> +- iommus : should point to the respective IOMMU block with master port as
> +  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> +  for details.
> +- mediatek,vpu : the node of video processor unit
> +
> +Example:
> +vcodec_enc: vcodec at 0x18002000 {
> +    compatible = "mediatek,mt8173-vcodec-enc";
> +    reg = <0 0x18002000 0 0x1000>,    /*VENC_SYS*/
> +          <0 0x19002000 0 0x1000>;    /*VENC_LT_SYS*/

This really looks like two encoder devices combined into a single
device tree node.
There are two register sets, two irqs, two sets of iommus, and two
sets of clocks.

If possible, please split this node into two, one for each encoder.


> +    interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>,
> +           <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>;
> +    mediatek,larb = <&larb3>,
> +                   <&larb5>;
> +    iommus = <&iommu M4U_PORT_VENC_RCPU>,
> +             <&iommu M4U_PORT_VENC_REC>,
> +             <&iommu M4U_PORT_VENC_BSDMA>,
> +             <&iommu M4U_PORT_VENC_SV_COMV>,
> +             <&iommu M4U_PORT_VENC_RD_COMV>,
> +             <&iommu M4U_PORT_VENC_CUR_LUMA>,
> +             <&iommu M4U_PORT_VENC_CUR_CHROMA>,
> +             <&iommu M4U_PORT_VENC_REF_LUMA>,
> +             <&iommu M4U_PORT_VENC_REF_CHROMA>,
> +             <&iommu M4U_PORT_VENC_NBM_RDMA>,
> +             <&iommu M4U_PORT_VENC_NBM_WDMA>,
> +             <&iommu M4U_PORT_VENC_RCPU_SET2>,
> +             <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
> +             <&iommu M4U_PORT_VENC_BSDMA_SET2>,
> +             <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
> +             <&iommu M4U_PORT_VENC_RD_COMA_SET2>,
> +             <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
> +             <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
> +             <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
> +             <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
> +    mediatek,vpu = <&vpu>;
> +    clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
> +             <&topckgen CLK_TOP_VENC_SEL>,
> +             <&topckgen CLK_TOP_UNIVPLL1_D2>,
> +             <&topckgen CLK_TOP_VENC_LT_SEL>;
> +    clock-names = "vencpll_d2",
> +                  "venc_sel",
> +                  "univpll1_d2",
> +                  "venc_lt_sel";

The names of these clocks should be from the perspective of the
encoder, not the clock provider.

-Dan

> +  };
> --
> 1.7.9.5
>


From marc.zyngier at arm.com  Tue Feb  9 03:31:55 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 9 Feb 2016 11:31:55 +0000
Subject: [PATCH 3/5] irqchip/gic-v2: Parse and export virtual GIC
 information
In-Reply-To: <56B9CC4B.90403@arm.com>
References: <1454950049-741-1-git-send-email-julien.grall@arm.com>
 <1454950049-741-4-git-send-email-julien.grall@arm.com>
 <56B8DEB8.4010509@arm.com> <56B9CC4B.90403@arm.com>
Message-ID: <56B9CE2B.4040709@arm.com>

On 09/02/16 11:23, Julien Grall wrote:
> On 08/02/16 18:30, Marc Zyngier wrote:
>> Julien,
> 
> Hi Marc,
> 
>> On 08/02/16 16:47, Julien Grall wrote:
> 
> [...]
> 
>>> +static void __init gic_of_setup_kvm_info(struct device_node *node)
>>> +{
>>> +	int ret;
>>> +	struct resource r;
>>> +	unsigned int irq;
>>> +
>>> +	gic_v2_kvm_info.type = GIC_V2;
>>> +
>>> +	irq = irq_of_parse_and_map(node, 0);
>>> +	if (!irq)
>>> +		gic_v2_kvm_info.maint_irq = -1;
>>
>> Please don't do that. 0 *is* the value for an invalid interrupt, and
>> this is what you should expose here. Same for GICv3.
> 
> I decided to use -1, because the function acpi_register_gsi is returning 
> a negative value when an error occurred.
> 
> AFAICT, returning 0 would be a valid value for acpi_register_gsi.

No really. It either returns -EINVAL, or the result of
irq_create_fwspec_mapping, which is either going to return a virtual
interrupt number (strictly positive), or zero if the mapping was impossible.

So anything <= 0 is an error, and you can use 0 to indicate it. In
general, there is no such thing as IRQ0 (if you're not convinced, please
argue with Linus: http://yarchive.net/comp/linux/zero.html).

>>> +	else
>>> +		gic_v2_kvm_info.maint_irq = irq;
>>> +
>>> +	ret = of_address_to_resource(node, 2, &r);
>>> +	if (!ret) {
>>> +		gic_v2_kvm_info.vctrl_base = r.start;
>>> +		gic_v2_kvm_info.vctrl_size = resource_size(&r);
>>> +	}
>>> +
>>> +	ret = of_address_to_resource(node, 3, &r);
>>> +	if (!ret) {
>>> +		if (!PAGE_ALIGNED(r.start))
>>> +			pr_warn("GICV physical address 0x%llx not page aligned\n",
>>> +				(unsigned long long)r.start);
>>> +		else if (!PAGE_ALIGNED(resource_size(&r)))
>>> +			pr_warn("GICV size 0x%llx not a multiple of page size 0x%lx\n",
>>> +				(unsigned long long)resource_size(&r),
>>> +				PAGE_SIZE);
>>> +		else {
>>> +			gic_v2_kvm_info.vcpu_base = r.start;
>>> +			gic_v2_kvm_info.vcpu_size = resource_size(&r);
>>
>> This tends to make me think that this should actually be a proper
>> resource, and not a set of arbitrary fields.
> 
> I will give a look.
> 
> [..]
> 
>>> @@ -1270,6 +1338,12 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
>>>   		return -EINVAL;
>>>
>>>   	cpu_phy_base = gic_cpu_base;
>>> +	acpi_data.maint_irq = processor->vgic_interrupt;
>>> +	acpi_data.maint_irq_mode = (processor->flags & ACPI_MADT_VGIC_IRQ_MODE) ?
>>> +				    ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
>>> +	acpi_data.vctrl_base = processor->gich_base_address;
>>> +	acpi_data.vcpu_base = processor->gicv_base_address;
>>> +
>>
>> Maybe you can now move all the ACPI data into this acpi_data structure?
>> This would allow for slightly less clutter...
> 
> Good idea, I will do it in the next version.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From broonie at kernel.org  Tue Feb  9 03:32:04 2016
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Feb 2016 11:32:04 +0000
Subject: [PATCH 07/11] ARM: dts: sunxi: Add dtsi file for AXP809 PMIC
In-Reply-To: <CAGb2v66a=LLMBEbrR2qCzuYp+-fa96qLROFN10+aNvfGTtW-Zg@mail.gmail.com>
References: <1454408864-24112-1-git-send-email-wens@csie.org>
 <1454408864-24112-8-git-send-email-wens@csie.org>
 <20160202121733.GO4455@sirena.org.uk>
 <CAGb2v657zYT30KbuK0fyVOmhv0kzJjj9gTsTFRaS4i3d6YhiHQ@mail.gmail.com>
 <20160208145347.GD7265@sirena.org.uk>
 <CAGb2v64ySLAVbPf_XaZnzm5T=SmQLip4iO2p4cGXg=C0=51eqA@mail.gmail.com>
 <20160208162244.GG7265@sirena.org.uk>
 <CAGb2v66a=LLMBEbrR2qCzuYp+-fa96qLROFN10+aNvfGTtW-Zg@mail.gmail.com>
Message-ID: <20160209113204.GC13270@sirena.org.uk>

On Tue, Feb 09, 2016 at 01:41:37PM +0800, Chen-Yu Tsai wrote:
> On Tue, Feb 9, 2016 at 12:22 AM, Mark Brown <broonie at kernel.org> wrote:

> > The whole point with constraints is that they describe what is safe on a
> > given board.  This includes powering off unused regulators - it should
> > be something that the system integrator configures, not something that
> > they get as default.

> OK. So how should one describe a regulator as unused? Just leave it out
> since it's not wired to anything? Or have an empty node at the board
> level? One of the regulators involved on my board is by (hardware)
> default on.

Like I say do it at the board level, you know it's not connected on that
board but another board may use it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/a5356163/attachment.sig>

From u.kleine-koenig at pengutronix.de  Tue Feb  9 03:36:24 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Tue, 9 Feb 2016 12:36:24 +0100
Subject: [PATCH] ARM: ks8695: fix __initdata annotation
In-Reply-To: <18237653.x9qPaNvtCU@wuerfel>
References: <1454941509-2773774-1-git-send-email-arnd@arndb.de>
 <20160209090030.GS13664@pengutronix.de>
 <18237653.x9qPaNvtCU@wuerfel>
Message-ID: <20160209113624.GU13664@pengutronix.de>

Hello Arnd,

On Tue, Feb 09, 2016 at 12:14:15PM +0100, Arnd Bergmann wrote:
> On Tuesday 09 February 2016 10:00:30 Uwe Kleine-K?nig wrote:
> > > diff --git a/arch/arm/mach-ks8695/board-og.c b/arch/arm/mach-ks8695/board-og.c
> > > index 1f4f2f4f25bb..fa1a7c2ca2bb 100644
> > > --- a/arch/arm/mach-ks8695/board-og.c
> > > +++ b/arch/arm/mach-ks8695/board-og.c
> > > @@ -80,7 +80,7 @@ static void __init og_pci_bus_reset(void)
> > >  #define      S8250_VIRT      0xf4000000
> > >  #define      S8250_SIZE      0x00100000
> > >  
> > > -static struct __initdata map_desc og_io_desc[] = {
> > > +static struct map_desc __initdata og_io_desc[] = {
> > 
> > I would have expected that
> > 
> > +static struct map_desc og_io_desc[] __initdata = {
> > 
> > is the correct variant?
> > 
> 
> I think those two mean the exact same thing, and we have tons of examples
> for either one in the kernel, unlike the one I removed. I have
> verified that the resulting object files are identical.
> 
> Can you point me to some documentation that clarifies which one to use,
> and why?

Having the attribute list after the declarator isn't recommended as
explicit as I remember having read it somewhere in the gcc docs.

	info gcc "Attribute Syntax"

has:

	 An attribute specifier list may appear immediately before a declarator
	(other than the first) in a comma-separated list of declarators in a
	declaration of more than one identifier using a single list of
	specifiers and qualifiers.  Such attribute specifiers apply only to the
	identifier before whose declarator they appear.  For example, in

	     __attribute__((noreturn)) void d0 (void),
		 __attribute__((format(printf, 1, 2))) d1 (const char *, ...),
		  d2 (void)

	the 'noreturn' attribute applies to all the functions declared; the
	'format' attribute only applies to 'd1'.

(Funny enough, in the example the attribute specifier list doesn't
appear *immediately* before the declarator d0.)

This might be interpreted as "usually the attribute specifier list appears
after the declarator". Other than that I cannot find an explict
recommended placement in the docs. The examples in

	info gcc "Variable Attributes"

always have the attribute list after the declarator.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From peter.ujfalusi at ti.com  Tue Feb  9 03:46:57 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Tue, 9 Feb 2016 13:46:57 +0200
Subject: [PATCH] ARM: DTS: am57xx-beagle-x15: Select SYS_CLK2 for audio clocks
Message-ID: <1455018417-2608-1-git-send-email-peter.ujfalusi@ti.com>

The tlv320aic3104 codec's master clock is coming from the SoC's CLKOUT2.
Select the SYS_CLK2 (via divider) as parent clock for CLKOUT2 and select
the same clock (SYS_CLK2) for McASP3 AHCLKX clock as well.
SYS_CLK2 is sourced from an external oscillator running 22.5792MHz and it
is coming in to the SoC via the X1_OSC1.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index c37a5193f199..592e65c3a4e0 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -173,6 +173,8 @@
 
 		sound0_master: simple-audio-card,codec {
 			sound-dai = <&tlv320aic3104>;
+			assigned-clocks = <&clkoutmux2_clk_mux>;
+			assigned-clock-parents = <&sys_clk2_dclk_div>;
 			clocks = <&clkout2_clk>;
 		};
 	};
@@ -795,6 +797,8 @@
 	pinctrl-names = "default", "sleep";
 	pinctrl-0 = <&mcasp3_pins_default>;
 	pinctrl-1 = <&mcasp3_pins_sleep>;
+	assigned-clocks = <&mcasp3_ahclkx_mux>;
+	assigned-clock-parents = <&sys_clkin2>;
 	status = "okay";
 
 	op-mode = <0>;	/* MCASP_IIS_MODE */
-- 
2.7.1



From kernel at martin.sperl.org  Tue Feb  9 03:47:16 2016
From: kernel at martin.sperl.org (kernel at martin.sperl.org)
Date: Tue,  9 Feb 2016 11:47:16 +0000
Subject: [PATCH] serial: bcm2835: fix unsigned int issue with irq
Message-ID: <1455018437-2405-1-git-send-email-kernel@martin.sperl.org>

From: Martin Sperl <kernel at martin.sperl.org>

Fixes error condition check when requesting the irq,
that would not trigger because of uart_port.irq being
defined as unsigned int.

Reported by: Dan Carpenter <dan.carpenter at oracle.com>
Signed-off-by: Martin Sperl <kernel at martin.sperl.org>
---
 drivers/tty/serial/8250/8250_bcm2835aux.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_bcm2835aux.c b/drivers/tty/serial/8250/8250_bcm2835aux.c
index ecf89f1..e10f124 100644
--- a/drivers/tty/serial/8250/8250_bcm2835aux.c
+++ b/drivers/tty/serial/8250/8250_bcm2835aux.c
@@ -59,12 +59,12 @@ static int bcm2835aux_serial_probe(struct platform_device *pdev)
 	}
 
 	/* get the interrupt */
-	data->uart.port.irq = platform_get_irq(pdev, 0);
-	if (data->uart.port.irq < 0) {
-		dev_err(&pdev->dev, "irq not found - %i",
-			data->uart.port.irq);
-		return data->uart.port.irq;
+	ret = platform_get_irq(pdev, 0);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "irq not found - %i", ret);
+		return ret;
 	}
+	data->uart.port.irq = ret;
 
 	/* map the main registers */
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-- 
1.7.10.4



From marc.zyngier at arm.com  Tue Feb  9 03:48:26 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 9 Feb 2016 11:48:26 +0000
Subject: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <CABM=7k=-Y+eFB2nUMfMjd3saTSNDsEyfHyYNf-ef8qQc5jCsxA@mail.gmail.com>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
 <56B8B45D.1020902@arm.com> <20160209085633.GA5388@kwain>
 <20160209090131.GB5388@kwain> <56B9ACE2.1060200@arm.com>
 <CABM=7knaepbyy4nw_GczVM7E_t6py7gG0ERs8ru_AYoVXvAQ+A@mail.gmail.com>
 <56B9B1B5.5070106@arm.com>
 <CABM=7k=-Y+eFB2nUMfMjd3saTSNDsEyfHyYNf-ef8qQc5jCsxA@mail.gmail.com>
Message-ID: <56B9D20A.8010709@arm.com>

On 09/02/16 10:13, Tsahee Zidenberg wrote:
> On 9 February 2016 at 11:30, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>
>> On 09/02/16 09:14, Tsahee Zidenberg wrote:
>>>
>>>
>>> On 9 February 2016 at 11:09, Marc Zyngier <marc.zyngier at arm.com
>>> <mailto:marc.zyngier at arm.com>> wrote:
>>>
>>>     On 09/02/16 09:01, Antoine Tenart wrote:
>>>     > On Tue, Feb 09, 2016 at 09:56:33AM +0100, Antoine Tenart wrote:
>>>     >> Hi Marc,
>>>     >>
>>>     >> On Mon, Feb 08, 2016 at 03:29:33PM +0000, Marc Zyngier wrote:
>>>     >>> On 08/02/16 09:11, Antoine Tenart wrote:
>>>     >>>
>>>     >>>> +          gic: gic at f0100000 {
>>>     >>>> +                  compatible = "arm,gic-v3";
>>>     >>>> +                  reg = <0x0 0xf0200000 0x0 0x10000>,     /* GIC Dist */
>>>     >>>> +                        <0x0 0xf0280000 0x0 0x200000>,    /* GICR */
>>>     >>>> +                        <0x0 0xf0100000 0x0 0x2000>;      /* GICC */
>>>     >>>> +                  interrupt-controller;
>>>     >>>> +                  #interrupt-cells = <3>;
>>>     >>>> +          };
>>>     >>>
>>>     >>> Something is wrong here. Either you are missing GICH and GICV (assuming
>>>     >>> you have legacy support), or you have an extra GICC region (which
>>>     >>> doesn't make sense on its own).
>>>     >>
>>>     >> I'll add the missing regions.
>>>     >
>>>     > Hmm, in fact the GICC region shouldn't be there. I'll make some tests
>>>     > and remove it.
>>>
>>>     If you have a GICv3 with legacy support, you will probably have GICC,
>>>     GICH and GICV. Linux itself will only use GICD and GICR, but it needs at
>>>     least GICV to be able to virtualize GICv2 guests. And GICV is not
>>>     allowed to exist without GICC and GICH, so I really recommend that you
>>>     keep GICC around.
>>>
>>>
>>> We use the GIC without legacy support (we disable it in early boot
>>> stages), so I think removing the GICC region is the better solution.
>>
>> Disabling legacy support doesn't mean that:
>> - the HW isn't present
>> - the associated regions are not useful
>>
> By "disabling lecgacy support in early boot" I don't just mean that
> ARE bit will be set, but it will actually be RAO/WI. There will be no
> way for SW to enable it and use these registers (which, sadly, means
> that there will be no way to enable gicv2 virtualization). If you
> insist - I will dig up the supposed location of GICV and GICH - yet it
> will be both untested and entirely unusable.

Just to make sure you are not missing the point: ARE==1 does *not* mean
that GICV is unusable. Quite the opposite. It only makes it illegal to
use GICC and GICH, but leaves GICV usable for a guest.

So the real question is: do you have any additional HW that would
actively prevent GICV from being used? If the answer to that is "no",
and assuming your GICv3 implementation is compliant with the
architecture, then GICV will be usable, and you should document all 3
regions.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From robin.murphy at arm.com  Tue Feb  9 03:52:20 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue, 9 Feb 2016 11:52:20 +0000
Subject: [PATCH] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <1454698027-20911-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1454698027-20911-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <56B9D2F4.8070308@arm.com>

On 05/02/16 18:47, tchalamarla at caviumnetworks.com wrote:
> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>
> An issue exists whereby the Linux kernel requires that ASIDs are a
> unique namespace per SMMU.

I too tend to consider the SMMUv2 architecture an "issue", but we should 
probably still call it by its name ;)

>  That ASID-local choice conflicts with the
> CN88xx SMMU, where only shared ASID namespaces are supported;
> specifically within a given node SMMU0 and SMMU1 share, as does SMMU2
> and SMMU3. CN88xx SMMU also requires global VMIDs.

"Global" meaning unique across all 4 SMMUs? Or just unique across each 
pair as per ASIDs?...

> This patch tries to address these issuee by supplying asid and vmid
> transformations from devicetree.
>
> Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> ---
>   .../devicetree/bindings/iommu/arm,smmu.txt         | 16 ++++++
>   drivers/iommu/arm-smmu.c                           | 59 ++++++++++++++++++----
>   2 files changed, 65 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index 7180745..eef06d0 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -55,6 +55,22 @@ conditions.
>                     aliases of secure registers have to be used during
>                     SMMU configuration.
>
> +- thunderx,smmu-asid-transform	: Enable proper handling for buggy
> +		  implementations that require special transformations
> +		  for smmu asid. if this property exists asid-transform
> +		  property must be present.
> +
> +- thunderx,smmu-vmid-transform	: Enable proper handling for buggy
> +		  implementations that require special transformations
> +		  for smmu vmid. if this property exists vmid-transform
> +		  property must be present.
> +
> +- asid-transform 	: Transform mask that needs to be applied to asid.
> +			This property has to be specified as '/bits/ 8' value.
> +
> +- vmid-transform 	: Transform mask that needs to be applied to vmid.
> +			This property has to be specified as '/bits/ 8' value.
> +

...because I've seen a ThunderX boot log indicating 4x128 context banks, 
and I don't see how applying an 8-bit mask to an 8-bit value is going to 
produce anything _globally_ unique in that case.

Regardless, I'm not sure this is an accurate description of the hardware 
as DT should be - this is more implying that each SMMU _requires_ a 
particular set of ASIDs/VMIDs to be used, which is not the same thing 
that the commit message and other comments say.

Robin.

>   Example:
>
>           smmu {
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 59ee4b8..8047834 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -300,8 +300,12 @@ struct arm_smmu_device {
>   	u32				features;
>
>   #define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
> +#define ARM_SMMU_OPT_TRANSFORM_ASID	(1 << 1)
> +#define ARM_SMMU_OPT_TRANSFORM_VMID	(1 << 2)
>   	u32				options;
>   	enum arm_smmu_arch_version	version;
> +	u8				asid_transform;
> +	u8				vmid_transform;
>
>   	u32				num_context_banks;
>   	u32				num_s2_context_banks;
> @@ -330,8 +334,25 @@ struct arm_smmu_cfg {
>   };
>   #define INVALID_IRPTNDX			0xff
>
> -#define ARM_SMMU_CB_ASID(cfg)		((cfg)->cbndx)
> -#define ARM_SMMU_CB_VMID(cfg)		((cfg)->cbndx + 1)
> +/*
> + * ThunderX has a unique requirement because of ERRATA#27704
> + * An issue exists whereby the Linux kernel requires that ASIDs are a
> + * unique namespace per SMMU.  That ASID-local choice conflicts with the
> + * CN88xx SMMU, where only shared ASID namespaces are supported;
> + * specifically within a given node SMMU0 and SMMU1 share, as does SMMU2
> + * and SMMU3.
> + * CN88xx SMMU also requires global VMIDs.
> + */
> +
> +#define ARM_SMMU_CB_ASID(smmu, cfg)					\
> +		(((smmu)->options & ARM_SMMU_OPT_TRANSFORM_ASID)	\
> +		? ((cfg)->cbndx | (smmu)->asid_transform)		\
> +		: ((cfg)->cbndx))
> +
> +#define ARM_SMMU_CB_VMID(smmu, cfg)					\
> +		(((smmu)->options & ARM_SMMU_OPT_TRANSFORM_VMID)	\
> +		? (((cfg)->cbndx + 1) | (smmu)->vmid_transform)		\
> +		: ((cfg)->cbndx + 1))
>
>   enum arm_smmu_domain_stage {
>   	ARM_SMMU_DOMAIN_S1 = 0,
> @@ -361,6 +382,8 @@ struct arm_smmu_option_prop {
>
>   static struct arm_smmu_option_prop arm_smmu_options[] = {
>   	{ ARM_SMMU_OPT_SECURE_CFG_ACCESS, "calxeda,smmu-secure-config-access" },
> +	{ ARM_SMMU_OPT_TRANSFORM_ASID, "thunderx,smmu-asid-transform" },
> +	{ ARM_SMMU_OPT_TRANSFORM_VMID, "thunderx,smmu-vmid-transform" },
>   	{ 0, NULL},
>   };
>
> @@ -570,11 +593,11 @@ static void arm_smmu_tlb_inv_context(void *cookie)
>
>   	if (stage1) {
>   		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
> -		writel_relaxed(ARM_SMMU_CB_ASID(cfg),
> +		writel_relaxed(ARM_SMMU_CB_ASID(smmu, cfg),
>   			       base + ARM_SMMU_CB_S1_TLBIASID);
>   	} else {
>   		base = ARM_SMMU_GR0(smmu);
> -		writel_relaxed(ARM_SMMU_CB_VMID(cfg),
> +		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg),
>   			       base + ARM_SMMU_GR0_TLBIVMID);
>   	}
>
> @@ -596,7 +619,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>
>   		if (!IS_ENABLED(CONFIG_64BIT) || smmu->version == ARM_SMMU_V1) {
>   			iova &= ~12UL;
> -			iova |= ARM_SMMU_CB_ASID(cfg);
> +			iova |= ARM_SMMU_CB_ASID(smmu, cfg);
>   			do {
>   				writel_relaxed(iova, reg);
>   				iova += granule;
> @@ -604,7 +627,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>   #ifdef CONFIG_64BIT
>   		} else {
>   			iova >>= 12;
> -			iova |= (u64)ARM_SMMU_CB_ASID(cfg) << 48;
> +			iova |= (u64)ARM_SMMU_CB_ASID(smmu, cfg) << 48;
>   			do {
>   				writeq_relaxed(iova, reg);
>   				iova += granule >> 12;
> @@ -624,7 +647,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>   #endif
>   	} else {
>   		reg = ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_TLBIVMID;
> -		writel_relaxed(ARM_SMMU_CB_VMID(cfg), reg);
> +		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg), reg);
>   	}
>   }
>
> @@ -752,7 +775,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>   		reg |= (CBAR_S1_BPSHCFG_NSH << CBAR_S1_BPSHCFG_SHIFT) |
>   			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
>   	} else {
> -		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
> +		reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBAR_VMID_SHIFT;
>   	}
>   	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
>
> @@ -760,11 +783,11 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>   	if (stage1) {
>   		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>
> -		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
> +		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
>   		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR0);
>
>   		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
> -		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
> +		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
>   		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR1);
>   	} else {
>   		reg64 = pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
> @@ -1793,6 +1816,22 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
>
>   	parse_driver_options(smmu);
>
> +	if (smmu->options & ARM_SMMU_OPT_TRANSFORM_ASID) {
> +		if (of_property_read_u8(dev->of_node, "#asid-transform",
> +					 &smmu->asid_transform)) {
> +			dev_err(dev, "missing #asid-transform property\n");
> +			return -ENODEV;
> +		}
> +	}
> +
> +	if (smmu->options & ARM_SMMU_OPT_TRANSFORM_VMID) {
> +		if (of_property_read_u8(dev->of_node, "#vmid-transform",
> +					 &smmu->vmid_transform)) {
> +			dev_err(dev, "missing #vmid-transform property\n");
> +			return -ENODEV;
> +		}
> +	}
> +
>   	if (smmu->version > ARM_SMMU_V1 &&
>   	    smmu->num_context_banks != smmu->num_context_irqs) {
>   		dev_err(dev,
>



From catalin.marinas at arm.com  Tue Feb  9 03:55:56 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 9 Feb 2016 11:55:56 +0000
Subject: [PATCH 0/4] copy_page improvements
In-Reply-To: <1454417186-21828-1-git-send-email-will.deacon@arm.com>
References: <1454417186-21828-1-git-send-email-will.deacon@arm.com>
Message-ID: <20160209115556.GD16122@e104818-lin.cambridge.arm.com>

On Tue, Feb 02, 2016 at 12:46:22PM +0000, Will Deacon wrote:
> Andrew Pinski (1):
>   arm64: lib: patch in prfm for copy_page if requested
> 
> Will Deacon (3):
>   arm64: prefetch: don't provide spin_lock_prefetch with LSE
>   arm64: prefetch: add alternative pattern for CPUs without a prefetcher
>   arm64: lib: improve copy_page to deal with 128 bytes at a time

Patches queued for 4.6. Thanks.

-- 
Catalin


From Chris.Brandt at renesas.com  Tue Feb  9 04:02:00 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Tue, 9 Feb 2016 12:02:00 +0000
Subject: [PATCH v3 0/3] kallsyms: remove special handling for CONFIG_ARM
In-Reply-To: <1455010262-28894-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455010262-28894-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <HKXPR06MB0565C2168EFA7CFF79C323DA8AD60@HKXPR06MB0565.apcprd06.prod.outlook.com>

On 9 Feb 2016, Ard Biesheuvel wrote:

>Ard Biesheuvel (3):
>  ARM: move .vectors and .stubs sections back into the kernel VMA
>  kallsyms: remove special lower address limit for CONFIG_ARM
>  kallsyms: remove --page-offset command line option
>
> arch/arm/kernel/entry-armv.S  | 3 +--
> arch/arm/kernel/vmlinux.lds.S | 6 ++++--
> scripts/kallsyms.c            | 8 --------
> scripts/link-vmlinux.sh       | 4 ----
> 4 files changed, 5 insertions(+), 16 deletions(-)


The linker script split (XIP vs non-XIP) has been applied, so now there's a vmlinux-xip.lds.S. So, you'd think you would need to mirror these changes in there (since the breakage of XIP_KERNEL is what started this).

Chris



From catalin.marinas at arm.com  Tue Feb  9 04:02:17 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 9 Feb 2016 12:02:17 +0000
Subject: [PATCH v3 23/23] arm64: Panic when VHE and non VHE CPUs coexist
In-Reply-To: <20160208162402.GC14146@leverpostej>
References: <1454522416-6874-1-git-send-email-marc.zyngier@arm.com>
 <1454522416-6874-24-git-send-email-marc.zyngier@arm.com>
 <20160208160445.GS6076@e104818-lin.cambridge.arm.com>
 <20160208162402.GC14146@leverpostej>
Message-ID: <20160209120217.GE16122@e104818-lin.cambridge.arm.com>

On Mon, Feb 08, 2016 at 04:24:03PM +0000, Mark Rutland wrote:
> On Mon, Feb 08, 2016 at 04:04:46PM +0000, Catalin Marinas wrote:
> > On Wed, Feb 03, 2016 at 06:00:16PM +0000, Marc Zyngier wrote:
> > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> > > index 6f2f377..f9b6a5b 100644
> > > --- a/arch/arm64/kernel/head.S
> > > +++ b/arch/arm64/kernel/head.S
> > > @@ -578,7 +578,24 @@ ENTRY(set_cpu_boot_mode_flag)
> > >  1:	str	w20, [x1]			// This CPU has booted in EL1
> > >  	dmb	sy
> > >  	dc	ivac, x1			// Invalidate potentially stale cache line
> > > +	adr_l	x1, __run_cpu_mode
> > > +	ldr	w0, [x1]
> > > +	mrs	x20, CurrentEL
> > > +	cbz	x0, skip_el_check
> > > +	cmp	x0, x20
> > > +	bne	mismatched_el
> > >  	ret
> > > +skip_el_check:			// Only the first CPU gets to set the rule
> > > +	str	w20, [x1]
> > > +	dmb	sy
> > > +	dc	ivac, x1	// Invalidate potentially stale cache line
> > > +	ret
> > > +mismatched_el:
> > > +	str	w20, [x1, #4]
> > > +	dmb	sy
> > > +	dc	ivac, x1	// Invalidate potentially stale cache line
> > > +1:	wfi
> > > +	b	1b
> > >  ENDPROC(set_cpu_boot_mode_flag)
> > 
> > Do we need to wait for the D-cache maintenance completion before
> > entering WFI (like issuing a DSB)? Same for the skip_el_check path
> > before the RET.
> 
> We would need that to complete the maintenance, yes.
> 
> However, given we're going into WFI immediately afterwards, and not
> signalling completion to other CPUs, what we gain is somewhat
> questionable.
> 
> Perhaps it's always better to do the maintenance on the read side (for
> consistency with [1]).
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/404661.html

While [1] looks clearer to me, it seems that it is not consistent with
the rest of the head.S file. Maybe we can clean them up as a separate
patch and leave the dc ivac here. We also seem to miss barriers in other
similar situations in head.S.

-- 
Catalin


From marc.zyngier at arm.com  Tue Feb  9 04:06:06 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 9 Feb 2016 12:06:06 +0000
Subject: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
In-Reply-To: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
References: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
Message-ID: <56B9D62E.8080003@arm.com>

Hi Robin,

On 09/02/16 11:04, Robin Murphy wrote:
> The existing msi-map code is fine for shifting the entire RID space
> upwards, but attempting finer-grained remapping reveals a bug. It turns
> out that we are mistakenly treating the msi-base part as an offset, not
> as a new base to remap onto, so things get squiffy when rid-base is
> nonzero. Fix this, and at the same time add a sanity check against
> having msi-map-mask clash with a nonzero rid-base, as that's another
> thing one can easily get wrong.
> 
> CC: <stable at vger.kernel.org>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>

Looks like Stuart and you both found the same bug at the same time:
https://lkml.org/lkml/2016/2/8/1066

but yours seem more correct to me (the rid_base masking in Stuart's
version seems odd).

> ---
>  drivers/of/irq.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 7ee21ae..e7bfc17 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -635,6 +635,13 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
>  		msi_base = be32_to_cpup(msi_map + 2);
>  		rid_len = be32_to_cpup(msi_map + 3);
>  
> +		if (rid_base & ~map_mask) {
> +			dev_err(parent_dev,
> +				"Invalid msi-map translation - msi-map-mask (0x%x) ignores rid-base (0x%x)\n",
> +				map_mask, rid_base);
> +			return rid_out;
> +		}
> +
>  		msi_controller_node = of_find_node_by_phandle(phandle);
>  
>  		matched = (masked_rid >= rid_base &&
> @@ -654,7 +661,7 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
>  	if (!matched)
>  		return rid_out;
>  
> -	rid_out = masked_rid + msi_base;
> +	rid_out = masked_rid - rid_base + msi_base;
>  	dev_dbg(dev,
>  		"msi-map at: %s, using mask %08x, rid-base: %08x, msi-base: %08x, length: %08x, rid: %08x -> %08x\n",
>  		dev_name(parent_dev), map_mask, rid_base, msi_base,
> 

Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>

	M.
-- 
Jazz is not dead. It just smells funny...


From michal.simek at xilinx.com  Tue Feb  9 04:17:13 2016
From: michal.simek at xilinx.com (Michal Simek)
Date: Tue, 9 Feb 2016 13:17:13 +0100
Subject: [PATCH] ARM: dts: zynq: Enable USB and USB PHY for ZYBO
In-Reply-To: <1454503265-20605-1-git-send-email-nathan@nathanrossi.com>
References: <1454503265-20605-1-git-send-email-nathan@nathanrossi.com>
Message-ID: <56B9D8C9.7060000@xilinx.com>

On 3.2.2016 13:41, Nathan Rossi wrote:
> Setup the USB controller and configure it to operate in host mode.
> Additionally add the USB phy node for the ZYBO, including reset gpio
> which is connected to a external MIO pin.
> 
> Signed-off-by: Nathan Rossi <nathan at nathanrossi.com>
> Cc: Rob Herring <robh+dt at kernel.org>
> Cc: Mark Rutland <mark.rutland at arm.com>
> Cc: Michal Simek <michal.simek at xilinx.com>
> Cc: S?ren Brinkmann <soren.brinkmann at xilinx.com>
> ---
>  arch/arm/boot/dts/zynq-zybo.dts | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/zynq-zybo.dts b/arch/arm/boot/dts/zynq-zybo.dts
> index 16c9cac..8f085b3 100644
> --- a/arch/arm/boot/dts/zynq-zybo.dts
> +++ b/arch/arm/boot/dts/zynq-zybo.dts
> @@ -33,6 +33,11 @@
>  		stdout-path = "serial0:115200n8";
>  	};
>  
> +	usb_phy0: phy0 {
> +		#phy-cells = <0>;
> +		compatible = "usb-nop-xceiv";
> +		reset-gpios = <&gpio0 46 1>;
> +	};
>  };
>  
>  &clkc {
> @@ -56,3 +61,9 @@
>  &uart1 {
>  	status = "okay";
>  };
> +
> +&usb0 {
> +	status = "okay";
> +	dr_mode = "host";
> +	usb-phy = <&usb_phy0>;
> +};
> 


Applied.

Thanks,
Michal


From catalin.marinas at arm.com  Tue Feb  9 04:19:16 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 9 Feb 2016 12:19:16 +0000
Subject: [PATCHv4 0/3] ARCH_SUPPORTS_DEBUG_PAGEALLOC for arm64
In-Reply-To: <1454718288-31374-1-git-send-email-labbott@fedoraproject.org>
References: <1454718288-31374-1-git-send-email-labbott@fedoraproject.org>
Message-ID: <20160209121916.GF16122@e104818-lin.cambridge.arm.com>

On Fri, Feb 05, 2016 at 04:24:45PM -0800, Laura Abbott wrote:
> Laura Abbott (3):
>   arm64: Drop alloc function from create_mapping
>   arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
>   arm64: ptdump: Indicate whether memory should be faulting

Patches queued for 4.6. Thanks.

-- 
Catalin


From jonathanh at nvidia.com  Tue Feb  9 04:26:49 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Tue, 9 Feb 2016 12:26:49 +0000
Subject: [PATCH V3] ARM64: tegra: Add support for Google Pixel C
In-Reply-To: <1454949199-27050-1-git-send-email-jonathanh@nvidia.com>
References: <1454949199-27050-1-git-send-email-jonathanh@nvidia.com>
Message-ID: <1455020809-17531-1-git-send-email-jonathanh@nvidia.com>

Add initial device-tree support for Google Pixel C (a.k.a. Smaug) based
upon Tegra210 SoC with 3 GiB of LPDDR4 RAM.

Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
---

Changes v2 -> v3:
- Added PSCI information to enable all 4 CPUs on boot

Changes v1 -> v2:
- Removed console boot parameter and added stdout-path
- Added 32k clock for PMC

 arch/arm64/boot/dts/nvidia/Makefile           |  1 +
 arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 83 +++++++++++++++++++++++++++
 2 files changed, 84 insertions(+)
 create mode 100644 arch/arm64/boot/dts/nvidia/tegra210-smaug.dts

diff --git a/arch/arm64/boot/dts/nvidia/Makefile b/arch/arm64/boot/dts/nvidia/Makefile
index a7e865da1005..0f7cdf3e05c1 100644
--- a/arch/arm64/boot/dts/nvidia/Makefile
+++ b/arch/arm64/boot/dts/nvidia/Makefile
@@ -2,6 +2,7 @@ dtb-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra132-norrin.dtb
 dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2371-0000.dtb
 dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2371-2180.dtb
 dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2571.dtb
+dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-smaug.dtb
 
 always		:= $(dtb-y)
 clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
new file mode 100644
index 000000000000..750e85c45135
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
@@ -0,0 +1,83 @@
+/dts-v1/;
+
+#include "tegra210.dtsi"
+
+/ {
+	model = "Google Pixel C";
+	compatible = "google,smaug-rev8", "google,smaug-rev7",
+		     "google,smaug-rev6", "google,smaug-rev5",
+		     "google,smaug-rev4", "google,smaug-rev3",
+		     "google,smaug-rev1", "google,smaug", "nvidia,tegra210";
+
+	aliases {
+		serial0 = &uarta;
+	};
+
+	chosen {
+		bootargs = "earlycon";
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x0 0x80000000 0x0 0xc0000000>;
+	};
+
+	serial at 0,70006000 {
+		status = "okay";
+	};
+
+	pmc at 0,7000e400 {
+		nvidia,invert-interrupt;
+		nvidia,suspend-mode = <0>;
+		nvidia,cpu-pwr-good-time = <0>;
+		nvidia,cpu-pwr-off-time = <0>;
+		nvidia,core-pwr-good-time = <12000 6000>;
+		nvidia,core-pwr-off-time = <39053>;
+		nvidia,core-power-req-active-high;
+		nvidia,sys-clock-req-active-high;
+		status = "okay";
+	};
+
+	sdhci at 0,700b0600 {
+		bus-width = <8>;
+		non-removable;
+		status = "okay";
+	};
+
+	clocks {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		clk32k_in: clock at 0 {
+			compatible = "fixed-clock";
+			reg = <0>;
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+	};
+
+	cpus {
+		cpu at 0 {
+			enable-method = "psci";
+		};
+
+		cpu at 1 {
+			enable-method = "psci";
+		};
+
+		cpu at 2 {
+			enable-method = "psci";
+		};
+
+		cpu at 3 {
+			enable-method = "psci";
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+};
-- 
2.1.4



From arnd at arndb.de  Tue Feb  9 04:28:15 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue,  9 Feb 2016 13:28:15 +0100
Subject: [PATCH] drm/tegra: remove unused variable
Message-ID: <1455020923-1089878-1-git-send-email-arnd@arndb.de>

A newly merged patch removed the only user of this variable,
leading to a harmless gcc warning:

drivers/gpu/drm/tegra/drm.c: In function 'tegra_drm_preclose':
drivers/gpu/drm/tegra/drm.c:861:19: error: unused variable 'crtc' [-Werror=unused-variable]

This removes the variable as well.

Cc: Terje Bergstr?m <tbergstrom at nvidia.com>
Cc: Daniel Stone <daniels at collabora.com>
Cc: Alex Deucher <alexander.deucher at amd.com>
Cc: Thierry Reding <treding at nvidia.com>
Cc: Daniel Vetter <daniel.vetter at intel.com>
Fixes: 0417d424ac0d ("drm/tegra: Stop cancelling page flip events")
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/gpu/drm/tegra/drm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 021d0e1398fb..8e6b18caa706 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -858,7 +858,6 @@ static void tegra_drm_preclose(struct drm_device *drm, struct drm_file *file)
 {
 	struct tegra_drm_file *fpriv = file->driver_priv;
 	struct tegra_drm_context *context, *tmp;
-	struct drm_crtc *crtc;
 
 	list_for_each_entry_safe(context, tmp, &fpriv->contexts, list)
 		tegra_drm_context_free(context);
-- 
2.7.0



From nm at ti.com  Tue Feb  9 04:31:44 2016
From: nm at ti.com (Nishanth Menon)
Date: Tue, 9 Feb 2016 06:31:44 -0600
Subject: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager
In-Reply-To: <CABb+yY3kGq_R49Xx4fK3UMqtuFiuv-pXJWvjkEFLPL9xRu5T4A@mail.gmail.com>
References: <1454690044-2560-1-git-send-email-nm@ti.com>
 <1454690044-2560-2-git-send-email-nm@ti.com>
 <CABb+yY3kGq_R49Xx4fK3UMqtuFiuv-pXJWvjkEFLPL9xRu5T4A@mail.gmail.com>
Message-ID: <56B9DC30.5040806@ti.com>

On 02/08/2016 10:14 PM, Jassi Brar wrote:

Thanks for the review.

> On Fri, Feb 5, 2016 at 10:04 PM, Nishanth Menon <nm at ti.com> wrote:
>> +
>> +       msgmgr: msgmgr at 02a00000 {
>> +               compatible = "ti,k2g-message-manager", "ti,message-manager";
>> +               #mbox-cells = <1>;
>> +               reg-names = "queue_proxy_region", "queue_state_debug_region";
>> +               reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
>> +
>> +               msgmgr_proxy_pmmc_tx_prio0: pmmc_tx_prio0 {
>> +                       ti,queue-id = <0>;
>> +                       ti,proxy-id = <0>;
>> +               };
>> +
>> +               msgmgr_proxy_pmmc_rx: pmmc_rx {
>> +                       ti,queue-id = <5>;
>> +                       ti,proxy-id = <2>;
>> +                       interrupt-names = "rx";
>> +                       interrupts = <GIC_SPI 324 IRQ_TYPE_EDGE_RISING>;
>> +               };
>> +       };
>> +
> I think we should get rid of consumer specifics from the provider node...


If I get rid of the consumer nodes, how do you propose I describe the rx
queue interrupt(s) in the msmgr dt node (Every Rx queue will have it's
own interrupt - and it cannot be reverse computed from queue ID, proxy ID)?


>> +...
>> +       pmmc {
>> +               ...
>> +               mbox-names = "tx", "rx";
>> +               mboxes = <&msgmgr &msgmgr_proxy_pmmc_tx>
>> +                        <&msgmgr &msgmgr_proxy_pmmc_rx>;
>> +               ...
>> +       };
>>
> ... and have consumers like
>        pmmc {
>                ...
>                mbox-names = "tx", "rx";
>                mboxes = <&msgmgr 0 0>
>                         <&msgmgr 5 2>;
>        };
> 
> I leave the IRQ for you to decide how to specify - a 'dummy' or
> 'valid' always provided as last cell in mboxes or some other way.
> (I'll review other patches in detail later)

What do we do with the issues that Suman pointed out in the mailbox
framework itself? Could you respond to that thread[1] as well?


[1] http://marc.info/?l=devicetree&m=145496308418123&w=2

-- 
Regards,
Nishanth Menon


From broonie at kernel.org  Tue Feb  9 04:36:49 2016
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Feb 2016 12:36:49 +0000
Subject: [PATCH V5 2/2] regulator: mt6323: Add support for MT6323 regulator
In-Reply-To: <1454874037-38905-2-git-send-email-blogic@openwrt.org>
References: <1454874037-38905-1-git-send-email-blogic@openwrt.org>
 <1454874037-38905-2-git-send-email-blogic@openwrt.org>
Message-ID: <20160209123649.GD13270@sirena.org.uk>

On Sun, Feb 07, 2016 at 08:40:37PM +0100, John Crispin wrote:

> * remove the code allows mode changes

That was excessive, there's no problem having set_mode() operations and
we can currently use them for static configurations.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/952d1a9e/attachment.sig>

From broonie at kernel.org  Tue Feb  9 04:41:33 2016
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Feb 2016 12:41:33 +0000
Subject: [PATCH V5 1/2] regulator: Add document for MT6323 regulator
In-Reply-To: <1454874037-38905-1-git-send-email-blogic@openwrt.org>
References: <1454874037-38905-1-git-send-email-blogic@openwrt.org>
Message-ID: <20160209124133.GE13270@sirena.org.uk>

On Sun, Feb 07, 2016 at 08:40:36PM +0100, John Crispin wrote:

> +Required properties:
> +- compatible: "mediatek,mt6323-regulator"

I'm really not happy with MFD subfunctions like this which add no
information over the parent device name appearing directly in the
binding, it results in us putting Linux specifics about how we split the
device up into the driver.  It's not like this could realistically be
used separately to the parent device.  Just have the MFD create the
device directly or if the individual regulators are reusable IPs which
can share a driver then describe them as such in the DT.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/b8ecaa5a/attachment.sig>

From blogic at openwrt.org  Tue Feb  9 04:45:17 2016
From: blogic at openwrt.org (John Crispin)
Date: Tue, 9 Feb 2016 13:45:17 +0100
Subject: [PATCH V5 1/2] regulator: Add document for MT6323 regulator
In-Reply-To: <20160209124133.GE13270@sirena.org.uk>
References: <1454874037-38905-1-git-send-email-blogic@openwrt.org>
 <20160209124133.GE13270@sirena.org.uk>
Message-ID: <56B9DF5D.2010501@openwrt.org>



On 09/02/2016 13:41, Mark Brown wrote:
> On Sun, Feb 07, 2016 at 08:40:36PM +0100, John Crispin wrote:
> 
>> +Required properties:
>> +- compatible: "mediatek,mt6323-regulator"
> 
> I'm really not happy with MFD subfunctions like this which add no
> information over the parent device name appearing directly in the
> binding, it results in us putting Linux specifics about how we split the
> device up into the driver.  It's not like this could realistically be
> used separately to the parent device.  Just have the MFD create the
> device directly or if the individual regulators are reusable IPs which
> can share a driver then describe them as such in the DT.
> 

Hi Mark,

How would you like it to be. i am failing to understand that from your
comment.

	John


From narmstrong at baylibre.com  Tue Feb  9 04:49:13 2016
From: narmstrong at baylibre.com (Neil Armstrong)
Date: Tue, 9 Feb 2016 13:49:13 +0100
Subject: [PATCH 4/4] pwm: omap-dmtimer: add dev_dbg() message for
 effective period and duty cycle
In-Reply-To: <20160205145146.34ec4eb9.drivshin.allworx@gmail.com>
References: <1454128014-22866-1-git-send-email-drivshin.allworx@gmail.com>
 <1454128014-22866-5-git-send-email-drivshin.allworx@gmail.com>
 <CAA3gFWvSsctXtds6_SEtYY1yUdWJDR1XjznGS6qjdrGW5Dbw=A@mail.gmail.com>
 <20160201132228.2634b72e.drivshin.allworx@gmail.com>
 <20160201185952.GN19432@atomide.com> <20160202162330.GA4918@ulmo>
 <20160202184443.1e1b0bf5.drivshin.allworx@gmail.com>
 <20160203141454.GC9650@ulmo>
 <20160205145146.34ec4eb9.drivshin.allworx@gmail.com>
Message-ID: <56B9E049.5080700@baylibre.com>

On 02/05/2016 08:51 PM, David Rivshin (Allworx) wrote:
> 
> Either way, I think any changes along these lines would probably be 
> cleaner ontop of the atomic update work (assuming some form of that 
> gets merged). And since it would also be outside the scope of this 
> patchset, you may still want to consider the simple debug message 
> in this patch as at least an interim state.
> 

Sure, we should push these patches and rework this one later.

Acked-by: Neil Armstrong <narmstrong at baylibre.com>

Thanks,
Neil


From will.deacon at arm.com  Tue Feb  9 05:22:15 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Feb 2016 13:22:15 +0000
Subject: [PATCH v2] arm64: disable kasan when accessing frame->fp in
 unwind_frame
In-Reply-To: <1454951589-18238-1-git-send-email-yang.shi@linaro.org>
References: <1454951589-18238-1-git-send-email-yang.shi@linaro.org>
Message-ID: <20160209132215.GL22874@arm.com>

On Mon, Feb 08, 2016 at 09:13:09AM -0800, Yang Shi wrote:
> When boot arm64 kernel with KASAN enabled, the below error is reported by
> kasan:
> 
> BUG: KASAN: out-of-bounds in unwind_frame+0xec/0x260 at addr ffffffc064d57ba0
> Read of size 8 by task pidof/499
> page:ffffffbdc39355c0 count:0 mapcount:0 mapping:          (null) index:0x0
> flags: 0x0()
> page dumped because: kasan: bad access detected
> CPU: 2 PID: 499 Comm: pidof Not tainted 4.5.0-rc1 #119
> Hardware name: Freescale Layerscape 2085a RDB Board (DT)
> Call trace:
> [<ffffffc00008d078>] dump_backtrace+0x0/0x290
> [<ffffffc00008d32c>] show_stack+0x24/0x30
> [<ffffffc0006a981c>] dump_stack+0x8c/0xd8
> [<ffffffc0002e4400>] kasan_report_error+0x558/0x588
> [<ffffffc0002e4958>] kasan_report+0x60/0x70
> [<ffffffc0002e3188>] __asan_load8+0x60/0x78
> [<ffffffc00008c92c>] unwind_frame+0xec/0x260
> [<ffffffc000087e60>] get_wchan+0x110/0x160
> [<ffffffc0003b647c>] do_task_stat+0xb44/0xb68
> [<ffffffc0003b7730>] proc_tgid_stat+0x40/0x50
> [<ffffffc0003ac840>] proc_single_show+0x88/0xd8
> [<ffffffc000345be8>] seq_read+0x370/0x770
> [<ffffffc00030aba0>] __vfs_read+0xc8/0x1d8
> [<ffffffc00030c0ec>] vfs_read+0x94/0x168
> [<ffffffc00030d458>] SyS_read+0xb8/0x128
> [<ffffffc000086530>] el0_svc_naked+0x24/0x28
> Memory state around the buggy address:
>  ffffffc064d57a80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4
>  ffffffc064d57b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >ffffffc064d57b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>                                   ^
>  ffffffc064d57c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  ffffffc064d57c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> Since the shadow byte pointed by the report is 0, so it may mean it is just hit
> oob in non-current task. So, disable the instrumentation to silence these
> warnings.
> 
> Signed-off-by: Yang Shi <yang.shi at linaro.org>

Acked-by: Will Deacon <will.deacon at arm.com>

Will


From oded.gabbay at gmail.com  Tue Feb  9 05:39:01 2016
From: oded.gabbay at gmail.com (Oded Gabbay)
Date: Tue, 9 Feb 2016 15:39:01 +0200
Subject: [RESEND PATCH v1] drm: Clean up drm Makefile
In-Reply-To: <20160209092941.GE11240@phenom.ffwll.local>
References: <1454147777-77577-1-git-send-email-xinliang.liu@linaro.org>
 <CAFCwf120-19JKDGGPOBQ4ALg=f5ESG4pVhMeN1s=0uz3OpoFpg@mail.gmail.com>
 <20160209092941.GE11240@phenom.ffwll.local>
Message-ID: <CAFCwf11hRvb1u9SghgJofyVa59B0q8f1JYm=uRofzrm+pvLpTA@mail.gmail.com>

On Tue, Feb 9, 2016 at 11:29 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Sat, Jan 30, 2016 at 01:11:01PM +0200, Oded Gabbay wrote:
>> On Sat, Jan 30, 2016 at 11:56 AM, Xinliang Liu <xinliang.liu at linaro.org> wrote:
>> > This patch cleans up the Makefile of drm root directory.
>> > Make core and device drivers configuration list sorted Alphabetically.
>> >
>> > Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
>> > Reviewed-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
>> > Reviewed-by: Yifan Liu <liu_fanyi at 163.com>
>> > ---
>> >  drivers/gpu/drm/Makefile | 102 ++++++++++++++++++++++++-----------------------
>> >  1 file changed, 52 insertions(+), 50 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> > index 61766dec6a8d..77000717305b 100644
>> > --- a/drivers/gpu/drm/Makefile
>> > +++ b/drivers/gpu/drm/Makefile
>> > @@ -2,6 +2,9 @@
>> >  # Makefile for the drm device driver.  This driver provides support for the
>> >  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>> >
>> > +CFLAGS_drm_trace_points.o := -I$(src)
>> > +
>> > +# core. Please keep this list sorted alphabetically
>> >  drm-y       := drm_auth.o drm_bufs.o drm_cache.o \
>> >                 drm_context.o drm_dma.o \
>> >                 drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
>> > @@ -13,64 +16,63 @@ drm-y       :=      drm_auth.o drm_bufs.o drm_cache.o \
>> >                 drm_trace_points.o drm_global.o drm_prime.o \
>> >                 drm_rect.o drm_vma_manager.o drm_flip_work.o \
>> >                 drm_modeset_lock.o drm_atomic.o drm_bridge.o
>> > -
>> > -drm-$(CONFIG_COMPAT) += drm_ioc32.o
>> > -drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
>> >  drm-$(CONFIG_PCI) += ati_pcigart.o
>> > -drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>> > -drm-$(CONFIG_OF) += drm_of.o
>> >  drm-$(CONFIG_AGP) += drm_agpsupport.o
>> > +drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
>> > +drm-$(CONFIG_COMPAT) += drm_ioc32.o
>> > +drm-$(CONFIG_OF) += drm_of.o
>> > +drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>> > +obj-$(CONFIG_DRM)      += drm.o
>> > +
>> > +obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
>> >
>> >  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
>> >                 drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
>> >  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>> > -drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
>> >  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
>> > -
>> > +drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
>> >  obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
>> >
>> > -CFLAGS_drm_trace_points.o := -I$(src)
>> > +obj-$(CONFIG_DRM_TTM) += ttm/
>> >
>> > -obj-$(CONFIG_DRM)      += drm.o
>> > -obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
>> > -obj-$(CONFIG_DRM_TTM)  += ttm/
>> > -obj-$(CONFIG_DRM_TDFX) += tdfx/
>> > -obj-$(CONFIG_DRM_R128) += r128/
>> > -obj-$(CONFIG_HSA_AMD) += amd/amdkfd/
>> > -obj-$(CONFIG_DRM_RADEON)+= radeon/
>> > -obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
>> > -obj-$(CONFIG_DRM_MGA)  += mga/
>> > -obj-$(CONFIG_DRM_I810) += i810/
>> > -obj-$(CONFIG_DRM_I915)  += i915/
>> > -obj-$(CONFIG_DRM_MGAG200) += mgag200/
>> > -obj-$(CONFIG_DRM_VC4)  += vc4/
>> > -obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
>> > -obj-$(CONFIG_DRM_SIS)   += sis/
>> > -obj-$(CONFIG_DRM_SAVAGE)+= savage/
>> > -obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
>> > -obj-$(CONFIG_DRM_VIA)  +=via/
>> > -obj-$(CONFIG_DRM_VGEM) += vgem/
>> > -obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
>> > -obj-$(CONFIG_DRM_EXYNOS) +=exynos/
>> > -obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
>> > -obj-$(CONFIG_DRM_GMA500) += gma500/
>> > -obj-$(CONFIG_DRM_UDL) += udl/
>> > -obj-$(CONFIG_DRM_AST) += ast/
>> > -obj-$(CONFIG_DRM_ARMADA) += armada/
>> > +# device drivers. Please keep this list sorted alphabetically
>> > +obj-$(CONFIG_DRM_AMDGPU)       += amd/amdgpu/
>> > +obj-$(CONFIG_HSA_AMD)          += amd/amdkfd/
>> > +obj-$(CONFIG_DRM_ARMADA)       += armada/
>> > +obj-$(CONFIG_DRM_AST)          += ast/
>> >  obj-$(CONFIG_DRM_ATMEL_HLCDC)  += atmel-hlcdc/
>> > -obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
>> > -obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
>> > -obj-y                  += omapdrm/
>> > -obj-y                  += tilcdc/
>> > -obj-$(CONFIG_DRM_QXL) += qxl/
>> > -obj-$(CONFIG_DRM_BOCHS) += bochs/
>> > -obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio/
>> > -obj-$(CONFIG_DRM_MSM) += msm/
>> > -obj-$(CONFIG_DRM_TEGRA) += tegra/
>> > -obj-$(CONFIG_DRM_STI) += sti/
>> > -obj-$(CONFIG_DRM_IMX) += imx/
>> > -obj-y                  += i2c/
>> > -obj-y                  += panel/
>> > -obj-y                  += bridge/
>> > -obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
>> > -obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
>> > +obj-$(CONFIG_DRM_BOCHS)                += bochs/
>> > +obj-y                          += bridge/
>> > +obj-$(CONFIG_DRM_CIRRUS_QEMU)  += cirrus/
>> > +obj-$(CONFIG_DRM_ETNAVIV)      += etnaviv/
>> > +obj-$(CONFIG_DRM_EXYNOS)       += exynos/
>> > +obj-$(CONFIG_DRM_FSL_DCU)      += fsl-dcu/
>> > +obj-$(CONFIG_DRM_GMA500)       += gma500/
>> > +obj-y                          += i2c/
>> > +obj-$(CONFIG_DRM_I810)         += i810/
>> > +obj-$(CONFIG_DRM_I915)         += i915/
>> > +obj-$(CONFIG_DRM_IMX)          += imx/
>> > +obj-$(CONFIG_DRM_MGA)          += mga/
>> > +obj-$(CONFIG_DRM_MGAG200)      += mgag200/
>> > +obj-$(CONFIG_DRM_MSM)          += msm/
>> > +obj-$(CONFIG_DRM_NOUVEAU)      += nouveau/
>> > +obj-y                          += omapdrm/
>> > +obj-y                          += panel/
>> > +obj-$(CONFIG_DRM_QXL)          += qxl/
>> > +obj-$(CONFIG_DRM_R128)         += r128/
>> > +obj-$(CONFIG_DRM_RADEON)       += radeon/
>> > +obj-$(CONFIG_DRM_RCAR_DU)      += rcar-du/
>> > +obj-$(CONFIG_DRM_ROCKCHIP)     += rockchip/
>> > +obj-$(CONFIG_DRM_SAVAGE)       += savage/
>> > +obj-$(CONFIG_DRM_SHMOBILE)     += shmobile/
>> > +obj-$(CONFIG_DRM_SIS)          += sis/
>> > +obj-$(CONFIG_DRM_STI)          += sti/
>> > +obj-$(CONFIG_DRM_TDFX)         += tdfx/
>> > +obj-$(CONFIG_DRM_TEGRA)                += tegra/
>> > +obj-y                          += tilcdc/
>> > +obj-$(CONFIG_DRM_UDL)          += udl/
>> > +obj-$(CONFIG_DRM_VC4)          += vc4/
>> > +obj-$(CONFIG_DRM_VGEM)         += vgem/
>> > +obj-$(CONFIG_DRM_VIA)          += via/
>> > +obj-$(CONFIG_DRM_VIRTIO_GPU)   += virtio/
>> > +obj-$(CONFIG_DRM_VMWGFX)       += vmwgfx/
>> > --
>> > 1.9.1
>> >
>> > _______________________________________________
>> > dri-devel mailing list
>> > dri-devel at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> NACK, amdkfd *must* be before amdgpu *and* radeon, because it needs to
>> be already loaded when amdgpu/radeon get loaded, and when all these
>> drivers are compiled inside the kernel, the order is maintained by the
>> linkage order in the makefile.
>
> That's not how this is supposed to be done. If you have inter-driver
> depencies like this you need to check for them, and defer the driver
> loading by returngin -EPROBE_DEFER. The core kernel will then re-probe
> your driver once other drivers have loaded. Handling inter-driver deps
> using compile-ordering is seriously too fragile.
>
> Please fix this up, thanks.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Hi Daniel,

Thanks for the EPROBE_DEFER pointer - I'll try to take a look and see
if it could be fixed quickly for 4.6

Oded


From aryabinin at virtuozzo.com  Tue Feb  9 05:50:14 2016
From: aryabinin at virtuozzo.com (Andrey Ryabinin)
Date: Tue, 9 Feb 2016 16:50:14 +0300
Subject: [PATCH v2] arm64: disable kasan when accessing frame->fp in
 unwind_frame
In-Reply-To: <1454951589-18238-1-git-send-email-yang.shi@linaro.org>
References: <1454951589-18238-1-git-send-email-yang.shi@linaro.org>
Message-ID: <56B9EE96.9060804@virtuozzo.com>

On 02/08/2016 08:13 PM, Yang Shi wrote:
> When boot arm64 kernel with KASAN enabled, the below error is reported by
> kasan:
> 
> BUG: KASAN: out-of-bounds in unwind_frame+0xec/0x260 at addr ffffffc064d57ba0
> Read of size 8 by task pidof/499
> page:ffffffbdc39355c0 count:0 mapcount:0 mapping:          (null) index:0x0
> flags: 0x0()
> page dumped because: kasan: bad access detected
> CPU: 2 PID: 499 Comm: pidof Not tainted 4.5.0-rc1 #119
> Hardware name: Freescale Layerscape 2085a RDB Board (DT)
> Call trace:
> [<ffffffc00008d078>] dump_backtrace+0x0/0x290
> [<ffffffc00008d32c>] show_stack+0x24/0x30
> [<ffffffc0006a981c>] dump_stack+0x8c/0xd8
> [<ffffffc0002e4400>] kasan_report_error+0x558/0x588
> [<ffffffc0002e4958>] kasan_report+0x60/0x70
> [<ffffffc0002e3188>] __asan_load8+0x60/0x78
> [<ffffffc00008c92c>] unwind_frame+0xec/0x260
> [<ffffffc000087e60>] get_wchan+0x110/0x160
> [<ffffffc0003b647c>] do_task_stat+0xb44/0xb68
> [<ffffffc0003b7730>] proc_tgid_stat+0x40/0x50
> [<ffffffc0003ac840>] proc_single_show+0x88/0xd8
> [<ffffffc000345be8>] seq_read+0x370/0x770
> [<ffffffc00030aba0>] __vfs_read+0xc8/0x1d8
> [<ffffffc00030c0ec>] vfs_read+0x94/0x168
> [<ffffffc00030d458>] SyS_read+0xb8/0x128
> [<ffffffc000086530>] el0_svc_naked+0x24/0x28
> Memory state around the buggy address:
>  ffffffc064d57a80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4
>  ffffffc064d57b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> ffffffc064d57b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>                                   ^
>  ffffffc064d57c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  ffffffc064d57c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> Since the shadow byte pointed by the report is 0, so it may mean it is just hit
> oob in non-current task. So, disable the instrumentation to silence these
> warnings.
> 
> Signed-off-by: Yang Shi <yang.shi at linaro.org>

Acked-by: Andrey Ryabinin <aryabinin at virtuozzo.com>



From rrichter at caviumnetworks.com  Tue Feb  9 05:53:40 2016
From: rrichter at caviumnetworks.com (Robert Richter)
Date: Tue, 9 Feb 2016 14:53:40 +0100
Subject: [PATCH v4 0/6] arm64 UEFI early FDT handling
Message-ID: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>

From: Robert Richter <rrichter at cavium.com>

Reposting an updated version of this patches ported to 4.5-rc1. It is
a followup to the version 3 from:

 http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel at linaro.org

The series is essential for NUMA on arm64. Early FDT handling is
required to make system topology data from firmware, esp. for cpus and
memory available to the early boot process. Ganapat's numa patches
depend on it. This series has been tested with his series v10 posted
here:

 http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni at caviumnetworks.com

A number of minor issues exist in the early UEFI/FDT handling path, such as:
- when booting via UEFI, memreserve entries are removed from the device tree but
  the /reserved-memory node is not
- memory nodes are removed from the device tree in a way that is not officially
  supported by the libfdt API (i.e., you cannot delete nodes while traversing
  the tree)
- removal of memory nodes may discard annotations (such as NUMA topology) that
  should ideally be retained, or may corrupt the tree by discarding nodes
  referenced by phandles.

Patches #1 and #2 introduce an arm64 specific version of
early_init_dt_add_memory_arch() so that we can modify it later to ignore DT
memory nodes if booting via UEFI.

Patch #3 moves some UEFI+FDT init code around before making changes to it.

Patch #4 moves the UEFI initialization to before the early FDT scanning so we
know at that point whether we are booting via UEFI or not.

Patch #5 changes the UEFI init code so that memory nodes are simply ignored, so
that they don't have to be removed by the stub anymore.

Patch #6 does the same as #5, but for memreserves and the /reserved-memory
node.

Changes since v3:
- prorted to v4.5-rc1

Changes since v2:
- instead of copying the generic implementation, turn
  early_init_dt_add_memory_arch() into a weak alias so that it is still
  accessible to overrides

Changes since v1:
- dropped first two patches, they have been merged into v4.2-rc1
- dropped last patch regarding FDT placement by the stub, this is not entirely
  relevant to the primary issue targeted by this series
- rebased onto for-next/core (arm64) as of today

Ard Biesheuvel (6):
  of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
  arm64: override generic version of early_init_dt_add_memory_arch()
  efi: move FDT handling to separate object file
  arm64/efi: move EFI /chosen node parsing before early FDT processing
  arm64/efi: ignore DT memory nodes instead of removing them
  arm64/efi: ignore DT memreserve entries instead of removing them

 arch/arm64/include/asm/efi.h       |  2 +
 arch/arm64/kernel/setup.c          |  3 ++
 arch/arm64/mm/init.c               | 12 +++++-
 drivers/firmware/efi/Makefile      |  1 +
 drivers/firmware/efi/arm-init.c    | 36 ++++++++++------
 drivers/firmware/efi/efi-fdt.c     | 73 +++++++++++++++++++++++++++++++++
 drivers/firmware/efi/efi.c         | 84 --------------------------------------
 drivers/firmware/efi/libstub/fdt.c | 33 +--------------
 drivers/of/fdt.c                   |  7 +++-
 include/linux/efi.h                |  2 +-
 include/linux/of_fdt.h             |  1 +
 11 files changed, 121 insertions(+), 133 deletions(-)
 create mode 100644 drivers/firmware/efi/efi-fdt.c

-- 
2.7.0.rc3


From rrichter at caviumnetworks.com  Tue Feb  9 05:53:41 2016
From: rrichter at caviumnetworks.com (Robert Richter)
Date: Tue, 9 Feb 2016 14:53:41 +0100
Subject: [PATCH v4 1/6] of/fdt: make generic early_init_dt_add_memory_arch() a
 weak alias
In-Reply-To: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
References: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
Message-ID: <1455026026-11571-2-git-send-email-rrichter@caviumnetworks.com>

From: Ard Biesheuvel <ard.biesheuvel at linaro.org>

The function early_init_dt_add_memory_arch() is defined as __weak
so that archs can override it. However, in this override implementation,
it may still be useful to invoke the generic implementation, so instead,
rename the generic version to early_init_dt_add_memory() and turn the
original definition into a weak alias. This way, the generic version can
still be called even in the presence of an arch specific override.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Message-Id: <1442881288-13962-2-git-send-email-ard.biesheuvel at linaro.org>
Signed-off-by: Robert Richter <rrichter at cavium.com>
---
 drivers/of/fdt.c       | 7 +++++--
 include/linux/of_fdt.h | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79db7899..cba8281ab5fd 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -980,7 +980,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
 #define MAX_MEMBLOCK_ADDR	((phys_addr_t)~0)
 #endif
 
-void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
+void __init early_init_dt_add_memory(u64 base, u64 size)
 {
 	const u64 phys_offset = __pa(PAGE_OFFSET);
 
@@ -1038,7 +1038,7 @@ void * __init __weak early_init_dt_alloc_memory_arch(u64 size, u64 align)
 	return __va(memblock_alloc(size, align));
 }
 #else
-void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
+void __init early_init_dt_add_memory(u64 base, u64 size)
 {
 	WARN_ON(1);
 }
@@ -1058,6 +1058,9 @@ void * __init __weak early_init_dt_alloc_memory_arch(u64 size, u64 align)
 }
 #endif
 
+__weak __alias(early_init_dt_add_memory)
+void early_init_dt_add_memory_arch(u64 base, u64 size);
+
 bool __init early_init_dt_verify(void *params)
 {
 	if (!params)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef3801812..463a06ba87ac 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -65,6 +65,7 @@ extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
 				     int depth, void *data);
 extern void early_init_fdt_scan_reserved_mem(void);
 extern void early_init_fdt_reserve_self(void);
+extern void early_init_dt_add_memory(u64 base, u64 size);
 extern void early_init_dt_add_memory_arch(u64 base, u64 size);
 extern int early_init_dt_reserve_memory_arch(phys_addr_t base, phys_addr_t size,
 					     bool no_map);
-- 
2.7.0.rc3



From rrichter at caviumnetworks.com  Tue Feb  9 05:53:42 2016
From: rrichter at caviumnetworks.com (Robert Richter)
Date: Tue, 9 Feb 2016 14:53:42 +0100
Subject: [PATCH v4 2/6] arm64: override generic version of
 early_init_dt_add_memory_arch()
In-Reply-To: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
References: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
Message-ID: <1455026026-11571-3-git-send-email-rrichter@caviumnetworks.com>

From: Ard Biesheuvel <ard.biesheuvel at linaro.org>

Override the __weak early_init_dt_add_memory_arch() with our own
version. We need this in a subsequent patch to make the handling of
the memory nodes conditional on whether we are booting via UEFI or
not. Note that for now, all that our version does is invoke the generic
implementation.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Message-Id: <1442881288-13962-3-git-send-email-ard.biesheuvel at linaro.org>
Signed-off-by: Robert Richter <rrichter at cavium.com>
---
 arch/arm64/mm/init.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3b061e67bfe..208c1d359018 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -380,3 +380,8 @@ static int __init keepinitrd_setup(char *__unused)
 
 __setup("keepinitrd", keepinitrd_setup);
 #endif
+
+void __init early_init_dt_add_memory_arch(u64 base, u64 size)
+{
+	early_init_dt_add_memory(base, size);
+}
-- 
2.7.0.rc3



From daniel at ffwll.ch  Tue Feb  9 05:54:55 2016
From: daniel at ffwll.ch (Daniel Vetter)
Date: Tue, 9 Feb 2016 14:54:55 +0100
Subject: [PATCH] drm/tegra: remove unused variable
In-Reply-To: <1455020923-1089878-1-git-send-email-arnd@arndb.de>
References: <1455020923-1089878-1-git-send-email-arnd@arndb.de>
Message-ID: <20160209135455.GW11240@phenom.ffwll.local>

On Tue, Feb 09, 2016 at 01:28:15PM +0100, Arnd Bergmann wrote:
> A newly merged patch removed the only user of this variable,
> leading to a harmless gcc warning:
> 
> drivers/gpu/drm/tegra/drm.c: In function 'tegra_drm_preclose':
> drivers/gpu/drm/tegra/drm.c:861:19: error: unused variable 'crtc' [-Werror=unused-variable]
> 
> This removes the variable as well.
> 
> Cc: Terje Bergstr?m <tbergstrom at nvidia.com>
> Cc: Daniel Stone <daniels at collabora.com>
> Cc: Alex Deucher <alexander.deucher at amd.com>
> Cc: Thierry Reding <treding at nvidia.com>
> Cc: Daniel Vetter <daniel.vetter at intel.com>
> Fixes: 0417d424ac0d ("drm/tegra: Stop cancelling page flip events")
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Already fixed by Dave in 10c1b6183a163aca59ba92b88f2b4c4cecd20d4c. Thanks
anyway for the quick patch.
-Daniel

> ---
>  drivers/gpu/drm/tegra/drm.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index 021d0e1398fb..8e6b18caa706 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -858,7 +858,6 @@ static void tegra_drm_preclose(struct drm_device *drm, struct drm_file *file)
>  {
>  	struct tegra_drm_file *fpriv = file->driver_priv;
>  	struct tegra_drm_context *context, *tmp;
> -	struct drm_crtc *crtc;
>  
>  	list_for_each_entry_safe(context, tmp, &fpriv->contexts, list)
>  		tegra_drm_context_free(context);
> -- 
> 2.7.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From rrichter at caviumnetworks.com  Tue Feb  9 05:53:43 2016
From: rrichter at caviumnetworks.com (Robert Richter)
Date: Tue, 9 Feb 2016 14:53:43 +0100
Subject: [PATCH v4 3/6] efi: move FDT handling to separate object file
In-Reply-To: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
References: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
Message-ID: <1455026026-11571-4-git-send-email-rrichter@caviumnetworks.com>

From: Ard Biesheuvel <ard.biesheuvel at linaro.org>

The EFI specific FDT handling is compiled conditionally, and is
logically independent of the rest of efi.o. So move it to a separate
file before making changes to it in subsequent patches.

Acked-by: Matt Fleming <matt.fleming at intel.com>
Acked-by: Leif Lindholm <leif.lindholm at linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Message-Id: <1442881288-13962-4-git-send-email-ard.biesheuvel at linaro.org>
[ rric: Ported to v4.5-rc1 ]
Signed-off-by: Robert Richter <rrichter at cavium.com>
---
 drivers/firmware/efi/Makefile  |  1 +
 drivers/firmware/efi/efi-fdt.c | 91 ++++++++++++++++++++++++++++++++++++++++++
 drivers/firmware/efi/efi.c     | 84 --------------------------------------
 3 files changed, 92 insertions(+), 84 deletions(-)
 create mode 100644 drivers/firmware/efi/efi-fdt.c

diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 62e654f255f4..bb7ec2fac25c 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_EFI_RUNTIME_MAP)		+= runtime-map.o
 obj-$(CONFIG_EFI_RUNTIME_WRAPPERS)	+= runtime-wrappers.o
 obj-$(CONFIG_EFI_STUB)			+= libstub/
 obj-$(CONFIG_EFI_FAKE_MEMMAP)		+= fake_mem.o
+obj-$(CONFIG_EFI_PARAMS_FROM_FDT)	+= efi-fdt.o
 
 arm-obj-$(CONFIG_EFI)			:= arm-init.o arm-runtime.o
 obj-$(CONFIG_ARM)			+= $(arm-obj-y)
diff --git a/drivers/firmware/efi/efi-fdt.c b/drivers/firmware/efi/efi-fdt.c
new file mode 100644
index 000000000000..8f3ce66e2b02
--- /dev/null
+++ b/drivers/firmware/efi/efi-fdt.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright (C) 2013 - 2015 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/efi.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+
+#define UEFI_PARAM(name, prop, field)			   \
+	{						   \
+		{ name },				   \
+		{ prop },				   \
+		offsetof(struct efi_fdt_params, field),    \
+		FIELD_SIZEOF(struct efi_fdt_params, field) \
+	}
+
+static __initdata struct {
+	const char name[32];
+	const char propname[32];
+	int offset;
+	int size;
+} dt_params[] = {
+	UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
+	UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
+	UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
+	UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
+	UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
+};
+
+struct param_info {
+	int found;
+	void *params;
+};
+
+static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
+				       int depth, void *data)
+{
+	struct param_info *info = data;
+	const void *prop;
+	void *dest;
+	u64 val;
+	int i, len;
+
+	if (depth != 1 || strcmp(uname, "chosen") != 0)
+		return 0;
+
+	for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+		prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
+		if (!prop)
+			return 0;
+		dest = info->params + dt_params[i].offset;
+		info->found++;
+
+		val = of_read_number(prop, len / sizeof(u32));
+
+		if (dt_params[i].size == sizeof(u32))
+			*(u32 *)dest = val;
+		else
+			*(u64 *)dest = val;
+
+		if (efi_enabled(EFI_DBG))
+			pr_info("  %s: 0x%0*llx\n", dt_params[i].name,
+				dt_params[i].size * 2, val);
+	}
+	return 1;
+}
+
+int __init efi_get_fdt_params(struct efi_fdt_params *params)
+{
+	struct param_info info;
+	int ret;
+
+	pr_info("Getting EFI parameters from FDT:\n");
+
+	info.found = 0;
+	info.params = params;
+
+	ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
+	if (!info.found)
+		pr_info("UEFI not found.\n");
+	else if (!ret)
+		pr_err("Can't find '%s' in device tree!\n",
+		       dt_params[info.found].name);
+
+	return ret;
+}
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37dad67a6..7c41c4284814 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -20,8 +20,6 @@
 #include <linux/init.h>
 #include <linux/device.h>
 #include <linux/efi.h>
-#include <linux/of.h>
-#include <linux/of_fdt.h>
 #include <linux/io.h>
 #include <linux/platform_device.h>
 
@@ -490,88 +488,6 @@ static int __init efi_load_efivars(void)
 device_initcall(efi_load_efivars);
 #endif
 
-#ifdef CONFIG_EFI_PARAMS_FROM_FDT
-
-#define UEFI_PARAM(name, prop, field)			   \
-	{						   \
-		{ name },				   \
-		{ prop },				   \
-		offsetof(struct efi_fdt_params, field),    \
-		FIELD_SIZEOF(struct efi_fdt_params, field) \
-	}
-
-static __initdata struct {
-	const char name[32];
-	const char propname[32];
-	int offset;
-	int size;
-} dt_params[] = {
-	UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
-	UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
-	UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
-	UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
-	UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
-};
-
-struct param_info {
-	int found;
-	void *params;
-};
-
-static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
-				       int depth, void *data)
-{
-	struct param_info *info = data;
-	const void *prop;
-	void *dest;
-	u64 val;
-	int i, len;
-
-	if (depth != 1 || strcmp(uname, "chosen") != 0)
-		return 0;
-
-	for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
-		prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
-		if (!prop)
-			return 0;
-		dest = info->params + dt_params[i].offset;
-		info->found++;
-
-		val = of_read_number(prop, len / sizeof(u32));
-
-		if (dt_params[i].size == sizeof(u32))
-			*(u32 *)dest = val;
-		else
-			*(u64 *)dest = val;
-
-		if (efi_enabled(EFI_DBG))
-			pr_info("  %s: 0x%0*llx\n", dt_params[i].name,
-				dt_params[i].size * 2, val);
-	}
-	return 1;
-}
-
-int __init efi_get_fdt_params(struct efi_fdt_params *params)
-{
-	struct param_info info;
-	int ret;
-
-	pr_info("Getting EFI parameters from FDT:\n");
-
-	info.found = 0;
-	info.params = params;
-
-	ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
-	if (!info.found)
-		pr_info("UEFI not found.\n");
-	else if (!ret)
-		pr_err("Can't find '%s' in device tree!\n",
-		       dt_params[info.found].name);
-
-	return ret;
-}
-#endif /* CONFIG_EFI_PARAMS_FROM_FDT */
-
 static __initdata char memory_type_name[][20] = {
 	"Reserved",
 	"Loader Code",
-- 
2.7.0.rc3



From rrichter at caviumnetworks.com  Tue Feb  9 05:53:44 2016
From: rrichter at caviumnetworks.com (Robert Richter)
Date: Tue, 9 Feb 2016 14:53:44 +0100
Subject: [PATCH v4 4/6] arm64/efi: move EFI /chosen node parsing before early
 FDT processing
In-Reply-To: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
References: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
Message-ID: <1455026026-11571-5-git-send-email-rrichter@caviumnetworks.com>

From: Ard Biesheuvel <ard.biesheuvel at linaro.org>

The early FDT processing is responsible for enumerating the
DT memory nodes and installing them as memblocks. This should
only be done if we are not booting via EFI, but at this point,
we don't know yet if that is the case or not.

So move part of the EFI init to before the early FDT processing. This
involves making some changes to the way EFI discovers the locations of
the EFI system table and the memory map, since those values are retrieved
from the FDT as well. Instead the of_scan infrastructure, it now uses
libfdt directly to access the /chosen node.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Message-Id: <1442881288-13962-5-git-send-email-ard.biesheuvel at linaro.org>
[ rric: Ported to v4.5-rc1 ]
Signed-off-by: Robert Richter <rrichter at cavium.com>
---
 arch/arm64/include/asm/efi.h    |  2 ++
 arch/arm64/kernel/setup.c       |  3 ++
 drivers/firmware/efi/arm-init.c | 34 ++++++++++++-------
 drivers/firmware/efi/efi-fdt.c  | 72 ++++++++++++++++-------------------------
 include/linux/efi.h             |  2 +-
 5 files changed, 55 insertions(+), 58 deletions(-)

diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index 8e88a696c9cb..acc7f65cef47 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -8,8 +8,10 @@
 
 #ifdef CONFIG_EFI
 extern void efi_init(void);
+extern void efi_parse_fdt(void *fdt);
 #else
 #define efi_init()
+#define efi_parse_fdt(x)
 #endif
 
 int efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md);
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479147db..3f5723329173 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -181,6 +181,9 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
 {
 	void *dt_virt = fixmap_remap_fdt(dt_phys);
 
+	if (dt_virt)
+		efi_parse_fdt(dt_virt);
+
 	if (!dt_virt || !early_init_dt_scan(dt_virt)) {
 		pr_crit("\n"
 			"Error: invalid device tree blob at physical address %pa (virtual address 0x%p)\n"
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9e15d571b53c..9fe04648d4d3 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -170,22 +170,35 @@ static __init void reserve_regions(void)
 		if (efi_enabled(EFI_DBG))
 			pr_cont("\n");
 	}
-
-	set_bit(EFI_MEMMAP, &efi.flags);
 }
 
-void __init efi_init(void)
+void __init efi_parse_fdt(void *fdt)
 {
 	struct efi_fdt_params params;
 
 	/* Grab UEFI information placed in FDT by stub */
-	if (!efi_get_fdt_params(&params))
+	if (!efi_get_fdt_params(fdt, &params))
 		return;
 
 	efi_system_table = params.system_table;
 
 	memmap.phys_map = params.mmap;
-	memmap.map = early_memremap(params.mmap, params.mmap_size);
+	memmap.desc_size = params.desc_size;
+	memmap.desc_version = params.desc_ver;
+	memmap.nr_map = params.mmap_size / params.desc_size;
+
+	set_bit(EFI_MEMMAP, &efi.flags);
+}
+
+void __init efi_init(void)
+{
+	int mmap_size = memmap.nr_map * memmap.desc_size;
+	u64 phys_map  = memmap.phys_map;
+
+	if (!efi_enabled(EFI_MEMMAP))
+		return;
+
+	memmap.map = early_memremap(phys_map, mmap_size);
 	if (memmap.map == NULL) {
 		/*
 		* If we are booting via UEFI, the UEFI memory map is the only
@@ -194,16 +207,13 @@ void __init efi_init(void)
 		*/
 		panic("Unable to map EFI memory map.\n");
 	}
-	memmap.map_end = memmap.map + params.mmap_size;
-	memmap.desc_size = params.desc_size;
-	memmap.desc_version = params.desc_ver;
+	memmap.map_end = memmap.map + mmap_size;
 
 	if (uefi_init() < 0)
 		return;
 
 	reserve_regions();
-	early_memunmap(memmap.map, params.mmap_size);
-	memblock_mark_nomap(params.mmap & PAGE_MASK,
-			    PAGE_ALIGN(params.mmap_size +
-				       (params.mmap & ~PAGE_MASK)));
+	early_memunmap(memmap.map, mmap_size);
+	memblock_mark_nomap(phys_map & PAGE_MASK,
+			    PAGE_ALIGN(mmap_size + (phys_map & ~PAGE_MASK)));
 }
diff --git a/drivers/firmware/efi/efi-fdt.c b/drivers/firmware/efi/efi-fdt.c
index 8f3ce66e2b02..e6622d3182ae 100644
--- a/drivers/firmware/efi/efi-fdt.c
+++ b/drivers/firmware/efi/efi-fdt.c
@@ -8,8 +8,7 @@
 
 #include <linux/init.h>
 #include <linux/efi.h>
-#include <linux/of.h>
-#include <linux/of_fdt.h>
+#include <linux/libfdt.h>
 
 #define UEFI_PARAM(name, prop, field)			   \
 	{						   \
@@ -32,60 +31,43 @@ static __initdata struct {
 	UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
 };
 
-struct param_info {
-	int found;
-	void *params;
-};
-
-static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
-				       int depth, void *data)
+int __init efi_get_fdt_params(void *fdt, struct efi_fdt_params *params)
 {
-	struct param_info *info = data;
 	const void *prop;
-	void *dest;
-	u64 val;
-	int i, len;
+	int node, i;
+
+	pr_info("Getting EFI parameters from FDT:\n");
 
-	if (depth != 1 || strcmp(uname, "chosen") != 0)
-		return 0;
+	node = fdt_path_offset(fdt, "/chosen");
+	if (node < 0) {
+		pr_err("/chosen node not found!\n");
+		return false;
+	}
 
 	for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
-		prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
-		if (!prop)
-			return 0;
-		dest = info->params + dt_params[i].offset;
-		info->found++;
+		void *dest;
+		int len;
+		u64 val;
 
-		val = of_read_number(prop, len / sizeof(u32));
+		prop = fdt_getprop(fdt, node, dt_params[i].propname, &len);
+		if (!prop || len != dt_params[i].size)
+			goto not_found;
+		dest = (void *)params + dt_params[i].offset;
 
 		if (dt_params[i].size == sizeof(u32))
-			*(u32 *)dest = val;
+			val = *(u32 *)dest = be32_to_cpup(prop);
 		else
-			*(u64 *)dest = val;
+			val = *(u64 *)dest = be64_to_cpup(prop);
 
-		if (efi_enabled(EFI_DBG))
-			pr_info("  %s: 0x%0*llx\n", dt_params[i].name,
-				dt_params[i].size * 2, val);
+		pr_info("  %s: 0x%0*llx\n", dt_params[i].name,
+			dt_params[i].size * 2, val);
 	}
-	return 1;
-}
+	return true;
 
-int __init efi_get_fdt_params(struct efi_fdt_params *params)
-{
-	struct param_info info;
-	int ret;
-
-	pr_info("Getting EFI parameters from FDT:\n");
-
-	info.found = 0;
-	info.params = params;
-
-	ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
-	if (!info.found)
+not_found:
+	if (i == 0)
 		pr_info("UEFI not found.\n");
-	else if (!ret)
-		pr_err("Can't find '%s' in device tree!\n",
-		       dt_params[info.found].name);
-
-	return ret;
+	else
+		pr_err("Can't find '%s' in device tree!\n", dt_params[i].name);
+	return false;
 }
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 569b5a866bb1..ede2c21c651b 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -915,7 +915,7 @@ extern void efi_initialize_iomem_resources(struct resource *code_resource,
 		struct resource *data_resource, struct resource *bss_resource);
 extern void efi_get_time(struct timespec *now);
 extern void efi_reserve_boot_services(void);
-extern int efi_get_fdt_params(struct efi_fdt_params *params);
+extern int efi_get_fdt_params(void *fdt, struct efi_fdt_params *params);
 extern struct efi_memory_map memmap;
 extern struct kobject *efi_kobj;
 
-- 
2.7.0.rc3



From rrichter at caviumnetworks.com  Tue Feb  9 05:53:45 2016
From: rrichter at caviumnetworks.com (Robert Richter)
Date: Tue, 9 Feb 2016 14:53:45 +0100
Subject: [PATCH v4 5/6] arm64/efi: ignore DT memory nodes instead of removing
 them
In-Reply-To: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
References: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
Message-ID: <1455026026-11571-6-git-send-email-rrichter@caviumnetworks.com>

From: Ard Biesheuvel <ard.biesheuvel at linaro.org>

There are two problems with the UEFI stub DT memory node removal
routine:
- it deletes nodes as it traverses the tree, which happens to work
  but is not supported, as deletion invalidates the node iterator;
- deleting memory nodes entirely may discard annotations in the form
  of additional properties on the nodes.

Now that the UEFI initialization has moved to an earlier stage, we can
actually just ignore any memblocks that are installed after we have
processed the UEFI memory map. This way, it is no longer necessary to
remove the nodes, so we can remove that logic from the stub as well.

Acked-by: Leif Lindholm <leif.lindholm at linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Message-Id: <1442881288-13962-6-git-send-email-ard.biesheuvel at linaro.org>
[ rric: Ported to v4.5-rc1 ]
Signed-off-by: Robert Richter <rrichter at cavium.com>
---
 arch/arm64/mm/init.c               |  6 +++++-
 drivers/firmware/efi/arm-init.c    |  2 +-
 drivers/firmware/efi/libstub/fdt.c | 24 +-----------------------
 3 files changed, 7 insertions(+), 25 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 208c1d359018..eda226e85c71 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -383,5 +383,9 @@ __setup("keepinitrd", keepinitrd_setup);
 
 void __init early_init_dt_add_memory_arch(u64 base, u64 size)
 {
-	early_init_dt_add_memory(base, size);
+	/*
+	 * Ignore DT memory nodes if we are booting via UEFI.
+	 */
+	if (!efi_enabled(EFI_MEMMAP))
+		early_init_dt_add_memory(base, size);
 }
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9fe04648d4d3..ded895706633 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -159,7 +159,7 @@ static __init void reserve_regions(void)
 		size = npages << PAGE_SHIFT;
 
 		if (is_normal_ram(md))
-			early_init_dt_add_memory_arch(paddr, size);
+			early_init_dt_add_memory(paddr, size);
 
 		if (is_reserve_region(md)) {
 			memblock_mark_nomap(paddr, size);
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index cf7b7d46302a..9df1560d57bc 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -24,7 +24,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
 			unsigned long map_size, unsigned long desc_size,
 			u32 desc_ver)
 {
-	int node, prev, num_rsv;
+	int node, num_rsv;
 	int status;
 	u32 fdt_val32;
 	u64 fdt_val64;
@@ -54,28 +54,6 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
 		goto fdt_set_fail;
 
 	/*
-	 * Delete any memory nodes present. We must delete nodes which
-	 * early_init_dt_scan_memory may try to use.
-	 */
-	prev = 0;
-	for (;;) {
-		const char *type;
-		int len;
-
-		node = fdt_next_node(fdt, prev, NULL);
-		if (node < 0)
-			break;
-
-		type = fdt_getprop(fdt, node, "device_type", &len);
-		if (type && strncmp(type, "memory", len) == 0) {
-			fdt_del_node(fdt, node);
-			continue;
-		}
-
-		prev = node;
-	}
-
-	/*
 	 * Delete all memory reserve map entries. When booting via UEFI,
 	 * kernel will use the UEFI memory map to find reserved regions.
 	 */
-- 
2.7.0.rc3



From tsahee at annapurnalabs.com  Tue Feb  9 05:54:31 2016
From: tsahee at annapurnalabs.com (Tsahee Zidenberg)
Date: Tue, 9 Feb 2016 15:54:31 +0200
Subject: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <56B9D20A.8010709@arm.com>
References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com>
 <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com>
 <56B8B45D.1020902@arm.com> <20160209085633.GA5388@kwain>
 <20160209090131.GB5388@kwain> <56B9ACE2.1060200@arm.com>
 <CABM=7knaepbyy4nw_GczVM7E_t6py7gG0ERs8ru_AYoVXvAQ+A@mail.gmail.com>
 <56B9B1B5.5070106@arm.com>
 <CABM=7k=-Y+eFB2nUMfMjd3saTSNDsEyfHyYNf-ef8qQc5jCsxA@mail.gmail.com>
 <56B9D20A.8010709@arm.com>
Message-ID: <CABM=7k=5WJj_rF1fWO+rnKiF_bcr=i8Bg8E4sKGOR=ER4zjgWw@mail.gmail.com>

On 9 February 2016 at 13:48, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 09/02/16 10:13, Tsahee Zidenberg wrote:
>> On 9 February 2016 at 11:30, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>
>>> On 09/02/16 09:14, Tsahee Zidenberg wrote:
>>>>
>>>>
>>>> On 9 February 2016 at 11:09, Marc Zyngier <marc.zyngier at arm.com
>>>> <mailto:marc.zyngier at arm.com>> wrote:
>>>>
>>>>     On 09/02/16 09:01, Antoine Tenart wrote:
>>>>     > On Tue, Feb 09, 2016 at 09:56:33AM +0100, Antoine Tenart wrote:
>>>>     >> Hi Marc,
>>>>     >>
>>>>     >> On Mon, Feb 08, 2016 at 03:29:33PM +0000, Marc Zyngier wrote:
>>>>     >>> On 08/02/16 09:11, Antoine Tenart wrote:
>>>>     >>>
>>>>     >>>> +          gic: gic at f0100000 {
>>>>     >>>> +                  compatible = "arm,gic-v3";
>>>>     >>>> +                  reg = <0x0 0xf0200000 0x0 0x10000>,     /* GIC Dist */
>>>>     >>>> +                        <0x0 0xf0280000 0x0 0x200000>,    /* GICR */
>>>>     >>>> +                        <0x0 0xf0100000 0x0 0x2000>;      /* GICC */
>>>>     >>>> +                  interrupt-controller;
>>>>     >>>> +                  #interrupt-cells = <3>;
>>>>     >>>> +          };
>>>>     >>>
>>>>     >>> Something is wrong here. Either you are missing GICH and GICV (assuming
>>>>     >>> you have legacy support), or you have an extra GICC region (which
>>>>     >>> doesn't make sense on its own).
>>>>     >>
>>>>     >> I'll add the missing regions.
>>>>     >
>>>>     > Hmm, in fact the GICC region shouldn't be there. I'll make some tests
>>>>     > and remove it.
>>>>
>>>>     If you have a GICv3 with legacy support, you will probably have GICC,
>>>>     GICH and GICV. Linux itself will only use GICD and GICR, but it needs at
>>>>     least GICV to be able to virtualize GICv2 guests. And GICV is not
>>>>     allowed to exist without GICC and GICH, so I really recommend that you
>>>>     keep GICC around.
>>>>
>>>>
>>>> We use the GIC without legacy support (we disable it in early boot
>>>> stages), so I think removing the GICC region is the better solution.
>>>
>>> Disabling legacy support doesn't mean that:
>>> - the HW isn't present
>>> - the associated regions are not useful
>>>
>> By "disabling lecgacy support in early boot" I don't just mean that
>> ARE bit will be set, but it will actually be RAO/WI. There will be no
>> way for SW to enable it and use these registers (which, sadly, means
>> that there will be no way to enable gicv2 virtualization). If you
>> insist - I will dig up the supposed location of GICV and GICH - yet it
>> will be both untested and entirely unusable.
>
> Just to make sure you are not missing the point: ARE==1 does *not* mean
> that GICV is unusable. Quite the opposite. It only makes it illegal to
> use GICC and GICH, but leaves GICV usable for a guest.
>
> So the real question is: do you have any additional HW that would
> actively prevent GICV from being used? If the answer to that is "no",
> and assuming your GICv3 implementation is compliant with the
> architecture, then GICV will be usable, and you should document all 3
> regions.
>

O.K. will add to next version.

> Thanks,
>
>         M.
> --
> Jazz is not dead. It just smells funny...


From rrichter at caviumnetworks.com  Tue Feb  9 05:53:46 2016
From: rrichter at caviumnetworks.com (Robert Richter)
Date: Tue, 9 Feb 2016 14:53:46 +0100
Subject: [PATCH v4 6/6] arm64/efi: ignore DT memreserve entries instead of
 removing them
In-Reply-To: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
References: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
Message-ID: <1455026026-11571-7-git-send-email-rrichter@caviumnetworks.com>

From: Ard Biesheuvel <ard.biesheuvel at linaro.org>

Now that the reservation of the FDT image itself is split off from
the processing of memory reservations described by the device tree,
we can make the DT scanning of memreserves conditional on whether
we booted via UEFI and have its memory map available. This allows
us to drop deletion of these memreserves in the stub. It also fixes
the issue where the /reserved-memory node (which offers another
way of reserving memory ranges) was not being ignored under UEFI.

Note that this reverts 0ceac9e094b0 ("efi/arm64: Fix fdt-related
memory reservation").

Acked-by: Leif Lindholm <leif.lindholm at linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Message-Id: <1442881288-13962-7-git-send-email-ard.biesheuvel at linaro.org>
Signed-off-by: Robert Richter <rrichter at cavium.com>
---
 arch/arm64/mm/init.c               |  3 ++-
 drivers/firmware/efi/libstub/fdt.c | 11 +----------
 2 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index eda226e85c71..ee061658866f 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -171,7 +171,8 @@ void __init arm64_memblock_init(void)
 		memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
 #endif
 
-	early_init_fdt_scan_reserved_mem();
+	if (!efi_enabled(EFI_MEMMAP))
+		early_init_fdt_scan_reserved_mem();
 
 	/* 4GB maximum for 32-bit only capable devices */
 	if (IS_ENABLED(CONFIG_ZONE_DMA))
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index 9df1560d57bc..12cb2a30a63f 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -24,8 +24,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
 			unsigned long map_size, unsigned long desc_size,
 			u32 desc_ver)
 {
-	int node, num_rsv;
-	int status;
+	int node, status;
 	u32 fdt_val32;
 	u64 fdt_val64;
 
@@ -53,14 +52,6 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
 	if (status != 0)
 		goto fdt_set_fail;
 
-	/*
-	 * Delete all memory reserve map entries. When booting via UEFI,
-	 * kernel will use the UEFI memory map to find reserved regions.
-	 */
-	num_rsv = fdt_num_mem_rsv(fdt);
-	while (num_rsv-- > 0)
-		fdt_del_mem_rsv(fdt, num_rsv);
-
 	node = fdt_subnode_offset(fdt, 0, "chosen");
 	if (node < 0) {
 		node = fdt_add_subnode(fdt, 0, "chosen");
-- 
2.7.0.rc3



From will.deacon at arm.com  Tue Feb  9 06:06:31 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Feb 2016 14:06:31 +0000
Subject: [PATCH 2/4] iommu/arm-smmu: Allow disabling unmatched stream
 bypass
In-Reply-To: <10ebf5a136a787da54ffd1d6167953f82f01a834.1453830752.git.robin.murphy@arm.com>
References: <cover.1453830752.git.robin.murphy@arm.com>
 <10ebf5a136a787da54ffd1d6167953f82f01a834.1453830752.git.robin.murphy@arm.com>
Message-ID: <20160209140631.GM22874@arm.com>

Hi Robin,

On Tue, Jan 26, 2016 at 06:06:35PM +0000, Robin Murphy wrote:
> Borrow the disable_bypass parameter from the SMMUv3 driver as a handy
> debugging/security feature so that unmatched stream IDs (i.e. devices
> not attached to an IOMMU domain) may be configured to fault.
> 
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
>  drivers/iommu/arm-smmu.c | 32 +++++++++++++++++++++++---------
>  1 file changed, 23 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 1f9093d..d1b7dc1 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -141,6 +141,8 @@
>  #define ID2_PTFS_16K			(1 << 13)
>  #define ID2_PTFS_64K			(1 << 14)
>  
> +#define sGFSR_USF			(1 << 1)
> +
>  /* Global TLB invalidation */
>  #define ARM_SMMU_GR0_TLBIVMID		0x64
>  #define ARM_SMMU_GR0_TLBIALLNSNH	0x68
> @@ -263,6 +265,10 @@ static int force_stage;
>  module_param_named(force_stage, force_stage, int, S_IRUGO);
>  MODULE_PARM_DESC(force_stage,
>  	"Force SMMU mappings to be installed at a particular stage of translation. A value of '1' or '2' forces the corresponding stage. All other values are ignored (i.e. no stage is forced). Note that selecting a specific stage will disable support for nested translation.");
> +static bool disable_bypass;
> +module_param_named(disable_bypass, disable_bypass, bool, S_IRUGO);
> +MODULE_PARM_DESC(disable_bypass,
> +	"Disable bypass streams such that incoming transactions from devices that are not attached to an iommu domain will report an abort back to the device and will not be allowed to pass through the SMMU.");
>  
>  enum arm_smmu_arch_version {
>  	ARM_SMMU_V1 = 1,
> @@ -704,8 +710,12 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
>  	if (!gfsr)
>  		return IRQ_NONE;
>  
> -	dev_err_ratelimited(smmu->dev,
> -		"Unexpected global fault, this could be serious\n");
> +	if (gfsr & sGFSR_USF)
> +		dev_err_ratelimited(smmu->dev, "Unmatched stream fault: ID 0x%x\n",
> +				    gfsynr1 & SMR_ID_MASK);
> +	else

I think I'd rather drop this message -- a global error is still indicative
that something has gone horriby wrong, and we already print the gsynr
registers below. Furthermore, if we take multiple faults, it might look
like they're all exclusively due to unmatched streams.

On top of that, I'm not convinced that USF will be set for an SMMU that
doesn't implement stream-matching (because it will match an S2CR of type
FAULT).

Other than that, looks good.

Will


From will.deacon at arm.com  Tue Feb  9 06:08:17 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Feb 2016 14:08:17 +0000
Subject: [PATCH 1/4] iommu/arm-smmu: Treat all device transactions as
 unprivileged
In-Reply-To: <6c5730256333b8d941f2c0371c1ab709a454938c.1453830752.git.robin.murphy@arm.com>
References: <cover.1453830752.git.robin.murphy@arm.com>
 <6c5730256333b8d941f2c0371c1ab709a454938c.1453830752.git.robin.murphy@arm.com>
Message-ID: <20160209140817.GN22874@arm.com>

On Tue, Jan 26, 2016 at 06:06:34PM +0000, Robin Murphy wrote:
> The IOMMU API has no concept of privilege so assumes all devices and
> mappings are equal, and indeed most non-CPU master devices on an AMBA
> interconnect make little use of the attribute bits on the bus thus by
> default perform unprivileged data accesses.
> 
> Some devices, however, believe themselves more equal than others, such
> as programmable DMA controllers whose 'master' thread issues bus
> transactions marked as privileged instruction fetches, while the data
> accesses of its channel threads (under the control of Linux, at least)
> are marked as unprivileged. This poses a problem for implementing the
> DMA API on an IOMMU conforming to ARM VMSAv8, under which a page that is
> unprivileged-writeable is also implicitly privileged-execute-never.
> Given that, there is no one set of attributes with which iommu_map() can
> implement, say, dma_alloc_coherent() that will allow every possible type
> of access without something running into unexecepted permission faults.
> 
> Fortunately the SMMU architecture provides a means to mitigate such
> issues by overriding the incoming attributes of a transaction; make use
> of that to strip the privileged/unprivileged status off incoming
> transactions, leaving just the instruction/data dichotomy which the
> IOMMU API does at least understand; Four states good, two states better.
> 
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
>  drivers/iommu/arm-smmu.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 59ee4b8..1f9093d 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -167,6 +167,9 @@
>  #define S2CR_TYPE_BYPASS		(1 << S2CR_TYPE_SHIFT)
>  #define S2CR_TYPE_FAULT			(2 << S2CR_TYPE_SHIFT)
>  
> +#define S2CR_PRIVCFG_SHIFT		24
> +#define S2CR_PRIVCFG_UNPRIV		(2 << S2CR_PRIVCFG_SHIFT)
> +
>  /* Context bank attribute registers */
>  #define ARM_SMMU_GR1_CBAR(n)		(0x0 + ((n) << 2))
>  #define CBAR_VMID_SHIFT			0
> @@ -1083,7 +1086,7 @@ static int arm_smmu_domain_add_master(struct arm_smmu_domain *smmu_domain,
>  		u32 idx, s2cr;
>  
>  		idx = cfg->smrs ? cfg->smrs[i].idx : cfg->streamids[i];
> -		s2cr = S2CR_TYPE_TRANS |
> +		s2cr = S2CR_TYPE_TRANS | S2CR_PRIVCFG_UNPRIV |
>  		       (smmu_domain->cfg.cbndx << S2CR_CBNDX_SHIFT);
>  		writel_relaxed(s2cr, gr0_base + ARM_SMMU_GR0_S2CR(idx));

Hmm, do we also need to worry about the bypass case? I guess not for the
moment, but I anticipate horrible things.

Will


From will.deacon at arm.com  Tue Feb  9 06:15:09 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Feb 2016 14:15:09 +0000
Subject: [PATCH 4/4] iommu/arm-smmu: Use per-context TLB sync as
 appropriate
In-Reply-To: <fc2ede950aea2e84a0b7cf93e4cd605f0cbdf3c3.1453830752.git.robin.murphy@arm.com>
References: <cover.1453830752.git.robin.murphy@arm.com>
 <fc2ede950aea2e84a0b7cf93e4cd605f0cbdf3c3.1453830752.git.robin.murphy@arm.com>
Message-ID: <20160209141508.GO22874@arm.com>

On Tue, Jan 26, 2016 at 06:06:37PM +0000, Robin Murphy wrote:
> TLB synchronisation is a mighty big hammmer to bring down on the
> transaction stream, typically stalling all in-flight transactions until
> the sync completes. Since in most cases (except at stage 2 on SMMUv1)
> a per-context sync operation is available, prefer that over the global
> operation when performing TLB maintenance for a single domain, to avoid
> unecessarily disrupting ongoing traffic in other contexts.
> 
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
>  drivers/iommu/arm-smmu.c | 32 ++++++++++++++++++++++++--------
>  1 file changed, 24 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 18e0e10..bf1895c 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -219,6 +219,8 @@
>  #define ARM_SMMU_CB_S1_TLBIVAL		0x620
>  #define ARM_SMMU_CB_S2_TLBIIPAS2	0x630
>  #define ARM_SMMU_CB_S2_TLBIIPAS2L	0x638
> +#define ARM_SMMU_CB_TLBSYNC		0x7f0
> +#define ARM_SMMU_CB_TLBSTATUS		0x7f4
>  #define ARM_SMMU_CB_ATS1PR		0x800
>  #define ARM_SMMU_CB_ATSR		0x8f0
>  
> @@ -546,14 +548,22 @@ static void __arm_smmu_free_bitmap(unsigned long *map, int idx)
>  }
>  
>  /* Wait for any pending TLB invalidations to complete */
> -static void __arm_smmu_tlb_sync(struct arm_smmu_device *smmu)
> +static void __arm_smmu_tlb_sync(struct arm_smmu_device *smmu, int cbndx)
>  {
>  	int count = 0;
> -	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
> +	void __iomem *base, __iomem *status;
>  
> -	writel_relaxed(0, gr0_base + ARM_SMMU_GR0_sTLBGSYNC);
> -	while (readl_relaxed(gr0_base + ARM_SMMU_GR0_sTLBGSTATUS)
> -	       & sTLBGSTATUS_GSACTIVE) {
> +	if (cbndx < 0) {
> +		base = ARM_SMMU_GR0(smmu);
> +		status = base + ARM_SMMU_GR0_sTLBGSTATUS;
> +		writel_relaxed(0, base + ARM_SMMU_GR0_sTLBGSYNC);
> +	} else {
> +		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cbndx);
> +		status = base + ARM_SMMU_CB_TLBSTATUS;
> +		writel_relaxed(0, base + ARM_SMMU_CB_TLBSYNC);
> +	}
> +
> +	while (readl_relaxed(status) & sTLBGSTATUS_GSACTIVE) {
>  		cpu_relax();
>  		if (++count == TLB_LOOP_TIMEOUT) {
>  			dev_err_ratelimited(smmu->dev,
> @@ -567,7 +577,13 @@ static void __arm_smmu_tlb_sync(struct arm_smmu_device *smmu)
>  static void arm_smmu_tlb_sync(void *cookie)
>  {
>  	struct arm_smmu_domain *smmu_domain = cookie;
> -	__arm_smmu_tlb_sync(smmu_domain->smmu);
> +	int cbndx = smmu_domain->cfg.cbndx;
> +
> +	if (smmu_domain->stage == ARM_SMMU_DOMAIN_S2 &&
> +	    smmu_domain->smmu->version < ARM_SMMU_V2)
> +		cbndx = -1;

I think it would be cleaner just to override the sync function pointer
when we initialise a stage-2 page table for an SMMUv1 implementation.

Any reason not to go that way?

Will


From will.deacon at arm.com  Tue Feb  9 06:16:11 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Feb 2016 14:16:11 +0000
Subject: [PATCH 0/4] Miscellaneous ARM SMMU patches
In-Reply-To: <cover.1453830752.git.robin.murphy@arm.com>
References: <cover.1453830752.git.robin.murphy@arm.com>
Message-ID: <20160209141610.GP22874@arm.com>

On Tue, Jan 26, 2016 at 06:06:33PM +0000, Robin Murphy wrote:
> Here's my current "miscellaneous SMMU enhancements" branch for your
> consideration. Patch #1 solves a subtle corner case that cropped up
> while exercising stage 1 context formats on the DMA330-MMU500 model;
> #3 will be wanted fairly soon for DMA ops integration so may as well
> get some exposure now; #2 and #4 are more nice-to-haves.

Cheers, Robin. I've queued #1 and #3 for 4.6. If you address the comments
on the other two, I can queue those as well.

Will


From lee.jones at linaro.org  Tue Feb  9 06:27:07 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Tue,  9 Feb 2016 14:27:07 +0000
Subject: [PATCH] mfd: Provide MACRO to declare commonly defined MFD cell
 attributes
Message-ID: <1455028027-1527-1-git-send-email-lee.jones@linaro.org>

Cc: Laxman Dewangan <ldewangan at nvidia.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 include/linux/mfd/core.h | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index 27dac3f..dacdc49 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -16,6 +16,38 @@
 
 #include <linux/platform_device.h>
 
+#define MFD_CELL_ALL(_name, _res, _pdata, _id, _compat, _match)		\
+	{								\
+		.name = (_name),					\
+		.num_resources = ARRAY_SIZE((_res)),			\
+		.resources = (_res),					\
+		.platform_data = (_pdata),				\
+		.pdata_size = ARRAY_SIZE((_pdata)),			\
+		.of_compatible = (_compat),				\
+		.acpi_match = (_match),					\
+		.id = _id,						\
+	}
+
+#define OF_MFD_CELL(_name, _res, _pdata, _id, _compat)			\
+	{								\
+		MFD_CELL_ALL(_name, _res, _pdata, _id, _compat, NULL)	\
+	}
+
+#define ACPI_MFD_CELL(_name, _res, _pdata, _id, _match)			\
+	{								\
+		MFD_CELL_ALL(_name, _res, _pdata, _id, NULL, _match)	\
+	}
+
+#define MFD_CELL_BASIC(_name, _res, _pdata, _id)			\
+	{								\
+		MFD_CELL_ALL(_name, _res, _pdata, _id, NULL, NULL)	\
+	}
+
+#define MFD_CELL_NAME(_name)						\
+	{								\
+		MFD_CELL_ALL(_name, NULL, NULL, 0, NULL, NULL)		\
+	}
+
 struct irq_domain;
 
 /* Matches ACPI PNP id, either _HID or _CID, or ACPI _ADR */
-- 
1.9.1



From sudeep.holla at arm.com  Tue Feb  9 06:32:56 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Tue,  9 Feb 2016 14:32:56 +0000
Subject: [PATCH 1/2] firmware: arm_scpi: add support for 64-bit sensor values
Message-ID: <1455028377-12728-1-git-send-email-sudeep.holla@arm.com>

SCPI specification version 1.1 extended the sensor from 32-bit to 64-bit
values in order to accommodate new sensor class with 64-bit requirements

Since the SCPI driver sets the higher 32-bit for older protocol version
to zeros, there's no need to explicitly check the SCPI protocol version
and the backward compatibility is maintainted.

Cc: Punit Agrawal <punit.agrawal at arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
---
 drivers/firmware/arm_scpi.c   | 8 +++++---
 drivers/hwmon/scpi-hwmon.c    | 6 +++---
 include/linux/scpi_protocol.h | 2 +-
 3 files changed, 9 insertions(+), 7 deletions(-)

Hi Guenter,

Since I have couple of other fixes for SCPI driver, if you can provide
your ACKs to this couple of patches after your review, I can take all of
them together via ARM-SoC if that's fine with you.

Regards,
Sudeep

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index c32ac6e61ba2..7e3e595c9f30 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -231,7 +231,8 @@ struct _scpi_sensor_info {
 };
 
 struct sensor_value {
-	__le32 val;
+	__le32 lo_val;
+	__le32 hi_val;
 } __packed;
 
 static struct scpi_drvinfo *scpi_info;
@@ -525,7 +526,7 @@ static int scpi_sensor_get_info(u16 sensor_id, struct scpi_sensor_info *info)
 	return ret;
 }
 
-int scpi_sensor_get_value(u16 sensor, u32 *val)
+int scpi_sensor_get_value(u16 sensor, u64 *val)
 {
 	__le16 id = cpu_to_le16(sensor);
 	struct sensor_value buf;
@@ -534,7 +535,8 @@ int scpi_sensor_get_value(u16 sensor, u32 *val)
 	ret = scpi_send_message(SCPI_CMD_SENSOR_VALUE, &id, sizeof(id),
 				&buf, sizeof(buf));
 	if (!ret)
-		*val = le32_to_cpu(buf.val);
+		*val = (u64)le32_to_cpu(buf.hi_val) << 32 |
+			le32_to_cpu(buf.lo_val);
 
 	return ret;
 }
diff --git a/drivers/hwmon/scpi-hwmon.c b/drivers/hwmon/scpi-hwmon.c
index 7e20567bc369..7101b14b5137 100644
--- a/drivers/hwmon/scpi-hwmon.c
+++ b/drivers/hwmon/scpi-hwmon.c
@@ -52,7 +52,7 @@ static int scpi_read_temp(void *dev, int *temp)
 	struct scpi_sensors *scpi_sensors = zone->scpi_sensors;
 	struct scpi_ops *scpi_ops = scpi_sensors->scpi_ops;
 	struct sensor_data *sensor = &scpi_sensors->data[zone->sensor_id];
-	u32 value;
+	u64 value;
 	int ret;
 
 	ret = scpi_ops->sensor_get_value(sensor->info.sensor_id, &value);
@@ -70,7 +70,7 @@ scpi_show_sensor(struct device *dev, struct device_attribute *attr, char *buf)
 	struct scpi_sensors *scpi_sensors = dev_get_drvdata(dev);
 	struct scpi_ops *scpi_ops = scpi_sensors->scpi_ops;
 	struct sensor_data *sensor;
-	u32 value;
+	u64 value;
 	int ret;
 
 	sensor = container_of(attr, struct sensor_data, dev_attr_input);
@@ -79,7 +79,7 @@ scpi_show_sensor(struct device *dev, struct device_attribute *attr, char *buf)
 	if (ret)
 		return ret;
 
-	return sprintf(buf, "%u\n", value);
+	return sprintf(buf, "%llu\n", value);
 }
 
 static ssize_t
diff --git a/include/linux/scpi_protocol.h b/include/linux/scpi_protocol.h
index 72ce932c69b2..ecd248d46281 100644
--- a/include/linux/scpi_protocol.h
+++ b/include/linux/scpi_protocol.h
@@ -68,7 +68,7 @@ struct scpi_ops {
 	struct scpi_dvfs_info *(*dvfs_get_info)(u8);
 	int (*sensor_get_capability)(u16 *sensors);
 	int (*sensor_get_info)(u16 sensor_id, struct scpi_sensor_info *);
-	int (*sensor_get_value)(u16, u32 *);
+	int (*sensor_get_value)(u16, u64 *);
 };
 
 #if IS_REACHABLE(CONFIG_ARM_SCPI_PROTOCOL)
-- 
1.9.1



From sudeep.holla at arm.com  Tue Feb  9 06:32:57 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Tue,  9 Feb 2016 14:32:57 +0000
Subject: [PATCH 2/2] hwmon: (scpi) add energy meter support
In-Reply-To: <1455028377-12728-1-git-send-email-sudeep.holla@arm.com>
References: <1455028377-12728-1-git-send-email-sudeep.holla@arm.com>
Message-ID: <1455028377-12728-2-git-send-email-sudeep.holla@arm.com>

SCPI specification v1.1 adds support for energy sensors. This patch
adds support for the same.

Cc: Punit Agrawal <punit.agrawal at arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
---
 drivers/hwmon/scpi-hwmon.c    | 8 ++++++++
 include/linux/scpi_protocol.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/hwmon/scpi-hwmon.c b/drivers/hwmon/scpi-hwmon.c
index 7101b14b5137..912b449c8303 100644
--- a/drivers/hwmon/scpi-hwmon.c
+++ b/drivers/hwmon/scpi-hwmon.c
@@ -114,6 +114,7 @@ static int scpi_hwmon_probe(struct platform_device *pdev)
 {
 	u16 nr_sensors, i;
 	int num_temp = 0, num_volt = 0, num_current = 0, num_power = 0;
+	int num_energy = 0;
 	struct scpi_ops *scpi_ops;
 	struct device *hwdev, *dev = &pdev->dev;
 	struct scpi_sensors *scpi_sensors;
@@ -182,6 +183,13 @@ static int scpi_hwmon_probe(struct platform_device *pdev)
 				 "power%d_label", num_power + 1);
 			num_power++;
 			break;
+		case ENERGY:
+			snprintf(sensor->input, sizeof(sensor->input),
+				 "energy%d_input", num_energy + 1);
+			snprintf(sensor->label, sizeof(sensor->input),
+				 "energy%d_label", num_energy + 1);
+			num_energy++;
+			break;
 		default:
 			continue;
 		}
diff --git a/include/linux/scpi_protocol.h b/include/linux/scpi_protocol.h
index ecd248d46281..35de50a65665 100644
--- a/include/linux/scpi_protocol.h
+++ b/include/linux/scpi_protocol.h
@@ -33,6 +33,7 @@ enum scpi_sensor_class {
 	VOLTAGE,
 	CURRENT,
 	POWER,
+	ENERGY,
 };
 
 struct scpi_sensor_info {
-- 
1.9.1



From ard.biesheuvel at linaro.org  Tue Feb  9 06:35:42 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 9 Feb 2016 15:35:42 +0100
Subject: [PATCH v4 0/6] arm64 UEFI early FDT handling
In-Reply-To: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
References: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
Message-ID: <CAKv+Gu-osoi53cpikDtZitJJX2gtZyhOMuvYf=cfeZi8zJ-LDg@mail.gmail.com>

(+ Grant)

On 9 February 2016 at 14:53, Robert Richter <rrichter at caviumnetworks.com> wrote:
> From: Robert Richter <rrichter at cavium.com>
>
> Reposting an updated version of this patches ported to 4.5-rc1. It is
> a followup to the version 3 from:
>
>  http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel at linaro.org
>
> The series is essential for NUMA on arm64. Early FDT handling is
> required to make system topology data from firmware, esp. for cpus and
> memory available to the early boot process. Ganapat's numa patches
> depend on it. This series has been tested with his series v10 posted
> here:
>
>  http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni at caviumnetworks.com
>

Hello Robert,

This series does not reflect anymore what we think is the best way to
deal with memory nodes and memreserves on UEFI systems.
Please refer to this thread:
http://thread.gmane.org/gmane.linux.kernel.efi/6464

As far as the memory nodes are concerned, if it is the best place to
store these NUMA annotations, then we should indeed preserve them, but
I think the discussion stalled without any conclusion having been
reached. As far as the /reserved-memory node is concerned, that one we
should really keep, so at least patch 6/6 of this series should be
replaced with something based on the series above.

Thanks,
Ard.


> A number of minor issues exist in the early UEFI/FDT handling path, such as:
> - when booting via UEFI, memreserve entries are removed from the device tree but
>   the /reserved-memory node is not
> - memory nodes are removed from the device tree in a way that is not officially
>   supported by the libfdt API (i.e., you cannot delete nodes while traversing
>   the tree)
> - removal of memory nodes may discard annotations (such as NUMA topology) that
>   should ideally be retained, or may corrupt the tree by discarding nodes
>   referenced by phandles.
>
> Patches #1 and #2 introduce an arm64 specific version of
> early_init_dt_add_memory_arch() so that we can modify it later to ignore DT
> memory nodes if booting via UEFI.
>
> Patch #3 moves some UEFI+FDT init code around before making changes to it.
>
> Patch #4 moves the UEFI initialization to before the early FDT scanning so we
> know at that point whether we are booting via UEFI or not.
>
> Patch #5 changes the UEFI init code so that memory nodes are simply ignored, so
> that they don't have to be removed by the stub anymore.
>
> Patch #6 does the same as #5, but for memreserves and the /reserved-memory
> node.
>
> Changes since v3:
> - prorted to v4.5-rc1
>
> Changes since v2:
> - instead of copying the generic implementation, turn
>   early_init_dt_add_memory_arch() into a weak alias so that it is still
>   accessible to overrides
>
> Changes since v1:
> - dropped first two patches, they have been merged into v4.2-rc1
> - dropped last patch regarding FDT placement by the stub, this is not entirely
>   relevant to the primary issue targeted by this series
> - rebased onto for-next/core (arm64) as of today
>
> Ard Biesheuvel (6):
>   of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
>   arm64: override generic version of early_init_dt_add_memory_arch()
>   efi: move FDT handling to separate object file
>   arm64/efi: move EFI /chosen node parsing before early FDT processing
>   arm64/efi: ignore DT memory nodes instead of removing them
>   arm64/efi: ignore DT memreserve entries instead of removing them
>
>  arch/arm64/include/asm/efi.h       |  2 +
>  arch/arm64/kernel/setup.c          |  3 ++
>  arch/arm64/mm/init.c               | 12 +++++-
>  drivers/firmware/efi/Makefile      |  1 +
>  drivers/firmware/efi/arm-init.c    | 36 ++++++++++------
>  drivers/firmware/efi/efi-fdt.c     | 73 +++++++++++++++++++++++++++++++++
>  drivers/firmware/efi/efi.c         | 84 --------------------------------------
>  drivers/firmware/efi/libstub/fdt.c | 33 +--------------
>  drivers/of/fdt.c                   |  7 +++-
>  include/linux/efi.h                |  2 +-
>  include/linux/of_fdt.h             |  1 +
>  11 files changed, 121 insertions(+), 133 deletions(-)
>  create mode 100644 drivers/firmware/efi/efi-fdt.c
>
> --
> 2.7.0.rc3


From arnd at arndb.de  Tue Feb  9 06:41:54 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 15:41:54 +0100
Subject: [PATCH V3 0/5] PCIe Xilinx generic driver for Microblaze and
In-Reply-To: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
References: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
Message-ID: <20578581.RaDqZvvMdm@wuerfel>

On Tuesday 09 February 2016 16:11:53 Bharat Kumar Gogada wrote:
> This patch series does modifications to pcie-xilinx.c, to support common
> driver on both Zynq and Microblaze architectures.
> Microblaze pci-common.c has been modified to support generic driver.
> 
> Bharat Kumar Gogada (5):
>   PCI: xilinx: Removing xilinx_pcie_parse_and_add_res function
>   PCI: xilinx: Removing struct hw_pci structure.
>   PCI: xilinx: Modifying AXI PCIe Host Bridge driver to     work on both
>      Zynq and Microblaze
>   PCI: xilinx: Updating Zynq PCI binding documentation     with 
>     Microblaze node.
>   Microblaze: Modifying microblaze PCI subsytem to     support  generic
>     Xilinx  AXI PCIe Host Bridge IP driver
> 

Reviewed-by: Arnd Bergmann <arnd at arndb.de>

I'm still not happy about needing the pci_fixup_irqs in patch 3/5, but
I can understand that fixing this is beyond the scope of your series.

	Arnd


From jassisinghbrar at gmail.com  Tue Feb  9 06:54:07 2016
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Tue, 9 Feb 2016 20:24:07 +0530
Subject: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager
In-Reply-To: <56B9DC30.5040806@ti.com>
References: <1454690044-2560-1-git-send-email-nm@ti.com>
 <1454690044-2560-2-git-send-email-nm@ti.com>
 <CABb+yY3kGq_R49Xx4fK3UMqtuFiuv-pXJWvjkEFLPL9xRu5T4A@mail.gmail.com>
 <56B9DC30.5040806@ti.com>
Message-ID: <CABb+yY24XzsWaSGLMCE4_nvgWx0OhhQmcaP41g06FxdjQYFchg@mail.gmail.com>

On Tue, Feb 9, 2016 at 6:01 PM, Nishanth Menon <nm at ti.com> wrote:
> On 02/08/2016 10:14 PM, Jassi Brar wrote:
>
> Thanks for the review.
>
>> On Fri, Feb 5, 2016 at 10:04 PM, Nishanth Menon <nm at ti.com> wrote:
>>> +
>>> +       msgmgr: msgmgr at 02a00000 {
>>> +               compatible = "ti,k2g-message-manager", "ti,message-manager";
>>> +               #mbox-cells = <1>;
>>> +               reg-names = "queue_proxy_region", "queue_state_debug_region";
>>> +               reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
>>> +
>>> +               msgmgr_proxy_pmmc_tx_prio0: pmmc_tx_prio0 {
>>> +                       ti,queue-id = <0>;
>>> +                       ti,proxy-id = <0>;
>>> +               };
>>> +
>>> +               msgmgr_proxy_pmmc_rx: pmmc_rx {
>>> +                       ti,queue-id = <5>;
>>> +                       ti,proxy-id = <2>;
>>> +                       interrupt-names = "rx";
>>> +                       interrupts = <GIC_SPI 32I didn't respond because I think Suman got Rob's point wrong.I didn't respond because I think Suman got Rob's point wrong.4 IRQ_TYPE_EDGE_RISING>;
>>> +               };
>>> +       };
>>> +
>> I think we should get rid of consumer specifics from the provider node...
>
>
> If I get rid of the consumer nodes, how do you propose I describe the rx
> queue interrupt(s) in the msmgr dt node (Every Rx queue will have it's
> own interrupt - and it cannot be reverse computed from queue ID, proxy ID)?
>
One option is to have controller driver construct interrupt name from
queue and proxy ids like

msgmgr: msgmgr at 02a00000 {
   ....
     interrupt-names = "irq_5_2", "irq_0_0";     /* irq_<queue-id>_<proxy-id> */
     interrupts = <GIC_SPI 324 IRQ_TYPE_EDGE_RISING>,
                        <GIC_SPI 325 IRQ_TYPE_EDGE_RISING>;
}

and have the consumer specify queue and proxy ids in mboxes property like
 pmmc {
       ....
       mbox-names = "tx", "rx";
       mboxes = <&msgmgr 0 0>
                          <&msgmgr 5 2>;
};


>>> +...
>>> +       pmmc {
>>> +               ...
>>> +               mbox-names = "tx", "rx";
>>> +               mboxes = <&msgmgr &msgmgr_proxy_pmmc_tx>
>>> +                        <&msgmgr &msgmgr_proxy_pmmc_rx>;
>>> +               ...
>>> +       };
>>>
>> ... and have consumers like
>>        pmmc {
>>                ...
>>                mbox-names = "tx", "rx";
>>                mboxes = <&msgmgr 0 0>
>>                         <&msgmgr 5 2>;
>>        };
>>
>> I leave the IRQ for you to decide how to specify - a 'dummy' or
>> 'valid' always provided as last cell in mboxes or some other way.
>> (I'll review other patches in detail later)
>
> What do we do with the issues that Suman pointed out in the mailbox
> framework itself? Could you respond to that thread[1] as well?
>
Phandle of provider in consumer node is quite normal and acceptable.
I think Rob (at least I am) is talking about the second cell where you
specify phandle (&msgmgr_proxy_xxx) instead of values from those child
nodes directly.
Which is what I suggest   mboxes = <&msgmgr 0 0>,  <&msgmgr 5 2>;

Cheers!


From will.deacon at arm.com  Tue Feb  9 06:54:26 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Feb 2016 14:54:26 +0000
Subject: [PATCH] arm64: replace read_lock to rcu lock in call_step_hook
In-Reply-To: <1454971764-30720-1-git-send-email-yang.shi@linaro.org>
References: <1454971764-30720-1-git-send-email-yang.shi@linaro.org>
Message-ID: <20160209145426.GR22874@arm.com>

On Mon, Feb 08, 2016 at 02:49:24PM -0800, Yang Shi wrote:
> BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
> in_atomic(): 1, irqs_disabled(): 128, pid: 383, name: sh
> Preemption disabled at:[<ffff800000124c18>] kgdb_cpu_enter+0x158/0x6b8
> 
> CPU: 3 PID: 383 Comm: sh Tainted: G        W       4.1.13-rt13 #2
> Hardware name: Freescale Layerscape 2085a RDB Board (DT)
> Call trace:
> [<ffff8000000885e8>] dump_backtrace+0x0/0x128
> [<ffff800000088734>] show_stack+0x24/0x30
> [<ffff80000079a7c4>] dump_stack+0x80/0xa0
> [<ffff8000000bd324>] ___might_sleep+0x18c/0x1a0
> [<ffff8000007a20ac>] __rt_spin_lock+0x2c/0x40
> [<ffff8000007a2268>] rt_read_lock+0x40/0x58
> [<ffff800000085328>] single_step_handler+0x38/0xd8
> [<ffff800000082368>] do_debug_exception+0x58/0xb8
> Exception stack(0xffff80834a1e7c80 to 0xffff80834a1e7da0)
> 7c80: ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7e40 ffff8083 001bfcc4 ffff8000
> 7ca0: f2000400 00000000 00000000 00000000 4a1e7d80 ffff8083 0049501c ffff8000
> 7cc0: 00005402 00000000 00aaa210 ffff8000 4a1e7ea0 ffff8083 000833f4 ffff8000
> 7ce0: ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7ea0 ffff8083 001bfcc0 ffff8000
> 7d00: 4a0fc400 ffff8083 00005402 00000000 4a1e7d40 ffff8083 00490324 ffff8000
> 7d20: ffffff9c 00000000 92c23ba0 0000ffff 000a0000 00000000 00000000 00000000
> 7d40: 00000008 00000000 00080000 00000000 92c23b8b 0000ffff 92c23b8e 0000ffff
> 7d60: 00000038 00000000 00001cb2 00000000 00000005 00000000 92d7b498 0000ffff
> 7d80: 01010101 01010101 92be9000 0000ffff 00000000 00000000 00000030 00000000
> [<ffff8000000833f4>] el1_dbg+0x18/0x6c
> 
> This issue is similar with 62c6c61("arm64: replace read_lock to rcu lock in
> call_break_hook"), but comes to single_step_handler.
> 
> This also solves kgdbts boot test silent hang issue on 4.4 -rt kernel.
> 
> Signed-off-by: Yang Shi <yang.shi at linaro.org>

Acked-by: Will Deacon <will.deacon at arm.com>

Will


From arnd at arndb.de  Tue Feb  9 06:54:26 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 15:54:26 +0100
Subject: [PATCH] Kbuild: provide a __UNIQUE_ID for clang
In-Reply-To: <20160208181326.GA3784@pobox.suse.cz>
References: <1454942318-2782493-1-git-send-email-arnd@arndb.de>
 <20160208181326.GA3784@pobox.suse.cz>
Message-ID: <2393216.K0HRYm6hPv@wuerfel>

On Monday 08 February 2016 19:13:26 Michal Marek wrote:
> On Mon, Feb 08, 2016 at 03:38:32PM +0100, Arnd Bergmann wrote:
> > The default __UNIQUE_ID macro in compiler.h fails to work for some drivers:
> > 
> > drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:615:1: error: redefinition of
> >       '__UNIQUE_ID_firmware615'
> > BRCMF_FW_NVRAM_DEF(4354, "brcmfmac4354-sdio.bin", "brcmfmac4354-sdio.txt");
> 
> I applied the patch to kbuild.git#kbuild, but can you tell me with which
> commit and config you get such failure. I only see a single
> MODULE_FIRMWARE() call in the expansion of BRCMF_FW_NVRAM_DEF(), which
> should work with line numbers as well. And I can't reproduce it with
> today's linux-next. If there is some issue with code not yet in
> linux-next, it needs to be worked around, because older GCCs did not
> have __COUNTER__.

I wrote this patch in early January before Arend van Spriel changed the
code with the patch below. I wasn't aware of his change, but that explains
why you don't see the problem any more.

	Arnd

commit 23195ec00503c6c29daea5b6c780787c0b5f1bf3
Author: Arend van Spriel <aspriel at gmail.com>
Date:   Sat Jan 16 16:39:13 2016 +0100

    brcmfmac: fix BRCMF_FW_NVRAM_DEF macro for older gcc compilers
    
    With gcc < 4.3 __UNIQUE_ID does not create unique ids with the macro
    BRCMF_FW_NVRAM_DEF. Fix this by removing the MODULE_FIRMWARE instance
    for the nvram file. This file is not in linux-firmware repo so it may
    not be needed anyway. Otherwise consider this as a temporary fix.
    
    Reported-by: Geert Uytterhoeven <geert at linux-m68k.org>
    Signed-off-by: Arend van Spriel <aspriel at gmail.com>
    Acked-by: Kalle Valo <kvalo at codeaurora.org>
    Tested-by: Geert Uytterhoeven <geert at linux-m68k.org>
    Signed-off-by: David S. Miller <davem at davemloft.net>

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
index ef06f57a7a0e..d3c9f0d52ae3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
@@ -47,8 +47,7 @@ static const char BRCM_ ## fw_nvram_name ## _FIRMWARE_NAME[] = \
 	BRCMF_FW_DEFAULT_PATH fw; \
 static const char BRCM_ ## fw_nvram_name ## _NVRAM_NAME[] = \
 	BRCMF_FW_DEFAULT_PATH nvram; \
-MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH fw); \
-MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH nvram)
+MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH fw);
 
 #define BRCMF_FW_DEF(fw_name, fw) \
 static const char BRCM_ ## fw_name ## _FIRMWARE_NAME[] = \



From arnd at arndb.de  Tue Feb  9 06:57:08 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 15:57:08 +0100
Subject: [PATCH V2 03/12] dtb: amd: Fix DMA ranges in device tree
In-Reply-To: <1454954357-8395-4-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
 <1454954357-8395-4-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <2845776.WTPtnQzg8d@wuerfel>

On Monday 08 February 2016 11:59:08 Suravee Suthikulpanit wrote:
> From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
> 
> Fix DMA ranges of smb0 and pcie0 nodes in AMD Seattle SOC.
> 
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
> 

This could use a changelog text to explain why it's broken and how the
fix works.

	Arnd


From arnd at arndb.de  Tue Feb  9 06:58:03 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 15:58:03 +0100
Subject: [PATCH V2 08/12] dtb: amd: Add PERF CCN-504 device tree node
In-Reply-To: <1454954357-8395-9-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
 <1454954357-8395-9-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <3090961.S0JY5ma2pB@wuerfel>

On Monday 08 February 2016 11:59:13 Suravee Suthikulpanit wrote:
> +               /* Perf CCN504 PMU */
> +               ccn: ccn at 0xe8000000 {
> 

The address is wrong, please remove the '0x'.

	Arnd


From arnd at arndb.de  Tue Feb  9 06:59:17 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 15:59:17 +0100
Subject: [PATCH V2 09/12] dtb: amd: Add KCS device tree node
In-Reply-To: <1454954357-8395-10-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
 <1454954357-8395-10-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <4018438.bPuTyoUuqf@wuerfel>

On Monday 08 February 2016 11:59:14 Suravee Suthikulpanit wrote:
> +
> +               ipmi_kcs: kcs at e0010000 {
> +                       status = "disabled";
> +                       compatible = "ipmi-kcs";
> +                       device_type = "ipmi";
> +                       reg = <0x0 0xe0010000 0 0x8>;
> +                       interrupts = <0 389 4>;
> +                       interrupt-names = "ipmi_kcs";
> +                       reg-size = <1>;
> +                       reg-spacing = <4>;
> +               };
>         };
> 

I see we don't have a binding file for this, can you add one please?


Why the strange name for the interrupt?

	Arnd


From krzysztof.adamski at tieto.com  Tue Feb  9 06:58:44 2016
From: krzysztof.adamski at tieto.com (Krzysztof Adamski)
Date: Tue,  9 Feb 2016 15:58:44 +0100
Subject: [PATCH v4 0/5] pinctrl: sunxi: Add H3 R_PIO controller support
Message-ID: <1455029929-18547-1-git-send-email-k@japko.eu>

This patch series is extension of my original single patch with the same
subject. It adds support for R_PIO so that GPIO port L can be used in H3
based devices. It was tested on OrangePi PC where PL is connected amount
others to an onboard led, a switch, an IR receiver and some VCC
controllers.

Patchset is based on next-20160209.

--- 

Changes since v3:
- collect some acked-bys
- fix r_pios #interrupt-cells

Changes since v2:
- fixed apb0 parrent clocks list
- moved binding documentation change to the proper patch
- simplified sunxi_pinctrl_gpio_get according to ChenYu suggestions
- fixed ordering in sunxi binding documentation

Changes since v1:
- splited patch to two separate - dtsi and c files
- added APB0 clocks a parent for R_PIO
- added fix in sunxi_pinctrl_gpio_get for getting pin value when in irq
  mode and on 2nd pinctrl
- fixed a "pwn" > "pwm" typo
- fixed order in allwinner,sunxi-pinctrl.txt


Krzysztof Adamski (5):
  clk: sunxi: Add apb0 gates for H3
  dts: sun8i-h3: Add APB0 related clocks and resets
  pinctrl: sunxi: Add H3 R_PIO controller support
  ARM: dts: sun8i-h3: Add R_PIO controller node to the dtsi
  pinctrl: sunxi: Use pin number when calling sunxi_pmx_set

 Documentation/devicetree/bindings/clock/sunxi.txt  |   1 +
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 arch/arm/boot/dts/sun8i-h3.dtsi                    |  36 +++++++
 drivers/clk/sunxi/clk-simple-gates.c               |   2 +
 drivers/pinctrl/sunxi/Kconfig                      |   4 +
 drivers/pinctrl/sunxi/Makefile                     |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c         | 106 +++++++++++++++++++++
 drivers/pinctrl/sunxi/pinctrl-sunxi.c              |   5 +-
 8 files changed, 154 insertions(+), 2 deletions(-)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c

-- 
2.1.4



From krzysztof.adamski at tieto.com  Tue Feb  9 06:58:45 2016
From: krzysztof.adamski at tieto.com (Krzysztof Adamski)
Date: Tue,  9 Feb 2016 15:58:45 +0100
Subject: [PATCH v4 1/5] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <1455029929-18547-1-git-send-email-k@japko.eu>
References: <1455029929-18547-1-git-send-email-k@japko.eu>
Message-ID: <1455029929-18547-2-git-send-email-k@japko.eu>

This patch adds support for APB0 in H3. It seems to be compatible with
earlier SOCs. apb0 gates controls R_ block peripherals (R_PIO, R_IR,
etc).

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
 drivers/clk/sunxi/clk-simple-gates.c              | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index 966dcaf..b74f430 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -46,6 +46,7 @@ Required properties:
 	"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
 	"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
 	"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
+	"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
 	"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
 	"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
 	"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
diff --git a/drivers/clk/sunxi/clk-simple-gates.c b/drivers/clk/sunxi/clk-simple-gates.c
index 2cfc5a8..940e7c1 100644
--- a/drivers/clk/sunxi/clk-simple-gates.c
+++ b/drivers/clk/sunxi/clk-simple-gates.c
@@ -132,6 +132,8 @@ CLK_OF_DECLARE(sun8i_a33_ahb1, "allwinner,sun8i-a33-ahb1-gates-clk",
 	       sunxi_simple_gates_init);
 CLK_OF_DECLARE(sun8i_a83t_apb0, "allwinner,sun8i-a83t-apb0-gates-clk",
 	       sunxi_simple_gates_init);
+CLK_OF_DECLARE(sun8i_h3_apb0, "allwinner,sun8i-h3-apb0-gates-clk",
+	       sunxi_simple_gates_init);
 CLK_OF_DECLARE(sun9i_a80_ahb0, "allwinner,sun9i-a80-ahb0-gates-clk",
 	       sunxi_simple_gates_init);
 CLK_OF_DECLARE(sun9i_a80_ahb1, "allwinner,sun9i-a80-ahb1-gates-clk",
-- 
2.1.4



From krzysztof.adamski at tieto.com  Tue Feb  9 06:58:48 2016
From: krzysztof.adamski at tieto.com (Krzysztof Adamski)
Date: Tue,  9 Feb 2016 15:58:48 +0100
Subject: [PATCH v4 4/5] ARM: dts: sun8i-h3: Add R_PIO controller node to the
 dtsi
In-Reply-To: <1455029929-18547-1-git-send-email-k@japko.eu>
References: <1455029929-18547-1-git-send-email-k@japko.eu>
Message-ID: <1455029929-18547-5-git-send-email-k@japko.eu>

Add the corresponding device node for R_PIO on H3 to the dtsi. Support
for the controller was added in earlier commit.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index a7b2c53..528e34c 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -526,5 +526,17 @@
 			compatible = "allwinner,sun6i-a31-clock-reset";
 			#reset-cells = <1>;
 		};
+
+		r_pio: pinctrl at 01f02c00 {
+			compatible = "allwinner,sun8i-h3-r-pinctrl";
+			reg = <0x01f02c00 0x400>;
+			interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&apb0_gates 0>;
+			resets = <&apb0_reset 0>;
+			gpio-controller;
+			#gpio-cells = <3>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+		};
 	};
 };
-- 
2.1.4



From krzysztof.adamski at tieto.com  Tue Feb  9 06:58:46 2016
From: krzysztof.adamski at tieto.com (Krzysztof Adamski)
Date: Tue,  9 Feb 2016 15:58:46 +0100
Subject: [PATCH v4 2/5] dts: sun8i-h3: Add APB0 related clocks and resets
In-Reply-To: <1455029929-18547-1-git-send-email-k@japko.eu>
References: <1455029929-18547-1-git-send-email-k@japko.eu>
Message-ID: <1455029929-18547-3-git-send-email-k@japko.eu>

APB0 is bearly mentioned in H3 User Manual and it is only setup in the
Allwinners kernel dump for CIR. I have verified experimentally that the
gate for R_PIO exists and works, though. There are probably other gates
there but I don't know their order right now and I don't have access to
their peripherals on my board to test them.

After some experiments and reviewing how this is organized on other
sunxi SoCs, I couldn't actually find any way to disable clocks for R_PIO
and they are working properly without doing anything so I assume they
are connected straight to the 24Mhz oscillator for now.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 6f6b4e4..a7b2c53 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -285,6 +285,24 @@
 			clocks = <&osc24M>, <&pll6x2>, <&pll5>;
 			clock-output-names = "mbus";
 		};
+
+		apb0: apb0_clk {
+			compatible = "fixed-factor-clock";
+			#clock-cells = <0>;
+			clock-div = <1>;
+			clock-mult = <1>;
+			clocks = <&osc24M>;
+			clock-output-names = "apb0";
+		};
+
+		apb0_gates: clk at 01f01428 {
+			compatible = "allwinner,sun8i-h3-apb0-gates-clk";
+			reg = <0x01f01428 0x4>;
+			#clock-cells = <1>;
+			clocks = <&apb0>;
+			clock-indices = <0>, <1>;
+			clock-output-names = "apb0_pio", "apb0_ir";
+		};
 	};
 
 	soc {
@@ -502,5 +520,11 @@
 			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
 		};
+
+		apb0_reset: reset at 01f014b0 {
+			reg = <0x01f014b0 0x4>;
+			compatible = "allwinner,sun6i-a31-clock-reset";
+			#reset-cells = <1>;
+		};
 	};
 };
-- 
2.1.4



From krzysztof.adamski at tieto.com  Tue Feb  9 06:58:49 2016
From: krzysztof.adamski at tieto.com (Krzysztof Adamski)
Date: Tue,  9 Feb 2016 15:58:49 +0100
Subject: [PATCH v4 5/5] pinctrl: sunxi: Use pin number when calling
 sunxi_pmx_set
In-Reply-To: <1455029929-18547-1-git-send-email-k@japko.eu>
References: <1455029929-18547-1-git-send-email-k@japko.eu>
Message-ID: <1455029929-18547-6-git-send-email-k@japko.eu>

sunxi_pmx_set accepts pin number and then calculates offset by
subtracting pin_base from it. sunxi_pinctrl_gpio_get, on the other hand,
gets offset so we have to convert it to pin number so we won't get
negative value in sunxi_pmx_set.

This was only used on A10 so far, where there is only one GPIO chip with
pin_base set to 0 so it didn't matter. However H3 also requires this
workaround but have two pinmux sections, triggering problem for PL port.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
Acked-by: Chen-Yu Tsai <wens at csie.org>
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 drivers/pinctrl/sunxi/pinctrl-sunxi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 7a2465f..96f64a1 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -459,15 +459,16 @@ static int sunxi_pinctrl_gpio_get(struct gpio_chip *chip, unsigned offset)
 	u8 index = sunxi_data_offset(offset);
 	u32 set_mux = pctl->desc->irq_read_needs_mux &&
 			test_bit(FLAG_USED_AS_IRQ, &chip->desc[offset].flags);
+	u32 pin = offset + chip->base;
 	u32 val;
 
 	if (set_mux)
-		sunxi_pmx_set(pctl->pctl_dev, offset, SUN4I_FUNC_INPUT);
+		sunxi_pmx_set(pctl->pctl_dev, pin, SUN4I_FUNC_INPUT);
 
 	val = (readl(pctl->membase + reg) >> index) & DATA_PINS_MASK;
 
 	if (set_mux)
-		sunxi_pmx_set(pctl->pctl_dev, offset, SUN4I_FUNC_IRQ);
+		sunxi_pmx_set(pctl->pctl_dev, pin, SUN4I_FUNC_IRQ);
 
 	return !!val;
 }
-- 
2.1.4



From krzysztof.adamski at tieto.com  Tue Feb  9 06:58:47 2016
From: krzysztof.adamski at tieto.com (Krzysztof Adamski)
Date: Tue,  9 Feb 2016 15:58:47 +0100
Subject: [PATCH v4 3/5] pinctrl: sunxi: Add H3 R_PIO controller support
In-Reply-To: <1455029929-18547-1-git-send-email-k@japko.eu>
References: <1455029929-18547-1-git-send-email-k@japko.eu>
Message-ID: <1455029929-18547-4-git-send-email-k@japko.eu>

H3 has additional PIO controller similar to what we can find on A23.
It's a 12 pin port, described in H3 Datasheet rev 1.1, pages 345-350.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
Acked-by: Chen-Yu Tsai <wens at csie.org>
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 drivers/pinctrl/sunxi/Kconfig                      |   4 +
 drivers/pinctrl/sunxi/Makefile                     |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c         | 106 +++++++++++++++++++++
 4 files changed, 112 insertions(+)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c

diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index 9213b27..3e56b16 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -21,6 +21,7 @@ Required properties:
   "allwinner,sun9i-a80-r-pinctrl"
   "allwinner,sun8i-a83t-pinctrl"
   "allwinner,sun8i-h3-pinctrl"
+  "allwinner,sun8i-h3-r-pinctrl"
 
 - reg: Should contain the register physical address and length for the
   pin controller.
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index f8dbc8b..75a26c9 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -55,6 +55,10 @@ config PINCTRL_SUN8I_H3
 	def_bool MACH_SUN8I
 	select PINCTRL_SUNXI_COMMON
 
+config PINCTRL_SUN8I_H3_R
+	def_bool MACH_SUN8I
+	select PINCTRL_SUNXI_COMMON
+
 config PINCTRL_SUN9I_A80
 	def_bool MACH_SUN9I
 	select PINCTRL_SUNXI_COMMON
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index ef82f22..a5d56f1 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -14,5 +14,6 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23_R)	+= pinctrl-sun8i-a23-r.o
 obj-$(CONFIG_PINCTRL_SUN8I_A33)		+= pinctrl-sun8i-a33.o
 obj-$(CONFIG_PINCTRL_SUN8I_A83T)	+= pinctrl-sun8i-a83t.o
 obj-$(CONFIG_PINCTRL_SUN8I_H3)		+= pinctrl-sun8i-h3.o
+obj-$(CONFIG_PINCTRL_SUN8I_H3_R)	+= pinctrl-sun8i-h3-r.o
 obj-$(CONFIG_PINCTRL_SUN9I_A80)		+= pinctrl-sun9i-a80.o
 obj-$(CONFIG_PINCTRL_SUN9I_A80_R)	+= pinctrl-sun9i-a80-r.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
new file mode 100644
index 0000000..686ec21
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
@@ -0,0 +1,106 @@
+/*
+ * Allwinner H3 SoCs pinctrl driver.
+ *
+ * Copyright (C) 2016 Krzysztof Adamski <k at japko.eu>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/pinctrl.h>
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin sun8i_h3_r_pins[] = {
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_twi"),         /* SCK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),	/* PL_EINT0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_twi"),         /* SDA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),	/* PL_EINT1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_uart"),        /* TX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),	/* PL_EINT2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_uart"),        /* RX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),	/* PL_EINT3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* MS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),	/* PL_EINT4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* CK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),	/* PL_EINT5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* DO */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),	/* PL_EINT6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_jtag"),        /* DI */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),	/* PL_EINT7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),	/* PL_EINT8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),	/* PL_EINT9 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_pwm"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)),	/* PL_EINT10 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "s_cir_rx"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 11)),	/* PL_EINT11 */
+};
+
+static const struct sunxi_pinctrl_desc sun8i_h3_r_pinctrl_data = {
+	.pins = sun8i_h3_r_pins,
+	.npins = ARRAY_SIZE(sun8i_h3_r_pins),
+	.irq_banks = 1,
+	.pin_base = PL_BASE,
+	.irq_read_needs_mux = true
+};
+
+static int sun8i_h3_r_pinctrl_probe(struct platform_device *pdev)
+{
+	return sunxi_pinctrl_init(pdev,
+				  &sun8i_h3_r_pinctrl_data);
+}
+
+static const struct of_device_id sun8i_h3_r_pinctrl_match[] = {
+	{ .compatible = "allwinner,sun8i-h3-r-pinctrl", },
+	{}
+};
+
+static struct platform_driver sun8i_h3_r_pinctrl_driver = {
+	.probe	= sun8i_h3_r_pinctrl_probe,
+	.driver	= {
+		.name		= "sun8i-h3-r-pinctrl",
+		.of_match_table	= sun8i_h3_r_pinctrl_match,
+	},
+};
+builtin_platform_driver(sun8i_h3_r_pinctrl_driver);
-- 
2.1.4



From linux at roeck-us.net  Tue Feb  9 07:06:47 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue,  9 Feb 2016 07:06:47 -0800
Subject: [PATCH] serial: clps711x: Fix bad usage of IS_ERR_VALUE
Message-ID: <1455030407-9075-1-git-send-email-linux@roeck-us.net>

IS_ERR_VALUE() assumes that its parameter is an unsigned long.
It can not be used to check if an unsigned int reflects an error.
Doing so can result in the following build warning.

drivers/tty/serial/clps711x.c: In function ?uart_clps711x_probe?:
include/linux/err.h:21:38: warning:
	comparison is always false due to limited range of data type
drivers/tty/serial/clps711x.c:471:6: note: in expansion of macro ?IS_ERR_VALUE?

If that warning is seen, an error return from platform_get_irq() is missed.

Use a temporary variable to check for errors from platform_get_irq().
Also don't use IS_ERR_VALUE() to check if an integer variable is < 0.
The variable can be checked directly in that case.

Signed-off-by: Guenter Roeck <linux at roeck-us.net>
---
 drivers/tty/serial/clps711x.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/clps711x.c b/drivers/tty/serial/clps711x.c
index b3a4e0cdddaa..5beafd2d2218 100644
--- a/drivers/tty/serial/clps711x.c
+++ b/drivers/tty/serial/clps711x.c
@@ -450,6 +450,7 @@ static int uart_clps711x_probe(struct platform_device *pdev)
 	struct clps711x_port *s;
 	struct resource *res;
 	struct clk *uart_clk;
+	int irq;
 
 	if (index < 0 || index >= UART_CLPS711X_NR)
 		return -EINVAL;
@@ -467,12 +468,13 @@ static int uart_clps711x_probe(struct platform_device *pdev)
 	if (IS_ERR(s->port.membase))
 		return PTR_ERR(s->port.membase);
 
-	s->port.irq = platform_get_irq(pdev, 0);
-	if (IS_ERR_VALUE(s->port.irq))
-		return s->port.irq;
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0)
+		return irq;
+	s->port.irq = irq;
 
 	s->rx_irq = platform_get_irq(pdev, 1);
-	if (IS_ERR_VALUE(s->rx_irq))
+	if (s->rx_irq < 0)
 		return s->rx_irq;
 
 	if (!np) {
-- 
2.5.0



From rostedt at goodmis.org  Tue Feb  9 07:07:58 2016
From: rostedt at goodmis.org (Steven Rostedt)
Date: Tue, 9 Feb 2016 10:07:58 -0500
Subject: [PATCH] arm64: replace read_lock to rcu lock in call_step_hook
In-Reply-To: <20160209145426.GR22874@arm.com>
References: <1454971764-30720-1-git-send-email-yang.shi@linaro.org>
 <20160209145426.GR22874@arm.com>
Message-ID: <20160209100758.69d9006f@gandalf.local.home>

On Tue, 9 Feb 2016 14:54:26 +0000
Will Deacon <will.deacon at arm.com> wrote:


> Acked-by: Will Deacon <will.deacon at arm.com>

Will,

The patch looks good to me. Do you want to take it through your tree?

It benefits mainline too as a rcu_read_lock() is more efficient than
rwlocks. Although I will say this is a slow path anyway.

-- Steve


From linux at roeck-us.net  Tue Feb  9 07:08:59 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue,  9 Feb 2016 07:08:59 -0800
Subject: [PATCH] tty/serial: digicolor: Fix bad usage of IS_ERR_VALUE
Message-ID: <1455030539-10798-1-git-send-email-linux@roeck-us.net>

IS_ERR_VALUE() assumes that its parameter is an unsigned long.
It can not be used to check if an unsigned int reflects an error.
Doing so can result in the following build warning.

drivers/tty/serial/digicolor-usart.c: In function ?digicolor_uart_probe?:
include/linux/err.h:21:38: warning:
	comparison is always false due to limited range of data type
drivers/tty/serial/digicolor-usart.c:485:6: note:
	in expansion of macro ?IS_ERR_VALUE?

If that warning is seen, an error return from platform_get_irq() is missed.

Signed-off-by: Guenter Roeck <linux at roeck-us.net>
---
 drivers/tty/serial/digicolor-usart.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/digicolor-usart.c b/drivers/tty/serial/digicolor-usart.c
index a80cdad114f3..02ad6953b167 100644
--- a/drivers/tty/serial/digicolor-usart.c
+++ b/drivers/tty/serial/digicolor-usart.c
@@ -453,7 +453,7 @@ static struct uart_driver digicolor_uart = {
 static int digicolor_uart_probe(struct platform_device *pdev)
 {
 	struct device_node *np = pdev->dev.of_node;
-	int ret, index;
+	int irq, ret, index;
 	struct digicolor_port *dp;
 	struct resource *res;
 	struct clk *uart_clk;
@@ -481,9 +481,10 @@ static int digicolor_uart_probe(struct platform_device *pdev)
 	if (IS_ERR(dp->port.membase))
 		return PTR_ERR(dp->port.membase);
 
-	dp->port.irq = platform_get_irq(pdev, 0);
-	if (IS_ERR_VALUE(dp->port.irq))
-		return dp->port.irq;
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0)
+		return irq;
+	dp->port.irq = irq;
 
 	dp->port.iotype = UPIO_MEM;
 	dp->port.uartclk = clk_get_rate(uart_clk);
-- 
2.5.0



From arnd at arndb.de  Tue Feb  9 07:10:21 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 16:10:21 +0100
Subject: [PATCH] ARM: ks8695: fix __initdata annotation
In-Reply-To: <20160209113624.GU13664@pengutronix.de>
References: <1454941509-2773774-1-git-send-email-arnd@arndb.de>
 <18237653.x9qPaNvtCU@wuerfel> <20160209113624.GU13664@pengutronix.de>
Message-ID: <3182431.K4Gl4054Gk@wuerfel>

On Tuesday 09 February 2016 12:36:24 Uwe Kleine-K?nig wrote:
> Having the attribute list after the declarator isn't recommended as
> explicit as I remember having read it somewhere in the gcc docs.
> 
>         info gcc "Attribute Syntax"
> 
> has:
> 
>          An attribute specifier list may appear immediately before a declarator
>         (other than the first) in a comma-separated list of declarators in a
>         declaration of more than one identifier using a single list of
>         specifiers and qualifiers.  Such attribute specifiers apply only to the
>         identifier before whose declarator they appear.  For example, in
> 
>              __attribute__((noreturn)) void d0 (void),
>                  __attribute__((format(printf, 1, 2))) d1 (const char *, ...),
>                   d2 (void)
> 
>         the 'noreturn' attribute applies to all the functions declared; the
>         'format' attribute only applies to 'd1'.
> 
> (Funny enough, in the example the attribute specifier list doesn't
> appear *immediately* before the declarator d0.)
> 
> This might be interpreted as "usually the attribute specifier list appears
> after the declarator". Other than that I cannot find an explict
> recommended placement in the docs. The examples in
> 
>         info gcc "Variable Attributes"
> 
> always have the attribute list after the declarator.

Ok, thanks for the detailed answer, I've fixed it up locally now.
I guess I'm applying the patch in arm-soc directly at some point
and will use the line you suggested after some more testing:

 static struct map_desc og_io_desc[] __initdata = {


	Arnd


From ard.biesheuvel at linaro.org  Tue Feb  9 07:13:45 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  9 Feb 2016 16:13:45 +0100
Subject: [PATCH v4 0/3] kallsyms: remove special handling for CONFIG_ARM
Message-ID: <1455030828-6416-1-git-send-email-ard.biesheuvel@linaro.org>

The kallsyms symbol address table generation contains a workaround for
CONFIG_ARM to address an issue with perf when it sees symbols whose
addresses are close to 0x0. The workaround is only enabled if XIP_KERNEL=n,
not because the issue itself only exists in that case, but because the
chosen workaround cannot deal with [_stext,_etext] living below PAGE_OFFSET.

So let's fix this properly, by emitting the stubs symbols at a more reasonable
offset, which is more likely to be the actual location of the vectors and stubs
sections at runtime, and will prevent the symbols from being mistaken for
userland symbols by perf.

Changes since v3:
- rebased onto -next, which contains a patch that moves the XIP handling to a
  separate linker script (patch #1)
  
Changes since v2:
- Move back to the original arrangement, where .stubs follows .vectors, and both
  are emitted outside of the ordinary kernel VMA space
- Move .vectors and .stubs sections to VMA 0xffff0000/0xffff1000, respectively.
  As Russell pointed out, this is the most reasonable value, since modern CPUs
  actually execute the vectors and stubs from there, and it fixes the kallsyms
  perf issue all the same.
- Rebased onto latest -next, which contains related ARM patch 8514/1, and
  updated kallsyms base relative patches (queued via akpm's tree)

Changes since v1:
- added Nico's ack
- use PROVIDE() for vector_fiq_offset since vector_fiq itself is not always
  defined
- put __stubs_start/_end inside the section definition so that the value of the
  start symbol equals the start of the section after alignment (fixes an issue
  on XIP spotted by Chris)

Patch #1 moves the .stubs and .vectors section back into the kernel VMA, while
preserving the guaranteed virtual offset of 4 KB. This results in all symbols
that kallsyms sees to be in a reasonable interval.

Patch #2 removes the special case for CONFIG_ARM && !CONFIG_XIP_KERNEL in the
invocation of scripts/kallsyms

Patch #3 removes the now unused --page-offset command line argument handling
from scripts/kallsyms.c

Ard Biesheuvel (3):
  ARM: move .vectors and .stubs sections back into the kernel VMA
  kallsyms: remove special lower address limit for CONFIG_ARM
  kallsyms: remove --page-offset command line option

 arch/arm/kernel/entry-armv.S      | 3 +--
 arch/arm/kernel/vmlinux-xip.lds.S | 6 ++++--
 arch/arm/kernel/vmlinux.lds.S     | 6 ++++--
 scripts/kallsyms.c                | 8 --------
 scripts/link-vmlinux.sh           | 4 ----
 5 files changed, 9 insertions(+), 18 deletions(-)

-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb  9 07:13:46 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  9 Feb 2016 16:13:46 +0100
Subject: [PATCH v4 1/3] ARM: move .vectors and .stubs sections back into the
 kernel VMA
In-Reply-To: <1455030828-6416-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455030828-6416-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455030828-6416-2-git-send-email-ard.biesheuvel@linaro.org>

Commit b9b32bf70f2f ("ARM: use linker magic for vectors and vector stubs")
updated the linker script to emit the .vectors and .stubs sections into a
VMA range that is zero based and disjoint from the normal static kernel
region. The reason for that was that this way, the sections can be placed
exactly 4 KB apart, while the payload of the .vectors section is only 32
bytes.

Since the symbols that are part of the .stubs section are emitted into the
kallsyms table, they appear with zero based addresses as well, e.g.,

  00001004 t vector_rst
  00001020 t vector_irq
  000010a0 t vector_dabt
  00001120 t vector_pabt
  000011a0 t vector_und
  00001220 t vector_addrexcptn
  00001240 t vector_fiq
  00001240 T vector_fiq_offset

As this confuses perf when it accesses the kallsyms tables, commit
7122c3e9154b ("scripts/link-vmlinux.sh: only filter kernel symbols for
arm") implemented a somewhat ugly special case for ARM, where the value
of CONFIG_PAGE_OFFSET is passed to scripts/kallsyms, and symbols whose
addresses are below it are filtered out. Note that this special case only
applies to CONFIG_XIP_KERNEL=n, not because the issue the patch addresses
exists only in that case, but because finding a limit below which to apply
the filtering is not entirely straightforward.

Since the .vectors and .stubs sections contain position independent code
that is never executed in place, we can emit it at its most likely runtime
VMA (for more recent CPUs), which is 0xffff0000 for the vector table and
0xffff1000 for the stubs. Not only does this fix the perf issue with
kallsyms, allowing us to drop the special case in scripts/kallsyms
entirely, it also gives debuggers a more realistic view of the address
space, and setting breakpoints or single stepping through code in the
vector table or the stubs is more likely to work as expected on CPUs that
use a high vector address. E.g.,

  00001240 A vector_fiq_offset
  ...
  c0c35000 T __init_begin
  c0c35000 T __vectors_start
  c0c35020 T __stubs_start
  c0c35020 T __vectors_end
  c0c352e0 T _sinittext
  c0c352e0 T __stubs_end
  ...
  ffff1004 t vector_rst
  ffff1020 t vector_irq
  ffff10a0 t vector_dabt
  ffff1120 t vector_pabt
  ffff11a0 t vector_und
  ffff1220 t vector_addrexcptn
  ffff1240 T vector_fiq

(Note that vector_fiq_offset is now an absolute symbol, which kallsyms
already ignores by default)

The LMA footprint is identical with or without this change, only the VMAs
are different:

  Before:
  Idx Name          Size      VMA       LMA       File off  Algn
   ...
   14 .notes        00000024  c0c34020  c0c34020  00a34020  2**2
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   15 .vectors      00000020  00000000  c0c35000  00a40000  2**1
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   16 .stubs        000002c0  00001000  c0c35020  00a41000  2**5
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   17 .init.text    0006b1b8  c0c352e0  c0c352e0  00a452e0  2**5
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   ...

  After:
  Idx Name          Size      VMA       LMA       File off  Algn
   ...
   14 .notes        00000024  c0c34020  c0c34020  00a34020  2**2
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   15 .vectors      00000020  ffff0000  c0c35000  00a40000  2**1
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   16 .stubs        000002c0  ffff1000  c0c35020  00a41000  2**5
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   17 .init.text    0006b1b8  c0c352e0  c0c352e0  00a452e0  2**5
                    CONTENTS, ALLOC, LOAD, READONLY, CODE
   ...

Acked-by: Nicolas Pitre <nico at linaro.org>
Acked-by: Chris Brandt <chris.brandt at renesas.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm/kernel/entry-armv.S      | 3 +--
 arch/arm/kernel/vmlinux-xip.lds.S | 6 ++++--
 arch/arm/kernel/vmlinux.lds.S     | 6 ++++--
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 788e40c1254f..e2550500486d 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -1201,8 +1201,7 @@ vector_addrexcptn:
 	.long	__fiq_svc			@  e
 	.long	__fiq_svc			@  f
 
-	.globl	vector_fiq_offset
-	.equ	vector_fiq_offset, vector_fiq
+	.globl	vector_fiq
 
 	.section .vectors, "ax", %progbits
 .L__vectors_start:
diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
index 6f59ef290289..7b1ded6fb628 100644
--- a/arch/arm/kernel/vmlinux-xip.lds.S
+++ b/arch/arm/kernel/vmlinux-xip.lds.S
@@ -154,19 +154,21 @@ SECTIONS
 	 * only thing that matters is their relative offsets
 	 */
 	__vectors_start = .;
-	.vectors 0 : AT(__vectors_start) {
+	.vectors 0xffff0000 : AT(__vectors_start) {
 		*(.vectors)
 	}
 	. = __vectors_start + SIZEOF(.vectors);
 	__vectors_end = .;
 
 	__stubs_start = .;
-	.stubs 0x1000 : AT(__stubs_start) {
+	.stubs ADDR(.vectors) + 0x1000 : AT(__stubs_start) {
 		*(.stubs)
 	}
 	. = __stubs_start + SIZEOF(.stubs);
 	__stubs_end = .;
 
+	PROVIDE(vector_fiq_offset = vector_fiq - ADDR(.vectors));
+
 	INIT_TEXT_SECTION(8)
 	.exit.text : {
 		ARM_EXIT_KEEP(EXIT_TEXT)
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index cdc84693091b..e087a2ed112b 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -164,19 +164,21 @@ SECTIONS
 	 * only thing that matters is their relative offsets
 	 */
 	__vectors_start = .;
-	.vectors 0 : AT(__vectors_start) {
+	.vectors 0xffff0000 : AT(__vectors_start) {
 		*(.vectors)
 	}
 	. = __vectors_start + SIZEOF(.vectors);
 	__vectors_end = .;
 
 	__stubs_start = .;
-	.stubs 0x1000 : AT(__stubs_start) {
+	.stubs ADDR(.vectors) + 0x1000 : AT(__stubs_start) {
 		*(.stubs)
 	}
 	. = __stubs_start + SIZEOF(.stubs);
 	__stubs_end = .;
 
+	PROVIDE(vector_fiq_offset = vector_fiq - ADDR(.vectors));
+
 	INIT_TEXT_SECTION(8)
 	.exit.text : {
 		ARM_EXIT_KEEP(EXIT_TEXT)
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb  9 07:13:47 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  9 Feb 2016 16:13:47 +0100
Subject: [PATCH v4 2/3] kallsyms: remove special lower address limit for
 CONFIG_ARM
In-Reply-To: <1455030828-6416-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455030828-6416-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455030828-6416-3-git-send-email-ard.biesheuvel@linaro.org>

Now that we no longer emit .stubs symbols into a section VMA loaded
at absolute address 0x1000, we can drop the ARM-specific override that
sets a lower limit based on CONFIG_PAGE_OFFSET, below which symbols are
filtered from the kallsyms output.

Acked-by: Nicolas Pitre <nico at linaro.org>
Acked-by: Chris Brandt <chris.brandt at renesas.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 scripts/link-vmlinux.sh | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index b0281f32f075..4846ecb9764c 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -82,10 +82,6 @@ kallsyms()
 		kallsymopt="${kallsymopt} --all-symbols"
 	fi
 
-	if [ -n "${CONFIG_ARM}" ] && [ -z "${CONFIG_XIP_KERNEL}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
-		kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
-	fi
-
 	if [ -n "${CONFIG_X86_64}" ] && [ -n "${CONFIG_SMP}" ]; then
 		kallsymopt="${kallsymopt} --absolute-percpu"
 	fi
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb  9 07:13:48 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue,  9 Feb 2016 16:13:48 +0100
Subject: [PATCH v4 3/3] kallsyms: remove --page-offset command line option
In-Reply-To: <1455030828-6416-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455030828-6416-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455030828-6416-4-git-send-email-ard.biesheuvel@linaro.org>

The --page-offset command line option was only used for ARM, to filter
symbol addresses below CONFIG_PAGE_OFFSET. This is no longer needed, so
remove the functionality altogether.

Acked-by: Nicolas Pitre <nico at linaro.org>
Acked-by: Chris Brandt <chris.brandt at renesas.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 scripts/kallsyms.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 02473b71643b..32c8d43590af 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -63,7 +63,6 @@ static unsigned int table_size, table_cnt;
 static int all_symbols = 0;
 static int absolute_percpu = 0;
 static char symbol_prefix_char = '\0';
-static unsigned long long kernel_start_addr = 0;
 static int base_relative = 0;
 
 int token_profit[0x10000];
@@ -228,10 +227,6 @@ static int symbol_valid(struct sym_entry *s)
 	int i;
 	char *sym_name = (char *)s->sym + 1;
 
-
-	if (s->addr < kernel_start_addr)
-		return 0;
-
 	/* skip prefix char */
 	if (symbol_prefix_char && *sym_name == symbol_prefix_char)
 		sym_name++;
@@ -774,9 +769,6 @@ int main(int argc, char **argv)
 				if ((*p == '"' && *(p+2) == '"') || (*p == '\'' && *(p+2) == '\''))
 					p++;
 				symbol_prefix_char = *p;
-			} else if (strncmp(argv[i], "--page-offset=", 14) == 0) {
-				const char *p = &argv[i][14];
-				kernel_start_addr = strtoull(p, NULL, 16);
 			} else if (strcmp(argv[i], "--base-relative") == 0)
 				base_relative = 1;
 			else
-- 
2.5.0



From arnd at arndb.de  Tue Feb  9 07:14:32 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 16:14:32 +0100
Subject: [PATCH v3 01/12] irqchip: armada-370-xp: add Kconfig option for
 the driver
In-Reply-To: <1454951660-13289-2-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
 <1454951660-13289-2-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <7747159.T9eeT0dC65@wuerfel>

On Monday 08 February 2016 18:14:09 Gregory CLEMENT wrote:
> 
> +config ARMADA_370_XP_IRQ
> +       bool
> +       default y if ARCH_MVEBU
> +       select GENERIC_IRQ_CHIP
> +
> 

Looks good. I wonder if we should also enable this for COMPILE_TEST, e.g.

config ARMADA_370_XP_IRQ
       bool "Marvell Armada 3xx/XP/3xxx interrupt controller" if COMPILE_TEST && !ARCH_MVEBU
       default ARCH_MVEBU
       select GENERIC_IRQ_CHIP

If we do this, it's probably something outside of your series that we should
do for all patches, so don't worry about it here. Any opinions on the general
question?

	Arnd


From vinod.koul at intel.com  Tue Feb  9 07:20:07 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 9 Feb 2016 20:50:07 +0530
Subject: [PATCH] dmaengine: pxa_dma: fix the maximum requestor line
In-Reply-To: <878u2u2vve.fsf@belgarion.home>
References: <1454941131-12308-1-git-send-email-robert.jarzmik@free.fr>
 <20160209033646.GK19598@localhost> <878u2u2vve.fsf@belgarion.home>
Message-ID: <20160209152007.GQ19598@localhost>

On Tue, Feb 09, 2016 at 08:20:05AM +0100, Robert Jarzmik wrote:
> Vinod Koul <vinod.koul at intel.com> writes:
> 
> > On Mon, Feb 08, 2016 at 03:18:51PM +0100, Robert Jarzmik wrote:
> >> The current number of requestor lines is limited to 31. This was an
> >> error of a previous commit, as this number is platform dependent, and is
> >> actually :
> >>  - for pxa25x: 40 requestor lines
> >>  - for pxa27x: 74 requestor lines
> >>  - for pxa3xx: 100 requestor lines
> >> 
> >> As the driver doesn't need to know the exact number, but only an
> >
> > and why would that be a good assumption?
> Well, the driver doesn't use the exact value. Would that be 128, 1000 or 10000,
> it wouldn't change its behavior. The clients either pass -1UL (ie. no flow
> control) or a requestor line number.

Somehow that does not sound right to me. You seem to have no way of knowing
what is the actual max request line for a platforms. What if on pxa25x user
requests more than 40 lines?

> > Btw shouldn't this data come from DT?
> It can if you wish, but in this case I must amend the platform data case too, ie
> mmp_dma_platdata. And this has an impact on MMP architecture. I'd rather have
> the simpler approach unless you really want the exact number of requestor lines
> to be passed in platform_data+DT.

The information that you have X lines on a platform needs to be described
and queried. I see current approach error prone

-- 
~Vinod


From broonie at kernel.org  Tue Feb  9 07:17:45 2016
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Feb 2016 15:17:45 +0000
Subject: [PATCH V5 1/2] regulator: Add document for MT6323 regulator
In-Reply-To: <56B9DF5D.2010501@openwrt.org>
References: <1454874037-38905-1-git-send-email-blogic@openwrt.org>
 <20160209124133.GE13270@sirena.org.uk>
 <56B9DF5D.2010501@openwrt.org>
Message-ID: <20160209151745.GG13270@sirena.org.uk>

On Tue, Feb 09, 2016 at 01:45:17PM +0100, John Crispin wrote:

> How would you like it to be. i am failing to understand that from your
> comment.

Remove the compatible string, you don't have a separate device to bind
to.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/b6ec989c/attachment.sig>

From arnd at arndb.de  Tue Feb  9 07:23:20 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 16:23:20 +0100
Subject: [PATCH v3 00/12] Add support for the Armada 3700 SoC an mvebu
 ARM64 based
In-Reply-To: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <3329016.IcNNJBVSgr@wuerfel>

On Monday 08 February 2016 18:14:08 Gregory CLEMENT wrote:
> This series introduce the support of the Armada 3700 family: it is the
> first ARM64 SoC of the mvebu family submitted to the mainline!
> 
> Currently there are two members of the Armada 3700 family, the only
> difference is the number of core: the Armada 3710 comes with one
> Cortex-A53 whereas the Armada 3720 comes with 2 Cortex-A53. In this
> series we enabled only the minimum to boot, pinctrl and clock tree
> will come soon.
> 
> The changes in this third version are very small (see the changelog).
> 
> The first two patches patches are here to be able to use the the
> ARCH_MVEBU for the Armada 3700 SoCs. The first ones is only here to
> have standalone series but it comes from Thomas Petazzoni's series:
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/472625
> 
> The third patch introduces a new serial driver for the uart used on
> this SoC. The driver remains simple even if the hardware is capable of
> doing more.
> 
> The forth one adapts the ahci driver to support the Armada 3700 SoC.
> The forth patch updates the binding documentation with the new
> compatible string.
> 
> The fifth patch adds a new entry Kconfig entry for this SoC family.
> 
> I took the opportunity of this series to tidy up the Marvell related
> files in the binding documentation with the seventh patch.
> 
> The eighth patch introduces the compatible string for the SoCs of the
> Armada 3700 family.
> 
> The ninth patch could be considered as the bulk of this series: it
> adds the device tree files for the Armada 3700 SoCs and for the
> reference board.
> 
> With the introduction of this new family the MAINTAINERS file, the
> Marvell README and the ARM64 defconfig files have to be updated: it is
> the purpose of the last 3 patches.
> 
> The patches 3 and 4 could be taken directly by the maintainer of their
> respective subsystem as there is no dependency at all with the rest of
> the series. I think that the rest of the series should go through the
> arm-soc maintainer but in doubt I also added the ARM64 maintainer as
> suggested by get_maintainer.pl.
> 
> 

Looks good overall,

Acked-by: Arnd Bergmann <arnd at arndb.de>


From arnd at arndb.de  Tue Feb  9 07:26:38 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 16:26:38 +0100
Subject: [PATCH] tty/serial: digicolor: Fix bad usage of IS_ERR_VALUE
In-Reply-To: <1455030539-10798-1-git-send-email-linux@roeck-us.net>
References: <1455030539-10798-1-git-send-email-linux@roeck-us.net>
Message-ID: <4571887.rTPndCnv20@wuerfel>

On Tuesday 09 February 2016 07:08:59 Guenter Roeck wrote:
> IS_ERR_VALUE() assumes that its parameter is an unsigned long.
> It can not be used to check if an unsigned int reflects an error.
> Doing so can result in the following build warning.
> 
> drivers/tty/serial/digicolor-usart.c: In function ?digicolor_uart_probe?:
> include/linux/err.h:21:38: warning:
>         comparison is always false due to limited range of data type
> drivers/tty/serial/digicolor-usart.c:485:6: note:
>         in expansion of macro ?IS_ERR_VALUE?
> 
> If that warning is seen, an error return from platform_get_irq() is missed.
> 
> 

The patch looks correct to me, but what compiler version and which kernel
tree is it that triggered the warning?

Andrzej Hajda just modified the definition of IS_ERR_VALUE(), and the
changes are still under discussion, but I don't see that warning with
any of the versions.

	Arnd


From wens at csie.org  Tue Feb  9 07:31:27 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue,  9 Feb 2016 23:31:27 +0800
Subject: [PATCH v2] ARM: sunxi_defconfig: Enable MUSB HDRC driver with
 Allwinner glue
Message-ID: <1455031887-14147-1-git-send-email-wens@csie.org>

Allwinner SoCs typically have a Mentor Graphics Inventra MUSB dual role
controller for USB OTG.

Now that the issue with MUSB and USB gadget registration order has been
resolved, we can enable this driver in dual role mode. This requires the
NOP USB transceiver driver, which is also enabled.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---

Changes since v1:

 - Dropped default USB gadget driver.

---
 arch/arm/configs/sunxi_defconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index a55c48e27309..81a1b92fd4e6 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -110,6 +110,10 @@ CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
 CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_HCD_PLATFORM=y
+CONFIG_USB_MUSB_HDRC=y
+CONFIG_USB_MUSB_SUNXI=y
+CONFIG_NOP_USB_XCEIV=y
+CONFIG_USB_GADGET=y
 CONFIG_MMC=y
 CONFIG_MMC_SUNXI=y
 CONFIG_NEW_LEDS=y
-- 
2.7.0



From ldewangan at nvidia.com  Tue Feb  9 07:20:25 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Tue, 9 Feb 2016 20:50:25 +0530
Subject: [PATCH] mfd: Provide MACRO to declare commonly defined MFD cell
 attributes
In-Reply-To: <1455028027-1527-1-git-send-email-lee.jones@linaro.org>
References: <1455028027-1527-1-git-send-email-lee.jones@linaro.org>
Message-ID: <56BA03B9.2010801@nvidia.com>


On Tuesday 09 February 2016 07:57 PM, Lee Jones wrote:
> +
> +#define MFD_CELL_NAME(_name)						\
> +	{								\
> +		MFD_CELL_ALL(_name, NULL, NULL, 0, NULL, NULL)		\
> +	}
> +
>   struct irq_domain;

It is failed in compilation as we can not use ARRAY_SIZE(NULL)

static struct mfd_cell max77620_children[] = {
         MFD_CELL_NAME("max77620-pinctrl"),
};

  CC      drivers/mfd/max77620.o
drivers/mfd/max77620.c:57:2: warning: braces around scalar initializer
   MFD_CELL_NAME("max77620-pinctrl"),

include/linux/compiler-gcc.h:64:63: warning: taking address of 
expression of type 'void'
  #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
                                                                ^
include/linux/bug.h:33:55: note: in definition of macro 'BUILD_BUG_ON_ZERO'
  #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
                                                        ^
include/linux/compiler-gcc.h:64:46: note: in expansion of macro 
'__same_type'
  #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))



From arnd at arndb.de  Tue Feb  9 07:32:14 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 16:32:14 +0100
Subject: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host
 controller ECAM compliant
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1ECAD436@lhreml503-mbs>
References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
 <2599997.xBRrI3qHak@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECAD436@lhreml503-mbs>
Message-ID: <3763449.y3Mfs92xrA@wuerfel>

On Monday 08 February 2016 17:21:27 Gabriele Paoloni wrote:
> Hi Arnd
> 
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > Sent: 08 February 2016 16:30
> > To: Gabriele Paoloni
> > Cc: linux-arm-kernel at lists.infradead.org; Guohanjun (Hanjun Guo);
> > Wangzhou (B); liudongdong (C); Linuxarm; qiujiang; bhelgaas at google.com;
> > Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-pci at vger.kernel.org;
> > linux-kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> > jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth)
> > Subject: Re: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host
> > controller ECAM compliant
> > 
> > On Monday 08 February 2016 15:55:35 Gabriele Paoloni wrote:
> > > > Doesn't this break backwards compatibility?
> > >
> > > Well Hip05/Hip06 SoCs are used into evaluation boards
> > > For the Estuary project.
> > >
> > > https://github.com/hisilicon/estuary
> > >
> > > As this new driver gets upstream we'll merge this new driver into
> > estuary
> > > and release a new version of the firmware to support it.
> > 
> > So what happens to folks running the old firmware then?
> 
> So far we haven't released the PCIe nodes dtsi upstream and we think
> we can handle the firmware upgrade for our current users either
> by pointing them to the updated Estuary branch or by internal 
> channels  

The dts files in the kernel tree are not really that important,
the question is whether you are breaking things for real users.

If the upstream drivers work on some released firmware version,
they should keep working.

> > 
> > > > I think you need to use a new compatible string in the firmware
> > > > if you change the register layout, and then change the driver
> > > > to support both the old and the new layout.
> > >
> > > You are right, for some reason in this patchset I missed the
> > Documentation
> > > update that I posted in the previous one, i.e.:
> > >
> > > --- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> > > +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> > > @@ -23,8 +23,8 @@ Optional properties:
> > >  Hip05 Example (note that Hip06 is the same except compatible):
> > >         pcie at 0xb0080000 {
> > >                 compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
> > > -               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0
> > 0x2000>;
> > > -               reg-names = "rc_dbi", "config";
> > > +               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00100000 0
> > 0x0f00000>;
> > > +               reg-names = "rc_dbi", "ecam-cfg";
> > >
> > 
> > That is not the compatible string, it's an undocumented register set.
> 
> Sorry, I misunderstood here, got it now :)
> 
> > You can either define the a new compatible string that gives the
> > "config"
> > registers a new meaning, or you change the binding to allow two either
> > a "config" or an "ecam-cfg" register set, and let the driver handle
> > both.
> 
> As per reply above I think that it would be quite easy for us to
> let out current users update the BIOS so I don't think there is any
> value in maintaining two version of the drivers one of which will
> not be used.
> 
> What do you think?

Requiring a BIOS update for a kernel update is really bad, even more
so when the same BIOS update breaks older kernels.

	Arnd


From jassisinghbrar at gmail.com  Tue Feb  9 07:35:20 2016
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Tue, 9 Feb 2016 21:05:20 +0530
Subject: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager
In-Reply-To: <CABb+yY24XzsWaSGLMCE4_nvgWx0OhhQmcaP41g06FxdjQYFchg@mail.gmail.com>
References: <1454690044-2560-1-git-send-email-nm@ti.com>
 <1454690044-2560-2-git-send-email-nm@ti.com>
 <CABb+yY3kGq_R49Xx4fK3UMqtuFiuv-pXJWvjkEFLPL9xRu5T4A@mail.gmail.com>
 <56B9DC30.5040806@ti.com>
 <CABb+yY24XzsWaSGLMCE4_nvgWx0OhhQmcaP41g06FxdjQYFchg@mail.gmail.com>
Message-ID: <CABb+yY3cUU6VAkev57sQB7vLGPAwh0YEAb3unsZ+h=Tvm5Nr2Q@mail.gmail.com>

On Tue, Feb 9, 2016 at 8:24 PM, Jassi Brar <jassisinghbrar at gmail.com> wrote:
> On Tue, Feb 9, 2016 at 6:01 PM, Nishanth Menon <nm at ti.com> wrote:
>> On 02/08/2016 10:14 PM, Jassi Brar wrote:
>>

>>>> +
>>> I think we should get rid of consumer specifics from the provider node...
>>
>>
>> If I get rid of the consumer nodes, how do you propose I describe the rx
>> queue interrupt(s) in the msmgr dt node (Every Rx queue will have it's
>> own interrupt - and it cannot be reverse computed from queue ID, proxy ID)?
>>
> One option is to have controller driver construct interrupt name from
> queue and proxy ids like
>
> msgmgr: msgmgr at 02a00000 {
>    ....
>      interrupt-names = "irq_5_2", "irq_0_0";     /* irq_<queue-id>_<proxy-id> */
>      interrupts = <GIC_SPI 324 IRQ_TYPE_EDGE_RISING>,
>                         <GIC_SPI 325 IRQ_TYPE_EDGE_RISING>;
> }
>
> and have the consumer specify queue and proxy ids in mboxes property like
>  pmmc {
>        ....
>        mbox-names = "tx", "rx";
>        mboxes = <&msgmgr 0 0>
>                           <&msgmgr 5 2>;
> };
>
However if the queue+proxy+interrupt tuple is a hard property of a
channel (which it seems to me now), then probably your original scheme
of chile node phandle is just as fine.

Thanks


From nm at ti.com  Tue Feb  9 07:43:46 2016
From: nm at ti.com (Nishanth Menon)
Date: Tue, 9 Feb 2016 09:43:46 -0600
Subject: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager
In-Reply-To: <CABb+yY24XzsWaSGLMCE4_nvgWx0OhhQmcaP41g06FxdjQYFchg@mail.gmail.com>
References: <1454690044-2560-1-git-send-email-nm@ti.com>
 <1454690044-2560-2-git-send-email-nm@ti.com>
 <CABb+yY3kGq_R49Xx4fK3UMqtuFiuv-pXJWvjkEFLPL9xRu5T4A@mail.gmail.com>
 <56B9DC30.5040806@ti.com>
 <CABb+yY24XzsWaSGLMCE4_nvgWx0OhhQmcaP41g06FxdjQYFchg@mail.gmail.com>
Message-ID: <CAGo_u6qGaQj9Qvjwrm7cD=cr2UjLN+62tcquXYPsQrRjYD=UCw@mail.gmail.com>

On Tue, Feb 9, 2016 at 8:54 AM, Jassi Brar <jassisinghbrar at gmail.com> wrote:
> On Tue, Feb 9, 2016 at 6:01 PM, Nishanth Menon <nm at ti.com> wrote:
>> On 02/08/2016 10:14 PM, Jassi Brar wrote:
>>
>> Thanks for the review.
>>
>>> On Fri, Feb 5, 2016 at 10:04 PM, Nishanth Menon <nm at ti.com> wrote:
>>>> +
>>>> +       msgmgr: msgmgr at 02a00000 {
>>>> +               compatible = "ti,k2g-message-manager", "ti,message-manager";
>>>> +               #mbox-cells = <1>;
>>>> +               reg-names = "queue_proxy_region", "queue_state_debug_region";
>>>> +               reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
>>>> +
>>>> +               msgmgr_proxy_pmmc_tx_prio0: pmmc_tx_prio0 {
>>>> +                       ti,queue-id = <0>;
>>>> +                       ti,proxy-id = <0>;
>>>> +               };
>>>> +
>>>> +               msgmgr_proxy_pmmc_rx: pmmc_rx {
>>>> +                       ti,queue-id = <5>;
>>>> +                       ti,proxy-id = <2>;
>>>> +                       interrupt-names = "rx";
>>>> +                       interrupts = <GIC_SPI 32I didn't respond because I think Suman got Rob's point wrong.I didn't respond because I think Suman got Rob's point wrong.4 IRQ_TYPE_EDGE_RISING>;
>>>> +               };
>>>> +       };
>>>> +
>>> I think we should get rid of consumer specifics from the provider node...
>>
>>
>> If I get rid of the consumer nodes, how do you propose I describe the rx
>> queue interrupt(s) in the msmgr dt node (Every Rx queue will have it's
>> own interrupt - and it cannot be reverse computed from queue ID, proxy ID)?
>>
> One option is to have controller driver construct interrupt name from
> queue and proxy ids like
>
> msgmgr: msgmgr at 02a00000 {
>    ....
>      interrupt-names = "irq_5_2", "irq_0_0";     /* irq_<queue-id>_<proxy-id> */
>      interrupts = <GIC_SPI 324 IRQ_TYPE_EDGE_RISING>,
>                         <GIC_SPI 325 IRQ_TYPE_EDGE_RISING>;
> }
>
> and have the consumer specify queue and proxy ids in mboxes property like
>  pmmc {
>        ....
>        mbox-names = "tx", "rx";
>        mboxes = <&msgmgr 0 0>
>                           <&msgmgr 5 2>;
> };
>

I was wondering about the same as well... the best option I can think
of at the moment is as follows:
 - out of a 62*9 (558) all combination possible child nodes, only 11
or so are valid for ARM - this is what is represented as child nodes
to msgmgr. rest of the proxies and queues are inaccessible for ARM.
-  move this "valid queue list" as compatible data in the driver.
- for each of the rx queues identified in the compatible data, I can
do of_irq_get(np, rx_queue_index) without enforcing a naming
convention requirement

If I go with the above approach, I loose ability for non queue
interrupts to be identified appropriately... I think moving valid
queue information to driver compatible data and named irq names might
be the best option for flexibility.

>
>>>> +...
>>>> +       pmmc {
>>>> +               ...
>>>> +               mbox-names = "tx", "rx";
>>>> +               mboxes = <&msgmgr &msgmgr_proxy_pmmc_tx>
>>>> +                        <&msgmgr &msgmgr_proxy_pmmc_rx>;
>>>> +               ...
>>>> +       };
>>>>
>>> ... and have consumers like
>>>        pmmc {
>>>                ...
>>>                mbox-names = "tx", "rx";
>>>                mboxes = <&msgmgr 0 0>
>>>                         <&msgmgr 5 2>;
>>>        };
>>>
>>> I leave the IRQ for you to decide how to specify - a 'dummy' or
>>> 'valid' always provided as last cell in mboxes or some other way.
>>> (I'll review other patches in detail later)
>>
>> What do we do with the issues that Suman pointed out in the mailbox
>> framework itself? Could you respond to that thread[1] as well?
>>
> Phandle of provider in consumer node is quite normal and acceptable.
> I think Rob (at least I am) is talking about the second cell where you
> specify phandle (&msgmgr_proxy_xxx) instead of values from those child
> nodes directly.
> Which is what I suggest   mboxes = <&msgmgr 0 0>,  <&msgmgr 5 2>;

Let me prototype this as part of of_xlate and see if I can pull the
qinst data back out.. obviously one negative will be that I will
register *all* valid channels as part of probe.. at least based on
initial code i wrote today morning..

-- 
---
Regards,
Nishanth Menon


From sudeep.holla at arm.com  Tue Feb  9 07:44:59 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Tue,  9 Feb 2016 15:44:59 +0000
Subject: [PATCH] ARM: dts: spear: replace gpio-key,
 wakeup with wakeup-source property
In-Reply-To: <1454968535-11994-1-git-send-email-sudeep.holla@arm.com>
References: <1454968535-11994-1-git-send-email-sudeep.holla@arm.com>
Message-ID: <1455032699-3086-1-git-send-email-sudeep.holla@arm.com>

Keyboard driver for GPIO buttons(gpio-keys) checks for the legacy
"gpio-key,wakeup" boolean property to enable gpio buttons as wakeup
source.

Few dts files assign value "1" to gpio-key,wakeup which is incorrect.
Since the presence of the boolean property indicates it is enabled,
value of "0" or "1" have no significance.

This patch replaces the legacy "gpio-key,wakeup" with the unified
"wakeup-source" property which inturn fixes the above mentioned issue.

Reviewed-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
---
 arch/arm/boot/dts/spear1310-evb.dts | 2 +-
 arch/arm/boot/dts/spear1340-evb.dts | 2 +-
 arch/arm/boot/dts/spear320-hmi.dts  | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

(this time adding arm at kernel.org correctly)

Hi ARM-SoC guys,

This is the only platform which doesn't have regular pull request,
Viresh has acked it already. Can you pick this up directly for v4.6 ?

Regards,
Sudeep

diff --git a/arch/arm/boot/dts/spear1310-evb.dts b/arch/arm/boot/dts/spear1310-evb.dts
index e48857249ce7..84101e4eebbf 100644
--- a/arch/arm/boot/dts/spear1310-evb.dts
+++ b/arch/arm/boot/dts/spear1310-evb.dts
@@ -161,7 +161,7 @@
 				linux,code = <0x100>;
 				gpios = <&gpio0 7 0x4>;
 				debounce-interval = <20>;
-				gpio-key,wakeup = <1>;
+				wakeup-source;
 			};
 		};
 
diff --git a/arch/arm/boot/dts/spear1340-evb.dts b/arch/arm/boot/dts/spear1340-evb.dts
index c611f5606dfe..6565f3cb866f 100644
--- a/arch/arm/boot/dts/spear1340-evb.dts
+++ b/arch/arm/boot/dts/spear1340-evb.dts
@@ -223,7 +223,7 @@
 				linux,code = <0x100>;
 				gpios = <&gpio1 1 0x4>;
 				debounce-interval = <20>;
-				gpio-key,wakeup = <1>;
+				wakeup-source;
 			};
 		};
 
diff --git a/arch/arm/boot/dts/spear320-hmi.dts b/arch/arm/boot/dts/spear320-hmi.dts
index 0aa6fef5ce22..0d0da1f65f0e 100644
--- a/arch/arm/boot/dts/spear320-hmi.dts
+++ b/arch/arm/boot/dts/spear320-hmi.dts
@@ -141,7 +141,7 @@
 				linux,code = <0x100>;
 				gpios = <&stmpegpio 3 0x4>;
 				debounce-interval = <20>;
-				gpio-key,wakeup = <1>;
+				wakeup-source;
 			};
 
 			button at 2 {
@@ -149,7 +149,7 @@
 				linux,code = <0x200>;
 				gpios = <&stmpegpio 2 0x4>;
 				debounce-interval = <20>;
-				gpio-key,wakeup = <1>;
+				wakeup-source;
 			};
 		};
 
-- 
1.9.1



From brijesh.singh at amd.com  Tue Feb  9 07:47:55 2016
From: brijesh.singh at amd.com (Brijesh Singh)
Date: Tue, 9 Feb 2016 09:47:55 -0600
Subject: [PATCH V2 09/12] dtb: amd: Add KCS device tree node
In-Reply-To: <4018438.bPuTyoUuqf@wuerfel>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
 <1454954357-8395-10-git-send-email-Suravee.Suthikulpanit@amd.com>
 <4018438.bPuTyoUuqf@wuerfel>
Message-ID: <56BA0A2B.5000705@amd.com>

Hi,

On 02/09/2016 08:59 AM, Arnd Bergmann wrote:
> On Monday 08 February 2016 11:59:14 Suravee Suthikulpanit wrote:
>> +
>> +               ipmi_kcs: kcs at e0010000 {
>> +                       status = "disabled";
>> +                       compatible = "ipmi-kcs";
>> +                       device_type = "ipmi";
>> +                       reg = <0x0 0xe0010000 0 0x8>;
>> +                       interrupts = <0 389 4>;
>> +                       interrupt-names = "ipmi_kcs";
>> +                       reg-size = <1>;
>> +                       reg-spacing = <4>;
>> +               };
>>         };
>>
> 
> I see we don't have a binding file for this, can you add one please?
>
There is binding file ipmi.txt [1]. Am I missing something ?
 
[1] http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/ipmi.txt

> 
> Why the strange name for the interrupt?
> 

Now I don't remember the doc but sometime back while implementing BMC on Seattle I saw that interrupt was labeled as "ipmi_kcs"
hence used the same name in DT. But if you want to use different name then let me know the string and will update it.

Theoretically IPMI system interface supports the following interface and any of these interfaces can be used by
A57 to communicate with BMC:

* Keyboard controller style (KCS)
* System Management Interface (SMIC)
* Block transfer (BT)
* SMBus system interface (SSIF)

AMD Seattle platform supports "KCS".



> 	Arnd
> 


From dietmar.eggemann at arm.com  Tue Feb  9 07:54:50 2016
From: dietmar.eggemann at arm.com (Dietmar Eggemann)
Date: Tue, 9 Feb 2016 15:54:50 +0000
Subject: [PATCH v3 2/6] drivers/cpufreq: implement
 init_cpu_capacity_default()
In-Reply-To: <20160205093040.GG29586@e106622-lin>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <1454500799-18451-3-git-send-email-juri.lelli@arm.com>
 <CAKfTPtDGk5BC25WqHdhDYDOBgUsuidAMhrXS=eDi6wJPZjfrwA@mail.gmail.com>
 <20160204093559.GA14099@e105550-lin.cambridge.arm.com>
 <CAKfTPtB4G3bP5N0hU6zWXJTddO34x3RnyGpp-4_otc8O=Wq2hw@mail.gmail.com>
 <20160204121620.GB29586@e106622-lin>
 <CAKfTPtDVasamRtG2kLxP0HsohmVQTPrXRgx36e+jb3gozDoo6g@mail.gmail.com>
 <20160204141345.GD29586@e106622-lin>
 <CAKfTPtDWP-AgqXsSuxCfVj33dh+i7oqDTkL=gUy7n-AB1anoow@mail.gmail.com>
 <CAKfTPtD4jTmUZoShGBm3oAFywizjp8jsEukmkeZU+x+zk-KZRA@mail.gmail.com>
 <20160205093040.GG29586@e106622-lin>
Message-ID: <56BA0BCA.6090903@arm.com>

On 05/02/16 09:30, Juri Lelli wrote:
> On 04/02/16 16:46, Vincent Guittot wrote:
>> On 4 February 2016 at 16:44, Vincent Guittot <vincent.guittot at linaro.org> wrote:
>>> On 4 February 2016 at 15:13, Juri Lelli <juri.lelli at arm.com> wrote:
>>>> On 04/02/16 13:35, Vincent Guittot wrote:
>>>>> On 4 February 2016 at 13:16, Juri Lelli <juri.lelli at arm.com> wrote:
>>>>>> Hi Vincent,
>>>>>>
>>>>>> On 04/02/16 13:03, Vincent Guittot wrote:
>>>>>>> On 4 February 2016 at 10:36, Morten Rasmussen <morten.rasmussen at arm.com> wrote:
>>>>>>>> On Wed, Feb 03, 2016 at 10:04:37PM +0100, Vincent Guittot wrote:
>>>>>>>>> On 3 February 2016 at 12:59, Juri Lelli <juri.lelli at arm.com> wrote:

[...]

>>>
>>> AFAICT, They don't have a dedicated cpufreq driver.
>>>
>>> More generally speaking, it can take time before having
>>
>> email sent before the ne d of the sentence ...
>>
>> More generally speaking, it can take time before having a cpufreq
>> driver whereas we want to run and test scheduler behavior of these
>> heterogenous platform
>>
> 
> I'm not familiar with this platform, but from what you are saying and
> what I could find online, it looks like full Linux support is not
> finished yet. Can we consider that as still in development? And if we
> can do that, maybe is fair enough that we use the sysfs interface to
> play with that platform until support is complete.
> 
> Do others have any opinion on this point?

IMHO, the solution should work for all of heterogeneous systems, (a) w/
cpufreq and driver, (b) w/ cpufreq and no driver loaded (yet) or (c) w/o
cpufreq.

That means that you can't put the benchmarking only into
cpufreq_register_driver() and rely on cpufreq policy topology.

Maybe you could do this for (b) and (c) inside an initcall and use
topology_core_cpumask() to figure out which cpu to profile?

This would then happen w/ the cpu frequency set by the fw.

But this then has to be synchronized somehow with the benchmarking
approach in cpufreq_register_driver().

[...]


From gabriele.paoloni at huawei.com  Tue Feb  9 07:56:26 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Tue, 9 Feb 2016 15:56:26 +0000
Subject: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host
 controller ECAM compliant
In-Reply-To: <3763449.y3Mfs92xrA@wuerfel>
References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
 <2599997.xBRrI3qHak@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECAD436@lhreml503-mbs>
 <3763449.y3Mfs92xrA@wuerfel>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECAF200@lhreml503-mbs>

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 09 February 2016 15:32
> To: linux-arm-kernel at lists.infradead.org
> Cc: Gabriele Paoloni; Lorenzo.Pieralisi at arm.com; jcm at redhat.com;
> tn at semihalf.com; linux-pci at vger.kernel.org; Linuxarm; xuwei (O); linux-
> kernel at vger.kernel.org; linux-acpi at vger.kernel.org; Wangzhou (B);
> liudongdong (C); Guohanjun (Hanjun Guo); bhelgaas at google.com;
> zhangjukuo; Liguozhu (Kenneth); qiujiang
> Subject: Re: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host
> controller ECAM compliant
> 
> On Monday 08 February 2016 17:21:27 Gabriele Paoloni wrote:
> > Hi Arnd
> >
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > Sent: 08 February 2016 16:30
> > > To: Gabriele Paoloni
> > > Cc: linux-arm-kernel at lists.infradead.org; Guohanjun (Hanjun Guo);
> > > Wangzhou (B); liudongdong (C); Linuxarm; qiujiang;
> bhelgaas at google.com;
> > > Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-
> pci at vger.kernel.org;
> > > linux-kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> > > jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth)
> > > Subject: Re: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe
> host
> > > controller ECAM compliant
> > >
> > > On Monday 08 February 2016 15:55:35 Gabriele Paoloni wrote:
> > > > > Doesn't this break backwards compatibility?
> > > >
> > > > Well Hip05/Hip06 SoCs are used into evaluation boards
> > > > For the Estuary project.
> > > >
> > > > https://github.com/hisilicon/estuary
> > > >
> > > > As this new driver gets upstream we'll merge this new driver into
> > > estuary
> > > > and release a new version of the firmware to support it.
> > >
> > > So what happens to folks running the old firmware then?
> >
> > So far we haven't released the PCIe nodes dtsi upstream and we think
> > we can handle the firmware upgrade for our current users either
> > by pointing them to the updated Estuary branch or by internal
> > channels
> 
> The dts files in the kernel tree are not really that important,
> the question is whether you are breaking things for real users.
> 
> If the upstream drivers work on some released firmware version,
> they should keep working.
> 
> > >
> > > > > I think you need to use a new compatible string in the firmware
> > > > > if you change the register layout, and then change the driver
> > > > > to support both the old and the new layout.
> > > >
> > > > You are right, for some reason in this patchset I missed the
> > > Documentation
> > > > update that I posted in the previous one, i.e.:
> > > >
> > > > --- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> > > > +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> > > > @@ -23,8 +23,8 @@ Optional properties:
> > > >  Hip05 Example (note that Hip06 is the same except compatible):
> > > >         pcie at 0xb0080000 {
> > > >                 compatible = "hisilicon,hip05-pcie", "snps,dw-
> pcie";
> > > > -               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000
> 0
> > > 0x2000>;
> > > > -               reg-names = "rc_dbi", "config";
> > > > +               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00100000
> 0
> > > 0x0f00000>;
> > > > +               reg-names = "rc_dbi", "ecam-cfg";
> > > >
> > >
> > > That is not the compatible string, it's an undocumented register
> set.
> >
> > Sorry, I misunderstood here, got it now :)
> >
> > > You can either define the a new compatible string that gives the
> > > "config"
> > > registers a new meaning, or you change the binding to allow two
> either
> > > a "config" or an "ecam-cfg" register set, and let the driver handle
> > > both.
> >
> > As per reply above I think that it would be quite easy for us to
> > let out current users update the BIOS so I don't think there is any
> > value in maintaining two version of the drivers one of which will
> > not be used.
> >
> > What do you think?
> 
> Requiring a BIOS update for a kernel update is really bad, even more
> so when the same BIOS update breaks older kernels.

Well I see your point.

To be honest I won't expect many users of the old BIOS version since
as I said we plan to send out the BIOS update to pretty much every user,
however on the other side it is not too much effort for me to add code
to support both ECAM/non ECAM, 
so ok I'll fix this in v3,

Many Thanks

Gab

> 
> 	Arnd


From stuart.yoder at nxp.com  Tue Feb  9 07:56:55 2016
From: stuart.yoder at nxp.com (Stuart Yoder)
Date: Tue, 9 Feb 2016 15:56:55 +0000
Subject: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
In-Reply-To: <56B9D62E.8080003@arm.com>
References: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
 <56B9D62E.8080003@arm.com>
Message-ID: <HE1PR04MB1641AF97F637BBCBB86BA4FE8DD60@HE1PR04MB1641.eurprd04.prod.outlook.com>


> -----Original Message-----
> From: Marc Zyngier [mailto:marc.zyngier at arm.com]
> Sent: Tuesday, February 09, 2016 6:06 AM
> To: Robin Murphy <robin.murphy at arm.com>; robh+dt at kernel.org; frowand.list at gmail.com;
> grant.likely at linaro.org; devicetree at vger.kernel.org
> Cc: mark.rutland at arm.com; david.daney at cavium.com; Stuart Yoder <stuart.yoder at nxp.com>;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> stable at vger.kernel.org
> Subject: Re: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
> 
> Hi Robin,
> 
> On 09/02/16 11:04, Robin Murphy wrote:
> > The existing msi-map code is fine for shifting the entire RID space
> > upwards, but attempting finer-grained remapping reveals a bug. It turns
> > out that we are mistakenly treating the msi-base part as an offset, not
> > as a new base to remap onto, so things get squiffy when rid-base is
> > nonzero. Fix this, and at the same time add a sanity check against
> > having msi-map-mask clash with a nonzero rid-base, as that's another
> > thing one can easily get wrong.
> >
> > CC: <stable at vger.kernel.org>
> > Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> 
> Looks like Stuart and you both found the same bug at the same time:
> https://lkml.org/lkml/2016/2/8/1066
> 
> but yours seem more correct to me (the rid_base masking in Stuart's
> version seems odd).
> 
> > ---
> >  drivers/of/irq.c | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> > index 7ee21ae..e7bfc17 100644
> > --- a/drivers/of/irq.c
> > +++ b/drivers/of/irq.c
> > @@ -635,6 +635,13 @@ static u32 __of_msi_map_rid(struct device *dev, struct
> device_node **np,
> >  		msi_base = be32_to_cpup(msi_map + 2);
> >  		rid_len = be32_to_cpup(msi_map + 3);
> >
> > +		if (rid_base & ~map_mask) {
> > +			dev_err(parent_dev,
> > +				"Invalid msi-map translation - msi-map-mask (0x%x) ignores rid-
> base (0x%x)\n",
> > +				map_mask, rid_base);
> > +			return rid_out;
> > +		}
> > +
> >  		msi_controller_node = of_find_node_by_phandle(phandle);
> >
> >  		matched = (masked_rid >= rid_base &&
> > @@ -654,7 +661,7 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node
> **np,
> >  	if (!matched)
> >  		return rid_out;
> >
> > -	rid_out = masked_rid + msi_base;
> > +	rid_out = masked_rid - rid_base + msi_base;
> >  	dev_dbg(dev,
> >  		"msi-map at: %s, using mask %08x, rid-base: %08x, msi-base: %08x, length:
> %08x, rid: %08x -> %08x\n",
> >  		dev_name(parent_dev), map_mask, rid_base, msi_base,
> >

This computation:  masked_rid - rid_base

...doesn't seem right to me.  We are taking a rid that
has been already masked and subtracting a rid base that has
not been masked.   I don't see how you can combine masked
and unmasked values in the same calculation.

Say I have this msi mapping:

                   msi-map = <0x0100 &its 0x11 0x1>;
                   msi-map-mask = <0xff>;

masked_rid = 0x0
rid_base = 0x0100
msi_base = 0x11

masked_rid - rid_base is 0x0 - 0x0100...which does not
give the msi index/offset we want.

Correct final answer should be 0x11.

In my patch I masked the rid_base so it can be subtracted
from the masked_rid.

masked_rid_base = 0x00

   msi_base + (masked_rid - masked_rid_base) = 0x11


Stuart



From tony at atomide.com  Tue Feb  9 07:58:11 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 9 Feb 2016 07:58:11 -0800
Subject: [PATCH 0/3] arm: dts: DRA7: Add IVA and DSPEVE thermal domain data
In-Reply-To: <56B95EF7.9080107@ti.com>
References: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>
 <20160208195704.GW19432@atomide.com> <56B95EF7.9080107@ti.com>
Message-ID: <20160209155811.GH19432@atomide.com>

* Keerthy <a0393675 at ti.com> [160208 19:38]:
> 
> 
> On Tuesday 09 February 2016 01:27 AM, Tony Lindgren wrote:
> >* Keerthy <j-keerthy at ti.com> [160208 01:19]:
> >>OMAP5 has 3 thermal zones cpu, core and multimedia.
> >>On the other hand DRA7 has 5 thermal zones cpu, gpu, core, dspeve
> >>and iva. Currently cpu, core and multimedia are being added via dt
> >>and the other 2 are getting added via kernel. Add the missing thermal
> >>domains in dt so as give the correct trip numbers, type and temperatures.
> >>
> >>Tested on DRA7-EVM.
> >
> >Are these critical fixes to have for v4.5-rc cycle or can they
> >wait for v4.6 merge window?
> 
> Driver configures some default thresholds that are a bit higher but there
> are some thresholds already for dspeve and iva too. So guess these can wait
> if its already too late.

OK let's rather wait then.

Regards,

Tony


From tony at atomide.com  Tue Feb  9 07:58:36 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 9 Feb 2016 07:58:36 -0800
Subject: [PATCH 0/3] omap: hwmod: add default reset handling support
In-Reply-To: <56B97572.6080100@ti.com>
References: <1454929941-23949-1-git-send-email-kishon@ti.com>
 <20160208204446.GC19432@atomide.com> <56B97572.6080100@ti.com>
Message-ID: <20160209155836.GI19432@atomide.com>

* Kishon Vijay Abraham I <kishon at ti.com> [160208 21:14]:
> Hi Tony,
> 
> On Tuesday 09 February 2016 02:14 AM, Tony Lindgren wrote:
> > Hi Kishon,
> > 
> > * Kishon Vijay Abraham I <kishon at ti.com> [160208 03:13]:
> >> Add a new hwmod flag to indicate custom reset handling and use it
> >> for devices that require custom reset handling (like dsp, ipu, iva).
> >>
> >> Tested PCIe on dra7-evm and dra72-evm.
> >> I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
> >> Or a way to test these cores to see if reset is not broken. Suman?
> >>
> >> I'll post this series once again after performing these tests.
> > 
> > Do we also still need to patch something in the pcie driver too
> > or can all that be left out now?
> 
> With this series changes in PCIe driver is not required at all.

OK good to hear.

Thanks,

Tony


From arnd at arndb.de  Tue Feb  9 08:00:48 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 17:00:48 +0100
Subject: [PATCH V2 09/12] dtb: amd: Add KCS device tree node
In-Reply-To: <56BA0A2B.5000705@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
 <4018438.bPuTyoUuqf@wuerfel> <56BA0A2B.5000705@amd.com>
Message-ID: <15181064.RzzsN4CWec@wuerfel>

On Tuesday 09 February 2016 09:47:55 Brijesh Singh wrote:
> > 
> > I see we don't have a binding file for this, can you add one please?
> >
> There is binding file ipmi.txt [1]. Am I missing something ?
>  
> [1] http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/ipmi.txt

Sorry, my mistake: I was looking for "ipmi_kcs", which is not in there.

> > 
> > Why the strange name for the interrupt?
> > 
> 
> Now I don't remember the doc but sometime back while implementing BMC on Seattle I saw that interrupt was labeled as "ipmi_kcs"
> hence used the same name in DT. But if you want to use different name then let me know the string and will update it.
> 
> Theoretically IPMI system interface supports the following interface and any of these interfaces can be used by
> A57 to communicate with BMC:
> 
> * Keyboard controller style (KCS)
> * System Management Interface (SMIC)
> * Block transfer (BT)
> * SMBus system interface (SSIF)
> 
> AMD Seattle platform supports "KCS".
> 

The important part for interrupt/reg/... names is that you must use exactly the
names that are listed in the binding. If there is no name in there, it's better
not to add the name property.

The other point is that "ipmi_kcs" is a name that is picked really badly, as it
uses a '_' character while DT properties by convention use '-' between names,
and the name of the IRQ is the same as the device itself, which is really
not a useful way to disambiguate multiple interrupts in the same device, if
someone ever adds another irq line.

	Arnd


From will.deacon at arm.com  Tue Feb  9 08:04:42 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Feb 2016 16:04:42 +0000
Subject: [PATCH] arm64: replace read_lock to rcu lock in call_step_hook
In-Reply-To: <20160209100758.69d9006f@gandalf.local.home>
References: <1454971764-30720-1-git-send-email-yang.shi@linaro.org>
 <20160209145426.GR22874@arm.com>
 <20160209100758.69d9006f@gandalf.local.home>
Message-ID: <20160209160442.GS22874@arm.com>

On Tue, Feb 09, 2016 at 10:07:58AM -0500, Steven Rostedt wrote:
> On Tue, 9 Feb 2016 14:54:26 +0000
> Will Deacon <will.deacon at arm.com> wrote:
> 
> 
> > Acked-by: Will Deacon <will.deacon at arm.com>
> 
> Will,

Hi Steve,

> The patch looks good to me. Do you want to take it through your tree?
> 
> It benefits mainline too as a rcu_read_lock() is more efficient than
> rwlocks. Although I will say this is a slow path anyway.

I was thinking that Catalin would queue it for 4.6 in the arm64 tree,
since that's probably easiest in case any unlikely conflicts crop up.

Will


From rostedt at goodmis.org  Tue Feb  9 08:08:15 2016
From: rostedt at goodmis.org (Steven Rostedt)
Date: Tue, 9 Feb 2016 11:08:15 -0500
Subject: [PATCH] arm64: replace read_lock to rcu lock in call_step_hook
In-Reply-To: <20160209160442.GS22874@arm.com>
References: <1454971764-30720-1-git-send-email-yang.shi@linaro.org>
 <20160209145426.GR22874@arm.com>
 <20160209100758.69d9006f@gandalf.local.home>
 <20160209160442.GS22874@arm.com>
Message-ID: <20160209110815.749c9e26@gandalf.local.home>

On Tue, 9 Feb 2016 16:04:42 +0000
Will Deacon <will.deacon at arm.com> wrote:
 
> > The patch looks good to me. Do you want to take it through your tree?
> > 
> > It benefits mainline too as a rcu_read_lock() is more efficient than
> > rwlocks. Although I will say this is a slow path anyway.  
> 
> I was thinking that Catalin would queue it for 4.6 in the arm64 tree,
> since that's probably easiest in case any unlikely conflicts crop up.

Oh, OK.

That's fine. I just didn't want you to think that the RT folks were
going to pull it in for mainline.

-- Steve


From mark.rutland at arm.com  Tue Feb  9 08:08:12 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 9 Feb 2016 16:08:12 +0000
Subject: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
In-Reply-To: <HE1PR04MB1641AF97F637BBCBB86BA4FE8DD60@HE1PR04MB1641.eurprd04.prod.outlook.com>
References: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
 <56B9D62E.8080003@arm.com>
 <HE1PR04MB1641AF97F637BBCBB86BA4FE8DD60@HE1PR04MB1641.eurprd04.prod.outlook.com>
Message-ID: <20160209160812.GC9332@leverpostej>

On Tue, Feb 09, 2016 at 03:56:55PM +0000, Stuart Yoder wrote:
> 
> > -----Original Message-----
> > From: Marc Zyngier [mailto:marc.zyngier at arm.com]
> > Sent: Tuesday, February 09, 2016 6:06 AM
> > To: Robin Murphy <robin.murphy at arm.com>; robh+dt at kernel.org; frowand.list at gmail.com;
> > grant.likely at linaro.org; devicetree at vger.kernel.org
> > Cc: mark.rutland at arm.com; david.daney at cavium.com; Stuart Yoder <stuart.yoder at nxp.com>;
> > linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> > stable at vger.kernel.org
> > Subject: Re: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
> > 
> > Hi Robin,
> > 
> > On 09/02/16 11:04, Robin Murphy wrote:
> > > The existing msi-map code is fine for shifting the entire RID space
> > > upwards, but attempting finer-grained remapping reveals a bug. It turns
> > > out that we are mistakenly treating the msi-base part as an offset, not
> > > as a new base to remap onto, so things get squiffy when rid-base is
> > > nonzero. Fix this, and at the same time add a sanity check against
> > > having msi-map-mask clash with a nonzero rid-base, as that's another
> > > thing one can easily get wrong.
> > >
> > > CC: <stable at vger.kernel.org>
> > > Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> > 
> > Looks like Stuart and you both found the same bug at the same time:
> > https://lkml.org/lkml/2016/2/8/1066
> > 
> > but yours seem more correct to me (the rid_base masking in Stuart's
> > version seems odd).
> > 
> > > ---
> > >  drivers/of/irq.c | 9 ++++++++-
> > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> > > index 7ee21ae..e7bfc17 100644
> > > --- a/drivers/of/irq.c
> > > +++ b/drivers/of/irq.c
> > > @@ -635,6 +635,13 @@ static u32 __of_msi_map_rid(struct device *dev, struct
> > device_node **np,
> > >  		msi_base = be32_to_cpup(msi_map + 2);
> > >  		rid_len = be32_to_cpup(msi_map + 3);
> > >
> > > +		if (rid_base & ~map_mask) {
> > > +			dev_err(parent_dev,
> > > +				"Invalid msi-map translation - msi-map-mask (0x%x) ignores rid-
> > base (0x%x)\n",
> > > +				map_mask, rid_base);
> > > +			return rid_out;
> > > +		}
> > > +
> > >  		msi_controller_node = of_find_node_by_phandle(phandle);
> > >
> > >  		matched = (masked_rid >= rid_base &&
> > > @@ -654,7 +661,7 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node
> > **np,
> > >  	if (!matched)
> > >  		return rid_out;
> > >
> > > -	rid_out = masked_rid + msi_base;
> > > +	rid_out = masked_rid - rid_base + msi_base;
> > >  	dev_dbg(dev,
> > >  		"msi-map at: %s, using mask %08x, rid-base: %08x, msi-base: %08x, length:
> > %08x, rid: %08x -> %08x\n",
> > >  		dev_name(parent_dev), map_mask, rid_base, msi_base,
> > >
> 
> This computation:  masked_rid - rid_base
> 
> ...doesn't seem right to me.  We are taking a rid that
> has been already masked and subtracting a rid base that has
> not been masked.

The binding only mentions that the input RID is masked, not the base, so
that seems correct to me.

> I don't see how you can combine masked and unmasked values in the same
> calculation.
> 
> Say I have this msi mapping:
> 
>                    msi-map = <0x0100 &its 0x11 0x1>;
>                    msi-map-mask = <0xff>;
> 

I'd say that this is an inconsistent set of properties, and it's
probably worth warning if we encounter this. There is no possible way
that rid-base can be encountered.

> masked_rid = 0x0
> rid_base = 0x0100
> msi_base = 0x11
> 
> masked_rid - rid_base is 0x0 - 0x0100...which does not
> give the msi index/offset we want.
> 
> Correct final answer should be 0x11.

You can unambiguously describe this with:

	msi-map = <0x00 &its 0x11 0x1>;
	msi-map-mask = <0xff>;

This is exactly the pattern we follow in example 2 in the binding
document.

> In my patch I masked the rid_base so it can be subtracted
> from the masked_rid.
> 
> masked_rid_base = 0x00
> 
>    msi_base + (masked_rid - masked_rid_base) = 0x11

As above, I think that this is an inconsistent DT, and we should
warn/fail in that case.

Thanks,
Mark.


From Chris.Brandt at renesas.com  Tue Feb  9 08:09:58 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Tue, 9 Feb 2016 16:09:58 +0000
Subject: [PATCH v4 3/3] kallsyms: remove --page-offset command line option
In-Reply-To: <1455030828-6416-4-git-send-email-ard.biesheuvel@linaro.org>
References: <1455030828-6416-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455030828-6416-4-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <HKXPR06MB056549C714A864B2D4F37DCA8AD60@HKXPR06MB0565.apcprd06.prod.outlook.com>

On 9 Feb 2016, Ard Biesheuvel wrote:

>diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
>index 02473b71643b..32c8d43590af 100644
>--- a/scripts/kallsyms.c
>+++ b/scripts/kallsyms.c
>@@ -63,7 +63,6 @@ static unsigned int table_size, table_cnt;
> static int all_symbols = 0;
> static int absolute_percpu = 0;
> static char symbol_prefix_char = '\0';
>-static unsigned long long kernel_start_addr = 0;
> static int base_relative = 0;



You removed kernel_start_addr, but you didn't remove all the instances of it in the file (you did remove them all in V2 though).

So, now I get:

  CC      scripts/mod/devicetable-offsets.s
../scripts/kallsyms.c: In function 'record_relative_base':
../scripts/kallsyms.c:740:6: error: 'kernel_start_addr' undeclared (first use in this function)
  if (kernel_start_addr > 0) {
      ^
../scripts/kallsyms.c:740:6: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [scripts/kallsyms] Error 1


Chris



From paul.burton at imgtec.com  Tue Feb  9 08:11:34 2016
From: paul.burton at imgtec.com (Paul Burton)
Date: Tue, 9 Feb 2016 08:11:34 -0800
Subject: [PATCH V3 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge
 driver to work on both  Zynq and Microblaze
In-Reply-To: <1455014518-8708-4-git-send-email-bharatku@xilinx.com>
References: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
 <1455014518-8708-4-git-send-email-bharatku@xilinx.com>
Message-ID: <20160209161134.GA24244@NP-P-BURTON>

On Tue, Feb 09, 2016 at 04:11:56PM +0530, Bharat Kumar Gogada wrote:
> Modifying Xilinx AXI PCIe Host Bridge Soft IP driver to work on both
> Zynq and Microblaze Architectures.
> With these modifications drivers/pci/host/pcie-xilinx.c, will
> work on both Zynq and Microblaze Architectures.
> 
> Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
> ---
> Changes:
> Removed unneccessary architecture dependent number of MSI's.
> Added #ifdef to pci_fixup_irqs which is ARM specific API.

Hi Bharat,

Why do you say pci_fixup_irqs is ARM-specific? It's declared in
include/linux/pci.h, defined in drivers/pci/setup-irq.c & used by
multiple architectures (alpha, arm, m68k, mips, sh, sparc, tile,
unicore32 from a quick grep).

Will you not break INTX-style interrupts by removing this?

Thanks,
    Paul

> ---
>  drivers/pci/host/pcie-xilinx.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
> index 13fec35..6cbce34 100644
> --- a/drivers/pci/host/pcie-xilinx.c
> +++ b/drivers/pci/host/pcie-xilinx.c
> @@ -704,7 +704,9 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
>  #endif
>  	pci_scan_child_bus(bus);
>  	pci_assign_unassigned_bus_resources(bus);
> +#ifdef CONFIG_ARM
>  	pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
> +#endif
>  	pci_bus_add_devices(bus);
>  	platform_set_drvdata(pdev, port);
>  
> -- 
> 2.1.1
> 


From brijesh.singh at amd.com  Tue Feb  9 08:11:38 2016
From: brijesh.singh at amd.com (Brijesh Singh)
Date: Tue, 9 Feb 2016 10:11:38 -0600
Subject: [PATCH V2 09/12] dtb: amd: Add KCS device tree node
In-Reply-To: <15181064.RzzsN4CWec@wuerfel>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
 <4018438.bPuTyoUuqf@wuerfel> <56BA0A2B.5000705@amd.com>
 <15181064.RzzsN4CWec@wuerfel>
Message-ID: <56BA0FBA.1010202@amd.com>

Hi,

On 02/09/2016 10:00 AM, Arnd Bergmann wrote:
> 
> The important part for interrupt/reg/... names is that you must use exactly the
> names that are listed in the binding. If there is no name in there, it's better
> not to add the name property.
> 
> The other point is that "ipmi_kcs" is a name that is picked really badly, as it
> uses a '_' character while DT properties by convention use '-' between names,
> and the name of the IRQ is the same as the device itself, which is really
> not a useful way to disambiguate multiple interrupts in the same device, if
> someone ever adds another irq line.
> 

Sure we will drop the name field. Thanks.

> 	Arnd
> 


From tony at atomide.com  Tue Feb  9 08:17:00 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 9 Feb 2016 08:17:00 -0800
Subject: [PATCH] ARM: RX51: Set system_rev from ATAGS
In-Reply-To: <20160208211022.GM30075@pali>
References: <3663322.UyrB2OmX6o@wuerfel>
 <1454696102-2214-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
 <20160208211022.GM30075@pali>
Message-ID: <20160209161659.GJ19432@atomide.com>

* Pali Roh?r <pali.rohar at gmail.com> [160208 13:11]:
>
> Tony, if you are going to take this patch, I would suggest to rename
> function name rx51_system_rev to rx51_set_system_rev as it says what
> function do (set system rev :-)).

Ivaylo can change it when reposting as the patch description is
missing.

Regards,

Tony


From ard.biesheuvel at linaro.org  Tue Feb  9 08:17:08 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 9 Feb 2016 17:17:08 +0100
Subject: [PATCH v4 3/3] kallsyms: remove --page-offset command line option
In-Reply-To: <HKXPR06MB056549C714A864B2D4F37DCA8AD60@HKXPR06MB0565.apcprd06.prod.outlook.com>
References: <1455030828-6416-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455030828-6416-4-git-send-email-ard.biesheuvel@linaro.org>
 <HKXPR06MB056549C714A864B2D4F37DCA8AD60@HKXPR06MB0565.apcprd06.prod.outlook.com>
Message-ID: <CAKv+Gu-rdP7-=Z2SO2jRS_dHzB8UDpZ7-RowN_400d32Qvxmqg@mail.gmail.com>

On 9 February 2016 at 17:09, Chris Brandt <Chris.Brandt at renesas.com> wrote:
> On 9 Feb 2016, Ard Biesheuvel wrote:
>
>>diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
>>index 02473b71643b..32c8d43590af 100644
>>--- a/scripts/kallsyms.c
>>+++ b/scripts/kallsyms.c
>>@@ -63,7 +63,6 @@ static unsigned int table_size, table_cnt;
>> static int all_symbols = 0;
>> static int absolute_percpu = 0;
>> static char symbol_prefix_char = '\0';
>>-static unsigned long long kernel_start_addr = 0;
>> static int base_relative = 0;
>
>
>
> You removed kernel_start_addr, but you didn't remove all the instances of it in the file (you did remove them all in V2 though).
>
> So, now I get:
>
>   CC      scripts/mod/devicetable-offsets.s
> ../scripts/kallsyms.c: In function 'record_relative_base':
> ../scripts/kallsyms.c:740:6: error: 'kernel_start_addr' undeclared (first use in this function)
>   if (kernel_start_addr > 0) {
>       ^
> ../scripts/kallsyms.c:740:6: note: each undeclared identifier is reported only once for each function it appears in
> make[2]: *** [scripts/kallsyms] Error 1
>

That is because this patch

http://ozlabs.org/~akpm/mmots/broken-out/kallsyms-add-support-for-relative-offsets-in-kallsyms-address-table-v5.patch

is also in flight, via akpm's tree, and is expected to hit -next
tomorrow. That patch removes this reference (or alternatively, will
not introduce it anymore if akpm decides to fold it into
http://ozlabs.org/~akpm/mmots/broken-out/kallsyms-add-support-for-relative-offsets-in-kallsyms-address-table.patch
before submitting it)

Going forward, it probably makes sense to only submit #1 of this
series for v4.6, and queue the remaining two after the merge window.

Thanks for testing btw,
Ard.


From robin.murphy at arm.com  Tue Feb  9 08:17:33 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue, 9 Feb 2016 16:17:33 +0000
Subject: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
In-Reply-To: <20160209160812.GC9332@leverpostej>
References: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
 <56B9D62E.8080003@arm.com>
 <HE1PR04MB1641AF97F637BBCBB86BA4FE8DD60@HE1PR04MB1641.eurprd04.prod.outlook.com>
 <20160209160812.GC9332@leverpostej>
Message-ID: <56BA111D.9050807@arm.com>

On 09/02/16 16:08, Mark Rutland wrote:
[...]

>>>> having msi-map-mask clash with a nonzero rid-base, as that's another
>>>> thing one can easily get wrong.

[...]

>>>> +		if (rid_base & ~map_mask) {
>>>> +			dev_err(parent_dev,
>>>> +				"Invalid msi-map translation - msi-map-mask (0x%x) ignores rid-
>>> base (0x%x)\n",
>>>> +				map_mask, rid_base);
>>>> +			return rid_out;
>>>> +		}

[...]

>>                     msi-map = <0x0100 &its 0x11 0x1>;
>>                     msi-map-mask = <0xff>;
>>
>
> I'd say that this is an inconsistent set of properties, and it's
> probably worth warning if we encounter this. There is no possible way
> that rid-base can be encountered.

Indeed ;)

Robin.

> Thanks,
> Mark.
>



From catalin.marinas at arm.com  Tue Feb  9 08:24:27 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 9 Feb 2016 16:24:27 +0000
Subject: [PATCH] arm64: replace read_lock to rcu lock in call_step_hook
In-Reply-To: <20160209160442.GS22874@arm.com>
References: <1454971764-30720-1-git-send-email-yang.shi@linaro.org>
 <20160209145426.GR22874@arm.com>
 <20160209100758.69d9006f@gandalf.local.home>
 <20160209160442.GS22874@arm.com>
Message-ID: <20160209162427.GH16122@e104818-lin.cambridge.arm.com>

On Tue, Feb 09, 2016 at 04:04:42PM +0000, Will Deacon wrote:
> On Tue, Feb 09, 2016 at 10:07:58AM -0500, Steven Rostedt wrote:
> > On Tue, 9 Feb 2016 14:54:26 +0000
> > Will Deacon <will.deacon at arm.com> wrote:
> > 
> > 
> > > Acked-by: Will Deacon <will.deacon at arm.com>
> 
> > The patch looks good to me. Do you want to take it through your tree?
> > 
> > It benefits mainline too as a rcu_read_lock() is more efficient than
> > rwlocks. Although I will say this is a slow path anyway.
> 
> I was thinking that Catalin would queue it for 4.6 in the arm64 tree,
> since that's probably easiest in case any unlikely conflicts crop up.

Queued.

-- 
Catalin


From helgaas at kernel.org  Tue Feb  9 08:26:28 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Tue, 9 Feb 2016 10:26:28 -0600
Subject: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for
 ThunderX-pass1 on-chip devices
In-Reply-To: <12842339.z2KnaZPlyO@wuerfel>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
 <56B919A5.5090000@caviumnetworks.com>
 <20160208232430.GA1353@localhost> <12842339.z2KnaZPlyO@wuerfel>
Message-ID: <20160209162628.GA20171@localhost>

On Tue, Feb 09, 2016 at 10:25:33AM +0100, Arnd Bergmann wrote:
> On Monday 08 February 2016 17:24:30 Bjorn Helgaas wrote:
> > > >
> > > >I assume your system conforms to expectations like these; I'm just
> > > >pointing them out because you mentioned buses with multiple devices on
> > > >them, which is definitely something one doesn't expect in PCIe.
> > > 
> > > The topology we have is currently working with the kernel's core PCI
> > > code.  I don't really want to get into discussing what the
> > > definition of PCIe is.  We have multiple devices (more than 32) on a
> > > single bus, and they have PCI Express and ARI Capabilities.  Is that
> > > PCIe?  I don't know.
> > 
> > I don't need to know the details of your topology.  As long as it
> > conforms to the PCIe spec, it should be fine.  If it *doesn't* conform
> > to the spec, but things currently seem to work, that's less fine,
> > because a future Linux change is liable to break something for you.
> > 
> > I was a little concerned about your statement that "there are multiple
> > devices residing on each bus, so from that point of view it cannot be
> > PCIe."  That made it sound like you're doing something outside the
> > spec.  If you're just using regular multi-function devices or ARI,
> > then I don't see any issue (or any reason to say it can't be PCIe).
> 
> It doesn't conform to the PCIe port spec, because there are no external
> ports but just integrated devices in the host bridge. 

Is there a spec section you have in mind?  Based on sec 1.3.1, I don't
think there's a requirement to have PCI Express Ports (is that what
you mean by "external ports"?)

Root Complex Integrated Endpoints (sec 1.3.2.3) are clearly supported
and they would not be behind a Root Port.  If you're using those, I
hope they're correctly identified via the PCIe capability Device/Port
Type (sec 7.8.2) because we rely on that type to figure out whether
the link-related registers are implemented.

The spec does include rules related to peer-to-peer transactions, MPS,
ASPM, error reporting, etc., and Linux relies on those, so I think it
would be important to get those right.

> For this special
> case, I don't think it matters at all from the point of view of the DT
> binding whether we call the node name "pci" or "pcie".

And the PCI core doesn't even know the node name, it doesn't matter
there either.

Bjorn


From arnd at arndb.de  Tue Feb  9 08:27:05 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 17:27:05 +0100
Subject: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06
 controllers driver to preapare for ACPI
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1ECAD249@lhreml503-mbs>
References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
 <3113837.YSNyDAf4HQ@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECAD249@lhreml503-mbs>
Message-ID: <5968234.D2a3VCM72k@wuerfel>

On Monday 08 February 2016 16:51:19 Gabriele Paoloni wrote:
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > On Monday 08 February 2016 16:06:54 Gabriele Paoloni wrote:
> > > > On Monday 08 February 2016 12:41:02 Gabriele Paoloni wrote:
> > int
> > > > size,
> > > > > +                         u32 *val)
> > > > > +{
> > > > > +   u32 reg;
> > > > > +   u32 reg_val;
> > > > > +   void *walker = &reg_val;
> > > > > +
> > > > > +   walker += (where & 0x3);
> > > > > +   reg = where & ~0x3;
> > > > > +   reg_val = readl(reg_base + reg);
> > > > > +
> > > > > +   if (size == 1)
> > > > > +           *val = *(u8 __force *) walker;
> > > > > +   else if (size == 2)
> > > > > +           *val = *(u16 __force *) walker;
> > > > > +   else if (size == 4)
> > > > > +           *val = reg_val;
> > > > > +   else
> > > > > +           return PCIBIOS_BAD_REGISTER_NUMBER;
> > > > > +
> > > > > +   return PCIBIOS_SUCCESSFUL;
> > > > > +}
> > > >
> > > > Isn't this the same hack that Qualcomm are using?
> > >
> > > As far as I can see Qualcomm defines its own config access
> > > mechanism only for RC config read and also it seems they're
> > > having problems with reporting the device class...
> > >
> > > https://github.com/torvalds/linux/blob/master/drivers/pci/host/pcie-
> > qcom.c#L474
> > >
> > > Our problem is that our HW can only perform 32b rd/wr accesses
> > > So we can't use readw/readb/writew/writeb...
> > >
> > >
> > 
> > Sorry, my mistake, I meant Cavium not Qualcomm.
> > See https://lkml.org/lkml/2016/2/5/689 for the patches.
> 
> Well, looking at it Cavium seems quite different, 
> 
> On read they need to trigger the retrieval of the
> config space info writing to the lower 32b of a 64b register,
> then they need to read data back on the upper 64b of the
> same register and adjust the content to remove the garbage...
> 
> We just use 32b accesses and adjust grab the appropriate
> bytes depending on the read/write sizes...

Hmm, I must have misremembered that too then, let me try once more ;-)

The above appears to reimplement pci_generic_config_read32(). Can you
just use that instead?

	Arnd


From arnd at arndb.de  Tue Feb  9 08:31:26 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 09 Feb 2016 17:31:26 +0100
Subject: [PATCH v5 3/3] pci,
 pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices
In-Reply-To: <20160209162628.GA20171@localhost>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
 <12842339.z2KnaZPlyO@wuerfel> <20160209162628.GA20171@localhost>
Message-ID: <4260938.2z2RNjENMM@wuerfel>

On Tuesday 09 February 2016 10:26:28 Bjorn Helgaas wrote:
> On Tue, Feb 09, 2016 at 10:25:33AM +0100, Arnd Bergmann wrote:
> > On Monday 08 February 2016 17:24:30 Bjorn Helgaas wrote:
> > > > >
> > > > >I assume your system conforms to expectations like these; I'm just
> > > > >pointing them out because you mentioned buses with multiple devices on
> > > > >them, which is definitely something one doesn't expect in PCIe.
> > > > 
> > > > The topology we have is currently working with the kernel's core PCI
> > > > code.  I don't really want to get into discussing what the
> > > > definition of PCIe is.  We have multiple devices (more than 32) on a
> > > > single bus, and they have PCI Express and ARI Capabilities.  Is that
> > > > PCIe?  I don't know.
> > > 
> > > I don't need to know the details of your topology.  As long as it
> > > conforms to the PCIe spec, it should be fine.  If it *doesn't* conform
> > > to the spec, but things currently seem to work, that's less fine,
> > > because a future Linux change is liable to break something for you.
> > > 
> > > I was a little concerned about your statement that "there are multiple
> > > devices residing on each bus, so from that point of view it cannot be
> > > PCIe."  That made it sound like you're doing something outside the
> > > spec.  If you're just using regular multi-function devices or ARI,
> > > then I don't see any issue (or any reason to say it can't be PCIe).
> > 
> > It doesn't conform to the PCIe port spec, because there are no external
> > ports but just integrated devices in the host bridge. 
> 
> Is there a spec section you have in mind?  Based on sec 1.3.1, I don't
> think there's a requirement to have PCI Express Ports (is that what
> you mean by "external ports"?)

No, I was just assuming that ports are specified in their own document,
which would not be followed here if there are none. There is nothing in
here that leads me to believe that the hardware is actually noncompliant
with any relevant standard.

> Root Complex Integrated Endpoints (sec 1.3.2.3) are clearly supported
> and they would not be behind a Root Port.  If you're using those, I
> hope they're correctly identified via the PCIe capability Device/Port
> Type (sec 7.8.2) because we rely on that type to figure out whether
> the link-related registers are implemented.
> 
> The spec does include rules related to peer-to-peer transactions, MPS,
> ASPM, error reporting, etc., and Linux relies on those, so I think it
> would be important to get those right.

David can probably explain more if the registers are compliant with
those parts of the spec.

	Arnd


From mathieu.poirier at linaro.org  Tue Feb  9 08:40:40 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 9 Feb 2016 09:40:40 -0700
Subject: [PATCH v5 1/3] mailbox: Add support for APM X-Gene platform
 mailbox driver
In-Reply-To: <90cb13a0b4d3817c18c11c183128c08d6458bf8d.1454967957.git.dhdang@apm.com>
References: <CABb+yY1cE152ZdfK_aeB8ufG=WfoUVB6BN8kXPphYgMBnpH-GA@mail.gmail.com>
 <cover.1454967957.git.dhdang@apm.com>
 <90cb13a0b4d3817c18c11c183128c08d6458bf8d.1454967957.git.dhdang@apm.com>
Message-ID: <CANLsYkwp4vJN+LcNm=7Xm=RppFnsPEXSAARS7=g6CZSsk5M5qw@mail.gmail.com>

On 8 February 2016 at 15:04, Duc Dang <dhdang at apm.com> wrote:
> X-Gene mailbox controller provides 8 mailbox channels, with
> each channel has a dedicated interrupt line.
>
> Signed-off-by: Feng Kan <fkan at apm.com>
> Signed-off-by: Duc Dang <dhdang at apm.com>
> ---
> Changes since v4:
>         - Rebase over v4.5-rc1
>         - Fix section mistmatch warning by removing
>         __init in slimpro_mbox_probe declaration
>         - Correctly print channel number when
>         there is no IRQ for that channel
>
> Changes since v3:
>         - Rebase over v4.4
>         - Remove 'id' in slimpro_mbox_chan structure
>         - Remove small functions that are only called once
>         and fold them into the other callers
>         - Remove void* pointer type cast
>         - Relax the number of mailbox IRQs condition
>         - Use subsys_initcall to guarantee mailbox driver
>         will be registered before any other dependent driver
>         is loaded.
>
>  drivers/mailbox/Kconfig                 |   9 ++
>  drivers/mailbox/Makefile                |   2 +
>  drivers/mailbox/mailbox-xgene-slimpro.c | 264 ++++++++++++++++++++++++++++++++
>  3 files changed, 275 insertions(+)
>  create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c
>
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index 546d05f..678e434 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -85,4 +85,13 @@ config MAILBOX_TEST
>           Test client to help with testing new Controller driver
>           implementations.
>
> +config XGENE_SLIMPRO_MBOX
> +       tristate "APM SoC X-Gene SLIMpro Mailbox Controller"
> +       depends on ARCH_XGENE
> +       help
> +         An implementation of the APM X-Gene Interprocessor Communication
> +         Mailbox (IPCM) between the ARM 64-bit cores and SLIMpro controller.
> +         It is used to send short messages between ARM64-bit cores and
> +         the SLIMpro Management Engine, primarily for PM. Say Y here if you
> +         want to use the APM X-Gene SLIMpro IPCM support.
>  endif
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index 92435ef..b602ef8 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -17,3 +17,5 @@ obj-$(CONFIG_ALTERA_MBOX)     += mailbox-altera.o
>  obj-$(CONFIG_BCM2835_MBOX)     += bcm2835-mailbox.o
>
>  obj-$(CONFIG_STI_MBOX)         += mailbox-sti.o
> +
> +obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
> diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c b/drivers/mailbox/mailbox-xgene-slimpro.c
> new file mode 100644
> index 0000000..0ea1eb8
> --- /dev/null
> +++ b/drivers/mailbox/mailbox-xgene-slimpro.c
> @@ -0,0 +1,264 @@
> +/*
> + * APM X-Gene SLIMpro MailBox Driver
> + *
> + * Copyright (c) 2015, Applied Micro Circuits Corporation
> + * Author: Feng Kan fkan at apm.com
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * 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/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/mailbox_controller.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/spinlock.h>
> +
> +#define MBOX_CON_NAME                  "slimpro-mbox"
> +#define MBOX_REG_SET_OFFSET            0x1000
> +#define MBOX_CNT                       8
> +#define MBOX_STATUS_AVAIL_MASK         BIT(16)
> +#define MBOX_STATUS_ACK_MASK           BIT(0)
> +
> +/* Configuration and Status Registers */
> +#define REG_DB_IN              0x00
> +#define REG_DB_DIN0            0x04
> +#define REG_DB_DIN1            0x08
> +#define REG_DB_OUT             0x10
> +#define REG_DB_DOUT0           0x14
> +#define REG_DB_DOUT1           0x18
> +#define REG_DB_STAT            0x20
> +#define REG_DB_STATMASK                0x24
> +
> +struct slimpro_mbox_chan {
> +       struct device *dev;
> +       struct mbox_chan *chan;
> +       void __iomem *reg;
> +       int irq;
> +       u32 rx_msg[3];
> +};
> +
> +struct slimpro_mbox {
> +       struct mbox_controller mb_ctrl;
> +       struct slimpro_mbox_chan mc[MBOX_CNT];
> +       struct mbox_chan chans[MBOX_CNT];
> +};

The above two structure declaration could use kernel style documentation.

> +
> +static void mb_chan_send_msg(struct slimpro_mbox_chan *mb_chan, u32 *msg)
> +{
> +       writel(msg[1], mb_chan->reg + REG_DB_DOUT0);
> +       writel(msg[2], mb_chan->reg + REG_DB_DOUT1);
> +       writel(msg[0], mb_chan->reg + REG_DB_OUT);
> +}
> +
> +static void mb_chan_recv_msg(struct slimpro_mbox_chan *mb_chan)
> +{
> +       mb_chan->rx_msg[1] = readl(mb_chan->reg + REG_DB_DIN0);
> +       mb_chan->rx_msg[2] = readl(mb_chan->reg + REG_DB_DIN1);
> +       mb_chan->rx_msg[0] = readl(mb_chan->reg + REG_DB_IN);
> +}

Is there a requirement that operations in the above two functions be
ordered?  If not significant gains could be achieved by using
writel/readl_relaxed().  Same comment for the rest of this driver.

Thanks,
Mathieu

> +
> +static int mb_chan_status_ack(struct slimpro_mbox_chan *mb_chan)
> +{
> +       u32 val = readl(mb_chan->reg + REG_DB_STAT);
> +
> +       if (val & MBOX_STATUS_ACK_MASK) {
> +               writel(MBOX_STATUS_ACK_MASK, mb_chan->reg + REG_DB_STAT);
> +               return 1;
> +       }
> +       return 0;
> +}
> +
> +static int mb_chan_status_avail(struct slimpro_mbox_chan *mb_chan)
> +{
> +       u32 val = readl(mb_chan->reg + REG_DB_STAT);
> +
> +       if (val & MBOX_STATUS_AVAIL_MASK) {
> +               mb_chan_recv_msg(mb_chan);
> +               writel(MBOX_STATUS_AVAIL_MASK, mb_chan->reg + REG_DB_STAT);
> +               return 1;
> +       }
> +       return 0;
> +}
> +
> +static irqreturn_t slimpro_mbox_irq(int irq, void *id)
> +{
> +       struct slimpro_mbox_chan *mb_chan = id;
> +
> +       if (mb_chan_status_ack(mb_chan))
> +               mbox_chan_txdone(mb_chan->chan, 0);
> +
> +       if (mb_chan_status_avail(mb_chan))
> +               mbox_chan_received_data(mb_chan->chan, mb_chan->rx_msg);
> +
> +       return IRQ_HANDLED;
> +}
> +
> +static int slimpro_mbox_send_data(struct mbox_chan *chan, void *msg)
> +{
> +       struct slimpro_mbox_chan *mb_chan = chan->con_priv;
> +
> +       mb_chan_send_msg(mb_chan, msg);
> +       return 0;
> +}
> +
> +static int slimpro_mbox_startup(struct mbox_chan *chan)
> +{
> +       struct slimpro_mbox_chan *mb_chan = chan->con_priv;
> +       int rc;
> +       u32 val;
> +
> +       rc = devm_request_irq(mb_chan->dev, mb_chan->irq, slimpro_mbox_irq, 0,
> +                             MBOX_CON_NAME, mb_chan);
> +       if (unlikely(rc)) {
> +               dev_err(mb_chan->dev, "failed to register mailbox interrupt %d\n",
> +                       mb_chan->irq);
> +               return rc;
> +       }
> +
> +       /* Enable HW interrupt */
> +       writel(MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK,
> +              mb_chan->reg + REG_DB_STAT);
> +       /* Unmask doorbell status interrupt */
> +       val = readl(mb_chan->reg + REG_DB_STATMASK);
> +       val &= ~(MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK);
> +       writel(val, mb_chan->reg + REG_DB_STATMASK);
> +
> +       return 0;
> +}
> +
> +static void slimpro_mbox_shutdown(struct mbox_chan *chan)
> +{
> +       struct slimpro_mbox_chan *mb_chan = chan->con_priv;
> +       u32 val;
> +
> +       /* Mask doorbell status interrupt */
> +       val = readl(mb_chan->reg + REG_DB_STATMASK);
> +       val |= (MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK);
> +       writel(val, mb_chan->reg + REG_DB_STATMASK);
> +
> +       devm_free_irq(mb_chan->dev, mb_chan->irq, mb_chan);
> +}
> +
> +static struct mbox_chan_ops slimpro_mbox_ops = {
> +       .send_data = slimpro_mbox_send_data,
> +       .startup = slimpro_mbox_startup,
> +       .shutdown = slimpro_mbox_shutdown,
> +};
> +
> +static int slimpro_mbox_probe(struct platform_device *pdev)
> +{
> +       struct slimpro_mbox *ctx;
> +       struct resource *regs;
> +       void __iomem *mb_base;
> +       int rc;
> +       int i;
> +
> +       ctx = devm_kzalloc(&pdev->dev, sizeof(struct slimpro_mbox), GFP_KERNEL);
> +       if (IS_ERR(ctx))
> +               return PTR_ERR(ctx);
> +
> +       platform_set_drvdata(pdev, ctx);
> +
> +       regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       mb_base = devm_ioremap(&pdev->dev, regs->start, resource_size(regs));
> +       if (IS_ERR(mb_base))
> +               return PTR_ERR(mb_base);
> +
> +       /* Setup mailbox links */
> +       for (i = 0; i < MBOX_CNT; i++) {
> +               ctx->mc[i].irq = platform_get_irq(pdev, i);
> +               if (ctx->mc[i].irq < 0) {
> +                       if (i == 0) {
> +                               dev_err(&pdev->dev, "no available IRQ\n");
> +                               return -EINVAL;
> +                       }
> +                       dev_info(&pdev->dev, "no IRQ for channel %d\n", i);
> +                       break;
> +               }
> +
> +               ctx->mc[i].dev = &pdev->dev;
> +               ctx->mc[i].reg = mb_base + i * MBOX_REG_SET_OFFSET;
> +               ctx->mc[i].chan = &ctx->chans[i];
> +               ctx->chans[i].con_priv = &ctx->mc[i];
> +       }
> +
> +       /* Setup mailbox controller */
> +       ctx->mb_ctrl.dev = &pdev->dev;
> +       ctx->mb_ctrl.chans = ctx->chans;
> +       ctx->mb_ctrl.txdone_irq = true;
> +       ctx->mb_ctrl.ops = &slimpro_mbox_ops;
> +       ctx->mb_ctrl.num_chans = i;
> +
> +       rc = mbox_controller_register(&ctx->mb_ctrl);
> +       if (rc) {
> +               dev_err(&pdev->dev,
> +                       "APM X-Gene SLIMpro MailBox register failed:%d\n", rc);
> +               return rc;
> +       }
> +
> +       dev_info(&pdev->dev, "APM X-Gene SLIMpro MailBox registered\n");
> +       return 0;
> +}
> +
> +static int slimpro_mbox_remove(struct platform_device *pdev)
> +{
> +       struct slimpro_mbox *smb = platform_get_drvdata(pdev);
> +
> +       mbox_controller_unregister(&smb->mb_ctrl);
> +       return 0;
> +}
> +
> +static const struct of_device_id slimpro_of_match[] = {
> +       {.compatible = "apm,xgene-slimpro-mbox" },
> +       { },
> +};
> +MODULE_DEVICE_TABLE(of, slimpro_of_match);
> +
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id slimpro_acpi_ids[] = {
> +       {"APMC0D01", 0},
> +       {}
> +};
> +MODULE_DEVICE_TABLE(acpi, slimpro_acpi_ids);
> +#endif
> +
> +static struct platform_driver slimpro_mbox_driver = {
> +       .probe  = slimpro_mbox_probe,
> +       .remove = slimpro_mbox_remove,
> +       .driver = {
> +               .name = "xgene-slimpro-mbox",
> +               .of_match_table = of_match_ptr(slimpro_of_match),
> +               .acpi_match_table = ACPI_PTR(slimpro_acpi_ids)
> +       },
> +};
> +
> +static int __init slimpro_mbox_init(void)
> +{
> +       return platform_driver_register(&slimpro_mbox_driver);
> +}
> +
> +static void __exit slimpro_mbox_exit(void)
> +{
> +       platform_driver_unregister(&slimpro_mbox_driver);
> +}
> +
> +subsys_initcall(slimpro_mbox_init);
> +module_exit(slimpro_mbox_exit);
> +
> +MODULE_DESCRIPTION("APM X-Gene SLIMpro Mailbox Driver");
> +MODULE_LICENSE("GPL");
> --
> 1.9.1
>


From gabriele.paoloni at huawei.com  Tue Feb  9 08:52:38 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Tue, 9 Feb 2016 16:52:38 +0000
Subject: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06
 controllers driver to preapare for ACPI
In-Reply-To: <5968234.D2a3VCM72k@wuerfel>
References: <1454935264-6076-1-git-send-email-gabriele.paoloni@huawei.com>
 <3113837.YSNyDAf4HQ@wuerfel>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECAD249@lhreml503-mbs>
 <5968234.D2a3VCM72k@wuerfel>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECAF48D@lhreml503-mbs>

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 09 February 2016 16:27
> To: Gabriele Paoloni
> Cc: linux-arm-kernel at lists.infradead.org; Guohanjun (Hanjun Guo);
> Wangzhou (B); liudongdong (C); Linuxarm; qiujiang; bhelgaas at google.com;
> Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-pci at vger.kernel.org;
> linux-kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth)
> Subject: Re: [RFC PATCH v2 1/3] PCI: hisi: re-architect Hip05/Hip06
> controllers driver to preapare for ACPI
> 
> On Monday 08 February 2016 16:51:19 Gabriele Paoloni wrote:
> > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > On Monday 08 February 2016 16:06:54 Gabriele Paoloni wrote:
> > > > > On Monday 08 February 2016 12:41:02 Gabriele Paoloni wrote:
> > > int
> > > > > size,
> > > > > > +                         u32 *val)
> > > > > > +{
> > > > > > +   u32 reg;
> > > > > > +   u32 reg_val;
> > > > > > +   void *walker = &reg_val;
> > > > > > +
> > > > > > +   walker += (where & 0x3);
> > > > > > +   reg = where & ~0x3;
> > > > > > +   reg_val = readl(reg_base + reg);
> > > > > > +
> > > > > > +   if (size == 1)
> > > > > > +           *val = *(u8 __force *) walker;
> > > > > > +   else if (size == 2)
> > > > > > +           *val = *(u16 __force *) walker;
> > > > > > +   else if (size == 4)
> > > > > > +           *val = reg_val;
> > > > > > +   else
> > > > > > +           return PCIBIOS_BAD_REGISTER_NUMBER;
> > > > > > +
> > > > > > +   return PCIBIOS_SUCCESSFUL;
> > > > > > +}
> > > > >
> > > > > Isn't this the same hack that Qualcomm are using?
> > > >
> > > > As far as I can see Qualcomm defines its own config access
> > > > mechanism only for RC config read and also it seems they're
> > > > having problems with reporting the device class...
> > > >
> > > >
> https://github.com/torvalds/linux/blob/master/drivers/pci/host/pcie-
> > > qcom.c#L474
> > > >
> > > > Our problem is that our HW can only perform 32b rd/wr accesses
> > > > So we can't use readw/readb/writew/writeb...
> > > >
> > > >
> > >
> > > Sorry, my mistake, I meant Cavium not Qualcomm.
> > > See https://lkml.org/lkml/2016/2/5/689 for the patches.
> >
> > Well, looking at it Cavium seems quite different,
> >
> > On read they need to trigger the retrieval of the
> > config space info writing to the lower 32b of a 64b register,
> > then they need to read data back on the upper 64b of the
> > same register and adjust the content to remove the garbage...
> >
> > We just use 32b accesses and adjust grab the appropriate
> > bytes depending on the read/write sizes...
> 
> Hmm, I must have misremembered that too then, let me try once more ;-)
> 
> The above appears to reimplement pci_generic_config_read32(). Can you
> just use that instead?

Nope I don't think so,

When we read the root complex config space we need to use a configuration
address space that is different from the one used to map the rest of the
hierarchy; I think this is something to do with Designware itself. It
is clear if you look at

http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L657

Here you can see that in calling "dw_pcie_wr_own_conf" Designware does not
pass "bus" and "devfn" that are actually required by pci_generic_config_read32()
to map the addr...

Many Thanks

Gab

> 
> 	Arnd


From stuart.yoder at nxp.com  Tue Feb  9 08:53:58 2016
From: stuart.yoder at nxp.com (Stuart Yoder)
Date: Tue, 9 Feb 2016 16:53:58 +0000
Subject: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
In-Reply-To: <20160209160812.GC9332@leverpostej>
References: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
 <56B9D62E.8080003@arm.com>
 <HE1PR04MB1641AF97F637BBCBB86BA4FE8DD60@HE1PR04MB1641.eurprd04.prod.outlook.com>
 <20160209160812.GC9332@leverpostej>
Message-ID: <HE1PR04MB1641792D75BC60CA549F45A98DD60@HE1PR04MB1641.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: Tuesday, February 09, 2016 10:08 AM
> To: Stuart Yoder <stuart.yoder at nxp.com>
> Cc: Marc Zyngier <marc.zyngier at arm.com>; Robin Murphy <robin.murphy at arm.com>;
> robh+dt at kernel.org; frowand.list at gmail.com; grant.likely at linaro.org;
> devicetree at vger.kernel.org; david.daney at cavium.com; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; stable at vger.kernel.org
> Subject: Re: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
> 
> On Tue, Feb 09, 2016 at 03:56:55PM +0000, Stuart Yoder wrote:
> >
> > > -----Original Message-----
> > > From: Marc Zyngier [mailto:marc.zyngier at arm.com]
> > > Sent: Tuesday, February 09, 2016 6:06 AM
> > > To: Robin Murphy <robin.murphy at arm.com>; robh+dt at kernel.org; frowand.list at gmail.com;
> > > grant.likely at linaro.org; devicetree at vger.kernel.org
> > > Cc: mark.rutland at arm.com; david.daney at cavium.com; Stuart Yoder
> <stuart.yoder at nxp.com>;
> > > linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> > > stable at vger.kernel.org
> > > Subject: Re: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
> > >
> > > Hi Robin,
> > >
> > > On 09/02/16 11:04, Robin Murphy wrote:
> > > > The existing msi-map code is fine for shifting the entire RID space
> > > > upwards, but attempting finer-grained remapping reveals a bug. It turns
> > > > out that we are mistakenly treating the msi-base part as an offset, not
> > > > as a new base to remap onto, so things get squiffy when rid-base is
> > > > nonzero. Fix this, and at the same time add a sanity check against
> > > > having msi-map-mask clash with a nonzero rid-base, as that's another
> > > > thing one can easily get wrong.
> > > >
> > > > CC: <stable at vger.kernel.org>
> > > > Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> > >
> > > Looks like Stuart and you both found the same bug at the same time:
> > > https://lkml.org/lkml/2016/2/8/1066
> > >
> > > but yours seem more correct to me (the rid_base masking in Stuart's
> > > version seems odd).
> > >
> > > > ---
> > > >  drivers/of/irq.c | 9 ++++++++-
> > > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> > > > index 7ee21ae..e7bfc17 100644
> > > > --- a/drivers/of/irq.c
> > > > +++ b/drivers/of/irq.c
> > > > @@ -635,6 +635,13 @@ static u32 __of_msi_map_rid(struct device *dev, struct
> > > device_node **np,
> > > >  		msi_base = be32_to_cpup(msi_map + 2);
> > > >  		rid_len = be32_to_cpup(msi_map + 3);
> > > >
> > > > +		if (rid_base & ~map_mask) {
> > > > +			dev_err(parent_dev,
> > > > +				"Invalid msi-map translation - msi-map-mask (0x%x) ignores
> rid-
> > > base (0x%x)\n",
> > > > +				map_mask, rid_base);
> > > > +			return rid_out;
> > > > +		}
> > > > +
> > > >  		msi_controller_node = of_find_node_by_phandle(phandle);
> > > >
> > > >  		matched = (masked_rid >= rid_base &&
> > > > @@ -654,7 +661,7 @@ static u32 __of_msi_map_rid(struct device *dev, struct
> device_node
> > > **np,
> > > >  	if (!matched)
> > > >  		return rid_out;
> > > >
> > > > -	rid_out = masked_rid + msi_base;
> > > > +	rid_out = masked_rid - rid_base + msi_base;
> > > >  	dev_dbg(dev,
> > > >  		"msi-map at: %s, using mask %08x, rid-base: %08x, msi-base: %08x,
> length:
> > > %08x, rid: %08x -> %08x\n",
> > > >  		dev_name(parent_dev), map_mask, rid_base, msi_base,
> > > >
> >
> > This computation:  masked_rid - rid_base
> >
> > ...doesn't seem right to me.  We are taking a rid that
> > has been already masked and subtracting a rid base that has
> > not been masked.
> 
> The binding only mentions that the input RID is masked, not the base, so
> that seems correct to me.
> 
> > I don't see how you can combine masked and unmasked values in the same
> > calculation.
> >
> > Say I have this msi mapping:
> >
> >                    msi-map = <0x0100 &its 0x11 0x1>;
> >                    msi-map-mask = <0xff>;
> >
> 
> I'd say that this is an inconsistent set of properties, and it's
> probably worth warning if we encounter this. There is no possible way
> that rid-base can be encountered.
> 
> > masked_rid = 0x0
> > rid_base = 0x0100
> > msi_base = 0x11
> >
> > masked_rid - rid_base is 0x0 - 0x0100...which does not
> > give the msi index/offset we want.
> >
> > Correct final answer should be 0x11.
> 
> You can unambiguously describe this with:
> 
> 	msi-map = <0x00 &its 0x11 0x1>;
> 	msi-map-mask = <0xff>;
> 
> This is exactly the pattern we follow in example 2 in the binding
> document.
> 
> > In my patch I masked the rid_base so it can be subtracted
> > from the masked_rid.
> >
> > masked_rid_base = 0x00
> >
> >    msi_base + (masked_rid - masked_rid_base) = 0x11
> 
> As above, I think that this is an inconsistent DT, and we should
> warn/fail in that case.

Thanks...understand now.  I'll test Robin's patch and confirm
that it works as is for me.

Thanks,
Stuart


From will.deacon at arm.com  Tue Feb  9 08:54:14 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Feb 2016 16:54:14 +0000
Subject: [PATCH v2] arm64: disable kasan when accessing frame->fp in
 unwind_frame
In-Reply-To: <1454951589-18238-1-git-send-email-yang.shi@linaro.org>
References: <1454951589-18238-1-git-send-email-yang.shi@linaro.org>
Message-ID: <20160209165414.GT22874@arm.com>

On Mon, Feb 08, 2016 at 09:13:09AM -0800, Yang Shi wrote:
> When boot arm64 kernel with KASAN enabled, the below error is reported by
> kasan:
> 
> BUG: KASAN: out-of-bounds in unwind_frame+0xec/0x260 at addr ffffffc064d57ba0
> Read of size 8 by task pidof/499
> page:ffffffbdc39355c0 count:0 mapcount:0 mapping:          (null) index:0x0
> flags: 0x0()
> page dumped because: kasan: bad access detected
> CPU: 2 PID: 499 Comm: pidof Not tainted 4.5.0-rc1 #119
> Hardware name: Freescale Layerscape 2085a RDB Board (DT)
> Call trace:
> [<ffffffc00008d078>] dump_backtrace+0x0/0x290
> [<ffffffc00008d32c>] show_stack+0x24/0x30
> [<ffffffc0006a981c>] dump_stack+0x8c/0xd8
> [<ffffffc0002e4400>] kasan_report_error+0x558/0x588
> [<ffffffc0002e4958>] kasan_report+0x60/0x70
> [<ffffffc0002e3188>] __asan_load8+0x60/0x78
> [<ffffffc00008c92c>] unwind_frame+0xec/0x260
> [<ffffffc000087e60>] get_wchan+0x110/0x160
> [<ffffffc0003b647c>] do_task_stat+0xb44/0xb68
> [<ffffffc0003b7730>] proc_tgid_stat+0x40/0x50
> [<ffffffc0003ac840>] proc_single_show+0x88/0xd8
> [<ffffffc000345be8>] seq_read+0x370/0x770
> [<ffffffc00030aba0>] __vfs_read+0xc8/0x1d8
> [<ffffffc00030c0ec>] vfs_read+0x94/0x168
> [<ffffffc00030d458>] SyS_read+0xb8/0x128
> [<ffffffc000086530>] el0_svc_naked+0x24/0x28
> Memory state around the buggy address:
>  ffffffc064d57a80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4
>  ffffffc064d57b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >ffffffc064d57b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>                                   ^
>  ffffffc064d57c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  ffffffc064d57c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> Since the shadow byte pointed by the report is 0, so it may mean it is just hit
> oob in non-current task. So, disable the instrumentation to silence these
> warnings.

Curious, but how did you trigger this? I'm just trying to confirm that
mainline is affected, but my machine boots happily with KASAN and STACKTRACE
selected and I can cat /proc/self/{stack,stat} quite happily.

What am I missing?

Will


From raveendra.padasalagi at broadcom.com  Tue Feb  9 08:55:26 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Tue, 9 Feb 2016 22:25:26 +0530
Subject: [PATCH 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <2631849.GeOulu78vx@wuerfel>
References: <1455008277-8312-1-git-send-email-raveendra.padasalagi@broadcom.com>
 <1455008277-8312-2-git-send-email-raveendra.padasalagi@broadcom.com>
 <2631849.GeOulu78vx@wuerfel>
Message-ID: <3b53af6b6c6735d10cb88518c8b8a0ae@mail.gmail.com>

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 09 February 2016 16:34
> To: Raveendra Padasalagi
> Cc: Dmitry Torokhov; Russell King; devicetree at vger.kernel.org;
linux-arm-
> kernel at lists.infradead.org; linux-input at vger.kernel.org; Rob Herring;
Pawel
> Moll; Mark Rutland; Ian Campbell; Kumar Gala; Jonathan Richardson; Jon
> Mason; Florian Fainelli; Ray Jui; Scott Branden;
linux-kernel at vger.kernel.org;
> bcm-kernel-feedback-list at broadcom.com
> Subject: Re: [PATCH 1/3] input: cygnus-update touchscreen dt node
document
>
> On Tuesday 09 February 2016 14:27:55 Raveendra Padasalagi wrote:
> > +
> > +One of the below 2 property is mandatory.
> > +- ts_syscon: handler of syscon node defining physical base address
> > +  of the controller and length of memory mapped region.
> > +  If this property is selected please make sure MFD_SYSCON config
> > +  is enabled in the defconfig file.
> > +or
> > +- reg: physical base address of the controller and length of memory
> > +  mapped region.
> > +
> >  - clocks:  The clock provided by the SOC to driver the tsc
> >  - clock-name:  name for the clock
> >  - interrupts: The touchscreen controller's interrupt @@ -54,12 +62,16
> > @@ Optional properties:
> >  - touchscreen-inverted-y: Y axis is inverted (boolean)
> >
> >  Example:
> > +       ts_adc_syscon: ts_adc_syscon at 0x180a6000 {
> > +               compatible = "syscon";
> > +               reg = <0x180a6000 0xc30>;
> > +       };
> >
> >         touchscreen: tsc at 0x180A6000 {
> >                 compatible = "brcm,iproc-touchscreen";
> >                 #address-cells = <1>;
> >                 #size-cells = <1>;
> > -               reg = <0x180A6000 0x40>;
> > +               syscon = <&ts_adc_syscon>;
> >                 clocks = <&adc_clk>;
> >                 clock-names = "tsc_clk";
> >                 interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
>
> This doesn't seem right: For one thing, it's an incompatible binding
change which
> you should try to avoid.

> Worse, the syscon has a name indicating that it really has a particular
function,
> but the name is completely generic (just "syscon"). Please add a
specific
> compatible string identifying the device that owns the registers, and
put any
> other associated properties (clocks, interrupts, ...) that are for that
device in
> general rather than just the touchscreen in there.

By mistake "syscon" name is documented in "touchscreen" label above. In
the
touchscreen driver code and .dtsi file it's named and used as "ts_syscon".
Please refer https://lkml.org/lkml/2016/2/9/71 for the changes.
Let me know if this ok. I will correct the documentation in the next
patch.

> Your changelog text fails to describe why you do this change in the
first place,
> and why you can't do it in a backward-compatible way, so please rewrite
that
> text.

Yes, I will update the change log in the next patch.

In Cygnus SOC, Touch screen controller registers are shared with ADC and
flex timer IP's.
Using readl/writel could lead to race condition. So this patch is
introduced to take care
mutually exclusive access of register's in such a case.

In the platform's where touchscreen register's are not shared normal
readl/writel
could be used.

Based on the dt  property entry "reg" or "ts_syscon" register accesses are
handled.
if "reg" is provided normal readl/writel API's are used to access
register's else if
"ts_syscon" is provided then syscon API's are used.

> 	Arnd


From ddaney at caviumnetworks.com  Tue Feb  9 08:58:50 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Tue, 9 Feb 2016 08:58:50 -0800
Subject: [PATCH v5 3/3] pci,
 pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices
In-Reply-To: <4260938.2z2RNjENMM@wuerfel>
References: <1454715675-17512-1-git-send-email-ddaney.cavm@gmail.com>
 <12842339.z2KnaZPlyO@wuerfel> <20160209162628.GA20171@localhost>
 <4260938.2z2RNjENMM@wuerfel>
Message-ID: <56BA1ACA.3090106@caviumnetworks.com>

On 02/09/2016 08:31 AM, Arnd Bergmann wrote:
> On Tuesday 09 February 2016 10:26:28 Bjorn Helgaas wrote:
>> On Tue, Feb 09, 2016 at 10:25:33AM +0100, Arnd Bergmann wrote:
>>> On Monday 08 February 2016 17:24:30 Bjorn Helgaas wrote:
>>>>>>
>>>>>> I assume your system conforms to expectations like these; I'm just
>>>>>> pointing them out because you mentioned buses with multiple devices on
>>>>>> them, which is definitely something one doesn't expect in PCIe.
>>>>>
>>>>> The topology we have is currently working with the kernel's core PCI
>>>>> code.  I don't really want to get into discussing what the
>>>>> definition of PCIe is.  We have multiple devices (more than 32) on a
>>>>> single bus, and they have PCI Express and ARI Capabilities.  Is that
>>>>> PCIe?  I don't know.
>>>>
>>>> I don't need to know the details of your topology.  As long as it
>>>> conforms to the PCIe spec, it should be fine.  If it *doesn't* conform
>>>> to the spec, but things currently seem to work, that's less fine,
>>>> because a future Linux change is liable to break something for you.
>>>>
>>>> I was a little concerned about your statement that "there are multiple
>>>> devices residing on each bus, so from that point of view it cannot be
>>>> PCIe."  That made it sound like you're doing something outside the
>>>> spec.  If you're just using regular multi-function devices or ARI,
>>>> then I don't see any issue (or any reason to say it can't be PCIe).
>>>
>>> It doesn't conform to the PCIe port spec, because there are no external
>>> ports but just integrated devices in the host bridge.
>>
>> Is there a spec section you have in mind?  Based on sec 1.3.1, I don't
>> think there's a requirement to have PCI Express Ports (is that what
>> you mean by "external ports"?)
>
> No, I was just assuming that ports are specified in their own document,
> which would not be followed here if there are none. There is nothing in
> here that leads me to believe that the hardware is actually noncompliant
> with any relevant standard.
>
>> Root Complex Integrated Endpoints (sec 1.3.2.3) are clearly supported
>> and they would not be behind a Root Port.  If you're using those, I
>> hope they're correctly identified via the PCIe capability Device/Port
>> Type (sec 7.8.2) because we rely on that type to figure out whether
>> the link-related registers are implemented.
>>
>> The spec does include rules related to peer-to-peer transactions, MPS,
>> ASPM, error reporting, etc., and Linux relies on those, so I think it
>> would be important to get those right.
>
> David can probably explain more if the registers are compliant with
> those parts of the spec.

It is somewhat moot, but in the interest of keeping this thread alive:

None of the "on-chip" devices behind these root complexes implements 
ASPM, AER, etc.  The capability structures for all the features you 
mention are not present.

All that is there beyond standard PCI capabilities are:

   - PCI Express capability, to indicate presence of PCI Express 
Extended Capabilities.

   - ARI capability so we can fit more than 16 devices on a bus.

   - SRIOV capability on devices that are virtualizable.

   - That's it!

The reality is that they are not really PCI/PCIe devices at all.  All 
the device registers are at fixed addresses and are connected to 
proprietary internal buses with various weird properties.  Witness the 
need for Enhanced Allocation capabilities to describe the fixed addressing.

The PCI config space is a veneer laid on top of it all to aid in device 
discovery and interrupt routing.

So is it PCI or PCIe?  It is not really important to say.  All we want, 
is to be able to get the pci-host-generic root complex driver to bind to 
our ECAM/ECAM-like configuration space accessors.

David Daney



>
> 	Arnd
>



From christoffer.dall at linaro.org  Tue Feb  9 09:00:42 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 18:00:42 +0100
Subject: [PATCH v2 18/28] ARM: KVM: Add HYP mode entry code
In-Reply-To: <1454583645-10144-19-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-19-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209170042.GA5171@cbox>

On Thu, Feb 04, 2016 at 11:00:35AM +0000, Marc Zyngier wrote:
> This part is almost entierely borrowed from the existing code, just
> slightly simplifying the HYP function call (as we now save SPSR_hyp
> in the world switch).
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kvm/hyp/Makefile    |   1 +
>  arch/arm/kvm/hyp/hyp-entry.S | 157 +++++++++++++++++++++++++++++++++++++++++++
>  arch/arm/kvm/hyp/hyp.h       |   2 +
>  3 files changed, 160 insertions(+)
>  create mode 100644 arch/arm/kvm/hyp/hyp-entry.S
> 
> diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
> index cfab402..a7d3a7e 100644
> --- a/arch/arm/kvm/hyp/Makefile
> +++ b/arch/arm/kvm/hyp/Makefile
> @@ -9,4 +9,5 @@ obj-$(CONFIG_KVM_ARM_HOST) += vgic-v2-sr.o
>  obj-$(CONFIG_KVM_ARM_HOST) += vfp.o
>  obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o
>  obj-$(CONFIG_KVM_ARM_HOST) += entry.o
> +obj-$(CONFIG_KVM_ARM_HOST) += hyp-entry.o
>  obj-$(CONFIG_KVM_ARM_HOST) += switch.o
> diff --git a/arch/arm/kvm/hyp/hyp-entry.S b/arch/arm/kvm/hyp/hyp-entry.S
> new file mode 100644
> index 0000000..44bc11f
> --- /dev/null
> +++ b/arch/arm/kvm/hyp/hyp-entry.S
> @@ -0,0 +1,157 @@
> +/*
> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> + * Author: Christoffer Dall <c.dall at virtualopensystems.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, write to the Free Software
> + * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
> + */
> +
> +#include <linux/linkage.h>
> +#include <asm/kvm_arm.h>
> +#include <asm/kvm_asm.h>
> +
> +	.arch_extension     virt
> +
> +	.text
> +	.pushsection	.hyp.text, "ax"
> +
> +.macro load_vcpu	reg
> +	mrc	p15, 4, \reg, c13, c0, 2	@ HTPIDR
> +.endm
> +
> +/********************************************************************
> + * Hypervisor exception vector and handlers
> + *
> + *
> + * The KVM/ARM Hypervisor ABI is defined as follows:
> + *
> + * Entry to Hyp mode from the host kernel will happen _only_ when an HVC
> + * instruction is issued since all traps are disabled when running the host
> + * kernel as per the Hyp-mode initialization at boot time.
> + *
> + * HVC instructions cause a trap to the vector page + offset 0x14 (see hyp_hvc
> + * below) when the HVC instruction is called from SVC mode (i.e. a guest or the
> + * host kernel) and they cause a trap to the vector page + offset 0x8 when HVC
> + * instructions are called from within Hyp-mode.
> + *
> + * Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
> + *    Switching to Hyp mode is done through a simple HVC #0 instruction. The
> + *    exception vector code will check that the HVC comes from VMID==0.
> + *    - r0 contains a pointer to a HYP function
> + *    - r1, r2, and r3 contain arguments to the above function.
> + *    - The HYP function will be called with its arguments in r0, r1 and r2.
> + *    On HYP function return, we return directly to SVC.
> + *
> + * Note that the above is used to execute code in Hyp-mode from a host-kernel
> + * point of view, and is a different concept from performing a world-switch and
> + * executing guest code SVC mode (with a VMID != 0).
> + */
> +
> +	.align 5
> +__hyp_vector:
> +	.global	__hyp_vector
> +__kvm_hyp_vector:
> +	.weak __kvm_hyp_vector
> +
> +	@ Hyp-mode exception vector
> +	W(b)	hyp_reset
> +	W(b)	hyp_undef
> +	W(b)	hyp_svc
> +	W(b)	hyp_pabt
> +	W(b)	hyp_dabt
> +	W(b)	hyp_hvc
> +	W(b)	hyp_irq
> +	W(b)	hyp_fiq
> +
> +.macro invalid_vector label, cause
> +	.align
> +\label:	b	.
> +.endm
> +
> +	invalid_vector	hyp_reset
> +	invalid_vector	hyp_undef
> +	invalid_vector	hyp_svc
> +	invalid_vector	hyp_pabt
> +	invalid_vector	hyp_dabt
> +	invalid_vector	hyp_fiq
> +
> +hyp_hvc:
> +	/*
> +	 * Getting here is either because of a trap from a guest,
> +	 * or from executing HVC from the host kernel, which means
> +	 * "do something in Hyp mode".
> +	 */
> +	push	{r0, r1, r2}
> +
> +	@ Check syndrome register
> +	mrc	p15, 4, r1, c5, c2, 0	@ HSR
> +	lsr	r0, r1, #HSR_EC_SHIFT
> +	cmp	r0, #HSR_EC_HVC
> +	bne	guest_trap		@ Not HVC instr.
> +
> +	/*
> +	 * Let's check if the HVC came from VMID 0 and allow simple
> +	 * switch to Hyp mode
> +	 */
> +	mrrc    p15, 6, r0, r2, c2
> +	lsr     r2, r2, #16
> +	and     r2, r2, #0xff
> +	cmp     r2, #0
> +	bne	guest_trap		@ Guest called HVC
> +
> +	/*
> +	 * Getting here means host called HVC, we shift parameters and branch
> +	 * to Hyp function.
> +	 */
> +	pop	{r0, r1, r2}
> +
> +	/* Check for __hyp_get_vectors */
> +	cmp	r0, #-1
> +	mrceq	p15, 4, r0, c12, c0, 0	@ get HVBAR
> +	beq	1f
> +
> +	push	{lr}
> +
> +	mov	lr, r0
> +	mov	r0, r1
> +	mov	r1, r2
> +	mov	r2, r3
> +
> +THUMB(	orr	lr, #1)
> +	blx	lr			@ Call the HYP function
> +
> +	pop	{lr}
> +1:	eret
> +
> +guest_trap:
> +	load_vcpu r0			@ Load VCPU pointer to r0
> +
> +	@ Check if we need the fault information

nit: this is not about faults at this point, so this comment should
either go or be reworded to "let's check if we trapped on guest VFP
access"

and I think the lsr can be moved into the ifdef as well.

> +	lsr	r1, r1, #HSR_EC_SHIFT
> +#ifdef CONFIG_VFPv3
> +	cmp	r1, #HSR_EC_CP_0_13
> +	beq	__vfp_guest_restore
> +#endif
> +
> +	mov	r1, #ARM_EXCEPTION_HVC
> +	b	__guest_exit
> +
> +hyp_irq:
> +	push	{r0, r1, r2}
> +	mov	r1, #ARM_EXCEPTION_IRQ
> +	load_vcpu r0			@ Load VCPU pointer to r0
> +	b	__guest_exit
> +
> +	.ltorg
> +
> +	.popsection
> diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
> index 7ddca54..8bbd2a7 100644
> --- a/arch/arm/kvm/hyp/hyp.h
> +++ b/arch/arm/kvm/hyp/hyp.h
> @@ -123,4 +123,6 @@ void __hyp_text __banked_restore_state(struct kvm_cpu_context *ctxt);
>  
>  int asmlinkage __guest_enter(struct kvm_vcpu *vcpu,
>  			     struct kvm_cpu_context *host);
> +int asmlinkage __hyp_do_panic(const char *, int, u32);
> +
>  #endif /* __ARM_KVM_HYP_H__ */
> -- 
> 2.1.4
> 
Otherwise looke good.

Thanks,
-Christoffer


From fu.wei at linaro.org  Tue Feb  9 09:00:36 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Wed, 10 Feb 2016 01:00:36 +0800
Subject: [PATCH v11 0/4] Watchdog: introduce ARM SBSA watchdog driver
Message-ID: <1455037240-16192-1-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This patchset:
    (1)Introduce Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
    for FDT info of SBSA Generic Watchdog, and give two examples of
    adding SBSA Generic Watchdog device node into the dts files:
    foundation-v8.dts and amd-seattle-soc.dtsi.

    (2)Introduce ARM SBSA watchdog driver:
        a.Use linux kernel watchdog framework;
        b.Work with FDT on ARM64;
        c.Support getting timeout from parameter and FDT at the driver
          init stage.
        d.The driver works in two modes:
          (1) single stage timeout (ignore WS0 interrupt)
          (2) two stages timeout (register WS0 interrupt, do panic in routine)
        e.User can config working mode by module parameter "action".

This patchset has been tested with watchdog daemon
(ACPI/FDT, module/build-in) on the following platforms:
    (1)ARM Foundation v8 model
    (2)AMD Seattle platform

This patchset has been tested with kdump successfully.

Changelog:
v11:Merge patch 4 and 5.
    Improve some comments.
    The driver works in two modes, it's configured by "action"(instead of
    panic_enabled).
    Improve the initialization of the timeout limits.
    Feeding dog by writing "0" to WRR.

v10:https://lkml.org/lkml/2016/2/3/817
    Delete pretimeout support.
    Separate the driver to two parts:
        (1) single stage timeout driver(ignore WS0 interrupt);
        (2) register WS0 interrupt for the half timeout panic.
    timeout == (enable --> WS1).

v9: https://lkml.org/lkml/2015/11/9/57
    Rebase to latest kernel version(4.3).
    Update the Documentation of sbsa-gwdt device node info of FDT:
        (1) move some introduction to pretimeout patch
        (2) delete WS1 value from "interrupts" of binding documentation,
            since WS1 won't be handled by Linux.

v8: https://lkml.org/lkml/2015/10/27/466
    Rebase to latest kernel version(4.3-rc7).
    Separate the patches of GTDT support and arm_arch_timer. This
    clocksource relevant patch will upstreamed in a individual patchset.
    Update all the default timeout and pretimeout to 30s and 60s.
    Improve documentation and inline comments.
    Fix a bug in pretimeout support which makes timeout and pretimeout
    parameters initialization fail.

v7: https://lkml.org/lkml/2015/8/24/611
    Rebase to latest kernel version(4.2-rc7).
    Improve FDT support: geting resource by order, instead of name.
    According to the FDT support, Update the example dts file, gtdt.c
    and sbsa_gwdt.c.
    Pass the sparse test, and fix the warning.
    Fix the max_pretimeout and max_timeout value overflow bug.
    Delete the WCV output value.
    

v6: https://lkml.org/lkml/2015/6/23/359
    Improve the dtb example files: reduce the register frame size to 4K.
    Improve pretimeout support:
        (1) improve watchdog_init_timeouts function
	(2) rename watchdog_check_min_max_timeouts back to the original name
        (1) improve watchdog_timeout_invalid/watchdog_pretimeout_invalid
    Add the new features in the sbsa_gwdt driver:
	(1) In the second stage, user can feed the dog without cleaning WS0.
	(2) In the second stage, user can trigger WS1 by setting pretimeout = 0.
	(3) expand the max value of pretimeout, in case 10 second is not enough
	    for a kdump kernel reboot in panic.

v5: https://lkml.org/lkml/2015/6/10/357
    Improve pretimeout support:
        (1)fix typo in documentation and comments.
	(2)fix the timeout limits validation bug.
    Simplify sbsa_gwdt driver:
	(1)integrate all the registers access functions into caller.

v4: https://lkml.org/lkml/2015/6/2/4
    Refactor GTDT support code: remove it from arch/arm64/kernel/acpi.c,
    put it into drivers/acpi/gtdt.c file.
    Integrate the GTDT code of drivers/clocksource/arm_arch_timer.c into
    drivers/acpi/gtdt.c.
    Improve pretimeout support, fix "pretimeout == 0" problem.
    Simplify sbsa_gwdt driver:
        (1)timeout/pretimeout limits setup;
        (2)keepalive function;
        (3)delete "clk == 0" check;
        (4)delete WS0 status bit check in interrupt routine;
        (5)sbsa_gwdt_set_wcv function.

v3: https://lkml.org/lkml/2015/5/25/111
    Delete "export arch_timer_get_rate" patch.
    Driver back to use arch_timer_get_cntfrq.
    Improve watchdog_init_timeouts function and update relevant documentation.
    Improve watchdog_timeout_invalid and watchdog_pretimeout_invalid.
    Improve foundation-v8.dts: delete the unnecessary tag of device node.
    Remove "ARM64 || COMPILE_TEST" from Kconfig.
    Add comments in arch/arm64/kernel/acpi.c
    Fix typoes and incorrect comments.

v2: https://lkml.org/lkml/2015/5/21/172
    Improve watchdog-kernel-api.txt documentation for pretimeout support.
    Export "arch_timer_get_rate" in arm_arch_timer.c.
    Add watchdog_init_timeouts API for pretimeout support in framework.
    Improve suspend and resume foundation in driver
    Improve timeout/pretimeout values init code in driver.
    Delete unnecessary items of the sbsa_gwdt struct and #define.
    Delete all unnecessary debug info in driver.
    Fix 64bit division bug.
    Use the arch_timer interface to get watchdog clock rate.
    Add MODULE_DEVICE_TABLE for platform device id.
    Fix typoes.

v1: https://lkml.org/lkml/2015/5/15/279
    The first version upstream patchset to linux mailing list.

Fu Wei (4):
  Documentation: add sbsa-gwdt driver documentation
  ARM64: add SBSA Generic Watchdog device node in foundation-v8.dts
  ARM64: add SBSA Generic Watchdog device node in amd-seattle-soc.dtsi
  Watchdog: introduce ARM SBSA watchdog driver

 .../devicetree/bindings/watchdog/sbsa-gwdt.txt     |  35 ++
 Documentation/watchdog/watchdog-parameters.txt     |   7 +
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi       |   9 +
 arch/arm64/boot/dts/arm/foundation-v8.dts          |   8 +
 drivers/watchdog/Kconfig                           |  20 +
 drivers/watchdog/Makefile                          |   1 +
 drivers/watchdog/sbsa_gwdt.c                       | 403 +++++++++++++++++++++
 7 files changed, 483 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
 create mode 100644 drivers/watchdog/sbsa_gwdt.c

-- 
2.5.0



From fu.wei at linaro.org  Tue Feb  9 09:00:37 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Wed, 10 Feb 2016 01:00:37 +0800
Subject: [PATCH v11 1/4] Documentation: add sbsa-gwdt driver documentation
In-Reply-To: <1455037240-16192-1-git-send-email-fu.wei@linaro.org>
References: <1455037240-16192-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1455037240-16192-2-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

The sbsa-gwdt.txt documentation in devicetree/bindings/watchdog is for
introducing SBSA(Server Base System Architecture) Generic Watchdog
device node info into FDT.

Also add sbsa-gwdt introduction in watchdog-parameters.txt

Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Fu Wei <fu.wei at linaro.org>
---
 .../devicetree/bindings/watchdog/sbsa-gwdt.txt     | 35 ++++++++++++++++++++++
 Documentation/watchdog/watchdog-parameters.txt     |  7 +++++
 2 files changed, 42 insertions(+)

diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
new file mode 100644
index 0000000..73a5d0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
@@ -0,0 +1,35 @@
+* SBSA (Server Base System Architecture) Generic Watchdog
+
+The SBSA Generic Watchdog Timer is used to force a reset of the system
+after two stages of timeout have elapsed.  A detailed definition of the
+watchdog timer can be found in the ARM document: ARM-DEN-0029 - Server
+Base System Architecture (SBSA)
+
+Required properties:
+- compatible: Should at least contain "arm,sbsa-gwdt".
+
+- reg: Each entry specifies the base physical address of a register frame
+  and the length of that frame; currently, two frames must be defined,
+  in this order:
+  1: Watchdog control frame;
+  2: Refresh frame.
+
+- interrupts: Should contain the Watchdog Signal 0 (WS0) SPI (Shared
+  Peripheral Interrupt) number of SBSA Generic Watchdog.
+
+Optional properties
+- timeout-sec: Watchdog timeout values (in seconds).
+
+- status: Indicates the device is not available for use. Should be "okay"
+  or "disabled" for available/unavailable. Default is "okay".
+
+Example for FVP Foundation Model v8:
+
+watchdog at 2a440000 {
+	compatible = "arm,sbsa-gwdt";
+	reg = <0x0 0x2a440000 0 0x1000>,
+	      <0x0 0x2a450000 0 0x1000>;
+	interrupts = <0 27 4>;
+	timeout-sec = <30>;
+	status = "okay";
+};
diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
index 9f9ec9f..ce7ae4e 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -284,6 +284,13 @@ sbc_fitpc2_wdt:
 margin: Watchdog margin in seconds (default 60s)
 nowayout: Watchdog cannot be stopped once started
 -------------------------------------------------
+sbsa_gwdt:
+timeout: Watchdog timeout in seconds. (default 10s)
+action: Watchdog action at the first stage timeout,
+	set to 0 to ignore, 1 to panic. (default=0)
+nowayout: Watchdog cannot be stopped once started
+	(default=kernel config parameter)
+-------------------------------------------------
 sc1200wdt:
 isapnp: When set to 0 driver ISA PnP support will be disabled (default=1)
 io: io port
-- 
2.5.0



From fu.wei at linaro.org  Tue Feb  9 09:00:38 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Wed, 10 Feb 2016 01:00:38 +0800
Subject: [PATCH v11 2/4] ARM64: add SBSA Generic Watchdog device node in
 foundation-v8.dts
In-Reply-To: <1455037240-16192-1-git-send-email-fu.wei@linaro.org>
References: <1455037240-16192-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1455037240-16192-3-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Fu Wei <fu.wei at linaro.org>
---
 arch/arm64/boot/dts/arm/foundation-v8.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dts b/arch/arm64/boot/dts/arm/foundation-v8.dts
index 4eac8dc..75da16b 100644
--- a/arch/arm64/boot/dts/arm/foundation-v8.dts
+++ b/arch/arm64/boot/dts/arm/foundation-v8.dts
@@ -237,4 +237,12 @@
 			};
 		};
 	};
+	watchdog at 2a440000 {
+		compatible = "arm,sbsa-gwdt";
+		reg = <0x0 0x2a440000 0 0x1000>,
+			<0x0 0x2a450000 0 0x1000>;
+		interrupts = <0 27 4>;
+		timeout-sec = <30>;
+		status = "okay";
+	};
 };
-- 
2.5.0



From fu.wei at linaro.org  Tue Feb  9 09:00:39 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Wed, 10 Feb 2016 01:00:39 +0800
Subject: [PATCH v11 3/4] ARM64: add SBSA Generic Watchdog device node in
 amd-seattle-soc.dtsi
In-Reply-To: <1455037240-16192-1-git-send-email-fu.wei@linaro.org>
References: <1455037240-16192-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1455037240-16192-4-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Signed-off-by: Fu Wei <fu.wei at linaro.org>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 2874d92..67eb636 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -84,6 +84,15 @@
 			clock-names = "uartclk", "apb_pclk";
 		};
 
+		watchdog0: watchdog at e0bb0000 {
+			compatible = "arm,sbsa-gwdt";
+			reg = <0x0 0xe0bc0000 0 0x1000>,
+				<0x0 0xe0bb0000 0 0x1000>;
+			interrupts = <0 337 4>;
+			timeout-sec = <15>;
+			status = "disabled";
+		};
+
 		spi0: ssp at e1020000 {
 			status = "disabled";
 			compatible = "arm,pl022", "arm,primecell";
-- 
2.5.0



From fu.wei at linaro.org  Tue Feb  9 09:00:40 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Wed, 10 Feb 2016 01:00:40 +0800
Subject: [PATCH v11 4/4] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <1455037240-16192-1-git-send-email-fu.wei@linaro.org>
References: <1455037240-16192-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1455037240-16192-5-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

According to Server Base System Architecture (SBSA) specification,
the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0)
is for alerting the system by interrupt, the second one (WS1) is a real
hardware reset.
More details about the hardware specification of this device:
ARM DEN0029B - Server Base System Architecture (SBSA)

This driver can operate ARM SBSA Generic Watchdog as a single stage watchdog
or a two stages watchdog, it's set up by the module parameter "action".
In the single stage mode, when the timeout is reached, your system
will be reset by WS1. The first signal (WS0) is ignored.
In the two stages mode, when the timeout is reached, the first signal (WS0)
will trigger panic. If the system is getting into trouble and cannot be reset
by panic or restart properly by the kdump kernel(if supported), then the
second stage (as long as the first stage) will be reached, system will be
reset by WS1. This function can help administrator to backup the system
context info by panic console output or kdump.

This driver bases on linux kernel watchdog framework, so it can get
timeout from module parameter and FDT at the driver init stage.

Signed-off-by: Fu Wei <fu.wei at linaro.org>
Reviewed-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Pratyush Anand <panand at redhat.com>
---
 drivers/watchdog/Kconfig     |  20 +++
 drivers/watchdog/Makefile    |   1 +
 drivers/watchdog/sbsa_gwdt.c | 403 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 424 insertions(+)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 0f6d851..ed9a5cb 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -202,6 +202,26 @@ config ARM_SP805_WATCHDOG
 	  ARM Primecell SP805 Watchdog timer. This will reboot your system when
 	  the timeout is reached.
 
+config ARM_SBSA_WATCHDOG
+	tristate "ARM SBSA Generic Watchdog"
+	depends on ARM64
+	depends on ARM_ARCH_TIMER
+	select WATCHDOG_CORE
+	help
+	  ARM SBSA Generic Watchdog has two stage timeouts:
+	  the first signal (WS0) is for alerting the system by interrupt,
+	  the second one (WS1) is a real hardware reset.
+	  More details: ARM DEN0029B - Server Base System Architecture (SBSA)
+
+	  This driver can operate ARM SBSA Generic Watchdog as a single stage
+	  or a two stages watchdog, it depends on the module parameter "action".
+
+	  Note: the maximum timeout in the two stages mode is half of that in
+	  the single stage mode.
+
+	  To compile this driver as module, choose M here: The module
+	  will be called sbsa_gwdt.
+
 config ASM9260_WATCHDOG
 	tristate "Alphascale ASM9260 watchdog"
 	depends on MACH_ASM9260
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index f566753..f9826d4 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
 
 # ARM Architecture
 obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
+obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
 obj-$(CONFIG_ASM9260_WATCHDOG) += asm9260_wdt.o
 obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
 obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
new file mode 100644
index 0000000..f506762
--- /dev/null
+++ b/drivers/watchdog/sbsa_gwdt.c
@@ -0,0 +1,403 @@
+/*
+ * SBSA(Server Base System Architecture) Generic Watchdog driver
+ *
+ * Copyright (c) 2015, Linaro Ltd.
+ * Author: Fu Wei <fu.wei at linaro.org>
+ *         Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
+ *         Al Stone <al.stone at linaro.org>
+ *         Timur Tabi <timur at codeaurora.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License 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.
+ *
+ * ARM SBSA Generic Watchdog has two stage timeouts:
+ * the first signal (WS0) is for alerting the system by interrupt,
+ * the second one (WS1) is a real hardware reset.
+ * More details about the hardware specification of this device:
+ * ARM DEN0029B - Server Base System Architecture (SBSA)
+ *
+ * This driver can operate ARM SBSA Generic Watchdog as a single stage watchdog
+ * or a two stages watchdog, it's set up by the module parameter "action".
+ * In the single stage mode, when the timeout is reached, your system
+ * will be reset by WS1. The first signal (WS0) is ignored.
+ * In the two stages mode, when the timeout is reached, the first signal (WS0)
+ * will trigger panic. If the system is getting into trouble and cannot be reset
+ * by panic or restart properly by the kdump kernel(if supported), then the
+ * second stage (as long as the first stage) will be reached, system will be
+ * reset by WS1. This function can help administrator to backup the system
+ * context info by panic console output or kdump.
+ *
+ * SBSA GWDT:
+ * if action is 1 (the two stages mode):
+ * |--------WOR-------WS0--------WOR-------WS1
+ * |----timeout-----(panic)----timeout-----reset
+ *
+ * if action is 0 (the single stage mode):
+ * |------WOR-----WS0(ignored)-----WOR------WS1
+ * |--------------timeout-------------------reset
+ *
+ * Note: Since this watchdog timer has two stages, and each stage is determined
+ * by WOR, in the single stage mode, the timeout is (WOR * 2); in the two
+ * stages mode, the timeout is WOR. The maximum timeout in the two stages mode
+ * is half of that in the single stage mode.
+ *
+ */
+
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/uaccess.h>
+#include <linux/watchdog.h>
+#include <asm/arch_timer.h>
+
+/* SBSA Generic Watchdog register definitions */
+/* refresh frame */
+#define SBSA_GWDT_WRR				0x000
+
+/* control frame */
+#define SBSA_GWDT_WCS				0x000
+#define SBSA_GWDT_WOR				0x008
+#define SBSA_GWDT_WCV				0x010
+
+/* refresh/control frame */
+#define SBSA_GWDT_W_IIDR			0xfcc
+#define SBSA_GWDT_IDR				0xfd0
+
+/* Watchdog Control and Status Register */
+#define SBSA_GWDT_WCS_EN			BIT(0)
+#define SBSA_GWDT_WCS_WS0			BIT(1)
+#define SBSA_GWDT_WCS_WS1			BIT(2)
+
+/**
+ * struct sbsa_gwdt - Internal representation of the SBSA GWDT
+ * @wdd:		kernel watchdog_device structure
+ * @clk:		store the System Counter clock frequency, in Hz.
+ * @refresh_base:	Virtual address of the watchdog refresh frame
+ * @control_base:	Virtual address of the watchdog control frame
+ */
+struct sbsa_gwdt {
+	struct watchdog_device	wdd;
+	u32			clk;
+	void __iomem		*refresh_base;
+	void __iomem		*control_base;
+};
+
+#define to_sbsa_gwdt(e) container_of(e, struct sbsa_gwdt, wdd)
+
+#define DEFAULT_TIMEOUT		10 /* seconds, the 1st + 2nd watch periods*/
+
+static unsigned int timeout;
+module_param(timeout, uint, 0);
+MODULE_PARM_DESC(timeout,
+		 "Watchdog timeout in seconds. (>=0, default="
+		 __MODULE_STRING(DEFAULT_TIMEOUT) ")");
+
+/*
+ * action refers to action taken when watchdog gets WS0
+ * 0 = skip
+ * 1 = panic
+ * defaults to skip (0)
+ */
+static int action;
+module_param(action, int, 0);
+MODULE_PARM_DESC(action, "after watchdog gets WS0 interrupt, do: "
+		 "0 = skip(*)  1 = panic");
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, S_IRUGO);
+MODULE_PARM_DESC(nowayout,
+		 "Watchdog cannot be stopped once started (default="
+		 __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+/*
+ * watchdog operation functions
+ */
+static int sbsa_gwdt_set_timeout(struct watchdog_device *wdd,
+				 unsigned int timeout)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	wdd->timeout = timeout;
+
+	if (action)
+		writel(gwdt->clk * timeout,
+		       gwdt->control_base + SBSA_GWDT_WOR);
+	else
+		/*
+		 * In the single stage mode, The first signal (WS0) is ignored,
+		 * the timeout is (WOR * 2), so the WOR should be configured
+		 * to half value of timeout.
+		 */
+		writel(gwdt->clk / 2 * timeout,
+		       gwdt->control_base + SBSA_GWDT_WOR);
+
+	return 0;
+}
+
+static unsigned int sbsa_gwdt_get_timeleft(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+	u64 timeleft = 0;
+
+	/*
+	 * In the single stage mode, if WS0 is deasserted
+	 * (watchdog is in the first stage),
+	 * timeleft = WOR + (WCV - system counter)
+	 */
+	if (!action &&
+	    !(readl(gwdt->control_base + SBSA_GWDT_WCS) & SBSA_GWDT_WCS_WS0))
+		timeleft += readl(gwdt->control_base + SBSA_GWDT_WOR);
+
+	timeleft += readq(gwdt->control_base + SBSA_GWDT_WCV) -
+		    arch_counter_get_cntvct();
+
+	do_div(timeleft, gwdt->clk);
+
+	return timeleft;
+}
+
+static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	/*
+	* Writing WRR for an explicit watchdog refresh.
+	* You can write anyting (like 0).
+	*/
+	writel(0, gwdt->refresh_base + SBSA_GWDT_WRR);
+
+	return 0;
+}
+
+static unsigned int sbsa_gwdt_status(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+	u32 status = readl(gwdt->control_base + SBSA_GWDT_WCS);
+
+	/* is the watchdog timer running? */
+	return (status & SBSA_GWDT_WCS_EN) << WDOG_ACTIVE;
+}
+
+static int sbsa_gwdt_start(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	/* writing WCS will cause an explicit watchdog refresh */
+	writel(SBSA_GWDT_WCS_EN, gwdt->control_base + SBSA_GWDT_WCS);
+
+	return sbsa_gwdt_keepalive(wdd);
+}
+
+static int sbsa_gwdt_stop(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	/* Simply write 0 to WCS to clean WCS_EN bit */
+	writel(0, gwdt->control_base + SBSA_GWDT_WCS);
+
+	return 0;
+}
+
+static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
+{
+	panic("SBSA Watchdog timeout");
+
+	return IRQ_HANDLED;
+}
+
+static struct watchdog_info sbsa_gwdt_info = {
+	.identity	= "SBSA Generic Watchdog",
+	.options	= WDIOF_SETTIMEOUT |
+			  WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE |
+			  WDIOF_CARDRESET,
+};
+
+static struct watchdog_ops sbsa_gwdt_ops = {
+	.owner		= THIS_MODULE,
+	.start		= sbsa_gwdt_start,
+	.stop		= sbsa_gwdt_stop,
+	.status		= sbsa_gwdt_status,
+	.ping		= sbsa_gwdt_keepalive,
+	.set_timeout	= sbsa_gwdt_set_timeout,
+	.get_timeleft	= sbsa_gwdt_get_timeleft,
+};
+
+static int sbsa_gwdt_probe(struct platform_device *pdev)
+{
+	void __iomem *rf_base, *cf_base;
+	struct device *dev = &pdev->dev;
+	struct watchdog_device *wdd;
+	struct sbsa_gwdt *gwdt;
+	struct resource *res;
+	int ret, irq;
+	u32 status;
+
+	gwdt = devm_kzalloc(dev, sizeof(*gwdt), GFP_KERNEL);
+	if (!gwdt)
+		return -ENOMEM;
+	platform_set_drvdata(pdev, gwdt);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	cf_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(cf_base))
+		return PTR_ERR(cf_base);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	rf_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(rf_base))
+		return PTR_ERR(rf_base);
+
+	if (action) {
+		irq = platform_get_irq(pdev, 0);
+		if (irq < 0) {
+			action = 0;
+			dev_warn(dev, "unable to get ws0 interrupt.\n");
+		} else {
+			if (devm_request_irq(dev, irq, sbsa_gwdt_interrupt, 0,
+					     pdev->name, gwdt)) {
+				action = 0;
+				dev_warn(dev, "unable to request IRQ %d.\n",
+					 irq);
+			}
+		}
+		if (!action)
+			dev_warn(dev, "fall back to signle stage mode.\n");
+	}
+
+	/*
+	 * Get the frequency of system counter from the cp15 interface of ARM
+	 * Generic timer. We don't need to check it, because if it returns "0",
+	 * system would panic in very early stage.
+	 */
+	gwdt->clk = arch_timer_get_cntfrq();
+	gwdt->refresh_base = rf_base;
+	gwdt->control_base = cf_base;
+
+	wdd = &gwdt->wdd;
+	wdd->parent = dev;
+	wdd->info = &sbsa_gwdt_info;
+	wdd->ops = &sbsa_gwdt_ops;
+	watchdog_set_drvdata(wdd, gwdt);
+	watchdog_set_nowayout(wdd, nowayout);
+
+	wdd->min_timeout = 1;
+	wdd->max_timeout = U32_MAX / gwdt->clk;
+	/*
+	 * In the single stage mode, The first signal (WS0) is ignored,
+	 * the timeout is (WOR * 2), so the maximum timeout should be double.
+	 */
+	if (!action)
+		wdd->max_timeout *= 2;
+
+	wdd->timeout = DEFAULT_TIMEOUT;
+	watchdog_init_timeout(wdd, timeout, dev);
+
+	status = readl(gwdt->control_base + SBSA_GWDT_WCS);
+	if (status & SBSA_GWDT_WCS_WS1) {
+		dev_warn(dev, "System reset by WDT.\n");
+		wdd->bootstatus |= WDIOF_CARDRESET;
+	}
+
+	ret = watchdog_register_device(wdd);
+	if (ret)
+		return ret;
+
+	/*
+	 * Update timeout to WOR.
+	 * Because of the explicit watchdog refresh mechanism,
+	 * it's also a ping, if watchdog is enabled.
+	 */
+	sbsa_gwdt_set_timeout(wdd, wdd->timeout);
+
+	dev_info(dev, "Initialized with %ds timeout @ %u Hz, action=%d.%s\n",
+		 wdd->timeout, gwdt->clk, action,
+		 status & SBSA_GWDT_WCS_EN ? " [enabled]" : "");
+
+	return 0;
+}
+
+static void sbsa_gwdt_shutdown(struct platform_device *pdev)
+{
+	struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
+
+	sbsa_gwdt_stop(&gwdt->wdd);
+}
+
+static int sbsa_gwdt_remove(struct platform_device *pdev)
+{
+	struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
+
+	watchdog_unregister_device(&gwdt->wdd);
+
+	return 0;
+}
+
+/* Disable watchdog if it is active during suspend */
+static int __maybe_unused sbsa_gwdt_suspend(struct device *dev)
+{
+	struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
+
+	if (watchdog_active(&gwdt->wdd))
+		sbsa_gwdt_stop(&gwdt->wdd);
+
+	return 0;
+}
+
+/* Enable watchdog and configure it if necessary */
+static int __maybe_unused sbsa_gwdt_resume(struct device *dev)
+{
+	struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
+
+	if (watchdog_active(&gwdt->wdd))
+		sbsa_gwdt_start(&gwdt->wdd);
+
+	return 0;
+}
+
+static const struct dev_pm_ops sbsa_gwdt_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(sbsa_gwdt_suspend, sbsa_gwdt_resume)
+};
+
+static const struct of_device_id sbsa_gwdt_of_match[] = {
+	{ .compatible = "arm,sbsa-gwdt", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sbsa_gwdt_of_match);
+
+static const struct platform_device_id sbsa_gwdt_pdev_match[] = {
+	{ .name = "sbsa-gwdt", },
+	{},
+};
+MODULE_DEVICE_TABLE(platform, sbsa_gwdt_pdev_match);
+
+static struct platform_driver sbsa_gwdt_driver = {
+	.driver = {
+		.name = "sbsa-gwdt",
+		.pm = &sbsa_gwdt_pm_ops,
+		.of_match_table = sbsa_gwdt_of_match,
+	},
+	.probe = sbsa_gwdt_probe,
+	.remove = sbsa_gwdt_remove,
+	.shutdown = sbsa_gwdt_shutdown,
+	.id_table = sbsa_gwdt_pdev_match,
+};
+
+module_platform_driver(sbsa_gwdt_driver);
+
+MODULE_DESCRIPTION("SBSA Generic Watchdog Driver");
+MODULE_AUTHOR("Fu Wei <fu.wei at linaro.org>");
+MODULE_AUTHOR("Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>");
+MODULE_AUTHOR("Al Stone <al.stone at linaro.org>");
+MODULE_AUTHOR("Timur Tabi <timur at codeaurora.org>");
+MODULE_LICENSE("GPL v2");
-- 
2.5.0



From ddaney at caviumnetworks.com  Tue Feb  9 09:03:11 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Tue, 9 Feb 2016 09:03:11 -0800
Subject: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
In-Reply-To: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
References: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
Message-ID: <56BA1BCF.8080309@caviumnetworks.com>

On 02/09/2016 03:04 AM, Robin Murphy wrote:
> The existing msi-map code is fine for shifting the entire RID space
> upwards, but attempting finer-grained remapping reveals a bug. It turns
> out that we are mistakenly treating the msi-base part as an offset, not
> as a new base to remap onto, so things get squiffy when rid-base is
> nonzero. Fix this, and at the same time add a sanity check against
> having msi-map-mask clash with a nonzero rid-base, as that's another
> thing one can easily get wrong.
>
> CC: <stable at vger.kernel.org>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>

This is equivalent to what I tested yesterday.  Thanks for fixing it...

Acked-by: David Daney <david.daney at cavium.com>



> ---
>   drivers/of/irq.c | 9 ++++++++-
>   1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 7ee21ae..e7bfc17 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -635,6 +635,13 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
>   		msi_base = be32_to_cpup(msi_map + 2);
>   		rid_len = be32_to_cpup(msi_map + 3);
>
> +		if (rid_base & ~map_mask) {
> +			dev_err(parent_dev,
> +				"Invalid msi-map translation - msi-map-mask (0x%x) ignores rid-base (0x%x)\n",
> +				map_mask, rid_base);
> +			return rid_out;
> +		}
> +
>   		msi_controller_node = of_find_node_by_phandle(phandle);
>
>   		matched = (masked_rid >= rid_base &&
> @@ -654,7 +661,7 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
>   	if (!matched)
>   		return rid_out;
>
> -	rid_out = masked_rid + msi_base;
> +	rid_out = masked_rid - rid_base + msi_base;
>   	dev_dbg(dev,
>   		"msi-map at: %s, using mask %08x, rid-base: %08x, msi-base: %08x, length: %08x, rid: %08x -> %08x\n",
>   		dev_name(parent_dev), map_mask, rid_base, msi_base,
>



From Tirumalesh.Chalamarla at caviumnetworks.com  Tue Feb  9 09:07:47 2016
From: Tirumalesh.Chalamarla at caviumnetworks.com (Chalamarla, Tirumalesh)
Date: Tue, 9 Feb 2016 17:07:47 +0000
Subject: [PATCH] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <56B9D2F4.8070308@arm.com>
References: <1454698027-20911-1-git-send-email-tchalamarla@caviumnetworks.com>
 <56B9D2F4.8070308@arm.com>
Message-ID: <D3352A05-3713-457E-AB65-1DEFB6F9E912@caviumnetworks.com>






On 2/9/16, 3:52 AM, "Robin Murphy" <robin.murphy at arm.com> wrote:

>On 05/02/16 18:47, tchalamarla at caviumnetworks.com wrote:
>> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>>
>> An issue exists whereby the Linux kernel requires that ASIDs are a
>> unique namespace per SMMU.
>
>I too tend to consider the SMMUv2 architecture an "issue", but we should 
>probably still call it by its name ;)
>
>>  That ASID-local choice conflicts with the
>> CN88xx SMMU, where only shared ASID namespaces are supported;
>> specifically within a given node SMMU0 and SMMU1 share, as does SMMU2
>> and SMMU3. CN88xx SMMU also requires global VMIDs.
>
>"Global" meaning unique across all 4 SMMUs? Or just unique across each 
>pair as per ASIDs?...
>
>> This patch tries to address these issuee by supplying asid and vmid
>> transformations from devicetree.
>>
>> Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
>> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>> ---
>>   .../devicetree/bindings/iommu/arm,smmu.txt         | 16 ++++++
>>   drivers/iommu/arm-smmu.c                           | 59 ++++++++++++++++++----
>>   2 files changed, 65 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> index 7180745..eef06d0 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> @@ -55,6 +55,22 @@ conditions.
>>                     aliases of secure registers have to be used during
>>                     SMMU configuration.
>>
>> +- thunderx,smmu-asid-transform	: Enable proper handling for buggy
>> +		  implementations that require special transformations
>> +		  for smmu asid. if this property exists asid-transform
>> +		  property must be present.
>> +
>> +- thunderx,smmu-vmid-transform	: Enable proper handling for buggy
>> +		  implementations that require special transformations
>> +		  for smmu vmid. if this property exists vmid-transform
>> +		  property must be present.
>> +
>> +- asid-transform 	: Transform mask that needs to be applied to asid.
>> +			This property has to be specified as '/bits/ 8' value.
>> +
>> +- vmid-transform 	: Transform mask that needs to be applied to vmid.
>> +			This property has to be specified as '/bits/ 8' value.
>> +
>
>...because I've seen a ThunderX boot log indicating 4x128 context banks, 
>and I don't see how applying an 8-bit mask to an 8-bit value is going to 
>produce anything _globally_ unique in that case.
>
>Regardless, I'm not sure this is an accurate description of the hardware 
>as DT should be - this is more implying that each SMMU _requires_ a 
>particular set of ASIDs/VMIDs to be used, which is not the same thing 
>that the commit message and other comments say.

I am rewriting this patch to include additional patches to support 16bit VMID and ASID. Will rebase this patch on top of it.
Though for 128 bit 7 bits are sufficient I thought it is still good idea to have this on top of 16bit VMID and ASID. 
>
>Robin.
>
>>   Example:
>>
>>           smmu {
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 59ee4b8..8047834 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -300,8 +300,12 @@ struct arm_smmu_device {
>>   	u32				features;
>>
>>   #define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
>> +#define ARM_SMMU_OPT_TRANSFORM_ASID	(1 << 1)
>> +#define ARM_SMMU_OPT_TRANSFORM_VMID	(1 << 2)
>>   	u32				options;
>>   	enum arm_smmu_arch_version	version;
>> +	u8				asid_transform;
>> +	u8				vmid_transform;
>>
>>   	u32				num_context_banks;
>>   	u32				num_s2_context_banks;
>> @@ -330,8 +334,25 @@ struct arm_smmu_cfg {
>>   };
>>   #define INVALID_IRPTNDX			0xff
>>
>> -#define ARM_SMMU_CB_ASID(cfg)		((cfg)->cbndx)
>> -#define ARM_SMMU_CB_VMID(cfg)		((cfg)->cbndx + 1)
>> +/*
>> + * ThunderX has a unique requirement because of ERRATA#27704
>> + * An issue exists whereby the Linux kernel requires that ASIDs are a
>> + * unique namespace per SMMU.  That ASID-local choice conflicts with the
>> + * CN88xx SMMU, where only shared ASID namespaces are supported;
>> + * specifically within a given node SMMU0 and SMMU1 share, as does SMMU2
>> + * and SMMU3.
>> + * CN88xx SMMU also requires global VMIDs.
>> + */
>> +
>> +#define ARM_SMMU_CB_ASID(smmu, cfg)					\
>> +		(((smmu)->options & ARM_SMMU_OPT_TRANSFORM_ASID)	\
>> +		? ((cfg)->cbndx | (smmu)->asid_transform)		\
>> +		: ((cfg)->cbndx))
>> +
>> +#define ARM_SMMU_CB_VMID(smmu, cfg)					\
>> +		(((smmu)->options & ARM_SMMU_OPT_TRANSFORM_VMID)	\
>> +		? (((cfg)->cbndx + 1) | (smmu)->vmid_transform)		\
>> +		: ((cfg)->cbndx + 1))
>>
>>   enum arm_smmu_domain_stage {
>>   	ARM_SMMU_DOMAIN_S1 = 0,
>> @@ -361,6 +382,8 @@ struct arm_smmu_option_prop {
>>
>>   static struct arm_smmu_option_prop arm_smmu_options[] = {
>>   	{ ARM_SMMU_OPT_SECURE_CFG_ACCESS, "calxeda,smmu-secure-config-access" },
>> +	{ ARM_SMMU_OPT_TRANSFORM_ASID, "thunderx,smmu-asid-transform" },
>> +	{ ARM_SMMU_OPT_TRANSFORM_VMID, "thunderx,smmu-vmid-transform" },
>>   	{ 0, NULL},
>>   };
>>
>> @@ -570,11 +593,11 @@ static void arm_smmu_tlb_inv_context(void *cookie)
>>
>>   	if (stage1) {
>>   		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
>> -		writel_relaxed(ARM_SMMU_CB_ASID(cfg),
>> +		writel_relaxed(ARM_SMMU_CB_ASID(smmu, cfg),
>>   			       base + ARM_SMMU_CB_S1_TLBIASID);
>>   	} else {
>>   		base = ARM_SMMU_GR0(smmu);
>> -		writel_relaxed(ARM_SMMU_CB_VMID(cfg),
>> +		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg),
>>   			       base + ARM_SMMU_GR0_TLBIVMID);
>>   	}
>>
>> @@ -596,7 +619,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>>
>>   		if (!IS_ENABLED(CONFIG_64BIT) || smmu->version == ARM_SMMU_V1) {
>>   			iova &= ~12UL;
>> -			iova |= ARM_SMMU_CB_ASID(cfg);
>> +			iova |= ARM_SMMU_CB_ASID(smmu, cfg);
>>   			do {
>>   				writel_relaxed(iova, reg);
>>   				iova += granule;
>> @@ -604,7 +627,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>>   #ifdef CONFIG_64BIT
>>   		} else {
>>   			iova >>= 12;
>> -			iova |= (u64)ARM_SMMU_CB_ASID(cfg) << 48;
>> +			iova |= (u64)ARM_SMMU_CB_ASID(smmu, cfg) << 48;
>>   			do {
>>   				writeq_relaxed(iova, reg);
>>   				iova += granule >> 12;
>> @@ -624,7 +647,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>>   #endif
>>   	} else {
>>   		reg = ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_TLBIVMID;
>> -		writel_relaxed(ARM_SMMU_CB_VMID(cfg), reg);
>> +		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg), reg);
>>   	}
>>   }
>>
>> @@ -752,7 +775,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>>   		reg |= (CBAR_S1_BPSHCFG_NSH << CBAR_S1_BPSHCFG_SHIFT) |
>>   			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
>>   	} else {
>> -		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
>> +		reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBAR_VMID_SHIFT;
>>   	}
>>   	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
>>
>> @@ -760,11 +783,11 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>>   	if (stage1) {
>>   		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>>
>> -		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
>> +		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
>>   		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR0);
>>
>>   		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
>> -		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
>> +		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
>>   		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR1);
>>   	} else {
>>   		reg64 = pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
>> @@ -1793,6 +1816,22 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
>>
>>   	parse_driver_options(smmu);
>>
>> +	if (smmu->options & ARM_SMMU_OPT_TRANSFORM_ASID) {
>> +		if (of_property_read_u8(dev->of_node, "#asid-transform",
>> +					 &smmu->asid_transform)) {
>> +			dev_err(dev, "missing #asid-transform property\n");
>> +			return -ENODEV;
>> +		}
>> +	}
>> +
>> +	if (smmu->options & ARM_SMMU_OPT_TRANSFORM_VMID) {
>> +		if (of_property_read_u8(dev->of_node, "#vmid-transform",
>> +					 &smmu->vmid_transform)) {
>> +			dev_err(dev, "missing #vmid-transform property\n");
>> +			return -ENODEV;
>> +		}
>> +	}
>> +
>>   	if (smmu->version > ARM_SMMU_V1 &&
>>   	    smmu->num_context_banks != smmu->num_context_irqs) {
>>   		dev_err(dev,
>>
>

From maxime.ripard at free-electrons.com  Tue Feb  9 09:10:40 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 9 Feb 2016 18:10:40 +0100
Subject: [PATCH v3 1/5] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <20160205115837.GD12071@box2.japko.eu>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-2-git-send-email-k@japko.eu>
 <20160204154752.4df7808be3364a98c496c030@free.fr>
 <20160205111152.GA31506@lukather>
 <20160205115837.GD12071@box2.japko.eu>
Message-ID: <20160209171040.GR31506@lukather>

On Fri, Feb 05, 2016 at 12:58:37PM +0100, Krzysztof Adamski wrote:
> On Fri, Feb 05, 2016 at 12:11:52PM +0100, Maxime Ripard wrote:
> >Hi,
> >
> >On Thu, Feb 04, 2016 at 03:47:52PM +0100, Jean-Francois Moine wrote:
> >>On Thu,  4 Feb 2016 00:33:46 +0100
> >>Krzysztof Adamski <k at japko.eu> wrote:
> >>
> >>> This patch adds support for APB0 in H3. It seems to be compatible with
> >>> earlier SOCs. apb0 gates controls R_ block peripherals (R_PIO, R_IR,
> >>> etc).
> >>>
> >>> Signed-off-by: Krzysztof Adamski <k at japko.eu>
> >>> ---
> >>>  Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
> >>>  drivers/clk/sunxi/clk-simple-gates.c              | 2 ++
> >>>  2 files changed, 3 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> >>> index e59f57b..751c8b9f0 100644
> >>> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> >>> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> >>> @@ -45,6 +45,7 @@ Required properties:
> >>>  	"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
> >>>  	"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
> >>>  	"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
> >>> +	"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
> >>>  	"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
> >>>  	"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
> >>>  	"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
> >>> diff --git a/drivers/clk/sunxi/clk-simple-gates.c b/drivers/clk/sunxi/clk-simple-gates.c
> >>> index f4da52b..6753c87 100644
> >>> --- a/drivers/clk/sunxi/clk-simple-gates.c
> >>> +++ b/drivers/clk/sunxi/clk-simple-gates.c
> >>> @@ -130,6 +130,8 @@ CLK_OF_DECLARE(sun8i_a23_apb2, "allwinner,sun8i-a23-apb2-gates-clk",
> >>>  	       sunxi_simple_gates_init);
> >>>  CLK_OF_DECLARE(sun8i_a33_ahb1, "allwinner,sun8i-a33-ahb1-gates-clk",
> >>>  	       sunxi_simple_gates_init);
> >>> +CLK_OF_DECLARE(sun8i_h3_apb0, "allwinner,sun8i-h3-apb0-gates-clk",
> >>> +	       sunxi_simple_gates_init);
> >>>  CLK_OF_DECLARE(sun9i_a80_ahb0, "allwinner,sun9i-a80-ahb0-gates-clk",
> >>>  	       sunxi_simple_gates_init);
> >>>  CLK_OF_DECLARE(sun9i_a80_ahb1, "allwinner,sun9i-a80-ahb1-gates-clk",
> >>
> >>It seems that the other compatible strings are there for historical
> >>reasons. Why do you need a new one with such a specific name?
> >>
> >>It would have been more sensible to add a generic compatible string as
> >>"allwinner,apb-gates", letting the removal of the other strings for a
> >>later patch...
> >
> >Yeah, it's a good idea, and it's probably time that we move to that.
> >
> >However, I'd like to keep per-soc and per-clocks compatibles in the
> >DT, in case we need to protect a clock in the future. That doesn't
> >prevent to have two compatibles thoughe, the specific and the generic.
> >
> 
> So now I'm not sure what you mean. You suggest that I should keep using
> specific (sun8i_h3_apb0) or change to generic (apb-gates) in my patch?

Both.

To have something like that:

compatible = "allwinner,sun8i-h3-apb0-gates-clk", "allwinner,sun4i-a10-gates-clk";

sun4i-a10-gates-clk being the generic compatible that we would use,
and we can always match against the h3 specific compatible if we need
to have a different behaviour.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/f1daa01c/attachment-0001.sig>

From maxime.ripard at free-electrons.com  Tue Feb  9 09:11:01 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 9 Feb 2016 18:11:01 +0100
Subject: [PATCH v3 1/5] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <20160206112605.4005784d1d0962c8adfe58a0@free.fr>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-2-git-send-email-k@japko.eu>
 <20160204154752.4df7808be3364a98c496c030@free.fr>
 <20160205111152.GA31506@lukather>
 <20160206112605.4005784d1d0962c8adfe58a0@free.fr>
Message-ID: <20160209171101.GS31506@lukather>

On Sat, Feb 06, 2016 at 11:26:05AM +0100, Jean-Francois Moine wrote:
> On Fri, 5 Feb 2016 12:11:52 +0100
> Maxime Ripard <maxime.ripard at free-electrons.com> wrote:
> 
> > However, I'd like to keep per-soc and per-clocks compatibles in the
> > DT, in case we need to protect a clock in the future.
> 
> What do you mean by "protect a clock"?

Prevent it from shutting down.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/4fa6d3c3/attachment.sig>

From maxime.ripard at free-electrons.com  Tue Feb  9 09:12:15 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 9 Feb 2016 18:12:15 +0100
Subject: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
In-Reply-To: <56B8BB1A.8010705@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-6-git-send-email-andre.przywara@arm.com>
 <20160201182754.GA14737@excalibur.cnev.de>
 <56AFE0EC.8080207@arm.com> <20160202100046.GM4652@lukather>
 <56B0DF26.10203@arm.com> <20160204165151.GK4270@lukather>
 <20160208155405.GA4677@rob-hp-laptop> <56B8BB1A.8010705@arm.com>
Message-ID: <20160209171215.GT31506@lukather>

On Mon, Feb 08, 2016 at 03:58:18PM +0000, Andre Przywara wrote:
> Hi,
> 
> On 08/02/16 15:54, Rob Herring wrote:
> > On Thu, Feb 04, 2016 at 05:51:51PM +0100, Maxime Ripard wrote:
> >> Hi Andre,
> >>
> >> On Tue, Feb 02, 2016 at 04:53:58PM +0000, Andre Przywara wrote:
> >>>> So, droping it in the filenames, why not. But I'd really like to keep
> >>>> the same compatible scheme.
> >>>
> >>> And I still don't get this: in the DT compatible scheme we always have a
> >>> vendor prefix, so allwinner,a64 is surely not a mysterious ARM Ltd. core
> >>> or a new Apple SoC. Instead it is the A64 from Allwinner, full stop. So
> >>> why should we add an arbitrary and confusing sun50i naming to it (when
> >>> it actually should be more like "sun8i-a64").
> >>
> >> I don't decide on their marketing names. And I know you want to start
> >> anew with the arm64 SoCs, but the truth is, you don't. Most of the
> >> compatibles in the DTSI are from earlier SoCs, and we have to keep
> >> that legacy and remain consistent with it. With all the good and bad
> >> things a legacy imply.
> > 
> > I have to agree. Unless there is some agreement to move to another 
> > naming scheme, then just follow the same pattern. If sunXi is just a 
> > made up name outside of Allwinner to provide some logical grouping of 
> > SoCs, then yes, that probably should not have been done.
> 
> So I still don't like it, but will not waste my time or energy on that
> front.
> 
> Maxime, do you want "allwinner,sun50i-a64" or would
> "allwinner,sunxi-a64" be OK as well?

The former will be fine.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/d2a5e77d/attachment.sig>

From yang.shi at linaro.org  Tue Feb  9 09:17:12 2016
From: yang.shi at linaro.org (Shi, Yang)
Date: Tue, 9 Feb 2016 09:17:12 -0800
Subject: [PATCH v2] arm64: disable kasan when accessing frame->fp in
 unwind_frame
In-Reply-To: <20160209165414.GT22874@arm.com>
References: <1454951589-18238-1-git-send-email-yang.shi@linaro.org>
 <20160209165414.GT22874@arm.com>
Message-ID: <56BA1F18.2020103@linaro.org>

On 2/9/2016 8:54 AM, Will Deacon wrote:
> On Mon, Feb 08, 2016 at 09:13:09AM -0800, Yang Shi wrote:
>> When boot arm64 kernel with KASAN enabled, the below error is reported by
>> kasan:
>>
>> BUG: KASAN: out-of-bounds in unwind_frame+0xec/0x260 at addr ffffffc064d57ba0
>> Read of size 8 by task pidof/499
>> page:ffffffbdc39355c0 count:0 mapcount:0 mapping:          (null) index:0x0
>> flags: 0x0()
>> page dumped because: kasan: bad access detected
>> CPU: 2 PID: 499 Comm: pidof Not tainted 4.5.0-rc1 #119
>> Hardware name: Freescale Layerscape 2085a RDB Board (DT)
>> Call trace:
>> [<ffffffc00008d078>] dump_backtrace+0x0/0x290
>> [<ffffffc00008d32c>] show_stack+0x24/0x30
>> [<ffffffc0006a981c>] dump_stack+0x8c/0xd8
>> [<ffffffc0002e4400>] kasan_report_error+0x558/0x588
>> [<ffffffc0002e4958>] kasan_report+0x60/0x70
>> [<ffffffc0002e3188>] __asan_load8+0x60/0x78
>> [<ffffffc00008c92c>] unwind_frame+0xec/0x260
>> [<ffffffc000087e60>] get_wchan+0x110/0x160
>> [<ffffffc0003b647c>] do_task_stat+0xb44/0xb68
>> [<ffffffc0003b7730>] proc_tgid_stat+0x40/0x50
>> [<ffffffc0003ac840>] proc_single_show+0x88/0xd8
>> [<ffffffc000345be8>] seq_read+0x370/0x770
>> [<ffffffc00030aba0>] __vfs_read+0xc8/0x1d8
>> [<ffffffc00030c0ec>] vfs_read+0x94/0x168
>> [<ffffffc00030d458>] SyS_read+0xb8/0x128
>> [<ffffffc000086530>] el0_svc_naked+0x24/0x28
>> Memory state around the buggy address:
>>   ffffffc064d57a80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4
>>   ffffffc064d57b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> ffffffc064d57b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>                                    ^
>>   ffffffc064d57c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>   ffffffc064d57c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>
>> Since the shadow byte pointed by the report is 0, so it may mean it is just hit
>> oob in non-current task. So, disable the instrumentation to silence these
>> warnings.
>
> Curious, but how did you trigger this? I'm just trying to confirm that
> mainline is affected, but my machine boots happily with KASAN and STACKTRACE
> selected and I can cat /proc/self/{stack,stat} quite happily.
>
> What am I missing?

I'm using mainline 4.5-rc1 kernel with gcc 5.2. And, my rootfs is NFS 
mounted.

Not sure if other kernel configs, i.e tracing stuff will have impact on 
the trigger since I'm not using the defconfig.

Thanks,
Yang

>
> Will
>



From will.deacon at arm.com  Tue Feb  9 09:20:58 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Feb 2016 17:20:58 +0000
Subject: [PATCH v4 0/7] arm64: Verify early CPU features
In-Reply-To: <1453745225-27736-1-git-send-email-suzuki.poulose@arm.com>
References: <1453745225-27736-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <20160209172057.GU22874@arm.com>

On Mon, Jan 25, 2016 at 06:06:58PM +0000, Suzuki K Poulose wrote:
> From: Suzuki K. Poulose <suzuki.poulose at arm.com>
> 
> This series adds support for verifying some of the cpufeatures
> that are decided early in the boot process based on the boot
> CPU and cannot be delayed until all the CPUs are up (e.g, ASIDBits
> and may be VHE?). It also adds support for handling the failures
> in booting the secondary CPUs which could not be synchronised
> with the master CPU, otherwise.
> 
> It also adds one of the users of this early hook, check for ASIDBits.
> The mm_context id is based on the ASIDBits width supported by the
> boot CPU and is used early in the initialisation. So we need to make
> sure that all the secondary CPUs supports the width reported by the
> booting CPU, failing which we crash the system.
> 
> This series has been tested on Juno, Fast model by injecting smaller
> ASIDBits, lack of page-size support and missing features(PAN)

Module the comments from Mark and Catalin on patch 4, the rest looks
good to me:

Acked-by: Will Deacon <will.deacon at arm.com>

Will


From mathieu.poirier at linaro.org  Tue Feb  9 09:06:18 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 9 Feb 2016 10:06:18 -0700
Subject: [PATCH V2 3/6] stm class: provision for statically assigned
 masterIDs
In-Reply-To: <AM4PR08MB0785EAA2B628765D7EA3FDA086D50@AM4PR08MB0785.eurprd08.prod.outlook.com>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
 <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org>
 <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com>
 <CANLsYky2twQ98u241YyHD=atYRp1N56YVHUQNY2E2Ljsq0cseA@mail.gmail.com>
 <87twlj49k7.fsf@ashishki-desk.ger.corp.intel.com>
 <CANLsYkw=mG+ch8QzxmbwWs9o+mndVNo1MuqXcrPrNJYj_SQcHQ@mail.gmail.com>
 <AM4PR08MB0785EAA2B628765D7EA3FDA086D50@AM4PR08MB0785.eurprd08.prod.outlook.com>
Message-ID: <CANLsYkzJEsq-jZAZu6xjwP+UhxJHehgpVB0s0oi8wkYksRwDMA@mail.gmail.com>

On 8 February 2016 at 10:44, Al Grant <Al.Grant at arm.com> wrote:
>> Mike did write "master IDs are hardwired to individual cores and core security
>> states", which make assignment for one platform very static.
>> On the flip side those will change from one system to another.
>
> It depends on your perspective.  From the perspective of a userspace
> process not pinned to a core, the master id will appear to vary
> dynamically and unpredictably as the thread migrates from one
> core to another.  (That's actually useful if the decoder wants to know
> where the thread is running at any given point, as it can find that out
> for free, without the need to track migration events.)

Right, that's the expected (and desired) behaviour.

>
> On the other hand if you are pinned (e.g. you're the kernel on a
> particular core, or you're a per-core worker thread in some thread
> pooling system) then you have a fixed master id, and then you can
> have one instance per core all using the same range of channel
> numbers, with the master id indicating the core - this saves on
> channel space compared to having to give each core its own
> range of channel space.

>From an STM core and driver point of view channel mapping works the
same way - pinning of tasks is  a kernel artefact.  The problem of
representing masterIDs in the STM core for an architecture with HW
assigned masterIDs is still unresolved.

>
> Al
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


From will.deacon at arm.com  Tue Feb  9 09:23:11 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Feb 2016 17:23:11 +0000
Subject: [PATCH v2] arm64: disable kasan when accessing frame->fp in
 unwind_frame
In-Reply-To: <56BA1F18.2020103@linaro.org>
References: <1454951589-18238-1-git-send-email-yang.shi@linaro.org>
 <20160209165414.GT22874@arm.com> <56BA1F18.2020103@linaro.org>
Message-ID: <20160209172310.GV22874@arm.com>

On Tue, Feb 09, 2016 at 09:17:12AM -0800, Shi, Yang wrote:
> On 2/9/2016 8:54 AM, Will Deacon wrote:
> >On Mon, Feb 08, 2016 at 09:13:09AM -0800, Yang Shi wrote:
> >>When boot arm64 kernel with KASAN enabled, the below error is reported by
> >>kasan:
> >>
> >>BUG: KASAN: out-of-bounds in unwind_frame+0xec/0x260 at addr ffffffc064d57ba0
> >>Read of size 8 by task pidof/499
> >>page:ffffffbdc39355c0 count:0 mapcount:0 mapping:          (null) index:0x0
> >>flags: 0x0()
> >>page dumped because: kasan: bad access detected
> >>CPU: 2 PID: 499 Comm: pidof Not tainted 4.5.0-rc1 #119
> >>Hardware name: Freescale Layerscape 2085a RDB Board (DT)
> >>Call trace:
> >>[<ffffffc00008d078>] dump_backtrace+0x0/0x290
> >>[<ffffffc00008d32c>] show_stack+0x24/0x30
> >>[<ffffffc0006a981c>] dump_stack+0x8c/0xd8
> >>[<ffffffc0002e4400>] kasan_report_error+0x558/0x588
> >>[<ffffffc0002e4958>] kasan_report+0x60/0x70
> >>[<ffffffc0002e3188>] __asan_load8+0x60/0x78
> >>[<ffffffc00008c92c>] unwind_frame+0xec/0x260
> >>[<ffffffc000087e60>] get_wchan+0x110/0x160
> >>[<ffffffc0003b647c>] do_task_stat+0xb44/0xb68
> >>[<ffffffc0003b7730>] proc_tgid_stat+0x40/0x50
> >>[<ffffffc0003ac840>] proc_single_show+0x88/0xd8
> >>[<ffffffc000345be8>] seq_read+0x370/0x770
> >>[<ffffffc00030aba0>] __vfs_read+0xc8/0x1d8
> >>[<ffffffc00030c0ec>] vfs_read+0x94/0x168
> >>[<ffffffc00030d458>] SyS_read+0xb8/0x128
> >>[<ffffffc000086530>] el0_svc_naked+0x24/0x28
> >>Memory state around the buggy address:
> >>  ffffffc064d57a80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4
> >>  ffffffc064d57b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>>ffffffc064d57b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>                                   ^
> >>  ffffffc064d57c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>  ffffffc064d57c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >>
> >>Since the shadow byte pointed by the report is 0, so it may mean it is just hit
> >>oob in non-current task. So, disable the instrumentation to silence these
> >>warnings.
> >
> >Curious, but how did you trigger this? I'm just trying to confirm that
> >mainline is affected, but my machine boots happily with KASAN and STACKTRACE
> >selected and I can cat /proc/self/{stack,stat} quite happily.
> >
> >What am I missing?
> 
> I'm using mainline 4.5-rc1 kernel with gcc 5.2. And, my rootfs is NFS
> mounted.
> 
> Not sure if other kernel configs, i.e tracing stuff will have impact on the
> trigger since I'm not using the defconfig.

If you could put your .config somewhere, that would be helpful, please.

Will


From tony at atomide.com  Tue Feb  9 09:24:04 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 9 Feb 2016 09:24:04 -0800
Subject: N900 sleep mode (in 4.5-rc0, if that matters)
In-Reply-To: <20160207212316.GA6147@amd>
References: <20160125163332.GT19432@atomide.com> <20160126140010.GA29723@amd>
 <20160126172527.GY3500@atomide.com> <20160130200244.GA30429@amd>
 <20160130201452.GC30429@amd> <20160130221509.GA28644@amd>
 <20160201181316.GM19432@atomide.com> <20160201211736.GA11283@amd>
 <20160201221111.GP19432@atomide.com> <20160207212316.GA6147@amd>
Message-ID: <20160209172403.GK19432@atomide.com>

* Pavel Machek <pavel at ucw.cz> [160207 13:24]:
> Hi!
> 
> > > (I assume I have to insmod and rmmod, right? Because powersave is not
> > > entered if I simply compile-out usb).
> > 
> > Depending on what the bootloader does and probably also if
> > USB was used during the booting.. So yeah you may need to modprobe
> > and then rmmod.
> > 
> > > Would you have commit ids for those rmmod fixes? It might be good to
> > > push them into stable, and I should try again with them applied...
> > 
> > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications")
> > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable")
> 
> Ok, with that, I can insmod and rmmod. But I still get:
> 
> 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000

I think the cm_idlest_per is fine.

> ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042
> 0000000d 48004a28 (fa004a28) cm_idlest3_core

Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go
down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ?

If not, the're PM runtime missing or broken somewhere.

FYI, below is my omap3 usb test script that I use to start and
stop USB, it also works on n900. And after stopping it n900
continues hitting deeper idle states just fine.

That is with these two phy patches applied on v4.5-rc3:

"phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload")
"phy: twl4030-usb: Relase usb phy on unload")

Maybe I gave you wrong info on the USB patches needed.. But these
two above are needed on v4.5-rc3. And looks like Kishon has now
applied them.

Oh and I also have the MMC PM runtime regression fix here that I
have not yet posted. Will post today. But I guess you're on
v4.4 right now still.

Regards,

Tony

8< --------
#!/bin/bash

# Change for your UDC controller
phy_module=phy_twl4030_usb
udc_glue=omap2430
udc_module=musb_hdrc
udc_name=musb-hdrc.0.auto

start_usb_gadgets() {
	vendor=0x1d6b
	product=0x0106
	file=$1
  
	mount -t configfs none /sys/kernel/config
	mkdir /sys/kernel/config/usb_gadget/g1
	old_pwd=$(pwd)
	cd /sys/kernel/config/usb_gadget/g1
	
	echo $product > idProduct
	echo $vendor > idVendor
	mkdir strings/0x409
	echo 123456789 > strings/0x409/serialnumber
	echo foo > strings/0x409/manufacturer
	echo "Multi Gadget" > strings/0x409/product
	
	mkdir configs/c.1
	echo 100 > configs/c.1/MaxPower
	mkdir configs/c.1/strings/0x409
	echo "Config 100mA" > configs/c.1/strings/0x409/configuration
	
	mkdir configs/c.5
	echo 500 > configs/c.5/MaxPower
	mkdir configs/c.5/strings/0x409
	echo "Config 500mA" > configs/c.5/strings/0x409/configuration

	mkdir functions/mass_storage.0
	echo $file > functions/mass_storage.0/lun.0/file
	ln -s functions/mass_storage.0 configs/c.1
	ln -s functions/mass_storage.0 configs/c.5

	mkdir functions/acm.0
	ln -s functions/acm.0 configs/c.1
	ln -s functions/acm.0 configs/c.5

	mkdir functions/ecm.0
	ln -s functions/ecm.0 configs/c.1
	ln -s functions/ecm.0 configs/c.5

	# Adding rndis seems to cause alignment trap or some
	# random oops on reboot after rmmod $udc_glue

	echo $udc_name > /sys/kernel/config/usb_gadget/g1/UDC
	cd $old_pwd
}

stop_usb_gadgets() {
	old_pwd=$(pwd)
	cd /sys/kernel/config/usb_gadget/g1

	echo "" > /sys/kernel/config/usb_gadget/g1/UDC

	rm configs/c.1/ecm.0
	rm configs/c.5/ecm.0
	rmdir functions/ecm.0

	rm configs/c.1/acm.0
	rm configs/c.5/acm.0
	rmdir functions/acm.0

	echo "" > functions/mass_storage.0/lun.0/file
	rm configs/c.1/mass_storage.0
	rm configs/c.5/mass_storage.0
	rmdir functions/mass_storage.0

	rmmod $udc_glue
	rmmod $phy_module
	rmmod $udc_module

	cd $old_pwd
}

case $1 in
	start)
	modprobe libcomposite
	modprobe $phy_module
	modprobe $udc_glue
	start_usb_gadgets ""
        ;;
	stop)
	stop_usb_gadgets
	;;
        *)
        ;;
esac


From will.deacon at arm.com  Tue Feb  9 09:24:54 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Feb 2016 17:24:54 +0000
Subject: [PATCH 0/4] arm64: cpufeature: Fix sign of feature bits
In-Reply-To: <1453805896-4397-1-git-send-email-suzuki.poulose@arm.com>
References: <1453805896-4397-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <20160209172453.GW22874@arm.com>

On Tue, Jan 26, 2016 at 10:58:12AM +0000, Suzuki K Poulose wrote:
> ARM ARM is getting updated with the guidelines on how to treat the
> feature values for their sign. This series fixes the handling of sign
> based on the new update. Also make the capabilities aware of the sign
> of the feature to use the appropriate helper for extracting the values.

For the series:

Acked-by: Will Deacon <will.deacon at arm.com>

Will


From lorenzo.pieralisi at arm.com  Tue Feb  9 09:28:00 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 9 Feb 2016 17:28:00 +0000
Subject: [PATCH V4 12/23] x86, ia64, pci: Remove ACPI companion device
 from platform specific data.
In-Reply-To: <1454606941-9523-13-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
 <1454606941-9523-13-git-send-email-tn@semihalf.com>
Message-ID: <20160209172800.GB22868@red-moon>

Tomasz,

On Thu, Feb 04, 2016 at 06:28:50PM +0100, Tomasz Nowicki wrote:
> Since PCI core code is setting ACPI companion device for us now,
> platform specific ACPI companion device setting turns out to be dead now.
> Therefore we can get rid of it, including related companion reference
> from PCI sysdata structure.
> 
> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
> Tested-by: Duc Dang <dhdang at apm.com>
> Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
> Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
> Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
> Tested-by: Sinan Kaya <okaya at codeaurora.org>
> ---
>  arch/ia64/hp/common/sba_iommu.c    |  2 +-
>  arch/ia64/include/asm/pci.h        |  1 -
>  arch/ia64/pci/pci.c                | 16 ----------------
>  arch/ia64/sn/kernel/io_acpi_init.c |  4 ++--
>  arch/x86/include/asm/pci.h         |  3 ---
>  arch/x86/pci/acpi.c                | 17 -----------------
>  6 files changed, 3 insertions(+), 40 deletions(-)

This patch has to be squashed with the previous one otherwise it
has bisectability issues (ie the previous patch passes the parent
to the pci_create_root_bus() call so, without this patch applied,
the companion initialization would fail).

Other than that:

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

> diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
> index a6d6190..78e4444 100644
> --- a/arch/ia64/hp/common/sba_iommu.c
> +++ b/arch/ia64/hp/common/sba_iommu.c
> @@ -1981,7 +1981,7 @@ sba_connect_bus(struct pci_bus *bus)
>  	if (PCI_CONTROLLER(bus)->iommu)
>  		return;
>  
> -	handle = acpi_device_handle(PCI_CONTROLLER(bus)->companion);
> +	handle = acpi_device_handle(ACPI_COMPANION(bus->bridge));
>  	if (!handle)
>  		return;
>  
> diff --git a/arch/ia64/include/asm/pci.h b/arch/ia64/include/asm/pci.h
> index 07039d1..5050748 100644
> --- a/arch/ia64/include/asm/pci.h
> +++ b/arch/ia64/include/asm/pci.h
> @@ -65,7 +65,6 @@ extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
>  #define pci_legacy_write platform_pci_legacy_write
>  
>  struct pci_controller {
> -	struct acpi_device *companion;
>  	void *iommu;
>  	int segment;
>  	int node;		/* nearest node with memory or NUMA_NO_NODE for global allocation */
> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
> index 8f6ac2f..978d6af 100644
> --- a/arch/ia64/pci/pci.c
> +++ b/arch/ia64/pci/pci.c
> @@ -301,28 +301,12 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
>  	}
>  
>  	info->controller.segment = root->segment;
> -	info->controller.companion = device;
>  	info->controller.node = acpi_get_node(device->handle);
>  	INIT_LIST_HEAD(&info->io_resources);
>  	return acpi_pci_root_create(root, &pci_acpi_root_ops,
>  				    &info->common, &info->controller);
>  }
>  
> -int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
> -{
> -	/*
> -	 * We pass NULL as parent to pci_create_root_bus(), so if it is not NULL
> -	 * here, pci_create_root_bus() has been called by someone else and
> -	 * sysdata is likely to be different from what we expect.  Let it go in
> -	 * that case.
> -	 */
> -	if (!bridge->dev.parent) {
> -		struct pci_controller *controller = bridge->bus->sysdata;
> -		ACPI_COMPANION_SET(&bridge->dev, controller->companion);
> -	}
> -	return 0;
> -}
> -
>  void pcibios_fixup_device_resources(struct pci_dev *dev)
>  {
>  	int idx;
> diff --git a/arch/ia64/sn/kernel/io_acpi_init.c b/arch/ia64/sn/kernel/io_acpi_init.c
> index 0640739..bcfddc2 100644
> --- a/arch/ia64/sn/kernel/io_acpi_init.c
> +++ b/arch/ia64/sn/kernel/io_acpi_init.c
> @@ -132,7 +132,7 @@ sn_get_bussoft_ptr(struct pci_bus *bus)
>  	struct acpi_resource_vendor_typed *vendor;
>  
>  
> -	handle = acpi_device_handle(PCI_CONTROLLER(bus)->companion);
> +	handle = acpi_device_handle(ACPI_COMPANION(bus->bridge));
>  	status = acpi_get_vendor_resource(handle, METHOD_NAME__CRS,
>  					  &sn_uuid, &buffer);
>  	if (ACPI_FAILURE(status)) {
> @@ -360,7 +360,7 @@ sn_acpi_get_pcidev_info(struct pci_dev *dev, struct pcidev_info **pcidev_info,
>  	acpi_status status;
>  	struct acpi_buffer name_buffer = { ACPI_ALLOCATE_BUFFER, NULL };
>  
> -	rootbus_handle = acpi_device_handle(PCI_CONTROLLER(dev)->companion);
> +	rootbus_handle = acpi_device_handle(ACPI_COMPANION(dev->bus->bridge));
>          status = acpi_evaluate_integer(rootbus_handle, METHOD_NAME__SEG, NULL,
>                                         &segment);
>          if (ACPI_SUCCESS(status)) {
> diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
> index 4625943..a98c022 100644
> --- a/arch/x86/include/asm/pci.h
> +++ b/arch/x86/include/asm/pci.h
> @@ -14,9 +14,6 @@
>  struct pci_sysdata {
>  	int		domain;		/* PCI domain */
>  	int		node;		/* NUMA node */
> -#ifdef CONFIG_ACPI
> -	struct acpi_device *companion;	/* ACPI companion device */
> -#endif
>  #ifdef CONFIG_X86_64
>  	void		*iommu;		/* IOMMU private data */
>  #endif
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 8e89921..d5086d1 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -341,7 +341,6 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
>  		struct pci_sysdata sd = {
>  			.domain = domain,
>  			.node = node,
> -			.companion = root->device
>  		};
>  
>  		memcpy(bus->sysdata, &sd, sizeof(sd));
> @@ -356,7 +355,6 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
>  		else {
>  			info->sd.domain = domain;
>  			info->sd.node = node;
> -			info->sd.companion = root->device;
>  			bus = acpi_pci_root_create(root, &acpi_pci_root_ops,
>  						   &info->common, &info->sd);
>  		}
> @@ -374,21 +372,6 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
>  	return bus;
>  }
>  
> -int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
> -{
> -	/*
> -	 * We pass NULL as parent to pci_create_root_bus(), so if it is not NULL
> -	 * here, pci_create_root_bus() has been called by someone else and
> -	 * sysdata is likely to be different from what we expect.  Let it go in
> -	 * that case.
> -	 */
> -	if (!bridge->dev.parent) {
> -		struct pci_sysdata *sd = bridge->bus->sysdata;
> -		ACPI_COMPANION_SET(&bridge->dev, sd->companion);
> -	}
> -	return 0;
> -}
> -
>  int __init pci_acpi_init(void)
>  {
>  	struct pci_dev *dev = NULL;
> -- 
> 1.9.1
> 


From steve.muckle at linaro.org  Tue Feb  9 09:30:05 2016
From: steve.muckle at linaro.org (Steve Muckle)
Date: Tue, 9 Feb 2016 09:30:05 -0800
Subject: [PATCH v3 0/6] CPUs capacity information for heterogeneous systems
In-Reply-To: <20160209103748.GP11415@e106622-lin>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <56B92BF4.4030405@linaro.org> <20160209103748.GP11415@e106622-lin>
Message-ID: <56BA221D.1030907@linaro.org>

On 02/09/2016 02:37 AM, Juri Lelli wrote:
>> I'm still concerned that there's no way to obtain optimal boot time on a
>> > heterogeneous system. Either the dynamic benchmarking is enabled, adding
>> > 1 sec, or the benchmarking is skipped, and task distribution on the
>> > heterogeneous CPUs is determined by the platform's CPU numbering and
>> > chance, potentially impacting performance nondeterministically until
>> > userspace sets the correct capacity values via sysfs.
>> > 
>> > I believe you tested the impact on boot time of using equal capacity
>> > values and saw little difference. I'm wondering though, what was the CPU
>> > numbering on that target?
>> > 
>
> My targets (Juno and TC2) had big cluster on 1,2 and little on the
> remaining cpus. Why do you think this might matter?

There's a natural bias in the scheduler AFAIK towards lower-numbered
CPUs since they are typically scanned in numerically ascending order. So
when all capacities are initially defaulted to be the same I think
you'll be more likely to use the lower numbered CPUs.

I'd be curious what the performance penalty is on a b.L system where the
lowest numbered CPUs are small. I don't have such a target but maybe
it's possible to compare booting just with bigs vs just with littles, at
least until userspace intializes and a script can bring up the others,
which is the same point at which capacities could be properly set. That
would give something of an upper bound.

> Anyway, IMHO boot time performance is not what we are targeting here, so
> I wouldn't be too worried about this particular point.

It may not be the most important thing but it is a factor worth
considering - as mentioned earlier there are applications where boot
time is critical such as automotive. It seems unfortunate that actual
performance may be left on the table due to (IMO anyway) a tenuous
concern over DT semantics. But it looks like that may just be my
position :/ .

thanks,
Steve


From heiko at sntech.de  Tue Feb  9 09:29:50 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 09 Feb 2016 18:29:50 +0100
Subject: [PATCH v7 6/9] ARM: dts: add pl330-broken-no-flushp quirk for
 rk3036 SoCs
In-Reply-To: <1453460812-8498-7-git-send-email-wxt@rock-chips.com>
References: <1453460812-8498-1-git-send-email-wxt@rock-chips.com>
 <1453460812-8498-7-git-send-email-wxt@rock-chips.com>
Message-ID: <1488837.V2iXLjBOmC@phil>

Am Freitag, 22. Januar 2016, 19:06:49 schrieb Caesar Wang:
> Pl330 integrated in rk3036 platform that doesn't support
> DMAFLUSHP function. So we add 'arm,pl330-broken-no-flushp' quirk
> for rk3036.
> 
> Signed-off-by: Caesar Wang <wxt at rock-chips.com>

applied the 3 (4/9, 5/9, 6/9) dts patches to my dts32 branch for 4.6
(after fixing the patch subjects to match the general style-convention)


From yang.shi at linaro.org  Tue Feb  9 09:31:21 2016
From: yang.shi at linaro.org (Shi, Yang)
Date: Tue, 9 Feb 2016 09:31:21 -0800
Subject: [PATCH v2] arm64: disable kasan when accessing frame->fp in
 unwind_frame
In-Reply-To: <20160209172310.GV22874@arm.com>
References: <1454951589-18238-1-git-send-email-yang.shi@linaro.org>
 <20160209165414.GT22874@arm.com> <56BA1F18.2020103@linaro.org>
 <20160209172310.GV22874@arm.com>
Message-ID: <56BA2269.1000908@linaro.org>

On 2/9/2016 9:23 AM, Will Deacon wrote:
> On Tue, Feb 09, 2016 at 09:17:12AM -0800, Shi, Yang wrote:
>> On 2/9/2016 8:54 AM, Will Deacon wrote:
>>> On Mon, Feb 08, 2016 at 09:13:09AM -0800, Yang Shi wrote:
>>>> When boot arm64 kernel with KASAN enabled, the below error is reported by
>>>> kasan:
>>>>
>>>> BUG: KASAN: out-of-bounds in unwind_frame+0xec/0x260 at addr ffffffc064d57ba0
>>>> Read of size 8 by task pidof/499
>>>> page:ffffffbdc39355c0 count:0 mapcount:0 mapping:          (null) index:0x0
>>>> flags: 0x0()
>>>> page dumped because: kasan: bad access detected
>>>> CPU: 2 PID: 499 Comm: pidof Not tainted 4.5.0-rc1 #119
>>>> Hardware name: Freescale Layerscape 2085a RDB Board (DT)
>>>> Call trace:
>>>> [<ffffffc00008d078>] dump_backtrace+0x0/0x290
>>>> [<ffffffc00008d32c>] show_stack+0x24/0x30
>>>> [<ffffffc0006a981c>] dump_stack+0x8c/0xd8
>>>> [<ffffffc0002e4400>] kasan_report_error+0x558/0x588
>>>> [<ffffffc0002e4958>] kasan_report+0x60/0x70
>>>> [<ffffffc0002e3188>] __asan_load8+0x60/0x78
>>>> [<ffffffc00008c92c>] unwind_frame+0xec/0x260
>>>> [<ffffffc000087e60>] get_wchan+0x110/0x160
>>>> [<ffffffc0003b647c>] do_task_stat+0xb44/0xb68
>>>> [<ffffffc0003b7730>] proc_tgid_stat+0x40/0x50
>>>> [<ffffffc0003ac840>] proc_single_show+0x88/0xd8
>>>> [<ffffffc000345be8>] seq_read+0x370/0x770
>>>> [<ffffffc00030aba0>] __vfs_read+0xc8/0x1d8
>>>> [<ffffffc00030c0ec>] vfs_read+0x94/0x168
>>>> [<ffffffc00030d458>] SyS_read+0xb8/0x128
>>>> [<ffffffc000086530>] el0_svc_naked+0x24/0x28
>>>> Memory state around the buggy address:
>>>>   ffffffc064d57a80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4
>>>>   ffffffc064d57b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>> ffffffc064d57b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>                                    ^
>>>>   ffffffc064d57c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>   ffffffc064d57c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>
>>>> Since the shadow byte pointed by the report is 0, so it may mean it is just hit
>>>> oob in non-current task. So, disable the instrumentation to silence these
>>>> warnings.
>>>
>>> Curious, but how did you trigger this? I'm just trying to confirm that
>>> mainline is affected, but my machine boots happily with KASAN and STACKTRACE
>>> selected and I can cat /proc/self/{stack,stat} quite happily.
>>>
>>> What am I missing?
>>
>> I'm using mainline 4.5-rc1 kernel with gcc 5.2. And, my rootfs is NFS
>> mounted.
>>
>> Not sure if other kernel configs, i.e tracing stuff will have impact on the
>> trigger since I'm not using the defconfig.
>
> If you could put your .config somewhere, that would be helpful, please.

Attached it. BTW, I run the test on LS2085a RDB board which has 8 A57 
cores. Not sure if it could be reproduced on other boards easily.

Yang

>
> Will
>

-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm64 4.5.0-rc1 Kernel Configuration
#
CONFIG_ARM64=y
CONFIG_64BIT=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=18
CONFIG_ARCH_MMAP_RND_BITS_MAX=24
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CSUM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ZONE_DMA=y
CONFIG_HAVE_GENERIC_RCU_GUP=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_SMP=y
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
CONFIG_KERNEL_MODE_NEON=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_HANDLE_DOMAIN_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
CONFIG_NO_HZ_FULL_ALL=y
# CONFIG_NO_HZ_FULL_SYSIDLE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_CONTEXT_TRACKING=y
CONFIG_CONTEXT_TRACKING_FORCE=y
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
CONFIG_RCU_KTHREAD_PRIO=0
CONFIG_RCU_NOCB_CPU=y
CONFIG_RCU_NOCB_CPU_NONE=y
# CONFIG_RCU_NOCB_CPU_ZERO is not set
# CONFIG_RCU_NOCB_CPU_ALL is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_GENERIC_SCHED_CLOCK=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_WRITEBACK=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_CGROUP_PIDS is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_HUGETLB is not set
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_DEBUG=y
CONFIG_CHECKPOINT_RESTORE=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
CONFIG_SYSFS_SYSCALL=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_BPF_SYSCALL=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
CONFIG_USERFAULTFD=y
CONFIG_PCI_QUIRKS=y
CONFIG_MEMBARRIER=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_SLUB_CPU_PARTIAL=y
# CONFIG_SYSTEM_DATA_VERIFICATION is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
# CONFIG_JUMP_LABEL is not set
# CONFIG_UPROBES is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_HAVE_RCU_TABLE_FREE=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_NONE is not set
CONFIG_CC_STACKPROTECTOR_REGULAR=y
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_MODULES_USE_ELF_RELA=y
CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
CONFIG_HAVE_ARCH_MMAP_RND_BITS=y
CONFIG_ARCH_MMAP_RND_BITS=18
CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y
CONFIG_ARCH_MMAP_RND_COMPAT_BITS=11
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_COMPAT_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
CONFIG_GCOV_KERNEL=y
CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
CONFIG_GCOV_PROFILE_ALL=y
CONFIG_GCOV_FORMAT_AUTODETECT=y
# CONFIG_GCOV_FORMAT_3_4 is not set
# CONFIG_GCOV_FORMAT_4_7 is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
# CONFIG_MODULE_COMPRESS is not set
CONFIG_MODULES_TREE_LOOKUP=y
CONFIG_BLOCK=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
# CONFIG_BLK_DEV_THROTTLING is not set
# CONFIG_BLK_CMDLINE_PARSER is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_EFI_PARTITION=y
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_CFQ_GROUP_IOSCHED is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
CONFIG_RWSEM_SPIN_ON_OWNER=y
CONFIG_LOCK_SPIN_ON_OWNER=y
CONFIG_FREEZER=y

#
# Platform selection
#
# CONFIG_ARCH_BCM_IPROC is not set
# CONFIG_ARCH_BERLIN is not set
# CONFIG_ARCH_EXYNOS7 is not set
CONFIG_ARCH_LAYERSCAPE=y
# CONFIG_ARCH_HISI is not set
# CONFIG_ARCH_MEDIATEK is not set
# CONFIG_ARCH_QCOM is not set
# CONFIG_ARCH_ROCKCHIP is not set
# CONFIG_ARCH_SEATTLE is not set
# CONFIG_ARCH_RENESAS is not set
# CONFIG_ARCH_STRATIX10 is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_SPRD is not set
# CONFIG_ARCH_THUNDER is not set
# CONFIG_ARCH_UNIPHIER is not set
# CONFIG_ARCH_VEXPRESS is not set
# CONFIG_ARCH_XGENE is not set
# CONFIG_ARCH_ZYNQMP is not set

#
# Bus support
#
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCI_DOMAINS_GENERIC=y
CONFIG_PCI_SYSCALL=y
CONFIG_PCI_BUS_ADDR_T_64BIT=y
CONFIG_PCI_MSI=y
CONFIG_PCI_MSI_IRQ_DOMAIN=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_REALLOC_ENABLE_AUTO is not set
# CONFIG_PCI_STUB is not set
# CONFIG_PCI_IOV is not set
# CONFIG_PCI_PRI is not set
# CONFIG_PCI_PASID is not set
CONFIG_PCI_LABEL=y

#
# PCI host controller drivers
#
CONFIG_PCIE_DW=y
# CONFIG_PCI_HOST_GENERIC is not set
CONFIG_PCI_LAYERSCAPE=y
# CONFIG_PCI_HISI is not set
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
# CONFIG_PCIE_ECRC is not set
# CONFIG_PCIEAER_INJECT is not set
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
CONFIG_PCIEASPM_DEFAULT=y
# CONFIG_PCIEASPM_POWERSAVE is not set
# CONFIG_PCIEASPM_PERFORMANCE is not set
CONFIG_PCIE_PME=y
# CONFIG_HOTPLUG_PCI is not set

#
# Kernel Features
#

#
# ARM errata workarounds via the alternatives framework
#
CONFIG_ARM64_ERRATUM_826319=y
CONFIG_ARM64_ERRATUM_827319=y
CONFIG_ARM64_ERRATUM_824069=y
CONFIG_ARM64_ERRATUM_819472=y
CONFIG_ARM64_ERRATUM_832075=y
CONFIG_ARM64_ERRATUM_834220=y
CONFIG_ARM64_ERRATUM_845719=y
CONFIG_ARM64_ERRATUM_843419=y
CONFIG_CAVIUM_ERRATUM_22375=y
CONFIG_CAVIUM_ERRATUM_23154=y
CONFIG_ARM64_4K_PAGES=y
# CONFIG_ARM64_16K_PAGES is not set
# CONFIG_ARM64_64K_PAGES is not set
CONFIG_ARM64_VA_BITS_39=y
# CONFIG_ARM64_VA_BITS_48 is not set
CONFIG_ARM64_VA_BITS=39
# CONFIG_CPU_BIG_ENDIAN is not set
# CONFIG_SCHED_MC is not set
# CONFIG_SCHED_SMT is not set
CONFIG_NR_CPUS=8
CONFIG_HOTPLUG_CPU=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_SCHED_HRTICK=y
CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HW_PERF_EVENTS=y
CONFIG_SYS_SUPPORTS_HUGETLBFS=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_NO_BOOTMEM=y
CONFIG_MEMORY_ISOLATION=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_MMU_NOTIFIER=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_CMA=y
# CONFIG_CMA_DEBUG is not set
# CONFIG_CMA_DEBUGFS is not set
CONFIG_CMA_AREAS=7
# CONFIG_ZPOOL is not set
# CONFIG_ZBUD is not set
# CONFIG_ZSMALLOC is not set
CONFIG_GENERIC_EARLY_IOREMAP=y
# CONFIG_IDLE_PAGE_TRACKING is not set
# CONFIG_SECCOMP is not set
# CONFIG_PARAVIRT is not set
# CONFIG_PARAVIRT_TIME_ACCOUNTING is not set
# CONFIG_XEN is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ARMV8_DEPRECATED=y
CONFIG_SWP_EMULATION=y
# CONFIG_CP15_BARRIER_EMULATION is not set
# CONFIG_SETEND_EMULATION is not set

#
# ARMv8.1 architectural features
#
CONFIG_ARM64_HW_AFDBM=y
CONFIG_ARM64_PAN=y
# CONFIG_ARM64_LSE_ATOMICS is not set

#
# Boot options
#
CONFIG_CMDLINE="console=ttyAMA0"
# CONFIG_CMDLINE_FORCE is not set
CONFIG_EFI_STUB=y
CONFIG_EFI=y
CONFIG_DMI=y

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=m
CONFIG_COREDUMP=y
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
# CONFIG_SUSPEND_SKIP_SYNC is not set
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_CLK=y
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y

#
# CPU Power Management
#

#
# CPU Idle
#
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y

#
# ARM CPU Idle Drivers
#
# CONFIG_ARM_CPUIDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
CONFIG_NET=y
CONFIG_NET_INGRESS=y
CONFIG_NET_EGRESS=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=m
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
# CONFIG_XFRM_STATISTICS is not set
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=m
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_FIB_TRIE_STATS is not set
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE_DEMUX=m
CONFIG_NET_IP_TUNNEL=y
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
# CONFIG_IP_MROUTE_MULTIPLE_TABLES is not set
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_SYN_COOKIES=y
# CONFIG_NET_IPVTI is not set
CONFIG_NET_UDP_TUNNEL=m
# CONFIG_NET_FOU is not set
# CONFIG_NET_FOU_IP_TUNNELS is not set
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_INET_UDP_DIAG is not set
# CONFIG_INET_DIAG_DESTROY is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IPV6=y
CONFIG_IPV6_ROUTER_PREF=y
# CONFIG_IPV6_ROUTE_INFO is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=m
# CONFIG_IPV6_MIP6 is not set
# CONFIG_IPV6_ILA is not set
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
# CONFIG_IPV6_VTI is not set
CONFIG_IPV6_SIT=y
# CONFIG_IPV6_SIT_6RD is not set
CONFIG_IPV6_NDISC_NODETYPE=y
CONFIG_IPV6_TUNNEL=m
# CONFIG_IPV6_GRE is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETLABEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NET_PTP_CLASSIFY=y
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=m

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_INGRESS=y
# CONFIG_NETFILTER_NETLINK_ACCT is not set
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NF_TABLES is not set
CONFIG_NETFILTER_XTABLES=m

#
# Xtables combined modules
#
# CONFIG_NETFILTER_XT_MARK is not set

#
# Xtables targets
#
# CONFIG_NETFILTER_XT_TARGET_CHECKSUM is not set
# CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set
# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
# CONFIG_NETFILTER_XT_TARGET_HL is not set
# CONFIG_NETFILTER_XT_TARGET_HMARK is not set
# CONFIG_NETFILTER_XT_TARGET_IDLETIMER is not set
# CONFIG_NETFILTER_XT_TARGET_LOG is not set
# CONFIG_NETFILTER_XT_TARGET_MARK is not set
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set
# CONFIG_NETFILTER_XT_TARGET_RATEEST is not set
# CONFIG_NETFILTER_XT_TARGET_TEE is not set
# CONFIG_NETFILTER_XT_TARGET_TPROXY is not set
# CONFIG_NETFILTER_XT_TARGET_TRACE is not set
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
# CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP is not set

#
# Xtables matches
#
# CONFIG_NETFILTER_XT_MATCH_ADDRTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
# CONFIG_NETFILTER_XT_MATCH_CGROUP is not set
# CONFIG_NETFILTER_XT_MATCH_COMMENT is not set
# CONFIG_NETFILTER_XT_MATCH_CPU is not set
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DEVGROUP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
CONFIG_NETFILTER_XT_MATCH_ECN=m
# CONFIG_NETFILTER_XT_MATCH_ESP is not set
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set
CONFIG_NETFILTER_XT_MATCH_HL=m
# CONFIG_NETFILTER_XT_MATCH_IPCOMP is not set
# CONFIG_NETFILTER_XT_MATCH_IPRANGE is not set
# CONFIG_NETFILTER_XT_MATCH_L2TP is not set
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
# CONFIG_NETFILTER_XT_MATCH_LIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_MAC is not set
# CONFIG_NETFILTER_XT_MATCH_MARK is not set
# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set
# CONFIG_NETFILTER_XT_MATCH_NFACCT is not set
# CONFIG_NETFILTER_XT_MATCH_OWNER is not set
# CONFIG_NETFILTER_XT_MATCH_POLICY is not set
# CONFIG_NETFILTER_XT_MATCH_PHYSDEV is not set
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
# CONFIG_NETFILTER_XT_MATCH_RATEEST is not set
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
# CONFIG_NETFILTER_XT_MATCH_RECENT is not set
CONFIG_NETFILTER_XT_MATCH_SCTP=m
# CONFIG_NETFILTER_XT_MATCH_SOCKET is not set
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
# CONFIG_NETFILTER_XT_MATCH_STRING is not set
# CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_TIME is not set
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_IP_SET is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV4 is not set
# CONFIG_NF_DUP_IPV4 is not set
# CONFIG_NF_LOG_ARP is not set
# CONFIG_NF_LOG_IPV4 is not set
CONFIG_NF_REJECT_IPV4=m
CONFIG_IP_NF_IPTABLES=m
# CONFIG_IP_NF_MATCH_AH is not set
CONFIG_IP_NF_MATCH_ECN=m
# CONFIG_IP_NF_MATCH_RPFILTER is not set
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_ECN=m
# CONFIG_IP_NF_TARGET_TTL is not set
CONFIG_IP_NF_RAW=m
# CONFIG_IP_NF_SECURITY is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m

#
# IPv6: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV6 is not set
# CONFIG_NF_DUP_IPV6 is not set
# CONFIG_NF_REJECT_IPV6 is not set
# CONFIG_NF_LOG_IPV6 is not set
CONFIG_IP6_NF_IPTABLES=m
# CONFIG_IP6_NF_MATCH_AH is not set
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
# CONFIG_IP6_NF_MATCH_MH is not set
# CONFIG_IP6_NF_MATCH_RPFILTER is not set
CONFIG_IP6_NF_MATCH_RT=m
# CONFIG_IP6_NF_TARGET_HL is not set
CONFIG_IP6_NF_FILTER=m
# CONFIG_IP6_NF_TARGET_REJECT is not set
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_RAW=m
# CONFIG_IP6_NF_SECURITY is not set
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_IP6=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_NFLOG=m
# CONFIG_IP_DCCP is not set
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_OBJCNT is not set
CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1 is not set
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE is not set
CONFIG_SCTP_COOKIE_HMAC_MD5=y
# CONFIG_SCTP_COOKIE_HMAC_SHA1 is not set
# CONFIG_RDS is not set
CONFIG_TIPC=m
CONFIG_TIPC_MEDIA_UDP=y
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
CONFIG_STP=m
CONFIG_BRIDGE=m
CONFIG_BRIDGE_IGMP_SNOOPING=y
# CONFIG_BRIDGE_VLAN_FILTERING is not set
CONFIG_HAVE_NET_DSA=y
CONFIG_VLAN_8021Q=m
# CONFIG_VLAN_8021Q_GVRP is not set
# CONFIG_VLAN_8021Q_MVRP is not set
# CONFIG_DECNET is not set
CONFIG_LLC=m
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_6LOWPAN is not set
# CONFIG_IEEE802154 is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_PRIO=m
# CONFIG_NET_SCH_MULTIQ is not set
CONFIG_NET_SCH_RED=m
# CONFIG_NET_SCH_SFB is not set
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
# CONFIG_NET_SCH_DRR is not set
# CONFIG_NET_SCH_MQPRIO is not set
# CONFIG_NET_SCH_CHOKE is not set
# CONFIG_NET_SCH_QFQ is not set
CONFIG_NET_SCH_CODEL=m
# CONFIG_NET_SCH_FQ_CODEL is not set
# CONFIG_NET_SCH_FQ is not set
# CONFIG_NET_SCH_HHF is not set
# CONFIG_NET_SCH_PIE is not set
CONFIG_NET_SCH_INGRESS=m
# CONFIG_NET_SCH_PLUG is not set

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=y
# CONFIG_NET_CLS_TCINDEX is not set
# CONFIG_NET_CLS_ROUTE4 is not set
# CONFIG_NET_CLS_FW is not set
CONFIG_NET_CLS_U32=y
# CONFIG_CLS_U32_PERF is not set
# CONFIG_CLS_U32_MARK is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_CLS_FLOW is not set
CONFIG_NET_CLS_CGROUP=y
# CONFIG_NET_CLS_BPF is not set
# CONFIG_NET_CLS_FLOWER is not set
# CONFIG_NET_EMATCH is not set
CONFIG_NET_CLS_ACT=y
# CONFIG_NET_ACT_POLICE is not set
# CONFIG_NET_ACT_GACT is not set
CONFIG_NET_ACT_MIRRED=m
# CONFIG_NET_ACT_IPT is not set
# CONFIG_NET_ACT_NAT is not set
# CONFIG_NET_ACT_PEDIT is not set
# CONFIG_NET_ACT_SIMP is not set
# CONFIG_NET_ACT_SKBEDIT is not set
# CONFIG_NET_ACT_CSUM is not set
# CONFIG_NET_ACT_VLAN is not set
# CONFIG_NET_ACT_BPF is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_MMAP is not set
# CONFIG_NETLINK_DIAG is not set
# CONFIG_MPLS is not set
# CONFIG_HSR is not set
# CONFIG_NET_SWITCHDEV is not set
# CONFIG_NET_L3_MASTER_DEV is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
CONFIG_SOCK_CGROUP_DATA=y
# CONFIG_CGROUP_NET_PRIO is not set
CONFIG_CGROUP_NET_CLASSID=y
CONFIG_NET_RX_BUSY_POLL=y
CONFIG_BQL=y
CONFIG_BPF_JIT=y
CONFIG_NET_FLOW_LIMIT=y

#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set

#
# CFG80211 needs to be enabled for MAC80211
#
CONFIG_MAC80211_STA_HASH_MAX_SIZE=0
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
# CONFIG_RFKILL_INPUT is not set
# CONFIG_RFKILL_GPIO is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
# CONFIG_LWTUNNEL is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#
CONFIG_ARM_AMBA=y

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER=y
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
CONFIG_ALLOW_DEV_COREDUMP=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_GENERIC_CPU_AUTOPROBE=y
CONFIG_REGMAP=y
CONFIG_REGMAP_MMIO=y
# CONFIG_DMA_SHARED_BUFFER is not set
# CONFIG_DMA_CMA is not set

#
# Bus devices
#
CONFIG_ARM_CCI=y
CONFIG_ARM_CCI_PMU=y
CONFIG_ARM_CCI400_COMMON=y
CONFIG_ARM_CCI400_PMU=y
# CONFIG_ARM_CCI500_PMU is not set
# CONFIG_ARM_CCN is not set
# CONFIG_VEXPRESS_CONFIG is not set
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_OF_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set
# CONFIG_MTD_PARTITIONED_MASTER is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_PHYSMAP_OF=y
# CONFIG_MTD_INTEL_VR_NOR is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
CONFIG_MTD_NAND_ECC=y
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_ECC_BCH is not set
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_DENALI_PCI is not set
# CONFIG_MTD_NAND_DENALI_DT is not set
# CONFIG_MTD_NAND_GPIO is not set
# CONFIG_MTD_NAND_OMAP_BCH_BUILD is not set
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_RICOH is not set
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_DOCG4 is not set
# CONFIG_MTD_NAND_CAFE is not set
# CONFIG_MTD_NAND_NANDSIM is not set
# CONFIG_MTD_NAND_BRCMNAND is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_NAND_HISI504 is not set
# CONFIG_MTD_ONENAND is not set

#
# LPDDR & LPDDR2 PCM memory drivers
#
# CONFIG_MTD_LPDDR is not set
# CONFIG_MTD_SPI_NOR is not set
# CONFIG_MTD_UBI is not set
CONFIG_DTC=y
CONFIG_OF=y
# CONFIG_OF_UNITTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_ADDRESS_PCI=y
CONFIG_OF_IRQ=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
CONFIG_OF_PCI=y
CONFIG_OF_PCI_IRQ=y
CONFIG_OF_MTD=y
CONFIG_OF_RESERVED_MEM=y
# CONFIG_OF_OVERLAY is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_NULL_BLK is not set
# CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_DRBD is not set
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SKD is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_VIRTIO_BLK is not set
# CONFIG_BLK_DEV_RBD is not set
# CONFIG_BLK_DEV_RSXX is not set
# CONFIG_BLK_DEV_NVME is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_SRAM is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_CB710_CORE is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set

#
# Altera FPGA firmware download module
#

#
# Intel MIC Bus Driver
#

#
# SCIF Bus Driver
#

#
# Intel MIC Host Driver
#

#
# Intel MIC Card Driver
#

#
# SCIF Driver
#

#
# Intel MIC Coprocessor State Management (COSM) Drivers
#
# CONFIG_GENWQE is not set
# CONFIG_ECHO is not set
# CONFIG_CXL_BASE is not set
# CONFIG_CXL_KERNEL_API is not set
# CONFIG_CXL_EEH is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_NETLINK is not set
# CONFIG_SCSI_MQ_DEFAULT is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_SCSI_CXGB3_ISCSI is not set
# CONFIG_SCSI_CXGB4_ISCSI is not set
# CONFIG_SCSI_BNX2_ISCSI is not set
# CONFIG_BE2ISCSI is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_HPSA is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_3W_SAS is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_HISI_SAS is not set
# CONFIG_SCSI_MVSAS is not set
# CONFIG_SCSI_MVUMI is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_SCSI_ESAS2R is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_MPT3SAS is not set
# CONFIG_SCSI_MPT2SAS is not set
# CONFIG_SCSI_UFSHCD is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_SNIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_WD719X is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_PMCRAID is not set
# CONFIG_SCSI_PM8001 is not set
# CONFIG_SCSI_VIRTIO is not set
# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_HAVE_PATA_PLATFORM=y
# CONFIG_ATA is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
CONFIG_MD_LINEAR=y
CONFIG_MD_RAID0=y
CONFIG_MD_RAID1=y
CONFIG_MD_RAID10=y
# CONFIG_MD_RAID456 is not set
CONFIG_MD_MULTIPATH=y
CONFIG_MD_FAULTY=y
# CONFIG_BCACHE is not set
CONFIG_BLK_DEV_DM_BUILTIN=y
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_MQ_DEFAULT is not set
# CONFIG_DM_DEBUG is not set
CONFIG_DM_BUFIO=y
# CONFIG_DM_DEBUG_BLOCK_STACK_TRACING is not set
CONFIG_DM_CRYPT=y
CONFIG_DM_SNAPSHOT=y
# CONFIG_DM_THIN_PROVISIONING is not set
# CONFIG_DM_CACHE is not set
# CONFIG_DM_ERA is not set
CONFIG_DM_MIRROR=y
# CONFIG_DM_LOG_USERSPACE is not set
# CONFIG_DM_RAID is not set
CONFIG_DM_ZERO=y
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
# CONFIG_DM_UEVENT is not set
# CONFIG_DM_FLAKEY is not set
# CONFIG_DM_VERITY is not set
# CONFIG_DM_SWITCH is not set
# CONFIG_DM_LOG_WRITES is not set
# CONFIG_TARGET_CORE is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_FIREWIRE_NOSY is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
# CONFIG_EQUALIZER is not set
# CONFIG_NET_FC is not set
# CONFIG_IFB is not set
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_IPVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_GENEVE is not set
CONFIG_NETCONSOLE=y
CONFIG_NETPOLL=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_TUN=m
# CONFIG_TUN_VNET_CROSS_LE is not set
# CONFIG_VETH is not set
# CONFIG_VIRTIO_NET is not set
# CONFIG_NLMON is not set
# CONFIG_ARCNET is not set

#
# CAIF transport drivers
#
# CONFIG_VHOST_NET is not set
# CONFIG_VHOST_CROSS_ENDIAN_LEGACY is not set

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
CONFIG_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
# CONFIG_VORTEX is not set
# CONFIG_TYPHOON is not set
CONFIG_NET_VENDOR_ADAPTEC=y
# CONFIG_ADAPTEC_STARFIRE is not set
CONFIG_NET_VENDOR_AGERE=y
# CONFIG_ET131X is not set
CONFIG_NET_VENDOR_ALTEON=y
# CONFIG_ACENIC is not set
# CONFIG_ALTERA_TSE is not set
CONFIG_NET_VENDOR_AMD=y
# CONFIG_AMD8111_ETH is not set
# CONFIG_PCNET32 is not set
# CONFIG_AMD_XGBE is not set
CONFIG_NET_VENDOR_ARC=y
# CONFIG_ARC_EMAC is not set
CONFIG_NET_VENDOR_ATHEROS=y
# CONFIG_ATL2 is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
# CONFIG_ALX is not set
# CONFIG_NET_VENDOR_AURORA is not set
CONFIG_NET_CADENCE=y
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
# CONFIG_BCMGENET is not set
# CONFIG_BNX2 is not set
# CONFIG_CNIC is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2X is not set
# CONFIG_SYSTEMPORT is not set
# CONFIG_BNXT is not set
CONFIG_NET_VENDOR_BROCADE=y
# CONFIG_BNA is not set
CONFIG_NET_VENDOR_CAVIUM=y
# CONFIG_THUNDER_NIC_PF is not set
# CONFIG_THUNDER_NIC_VF is not set
# CONFIG_THUNDER_NIC_BGX is not set
# CONFIG_LIQUIDIO is not set
CONFIG_NET_VENDOR_CHELSIO=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
# CONFIG_CHELSIO_T4 is not set
# CONFIG_CHELSIO_T4VF is not set
CONFIG_NET_VENDOR_CISCO=y
# CONFIG_ENIC is not set
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_DEC=y
# CONFIG_NET_TULIP is not set
CONFIG_NET_VENDOR_DLINK=y
# CONFIG_DL2K is not set
# CONFIG_SUNDANCE is not set
CONFIG_NET_VENDOR_EMULEX=y
# CONFIG_BE2NET is not set
CONFIG_NET_VENDOR_EZCHIP=y
# CONFIG_EZCHIP_NPS_MANAGEMENT_ENET is not set
CONFIG_NET_VENDOR_EXAR=y
# CONFIG_S2IO is not set
# CONFIG_VXGE is not set
CONFIG_NET_VENDOR_FREESCALE=y
# CONFIG_FSL_PQ_MDIO is not set
# CONFIG_FSL_XGMAC_MDIO is not set
# CONFIG_GIANFAR is not set
CONFIG_NET_VENDOR_HISILICON=y
# CONFIG_HIX5HD2_GMAC is not set
# CONFIG_HIP04_ETH is not set
# CONFIG_HNS is not set
# CONFIG_HNS_DSAF is not set
# CONFIG_HNS_ENET is not set
CONFIG_NET_VENDOR_HP=y
# CONFIG_HP100 is not set
CONFIG_NET_VENDOR_INTEL=y
# CONFIG_E100 is not set
# CONFIG_E1000 is not set
CONFIG_E1000E=y
# CONFIG_IGB is not set
# CONFIG_IGBVF is not set
# CONFIG_IXGB is not set
# CONFIG_IXGBE is not set
# CONFIG_IXGBEVF is not set
# CONFIG_I40E is not set
# CONFIG_I40EVF is not set
# CONFIG_FM10K is not set
CONFIG_NET_VENDOR_I825XX=y
# CONFIG_JME is not set
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
CONFIG_NET_VENDOR_MELLANOX=y
# CONFIG_MLX4_EN is not set
# CONFIG_MLX4_CORE is not set
# CONFIG_MLX5_CORE is not set
# CONFIG_MLXSW_CORE is not set
CONFIG_NET_VENDOR_MICREL=y
# CONFIG_KS8851_MLL is not set
# CONFIG_KSZ884X_PCI is not set
CONFIG_NET_VENDOR_MYRI=y
# CONFIG_MYRI10GE is not set
# CONFIG_FEALNX is not set
CONFIG_NET_VENDOR_NATSEMI=y
# CONFIG_NATSEMI is not set
# CONFIG_NS83820 is not set
CONFIG_NET_VENDOR_NETRONOME=y
# CONFIG_NFP_NETVF is not set
CONFIG_NET_VENDOR_8390=y
# CONFIG_NE2K_PCI is not set
CONFIG_NET_VENDOR_NVIDIA=y
# CONFIG_FORCEDETH is not set
CONFIG_NET_VENDOR_OKI=y
# CONFIG_ETHOC is not set
CONFIG_NET_PACKET_ENGINE=y
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_NET_VENDOR_QLOGIC=y
# CONFIG_QLA3XXX is not set
# CONFIG_QLCNIC is not set
# CONFIG_QLGE is not set
# CONFIG_NETXEN_NIC is not set
# CONFIG_QED is not set
CONFIG_NET_VENDOR_QUALCOMM=y
CONFIG_NET_VENDOR_REALTEK=y
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_R8169 is not set
CONFIG_NET_VENDOR_RENESAS=y
CONFIG_NET_VENDOR_RDC=y
# CONFIG_R6040 is not set
CONFIG_NET_VENDOR_ROCKER=y
CONFIG_NET_VENDOR_SAMSUNG=y
# CONFIG_SXGBE_ETH is not set
CONFIG_NET_VENDOR_SEEQ=y
CONFIG_NET_VENDOR_SILAN=y
# CONFIG_SC92031 is not set
CONFIG_NET_VENDOR_SIS=y
# CONFIG_SIS900 is not set
# CONFIG_SIS190 is not set
# CONFIG_SFC is not set
CONFIG_NET_VENDOR_SMSC=y
# CONFIG_SMC91X is not set
# CONFIG_EPIC100 is not set
# CONFIG_SMSC911X is not set
# CONFIG_SMSC9420 is not set
CONFIG_NET_VENDOR_STMICRO=y
# CONFIG_STMMAC_ETH is not set
CONFIG_NET_VENDOR_SUN=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NIU is not set
CONFIG_NET_VENDOR_SYNOPSYS=y
# CONFIG_SYNOPSYS_DWC_ETH_QOS is not set
CONFIG_NET_VENDOR_TEHUTI=y
# CONFIG_TEHUTI is not set
CONFIG_NET_VENDOR_TI=y
# CONFIG_TI_CPSW_ALE is not set
# CONFIG_TLAN is not set
CONFIG_NET_VENDOR_VIA=y
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_NET_VENDOR_WIZNET=y
# CONFIG_WIZNET_W5100 is not set
# CONFIG_WIZNET_W5300 is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_NET_SB1000 is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_AQUANTIA_PHY is not set
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_TERANETICS_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM7XXX_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_DP83848_PHY is not set
# CONFIG_DP83867_PHY is not set
# CONFIG_MICROCHIP_PHY is not set
CONFIG_FIXED_PHY=y
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_OCTEON is not set
CONFIG_MDIO_BUS_MUX=y
# CONFIG_MDIO_BUS_MUX_GPIO is not set
CONFIG_MDIO_BUS_MUX_MMIOREG=y
# CONFIG_MDIO_BCM_UNIMAC is not set
CONFIG_PPP=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_FILTER=y
# CONFIG_PPP_MPPE is not set
CONFIG_PPP_MULTILINK=y
CONFIG_PPPOE=m
# CONFIG_PPTP is not set
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_SLIP=m
CONFIG_SLHC=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
CONFIG_USB_NET_DRIVERS=y
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_RTL8152 is not set
# CONFIG_USB_LAN78XX is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_HSO is not set
# CONFIG_USB_IPHETH is not set
CONFIG_WLAN=y
CONFIG_WLAN_VENDOR_ADMTEK=y
CONFIG_WLAN_VENDOR_ATH=y
# CONFIG_ATH_DEBUG is not set
# CONFIG_ATH5K_PCI is not set
CONFIG_WLAN_VENDOR_ATMEL=y
CONFIG_WLAN_VENDOR_BROADCOM=y
CONFIG_WLAN_VENDOR_CISCO=y
CONFIG_WLAN_VENDOR_INTEL=y
CONFIG_WLAN_VENDOR_INTERSIL=y
# CONFIG_HOSTAP is not set
# CONFIG_PRISM54 is not set
CONFIG_WLAN_VENDOR_MARVELL=y
CONFIG_WLAN_VENDOR_MEDIATEK=y
CONFIG_WLAN_VENDOR_RALINK=y
CONFIG_WLAN_VENDOR_REALTEK=y
CONFIG_WLAN_VENDOR_RSI=y
CONFIG_WLAN_VENDOR_ST=y
CONFIG_WLAN_VENDOR_TI=y
CONFIG_WLAN_VENDOR_ZYDAS=y

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_VMXNET3 is not set
# CONFIG_FUJITSU_ES is not set
# CONFIG_ISDN is not set
# CONFIG_NVM is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_OMAP4 is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_BCM is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_CYPRESS=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_PS2_FOCALTECH=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_GPIO is not set
# CONFIG_MOUSE_SYNAPTICS_USB is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_AMBAKMI is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_SERIO_APBPS2 is not set
# CONFIG_USERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVMEM=y
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_EARLYCON=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
CONFIG_SERIAL_8250_FSL=y
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_RT288X is not set
# CONFIG_SERIAL_8250_FINTEK is not set
# CONFIG_SERIAL_8250_INGENIC is not set
# CONFIG_SERIAL_8250_MID is not set
CONFIG_SERIAL_OF_PLATFORM=y

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_AMBA_PL010 is not set
# CONFIG_SERIAL_AMBA_PL011 is not set
# CONFIG_SERIAL_EARLYCON_ARM_SEMIHOST is not set
# CONFIG_SERIAL_KGDB_NMI is not set
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_CONSOLE_POLL=y
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_RP2 is not set
# CONFIG_SERIAL_FSL_LPUART is not set
# CONFIG_SERIAL_CONEXANT_DIGICOLOR is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_VIRTIO_CONSOLE is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=m
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_VIRTIO is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# PCMCIA character devices
#
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
# CONFIG_XILLYBUS is not set

#
# I2C support
#
# CONFIG_I2C is not set
# CONFIG_SPI is not set
# CONFIG_SPMI is not set
# CONFIG_HSI is not set

#
# PPS support
#
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set
# CONFIG_NTP_PPS is not set

#
# PPS clients support
#
# CONFIG_PPS_CLIENT_KTIMER is not set
# CONFIG_PPS_CLIENT_LDISC is not set
# CONFIG_PPS_CLIENT_GPIO is not set

#
# PPS generators support
#

#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=y

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_OF_GPIO=y
CONFIG_GPIO_ACPI=y
# CONFIG_DEBUG_GPIO is not set
# CONFIG_GPIO_SYSFS is not set

#
# Memory mapped GPIO drivers
#
# CONFIG_GPIO_74XX_MMIO is not set
# CONFIG_GPIO_ALTERA is not set
# CONFIG_GPIO_AMDPT is not set
# CONFIG_GPIO_DWAPB is not set
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_GRGPIO is not set
# CONFIG_GPIO_PL061 is not set
# CONFIG_GPIO_SYSCON is not set
# CONFIG_GPIO_VX855 is not set
# CONFIG_GPIO_XGENE is not set
# CONFIG_GPIO_XILINX is not set
# CONFIG_GPIO_ZX is not set

#
# MFD GPIO expanders
#

#
# PCI GPIO expanders
#
# CONFIG_GPIO_AMD8111 is not set
# CONFIG_GPIO_BT8XX is not set
# CONFIG_GPIO_ML_IOH is not set
# CONFIG_GPIO_RDC321X is not set

#
# USB GPIO expanders
#
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_BQ27XXX is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_GPIO is not set
CONFIG_POWER_RESET=y
# CONFIG_POWER_RESET_GPIO is not set
# CONFIG_POWER_RESET_GPIO_RESTART is not set
# CONFIG_POWER_RESET_LTC2952 is not set
# CONFIG_POWER_RESET_RESTART is not set
# CONFIG_POWER_RESET_XGENE is not set
# CONFIG_POWER_RESET_SYSCON is not set
# CONFIG_POWER_RESET_SYSCON_POWEROFF is not set
# CONFIG_POWER_AVS is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_GPIO_FAN is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_MAX197 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_NTC_THERMISTOR is not set
# CONFIG_SENSORS_NCT6683 is not set
# CONFIG_SENSORS_NCT6775 is not set
# CONFIG_SENSORS_SHT15 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SCH56XX_COMMON is not set
# CONFIG_SENSORS_SCH5627 is not set
# CONFIG_SENSORS_SCH5636 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set

#
# ACPI drivers
#
# CONFIG_SENSORS_ACPI_POWER is not set
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
CONFIG_THERMAL_OF=y
# CONFIG_THERMAL_WRITABLE_TRIPS is not set
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
# CONFIG_THERMAL_DEFAULT_GOV_POWER_ALLOCATOR is not set
# CONFIG_THERMAL_GOV_FAIR_SHARE is not set
CONFIG_THERMAL_GOV_STEP_WISE=y
# CONFIG_THERMAL_GOV_BANG_BANG is not set
# CONFIG_THERMAL_GOV_USER_SPACE is not set
# CONFIG_THERMAL_GOV_POWER_ALLOCATOR is not set
# CONFIG_THERMAL_EMULATION is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
# CONFIG_WATCHDOG_SYSFS is not set

#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
# CONFIG_GPIO_WATCHDOG is not set
# CONFIG_XILINX_WATCHDOG is not set
# CONFIG_ARM_SP805_WATCHDOG is not set
# CONFIG_CADENCE_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
# CONFIG_TS4800_WATCHDOG is not set
# CONFIG_MAX63XX_WATCHDOG is not set
# CONFIG_IMX2_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_I6300ESB_WDT is not set
# CONFIG_BCM7038_WDT is not set
# CONFIG_MEN_A21_WDT is not set

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_ATMEL_FLEXCOM is not set
# CONFIG_MFD_ATMEL_HLCDC is not set
# CONFIG_MFD_DLN2 is not set
# CONFIG_MFD_HI6421_PMIC is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_LPC_ICH is not set
# CONFIG_LPC_SCH is not set
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_KEMPLD is not set
# CONFIG_MFD_MT6397 is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RDC321X is not set
# CONFIG_MFD_RTSX_PCI is not set
# CONFIG_MFD_RTSX_USB is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_ABX500_CORE is not set
CONFIG_MFD_SYSCON=y
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_TPS65912 is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_VX855 is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
# CONFIG_DRM is not set

#
# Frame buffer Devices
#
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
# CONFIG_VGASTATE is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_DUMMY_CONSOLE_COLUMNS=80
CONFIG_DUMMY_CONSOLE_ROWS=25
# CONFIG_SOUND is not set

#
# HID support
#
CONFIG_HID=y
# CONFIG_HID_BATTERY_STRENGTH is not set
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_APPLEIR is not set
# CONFIG_HID_AUREAL is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_BETOP_FF is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_ELO is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_GEMBIRD is not set
# CONFIG_HID_GFRM is not set
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MAGICMOUSE is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PENMOUNT is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PLANTRONICS is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_RMI is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_WACOM is not set
# CONFIG_HID_XINMO is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set

#
# USB HID support
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_USB_ULPI_BUS is not set
# CONFIG_USB_MON is not set
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_PCI=y
CONFIG_USB_XHCI_PLATFORM=y
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=y
CONFIG_USB_EHCI_HCD_PLATFORM=y
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_FOTG210_HCD is not set
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_PCI=y
CONFIG_USB_OHCI_HCD_PLATFORM=y
# CONFIG_USB_UHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_HCD_TEST_MODE is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_REALTEK is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_STORAGE_ENE_UB6250 is not set
# CONFIG_USB_UAS is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USBIP_CORE is not set
# CONFIG_USB_MUSB_HDRC is not set
CONFIG_USB_DWC3=y
CONFIG_USB_DWC3_HOST=y

#
# Platform Glue Driver Support
#
CONFIG_USB_DWC3_PCI=y
CONFIG_USB_DWC3_OF_SIMPLE=y
# CONFIG_USB_DWC2 is not set
# CONFIG_USB_CHIPIDEA is not set
# CONFIG_USB_ISP1760 is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_EHSET_TEST_FIXTURE is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set
# CONFIG_USB_LINK_LAYER_TEST is not set
# CONFIG_USB_CHAOSKEY is not set

#
# USB Physical Layer drivers
#
# CONFIG_USB_PHY is not set
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_USB_ULPI is not set
# CONFIG_USB_GADGET is not set
# CONFIG_UWB is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_ARMMMCI is not set
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
# CONFIG_MMC_SDHCI_PCI is not set
# CONFIG_MMC_SDHCI_ACPI is not set
CONFIG_MMC_SDHCI_PLTFM=y
# CONFIG_MMC_SDHCI_OF_ARASAN is not set
# CONFIG_MMC_SDHCI_OF_AT91 is not set
CONFIG_MMC_SDHCI_OF_ESDHC=y
# CONFIG_MMC_SDHCI_F_SDH30 is not set
# CONFIG_MMC_TIFM_SD is not set
# CONFIG_MMC_CB710 is not set
# CONFIG_MMC_VIA_SDMMC is not set
# CONFIG_MMC_DW is not set
# CONFIG_MMC_VUB300 is not set
# CONFIG_MMC_USHC is not set
# CONFIG_MMC_USDHI6ROL0 is not set
# CONFIG_MMC_TOSHIBA_PCI is not set
# CONFIG_MMC_MTK is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC_SUPPORT=y
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
CONFIG_VFIO_IOMMU_TYPE1=y
# CONFIG_VFIO_VIRQFD is not set
CONFIG_VFIO=y
# CONFIG_VFIO_NOIOMMU is not set
# CONFIG_VFIO_PCI is not set
# CONFIG_VFIO_PLATFORM is not set
# CONFIG_VIRT_DRIVERS is not set
CONFIG_VIRTIO=y

#
# Virtio drivers
#
# CONFIG_VIRTIO_PCI is not set
# CONFIG_VIRTIO_BALLOON is not set
# CONFIG_VIRTIO_INPUT is not set
CONFIG_VIRTIO_MMIO=y
# CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES is not set

#
# Microsoft Hyper-V guest support
#
CONFIG_STAGING=y
# CONFIG_COMEDI is not set
# CONFIG_RTL8192U is not set
# CONFIG_RTLLIB is not set
# CONFIG_R8712U is not set
# CONFIG_R8723AU is not set
# CONFIG_RTS5208 is not set

#
# Speakup console speech
#
# CONFIG_SPEAKUP is not set
# CONFIG_STAGING_MEDIA is not set

#
# Android
#
# CONFIG_STAGING_BOARD is not set
# CONFIG_WIMAX_GDM72XX is not set
# CONFIG_LTE_GDM724X is not set
# CONFIG_LUSTRE_FS is not set
# CONFIG_DGNC is not set
# CONFIG_DGAP is not set
# CONFIG_GS_FPGABOOT is not set
# CONFIG_COMMON_CLK_XLNX_CLKWZRD is not set
CONFIG_FSL_MC_BUS=y
# CONFIG_MOST is not set
# CONFIG_CHROME_PLATFORMS is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_VERSATILE is not set
CONFIG_CLK_QORIQ=y
CONFIG_COMMON_CLK_XGENE=y
# CONFIG_COMMON_CLK_NXP is not set
# CONFIG_COMMON_CLK_PXA is not set

#
# Hardware Spinlock drivers
#

#
# Clock Source drivers
#
CONFIG_CLKSRC_OF=y
CONFIG_CLKSRC_ACPI=y
CONFIG_CLKSRC_PROBE=y
CONFIG_ARM_ARCH_TIMER=y
CONFIG_ARM_ARCH_TIMER_EVTSTREAM=y
# CONFIG_ARM_TIMER_SP804 is not set
# CONFIG_ATMEL_PIT is not set
# CONFIG_SH_TIMER_CMT is not set
# CONFIG_SH_TIMER_MTU2 is not set
# CONFIG_SH_TIMER_TMU is not set
# CONFIG_EM_TIMER_STI is not set
# CONFIG_MAILBOX is not set
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y

#
# Generic IOMMU Pagetable Support
#
CONFIG_IOMMU_IO_PGTABLE=y
CONFIG_IOMMU_IO_PGTABLE_LPAE=y
# CONFIG_IOMMU_IO_PGTABLE_LPAE_SELFTEST is not set
CONFIG_IOMMU_IOVA=y
CONFIG_OF_IOMMU=y
CONFIG_IOMMU_DMA=y
CONFIG_ARM_SMMU=y
# CONFIG_ARM_SMMU_V3 is not set

#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers
#

#
# SOC (System On Chip) specific Drivers
#
# CONFIG_SUNXI_SRAM is not set
# CONFIG_SOC_TI is not set
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
CONFIG_MEMORY=y
# CONFIG_ARM_PL172_MPMC is not set
# CONFIG_IIO is not set
# CONFIG_NTB is not set
# CONFIG_VME_BUS is not set
# CONFIG_PWM is not set
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
CONFIG_ARM_GIC_MAX_NR=1
CONFIG_ARM_GIC_V2M=y
CONFIG_ARM_GIC_V3=y
CONFIG_ARM_GIC_V3_ITS=y
# CONFIG_HISILICON_IRQ_MBIGEN is not set
# CONFIG_TS4800_IRQ is not set
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
# CONFIG_FMC is not set

#
# PHY Subsystem
#
CONFIG_GENERIC_PHY=y
# CONFIG_PHY_PXA_28NM_HSIC is not set
# CONFIG_PHY_PXA_28NM_USB2 is not set
# CONFIG_BCM_KONA_USB2_PHY is not set
# CONFIG_PHY_HI6220_USB is not set
# CONFIG_PHY_XGENE is not set
# CONFIG_POWERCAP is not set
# CONFIG_MCB is not set

#
# Performance monitor support
#
CONFIG_ARM_PMU=y
CONFIG_RAS=y
# CONFIG_THUNDERBOLT is not set

#
# Android
#
# CONFIG_ANDROID is not set
# CONFIG_LIBNVDIMM is not set
# CONFIG_NVMEM is not set
# CONFIG_STM is not set
# CONFIG_STM_DUMMY is not set
# CONFIG_STM_SOURCE_CONSOLE is not set
# CONFIG_INTEL_TH is not set

#
# FPGA Configuration Support
#
# CONFIG_FPGA is not set

#
# Firmware Drivers
#
CONFIG_ARM_PSCI_FW=y
# CONFIG_FIRMWARE_MEMMAP is not set
CONFIG_DMIID=y
# CONFIG_DMI_SYSFS is not set
CONFIG_HAVE_ARM_SMCCC=y

#
# EFI (Extensible Firmware Interface) Support
#
# CONFIG_EFI_VARS is not set
CONFIG_EFI_ESRT=y
CONFIG_EFI_PARAMS_FROM_FDT=y
CONFIG_EFI_RUNTIME_WRAPPERS=y
CONFIG_EFI_ARMSTUB=y
CONFIG_ACPI=y
CONFIG_ACPI_GENERIC_GSI=y
CONFIG_ACPI_CCA_REQUIRED=y
# CONFIG_ACPI_DEBUGGER is not set
# CONFIG_ACPI_EC_DEBUGFS is not set
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_HED is not set
# CONFIG_ACPI_CUSTOM_METHOD is not set
CONFIG_ACPI_REDUCED_HARDWARE_ONLY=y
# CONFIG_PMIC_OPREGION is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_ENCRYPTION is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_BTRFS_FS=y
CONFIG_BTRFS_FS_POSIX_ACL=y
# CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
# CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
# CONFIG_BTRFS_DEBUG is not set
# CONFIG_BTRFS_ASSERT is not set
# CONFIG_NILFS2_FS is not set
# CONFIG_F2FS_FS is not set
# CONFIG_FS_DAX is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_MANDATORY_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
CONFIG_AUTOFS4_FS=y
CONFIG_FUSE_FS=m
CONFIG_CUSE=m
# CONFIG_OVERLAY_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_PROC_CHILDREN=y
CONFIG_KERNFS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=m
CONFIG_EFIVAR_FS=m
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
CONFIG_ROMFS_FS=m
CONFIG_ROMFS_BACKED_BY_BLOCK=y
# CONFIG_ROMFS_BACKED_BY_MTD is not set
# CONFIG_ROMFS_BACKED_BY_BOTH is not set
CONFIG_ROMFS_ON_BLOCK=y
CONFIG_PSTORE=y
CONFIG_PSTORE_CONSOLE=y
# CONFIG_PSTORE_PMSG is not set
CONFIG_PSTORE_FTRACE=y
CONFIG_PSTORE_RAM=y
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=y
# CONFIG_NFS_SWAP is not set
# CONFIG_NFS_V4_1 is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
# CONFIG_NFSD is not set
CONFIG_GRACE_PERIOD=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=m
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
# CONFIG_CIFS_UPCALL is not set
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_ACL is not set
CONFIG_CIFS_DEBUG=y
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_DFS_UPCALL is not set
# CONFIG_CIFS_SMB2 is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
CONFIG_NLS_UTF8=m
# CONFIG_DLM is not set
CONFIG_HAVE_KVM_IRQFD=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_MMIO=y
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y
CONFIG_KVM_VFIO=y
CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL=y
CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y
CONFIG_KVM_COMPAT=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM_ARM_VGIC_V3=y
CONFIG_KVM=y
CONFIG_KVM_ARM_HOST=y

#
# Kernel hacking
#

#
# printk and dmesg options
#
# CONFIG_PRINTK_TIME is not set
CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_DYNAMIC_DEBUG is not set

#
# Compile-time checks and compiler options
#
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_INFO_SPLIT is not set
# CONFIG_DEBUG_INFO_DWARF4 is not set
# CONFIG_GDB_SCRIPTS is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_PAGE_OWNER is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_SECTION_MISMATCH_WARN_ONLY=y
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
CONFIG_DEBUG_KERNEL=y

#
# Memory Debugging
#
# CONFIG_PAGE_EXTENSION is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400
# CONFIG_DEBUG_KMEMLEAK_TEST is not set
# CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
CONFIG_HAVE_ARCH_KASAN=y
CONFIG_KASAN=y
CONFIG_KASAN_OUTLINE=y
# CONFIG_KASAN_INLINE is not set
CONFIG_TEST_KASAN=m
# CONFIG_DEBUG_SHIRQ is not set

#
# Debug Lockups and Hangs
#
CONFIG_LOCKUP_DETECTOR=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_WQ_WATCHDOG=y
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_PANIC_TIMEOUT=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHED_INFO=y
CONFIG_SCHEDSTATS=y
# CONFIG_SCHED_STACK_END_CHECK is not set
# CONFIG_DEBUG_TIMEKEEPING is not set
# CONFIG_TIMER_STATS is not set
CONFIG_DEBUG_PREEMPT=y

#
# Lock Debugging (spinlocks, mutexes, etc...)
#
# CONFIG_DEBUG_RT_MUTEXES is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_DEBUG_ATOMIC_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_LOCK_TORTURE_TEST=y
CONFIG_TRACE_IRQFLAGS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_HAVE_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_PI_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set

#
# RCU Debugging
#
CONFIG_PROVE_RCU=y
# CONFIG_PROVE_RCU_REPEATEDLY is not set
# CONFIG_SPARSE_RCU_POINTER is not set
CONFIG_TORTURE_TEST=y
CONFIG_RCU_TORTURE_TEST=y
CONFIG_RCU_TORTURE_TEST_RUNNABLE=y
# CONFIG_RCU_TORTURE_TEST_SLOW_PREINIT is not set
# CONFIG_RCU_TORTURE_TEST_SLOW_INIT is not set
# CONFIG_RCU_TORTURE_TEST_SLOW_CLEANUP is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
# CONFIG_RCU_TRACE is not set
# CONFIG_RCU_EQS_DEBUG is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_IRQSOFF_TRACER=y
CONFIG_PREEMPT_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_TRACER_SNAPSHOT=y
CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP=y
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
CONFIG_STACK_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
# CONFIG_PROBE_EVENTS is not set
CONFIG_DYNAMIC_FTRACE=y
# CONFIG_FUNCTION_PROFILER is not set
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_TRACEPOINT_BENCHMARK is not set
CONFIG_RING_BUFFER_BENCHMARK=y
CONFIG_RING_BUFFER_STARTUP_TEST=y
# CONFIG_TRACE_ENUM_MAP_FILE is not set
CONFIG_TRACING_EVENTS_GPIO=y

#
# Runtime Testing
#
# CONFIG_LKDTM is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_PERCPU_TEST is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_TEST_HEXDUMP is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_TEST_PRINTF is not set
# CONFIG_TEST_RHASHTABLE is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_TEST_LKM is not set
# CONFIG_TEST_USER_COPY is not set
CONFIG_TEST_BPF=m
# CONFIG_TEST_UDELAY is not set
# CONFIG_MEMTEST is not set
# CONFIG_TEST_STATIC_KEYS is not set
CONFIG_SAMPLES=y
# CONFIG_SAMPLE_TRACE_EVENTS is not set
# CONFIG_SAMPLE_KOBJECT is not set
# CONFIG_SAMPLE_HW_BREAKPOINT is not set
# CONFIG_SAMPLE_KFIFO is not set
# CONFIG_SAMPLE_KDB is not set
# CONFIG_SAMPLE_CONFIGFS is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_KGDB_TESTS=y
CONFIG_KGDB_TESTS_ON_BOOT=y
CONFIG_KGDB_TESTS_BOOT_STRING="V1F100"
CONFIG_KGDB_KDB=y
CONFIG_KDB_DEFAULT_ENABLE=0x1
# CONFIG_KDB_KEYBOARD is not set
CONFIG_KDB_CONTINUE_CATASTROPHIC=0
CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y
CONFIG_UBSAN=y
CONFIG_UBSAN_SANITIZE_ALL=y
# CONFIG_UBSAN_ALIGNMENT is not set
CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y
# CONFIG_STRICT_DEVMEM is not set
# CONFIG_ARM64_PTDUMP is not set
# CONFIG_PID_IN_CONTEXTIDR is not set
# CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET is not set
# CONFIG_DEBUG_SET_MODULE_RONX is not set
CONFIG_DEBUG_RODATA=y
# CONFIG_DEBUG_ALIGN_RODATA is not set
# CONFIG_CORESIGHT is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_PERSISTENT_KEYRINGS is not set
# CONFIG_BIG_KEYS is not set
# CONFIG_ENCRYPTED_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_NETWORK is not set
# CONFIG_SECURITY_PATH is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set
CONFIG_INTEGRITY=y
# CONFIG_INTEGRITY_SIGNATURE is not set
# CONFIG_IMA is not set
# CONFIG_EVM is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_XOR_BLOCKS=y
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_RNG_DEFAULT=m
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_AKCIPHER2=y
# CONFIG_CRYPTO_RSA is not set
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_NULL2=y
# CONFIG_CRYPTO_PCRYPT is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_MCRYPTD is not set
CONFIG_CRYPTO_AUTHENC=y
CONFIG_CRYPTO_TEST=m

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_CHACHA20POLY1305 is not set
CONFIG_CRYPTO_SEQIV=m
CONFIG_CRYPTO_ECHAINIV=m

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_CTR=m
CONFIG_CRYPTO_CTS=y
CONFIG_CRYPTO_ECB=m
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set
# CONFIG_CRYPTO_KEYWRAP is not set

#
# Hash modes
#
CONFIG_CRYPTO_CMAC=m
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_CRCT10DIF is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_POLY1305 is not set
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
# CONFIG_CRYPTO_TGR192 is not set
CONFIG_CRYPTO_WP512=m

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_BLOWFISH_COMMON=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST_COMMON=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_KHAZAD=m
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_CHACHA20 is not set
# CONFIG_CRYPTO_SEED is not set
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set
# CONFIG_CRYPTO_842 is not set
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_DRBG_MENU=m
CONFIG_CRYPTO_DRBG_HMAC=y
# CONFIG_CRYPTO_DRBG_HASH is not set
# CONFIG_CRYPTO_DRBG_CTR is not set
CONFIG_CRYPTO_DRBG=m
CONFIG_CRYPTO_JITTERENTROPY=m
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_USER_API_RNG is not set
# CONFIG_CRYPTO_USER_API_AEAD is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_CCP is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set

#
# Certificates for signature checking
#
# CONFIG_SYSTEM_TRUSTED_KEYRING is not set
# CONFIG_ARM64_CRYPTO is not set
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_RAID6_PQ=y
CONFIG_BITREVERSE=y
CONFIG_HAVE_ARCH_BITREVERSE=y
CONFIG_RATIONAL=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
# CONFIG_CRC8 is not set
CONFIG_AUDIT_ARCH_COMPAT_GENERIC=y
# CONFIG_RANDOM32_SELFTEST is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_LZ4_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_DECOMPRESS_LZ4=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_REED_SOLOMON=y
CONFIG_REED_SOLOMON_ENC8=y
CONFIG_REED_SOLOMON_DEC8=y
CONFIG_ASSOCIATIVE_ARRAY=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT_MAP=y
CONFIG_HAS_DMA=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
# CONFIG_IRQ_POLL is not set
CONFIG_LIBFDT=y
CONFIG_OID_REGISTRY=y
CONFIG_UCS2_STRING=y
# CONFIG_SG_SPLIT is not set
CONFIG_ARCH_HAS_SG_CHAIN=y

From yang.shi at linaro.org  Tue Feb  9 09:32:53 2016
From: yang.shi at linaro.org (Shi, Yang)
Date: Tue, 9 Feb 2016 09:32:53 -0800
Subject: [PATCH v2] arm64: disable kasan when accessing frame->fp in
 unwind_frame
In-Reply-To: <56BA2269.1000908@linaro.org>
References: <1454951589-18238-1-git-send-email-yang.shi@linaro.org>
 <20160209165414.GT22874@arm.com> <56BA1F18.2020103@linaro.org>
 <20160209172310.GV22874@arm.com> <56BA2269.1000908@linaro.org>
Message-ID: <56BA22C5.1090004@linaro.org>

On 2/9/2016 9:31 AM, Shi, Yang wrote:
> On 2/9/2016 9:23 AM, Will Deacon wrote:
>> On Tue, Feb 09, 2016 at 09:17:12AM -0800, Shi, Yang wrote:
>>> On 2/9/2016 8:54 AM, Will Deacon wrote:
>>>> On Mon, Feb 08, 2016 at 09:13:09AM -0800, Yang Shi wrote:
>>>>> When boot arm64 kernel with KASAN enabled, the below error is
>>>>> reported by
>>>>> kasan:
>>>>>
>>>>> BUG: KASAN: out-of-bounds in unwind_frame+0xec/0x260 at addr
>>>>> ffffffc064d57ba0
>>>>> Read of size 8 by task pidof/499
>>>>> page:ffffffbdc39355c0 count:0 mapcount:0 mapping:          (null)
>>>>> index:0x0
>>>>> flags: 0x0()
>>>>> page dumped because: kasan: bad access detected
>>>>> CPU: 2 PID: 499 Comm: pidof Not tainted 4.5.0-rc1 #119
>>>>> Hardware name: Freescale Layerscape 2085a RDB Board (DT)
>>>>> Call trace:
>>>>> [<ffffffc00008d078>] dump_backtrace+0x0/0x290
>>>>> [<ffffffc00008d32c>] show_stack+0x24/0x30
>>>>> [<ffffffc0006a981c>] dump_stack+0x8c/0xd8
>>>>> [<ffffffc0002e4400>] kasan_report_error+0x558/0x588
>>>>> [<ffffffc0002e4958>] kasan_report+0x60/0x70
>>>>> [<ffffffc0002e3188>] __asan_load8+0x60/0x78
>>>>> [<ffffffc00008c92c>] unwind_frame+0xec/0x260
>>>>> [<ffffffc000087e60>] get_wchan+0x110/0x160
>>>>> [<ffffffc0003b647c>] do_task_stat+0xb44/0xb68
>>>>> [<ffffffc0003b7730>] proc_tgid_stat+0x40/0x50
>>>>> [<ffffffc0003ac840>] proc_single_show+0x88/0xd8
>>>>> [<ffffffc000345be8>] seq_read+0x370/0x770
>>>>> [<ffffffc00030aba0>] __vfs_read+0xc8/0x1d8
>>>>> [<ffffffc00030c0ec>] vfs_read+0x94/0x168
>>>>> [<ffffffc00030d458>] SyS_read+0xb8/0x128
>>>>> [<ffffffc000086530>] el0_svc_naked+0x24/0x28
>>>>> Memory state around the buggy address:
>>>>>   ffffffc064d57a80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4
>>>>>   ffffffc064d57b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>> ffffffc064d57b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>                                    ^
>>>>>   ffffffc064d57c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>   ffffffc064d57c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>
>>>>> Since the shadow byte pointed by the report is 0, so it may mean it
>>>>> is just hit
>>>>> oob in non-current task. So, disable the instrumentation to silence
>>>>> these
>>>>> warnings.
>>>>
>>>> Curious, but how did you trigger this? I'm just trying to confirm that
>>>> mainline is affected, but my machine boots happily with KASAN and
>>>> STACKTRACE
>>>> selected and I can cat /proc/self/{stack,stat} quite happily.
>>>>
>>>> What am I missing?
>>>
>>> I'm using mainline 4.5-rc1 kernel with gcc 5.2. And, my rootfs is NFS
>>> mounted.
>>>
>>> Not sure if other kernel configs, i.e tracing stuff will have impact
>>> on the
>>> trigger since I'm not using the defconfig.
>>
>> If you could put your .config somewhere, that would be helpful, please.
>
> Attached it. BTW, I run the test on LS2085a RDB board which has 8 A57
> cores. Not sure if it could be reproduced on other boards easily.

This config has GCOV enabled, my test is run with it disabled. So, you 
may need disable it to replicate the trigger.

Regards,
Yang

>
> Yang
>
>>
>> Will
>>
>



From will.deacon at arm.com  Tue Feb  9 09:36:06 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 9 Feb 2016 17:36:06 +0000
Subject: [PATCH 6/6] arm64: compat: Check for AArch32 state
In-Reply-To: <1453980737-6126-7-git-send-email-suzuki.poulose@arm.com>
References: <1453980737-6126-1-git-send-email-suzuki.poulose@arm.com>
 <1453980737-6126-7-git-send-email-suzuki.poulose@arm.com>
Message-ID: <20160209173606.GX22874@arm.com>

On Thu, Jan 28, 2016 at 11:32:17AM +0000, Suzuki K Poulose wrote:
> Make sure we have AArch32 state available for running COMPAT binaries.
> 
> Signed-off-by: Yury Norov <ynorov at caviumnetworks.com>
> [ Added checks for ELF HWCAP, Use cap bit in cap_hwcaps ]
> Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>

[...]

> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> index 8cc2a86..2890b74 100644
> --- a/arch/arm64/kernel/cpuinfo.c
> +++ b/arch/arm64/kernel/cpuinfo.c
> @@ -124,7 +124,8 @@ static int c_show(struct seq_file *m, void *v)
>  		 * software which does already (at least for 32-bit).
>  		 */
>  		seq_puts(m, "Features\t:");
> -		if (personality(current->personality) == PER_LINUX32) {
> +		if (system_supports_32bit_el0() &&
> +			personality(current->personality) == PER_LINUX32) {

Wouldn't it be better to prevent tasks changing to the PER_LINUX32
personality on systems that don't support AArch32 at EL0?

Will


From gabriele.paoloni at huawei.com  Tue Feb  9 09:34:19 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Tue, 9 Feb 2016 17:34:19 +0000
Subject: [RFC PATCH v3 2/3] PCI: hisi: Add ECAM support to HiSilicon PCIe host
 controller
In-Reply-To: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
References: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
Message-ID: <1455039260-6040-3-git-send-email-gabriele.paoloni@huawei.com>

From: gabriele paoloni <gabriele.paoloni at huawei.com>

This patch modifies the current Hip05/Hip06 PCIe host
controller driver to add support for ECAM compliant
platforms.
This is needed in preparation for the ACPI based driver
to allow both DT and ACPI drivers to use the same BIOS
(that configure the Designware iATUs).
This commit doesn't break backward compatibility with
previous non-ECAM platforms.

Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
Signed-off-by: Dongdong Liu <liudongdong3 at huawei.com>
---
 .../devicetree/bindings/pci/hisilicon-pcie.txt     | 15 +++++---
 drivers/pci/host/pcie-designware.c                 |  4 +--
 drivers/pci/host/pcie-designware.h                 |  2 ++
 drivers/pci/host/pcie-hisi.c                       | 40 ++++++++++++++++++++++
 4 files changed, 53 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
index b721bea..5a4c1e7 100644
--- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
@@ -9,10 +9,13 @@ Additional properties are described here:
 
 Required properties
 - compatible: Should contain "hisilicon,hip05-pcie" or "hisilicon,hip06-pcie".
-- reg: Should contain rc_dbi, config registers location and length.
-- reg-names: Must include the following entries:
+- reg: Should contain rc_dbi and  either config or ecam-cfg registers
+       location and length (it depends on the platform BIOS).
+- reg-names: Must include
   "rc_dbi": controller configuration registers;
-  "config": PCIe configuration space registers.
+  and one of the following entries:
+    "config": PCIe configuration space registers for non-ECAM platforms.
+    "ecam-cfg": PCIe configuration space registers for ECAM platforms
 - msi-parent: Should be its_pcie which is an ITS receiving MSI interrupts.
 - port-id: Should be 0, 1, 2 or 3.
 
@@ -23,8 +26,10 @@ Optional properties:
 Hip05 Example (note that Hip06 is the same except compatible):
 	pcie at 0xb0080000 {
 		compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
-		reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0 0x2000>;
-		reg-names = "rc_dbi", "config";
+		reg = <0 0xb0080000 0 0x10000>,
+			  <0x220 0x00000000 0 0x2000>
+			/* or <0x220 0x00100000 0 0x0f00000> for ecam-cfg*/;
+		reg-names = "rc_dbi", "config" /* or "ecam-cfg" */;
 		bus-range = <0  15>;
 		msi-parent = <&its_pcie>;
 		#address-cells = <3>;
diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
index 2171682..5f19ea4 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -69,8 +69,6 @@
 #define PCIE_ATU_FUNC(x)		(((x) & 0x7) << 16)
 #define PCIE_ATU_UPPER_TARGET		0x91C
 
-static struct pci_ops dw_pcie_ops;
-
 int dw_pcie_cfg_read(void __iomem *addr, int size, u32 *val)
 {
 	if ((uintptr_t)addr & (size - 1)) {
@@ -690,7 +688,7 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
 	return dw_pcie_wr_other_conf(pp, bus, devfn, where, size, val);
 }
 
-static struct pci_ops dw_pcie_ops = {
+struct pci_ops dw_pcie_ops = {
 	.read = dw_pcie_rd_conf,
 	.write = dw_pcie_wr_conf,
 };
diff --git a/drivers/pci/host/pcie-designware.h b/drivers/pci/host/pcie-designware.h
index 2356d29..3f42655 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -80,4 +80,6 @@ int dw_pcie_link_up(struct pcie_port *pp);
 void dw_pcie_setup_rc(struct pcie_port *pp);
 int dw_pcie_host_init(struct pcie_port *pp);
 
+extern struct pci_ops dw_pcie_ops;
+
 #endif /* _PCIE_DESIGNWARE_H */
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index 458d0f8..d3e2047 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -43,6 +43,18 @@ struct pcie_soc_ops {
 	int (*hisi_pcie_link_up)(struct hisi_pcie *pcie);
 };
 
+static inline int hisi_rd_ecam_conf(struct pcie_port *pp, struct pci_bus *bus,
+		unsigned int devfn, int where, int size, u32 *value)
+{
+	return pci_generic_config_read(bus, devfn, where, size, value);
+}
+
+static inline int hisi_wr_ecam_conf(struct pcie_port *pp, struct pci_bus *bus,
+		unsigned int devfn, int where, int size, u32 value)
+{
+	return pci_generic_config_write(bus, devfn, where, size, value);
+}
+
 static inline int hisi_pcie_cfg_read(struct pcie_port *pp, int where,
 		int size, u32 *val)
 {
@@ -72,6 +84,17 @@ struct pcie_host_ops hisi_pcie_host_ops = {
 		.link_up = hisi_pcie_link_up,
 };
 
+static void __iomem *hisi_pci_map_cfg_bus_cam(struct pci_bus *bus,
+					     unsigned int devfn,
+					     int where)
+{
+	void __iomem *addr;
+	struct pcie_port *pp = bus->sysdata;
+
+	addr = pp->va_cfg1_base + where;
+
+	return addr;
+}
 
 static int hisi_add_pcie_port(struct pcie_port *pp,
 				     struct platform_device *pdev)
@@ -137,6 +160,23 @@ static int hisi_pcie_probe(struct platform_device *pdev)
 
 	hisi_pcie->pp.dbi_base = hisi_pcie->reg_base;
 
+	reg = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam-cfg");
+	if (reg) {
+		/* ECAM driver version */
+		hisi_pcie->pp.va_cfg0_base =
+				devm_ioremap_resource(&pdev->dev, reg);
+		if (IS_ERR(hisi_pcie->pp.va_cfg0_base)) {
+			dev_err(pp->dev, "cannot get ecam-cfg\n");
+			return PTR_ERR(hisi_pcie->pp.va_cfg0_base);
+		}
+		hisi_pcie->pp.va_cfg1_base = hisi_pcie->pp.va_cfg0_base;
+
+		dw_pcie_ops.map_bus = hisi_pci_map_cfg_bus_cam;
+
+		hisi_pcie_host_ops.rd_other_conf = hisi_rd_ecam_conf;
+		hisi_pcie_host_ops.wr_other_conf = hisi_wr_ecam_conf;
+	}
+
 	ret = hisi_add_pcie_port(pp, pdev);
 	if (ret)
 		return ret;
-- 
1.9.1




From gabriele.paoloni at huawei.com  Tue Feb  9 09:34:20 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Tue, 9 Feb 2016 17:34:20 +0000
Subject: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for HiSilicon
 SoCs Host Controllers
In-Reply-To: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
References: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
Message-ID: <1455039260-6040-4-git-send-email-gabriele.paoloni@huawei.com>

From: gabriele paoloni <gabriele.paoloni at huawei.com>

This patch adds specific quirks for PCI config space accessors,
it uses _HID to decide whether to hook pci_ops or not.

Signed-off-by: Dongdong Liu <liudongdong3 at huawei.com>
Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
---
 MAINTAINERS                       |   1 +
 drivers/pci/host/Kconfig          |   8 ++
 drivers/pci/host/Makefile         |   1 +
 drivers/pci/host/pcie-hisi-acpi.c | 188 ++++++++++++++++++++++++++++++++++++++
 drivers/pci/host/pcie-hisi.c      |   2 -
 drivers/pci/host/pcie-hisi.h      |   2 +
 6 files changed, 200 insertions(+), 2 deletions(-)
 create mode 100644 drivers/pci/host/pcie-hisi-acpi.c

diff --git a/MAINTAINERS b/MAINTAINERS
index d69f436..f184c3e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8412,6 +8412,7 @@ F:	Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
 F:	drivers/pci/host/pcie-hisi.h
 F:	drivers/pci/host/pcie-hisi.c
 F:	drivers/pci/host/pcie-hisi-common.c
+F:	drivers/pci/host/pcie-hisi-acpi.c
 
 PCIE DRIVER FOR QUALCOMM MSM
 M:     Stanimir Varbanov <svarbanov at mm-sol.com>
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 75a6054..65b1add 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -181,6 +181,14 @@ config PCI_HISI
 	  Say Y here if you want PCIe controller support on HiSilicon
 	  Hip05 and Hip06 SoCs
 
+config PCI_HISI_ACPI
+	depends on ACPI
+	bool "HiSilicon Hip05 and Hip06 SoCs ACPI PCIe controllers"
+	select ACPI_PCI_HOST_GENERIC
+	help
+	  Say Y here if you want ACPI PCIe controller support on HiSilicon
+	  Hip05 and Hip06 SoCs
+
 config PCIE_QCOM
 	bool "Qualcomm PCIe controller"
 	depends on ARCH_QCOM && OF
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 8c93c0f..57e4379 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -21,4 +21,5 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
 obj-$(CONFIG_PCI_HISI) += pcie-hisi.o pcie-hisi-common.o
+obj-$(CONFIG_PCI_HISI_ACPI) += pcie-hisi-acpi.o pcie-hisi-common.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
diff --git a/drivers/pci/host/pcie-hisi-acpi.c b/drivers/pci/host/pcie-hisi-acpi.c
new file mode 100644
index 0000000..3605260
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi-acpi.c
@@ -0,0 +1,188 @@
+/*
+ * PCIe host controller driver for HiSilicon HipXX SoCs
+ *
+ * Copyright (C) 2016 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Dongdong Liu <liudongdong3 at huawei.com>
+ *         Gabriele Paoloni <gabriele.paoloni at huawei.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.
+ */
+#include <linux/interrupt.h>
+#include <linux/acpi.h>
+#include <linux/ecam.h>
+#include <linux/pci.h>
+#include <linux/pci-acpi.h>
+#include "pcie-hisi.h"
+
+#define GET_PCIE_LINK_STATUS  0x0
+
+/* uuid 6d30f553-836c-408e-b6ad-45bccc957949 */
+const u8 hisi_pcie_acpi_dsm_uuid[] = {
+	0x53, 0xf5, 0x30, 0x6d, 0x6c, 0x83, 0x8e, 0x40,
+	0xb6, 0xad, 0x45, 0xbc, 0xcc, 0x95, 0x79, 0x49
+};
+
+static const struct acpi_device_id hisi_pcie_ids[] = {
+	{"HISI0080", 0},
+	{"", 0},
+};
+
+static int hisi_pcie_get_addr(struct acpi_pci_root *root, const char *name,
+				void __iomem **addr)
+{
+	struct acpi_device *device;
+	u64 base;
+	u64 size;
+	u32 buf[4];
+	int ret;
+
+	device =  root->device;
+	ret = fwnode_property_read_u32_array(&device->fwnode, name,
+					buf, ARRAY_SIZE(buf));
+	if (ret) {
+		dev_err(&device->dev, "can't get %s\n", name);
+		return ret;
+	}
+
+	base = ((u64)buf[0] << 32) | buf[1];
+	size =  ((u64)buf[2] << 32) | buf[3];
+	*addr = devm_ioremap(&device->dev, base, size);
+	if (!(*addr)) {
+		dev_err(&device->dev, "error with ioremap\n");
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+
+static int hisi_pcie_link_up_acpi(struct acpi_pci_root *root)
+{
+	u32 val;
+	struct acpi_device *device;
+	union acpi_object *obj;
+
+	device = root->device;
+	obj = acpi_evaluate_dsm(device->handle,
+		hisi_pcie_acpi_dsm_uuid, 0,
+		GET_PCIE_LINK_STATUS, NULL);
+
+	if (!obj  ||  obj->type != ACPI_TYPE_INTEGER)  {
+		dev_err(&device->dev, "can't get link status from _DSM\n");
+		return 0;
+	}
+	val = obj->integer.value;
+
+	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
+
+}
+
+/*
+ * Retrieve rc_dbi base and size from _DSD
+ * Name (_DSD, Package () {
+ *	ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+ *	Package () {
+ *	Package () {"rc-dbi", Package () { 0x0, 0xb0080000, 0x0, 0x10000 }},
+ *	}
+ *	})
+ */
+static int hisi_pcie_init(struct acpi_pci_root *root)
+{
+	int ret;
+	struct acpi_device *device;
+	void __iomem *reg_base;
+
+	device =  root->device;
+	ret = hisi_pcie_get_addr(root, "rc-dbi", &reg_base);
+	if (ret) {
+		dev_err(&device->dev, "can't get rc-dbi\n");
+		return ret;
+	}
+
+	root->sysdata = reg_base;
+	return 0;
+}
+
+static int hisi_pcie_match(struct pci_mcfg_fixup *fixup,
+			struct acpi_pci_root *root)
+{
+	int ret;
+	struct acpi_device *device;
+
+	device = root->device;
+	ret = acpi_match_device_ids(device, hisi_pcie_ids);
+	if (ret)
+		return 0;
+
+	ret = hisi_pcie_init(root);
+	if (ret)
+		dev_warn(&device->dev, "hisi pcie init fail\n");
+
+	return 1;
+}
+
+static int hisi_pcie_acpi_valid_config(struct acpi_pci_root *root,
+				struct pci_bus *bus, int dev)
+{
+	/* If there is no link, then there is no device */
+	if (bus->number != root->secondary.start) {
+		if (!hisi_pcie_link_up_acpi(root))
+			return 0;
+	}
+
+	/* access only one slot on each root port */
+	if (bus->number == root->secondary.start && dev > 0)
+		return 0;
+
+	/*
+	 * do not read more than one device on the bus directly attached
+	 * to RC's (Virtual Bridge's) DS side.
+	 */
+	if (bus->primary == root->secondary.start && dev > 0)
+		return 0;
+
+	return 1;
+}
+
+static int hisi_pcie_acpi_rd_conf(struct pci_bus *bus, u32 devfn, int where,
+		int size, u32 *val)
+{
+	struct acpi_pci_root *root = bus->sysdata;
+	void __iomem *reg_base = root->sysdata;
+
+	if (hisi_pcie_acpi_valid_config(root, bus, PCI_SLOT(devfn)) == 0)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	if (bus->number == root->secondary.start)
+		return hisi_pcie_common_cfg_read(reg_base, where, size, val);
+
+	return pci_generic_config_read(bus, devfn, where, size, val);
+}
+
+static int hisi_pcie_acpi_wr_conf(struct pci_bus *bus, u32 devfn,
+		int where, int size, u32 val)
+{
+	struct acpi_pci_root *root = bus->sysdata;
+	void __iomem *reg_base = root->sysdata;
+
+	if (hisi_pcie_acpi_valid_config(root, bus, PCI_SLOT(devfn)) == 0)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	if (bus->number == root->secondary.start)
+		return hisi_pcie_common_cfg_write(reg_base, where, size, val);
+
+	return pci_generic_config_write(bus, devfn, where, size, val);
+}
+
+struct pci_ops hisi_pcie_acpi_ops = {
+	.map_bus = pci_mcfg_dev_base,
+	.read = hisi_pcie_acpi_rd_conf,
+	.write = hisi_pcie_acpi_wr_conf,
+};
+
+
+DECLARE_ACPI_MCFG_FIXUP(NULL, hisi_pcie_match, &hisi_pcie_acpi_ops,
+	PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index d3e2047..d1ef346 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -23,8 +23,6 @@
 #include "pcie-designware.h"
 #include "pcie-hisi.h"
 
-#define PCIE_LTSSM_LINKUP_STATE				0x11
-#define PCIE_LTSSM_STATE_MASK				0x3F
 #define PCIE_SUBCTRL_SYS_STATE4_REG			0x6818
 #define PCIE_SYS_STATE4						0x31c
 #define PCIE_HIP06_CTRL_OFF					0x1000
diff --git a/drivers/pci/host/pcie-hisi.h b/drivers/pci/host/pcie-hisi.h
index 29e0790..45cf0fd 100644
--- a/drivers/pci/host/pcie-hisi.h
+++ b/drivers/pci/host/pcie-hisi.h
@@ -14,6 +14,8 @@
 #ifndef PCIE_HISI_H_
 #define PCIE_HISI_H_
 
+#define PCIE_LTSSM_LINKUP_STATE				0x11
+#define PCIE_LTSSM_STATE_MASK				0x3F
 
 int hisi_pcie_common_cfg_read(void __iomem *reg_base, int where, int size,
 			      u32 *val);
-- 
1.9.1




From tony at atomide.com  Tue Feb  9 09:38:08 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 9 Feb 2016 09:38:08 -0800
Subject: N900 sleep mode (in 4.5-rc0, if that matters)
In-Reply-To: <20160209172403.GK19432@atomide.com>
References: <20160126140010.GA29723@amd> <20160126172527.GY3500@atomide.com>
 <20160130200244.GA30429@amd> <20160130201452.GC30429@amd>
 <20160130221509.GA28644@amd> <20160201181316.GM19432@atomide.com>
 <20160201211736.GA11283@amd> <20160201221111.GP19432@atomide.com>
 <20160207212316.GA6147@amd> <20160209172403.GK19432@atomide.com>
Message-ID: <20160209173807.GL19432@atomide.com>

* Tony Lindgren <tony at atomide.com> [160209 09:26]:
> * Pavel Machek <pavel at ucw.cz> [160207 13:24]:
> > Hi!
> > 
> > > > (I assume I have to insmod and rmmod, right? Because powersave is not
> > > > entered if I simply compile-out usb).
> > > 
> > > Depending on what the bootloader does and probably also if
> > > USB was used during the booting.. So yeah you may need to modprobe
> > > and then rmmod.
> > > 
> > > > Would you have commit ids for those rmmod fixes? It might be good to
> > > > push them into stable, and I should try again with them applied...
> > > 
> > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications")
> > > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable")
> > 
> > Ok, with that, I can insmod and rmmod. But I still get:
> > 
> > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000
> 
> I think the cm_idlest_per is fine.
> 
> > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042
> > 0000000d 48004a28 (fa004a28) cm_idlest3_core
> 
> Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go
> down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ?
> 
> If not, the're PM runtime missing or broken somewhere.
> 
> FYI, below is my omap3 usb test script that I use to start and
> stop USB, it also works on n900. And after stopping it n900
> continues hitting deeper idle states just fine.
> 
> That is with these two phy patches applied on v4.5-rc3:
> 
> "phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload")
> "phy: twl4030-usb: Relase usb phy on unload")
> 
> Maybe I gave you wrong info on the USB patches needed.. But these
> two above are needed on v4.5-rc3. And looks like Kishon has now
> applied them.
> 
> Oh and I also have the MMC PM runtime regression fix here that I
> have not yet posted. Will post today. But I guess you're on
> v4.4 right now still.

And looks like the USB RNDIS gadget has some extra issues
breaking reboot. So I'd stick to ECM if possible and leave out
RNDIS completely.

Tony


From gabriele.paoloni at huawei.com  Tue Feb  9 09:34:17 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Tue, 9 Feb 2016 17:34:17 +0000
Subject: [RFC PATCH v3 0/3] Add ACPI support for HiSilicon PCIe Host
 Controllers
Message-ID: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>

From: gabriele paoloni <gabriele.paoloni at huawei.com>

This patchset adds ACPI support for the HiSilicon Hip05/Hip06 SoC PCIe controllers
The four patches respectively:
        - re-architect the current HiSilicon driver to make it scalable to the
          new ACPI quirks
        - rework the current HiSilicon driver to add support for ECAM platforms
        - adds the HiSilicon ACPI specific quirks.

   This patchset  is based on
   https://github.com/semihalf-nowicki-tomasz/linux.git
   branch pci-acpi-v4

Changes v1 -> v2: removed the ACPI quirks dependency on Designware framework

Changes v2 -> v3: kept backward compatibility for non-ECAM platforms

gabriele paoloni (3):
  PCI: hisi: re-architect Hip05/Hip06 controllers driver to preapare for
    ACPI
  PCI: hisi: Add ECAM support to HiSilicon PCIe host controller
  PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

 .../devicetree/bindings/pci/hisilicon-pcie.txt     |  15 +-
 MAINTAINERS                                        |   3 +
 drivers/pci/host/Kconfig                           |   8 +
 drivers/pci/host/Makefile                          |   3 +-
 drivers/pci/host/pcie-designware.c                 |   4 +-
 drivers/pci/host/pcie-designware.h                 |   2 +
 drivers/pci/host/pcie-hisi-acpi.c                  | 188 +++++++++++++++++++++
 drivers/pci/host/pcie-hisi-common.c                |  73 ++++++++
 drivers/pci/host/pcie-hisi.c                       | 149 ++++++++--------
 drivers/pci/host/pcie-hisi.h                       |  25 +++
 10 files changed, 382 insertions(+), 88 deletions(-)
 create mode 100644 drivers/pci/host/pcie-hisi-acpi.c
 create mode 100644 drivers/pci/host/pcie-hisi-common.c
 create mode 100644 drivers/pci/host/pcie-hisi.h

-- 
1.9.1




From timur at codeaurora.org  Tue Feb  9 09:39:26 2016
From: timur at codeaurora.org (Timur Tabi)
Date: Tue, 9 Feb 2016 11:39:26 -0600
Subject: [PATCH v11 4/4] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <1455037240-16192-5-git-send-email-fu.wei@linaro.org>
References: <1455037240-16192-1-git-send-email-fu.wei@linaro.org>
 <1455037240-16192-5-git-send-email-fu.wei@linaro.org>
Message-ID: <56BA244E.1020402@codeaurora.org>

fu.wei at linaro.org wrote:

> +		if (!action)
> +			dev_warn(dev, "fall back to signle stage mode.\n");

"falling back to single stage mode"

Acked-by: Timur Tabi <timur at codeaurora.org>

The whole "calculate the timeouts different if 'action' is enabled" 
seems clunky to me, but I can't think of a better way to handle it.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation collaborative project.


From juri.lelli at arm.com  Tue Feb  9 09:40:52 2016
From: juri.lelli at arm.com (Juri Lelli)
Date: Tue, 9 Feb 2016 17:40:52 +0000
Subject: [PATCH v3 0/6] CPUs capacity information for heterogeneous systems
In-Reply-To: <56BA221D.1030907@linaro.org>
References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com>
 <56B92BF4.4030405@linaro.org> <20160209103748.GP11415@e106622-lin>
 <56BA221D.1030907@linaro.org>
Message-ID: <20160209174052.GT11415@e106622-lin>

On 09/02/16 09:30, Steve Muckle wrote:
> On 02/09/2016 02:37 AM, Juri Lelli wrote:
> >> I'm still concerned that there's no way to obtain optimal boot time on a
> >> > heterogeneous system. Either the dynamic benchmarking is enabled, adding
> >> > 1 sec, or the benchmarking is skipped, and task distribution on the
> >> > heterogeneous CPUs is determined by the platform's CPU numbering and
> >> > chance, potentially impacting performance nondeterministically until
> >> > userspace sets the correct capacity values via sysfs.
> >> > 
> >> > I believe you tested the impact on boot time of using equal capacity
> >> > values and saw little difference. I'm wondering though, what was the CPU
> >> > numbering on that target?
> >> > 
> >
> > My targets (Juno and TC2) had big cluster on 1,2 and little on the
> > remaining cpus. Why do you think this might matter?
> 
> There's a natural bias in the scheduler AFAIK towards lower-numbered
> CPUs since they are typically scanned in numerically ascending order. So
> when all capacities are initially defaulted to be the same I think
> you'll be more likely to use the lower numbered CPUs.
> 
> I'd be curious what the performance penalty is on a b.L system where the
> lowest numbered CPUs are small. I don't have such a target but maybe
> it's possible to compare booting just with bigs vs just with littles, at
> least until userspace intializes and a script can bring up the others,
> which is the same point at which capacities could be properly set. That
> would give something of an upper bound.
> 

Yeah. I could run some tests along this line. It should give us a rough
idea about how much we are leaving on the table.

> > Anyway, IMHO boot time performance is not what we are targeting here, so
> > I wouldn't be too worried about this particular point.
> 
> It may not be the most important thing but it is a factor worth
> considering - as mentioned earlier there are applications where boot
> time is critical such as automotive. It seems unfortunate that actual
> performance may be left on the table due to (IMO anyway) a tenuous
> concern over DT semantics. But it looks like that may just be my
> position :/ .
> 

Don't get me wrong Steve. I agree with you and I tried to defend the DT
approach as much as I could. I still think that it is the best solution
(much more cleaner and simpler), but it seems that there is no way we
can make it happen. Or has this discussion we are having changed things
in the meantime? :)

Thanks,

- Juri


From s-anna at ti.com  Tue Feb  9 09:40:37 2016
From: s-anna at ti.com (Suman Anna)
Date: Tue, 9 Feb 2016 11:40:37 -0600
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
Message-ID: <56BA2495.9020407@ti.com>

Hi Paul,

On 02/09/2016 02:49 AM, Paul Walmsley wrote:
> On Mon, 8 Feb 2016, Suman Anna wrote:
> 
>> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
>>> On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:
>>>
>>>> Paul, what do you think is the best way forward to perform reset?
>>>
>>> Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
>>> Those often need special reset handling to ensure that WFI/HLT-like 
>>> instructions are executed after reset.  This special handling ensures that 
>>> the IP blocks' bus initiator interfaces indicate that they are in standby 
>>> to the PRCM - thus allowing power management for the rest of the chip to 
>>> work correctly.
>>>
>>> But that doesn't seem to be the case with PCIe - and maybe others - 
>>> possibly some of the MMUs?  
>>
>> Yeah, the sequencing between clocks and resets would still be the same
>> for MMUs, so, adding the custom flags for MMUs is fine.
> 
> I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs.  
> We've stated that the main point of the custom hardreset code is to handle 
> processors that need to be placed into WFI/HLT, but it doesn't seem like 
> there would be an equivalent for MMUs.  Thoughts?

The current OMAP IOMMU code already leverages the pdata ops for
performing the resets, so not adding the flags would also require
additional changes in the driver.

Also, the reset lines controlling the MMUs actually also manage the
reset for all the other sub-modules other than the processor cores
within the sub-systems. We have currently different issues (see [1] for
eg. around the IPU sub-system entering RET in between), so from a PM
point of view, we do prefer to place the MMUs also in reset when we are
runtime suspended.

regards
Suman

[1]
http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=a7db749a8a0fdfe7baa185db9f5071789a889061




From gabriele.paoloni at huawei.com  Tue Feb  9 09:34:18 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Tue, 9 Feb 2016 17:34:18 +0000
Subject: [RFC PATCH v3 1/3] PCI: hisi: re-architect Hip05/Hip06 controllers
 driver to preapare for ACPI
In-Reply-To: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
References: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
Message-ID: <1455039260-6040-2-git-send-email-gabriele.paoloni@huawei.com>

From: gabriele paoloni <gabriele.paoloni at huawei.com>

re-architect the Hip05/Hip06 host controllers driver to prepare
for the ACPI based driver.
The common functions used also by the ACPI driver have been grouped
into a new "common" file

Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
---
 MAINTAINERS                         |   2 +
 drivers/pci/host/Makefile           |   2 +-
 drivers/pci/host/pcie-hisi-common.c |  73 ++++++++++++++++++++++
 drivers/pci/host/pcie-hisi.c        | 119 +++++++++++-------------------------
 drivers/pci/host/pcie-hisi.h        |  23 +++++++
 5 files changed, 135 insertions(+), 84 deletions(-)
 create mode 100644 drivers/pci/host/pcie-hisi-common.c
 create mode 100644 drivers/pci/host/pcie-hisi.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 30aca4a..d69f436 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8409,7 +8409,9 @@ M:	Gabriele Paoloni <gabriele.paoloni at huawei.com>
 L:	linux-pci at vger.kernel.org
 S:	Maintained
 F:	Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
+F:	drivers/pci/host/pcie-hisi.h
 F:	drivers/pci/host/pcie-hisi.c
+F:	drivers/pci/host/pcie-hisi-common.c
 
 PCIE DRIVER FOR QUALCOMM MSM
 M:     Stanimir Varbanov <svarbanov at mm-sol.com>
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 7b2f20c..8c93c0f 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -20,5 +20,5 @@ obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
 obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
-obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
+obj-$(CONFIG_PCI_HISI) += pcie-hisi.o pcie-hisi-common.o
 obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
diff --git a/drivers/pci/host/pcie-hisi-common.c b/drivers/pci/host/pcie-hisi-common.c
new file mode 100644
index 0000000..6dfb4c3
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi-common.c
@@ -0,0 +1,73 @@
+/*
+ * PCIe host controller common functions for HiSilicon SoCs
+ *
+ * Copyright (C) 2015 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Zhou Wang <wangzhou1 at hisilicon.com>
+ *         Dacai Zhu <zhudacai at hisilicon.com>
+ *         Gabriele Paoloni <gabriele.paoloni at huawei.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.
+ */
+
+#include <linux/acpi.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of_pci.h>
+#include <linux/regmap.h>
+
+#include "pcie-designware.h"
+#include "pcie-hisi.h"
+
+/* HipXX PCIe host only supports 32-bit config access */
+int hisi_pcie_common_cfg_read(void __iomem *reg_base, int where, int size,
+			      u32 *val)
+{
+	u32 reg;
+	u32 reg_val;
+	void *walker = &reg_val;
+
+	walker += (where & 0x3);
+	reg = where & ~0x3;
+	reg_val = readl(reg_base + reg);
+
+	if (size == 1)
+		*val = *(u8 __force *) walker;
+	else if (size == 2)
+		*val = *(u16 __force *) walker;
+	else if (size == 4)
+		*val = reg_val;
+	else
+		return PCIBIOS_BAD_REGISTER_NUMBER;
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+/* HipXX PCIe host only supports 32-bit config access */
+int hisi_pcie_common_cfg_write(void __iomem *reg_base, int where, int  size,
+				u32 val)
+{
+	u32 reg_val;
+	u32 reg;
+	void *walker = &reg_val;
+
+	walker += (where & 0x3);
+	reg = where & ~0x3;
+	if (size == 4)
+		writel(val, reg_base + reg);
+	else if (size == 2) {
+		reg_val = readl(reg_base + reg);
+		*(u16 __force *) walker = val;
+		writel(val, reg_base + reg);
+	} else if (size == 1) {
+		reg_val = readl(reg_base + reg);
+		*(u8 __force *) walker = val;
+		writel(val, reg_base + reg);
+	} else
+		return PCIBIOS_BAD_REGISTER_NUMBER;
+
+	return PCIBIOS_SUCCESSFUL;
+}
diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
index 3e98d4e..458d0f8 100644
--- a/drivers/pci/host/pcie-hisi.c
+++ b/drivers/pci/host/pcie-hisi.c
@@ -21,6 +21,7 @@
 #include <linux/regmap.h>
 
 #include "pcie-designware.h"
+#include "pcie-hisi.h"
 
 #define PCIE_LTSSM_LINKUP_STATE				0x11
 #define PCIE_LTSSM_STATE_MASK				0x3F
@@ -30,12 +31,6 @@
 
 #define to_hisi_pcie(x)	container_of(x, struct hisi_pcie, pp)
 
-struct hisi_pcie;
-
-struct pcie_soc_ops {
-	int (*hisi_pcie_link_up)(struct hisi_pcie *pcie);
-};
-
 struct hisi_pcie {
 	struct regmap *subctrl;
 	void __iomem *reg_base;
@@ -44,87 +39,24 @@ struct hisi_pcie {
 	struct pcie_soc_ops *soc_ops;
 };
 
-static inline void hisi_pcie_apb_writel(struct hisi_pcie *pcie,
-					u32 val, u32 reg)
-{
-	writel(val, pcie->reg_base + reg);
-}
-
-static inline u32 hisi_pcie_apb_readl(struct hisi_pcie *pcie, u32 reg)
-{
-	return readl(pcie->reg_base + reg);
-}
-
-/* HipXX PCIe host only supports 32-bit config access */
-static int hisi_pcie_cfg_read(struct pcie_port *pp, int where, int size,
-			      u32 *val)
-{
-	u32 reg;
-	u32 reg_val;
-	struct hisi_pcie *pcie = to_hisi_pcie(pp);
-	void *walker = &reg_val;
-
-	walker += (where & 0x3);
-	reg = where & ~0x3;
-	reg_val = hisi_pcie_apb_readl(pcie, reg);
-
-	if (size == 1)
-		*val = *(u8 __force *) walker;
-	else if (size == 2)
-		*val = *(u16 __force *) walker;
-	else if (size == 4)
-		*val = reg_val;
-	else
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	return PCIBIOS_SUCCESSFUL;
-}
+struct pcie_soc_ops {
+	int (*hisi_pcie_link_up)(struct hisi_pcie *pcie);
+};
 
-/* HipXX PCIe host only supports 32-bit config access */
-static int hisi_pcie_cfg_write(struct pcie_port *pp, int where, int  size,
-				u32 val)
+static inline int hisi_pcie_cfg_read(struct pcie_port *pp, int where,
+		int size, u32 *val)
 {
-	u32 reg_val;
-	u32 reg;
 	struct hisi_pcie *pcie = to_hisi_pcie(pp);
-	void *walker = &reg_val;
-
-	walker += (where & 0x3);
-	reg = where & ~0x3;
-	if (size == 4)
-		hisi_pcie_apb_writel(pcie, val, reg);
-	else if (size == 2) {
-		reg_val = hisi_pcie_apb_readl(pcie, reg);
-		*(u16 __force *) walker = val;
-		hisi_pcie_apb_writel(pcie, reg_val, reg);
-	} else if (size == 1) {
-		reg_val = hisi_pcie_apb_readl(pcie, reg);
-		*(u8 __force *) walker = val;
-		hisi_pcie_apb_writel(pcie, reg_val, reg);
-	} else
-		return PCIBIOS_BAD_REGISTER_NUMBER;
-
-	return PCIBIOS_SUCCESSFUL;
-}
 
-static int hisi_pcie_link_up_hip05(struct hisi_pcie *hisi_pcie)
-{
-	u32 val;
-
-	regmap_read(hisi_pcie->subctrl, PCIE_SUBCTRL_SYS_STATE4_REG +
-		    0x100 * hisi_pcie->port_id, &val);
-
-	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
+	return hisi_pcie_common_cfg_read(pcie->reg_base, where, size, val);
 }
 
-static int hisi_pcie_link_up_hip06(struct hisi_pcie *hisi_pcie)
+static inline int hisi_pcie_cfg_write(struct pcie_port *pp, int where,
+		int size, u32 val)
 {
-	u32 val;
-
-	val = hisi_pcie_apb_readl(hisi_pcie, PCIE_HIP06_CTRL_OFF +
-			PCIE_SYS_STATE4);
+	struct hisi_pcie *pcie = to_hisi_pcie(pp);
 
-	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
+	return hisi_pcie_common_cfg_write(pcie->reg_base, where, size, val);
 }
 
 static int hisi_pcie_link_up(struct pcie_port *pp)
@@ -134,12 +66,13 @@ static int hisi_pcie_link_up(struct pcie_port *pp)
 	return hisi_pcie->soc_ops->hisi_pcie_link_up(hisi_pcie);
 }
 
-static struct pcie_host_ops hisi_pcie_host_ops = {
-	.rd_own_conf = hisi_pcie_cfg_read,
-	.wr_own_conf = hisi_pcie_cfg_write,
-	.link_up = hisi_pcie_link_up,
+struct pcie_host_ops hisi_pcie_host_ops = {
+		.rd_own_conf = hisi_pcie_cfg_read,
+		.wr_own_conf = hisi_pcie_cfg_write,
+		.link_up = hisi_pcie_link_up,
 };
 
+
 static int hisi_add_pcie_port(struct pcie_port *pp,
 				     struct platform_device *pdev)
 {
@@ -215,6 +148,26 @@ static int hisi_pcie_probe(struct platform_device *pdev)
 	return 0;
 }
 
+static int hisi_pcie_link_up_hip05(struct hisi_pcie *hisi_pcie)
+{
+	u32 val;
+
+	regmap_read(hisi_pcie->subctrl, PCIE_SUBCTRL_SYS_STATE4_REG +
+		    0x100 * hisi_pcie->port_id, &val);
+
+	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
+}
+
+static int hisi_pcie_link_up_hip06(struct hisi_pcie *hisi_pcie)
+{
+	u32 val;
+
+	val = readl(hisi_pcie->reg_base + PCIE_HIP06_CTRL_OFF +
+			PCIE_SYS_STATE4);
+
+	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
+}
+
 static struct pcie_soc_ops hip05_ops = {
 		&hisi_pcie_link_up_hip05
 };
diff --git a/drivers/pci/host/pcie-hisi.h b/drivers/pci/host/pcie-hisi.h
new file mode 100644
index 0000000..29e0790
--- /dev/null
+++ b/drivers/pci/host/pcie-hisi.h
@@ -0,0 +1,23 @@
+/*
+ * PCIe host controller driver for HiSilicon SoCs
+ *
+ * Copyright (C) 2015 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Author: Zhou Wang <wangzhou1 at hisilicon.com>
+ *         Dacai Zhu <zhudacai at hisilicon.com>
+ *         Gabriele Paoloni <gabriele.paoloni at huawei.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.
+ */
+#ifndef PCIE_HISI_H_
+#define PCIE_HISI_H_
+
+
+int hisi_pcie_common_cfg_read(void __iomem *reg_base, int where, int size,
+			      u32 *val);
+int hisi_pcie_common_cfg_write(void __iomem *reg_base, int where, int  size,
+				u32 val);
+
+#endif /* PCIE_HISI_H_ */
-- 
1.9.1




From dmitry.torokhov at gmail.com  Tue Feb  9 09:43:51 2016
From: dmitry.torokhov at gmail.com (Dmitry Torokhov)
Date: Tue, 9 Feb 2016 09:43:51 -0800
Subject: [PATCH 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <3b53af6b6c6735d10cb88518c8b8a0ae@mail.gmail.com>
References: <1455008277-8312-1-git-send-email-raveendra.padasalagi@broadcom.com>
 <1455008277-8312-2-git-send-email-raveendra.padasalagi@broadcom.com>
 <2631849.GeOulu78vx@wuerfel>
 <3b53af6b6c6735d10cb88518c8b8a0ae@mail.gmail.com>
Message-ID: <20160209174351.GC40460@dtor-ws>

On Tue, Feb 09, 2016 at 10:25:26PM +0530, Raveendra Padasalagi wrote:
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > Sent: 09 February 2016 16:34
> > To: Raveendra Padasalagi
> > Cc: Dmitry Torokhov; Russell King; devicetree at vger.kernel.org;
> linux-arm-
> > kernel at lists.infradead.org; linux-input at vger.kernel.org; Rob Herring;
> Pawel
> > Moll; Mark Rutland; Ian Campbell; Kumar Gala; Jonathan Richardson; Jon
> > Mason; Florian Fainelli; Ray Jui; Scott Branden;
> linux-kernel at vger.kernel.org;
> > bcm-kernel-feedback-list at broadcom.com
> > Subject: Re: [PATCH 1/3] input: cygnus-update touchscreen dt node
> document
> >
> > On Tuesday 09 February 2016 14:27:55 Raveendra Padasalagi wrote:
> > > +
> > > +One of the below 2 property is mandatory.
> > > +- ts_syscon: handler of syscon node defining physical base address
> > > +  of the controller and length of memory mapped region.
> > > +  If this property is selected please make sure MFD_SYSCON config
> > > +  is enabled in the defconfig file.
> > > +or
> > > +- reg: physical base address of the controller and length of memory
> > > +  mapped region.
> > > +
> > >  - clocks:  The clock provided by the SOC to driver the tsc
> > >  - clock-name:  name for the clock
> > >  - interrupts: The touchscreen controller's interrupt @@ -54,12 +62,16
> > > @@ Optional properties:
> > >  - touchscreen-inverted-y: Y axis is inverted (boolean)
> > >
> > >  Example:
> > > +       ts_adc_syscon: ts_adc_syscon at 0x180a6000 {
> > > +               compatible = "syscon";
> > > +               reg = <0x180a6000 0xc30>;
> > > +       };
> > >
> > >         touchscreen: tsc at 0x180A6000 {
> > >                 compatible = "brcm,iproc-touchscreen";
> > >                 #address-cells = <1>;
> > >                 #size-cells = <1>;
> > > -               reg = <0x180A6000 0x40>;
> > > +               syscon = <&ts_adc_syscon>;
> > >                 clocks = <&adc_clk>;
> > >                 clock-names = "tsc_clk";
> > >                 interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
> >
> > This doesn't seem right: For one thing, it's an incompatible binding
> change which
> > you should try to avoid.
> 
> > Worse, the syscon has a name indicating that it really has a particular
> function,
> > but the name is completely generic (just "syscon"). Please add a
> specific
> > compatible string identifying the device that owns the registers, and
> put any
> > other associated properties (clocks, interrupts, ...) that are for that
> device in
> > general rather than just the touchscreen in there.
> 
> By mistake "syscon" name is documented in "touchscreen" label above. In
> the
> touchscreen driver code and .dtsi file it's named and used as "ts_syscon".
> Please refer https://lkml.org/lkml/2016/2/9/71 for the changes.
> Let me know if this ok. I will correct the documentation in the next
> patch.
> 
> > Your changelog text fails to describe why you do this change in the
> first place,
> > and why you can't do it in a backward-compatible way, so please rewrite
> that
> > text.
> 
> Yes, I will update the change log in the next patch.
> 
> In Cygnus SOC, Touch screen controller registers are shared with ADC and
> flex timer IP's.
> Using readl/writel could lead to race condition. So this patch is
> introduced to take care
> mutually exclusive access of register's in such a case.
> 
> In the platform's where touchscreen register's are not shared normal
> readl/writel
> could be used.

Are there currently platforms where the registers are not shared? If we
have to use regmap to correctly update registers (and thus we need
syscon) then I wonder if we should even attempt to support direct
register access by the driver.

> 
> Based on the dt  property entry "reg" or "ts_syscon" register accesses are
> handled.
> if "reg" is provided normal readl/writel API's are used to access
> register's else if
> "ts_syscon" is provided then syscon API's are used.

If we decide that we still allow register access then please change the
driver so it instantiates its own regmap instance in this case instead
of doing checks all the time.

Thanks.

-- 
Dmitry


From s-anna at ti.com  Tue Feb  9 09:44:45 2016
From: s-anna at ti.com (Suman Anna)
Date: Tue, 9 Feb 2016 11:44:45 -0600
Subject: [PATCH 0/3] omap: hwmod: add default reset handling support
In-Reply-To: <56B9767D.7000708@ti.com>
References: <1454929941-23949-1-git-send-email-kishon@ti.com>
 <56B9037C.2050203@ti.com> <56B9767D.7000708@ti.com>
Message-ID: <56BA258D.3040002@ti.com>

On 02/08/2016 11:17 PM, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Tuesday 09 February 2016 02:37 AM, Suman Anna wrote:
>> On 02/08/2016 05:12 AM, Kishon Vijay Abraham I wrote:
>>> Add a new hwmod flag to indicate custom reset handling and use it
>>> for devices that require custom reset handling (like dsp, ipu, iva).
>>>
>>> Tested PCIe on dra7-evm and dra72-evm.
>>> I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
>>> Or a way to test these cores to see if reset is not broken. Suman?
>>
>> I won't be able to test this week, and have requested Dave to check on
>> wkup_m3_rproc driver atleast. I see one potential issue (see my commment
>> on the other thread), but can confirm that only after testing.
>>
>> Have you tested multiple probe/removal sequences? Can you check the
>> return status on the _hardreset_deassert call with your PCIe driver,
>> believe even that one would return an error on multiple probes.
> 
> hmm.. the PCIe driver is built-in and can't be made as module because of other
> issues in PCIe core. But looks like the first deassert succeeded since I didn't
> observe the boot hang because of PCIe.

You can try unbind and bind through sysfs, it should result in a remove
and probe even if your driver is built-in.

regards
Suman
>>
>>>
>>> I'll post this series once again after performing these tests.
>>>
>>> Paul Walmsley (3):
>>>   ARM: omap2+: omap_hwmod: introduce hwmod flag for custom reset
>>>     handling
>>>   ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for custom reset
>>>     handling
>>>   ARM: OMAP2+: hwmod: Add default reset handling
>>>
>>>  arch/arm/mach-omap2/omap_hwmod.c                   |   16 +++++++++++-----
>>>  arch/arm/mach-omap2/omap_hwmod.h                   |   12 ++++++++++++
>>>  arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
>>>  arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
>>>  .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
>>>  arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
>>>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
>>>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
>>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
>>>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
>>>  10 files changed, 41 insertions(+), 5 deletions(-)
>>>
>>



From fu.wei at linaro.org  Tue Feb  9 09:47:28 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Wed, 10 Feb 2016 01:47:28 +0800
Subject: [PATCH v11 4/4] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <56BA244E.1020402@codeaurora.org>
References: <1455037240-16192-1-git-send-email-fu.wei@linaro.org>
 <1455037240-16192-5-git-send-email-fu.wei@linaro.org>
 <56BA244E.1020402@codeaurora.org>
Message-ID: <CADyBb7sqKiFfrwkKUYOAXY3JCZzEM2jtR3Xac_ihafxf_McsLg@mail.gmail.com>

Hi Timur,

On 10 February 2016 at 01:39, Timur Tabi <timur at codeaurora.org> wrote:
> fu.wei at linaro.org wrote:
>
>> +               if (!action)
>> +                       dev_warn(dev, "fall back to signle stage
>> mode.\n");
>
>
> "falling back to single stage mode"

Thanks for your correction.  :-)
Will fixed it

>
> Acked-by: Timur Tabi <timur at codeaurora.org>
>

Thanks, will add this

> The whole "calculate the timeouts different if 'action' is enabled" seems
> clunky to me, but I can't think of a better way to handle it.
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
> Forum, a Linux Foundation collaborative project.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From lorenzo.pieralisi at arm.com  Tue Feb  9 10:02:27 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 9 Feb 2016 18:02:27 +0000
Subject: [PATCH V4 11/23] pci, acpi: Move ACPI host bridge device
 companion assignment to core code.
In-Reply-To: <1454606941-9523-12-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
 <1454606941-9523-12-git-send-email-tn@semihalf.com>
Message-ID: <20160209180227.GC22868@red-moon>

On Thu, Feb 04, 2016 at 06:28:49PM +0100, Tomasz Nowicki wrote:
> Currently we have two platforms (x86 & ia64) capable of PCI ACPI host
> bridge initialization. They both use sysdata to pass down parent
> device reference and both rely on NULL parent in pci_create_root_bus()
> to validate sysdata content.
> 
> It looks hacky and prevents us from getting some firmware specific
> info for PCI host controller e.g. PCI bus domain number.
> However, we overcome that blocker by passing down parent
> device via pci_create_root_bus parameter (as the ACPI device type)
> and using ACPI_COMPANION_SET in core code for ACPI boot method.
> ACPI_COMPANION_SET is safe to run for all cases DT, ACPI and DT&ACPI.
> 
> Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
> Tested-by: Duc Dang <dhdang at apm.com>
> Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
> Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
> Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
> Tested-by: Sinan Kaya <okaya at codeaurora.org>
> ---
>  drivers/acpi/pci_root.c | 5 ++++-
>  drivers/pci/probe.c     | 2 ++
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index ae3fe4e..a65c8c2 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -846,7 +846,10 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>  
>  	pci_acpi_root_add_resources(info);
>  	pci_add_resource(&info->resources, &root->secondary);
> -	bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
> +
> +	/* Root bridge device needs to be sure of parent ACPI type */

You can improve the comment.

"pci_create_root_bus() needs to detect the parent device type,
so initialize its companion data accordingly".

> +	ACPI_COMPANION_SET(&device->dev, device);
> +	bus = pci_create_root_bus(&device->dev, busnum, ops->pci_ops,
>  				  sysdata, &info->resources);
>  	if (!bus)
>  		goto out_release_info;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 6d7ab9b..81dd3a2 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -2100,6 +2100,8 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
>  	bridge->dev.parent = parent;
>  	bridge->dev.release = pci_release_host_bridge_dev;
>  	dev_set_name(&bridge->dev, "pci%04x:%02x", pci_domain_nr(b), bus);
> +	ACPI_COMPANION_SET(&bridge->dev,
> +			   parent ? to_acpi_device_node(parent->fwnode) : NULL);
if (parent)
	ACPI_COMPANION_SET(&bridge->dev, ACPI_COMPANION(parent));

?

It seems fine to me, hopefully Rafael can have a look to countercheck.

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

>  	error = pcibios_root_bridge_prepare(bridge);
>  	if (error) {
>  		kfree(bridge);
> -- 
> 1.9.1
> 


From nm at ti.com  Tue Feb  9 10:10:31 2016
From: nm at ti.com (Nishanth Menon)
Date: Tue, 9 Feb 2016 12:10:31 -0600
Subject: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager
In-Reply-To: <CAGo_u6qGaQj9Qvjwrm7cD=cr2UjLN+62tcquXYPsQrRjYD=UCw@mail.gmail.com>
References: <1454690044-2560-1-git-send-email-nm@ti.com>
 <1454690044-2560-2-git-send-email-nm@ti.com>
 <CABb+yY3kGq_R49Xx4fK3UMqtuFiuv-pXJWvjkEFLPL9xRu5T4A@mail.gmail.com>
 <56B9DC30.5040806@ti.com>
 <CABb+yY24XzsWaSGLMCE4_nvgWx0OhhQmcaP41g06FxdjQYFchg@mail.gmail.com>
 <CAGo_u6qGaQj9Qvjwrm7cD=cr2UjLN+62tcquXYPsQrRjYD=UCw@mail.gmail.com>
Message-ID: <20160209181031.GA23603@kahuna>

On 09:43-20160209, Nishanth Menon wrote:
> On Tue, Feb 9, 2016 at 8:54 AM, Jassi Brar <jassisinghbrar at gmail.com> wrote:
[..]
> Let me prototype this as part of of_xlate and see if I can pull the
> qinst data back out.. obviously one negative will be that I will
> register *all* valid channels as part of probe.. at least based on
> initial code i wrote today morning..

OK - I believe I have it working now. How does the following look? If
this looks fine to you, then I will post a v2 including the driver
update.
Changes here:
	- dropped the generic message-manager compatible
	- dropped child nodes
	- moved the valid queue information to driver (no longer in dts)
	- rx interrupts per SoC are explicitly named list in binding(and
	  dts)

Texas Instruments' Message Manager Driver
========================================

The Texas Instruments' Message Manager is a mailbox controller that has
configurable queues selectable at SoC(System on Chip) integration. The Message
manager is broken up into queues in different address regions that are called
"proxies" - each instance is unidirectional and is instantiated at SoC
integration level to indicate receive or transmit path.

Message Manager Device Node:
===========================
Required properties:
--------------------
- compatible:		Shall be: "ti,k2g-message-manager"
- reg-names 		queue_proxy_region - Map the queue proxy region.
			queue_state_debug_region - Map the queue state debug
			region.
- reg:			Contains the register map per reg-names.
- #mbox-cells		Shall be 2. Contains the queue ID and proxy ID in that
		        order referring to the transfer path.
- interrupt-names:	Contains interrupt names matching the rx transfer path
			for a given SoC. Receive interrupts shall be of the
			format: "rx_<QID>_<PID>".
			For ti,k2g-message-manager, this shall contain:
				"rx_005_002", "rx_057_002"
- interrupts:		Contains the interrupt information corresponding to
			interrupt-names property.

Example(K2G):
------------

	msgmgr: msgmgr at 02a00000 {
		compatible = "ti,k2g-message-manager";
		#mbox-cells = <2>;
		reg-names = "queue_proxy_region", "queue_state_debug_region";
		reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
		interrupt-names = "rx_005_002",
				  "rx_057_002";
		interrupts = <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
			     <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
	};

	pmmc: pmmc {
		[...]
		mbox-names = "rx", "tx";
		# RX queue ID is 5, proxy ID is 2
		# TX queue ID is 0, proxy ID is 0
		mboxes= <&msgmgr 5 2>,
			<&msgmgr 0 0>;
		[...]
	};
-- 
Regards,
Nishanth Menon


From stephanolbrich at gmx.de  Tue Feb  9 10:10:32 2016
From: stephanolbrich at gmx.de (stephanolbrich at gmx.de)
Date: Tue,  9 Feb 2016 19:10:32 +0100
Subject: [PATCH 1/4] spi: bcm2835aux: fix bitmask defines
In-Reply-To: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
Message-ID: <1455041435-8015-2-git-send-email-stephanolbrich@gmx.de>

From: Stephan Olbrich <stephanolbrich at gmx.de>

The bitmasks for txempty and idle interrupts were interchanged.

Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
---
 drivers/spi/spi-bcm2835aux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
index 7de6f84..ecc73c0 100644
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -73,8 +73,8 @@
 
 /* Bitfields in CNTL1 */
 #define BCM2835_AUX_SPI_CNTL1_CSHIGH	0x00000700
-#define BCM2835_AUX_SPI_CNTL1_IDLE	0x00000080
-#define BCM2835_AUX_SPI_CNTL1_TXEMPTY	0x00000040
+#define BCM2835_AUX_SPI_CNTL1_TXEMPTY	0x00000080
+#define BCM2835_AUX_SPI_CNTL1_IDLE	0x00000040
 #define BCM2835_AUX_SPI_CNTL1_MSBF_IN	0x00000002
 #define BCM2835_AUX_SPI_CNTL1_KEEP_IN	0x00000001
 
-- 
2.5.0



From stephanolbrich at gmx.de  Tue Feb  9 10:10:34 2016
From: stephanolbrich at gmx.de (stephanolbrich at gmx.de)
Date: Tue,  9 Feb 2016 19:10:34 +0100
Subject: [PATCH 3/4] spi: bcm2835aux: set up spi-mode before asserting cs-gpio
In-Reply-To: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
Message-ID: <1455041435-8015-4-git-send-email-stephanolbrich@gmx.de>

From: Stephan Olbrich <stephanolbrich at gmx.de>

When using reverse polarity for clock (spi-cpol) on a device
the clock line gets altered after chip-select has been asserted
resulting in an additional clock beat, which confuses hardware.

To avoid this situation this patch moves the setup of polarity
(spi-cpol and spi-cpha) outside of the chip-select into
prepare_message, which is run prior to asserting chip-select.

Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
---
 drivers/spi/spi-bcm2835aux.c | 54 +++++++++++++++++++++++++++++++-------------
 1 file changed, 38 insertions(+), 16 deletions(-)

diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
index d2f0067..b90aa34 100644
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -218,9 +218,9 @@ static irqreturn_t bcm2835aux_spi_interrupt(int irq, void *dev_id)
 			BCM2835_AUX_SPI_CNTL1_IDLE);
 	}
 
-	/* and if rx_len is 0 then wake up completion and disable spi */
+	/* and if rx_len is 0 then disable interrupts and wake up completion */
 	if (!bs->rx_len) {
-		bcm2835aux_spi_reset_hw(bs);
+		bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1]);
 		complete(&master->xfer_completion);
 	}
 
@@ -313,9 +313,6 @@ static int bcm2835aux_spi_transfer_one_poll(struct spi_master *master,
 		}
 	}
 
-	/* Transfer complete - reset SPI HW */
-	bcm2835aux_spi_reset_hw(bs);
-
 	/* and return without waiting for completion */
 	return 0;
 }
@@ -336,10 +333,6 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master,
 	 * resulting (potentially) in more interrupts when transferring
 	 * more than 12 bytes
 	 */
-	bs->cntl[0] = BCM2835_AUX_SPI_CNTL0_ENABLE |
-		      BCM2835_AUX_SPI_CNTL0_VAR_WIDTH |
-		      BCM2835_AUX_SPI_CNTL0_MSBF_OUT;
-	bs->cntl[1] = BCM2835_AUX_SPI_CNTL1_MSBF_IN;
 
 	/* set clock */
 	spi_hz = tfr->speed_hz;
@@ -358,13 +351,6 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master,
 
 	spi_used_hz = clk_hz / (2 * (speed + 1));
 
-	/* handle all the modes */
-	if (spi->mode & SPI_CPOL)
-		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPOL;
-	if (spi->mode & SPI_CPHA)
-		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT |
-			       BCM2835_AUX_SPI_CNTL0_CPHA_IN;
-
 	/* set transmit buffers and length */
 	bs->tx_buf = tfr->tx_buf;
 	bs->rx_buf = tfr->rx_buf;
@@ -388,6 +374,40 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master,
 	return bcm2835aux_spi_transfer_one_irq(master, spi, tfr);
 }
 
+static int bcm2835aux_spi_prepare_message(struct spi_master *master,
+					  struct spi_message *msg)
+{
+	struct spi_device *spi = msg->spi;
+	struct bcm2835aux_spi *bs = spi_master_get_devdata(master);
+
+	bs->cntl[0] = BCM2835_AUX_SPI_CNTL0_ENABLE |
+		      BCM2835_AUX_SPI_CNTL0_VAR_WIDTH |
+		      BCM2835_AUX_SPI_CNTL0_MSBF_OUT;
+	bs->cntl[1] = BCM2835_AUX_SPI_CNTL1_MSBF_IN;
+
+	/* handle all the modes */
+	if (spi->mode & SPI_CPOL)
+		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPOL;
+	if (spi->mode & SPI_CPHA)
+		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT |
+			       BCM2835_AUX_SPI_CNTL0_CPHA_IN;
+
+	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1]);
+	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL0, bs->cntl[0]);
+
+	return 0;
+}
+
+static int bcm2835aux_spi_unprepare_message(struct spi_master *master,
+					    struct spi_message *msg)
+{
+	struct bcm2835aux_spi *bs = spi_master_get_devdata(master);
+
+	bcm2835aux_spi_reset_hw(bs);
+
+	return 0;
+}
+
 static void bcm2835aux_spi_handle_err(struct spi_master *master,
 				      struct spi_message *msg)
 {
@@ -416,6 +436,8 @@ static int bcm2835aux_spi_probe(struct platform_device *pdev)
 	master->num_chipselect = -1;
 	master->transfer_one = bcm2835aux_spi_transfer_one;
 	master->handle_err = bcm2835aux_spi_handle_err;
+	master->prepare_message = bcm2835aux_spi_prepare_message;
+	master->unprepare_message = bcm2835aux_spi_unprepare_message;
 	master->dev.of_node = pdev->dev.of_node;
 
 	bs = spi_master_get_devdata(master);
-- 
2.5.0



From stephanolbrich at gmx.de  Tue Feb  9 10:10:31 2016
From: stephanolbrich at gmx.de (stephanolbrich at gmx.de)
Date: Tue,  9 Feb 2016 19:10:31 +0100
Subject: [PATCH 0/4] spi: bcm2835aux: auxiliary spi improvements
Message-ID: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>

From: Stephan Olbrich <stephanolbrich at gmx.de>

This patch series has some improvements and fixes for the auxiliary spi.

1. fix bitmask defines
 just fixes a typo (needed in 2.)

2. disable tx fifo empty irq
 reduces the numer of interrupts with nothing to do

3. set up spi-mode before asserting cs-gpio
 As Martin Sperl suggested this is done in the same way as in spi-bcm2835.c
 acace73df2c1913a526c1b41e4741a4a6704c863

4. fix CPOL/CPHA setting
 From what I've seen in the documentation [1] and seen on the scope this chip
 doesn't support modes with CPHA=1. With this patch spi mode 0 and 2 should
 work correctly whereas mode 1 and 3 do not. 

[1] https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

Stephan Olbrich (4):
  spi: bcm2835aux: fix bitmask defines
  spi: bcm2835aux: disable tx fifo empty irq
  spi: bcm2835aux: set up spi-mode before asserting cs-gpio
  spi: bcm2835aux: fix CPOL/CPHA setting

 drivers/spi/spi-bcm2835aux.c | 64 +++++++++++++++++++++++++++++++-------------
 1 file changed, 46 insertions(+), 18 deletions(-)

-- 
2.5.0



From stephanolbrich at gmx.de  Tue Feb  9 10:10:33 2016
From: stephanolbrich at gmx.de (stephanolbrich at gmx.de)
Date: Tue,  9 Feb 2016 19:10:33 +0100
Subject: [PATCH 2/4] spi: bcm2835aux: disable tx fifo empty irq
In-Reply-To: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
Message-ID: <1455041435-8015-3-git-send-email-stephanolbrich@gmx.de>

From: Stephan Olbrich <stephanolbrich at gmx.de>

The tx empty irq can be disabled when all data was copied.
This prevents unnecessary interrupts while the last bytes are sent.

Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
---
 drivers/spi/spi-bcm2835aux.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
index ecc73c0..d2f0067 100644
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -212,6 +212,12 @@ static irqreturn_t bcm2835aux_spi_interrupt(int irq, void *dev_id)
 		ret = IRQ_HANDLED;
 	}
 
+	if (!bs->tx_len) {
+		/* disable tx fifo empty interrupt */
+		bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1] |
+			BCM2835_AUX_SPI_CNTL1_IDLE);
+	}
+
 	/* and if rx_len is 0 then wake up completion and disable spi */
 	if (!bs->rx_len) {
 		bcm2835aux_spi_reset_hw(bs);
-- 
2.5.0



From stephanolbrich at gmx.de  Tue Feb  9 10:10:35 2016
From: stephanolbrich at gmx.de (stephanolbrich at gmx.de)
Date: Tue,  9 Feb 2016 19:10:35 +0100
Subject: [PATCH 4/4] spi: bcm2835aux: fix CPOL/CPHA setting
In-Reply-To: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
Message-ID: <1455041435-8015-5-git-send-email-stephanolbrich@gmx.de>

From: Stephan Olbrich <stephanolbrich at gmx.de>

The auxiliary spi supports only CPHA=0 modes as the first bit is
always output to the pin before the first clock cycle. In CPHA=1
modes the first clock edge outputs the second bit hence the slave
can never read the first bit.

Also the CPHA registers switch between clocking data in/out on
rising/falling edge hence depend on the CPOL setting.

Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
---
 drivers/spi/spi-bcm2835aux.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
index b90aa34..169f521 100644
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -386,12 +386,12 @@ static int bcm2835aux_spi_prepare_message(struct spi_master *master,
 	bs->cntl[1] = BCM2835_AUX_SPI_CNTL1_MSBF_IN;
 
 	/* handle all the modes */
-	if (spi->mode & SPI_CPOL)
+	if (spi->mode & SPI_CPOL) {
 		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPOL;
-	if (spi->mode & SPI_CPHA)
-		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT |
-			       BCM2835_AUX_SPI_CNTL0_CPHA_IN;
-
+		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT;
+	} else {
+		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_IN;
+	}
 	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1]);
 	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL0, bs->cntl[0]);
 
-- 
2.5.0



From mark.rutland at arm.com  Tue Feb  9 10:11:41 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue,  9 Feb 2016 18:11:41 +0000
Subject: [PATCH] arm64: Rework valid_user_regs
Message-ID: <1455041501-30018-1-git-send-email-mark.rutland@arm.com>

We validate pstate using PSR_MODE32_BIT, which is part of the
user-provided pstate (and cannot be trusted). Also, we conflate
validation of AArch32 and AArch64 pstate values, making the code
difficult to reason about.

Instead, validate the pstate value based on the associated task. The
task may or may not be current (e.g. when using ptrace), so this must be
passed explicitly by callers. To avoid circular header dependencies via
sched.h, is_compat_task is pulled out of asm/ptrace.h.

To make the code possible to reason about, the AArch64 and AArch32
validation is split into separate functions. Software must respect the
RES0 policy for SPSR bits, and thus the kernel mirrors the hardware
policy (RAZ/WI) for bits as-yet unallocated. When these acquire an
architected meaning writes may be permitted (potentially with additional
validation).

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Dave Martin <dave.martin at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Peter Maydell <peter.maydell at linaro.org>
Cc: Will Deacon <will.deacon at arm.com>
---
 arch/arm64/include/asm/ptrace.h | 32 ++-------------------
 arch/arm64/kernel/ptrace.c      | 64 +++++++++++++++++++++++++++++++++++++++--
 arch/arm64/kernel/signal.c      |  4 +--
 arch/arm64/kernel/signal32.c    |  2 +-
 4 files changed, 68 insertions(+), 34 deletions(-)

diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index e9e5467..0bb538b 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -151,35 +151,9 @@ static inline unsigned long regs_return_value(struct pt_regs *regs)
 	return regs->regs[0];
 }
 
-/*
- * Are the current registers suitable for user mode? (used to maintain
- * security in signal handlers)
- */
-static inline int valid_user_regs(struct user_pt_regs *regs)
-{
-	if (user_mode(regs) && (regs->pstate & PSR_I_BIT) == 0) {
-		regs->pstate &= ~(PSR_F_BIT | PSR_A_BIT);
-
-		/* The T bit is reserved for AArch64 */
-		if (!(regs->pstate & PSR_MODE32_BIT))
-			regs->pstate &= ~COMPAT_PSR_T_BIT;
-
-		return 1;
-	}
-
-	/*
-	 * Force PSR to something logical...
-	 */
-	regs->pstate &= PSR_f | PSR_s | (PSR_x & ~PSR_A_BIT) | \
-			COMPAT_PSR_T_BIT | PSR_MODE32_BIT;
-
-	if (!(regs->pstate & PSR_MODE32_BIT)) {
-		regs->pstate &= ~COMPAT_PSR_T_BIT;
-		regs->pstate |= PSR_MODE_EL0t;
-	}
-
-	return 0;
-}
+/* We must avoid circular header include via sched.h */
+struct task_struct;
+int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task);
 
 #define instruction_pointer(regs)	((unsigned long)(regs)->pc)
 
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index ff7f132..23c20c2 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -500,7 +500,7 @@ static int gpr_set(struct task_struct *target, const struct user_regset *regset,
 	if (ret)
 		return ret;
 
-	if (!valid_user_regs(&newregs))
+	if (!valid_user_regs(&newregs, target))
 		return -EINVAL;
 
 	task_pt_regs(target)->user_regs = newregs;
@@ -770,7 +770,7 @@ static int compat_gpr_set(struct task_struct *target,
 
 	}
 
-	if (valid_user_regs(&newregs.user_regs))
+	if (valid_user_regs(&newregs.user_regs, target))
 		*task_pt_regs(target) = newregs;
 	else
 		ret = -EINVAL;
@@ -1272,3 +1272,63 @@ asmlinkage void syscall_trace_exit(struct pt_regs *regs)
 	if (test_thread_flag(TIF_SYSCALL_TRACE))
 		tracehook_report_syscall(regs, PTRACE_SYSCALL_EXIT);
 }
+
+/*
+ * Bits which are architecturally RES0 per ARM DDI 0487A.h
+ * The kernel matches the HW policy. Userspace cannot use these until they have
+ * an architectural meaning.
+ */
+#define SPSR_EL1_AARCH64_RES0_BITS \
+	(GENMASK_ULL(63,32) | GENMASK_ULL(27, 22) | GENMASK_ULL(19, 10) | \
+	 GENMASK_ULL(5, 5))
+#define SPSR_EL1_AARCH32_RES0_BITS \
+	(GENMASK_ULL(63,32) | (GENMASK_ULL(23, 22)))
+
+static int valid_aa32_regs(struct user_pt_regs *regs)
+{
+	regs->pstate &= ~SPSR_EL1_AARCH32_RES0_BITS;
+
+	if (user_mode(regs) && (regs->pstate & PSR_MODE32_BIT) &&
+	    (regs->pstate & COMPAT_PSR_A_BIT) == 0 &&
+	    (regs->pstate & COMPAT_PSR_I_BIT) == 0 &&
+	    (regs->pstate & COMPAT_PSR_F_BIT) == 0) {
+		return 1;
+	}
+
+	/* Force PSR to a valid 32-bit EL0t */
+	regs->pstate |= PSR_MODE32_BIT;
+	regs->pstate &= PSR_f | PSR_s | (PSR_x & ~COMPAT_PSR_A_BIT) | \
+			COMPAT_PSR_T_BIT;
+
+	return 0;
+}
+
+static int valid_aa64_regs(struct user_pt_regs *regs)
+{
+	regs->pstate &= ~SPSR_EL1_AARCH64_RES0_BITS;
+
+	if (user_mode(regs) && !(regs->pstate & PSR_MODE32_BIT) &&
+	    (regs->pstate & PSR_D_BIT) == 0 &&
+	    (regs->pstate & PSR_A_BIT) == 0 &&
+	    (regs->pstate & PSR_I_BIT) == 0 &&
+	    (regs->pstate & PSR_F_BIT) == 0) {
+		return 1;
+	}
+
+	/* Force PSR to a valid 64-bit EL0t */
+	regs->pstate &= PSR_f | PSR_s;
+
+	return 0;
+}
+
+/*
+ * Are the current registers suitable for user mode? (used to maintain
+ * security in signal handlers)
+ */
+int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
+{
+	if (is_compat_thread(task_thread_info(task)))
+		return valid_aa32_regs(regs);
+	else
+		return valid_aa64_regs(regs);
+}
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index e18c48c..a8eafdb 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -115,7 +115,7 @@ static int restore_sigframe(struct pt_regs *regs,
 	 */
 	regs->syscallno = ~0UL;
 
-	err |= !valid_user_regs(&regs->user_regs);
+	err |= !valid_user_regs(&regs->user_regs, current);
 
 	if (err == 0) {
 		struct fpsimd_context *fpsimd_ctx =
@@ -307,7 +307,7 @@ static void handle_signal(struct ksignal *ksig, struct pt_regs *regs)
 	/*
 	 * Check that the resulting registers are actually sane.
 	 */
-	ret |= !valid_user_regs(&regs->user_regs);
+	ret |= !valid_user_regs(&regs->user_regs, current);
 
 	/*
 	 * Fast forward the stepping logic so we step into the signal
diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index 71ef6dc..1073356 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -356,7 +356,7 @@ static int compat_restore_sigframe(struct pt_regs *regs,
 	 */
 	regs->syscallno = ~0UL;
 
-	err |= !valid_user_regs(&regs->user_regs);
+	err |= !valid_user_regs(&regs->user_regs, current);
 
 	aux = (struct compat_aux_sigframe __user *) sf->uc.uc_regspace;
 	if (err == 0)
-- 
1.9.1



From stuart.yoder at nxp.com  Tue Feb  9 10:12:24 2016
From: stuart.yoder at nxp.com (Stuart Yoder)
Date: Tue, 9 Feb 2016 18:12:24 +0000
Subject: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
In-Reply-To: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
References: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
Message-ID: <HE1PR04MB16413597FD97D47AFB9880D78DD60@HE1PR04MB1641.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Tuesday, February 09, 2016 5:05 AM
> To: robh+dt at kernel.org; frowand.list at gmail.com; grant.likely at linaro.org;
> devicetree at vger.kernel.org
> Cc: marc.zyngier at arm.com; mark.rutland at arm.com; david.daney at cavium.com; Stuart Yoder
> <stuart.yoder at nxp.com>; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; stable at vger.kernel.org
> Subject: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
> 
> The existing msi-map code is fine for shifting the entire RID space
> upwards, but attempting finer-grained remapping reveals a bug. It turns
> out that we are mistakenly treating the msi-base part as an offset, not
> as a new base to remap onto, so things get squiffy when rid-base is
> nonzero. Fix this, and at the same time add a sanity check against
> having msi-map-mask clash with a nonzero rid-base, as that's another
> thing one can easily get wrong.
> 
> CC: <stable at vger.kernel.org>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
>  drivers/of/irq.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 7ee21ae..e7bfc17 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -635,6 +635,13 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node
> **np,
>  		msi_base = be32_to_cpup(msi_map + 2);
>  		rid_len = be32_to_cpup(msi_map + 3);
> 
> +		if (rid_base & ~map_mask) {
> +			dev_err(parent_dev,
> +				"Invalid msi-map translation - msi-map-mask (0x%x) ignores rid-
> base (0x%x)\n",
> +				map_mask, rid_base);
> +			return rid_out;
> +		}
> +
>  		msi_controller_node = of_find_node_by_phandle(phandle);
> 
>  		matched = (masked_rid >= rid_base &&
> @@ -654,7 +661,7 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node
> **np,
>  	if (!matched)
>  		return rid_out;
> 
> -	rid_out = masked_rid + msi_base;
> +	rid_out = masked_rid - rid_base + msi_base;
>  	dev_dbg(dev,
>  		"msi-map at: %s, using mask %08x, rid-base: %08x, msi-base: %08x, length:
> %08x, rid: %08x -> %08x\n",
>  		dev_name(parent_dev), map_mask, rid_base, msi_base,
> --
> 2.7.0.25.gfc10eb5.dirty

Tested-by: Stuart Yoder <stuart.yoder at nxp.com>


From mark.rutland at arm.com  Tue Feb  9 10:16:42 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 9 Feb 2016 18:16:42 +0000
Subject: [RFC PATCH v3 2/3] PCI: hisi: Add ECAM support to HiSilicon PCIe
 host controller
In-Reply-To: <1455039260-6040-3-git-send-email-gabriele.paoloni@huawei.com>
References: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
 <1455039260-6040-3-git-send-email-gabriele.paoloni@huawei.com>
Message-ID: <20160209181641.GB4348@leverpostej>

On Tue, Feb 09, 2016 at 05:34:19PM +0000, Gabriele Paoloni wrote:
> From: gabriele paoloni <gabriele.paoloni at huawei.com>
> 
> This patch modifies the current Hip05/Hip06 PCIe host
> controller driver to add support for ECAM compliant
> platforms.
> This is needed in preparation for the ACPI based driver
> to allow both DT and ACPI drivers to use the same BIOS
> (that configure the Designware iATUs).
> This commit doesn't break backward compatibility with
> previous non-ECAM platforms.

Please forgive my ignorance, but if the system can be made ECAM
compliant, why can the generic ECAM driver not be used in that case?

That would require no changes to this driver/binding.

Thanks,
Mark.

> Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
> Signed-off-by: Dongdong Liu <liudongdong3 at huawei.com>
> ---
>  .../devicetree/bindings/pci/hisilicon-pcie.txt     | 15 +++++---
>  drivers/pci/host/pcie-designware.c                 |  4 +--
>  drivers/pci/host/pcie-designware.h                 |  2 ++
>  drivers/pci/host/pcie-hisi.c                       | 40 ++++++++++++++++++++++
>  4 files changed, 53 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> index b721bea..5a4c1e7 100644
> --- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> @@ -9,10 +9,13 @@ Additional properties are described here:
>  
>  Required properties
>  - compatible: Should contain "hisilicon,hip05-pcie" or "hisilicon,hip06-pcie".
> -- reg: Should contain rc_dbi, config registers location and length.
> -- reg-names: Must include the following entries:
> +- reg: Should contain rc_dbi and  either config or ecam-cfg registers
> +       location and length (it depends on the platform BIOS).
> +- reg-names: Must include
>    "rc_dbi": controller configuration registers;
> -  "config": PCIe configuration space registers.
> +  and one of the following entries:
> +    "config": PCIe configuration space registers for non-ECAM platforms.
> +    "ecam-cfg": PCIe configuration space registers for ECAM platforms
>  - msi-parent: Should be its_pcie which is an ITS receiving MSI interrupts.
>  - port-id: Should be 0, 1, 2 or 3.
>  
> @@ -23,8 +26,10 @@ Optional properties:
>  Hip05 Example (note that Hip06 is the same except compatible):
>  	pcie at 0xb0080000 {
>  		compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
> -		reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0 0x2000>;
> -		reg-names = "rc_dbi", "config";
> +		reg = <0 0xb0080000 0 0x10000>,
> +			  <0x220 0x00000000 0 0x2000>
> +			/* or <0x220 0x00100000 0 0x0f00000> for ecam-cfg*/;
> +		reg-names = "rc_dbi", "config" /* or "ecam-cfg" */;
>  		bus-range = <0  15>;
>  		msi-parent = <&its_pcie>;
>  		#address-cells = <3>;
> diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
> index 2171682..5f19ea4 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -69,8 +69,6 @@
>  #define PCIE_ATU_FUNC(x)		(((x) & 0x7) << 16)
>  #define PCIE_ATU_UPPER_TARGET		0x91C
>  
> -static struct pci_ops dw_pcie_ops;
> -
>  int dw_pcie_cfg_read(void __iomem *addr, int size, u32 *val)
>  {
>  	if ((uintptr_t)addr & (size - 1)) {
> @@ -690,7 +688,7 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
>  	return dw_pcie_wr_other_conf(pp, bus, devfn, where, size, val);
>  }
>  
> -static struct pci_ops dw_pcie_ops = {
> +struct pci_ops dw_pcie_ops = {
>  	.read = dw_pcie_rd_conf,
>  	.write = dw_pcie_wr_conf,
>  };
> diff --git a/drivers/pci/host/pcie-designware.h b/drivers/pci/host/pcie-designware.h
> index 2356d29..3f42655 100644
> --- a/drivers/pci/host/pcie-designware.h
> +++ b/drivers/pci/host/pcie-designware.h
> @@ -80,4 +80,6 @@ int dw_pcie_link_up(struct pcie_port *pp);
>  void dw_pcie_setup_rc(struct pcie_port *pp);
>  int dw_pcie_host_init(struct pcie_port *pp);
>  
> +extern struct pci_ops dw_pcie_ops;
> +
>  #endif /* _PCIE_DESIGNWARE_H */
> diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
> index 458d0f8..d3e2047 100644
> --- a/drivers/pci/host/pcie-hisi.c
> +++ b/drivers/pci/host/pcie-hisi.c
> @@ -43,6 +43,18 @@ struct pcie_soc_ops {
>  	int (*hisi_pcie_link_up)(struct hisi_pcie *pcie);
>  };
>  
> +static inline int hisi_rd_ecam_conf(struct pcie_port *pp, struct pci_bus *bus,
> +		unsigned int devfn, int where, int size, u32 *value)
> +{
> +	return pci_generic_config_read(bus, devfn, where, size, value);
> +}
> +
> +static inline int hisi_wr_ecam_conf(struct pcie_port *pp, struct pci_bus *bus,
> +		unsigned int devfn, int where, int size, u32 value)
> +{
> +	return pci_generic_config_write(bus, devfn, where, size, value);
> +}
> +
>  static inline int hisi_pcie_cfg_read(struct pcie_port *pp, int where,
>  		int size, u32 *val)
>  {
> @@ -72,6 +84,17 @@ struct pcie_host_ops hisi_pcie_host_ops = {
>  		.link_up = hisi_pcie_link_up,
>  };
>  
> +static void __iomem *hisi_pci_map_cfg_bus_cam(struct pci_bus *bus,
> +					     unsigned int devfn,
> +					     int where)
> +{
> +	void __iomem *addr;
> +	struct pcie_port *pp = bus->sysdata;
> +
> +	addr = pp->va_cfg1_base + where;
> +
> +	return addr;
> +}
>  
>  static int hisi_add_pcie_port(struct pcie_port *pp,
>  				     struct platform_device *pdev)
> @@ -137,6 +160,23 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>  
>  	hisi_pcie->pp.dbi_base = hisi_pcie->reg_base;
>  
> +	reg = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam-cfg");
> +	if (reg) {
> +		/* ECAM driver version */
> +		hisi_pcie->pp.va_cfg0_base =
> +				devm_ioremap_resource(&pdev->dev, reg);
> +		if (IS_ERR(hisi_pcie->pp.va_cfg0_base)) {
> +			dev_err(pp->dev, "cannot get ecam-cfg\n");
> +			return PTR_ERR(hisi_pcie->pp.va_cfg0_base);
> +		}
> +		hisi_pcie->pp.va_cfg1_base = hisi_pcie->pp.va_cfg0_base;
> +
> +		dw_pcie_ops.map_bus = hisi_pci_map_cfg_bus_cam;
> +
> +		hisi_pcie_host_ops.rd_other_conf = hisi_rd_ecam_conf;
> +		hisi_pcie_host_ops.wr_other_conf = hisi_wr_ecam_conf;
> +	}
> +
>  	ret = hisi_add_pcie_port(pp, pdev);
>  	if (ret)
>  		return ret;
> -- 
> 1.9.1
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From mark.rutland at arm.com  Tue Feb  9 10:19:50 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 9 Feb 2016 18:19:50 +0000
Subject: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
In-Reply-To: <56BA111D.9050807@arm.com>
References: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
 <56B9D62E.8080003@arm.com>
 <HE1PR04MB1641AF97F637BBCBB86BA4FE8DD60@HE1PR04MB1641.eurprd04.prod.outlook.com>
 <20160209160812.GC9332@leverpostej> <56BA111D.9050807@arm.com>
Message-ID: <20160209181949.GC4348@leverpostej>

On Tue, Feb 09, 2016 at 04:17:33PM +0000, Robin Murphy wrote:
> On 09/02/16 16:08, Mark Rutland wrote:
> [...]
> 
> >>>>having msi-map-mask clash with a nonzero rid-base, as that's another
> >>>>thing one can easily get wrong.
> 
> [...]
> 
> >>>>+		if (rid_base & ~map_mask) {
> >>>>+			dev_err(parent_dev,
> >>>>+				"Invalid msi-map translation - msi-map-mask (0x%x) ignores rid-
> >>>base (0x%x)\n",
> >>>>+				map_mask, rid_base);
> >>>>+			return rid_out;
> >>>>+		}
> 
> [...]
> 
> >>                    msi-map = <0x0100 &its 0x11 0x1>;
> >>                    msi-map-mask = <0xff>;
> >>
> >
> >I'd say that this is an inconsistent set of properties, and it's
> >probably worth warning if we encounter this. There is no possible way
> >that rid-base can be encountered.
> 
> Indeed ;)

Ah!

FWIW:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Though it would be nice if we could fail the translation entirely rather
than just logging an error and idmapping the rid.

Thanks,
Mark.


From mark.rutland at arm.com  Tue Feb  9 10:24:29 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 9 Feb 2016 18:24:29 +0000
Subject: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
 HiSilicon SoCs Host Controllers
In-Reply-To: <1455039260-6040-4-git-send-email-gabriele.paoloni@huawei.com>
References: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
 <1455039260-6040-4-git-send-email-gabriele.paoloni@huawei.com>
Message-ID: <20160209182429.GD4348@leverpostej>

On Tue, Feb 09, 2016 at 05:34:20PM +0000, Gabriele Paoloni wrote:
> From: gabriele paoloni <gabriele.paoloni at huawei.com>
> 
> This patch adds specific quirks for PCI config space accessors,
> it uses _HID to decide whether to hook pci_ops or not.

If I understand correctly, this would mean that it's not actually ECAM
compliant, then?

> Signed-off-by: Dongdong Liu <liudongdong3 at huawei.com>
> Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
> ---
>  MAINTAINERS                       |   1 +
>  drivers/pci/host/Kconfig          |   8 ++
>  drivers/pci/host/Makefile         |   1 +
>  drivers/pci/host/pcie-hisi-acpi.c | 188 ++++++++++++++++++++++++++++++++++++++
>  drivers/pci/host/pcie-hisi.c      |   2 -
>  drivers/pci/host/pcie-hisi.h      |   2 +
>  6 files changed, 200 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/pci/host/pcie-hisi-acpi.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d69f436..f184c3e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8412,6 +8412,7 @@ F:	Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
>  F:	drivers/pci/host/pcie-hisi.h
>  F:	drivers/pci/host/pcie-hisi.c
>  F:	drivers/pci/host/pcie-hisi-common.c
> +F:	drivers/pci/host/pcie-hisi-acpi.c
>  
>  PCIE DRIVER FOR QUALCOMM MSM
>  M:     Stanimir Varbanov <svarbanov at mm-sol.com>
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 75a6054..65b1add 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -181,6 +181,14 @@ config PCI_HISI
>  	  Say Y here if you want PCIe controller support on HiSilicon
>  	  Hip05 and Hip06 SoCs
>  
> +config PCI_HISI_ACPI
> +	depends on ACPI
> +	bool "HiSilicon Hip05 and Hip06 SoCs ACPI PCIe controllers"
> +	select ACPI_PCI_HOST_GENERIC
> +	help
> +	  Say Y here if you want ACPI PCIe controller support on HiSilicon
> +	  Hip05 and Hip06 SoCs
> +
>  config PCIE_QCOM
>  	bool "Qualcomm PCIe controller"
>  	depends on ARCH_QCOM && OF
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 8c93c0f..57e4379 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -21,4 +21,5 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
>  obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
>  obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
>  obj-$(CONFIG_PCI_HISI) += pcie-hisi.o pcie-hisi-common.o
> +obj-$(CONFIG_PCI_HISI_ACPI) += pcie-hisi-acpi.o pcie-hisi-common.o
>  obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
> diff --git a/drivers/pci/host/pcie-hisi-acpi.c b/drivers/pci/host/pcie-hisi-acpi.c
> new file mode 100644
> index 0000000..3605260
> --- /dev/null
> +++ b/drivers/pci/host/pcie-hisi-acpi.c
> @@ -0,0 +1,188 @@
> +/*
> + * PCIe host controller driver for HiSilicon HipXX SoCs
> + *
> + * Copyright (C) 2016 HiSilicon Co., Ltd. http://www.hisilicon.com
> + *
> + * Author: Dongdong Liu <liudongdong3 at huawei.com>
> + *         Gabriele Paoloni <gabriele.paoloni at huawei.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.
> + */
> +#include <linux/interrupt.h>
> +#include <linux/acpi.h>
> +#include <linux/ecam.h>
> +#include <linux/pci.h>
> +#include <linux/pci-acpi.h>
> +#include "pcie-hisi.h"
> +
> +#define GET_PCIE_LINK_STATUS  0x0
> +
> +/* uuid 6d30f553-836c-408e-b6ad-45bccc957949 */
> +const u8 hisi_pcie_acpi_dsm_uuid[] = {
> +	0x53, 0xf5, 0x30, 0x6d, 0x6c, 0x83, 0x8e, 0x40,
> +	0xb6, 0xad, 0x45, 0xbc, 0xcc, 0x95, 0x79, 0x49
> +};
> +
> +static const struct acpi_device_id hisi_pcie_ids[] = {
> +	{"HISI0080", 0},
> +	{"", 0},
> +};
> +
> +static int hisi_pcie_get_addr(struct acpi_pci_root *root, const char *name,
> +				void __iomem **addr)
> +{
> +	struct acpi_device *device;
> +	u64 base;
> +	u64 size;
> +	u32 buf[4];
> +	int ret;
> +
> +	device =  root->device;
> +	ret = fwnode_property_read_u32_array(&device->fwnode, name,
> +					buf, ARRAY_SIZE(buf));
> +	if (ret) {
> +		dev_err(&device->dev, "can't get %s\n", name);
> +		return ret;
> +	}
> +
> +	base = ((u64)buf[0] << 32) | buf[1];
> +	size =  ((u64)buf[2] << 32) | buf[3];
> +	*addr = devm_ioremap(&device->dev, base, size);
> +	if (!(*addr)) {
> +		dev_err(&device->dev, "error with ioremap\n");
> +		return -ENOMEM;
> +	}

This does not seem like the correct way of describing an addres in ACPI.

> +
> +	return 0;
> +}
> +
> +
> +static int hisi_pcie_link_up_acpi(struct acpi_pci_root *root)
> +{
> +	u32 val;
> +	struct acpi_device *device;
> +	union acpi_object *obj;
> +
> +	device = root->device;
> +	obj = acpi_evaluate_dsm(device->handle,
> +		hisi_pcie_acpi_dsm_uuid, 0,
> +		GET_PCIE_LINK_STATUS, NULL);
> +
> +	if (!obj  ||  obj->type != ACPI_TYPE_INTEGER)  {
> +		dev_err(&device->dev, "can't get link status from _DSM\n");
> +		return 0;
> +	}
> +	val = obj->integer.value;
> +
> +	return ((val & PCIE_LTSSM_STATE_MASK) == PCIE_LTSSM_LINKUP_STATE);
> +
> +}
> +
> +/*
> + * Retrieve rc_dbi base and size from _DSD
> + * Name (_DSD, Package () {
> + *	ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> + *	Package () {
> + *	Package () {"rc-dbi", Package () { 0x0, 0xb0080000, 0x0, 0x10000 }},
> + *	}
> + *	})
> + */

As above, this does not look right. ACPI has standard mechanisms for
describing addresses. Making something up like this is not a good idea.

Mark.



From christoffer.dall at linaro.org  Tue Feb  9 10:28:28 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:28:28 +0100
Subject: [PATCH v2 20/28] ARM: KVM: Change kvm_call_hyp return type to
 unsigned long
In-Reply-To: <1454583645-10144-21-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-21-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209182828.GB5171@cbox>

On Thu, Feb 04, 2016 at 11:00:37AM +0000, Marc Zyngier wrote:
> Having u64 as the kvm_call_hyp return type is problematic, as
> it forces all kind of tricks for the return values from HYP
> to be promoted to 64bit (LE has the LSB in r0, and BE has them
> in r1).
> 
> Since the only user of the return value is perfectly happy with
> a 32bit value, let's make kvm_call_hyp return an unsigned long,
> which is 32bit on ARM.

I wonder why I ever did this as a u64...

should the arm64 counterpart be modified to an unsigned long as well?

> 
> This solves yet another headache.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/include/asm/kvm_host.h |  2 +-
>  arch/arm/kvm/interrupts.S       | 10 ++--------
>  2 files changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 02932ba..c62d717 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -165,7 +165,7 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
>  int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
>  int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
>  int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
> -u64 kvm_call_hyp(void *hypfn, ...);
> +unsigned long kvm_call_hyp(void *hypfn, ...);
>  void force_vm_exit(const cpumask_t *mask);
>  
>  #define KVM_ARCH_WANT_MMU_NOTIFIER
> diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
> index 7bfb289..01eb169 100644
> --- a/arch/arm/kvm/interrupts.S
> +++ b/arch/arm/kvm/interrupts.S
> @@ -207,20 +207,14 @@ after_vfp_restore:
>  
>  	restore_host_regs
>  	clrex				@ Clear exclusive monitor
> -#ifndef CONFIG_CPU_ENDIAN_BE8
>  	mov	r0, r1			@ Return the return code
> -	mov	r1, #0			@ Clear upper bits in return value
> -#else
> -	@ r1 already has return code
> -	mov	r0, #0			@ Clear upper bits in return value
> -#endif /* CONFIG_CPU_ENDIAN_BE8 */
>  	bx	lr			@ return to IOCTL
>  
>  /********************************************************************
>   *  Call function in Hyp mode
>   *
>   *
> - * u64 kvm_call_hyp(void *hypfn, ...);
> + * unsigned long kvm_call_hyp(void *hypfn, ...);
>   *
>   * This is not really a variadic function in the classic C-way and care must
>   * be taken when calling this to ensure parameters are passed in registers
> @@ -231,7 +225,7 @@ after_vfp_restore:
>   * passed as r0, r1, and r2 (a maximum of 3 arguments in addition to the
>   * function pointer can be passed).  The function being called must be mapped
>   * in Hyp mode (see init_hyp_mode in arch/arm/kvm/arm.c).  Return values are
> - * passed in r0 and r1.
> + * passed in r0 (strictly 32bit).
>   *
>   * A function pointer with a value of 0xffffffff has a special meaning,
>   * and is used to implement __hyp_get_vectors in the same way as in
> -- 
> 2.1.4
> 

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From sboyd at codeaurora.org  Tue Feb  9 10:29:17 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Tue, 9 Feb 2016 10:29:17 -0800
Subject: [PATCH 0/2] CREG clk driver for NXP LPC18xx family
In-Reply-To: <CAGhQ9Vy14XR+-kgACiqPgs0SPueizD6Gd2q5kaNqM5mGna0V=g@mail.gmail.com>
References: <1436651307-24098-1-git-send-email-manabian@gmail.com>
 <20160208222637.GV4848@codeaurora.org>
 <CAGhQ9Vy14XR+-kgACiqPgs0SPueizD6Gd2q5kaNqM5mGna0V=g@mail.gmail.com>
Message-ID: <20160209182917.GA31947@codeaurora.org>

On 02/09, Joachim Eastwood wrote:
> Hi Stephen,
> 
> On 8 February 2016 at 23:26, Stephen Boyd <sboyd at codeaurora.org> wrote:
> > On 07/11, Joachim Eastwood wrote:
> >> This patch set adds a clk driver for the low power clocks found in
> >> the CREG block on lpc18xx. CREG is a collection of miscellaneous
> >> configuration registers that can be accessed through a syscon
> >> regmap interface. The clk driver makes it possible to setup and
> >> enabled these two clocks.
> >>
> >> This need to support peripherals like the internal RTC on the
> >> lpc18xx platform.
> >>
> >
> > I know this is many months old, but is this driver still
> > required? I can apply it to clk-next if so.
> 
> It is still needed for the internal RTC (rtc-lpc24xx) on lpc18xx. The
> RTC uses a 1 kHz clock that is controlled in CREG (misc system regs).
> 
> Note; if you apply it you will most likely get a very trivial conflict
> in drivers/clk/nxp/Makefile because clk-lpc32xx.c has been added since
> these patches was sent.
> 

Hm, ok. I see that Mike had some comments on the thread that look
to be left unanswered? Care to address those first?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From javier at osg.samsung.com  Tue Feb  9 10:30:05 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Tue,  9 Feb 2016 15:30:05 -0300
Subject: [PATCH] ARM: dts: Move syscon reboot/poweroff to common dtsi for
 Exynos
Message-ID: <1455042606-10075-1-git-send-email-javier@osg.samsung.com>

All Exynos SoCs have the same syscon reboot and poweroff device nodes so
there is no need to duplicate the same on each SoC dtsi and can be moved
to a common dtsi that can be included by all the SoCs dtsi files.

Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>

---
Hello,

The patch was tested on an Exynos5800 Peach Pi Chromebook and an
Exynos5422 Odroid XU4 board. Reboot and poweroff worked for both.

But testing on Exynos3 and Exynos4 will be highly appreciated.

Best regards,
Javier

 arch/arm/boot/dts/exynos-syscon-restart.dtsi | 23 +++++++++++++++++++++++
 arch/arm/boot/dts/exynos3250.dtsi            | 15 +--------------
 arch/arm/boot/dts/exynos4.dtsi               | 15 +--------------
 arch/arm/boot/dts/exynos5.dtsi               | 15 +--------------
 arch/arm/boot/dts/exynos5410.dtsi            | 15 +--------------
 5 files changed, 27 insertions(+), 56 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos-syscon-restart.dtsi

diff --git a/arch/arm/boot/dts/exynos-syscon-restart.dtsi b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
new file mode 100644
index 000000000000..2b8acf554881
--- /dev/null
+++ b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
@@ -0,0 +1,23 @@
+/*
+ * Samsung's Exynos SoC syscon reboot/poweroff nodes common definition.
+ *
+ * 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.
+ */
+
+/ {
+	poweroff: syscon-poweroff {
+		compatible = "syscon-poweroff";
+		regmap = <&pmu_system_controller>;
+		offset = <0x330C>; /* PS_HOLD_CONTROL */
+		mask = <0x5200>; /* reset value */
+	};
+
+	reboot: syscon-reboot {
+		compatible = "syscon-reboot";
+		regmap = <&pmu_system_controller>;
+		offset = <0x0400>; /* SWRESET */
+		mask = <0x1>;
+	};
+};
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 18e3deffbf48..d9c221517935 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -19,6 +19,7 @@
 
 #include "skeleton.dtsi"
 #include "exynos4-cpu-thermal.dtsi"
+#include "exynos-syscon-restart.dtsi"
 #include <dt-bindings/clock/exynos3250.h>
 
 / {
@@ -152,20 +153,6 @@
 			interrupt-parent = <&gic>;
 		};
 
-		poweroff: syscon-poweroff {
-			compatible = "syscon-poweroff";
-			regmap = <&pmu_system_controller>;
-			offset = <0x330C>; /* PS_HOLD_CONTROL */
-			mask = <0x5200>; /* Reset value */
-		};
-
-		reboot: syscon-reboot {
-			compatible = "syscon-reboot";
-			regmap = <&pmu_system_controller>;
-			offset = <0x0400>; /* SWRESET */
-			mask = <0x1>;
-		};
-
 		mipi_phy: video-phy at 10020710 {
 			compatible = "samsung,s5pv210-mipi-video-phy";
 			#phy-cells = <1>;
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index ca621a92319e..e6f6939ccdfa 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -21,6 +21,7 @@
 
 #include <dt-bindings/clock/exynos4.h>
 #include <dt-bindings/clock/exynos-audss-clk.h>
+#include "exynos-syscon-restart.dtsi"
 #include "skeleton.dtsi"
 
 / {
@@ -163,20 +164,6 @@
 		interrupt-parent = <&gic>;
 	};
 
-	poweroff: syscon-poweroff {
-		compatible = "syscon-poweroff";
-		regmap = <&pmu_system_controller>;
-		offset = <0x330C>; /* PS_HOLD_CONTROL */
-		mask = <0x5200>; /* reset value */
-	};
-
-	reboot: syscon-reboot {
-		compatible = "syscon-reboot";
-		regmap = <&pmu_system_controller>;
-		offset = <0x0400>; /* SWRESET */
-		mask = <0x1>;
-	};
-
 	dsi_0: dsi at 11C80000 {
 		compatible = "samsung,exynos4210-mipi-dsi";
 		reg = <0x11C80000 0x10000>;
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index b61d1f637510..92313cac035e 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -14,6 +14,7 @@
  */
 
 #include "skeleton.dtsi"
+#include "exynos-syscon-restart.dtsi"
 
 / {
 	interrupt-parent = <&gic>;
@@ -93,20 +94,6 @@
 		status = "disabled";
 	};
 
-	poweroff: syscon-poweroff {
-		compatible = "syscon-poweroff";
-		regmap = <&pmu_system_controller>;
-		offset = <0x330C>; /* PS_HOLD_CONTROL */
-		mask = <0x5200>; /* reset value */
-	};
-
-	reboot: syscon-reboot {
-		compatible = "syscon-reboot";
-		regmap = <&pmu_system_controller>;
-		offset = <0x0400>; /* SWRESET */
-		mask = <0x1>;
-	};
-
 	fimd: fimd at 14400000 {
 		compatible = "samsung,exynos5250-fimd";
 		interrupt-parent = <&combiner>;
diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
index f3490f567344..fa558674ac76 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -14,6 +14,7 @@
  */
 
 #include "skeleton.dtsi"
+#include "exynos-syscon-restart.dtsi"
 #include <dt-bindings/clock/exynos5410.h>
 
 / {
@@ -117,20 +118,6 @@
 			reg = <0x10040000 0x5000>;
 		};
 
-		poweroff: syscon-poweroff {
-			compatible = "syscon-poweroff";
-			regmap = <&pmu_system_controller>;
-			offset = <0x330C>; /* PS_HOLD_CONTROL */
-			mask = <0x5200>; /* reset value */
-		};
-
-		reboot: syscon-reboot {
-			compatible = "syscon-reboot";
-			regmap = <&pmu_system_controller>;
-			offset = <0x0400>; /* SWRESET */
-			mask = <0x1>;
-		};
-
 		mct: mct at 101C0000 {
 			compatible = "samsung,exynos4210-mct";
 			reg = <0x101C0000 0xB00>;
-- 
2.5.0



From maxime.ripard at free-electrons.com  Tue Feb  9 10:31:13 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 9 Feb 2016 19:31:13 +0100
Subject: [PATCH v2] ARM: sunxi_defconfig: Enable MUSB HDRC driver with
 Allwinner glue
In-Reply-To: <1455031887-14147-1-git-send-email-wens@csie.org>
References: <1455031887-14147-1-git-send-email-wens@csie.org>
Message-ID: <20160209183113.GV31506@lukather>

On Tue, Feb 09, 2016 at 11:31:27PM +0800, Chen-Yu Tsai wrote:
> Allwinner SoCs typically have a Mentor Graphics Inventra MUSB dual role
> controller for USB OTG.
> 
> Now that the issue with MUSB and USB gadget registration order has been
> resolved, we can enable this driver in dual role mode. This requires the
> NOP USB transceiver driver, which is also enabled.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/71e9bf9b/attachment.sig>

From maxime.ripard at free-electrons.com  Tue Feb  9 10:34:20 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 9 Feb 2016 19:34:20 +0100
Subject: [linux-sunxi][PATCH v2] ARM: dts: sun7i: Enable USB DRC on Itead
 Ibox
In-Reply-To: <1455010156-27754-1-git-send-email-codekipper@gmail.com>
References: <1455010156-27754-1-git-send-email-codekipper@gmail.com>
Message-ID: <20160209183420.GW31506@lukather>

Hi,

On Tue, Feb 09, 2016 at 10:29:16AM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
> 
> Enable the otg/drc usb controller on the Itead Ibox device.
> 
> Note this board has the otg-vbus connected directly to the 5v-dcc of
> the board, so there is no vbus0 regulator, nor vbus0-det.
> 
> Signed-off-by: Marcus Cooper <codekipper at gmail.com>
> ---
> Changes since v1:
> - Added comment concerning vbus0 regulator and detection to commit message
> 
> ---
>  arch/arm/boot/dts/sun7i-a20-itead-ibox.dts     | 14 ++++++++++++++
>  arch/arm/boot/dts/sunxi-itead-core-common.dtsi |  9 +++++++++
>  2 files changed, 23 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
> index 661c21d..a512581 100644
> --- a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
> @@ -118,8 +118,22 @@
>  		allwinner,drive = <SUN4I_PINCTRL_20_MA>;
>  		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>  	};
> +
> +	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
> +		allwinner,pins = "PH4";
> +		allwinner,function = "gpio_in";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +	};
>  };
>  
>  &reg_ahci_5v {
>  	status = "okay";
>  };
> +
> +&usbphy {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&usb0_id_detect_pin>;
> +	usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
> +	status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
> index 2565d51..d22eea3 100644
> --- a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
> +++ b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
> @@ -88,6 +88,10 @@
>  	status = "okay";
>  };
>  
> +&otg_sram {
> +	status = "okay";
> +};
> +
>  #include "axp209.dtsi"
>  
>  &reg_dcdc2 {
> @@ -129,6 +133,11 @@
>  	status = "okay";
>  };
>  
> +&usb_otg {
> +	dr_mode = "otg";

If VBUS is tied to 5V, without anyway to disable it, then it cannot do
OTG.

The mode it can do is host.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/0f3e8167/attachment.sig>

From maxime.ripard at free-electrons.com  Tue Feb  9 10:36:31 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 9 Feb 2016 19:36:31 +0100
Subject: [linux-sunxi][PATCH v2] ARM: dts: sun7i: Enable USB DRC on
 Olimex A20 EVB
In-Reply-To: <1455010408-27896-1-git-send-email-codekipper@gmail.com>
References: <1455010408-27896-1-git-send-email-codekipper@gmail.com>
Message-ID: <20160209183631.GX31506@lukather>

On Tue, Feb 09, 2016 at 10:33:28AM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
> 
> Enable the otg/drc usb controller on the Olimex A20 EVB.
> 
> Signed-off-by: Marcus Cooper <codekipper at gmail.com>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/04746ce9/attachment-0001.sig>

From maxime.ripard at free-electrons.com  Tue Feb  9 10:36:45 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 9 Feb 2016 19:36:45 +0100
Subject: [linux-sunxi][PATCH] ARM: dts: sun7i: Enable USB DRC on MK808C
In-Reply-To: <1455009932-27616-1-git-send-email-codekipper@gmail.com>
References: <1455009932-27616-1-git-send-email-codekipper@gmail.com>
Message-ID: <20160209183645.GY31506@lukather>

On Tue, Feb 09, 2016 at 10:25:32AM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
> 
> Enable the otg/drc usb controller on the MK808C.
> 
> Signed-off-by: Marcus Cooper <codekipper at gmail.com>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/e459fb62/attachment.sig>

From christoffer.dall at linaro.org  Tue Feb  9 10:39:01 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:39:01 +0100
Subject: [PATCH v2 26/28] ARM: KVM: Remove unused hyp_pc field
In-Reply-To: <1454583645-10144-27-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-27-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209183901.GC5171@cbox>

On Thu, Feb 04, 2016 at 11:00:43AM +0000, Marc Zyngier wrote:
> This field was never populated, and the panic code already
> does something similar. Delete the related code.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/include/asm/kvm_emulate.h | 5 -----
>  arch/arm/include/asm/kvm_host.h    | 1 -
>  arch/arm/kernel/asm-offsets.c      | 1 -
>  arch/arm/kvm/handle_exit.c         | 5 -----
>  4 files changed, 12 deletions(-)
> 
> diff --git a/arch/arm/include/asm/kvm_emulate.h b/arch/arm/include/asm/kvm_emulate.h
> index f710616..8a8c6de 100644
> --- a/arch/arm/include/asm/kvm_emulate.h
> +++ b/arch/arm/include/asm/kvm_emulate.h
> @@ -108,11 +108,6 @@ static inline phys_addr_t kvm_vcpu_get_fault_ipa(struct kvm_vcpu *vcpu)
>  	return ((phys_addr_t)vcpu->arch.fault.hpfar & HPFAR_MASK) << 8;
>  }
>  
> -static inline unsigned long kvm_vcpu_get_hyp_pc(struct kvm_vcpu *vcpu)
> -{
> -	return vcpu->arch.fault.hyp_pc;
> -}
> -
>  static inline bool kvm_vcpu_dabt_isvalid(struct kvm_vcpu *vcpu)
>  {
>  	return kvm_vcpu_get_hsr(vcpu) & HSR_ISV;
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index daf6a71..19e9aba 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -85,7 +85,6 @@ struct kvm_vcpu_fault_info {
>  	u32 hsr;		/* Hyp Syndrome Register */
>  	u32 hxfar;		/* Hyp Data/Inst. Fault Address Register */
>  	u32 hpfar;		/* Hyp IPA Fault Address Register */
> -	u32 hyp_pc;		/* PC when exception was taken from Hyp mode */
>  };
>  
>  /*
> diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
> index 1f24c32..27d0581 100644
> --- a/arch/arm/kernel/asm-offsets.c
> +++ b/arch/arm/kernel/asm-offsets.c
> @@ -175,7 +175,6 @@ int main(void)
>    DEFINE(CPU_CTXT_VFP,		offsetof(struct kvm_cpu_context, vfp));
>    DEFINE(CPU_CTXT_GP_REGS,	offsetof(struct kvm_cpu_context, gp_regs));
>    DEFINE(GP_REGS_USR,		offsetof(struct kvm_regs, usr_regs));
> -  DEFINE(VCPU_HYP_PC,		offsetof(struct kvm_vcpu, arch.fault.hyp_pc));
>  #endif
>    BLANK();
>  #ifdef CONFIG_VDSO
> diff --git a/arch/arm/kvm/handle_exit.c b/arch/arm/kvm/handle_exit.c
> index 3ede90d..5377d753 100644
> --- a/arch/arm/kvm/handle_exit.c
> +++ b/arch/arm/kvm/handle_exit.c
> @@ -147,11 +147,6 @@ int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
>  	switch (exception_index) {
>  	case ARM_EXCEPTION_IRQ:
>  		return 1;
> -	case ARM_EXCEPTION_UNDEFINED:
> -		kvm_err("Undefined exception in Hyp mode at: %#08lx\n",
> -			kvm_vcpu_get_hyp_pc(vcpu));
> -		BUG();
> -		panic("KVM: Hypervisor undefined exception!\n");
>  	case ARM_EXCEPTION_DATA_ABORT:
>  	case ARM_EXCEPTION_PREF_ABORT:
>  	case ARM_EXCEPTION_HVC:
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:39:17 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:39:17 +0100
Subject: [PATCH v2 27/28] ARM: KVM: Remove handling of
 ARM_EXCEPTION_DATA/PREF_ABORT
In-Reply-To: <1454583645-10144-28-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-28-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209183917.GD5171@cbox>

On Thu, Feb 04, 2016 at 11:00:44AM +0000, Marc Zyngier wrote:
> These are now handled as a panic, so there is little point in
> keeping them around.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kvm/handle_exit.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/kvm/handle_exit.c b/arch/arm/kvm/handle_exit.c
> index 5377d753..3f1ef0d 100644
> --- a/arch/arm/kvm/handle_exit.c
> +++ b/arch/arm/kvm/handle_exit.c
> @@ -147,8 +147,6 @@ int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
>  	switch (exception_index) {
>  	case ARM_EXCEPTION_IRQ:
>  		return 1;
> -	case ARM_EXCEPTION_DATA_ABORT:
> -	case ARM_EXCEPTION_PREF_ABORT:
>  	case ARM_EXCEPTION_HVC:
>  		/*
>  		 * See ARM ARM B1.14.1: "Hyp traps on instructions
> -- 
> 2.1.4
> 

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:39:48 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:39:48 +0100
Subject: [PATCH v2 28/28] ARM: KVM: Remove
 __kvm_hyp_exit/__kvm_hyp_exit_end
In-Reply-To: <1454583645-10144-29-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-29-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209183948.GE5171@cbox>

On Thu, Feb 04, 2016 at 11:00:45AM +0000, Marc Zyngier wrote:
> I have no idea what these were for - probably a leftover from an
> early implementation. Good bye!
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:39:53 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:39:53 +0100
Subject: [PATCH v2 01/28] ARM: KVM: Move the  HYP code to its own section
In-Reply-To: <1454583645-10144-2-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-2-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209183953.GF5171@cbox>

On Thu, Feb 04, 2016 at 11:00:18AM +0000, Marc Zyngier wrote:
> In order to be able to spread the HYP code into multiple compilation
> units, adopt a layout similar to that of arm64:
> - the HYP text is emited in its own section (.hyp.text)
> - two linker generated symbols are use to identify the boundaries
>   of that section
> 
> No functionnal change.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:39:59 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:39:59 +0100
Subject: [PATCH v2 02/28] ARM: KVM: Remove
 __kvm_hyp_code_start/__kvm_hyp_code_end
In-Reply-To: <1454583645-10144-3-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-3-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209183959.GG5171@cbox>

On Thu, Feb 04, 2016 at 11:00:19AM +0000, Marc Zyngier wrote:
> Now that we've unified the way we refer to the HYP text between
> arm and arm64, drop __kvm_hyp_code_start/end, and just use the
> __hyp_text_start/end symbols.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>


From horms at verge.net.au  Tue Feb  9 10:39:21 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 9 Feb 2016 19:39:21 +0100
Subject: [GIT PULL] Renesas ARM Based SoC DT Updates for v4.6
In-Reply-To: <CAMuHMdVWYVEHTvGYEZkEXpEaMzfZ_NfMAb0o8HtVcJM+GDdfmA@mail.gmail.com>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
 <20160208215130.GJ25468@localhost>
 <CAMuHMdVWYVEHTvGYEZkEXpEaMzfZ_NfMAb0o8HtVcJM+GDdfmA@mail.gmail.com>
Message-ID: <20160209183921.GA1089@verge.net.au>

On Tue, Feb 09, 2016 at 08:39:31AM +0100, Geert Uytterhoeven wrote:
> Hi Olof,
> 
> On Mon, Feb 8, 2016 at 10:51 PM, Olof Johansson <olof at lixom.net> wrote:
> > On Thu, Feb 04, 2016 at 03:30:02PM +0100, Simon Horman wrote:
> >> Please consider these Renesas ARM based SoC DT updates for v4.6.
> >>
> >>
> >> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> >>
> >>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-for-v4.6
> >>
> >> for you to fetch changes up to d7a11140d0a659e5c1f83627792f95b6713030a2:
> >>
> >>   ARM: dts: silk: Enable SCIF_CLK frequency and pins (2016-02-02 14:02:28 +0100)
> >>
> >> ----------------------------------------------------------------
> >> Renesas ARM Based SoC DT Updates for v4.6
> >>
> >> * Use SCIF and USBHS fallback compatibility strings
> >> * Add Baud Rate Generator (BRG) support for (H)SCIF
> >> * Enable SCIF_CLK frequency and pins
> >> * Use GIC_* defines
> >> * Migrate to generic l2c OF initialization on r8a7740
> >> * Enable audio on r8a7793/gose
> >> * Enable HDMI vidio out on r8a7793
> >> * Enable i2c on r8a7793/gose
> >> * Enable QSPI on alt
> >> * Enable GPIO keys and leds on gise
> >> * Enable audio on porter
> >> * Enable DU on porter
> >>
> >> ----------------------------------------------------------------
> >> Geert Uytterhoeven (22):
> >>       ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization
> >>       ARM: shmobile: r8a7740: Remove mapping of L2 cache controller registers
> >
> > Hmm. Those aren't DT changes. There's also nothing for r8a7740 to convert
> > L2 init to DT earlier in this branch, which makes this look like it's just
> > a generic cleanup that should go in independently in your cleanup branch.
> >
> > Or am I missing some dependency that isn't obvious? If I'm not, then please
> > respin this branch and move those to the place they belong (cleanup).
> 
> The dependency is commit 374e70075e58acfe ("ARM: shmobile: r8a7740 dtsi: Add
> L2 cache-controller node"), which has already entered mainline in v4.5-rc1.
> 
> So I agree with your comments.

Sorry for the mix-up.
I'll see about respinning this.


From christoffer.dall at linaro.org  Tue Feb  9 10:42:07 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:42:07 +0100
Subject: [PATCH v2 03/28] ARM: KVM: Move VFP registers to a CPU context
 structure
In-Reply-To: <1454583645-10144-4-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-4-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184207.GH5171@cbox>

On Thu, Feb 04, 2016 at 11:00:20AM +0000, Marc Zyngier wrote:
> In order to turn the WS code into something that looks a bit
> more like the arm64 version, move the VFP registers into a
> CPU context container for both the host and the guest.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:42:23 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:42:23 +0100
Subject: [PATCH v2 06/28] ARM: KVM: Add a HYP-specific header file
In-Reply-To: <1454583645-10144-7-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-7-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184223.GK5171@cbox>

On Thu, Feb 04, 2016 at 11:00:23AM +0000, Marc Zyngier wrote:
> In order to expose the various HYP services that are private to
> the hypervisor, add a new hyp.h file.
> 
> So far, it only contains mundane things such as section annotation
> and VA manipulation.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:42:13 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:42:13 +0100
Subject: [PATCH v2 04/28] ARM: KVM: Move CP15 array into the CPU context
 structure
In-Reply-To: <1454583645-10144-5-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-5-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184213.GI5171@cbox>

On Thu, Feb 04, 2016 at 11:00:21AM +0000, Marc Zyngier wrote:
> Continuing our rework of the CPU context, we now move the CP15
> array into the CPU context structure. As this causes quite a bit
> of churn, we introduce the vcpu_cp15() macro that abstract the
> location of the actual array. This will probably help next time
> we have to revisit that code.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:42:18 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:42:18 +0100
Subject: [PATCH v2 05/28] ARM: KVM: Move GP registers into the CPU
 context structure
In-Reply-To: <1454583645-10144-6-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-6-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184218.GJ5171@cbox>

On Thu, Feb 04, 2016 at 11:00:22AM +0000, Marc Zyngier wrote:
> Continuing our rework of the CPU context, we now move the GP
> registers into the CPU context structure.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:42:28 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:42:28 +0100
Subject: [PATCH v2 08/28] ARM: KVM: Add TLB invalidation code
In-Reply-To: <1454583645-10144-9-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-9-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184228.GL5171@cbox>

On Thu, Feb 04, 2016 at 11:00:25AM +0000, Marc Zyngier wrote:
> Convert the TLB invalidation code to C, hooking it into the
> build system whilst we're at it.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kvm/Makefile     |  1 +
>  arch/arm/kvm/hyp/Makefile |  5 ++++
>  arch/arm/kvm/hyp/hyp.h    |  5 ++++
>  arch/arm/kvm/hyp/tlb.c    | 71 +++++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 82 insertions(+)
>  create mode 100644 arch/arm/kvm/hyp/Makefile
>  create mode 100644 arch/arm/kvm/hyp/tlb.c
> 
> diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
> index c5eef02c..eb1bf43 100644
> --- a/arch/arm/kvm/Makefile
> +++ b/arch/arm/kvm/Makefile
> @@ -17,6 +17,7 @@ AFLAGS_interrupts.o := -Wa,-march=armv7-a$(plus_virt)
>  KVM := ../../../virt/kvm
>  kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o $(KVM)/vfio.o
>  
> +obj-$(CONFIG_KVM_ARM_HOST) += hyp/
>  obj-y += kvm-arm.o init.o interrupts.o
>  obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o
>  obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o
> diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
> new file mode 100644
> index 0000000..36c760d
> --- /dev/null
> +++ b/arch/arm/kvm/hyp/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for Kernel-based Virtual Machine module, HYP part
> +#
> +
> +obj-$(CONFIG_KVM_ARM_HOST) += tlb.o
> diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
> index 727089f..5808bbd 100644
> --- a/arch/arm/kvm/hyp/hyp.h
> +++ b/arch/arm/kvm/hyp/hyp.h
> @@ -42,4 +42,9 @@
>  })
>  #define read_sysreg(...)		__read_sysreg(__VA_ARGS__)
>  
> +#define VTTBR		__ACCESS_CP15_64(6, c2)
> +#define ICIALLUIS	__ACCESS_CP15(c7, 0, c1, 0)
> +#define TLBIALLIS	__ACCESS_CP15(c8, 0, c3, 0)
> +#define TLBIALLNSNHIS	__ACCESS_CP15(c8, 4, c3, 4)
> +
>  #endif /* __ARM_KVM_HYP_H__ */
> diff --git a/arch/arm/kvm/hyp/tlb.c b/arch/arm/kvm/hyp/tlb.c
> new file mode 100644
> index 0000000..993fe89
> --- /dev/null
> +++ b/arch/arm/kvm/hyp/tlb.c
> @@ -0,0 +1,71 @@
> +/*
> + * Original code:
> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> + * Author: Christoffer Dall <c.dall at virtualopensystems.com>
> + *
> + * Mostly rewritten in C by Marc Zyngier <marc.zyngier at arm.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 "hyp.h"
> +
> +/**
> + * Flush per-VMID TLBs
> + *
> + * __kvm_tlb_flush_vmid(struct kvm *kvm);
> + *
> + * We rely on the hardware to broadcast the TLB invalidation to all CPUs
> + * inside the inner-shareable domain (which is the case for all v7
> + * implementations).  If we come across a non-IS SMP implementation, we'll
> + * have to use an IPI based mechanism. Until then, we stick to the simple
> + * hardware assisted version.
> + *
> + * As v7 does not support flushing per IPA, just nuke the whole TLB
> + * instead, ignoring the ipa value.
> + */
> +static void __hyp_text __tlb_flush_vmid(struct kvm *kvm)
> +{
> +	dsb(ishst);
> +
> +	/* Switch to requested VMID */
> +	kvm = kern_hyp_va(kvm);
> +	write_sysreg(kvm->arch.vttbr, VTTBR);
> +	isb();
> +
> +	write_sysreg(0, TLBIALLIS);
> +	dsb(ish);
> +	isb();
> +
> +	write_sysreg(0, VTTBR);
> +}
> +
> +__alias(__tlb_flush_vmid) void __weak __kvm_tlb_flush_vmid(struct kvm *kvm);
> +
> +static void __hyp_text __tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
> +{
> +	__tlb_flush_vmid(kvm);
> +}
> +
> +__alias(__tlb_flush_vmid_ipa) void __weak __kvm_tlb_flush_vmid_ipa(struct kvm *kvm,
> +							    phys_addr_t ipa);
> +
> +static void __hyp_text __tlb_flush_vm_context(void)
> +{
> +	dsb(ishst);

do we need this initial dsb?

> +	write_sysreg(0, TLBIALLNSNHIS);
> +	write_sysreg(0, ICIALLUIS);
> +	dsb(ish);

we used to have an isb here, but we got rid of this because it's always
followed by eret?

> +}
> +
> +__alias(__tlb_flush_vm_context) void __weak __kvm_flush_vm_context(void);
> -- 
> 2.1.4
> 


From christoffer.dall at linaro.org  Tue Feb  9 10:42:35 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:42:35 +0100
Subject: [PATCH v2 09/28] ARM: KVM: Add CP15 save/restore code
In-Reply-To: <1454583645-10144-10-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-10-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184235.GM5171@cbox>

On Thu, Feb 04, 2016 at 11:00:26AM +0000, Marc Zyngier wrote:
> Concert the CP15 save/restore code to C.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:42:47 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:42:47 +0100
Subject: [PATCH v2 11/28] ARM: KVM: Add vgic v2 save/restore
In-Reply-To: <1454583645-10144-12-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-12-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184247.GO5171@cbox>

On Thu, Feb 04, 2016 at 11:00:28AM +0000, Marc Zyngier wrote:
> This patch shouldn't exist, as we should be able to reuse the
> arm64 version for free. I'll get there eventually, but in the
> meantime I need an interrupt controller.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:42:42 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:42:42 +0100
Subject: [PATCH v2 10/28] ARM: KVM: Add timer save/restore
In-Reply-To: <1454583645-10144-11-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-11-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184242.GN5171@cbox>

On Thu, Feb 04, 2016 at 11:00:27AM +0000, Marc Zyngier wrote:
> This patch shouldn't exist, as we should be able to reuse the
> arm64 version for free. I'll get there eventually, but in the
> meantime I need a timer ticking.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kvm/hyp/Makefile   |  1 +
>  arch/arm/kvm/hyp/hyp.h      |  8 +++++
>  arch/arm/kvm/hyp/timer-sr.c | 71 +++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 80 insertions(+)
>  create mode 100644 arch/arm/kvm/hyp/timer-sr.c
> 
> diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
> index 9f96fcb..9241ae8 100644
> --- a/arch/arm/kvm/hyp/Makefile
> +++ b/arch/arm/kvm/hyp/Makefile
> @@ -4,3 +4,4 @@
>  
>  obj-$(CONFIG_KVM_ARM_HOST) += tlb.o
>  obj-$(CONFIG_KVM_ARM_HOST) += cp15-sr.o
> +obj-$(CONFIG_KVM_ARM_HOST) += timer-sr.o
> diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
> index ab2cb82..4924418 100644
> --- a/arch/arm/kvm/hyp/hyp.h
> +++ b/arch/arm/kvm/hyp/hyp.h
> @@ -46,6 +46,9 @@
>  #define TTBR1		__ACCESS_CP15_64(1, c2)
>  #define VTTBR		__ACCESS_CP15_64(6, c2)
>  #define PAR		__ACCESS_CP15_64(0, c7)
> +#define CNTV_CVAL	__ACCESS_CP15_64(3, c14)
> +#define CNTVOFF		__ACCESS_CP15_64(4, c14)
> +
>  #define CSSELR		__ACCESS_CP15(c0, 2, c0, 0)
>  #define VMPIDR		__ACCESS_CP15(c0, 4, c0, 5)
>  #define SCTLR		__ACCESS_CP15(c1, 0, c0, 0)
> @@ -71,6 +74,11 @@
>  #define TID_URO		__ACCESS_CP15(c13, 0, c0, 3)
>  #define TID_PRIV	__ACCESS_CP15(c13, 0, c0, 4)
>  #define CNTKCTL		__ACCESS_CP15(c14, 0, c1, 0)
> +#define CNTV_CTL	__ACCESS_CP15(c14, 0, c3, 1)
> +#define CNTHCTL		__ACCESS_CP15(c14, 4, c1, 0)
> +
> +void __timer_save_state(struct kvm_vcpu *vcpu);
> +void __timer_restore_state(struct kvm_vcpu *vcpu);
>  
>  void __sysreg_save_state(struct kvm_cpu_context *ctxt);
>  void __sysreg_restore_state(struct kvm_cpu_context *ctxt);
> diff --git a/arch/arm/kvm/hyp/timer-sr.c b/arch/arm/kvm/hyp/timer-sr.c
> new file mode 100644
> index 0000000..d7535fd
> --- /dev/null
> +++ b/arch/arm/kvm/hyp/timer-sr.c
> @@ -0,0 +1,71 @@
> +/*
> + * Copyright (C) 2012-2015 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.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 <clocksource/arm_arch_timer.h>
> +#include <linux/compiler.h>
> +#include <linux/kvm_host.h>
> +
> +#include <asm/kvm_mmu.h>
> +
> +#include "hyp.h"
> +
> +/* vcpu is already in the HYP VA space */
> +void __hyp_text __timer_save_state(struct kvm_vcpu *vcpu)
> +{
> +	struct kvm *kvm = kern_hyp_va(vcpu->kvm);
> +	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> +	u64 val;
> +
> +	if (kvm->arch.timer.enabled) {
> +		timer->cntv_ctl = read_sysreg(CNTV_CTL);
> +		timer->cntv_cval = read_sysreg(CNTV_CVAL);
> +	}
> +
> +	/* Disable the virtual timer */
> +	write_sysreg(0, CNTV_CTL);
> +
> +	/* Allow physical timer/counter access for the host */
> +	val = read_sysreg(CNTHCTL);
> +	val |= CNTHCTL_EL1PCTEN | CNTHCTL_EL1PCEN;
> +	write_sysreg(val, CNTHCTL);
> +
> +	/* Clear cntvoff for the host */
> +	write_sysreg(0, CNTVOFF);

in the asm version we only did this if the timer was enabled, probably
the theory being that only in that case did we mody the offset.  But it
should be safe to just clear the cntvoff in any case, right?

> +}
> +
> +void __hyp_text __timer_restore_state(struct kvm_vcpu *vcpu)
> +{
> +	struct kvm *kvm = kern_hyp_va(vcpu->kvm);
> +	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> +	u64 val;
> +
> +	/*
> +	 * Disallow physical timer access for the guest
> +	 * Physical counter access is allowed
> +	 */
> +	val = read_sysreg(CNTHCTL);
> +	val &= ~CNTHCTL_EL1PCEN;
> +	val |= CNTHCTL_EL1PCTEN;
> +	write_sysreg(val, CNTHCTL);
> +
> +	if (kvm->arch.timer.enabled) {
> +		write_sysreg(kvm->arch.timer.cntvoff, CNTVOFF);
> +		write_sysreg(timer->cntv_cval, CNTV_CVAL);
> +		isb();
> +		write_sysreg(timer->cntv_ctl, CNTV_CTL);
> +	}
> +}
> -- 
> 2.1.4
> 

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:42:52 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:42:52 +0100
Subject: [PATCH v2 12/28] ARM: KVM: Add VFP save/restore
In-Reply-To: <1454583645-10144-13-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-13-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184252.GP5171@cbox>

On Thu, Feb 04, 2016 at 11:00:29AM +0000, Marc Zyngier wrote:
> This is almost a copy/paste of the existing version, with a couple
> of subtle differences:
> - Only write to FPEXC once on the save path
> - Add an isb when enabling VFP access
> 
> The patch also defines a few sysreg accessors and a __vfp_enabled
> predicate that test the VFP trapping state.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:45:03 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:45:03 +0100
Subject: [PATCH v2 19/28] ARM: KVM: Add panic handling code
In-Reply-To: <1454583645-10144-20-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-20-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184503.GV5171@cbox>

On Thu, Feb 04, 2016 at 11:00:36AM +0000, Marc Zyngier wrote:
> Instead of spinning forever, let's "properly" handle any unexpected
> exception ("properly" meaning "print a spat on the console and die").
> 
> This has proved useful quite a few times...
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kvm/hyp/hyp-entry.S | 28 +++++++++++++++++++++-------
>  arch/arm/kvm/hyp/switch.c    | 38 ++++++++++++++++++++++++++++++++++++++
>  2 files changed, 59 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/kvm/hyp/hyp-entry.S b/arch/arm/kvm/hyp/hyp-entry.S
> index 44bc11f..ca412ad 100644
> --- a/arch/arm/kvm/hyp/hyp-entry.S
> +++ b/arch/arm/kvm/hyp/hyp-entry.S
> @@ -75,15 +75,29 @@ __kvm_hyp_vector:
>  
>  .macro invalid_vector label, cause
>  	.align
> -\label:	b	.
> +\label:	mov	r0, #\cause
> +	b	__hyp_panic
>  .endm
>  
> -	invalid_vector	hyp_reset
> -	invalid_vector	hyp_undef
> -	invalid_vector	hyp_svc
> -	invalid_vector	hyp_pabt
> -	invalid_vector	hyp_dabt
> -	invalid_vector	hyp_fiq
> +	invalid_vector	hyp_reset	ARM_EXCEPTION_RESET
> +	invalid_vector	hyp_undef	ARM_EXCEPTION_UNDEFINED
> +	invalid_vector	hyp_svc		ARM_EXCEPTION_SOFTWARE
> +	invalid_vector	hyp_pabt	ARM_EXCEPTION_PREF_ABORT
> +	invalid_vector	hyp_dabt	ARM_EXCEPTION_DATA_ABORT
> +	invalid_vector	hyp_fiq		ARM_EXCEPTION_FIQ
> +
> +ENTRY(__hyp_do_panic)
> +	mrs	lr, cpsr
> +	bic	lr, lr, #MODE_MASK
> +	orr	lr, lr, #SVC_MODE
> +THUMB(	orr	lr, lr, #PSR_T_BIT	)
> +	msr	spsr_cxsf, lr
> +	ldr	lr, =panic
> +	msr	ELR_hyp, lr
> +	ldr	lr, =kvm_call_hyp
> +	clrex
> +	eret
> +ENDPROC(__hyp_do_panic)
>  
>  hyp_hvc:
>  	/*
> diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
> index 8bfd729..67f3944 100644
> --- a/arch/arm/kvm/hyp/switch.c
> +++ b/arch/arm/kvm/hyp/switch.c
> @@ -188,3 +188,41 @@ again:
>  }
>  
>  __alias(__guest_run) int __weak __kvm_vcpu_run(struct kvm_vcpu *vcpu);
> +
> +static const char * const __hyp_panic_string[] = {
> +	[ARM_EXCEPTION_RESET]      = "\nHYP panic: RST?? PC:%08x CPSR:%08x",
> +	[ARM_EXCEPTION_UNDEFINED]  = "\nHYP panic: UNDEF PC:%08x CPSR:%08x",
> +	[ARM_EXCEPTION_SOFTWARE]   = "\nHYP panic: SVC?? PC:%08x CPSR:%08x",
> +	[ARM_EXCEPTION_PREF_ABORT] = "\nHYP panic: PABRT PC:%08x CPSR:%08x",
> +	[ARM_EXCEPTION_DATA_ABORT] = "\nHYP panic: DABRT PC:%08x ADDR:%08x",
> +	[ARM_EXCEPTION_IRQ]        = "\nHYP panic: IRQ?? PC:%08x CPSR:%08x",
> +	[ARM_EXCEPTION_FIQ]        = "\nHYP panic: FIQ?? PC:%08x CPSR:%08x",
> +	[ARM_EXCEPTION_HVC]        = "\nHYP panic: HVC?? PC:%08x CPSR:%08x",

Why the question marks?

> +};
> +
> +void __hyp_text __noreturn __hyp_panic(int cause)
> +{
> +	u32 elr = read_special(ELR_hyp);
> +	u32 val;
> +
> +	if (cause == ARM_EXCEPTION_DATA_ABORT)
> +		val = read_sysreg(HDFAR);
> +	else
> +		val = read_special(SPSR);
> +
> +	if (read_sysreg(VTTBR)) {
> +		struct kvm_vcpu *vcpu;
> +		struct kvm_cpu_context *host_ctxt;
> +
> +		vcpu = (struct kvm_vcpu *)read_sysreg(HTPIDR);
> +		host_ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
> +		__deactivate_traps(vcpu);
> +		__deactivate_vm(vcpu);
> +		__sysreg_restore_state(host_ctxt);
> +	}
> +
> +	/* Call panic for real */
> +	__hyp_do_panic(__hyp_panic_string[cause], elr, val);
> +
> +	unreachable();
> +}
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Otherwise:

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:45:13 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:45:13 +0100
Subject: [PATCH v2 22/28] ARM: KVM: Switch to C-based stage2 init
In-Reply-To: <1454583645-10144-23-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-23-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184513.GX5171@cbox>

Mising (sarcastic) commit message?

On Thu, Feb 04, 2016 at 11:00:39AM +0000, Marc Zyngier wrote:
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:45:17 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:45:17 +0100
Subject: [PATCH v2 23/28] ARM: KVM: Remove __weak attributes
In-Reply-To: <1454583645-10144-24-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-24-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184517.GY5171@cbox>

On Thu, Feb 04, 2016 at 11:00:40AM +0000, Marc Zyngier wrote:
> Now that the old code is long gone, we can remove all the weak
> attributes, as there is only one version of the code.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:45:22 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:45:22 +0100
Subject: [PATCH v2 24/28] ARM: KVM: Turn CP15 defines to an enum
In-Reply-To: <1454583645-10144-25-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-25-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184522.GZ5171@cbox>

On Thu, Feb 04, 2016 at 11:00:41AM +0000, Marc Zyngier wrote:
> Just like on arm64, having the CP15 registers expressed as a set
> of #defines has been very conflict-prone. Let's turn it into an
> enum, which should make it more manageable.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:42:57 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:42:57 +0100
Subject: [PATCH v2 13/28] ARM: KVM: Add banked registers save/restore
In-Reply-To: <1454583645-10144-14-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-14-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184257.GQ5171@cbox>

On Thu, Feb 04, 2016 at 11:00:30AM +0000, Marc Zyngier wrote:
> Banked registers are one of the many perks of the 32bit architecture,
> and the world switch needs to cope with it.
> 
> This requires some "special" accessors, as these are not accessed
> using a standard coprocessor instruction.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:44:45 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:44:45 +0100
Subject: [PATCH v2 14/28] ARM: KVM: Add guest entry code
In-Reply-To: <1454583645-10144-15-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-15-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184445.GR5171@cbox>

On Thu, Feb 04, 2016 at 11:00:31AM +0000, Marc Zyngier wrote:
> Add the very minimal piece of code that is now required to jump
> into the guest (and return from it). This code is only concerned
> with save/restoring the USR registers (r0-r12+lr for the guest,
> r4-r12+lr for the host), as everything else is dealt with in C
> (VFP is another matter though).
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kvm/hyp/Makefile |  1 +
>  arch/arm/kvm/hyp/entry.S  | 70 +++++++++++++++++++++++++++++++++++++++++++++++
>  arch/arm/kvm/hyp/hyp.h    |  2 ++
>  3 files changed, 73 insertions(+)
>  create mode 100644 arch/arm/kvm/hyp/entry.S
> 
> diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
> index 173bd1d..c779690 100644
> --- a/arch/arm/kvm/hyp/Makefile
> +++ b/arch/arm/kvm/hyp/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_KVM_ARM_HOST) += timer-sr.o
>  obj-$(CONFIG_KVM_ARM_HOST) += vgic-v2-sr.o
>  obj-$(CONFIG_KVM_ARM_HOST) += vfp.o
>  obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o
> +obj-$(CONFIG_KVM_ARM_HOST) += entry.o
> diff --git a/arch/arm/kvm/hyp/entry.S b/arch/arm/kvm/hyp/entry.S
> new file mode 100644
> index 0000000..32f79b0
> --- /dev/null
> +++ b/arch/arm/kvm/hyp/entry.S
> @@ -0,0 +1,70 @@
> +/*
> + * Copyright (C) 2016 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.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/linkage.h>
> +#include <asm/asm-offsets.h>
> +#include <asm/kvm_arm.h>
> +
> +	.arch_extension     virt
> +
> +	.text
> +	.pushsection	.hyp.text, "ax"
> +
> +#define USR_REGS_OFFSET		(CPU_CTXT_GP_REGS + GP_REGS_USR)
> +
> +/* int __guest_enter(struct kvm_vcpu *vcpu, struct kvm_cpu_context *host) */
> +ENTRY(__guest_enter)
> +	@ Save host registers
> +	add	r1, r1, #(USR_REGS_OFFSET + S_R4)
> +	stm	r1!, {r4-r12}
> +	str	lr, [r1, #4]	@ Skip SP_usr (already saved)
> +
> +	@ Restore guest registers
> +	add	r0, r0,  #(VCPU_GUEST_CTXT + USR_REGS_OFFSET + S_R0)

this really relies on offsetof(struct pt_regs, ARM_r0) == 0, which I
guess will likely never change, but given there's both a kernel and uapi
version of struct pt_regs, are we sure about this?

> +	ldr	lr, [r0, #S_LR]
> +	ldm	r0, {r0-r12}
> +
> +	clrex
> +	eret
> +ENDPROC(__guest_enter)
> +
> +ENTRY(__guest_exit)
> +	/*
> +	 * return convention:
> +	 * guest r0, r1, r2 saved on the stack
> +	 * r0: vcpu pointer
> +	 * r1: exception code
> +	 */
> +
> +	add	r2, r0, #(VCPU_GUEST_CTXT + USR_REGS_OFFSET + S_R3)
> +	stm	r2!, {r3-r12}
> +	str	lr, [r2, #4]
> +	add	r2, r0, #(VCPU_GUEST_CTXT + USR_REGS_OFFSET + S_R0)
> +	pop	{r3, r4, r5}		@ r0, r1, r2
> +	stm	r2, {r3-r5}
> +
> +	ldr	r0, [r0, #VCPU_HOST_CTXT]
> +	add	r0, r0, #(USR_REGS_OFFSET + S_R4)
> +	ldm	r0!, {r4-r12}
> +	ldr	lr, [r0, #4]
> +
> +	mov	r0, r1
> +	bx	lr
> +ENDPROC(__guest_exit)
> +
> +	.popsection
> +
> diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
> index 278eb1f..b3f6ed2 100644
> --- a/arch/arm/kvm/hyp/hyp.h
> +++ b/arch/arm/kvm/hyp/hyp.h
> @@ -110,4 +110,6 @@ static inline bool __vfp_enabled(void)
>  void __hyp_text __banked_save_state(struct kvm_cpu_context *ctxt);
>  void __hyp_text __banked_restore_state(struct kvm_cpu_context *ctxt);
>  
> +int asmlinkage __guest_enter(struct kvm_vcpu *vcpu,
> +			     struct kvm_cpu_context *host);
>  #endif /* __ARM_KVM_HYP_H__ */
> -- 
> 2.1.4
> 

Otherwise:
Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:44:49 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:44:49 +0100
Subject: [PATCH v2 15/28] ARM: KVM: Add VFP lazy save/restore handler
In-Reply-To: <1454583645-10144-16-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-16-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184449.GS5171@cbox>

On Thu, Feb 04, 2016 at 11:00:32AM +0000, Marc Zyngier wrote:
> Similar to the arm64 version, add the code that deals with VFP traps,
> re-enabling VFP, save/restoring the registers and resuming the guest.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:44:59 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:44:59 +0100
Subject: [PATCH v2 17/28] ARM: KVM: Add populating of fault data structure
In-Reply-To: <1454583645-10144-18-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-18-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184459.GU5171@cbox>

On Thu, Feb 04, 2016 at 11:00:34AM +0000, Marc Zyngier wrote:
> On guest exit, we must take care of populating our fault data
> structure so that the host code can handle it. This includes
> resolving the IPA for permission faults, which can result in
> restarting the guest.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:45:09 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:45:09 +0100
Subject: [PATCH v2 21/28] ARM: KVM: Remove the old world switch
In-Reply-To: <1454583645-10144-22-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-22-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184509.GW5171@cbox>

On Thu, Feb 04, 2016 at 11:00:38AM +0000, Marc Zyngier wrote:
> As we now have a full reimplementation of the world switch, it is
> time to kiss the old stuff goodbye. I'm not sure we'll miss it.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:44:55 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:44:55 +0100
Subject: [PATCH v2 16/28] ARM: KVM: Add the new world switch implementation
In-Reply-To: <1454583645-10144-17-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-17-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184455.GT5171@cbox>

On Thu, Feb 04, 2016 at 11:00:33AM +0000, Marc Zyngier wrote:
> The new world switch implementation is modeled after the arm64 one,
> calling the various save/restore functions in turn, and having as
> little state as possible.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kvm/hyp/Makefile |   1 +
>  arch/arm/kvm/hyp/hyp.h    |   7 +++
>  arch/arm/kvm/hyp/switch.c | 136 ++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 144 insertions(+)
>  create mode 100644 arch/arm/kvm/hyp/switch.c
> 
> diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
> index c779690..cfab402 100644
> --- a/arch/arm/kvm/hyp/Makefile
> +++ b/arch/arm/kvm/hyp/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_KVM_ARM_HOST) += vgic-v2-sr.o
>  obj-$(CONFIG_KVM_ARM_HOST) += vfp.o
>  obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o
>  obj-$(CONFIG_KVM_ARM_HOST) += entry.o
> +obj-$(CONFIG_KVM_ARM_HOST) += switch.o
> diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
> index b3f6ed2..2ca651f 100644
> --- a/arch/arm/kvm/hyp/hyp.h
> +++ b/arch/arm/kvm/hyp/hyp.h
> @@ -60,11 +60,16 @@
>  #define CNTV_CVAL	__ACCESS_CP15_64(3, c14)
>  #define CNTVOFF		__ACCESS_CP15_64(4, c14)
>  
> +#define MIDR		__ACCESS_CP15(c0, 0, c0, 0)
>  #define CSSELR		__ACCESS_CP15(c0, 2, c0, 0)
> +#define VMIDR		__ACCESS_CP15(c0, 4, c0, 0)

Nit: This is called VPIDR in v7 and VMPIDR_EL2 in v8 IIUC.  Should we
refer to it by one of those names instead?

>  #define VMPIDR		__ACCESS_CP15(c0, 4, c0, 5)
>  #define SCTLR		__ACCESS_CP15(c1, 0, c0, 0)
>  #define CPACR		__ACCESS_CP15(c1, 0, c0, 2)
> +#define HCR		__ACCESS_CP15(c1, 4, c1, 0)
> +#define HDCR		__ACCESS_CP15(c1, 4, c1, 1)
>  #define HCPTR		__ACCESS_CP15(c1, 4, c1, 2)
> +#define HSTR		__ACCESS_CP15(c1, 4, c1, 3)
>  #define TTBCR		__ACCESS_CP15(c2, 0, c0, 2)
>  #define DACR		__ACCESS_CP15(c3, 0, c0, 0)
>  #define DFSR		__ACCESS_CP15(c5, 0, c0, 0)
> @@ -73,6 +78,7 @@
>  #define AIFSR		__ACCESS_CP15(c5, 0, c1, 1)
>  #define DFAR		__ACCESS_CP15(c6, 0, c0, 0)
>  #define IFAR		__ACCESS_CP15(c6, 0, c0, 2)
> +#define HDFAR		__ACCESS_CP15(c6, 4, c0, 0)
>  #define ICIALLUIS	__ACCESS_CP15(c7, 0, c1, 0)
>  #define TLBIALLIS	__ACCESS_CP15(c8, 0, c3, 0)
>  #define TLBIALLNSNHIS	__ACCESS_CP15(c8, 4, c3, 4)
> @@ -85,6 +91,7 @@
>  #define TID_URW		__ACCESS_CP15(c13, 0, c0, 2)
>  #define TID_URO		__ACCESS_CP15(c13, 0, c0, 3)
>  #define TID_PRIV	__ACCESS_CP15(c13, 0, c0, 4)
> +#define HTPIDR		__ACCESS_CP15(c13, 4, c0, 2)
>  #define CNTKCTL		__ACCESS_CP15(c14, 0, c1, 0)
>  #define CNTV_CTL	__ACCESS_CP15(c14, 0, c3, 1)
>  #define CNTHCTL		__ACCESS_CP15(c14, 4, c1, 0)
> diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
> new file mode 100644
> index 0000000..f715b0d
> --- /dev/null
> +++ b/arch/arm/kvm/hyp/switch.c
> @@ -0,0 +1,136 @@
> +/*
> + * Copyright (C) 2015 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier at arm.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 <asm/kvm_asm.h>
> +#include "hyp.h"
> +
> +__asm__(".arch_extension     virt");
> +
> +static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu, u32 *fpexc)

Nit: can you document the fpexc or name it host_fpexc_preserve or something?

> +{
> +	u32 val;
> +
> +	/*
> +	 * We are about to set HCPTR.TCP10/11 to trap all floating point
> +	 * register accesses to HYP, however, the ARM ARM clearly states that
> +	 * traps are only taken to HYP if the operation would not otherwise
> +	 * trap to SVC.  Therefore, always make sure that for 32-bit guests,
> +	 * we set FPEXC.EN to prevent traps to SVC, when setting the TCP bits.
> +	 */
> +	val = read_sysreg(VFP_FPEXC);
> +	*fpexc = val;
> +	if (!(val & FPEXC_EN)) {
> +		write_sysreg(val | FPEXC_EN, VFP_FPEXC);
> +		isb();
> +	}
> +
> +	write_sysreg(vcpu->arch.hcr | vcpu->arch.irq_lines, HCR);
> +	/* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
> +	write_sysreg(HSTR_T(15), HSTR);
> +	write_sysreg(HCPTR_TTA | HCPTR_TCP(10) | HCPTR_TCP(11), HCPTR);
> +	val = read_sysreg(HDCR);
> +	write_sysreg(val | HDCR_TPM | HDCR_TPMCR, HDCR);
> +}
> +
> +static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
> +{
> +	u32 val;
> +
> +	write_sysreg(0, HCR);
> +	write_sysreg(0, HSTR);
> +	val = read_sysreg(HDCR);
> +	write_sysreg(val & ~(HDCR_TPM | HDCR_TPMCR), HDCR);
> +	write_sysreg(0, HCPTR);
> +}
> +
> +static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
> +{
> +	struct kvm *kvm = kern_hyp_va(vcpu->kvm);
> +	write_sysreg(kvm->arch.vttbr, VTTBR);
> +	write_sysreg(vcpu->arch.midr, VMIDR);
> +}
> +
> +static void __hyp_text __deactivate_vm(struct kvm_vcpu *vcpu)
> +{
> +	write_sysreg(0, VTTBR);
> +	write_sysreg(read_sysreg(MIDR), VMIDR);
> +}
> +
> +static void __hyp_text __vgic_save_state(struct kvm_vcpu *vcpu)
> +{
> +	__vgic_v2_save_state(vcpu);
> +}
> +
> +static void __hyp_text __vgic_restore_state(struct kvm_vcpu *vcpu)
> +{
> +	__vgic_v2_restore_state(vcpu);
> +}
> +
> +static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
> +{
> +	struct kvm_cpu_context *host_ctxt;
> +	struct kvm_cpu_context *guest_ctxt;
> +	bool fp_enabled;
> +	u64 exit_code;
> +	u32 fpexc;
> +
> +	vcpu = kern_hyp_va(vcpu);
> +	write_sysreg(vcpu, HTPIDR);
> +
> +	host_ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
> +	guest_ctxt = &vcpu->arch.ctxt;
> +
> +	__sysreg_save_state(host_ctxt);
> +	__banked_save_state(host_ctxt);
> +
> +	__activate_traps(vcpu, &fpexc);
> +	__activate_vm(vcpu);
> +
> +	__vgic_restore_state(vcpu);
> +	__timer_restore_state(vcpu);
> +
> +	__sysreg_restore_state(guest_ctxt);
> +	__banked_restore_state(guest_ctxt);
> +
> +	/* Jump in the fire! */
> +	exit_code = __guest_enter(vcpu, host_ctxt);
> +	/* And we're baaack! */
> +
> +	fp_enabled = __vfp_enabled();
> +
> +	__banked_save_state(guest_ctxt);
> +	__sysreg_save_state(guest_ctxt);
> +	__timer_save_state(vcpu);
> +	__vgic_save_state(vcpu);
> +
> +	__deactivate_traps(vcpu);
> +	__deactivate_vm(vcpu);
> +
> +	__banked_restore_state(host_ctxt);
> +	__sysreg_restore_state(host_ctxt);
> +
> +	if (fp_enabled) {
> +		__vfp_save_state(&guest_ctxt->vfp);
> +		__vfp_restore_state(&host_ctxt->vfp);
> +	}
> +
> +	write_sysreg(fpexc, VFP_FPEXC);
> +
> +	return exit_code;
> +}
> +
> +__alias(__guest_run) int __weak __kvm_vcpu_run(struct kvm_vcpu *vcpu);
> -- 
> 2.1.4
> 

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Tue Feb  9 10:45:26 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:45:26 +0100
Subject: [PATCH v2 25/28] ARM: KVM: Cleanup asm-offsets.c
In-Reply-To: <1454583645-10144-26-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-26-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184526.GA5171@cbox>

On Thu, Feb 04, 2016 at 11:00:42AM +0000, Marc Zyngier wrote:
> Since we don't have much assembler left, most of the KVM stuff
> in asm-offsets.c is now superfluous. Let's get rid of it.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>


From geert+renesas at glider.be  Tue Feb  9 10:45:04 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Tue,  9 Feb 2016 19:45:04 +0100
Subject: [PATCH] ARM: shmobile: r8a7740: Remove obsolete #include
 <asm/hardware/cache-l2x0.h>
Message-ID: <1455043504-27933-1-git-send-email-geert+renesas@glider.be>

As of commit 540977ae9746e60c ("ARM: shmobile: r8a7740: Migrate to
generic l2c OF initialization"), no l2x0 functionality is used from
platform code, so the include can be removed.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
As you plan to respin renesas-dt-for-v4.6, perhaps this can still be
folded in the original commit?

 arch/arm/mach-shmobile/setup-r8a7740.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 496569f9d578b863..3e71cd4168dd00cb 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -23,7 +23,6 @@
 #include <asm/mach/map.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
-#include <asm/hardware/cache-l2x0.h>
 
 #include "common.h"
 
-- 
1.9.1



From christoffer.dall at linaro.org  Tue Feb  9 10:49:20 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 19:49:20 +0100
Subject: [PATCH v2 00/28] ARM: KVM: Rewrite the world switch in C (mostly)
In-Reply-To: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209184920.GB5171@cbox>

On Thu, Feb 04, 2016 at 11:00:17AM +0000, Marc Zyngier wrote:
> Now that the arm64 rewrite is in mainline, I've taken a stab at fixing
> the 32bit code the same way. This is fairly straightforward (once
> you've been through it once...), with a few patches that adapt the
> code to be similar to the 64bit version.
> 
> Note that the timer and GIC code should be made common between the two
> architectures, as this is litterally the exact same code (I've posted
> some proof of concept for that a while ago, see
> http://www.spinics.net/lists/kvm/msg126775.html).
> 
> This has been tested on a Dual A7, and the code is pushed on a branch:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm/wsinc
> 

This looks good overall.

I tested it briefly on TC2 and it seems generally happy.

-Christoffer


From horms at verge.net.au  Tue Feb  9 10:54:42 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 9 Feb 2016 19:54:42 +0100
Subject: [PATCH 0/2] ARM: shmobile: Remove legacy machine_desc.map_io()
 callbacks
In-Reply-To: <CAMuHMdVP8_9Nk8FQvHyVqfhK+Yhz2g0weE3nCxQeZ1wpeAEEUQ@mail.gmail.com>
References: <1453994246-12886-1-git-send-email-geert+renesas@glider.be>
 <20160202140738.GC4304@verge.net.au>
 <CAMuHMdVP8_9Nk8FQvHyVqfhK+Yhz2g0weE3nCxQeZ1wpeAEEUQ@mail.gmail.com>
Message-ID: <20160209185441.GA12049@verge.net.au>

On Mon, Feb 08, 2016 at 04:03:29PM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Tue, Feb 2, 2016 at 3:07 PM, Simon Horman <horms at verge.net.au> wrote:
> > On Thu, Jan 28, 2016 at 04:17:24PM +0100, Geert Uytterhoeven wrote:
> >> This patch series removes the legacy machine_desc.map_io() callback for
> >> SoCs that no longer rely on it, but use ioremap() instead.
> >>
> >> The patch for emev2 depends on "ARM: shmobile: Consolidate SCU mapping
> >> code" ("FIXME" commit ID reference to be updated).
> >>
> >> Thanks!
> >
> > Thanks, I have queued these up.
> 
> Thanks, but unfortunately it's not in renesas-devel-20160205-v4.5-rc2?

Sorry about that, I'll try to actually queue it up this time.


From christoffer.dall at linaro.org  Tue Feb  9 11:06:16 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 20:06:16 +0100
Subject: [RFC PATCH 0/5] arm/arm64: Making HYP vgic/timer save/restore
 common
In-Reply-To: <1453996565-19666-1-git-send-email-marc.zyngier@arm.com>
References: <1453996565-19666-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209190616.GC5171@cbox>

On Thu, Jan 28, 2016 at 03:56:00PM +0000, Marc Zyngier wrote:
> With the current state of the C conversion of arm and arm64 world
> switches, we are still unable to share some of the most obvious
> candidates (GIC and timer save/restore). In order to reduce the bloat,
> let's move these files to a common location (virt/kvm/arm/hyp).
> 
> The changes are extremely mechanical, with a small hack to deal with
> system register names on the 32bit side (I've decided to align on the
> 64bit names).
> 
> I'd like to know what people think of the common location. Does it
> makes sense to have a "hyp" subdirectory to indicate that this is not
> "normal" kernel code?

I think so, it means to me typically executing in "hyp/el2" or just
low-level hypervisor logic, in the case of VHE.


> 
> These patches are on top of 4.5-rc1, plus the VHE and 32bit WS rewrite
> patches, and I've pushed out a branch at
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/mov-hyp
> 
> Marc Zyngier (5):
>   arm64: KVM: Move kvm/hyp/hyp.h to include/asm/kvm_hyp.h
>   arm64: KVM: Move vgic-v2 and timer save/restore to virt/kvm/arm/hyp
>   ARM: KVM: Move kvm/hyp/hyp.h to include/asm/kvm_hyp.h
>   ARM: KVM: Use common version of vgic-v2-sr.c
>   ARM: KVM: Use common version of timer-sr.c
> 
>  arch/arm/{kvm/hyp/hyp.h => include/asm/kvm_hyp.h}  |  9 +++
>  arch/arm/kvm/hyp/Makefile                          |  7 +-
>  arch/arm/kvm/hyp/banked-sr.c                       |  2 +-
>  arch/arm/kvm/hyp/cp15-sr.c                         |  2 +-
>  arch/arm/kvm/hyp/switch.c                          |  2 +-
>  arch/arm/kvm/hyp/timer-sr.c                        | 71 ------------------
>  arch/arm/kvm/hyp/tlb.c                             |  2 +-
>  arch/arm/kvm/hyp/vgic-v2-sr.c                      | 84 ----------------------
>  .../arm64/{kvm/hyp/hyp.h => include/asm/kvm_hyp.h} |  0
>  arch/arm64/kvm/hyp/Makefile                        |  7 +-
>  arch/arm64/kvm/hyp/debug-sr.c                      |  4 +-
>  arch/arm64/kvm/hyp/switch.c                        |  3 +-
>  arch/arm64/kvm/hyp/sysreg-sr.c                     |  4 +-
>  arch/arm64/kvm/hyp/tlb.c                           |  2 +-
>  arch/arm64/kvm/hyp/vgic-v3-sr.c                    |  4 +-
>  {arch/arm64/kvm => virt/kvm/arm}/hyp/timer-sr.c    |  4 +-
>  {arch/arm64/kvm => virt/kvm/arm}/hyp/vgic-v2-sr.c  |  4 +-
>  17 files changed, 30 insertions(+), 181 deletions(-)
>  rename arch/arm/{kvm/hyp/hyp.h => include/asm/kvm_hyp.h} (93%)
>  delete mode 100644 arch/arm/kvm/hyp/timer-sr.c
>  delete mode 100644 arch/arm/kvm/hyp/vgic-v2-sr.c
>  rename arch/arm64/{kvm/hyp/hyp.h => include/asm/kvm_hyp.h} (100%)
>  rename {arch/arm64/kvm => virt/kvm/arm}/hyp/timer-sr.c (97%)
>  rename {arch/arm64/kvm => virt/kvm/arm}/hyp/vgic-v2-sr.c (98%)
> 
> -- 
> 2.1.4
> 


From horms at verge.net.au  Tue Feb  9 11:07:27 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 9 Feb 2016 20:07:27 +0100
Subject: [PATCH 0/3] ARM: shmobile: SCU cleanup and consolidation
In-Reply-To: <CAMuHMdUn7=AAehQqG5ezc4wkKjytOoVz7U9HT_HvPLVj+Na7Vg@mail.gmail.com>
References: <1453994012-12696-1-git-send-email-geert+renesas@glider.be>
 <20160202140550.GB4304@verge.net.au>
 <CAMuHMdUn7=AAehQqG5ezc4wkKjytOoVz7U9HT_HvPLVj+Na7Vg@mail.gmail.com>
Message-ID: <20160209190727.GB12049@verge.net.au>

On Mon, Feb 08, 2016 at 04:04:34PM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Tue, Feb 2, 2016 at 3:05 PM, Simon Horman <horms at verge.net.au> wrote:
> > On Thu, Jan 28, 2016 at 04:13:29PM +0100, Geert Uytterhoeven wrote:
> >> This patch series contains cleanups and consolidations of the SCU code
> >> for shmobile SoCs with Cortex-A9 CPU cores.
> >>
> >> This has been tested on emev2/kzm9d, r8a7779/marzen, and sh73a0/kzm9g.
> >>
> >> Thanks!
> >
> > Thanks, I have queued these up.
> 
> Except for the third patch?

It seems that I missed the first one too.
I'll try to do better this time around :^)


From horms at verge.net.au  Tue Feb  9 11:25:46 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 9 Feb 2016 20:25:46 +0100
Subject: [PATCH] ARM: shmobile: r8a7740: Remove obsolete #include
 <asm/hardware/cache-l2x0.h>
In-Reply-To: <1455043504-27933-1-git-send-email-geert+renesas@glider.be>
References: <1455043504-27933-1-git-send-email-geert+renesas@glider.be>
Message-ID: <20160209192546.GD12049@verge.net.au>

On Tue, Feb 09, 2016 at 07:45:04PM +0100, Geert Uytterhoeven wrote:
> As of commit 540977ae9746e60c ("ARM: shmobile: r8a7740: Migrate to
> generic l2c OF initialization"), no l2x0 functionality is used from
> platform code, so the include can be removed.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> ---
> As you plan to respin renesas-dt-for-v4.6, perhaps this can still be
> folded in the original commit?

Thanks, I have squashed this into the original commit.


From nicolas.pitre at linaro.org  Tue Feb  9 11:28:51 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 9 Feb 2016 14:28:51 -0500 (EST)
Subject: [PATCH v4 3/3] kallsyms: remove --page-offset command line option
In-Reply-To: <CAKv+Gu-rdP7-=Z2SO2jRS_dHzB8UDpZ7-RowN_400d32Qvxmqg@mail.gmail.com>
References: <1455030828-6416-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455030828-6416-4-git-send-email-ard.biesheuvel@linaro.org>
 <HKXPR06MB056549C714A864B2D4F37DCA8AD60@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu-rdP7-=Z2SO2jRS_dHzB8UDpZ7-RowN_400d32Qvxmqg@mail.gmail.com>
Message-ID: <alpine.LFD.2.20.1602091407380.17825@knanqh.ubzr>

On Tue, 9 Feb 2016, Ard Biesheuvel wrote:

> On 9 February 2016 at 17:09, Chris Brandt <Chris.Brandt at renesas.com> wrote:
> > On 9 Feb 2016, Ard Biesheuvel wrote:
> >
> >>diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
> >>index 02473b71643b..32c8d43590af 100644
> >>--- a/scripts/kallsyms.c
> >>+++ b/scripts/kallsyms.c
> >>@@ -63,7 +63,6 @@ static unsigned int table_size, table_cnt;
> >> static int all_symbols = 0;
> >> static int absolute_percpu = 0;
> >> static char symbol_prefix_char = '\0';
> >>-static unsigned long long kernel_start_addr = 0;
> >> static int base_relative = 0;
> >
> >
> >
> > You removed kernel_start_addr, but you didn't remove all the instances of it in the file (you did remove them all in V2 though).
> >
> > So, now I get:
> >
> >   CC      scripts/mod/devicetable-offsets.s
> > ../scripts/kallsyms.c: In function 'record_relative_base':
> > ../scripts/kallsyms.c:740:6: error: 'kernel_start_addr' undeclared (first use in this function)
> >   if (kernel_start_addr > 0) {
> >       ^
> > ../scripts/kallsyms.c:740:6: note: each undeclared identifier is reported only once for each function it appears in
> > make[2]: *** [scripts/kallsyms] Error 1
> >
> 
> That is because this patch
> 
> http://ozlabs.org/~akpm/mmots/broken-out/kallsyms-add-support-for-relative-offsets-in-kallsyms-address-table-v5.patch
> 
> is also in flight, via akpm's tree, and is expected to hit -next
> tomorrow. That patch removes this reference (or alternatively, will
> not introduce it anymore if akpm decides to fold it into
> http://ozlabs.org/~akpm/mmots/broken-out/kallsyms-add-support-for-relative-offsets-in-kallsyms-address-table.patch
> before submitting it)
> 
> Going forward, it probably makes sense to only submit #1 of this
> series for v4.6, and queue the remaining two after the merge window.

Well... If akpm agrees, you could get those patches back and create a 
tree of your own with all ACKs for this work to avoi all this patch 
ordering dependency nightmare (including the work that depends on this) 
and submit it upstream (to Linus maybe?) while having it merged in 
linux-next in the mean time.


Nicolas


From ddaney.cavm at gmail.com  Tue Feb  9 11:29:16 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Tue,  9 Feb 2016 11:29:16 -0800
Subject: [PATCH] arm64: Add workaround for Cavium erratum 27456
Message-ID: <1455046156-10582-1-git-send-email-ddaney.cavm@gmail.com>

From: Andrew Pinski <apinski at cavium.com>

On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
instructions may cause the icache to become invalid if it contains
data for a non-current ASID.

This patch implements the workaround (which flushes the local icache
when switching the mm) by using code patching.

Signed-off-by: Andrew Pinski <apinski at cavium.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 arch/arm64/Kconfig                  | 11 +++++++++++
 arch/arm64/include/asm/cpufeature.h |  3 ++-
 arch/arm64/kernel/cpu_errata.c      |  9 +++++++++
 arch/arm64/mm/proc.S                | 12 ++++++++++++
 4 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc6228..a969970 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -432,6 +432,17 @@ config CAVIUM_ERRATUM_23154
 
 	  If unsure, say Y.
 
+config CAVIUM_ERRATUM_27456
+	bool "Cavium erratum 27456: Broadcast TLBI instructions may cause the icache to become invalid"
+	default y
+	help
+	  On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
+	  instructions may cause the icache to become invalid if it
+	  contains data for a non-current ASID.  The fix is to flush
+	  the icache when changing the mm context.
+
+	  If unsure, say Y.
+
 endmenu
 
 
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 8f271b8..8136afc 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -30,8 +30,9 @@
 #define ARM64_HAS_LSE_ATOMICS			5
 #define ARM64_WORKAROUND_CAVIUM_23154		6
 #define ARM64_WORKAROUND_834220			7
+#define ARM64_WORKAROUND_CAVIUM_27456		8
 
-#define ARM64_NCAPS				8
+#define ARM64_NCAPS				9
 
 #ifndef __ASSEMBLY__
 
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index feb6b4e..a3e846a 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -100,6 +100,15 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
 		MIDR_RANGE(MIDR_THUNDERX, 0x00, 0x01),
 	},
 #endif
+#ifdef CONFIG_CAVIUM_ERRATUM_27456
+	{
+	/* Cavium ThunderX, T88 pass 1.x - 2.1 */
+		.desc = "Cavium erratum 27456",
+		.capability = ARM64_WORKAROUND_CAVIUM_27456,
+		MIDR_RANGE(MIDR_THUNDERX, 0x00,
+			   (1 << MIDR_VARIANT_SHIFT) | 1),
+	},
+#endif
 	{
 	}
 };
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index c164d2c..0f3be00 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -25,6 +25,8 @@
 #include <asm/hwcap.h>
 #include <asm/pgtable-hwdef.h>
 #include <asm/pgtable.h>
+#include <asm/cpufeature.h>
+#include <asm/alternative.h>
 
 #include "proc-macros.S"
 
@@ -137,7 +139,17 @@ ENTRY(cpu_do_switch_mm)
 	bfi	x0, x1, #48, #16		// set the ASID
 	msr	ttbr0_el1, x0			// set TTBR0
 	isb
+alternative_if_not ARM64_WORKAROUND_CAVIUM_27456
 	ret
+	nop
+	nop
+	nop
+alternative_else
+	ic	iallu
+	dsb	nsh
+	isb
+	ret
+alternative_endif
 ENDPROC(cpu_do_switch_mm)
 
 /*
-- 
1.8.3.1



From broonie at kernel.org  Tue Feb  9 11:36:16 2016
From: broonie at kernel.org (Mark Brown)
Date: Tue, 9 Feb 2016 19:36:16 +0000
Subject: [PATCH v5 3/5] mtd: devices: m25p80: add support for mmap read
 request
In-Reply-To: <1449807000-6457-4-git-send-email-vigneshr@ti.com>
References: <1449807000-6457-1-git-send-email-vigneshr@ti.com>
 <1449807000-6457-4-git-send-email-vigneshr@ti.com>
Message-ID: <20160209193616.GN13270@sirena.org.uk>

On Fri, Dec 11, 2015 at 09:39:58AM +0530, Vignesh R wrote:

> +	if (spi_flash_read_supported(spi)) {
> +		struct spi_flash_read_message msg;
> +		int ret;
> +
> +		msg.buf = buf;
> +		msg.from = from;
> +		msg.len = len;
> +		msg.read_opcode = nor->read_opcode;
> +		msg.addr_width = nor->addr_width;
> +		msg.dummy_bytes = dummy;
> +		/* TODO: Support other combinations */
> +		msg.opcode_nbits = SPI_NBITS_SINGLE;
> +		msg.addr_nbits = SPI_NBITS_SINGLE;
> +		msg.data_nbits = m25p80_rx_nbits(nor);
> +
> +		ret = spi_flash_read(spi, &msg);
> +		*retlen = msg.retlen;
> +		return ret;

Looking at this I can't help but think that spi_flash_read() ought to
have the stub in rather than the caller.  But given that we're pretty
much only ever expecting one user I'm not 100% sure it actually matters.
Anyway, I applied the first two patches.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/4e2f6800/attachment.sig>

From paul at pwsan.com  Tue Feb  9 11:36:40 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 9 Feb 2016 19:36:40 +0000 (UTC)
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <56BA2495.9020407@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
Message-ID: <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>

Hi Suman 

On Tue, 9 Feb 2016, Suman Anna wrote:

> On 02/09/2016 02:49 AM, Paul Walmsley wrote:
> > On Mon, 8 Feb 2016, Suman Anna wrote:
> >> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
> >>> On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:
> >>>
> >>>> Paul, what do you think is the best way forward to perform reset?
> >>>
> >>> Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
> >>> Those often need special reset handling to ensure that WFI/HLT-like 
> >>> instructions are executed after reset.  This special handling ensures that 
> >>> the IP blocks' bus initiator interfaces indicate that they are in standby 
> >>> to the PRCM - thus allowing power management for the rest of the chip to 
> >>> work correctly.
> >>>
> >>> But that doesn't seem to be the case with PCIe - and maybe others - 
> >>> possibly some of the MMUs?  
> >>
> >> Yeah, the sequencing between clocks and resets would still be the same
> >> for MMUs, so, adding the custom flags for MMUs is fine.
> > 
> > I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs.  
> > We've stated that the main point of the custom hardreset code is to handle 
> > processors that need to be placed into WFI/HLT, but it doesn't seem like 
> > there would be an equivalent for MMUs.  Thoughts?
> 
> The current OMAP IOMMU code already leverages the pdata ops for
> performing the resets, so not adding the flags would also require
> additional changes in the driver.
> 
> Also, the reset lines controlling the MMUs actually also manage the
> reset for all the other sub-modules other than the processor cores
> within the sub-systems. We have currently different issues (see [1] for
> eg. around the IPU sub-system entering RET in between), so from a PM
> point of view, we do prefer to place the MMUs also in reset when we are
> runtime suspended.

Should we reassert hardreset in _idle() for IP blocks that don't have 
HWMOD_CUSTOM_HARDRESET set on them?  Would that allow us to use this 
mechanism for the uncore hardreset lines, or are there other quirks?

Also - would that address the potential issue that you mentioned with the 
PCIe block, or is that a different issue?


- Paul


From Suravee.Suthikulpanit at amd.com  Tue Feb  9 11:49:55 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Tue, 9 Feb 2016 13:49:55 -0600
Subject: [PATCH V2 01/12] MAINTAINERS: Adding Maintainers for AMD Seattle
 Device Tree
In-Reply-To: <20160208213858.GG25468@localhost>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
 <1454954357-8395-2-git-send-email-Suravee.Suthikulpanit@amd.com>
 <20160208213858.GG25468@localhost>
Message-ID: <56BA42E3.7030502@amd.com>



On 02/08/2016 03:38 PM, Olof Johansson wrote:
> On Mon, Feb 08, 2016 at 11:59:06AM -0600, Suravee Suthikulpanit wrote:
>> From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
>>
>> Adding maintainers for AMD Seattle device tree.
>>
>> Signed-off-by: Brijesh Singh <brijeshkumar.singh at amd.com>
>> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
>> Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com>
>
> Thanks, I've applied the series to next/dt64 now.
>
>
> -Olof
>

Thank you,
Suravee


From horms at verge.net.au  Tue Feb  9 11:50:54 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 9 Feb 2016 20:50:54 +0100
Subject: [PATCH 5/5] ARM: dts: r8a7794 add sound support
In-Reply-To: <2179456.HznTXDfKhZ@wasted.cogentembedded.com>
References: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>
 <2179456.HznTXDfKhZ@wasted.cogentembedded.com>
Message-ID: <20160209195054.GA14008@verge.net.au>

On Tue, Feb 09, 2016 at 02:04:07AM +0300, Sergei Shtylyov wrote:
> Define the generic R8A7794 part of  the sound device node.
> This sound device  is a complex one and comprises the Audio Clock Generator
> (ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
> (SSI[U]), and Audio DMAC-Peripheral-Peripheral.
> It is up  to the board file to enable the device.
> 
> This patch is based on the R8A7791 sound work by Kuninori Morimoto.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> ---
>  arch/arm/boot/dts/r8a7794.dtsi |  171 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 171 insertions(+)
> 
> Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
> ===================================================================
> --- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
> +++ renesas/arch/arm/boot/dts/r8a7794.dtsi
> @@ -1309,4 +1309,175 @@
>  		#iommu-cells = <1>;
>  		status = "disabled";
>  	};
> +
> +	rcar_sound: sound at ec500000 {
> +		/*
> +		 * #sound-dai-cells is required
> +		 *
> +		 * Single DAI : #sound-dai-cells = <0>;         <&rcar_sound>;
> +		 * Multi  DAI : #sound-dai-cells = <1>;         <&rcar_sound N>;
> +		 */
> +		compatible = "renesas,rcar_sound-r8a7794",
> +			     "renesas,rcar_sound-gen2";
> +		reg =	<0 0xec500000 0 0x1000>, /* SCU */
> +			<0 0xec5a0000 0 0x100>,  /* ADG */
> +			<0 0xec540000 0 0x1000>, /* SSIU */
> +			<0 0xec541000 0 0x280>,  /* SSI */
> +			<0 0xec740000 0 0x200>;  /* Audio DMAC peri peri */
> +		reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
> +
> +		clocks = <&mstp10_clks R8A7794_CLK_SSI_ALL>,
> +			 <&mstp10_clks R8A7794_CLK_SSI9>,
> +			 <&mstp10_clks R8A7794_CLK_SSI8>,
> +			 <&mstp10_clks R8A7794_CLK_SSI7>,
> +			 <&mstp10_clks R8A7794_CLK_SSI6>,
> +			 <&mstp10_clks R8A7794_CLK_SSI5>,
> +			 <&mstp10_clks R8A7794_CLK_SSI4>,
> +			 <&mstp10_clks R8A7794_CLK_SSI3>,
> +			 <&mstp10_clks R8A7794_CLK_SSI2>,
> +			 <&mstp10_clks R8A7794_CLK_SSI1>,
> +			 <&mstp10_clks R8A7794_CLK_SSI0>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC9>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC8>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC7>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC6>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC5>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC4>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC3>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC2>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC1>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC0>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_DVC0>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_DVC1>,
> +			 <&audio_clka>, <&audio_clkb>, <&audio_clkc>,
> +			 <&m2_clk>;
> +		clock-names = "ssi-all",
> +			      "ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
> +			      "ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0",
> +			      "src.9", "src.8", "src.7", "src.6", "src.5",
> +			      "src.4", "src.3", "src.2", "src.1", "src.0",
> +			      "clk_a", "clk_b", "clk_c", "clk_i";
> +		power-domains = <&cpg_clocks>;
> +
> +		status = "disabled";
> +		rcar_sound,src {
> +			src0: src at 0 {
> +				interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x85>, <&audma0 0x9a>;
> +				dma-names = "rx", "tx";
> +			};
> +			src1: src at 1 {
> +				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x87>, <&audma0 0x9c>;
> +				dma-names = "rx", "tx";
> +			};
> +			src2: src at 2 {
> +				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x89>, <&audma0 0x9e>;
> +				dma-names = "rx", "tx";
> +			};
> +			src3: src at 3 {
> +				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
> +				dma-names = "rx", "tx";
> +			};
> +			src4: src at 4 {
> +				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
> +				dma-names = "rx", "tx";
> +			};
> +			src5: src at 5 {
> +				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
> +				dma-names = "rx", "tx";
> +			};
> +			src6: src at 6 {
> +				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x91>, <&audma0 0xb4>;
> +				dma-names = "rx", "tx";
> +			};
> +			src7: src at 7 {
> +				interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x93>, <&audma0 0xb6>;
> +				dma-names = "rx", "tx";
> +			};
> +			src8: src at 8 {
> +				interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x95>, <&audma0 0xb8>;
> +				dma-names = "rx", "tx";
> +			};
> +			src9: src at 9 {
> +				interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x97>, <&audma0 0xba>;
> +				dma-names = "rx", "tx";
> +			};
> +		};

My reading of the documentation is that src0, 7, 8 and 9 are not
present on the r8a7794. I am referring to Figure 38.1b or r1.02 of
the R-Car Gen2 User's Manual.

[snip]


From marc.zyngier at arm.com  Tue Feb  9 11:52:22 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 9 Feb 2016 19:52:22 +0000
Subject: [PATCH] arm64: Add workaround for Cavium erratum 27456
In-Reply-To: <1455046156-10582-1-git-send-email-ddaney.cavm@gmail.com>
References: <1455046156-10582-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <20160209195222.0882d7f7@arm.com>

On Tue,  9 Feb 2016 11:29:16 -0800
David Daney <ddaney.cavm at gmail.com> wrote:

Hi David,

> From: Andrew Pinski <apinski at cavium.com>
> 
> On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
> instructions may cause the icache to become invalid if it contains
> data for a non-current ASID.
> 
> This patch implements the workaround (which flushes the local icache
> when switching the mm) by using code patching.
> 
> Signed-off-by: Andrew Pinski <apinski at cavium.com>
> Signed-off-by: David Daney <david.daney at cavium.com>
> ---
>  arch/arm64/Kconfig                  | 11 +++++++++++
>  arch/arm64/include/asm/cpufeature.h |  3 ++-
>  arch/arm64/kernel/cpu_errata.c      |  9 +++++++++
>  arch/arm64/mm/proc.S                | 12 ++++++++++++
>  4 files changed, 34 insertions(+), 1 deletion(-)

It would be good to update Documentation/arm64/silicon-errata.txt to
reflect the fact that there is a workaround available for this erratum.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.


From info at lategoodbye.de  Tue Feb  9 11:54:03 2016
From: info at lategoodbye.de (Stefan Wahren)
Date: Tue, 9 Feb 2016 20:54:03 +0100
Subject: [PATCH 1/4] spi: bcm2835aux: fix bitmask defines
In-Reply-To: <1455041435-8015-2-git-send-email-stephanolbrich@gmx.de>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <1455041435-8015-2-git-send-email-stephanolbrich@gmx.de>
Message-ID: <56BA43DB.7030209@lategoodbye.de>

Hi Stephan,

Am 09.02.2016 um 19:10 schrieb stephanolbrich at gmx.de:
> From: Stephan Olbrich <stephanolbrich at gmx.de>
>
> The bitmasks for txempty and idle interrupts were interchanged.
>
> Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
> ---
>   drivers/spi/spi-bcm2835aux.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
> index 7de6f84..ecc73c0 100644
> --- a/drivers/spi/spi-bcm2835aux.c
> +++ b/drivers/spi/spi-bcm2835aux.c
> @@ -73,8 +73,8 @@
>
>   /* Bitfields in CNTL1 */
>   #define BCM2835_AUX_SPI_CNTL1_CSHIGH	0x00000700
> -#define BCM2835_AUX_SPI_CNTL1_IDLE	0x00000080
> -#define BCM2835_AUX_SPI_CNTL1_TXEMPTY	0x00000040

according to a comment in this file these values are from 
brcm_usrlib/dag/vmcsx/vcinclude/bcm2708_chip/aux_io.h.

So you want to say that at least these 2 are wrong and you took the 
values from BCM2835-ARM-Peripherals.pdf [1]?

I think it's worth to mention it.

Regards

[1] - 
https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

> +#define BCM2835_AUX_SPI_CNTL1_TXEMPTY	0x00000080
> +#define BCM2835_AUX_SPI_CNTL1_IDLE	0x00000040
>   #define BCM2835_AUX_SPI_CNTL1_MSBF_IN	0x00000002
>   #define BCM2835_AUX_SPI_CNTL1_KEEP_IN	0x00000001
>





From hdegoede at redhat.com  Tue Feb  9 11:54:52 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Tue, 9 Feb 2016 20:54:52 +0100
Subject: [linux-sunxi][PATCH v2] ARM: dts: sun7i: Enable USB DRC on Itead
 Ibox
In-Reply-To: <CAEKpxBncN5-WYTNTw+8jfZypiMNfJt=55qEx2zTPfvZmjr9XdQ@mail.gmail.com>
References: <1455010156-27754-1-git-send-email-codekipper@gmail.com>
 <20160209183420.GW31506@lukather>
 <CAEKpxBncN5-WYTNTw+8jfZypiMNfJt=55qEx2zTPfvZmjr9XdQ@mail.gmail.com>
Message-ID: <56BA440C.5030903@redhat.com>

Hi,

On 02/09/2016 08:10 PM, Code Kipper wrote:
>
>
> On 9 February 2016 at 19:34, Maxime Ripard <maxime.ripard at free-electrons.com <mailto:maxime.ripard at free-electrons.com>> wrote:
>  > Hi,
>  >
>  > On Tue, Feb 09, 2016 at 10:29:16AM +0100, codekipper at gmail.com <mailto:codekipper at gmail.com> wrote:
>  >> From: Marcus Cooper <codekipper at gmail.com <mailto:codekipper at gmail.com>>
>  >>
>  >> Enable the otg/drc usb controller on the Itead Ibox device.
>  >>
>  >> Note this board has the otg-vbus connected directly to the 5v-dcc of
>  >> the board, so there is no vbus0 regulator, nor vbus0-det.
>  >>
>  >> Signed-off-by: Marcus Cooper <codekipper at gmail.com <mailto:codekipper at gmail.com>>
>  >> ---
>  >> Changes since v1:
>  >> - Added comment concerning vbus0 regulator and detection to commit message
>  >>
>  >> ---
>  >>  arch/arm/boot/dts/sun7i-a20-itead-ibox.dts     | 14 ++++++++++++++
>  >>  arch/arm/boot/dts/sunxi-itead-core-common.dtsi |  9 +++++++++
>  >>  2 files changed, 23 insertions(+)
>  >>
>  >> diff --git a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
>  >> index 661c21d..a512581 100644
>  >> --- a/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
>  >> +++ b/arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
>  >> @@ -118,8 +118,22 @@
>  >>               allwinner,drive = <SUN4I_PINCTRL_20_MA>;
>  >>               allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>  >>       };
>  >> +
>  >> +     usb0_id_detect_pin: usb0_id_detect_pin at 0 {
>  >> +             allwinner,pins = "PH4";
>  >> +             allwinner,function = "gpio_in";
>  >> +             allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>  >> +             allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>  >> +     };
>  >>  };
>  >>
>  >>  &reg_ahci_5v {
>  >>       status = "okay";
>  >>  };
>  >> +
>  >> +&usbphy {
>  >> +     pinctrl-names = "default";
>  >> +     pinctrl-0 = <&usb0_id_detect_pin>;
>  >> +     usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
>  >> +     status = "okay";
>  >> +};
>  >> diff --git a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
>  >> index 2565d51..d22eea3 100644
>  >> --- a/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
>  >> +++ b/arch/arm/boot/dts/sunxi-itead-core-common.dtsi
>  >> @@ -88,6 +88,10 @@
>  >>       status = "okay";
>  >>  };
>  >>
>  >> +&otg_sram {
>  >> +     status = "okay";
>  >> +};
>  >> +
>  >>  #include "axp209.dtsi"
>  >>
>  >>  &reg_dcdc2 {
>  >> @@ -129,6 +133,11 @@
>  >>       status = "okay";
>  >>  };
>  >>
>  >> +&usb_otg {
>  >> +     dr_mode = "otg";
>  >
>  > If VBUS is tied to 5V, without anyway to disable it, then it cannot do
>  > OTG.
>  >
>  > The mode it can do is host.
> This is the same patch as what was applied to cubieboard2 https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts?id=b8962f7ee700580a148e05eceb2302bcfc59ffbc which it looks like this hardware copies. I can power the Ibox using this USB socket and when I plug in a usb2ethernet device then it is detected.

Right, the otg port on the cubieboard can work in otg mode just fine, as long as either the
otg is the only power supply, or the 5v supplied to the power barrel comes from the same
source as the otg 5v. Note that only allowing host mode does not take away this limitation
as the 2 5v pins are hardwired together, so we might just as well offer otg support.

Regards,

Hans


From ddaney at caviumnetworks.com  Tue Feb  9 11:59:10 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Tue, 9 Feb 2016 11:59:10 -0800
Subject: [PATCH] arm64: Add workaround for Cavium erratum 27456
In-Reply-To: <20160209195222.0882d7f7@arm.com>
References: <1455046156-10582-1-git-send-email-ddaney.cavm@gmail.com>
 <20160209195222.0882d7f7@arm.com>
Message-ID: <56BA450E.50109@caviumnetworks.com>

On 02/09/2016 11:52 AM, Marc Zyngier wrote:
> On Tue,  9 Feb 2016 11:29:16 -0800
> David Daney <ddaney.cavm at gmail.com> wrote:
>
> Hi David,
>
>> From: Andrew Pinski <apinski at cavium.com>
>>
>> On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
>> instructions may cause the icache to become invalid if it contains
>> data for a non-current ASID.
>>
>> This patch implements the workaround (which flushes the local icache
>> when switching the mm) by using code patching.
>>
>> Signed-off-by: Andrew Pinski <apinski at cavium.com>
>> Signed-off-by: David Daney <david.daney at cavium.com>
>> ---
>>   arch/arm64/Kconfig                  | 11 +++++++++++
>>   arch/arm64/include/asm/cpufeature.h |  3 ++-
>>   arch/arm64/kernel/cpu_errata.c      |  9 +++++++++
>>   arch/arm64/mm/proc.S                | 12 ++++++++++++
>>   4 files changed, 34 insertions(+), 1 deletion(-)
>
> It would be good to update Documentation/arm64/silicon-errata.txt to
> reflect the fact that there is a workaround available for this erratum.

Would you prefer a separate patch for that, or should I roll it into 
this one and resubmit?

David Daney


>
> Thanks,
>
> 	M.
>



From marc.zyngier at arm.com  Tue Feb  9 12:07:15 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 9 Feb 2016 20:07:15 +0000
Subject: [PATCH] arm64: Add workaround for Cavium erratum 27456
In-Reply-To: <56BA450E.50109@caviumnetworks.com>
References: <1455046156-10582-1-git-send-email-ddaney.cavm@gmail.com>
 <20160209195222.0882d7f7@arm.com>
 <56BA450E.50109@caviumnetworks.com>
Message-ID: <20160209200715.22487785@arm.com>

On Tue, 9 Feb 2016 11:59:10 -0800
David Daney <ddaney at caviumnetworks.com> wrote:

> On 02/09/2016 11:52 AM, Marc Zyngier wrote:
> > On Tue,  9 Feb 2016 11:29:16 -0800
> > David Daney <ddaney.cavm at gmail.com> wrote:
> >
> > Hi David,
> >
> >> From: Andrew Pinski <apinski at cavium.com>
> >>
> >> On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
> >> instructions may cause the icache to become invalid if it contains
> >> data for a non-current ASID.
> >>
> >> This patch implements the workaround (which flushes the local icache
> >> when switching the mm) by using code patching.
> >>
> >> Signed-off-by: Andrew Pinski <apinski at cavium.com>
> >> Signed-off-by: David Daney <david.daney at cavium.com>
> >> ---
> >>   arch/arm64/Kconfig                  | 11 +++++++++++
> >>   arch/arm64/include/asm/cpufeature.h |  3 ++-
> >>   arch/arm64/kernel/cpu_errata.c      |  9 +++++++++
> >>   arch/arm64/mm/proc.S                | 12 ++++++++++++
> >>   4 files changed, 34 insertions(+), 1 deletion(-)
> >
> > It would be good to update Documentation/arm64/silicon-errata.txt to
> > reflect the fact that there is a workaround available for this erratum.
> 
> Would you prefer a separate patch for that, or should I roll it into 
> this one and resubmit?

It'd feel more logical to keep it all together, but I'll leave that
decision to Catalin and Will.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.


From Valdis.Kletnieks at vt.edu  Tue Feb  9 12:14:35 2016
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 09 Feb 2016 15:14:35 -0500
Subject: [PATCH v12 2/4] PM / Domains: add setter for dev.pm_domain
In-Reply-To: <CAJZ5v0jUipo06fpSQsKi+5Po_32ntgc3Ns29=17SgQr2PSj+kA@mail.gmail.com>
References: <1452181575-9206-1-git-send-email-tomeu.vizoso@collabora.com>
 <CAHp75VdWPUZ8F5rsGn3M1e5Pgpcg1CErBej9PE_3+ZPke5CDFA@mail.gmail.com>
 <CAHp75Vf9TS-AxJALQjiwNjMCT8ct5SBanYzrEsV9aj=DsUw-OA@mail.gmail.com>
 <1783906.XctYjeUNLr@vostro.rjw.lan>
 <44858.1454967873@turing-police.cc.vt.edu>
 <CAJZ5v0jUipo06fpSQsKi+5Po_32ntgc3Ns29=17SgQr2PSj+kA@mail.gmail.com>
Message-ID: <43751.1455048875@turing-police.cc.vt.edu>

On Mon, 08 Feb 2016 22:50:39 +0100, "Rafael J. Wysocki" said:
> On Mon, Feb 8, 2016 at 10:44 PM,  <Valdis.Kletnieks at vt.edu> wrote:

> > My Dell Latitude laptopi on next-20160201 is throwing a similar error
> > at shutdown, except the traceback continues:
> >
> > mei_me_remove+0xbd/0xc0
> > pci_device_shutdown+0x32/0x50
> > device_shutdown+0xe2/0x210
> >
> > (sorry, that's all I have, transcribing from one frame of video shot while
> > the system was shutting down....)
>
> This should be fixed in 4.5-rc3, so please retest.

Confirming that next-20160201 has the problem, but it is fixed as of next-20160208.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/21dddf40/attachment.sig>

From martin-langer at gmx.de  Tue Feb  9 12:17:44 2016
From: martin-langer at gmx.de (Martin Langer)
Date: Tue, 9 Feb 2016 21:17:44 +0100
Subject: EMXX platform support
Message-ID: <20160209201743.GA5628@reno.home>

Hello,

are there any plans in supporting emxx platform?

The Sony PCM D-100 is based on this platform and they released a lot of their linux code:
http://oss.sony.net/Products/Linux/Audio/PCM-D100.html

... including basic code for the kernel 2.6.35, see:
http://oss.sony.net/Products/Linux/Audio/Download/PCM-D100/linux-kernel-2.6.35.tgz

I'm wondering that it is not yet part of the kernel. Probably I am the first person who looked into their package.


Bye,
Martin


From ard.biesheuvel at linaro.org  Tue Feb  9 12:18:02 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 9 Feb 2016 21:18:02 +0100
Subject: [PATCH v4 3/3] kallsyms: remove --page-offset command line option
In-Reply-To: <alpine.LFD.2.20.1602091407380.17825@knanqh.ubzr>
References: <1455030828-6416-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455030828-6416-4-git-send-email-ard.biesheuvel@linaro.org>
 <HKXPR06MB056549C714A864B2D4F37DCA8AD60@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu-rdP7-=Z2SO2jRS_dHzB8UDpZ7-RowN_400d32Qvxmqg@mail.gmail.com>
 <alpine.LFD.2.20.1602091407380.17825@knanqh.ubzr>
Message-ID: <CAKv+Gu_7c2uKzj=tz4fSgX37C8aqNNnWKfXk-9kzAi5g=V+Vgw@mail.gmail.com>

On 9 February 2016 at 20:28, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> On Tue, 9 Feb 2016, Ard Biesheuvel wrote:
>
>> On 9 February 2016 at 17:09, Chris Brandt <Chris.Brandt at renesas.com> wrote:
>> > On 9 Feb 2016, Ard Biesheuvel wrote:
>> >
>> >>diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
>> >>index 02473b71643b..32c8d43590af 100644
>> >>--- a/scripts/kallsyms.c
>> >>+++ b/scripts/kallsyms.c
>> >>@@ -63,7 +63,6 @@ static unsigned int table_size, table_cnt;
>> >> static int all_symbols = 0;
>> >> static int absolute_percpu = 0;
>> >> static char symbol_prefix_char = '\0';
>> >>-static unsigned long long kernel_start_addr = 0;
>> >> static int base_relative = 0;
>> >
>> >
>> >
>> > You removed kernel_start_addr, but you didn't remove all the instances of it in the file (you did remove them all in V2 though).
>> >
>> > So, now I get:
>> >
>> >   CC      scripts/mod/devicetable-offsets.s
>> > ../scripts/kallsyms.c: In function 'record_relative_base':
>> > ../scripts/kallsyms.c:740:6: error: 'kernel_start_addr' undeclared (first use in this function)
>> >   if (kernel_start_addr > 0) {
>> >       ^
>> > ../scripts/kallsyms.c:740:6: note: each undeclared identifier is reported only once for each function it appears in
>> > make[2]: *** [scripts/kallsyms] Error 1
>> >
>>
>> That is because this patch
>>
>> http://ozlabs.org/~akpm/mmots/broken-out/kallsyms-add-support-for-relative-offsets-in-kallsyms-address-table-v5.patch
>>
>> is also in flight, via akpm's tree, and is expected to hit -next
>> tomorrow. That patch removes this reference (or alternatively, will
>> not introduce it anymore if akpm decides to fold it into
>> http://ozlabs.org/~akpm/mmots/broken-out/kallsyms-add-support-for-relative-offsets-in-kallsyms-address-table.patch
>> before submitting it)
>>
>> Going forward, it probably makes sense to only submit #1 of this
>> series for v4.6, and queue the remaining two after the merge window.
>
> Well... If akpm agrees, you could get those patches back and create a
> tree of your own with all ACKs for this work to avoi all this patch
> ordering dependency nightmare (including the work that depends on this)
> and submit it upstream (to Linus maybe?) while having it merged in
> linux-next in the mean time.
>

All these changes are related to my KASLR series for arm64 in one way
or the other, some of which is en route via akpm's tree (including the
generic kallsyms changes that these patches are based on) and some via
Catalin's tree. If Russell is ok to take this #1 for v4.6, I am happy
to sit on the remaining two for a while (which essentially only remove
dead code once #1 is applied)

Thanks,
Ard.


From info at lategoodbye.de  Tue Feb  9 12:21:15 2016
From: info at lategoodbye.de (Stefan Wahren)
Date: Tue, 9 Feb 2016 21:21:15 +0100
Subject: [PATCH 4/4] spi: bcm2835aux: fix CPOL/CPHA setting
In-Reply-To: <1455041435-8015-5-git-send-email-stephanolbrich@gmx.de>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <1455041435-8015-5-git-send-email-stephanolbrich@gmx.de>
Message-ID: <56BA4A3B.3090605@lategoodbye.de>

Hi Stephan,

Am 09.02.2016 um 19:10 schrieb stephanolbrich at gmx.de:
> From: Stephan Olbrich <stephanolbrich at gmx.de>
>
> The auxiliary spi supports only CPHA=0 modes as the first bit is
> always output to the pin before the first clock cycle. In CPHA=1
> modes the first clock edge outputs the second bit hence the slave
> can never read the first bit.

in case auxiliary spi isn't able to handle all modes shouldn't we report 
this to the upper layers?

Regards


From d-gerlach at ti.com  Tue Feb  9 12:19:32 2016
From: d-gerlach at ti.com (Dave Gerlach)
Date: Tue, 9 Feb 2016 14:19:32 -0600
Subject: [PATCH 0/3] omap: hwmod: add default reset handling support
In-Reply-To: <56BA258D.3040002@ti.com>
References: <1454929941-23949-1-git-send-email-kishon@ti.com>
 <56B9037C.2050203@ti.com> <56B9767D.7000708@ti.com> <56BA258D.3040002@ti.com>
Message-ID: <56BA49D4.8040900@ti.com>

Hi,
On 02/09/2016 11:44 AM, Suman Anna wrote:
> On 02/08/2016 11:17 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Tuesday 09 February 2016 02:37 AM, Suman Anna wrote:
>>> On 02/08/2016 05:12 AM, Kishon Vijay Abraham I wrote:
>>>> Add a new hwmod flag to indicate custom reset handling and use it
>>>> for devices that require custom reset handling (like dsp, ipu, iva).
>>>>
>>>> Tested PCIe on dra7-evm and dra72-evm.
>>>> I need help in testing DSP, IPU, IVA, PRU, GFX, M3 in other platforms.
>>>> Or a way to test these cores to see if reset is not broken. Suman?
>>>
>>> I won't be able to test this week, and have requested Dave to check on
>>> wkup_m3_rproc driver atleast. I see one potential issue (see my commment
>>> on the other thread), but can confirm that only after testing.
>>>
>>> Have you tested multiple probe/removal sequences? Can you check the
>>> return status on the _hardreset_deassert call with your PCIe driver,
>>> believe even that one would return an error on multiple probes.
>>
>> hmm.. the PCIe driver is built-in and can't be made as module because of other
>> issues in PCIe core. But looks like the first deassert succeeded since I didn't
>> observe the boot hang because of PCIe.
>
> You can try unbind and bind through sysfs, it should result in a remove
> and probe even if your driver is built-in.

Sorry got held up by the discussion here [1], that regression affects 
rmmod/re-insmod of wkup_m3_rproc as well. If I revert the guilty patch 
5de85b9d57ab ("PM / runtime: Re-init runtime
PM states at probe error and driver unbind") and apply these three 
patches, on initial probe of the wkup_m3_rproc and wkup_m3_ipc drivers 
in v4.5-rc3 I see:

[   15.593460] omap_hwmod: wkup_m3: _wait_target_disable failed

Which is triggered by the reset of the wkup_m3 from the wkup_m3_ipc 
driver when booting the wkup_m3_rproc. Flow is:

1. wkup_m3_rproc probes and calls pm_runtime_get_sync, which calls hwmod 
_enable but bails out because _are_all_hardreset_lines_asserted(oh) 
causes it to return 0.

2. wkup_m3_ipc probes and calls rproc_boot, which triggers 
omap_device_deassert_hardreset in order to let the wkup_m3 start.

It is inside the omap_device_deassert_hardreset ( and inside that, 
omap_hwmod_deassert_hardreset) where I end up with the error message, 
but after that rmmod/insmod of the module over and over again shows no 
additional error messages (at least with the above mentioned PM patch 
reverted).

Regards,
Dave

[1] http://www.spinics.net/lists/arm-kernel/msg477160.html

>
> regards
> Suman
>>>
>>>>
>>>> I'll post this series once again after performing these tests.
>>>>
>>>> Paul Walmsley (3):
>>>>    ARM: omap2+: omap_hwmod: introduce hwmod flag for custom reset
>>>>      handling
>>>>    ARM: OMAP2+: hwmod: use HWMOD_CUSTOM_HARDRESET for custom reset
>>>>      handling
>>>>    ARM: OMAP2+: hwmod: Add default reset handling
>>>>
>>>>   arch/arm/mach-omap2/omap_hwmod.c                   |   16 +++++++++++-----
>>>>   arch/arm/mach-omap2/omap_hwmod.h                   |   12 ++++++++++++
>>>>   arch/arm/mach-omap2/omap_hwmod_2420_data.c         |    2 ++
>>>>   arch/arm/mach-omap2/omap_hwmod_2430_data.c         |    1 +
>>>>   .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    2 ++
>>>>   arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    1 +
>>>>   arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    3 +++
>>>>   arch/arm/mach-omap2/omap_hwmod_43xx_data.c         |    1 +
>>>>   arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    6 ++++++
>>>>   arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    2 ++
>>>>   10 files changed, 41 insertions(+), 5 deletions(-)
>>>>
>>>
>



From robert.jarzmik at free.fr  Tue Feb  9 12:22:08 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Tue, 09 Feb 2016 21:22:08 +0100
Subject: [PATCH] dmaengine: pxa_dma: fix the maximum requestor line
In-Reply-To: <20160209152007.GQ19598@localhost> (Vinod Koul's message of "Tue, 
 9 Feb 2016 20:50:07 +0530")
References: <1454941131-12308-1-git-send-email-robert.jarzmik@free.fr>
 <20160209033646.GK19598@localhost> <878u2u2vve.fsf@belgarion.home>
 <20160209152007.GQ19598@localhost>
Message-ID: <874mdh3a8f.fsf@belgarion.home>

Vinod Koul <vinod.koul at intel.com> writes:

> On Tue, Feb 09, 2016 at 08:20:05AM +0100, Robert Jarzmik wrote:
>> Vinod Koul <vinod.koul at intel.com> writes:
>> 
>> > On Mon, Feb 08, 2016 at 03:18:51PM +0100, Robert Jarzmik wrote:
>> >> The current number of requestor lines is limited to 31. This was an
>> >> error of a previous commit, as this number is platform dependent, and is
>> >> actually :
>> >>  - for pxa25x: 40 requestor lines
>> >>  - for pxa27x: 74 requestor lines
>> >>  - for pxa3xx: 100 requestor lines
>> >> 
>> >> As the driver doesn't need to know the exact number, but only an
>> >
>> > and why would that be a good assumption?
>> Well, the driver doesn't use the exact value. Would that be 128, 1000 or 10000,
>> it wouldn't change its behavior. The clients either pass -1UL (ie. no flow
>> control) or a requestor line number.
>
> Somehow that does not sound right to me. You seem to have no way of knowing
> what is the actual max request line for a platforms. What if on pxa25x user
> requests more than 40 lines?
>
>> > Btw shouldn't this data come from DT?
>> It can if you wish, but in this case I must amend the platform data case too, ie
>> mmp_dma_platdata. And this has an impact on MMP architecture. I'd rather have
>> the simpler approach unless you really want the exact number of requestor lines
>> to be passed in platform_data+DT.
>
> The information that you have X lines on a platform needs to be described
> and queried. I see current approach error prone

Actually I have thought over your point, and you're quite right (this is your
case of more than 40 lines).

The exception I have found is :
 - a device driver is wrongly written
 - it requests the requestor line 0x1000 (below 0x8000)
 - pxa_dma computes the register in pxad_drcmr(0x1000)
   => this gives : base + 0x1000 + 4 * 0x1000 = base + 0x5000
   => this is a not existing iomapped register

So yes, I will respin the patchset, with :
 - one patch adding the number of requestors in mmp_dma.h
 - one patch adding the number of requestors in devicetree description
 - one patch adding the number of requestors in arch/arm/mach-pxa (my tree)
 - one patch adding the use of number of requestors in pxa_dma.c

Cheers.

-- 
Robert


From sergei.shtylyov at cogentembedded.com  Tue Feb  9 12:25:33 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Tue, 9 Feb 2016 23:25:33 +0300
Subject: [PATCH 5/5] ARM: dts: r8a7794 add sound support
In-Reply-To: <20160209195054.GA14008@verge.net.au>
References: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>
 <2179456.HznTXDfKhZ@wasted.cogentembedded.com>
 <20160209195054.GA14008@verge.net.au>
Message-ID: <56BA4B3D.1030301@cogentembedded.com>

Hello.

On 02/09/2016 10:50 PM, Simon Horman wrote:

>> Define the generic R8A7794 part of  the sound device node.
>> This sound device  is a complex one and comprises the Audio Clock Generator
>> (ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
>> (SSI[U]), and Audio DMAC-Peripheral-Peripheral.
>> It is up  to the board file to enable the device.
>>
>> This patch is based on the R8A7791 sound work by Kuninori Morimoto.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>>
>> ---
>>   arch/arm/boot/dts/r8a7794.dtsi |  171 +++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 171 insertions(+)
>>
>> Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
>> ===================================================================
>> --- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
>> +++ renesas/arch/arm/boot/dts/r8a7794.dtsi
>> @@ -1309,4 +1309,175 @@
>>   		#iommu-cells = <1>;
>>   		status = "disabled";
>>   	};
>> +
>> +	rcar_sound: sound at ec500000 {
>> +		/*
>> +		 * #sound-dai-cells is required
>> +		 *
>> +		 * Single DAI : #sound-dai-cells = <0>;         <&rcar_sound>;
>> +		 * Multi  DAI : #sound-dai-cells = <1>;         <&rcar_sound N>;
>> +		 */
>> +		compatible = "renesas,rcar_sound-r8a7794",
>> +			     "renesas,rcar_sound-gen2";
>> +		reg =	<0 0xec500000 0 0x1000>, /* SCU */
>> +			<0 0xec5a0000 0 0x100>,  /* ADG */
>> +			<0 0xec540000 0 0x1000>, /* SSIU */
>> +			<0 0xec541000 0 0x280>,  /* SSI */
>> +			<0 0xec740000 0 0x200>;  /* Audio DMAC peri peri */
>> +		reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
>> +
>> +		clocks = <&mstp10_clks R8A7794_CLK_SSI_ALL>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI9>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI8>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI7>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI6>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI5>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI4>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI3>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI2>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI1>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI0>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC9>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC8>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC7>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC6>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC5>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC4>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC3>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC2>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC1>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC0>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_DVC0>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_DVC1>,
>> +			 <&audio_clka>, <&audio_clkb>, <&audio_clkc>,
>> +			 <&m2_clk>;
>> +		clock-names = "ssi-all",
>> +			      "ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
>> +			      "ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0",
>> +			      "src.9", "src.8", "src.7", "src.6", "src.5",
>> +			      "src.4", "src.3", "src.2", "src.1", "src.0",
>> +			      "clk_a", "clk_b", "clk_c", "clk_i";
>> +		power-domains = <&cpg_clocks>;
>> +
>> +		status = "disabled";
>> +		rcar_sound,src {
>> +			src0: src at 0 {
>> +				interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x85>, <&audma0 0x9a>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +			src1: src at 1 {
>> +				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x87>, <&audma0 0x9c>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +			src2: src at 2 {
>> +				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x89>, <&audma0 0x9e>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +			src3: src at 3 {
>> +				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +			src4: src at 4 {
>> +				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +			src5: src at 5 {
>> +				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +			src6: src at 6 {
>> +				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x91>, <&audma0 0xb4>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +			src7: src at 7 {
>> +				interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x93>, <&audma0 0xb6>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +			src8: src at 8 {
>> +				interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x95>, <&audma0 0xb8>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +			src9: src at 9 {
>> +				interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x97>, <&audma0 0xba>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +		};

> My reading of the documentation is that src0, 7, 8 and 9 are not
> present on the r8a7794. I am referring to Figure 38.1b or r1.02 of
> the R-Car Gen2 User's Manual.

    Indeed, thank you for the timely comment (I'm working on the series 
respin)! However, table 7A.12 still lists the SRC0/7/8/9 clocks for R8A7794, 
table 11.1 still lists SRC0/7/8/9 interrupts for R8A7794, and table 43.4 still 
lists SRC0/7/8/9 MID+RID for R8A7794 -- go figure...

> [snip]

MBR, Sergei



From dannym at scratchpost.org  Tue Feb  9 12:33:21 2016
From: dannym at scratchpost.org (Danny Milosavljevic)
Date: Tue, 9 Feb 2016 21:33:21 +0100
Subject: [linux-sunxi] Re: [PATCH 11/11] arm64: dts: add Pine64 support
In-Reply-To: <CAGRGNgWTMVYExfWZceoY2UKVYq=3g6EnhYBqt9GOFk0Yh6j+4g@mail.gmail.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-12-git-send-email-andre.przywara@arm.com>
 <20160205090337.GB1139@lukather> <56B47391.1040709@arm.com>
 <CAGRGNgWTMVYExfWZceoY2UKVYq=3g6EnhYBqt9GOFk0Yh6j+4g@mail.gmail.com>
Message-ID: <20160209213321.7ab6beba@scratchpost.org>

Hi,

On Mon, 8 Feb 2016 11:55:43 +1100
Julian Calaby <julian.calaby at gmail.com> wrote:

> I believe that device tree overlays are the generally recommended method.

I agree. But last time I tried, the device tree compiler didn't 
support overlays - neither in Debian nor in the in-kernel dtc ("-@" is 
unsupported; last tried with linux-4.3-rc7). 

And even if you could compile them, the platform has to support specifying which 
overlays to use in the first place (for example as a Linux cmdline option). 

For example Beaglebone Black (TI Sitara) does. I don't know whether sunxi does.

Also, the overlay dts files are very different from normal dts files, see 
<http://www.patternagents.com/news/2015/01/29/devicetree-overlays.html>.

The original Linux device tree changeset patchset also introduced an in-kernel 
interface for loading/unloading of DT overlays at runtime. AFAIK, this is still 
not available to user space.

More info at <https://lwn.net/Articles/616859/>.

(I tried some 4 months ago - it wasn't integrated enough. 
 So now I just patch the main dts every time - which I probably shouldn't)

Regards,
   Danny


From christoffer.dall at linaro.org  Tue Feb  9 12:38:03 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 21:38:03 +0100
Subject: [RFC PATCH 0/5] arm/arm64: Making HYP vgic/timer save/restore
 common
In-Reply-To: <1453996565-19666-1-git-send-email-marc.zyngier@arm.com>
References: <1453996565-19666-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209203803.GD5171@cbox>

On Thu, Jan 28, 2016 at 03:56:00PM +0000, Marc Zyngier wrote:
> With the current state of the C conversion of arm and arm64 world
> switches, we are still unable to share some of the most obvious
> candidates (GIC and timer save/restore). In order to reduce the bloat,
> let's move these files to a common location (virt/kvm/arm/hyp).
> 
> The changes are extremely mechanical, with a small hack to deal with
> system register names on the 32bit side (I've decided to align on the
> 64bit names).
> 
> I'd like to know what people think of the common location. Does it
> makes sense to have a "hyp" subdirectory to indicate that this is not
> "normal" kernel code?
> 
> These patches are on top of 4.5-rc1, plus the VHE and 32bit WS rewrite
> patches, and I've pushed out a branch at
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/mov-hyp
> 

ack on this series, tested on TC2 and Mustang as well.

-Christoffer


From nicolas.pitre at linaro.org  Tue Feb  9 12:45:40 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 9 Feb 2016 15:45:40 -0500 (EST)
Subject: [PATCH v4 3/3] kallsyms: remove --page-offset command line option
In-Reply-To: <CAKv+Gu_7c2uKzj=tz4fSgX37C8aqNNnWKfXk-9kzAi5g=V+Vgw@mail.gmail.com>
References: <1455030828-6416-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455030828-6416-4-git-send-email-ard.biesheuvel@linaro.org>
 <HKXPR06MB056549C714A864B2D4F37DCA8AD60@HKXPR06MB0565.apcprd06.prod.outlook.com>
 <CAKv+Gu-rdP7-=Z2SO2jRS_dHzB8UDpZ7-RowN_400d32Qvxmqg@mail.gmail.com>
 <alpine.LFD.2.20.1602091407380.17825@knanqh.ubzr>
 <CAKv+Gu_7c2uKzj=tz4fSgX37C8aqNNnWKfXk-9kzAi5g=V+Vgw@mail.gmail.com>
Message-ID: <alpine.LFD.2.20.1602091545170.17825@knanqh.ubzr>

On Tue, 9 Feb 2016, Ard Biesheuvel wrote:

> On 9 February 2016 at 20:28, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> > On Tue, 9 Feb 2016, Ard Biesheuvel wrote:
> >
> >> On 9 February 2016 at 17:09, Chris Brandt <Chris.Brandt at renesas.com> wrote:
> >> > On 9 Feb 2016, Ard Biesheuvel wrote:
> >> >
> >> >>diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
> >> >>index 02473b71643b..32c8d43590af 100644
> >> >>--- a/scripts/kallsyms.c
> >> >>+++ b/scripts/kallsyms.c
> >> >>@@ -63,7 +63,6 @@ static unsigned int table_size, table_cnt;
> >> >> static int all_symbols = 0;
> >> >> static int absolute_percpu = 0;
> >> >> static char symbol_prefix_char = '\0';
> >> >>-static unsigned long long kernel_start_addr = 0;
> >> >> static int base_relative = 0;
> >> >
> >> >
> >> >
> >> > You removed kernel_start_addr, but you didn't remove all the instances of it in the file (you did remove them all in V2 though).
> >> >
> >> > So, now I get:
> >> >
> >> >   CC      scripts/mod/devicetable-offsets.s
> >> > ../scripts/kallsyms.c: In function 'record_relative_base':
> >> > ../scripts/kallsyms.c:740:6: error: 'kernel_start_addr' undeclared (first use in this function)
> >> >   if (kernel_start_addr > 0) {
> >> >       ^
> >> > ../scripts/kallsyms.c:740:6: note: each undeclared identifier is reported only once for each function it appears in
> >> > make[2]: *** [scripts/kallsyms] Error 1
> >> >
> >>
> >> That is because this patch
> >>
> >> http://ozlabs.org/~akpm/mmots/broken-out/kallsyms-add-support-for-relative-offsets-in-kallsyms-address-table-v5.patch
> >>
> >> is also in flight, via akpm's tree, and is expected to hit -next
> >> tomorrow. That patch removes this reference (or alternatively, will
> >> not introduce it anymore if akpm decides to fold it into
> >> http://ozlabs.org/~akpm/mmots/broken-out/kallsyms-add-support-for-relative-offsets-in-kallsyms-address-table.patch
> >> before submitting it)
> >>
> >> Going forward, it probably makes sense to only submit #1 of this
> >> series for v4.6, and queue the remaining two after the merge window.
> >
> > Well... If akpm agrees, you could get those patches back and create a
> > tree of your own with all ACKs for this work to avoi all this patch
> > ordering dependency nightmare (including the work that depends on this)
> > and submit it upstream (to Linus maybe?) while having it merged in
> > linux-next in the mean time.
> >
> 
> All these changes are related to my KASLR series for arm64 in one way
> or the other, some of which is en route via akpm's tree (including the
> generic kallsyms changes that these patches are based on) and some via
> Catalin's tree. If Russell is ok to take this #1 for v4.6, I am happy
> to sit on the remaining two for a while (which essentially only remove
> dead code once #1 is applied)

OK makes sense.


Nicolas


From christoffer.dall at linaro.org  Tue Feb  9 12:49:14 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 21:49:14 +0100
Subject: [PATCH 3/5] irqchip/gic-v2: Parse and export virtual GIC
 information
In-Reply-To: <1454950049-741-4-git-send-email-julien.grall@arm.com>
References: <1454950049-741-1-git-send-email-julien.grall@arm.com>
 <1454950049-741-4-git-send-email-julien.grall@arm.com>
Message-ID: <20160209204914.GE5171@cbox>

On Mon, Feb 08, 2016 at 04:47:27PM +0000, Julien Grall wrote:
> For now, the firmware tables are parsed 2 times: once in the GIC
> drivers, the other timer when initializing the vGIC. It means code
> duplication and make more tedious to add the support for another
> firmware table (like ACPI).
> 
> Introduce a new structure and set of helpers to get/set the virtual GIC
> information. Also fill up the structure for GICv2.
> 
> Signed-off-by: Julien Grall <julien.grall at arm.com>
> ---
> 
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Jason Cooper <jason at lakedaemon.net>
> Cc: Marc Zyngier <marc.zyngier at arm.com>
> 
>  drivers/irqchip/irq-gic-common.c       | 13 ++++++
>  drivers/irqchip/irq-gic-common.h       |  3 ++
>  drivers/irqchip/irq-gic.c              | 78 +++++++++++++++++++++++++++++++++-
>  include/linux/irqchip/arm-gic-common.h | 34 +++++++++++++++
>  4 files changed, 127 insertions(+), 1 deletion(-)
>  create mode 100644 include/linux/irqchip/arm-gic-common.h
> 
> diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
> index f174ce0..704caf4 100644
> --- a/drivers/irqchip/irq-gic-common.c
> +++ b/drivers/irqchip/irq-gic-common.c
> @@ -21,6 +21,19 @@
>  
>  #include "irq-gic-common.h"
>  
> +static const struct gic_kvm_info *gic_kvm_info;
> +
> +const struct gic_kvm_info *gic_get_kvm_info(void)
> +{
> +	return gic_kvm_info;
> +}
> +
> +void gic_set_kvm_info(const struct gic_kvm_info *info)
> +{
> +	WARN(gic_kvm_info != NULL, "gic_kvm_info already set\n");
> +	gic_kvm_info = info;
> +}
> +
>  void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
>  		void *data)
>  {
> diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
> index fff697d..205e5fd 100644
> --- a/drivers/irqchip/irq-gic-common.h
> +++ b/drivers/irqchip/irq-gic-common.h
> @@ -19,6 +19,7 @@
>  
>  #include <linux/of.h>
>  #include <linux/irqdomain.h>
> +#include <linux/irqchip/arm-gic-common.h>
>  
>  struct gic_quirk {
>  	const char *desc;
> @@ -35,4 +36,6 @@ void gic_cpu_config(void __iomem *base, void (*sync_access)(void));
>  void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
>  		void *data);
>  
> +void gic_set_kvm_info(const struct gic_kvm_info *info);
> +
>  #endif /* _IRQ_GIC_COMMON_H */
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 911758c..d3a09a4 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -102,6 +102,8 @@ static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;
>  
>  static struct gic_chip_data gic_data[CONFIG_ARM_GIC_MAX_NR] __read_mostly;
>  
> +static struct gic_kvm_info gic_v2_kvm_info;
> +
>  #ifdef CONFIG_GIC_NON_BANKED
>  static void __iomem *gic_get_percpu_base(union gic_base *base)
>  {
> @@ -1190,6 +1192,44 @@ static bool gic_check_eoimode(struct device_node *node, void __iomem **base)
>  	return true;
>  }
>  
> +static void __init gic_of_setup_kvm_info(struct device_node *node)
> +{
> +	int ret;
> +	struct resource r;
> +	unsigned int irq;
> +
> +	gic_v2_kvm_info.type = GIC_V2;
> +
> +	irq = irq_of_parse_and_map(node, 0);
> +	if (!irq)
> +		gic_v2_kvm_info.maint_irq = -1;
> +	else
> +		gic_v2_kvm_info.maint_irq = irq;
> +
> +	ret = of_address_to_resource(node, 2, &r);
> +	if (!ret) {
> +		gic_v2_kvm_info.vctrl_base = r.start;
> +		gic_v2_kvm_info.vctrl_size = resource_size(&r);
> +	}
> +
> +	ret = of_address_to_resource(node, 3, &r);
> +	if (!ret) {
> +		if (!PAGE_ALIGNED(r.start))
> +			pr_warn("GICV physical address 0x%llx not page aligned\n",
> +				(unsigned long long)r.start);
> +		else if (!PAGE_ALIGNED(resource_size(&r)))
> +			pr_warn("GICV size 0x%llx not a multiple of page size 0x%lx\n",
> +				(unsigned long long)resource_size(&r),
> +				PAGE_SIZE);
> +		else {
> +			gic_v2_kvm_info.vcpu_base = r.start;
> +			gic_v2_kvm_info.vcpu_size = resource_size(&r);
> +		}
> +	}
> +
> +	gic_set_kvm_info(&gic_v2_kvm_info);
> +}
> +
>  int __init
>  gic_of_init(struct device_node *node, struct device_node *parent)
>  {
> @@ -1219,8 +1259,10 @@ gic_of_init(struct device_node *node, struct device_node *parent)
>  
>  	__gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset,
>  			 &node->fwnode);
> -	if (!gic_cnt)
> +	if (!gic_cnt) {
>  		gic_init_physaddr(node);
> +		gic_of_setup_kvm_info(node);
> +	}
>  
>  	if (parent) {
>  		irq = irq_of_parse_and_map(node, 0);
> @@ -1247,6 +1289,32 @@ IRQCHIP_DECLARE(pl390, "arm,pl390", gic_of_init);
>  
>  #ifdef CONFIG_ACPI
>  static phys_addr_t cpu_phy_base __initdata;
> +static struct
> +{
> +	u32 maint_irq;
> +	int maint_irq_mode;
> +	phys_addr_t vctrl_base;
> +	phys_addr_t vcpu_base;
> +} acpi_data __initdata;
> +
> +static void __init gic_acpi_setup_kvm_info(void)
> +{
> +	gic_v2_kvm_info.type = GIC_V2;
> +
> +	gic_v2_kvm_info.maint_irq = acpi_register_gsi(NULL,
> +						      acpi_data.maint_irq,
> +						      acpi_data.maint_irq_mode,
> +						      ACPI_ACTIVE_HIGH);
> +	gic_v2_kvm_info.vctrl_base = acpi_data.vctrl_base;
> +	if (gic_v2_kvm_info.vctrl_base)
> +		gic_v2_kvm_info.vctrl_size = SZ_8K;
> +
> +	gic_v2_kvm_info.vcpu_base = acpi_data.vcpu_base;
> +	if (gic_v2_kvm_info.vcpu_base)
> +		gic_v2_kvm_info.vcpu_size = SZ_8K;

why are the sizes hard-coded to 8K in this case?

Thanks,
-Christoffer


From dave.long at linaro.org  Tue Feb  9 12:53:39 2016
From: dave.long at linaro.org (David Long)
Date: Tue, 9 Feb 2016 15:53:39 -0500
Subject: [PATCH v3 0/2] Consolidate redundant register/stack access code
In-Reply-To: <1455010600.13384.3.camel@ellerman.id.au>
References: <1454996337-7935-1-git-send-email-dave.long@linaro.org>
 <1455010600.13384.3.camel@ellerman.id.au>
Message-ID: <56BA51D3.9030204@linaro.org>

On 02/09/2016 04:36 AM, Michael Ellerman wrote:
> On Tue, 2016-02-09 at 00:38 -0500, David Long wrote:
>
>> From: "David A. Long" <dave.long at linaro.org>
>>
>> Move duplicate and functionally equivalent code for accessing registers
>> and stack (CONFIG_HAVE_REGS_AND_STACK_ACCESS_API) from arch subdirs into
>> common kernel files.
>>
>> I'm sending this out again (with updated distribution list) because v2
>> just never got pulled in, even though I don't think there were any
>> outstanding issues.
>
> A big cross arch patch like this would often get taken by Andrew Morton, but
> AFAICS you didn't CC him - so I just added him, perhaps he'll pick it up for
> us :D
>
> cheers
>

Thanks much.

-dl



From dave.long at linaro.org  Tue Feb  9 12:55:02 2016
From: dave.long at linaro.org (David Long)
Date: Tue, 9 Feb 2016 15:55:02 -0500
Subject: [PATCH v3 0/2] Consolidate redundant register/stack access code
In-Reply-To: <20160209094526.GB25268@gmail.com>
References: <1454996337-7935-1-git-send-email-dave.long@linaro.org>
 <1455010600.13384.3.camel@ellerman.id.au> <20160209094526.GB25268@gmail.com>
Message-ID: <56BA5226.3090105@linaro.org>

On 02/09/2016 04:45 AM, Ingo Molnar wrote:
>
> * Michael Ellerman <mpe at ellerman.id.au> wrote:
>
>> On Tue, 2016-02-09 at 00:38 -0500, David Long wrote:
>>
>>> From: "David A. Long" <dave.long at linaro.org>
>>>
>>> Move duplicate and functionally equivalent code for accessing registers
>>> and stack (CONFIG_HAVE_REGS_AND_STACK_ACCESS_API) from arch subdirs into
>>> common kernel files.
>>>
>>> I'm sending this out again (with updated distribution list) because v2
>>> just never got pulled in, even though I don't think there were any
>>> outstanding issues.
>>
>> A big cross arch patch like this would often get taken by Andrew Morton, but
>> AFAICS you didn't CC him - so I just added him, perhaps he'll pick it up for
>> us :D
>
> The other problem is that the second patch is commingling changes to 6 separate
> architectures:
>
>   16 files changed, 106 insertions(+), 343 deletions(-)
>
> that should probably be 6 separate patches. Easier to review, easier to bisect to,
> easier to revert, etc.
>
> Thanks,
>
> 	Ingo
>

I see your point but I'm not sure it could have been broken into 
separate successive patches that would each build for all architectures.

-dl



From christoffer.dall at linaro.org  Tue Feb  9 12:59:19 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Tue, 9 Feb 2016 21:59:19 +0100
Subject: [PATCH 0/8] KVM/ARM: Guest Entry/Exit optimizations
In-Reply-To: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160209205919.GF5171@cbox>

On Mon, Feb 08, 2016 at 11:40:14AM +0000, Marc Zyngier wrote:
> I've recently been looking at our entry/exit costs, and profiling
> figures did show some very low hanging fruits.
> 
> The most obvious cost is that accessing the GIC HW is slow. As in
> "deadly slow", specially when GICv2 is involved. So not hammering the
> HW when there is nothing to write is immediately beneficial, as this
> is the most common cases (whatever people seem to think, interrupts
> are a *rare* event).
> 
> Another easy thing to fix is the way we handle trapped system
> registers. We do insist on (mostly) sorting them, but we do perform a
> linear search on trap. We can switch to a binary search for free, and
> get immediate benefits (the PMU code, being extremely trap-happy,
> benefits immediately from this).
> 
> With these in place, I see an improvement of 20 to 30% (depending on
> the platform) on our world-switch cycle count when running a set of
> hand-crafted guests that are designed to only perform traps.

I'm curious about the weight of these two?  My guess based on the
measurement work I did is that the GIC is by far the worst sinner, but
that was exacerbated on X-Gene compared to Seattle.

> 
> Methodology:
> 
> * NULL-hypercall guest: Perform 65536 PSCI_0_2_FN_PSCI_VERSION calls,
> and then a power-off:
> 
> __start:
> 	mov	x19, #(1 << 16)
> 1:	mov	x0, #0x84000000
> 	hvc	#0
> 	sub	x19, x19, #1
> 	cbnz	x19, 1b
> 	mov	x0, #0x84000000
> 	add	x0, x0, #9
> 	hvc	#0
> 	b	.
> 
> * sysreg trap guest: Perform 2^20 PMSELR_EL0 accesses, and power-off:
> 
> __start:
> 	mov	x19, #(1 << 20)
> 1:	mrs	x0, PMSELR_EL0
> 	sub	x19, x19, #1
> 	cbnz	x19, 1b
> 	mov	x0, #0x84000000
> 	add	x0, x0, #9
> 	hvc	#0
> 	b	.
> 
> * These guests are profiled using perf and kvmtool:
> 
> taskset -c 1 perf stat -e cycles:kh lkvm run -c1 --kernel do_sysreg.bin 2>&1 >/dev/null| grep cycles

these would be good to add to kvm-unit-tests so we can keep an eye on
this sort of thing...


> 
> The result is then divided by the number of iterations (2^16 or 2^20).
> 
> These tests have been run on Seattle, Mustang, and LS2085, and shown
> significant improvements in all cases. I've only touched the arm64
> GIC code, but obviously the 32bit code should use it as well once
> we've migrated it to C.
> 
> I've pushed out a branch (kvm-arm64/suck-less) to the usual location.
> 

Looks promising!

-Christoffer


From okaya at codeaurora.org  Tue Feb  9 13:01:16 2016
From: okaya at codeaurora.org (Sinan Kaya)
Date: Tue, 9 Feb 2016 16:01:16 -0500
Subject: [PATCH V13 08/10] dma: qcom_hidma: read the channel id from HW
In-Reply-To: <56B75CF8.9070709@codeaurora.org>
References: <1454106914-15857-1-git-send-email-okaya@codeaurora.org>
 <1454106914-15857-9-git-send-email-okaya@codeaurora.org>
 <20160201153542.GA20396@leverpostej> <56B247A1.20503@codeaurora.org>
 <20160203183650.GI1234@leverpostej> <56B75CF8.9070709@codeaurora.org>
Message-ID: <56BA539C.4030403@codeaurora.org>

On 2/7/2016 10:04 AM, Sinan Kaya wrote:
> Hi Mark,
> 
> On 2/3/2016 1:36 PM, Mark Rutland wrote:
>> > Sorry, but it's going to be far easier to review with useless code
>> > removed, so I will wait until the next posting where this patch is
>> > folded in.
> V14 of the patch have been posted on the mail-list where this patch has
> been folder into the existing code. 
> 
> https://lkml.org/lkml/2016/2/4/1086
> 
> I have also captured the information you previously asked into the cover 
> letter as you asked.
> 
> I'm looking forward to hear your other comments.
> Sinan

ping

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project


From ddaney.cavm at gmail.com  Tue Feb  9 13:16:39 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Tue,  9 Feb 2016 13:16:39 -0800
Subject: [PATCH v2] arm64: Add workaround for Cavium erratum 27456
Message-ID: <1455052599-11418-1-git-send-email-ddaney.cavm@gmail.com>

From: Andrew Pinski <apinski at cavium.com>

On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
instructions may cause the icache to become invalid if it contains
data for a non-current ASID.

This patch implements the workaround (which flushes the local icache
when switching the mm) by using code patching.

Signed-off-by: Andrew Pinski <apinski at cavium.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
Changes from v1: Add entry to silicon-errata.txt

 Documentation/arm64/silicon-errata.txt |  1 +
 arch/arm64/Kconfig                     | 11 +++++++++++
 arch/arm64/include/asm/cpufeature.h    |  3 ++-
 arch/arm64/kernel/cpu_errata.c         |  9 +++++++++
 arch/arm64/mm/proc.S                   | 12 ++++++++++++
 5 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index 58b71dd..ba4b6ac 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -56,3 +56,4 @@ stable kernels.
 |                |                 |                 |                         |
 | Cavium         | ThunderX ITS    | #22375, #24313  | CAVIUM_ERRATUM_22375    |
 | Cavium         | ThunderX GICv3  | #23154          | CAVIUM_ERRATUM_23154    |
+| Cavium         | ThunderX Core   | #27456          | CAVIUM_ERRATUM_27456    |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc6228..a969970 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -432,6 +432,17 @@ config CAVIUM_ERRATUM_23154
 
 	  If unsure, say Y.
 
+config CAVIUM_ERRATUM_27456
+	bool "Cavium erratum 27456: Broadcast TLBI instructions may cause the icache to become invalid"
+	default y
+	help
+	  On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
+	  instructions may cause the icache to become invalid if it
+	  contains data for a non-current ASID.  The fix is to flush
+	  the icache when changing the mm context.
+
+	  If unsure, say Y.
+
 endmenu
 
 
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 8f271b8..8136afc 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -30,8 +30,9 @@
 #define ARM64_HAS_LSE_ATOMICS			5
 #define ARM64_WORKAROUND_CAVIUM_23154		6
 #define ARM64_WORKAROUND_834220			7
+#define ARM64_WORKAROUND_CAVIUM_27456		8
 
-#define ARM64_NCAPS				8
+#define ARM64_NCAPS				9
 
 #ifndef __ASSEMBLY__
 
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index feb6b4e..a3e846a 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -100,6 +100,15 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
 		MIDR_RANGE(MIDR_THUNDERX, 0x00, 0x01),
 	},
 #endif
+#ifdef CONFIG_CAVIUM_ERRATUM_27456
+	{
+	/* Cavium ThunderX, T88 pass 1.x - 2.1 */
+		.desc = "Cavium erratum 27456",
+		.capability = ARM64_WORKAROUND_CAVIUM_27456,
+		MIDR_RANGE(MIDR_THUNDERX, 0x00,
+			   (1 << MIDR_VARIANT_SHIFT) | 1),
+	},
+#endif
 	{
 	}
 };
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index c164d2c..0f3be00 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -25,6 +25,8 @@
 #include <asm/hwcap.h>
 #include <asm/pgtable-hwdef.h>
 #include <asm/pgtable.h>
+#include <asm/cpufeature.h>
+#include <asm/alternative.h>
 
 #include "proc-macros.S"
 
@@ -137,7 +139,17 @@ ENTRY(cpu_do_switch_mm)
 	bfi	x0, x1, #48, #16		// set the ASID
 	msr	ttbr0_el1, x0			// set TTBR0
 	isb
+alternative_if_not ARM64_WORKAROUND_CAVIUM_27456
 	ret
+	nop
+	nop
+	nop
+alternative_else
+	ic	iallu
+	dsb	nsh
+	isb
+	ret
+alternative_endif
 ENDPROC(cpu_do_switch_mm)
 
 /*
-- 
1.8.3.1



From paul at pwsan.com  Tue Feb  9 13:34:32 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 9 Feb 2016 21:34:32 +0000 (UTC)
Subject: [PATCH 0/3] omap: hwmod: add default reset handling support
In-Reply-To: <56BA49D4.8040900@ti.com>
References: <1454929941-23949-1-git-send-email-kishon@ti.com>
 <56B9037C.2050203@ti.com> <56B9767D.7000708@ti.com> <56BA258D.3040002@ti.com>
 <56BA49D4.8040900@ti.com>
Message-ID: <alpine.DEB.2.02.1602092131280.27214@utopia.booyaka.com>

On Tue, 9 Feb 2016, Dave Gerlach wrote:

> Sorry got held up by the discussion here [1], that regression affects
> rmmod/re-insmod of wkup_m3_rproc as well. If I revert the guilty patch
> 5de85b9d57ab ("PM / runtime: Re-init runtime
> PM states at probe error and driver unbind") and apply these three patches, on
> initial probe of the wkup_m3_rproc and wkup_m3_ipc drivers in v4.5-rc3 I see:
> 
> [   15.593460] omap_hwmod: wkup_m3: _wait_target_disable failed
> 
> Which is triggered by the reset of the wkup_m3 from the wkup_m3_ipc driver
> when booting the wkup_m3_rproc. Flow is:
> 
> 1. wkup_m3_rproc probes and calls pm_runtime_get_sync, which calls hwmod
> _enable but bails out because _are_all_hardreset_lines_asserted(oh) causes it
> to return 0.
> 
> 2. wkup_m3_ipc probes and calls rproc_boot, which triggers
> omap_device_deassert_hardreset in order to let the wkup_m3 start.

The patches that Kishon posted shouldn't change the existing hardreset 
behavior for any IP block with HWMOD_CUSTOM_HARDRESET marked.  If the
behavior changes before and after that patch set, something isn't right.

> It is inside the omap_device_deassert_hardreset ( and inside that,
> omap_hwmod_deassert_hardreset) where I end up with the error message, but
> after that rmmod/insmod of the module over and over again shows no additional
> error messages (at least with the above mentioned PM patch reverted).

I no longer recall why we had the _are_all_hardreset_lines_asserted(oh) 
test in place.  But we might be able to drop it now that we have the 
HWMOD_CUSTOM_HARDRESET flag.
 

- Paul


From yang.shi at linaro.org  Tue Feb  9 13:26:22 2016
From: yang.shi at linaro.org (Yang Shi)
Date: Tue,  9 Feb 2016 13:26:22 -0800
Subject: [PATCH] arm64: use raw_smp_processor_id in stack backtrace dump
Message-ID: <1455053182-31404-1-git-send-email-yang.shi@linaro.org>

dump_backtrace may be called in kthread context, which is not bound to a single
cpu, i.e. khungtaskd, then calling smp_processor_id may trigger the below bug
report:

BUG: using smp_processor_id() in preemptible [00000000] code: khungtaskd/71
caller is debug_smp_processor_id+0x1c/0x28
CPU: 3 PID: 71 Comm: khungtaskd Not tainted 4.5.0-rc1 #144
Hardware name: Freescale Layerscape 2085a RDB Board (DT)
Call trace:
[<ffffffc00008d120>] dump_backtrace+0x0/0x290
[<ffffffc00008d3d4>] show_stack+0x24/0x30
[<ffffffc0006bfd1c>] dump_stack+0x8c/0xd8
[<ffffffc0006fe56c>] check_preemption_disabled+0x184/0x188
[<ffffffc0006fe58c>] debug_smp_processor_id+0x1c/0x28
[<ffffffc00008d1a4>] dump_backtrace+0x84/0x290
[<ffffffc00008d3d4>] show_stack+0x24/0x30
[<ffffffc00012aa5c>] sched_show_task+0x16c/0x280
[<ffffffc0001f3df8>] watchdog+0x560/0x708
[<ffffffc000111bb8>] kthread+0x1b0/0x1d0
[<ffffffc0000864d0>] ret_from_fork+0x10/0x40

Replace it to raw version to prevent from the race condition.

Signed-off-by: Yang Shi <yang.shi at linaro.org>
---
 arch/arm64/kernel/traps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index cbedd72..9abe236 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -146,7 +146,7 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
 static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 {
 	struct stackframe frame;
-	unsigned long irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
+	unsigned long irq_stack_ptr = IRQ_STACK_PTR(raw_smp_processor_id());
 	int skip;
 
 	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
-- 
2.0.2



From sergei.shtylyov at cogentembedded.com  Tue Feb  9 13:52:09 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Feb 2016 00:52:09 +0300
Subject: [PATCH v2 0/5] Add R8A7794 sound DT support
Message-ID: <12033353.rt0nolnBmD@wasted.cogentembedded.com>

Hello.

   Here's the set of 5 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20160208-v4.5-rc3' tag. I'm adding the sound device tree support
for the R8A7794 SoC. The sound patch for the SILK board will be posted RSN. :-)

[1/5] ARM: dts: r8a7794: add audio clocks
[2/5] ARM: dts: r8a7794: add MSTP5 clocks
[3/5] ARM: dts: r8a7794: add MSTP10 clocks
[4/5] ARM: dts: r8a7794: add Audio-DMAC support
[5/5] ARM: dts: r8a7794 add sound support

WBR, Sergei



From edubezval at gmail.com  Tue Feb  9 13:52:12 2016
From: edubezval at gmail.com (Eduardo Valentin)
Date: Tue, 9 Feb 2016 13:52:12 -0800
Subject: [PATCH 0/3] arm: dts: DRA7: Add IVA and DSPEVE thermal domain data
In-Reply-To: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>
References: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>
Message-ID: <20160209215210.GB27284@localhost.localdomain>

On Mon, Feb 08, 2016 at 02:46:27PM +0530, Keerthy wrote:
> OMAP5 has 3 thermal zones cpu, core and multimedia.
> On the other hand DRA7 has 5 thermal zones cpu, gpu, core, dspeve
> and iva. Currently cpu, core and multimedia are being added via dt
> and the other 2 are getting added via kernel. Add the missing thermal
> domains in dt so as give the correct trip numbers, type and temperatures.
> 
> Tested on DRA7-EVM.

For the series:

Acked-by: Eduardo Valentin <edubezval at gmail.com>

>  
> Keerthy (3):
>   arm: dts: DRA7: Add DSPEVE thermal data
>   arm: dts: DRA7: Add IVA thermal data
>   arm: dts: DRA7: Add missing IVA and DSPEVE thermal domain data
> 
>  arch/arm/boot/dts/dra7-dspeve-thermal.dtsi | 27 +++++++++++++++++++++++++++
>  arch/arm/boot/dts/dra7-iva-thermal.dtsi    | 27 +++++++++++++++++++++++++++
>  arch/arm/boot/dts/dra7.dtsi                |  2 ++
>  3 files changed, 56 insertions(+)
>  create mode 100644 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi
>  create mode 100644 arch/arm/boot/dts/dra7-iva-thermal.dtsi
> 
> -- 
> 1.9.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/7401701f/attachment.sig>

From sergei.shtylyov at cogentembedded.com  Tue Feb  9 13:53:18 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Feb 2016 00:53:18 +0300
Subject: [PATCH v2 1/5] ARM: dts: r8a7794: add audio clocks
In-Reply-To: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
Message-ID: <2889404.8PU5kSFXZ7@wasted.cogentembedded.com>

Describe the external audio clocks (signals AUDIO_CLK[ABC]) required by
the sound driver. Boards that provide audio clocks need to override the
clock frequencies.

This patch is based on the commit 0d3dbde84a45 ("ARM: shmobile: r8a7791:
add  audio clock on DTSI").

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/boot/dts/r8a7794.dtsi |   24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -833,6 +833,30 @@
 			status = "disabled";
 		};
 
+		/*
+		 * The external audio clocks are configured  as 0 Hz fixed
+		 * frequency clocks by default.  Boards that provide audio
+		 * clocks should override them.
+		 */
+		audio_clka: audio_clka {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+			clock-output-names = "audio_clka";
+		};
+		audio_clkb: audio_clkb {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+			clock-output-names = "audio_clkb";
+		};
+		audio_clkc: audio_clkc {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+			clock-output-names = "audio_clkc";
+		};
+
 		/* Special CPG clocks */
 		cpg_clocks: cpg_clocks at e6150000 {
 			compatible = "renesas,r8a7794-cpg-clocks",



From edubezval at gmail.com  Tue Feb  9 13:53:27 2016
From: edubezval at gmail.com (Eduardo Valentin)
Date: Tue, 9 Feb 2016 13:53:27 -0800
Subject: [PATCH 0/3] arm: dts: DRA7: Add IVA and DSPEVE thermal domain data
In-Reply-To: <56B95EF7.9080107@ti.com>
References: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>
 <20160208195704.GW19432@atomide.com> <56B95EF7.9080107@ti.com>
Message-ID: <20160209215326.GC27284@localhost.localdomain>

On Tue, Feb 09, 2016 at 09:07:27AM +0530, Keerthy wrote:
> 
> 
> On Tuesday 09 February 2016 01:27 AM, Tony Lindgren wrote:
> >* Keerthy <j-keerthy at ti.com> [160208 01:19]:
> >>OMAP5 has 3 thermal zones cpu, core and multimedia.
> >>On the other hand DRA7 has 5 thermal zones cpu, gpu, core, dspeve
> >>and iva. Currently cpu, core and multimedia are being added via dt
> >>and the other 2 are getting added via kernel. Add the missing thermal
> >>domains in dt so as give the correct trip numbers, type and temperatures.

But the driver would add these default domains only if booted /loaded with
missing DT device entry, right?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/6e42b80d/attachment.sig>

From sergei.shtylyov at cogentembedded.com  Tue Feb  9 13:54:06 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Feb 2016 00:54:06 +0300
Subject: [PATCH v2 2/5] ARM: dts: r8a7794: add MSTP5 clocks
In-Reply-To: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
Message-ID: <2534244.nKeMkkXfQ6@wasted.cogentembedded.com>

Add some MSTP5 clocks to the R8A7794 device tree.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes in version 2:
- added "the" article to the change log.

 arch/arm/boot/dts/r8a7794.dtsi            |    9 +++++++++
 include/dt-bindings/clock/r8a7794-clock.h |    1 +
 2 files changed, 10 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -1105,6 +1105,15 @@
 			clock-indices = <R8A7794_CLK_IRQC>;
 			clock-output-names = "irqc";
 		};
+		mstp5_clks: mstp5_clks at e6150144 {
+			compatible = "renesas,r8a7794-mstp-clocks", "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150144 0 4>, <0 0xe615003c 0 4>;
+			clocks = <&hp_clk>, <&extal_clk>, <&p_clk>;
+			#clock-cells = <1>;
+			clock-indices = <R8A7794_CLK_AUDIO_DMAC0
+					 R8A7794_CLK_THERMAL R8A7794_CLK_PWM>;
+			clock-output-names = "audmac0", "thermal", "pwm";
+		};
 		mstp7_clks: mstp7_clks at e615014c {
 			compatible = "renesas,r8a7794-mstp-clocks", "renesas,cpg-mstp-clocks";
 			reg = <0 0xe615014c 0 4>, <0 0xe61501c4 0 4>;
Index: renesas/include/dt-bindings/clock/r8a7794-clock.h
===================================================================
--- renesas.orig/include/dt-bindings/clock/r8a7794-clock.h
+++ renesas/include/dt-bindings/clock/r8a7794-clock.h
@@ -64,6 +64,7 @@
 #define R8A7794_CLK_IRQC		7
 
 /* MSTP5 */
+#define R8A7794_CLK_AUDIO_DMAC0		2
 #define R8A7794_CLK_THERMAL		22
 #define R8A7794_CLK_PWM			23
 



From sergei.shtylyov at cogentembedded.com  Tue Feb  9 13:55:27 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Feb 2016 00:55:27 +0300
Subject: [PATCH v2 3/5] ARM: dts: r8a7794: add MSTP10 clocks
In-Reply-To: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
Message-ID: <3117199.H0l8KQQ7pd@wasted.cogentembedded.com>

Add MSTP10 clocks to the R8A7794 device tree.

This patch is based on the commit ee9141522dcf ("ARM: shmobile: r8a7791:
add MSTP10 support on DTSI").

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes in version 2:
- fixed the SoC model in the change log;
- added "the" article to the change log.

 arch/arm/boot/dts/r8a7794.dtsi            |   53 ++++++++++++++++++++++++++++++
 include/dt-bindings/clock/r8a7794-clock.h |   28 +++++++++++++++
 2 files changed, 81 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -1165,6 +1165,59 @@
 				"gpio1", "gpio0", "qspi_mod",
 				"i2c5", "i2c4", "i2c3", "i2c2", "i2c1", "i2c0";
 		};
+		mstp10_clks: mstp10_clks at e6150998 {
+			compatible = "renesas,r8a7794-mstp-clocks",
+				     "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>;
+			clocks = <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+				 <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+				 <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>,
+				 <&mstp10_clks R8A7794_CLK_SCU_ALL>;
+			#clock-cells = <1>;
+			clock-indices = <R8A7794_CLK_SSI_ALL
+					 R8A7794_CLK_SSI9 R8A7794_CLK_SSI8
+					 R8A7794_CLK_SSI7 R8A7794_CLK_SSI6
+					 R8A7794_CLK_SSI5 R8A7794_CLK_SSI4
+					 R8A7794_CLK_SSI3 R8A7794_CLK_SSI2
+					 R8A7794_CLK_SSI1 R8A7794_CLK_SSI0
+					 R8A7794_CLK_SCU_ALL
+					 R8A7794_CLK_SCU_DVC1
+					 R8A7794_CLK_SCU_DVC0
+					 R8A7794_CLK_SCU_CTU1_MIX1
+					 R8A7794_CLK_SCU_CTU0_MIX0
+					 R8A7794_CLK_SCU_SRC9
+					 R8A7794_CLK_SCU_SRC8
+					 R8A7794_CLK_SCU_SRC7
+					 R8A7794_CLK_SCU_SRC6
+					 R8A7794_CLK_SCU_SRC5
+					 R8A7794_CLK_SCU_SRC4
+					 R8A7794_CLK_SCU_SRC3
+					 R8A7794_CLK_SCU_SRC2
+					 R8A7794_CLK_SCU_SRC1
+					 R8A7794_CLK_SCU_SRC0>;
+			clock-output-names = "ssi-all", "ssi9", "ssi8", "ssi7",
+					     "ssi6", "ssi5", "ssi4", "ssi3",
+					     "ssi2", "ssi1", "ssi0",
+					     "scu-all", "scu-dvc1", "scu-dvc0",
+					     "scu-ctu1-mix1", "scu-ctu0-mix0",
+					     "scu-src9", "scu-src8", "scu-src7",
+					     "scu-src6", "scu-src5", "scu-src4",
+					     "scu-src3", "scu-src2", "scu-src1",
+					     "scu-src0";
+		};
 		mstp11_clks: mstp11_clks at e615099c {
 			compatible = "renesas,r8a7794-mstp-clocks", "renesas,cpg-mstp-clocks";
 			reg = <0 0xe615099c 0 4>, <0 0xe61509ac 0 4>;
Index: renesas/include/dt-bindings/clock/r8a7794-clock.h
===================================================================
--- renesas.orig/include/dt-bindings/clock/r8a7794-clock.h
+++ renesas/include/dt-bindings/clock/r8a7794-clock.h
@@ -103,6 +103,34 @@
 #define R8A7794_CLK_I2C1		30
 #define R8A7794_CLK_I2C0		31
 
+/* MSTP10 */
+#define R8A7794_CLK_SSI_ALL		5
+#define R8A7794_CLK_SSI9		6
+#define R8A7794_CLK_SSI8		7
+#define R8A7794_CLK_SSI7		8
+#define R8A7794_CLK_SSI6		9
+#define R8A7794_CLK_SSI5		10
+#define R8A7794_CLK_SSI4		11
+#define R8A7794_CLK_SSI3		12
+#define R8A7794_CLK_SSI2		13
+#define R8A7794_CLK_SSI1		14
+#define R8A7794_CLK_SSI0		15
+#define R8A7794_CLK_SCU_ALL		17
+#define R8A7794_CLK_SCU_DVC1		18
+#define R8A7794_CLK_SCU_DVC0		19
+#define R8A7794_CLK_SCU_CTU1_MIX1	20
+#define R8A7794_CLK_SCU_CTU0_MIX0	21
+#define R8A7794_CLK_SCU_SRC9		22
+#define R8A7794_CLK_SCU_SRC8		23
+#define R8A7794_CLK_SCU_SRC7		24
+#define R8A7794_CLK_SCU_SRC6		25
+#define R8A7794_CLK_SCU_SRC5		26
+#define R8A7794_CLK_SCU_SRC4		27
+#define R8A7794_CLK_SCU_SRC3		28
+#define R8A7794_CLK_SCU_SRC2		29
+#define R8A7794_CLK_SCU_SRC1		30
+#define R8A7794_CLK_SCU_SRC0		31
+
 /* MSTP11 */
 #define R8A7794_CLK_SCIFA3		6
 #define R8A7794_CLK_SCIFA4		7



From sergei.shtylyov at cogentembedded.com  Tue Feb  9 13:56:34 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Feb 2016 00:56:34 +0300
Subject: [PATCH v2 4/5] ARM: dts: r8a7794: add Audio-DMAC support
In-Reply-To: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
Message-ID: <5519679.0f6oS5evyW@wasted.cogentembedded.com>

Describe Audio-DMAC in the R8A7794 device tree.

This patch is loosely based on the commit 8994fff67761 ("ARM: shmobile:
r8a7791: Add Audio DMAC devices to DT").

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/boot/dts/r8a7794.dtsi |   28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -281,6 +281,34 @@
 		dma-channels = <15>;
 	};
 
+	audma0: dma-controller at ec700000 {
+		compatible = "renesas,dmac-r8a7794", "renesas,rcar-dmac";
+		reg = <0 0xec700000 0 0x10000>;
+		interrupts =	<GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "error",
+				  "ch0", "ch1", "ch2", "ch3", "ch4", "ch5",
+				  "ch6", "ch7", "ch8", "ch9", "ch10", "ch11",
+				  "ch12";
+		clocks = <&mstp5_clks R8A7794_CLK_AUDIO_DMAC0>;
+		clock-names = "fck";
+		power-domains = <&cpg_clocks>;
+		#dma-cells = <1>;
+		dma-channels = <13>;
+	};
+
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a7794",
 			     "renesas,rcar-gen2-scifa", "renesas,scifa";



From wei at redhat.com  Tue Feb  9 13:57:12 2016
From: wei at redhat.com (Wei Huang)
Date: Tue, 9 Feb 2016 15:57:12 -0600
Subject: [PATCH 3/5] irqchip/gic-v2: Parse and export virtual GIC
 information
In-Reply-To: <20160209204914.GE5171@cbox>
References: <1454950049-741-1-git-send-email-julien.grall@arm.com>
 <1454950049-741-4-git-send-email-julien.grall@arm.com>
 <20160209204914.GE5171@cbox>
Message-ID: <56BA60B8.3020008@redhat.com>



On 02/09/2016 02:49 PM, Christoffer Dall wrote:
> On Mon, Feb 08, 2016 at 04:47:27PM +0000, Julien Grall wrote:
>> For now, the firmware tables are parsed 2 times: once in the GIC
>> drivers, the other timer when initializing the vGIC. It means code
>> duplication and make more tedious to add the support for another
>> firmware table (like ACPI).
>>
>> Introduce a new structure and set of helpers to get/set the virtual GIC
>> information. Also fill up the structure for GICv2.
>>
>> Signed-off-by: Julien Grall <julien.grall at arm.com>
>> ---
>>
>> Cc: Thomas Gleixner <tglx at linutronix.de>
>> Cc: Jason Cooper <jason at lakedaemon.net>
>> Cc: Marc Zyngier <marc.zyngier at arm.com>
>>
>>  drivers/irqchip/irq-gic-common.c       | 13 ++++++
>>  drivers/irqchip/irq-gic-common.h       |  3 ++
>>  drivers/irqchip/irq-gic.c              | 78 +++++++++++++++++++++++++++++++++-
>>  include/linux/irqchip/arm-gic-common.h | 34 +++++++++++++++
>>  4 files changed, 127 insertions(+), 1 deletion(-)
>>  create mode 100644 include/linux/irqchip/arm-gic-common.h
>>
>> diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
>> index f174ce0..704caf4 100644
>> --- a/drivers/irqchip/irq-gic-common.c
>> +++ b/drivers/irqchip/irq-gic-common.c
>> @@ -21,6 +21,19 @@
>>  
>>  #include "irq-gic-common.h"
>>  
>> +static const struct gic_kvm_info *gic_kvm_info;
>> +
>> +const struct gic_kvm_info *gic_get_kvm_info(void)
>> +{
>> +	return gic_kvm_info;
>> +}
>> +
>> +void gic_set_kvm_info(const struct gic_kvm_info *info)
>> +{
>> +	WARN(gic_kvm_info != NULL, "gic_kvm_info already set\n");
>> +	gic_kvm_info = info;
>> +}
>> +
>>  void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
>>  		void *data)
>>  {
>> diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
>> index fff697d..205e5fd 100644
>> --- a/drivers/irqchip/irq-gic-common.h
>> +++ b/drivers/irqchip/irq-gic-common.h
>> @@ -19,6 +19,7 @@
>>  
>>  #include <linux/of.h>
>>  #include <linux/irqdomain.h>
>> +#include <linux/irqchip/arm-gic-common.h>
>>  
>>  struct gic_quirk {
>>  	const char *desc;
>> @@ -35,4 +36,6 @@ void gic_cpu_config(void __iomem *base, void (*sync_access)(void));
>>  void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
>>  		void *data);
>>  
>> +void gic_set_kvm_info(const struct gic_kvm_info *info);
>> +
>>  #endif /* _IRQ_GIC_COMMON_H */
>> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
>> index 911758c..d3a09a4 100644
>> --- a/drivers/irqchip/irq-gic.c
>> +++ b/drivers/irqchip/irq-gic.c
>> @@ -102,6 +102,8 @@ static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;
>>  
>>  static struct gic_chip_data gic_data[CONFIG_ARM_GIC_MAX_NR] __read_mostly;
>>  
>> +static struct gic_kvm_info gic_v2_kvm_info;
>> +
>>  #ifdef CONFIG_GIC_NON_BANKED
>>  static void __iomem *gic_get_percpu_base(union gic_base *base)
>>  {
>> @@ -1190,6 +1192,44 @@ static bool gic_check_eoimode(struct device_node *node, void __iomem **base)
>>  	return true;
>>  }
>>  
>> +static void __init gic_of_setup_kvm_info(struct device_node *node)
>> +{
>> +	int ret;
>> +	struct resource r;
>> +	unsigned int irq;
>> +
>> +	gic_v2_kvm_info.type = GIC_V2;
>> +
>> +	irq = irq_of_parse_and_map(node, 0);
>> +	if (!irq)
>> +		gic_v2_kvm_info.maint_irq = -1;
>> +	else
>> +		gic_v2_kvm_info.maint_irq = irq;
>> +
>> +	ret = of_address_to_resource(node, 2, &r);
>> +	if (!ret) {
>> +		gic_v2_kvm_info.vctrl_base = r.start;
>> +		gic_v2_kvm_info.vctrl_size = resource_size(&r);
>> +	}
>> +
>> +	ret = of_address_to_resource(node, 3, &r);
>> +	if (!ret) {
>> +		if (!PAGE_ALIGNED(r.start))
>> +			pr_warn("GICV physical address 0x%llx not page aligned\n",
>> +				(unsigned long long)r.start);
>> +		else if (!PAGE_ALIGNED(resource_size(&r)))
>> +			pr_warn("GICV size 0x%llx not a multiple of page size 0x%lx\n",
>> +				(unsigned long long)resource_size(&r),
>> +				PAGE_SIZE);
>> +		else {
>> +			gic_v2_kvm_info.vcpu_base = r.start;
>> +			gic_v2_kvm_info.vcpu_size = resource_size(&r);
>> +		}
>> +	}
>> +
>> +	gic_set_kvm_info(&gic_v2_kvm_info);
>> +}
>> +
>>  int __init
>>  gic_of_init(struct device_node *node, struct device_node *parent)
>>  {
>> @@ -1219,8 +1259,10 @@ gic_of_init(struct device_node *node, struct device_node *parent)
>>  
>>  	__gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset,
>>  			 &node->fwnode);
>> -	if (!gic_cnt)
>> +	if (!gic_cnt) {
>>  		gic_init_physaddr(node);
>> +		gic_of_setup_kvm_info(node);
>> +	}
>>  
>>  	if (parent) {
>>  		irq = irq_of_parse_and_map(node, 0);
>> @@ -1247,6 +1289,32 @@ IRQCHIP_DECLARE(pl390, "arm,pl390", gic_of_init);
>>  
>>  #ifdef CONFIG_ACPI
>>  static phys_addr_t cpu_phy_base __initdata;
>> +static struct
>> +{
>> +	u32 maint_irq;
>> +	int maint_irq_mode;
>> +	phys_addr_t vctrl_base;
>> +	phys_addr_t vcpu_base;
>> +} acpi_data __initdata;
>> +
>> +static void __init gic_acpi_setup_kvm_info(void)
>> +{
>> +	gic_v2_kvm_info.type = GIC_V2;
>> +
>> +	gic_v2_kvm_info.maint_irq = acpi_register_gsi(NULL,
>> +						      acpi_data.maint_irq,
>> +						      acpi_data.maint_irq_mode,
>> +						      ACPI_ACTIVE_HIGH);
>> +	gic_v2_kvm_info.vctrl_base = acpi_data.vctrl_base;
>> +	if (gic_v2_kvm_info.vctrl_base)
>> +		gic_v2_kvm_info.vctrl_size = SZ_8K;
>> +
>> +	gic_v2_kvm_info.vcpu_base = acpi_data.vcpu_base;
>> +	if (gic_v2_kvm_info.vcpu_base)
>> +		gic_v2_kvm_info.vcpu_size = SZ_8K;
> 
> why are the sizes hard-coded to 8K in this case?

ACPI doesn't provide the size info for GICH and GICV resources. So we
have to pick a default one, which is 8K.

> 
> Thanks,
> -Christoffer
> 


From sergei.shtylyov at cogentembedded.com  Tue Feb  9 13:58:48 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Feb 2016 00:58:48 +0300
Subject: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
In-Reply-To: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
Message-ID: <2543047.yYrDdYb9v5@wasted.cogentembedded.com>

Define the generic R8A7794 part of  the sound device node.
This sound device  is a complex one and comprises the Audio Clock Generator
(ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
(SSI[U]), and Audio DMAC-Peripheral-Peripheral.
It is up  to the board file to enable the device.

This patch is based on the R8A7791 sound work by Kuninori Morimoto.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
Changes in version 2:
- added "ctu.[01]", "mix.[01]", "dvc.[01]" to the "clock-names" prop;
- added  CTU/DVC/MIX subnodes;
- removed SRC0/7/8/9 subnodes;
- added missing colon to the subject.

 arch/arm/boot/dts/r8a7794.dtsi |  182 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 182 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -1309,4 +1309,186 @@
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
+
+	rcar_sound: sound at ec500000 {
+		/*
+		 * #sound-dai-cells is required
+		 *
+		 * Single DAI : #sound-dai-cells = <0>;         <&rcar_sound>;
+		 * Multi  DAI : #sound-dai-cells = <1>;         <&rcar_sound N>;
+		 */
+		compatible = "renesas,rcar_sound-r8a7794",
+			     "renesas,rcar_sound-gen2";
+		reg =	<0 0xec500000 0 0x1000>, /* SCU */
+			<0 0xec5a0000 0 0x100>,  /* ADG */
+			<0 0xec540000 0 0x1000>, /* SSIU */
+			<0 0xec541000 0 0x280>,  /* SSI */
+			<0 0xec740000 0 0x200>;  /* Audio DMAC peri peri */
+		reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
+
+		clocks = <&mstp10_clks R8A7794_CLK_SSI_ALL>,
+			 <&mstp10_clks R8A7794_CLK_SSI9>,
+			 <&mstp10_clks R8A7794_CLK_SSI8>,
+			 <&mstp10_clks R8A7794_CLK_SSI7>,
+			 <&mstp10_clks R8A7794_CLK_SSI6>,
+			 <&mstp10_clks R8A7794_CLK_SSI5>,
+			 <&mstp10_clks R8A7794_CLK_SSI4>,
+			 <&mstp10_clks R8A7794_CLK_SSI3>,
+			 <&mstp10_clks R8A7794_CLK_SSI2>,
+			 <&mstp10_clks R8A7794_CLK_SSI1>,
+			 <&mstp10_clks R8A7794_CLK_SSI0>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC9>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC8>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC7>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC6>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC5>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC4>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC3>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC2>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC1>,
+			 <&mstp10_clks R8A7794_CLK_SCU_SRC0>,
+			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
+			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
+			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
+			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
+			 <&mstp10_clks R8A7794_CLK_SCU_DVC0>,
+			 <&mstp10_clks R8A7794_CLK_SCU_DVC1>,
+			 <&audio_clka>, <&audio_clkb>, <&audio_clkc>,
+			 <&m2_clk>;
+		clock-names = "ssi-all",
+			      "ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
+			      "ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0",
+			      "src.9", "src.8", "src.7", "src.6", "src.5",
+			      "src.4", "src.3", "src.2", "src.1", "src.0",
+			      "ctu.0", "ctu.1",
+			      "mix.0", "mix.1",
+			      "dvc.0", "dvc.1",
+			      "clk_a", "clk_b", "clk_c", "clk_i";
+		power-domains = <&cpg_clocks>;
+
+		status = "disabled";
+
+		rcar_sound,dvc {
+			dvc0: dvc at 0 {
+				dmas = <&audma0 0xbc>;
+				dma-names = "tx";
+			};
+			dvc1: dvc at 1 {
+				dmas = <&audma0 0xbe>;
+				dma-names = "tx";
+			};
+		};
+
+		rcar_sound,mix {
+			mix0: mix at 0 { };
+			mix1: mix at 1 { };
+		};
+
+		rcar_sound,ctu {
+			ctu00: ctu at 0 { };
+			ctu01: ctu at 1 { };
+			ctu02: ctu at 2 { };
+			ctu03: ctu at 3 { };
+			ctu10: ctu at 4 { };
+			ctu11: ctu at 5 { };
+			ctu12: ctu at 6 { };
+			ctu13: ctu at 7 { };
+		};
+
+		rcar_sound,src {
+			src1: src at 1 {
+				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x87>, <&audma0 0x9c>;
+				dma-names = "rx", "tx";
+			};
+			src2: src at 2 {
+				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x89>, <&audma0 0x9e>;
+				dma-names = "rx", "tx";
+			};
+			src3: src at 3 {
+				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
+				dma-names = "rx", "tx";
+			};
+			src4: src at 4 {
+				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
+				dma-names = "rx", "tx";
+			};
+			src5: src at 5 {
+				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
+				dma-names = "rx", "tx";
+			};
+			src6: src at 6 {
+				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x91>, <&audma0 0xb4>;
+				dma-names = "rx", "tx";
+			};
+		};
+
+		rcar_sound,ssi {
+			ssi0: ssi at 0 {
+				interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x01>, <&audma0 0x02>,
+				       <&audma0 0x15>, <&audma0 0x16>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi1: ssi at 1 {
+				interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x03>, <&audma0 0x04>,
+				       <&audma0 0x49>, <&audma0 0x4a>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi2: ssi at 2 {
+				interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x05>, <&audma0 0x06>,
+				       <&audma0 0x63>, <&audma0 0x64>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi3: ssi at 3 {
+				interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x07>, <&audma0 0x08>,
+				       <&audma0 0x6f>, <&audma0 0x70>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi4: ssi at 4 {
+				interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x09>, <&audma0 0x0a>,
+				       <&audma0 0x71>, <&audma0 0x72>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi5: ssi at 5 {
+				interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x0b>, <&audma0 0x0c>,
+				       <&audma0 0x73>, <&audma0 0x74>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi6: ssi at 6 {
+				interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x0d>, <&audma0 0x0e>,
+				       <&audma0 0x75>, <&audma0 0x76>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi7: ssi at 7 {
+				interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x0f>, <&audma0 0x10>,
+				       <&audma0 0x79>, <&audma0 0x7a>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi8: ssi at 8 {
+				interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x11>, <&audma0 0x12>,
+				       <&audma0 0x7b>, <&audma0 0x7c>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+			ssi9: ssi at 9 {
+				interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x13>, <&audma0 0x14>,
+				       <&audma0 0x7d>, <&audma0 0x7e>;
+				dma-names = "rx", "tx", "rxu", "txu";
+			};
+		};
+	};
 };



From carlo at caione.org  Tue Feb  9 14:00:17 2016
From: carlo at caione.org (Carlo Caione)
Date: Tue, 9 Feb 2016 23:00:17 +0100
Subject: [PATCH] tty: serial: meson: Add support for XTAL clock input
In-Reply-To: <1454935783-17027-1-git-send-email-afaerber@suse.de>
References: <1454935783-17027-1-git-send-email-afaerber@suse.de>
Message-ID: <CAOQ7t2boy8Y0uPi8iEm=y_qdfY-rdGCK_NRKpx_3Awy4xstwQA@mail.gmail.com>

On Mon, Feb 8, 2016 at 1:49 PM, Andreas F?rber <afaerber at suse.de> wrote:
> Fix the baudrate calculation for 24 MHz XTAL clock found on gxbb platforms.
>
> Signed-off-by: Andreas F?rber <afaerber at suse.de>

Acked-by: Carlo Caione <carlo at endlessm.com>

Thanks!

-- 
Carlo Caione


From edubezval at gmail.com  Tue Feb  9 14:09:01 2016
From: edubezval at gmail.com (Eduardo Valentin)
Date: Tue, 9 Feb 2016 14:09:01 -0800
Subject: [PATCH] arm: dts: AM57XX: Correct the thermal thresholds
In-Reply-To: <1454924705-8382-1-git-send-email-j-keerthy@ti.com>
References: <1454924705-8382-1-git-send-email-j-keerthy@ti.com>
Message-ID: <20160209220901.GC28102@localhost.localdomain>

On Mon, Feb 08, 2016 at 03:15:05PM +0530, Keerthy wrote:
> The thermal threholds for am57xx are different from that of dra7.
> Correcting the thresholds for the same.
> 
> Signed-off-by: Keerthy <j-keerthy at ti.com>
> ---
> 
> Depends on: https://lkml.org/lkml/2016/2/8/90
> 
>  arch/arm/boot/dts/am57xx-beagle-x15.dts | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> Index: linux/arch/arm/boot/dts/am57xx-beagle-x15.dts
> ===================================================================
> --- linux.orig/arch/arm/boot/dts/am57xx-beagle-x15.dts	2016-02-08 14:57:05.514959101 +0530
> +++ linux/arch/arm/boot/dts/am57xx-beagle-x15.dts	2016-02-08 14:57:05.510959168 +0530

Sorry, did not bother to check, but is this the only user of am57xx?

Apart from the above:

Acked-by: Eduardo Valentin <edubezval at gmail.com>


> @@ -825,3 +825,27 @@
>  		status = "okay";
>  	};
>  };
> +
> +&cpu_alert0 {
> +	temperature = <90000>; /* milliCelsius */
> +};
> +
> +&cpu_crit {
> +	temperature = <105000>; /* milliCelsius */
> +};
> +
> +&gpu_crit {
> +	temperature = <105000>; /* milliCelsius */
> +};
> +
> +&core_crit {
> +	temperature = <105000>; /* milliCelsius */
> +};
> +
> +&dspeve_crit {
> +	temperature = <105000>; /* milliCelsius */
> +};
> +
> +&iva_crit {
> +	temperature = <105000>; /* milliCelsius */
> +};
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/e62133ba/attachment.sig>

From edubezval at gmail.com  Tue Feb  9 14:10:27 2016
From: edubezval at gmail.com (Eduardo Valentin)
Date: Tue, 9 Feb 2016 14:10:27 -0800
Subject: [PATCH 3/3] thermal: allow u8500-thermal driver to be a module
In-Reply-To: <20160127073300.GJ3368@x1>
References: <1453740264-1972562-1-git-send-email-arnd@arndb.de>
 <1453740264-1972562-4-git-send-email-arnd@arndb.de>
 <20160127073300.GJ3368@x1>
Message-ID: <20160209221026.GD28102@localhost.localdomain>

On Wed, Jan 27, 2016 at 07:33:00AM +0000, Lee Jones wrote:
> On Mon, 25 Jan 2016, Arnd Bergmann wrote:
> 
> > When the thermal subsystem is a loadable module, the u8500 driver
> > fails to build:
> > 
> > drivers/thermal/built-in.o: In function `db8500_thermal_probe':
> > db8500_thermal.c:(.text+0x96c): undefined reference to `thermal_zone_device_register'
> > drivers/thermal/built-in.o: In function `db8500_thermal_work':
> > db8500_thermal.c:(.text+0xab4): undefined reference to `thermal_zone_device_update'
> > 
> > This changes the symbol to a tristate, so Kconfig can track the
> > dependency correctly.
> > 
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > ---
> >  drivers/mfd/db8500-prcmu.c | 3 +++
> >  drivers/thermal/Kconfig    | 4 ++--
> >  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> As this touches a core Thermal file, I think it's better off going in
> via that tree.  If that's a problem, I can take it with the relevant
> Acks.
> 
> Acked-by: Lee Jones <lee.jones at linaro.org>


Thanks, I am adding to linux-next to see how it goes.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/3f8a8e06/attachment.sig>

From tchalamarla at caviumnetworks.com  Tue Feb  9 14:15:13 2016
From: tchalamarla at caviumnetworks.com (tchalamarla at caviumnetworks.com)
Date: Tue, 9 Feb 2016 14:15:13 -0800
Subject: [PATCH V2] arm64: KVM: Configure TCR_EL2.ps at runtime
Message-ID: <1455056113-25948-1-git-send-email-tchalamarla@caviumnetworks.com>

From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>

Setting TCR_EL2.ps to 40 bits is wrong on systems with ps size is
less than 40 bits. and with systems where RAM is at higher address,
this will break KVM.

This patch sets TCR_EL2.ps at runtime similar to VTCR_EL.ps

Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
---
 arch/arm64/include/asm/kvm_arm.h |  5 ++++-
 arch/arm64/kvm/hyp-init.S        | 10 ++++++----
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 738a95f..92f2ffd 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -107,7 +107,10 @@
 #define TCR_EL2_MASK	(TCR_EL2_TG0 | TCR_EL2_SH0 | \
 			 TCR_EL2_ORGN0 | TCR_EL2_IRGN0 | TCR_EL2_T0SZ)
 
-#define TCR_EL2_FLAGS	(TCR_EL2_RES1 | TCR_EL2_PS_40B)
+/*
+ * TCR_EL2.ps is configured at runtime similar to VTCR_EL2
+ */
+#define TCR_EL2_FLAGS	(TCR_EL2_RES1)
 
 /* VTCR_EL2 Registers bits */
 #define VTCR_EL2_RES1		(1 << 31)
diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
index 3e568dc..b246de1e 100644
--- a/arch/arm64/kvm/hyp-init.S
+++ b/arch/arm64/kvm/hyp-init.S
@@ -85,15 +85,17 @@ __do_hyp_init:
 	ldr_l	x5, idmap_t0sz
 	bfi	x4, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH
 #endif
-	msr	tcr_el2, x4
-
-	ldr	x4, =VTCR_EL2_FLAGS
 	/*
 	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
-	 * VTCR_EL2.
+	 * TCR_EL2 and VTCR_EL2.
 	 */
 	mrs	x5, ID_AA64MMFR0_EL1
 	bfi	x4, x5, #16, #3
+
+	msr	tcr_el2, x4
+
+	ldr	x4, =VTCR_EL2_FLAGS
+	bfi	x4, x5, #16, #3
 	/*
 	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS bit in
 	 * VTCR_EL2.
-- 
2.1.0



From nm at ti.com  Tue Feb  9 14:16:16 2016
From: nm at ti.com (Nishanth Menon)
Date: Tue, 9 Feb 2016 16:16:16 -0600
Subject: [PATCH] arm: dts: AM57XX: Correct the thermal thresholds
In-Reply-To: <20160209220901.GC28102@localhost.localdomain>
References: <1454924705-8382-1-git-send-email-j-keerthy@ti.com>
 <20160209220901.GC28102@localhost.localdomain>
Message-ID: <56BA6530.4030102@ti.com>

On 02/09/2016 04:09 PM, Eduardo Valentin wrote:
> On Mon, Feb 08, 2016 at 03:15:05PM +0530, Keerthy wrote:
>> The thermal threholds for am57xx are different from that of dra7.
>> Correcting the thresholds for the same.
>>
>> Signed-off-by: Keerthy <j-keerthy at ti.com>
>> ---
>>
>> Depends on: https://lkml.org/lkml/2016/2/8/90
>>
>>  arch/arm/boot/dts/am57xx-beagle-x15.dts | 24 ++++++++++++++++++++++++
>>  1 file changed, 24 insertions(+)
>>
>> Index: linux/arch/arm/boot/dts/am57xx-beagle-x15.dts
>> ===================================================================
>> --- linux.orig/arch/arm/boot/dts/am57xx-beagle-x15.dts	2016-02-08 14:57:05.514959101 +0530
>> +++ linux/arch/arm/boot/dts/am57xx-beagle-x15.dts	2016-02-08 14:57:05.510959168 +0530
> 
> Sorry, did not bother to check, but is this the only user of am57xx?

we will have AM57xx-IDK as well coming down the line. we already have
arch/arm/boot/dts/am57xx-cl-som-am57x.dts
arch/arm/boot/dts/am57xx-sbc-am57x.dts - not really sure what grade of
silicon are used in cl-SOM and sbc boards.


-- 
Regards,
Nishanth Menon


From edubezval at gmail.com  Tue Feb  9 14:18:16 2016
From: edubezval at gmail.com (Eduardo Valentin)
Date: Tue, 9 Feb 2016 14:18:16 -0800
Subject: [PATCH 0/3] randconfig warning fixes for thermal
In-Reply-To: <1453740264-1972562-1-git-send-email-arnd@arndb.de>
References: <1453740264-1972562-1-git-send-email-arnd@arndb.de>
Message-ID: <20160209221815.GE28102@localhost.localdomain>

On Mon, Jan 25, 2016 at 05:44:09PM +0100, Arnd Bergmann wrote:
> These are three simple fixes for ARM randconfig builds:
> 
>  [PATCH 1/3] thermal: spear: use __maybe_unused for PM functions
>  [PATCH 2/3] thermal: allow spear-thermal driver to be a module
>  [PATCH 3/3] thermal: allow u8500-thermal driver to be a module
> 
> All three bugs are on configurationsn that are not important and
> that rarely happen even with randconfig builds.
> 
> 	Arnd

Thanks a lot for your cleanups Arnd,
queueing all three.

Eduardo Valentin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/57f41a2f/attachment.sig>

From jic23 at kernel.org  Tue Feb  9 14:44:25 2016
From: jic23 at kernel.org (Jonathan Cameron)
Date: Tue, 9 Feb 2016 22:44:25 +0000
Subject: [PATCH v1 2/2] iio: dac: vf610_dac: Add IIO DAC driver for Vybrid
 SoC
In-Reply-To: <5a699d45c89d239f3e49fa83d16a9b467016e219.1454939346.git.maitysanchayan@gmail.com>
References: <cover.1454939346.git.maitysanchayan@gmail.com>
 <5a699d45c89d239f3e49fa83d16a9b467016e219.1454939346.git.maitysanchayan@gmail.com>
Message-ID: <56BA6BC9.1020101@kernel.org>

On 09/02/16 05:26, Sanchayan Maity wrote:
> Add driver support for DAC peripheral on Vybrid SoC.
> 
> Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
Few minor comments inline.

Jonathan
> ---
>  .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
>  drivers/iio/dac/Kconfig                            |   8 +
>  drivers/iio/dac/Makefile                           |   1 +
>  drivers/iio/dac/vf610_dac.c                        | 302 +++++++++++++++++++++
>  4 files changed, 331 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>  create mode 100644 drivers/iio/dac/vf610_dac.c
> 
> diff --git a/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
> new file mode 100644
> index 0000000..97d7a40
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
> @@ -0,0 +1,20 @@
> +Freescale vf610 Digital to Analog Converter bindings
> +
> +The devicetree bindings are for the new DAC driver written for
> +vf610 SoCs from Freescale.
> +
> +Required properties:
> +- compatible: Should contain "fsl,vf610-dac"
> +- reg: Offset and length of the register set for the device
> +- interrupts: Should contain the interrupt for the device
> +- clocks: The clock is needed by the DAC controller
> +- clock-names: Must contain "dac", matching entry in the clocks property.
> +
> +Example:
> +dac0: dac at 400cc000 {
> +	compatible = "fsl,vf610-dac";
> +	reg = <0x400cc000 0x1000>;
> +	interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
> +	clock-names = "dac";
> +	clocks = <&clks VF610_CLK_DAC0>;
> +};
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index e701e28..8eb0502 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -196,4 +196,12 @@ config MCP4922
>  	  To compile this driver as a module, choose M here: the module
>  	  will be called mcp4922.
>  
> +config VF610_DAC
> +	tristate "Vybrid vf610 DAC driver"
> +	help
> +	  Say yes here to support Vybrid board digital-to-analog converter.
> +
> +	  This driver can also be built as a module. If so, the module will
> +	  be called vf610_dac.
> +
>  endmenu
> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> index 63ae056..93feb27 100644
> --- a/drivers/iio/dac/Makefile
> +++ b/drivers/iio/dac/Makefile
> @@ -21,3 +21,4 @@ obj-$(CONFIG_MAX517) += max517.o
>  obj-$(CONFIG_MAX5821) += max5821.o
>  obj-$(CONFIG_MCP4725) += mcp4725.o
>  obj-$(CONFIG_MCP4922) += mcp4922.o
> +obj-$(CONFIG_VF610_DAC) += vf610_dac.o
> diff --git a/drivers/iio/dac/vf610_dac.c b/drivers/iio/dac/vf610_dac.c
> new file mode 100644
> index 0000000..775b349
> --- /dev/null
> +++ b/drivers/iio/dac/vf610_dac.c
> @@ -0,0 +1,302 @@
> +/*
> + * Freescale Vybrid vf610 DAC driver
> + *
> + * Copyright 2016 Toradex AG
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/slab.h>
> +
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +
> +#define DRIVER_NAME "vf610-dac"
One of my pet hates is having defines like this that add nothing.
Just put it in where it is used (as there is only one place).

> +
> +#define VF610_DACx_STATCTRL		0x20
> +
> +#define VF610_DAC_DACEN			BIT(15)
> +#define VF610_DAC_DACRFS		BIT(14)
> +#define VF610_DAC_LPEN			BIT(11)
> +
> +#define VF610_DAC_DAT0(x)		((x) & 0xFFF)
> +
> +enum conversion_mode_sel {
> +	VF610_DAC_CONV_HIGH_POWER,
> +	VF610_DAC_CONV_LOW_POWER,
> +};
> +
> +struct vf610_dac {
> +	struct clk *clk;
> +	struct device *dev;
> +	enum conversion_mode_sel conv_mode;
> +	void __iomem *regs;
> +	int irq;
> +};
> +
> +static int vf610_dac_init(struct vf610_dac *info)
> +{
> +	int val;
> +
> +	info->conv_mode = VF610_DAC_CONV_LOW_POWER;
> +	val = VF610_DAC_DACEN | VF610_DAC_DACRFS |
> +		VF610_DAC_LPEN;
> +	writel(val, info->regs + VF610_DACx_STATCTRL);
> +
> +	return 0;
> +}
> +
> +static int vf610_set_conversion_mode(struct iio_dev *indio_dev,
> +				const struct iio_chan_spec *chan,
> +				unsigned int mode)
> +{
> +	struct vf610_dac *info = iio_priv(indio_dev);
> +	int val;
> +
> +	mutex_lock(&indio_dev->mlock);
> +	info->conv_mode = mode;
> +	val = readl(info->regs + VF610_DACx_STATCTRL);
> +	if (mode)
> +		val |= VF610_DAC_LPEN;
> +	else
> +		val &= ~VF610_DAC_LPEN;
> +	writel(val, info->regs + VF610_DACx_STATCTRL);
> +	mutex_unlock(&indio_dev->mlock);
> +
> +	return 0;
> +}
> +
> +static int vf610_get_conversion_mode(struct iio_dev *indio_dev,
> +				const struct iio_chan_spec *chan)
> +{
> +	struct vf610_dac *info = iio_priv(indio_dev);
> +
> +	return info->conv_mode;
> +}
> +
> +static const char * const vf610_conv_modes[] = { "high-power", "low-power"};
> +
> +static const struct iio_enum vf610_conversion_mode = {
> +	.items = vf610_conv_modes,
> +	.num_items = ARRAY_SIZE(vf610_conv_modes),
> +	.get = vf610_get_conversion_mode,
> +	.set = vf610_set_conversion_mode,
> +};
> +
> +static const struct iio_chan_spec_ext_info vf610_ext_info[] = {
> +	IIO_ENUM("conversion_mode", IIO_SHARED_BY_DIR,
This will amke it called out_conversion_mode. Does it actually
make sense, rather than IIO_SHARED_BY_ALL which would just
be conversion_mode?  Doesn't really matter either way.
> +		&vf610_conversion_mode),
> +	{},
> +};
> +
> +#define VF610_DAC_CHAN(_chan_type) { \
> +	.type = (_chan_type), \
> +	.indexed = -1, \
> +	.output = 1, \
> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> +	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> +	.ext_info = vf610_ext_info, \
> +}
> +
> +static const struct iio_chan_spec vf610_dac_iio_channels[] = {
> +	VF610_DAC_CHAN(IIO_VOLTAGE),
> +};
> +
> +static int vf610_read_raw(struct iio_dev *indio_dev,
> +			struct iio_chan_spec const *chan,
> +			int *val, int *val2,
> +			long mask)
> +{
> +	struct vf610_dac *info = iio_priv(indio_dev);
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		*val = VF610_DAC_DAT0(readl(info->regs));
> +		return IIO_VAL_INT;
> +	case IIO_CHAN_INFO_SCALE:
> +		/*
> +		 * DACRFS is always 1 for valid reference and typical
> +		 * reference voltage as per Vybrid datasheet is 3.3V
> +		 * from section 9.1.2.1 of Vybrid datasheet
> +		 */
> +		*val = 3300 /* mV */;
> +		*val2 = 12;
Looks at least superficially right to me - I'm being lazy and not reading
the datasheet on this occasion!
> +		return IIO_VAL_FRACTIONAL_LOG2;
> +
> +	default:
> +		break;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static int vf610_write_raw(struct iio_dev *indio_dev,
> +			struct iio_chan_spec const *chan,
> +			int val, int val2,
> +			long mask)
> +{
> +	struct vf610_dac *info = iio_priv(indio_dev);
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		mutex_lock(&indio_dev->mlock);
> +		writel(VF610_DAC_DAT0(val), info->regs);
> +		mutex_unlock(&indio_dev->mlock);
> +		return 0;
> +
> +	default:
> +		break;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static const struct iio_info vf610_dac_iio_info = {
> +	.driver_module = THIS_MODULE,
> +	.read_raw = &vf610_read_raw,
> +	.write_raw = &vf610_write_raw,
> +};
> +
> +static const struct of_device_id vf610_dac_match[] = {
> +	{ .compatible = "fsl,vf610-dac", },
> +	{ /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, vf610_dac_match);
> +
> +static int vf610_dac_probe(struct platform_device *pdev)
> +{
> +	struct iio_dev *indio_dev;
> +	struct vf610_dac *info;
> +	struct resource *mem;
> +	int ret;
> +
> +	indio_dev = devm_iio_device_alloc(&pdev->dev,
> +					sizeof(struct vf610_dac));
> +	if (!indio_dev) {
> +		dev_err(&pdev->dev, "Failed allocating iio device\n");
> +		return -ENOMEM;
> +	}
> +
> +	info = iio_priv(indio_dev);
> +	info->dev = &pdev->dev;
> +
> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	info->regs = devm_ioremap_resource(&pdev->dev, mem);
> +	if (IS_ERR(info->regs))
> +		return PTR_ERR(info->regs);
> +
> +	info->clk = devm_clk_get(&pdev->dev, "dac");
> +	if (IS_ERR(info->clk)) {
> +		dev_err(&pdev->dev, "failed getting clock, err = %ld\n",
> +			PTR_ERR(info->clk));
> +		return PTR_ERR(info->clk);
> +	}
> +
> +	platform_set_drvdata(pdev, indio_dev);
> +
> +	indio_dev->name = dev_name(&pdev->dev);
> +	indio_dev->dev.parent = &pdev->dev;
> +	indio_dev->dev.of_node = pdev->dev.of_node;
> +	indio_dev->info = &vf610_dac_iio_info;
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->channels = vf610_dac_iio_channels;
> +	indio_dev->num_channels = ARRAY_SIZE(vf610_dac_iio_channels);
> +
> +	ret = clk_prepare_enable(info->clk);
> +	if (ret) {
> +		dev_err(&pdev->dev,
> +			"Could not prepare or enable the clock\n");
> +		return ret;
> +	}
> +
> +	ret = iio_device_register(indio_dev);
> +	if (ret) {
> +		dev_err(&pdev->dev, "Couldn't register the device\n");
> +		goto error_iio_device_register;
> +	}
> +
> +	vf610_dac_init(info);
Peter already pointed this out, but iio_device_register is responsible
for exposing an IIO device to the rest of the system (userspace and
in kernel client driverS) so it should not be called until everything is
ready.  You might just get a read before we get to the init call here.
> +
> +	return 0;
> +
> +error_iio_device_register:
> +	clk_disable_unprepare(info->clk);
> +
> +	return ret;
> +}
> +
> +static int vf610_dac_remove(struct platform_device *pdev)
> +{
> +	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> +	struct vf610_dac *info = iio_priv(indio_dev);
> +
> +	iio_device_unregister(indio_dev);
> +	clk_disable_unprepare(info->clk);
> +
> +	return 0;
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int vf610_dac_suspend(struct device *dev)
> +{
> +	struct iio_dev *indio_dev = dev_get_drvdata(dev);
> +	struct vf610_dac *info = iio_priv(indio_dev);
> +	int val;
> +
Given this is presumably 'kind of' the oposite of the
init below, for clear balance I'd break this out to
a vf610_dac_exit function.

Also opens up the question of whether it makes sense to make
this same write in the remove function above.

> +	val = readl(info->regs + VF610_DACx_STATCTRL);
> +	val &= ~VF610_DAC_DACEN;
> +	writel(val, info->regs + VF610_DACx_STATCTRL);
> +
> +	clk_disable_unprepare(info->clk);
> +
> +	return 0;
> +}
> +
> +static int vf610_dac_resume(struct device *dev)
> +{
> +	struct iio_dev *indio_dev = dev_get_drvdata(dev);
> +	struct vf610_dac *info = iio_priv(indio_dev);
> +	int ret;
> +
> +	ret = clk_prepare_enable(info->clk);
> +	if (ret)
> +		return ret;
> +
> +	vf610_dac_init(info);
> +
> +	return 0;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(vf610_dac_pm_ops, vf610_dac_suspend, vf610_dac_resume);
> +
> +static struct platform_driver vf610_dac_driver = {
> +	.probe          = vf610_dac_probe,
> +	.remove         = vf610_dac_remove,
> +	.driver         = {
> +		.name   = DRIVER_NAME,
> +		.of_match_table = vf610_dac_match,
> +		.pm     = &vf610_dac_pm_ops,
> +	},
> +};
> +module_platform_driver(vf610_dac_driver);
> +
> +MODULE_AUTHOR("Sanchayan Maity <sanchayan.maity at toradex.com");
> +MODULE_DESCRIPTION("Freescale VF610 DAC driver");
> +MODULE_LICENSE("GPL v2");
> 



From wsa at the-dreams.de  Tue Feb  9 14:57:24 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Tue, 9 Feb 2016 23:57:24 +0100
Subject: [PATCH] dmaengine: use phys_addr_t for slave configuration
In-Reply-To: <CAMuHMdXe8i2JbhOP2sWkVkqHEeBnW4AfVBbRaoZW=Kg0s_9m3g@mail.gmail.com>
References: <1366967214-20776-1-git-send-email-linus.walleij@linaro.org>
 <CAMuHMdUTzTBT8DyRb5WN048U5DbVsFnhJB0c5tjHBnA4rfetJg@mail.gmail.com>
 <20150710081411.GF836@localhost>
 <CAMuHMdV8a1W1MyJPanUNBzaiNsL96JYzetBVSiZoC3=eKXzo1Q@mail.gmail.com>
 <20151215172649.GK1854@localhost>
 <CAMuHMdXe8i2JbhOP2sWkVkqHEeBnW4AfVBbRaoZW=Kg0s_9m3g@mail.gmail.com>
Message-ID: <20160209225724.GA1522@katana>


> This is a dependency for adding iommu support to the rcar-dmac driver, cfr.
> "[PATCH v2 0/5] dmaengine: rcar-dmac: add iommu support for slave transfers".
> http://www.spinics.net/lists/linux-renesas-soc/msg00066.html
> https://www.mail-archive.com/linux-renesas-soc at vger.kernel.org/msg00108.html
> 
> Thank you for applying!

Yup, we really need it. Anything we can do to help?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/1375b676/attachment.sig>

From Lijun.Pan at freescale.com  Tue Feb  9 15:08:07 2016
From: Lijun.Pan at freescale.com (Lijun Pan)
Date: Tue, 9 Feb 2016 17:08:07 -0600
Subject: [PATCH] ARM: dts: ls2080a: Add quirk for Erratum A009116
Message-ID: <1455059287-2500-1-git-send-email-Lijun.Pan@freescale.com>

Add "snps,quirk-frame-length-adjustment" property to
USB3 node for erratum A009116. This property provides
value of GFLADJ_30MHZ for post silicon frame length
adjustment.

Signed-off-by: Lijun Pan <Lijun.Pan at freescale.com>
---
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 6e9e033..fa506f5 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -501,6 +501,7 @@
 			reg = <0x0 0x3100000 0x0 0x10000>;
 			interrupts = <0 80 0x4>; /* Level high type */
 			dr_mode = "host";
+			snps,quirk-frame-length-adjustment = <0x20>;
 		};
 
 		usb1: usb3 at 3110000 {
@@ -509,6 +510,7 @@
 			reg = <0x0 0x3110000 0x0 0x10000>;
 			interrupts = <0 81 0x4>; /* Level high type */
 			dr_mode = "host";
+			snps,quirk-frame-length-adjustment = <0x20>;
 		};
 
 		ccn at 4000000 {
-- 
1.7.9.5



From heiko at sntech.de  Tue Feb  9 15:32:51 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Wed, 10 Feb 2016 00:32:51 +0100
Subject: [PATCH] ARM: dts: rockchip: replace gpio-key,
 wakeup with wakeup-source property
In-Reply-To: <1454968512-11956-1-git-send-email-sudeep.holla@arm.com>
References: <1454968512-11956-1-git-send-email-sudeep.holla@arm.com>
Message-ID: <48510660.EJbbczq5fX@phil>

Hi Sudeep,

Am Montag, 8. Februar 2016, 21:55:12 schrieb Sudeep Holla:
> Keyboard driver for GPIO buttons(gpio-keys) checks for the legacy
> "gpio-key,wakeup" boolean property to enable gpio buttons as wakeup
> source.
> 
> Few dts files assign value "1" to gpio-key,wakeup and in one instance a
> value "0" is assigned probably assuming it won't be enabled as a wakeup
> source. Since the presence of the boolean property indicates it is
> enabled, value of "0" have no value.
> 
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property which inturn fixes the above mentioned issue.
> 
> Cc: linux-rockchip at lists.infradead.org
> Reviewed-by: Heiko Stuebner <heiko at sntech.de>
> Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
> ---
>  arch/arm/boot/dts/rk3066a-bqcurie2.dts          | 3 +--
>  arch/arm/boot/dts/rk3066a-rayeager.dts          | 2 +-
>  arch/arm/boot/dts/rk3188-radxarock.dts          | 2 +-
>  arch/arm/boot/dts/rk3288-evb.dtsi               | 2 +-
>  arch/arm/boot/dts/rk3288-firefly.dtsi           | 2 +-
>  arch/arm/boot/dts/rk3288-popmetal.dts           | 2 +-
>  arch/arm/boot/dts/rk3288-r89.dts                | 2 +-
>  arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 2 +-
>  arch/arm/boot/dts/rk3288-veyron.dtsi            | 2 +-
>  arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi    | 2 +-
>  arch/arm64/boot/dts/rockchip/rk3368-r88.dts     | 2 +-
>  11 files changed, 11 insertions(+), 12 deletions(-)
> 
> Hi Heiko,
> 
> You can reviewed this, however there are couple of ARM64 dts additions.
> Also most of the other platform/SoC maintainers preferred to take it via
> their tree and few of these got missed during v4.5 merge window.
> Can you take it via your tree for v4.6 ?

I've split the patch in two, as the 32 and 64 bit devicetree parts go 
through separate branches and applied both to their respective branches for 
v4.6


Heiko


From Suravee.Suthikulpanit at amd.com  Tue Feb  9 15:35:34 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Tue, 9 Feb 2016 17:35:34 -0600
Subject: [PATCH V2 08/12] dtb: amd: Add PERF CCN-504 device tree node
In-Reply-To: <3090961.S0JY5ma2pB@wuerfel>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
 <1454954357-8395-9-git-send-email-Suravee.Suthikulpanit@amd.com>
 <3090961.S0JY5ma2pB@wuerfel>
Message-ID: <56BA77C6.6020803@amd.com>



On 02/09/2016 08:58 AM, Arnd Bergmann wrote:
> On Monday 08 February 2016 11:59:13 Suravee Suthikulpanit wrote:
>> +               /* Perf CCN504 PMU */
>> +               ccn: ccn at 0xe8000000 {
>>
>
> The address is wrong, please remove the '0x'.
>
> 	Arnd
>

Right, thanks for catching this.

Suravee


From eric at anholt.net  Tue Feb  9 15:44:02 2016
From: eric at anholt.net (Eric Anholt)
Date: Tue, 09 Feb 2016 15:44:02 -0800
Subject: [PATCH 1/4] spi: bcm2835aux: fix bitmask defines
In-Reply-To: <1455041435-8015-2-git-send-email-stephanolbrich@gmx.de>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <1455041435-8015-2-git-send-email-stephanolbrich@gmx.de>
Message-ID: <87lh6t4fgd.fsf@eliezer.anholt.net>

stephanolbrich at gmx.de writes:

> From: Stephan Olbrich <stephanolbrich at gmx.de>
>
> The bitmasks for txempty and idle interrupts were interchanged.
>
> Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
> ---
>  drivers/spi/spi-bcm2835aux.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
> index 7de6f84..ecc73c0 100644
> --- a/drivers/spi/spi-bcm2835aux.c
> +++ b/drivers/spi/spi-bcm2835aux.c
> @@ -73,8 +73,8 @@
>  
>  /* Bitfields in CNTL1 */
>  #define BCM2835_AUX_SPI_CNTL1_CSHIGH	0x00000700
> -#define BCM2835_AUX_SPI_CNTL1_IDLE	0x00000080
> -#define BCM2835_AUX_SPI_CNTL1_TXEMPTY	0x00000040
> +#define BCM2835_AUX_SPI_CNTL1_TXEMPTY	0x00000080
> +#define BCM2835_AUX_SPI_CNTL1_IDLE	0x00000040
>  #define BCM2835_AUX_SPI_CNTL1_MSBF_IN	0x00000002
>  #define BCM2835_AUX_SPI_CNTL1_KEEP_IN	0x00000001

Confirmed by looking at the hardware.

Reviewed-by: Eric Anholt <eric at anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/d846cff3/attachment.sig>

From eric at anholt.net  Tue Feb  9 15:45:32 2016
From: eric at anholt.net (Eric Anholt)
Date: Tue, 09 Feb 2016 15:45:32 -0800
Subject: [PATCH 2/4] spi: bcm2835aux: disable tx fifo empty irq
In-Reply-To: <1455041435-8015-3-git-send-email-stephanolbrich@gmx.de>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <1455041435-8015-3-git-send-email-stephanolbrich@gmx.de>
Message-ID: <87io1x4fdv.fsf@eliezer.anholt.net>

stephanolbrich at gmx.de writes:

> From: Stephan Olbrich <stephanolbrich at gmx.de>
>
> The tx empty irq can be disabled when all data was copied.
> This prevents unnecessary interrupts while the last bytes are sent.
>
> Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
> ---
>  drivers/spi/spi-bcm2835aux.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
> index ecc73c0..d2f0067 100644
> --- a/drivers/spi/spi-bcm2835aux.c
> +++ b/drivers/spi/spi-bcm2835aux.c
> @@ -212,6 +212,12 @@ static irqreturn_t bcm2835aux_spi_interrupt(int irq, void *dev_id)
>  		ret = IRQ_HANDLED;
>  	}
>  
> +	if (!bs->tx_len) {
> +		/* disable tx fifo empty interrupt */
> +		bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1] |
> +			BCM2835_AUX_SPI_CNTL1_IDLE);
> +	}
> +
>  	/* and if rx_len is 0 then wake up completion and disable spi */
>  	if (!bs->rx_len) {
>  		bcm2835aux_spi_reset_hw(bs);
> -- 
> 2.5.0

Right, we don't want to come back in here with a spurious TX empty
interrupt while we wait for the RX bits to trickle in through the FIFO.
I'm having a hard time reasoning through how likely this would be, but
it seems like a good change.

Reviewed-by: Eric Anholt <eric at anholt.net>

Aside: I think I see a problem that we reset the hardware before it has
asserted SPI_STAT_BUSY, since we reset as soon as we've collected our RX
data (!bs->rx_len).  That means we've potentially missed the trailing
hold time on CS at the end of the transfer, and it's going to resume at
the same point in its state machine when we reassert CNTL0_ENABLE for
the next transfer.  That doesn't seem like what we want.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/dc3a5fe5/attachment.sig>

From eric at anholt.net  Tue Feb  9 15:49:24 2016
From: eric at anholt.net (Eric Anholt)
Date: Tue, 09 Feb 2016 15:49:24 -0800
Subject: [PATCH 3/4] spi: bcm2835aux: set up spi-mode before asserting
 cs-gpio
In-Reply-To: <1455041435-8015-4-git-send-email-stephanolbrich@gmx.de>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <1455041435-8015-4-git-send-email-stephanolbrich@gmx.de>
Message-ID: <87d1s54f7f.fsf@eliezer.anholt.net>

stephanolbrich at gmx.de writes:

> From: Stephan Olbrich <stephanolbrich at gmx.de>
>
> When using reverse polarity for clock (spi-cpol) on a device
> the clock line gets altered after chip-select has been asserted
> resulting in an additional clock beat, which confuses hardware.
>
> To avoid this situation this patch moves the setup of polarity
> (spi-cpol and spi-cpha) outside of the chip-select into
> prepare_message, which is run prior to asserting chip-select.

This patch surprised me.  I would have thought that the solution was to
just write the updated CNTL bits for CPOL and wait a moment whenever it
changes.  The CS only gets asserted later on when we get some data in
the TX FIFO, so I think you're just reducing the chance of losing the
race to get our inverted clock noticed by the device before the CS gets
asserted.

If we're only talking to a device that does an inverted clock, it seems
silly that we're resetting the hardware back to non-inverted clock after
every transfer/message.

I'd be OK with the patch anyway, since you reduce the number of resets
for a multi-transfer message, except for what I think is bug...

> Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
> ---
>  drivers/spi/spi-bcm2835aux.c | 54 +++++++++++++++++++++++++++++++-------------
>  1 file changed, 38 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
> index d2f0067..b90aa34 100644
> --- a/drivers/spi/spi-bcm2835aux.c
> +++ b/drivers/spi/spi-bcm2835aux.c    
> @@ -218,9 +218,9 @@ static irqreturn_t bcm2835aux_spi_interrupt(int irq, void *dev_id)
>  			BCM2835_AUX_SPI_CNTL1_IDLE);
>  	}
>  
> -	/* and if rx_len is 0 then wake up completion and disable spi */
> +	/* and if rx_len is 0 then disable interrupts and wake up completion */
>  	if (!bs->rx_len) {
> -		bcm2835aux_spi_reset_hw(bs);
> +		bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1]);
>  		complete(&master->xfer_completion);
>  	}
>  
> @@ -313,9 +313,6 @@ static int bcm2835aux_spi_transfer_one_poll(struct spi_master *master,
>  		}
>  	}
>  
> -	/* Transfer complete - reset SPI HW */
> -	bcm2835aux_spi_reset_hw(bs);
> -
>  	/* and return without waiting for completion */
>  	return 0;
>  }
> @@ -336,10 +333,6 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master,
>  	 * resulting (potentially) in more interrupts when transferring
>  	 * more than 12 bytes
>  	 */
> -	bs->cntl[0] = BCM2835_AUX_SPI_CNTL0_ENABLE |
> -		      BCM2835_AUX_SPI_CNTL0_VAR_WIDTH |
> -		      BCM2835_AUX_SPI_CNTL0_MSBF_OUT;
> -	bs->cntl[1] = BCM2835_AUX_SPI_CNTL1_MSBF_IN;
>  
>  	/* set clock */
>  	spi_hz = tfr->speed_hz;

Just below this block, we update cntl[0] with the transfer's speed bits,
so now that you're not resetting cntl[0] on each transfer, their speeds
will all get ORed all together by the end.  I think you could just mask
out the max speed before setting the new one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/014504fd/attachment.sig>

From eric at anholt.net  Tue Feb  9 16:13:06 2016
From: eric at anholt.net (Eric Anholt)
Date: Tue, 09 Feb 2016 16:13:06 -0800
Subject: [PATCH 4/4] spi: bcm2835aux: fix CPOL/CPHA setting
In-Reply-To: <1455041435-8015-5-git-send-email-stephanolbrich@gmx.de>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <1455041435-8015-5-git-send-email-stephanolbrich@gmx.de>
Message-ID: <87a8n94e3x.fsf@eliezer.anholt.net>

stephanolbrich at gmx.de writes:

> From: Stephan Olbrich <stephanolbrich at gmx.de>
>
> The auxiliary spi supports only CPHA=0 modes as the first bit is
> always output to the pin before the first clock cycle. In CPHA=1
> modes the first clock edge outputs the second bit hence the slave
> can never read the first bit.
>
> Also the CPHA registers switch between clocking data in/out on
> rising/falling edge hence depend on the CPOL setting.
>
> Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
> ---
>  drivers/spi/spi-bcm2835aux.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
> index b90aa34..169f521 100644
> --- a/drivers/spi/spi-bcm2835aux.c
> +++ b/drivers/spi/spi-bcm2835aux.c
> @@ -386,12 +386,12 @@ static int bcm2835aux_spi_prepare_message(struct spi_master *master,
>  	bs->cntl[1] = BCM2835_AUX_SPI_CNTL1_MSBF_IN;
>  
>  	/* handle all the modes */
> -	if (spi->mode & SPI_CPOL)
> +	if (spi->mode & SPI_CPOL) {
>  		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPOL;
> -	if (spi->mode & SPI_CPHA)
> -		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT |
> -			       BCM2835_AUX_SPI_CNTL0_CPHA_IN;
> -
> +		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT;
> +	} else {
> +		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_IN;
> +	}
>  	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1]);
>  	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL0, bs->cntl[0]);

(Note for other readers: A better name for CNTL0_CPHA_* would be
CNTL0_*_RISING).

I think you're right about not actually supporting CPHA.  I don't see
wany way to keep bit 1 out lasting through the first full clock cycle.
I think Stefan's right that we should drop CPHA from MODE_BITS
(actually, MODE_BITS would be nicer if we just merged it into its one
user, I think).

However, this hunk appears to be correct and would fix the timing of our
data going out in the CPOL=0 case and of sampling IN data for CPOL=1.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160209/c71b2207/attachment-0001.sig>

From vz at mleia.com  Tue Feb  9 16:19:03 2016
From: vz at mleia.com (Vladimir Zapolskiy)
Date: Wed, 10 Feb 2016 02:19:03 +0200
Subject: [PATCH 00/11] clk: lpc32xx: add clock support for NXP LPC32xx
In-Reply-To: <loom.20160209T215103-78@post.gmane.org>
References: <1447981511-29653-1-git-send-email-vz@mleia.com>
 <loom.20160209T215103-78@post.gmane.org>
Message-ID: <56BA81F7.4080006@mleia.com>

Hi Sylvain,

On 09.02.2016 23:01, Sylvain Lemieux wrote:
> Vladimir Zapolskiy <vz at ...> writes:
>>
>> This changeset adds common clock framework driver for NXP LPC32xx
>> boards.
> 
> Hi Vladimir,
> 
> Just to let you know that we did some testing using this changeset;
> I installed patches 4 to 7, 10 & 11 on top of 4.5-rc1.
> 
> I was able to run our software (SIC1 interrupt sources disable)
> without any problem a custom LPC32xx board.

this is a known issue, and I hope it will be fixed in upstream in v4.6,
the required changes in irqchip and gpiochip drivers were sent for
review some time ago, a bit more work is needed to 

Also 2-3 more clean-up changes in USB host and gadget drivers are done
locally (no more need to configure clocks out of the common clock
framework), but not yet submitted, will do it tomorrow.

> We did not get any problem with the clock signals we are using.
> 

Thank you for testing, I'm going to add your Tested-by tag (if you
don't mind) and submit a PR to ARM maintainers shortly.

>> Vladimir Zapolskiy (11):
>>   dt-bindings: clock: add description of LPC32xx clock controller
>>   dt-bindings: clock: add description of LPC32xx USB clock controller
>>   dt-bindings: clock: add NXP LPC32xx clock list for consumers
>>   arm: dts: lpc32xx: add device nodes for external oscillators
>>   arm: dts: lpc32xx: add clock controller device node
>>   arm: dts: lpc32xx: add clock properties to device nodes
>>   arm: dts: lpc32xx: add USB clock controller
>>   clk: lpc18xx: add NXP specific common clock framework selection
>>   clk: lpc32xx: add common clock framework driver
>>   arm: lpc32xx: switch to common clock framework
>>   arm: dts: lpc32xx: remove clock frequency property from UART device
>>     nodes
> 
> 

With best wishes,
Vladimir


From kuninori.morimoto.gx at renesas.com  Tue Feb  9 16:32:48 2016
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Wed, 10 Feb 2016 00:32:48 +0000
Subject: [PATCH 5/5] ARM: dts: r8a7794 add sound support
In-Reply-To: <56BA4B3D.1030301@cogentembedded.com>
References: <4253511.vvGjIdOnb6@wasted.cogentembedded.com>
 <2179456.HznTXDfKhZ@wasted.cogentembedded.com>
 <20160209195054.GA14008@verge.net.au>
 <56BA4B3D.1030301@cogentembedded.com>
Message-ID: <877fidtnm6.wl%kuninori.morimoto.gx@renesas.com>


Hi

> >> Define the generic R8A7794 part of  the sound device node.
> >> This sound device  is a complex one and comprises the Audio Clock Generator
> >> (ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
> >> (SSI[U]), and Audio DMAC-Peripheral-Peripheral.
> >> It is up  to the board file to enable the device.
> >>
> >> This patch is based on the R8A7791 sound work by Kuninori Morimoto.
> >>
> >> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> >>
> >> ---
(snip)
> > My reading of the documentation is that src0, 7, 8 and 9 are not
> > present on the r8a7794. I am referring to Figure 38.1b or r1.02 of
> > the R-Car Gen2 User's Manual.
> 
>    Indeed, thank you for the timely comment (I'm working on the series
> respin)! However, table 7A.12 still lists the SRC0/7/8/9 clocks for
> R8A7794, table 11.1 still lists SRC0/7/8/9 interrupts for R8A7794, and
> table 43.4 still lists SRC0/7/8/9 MID+RID for R8A7794 -- go figure...

Oops, current rsnd driver is assuming that DT has all channels.
This means it doesn't check src number itself.

Can you add src0, 7, 8, 9 with "non exist" comment ?
Otherwise, we need to modify driver, but I'm not sure how this assumption is deep.

Best regards
---
Kuninori Morimoto


From kuninori.morimoto.gx at renesas.com  Tue Feb  9 16:41:30 2016
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Wed, 10 Feb 2016 00:41:30 +0000
Subject: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
In-Reply-To: <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
 <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
Message-ID: <874mdhtn7d.wl%kuninori.morimoto.gx@renesas.com>


Hi Sergei

Sorry for my un-ordered response

> Define the generic R8A7794 part of  the sound device node.
> This sound device  is a complex one and comprises the Audio Clock Generator
> (ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
> (SSI[U]), and Audio DMAC-Peripheral-Peripheral.
> It is up  to the board file to enable the device.
> 
> This patch is based on the R8A7791 sound work by Kuninori Morimoto.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
(snip)
> +		rcar_sound,src {
> +			src1: src at 1 {
> +				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x87>, <&audma0 0x9c>;
> +				dma-names = "rx", "tx";
> +			};
> +			src2: src at 2 {
> +				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x89>, <&audma0 0x9e>;
> +				dma-names = "rx", "tx";
> +			};
> +			src3: src at 3 {
> +				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
> +				dma-names = "rx", "tx";
> +			};
> +			src4: src at 4 {
> +				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
> +				dma-names = "rx", "tx";
> +			};
> +			src5: src at 5 {
> +				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
> +				dma-names = "rx", "tx";
> +			};
> +			src6: src at 6 {
> +				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> +				dmas = <&audma0 0x91>, <&audma0 0xb4>;
> +				dma-names = "rx", "tx";
> +			};
> +		};

I think this can't work correctly, because driver is assuming
DT has all channles (from 0). (see linux/sound/soc/sh/rcar/src.c :: rsnd_src_probe)
Can you adds dummy src0 with some comments ? or fix src.c driver ?



From niklas.soderlund+renesas at ragnatech.se  Tue Feb  9 16:57:52 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Wed, 10 Feb 2016 01:57:52 +0100
Subject: [PATCH v3 2/8] dma-mapping: add {map,unmap}_resource to dma_map_ops
In-Reply-To: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455065878-11906-3-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Add methods to handle mapping of device resources from a physical
address. This is needed for example to map be able to map MMIO FIFO
registers to a IOMMU.

Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
---
 include/linux/dma-mapping.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 75857cd..e3aba4e 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -49,6 +49,12 @@ struct dma_map_ops {
 			 struct scatterlist *sg, int nents,
 			 enum dma_data_direction dir,
 			 struct dma_attrs *attrs);
+	dma_addr_t (*map_resource)(struct device *dev, phys_addr_t phys_addr,
+			       size_t size, enum dma_data_direction dir,
+			       struct dma_attrs *attrs);
+	void (*unmap_resource)(struct device *dev, dma_addr_t dma_handle,
+			   size_t size, enum dma_data_direction dir,
+			   struct dma_attrs *attrs);
 	void (*sync_single_for_cpu)(struct device *dev,
 				    dma_addr_t dma_handle, size_t size,
 				    enum dma_data_direction dir);
-- 
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb  9 16:57:53 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Wed, 10 Feb 2016 01:57:53 +0100
Subject: [PATCH v3 3/8] dma-mapping: add dma_{map,unmap}_resource
In-Reply-To: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455065878-11906-4-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Map/Unmap a device resource from a physical address. If no dma_map_ops
method is available the operation is a no-op.

Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
---
 include/linux/dma-mapping.h | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index e3aba4e..21bf986 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -216,6 +216,33 @@ static inline void dma_unmap_page(struct device *dev, dma_addr_t addr,
 	debug_dma_unmap_page(dev, addr, size, dir, false);
 }
 
+static inline dma_addr_t dma_map_resource(struct device *dev,
+					  phys_addr_t phys_addr,
+					  size_t size,
+					  enum dma_data_direction dir,
+					  struct dma_attrs *attrs)
+{
+	struct dma_map_ops *ops = get_dma_ops(dev);
+
+	BUG_ON(!valid_dma_direction(dir));
+	if (ops->map_resource)
+		return ops->map_resource(dev, phys_addr, size, dir, attrs);
+
+	return phys_addr;
+}
+
+static inline void dma_unmap_resource(struct device *dev, dma_addr_t addr,
+				      size_t size, enum dma_data_direction dir,
+				      struct dma_attrs *attrs)
+{
+	struct dma_map_ops *ops = get_dma_ops(dev);
+
+	BUG_ON(!valid_dma_direction(dir));
+	if (ops->unmap_resource)
+		ops->unmap_resource(dev, addr, size, dir, attrs);
+
+}
+
 static inline void dma_sync_single_for_cpu(struct device *dev, dma_addr_t addr,
 					   size_t size,
 					   enum dma_data_direction dir)
-- 
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb  9 16:57:51 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Wed, 10 Feb 2016 01:57:51 +0100
Subject: [PATCH v3 1/8] iommu: Add MMIO mapping type
In-Reply-To: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455065878-11906-2-git-send-email-niklas.soderlund+renesas@ragnatech.se>

From: Robin Murphy <robin.murphy at arm.com>

On some platforms, MMIO regions might need slightly different treatment
compared to mapping regular memory; add the notion of MMIO mappings to
the IOMMU API's memory type flags, so that callers can let the IOMMU
drivers know to do the right thing.

Signed-off-by: Robin Murphy <robin.murphy at arm.com>
Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
 drivers/iommu/io-pgtable-arm.c | 4 +++-
 include/linux/iommu.h          | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 381ca5a..3ff4f87 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -364,7 +364,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data,
 			pte |= ARM_LPAE_PTE_HAP_READ;
 		if (prot & IOMMU_WRITE)
 			pte |= ARM_LPAE_PTE_HAP_WRITE;
-		if (prot & IOMMU_CACHE)
+		if (prot & IOMMU_MMIO)
+			pte |= ARM_LPAE_PTE_MEMATTR_DEV;
+		else if (prot & IOMMU_CACHE)
 			pte |= ARM_LPAE_PTE_MEMATTR_OIWB;
 		else
 			pte |= ARM_LPAE_PTE_MEMATTR_NC;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index a5c539f..34b6432 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -30,6 +30,7 @@
 #define IOMMU_WRITE	(1 << 1)
 #define IOMMU_CACHE	(1 << 2) /* DMA cache coherency */
 #define IOMMU_NOEXEC	(1 << 3)
+#define IOMMU_MMIO	(1 << 4) /* e.g. things like MSI doorbells */
 
 struct iommu_ops;
 struct iommu_group;
-- 
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb  9 16:57:54 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Wed, 10 Feb 2016 01:57:54 +0100
Subject: [PATCH v3 4/8] arm: dma-mapping: add {map,
 unmap}_resource for iommu ops
In-Reply-To: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455065878-11906-5-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Add methods to map/unmap device resources addresses for dma_map_ops that
are IOMMU aware. This is needed to map a device MMIO register from a
physical address.

Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
---
 arch/arm/mm/dma-mapping.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 0eca381..ae2b175 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1814,6 +1814,63 @@ static void arm_iommu_unmap_page(struct device *dev, dma_addr_t handle,
 	__free_iova(mapping, iova, len);
 }
 
+/**
+ * arm_iommu_map_resource - map a device resource for DMA
+ * @dev: valid struct device pointer
+ * @phys_addr: physical address of resource
+ * @size: size of resource to map
+ * @dir: DMA transfer direction
+ */
+static dma_addr_t arm_iommu_map_resource(struct device *dev,
+		phys_addr_t phys_addr, size_t size,
+		enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+	dma_addr_t dma_addr;
+	int ret, prot;
+	phys_addr_t addr = phys_addr & PAGE_MASK;
+	int offset = phys_addr & ~PAGE_MASK;
+	int len = PAGE_ALIGN(size + offset);
+
+	dma_addr = __alloc_iova(mapping, size);
+	if (dma_addr == DMA_ERROR_CODE)
+		return dma_addr;
+
+	prot = __dma_direction_to_prot(dir) | IOMMU_MMIO;
+
+	ret = iommu_map(mapping->domain, dma_addr, addr, len, prot);
+	if (ret < 0)
+		goto fail;
+
+	return dma_addr + offset;
+fail:
+	__free_iova(mapping, dma_addr, size);
+	return DMA_ERROR_CODE;
+}
+
+/**
+ * arm_iommu_unmap_resource - unmap a device DMA resource
+ * @dev: valid struct device pointer
+ * @dma_handle: DMA address to resource
+ * @size: size of resource to map
+ * @dir: DMA transfer direction
+ */
+static void arm_iommu_unmap_resource(struct device *dev, dma_addr_t dma_handle,
+		size_t size, enum dma_data_direction dir,
+		struct dma_attrs *attrs)
+{
+	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+	dma_addr_t iova = dma_handle & PAGE_MASK;
+	int offset = dma_handle & ~PAGE_MASK;
+	int len = PAGE_ALIGN(size + offset);
+
+	if (!iova)
+		return;
+
+	iommu_unmap(mapping->domain, iova, len);
+	__free_iova(mapping, iova, len);
+}
+
 static void arm_iommu_sync_single_for_cpu(struct device *dev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
@@ -1858,6 +1915,9 @@ struct dma_map_ops iommu_ops = {
 	.sync_sg_for_cpu	= arm_iommu_sync_sg_for_cpu,
 	.sync_sg_for_device	= arm_iommu_sync_sg_for_device,
 
+	.map_resource		= arm_iommu_map_resource,
+	.unmap_resource		= arm_iommu_unmap_resource,
+
 	.set_dma_mask		= arm_dma_set_mask,
 };
 
@@ -1873,6 +1933,9 @@ struct dma_map_ops iommu_coherent_ops = {
 	.map_sg		= arm_coherent_iommu_map_sg,
 	.unmap_sg	= arm_coherent_iommu_unmap_sg,
 
+	.map_resource	= arm_iommu_map_resource,
+	.unmap_resource	= arm_iommu_unmap_resource,
+
 	.set_dma_mask	= arm_dma_set_mask,
 };
 
-- 
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb  9 16:57:50 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Wed, 10 Feb 2016 01:57:50 +0100
Subject: [PATCH v3 0/8] dmaengine: rcar-dmac: add iommu support for slave
 transfers
Message-ID: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Hi,

This series add iommu support to rcar-dmac. It's tested on koelsch with
CONFIG_IPMMU_VMSA and by enabling the ipmmu_ds node in r8a7791.dtsi. I
verified operation by interacting with /dev/mmcblk1  which is a device
behind the iommu.

The series depends on out of tree patch '[PATCH] dmaengine: use
phys_addr_t for slave configuration' which currently is under review.

* Changes since v2
- Drop patch to add dma_{map,unmap}_page_attrs.
- Add dma_{map,unmap}_resource to handle the mapping without involving a
  'struct page'. Thanks Laurent and Robin for pointing this out.
- Use size instead of address to keep track of if a mapping exist or not
  since addr == 0 is valid. Thanks Laurent.
- Pick up patch from Robin with Laurents ack (hope it's OK for me to
  attach the ack?) to add IOMMU_MMIO.
- Fix bug in rcar_dmac_device_config where the error check where
  inverted.
- Use DMA_BIDIRECTIONAL in rcar_dmac_device_config since we at that
  point can't be sure what direction the mapping is going to be used.

* Changes since v1
- Add and use a dma_{map,unmap}_page_attrs to be able to map the page
  using attributes DMA_ATTR_NO_KERNEL_MAPPING and
  DMA_ATTR_SKIP_CPU_SYNC. Thanks Laurent.
- Drop check if dmac is part of a iommu group or not, let the DMA
  mapping api handle it.
- Move slave configuration data around in rcar-dmac to avoid code
  duplication.
- Fix build issue reported by 'kbuild test robot' regarding phys_to_page
  not availability on some configurations.
- Add DT information for r8a7791.

* Changes since RFC
- Switch to use the dma-mapping api instead of using the iommu_map()
  directly. Turns out the dma-mapper is much smarter then me...
- Dropped the patch to expose domain->ops->pgsize_bitmap from within the
  iommu api.
- Dropped the patch showing how I tested the RFC.

Niklas S?derlund (7):
  dma-mapping: add {map,unmap}_resource to dma_map_ops
  dma-mapping: add dma_{map,unmap}_resource
  arm: dma-mapping: add {map,unmap}_resource for iommu ops
  dmaengine: rcar-dmac: group slave configuration
  dmaengine: rcar-dmac: add iommu support for slave transfers
  ARM: dts: r8a7790: add iommus to dmac0 and dmac1
  ARM: dts: r8a7791: add iommus to dmac0 and dmac1

Robin Murphy (1):
  iommu: Add MMIO mapping type

 arch/arm/boot/dts/r8a7790.dtsi | 30 +++++++++++++++
 arch/arm/boot/dts/r8a7791.dtsi | 30 +++++++++++++++
 arch/arm/mm/dma-mapping.c      | 63 +++++++++++++++++++++++++++++++
 drivers/dma/sh/rcar-dmac.c     | 86 +++++++++++++++++++++++++++++++++---------
 drivers/iommu/io-pgtable-arm.c |  4 +-
 include/linux/dma-mapping.h    | 33 ++++++++++++++++
 include/linux/iommu.h          |  1 +
 7 files changed, 229 insertions(+), 18 deletions(-)

--
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb  9 16:57:56 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Wed, 10 Feb 2016 01:57:56 +0100
Subject: [PATCH v3 6/8] dmaengine: rcar-dmac: add iommu support for slave
 transfers
In-Reply-To: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455065878-11906-7-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Enable slave transfers to devices behind IPMMU:s by mapping the slave
addresses using the dma-mapping API.

Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
---
 drivers/dma/sh/rcar-dmac.c | 57 ++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 52 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index 743873c..268407c 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -1106,21 +1106,68 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
 	return desc;
 }
 
+static int rcar_dmac_set_slave_addr(struct dma_chan *chan,
+				     struct rcar_dmac_chan_slave *slave,
+				     phys_addr_t addr, size_t size)
+{
+	struct dma_attrs attrs;
+	enum dma_data_direction dir;
+
+	init_dma_attrs(&attrs);
+	dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &attrs);
+	dma_set_attr(DMA_ATTR_SKIP_CPU_SYNC, &attrs);
+
+	/*
+	 * We can't know the direction at this time, see documentation for
+	 * 'direction' in struct dma_slave_config.
+	 */
+	dir = DMA_BIDIRECTIONAL;
+
+	if (slave->xfer_size) {
+		dma_unmap_resource(chan->device->dev, slave->slave_addr,
+				slave->xfer_size, dir, &attrs);
+		slave->slave_addr = 0;
+		slave->xfer_size = 0;
+	}
+
+	if (size) {
+		slave->slave_addr = dma_map_resource(chan->device->dev, addr,
+				size, dir, &attrs);
+
+		if (dma_mapping_error(chan->device->dev, slave->slave_addr)) {
+			struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
+
+			dev_err(chan->device->dev,
+					"chan%u: failed to map %zx@%pap",
+					rchan->index, size, &addr);
+			return -EIO;
+		}
+
+		slave->xfer_size = size;
+	}
+
+	return 0;
+}
+
 static int rcar_dmac_device_config(struct dma_chan *chan,
 				   struct dma_slave_config *cfg)
 {
 	struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
+	int ret;
 
 	/*
 	 * We could lock this, but you shouldn't be configuring the
 	 * channel, while using it...
 	 */
-	rchan->src.slave_addr = cfg->src_addr;
-	rchan->dst.slave_addr = cfg->dst_addr;
-	rchan->src.xfer_size = cfg->src_addr_width;
-	rchan->dst.xfer_size = cfg->dst_addr_width;
 
-	return 0;
+	ret = rcar_dmac_set_slave_addr(chan, &rchan->src, cfg->src_addr,
+			cfg->src_addr_width);
+	if (ret)
+		return ret;
+
+	ret = rcar_dmac_set_slave_addr(chan, &rchan->dst, cfg->dst_addr,
+			cfg->dst_addr_width);
+	return ret;
 }
 
 static int rcar_dmac_chan_terminate_all(struct dma_chan *chan)
-- 
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb  9 16:57:58 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Wed, 10 Feb 2016 01:57:58 +0100
Subject: [PATCH v3 8/8] ARM: dts: r8a7791: add iommus to dmac0 and dmac1
In-Reply-To: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455065878-11906-9-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
---
 arch/arm/boot/dts/r8a7791.dtsi | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 2a369dd..6dff061 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -283,6 +283,21 @@
 		power-domains = <&cpg_clocks>;
 		#dma-cells = <1>;
 		dma-channels = <15>;
+		iommus = <&ipmmu_ds 0>,
+			 <&ipmmu_ds 1>,
+			 <&ipmmu_ds 2>,
+			 <&ipmmu_ds 3>,
+			 <&ipmmu_ds 4>,
+			 <&ipmmu_ds 5>,
+			 <&ipmmu_ds 6>,
+			 <&ipmmu_ds 7>,
+			 <&ipmmu_ds 8>,
+			 <&ipmmu_ds 9>,
+			 <&ipmmu_ds 10>,
+			 <&ipmmu_ds 11>,
+			 <&ipmmu_ds 12>,
+			 <&ipmmu_ds 13>,
+			 <&ipmmu_ds 14>;
 	};
 
 	dmac1: dma-controller at e6720000 {
@@ -314,6 +329,21 @@
 		power-domains = <&cpg_clocks>;
 		#dma-cells = <1>;
 		dma-channels = <15>;
+		iommus = <&ipmmu_ds 15>,
+			 <&ipmmu_ds 16>,
+			 <&ipmmu_ds 17>,
+			 <&ipmmu_ds 18>,
+			 <&ipmmu_ds 19>,
+			 <&ipmmu_ds 20>,
+			 <&ipmmu_ds 21>,
+			 <&ipmmu_ds 22>,
+			 <&ipmmu_ds 23>,
+			 <&ipmmu_ds 24>,
+			 <&ipmmu_ds 25>,
+			 <&ipmmu_ds 26>,
+			 <&ipmmu_ds 27>,
+			 <&ipmmu_ds 28>,
+			 <&ipmmu_ds 29>;
 	};
 
 	audma0: dma-controller at ec700000 {
-- 
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb  9 16:57:55 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Wed, 10 Feb 2016 01:57:55 +0100
Subject: [PATCH v3 5/8] dmaengine: rcar-dmac: group slave configuration
In-Reply-To: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455065878-11906-6-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Group slave address and transfer size in own structs for source and
destination. This is in preparation for hooking up the dma-mapping API
to the slave addresses.

Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
---
 drivers/dma/sh/rcar-dmac.c | 37 +++++++++++++++++++++----------------
 1 file changed, 21 insertions(+), 16 deletions(-)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index 7820d07..743873c 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -118,14 +118,21 @@ struct rcar_dmac_desc_page {
 	sizeof(struct rcar_dmac_xfer_chunk))
 
 /*
+ * @slave_addr: slave memory address
+ * @xfer_size: size (in bytes) of hardware transfers
+ */
+struct rcar_dmac_chan_slave {
+	dma_addr_t slave_addr;
+	unsigned int xfer_size;
+};
+
+/*
  * struct rcar_dmac_chan - R-Car Gen2 DMA Controller Channel
  * @chan: base DMA channel object
  * @iomem: channel I/O memory base
  * @index: index of this channel in the controller
- * @src_xfer_size: size (in bytes) of hardware transfers on the source side
- * @dst_xfer_size: size (in bytes) of hardware transfers on the destination side
- * @src_slave_addr: slave source memory address
- * @dst_slave_addr: slave destination memory address
+ * @src: slave memory address and size on the source side
+ * @dst: slave memory address and size on the destination side
  * @mid_rid: hardware MID/RID for the DMA client using this channel
  * @lock: protects the channel CHCR register and the desc members
  * @desc.free: list of free descriptors
@@ -142,10 +149,8 @@ struct rcar_dmac_chan {
 	void __iomem *iomem;
 	unsigned int index;
 
-	unsigned int src_xfer_size;
-	unsigned int dst_xfer_size;
-	dma_addr_t src_slave_addr;
-	dma_addr_t dst_slave_addr;
+	struct rcar_dmac_chan_slave src;
+	struct rcar_dmac_chan_slave dst;
 	int mid_rid;
 
 	spinlock_t lock;
@@ -793,13 +798,13 @@ static void rcar_dmac_chan_configure_desc(struct rcar_dmac_chan *chan,
 	case DMA_DEV_TO_MEM:
 		chcr = RCAR_DMACHCR_DM_INC | RCAR_DMACHCR_SM_FIXED
 		     | RCAR_DMACHCR_RS_DMARS;
-		xfer_size = chan->src_xfer_size;
+		xfer_size = chan->src.xfer_size;
 		break;
 
 	case DMA_MEM_TO_DEV:
 		chcr = RCAR_DMACHCR_DM_FIXED | RCAR_DMACHCR_SM_INC
 		     | RCAR_DMACHCR_RS_DMARS;
-		xfer_size = chan->dst_xfer_size;
+		xfer_size = chan->dst.xfer_size;
 		break;
 
 	case DMA_MEM_TO_MEM:
@@ -1038,7 +1043,7 @@ rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 	}
 
 	dev_addr = dir == DMA_DEV_TO_MEM
-		 ? rchan->src_slave_addr : rchan->dst_slave_addr;
+		 ? rchan->src.slave_addr : rchan->dst.slave_addr;
 	return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
 				      dir, flags, false);
 }
@@ -1093,7 +1098,7 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
 	}
 
 	dev_addr = dir == DMA_DEV_TO_MEM
-		 ? rchan->src_slave_addr : rchan->dst_slave_addr;
+		 ? rchan->src.slave_addr : rchan->dst.slave_addr;
 	desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
 				      dir, flags, true);
 
@@ -1110,10 +1115,10 @@ static int rcar_dmac_device_config(struct dma_chan *chan,
 	 * We could lock this, but you shouldn't be configuring the
 	 * channel, while using it...
 	 */
-	rchan->src_slave_addr = cfg->src_addr;
-	rchan->dst_slave_addr = cfg->dst_addr;
-	rchan->src_xfer_size = cfg->src_addr_width;
-	rchan->dst_xfer_size = cfg->dst_addr_width;
+	rchan->src.slave_addr = cfg->src_addr;
+	rchan->dst.slave_addr = cfg->dst_addr;
+	rchan->src.xfer_size = cfg->src_addr_width;
+	rchan->dst.xfer_size = cfg->dst_addr_width;
 
 	return 0;
 }
-- 
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb  9 16:57:57 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Wed, 10 Feb 2016 01:57:57 +0100
Subject: [PATCH v3 7/8] ARM: dts: r8a7790: add iommus to dmac0 and dmac1
In-Reply-To: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455065878-11906-8-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
---
 arch/arm/boot/dts/r8a7790.dtsi | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 7dfd393..048bbf8 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -294,6 +294,21 @@
 		power-domains = <&cpg_clocks>;
 		#dma-cells = <1>;
 		dma-channels = <15>;
+		iommus = <&ipmmu_ds 0>,
+			 <&ipmmu_ds 1>,
+			 <&ipmmu_ds 2>,
+			 <&ipmmu_ds 3>,
+			 <&ipmmu_ds 4>,
+			 <&ipmmu_ds 5>,
+			 <&ipmmu_ds 6>,
+			 <&ipmmu_ds 7>,
+			 <&ipmmu_ds 8>,
+			 <&ipmmu_ds 9>,
+			 <&ipmmu_ds 10>,
+			 <&ipmmu_ds 11>,
+			 <&ipmmu_ds 12>,
+			 <&ipmmu_ds 13>,
+			 <&ipmmu_ds 14>;
 	};
 
 	dmac1: dma-controller at e6720000 {
@@ -325,6 +340,21 @@
 		power-domains = <&cpg_clocks>;
 		#dma-cells = <1>;
 		dma-channels = <15>;
+		iommus = <&ipmmu_ds 15>,
+			 <&ipmmu_ds 16>,
+			 <&ipmmu_ds 17>,
+			 <&ipmmu_ds 18>,
+			 <&ipmmu_ds 19>,
+			 <&ipmmu_ds 20>,
+			 <&ipmmu_ds 21>,
+			 <&ipmmu_ds 22>,
+			 <&ipmmu_ds 23>,
+			 <&ipmmu_ds 24>,
+			 <&ipmmu_ds 25>,
+			 <&ipmmu_ds 26>,
+			 <&ipmmu_ds 27>,
+			 <&ipmmu_ds 28>,
+			 <&ipmmu_ds 29>;
 	};
 
 	audma0: dma-controller at ec700000 {
-- 
2.7.1



From s-anna at ti.com  Tue Feb  9 17:42:34 2016
From: s-anna at ti.com (Suman Anna)
Date: Tue, 9 Feb 2016 19:42:34 -0600
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
Message-ID: <56BA958A.1020503@ti.com>

Hi Paul,

On 02/09/2016 01:36 PM, Paul Walmsley wrote:
> Hi Suman 
> 
> On Tue, 9 Feb 2016, Suman Anna wrote:
> 
>> On 02/09/2016 02:49 AM, Paul Walmsley wrote:
>>> On Mon, 8 Feb 2016, Suman Anna wrote:
>>>> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
>>>>> On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:
>>>>>
>>>>>> Paul, what do you think is the best way forward to perform reset?
>>>>>
>>>>> Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
>>>>> Those often need special reset handling to ensure that WFI/HLT-like 
>>>>> instructions are executed after reset.  This special handling ensures that 
>>>>> the IP blocks' bus initiator interfaces indicate that they are in standby 
>>>>> to the PRCM - thus allowing power management for the rest of the chip to 
>>>>> work correctly.
>>>>>
>>>>> But that doesn't seem to be the case with PCIe - and maybe others - 
>>>>> possibly some of the MMUs?  
>>>>
>>>> Yeah, the sequencing between clocks and resets would still be the same
>>>> for MMUs, so, adding the custom flags for MMUs is fine.
>>>
>>> I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs.  
>>> We've stated that the main point of the custom hardreset code is to handle 
>>> processors that need to be placed into WFI/HLT, but it doesn't seem like 
>>> there would be an equivalent for MMUs.  Thoughts?
>>
>> The current OMAP IOMMU code already leverages the pdata ops for
>> performing the resets, so not adding the flags would also require
>> additional changes in the driver.
>>
>> Also, the reset lines controlling the MMUs actually also manage the
>> reset for all the other sub-modules other than the processor cores
>> within the sub-systems. We have currently different issues (see [1] for
>> eg. around the IPU sub-system entering RET in between), so from a PM
>> point of view, we do prefer to place the MMUs also in reset when we are
>> runtime suspended.
> 
> Should we reassert hardreset in _idle() for IP blocks that don't have 
> HWMOD_CUSTOM_HARDRESET set on them?  Would that allow us to use this 
> mechanism for the uncore hardreset lines, or are there other quirks?
> 
> Also - would that address the potential issue that you mentioned with the 
> PCIe block, or is that a different issue?

Yeah, I think that would address the PCIe block issue in terms of reset
state balancing between pm_runtime_get_sync() and pm_runtime_put()
calls. Right now, they are unbalanced. The PCIe block is using these
only in probe and remove, so it should work for that IP.

The IPUs and DSPs in general would also place the reset lines asserted
when suspended, as the power up sequence almost always involves
releasing a reset line with the boot-up code on the processor detecting
that it is a power restore boot.

regards
Suman



From ezequiel at vanguardiasur.com.ar  Tue Feb  9 17:54:24 2016
From: ezequiel at vanguardiasur.com.ar (Ezequiel Garcia)
Date: Tue,  9 Feb 2016 22:54:24 -0300
Subject: [PATCH v2 0/3] lpc32xx clockevent: Support periodic mode and ARM
 delay timer
Message-ID: <1455069267-4784-1-git-send-email-ezequiel@vanguardiasur.com.ar>

This patchset introduces periodic timer mode. As was discussed on v1,
the current implementation (MR0=1, PR=ticks) is not suitable for
implementing a periodoc timer mode.

This can be seen with a very simple test, by counting the number of
interrupts during 1-second.

Implementing the periodic timer mode with MR0=1, PR=ticks_per_jiffy
results in half the expected number of interrupts (CONFIG_HZ=100):

(See: http://git.infradead.org/users/ezequielg/linux/shortlog/refs/heads/lpc32xx_periodic_with_pr)

$ cat /proc/interrupts | grep clockevent && sleep 1 && cat /proc/interrupts | grep clockevent
 16:        846  nvic_irq  13 Edge      lpc3220 clockevent
 16:        900  nvic_irq  13 Edge      lpc3220 clockevent

On the other side, with this patchset the number of interrupts
is closer to the expected:

$ cat /proc/interrupts | grep clockevent && sleep 1 && cat /proc/interrupts | grep clockevent
 16:       1580  nvic_irq  13 Edge      lpc3220 clockevent
 16:       1688  nvic_irq  13 Edge      lpc3220 clockevent

Therefore, the first patch switches the timer one-shot implementation
to use PR=0 and MR0=ticks. The second patch implements periodic mode
using this.

The last patch adds support for the ARM delay timer, which is used
for udelay and also to skip the delay loop calibration.

Ezequiel Garcia (3):
  clocksource/drivers/lpc32xx: Don't use the prescaler counter for
    clockevents
  clocksource/drivers/lpc32xx: Support periodic mode
  clocksource/drivers/lpc32xx: Support timer-based ARM delay

 drivers/clocksource/Kconfig        |  1 +
 drivers/clocksource/time-lpc32xx.c | 66 ++++++++++++++++++++++++++++++--------
 2 files changed, 54 insertions(+), 13 deletions(-)

-- 
2.7.0



From ezequiel at vanguardiasur.com.ar  Tue Feb  9 17:54:25 2016
From: ezequiel at vanguardiasur.com.ar (Ezequiel Garcia)
Date: Tue,  9 Feb 2016 22:54:25 -0300
Subject: [PATCH v2 1/3] clocksource/drivers/lpc32xx: Don't use the prescaler
 counter for clockevents
In-Reply-To: <1455069267-4784-1-git-send-email-ezequiel@vanguardiasur.com.ar>
References: <1455069267-4784-1-git-send-email-ezequiel@vanguardiasur.com.ar>
Message-ID: <1455069267-4784-2-git-send-email-ezequiel@vanguardiasur.com.ar>

This commit switches the clockevents one-shot current implementation
to avoid using the prescaler counter. The clockevents timer currently
uses MR0=1, PR=ticks; and after this commit is uses MR0=ticks, PR=0.

While using the prescaler with PR=1 works fine in one-shot mode,
it seems it doesn't work as expected in periodic mode.

By using the only match channel register (MR0) for the timer we make
the periodic mode introduction easier, and consistent with one-shot mode.

Signed-off-by: Ezequiel Garcia <ezequiel at vanguardiasur.com.ar>
---
 drivers/clocksource/time-lpc32xx.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/clocksource/time-lpc32xx.c b/drivers/clocksource/time-lpc32xx.c
index 1316876b487a..50d1a63cbe1e 100644
--- a/drivers/clocksource/time-lpc32xx.c
+++ b/drivers/clocksource/time-lpc32xx.c
@@ -60,14 +60,13 @@ static int lpc32xx_clkevt_next_event(unsigned long delta,
 		container_of(evtdev, struct lpc32xx_clock_event_ddata, evtdev);
 
 	/*
-	 * Place timer in reset and program the delta in the prescale
-	 * register (PR). When the prescale counter matches the value
-	 * in PR the counter register is incremented and the compare
-	 * match will trigger. After setup the timer is released from
-	 * reset and enabled.
+	 * Place timer in reset and program the delta in the match
+	 * channel 0 (MR0). When the timer counter matches the value
+	 * in MR0 register the match will trigger an interrupt.
+	 * After setup the timer is released from reset and enabled.
 	 */
 	writel_relaxed(LPC32XX_TIMER_TCR_CRST, ddata->base + LPC32XX_TIMER_TCR);
-	writel_relaxed(delta, ddata->base + LPC32XX_TIMER_PR);
+	writel_relaxed(delta, ddata->base + LPC32XX_TIMER_MR0);
 	writel_relaxed(LPC32XX_TIMER_TCR_CEN, ddata->base + LPC32XX_TIMER_TCR);
 
 	return 0;
@@ -210,13 +209,13 @@ static int __init lpc32xx_clockevent_init(struct device_node *np)
 
 	/*
 	 * Disable timer and clear any pending interrupt (IR) on match
-	 * channel 0 (MR0). Configure a compare match value of 1 on MR0
-	 * and enable interrupt, reset on match and stop on match (MCR).
+	 * channel 0 (MR0). Clear the prescaler as it's not used.
+	 * Enable interrupt, reset on match and stop on match (MCR).
 	 */
 	writel_relaxed(0, base + LPC32XX_TIMER_TCR);
+	writel_relaxed(0, base + LPC32XX_TIMER_PR);
 	writel_relaxed(0, base + LPC32XX_TIMER_CTCR);
 	writel_relaxed(LPC32XX_TIMER_IR_MR0INT, base + LPC32XX_TIMER_IR);
-	writel_relaxed(1, base + LPC32XX_TIMER_MR0);
 	writel_relaxed(LPC32XX_TIMER_MCR_MR0I | LPC32XX_TIMER_MCR_MR0R |
 		       LPC32XX_TIMER_MCR_MR0S, base + LPC32XX_TIMER_MCR);
 
-- 
2.7.0



From ezequiel at vanguardiasur.com.ar  Tue Feb  9 17:54:26 2016
From: ezequiel at vanguardiasur.com.ar (Ezequiel Garcia)
Date: Tue,  9 Feb 2016 22:54:26 -0300
Subject: [PATCH v2 2/3] clocksource/drivers/lpc32xx: Support periodic mode
In-Reply-To: <1455069267-4784-1-git-send-email-ezequiel@vanguardiasur.com.ar>
References: <1455069267-4784-1-git-send-email-ezequiel@vanguardiasur.com.ar>
Message-ID: <1455069267-4784-3-git-send-email-ezequiel@vanguardiasur.com.ar>

This commit adds the support for periodic mode. This is done by not
setting the MR0S (Stop on TnMR0) bit on MCR, thus allowing
interrupts to be periodically generated on MR0 matches.

In order to do this, move the initial configuration that is specific to
the one-shot mode to set_state_oneshot().

Signed-off-by: Ezequiel Garcia <ezequiel at vanguardiasur.com.ar>
---
 drivers/clocksource/time-lpc32xx.c | 39 +++++++++++++++++++++++++++++++++-----
 1 file changed, 34 insertions(+), 5 deletions(-)

diff --git a/drivers/clocksource/time-lpc32xx.c b/drivers/clocksource/time-lpc32xx.c
index 50d1a63cbe1e..5694eddade15 100644
--- a/drivers/clocksource/time-lpc32xx.c
+++ b/drivers/clocksource/time-lpc32xx.c
@@ -43,6 +43,7 @@
 struct lpc32xx_clock_event_ddata {
 	struct clock_event_device evtdev;
 	void __iomem *base;
+	u32 ticks_per_jiffy;
 };
 
 /* Needed for the sched clock */
@@ -85,11 +86,39 @@ static int lpc32xx_clkevt_shutdown(struct clock_event_device *evtdev)
 
 static int lpc32xx_clkevt_oneshot(struct clock_event_device *evtdev)
 {
+	struct lpc32xx_clock_event_ddata *ddata =
+		container_of(evtdev, struct lpc32xx_clock_event_ddata, evtdev);
+
 	/*
 	 * When using oneshot, we must also disable the timer
 	 * to wait for the first call to set_next_event().
 	 */
-	return lpc32xx_clkevt_shutdown(evtdev);
+	writel_relaxed(0, ddata->base + LPC32XX_TIMER_TCR);
+
+	/* Enable interrupt, reset on match and stop on match (MCR). */
+	writel_relaxed(LPC32XX_TIMER_MCR_MR0I | LPC32XX_TIMER_MCR_MR0R |
+		       LPC32XX_TIMER_MCR_MR0S, ddata->base + LPC32XX_TIMER_MCR);
+	return 0;
+}
+
+static int lpc32xx_clkevt_periodic(struct clock_event_device *evtdev)
+{
+	struct lpc32xx_clock_event_ddata *ddata =
+		container_of(evtdev, struct lpc32xx_clock_event_ddata, evtdev);
+
+	/* Enable interrupt and reset on match. */
+	writel_relaxed(LPC32XX_TIMER_MCR_MR0I | LPC32XX_TIMER_MCR_MR0R,
+		       ddata->base + LPC32XX_TIMER_MCR);
+
+	/*
+	 * Place timer in reset and program the delta in the match
+	 * channel 0 (MR0).
+	 */
+	writel_relaxed(LPC32XX_TIMER_TCR_CRST, ddata->base + LPC32XX_TIMER_TCR);
+	writel_relaxed(ddata->ticks_per_jiffy, ddata->base + LPC32XX_TIMER_MR0);
+	writel_relaxed(LPC32XX_TIMER_TCR_CEN, ddata->base + LPC32XX_TIMER_TCR);
+
+	return 0;
 }
 
 static irqreturn_t lpc32xx_clock_event_handler(int irq, void *dev_id)
@@ -107,11 +136,13 @@ static irqreturn_t lpc32xx_clock_event_handler(int irq, void *dev_id)
 static struct lpc32xx_clock_event_ddata lpc32xx_clk_event_ddata = {
 	.evtdev = {
 		.name			= "lpc3220 clockevent",
-		.features		= CLOCK_EVT_FEAT_ONESHOT,
+		.features		= CLOCK_EVT_FEAT_ONESHOT |
+					  CLOCK_EVT_FEAT_PERIODIC,
 		.rating			= 300,
 		.set_next_event		= lpc32xx_clkevt_next_event,
 		.set_state_shutdown	= lpc32xx_clkevt_shutdown,
 		.set_state_oneshot	= lpc32xx_clkevt_oneshot,
+		.set_state_periodic	= lpc32xx_clkevt_periodic,
 	},
 };
 
@@ -210,17 +241,15 @@ static int __init lpc32xx_clockevent_init(struct device_node *np)
 	/*
 	 * Disable timer and clear any pending interrupt (IR) on match
 	 * channel 0 (MR0). Clear the prescaler as it's not used.
-	 * Enable interrupt, reset on match and stop on match (MCR).
 	 */
 	writel_relaxed(0, base + LPC32XX_TIMER_TCR);
 	writel_relaxed(0, base + LPC32XX_TIMER_PR);
 	writel_relaxed(0, base + LPC32XX_TIMER_CTCR);
 	writel_relaxed(LPC32XX_TIMER_IR_MR0INT, base + LPC32XX_TIMER_IR);
-	writel_relaxed(LPC32XX_TIMER_MCR_MR0I | LPC32XX_TIMER_MCR_MR0R |
-		       LPC32XX_TIMER_MCR_MR0S, base + LPC32XX_TIMER_MCR);
 
 	rate = clk_get_rate(clk);
 	lpc32xx_clk_event_ddata.base = base;
+	lpc32xx_clk_event_ddata.ticks_per_jiffy = DIV_ROUND_CLOSEST(rate, HZ);
 	clockevents_config_and_register(&lpc32xx_clk_event_ddata.evtdev,
 					rate, 1, -1);
 
-- 
2.7.0



From ezequiel at vanguardiasur.com.ar  Tue Feb  9 17:54:27 2016
From: ezequiel at vanguardiasur.com.ar (Ezequiel Garcia)
Date: Tue,  9 Feb 2016 22:54:27 -0300
Subject: [PATCH v2 3/3] clocksource/drivers/lpc32xx: Support timer-based ARM
 delay
In-Reply-To: <1455069267-4784-1-git-send-email-ezequiel@vanguardiasur.com.ar>
References: <1455069267-4784-1-git-send-email-ezequiel@vanguardiasur.com.ar>
Message-ID: <1455069267-4784-4-git-send-email-ezequiel@vanguardiasur.com.ar>

This commit implements the ARM timer-based delay timer for the
LPC32xx, LPC18xx, LPC43xx family of SoCs.

Also, add a dependency to restrict compiling this driver for
the ARM architecture.

Signed-off-by: Ezequiel Garcia <ezequiel at vanguardiasur.com.ar>
---
 drivers/clocksource/Kconfig        |  1 +
 drivers/clocksource/time-lpc32xx.c | 12 ++++++++++++
 2 files changed, 13 insertions(+)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 33db7406c0e2..c346be650892 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -160,6 +160,7 @@ config CLKSRC_EFM32
 config CLKSRC_LPC32XX
 	bool "Clocksource for LPC32XX" if COMPILE_TEST
 	depends on GENERIC_CLOCKEVENTS && HAS_IOMEM
+	depends on ARM
 	select CLKSRC_MMIO
 	select CLKSRC_OF
 	help
diff --git a/drivers/clocksource/time-lpc32xx.c b/drivers/clocksource/time-lpc32xx.c
index 5694eddade15..daae61e8c820 100644
--- a/drivers/clocksource/time-lpc32xx.c
+++ b/drivers/clocksource/time-lpc32xx.c
@@ -18,6 +18,7 @@
 #include <linux/clk.h>
 #include <linux/clockchips.h>
 #include <linux/clocksource.h>
+#include <linux/delay.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/kernel.h>
@@ -54,6 +55,15 @@ static u64 notrace lpc32xx_read_sched_clock(void)
 	return readl(clocksource_timer_counter);
 }
 
+static unsigned long lpc32xx_delay_timer_read(void)
+{
+	return readl(clocksource_timer_counter);
+}
+
+static struct delay_timer lpc32xx_delay_timer = {
+	.read_current_timer = lpc32xx_delay_timer_read,
+};
+
 static int lpc32xx_clkevt_next_event(unsigned long delta,
 				     struct clock_event_device *evtdev)
 {
@@ -192,6 +202,8 @@ static int __init lpc32xx_clocksource_init(struct device_node *np)
 	}
 
 	clocksource_timer_counter = base + LPC32XX_TIMER_TC;
+	lpc32xx_delay_timer.freq = rate;
+	register_current_timer_delay(&lpc32xx_delay_timer);
 	sched_clock_register(lpc32xx_read_sched_clock, 32, rate);
 
 	return 0;
-- 
2.7.0



From dhdang at apm.com  Tue Feb  9 17:49:44 2016
From: dhdang at apm.com (Duc Dang)
Date: Tue,  9 Feb 2016 17:49:44 -0800
Subject: [PATCH] pci: xgene: Add ECAM fixups
Message-ID: <1455068984-22210-1-git-send-email-dhdang@apm.com>

X-Gene PCIe controller does not fully support ECAM.
This patch adds required ECAM fixup to allow X-Gene
PCIe controller to be functional in ACPI boot mode.

This patch is based on the original work of
Mark Salter <msalter at redhat.com> and depends on
Tomasz's PCIe ACPI series:
https://lkml.org/lkml/2016/2/4/646

Signed-off-by: Duc Dang <dhdang at apm.com>
---
 drivers/pci/host/pci-xgene.c | 130 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 127 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/host/pci-xgene.c b/drivers/pci/host/pci-xgene.c
index ae00ce2..5d3f74e 100644
--- a/drivers/pci/host/pci-xgene.c
+++ b/drivers/pci/host/pci-xgene.c
@@ -29,6 +29,11 @@
 #include <linux/pci.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
+#ifdef CONFIG_ACPI
+#include <linux/acpi.h>
+#include <linux/ecam.h>
+#include <linux/pci-acpi.h>
+#endif
 
 #define PCIECORE_CTLANDSTATUS		0x50
 #define PIM1_1L				0x80
@@ -76,6 +81,13 @@ struct xgene_pcie_port {
 	u32			version;
 };
 
+static struct xgene_pcie_port *(*xgene_pcie_bus_to_port)(struct pci_bus *bus);
+
+static struct xgene_pcie_port *xgene_pcie_dt_bus_to_port(struct pci_bus *bus)
+{
+	return bus->sysdata;
+}
+
 static inline u32 pcie_bar_low_val(u32 addr, u32 flags)
 {
 	return (addr & PCI_BASE_ADDRESS_MEM_MASK) | flags;
@@ -87,7 +99,7 @@ static inline u32 pcie_bar_low_val(u32 addr, u32 flags)
  */
 static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
 {
-	struct xgene_pcie_port *port = bus->sysdata;
+	struct xgene_pcie_port *port = xgene_pcie_bus_to_port(bus);
 
 	if (bus->number >= (bus->primary + 1))
 		return port->cfg_base + AXI_EP_CFG_ACCESS;
@@ -101,7 +113,7 @@ static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
  */
 static void xgene_pcie_set_rtdid_reg(struct pci_bus *bus, uint devfn)
 {
-	struct xgene_pcie_port *port = bus->sysdata;
+	struct xgene_pcie_port *port = xgene_pcie_bus_to_port(bus);
 	unsigned int b, d, f;
 	u32 rtdid_val = 0;
 
@@ -148,7 +160,7 @@ static void __iomem *xgene_pcie_map_bus(struct pci_bus *bus, unsigned int devfn,
 static int xgene_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
 				    int where, int size, u32 *val)
 {
-	struct xgene_pcie_port *port = bus->sysdata;
+	struct xgene_pcie_port *port = xgene_pcie_bus_to_port(bus);
 
 	if (pci_generic_config_read32(bus, devfn, where & ~0x3, 4, val) !=
 	    PCIBIOS_SUCCESSFUL)
@@ -509,6 +521,116 @@ static int xgene_pcie_setup(struct xgene_pcie_port *port,
 	return 0;
 }
 
+#ifdef CONFIG_ACPI
+#define APM_OEM_ID		"APM   "
+#define APM_XGENE_TABLE_ID	"XGENE   "
+static LIST_HEAD(xgene_acpi_pcie_roots);
+
+struct xgene_pcie_acpi_root {
+	struct list_head list;
+	struct acpi_pci_root *root;
+	struct xgene_pcie_port port;
+};
+
+static struct xgene_pcie_port *xgene_pcie_acpi_bus_to_port(struct pci_bus *bus)
+{
+	struct acpi_pci_root *root = bus->sysdata;
+	struct xgene_pcie_acpi_root *xgene_root;
+
+	list_for_each_entry(xgene_root, &xgene_acpi_pcie_roots, list) {
+		if (xgene_root->root == root)
+			return &xgene_root->port;
+	}
+
+	return NULL;
+}
+
+static acpi_status xgene_pcie_find_csr_base(struct acpi_resource *acpi_res,
+					    void *data)
+{
+	struct xgene_pcie_acpi_root *root = data;
+	struct acpi_resource_fixed_memory32 *fixed32;
+
+	if (acpi_res->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
+		fixed32 = &acpi_res->data.fixed_memory32;
+		root->port.csr_base = ioremap(fixed32->address,
+					      fixed32->address_length);
+		return AE_CTRL_TERMINATE;
+	}
+	return AE_OK;
+}
+
+static int xgene_pcie_mcfg_fixup(struct acpi_pci_root *root)
+{
+	struct pci_mmcfg_region *cfg;
+	struct acpi_device *device = root->device;
+	struct xgene_pcie_acpi_root *acpi_root;
+
+	acpi_root = kzalloc(sizeof(*acpi_root), GFP_KERNEL);
+	if (acpi_root == NULL)
+		return -ENOMEM;
+
+	INIT_LIST_HEAD(&acpi_root->list);
+	acpi_root->root = root;
+
+	cfg = pci_mmconfig_lookup(root->segment, root->secondary.start);
+	if (cfg)
+		acpi_root->port.cfg_base = cfg->virt;
+	else {
+		dev_err(&device->dev, "Failed to get CFG virt base\n");
+		return -ENODEV;
+	}
+
+	acpi_walk_resources(device->handle, METHOD_NAME__CRS,
+			    xgene_pcie_find_csr_base, acpi_root);
+
+	if (!acpi_root->port.csr_base) {
+		kfree(acpi_root);
+		return -ENODEV;
+	}
+
+	/* Update bus_to_port method */
+	xgene_pcie_bus_to_port = xgene_pcie_acpi_bus_to_port;
+
+	/* Set to IP version 1 to disable Configuration-Request Retry Status */
+	acpi_root->port.version = XGENE_PCIE_IP_VER_1;
+
+	list_add(&acpi_root->list, &xgene_acpi_pcie_roots);
+
+	return 0;
+}
+
+static int xgene_pcie_acpi_match(struct pci_mcfg_fixup *fixup,
+				 struct acpi_pci_root *root)
+{
+	struct acpi_table_header table_header;
+
+	if (acpi_get_table_header(ACPI_SIG_MCFG, 0, &table_header))
+		return 0;
+
+	if (strncmp(APM_OEM_ID, table_header.oem_id, ACPI_OEM_ID_SIZE))
+		return 0;
+
+	if (strncmp(APM_XGENE_TABLE_ID, table_header.oem_table_id,
+		    ACPI_OEM_TABLE_ID_SIZE))
+		return 0;
+
+	/*
+	 * MCFG table matches with X-Gene PCIe MCFG table.
+	 * Now perform additional fix-up actions to prepare for
+	 * X-Gene PCIe private data.
+	 */
+	if (xgene_pcie_mcfg_fixup(root))
+		return 0;
+
+	return 1;
+}
+
+DECLARE_ACPI_MCFG_FIXUP(NULL, xgene_pcie_acpi_match, &xgene_pcie_ops,
+			PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
+
+#endif /* CONFIG_ACPI */
+
 static int xgene_pcie_probe_bridge(struct platform_device *pdev)
 {
 	struct device_node *dn = pdev->dev.of_node;
@@ -518,6 +640,8 @@ static int xgene_pcie_probe_bridge(struct platform_device *pdev)
 	int ret;
 	LIST_HEAD(res);
 
+	xgene_pcie_bus_to_port = xgene_pcie_dt_bus_to_port;
+
 	port = devm_kzalloc(&pdev->dev, sizeof(*port), GFP_KERNEL);
 	if (!port)
 		return -ENOMEM;
-- 
1.9.1



From dhdang at apm.com  Tue Feb  9 17:56:24 2016
From: dhdang at apm.com (Duc Dang)
Date: Tue,  9 Feb 2016 17:56:24 -0800
Subject: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for
 X-Gene v1
Message-ID: <1455069384-22323-1-git-send-email-dhdang@apm.com>

This patch makes pci-xgene-msi driver ACPI-aware and provides
MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode.

Signed-off-by: Duc Dang <dhdang at apm.com>
---
 drivers/pci/host/pci-xgene-msi.c | 35 ++++++++++++++++++++++++++++++++---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
index a6456b5..466aa93 100644
--- a/drivers/pci/host/pci-xgene-msi.c
+++ b/drivers/pci/host/pci-xgene-msi.c
@@ -24,6 +24,7 @@
 #include <linux/pci.h>
 #include <linux/platform_device.h>
 #include <linux/of_pci.h>
+#include <linux/acpi.h>
 
 #define MSI_IR0			0x000000
 #define MSI_INT0		0x800000
@@ -39,7 +40,7 @@ struct xgene_msi_group {
 };
 
 struct xgene_msi {
-	struct device_node	*node;
+	struct fwnode_handle	*fwnode;
 	struct irq_domain	*inner_domain;
 	struct irq_domain	*msi_domain;
 	u64			msi_addr;
@@ -249,6 +250,13 @@ static const struct irq_domain_ops msi_domain_ops = {
 	.free   = xgene_irq_domain_free,
 };
 
+#ifdef CONFIG_ACPI
+static struct fwnode_handle *xgene_msi_get_fwnode(struct device *dev)
+{
+	return xgene_msi_ctrl.fwnode;
+}
+#endif
+
 static int xgene_allocate_domains(struct xgene_msi *msi)
 {
 	msi->inner_domain = irq_domain_add_linear(NULL, NR_MSI_VEC,
@@ -256,7 +264,7 @@ static int xgene_allocate_domains(struct xgene_msi *msi)
 	if (!msi->inner_domain)
 		return -ENOMEM;
 
-	msi->msi_domain = pci_msi_create_irq_domain(of_node_to_fwnode(msi->node),
+	msi->msi_domain = pci_msi_create_irq_domain(msi->fwnode,
 						    &xgene_msi_domain_info,
 						    msi->inner_domain);
 
@@ -265,6 +273,9 @@ static int xgene_allocate_domains(struct xgene_msi *msi)
 		return -ENOMEM;
 	}
 
+#ifdef CONFIG_ACPI
+	pci_msi_register_fwnode_provider(&xgene_msi_get_fwnode);
+#endif
 	return 0;
 }
 
@@ -473,6 +484,13 @@ static const struct of_device_id xgene_msi_match_table[] = {
 	{},
 };
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id xgene_msi_acpi_ids[] = {
+	{"APMC0D0E", 0},
+	{ },
+};
+#endif
+
 static int xgene_msi_probe(struct platform_device *pdev)
 {
 	struct resource *res;
@@ -494,7 +512,17 @@ static int xgene_msi_probe(struct platform_device *pdev)
 		goto error;
 	}
 	xgene_msi->msi_addr = res->start;
-	xgene_msi->node = pdev->dev.of_node;
+
+	xgene_msi->fwnode = of_node_to_fwnode(pdev->dev.of_node);
+	if (!xgene_msi->fwnode) {
+		xgene_msi->fwnode = irq_domain_alloc_fwnode(NULL);
+		if (!xgene_msi->fwnode) {
+			dev_err(&pdev->dev, "Failed to create fwnode\n");
+			rc = ENOMEM;
+			goto error;
+		}
+	}
+
 	xgene_msi->num_cpus = num_possible_cpus();
 
 	rc = xgene_msi_init_allocator(xgene_msi);
@@ -571,6 +599,7 @@ static struct platform_driver xgene_msi_driver = {
 	.driver = {
 		.name = "xgene-msi",
 		.of_match_table = xgene_msi_match_table,
+		.acpi_match_table = ACPI_PTR(xgene_msi_acpi_ids),
 	},
 	.probe = xgene_msi_probe,
 	.remove = xgene_msi_remove,
-- 
1.9.1



From linux at roeck-us.net  Tue Feb  9 18:37:46 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 9 Feb 2016 18:37:46 -0800
Subject: [PATCH] tty/serial: digicolor: Fix bad usage of IS_ERR_VALUE
In-Reply-To: <4571887.rTPndCnv20@wuerfel>
References: <1455030539-10798-1-git-send-email-linux@roeck-us.net>
 <4571887.rTPndCnv20@wuerfel>
Message-ID: <56BAA27A.9050605@roeck-us.net>

On 02/09/2016 07:26 AM, Arnd Bergmann wrote:
> On Tuesday 09 February 2016 07:08:59 Guenter Roeck wrote:
>> IS_ERR_VALUE() assumes that its parameter is an unsigned long.
>> It can not be used to check if an unsigned int reflects an error.
>> Doing so can result in the following build warning.
>>
>> drivers/tty/serial/digicolor-usart.c: In function ?digicolor_uart_probe?:
>> include/linux/err.h:21:38: warning:
>>          comparison is always false due to limited range of data type
>> drivers/tty/serial/digicolor-usart.c:485:6: note:
>>          in expansion of macro ?IS_ERR_VALUE?
>>
>> If that warning is seen, an error return from platform_get_irq() is missed.
>>
>>
>
> The patch looks correct to me, but what compiler version and which kernel
> tree is it that triggered the warning?
>
> Andrzej Hajda just modified the definition of IS_ERR_VALUE(), and the
> changes are still under discussion, but I don't see that warning with
> any of the versions.
>
I see it with gcc 5.1 and 5.2 (and W=1). I did not see / notice Andrzej's patch.

I agree that fixing the problem in IS_ERR_VALUE() is preferrable.

Guenter



From shaun.ren at linux.com  Tue Feb  9 18:45:19 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Tue,  9 Feb 2016 18:45:19 -0800
Subject: [PATCH v3 0/9] Staging: rts5208: Coding style and dma mapping fixes
In-Reply-To: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
References: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>

This set of patches fixes the coding style issues in rtsx_transport.c, and
dds a missing call dma_mapping_error() after dma_map_single().

Changes since v2
 * Incorporated Joshua Clayton's suggestions regarding the block comments



From shaun.ren at linux.com  Tue Feb  9 18:45:20 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Tue,  9 Feb 2016 18:45:20 -0800
Subject: [PATCH v3 1/9] Staging: rts5208: rtsx_transport.c: Cleanup comments
In-Reply-To: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
References: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
 <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455072328-7033-2-git-send-email-shaun.ren@linux.com>

This patch fixes all multiline comments to conform to the coding style,
which states that multiline comments should start with "/*" and end
with "*/" on a separate line.

Also cleans up some comments to make them more clear and/or reflect what
the code is doing.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
Changes since v2
 * Cleaned up comments as per Joshua Clayton's suggestions
 
 drivers/staging/rts5208/rtsx_transport.c | 53 ++++++++++++++++----------------
 1 file changed, 27 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index f27491e..5de8913 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -1,4 +1,5 @@
-/* Driver for Realtek PCI-Express card reader
+/*
+ * Driver for Realtek PCI-Express card reader
  *
  * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
@@ -30,13 +31,15 @@
  * Scatter-gather transfer buffer access routines
  ***********************************************************************/
 
-/* Copy a buffer of length buflen to/from the srb's transfer buffer.
+/*
+ * Copy a buffer of length buflen to/from the srb's transfer buffer.
  * (Note: for scatter-gather transfers (srb->use_sg > 0), srb->request_buffer
  * points to a list of s-g entries and we ignore srb->request_bufflen.
  * For non-scatter-gather transfers, srb->request_buffer points to the
  * transfer buffer itself and srb->request_bufflen is the buffer's length.)
  * Update the *index and *offset variables so that the next copy will
- * pick up from where this one left off. */
+ * pick up from where this one left off.
+ */
 
 unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 	unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
@@ -44,8 +47,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 {
 	unsigned int cnt;
 
-	/* If not using scatter-gather, just transfer the data directly.
-	 * Make certain it will fit in the available buffer space. */
+	/* If not using scatter-gather, just transfer the data directly. */
 	if (scsi_sg_count(srb) == 0) {
 		if (*offset >= scsi_bufflen(srb))
 			return 0;
@@ -58,22 +60,22 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 					*offset, cnt);
 		*offset += cnt;
 
-	/* Using scatter-gather.  We have to go through the list one entry
+	/*
+	 * Using scatter-gather.  We have to go through the list one entry
 	 * at a time.  Each s-g entry contains some number of pages, and
-	 * each page has to be kmap()'ed separately.  If the page is already
-	 * in kernel-addressable memory then kmap() will return its address.
-	 * If the page is not directly accessible -- such as a user buffer
-	 * located in high memory -- then kmap() will map it to a temporary
-	 * position in the kernel's virtual address space. */
+	 * each page has to be kmap()'ed separately.
+	 */
 	} else {
 		struct scatterlist *sg =
 				(struct scatterlist *) scsi_sglist(srb)
 				+ *index;
 
-		/* This loop handles a single s-g list entry, which may
+		/*
+		 * This loop handles a single s-g list entry, which may
 		 * include multiple pages.  Find the initial page structure
 		 * and the starting offset within the page, and update
-		 * the *offset and *index values for the next loop. */
+		 * the *offset and *index values for the next loop.
+		 */
 		cnt = 0;
 		while (cnt < buflen && *index < scsi_sg_count(srb)) {
 			struct page *page = sg_page(sg) +
@@ -95,9 +97,6 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 				++sg;
 			}
 
-			/* Transfer the data for all the pages in this
-			 * s-g entry.  For each page: call kmap(), do the
-			 * transfer, and call kunmap() immediately after. */
 			while (sglen > 0) {
 				unsigned int plen = min(sglen, (unsigned int)
 						PAGE_SIZE - poff);
@@ -122,8 +121,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 	return cnt;
 }
 
-/* Store the contents of buffer into srb's transfer buffer and set the
-* SCSI residue. */
+/*
+ * Store the contents of buffer into srb's transfer buffer and set the SCSI
+ * SCSI residue.
+ */
 void rtsx_stor_set_xfer_buf(unsigned char *buffer,
 	unsigned int buflen, struct scsi_cmnd *srb)
 {
@@ -151,7 +152,8 @@ void rtsx_stor_get_xfer_buf(unsigned char *buffer,
  * Transport routines
  ***********************************************************************/
 
-/* Invoke the transport and basic error-handling/recovery methods
+/*
+ * Invoke the transport and basic error-handling/recovery methods
  *
  * This is used to send the message to the device and receive the response.
  */
@@ -161,8 +163,9 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 
 	result = rtsx_scsi_handler(srb, chip);
 
-	/* if the command gets aborted by the higher layers, we need to
-	 * short-circuit all other processing
+	/*
+	 * if the command gets aborted by the higher layers, we need to
+	 * short-circuit all other processing.
 	 */
 	if (rtsx_chk_stat(chip, RTSX_STAT_ABORT)) {
 		dev_dbg(rtsx_dev(chip), "-- command was aborted\n");
@@ -194,9 +197,6 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 
 	return;
 
-	/* Error and abort processing: try to resynchronize with the device
-	 * by issuing a port reset.  If that fails, try a class-specific
-	 * device reset. */
 Handle_Errors:
 	return;
 }
@@ -368,10 +368,11 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
 	resid = size;
 	sg_ptr = sg;
 	chip->sgi = 0;
-	/* Usually the next entry will be @sg@ + 1, but if this sg element
+	/*
+	 * Usually the next entry will be @sg@ + 1, but if this sg element
 	 * is part of a chained scatterlist, it could jump to the start of
 	 * a new scatterlist array. So here we use sg_next to move to
-	 * the proper sg
+	 * the proper sg.
 	 */
 	for (i = 0; i < *index; i++)
 		sg_ptr = sg_next(sg_ptr);
-- 
2.7.0



From shaun.ren at linux.com  Tue Feb  9 18:45:21 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Tue,  9 Feb 2016 18:45:21 -0800
Subject: [PATCH v3 2/9] Staging: rts5208: rtsx_transport.c: Align to open
 parenthesis
In-Reply-To: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
References: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
 <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455072328-7033-3-git-send-email-shaun.ren@linux.com>

This patch fixes the alignment issue reported by checkpatch.pl:

CHECK: Alignment should match open parenthesis

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 61 ++++++++++++++++++--------------
 1 file changed, 35 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 5de8913..17bea8a 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -42,8 +42,11 @@
  */
 
 unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
-	unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
-	unsigned int *offset, enum xfer_buf_dir dir)
+				       unsigned int buflen,
+				       struct scsi_cmnd *srb,
+				       unsigned int *index,
+				       unsigned int *offset,
+				     enum xfer_buf_dir dir)
 {
 	unsigned int cnt;
 
@@ -54,10 +57,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 		cnt = min(buflen, scsi_bufflen(srb) - *offset);
 		if (dir == TO_XFER_BUF)
 			memcpy((unsigned char *) scsi_sglist(srb) + *offset,
-					buffer, cnt);
+			       buffer, cnt);
 		else
 			memcpy(buffer, (unsigned char *) scsi_sglist(srb) +
-					*offset, cnt);
+			       *offset, cnt);
 		*offset += cnt;
 
 	/*
@@ -126,7 +129,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
  * SCSI residue.
  */
 void rtsx_stor_set_xfer_buf(unsigned char *buffer,
-	unsigned int buflen, struct scsi_cmnd *srb)
+			    unsigned int buflen, struct scsi_cmnd *srb)
 {
 	unsigned int index = 0, offset = 0;
 
@@ -137,7 +140,7 @@ void rtsx_stor_set_xfer_buf(unsigned char *buffer,
 }
 
 void rtsx_stor_get_xfer_buf(unsigned char *buffer,
-	unsigned int buflen, struct scsi_cmnd *srb)
+			    unsigned int buflen, struct scsi_cmnd *srb)
 {
 	unsigned int index = 0, offset = 0;
 
@@ -191,8 +194,8 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 		/* set the result so the higher layers expect this data */
 		srb->result = SAM_STAT_CHECK_CONDITION;
 		memcpy(srb->sense_buffer,
-			(unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
-			sizeof(struct sense_data_t));
+		       (unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
+		       sizeof(struct sense_data_t));
 	}
 
 	return;
@@ -202,7 +205,7 @@ Handle_Errors:
 }
 
 void rtsx_add_cmd(struct rtsx_chip *chip,
-		u8 cmd_type, u16 reg_addr, u8 mask, u8 data)
+		  u8 cmd_type, u16 reg_addr, u8 mask, u8 data)
 {
 	u32 *cb = (u32 *)(chip->host_cmds_ptr);
 	u32 val = 0;
@@ -321,9 +324,11 @@ static inline void rtsx_add_sg_tbl(
 }
 
 static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
-		struct scatterlist *sg, int num_sg, unsigned int *index,
-		unsigned int *offset, int size,
-		enum dma_data_direction dma_dir, int timeout)
+					     struct scatterlist *sg, int num_sg,
+					     unsigned int *index,
+					     unsigned int *offset, int size,
+					     enum dma_data_direction dma_dir,
+					     int timeout)
 {
 	struct rtsx_dev *rtsx = chip->rtsx;
 	struct completion trans_done;
@@ -486,8 +491,9 @@ out:
 }
 
 static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
-		struct scatterlist *sg, int num_sg,
-		enum dma_data_direction dma_dir, int timeout)
+				     struct scatterlist *sg, int num_sg,
+				     enum dma_data_direction dma_dir,
+				     int timeout)
 {
 	struct rtsx_dev *rtsx = chip->rtsx;
 	struct completion trans_done;
@@ -633,7 +639,8 @@ out:
 }
 
 static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
-		size_t len, enum dma_data_direction dma_dir, int timeout)
+			     size_t len, enum dma_data_direction dma_dir,
+			     int timeout)
 {
 	struct rtsx_dev *rtsx = chip->rtsx;
 	struct completion trans_done;
@@ -716,9 +723,9 @@ out:
 }
 
 int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
-		void *buf, size_t len, int use_sg, unsigned int *index,
-		unsigned int *offset, enum dma_data_direction dma_dir,
-		int timeout)
+			       void *buf, size_t len, int use_sg,
+			       unsigned int *index, unsigned int *offset,
+			       enum dma_data_direction dma_dir, int timeout)
 {
 	int err = 0;
 
@@ -726,11 +733,13 @@ int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
 	if (rtsx_chk_stat(chip, RTSX_STAT_ABORT))
 		return -EIO;
 
-	if (use_sg)
-		err = rtsx_transfer_sglist_adma_partial(chip, card,
-				(struct scatterlist *)buf, use_sg,
-				index, offset, (int)len, dma_dir, timeout);
-	else
+	if (use_sg) {
+		struct scatterlist *sg = (struct scatterlist *)buf;
+
+		err = rtsx_transfer_sglist_adma_partial(chip, card, sg, use_sg,
+							index, offset, (int)len,
+							dma_dir, timeout);
+	} else
 		err = rtsx_transfer_buf(chip, card,
 					buf, len, dma_dir, timeout);
 	if (err < 0) {
@@ -745,7 +754,7 @@ int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
 }
 
 int rtsx_transfer_data(struct rtsx_chip *chip, u8 card, void *buf, size_t len,
-		int use_sg, enum dma_data_direction dma_dir, int timeout)
+		       int use_sg, enum dma_data_direction dma_dir, int timeout)
 {
 	int err = 0;
 
@@ -757,8 +766,8 @@ int rtsx_transfer_data(struct rtsx_chip *chip, u8 card, void *buf, size_t len,
 
 	if (use_sg) {
 		err = rtsx_transfer_sglist_adma(chip, card,
-				(struct scatterlist *)buf,
-				use_sg, dma_dir, timeout);
+						(struct scatterlist *)buf,
+						use_sg, dma_dir, timeout);
 	} else {
 		err = rtsx_transfer_buf(chip, card, buf, len, dma_dir, timeout);
 	}
-- 
2.7.0



From shaun.ren at linux.com  Tue Feb  9 18:45:22 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Tue,  9 Feb 2016 18:45:22 -0800
Subject: [PATCH v3 3/9] Staging: rts5208: rtsx_transport.c: Remove spaces
 after casts
In-Reply-To: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
References: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
 <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455072328-7033-4-git-send-email-shaun.ren@linux.com>

This patch removes all spaces after casts in rtsx_transport.c, as reported
by checkpatch.pl:

CHECK: No space is necessary after a cast

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 17bea8a..57b1f46 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -56,10 +56,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 			return 0;
 		cnt = min(buflen, scsi_bufflen(srb) - *offset);
 		if (dir == TO_XFER_BUF)
-			memcpy((unsigned char *) scsi_sglist(srb) + *offset,
+			memcpy((unsigned char *)scsi_sglist(srb) + *offset,
 			       buffer, cnt);
 		else
-			memcpy(buffer, (unsigned char *) scsi_sglist(srb) +
+			memcpy(buffer, (unsigned char *)scsi_sglist(srb) +
 			       *offset, cnt);
 		*offset += cnt;
 
@@ -70,7 +70,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 	 */
 	} else {
 		struct scatterlist *sg =
-				(struct scatterlist *) scsi_sglist(srb)
+				(struct scatterlist *)scsi_sglist(srb)
 				+ *index;
 
 		/*
-- 
2.7.0



From shaun.ren at linux.com  Tue Feb  9 18:45:23 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Tue,  9 Feb 2016 18:45:23 -0800
Subject: [PATCH v3 4/9] Staging: rts5208: rtsx_transport.c: Add spaces around -
In-Reply-To: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
References: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
 <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455072328-7033-5-git-send-email-shaun.ren@linux.com>

This patch fixes the following styling issue in rtsx_transport.c
as reported by checkpatch.pl:

CHECK: spaces preferred around that '-' (ctx:VxV)

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 57b1f46..b137aca 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -83,8 +83,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 		while (cnt < buflen && *index < scsi_sg_count(srb)) {
 			struct page *page = sg_page(sg) +
 					((sg->offset + *offset) >> PAGE_SHIFT);
-			unsigned int poff =
-					(sg->offset + *offset) & (PAGE_SIZE-1);
+			unsigned int poff = (sg->offset + *offset) &
+					    (PAGE_SIZE - 1);
 			unsigned int sglen = sg->length - *offset;
 
 			if (sglen > buflen - cnt) {
-- 
2.7.0



From shaun.ren at linux.com  Tue Feb  9 18:45:24 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Tue,  9 Feb 2016 18:45:24 -0800
Subject: [PATCH v3 5/9] Staging: rts5208: rtsx_transport.c: Remove extra
 newlines
In-Reply-To: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
References: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
 <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455072328-7033-6-git-send-email-shaun.ren@linux.com>

This patch fixes the following issues in rtsx_transport.c as reported by
checkpatch.pl:

CHECK: Blank lines aren't necessary after an open brace '{'
CHECK: Please don't use multiple blank lines

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index b137aca..14321c0 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -88,12 +88,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 			unsigned int sglen = sg->length - *offset;
 
 			if (sglen > buflen - cnt) {
-
 				/* Transfer ends within this s-g entry */
 				sglen = buflen - cnt;
 				*offset += sglen;
 			} else {
-
 				/* Transfer continues to next s-g entry */
 				*offset = 0;
 				++*index;
@@ -150,7 +148,6 @@ void rtsx_stor_get_xfer_buf(unsigned char *buffer,
 		scsi_set_resid(srb, scsi_bufflen(srb) - buflen);
 }
 
-
 /***********************************************************************
  * Transport routines
  ***********************************************************************/
-- 
2.7.0



From shaun.ren at linux.com  Tue Feb  9 18:45:25 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Tue,  9 Feb 2016 18:45:25 -0800
Subject: [PATCH v3 6/9] Staging: rts5208: rtsx_transport.c: Fix label naming
 convention
In-Reply-To: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
References: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
 <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455072328-7033-7-git-send-email-shaun.ren@linux.com>

This patch fixes the following naming convention issue in rtsx_transport.c,
as reported by checkpatch.pl:

CHECK: Avoid CamelCase: <Handle_Errors>

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
Changes since v2
 * Update patch to reflect the changes made in PATCH 1/9 (block comments)

 drivers/staging/rts5208/rtsx_transport.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 14321c0..ea00347 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -170,14 +170,14 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 	if (rtsx_chk_stat(chip, RTSX_STAT_ABORT)) {
 		dev_dbg(rtsx_dev(chip), "-- command was aborted\n");
 		srb->result = DID_ABORT << 16;
-		goto Handle_Errors;
+		goto handle_errors;
 	}
 
 	/* if there is a transport error, reset and don't auto-sense */
 	if (result == TRANSPORT_ERROR) {
 		dev_dbg(rtsx_dev(chip), "-- transport indicates error, resetting\n");
 		srb->result = DID_ERROR << 16;
-		goto Handle_Errors;
+		goto handle_errors;
 	}
 
 	srb->result = SAM_STAT_GOOD;
@@ -197,7 +197,7 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 
 	return;
 
-Handle_Errors:
+handle_errors:
 	return;
 }
 
-- 
2.7.0



From shaun.ren at linux.com  Tue Feb  9 18:45:28 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Tue,  9 Feb 2016 18:45:28 -0800
Subject: [PATCH v3 9/9] Staging: rts5208: Add missing dma_mapping_error
In-Reply-To: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
References: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
 <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455072328-7033-10-git-send-email-shaun.ren@linux.com>

This patch adds a dma_mapping_error call to debug potential DMA mapping
errors after the dma_map_single call in rtsx_transport.c.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 46fc8c2..2b38de7 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -658,7 +658,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
 		return -ENXIO;
 
 	addr = dma_map_single(&rtsx->pci->dev, buf, len, dma_dir);
-	if (!addr)
+	if (dma_mapping_error(&rtsx->pci->dev, addr))
 		return -ENOMEM;
 
 	if (card == SD_CARD)
-- 
2.7.0



From shaun.ren at linux.com  Tue Feb  9 18:45:26 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Tue,  9 Feb 2016 18:45:26 -0800
Subject: [PATCH v3 7/9] Staging: rts5208: rtsx_transport.c: Remove unnecessary
 parentheses
In-Reply-To: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
References: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
 <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455072328-7033-8-git-send-email-shaun.ren@linux.com>

This patch removes all unnecessary parentheses found by checkpatch.pl.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index ea00347..c956072 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -191,7 +191,7 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 		/* set the result so the higher layers expect this data */
 		srb->result = SAM_STAT_CHECK_CONDITION;
 		memcpy(srb->sense_buffer,
-		       (unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
+		       (unsigned char *)&chip->sense_buffer[SCSI_LUN(srb)],
 		       sizeof(struct sense_data_t));
 	}
 
@@ -365,7 +365,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
 
 	spin_unlock_irq(&rtsx->reg_lock);
 
-	sg_cnt = dma_map_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	sg_cnt = dma_map_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	resid = size;
 	sg_ptr = sg;
@@ -479,7 +479,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
 out:
 	rtsx->done = NULL;
 	rtsx->trans_state = STATE_TRANS_NONE;
-	dma_unmap_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	dma_unmap_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	if (err < 0)
 		rtsx_stop_cmd(chip, card);
@@ -529,7 +529,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
 
 	spin_unlock_irq(&rtsx->reg_lock);
 
-	buf_cnt = dma_map_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	buf_cnt = dma_map_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	sg_ptr = sg;
 
@@ -627,7 +627,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
 out:
 	rtsx->done = NULL;
 	rtsx->trans_state = STATE_TRANS_NONE;
-	dma_unmap_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	dma_unmap_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	if (err < 0)
 		rtsx_stop_cmd(chip, card);
@@ -657,7 +657,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
 	else
 		return -ENXIO;
 
-	addr = dma_map_single(&(rtsx->pci->dev), buf, len, dma_dir);
+	addr = dma_map_single(&rtsx->pci->dev, buf, len, dma_dir);
 	if (!addr)
 		return -ENOMEM;
 
@@ -711,7 +711,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
 out:
 	rtsx->done = NULL;
 	rtsx->trans_state = STATE_TRANS_NONE;
-	dma_unmap_single(&(rtsx->pci->dev), addr, len, dma_dir);
+	dma_unmap_single(&rtsx->pci->dev, addr, len, dma_dir);
 
 	if (err < 0)
 		rtsx_stop_cmd(chip, card);
-- 
2.7.0



From shaun.ren at linux.com  Tue Feb  9 18:45:27 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Tue,  9 Feb 2016 18:45:27 -0800
Subject: [PATCH v3 8/9] Staging: rts5208: rtsx_transport.c: Fix comparisons to
 NULL
In-Reply-To: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
References: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
 <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455072328-7033-9-git-send-email-shaun.ren@linux.com>

This patch changes all comparsions to NULL with !..., as reported by
checkpatch.pl.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index c956072..46fc8c2 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -336,7 +336,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
 	struct scatterlist *sg_ptr;
 	u32 val = TRIG_DMA;
 
-	if ((sg == NULL) || (num_sg <= 0) || !offset || !index)
+	if (!sg || (num_sg <= 0) || !offset || !index)
 		return -EIO;
 
 	if (dma_dir == DMA_TO_DEVICE)
@@ -500,7 +500,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
 	long timeleft;
 	struct scatterlist *sg_ptr;
 
-	if ((sg == NULL) || (num_sg <= 0))
+	if (!sg || (num_sg <= 0))
 		return -EIO;
 
 	if (dma_dir == DMA_TO_DEVICE)
@@ -647,7 +647,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
 	u32 val = 1 << 31;
 	long timeleft;
 
-	if ((buf == NULL) || (len <= 0))
+	if (!buf || (len <= 0))
 		return -EIO;
 
 	if (dma_dir == DMA_TO_DEVICE)
-- 
2.7.0



From joe at perches.com  Tue Feb  9 18:58:11 2016
From: joe at perches.com (Joe Perches)
Date: Tue, 09 Feb 2016 18:58:11 -0800
Subject: [PATCH v3 2/9] Staging: rts5208: rtsx_transport.c: Align to
 open parenthesis
In-Reply-To: <1455072328-7033-3-git-send-email-shaun.ren@linux.com>
References: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
 <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
 <1455072328-7033-3-git-send-email-shaun.ren@linux.com>
Message-ID: <1455073091.3333.24.camel@perches.com>

On Tue, 2016-02-09 at 18:45 -0800, Shaun Ren wrote:
> This patch fixes the alignment issue reported by checkpatch.pl:
> 
> CHECK: Alignment should match open parenthesis
> 
> Signed-off-by: Shaun Ren <shaun.ren at linux.com>
> ---
> ?drivers/staging/rts5208/rtsx_transport.c | 61 ++++++++++++++++++--------------
> ?1 file changed, 35 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
> index 5de8913..17bea8a 100644
> --- a/drivers/staging/rts5208/rtsx_transport.c
> +++ b/drivers/staging/rts5208/rtsx_transport.c
> @@ -42,8 +42,11 @@
> ? */
> ?
> ?unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
> -	unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
> -	unsigned int *offset, enum xfer_buf_dir dir)
> +				???????unsigned int buflen,
> +				???????struct scsi_cmnd *srb,
> +				???????unsigned int *index,
> +				???????unsigned int *offset,
> +				?????enum xfer_buf_dir dir)

Doesn't this look odd to you?

> ?{
> ?	unsigned int cnt;
> ?
> @@ -54,10 +57,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
> ?		cnt = min(buflen, scsi_bufflen(srb) - *offset);
> ?		if (dir == TO_XFER_BUF)
> ?			memcpy((unsigned char *) scsi_sglist(srb) + *offset,
> -					buffer, cnt);
> +			???????buffer, cnt);
> ?		else
> ?			memcpy(buffer, (unsigned char *) scsi_sglist(srb) +
> -					*offset, cnt);
> +			???????*offset, cnt);

If you really want to make this look nicer and more
intelligible, it's probably be better to use a more
symmetric form like:

		if (dir == TO_XFER_BUF)
			memcpy((unsigned char *)scsi_sglist(srb) + *offset,
			       buffer,
			       cnt);
		else
			memcpy(buffer,
			       (unsigned char *)scsi_sglist(srb) + *offset,
			       cnt);
or maybe

		void *to;
		void *from;

		[...]

		if (dir == TO_XFER_BUF) {
			to = (unsigned char *)scsi_sglist(srb) + *offset;
			from = buffer;
		} else {
			to = buffer;
			from = (unsigned char *)scsi_sglist(srb) +
*offset;
		}
		memcpy(to, from, cnt);

or maybe

		void *to;
		void *from;

		[...]

		to = (unsigned char *)scsi_sglist(srb) + *offset;
		from = buffer;
		if (dir != TO_XFER_BUF)
			swap(to, from);

		memcpy(to, from, cnt);



From stillcompiling at gmail.com  Tue Feb  9 19:06:06 2016
From: stillcompiling at gmail.com (Joshua Clayton)
Date: Tue, 09 Feb 2016 19:06:06 -0800
Subject: [PATCH v3 1/9] Staging: rts5208: rtsx_transport.c: Cleanup
 comments
In-Reply-To: <1455072328-7033-2-git-send-email-shaun.ren@linux.com>
References: <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
 <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
 <1455072328-7033-2-git-send-email-shaun.ren@linux.com>
Message-ID: <4448620.TdHnN3dFWN@diplodocus>

Hi Shaun.
These comments now reflect common kernel style.
Thanks for addressing my comments.

Just one minor note below. It seems the word SCSI
SCSI got duplicated in one comment. (Noted below).

The rest look great to me.

On Tuesday, February 09, 2016 06:45:20 PM Shaun Ren wrote:
> This patch fixes all multiline comments to conform to the coding style,
> which states that multiline comments should start with "/*" and end
> with "*/" on a separate line.
> 
> Also cleans up some comments to make them more clear and/or reflect what
> the code is doing.
> 
> Signed-off-by: Shaun Ren <shaun.ren at linux.com>
> ---
> Changes since v2
>  * Cleaned up comments as per Joshua Clayton's suggestions
>  
>  drivers/staging/rts5208/rtsx_transport.c | 53 ++++++++++++++++----------------
>  1 file changed, 27 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
> index f27491e..5de8913 100644
> --- a/drivers/staging/rts5208/rtsx_transport.c
> +++ b/drivers/staging/rts5208/rtsx_transport.c
> @@ -1,4 +1,5 @@
> -/* Driver for Realtek PCI-Express card reader
> +/*
> + * Driver for Realtek PCI-Express card reader
>   *
>   * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
>   *
> @@ -30,13 +31,15 @@
>   * Scatter-gather transfer buffer access routines
>   ***********************************************************************/
>  
> -/* Copy a buffer of length buflen to/from the srb's transfer buffer.
> +/*
> + * Copy a buffer of length buflen to/from the srb's transfer buffer.
>   * (Note: for scatter-gather transfers (srb->use_sg > 0), srb->request_buffer
>   * points to a list of s-g entries and we ignore srb->request_bufflen.
>   * For non-scatter-gather transfers, srb->request_buffer points to the
>   * transfer buffer itself and srb->request_bufflen is the buffer's length.)
>   * Update the *index and *offset variables so that the next copy will
> - * pick up from where this one left off. */
> + * pick up from where this one left off.
> + */
>  
>  unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
>  	unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
> @@ -44,8 +47,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
>  {
>  	unsigned int cnt;
>  
> -	/* If not using scatter-gather, just transfer the data directly.
> -	 * Make certain it will fit in the available buffer space. */
> +	/* If not using scatter-gather, just transfer the data directly. */
>  	if (scsi_sg_count(srb) == 0) {
>  		if (*offset >= scsi_bufflen(srb))
>  			return 0;
> @@ -58,22 +60,22 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
>  					*offset, cnt);
>  		*offset += cnt;
>  
> -	/* Using scatter-gather.  We have to go through the list one entry
> +	/*
> +	 * Using scatter-gather.  We have to go through the list one entry
>  	 * at a time.  Each s-g entry contains some number of pages, and
> -	 * each page has to be kmap()'ed separately.  If the page is already
> -	 * in kernel-addressable memory then kmap() will return its address.
> -	 * If the page is not directly accessible -- such as a user buffer
> -	 * located in high memory -- then kmap() will map it to a temporary
> -	 * position in the kernel's virtual address space. */
> +	 * each page has to be kmap()'ed separately.
> +	 */
>  	} else {
>  		struct scatterlist *sg =
>  				(struct scatterlist *) scsi_sglist(srb)
>  				+ *index;
>  
> -		/* This loop handles a single s-g list entry, which may
> +		/*
> +		 * This loop handles a single s-g list entry, which may
>  		 * include multiple pages.  Find the initial page structure
>  		 * and the starting offset within the page, and update
> -		 * the *offset and *index values for the next loop. */
> +		 * the *offset and *index values for the next loop.
> +		 */
>  		cnt = 0;
>  		while (cnt < buflen && *index < scsi_sg_count(srb)) {
>  			struct page *page = sg_page(sg) +
> @@ -95,9 +97,6 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
>  				++sg;
>  			}
>  
> -			/* Transfer the data for all the pages in this
> -			 * s-g entry.  For each page: call kmap(), do the
> -			 * transfer, and call kunmap() immediately after. */
>  			while (sglen > 0) {
>  				unsigned int plen = min(sglen, (unsigned int)
>  						PAGE_SIZE - poff);
> @@ -122,8 +121,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
>  	return cnt;
>  }
>  
> -/* Store the contents of buffer into srb's transfer buffer and set the
> -* SCSI residue. */
> +/*
> + * Store the contents of buffer into srb's transfer buffer and set the SCSI
> + * SCSI residue.
> + */

SCSI SCSI 

>  void rtsx_stor_set_xfer_buf(unsigned char *buffer,
>  	unsigned int buflen, struct scsi_cmnd *srb)
>  {
> @@ -151,7 +152,8 @@ void rtsx_stor_get_xfer_buf(unsigned char *buffer,
>   * Transport routines
>   ***********************************************************************/
>  
> -/* Invoke the transport and basic error-handling/recovery methods
> +/*
> + * Invoke the transport and basic error-handling/recovery methods
>   *
>   * This is used to send the message to the device and receive the response.
>   */
> @@ -161,8 +163,9 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>  
>  	result = rtsx_scsi_handler(srb, chip);
>  
> -	/* if the command gets aborted by the higher layers, we need to
> -	 * short-circuit all other processing
> +	/*
> +	 * if the command gets aborted by the higher layers, we need to
> +	 * short-circuit all other processing.
>  	 */
>  	if (rtsx_chk_stat(chip, RTSX_STAT_ABORT)) {
>  		dev_dbg(rtsx_dev(chip), "-- command was aborted\n");
> @@ -194,9 +197,6 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
>  
>  	return;
>  
> -	/* Error and abort processing: try to resynchronize with the device
> -	 * by issuing a port reset.  If that fails, try a class-specific
> -	 * device reset. */
>  Handle_Errors:
>  	return;
>  }
> @@ -368,10 +368,11 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
>  	resid = size;
>  	sg_ptr = sg;
>  	chip->sgi = 0;
> -	/* Usually the next entry will be @sg@ + 1, but if this sg element
> +	/*
> +	 * Usually the next entry will be @sg@ + 1, but if this sg element
>  	 * is part of a chained scatterlist, it could jump to the start of
>  	 * a new scatterlist array. So here we use sg_next to move to
> -	 * the proper sg
> +	 * the proper sg.
>  	 */
>  	for (i = 0; i < *index; i++)
>  		sg_ptr = sg_next(sg_ptr);
> 



From kuninori.morimoto.gx at renesas.com  Tue Feb  9 19:12:02 2016
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Wed, 10 Feb 2016 03:12:02 +0000
Subject: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
In-Reply-To: <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
 <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
Message-ID: <87lh6ts1o0.wl%kuninori.morimoto.gx@renesas.com>


Hi Sergei, again

> Define the generic R8A7794 part of  the sound device node.
> This sound device  is a complex one and comprises the Audio Clock Generator
> (ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
> (SSI[U]), and Audio DMAC-Peripheral-Peripheral.
> It is up  to the board file to enable the device.
> 
> This patch is based on the R8A7791 sound work by Kuninori Morimoto.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
(snip)
> +		clocks = <&mstp10_clks R8A7794_CLK_SSI_ALL>,
> +			 <&mstp10_clks R8A7794_CLK_SSI9>,
> +			 <&mstp10_clks R8A7794_CLK_SSI8>,
> +			 <&mstp10_clks R8A7794_CLK_SSI7>,
> +			 <&mstp10_clks R8A7794_CLK_SSI6>,
> +			 <&mstp10_clks R8A7794_CLK_SSI5>,
> +			 <&mstp10_clks R8A7794_CLK_SSI4>,
> +			 <&mstp10_clks R8A7794_CLK_SSI3>,
> +			 <&mstp10_clks R8A7794_CLK_SSI2>,
> +			 <&mstp10_clks R8A7794_CLK_SSI1>,
> +			 <&mstp10_clks R8A7794_CLK_SSI0>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC9>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC8>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC7>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC6>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC5>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC4>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC3>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC2>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC1>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC0>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_DVC0>,
> +			 <&mstp10_clks R8A7794_CLK_SCU_DVC1>,
> +			 <&audio_clka>, <&audio_clkb>, <&audio_clkc>,
> +			 <&m2_clk>;
> +		clock-names = "ssi-all",
> +			      "ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
> +			      "ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0",
> +			      "src.9", "src.8", "src.7", "src.6", "src.5",
> +			      "src.4", "src.3", "src.2", "src.1", "src.0",
> +			      "ctu.0", "ctu.1",
> +			      "mix.0", "mix.1",
> +			      "dvc.0", "dvc.1",
> +			      "clk_a", "clk_b", "clk_c", "clk_i";

I'm sorry about my previous email. I think I made you confuse.
I meant you can remove CTU/MIX field if your patch doesn't care these.


From wens at csie.org  Tue Feb  9 19:25:28 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Wed, 10 Feb 2016 11:25:28 +0800
Subject: [PATCH 1/2] clk: sunxi: Add support for A80 APBS clock
In-Reply-To: <20160202111541.GN4652@lukather>
References: <1454337769-4130-1-git-send-email-wens@csie.org>
 <1454337769-4130-2-git-send-email-wens@csie.org>
 <20160202111541.GN4652@lukather>
Message-ID: <CAGb2v64Jz49y+pUJe=FPw8Nh2rDo=-=+mXNVa4B7f_V2GjTfiw@mail.gmail.com>

On Tue, Feb 2, 2016 at 7:15 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> Hi Chen-Yu
>
> On Mon, Feb 01, 2016 at 10:42:48PM +0800, Chen-Yu Tsai wrote:
>> A80's APBS clock is not the same as the APB0 clock on A23. The A80's
>> is a zero-based divider, while the A23's is a power-of-two divider.
>>
>> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
>> ---
>>  Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
>>  drivers/clk/sunxi/Makefile                        |  2 +-
>>  drivers/clk/sunxi/clk-sun9i-apbs.c                | 64 +++++++++++++++++++++++
>>  3 files changed, 66 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/clk/sunxi/clk-sun9i-apbs.c
>>
>> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
>> index e59f57b24777..fad81157798c 100644
>> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
>> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
>> @@ -58,6 +58,7 @@ Required properties:
>>       "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
>>       "allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
>>       "allwinner,sun8i-h3-bus-gates-clk" - for the bus gates on H3
>> +     "allwinner,sun9i-a80-apbs-clk" - for the APBS clock on A80
>>       "allwinner,sun9i-a80-apbs-gates-clk" - for the APBS gates on A80
>>       "allwinner,sun4i-a10-dram-gates-clk" - for the DRAM gates on A10
>>       "allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
>> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
>> index 3fd7901d48e4..df433b3f789d 100644
>> --- a/drivers/clk/sunxi/Makefile
>> +++ b/drivers/clk/sunxi/Makefile
>> @@ -17,7 +17,7 @@ obj-y += clk-sun9i-core.o
>>  obj-y += clk-sun9i-mmc.o
>>  obj-y += clk-usb.o
>>
>> -obj-$(CONFIG_MACH_SUN9I) += clk-sun8i-apb0.o
>> +obj-$(CONFIG_MACH_SUN9I) += clk-sun9i-apbs.o
>>  obj-$(CONFIG_MACH_SUN9I) += clk-sun9i-cpus.o
>>
>>  obj-$(CONFIG_MFD_SUN6I_PRCM) += \
>> diff --git a/drivers/clk/sunxi/clk-sun9i-apbs.c b/drivers/clk/sunxi/clk-sun9i-apbs.c
>> new file mode 100644
>> index 000000000000..aacb92873621
>> --- /dev/null
>> +++ b/drivers/clk/sunxi/clk-sun9i-apbs.c
>> @@ -0,0 +1,64 @@
>> +/*
>> + * Copyright (C) 2016 Chen-Yu Tsai
>> + * Author: Chen-Yu Tsai <wens at csie.org>
>> + *
>> + * Allwinner A80 APBS clock driver
>> + *
>> + * License Terms: GNU General Public License v2
>> + *
>> + * Based on clk-sun6i-apbs.c
>> + * Allwinner A31 APB0 clock driver
>> + *
>> + * Copyright (C) 2014 Free Electrons
>> + * Author: Boris BREZILLON <boris.brezillon at free-electrons.com>
>> + *
>> + */
>> +
>> +#include <linux/clk-provider.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/platform_device.h>
>> +
>> +static void sun9i_apbs_setup(struct device_node *node)
>> +{
>> +     const char *name = node->name;
>> +     const char *parent;
>> +     struct resource res;
>> +     struct clk *clk;
>> +     void __iomem *reg;
>> +     int ret;
>> +
>> +     reg = of_io_request_and_map(node, 0, of_node_full_name(node));
>> +     if (IS_ERR(reg)) {
>> +             pr_err("Could not get registers for a80-apbs-clk\n");
>> +             return;
>> +     }
>> +
>> +     parent = of_clk_get_parent_name(node, 0);
>> +     if (!parent)
>> +             return;
>> +
>> +     of_property_read_string(node, "clock-output-names", &name);
>> +
>> +     /* The A80 APBS clock is a standard 2 bit wide divider clock */
>> +     clk = clk_register_divider(NULL, name, parent, 0, reg, 0, 2, 0, NULL);
>> +     if (IS_ERR(clk)) {
>> +             pr_err("failed to register a80-apbs-clk: %ld\n", PTR_ERR(clk));
>> +             goto err_unmap;
>> +     }
>> +
>> +     ret = of_clk_add_provider(node, of_clk_src_simple_get, clk);
>> +     if (ret)
>> +             goto err_unregister;
>> +
>> +     return;
>> +
>> +err_unregister:
>> +     clk_unregister_divider(clk);
>> +err_unmap:
>> +     iounmap(reg);
>> +     of_address_to_resource(node, 0, &res);
>> +     release_mem_region(res.start, resource_size(&res));
>> +}
>> +CLK_OF_DECLARE(sun9i_apbs, "allwinner,sun9i-a80-apbs-clk", sun9i_apbs_setup);
>
> So it's just a different set of flags? Maybe we can simply reuse the
> same driver.

We could. I'll look into it.

ChenYu


From a0393675 at ti.com  Tue Feb  9 19:37:37 2016
From: a0393675 at ti.com (Keerthy)
Date: Wed, 10 Feb 2016 09:07:37 +0530
Subject: [PATCH 0/3] arm: dts: DRA7: Add IVA and DSPEVE thermal domain data
In-Reply-To: <20160209215326.GC27284@localhost.localdomain>
References: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>
 <20160208195704.GW19432@atomide.com> <56B95EF7.9080107@ti.com>
 <20160209215326.GC27284@localhost.localdomain>
Message-ID: <56BAB081.5040005@ti.com>



On Wednesday 10 February 2016 03:23 AM, Eduardo Valentin wrote:
> On Tue, Feb 09, 2016 at 09:07:27AM +0530, Keerthy wrote:
>>
>>
>> On Tuesday 09 February 2016 01:27 AM, Tony Lindgren wrote:
>>> * Keerthy <j-keerthy at ti.com> [160208 01:19]:
>>>> OMAP5 has 3 thermal zones cpu, core and multimedia.
>>>> On the other hand DRA7 has 5 thermal zones cpu, gpu, core, dspeve
>>>> and iva. Currently cpu, core and multimedia are being added via dt
>>>> and the other 2 are getting added via kernel. Add the missing thermal
>>>> domains in dt so as give the correct trip numbers, type and temperatures.
>
> But the driver would add these default domains only if booted /loaded with
> missing DT device entry, right?

Yes Eduardo, but with default trip values not the absolute which is 
added with this patch series.

>


From dhdang at apm.com  Tue Feb  9 19:46:57 2016
From: dhdang at apm.com (Duc Dang)
Date: Tue, 9 Feb 2016 19:46:57 -0800
Subject: [PATCH v5 1/3] mailbox: Add support for APM X-Gene platform
 mailbox driver
In-Reply-To: <CANLsYkwp4vJN+LcNm=7Xm=RppFnsPEXSAARS7=g6CZSsk5M5qw@mail.gmail.com>
References: <CABb+yY1cE152ZdfK_aeB8ufG=WfoUVB6BN8kXPphYgMBnpH-GA@mail.gmail.com>
 <cover.1454967957.git.dhdang@apm.com>
 <90cb13a0b4d3817c18c11c183128c08d6458bf8d.1454967957.git.dhdang@apm.com>
 <CANLsYkwp4vJN+LcNm=7Xm=RppFnsPEXSAARS7=g6CZSsk5M5qw@mail.gmail.com>
Message-ID: <CADaLNDktgAnq5VHGj=B0iO9-GnMAamTEVELYuBTVegeL3QZ4Sw@mail.gmail.com>

On Tue, Feb 9, 2016 at 8:40 AM, Mathieu Poirier
<mathieu.poirier at linaro.org> wrote:
> On 8 February 2016 at 15:04, Duc Dang <dhdang at apm.com> wrote:
>> X-Gene mailbox controller provides 8 mailbox channels, with
>> each channel has a dedicated interrupt line.
>>
>> Signed-off-by: Feng Kan <fkan at apm.com>
>> Signed-off-by: Duc Dang <dhdang at apm.com>
>> ---
>> Changes since v4:
>>         - Rebase over v4.5-rc1
>>         - Fix section mistmatch warning by removing
>>         __init in slimpro_mbox_probe declaration
>>         - Correctly print channel number when
>>         there is no IRQ for that channel
>>
>> Changes since v3:
>>         - Rebase over v4.4
>>         - Remove 'id' in slimpro_mbox_chan structure
>>         - Remove small functions that are only called once
>>         and fold them into the other callers
>>         - Remove void* pointer type cast
>>         - Relax the number of mailbox IRQs condition
>>         - Use subsys_initcall to guarantee mailbox driver
>>         will be registered before any other dependent driver
>>         is loaded.
>>
>>  drivers/mailbox/Kconfig                 |   9 ++
>>  drivers/mailbox/Makefile                |   2 +
>>  drivers/mailbox/mailbox-xgene-slimpro.c | 264 ++++++++++++++++++++++++++++++++
>>  3 files changed, 275 insertions(+)
>>  create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c
>>
>> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
>> index 546d05f..678e434 100644
>> --- a/drivers/mailbox/Kconfig
>> +++ b/drivers/mailbox/Kconfig
>> @@ -85,4 +85,13 @@ config MAILBOX_TEST
>>           Test client to help with testing new Controller driver
>>           implementations.
>>
>> +config XGENE_SLIMPRO_MBOX
>> +       tristate "APM SoC X-Gene SLIMpro Mailbox Controller"
>> +       depends on ARCH_XGENE
>> +       help
>> +         An implementation of the APM X-Gene Interprocessor Communication
>> +         Mailbox (IPCM) between the ARM 64-bit cores and SLIMpro controller.
>> +         It is used to send short messages between ARM64-bit cores and
>> +         the SLIMpro Management Engine, primarily for PM. Say Y here if you
>> +         want to use the APM X-Gene SLIMpro IPCM support.
>>  endif
>> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
>> index 92435ef..b602ef8 100644
>> --- a/drivers/mailbox/Makefile
>> +++ b/drivers/mailbox/Makefile
>> @@ -17,3 +17,5 @@ obj-$(CONFIG_ALTERA_MBOX)     += mailbox-altera.o
>>  obj-$(CONFIG_BCM2835_MBOX)     += bcm2835-mailbox.o
>>
>>  obj-$(CONFIG_STI_MBOX)         += mailbox-sti.o
>> +
>> +obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
>> diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c b/drivers/mailbox/mailbox-xgene-slimpro.c
>> new file mode 100644
>> index 0000000..0ea1eb8
>> --- /dev/null
>> +++ b/drivers/mailbox/mailbox-xgene-slimpro.c
>> @@ -0,0 +1,264 @@
>> +/*
>> + * APM X-Gene SLIMpro MailBox Driver
>> + *
>> + * Copyright (c) 2015, Applied Micro Circuits Corporation
>> + * Author: Feng Kan fkan at apm.com
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of
>> + * the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * 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/delay.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/mailbox_controller.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/spinlock.h>
>> +
>> +#define MBOX_CON_NAME                  "slimpro-mbox"
>> +#define MBOX_REG_SET_OFFSET            0x1000
>> +#define MBOX_CNT                       8
>> +#define MBOX_STATUS_AVAIL_MASK         BIT(16)
>> +#define MBOX_STATUS_ACK_MASK           BIT(0)
>> +
>> +/* Configuration and Status Registers */
>> +#define REG_DB_IN              0x00
>> +#define REG_DB_DIN0            0x04
>> +#define REG_DB_DIN1            0x08
>> +#define REG_DB_OUT             0x10
>> +#define REG_DB_DOUT0           0x14
>> +#define REG_DB_DOUT1           0x18
>> +#define REG_DB_STAT            0x20
>> +#define REG_DB_STATMASK                0x24
>> +
>> +struct slimpro_mbox_chan {
>> +       struct device *dev;
>> +       struct mbox_chan *chan;
>> +       void __iomem *reg;
>> +       int irq;
>> +       u32 rx_msg[3];
>> +};
>> +
>> +struct slimpro_mbox {
>> +       struct mbox_controller mb_ctrl;
>> +       struct slimpro_mbox_chan mc[MBOX_CNT];
>> +       struct mbox_chan chans[MBOX_CNT];
>> +};
>
> The above two structure declaration could use kernel style documentation.

Can you please clarify or give an example? I looked into several files
in drivers/mailbox/ and drivers/irqchip but could not find what I need
to tweak.

>
>> +
>> +static void mb_chan_send_msg(struct slimpro_mbox_chan *mb_chan, u32 *msg)
>> +{
>> +       writel(msg[1], mb_chan->reg + REG_DB_DOUT0);
>> +       writel(msg[2], mb_chan->reg + REG_DB_DOUT1);
>> +       writel(msg[0], mb_chan->reg + REG_DB_OUT);
>> +}
>> +
>> +static void mb_chan_recv_msg(struct slimpro_mbox_chan *mb_chan)
>> +{
>> +       mb_chan->rx_msg[1] = readl(mb_chan->reg + REG_DB_DIN0);
>> +       mb_chan->rx_msg[2] = readl(mb_chan->reg + REG_DB_DIN1);
>> +       mb_chan->rx_msg[0] = readl(mb_chan->reg + REG_DB_IN);
>> +}
>
> Is there a requirement that operations in the above two functions be
> ordered?  If not significant gains could be achieved by using
> writel/readl_relaxed().  Same comment for the rest of this driver.

The 'writes' need to be in order as writing to REG_DB_OUT will trigger
interrupt, so I want the other 2 'writes' complete before it.

After the receiver get the message, it will clear door bell available
interrupt request, this will also trigger a door bell acknowledge
interrupt. So the 'read' to get the message and the 'write' to clear
the door bell available interrupt must be in order as well.

Regards,
Duc Dang.
>
> Thanks,
> Mathieu
>
>> +
>> +static int mb_chan_status_ack(struct slimpro_mbox_chan *mb_chan)
>> +{
>> +       u32 val = readl(mb_chan->reg + REG_DB_STAT);
>> +
>> +       if (val & MBOX_STATUS_ACK_MASK) {
>> +               writel(MBOX_STATUS_ACK_MASK, mb_chan->reg + REG_DB_STAT);
>> +               return 1;
>> +       }
>> +       return 0;
>> +}
>> +
>> +static int mb_chan_status_avail(struct slimpro_mbox_chan *mb_chan)
>> +{
>> +       u32 val = readl(mb_chan->reg + REG_DB_STAT);
>> +
>> +       if (val & MBOX_STATUS_AVAIL_MASK) {
>> +               mb_chan_recv_msg(mb_chan);
>> +               writel(MBOX_STATUS_AVAIL_MASK, mb_chan->reg + REG_DB_STAT);
>> +               return 1;
>> +       }
>> +       return 0;
>> +}
>> +
>> +static irqreturn_t slimpro_mbox_irq(int irq, void *id)
>> +{
>> +       struct slimpro_mbox_chan *mb_chan = id;
>> +
>> +       if (mb_chan_status_ack(mb_chan))
>> +               mbox_chan_txdone(mb_chan->chan, 0);
>> +
>> +       if (mb_chan_status_avail(mb_chan))
>> +               mbox_chan_received_data(mb_chan->chan, mb_chan->rx_msg);
>> +
>> +       return IRQ_HANDLED;
>> +}
>> +
>> +static int slimpro_mbox_send_data(struct mbox_chan *chan, void *msg)
>> +{
>> +       struct slimpro_mbox_chan *mb_chan = chan->con_priv;
>> +
>> +       mb_chan_send_msg(mb_chan, msg);
>> +       return 0;
>> +}
>> +
>> +static int slimpro_mbox_startup(struct mbox_chan *chan)
>> +{
>> +       struct slimpro_mbox_chan *mb_chan = chan->con_priv;
>> +       int rc;
>> +       u32 val;
>> +
>> +       rc = devm_request_irq(mb_chan->dev, mb_chan->irq, slimpro_mbox_irq, 0,
>> +                             MBOX_CON_NAME, mb_chan);
>> +       if (unlikely(rc)) {
>> +               dev_err(mb_chan->dev, "failed to register mailbox interrupt %d\n",
>> +                       mb_chan->irq);
>> +               return rc;
>> +       }
>> +
>> +       /* Enable HW interrupt */
>> +       writel(MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK,
>> +              mb_chan->reg + REG_DB_STAT);
>> +       /* Unmask doorbell status interrupt */
>> +       val = readl(mb_chan->reg + REG_DB_STATMASK);
>> +       val &= ~(MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK);
>> +       writel(val, mb_chan->reg + REG_DB_STATMASK);
>> +
>> +       return 0;
>> +}
>> +
>> +static void slimpro_mbox_shutdown(struct mbox_chan *chan)
>> +{
>> +       struct slimpro_mbox_chan *mb_chan = chan->con_priv;
>> +       u32 val;
>> +
>> +       /* Mask doorbell status interrupt */
>> +       val = readl(mb_chan->reg + REG_DB_STATMASK);
>> +       val |= (MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK);
>> +       writel(val, mb_chan->reg + REG_DB_STATMASK);
>> +
>> +       devm_free_irq(mb_chan->dev, mb_chan->irq, mb_chan);
>> +}
>> +
>> +static struct mbox_chan_ops slimpro_mbox_ops = {
>> +       .send_data = slimpro_mbox_send_data,
>> +       .startup = slimpro_mbox_startup,
>> +       .shutdown = slimpro_mbox_shutdown,
>> +};
>> +
>> +static int slimpro_mbox_probe(struct platform_device *pdev)
>> +{
>> +       struct slimpro_mbox *ctx;
>> +       struct resource *regs;
>> +       void __iomem *mb_base;
>> +       int rc;
>> +       int i;
>> +
>> +       ctx = devm_kzalloc(&pdev->dev, sizeof(struct slimpro_mbox), GFP_KERNEL);
>> +       if (IS_ERR(ctx))
>> +               return PTR_ERR(ctx);
>> +
>> +       platform_set_drvdata(pdev, ctx);
>> +
>> +       regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +       mb_base = devm_ioremap(&pdev->dev, regs->start, resource_size(regs));
>> +       if (IS_ERR(mb_base))
>> +               return PTR_ERR(mb_base);
>> +
>> +       /* Setup mailbox links */
>> +       for (i = 0; i < MBOX_CNT; i++) {
>> +               ctx->mc[i].irq = platform_get_irq(pdev, i);
>> +               if (ctx->mc[i].irq < 0) {
>> +                       if (i == 0) {
>> +                               dev_err(&pdev->dev, "no available IRQ\n");
>> +                               return -EINVAL;
>> +                       }
>> +                       dev_info(&pdev->dev, "no IRQ for channel %d\n", i);
>> +                       break;
>> +               }
>> +
>> +               ctx->mc[i].dev = &pdev->dev;
>> +               ctx->mc[i].reg = mb_base + i * MBOX_REG_SET_OFFSET;
>> +               ctx->mc[i].chan = &ctx->chans[i];
>> +               ctx->chans[i].con_priv = &ctx->mc[i];
>> +       }
>> +
>> +       /* Setup mailbox controller */
>> +       ctx->mb_ctrl.dev = &pdev->dev;
>> +       ctx->mb_ctrl.chans = ctx->chans;
>> +       ctx->mb_ctrl.txdone_irq = true;
>> +       ctx->mb_ctrl.ops = &slimpro_mbox_ops;
>> +       ctx->mb_ctrl.num_chans = i;
>> +
>> +       rc = mbox_controller_register(&ctx->mb_ctrl);
>> +       if (rc) {
>> +               dev_err(&pdev->dev,
>> +                       "APM X-Gene SLIMpro MailBox register failed:%d\n", rc);
>> +               return rc;
>> +       }
>> +
>> +       dev_info(&pdev->dev, "APM X-Gene SLIMpro MailBox registered\n");
>> +       return 0;
>> +}
>> +
>> +static int slimpro_mbox_remove(struct platform_device *pdev)
>> +{
>> +       struct slimpro_mbox *smb = platform_get_drvdata(pdev);
>> +
>> +       mbox_controller_unregister(&smb->mb_ctrl);
>> +       return 0;
>> +}
>> +
>> +static const struct of_device_id slimpro_of_match[] = {
>> +       {.compatible = "apm,xgene-slimpro-mbox" },
>> +       { },
>> +};
>> +MODULE_DEVICE_TABLE(of, slimpro_of_match);
>> +
>> +#ifdef CONFIG_ACPI
>> +static const struct acpi_device_id slimpro_acpi_ids[] = {
>> +       {"APMC0D01", 0},
>> +       {}
>> +};
>> +MODULE_DEVICE_TABLE(acpi, slimpro_acpi_ids);
>> +#endif
>> +
>> +static struct platform_driver slimpro_mbox_driver = {
>> +       .probe  = slimpro_mbox_probe,
>> +       .remove = slimpro_mbox_remove,
>> +       .driver = {
>> +               .name = "xgene-slimpro-mbox",
>> +               .of_match_table = of_match_ptr(slimpro_of_match),
>> +               .acpi_match_table = ACPI_PTR(slimpro_acpi_ids)
>> +       },
>> +};
>> +
>> +static int __init slimpro_mbox_init(void)
>> +{
>> +       return platform_driver_register(&slimpro_mbox_driver);
>> +}
>> +
>> +static void __exit slimpro_mbox_exit(void)
>> +{
>> +       platform_driver_unregister(&slimpro_mbox_driver);
>> +}
>> +
>> +subsys_initcall(slimpro_mbox_init);
>> +module_exit(slimpro_mbox_exit);
>> +
>> +MODULE_DESCRIPTION("APM X-Gene SLIMpro Mailbox Driver");
>> +MODULE_LICENSE("GPL");
>> --
>> 1.9.1
>>


From lkp at intel.com  Tue Feb  9 20:10:33 2016
From: lkp at intel.com (kbuild test robot)
Date: Wed, 10 Feb 2016 12:10:33 +0800
Subject: [PATCH] pci: xgene: Add ECAM fixups
In-Reply-To: <1455068984-22210-1-git-send-email-dhdang@apm.com>
Message-ID: <201602101236.v5Xf48zl%fengguang.wu@intel.com>

Hi Duc,

[auto build test ERROR on pci/next]
[also build test ERROR on v4.5-rc3 next-20160209]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Duc-Dang/pci-xgene-Add-ECAM-fixups/20160210-095702
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: arm64-allyesconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

>> drivers/pci/host/pci-xgene.c:34:24: fatal error: linux/ecam.h: No such file or directory
    #include <linux/ecam.h>
                           ^
   compilation terminated.

vim +34 drivers/pci/host/pci-xgene.c

    28	#include <linux/of_pci.h>
    29	#include <linux/pci.h>
    30	#include <linux/platform_device.h>
    31	#include <linux/slab.h>
    32	#ifdef CONFIG_ACPI
    33	#include <linux/acpi.h>
  > 34	#include <linux/ecam.h>
    35	#include <linux/pci-acpi.h>
    36	#endif
    37	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 48147 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160210/ef5471ae/attachment-0001.obj>

From raveendra.padasalagi at broadcom.com  Tue Feb  9 20:54:43 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Wed, 10 Feb 2016 10:24:43 +0530
Subject: [PATCH 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <20160209174351.GC40460@dtor-ws>
References: <1455008277-8312-1-git-send-email-raveendra.padasalagi@broadcom.com>
 <1455008277-8312-2-git-send-email-raveendra.padasalagi@broadcom.com>
 <2631849.GeOulu78vx@wuerfel> <3b53af6b6c6735d10cb88518c8b8a0ae@mail.gmail.com>
 <20160209174351.GC40460@dtor-ws>
Message-ID: <979fb4dc5fba643a6780759d2a13530a@mail.gmail.com>

> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov at gmail.com]
> Sent: 09 February 2016 23:14
> To: Raveendra Padasalagi
> Cc: Arnd Bergmann; Russell King; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-input at vger.kernel.org; Rob Herring;
Pawel
> Moll; Mark Rutland; Ian Campbell; Kumar Gala; Jonathan Richardson; Jon
> Mason; Florian Fainelli; Ray Jui; Scott Branden;
linux-kernel at vger.kernel.org;
> bcm-kernel-feedback-list at broadcom.com
> Subject: Re: [PATCH 1/3] input: cygnus-update touchscreen dt node
document
>
> On Tue, Feb 09, 2016 at 10:25:26PM +0530, Raveendra Padasalagi wrote:
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > Sent: 09 February 2016 16:34
> > > To: Raveendra Padasalagi
> > > Cc: Dmitry Torokhov; Russell King; devicetree at vger.kernel.org;
> > linux-arm-
> > > kernel at lists.infradead.org; linux-input at vger.kernel.org; Rob
> > > Herring;
> > Pawel
> > > Moll; Mark Rutland; Ian Campbell; Kumar Gala; Jonathan Richardson;
> > > Jon Mason; Florian Fainelli; Ray Jui; Scott Branden;
> > linux-kernel at vger.kernel.org;
> > > bcm-kernel-feedback-list at broadcom.com
> > > Subject: Re: [PATCH 1/3] input: cygnus-update touchscreen dt node
> > document
> > >
> > > On Tuesday 09 February 2016 14:27:55 Raveendra Padasalagi wrote:
> > > > +
> > > > +One of the below 2 property is mandatory.
> > > > +- ts_syscon: handler of syscon node defining physical base
> > > > +address
> > > > +  of the controller and length of memory mapped region.
> > > > +  If this property is selected please make sure MFD_SYSCON config
> > > > +  is enabled in the defconfig file.
> > > > +or
> > > > +- reg: physical base address of the controller and length of
> > > > +memory
> > > > +  mapped region.
> > > > +
> > > >  - clocks:  The clock provided by the SOC to driver the tsc
> > > >  - clock-name:  name for the clock
> > > >  - interrupts: The touchscreen controller's interrupt @@ -54,12
> > > > +62,16 @@ Optional properties:
> > > >  - touchscreen-inverted-y: Y axis is inverted (boolean)
> > > >
> > > >  Example:
> > > > +       ts_adc_syscon: ts_adc_syscon at 0x180a6000 {
> > > > +               compatible = "syscon";
> > > > +               reg = <0x180a6000 0xc30>;
> > > > +       };
> > > >
> > > >         touchscreen: tsc at 0x180A6000 {
> > > >                 compatible = "brcm,iproc-touchscreen";
> > > >                 #address-cells = <1>;
> > > >                 #size-cells = <1>;
> > > > -               reg = <0x180A6000 0x40>;
> > > > +               syscon = <&ts_adc_syscon>;
> > > >                 clocks = <&adc_clk>;
> > > >                 clock-names = "tsc_clk";
> > > >                 interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
> > >
> > > This doesn't seem right: For one thing, it's an incompatible binding
> > change which
> > > you should try to avoid.
> >
> > > Worse, the syscon has a name indicating that it really has a
> > > particular
> > function,
> > > but the name is completely generic (just "syscon"). Please add a
> > specific
> > > compatible string identifying the device that owns the registers,
> > > and
> > put any
> > > other associated properties (clocks, interrupts, ...) that are for
> > > that
> > device in
> > > general rather than just the touchscreen in there.
> >
> > By mistake "syscon" name is documented in "touchscreen" label above.
> > In the touchscreen driver code and .dtsi file it's named and used as
> > "ts_syscon".
> > Please refer https://lkml.org/lkml/2016/2/9/71 for the changes.
> > Let me know if this ok. I will correct the documentation in the next
> > patch.
> >
> > > Your changelog text fails to describe why you do this change in the
> > first place,
> > > and why you can't do it in a backward-compatible way, so please
> > > rewrite
> > that
> > > text.
> >
> > Yes, I will update the change log in the next patch.
> >
> > In Cygnus SOC, Touch screen controller registers are shared with ADC
> > and flex timer IP's.
> > Using readl/writel could lead to race condition. So this patch is
> > introduced to take care mutually exclusive access of register's in
> > such a case.
> >
> > In the platform's where touchscreen register's are not shared normal
> > readl/writel could be used.
>
> Are there currently platforms where the registers are not shared? If we
have to
> use regmap to correctly update registers (and thus we need
> syscon) then I wonder if we should even attempt to support direct
register
> access by the driver.

Currently there are no platforms without register sharing, but we would
like to keep
the driver generic enough to take care of future SOC's if comes with
dedicated registers
and same touchscreen IP being re-used.
> >
> > Based on the dt  property entry "reg" or "ts_syscon" register accesses
> > are handled.
> > if "reg" is provided normal readl/writel API's are used to access
> > register's else if "ts_syscon" is provided then syscon API's are used.
>
> If we decide that we still allow register access then please change the
driver so it
> instantiates its own regmap instance in this case instead of doing
checks all the
> time.

Using remap will leads to overhead of locking and unlocking for each
register access
in case if a dedicated register's present in the platform. I think current
implementation
of simple check of regs or remap is better over using regmap read/write
calls with locking
overhead. Let me know your opinion.



> Thanks.
>
> --
> Dmitry


From sudipm.mukherjee at gmail.com  Tue Feb  9 21:21:26 2016
From: sudipm.mukherjee at gmail.com (Sudip Mukherjee)
Date: Wed, 10 Feb 2016 10:51:26 +0530
Subject: [PATCH v2 2/9] Staging: rts5208: rtsx_transport.c: Align to open
 parenthesis
In-Reply-To: <1454981485-15686-3-git-send-email-shaun.ren@linux.com>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-3-git-send-email-shaun.ren@linux.com>
Message-ID: <20160210052126.GB27755@sudip-pc>

On Mon, Feb 08, 2016 at 05:31:18PM -0800, Shaun Ren wrote:
> This patch fixes the alignment issue reported by checkpatch.pl:
> 
> CHECK: Alignment should match open parenthesis
> 
> Signed-off-by: Shaun Ren <shaun.ren at linux.com>
> ---
>  drivers/staging/rts5208/rtsx_transport.c | 61 ++++++++++++++++++--------------
>  1 file changed, 35 insertions(+), 26 deletions(-)
> 
<snip>
>  
> @@ -732,11 +739,13 @@ int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
>  	if (rtsx_chk_stat(chip, RTSX_STAT_ABORT))
>  		return -EIO;
>  
> -	if (use_sg)
> -		err = rtsx_transfer_sglist_adma_partial(chip, card,
> -				(struct scatterlist *)buf, use_sg,
> -				index, offset, (int)len, dma_dir, timeout);
> -	else
> +	if (use_sg) {
> +		struct scatterlist *sg = (struct scatterlist *)buf;

this change is not documented in commit message.	
> +
> +		err = rtsx_transfer_sglist_adma_partial(chip, card, sg, use_sg,
> +							index, offset, (int)len,
> +							dma_dir, timeout);
> +	} else

This will introduce new checkpatch warning. If you are giving braces in
the if block then you need to have braces in the else part also.

regards
sudip


From sudipm.mukherjee at gmail.com  Tue Feb  9 21:26:41 2016
From: sudipm.mukherjee at gmail.com (Sudip Mukherjee)
Date: Wed, 10 Feb 2016 10:56:41 +0530
Subject: [PATCH v2 7/9] Staging: rts5208: rtsx_transport.c: Remove
 unnecessary parentheses
In-Reply-To: <1454981485-15686-8-git-send-email-shaun.ren@linux.com>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-8-git-send-email-shaun.ren@linux.com>
Message-ID: <20160210052641.GC27755@sudip-pc>

On Mon, Feb 08, 2016 at 05:31:23PM -0800, Shaun Ren wrote:
> This patch removes all unnecessary parentheses found by checkpatch.pl.
> 
> Signed-off-by: Shaun Ren <shaun.ren at linux.com>

This will not apply anymore because of some other changes done by:
9a66d05d82db ("Staging: rts5208: fix check for dma mapping error")

regards
sudip


From kishon at ti.com  Tue Feb  9 21:36:46 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 10 Feb 2016 11:06:46 +0530
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
Message-ID: <56BACC6E.3060908@ti.com>



On Wednesday 10 February 2016 01:06 AM, Paul Walmsley wrote:
> Hi Suman 
> 
> On Tue, 9 Feb 2016, Suman Anna wrote:
> 
>> On 02/09/2016 02:49 AM, Paul Walmsley wrote:
>>> On Mon, 8 Feb 2016, Suman Anna wrote:
>>>> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
>>>>> On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:
>>>>>
>>>>>> Paul, what do you think is the best way forward to perform reset?
>>>>>
>>>>> Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
>>>>> Those often need special reset handling to ensure that WFI/HLT-like 
>>>>> instructions are executed after reset.  This special handling ensures that 
>>>>> the IP blocks' bus initiator interfaces indicate that they are in standby 
>>>>> to the PRCM - thus allowing power management for the rest of the chip to 
>>>>> work correctly.
>>>>>
>>>>> But that doesn't seem to be the case with PCIe - and maybe others - 
>>>>> possibly some of the MMUs?  
>>>>
>>>> Yeah, the sequencing between clocks and resets would still be the same
>>>> for MMUs, so, adding the custom flags for MMUs is fine.
>>>
>>> I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs.  
>>> We've stated that the main point of the custom hardreset code is to handle 
>>> processors that need to be placed into WFI/HLT, but it doesn't seem like 
>>> there would be an equivalent for MMUs.  Thoughts?
>>
>> The current OMAP IOMMU code already leverages the pdata ops for
>> performing the resets, so not adding the flags would also require
>> additional changes in the driver.
>>
>> Also, the reset lines controlling the MMUs actually also manage the
>> reset for all the other sub-modules other than the processor cores
>> within the sub-systems. We have currently different issues (see [1] for
>> eg. around the IPU sub-system entering RET in between), so from a PM
>> point of view, we do prefer to place the MMUs also in reset when we are
>> runtime suspended.
> 
> Should we reassert hardreset in _idle() for IP blocks that don't have 
> HWMOD_CUSTOM_HARDRESET set on them?  Would that allow us to use this 
> mechanism for the uncore hardreset lines, or are there other quirks?

IIUC _idle() will be called on pm_runtime_put. That would mean we perform reset
on every suspend/resume cycle which is not desired. (suspend/resume support for
PCIe is not yet in mainline but once we have it runtime_put and runtime_get
will be invoked during suspend/resume cycle). Let me know if my understanding
is wrong.

Thanks
Kishon
> 
> Also - would that address the potential issue that you mentioned with the 
> PCIe block, or is that a different issue?
> 
> 
> - Paul
> 


From kishon at ti.com  Tue Feb  9 21:38:35 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 10 Feb 2016 11:08:35 +0530
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <56BA958A.1020503@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com>
Message-ID: <56BACCDB.2070507@ti.com>

Hi,

On Wednesday 10 February 2016 07:12 AM, Suman Anna wrote:
> Hi Paul,
> 
> On 02/09/2016 01:36 PM, Paul Walmsley wrote:
>> Hi Suman 
>>
>> On Tue, 9 Feb 2016, Suman Anna wrote:
>>
>>> On 02/09/2016 02:49 AM, Paul Walmsley wrote:
>>>> On Mon, 8 Feb 2016, Suman Anna wrote:
>>>>> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
>>>>>> On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:
>>>>>>
>>>>>>> Paul, what do you think is the best way forward to perform reset?
>>>>>>
>>>>>> Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
>>>>>> Those often need special reset handling to ensure that WFI/HLT-like 
>>>>>> instructions are executed after reset.  This special handling ensures that 
>>>>>> the IP blocks' bus initiator interfaces indicate that they are in standby 
>>>>>> to the PRCM - thus allowing power management for the rest of the chip to 
>>>>>> work correctly.
>>>>>>
>>>>>> But that doesn't seem to be the case with PCIe - and maybe others - 
>>>>>> possibly some of the MMUs?  
>>>>>
>>>>> Yeah, the sequencing between clocks and resets would still be the same
>>>>> for MMUs, so, adding the custom flags for MMUs is fine.
>>>>
>>>> I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs.  
>>>> We've stated that the main point of the custom hardreset code is to handle 
>>>> processors that need to be placed into WFI/HLT, but it doesn't seem like 
>>>> there would be an equivalent for MMUs.  Thoughts?
>>>
>>> The current OMAP IOMMU code already leverages the pdata ops for
>>> performing the resets, so not adding the flags would also require
>>> additional changes in the driver.
>>>
>>> Also, the reset lines controlling the MMUs actually also manage the
>>> reset for all the other sub-modules other than the processor cores
>>> within the sub-systems. We have currently different issues (see [1] for
>>> eg. around the IPU sub-system entering RET in between), so from a PM
>>> point of view, we do prefer to place the MMUs also in reset when we are
>>> runtime suspended.
>>
>> Should we reassert hardreset in _idle() for IP blocks that don't have 
>> HWMOD_CUSTOM_HARDRESET set on them?  Would that allow us to use this 
>> mechanism for the uncore hardreset lines, or are there other quirks?
>>
>> Also - would that address the potential issue that you mentioned with the 
>> PCIe block, or is that a different issue?
> 
> Yeah, I think that would address the PCIe block issue in terms of reset
> state balancing between pm_runtime_get_sync() and pm_runtime_put()
> calls. Right now, they are unbalanced. The PCIe block is using these
> only in probe and remove, so it should work for that IP.

As I mentioned before this would result in undesired behavior during
suspend/resume cycle in PCIe. (This should be okay for the current mainline
code but would break once we add suspend/resume support for PCIe).

Thanks
Kishon


From bharat.kumar.gogada at xilinx.com  Tue Feb  9 21:55:51 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Wed, 10 Feb 2016 05:55:51 +0000
Subject: [PATCH V3 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge
 driver to work on both  Zynq and Microblaze
In-Reply-To: <20160209161134.GA24244@NP-P-BURTON>
References: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
 <1455014518-8708-4-git-send-email-bharatku@xilinx.com>
 <20160209161134.GA24244@NP-P-BURTON>
Message-ID: <8520D5D51A55D047800579B09414719825881780@XAP-PVEXMBX01.xlnx.xilinx.com>

> On Tue, Feb 09, 2016 at 04:11:56PM +0530, Bharat Kumar Gogada wrote:
> > Modifying Xilinx AXI PCIe Host Bridge Soft IP driver to work on both
> > Zynq and Microblaze Architectures.
> > With these modifications drivers/pci/host/pcie-xilinx.c, will work on
> > both Zynq and Microblaze Architectures.
> >
> > Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> > Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
> > ---
> > Changes:
> > Removed unneccessary architecture dependent number of MSI's.
> > Added #ifdef to pci_fixup_irqs which is ARM specific API.
> 
> Hi Bharat,
> 
> Why do you say pci_fixup_irqs is ARM-specific? It's declared in
> include/linux/pci.h, defined in drivers/pci/setup-irq.c & used by multiple
> architectures (alpha, arm, m68k, mips, sh, sparc, tile,
> unicore32 from a quick grep).
> 
> Will you not break INTX-style interrupts by removing this?
> 
I meant to say ARM specific w.r.t Microblaze architecture, which is what this patch series are for. This has been already discussed in my previous patch by  Arnd Bergmann and Lorenzo Pieralisi . (https://lkml.org/lkml/2016/1/12/707)

Bharat

From anup.patel at broadcom.com  Tue Feb  9 22:10:45 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Wed, 10 Feb 2016 11:40:45 +0530
Subject: [PATCH 0/6] More updates for NS2 DT
Message-ID: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>

This patchset primarily adds more DT nodes for NS2 SVK. It also does
minor update to arch/arm64/Kconfig.platforms and adds missing DT
bindings document for sp805 driver.

The patchset is based on v4.5-rc3 tag and is available in ns2_dt2_v1
branch of https://github.com/Broadcom/arm64-linux.git

All patches have been tested on Broadcom NS2 SVK.

Anup Patel (5):
  arm64: Select COMMON_CLK_IPROC, PINCTRL and GPIOLIB for iProc SoCs
  arm64: dts: Add SDHCI DT node for NS2
  arm64: dts: Add ARM SP804 timer DT nodes for NS2
  dt-bindings: watchdog: Add ARM SP805 DT bindings
  arm64: dts: Add ARM SP805 watchdog DT node for NS2

Ray Jui (1):
  arm64: dts: Add PCIe0 and PCIe4 DT nodes for NS2

 .../devicetree/bindings/watchdog/arm,sp805.txt     |  17 +++
 arch/arm64/Kconfig.platforms                       |   3 +
 arch/arm64/boot/dts/broadcom/ns2-svk.dts           |  12 ++
 arch/arm64/boot/dts/broadcom/ns2.dtsi              | 140 +++++++++++++++++++++
 4 files changed, 172 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/arm,sp805.txt

-- 
1.9.1



From anup.patel at broadcom.com  Tue Feb  9 22:10:46 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Wed, 10 Feb 2016 11:40:46 +0530
Subject: [PATCH 1/6] arm64: Select COMMON_CLK_IPROC,
 PINCTRL and GPIOLIB for iProc SoCs
In-Reply-To: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
References: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <1455084651-29325-2-git-send-email-anup.patel@broadcom.com>

We select COMMON_CLK_IPROC, PINCTRL, and GPIOLIB in arm64 Kconfig
for ARCH_BCM_IPROC so that we can use COMMON_CLK, PINCTRL and GPIOLIB
with iProc SoC drivers.

Signed-off-by: Anup Patel <anup.patel at broadcom.com>
Signed-off-by: Ray Jui <rjui at broadcom.com>
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yrdreddy at broadcom.com>
---
 arch/arm64/Kconfig.platforms | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f6..e20b50c 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -2,6 +2,9 @@ menu "Platform selection"
 
 config ARCH_BCM_IPROC
 	bool "Broadcom iProc SoC Family"
+	select COMMON_CLK_IPROC
+	select PINCTRL
+	select ARCH_REQUIRE_GPIOLIB
 	help
 	  This enables support for Broadcom iProc based SoCs
 
-- 
1.9.1



From anup.patel at broadcom.com  Tue Feb  9 22:10:47 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Wed, 10 Feb 2016 11:40:47 +0530
Subject: [PATCH 2/6] arm64: dts: Add SDHCI DT node for NS2
In-Reply-To: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
References: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <1455084651-29325-3-git-send-email-anup.patel@broadcom.com>

The IPROC SDHCI driver works fine for SDIO 3.0 on NS2 so let's enable
it for NS2 SoC in NS2 DT.

Signed-off-by: Anup Patel <anup.patel at broadcom.com>
Reviewed-by: Vikram Prakash <vikramp at broadcom.com>
Reviewed-by: Ray Jui <rjui at broadcom.com>
---
 arch/arm64/boot/dts/broadcom/ns2-svk.dts |  4 ++++
 arch/arm64/boot/dts/broadcom/ns2.dtsi    | 18 ++++++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index 6bb3d4d..3321bd1 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -64,6 +64,10 @@
 	status = "ok";
 };
 
+&sdio0 {
+	status = "ok";
+};
+
 &nand {
 	nandcs at 0 {
 		compatible = "brcm,nandcs";
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index a510d3a..b1f352d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -291,6 +291,24 @@
 			reg = <0x66220000 0x28>;
 		};
 
+		sdio0: sdhci at 66420000 {
+			compatible = "brcm,sdhci-iproc-cygnus";
+			reg = <0x66420000 0x100>;
+			interrupts = <GIC_SPI 421 IRQ_TYPE_LEVEL_HIGH>;
+			bus-width = <8>;
+			clocks = <&genpll_sw BCM_NS2_GENPLL_SW_SDIO_CLK>;
+			status = "disabled";
+		};
+
+		sdio1: sdhci at 66430000 {
+			compatible = "brcm,sdhci-iproc-cygnus";
+			reg = <0x66430000 0x100>;
+			interrupts = <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>;
+			bus-width = <8>;
+			clocks = <&genpll_sw BCM_NS2_GENPLL_SW_SDIO_CLK>;
+			status = "disabled";
+		};
+
 		nand: nand at 66460000 {
 			compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
 			reg = <0x66460000 0x600>,
-- 
1.9.1



From anup.patel at broadcom.com  Tue Feb  9 22:10:48 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Wed, 10 Feb 2016 11:40:48 +0530
Subject: [PATCH 3/6] arm64: dts: Add ARM SP804 timer DT nodes for NS2
In-Reply-To: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
References: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <1455084651-29325-4-git-send-email-anup.patel@broadcom.com>

We have four ARM SP804 dual-mode timer instances in NS2 SoC
hence this patch adds appropriate DT nodes for NS2.

Signed-off-by: Anup Patel <anup.patel at broadcom.com>
Reviewed-by: Ray Jui <rjui at broadcom.com>
Reviewed-by: Pramod KUMAR <pramodku at broadcom.com>
Reviewed-by: Scott Branden <sbranden at broadcom.com>
---
 arch/arm64/boot/dts/broadcom/ns2.dtsi | 40 +++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index b1f352d..83e1c27 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -256,6 +256,46 @@
 			      <0x65260000 0x1000>;
 		};
 
+		timer0: timer at 66030000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x66030000 0x1000>;
+			interrupts = <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&iprocslow>,
+				 <&iprocslow>,
+				 <&iprocslow>;
+			clock-names = "timer1", "timer2", "apb_pclk";
+		};
+
+		timer1: timer at 66040000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x66040000 0x1000>;
+			interrupts = <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&iprocslow>,
+				 <&iprocslow>,
+				 <&iprocslow>;
+			clock-names = "timer1", "timer2", "apb_pclk";
+		};
+
+		timer2: timer at 66050000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x66050000 0x1000>;
+			interrupts = <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&iprocslow>,
+				 <&iprocslow>,
+				 <&iprocslow>;
+			clock-names = "timer1", "timer2", "apb_pclk";
+		};
+
+		timer3: timer at 66060000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x66060000 0x1000>;
+			interrupts = <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&iprocslow>,
+				 <&iprocslow>,
+				 <&iprocslow>;
+			clock-names = "timer1", "timer2", "apb_pclk";
+		};
+
 		i2c0: i2c at 66080000 {
 			compatible = "brcm,iproc-i2c";
 			reg = <0x66080000 0x100>;
-- 
1.9.1



From anup.patel at broadcom.com  Tue Feb  9 22:10:49 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Wed, 10 Feb 2016 11:40:49 +0530
Subject: [PATCH 4/6] dt-bindings: watchdog: Add ARM SP805 DT bindings
In-Reply-To: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
References: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <1455084651-29325-5-git-send-email-anup.patel@broadcom.com>

The ARM SP805 DT node is already present in various DTS files.
This patch adds missing DT bindings documentation for ARM SP805.

Signed-off-by: Anup Patel <anup.patel at broadcom.com>
Reviewed-by: Ray Jui <rjui at broadcom.com>
Reviewed-by: Vikram Prakash <vikramp at broadcom.com>
Reviewed-by: Scott Branden <sbranden at broadcom.com>
---
 .../devicetree/bindings/watchdog/arm,sp805.txt          | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/arm,sp805.txt

diff --git a/Documentation/devicetree/bindings/watchdog/arm,sp805.txt b/Documentation/devicetree/bindings/watchdog/arm,sp805.txt
new file mode 100644
index 0000000..6ebb77d
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/arm,sp805.txt
@@ -0,0 +1,17 @@
+ARM AMBA Primecell SP805 Watchdog
+
+Required properties:
+- compatible: Should be "arm,sp805" & "arm,primecell"
+- reg: Should contain location and length for watchdog timer register.
+- interrupts: Should contain the list of watchdog timer interrupts.
+- clocks: clocks driving the watchdog timer hardware. This list should be 2
+	clocks. With 2 clocks, the order is wdogclk clock, apb_pclk.
+
+Example:
+	wdt at 66090000 {
+		compatible = "arm,sp805", "arm,primecell";
+		reg = <0x66090000 0x1000>;
+		interrupts = <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&apb_pclk>,<&apb_pclk>;
+		clock-names = "wdogclk", "apb_pclk";
+	};
-- 
1.9.1



From anup.patel at broadcom.com  Tue Feb  9 22:10:50 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Wed, 10 Feb 2016 11:40:50 +0530
Subject: [PATCH 5/6] arm64: dts: Add ARM SP805 watchdog DT node for NS2
In-Reply-To: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
References: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <1455084651-29325-6-git-send-email-anup.patel@broadcom.com>

We have one ARM SP805 watchdog instance on NS2 for non-secure software
hence this patch adds appropriate watchdog DT node in NS2 DT.

Signed-off-by: Anup Patel <anup.patel at broadcom.com>
Reviewed-by: Ray Jui <rjui at broadcom.com>
Reviewed-by: Pramod KUMAR <pramodku at broadcom.com>
Reviewed-by: Scott Branden <sbranden at broadcom.com>
---
 arch/arm64/boot/dts/broadcom/ns2.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 83e1c27..062616b4 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -306,6 +306,14 @@
 			status = "disabled";
 		};
 
+		wdt0: watchdog at 66090000 {
+			compatible = "arm,sp805", "arm,primecell";
+			reg = <0x66090000 0x1000>;
+			interrupts = <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&iprocslow>, <&iprocslow>;
+			clock-names = "wdogclk", "apb_pclk";
+		};
+
 		i2c1: i2c at 660b0000 {
 			compatible = "brcm,iproc-i2c";
 			reg = <0x660b0000 0x100>;
-- 
1.9.1



From anup.patel at broadcom.com  Tue Feb  9 22:10:51 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Wed, 10 Feb 2016 11:40:51 +0530
Subject: [PATCH 6/6] arm64: dts: Add PCIe0 and PCIe4 DT nodes for NS2
In-Reply-To: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
References: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <1455084651-29325-7-git-send-email-anup.patel@broadcom.com>

From: Ray Jui <rjui at broadcom.com>

This patch enables PCIe0 and PCIe4 for NS2 by adding
appropriate DT nodes in NS2 DT.

Signed-off-by: Ray Jui <rjui at broadcom.com>
Signed-off-by: Anup Patel <anup.patel at broadcom.com>
Reviewed-by: Scott Branden <sbranden at broadcom.com>
---
 arch/arm64/boot/dts/broadcom/ns2-svk.dts |  8 ++++
 arch/arm64/boot/dts/broadcom/ns2.dtsi    | 74 ++++++++++++++++++++++++++++++++
 2 files changed, 82 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index 3321bd1..ce0ab84 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -52,6 +52,14 @@
 	};
 };
 
+&pcie0 {
+	status = "ok";
+};
+
+&pcie4 {
+	status = "ok";
+};
+
 &i2c0 {
 	status = "ok";
 };
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 062616b4..6f81c9d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -137,6 +137,80 @@
 		};
 	};
 
+	pcie0: pcie at 20020000 {
+		compatible = "brcm,iproc-pcie";
+		reg = <0 0x20020000 0 0x1000>;
+
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &gic GIC_SPI 281 IRQ_TYPE_NONE>;
+
+		linux,pci-domain = <0>;
+
+		bus-range = <0x00 0xff>;
+
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		ranges = <0x83000000 0 0x00000000 0 0x00000000 0 0x20000000>;
+
+		brcm,pcie-ob;
+		brcm,pcie-ob-oarr-size;
+		brcm,pcie-ob-axi-offset = <0x00000000>;
+		brcm,pcie-ob-window-size = <256>;
+
+		status = "disabled";
+
+		msi-parent = <&msi0>;
+		msi0: msi at 20020000 {
+			compatible = "brcm,iproc-msi";
+			msi-controller;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 277 IRQ_TYPE_NONE>,
+				     <GIC_SPI 278 IRQ_TYPE_NONE>,
+				     <GIC_SPI 279 IRQ_TYPE_NONE>,
+				     <GIC_SPI 280 IRQ_TYPE_NONE>;
+			brcm,num-eq-region = <1>;
+			brcm,num-msi-msg-region = <1>;
+		};
+	};
+
+	pcie4: pcie at 50020000 {
+		compatible = "brcm,iproc-pcie";
+		reg = <0 0x50020000 0 0x1000>;
+
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &gic GIC_SPI 305 IRQ_TYPE_NONE>;
+
+		linux,pci-domain = <4>;
+
+		bus-range = <0x00 0xff>;
+
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		ranges = <0x83000000 0 0x00000000 0 0x30000000 0 0x20000000>;
+
+		brcm,pcie-ob;
+		brcm,pcie-ob-oarr-size;
+		brcm,pcie-ob-axi-offset = <0x30000000>;
+		brcm,pcie-ob-window-size = <256>;
+
+		status = "disabled";
+
+		msi-parent = <&msi4>;
+		msi4: msi at 50020000 {
+			compatible = "brcm,iproc-msi";
+			msi-controller;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 301 IRQ_TYPE_NONE>,
+				     <GIC_SPI 302 IRQ_TYPE_NONE>,
+				     <GIC_SPI 303 IRQ_TYPE_NONE>,
+				     <GIC_SPI 304 IRQ_TYPE_NONE>;
+		};
+	};
+
 	soc: soc {
 		compatible = "simple-bus";
 		#address-cells = <1>;
-- 
1.9.1



From k at japko.eu  Tue Feb  9 23:17:14 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Wed, 10 Feb 2016 08:17:14 +0100
Subject: [linux-sunxi] Re: [PATCH v3 1/5] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <20160209171040.GR31506@lukather>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-2-git-send-email-k@japko.eu>
 <20160204154752.4df7808be3364a98c496c030@free.fr>
 <20160205111152.GA31506@lukather>
 <20160205115837.GD12071@box2.japko.eu>
 <20160209171040.GR31506@lukather>
Message-ID: <20160210071713.GA19622@box2.japko.eu>

On Tue, Feb 09, 2016 at 06:10:40PM +0100, Maxime Ripard wrote:
>> >>It seems that the other compatible strings are there for historical
>> >>reasons. Why do you need a new one with such a specific name?
>> >>
>> >>It would have been more sensible to add a generic compatible string as
>> >>"allwinner,apb-gates", letting the removal of the other strings for a
>> >>later patch...
>> >
>> >Yeah, it's a good idea, and it's probably time that we move to that.
>> >
>> >However, I'd like to keep per-soc and per-clocks compatibles in the
>> >DT, in case we need to protect a clock in the future. That doesn't
>> >prevent to have two compatibles thoughe, the specific and the generic.
>> >
>>
>> So now I'm not sure what you mean. You suggest that I should keep using
>> specific (sun8i_h3_apb0) or change to generic (apb-gates) in my patch?
>
>Both.
>
>To have something like that:
>
>compatible = "allwinner,sun8i-h3-apb0-gates-clk", "allwinner,sun4i-a10-gates-clk";
>
>sun4i-a10-gates-clk being the generic compatible that we would use,
>and we can always match against the h3 specific compatible if we need
>to have a different behaviour.

This seems like a good idea to me but since this is new thing anyways 
(other sunxi SoCs don't do this right now) shouldn't we introduce other
more generic name for generic clock (like "allwinner,apb-gates" 
mentioned earlier, or maybe "allwinner,simple-apb-gates")?

Also, wouldn't this be cleaner if I use only specific compatible string 
right now and provide separate patch that adds generic compatible string 
to all current SoCs at once? The downside of this is that it's easier to 
get merge conflicts unless I wait for applying this patchset.

Best regards,
Krzysztof Adamski


From linux.amoon at gmail.com  Tue Feb  9 23:27:50 2016
From: linux.amoon at gmail.com (Anand Moon)
Date: Wed, 10 Feb 2016 12:57:50 +0530
Subject: lockdep: INFO: possible irq lock inversion dependency detected on
 Odroid U3
Message-ID: <CANAwSgRgFMNWGhTe7xsHqkQQ1JS0XW6pO8LT8c6rZm=3cEBcbg@mail.gmail.com>

Hi all,

I am observing following lockdep info.

[  139.806823] =========================================================
[  139.811934] [ INFO: possible irq lock inversion dependency detected ]
[  139.818362] 4.5.0-rc3-u3s #11 Tainted: G        W
[  139.823566] ---------------------------------------------------------
[  139.829990] swapper/0/0 just changed the state of lock:
[  139.835197]  (&(&substream->self_group.lock)->rlock){..-...}, at:
[<c04e03cc>] _snd_pcm_stream_lock_irqsave+0x34/0x40
[  139.845788] but this lock took another, SOFTIRQ-unsafe lock in the past:
[  139.852468]  (&(&pri_dai->spinlock)->rlock){+.+...}

and interrupts could create inverse lock ordering between them.

[  139.863319]
[  139.863319] other info that might help us debug this:
[  139.869830]  Possible interrupt unsafe locking scenario:
[  139.869830]
[  139.876599]        CPU0                    CPU1
[  139.881113]        ----                    ----
[  139.885626]   lock(&(&pri_dai->spinlock)->rlock);
[  139.890314]                                local_irq_disable();
[  139.896216]
lock(&(&substream->self_group.lock)->rlock);
[  139.904201]
lock(&(&pri_dai->spinlock)->rlock);
[  139.911405]   <Interrupt>
[  139.914009]     lock(&(&substream->self_group.lock)->rlock);
[  139.919652]
[  139.919652]  *** DEADLOCK ***
[  139.919652]
[  139.925558] 1 lock held by swapper/0/0:
[  139.929374]  #0:  (snd_pcm_link_rwlock){...-..}, at: [<c04e0330>]
snd_pcm_stream_lock+0x20/0x50
[  139.938054]
[  139.938054] the shortest dependencies between 2nd lock and 1st lock:
[  139.945893]  -> (&(&pri_dai->spinlock)->rlock){+.+...} ops: 37 {
[  139.951856]     HARDIRQ-ON-W at:
[  139.955067]                       [<c066b89c>] _raw_spin_lock+0x3c/0x74
[  139.961663]                       [<c0500558>] i2s_set_sysclk+0x40/0x464
[  139.968347]                       [<c0500e0c>]
samsung_i2s_dai_probe+0x238/0x2b0
[  139.975725]                       [<c04ed5f8>] soc_probe_dai.part.2+0x30/0x6c
[  139.982842]                       [<c04ee1b8>]
snd_soc_register_card+0x854/0xe64
[  139.990220]                       [<c04f9b0c>]
devm_snd_soc_register_card+0x38/0x70
[  139.997859]                       [<c04ff0f8>]
asoc_simple_card_probe+0x224/0x460
[  140.005323]                       [<c036da6c>] platform_drv_probe+0x4c/0xb0
[  140.012267]                       [<c036c2ac>]
driver_probe_device+0x20c/0x2b8
[  140.019472]                       [<c036a644>] bus_for_each_drv+0x60/0x94
[  140.026242]                       [<c036bfc0>] __device_attach+0xb4/0x118
[  140.033013]                       [<c036b464>] bus_probe_device+0x88/0x90
[  140.039783]                       [<c036b900>]
deferred_probe_work_func+0x6c/0x9c
[  140.047248]                       [<c0043408>] process_one_work+0x1a8/0x514
[  140.054192]                       [<c00437ac>] worker_thread+0x38/0x574
[  140.060789]                       [<c0049c0c>] kthread+0xf4/0x10c
[  140.066865]                       [<c000f890>] ret_from_fork+0x14/0x24
[  140.073376]     SOFTIRQ-ON-W at:
[  140.076587]                       [<c066b89c>] _raw_spin_lock+0x3c/0x74
[  140.083183]                       [<c0500558>] i2s_set_sysclk+0x40/0x464
[  140.089867]                       [<c0500e0c>]
samsung_i2s_dai_probe+0x238/0x2b0
[  140.097245]                       [<c04ed5f8>] soc_probe_dai.part.2+0x30/0x6c
[  140.104362]                       [<c04ee1b8>]
snd_soc_register_card+0x854/0xe64
[  140.111740]                       [<c04f9b0c>]
devm_snd_soc_register_card+0x38/0x70
[  140.119379]                       [<c04ff0f8>]
asoc_simple_card_probe+0x224/0x460
[  140.126843]                       [<c036da6c>] platform_drv_probe+0x4c/0xb0
[  140.133787]                       [<c036c2ac>]
driver_probe_device+0x20c/0x2b8
[  140.140992]                       [<c036a644>] bus_for_each_drv+0x60/0x94
[  140.147762]                       [<c036bfc0>] __device_attach+0xb4/0x118
[  140.154533]                       [<c036b464>] bus_probe_device+0x88/0x90
[  140.161303]                       [<c036b900>]
deferred_probe_work_func+0x6c/0x9c
[  140.168768]                       [<c0043408>] process_one_work+0x1a8/0x514
[  140.175712]                       [<c00437ac>] worker_thread+0x38/0x574
[  140.182309]                       [<c0049c0c>] kthread+0xf4/0x10c
[  140.188385]                       [<c000f890>] ret_from_fork+0x14/0x24
[  140.194896]     INITIAL USE at:
[  140.198020]                      [<c066bb14>]
_raw_spin_lock_irqsave+0x48/0x84
[  140.205224]                      [<c04c2d44>] clk_divider_set_rate+0x40/0xc0
[  140.212255]                      [<c04c1320>] clk_change_rate+0x17c/0x210
[  140.219025]                      [<c04c12b8>] clk_change_rate+0x114/0x210
[  140.225796]   }
[  140.227532]   ... key      at: [<c13e2f04>] __key.37532+0x0/0x8
[  140.233435]   ... acquired at:
[  140.236472]    [<c04ffb18>] i2s_trigger+0x40/0x62c
[  140.241246]    [<c04f4d14>] soc_pcm_trigger+0xd0/0x11c
[  140.246367]    [<c04dfe58>] snd_pcm_action_single+0x38/0x80
[  140.251922]    [<c04e1dac>] snd_pcm_common_ioctl1+0x3bc/0xe20
[  140.257651]    [<c04e29b4>] snd_pcm_playback_ioctl1+0x1a4/0x69c
[  140.263553]    [<c01343f8>] do_vfs_ioctl+0xa0/0x9d4
[  140.268414]    [<c0134d60>] SyS_ioctl+0x34/0x5c
[  140.272927]    [<c000f800>] ret_fast_syscall+0x0/0x1c
[  140.277962]
[  140.279438] -> (&(&substream->self_group.lock)->rlock){..-...} ops: 153 {
[  140.286209]    IN-SOFTIRQ-W at:
[  140.289333]                     [<c066b89c>] _raw_spin_lock+0x3c/0x74
[  140.295757]                     [<c04e03cc>]
_snd_pcm_stream_lock_irqsave+0x34/0x40
[  140.303395]                     [<c04e6f44>] snd_pcm_period_elapsed+0x1c/0xa0
[  140.310512]                     [<c02de5b0>] pl330_tasklet+0x198/0x518
[  140.317022]                     [<c002e424>] tasklet_action+0xac/0x164
[  140.323532]                     [<c002e6ac>] __do_softirq+0x168/0x2c0
[  140.329955]                     [<c002eba8>] irq_exit+0xec/0x128
[  140.335945]                     [<c0087314>] __handle_domain_irq+0x80/0xec
[  140.342802]                     [<c0009514>] gic_handle_irq+0x54/0x94
[  140.349225]                     [<c00144f8>] __irq_svc+0x58/0x98
[  140.355214]                     [<c00102f8>] arch_cpu_idle+0x24/0x3c
[  140.361551]                     [<c00102f8>] arch_cpu_idle+0x24/0x3c
[  140.367887]                     [<c006d5d4>] cpu_startup_entry+0x1f4/0x280
[  140.374744]                     [<c08c8ccc>] start_kernel+0x3ec/0x3f8
[  140.381169]    INITIAL USE at:
[  140.384205]                    [<c066b89c>] _raw_spin_lock+0x3c/0x74
[  140.390542]                    [<c04e0850>] snd_pcm_sync_ptr+0xf8/0x1e0
[  140.397139]                    [<c04e1e68>] snd_pcm_common_ioctl1+0x478/0xe20
[  140.404256]                    [<c04e3078>]
snd_pcm_capture_ioctl1+0x1a4/0x688
[  140.411461]                    [<c01343f8>] do_vfs_ioctl+0xa0/0x9d4
[  140.417710]                    [<c0134d60>] SyS_ioctl+0x34/0x5c
[  140.423613]                    [<c000f800>] ret_fast_syscall+0x0/0x1c
[  140.430036]  }
[  140.431685]  ... key      at: [<c13e2be8>] __key.29136+0x0/0x8
[  140.437501]  ... acquired at:
[  140.440452]    [<c0079630>] __lock_acquire+0x774/0x1ee0
[  140.445659]    [<c007b390>] lock_acquire+0xa8/0xd0
[  140.450433]    [<c066b89c>] _raw_spin_lock+0x3c/0x74
[  140.455381]    [<c04e03cc>] _snd_pcm_stream_lock_irqsave+0x34/0x40
[  140.461544]    [<c04e6f44>] snd_pcm_period_elapsed+0x1c/0xa0
[  140.467186]    [<c02de5b0>] pl330_tasklet+0x198/0x518
[  140.472220]    [<c002e424>] tasklet_action+0xac/0x164
[  140.477255]    [<c002e6ac>] __do_softirq+0x168/0x2c0
[  140.482202]    [<c002eba8>] irq_exit+0xec/0x128
[  140.486716]    [<c0087314>] __handle_domain_irq+0x80/0xec
[  140.492097]    [<c0009514>] gic_handle_irq+0x54/0x94
[  140.497044]    [<c00144f8>] __irq_svc+0x58/0x98
[  140.501559]    [<c00102f8>] arch_cpu_idle+0x24/0x3c
[  140.506420]    [<c00102f8>] arch_cpu_idle+0x24/0x3c
[  140.511280]    [<c006d5d4>] cpu_startup_entry+0x1f4/0x280
[  140.516662]    [<c08c8ccc>] start_kernel+0x3ec/0x3f8
[  140.521609]
[  140.523086]
[  140.523086] stack backtrace:
[  140.527435] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
4.5.0-rc3-u3s #11
[  140.535240] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[  140.541339] [<c0016d6c>] (unwind_backtrace) from [<c00139f8>]
(show_stack+0x10/0x14)
[  140.549063] [<c00139f8>] (show_stack) from [<c0283884>]
(dump_stack+0x98/0xc4)
[  140.556263] [<c0283884>] (dump_stack) from [<c0075458>]
(print_irq_inversion_bug+0x1d4/0x21c)
[  140.564766] [<c0075458>] (print_irq_inversion_bug) from
[<c0075550>] (check_usage_forwards+0xb0/0x10c)
[  140.574051] [<c0075550>] (check_usage_forwards) from [<c00764f8>]
(mark_lock+0x370/0x81c)
[  140.582211] [<c00764f8>] (mark_lock) from [<c0079630>]
(__lock_acquire+0x774/0x1ee0)
[  140.589936] [<c0079630>] (__lock_acquire) from [<c007b390>]
(lock_acquire+0xa8/0xd0)
[  140.597665] [<c007b390>] (lock_acquire) from [<c066b89c>]
(_raw_spin_lock+0x3c/0x74)
[  140.605389] [<c066b89c>] (_raw_spin_lock) from [<c04e03cc>]
(_snd_pcm_stream_lock_irqsave+0x34/0x40)
[  140.614503] [<c04e03cc>] (_snd_pcm_stream_lock_irqsave) from
[<c04e6f44>] (snd_pcm_period_elapsed+0x1c/0xa0)
[  140.624313] [<c04e6f44>] (snd_pcm_period_elapsed) from [<c02de5b0>]
(pl330_tasklet+0x198/0x518)
[  140.632993] [<c02de5b0>] (pl330_tasklet) from [<c002e424>]
(tasklet_action+0xac/0x164)
[  140.640890] [<c002e424>] (tasklet_action) from [<c002e6ac>]
(__do_softirq+0x168/0x2c0)
[  140.648787] [<c002e6ac>] (__do_softirq) from [<c002eba8>]
(irq_exit+0xec/0x128)
[  140.656080] [<c002eba8>] (irq_exit) from [<c0087314>]
(__handle_domain_irq+0x80/0xec)
[  140.663889] [<c0087314>] (__handle_domain_irq) from [<c0009514>]
(gic_handle_irq+0x54/0x94)
[  140.672219] [<c0009514>] (gic_handle_irq) from [<c00144f8>]
(__irq_svc+0x58/0x98)
[  140.679677] Exception stack(0xc0aa5f50 to 0xc0aa5f98)
[  140.684716] 5f40:                                     00000000
2e0b1000 00000000 c0aaa540
[  140.692879] 5f60: c0aa4000 c0aa655c 00000000 00000000 c0aa5fa8
c093d49c c0aa65bc c0aa65c4
[  140.701035] 5f80: 00000000 c0aa5fa0 c0076b38 c00102f8 20030053 ffffffff
[  140.707637] [<c00144f8>] (__irq_svc) from [<c00102f8>]
(arch_cpu_idle+0x24/0x3c)
[  140.715014] [<c00102f8>] (arch_cpu_idle) from [<c006d5d4>]
(cpu_startup_entry+0x1f4/0x280)
[  140.723265] [<c006d5d4>] (cpu_startup_entry) from [<c08c8ccc>]
(start_kernel+0x3ec/0x3f8)

Best Regards
-Anand Moon


From marc.zyngier at arm.com  Tue Feb  9 23:31:00 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 07:31:00 +0000
Subject: [PATCH V2] arm64: KVM: Configure TCR_EL2.ps at runtime
In-Reply-To: <1455056113-25948-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1455056113-25948-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <20160210073100.235478c7@arm.com>

On Tue, 9 Feb 2016 14:15:13 -0800
<tchalamarla at caviumnetworks.com> wrote:

Tirumalesh,

> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> 
> Setting TCR_EL2.ps to 40 bits is wrong on systems with ps size is
> less than 40 bits. and with systems where RAM is at higher address,
> this will break KVM.
> 
> This patch sets TCR_EL2.ps at runtime similar to VTCR_EL.ps

VTCR_EL2.PS (and please use capital letters to designate a field in a
given register).

> 
> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> ---
>  arch/arm64/include/asm/kvm_arm.h |  5 ++++-
>  arch/arm64/kvm/hyp-init.S        | 10 ++++++----
>  2 files changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 738a95f..92f2ffd 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -107,7 +107,10 @@
>  #define TCR_EL2_MASK	(TCR_EL2_TG0 | TCR_EL2_SH0 | \
>  			 TCR_EL2_ORGN0 | TCR_EL2_IRGN0 | TCR_EL2_T0SZ)
>  
> -#define TCR_EL2_FLAGS	(TCR_EL2_RES1 | TCR_EL2_PS_40B)
> +/*
> + * TCR_EL2.ps is configured at runtime similar to VTCR_EL2
> + */
> +#define TCR_EL2_FLAGS	(TCR_EL2_RES1)

Now that you've reduced the flags to be the reserved bits only, why not
clean it up for good, and directly use TCR_EL2_RES1? Also, that comment
is pretty pointless, as the whole of TCR_EL2 is now dynamically
configured, not just the PS field.

>  
>  /* VTCR_EL2 Registers bits */
>  #define VTCR_EL2_RES1		(1 << 31)
> diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
> index 3e568dc..b246de1e 100644
> --- a/arch/arm64/kvm/hyp-init.S
> +++ b/arch/arm64/kvm/hyp-init.S
> @@ -85,15 +85,17 @@ __do_hyp_init:
>  	ldr_l	x5, idmap_t0sz
>  	bfi	x4, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH
>  #endif
> -	msr	tcr_el2, x4
> -
> -	ldr	x4, =VTCR_EL2_FLAGS
>  	/*
>  	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
> -	 * VTCR_EL2.
> +	 * TCR_EL2 and VTCR_EL2.
>  	 */
>  	mrs	x5, ID_AA64MMFR0_EL1
>  	bfi	x4, x5, #16, #3
> +
> +	msr	tcr_el2, x4
> +
> +	ldr	x4, =VTCR_EL2_FLAGS
> +	bfi	x4, x5, #16, #3
>  	/*
>  	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS bit in
>  	 * VTCR_EL2.

Otherwise look OK to me.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.


From marc.zyngier at arm.com  Tue Feb  9 23:42:47 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 07:42:47 +0000
Subject: [PATCH v2 22/28] ARM: KVM: Switch to C-based stage2 init
In-Reply-To: <20160209184513.GX5171@cbox>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-23-git-send-email-marc.zyngier@arm.com>
 <20160209184513.GX5171@cbox>
Message-ID: <20160210074247.589db14b@arm.com>

On Tue, 9 Feb 2016 19:45:13 +0100
Christoffer Dall <christoffer.dall at linaro.org> wrote:

> Mising (sarcastic) commit message?

Ah! I'll try to think of something along the lines of:

"Let's now retire the code that bravely served us for three
years, and enjoy a brand new set of bugs. At least, we can blame the
compiler this time."

> On Thu, Feb 04, 2016 at 11:00:39AM +0000, Marc Zyngier wrote:
> > Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> > ---
> 
> Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.


From broonie at kernel.org  Wed Feb 10 00:01:49 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 10 Feb 2016 08:01:49 +0000
Subject: [PATCH 3/4] spi: bcm2835aux: set up spi-mode before asserting
 cs-gpio
In-Reply-To: <87d1s54f7f.fsf@eliezer.anholt.net>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <1455041435-8015-4-git-send-email-stephanolbrich@gmx.de>
 <87d1s54f7f.fsf@eliezer.anholt.net>
Message-ID: <20160210080149.GQ13270@sirena.org.uk>

On Tue, Feb 09, 2016 at 03:49:24PM -0800, Eric Anholt wrote:

> This patch surprised me.  I would have thought that the solution was to
> just write the updated CNTL bits for CPOL and wait a moment whenever it
> changes.  The CS only gets asserted later on when we get some data in
> the TX FIFO, so I think you're just reducing the chance of losing the
> race to get our inverted clock noticed by the device before the CS gets
> asserted.

We support (and generally want to use since hardware chip selects are
often very limited in what they do) chip select on GPIO.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160210/5b1f94c4/attachment.sig>

From christoffer.dall at linaro.org  Wed Feb 10 00:04:27 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 10 Feb 2016 09:04:27 +0100
Subject: [PATCH v2 22/28] ARM: KVM: Switch to C-based stage2 init
In-Reply-To: <20160210074247.589db14b@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-23-git-send-email-marc.zyngier@arm.com>
 <20160209184513.GX5171@cbox> <20160210074247.589db14b@arm.com>
Message-ID: <20160210080427.GG5171@cbox>

On Wed, Feb 10, 2016 at 07:42:47AM +0000, Marc Zyngier wrote:
> On Tue, 9 Feb 2016 19:45:13 +0100
> Christoffer Dall <christoffer.dall at linaro.org> wrote:
> 
> > Mising (sarcastic) commit message?
> 
> Ah! I'll try to think of something along the lines of:
> 
> "Let's now retire the code that bravely served us for three
> years, and enjoy a brand new set of bugs. At least, we can blame the
> compiler this time."
> 
You are the master of those ;)

-Christoffer


From linus.walleij at linaro.org  Wed Feb 10 00:15:08 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Feb 2016 09:15:08 +0100
Subject: [PATCH] ARM: Use generic clkdev.h header
In-Reply-To: <7387260.8XnD1ditcY@wuerfel>
References: <1453932702-6930-1-git-send-email-sboyd@codeaurora.org>
 <6141409.WI4q6BtOxa@wuerfel>
 <20160128201238.GN12841@codeaurora.org>
 <7387260.8XnD1ditcY@wuerfel>
Message-ID: <CACRpkdZj8JM+qYYfE4+cF1iMevJS5t-c_KpV-2jjjspFywf+XQ@mail.gmail.com>

On Thu, Jan 28, 2016 at 11:07 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 28 January 2016 12:12:38 Stephen Boyd wrote:
>> From: Stephen Boyd <sboyd at codeaurora.org>
>> Subject: [PATCH] ARM: plat-versatile: Remove unused clock.c file
>>
>> This file isn't compiled anymore because PLAT_VERSATILE_CLOCK is
>> never selected. Remove the file and the config.
>>
>> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
>> ---
>>  arch/arm/plat-versatile/Kconfig  |  3 --
>>  arch/arm/plat-versatile/Makefile |  1 -
>>  arch/arm/plat-versatile/clock.c  | 74 ----------------------------------------
>>  3 files changed, 78 deletions(-)
>>  delete mode 100644 arch/arm/plat-versatile/clock.c
>>
>
> Looks good, I've added it to my todo list for arm-soc in 4.6.
>
> I think Linus Walleij has some related work pending, so I'll
> let him Ack this patch or pick it up in his tree if he prefers.
>
> Acked-by: Arnd Bergmann <arnd at arndb.de>

OK yeah I have a bunch of Versatile family cleanups pending,
I will put this in the bottom of the pile before the pull request,
thanks!

Yours,
Linus Walleij


From marc.zyngier at arm.com  Wed Feb 10 00:34:21 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 08:34:21 +0000
Subject: [PATCH 0/8] KVM/ARM: Guest Entry/Exit optimizations
In-Reply-To: <20160209205919.GF5171@cbox>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <20160209205919.GF5171@cbox>
Message-ID: <56BAF60D.6020506@arm.com>

On 09/02/16 20:59, Christoffer Dall wrote:
> On Mon, Feb 08, 2016 at 11:40:14AM +0000, Marc Zyngier wrote:
>> I've recently been looking at our entry/exit costs, and profiling
>> figures did show some very low hanging fruits.
>>
>> The most obvious cost is that accessing the GIC HW is slow. As in
>> "deadly slow", specially when GICv2 is involved. So not hammering the
>> HW when there is nothing to write is immediately beneficial, as this
>> is the most common cases (whatever people seem to think, interrupts
>> are a *rare* event).
>>
>> Another easy thing to fix is the way we handle trapped system
>> registers. We do insist on (mostly) sorting them, but we do perform a
>> linear search on trap. We can switch to a binary search for free, and
>> get immediate benefits (the PMU code, being extremely trap-happy,
>> benefits immediately from this).
>>
>> With these in place, I see an improvement of 20 to 30% (depending on
>> the platform) on our world-switch cycle count when running a set of
>> hand-crafted guests that are designed to only perform traps.
> 
> I'm curious about the weight of these two?  My guess based on the
> measurement work I did is that the GIC is by far the worst sinner, but
> that was exacerbated on X-Gene compared to Seattle.

Indeed, the GIC is the real pig. 80% of the benefit is provided by not
accessing it when not absolutely required. The sysreg access is only
visible for workloads that are extremely trap-happy, but that's what
happens with as soon as you start exercising the PMU code.

>>
>> Methodology:
>>
>> * NULL-hypercall guest: Perform 65536 PSCI_0_2_FN_PSCI_VERSION calls,
>> and then a power-off:
>>
>> __start:
>> 	mov	x19, #(1 << 16)
>> 1:	mov	x0, #0x84000000
>> 	hvc	#0
>> 	sub	x19, x19, #1
>> 	cbnz	x19, 1b
>> 	mov	x0, #0x84000000
>> 	add	x0, x0, #9
>> 	hvc	#0
>> 	b	.
>>
>> * sysreg trap guest: Perform 2^20 PMSELR_EL0 accesses, and power-off:
>>
>> __start:
>> 	mov	x19, #(1 << 20)
>> 1:	mrs	x0, PMSELR_EL0
>> 	sub	x19, x19, #1
>> 	cbnz	x19, 1b
>> 	mov	x0, #0x84000000
>> 	add	x0, x0, #9
>> 	hvc	#0
>> 	b	.
>>
>> * These guests are profiled using perf and kvmtool:
>>
>> taskset -c 1 perf stat -e cycles:kh lkvm run -c1 --kernel do_sysreg.bin 2>&1 >/dev/null| grep cycles
> 
> these would be good to add to kvm-unit-tests so we can keep an eye on
> this sort of thing...

Yeah, I was thinking of that too. In the meantime, I've also created a
GICv2 self-IPI test case, which has led to further improvement (a 10%
reduction in the number of cycles on Seattle). The ugly thing about that
test is that it knows where kvmtool places the GIC (I didn't fancy
parsing the DT in assembly code). Hopefully there is a way to abstract this.

We definitely run that kind of things on a regular basis and track the
evolutions...

> 
>>
>> The result is then divided by the number of iterations (2^16 or 2^20).
>>
>> These tests have been run on Seattle, Mustang, and LS2085, and shown
>> significant improvements in all cases. I've only touched the arm64
>> GIC code, but obviously the 32bit code should use it as well once
>> we've migrated it to C.
>>
>> I've pushed out a branch (kvm-arm64/suck-less) to the usual location.
>>
> 
> Looks promising!

I thought as much. I'll keep on updating this branch, as it looks like
there is a few more low hanging fruits around there...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From tn at semihalf.com  Wed Feb 10 00:55:04 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Wed, 10 Feb 2016 09:55:04 +0100
Subject: [PATCH V3 00/10] Introduce ACPI world to GICv3 & ITS irqchip
In-Reply-To: <1453209083-3358-1-git-send-email-tn@semihalf.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
Message-ID: <56BAFAE8.4070308@semihalf.com>

On 19.01.2016 14:11, Tomasz Nowicki wrote:
> Patches base on Suravee's ACPI GICv2m support:
> https://lkml.org/lkml/2015/12/10/475
>
> The following git branch contains submitted patches along with
> the useful patches from the test point of view (mainly ACPI ARM64 PCI support).
> https://github.com/semihalf-nowicki-tomasz/linux.git (gicv3-its-acpi-v3)
>

Hi Marc,

Can you please have a look at this series. I think your previous 
concerns have been addressed.

Tomasz


From ralf at linux-mips.org  Wed Feb 10 01:01:06 2016
From: ralf at linux-mips.org (Ralf Baechle)
Date: Wed, 10 Feb 2016 10:01:06 +0100
Subject: [PATCH] MIPS: pci-mt7620: Fix return value check in
 mt7620_pci_probe()
In-Reply-To: <56B613D3.2070709@openwrt.org>
References: <1454768659-32720-1-git-send-email-weiyj_lk@163.com>
 <56B613D3.2070709@openwrt.org>
Message-ID: <20160210090106.GA10352@linux-mips.org>

On Sat, Feb 06, 2016 at 04:40:03PM +0100, John Crispin wrote:

> On 06/02/2016 15:24, weiyj_lk at 163.com wrote:
> > From: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
> > 
> > In case of error, the function devm_ioremap_resource() returns
> > ERR_PTR() and never returns NULL. The NULL test in the return
> > value check should be replaced with IS_ERR().
> > 
> > Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn>
> 
> Hi,
> 
> thanks for the fix.
> 
> Acked-by: John Crispin <blogic at openwrt.org>
> 
> @Ralf: can you merge this via LMO with the next PR please ?
> 
> @mbgg: ignore the patch please it is for the legacy MIPS SoCs

Applied.  Thanks folks,

  Ralf


From antoine.tenart at free-electrons.com  Wed Feb 10 01:22:46 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Wed, 10 Feb 2016 10:22:46 +0100
Subject: [PATCH v2 3/3] arm64: defconfig: enable the Alpine family
In-Reply-To: <1455096166-4899-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455096166-4899-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455096166-4899-4-git-send-email-antoine.tenart@free-electrons.com>

Enable the Alpine SoC family in the arm64 defconfig.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 18ca9fb9e65f..10387947a164 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -31,6 +31,7 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_ARCH_ALPINE=y
 CONFIG_ARCH_BCM_IPROC=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_ARCH_EXYNOS7=y
-- 
2.7.0



From antoine.tenart at free-electrons.com  Wed Feb 10 01:22:43 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Wed, 10 Feb 2016 10:22:43 +0100
Subject: [PATCH v2 0/3] arm64: introduce the Alpine support
Message-ID: <1455096166-4899-1-git-send-email-antoine.tenart@free-electrons.com>

Hi all,

This series introduces the support for the arm64 Alpine family from
Annapurna Labs, by adding a device tree for the Alpine v2 EVP. This
board has 4 Cortex A57 and a few nodes in its device tree for now.

You can find the series at:
https://github.com/atenart/linux.git 4.5-rc1/alpinev2-bringup

Antoine

Since v1:
  - Fixed the armv8-timer interrupts.
  - Added the GICV and GIVH ranges.
  - Added the GIC maintainance interrupt.
  - Moved the aliases to the dts file.
  - Fixed the pci node.
  - Added the arm,psci cpu_off and cpu_suspend functions.
  - Added the io-fabric bus.
  - Fixed the stdout-path.

Antoine Tenart (3):
  arm64: add Alpine SoC family
  arm64: dts: add the Alpine v2 EVP
  arm64: defconfig: enable the Alpine family

 arch/arm64/Kconfig.platforms             |   6 +
 arch/arm64/boot/dts/Makefile             |   1 +
 arch/arm64/boot/dts/al/Makefile          |   5 +
 arch/arm64/boot/dts/al/alpine-v2-evp.dts |  53 ++++++++
 arch/arm64/boot/dts/al/alpine-v2.dtsi    | 226 +++++++++++++++++++++++++++++++
 arch/arm64/configs/defconfig             |   1 +
 6 files changed, 292 insertions(+)
 create mode 100644 arch/arm64/boot/dts/al/Makefile
 create mode 100644 arch/arm64/boot/dts/al/alpine-v2-evp.dts
 create mode 100644 arch/arm64/boot/dts/al/alpine-v2.dtsi

-- 
2.7.0



From antoine.tenart at free-electrons.com  Wed Feb 10 01:22:44 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Wed, 10 Feb 2016 10:22:44 +0100
Subject: [PATCH v2 1/3] arm64: add Alpine SoC family
In-Reply-To: <1455096166-4899-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455096166-4899-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455096166-4899-2-git-send-email-antoine.tenart@free-electrons.com>

This patch introduces ARCH_ALPINE to add the support of the Alpine SoC
family for the arm64 architecture.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
---
 arch/arm64/Kconfig.platforms | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f674bde..bfbefa3e0dbe 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -1,5 +1,11 @@
 menu "Platform selection"
 
+config ARCH_ALPINE
+	bool "Annapurna Labs Alpine platform"
+	help
+	  This enables support for the Annapurna Labs Alpine
+	  Soc family.
+
 config ARCH_BCM_IPROC
 	bool "Broadcom iProc SoC Family"
 	help
-- 
2.7.0



From antoine.tenart at free-electrons.com  Wed Feb 10 01:22:45 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Wed, 10 Feb 2016 10:22:45 +0100
Subject: [PATCH v2 2/3] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <1455096166-4899-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455096166-4899-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455096166-4899-3-git-send-email-antoine.tenart@free-electrons.com>

This patch adds the initial support for the Alpine v2 EVP board from
Annapurna Labs (Amazon).

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Barak Wasserstrom <barak at annapurnalabs.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 arch/arm64/boot/dts/Makefile             |   1 +
 arch/arm64/boot/dts/al/Makefile          |   5 +
 arch/arm64/boot/dts/al/alpine-v2-evp.dts |  53 ++++++++
 arch/arm64/boot/dts/al/alpine-v2.dtsi    | 226 +++++++++++++++++++++++++++++++
 4 files changed, 285 insertions(+)
 create mode 100644 arch/arm64/boot/dts/al/Makefile
 create mode 100644 arch/arm64/boot/dts/al/alpine-v2-evp.dts
 create mode 100644 arch/arm64/boot/dts/al/alpine-v2.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index f832b8a7453a..fd80617a9c6f 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,3 +1,4 @@
+dts-dirs += al
 dts-dirs += altera
 dts-dirs += amd
 dts-dirs += apm
diff --git a/arch/arm64/boot/dts/al/Makefile b/arch/arm64/boot/dts/al/Makefile
new file mode 100644
index 000000000000..8a6cde4f9b23
--- /dev/null
+++ b/arch/arm64/boot/dts/al/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_ALPINE)	+= alpine-v2-evp.dtb
+
+always		:= $(dtb-y)
+subdir-y	:= $(dts-dirs)
+clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/al/alpine-v2-evp.dts b/arch/arm64/boot/dts/al/alpine-v2-evp.dts
new file mode 100644
index 000000000000..a079d7b3063e
--- /dev/null
+++ b/arch/arm64/boot/dts/al/alpine-v2-evp.dts
@@ -0,0 +1,53 @@
+/*
+ * Copyright 2016 Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ *
+ * Antoine Tenart <antoine.tenart at free-electrons.com>
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * BSD license below:
+ *
+ *     Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *      - Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *
+ *      - Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include "alpine-v2.dtsi"
+
+/ {
+	model = "Annapurna Labs Alpine v2 EVP";
+	compatible = "al,alpine-v2-evp", "al,alpine-v2";
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
+
+&uart0 { status = "okay"; };
diff --git a/arch/arm64/boot/dts/al/alpine-v2.dtsi b/arch/arm64/boot/dts/al/alpine-v2.dtsi
new file mode 100644
index 000000000000..c021e077343b
--- /dev/null
+++ b/arch/arm64/boot/dts/al/alpine-v2.dtsi
@@ -0,0 +1,226 @@
+/*
+ * Copyright 2016 Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ *
+ * Antoine Tenart <antoine.tenart at free-electrons.com>
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * BSD license below:
+ *
+ *     Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *      - Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *
+ *      - Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	model = "Annapurna Labs Alpine v2";
+	compatible = "al,alpine-v2";
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			compatible = "arm,cortex-a57", "arm,armv8";
+			device_type = "cpu";
+			reg = <0x0 0x0>;
+			enable-method = "psci";
+		};
+
+		cpu at 1 {
+			compatible = "arm,cortex-a57", "arm,armv8";
+			device_type = "cpu";
+			reg = <0x0 0x1>;
+			enable-method = "psci";
+		};
+
+		cpu at 2 {
+			compatible = "arm,cortex-a57", "arm,armv8";
+			device_type = "cpu";
+			reg = <0x0 0x2>;
+			enable-method = "psci";
+		};
+
+		cpu at 3 {
+			compatible = "arm,cortex-a57", "arm,armv8";
+			device_type = "cpu";
+			reg = <0x0 0x3>;
+			enable-method = "psci";
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2", "arm,psci";
+		method = "smc";
+		cpu_suspend = <0x84000001>;
+		cpu_off = <0x84000002>;
+		cpu_on = <0x84000003>;
+	};
+
+	sbclk: sbclk {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1000000>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+
+		interrupt-parent = <&gic>;
+		ranges;
+
+		timer {
+			compatible = "arm,armv8-timer";
+			interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+				     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+				     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+				     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+		};
+
+		pmu {
+			compatible = "arm,armv8-pmuv3";
+			interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		gic: gic at f0100000 {
+			compatible = "arm,gic-v3";
+			reg = <0x0 0xf0200000 0x0 0x10000>,	/* GIC Dist */
+			      <0x0 0xf0280000 0x0 0x200000>,	/* GICR */
+			      <0x0 0xf0100000 0x0 0x2000>,	/* GICC */
+			      <0x0 0xf0110000 0x0 0x2000>,	/* GICV */
+			      <0x0 0xf0120000 0x0 0x2000>;	/* GICH */
+			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+		};
+
+		pci at fbc00000 {
+			compatible = "pci-host-ecam-generic";
+			device_type = "pci";
+			#size-cells = <2>;
+			#address-cells = <3>;
+			#interrupt-cells = <1>;
+			reg = <0x0 0xfbc00000 0x0 0x100000>;
+			interrupt-map-mask = <0xf800 0 0 7>;
+			/* add legacy interrupts for SATA only */
+			interrupt-map = <0x4000 0 0 1 &gic 0 53 4>,
+					<0x4800 0 0 1 &gic 0 54 4>;
+			/* 32 bit non prefetchable memory space */
+			ranges = <0x2000000 0x0 0xfe000000 0x0 0xfe000000 0x0 0x1000000>;
+			bus-range = <0x00 0x00>;
+		};
+
+		io-fabric {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0x0 0x0 0xfc000000 0x2000000>;
+
+			uart0: serial at 1883000 {
+				compatible = "ns16550a";
+				device_type = "serial";
+				reg = <0x1883000 0x1000>;
+				interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+				clock-frequency = <500000000>;
+				reg-shift = <2>;
+				reg-io-width = <4>;
+				status = "disabled";
+			};
+
+			uart1: serial at 1884000 {
+				compatible = "ns16550a";
+				device_type = "serial";
+				reg = <0x1884000 0x1000>;
+				interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+				clock-frequency = <500000000>;
+				reg-shift = <2>;
+				reg-io-width = <4>;
+				status = "disabled";
+			};
+
+			uart2: serial at 1885000 {
+				compatible = "ns16550a";
+				device_type = "serial";
+				reg = <0x1885000 0x1000>;
+				interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+				clock-frequency = <500000000>;
+				reg-shift = <2>;
+				reg-io-width = <4>;
+				status = "disabled";
+			};
+
+			uart3: serial at 1886000 {
+				compatible = "ns16550a";
+				device_type = "serial";
+				reg = <0x1886000 0x1000>;
+				interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+				clock-frequency = <500000000>;
+				reg-shift = <2>;
+				reg-io-width = <4>;
+				status = "disabled";
+			};
+
+			timer0: timer at 1890000 {
+				compatible = "arm,sp804", "arm,primecell";
+				reg = <0x1890000 0x1000>;
+				interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&sbclk>;
+			};
+
+			timer1: timer at 1891000 {
+				compatible = "arm,sp804", "arm,primecell";
+				reg = <0x1891000 0x1000>;
+				interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&sbclk>;
+				status = "disabled";
+			};
+
+			timer2: timer at 1892000 {
+				compatible = "arm,sp804", "arm,primecell";
+				reg = <0x1892000 0x1000>;
+				interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&sbclk>;
+				status = "disabled";
+			};
+
+			timer3: timer at 1893000 {
+				compatible = "arm,sp804", "arm,primecell";
+				reg = <0x1893000 0x1000>;
+				interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&sbclk>;
+				status = "disabled";
+			};
+		};
+	};
+};
-- 
2.7.0



From will.deacon at arm.com  Wed Feb 10 01:28:23 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 09:28:23 +0000
Subject: [PATCH] arm64: Add workaround for Cavium erratum 27456
In-Reply-To: <1455046156-10582-1-git-send-email-ddaney.cavm@gmail.com>
References: <1455046156-10582-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <20160210092822.GA1052@arm.com>

On Tue, Feb 09, 2016 at 11:29:16AM -0800, David Daney wrote:
> From: Andrew Pinski <apinski at cavium.com>
> 
> On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
> instructions may cause the icache to become invalid if it contains
> data for a non-current ASID.
> 
> This patch implements the workaround (which flushes the local icache
> when switching the mm) by using code patching.

So, to be clear, is this "just" a performance problem as opposed to a
correctness issue? If so, do you have any numbers with and without this
change?

Will


From linus.walleij at linaro.org  Wed Feb 10 01:29:13 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Feb 2016 10:29:13 +0100
Subject: [PATCH] pinctrl: mediatek: guard sub-directory with
 CONFIG_PINCTRL_MTK
In-Reply-To: <CAK7LNAQ_8o0FiRpb7D6RBmA+7WxRMFhWJjo2f4E_NH5qAGYb4A@mail.gmail.com>
References: <1453563204-30407-1-git-send-email-yamada.masahiro@socionext.com>
 <CACRpkdbrJ5P8Ro4RQUquMOTuXhN+54ZHYGbLqrbwW6tbwCC7Mg@mail.gmail.com>
 <CAK7LNAQ_8o0FiRpb7D6RBmA+7WxRMFhWJjo2f4E_NH5qAGYb4A@mail.gmail.com>
Message-ID: <CACRpkdaA37GXf8c=EznSpocLp33CaU8dYqb8V0pua4dVfZa_2w@mail.gmail.com>

On Thu, Jan 28, 2016 at 5:22 AM, Masahiro Yamada
<yamada.masahiro at socionext.com> wrote:
> Hi Linus
>
> 2016-01-27 23:11 GMT+09:00 Linus Walleij <linus.walleij at linaro.org>:
>> On Sat, Jan 23, 2016 at 4:33 PM, Masahiro Yamada
>> <yamada.masahiro at socionext.com> wrote:
>>
>>> CONFIG_PINCTRL_MTK is more suitable than CONFIG_ARCH_MEDIATEK
>>> to guard the drivers/pinctrl/mediatek/ directory.
>>> (I renamed CONFIG_PINCTRL_MTK_COMMON to CONFIG_PINCTRL_MTK.)
>>>
>>> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
>>
>> This patch does not apply to linux v4.5-rc1, please rebase the
>> patch and resend.
>
>
> These two patches can be applied in this order:
> https://patchwork.kernel.org/patch/8097541/
> https://patchwork.kernel.org/patch/8097551/
>
> (Sorry, I should have sent them as a series.)

No order works for me and I have merged quite a lot of other stuff
that had higher priority.

But please rebase both patches on my "devel" branch and resend
and I will apply them.

Yours,
Linus Walleij


From gabriele.paoloni at huawei.com  Wed Feb 10 01:39:44 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Wed, 10 Feb 2016 09:39:44 +0000
Subject: [RFC PATCH v3 2/3] PCI: hisi: Add ECAM support to HiSilicon
 PCIe host controller
In-Reply-To: <20160209181641.GB4348@leverpostej>
References: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
 <1455039260-6040-3-git-send-email-gabriele.paoloni@huawei.com>
 <20160209181641.GB4348@leverpostej>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1544@lhreml503-mbs>

Hi Mark, thanks for reviewing

> -----Original Message-----
> From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-
> owner at vger.kernel.org] On Behalf Of Mark Rutland
> Sent: 09 February 2016 18:17
> To: Gabriele Paoloni
> Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C); Linuxarm;
> qiujiang; bhelgaas at google.com; arnd at arndb.de;
> Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-pci at vger.kernel.org;
> linux-kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth); linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [RFC PATCH v3 2/3] PCI: hisi: Add ECAM support to
> HiSilicon PCIe host controller
> 
> On Tue, Feb 09, 2016 at 05:34:19PM +0000, Gabriele Paoloni wrote:
> > From: gabriele paoloni <gabriele.paoloni at huawei.com>
> >
> > This patch modifies the current Hip05/Hip06 PCIe host
> > controller driver to add support for ECAM compliant
> > platforms.
> > This is needed in preparation for the ACPI based driver
> > to allow both DT and ACPI drivers to use the same BIOS
> > (that configure the Designware iATUs).
> > This commit doesn't break backward compatibility with
> > previous non-ECAM platforms.
> 
> Please forgive my ignorance, but if the system can be made ECAM
> compliant, why can the generic ECAM driver not be used in that case?

Sorry, you are right. The thing is that the driver is never
fully ECAM as for the RC config space there it uses 
"hisi_pcie_cfg_read()" and "hisi_pcie_cfg_write"; this is 
because generally Designware based controller are non-ECAM
and this is clear from:

http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L657

Here you can see that if bus->number == root_bus_nr a different
function is used to read/write configuration space registers

This patch implements ECAM support any connected PCIe device that
is not the root complex.

I will rephrase the patch in v4

Thanks

Gab

> 
> That would require no changes to this driver/binding.
> 
> Thanks,
> Mark.
> 
> > Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
> > Signed-off-by: Dongdong Liu <liudongdong3 at huawei.com>
> > ---
> >  .../devicetree/bindings/pci/hisilicon-pcie.txt     | 15 +++++---
> >  drivers/pci/host/pcie-designware.c                 |  4 +--
> >  drivers/pci/host/pcie-designware.h                 |  2 ++
> >  drivers/pci/host/pcie-hisi.c                       | 40
> ++++++++++++++++++++++
> >  4 files changed, 53 insertions(+), 8 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> > index b721bea..5a4c1e7 100644
> > --- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> > +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> > @@ -9,10 +9,13 @@ Additional properties are described here:
> >
> >  Required properties
> >  - compatible: Should contain "hisilicon,hip05-pcie" or
> "hisilicon,hip06-pcie".
> > -- reg: Should contain rc_dbi, config registers location and length.
> > -- reg-names: Must include the following entries:
> > +- reg: Should contain rc_dbi and  either config or ecam-cfg
> registers
> > +       location and length (it depends on the platform BIOS).
> > +- reg-names: Must include
> >    "rc_dbi": controller configuration registers;
> > -  "config": PCIe configuration space registers.
> > +  and one of the following entries:
> > +    "config": PCIe configuration space registers for non-ECAM
> platforms.
> > +    "ecam-cfg": PCIe configuration space registers for ECAM
> platforms
> >  - msi-parent: Should be its_pcie which is an ITS receiving MSI
> interrupts.
> >  - port-id: Should be 0, 1, 2 or 3.
> >
> > @@ -23,8 +26,10 @@ Optional properties:
> >  Hip05 Example (note that Hip06 is the same except compatible):
> >  	pcie at 0xb0080000 {
> >  		compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
> > -		reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0
> 0x2000>;
> > -		reg-names = "rc_dbi", "config";
> > +		reg = <0 0xb0080000 0 0x10000>,
> > +			  <0x220 0x00000000 0 0x2000>
> > +			/* or <0x220 0x00100000 0 0x0f00000> for ecam-cfg*/;
> > +		reg-names = "rc_dbi", "config" /* or "ecam-cfg" */;
> >  		bus-range = <0  15>;
> >  		msi-parent = <&its_pcie>;
> >  		#address-cells = <3>;
> > diff --git a/drivers/pci/host/pcie-designware.c
> b/drivers/pci/host/pcie-designware.c
> > index 2171682..5f19ea4 100644
> > --- a/drivers/pci/host/pcie-designware.c
> > +++ b/drivers/pci/host/pcie-designware.c
> > @@ -69,8 +69,6 @@
> >  #define PCIE_ATU_FUNC(x)		(((x) & 0x7) << 16)
> >  #define PCIE_ATU_UPPER_TARGET		0x91C
> >
> > -static struct pci_ops dw_pcie_ops;
> > -
> >  int dw_pcie_cfg_read(void __iomem *addr, int size, u32 *val)
> >  {
> >  	if ((uintptr_t)addr & (size - 1)) {
> > @@ -690,7 +688,7 @@ static int dw_pcie_wr_conf(struct pci_bus *bus,
> u32 devfn,
> >  	return dw_pcie_wr_other_conf(pp, bus, devfn, where, size, val);
> >  }
> >
> > -static struct pci_ops dw_pcie_ops = {
> > +struct pci_ops dw_pcie_ops = {
> >  	.read = dw_pcie_rd_conf,
> >  	.write = dw_pcie_wr_conf,
> >  };
> > diff --git a/drivers/pci/host/pcie-designware.h
> b/drivers/pci/host/pcie-designware.h
> > index 2356d29..3f42655 100644
> > --- a/drivers/pci/host/pcie-designware.h
> > +++ b/drivers/pci/host/pcie-designware.h
> > @@ -80,4 +80,6 @@ int dw_pcie_link_up(struct pcie_port *pp);
> >  void dw_pcie_setup_rc(struct pcie_port *pp);
> >  int dw_pcie_host_init(struct pcie_port *pp);
> >
> > +extern struct pci_ops dw_pcie_ops;
> > +
> >  #endif /* _PCIE_DESIGNWARE_H */
> > diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-
> hisi.c
> > index 458d0f8..d3e2047 100644
> > --- a/drivers/pci/host/pcie-hisi.c
> > +++ b/drivers/pci/host/pcie-hisi.c
> > @@ -43,6 +43,18 @@ struct pcie_soc_ops {
> >  	int (*hisi_pcie_link_up)(struct hisi_pcie *pcie);
> >  };
> >
> > +static inline int hisi_rd_ecam_conf(struct pcie_port *pp, struct
> pci_bus *bus,
> > +		unsigned int devfn, int where, int size, u32 *value)
> > +{
> > +	return pci_generic_config_read(bus, devfn, where, size, value);
> > +}
> > +
> > +static inline int hisi_wr_ecam_conf(struct pcie_port *pp, struct
> pci_bus *bus,
> > +		unsigned int devfn, int where, int size, u32 value)
> > +{
> > +	return pci_generic_config_write(bus, devfn, where, size, value);
> > +}
> > +
> >  static inline int hisi_pcie_cfg_read(struct pcie_port *pp, int
> where,
> >  		int size, u32 *val)
> >  {
> > @@ -72,6 +84,17 @@ struct pcie_host_ops hisi_pcie_host_ops = {
> >  		.link_up = hisi_pcie_link_up,
> >  };
> >
> > +static void __iomem *hisi_pci_map_cfg_bus_cam(struct pci_bus *bus,
> > +					     unsigned int devfn,
> > +					     int where)
> > +{
> > +	void __iomem *addr;
> > +	struct pcie_port *pp = bus->sysdata;
> > +
> > +	addr = pp->va_cfg1_base + where;
> > +
> > +	return addr;
> > +}
> >
> >  static int hisi_add_pcie_port(struct pcie_port *pp,
> >  				     struct platform_device *pdev)
> > @@ -137,6 +160,23 @@ static int hisi_pcie_probe(struct
> platform_device *pdev)
> >
> >  	hisi_pcie->pp.dbi_base = hisi_pcie->reg_base;
> >
> > +	reg = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam-
> cfg");
> > +	if (reg) {
> > +		/* ECAM driver version */
> > +		hisi_pcie->pp.va_cfg0_base =
> > +				devm_ioremap_resource(&pdev->dev, reg);
> > +		if (IS_ERR(hisi_pcie->pp.va_cfg0_base)) {
> > +			dev_err(pp->dev, "cannot get ecam-cfg\n");
> > +			return PTR_ERR(hisi_pcie->pp.va_cfg0_base);
> > +		}
> > +		hisi_pcie->pp.va_cfg1_base = hisi_pcie->pp.va_cfg0_base;
> > +
> > +		dw_pcie_ops.map_bus = hisi_pci_map_cfg_bus_cam;
> > +
> > +		hisi_pcie_host_ops.rd_other_conf = hisi_rd_ecam_conf;
> > +		hisi_pcie_host_ops.wr_other_conf = hisi_wr_ecam_conf;
> > +	}
> > +
> >  	ret = hisi_add_pcie_port(pp, pdev);
> >  	if (ret)
> >  		return ret;
> > --
> > 1.9.1
> >
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From marc.zyngier at arm.com  Wed Feb 10 01:50:52 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 09:50:52 +0000
Subject: [PATCH V3 01/10] irqchip / GICv3: Refactor gic_of_init() for
 GICv3 driver
In-Reply-To: <1453209083-3358-2-git-send-email-tn@semihalf.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
 <1453209083-3358-2-git-send-email-tn@semihalf.com>
Message-ID: <56BB07FC.8040609@arm.com>

On 19/01/16 13:11, Tomasz Nowicki wrote:
> Isolate hardware abstraction (FDT) code to gic_of_init().
> Rest of the logic goes to gic_init_bases() and expects well
> defined data to initialize GIC properly. The same solution
> is used for GICv2 driver.
> 
> This is needed for ACPI initialization later.
> 
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki at linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

	M.
-- 
Jazz is not dead. It just smells funny...


From sudeep.holla at arm.com  Wed Feb 10 01:51:32 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Wed, 10 Feb 2016 09:51:32 +0000
Subject: [PATCH] ARM: dts: rockchip: replace gpio-key,wakeup with
 wakeup-source property
In-Reply-To: <48510660.EJbbczq5fX@phil>
References: <1454968512-11956-1-git-send-email-sudeep.holla@arm.com>
 <48510660.EJbbczq5fX@phil>
Message-ID: <56BB0824.2030900@arm.com>



On 09/02/16 23:32, Heiko Stuebner wrote:
> Hi Sudeep,
>
> Am Montag, 8. Februar 2016, 21:55:12 schrieb Sudeep Holla:

[..]

>> Hi Heiko,
>>
>> You can reviewed this, however there are couple of ARM64 dts additions.
>> Also most of the other platform/SoC maintainers preferred to take it via
>> their tree and few of these got missed during v4.5 merge window.
>> Can you take it via your tree for v4.6 ?
>
> I've split the patch in two, as the 32 and 64 bit devicetree parts go
> through separate branches and applied both to their respective branches for
> v4.6

Thanks for splitting up the patch yourself.

-- 
Regards,
Sudeep


From gabriele.paoloni at huawei.com  Wed Feb 10 01:52:36 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Wed, 10 Feb 2016 09:52:36 +0000
Subject: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
 HiSilicon SoCs Host Controllers
In-Reply-To: <20160209182429.GD4348@leverpostej>
References: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
 <1455039260-6040-4-git-send-email-gabriele.paoloni@huawei.com>
 <20160209182429.GD4348@leverpostej>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1591@lhreml503-mbs>

Hi Mark

> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: 09 February 2016 18:24
> To: Gabriele Paoloni
> Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C); Linuxarm;
> qiujiang; bhelgaas at google.com; arnd at arndb.de;
> Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-pci at vger.kernel.org;
> linux-kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth); linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
> HiSilicon SoCs Host Controllers
> 
> On Tue, Feb 09, 2016 at 05:34:20PM +0000, Gabriele Paoloni wrote:
> > From: gabriele paoloni <gabriele.paoloni at huawei.com>
> >
> > This patch adds specific quirks for PCI config space accessors,
> > it uses _HID to decide whether to hook pci_ops or not.
> 
> If I understand correctly, this would mean that it's not actually ECAM
> compliant, then?

Correct we need out own methods to read/write the RC config space...see
for example:

+	if (bus->number == root->secondary.start)
+		return hisi_pcie_common_cfg_read(reg_base, where, size, val);
+
+	return pci_generic_config_read(bus, devfn, where, size, val);

> 
> > Signed-off-by: Dongdong Liu <liudongdong3 at huawei.com>
> > Signed-off-by: Gabriele Paoloni <gabriele.paoloni at huawei.com>
> > ---
> >  MAINTAINERS                       |   1 +
> >  drivers/pci/host/Kconfig          |   8 ++
> >  drivers/pci/host/Makefile         |   1 +
> >  drivers/pci/host/pcie-hisi-acpi.c | 188
> ++++++++++++++++++++++++++++++++++++++
> >  drivers/pci/host/pcie-hisi.c      |   2 -
> >  drivers/pci/host/pcie-hisi.h      |   2 +
> >  6 files changed, 200 insertions(+), 2 deletions(-)
> >  create mode 100644 drivers/pci/host/pcie-hisi-acpi.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index d69f436..f184c3e 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -8412,6 +8412,7 @@ F:
> 	Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> >  F:	drivers/pci/host/pcie-hisi.h
> >  F:	drivers/pci/host/pcie-hisi.c
> >  F:	drivers/pci/host/pcie-hisi-common.c
> > +F:	drivers/pci/host/pcie-hisi-acpi.c
> >
> >  PCIE DRIVER FOR QUALCOMM MSM
> >  M:     Stanimir Varbanov <svarbanov at mm-sol.com>
> > diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> > index 75a6054..65b1add 100644
> > --- a/drivers/pci/host/Kconfig
> > +++ b/drivers/pci/host/Kconfig
> > @@ -181,6 +181,14 @@ config PCI_HISI
> >  	  Say Y here if you want PCIe controller support on HiSilicon
> >  	  Hip05 and Hip06 SoCs
> >
> > +config PCI_HISI_ACPI
> > +	depends on ACPI
> > +	bool "HiSilicon Hip05 and Hip06 SoCs ACPI PCIe controllers"
> > +	select ACPI_PCI_HOST_GENERIC
> > +	help
> > +	  Say Y here if you want ACPI PCIe controller support on
> HiSilicon
> > +	  Hip05 and Hip06 SoCs
> > +
> >  config PCIE_QCOM
> >  	bool "Qualcomm PCIe controller"
> >  	depends on ARCH_QCOM && OF
> > diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> > index 8c93c0f..57e4379 100644
> > --- a/drivers/pci/host/Makefile
> > +++ b/drivers/pci/host/Makefile
> > @@ -21,4 +21,5 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
> >  obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
> >  obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
> >  obj-$(CONFIG_PCI_HISI) += pcie-hisi.o pcie-hisi-common.o
> > +obj-$(CONFIG_PCI_HISI_ACPI) += pcie-hisi-acpi.o pcie-hisi-common.o
> >  obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
> > diff --git a/drivers/pci/host/pcie-hisi-acpi.c
> b/drivers/pci/host/pcie-hisi-acpi.c
> > new file mode 100644
> > index 0000000..3605260
> > --- /dev/null
> > +++ b/drivers/pci/host/pcie-hisi-acpi.c
> > @@ -0,0 +1,188 @@
> > +/*
> > + * PCIe host controller driver for HiSilicon HipXX SoCs
> > + *
> > + * Copyright (C) 2016 HiSilicon Co., Ltd. http://www.hisilicon.com
> > + *
> > + * Author: Dongdong Liu <liudongdong3 at huawei.com>
> > + *         Gabriele Paoloni <gabriele.paoloni at huawei.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.
> > + */
> > +#include <linux/interrupt.h>
> > +#include <linux/acpi.h>
> > +#include <linux/ecam.h>
> > +#include <linux/pci.h>
> > +#include <linux/pci-acpi.h>
> > +#include "pcie-hisi.h"
> > +
> > +#define GET_PCIE_LINK_STATUS  0x0
> > +
> > +/* uuid 6d30f553-836c-408e-b6ad-45bccc957949 */
> > +const u8 hisi_pcie_acpi_dsm_uuid[] = {
> > +	0x53, 0xf5, 0x30, 0x6d, 0x6c, 0x83, 0x8e, 0x40,
> > +	0xb6, 0xad, 0x45, 0xbc, 0xcc, 0x95, 0x79, 0x49
> > +};
> > +
> > +static const struct acpi_device_id hisi_pcie_ids[] = {
> > +	{"HISI0080", 0},
> > +	{"", 0},
> > +};
> > +
> > +static int hisi_pcie_get_addr(struct acpi_pci_root *root, const char
> *name,
> > +				void __iomem **addr)
> > +{
> > +	struct acpi_device *device;
> > +	u64 base;
> > +	u64 size;
> > +	u32 buf[4];
> > +	int ret;
> > +
> > +	device =  root->device;
> > +	ret = fwnode_property_read_u32_array(&device->fwnode, name,
> > +					buf, ARRAY_SIZE(buf));
> > +	if (ret) {
> > +		dev_err(&device->dev, "can't get %s\n", name);
> > +		return ret;
> > +	}
> > +
> > +	base = ((u64)buf[0] << 32) | buf[1];
> > +	size =  ((u64)buf[2] << 32) | buf[3];
> > +	*addr = devm_ioremap(&device->dev, base, size);
> > +	if (!(*addr)) {
> > +		dev_err(&device->dev, "error with ioremap\n");
> > +		return -ENOMEM;
> > +	}
> 
> This does not seem like the correct way of describing an addres in
> ACPI.

Ok I guess this is related to the comment below...

> 
> > +
> > +	return 0;
> > +}
> > +
> > +
> > +static int hisi_pcie_link_up_acpi(struct acpi_pci_root *root)
> > +{
> > +	u32 val;
> > +	struct acpi_device *device;
> > +	union acpi_object *obj;
> > +
> > +	device = root->device;
> > +	obj = acpi_evaluate_dsm(device->handle,
> > +		hisi_pcie_acpi_dsm_uuid, 0,
> > +		GET_PCIE_LINK_STATUS, NULL);
> > +
> > +	if (!obj  ||  obj->type != ACPI_TYPE_INTEGER)  {
> > +		dev_err(&device->dev, "can't get link status from _DSM\n");
> > +		return 0;
> > +	}
> > +	val = obj->integer.value;
> > +
> > +	return ((val & PCIE_LTSSM_STATE_MASK) ==
> PCIE_LTSSM_LINKUP_STATE);
> > +
> > +}
> > +
> > +/*
> > + * Retrieve rc_dbi base and size from _DSD
> > + * Name (_DSD, Package () {
> > + *	ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > + *	Package () {
> > + *	Package () {"rc-dbi", Package () { 0x0, 0xb0080000, 0x0, 0x10000
> }},
> > + *	}
> > + *	})
> > + */
> 
> As above, this does not look right. ACPI has standard mechanisms for
> describing addresses. Making something up like this is not a good idea.
 
I am quite new to ACPI, may I ask you to explain a bit? 
In our case we need to put somewhere in the ACPI table the value of 
the base register address used to read/write the RC config space... 

Do you have any suggestion about the correct place to put it?

Many Thanks

Gab

> 
> Mark.



From marc.zyngier at arm.com  Wed Feb 10 01:55:46 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 09:55:46 +0000
Subject: [PATCH V3 02/10] irqchip / GICv3: Add ACPI support for GICv3+
 initialization
In-Reply-To: <1453209083-3358-3-git-send-email-tn@semihalf.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
 <1453209083-3358-3-git-send-email-tn@semihalf.com>
Message-ID: <56BB0922.3040507@arm.com>

On 19/01/16 13:11, Tomasz Nowicki wrote:
> With the refator of gic_of_init(), GICv3/4 can be initialized
> by gic_init_bases() with gic distributor base address and gic
> redistributor region(s).
> 
> So get the redistributor region base addresses from MADT GIC
> redistributor subtable, and the distributor base address from
> GICD subtable to init GICv3 irqchip in ACPI way.
> 
> Note: GIC redistributor base address may also be provided in
> GICC structures on systems supporting GICv3 and above if the GIC
> Redistributors are not in the always-on power domain, this
> patch didn't implement such feature yet.
> Also, ACPI ITS initialization will be added in the following patches.
> 
> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
> Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

	M.
-- 
Jazz is not dead. It just smells funny...


From linus.walleij at linaro.org  Wed Feb 10 01:56:05 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Feb 2016 10:56:05 +0100
Subject: [PATCH] pinctrl: uniphier: add COMPILE_TEST option
In-Reply-To: <1454247171-25028-1-git-send-email-yamada.masahiro@socionext.com>
References: <1454247171-25028-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <CACRpkdY88xjpZayhOVWmo7AGYjOAmZc60uRJ+DrT0aKV=8C0VA@mail.gmail.com>

On Sun, Jan 31, 2016 at 2:32 PM, Masahiro Yamada
<yamada.masahiro at socionext.com> wrote:

> Add COMPILE_TEST for the compilation test coverage.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>

Patch applied.

Yours,
Linus Walleij


From yamada.masahiro at socionext.com  Wed Feb 10 01:56:45 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Wed, 10 Feb 2016 18:56:45 +0900
Subject: [PATCH] pinctrl: mediatek: guard sub-directory with
 CONFIG_PINCTRL_MTK
In-Reply-To: <CACRpkdaA37GXf8c=EznSpocLp33CaU8dYqb8V0pua4dVfZa_2w@mail.gmail.com>
References: <1453563204-30407-1-git-send-email-yamada.masahiro@socionext.com>
 <CACRpkdbrJ5P8Ro4RQUquMOTuXhN+54ZHYGbLqrbwW6tbwCC7Mg@mail.gmail.com>
 <CAK7LNAQ_8o0FiRpb7D6RBmA+7WxRMFhWJjo2f4E_NH5qAGYb4A@mail.gmail.com>
 <CACRpkdaA37GXf8c=EznSpocLp33CaU8dYqb8V0pua4dVfZa_2w@mail.gmail.com>
Message-ID: <CAK7LNATxUjsEtVmD3i4ZByC3kjnOk7gMf29hOn7ZfQa2MB9Gqw@mail.gmail.com>

Hi Linus,


2016-02-10 18:29 GMT+09:00 Linus Walleij <linus.walleij at linaro.org>:
> On Thu, Jan 28, 2016 at 5:22 AM, Masahiro Yamada
> <yamada.masahiro at socionext.com> wrote:
>> Hi Linus
>>
>> 2016-01-27 23:11 GMT+09:00 Linus Walleij <linus.walleij at linaro.org>:
>>> On Sat, Jan 23, 2016 at 4:33 PM, Masahiro Yamada
>>> <yamada.masahiro at socionext.com> wrote:
>>>
>>>> CONFIG_PINCTRL_MTK is more suitable than CONFIG_ARCH_MEDIATEK
>>>> to guard the drivers/pinctrl/mediatek/ directory.
>>>> (I renamed CONFIG_PINCTRL_MTK_COMMON to CONFIG_PINCTRL_MTK.)
>>>>
>>>> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
>>>
>>> This patch does not apply to linux v4.5-rc1, please rebase the
>>> patch and resend.
>>
>>
>> These two patches can be applied in this order:
>> https://patchwork.kernel.org/patch/8097541/
>> https://patchwork.kernel.org/patch/8097551/
>>
>> (Sorry, I should have sent them as a series.)
>
> No order works for me and I have merged quite a lot of other stuff
> that had higher priority.
>
> But please rebase both patches on my "devel" branch and resend
> and I will apply them.
>

Sure.

The first one is already in your devel branch.

I've rebased and posted the second one.




-- 
Best Regards
Masahiro Yamada


From will.deacon at arm.com  Wed Feb 10 02:07:30 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 10:07:30 +0000
Subject: [PATCH] arm64: prefetch: add missing #include for spin_lock_prefetch
Message-ID: <1455098850-3551-1-git-send-email-will.deacon@arm.com>

As of 52e662326e1e ("arm64: prefetch: don't provide spin_lock_prefetch
with LSE"), spin_lock_prefetch is patched at runtime when the LSE atomics
are in use. This relies on the ARM64_LSE_ATOMIC_INSN macro to drive
the alternatives framework, but that macro is only available via
asm/lse.h, which isn't explicitly included in processor.h. Consequently,
drivers can run into build failures such as:

   In file included from include/linux/prefetch.h:14:0,
                    from drivers/net/ethernet/intel/i40e/i40e_txrx.c:27:
   arch/arm64/include/asm/processor.h: In function 'spin_lock_prefetch':
   arch/arm64/include/asm/processor.h:183:15: error: expected string literal before 'ARM64_LSE_ATOMIC_INSN'
     asm volatile(ARM64_LSE_ATOMIC_INSN(

This patch add the missing include and gets things building again.

Reported-by: kbuild test robot <fengguang.wu at intel.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm64/include/asm/processor.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 31b76fce4477..5bb1d763d17a 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -32,6 +32,7 @@
 #include <asm/alternative.h>
 #include <asm/fpsimd.h>
 #include <asm/hw_breakpoint.h>
+#include <asm/lse.h>
 #include <asm/pgtable-hwdef.h>
 #include <asm/ptrace.h>
 #include <asm/types.h>
-- 
2.1.4



From broonie at kernel.org  Wed Feb 10 02:08:37 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 10 Feb 2016 10:08:37 +0000
Subject: next-20160210 build: 2 failures 4 warnings (next-20160210)
In-Reply-To: <E1aTQoy-0005cH-Tr@optimist>
References: <E1aTQoy-0005cH-Tr@optimist>
Message-ID: <20160210100837.GT13270@sirena.org.uk>

On Wed, Feb 10, 2016 at 09:12:25AM +0000, Build bot for Mark Brown wrote:

Today's -next fails to build an arm64 allmodconfig due to:

> 	arm64-allmodconfig
> ../arch/arm64/include/asm/processor.h:183:15: error: expected string literal before 'ARM64_LSE_ATOMIC_INSN'

due to 52e662326e1e915 (arm64: prefetch: don't provide
spin_lock_prefetch with LSE) which adds use of ARM64_LSE_ATOMIC_INSN but
does not add an inclusion of asm/lse.h which defines it.  Most files
have an implicit include so build fine but a few don't which causes the
failure.  It does add an inclusion of asm/alternative.h which may be the
best place to add the inclusion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160210/6989b180/attachment.sig>

From will.deacon at arm.com  Wed Feb 10 02:12:39 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 10:12:39 +0000
Subject: next-20160210 build: 2 failures 4 warnings (next-20160210)
In-Reply-To: <20160210100837.GT13270@sirena.org.uk>
References: <E1aTQoy-0005cH-Tr@optimist> <20160210100837.GT13270@sirena.org.uk>
Message-ID: <20160210101238.GC1052@arm.com>

On Wed, Feb 10, 2016 at 10:08:37AM +0000, Mark Brown wrote:
> On Wed, Feb 10, 2016 at 09:12:25AM +0000, Build bot for Mark Brown wrote:
> 
> Today's -next fails to build an arm64 allmodconfig due to:
> 
> > 	arm64-allmodconfig
> > ../arch/arm64/include/asm/processor.h:183:15: error: expected string literal before 'ARM64_LSE_ATOMIC_INSN'
> 
> due to 52e662326e1e915 (arm64: prefetch: don't provide
> spin_lock_prefetch with LSE) which adds use of ARM64_LSE_ATOMIC_INSN but
> does not add an inclusion of asm/lse.h which defines it.  Most files
> have an implicit include so build fine but a few don't which causes the
> failure.  It does add an inclusion of asm/alternative.h which may be the
> best place to add the inclusion.

I just sent a fix to the list.

Will


From marc.zyngier at arm.com  Wed Feb 10 02:16:31 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 10:16:31 +0000
Subject: [PATCH V3 03/10] irqchip,GICv3,ACPI: Add redistributor support
 via GICC structures.
In-Reply-To: <1453209083-3358-4-git-send-email-tn@semihalf.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
 <1453209083-3358-4-git-send-email-tn@semihalf.com>
Message-ID: <56BB0DFF.1040802@arm.com>

On 19/01/16 13:11, Tomasz Nowicki wrote:
> Following ACPI spec:
> On systems supporting GICv3 and above, GICR Base Address in MADT GICC
> structure holds the 64-bit physical address of the associated Redistributor.
> If all of the GIC Redistributors are in the always-on power domain,
> GICR structures should be used to describe the Redistributors instead,
> and this field must be set to 0.
> 
> It means that we have two ways to initialize registirbutors map.
> 1. via GICD structure which can accommodate many redistributors as a region
> 2. via GICC which is able to describe single redistributor
> 
> This patch is going to add support for second option.
> Considering redistributors, GICD and GICC subtables have be mutually
> exclusive. While discovering and mapping redistributor, we need to know
> its size in advance. For the GICC case, redistributor can be in
> a power-domain that is off, thus we cannot relay on GICR TYPER register.
> Therefore, we get GIC version from distributor register and map 2xSZ_64K
> for GICv3 and 4xSZ_64K for GICv4.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>

This is incredibly convoluted, but I'm not sure there is a better way
given the current ACPI API. Still, it hurts.

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

	M.
-- 
Jazz is not dead. It just smells funny...


From marc.zyngier at arm.com  Wed Feb 10 02:19:06 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 10:19:06 +0000
Subject: [PATCH V3 00/10] Introduce ACPI world to GICv3 & ITS irqchip
In-Reply-To: <56BAFAE8.4070308@semihalf.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
 <56BAFAE8.4070308@semihalf.com>
Message-ID: <56BB0E9A.6010809@arm.com>

Thomasz,

On 10/02/16 08:55, Tomasz Nowicki wrote:
> On 19.01.2016 14:11, Tomasz Nowicki wrote:
>> Patches base on Suravee's ACPI GICv2m support:
>> https://lkml.org/lkml/2015/12/10/475
>>
>> The following git branch contains submitted patches along with
>> the useful patches from the test point of view (mainly ACPI ARM64 PCI support).
>> https://github.com/semihalf-nowicki-tomasz/linux.git (gicv3-its-acpi-v3)
>>
> 
> Hi Marc,
> 
> Can you please have a look at this series. I think your previous 
> concerns have been addressed.

I've just acked the first 3 patches, which I believe are good to go.

The ITS support is a separate thing, mostly because it introduces a
completely new infrastructure (IORT). I'll review that separately (no
need to resend the patches though).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From robin.murphy at arm.com  Wed Feb 10 02:25:07 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 10 Feb 2016 10:25:07 +0000
Subject: [PATCH v3 3/8] dma-mapping: add dma_{map,unmap}_resource
In-Reply-To: <1455065878-11906-4-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <1455065878-11906-4-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <56BB1003.8020409@arm.com>

Hi Niklas,

Thanks for doing this, it looks good. Just a couple of minor comments on 
this and the next patch...

On 10/02/16 00:57, Niklas S?derlund wrote:
> Map/Unmap a device resource from a physical address. If no dma_map_ops
> method is available the operation is a no-op.
>
> Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
> ---
>   include/linux/dma-mapping.h | 27 +++++++++++++++++++++++++++
>   1 file changed, 27 insertions(+)
>
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index e3aba4e..21bf986 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -216,6 +216,33 @@ static inline void dma_unmap_page(struct device *dev, dma_addr_t addr,
>   	debug_dma_unmap_page(dev, addr, size, dir, false);
>   }
>
> +static inline dma_addr_t dma_map_resource(struct device *dev,
> +					  phys_addr_t phys_addr,
> +					  size_t size,
> +					  enum dma_data_direction dir,
> +					  struct dma_attrs *attrs)
> +{
> +	struct dma_map_ops *ops = get_dma_ops(dev);
> +
> +	BUG_ON(!valid_dma_direction(dir));

I think it would be worth also having the same inverse pfn_valid() check 
as ioremap() here, to make sure this is similarly hard to misuse.

Robin.

> +	if (ops->map_resource)
> +		return ops->map_resource(dev, phys_addr, size, dir, attrs);
> +
> +	return phys_addr;
> +}
> +
> +static inline void dma_unmap_resource(struct device *dev, dma_addr_t addr,
> +				      size_t size, enum dma_data_direction dir,
> +				      struct dma_attrs *attrs)
> +{
> +	struct dma_map_ops *ops = get_dma_ops(dev);
> +
> +	BUG_ON(!valid_dma_direction(dir));
> +	if (ops->unmap_resource)
> +		ops->unmap_resource(dev, addr, size, dir, attrs);
> +
> +}
> +
>   static inline void dma_sync_single_for_cpu(struct device *dev, dma_addr_t addr,
>   					   size_t size,
>   					   enum dma_data_direction dir)
>



From marc.zyngier at arm.com  Wed Feb 10 02:25:39 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 10:25:39 +0000
Subject: [PATCH V3 04/10] irqchip / GICv3: remove gic root node in ITS
In-Reply-To: <1453209083-3358-5-git-send-email-tn@semihalf.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
 <1453209083-3358-5-git-send-email-tn@semihalf.com>
Message-ID: <56BB1023.4090005@arm.com>

On 19/01/16 13:11, Tomasz Nowicki wrote:
> From: Hanjun Guo <hanjun.guo at linaro.org>
> 
> The gic_root_node defined in ITS driver is not actually
> used, and the ITS driver seems will not use it in the
> future, so just remove it.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

	M.
-- 
Jazz is not dead. It just smells funny...


From will.deacon at arm.com  Wed Feb 10 02:29:40 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 10:29:40 +0000
Subject: [PATCH] arm64: use raw_smp_processor_id in stack backtrace dump
In-Reply-To: <1455053182-31404-1-git-send-email-yang.shi@linaro.org>
References: <1455053182-31404-1-git-send-email-yang.shi@linaro.org>
Message-ID: <20160210102939.GD1052@arm.com>

On Tue, Feb 09, 2016 at 01:26:22PM -0800, Yang Shi wrote:
> dump_backtrace may be called in kthread context, which is not bound to a single
> cpu, i.e. khungtaskd, then calling smp_processor_id may trigger the below bug
> report:

If we're preemptible here, it means that our irq_stack_ptr is potentially
bogus. Whilst this isn't an issue for kthreads, it does feel like we
could make this slightly more robust in the face of potential frame
corruption. Maybe just zero the IRQ stack pointer if we're in preemptible
context?

Will

> BUG: using smp_processor_id() in preemptible [00000000] code: khungtaskd/71
> caller is debug_smp_processor_id+0x1c/0x28
> CPU: 3 PID: 71 Comm: khungtaskd Not tainted 4.5.0-rc1 #144
> Hardware name: Freescale Layerscape 2085a RDB Board (DT)
> Call trace:
> [<ffffffc00008d120>] dump_backtrace+0x0/0x290
> [<ffffffc00008d3d4>] show_stack+0x24/0x30
> [<ffffffc0006bfd1c>] dump_stack+0x8c/0xd8
> [<ffffffc0006fe56c>] check_preemption_disabled+0x184/0x188
> [<ffffffc0006fe58c>] debug_smp_processor_id+0x1c/0x28
> [<ffffffc00008d1a4>] dump_backtrace+0x84/0x290
> [<ffffffc00008d3d4>] show_stack+0x24/0x30
> [<ffffffc00012aa5c>] sched_show_task+0x16c/0x280
> [<ffffffc0001f3df8>] watchdog+0x560/0x708
> [<ffffffc000111bb8>] kthread+0x1b0/0x1d0
> [<ffffffc0000864d0>] ret_from_fork+0x10/0x40
> 
> Replace it to raw version to prevent from the race condition.
> 
> Signed-off-by: Yang Shi <yang.shi at linaro.org>
> ---
>  arch/arm64/kernel/traps.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index cbedd72..9abe236 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -146,7 +146,7 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
>  static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
>  {
>  	struct stackframe frame;
> -	unsigned long irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
> +	unsigned long irq_stack_ptr = IRQ_STACK_PTR(raw_smp_processor_id());
>  	int skip;
>  
>  	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
> -- 
> 2.0.2
> 


From marc.zyngier at arm.com  Wed Feb 10 02:30:46 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 10:30:46 +0000
Subject: [PATCH V3 05/10] irqchip, gicv3, its: Mark its_init() and its
 children as __init
In-Reply-To: <1453209083-3358-6-git-send-email-tn@semihalf.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
 <1453209083-3358-6-git-send-email-tn@semihalf.com>
Message-ID: <56BB1156.4070507@arm.com>

On 19/01/16 13:11, Tomasz Nowicki wrote:
> gicv3_init_bases() is the only caller for its_init(),
> also it is a __init function, so mark its_init() as __init too,
> then recursively mark the functions called as __init.
> 
> This will help to introduce ITS initialization using ACPI tables as
> we will use acpi_table_parse_entries family functions there which
> belong to __init section as well.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

	M.
-- 
Jazz is not dead. It just smells funny...


From will.deacon at arm.com  Wed Feb 10 02:36:01 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 10:36:01 +0000
Subject: [PATCH v10 01/21] ARM64: Move PMU register related defines to
 asm/pmu.h
In-Reply-To: <1453866709-20324-2-git-send-email-zhaoshenglong@huawei.com>
References: <1453866709-20324-1-git-send-email-zhaoshenglong@huawei.com>
 <1453866709-20324-2-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <20160210103600.GE1052@arm.com>

On Wed, Jan 27, 2016 at 11:51:29AM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
> 
> To use the ARMv8 PMU related register defines from the KVM code,
> we move the relevant definitions to asm/pmu.h header file.
> 
> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> Acked-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/pmu.h   | 67 ++++++++++++++++++++++++++++++++++++++++++
>  arch/arm64/kernel/perf_event.c | 36 +----------------------
>  2 files changed, 68 insertions(+), 35 deletions(-)
>  create mode 100644 arch/arm64/include/asm/pmu.h
> 
> diff --git a/arch/arm64/include/asm/pmu.h b/arch/arm64/include/asm/pmu.h
> new file mode 100644
> index 0000000..4406184
> --- /dev/null
> +++ b/arch/arm64/include/asm/pmu.h

I think you can stick this in perf_event.h and avoid having a brand
new header.

> @@ -0,0 +1,67 @@
> +/*
> + * PMU support
> + *
> + * Copyright (C) 2012 ARM Limited
> + * Author: Will Deacon <will.deacon at arm.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/>.
> + */
> +#ifndef __ASM_PMU_H
> +#define __ASM_PMU_H
> +
> +#define ARMV8_MAX_COUNTERS      32
> +#define ARMV8_COUNTER_MASK      (ARMV8_MAX_COUNTERS - 1)

[...]

> +/*
> + * Event filters for PMUv3
> + */
> +#define	ARMV8_EXCLUDE_EL1	(1 << 31)
> +#define	ARMV8_EXCLUDE_EL0	(1 << 30)
> +#define	ARMV8_INCLUDE_EL2	(1 << 27)

You should prefix these more specifically if they're going to be exposed
like this. Something like ARMV8_PMU_*.

Will


From catalin.marinas at arm.com  Wed Feb 10 02:38:14 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 10 Feb 2016 10:38:14 +0000
Subject: [PATCHv4 2/3] arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
In-Reply-To: <1454718288-31374-3-git-send-email-labbott@fedoraproject.org>
References: <1454718288-31374-1-git-send-email-labbott@fedoraproject.org>
 <1454718288-31374-3-git-send-email-labbott@fedoraproject.org>
Message-ID: <20160210103814.GC13577@e104818-lin.cambridge.arm.com>

On Fri, Feb 05, 2016 at 04:24:47PM -0800, Laura Abbott wrote:
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -149,6 +149,19 @@ static void split_pud(pud_t *old_pud, pmd_t *pmd)
>  	} while (pmd++, i++, i < PTRS_PER_PMD);
>  }
>  
> +bool block_mappings_allowed(phys_addr_t (*pgtable_alloc)(void))
> +{
> +
> +	/*
> +	 * If debug_page_alloc is enabled we must map the linear map
> +	 * using pages. However, other mappings created by
> +	 * create_mapping_noalloc must use sections in some cases. Allow
> +	 * sections to be used in those cases, where no pgtable_alloc
> +	 * function is provided.
> +	 */
> +	return !pgtable_alloc || !debug_pagealloc_enabled();
> +}

This breaks the build when CONFIG_DEBUG_PAGEALLOC is not enabled
(defconfig) since debug_pagealloc_enabled() is not defined. A fix went
in next/master as commit 0987684b855c
("mm-slab-clean-up-debug_pagealloc-processing-code-fix"). I need to
track it down and merge it via the arm64 tree, otherwise I'll add some
#ifdefs in this function.

BTW, shouldn't the block_mappings_allowed() function be static?

-- 
Catalin


From ard.biesheuvel at linaro.org  Wed Feb 10 02:40:00 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 10 Feb 2016 11:40:00 +0100
Subject: [PATCHv4 2/3] arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
In-Reply-To: <20160210103814.GC13577@e104818-lin.cambridge.arm.com>
References: <1454718288-31374-1-git-send-email-labbott@fedoraproject.org>
 <1454718288-31374-3-git-send-email-labbott@fedoraproject.org>
 <20160210103814.GC13577@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu9H2d5762MBAJGrxchw1CYCsz0WwAs=8zTf0aB1eFT8RQ@mail.gmail.com>

On 10 February 2016 at 11:38, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Fri, Feb 05, 2016 at 04:24:47PM -0800, Laura Abbott wrote:
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -149,6 +149,19 @@ static void split_pud(pud_t *old_pud, pmd_t *pmd)
>>       } while (pmd++, i++, i < PTRS_PER_PMD);
>>  }
>>
>> +bool block_mappings_allowed(phys_addr_t (*pgtable_alloc)(void))
>> +{
>> +
>> +     /*
>> +      * If debug_page_alloc is enabled we must map the linear map
>> +      * using pages. However, other mappings created by
>> +      * create_mapping_noalloc must use sections in some cases. Allow
>> +      * sections to be used in those cases, where no pgtable_alloc
>> +      * function is provided.
>> +      */
>> +     return !pgtable_alloc || !debug_pagealloc_enabled();
>> +}
>
> This breaks the build when CONFIG_DEBUG_PAGEALLOC is not enabled
> (defconfig) since debug_pagealloc_enabled() is not defined. A fix went
> in next/master as commit 0987684b855c
> ("mm-slab-clean-up-debug_pagealloc-processing-code-fix"). I need to
> track it down and merge it via the arm64 tree, otherwise I'll add some
> #ifdefs in this function.
>
> BTW, shouldn't the block_mappings_allowed() function be static?
>

Yes, it should.


From catalin.marinas at arm.com  Wed Feb 10 02:41:16 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 10 Feb 2016 10:41:16 +0000
Subject: [PATCH] arm64: prefetch: add missing #include for
 spin_lock_prefetch
In-Reply-To: <1455098850-3551-1-git-send-email-will.deacon@arm.com>
References: <1455098850-3551-1-git-send-email-will.deacon@arm.com>
Message-ID: <20160210104116.GD13577@e104818-lin.cambridge.arm.com>

On Wed, Feb 10, 2016 at 10:07:30AM +0000, Will Deacon wrote:
> As of 52e662326e1e ("arm64: prefetch: don't provide spin_lock_prefetch
> with LSE"), spin_lock_prefetch is patched at runtime when the LSE atomics
> are in use. This relies on the ARM64_LSE_ATOMIC_INSN macro to drive
> the alternatives framework, but that macro is only available via
> asm/lse.h, which isn't explicitly included in processor.h. Consequently,
> drivers can run into build failures such as:
> 
>    In file included from include/linux/prefetch.h:14:0,
>                     from drivers/net/ethernet/intel/i40e/i40e_txrx.c:27:
>    arch/arm64/include/asm/processor.h: In function 'spin_lock_prefetch':
>    arch/arm64/include/asm/processor.h:183:15: error: expected string literal before 'ARM64_LSE_ATOMIC_INSN'
>      asm volatile(ARM64_LSE_ATOMIC_INSN(
> 
> This patch add the missing include and gets things building again.
> 
> Reported-by: kbuild test robot <fengguang.wu at intel.com>
> Signed-off-by: Will Deacon <will.deacon at arm.com>

Applied. Thanks.

-- 
Catalin


From marc.zyngier at arm.com  Wed Feb 10 02:47:36 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 10:47:36 +0000
Subject: [PATCH V3 06/10] irqchip, GICv3, ITS: Refator ITS dt init code to
 prepare for ACPI.
In-Reply-To: <1453209083-3358-7-git-send-email-tn@semihalf.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
 <1453209083-3358-7-git-send-email-tn@semihalf.com>
Message-ID: <56BB1548.5050402@arm.com>

On 19/01/16 13:11, Tomasz Nowicki wrote:
> Similarly to GICv3 core, we need to extract common code before adding
> ACPI support. No functional changes.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
> ---
>  drivers/irqchip/irq-gic-v3-its.c   | 82 +++++++++++++++++++++++---------------
>  drivers/irqchip/irq-gic-v3.c       |  6 +--
>  include/linux/irqchip/arm-gic-v3.h |  2 +-
>  3 files changed, 52 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 2bbed18..fecb7a6 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -813,7 +813,7 @@ static void its_free_tables(struct its_node *its)
>  	}
>  }
>  
> -static int its_alloc_tables(const char *node_name, struct its_node *its)
> +static int its_alloc_tables(struct its_node *its)
>  {
>  	int err;
>  	int i;
> @@ -868,8 +868,8 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
>  				    order);
>  			if (order >= MAX_ORDER) {
>  				order = MAX_ORDER - 1;
> -				pr_warn("%s: Device Table too large, reduce its page order to %u\n",
> -					node_name, order);
> +				pr_warn("ITS at 0x%lx: Device Table too large, reduce its page order to %u\n",
> +					its->phys_base, order);
>  			}
>  		}
>  
> @@ -878,8 +878,8 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
>  		if (alloc_pages > GITS_BASER_PAGES_MAX) {
>  			alloc_pages = GITS_BASER_PAGES_MAX;
>  			order = get_order(GITS_BASER_PAGES_MAX * psz);
> -			pr_warn("%s: Device Table too large, reduce its page order to %u (%u pages)\n",
> -				node_name, order, alloc_pages);
> +			pr_warn("ITS at 0x%lx: Device Table too large, reduce its page order to %u (%u pages)\n",
> +				its->phys_base, order, alloc_pages);
>  		}
>  
>  		base = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
> @@ -948,8 +948,8 @@ retry_baser:
>  		}
>  
>  		if (val != tmp) {
> -			pr_err("ITS: %s: GITS_BASER%d doesn't stick: %lx %lx\n",
> -			       node_name, i,
> +			pr_err("ITS at 0x%lx: GITS_BASER%d doesn't stick: %lx %lx\n",
> +			       its->phys_base, i,
>  			       (unsigned long) val, (unsigned long) tmp);
>  			err = -ENXIO;
>  			goto out_free;
> @@ -1424,10 +1424,11 @@ static void its_enable_quirks(struct its_node *its)
>  	gic_enable_quirks(iidr, its_quirks, its);
>  }
>  
> -static int __init its_probe(struct device_node *node,
> -			    struct irq_domain *parent)
> +static int __init its_probe_one(phys_addr_t phys_base, unsigned long size,
> +				struct irq_domain *parent,
> +				bool is_msi_controller,

I really question the fact that you are keeping this msi_controller
thing. Let's face it: if this is not an MSI controller, then the whole
thing is absolutely pointless.

So I'd rather you simplify the whole in a separate patch, and just don't
bother initializing the ITS if it cannot be used for MSIs.

> +				struct fwnode_handle *handler)
>  {
> -	struct resource res;
>  	struct its_node *its;
>  	void __iomem *its_base;
>  	struct irq_domain *inner_domain;
> @@ -1435,33 +1436,26 @@ static int __init its_probe(struct device_node *node,
>  	u64 baser, tmp;
>  	int err;
>  
> -	err = of_address_to_resource(node, 0, &res);
> -	if (err) {
> -		pr_warn("%s: no regs?\n", node->full_name);
> -		return -ENXIO;
> -	}
> -
> -	its_base = ioremap(res.start, resource_size(&res));
> +	its_base = ioremap(phys_base, size);
>  	if (!its_base) {
> -		pr_warn("%s: unable to map registers\n", node->full_name);
> +		pr_warn("Unable to map ITS registers\n");

There is some value in at least displaying the base address - think of
people writing their DT or ACPI tables. Please do not blindly remove
debugging information which is often useful on a system with multiple ITS.

>  		return -ENOMEM;
>  	}
>  
>  	val = readl_relaxed(its_base + GITS_PIDR2) & GIC_PIDR2_ARCH_MASK;
>  	if (val != 0x30 && val != 0x40) {
> -		pr_warn("%s: no ITS detected, giving up\n", node->full_name);
> +		pr_warn("No ITS detected, giving up\n");
>  		err = -ENODEV;
>  		goto out_unmap;
>  	}
>  
>  	err = its_force_quiescent(its_base);
>  	if (err) {
> -		pr_warn("%s: failed to quiesce, giving up\n",
> -			node->full_name);
> +		pr_warn("Failed to quiesce, giving up\n");
>  		goto out_unmap;
>  	}
>  
> -	pr_info("ITS: %s\n", node->full_name);
> +	pr_info("ITS at 0x%lx\n", (long)phys_base);
>  
>  	its = kzalloc(sizeof(*its), GFP_KERNEL);
>  	if (!its) {
> @@ -1473,7 +1467,7 @@ static int __init its_probe(struct device_node *node,
>  	INIT_LIST_HEAD(&its->entry);
>  	INIT_LIST_HEAD(&its->its_device_list);
>  	its->base = its_base;
> -	its->phys_base = res.start;
> +	its->phys_base = phys_base;
>  	its->ite_size = ((readl_relaxed(its_base + GITS_TYPER) >> 4) & 0xf) + 1;
>  
>  	its->cmd_base = kzalloc(ITS_CMD_QUEUE_SZ, GFP_KERNEL);
> @@ -1485,7 +1479,7 @@ static int __init its_probe(struct device_node *node,
>  
>  	its_enable_quirks(its);
>  
> -	err = its_alloc_tables(node->full_name, its);
> +	err = its_alloc_tables(its);
>  	if (err)
>  		goto out_free_cmd;
>  
> @@ -1521,7 +1515,7 @@ static int __init its_probe(struct device_node *node,
>  	writeq_relaxed(0, its->base + GITS_CWRITER);
>  	writel_relaxed(GITS_CTLR_ENABLE, its->base + GITS_CTLR);
>  
> -	if (of_property_read_bool(node, "msi-controller")) {
> +	if (is_msi_controller) {
>  		struct msi_domain_info *info;
>  
>  		info = kzalloc(sizeof(*info), GFP_KERNEL);
> @@ -1530,7 +1524,8 @@ static int __init its_probe(struct device_node *node,
>  			goto out_free_tables;
>  		}
>  
> -		inner_domain = irq_domain_add_tree(node, &its_domain_ops, its);
> +		inner_domain = irq_domain_create_tree(handler, &its_domain_ops,
> +						      its);
>  		if (!inner_domain) {
>  			err = -ENOMEM;
>  			kfree(info);
> @@ -1558,10 +1553,28 @@ out_free_its:
>  	kfree(its);
>  out_unmap:
>  	iounmap(its_base);
> -	pr_err("ITS: failed probing %s (%d)\n", node->full_name, err);
> +	pr_err("ITS at 0x%lx: failed probing (%d)\n", (long)phys_base, err);
>  	return err;
>  }
>  
> +static int __init
> +its_of_probe(struct device_node *node, struct irq_domain *parent)
> +{
> +	struct resource res;
> +	bool is_msi_controller = false;
> +
> +	if (of_address_to_resource(node, 0, &res)) {
> +		pr_warn("%s: no regs?\n", node->full_name);
> +		return -ENXIO;
> +	}
> +
> +	if (of_property_read_bool(node, "msi-controller"))
> +		is_msi_controller = true;

This is where you should return early, with a message saying that this
ITS is being ignored if it doesn't have the msi-controller property.

> +
> +	return its_probe_one(res.start, resource_size(&res), parent,
> +			    is_msi_controller, &node->fwnode);
> +}
> +
>  static bool gic_rdists_supports_plpis(void)
>  {
>  	return !!(readl_relaxed(gic_data_rdist_rd_base() + GICR_TYPER) & GICR_TYPER_PLPIS);
> @@ -1586,14 +1599,17 @@ static struct of_device_id its_device_id[] = {
>  	{},
>  };
>  
> -int __init its_init(struct device_node *node, struct rdists *rdists,
> -	     struct irq_domain *parent_domain)
> +int __init its_init(struct fwnode_handle *handle, struct rdists *rdists,
> +		    struct irq_domain *parent_domain)
>  {
> -	struct device_node *np;
> +	struct device_node *np, *of_node;
>  
> -	for (np = of_find_matching_node(node, its_device_id); np;
> -	     np = of_find_matching_node(np, its_device_id)) {
> -		its_probe(np, parent_domain);
> +	of_node = to_of_node(handle);
> +	if (of_node) {
> +		for (np = of_find_matching_node(of_node, its_device_id); np;
> +		     np = of_find_matching_node(np, its_device_id)) {
> +			its_of_probe(np, parent_domain);
> +		}
>  	}
>  
>  	if (list_empty(&its_nodes)) {
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index dd16a60..995b7251 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -832,7 +832,6 @@ static int __init gic_init_bases(void __iomem *dist_base,
>  				 u64 redist_stride,
>  				 struct fwnode_handle *handle)
>  {
> -	struct device_node *node;
>  	u32 typer;
>  	int gic_irqs;
>  	int err;
> @@ -872,10 +871,9 @@ static int __init gic_init_bases(void __iomem *dist_base,
>  
>  	set_handle_irq(gic_handle_irq);
>  
> -	node = to_of_node(handle);
>  	if (IS_ENABLED(CONFIG_ARM_GIC_V3_ITS) && gic_dist_supports_lpis() &&
> -	    node) /* Temp hack to prevent ITS init for ACPI */
> -		its_init(node, &gic_data.rdists, gic_data.domain);
> +	    to_of_node(handle)) /* Temp hack to prevent ITS init for ACPI */
> +		its_init(handle, &gic_data.rdists, gic_data.domain);
>  
>  	gic_smp_init();
>  	gic_dist_init();
> diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
> index d5d798b..a40ed7d 100644
> --- a/include/linux/irqchip/arm-gic-v3.h
> +++ b/include/linux/irqchip/arm-gic-v3.h
> @@ -332,7 +332,7 @@ struct rdists {
>  struct irq_domain;
>  struct device_node;
>  int its_cpu_init(void);
> -int its_init(struct device_node *node, struct rdists *rdists,
> +int its_init(struct fwnode_handle *handle, struct rdists *rdists,
>  	     struct irq_domain *domain);
>  
>  static inline bool gic_enable_sre(void)
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From m.szyprowski at samsung.com  Wed Feb 10 02:47:26 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed, 10 Feb 2016 11:47:26 +0100
Subject: [PATCH v5 RESEND 1/5] drivers: nvdimm: ensure no negative value gets
 returned on positive match
In-Reply-To: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
References: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455101250-11327-2-git-send-email-m.szyprowski@samsung.com>

From: Dan Williams <dan.j.williams at intel.com>

This patch ensures that existing bus match callbacks don't return
negative values (which might be interpreted as potential errors in the
future) in case of positive match.

Signed-off-by: Dan Williams <dan.j.williams at intel.com>
Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/nvdimm/bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
index 7e2c43f..2b2181c 100644
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -62,7 +62,7 @@ static int nvdimm_bus_match(struct device *dev, struct device_driver *drv)
 {
 	struct nd_device_driver *nd_drv = to_nd_device_driver(drv);
 
-	return test_bit(to_nd_device_type(dev), &nd_drv->type);
+	return !!test_bit(to_nd_device_type(dev), &nd_drv->type);
 }
 
 static struct module *to_bus_provider(struct device *dev)
-- 
1.9.2



From m.szyprowski at samsung.com  Wed Feb 10 02:47:25 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed, 10 Feb 2016 11:47:25 +0100
Subject: [PATCH v5 RESEND 0/5] AMBA: add complete support for power domains
Message-ID: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>

(Old thread name: Exynos4210: fix power domain for MDMA1 device)

This patchset fixes mysterious boot hang on Exynos 4210 SoCs, when IOMMU
is enabled. There is no direct dependency between IOMMU devices and
MDMA1. However enabling IOMMU changes the device probe order, what
results in LCD0 power domain being turned off for some time. During that
time the registration of MDMA1 device happens, what results in system
hangs, because the common bus code tries to read PID/CID registers from
turned-off device.

Since the proposed change in the driver core had impact on existing
drivers (see '-next regression: "driver cohandle -EPROBE_DEFER from
bus_type.match()"' thread https://lkml.org/lkml/2015/12/17/390 ), I've
checked all the functions assigned to match callback of struct bus_type
objects and found that there are only 4 such functions that don't return
0/1 values:

1. arch/arm/common/sa1111.c: sa1111_match -> result of bitwise &
2. drivers/nvdimm/bus.c: nvdimm_bus_match -> result of test_bit()
3. drivers/sh/superhyway/superhyway.c: superhyway_bus_match -> error codes
     (this is really funny case, all errors are resolved to 'matched' case)
4. drivers/staging/unisys/visorbus/visorbus_main.c: visorbus_match -> 0 and
     some positive integer values, safe for now

The list of functions that I've examined has been generated by following
shell command:
$ git grep -Pp "\.match\s" | grep -A1 bus_type | grep "\.match\s" | tr -s "\t;&,=:" " " | cut -d" " -f1,3

Only the first two functions require potential fixing to ensure that
correct match will not result in negative return value, so the 2
additional patches have been added to v5 patchset.

Best regards
Marek Szyprowski
Samsung R&D Institute Poland

Changelog:

v5:
- added 2 more patches to avoid regression with existing drivers (nvdimm and
  sa1111), for more information, see https://lkml.org/lkml/2015/12/17/390
- changed thread name to "AMBA: add complete support for power domains"

v4: https://lkml.org/lkml/2015/12/2/52
- fixed more issues pointed by Ulf Hansson and Russell King

v3: https://lkml.org/lkml/2015/12/1/334
- fixed issues pointed by Ulf Hansson
- dropped patch for exynos4210 dts, because it already got queued for merging

v2: https://lkml.org/lkml/2015/11/26/229
- added 2 patches from 'On-demand device probing' thread
  (https://lkml.org/lkml/2015/9/29/189), which move PID/CIR reading
  from amba_device_add() to amba_match()
- moved dev_pm_domain_attach() to amba_match(), which is allowed to
  return -EPROBE_DEFER

v1: http://www.spinics.net/lists/arm-kernel/msg463185.html
- initial version


Patch summary:

Dan Williams (1):
  drivers: nvdimm: ensure no negative value gets returned on positive
    match

Marek Szyprowski (2):
  ARM: sa1111: ensure no negative value gets returned on positive match
  ARM: amba: Properly handle devices with power domains

Tomeu Vizoso (2):
  driver core: handle -EPROBE_DEFER from bus_type.match()
  ARM: amba: Move reading of periphid to amba_match()

 Documentation/driver-model/porting.txt |   6 +-
 arch/arm/common/sa1111.c               |   2 +-
 drivers/amba/bus.c                     | 152 ++++++++++++++++++---------------
 drivers/base/dd.c                      |  24 +++++-
 drivers/nvdimm/bus.c                   |   2 +-
 include/linux/device.h                 |   7 +-
 6 files changed, 114 insertions(+), 79 deletions(-)

-- 
1.9.2



From m.szyprowski at samsung.com  Wed Feb 10 02:47:29 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed, 10 Feb 2016 11:47:29 +0100
Subject: [PATCH v5 RESEND 4/5] ARM: amba: Move reading of periphid to
 amba_match()
In-Reply-To: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
References: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455101250-11327-5-git-send-email-m.szyprowski@samsung.com>

From: Tomeu Vizoso <tomeu.vizoso at collabora.com>

Reading the periphid when the Primecell device is registered means that
the apb pclk must be available by then or the device won't be registered
at all.

By reading the periphid in amba_match() we can return -EPROBE_DEFER if
the apb pclk isn't there yet and the device will be retried later.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso at collabora.com>
[minor code adjustments, removed forward declaration, added missing
comment]
Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
Reviewed-by: Ulf Hansson <ulf.hansson at linaro.org>
---
 drivers/amba/bus.c | 146 +++++++++++++++++++++++++++--------------------------
 1 file changed, 75 insertions(+), 71 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index f009936..643127f 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -24,6 +24,71 @@
 
 #define to_amba_driver(d)	container_of(d, struct amba_driver, drv)
 
+static int amba_get_enable_pclk(struct amba_device *pcdev)
+{
+	int ret;
+
+	pcdev->pclk = clk_get(&pcdev->dev, "apb_pclk");
+	if (IS_ERR(pcdev->pclk))
+		return PTR_ERR(pcdev->pclk);
+
+	ret = clk_prepare_enable(pcdev->pclk);
+	if (ret)
+		clk_put(pcdev->pclk);
+
+	return ret;
+}
+
+static void amba_put_disable_pclk(struct amba_device *pcdev)
+{
+	clk_disable_unprepare(pcdev->pclk);
+	clk_put(pcdev->pclk);
+}
+
+static int amba_read_periphid(struct amba_device *dev)
+{
+	u32 size;
+	void __iomem *tmp;
+	int i, ret = 0;
+
+	/*
+	 * Dynamically calculate the size of the resource
+	 * and use this for iomap
+	 */
+	size = resource_size(&dev->res);
+	tmp = ioremap(dev->res.start, size);
+	if (!tmp)
+		return -ENOMEM;
+
+	ret = amba_get_enable_pclk(dev);
+	if (ret == 0) {
+		u32 pid, cid;
+
+		/*
+		 * Read pid and cid based on size of resource
+		 * they are located at end of region
+		 */
+		for (pid = 0, i = 0; i < 4; i++)
+			pid |= (readl(tmp + size - 0x20 + 4 * i) & 255) <<
+				(i * 8);
+		for (cid = 0, i = 0; i < 4; i++)
+			cid |= (readl(tmp + size - 0x10 + 4 * i) & 255) <<
+				(i * 8);
+
+		amba_put_disable_pclk(dev);
+
+		if (cid == AMBA_CID || cid == CORESIGHT_CID)
+			dev->periphid = pid;
+
+		if (!dev->periphid)
+			ret = -ENODEV;
+	}
+
+	iounmap(tmp);
+
+	return ret;
+}
+
 static const struct amba_id *
 amba_lookup(const struct amba_id *table, struct amba_device *dev)
 {
@@ -43,11 +108,19 @@ static int amba_match(struct device *dev, struct device_driver *drv)
 {
 	struct amba_device *pcdev = to_amba_device(dev);
 	struct amba_driver *pcdrv = to_amba_driver(drv);
+	int ret;
 
 	/* When driver_override is set, only bind to the matching driver */
 	if (pcdev->driver_override)
 		return !strcmp(pcdev->driver_override, drv->name);
 
+	/* Do plug-n-play if no hard-coded primecell ID has been provided */
+	if (!pcdev->periphid) {
+		ret = amba_read_periphid(pcdev);
+		if (ret)
+			return ret;
+	}
+
 	return amba_lookup(pcdrv->id_table, pcdev) != NULL;
 }
 
@@ -204,27 +277,6 @@ static int __init amba_init(void)
 
 postcore_initcall(amba_init);
 
-static int amba_get_enable_pclk(struct amba_device *pcdev)
-{
-	int ret;
-
-	pcdev->pclk = clk_get(&pcdev->dev, "apb_pclk");
-	if (IS_ERR(pcdev->pclk))
-		return PTR_ERR(pcdev->pclk);
-
-	ret = clk_prepare_enable(pcdev->pclk);
-	if (ret)
-		clk_put(pcdev->pclk);
-
-	return ret;
-}
-
-static void amba_put_disable_pclk(struct amba_device *pcdev)
-{
-	clk_disable_unprepare(pcdev->pclk);
-	clk_put(pcdev->pclk);
-}
-
 /*
  * These are the device model conversion veneers; they convert the
  * device model structures to our more specific structures.
@@ -341,15 +393,12 @@ static void amba_device_release(struct device *dev)
  *	@dev: AMBA device allocated by amba_device_alloc
  *	@parent: resource parent for this devices resources
  *
- *	Claim the resource, and read the device cell ID if not already
- *	initialized.  Register the AMBA device with the Linux device
+ *	Claim the resource, and register the AMBA device with the Linux device
  *	manager.
  */
 int amba_device_add(struct amba_device *dev, struct resource *parent)
 {
-	u32 size;
-	void __iomem *tmp;
-	int i, ret;
+	int ret;
 
 	WARN_ON(dev->irq[0] == (unsigned int)-1);
 	WARN_ON(dev->irq[1] == (unsigned int)-1);
@@ -358,51 +407,6 @@ int amba_device_add(struct amba_device *dev, struct resource *parent)
 	if (ret)
 		goto err_out;
 
-	/* Hard-coded primecell ID instead of plug-n-play */
-	if (dev->periphid != 0)
-		goto skip_probe;
-
-	/*
-	 * Dynamically calculate the size of the resource
-	 * and use this for iomap
-	 */
-	size = resource_size(&dev->res);
-	tmp = ioremap(dev->res.start, size);
-	if (!tmp) {
-		ret = -ENOMEM;
-		goto err_release;
-	}
-
-	ret = amba_get_enable_pclk(dev);
-	if (ret == 0) {
-		u32 pid, cid;
-
-		/*
-		 * Read pid and cid based on size of resource
-		 * they are located at end of region
-		 */
-		for (pid = 0, i = 0; i < 4; i++)
-			pid |= (readl(tmp + size - 0x20 + 4 * i) & 255) <<
-				(i * 8);
-		for (cid = 0, i = 0; i < 4; i++)
-			cid |= (readl(tmp + size - 0x10 + 4 * i) & 255) <<
-				(i * 8);
-
-		amba_put_disable_pclk(dev);
-
-		if (cid == AMBA_CID || cid == CORESIGHT_CID)
-			dev->periphid = pid;
-
-		if (!dev->periphid)
-			ret = -ENODEV;
-	}
-
-	iounmap(tmp);
-
-	if (ret)
-		goto err_release;
-
- skip_probe:
 	ret = device_add(&dev->dev);
 	if (ret)
 		goto err_release;
-- 
1.9.2



From m.szyprowski at samsung.com  Wed Feb 10 02:47:27 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed, 10 Feb 2016 11:47:27 +0100
Subject: [PATCH v5 RESEND 2/5] ARM: sa1111: ensure no negative value gets
 returned on positive match
In-Reply-To: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
References: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455101250-11327-3-git-send-email-m.szyprowski@samsung.com>

This patch ensures that existing bus match callbacks don't return
negative values (which might be interpreted as potential errors in the
future) in case of positive match.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 arch/arm/common/sa1111.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/common/sa1111.c b/arch/arm/common/sa1111.c
index 3d22494..fb0a0a4 100644
--- a/arch/arm/common/sa1111.c
+++ b/arch/arm/common/sa1111.c
@@ -1290,7 +1290,7 @@ static int sa1111_match(struct device *_dev, struct device_driver *_drv)
 	struct sa1111_dev *dev = SA1111_DEV(_dev);
 	struct sa1111_driver *drv = SA1111_DRV(_drv);
 
-	return dev->devid & drv->devid;
+	return !!(dev->devid & drv->devid);
 }
 
 static int sa1111_bus_suspend(struct device *dev, pm_message_t state)
-- 
1.9.2



From m.szyprowski at samsung.com  Wed Feb 10 02:47:30 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed, 10 Feb 2016 11:47:30 +0100
Subject: [PATCH v5 RESEND 5/5] ARM: amba: Properly handle devices with power
 domains
In-Reply-To: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
References: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455101250-11327-6-git-send-email-m.szyprowski@samsung.com>

To read pid/cid registers, the probed device need to be properly turned on.
When it is inside a power domain, the bus code should ensure that the
given power domain is enabled before trying to access device's registers.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
Reviewed-by: Ulf Hansson <ulf.hansson at linaro.org>
---
 drivers/amba/bus.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 643127f..570033b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -60,6 +60,10 @@ static int amba_read_periphid(struct amba_device *dev)
 	if (!tmp)
 		return -ENOMEM;
 
+	ret = dev_pm_domain_attach(&dev->dev, true);
+	if (ret == -EPROBE_DEFER)
+		goto err_unmap;
+
 	ret = amba_get_enable_pclk(dev);
 	if (ret == 0) {
 		u32 pid, cid;
@@ -84,6 +88,8 @@ static int amba_read_periphid(struct amba_device *dev)
 			ret = -ENODEV;
 	}
 
+	dev_pm_domain_detach(&dev->dev, true);
+err_unmap:
 	iounmap(tmp);
 
 	return ret;
-- 
1.9.2



From m.szyprowski at samsung.com  Wed Feb 10 02:47:28 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed, 10 Feb 2016 11:47:28 +0100
Subject: [PATCH v5 RESEND 3/5] driver core: handle -EPROBE_DEFER from
 bus_type.match()
In-Reply-To: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
References: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455101250-11327-4-git-send-email-m.szyprowski@samsung.com>

From: Tomeu Vizoso <tomeu.vizoso at collabora.com>

Allow implementations of the match() callback in struct bus_type to
return errors and if it's -EPROBE_DEFER then queue the device for
deferred probing.

This is useful to buses such as AMBA in which devices are registered
before their matching information can be retrieved from the HW
(typically because a clock driver hasn't probed yet).

Signed-off-by: Tomeu Vizoso <tomeu.vizoso at collabora.com>
[changed if-else code structure, adjusted documentation to match the code,
extended comments]
Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
Reviewed-by: Ulf Hansson <ulf.hansson at linaro.org>
---
 Documentation/driver-model/porting.txt |  6 ++++--
 drivers/base/dd.c                      | 24 ++++++++++++++++++++++--
 include/linux/device.h                 |  7 +++++--
 3 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/Documentation/driver-model/porting.txt b/Documentation/driver-model/porting.txt
index 92d86f7..453053f 100644
--- a/Documentation/driver-model/porting.txt
+++ b/Documentation/driver-model/porting.txt
@@ -340,8 +340,10 @@ comparison:
 
   int (*match)(struct device * dev, struct device_driver * drv);
 
-match should return '1' if the driver supports the device, and '0'
-otherwise. 
+match should return positive value if the driver supports the device,
+and zero otherwise. It may also return error code (for example
+-EPROBE_DEFER) if determining that given driver supports the device is
+not possible.
 
 When a device is registered, the bus's list of drivers is iterated
 over. bus->match() is called for each one until a match is found. 
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 7399be7..7c3f1f1 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -544,6 +544,7 @@ static int __device_attach_driver(struct device_driver *drv, void *_data)
 	struct device_attach_data *data = _data;
 	struct device *dev = data->dev;
 	bool async_allowed;
+	int ret;
 
 	/*
 	 * Check if device has already been claimed. This may
@@ -554,8 +555,17 @@ static int __device_attach_driver(struct device_driver *drv, void *_data)
 	if (dev->driver)
 		return -EBUSY;
 
-	if (!driver_match_device(drv, dev))
+	ret = driver_match_device(drv, dev);
+	if (ret == 0) {
+		/* no match */
 		return 0;
+	} else if (ret == -EPROBE_DEFER) {
+		dev_dbg(dev, "Device match requests probe deferral\n");
+		driver_deferred_probe_add(dev);
+	} else if (ret < 0) {
+		dev_dbg(dev, "Bus failed to match device: %d", ret);
+		return ret;
+	} /* ret > 0 means positive match */
 
 	async_allowed = driver_allows_async_probing(drv);
 
@@ -675,6 +685,7 @@ void device_initial_probe(struct device *dev)
 static int __driver_attach(struct device *dev, void *data)
 {
 	struct device_driver *drv = data;
+	int ret;
 
 	/*
 	 * Lock device and try to bind to it. We drop the error
@@ -686,8 +697,17 @@ static int __driver_attach(struct device *dev, void *data)
 	 * is an error.
 	 */
 
-	if (!driver_match_device(drv, dev))
+	ret = driver_match_device(drv, dev);
+	if (ret == 0) {
+		/* no match */
 		return 0;
+	} else if (ret == -EPROBE_DEFER) {
+		dev_dbg(dev, "Device match requests probe deferral\n");
+		driver_deferred_probe_add(dev);
+	} else if (ret < 0) {
+		dev_dbg(dev, "Bus failed to match device: %d", ret);
+		return ret;
+	} /* ret > 0 means positive match */
 
 	if (dev->parent)	/* Needed for USB */
 		device_lock(dev->parent);
diff --git a/include/linux/device.h b/include/linux/device.h
index f627ba2..75a2cde 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -70,8 +70,11 @@ extern void bus_remove_file(struct bus_type *, struct bus_attribute *);
  * @dev_groups:	Default attributes of the devices on the bus.
  * @drv_groups: Default attributes of the device drivers on the bus.
  * @match:	Called, perhaps multiple times, whenever a new device or driver
- *		is added for this bus. It should return a nonzero value if the
- *		given device can be handled by the given driver.
+ *		is added for this bus. It should return a positive value if the
+ *		given device can be handled by the given driver and zero
+ *		otherwise. It may also return error code if determining that
+ *		the driver supports the device is not possible. In case of
+ *		-EPROBE_DEFER it will queue the device for deferred probing.
  * @uevent:	Called when a device is added, removed, or a few other things
  *		that generate uevents to add the environment variables.
  * @probe:	Called when a new device or driver add to this bus, and callback
-- 
1.9.2



From robin.murphy at arm.com  Wed Feb 10 02:49:31 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 10 Feb 2016 10:49:31 +0000
Subject: [PATCH v3 6/8] dmaengine: rcar-dmac: add iommu support for slave
 transfers
In-Reply-To: <1455065878-11906-7-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <1455065878-11906-7-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <56BB15BB.30806@arm.com>

On 10/02/16 00:57, Niklas S?derlund wrote:
> Enable slave transfers to devices behind IPMMU:s by mapping the slave
> addresses using the dma-mapping API.
>
> Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
> ---
>   drivers/dma/sh/rcar-dmac.c | 57 ++++++++++++++++++++++++++++++++++++++++++----
>   1 file changed, 52 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index 743873c..268407c 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -1106,21 +1106,68 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
>   	return desc;
>   }
>
> +static int rcar_dmac_set_slave_addr(struct dma_chan *chan,
> +				     struct rcar_dmac_chan_slave *slave,
> +				     phys_addr_t addr, size_t size)
> +{
> +	struct dma_attrs attrs;
> +	enum dma_data_direction dir;
> +
> +	init_dma_attrs(&attrs);
> +	dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &attrs);
> +	dma_set_attr(DMA_ATTR_SKIP_CPU_SYNC, &attrs);

Now that we have a way to deal with MMIO addresses properly, we don't 
need these any more.

Robin.

> +
> +	/*
> +	 * We can't know the direction at this time, see documentation for
> +	 * 'direction' in struct dma_slave_config.
> +	 */
> +	dir = DMA_BIDIRECTIONAL;
> +
> +	if (slave->xfer_size) {
> +		dma_unmap_resource(chan->device->dev, slave->slave_addr,
> +				slave->xfer_size, dir, &attrs);
> +		slave->slave_addr = 0;
> +		slave->xfer_size = 0;
> +	}
> +
> +	if (size) {
> +		slave->slave_addr = dma_map_resource(chan->device->dev, addr,
> +				size, dir, &attrs);
> +
> +		if (dma_mapping_error(chan->device->dev, slave->slave_addr)) {
> +			struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
> +
> +			dev_err(chan->device->dev,
> +					"chan%u: failed to map %zx@%pap",
> +					rchan->index, size, &addr);
> +			return -EIO;
> +		}
> +
> +		slave->xfer_size = size;
> +	}
> +
> +	return 0;
> +}
> +
>   static int rcar_dmac_device_config(struct dma_chan *chan,
>   				   struct dma_slave_config *cfg)
>   {
>   	struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
> +	int ret;
>
>   	/*
>   	 * We could lock this, but you shouldn't be configuring the
>   	 * channel, while using it...
>   	 */
> -	rchan->src.slave_addr = cfg->src_addr;
> -	rchan->dst.slave_addr = cfg->dst_addr;
> -	rchan->src.xfer_size = cfg->src_addr_width;
> -	rchan->dst.xfer_size = cfg->dst_addr_width;
>
> -	return 0;
> +	ret = rcar_dmac_set_slave_addr(chan, &rchan->src, cfg->src_addr,
> +			cfg->src_addr_width);
> +	if (ret)
> +		return ret;
> +
> +	ret = rcar_dmac_set_slave_addr(chan, &rchan->dst, cfg->dst_addr,
> +			cfg->dst_addr_width);
> +	return ret;
>   }
>
>   static int rcar_dmac_chan_terminate_all(struct dma_chan *chan)
>



From mark.rutland at arm.com  Wed Feb 10 02:54:54 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 10 Feb 2016 10:54:54 +0000
Subject: [PATCHv4 2/3] arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
In-Reply-To: <20160210103814.GC13577@e104818-lin.cambridge.arm.com>
References: <1454718288-31374-1-git-send-email-labbott@fedoraproject.org>
 <1454718288-31374-3-git-send-email-labbott@fedoraproject.org>
 <20160210103814.GC13577@e104818-lin.cambridge.arm.com>
Message-ID: <20160210105453.GB2632@leverpostej>

On Wed, Feb 10, 2016 at 10:38:14AM +0000, Catalin Marinas wrote:
> On Fri, Feb 05, 2016 at 04:24:47PM -0800, Laura Abbott wrote:
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -149,6 +149,19 @@ static void split_pud(pud_t *old_pud, pmd_t *pmd)
> >  	} while (pmd++, i++, i < PTRS_PER_PMD);
> >  }
> >  
> > +bool block_mappings_allowed(phys_addr_t (*pgtable_alloc)(void))
> > +{
> > +
> > +	/*
> > +	 * If debug_page_alloc is enabled we must map the linear map
> > +	 * using pages. However, other mappings created by
> > +	 * create_mapping_noalloc must use sections in some cases. Allow
> > +	 * sections to be used in those cases, where no pgtable_alloc
> > +	 * function is provided.
> > +	 */
> > +	return !pgtable_alloc || !debug_pagealloc_enabled();
> > +}
> 
> This breaks the build when CONFIG_DEBUG_PAGEALLOC is not enabled
> (defconfig) since debug_pagealloc_enabled() is not defined. A fix went
> in next/master as commit 0987684b855c
> ("mm-slab-clean-up-debug_pagealloc-processing-code-fix"). I need to
> track it down and merge it via the arm64 tree, otherwise I'll add some
> #ifdefs in this function.

In the cover for v2 [1],  it was mentioend that we needed a patch [2]
"mm: provide debug_pagealloc_enabled() without CONFIG_DEBUG_PAGEALLOC".
I assumed that was already queued via the mm tree.

> BTW, shouldn't the block_mappings_allowed() function be static?

That would make sense to me, yes.

Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/403439.html  
[2] http://article.gmane.org/gmane.linux.kernel.mm/1452


From jonathanh at nvidia.com  Wed Feb 10 02:57:11 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Wed, 10 Feb 2016 10:57:11 +0000
Subject: [PATCH V5 10/14] Documentation: DT: bindings: Add power domain
 info for NVIDIA PMC
In-Reply-To: <CAL_JsqLcoKW2znNNvM=sYLmZ6O6ZWqn7+aXspkXoONw6-O1ygg@mail.gmail.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-11-git-send-email-jonathanh@nvidia.com>
 <20160129160625.GA21918@rob-hp-laptop> <56B1DE40.7080403@nvidia.com>
 <CAL_JsqLcoKW2znNNvM=sYLmZ6O6ZWqn7+aXspkXoONw6-O1ygg@mail.gmail.com>
Message-ID: <56BB1787.4050801@nvidia.com>


On 03/02/16 15:48, Rob Herring wrote:
> On Wed, Feb 3, 2016 at 5:02 AM, Jon Hunter <jonathanh at nvidia.com> wrote:
>>
>> On 29/01/16 16:06, Rob Herring wrote:
>>> On Thu, Jan 28, 2016 at 04:33:48PM +0000, Jon Hunter wrote:
>>>> Add power-domain binding documentation for the NVIDIA PMC driver in
>>>> order to support generic power-domains.
>>>>
>>>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
>>>> ---
>>>>  .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      | 55 ++++++++++++++++++++++
>>>>  1 file changed, 55 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>>>> index 53aa5496c5cf..3c77373aa826 100644
>>>> --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>>>> @@ -1,5 +1,7 @@
>>>>  NVIDIA Tegra Power Management Controller (PMC)
>>>>
>>>> +== Power Management Controller Node ==
>>>> +
>>>>  The PMC block interacts with an external Power Management Unit. The PMC
>>>>  mostly controls the entry and exit of the system from different sleep
>>>>  modes. It provides power-gating controllers for SoC and CPU power-islands.
>>>> @@ -70,6 +72,10 @@ Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'
>>>>                       Defaults to 0. Valid values are described in section 12.5.2
>>>>                       "Pinmux Support" of the Tegra4 Technical Reference Manual.
>>>>
>>>> +Optional nodes:
>>>> +- powergates : This node contains a hierarchy of power domain nodes, which
>>>> +           should match the powergates on the Tegra SoC.
>>>> +
>>>>  Example:
>>>>
>>>>  / SoC dts including file
>>>> @@ -115,3 +121,52 @@ pmc at 7000f400 {
>>>>      };
>>>>      ...
>>>>  };
>>>> +
>>>> +
>>>> +== PM Domain Nodes ==
>>>> +
>>>> +Each of the PM domain nodes represents a power-domain on the Tegra SoC
>>>> +that can be power-gated by the PMC and should be named appropriately.
>>>> +
>>>> +Required properties:
>>>> +  - clocks: Must contain an entry for each clock required by the PMC for
>>>> +    controlling a power-gate. See ../clocks/clock-bindings.txt for details.
>>>> +  - resets: Must contain an entry for each reset required by the PMC for
>>>> +    controlling a power-gate. See ../reset/reset.txt for details.
>>>> +  - nvidia,powergate: Integer cell that contains an identifier for the PMC
>>>> +    power-gate that is associated with the power-domain. Please refer to
>>>> +    the Tegra TRM for more details.
>>>
>>> Why not make this value be the power-domain cell for consumers and the
>>> pmc be the phandle.
>>
>> Is there anything wrong with using a label for the consumers? Seems
>> simpler, if you can just say ...
>>
>>         adma: adma at 702e2000 {
>>                 ...
>>                 power-domains = <&pd_audio>;
>>                 ...
>>         };
> 
> Only that is a bit unusual. It would only really matter if we had some
> common parsing that we wanted to share. I'd look at other examples and
> try to align. If there's no clear pattern, then it is fine.

So I have been having a look at this and it appears to be mixed across
the various SoCs. It seems that those SoCs that define the generic PM
domains statically in the machine/soc code use a phandle plus a argument
to identify the power domain. However, for those that describe the
power-domain in the DT (listing clocks, resets, etc), they just use a
phandle to the power-domain itself (like I have above). It looks like if
you are describing the power domain in DT, then it is much simplier to
do this.

Given that I wish to keep the description of the power-domain in DT, it
is much easier to stick with the same conventions that the other SoCs
are using.

Cheers
Jon


From linus.walleij at linaro.org  Wed Feb 10 02:58:46 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Feb 2016 11:58:46 +0100
Subject: [PATCH v5 1/3] gpio: xgene: Enable X-Gene standby GPIO as
 interrupt controller
In-Reply-To: <1454041735-8434-2-git-send-email-qnguyen@apm.com>
References: <1454041735-8434-1-git-send-email-qnguyen@apm.com>
 <1454041735-8434-2-git-send-email-qnguyen@apm.com>
Message-ID: <CACRpkdZXFVgtQfMM_r+xxceiAuiUDsxH-XGBOpEA9Am0BF+gRQ@mail.gmail.com>

On Fri, Jan 29, 2016 at 5:28 AM, Quan Nguyen <qnguyen at apm.com> wrote:

> Enable X-Gene standby GPIO controller as interrupt controller to provide
> its own resources. This avoids ambiguity where GIC interrupt resource is
> use as X-Gene standby GPIO interrupt resource in user driver.
>
> Signed-off-by: Y Vo <yvo at apm.com>
> Signed-off-by: Quan Nguyen <qnguyen at apm.com>

I want Marc's ACK on this before I merge it.

But it is looking way more acceptable than earlier incarnations! :)

> +       /* Propagate IRQ type setting to parent */
> +       if (type & IRQ_TYPE_EDGE_BOTH)
> +               return irq_chip_set_type_parent(d, IRQ_TYPE_EDGE_RISING);
> +       else
> +               return irq_chip_set_type_parent(d, IRQ_TYPE_LEVEL_HIGH);

This makes it look much more solid, nice.

> +static void xgene_gpio_sb_irq_shutdown(struct irq_data *d)
> +{
> +       struct xgene_gpio_sb *priv = irq_data_get_irq_chip_data(d);
> +
> +       gpiochip_unlock_as_irq(&priv->gc, HWIRQ_TO_GPIO(priv, d->hwirq));

Oh really. Well.

> +       if (is_of_node(domain->parent->fwnode)) {
> +               parent_fwspec.fwnode = domain->parent->fwnode;
> +               parent_fwspec.param_count = 3;
> +               parent_fwspec.param[0] = 0;/* SPI */
> +               /* Skip SGIs and PPIs*/
> +               parent_fwspec.param[1] = hwirq + priv->parent_irq_base - 32;
> +               parent_fwspec.param[2] = fwspec->param[1];
> +       } else if (is_fwnode_irqchip(domain->parent->fwnode)) {
> +               parent_fwspec.fwnode = domain->parent->fwnode;
> +               parent_fwspec.param_count = 2;
> +               parent_fwspec.param[0] = hwirq + priv->parent_irq_base;
> +               parent_fwspec.param[1] = fwspec->param[1];
> +       } else
> +               return -EINVAL;

This kind of stuff hardcodes knowledge of the GIC into this controller,
like that the SGI+PPI occupy the first 32 hwIRQs. But maybe there is
no better way to do it?

Yours,
Linus Walleij


From catalin.marinas at arm.com  Wed Feb 10 03:02:12 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 10 Feb 2016 11:02:12 +0000
Subject: [PATCHv4 2/3] arm64: Add support for ARCH_SUPPORTS_DEBUG_PAGEALLOC
In-Reply-To: <20160210103814.GC13577@e104818-lin.cambridge.arm.com>
References: <1454718288-31374-1-git-send-email-labbott@fedoraproject.org>
 <1454718288-31374-3-git-send-email-labbott@fedoraproject.org>
 <20160210103814.GC13577@e104818-lin.cambridge.arm.com>
Message-ID: <20160210110212.GE13577@e104818-lin.cambridge.arm.com>

On Wed, Feb 10, 2016 at 10:38:14AM +0000, Catalin Marinas wrote:
> On Fri, Feb 05, 2016 at 04:24:47PM -0800, Laura Abbott wrote:
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -149,6 +149,19 @@ static void split_pud(pud_t *old_pud, pmd_t *pmd)
> >  	} while (pmd++, i++, i < PTRS_PER_PMD);
> >  }
> >  
> > +bool block_mappings_allowed(phys_addr_t (*pgtable_alloc)(void))
> > +{
> > +
> > +	/*
> > +	 * If debug_page_alloc is enabled we must map the linear map
> > +	 * using pages. However, other mappings created by
> > +	 * create_mapping_noalloc must use sections in some cases. Allow
> > +	 * sections to be used in those cases, where no pgtable_alloc
> > +	 * function is provided.
> > +	 */
> > +	return !pgtable_alloc || !debug_pagealloc_enabled();
> > +}
> 
> This breaks the build when CONFIG_DEBUG_PAGEALLOC is not enabled
> (defconfig) since debug_pagealloc_enabled() is not defined. A fix went
> in next/master as commit 0987684b855c
> ("mm-slab-clean-up-debug_pagealloc-processing-code-fix"). I need to
> track it down and merge it via the arm64 tree, otherwise I'll add some
> #ifdefs in this function.

It seems that there are other patches in the mm tree requiring this
change. I'll fix it locally (#ifdefs) and revert the change after -rc1.

-- 
Catalin


From mark.rutland at arm.com  Wed Feb 10 03:12:34 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 10 Feb 2016 11:12:34 +0000
Subject: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
 HiSilicon SoCs Host Controllers
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1591@lhreml503-mbs>
References: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
 <1455039260-6040-4-git-send-email-gabriele.paoloni@huawei.com>
 <20160209182429.GD4348@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1591@lhreml503-mbs>
Message-ID: <20160210111234.GC2632@leverpostej>

On Wed, Feb 10, 2016 at 09:52:36AM +0000, Gabriele Paoloni wrote:
> Hi Mark
> 
> > On Tue, Feb 09, 2016 at 05:34:20PM +0000, Gabriele Paoloni wrote:
> > > From: gabriele paoloni <gabriele.paoloni at huawei.com>
> > > +/*
> > > + * Retrieve rc_dbi base and size from _DSD
> > > + * Name (_DSD, Package () {
> > > + *	ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > > + *	Package () {
> > > + *	Package () {"rc-dbi", Package () { 0x0, 0xb0080000, 0x0, 0x10000
> > }},
> > > + *	}
> > > + *	})
> > > + */
> > 
> > As above, this does not look right. ACPI has standard mechanisms for
> > describing addresses. Making something up like this is not a good idea.
>  
> I am quite new to ACPI, may I ask you to explain a bit? 

ACPI has standard mechanisms for describing certain resources, and these
should not be described in _DSD. Memory or IO address regions are such
resources (in _CRS, IIRC), and should not be described in _DSD.

Thanks,
Mark.


From srinivas.kandagatla at linaro.org  Wed Feb 10 03:36:04 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Wed, 10 Feb 2016 11:36:04 +0000
Subject: [PATCH v2 0/8] arm64: dts: apq8016 dt patches (Set2).
Message-ID: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>

Hi Andy, 

Here are few more dt patches (set2) which enables usb and lpass,
with some fixes. I have tested these patches with few changes
to defconfig on DB410C + a usb phy fix.

Thanks,
srini

Changes since v1:
 - moved usb usb2513 and usb_id nodes out of soc
 as suggested by Stephen Boyd.
 - fixed lpass node name, spotted by Stephen Boyd.
 - added new patch to enable bam dma
 - added a fix from Ivan on led mpp pins.


Ivan T. Ivanov (1):
  arm64: dts: qcom: Fix MPP's function used for LED control

Srinivas Kandagatla (7):
  arm64: dts: qcom: add manual pullup setting to otg.
  arm64: dts: qcom: apq8016-sbc: add usb support
  arm64: dts: qcom: add audio pinctrls
  arm64: dts: qcom: add lpass node
  arm64: dts: qcom: apq8016-sbc: enable lpass on DB410c
  arm64: dts: qcom: fix usb digital voltage levels
  arm64: dts: qcom: apq8016-sbc: enable bam dma node.

 .../arm64/boot/dts/qcom/apq8016-sbc-pmic-pins.dtsi |   2 +-
 arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi |  15 ++
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi          |  43 ++++
 arch/arm64/boot/dts/qcom/msm8916-pins.dtsi         | 216 +++++++++++++++++++++
 arch/arm64/boot/dts/qcom/msm8916.dtsi              |  29 ++-
 5 files changed, 303 insertions(+), 2 deletions(-)

-- 
1.9.1



From srinivas.kandagatla at linaro.org  Wed Feb 10 03:36:37 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Wed, 10 Feb 2016 11:36:37 +0000
Subject: [PATCH v2 1/8] arm64: dts: qcom: add manual pullup setting to otg.
In-Reply-To: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1455104197-10516-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds manual pull up setting for usb otg indicating that the
vbus is vbus is not routed to USB controller/phy therefore enables
pull-up explicitly before starting controller.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index ff7ca44..c1592d4 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -399,6 +399,7 @@
 			qcom,phy-init-sequence = <0x44 0x6B 0x24 0x13>;
 			dr_mode = "peripheral";
 			qcom,otg-control = <2>; // PMIC
+			qcom,manual-pullup;
 
 			clocks = <&gcc GCC_USB_HS_AHB_CLK>,
 				 <&gcc GCC_USB_HS_SYSTEM_CLK>,
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Wed Feb 10 03:36:42 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Wed, 10 Feb 2016 11:36:42 +0000
Subject: [PATCH v2 2/8] arm64: dts: qcom: apq8016-sbc: add usb support
In-Reply-To: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1455104202-10560-1-git-send-email-srinivas.kandagatla@linaro.org>

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi | 15 ++++++++++
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi          | 35 ++++++++++++++++++++++
 2 files changed, 50 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
index cbeee0b..4a79dd9 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
@@ -10,4 +10,19 @@
 			output-low;
 		};
 	};
+
+	usb_id_default: usb_id_default {
+		pinmux {
+			function = "gpio";
+			pins = "gpio121";
+		};
+
+		pinconf {
+			pins = "gpio121";
+			function = "gpio";
+			drive-strength = <8>;
+			input-enable;
+			bias-pull-up;
+		};
+	};
 };
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 9a6c595..23ba95a 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -151,6 +151,41 @@
 			cd-gpios = <&msmgpio 38 0x1>;
 			status = "okay";
 		};
+
+		usb at 78d9000 {
+			extcon = <&usb_id>, <&usb_id>;
+			status = "okay";
+		};
+
+		ehci at 78d9000 {
+			status = "okay";
+		};
+
+		phy at 78d9000 {
+			v1p8-supply = <&pm8916_l7>;
+			v3p3-supply = <&pm8916_l13>;
+			vddcx-supply = <&pm8916_s1>;
+			extcon = <&usb_id>, <&usb_id>;
+			dr_mode = "otg";
+			status = "okay";
+			switch-gpio = <&pm8916_gpios 4 GPIO_ACTIVE_HIGH>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&usb_sw_sel_pm>;
+		};
+	};
+
+	usb2513 {
+		compatible = "smsc,usb3503";
+		reset-gpios = <&pm8916_gpios 3 GPIO_ACTIVE_LOW>;
+		initial-mode = <1>;
+	};
+
+	usb_id: usb-id {
+		interrupt-parent = <&msmgpio>;
+		compatible = "linux,extcon-usb-gpio";
+		id-gpio = <&msmgpio 121 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_id_default>;
 	};
 };
 
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Wed Feb 10 03:36:48 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Wed, 10 Feb 2016 11:36:48 +0000
Subject: [PATCH v2 3/8] arm64: dts: qcom: add audio pinctrls
In-Reply-To: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1455104208-10602-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds pinctrls required for digital and analog audio via lpass.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 216 +++++++++++++++++++++++++++++
 1 file changed, 216 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index 8d05005..e9ea5ca 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -504,4 +504,220 @@
 			};
 		};
 	};
+
+	ext-codec-lines {
+		ext_codec_lines_act: lines_on {
+			pinmux {
+				function = "gpio";
+				pins = "gpio67";
+			};
+			pinconf {
+				pins = "gpio67";
+				drive-strength = <8>;
+				bias-disable;
+				output-high;
+			};
+		};
+		ext_codec_lines_sus: lines_off {
+			pinmux {
+				function = "gpio";
+				pins = "gpio67";
+			};
+			pinconf {
+				pins = "gpio67";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	cdc-pdm-lines {
+		cdc_pdm_lines_act: pdm_lines_on {
+			pinmux {
+				function = "cdc_pdm0";
+				pins = "gpio63", "gpio64", "gpio65", "gpio66",
+				       "gpio67", "gpio68";
+			};
+			pinconf {
+				pins = "gpio63", "gpio64", "gpio65", "gpio66",
+				       "gpio67", "gpio68";
+				drive-strength = <8>;
+				bias-pull-none;
+			};
+		};
+		cdc_pdm_lines_sus: pdm_lines_off {
+			pinmux {
+				function = "cdc_pdm0";
+				pins = "gpio63", "gpio64", "gpio65", "gpio66",
+				       "gpio67", "gpio68";
+			};
+			pinconf {
+				pins = "gpio63", "gpio64", "gpio65", "gpio66",
+				       "gpio67", "gpio68";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	ext-pri-tlmm-lines {
+		ext_pri_tlmm_lines_act: ext_pa_on {
+			pinmux {
+				function = "pri_mi2s";
+				pins = "gpio113", "gpio114", "gpio115",
+				       "gpio116";
+			};
+			pinconf {
+				pins = "gpio113", "gpio114", "gpio115",
+				       "gpio116";
+				drive-strength = <8>;
+				bias-pull-none;
+			};
+		};
+
+		ext_pri_tlmm_lines_sus: ext_pa_off {
+			pinmux {
+				function = "pri_mi2s";
+				pins = "gpio113", "gpio114", "gpio115",
+				       "gpio116";
+			};
+			pinconf {
+				pins = "gpio113", "gpio114", "gpio115",
+				       "gpio116";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	ext-pri-ws-line {
+		ext_pri_ws_act: ext_pa_on {
+			pinmux {
+				function = "pri_mi2s_ws";
+				pins = "gpio110";
+			};
+			pinconf {
+				pins = "gpio110";
+				drive-strength = <8>;
+				bias-pull-none;
+			};
+		};
+
+		ext_pri_ws_sus: ext_pa_off {
+			pinmux {
+				function = "pri_mi2s_ws";
+				pins = "gpio110";
+			};
+			pinconf {
+				pins = "gpio110";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	ext-mclk-tlmm-lines {
+		ext_mclk_tlmm_lines_act: mclk_lines_on {
+			pinmux {
+				function = "pri_mi2s";
+				pins = "gpio116";
+			};
+			pinconf {
+				pins = "gpio116";
+				drive-strength = <8>;
+				bias-pull-none;
+			};
+		};
+		ext_mclk_tlmm_lines_sus: mclk_lines_off {
+			pinmux {
+				function = "pri_mi2s";
+				pins = "gpio116";
+			};
+			pinconf {
+				pins = "gpio116";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	/* secondary Mi2S */
+	ext-sec-tlmm-lines {
+		ext_sec_tlmm_lines_act: tlmm_lines_on {
+			pinmux {
+				function = "sec_mi2s";
+				pins = "gpio112", "gpio117", "gpio118",
+				       "gpio119";
+			};
+			pinconf {
+				pins = "gpio112", "gpio117", "gpio118",
+					"gpio119";
+				drive-strength = <8>;
+				bias-pull-none;
+			};
+		};
+		ext_sec_tlmm_lines_sus: tlmm_lines_off {
+			pinmux {
+				function = "sec_mi2s";
+				pins = "gpio112", "gpio117", "gpio118",
+				       "gpio119";
+			};
+			pinconf {
+				pins = "gpio112", "gpio117", "gpio118",
+					"gpio119";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	cdc-dmic-lines {
+		cdc_dmic_lines_act: dmic_lines_on {
+			pinmux_dmic0_clk {
+				function = "dmic0_clk";
+				pins = "gpio0";
+			};
+			pinmux_dmic0_data {
+				function = "dmic0_data";
+				pins = "gpio1";
+			};
+			pinconf {
+				pins = "gpio0", "gpio1";
+				drive-strength = <8>;
+			};
+		};
+		cdc_dmic_lines_sus: dmic_lines_off {
+			pinconf {
+				pins = "gpio0", "gpio1";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	cross-conn-det {
+		cross_conn_det_act: lines_on {
+			pinmux {
+				function = "gpio";
+				pins = "gpio120";
+			};
+			pinconf {
+				pins = "gpio120";
+				drive-strength = <8>;
+				output-low;
+				bias-pull-down;
+			};
+		};
+		cross_conn_det_sus: lines_off {
+			pinmux {
+				function = "gpio";
+				pins = "gpio120";
+			};
+			pinconf {
+				pins = "gpio120";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
 };
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Wed Feb 10 03:36:55 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Wed, 10 Feb 2016 11:36:55 +0000
Subject: [PATCH v2 4/8] arm64: dts: qcom: add lpass node
In-Reply-To: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1455104215-10645-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds lpass node to the SOC.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index c1592d4..a6fddce 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -343,6 +343,32 @@
 			status = "disabled";
 		};
 
+		lpass: lpass at 07708000 {
+			status = "disabled";
+			compatible = "qcom,lpass-cpu-apq8016";
+			clocks = <&gcc GCC_ULTAUDIO_AHBFABRIC_IXFABRIC_CLK>,
+				 <&gcc GCC_ULTAUDIO_PCNOC_MPORT_CLK>,
+				 <&gcc GCC_ULTAUDIO_PCNOC_SWAY_CLK>,
+				 <&gcc GCC_ULTAUDIO_LPAIF_PRI_I2S_CLK>,
+				 <&gcc GCC_ULTAUDIO_LPAIF_SEC_I2S_CLK>,
+				 <&gcc GCC_ULTAUDIO_LPAIF_SEC_I2S_CLK>,
+				 <&gcc GCC_ULTAUDIO_LPAIF_AUX_I2S_CLK>;
+
+			clock-names = "ahbix-clk",
+					"pcnoc-mport-clk",
+					"pcnoc-sway-clk",
+					"mi2s-bit-clk0",
+					"mi2s-bit-clk1",
+					"mi2s-bit-clk2",
+					"mi2s-bit-clk3";
+			#sound-dai-cells = <1>;
+
+			interrupts = <0 160 0>;
+			interrupt-names = "lpass-irq-lpaif";
+			reg = <0x07708000 0x10000>;
+			reg-names = "lpass-lpaif";
+		};
+
 		sdhc_1: sdhci at 07824000 {
 			compatible = "qcom,sdhci-msm-v4";
 			reg = <0x07824900 0x11c>, <0x07824000 0x800>;
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Wed Feb 10 03:37:03 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Wed, 10 Feb 2016 11:37:03 +0000
Subject: [PATCH v2 5/8] arm64: dts: qcom: apq8016-sbc: enable lpass on DB410c
In-Reply-To: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1455104223-10687-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch enables the lpass on DB410C. LPASS is used as cpu dai for
both analog and digital audio.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 23ba95a..8ab87e7 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -172,6 +172,10 @@
 			pinctrl-names = "default";
 			pinctrl-0 = <&usb_sw_sel_pm>;
 		};
+
+		lpass at 07708000 {
+			status = "okay";
+		};
 	};
 
 	usb2513 {
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Wed Feb 10 03:37:10 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Wed, 10 Feb 2016 11:37:10 +0000
Subject: [PATCH v2 6/8] arm64: dts: qcom: fix usb digital voltage levels
In-Reply-To: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1455104230-10729-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch updates the digital voltage levels from corner values to
microvolts as we are going to use s1 regulator directly for vddcx
instead of s1_corner.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index a6fddce..2f40fdd 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -421,7 +421,7 @@
 			interrupts = <GIC_SPI 134 IRQ_TYPE_EDGE_BOTH>,
 				     <GIC_SPI 140 IRQ_TYPE_EDGE_RISING>;
 
-			qcom,vdd-levels = <1 5 7>;
+			qcom,vdd-levels = <500000 1000000 1320000>;
 			qcom,phy-init-sequence = <0x44 0x6B 0x24 0x13>;
 			dr_mode = "peripheral";
 			qcom,otg-control = <2>; // PMIC
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Wed Feb 10 03:37:17 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Wed, 10 Feb 2016 11:37:17 +0000
Subject: [PATCH v2 7/8] arm64: dts: qcom: apq8016-sbc: enable bam dma node.
In-Reply-To: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1455104237-10771-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch enables bam dma node, dma is used for both tx and rx on spi
and on high speed serial.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 8ab87e7..a1a39d0 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -33,6 +33,10 @@
 	};
 
 	soc {
+		dma at 7884000 {
+			status = "okay";
+		};
+
 		serial at 78af000 {
 			label = "LS-UART0";
 			status = "okay";
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Wed Feb 10 03:37:24 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Wed, 10 Feb 2016 11:37:24 +0000
Subject: [PATCH v2 8/8] arm64: dts: qcom: Fix MPP's function used for LED
 control
In-Reply-To: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1455104244-10813-1-git-send-email-srinivas.kandagatla@linaro.org>

From: "Ivan T. Ivanov" <ivan.ivanov at linaro.org>

The qcom-spmi-mpp driver is now using string "digital" to denote
old "normal" functionality. Update DTS file.
Also update the powersource.

Signed-off-by: Ivan T. Ivanov <ivan.ivanov at linaro.org>
---
 arch/arm64/boot/dts/qcom/apq8016-sbc-pmic-pins.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc-pmic-pins.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc-pmic-pins.dtsi
index e03c11d..f881437 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc-pmic-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc-pmic-pins.dtsi
@@ -33,7 +33,7 @@
 	pm8916_mpps_leds: pm8916_mpps_leds {
 		pinconf {
 			pins = "mpp2", "mpp3";
-			function = PMIC_GPIO_FUNC_NORMAL;
+			function = "digital";
 			output-low;
 		};
 	};
-- 
1.9.1



From marc.zyngier at arm.com  Wed Feb 10 03:46:03 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 11:46:03 +0000
Subject: [PATCH V3 08/10] irqchip, gicv3, its: Probe ITS in the ACPI way.
In-Reply-To: <1453209083-3358-9-git-send-email-tn@semihalf.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
 <1453209083-3358-9-git-send-email-tn@semihalf.com>
Message-ID: <56BB22FB.5060609@arm.com>

On 19/01/16 13:11, Tomasz Nowicki wrote:
> Since we prepared ITS for being initialized different that via DT,
> it is now possible to parse MADT and pass mandatory info to
> firmware-agnostic ITS init call.
> 
> Note that we are using here IORT lib to keep track of allocated
> domain handler which will be used to build PCI MSI domain on top
> in the later patches.
> 
> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
> Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
> ---
>  drivers/irqchip/irq-gic-v3-its.c | 57 +++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 56 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index fecb7a6..42f378a 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -15,10 +15,13 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <linux/acpi.h>
>  #include <linux/bitmap.h>
>  #include <linux/cpu.h>
>  #include <linux/delay.h>
>  #include <linux/interrupt.h>
> +#include <linux/irqdomain.h>
> +#include <linux/iort.h>
>  #include <linux/log2.h>
>  #include <linux/mm.h>
>  #include <linux/msi.h>
> @@ -1272,6 +1275,11 @@ static int its_irq_gic_domain_alloc(struct irq_domain *domain,
>  		fwspec.param[0] = GIC_IRQ_TYPE_LPI;
>  		fwspec.param[1] = hwirq;
>  		fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
> +	} else if (is_fwnode_irqchip(domain->parent->fwnode)) {
> +		fwspec.fwnode = domain->parent->fwnode;
> +		fwspec.param_count = 2;
> +		fwspec.param[0] = hwirq;
> +		fwspec.param[1] = IRQ_TYPE_EDGE_RISING;
>  	} else {
>  		return -EINVAL;
>  	}
> @@ -1594,6 +1602,52 @@ int its_cpu_init(void)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_ACPI
> +
> +#define ACPI_GICV3_ITS_MEM_SIZE (2 * SZ_64K)
> +
> +static struct irq_domain *its_parent __initdata;
> +
> +static int __init
> +gic_acpi_parse_madt_its(struct acpi_subtable_header *header,
> +			const unsigned long end)
> +{
> +	struct acpi_madt_generic_translator *its_entry;
> +	struct fwnode_handle *domain_handle;
> +	int err;
> +
> +	its_entry = (struct acpi_madt_generic_translator *)header;
> +	domain_handle = irq_domain_alloc_fwnode((void *)its_entry->base_address);
> +	if (!domain_handle) {
> +		pr_err("Unable to allocate GICv2m domain token\n");

-ECOPYPASTE.

> +		return -ENOMEM;
> +	}
> +
> +	/* ITS works as msi controller in ACPI case */
> +	err = its_probe_one(its_entry->base_address, ACPI_GICV3_ITS_MEM_SIZE,
> +			    its_parent, true, domain_handle);
> +	if (err) {
> +		irq_domain_free_fwnode(domain_handle);
> +		return err;
> +	}
> +	iort_register_domain_token(its_entry->translation_id, domain_handle);

And what if this fails?

> +	return 0;
> +}
> +
> +void __init its_acpi_probe(struct irq_domain *parent_domain)
> +{
> +	int count;
> +
> +	its_parent = parent_domain;
> +	count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
> +				      gic_acpi_parse_madt_its, 0);
> +	if (count <= 0)
> +		pr_info("No valid GIC ITS entries exist\n");
> +}
> +#else
> +static inline void __init its_acpi_probe(struct irq_domain *parent_domain) { }
> +#endif
> +
>  static struct of_device_id its_device_id[] = {
>  	{	.compatible	= "arm,gic-v3-its",	},
>  	{},
> @@ -1610,7 +1664,8 @@ int __init its_init(struct fwnode_handle *handle, struct rdists *rdists,
>  		     np = of_find_matching_node(np, its_device_id)) {
>  			its_of_probe(np, parent_domain);
>  		}
> -	}
> +	} else
> +		its_acpi_probe(parent_domain);

Missing braces.

>  
>  	if (list_empty(&its_nodes)) {
>  		pr_warn("ITS: No ITS available, not enabling LPIs\n");
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From james.morse at arm.com  Wed Feb 10 03:52:31 2016
From: james.morse at arm.com (James Morse)
Date: Wed, 10 Feb 2016 11:52:31 +0000
Subject: [PATCH] arm64: use raw_smp_processor_id in stack backtrace dump
In-Reply-To: <20160210102939.GD1052@arm.com>
References: <1455053182-31404-1-git-send-email-yang.shi@linaro.org>
 <20160210102939.GD1052@arm.com>
Message-ID: <56BB247F.6040202@arm.com>

On 10/02/16 10:29, Will Deacon wrote:
> On Tue, Feb 09, 2016 at 01:26:22PM -0800, Yang Shi wrote:
>> dump_backtrace may be called in kthread context, which is not bound to a single
>> cpu, i.e. khungtaskd, then calling smp_processor_id may trigger the below bug
>> report:
> 
> If we're preemptible here, it means that our irq_stack_ptr is potentially
> bogus. Whilst this isn't an issue for kthreads, it does feel like we
> could make this slightly more robust in the face of potential frame
> corruption. Maybe just zero the IRQ stack pointer if we're in preemptible
> context?

Switching between stacks is only valid if we are tracing ourselves while on the
irq_stack, we should probably prevent it for other tasks too.

Something like (untested):
---------------------
if (tsk == current && in_atomic())
	irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
else
	irq_stack_ptr = 0;
---------------------

This would work when we trace ourselves while on the irq_stack, but break*
tracing a running task on a remote cpu (khungtaskd doesn't do this).

The same fix would apply to unwind_frame(), we have 'tsk' in both functions.

Thoughts?


James


* If this were to ever happen, we would fail to switch to the original stack if
  tracing a remote irq stack, and print the wrong exception args. I'm not aware
  of any users of this, (panic() sends an IPI).


From robin.murphy at arm.com  Wed Feb 10 03:58:15 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 10 Feb 2016 11:58:15 +0000
Subject: [PATCH 4/4] iommu/arm-smmu: Use per-context TLB sync as
 appropriate
In-Reply-To: <20160209141508.GO22874@arm.com>
References: <cover.1453830752.git.robin.murphy@arm.com>
 <fc2ede950aea2e84a0b7cf93e4cd605f0cbdf3c3.1453830752.git.robin.murphy@arm.com>
 <20160209141508.GO22874@arm.com>
Message-ID: <56BB25D7.6070306@arm.com>

On 09/02/16 14:15, Will Deacon wrote:
> On Tue, Jan 26, 2016 at 06:06:37PM +0000, Robin Murphy wrote:
>> TLB synchronisation is a mighty big hammmer to bring down on the
>> transaction stream, typically stalling all in-flight transactions until
>> the sync completes. Since in most cases (except at stage 2 on SMMUv1)
>> a per-context sync operation is available, prefer that over the global
>> operation when performing TLB maintenance for a single domain, to avoid
>> unecessarily disrupting ongoing traffic in other contexts.
>>
>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>> ---
>>   drivers/iommu/arm-smmu.c | 32 ++++++++++++++++++++++++--------
>>   1 file changed, 24 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 18e0e10..bf1895c 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -219,6 +219,8 @@
>>   #define ARM_SMMU_CB_S1_TLBIVAL		0x620
>>   #define ARM_SMMU_CB_S2_TLBIIPAS2	0x630
>>   #define ARM_SMMU_CB_S2_TLBIIPAS2L	0x638
>> +#define ARM_SMMU_CB_TLBSYNC		0x7f0
>> +#define ARM_SMMU_CB_TLBSTATUS		0x7f4
>>   #define ARM_SMMU_CB_ATS1PR		0x800
>>   #define ARM_SMMU_CB_ATSR		0x8f0
>>
>> @@ -546,14 +548,22 @@ static void __arm_smmu_free_bitmap(unsigned long *map, int idx)
>>   }
>>
>>   /* Wait for any pending TLB invalidations to complete */
>> -static void __arm_smmu_tlb_sync(struct arm_smmu_device *smmu)
>> +static void __arm_smmu_tlb_sync(struct arm_smmu_device *smmu, int cbndx)
>>   {
>>   	int count = 0;
>> -	void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
>> +	void __iomem *base, __iomem *status;
>>
>> -	writel_relaxed(0, gr0_base + ARM_SMMU_GR0_sTLBGSYNC);
>> -	while (readl_relaxed(gr0_base + ARM_SMMU_GR0_sTLBGSTATUS)
>> -	       & sTLBGSTATUS_GSACTIVE) {
>> +	if (cbndx < 0) {
>> +		base = ARM_SMMU_GR0(smmu);
>> +		status = base + ARM_SMMU_GR0_sTLBGSTATUS;
>> +		writel_relaxed(0, base + ARM_SMMU_GR0_sTLBGSYNC);
>> +	} else {
>> +		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cbndx);
>> +		status = base + ARM_SMMU_CB_TLBSTATUS;
>> +		writel_relaxed(0, base + ARM_SMMU_CB_TLBSYNC);
>> +	}
>> +
>> +	while (readl_relaxed(status) & sTLBGSTATUS_GSACTIVE) {
>>   		cpu_relax();
>>   		if (++count == TLB_LOOP_TIMEOUT) {
>>   			dev_err_ratelimited(smmu->dev,
>> @@ -567,7 +577,13 @@ static void __arm_smmu_tlb_sync(struct arm_smmu_device *smmu)
>>   static void arm_smmu_tlb_sync(void *cookie)
>>   {
>>   	struct arm_smmu_domain *smmu_domain = cookie;
>> -	__arm_smmu_tlb_sync(smmu_domain->smmu);
>> +	int cbndx = smmu_domain->cfg.cbndx;
>> +
>> +	if (smmu_domain->stage == ARM_SMMU_DOMAIN_S2 &&
>> +	    smmu_domain->smmu->version < ARM_SMMU_V2)
>> +		cbndx = -1;
>
> I think it would be cleaner just to override the sync function pointer
> when we initialise a stage-2 page table for an SMMUv1 implementation.
>
> Any reason not to go that way?

Frankly, the idea just didn't occur to me. Looking more closely, if we 
were to simply put a set of iommu_gather_ops pointers in each domain 
based on the format, we could then also break up the confusing mess of 
arm_smmu_tlb_inv_range_nosync(), which would be nice.

I'll give that a go on top of the context format series I'm preparing 
(with which it would otherwise conflict horribly) and see how it looks.

Robin.


From will.deacon at arm.com  Wed Feb 10 03:58:53 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 11:58:53 +0000
Subject: [PATCH] arm64: Rework valid_user_regs
In-Reply-To: <1455041501-30018-1-git-send-email-mark.rutland@arm.com>
References: <1455041501-30018-1-git-send-email-mark.rutland@arm.com>
Message-ID: <20160210115853.GG1052@arm.com>

Hi Mark,

On Tue, Feb 09, 2016 at 06:11:41PM +0000, Mark Rutland wrote:
> We validate pstate using PSR_MODE32_BIT, which is part of the
> user-provided pstate (and cannot be trusted). Also, we conflate
> validation of AArch32 and AArch64 pstate values, making the code
> difficult to reason about.
> 
> Instead, validate the pstate value based on the associated task. The
> task may or may not be current (e.g. when using ptrace), so this must be
> passed explicitly by callers. To avoid circular header dependencies via
> sched.h, is_compat_task is pulled out of asm/ptrace.h.
> 
> To make the code possible to reason about, the AArch64 and AArch32
> validation is split into separate functions. Software must respect the
> RES0 policy for SPSR bits, and thus the kernel mirrors the hardware
> policy (RAZ/WI) for bits as-yet unallocated. When these acquire an
> architected meaning writes may be permitted (potentially with additional
> validation).

Thanks for doing this. Comments inline.

> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Dave Martin <dave.martin at arm.com>
> Cc: James Morse <james.morse at arm.com>
> Cc: Peter Maydell <peter.maydell at linaro.org>
> Cc: Will Deacon <will.deacon at arm.com>
> ---
>  arch/arm64/include/asm/ptrace.h | 32 ++-------------------
>  arch/arm64/kernel/ptrace.c      | 64 +++++++++++++++++++++++++++++++++++++++--
>  arch/arm64/kernel/signal.c      |  4 +--
>  arch/arm64/kernel/signal32.c    |  2 +-
>  4 files changed, 68 insertions(+), 34 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> index e9e5467..0bb538b 100644
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -151,35 +151,9 @@ static inline unsigned long regs_return_value(struct pt_regs *regs)
>  	return regs->regs[0];
>  }
>  
> -/*
> - * Are the current registers suitable for user mode? (used to maintain
> - * security in signal handlers)
> - */
> -static inline int valid_user_regs(struct user_pt_regs *regs)
> -{
> -	if (user_mode(regs) && (regs->pstate & PSR_I_BIT) == 0) {
> -		regs->pstate &= ~(PSR_F_BIT | PSR_A_BIT);
> -
> -		/* The T bit is reserved for AArch64 */
> -		if (!(regs->pstate & PSR_MODE32_BIT))
> -			regs->pstate &= ~COMPAT_PSR_T_BIT;
> -
> -		return 1;
> -	}
> -
> -	/*
> -	 * Force PSR to something logical...
> -	 */
> -	regs->pstate &= PSR_f | PSR_s | (PSR_x & ~PSR_A_BIT) | \
> -			COMPAT_PSR_T_BIT | PSR_MODE32_BIT;
> -
> -	if (!(regs->pstate & PSR_MODE32_BIT)) {
> -		regs->pstate &= ~COMPAT_PSR_T_BIT;
> -		regs->pstate |= PSR_MODE_EL0t;
> -	}
> -
> -	return 0;
> -}
> +/* We must avoid circular header include via sched.h */
> +struct task_struct;
> +int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task);
>  
>  #define instruction_pointer(regs)	((unsigned long)(regs)->pc)
>  
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index ff7f132..23c20c2 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -500,7 +500,7 @@ static int gpr_set(struct task_struct *target, const struct user_regset *regset,
>  	if (ret)
>  		return ret;
>  
> -	if (!valid_user_regs(&newregs))
> +	if (!valid_user_regs(&newregs, target))
>  		return -EINVAL;
>  
>  	task_pt_regs(target)->user_regs = newregs;
> @@ -770,7 +770,7 @@ static int compat_gpr_set(struct task_struct *target,
>  
>  	}
>  
> -	if (valid_user_regs(&newregs.user_regs))
> +	if (valid_user_regs(&newregs.user_regs, target))
>  		*task_pt_regs(target) = newregs;
>  	else
>  		ret = -EINVAL;
> @@ -1272,3 +1272,63 @@ asmlinkage void syscall_trace_exit(struct pt_regs *regs)
>  	if (test_thread_flag(TIF_SYSCALL_TRACE))
>  		tracehook_report_syscall(regs, PTRACE_SYSCALL_EXIT);
>  }
> +
> +/*
> + * Bits which are architecturally RES0 per ARM DDI 0487A.h
> + * The kernel matches the HW policy. Userspace cannot use these until they have
> + * an architectural meaning.
> + */
> +#define SPSR_EL1_AARCH64_RES0_BITS \
> +	(GENMASK_ULL(63,32) | GENMASK_ULL(27, 22) | GENMASK_ULL(19, 10) | \
> +	 GENMASK_ULL(5, 5))
> +#define SPSR_EL1_AARCH32_RES0_BITS \
> +	(GENMASK_ULL(63,32) | (GENMASK_ULL(23, 22)))

The J bit (24) is also RES0 and the E bit (9) can be RES0/RES1 depending
on what the CPU supports. It also might be worth negating these in the
definition, rather than on every use.

> +static int valid_aa32_regs(struct user_pt_regs *regs)

valid_compat_user_regs

> +{
> +	regs->pstate &= ~SPSR_EL1_AARCH32_RES0_BITS;
> +
> +	if (user_mode(regs) && (regs->pstate & PSR_MODE32_BIT) &&
> +	    (regs->pstate & COMPAT_PSR_A_BIT) == 0 &&
> +	    (regs->pstate & COMPAT_PSR_I_BIT) == 0 &&
> +	    (regs->pstate & COMPAT_PSR_F_BIT) == 0) {
> +		return 1;
> +	}
> +
> +	/* Force PSR to a valid 32-bit EL0t */
> +	regs->pstate |= PSR_MODE32_BIT;
> +	regs->pstate &= PSR_f | PSR_s | (PSR_x & ~COMPAT_PSR_A_BIT) | \
> +			COMPAT_PSR_T_BIT;
> +
> +	return 0;
> +}
> +
> +static int valid_aa64_regs(struct user_pt_regs *regs)

valid_native_user_regs

> +{
> +	regs->pstate &= ~SPSR_EL1_AARCH64_RES0_BITS;
> +
> +	if (user_mode(regs) && !(regs->pstate & PSR_MODE32_BIT) &&
> +	    (regs->pstate & PSR_D_BIT) == 0 &&
> +	    (regs->pstate & PSR_A_BIT) == 0 &&
> +	    (regs->pstate & PSR_I_BIT) == 0 &&
> +	    (regs->pstate & PSR_F_BIT) == 0) {
> +		return 1;
> +	}

I think we should err on the side of caution and nuke SS and IL for both
native and compat too, although that seems a odds with the PSR_s mask.
I wonder how relevant those PSR groups are in ARMv8...

> +	/* Force PSR to a valid 64-bit EL0t */
> +	regs->pstate &= PSR_f | PSR_s;
> +
> +	return 0;
> +}
> +
> +/*
> + * Are the current registers suitable for user mode? (used to maintain
> + * security in signal handlers)
> + */
> +int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
> +{
> +	if (is_compat_thread(task_thread_info(task)))

is_compat_task

Will


From drjones at redhat.com  Wed Feb 10 04:02:11 2016
From: drjones at redhat.com (Andrew Jones)
Date: Wed, 10 Feb 2016 13:02:11 +0100
Subject: [PATCH 0/8] KVM/ARM: Guest Entry/Exit optimizations
In-Reply-To: <56BAF60D.6020506@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <20160209205919.GF5171@cbox> <56BAF60D.6020506@arm.com>
Message-ID: <20160210120211.fjp2sxzivdhxug6p@hawk.localdomain>

On Wed, Feb 10, 2016 at 08:34:21AM +0000, Marc Zyngier wrote:
> On 09/02/16 20:59, Christoffer Dall wrote:
> > On Mon, Feb 08, 2016 at 11:40:14AM +0000, Marc Zyngier wrote:
> >> I've recently been looking at our entry/exit costs, and profiling
> >> figures did show some very low hanging fruits.
> >>
> >> The most obvious cost is that accessing the GIC HW is slow. As in
> >> "deadly slow", specially when GICv2 is involved. So not hammering the
> >> HW when there is nothing to write is immediately beneficial, as this
> >> is the most common cases (whatever people seem to think, interrupts
> >> are a *rare* event).
> >>
> >> Another easy thing to fix is the way we handle trapped system
> >> registers. We do insist on (mostly) sorting them, but we do perform a
> >> linear search on trap. We can switch to a binary search for free, and
> >> get immediate benefits (the PMU code, being extremely trap-happy,
> >> benefits immediately from this).
> >>
> >> With these in place, I see an improvement of 20 to 30% (depending on
> >> the platform) on our world-switch cycle count when running a set of
> >> hand-crafted guests that are designed to only perform traps.
> > 
> > I'm curious about the weight of these two?  My guess based on the
> > measurement work I did is that the GIC is by far the worst sinner, but
> > that was exacerbated on X-Gene compared to Seattle.
> 
> Indeed, the GIC is the real pig. 80% of the benefit is provided by not
> accessing it when not absolutely required. The sysreg access is only
> visible for workloads that are extremely trap-happy, but that's what
> happens with as soon as you start exercising the PMU code.
> 
> >>
> >> Methodology:
> >>
> >> * NULL-hypercall guest: Perform 65536 PSCI_0_2_FN_PSCI_VERSION calls,
> >> and then a power-off:
> >>
> >> __start:
> >> 	mov	x19, #(1 << 16)
> >> 1:	mov	x0, #0x84000000
> >> 	hvc	#0
> >> 	sub	x19, x19, #1
> >> 	cbnz	x19, 1b
> >> 	mov	x0, #0x84000000
> >> 	add	x0, x0, #9
> >> 	hvc	#0
> >> 	b	.
> >>
> >> * sysreg trap guest: Perform 2^20 PMSELR_EL0 accesses, and power-off:
> >>
> >> __start:
> >> 	mov	x19, #(1 << 20)
> >> 1:	mrs	x0, PMSELR_EL0
> >> 	sub	x19, x19, #1
> >> 	cbnz	x19, 1b
> >> 	mov	x0, #0x84000000
> >> 	add	x0, x0, #9
> >> 	hvc	#0
> >> 	b	.
> >>
> >> * These guests are profiled using perf and kvmtool:
> >>
> >> taskset -c 1 perf stat -e cycles:kh lkvm run -c1 --kernel do_sysreg.bin 2>&1 >/dev/null| grep cycles
> > 
> > these would be good to add to kvm-unit-tests so we can keep an eye on
> > this sort of thing...

I can work on that. (Actually I already had put this on my TODO when I
saw this series. Your interest in it just bumped it up in priority :-)

> 
> Yeah, I was thinking of that too. In the meantime, I've also created a
> GICv2 self-IPI test case, which has led to further improvement (a 10%
> reduction in the number of cycles on Seattle). The ugly thing about that
> test is that it knows where kvmtool places the GIC (I didn't fancy
> parsing the DT in assembly code). Hopefully there is a way to abstract this.

I have a simple IPI test written for kvm-unit-tests already[*], but it's
been laying around for a while. I can dust it off and make a self-IPI
test out of it yet today though. I've been hesitating to post any gic
related stuff to kvm-unit-tests, because I know Andre has been looking
into it (and he has the gic expertise to do it more cleanly than I). I'll
go ahead and post my little thing now though, as he can always review it
and/or clean it up later :-)

[*] https://github.com/rhdrjones/kvm-unit-tests/commit/05af9b0361ac5eab58f46e5451e585c9625c3b75

Thanks,
drew


From marc.zyngier at arm.com  Wed Feb 10 04:02:45 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 12:02:45 +0000
Subject: [PATCH V3 10/10] acpi, gicv3, its: Use MADT ITS subtable to do
 PCI/MSI domain initialization.
In-Reply-To: <1453209083-3358-11-git-send-email-tn@semihalf.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
 <1453209083-3358-11-git-send-email-tn@semihalf.com>
Message-ID: <56BB26E5.6060703@arm.com>

On 19/01/16 13:11, Tomasz Nowicki wrote:
> After refactoring DT code, we let ACPI to build ITS PCI MSI domain
> and do requester ID to device ID translation using IORT table.
> 
> We have now full PCI MSI domain stack, thus we can enable ITS initialization
> from GICv3 core driver for ACPI scenario.
> 
> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
> ---
>  drivers/irqchip/irq-gic-v3-its-pci-msi.c | 44 +++++++++++++++++++++++++++++++-
>  drivers/irqchip/irq-gic-v3.c             |  3 +--
>  drivers/pci/msi.c                        |  3 +++
>  3 files changed, 47 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> index 06165cb..7f0a958 100644
> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> @@ -15,6 +15,8 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <linux/acpi.h>
> +#include <linux/iort.h>
>  #include <linux/msi.h>
>  #include <linux/of.h>
>  #include <linux/of_irq.h>
> @@ -143,10 +145,50 @@ static int __init its_pci_of_msi_init(void)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_ACPI
> +
> +static int __init
> +its_pci_msi_parse_madt(struct acpi_subtable_header *header,
> +		    const unsigned long end)
> +{
> +	struct acpi_madt_generic_translator *its_entry;
> +	struct fwnode_handle *domain_handle;
> +
> +	its_entry = (struct acpi_madt_generic_translator *)header;
> +	domain_handle = iort_find_its_domain_token(its_entry->translation_id);
> +	if (!domain_handle) {
> +		pr_err("ITS at 0x%lx: Unable to locate ITS domain handle\n",
> +		       (long)its_entry->base_address);
> +		return 0;
> +	}
> +
> +	if (its_pci_msi_init_one(domain_handle))
> +		return 0;
> +
> +	pci_msi_register_fwnode_provider(&iort_find_pci_domain_token);

I'm a bit worried by this. You are registering this for each and every
ITS that gets probed (useless, but why not). But also, you're using a
hook that is designed to work at the bus level, without caring for the
actual PCI devices. That's fine for something like GICv2m, which exposes
a single domain, but I can't picture how this works when you have
devices sitting behind a single RC that talk to different ITSs.

My understanding is that IORT was behaving in a similar way the msi-map
property works, so I'm a bit puzzled here.

Can you please shed some light on that?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From will.deacon at arm.com  Wed Feb 10 04:10:30 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 12:10:30 +0000
Subject: [PATCH] arm64: use raw_smp_processor_id in stack backtrace dump
In-Reply-To: <56BB247F.6040202@arm.com>
References: <1455053182-31404-1-git-send-email-yang.shi@linaro.org>
 <20160210102939.GD1052@arm.com> <56BB247F.6040202@arm.com>
Message-ID: <20160210121030.GH1052@arm.com>

On Wed, Feb 10, 2016 at 11:52:31AM +0000, James Morse wrote:
> On 10/02/16 10:29, Will Deacon wrote:
> > On Tue, Feb 09, 2016 at 01:26:22PM -0800, Yang Shi wrote:
> >> dump_backtrace may be called in kthread context, which is not bound to a single
> >> cpu, i.e. khungtaskd, then calling smp_processor_id may trigger the below bug
> >> report:
> > 
> > If we're preemptible here, it means that our irq_stack_ptr is potentially
> > bogus. Whilst this isn't an issue for kthreads, it does feel like we
> > could make this slightly more robust in the face of potential frame
> > corruption. Maybe just zero the IRQ stack pointer if we're in preemptible
> > context?
> 
> Switching between stacks is only valid if we are tracing ourselves while on the
> irq_stack, we should probably prevent it for other tasks too.
> 
> Something like (untested):
> ---------------------
> if (tsk == current && in_atomic())
> 	irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
> else
> 	irq_stack_ptr = 0;
> ---------------------
> 
> This would work when we trace ourselves while on the irq_stack, but break*
> tracing a running task on a remote cpu (khungtaskd doesn't do this).
> 
> The same fix would apply to unwind_frame(), we have 'tsk' in both functions.
> 
> Thoughts?

in_atomic is a misnomer:

  https://lwn.net/Articles/274695/

;)

So we might be better off zeroing the pointer if tsk != current ||
preemptible(). But yeah, I think we're in general agreement about this.

Will


From robin.murphy at arm.com  Wed Feb 10 04:10:28 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 10 Feb 2016 12:10:28 +0000
Subject: [PATCH 2/4] iommu/arm-smmu: Allow disabling unmatched stream
 bypass
In-Reply-To: <20160209140631.GM22874@arm.com>
References: <cover.1453830752.git.robin.murphy@arm.com>
 <10ebf5a136a787da54ffd1d6167953f82f01a834.1453830752.git.robin.murphy@arm.com>
 <20160209140631.GM22874@arm.com>
Message-ID: <56BB28B4.2040406@arm.com>

On 09/02/16 14:06, Will Deacon wrote:
> Hi Robin,
>
> On Tue, Jan 26, 2016 at 06:06:35PM +0000, Robin Murphy wrote:
>> Borrow the disable_bypass parameter from the SMMUv3 driver as a handy
>> debugging/security feature so that unmatched stream IDs (i.e. devices
>> not attached to an IOMMU domain) may be configured to fault.
>>
>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>> ---
>>   drivers/iommu/arm-smmu.c | 32 +++++++++++++++++++++++---------
>>   1 file changed, 23 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 1f9093d..d1b7dc1 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -141,6 +141,8 @@
>>   #define ID2_PTFS_16K			(1 << 13)
>>   #define ID2_PTFS_64K			(1 << 14)
>>
>> +#define sGFSR_USF			(1 << 1)
>> +
>>   /* Global TLB invalidation */
>>   #define ARM_SMMU_GR0_TLBIVMID		0x64
>>   #define ARM_SMMU_GR0_TLBIALLNSNH	0x68
>> @@ -263,6 +265,10 @@ static int force_stage;
>>   module_param_named(force_stage, force_stage, int, S_IRUGO);
>>   MODULE_PARM_DESC(force_stage,
>>   	"Force SMMU mappings to be installed at a particular stage of translation. A value of '1' or '2' forces the corresponding stage. All other values are ignored (i.e. no stage is forced). Note that selecting a specific stage will disable support for nested translation.");
>> +static bool disable_bypass;
>> +module_param_named(disable_bypass, disable_bypass, bool, S_IRUGO);
>> +MODULE_PARM_DESC(disable_bypass,
>> +	"Disable bypass streams such that incoming transactions from devices that are not attached to an iommu domain will report an abort back to the device and will not be allowed to pass through the SMMU.");
>>
>>   enum arm_smmu_arch_version {
>>   	ARM_SMMU_V1 = 1,
>> @@ -704,8 +710,12 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev)
>>   	if (!gfsr)
>>   		return IRQ_NONE;
>>
>> -	dev_err_ratelimited(smmu->dev,
>> -		"Unexpected global fault, this could be serious\n");
>> +	if (gfsr & sGFSR_USF)
>> +		dev_err_ratelimited(smmu->dev, "Unmatched stream fault: ID 0x%x\n",
>> +				    gfsynr1 & SMR_ID_MASK);
>> +	else
>
> I think I'd rather drop this message -- a global error is still indicative
> that something has gone horriby wrong, and we already print the gsynr
> registers below. Furthermore, if we take multiple faults, it might look
> like they're all exclusively due to unmatched streams.
>
> On top of that, I'm not convinced that USF will be set for an SMMU that
> doesn't implement stream-matching (because it will match an S2CR of type
> FAULT).

You're quite right, by the look of it the stream indexing case should 
report ICF rather than USF. My rationale for special-casing the message 
was that it's less of an "unexpected" fault when it's something you've 
specifically asked the driver for, but it also seems reasonable that 
someone turning on such an "I know what I'm doing" feature might be able 
to decode GFSR themselves. Considering the machinations of matching 
!MULTI and USF or ICF as appropriate just for the sake of printing a 
slightly reworded message, I'll drop this hunk.

> Other than that, looks good.

Thanks,
Robin.


From sergei.shtylyov at cogentembedded.com  Wed Feb 10 04:11:03 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Feb 2016 15:11:03 +0300
Subject: [PATCH v3 2/8] dma-mapping: add {map,unmap}_resource to
 dma_map_ops
In-Reply-To: <1455065878-11906-3-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <1455065878-11906-3-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <56BB28D7.1090608@cogentembedded.com>

Hello.

On 2/10/2016 3:57 AM, Niklas S?derlund wrote:

> Add methods to handle mapping of device resources from a physical
> address. This is needed for example to map be able to map MMIO FIFO
                                          ^^^ not needed

> registers to a IOMMU.
>
> Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
[...]

MBR, Sergei



From marc.zyngier at arm.com  Wed Feb 10 04:24:06 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 12:24:06 +0000
Subject: [PATCH 0/8] KVM/ARM: Guest Entry/Exit optimizations
In-Reply-To: <20160210120211.fjp2sxzivdhxug6p@hawk.localdomain>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <20160209205919.GF5171@cbox> <56BAF60D.6020506@arm.com>
 <20160210120211.fjp2sxzivdhxug6p@hawk.localdomain>
Message-ID: <56BB2BE6.8020600@arm.com>

On 10/02/16 12:02, Andrew Jones wrote:
> On Wed, Feb 10, 2016 at 08:34:21AM +0000, Marc Zyngier wrote:
>> On 09/02/16 20:59, Christoffer Dall wrote:
>>> On Mon, Feb 08, 2016 at 11:40:14AM +0000, Marc Zyngier wrote:
>>>> I've recently been looking at our entry/exit costs, and profiling
>>>> figures did show some very low hanging fruits.
>>>>
>>>> The most obvious cost is that accessing the GIC HW is slow. As in
>>>> "deadly slow", specially when GICv2 is involved. So not hammering the
>>>> HW when there is nothing to write is immediately beneficial, as this
>>>> is the most common cases (whatever people seem to think, interrupts
>>>> are a *rare* event).
>>>>
>>>> Another easy thing to fix is the way we handle trapped system
>>>> registers. We do insist on (mostly) sorting them, but we do perform a
>>>> linear search on trap. We can switch to a binary search for free, and
>>>> get immediate benefits (the PMU code, being extremely trap-happy,
>>>> benefits immediately from this).
>>>>
>>>> With these in place, I see an improvement of 20 to 30% (depending on
>>>> the platform) on our world-switch cycle count when running a set of
>>>> hand-crafted guests that are designed to only perform traps.
>>>
>>> I'm curious about the weight of these two?  My guess based on the
>>> measurement work I did is that the GIC is by far the worst sinner, but
>>> that was exacerbated on X-Gene compared to Seattle.
>>
>> Indeed, the GIC is the real pig. 80% of the benefit is provided by not
>> accessing it when not absolutely required. The sysreg access is only
>> visible for workloads that are extremely trap-happy, but that's what
>> happens with as soon as you start exercising the PMU code.
>>
>>>>
>>>> Methodology:
>>>>
>>>> * NULL-hypercall guest: Perform 65536 PSCI_0_2_FN_PSCI_VERSION calls,
>>>> and then a power-off:
>>>>
>>>> __start:
>>>> 	mov	x19, #(1 << 16)
>>>> 1:	mov	x0, #0x84000000
>>>> 	hvc	#0
>>>> 	sub	x19, x19, #1
>>>> 	cbnz	x19, 1b
>>>> 	mov	x0, #0x84000000
>>>> 	add	x0, x0, #9
>>>> 	hvc	#0
>>>> 	b	.
>>>>
>>>> * sysreg trap guest: Perform 2^20 PMSELR_EL0 accesses, and power-off:
>>>>
>>>> __start:
>>>> 	mov	x19, #(1 << 20)
>>>> 1:	mrs	x0, PMSELR_EL0
>>>> 	sub	x19, x19, #1
>>>> 	cbnz	x19, 1b
>>>> 	mov	x0, #0x84000000
>>>> 	add	x0, x0, #9
>>>> 	hvc	#0
>>>> 	b	.
>>>>
>>>> * These guests are profiled using perf and kvmtool:
>>>>
>>>> taskset -c 1 perf stat -e cycles:kh lkvm run -c1 --kernel do_sysreg.bin 2>&1 >/dev/null| grep cycles
>>>
>>> these would be good to add to kvm-unit-tests so we can keep an eye on
>>> this sort of thing...
> 
> I can work on that. (Actually I already had put this on my TODO when I
> saw this series. Your interest in it just bumped it up in priority :-)

Ah! You're in charge, then! ;-)

>>
>> Yeah, I was thinking of that too. In the meantime, I've also created a
>> GICv2 self-IPI test case, which has led to further improvement (a 10%
>> reduction in the number of cycles on Seattle). The ugly thing about that
>> test is that it knows where kvmtool places the GIC (I didn't fancy
>> parsing the DT in assembly code). Hopefully there is a way to abstract this.
> 
> I have a simple IPI test written for kvm-unit-tests already[*], but it's
> been laying around for a while. I can dust it off and make a self-IPI
> test out of it yet today though. I've been hesitating to post any gic
> related stuff to kvm-unit-tests, because I know Andre has been looking
> into it (and he has the gic expertise to do it more cleanly than I). I'll
> go ahead and post my little thing now though, as he can always review it
> and/or clean it up later :-)
> 
> [*] https://github.com/rhdrjones/kvm-unit-tests/commit/05af9b0361ac5eab58f46e5451e585c9625c3b75

For the record, the test case I've been running is this:

__start:
	mov	x19, #(1 << 20)

	mov	x0, #0x3fff0000		// Dist
	mov	x1, #0x3ffd0000		// CPU
	mov	w2, #1
	str	w2, [x0]		// Enable Group0
	ldr	w2, =0xa0a0a0a0
	str	w2, [x0, 0x400]		// A0 priority for SGI0-3
	mov	w2, #0x0f
	str	w2, [x0, #0x100]	// Enable SGI0-3
	mov	w2, #0xf0
	str	w2, [x1, #4]		// PMR
	mov	w2, #1
	str	w2, [x1]		// Enable CPU interface
	
1:
	mov	w2, #(2 << 24)		// Interrupt self with SGI0
	str	w2, [x0, #0xf00]

2:	ldr	w2, [x1, #0x0c]		// GICC_IAR
	cmp	w2, #0x3ff
	b.ne	3f

	wfi
	b	2b

3:	str	w2, [x1, #0x10]		// EOI

	sub	x19, x19, #1
	cbnz	x19, 1b

// Die
	mov	x0, #0x84000000
	add	x0, x0, #9
	hvc	#0
	b	.

Feel free to adapt it so it fits in your framework if you find it useful
(but I guess you'll be inclined to rewrite it in C).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From andre.przywara at arm.com  Wed Feb 10 04:30:49 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 10 Feb 2016 12:30:49 +0000
Subject: breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi: Refactor
 A31 PLL6 so that it can be reused)
In-Reply-To: <56B4E2FB.3050703@arm.com>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com>
Message-ID: <56BB2D79.6090402@arm.com>

Hi,

just a ping:

Are we really OK with breaking existing DTs in 4.6? (per the code in
-next: f7d372ba54ea04d528a291b8dbe34716507bb60b, which is this patch).

Also I think one needs ACKs from DT maintainers before merging something
in the respective directories, which I don't see here.

As I am somewhat blocked on that patch, I'd like to have some discussion
on the list.

Thanks,
Andre.

On 05/02/16 17:59, Andre Przywara wrote:
> Hi Maxime,
> 
> just found this while looking at your current git branch, so sorry for
> the late reply.
> 
> CC:ing DT people, since you touch both existing DTs(!) and the binding doc.
> 
> On 01/02/16 20:20, Maxime Ripard wrote:
>> Remove the fixed dividers from the PLL6 driver to be able to have a
>> reusable driver that can be used across several SoCs that share the same
>> controller, but don't have the same set of dividers for this clock, and to
>> also be reused multiple times in the same SoC, since we're droping the
>> clock name.
>>
>> Acked-by: Chen-Yu Tsai <wens at csie.org>
>> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
>> ---
>>
>> Changes from v3:
>>   - Fixed the documentation
>>   - Added pll6d2 back
>>
>> Changes from v2:
>>   - Rebased and converted over to the new factors refactoring. Fixed the
>>     retrieved rate
>>
>>  Documentation/devicetree/bindings/clock/sunxi.txt |  2 +-
>>  arch/arm/boot/dts/sun6i-a31.dtsi                  | 36 +++++++++++-----------
>>  arch/arm/boot/dts/sun8i-a23-a33.dtsi              | 25 ++++++++++-----
>>  arch/arm/boot/dts/sun8i-a23.dtsi                  |  2 +-
>>  arch/arm/boot/dts/sun8i-a33.dtsi                  |  4 +--
>>  arch/arm/boot/dts/sun8i-h3.dtsi                   | 37 ++++++++++++++---------
> 
> So are you really breaking all those systems by changing the DT and the
> driver in an incompatible way?
> Please correct me if this assessment is wrong, but to me it looks like
> any user out there is either stuck with 4.5 at best _or_ will only be
> able to run 4.6 and later (depending on which version of the DT she is
> using)? And no, switching DTs along with the kernel is _not_ an option.
> That is not how I understand DT.
> Also this totally ignores any other DT user (U-Boot, FreeBSD, you name it).
> 
> I actually appreciate this rework, it's more flexible now and looks
> better, but you really can't do this in a way to breaks compatibility
> with existing DTs.
> 
> Jean-Francois came up with another solution for the pll8 clock [1], so
> could this be considered at least?
> I think changing the H3 PLL8 clock from dummy to something real is a
> different story in terms of compatibility (since it never really worked
> before and this wouldn't change for any old-DT user).
> 
> Cheers,
> Andre.
> 
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/405104.html
> 
>>  drivers/clk/sunxi/clk-sunxi.c                     | 32 ++++++++++----------
>>  7 files changed, 78 insertions(+), 60 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
>> index e59f57b24777..f82850c0f6a5 100644
>> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
>> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
>> @@ -86,7 +86,7 @@ Required properties for all clocks:
>>  - #clock-cells : from common clock binding; shall be set to 0 except for
>>  	the following compatibles where it shall be set to 1:
>>  	"allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk",
>> -	"allwinner,sun4i-pll6-clk", "allwinner,sun6i-a31-pll6-clk",
>> +	"allwinner,sun4i-pll6-clk",
>>  	"allwinner,*-usb-clk", "allwinner,*-mmc-clk",
>>  	"allwinner,*-mmc-config-clk"
>>  - clock-output-names : shall be the corresponding names of the outputs.
>> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
>> index b6ad7850fac6..05fe3d1aa328 100644
>> --- a/arch/arm/boot/dts/sun6i-a31.dtsi
>> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
>> @@ -65,7 +65,7 @@
>>  			compatible = "allwinner,simple-framebuffer",
>>  				     "simple-framebuffer";
>>  			allwinner,pipeline = "de_be0-lcd0-hdmi";
>> -			clocks = <&pll6 0>;
>> +			clocks = <&pll6>;
>>  			status = "disabled";
>>  		};
>>  
>> @@ -73,7 +73,7 @@
>>  			compatible = "allwinner,simple-framebuffer",
>>  				     "simple-framebuffer";
>>  			allwinner,pipeline = "de_be0-lcd0";
>> -			clocks = <&pll6 0>;
>> +			clocks = <&pll6>;
>>  			status = "disabled";
>>  		};
>>  	};
>> @@ -201,11 +201,11 @@
>>  		};
>>  
>>  		pll6: clk at 01c20028 {
>> -			#clock-cells = <1>;
>> +			#clock-cells = <0>;
>>  			compatible = "allwinner,sun6i-a31-pll6-clk";
>>  			reg = <0x01c20028 0x4>;
>>  			clocks = <&osc24M>;
>> -			clock-output-names = "pll6", "pll6x2";
>> +			clock-output-names = "pll6";
>>  		};
>>  
>>  		cpu: cpu at 01c20050 {
>> @@ -235,7 +235,7 @@
>>  			#clock-cells = <0>;
>>  			compatible = "allwinner,sun6i-a31-ahb1-clk";
>>  			reg = <0x01c20054 0x4>;
>> -			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
>> +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
>>  			clock-output-names = "ahb1";
>>  
>>  			/*
>> @@ -244,7 +244,7 @@
>>  			 * controller requires AHB1 clocked from PLL6.
>>  			 */
>>  			assigned-clocks = <&ahb1>;
>> -			assigned-clock-parents = <&pll6 0>;
>> +			assigned-clock-parents = <&pll6>;
>>  		};
>>  
>>  		ahb1_gates: clk at 01c20060 {
>> @@ -307,7 +307,7 @@
>>  			#clock-cells = <0>;
>>  			compatible = "allwinner,sun4i-a10-apb1-clk";
>>  			reg = <0x01c20058 0x4>;
>> -			clocks = <&osc32k>, <&osc24M>, <&pll6 0>, <&pll6 0>;
>> +			clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
>>  			clock-output-names = "apb2";
>>  		};
>>  
>> @@ -331,7 +331,7 @@
>>  			#clock-cells = <1>;
>>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>>  			reg = <0x01c20088 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>;
>> +			clocks = <&osc24M>, <&pll6>;
>>  			clock-output-names = "mmc0",
>>  					     "mmc0_output",
>>  					     "mmc0_sample";
>> @@ -341,7 +341,7 @@
>>  			#clock-cells = <1>;
>>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>>  			reg = <0x01c2008c 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>;
>> +			clocks = <&osc24M>, <&pll6>;
>>  			clock-output-names = "mmc1",
>>  					     "mmc1_output",
>>  					     "mmc1_sample";
>> @@ -351,7 +351,7 @@
>>  			#clock-cells = <1>;
>>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>>  			reg = <0x01c20090 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>;
>> +			clocks = <&osc24M>, <&pll6>;
>>  			clock-output-names = "mmc2",
>>  					     "mmc2_output",
>>  					     "mmc2_sample";
>> @@ -361,7 +361,7 @@
>>  			#clock-cells = <1>;
>>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>>  			reg = <0x01c20094 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>;
>> +			clocks = <&osc24M>, <&pll6>;
>>  			clock-output-names = "mmc3",
>>  					     "mmc3_output",
>>  					     "mmc3_sample";
>> @@ -371,7 +371,7 @@
>>  			#clock-cells = <0>;
>>  			compatible = "allwinner,sun4i-a10-mod0-clk";
>>  			reg = <0x01c2009c 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>;
>> +			clocks = <&osc24M>, <&pll6>;
>>  			clock-output-names = "ss";
>>  		};
>>  
>> @@ -379,7 +379,7 @@
>>  			#clock-cells = <0>;
>>  			compatible = "allwinner,sun4i-a10-mod0-clk";
>>  			reg = <0x01c200a0 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>;
>> +			clocks = <&osc24M>, <&pll6>;
>>  			clock-output-names = "spi0";
>>  		};
>>  
>> @@ -387,7 +387,7 @@
>>  			#clock-cells = <0>;
>>  			compatible = "allwinner,sun4i-a10-mod0-clk";
>>  			reg = <0x01c200a4 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>;
>> +			clocks = <&osc24M>, <&pll6>;
>>  			clock-output-names = "spi1";
>>  		};
>>  
>> @@ -395,7 +395,7 @@
>>  			#clock-cells = <0>;
>>  			compatible = "allwinner,sun4i-a10-mod0-clk";
>>  			reg = <0x01c200a8 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>;
>> +			clocks = <&osc24M>, <&pll6>;
>>  			clock-output-names = "spi2";
>>  		};
>>  
>> @@ -403,7 +403,7 @@
>>  			#clock-cells = <0>;
>>  			compatible = "allwinner,sun4i-a10-mod0-clk";
>>  			reg = <0x01c200ac 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>;
>> +			clocks = <&osc24M>, <&pll6>;
>>  			clock-output-names = "spi3";
>>  		};
>>  
>> @@ -1042,8 +1042,8 @@
>>  			ar100: ar100_clk {
>>  				compatible = "allwinner,sun6i-a31-ar100-clk";
>>  				#clock-cells = <0>;
>> -				clocks = <&osc32k>, <&osc24M>, <&pll6 0>,
>> -					 <&pll6 0>;
>> +				clocks = <&osc32k>, <&osc24M>, <&pll6>,
>> +					 <&pll6>;
>>  				clock-output-names = "ar100";
>>  			};
>>  
>> diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
>> index 6f88fb0ddbc7..edc85eeaf365 100644
>> --- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
>> @@ -60,7 +60,7 @@
>>  			compatible = "allwinner,simple-framebuffer",
>>  				     "simple-framebuffer";
>>  			allwinner,pipeline = "de_be0-lcd0";
>> -			clocks = <&pll6 0>;
>> +			clocks = <&pll6>;
>>  			status = "disabled";
>>  		};
>>  	};
>> @@ -129,11 +129,20 @@
>>  		};
>>  
>>  		pll6: clk at 01c20028 {
>> -			#clock-cells = <1>;
>> +			#clock-cells = <0>;
>>  			compatible = "allwinner,sun6i-a31-pll6-clk";
>>  			reg = <0x01c20028 0x4>;
>>  			clocks = <&osc24M>;
>> -			clock-output-names = "pll6", "pll6x2";
>> +			clock-output-names = "pll6";
>> +		};
>> +
>> +                pll6x2: pll6x2_clk {
>> +			compatible = "fixed-factor-clock";
>> +			#clock-cells = <0>;
>> +			clock-div = <1>;
>> +			clock-mult = <2>;
>> +			clocks = <&pll6>;
>> +			clock-output-names = "pll6-2x";
>>  		};
>>  
>>  		cpu: cpu_clk at 01c20050 {
>> @@ -163,7 +172,7 @@
>>  			#clock-cells = <0>;
>>  			compatible = "allwinner,sun6i-a31-ahb1-clk";
>>  			reg = <0x01c20054 0x4>;
>> -			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
>> +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
>>  			clock-output-names = "ahb1";
>>  		};
>>  
>> @@ -190,7 +199,7 @@
>>  			#clock-cells = <0>;
>>  			compatible = "allwinner,sun4i-a10-apb1-clk";
>>  			reg = <0x01c20058 0x4>;
>> -			clocks = <&osc32k>, <&osc24M>, <&pll6 0>, <&pll6 0>;
>> +			clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
>>  			clock-output-names = "apb2";
>>  		};
>>  
>> @@ -213,7 +222,7 @@
>>  			#clock-cells = <1>;
>>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>>  			reg = <0x01c20088 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>;
>> +			clocks = <&osc24M>, <&pll6>;
>>  			clock-output-names = "mmc0",
>>  					     "mmc0_output",
>>  					     "mmc0_sample";
>> @@ -223,7 +232,7 @@
>>  			#clock-cells = <1>;
>>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>>  			reg = <0x01c2008c 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>;
>> +			clocks = <&osc24M>, <&pll6>;
>>  			clock-output-names = "mmc1",
>>  					     "mmc1_output",
>>  					     "mmc1_sample";
>> @@ -233,7 +242,7 @@
>>  			#clock-cells = <1>;
>>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>>  			reg = <0x01c20090 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>;
>> +			clocks = <&osc24M>, <&pll6>;
>>  			clock-output-names = "mmc2",
>>  					     "mmc2_output",
>>  					     "mmc2_sample";
>> diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/sun8i-a23.dtsi
>> index 92e6616979ea..5e589c1ddda9 100644
>> --- a/arch/arm/boot/dts/sun8i-a23.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-a23.dtsi
>> @@ -79,7 +79,7 @@
>>  			#clock-cells = <0>;
>>  			compatible = "allwinner,sun8i-a23-mbus-clk";
>>  			reg = <0x01c2015c 0x4>;
>> -			clocks = <&osc24M>, <&pll6 1>, <&pll5>;
>> +			clocks = <&osc24M>, <&pll6x2>, <&pll5>;
>>  			clock-output-names = "mbus";
>>  		};
>>  	};
>> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
>> index 001d8402ca18..f3eb618bcfa7 100644
>> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
>> @@ -103,7 +103,7 @@
>>  			#clock-cells = <0>;
>>  			compatible = "allwinner,sun4i-a10-mod0-clk";
>>  			reg = <0x01c2009c 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>;
>> +			clocks = <&osc24M>, <&pll6>;
>>  			clock-output-names = "ss";
>>  		};
>>  
>> @@ -111,7 +111,7 @@
>>  			#clock-cells = <0>;
>>  			compatible = "allwinner,sun8i-a23-mbus-clk";
>>  			reg = <0x01c2015c 0x4>;
>> -			clocks = <&osc24M>, <&pll6 1>, <&pll5>, <&pll11>;
>> +			clocks = <&osc24M>, <&pll6x2>, <&pll5>, <&pll11>;
>>  			clock-output-names = "mbus";
>>  		};
>>  	};
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index 1524130e43c9..6f6b4e469ac9 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -121,11 +121,11 @@
>>  		};
>>  
>>  		pll6: clk at 01c20028 {
>> -			#clock-cells = <1>;
>> +			#clock-cells = <0>;
>>  			compatible = "allwinner,sun6i-a31-pll6-clk";
>>  			reg = <0x01c20028 0x4>;
>>  			clocks = <&osc24M>;
>> -			clock-output-names = "pll6", "pll6x2";
>> +			clock-output-names = "pll6";
>>  		};
>>  
>>  		pll6d2: pll6d2_clk {
>> @@ -133,15 +133,24 @@
>>  			compatible = "fixed-factor-clock";
>>  			clock-div = <2>;
>>  			clock-mult = <1>;
>> -			clocks = <&pll6 0>;
>> -			clock-output-names = "pll6d2";
>> +			clocks = <&pll6>;
>> +			clock-output-names = "pll6-d2";
>>  		};
>>  
>> -		/* dummy clock until pll6 can be reused */
>> -		pll8: pll8_clk {
>> +		pll6x2: pll6x2_clk {
>>  			#clock-cells = <0>;
>> -			compatible = "fixed-clock";
>> -			clock-frequency = <1>;
>> +			compatible = "fixed-factor-clock";
>> +			clock-div = <1>;
>> +			clock-mult = <2>;
>> +			clocks = <&pll6>;
>> +			clock-output-names = "pll6-2x";
>> +		};
>> +
>> +		pll8: clk at 01c20044 {
>> +			#clock-cells = <0>;
>> +			compatible = "allwinner,sun6i-a31-pll6-clk";
>> +			reg = <0x01c20044 0x4>;
>> +			clocks = <&osc24M>;
>>  			clock-output-names = "pll8";
>>  		};
>>  
>> @@ -165,7 +174,7 @@
>>  			#clock-cells = <0>;
>>  			compatible = "allwinner,sun6i-a31-ahb1-clk";
>>  			reg = <0x01c20054 0x4>;
>> -			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
>> +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
>>  			clock-output-names = "ahb1";
>>  		};
>>  
>> @@ -189,7 +198,7 @@
>>  			#clock-cells = <0>;
>>  			compatible = "allwinner,sun4i-a10-apb1-clk";
>>  			reg = <0x01c20058 0x4>;
>> -			clocks = <&osc32k>, <&osc24M>, <&pll6 0>, <&pll6 0>;
>> +			clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
>>  			clock-output-names = "apb2";
>>  		};
>>  
>> @@ -243,7 +252,7 @@
>>  			#clock-cells = <1>;
>>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>>  			reg = <0x01c20088 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>> +			clocks = <&osc24M>, <&pll6>, <&pll8>;
>>  			clock-output-names = "mmc0",
>>  					     "mmc0_output",
>>  					     "mmc0_sample";
>> @@ -253,7 +262,7 @@
>>  			#clock-cells = <1>;
>>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>>  			reg = <0x01c2008c 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>> +			clocks = <&osc24M>, <&pll6>, <&pll8>;
>>  			clock-output-names = "mmc1",
>>  					     "mmc1_output",
>>  					     "mmc1_sample";
>> @@ -263,7 +272,7 @@
>>  			#clock-cells = <1>;
>>  			compatible = "allwinner,sun4i-a10-mmc-clk";
>>  			reg = <0x01c20090 0x4>;
>> -			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
>> +			clocks = <&osc24M>, <&pll6>, <&pll8>;
>>  			clock-output-names = "mmc2",
>>  					     "mmc2_output",
>>  					     "mmc2_sample";
>> @@ -273,7 +282,7 @@
>>  			#clock-cells = <0>;
>>  			compatible = "allwinner,sun8i-a23-mbus-clk";
>>  			reg = <0x01c2015c 0x4>;
>> -			clocks = <&osc24M>, <&pll6 1>, <&pll5>;
>> +			clocks = <&osc24M>, <&pll6x2>, <&pll5>;
>>  			clock-output-names = "mbus";
>>  		};
>>  	};
>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>> index da15f2b12ab2..4de800e379d3 100644
>> --- a/drivers/clk/sunxi/clk-sunxi.c
>> +++ b/drivers/clk/sunxi/clk-sunxi.c
>> @@ -227,9 +227,9 @@ static void sun4i_get_pll5_factors(struct factors_request *req)
>>  }
>>  
>>  /**
>> - * sun6i_a31_get_pll6_factors() - calculates n, k factors for A31 PLL6x2
>> - * PLL6x2 rate is calculated as follows
>> - * rate = parent_rate * (n + 1) * (k + 1)
>> + * sun6i_a31_get_pll6_factors() - calculates n, k factors for A31 PLL6
>> + * PLL6 rate is calculated as follows
>> + * rate = parent_rate * (n + 1) * (k + 1) / 2
>>   * parent_rate is always 24Mhz
>>   */
>>  
>> @@ -238,8 +238,8 @@ static void sun6i_a31_get_pll6_factors(struct factors_request *req)
>>  	u8 div;
>>  
>>  	/* Normalize value to a parent_rate multiple (24M) */
>> -	div = req->rate / req->parent_rate;
>> -	req->rate = req->parent_rate * div;
>> +	div = req->rate / (req->parent_rate / 2);
>> +	req->rate = (req->parent_rate / 2) * div;
>>  
>>  	req->k = div / 32;
>>  	if (req->k > 3)
>> @@ -248,6 +248,15 @@ static void sun6i_a31_get_pll6_factors(struct factors_request *req)
>>  	req->n = DIV_ROUND_UP(div, (req->k + 1)) - 1;
>>  }
>>  
>> +static void sun6i_a31_pll6_recalc(struct factors_request *req)
>> +{
>> +	req->rate = req->parent_rate;
>> +
>> +	req->rate *= req->n + 1;
>> +	req->rate *= req->k + 1;
>> +	req->rate /= 2;
>> +}
>> +
>>  /**
>>   * sun5i_a13_get_ahb_factors() - calculates m, p factors for AHB
>>   * AHB rate is calculated as follows
>> @@ -537,7 +546,7 @@ static const struct factors_data sun6i_a31_pll6_data __initconst = {
>>  	.enable = 31,
>>  	.table = &sun6i_a31_pll6_config,
>>  	.getter = sun6i_a31_get_pll6_factors,
>> -	.name = "pll6x2",
>> +	.recalc = sun6i_a31_pll6_recalc,
>>  };
>>  
>>  static const struct factors_data sun5i_a13_ahb_data __initconst = {
>> @@ -788,15 +797,6 @@ static const struct divs_data pll6_divs_data __initconst = {
>>  	}
>>  };
>>  
>> -static const struct divs_data sun6i_a31_pll6_divs_data __initconst = {
>> -	.factors = &sun6i_a31_pll6_data,
>> -	.ndivs = 2,
>> -	.div = {
>> -		{ .fixed = 2 }, /* normal output */
>> -		{ .self = 1 }, /* base factor clock, 2x */
>> -	}
>> -};
>> -
>>  /**
>>   * sunxi_divs_clk_setup() - Setup function for leaf divisors on clocks
>>   *
>> @@ -938,6 +938,7 @@ free_clkdata:
>>  static const struct of_device_id clk_factors_match[] __initconst = {
>>  	{.compatible = "allwinner,sun4i-a10-pll1-clk", .data = &sun4i_pll1_data,},
>>  	{.compatible = "allwinner,sun6i-a31-pll1-clk", .data = &sun6i_a31_pll1_data,},
>> +	{.compatible = "allwinner,sun6i-a31-pll6-clk", .data = &sun6i_a31_pll6_data,},
>>  	{.compatible = "allwinner,sun8i-a23-pll1-clk", .data = &sun8i_a23_pll1_data,},
>>  	{.compatible = "allwinner,sun7i-a20-pll4-clk", .data = &sun7i_a20_pll4_data,},
>>  	{.compatible = "allwinner,sun5i-a13-ahb-clk", .data = &sun5i_a13_ahb_data,},
>> @@ -959,7 +960,6 @@ static const struct of_device_id clk_div_match[] __initconst = {
>>  static const struct of_device_id clk_divs_match[] __initconst = {
>>  	{.compatible = "allwinner,sun4i-a10-pll5-clk", .data = &pll5_divs_data,},
>>  	{.compatible = "allwinner,sun4i-a10-pll6-clk", .data = &pll6_divs_data,},
>> -	{.compatible = "allwinner,sun6i-a31-pll6-clk", .data = &sun6i_a31_pll6_divs_data,},
>>  	{}
>>  };
>>  
>>
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From mark.rutland at arm.com  Wed Feb 10 04:31:10 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 10 Feb 2016 12:31:10 +0000
Subject: [PATCH] arm64: Rework valid_user_regs
In-Reply-To: <20160210115853.GG1052@arm.com>
References: <1455041501-30018-1-git-send-email-mark.rutland@arm.com>
 <20160210115853.GG1052@arm.com>
Message-ID: <20160210123110.GD2632@leverpostej>

On Wed, Feb 10, 2016 at 11:58:53AM +0000, Will Deacon wrote:
> Hi Mark,
> 
> On Tue, Feb 09, 2016 at 06:11:41PM +0000, Mark Rutland wrote:
> > +/*
> > + * Bits which are architecturally RES0 per ARM DDI 0487A.h
> > + * The kernel matches the HW policy. Userspace cannot use these until they have
> > + * an architectural meaning.
> > + */
> > +#define SPSR_EL1_AARCH64_RES0_BITS \
> > +	(GENMASK_ULL(63,32) | GENMASK_ULL(27, 22) | GENMASK_ULL(19, 10) | \
> > +	 GENMASK_ULL(5, 5))
> > +#define SPSR_EL1_AARCH32_RES0_BITS \
> > +	(GENMASK_ULL(63,32) | (GENMASK_ULL(23, 22)))
> 
> The J bit (24) is also RES0 and the E bit (9) can be RES0/RES1 depending
> on what the CPU supports.

>From a quick look, J is always RES0 for ARMv8. I'll add that to the
mask.

E is a bit more complex; I'll see about handling that dynamically in
valid_compat_user_regs.

> It also might be worth negating these in the definition, rather than
> on every use.

Does that make anything clearer? They're constants which get used once
each, and SPSR_EL1_AARCH*_MASK wouldn't make it clear what the bits
actually are.

If you have a better suggestion for a name I'm happy to change it.

> > +static int valid_aa32_regs(struct user_pt_regs *regs)
> 
> valid_compat_user_regs

Ok

> > +static int valid_aa64_regs(struct user_pt_regs *regs)
> 
> valid_native_user_regs

Ok.

> > +{
> > +	regs->pstate &= ~SPSR_EL1_AARCH64_RES0_BITS;
> > +
> > +	if (user_mode(regs) && !(regs->pstate & PSR_MODE32_BIT) &&
> > +	    (regs->pstate & PSR_D_BIT) == 0 &&
> > +	    (regs->pstate & PSR_A_BIT) == 0 &&
> > +	    (regs->pstate & PSR_I_BIT) == 0 &&
> > +	    (regs->pstate & PSR_F_BIT) == 0) {
> > +		return 1;
> > +	}
> 
> I think we should err on the side of caution and nuke SS and IL for both
> native and compat too, although that seems a odds with the PSR_s mask.
> I wonder how relevant those PSR groups are in ARMv8...

Ok.

I couldn't spot anything in the ARM ARM regarding PSR bit groups,; I was
cargo-culting from the existing code. I'm more than happy to make the
PSR_* groups an aarch32/compat thing.

> > +int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
> > +{
> > +	if (is_compat_thread(task_thread_info(task)))
> 
> is_compat_task

Can't do; is_compat_task() takes no task_struct and assumes we're asking
about current (which doesn't work for the ptrace cases).

We could add a new helper for this, but I think that should be future
cleanup as we'd want to alter the other uses:

[mark at leverpostej:~/src/linux]% git grep is_compat_thread origin/master
origin/master:arch/arm64/include/asm/compat.h:static inline int is_compat_thread(struct thread_info *thread)
origin/master:arch/arm64/include/asm/compat.h:static inline int is_compat_thread(struct thread_info *thread)
origin/master:arch/arm64/include/asm/processor.h:       if (is_compat_thread(task_thread_info(t)))                      \
origin/master:arch/arm64/kernel/hw_breakpoint.c:        return tsk && is_compat_thread(task_thread_info(tsk));
origin/master:arch/arm64/kernel/perf_regs.c:    if (is_compat_thread(task_thread_info(task)))
origin/master:arch/arm64/kernel/process.c:                      if (is_compat_thread(task_thread_info(p)))
origin/master:arch/arm64/kernel/process.c:      tpidrro = is_compat_thread(task_thread_info(next)) ?
origin/master:arch/arm64/kernel/ptrace.c:       else if (is_compat_thread(task_thread_info(task)))

I'm happy to look at cleaning that up as a later patch/series.

Thanks,
Mark.


From lars.persson at axis.com  Wed Feb 10 04:41:49 2016
From: lars.persson at axis.com (Lars Persson)
Date: Wed, 10 Feb 2016 13:41:49 +0100
Subject: [PATCH 0/8] arm: Add Artpec-6 SoC
Message-ID: <cover.1455107681.git.larper@axis.com>

Basic support for the Axis Artpec-6 ARM SoC. Timers, interrupts, UARTs and
ethernet are wired up.

Lars Persson (8):
  clk: add device tree binding for artpec-6 pll1 clock
  clk: add artpec-6 pll1 clock driver
  arm: add device-tree SoC bindings for Axis Artpec-6
  arm: dts: add Artpec-6 soc dtsi file
  arm: dts: add Artpec-6 development board dts
  arm: initial machine port for artpec-6 SoC
  arm: multi_v7_defconfig: add MACH_ARTPEC6
  arm: mach-artpec: add entry to MAINTAINERS

 Documentation/devicetree/bindings/arm/axis.txt     |   8 +
 .../devicetree/bindings/clock/artpec6.txt          |  14 ++
 MAINTAINERS                                        |  10 +
 arch/arm/Kconfig                                   |   2 +
 arch/arm/Makefile                                  |   1 +
 arch/arm/boot/dts/Makefile                         |   2 +
 arch/arm/boot/dts/artpec6-devboard.dts             |  57 +++++
 arch/arm/boot/dts/artpec6.dtsi                     | 238 +++++++++++++++++++++
 arch/arm/configs/multi_v7_defconfig                |   2 +
 arch/arm/mach-artpec/Kconfig                       |  22 ++
 arch/arm/mach-artpec/Makefile                      |   1 +
 arch/arm/mach-artpec/board-artpec6.c               |  66 ++++++
 drivers/clk/Makefile                               |   1 +
 drivers/clk/clk-artpec6.c                          |  70 ++++++
 14 files changed, 494 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/axis.txt
 create mode 100644 Documentation/devicetree/bindings/clock/artpec6.txt
 create mode 100644 arch/arm/boot/dts/artpec6-devboard.dts
 create mode 100644 arch/arm/boot/dts/artpec6.dtsi
 create mode 100644 arch/arm/mach-artpec/Kconfig
 create mode 100644 arch/arm/mach-artpec/Makefile
 create mode 100644 arch/arm/mach-artpec/board-artpec6.c
 create mode 100644 drivers/clk/clk-artpec6.c

-- 
2.1.4



From lars.persson at axis.com  Wed Feb 10 04:41:52 2016
From: lars.persson at axis.com (Lars Persson)
Date: Wed, 10 Feb 2016 13:41:52 +0100
Subject: [PATCH 3/8] arm: add device-tree SoC bindings for Axis Artpec-6
In-Reply-To: <cover.1455107681.git.larper@axis.com>
References: <cover.1455107681.git.larper@axis.com>
Message-ID: <06f7e5ffdef7ba79b5702f063512010329c40cba.1455107681.git.larper@axis.com>

Signed-off-by: Lars Persson <larper at axis.com>
---
 Documentation/devicetree/bindings/arm/axis.txt | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/axis.txt

diff --git a/Documentation/devicetree/bindings/arm/axis.txt b/Documentation/devicetree/bindings/arm/axis.txt
new file mode 100644
index 0000000..4c98701
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/axis.txt
@@ -0,0 +1,8 @@
+Axis Communications AB
+ARTPEC series SoC Device Tree Bindings
+
+
+ARTPEC-6 ARM SoC
+
+Required root node properties:
+    - compatible = "axis,artpec6-dev-board", "axis,artpec6";
-- 
2.1.4



From lars.persson at axis.com  Wed Feb 10 04:41:50 2016
From: lars.persson at axis.com (Lars Persson)
Date: Wed, 10 Feb 2016 13:41:50 +0100
Subject: [PATCH 1/8] clk: add device tree binding for artpec-6 pll1 clock
In-Reply-To: <cover.1455107681.git.larper@axis.com>
References: <cover.1455107681.git.larper@axis.com>
Message-ID: <c092f501a595032f9b76f18fc4bf093503a181c8.1455107681.git.larper@axis.com>

Signed-off-by: Lars Persson <larper at axis.com>
---
 Documentation/devicetree/bindings/clock/artpec6.txt | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/artpec6.txt

diff --git a/Documentation/devicetree/bindings/clock/artpec6.txt b/Documentation/devicetree/bindings/clock/artpec6.txt
new file mode 100644
index 0000000..e50f7a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/artpec6.txt
@@ -0,0 +1,14 @@
+* Clock bindings for Axis ARTPEC-6 chip
+
+Required properties:
+- compatible: Should be "axis,artpec6-pll1-clock"
+- #clock-cells: Should be <1>
+
+Examples:
+
+pll1_clk: pll1_clk {
+	#clock-cells = <1>;
+	compatible = "axis,artpec6-pll1-clock";
+	clocks = <&ext_clk>;
+	status = "okay";
+};
-- 
2.1.4



From lars.persson at axis.com  Wed Feb 10 04:41:54 2016
From: lars.persson at axis.com (Lars Persson)
Date: Wed, 10 Feb 2016 13:41:54 +0100
Subject: [PATCH 5/8] arm: dts: add Artpec-6 development board dts
In-Reply-To: <cover.1455107681.git.larper@axis.com>
References: <cover.1455107681.git.larper@axis.com>
Message-ID: <a1015afcbd0a726915c674ad58425be951a4158f.1455107681.git.larper@axis.com>

Signed-off-by: Lars Persson <larper at axis.com>
---
 arch/arm/boot/dts/Makefile             |  2 ++
 arch/arm/boot/dts/artpec6-devboard.dts | 57 ++++++++++++++++++++++++++++++++++
 2 files changed, 59 insertions(+)
 create mode 100644 arch/arm/boot/dts/artpec6-devboard.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..2ebe99c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -2,6 +2,8 @@ ifeq ($(CONFIG_OF),y)
 
 dtb-$(CONFIG_ARCH_ALPINE) += \
 	alpine-db.dtb
+dtb-$(CONFIG_MACH_ARTPEC6) += \
+	artpec6-devboard.dtb
 dtb-$(CONFIG_MACH_ASM9260) += \
 	alphascale-asm9260-devkit.dtb
 # Keep at91 dtb files sorted alphabetically for each SoC
diff --git a/arch/arm/boot/dts/artpec6-devboard.dts b/arch/arm/boot/dts/artpec6-devboard.dts
new file mode 100644
index 0000000..f6c5e4f
--- /dev/null
+++ b/arch/arm/boot/dts/artpec6-devboard.dts
@@ -0,0 +1,57 @@
+/*
+ * Axis ARTPEC-6 development board.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "artpec6.dtsi"
+
+/ {
+	model = "ARTPEC-6 development board";
+	compatible = "axis,artpec6-dev-board", "axis,artpec6";
+
+	chosen {
+		stdout-path = "serial3:115200n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x0 0x10000000>;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart1 {
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&uart3 {
+	status = "okay";
+};
+
+&ethernet {
+	status = "okay";
+
+	phy-handle = <&phy1>;
+	phy-mode = "gmii";
+
+	mdio {
+		#address-cells = <0x1>;
+		#size-cells = <0x0>;
+		phy1: phy at 0 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			device_type = "ethernet-phy";
+			reg = <0x0>;
+		};
+	};
+};
-- 
2.1.4



From lars.persson at axis.com  Wed Feb 10 04:41:51 2016
From: lars.persson at axis.com (Lars Persson)
Date: Wed, 10 Feb 2016 13:41:51 +0100
Subject: [PATCH 2/8] clk: add artpec-6 pll1 clock driver
In-Reply-To: <cover.1455107681.git.larper@axis.com>
References: <cover.1455107681.git.larper@axis.com>
Message-ID: <30bfa3b9a237699a7a2078c51903238aa330b992.1455107681.git.larper@axis.com>

The PLL1 clock is a fixed-factor clock with factors derived from boot
mode pins. This driver is a simple wrapper to register the fixed
factor clock according to the pin settings.

Signed-off-by: Lars Persson <larper at axis.com>
---
 drivers/clk/Makefile      |  1 +
 drivers/clk/clk-artpec6.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 71 insertions(+)
 create mode 100644 drivers/clk/clk-artpec6.c

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index b038e36..388f0cf 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -17,6 +17,7 @@ endif
 
 # hardware specific clock types
 # please keep this section sorted lexicographically by file/directory path name
+obj-$(CONFIG_MACH_ARTPEC6)		+= clk-artpec6.o
 obj-$(CONFIG_MACH_ASM9260)		+= clk-asm9260.o
 obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)	+= clk-axi-clkgen.o
 obj-$(CONFIG_ARCH_AXXIA)		+= clk-axm5516.o
diff --git a/drivers/clk/clk-artpec6.c b/drivers/clk/clk-artpec6.c
new file mode 100644
index 0000000..3664c44
--- /dev/null
+++ b/drivers/clk/clk-artpec6.c
@@ -0,0 +1,70 @@
+/*
+ * ARTPEC-6 clock initialization
+ *
+ * Copyright 2015 Axis Comunications AB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+static void __init of_artpec6_pll1_setup(struct device_node *np)
+{
+	void __iomem *devstat;
+	struct clk *clk;
+	const char *clk_name = np->name;
+	const char *parent_name;
+	u32 pll_mode, pll_m, pll_n;
+
+	parent_name = of_clk_get_parent_name(np, 0);
+
+	devstat = of_iomap(np, 0);
+	if (devstat == NULL) {
+		pr_err("error to ioremap DEVSTAT\n");
+		return;
+	}
+
+	/* DEVSTAT register contains PLL settings */
+	pll_mode = (readl(devstat) >> 6) & 3;
+	iounmap(devstat);
+
+	/*
+	 * pll1 settings are designed for different DDR speeds using a fixed
+	 * 50MHz external clock. However, a different external clock could be
+	 * used on different boards.
+	 * CPU clock is half the DDR clock.
+	 */
+	switch (pll_mode) {
+	case 0: /* DDR3-2133 mode */
+		pll_m = 4;
+		pll_n = 85;
+		break;
+	case 1: /* DDR3-1866 mode */
+		pll_m = 6;
+		pll_n = 112;
+		break;
+	case 2: /* DDR3-1600 mode */
+		pll_m = 4;
+		pll_n = 64;
+		break;
+	case 3: /* DDR3-1333 mode */
+		pll_m = 8;
+		pll_n = 106;
+		break;
+	}
+	/* ext_clk is defined in device tree */
+	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
+			pll_n, pll_m);
+	if (IS_ERR(clk)) {
+		pr_err("%s not registered\n", clk_name);
+		return;
+	}
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+}
+CLK_OF_DECLARE(artpec6_pll1, "axis,artpec6-pll1-clock", of_artpec6_pll1_setup);
-- 
2.1.4



From lars.persson at axis.com  Wed Feb 10 04:41:53 2016
From: lars.persson at axis.com (Lars Persson)
Date: Wed, 10 Feb 2016 13:41:53 +0100
Subject: [PATCH 4/8] arm: dts: add Artpec-6 soc dtsi file
In-Reply-To: <cover.1455107681.git.larper@axis.com>
References: <cover.1455107681.git.larper@axis.com>
Message-ID: <733065957e9ec67d698870cf832b4641d0da30cb.1455107681.git.larper@axis.com>

Signed-off-by: Lars Persson <larper at axis.com>
---
 arch/arm/boot/dts/artpec6.dtsi | 238 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 238 insertions(+)
 create mode 100644 arch/arm/boot/dts/artpec6.dtsi

diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/arm/boot/dts/artpec6.dtsi
new file mode 100644
index 0000000..c1790d8
--- /dev/null
+++ b/arch/arm/boot/dts/artpec6.dtsi
@@ -0,0 +1,238 @@
+/*
+ * Device Tree Source for the Axis ARTPEC-6 SoC
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "skeleton.dtsi"
+
+/ {
+	compatible = "axis,artpec6";
+	interrupt-parent = <&intc>;
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+			next-level-cache = <&pl310>;
+		};
+
+		cpu1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <1>;
+			next-level-cache = <&pl310>;
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2", "arm,psci";
+		method = "smc";
+		psci_version = <0x84000000>;
+		cpu_on = <0x84000003>;
+		system_reset = <0x84000009>;
+	};
+
+	scu at faf00000 {
+		compatible = "arm,cortex-a9-scu";
+		reg = <0xfaf00000 0x58>;
+	};
+
+	/* Main external clock driving CPU and peripherals */
+	ext_clk: ext_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <50000000>;
+	};
+
+	/* PLL1 is used by CPU and some peripherals */
+	pll1_clk: pll1_clk at f8000000 {
+		#clock-cells = <0>;
+		compatible = "axis,artpec6-pll1-clock";
+		reg = <0xf8000000 4>;
+		clocks = <&ext_clk>;
+	};
+
+	cpu_clk: cpu_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&pll1_clk>;
+		clock-output-names = "cpu_clk";
+	};
+
+	cpu_clkdiv2: cpu_clkdiv2 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <2>;
+		clock-mult = <1>;
+		clocks = <&cpu_clk>;
+	};
+
+	cpu_clkdiv4: cpu_clkdiv4 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <4>;
+		clock-mult = <1>;
+		clocks = <&cpu_clk>;
+	};
+
+	apb_pclk: apb_pclk {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <8>;
+		clock-mult = <1>;
+		clocks = <&cpu_clk>;
+		clock-output-names = "apb_pclk";
+	};
+
+	/* PLL2 is used by a number of peripherals, including UDL */
+	pll2: pll2 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <24>;
+		clocks = <&ext_clk>;
+	};
+
+	/* PLL2DIV2 is used by the Fractional Clock Divider, for i2s */
+	pll2div2: pll2div2 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <2>;
+		clock-mult = <1>;
+		clocks = <&pll2>;
+	};
+
+	pll2div12: pll2div12 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <12>;
+		clock-mult = <1>;
+		clocks = <&pll2>;
+	};
+
+	pll2div24: pll2div24 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <24>;
+		clock-mult = <1>;
+		clocks = <&pll2>;
+		clock-output-names = "uart_clk";
+	};
+
+
+	gtimer at faf00200 {
+		compatible = "arm,cortex-a9-global-timer";
+		reg = <0xfaf00200 0x20>;
+		interrupts = <GIC_PPI 11 0xf01>;
+		clocks = <&cpu_clkdiv2>;
+	};
+
+	timer at faf00600 {
+		compatible = "arm,cortex-a9-twd-timer";
+		reg = <0xfaf00600 0x20>;
+		interrupts = <GIC_PPI 13 0xf04>;
+		clocks = <&cpu_clkdiv2>;
+		status = "disabled";
+	};
+
+	intc: interrupt-controller at faf01000 {
+		interrupt-controller;
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		reg = < 0xfaf01000 0x1000 >, < 0xfaf00100 0x0100 >;
+	};
+
+	pl310: cache-controller at faf10000 {
+		compatible = "arm,pl310-cache";
+		cache-unified;
+		cache-level = <2>;
+		reg = <0xfaf10000 0x1000>;
+		interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+		arm,data-latency = <1 1 1>;
+		arm,tag-latency = <1 1 1>;
+		arm,filter-ranges = <0x0 0x80000000>;
+	};
+
+	pmu {
+		compatible = "arm,cortex-a9-pmu";
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			<GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-parent = <&intc>;
+	};
+
+	amba at 0 {
+		compatible = "simple-bus";
+		#address-cells = <0x1>;
+		#size-cells = <0x1>;
+		interrupt-parent = <&intc>;
+		ranges;
+		dma-ranges = <0x80000000 0x00000000 0x40000000>;
+		dma-coherent;
+
+		ethernet: ethernet at f8010000 {
+			clock-names = "phy_ref_clk", "apb_pclk";
+			clocks = <&ext_clk>, <&apb_pclk>;
+			compatible = "snps,dwc-qos-ethernet-4.10";
+			interrupt-parent = <&intc>;
+			interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+			reg = <0xf8010000 0x4000>;
+
+			snps,write-requests = <2>;
+			snps,read-requests = <16>;
+			snps,txpbl = <8>;
+			snps,rxpbl = <2>;
+
+			status = "disabled";
+		};
+
+		uart0: uart at f8036000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xf8036000 0x1000>;
+			interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pll2div24>, <&apb_pclk>;
+			clock-names = "uart_clk", "apb_pclk";
+			status = "disabled";
+		};
+		uart1: uart at f8037000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xf8037000 0x1000>;
+			interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pll2div24>, <&apb_pclk>;
+			clock-names = "uart_clk", "apb_pclk";
+			status = "disabled";
+		};
+		uart2: uart at f8038000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xf8038000 0x1000>;
+			interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pll2div24>, <&apb_pclk>;
+			clock-names = "uart_clk", "apb_pclk";
+			status = "disabled";
+		};
+		uart3: uart at f8039000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xf8039000 0x1000>;
+			interrupts = <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pll2div24>, <&apb_pclk>;
+			clock-names = "uart_clk", "apb_pclk";
+			status = "disabled";
+		};
+	};
+};
-- 
2.1.4



From lars.persson at axis.com  Wed Feb 10 04:41:57 2016
From: lars.persson at axis.com (Lars Persson)
Date: Wed, 10 Feb 2016 13:41:57 +0100
Subject: [PATCH 8/8] arm: mach-artpec: add entry to MAINTAINERS
In-Reply-To: <cover.1455107681.git.larper@axis.com>
References: <cover.1455107681.git.larper@axis.com>
Message-ID: <0b705a87e60c75c71721f3cf013b544eea746a95.1455107681.git.larper@axis.com>

Signed-off-by: Lars Persson <larper at axis.com>
Signed-off-by: Jesper Nilsson <jesper.nilsson at axis.com>
---
 MAINTAINERS | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7f1fa4f..d32c1aa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -932,6 +932,16 @@ M:	Tsahee Zidenberg <tsahee at annapurnalabs.com>
 S:	Maintained
 F:	arch/arm/mach-alpine/
 
+ARM/ARTPEC MACHINE SUPPORT
+M:	Jesper Nilsson <jesper.nilsson at axis.com>
+M:	Lars Persson <lars.persson at axis.com>
+M:	Niklas Cassel <niklas.cassel at axis.com>
+S:	Maintained
+L:	linux-arm-kernel at axis.com
+F:	arch/arm/mach-artpec
+F:	arch/arm/boot/dts/artpec6*
+F:	drivers/clk/clk-artpec6.c
+
 ARM/ATMEL AT91RM9200, AT91SAM9 AND SAMA5 SOC SUPPORT
 M:	Nicolas Ferre <nicolas.ferre at atmel.com>
 M:	Alexandre Belloni <alexandre.belloni at free-electrons.com>
-- 
2.1.4



From lars.persson at axis.com  Wed Feb 10 04:41:56 2016
From: lars.persson at axis.com (Lars Persson)
Date: Wed, 10 Feb 2016 13:41:56 +0100
Subject: [PATCH 7/8] arm: multi_v7_defconfig: add MACH_ARTPEC6
In-Reply-To: <cover.1455107681.git.larper@axis.com>
References: <cover.1455107681.git.larper@axis.com>
Message-ID: <36d8a6a0236e08bc7286085018e2fa7a67691b39.1455107681.git.larper@axis.com>

Signed-off-by: Lars Persson <larper at axis.com>
---
 arch/arm/configs/multi_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 8e8b2ac..bf3840e 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -16,6 +16,8 @@ CONFIG_ARCH_MULTI_V7=y
 # CONFIG_ARCH_MULTI_V4 is not set
 CONFIG_ARCH_VIRT=y
 CONFIG_ARCH_ALPINE=y
+CONFIG_ARCH_ARTPEC=y
+CONFIG_MACH_ARTPEC6=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_375=y
-- 
2.1.4



From lars.persson at axis.com  Wed Feb 10 04:41:55 2016
From: lars.persson at axis.com (Lars Persson)
Date: Wed, 10 Feb 2016 13:41:55 +0100
Subject: [PATCH 6/8] arm: initial machine port for artpec-6 SoC
In-Reply-To: <cover.1455107681.git.larper@axis.com>
References: <cover.1455107681.git.larper@axis.com>
Message-ID: <fa3483f1a388e443245084c3b5e9aa1ad2f61392.1455107681.git.larper@axis.com>

Basic machine port for the Artpec-6 SoC from Axis
Communications.

Signed-off-by: Lars Persson <larper at axis.com>
---
 arch/arm/Kconfig                     |  2 ++
 arch/arm/Makefile                    |  1 +
 arch/arm/mach-artpec/Kconfig         | 22 ++++++++++++
 arch/arm/mach-artpec/Makefile        |  1 +
 arch/arm/mach-artpec/board-artpec6.c | 66 ++++++++++++++++++++++++++++++++++++
 5 files changed, 92 insertions(+)
 create mode 100644 arch/arm/mach-artpec/Kconfig
 create mode 100644 arch/arm/mach-artpec/Makefile
 create mode 100644 arch/arm/mach-artpec/board-artpec6.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4f799e5..e1565dd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -724,6 +724,8 @@ source "arch/arm/mach-mvebu/Kconfig"
 
 source "arch/arm/mach-alpine/Kconfig"
 
+source "arch/arm/mach-artpec/Kconfig"
+
 source "arch/arm/mach-asm9260/Kconfig"
 
 source "arch/arm/mach-at91/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index fe25410..4eb24c6 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -154,6 +154,7 @@ textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
 # Machine directory name.  This list is sorted alphanumerically
 # by CONFIG_* macro name.
 machine-$(CONFIG_ARCH_ALPINE)		+= alpine
+machine-$(CONFIG_ARCH_ARTPEC)		+= artpec
 machine-$(CONFIG_ARCH_AT91)		+= at91
 machine-$(CONFIG_ARCH_AXXIA)		+= axxia
 machine-$(CONFIG_ARCH_BCM)		+= bcm
diff --git a/arch/arm/mach-artpec/Kconfig b/arch/arm/mach-artpec/Kconfig
new file mode 100644
index 0000000..eaa73d6
--- /dev/null
+++ b/arch/arm/mach-artpec/Kconfig
@@ -0,0 +1,22 @@
+menuconfig ARCH_ARTPEC
+	bool "Axis Communications ARM based ARTPEC SoCs" if ARCH_MULTI_V7
+
+if ARCH_ARTPEC
+
+config MACH_ARTPEC6
+	bool "Axis ARTPEC-6 ARM Cortex A9 Platform" if ARCH_MULTI_V7
+	select ARM_AMBA
+	select ARM_GIC
+	select ARM_GLOBAL_TIMER
+	select ARM_PSCI
+	select COMMON_CLK
+	select GENERIC_CLOCKEVENTS
+	select HAVE_ARM_ARCH_TIMER
+	select HAVE_ARM_SCU
+	select HAVE_ARM_TWD if SMP
+	select SPARSE_IRQ
+	select USE_OF
+	help
+	  Support for Axis ARTPEC-6 ARM Cortex A9 Platform
+
+endif
diff --git a/arch/arm/mach-artpec/Makefile b/arch/arm/mach-artpec/Makefile
new file mode 100644
index 0000000..78325f0
--- /dev/null
+++ b/arch/arm/mach-artpec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MACH_ARTPEC6)		:= board-artpec6.o
diff --git a/arch/arm/mach-artpec/board-artpec6.c b/arch/arm/mach-artpec/board-artpec6.c
new file mode 100644
index 0000000..6d7a59f
--- /dev/null
+++ b/arch/arm/mach-artpec/board-artpec6.c
@@ -0,0 +1,66 @@
+/*
+ * ARTPEC-6 device support.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/amba/bus.h>
+#include <linux/clocksource.h>
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/of_platform.h>
+#include <linux/of.h>
+#include <linux/clk-provider.h>
+#include <linux/smp.h>
+#include <asm/smp_scu.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/psci.h>
+#include <linux/arm-smccc.h>
+
+#define ARTPEC6_DMACFG 0xf8000010
+#define ARTPEC6_DMACFG_UARTS_BURST 0xff
+
+#define SECURE_OP_L2C_WRITEREG 0xb4000001
+
+static void __init artpec6_init_machine(void)
+{
+	void __iomem *dmacfg;
+
+	/* Use PL011 DMA Burst Request signal instead of DMA Single Request */
+	dmacfg = ioremap(ARTPEC6_DMACFG, 4);
+	if (dmacfg) {
+		__raw_writel(ARTPEC6_DMACFG_UARTS_BURST, dmacfg);
+		iounmap(dmacfg);
+	}
+
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static void artpec6_l2c310_write_sec(unsigned long val, unsigned reg)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_smc(SECURE_OP_L2C_WRITEREG, reg, val, 0,
+		      0, 0, 0, 0, &res);
+
+	WARN_ON(res.a0);
+}
+
+static const char * const artpec6_dt_match[] = {
+	"axis,artpec6",
+	NULL
+};
+
+DT_MACHINE_START(ARTPEC6, "Axis ARTPEC-6 Platform")
+	.l2c_aux_val	= 0x0C000000,
+	.l2c_aux_mask	= 0xF3FFFFFF,
+	.l2c_write_sec  = artpec6_l2c310_write_sec,
+	.init_irq	= irqchip_init,
+	.init_machine	= artpec6_init_machine,
+	.dt_compat	= artpec6_dt_match,
+MACHINE_END
-- 
2.1.4



From christoffer.dall at linaro.org  Wed Feb 10 04:44:28 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 10 Feb 2016 13:44:28 +0100
Subject: [PATCH 1/8] arm64: KVM: Switch the sys_reg search to be a binary
 search
In-Reply-To: <1454931622-14902-2-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <1454931622-14902-2-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160210124428.GH5171@cbox>

On Mon, Feb 08, 2016 at 11:40:15AM +0000, Marc Zyngier wrote:
> Our 64bit sys_reg table is about 90 entries long (so far, and the
> PMU support is likely to increase this). This means that on average,
> it takes 45 comparaisons to find the right entry (and actually the
> full 90 if we have to search the invariant table).
> 
> Not the most efficient thing. Specially when you think that this
> table is already sorted. Switching to a binary search effectively
> reduces the search to about 7 comparaisons. Slightly better!
> 
> As an added bonus, the comparaison is done by comparing all the

s/comparaison/comparison/

> fields at once, instead of one at a time.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Wed Feb 10 04:44:36 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 10 Feb 2016 13:44:36 +0100
Subject: [PATCH 2/8] ARM: KVM: Properly sort the invariant table
In-Reply-To: <1454931622-14902-3-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <1454931622-14902-3-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160210124436.GI5171@cbox>

On Mon, Feb 08, 2016 at 11:40:16AM +0000, Marc Zyngier wrote:
> Not having the invariant table properly sorted is an oddity, and
> may get in the way of future optimisations. Let's fix it.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Wed Feb 10 04:44:42 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 10 Feb 2016 13:44:42 +0100
Subject: [PATCH 3/8] ARM: KVM: Enforce sorting of all CP tables
In-Reply-To: <1454931622-14902-4-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <1454931622-14902-4-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160210124442.GJ5171@cbox>

On Mon, Feb 08, 2016 at 11:40:17AM +0000, Marc Zyngier wrote:
> Since we're obviously terrible at sorting the CP tables, make sure
> we're going to do it properly (or fail to boot). arm64 has had the
> same mechanism for a while, and nobody ever broke it...
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Wed Feb 10 04:44:47 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 10 Feb 2016 13:44:47 +0100
Subject: [PATCH 5/8] ARM: KVM: Switch the CP reg search to be a binary
 search
In-Reply-To: <1454931622-14902-6-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <1454931622-14902-6-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160210124447.GK5171@cbox>

On Mon, Feb 08, 2016 at 11:40:19AM +0000, Marc Zyngier wrote:
> Doing a linear search is a bit silly when we can do a binary search.
> Not that we trap that so many things that it has become a burden yet,
> but it makes sense to align it with the arm64 code.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Wed Feb 10 04:44:52 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 10 Feb 2016 13:44:52 +0100
Subject: [PATCH 4/8] ARM: KVM: Rename struct coproc_reg::is_64 to is_64bit
In-Reply-To: <1454931622-14902-5-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <1454931622-14902-5-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160210124452.GL5171@cbox>

On Mon, Feb 08, 2016 at 11:40:18AM +0000, Marc Zyngier wrote:
> As we're going to play some tricks on the struct coproc_reg,
> make sure its 64bit indicator field matches that of coproc_params.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Wed Feb 10 04:44:59 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 10 Feb 2016 13:44:59 +0100
Subject: [PATCH 6/8] KVM: arm/arm64: timer: Add active state caching
In-Reply-To: <1454931622-14902-7-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <1454931622-14902-7-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160210124459.GM5171@cbox>

On Mon, Feb 08, 2016 at 11:40:20AM +0000, Marc Zyngier wrote:
> Programming the active state in the (re)distributor can be an
> expensive operation so it makes some sense to try and reduce
> the number of accesses as much as possible. So far, we
> program the active state on each VM entry, but there is some
> opportunity to do less.
> 
> An obvious solution is to cache the active state in memory,
> and only program it in the HW when conditions change. But
> because the HW can also change things under our feet (the active
> state can transition from 1 to 0 when the guest does an EOI),
> some precautions have to be taken, which amount to only caching
> an "inactive" state, and always programing it otherwise.
> 
> With this in place, we observe a reduction of around 700 cycles
> on a 2GHz GICv2 platform for a NULL hypercall.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Wed Feb 10 04:45:06 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 10 Feb 2016 13:45:06 +0100
Subject: [PATCH 7/8] KVM: arm/arm64: Avoid accessing GICH registers
In-Reply-To: <1454931622-14902-8-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <1454931622-14902-8-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160210124506.GN5171@cbox>

On Mon, Feb 08, 2016 at 11:40:21AM +0000, Marc Zyngier wrote:
> GICv2 registers are *slow*. As in "terrifyingly slow". Which is bad.
> But we're equaly bad, as we make a point in accessing them even if
> we don't have any interrupt in flight.
> 
> A good solution is to first find out if we have anything useful to
> write into the GIC, and if we don't, to simply not do it. This
> involves tracking which LRs actually have something valid there.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/hyp/vgic-v2-sr.c | 71 ++++++++++++++++++++++++++++-------------
>  include/kvm/arm_vgic.h          |  2 ++
>  2 files changed, 51 insertions(+), 22 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/vgic-v2-sr.c b/arch/arm64/kvm/hyp/vgic-v2-sr.c
> index e717612..874a08d 100644
> --- a/arch/arm64/kvm/hyp/vgic-v2-sr.c
> +++ b/arch/arm64/kvm/hyp/vgic-v2-sr.c
> @@ -38,28 +38,40 @@ void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
>  
>  	nr_lr = vcpu->arch.vgic_cpu.nr_lr;
>  	cpu_if->vgic_vmcr = readl_relaxed(base + GICH_VMCR);
> -	cpu_if->vgic_misr = readl_relaxed(base + GICH_MISR);
> -	eisr0  = readl_relaxed(base + GICH_EISR0);
> -	elrsr0 = readl_relaxed(base + GICH_ELRSR0);
> -	if (unlikely(nr_lr > 32)) {
> -		eisr1  = readl_relaxed(base + GICH_EISR1);
> -		elrsr1 = readl_relaxed(base + GICH_ELRSR1);
> -	} else {
> -		eisr1 = elrsr1 = 0;
> -	}
> +
> +	if (vcpu->arch.vgic_cpu.live_lrs) {
> +		eisr0  = readl_relaxed(base + GICH_EISR0);
> +		elrsr0 = readl_relaxed(base + GICH_ELRSR0);
> +		cpu_if->vgic_misr = readl_relaxed(base + GICH_MISR);
> +		cpu_if->vgic_apr    = readl_relaxed(base + GICH_APR);
> +
> +		if (unlikely(nr_lr > 32)) {
> +			eisr1  = readl_relaxed(base + GICH_EISR1);
> +			elrsr1 = readl_relaxed(base + GICH_ELRSR1);
> +		} else {
> +			eisr1 = elrsr1 = 0;
> +		}
> +
>  #ifdef CONFIG_CPU_BIG_ENDIAN
> -	cpu_if->vgic_eisr  = ((u64)eisr0 << 32) | eisr1;
> -	cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
> +		cpu_if->vgic_eisr  = ((u64)eisr0 << 32) | eisr1;
> +		cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
>  #else
> -	cpu_if->vgic_eisr  = ((u64)eisr1 << 32) | eisr0;
> -	cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
> +		cpu_if->vgic_eisr  = ((u64)eisr1 << 32) | eisr0;
> +		cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
>  #endif
> -	cpu_if->vgic_apr    = readl_relaxed(base + GICH_APR);
>  
> -	writel_relaxed(0, base + GICH_HCR);
> +		for (i = 0; i < nr_lr; i++)
> +			if (vcpu->arch.vgic_cpu.live_lrs & (1UL << i))
> +				cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
>  
> -	for (i = 0; i < nr_lr; i++)
> -		cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
> +		writel_relaxed(0, base + GICH_HCR);
> +
> +		vcpu->arch.vgic_cpu.live_lrs = 0;
> +	} else {
> +		cpu_if->vgic_eisr = 0;
> +		cpu_if->vgic_elrsr = ~0UL;
> +		cpu_if->vgic_misr = 0;
> +	}
>  }
>  
>  /* vcpu is already in the HYP VA space */
> @@ -70,15 +82,30 @@ void __hyp_text __vgic_v2_restore_state(struct kvm_vcpu *vcpu)
>  	struct vgic_dist *vgic = &kvm->arch.vgic;
>  	void __iomem *base = kern_hyp_va(vgic->vctrl_base);
>  	int i, nr_lr;
> +	u64 live_lrs = 0;
>  
>  	if (!base)
>  		return;
>  
> -	writel_relaxed(cpu_if->vgic_hcr, base + GICH_HCR);
> -	writel_relaxed(cpu_if->vgic_vmcr, base + GICH_VMCR);
> -	writel_relaxed(cpu_if->vgic_apr, base + GICH_APR);
> -
>  	nr_lr = vcpu->arch.vgic_cpu.nr_lr;
> +
>  	for (i = 0; i < nr_lr; i++)
> -		writel_relaxed(cpu_if->vgic_lr[i], base + GICH_LR0 + (i * 4));
> +		if (cpu_if->vgic_lr[i] & GICH_LR_STATE)
> +			live_lrs |= 1UL << i;
> +
> +	if (live_lrs) {
> +		writel_relaxed(cpu_if->vgic_hcr, base + GICH_HCR);
> +		writel_relaxed(cpu_if->vgic_apr, base + GICH_APR);
> +		for (i = 0; i < nr_lr; i++) {
> +			u32 val = 0;
> +
> +			if (live_lrs & (1UL << i))
> +				val = cpu_if->vgic_lr[i];
> +
> +			writel_relaxed(val, base + GICH_LR0 + (i * 4));
> +		}
> +	}
> +
> +	writel_relaxed(cpu_if->vgic_vmcr, base + GICH_VMCR);

couldn't you optimize this out by storing the last read value and
compare if anything changed?  (you'd have to invalidate the cached value
on vcpu_put obviously).

> +	vcpu->arch.vgic_cpu.live_lrs = live_lrs;
>  }
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index 13a3d53..f473fd6 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -321,6 +321,8 @@ struct vgic_cpu {
>  
>  	/* Protected by the distributor's irq_phys_map_lock */
>  	struct list_head	irq_phys_map_list;
> +
> +	u64		live_lrs;
>  };
>  
>  #define LR_EMPTY	0xff
> -- 
> 2.1.4
> 

Otherwise:

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Wed Feb 10 04:45:13 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 10 Feb 2016 13:45:13 +0100
Subject: [PATCH 8/8] KVM: arm64: Avoid accessing ICH registers
In-Reply-To: <1454931622-14902-9-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <1454931622-14902-9-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160210124513.GO5171@cbox>

On Mon, Feb 08, 2016 at 11:40:22AM +0000, Marc Zyngier wrote:
> Just like on GICv2, we're a bit hammer-happy with GICv3, and access
> them more often than we should.
> 
> Adopt a policy similar to what we do for GICv2, only save/restoring
> the minimal set of registers. As we don't access the registers
> linearly anymore (we may skip some), the convoluted accessors become
> slightly simpler, and we can drop the ugly indexing macro that
> tended to confuse the reviewers.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/hyp/vgic-v3-sr.c | 288 ++++++++++++++++++++++++----------------
>  include/kvm/arm_vgic.h          |   6 -
>  virt/kvm/arm/vgic-v3.c          |   4 +-
>  3 files changed, 176 insertions(+), 122 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
> index 9142e082..d3813f5 100644
> --- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
> +++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
> @@ -39,12 +39,104 @@
>  		asm volatile("msr_s " __stringify(r) ", %0" : : "r" (__val));\
>  	} while (0)
>  
> -/* vcpu is already in the HYP VA space */
> +static u64 __hyp_text __gic_v3_get_lr(unsigned int lr)
> +{
> +	switch (lr & 0xf) {
> +	case 0:
> +		return read_gicreg(ICH_LR0_EL2);
> +	case 1:
> +		return read_gicreg(ICH_LR1_EL2);
> +	case 2:
> +		return read_gicreg(ICH_LR2_EL2);
> +	case 3:
> +		return read_gicreg(ICH_LR3_EL2);
> +	case 4:
> +		return read_gicreg(ICH_LR4_EL2);
> +	case 5:
> +		return read_gicreg(ICH_LR5_EL2);
> +	case 6:
> +		return read_gicreg(ICH_LR6_EL2);
> +	case 7:
> +		return read_gicreg(ICH_LR7_EL2);
> +	case 8:
> +		return read_gicreg(ICH_LR8_EL2);
> +	case 9:
> +		return read_gicreg(ICH_LR9_EL2);
> +	case 10:
> +		return read_gicreg(ICH_LR10_EL2);
> +	case 11:
> +		return read_gicreg(ICH_LR11_EL2);
> +	case 12:
> +		return read_gicreg(ICH_LR12_EL2);
> +	case 13:
> +		return read_gicreg(ICH_LR13_EL2);
> +	case 14:
> +		return read_gicreg(ICH_LR14_EL2);
> +	case 15:
> +		return read_gicreg(ICH_LR15_EL2);
> +	}
> +
> +	unreachable();
> +}
> +
> +static void __hyp_text __gic_v3_set_lr(u64 val, int lr)
> +{
> +	switch (lr & 0xf) {
> +	case 0:
> +		write_gicreg(val, ICH_LR0_EL2);
> +		break;
> +	case 1:
> +		write_gicreg(val, ICH_LR1_EL2);
> +		break;
> +	case 2:
> +		write_gicreg(val, ICH_LR2_EL2);
> +		break;
> +	case 3:
> +		write_gicreg(val, ICH_LR3_EL2);
> +		break;
> +	case 4:
> +		write_gicreg(val, ICH_LR4_EL2);
> +		break;
> +	case 5:
> +		write_gicreg(val, ICH_LR5_EL2);
> +		break;
> +	case 6:
> +		write_gicreg(val, ICH_LR6_EL2);
> +		break;
> +	case 7:
> +		write_gicreg(val, ICH_LR7_EL2);
> +		break;
> +	case 8:
> +		write_gicreg(val, ICH_LR8_EL2);
> +		break;
> +	case 9:
> +		write_gicreg(val, ICH_LR9_EL2);
> +		break;
> +	case 10:
> +		write_gicreg(val, ICH_LR10_EL2);
> +		break;
> +	case 11:
> +		write_gicreg(val, ICH_LR11_EL2);
> +		break;
> +	case 12:
> +		write_gicreg(val, ICH_LR12_EL2);
> +		break;
> +	case 13:
> +		write_gicreg(val, ICH_LR13_EL2);
> +		break;
> +	case 14:
> +		write_gicreg(val, ICH_LR14_EL2);
> +		break;
> +	case 15:
> +		write_gicreg(val, ICH_LR15_EL2);
> +		break;
> +	}
> +}
> +
>  void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
>  {
>  	struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
>  	u64 val;
> -	u32 max_lr_idx, nr_pri_bits;
>  
>  	/*
>  	 * Make sure stores to the GIC via the memory mapped interface
> @@ -53,68 +145,50 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
>  	dsb(st);
>  
>  	cpu_if->vgic_vmcr  = read_gicreg(ICH_VMCR_EL2);
> -	cpu_if->vgic_misr  = read_gicreg(ICH_MISR_EL2);
> -	cpu_if->vgic_eisr  = read_gicreg(ICH_EISR_EL2);
> -	cpu_if->vgic_elrsr = read_gicreg(ICH_ELSR_EL2);
>  
> -	write_gicreg(0, ICH_HCR_EL2);
> -	val = read_gicreg(ICH_VTR_EL2);
> -	max_lr_idx = vtr_to_max_lr_idx(val);
> -	nr_pri_bits = vtr_to_nr_pri_bits(val);
> +	if (vcpu->arch.vgic_cpu.live_lrs) {
> +		int i;
> +		u32 max_lr_idx, nr_pri_bits;
>  
> -	switch (max_lr_idx) {
> -	case 15:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(15)] = read_gicreg(ICH_LR15_EL2);
> -	case 14:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(14)] = read_gicreg(ICH_LR14_EL2);
> -	case 13:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(13)] = read_gicreg(ICH_LR13_EL2);
> -	case 12:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(12)] = read_gicreg(ICH_LR12_EL2);
> -	case 11:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(11)] = read_gicreg(ICH_LR11_EL2);
> -	case 10:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(10)] = read_gicreg(ICH_LR10_EL2);
> -	case 9:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(9)] = read_gicreg(ICH_LR9_EL2);
> -	case 8:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(8)] = read_gicreg(ICH_LR8_EL2);
> -	case 7:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(7)] = read_gicreg(ICH_LR7_EL2);
> -	case 6:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(6)] = read_gicreg(ICH_LR6_EL2);
> -	case 5:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(5)] = read_gicreg(ICH_LR5_EL2);
> -	case 4:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(4)] = read_gicreg(ICH_LR4_EL2);
> -	case 3:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(3)] = read_gicreg(ICH_LR3_EL2);
> -	case 2:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(2)] = read_gicreg(ICH_LR2_EL2);
> -	case 1:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(1)] = read_gicreg(ICH_LR1_EL2);
> -	case 0:
> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(0)] = read_gicreg(ICH_LR0_EL2);
> -	}
> +		cpu_if->vgic_misr  = read_gicreg(ICH_MISR_EL2);
> +		cpu_if->vgic_eisr  = read_gicreg(ICH_EISR_EL2);
> +		cpu_if->vgic_elrsr = read_gicreg(ICH_ELSR_EL2);
>  
> -	switch (nr_pri_bits) {
> -	case 7:
> -		cpu_if->vgic_ap0r[3] = read_gicreg(ICH_AP0R3_EL2);
> -		cpu_if->vgic_ap0r[2] = read_gicreg(ICH_AP0R2_EL2);
> -	case 6:
> -		cpu_if->vgic_ap0r[1] = read_gicreg(ICH_AP0R1_EL2);
> -	default:
> -		cpu_if->vgic_ap0r[0] = read_gicreg(ICH_AP0R0_EL2);
> -	}
> +		write_gicreg(0, ICH_HCR_EL2);
> +		val = read_gicreg(ICH_VTR_EL2);

can't we cache the read of ICH_VTR_EL2 then?

> +		max_lr_idx = vtr_to_max_lr_idx(val);
> +		nr_pri_bits = vtr_to_nr_pri_bits(val);
>  
> -	switch (nr_pri_bits) {
> -	case 7:
> -		cpu_if->vgic_ap1r[3] = read_gicreg(ICH_AP1R3_EL2);
> -		cpu_if->vgic_ap1r[2] = read_gicreg(ICH_AP1R2_EL2);
> -	case 6:
> -		cpu_if->vgic_ap1r[1] = read_gicreg(ICH_AP1R1_EL2);
> -	default:
> -		cpu_if->vgic_ap1r[0] = read_gicreg(ICH_AP1R0_EL2);
> +		for (i = 0; i <= max_lr_idx; i++) {
> +			if (vcpu->arch.vgic_cpu.live_lrs & (1UL << i))
> +				cpu_if->vgic_lr[i] = __gic_v3_get_lr(i);
> +		}
> +
> +		switch (nr_pri_bits) {
> +		case 7:
> +			cpu_if->vgic_ap0r[3] = read_gicreg(ICH_AP0R3_EL2);
> +			cpu_if->vgic_ap0r[2] = read_gicreg(ICH_AP0R2_EL2);
> +		case 6:
> +			cpu_if->vgic_ap0r[1] = read_gicreg(ICH_AP0R1_EL2);
> +		default:
> +			cpu_if->vgic_ap0r[0] = read_gicreg(ICH_AP0R0_EL2);
> +		}
> +
> +		switch (nr_pri_bits) {
> +		case 7:
> +			cpu_if->vgic_ap1r[3] = read_gicreg(ICH_AP1R3_EL2);
> +			cpu_if->vgic_ap1r[2] = read_gicreg(ICH_AP1R2_EL2);
> +		case 6:
> +			cpu_if->vgic_ap1r[1] = read_gicreg(ICH_AP1R1_EL2);
> +		default:
> +			cpu_if->vgic_ap1r[0] = read_gicreg(ICH_AP1R0_EL2);
> +		}
> +
> +		vcpu->arch.vgic_cpu.live_lrs = 0;
> +	} else {
> +		cpu_if->vgic_misr  = 0;
> +		cpu_if->vgic_eisr  = 0;
> +		cpu_if->vgic_elrsr = 0xffff;
>  	}
>  
>  	val = read_gicreg(ICC_SRE_EL2);
> @@ -128,6 +202,8 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
>  	struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
>  	u64 val;
>  	u32 max_lr_idx, nr_pri_bits;
> +	u16 live_lrs = 0;
> +	int i;
>  
>  	/*
>  	 * VFIQEn is RES1 if ICC_SRE_EL1.SRE is 1. This causes a
> @@ -140,68 +216,51 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
>  	write_gicreg(cpu_if->vgic_sre, ICC_SRE_EL1);
>  	isb();
>  
> -	write_gicreg(cpu_if->vgic_hcr, ICH_HCR_EL2);
> -	write_gicreg(cpu_if->vgic_vmcr, ICH_VMCR_EL2);
> -
>  	val = read_gicreg(ICH_VTR_EL2);

same as above

>  	max_lr_idx = vtr_to_max_lr_idx(val);
>  	nr_pri_bits = vtr_to_nr_pri_bits(val);
>  
> -	switch (nr_pri_bits) {
> -	case 7:
> -		 write_gicreg(cpu_if->vgic_ap1r[3], ICH_AP1R3_EL2);
> -		 write_gicreg(cpu_if->vgic_ap1r[2], ICH_AP1R2_EL2);
> -	case 6:
> -		 write_gicreg(cpu_if->vgic_ap1r[1], ICH_AP1R1_EL2);
> -	default:
> -		 write_gicreg(cpu_if->vgic_ap1r[0], ICH_AP1R0_EL2);
> -	}	 	                           
> -		 	                           
> -	switch (nr_pri_bits) {
> -	case 7:
> -		 write_gicreg(cpu_if->vgic_ap0r[3], ICH_AP0R3_EL2);
> -		 write_gicreg(cpu_if->vgic_ap0r[2], ICH_AP0R2_EL2);
> -	case 6:
> -		 write_gicreg(cpu_if->vgic_ap0r[1], ICH_AP0R1_EL2);
> -	default:
> -		 write_gicreg(cpu_if->vgic_ap0r[0], ICH_AP0R0_EL2);
> +	for (i = 0; i <= max_lr_idx; i++) {
> +		if (cpu_if->vgic_lr[i] & ICH_LR_STATE)
> +			live_lrs |= (1 << i);
>  	}
>  
> -	switch (max_lr_idx) {
> -	case 15:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(15)], ICH_LR15_EL2);
> -	case 14:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(14)], ICH_LR14_EL2);
> -	case 13:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(13)], ICH_LR13_EL2);
> -	case 12:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(12)], ICH_LR12_EL2);
> -	case 11:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(11)], ICH_LR11_EL2);
> -	case 10:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(10)], ICH_LR10_EL2);
> -	case 9:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(9)], ICH_LR9_EL2);
> -	case 8:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(8)], ICH_LR8_EL2);
> -	case 7:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(7)], ICH_LR7_EL2);
> -	case 6:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(6)], ICH_LR6_EL2);
> -	case 5:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(5)], ICH_LR5_EL2);
> -	case 4:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(4)], ICH_LR4_EL2);
> -	case 3:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(3)], ICH_LR3_EL2);
> -	case 2:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(2)], ICH_LR2_EL2);
> -	case 1:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(1)], ICH_LR1_EL2);
> -	case 0:
> -		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(0)], ICH_LR0_EL2);
> +	write_gicreg(cpu_if->vgic_vmcr, ICH_VMCR_EL2);

also here you may be able to optimize and cache the last seen in-ardware VMCR.

> +
> +	if (live_lrs) {
> +		write_gicreg(cpu_if->vgic_hcr, ICH_HCR_EL2);
> +
> +		switch (nr_pri_bits) {
> +		case 7:
> +			write_gicreg(cpu_if->vgic_ap1r[3], ICH_AP1R3_EL2);
> +			write_gicreg(cpu_if->vgic_ap1r[2], ICH_AP1R2_EL2);
> +		case 6:
> +			write_gicreg(cpu_if->vgic_ap1r[1], ICH_AP1R1_EL2);
> +		default:
> +			write_gicreg(cpu_if->vgic_ap1r[0], ICH_AP1R0_EL2);
> +		}
> +		 	                           

nit: trailing white space

> +		switch (nr_pri_bits) {
> +		case 7:
> +			write_gicreg(cpu_if->vgic_ap0r[3], ICH_AP0R3_EL2);
> +			write_gicreg(cpu_if->vgic_ap0r[2], ICH_AP0R2_EL2);
> +		case 6:
> +			write_gicreg(cpu_if->vgic_ap0r[1], ICH_AP0R1_EL2);
> +		default:
> +			write_gicreg(cpu_if->vgic_ap0r[0], ICH_AP0R0_EL2);
> +		}
> +
> +		for (i = 0; i <= max_lr_idx; i++) {
> +			val = 0;
> +
> +			if (live_lrs & (1 << i))
> +				val = cpu_if->vgic_lr[i];
> +
> +			__gic_v3_set_lr(val, i);
> +		}
>  	}
>  
> +
>  	/*
>  	 * Ensures that the above will have reached the
>  	 * (re)distributors. This ensure the guest will read the
> @@ -209,6 +268,7 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
>  	 */
>  	isb();
>  	dsb(sy);
> +	vcpu->arch.vgic_cpu.live_lrs = live_lrs;
>  
>  	/*
>  	 * Prevent the guest from touching the GIC system registers if
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index f473fd6..281caf8 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -279,12 +279,6 @@ struct vgic_v2_cpu_if {
>  	u32		vgic_lr[VGIC_V2_MAX_LRS];
>  };
>  
> -/*
> - * LRs are stored in reverse order in memory. make sure we index them
> - * correctly.
> - */
> -#define VGIC_V3_LR_INDEX(lr)		(VGIC_V3_MAX_LRS - 1 - lr)
> -
>  struct vgic_v3_cpu_if {
>  #ifdef CONFIG_KVM_ARM_VGIC_V3
>  	u32		vgic_hcr;
> diff --git a/virt/kvm/arm/vgic-v3.c b/virt/kvm/arm/vgic-v3.c
> index 453eafd..11b5ff6 100644
> --- a/virt/kvm/arm/vgic-v3.c
> +++ b/virt/kvm/arm/vgic-v3.c
> @@ -42,7 +42,7 @@ static u32 ich_vtr_el2;
>  static struct vgic_lr vgic_v3_get_lr(const struct kvm_vcpu *vcpu, int lr)
>  {
>  	struct vgic_lr lr_desc;
> -	u64 val = vcpu->arch.vgic_cpu.vgic_v3.vgic_lr[VGIC_V3_LR_INDEX(lr)];
> +	u64 val = vcpu->arch.vgic_cpu.vgic_v3.vgic_lr[lr];
>  
>  	if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
>  		lr_desc.irq = val & ICH_LR_VIRTUALID_MASK;
> @@ -106,7 +106,7 @@ static void vgic_v3_set_lr(struct kvm_vcpu *vcpu, int lr,
>  		lr_val |= ((u64)lr_desc.hwirq) << ICH_LR_PHYS_ID_SHIFT;
>  	}
>  
> -	vcpu->arch.vgic_cpu.vgic_v3.vgic_lr[VGIC_V3_LR_INDEX(lr)] = lr_val;
> +	vcpu->arch.vgic_cpu.vgic_v3.vgic_lr[lr] = lr_val;
>  
>  	if (!(lr_desc.state & LR_STATE_MASK))
>  		vcpu->arch.vgic_cpu.vgic_v3.vgic_elrsr |= (1U << lr);
> -- 
> 2.1.4
> 

Ignoring potential further optimizations:

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From ldewangan at nvidia.com  Wed Feb 10 04:38:49 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 10 Feb 2016 18:08:49 +0530
Subject: [PATCH] mfd: Provide MACRO to declare commonly defined MFD cell
 attributes
In-Reply-To: <1455028027-1527-1-git-send-email-lee.jones@linaro.org>
References: <1455028027-1527-1-git-send-email-lee.jones@linaro.org>
Message-ID: <56BB2F59.9030702@nvidia.com>


On Tuesday 09 February 2016 07:57 PM, Lee Jones wrote:
> Cc: Laxman Dewangan <ldewangan at nvidia.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>   include/linux/mfd/core.h | 32 ++++++++++++++++++++++++++++++++
>   1 file changed, 32 insertions(+)
>
> diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
> index 27dac3f..dacdc49 100644
> --- a/include/linux/mfd/core.h
> +++ b/include/linux/mfd/core.h
> @@ -16,6 +16,38 @@
>   
>   #include <linux/platform_device.h>
>   
> +#define MFD_CELL_ALL(_name, _res, _pdata, _id, _compat, _match)		\
> +	{								\
> +		.name = (_name),					\
> +		.num_resources = ARRAY_SIZE((_res)),			\
> +		.resources = (_res),					\
> +		.platform_data = (_pdata),				\
> +		.pdata_size = ARRAY_SIZE((_pdata)),			\
> +		.of_compatible = (_compat),				\
> +		.acpi_match = (_match),					\
> +		.id = _id,						\
> +	}
>

Should we add the _res_size and _pdata_size also in argument and use 
them instead of ARRA_SIZE and lets client set the size with help of 
ARRAY_SIZE based on type of data?



From maxime.ripard at free-electrons.com  Wed Feb 10 04:53:33 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 10 Feb 2016 13:53:33 +0100
Subject: [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused
In-Reply-To: <20160204162545.f806fcb64a826d2c3313985b@free.fr>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <20160204120507.GC4270@lukather>
 <20160204162545.f806fcb64a826d2c3313985b@free.fr>
Message-ID: <20160210125333.GC31506@lukather>

On Thu, Feb 04, 2016 at 04:25:45PM +0100, Jean-Francois Moine wrote:
> On Thu, 4 Feb 2016 13:05:07 +0100
> Maxime Ripard <maxime.ripard at free-electrons.com> wrote:
> 
> > On Mon, Feb 01, 2016 at 09:20:00PM +0100, Maxime Ripard wrote:
> > > Remove the fixed dividers from the PLL6 driver to be able to have a
> > > reusable driver that can be used across several SoCs that share the same
> > > controller, but don't have the same set of dividers for this clock, and to
> > > also be reused multiple times in the same SoC, since we're droping the
> > > clock name.
> > > 
> > > Acked-by: Chen-Yu Tsai <wens at csie.org>
> > > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > 
> > Applied.
> > 
> > Maxime
> 
> I don't agree:
> - you changed the DTs of many SoCs without any valid reason,

I did give you a significant number of reasons [1]. The fact that you
chose to ignore them is up to you.

> - you complexified the treatment of the pll6 in clk-sunxi.c while
>   defining a x2 rate instead of the single rate would also work for
>   the other pll periphs (pll8).

I've not used in this patch anything that is not already in there, so
I'm not really sure how it complexifies anything. Feel free to
enlighten me.

> 
> Here is a simpler patch:
> 
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi	2016-02-01 08:24:06.179396522 +0100
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi	2016-02-04 16:18:05.911509291 +0100
> @@ -137,12 +137,23 @@
>  			clock-output-names = "pll6d2";
>  		};
>  
> -		/* dummy clock until pll6 can be reused */
> +		pll8x2: clk at 01c20044 {			/* PLL_PERIPH1 */
> +			#clock-cells = <0>;
> +			compatible = "allwinner,pll-periphx2-clk";
> +			reg = <0x01c20044 0x4>;
> +			clocks = <&osc24M>;
> +			clock-output-names = "pll8x2";
> +		};
> +
>  		pll8: pll8_clk {
>  			#clock-cells = <0>;
> -			compatible = "fixed-clock";
> -			clock-frequency = <1>;
> +			compatible = "fixed-factor-clock";
> +			clock-div = <2>;
> +			clock-mult = <1>;
> +			clocks = <&pll8x2>;
>  			clock-output-names = "pll8";
> +			assigned-clocks = <&pll8x2>;
> +			assigned-clock-rates = <1200000000>;
>  		};
>  
>  		cpu: cpu_clk at 01c20050 {
> --- a/drivers/clk/sunxi/clk-sunxi.c	2016-02-01 08:24:06.199396132 +0100
> +++ b/drivers/clk/sunxi/clk-sunxi.c	2016-02-04 16:03:41.056322804 +0100
> @@ -714,6 +714,12 @@
>  	.name = "pll6",
>  };
>  
> +static const struct factors_data pll_periphx2_data __initconst = {
> +	.enable = 31,
> +	.table = &sun6i_a31_pll6_config,
> +	.getter = sun6i_a31_get_pll6_factors,
> +};
> +
>  static const struct factors_data sun6i_a31_pll6_data __initconst = {
>  	.enable = 31,
>  	.table = &sun6i_a31_pll6_config,
> @@ -1110,6 +1116,7 @@
>  	{.compatible = "allwinner,sun5i-a13-ahb-clk", .data = &sun5i_a13_ahb_data,},
>  	{.compatible = "allwinner,sun4i-a10-apb1-clk", .data = &sun4i_apb1_data,},
>  	{.compatible = "allwinner,sun7i-a20-out-clk", .data = &sun7i_a20_out_data,},
> +	{.compatible = "allwinner,pll-periphx2-clk", .data = &pll_periphx2_data,},
>  	{}
>  };

Except that it doesn't match the hardware and that the parenthood
relationship is inversed. The pll6 output is 24 MHz * n * k / 2, as
seen in any datasheet that uses it. Your clock driver doesn't
represent that fact.

Maxime

[1]: http://www.spinics.net/lists/arm-kernel/msg479744.html

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160210/aec9593f/attachment.sig>

From maxime.ripard at free-electrons.com  Wed Feb 10 04:59:36 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 10 Feb 2016 13:59:36 +0100
Subject: [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused
In-Reply-To: <56B4E2FB.3050703@arm.com>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com>
Message-ID: <20160210125936.GD31506@lukather>

Hi,

On Fri, Feb 05, 2016 at 05:59:23PM +0000, Andre Przywara wrote:
> Hi Maxime,
> 
> just found this while looking at your current git branch, so sorry for
> the late reply.
> 
> CC:ing DT people, since you touch both existing DTs(!) and the binding doc.
> 
> On 01/02/16 20:20, Maxime Ripard wrote:
> > Remove the fixed dividers from the PLL6 driver to be able to have a
> > reusable driver that can be used across several SoCs that share the same
> > controller, but don't have the same set of dividers for this clock, and to
> > also be reused multiple times in the same SoC, since we're droping the
> > clock name.
> > 
> > Acked-by: Chen-Yu Tsai <wens at csie.org>
> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> > ---
> > 
> > Changes from v3:
> >   - Fixed the documentation
> >   - Added pll6d2 back
> > 
> > Changes from v2:
> >   - Rebased and converted over to the new factors refactoring. Fixed the
> >     retrieved rate
> > 
> >  Documentation/devicetree/bindings/clock/sunxi.txt |  2 +-
> >  arch/arm/boot/dts/sun6i-a31.dtsi                  | 36 +++++++++++-----------
> >  arch/arm/boot/dts/sun8i-a23-a33.dtsi              | 25 ++++++++++-----
> >  arch/arm/boot/dts/sun8i-a23.dtsi                  |  2 +-
> >  arch/arm/boot/dts/sun8i-a33.dtsi                  |  4 +--
> >  arch/arm/boot/dts/sun8i-h3.dtsi                   | 37 ++++++++++++++---------
> 
> So are you really breaking all those systems by changing the DT and the
> driver in an incompatible way?

Yes.

> Please correct me if this assessment is wrong, but to me it looks like
> any user out there is either stuck with 4.5 at best _or_ will only be
> able to run 4.6 and later (depending on which version of the DT she is
> using)? And no, switching DTs along with the kernel is _not_ an option.

It is. And it is one that every other ARM platform chose. And so did
every distribution.

> That is not how I understand DT.

I'm sorry for that. This has never been something we said was
happening.

> Also this totally ignores any other DT user (U-Boot, FreeBSD, you
> name it).

Which all have their own DT copies, with their own bindings, that we
(ie Linux) never agreed on.

By further extending that argument, you're currently looking at the DT
from Allwinner, do you want to support theirs as well?

> I actually appreciate this rework, it's more flexible now and looks
> better, but you really can't do this in a way to breaks compatibility
> with existing DTs.
> 
> Jean-Francois came up with another solution for the pll8 clock [1], so
> could this be considered at least?
> I think changing the H3 PLL8 clock from dummy to something real is a
> different story in terms of compatibility (since it never really worked
> before and this wouldn't change for any old-DT user).

So, one would have to update the DT anyway to benefit from these
changes? What's the point of maintaining DT stability if you add every
new release new stuff to the DT that users are going to want? Beside
adding untested, unmaintained, dead, and possibly broken code, that is.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160210/76711c11/attachment.sig>

From lee.jones at linaro.org  Wed Feb 10 05:02:17 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 13:02:17 +0000
Subject: [PATCH 00/11] pwm: Add support for PWM Capture
Message-ID: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>

The first part of this set extends the current PWM API to allow external
code to request a PWM Capture.  Subsequent patches then make use of the
new API by providing a userspace offering via /sysfs.  The final part of
the set supplies PWM Capture functionality into the already existing STi
PWM driver.

This patch-set has been tested end to end via /sysfs.

Lee Jones (11):
  pwm: Add PWM Capture support
  pwm: sysfs: Add PWM Capture support
  pwm: sti: Reorganise register names in preparation for new
    functionality
  pwm: sti: Only request clock rate when you need to
  pwm: sti: Supply PWM Capture register addresses and bit locations
  pwm: sti: Supply PWM Capture clock handling
  pwm: sti: Initialise PWM Capture channel data
  pwm: sti: Add support for PWM Capture IRQs
  pwm: sti: Add PWM Capture call-back
  pwm: sti: Enable PWM Capture
  pwm: sti: Take the opportunity to conduct a little house keeping

 drivers/pwm/core.c    |  26 ++++
 drivers/pwm/pwm-sti.c | 383 ++++++++++++++++++++++++++++++++++++++++++--------
 drivers/pwm/sysfs.c   |  28 ++++
 include/linux/pwm.h   |  13 ++
 4 files changed, 391 insertions(+), 59 deletions(-)

-- 
1.9.1



From lee.jones at linaro.org  Wed Feb 10 05:02:18 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 13:02:18 +0000
Subject: [PATCH 01/11] pwm: Add PWM Capture support
In-Reply-To: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
References: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1455109348-32767-2-git-send-email-lee.jones@linaro.org>

Supply a PWM Capture call-back Op in order to pass back
information obtained by running analysis on PWM a signal.
This would normally (at least during testing) be called from
the Sysfs routines with a view to printing out PWM Capture
data which has been encoded into a string.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/pwm/core.c  | 26 ++++++++++++++++++++++++++
 include/linux/pwm.h | 13 +++++++++++++
 2 files changed, 39 insertions(+)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index d24ca5f..8f4a8a9 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -494,6 +494,32 @@ unlock:
 EXPORT_SYMBOL_GPL(pwm_set_polarity);
 
 /**
+ * pwm_capture() - capture and report a PWM signal
+ * @pwm: PWM device
+ * @channel: PWM capture channel to use
+ * @buf: buffer to place output message into
+ *
+ * Returns: 0 on success or a negative error code on failure.
+ */
+int pwm_capture(struct pwm_device *pwm, int channel, char *buf)
+{
+	int err;
+
+	if (!pwm || !pwm->chip->ops)
+		return -EINVAL;
+
+	if (!pwm->chip->ops->capture)
+		return -ENOSYS;
+
+	mutex_lock(&pwm->lock);
+	err = pwm->chip->ops->capture(pwm->chip, pwm, channel, buf);
+	mutex_unlock(&pwm->lock);
+
+	return err;
+}
+EXPORT_SYMBOL_GPL(pwm_capture);
+
+/**
  * pwm_enable() - start a PWM output toggling
  * @pwm: PWM device
  *
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index cfc3ed4..7bcff6b 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -33,6 +33,11 @@ int pwm_enable(struct pwm_device *pwm);
  * pwm_disable - stop a PWM output toggling
  */
 void pwm_disable(struct pwm_device *pwm);
+
+/*
+ * pwm_capture - capture and report a PWM signal
+ */
+int pwm_capture(struct pwm_device *pwm, int channel, char *buf);
 #else
 static inline struct pwm_device *pwm_request(int pwm_id, const char *label)
 {
@@ -56,6 +61,11 @@ static inline int pwm_enable(struct pwm_device *pwm)
 static inline void pwm_disable(struct pwm_device *pwm)
 {
 }
+
+static inline int pwm_capture(struct pwm_device *pwm, int channel, char *buf)
+{
+	return -EINVAL;
+}
 #endif
 
 struct pwm_chip;
@@ -150,6 +160,7 @@ static inline enum pwm_polarity pwm_get_polarity(const struct pwm_device *pwm)
  * @free: optional hook for freeing a PWM
  * @config: configure duty cycles and period length for this PWM
  * @set_polarity: configure the polarity of this PWM
+ * @capture: capture and report PWM signal
  * @enable: enable PWM output toggling
  * @disable: disable PWM output toggling
  * @dbg_show: optional routine to show contents in debugfs
@@ -162,6 +173,8 @@ struct pwm_ops {
 		      int duty_ns, int period_ns);
 	int (*set_polarity)(struct pwm_chip *chip, struct pwm_device *pwm,
 			    enum pwm_polarity polarity);
+	int (*capture)(struct pwm_chip *chip, struct pwm_device *pwm,
+		       int channel, char *buf);
 	int (*enable)(struct pwm_chip *chip, struct pwm_device *pwm);
 	void (*disable)(struct pwm_chip *chip, struct pwm_device *pwm);
 #ifdef CONFIG_DEBUG_FS
-- 
1.9.1



From lee.jones at linaro.org  Wed Feb 10 05:02:19 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 13:02:19 +0000
Subject: [PATCH 02/11] pwm: sysfs: Add PWM Capture support
In-Reply-To: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
References: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1455109348-32767-3-git-send-email-lee.jones@linaro.org>

Allow a user to read PWM Capture results from /sysfs. First,
the user must tell PWM Capture which channel they wish to
read from:

  $ echo 2 > $PWMCHIP/capture

To start a capture and read the result, simply read the file:

  $ cat $PWMCHIP/capture

The output format is left to the device.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/pwm/sysfs.c | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index 9c90886..3572ef4 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -23,6 +23,8 @@
 #include <linux/kdev_t.h>
 #include <linux/pwm.h>
 
+static int capture_channel;
+
 struct pwm_export {
 	struct device child;
 	struct pwm_device *pwm;
@@ -167,16 +169,42 @@ static ssize_t polarity_store(struct device *child,
 	return ret ? : size;
 }
 
+static ssize_t capture_show(struct device *child,
+			    struct device_attribute *attr,
+			    char *buf)
+{
+	struct pwm_device *pwm = child_to_pwm_device(child);
+
+	return pwm_capture(pwm, capture_channel, buf);
+}
+
+static ssize_t capture_store(struct device *child,
+			     struct device_attribute *attr,
+			     const char *buf, size_t size)
+{
+	int val, ret;
+
+	ret = kstrtoint(buf, 0, &val);
+	if (ret)
+		return ret;
+
+	capture_channel = val;
+
+	return size;
+}
+
 static DEVICE_ATTR_RW(period);
 static DEVICE_ATTR_RW(duty_cycle);
 static DEVICE_ATTR_RW(enable);
 static DEVICE_ATTR_RW(polarity);
+static DEVICE_ATTR_RW(capture);
 
 static struct attribute *pwm_attrs[] = {
 	&dev_attr_period.attr,
 	&dev_attr_duty_cycle.attr,
 	&dev_attr_enable.attr,
 	&dev_attr_polarity.attr,
+	&dev_attr_capture.attr,
 	NULL
 };
 ATTRIBUTE_GROUPS(pwm);
-- 
1.9.1



From lee.jones at linaro.org  Wed Feb 10 05:02:20 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 13:02:20 +0000
Subject: [PATCH 03/11] pwm: sti: Reorganise register names in preparation for
 new functionality
In-Reply-To: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
References: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1455109348-32767-4-git-send-email-lee.jones@linaro.org>

Exciting functionality is on the way to this device.  But
before we can add it, we need to do some basic housekeeping
so the additions can be added cleanly.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/pwm/pwm-sti.c | 76 +++++++++++++++++++++++++++------------------------
 1 file changed, 41 insertions(+), 35 deletions(-)

diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
index 92abbd5..4e06c4d 100644
--- a/drivers/pwm/pwm-sti.c
+++ b/drivers/pwm/pwm-sti.c
@@ -21,18 +21,22 @@
 #include <linux/slab.h>
 #include <linux/time.h>
 
-#define STI_DS_REG(ch)	(4 * (ch))	/* Channel's Duty Cycle register */
-#define STI_PWMCR	0x50		/* Control/Config register */
-#define STI_INTEN	0x54		/* Interrupt Enable/Disable register */
+#define PWM_OUT_VAL(x)	(0x00 + (4 * (x))) /* Channel's Duty Cycle register */
+
+#define STI_PWM_CTRL	0x50		/* Control/Config register */
+#define STI_INT_EN	0x54		/* Interrupt Enable/Disable register */
 #define PWM_PRESCALE_LOW_MASK		0x0f
 #define PWM_PRESCALE_HIGH_MASK		0xf0
 
 /* Regfield IDs */
 enum {
+	/* Bits in PWM_CTRL*/
 	PWMCLK_PRESCALE_LOW,
 	PWMCLK_PRESCALE_HIGH,
-	PWM_EN,
-	PWM_INT_EN,
+
+	PWM_OUT_EN,
+
+	PWM_CPT_INT_EN,
 
 	/* Keep last */
 	MAX_REGFIELDS
@@ -47,14 +51,14 @@ struct sti_pwm_compat_data {
 
 struct sti_pwm_chip {
 	struct device *dev;
-	struct clk *clk;
 	unsigned long clk_rate;
+	struct clk *pwm_clk;
 	struct regmap *regmap;
 	struct sti_pwm_compat_data *cdata;
 	struct regmap_field *prescale_low;
 	struct regmap_field *prescale_high;
-	struct regmap_field *pwm_en;
-	struct regmap_field *pwm_int_en;
+	struct regmap_field *pwm_out_en;
+	struct regmap_field *pwm_cpt_int_en;
 	struct pwm_chip chip;
 	struct pwm_device *cur;
 	unsigned long configured;
@@ -64,10 +68,10 @@ struct sti_pwm_chip {
 };
 
 static const struct reg_field sti_pwm_regfields[MAX_REGFIELDS] = {
-	[PWMCLK_PRESCALE_LOW]	= REG_FIELD(STI_PWMCR, 0, 3),
-	[PWMCLK_PRESCALE_HIGH]	= REG_FIELD(STI_PWMCR, 11, 14),
-	[PWM_EN]		= REG_FIELD(STI_PWMCR, 9, 9),
-	[PWM_INT_EN]		= REG_FIELD(STI_INTEN, 0, 0),
+	[PWMCLK_PRESCALE_LOW]	= REG_FIELD(STI_PWM_CTRL, 0, 3),
+	[PWMCLK_PRESCALE_HIGH]	= REG_FIELD(STI_PWM_CTRL, 11, 14),
+	[PWM_OUT_EN]		= REG_FIELD(STI_PWM_CTRL, 9, 9),
+	[PWM_CPT_INT_EN]	= REG_FIELD(STI_INT_EN, 1, 4),
 };
 
 static inline struct sti_pwm_chip *to_sti_pwmchip(struct pwm_chip *chip)
@@ -144,7 +148,7 @@ static int sti_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 	    ((ncfg == 1) && (pwm->hwpwm != cur->hwpwm) && period_same) ||
 	    ((ncfg > 1) && period_same)) {
 		/* Enable clock before writing to PWM registers. */
-		ret = clk_enable(pc->clk);
+		ret = clk_enable(pc->pwm_clk);
 		if (ret)
 			return ret;
 
@@ -174,11 +178,12 @@ static int sti_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 		 */
 		pwmvalx = cdata->max_pwm_cnt * duty_ns / period_ns;
 
-		ret = regmap_write(pc->regmap, STI_DS_REG(pwm->hwpwm), pwmvalx);
+		ret = regmap_write(pc->regmap,
+				   PWM_OUT_VAL(pwm->hwpwm), pwmvalx);
 		if (ret)
 			goto clk_dis;
 
-		ret = regmap_field_write(pc->pwm_int_en, 0);
+		ret = regmap_field_write(pc->pwm_cpt_int_en, 0);
 
 		set_bit(pwm->hwpwm, &pc->configured);
 		pc->cur = pwm;
@@ -190,7 +195,7 @@ static int sti_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 	}
 
 clk_dis:
-	clk_disable(pc->clk);
+	clk_disable(pc->pwm_clk);
 	return ret;
 }
 
@@ -206,11 +211,11 @@ static int sti_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 	 */
 	mutex_lock(&pc->sti_pwm_lock);
 	if (!pc->en_count) {
-		ret = clk_enable(pc->clk);
+		ret = clk_enable(pc->pwm_clk);
 		if (ret)
 			goto out;
 
-		ret = regmap_field_write(pc->pwm_en, 1);
+		ret = regmap_field_write(pc->pwm_out_en, 1);
 		if (ret) {
 			dev_err(dev, "failed to enable PWM device:%d\n",
 				pwm->hwpwm);
@@ -232,9 +237,9 @@ static void sti_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
 		mutex_unlock(&pc->sti_pwm_lock);
 		return;
 	}
-	regmap_field_write(pc->pwm_en, 0);
+	regmap_field_write(pc->pwm_out_en, 0);
 
-	clk_disable(pc->clk);
+	clk_disable(pc->pwm_clk);
 	mutex_unlock(&pc->sti_pwm_lock);
 }
 
@@ -277,15 +282,16 @@ static int sti_pwm_probe_dt(struct sti_pwm_chip *pc)
 	if (IS_ERR(pc->prescale_high))
 		return PTR_ERR(pc->prescale_high);
 
-	pc->pwm_en = devm_regmap_field_alloc(dev, pc->regmap,
-					     reg_fields[PWM_EN]);
-	if (IS_ERR(pc->pwm_en))
-		return PTR_ERR(pc->pwm_en);
 
-	pc->pwm_int_en = devm_regmap_field_alloc(dev, pc->regmap,
-						 reg_fields[PWM_INT_EN]);
-	if (IS_ERR(pc->pwm_int_en))
-		return PTR_ERR(pc->pwm_int_en);
+	pc->pwm_out_en = devm_regmap_field_alloc(dev, pc->regmap,
+						 reg_fields[PWM_OUT_EN]);
+	if (IS_ERR(pc->pwm_out_en))
+		return PTR_ERR(pc->pwm_out_en);
+
+	pc->pwm_cpt_int_en = devm_regmap_field_alloc(dev, pc->regmap,
+						 reg_fields[PWM_CPT_INT_EN]);
+	if (IS_ERR(pc->pwm_cpt_int_en))
+		return PTR_ERR(pc->pwm_cpt_int_en);
 
 	return 0;
 }
@@ -341,19 +347,19 @@ static int sti_pwm_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	pc->clk = of_clk_get_by_name(dev->of_node, "pwm");
-	if (IS_ERR(pc->clk)) {
+	pc->pwm_clk = of_clk_get_by_name(dev->of_node, "pwm");
+	if (IS_ERR(pc->pwm_clk)) {
 		dev_err(dev, "failed to get PWM clock\n");
-		return PTR_ERR(pc->clk);
+		return PTR_ERR(pc->pwm_clk);
 	}
 
-	pc->clk_rate = clk_get_rate(pc->clk);
+	pc->clk_rate = clk_get_rate(pc->pwm_clk);
 	if (!pc->clk_rate) {
 		dev_err(dev, "failed to get clock rate\n");
 		return -EINVAL;
 	}
 
-	ret = clk_prepare(pc->clk);
+	ret = clk_prepare(pc->pwm_clk);
 	if (ret) {
 		dev_err(dev, "failed to prepare clock\n");
 		return ret;
@@ -367,7 +373,7 @@ static int sti_pwm_probe(struct platform_device *pdev)
 
 	ret = pwmchip_add(&pc->chip);
 	if (ret < 0) {
-		clk_unprepare(pc->clk);
+		clk_unprepare(pc->pwm_clk);
 		return ret;
 	}
 
@@ -384,7 +390,7 @@ static int sti_pwm_remove(struct platform_device *pdev)
 	for (i = 0; i < pc->cdata->num_chan; i++)
 		pwm_disable(&pc->chip.pwms[i]);
 
-	clk_unprepare(pc->clk);
+	clk_unprepare(pc->pwm_clk);
 
 	return pwmchip_remove(&pc->chip);
 }
-- 
1.9.1



From lee.jones at linaro.org  Wed Feb 10 05:02:23 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 13:02:23 +0000
Subject: [PATCH 06/11] pwm: sti: Supply PWM Capture clock handling
In-Reply-To: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
References: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1455109348-32767-7-git-send-email-lee.jones@linaro.org>

ST's PWM IP is supplied by 2 different clocks.  One for PWM
Output and the other for Capture.  This patch provides clock
handling for the latter.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/pwm/pwm-sti.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
index 2336bac..9e6b1c8 100644
--- a/drivers/pwm/pwm-sti.c
+++ b/drivers/pwm/pwm-sti.c
@@ -74,6 +74,7 @@ struct sti_pwm_compat_data {
 struct sti_pwm_chip {
 	struct device *dev;
 	struct clk *pwm_clk;
+	struct clk *cpt_clk;
 	struct regmap *regmap;
 	struct sti_pwm_compat_data *cdata;
 	struct regmap_field *prescale_low;
@@ -183,6 +184,10 @@ static int sti_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 		if (ret)
 			return ret;
 
+		ret = clk_enable(pc->cpt_clk);
+		if (ret)
+			return ret;
+
 		if (!period_same) {
 			ret = sti_pwm_get_prescale(pc, period_ns, &prescale);
 			if (ret)
@@ -227,6 +232,7 @@ static int sti_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 
 clk_dis:
 	clk_disable(pc->pwm_clk);
+	clk_disable(pc->cpt_clk);
 	return ret;
 }
 
@@ -246,6 +252,10 @@ static int sti_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 		if (ret)
 			goto out;
 
+		ret = clk_enable(pc->cpt_clk);
+		if (ret)
+			goto out;
+
 		ret = regmap_field_write(pc->pwm_out_en, 1);
 		if (ret) {
 			dev_err(dev, "failed to enable PWM device:%d\n",
@@ -271,6 +281,7 @@ static void sti_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
 	regmap_field_write(pc->pwm_out_en, 0);
 
 	clk_disable(pc->pwm_clk);
+	clk_disable(pc->cpt_clk);
 	mutex_unlock(&pc->sti_pwm_lock);
 }
 
@@ -390,6 +401,18 @@ static int sti_pwm_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	pc->cpt_clk = of_clk_get_by_name(dev->of_node, "capture");
+	if (IS_ERR(pc->cpt_clk)) {
+		dev_err(dev, "failed to get PWM capture clock\n");
+		return PTR_ERR(pc->cpt_clk);
+	}
+
+	ret = clk_prepare(pc->cpt_clk);
+	if (ret) {
+		dev_err(dev, "failed to prepare clock\n");
+		return ret;
+	}
+
 	pc->chip.dev = dev;
 	pc->chip.ops = &sti_pwm_ops;
 	pc->chip.base = -1;
@@ -399,6 +422,7 @@ static int sti_pwm_probe(struct platform_device *pdev)
 	ret = pwmchip_add(&pc->chip);
 	if (ret < 0) {
 		clk_unprepare(pc->pwm_clk);
+		clk_unprepare(pc->cpt_clk);
 		return ret;
 	}
 
@@ -416,6 +440,7 @@ static int sti_pwm_remove(struct platform_device *pdev)
 		pwm_disable(&pc->chip.pwms[i]);
 
 	clk_unprepare(pc->pwm_clk);
+	clk_unprepare(pc->cpt_clk);
 
 	return pwmchip_remove(&pc->chip);
 }
-- 
1.9.1



From lee.jones at linaro.org  Wed Feb 10 05:02:21 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 13:02:21 +0000
Subject: [PATCH 04/11] pwm: sti: Only request clock rate when you need to
In-Reply-To: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
References: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1455109348-32767-5-git-send-email-lee.jones@linaro.org>

In the original code the clock rate was only obtained during
initialisation; however, the rate may change between then and
its use.  This patch ensures the correct rate is acquired just
before use.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/pwm/pwm-sti.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
index 4e06c4d..aa217e2 100644
--- a/drivers/pwm/pwm-sti.c
+++ b/drivers/pwm/pwm-sti.c
@@ -51,7 +51,6 @@ struct sti_pwm_compat_data {
 
 struct sti_pwm_chip {
 	struct device *dev;
-	unsigned long clk_rate;
 	struct clk *pwm_clk;
 	struct regmap *regmap;
 	struct sti_pwm_compat_data *cdata;
@@ -86,13 +85,20 @@ static int sti_pwm_get_prescale(struct sti_pwm_chip *pc, unsigned long period,
 				unsigned int *prescale)
 {
 	struct sti_pwm_compat_data *cdata = pc->cdata;
+	unsigned long clk_rate;
 	unsigned long val;
 	unsigned int ps;
 
+	clk_rate = clk_get_rate(pc->pwm_clk);
+	if (!clk_rate) {
+		dev_err(pc->dev, "failed to get clock rate\n");
+		return -EINVAL;
+	}
+
 	/*
 	 * prescale = ((period_ns * clk_rate) / (10^9 * (max_pwm_count + 1)) - 1
 	 */
-	val = NSEC_PER_SEC / pc->clk_rate;
+	val = NSEC_PER_SEC / clk_rate;
 	val *= cdata->max_pwm_cnt + 1;
 
 	if (period % val) {
@@ -353,12 +359,6 @@ static int sti_pwm_probe(struct platform_device *pdev)
 		return PTR_ERR(pc->pwm_clk);
 	}
 
-	pc->clk_rate = clk_get_rate(pc->pwm_clk);
-	if (!pc->clk_rate) {
-		dev_err(dev, "failed to get clock rate\n");
-		return -EINVAL;
-	}
-
 	ret = clk_prepare(pc->pwm_clk);
 	if (ret) {
 		dev_err(dev, "failed to prepare clock\n");
-- 
1.9.1



From lee.jones at linaro.org  Wed Feb 10 05:02:22 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 13:02:22 +0000
Subject: [PATCH 05/11] pwm: sti: Supply PWM Capture register addresses and bit
 locations
In-Reply-To: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
References: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1455109348-32767-6-git-send-email-lee.jones@linaro.org>

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/pwm/pwm-sti.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
index aa217e2..2336bac 100644
--- a/drivers/pwm/pwm-sti.c
+++ b/drivers/pwm/pwm-sti.c
@@ -22,26 +22,48 @@
 #include <linux/time.h>
 
 #define PWM_OUT_VAL(x)	(0x00 + (4 * (x))) /* Channel's Duty Cycle register */
+#define PWM_CPT_VAL(x)	(0x10 + (4 * (x))) /* Capture value */
+#define PWM_CPT_EDGE(x) (0x30 + (4 * (x))) /* Edge to capture on */
 
 #define STI_PWM_CTRL	0x50		/* Control/Config register */
 #define STI_INT_EN	0x54		/* Interrupt Enable/Disable register */
+#define STI_INT_STA	0x58		/* Interrupt Status register */
+#define PWM_INT_ACK			0x5c
 #define PWM_PRESCALE_LOW_MASK		0x0f
 #define PWM_PRESCALE_HIGH_MASK		0xf0
+#define PWM_CPT_EDGE_MASK		0x03
+#define PWM_INT_ACK_MASK		0x1ff
+
+#define STI_MAX_CPT_CHANS		4
+#define CPT_DC_MAX			0xff
 
 /* Regfield IDs */
 enum {
 	/* Bits in PWM_CTRL*/
 	PWMCLK_PRESCALE_LOW,
 	PWMCLK_PRESCALE_HIGH,
+	CPTCLK_PRESCALE,
 
 	PWM_OUT_EN,
+	PWM_CPT_EN,
 
 	PWM_CPT_INT_EN,
+	PWM_CPT_INT_STAT,
 
 	/* Keep last */
 	MAX_REGFIELDS
 };
 
+/* Each capture input can be programmed to detect rising-edge, falling-edge,
+ * either edge or neither egde
+ */
+enum sti_cpt_edge {
+	CPT_EDGE_DISABLED,
+	CPT_EDGE_RISING,
+	CPT_EDGE_FALLING,
+	CPT_EDGE_BOTH,
+};
+
 struct sti_pwm_compat_data {
 	const struct reg_field *reg_fields;
 	unsigned int num_chan;
@@ -69,8 +91,11 @@ struct sti_pwm_chip {
 static const struct reg_field sti_pwm_regfields[MAX_REGFIELDS] = {
 	[PWMCLK_PRESCALE_LOW]	= REG_FIELD(STI_PWM_CTRL, 0, 3),
 	[PWMCLK_PRESCALE_HIGH]	= REG_FIELD(STI_PWM_CTRL, 11, 14),
+	[CPTCLK_PRESCALE]	= REG_FIELD(STI_PWM_CTRL, 4, 8),
 	[PWM_OUT_EN]		= REG_FIELD(STI_PWM_CTRL, 9, 9),
+	[PWM_CPT_EN]		= REG_FIELD(STI_PWM_CTRL, 10, 10),
 	[PWM_CPT_INT_EN]	= REG_FIELD(STI_INT_EN, 1, 4),
+	[PWM_CPT_INT_STAT]	= REG_FIELD(STI_INT_STA, 1, 4),
 };
 
 static inline struct sti_pwm_chip *to_sti_pwmchip(struct pwm_chip *chip)
-- 
1.9.1



From lee.jones at linaro.org  Wed Feb 10 05:02:27 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 13:02:27 +0000
Subject: [PATCH 10/11] pwm: sti: Enable PWM Capture
In-Reply-To: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
References: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1455109348-32767-11-git-send-email-lee.jones@linaro.org>

Once all functionality is in place, we provide the means to
enable PWM Capture.  Here we are simply obtaining the
associated regmap and twiddling the relevant enable register
bits.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/pwm/pwm-sti.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
index 8de9b4a..93cf20e 100644
--- a/drivers/pwm/pwm-sti.c
+++ b/drivers/pwm/pwm-sti.c
@@ -279,6 +279,13 @@ static int sti_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 				pwm->hwpwm);
 			goto out;
 		}
+
+		ret = regmap_field_write(pc->pwm_cpt_en, 1);
+		if (ret) {
+			dev_err(dev, "failed to enable PWM capture:%d\n",
+				pwm->hwpwm);
+			goto out;
+		}
 	}
 	pc->en_count++;
 out:
@@ -296,6 +303,7 @@ static void sti_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
 		return;
 	}
 	regmap_field_write(pc->pwm_out_en, 0);
+	regmap_field_write(pc->pwm_cpt_en, 0);
 
 	clk_disable(pc->pwm_clk);
 	clk_disable(pc->cpt_clk);
@@ -492,6 +500,11 @@ static int sti_pwm_probe_dt(struct sti_pwm_chip *pc)
 	if (IS_ERR(pc->pwm_out_en))
 		return PTR_ERR(pc->pwm_out_en);
 
+	pc->pwm_cpt_en = devm_regmap_field_alloc(dev, pc->regmap,
+						 reg_fields[PWM_CPT_EN]);
+	if (IS_ERR(pc->pwm_cpt_en))
+		return PTR_ERR(pc->pwm_cpt_en);
+
 	pc->pwm_cpt_int_en = devm_regmap_field_alloc(dev, pc->regmap,
 						 reg_fields[PWM_CPT_INT_EN]);
 	if (IS_ERR(pc->pwm_cpt_int_en))
-- 
1.9.1



From lee.jones at linaro.org  Wed Feb 10 05:02:24 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 13:02:24 +0000
Subject: [PATCH 07/11] pwm: sti: Initialise PWM Capture channel data
In-Reply-To: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
References: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1455109348-32767-8-git-send-email-lee.jones@linaro.org>

Each PWM Capture channel is allocated a structure to hold its own
state.  During a capture the channel may be partaking in one of 3
phases.  Initial (rising) phase change, a subsequent (falling)
phase change indicating end of the duty-cycle phase and finally
a final (rising) phase change indicating the end of the period.
The timer value snapshot each event is held in a variable of the
same name, and the phase number (0, 1, 2) is contained in the
index variable.  Other channel specific information, such as GPIO
pin, the IRQ wait queue and locking is also contained in the
structure.  This patch initialises this structure for each of
the available channels.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/pwm/pwm-sti.c | 49 ++++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 42 insertions(+), 7 deletions(-)

diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
index 9e6b1c8..fca692a 100644
--- a/drivers/pwm/pwm-sti.c
+++ b/drivers/pwm/pwm-sti.c
@@ -11,15 +11,19 @@
  */
 
 #include <linux/clk.h>
+#include <linux/gpio.h>
 #include <linux/math64.h>
 #include <linux/mfd/syscon.h>
 #include <linux/module.h>
 #include <linux/of.h>
+#include <linux/of_gpio.h>
 #include <linux/platform_device.h>
 #include <linux/pwm.h>
 #include <linux/regmap.h>
+#include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/time.h>
+#include <linux/wait.h>
 
 #define PWM_OUT_VAL(x)	(0x00 + (4 * (x))) /* Channel's Duty Cycle register */
 #define PWM_CPT_VAL(x)	(0x10 + (4 * (x))) /* Capture value */
@@ -64,9 +68,18 @@ enum sti_cpt_edge {
 	CPT_EDGE_BOTH,
 };
 
+struct sti_cpt_data {
+	u32 snapshot[3];
+	int index;
+	int gpio;
+	struct mutex lock;
+	wait_queue_head_t wait;
+};
+
 struct sti_pwm_compat_data {
 	const struct reg_field *reg_fields;
-	unsigned int num_chan;
+	unsigned int pwm_num_chan;
+	unsigned int cpt_num_chan;
 	unsigned int max_pwm_cnt;
 	unsigned int max_prescale;
 };
@@ -77,6 +90,7 @@ struct sti_pwm_chip {
 	struct clk *cpt_clk;
 	struct regmap *regmap;
 	struct sti_pwm_compat_data *cdata;
+	struct sti_cpt_data *cpt_data[STI_MAX_CPT_CHANS];
 	struct regmap_field *prescale_low;
 	struct regmap_field *prescale_high;
 	struct regmap_field *pwm_out_en;
@@ -307,10 +321,15 @@ static int sti_pwm_probe_dt(struct sti_pwm_chip *pc)
 	struct device_node *np = dev->of_node;
 	struct sti_pwm_compat_data *cdata = pc->cdata;
 	u32 num_chan;
+	int ret;
 
-	of_property_read_u32(np, "st,pwm-num-chan", &num_chan);
-	if (num_chan)
-		cdata->num_chan = num_chan;
+	ret = of_property_read_u32(np, "st,pwm-num-chan", &num_chan);
+	if (!ret)
+		cdata->pwm_num_chan = num_chan;
+
+	ret = of_property_read_u32(np, "st,capture-num-chan", &num_chan);
+	if (!ret)
+		cdata->cpt_num_chan = num_chan;
 
 	reg_fields = cdata->reg_fields;
 
@@ -347,9 +366,11 @@ static const struct regmap_config sti_pwm_regmap_config = {
 static int sti_pwm_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
 	struct sti_pwm_compat_data *cdata;
 	struct sti_pwm_chip *pc;
 	struct resource *res;
+	unsigned int chan;
 	int ret;
 
 	pc = devm_kzalloc(dev, sizeof(*pc), GFP_KERNEL);
@@ -378,7 +399,8 @@ static int sti_pwm_probe(struct platform_device *pdev)
 	cdata->reg_fields   = &sti_pwm_regfields[0];
 	cdata->max_prescale = 0xff;
 	cdata->max_pwm_cnt  = 255;
-	cdata->num_chan     = 1;
+	cdata->pwm_num_chan     = 1;
+	cdata->cpt_num_chan	= 0;
 
 	pc->cdata = cdata;
 	pc->dev = dev;
@@ -389,6 +411,19 @@ static int sti_pwm_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	for (chan = 0; chan < cdata->cpt_num_chan; chan++) {
+		struct sti_cpt_data *data;
+
+		data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+		if (!data)
+			return -ENOMEM;
+
+		init_waitqueue_head(&data->wait);
+		mutex_init(&data->lock);
+		data->gpio = of_get_named_gpio(np, "capture-gpios", chan);
+		pc->cpt_data[chan] = data;
+	}
+
 	pc->pwm_clk = of_clk_get_by_name(dev->of_node, "pwm");
 	if (IS_ERR(pc->pwm_clk)) {
 		dev_err(dev, "failed to get PWM clock\n");
@@ -416,7 +451,7 @@ static int sti_pwm_probe(struct platform_device *pdev)
 	pc->chip.dev = dev;
 	pc->chip.ops = &sti_pwm_ops;
 	pc->chip.base = -1;
-	pc->chip.npwm = pc->cdata->num_chan;
+	pc->chip.npwm = pc->cdata->pwm_num_chan;
 	pc->chip.can_sleep = true;
 
 	ret = pwmchip_add(&pc->chip);
@@ -436,7 +471,7 @@ static int sti_pwm_remove(struct platform_device *pdev)
 	struct sti_pwm_chip *pc = platform_get_drvdata(pdev);
 	unsigned int i;
 
-	for (i = 0; i < pc->cdata->num_chan; i++)
+	for (i = 0; i < pc->cdata->pwm_num_chan; i++)
 		pwm_disable(&pc->chip.pwms[i]);
 
 	clk_unprepare(pc->pwm_clk);
-- 
1.9.1



From lee.jones at linaro.org  Wed Feb 10 05:02:25 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 13:02:25 +0000
Subject: [PATCH 08/11] pwm: sti: Add support for PWM Capture IRQs
In-Reply-To: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
References: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1455109348-32767-9-git-send-email-lee.jones@linaro.org>

Here we're requesting the PWM Capture IRQ and supplying the
handler which will be called in the event of an IRQ fire to
handle it.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/pwm/pwm-sti.c | 91 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 90 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
index fca692a..82a69e4 100644
--- a/drivers/pwm/pwm-sti.c
+++ b/drivers/pwm/pwm-sti.c
@@ -12,6 +12,7 @@
 
 #include <linux/clk.h>
 #include <linux/gpio.h>
+#include <linux/interrupt.h>
 #include <linux/math64.h>
 #include <linux/mfd/syscon.h>
 #include <linux/module.h>
@@ -94,7 +95,9 @@ struct sti_pwm_chip {
 	struct regmap_field *prescale_low;
 	struct regmap_field *prescale_high;
 	struct regmap_field *pwm_out_en;
+	struct regmap_field *pwm_cpt_en;
 	struct regmap_field *pwm_cpt_int_en;
+	struct regmap_field *pwm_cpt_int_stat;
 	struct pwm_chip chip;
 	struct pwm_device *cur;
 	unsigned long configured;
@@ -314,6 +317,74 @@ static const struct pwm_ops sti_pwm_ops = {
 	.owner = THIS_MODULE,
 };
 
+static irqreturn_t sti_pwm_interrupt(int irq, void *data)
+{
+	struct sti_pwm_chip *pc = data;
+	struct device *dev = pc->dev;
+	struct sti_cpt_data *d;
+	int channel;
+	int cpt_int_stat;
+	int reg;
+	int ret = IRQ_NONE;
+
+	ret = regmap_field_read(pc->pwm_cpt_int_stat, &cpt_int_stat);
+	if (ret)
+		return ret;
+
+	while (cpt_int_stat) {
+		channel = ffs(cpt_int_stat) - 1;
+
+		d = pc->cpt_data[channel];
+
+		/*
+		 * Capture input:
+		 *    _______                   _______
+		 *   |       |                 |       |
+		 * __|       |_________________|       |________
+		 *   ^0      ^1                ^2
+		 *
+		 * Capture start by the first available rising edge
+		 * When a capture event occurs, capture value (CPT_VALx)
+		 * is stored, index incremented, capture edge changed.
+		 *
+		 * After the capture, if the index > 1, we have collected
+		 * the necessary data so we signal the thread waiting for it
+		 * and disable the capture by setting capture edge to none
+		 *
+		 */
+
+		regmap_read(pc->regmap,
+			    PWM_CPT_VAL(channel), &d->snapshot[d->index]);
+
+		switch (d->index) {
+		case 0:
+		case 1:
+			regmap_read(pc->regmap, PWM_CPT_EDGE(channel), &reg);
+			reg ^= PWM_CPT_EDGE_MASK;
+			regmap_write(pc->regmap, PWM_CPT_EDGE(channel), reg);
+
+			d->index++;
+			break;
+		case 2:
+			regmap_write(pc->regmap,
+				     PWM_CPT_EDGE(channel), CPT_EDGE_DISABLED);
+			wake_up(&d->wait);
+			break;
+		default:
+			dev_err(dev, "Internal error\n");
+		}
+
+		clear_bit(channel, (unsigned long int *)&cpt_int_stat);
+
+		ret = IRQ_HANDLED;
+	}
+
+	/* Just ACK everything */
+	regmap_write(pc->regmap, PWM_INT_ACK, PWM_INT_ACK_MASK);
+
+	return ret;
+}
+
 static int sti_pwm_probe_dt(struct sti_pwm_chip *pc)
 {
 	struct device *dev = pc->dev;
@@ -354,6 +425,11 @@ static int sti_pwm_probe_dt(struct sti_pwm_chip *pc)
 	if (IS_ERR(pc->pwm_cpt_int_en))
 		return PTR_ERR(pc->pwm_cpt_int_en);
 
+	pc->pwm_cpt_int_stat = devm_regmap_field_alloc(dev, pc->regmap,
+						reg_fields[PWM_CPT_INT_STAT]);
+	if (IS_ERR(pc->pwm_cpt_int_stat))
+		return PTR_ERR(pc->pwm_cpt_int_stat);
+
 	return 0;
 }
 
@@ -371,7 +447,7 @@ static int sti_pwm_probe(struct platform_device *pdev)
 	struct sti_pwm_chip *pc;
 	struct resource *res;
 	unsigned int chan;
-	int ret;
+	int ret, irq;
 
 	pc = devm_kzalloc(dev, sizeof(*pc), GFP_KERNEL);
 	if (!pc)
@@ -392,6 +468,19 @@ static int sti_pwm_probe(struct platform_device *pdev)
 	if (IS_ERR(pc->regmap))
 		return PTR_ERR(pc->regmap);
 
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "Failed to obtain IRQ\n");
+		return -ENODEV;
+	}
+
+	ret = devm_request_irq(&pdev->dev, irq, sti_pwm_interrupt,
+			       0, pdev->name, (void *) pc);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed to request IRQ\n");
+		return ret;
+	}
+
 	/*
 	 * Setup PWM data with default values: some values could be replaced
 	 * with specific ones provided from Device Tree.
-- 
1.9.1



From lee.jones at linaro.org  Wed Feb 10 05:02:28 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 13:02:28 +0000
Subject: [PATCH 11/11] pwm: sti: Take the opportunity to conduct a little
 house keeping
In-Reply-To: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
References: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1455109348-32767-12-git-send-email-lee.jones@linaro.org>

This includes fixing some Coding Style issues and re-ordering/
simplifying a little code.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/pwm/pwm-sti.c | 27 ++++++++++++++-------------
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
index 93cf20e..93e3abf 100644
--- a/drivers/pwm/pwm-sti.c
+++ b/drivers/pwm/pwm-sti.c
@@ -144,13 +144,13 @@ static int sti_pwm_get_prescale(struct sti_pwm_chip *pc, unsigned long period,
 	val = NSEC_PER_SEC / clk_rate;
 	val *= cdata->max_pwm_cnt + 1;
 
-	if (period % val) {
+	if (period % val)
 		return -EINVAL;
-	} else {
-		ps  = period / val - 1;
-		if (ps > cdata->max_prescale)
-			return -EINVAL;
-	}
+
+	ps  = period / val - 1;
+	if (ps > cdata->max_prescale)
+		return -EINVAL;
+
 	*prescale = ps;
 
 	return 0;
@@ -166,7 +166,7 @@ static int sti_pwm_get_prescale(struct sti_pwm_chip *pc, unsigned long period,
  * 256 values.
  */
 static int sti_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
-			 int duty_ns, int period_ns)
+			int duty_ns, int period_ns)
 {
 	struct sti_pwm_chip *pc = to_sti_pwmchip(chip);
 	struct sti_pwm_compat_data *cdata = pc->cdata;
@@ -212,7 +212,7 @@ static int sti_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 
 			ret =
 			regmap_field_write(pc->prescale_low,
-					   prescale & PWM_PRESCALE_LOW_MASK);
+				prescale & PWM_PRESCALE_LOW_MASK);
 			if (ret)
 				goto clk_dis;
 
@@ -506,7 +506,7 @@ static int sti_pwm_probe_dt(struct sti_pwm_chip *pc)
 		return PTR_ERR(pc->pwm_cpt_en);
 
 	pc->pwm_cpt_int_en = devm_regmap_field_alloc(dev, pc->regmap,
-						 reg_fields[PWM_CPT_INT_EN]);
+						reg_fields[PWM_CPT_INT_EN]);
 	if (IS_ERR(pc->pwm_cpt_int_en))
 		return PTR_ERR(pc->pwm_cpt_int_en);
 
@@ -570,10 +570,11 @@ static int sti_pwm_probe(struct platform_device *pdev)
 	 * Setup PWM data with default values: some values could be replaced
 	 * with specific ones provided from Device Tree.
 	 */
-	cdata->reg_fields   = &sti_pwm_regfields[0];
-	cdata->max_prescale = 0xff;
-	cdata->max_pwm_cnt  = 255;
-	cdata->pwm_num_chan     = 1;
+
+	cdata->reg_fields	= &sti_pwm_regfields[0];
+	cdata->max_prescale	= 0xff;
+	cdata->max_pwm_cnt	= 255;
+	cdata->pwm_num_chan	= 1;
 	cdata->cpt_num_chan	= 0;
 
 	pc->cdata = cdata;
-- 
1.9.1



From lee.jones at linaro.org  Wed Feb 10 05:02:26 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 13:02:26 +0000
Subject: [PATCH 09/11] pwm: sti: Add PWM Capture call-back
In-Reply-To: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
References: <1455109348-32767-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1455109348-32767-10-git-send-email-lee.jones@linaro.org>

Once a PWM Capture has been initiated, the capture call
enables a rising edge detection IRQ, then waits.  Once each
of the 3 phase changes have been recorded the thread then
wakes.  The remaining part of the call carries out the
relevant calculations and passes back a formatted string to
the caller.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/pwm/pwm-sti.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c
index 82a69e4..8de9b4a 100644
--- a/drivers/pwm/pwm-sti.c
+++ b/drivers/pwm/pwm-sti.c
@@ -309,7 +309,79 @@ static void sti_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
 	clear_bit(pwm->hwpwm, &pc->configured);
 }
 
+static int sti_pwm_capture(struct pwm_chip *chip, struct pwm_device *pwm,
+			   int channel, char *buf)
+{
+	struct sti_pwm_chip *pc = to_sti_pwmchip(chip);
+	struct sti_pwm_compat_data *cdata = pc->cdata;
+	struct sti_cpt_data *d = pc->cpt_data[channel];
+	struct device *dev = pc->dev;
+	unsigned int f, dc;
+	unsigned int high, low;
+	bool level;
+	int ret;
+
+	if (channel > cdata->cpt_num_chan - 1) {
+		dev_err(dev, "Channel %d is not valid\n", channel);
+		return -EINVAL;
+	}
+
+	mutex_lock(&d->lock);
+
+	/* Prepare capture measurement */
+	d->index = 0;
+	regmap_write(pc->regmap, PWM_CPT_EDGE(channel), CPT_EDGE_RISING);
+	regmap_field_write(pc->pwm_cpt_int_en, BIT(channel));
+	ret = wait_event_interruptible_timeout(d->wait, d->index > 1, HZ);
+
+	/*
+	 * In case we woke up for another reason than completion
+	 * make sure to disable the capture.
+	 */
+	regmap_write(pc->regmap, PWM_CPT_EDGE(channel), CPT_EDGE_DISABLED);
+
+	if (ret == -ERESTARTSYS)
+		goto out;
+
+	switch (d->index) {
+	case 0:
+	case 1:
+		/*
+		 * Getting here could mean :
+		 *  - input signal is constant of less than 1Hz
+		 *  - there is no input signal at all
+		 *
+		 * In such case the frequency is rounded down to 0
+		 * level of the supposed constant signal is reported
+		 * using duty cycle min and max values.
+		 */
+		level = gpio_get_value(d->gpio);
+
+		ret = sprintf(buf, "0:%u\n", level ? CPT_DC_MAX : 0);
+		break;
+	case 2:
+		/* We have evertying we need */
+		high = d->snapshot[1] - d->snapshot[0];
+		low  = d->snapshot[2] - d->snapshot[1];
+
+		/* Calculate frequency in Hz */
+		f = clk_get_rate(pc->cpt_clk) / (1 * (high + low));
+
+		/* Calculate the duty cycle */
+		dc = CPT_DC_MAX * high / (high + low);
+
+		ret = sprintf(buf, "%u:%u\n", f, dc);
+	default:
+		dev_err(dev, "Internal error\n");
+	}
+
+out:
+	mutex_unlock(&d->lock);
+	return ret;
+}
+
 static const struct pwm_ops sti_pwm_ops = {
+	.capture = sti_pwm_capture,
 	.config = sti_pwm_config,
 	.enable = sti_pwm_enable,
 	.disable = sti_pwm_disable,
-- 
1.9.1



From antoine.tenart at free-electrons.com  Wed Feb 10 05:23:00 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Wed, 10 Feb 2016 14:23:00 +0100
Subject: [PATCH v2 4/7] arm64: dts: alpine: add the MSIX node in the Alpine v2
 dtsi
In-Reply-To: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455110583-19515-5-git-send-email-antoine.tenart@free-electrons.com>

Following the addition of the Alpine MSIX controller driver, add the
corresponding node in the Alpine v2 device tree.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 arch/arm64/boot/dts/al/alpine-v2.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/al/alpine-v2.dtsi b/arch/arm64/boot/dts/al/alpine-v2.dtsi
index c021e077343b..5b7bef684256 100644
--- a/arch/arm64/boot/dts/al/alpine-v2.dtsi
+++ b/arch/arm64/boot/dts/al/alpine-v2.dtsi
@@ -139,6 +139,16 @@
 			/* 32 bit non prefetchable memory space */
 			ranges = <0x2000000 0x0 0xfe000000 0x0 0xfe000000 0x0 0x1000000>;
 			bus-range = <0x00 0x00>;
+			msi-parent = <&msix>;
+		};
+
+		msix: msix at fbe00000 {
+			compatible = "al,alpine-msix";
+			reg = <0x0 0xfbe00000 0x0 0x100000>;
+			interrupt-controller;
+			msi-controller;
+			al,msi-base-spi = <160>;
+			al,msi-num-spis = <160>;
 		};
 
 		io-fabric {
-- 
2.7.0



From antoine.tenart at free-electrons.com  Wed Feb 10 05:22:57 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Wed, 10 Feb 2016 14:22:57 +0100
Subject: [PATCH v2 1/7] irqchip/gic-v3: always return IRQ_SET_MASK_OK_DONE in
 gic_set_affinity
In-Reply-To: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455110583-19515-2-git-send-email-antoine.tenart@free-electrons.com>

Always return IRQ_SET_MASK_OK_DONE instead of IRQ_SET_MASK_OK when the
affinity has been updated. When using stacked irqchips, returning
IRQ_SET_MASK_OK_DONE means skipping all descendant irqchips.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
---
 drivers/irqchip/irq-gic-v3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index d7be6ddc34f6..ca120a99bd5a 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -634,7 +634,7 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
 	else
 		gic_dist_wait_for_rwp();
 
-	return IRQ_SET_MASK_OK;
+	return IRQ_SET_MASK_OK_DONE;
 }
 #else
 #define gic_set_affinity	NULL
-- 
2.7.0



From antoine.tenart at free-electrons.com  Wed Feb 10 05:22:59 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Wed, 10 Feb 2016 14:22:59 +0100
Subject: [PATCH v2 3/7] Documentation: bindings: document the Alpine MSIX
 driver
In-Reply-To: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455110583-19515-4-git-send-email-antoine.tenart@free-electrons.com>

Following the addition of the Alpine MSIX driver, this patch adds the
corresponding bindings documentation.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 .../interrupt-controller/al,alpine-msix.txt        | 24 ++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt

diff --git a/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt b/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
new file mode 100644
index 000000000000..c7d3d0192f5d
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
@@ -0,0 +1,24 @@
+Alpine MSIX controller
+
+Required properties:
+
+- compatible: should be "al,alpine-msix"
+- reg: physical base address and size of the registers
+- interrupt-parent: specifies the parent interrupt controller.
+- interrupt-controller: identifies the node as an interrupt controller
+- msi-controller: identifies the node as an PCI Message Signaled Interrupt
+		  controller
+- al,msi-base-spi: SPI base of the MSI frame
+- al,msi-num-spis: number of SPIs assigned to the MSI frame
+
+Example:
+
+msix: msix {
+	compatible = "al,alpine-msix";
+	reg = <0x0 0xfbe00000 0x0 0x100000>;
+	interrupt-parent = <&gic>;
+	interrupt-controller;
+	msi-controller;
+	al,msi-base-spi = <160>;
+	al,msi-num-spis = <160>;
+};
-- 
2.7.0



From antoine.tenart at free-electrons.com  Wed Feb 10 05:22:56 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Wed, 10 Feb 2016 14:22:56 +0100
Subject: [PATCH v2 0/7] irqchip: introduce the Alpine MSIX driver
Message-ID: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>

Hi all,

This series introduce the Alpine MSIX driver, and enables it in both
the Alpine v1 and Alpine v2 device trees.

This series depends on "[PATCH v2 0/3] arm64: introduce the Alpine support":
https://lkml.org/lkml/2016/2/10/83

You can find the series at:
https://github.com/atenart/linux.git 4.5-rc1/alpinev2-msix

Antoine

Since v1:
  - Added an interrupt-parent property in the documentation example.
  - Updated to use bitmap_*() instead of *_bit().
  - Removed the static irq_set_affinity to use irq_chip_set_affinity_parent().
  - Updated the address field to use phys_addr_t.
  - Added a comment on why we're setting bit 16 in the address.
  - Patched the gic_set_affinity() function in irqchip/gic-v3.

Antoine Tenart (7):
  irqchip/gic-v3: always return IRQ_SET_MASK_OK_DONE in gic_set_affinity
  irqchip: add the Alpine MSIX interrupt controller
  Documentation: bindings: document the Alpine MSIX driver
  arm64: dts: alpine: add the MSIX node in the Alpine v2 dtsi
  ARM: dts: alpine: add the MSIX node
  arm64: alpine: select the Alpine MSI controller driver
  arm: alpine: select the Alpine MSI controller driver

 .../interrupt-controller/al,alpine-msix.txt        |  24 ++
 arch/arm/boot/dts/alpine.dtsi                      |  10 +
 arch/arm/mach-alpine/Kconfig                       |   1 +
 arch/arm64/Kconfig.platforms                       |   1 +
 arch/arm64/boot/dts/al/alpine-v2.dtsi              |  10 +
 drivers/irqchip/Kconfig                            |   6 +
 drivers/irqchip/Makefile                           |   1 +
 drivers/irqchip/irq-alpine-msi.c                   | 293 +++++++++++++++++++++
 drivers/irqchip/irq-gic-v3.c                       |   2 +-
 9 files changed, 347 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
 create mode 100644 drivers/irqchip/irq-alpine-msi.c

-- 
2.7.0



From antoine.tenart at free-electrons.com  Wed Feb 10 05:22:58 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Wed, 10 Feb 2016 14:22:58 +0100
Subject: [PATCH v2 2/7] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455110583-19515-3-git-send-email-antoine.tenart@free-electrons.com>

This patch adds the Alpine MSIX interrupt controller driver.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 drivers/irqchip/Kconfig          |   6 +
 drivers/irqchip/Makefile         |   1 +
 drivers/irqchip/irq-alpine-msi.c | 293 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 300 insertions(+)
 create mode 100644 drivers/irqchip/irq-alpine-msi.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 715923d5236c..f20e5b28eb5f 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -60,6 +60,12 @@ config ARM_VIC_NR
 	  The maximum number of VICs available in the system, for
 	  power management.
 
+config ALPINE_MSI
+	bool
+	depends on PCI && PCI_MSI
+	select GENERIC_IRQ_CHIP
+	select PCI_MSI_IRQ_DOMAIN
+
 config ATMEL_AIC_IRQ
 	bool
 	select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 18caacb60d58..57f68e0eea74 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_IRQCHIP)			+= irqchip.o
 
+obj-$(CONFIG_ALPINE_MSI)		+= irq-alpine-msi.o
 obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2835.o
 obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2836.o
 obj-$(CONFIG_ARCH_EXYNOS)		+= exynos-combiner.o
diff --git a/drivers/irqchip/irq-alpine-msi.c b/drivers/irqchip/irq-alpine-msi.c
new file mode 100644
index 000000000000..f8712722a606
--- /dev/null
+++ b/drivers/irqchip/irq-alpine-msi.c
@@ -0,0 +1,293 @@
+/*
+ * Annapurna Labs MSIX support services
+ *
+ * Copyright (C) 2016, Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ *
+ * Antoine Tenart <antoine.tenart at free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/irqchip.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/msi.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_pci.h>
+#include <linux/pci.h>
+#include <linux/slab.h>
+
+#include <asm/irq.h>
+#include <asm-generic/msi.h>
+
+/* MSIX message address format: local GIC target */
+#define ALPINE_MSIX_SPI_TARGET_CLUSTER0		BIT(16)
+
+struct alpine_msix_data {
+	spinlock_t msi_map_lock;
+	phys_addr_t addr;
+	u32 spi_first;		/* The SGI number that MSIs start */
+	u32 num_spis;		/* The number of SGIs for MSIs */
+	unsigned long *msi_map;
+};
+
+static void alpine_msix_mask_msi_irq(struct irq_data *d)
+{
+	pci_msi_mask_irq(d);
+	irq_chip_mask_parent(d);
+}
+
+static void alpine_msix_unmask_msi_irq(struct irq_data *d)
+{
+	pci_msi_unmask_irq(d);
+	irq_chip_unmask_parent(d);
+}
+
+static struct irq_chip alpine_msix_irq_chip = {
+	.name			= "MSIx",
+	.irq_mask		= alpine_msix_mask_msi_irq,
+	.irq_unmask		= alpine_msix_unmask_msi_irq,
+	.irq_eoi		= irq_chip_eoi_parent,
+	.irq_set_affinity	= irq_chip_set_affinity_parent,
+};
+
+static int alpine_msix_allocate_sgi(struct alpine_msix_data *priv, int num_req)
+{
+	int first;
+
+	spin_lock(&priv->msi_map_lock);
+
+	first = bitmap_find_next_zero_area(priv->msi_map, priv->num_spis, 0,
+					   num_req, 0);
+	if (first >= priv->num_spis) {
+		spin_unlock(&priv->msi_map_lock);
+		return -ENOSPC;
+	}
+
+	bitmap_set(priv->msi_map, first, num_req);
+
+	spin_unlock(&priv->msi_map_lock);
+
+	return priv->spi_first + first;
+}
+
+static void alpine_msix_free_sgi(struct alpine_msix_data *priv, unsigned sgi,
+				 int num_req)
+{
+	int first = sgi - priv->spi_first;
+
+	spin_lock(&priv->msi_map_lock);
+
+	bitmap_clear(priv->msi_map, first, num_req);
+
+	spin_unlock(&priv->msi_map_lock);
+}
+
+static void alpine_msix_compose_msi_msg(struct irq_data *data,
+					struct msi_msg *msg)
+{
+	struct alpine_msix_data *priv = irq_data_get_irq_chip_data(data);
+	phys_addr_t msg_addr = priv->addr;
+
+	msg_addr |= (data->hwirq << 3);
+
+	msg->address_hi = upper_32_bits(msg_addr);
+	msg->address_lo = lower_32_bits(msg_addr);
+	msg->data = 0;
+}
+
+static struct msi_domain_info alpine_msix_domain_info = {
+	.flags	= MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+		  MSI_FLAG_PCI_MSIX,
+	.chip	= &alpine_msix_irq_chip,
+};
+
+static struct irq_chip middle_irq_chip = {
+	.name			= "alpine_msix_middle",
+	.irq_mask		= irq_chip_mask_parent,
+	.irq_unmask		= irq_chip_unmask_parent,
+	.irq_eoi		= irq_chip_eoi_parent,
+	.irq_set_affinity	= irq_chip_set_affinity_parent,
+	.irq_compose_msi_msg	= alpine_msix_compose_msi_msg,
+};
+
+static int alpine_msix_gic_domain_alloc(struct irq_domain *domain,
+					unsigned int virq, int sgi)
+{
+	struct irq_fwspec fwspec;
+	struct irq_data *d;
+	int ret;
+
+	if (!is_of_node(domain->parent->fwnode))
+		return -EINVAL;
+
+	fwspec.fwnode = domain->parent->fwnode;
+	fwspec.param_count = 3;
+	fwspec.param[0] = 0;
+	fwspec.param[1] = sgi;
+	fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
+
+	ret = irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
+	if (ret)
+		return ret;
+
+	d = irq_domain_get_irq_data(domain->parent, virq);
+	d->chip->irq_set_type(d, IRQ_TYPE_EDGE_RISING);
+
+	return 0;
+}
+
+static int alpine_msix_middle_domain_alloc(struct irq_domain *domain,
+					   unsigned int virq,
+					   unsigned int nr_irqs, void *args)
+{
+	struct alpine_msix_data *priv = domain->host_data;
+	int sgi, err, i;
+
+	sgi = alpine_msix_allocate_sgi(priv, nr_irqs);
+	if (sgi < 0)
+		return sgi;
+
+	for (i = 0; i < nr_irqs; i++) {
+		err = alpine_msix_gic_domain_alloc(domain, virq + i, sgi + i);
+		if (err)
+			goto err_sgi;
+
+		irq_domain_set_hwirq_and_chip(domain, virq + i, sgi + i,
+					      &middle_irq_chip, priv);
+	}
+
+	return 0;
+
+err_sgi:
+	while (--i >= 0)
+		irq_domain_free_irqs_parent(domain, virq, i);
+	alpine_msix_free_sgi(priv, sgi, nr_irqs);
+	return err;
+}
+
+static void alpine_msix_middle_domain_free(struct irq_domain *domain,
+					   unsigned int virq,
+					   unsigned int nr_irqs)
+{
+	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+	struct alpine_msix_data *priv = irq_data_get_irq_chip_data(d);
+
+	irq_domain_free_irqs_parent(domain, virq, nr_irqs);
+	alpine_msix_free_sgi(priv, d->hwirq, nr_irqs);
+}
+
+static const struct irq_domain_ops alpine_msix_middle_domain_ops = {
+	.alloc	= alpine_msix_middle_domain_alloc,
+	.free	= alpine_msix_middle_domain_free,
+};
+
+static int alpine_msix_init_domains(struct alpine_msix_data *priv,
+				    struct device_node *node)
+{
+	struct irq_domain *middle_domain, *msi_domain, *gic_domain;
+	struct device_node *gic_node;
+
+	gic_node = of_irq_find_parent(node);
+	if (!gic_node) {
+		pr_err("Failed to find the GIC node\n");
+		return -ENODEV;
+	}
+
+	gic_domain = irq_find_host(gic_node);
+	if (!gic_domain) {
+		pr_err("Failed to find the GIC domain\n");
+		return -ENXIO;
+	}
+
+	middle_domain = irq_domain_add_tree(NULL,
+					    &alpine_msix_middle_domain_ops,
+					    priv);
+	if (!middle_domain) {
+		pr_err("Failed to create the MSIX middle domain\n");
+		return -ENOMEM;
+	}
+
+	middle_domain->parent = gic_domain;
+
+	msi_domain = pci_msi_create_irq_domain(of_node_to_fwnode(node),
+					       &alpine_msix_domain_info,
+					       middle_domain);
+	if (!msi_domain) {
+		pr_err("Failed to create MSI domain\n");
+		irq_domain_remove(msi_domain);
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+static int alpine_msix_init(struct device_node *node,
+			    struct device_node *parent)
+{
+	struct alpine_msix_data *priv;
+	struct resource res;
+	int ret;
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	spin_lock_init(&priv->msi_map_lock);
+
+	ret = of_address_to_resource(node, 0, &res);
+	if (ret) {
+		pr_err("Failed to allocate resource\n");
+		goto err_priv;
+	}
+
+	/*
+	 * The 20 least significant bits of addr provide direct information
+	 * regarding the interrupt destination.
+	 *
+	 * To select the primary GIC as the target GIC, bits [18:17] must be set
+	 * to 0x0. In this case, bit 16 (SPI_TARGET_CLUSTER0) must be set.
+	 */
+	priv->addr = res.start & GENMASK_ULL(63,20);
+	priv->addr |= ALPINE_MSIX_SPI_TARGET_CLUSTER0;
+
+	if (of_property_read_u32(node, "al,msi-base-spi", &priv->spi_first)) {
+		pr_err("Unable to parse MSI base\n");
+		ret = -EINVAL;
+		goto err_priv;
+	}
+
+	if (of_property_read_u32(node, "al,msi-num-spis", &priv->num_spis)) {
+		pr_err("Unable to parse MSI numbers\n");
+		ret = -EINVAL;
+		goto err_priv;
+	}
+
+	priv->msi_map = kzalloc(sizeof(*priv->msi_map) * BITS_TO_LONGS(priv->num_spis),
+				GFP_KERNEL);
+	if (!priv->msi_map) {
+		ret = -ENOMEM;
+		goto err_priv;
+	}
+
+	pr_debug("Registering %d msixs, starting at %d\n",
+		 priv->num_spis, priv->spi_first);
+
+	ret = alpine_msix_init_domains(priv, node);
+	if (ret)
+		goto err_map;
+
+	return 0;
+
+err_map:
+	kfree(priv->msi_map);
+err_priv:
+	kfree(priv);
+	return ret;
+}
+IRQCHIP_DECLARE(alpine_msix, "al,alpine-msix", alpine_msix_init);
-- 
2.7.0



From antoine.tenart at free-electrons.com  Wed Feb 10 05:23:01 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Wed, 10 Feb 2016 14:23:01 +0100
Subject: [PATCH v2 5/7] ARM: dts: alpine: add the MSIX node
In-Reply-To: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455110583-19515-6-git-send-email-antoine.tenart@free-electrons.com>

With the newly available MSIX driver for Alpine, add the corresponding
node in the Alpine device tree.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
---
 arch/arm/boot/dts/alpine.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/alpine.dtsi b/arch/arm/boot/dts/alpine.dtsi
index 9af2d60e9a7f..db8752fc480e 100644
--- a/arch/arm/boot/dts/alpine.dtsi
+++ b/arch/arm/boot/dts/alpine.dtsi
@@ -155,6 +155,16 @@
 			ranges = <0x02000000 0x0 0xfe000000 0x0 0xfe000000 0x0 0x1000000>;
 
 			bus-range = <0x00 0x00>;
+			msi-parent = <&msix>;
+		};
+
+		msix: msix at fbe00000 {
+			compatible = "al,alpine-msix";
+			reg = <0x0 0xfbe00000 0x0 0x100000>;
+			interrupt-controller;
+			msi-controller;
+			al,msi-base-spi = <96>;
+			al,msi-num-spis = <64>;
 		};
 	};
 };
-- 
2.7.0



From antoine.tenart at free-electrons.com  Wed Feb 10 05:23:02 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Wed, 10 Feb 2016 14:23:02 +0100
Subject: [PATCH v2 6/7] arm64: alpine: select the Alpine MSI controller driver
In-Reply-To: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455110583-19515-7-git-send-email-antoine.tenart@free-electrons.com>

Select the Alpine MSI controller driver when using an Alpine platform.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index bfbefa3e0dbe..6761e12e5e13 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -2,6 +2,7 @@ menu "Platform selection"
 
 config ARCH_ALPINE
 	bool "Annapurna Labs Alpine platform"
+	select ALPINE_MSI
 	help
 	  This enables support for the Annapurna Labs Alpine
 	  Soc family.
-- 
2.7.0



From antoine.tenart at free-electrons.com  Wed Feb 10 05:23:03 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Wed, 10 Feb 2016 14:23:03 +0100
Subject: [PATCH v2 7/7] arm: alpine: select the Alpine MSI controller driver
In-Reply-To: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455110583-19515-8-git-send-email-antoine.tenart@free-electrons.com>

Select the Alpine MSI controller driver when using an Alpine platform.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 arch/arm/mach-alpine/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-alpine/Kconfig b/arch/arm/mach-alpine/Kconfig
index 5c2d54f59f53..b41838a58ae4 100644
--- a/arch/arm/mach-alpine/Kconfig
+++ b/arch/arm/mach-alpine/Kconfig
@@ -1,6 +1,7 @@
 config ARCH_ALPINE
 	bool "Annapurna Labs Alpine platform"
 	depends on ARCH_MULTI_V7
+	select ALPINE_MSI
 	select ARM_AMBA
 	select ARM_GIC
 	select GENERIC_IRQ_CHIP
-- 
2.7.0



From lorenzo.pieralisi at arm.com  Wed Feb 10 05:30:37 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 10 Feb 2016 13:30:37 +0000
Subject: [PATCH v7 5/5] PCI: ACPI: Add a generic ACPI based host controller
In-Reply-To: <CAKc_7PVNm7z8nv_+Tr9FYhrVAA+-vh4CDMB83WAyT8tdi+CHzA@mail.gmail.com>
References: <1454058340-7904-1-git-send-email-jchandra@broadcom.com>
 <1454058340-7904-6-git-send-email-jchandra@broadcom.com>
 <20160205001907.GJ7031@localhost>
 <CAKc_7PXYtFt1MQE-UGO0O5vvQ+xFKa2b5=F8wXB=EN-JUJVzZw@mail.gmail.com>
 <20160205094740.GA31547@red-moon>
 <CAKc_7PVNm7z8nv_+Tr9FYhrVAA+-vh4CDMB83WAyT8tdi+CHzA@mail.gmail.com>
Message-ID: <20160210133037.GA25060@red-moon>

On Mon, Feb 08, 2016 at 04:57:46PM +0530, Jayachandran Chandrashekaran Nair wrote:
> Lorenzo,
> 
> On Fri, Feb 5, 2016 at 3:17 PM, Lorenzo Pieralisi
> <lorenzo.pieralisi at arm.com> wrote:
> > On Fri, Feb 05, 2016 at 02:05:37PM +0530, Jayachandran Chandrashekaran Nair wrote:
> >
> > [...]
> >
> >> pci_host_acpi.c is a generic implementation of these using a sysdata
> >> pointing to acpi_pci_root_info, and using a pointer to the pci_mmcfg_region
> >> to access ECAM area, Maybe I can rename this file to
> >> pci_acpi_host_generic.c to reflect this better.
> >
> > Maybe you should stop sending this series and work with Tomasz to
> > get this done, you are confusing everyone and I am really really
> > annoyed about this.
> >
> > Do you realize there is no point in having two patch series doing
> > the same thing and wasting everyone's review time ?
> >
> > Do you realize he started this work long before you and went through
> > several rounds of review already (I told you before but in case you
> > forgot) ?
> >
> > Tomasz posted a version yesterday, integrating comments following months
> > of review and testing and I think it is ready to get upstream:
> >
> > https://lkml.org/lkml/2016/2/4/646
> >
> > Did you even consider reviewing his code or helping him instead of
> > churning out more patches doing the *SAME* thing ?
> 
> This is getting ridiculous, I had replied to your earlier mails on why
> my patchset is NOT doing the exact same thing. I had also explained
> why helping was not feasible.
> 
> The basic point again: I am trying to give a much simpler patchset
> to solve the same problem, I take it that you haven't reviewed my
> patchset before writing this mail. I would have appreciated
> a technical discussion rather than this pointless flamefest.
> 
> If you have reviewed it, you can see that there are just 5 patches
> instead of 23, and that overall it is a much simpler approach.

Ok, let's make it constructive. I think there is part of your
implementation that definitely makes sense (in particular the way you
cleaned-up the x86 MCFG unadulterated mess - patch 1), I will ask
Tomasz to integrate it, please work together on this.

I have nothing against your patchset, my point is that we can't keep
reviewing and testing two series (and I mean on ARM64 AND x86), please
understand my point, it is very time consuming to understand the
differences and make sure we don't break x86 in the process and I would
have to ask you to add all the code that I already reviewed in Tomasz's
set, I just do not want to do that.

I will reply to Tomasz, let's work together to have a single final
implementation please, I do not think I am asking too much here and
yes, by integrating part of your code I think Tomasz's patchset is
ready to go, obviously subject to Bjorn's review and opinion.

Thanks,
Lorenzo


From marc.zyngier at arm.com  Wed Feb 10 05:34:44 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 13:34:44 +0000
Subject: [PATCH 7/8] KVM: arm/arm64: Avoid accessing GICH registers
In-Reply-To: <20160210124506.GN5171@cbox>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <1454931622-14902-8-git-send-email-marc.zyngier@arm.com>
 <20160210124506.GN5171@cbox>
Message-ID: <56BB3C74.9000105@arm.com>

On 10/02/16 12:45, Christoffer Dall wrote:
> On Mon, Feb 08, 2016 at 11:40:21AM +0000, Marc Zyngier wrote:
>> GICv2 registers are *slow*. As in "terrifyingly slow". Which is bad.
>> But we're equaly bad, as we make a point in accessing them even if
>> we don't have any interrupt in flight.
>>
>> A good solution is to first find out if we have anything useful to
>> write into the GIC, and if we don't, to simply not do it. This
>> involves tracking which LRs actually have something valid there.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kvm/hyp/vgic-v2-sr.c | 71 ++++++++++++++++++++++++++++-------------
>>  include/kvm/arm_vgic.h          |  2 ++
>>  2 files changed, 51 insertions(+), 22 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/hyp/vgic-v2-sr.c b/arch/arm64/kvm/hyp/vgic-v2-sr.c
>> index e717612..874a08d 100644
>> --- a/arch/arm64/kvm/hyp/vgic-v2-sr.c
>> +++ b/arch/arm64/kvm/hyp/vgic-v2-sr.c
>> @@ -38,28 +38,40 @@ void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
>>  
>>  	nr_lr = vcpu->arch.vgic_cpu.nr_lr;
>>  	cpu_if->vgic_vmcr = readl_relaxed(base + GICH_VMCR);
>> -	cpu_if->vgic_misr = readl_relaxed(base + GICH_MISR);
>> -	eisr0  = readl_relaxed(base + GICH_EISR0);
>> -	elrsr0 = readl_relaxed(base + GICH_ELRSR0);
>> -	if (unlikely(nr_lr > 32)) {
>> -		eisr1  = readl_relaxed(base + GICH_EISR1);
>> -		elrsr1 = readl_relaxed(base + GICH_ELRSR1);
>> -	} else {
>> -		eisr1 = elrsr1 = 0;
>> -	}
>> +
>> +	if (vcpu->arch.vgic_cpu.live_lrs) {
>> +		eisr0  = readl_relaxed(base + GICH_EISR0);
>> +		elrsr0 = readl_relaxed(base + GICH_ELRSR0);
>> +		cpu_if->vgic_misr = readl_relaxed(base + GICH_MISR);
>> +		cpu_if->vgic_apr    = readl_relaxed(base + GICH_APR);
>> +
>> +		if (unlikely(nr_lr > 32)) {
>> +			eisr1  = readl_relaxed(base + GICH_EISR1);
>> +			elrsr1 = readl_relaxed(base + GICH_ELRSR1);
>> +		} else {
>> +			eisr1 = elrsr1 = 0;
>> +		}
>> +
>>  #ifdef CONFIG_CPU_BIG_ENDIAN
>> -	cpu_if->vgic_eisr  = ((u64)eisr0 << 32) | eisr1;
>> -	cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
>> +		cpu_if->vgic_eisr  = ((u64)eisr0 << 32) | eisr1;
>> +		cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
>>  #else
>> -	cpu_if->vgic_eisr  = ((u64)eisr1 << 32) | eisr0;
>> -	cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
>> +		cpu_if->vgic_eisr  = ((u64)eisr1 << 32) | eisr0;
>> +		cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
>>  #endif
>> -	cpu_if->vgic_apr    = readl_relaxed(base + GICH_APR);
>>  
>> -	writel_relaxed(0, base + GICH_HCR);
>> +		for (i = 0; i < nr_lr; i++)
>> +			if (vcpu->arch.vgic_cpu.live_lrs & (1UL << i))
>> +				cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
>>  
>> -	for (i = 0; i < nr_lr; i++)
>> -		cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
>> +		writel_relaxed(0, base + GICH_HCR);
>> +
>> +		vcpu->arch.vgic_cpu.live_lrs = 0;
>> +	} else {
>> +		cpu_if->vgic_eisr = 0;
>> +		cpu_if->vgic_elrsr = ~0UL;
>> +		cpu_if->vgic_misr = 0;
>> +	}
>>  }
>>  
>>  /* vcpu is already in the HYP VA space */
>> @@ -70,15 +82,30 @@ void __hyp_text __vgic_v2_restore_state(struct kvm_vcpu *vcpu)
>>  	struct vgic_dist *vgic = &kvm->arch.vgic;
>>  	void __iomem *base = kern_hyp_va(vgic->vctrl_base);
>>  	int i, nr_lr;
>> +	u64 live_lrs = 0;
>>  
>>  	if (!base)
>>  		return;
>>  
>> -	writel_relaxed(cpu_if->vgic_hcr, base + GICH_HCR);
>> -	writel_relaxed(cpu_if->vgic_vmcr, base + GICH_VMCR);
>> -	writel_relaxed(cpu_if->vgic_apr, base + GICH_APR);
>> -
>>  	nr_lr = vcpu->arch.vgic_cpu.nr_lr;
>> +
>>  	for (i = 0; i < nr_lr; i++)
>> -		writel_relaxed(cpu_if->vgic_lr[i], base + GICH_LR0 + (i * 4));
>> +		if (cpu_if->vgic_lr[i] & GICH_LR_STATE)
>> +			live_lrs |= 1UL << i;
>> +
>> +	if (live_lrs) {
>> +		writel_relaxed(cpu_if->vgic_hcr, base + GICH_HCR);
>> +		writel_relaxed(cpu_if->vgic_apr, base + GICH_APR);
>> +		for (i = 0; i < nr_lr; i++) {
>> +			u32 val = 0;
>> +
>> +			if (live_lrs & (1UL << i))
>> +				val = cpu_if->vgic_lr[i];
>> +
>> +			writel_relaxed(val, base + GICH_LR0 + (i * 4));
>> +		}
>> +	}
>> +
>> +	writel_relaxed(cpu_if->vgic_vmcr, base + GICH_VMCR);
> 
> couldn't you optimize this out by storing the last read value and
> compare if anything changed?  (you'd have to invalidate the cached value
> on vcpu_put obviously).

Yeah, very good point. Only the guest can update this, so we could even
move it to vcpu_load/vcpu_put entirely, and never save/restore it inside
the run loop.

I'll keep that for a further patch, as it requires a bit of infrastructure.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From rob.herring at linaro.org  Wed Feb 10 05:42:02 2016
From: rob.herring at linaro.org (Rob Herring)
Date: Wed, 10 Feb 2016 07:42:02 -0600
Subject: breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi:
 Refactor A31 PLL6 so that it can be reused)
In-Reply-To: <56BB2D79.6090402@arm.com>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <56BB2D79.6090402@arm.com>
Message-ID: <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>

On Wed, Feb 10, 2016 at 6:30 AM, Andre Przywara <andre.przywara at arm.com> wrote:
> Hi,
>
> just a ping:
>
> Are we really OK with breaking existing DTs in 4.6? (per the code in
> -next: f7d372ba54ea04d528a291b8dbe34716507bb60b, which is this patch).

I only warn and make sure people are aware of the issue. I leave that
up to platform maintainers to decide. It depends on the maturity of
the platform and users. If people complain about it then it's their
mess. For platforms supported in distros such as debian or fedora, I
would strongly recommend against breaking compatibility. They do ship
dtbs, but it's a chicken and egg problem. If dtbs were stable and
provided by firmware, then they wouldn't have to provide them. If dtbs
are unstable, then they have no choice.

> Also I think one needs ACKs from DT maintainers before merging something
> in the respective directories, which I don't see here.

It can go in with subsystem maintainers ack, but there are problems
with this one regardless of compatibility.

> As I am somewhat blocked on that patch, I'd like to have some discussion
> on the list.
>
> Thanks,
> Andre.
>
> On 05/02/16 17:59, Andre Przywara wrote:
>> Hi Maxime,
>>
>> just found this while looking at your current git branch, so sorry for
>> the late reply.
>>
>> CC:ing DT people, since you touch both existing DTs(!) and the binding doc.
>>
>> On 01/02/16 20:20, Maxime Ripard wrote:
>>> Remove the fixed dividers from the PLL6 driver to be able to have a
>>> reusable driver that can be used across several SoCs that share the same
>>> controller, but don't have the same set of dividers for this clock, and to
>>> also be reused multiple times in the same SoC, since we're droping the
>>> clock name.

Removing a compatible name or not has nothing to do with sharing code.

>>>
>>> Acked-by: Chen-Yu Tsai <wens at csie.org>
>>> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
>>> ---
>>>
>>> Changes from v3:
>>>   - Fixed the documentation
>>>   - Added pll6d2 back
>>>
>>> Changes from v2:
>>>   - Rebased and converted over to the new factors refactoring. Fixed the
>>>     retrieved rate
>>>
>>>  Documentation/devicetree/bindings/clock/sunxi.txt |  2 +-
>>>  arch/arm/boot/dts/sun6i-a31.dtsi                  | 36 +++++++++++-----------
>>>  arch/arm/boot/dts/sun8i-a23-a33.dtsi              | 25 ++++++++++-----
>>>  arch/arm/boot/dts/sun8i-a23.dtsi                  |  2 +-
>>>  arch/arm/boot/dts/sun8i-a33.dtsi                  |  4 +--
>>>  arch/arm/boot/dts/sun8i-h3.dtsi                   | 37 ++++++++++++++---------
>>
>> So are you really breaking all those systems by changing the DT and the
>> driver in an incompatible way?
>> Please correct me if this assessment is wrong, but to me it looks like
>> any user out there is either stuck with 4.5 at best _or_ will only be
>> able to run 4.6 and later (depending on which version of the DT she is
>> using)? And no, switching DTs along with the kernel is _not_ an option.
>> That is not how I understand DT.
>> Also this totally ignores any other DT user (U-Boot, FreeBSD, you name it).
>>
>> I actually appreciate this rework, it's more flexible now and looks
>> better, but you really can't do this in a way to breaks compatibility
>> with existing DTs.
>>
>> Jean-Francois came up with another solution for the pll8 clock [1], so
>> could this be considered at least?
>> I think changing the H3 PLL8 clock from dummy to something real is a
>> different story in terms of compatibility (since it never really worked
>> before and this wouldn't change for any old-DT user).
>>
>> Cheers,
>> Andre.
>>
>> [1]
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/405104.html
>>
>>>  drivers/clk/sunxi/clk-sunxi.c                     | 32 ++++++++++----------
>>>  7 files changed, 78 insertions(+), 60 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
>>> index e59f57b24777..f82850c0f6a5 100644
>>> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
>>> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
>>> @@ -86,7 +86,7 @@ Required properties for all clocks:
>>>  - #clock-cells : from common clock binding; shall be set to 0 except for
>>>      the following compatibles where it shall be set to 1:
>>>      "allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk",
>>> -    "allwinner,sun4i-pll6-clk", "allwinner,sun6i-a31-pll6-clk",
>>> +    "allwinner,sun4i-pll6-clk",
>>>      "allwinner,*-usb-clk", "allwinner,*-mmc-clk",
>>>      "allwinner,*-mmc-config-clk"
>>>  - clock-output-names : shall be the corresponding names of the outputs.
>>> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
>>> index b6ad7850fac6..05fe3d1aa328 100644
>>> --- a/arch/arm/boot/dts/sun6i-a31.dtsi
>>> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
>>> @@ -65,7 +65,7 @@
>>>                      compatible = "allwinner,simple-framebuffer",
>>>                                   "simple-framebuffer";
>>>                      allwinner,pipeline = "de_be0-lcd0-hdmi";
>>> -                    clocks = <&pll6 0>;
>>> +                    clocks = <&pll6>;
>>>                      status = "disabled";
>>>              };
>>>
>>> @@ -73,7 +73,7 @@
>>>                      compatible = "allwinner,simple-framebuffer",
>>>                                   "simple-framebuffer";
>>>                      allwinner,pipeline = "de_be0-lcd0";
>>> -                    clocks = <&pll6 0>;
>>> +                    clocks = <&pll6>;
>>>                      status = "disabled";
>>>              };
>>>      };
>>> @@ -201,11 +201,11 @@
>>>              };
>>>
>>>              pll6: clk at 01c20028 {
>>> -                    #clock-cells = <1>;
>>> +                    #clock-cells = <0>;
>>>                      compatible = "allwinner,sun6i-a31-pll6-clk";

The name is removed, but remains here?


From alex.bennee at linaro.org  Wed Feb 10 05:49:14 2016
From: alex.bennee at linaro.org (Alex =?utf-8?Q?Benn=C3=A9e?=)
Date: Wed, 10 Feb 2016 13:49:14 +0000
Subject: [PATCH 1/8] arm64: KVM: Switch the sys_reg search to be a binary
 search
In-Reply-To: <1454931622-14902-2-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <1454931622-14902-2-git-send-email-marc.zyngier@arm.com>
Message-ID: <87ziv8vfol.fsf@linaro.org>


Marc Zyngier <marc.zyngier at arm.com> writes:

> Our 64bit sys_reg table is about 90 entries long (so far, and the
> PMU support is likely to increase this). This means that on average,
> it takes 45 comparaisons to find the right entry (and actually the
> full 90 if we have to search the invariant table).
>
> Not the most efficient thing. Specially when you think that this
> table is already sorted. Switching to a binary search effectively
> reduces the search to about 7 comparaisons. Slightly better!

Is there an argument for making this a hash table instead or is this not
possible as you would have to use dynamically allocated instead?

--
Alex Benn?e


From geert+renesas at glider.be  Wed Feb 10 05:56:53 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Wed, 10 Feb 2016 14:56:53 +0100
Subject: [PATCH v2 0/2] ARM: shmobile: Avoid writing to .text
Message-ID: <1455112615-6970-1-git-send-email-geert+renesas@glider.be>

        Hi Simon, Magnus,

When CONFIG_DEBUG_RODATA=y, the kernel crashes during system suspend:

    Freezing user space processes ... (elapsed 0.004 seconds) done.
    Freezing remaining freezable tasks ... (elapsed 0.002 seconds)
    done.
    PM: suspend of devices complete after 111.948 msecs
    PM: late suspend of devices complete after 1.086 msecs
    PM: noirq suspend of devices complete after 11.576 msecs
    Disabling non-boot CPUs ...
    Kernel panic - not syncing: Attempted to kill the idle task!
    1014ec ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
    CPU0: stopping

This happens because the shmobile assembler sources have several
variables that are written to in the .text section, while .text is
mapped read-only after kernel bootup if CONFIG_DEBUG_RODATA=y.

This series fixes this by moving variables from .text to .data, or just
removing them.
Note that there's still an issue with shmobile_boot_fn in
arch/arm/mach-shmobile/headsmp.S.  So far I didn't manage to fix this
(the code and data are copied to SRAM on some SoCs).  However, currently
this is mostly harmless, as this is written to during early kernel boot
up only, before .text is marked read-only. It does matter for XIP
(anyone using that with SMP?), so we do want to fix that in the long
run, too.

These issues were uncovered by "[PATCH v2] ARM: mm: flip priority of
CONFIG_DEBUG_RODATA". As that patch is already queued in arm/for-next, I
think all these fixes should be queued for v4.5, to avoid a dependency
with the arm tree.

Changes compared to v1:
  - Dropped "ARM: shmobile: Move shmobile_scu_base from .text to .data",
    which Simon has applied, and queued in soc-for-v4.6 (should be
    soc-for-v4.5?),
  - Added Reviewed-by,
  - Store offsets instead of pointers, as suggested by Nicolas Pitre
    <nicolas.pitre at linaro.org>,
  - Added "ARM: shmobile: Remove shmobile_boot_arg".

Tested hard on sh73a0/kzm9g, r8a7791/koelsch.
Tested lighter on emev2/kzm9d[*], r8a73a4/ape6evm, r8a7740/armadillo, and
r8a7779/marzen[*] ([*] = no remote resume).

Thanks!

Geert Uytterhoeven (2):
  ARM: shmobile: Move shmobile_smp_{mpidr,fn,arg}[] from .text to .data
  ARM: shmobile: Remove shmobile_boot_arg

 arch/arm/mach-shmobile/common.h       |  1 -
 arch/arm/mach-shmobile/headsmp.S      | 28 ++++++++++++++++------------
 arch/arm/mach-shmobile/platsmp-apmu.c |  1 -
 arch/arm/mach-shmobile/platsmp-scu.c  |  1 -
 4 files changed, 16 insertions(+), 15 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From geert+renesas at glider.be  Wed Feb 10 05:56:55 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Wed, 10 Feb 2016 14:56:55 +0100
Subject: [PATCH v2 2/2] ARM: shmobile: Remove shmobile_boot_arg
In-Reply-To: <1455112615-6970-1-git-send-email-geert+renesas@glider.be>
References: <1455112615-6970-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455112615-6970-3-git-send-email-geert+renesas@glider.be>

CPU boot configuration writes to shmobile_boot_arg, which is located in
the .text section, and thus should not be written to.

As of commit 1d33a354bbb618ba ("ARM: shmobile: Per-CPU SMP boot / sleep
code for SCU SoCs"), and ignoring accidental remainings,
shmobile_boot_arg is always set to MPIDR_HWID_BITMASK by C code.
Hence we can just hardcode this in the assembler code, and remove the
variable, and thus also remove the need to write to this variable.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v2:
  - New.
---
 arch/arm/mach-shmobile/common.h       | 1 -
 arch/arm/mach-shmobile/headsmp.S      | 8 ++------
 arch/arm/mach-shmobile/platsmp-apmu.c | 1 -
 arch/arm/mach-shmobile/platsmp-scu.c  | 1 -
 4 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/common.h b/arch/arm/mach-shmobile/common.h
index 225c12bb3de91e76..5464b7a75e3028a7 100644
--- a/arch/arm/mach-shmobile/common.h
+++ b/arch/arm/mach-shmobile/common.h
@@ -4,7 +4,6 @@
 extern void shmobile_init_delay(void);
 extern void shmobile_boot_vector(void);
 extern unsigned long shmobile_boot_fn;
-extern unsigned long shmobile_boot_arg;
 extern unsigned long shmobile_boot_size;
 extern void shmobile_smp_boot(void);
 extern void shmobile_smp_sleep(void);
diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index 4cf7f0b016b0b0fe..ede974b4fd67d8cd 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -24,7 +24,6 @@
 	.arm
 	.align  12
 ENTRY(shmobile_boot_vector)
-	ldr     r0, 2f
 	ldr     r1, 1f
 	bx	r1
 
@@ -34,9 +33,6 @@ ENDPROC(shmobile_boot_vector)
 	.globl	shmobile_boot_fn
 shmobile_boot_fn:
 1:	.space	4
-	.globl	shmobile_boot_arg
-shmobile_boot_arg:
-2:	.space	4
 	.globl	shmobile_boot_size
 shmobile_boot_size:
 	.long	. - shmobile_boot_vector
@@ -46,9 +42,9 @@ shmobile_boot_size:
  */
 
 ENTRY(shmobile_smp_boot)
-						@ r0 = MPIDR_HWID_BITMASK
 	mrc	p15, 0, r1, c0, c0, 5		@ r1 = MPIDR
-	and	r0, r1, r0			@ r0 = cpu_logical_map() value
+	and	r0, r1, #0xffffff		@ MPIDR_HWID_BITMASK
+						@ r0 = cpu_logical_map() value
 	mov	r1, #0				@ r1 = CPU index
 	adr	r2, 1f
 	ldmia	r2, {r5, r6, r7}
diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c b/arch/arm/mach-shmobile/platsmp-apmu.c
index 911884f7e28b174c..aba75c89f9c1c5eb 100644
--- a/arch/arm/mach-shmobile/platsmp-apmu.c
+++ b/arch/arm/mach-shmobile/platsmp-apmu.c
@@ -123,7 +123,6 @@ void __init shmobile_smp_apmu_prepare_cpus(unsigned int max_cpus,
 {
 	/* install boot code shared by all CPUs */
 	shmobile_boot_fn = virt_to_phys(shmobile_smp_boot);
-	shmobile_boot_arg = MPIDR_HWID_BITMASK;
 
 	/* perform per-cpu setup */
 	apmu_parse_cfg(apmu_init_cpu, apmu_config, num);
diff --git a/arch/arm/mach-shmobile/platsmp-scu.c b/arch/arm/mach-shmobile/platsmp-scu.c
index 4c7d2caf3730f644..8d478f1da265d55e 100644
--- a/arch/arm/mach-shmobile/platsmp-scu.c
+++ b/arch/arm/mach-shmobile/platsmp-scu.c
@@ -46,7 +46,6 @@ void __init shmobile_smp_scu_prepare_cpus(phys_addr_t scu_base_phys,
 {
 	/* install boot code shared by all CPUs */
 	shmobile_boot_fn = virt_to_phys(shmobile_smp_boot);
-	shmobile_boot_arg = MPIDR_HWID_BITMASK;
 
 	/* enable SCU and cache coherency on booting CPU */
 	shmobile_scu_base_phys = scu_base_phys;
-- 
1.9.1



From geert+renesas at glider.be  Wed Feb 10 05:56:54 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Wed, 10 Feb 2016 14:56:54 +0100
Subject: [PATCH v2 1/2] ARM: shmobile: Move shmobile_smp_{mpidr, fn,
 arg}[] from .text to .data
In-Reply-To: <1455112615-6970-1-git-send-email-geert+renesas@glider.be>
References: <1455112615-6970-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455112615-6970-2-git-send-email-geert+renesas@glider.be>

If CONFIG_DEBUG_RODATA=y, the kernel crashes during system suspend:

    Freezing user space processes ... (elapsed 0.004 seconds) done.
    Freezing remaining freezable tasks ... (elapsed 0.002 seconds)
    done.
    PM: suspend of devices complete after 111.948 msecs
    PM: late suspend of devices complete after 1.086 msecs
    PM: noirq suspend of devices complete after 11.576 msecs
    Disabling non-boot CPUs ...
    Kernel panic - not syncing: Attempted to kill the idle task!
    1014ec ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
    CPU0: stopping

This happens because the .text section is marked read-only, while the
arrays shmobile_smp_mpidr[], shmobile_smp_fn[], and shmobile_smp_arg[]
are being written to.

Fix this by moving these arrays from the .text to the .data section.
This requires accessing them through PC-relative offsets.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Reviewed-by: Kees Cook <keescook at chromium.org>
---
v2:
  - Add Reviewed-by,
  - Store offsets instead of pointers, as suggested by Nicolas Pitre
    <nicolas.pitre at linaro.org>.
---
 arch/arm/mach-shmobile/headsmp.S | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index 330c1fc63197df89..4cf7f0b016b0b0fe 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -50,9 +50,11 @@ ENTRY(shmobile_smp_boot)
 	mrc	p15, 0, r1, c0, c0, 5		@ r1 = MPIDR
 	and	r0, r1, r0			@ r0 = cpu_logical_map() value
 	mov	r1, #0				@ r1 = CPU index
-	adr	r5, 1f				@ array of per-cpu mpidr values
-	adr	r6, 2f				@ array of per-cpu functions
-	adr	r7, 3f				@ array of per-cpu arguments
+	adr	r2, 1f
+	ldmia	r2, {r5, r6, r7}
+	add	r5, r5, r2			@ array of per-cpu mpidr values
+	add	r6, r6, r2			@ array of per-cpu functions
+	add	r7, r7, r2			@ array of per-cpu arguments
 
 shmobile_smp_boot_find_mpidr:
 	ldr	r8, [r5, r1, lsl #2]
@@ -80,12 +82,18 @@ ENTRY(shmobile_smp_sleep)
 	b	shmobile_smp_boot
 ENDPROC(shmobile_smp_sleep)
 
+	.align	2
+1:	.long	shmobile_smp_mpidr - .
+	.long	shmobile_smp_fn - 1b
+	.long	shmobile_smp_arg - 1b
+
+	.data
 	.globl	shmobile_smp_mpidr
 shmobile_smp_mpidr:
-1:	.space	NR_CPUS * 4
+	.space	NR_CPUS * 4
 	.globl	shmobile_smp_fn
 shmobile_smp_fn:
-2:	.space	NR_CPUS * 4
+	.space	NR_CPUS * 4
 	.globl	shmobile_smp_arg
 shmobile_smp_arg:
-3:	.space	NR_CPUS * 4
+	.space	NR_CPUS * 4
-- 
1.9.1



From marc.zyngier at arm.com  Wed Feb 10 06:00:34 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 14:00:34 +0000
Subject: [PATCH 1/8] arm64: KVM: Switch the sys_reg search to be a binary
 search
In-Reply-To: <87ziv8vfol.fsf@linaro.org>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <1454931622-14902-2-git-send-email-marc.zyngier@arm.com>
 <87ziv8vfol.fsf@linaro.org>
Message-ID: <56BB4282.6040005@arm.com>

On 10/02/16 13:49, Alex Benn?e wrote:
> 
> Marc Zyngier <marc.zyngier at arm.com> writes:
> 
>> Our 64bit sys_reg table is about 90 entries long (so far, and the
>> PMU support is likely to increase this). This means that on average,
>> it takes 45 comparaisons to find the right entry (and actually the
>> full 90 if we have to search the invariant table).
>>
>> Not the most efficient thing. Specially when you think that this
>> table is already sorted. Switching to a binary search effectively
>> reduces the search to about 7 comparaisons. Slightly better!
> 
> Is there an argument for making this a hash table instead or is this not
> possible as you would have to use dynamically allocated instead?

I believe it would be possible, assuming we have the right hash. Another
alternative would be a radix tree, which would always give us the right
sysreg in four memory accesses. It has some impacts on the memory side,
but that's shouldn't a blocker.

As I said, the binary search was a very low hanging fruit, so it made
some sense to implement it and see how we fared. Finding the perfect
data structure is left as an exercise for the reader! ;-)

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From thomas.petazzoni at free-electrons.com  Wed Feb 10 06:00:46 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Feb 2016 15:00:46 +0100
Subject: [PATCH v2 0/6] irqchip: irq-armada-370-xp: generic MSI
 infrastructure and assorted fixes
In-Reply-To: <1453899395-3532-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1453899395-3532-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20160210150046.118fc991@free-electrons.com>

Hello,

On Wed, 27 Jan 2016 13:56:29 +0100, Thomas Petazzoni wrote:

> Thomas Petazzoni (6):
>   irqchip: irq-armada-370-xp: add Kconfig option for the driver
>   irqchip: irq-armada-370-xp: use the generic MSI infrastructure
>   irqchip: irq-armada-370-xp: use PCI_MSI_DOORBELL_START where
>     appropriate
>   irqchip: irq-armada-370-xp: use shorter names for irq_chip
>   irqchip: irq-armada-370-xp: allow allocation of multiple MSIs
>   ARM: mvebu: use the ARMADA_370_XP_IRQ option

Jason, Thomas, any chance to get this applied soonish?

The core patch of the series, which migrates the irq-armada-370-xp
driver to use the generic MSI infrastructure has been Reviewed-by: Marc
Zyngier, and the other patches in the series have Acked-by/Reviewed-by
from Gregory Clement.

Of course, if there's anything left to be changed, I'd be happy to
respin a new version of this series.

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From rob.herring at linaro.org  Wed Feb 10 06:02:45 2016
From: rob.herring at linaro.org (Rob Herring)
Date: Wed, 10 Feb 2016 08:02:45 -0600
Subject: [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused
In-Reply-To: <20160210125936.GD31506@lukather>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <20160210125936.GD31506@lukather>
Message-ID: <CABGGisxORFOxLVQiTZ=gEr6j2JnVcjQxTLJFPa7uG93g46CKwg@mail.gmail.com>

On Wed, Feb 10, 2016 at 6:59 AM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> Hi,
>
> On Fri, Feb 05, 2016 at 05:59:23PM +0000, Andre Przywara wrote:
>> Hi Maxime,
>>
>> just found this while looking at your current git branch, so sorry for
>> the late reply.
>>
>> CC:ing DT people, since you touch both existing DTs(!) and the binding doc.

[...]

>> So are you really breaking all those systems by changing the DT and the
>> driver in an incompatible way?
>
> Yes.
>
>> Please correct me if this assessment is wrong, but to me it looks like
>> any user out there is either stuck with 4.5 at best _or_ will only be
>> able to run 4.6 and later (depending on which version of the DT she is
>> using)? And no, switching DTs along with the kernel is _not_ an option.
>
> It is. And it is one that every other ARM platform chose. And so did
> every distribution.

I do leave it to platform maintainers judgement (perhaps that should
be reconsidered), but it should still be case by case basis not an all
out disregard for the ABI. If you decide to ignore the ABI, then there
is no decision for the distros or other users.

>> That is not how I understand DT.
>
> I'm sorry for that. This has never been something we said was
> happening.
>
>> Also this totally ignores any other DT user (U-Boot, FreeBSD, you
>> name it).
>
> Which all have their own DT copies, with their own bindings, that we
> (ie Linux) never agreed on.

That is not really true. There are some differences ATM, but they are
largely derivatives of the kernel copy and the goal is to align them.
If we don't maintain an ABI, that will never happen.

> By further extending that argument, you're currently looking at the DT
> from Allwinner, do you want to support theirs as well?

Vendor ones we treat like vendor kernels. However, if the differences
come down to bikeshedding, then we will take vendor bindings to
maintain the ABI. That's generally only when the compatible string
differs though.

Rob


From lorenzo.pieralisi at arm.com  Wed Feb 10 06:06:03 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 10 Feb 2016 14:06:03 +0000
Subject: [PATCH V4 15/23] acpi, mcfg: Implement two calls that might be
 used to inject/remove MCFG region.
In-Reply-To: <1454606941-9523-16-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
 <1454606941-9523-16-git-send-email-tn@semihalf.com>
Message-ID: <20160210140602.GB25060@red-moon>

On Thu, Feb 04, 2016 at 06:28:53PM +0100, Tomasz Nowicki wrote:
> Lets abstract two calls which allow to inject and remove MCFG regions
> which may come from DSDT table. These calls will be used for x86 and ARM64
> PCI host bridge driver in the later patches.
> 
> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
> Tested-by: Duc Dang <dhdang at apm.com>
> Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
> Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
> Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
> Tested-by: Sinan Kaya <okaya at codeaurora.org>
> ---
>  drivers/acpi/mcfg.c      | 38 ++++++++++++++++++++++++++++++++++++++
>  include/linux/pci-acpi.h |  9 +++++++++
>  2 files changed, 47 insertions(+)
> 
> diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
> index 3e1e7be..dca4c4e 100644
> --- a/drivers/acpi/mcfg.c
> +++ b/drivers/acpi/mcfg.c
> @@ -10,6 +10,7 @@
>  #include <linux/acpi.h>
>  #include <linux/ecam.h>
>  #include <linux/pci.h>
> +#include <linux/pci-acpi.h>
>  
>  #define	PREFIX	"MCFG: "
>  
> @@ -77,6 +78,43 @@ int __init acpi_parse_mcfg(struct acpi_table_header *header)
>  	return 0;
>  }
>  
> +int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci)
> +{
> +	struct pci_mmcfg_region *cfg;
> +	struct acpi_pci_root *root;
> +	int seg, start, end, err;
> +
> +	root = ci->root;
> +	seg = root->segment;
> +	start = root->secondary.start;
> +	end = root->secondary.end;
> +
> +	cfg = pci_mmconfig_lookup(seg, start);
> +	if (cfg)
> +		return 0;
> +
> +	cfg = pci_mmconfig_alloc(seg, start, end, root->mcfg_addr);
> +	if (!cfg)
> +		return -ENOMEM;
> +
> +	err = pci_mmconfig_inject(cfg);
> +	return err;

When you integrate Jayachandran's patch this whole function will
become a pci_mmconfig_insert() and that's where hot_added should
be set.

> +}
> +
> +void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci)
> +{
> +	struct acpi_pci_root *root = ci->root;
> +	struct pci_mmcfg_region *cfg;
> +
> +	cfg = pci_mmconfig_lookup(root->segment, root->secondary.start);
> +	if (!cfg)
> +		return;
> +
> +	if (cfg->hot_added)

Move the hot_added check in pci_mmconfig_delete() (that does the look
up again), we do not want to carry out pci_mmconfig_lookup only to
check that flag here (and we miss rcu locking for the look-up BTW).

Thanks,
Lorenzo

> +		pci_mmconfig_delete(root->segment, root->secondary.start,
> +				    root->secondary.end);
> +}
> +
>  int __init __weak acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
>  					struct acpi_mcfg_allocation *cfg)
>  {
> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
> index a72e22d..65b91f3 100644
> --- a/include/linux/pci-acpi.h
> +++ b/include/linux/pci-acpi.h
> @@ -80,6 +80,15 @@ extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>  void acpi_pci_add_bus(struct pci_bus *bus);
>  void acpi_pci_remove_bus(struct pci_bus *bus);
>  
> +#ifdef	CONFIG_PCI_MMCONFIG
> +int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci);
> +void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci);
> +#else
> +static inline int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci)
> +{ return 0; }
> +static inline void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci) { }
> +#endif
> +
>  #ifdef	CONFIG_ACPI_PCI_SLOT
>  void acpi_pci_slot_init(void);
>  void acpi_pci_slot_enumerate(struct pci_bus *bus);
> -- 
> 1.9.1
> 


From robh at kernel.org  Wed Feb 10 06:06:38 2016
From: robh at kernel.org (Rob Herring)
Date: Wed, 10 Feb 2016 08:06:38 -0600
Subject: [PATCH V5 10/14] Documentation: DT: bindings: Add power domain
 info for NVIDIA PMC
In-Reply-To: <56BB1787.4050801@nvidia.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-11-git-send-email-jonathanh@nvidia.com>
 <20160129160625.GA21918@rob-hp-laptop>
 <56B1DE40.7080403@nvidia.com>
 <CAL_JsqLcoKW2znNNvM=sYLmZ6O6ZWqn7+aXspkXoONw6-O1ygg@mail.gmail.com>
 <56BB1787.4050801@nvidia.com>
Message-ID: <CAL_JsqKAFEpo=W=2w=7+QrmMR8uJ5SsXpkuEj=E1axOraCQ9ZQ@mail.gmail.com>

On Wed, Feb 10, 2016 at 4:57 AM, Jon Hunter <jonathanh at nvidia.com> wrote:
>
> On 03/02/16 15:48, Rob Herring wrote:
>> On Wed, Feb 3, 2016 at 5:02 AM, Jon Hunter <jonathanh at nvidia.com> wrote:
>>>
>>> On 29/01/16 16:06, Rob Herring wrote:
>>>> On Thu, Jan 28, 2016 at 04:33:48PM +0000, Jon Hunter wrote:
>>>>> Add power-domain binding documentation for the NVIDIA PMC driver in
>>>>> order to support generic power-domains.
>>>>>
>>>>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
>>>>> ---
>>>>>  .../bindings/arm/tegra/nvidia,tegra20-pmc.txt      | 55 ++++++++++++++++++++++
>>>>>  1 file changed, 55 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>>>>> index 53aa5496c5cf..3c77373aa826 100644
>>>>> --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>>>>> +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>>>>> @@ -1,5 +1,7 @@
>>>>>  NVIDIA Tegra Power Management Controller (PMC)
>>>>>
>>>>> +== Power Management Controller Node ==
>>>>> +
>>>>>  The PMC block interacts with an external Power Management Unit. The PMC
>>>>>  mostly controls the entry and exit of the system from different sleep
>>>>>  modes. It provides power-gating controllers for SoC and CPU power-islands.
>>>>> @@ -70,6 +72,10 @@ Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'
>>>>>                       Defaults to 0. Valid values are described in section 12.5.2
>>>>>                       "Pinmux Support" of the Tegra4 Technical Reference Manual.
>>>>>
>>>>> +Optional nodes:
>>>>> +- powergates : This node contains a hierarchy of power domain nodes, which
>>>>> +           should match the powergates on the Tegra SoC.
>>>>> +
>>>>>  Example:
>>>>>
>>>>>  / SoC dts including file
>>>>> @@ -115,3 +121,52 @@ pmc at 7000f400 {
>>>>>      };
>>>>>      ...
>>>>>  };
>>>>> +
>>>>> +
>>>>> +== PM Domain Nodes ==
>>>>> +
>>>>> +Each of the PM domain nodes represents a power-domain on the Tegra SoC
>>>>> +that can be power-gated by the PMC and should be named appropriately.
>>>>> +
>>>>> +Required properties:
>>>>> +  - clocks: Must contain an entry for each clock required by the PMC for
>>>>> +    controlling a power-gate. See ../clocks/clock-bindings.txt for details.
>>>>> +  - resets: Must contain an entry for each reset required by the PMC for
>>>>> +    controlling a power-gate. See ../reset/reset.txt for details.
>>>>> +  - nvidia,powergate: Integer cell that contains an identifier for the PMC
>>>>> +    power-gate that is associated with the power-domain. Please refer to
>>>>> +    the Tegra TRM for more details.
>>>>
>>>> Why not make this value be the power-domain cell for consumers and the
>>>> pmc be the phandle.
>>>
>>> Is there anything wrong with using a label for the consumers? Seems
>>> simpler, if you can just say ...
>>>
>>>         adma: adma at 702e2000 {
>>>                 ...
>>>                 power-domains = <&pd_audio>;
>>>                 ...
>>>         };
>>
>> Only that is a bit unusual. It would only really matter if we had some
>> common parsing that we wanted to share. I'd look at other examples and
>> try to align. If there's no clear pattern, then it is fine.
>
> So I have been having a look at this and it appears to be mixed across
> the various SoCs. It seems that those SoCs that define the generic PM
> domains statically in the machine/soc code use a phandle plus a argument
> to identify the power domain. However, for those that describe the
> power-domain in the DT (listing clocks, resets, etc), they just use a
> phandle to the power-domain itself (like I have above). It looks like if
> you are describing the power domain in DT, then it is much simplier to
> do this.
>
> Given that I wish to keep the description of the power-domain in DT, it
> is much easier to stick with the same conventions that the other SoCs
> are using.

Okay.

Acked-by: Rob Herring <robh at kernel.org>

Rob


From marc.zyngier at arm.com  Wed Feb 10 06:08:17 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 14:08:17 +0000
Subject: [PATCH v2 0/6] irqchip: irq-armada-370-xp: generic MSI
 infrastructure and assorted fixes
In-Reply-To: <20160210150046.118fc991@free-electrons.com>
References: <1453899395-3532-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160210150046.118fc991@free-electrons.com>
Message-ID: <56BB4451.3070707@arm.com>

On 10/02/16 14:00, Thomas Petazzoni wrote:
> Hello,
> 
> On Wed, 27 Jan 2016 13:56:29 +0100, Thomas Petazzoni wrote:
> 
>> Thomas Petazzoni (6):
>>   irqchip: irq-armada-370-xp: add Kconfig option for the driver
>>   irqchip: irq-armada-370-xp: use the generic MSI infrastructure
>>   irqchip: irq-armada-370-xp: use PCI_MSI_DOORBELL_START where
>>     appropriate
>>   irqchip: irq-armada-370-xp: use shorter names for irq_chip
>>   irqchip: irq-armada-370-xp: allow allocation of multiple MSIs
>>   ARM: mvebu: use the ARMADA_370_XP_IRQ option
> 
> Jason, Thomas, any chance to get this applied soonish?
> 
> The core patch of the series, which migrates the irq-armada-370-xp
> driver to use the generic MSI infrastructure has been Reviewed-by: Marc
> Zyngier, and the other patches in the series have Acked-by/Reviewed-by
> from Gregory Clement.
> 
> Of course, if there's anything left to be changed, I'd be happy to
> respin a new version of this series.
> 

Noticing the distribution list, it would be good to repost these patches
with acks and co to LKML...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From thomas.petazzoni at free-electrons.com  Wed Feb 10 06:10:56 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Feb 2016 15:10:56 +0100
Subject: [PATCH v2 0/6] irqchip: irq-armada-370-xp: generic MSI
 infrastructure and assorted fixes
In-Reply-To: <56BB4451.3070707@arm.com>
References: <1453899395-3532-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160210150046.118fc991@free-electrons.com>
 <56BB4451.3070707@arm.com>
Message-ID: <20160210151056.08a57312@free-electrons.com>

Hello,

On Wed, 10 Feb 2016 14:08:17 +0000, Marc Zyngier wrote:

> > Jason, Thomas, any chance to get this applied soonish?
> > 
> > The core patch of the series, which migrates the irq-armada-370-xp
> > driver to use the generic MSI infrastructure has been Reviewed-by: Marc
> > Zyngier, and the other patches in the series have Acked-by/Reviewed-by
> > from Gregory Clement.
> > 
> > Of course, if there's anything left to be changed, I'd be happy to
> > respin a new version of this series.
> > 
> 
> Noticing the distribution list, it would be good to repost these patches
> with acks and co to LKML...

Right, will do. Thanks for the suggestion.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From julien.grall at arm.com  Wed Feb 10 06:19:08 2016
From: julien.grall at arm.com (Julien Grall)
Date: Wed, 10 Feb 2016 14:19:08 +0000
Subject: [PATCH 3/5] irqchip/gic-v2: Parse and export virtual GIC
 information
In-Reply-To: <20160209204914.GE5171@cbox>
References: <1454950049-741-1-git-send-email-julien.grall@arm.com>
 <1454950049-741-4-git-send-email-julien.grall@arm.com>
 <20160209204914.GE5171@cbox>
Message-ID: <56BB46DC.7080202@arm.com>

Hi Christoffer,

On 09/02/16 20:49, Christoffer Dall wrote:
>> +static void __init gic_acpi_setup_kvm_info(void)
>> +{
>> +	gic_v2_kvm_info.type = GIC_V2;
>> +
>> +	gic_v2_kvm_info.maint_irq = acpi_register_gsi(NULL,
>> +						      acpi_data.maint_irq,
>> +						      acpi_data.maint_irq_mode,
>> +						      ACPI_ACTIVE_HIGH);
>> +	gic_v2_kvm_info.vctrl_base = acpi_data.vctrl_base;
>> +	if (gic_v2_kvm_info.vctrl_base)
>> +		gic_v2_kvm_info.vctrl_size = SZ_8K;
>> +
>> +	gic_v2_kvm_info.vcpu_base = acpi_data.vcpu_base;
>> +	if (gic_v2_kvm_info.vcpu_base)
>> +		gic_v2_kvm_info.vcpu_size = SZ_8K;
>
> why are the sizes hard-coded to 8K in this case?

The MADT only provides the base addresses and not the size. The default 
value has been chosen based on the GICv2 spec (ARM IHI 0048B.b)
	* GICV: See 5.5
	* GICH: I can't find again the section about it. But the example 
bindings in 
Documents/devicetree/bindings/interrupt-controller/arm,gic.txt uses 8K.

I will add a comment in the code explaining where the 8K come from.

Cheers,

-- 
Julien Grall


From will.deacon at arm.com  Wed Feb 10 06:21:13 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 14:21:13 +0000
Subject: [PATCH v3 3/3] iommu/io-pgtable: Avoid redundant TLB syncs
In-Reply-To: <81a5e784494a04713e152659c95b34e92d944f32.1453723096.git.robin.murphy@arm.com>
References: <cover.1453723096.git.robin.murphy@arm.com>
 <81a5e784494a04713e152659c95b34e92d944f32.1453723096.git.robin.murphy@arm.com>
Message-ID: <20160210142112.GK1052@arm.com>

On Tue, Jan 26, 2016 at 05:13:15PM +0000, Robin Murphy wrote:
> In certain unmapping situations it is quite possible to end up issuing
> back-to-back TLB synchronisations, which at best is a waste of time and
> effort, and at worst causes some hardware to get rather confused. Whilst
> the pagetable implementations, or the IOMMU drivers, or both, could keep
> track of things to avoid this happening, it seems to make the most sense
> to prevent code duplication and add some simple state tracking in the
> common interface between the two.
> 
> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
>  drivers/iommu/io-pgtable.h | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)

Acked-by: Will Deacon <will.deacon at arm.com>

Will


From peter.maydell at linaro.org  Wed Feb 10 06:23:29 2016
From: peter.maydell at linaro.org (Peter Maydell)
Date: Wed, 10 Feb 2016 14:23:29 +0000
Subject: [PATCH] arm64: Rework valid_user_regs
In-Reply-To: <20160210123110.GD2632@leverpostej>
References: <1455041501-30018-1-git-send-email-mark.rutland@arm.com>
 <20160210115853.GG1052@arm.com> <20160210123110.GD2632@leverpostej>
Message-ID: <CAFEAcA-3mgxu6hNSOLhFMmfzB705xyZTyfa5eiRWX6MOnYMVvQ@mail.gmail.com>

On 10 February 2016 at 12:31, Mark Rutland <mark.rutland at arm.com> wrote:
> On Wed, Feb 10, 2016 at 11:58:53AM +0000, Will Deacon wrote:
>> I think we should err on the side of caution and nuke SS and IL for both
>> native and compat too, although that seems a odds with the PSR_s mask.
>> I wonder how relevant those PSR groups are in ARMv8...
>
> Ok.

If you nuke SS does that have any side effects in the case
of (for instance) interactions between ptrace single step
and ptrace syscall tracing? (ie do we ever end up in a situation
where the ptracer can read a PSR for the debuggee which has
SS set? if so then it should be able to write back the PSR
it has just read without any bits being unset.)

Clearing IL should be ok, though it's pretty harmless for
the user process to have IL set, it will just cause an exception.
(Userspace can't end up with IL set unless we allow it to by
doing an exception-return to EL0 with an IL-set SPSR.)

> I couldn't spot anything in the ARM ARM regarding PSR bit groups,; I was
> cargo-culting from the existing code. I'm more than happy to make the
> PSR_* groups an aarch32/compat thing.

It's not clear to me that they make much sense for 32-bit either.
NZCVQ are in PSR_f, but GE are in PSR_s. I and F are in
PSR_c but A is in PSR_x. Presumably we need to leave them in
the header file for back-compat with userspace, but I suspect
any kernel code using them would benefit from using constants
that more clearly reflect what it's doing.

(For instance, why do we clear NZCVQ on entry to a signal handler
but not GE? Harmless, since the calling convention doesn't require
any particular value for any of those flags on function entry,
but an odd inconsistency.)

thanks
-- PMM


From juri.lelli at arm.com  Wed Feb 10 06:25:24 2016
From: juri.lelli at arm.com (Juri Lelli)
Date: Wed, 10 Feb 2016 14:25:24 +0000
Subject: [PATCH v3 2/6] drivers/cpufreq: implement
 init_cpu_capacity_default()
In-Reply-To: <56BA0BCA.6090903@arm.com>
References: <CAKfTPtDGk5BC25WqHdhDYDOBgUsuidAMhrXS=eDi6wJPZjfrwA@mail.gmail.com>
 <20160204093559.GA14099@e105550-lin.cambridge.arm.com>
 <CAKfTPtB4G3bP5N0hU6zWXJTddO34x3RnyGpp-4_otc8O=Wq2hw@mail.gmail.com>
 <20160204121620.GB29586@e106622-lin>
 <CAKfTPtDVasamRtG2kLxP0HsohmVQTPrXRgx36e+jb3gozDoo6g@mail.gmail.com>
 <20160204141345.GD29586@e106622-lin>
 <CAKfTPtDWP-AgqXsSuxCfVj33dh+i7oqDTkL=gUy7n-AB1anoow@mail.gmail.com>
 <CAKfTPtD4jTmUZoShGBm3oAFywizjp8jsEukmkeZU+x+zk-KZRA@mail.gmail.com>
 <20160205093040.GG29586@e106622-lin> <56BA0BCA.6090903@arm.com>
Message-ID: <20160210142524.GE11415@e106622-lin>

On 09/02/16 15:54, Dietmar Eggemann wrote:
> On 05/02/16 09:30, Juri Lelli wrote:
> > On 04/02/16 16:46, Vincent Guittot wrote:
> >> On 4 February 2016 at 16:44, Vincent Guittot <vincent.guittot at linaro.org> wrote:
> >>> On 4 February 2016 at 15:13, Juri Lelli <juri.lelli at arm.com> wrote:
> >>>> On 04/02/16 13:35, Vincent Guittot wrote:
> >>>>> On 4 February 2016 at 13:16, Juri Lelli <juri.lelli at arm.com> wrote:
> >>>>>> Hi Vincent,
> >>>>>>
> >>>>>> On 04/02/16 13:03, Vincent Guittot wrote:
> >>>>>>> On 4 February 2016 at 10:36, Morten Rasmussen <morten.rasmussen at arm.com> wrote:
> >>>>>>>> On Wed, Feb 03, 2016 at 10:04:37PM +0100, Vincent Guittot wrote:
> >>>>>>>>> On 3 February 2016 at 12:59, Juri Lelli <juri.lelli at arm.com> wrote:
> 
> [...]
> 
> >>>
> >>> AFAICT, They don't have a dedicated cpufreq driver.
> >>>
> >>> More generally speaking, it can take time before having
> >>
> >> email sent before the ne d of the sentence ...
> >>
> >> More generally speaking, it can take time before having a cpufreq
> >> driver whereas we want to run and test scheduler behavior of these
> >> heterogenous platform
> >>
> > 
> > I'm not familiar with this platform, but from what you are saying and
> > what I could find online, it looks like full Linux support is not
> > finished yet. Can we consider that as still in development? And if we
> > can do that, maybe is fair enough that we use the sysfs interface to
> > play with that platform until support is complete.
> > 
> > Do others have any opinion on this point?
> 
> IMHO, the solution should work for all of heterogeneous systems, (a) w/
> cpufreq and driver, (b) w/ cpufreq and no driver loaded (yet) or (c) w/o
> cpufreq.
> 
> That means that you can't put the benchmarking only into
> cpufreq_register_driver() and rely on cpufreq policy topology.
> 
> Maybe you could do this for (b) and (c) inside an initcall and use
> topology_core_cpumask() to figure out which cpu to profile?
> 
> This would then happen w/ the cpu frequency set by the fw.
> 
> But this then has to be synchronized somehow with the benchmarking
> approach in cpufreq_register_driver().
> 

Yes, I guess the tricky situation is the mixed one, when we might have
the benchmarking executing in a late_initcall when cpufreq kicks in. Or
we can also end up doing the benchmarking twice if cpufreq finishes
initialization after the late_initcall has been executed.

I'm not sure how this can be solved in a clean way. Ideally we would
start benchmarking in the late_initcall (at the frequency set by fw) and
then bailout if cpufreq kicks in. That should work also for the cpufreq
driver as a module case. But, we could do the same thing twice if the
late_initcall is faster or gets executed before cpufreq starts to be
initialized.

Any suggestion anyone? :)

Best,

- Juri


From slemieux.tyco at gmail.com  Wed Feb 10 06:25:17 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Wed, 10 Feb 2016 09:25:17 -0500
Subject: [PATCH 00/11] clk: lpc32xx: add clock support for NXP LPC32xx
In-Reply-To: <56BA81F7.4080006@mleia.com>
References: <1447981511-29653-1-git-send-email-vz@mleia.com>
 <loom.20160209T215103-78@post.gmane.org>  <56BA81F7.4080006@mleia.com>
Message-ID: <1455114317.23786.11.camel@localhost>

Hi Vladimir,

On Wed, 2016-02-10 at 02:19 +0200, Vladimir Zapolskiy wrote:
> Hi Sylvain,
> 
> On 09.02.2016 23:01, Sylvain Lemieux wrote:
> > Vladimir Zapolskiy <vz at ...> writes:
> >>
> >> This changeset adds common clock framework driver for NXP LPC32xx
> >> boards.
> > 
> > Just to let you know that we did some testing using this changeset;
> > I installed patches 4 to 7, 10 & 11 on top of 4.5-rc1.
> > 
> > I was able to run our software (SIC1 interrupt sources disable)
> > without any problem a custom LPC32xx board.
> 
> this is a known issue, and I hope it will be fixed in upstream in v4.6,
> the required changes in irqchip and gpiochip drivers were sent for
> review some time ago, a bit more work is needed to 
> 
I also tested the irqchip patches you sent previously;
I will send a separate e-mail with the information.

> Also 2-3 more clean-up changes in USB host and gadget drivers are done
> locally (no more need to configure clocks out of the common clock
> framework), but not yet submitted, will do it tomorrow.
> 
> > We did not get any problem with the clock signals we are using.
> > 
> 
> Thank you for testing, I'm going to add your Tested-by tag (if you
> don't mind) and submit a PR to ARM maintainers shortly.
> 
You can go ahead for the tag; please use slemieux at tycoint.com

> >> Vladimir Zapolskiy (11):
> >>   dt-bindings: clock: add description of LPC32xx clock controller
> >>   dt-bindings: clock: add description of LPC32xx USB clock controller
> >>   dt-bindings: clock: add NXP LPC32xx clock list for consumers
> >>   arm: dts: lpc32xx: add device nodes for external oscillators
> >>   arm: dts: lpc32xx: add clock controller device node
> >>   arm: dts: lpc32xx: add clock properties to device nodes
> >>   arm: dts: lpc32xx: add USB clock controller
> >>   clk: lpc18xx: add NXP specific common clock framework selection
> >>   clk: lpc32xx: add common clock framework driver
> >>   arm: lpc32xx: switch to common clock framework
> >>   arm: dts: lpc32xx: remove clock frequency property from UART device
> >>     nodes
> > 
> > 
> 
> With best wishes,
> Vladimir




From robin.murphy at arm.com  Wed Feb 10 06:25:33 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 10 Feb 2016 14:25:33 +0000
Subject: [PATCH v2] iommu/arm-smmu: Allow disabling unmatched stream bypass
In-Reply-To: <20160209140631.GM22874@arm.com>
References: <cover.1453830752.git.robin.murphy@arm.com>
 <10ebf5a136a787da54ffd1d6167953f82f01a834.1453830752.git.robin.murphy@arm.com>
 <20160209140631.GM22874@arm.com>
Message-ID: <72d7de65c4ace47b55c31fc4e74ce4f1891eabb4.1455114028.git.robin.murphy@arm.com>

Borrow the disable_bypass parameter from the SMMUv3 driver as a handy
debugging/security feature so that unmatched stream IDs (i.e. devices
not attached to an IOMMU domain) may be configured to fault.

Rather than introduce unsightly inconsistency, or repeat the existing
unnecessary use of module_param_named(), fix that as well in passing.

Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---

v2:
- Don't bother trying to report the fault specially.
- Realise that calling module_param_named() with identical variable
  and parameter names is silly.

 drivers/iommu/arm-smmu.c | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 1f9093d..cf1e330 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -260,9 +260,13 @@
 #define FSYNR0_WNR			(1 << 4)
 
 static int force_stage;
-module_param_named(force_stage, force_stage, int, S_IRUGO);
+module_param(force_stage, int, S_IRUGO);
 MODULE_PARM_DESC(force_stage,
 	"Force SMMU mappings to be installed at a particular stage of translation. A value of '1' or '2' forces the corresponding stage. All other values are ignored (i.e. no stage is forced). Note that selecting a specific stage will disable support for nested translation.");
+static bool disable_bypass;
+module_param(disable_bypass, bool, S_IRUGO);
+MODULE_PARM_DESC(disable_bypass,
+	"Disable bypass streams such that incoming transactions from devices that are not attached to an iommu domain will report an abort back to the device and will not be allowed to pass through the SMMU.");
 
 enum arm_smmu_arch_version {
 	ARM_SMMU_V1 = 1,
@@ -1111,9 +1115,9 @@ static void arm_smmu_domain_remove_master(struct arm_smmu_domain *smmu_domain,
 	 */
 	for (i = 0; i < cfg->num_streamids; ++i) {
 		u32 idx = cfg->smrs ? cfg->smrs[i].idx : cfg->streamids[i];
+		u32 reg = disable_bypass ? S2CR_TYPE_FAULT : S2CR_TYPE_BYPASS;
 
-		writel_relaxed(S2CR_TYPE_BYPASS,
-			       gr0_base + ARM_SMMU_GR0_S2CR(idx));
+		writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_S2CR(idx));
 	}
 
 	arm_smmu_master_free_smrs(smmu, cfg);
@@ -1476,11 +1480,11 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
 	reg = readl_relaxed(ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sGFSR);
 	writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sGFSR);
 
-	/* Mark all SMRn as invalid and all S2CRn as bypass */
+	/* Mark all SMRn as invalid and all S2CRn as bypass unless overridden */
+	reg = disable_bypass ? S2CR_TYPE_FAULT : S2CR_TYPE_BYPASS;
 	for (i = 0; i < smmu->num_mapping_groups; ++i) {
 		writel_relaxed(0, gr0_base + ARM_SMMU_GR0_SMR(i));
-		writel_relaxed(S2CR_TYPE_BYPASS,
-			gr0_base + ARM_SMMU_GR0_S2CR(i));
+		writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_S2CR(i));
 	}
 
 	/* Make sure all context banks are disabled and clear CB_FSR  */
@@ -1502,8 +1506,12 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
 	/* Disable TLB broadcasting. */
 	reg |= (sCR0_VMIDPNE | sCR0_PTM);
 
-	/* Enable client access, but bypass when no mapping is found */
-	reg &= ~(sCR0_CLIENTPD | sCR0_USFCFG);
+	/* Enable client access, handling unmatched streams as appropriate */
+	reg &= ~sCR0_CLIENTPD;
+	if (disable_bypass)
+		reg |= sCR0_USFCFG;
+	else
+		reg &= ~sCR0_USFCFG;
 
 	/* Disable forced broadcasting */
 	reg &= ~sCR0_FB;
-- 
2.7.0.25.gfc10eb5.dirty



From sudeep.holla at arm.com  Wed Feb 10 06:27:16 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Wed, 10 Feb 2016 14:27:16 +0000
Subject: [GIT PULL] VExpress/Juno: DT updates for v4.6
Message-ID: <56BB48C4.4040604@arm.com>

Hi ARM-SoC team,

Please pull DT updates for VExpress/Juno platforms

--
Regards,
Sudeep

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git 
tags/vexpress-for-v4.6/dt-updates

for you to fetch changes up to 9fd9288ed0899f9e318a97d73e777d6d3357265e:

   arm64: dts: Add HDLCD support on Juno platforms (2016-02-10 10:58:33 
  +0000)

----------------------------------------------------------------
Few updates for ARM VExpress/Juno platforms

1. GICv3 support on Foundation models

2. Support for Juno R2 board

3. Support for ARM HDLCD on all Juno platforms

----------------------------------------------------------------
Andre Przywara (4):
       arm64: dts: prepare foundation-v8.dts to cope with GICv3
       arm64: dts: Foundation model: increase GICC region to allow EOImode=1
       arm64: dts: split Foundation model dts to put the GIC separately
       arm64: dts: add .dts for GICv3 Foundation model

Liviu Dudau (2):
       Documentation: drm: Add DT bindings for ARM HDLCD
       arm64: dts: Add HDLCD support on Juno platforms

Sudeep Holla (2):
       arm64: dts: move juno pcie-controller to base file
       arm64: dts: Add support for Juno r2 board

  Documentation/devicetree/bindings/arm/arm-boards   |   1 +
  .../devicetree/bindings/display/arm,hdlcd.txt      |  79 +++++++
  arch/arm64/boot/dts/arm/Makefile                   |   4 +-
  arch/arm64/boot/dts/arm/foundation-v8-gicv3.dts    |  30 +++
  arch/arm64/boot/dts/arm/foundation-v8.dts          | 227 
+-------------------
  arch/arm64/boot/dts/arm/foundation-v8.dtsi         | 228 
+++++++++++++++++++++
  arch/arm64/boot/dts/arm/juno-base.dtsi             |  68 +++++-
  arch/arm64/boot/dts/arm/juno-r1.dts                |  25 +--
  arch/arm64/boot/dts/arm/juno-r2.dts                | 183 +++++++++++++++++
  9 files changed, 595 insertions(+), 250 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/display/arm,hdlcd.txt
  create mode 100644 arch/arm64/boot/dts/arm/foundation-v8-gicv3.dts
  create mode 100644 arch/arm64/boot/dts/arm/foundation-v8.dtsi
  create mode 100644 arch/arm64/boot/dts/arm/juno-r2.dts


From arnd at arndb.de  Wed Feb 10 06:28:56 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 15:28:56 +0100
Subject: [PATCH] pci: xgene: Add ECAM fixups
In-Reply-To: <1455068984-22210-1-git-send-email-dhdang@apm.com>
References: <1455068984-22210-1-git-send-email-dhdang@apm.com>
Message-ID: <2994764.UGKJE3zfLx@wuerfel>

On Tuesday 09 February 2016 17:49:44 Duc Dang wrote:
> X-Gene PCIe controller does not fully support ECAM.
> This patch adds required ECAM fixup to allow X-Gene
> PCIe controller to be functional in ACPI boot mode.
> 
> This patch is based on the original work of
> Mark Salter <msalter at redhat.com> and depends on
> Tomasz's PCIe ACPI series:
> https://lkml.org/lkml/2016/2/4/646
> 
> Signed-off-by: Duc Dang <dhdang at apm.com>
> ---

This really has nothing to do with the PCI host device driver, please
keep it in a separate file in drivers/acpi/.

	Arnd


From arnd at arndb.de  Wed Feb 10 06:36:03 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 15:36:03 +0100
Subject: [PATCH 1/8] clk: add device tree binding for artpec-6 pll1 clock
In-Reply-To: <c092f501a595032f9b76f18fc4bf093503a181c8.1455107681.git.larper@axis.com>
References: <cover.1455107681.git.larper@axis.com>
 <c092f501a595032f9b76f18fc4bf093503a181c8.1455107681.git.larper@axis.com>
Message-ID: <12746231.crYxCXlbXY@wuerfel>

On Wednesday 10 February 2016 13:41:50 Lars Persson wrote:
> Signed-off-by: Lars Persson <larper at axis.com>
> ---

Always write a changelog comment.

> +* Clock bindings for Axis ARTPEC-6 chip
> +
> +Required properties:
> +- compatible: Should be "axis,artpec6-pll1-clock"
> +- #clock-cells: Should be <1>

What is the clock cell used for?

> +Examples:
> +
> +pll1_clk: pll1_clk {
> +	#clock-cells = <1>;
> +	compatible = "axis,artpec6-pll1-clock";
> +	clocks = <&ext_clk>;
> +	status = "okay";
> +};
> 



From arnd at arndb.de  Wed Feb 10 06:37:02 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 15:37:02 +0100
Subject: [PATCH 3/8] arm: add device-tree SoC bindings for Axis Artpec-6
In-Reply-To: <06f7e5ffdef7ba79b5702f063512010329c40cba.1455107681.git.larper@axis.com>
References: <cover.1455107681.git.larper@axis.com>
 <06f7e5ffdef7ba79b5702f063512010329c40cba.1455107681.git.larper@axis.com>
Message-ID: <7215228.dtgbJ3Moag@wuerfel>

On Wednesday 10 February 2016 13:41:52 Lars Persson wrote:
> Signed-off-by: Lars Persson <larper at axis.com>

Add a changelog

>  Documentation/devicetree/bindings/arm/axis.txt | 8 ++++++++
>  1 file changed, 8 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/axis.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/axis.txt b/Documentation/devicetree/bindings/arm/axis.txt
> new file mode 100644
> index 0000000..4c98701
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/axis.txt
> @@ -0,0 +1,8 @@
> +Axis Communications AB
> +ARTPEC series SoC Device Tree Bindings
> +
> +
> +ARTPEC-6 ARM SoC
> +
> +Required root node properties:
> +    - compatible = "axis,artpec6-dev-board", "axis,artpec6";
> 

Requiring "axis,artpec6-dev-board" to be used for all boards somewhat
misses the point of board specific compatibility values.

	Arnd


From maxime.ripard at free-electrons.com  Wed Feb 10 06:37:55 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 10 Feb 2016 15:37:55 +0100
Subject: breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi:
 Refactor A31 PLL6 so that it can be reused)
In-Reply-To: <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <56BB2D79.6090402@arm.com>
 <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
Message-ID: <20160210143755.GE31506@lukather>

Hi Rob,

On Wed, Feb 10, 2016 at 07:42:02AM -0600, Rob Herring wrote:
> On Wed, Feb 10, 2016 at 6:30 AM, Andre Przywara <andre.przywara at arm.com> wrote:
> > Hi,
> >
> > just a ping:
> >
> > Are we really OK with breaking existing DTs in 4.6? (per the code in
> > -next: f7d372ba54ea04d528a291b8dbe34716507bb60b, which is this patch).
> 
> I only warn and make sure people are aware of the issue. I leave that
> up to platform maintainers to decide. It depends on the maturity of
> the platform and users.

The impacted SoCs support is really partial. For the most supported
one, big things like display or sound are totally missing, and we
still update them on a regular basis to add support for new
devices. As such, users are very likely to upgrade the DT from one
version to another just because there's new devices available to
them. And the newest SoC impacted just got introduced in 4.5, and only
has the UART and MMC devices available.

> If people complain about it then it's their mess. For platforms
> supported in distros such as debian or fedora, I would strongly
> recommend against breaking compatibility.

None of them are officially supported:
https://www.debian.org/releases/stable/armhf/ch02s01.html.en
https://fedoraproject.org/wiki/Architectures/ARM#Fedora_23

Only the older one are, and they are not affected by this patch.

> They do ship dtbs, but it's a chicken and egg problem. If dtbs were
> stable and provided by firmware, then they wouldn't have to provide
> them. If dtbs are unstable, then they have no choice.

And while it might work great on platforms that have all the needed
documentation, or a perfect one, which is our case. Almost each
release, we discover that something is not working as it was
documented, when it was documented in the first place.

It also seems that even on well documented platforms, supported by the
vendors, the stable ABI dream is not going to happen:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Atmel/README#n105
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/arm/marvell,berlin.txt#n4

If it makes things clearer, I can also add such a statement.

> > Also I think one needs ACKs from DT maintainers before merging something
> > in the respective directories, which I don't see here.
> 
> It can go in with subsystem maintainers ack, but there are problems
> with this one regardless of compatibility.
> 
> > As I am somewhat blocked on that patch, I'd like to have some discussion
> > on the list.
> >
> > Thanks,
> > Andre.
> >
> > On 05/02/16 17:59, Andre Przywara wrote:
> >> Hi Maxime,
> >>
> >> just found this while looking at your current git branch, so sorry for
> >> the late reply.
> >>
> >> CC:ing DT people, since you touch both existing DTs(!) and the binding doc.
> >>
> >> On 01/02/16 20:20, Maxime Ripard wrote:
> >>> Remove the fixed dividers from the PLL6 driver to be able to have a
> >>> reusable driver that can be used across several SoCs that share the same
> >>> controller, but don't have the same set of dividers for this clock, and to
> >>> also be reused multiple times in the same SoC, since we're droping the
> >>> clock name.
> 
> Removing a compatible name or not has nothing to do with sharing code.

This was not about the compatible name, but the hardcoded name in our
structure associated to that compatible. And since we can't register
two clocks with the same name, we couldn't use the same compatible
several times.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160210/dbaba577/attachment.sig>

From arnd at arndb.de  Wed Feb 10 06:38:48 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 15:38:48 +0100
Subject: [PATCH 4/8] arm: dts: add Artpec-6 soc dtsi file
In-Reply-To: <733065957e9ec67d698870cf832b4641d0da30cb.1455107681.git.larper@axis.com>
References: <cover.1455107681.git.larper@axis.com>
 <733065957e9ec67d698870cf832b4641d0da30cb.1455107681.git.larper@axis.com>
Message-ID: <2518578.qKxQQXPlfn@wuerfel>

On Wednesday 10 February 2016 13:41:53 Lars Persson wrote:
> Signed-off-by: Lars Persson <larper at axis.com>
> ---

Missing changelog

>  arch/arm/boot/dts/artpec6.dtsi | 238 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 238 insertions(+)
>  create mode 100644 arch/arm/boot/dts/artpec6.dtsi
> 
> diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/arm/boot/dts/artpec6.dtsi
> new file mode 100644
> index 0000000..c1790d8
> --- /dev/null
> +++ b/arch/arm/boot/dts/artpec6.dtsi
> @@ -0,0 +1,238 @@
> +/*
> + * Device Tree Source for the Axis ARTPEC-6 SoC
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include "skeleton.dtsi"
> +
> +/ {
> +	compatible = "axis,artpec6";
> +	interrupt-parent = <&intc>;
> +
> +	aliases {
> +		serial0 = &uart0;
> +		serial1 = &uart1;
> +		serial2 = &uart2;
> +		serial3 = &uart3;
> +	};

Move the aliases into the board, not all boards might use all four
uarts, or some board might assign different numbers.

> +		uart0: uart at f8036000 {

make this "serial at f8036000"

	Arnd



From mathieu.poirier at linaro.org  Wed Feb 10 06:41:30 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 10 Feb 2016 07:41:30 -0700
Subject: [PATCH v5 1/3] mailbox: Add support for APM X-Gene platform
 mailbox driver
In-Reply-To: <CADaLNDktgAnq5VHGj=B0iO9-GnMAamTEVELYuBTVegeL3QZ4Sw@mail.gmail.com>
References: <CABb+yY1cE152ZdfK_aeB8ufG=WfoUVB6BN8kXPphYgMBnpH-GA@mail.gmail.com>
 <cover.1454967957.git.dhdang@apm.com>
 <90cb13a0b4d3817c18c11c183128c08d6458bf8d.1454967957.git.dhdang@apm.com>
 <CANLsYkwp4vJN+LcNm=7Xm=RppFnsPEXSAARS7=g6CZSsk5M5qw@mail.gmail.com>
 <CADaLNDktgAnq5VHGj=B0iO9-GnMAamTEVELYuBTVegeL3QZ4Sw@mail.gmail.com>
Message-ID: <CANLsYkxPnFCuJLyKsHnXKdbvAwNurtgQgJ-WF+bD26+8EjkfJw@mail.gmail.com>

On 9 February 2016 at 20:46, Duc Dang <dhdang at apm.com> wrote:
> On Tue, Feb 9, 2016 at 8:40 AM, Mathieu Poirier
> <mathieu.poirier at linaro.org> wrote:
>> On 8 February 2016 at 15:04, Duc Dang <dhdang at apm.com> wrote:
>>> X-Gene mailbox controller provides 8 mailbox channels, with
>>> each channel has a dedicated interrupt line.
>>>
>>> Signed-off-by: Feng Kan <fkan at apm.com>
>>> Signed-off-by: Duc Dang <dhdang at apm.com>
>>> ---
>>> Changes since v4:
>>>         - Rebase over v4.5-rc1
>>>         - Fix section mistmatch warning by removing
>>>         __init in slimpro_mbox_probe declaration
>>>         - Correctly print channel number when
>>>         there is no IRQ for that channel
>>>
>>> Changes since v3:
>>>         - Rebase over v4.4
>>>         - Remove 'id' in slimpro_mbox_chan structure
>>>         - Remove small functions that are only called once
>>>         and fold them into the other callers
>>>         - Remove void* pointer type cast
>>>         - Relax the number of mailbox IRQs condition
>>>         - Use subsys_initcall to guarantee mailbox driver
>>>         will be registered before any other dependent driver
>>>         is loaded.
>>>
>>>  drivers/mailbox/Kconfig                 |   9 ++
>>>  drivers/mailbox/Makefile                |   2 +
>>>  drivers/mailbox/mailbox-xgene-slimpro.c | 264 ++++++++++++++++++++++++++++++++
>>>  3 files changed, 275 insertions(+)
>>>  create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c
>>>
>>> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
>>> index 546d05f..678e434 100644
>>> --- a/drivers/mailbox/Kconfig
>>> +++ b/drivers/mailbox/Kconfig
>>> @@ -85,4 +85,13 @@ config MAILBOX_TEST
>>>           Test client to help with testing new Controller driver
>>>           implementations.
>>>
>>> +config XGENE_SLIMPRO_MBOX
>>> +       tristate "APM SoC X-Gene SLIMpro Mailbox Controller"
>>> +       depends on ARCH_XGENE
>>> +       help
>>> +         An implementation of the APM X-Gene Interprocessor Communication
>>> +         Mailbox (IPCM) between the ARM 64-bit cores and SLIMpro controller.
>>> +         It is used to send short messages between ARM64-bit cores and
>>> +         the SLIMpro Management Engine, primarily for PM. Say Y here if you
>>> +         want to use the APM X-Gene SLIMpro IPCM support.
>>>  endif
>>> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
>>> index 92435ef..b602ef8 100644
>>> --- a/drivers/mailbox/Makefile
>>> +++ b/drivers/mailbox/Makefile
>>> @@ -17,3 +17,5 @@ obj-$(CONFIG_ALTERA_MBOX)     += mailbox-altera.o
>>>  obj-$(CONFIG_BCM2835_MBOX)     += bcm2835-mailbox.o
>>>
>>>  obj-$(CONFIG_STI_MBOX)         += mailbox-sti.o
>>> +
>>> +obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
>>> diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c b/drivers/mailbox/mailbox-xgene-slimpro.c
>>> new file mode 100644
>>> index 0000000..0ea1eb8
>>> --- /dev/null
>>> +++ b/drivers/mailbox/mailbox-xgene-slimpro.c
>>> @@ -0,0 +1,264 @@
>>> +/*
>>> + * APM X-Gene SLIMpro MailBox Driver
>>> + *
>>> + * Copyright (c) 2015, Applied Micro Circuits Corporation
>>> + * Author: Feng Kan fkan at apm.com
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU General Public License as
>>> + * published by the Free Software Foundation; either version 2 of
>>> + * the License, or (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * 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/delay.h>
>>> +#include <linux/interrupt.h>
>>> +#include <linux/io.h>
>>> +#include <linux/mailbox_controller.h>
>>> +#include <linux/module.h>
>>> +#include <linux/of.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/spinlock.h>
>>> +
>>> +#define MBOX_CON_NAME                  "slimpro-mbox"
>>> +#define MBOX_REG_SET_OFFSET            0x1000
>>> +#define MBOX_CNT                       8
>>> +#define MBOX_STATUS_AVAIL_MASK         BIT(16)
>>> +#define MBOX_STATUS_ACK_MASK           BIT(0)
>>> +
>>> +/* Configuration and Status Registers */
>>> +#define REG_DB_IN              0x00
>>> +#define REG_DB_DIN0            0x04
>>> +#define REG_DB_DIN1            0x08
>>> +#define REG_DB_OUT             0x10
>>> +#define REG_DB_DOUT0           0x14
>>> +#define REG_DB_DOUT1           0x18
>>> +#define REG_DB_STAT            0x20
>>> +#define REG_DB_STATMASK                0x24
>>> +
>>> +struct slimpro_mbox_chan {
>>> +       struct device *dev;
>>> +       struct mbox_chan *chan;
>>> +       void __iomem *reg;
>>> +       int irq;
>>> +       u32 rx_msg[3];
>>> +};
>>> +
>>> +struct slimpro_mbox {
>>> +       struct mbox_controller mb_ctrl;
>>> +       struct slimpro_mbox_chan mc[MBOX_CNT];
>>> +       struct mbox_chan chans[MBOX_CNT];
>>> +};
>>
>> The above two structure declaration could use kernel style documentation.
>
> Can you please clarify or give an example? I looked into several files
> in drivers/mailbox/ and drivers/irqchip but could not find what I need
> to tweak.

http://lxr.free-electrons.com/source/drivers/mailbox/mailbox-sti.c#L42

>
>>
>>> +
>>> +static void mb_chan_send_msg(struct slimpro_mbox_chan *mb_chan, u32 *msg)
>>> +{
>>> +       writel(msg[1], mb_chan->reg + REG_DB_DOUT0);
>>> +       writel(msg[2], mb_chan->reg + REG_DB_DOUT1);
>>> +       writel(msg[0], mb_chan->reg + REG_DB_OUT);
>>> +}
>>> +
>>> +static void mb_chan_recv_msg(struct slimpro_mbox_chan *mb_chan)
>>> +{
>>> +       mb_chan->rx_msg[1] = readl(mb_chan->reg + REG_DB_DIN0);
>>> +       mb_chan->rx_msg[2] = readl(mb_chan->reg + REG_DB_DIN1);
>>> +       mb_chan->rx_msg[0] = readl(mb_chan->reg + REG_DB_IN);
>>> +}
>>
>> Is there a requirement that operations in the above two functions be
>> ordered?  If not significant gains could be achieved by using
>> writel/readl_relaxed().  Same comment for the rest of this driver.
>
> The 'writes' need to be in order as writing to REG_DB_OUT will trigger
> interrupt, so I want the other 2 'writes' complete before it.
>
> After the receiver get the message, it will clear door bell available
> interrupt request, this will also trigger a door bell acknowledge
> interrupt. So the 'read' to get the message and the 'write' to clear
> the door bell available interrupt must be in order as well.
>
> Regards,
> Duc Dang.
>>
>> Thanks,
>> Mathieu
>>
>>> +
>>> +static int mb_chan_status_ack(struct slimpro_mbox_chan *mb_chan)
>>> +{
>>> +       u32 val = readl(mb_chan->reg + REG_DB_STAT);
>>> +
>>> +       if (val & MBOX_STATUS_ACK_MASK) {
>>> +               writel(MBOX_STATUS_ACK_MASK, mb_chan->reg + REG_DB_STAT);
>>> +               return 1;
>>> +       }
>>> +       return 0;
>>> +}
>>> +
>>> +static int mb_chan_status_avail(struct slimpro_mbox_chan *mb_chan)
>>> +{
>>> +       u32 val = readl(mb_chan->reg + REG_DB_STAT);
>>> +
>>> +       if (val & MBOX_STATUS_AVAIL_MASK) {
>>> +               mb_chan_recv_msg(mb_chan);
>>> +               writel(MBOX_STATUS_AVAIL_MASK, mb_chan->reg + REG_DB_STAT);
>>> +               return 1;
>>> +       }
>>> +       return 0;
>>> +}
>>> +
>>> +static irqreturn_t slimpro_mbox_irq(int irq, void *id)
>>> +{
>>> +       struct slimpro_mbox_chan *mb_chan = id;
>>> +
>>> +       if (mb_chan_status_ack(mb_chan))
>>> +               mbox_chan_txdone(mb_chan->chan, 0);
>>> +
>>> +       if (mb_chan_status_avail(mb_chan))
>>> +               mbox_chan_received_data(mb_chan->chan, mb_chan->rx_msg);
>>> +
>>> +       return IRQ_HANDLED;
>>> +}
>>> +
>>> +static int slimpro_mbox_send_data(struct mbox_chan *chan, void *msg)
>>> +{
>>> +       struct slimpro_mbox_chan *mb_chan = chan->con_priv;
>>> +
>>> +       mb_chan_send_msg(mb_chan, msg);
>>> +       return 0;
>>> +}
>>> +
>>> +static int slimpro_mbox_startup(struct mbox_chan *chan)
>>> +{
>>> +       struct slimpro_mbox_chan *mb_chan = chan->con_priv;
>>> +       int rc;
>>> +       u32 val;
>>> +
>>> +       rc = devm_request_irq(mb_chan->dev, mb_chan->irq, slimpro_mbox_irq, 0,
>>> +                             MBOX_CON_NAME, mb_chan);
>>> +       if (unlikely(rc)) {
>>> +               dev_err(mb_chan->dev, "failed to register mailbox interrupt %d\n",
>>> +                       mb_chan->irq);
>>> +               return rc;
>>> +       }
>>> +
>>> +       /* Enable HW interrupt */
>>> +       writel(MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK,
>>> +              mb_chan->reg + REG_DB_STAT);
>>> +       /* Unmask doorbell status interrupt */
>>> +       val = readl(mb_chan->reg + REG_DB_STATMASK);
>>> +       val &= ~(MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK);
>>> +       writel(val, mb_chan->reg + REG_DB_STATMASK);
>>> +
>>> +       return 0;
>>> +}
>>> +
>>> +static void slimpro_mbox_shutdown(struct mbox_chan *chan)
>>> +{
>>> +       struct slimpro_mbox_chan *mb_chan = chan->con_priv;
>>> +       u32 val;
>>> +
>>> +       /* Mask doorbell status interrupt */
>>> +       val = readl(mb_chan->reg + REG_DB_STATMASK);
>>> +       val |= (MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK);
>>> +       writel(val, mb_chan->reg + REG_DB_STATMASK);
>>> +
>>> +       devm_free_irq(mb_chan->dev, mb_chan->irq, mb_chan);
>>> +}
>>> +
>>> +static struct mbox_chan_ops slimpro_mbox_ops = {
>>> +       .send_data = slimpro_mbox_send_data,
>>> +       .startup = slimpro_mbox_startup,
>>> +       .shutdown = slimpro_mbox_shutdown,
>>> +};
>>> +
>>> +static int slimpro_mbox_probe(struct platform_device *pdev)
>>> +{
>>> +       struct slimpro_mbox *ctx;
>>> +       struct resource *regs;
>>> +       void __iomem *mb_base;
>>> +       int rc;
>>> +       int i;
>>> +
>>> +       ctx = devm_kzalloc(&pdev->dev, sizeof(struct slimpro_mbox), GFP_KERNEL);
>>> +       if (IS_ERR(ctx))
>>> +               return PTR_ERR(ctx);
>>> +
>>> +       platform_set_drvdata(pdev, ctx);
>>> +
>>> +       regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> +       mb_base = devm_ioremap(&pdev->dev, regs->start, resource_size(regs));
>>> +       if (IS_ERR(mb_base))
>>> +               return PTR_ERR(mb_base);
>>> +
>>> +       /* Setup mailbox links */
>>> +       for (i = 0; i < MBOX_CNT; i++) {
>>> +               ctx->mc[i].irq = platform_get_irq(pdev, i);
>>> +               if (ctx->mc[i].irq < 0) {
>>> +                       if (i == 0) {
>>> +                               dev_err(&pdev->dev, "no available IRQ\n");
>>> +                               return -EINVAL;
>>> +                       }
>>> +                       dev_info(&pdev->dev, "no IRQ for channel %d\n", i);
>>> +                       break;
>>> +               }
>>> +
>>> +               ctx->mc[i].dev = &pdev->dev;
>>> +               ctx->mc[i].reg = mb_base + i * MBOX_REG_SET_OFFSET;
>>> +               ctx->mc[i].chan = &ctx->chans[i];
>>> +               ctx->chans[i].con_priv = &ctx->mc[i];
>>> +       }
>>> +
>>> +       /* Setup mailbox controller */
>>> +       ctx->mb_ctrl.dev = &pdev->dev;
>>> +       ctx->mb_ctrl.chans = ctx->chans;
>>> +       ctx->mb_ctrl.txdone_irq = true;
>>> +       ctx->mb_ctrl.ops = &slimpro_mbox_ops;
>>> +       ctx->mb_ctrl.num_chans = i;
>>> +
>>> +       rc = mbox_controller_register(&ctx->mb_ctrl);
>>> +       if (rc) {
>>> +               dev_err(&pdev->dev,
>>> +                       "APM X-Gene SLIMpro MailBox register failed:%d\n", rc);
>>> +               return rc;
>>> +       }
>>> +
>>> +       dev_info(&pdev->dev, "APM X-Gene SLIMpro MailBox registered\n");
>>> +       return 0;
>>> +}
>>> +
>>> +static int slimpro_mbox_remove(struct platform_device *pdev)
>>> +{
>>> +       struct slimpro_mbox *smb = platform_get_drvdata(pdev);
>>> +
>>> +       mbox_controller_unregister(&smb->mb_ctrl);
>>> +       return 0;
>>> +}
>>> +
>>> +static const struct of_device_id slimpro_of_match[] = {
>>> +       {.compatible = "apm,xgene-slimpro-mbox" },
>>> +       { },
>>> +};
>>> +MODULE_DEVICE_TABLE(of, slimpro_of_match);
>>> +
>>> +#ifdef CONFIG_ACPI
>>> +static const struct acpi_device_id slimpro_acpi_ids[] = {
>>> +       {"APMC0D01", 0},
>>> +       {}
>>> +};
>>> +MODULE_DEVICE_TABLE(acpi, slimpro_acpi_ids);
>>> +#endif
>>> +
>>> +static struct platform_driver slimpro_mbox_driver = {
>>> +       .probe  = slimpro_mbox_probe,
>>> +       .remove = slimpro_mbox_remove,
>>> +       .driver = {
>>> +               .name = "xgene-slimpro-mbox",
>>> +               .of_match_table = of_match_ptr(slimpro_of_match),
>>> +               .acpi_match_table = ACPI_PTR(slimpro_acpi_ids)
>>> +       },
>>> +};
>>> +
>>> +static int __init slimpro_mbox_init(void)
>>> +{
>>> +       return platform_driver_register(&slimpro_mbox_driver);
>>> +}
>>> +
>>> +static void __exit slimpro_mbox_exit(void)
>>> +{
>>> +       platform_driver_unregister(&slimpro_mbox_driver);
>>> +}
>>> +
>>> +subsys_initcall(slimpro_mbox_init);
>>> +module_exit(slimpro_mbox_exit);
>>> +
>>> +MODULE_DESCRIPTION("APM X-Gene SLIMpro Mailbox Driver");
>>> +MODULE_LICENSE("GPL");
>>> --
>>> 1.9.1
>>>


From arnd at arndb.de  Wed Feb 10 06:42:14 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 15:42:14 +0100
Subject: [PATCH 6/8] arm: initial machine port for artpec-6 SoC
In-Reply-To: <fa3483f1a388e443245084c3b5e9aa1ad2f61392.1455107681.git.larper@axis.com>
References: <cover.1455107681.git.larper@axis.com>
 <fa3483f1a388e443245084c3b5e9aa1ad2f61392.1455107681.git.larper@axis.com>
Message-ID: <2600190.zvDdb99M2V@wuerfel>

On Wednesday 10 February 2016 13:41:55 Lars Persson wrote:
> @@ -0,0 +1,22 @@
> +menuconfig ARCH_ARTPEC
> +	bool "Axis Communications ARM based ARTPEC SoCs" if ARCH_MULTI_V7
> +
> +if ARCH_ARTPEC
> +
> +config MACH_ARTPEC6
> +	bool "Axis ARTPEC-6 ARM Cortex A9 Platform" if ARCH_MULTI_V7

Change both to use

	depends on ARCH_MULTI_V7

like we changed all other platforms in 4.5

> +	select ARM_AMBA
> +	select ARM_GIC
> +	select ARM_GLOBAL_TIMER
> +	select ARM_PSCI
> +	select COMMON_CLK
> +	select GENERIC_CLOCKEVENTS
> +	select HAVE_ARM_ARCH_TIMER
> +	select HAVE_ARM_SCU
> +	select HAVE_ARM_TWD if SMP
> +	select SPARSE_IRQ
> +	select USE_OF

No need for GENERIC_CLOCKEVENTS, COMMON_CLK, USE_OF or SPARSE_IRQ to be selected, they
are always enabled with ARCH_MULTIPLATFORM. Check the others as well to see if 
you can drop more of them.

> +
> +#define ARTPEC6_DMACFG 0xf8000010
> +#define ARTPEC6_DMACFG_UARTS_BURST 0xff
> +
> +#define SECURE_OP_L2C_WRITEREG 0xb4000001
> +
> +static void __init artpec6_init_machine(void)
> +{
> +	void __iomem *dmacfg;
> +
> +	/* Use PL011 DMA Burst Request signal instead of DMA Single Request */
> +	dmacfg = ioremap(ARTPEC6_DMACFG, 4);
> +	if (dmacfg) {
> +		__raw_writel(ARTPEC6_DMACFG_UARTS_BURST, dmacfg);
> +		iounmap(dmacfg);
> +	}

Can you do this in the bootloader?

If not, please use a DT node to pass the address rather than hardcoding it,
and use writel() instead of __raw_writel() so it works with on big-endian kernels.

> +DT_MACHINE_START(ARTPEC6, "Axis ARTPEC-6 Platform")
> +	.l2c_aux_val	= 0x0C000000,
> +	.l2c_aux_mask	= 0xF3FFFFFF,
> +	.l2c_write_sec  = artpec6_l2c310_write_sec,
> +	.init_irq	= irqchip_init,
> +	.init_machine	= artpec6_init_machine,
> +	.dt_compat	= artpec6_dt_match,
> +MACHINE_END
> 

You can drop the irqchip_init.

	Arnd


From arnd at arndb.de  Wed Feb 10 06:42:32 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 15:42:32 +0100
Subject: [PATCH 7/8] arm: multi_v7_defconfig: add MACH_ARTPEC6
In-Reply-To: <36d8a6a0236e08bc7286085018e2fa7a67691b39.1455107681.git.larper@axis.com>
References: <cover.1455107681.git.larper@axis.com>
 <36d8a6a0236e08bc7286085018e2fa7a67691b39.1455107681.git.larper@axis.com>
Message-ID: <22004657.zNDLNVmTMr@wuerfel>

On Wednesday 10 February 2016 13:41:56 Lars Persson wrote:
> Signed-off-by: Lars Persson <larper at axis.com>
> ---
>  arch/arm/configs/multi_v7_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index 8e8b2ac..bf3840e 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -16,6 +16,8 @@ CONFIG_ARCH_MULTI_V7=y
>  # CONFIG_ARCH_MULTI_V4 is not set
>  CONFIG_ARCH_VIRT=y
>  CONFIG_ARCH_ALPINE=y
> +CONFIG_ARCH_ARTPEC=y
> +CONFIG_MACH_ARTPEC6=y
>  CONFIG_ARCH_MVEBU=y
>  CONFIG_MACH_ARMADA_370=y
>  CONFIG_MACH_ARMADA_375=y
> 

No other drivers that you need here?

	Arnd


From will.deacon at arm.com  Wed Feb 10 06:43:24 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 14:43:24 +0000
Subject: [PATCH] arm64: Rework valid_user_regs
In-Reply-To: <CAFEAcA-3mgxu6hNSOLhFMmfzB705xyZTyfa5eiRWX6MOnYMVvQ@mail.gmail.com>
References: <1455041501-30018-1-git-send-email-mark.rutland@arm.com>
 <20160210115853.GG1052@arm.com> <20160210123110.GD2632@leverpostej>
 <CAFEAcA-3mgxu6hNSOLhFMmfzB705xyZTyfa5eiRWX6MOnYMVvQ@mail.gmail.com>
Message-ID: <20160210144324.GL1052@arm.com>

On Wed, Feb 10, 2016 at 02:23:29PM +0000, Peter Maydell wrote:
> On 10 February 2016 at 12:31, Mark Rutland <mark.rutland at arm.com> wrote:
> > On Wed, Feb 10, 2016 at 11:58:53AM +0000, Will Deacon wrote:
> >> I think we should err on the side of caution and nuke SS and IL for both
> >> native and compat too, although that seems a odds with the PSR_s mask.
> >> I wonder how relevant those PSR groups are in ARMv8...
> >
> > Ok.
> 
> If you nuke SS does that have any side effects in the case
> of (for instance) interactions between ptrace single step
> and ptrace syscall tracing? (ie do we ever end up in a situation
> where the ptracer can read a PSR for the debuggee which has
> SS set? if so then it should be able to write back the PSR
> it has just read without any bits being unset.)

I don't think so -- the signal dispatch logic "fast-forwards" the stepping
state machine so that we step into the signal handler, therefore the SS
bit should always be clear on entry afaict.

> Clearing IL should be ok, though it's pretty harmless for
> the user process to have IL set, it will just cause an exception.
> (Userspace can't end up with IL set unless we allow it to by
> doing an exception-return to EL0 with an IL-set SPSR.)

I was just musing about potential hardware bugs and thought it cleaner
/safer to clear those bits.

> > I couldn't spot anything in the ARM ARM regarding PSR bit groups,; I was
> > cargo-culting from the existing code. I'm more than happy to make the
> > PSR_* groups an aarch32/compat thing.
> 
> It's not clear to me that they make much sense for 32-bit either.
> NZCVQ are in PSR_f, but GE are in PSR_s. I and F are in
> PSR_c but A is in PSR_x. Presumably we need to leave them in
> the header file for back-compat with userspace, but I suspect
> any kernel code using them would benefit from using constants
> that more clearly reflect what it's doing.
> 
> (For instance, why do we clear NZCVQ on entry to a signal handler
> but not GE? Harmless, since the calling convention doesn't require
> any particular value for any of those flags on function entry,
> but an odd inconsistency.)

No idea. This whole area is pretty crufty, so we could probably clean
that up while we're here.

Will


From arnd at arndb.de  Wed Feb 10 06:43:27 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 15:43:27 +0100
Subject: [PATCH 0/8] arm: Add Artpec-6 SoC
In-Reply-To: <cover.1455107681.git.larper@axis.com>
References: <cover.1455107681.git.larper@axis.com>
Message-ID: <3600743.1EoOBI7uCq@wuerfel>

On Wednesday 10 February 2016 13:41:49 Lars Persson wrote:
> Basic support for the Axis Artpec-6 ARM SoC. Timers, interrupts, UARTs and
> ethernet are wired up.
> 

Hi Lars,

Looks nice overall, I just have a few small comments on some of the patches.
Please also add a patch do add yourself in the MAINTAINERS file.

	Arnd


From arnd at arndb.de  Wed Feb 10 06:45:01 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 15:45:01 +0100
Subject: breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi:
 Refactor A31 PLL6 so that it can be reused)
In-Reply-To: <20160210143755.GE31506@lukather>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
 <20160210143755.GE31506@lukather>
Message-ID: <3703606.9ibfaTDDFx@wuerfel>

On Wednesday 10 February 2016 15:37:55 Maxime Ripard wrote:
> Hi Rob,
> 
> On Wed, Feb 10, 2016 at 07:42:02AM -0600, Rob Herring wrote:
> > On Wed, Feb 10, 2016 at 6:30 AM, Andre Przywara <andre.przywara at arm.com> wrote:
> > > Hi,
> > >
> > > just a ping:
> > >
> > > Are we really OK with breaking existing DTs in 4.6? (per the code in
> > > -next: f7d372ba54ea04d528a291b8dbe34716507bb60b, which is this patch).
> > 
> > I only warn and make sure people are aware of the issue. I leave that
> > up to platform maintainers to decide. It depends on the maturity of
> > the platform and users.
> 
> The impacted SoCs support is really partial. For the most supported
> one, big things like display or sound are totally missing, and we
> still update them on a regular basis to add support for new
> devices. As such, users are very likely to upgrade the DT from one
> version to another just because there's new devices available to
> them. And the newest SoC impacted just got introduced in 4.5, and only
> has the UART and MMC devices available.
> 
> 

I think the main problems we had were around people building their
own boards and maintaining out-of-tree dts files.

	Arnd


From gabriele.paoloni at huawei.com  Wed Feb 10 06:45:09 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Wed, 10 Feb 2016 14:45:09 +0000
Subject: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
 HiSilicon SoCs Host Controllers
In-Reply-To: <20160210111234.GC2632@leverpostej>
References: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
 <1455039260-6040-4-git-send-email-gabriele.paoloni@huawei.com>
 <20160209182429.GD4348@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1591@lhreml503-mbs>
 <20160210111234.GC2632@leverpostej>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1D30@lhreml503-mbs>

> -----Original Message-----
> From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> owner at vger.kernel.org] On Behalf Of Mark Rutland
> Sent: 10 February 2016 11:13
> To: Gabriele Paoloni
> Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C); Linuxarm;
> qiujiang; bhelgaas at google.com; arnd at arndb.de;
> Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-pci at vger.kernel.org;
> linux-kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth); linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
> HiSilicon SoCs Host Controllers
> 
> On Wed, Feb 10, 2016 at 09:52:36AM +0000, Gabriele Paoloni wrote:
> > Hi Mark
> >
> > > On Tue, Feb 09, 2016 at 05:34:20PM +0000, Gabriele Paoloni wrote:
> > > > From: gabriele paoloni <gabriele.paoloni at huawei.com>
> > > > +/*
> > > > + * Retrieve rc_dbi base and size from _DSD
> > > > + * Name (_DSD, Package () {
> > > > + *	ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > > > + *	Package () {
> > > > + *	Package () {"rc-dbi", Package () { 0x0, 0xb0080000, 0x0,
> 0x10000
> > > }},
> > > > + *	}
> > > > + *	})
> > > > + */
> > >
> > > As above, this does not look right. ACPI has standard mechanisms
> for
> > > describing addresses. Making something up like this is not a good
> idea.
> >
> > I am quite new to ACPI, may I ask you to explain a bit?
> 
> ACPI has standard mechanisms for describing certain resources, and
> these
> should not be described in _DSD. Memory or IO address regions are such
> resources (in _CRS, IIRC), and should not be described in _DSD.

Hi Mark,

In my case I think in need to look into the MCFG object as the problem
I have is RC using a different range than the rest of the hierarchy.

I'll investigate this and try to come with a solution in v4

Many Thanks

Gab 

> 
> Thanks,
> Mark.


From marc.zyngier at arm.com  Wed Feb 10 06:46:02 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 14:46:02 +0000
Subject: [PATCH 3/5] irqchip/gic-v2: Parse and export virtual GIC
 information
In-Reply-To: <56BB46DC.7080202@arm.com>
References: <1454950049-741-1-git-send-email-julien.grall@arm.com>
 <1454950049-741-4-git-send-email-julien.grall@arm.com>
 <20160209204914.GE5171@cbox> <56BB46DC.7080202@arm.com>
Message-ID: <56BB4D2A.1030903@arm.com>

On 10/02/16 14:19, Julien Grall wrote:
> Hi Christoffer,
> 
> On 09/02/16 20:49, Christoffer Dall wrote:
>>> +static void __init gic_acpi_setup_kvm_info(void)
>>> +{
>>> +	gic_v2_kvm_info.type = GIC_V2;
>>> +
>>> +	gic_v2_kvm_info.maint_irq = acpi_register_gsi(NULL,
>>> +						      acpi_data.maint_irq,
>>> +						      acpi_data.maint_irq_mode,
>>> +						      ACPI_ACTIVE_HIGH);
>>> +	gic_v2_kvm_info.vctrl_base = acpi_data.vctrl_base;
>>> +	if (gic_v2_kvm_info.vctrl_base)
>>> +		gic_v2_kvm_info.vctrl_size = SZ_8K;
>>> +
>>> +	gic_v2_kvm_info.vcpu_base = acpi_data.vcpu_base;
>>> +	if (gic_v2_kvm_info.vcpu_base)
>>> +		gic_v2_kvm_info.vcpu_size = SZ_8K;
>>
>> why are the sizes hard-coded to 8K in this case?
> 
> The MADT only provides the base addresses and not the size. The default 
> value has been chosen based on the GICv2 spec (ARM IHI 0048B.b)
> 	* GICV: See 5.5
> 	* GICH: I can't find again the section about it. But the example 
> bindings in 
> Documents/devicetree/bindings/interrupt-controller/arm,gic.txt uses 8K.
> 
> I will add a comment in the code explaining where the 8K come from.

The GICH size can be found in the GIC400 TRM:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0471b/CHDBJDCB.html

The first 4kB are banked per CPU, while the next 4kB are exposing all
CPUs, each in a 512 bytes window. We don't give a damn about the second
page, but hey, it is there...

Of course, this is GIC400, not the architecture spec. So maybe
considering a 4kB size would be better, just in case someone is
braindead enough to produce another GICv2 implementation without the
aliases...

	M.
-- 
Jazz is not dead. It just smells funny...


From thomas.petazzoni at free-electrons.com  Wed Feb 10 06:46:59 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Feb 2016 15:46:59 +0100
Subject: [PATCH v3 4/6] irqchip: irq-armada-370-xp: use shorter names for
 irq_chip
In-Reply-To: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455115621-22846-5-git-send-email-thomas.petazzoni@free-electrons.com>

In order to make the output of /proc/interrupts, use shorter names for
the irq_chip registered by the irq-armada-370-xp driver. Using capital
letters also matches better what is done for the GIC driver, which
uses just "GIC" as the irq_chip->name.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/irqchip/irq-armada-370-xp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index f53eb71..c99ae5f 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -117,7 +117,7 @@ static void armada_370_xp_irq_unmask(struct irq_data *d)
 #ifdef CONFIG_PCI_MSI
 
 static struct irq_chip armada_370_xp_msi_irq_chip = {
-	.name = "armada_370_xp_msi_irq",
+	.name = "MPIC MSI",
 	.irq_mask = pci_msi_mask_irq,
 	.irq_unmask = pci_msi_unmask_irq,
 };
@@ -141,7 +141,7 @@ static int armada_370_xp_msi_set_affinity(struct irq_data *irq_data,
 }
 
 static struct irq_chip armada_370_xp_msi_bottom_irq_chip = {
-	.name			= "armada_370_xp_msi_irq",
+	.name			= "MPIC MSI",
 	.irq_compose_msi_msg	= armada_370_xp_compose_msi_msg,
 	.irq_set_affinity	= armada_370_xp_msi_set_affinity,
 };
@@ -253,7 +253,7 @@ static int armada_xp_set_affinity(struct irq_data *d,
 #endif
 
 static struct irq_chip armada_370_xp_irq_chip = {
-	.name		= "armada_370_xp_irq",
+	.name		= "MPIC",
 	.irq_mask       = armada_370_xp_irq_mask,
 	.irq_mask_ack   = armada_370_xp_irq_mask,
 	.irq_unmask     = armada_370_xp_irq_unmask,
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 10 06:46:58 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Feb 2016 15:46:58 +0100
Subject: [PATCH v3 3/6] irqchip: irq-armada-370-xp: use PCI_MSI_DOORBELL_START
 where appropriate
In-Reply-To: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455115621-22846-4-git-send-email-thomas.petazzoni@free-electrons.com>

As suggested by Gregory Clement, this commit adjusts the
irq-armada-370-xp driver to use the PCI_MSI_DOORBELL_START define in
the armada_370_xp_handle_msi_irq() function, rather than hardcoding
its value.

Suggested-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/irqchip/irq-armada-370-xp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index e5738c5..f53eb71 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -401,10 +401,10 @@ static void armada_370_xp_handle_msi_irq(struct pt_regs *regs, bool is_chained)
 
 		if (is_chained) {
 			irq = irq_find_mapping(armada_370_xp_msi_inner_domain,
-					       msinr - 16);
+					       msinr - PCI_MSI_DOORBELL_START);
 			generic_handle_irq(irq);
 		} else {
-			irq = msinr - 16;
+			irq = msinr - PCI_MSI_DOORBELL_START;
 			handle_domain_irq(armada_370_xp_msi_inner_domain,
 					  irq, regs);
 		}
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 10 06:46:56 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Feb 2016 15:46:56 +0100
Subject: [PATCH v3 1/6] irqchip: irq-armada-370-xp: add Kconfig option for the
 driver
In-Reply-To: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455115621-22846-2-git-send-email-thomas.petazzoni@free-electrons.com>

Instead of building the irq-armada-370-xp driver directly when
CONFIG_ARCH_MVEBU is enabled, this commit introduces an intermediate
CONFIG_ARMADA_370_XP_IRQ hidden Kconfig option.

This allows this option to select other interrupt-related Kconfig
options (which will be needed in follow-up commits) rather than having
such selects done from arch/arm/mach-<foo>/.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/irqchip/Kconfig  | 5 +++++
 drivers/irqchip/Makefile | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 715923d..e2cab87 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -60,6 +60,11 @@ config ARM_VIC_NR
 	  The maximum number of VICs available in the system, for
 	  power management.
 
+config ARMADA_370_XP_IRQ
+	bool
+	default y if ARCH_MVEBU
+	select GENERIC_IRQ_CHIP
+
 config ATMEL_AIC_IRQ
 	bool
 	select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 18caacb..30dba04 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -5,7 +5,6 @@ obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2836.o
 obj-$(CONFIG_ARCH_EXYNOS)		+= exynos-combiner.o
 obj-$(CONFIG_ARCH_HIP04)		+= irq-hip04.o
 obj-$(CONFIG_ARCH_MMP)			+= irq-mmp.o
-obj-$(CONFIG_ARCH_MVEBU)		+= irq-armada-370-xp.o
 obj-$(CONFIG_IRQ_MXS)			+= irq-mxs.o
 obj-$(CONFIG_ARCH_TEGRA)		+= irq-tegra.o
 obj-$(CONFIG_ARCH_S3C24XX)		+= irq-s3c24xx.o
@@ -28,6 +27,7 @@ obj-$(CONFIG_ARM_GIC_V3_ITS)		+= irq-gic-v3-its.o irq-gic-v3-its-pci-msi.o irq-g
 obj-$(CONFIG_HISILICON_IRQ_MBIGEN)	+= irq-mbigen.o
 obj-$(CONFIG_ARM_NVIC)			+= irq-nvic.o
 obj-$(CONFIG_ARM_VIC)			+= irq-vic.o
+obj-$(CONFIG_ARMADA_370_XP_IRQ)		+= irq-armada-370-xp.o
 obj-$(CONFIG_ATMEL_AIC_IRQ)		+= irq-atmel-aic-common.o irq-atmel-aic.o
 obj-$(CONFIG_ATMEL_AIC5_IRQ)	+= irq-atmel-aic-common.o irq-atmel-aic5.o
 obj-$(CONFIG_I8259)			+= irq-i8259.o
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 10 06:46:55 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Feb 2016 15:46:55 +0100
Subject: [PATCH v3 0/6] irqchip: irq-armada-370-xp: generic MSI infrastructure
 and assorted fixes
Message-ID: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hello,

This patch series converts the Armada 370/XP irqchip driver (also used
on Armada 375, 38x and 39x) to the new MSI infrastructure put in place
by Marc. It doesn't bring any functional difference other than using
the right, modern, MSI mechanism, which might ultimately allow Marc to
remove the old way of implementing MSI support.

It has been tested on Armada 38x and Armada XP with an Intel e1000e
NIC and an Intel IGB NIC, both of which use MSI interrupts.

Note that this patch series depends on the patch series from Marc
Zyngier for proper operation, which have already been merged in
tip.git by Thomas Gleixner:

  http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=530cbe100ef7587aa5b5ac3a4b670cda4d50e598
  http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=14a0db3cdd114da757197193f66786e63649c91e

Changes since v2:

 - No code changes.

 - Added Reviewed-by from Marc Zyngier on patches:

   irqchip: irq-armada-370-xp: use the generic MSI infrastructure

 - Added Acked-by from Gregory Clement on patches:

   irqchip: irq-armada-370-xp: use PCI_MSI_DOORBELL_START where appropriate
   irqchip: irq-armada-370-xp: use shorter names for irq_chip
   ARM: mvebu: use the ARMADA_370_XP_IRQ option

 - Added Reviewed-by from Gregory Clement on patches:

   irqchip: irq-armada-370-xp: allow allocation of multiple MSIs

 - Posted to a wider audience, including lkml.

Changes since v1:

 - Rebased on top of v4.5-rc1, and the latest version of Marc Zyngier
   irqchip core fixes, which are needed for this series to work.

 - Added Acked-by from Gregory Clement on patch "irqchip:
   irq-armada-370-xp: add Kconfig option for the driver"

 - Add a new patch that changes hardcoded "16" values by the
   appropriate PCI_MSI_DOORBELL_START definition. Noticed by Gregory
   Clement.

 - Drop the ->irq_enable() and ->irq_disable() callbacks from struct
   irq_chip armada_370_xp_msi_irq_chip, as they are not needed, since
   we already provide the same callbacks for ->irq_mask() and
   ->irq_unmask(). Noticed by Marc Zyngier.

 - Drop the MSI_FLAG_MULTI_PCI_MSI, since we don't (yet) support
   allocating multiple MSIs as once. Noticed by Marc Zyngier.

 - Added a separate commit actually implementing the allocation of
   multiple MSIs at once, and therefore adds the
   MSI_FLAG_MULTI_PCI_MSI.

 - Reorder code in armada_370_xp_mpic_of_init() to make a BUG_ON()
   really useful. Noticed by Marc Zyngier.

Thanks!

Thomas

Thomas Petazzoni (6):
  irqchip: irq-armada-370-xp: add Kconfig option for the driver
  irqchip: irq-armada-370-xp: use the generic MSI infrastructure
  irqchip: irq-armada-370-xp: use PCI_MSI_DOORBELL_START where
    appropriate
  irqchip: irq-armada-370-xp: use shorter names for irq_chip
  irqchip: irq-armada-370-xp: allow allocation of multiple MSIs
  ARM: mvebu: use the ARMADA_370_XP_IRQ option

 arch/arm/mach-mvebu/Kconfig         |   6 +-
 drivers/irqchip/Kconfig             |   6 ++
 drivers/irqchip/Makefile            |   2 +-
 drivers/irqchip/irq-armada-370-xp.c | 156 +++++++++++++++---------------------
 4 files changed, 78 insertions(+), 92 deletions(-)

-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 10 06:46:57 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Feb 2016 15:46:57 +0100
Subject: [PATCH v3 2/6] irqchip: irq-armada-370-xp: use the generic MSI
 infrastructure
In-Reply-To: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455115621-22846-3-git-send-email-thomas.petazzoni@free-electrons.com>

This commit moves the irq-armada-370-xp driver from using the
PCI-specific MSI infrastructure to the generic MSI infrastructure, to
which drivers are progressively converted.

In this hardware, the MSI controller is directly bundled inside the
interrupt controller, so we have a single Device Tree node to which
multiple IRQ domaines are attached: the wired interrupt domain and the
MSI interrupt domain. In order to ensure that they can be
differentiated, we have to force the bus_token of the wired interrupt
domain to be DOMAIN_BUS_WIRED. The MSI domain bus_token is
automatically set to the appropriate value by
pci_msi_create_irq_domain().

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Suggested-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
---
 drivers/irqchip/Kconfig             |   1 +
 drivers/irqchip/irq-armada-370-xp.c | 149 +++++++++++++++---------------------
 2 files changed, 62 insertions(+), 88 deletions(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index e2cab87..d233a80 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -64,6 +64,7 @@ config ARMADA_370_XP_IRQ
 	bool
 	default y if ARCH_MVEBU
 	select GENERIC_IRQ_CHIP
+	select PCI_MSI_IRQ_DOMAIN if PCI_MSI
 
 config ATMEL_AIC_IRQ
 	bool
diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index 3f3a8c3..e5738c5 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -71,6 +71,7 @@ static u32 doorbell_mask_reg;
 static int parent_irq;
 #ifdef CONFIG_PCI_MSI
 static struct irq_domain *armada_370_xp_msi_domain;
+static struct irq_domain *armada_370_xp_msi_inner_domain;
 static DECLARE_BITMAP(msi_used, PCI_MSI_DOORBELL_NR);
 static DEFINE_MUTEX(msi_used_lock);
 static phys_addr_t msi_doorbell_addr;
@@ -115,127 +116,99 @@ static void armada_370_xp_irq_unmask(struct irq_data *d)
 
 #ifdef CONFIG_PCI_MSI
 
-static int armada_370_xp_alloc_msi(void)
-{
-	int hwirq;
-
-	mutex_lock(&msi_used_lock);
-	hwirq = find_first_zero_bit(&msi_used, PCI_MSI_DOORBELL_NR);
-	if (hwirq >= PCI_MSI_DOORBELL_NR)
-		hwirq = -ENOSPC;
-	else
-		set_bit(hwirq, msi_used);
-	mutex_unlock(&msi_used_lock);
+static struct irq_chip armada_370_xp_msi_irq_chip = {
+	.name = "armada_370_xp_msi_irq",
+	.irq_mask = pci_msi_mask_irq,
+	.irq_unmask = pci_msi_unmask_irq,
+};
 
-	return hwirq;
-}
+static struct msi_domain_info armada_370_xp_msi_domain_info = {
+	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),
+	.chip	= &armada_370_xp_msi_irq_chip,
+};
 
-static void armada_370_xp_free_msi(int hwirq)
+static void armada_370_xp_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
 {
-	mutex_lock(&msi_used_lock);
-	if (!test_bit(hwirq, msi_used))
-		pr_err("trying to free unused MSI#%d\n", hwirq);
-	else
-		clear_bit(hwirq, msi_used);
-	mutex_unlock(&msi_used_lock);
+	msg->address_lo = lower_32_bits(msi_doorbell_addr);
+	msg->address_hi = upper_32_bits(msi_doorbell_addr);
+	msg->data = 0xf00 | (data->hwirq + PCI_MSI_DOORBELL_START);
 }
 
-static int armada_370_xp_setup_msi_irq(struct msi_controller *chip,
-				       struct pci_dev *pdev,
-				       struct msi_desc *desc)
+static int armada_370_xp_msi_set_affinity(struct irq_data *irq_data,
+					  const struct cpumask *mask, bool force)
 {
-	struct msi_msg msg;
-	int virq, hwirq;
+	 return -EINVAL;
+}
 
-	/* We support MSI, but not MSI-X */
-	if (desc->msi_attrib.is_msix)
-		return -EINVAL;
+static struct irq_chip armada_370_xp_msi_bottom_irq_chip = {
+	.name			= "armada_370_xp_msi_irq",
+	.irq_compose_msi_msg	= armada_370_xp_compose_msi_msg,
+	.irq_set_affinity	= armada_370_xp_msi_set_affinity,
+};
 
-	hwirq = armada_370_xp_alloc_msi();
-	if (hwirq < 0)
-		return hwirq;
+static int armada_370_xp_msi_alloc(struct irq_domain *domain, unsigned int virq,
+				   unsigned int nr_irqs, void *args)
+{
+	int hwirq;
 
-	virq = irq_create_mapping(armada_370_xp_msi_domain, hwirq);
-	if (!virq) {
-		armada_370_xp_free_msi(hwirq);
-		return -EINVAL;
+	mutex_lock(&msi_used_lock);
+	hwirq = find_first_zero_bit(&msi_used, PCI_MSI_DOORBELL_NR);
+	if (hwirq >= PCI_MSI_DOORBELL_NR) {
+		mutex_unlock(&msi_used_lock);
+		return -ENOSPC;
 	}
 
-	irq_set_msi_desc(virq, desc);
+	set_bit(hwirq, msi_used);
+	mutex_unlock(&msi_used_lock);
 
-	msg.address_lo = msi_doorbell_addr;
-	msg.address_hi = 0;
-	msg.data = 0xf00 | (hwirq + 16);
+	irq_domain_set_info(domain, virq, hwirq, &armada_370_xp_msi_bottom_irq_chip,
+			    domain->host_data, handle_simple_irq,
+			    NULL, NULL);
 
-	pci_write_msi_msg(virq, &msg);
-	return 0;
+	return hwirq;
 }
 
-static void armada_370_xp_teardown_msi_irq(struct msi_controller *chip,
-					   unsigned int irq)
+static void armada_370_xp_msi_free(struct irq_domain *domain,
+				   unsigned int virq, unsigned int nr_irqs)
 {
-	struct irq_data *d = irq_get_irq_data(irq);
-	unsigned long hwirq = d->hwirq;
-
-	irq_dispose_mapping(irq);
-	armada_370_xp_free_msi(hwirq);
-}
-
-static struct irq_chip armada_370_xp_msi_irq_chip = {
-	.name = "armada_370_xp_msi_irq",
-	.irq_enable = pci_msi_unmask_irq,
-	.irq_disable = pci_msi_mask_irq,
-	.irq_mask = pci_msi_mask_irq,
-	.irq_unmask = pci_msi_unmask_irq,
-};
+	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
 
-static int armada_370_xp_msi_map(struct irq_domain *domain, unsigned int virq,
-				 irq_hw_number_t hw)
-{
-	irq_set_chip_and_handler(virq, &armada_370_xp_msi_irq_chip,
-				 handle_simple_irq);
-
-	return 0;
+	mutex_lock(&msi_used_lock);
+	if (!test_bit(d->hwirq, msi_used))
+		pr_err("trying to free unused MSI#%lu\n", d->hwirq);
+	else
+		clear_bit(d->hwirq, msi_used);
+	mutex_unlock(&msi_used_lock);
 }
 
-static const struct irq_domain_ops armada_370_xp_msi_irq_ops = {
-	.map = armada_370_xp_msi_map,
+static const struct irq_domain_ops armada_370_xp_msi_domain_ops = {
+	.alloc	= armada_370_xp_msi_alloc,
+	.free	= armada_370_xp_msi_free,
 };
 
 static int armada_370_xp_msi_init(struct device_node *node,
 				  phys_addr_t main_int_phys_base)
 {
-	struct msi_controller *msi_chip;
 	u32 reg;
-	int ret;
 
 	msi_doorbell_addr = main_int_phys_base +
 		ARMADA_370_XP_SW_TRIG_INT_OFFS;
 
-	msi_chip = kzalloc(sizeof(*msi_chip), GFP_KERNEL);
-	if (!msi_chip)
+	armada_370_xp_msi_inner_domain =
+		irq_domain_add_linear(NULL, PCI_MSI_DOORBELL_NR,
+				      &armada_370_xp_msi_domain_ops, NULL);
+	if (!armada_370_xp_msi_inner_domain)
 		return -ENOMEM;
 
-	msi_chip->setup_irq = armada_370_xp_setup_msi_irq;
-	msi_chip->teardown_irq = armada_370_xp_teardown_msi_irq;
-	msi_chip->of_node = node;
-
 	armada_370_xp_msi_domain =
-		irq_domain_add_linear(NULL, PCI_MSI_DOORBELL_NR,
-				      &armada_370_xp_msi_irq_ops,
-				      NULL);
+		pci_msi_create_irq_domain(of_node_to_fwnode(node),
+					  &armada_370_xp_msi_domain_info,
+					  armada_370_xp_msi_inner_domain);
 	if (!armada_370_xp_msi_domain) {
-		kfree(msi_chip);
+		irq_domain_remove(armada_370_xp_msi_inner_domain);
 		return -ENOMEM;
 	}
 
-	ret = of_pci_msi_chip_add(msi_chip);
-	if (ret < 0) {
-		irq_domain_remove(armada_370_xp_msi_domain);
-		kfree(msi_chip);
-		return ret;
-	}
-
 	reg = readl(per_cpu_int_base + ARMADA_370_XP_IN_DRBEL_MSK_OFFS)
 		| PCI_MSI_DOORBELL_MASK;
 
@@ -427,12 +400,12 @@ static void armada_370_xp_handle_msi_irq(struct pt_regs *regs, bool is_chained)
 			continue;
 
 		if (is_chained) {
-			irq = irq_find_mapping(armada_370_xp_msi_domain,
+			irq = irq_find_mapping(armada_370_xp_msi_inner_domain,
 					       msinr - 16);
 			generic_handle_irq(irq);
 		} else {
 			irq = msinr - 16;
-			handle_domain_irq(armada_370_xp_msi_domain,
+			handle_domain_irq(armada_370_xp_msi_inner_domain,
 					  irq, regs);
 		}
 	}
@@ -604,8 +577,8 @@ static int __init armada_370_xp_mpic_of_init(struct device_node *node,
 	armada_370_xp_mpic_domain =
 		irq_domain_add_linear(node, nr_irqs,
 				&armada_370_xp_mpic_irq_ops, NULL);
-
 	BUG_ON(!armada_370_xp_mpic_domain);
+	armada_370_xp_mpic_domain->bus_token = DOMAIN_BUS_WIRED;
 
 	/* Setup for the boot CPU */
 	armada_xp_mpic_perf_init();
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 10 06:47:01 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Feb 2016 15:47:01 +0100
Subject: [PATCH v3 6/6] ARM: mvebu: use the ARMADA_370_XP_IRQ option
In-Reply-To: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455115621-22846-7-git-send-email-thomas.petazzoni@free-electrons.com>

Now that there is a ARMADA_370_XP_IRQ option to enable the irqchip
driver for Armada 370, XP, 375, 38x and 39x, let's select this option
when needed. Note that this selection is currently not mandatory
because ARMADA_370_XP_IRQ is for now always enabled when ARCH_MVEBU=y,
but this is something that we will change in the future, and therefore
we should make the relevant platforms select ARMADA_370_XP_IRQ when
needed.

Due to this, selecting GENERIC_IRQ_CHIP is no longer needed.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/mach-mvebu/Kconfig | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 64e3d2c..b003e3a 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -3,7 +3,6 @@ menuconfig ARCH_MVEBU
 	depends on ARCH_MULTI_V7 || ARCH_MULTI_V5
 	select ARCH_SUPPORTS_BIG_ENDIAN
 	select CLKSRC_MMIO
-	select GENERIC_IRQ_CHIP
 	select PINCTRL
 	select PLAT_ORION
 	select SOC_BUS
@@ -29,6 +28,7 @@ config MACH_ARMADA_370
 	bool "Marvell Armada 370 boards"
 	depends on ARCH_MULTI_V7
 	select ARMADA_370_CLK
+	select ARMADA_370_XP_IRQ
 	select CPU_PJ4B
 	select MACH_MVEBU_V7
 	select PINCTRL_ARMADA_370
@@ -39,6 +39,7 @@ config MACH_ARMADA_370
 config MACH_ARMADA_375
 	bool "Marvell Armada 375 boards"
 	depends on ARCH_MULTI_V7
+	select ARMADA_370_XP_IRQ
 	select ARM_ERRATA_720789
 	select ARM_ERRATA_753970
 	select ARM_GIC
@@ -58,6 +59,7 @@ config MACH_ARMADA_38X
 	select ARM_ERRATA_720789
 	select ARM_ERRATA_753970
 	select ARM_GIC
+	select ARMADA_370_XP_IRQ
 	select ARMADA_38X_CLK
 	select HAVE_ARM_SCU
 	select HAVE_ARM_TWD if SMP
@@ -72,6 +74,7 @@ config MACH_ARMADA_39X
 	bool "Marvell Armada 39x boards"
 	depends on ARCH_MULTI_V7
 	select ARM_GIC
+	select ARMADA_370_XP_IRQ
 	select ARMADA_39X_CLK
 	select CACHE_L2X0
 	select HAVE_ARM_SCU
@@ -86,6 +89,7 @@ config MACH_ARMADA_39X
 config MACH_ARMADA_XP
 	bool "Marvell Armada XP boards"
 	depends on ARCH_MULTI_V7
+	select ARMADA_370_XP_IRQ
 	select ARMADA_XP_CLK
 	select CPU_PJ4B
 	select MACH_MVEBU_V7
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 10 06:47:00 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Feb 2016 15:47:00 +0100
Subject: [PATCH v3 5/6] irqchip: irq-armada-370-xp: allow allocation of
 multiple MSIs
In-Reply-To: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455115621-22846-6-git-send-email-thomas.petazzoni@free-electrons.com>

Add support for allocating multiple MSIs at the same time, so that the
MSI_FLAG_MULTI_PCI_MSI flag can be added to the msi_domain_info
structure.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/irqchip/irq-armada-370-xp.c | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/irqchip/irq-armada-370-xp.c b/drivers/irqchip/irq-armada-370-xp.c
index c99ae5f..e7dc6cb 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -123,7 +123,8 @@ static struct irq_chip armada_370_xp_msi_irq_chip = {
 };
 
 static struct msi_domain_info armada_370_xp_msi_domain_info = {
-	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),
+	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+		   MSI_FLAG_MULTI_PCI_MSI),
 	.chip	= &armada_370_xp_msi_irq_chip,
 };
 
@@ -149,21 +150,26 @@ static struct irq_chip armada_370_xp_msi_bottom_irq_chip = {
 static int armada_370_xp_msi_alloc(struct irq_domain *domain, unsigned int virq,
 				   unsigned int nr_irqs, void *args)
 {
-	int hwirq;
+	int hwirq, i;
 
 	mutex_lock(&msi_used_lock);
-	hwirq = find_first_zero_bit(&msi_used, PCI_MSI_DOORBELL_NR);
+
+	hwirq = bitmap_find_next_zero_area(msi_used, PCI_MSI_DOORBELL_NR,
+					   0, nr_irqs, 0);
 	if (hwirq >= PCI_MSI_DOORBELL_NR) {
 		mutex_unlock(&msi_used_lock);
 		return -ENOSPC;
 	}
 
-	set_bit(hwirq, msi_used);
+	bitmap_set(msi_used, hwirq, nr_irqs);
 	mutex_unlock(&msi_used_lock);
 
-	irq_domain_set_info(domain, virq, hwirq, &armada_370_xp_msi_bottom_irq_chip,
-			    domain->host_data, handle_simple_irq,
-			    NULL, NULL);
+	for (i = 0; i < nr_irqs; i++) {
+		irq_domain_set_info(domain, virq + i, hwirq + i,
+				    &armada_370_xp_msi_bottom_irq_chip,
+				    domain->host_data, handle_simple_irq,
+				    NULL, NULL);
+	}
 
 	return hwirq;
 }
@@ -174,10 +180,7 @@ static void armada_370_xp_msi_free(struct irq_domain *domain,
 	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
 
 	mutex_lock(&msi_used_lock);
-	if (!test_bit(d->hwirq, msi_used))
-		pr_err("trying to free unused MSI#%lu\n", d->hwirq);
-	else
-		clear_bit(d->hwirq, msi_used);
+	bitmap_clear(msi_used, d->hwirq, nr_irqs);
 	mutex_unlock(&msi_used_lock);
 }
 
-- 
2.6.4



From alim.akhtar at gmail.com  Wed Feb 10 06:53:14 2016
From: alim.akhtar at gmail.com (Alim Akhtar)
Date: Wed, 10 Feb 2016 20:23:14 +0530
Subject: [PATCH] ARM: dts: Move syscon reboot/poweroff to common dtsi for
 Exynos
In-Reply-To: <1455042606-10075-1-git-send-email-javier@osg.samsung.com>
References: <1455042606-10075-1-git-send-email-javier@osg.samsung.com>
Message-ID: <CAGOxZ53YNc43W6ja+p=u-SMLnj0MfaN9uMq7Qqd28s6RWHHY0w@mail.gmail.com>

Hi Javier,

On Wed, Feb 10, 2016 at 12:00 AM, Javier Martinez Canillas
<javier at osg.samsung.com> wrote:
> All Exynos SoCs have the same syscon reboot and poweroff device nodes so
> there is no need to duplicate the same on each SoC dtsi and can be moved
> to a common dtsi that can be included by all the SoCs dtsi files.
>
> Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
>
Looks good to me.
Reviewed-by: Alim Akhtar <alim.akhtar at samsung,com>
> ---
> Hello,
>
> The patch was tested on an Exynos5800 Peach Pi Chromebook and an
> Exynos5422 Odroid XU4 board. Reboot and poweroff worked for both.
>
> But testing on Exynos3 and Exynos4 will be highly appreciated.
>
> Best regards,
> Javier
>
>  arch/arm/boot/dts/exynos-syscon-restart.dtsi | 23 +++++++++++++++++++++++
>  arch/arm/boot/dts/exynos3250.dtsi            | 15 +--------------
>  arch/arm/boot/dts/exynos4.dtsi               | 15 +--------------
>  arch/arm/boot/dts/exynos5.dtsi               | 15 +--------------
>  arch/arm/boot/dts/exynos5410.dtsi            | 15 +--------------
>  5 files changed, 27 insertions(+), 56 deletions(-)
>  create mode 100644 arch/arm/boot/dts/exynos-syscon-restart.dtsi
>
> diff --git a/arch/arm/boot/dts/exynos-syscon-restart.dtsi b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
> new file mode 100644
> index 000000000000..2b8acf554881
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
> @@ -0,0 +1,23 @@
> +/*
> + * Samsung's Exynos SoC syscon reboot/poweroff nodes common definition.
> + *
> + * 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.
> + */
> +
> +/ {
> +       poweroff: syscon-poweroff {
> +               compatible = "syscon-poweroff";
> +               regmap = <&pmu_system_controller>;
> +               offset = <0x330C>; /* PS_HOLD_CONTROL */
> +               mask = <0x5200>; /* reset value */
> +       };
> +
> +       reboot: syscon-reboot {
> +               compatible = "syscon-reboot";
> +               regmap = <&pmu_system_controller>;
> +               offset = <0x0400>; /* SWRESET */
> +               mask = <0x1>;
> +       };
> +};
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
> index 18e3deffbf48..d9c221517935 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -19,6 +19,7 @@
>
>  #include "skeleton.dtsi"
>  #include "exynos4-cpu-thermal.dtsi"
> +#include "exynos-syscon-restart.dtsi"
>  #include <dt-bindings/clock/exynos3250.h>
>
>  / {
> @@ -152,20 +153,6 @@
>                         interrupt-parent = <&gic>;
>                 };
>
> -               poweroff: syscon-poweroff {
> -                       compatible = "syscon-poweroff";
> -                       regmap = <&pmu_system_controller>;
> -                       offset = <0x330C>; /* PS_HOLD_CONTROL */
> -                       mask = <0x5200>; /* Reset value */
> -               };
> -
> -               reboot: syscon-reboot {
> -                       compatible = "syscon-reboot";
> -                       regmap = <&pmu_system_controller>;
> -                       offset = <0x0400>; /* SWRESET */
> -                       mask = <0x1>;
> -               };
> -
>                 mipi_phy: video-phy at 10020710 {
>                         compatible = "samsung,s5pv210-mipi-video-phy";
>                         #phy-cells = <1>;
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index ca621a92319e..e6f6939ccdfa 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -21,6 +21,7 @@
>
>  #include <dt-bindings/clock/exynos4.h>
>  #include <dt-bindings/clock/exynos-audss-clk.h>
> +#include "exynos-syscon-restart.dtsi"
>  #include "skeleton.dtsi"
>
>  / {
> @@ -163,20 +164,6 @@
>                 interrupt-parent = <&gic>;
>         };
>
> -       poweroff: syscon-poweroff {
> -               compatible = "syscon-poweroff";
> -               regmap = <&pmu_system_controller>;
> -               offset = <0x330C>; /* PS_HOLD_CONTROL */
> -               mask = <0x5200>; /* reset value */
> -       };
> -
> -       reboot: syscon-reboot {
> -               compatible = "syscon-reboot";
> -               regmap = <&pmu_system_controller>;
> -               offset = <0x0400>; /* SWRESET */
> -               mask = <0x1>;
> -       };
> -
>         dsi_0: dsi at 11C80000 {
>                 compatible = "samsung,exynos4210-mipi-dsi";
>                 reg = <0x11C80000 0x10000>;
> diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
> index b61d1f637510..92313cac035e 100644
> --- a/arch/arm/boot/dts/exynos5.dtsi
> +++ b/arch/arm/boot/dts/exynos5.dtsi
> @@ -14,6 +14,7 @@
>   */
>
>  #include "skeleton.dtsi"
> +#include "exynos-syscon-restart.dtsi"
>
>  / {
>         interrupt-parent = <&gic>;
> @@ -93,20 +94,6 @@
>                 status = "disabled";
>         };
>
> -       poweroff: syscon-poweroff {
> -               compatible = "syscon-poweroff";
> -               regmap = <&pmu_system_controller>;
> -               offset = <0x330C>; /* PS_HOLD_CONTROL */
> -               mask = <0x5200>; /* reset value */
> -       };
> -
> -       reboot: syscon-reboot {
> -               compatible = "syscon-reboot";
> -               regmap = <&pmu_system_controller>;
> -               offset = <0x0400>; /* SWRESET */
> -               mask = <0x1>;
> -       };
> -
>         fimd: fimd at 14400000 {
>                 compatible = "samsung,exynos5250-fimd";
>                 interrupt-parent = <&combiner>;
> diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
> index f3490f567344..fa558674ac76 100644
> --- a/arch/arm/boot/dts/exynos5410.dtsi
> +++ b/arch/arm/boot/dts/exynos5410.dtsi
> @@ -14,6 +14,7 @@
>   */
>
>  #include "skeleton.dtsi"
> +#include "exynos-syscon-restart.dtsi"
>  #include <dt-bindings/clock/exynos5410.h>
>
>  / {
> @@ -117,20 +118,6 @@
>                         reg = <0x10040000 0x5000>;
>                 };
>
> -               poweroff: syscon-poweroff {
> -                       compatible = "syscon-poweroff";
> -                       regmap = <&pmu_system_controller>;
> -                       offset = <0x330C>; /* PS_HOLD_CONTROL */
> -                       mask = <0x5200>; /* reset value */
> -               };
> -
> -               reboot: syscon-reboot {
> -                       compatible = "syscon-reboot";
> -                       regmap = <&pmu_system_controller>;
> -                       offset = <0x0400>; /* SWRESET */
> -                       mask = <0x1>;
> -               };
> -
>                 mct: mct at 101C0000 {
>                         compatible = "samsung,exynos4210-mct";
>                         reg = <0x101C0000 0xB00>;
> --
> 2.5.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Regards,
Alim


From mathieu.poirier at linaro.org  Wed Feb 10 06:57:09 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 10 Feb 2016 07:57:09 -0700
Subject: [PATCH v11 4/4] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <1455037240-16192-5-git-send-email-fu.wei@linaro.org>
References: <1455037240-16192-1-git-send-email-fu.wei@linaro.org>
 <1455037240-16192-5-git-send-email-fu.wei@linaro.org>
Message-ID: <CANLsYkwjFwy_2zoU04sRsEgoj3y+wesat=TUjBCpG=iw5WweHw@mail.gmail.com>

On 9 February 2016 at 10:00,  <fu.wei at linaro.org> wrote:
> From: Fu Wei <fu.wei at linaro.org>
>
> According to Server Base System Architecture (SBSA) specification,
> the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0)
> is for alerting the system by interrupt, the second one (WS1) is a real
> hardware reset.
> More details about the hardware specification of this device:
> ARM DEN0029B - Server Base System Architecture (SBSA)
>
> This driver can operate ARM SBSA Generic Watchdog as a single stage watchdog
> or a two stages watchdog, it's set up by the module parameter "action".
> In the single stage mode, when the timeout is reached, your system
> will be reset by WS1. The first signal (WS0) is ignored.
> In the two stages mode, when the timeout is reached, the first signal (WS0)
> will trigger panic. If the system is getting into trouble and cannot be reset
> by panic or restart properly by the kdump kernel(if supported), then the
> second stage (as long as the first stage) will be reached, system will be
> reset by WS1. This function can help administrator to backup the system
> context info by panic console output or kdump.
>
> This driver bases on linux kernel watchdog framework, so it can get
> timeout from module parameter and FDT at the driver init stage.
>
> Signed-off-by: Fu Wei <fu.wei at linaro.org>
> Reviewed-by: Graeme Gregory <graeme.gregory at linaro.org>
> Tested-by: Pratyush Anand <panand at redhat.com>
> ---
>  drivers/watchdog/Kconfig     |  20 +++
>  drivers/watchdog/Makefile    |   1 +
>  drivers/watchdog/sbsa_gwdt.c | 403 +++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 424 insertions(+)
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 0f6d851..ed9a5cb 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -202,6 +202,26 @@ config ARM_SP805_WATCHDOG
>           ARM Primecell SP805 Watchdog timer. This will reboot your system when
>           the timeout is reached.
>
> +config ARM_SBSA_WATCHDOG
> +       tristate "ARM SBSA Generic Watchdog"
> +       depends on ARM64
> +       depends on ARM_ARCH_TIMER
> +       select WATCHDOG_CORE
> +       help
> +         ARM SBSA Generic Watchdog has two stage timeouts:
> +         the first signal (WS0) is for alerting the system by interrupt,
> +         the second one (WS1) is a real hardware reset.
> +         More details: ARM DEN0029B - Server Base System Architecture (SBSA)
> +
> +         This driver can operate ARM SBSA Generic Watchdog as a single stage
> +         or a two stages watchdog, it depends on the module parameter "action".
> +
> +         Note: the maximum timeout in the two stages mode is half of that in
> +         the single stage mode.
> +
> +         To compile this driver as module, choose M here: The module
> +         will be called sbsa_gwdt.
> +
>  config ASM9260_WATCHDOG
>         tristate "Alphascale ASM9260 watchdog"
>         depends on MACH_ASM9260
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index f566753..f9826d4 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
>
>  # ARM Architecture
>  obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
> +obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
>  obj-$(CONFIG_ASM9260_WATCHDOG) += asm9260_wdt.o
>  obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
>  obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
> new file mode 100644
> index 0000000..f506762
> --- /dev/null
> +++ b/drivers/watchdog/sbsa_gwdt.c
> @@ -0,0 +1,403 @@
> +/*
> + * SBSA(Server Base System Architecture) Generic Watchdog driver
> + *
> + * Copyright (c) 2015, Linaro Ltd.
> + * Author: Fu Wei <fu.wei at linaro.org>
> + *         Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
> + *         Al Stone <al.stone at linaro.org>
> + *         Timur Tabi <timur at codeaurora.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License 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.
> + *
> + * ARM SBSA Generic Watchdog has two stage timeouts:
> + * the first signal (WS0) is for alerting the system by interrupt,
> + * the second one (WS1) is a real hardware reset.
> + * More details about the hardware specification of this device:
> + * ARM DEN0029B - Server Base System Architecture (SBSA)
> + *
> + * This driver can operate ARM SBSA Generic Watchdog as a single stage watchdog
> + * or a two stages watchdog, it's set up by the module parameter "action".
> + * In the single stage mode, when the timeout is reached, your system
> + * will be reset by WS1. The first signal (WS0) is ignored.
> + * In the two stages mode, when the timeout is reached, the first signal (WS0)
> + * will trigger panic. If the system is getting into trouble and cannot be reset
> + * by panic or restart properly by the kdump kernel(if supported), then the
> + * second stage (as long as the first stage) will be reached, system will be
> + * reset by WS1. This function can help administrator to backup the system
> + * context info by panic console output or kdump.
> + *
> + * SBSA GWDT:
> + * if action is 1 (the two stages mode):
> + * |--------WOR-------WS0--------WOR-------WS1
> + * |----timeout-----(panic)----timeout-----reset
> + *
> + * if action is 0 (the single stage mode):
> + * |------WOR-----WS0(ignored)-----WOR------WS1
> + * |--------------timeout-------------------reset
> + *
> + * Note: Since this watchdog timer has two stages, and each stage is determined
> + * by WOR, in the single stage mode, the timeout is (WOR * 2); in the two
> + * stages mode, the timeout is WOR. The maximum timeout in the two stages mode
> + * is half of that in the single stage mode.
> + *
> + */
> +
> +#include <linux/io.h>
> +#include <linux/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/uaccess.h>
> +#include <linux/watchdog.h>
> +#include <asm/arch_timer.h>
> +
> +/* SBSA Generic Watchdog register definitions */
> +/* refresh frame */
> +#define SBSA_GWDT_WRR                          0x000
> +
> +/* control frame */
> +#define SBSA_GWDT_WCS                          0x000
> +#define SBSA_GWDT_WOR                          0x008
> +#define SBSA_GWDT_WCV                          0x010
> +
> +/* refresh/control frame */
> +#define SBSA_GWDT_W_IIDR                       0xfcc
> +#define SBSA_GWDT_IDR                          0xfd0
> +
> +/* Watchdog Control and Status Register */
> +#define SBSA_GWDT_WCS_EN                       BIT(0)
> +#define SBSA_GWDT_WCS_WS0                      BIT(1)
> +#define SBSA_GWDT_WCS_WS1                      BIT(2)
> +
> +/**
> + * struct sbsa_gwdt - Internal representation of the SBSA GWDT
> + * @wdd:               kernel watchdog_device structure
> + * @clk:               store the System Counter clock frequency, in Hz.
> + * @refresh_base:      Virtual address of the watchdog refresh frame
> + * @control_base:      Virtual address of the watchdog control frame
> + */
> +struct sbsa_gwdt {
> +       struct watchdog_device  wdd;
> +       u32                     clk;
> +       void __iomem            *refresh_base;
> +       void __iomem            *control_base;
> +};
> +
> +#define to_sbsa_gwdt(e) container_of(e, struct sbsa_gwdt, wdd)
> +
> +#define DEFAULT_TIMEOUT                10 /* seconds, the 1st + 2nd watch periods*/
> +
> +static unsigned int timeout;
> +module_param(timeout, uint, 0);
> +MODULE_PARM_DESC(timeout,
> +                "Watchdog timeout in seconds. (>=0, default="
> +                __MODULE_STRING(DEFAULT_TIMEOUT) ")");
> +
> +/*
> + * action refers to action taken when watchdog gets WS0
> + * 0 = skip
> + * 1 = panic
> + * defaults to skip (0)
> + */
> +static int action;
> +module_param(action, int, 0);
> +MODULE_PARM_DESC(action, "after watchdog gets WS0 interrupt, do: "
> +                "0 = skip(*)  1 = panic");
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +module_param(nowayout, bool, S_IRUGO);
> +MODULE_PARM_DESC(nowayout,
> +                "Watchdog cannot be stopped once started (default="
> +                __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> +
> +/*
> + * watchdog operation functions
> + */
> +static int sbsa_gwdt_set_timeout(struct watchdog_device *wdd,
> +                                unsigned int timeout)
> +{
> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +
> +       wdd->timeout = timeout;
> +
> +       if (action)
> +               writel(gwdt->clk * timeout,
> +                      gwdt->control_base + SBSA_GWDT_WOR);
> +       else
> +               /*
> +                * In the single stage mode, The first signal (WS0) is ignored,
> +                * the timeout is (WOR * 2), so the WOR should be configured
> +                * to half value of timeout.
> +                */
> +               writel(gwdt->clk / 2 * timeout,
> +                      gwdt->control_base + SBSA_GWDT_WOR);
> +
> +       return 0;
> +}
> +
> +static unsigned int sbsa_gwdt_get_timeleft(struct watchdog_device *wdd)
> +{
> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +       u64 timeleft = 0;
> +
> +       /*
> +        * In the single stage mode, if WS0 is deasserted
> +        * (watchdog is in the first stage),
> +        * timeleft = WOR + (WCV - system counter)
> +        */
> +       if (!action &&
> +           !(readl(gwdt->control_base + SBSA_GWDT_WCS) & SBSA_GWDT_WCS_WS0))
> +               timeleft += readl(gwdt->control_base + SBSA_GWDT_WOR);
> +
> +       timeleft += readq(gwdt->control_base + SBSA_GWDT_WCV) -
> +                   arch_counter_get_cntvct();
> +
> +       do_div(timeleft, gwdt->clk);
> +
> +       return timeleft;
> +}
> +
> +static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
> +{
> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +
> +       /*
> +       * Writing WRR for an explicit watchdog refresh.
> +       * You can write anyting (like 0).
> +       */
> +       writel(0, gwdt->refresh_base + SBSA_GWDT_WRR);
> +
> +       return 0;
> +}
> +
> +static unsigned int sbsa_gwdt_status(struct watchdog_device *wdd)
> +{
> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +       u32 status = readl(gwdt->control_base + SBSA_GWDT_WCS);
> +
> +       /* is the watchdog timer running? */
> +       return (status & SBSA_GWDT_WCS_EN) << WDOG_ACTIVE;
> +}
> +
> +static int sbsa_gwdt_start(struct watchdog_device *wdd)
> +{
> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +
> +       /* writing WCS will cause an explicit watchdog refresh */
> +       writel(SBSA_GWDT_WCS_EN, gwdt->control_base + SBSA_GWDT_WCS);
> +
> +       return sbsa_gwdt_keepalive(wdd);
> +}
> +
> +static int sbsa_gwdt_stop(struct watchdog_device *wdd)
> +{
> +       struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +
> +       /* Simply write 0 to WCS to clean WCS_EN bit */
> +       writel(0, gwdt->control_base + SBSA_GWDT_WCS);
> +
> +       return 0;
> +}
> +
> +static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
> +{
> +       panic("SBSA Watchdog timeout");
> +
> +       return IRQ_HANDLED;
> +}
> +
> +static struct watchdog_info sbsa_gwdt_info = {
> +       .identity       = "SBSA Generic Watchdog",
> +       .options        = WDIOF_SETTIMEOUT |
> +                         WDIOF_KEEPALIVEPING |
> +                         WDIOF_MAGICCLOSE |
> +                         WDIOF_CARDRESET,
> +};
> +
> +static struct watchdog_ops sbsa_gwdt_ops = {
> +       .owner          = THIS_MODULE,
> +       .start          = sbsa_gwdt_start,
> +       .stop           = sbsa_gwdt_stop,
> +       .status         = sbsa_gwdt_status,
> +       .ping           = sbsa_gwdt_keepalive,
> +       .set_timeout    = sbsa_gwdt_set_timeout,
> +       .get_timeleft   = sbsa_gwdt_get_timeleft,
> +};
> +
> +static int sbsa_gwdt_probe(struct platform_device *pdev)
> +{
> +       void __iomem *rf_base, *cf_base;
> +       struct device *dev = &pdev->dev;
> +       struct watchdog_device *wdd;
> +       struct sbsa_gwdt *gwdt;
> +       struct resource *res;
> +       int ret, irq;
> +       u32 status;
> +
> +       gwdt = devm_kzalloc(dev, sizeof(*gwdt), GFP_KERNEL);
> +       if (!gwdt)
> +               return -ENOMEM;
> +       platform_set_drvdata(pdev, gwdt);
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       cf_base = devm_ioremap_resource(dev, res);
> +       if (IS_ERR(cf_base))
> +               return PTR_ERR(cf_base);
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +       rf_base = devm_ioremap_resource(dev, res);
> +       if (IS_ERR(rf_base))
> +               return PTR_ERR(rf_base);
> +
> +       if (action) {
> +               irq = platform_get_irq(pdev, 0);
> +               if (irq < 0) {
> +                       action = 0;
> +                       dev_warn(dev, "unable to get ws0 interrupt.\n");
> +               } else {
> +                       if (devm_request_irq(dev, irq, sbsa_gwdt_interrupt, 0,
> +                                            pdev->name, gwdt)) {
> +                               action = 0;
> +                               dev_warn(dev, "unable to request IRQ %d.\n",
> +                                        irq);
> +                       }
> +               }
> +               if (!action)
> +                       dev_warn(dev, "fall back to signle stage mode.\n");
> +       }
> +
> +       /*
> +        * Get the frequency of system counter from the cp15 interface of ARM
> +        * Generic timer. We don't need to check it, because if it returns "0",
> +        * system would panic in very early stage.
> +        */
> +       gwdt->clk = arch_timer_get_cntfrq();
> +       gwdt->refresh_base = rf_base;
> +       gwdt->control_base = cf_base;
> +
> +       wdd = &gwdt->wdd;
> +       wdd->parent = dev;
> +       wdd->info = &sbsa_gwdt_info;
> +       wdd->ops = &sbsa_gwdt_ops;
> +       watchdog_set_drvdata(wdd, gwdt);
> +       watchdog_set_nowayout(wdd, nowayout);
> +
> +       wdd->min_timeout = 1;
> +       wdd->max_timeout = U32_MAX / gwdt->clk;
> +       /*
> +        * In the single stage mode, The first signal (WS0) is ignored,
> +        * the timeout is (WOR * 2), so the maximum timeout should be double.
> +        */
> +       if (!action)
> +               wdd->max_timeout *= 2;
> +
> +       wdd->timeout = DEFAULT_TIMEOUT;
> +       watchdog_init_timeout(wdd, timeout, dev);
> +
> +       status = readl(gwdt->control_base + SBSA_GWDT_WCS);
> +       if (status & SBSA_GWDT_WCS_WS1) {
> +               dev_warn(dev, "System reset by WDT.\n");
> +               wdd->bootstatus |= WDIOF_CARDRESET;
> +       }
> +
> +       ret = watchdog_register_device(wdd);
> +       if (ret)
> +               return ret;
> +
> +       /*
> +        * Update timeout to WOR.
> +        * Because of the explicit watchdog refresh mechanism,
> +        * it's also a ping, if watchdog is enabled.
> +        */
> +       sbsa_gwdt_set_timeout(wdd, wdd->timeout);
> +
> +       dev_info(dev, "Initialized with %ds timeout @ %u Hz, action=%d.%s\n",
> +                wdd->timeout, gwdt->clk, action,
> +                status & SBSA_GWDT_WCS_EN ? " [enabled]" : "");
> +
> +       return 0;
> +}
> +
> +static void sbsa_gwdt_shutdown(struct platform_device *pdev)
> +{
> +       struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
> +
> +       sbsa_gwdt_stop(&gwdt->wdd);
> +}
> +
> +static int sbsa_gwdt_remove(struct platform_device *pdev)
> +{
> +       struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
> +
> +       watchdog_unregister_device(&gwdt->wdd);
> +
> +       return 0;
> +}
> +
> +/* Disable watchdog if it is active during suspend */
> +static int __maybe_unused sbsa_gwdt_suspend(struct device *dev)
> +{
> +       struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
> +
> +       if (watchdog_active(&gwdt->wdd))
> +               sbsa_gwdt_stop(&gwdt->wdd);
> +
> +       return 0;
> +}
> +
> +/* Enable watchdog and configure it if necessary */
> +static int __maybe_unused sbsa_gwdt_resume(struct device *dev)
> +{
> +       struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
> +
> +       if (watchdog_active(&gwdt->wdd))
> +               sbsa_gwdt_start(&gwdt->wdd);
> +
> +       return 0;
> +}
> +
> +static const struct dev_pm_ops sbsa_gwdt_pm_ops = {
> +       SET_SYSTEM_SLEEP_PM_OPS(sbsa_gwdt_suspend, sbsa_gwdt_resume)
> +};
> +
> +static const struct of_device_id sbsa_gwdt_of_match[] = {
> +       { .compatible = "arm,sbsa-gwdt", },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(of, sbsa_gwdt_of_match);
> +
> +static const struct platform_device_id sbsa_gwdt_pdev_match[] = {
> +       { .name = "sbsa-gwdt", },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(platform, sbsa_gwdt_pdev_match);
> +
> +static struct platform_driver sbsa_gwdt_driver = {
> +       .driver = {
> +               .name = "sbsa-gwdt",
> +               .pm = &sbsa_gwdt_pm_ops,
> +               .of_match_table = sbsa_gwdt_of_match,
> +       },
> +       .probe = sbsa_gwdt_probe,
> +       .remove = sbsa_gwdt_remove,
> +       .shutdown = sbsa_gwdt_shutdown,
> +       .id_table = sbsa_gwdt_pdev_match,
> +};
> +
> +module_platform_driver(sbsa_gwdt_driver);
> +
> +MODULE_DESCRIPTION("SBSA Generic Watchdog Driver");
> +MODULE_AUTHOR("Fu Wei <fu.wei at linaro.org>");
> +MODULE_AUTHOR("Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>");
> +MODULE_AUTHOR("Al Stone <al.stone at linaro.org>");
> +MODULE_AUTHOR("Timur Tabi <timur at codeaurora.org>");
> +MODULE_LICENSE("GPL v2");
> --
> 2.5.0
>

For this patch:

Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>


From arnd at arndb.de  Wed Feb 10 07:03:00 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 16:03 +0100
Subject: [PATCH v2 0/3] arm64: introduce the Alpine support
In-Reply-To: <1455096166-4899-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455096166-4899-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <2400841.qqlksbZnmp@wuerfel>

On Wednesday 10 February 2016 10:22:43 Antoine Tenart wrote:
> Hi all,
> 
> This series introduces the support for the arm64 Alpine family from
> Annapurna Labs, by adding a device tree for the Alpine v2 EVP. This
> board has 4 Cortex A57 and a few nodes in its device tree for now.
> 
> You can find the series at:
> https://github.com/atenart/linux.git 4.5-rc1/alpinev2-bringup
> 
> 

Acked-by: Arnd Bergmann <arnd at arndb.de>

Nice work!

	Arnd


From u.kleine-koenig at pengutronix.de  Wed Feb 10 07:03:15 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Wed, 10 Feb 2016 16:03:15 +0100
Subject: noise issues when recording sound on i.MX28
In-Reply-To: <CAOMZO5AE6HwBYz7kOFORt0HTojJLSb0MYUbkb_HCshDHy=d27g@mail.gmail.com>
References: <20160127105613.GC13664@pengutronix.de>
 <CAOMZO5BpLen517q2heramSta-R6pdESkjM6w=7FRMZebY6ue-Q@mail.gmail.com>
 <20160127144340.GD13664@pengutronix.de>
 <CAOMZO5AE6HwBYz7kOFORt0HTojJLSb0MYUbkb_HCshDHy=d27g@mail.gmail.com>
Message-ID: <20160210150315.GC13664@pengutronix.de>

Hello Fabio,

On Tue, Feb 02, 2016 at 11:00:33AM -0200, Fabio Estevam wrote:
> On Wed, Jan 27, 2016 at 12:43 PM, Uwe Kleine-K?nig
> <u.kleine-koenig at pengutronix.de> wrote:
> 
> > So you didn't hit the problem that resetting a saif didn't work, right?
> 
> No, we haven't seen this reset issue.
> 
> > Do you have a few more technical details here? A usecase of my machine
> 
> Let me find out as it has been several years I worked on this problem.
> Will let you know.

Anything new on your end? I know from Lothar that he invested quite some
time to debug his hardware setup, tested the codec instead of the i.MX28
as clock provider and several more things. I also spend some time on
this issue and we both hope that Freescale/NXP can help in better
understanding the issue and hopefully can come up with a recipe to make
concurrent recording and playback on i.MX28 work.

Lothar is in contact with Freescale, too, but up to now with little
success. The company I'm working for at the moment would also welcome a
solution here.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From maxime.ripard at free-electrons.com  Wed Feb 10 07:06:43 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 10 Feb 2016 16:06:43 +0100
Subject: [linux-sunxi] Re: [PATCH v3 1/5] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <20160210071713.GA19622@box2.japko.eu>
References: <1454542430-16572-1-git-send-email-k@japko.eu>
 <1454542430-16572-2-git-send-email-k@japko.eu>
 <20160204154752.4df7808be3364a98c496c030@free.fr>
 <20160205111152.GA31506@lukather>
 <20160205115837.GD12071@box2.japko.eu>
 <20160209171040.GR31506@lukather>
 <20160210071713.GA19622@box2.japko.eu>
Message-ID: <20160210150643.GG31506@lukather>

Hi,

On Wed, Feb 10, 2016 at 08:17:14AM +0100, Krzysztof Adamski wrote:
> On Tue, Feb 09, 2016 at 06:10:40PM +0100, Maxime Ripard wrote:
> >>>>It seems that the other compatible strings are there for historical
> >>>>reasons. Why do you need a new one with such a specific name?
> >>>>
> >>>>It would have been more sensible to add a generic compatible string as
> >>>>"allwinner,apb-gates", letting the removal of the other strings for a
> >>>>later patch...
> >>>
> >>>Yeah, it's a good idea, and it's probably time that we move to that.
> >>>
> >>>However, I'd like to keep per-soc and per-clocks compatibles in the
> >>>DT, in case we need to protect a clock in the future. That doesn't
> >>>prevent to have two compatibles thoughe, the specific and the generic.
> >>>
> >>
> >>So now I'm not sure what you mean. You suggest that I should keep using
> >>specific (sun8i_h3_apb0) or change to generic (apb-gates) in my patch?
> >
> >Both.
> >
> >To have something like that:
> >
> >compatible = "allwinner,sun8i-h3-apb0-gates-clk", "allwinner,sun4i-a10-gates-clk";
> >
> >sun4i-a10-gates-clk being the generic compatible that we would use,
> >and we can always match against the h3 specific compatible if we need
> >to have a different behaviour.
> 
> This seems like a good idea to me but since this is new thing anyways (other
> sunxi SoCs don't do this right now) shouldn't we introduce other
> more generic name for generic clock (like "allwinner,apb-gates" mentioned
> earlier, or maybe "allwinner,simple-apb-gates")?

This is not specific to the APB bus, and the earlier SoC that
introduced those kind of clocks was the A10, hence why I was
suggesting that compatible (since we generally try to use the SoC that
introduced that hardware block in the compatible name).

> Also, wouldn't this be cleaner if I use only specific compatible string
> right now and provide separate patch that adds generic compatible string to
> all current SoCs at once? The downside of this is that it's easier to get
> merge conflicts unless I wait for applying this patchset.

I'd prefer if you added the generic one and were using it in your
subsequent patches. We can always mass convert the existing drivers
later on.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160210/edc4c658/attachment.sig>

From arnd at arndb.de  Wed Feb 10 07:09:02 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 16:09:02 +0100
Subject: [PATCH] bridge: mdb: avoid uninitialized variable warning
Message-ID: <1455116946-2948649-1-git-send-email-arnd@arndb.de>

A recent change to the mdb code confused the compiler to the point
where it did not realize that the port-group returned from
br_mdb_add_group() is always valid when the function returns a nonzero
return value, so we get a spurious warning:

net/bridge/br_mdb.c: In function 'br_mdb_add':
net/bridge/br_mdb.c:542:4: error: 'pg' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    __br_mdb_notify(dev, entry, RTM_NEWMDB, pg);

Slightly rearranging the code in br_mdb_add_group() makes the problem
go away, as gcc is clever enough to see that both functions check
for 'ret != 0'.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 9e8430f8d60d ("bridge: mdb: Passing the port-group pointer to br_mdb module")
---
 net/bridge/br_mdb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/bridge/br_mdb.c b/net/bridge/br_mdb.c
index ac089286526e..9ab1fcd488c6 100644
--- a/net/bridge/br_mdb.c
+++ b/net/bridge/br_mdb.c
@@ -437,8 +437,8 @@ static int br_mdb_add_group(struct net_bridge *br, struct net_bridge_port *port,
 	mp = br_mdb_ip_get(mdb, group);
 	if (!mp) {
 		mp = br_multicast_new_group(br, port, group);
-		err = PTR_ERR(mp);
-		if (IS_ERR(mp))
+		err = PTR_ERR_OR_ZERO(mp);
+		if (err)
 			return err;
 	}
 
-- 
2.7.0



From marc.zyngier at arm.com  Wed Feb 10 07:09:44 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 15:09:44 +0000
Subject: [PATCH v5 1/3] gpio: xgene: Enable X-Gene standby GPIO as
 interrupt controller
In-Reply-To: <1454041735-8434-2-git-send-email-qnguyen@apm.com>
References: <1454041735-8434-1-git-send-email-qnguyen@apm.com>
 <1454041735-8434-2-git-send-email-qnguyen@apm.com>
Message-ID: <56BB52B8.4040501@arm.com>

Quan,

This is getting better. Some comments below.

On 29/01/16 04:28, Quan Nguyen wrote:
> Enable X-Gene standby GPIO controller as interrupt controller to provide
> its own resources. This avoids ambiguity where GIC interrupt resource is
> use as X-Gene standby GPIO interrupt resource in user driver.
> 
> Signed-off-by: Y Vo <yvo at apm.com>
> Signed-off-by: Quan Nguyen <qnguyen at apm.com>
> ---
>  drivers/gpio/gpio-xgene-sb.c | 275 ++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 243 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-xgene-sb.c b/drivers/gpio/gpio-xgene-sb.c
> index 282004d..026da90 100644
> --- a/drivers/gpio/gpio-xgene-sb.c
> +++ b/drivers/gpio/gpio-xgene-sb.c
> @@ -2,8 +2,9 @@
>   * AppliedMicro X-Gene SoC GPIO-Standby Driver
>   *
>   * Copyright (c) 2014, Applied Micro Circuits Corporation
> - * Author: 	Tin Huynh <tnhuynh at apm.com>.
> - * 		Y Vo <yvo at apm.com>.
> + * Author:	Tin Huynh <tnhuynh at apm.com>.
> + *		Y Vo <yvo at apm.com>.
> + *		Quan Nguyen <qnguyen at apm.com>.
>   *
>   * This program is free software; you can redistribute  it and/or modify it
>   * under  the terms of  the GNU General  Public License as published by the
> @@ -28,9 +29,14 @@
>  
>  #include "gpiolib.h"
>  
> -#define XGENE_MAX_GPIO_DS		22
> -#define XGENE_MAX_GPIO_DS_IRQ		6
> +/* Common property names */
> +#define XGENE_NIRQ_PROPERTY		"apm,nr-irqs"
> +#define XGENE_NGPIO_PROPERTY		"apm,nr-gpios"
> +#define XGENE_IRQ_START_PROPERTY	"apm,irq-start"
>  
> +#define XGENE_DFLT_MAX_NGPIO		22
> +#define XGENE_DFLT_MAX_NIRQ		6
> +#define XGENE_DFLT_IRQ_START_PIN	8
>  #define GPIO_MASK(x)			(1U << ((x) % 32))
>  
>  #define MPA_GPIO_INT_LVL		0x0290
> @@ -39,19 +45,32 @@
>  #define MPA_GPIO_IN_ADDR 		0x02a4
>  #define MPA_GPIO_SEL_LO 		0x0294
>  
> +#define GPIO_INT_LEVEL_H	0x000001
> +#define GPIO_INT_LEVEL_L	0x000000
> +
>  /**
>   * struct xgene_gpio_sb - GPIO-Standby private data structure.
>   * @gc:				memory-mapped GPIO controllers.
> - * @irq:			Mapping GPIO pins and interrupt number
> - * nirq:			Number of GPIO pins that supports interrupt
> + * @regs:			GPIO register base offset
> + * @irq_domain:			GPIO interrupt domain
> + * @irq_start:			GPIO pin that start support interrupt
> + * @nirq:			Number of GPIO pins that supports interrupt
> + * @parent_irq_base:		Start parent HWIRQ
>   */
>  struct xgene_gpio_sb {
>  	struct gpio_chip	gc;
> -	u32 *irq;
> -	u32 nirq;
> +	void __iomem		*regs;
> +	struct irq_domain	*irq_domain;
> +	u16			irq_start;
> +	u16			nirq;
> +	u16			parent_irq_base;
>  };
>  
> -static void xgene_gpio_set_bit(struct gpio_chip *gc, void __iomem *reg, u32 gpio, int val)
> +#define HWIRQ_TO_GPIO(priv, hwirq) ((hwirq) + (priv)->irq_start)
> +#define GPIO_TO_HWIRQ(priv, gpio) ((gpio) - (priv)->irq_start)
> +
> +static void xgene_gpio_set_bit(struct gpio_chip *gc,
> +				void __iomem *reg, u32 gpio, int val)
>  {
>  	u32 data;
>  
> @@ -63,23 +82,180 @@ static void xgene_gpio_set_bit(struct gpio_chip *gc, void __iomem *reg, u32 gpio
>  	gc->write_reg(reg, data);
>  }
>  
> -static int apm_gpio_sb_to_irq(struct gpio_chip *gc, u32 gpio)
> +static int xgene_gpio_sb_irq_set_type(struct irq_data *d, unsigned int type)
> +{
> +	struct xgene_gpio_sb *priv = irq_data_get_irq_chip_data(d);
> +	int gpio = HWIRQ_TO_GPIO(priv, d->hwirq);
> +	int lvl_type = GPIO_INT_LEVEL_H;
> +
> +	switch (type & IRQ_TYPE_SENSE_MASK) {
> +	case IRQ_TYPE_EDGE_RISING:
> +	case IRQ_TYPE_LEVEL_HIGH:
> +		lvl_type = GPIO_INT_LEVEL_H;
> +		break;
> +	case IRQ_TYPE_EDGE_FALLING:
> +	case IRQ_TYPE_LEVEL_LOW:
> +		lvl_type = GPIO_INT_LEVEL_L;
> +		break;
> +	default:
> +		break;
> +	}
> +
> +	xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_SEL_LO,
> +			gpio * 2, 1);
> +	xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_INT_LVL,
> +			d->hwirq, lvl_type);
> +
> +	/* Propagate IRQ type setting to parent */
> +	if (type & IRQ_TYPE_EDGE_BOTH)
> +		return irq_chip_set_type_parent(d, IRQ_TYPE_EDGE_RISING);
> +	else
> +		return irq_chip_set_type_parent(d, IRQ_TYPE_LEVEL_HIGH);
> +}
> +
> +static void xgene_gpio_sb_irq_shutdown(struct irq_data *d)
> +{
> +	struct xgene_gpio_sb *priv = irq_data_get_irq_chip_data(d);
> +
> +	gpiochip_unlock_as_irq(&priv->gc, HWIRQ_TO_GPIO(priv, d->hwirq));
> +}
> +
> +static struct irq_chip xgene_gpio_sb_irq_chip = {
> +	.name           = "sbgpio",
> +	.irq_ack        = irq_chip_ack_parent,

There is no point calling irq_chip_ack_parent, as the GIC doesn't
implement an irq_ack method at all.

> +	.irq_eoi	= irq_chip_eoi_parent,
> +	.irq_mask       = irq_chip_mask_parent,
> +	.irq_unmask     = irq_chip_unmask_parent,
> +	.irq_set_type   = xgene_gpio_sb_irq_set_type,
> +	.irq_shutdown   = xgene_gpio_sb_irq_shutdown,
> +};
> +
> +static int xgene_gpio_sb_to_irq(struct gpio_chip *gc, u32 gpio)
>  {
>  	struct xgene_gpio_sb *priv = gpiochip_get_data(gc);
> +	struct irq_fwspec fwspec;
> +
> +	if ((gpio < priv->irq_start) ||
> +			(gpio > HWIRQ_TO_GPIO(priv, priv->nirq)))
> +		return -ENXIO;
> +
> +	if (gc->parent->of_node)
> +		fwspec.fwnode = of_node_to_fwnode(gc->parent->of_node);
> +	else
> +		fwspec.fwnode = gc->parent->fwnode;
> +	fwspec.param_count = 2;
> +	fwspec.param[0] = GPIO_TO_HWIRQ(priv, gpio);
> +	fwspec.param[1] = IRQ_TYPE_NONE;
> +	return irq_create_fwspec_mapping(&fwspec);
> +}
> +
> +static void xgene_gpio_sb_domain_activate(struct irq_domain *d,
> +		struct irq_data *irq_data)
> +{
> +	struct xgene_gpio_sb *priv = d->host_data;
> +	u32 gpio = HWIRQ_TO_GPIO(priv, irq_data->hwirq);
> +
> +	if (gpiochip_lock_as_irq(&priv->gc, gpio)) {
> +		dev_err(priv->gc.parent,
> +		"Unable to configure XGene GPIO standby pin %d as IRQ\n",
> +				gpio);
> +		return;
> +	}
> +
> +	xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_SEL_LO,
> +			gpio * 2, 1);
> +}
> +
> +static void xgene_gpio_sb_domain_deactivate(struct irq_domain *d,
> +		struct irq_data *irq_data)
> +{
> +	struct xgene_gpio_sb *priv = d->host_data;
> +	u32 gpio = HWIRQ_TO_GPIO(priv, irq_data->hwirq);
> +
> +	gpiochip_unlock_as_irq(&priv->gc, gpio);

Is it right to do the unlock both in irq_shutdown and domain_deactivate?
This seems a bit odd to me to have such an inbalance. My hunch is that
you should either implement irq_startup, do the locking there and drop
the unlock drop deactivate, or kill irq_shutdown.

Linus, what do you think?

> +	xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_SEL_LO,
> +			gpio * 2, 0);
> +}
>  
> -	if (priv->irq[gpio])
> -		return priv->irq[gpio];
> +static int xgene_gpio_sb_domain_translate(struct irq_domain *d,
> +		struct irq_fwspec *fwspec,
> +		unsigned long *hwirq,
> +		unsigned int *type)
> +{
> +	struct xgene_gpio_sb *priv = d->host_data;
> +
> +	if ((fwspec->param_count != 2) ||
> +		(fwspec->param[0] >= priv->nirq))
> +		return -EINVAL;
> +	*hwirq = fwspec->param[0];
> +	*type = fwspec->param[1];
> +	return 0;
> +}
> +
> +static int xgene_gpio_sb_domain_alloc(struct irq_domain *domain,
> +					unsigned int virq,
> +					unsigned int nr_irqs, void *data)
> +{
> +	struct irq_fwspec *fwspec = data;
> +	struct irq_fwspec parent_fwspec;
> +	struct xgene_gpio_sb *priv = domain->host_data;
> +	irq_hw_number_t hwirq;
> +	unsigned int i;
> +
> +	hwirq = fwspec->param[0];
> +	for (i = 0; i < nr_irqs; i++)
> +		irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
> +				&xgene_gpio_sb_irq_chip, priv);
> +
> +	if (is_of_node(domain->parent->fwnode)) {
> +		parent_fwspec.fwnode = domain->parent->fwnode;
> +		parent_fwspec.param_count = 3;
> +		parent_fwspec.param[0] = 0;/* SPI */
> +		/* Skip SGIs and PPIs*/
> +		parent_fwspec.param[1] = hwirq + priv->parent_irq_base - 32;
> +		parent_fwspec.param[2] = fwspec->param[1];
> +	} else if (is_fwnode_irqchip(domain->parent->fwnode)) {
> +		parent_fwspec.fwnode = domain->parent->fwnode;

nit: You can move this out of the if/else, and always assign the fwnode.

> +		parent_fwspec.param_count = 2;
> +		parent_fwspec.param[0] = hwirq + priv->parent_irq_base;
> +		parent_fwspec.param[1] = fwspec->param[1];
> +	} else
> +		return -EINVAL;
>  
> -	return -ENXIO;
> +	return irq_domain_alloc_irqs_parent(domain, virq, nr_irqs,
> +			&parent_fwspec);
>  }
>  
> +static void xgene_gpio_sb_domain_free(struct irq_domain *domain,
> +		unsigned int virq,
> +		unsigned int nr_irqs)
> +{
> +	struct irq_data *d;
> +	unsigned int i;
> +
> +	for (i = 0; i < nr_irqs; i++) {
> +		d = irq_domain_get_irq_data(domain, virq + i);
> +		irq_domain_reset_irq_data(d);
> +	}
> +}
> +
> +static const struct irq_domain_ops xgene_gpio_sb_domain_ops = {
> +	.translate      = xgene_gpio_sb_domain_translate,
> +	.alloc          = xgene_gpio_sb_domain_alloc,
> +	.free           = xgene_gpio_sb_domain_free,
> +	.activate	= xgene_gpio_sb_domain_activate,
> +	.deactivate	= xgene_gpio_sb_domain_deactivate,
> +};
> +
>  static int xgene_gpio_sb_probe(struct platform_device *pdev)
>  {
>  	struct xgene_gpio_sb *priv;
> -	u32 ret, i;
> -	u32 default_lines[] = {0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D};
> +	u32 ret;
>  	struct resource *res;
>  	void __iomem *regs;
> +	struct irq_domain *parent_domain = NULL;
> +	struct fwnode_handle *fwnode;
> +	u32 val32;
>  
>  	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>  	if (!priv)
> @@ -90,6 +266,18 @@ static int xgene_gpio_sb_probe(struct platform_device *pdev)
>  	if (IS_ERR(regs))
>  		return PTR_ERR(regs);
>  
> +	priv->regs = regs;
> +
> +	ret = platform_get_irq(pdev, 0);
> +	if (ret > 0) {
> +		priv->parent_irq_base = irq_get_irq_data(ret)->hwirq;
> +		parent_domain = irq_get_irq_data(ret)->domain;
> +	}
> +	if (!parent_domain) {
> +		dev_err(&pdev->dev, "unable to obtain parent domain\n");
> +		return -ENODEV;
> +	}
> +
>  	ret = bgpio_init(&priv->gc, &pdev->dev, 4,
>  			regs + MPA_GPIO_IN_ADDR,
>  			regs + MPA_GPIO_OUT_ADDR, NULL,
> @@ -97,30 +285,51 @@ static int xgene_gpio_sb_probe(struct platform_device *pdev)
>          if (ret)
>                  return ret;
>  
> -	priv->gc.to_irq = apm_gpio_sb_to_irq;
> -	priv->gc.ngpio = XGENE_MAX_GPIO_DS;
> +	priv->gc.to_irq = xgene_gpio_sb_to_irq;
>  
> -	priv->nirq = XGENE_MAX_GPIO_DS_IRQ;
> +	/* Retrieve start irq pin, use default if property not found */
> +	priv->irq_start = XGENE_DFLT_IRQ_START_PIN;
> +	if (!device_property_read_u32(&pdev->dev,
> +					XGENE_IRQ_START_PROPERTY, &val32))

Is that for ACPI as well?

> +		priv->irq_start = val32;
>  
> -	priv->irq = devm_kzalloc(&pdev->dev, sizeof(u32) * XGENE_MAX_GPIO_DS,
> -				   GFP_KERNEL);
> -	if (!priv->irq)
> -		return -ENOMEM;
> +	/* Retrieve number irqs, use default if property not found */
> +	priv->nirq = XGENE_DFLT_MAX_NIRQ;
> +	if (!device_property_read_u32(&pdev->dev, XGENE_NIRQ_PROPERTY, &val32))
> +		priv->nirq = val32;
>  
> -	for (i = 0; i < priv->nirq; i++) {
> -		priv->irq[default_lines[i]] = platform_get_irq(pdev, i);
> -		xgene_gpio_set_bit(&priv->gc, regs + MPA_GPIO_SEL_LO,
> -                                   default_lines[i] * 2, 1);
> -		xgene_gpio_set_bit(&priv->gc, regs + MPA_GPIO_INT_LVL, i, 1);
> -	}
> +	/* Retrieve number gpio, use default if property not found */
> +	priv->gc.ngpio = XGENE_DFLT_MAX_NGPIO;
> +	if (!device_property_read_u32(&pdev->dev, XGENE_NGPIO_PROPERTY, &val32))
> +		priv->gc.ngpio = val32;
> +
> +	dev_info(&pdev->dev, "Support %d gpios, %d irqs start from pin %d\n",
> +			priv->gc.ngpio, priv->nirq, priv->irq_start);
>  
>  	platform_set_drvdata(pdev, priv);
>  
> -	ret = gpiochip_add_data(&priv->gc, priv);
> -	if (ret)
> -		dev_err(&pdev->dev, "failed to register X-Gene GPIO Standby driver\n");
> +	if (pdev->dev.of_node)
> +		fwnode = of_node_to_fwnode(pdev->dev.of_node);
>  	else
> -		dev_info(&pdev->dev, "X-Gene GPIO Standby driver registered\n");
> +		fwnode = pdev->dev.fwnode;
> +
> +	priv->irq_domain = irq_domain_create_hierarchy(parent_domain,
> +					0, priv->nirq, fwnode,
> +					&xgene_gpio_sb_domain_ops, priv);
> +	if (!priv->irq_domain)
> +		return -ENODEV;
> +
> +	priv->gc.irqdomain = priv->irq_domain;
> +
> +	ret = gpiochip_add_data(&priv->gc, priv);
> +	if (ret) {
> +		dev_err(&pdev->dev,
> +			"failed to register X-Gene GPIO Standby driver\n");
> +		irq_domain_remove(priv->irq_domain);
> +		return ret;
> +	}
> +
> +	dev_info(&pdev->dev, "X-Gene GPIO Standby driver registered\n");
>  
>  	if (priv->nirq > 0) {
>  		/* Register interrupt handlers for gpio signaled acpi events */
> @@ -138,6 +347,8 @@ static int xgene_gpio_sb_remove(struct platform_device *pdev)
>  		acpi_gpiochip_free_interrupts(&priv->gc);
>  	}
>  
> +	irq_domain_remove(priv->irq_domain);
> +
>  	gpiochip_remove(&priv->gc);
>  	return 0;
>  }
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From arnd at arndb.de  Wed Feb 10 07:10:42 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 16:10:42 +0100
Subject: [PATCH] Input: colibri ts: include linux/of.h explicitly
Message-ID: <1455117056-2975628-1-git-send-email-arnd@arndb.de>

The newly added driver calls functions for accessing the DT but
does not include the header they are defined in, which fails
in configurations in which we don't get the header implicitly
through something else:

drivers/input/touchscreen/colibri-vf50-ts.c: In function 'vf50_ts_probe':
drivers/input/touchscreen/colibri-vf50-ts.c:302:10: error: implicit declaration of function 'of_property_read_u32' [-Werror=implicit-function-declaration]

This adds an explict #include, to ensure we can always build it.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 48ead50c1dd8 ("Input: Add touchscreen support for Colibri VF50")
---
 drivers/input/touchscreen/colibri-vf50-ts.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/touchscreen/colibri-vf50-ts.c b/drivers/input/touchscreen/colibri-vf50-ts.c
index 5d4903a402cc..69828d015d45 100644
--- a/drivers/input/touchscreen/colibri-vf50-ts.c
+++ b/drivers/input/touchscreen/colibri-vf50-ts.c
@@ -21,6 +21,7 @@
 #include <linux/interrupt.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <linux/of.h>
 #include <linux/pinctrl/consumer.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
-- 
2.7.0



From kernel at martin.sperl.org  Wed Feb 10 07:12:05 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Wed, 10 Feb 2016 16:12:05 +0100
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in console
Message-ID: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>

Hi!

I got a strange effect when using the auxiliar UART as the logging console:

The kernel is configured for drivers/tty/serial/8250/8250_bcm2835aux.c to
get linked into the main kernel (requires also 8250.c to be linked in).

As long as I boot using the main UART (PL011) in the kernel parameters:
  earlyprintk consoleblank=0 console=ttyAMA0 root=/dev/mmcblk0p2 rootwait

Everything works fine - early_printk works and normal logging works as well.
Both configured ttys (/dev/ttyAMA0 and /dev/ttyS0) in /etc/initttab
work fine.

Now when I switch the console to use the auxiliar UART
(which right now does not support early_printk) like this:
  earlyprintk consoleblank=0 console=ttyS0,115200n1 root=/dev/mmcblk0p2 rootwait

I get the situation where:
* u-boot starts and writes to the main UART
* Kernel boots using early_printk logging to the main UART until we get to:
  [    2.657090] bootconsole [earlycon0] disabled
* then we see the earlyprintk buffer dumped on the aux-uart
* then booting continues and logging happens on the aux-uart:
  [    2.657090] bootconsole [earlycon0] disabled
  [    2.662673] 20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
  [    2.663793] console [ttyS0] disabled
  [    2.663899] 20215040.serial: ttyS0 at MMIO 0x0 (irq = 53, base_baud = 31224999) is a 16550
  [    3.384166] console [ttyS0] enabled
* everything works fine and I get networking and everything up
  [....] Starting NTP server: ntpd. ok
  [....] Starting OpenBSD Secure Shell server: sshd. ok
  My IP address is 10.10.10.41 ::127.0.0.1

  Raspbian GNU/Linux 7 raspcm.intern.sperl.org ttyS0
* I can even log in via SSH and networking works.
  Note that I have the getty for ttyAMA0 disabled in inittab
* when I then enable the tty on the main UART like this:
  root at raspcm:~# /sbin/getty -a root -L ttyAMA0 115200 vt100
* I get the following:
  [   72.962845] uart-pl011 20201000.serial: no DMA platform data
* the system freezes?
* sometimes I still get the following on the auxiliar UART before the system ?crashes":
  (at least when starting the tty from inittab)
  [   73.072985] bcm2835-clk 20101000.cprman: plld: couldn't lock PLL
  [   73.079132] ------------[ cut here ]------------
  [   73.083848] WARNING: CPU: 0 PID: 2329 at drivers/clk/clk.c:680 clk_core_disable+0x34/0xf0()
  [   73.093067] ---[ end trace 416e78cea88f5fb5 ]---
  [   73.097848] ------------[ cut here ]------------
  [   73.102616] WARNING: CPU: 0 PID: 2329 at drivers/clk/clk.c:575 clk_core_unprepare+0x34/0x110()
  [   73.112219] ---[ end trace 416e78cea88f5fb6 ]---

A similar effect I get when using stty: 
  root at raspcm:~# stty -F /dev/ttyAMA0
  [  128.878127] uart-pl011 20201000.serial: no DMA platform data
  speed 9600 baud; line = 0;
  -brkint -imaxbel
Then the system freezes.

As if the plld does not lock - even if it (probably) is already locked.

Or the message actually comes from bcm2835_clock_wait_busy which also
produces this message - so maybe we should better identify the message.

Note that the same also applies if I remove earlyprintk with
the only difference being that I do not get the initial boot
messages on the main UART.
(at that time only: "Uncompressing Linux... done, booting the kernel.?
shows on the main uart after u-boot start..)

Unfortunately it is only possible to really test this on a
rpi-Compute module, as only there we can expose both uarts
on distinct GPIOs at the same time:
  GPIO 14: level=1 fsel=4 alt=0 func=TXD0
  GPIO 15: level=1 fsel=4 alt=0 func=RXD0
  GPIO 32: level=1 fsel=2 alt=5 func=TXD1
  GPIO 33: level=1 fsel=2 alt=5 func=RXD1

Here the commits I have used based on spi/for-next (based on 4.4.0)
with the patches (* prefix) for the driver for aux-uart
added separately as they are not in the tree I have used:
* a96f6c7 serial: bcm2835: add driver for bcm2835-aux-uart
* 464e876 clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.
* 1af1b28 clk: bcm2835: Add a driver for the auxiliary peripheral clock gates.
ece19b8 Merge remote-tracking branch 'spi/fix/loopback' into spi-linus
887e6a3 Merge tag 'spi-v4.5' into spi-linus
ebea7c0 spi: fix counting in spi-loopback-test code
cabeea9 Merge remote-tracking branches 'spi/topic/sun4i', 'spi/topic/topcliff-pc
4f95307 Merge remote-tracking branches 'spi/topic/overlay', 'spi/topic/pxa2xx',
41d5a70 Merge remote-tracking branches 'spi/topic/lm70llp', 'spi/topic/loopback'
635b9b2 Merge remote-tracking branches 'spi/topic/dw', 'spi/topic/dw-mid', 'spi/
3c27892 Merge remote-tracking branches 'spi/topic/bcm63xx', 'spi/topic/butterfly
9b17e80 Merge remote-tracking branch 'spi/topic/sunxi' into spi-next
174c211 Merge remote-tracking branch 'spi/topic/core' into spi-next
f30f072 Merge remote-tracking branch 'spi/fix/mtk' into spi-linus
afd2ff9 Linux 4.4

Maybe someone has gotten any idea?

In the meantime I will try to reproduce on a 4.5-rc3 based branch.

Thanks,
	Martin

 

From arnd at arndb.de  Wed Feb 10 07:14:21 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 16:14:21 +0100
Subject: [PATCH] cpufreq: select IRQ_WORK in Kconfig
Message-ID: <1455117265-3007562-1-git-send-email-arnd@arndb.de>

The cpufreq core code has started using the irq_work infrastructure, but that
can be disabled in Kconfig, causing a link failure:

drivers/cpufreq/cpufreq_governor.c: In function 'gov_queue_irq_work':
drivers/cpufreq/cpufreq_governor.c:251:3: error: implicit declaration of function 'irq_work_queue_on' [-Werror=implicit-function-declaration]

This adds an explicit 'select' to ensure it's always enabled.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 0144fa03ef46 ("cpufreq: governor: Replace timers with utilization update callbacks")
---
 drivers/cpufreq/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 3050e8d48887..ca05037dd565 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -3,6 +3,7 @@ menu "CPU Frequency scaling"
 config CPU_FREQ
 	bool "CPU Frequency scaling"
 	select SRCU
+	select IRQ_WORK
 	help
 	  CPU Frequency scaling allows you to change the clock speed of 
 	  CPUs on the fly. This is a nice method to save power, because 
-- 
2.7.0



From julien.grall at arm.com  Wed Feb 10 07:22:12 2016
From: julien.grall at arm.com (Julien Grall)
Date: Wed, 10 Feb 2016 15:22:12 +0000
Subject: [PATCH 3/5] irqchip/gic-v2: Parse and export virtual GIC
 information
In-Reply-To: <56BB4D2A.1030903@arm.com>
References: <1454950049-741-1-git-send-email-julien.grall@arm.com>
 <1454950049-741-4-git-send-email-julien.grall@arm.com>
 <20160209204914.GE5171@cbox> <56BB46DC.7080202@arm.com>
 <56BB4D2A.1030903@arm.com>
Message-ID: <56BB55A4.5020608@arm.com>

Hi Marc,

On 10/02/16 14:46, Marc Zyngier wrote:
> On 10/02/16 14:19, Julien Grall wrote:
>> On 09/02/16 20:49, Christoffer Dall wrote:
>>>> +static void __init gic_acpi_setup_kvm_info(void)
>>>> +{
>>>> +	gic_v2_kvm_info.type = GIC_V2;
>>>> +
>>>> +	gic_v2_kvm_info.maint_irq = acpi_register_gsi(NULL,
>>>> +						      acpi_data.maint_irq,
>>>> +						      acpi_data.maint_irq_mode,
>>>> +						      ACPI_ACTIVE_HIGH);
>>>> +	gic_v2_kvm_info.vctrl_base = acpi_data.vctrl_base;
>>>> +	if (gic_v2_kvm_info.vctrl_base)
>>>> +		gic_v2_kvm_info.vctrl_size = SZ_8K;
>>>> +
>>>> +	gic_v2_kvm_info.vcpu_base = acpi_data.vcpu_base;
>>>> +	if (gic_v2_kvm_info.vcpu_base)
>>>> +		gic_v2_kvm_info.vcpu_size = SZ_8K;
>>>
>>> why are the sizes hard-coded to 8K in this case?
>>
>> The MADT only provides the base addresses and not the size. The default
>> value has been chosen based on the GICv2 spec (ARM IHI 0048B.b)
>> 	* GICV: See 5.5
>> 	* GICH: I can't find again the section about it. But the example
>> bindings in
>> Documents/devicetree/bindings/interrupt-controller/arm,gic.txt uses 8K.
>>
>> I will add a comment in the code explaining where the 8K come from.
>
> The GICH size can be found in the GIC400 TRM:
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0471b/CHDBJDCB.html
>
> The first 4kB are banked per CPU, while the next 4kB are exposing all
> CPUs, each in a 512 bytes window. We don't give a damn about the second
> page, but hey, it is there...
>
> Of course, this is GIC400, not the architecture spec. So maybe
> considering a 4kB size would be better, just in case someone is
> braindead enough to produce another GICv2 implementation without the
> aliases...

Ok, I will change the GICH to 4KB in the next version.

Cheers,

-- 
Julien Grall


From arnd at arndb.de  Wed Feb 10 07:21:19 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 16:21:19 +0100
Subject: [PATCH] tty/serial: digicolor: Fix bad usage of IS_ERR_VALUE
In-Reply-To: <56BAA27A.9050605@roeck-us.net>
References: <1455030539-10798-1-git-send-email-linux@roeck-us.net>
 <4571887.rTPndCnv20@wuerfel> <56BAA27A.9050605@roeck-us.net>
Message-ID: <2606061.l722KO95iI@wuerfel>

On Tuesday 09 February 2016 18:37:46 Guenter Roeck wrote:
> On 02/09/2016 07:26 AM, Arnd Bergmann wrote:
> > On Tuesday 09 February 2016 07:08:59 Guenter Roeck wrote:
> >> IS_ERR_VALUE() assumes that its parameter is an unsigned long.
> >> It can not be used to check if an unsigned int reflects an error.
> >> Doing so can result in the following build warning.
> >>
> >> drivers/tty/serial/digicolor-usart.c: In function ?digicolor_uart_probe?:
> >> include/linux/err.h:21:38: warning:
> >>          comparison is always false due to limited range of data type
> >> drivers/tty/serial/digicolor-usart.c:485:6: note:
> >>          in expansion of macro ?IS_ERR_VALUE?
> >>
> >> If that warning is seen, an error return from platform_get_irq() is missed.
> >>
> >>
> >
> > The patch looks correct to me, but what compiler version and which kernel
> > tree is it that triggered the warning?
> >
> > Andrzej Hajda just modified the definition of IS_ERR_VALUE(), and the
> > changes are still under discussion, but I don't see that warning with
> > any of the versions.
> >
> I see it with gcc 5.1 and 5.2 (and W=1). I did not see / notice Andrzej's patch.
> 
> I agree that fixing the problem in IS_ERR_VALUE() is preferrable.
> 
> 

Ah, W=1 explains it. We are still debating about the proper solution. Al Viro
pointed out that most users of IS_ERR_VALUE() shouldn't be using it at all,
so your patch is probably best here after all.

	Arnd


From arnd at arndb.de  Wed Feb 10 07:24:38 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 16:24:38 +0100
Subject: EMXX platform support
In-Reply-To: <20160209201743.GA5628@reno.home>
References: <20160209201743.GA5628@reno.home>
Message-ID: <56882101.BaoQy5A3Ep@wuerfel>

On Tuesday 09 February 2016 21:17:44 Martin Langer wrote:
> Hello,
> 
> are there any plans in supporting emxx platform?
> 
> The Sony PCM D-100 is based on this platform and they released a lot of their linux code:
> http://oss.sony.net/Products/Linux/Audio/PCM-D100.html
> 
> ... including basic code for the kernel 2.6.35, see:
> http://oss.sony.net/Products/Linux/Audio/Download/PCM-D100/linux-kernel-2.6.35.tgz
> 
> I'm wondering that it is not yet part of the kernel. Probably I am the first person who looked into their package.
> 

You are welcome to start contributing a port, but please be aware that
platform support has been almost completely changed since 2.6.35, so
if you want to add something here, that likely involves a rewrite of
anything under arch/arm.

	Arnd


From rafael at kernel.org  Wed Feb 10 07:28:33 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Wed, 10 Feb 2016 16:28:33 +0100
Subject: [PATCH] cpufreq: select IRQ_WORK in Kconfig
In-Reply-To: <1455117265-3007562-1-git-send-email-arnd@arndb.de>
References: <1455117265-3007562-1-git-send-email-arnd@arndb.de>
Message-ID: <CAJZ5v0jqyd41Vzm61BEMeSHs=sAGYghM77nipBMVhQiyRfeqGw@mail.gmail.com>

On Wed, Feb 10, 2016 at 4:14 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> The cpufreq core code has started using the irq_work infrastructure, but that
> can be disabled in Kconfig, causing a link failure:
>
> drivers/cpufreq/cpufreq_governor.c: In function 'gov_queue_irq_work':
> drivers/cpufreq/cpufreq_governor.c:251:3: error: implicit declaration of function 'irq_work_queue_on' [-Werror=implicit-function-declaration]
>
> This adds an explicit 'select' to ensure it's always enabled.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 0144fa03ef46 ("cpufreq: governor: Replace timers with utilization update callbacks")
> ---
>  drivers/cpufreq/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index 3050e8d48887..ca05037dd565 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -3,6 +3,7 @@ menu "CPU Frequency scaling"
>  config CPU_FREQ
>         bool "CPU Frequency scaling"
>         select SRCU
> +       select IRQ_WORK
>         help
>           CPU Frequency scaling allows you to change the clock speed of
>           CPUs on the fly. This is a nice method to save power, because
> --

Good catch, thanks!

I'll update the patch to do that.

Thanks,
Rafael


From marc.zyngier at arm.com  Wed Feb 10 07:32:52 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 15:32:52 +0000
Subject: [PATCH v2 08/28] ARM: KVM: Add TLB invalidation code
In-Reply-To: <20160209184228.GL5171@cbox>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-9-git-send-email-marc.zyngier@arm.com>
 <20160209184228.GL5171@cbox>
Message-ID: <56BB5824.2010502@arm.com>

On 09/02/16 18:42, Christoffer Dall wrote:
> On Thu, Feb 04, 2016 at 11:00:25AM +0000, Marc Zyngier wrote:
>> Convert the TLB invalidation code to C, hooking it into the
>> build system whilst we're at it.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm/kvm/Makefile     |  1 +
>>  arch/arm/kvm/hyp/Makefile |  5 ++++
>>  arch/arm/kvm/hyp/hyp.h    |  5 ++++
>>  arch/arm/kvm/hyp/tlb.c    | 71 +++++++++++++++++++++++++++++++++++++++++++++++
>>  4 files changed, 82 insertions(+)
>>  create mode 100644 arch/arm/kvm/hyp/Makefile
>>  create mode 100644 arch/arm/kvm/hyp/tlb.c
>>
>> diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
>> index c5eef02c..eb1bf43 100644
>> --- a/arch/arm/kvm/Makefile
>> +++ b/arch/arm/kvm/Makefile
>> @@ -17,6 +17,7 @@ AFLAGS_interrupts.o := -Wa,-march=armv7-a$(plus_virt)
>>  KVM := ../../../virt/kvm
>>  kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o $(KVM)/vfio.o
>>  
>> +obj-$(CONFIG_KVM_ARM_HOST) += hyp/
>>  obj-y += kvm-arm.o init.o interrupts.o
>>  obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o
>>  obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o
>> diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
>> new file mode 100644
>> index 0000000..36c760d
>> --- /dev/null
>> +++ b/arch/arm/kvm/hyp/Makefile
>> @@ -0,0 +1,5 @@
>> +#
>> +# Makefile for Kernel-based Virtual Machine module, HYP part
>> +#
>> +
>> +obj-$(CONFIG_KVM_ARM_HOST) += tlb.o
>> diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
>> index 727089f..5808bbd 100644
>> --- a/arch/arm/kvm/hyp/hyp.h
>> +++ b/arch/arm/kvm/hyp/hyp.h
>> @@ -42,4 +42,9 @@
>>  })
>>  #define read_sysreg(...)		__read_sysreg(__VA_ARGS__)
>>  
>> +#define VTTBR		__ACCESS_CP15_64(6, c2)
>> +#define ICIALLUIS	__ACCESS_CP15(c7, 0, c1, 0)
>> +#define TLBIALLIS	__ACCESS_CP15(c8, 0, c3, 0)
>> +#define TLBIALLNSNHIS	__ACCESS_CP15(c8, 4, c3, 4)
>> +
>>  #endif /* __ARM_KVM_HYP_H__ */
>> diff --git a/arch/arm/kvm/hyp/tlb.c b/arch/arm/kvm/hyp/tlb.c
>> new file mode 100644
>> index 0000000..993fe89
>> --- /dev/null
>> +++ b/arch/arm/kvm/hyp/tlb.c
>> @@ -0,0 +1,71 @@
>> +/*
>> + * Original code:
>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>> + * Author: Christoffer Dall <c.dall at virtualopensystems.com>
>> + *
>> + * Mostly rewritten in C by Marc Zyngier <marc.zyngier at arm.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 "hyp.h"
>> +
>> +/**
>> + * Flush per-VMID TLBs
>> + *
>> + * __kvm_tlb_flush_vmid(struct kvm *kvm);
>> + *
>> + * We rely on the hardware to broadcast the TLB invalidation to all CPUs
>> + * inside the inner-shareable domain (which is the case for all v7
>> + * implementations).  If we come across a non-IS SMP implementation, we'll
>> + * have to use an IPI based mechanism. Until then, we stick to the simple
>> + * hardware assisted version.
>> + *
>> + * As v7 does not support flushing per IPA, just nuke the whole TLB
>> + * instead, ignoring the ipa value.
>> + */
>> +static void __hyp_text __tlb_flush_vmid(struct kvm *kvm)
>> +{
>> +	dsb(ishst);
>> +
>> +	/* Switch to requested VMID */
>> +	kvm = kern_hyp_va(kvm);
>> +	write_sysreg(kvm->arch.vttbr, VTTBR);
>> +	isb();
>> +
>> +	write_sysreg(0, TLBIALLIS);
>> +	dsb(ish);
>> +	isb();
>> +
>> +	write_sysreg(0, VTTBR);
>> +}
>> +
>> +__alias(__tlb_flush_vmid) void __weak __kvm_tlb_flush_vmid(struct kvm *kvm);
>> +
>> +static void __hyp_text __tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
>> +{
>> +	__tlb_flush_vmid(kvm);
>> +}
>> +
>> +__alias(__tlb_flush_vmid_ipa) void __weak __kvm_tlb_flush_vmid_ipa(struct kvm *kvm,
>> +							    phys_addr_t ipa);
>> +
>> +static void __hyp_text __tlb_flush_vm_context(void)
>> +{
>> +	dsb(ishst);
> 
> do we need this initial dsb?

I'm a copy-paste muppet. I'll drop that.

>> +	write_sysreg(0, TLBIALLNSNHIS);
>> +	write_sysreg(0, ICIALLUIS);
>> +	dsb(ish);
> 
> we used to have an isb here, but we got rid of this because it's always
> followed by eret?

Indeed. We were super extra cautious in the old code, and eret does the
right thing.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From marc.zyngier at arm.com  Wed Feb 10 07:36:40 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 15:36:40 +0000
Subject: [PATCH v2 10/28] ARM: KVM: Add timer save/restore
In-Reply-To: <20160209184242.GN5171@cbox>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-11-git-send-email-marc.zyngier@arm.com>
 <20160209184242.GN5171@cbox>
Message-ID: <56BB5908.2030904@arm.com>

On 09/02/16 18:42, Christoffer Dall wrote:
> On Thu, Feb 04, 2016 at 11:00:27AM +0000, Marc Zyngier wrote:
>> This patch shouldn't exist, as we should be able to reuse the
>> arm64 version for free. I'll get there eventually, but in the
>> meantime I need a timer ticking.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm/kvm/hyp/Makefile   |  1 +
>>  arch/arm/kvm/hyp/hyp.h      |  8 +++++
>>  arch/arm/kvm/hyp/timer-sr.c | 71 +++++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 80 insertions(+)
>>  create mode 100644 arch/arm/kvm/hyp/timer-sr.c
>>
>> diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
>> index 9f96fcb..9241ae8 100644
>> --- a/arch/arm/kvm/hyp/Makefile
>> +++ b/arch/arm/kvm/hyp/Makefile
>> @@ -4,3 +4,4 @@
>>  
>>  obj-$(CONFIG_KVM_ARM_HOST) += tlb.o
>>  obj-$(CONFIG_KVM_ARM_HOST) += cp15-sr.o
>> +obj-$(CONFIG_KVM_ARM_HOST) += timer-sr.o
>> diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
>> index ab2cb82..4924418 100644
>> --- a/arch/arm/kvm/hyp/hyp.h
>> +++ b/arch/arm/kvm/hyp/hyp.h
>> @@ -46,6 +46,9 @@
>>  #define TTBR1		__ACCESS_CP15_64(1, c2)
>>  #define VTTBR		__ACCESS_CP15_64(6, c2)
>>  #define PAR		__ACCESS_CP15_64(0, c7)
>> +#define CNTV_CVAL	__ACCESS_CP15_64(3, c14)
>> +#define CNTVOFF		__ACCESS_CP15_64(4, c14)
>> +
>>  #define CSSELR		__ACCESS_CP15(c0, 2, c0, 0)
>>  #define VMPIDR		__ACCESS_CP15(c0, 4, c0, 5)
>>  #define SCTLR		__ACCESS_CP15(c1, 0, c0, 0)
>> @@ -71,6 +74,11 @@
>>  #define TID_URO		__ACCESS_CP15(c13, 0, c0, 3)
>>  #define TID_PRIV	__ACCESS_CP15(c13, 0, c0, 4)
>>  #define CNTKCTL		__ACCESS_CP15(c14, 0, c1, 0)
>> +#define CNTV_CTL	__ACCESS_CP15(c14, 0, c3, 1)
>> +#define CNTHCTL		__ACCESS_CP15(c14, 4, c1, 0)
>> +
>> +void __timer_save_state(struct kvm_vcpu *vcpu);
>> +void __timer_restore_state(struct kvm_vcpu *vcpu);
>>  
>>  void __sysreg_save_state(struct kvm_cpu_context *ctxt);
>>  void __sysreg_restore_state(struct kvm_cpu_context *ctxt);
>> diff --git a/arch/arm/kvm/hyp/timer-sr.c b/arch/arm/kvm/hyp/timer-sr.c
>> new file mode 100644
>> index 0000000..d7535fd
>> --- /dev/null
>> +++ b/arch/arm/kvm/hyp/timer-sr.c
>> @@ -0,0 +1,71 @@
>> +/*
>> + * Copyright (C) 2012-2015 - ARM Ltd
>> + * Author: Marc Zyngier <marc.zyngier at arm.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 <clocksource/arm_arch_timer.h>
>> +#include <linux/compiler.h>
>> +#include <linux/kvm_host.h>
>> +
>> +#include <asm/kvm_mmu.h>
>> +
>> +#include "hyp.h"
>> +
>> +/* vcpu is already in the HYP VA space */
>> +void __hyp_text __timer_save_state(struct kvm_vcpu *vcpu)
>> +{
>> +	struct kvm *kvm = kern_hyp_va(vcpu->kvm);
>> +	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> +	u64 val;
>> +
>> +	if (kvm->arch.timer.enabled) {
>> +		timer->cntv_ctl = read_sysreg(CNTV_CTL);
>> +		timer->cntv_cval = read_sysreg(CNTV_CVAL);
>> +	}
>> +
>> +	/* Disable the virtual timer */
>> +	write_sysreg(0, CNTV_CTL);
>> +
>> +	/* Allow physical timer/counter access for the host */
>> +	val = read_sysreg(CNTHCTL);
>> +	val |= CNTHCTL_EL1PCTEN | CNTHCTL_EL1PCEN;
>> +	write_sysreg(val, CNTHCTL);
>> +
>> +	/* Clear cntvoff for the host */
>> +	write_sysreg(0, CNTVOFF);
> 
> in the asm version we only did this if the timer was enabled, probably
> the theory being that only in that case did we mody the offset.  But it
> should be safe to just clear the cntvoff in any case, right?

It is indeed perfectly safe. I've copied the arm64 code into the 32bit
tree, so we get this cntvoff reset (arm64 requires it since it the
virtual counter is used in the vdso), but this doesn't hurt on 32bit either.

> 
>> +}
>> +
>> +void __hyp_text __timer_restore_state(struct kvm_vcpu *vcpu)
>> +{
>> +	struct kvm *kvm = kern_hyp_va(vcpu->kvm);
>> +	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
>> +	u64 val;
>> +
>> +	/*
>> +	 * Disallow physical timer access for the guest
>> +	 * Physical counter access is allowed
>> +	 */
>> +	val = read_sysreg(CNTHCTL);
>> +	val &= ~CNTHCTL_EL1PCEN;
>> +	val |= CNTHCTL_EL1PCTEN;
>> +	write_sysreg(val, CNTHCTL);
>> +
>> +	if (kvm->arch.timer.enabled) {
>> +		write_sysreg(kvm->arch.timer.cntvoff, CNTVOFF);
>> +		write_sysreg(timer->cntv_cval, CNTV_CVAL);
>> +		isb();
>> +		write_sysreg(timer->cntv_ctl, CNTV_CTL);
>> +	}
>> +}
>> -- 
>> 2.1.4
>>
> 
> Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From jason at lakedaemon.net  Wed Feb 10 07:38:29 2016
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 10 Feb 2016 15:38:29 +0000
Subject: [PATCH v2 0/6] irqchip: irq-armada-370-xp: generic MSI
 infrastructure and assorted fixes
In-Reply-To: <56BB4451.3070707@arm.com>
References: <1453899395-3532-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160210150046.118fc991@free-electrons.com>
 <56BB4451.3070707@arm.com>
Message-ID: <20160210153829.GA5183@io.lakedaemon.net>

On Wed, Feb 10, 2016 at 02:08:17PM +0000, Marc Zyngier wrote:
> On 10/02/16 14:00, Thomas Petazzoni wrote:
> > Hello,
> > 
> > On Wed, 27 Jan 2016 13:56:29 +0100, Thomas Petazzoni wrote:
> > 
> >> Thomas Petazzoni (6):
> >>   irqchip: irq-armada-370-xp: add Kconfig option for the driver
> >>   irqchip: irq-armada-370-xp: use the generic MSI infrastructure
> >>   irqchip: irq-armada-370-xp: use PCI_MSI_DOORBELL_START where
> >>     appropriate
> >>   irqchip: irq-armada-370-xp: use shorter names for irq_chip
> >>   irqchip: irq-armada-370-xp: allow allocation of multiple MSIs
> >>   ARM: mvebu: use the ARMADA_370_XP_IRQ option
> > 
> > Jason, Thomas, any chance to get this applied soonish?
> > 
> > The core patch of the series, which migrates the irq-armada-370-xp
> > driver to use the generic MSI infrastructure has been Reviewed-by: Marc
> > Zyngier, and the other patches in the series have Acked-by/Reviewed-by
> > from Gregory Clement.
> > 
> > Of course, if there's anything left to be changed, I'd be happy to
> > respin a new version of this series.
> > 
> 
> Noticing the distribution list, it would be good to repost these patches
> with acks and co to LKML...

agreed, and I'll pick it up within the next day or so.  Still getting my
home network setup... too much wifi. :(

thx,

Jason.


From lee.jones at linaro.org  Wed Feb 10 07:38:46 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 15:38:46 +0000
Subject: [PATCH v2] mfd: Provide MACRO to declare commonly defined MFD cell
 attributes
In-Reply-To: <1455028027-1527-1-git-send-email-lee.jones@linaro.org>
References: <1455028027-1527-1-git-send-email-lee.jones@linaro.org>
Message-ID: <20160210153846.GB26950@x1>

mfd: Provide MACRO to declare commonly defined MFD cell attributes
    
Cc: Laxman Dewangan <ldewangan at nvidia.com>
Signed-off-by: Lee Jones <lee.jones at linaro.org>

---
 include/linux/mfd/core.h | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
index bc6f7e0..1a5a87f 100644
--- a/include/linux/mfd/core.h
+++ b/include/linux/mfd/core.h
@@ -16,6 +16,32 @@
 
 #include <linux/platform_device.h>
 
+#define MFD_ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+
+#define MFD_CELL_ALL(_name, _res, _pdata, _id, _compat, _match)		\
+	{								\
+		.name = (_name),					\
+		.resources = (_res),					\
+		.num_resources = MFD_ARRAY_SIZE((_res)),		\
+		.platform_data = (_pdata),				\
+		.pdata_size = MFD_ARRAY_SIZE((_pdata)), 		\
+		.of_compatible = (_compat),				\
+		.acpi_match = (_match),					\
+		.id = _id,						\
+	}
+
+#define OF_MFD_CELL(_name, _res, _pdata, _id, _compat)			\
+		MFD_CELL_ALL(_name, _res, _pdata, _id, _compat, NULL)	\
+
+#define ACPI_MFD_CELL(_name, _res, _pdata, _id, _match)			\
+		MFD_CELL_ALL(_name, _res, _pdata, _id, NULL, _match)	\
+
+#define MFD_CELL_BASIC(_name, _res, _pdata, _id)			\
+		MFD_CELL_ALL(_name, _res, _pdata, _id, NULL, NULL)	\
+
+#define MFD_CELL_NAME(_name)						\
+		MFD_CELL_ALL(_name, NULL, NULL, 0, NULL, NULL)		\
+
 struct irq_domain;
 struct property_set;


From lee.jones at linaro.org  Wed Feb 10 07:39:38 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 15:39:38 +0000
Subject: [PATCH v2] mfd: ab8500: Provide a small example using new MFD cell
 MACROs
In-Reply-To: <1455028027-1527-1-git-send-email-lee.jones@linaro.org>
References: <1455028027-1527-1-git-send-email-lee.jones@linaro.org>
Message-ID: <20160210153938.GC26950@x1>

mfd: ab8500: Provide a small example using new MFD cell MACROs
    
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mfd/ab8500-core.c | 106 +++++++++++++++-------------------------------
 1 file changed, 34 insertions(+), 72 deletions(-)

diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index f3d6891..c03a86e 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -634,79 +634,41 @@ static const struct mfd_cell ab8500_bm_devs[] = {
 
 static const struct mfd_cell ab8500_devs[] = {
 #ifdef CONFIG_DEBUG_FS
-	{
-		.name = "ab8500-debug",
-		.of_compatible = "stericsson,ab8500-debug",
-	},
+	OF_MFD_CELL("ab8500-debug",
+		    NULL, NULL, 0, "stericsson,ab8500-debug"),
 #endif
-	{
-		.name = "ab8500-sysctrl",
-		.of_compatible = "stericsson,ab8500-sysctrl",
-	},
-	{
-		.name = "ab8500-ext-regulator",
-		.of_compatible = "stericsson,ab8500-ext-regulator",
-	},
-	{
-		.name = "ab8500-regulator",
-		.of_compatible = "stericsson,ab8500-regulator",
-	},
-	{
-		.name = "abx500-clk",
-		.of_compatible = "stericsson,abx500-clk",
-	},
-	{
-		.name = "ab8500-gpadc",
-		.of_compatible = "stericsson,ab8500-gpadc",
-	},
-	{
-		.name = "ab8500-rtc",
-		.of_compatible = "stericsson,ab8500-rtc",
-	},
-	{
-		.name = "ab8500-acc-det",
-		.of_compatible = "stericsson,ab8500-acc-det",
-	},
-	{
-
-		.name = "ab8500-poweron-key",
-		.of_compatible = "stericsson,ab8500-poweron-key",
-	},
-	{
-		.name = "ab8500-pwm",
-		.of_compatible = "stericsson,ab8500-pwm",
-		.id = 1,
-	},
-	{
-		.name = "ab8500-pwm",
-		.of_compatible = "stericsson,ab8500-pwm",
-		.id = 2,
-	},
-	{
-		.name = "ab8500-pwm",
-		.of_compatible = "stericsson,ab8500-pwm",
-		.id = 3,
-	},
-	{
-		.name = "ab8500-denc",
-		.of_compatible = "stericsson,ab8500-denc",
-	},
-	{
-		.name = "pinctrl-ab8500",
-		.of_compatible = "stericsson,ab8500-gpio",
-	},
-	{
-		.name = "abx500-temp",
-		.of_compatible = "stericsson,abx500-temp",
-	},
-	{
-		.name = "ab8500-usb",
-		.of_compatible = "stericsson,ab8500-usb",
-	},
-	{
-		.name = "ab8500-codec",
-		.of_compatible = "stericsson,ab8500-codec",
-	},
+	OF_MFD_CELL("ab8500-sysctrl",
+		    NULL, NULL, 0, "stericsson,ab8500-sysctrl"),
+	OF_MFD_CELL("ab8500-ext-regulator",
+		    NULL, NULL, 0, "stericsson,ab8500-ext-regulator"),
+	OF_MFD_CELL("ab8500-regulator",
+		    NULL, NULL, 0, "stericsson,ab8500-regulator"),
+	OF_MFD_CELL("abx500-clk",
+		    NULL, NULL, 0, "stericsson,abx500-clk"),
+	OF_MFD_CELL("ab8500-gpadc",
+		    NULL, NULL, 0, "stericsson,ab8500-gpadc"),
+	OF_MFD_CELL("ab8500-rtc",
+		    NULL, NULL, 0, "stericsson,ab8500-rtc"),
+	OF_MFD_CELL("ab8500-acc-det",
+		    NULL, NULL, 0, "stericsson,ab8500-acc-det"),
+	OF_MFD_CELL("ab8500-poweron-key",
+		    NULL, NULL, 0, "stericsson,ab8500-poweron-key"),
+	OF_MFD_CELL("ab8500-pwm",
+		    NULL, NULL, 1, "stericsson,ab8500-pwm"),
+	OF_MFD_CELL("ab8500-pwm",
+		    NULL, NULL, 2, "stericsson,ab8500-pwm"),
+	OF_MFD_CELL("ab8500-pwm",
+		    NULL, NULL, 3, "stericsson,ab8500-pwm"),
+	OF_MFD_CELL("ab8500-denc",
+		    NULL, NULL, 0, "stericsson,ab8500-denc"),
+	OF_MFD_CELL("pinctrl-ab8500",
+		    NULL, NULL, 0, "stericsson,ab8500-gpio"),
+	OF_MFD_CELL("abx500-temp",
+		    NULL, NULL, 0, "stericsson,abx500-temp"),
+	OF_MFD_CELL("ab8500-usb",
+		    NULL, NULL, 0, "stericsson,ab8500-usb"),
+	OF_MFD_CELL("ab8500-codec",
+		    NULL, NULL, 0, "stericsson,ab8500-codec"),
 };
 
 static const struct mfd_cell ab9540_devs[] = {


From nicolas.pitre at linaro.org  Wed Feb 10 07:40:49 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 10 Feb 2016 10:40:49 -0500 (EST)
Subject: [PATCH v2 1/2] ARM: shmobile: Move shmobile_smp_{mpidr, fn, arg}[]
 from .text to .data
In-Reply-To: <1455112615-6970-2-git-send-email-geert+renesas@glider.be>
References: <1455112615-6970-1-git-send-email-geert+renesas@glider.be>
 <1455112615-6970-2-git-send-email-geert+renesas@glider.be>
Message-ID: <alpine.LFD.2.20.1602101037430.17825@knanqh.ubzr>

On Wed, 10 Feb 2016, Geert Uytterhoeven wrote:

> If CONFIG_DEBUG_RODATA=y, the kernel crashes during system suspend:
> 
>     Freezing user space processes ... (elapsed 0.004 seconds) done.
>     Freezing remaining freezable tasks ... (elapsed 0.002 seconds)
>     done.
>     PM: suspend of devices complete after 111.948 msecs
>     PM: late suspend of devices complete after 1.086 msecs
>     PM: noirq suspend of devices complete after 11.576 msecs
>     Disabling non-boot CPUs ...
>     Kernel panic - not syncing: Attempted to kill the idle task!
>     1014ec ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
>     CPU0: stopping
> 
> This happens because the .text section is marked read-only, while the
> arrays shmobile_smp_mpidr[], shmobile_smp_fn[], and shmobile_smp_arg[]
> are being written to.
> 
> Fix this by moving these arrays from the .text to the .data section.
> This requires accessing them through PC-relative offsets.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> Reviewed-by: Kees Cook <keescook at chromium.org>

You could replace .data with .bss to avoid allocating zero-initialized 
space in the kernel binary.  Then you may add

Reviewed-by: Nicolas Pitre <nico at linaro.org>


> ---
> v2:
>   - Add Reviewed-by,
>   - Store offsets instead of pointers, as suggested by Nicolas Pitre
>     <nicolas.pitre at linaro.org>.
> ---
>  arch/arm/mach-shmobile/headsmp.S | 20 ++++++++++++++------
>  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
> index 330c1fc63197df89..4cf7f0b016b0b0fe 100644
> --- a/arch/arm/mach-shmobile/headsmp.S
> +++ b/arch/arm/mach-shmobile/headsmp.S
> @@ -50,9 +50,11 @@ ENTRY(shmobile_smp_boot)
>  	mrc	p15, 0, r1, c0, c0, 5		@ r1 = MPIDR
>  	and	r0, r1, r0			@ r0 = cpu_logical_map() value
>  	mov	r1, #0				@ r1 = CPU index
> -	adr	r5, 1f				@ array of per-cpu mpidr values
> -	adr	r6, 2f				@ array of per-cpu functions
> -	adr	r7, 3f				@ array of per-cpu arguments
> +	adr	r2, 1f
> +	ldmia	r2, {r5, r6, r7}
> +	add	r5, r5, r2			@ array of per-cpu mpidr values
> +	add	r6, r6, r2			@ array of per-cpu functions
> +	add	r7, r7, r2			@ array of per-cpu arguments
>  
>  shmobile_smp_boot_find_mpidr:
>  	ldr	r8, [r5, r1, lsl #2]
> @@ -80,12 +82,18 @@ ENTRY(shmobile_smp_sleep)
>  	b	shmobile_smp_boot
>  ENDPROC(shmobile_smp_sleep)
>  
> +	.align	2
> +1:	.long	shmobile_smp_mpidr - .
> +	.long	shmobile_smp_fn - 1b
> +	.long	shmobile_smp_arg - 1b
> +
> +	.data
>  	.globl	shmobile_smp_mpidr
>  shmobile_smp_mpidr:
> -1:	.space	NR_CPUS * 4
> +	.space	NR_CPUS * 4
>  	.globl	shmobile_smp_fn
>  shmobile_smp_fn:
> -2:	.space	NR_CPUS * 4
> +	.space	NR_CPUS * 4
>  	.globl	shmobile_smp_arg
>  shmobile_smp_arg:
> -3:	.space	NR_CPUS * 4
> +	.space	NR_CPUS * 4
> -- 
> 1.9.1
> 
> 


From linus.walleij at linaro.org  Wed Feb 10 07:42:04 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Feb 2016 16:42:04 +0100
Subject: [PATCH v5] pinctrl: rockchip: add support for the rk3399
In-Reply-To: <1454295501-32165-1-git-send-email-david.wu@rock-chips.com>
References: <1454295501-32165-1-git-send-email-david.wu@rock-chips.com>
Message-ID: <CACRpkdYsYse-EYQ2YJFbRRMVrfp-0k-CctvCZtGtzNgJNyo1Bg@mail.gmail.com>

On Mon, Feb 1, 2016 at 3:58 AM, David Wu <david.wu at rock-chips.com> wrote:

> The pinctrl of rk3399 is much different from other's,
> especially the 3bits of drive strength.
>
> Signed-off-by: David Wu <david.wu at rock-chips.com>
> Reviewed-by: Heiko Stuebner <heiko at sntech.de>
> ---
> Changes in v5:
> - merge the binding-doc-addition in one patch (Linus Heiko)
> - fix the comment of bit15 drive setting (Heiko)

Patch applied.

Yours,
Linus Walleij


From nicolas.pitre at linaro.org  Wed Feb 10 07:47:55 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 10 Feb 2016 10:47:55 -0500 (EST)
Subject: [PATCH v2 2/2] ARM: shmobile: Remove shmobile_boot_arg
In-Reply-To: <1455112615-6970-3-git-send-email-geert+renesas@glider.be>
References: <1455112615-6970-1-git-send-email-geert+renesas@glider.be>
 <1455112615-6970-3-git-send-email-geert+renesas@glider.be>
Message-ID: <alpine.LFD.2.20.1602101047280.17825@knanqh.ubzr>

On Wed, 10 Feb 2016, Geert Uytterhoeven wrote:

> CPU boot configuration writes to shmobile_boot_arg, which is located in
> the .text section, and thus should not be written to.
> 
> As of commit 1d33a354bbb618ba ("ARM: shmobile: Per-CPU SMP boot / sleep
> code for SCU SoCs"), and ignoring accidental remainings,
> shmobile_boot_arg is always set to MPIDR_HWID_BITMASK by C code.
> Hence we can just hardcode this in the assembler code, and remove the
> variable, and thus also remove the need to write to this variable.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>

Acked-by: Nicolas Pitre <nico at linaro.org>



> ---
> v2:
>   - New.
> ---
>  arch/arm/mach-shmobile/common.h       | 1 -
>  arch/arm/mach-shmobile/headsmp.S      | 8 ++------
>  arch/arm/mach-shmobile/platsmp-apmu.c | 1 -
>  arch/arm/mach-shmobile/platsmp-scu.c  | 1 -
>  4 files changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/mach-shmobile/common.h b/arch/arm/mach-shmobile/common.h
> index 225c12bb3de91e76..5464b7a75e3028a7 100644
> --- a/arch/arm/mach-shmobile/common.h
> +++ b/arch/arm/mach-shmobile/common.h
> @@ -4,7 +4,6 @@
>  extern void shmobile_init_delay(void);
>  extern void shmobile_boot_vector(void);
>  extern unsigned long shmobile_boot_fn;
> -extern unsigned long shmobile_boot_arg;
>  extern unsigned long shmobile_boot_size;
>  extern void shmobile_smp_boot(void);
>  extern void shmobile_smp_sleep(void);
> diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
> index 4cf7f0b016b0b0fe..ede974b4fd67d8cd 100644
> --- a/arch/arm/mach-shmobile/headsmp.S
> +++ b/arch/arm/mach-shmobile/headsmp.S
> @@ -24,7 +24,6 @@
>  	.arm
>  	.align  12
>  ENTRY(shmobile_boot_vector)
> -	ldr     r0, 2f
>  	ldr     r1, 1f
>  	bx	r1
>  
> @@ -34,9 +33,6 @@ ENDPROC(shmobile_boot_vector)
>  	.globl	shmobile_boot_fn
>  shmobile_boot_fn:
>  1:	.space	4
> -	.globl	shmobile_boot_arg
> -shmobile_boot_arg:
> -2:	.space	4
>  	.globl	shmobile_boot_size
>  shmobile_boot_size:
>  	.long	. - shmobile_boot_vector
> @@ -46,9 +42,9 @@ shmobile_boot_size:
>   */
>  
>  ENTRY(shmobile_smp_boot)
> -						@ r0 = MPIDR_HWID_BITMASK
>  	mrc	p15, 0, r1, c0, c0, 5		@ r1 = MPIDR
> -	and	r0, r1, r0			@ r0 = cpu_logical_map() value
> +	and	r0, r1, #0xffffff		@ MPIDR_HWID_BITMASK
> +						@ r0 = cpu_logical_map() value
>  	mov	r1, #0				@ r1 = CPU index
>  	adr	r2, 1f
>  	ldmia	r2, {r5, r6, r7}
> diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c b/arch/arm/mach-shmobile/platsmp-apmu.c
> index 911884f7e28b174c..aba75c89f9c1c5eb 100644
> --- a/arch/arm/mach-shmobile/platsmp-apmu.c
> +++ b/arch/arm/mach-shmobile/platsmp-apmu.c
> @@ -123,7 +123,6 @@ void __init shmobile_smp_apmu_prepare_cpus(unsigned int max_cpus,
>  {
>  	/* install boot code shared by all CPUs */
>  	shmobile_boot_fn = virt_to_phys(shmobile_smp_boot);
> -	shmobile_boot_arg = MPIDR_HWID_BITMASK;
>  
>  	/* perform per-cpu setup */
>  	apmu_parse_cfg(apmu_init_cpu, apmu_config, num);
> diff --git a/arch/arm/mach-shmobile/platsmp-scu.c b/arch/arm/mach-shmobile/platsmp-scu.c
> index 4c7d2caf3730f644..8d478f1da265d55e 100644
> --- a/arch/arm/mach-shmobile/platsmp-scu.c
> +++ b/arch/arm/mach-shmobile/platsmp-scu.c
> @@ -46,7 +46,6 @@ void __init shmobile_smp_scu_prepare_cpus(phys_addr_t scu_base_phys,
>  {
>  	/* install boot code shared by all CPUs */
>  	shmobile_boot_fn = virt_to_phys(shmobile_smp_boot);
> -	shmobile_boot_arg = MPIDR_HWID_BITMASK;
>  
>  	/* enable SCU and cache coherency on booting CPU */
>  	shmobile_scu_base_phys = scu_base_phys;
> -- 
> 1.9.1
> 
> 


From will.deacon at arm.com  Wed Feb 10 07:48:16 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 15:48:16 +0000
Subject: [PATCH v3 1/3] iommu/io-pgtable: Add ARMv7 short descriptor
 support
In-Reply-To: <066c4af0e29c9cc658bd5e48edc5e2d7ba7140a1.1453723096.git.robin.murphy@arm.com>
References: <cover.1453723096.git.robin.murphy@arm.com>
 <066c4af0e29c9cc658bd5e48edc5e2d7ba7140a1.1453723096.git.robin.murphy@arm.com>
Message-ID: <20160210154815.GO1052@arm.com>

Hi Robin,

On Tue, Jan 26, 2016 at 05:13:13PM +0000, Robin Murphy wrote:
> Add a nearly-complete ARMv7 short descriptor implementation, omitting
> only a few legacy and CPU-centric aspects which shouldn't be necessary
> for IOMMU API use anyway.
> 
> Signed-off-by: Yong Wu <yong.wu at mediatek.com>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
>  drivers/iommu/Kconfig              |  19 +
>  drivers/iommu/Makefile             |   1 +
>  drivers/iommu/io-pgtable-arm-v7s.c | 849 +++++++++++++++++++++++++++++++++++++
>  drivers/iommu/io-pgtable.c         |   3 +
>  drivers/iommu/io-pgtable.h         |  14 +-
>  5 files changed, 885 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/iommu/io-pgtable-arm-v7s.c

This looks good to me, with one minor comment below.

> diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
> index 36673c8..aa57073 100644
> --- a/drivers/iommu/io-pgtable.h
> +++ b/drivers/iommu/io-pgtable.h
> @@ -1,5 +1,6 @@
>  #ifndef __IO_PGTABLE_H
>  #define __IO_PGTABLE_H
> +#include <linux/bitops.h>
>  
>  /*
>   * Public API for use by IOMMU drivers
> @@ -9,6 +10,7 @@ enum io_pgtable_fmt {
>  	ARM_32_LPAE_S2,
>  	ARM_64_LPAE_S1,
>  	ARM_64_LPAE_S2,
> +	ARM_V7S,
>  	IO_PGTABLE_NUM_FMTS,
>  };
>  
> @@ -45,7 +47,9 @@ struct iommu_gather_ops {
>   *                 page table walker.
>   */
>  struct io_pgtable_cfg {
> -	#define IO_PGTABLE_QUIRK_ARM_NS	(1 << 0)	/* Set NS bit in PTEs */
> +	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0) /* Set NS bit in PTEs */
> +	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1) /* No AP/XN bits */
> +	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2) /* TLB Inv. on map */

We should either try to keep these generic or add _ARM_ in the names. I
don't see why we couldn't have them as generic quicks, but that means
you should fix the AP/XN comment to be architecture agnostic and also
hack the lpae iopgtable alloc code to reject a cfg with unsupported
quirks.

With that change, I'm happy to queue this via my tree or whatever is
easiest for Yong/Joerg.

Will


From marc.zyngier at arm.com  Wed Feb 10 07:48:35 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 15:48:35 +0000
Subject: [PATCH v2 14/28] ARM: KVM: Add guest entry code
In-Reply-To: <20160209184445.GR5171@cbox>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-15-git-send-email-marc.zyngier@arm.com>
 <20160209184445.GR5171@cbox>
Message-ID: <56BB5BD3.8020600@arm.com>

On 09/02/16 18:44, Christoffer Dall wrote:
> On Thu, Feb 04, 2016 at 11:00:31AM +0000, Marc Zyngier wrote:
>> Add the very minimal piece of code that is now required to jump
>> into the guest (and return from it). This code is only concerned
>> with save/restoring the USR registers (r0-r12+lr for the guest,
>> r4-r12+lr for the host), as everything else is dealt with in C
>> (VFP is another matter though).
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm/kvm/hyp/Makefile |  1 +
>>  arch/arm/kvm/hyp/entry.S  | 70 +++++++++++++++++++++++++++++++++++++++++++++++
>>  arch/arm/kvm/hyp/hyp.h    |  2 ++
>>  3 files changed, 73 insertions(+)
>>  create mode 100644 arch/arm/kvm/hyp/entry.S
>>
>> diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
>> index 173bd1d..c779690 100644
>> --- a/arch/arm/kvm/hyp/Makefile
>> +++ b/arch/arm/kvm/hyp/Makefile
>> @@ -8,3 +8,4 @@ obj-$(CONFIG_KVM_ARM_HOST) += timer-sr.o
>>  obj-$(CONFIG_KVM_ARM_HOST) += vgic-v2-sr.o
>>  obj-$(CONFIG_KVM_ARM_HOST) += vfp.o
>>  obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o
>> +obj-$(CONFIG_KVM_ARM_HOST) += entry.o
>> diff --git a/arch/arm/kvm/hyp/entry.S b/arch/arm/kvm/hyp/entry.S
>> new file mode 100644
>> index 0000000..32f79b0
>> --- /dev/null
>> +++ b/arch/arm/kvm/hyp/entry.S
>> @@ -0,0 +1,70 @@
>> +/*
>> + * Copyright (C) 2016 - ARM Ltd
>> + * Author: Marc Zyngier <marc.zyngier at arm.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/linkage.h>
>> +#include <asm/asm-offsets.h>
>> +#include <asm/kvm_arm.h>
>> +
>> +	.arch_extension     virt
>> +
>> +	.text
>> +	.pushsection	.hyp.text, "ax"
>> +
>> +#define USR_REGS_OFFSET		(CPU_CTXT_GP_REGS + GP_REGS_USR)
>> +
>> +/* int __guest_enter(struct kvm_vcpu *vcpu, struct kvm_cpu_context *host) */
>> +ENTRY(__guest_enter)
>> +	@ Save host registers
>> +	add	r1, r1, #(USR_REGS_OFFSET + S_R4)
>> +	stm	r1!, {r4-r12}
>> +	str	lr, [r1, #4]	@ Skip SP_usr (already saved)
>> +
>> +	@ Restore guest registers
>> +	add	r0, r0,  #(VCPU_GUEST_CTXT + USR_REGS_OFFSET + S_R0)
> 
> this really relies on offsetof(struct pt_regs, ARM_r0) == 0, which I
> guess will likely never change, but given there's both a kernel and uapi
> version of struct pt_regs, are we sure about this?

If they did diverge, a lot of things would just break. arm64 does have
different types between user and kernel, but the userspace version is
guaranteed to be a strict prefix of the kernel one. I believe arm would
have to enforce the same thing if it changed.

> 
>> +	ldr	lr, [r0, #S_LR]
>> +	ldm	r0, {r0-r12}
>> +
>> +	clrex
>> +	eret
>> +ENDPROC(__guest_enter)
>> +
>> +ENTRY(__guest_exit)
>> +	/*
>> +	 * return convention:
>> +	 * guest r0, r1, r2 saved on the stack
>> +	 * r0: vcpu pointer
>> +	 * r1: exception code
>> +	 */
>> +
>> +	add	r2, r0, #(VCPU_GUEST_CTXT + USR_REGS_OFFSET + S_R3)
>> +	stm	r2!, {r3-r12}
>> +	str	lr, [r2, #4]
>> +	add	r2, r0, #(VCPU_GUEST_CTXT + USR_REGS_OFFSET + S_R0)
>> +	pop	{r3, r4, r5}		@ r0, r1, r2
>> +	stm	r2, {r3-r5}
>> +
>> +	ldr	r0, [r0, #VCPU_HOST_CTXT]
>> +	add	r0, r0, #(USR_REGS_OFFSET + S_R4)
>> +	ldm	r0!, {r4-r12}
>> +	ldr	lr, [r0, #4]
>> +
>> +	mov	r0, r1
>> +	bx	lr
>> +ENDPROC(__guest_exit)
>> +
>> +	.popsection
>> +
>> diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
>> index 278eb1f..b3f6ed2 100644
>> --- a/arch/arm/kvm/hyp/hyp.h
>> +++ b/arch/arm/kvm/hyp/hyp.h
>> @@ -110,4 +110,6 @@ static inline bool __vfp_enabled(void)
>>  void __hyp_text __banked_save_state(struct kvm_cpu_context *ctxt);
>>  void __hyp_text __banked_restore_state(struct kvm_cpu_context *ctxt);
>>  
>> +int asmlinkage __guest_enter(struct kvm_vcpu *vcpu,
>> +			     struct kvm_cpu_context *host);
>>  #endif /* __ARM_KVM_HYP_H__ */
>> -- 
>> 2.1.4
>>
> 
> Otherwise:
> Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From marc.zyngier at arm.com  Wed Feb 10 08:00:10 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 16:00:10 +0000
Subject: [PATCH v2 16/28] ARM: KVM: Add the new world switch implementation
In-Reply-To: <20160209184455.GT5171@cbox>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-17-git-send-email-marc.zyngier@arm.com>
 <20160209184455.GT5171@cbox>
Message-ID: <56BB5E8A.5030103@arm.com>

On 09/02/16 18:44, Christoffer Dall wrote:
> On Thu, Feb 04, 2016 at 11:00:33AM +0000, Marc Zyngier wrote:
>> The new world switch implementation is modeled after the arm64 one,
>> calling the various save/restore functions in turn, and having as
>> little state as possible.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm/kvm/hyp/Makefile |   1 +
>>  arch/arm/kvm/hyp/hyp.h    |   7 +++
>>  arch/arm/kvm/hyp/switch.c | 136 ++++++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 144 insertions(+)
>>  create mode 100644 arch/arm/kvm/hyp/switch.c
>>
>> diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
>> index c779690..cfab402 100644
>> --- a/arch/arm/kvm/hyp/Makefile
>> +++ b/arch/arm/kvm/hyp/Makefile
>> @@ -9,3 +9,4 @@ obj-$(CONFIG_KVM_ARM_HOST) += vgic-v2-sr.o
>>  obj-$(CONFIG_KVM_ARM_HOST) += vfp.o
>>  obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o
>>  obj-$(CONFIG_KVM_ARM_HOST) += entry.o
>> +obj-$(CONFIG_KVM_ARM_HOST) += switch.o
>> diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
>> index b3f6ed2..2ca651f 100644
>> --- a/arch/arm/kvm/hyp/hyp.h
>> +++ b/arch/arm/kvm/hyp/hyp.h
>> @@ -60,11 +60,16 @@
>>  #define CNTV_CVAL	__ACCESS_CP15_64(3, c14)
>>  #define CNTVOFF		__ACCESS_CP15_64(4, c14)
>>  
>> +#define MIDR		__ACCESS_CP15(c0, 0, c0, 0)
>>  #define CSSELR		__ACCESS_CP15(c0, 2, c0, 0)
>> +#define VMIDR		__ACCESS_CP15(c0, 4, c0, 0)
> 
> Nit: This is called VPIDR in v7 and VMPIDR_EL2 in v8 IIUC.  Should we
> refer to it by one of those names instead?

Seems to be VPIDR in all cases, actually (I stupidly made it consistent,
silly me!). I'll definitely fix that, thanks for noticing it!

Cheers,

	M.
-- 
Jazz is not dead. It just smells funny...


From mark.rutland at arm.com  Wed Feb 10 08:01:27 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 10 Feb 2016 16:01:27 +0000
Subject: [PATCH] arm64: Rework valid_user_regs
In-Reply-To: <20160210144324.GL1052@arm.com>
References: <1455041501-30018-1-git-send-email-mark.rutland@arm.com>
 <20160210115853.GG1052@arm.com> <20160210123110.GD2632@leverpostej>
 <CAFEAcA-3mgxu6hNSOLhFMmfzB705xyZTyfa5eiRWX6MOnYMVvQ@mail.gmail.com>
 <20160210144324.GL1052@arm.com>
Message-ID: <20160210160127.GE2632@leverpostej>

On Wed, Feb 10, 2016 at 02:43:24PM +0000, Will Deacon wrote:
> On Wed, Feb 10, 2016 at 02:23:29PM +0000, Peter Maydell wrote:
> > On 10 February 2016 at 12:31, Mark Rutland <mark.rutland at arm.com> wrote:
> > > On Wed, Feb 10, 2016 at 11:58:53AM +0000, Will Deacon wrote:
> > >> I think we should err on the side of caution and nuke SS and IL for both
> > >> native and compat too, although that seems a odds with the PSR_s mask.
> > >> I wonder how relevant those PSR groups are in ARMv8...
> > >
> > > Ok.
> > 
> > If you nuke SS does that have any side effects in the case
> > of (for instance) interactions between ptrace single step
> > and ptrace syscall tracing? (ie do we ever end up in a situation
> > where the ptracer can read a PSR for the debuggee which has
> > SS set? if so then it should be able to write back the PSR
> > it has just read without any bits being unset.)
> 
> I don't think so -- the signal dispatch logic "fast-forwards" the stepping
> state machine so that we step into the signal handler, therefore the SS
> bit should always be clear on entry afaict.

That handles entry, but what about exit?

Is there are a guarantee that we won't call user_enable_single_step() if
the return path is traced?

Mark.


From marc.zyngier at arm.com  Wed Feb 10 08:02:14 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 16:02:14 +0000
Subject: [PATCH v2 18/28] ARM: KVM: Add HYP mode entry code
In-Reply-To: <20160209170042.GA5171@cbox>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-19-git-send-email-marc.zyngier@arm.com>
 <20160209170042.GA5171@cbox>
Message-ID: <56BB5F06.9000606@arm.com>

On 09/02/16 17:00, Christoffer Dall wrote:
> On Thu, Feb 04, 2016 at 11:00:35AM +0000, Marc Zyngier wrote:
>> This part is almost entierely borrowed from the existing code, just
>> slightly simplifying the HYP function call (as we now save SPSR_hyp
>> in the world switch).
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm/kvm/hyp/Makefile    |   1 +
>>  arch/arm/kvm/hyp/hyp-entry.S | 157 +++++++++++++++++++++++++++++++++++++++++++
>>  arch/arm/kvm/hyp/hyp.h       |   2 +
>>  3 files changed, 160 insertions(+)
>>  create mode 100644 arch/arm/kvm/hyp/hyp-entry.S
>>
>> diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
>> index cfab402..a7d3a7e 100644
>> --- a/arch/arm/kvm/hyp/Makefile
>> +++ b/arch/arm/kvm/hyp/Makefile
>> @@ -9,4 +9,5 @@ obj-$(CONFIG_KVM_ARM_HOST) += vgic-v2-sr.o
>>  obj-$(CONFIG_KVM_ARM_HOST) += vfp.o
>>  obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o
>>  obj-$(CONFIG_KVM_ARM_HOST) += entry.o
>> +obj-$(CONFIG_KVM_ARM_HOST) += hyp-entry.o
>>  obj-$(CONFIG_KVM_ARM_HOST) += switch.o
>> diff --git a/arch/arm/kvm/hyp/hyp-entry.S b/arch/arm/kvm/hyp/hyp-entry.S
>> new file mode 100644
>> index 0000000..44bc11f
>> --- /dev/null
>> +++ b/arch/arm/kvm/hyp/hyp-entry.S
>> @@ -0,0 +1,157 @@
>> +/*
>> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
>> + * Author: Christoffer Dall <c.dall at virtualopensystems.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, write to the Free Software
>> + * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
>> + */
>> +
>> +#include <linux/linkage.h>
>> +#include <asm/kvm_arm.h>
>> +#include <asm/kvm_asm.h>
>> +
>> +	.arch_extension     virt
>> +
>> +	.text
>> +	.pushsection	.hyp.text, "ax"
>> +
>> +.macro load_vcpu	reg
>> +	mrc	p15, 4, \reg, c13, c0, 2	@ HTPIDR
>> +.endm
>> +
>> +/********************************************************************
>> + * Hypervisor exception vector and handlers
>> + *
>> + *
>> + * The KVM/ARM Hypervisor ABI is defined as follows:
>> + *
>> + * Entry to Hyp mode from the host kernel will happen _only_ when an HVC
>> + * instruction is issued since all traps are disabled when running the host
>> + * kernel as per the Hyp-mode initialization at boot time.
>> + *
>> + * HVC instructions cause a trap to the vector page + offset 0x14 (see hyp_hvc
>> + * below) when the HVC instruction is called from SVC mode (i.e. a guest or the
>> + * host kernel) and they cause a trap to the vector page + offset 0x8 when HVC
>> + * instructions are called from within Hyp-mode.
>> + *
>> + * Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
>> + *    Switching to Hyp mode is done through a simple HVC #0 instruction. The
>> + *    exception vector code will check that the HVC comes from VMID==0.
>> + *    - r0 contains a pointer to a HYP function
>> + *    - r1, r2, and r3 contain arguments to the above function.
>> + *    - The HYP function will be called with its arguments in r0, r1 and r2.
>> + *    On HYP function return, we return directly to SVC.
>> + *
>> + * Note that the above is used to execute code in Hyp-mode from a host-kernel
>> + * point of view, and is a different concept from performing a world-switch and
>> + * executing guest code SVC mode (with a VMID != 0).
>> + */
>> +
>> +	.align 5
>> +__hyp_vector:
>> +	.global	__hyp_vector
>> +__kvm_hyp_vector:
>> +	.weak __kvm_hyp_vector
>> +
>> +	@ Hyp-mode exception vector
>> +	W(b)	hyp_reset
>> +	W(b)	hyp_undef
>> +	W(b)	hyp_svc
>> +	W(b)	hyp_pabt
>> +	W(b)	hyp_dabt
>> +	W(b)	hyp_hvc
>> +	W(b)	hyp_irq
>> +	W(b)	hyp_fiq
>> +
>> +.macro invalid_vector label, cause
>> +	.align
>> +\label:	b	.
>> +.endm
>> +
>> +	invalid_vector	hyp_reset
>> +	invalid_vector	hyp_undef
>> +	invalid_vector	hyp_svc
>> +	invalid_vector	hyp_pabt
>> +	invalid_vector	hyp_dabt
>> +	invalid_vector	hyp_fiq
>> +
>> +hyp_hvc:
>> +	/*
>> +	 * Getting here is either because of a trap from a guest,
>> +	 * or from executing HVC from the host kernel, which means
>> +	 * "do something in Hyp mode".
>> +	 */
>> +	push	{r0, r1, r2}
>> +
>> +	@ Check syndrome register
>> +	mrc	p15, 4, r1, c5, c2, 0	@ HSR
>> +	lsr	r0, r1, #HSR_EC_SHIFT
>> +	cmp	r0, #HSR_EC_HVC
>> +	bne	guest_trap		@ Not HVC instr.
>> +
>> +	/*
>> +	 * Let's check if the HVC came from VMID 0 and allow simple
>> +	 * switch to Hyp mode
>> +	 */
>> +	mrrc    p15, 6, r0, r2, c2
>> +	lsr     r2, r2, #16
>> +	and     r2, r2, #0xff
>> +	cmp     r2, #0
>> +	bne	guest_trap		@ Guest called HVC
>> +
>> +	/*
>> +	 * Getting here means host called HVC, we shift parameters and branch
>> +	 * to Hyp function.
>> +	 */
>> +	pop	{r0, r1, r2}
>> +
>> +	/* Check for __hyp_get_vectors */
>> +	cmp	r0, #-1
>> +	mrceq	p15, 4, r0, c12, c0, 0	@ get HVBAR
>> +	beq	1f
>> +
>> +	push	{lr}
>> +
>> +	mov	lr, r0
>> +	mov	r0, r1
>> +	mov	r1, r2
>> +	mov	r2, r3
>> +
>> +THUMB(	orr	lr, #1)
>> +	blx	lr			@ Call the HYP function
>> +
>> +	pop	{lr}
>> +1:	eret
>> +
>> +guest_trap:
>> +	load_vcpu r0			@ Load VCPU pointer to r0
>> +
>> +	@ Check if we need the fault information
> 
> nit: this is not about faults at this point, so this comment should
> either go or be reworded to "let's check if we trapped on guest VFP
> access"
> 
> and I think the lsr can be moved into the ifdef as well.

Yes, both good points.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From marc.zyngier at arm.com  Wed Feb 10 08:03:48 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 16:03:48 +0000
Subject: [PATCH v2 19/28] ARM: KVM: Add panic handling code
In-Reply-To: <20160209184503.GV5171@cbox>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-20-git-send-email-marc.zyngier@arm.com>
 <20160209184503.GV5171@cbox>
Message-ID: <56BB5F64.8070708@arm.com>

On 09/02/16 18:45, Christoffer Dall wrote:
> On Thu, Feb 04, 2016 at 11:00:36AM +0000, Marc Zyngier wrote:
>> Instead of spinning forever, let's "properly" handle any unexpected
>> exception ("properly" meaning "print a spat on the console and die").
>>
>> This has proved useful quite a few times...
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm/kvm/hyp/hyp-entry.S | 28 +++++++++++++++++++++-------
>>  arch/arm/kvm/hyp/switch.c    | 38 ++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 59 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/kvm/hyp/hyp-entry.S b/arch/arm/kvm/hyp/hyp-entry.S
>> index 44bc11f..ca412ad 100644
>> --- a/arch/arm/kvm/hyp/hyp-entry.S
>> +++ b/arch/arm/kvm/hyp/hyp-entry.S
>> @@ -75,15 +75,29 @@ __kvm_hyp_vector:
>>  
>>  .macro invalid_vector label, cause
>>  	.align
>> -\label:	b	.
>> +\label:	mov	r0, #\cause
>> +	b	__hyp_panic
>>  .endm
>>  
>> -	invalid_vector	hyp_reset
>> -	invalid_vector	hyp_undef
>> -	invalid_vector	hyp_svc
>> -	invalid_vector	hyp_pabt
>> -	invalid_vector	hyp_dabt
>> -	invalid_vector	hyp_fiq
>> +	invalid_vector	hyp_reset	ARM_EXCEPTION_RESET
>> +	invalid_vector	hyp_undef	ARM_EXCEPTION_UNDEFINED
>> +	invalid_vector	hyp_svc		ARM_EXCEPTION_SOFTWARE
>> +	invalid_vector	hyp_pabt	ARM_EXCEPTION_PREF_ABORT
>> +	invalid_vector	hyp_dabt	ARM_EXCEPTION_DATA_ABORT
>> +	invalid_vector	hyp_fiq		ARM_EXCEPTION_FIQ
>> +
>> +ENTRY(__hyp_do_panic)
>> +	mrs	lr, cpsr
>> +	bic	lr, lr, #MODE_MASK
>> +	orr	lr, lr, #SVC_MODE
>> +THUMB(	orr	lr, lr, #PSR_T_BIT	)
>> +	msr	spsr_cxsf, lr
>> +	ldr	lr, =panic
>> +	msr	ELR_hyp, lr
>> +	ldr	lr, =kvm_call_hyp
>> +	clrex
>> +	eret
>> +ENDPROC(__hyp_do_panic)
>>  
>>  hyp_hvc:
>>  	/*
>> diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
>> index 8bfd729..67f3944 100644
>> --- a/arch/arm/kvm/hyp/switch.c
>> +++ b/arch/arm/kvm/hyp/switch.c
>> @@ -188,3 +188,41 @@ again:
>>  }
>>  
>>  __alias(__guest_run) int __weak __kvm_vcpu_run(struct kvm_vcpu *vcpu);
>> +
>> +static const char * const __hyp_panic_string[] = {
>> +	[ARM_EXCEPTION_RESET]      = "\nHYP panic: RST?? PC:%08x CPSR:%08x",
>> +	[ARM_EXCEPTION_UNDEFINED]  = "\nHYP panic: UNDEF PC:%08x CPSR:%08x",
>> +	[ARM_EXCEPTION_SOFTWARE]   = "\nHYP panic: SVC?? PC:%08x CPSR:%08x",
>> +	[ARM_EXCEPTION_PREF_ABORT] = "\nHYP panic: PABRT PC:%08x CPSR:%08x",
>> +	[ARM_EXCEPTION_DATA_ABORT] = "\nHYP panic: DABRT PC:%08x ADDR:%08x",
>> +	[ARM_EXCEPTION_IRQ]        = "\nHYP panic: IRQ?? PC:%08x CPSR:%08x",
>> +	[ARM_EXCEPTION_FIQ]        = "\nHYP panic: FIQ?? PC:%08x CPSR:%08x",
>> +	[ARM_EXCEPTION_HVC]        = "\nHYP panic: HVC?? PC:%08x CPSR:%08x",
> 
> Why the question marks?

Ah, that was me wondering how we'd get those! I'll remove them.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From will.deacon at arm.com  Wed Feb 10 08:04:21 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 16:04:21 +0000
Subject: [PATCH] arm64: Rework valid_user_regs
In-Reply-To: <20160210160127.GE2632@leverpostej>
References: <1455041501-30018-1-git-send-email-mark.rutland@arm.com>
 <20160210115853.GG1052@arm.com> <20160210123110.GD2632@leverpostej>
 <CAFEAcA-3mgxu6hNSOLhFMmfzB705xyZTyfa5eiRWX6MOnYMVvQ@mail.gmail.com>
 <20160210144324.GL1052@arm.com> <20160210160127.GE2632@leverpostej>
Message-ID: <20160210160420.GQ1052@arm.com>

On Wed, Feb 10, 2016 at 04:01:27PM +0000, Mark Rutland wrote:
> On Wed, Feb 10, 2016 at 02:43:24PM +0000, Will Deacon wrote:
> > On Wed, Feb 10, 2016 at 02:23:29PM +0000, Peter Maydell wrote:
> > > On 10 February 2016 at 12:31, Mark Rutland <mark.rutland at arm.com> wrote:
> > > > On Wed, Feb 10, 2016 at 11:58:53AM +0000, Will Deacon wrote:
> > > >> I think we should err on the side of caution and nuke SS and IL for both
> > > >> native and compat too, although that seems a odds with the PSR_s mask.
> > > >> I wonder how relevant those PSR groups are in ARMv8...
> > > >
> > > > Ok.
> > > 
> > > If you nuke SS does that have any side effects in the case
> > > of (for instance) interactions between ptrace single step
> > > and ptrace syscall tracing? (ie do we ever end up in a situation
> > > where the ptracer can read a PSR for the debuggee which has
> > > SS set? if so then it should be able to write back the PSR
> > > it has just read without any bits being unset.)
> > 
> > I don't think so -- the signal dispatch logic "fast-forwards" the stepping
> > state machine so that we step into the signal handler, therefore the SS
> > bit should always be clear on entry afaict.
> 
> That handles entry, but what about exit?
> 
> Is there are a guarantee that we won't call user_enable_single_step() if
> the return path is traced?

Why would that be a problem? I think I'm missing your point...

Will


From mark.rutland at arm.com  Wed Feb 10 08:05:50 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 10 Feb 2016 16:05:50 +0000
Subject: [PATCH] arm64: Rework valid_user_regs
In-Reply-To: <20160210160420.GQ1052@arm.com>
References: <1455041501-30018-1-git-send-email-mark.rutland@arm.com>
 <20160210115853.GG1052@arm.com> <20160210123110.GD2632@leverpostej>
 <CAFEAcA-3mgxu6hNSOLhFMmfzB705xyZTyfa5eiRWX6MOnYMVvQ@mail.gmail.com>
 <20160210144324.GL1052@arm.com> <20160210160127.GE2632@leverpostej>
 <20160210160420.GQ1052@arm.com>
Message-ID: <20160210160550.GF2632@leverpostej>

On Wed, Feb 10, 2016 at 04:04:21PM +0000, Will Deacon wrote:
> On Wed, Feb 10, 2016 at 04:01:27PM +0000, Mark Rutland wrote:
> > On Wed, Feb 10, 2016 at 02:43:24PM +0000, Will Deacon wrote:
> > > On Wed, Feb 10, 2016 at 02:23:29PM +0000, Peter Maydell wrote:
> > > > On 10 February 2016 at 12:31, Mark Rutland <mark.rutland at arm.com> wrote:
> > > > > On Wed, Feb 10, 2016 at 11:58:53AM +0000, Will Deacon wrote:
> > > > >> I think we should err on the side of caution and nuke SS and IL for both
> > > > >> native and compat too, although that seems a odds with the PSR_s mask.
> > > > >> I wonder how relevant those PSR groups are in ARMv8...
> > > > >
> > > > > Ok.
> > > > 
> > > > If you nuke SS does that have any side effects in the case
> > > > of (for instance) interactions between ptrace single step
> > > > and ptrace syscall tracing? (ie do we ever end up in a situation
> > > > where the ptracer can read a PSR for the debuggee which has
> > > > SS set? if so then it should be able to write back the PSR
> > > > it has just read without any bits being unset.)
> > > 
> > > I don't think so -- the signal dispatch logic "fast-forwards" the stepping
> > > state machine so that we step into the signal handler, therefore the SS
> > > bit should always be clear on entry afaict.
> > 
> > That handles entry, but what about exit?
> > 
> > Is there are a guarantee that we won't call user_enable_single_step() if
> > the return path is traced?
> 
> Why would that be a problem? I think I'm missing your point...

We would nuke the SS bit if the tracing happens after
user_enable_single_step, if the tracer fiddled with pstate at all. So
you wouldn't get the single stepping you expected.

Maybe I'm missing some reason this is prevented by construction.

Mark.


From marc.zyngier at arm.com  Wed Feb 10 08:07:07 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 16:07:07 +0000
Subject: [PATCH v2 20/28] ARM: KVM: Change kvm_call_hyp return type to
 unsigned long
In-Reply-To: <20160209182828.GB5171@cbox>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-21-git-send-email-marc.zyngier@arm.com>
 <20160209182828.GB5171@cbox>
Message-ID: <56BB602B.4060902@arm.com>

On 09/02/16 18:28, Christoffer Dall wrote:
> On Thu, Feb 04, 2016 at 11:00:37AM +0000, Marc Zyngier wrote:
>> Having u64 as the kvm_call_hyp return type is problematic, as
>> it forces all kind of tricks for the return values from HYP
>> to be promoted to 64bit (LE has the LSB in r0, and BE has them
>> in r1).
>>
>> Since the only user of the return value is perfectly happy with
>> a 32bit value, let's make kvm_call_hyp return an unsigned long,
>> which is 32bit on ARM.
> 
> I wonder why I ever did this as a u64...

Probably to cater for the largest possible return value, before we
started looking at BE... ;-)

> should the arm64 counterpart be modified to an unsigned long as well?

That'd be a sensible change.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From lee.jones at linaro.org  Wed Feb 10 08:12:16 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 16:12:16 +0000
Subject: [PATCH v9 1/2] mfd: act8945a: add Active-semi ACT8945A PMIC MFD
 driver
In-Reply-To: <1453887530-22490-2-git-send-email-wenyou.yang@atmel.com>
References: <1453887530-22490-1-git-send-email-wenyou.yang@atmel.com>
 <1453887530-22490-2-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20160210161216.GG26950@x1>

On Wed, 27 Jan 2016, Wenyou Yang wrote:

> This patch adds support for the Active-semi ACT8945A PMIC.
> It is a Multi Function Device with the following subdevices:
>  - Regulator
>  - Charger
> 
> It is interfaced to the host controller using I2C interface,
> ACT8945A is a child device of the I2C.
> 
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> Acked-by: Lee Jones <lee.jones at linaro.org>
> Acked-by: Peter Korsgaard <peter at korsgaard.com>
> ---
> 
> Changes in v9:
>  - remove unneeded struct act8945a_dev structure.
>  - collect Acked from Lee.
>  - collect Acked from Peter.
> 
> Changes in v8:
>  - change the subdevice's name "act8945a-pmic" to "act8945a-regulator".
> 
> Changes in v7:
>  - remove struct act8945a_dev to .c file.
>  - remove unused .h file.
> 
> Changes in v6:
>  - change MFD_ACT8945A type from bool to tristate.
>  - revert depends on to 'I2C'.
> 
> Changes in v5:
>  - change depends on to 'I2C=y'.
> 
> Changes in v4:
>  - add a space before .compatible.
>  - collect Reviewed-by from Krzysztof Kozlowski.
> 
> Changes in v3: None
> Changes in v2:
>  - add more help information in Kconfig.
>  - update the file header with short version license and author line.
>  - remove unused structure members (dev, i2c_client) of stuct act8945a_dev.
>  - use define "PLATFORM_DEVID_NONE" for mfd_add_devices(), instead of '-1'.
>  - use more explicit info to indicate the failure to add sub devices.
>  - remove the unnecessary print out.
>  - substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").
> 
>  drivers/mfd/Kconfig    |   11 +++++
>  drivers/mfd/Makefile   |    1 +
>  drivers/mfd/act8945a.c |  104 ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 116 insertions(+)
>  create mode 100644 drivers/mfd/act8945a.c

Applied, thanks.

> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 6c4ebd9..38994bb 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -18,6 +18,17 @@ config MFD_CS5535
>  	  This is the core driver for CS5535/CS5536 MFD functions.  This is
>            necessary for using the board's GPIO and MFGPT functionality.
>  
> +config MFD_ACT8945A
> +	tristate "Active-semi ACT8945A"
> +	select MFD_CORE
> +	select REGMAP_I2C
> +	depends on I2C && OF
> +	help
> +	  Support for the ACT8945A PMIC from Active-semi. This device
> +	  features three step-down DC/DC converters and four low-dropout
> +	  linear regulators, along with a complete ActivePath battery
> +	  charger.
> +
>  config MFD_AS3711
>  	bool "AMS AS3711"
>  	select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 0f230a6..2f1ca82 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -6,6 +6,7 @@
>  obj-$(CONFIG_MFD_88PM860X)	+= 88pm860x.o
>  obj-$(CONFIG_MFD_88PM800)	+= 88pm800.o 88pm80x.o
>  obj-$(CONFIG_MFD_88PM805)	+= 88pm805.o 88pm80x.o
> +obj-$(CONFIG_MFD_ACT8945A)	+= act8945a.o
>  obj-$(CONFIG_MFD_SM501)		+= sm501.o
>  obj-$(CONFIG_MFD_ASIC3)		+= asic3.o tmio_core.o
>  obj-$(CONFIG_MFD_BCM590XX)	+= bcm590xx.o
> diff --git a/drivers/mfd/act8945a.c b/drivers/mfd/act8945a.c
> new file mode 100644
> index 0000000..f59eb99
> --- /dev/null
> +++ b/drivers/mfd/act8945a.c
> @@ -0,0 +1,104 @@
> +/*
> + * MFD driver for Active-semi ACT8945a PMIC
> + *
> + * Copyright (C) 2015 Atmel Corporation.
> + *
> + * Author: Wenyou Yang <wenyou.yang at atmel.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under  the terms of the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/mfd/core.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/regmap.h>
> +
> +static const struct mfd_cell act8945a_devs[] = {
> +	{
> +		.name = "act8945a-regulator",
> +		.of_compatible = "active-semi,act8945a-regulator",
> +	},
> +	{
> +		.name = "act8945a-charger",
> +		.of_compatible = "active-semi,act8945a-charger",
> +	},
> +};
> +
> +static const struct regmap_config act8945a_regmap_config = {
> +	.reg_bits = 8,
> +	.val_bits = 8,
> +};
> +
> +static int act8945a_i2c_probe(struct i2c_client *i2c,
> +			      const struct i2c_device_id *id)
> +{
> +	int ret;
> +	struct regmap *regmap;
> +
> +	regmap = devm_regmap_init_i2c(i2c, &act8945a_regmap_config);
> +	if (IS_ERR(regmap)) {
> +		ret = PTR_ERR(regmap);
> +		dev_err(&i2c->dev, "regmap init failed: %d\n", ret);
> +		return ret;
> +	}
> +
> +	i2c_set_clientdata(i2c, regmap);
> +
> +	ret = mfd_add_devices(&i2c->dev, PLATFORM_DEVID_NONE, act8945a_devs,
> +			      ARRAY_SIZE(act8945a_devs), NULL, 0, NULL);
> +	if (ret) {
> +		dev_err(&i2c->dev, "Failed to add sub devices\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int act8945a_i2c_remove(struct i2c_client *i2c)
> +{
> +	mfd_remove_devices(&i2c->dev);
> +
> +	return 0;
> +}
> +
> +static const struct i2c_device_id act8945a_i2c_id[] = {
> +	{ "act8945a", 0 },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(i2c, act8945a_i2c_id);
> +
> +static const struct of_device_id act8945a_of_match[] = {
> +	{ .compatible = "active-semi,act8945a", },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, act8945a_of_match);
> +
> +static struct i2c_driver act8945a_i2c_driver = {
> +	.driver = {
> +		   .name = "act8945a",
> +		   .of_match_table = of_match_ptr(act8945a_of_match),
> +	},
> +	.probe = act8945a_i2c_probe,
> +	.remove = act8945a_i2c_remove,
> +	.id_table = act8945a_i2c_id,
> +};
> +
> +static int __init act8945a_i2c_init(void)
> +{
> +	return i2c_add_driver(&act8945a_i2c_driver);
> +}
> +subsys_initcall(act8945a_i2c_init);
> +
> +static void __exit act8945a_i2c_exit(void)
> +{
> +	i2c_del_driver(&act8945a_i2c_driver);
> +}
> +module_exit(act8945a_i2c_exit);
> +
> +MODULE_DESCRIPTION("ACT8945A PMIC multi-function driver");
> +MODULE_AUTHOR("Wenyou Yang <wenyou.yang at atmel.com>");
> +MODULE_LICENSE("GPL");

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Wed Feb 10 08:12:49 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 16:12:49 +0000
Subject: [PATCH v9 2/2] mfd: add documentation for ACT8945A DT bindings
In-Reply-To: <1453887530-22490-3-git-send-email-wenyou.yang@atmel.com>
References: <1453887530-22490-1-git-send-email-wenyou.yang@atmel.com>
 <1453887530-22490-3-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20160210161249.GA3782@x1>

On Wed, 27 Jan 2016, Wenyou Yang wrote:

> The Active-semi ACT8945A PMIC is a Multi-Function Device, it has
> two subdevices:
>  - Regulator
>  - Charger
> 
> This patch adds documentation for ACT8945A DT bindings.
> 
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> Acked-by: Rob Herring <robh at kernel.org>
> Acked-by: Lee Jones <lee.jones at linaro.org>
> ---
> 
> Changes in v9: None
> Changes in v8: None
> Changes in v7:
>  - collect Acked-by from Lee Jones
> 
> Changes in v6:
>  - change the regulator name.
> 
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
>  - fix the tabbing errors in Example.
>  - use "pmic at 5b" label, not "act8945a at 5b" in Example.
>  - collect Acked-by from Rob.
> 
> Changes in v2:
>  - use more specific label in Example.
>  - add pmic and charger nodes in Example.
> 
>  Documentation/devicetree/bindings/mfd/act8945a.txt |   82 ++++++++++++++++++++
>  1 file changed, 82 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/act8945a.txt

Applied, thanks.

> diff --git a/Documentation/devicetree/bindings/mfd/act8945a.txt b/Documentation/devicetree/bindings/mfd/act8945a.txt
> new file mode 100644
> index 0000000..f2a8387
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/act8945a.txt
> @@ -0,0 +1,82 @@
> +Device-Tree bindings for Active-semi ACT8945A MFD driver
> +
> +Required properties:
> + - compatible: "active-semi,act8945a".
> + - reg: the I2C slave address for the ACT8945A chip
> +
> +The chip exposes two subdevices:
> + - a regulators: see ../regulator/act8945a-regulator.txt
> + - a charger: see ../power/act8945a-charger.txt
> +
> +Example:
> +	pmic at 5b {
> +		compatible = "active-semi,act8945a";
> +		reg = <0x5b>;
> +		status = "okay";
> +
> +		pmic {
> +			compatible = "active-semi,act8945a-regulator";
> +			active-semi,vsel-high;
> +
> +			regulators {
> +				vdd_1v35_reg: REG_DCDC1 {
> +					regulator-name = "VDD_1V35";
> +					regulator-min-microvolt = <1350000>;
> +					regulator-max-microvolt = <1350000>;
> +					regulator-always-on;
> +				};
> +
> +				vdd_1v2_reg: REG_DCDC2 {
> +					regulator-name = "VDD_1V2";
> +					regulator-min-microvolt = <1100000>;
> +					regulator-max-microvolt = <1300000>;
> +					regulator-always-on;
> +				};
> +
> +				vdd_3v3_reg: REG_DCDC3 {
> +					regulator-name = "VDD_3V3";
> +					regulator-min-microvolt = <3300000>;
> +					regulator-max-microvolt = <3300000>;
> +					regulator-always-on;
> +				};
> +
> +				vdd_fuse_reg: REG_LDO1 {
> +					regulator-name = "VDD_FUSE";
> +					regulator-min-microvolt = <2500000>;
> +					regulator-max-microvolt = <2500000>;
> +					regulator-always-on;
> +				};
> +
> +				vdd_3v3_lp_reg: REG_LDO2 {
> +					regulator-name = "VDD_3V3_LP";
> +					regulator-min-microvolt = <3300000>;
> +					regulator-max-microvolt = <3300000>;
> +					regulator-always-on;
> +				};
> +
> +				vdd_led_reg: REG_LDO3 {
> +					regulator-name = "VDD_LED";
> +					regulator-min-microvolt = <3300000>;
> +					regulator-max-microvolt = <3300000>;
> +					regulator-always-on;
> +				};
> +
> +				vdd_sdhc_1v8_reg: REG_LDO4 {
> +					regulator-name = "VDD_SDHC_1V8";
> +					regulator-min-microvolt = <1800000>;
> +					regulator-max-microvolt = <1800000>;
> +					regulator-always-on;
> +				};
> +			};
> +		};
> +
> +		charger {
> +			compatible = "active-semi,act8945a-charger";
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_charger_chglev>;
> +			active-semi,chglev-gpio = <&pioA 12 GPIO_ACTIVE_HIGH>;
> +			active-semi,input_voltage_threshold = <6600>;
> +			active-semi,precondition_timeout = <40>;
> +			active-semi,total_timeout = <3>;
> +		};
> +	};

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From andre.przywara at arm.com  Wed Feb 10 08:14:34 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 10 Feb 2016 16:14:34 +0000
Subject: breaking DT compatibility
In-Reply-To: <20160210143755.GE31506@lukather>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <56BB2D79.6090402@arm.com>
 <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
 <20160210143755.GE31506@lukather>
Message-ID: <56BB61EA.1030805@arm.com>

Hi,

On 10/02/16 14:37, Maxime Ripard wrote:
> Hi Rob,
> 
> On Wed, Feb 10, 2016 at 07:42:02AM -0600, Rob Herring wrote:
>> On Wed, Feb 10, 2016 at 6:30 AM, Andre Przywara <andre.przywara at arm.com> wrote:
>>> Hi,
>>>
>>> just a ping:
>>>
>>> Are we really OK with breaking existing DTs in 4.6? (per the code in
>>> -next: f7d372ba54ea04d528a291b8dbe34716507bb60b, which is this patch).
>>
>> I only warn and make sure people are aware of the issue. I leave that
>> up to platform maintainers to decide. It depends on the maturity of
>> the platform and users.
> 
> The impacted SoCs support is really partial. For the most supported
> one, big things like display or sound are totally missing, and we
> still update them on a regular basis to add support for new
> devices. As such, users are very likely to upgrade the DT from one
> version to another just because there's new devices available to
> them. And the newest SoC impacted just got introduced in 4.5, and only
> has the UART and MMC devices available.

But I still don't see why we have to break things - can't we just
improve support _without_ breaking compatibility? For instance keeping
the old behaviour around? I can dig out my old x86 hat and find a
_compatible_ solution for this, if you prefer ;-)
Actually doesn't Jean-Francois' patch fixes the PLL8 issue without
breaking anything?

Also were do you want to draw the line for "partial support"? The
sun6i-a31.dtsi is around since 3.12, which was released more than 2
years ago.
If we want to wait for "stabilization", we will probably wait forever. I
find discussions about DT stabilization going back to the very beginning
of DT for ARM - as well as the request for moving the DT bindings out of
the kernel (which I think we should really eventually do now).

Frankly I don't care so much about these particular boards, but just
want avoid to set a bad example for the future - in particular sneaking
this behaviour into the arm64 world, where DTs _really_ come with the
board or are even generated by the (UEFI-)firmware.
U-Boot already can embed a device tree, sounds like a perfect place to
have it stored for me - as long as there is _one_ best version of it.

>> If people complain about it then it's their mess. For platforms
>> supported in distros such as debian or fedora, I would strongly
>> recommend against breaking compatibility.
> 
> None of them are officially supported:
> https://www.debian.org/releases/stable/armhf/ch02s01.html.en
> https://fedoraproject.org/wiki/Architectures/ARM#Fedora_23
> 
> Only the older one are, and they are not affected by this patch.
> 
>> They do ship dtbs, but it's a chicken and egg problem. If dtbs were
>> stable and provided by firmware, then they wouldn't have to provide
>> them. If dtbs are unstable, then they have no choice.
> 
> And while it might work great on platforms that have all the needed
> documentation, or a perfect one, which is our case. Almost each
> release, we discover that something is not working as it was
> documented, when it was documented in the first place.

I understand that it's not an ideal situation for those Allwinner chips
- but nevertheless I would like us to at least _try_ to comply with this
idea. As said before: this patch is a nice rework/cleanup - but
definitely not a good reason to break compatibility.

> It also seems that even on well documented platforms, supported by the
> vendors, the stable ABI dream is not going to happen:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Atmel/README#n105
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/arm/marvell,berlin.txt#n4

I find those two statements really unfortunate ...

> If it makes things clearer, I can also add such a statement.

and would rather see us referring solely to this document instead:
	Documentation/devicetree/bindings/ABI.txt

Cheers,
Andre.

>>> Also I think one needs ACKs from DT maintainers before merging something
>>> in the respective directories, which I don't see here.
>>
>> It can go in with subsystem maintainers ack, but there are problems
>> with this one regardless of compatibility.
>>
>>> As I am somewhat blocked on that patch, I'd like to have some discussion
>>> on the list.
>>>
>>> Thanks,
>>> Andre.
>>>
>>> On 05/02/16 17:59, Andre Przywara wrote:
>>>> Hi Maxime,
>>>>
>>>> just found this while looking at your current git branch, so sorry for
>>>> the late reply.
>>>>
>>>> CC:ing DT people, since you touch both existing DTs(!) and the binding doc.
>>>>
>>>> On 01/02/16 20:20, Maxime Ripard wrote:
>>>>> Remove the fixed dividers from the PLL6 driver to be able to have a
>>>>> reusable driver that can be used across several SoCs that share the same
>>>>> controller, but don't have the same set of dividers for this clock, and to
>>>>> also be reused multiple times in the same SoC, since we're droping the
>>>>> clock name.
>>
>> Removing a compatible name or not has nothing to do with sharing code.
> 
> This was not about the compatible name, but the hardcoded name in our
> structure associated to that compatible. And since we can't register
> two clocks with the same name, we couldn't use the same compatible
> several times.
> 
> Maxime
> 


From lee.jones at linaro.org  Wed Feb 10 08:14:52 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 16:14:52 +0000
Subject: [PATCH v7 04/10] mfd: axp20x: Add missing copyright notice
In-Reply-To: <20160125152958.GO7908@lukather>
References: <1452655854-1528-1-git-send-email-wens@csie.org>
 <1452655854-1528-5-git-send-email-wens@csie.org>
 <20160125143957.GS3368@x1> <20160125152958.GO7908@lukather>
Message-ID: <20160210161452.GB3782@x1>

On Mon, 25 Jan 2016, Maxime Ripard wrote:
> On Mon, Jan 25, 2016 at 02:39:57PM +0000, Lee Jones wrote:
> > On Wed, 13 Jan 2016, Chen-Yu Tsai wrote:
> > 
> > > When the driver was merged, the original author did not include a proper
> > > copyright notice. This patch adds the notice, backdated to when the
> > > driver was merged.
> > 
> > This is very wordy. 
> > 
> > "Supply a backdated copyright notice."
> > 
> > > Cc: Carlo Caione <carlo at caione.org>
> > > Signed-off-by: Chen-Yu Tsai <wens at csie.org>
> > > ---
> > > 
> > > New patch in v7.
> > > 
> > > ---
> > >  drivers/mfd/axp20x.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > 
> > Patch looks fine though:
> > 
> > Acked-by: Lee Jones <lee.jones at linaro.org>
> 
> How do you want to merge these patches ?
> 
> AFAIK, it's mostly MFD patches that could go through your tree, so
> feel free to apply them, I'll apply the DT parts.

Apologies for the delay, I've been super busy.

Yes, please take the ARM patches, I'll take the rest.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Wed Feb 10 08:23:49 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 16:23:49 +0000
Subject: [PATCH 01/14] mfd: intel_quark_i2c_gpio: Use clkdev_create()
In-Reply-To: <1454982341-22715-2-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
 <1454982341-22715-2-git-send-email-sboyd@codeaurora.org>
Message-ID: <20160210162349.GJ3782@x1>

On Mon, 08 Feb 2016, Stephen Boyd wrote:

> Convert this driver to use clkdev_create() instead of
> clk_register_clkdevs(). The latter API is only used by this driver,
> although this driver only allocates one clk to add anyway.
> Furthermore, this driver allocates the clk_lookup structure with
> devm, but clkdev_drop() will free that structure when passed,
> leading to a double free when this driver is removed. Clean it
> all up and pave the way for the removal of clk_register_clkdevs().
> 
> Cc: Lee Jones <lee.jones at linaro.org>
> Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
>  drivers/mfd/intel_quark_i2c_gpio.c | 26 +++++++++-----------------
>  1 file changed, 9 insertions(+), 17 deletions(-)

I never much liked this code [0]

Glad for it to be simplified.

Applied, thanks.

[0] https://lkml.org/lkml/2014/11/25/845

> diff --git a/drivers/mfd/intel_quark_i2c_gpio.c b/drivers/mfd/intel_quark_i2c_gpio.c
> index 042137465300..bdc5e27222c0 100644
> --- a/drivers/mfd/intel_quark_i2c_gpio.c
> +++ b/drivers/mfd/intel_quark_i2c_gpio.c
> @@ -52,8 +52,6 @@
>  /* The Quark I2C controller source clock */
>  #define INTEL_QUARK_I2C_CLK_HZ	33000000
>  
> -#define INTEL_QUARK_I2C_NCLK	1
> -
>  struct intel_quark_mfd {
>  	struct pci_dev		*pdev;
>  	struct clk		*i2c_clk;
> @@ -128,30 +126,24 @@ MODULE_DEVICE_TABLE(pci, intel_quark_mfd_ids);
>  static int intel_quark_register_i2c_clk(struct intel_quark_mfd *quark_mfd)
>  {
>  	struct pci_dev *pdev = quark_mfd->pdev;
> -	struct clk_lookup *i2c_clk_lookup;
>  	struct clk *i2c_clk;
> -	int ret;
> -
> -	i2c_clk_lookup = devm_kcalloc(&pdev->dev, INTEL_QUARK_I2C_NCLK,
> -				      sizeof(*i2c_clk_lookup), GFP_KERNEL);
> -	if (!i2c_clk_lookup)
> -		return -ENOMEM;
> -
> -	i2c_clk_lookup[0].dev_id = INTEL_QUARK_I2C_CONTROLLER_CLK;
>  
>  	i2c_clk = clk_register_fixed_rate(&pdev->dev,
>  					  INTEL_QUARK_I2C_CONTROLLER_CLK, NULL,
>  					  CLK_IS_ROOT, INTEL_QUARK_I2C_CLK_HZ);
> +	if (IS_ERR(i2c_clk))
> +		return PTR_ERR(i2c_clk);
>  
> -	quark_mfd->i2c_clk_lookup = i2c_clk_lookup;
>  	quark_mfd->i2c_clk = i2c_clk;
> +	quark_mfd->i2c_clk_lookup = clkdev_create(i2c_clk, NULL,
> +						INTEL_QUARK_I2C_CONTROLLER_CLK);
>  
> -	ret = clk_register_clkdevs(i2c_clk, i2c_clk_lookup,
> -				   INTEL_QUARK_I2C_NCLK);
> -	if (ret)
> -		dev_err(&pdev->dev, "Fixed clk register failed: %d\n", ret);
> +	if (!quark_mfd->i2c_clk_lookup) {
> +		dev_err(&pdev->dev, "Fixed clk register failed\n");
> +		return -ENOMEM;
> +	}
>  
> -	return ret;
> +	return 0;
>  }
>  
>  static void intel_quark_unregister_i2c_clk(struct pci_dev *pdev)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From tj at kernel.org  Wed Feb 10 08:25:47 2016
From: tj at kernel.org (Tejun Heo)
Date: Wed, 10 Feb 2016 11:25:47 -0500
Subject: [PATCH v4 0/3] ata: Fixes related to edge trigger latch for the
 ahci_xgene_driver.
In-Reply-To: <1454738124-9351-1-git-send-email-stripathi@apm.com>
References: <1454738124-9351-1-git-send-email-stripathi@apm.com>
Message-ID: <20160210162547.GJ3741@mtj.duckdns.org>

On Sat, Feb 06, 2016 at 11:25:21AM +0530, suman Tripathi wrote:
> From: Suman Tripathi <stripathi at apm.com>
> 
> This patch set implements a workaround for an errate in the APM
> X-Gene SATA host controller with edge interrupt. The HOST_IRQ_STAT
> misses the edge interrupt from the PORT_IRQ_STAT when clearing the
> HOST_IRQ_STAT and reporting the PORT_IRQ_STAT happens in same clock
> cycle. It also implements the capability to override generic interrupt
> handler.

Applied 1-3 to libata/for-4.6 with minor updates.

Thanks.

-- 
tejun


From thomas.petazzoni at free-electrons.com  Wed Feb 10 08:29:15 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Feb 2016 17:29:15 +0100
Subject: [PATCH v2 1/2] ARM: mvebu: use armada-370-sata for SATA on Armada 375
Message-ID: <1455121756-20804-1-git-send-email-thomas.petazzoni@free-electrons.com>

From: Lior Amsalem <alior at marvell.com>

The Armada 375 has the same SATA IP as Armada 370 and Armada XP, which
requires the PHY speed to be set in the LP_PHY_CTL register for SATA
hotplug to work.

Therefore, this commit updates the compatible string used to describe
the SATA IP in Armada 375 from marvell,orion-sata to
marvell,armada-370-sata.

Fixes: 4de59085091f753d08c8429d756b46756ab94665 ("ARM: mvebu: add Device Tree description of the Armada 375 SoC")
Cc: <stable at vger.kernel.org>
Signed-off-by: Lior Amsalem <alior at marvell.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
Changes since v1:
 - Add Fixes: tag, and add stable@ in Cc, as suggested by Andrew Lunn.
---
 arch/arm/boot/dts/armada-375.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 7ccce75..cc952cf 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -529,7 +529,7 @@
 			};
 
 			sata at a0000 {
-				compatible = "marvell,orion-sata";
+				compatible = "marvell,armada-370-sata";
 				reg = <0xa0000 0x5000>;
 				interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&gateclk 14>, <&gateclk 20>;
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 10 08:29:16 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 10 Feb 2016 17:29:16 +0100
Subject: [PATCH v2 2/2] ARM: mvebu: add NAND description to Armada 370 DB and
 Armada XP DB
In-Reply-To: <1455121756-20804-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455121756-20804-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455121756-20804-2-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adds the Device Tree description for the 1GB NAND flash
present in the Armada 370 DB and Armada XP DB evaluation boards from
Marvell.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
Changes since v1:
 - Use the new MTD partitions DT binding, with all partitions grouped
   into a 'partitions' subnode. Suggested by Andrew Lunn.
---
 arch/arm/boot/dts/armada-370-db.dts | 27 +++++++++++++++++++++++++++
 arch/arm/boot/dts/armada-xp-db.dts  | 28 ++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index bb280de..2364fc5 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -168,6 +168,33 @@
 					spi-max-frequency = <50000000>;
 				};
 			};
+
+			nand at d0000 {
+				status = "okay";
+				num-cs = <1>;
+				marvell,nand-keep-config;
+				marvell,nand-enable-arbiter;
+				nand-on-flash-bbt;
+
+				partitions {
+					compatible = "fixed-partitions";
+					#address-cells = <1>;
+					#size-cells = <1>;
+
+					partition at 0 {
+						label = "U-Boot";
+						reg = <0 0x800000>;
+					};
+					partition at 800000 {
+						label = "Linux";
+						reg = <0x800000 0x800000>;
+					};
+					partition at 1000000 {
+						label = "Filesystem";
+						reg = <0x1000000 0x3f000000>;
+					};
+				};
+			};
 		};
 
 		pcie-controller {
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index f774101..96aaaed 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -229,6 +229,34 @@
 					spi-max-frequency = <20000000>;
 				};
 			};
+
+			nand at d0000 {
+				status = "okay";
+				num-cs = <1>;
+				marvell,nand-keep-config;
+				marvell,nand-enable-arbiter;
+				nand-on-flash-bbt;
+
+				partitions {
+					compatible = "fixed-partitions";
+					#address-cells = <1>;
+					#size-cells = <1>;
+
+					partition at 0 {
+						label = "U-Boot";
+						reg = <0 0x800000>;
+					};
+					partition at 800000 {
+						label = "Linux";
+						reg = <0x800000 0x800000>;
+					};
+					partition at 1000000 {
+						label = "Filesystem";
+						reg = <0x1000000 0x3f000000>;
+
+					};
+				};
+			};
 		};
 	};
 };
-- 
2.6.4



From mark.rutland at arm.com  Wed Feb 10 08:30:01 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 10 Feb 2016 16:30:01 +0000
Subject: breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi:
 Refactor A31 PLL6 so that it can be reused)
In-Reply-To: <20160210143755.GE31506@lukather>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <56BB2D79.6090402@arm.com>
 <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
 <20160210143755.GE31506@lukather>
Message-ID: <20160210163001.GG2632@leverpostej>

On Wed, Feb 10, 2016 at 03:37:55PM +0100, Maxime Ripard wrote:
> Hi Rob,
> 
> On Wed, Feb 10, 2016 at 07:42:02AM -0600, Rob Herring wrote:
> > On Wed, Feb 10, 2016 at 6:30 AM, Andre Przywara <andre.przywara at arm.com> wrote:
> > > Hi,
> > >
> > > just a ping:
> > >
> > > Are we really OK with breaking existing DTs in 4.6? (per the code in
> > > -next: f7d372ba54ea04d528a291b8dbe34716507bb60b, which is this patch).
> > 
> > I only warn and make sure people are aware of the issue. I leave that
> > up to platform maintainers to decide. It depends on the maturity of
> > the platform and users.
> 
> The impacted SoCs support is really partial. For the most supported
> one, big things like display or sound are totally missing, and we
> still update them on a regular basis to add support for new
> devices. As such, users are very likely to upgrade the DT from one
> version to another just because there's new devices available to
> them. And the newest SoC impacted just got introduced in 4.5, and only
> has the UART and MMC devices available.
> 
> > If people complain about it then it's their mess. For platforms
> > supported in distros such as debian or fedora, I would strongly
> > recommend against breaking compatibility.
> 
> None of them are officially supported:
> https://www.debian.org/releases/stable/armhf/ch02s01.html.en
> https://fedoraproject.org/wiki/Architectures/ARM#Fedora_23
> 
> Only the older one are, and they are not affected by this patch.
> 
> > They do ship dtbs, but it's a chicken and egg problem. If dtbs were
> > stable and provided by firmware, then they wouldn't have to provide
> > them. If dtbs are unstable, then they have no choice.
> 
> And while it might work great on platforms that have all the needed
> documentation, or a perfect one, which is our case. Almost each
> release, we discover that something is not working as it was
> documented, when it was documented in the first place.
> 
> It also seems that even on well documented platforms, supported by the
> vendors, the stable ABI dream is not going to happen:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Atmel/README#n105
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/arm/marvell,berlin.txt#n4

To be quite frank, I completely disagree with that stance.

It seems like the only reason DT bindings aren't remaining stable is
because people are deliberately ignoring the requirement and reasoning
for doing so.

I agree that it can be painful, and that we cannot predict the future.
There will always be bugs.

Having code in mainline comes with responsibilities. One of those is to
keep said code working for existing users. Otherwise, why bother having
it in mainline at all?

Mark.


From will.deacon at arm.com  Wed Feb 10 08:36:15 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 16:36:15 +0000
Subject: [PATCH] arm64: Rework valid_user_regs
In-Reply-To: <20160210160550.GF2632@leverpostej>
References: <1455041501-30018-1-git-send-email-mark.rutland@arm.com>
 <20160210115853.GG1052@arm.com> <20160210123110.GD2632@leverpostej>
 <CAFEAcA-3mgxu6hNSOLhFMmfzB705xyZTyfa5eiRWX6MOnYMVvQ@mail.gmail.com>
 <20160210144324.GL1052@arm.com> <20160210160127.GE2632@leverpostej>
 <20160210160420.GQ1052@arm.com> <20160210160550.GF2632@leverpostej>
Message-ID: <20160210163615.GR1052@arm.com>

On Wed, Feb 10, 2016 at 04:05:50PM +0000, Mark Rutland wrote:
> On Wed, Feb 10, 2016 at 04:04:21PM +0000, Will Deacon wrote:
> > On Wed, Feb 10, 2016 at 04:01:27PM +0000, Mark Rutland wrote:
> > > On Wed, Feb 10, 2016 at 02:43:24PM +0000, Will Deacon wrote:
> > > > On Wed, Feb 10, 2016 at 02:23:29PM +0000, Peter Maydell wrote:
> > > > > On 10 February 2016 at 12:31, Mark Rutland <mark.rutland at arm.com> wrote:
> > > > > > On Wed, Feb 10, 2016 at 11:58:53AM +0000, Will Deacon wrote:
> > > > > >> I think we should err on the side of caution and nuke SS and IL for both
> > > > > >> native and compat too, although that seems a odds with the PSR_s mask.
> > > > > >> I wonder how relevant those PSR groups are in ARMv8...
> > > > > >
> > > > > > Ok.
> > > > > 
> > > > > If you nuke SS does that have any side effects in the case
> > > > > of (for instance) interactions between ptrace single step
> > > > > and ptrace syscall tracing? (ie do we ever end up in a situation
> > > > > where the ptracer can read a PSR for the debuggee which has
> > > > > SS set? if so then it should be able to write back the PSR
> > > > > it has just read without any bits being unset.)
> > > > 
> > > > I don't think so -- the signal dispatch logic "fast-forwards" the stepping
> > > > state machine so that we step into the signal handler, therefore the SS
> > > > bit should always be clear on entry afaict.
> > > 
> > > That handles entry, but what about exit?
> > > 
> > > Is there are a guarantee that we won't call user_enable_single_step() if
> > > the return path is traced?
> > 
> > Why would that be a problem? I think I'm missing your point...
> 
> We would nuke the SS bit if the tracing happens after
> user_enable_single_step, if the tracer fiddled with pstate at all. So
> you wouldn't get the single stepping you expected.
> 
> Maybe I'm missing some reason this is prevented by construction.

Ok, for some reason I thought this was all about signal handling, but I
now see Peter was referring to general ptrace register manipulation.

In which case, we could force SS to zero if TIF_SINGLESTEP is not set
on the tracee, otherwise letting it be set. Ultimately, MDSCR_EL1.SS
prevents PSTATE.SS from taking effect if !TIF_SINGLESTEP, but it's
worth cleaning this up imo.

Will


From martin at sperl.org  Wed Feb 10 08:39:10 2016
From: martin at sperl.org (Martin Sperl)
Date: Wed, 10 Feb 2016 17:39:10 +0100
Subject: [GIT PULL] bcm2835 DT changes for 4.6
In-Reply-To: <1454977978-17491-1-git-send-email-eric@anholt.net>
References: <1454977978-17491-1-git-send-email-eric@anholt.net>
Message-ID: <DDFB1D8B-805B-488F-9582-796EBCEF287B@sperl.org>


> On 09.02.2016, at 01:32, Eric Anholt <eric at anholt.net> wrote:
> 
> Hi Florian.  Here's the first set of patches for bcm2835 for 4.6.
> We've got more DT patches that are going to happen for new boards,
> too, but they're still getting polished.
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>  git at github.com:anholt/linux.git tags/bcm2835-dt-next-2016-02-04
> 
> for you to fetch changes up to 5ec6f2cd8ec4bcd38ba199ea8711a5ec906d85e7:
> 
>  ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT. (2016-02-02 20:02:45 -0800)
> 
> ----------------------------------------------------------------
> This pull request covers mostly DT changes that didn't make it into
> 4.5 because required header files went through other trees.
> 
> ----------------------------------------------------------------
> Alexander Aring (1):
>      ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
> 
> Lubomir Rintel (1):
>      ARM: bcm2835: dt: Add Raspberry Pi Model A
> 
> Martin Sperl (2):
>      ARM: bcm2835: add the auxiliary spi1 and spi2 to the device tree
>      ARM: bcm2835: follow dt uart node-naming convention

Do you want me to resend a rebased version of:
     ARM: bcm2835: add bcm2835-aux-uart support to default DT

The corresponding driver has been added to tty/tty-next.

Thanks,
	Martin

From ulf.hansson at linaro.org  Wed Feb 10 08:39:57 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Wed, 10 Feb 2016 17:39:57 +0100
Subject: [PATCH v5 RESEND 2/5] ARM: sa1111: ensure no negative value gets
 returned on positive match
In-Reply-To: <1455101250-11327-3-git-send-email-m.szyprowski@samsung.com>
References: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
 <1455101250-11327-3-git-send-email-m.szyprowski@samsung.com>
Message-ID: <CAPDyKFqJTB=Q=uQtqHVy7_ssoDyUSDZtB7H+k00QFnwXqDkzDQ@mail.gmail.com>

On 10 February 2016 at 11:47, Marek Szyprowski <m.szyprowski at samsung.com> wrote:
> This patch ensures that existing bus match callbacks don't return
> negative values (which might be interpreted as potential errors in the
> future) in case of positive match.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>

FYI:
This one has actually been acked by Russell.
https://lkml.org/lkml/2015/12/23/111

Kind regards
Uffe

> ---
>  arch/arm/common/sa1111.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/common/sa1111.c b/arch/arm/common/sa1111.c
> index 3d22494..fb0a0a4 100644
> --- a/arch/arm/common/sa1111.c
> +++ b/arch/arm/common/sa1111.c
> @@ -1290,7 +1290,7 @@ static int sa1111_match(struct device *_dev, struct device_driver *_drv)
>         struct sa1111_dev *dev = SA1111_DEV(_dev);
>         struct sa1111_driver *drv = SA1111_DRV(_drv);
>
> -       return dev->devid & drv->devid;
> +       return !!(dev->devid & drv->devid);
>  }
>
>  static int sa1111_bus_suspend(struct device *dev, pm_message_t state)
> --
> 1.9.2
>


From marc.zyngier at arm.com  Wed Feb 10 08:47:24 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 16:47:24 +0000
Subject: [PATCH 8/8] KVM: arm64: Avoid accessing ICH registers
In-Reply-To: <20160210124513.GO5171@cbox>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <1454931622-14902-9-git-send-email-marc.zyngier@arm.com>
 <20160210124513.GO5171@cbox>
Message-ID: <56BB699C.8060908@arm.com>

On 10/02/16 12:45, Christoffer Dall wrote:
> On Mon, Feb 08, 2016 at 11:40:22AM +0000, Marc Zyngier wrote:
>> Just like on GICv2, we're a bit hammer-happy with GICv3, and access
>> them more often than we should.
>>
>> Adopt a policy similar to what we do for GICv2, only save/restoring
>> the minimal set of registers. As we don't access the registers
>> linearly anymore (we may skip some), the convoluted accessors become
>> slightly simpler, and we can drop the ugly indexing macro that
>> tended to confuse the reviewers.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kvm/hyp/vgic-v3-sr.c | 288 ++++++++++++++++++++++++----------------
>>  include/kvm/arm_vgic.h          |   6 -
>>  virt/kvm/arm/vgic-v3.c          |   4 +-
>>  3 files changed, 176 insertions(+), 122 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
>> index 9142e082..d3813f5 100644
>> --- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
>> +++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
>> @@ -39,12 +39,104 @@
>>  		asm volatile("msr_s " __stringify(r) ", %0" : : "r" (__val));\
>>  	} while (0)
>>  
>> -/* vcpu is already in the HYP VA space */
>> +static u64 __hyp_text __gic_v3_get_lr(unsigned int lr)
>> +{
>> +	switch (lr & 0xf) {
>> +	case 0:
>> +		return read_gicreg(ICH_LR0_EL2);
>> +	case 1:
>> +		return read_gicreg(ICH_LR1_EL2);
>> +	case 2:
>> +		return read_gicreg(ICH_LR2_EL2);
>> +	case 3:
>> +		return read_gicreg(ICH_LR3_EL2);
>> +	case 4:
>> +		return read_gicreg(ICH_LR4_EL2);
>> +	case 5:
>> +		return read_gicreg(ICH_LR5_EL2);
>> +	case 6:
>> +		return read_gicreg(ICH_LR6_EL2);
>> +	case 7:
>> +		return read_gicreg(ICH_LR7_EL2);
>> +	case 8:
>> +		return read_gicreg(ICH_LR8_EL2);
>> +	case 9:
>> +		return read_gicreg(ICH_LR9_EL2);
>> +	case 10:
>> +		return read_gicreg(ICH_LR10_EL2);
>> +	case 11:
>> +		return read_gicreg(ICH_LR11_EL2);
>> +	case 12:
>> +		return read_gicreg(ICH_LR12_EL2);
>> +	case 13:
>> +		return read_gicreg(ICH_LR13_EL2);
>> +	case 14:
>> +		return read_gicreg(ICH_LR14_EL2);
>> +	case 15:
>> +		return read_gicreg(ICH_LR15_EL2);
>> +	}
>> +
>> +	unreachable();
>> +}
>> +
>> +static void __hyp_text __gic_v3_set_lr(u64 val, int lr)
>> +{
>> +	switch (lr & 0xf) {
>> +	case 0:
>> +		write_gicreg(val, ICH_LR0_EL2);
>> +		break;
>> +	case 1:
>> +		write_gicreg(val, ICH_LR1_EL2);
>> +		break;
>> +	case 2:
>> +		write_gicreg(val, ICH_LR2_EL2);
>> +		break;
>> +	case 3:
>> +		write_gicreg(val, ICH_LR3_EL2);
>> +		break;
>> +	case 4:
>> +		write_gicreg(val, ICH_LR4_EL2);
>> +		break;
>> +	case 5:
>> +		write_gicreg(val, ICH_LR5_EL2);
>> +		break;
>> +	case 6:
>> +		write_gicreg(val, ICH_LR6_EL2);
>> +		break;
>> +	case 7:
>> +		write_gicreg(val, ICH_LR7_EL2);
>> +		break;
>> +	case 8:
>> +		write_gicreg(val, ICH_LR8_EL2);
>> +		break;
>> +	case 9:
>> +		write_gicreg(val, ICH_LR9_EL2);
>> +		break;
>> +	case 10:
>> +		write_gicreg(val, ICH_LR10_EL2);
>> +		break;
>> +	case 11:
>> +		write_gicreg(val, ICH_LR11_EL2);
>> +		break;
>> +	case 12:
>> +		write_gicreg(val, ICH_LR12_EL2);
>> +		break;
>> +	case 13:
>> +		write_gicreg(val, ICH_LR13_EL2);
>> +		break;
>> +	case 14:
>> +		write_gicreg(val, ICH_LR14_EL2);
>> +		break;
>> +	case 15:
>> +		write_gicreg(val, ICH_LR15_EL2);
>> +		break;
>> +	}
>> +}
>> +
>>  void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
>>  {
>>  	struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
>>  	u64 val;
>> -	u32 max_lr_idx, nr_pri_bits;
>>  
>>  	/*
>>  	 * Make sure stores to the GIC via the memory mapped interface
>> @@ -53,68 +145,50 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
>>  	dsb(st);
>>  
>>  	cpu_if->vgic_vmcr  = read_gicreg(ICH_VMCR_EL2);
>> -	cpu_if->vgic_misr  = read_gicreg(ICH_MISR_EL2);
>> -	cpu_if->vgic_eisr  = read_gicreg(ICH_EISR_EL2);
>> -	cpu_if->vgic_elrsr = read_gicreg(ICH_ELSR_EL2);
>>  
>> -	write_gicreg(0, ICH_HCR_EL2);
>> -	val = read_gicreg(ICH_VTR_EL2);
>> -	max_lr_idx = vtr_to_max_lr_idx(val);
>> -	nr_pri_bits = vtr_to_nr_pri_bits(val);
>> +	if (vcpu->arch.vgic_cpu.live_lrs) {
>> +		int i;
>> +		u32 max_lr_idx, nr_pri_bits;
>>  
>> -	switch (max_lr_idx) {
>> -	case 15:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(15)] = read_gicreg(ICH_LR15_EL2);
>> -	case 14:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(14)] = read_gicreg(ICH_LR14_EL2);
>> -	case 13:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(13)] = read_gicreg(ICH_LR13_EL2);
>> -	case 12:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(12)] = read_gicreg(ICH_LR12_EL2);
>> -	case 11:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(11)] = read_gicreg(ICH_LR11_EL2);
>> -	case 10:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(10)] = read_gicreg(ICH_LR10_EL2);
>> -	case 9:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(9)] = read_gicreg(ICH_LR9_EL2);
>> -	case 8:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(8)] = read_gicreg(ICH_LR8_EL2);
>> -	case 7:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(7)] = read_gicreg(ICH_LR7_EL2);
>> -	case 6:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(6)] = read_gicreg(ICH_LR6_EL2);
>> -	case 5:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(5)] = read_gicreg(ICH_LR5_EL2);
>> -	case 4:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(4)] = read_gicreg(ICH_LR4_EL2);
>> -	case 3:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(3)] = read_gicreg(ICH_LR3_EL2);
>> -	case 2:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(2)] = read_gicreg(ICH_LR2_EL2);
>> -	case 1:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(1)] = read_gicreg(ICH_LR1_EL2);
>> -	case 0:
>> -		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(0)] = read_gicreg(ICH_LR0_EL2);
>> -	}
>> +		cpu_if->vgic_misr  = read_gicreg(ICH_MISR_EL2);
>> +		cpu_if->vgic_eisr  = read_gicreg(ICH_EISR_EL2);
>> +		cpu_if->vgic_elrsr = read_gicreg(ICH_ELSR_EL2);
>>  
>> -	switch (nr_pri_bits) {
>> -	case 7:
>> -		cpu_if->vgic_ap0r[3] = read_gicreg(ICH_AP0R3_EL2);
>> -		cpu_if->vgic_ap0r[2] = read_gicreg(ICH_AP0R2_EL2);
>> -	case 6:
>> -		cpu_if->vgic_ap0r[1] = read_gicreg(ICH_AP0R1_EL2);
>> -	default:
>> -		cpu_if->vgic_ap0r[0] = read_gicreg(ICH_AP0R0_EL2);
>> -	}
>> +		write_gicreg(0, ICH_HCR_EL2);
>> +		val = read_gicreg(ICH_VTR_EL2);
> 
> can't we cache the read of ICH_VTR_EL2 then?

We can (this is an invariant anyway). I don't expect it to be slow
though, as this doesn't have to go deep into the GIC, and stays at the
CPU level. I'll benchmark it anyway.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From lee.jones at linaro.org  Wed Feb 10 08:55:12 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 16:55:12 +0000
Subject: [PATCH v10 1/2] mfd: act8945a: add Active-semi ACT8945A PMIC MFD
 driver
In-Reply-To: <1454643390-16910-2-git-send-email-wenyou.yang@atmel.com>
References: <1454643390-16910-1-git-send-email-wenyou.yang@atmel.com>
 <1454643390-16910-2-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20160210165512.GP3782@x1>

On Fri, 05 Feb 2016, Wenyou Yang wrote:

> This patch adds support for the Active-semi ACT8945A PMIC.
> It is a Multi Function Device with the following subdevices:
>  - Regulator
>  - Charger
> 
> It is interfaced to the host controller using I2C interface,
> ACT8945A is a child device of the I2C.
> 
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> Acked-by: Lee Jones <lee.jones at linaro.org>
> Acked-by: Peter Korsgaard <peter at korsgaard.com>
> ---
> 
> Changes in v10:
>  - remove the mfd cell .of_compatible.

v9 unapplied, v10 applied.

> Changes in v9:
>  - remove unneeded struct act8945a_dev structure.
>  - collect Acked from Lee.
>  - collect Acked from Peter.
> 
> Changes in v8:
>  - change the subdevice's name "act8945a-pmic" to "act8945a-regulator".
> 
> Changes in v7:
>  - remove struct act8945a_dev to .c file.
>  - remove unused .h file.
> 
> Changes in v6:
>  - change MFD_ACT8945A type from bool to tristate.
>  - revert depends on to 'I2C'.
> 
> Changes in v5:
>  - change depends on to 'I2C=y'.
> 
> Changes in v4:
>  - add a space before .compatible.
>  - collect Reviewed-by from Krzysztof Kozlowski.
> 
> Changes in v3: None
> Changes in v2:
>  - add more help information in Kconfig.
>  - update the file header with short version license and author line.
>  - remove unused structure members (dev, i2c_client) of stuct act8945a_dev.
>  - use define "PLATFORM_DEVID_NONE" for mfd_add_devices(), instead of '-1'.
>  - use more explicit info to indicate the failure to add sub devices.
>  - remove the unnecessary print out.
>  - substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").
> 
>  drivers/mfd/Kconfig    |   11 ++++++
>  drivers/mfd/Makefile   |    1 +
>  drivers/mfd/act8945a.c |  102 ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 114 insertions(+)
>  create mode 100644 drivers/mfd/act8945a.c
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 6c4ebd9..38994bb 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -18,6 +18,17 @@ config MFD_CS5535
>  	  This is the core driver for CS5535/CS5536 MFD functions.  This is
>            necessary for using the board's GPIO and MFGPT functionality.
>  
> +config MFD_ACT8945A
> +	tristate "Active-semi ACT8945A"
> +	select MFD_CORE
> +	select REGMAP_I2C
> +	depends on I2C && OF
> +	help
> +	  Support for the ACT8945A PMIC from Active-semi. This device
> +	  features three step-down DC/DC converters and four low-dropout
> +	  linear regulators, along with a complete ActivePath battery
> +	  charger.
> +
>  config MFD_AS3711
>  	bool "AMS AS3711"
>  	select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 0f230a6..2f1ca82 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -6,6 +6,7 @@
>  obj-$(CONFIG_MFD_88PM860X)	+= 88pm860x.o
>  obj-$(CONFIG_MFD_88PM800)	+= 88pm800.o 88pm80x.o
>  obj-$(CONFIG_MFD_88PM805)	+= 88pm805.o 88pm80x.o
> +obj-$(CONFIG_MFD_ACT8945A)	+= act8945a.o
>  obj-$(CONFIG_MFD_SM501)		+= sm501.o
>  obj-$(CONFIG_MFD_ASIC3)		+= asic3.o tmio_core.o
>  obj-$(CONFIG_MFD_BCM590XX)	+= bcm590xx.o
> diff --git a/drivers/mfd/act8945a.c b/drivers/mfd/act8945a.c
> new file mode 100644
> index 0000000..525b546
> --- /dev/null
> +++ b/drivers/mfd/act8945a.c
> @@ -0,0 +1,102 @@
> +/*
> + * MFD driver for Active-semi ACT8945a PMIC
> + *
> + * Copyright (C) 2015 Atmel Corporation.
> + *
> + * Author: Wenyou Yang <wenyou.yang at atmel.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under  the terms of the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/mfd/core.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/regmap.h>
> +
> +static const struct mfd_cell act8945a_devs[] = {
> +	{
> +		.name = "act8945a-regulator",
> +	},
> +	{
> +		.name = "act8945a-charger",
> +	},
> +};
> +
> +static const struct regmap_config act8945a_regmap_config = {
> +	.reg_bits = 8,
> +	.val_bits = 8,
> +};
> +
> +static int act8945a_i2c_probe(struct i2c_client *i2c,
> +			      const struct i2c_device_id *id)
> +{
> +	int ret;
> +	struct regmap *regmap;
> +
> +	regmap = devm_regmap_init_i2c(i2c, &act8945a_regmap_config);
> +	if (IS_ERR(regmap)) {
> +		ret = PTR_ERR(regmap);
> +		dev_err(&i2c->dev, "regmap init failed: %d\n", ret);
> +		return ret;
> +	}
> +
> +	i2c_set_clientdata(i2c, regmap);
> +
> +	ret = mfd_add_devices(&i2c->dev, PLATFORM_DEVID_NONE, act8945a_devs,
> +			      ARRAY_SIZE(act8945a_devs), NULL, 0, NULL);
> +	if (ret) {
> +		dev_err(&i2c->dev, "Failed to add sub devices\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int act8945a_i2c_remove(struct i2c_client *i2c)
> +{
> +	mfd_remove_devices(&i2c->dev);
> +
> +	return 0;
> +}
> +
> +static const struct i2c_device_id act8945a_i2c_id[] = {
> +	{ "act8945a", 0 },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(i2c, act8945a_i2c_id);
> +
> +static const struct of_device_id act8945a_of_match[] = {
> +	{ .compatible = "active-semi,act8945a", },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, act8945a_of_match);
> +
> +static struct i2c_driver act8945a_i2c_driver = {
> +	.driver = {
> +		   .name = "act8945a",
> +		   .of_match_table = of_match_ptr(act8945a_of_match),
> +	},
> +	.probe = act8945a_i2c_probe,
> +	.remove = act8945a_i2c_remove,
> +	.id_table = act8945a_i2c_id,
> +};
> +
> +static int __init act8945a_i2c_init(void)
> +{
> +	return i2c_add_driver(&act8945a_i2c_driver);
> +}
> +subsys_initcall(act8945a_i2c_init);
> +
> +static void __exit act8945a_i2c_exit(void)
> +{
> +	i2c_del_driver(&act8945a_i2c_driver);
> +}
> +module_exit(act8945a_i2c_exit);
> +
> +MODULE_DESCRIPTION("ACT8945A PMIC multi-function driver");
> +MODULE_AUTHOR("Wenyou Yang <wenyou.yang at atmel.com>");
> +MODULE_LICENSE("GPL");

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Wed Feb 10 08:55:24 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 16:55:24 +0000
Subject: [PATCH v10 2/2] mfd: add documentation for ACT8945A DT bindings
In-Reply-To: <1454643390-16910-3-git-send-email-wenyou.yang@atmel.com>
References: <1454643390-16910-1-git-send-email-wenyou.yang@atmel.com>
 <1454643390-16910-3-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20160210165524.GQ3782@x1>

On Fri, 05 Feb 2016, Wenyou Yang wrote:

> The Active-semi ACT8945A PMIC is a Multi-Function Device, it has
> two subdevices:
>  - Regulator
>  - Charger
> 
> This patch adds documentation for ACT8945A DT bindings.
> 
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> Acked-by: Rob Herring <robh at kernel.org>
> Acked-by: Lee Jones <lee.jones at linaro.org>
> ---
> 
> Changes in v10:
>  - update the example, due to the subdevices are not regarded as
>    a child node.

v9 unapplied, v10 applied.

> Changes in v9: None
> Changes in v8: None
> Changes in v7:
>  - collect Acked-by from Lee Jones
> 
> Changes in v6:
>  - change the regulator name.
> 
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
>  - fix the tabbing errors in Example.
>  - use "pmic at 5b" label, not "act8945a at 5b" in Example.
>  - collect Acked-by from Rob.
> 
> Changes in v2:
>  - use more specific label in Example.
>  - add pmic and charger nodes in Example.
> 
>  Documentation/devicetree/bindings/mfd/act8945a.txt |   76 ++++++++++++++++++++
>  1 file changed, 76 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/act8945a.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/act8945a.txt b/Documentation/devicetree/bindings/mfd/act8945a.txt
> new file mode 100644
> index 0000000..f712830
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/act8945a.txt
> @@ -0,0 +1,76 @@
> +Device-Tree bindings for Active-semi ACT8945A MFD driver
> +
> +Required properties:
> + - compatible: "active-semi,act8945a".
> + - reg: the I2C slave address for the ACT8945A chip
> +
> +The chip exposes two subdevices:
> + - a regulators: see ../regulator/act8945a-regulator.txt
> + - a charger: see ../power/act8945a-charger.txt
> +
> +Example:
> +	pmic at 5b {
> +		compatible = "active-semi,act8945a";
> +		reg = <0x5b>;
> +		status = "okay";
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_charger_chglev>;
> +		active-semi,chglev-gpio = <&pioA 12 GPIO_ACTIVE_HIGH>;
> +		active-semi,input-voltage-threshold-microvolt = <6600>;
> +		active-semi,precondition-timeout = <40>;
> +		active-semi,total-timeout = <3>;
> +
> +		active-semi,vsel-high;
> +
> +		regulators {
> +			vdd_1v35_reg: REG_DCDC1 {
> +				regulator-name = "VDD_1V35";
> +				regulator-min-microvolt = <1350000>;
> +				regulator-max-microvolt = <1350000>;
> +				regulator-always-on;
> +			};
> +
> +			vdd_1v2_reg: REG_DCDC2 {
> +				regulator-name = "VDD_1V2";
> +				regulator-min-microvolt = <1100000>;
> +				regulator-max-microvolt = <1300000>;
> +				regulator-always-on;
> +			};
> +
> +			vdd_3v3_reg: REG_DCDC3 {
> +				regulator-name = "VDD_3V3";
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-always-on;
> +			};
> +
> +			vdd_fuse_reg: REG_LDO1 {
> +				regulator-name = "VDD_FUSE";
> +				regulator-min-microvolt = <2500000>;
> +				regulator-max-microvolt = <2500000>;
> +				regulator-always-on;
> +			};
> +
> +			vdd_3v3_lp_reg: REG_LDO2 {
> +				regulator-name = "VDD_3V3_LP";
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-always-on;
> +			};
> +
> +			vdd_led_reg: REG_LDO3 {
> +				regulator-name = "VDD_LED";
> +				regulator-min-microvolt = <3300000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-always-on;
> +			};
> +
> +			vdd_sdhc_1v8_reg: REG_LDO4 {
> +				regulator-name = "VDD_SDHC_1V8";
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <1800000>;
> +				regulator-always-on;
> +			};
> +		};
> +	};

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Wed Feb 10 08:58:56 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 16:58:56 +0000
Subject: [PATCH V3 1/4] dt-bindings: mfd: Add bindings for the MediaTek
 MT6323 PMIC
In-Reply-To: <1453895258-44369-1-git-send-email-blogic@openwrt.org>
References: <1453895258-44369-1-git-send-email-blogic@openwrt.org>
Message-ID: <20160210165856.GS3782@x1>

On Wed, 27 Jan 2016, John Crispin wrote:

> Signed-off-by: John Crispin <blogic at openwrt.org>
> Cc: devicetree at vger.kernel.org
> ---
>  Documentation/devicetree/bindings/mfd/mt6397.txt |   10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)

Applied, thanks.

> diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt
> index 15043e6..949c85f 100644
> --- a/Documentation/devicetree/bindings/mfd/mt6397.txt
> +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
> @@ -1,6 +1,6 @@
> -MediaTek MT6397 Multifunction Device Driver
> +MediaTek MT6397/MT6323 Multifunction Device Driver
>  
> -MT6397 is a multifunction device with the following sub modules:
> +MT6397/MT6323 is a multifunction device with the following sub modules:
>  - Regulator
>  - RTC
>  - Audio codec
> @@ -8,14 +8,14 @@ MT6397 is a multifunction device with the following sub modules:
>  - Clock
>  
>  It is interfaced to host controller using SPI interface by a proprietary hardware
> -called PMIC wrapper or pwrap. MT6397 MFD is a child device of pwrap.
> +called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap.
>  See the following for pwarp node definitions:
>  Documentation/devicetree/bindings/soc/pwrap.txt
>  
>  This document describes the binding for MFD device and its sub module.
>  
>  Required properties:
> -compatible: "mediatek,mt6397"
> +compatible: "mediatek,mt6397" or "mediatek,mt6323"
>  
>  Optional subnodes:
>  
> @@ -26,6 +26,8 @@ Optional subnodes:
>  	Required properties:
>  		- compatible: "mediatek,mt6397-regulator"
>  	see Documentation/devicetree/bindings/regulator/mt6397-regulator.txt
> +		- compatible: "mediatek,mt6323-regulator"
> +	see Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
>  - codec
>  	Required properties:
>  		- compatible: "mediatek,mt6397-codec"

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Wed Feb 10 08:59:07 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 16:59:07 +0000
Subject: [PATCH V3 2/4] mfd: mt6397: int_con and int_status may vary in
 location
In-Reply-To: <1453895258-44369-2-git-send-email-blogic@openwrt.org>
References: <1453895258-44369-1-git-send-email-blogic@openwrt.org>
 <1453895258-44369-2-git-send-email-blogic@openwrt.org>
Message-ID: <20160210165907.GT3782@x1>

On Wed, 27 Jan 2016, John Crispin wrote:

> MT6323 has the INT_CON and INT_STATUS located at a different position.
> Make the registers locations configurable.
> 
> Signed-off-by: John Crispin <blogic at openwrt.org>
> ---
>  drivers/mfd/mt6397-core.c       |   27 +++++++++++++++++----------
>  include/linux/mfd/mt6397/core.h |    2 ++
>  2 files changed, 19 insertions(+), 10 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index 1749c1c..75ad0fe 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -69,8 +69,10 @@ static void mt6397_irq_sync_unlock(struct irq_data *data)
>  {
>  	struct mt6397_chip *mt6397 = irq_data_get_irq_chip_data(data);
>  
> -	regmap_write(mt6397->regmap, MT6397_INT_CON0, mt6397->irq_masks_cur[0]);
> -	regmap_write(mt6397->regmap, MT6397_INT_CON1, mt6397->irq_masks_cur[1]);
> +	regmap_write(mt6397->regmap, mt6397->int_con[0],
> +		     mt6397->irq_masks_cur[0]);
> +	regmap_write(mt6397->regmap, mt6397->int_con[1],
> +		     mt6397->irq_masks_cur[1]);
>  
>  	mutex_unlock(&mt6397->irqlock);
>  }
> @@ -147,8 +149,8 @@ static irqreturn_t mt6397_irq_thread(int irq, void *data)
>  {
>  	struct mt6397_chip *mt6397 = data;
>  
> -	mt6397_irq_handle_reg(mt6397, MT6397_INT_STATUS0, 0);
> -	mt6397_irq_handle_reg(mt6397, MT6397_INT_STATUS1, 16);
> +	mt6397_irq_handle_reg(mt6397, mt6397->int_status[0], 0);
> +	mt6397_irq_handle_reg(mt6397, mt6397->int_status[1], 16);
>  
>  	return IRQ_HANDLED;
>  }
> @@ -177,8 +179,8 @@ static int mt6397_irq_init(struct mt6397_chip *mt6397)
>  	mutex_init(&mt6397->irqlock);
>  
>  	/* Mask all interrupt sources */
> -	regmap_write(mt6397->regmap, MT6397_INT_CON0, 0x0);
> -	regmap_write(mt6397->regmap, MT6397_INT_CON1, 0x0);
> +	regmap_write(mt6397->regmap, mt6397->int_con[0], 0x0);
> +	regmap_write(mt6397->regmap, mt6397->int_con[1], 0x0);
>  
>  	mt6397->irq_domain = irq_domain_add_linear(mt6397->dev->of_node,
>  		MT6397_IRQ_NR, &mt6397_irq_domain_ops, mt6397);
> @@ -203,8 +205,8 @@ static int mt6397_irq_suspend(struct device *dev)
>  {
>  	struct mt6397_chip *chip = dev_get_drvdata(dev);
>  
> -	regmap_write(chip->regmap, MT6397_INT_CON0, chip->wake_mask[0]);
> -	regmap_write(chip->regmap, MT6397_INT_CON1, chip->wake_mask[1]);
> +	regmap_write(chip->regmap, chip->int_con[0], chip->wake_mask[0]);
> +	regmap_write(chip->regmap, chip->int_con[1], chip->wake_mask[1]);
>  
>  	enable_irq_wake(chip->irq);
>  
> @@ -215,8 +217,8 @@ static int mt6397_irq_resume(struct device *dev)
>  {
>  	struct mt6397_chip *chip = dev_get_drvdata(dev);
>  
> -	regmap_write(chip->regmap, MT6397_INT_CON0, chip->irq_masks_cur[0]);
> -	regmap_write(chip->regmap, MT6397_INT_CON1, chip->irq_masks_cur[1]);
> +	regmap_write(chip->regmap, chip->int_con[0], chip->irq_masks_cur[0]);
> +	regmap_write(chip->regmap, chip->int_con[1], chip->irq_masks_cur[1]);
>  
>  	disable_irq_wake(chip->irq);
>  
> @@ -237,6 +239,11 @@ static int mt6397_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  
>  	mt6397->dev = &pdev->dev;
> +	mt6397->int_con[0] = MT6397_INT_CON0;
> +	mt6397->int_con[1] = MT6397_INT_CON1;
> +	mt6397->int_status[0] = MT6397_INT_STATUS0;
> +	mt6397->int_status[1] = MT6397_INT_STATUS1;
> +
>  	/*
>  	 * mt6397 MFD is child device of soc pmic wrapper.
>  	 * Regmap is set from its parent.
> diff --git a/include/linux/mfd/mt6397/core.h b/include/linux/mfd/mt6397/core.h
> index 45b8e8a..d678f52 100644
> --- a/include/linux/mfd/mt6397/core.h
> +++ b/include/linux/mfd/mt6397/core.h
> @@ -60,6 +60,8 @@ struct mt6397_chip {
>  	u16 wake_mask[2];
>  	u16 irq_masks_cur[2];
>  	u16 irq_masks_cache[2];
> +	u16 int_con[2];
> +	u16 int_status[2];
>  };
>  
>  #endif /* __MFD_MT6397_CORE_H__ */

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Wed Feb 10 08:59:19 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 16:59:19 +0000
Subject: [PATCH V3 3/4] mfd: mt6397: add support for different Slave types
In-Reply-To: <1453895258-44369-3-git-send-email-blogic@openwrt.org>
References: <1453895258-44369-1-git-send-email-blogic@openwrt.org>
 <1453895258-44369-3-git-send-email-blogic@openwrt.org>
Message-ID: <20160210165919.GU3782@x1>

On Wed, 27 Jan 2016, John Crispin wrote:

> Signed-off-by: John Crispin <blogic at openwrt.org>
> ---
>  drivers/mfd/mt6397-core.c |   58 ++++++++++++++++++++++++++++++++-------------
>  1 file changed, 41 insertions(+), 17 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index 75ad0fe..aa91606 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -24,6 +24,9 @@
>  #define MT6397_RTC_BASE		0xe000
>  #define MT6397_RTC_SIZE		0x3e
>  
> +#define MT6391_CID_CODE		0x91
> +#define MT6397_CID_CODE		0x97
> +
>  static const struct resource mt6397_rtc_resources[] = {
>  	{
>  		.start = MT6397_RTC_BASE,
> @@ -232,39 +235,60 @@ static SIMPLE_DEV_PM_OPS(mt6397_pm_ops, mt6397_irq_suspend,
>  static int mt6397_probe(struct platform_device *pdev)
>  {
>  	int ret;
> -	struct mt6397_chip *mt6397;
> +	unsigned int id;
> +	struct mt6397_chip *pmic;
>  
> -	mt6397 = devm_kzalloc(&pdev->dev, sizeof(*mt6397), GFP_KERNEL);
> -	if (!mt6397)
> +	pmic = devm_kzalloc(&pdev->dev, sizeof(*pmic), GFP_KERNEL);
> +	if (!pmic)
>  		return -ENOMEM;
>  
> -	mt6397->dev = &pdev->dev;
> -	mt6397->int_con[0] = MT6397_INT_CON0;
> -	mt6397->int_con[1] = MT6397_INT_CON1;
> -	mt6397->int_status[0] = MT6397_INT_STATUS0;
> -	mt6397->int_status[1] = MT6397_INT_STATUS1;
> +	pmic->dev = &pdev->dev;
>  
>  	/*
>  	 * mt6397 MFD is child device of soc pmic wrapper.
>  	 * Regmap is set from its parent.
>  	 */
> -	mt6397->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> -	if (!mt6397->regmap)
> +	pmic->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> +	if (!pmic->regmap)
>  		return -ENODEV;
>  
> -	platform_set_drvdata(pdev, mt6397);
> +	platform_set_drvdata(pdev, pmic);
> +
> +	ret = regmap_read(pmic->regmap, MT6397_CID, &id);
> +	if (ret) {
> +		dev_err(pmic->dev, "Failed to read chip id: %d\n", ret);
> +		goto fail_irq;
> +	}
> +
> +	switch (id & 0xff) {
> +	case MT6397_CID_CODE:
> +	case MT6391_CID_CODE:
> +		pmic->int_con[0] = MT6397_INT_CON0;
> +		pmic->int_con[1] = MT6397_INT_CON1;
> +		pmic->int_status[0] = MT6397_INT_STATUS0;
> +		pmic->int_status[1] = MT6397_INT_STATUS1;
> +		ret = mfd_add_devices(&pdev->dev, -1, mt6397_devs,
> +				ARRAY_SIZE(mt6397_devs), NULL, 0, NULL);
> +		break;
> +
> +	default:
> +		dev_err(&pdev->dev, "unsupported chip: %d\n", id);
> +		ret = -ENODEV;
> +		break;
> +	}
>  
> -	mt6397->irq = platform_get_irq(pdev, 0);
> -	if (mt6397->irq > 0) {
> -		ret = mt6397_irq_init(mt6397);
> +	pmic->irq = platform_get_irq(pdev, 0);
> +	if (pmic->irq > 0) {
> +		ret = mt6397_irq_init(pmic);
>  		if (ret)
>  			return ret;
>  	}
>  
> -	ret = mfd_add_devices(&pdev->dev, -1, mt6397_devs,
> -			ARRAY_SIZE(mt6397_devs), NULL, 0, NULL);
> -	if (ret)
> +fail_irq:
> +	if (ret) {
> +		irq_domain_remove(pmic->irq_domain);
>  		dev_err(&pdev->dev, "failed to add child devices: %d\n", ret);
> +	}
>  
>  	return ret;
>  }

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Wed Feb 10 08:59:32 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 16:59:32 +0000
Subject: [PATCH V3 4/4] mfd: mt6397: add MT6323 support to MT6397 driver
In-Reply-To: <1453895258-44369-4-git-send-email-blogic@openwrt.org>
References: <1453895258-44369-1-git-send-email-blogic@openwrt.org>
 <1453895258-44369-4-git-send-email-blogic@openwrt.org>
Message-ID: <20160210165932.GV3782@x1>

On Wed, 27 Jan 2016, John Crispin wrote:

> Signed-off-by: John Crispin <blogic at openwrt.org>
> ---
> Changes in V3
> * fix copyright date/author
> * use short license text
> * reanme the conetxt variable inside the probe function
> 
>  drivers/mfd/mt6397-core.c            |   20 ++
>  include/linux/mfd/mt6323/core.h      |   36 +++
>  include/linux/mfd/mt6323/registers.h |  408 ++++++++++++++++++++++++++++++++++
>  3 files changed, 464 insertions(+)
>  create mode 100644 include/linux/mfd/mt6323/core.h
>  create mode 100644 include/linux/mfd/mt6323/registers.h

Applied, thanks.

> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index aa91606..8234cd3 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -19,11 +19,14 @@
>  #include <linux/regmap.h>
>  #include <linux/mfd/core.h>
>  #include <linux/mfd/mt6397/core.h>
> +#include <linux/mfd/mt6323/core.h>
>  #include <linux/mfd/mt6397/registers.h>
> +#include <linux/mfd/mt6323/registers.h>
>  
>  #define MT6397_RTC_BASE		0xe000
>  #define MT6397_RTC_SIZE		0x3e
>  
> +#define MT6323_CID_CODE		0x23
>  #define MT6391_CID_CODE		0x91
>  #define MT6397_CID_CODE		0x97
>  
> @@ -40,6 +43,13 @@ static const struct resource mt6397_rtc_resources[] = {
>  	},
>  };
>  
> +static const struct mfd_cell mt6323_devs[] = {
> +	{
> +		.name = "mt6323-regulator",
> +		.of_compatible = "mediatek,mt6323-regulator"
> +	},
> +};
> +
>  static const struct mfd_cell mt6397_devs[] = {
>  	{
>  		.name = "mt6397-rtc",
> @@ -261,6 +271,15 @@ static int mt6397_probe(struct platform_device *pdev)
>  	}
>  
>  	switch (id & 0xff) {
> +	case MT6323_CID_CODE:
> +		pmic->int_con[0] = MT6323_INT_CON0;
> +		pmic->int_con[1] = MT6323_INT_CON1;
> +		pmic->int_status[0] = MT6323_INT_STATUS0;
> +		pmic->int_status[1] = MT6323_INT_STATUS1;
> +		ret = mfd_add_devices(&pdev->dev, -1, mt6323_devs,
> +				ARRAY_SIZE(mt6323_devs), NULL, 0, NULL);
> +		break;
> +
>  	case MT6397_CID_CODE:
>  	case MT6391_CID_CODE:
>  		pmic->int_con[0] = MT6397_INT_CON0;
> @@ -302,6 +321,7 @@ static int mt6397_remove(struct platform_device *pdev)
>  
>  static const struct of_device_id mt6397_of_match[] = {
>  	{ .compatible = "mediatek,mt6397" },
> +	{ .compatible = "mediatek,mt6323" },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(of, mt6397_of_match);
> diff --git a/include/linux/mfd/mt6323/core.h b/include/linux/mfd/mt6323/core.h
> new file mode 100644
> index 0000000..06d0ec3
> --- /dev/null
> +++ b/include/linux/mfd/mt6323/core.h
> @@ -0,0 +1,36 @@
> +/*
> + * Copyright (c) 2016 Chen Zhong <chen.zhong at mediatek.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.
> + */
> +
> +#ifndef __MFD_MT6323_CORE_H__
> +#define __MFD_MT6323_CORE_H__
> +
> +enum MT6323_IRQ_STATUS_numbers {
> +	MT6323_IRQ_STATUS_SPKL_AB = 0,
> +	MT6323_IRQ_STATUS_SPKL,
> +	MT6323_IRQ_STATUS_BAT_L,
> +	MT6323_IRQ_STATUS_BAT_H,
> +	MT6323_IRQ_STATUS_WATCHDOG,
> +	MT6323_IRQ_STATUS_PWRKEY,
> +	MT6323_IRQ_STATUS_THR_L,
> +	MT6323_IRQ_STATUS_THR_H,
> +	MT6323_IRQ_STATUS_VBATON_UNDET,
> +	MT6323_IRQ_STATUS_BVALID_DET,
> +	MT6323_IRQ_STATUS_CHRDET,
> +	MT6323_IRQ_STATUS_OV,
> +	MT6323_IRQ_STATUS_LDO = 16,
> +	MT6323_IRQ_STATUS_FCHRKEY,
> +	MT6323_IRQ_STATUS_ACCDET,
> +	MT6323_IRQ_STATUS_AUDIO,
> +	MT6323_IRQ_STATUS_RTC,
> +	MT6323_IRQ_STATUS_VPROC,
> +	MT6323_IRQ_STATUS_VSYS,
> +	MT6323_IRQ_STATUS_VPA,
> +	MT6323_IRQ_STATUS_NR,
> +};
> +
> +#endif /* __MFD_MT6323_CORE_H__ */
> diff --git a/include/linux/mfd/mt6323/registers.h b/include/linux/mfd/mt6323/registers.h
> new file mode 100644
> index 0000000..160f3c0
> --- /dev/null
> +++ b/include/linux/mfd/mt6323/registers.h
> @@ -0,0 +1,408 @@
> +/*
> + * Copyright (c) 2016 Chen Zhong <chen.zhong at mediatek.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.
> + */
> +
> +#ifndef __MFD_MT6323_REGISTERS_H__
> +#define __MFD_MT6323_REGISTERS_H__
> +
> +/* PMIC Registers */
> +#define MT6323_CHR_CON0           0x0000
> +#define MT6323_CHR_CON1           0x0002
> +#define MT6323_CHR_CON2           0x0004
> +#define MT6323_CHR_CON3           0x0006
> +#define MT6323_CHR_CON4           0x0008
> +#define MT6323_CHR_CON5           0x000A
> +#define MT6323_CHR_CON6           0x000C
> +#define MT6323_CHR_CON7           0x000E
> +#define MT6323_CHR_CON8           0x0010
> +#define MT6323_CHR_CON9           0x0012
> +#define MT6323_CHR_CON10          0x0014
> +#define MT6323_CHR_CON11          0x0016
> +#define MT6323_CHR_CON12          0x0018
> +#define MT6323_CHR_CON13          0x001A
> +#define MT6323_CHR_CON14          0x001C
> +#define MT6323_CHR_CON15          0x001E
> +#define MT6323_CHR_CON16          0x0020
> +#define MT6323_CHR_CON17          0x0022
> +#define MT6323_CHR_CON18          0x0024
> +#define MT6323_CHR_CON19          0x0026
> +#define MT6323_CHR_CON20          0x0028
> +#define MT6323_CHR_CON21          0x002A
> +#define MT6323_CHR_CON22          0x002C
> +#define MT6323_CHR_CON23          0x002E
> +#define MT6323_CHR_CON24          0x0030
> +#define MT6323_CHR_CON25          0x0032
> +#define MT6323_CHR_CON26          0x0034
> +#define MT6323_CHR_CON27          0x0036
> +#define MT6323_CHR_CON28          0x0038
> +#define MT6323_CHR_CON29          0x003A
> +#define MT6323_STRUP_CON0         0x003C
> +#define MT6323_STRUP_CON2         0x003E
> +#define MT6323_STRUP_CON3         0x0040
> +#define MT6323_STRUP_CON4         0x0042
> +#define MT6323_STRUP_CON5         0x0044
> +#define MT6323_STRUP_CON6         0x0046
> +#define MT6323_STRUP_CON7         0x0048
> +#define MT6323_STRUP_CON8         0x004A
> +#define MT6323_STRUP_CON9         0x004C
> +#define MT6323_STRUP_CON10        0x004E
> +#define MT6323_STRUP_CON11        0x0050
> +#define MT6323_SPK_CON0           0x0052
> +#define MT6323_SPK_CON1           0x0054
> +#define MT6323_SPK_CON2           0x0056
> +#define MT6323_SPK_CON6           0x005E
> +#define MT6323_SPK_CON7           0x0060
> +#define MT6323_SPK_CON8           0x0062
> +#define MT6323_SPK_CON9           0x0064
> +#define MT6323_SPK_CON10          0x0066
> +#define MT6323_SPK_CON11          0x0068
> +#define MT6323_SPK_CON12          0x006A
> +#define MT6323_CID                0x0100
> +#define MT6323_TOP_CKPDN0         0x0102
> +#define MT6323_TOP_CKPDN0_SET     0x0104
> +#define MT6323_TOP_CKPDN0_CLR     0x0106
> +#define MT6323_TOP_CKPDN1         0x0108
> +#define MT6323_TOP_CKPDN1_SET     0x010A
> +#define MT6323_TOP_CKPDN1_CLR     0x010C
> +#define MT6323_TOP_CKPDN2         0x010E
> +#define MT6323_TOP_CKPDN2_SET     0x0110
> +#define MT6323_TOP_CKPDN2_CLR     0x0112
> +#define MT6323_TOP_RST_CON        0x0114
> +#define MT6323_TOP_RST_CON_SET    0x0116
> +#define MT6323_TOP_RST_CON_CLR    0x0118
> +#define MT6323_TOP_RST_MISC       0x011A
> +#define MT6323_TOP_RST_MISC_SET   0x011C
> +#define MT6323_TOP_RST_MISC_CLR   0x011E
> +#define MT6323_TOP_CKCON0         0x0120
> +#define MT6323_TOP_CKCON0_SET     0x0122
> +#define MT6323_TOP_CKCON0_CLR     0x0124
> +#define MT6323_TOP_CKCON1         0x0126
> +#define MT6323_TOP_CKCON1_SET     0x0128
> +#define MT6323_TOP_CKCON1_CLR     0x012A
> +#define MT6323_TOP_CKTST0         0x012C
> +#define MT6323_TOP_CKTST1         0x012E
> +#define MT6323_TOP_CKTST2         0x0130
> +#define MT6323_TEST_OUT           0x0132
> +#define MT6323_TEST_CON0          0x0134
> +#define MT6323_TEST_CON1          0x0136
> +#define MT6323_EN_STATUS0         0x0138
> +#define MT6323_EN_STATUS1         0x013A
> +#define MT6323_OCSTATUS0          0x013C
> +#define MT6323_OCSTATUS1          0x013E
> +#define MT6323_PGSTATUS           0x0140
> +#define MT6323_CHRSTATUS          0x0142
> +#define MT6323_TDSEL_CON          0x0144
> +#define MT6323_RDSEL_CON          0x0146
> +#define MT6323_SMT_CON0           0x0148
> +#define MT6323_SMT_CON1           0x014A
> +#define MT6323_SMT_CON2           0x014C
> +#define MT6323_SMT_CON3           0x014E
> +#define MT6323_SMT_CON4           0x0150
> +#define MT6323_DRV_CON0           0x0152
> +#define MT6323_DRV_CON1           0x0154
> +#define MT6323_DRV_CON2           0x0156
> +#define MT6323_DRV_CON3           0x0158
> +#define MT6323_DRV_CON4           0x015A
> +#define MT6323_SIMLS1_CON         0x015C
> +#define MT6323_SIMLS2_CON         0x015E
> +#define MT6323_INT_CON0           0x0160
> +#define MT6323_INT_CON0_SET       0x0162
> +#define MT6323_INT_CON0_CLR       0x0164
> +#define MT6323_INT_CON1           0x0166
> +#define MT6323_INT_CON1_SET       0x0168
> +#define MT6323_INT_CON1_CLR       0x016A
> +#define MT6323_INT_MISC_CON       0x016C
> +#define MT6323_INT_MISC_CON_SET   0x016E
> +#define MT6323_INT_MISC_CON_CLR   0x0170
> +#define MT6323_INT_STATUS0        0x0172
> +#define MT6323_INT_STATUS1        0x0174
> +#define MT6323_OC_GEAR_0          0x0176
> +#define MT6323_OC_GEAR_1          0x0178
> +#define MT6323_OC_GEAR_2          0x017A
> +#define MT6323_OC_CTL_VPROC       0x017C
> +#define MT6323_OC_CTL_VSYS        0x017E
> +#define MT6323_OC_CTL_VPA         0x0180
> +#define MT6323_FQMTR_CON0         0x0182
> +#define MT6323_FQMTR_CON1         0x0184
> +#define MT6323_FQMTR_CON2         0x0186
> +#define MT6323_RG_SPI_CON         0x0188
> +#define MT6323_DEW_DIO_EN         0x018A
> +#define MT6323_DEW_READ_TEST      0x018C
> +#define MT6323_DEW_WRITE_TEST     0x018E
> +#define MT6323_DEW_CRC_SWRST      0x0190
> +#define MT6323_DEW_CRC_EN         0x0192
> +#define MT6323_DEW_CRC_VAL        0x0194
> +#define MT6323_DEW_DBG_MON_SEL    0x0196
> +#define MT6323_DEW_CIPHER_KEY_SEL 0x0198
> +#define MT6323_DEW_CIPHER_IV_SEL  0x019A
> +#define MT6323_DEW_CIPHER_EN      0x019C
> +#define MT6323_DEW_CIPHER_RDY     0x019E
> +#define MT6323_DEW_CIPHER_MODE    0x01A0
> +#define MT6323_DEW_CIPHER_SWRST   0x01A2
> +#define MT6323_DEW_RDDMY_NO       0x01A4
> +#define MT6323_DEW_RDATA_DLY_SEL  0x01A6
> +#define MT6323_BUCK_CON0          0x0200
> +#define MT6323_BUCK_CON1          0x0202
> +#define MT6323_BUCK_CON2          0x0204
> +#define MT6323_BUCK_CON3          0x0206
> +#define MT6323_BUCK_CON4          0x0208
> +#define MT6323_BUCK_CON5          0x020A
> +#define MT6323_VPROC_CON0         0x020C
> +#define MT6323_VPROC_CON1         0x020E
> +#define MT6323_VPROC_CON2         0x0210
> +#define MT6323_VPROC_CON3         0x0212
> +#define MT6323_VPROC_CON4         0x0214
> +#define MT6323_VPROC_CON5         0x0216
> +#define MT6323_VPROC_CON7         0x021A
> +#define MT6323_VPROC_CON8         0x021C
> +#define MT6323_VPROC_CON9         0x021E
> +#define MT6323_VPROC_CON10        0x0220
> +#define MT6323_VPROC_CON11        0x0222
> +#define MT6323_VPROC_CON12        0x0224
> +#define MT6323_VPROC_CON13        0x0226
> +#define MT6323_VPROC_CON14        0x0228
> +#define MT6323_VPROC_CON15        0x022A
> +#define MT6323_VPROC_CON18        0x0230
> +#define MT6323_VSYS_CON0          0x0232
> +#define MT6323_VSYS_CON1          0x0234
> +#define MT6323_VSYS_CON2          0x0236
> +#define MT6323_VSYS_CON3          0x0238
> +#define MT6323_VSYS_CON4          0x023A
> +#define MT6323_VSYS_CON5          0x023C
> +#define MT6323_VSYS_CON7          0x0240
> +#define MT6323_VSYS_CON8          0x0242
> +#define MT6323_VSYS_CON9          0x0244
> +#define MT6323_VSYS_CON10         0x0246
> +#define MT6323_VSYS_CON11         0x0248
> +#define MT6323_VSYS_CON12         0x024A
> +#define MT6323_VSYS_CON13         0x024C
> +#define MT6323_VSYS_CON14         0x024E
> +#define MT6323_VSYS_CON15         0x0250
> +#define MT6323_VSYS_CON18         0x0256
> +#define MT6323_VPA_CON0           0x0300
> +#define MT6323_VPA_CON1           0x0302
> +#define MT6323_VPA_CON2           0x0304
> +#define MT6323_VPA_CON3           0x0306
> +#define MT6323_VPA_CON4           0x0308
> +#define MT6323_VPA_CON5           0x030A
> +#define MT6323_VPA_CON7           0x030E
> +#define MT6323_VPA_CON8           0x0310
> +#define MT6323_VPA_CON9           0x0312
> +#define MT6323_VPA_CON10          0x0314
> +#define MT6323_VPA_CON11          0x0316
> +#define MT6323_VPA_CON12          0x0318
> +#define MT6323_VPA_CON14          0x031C
> +#define MT6323_VPA_CON16          0x0320
> +#define MT6323_VPA_CON17          0x0322
> +#define MT6323_VPA_CON18          0x0324
> +#define MT6323_VPA_CON19          0x0326
> +#define MT6323_VPA_CON20          0x0328
> +#define MT6323_BUCK_K_CON0        0x032A
> +#define MT6323_BUCK_K_CON1        0x032C
> +#define MT6323_BUCK_K_CON2        0x032E
> +#define MT6323_ISINK0_CON0        0x0330
> +#define MT6323_ISINK0_CON1        0x0332
> +#define MT6323_ISINK0_CON2        0x0334
> +#define MT6323_ISINK0_CON3        0x0336
> +#define MT6323_ISINK1_CON0        0x0338
> +#define MT6323_ISINK1_CON1        0x033A
> +#define MT6323_ISINK1_CON2        0x033C
> +#define MT6323_ISINK1_CON3        0x033E
> +#define MT6323_ISINK2_CON0        0x0340
> +#define MT6323_ISINK2_CON1        0x0342
> +#define MT6323_ISINK2_CON2        0x0344
> +#define MT6323_ISINK2_CON3        0x0346
> +#define MT6323_ISINK3_CON0        0x0348
> +#define MT6323_ISINK3_CON1        0x034A
> +#define MT6323_ISINK3_CON2        0x034C
> +#define MT6323_ISINK3_CON3        0x034E
> +#define MT6323_ISINK_ANA0         0x0350
> +#define MT6323_ISINK_ANA1         0x0352
> +#define MT6323_ISINK_PHASE_DLY    0x0354
> +#define MT6323_ISINK_EN_CTRL      0x0356
> +#define MT6323_ANALDO_CON0        0x0400
> +#define MT6323_ANALDO_CON1        0x0402
> +#define MT6323_ANALDO_CON2        0x0404
> +#define MT6323_ANALDO_CON3        0x0406
> +#define MT6323_ANALDO_CON4        0x0408
> +#define MT6323_ANALDO_CON5        0x040A
> +#define MT6323_ANALDO_CON6        0x040C
> +#define MT6323_ANALDO_CON7        0x040E
> +#define MT6323_ANALDO_CON8        0x0410
> +#define MT6323_ANALDO_CON10       0x0412
> +#define MT6323_ANALDO_CON15       0x0414
> +#define MT6323_ANALDO_CON16       0x0416
> +#define MT6323_ANALDO_CON17       0x0418
> +#define MT6323_ANALDO_CON18       0x041A
> +#define MT6323_ANALDO_CON19       0x041C
> +#define MT6323_ANALDO_CON20       0x041E
> +#define MT6323_ANALDO_CON21       0x0420
> +#define MT6323_DIGLDO_CON0        0x0500
> +#define MT6323_DIGLDO_CON2        0x0502
> +#define MT6323_DIGLDO_CON3        0x0504
> +#define MT6323_DIGLDO_CON5        0x0506
> +#define MT6323_DIGLDO_CON6        0x0508
> +#define MT6323_DIGLDO_CON7        0x050A
> +#define MT6323_DIGLDO_CON8        0x050C
> +#define MT6323_DIGLDO_CON9        0x050E
> +#define MT6323_DIGLDO_CON10       0x0510
> +#define MT6323_DIGLDO_CON11       0x0512
> +#define MT6323_DIGLDO_CON12       0x0514
> +#define MT6323_DIGLDO_CON13       0x0516
> +#define MT6323_DIGLDO_CON14       0x0518
> +#define MT6323_DIGLDO_CON15       0x051A
> +#define MT6323_DIGLDO_CON16       0x051C
> +#define MT6323_DIGLDO_CON17       0x051E
> +#define MT6323_DIGLDO_CON18       0x0520
> +#define MT6323_DIGLDO_CON19       0x0522
> +#define MT6323_DIGLDO_CON20       0x0524
> +#define MT6323_DIGLDO_CON21       0x0526
> +#define MT6323_DIGLDO_CON23       0x0528
> +#define MT6323_DIGLDO_CON24       0x052A
> +#define MT6323_DIGLDO_CON26       0x052C
> +#define MT6323_DIGLDO_CON27       0x052E
> +#define MT6323_DIGLDO_CON28       0x0530
> +#define MT6323_DIGLDO_CON29       0x0532
> +#define MT6323_DIGLDO_CON30       0x0534
> +#define MT6323_DIGLDO_CON31       0x0536
> +#define MT6323_DIGLDO_CON32       0x0538
> +#define MT6323_DIGLDO_CON33       0x053A
> +#define MT6323_DIGLDO_CON34       0x053C
> +#define MT6323_DIGLDO_CON35       0x053E
> +#define MT6323_DIGLDO_CON36       0x0540
> +#define MT6323_DIGLDO_CON39       0x0542
> +#define MT6323_DIGLDO_CON40       0x0544
> +#define MT6323_DIGLDO_CON41       0x0546
> +#define MT6323_DIGLDO_CON42       0x0548
> +#define MT6323_DIGLDO_CON43       0x054A
> +#define MT6323_DIGLDO_CON44       0x054C
> +#define MT6323_DIGLDO_CON45       0x054E
> +#define MT6323_DIGLDO_CON46       0x0550
> +#define MT6323_DIGLDO_CON47       0x0552
> +#define MT6323_DIGLDO_CON48       0x0554
> +#define MT6323_DIGLDO_CON49       0x0556
> +#define MT6323_DIGLDO_CON50       0x0558
> +#define MT6323_DIGLDO_CON51       0x055A
> +#define MT6323_DIGLDO_CON52       0x055C
> +#define MT6323_DIGLDO_CON53       0x055E
> +#define MT6323_DIGLDO_CON54       0x0560
> +#define MT6323_EFUSE_CON0         0x0600
> +#define MT6323_EFUSE_CON1         0x0602
> +#define MT6323_EFUSE_CON2         0x0604
> +#define MT6323_EFUSE_CON3         0x0606
> +#define MT6323_EFUSE_CON4         0x0608
> +#define MT6323_EFUSE_CON5         0x060A
> +#define MT6323_EFUSE_CON6         0x060C
> +#define MT6323_EFUSE_VAL_0_15     0x060E
> +#define MT6323_EFUSE_VAL_16_31    0x0610
> +#define MT6323_EFUSE_VAL_32_47    0x0612
> +#define MT6323_EFUSE_VAL_48_63    0x0614
> +#define MT6323_EFUSE_VAL_64_79    0x0616
> +#define MT6323_EFUSE_VAL_80_95    0x0618
> +#define MT6323_EFUSE_VAL_96_111   0x061A
> +#define MT6323_EFUSE_VAL_112_127  0x061C
> +#define MT6323_EFUSE_VAL_128_143  0x061E
> +#define MT6323_EFUSE_VAL_144_159  0x0620
> +#define MT6323_EFUSE_VAL_160_175  0x0622
> +#define MT6323_EFUSE_VAL_176_191  0x0624
> +#define MT6323_EFUSE_DOUT_0_15    0x0626
> +#define MT6323_EFUSE_DOUT_16_31   0x0628
> +#define MT6323_EFUSE_DOUT_32_47   0x062A
> +#define MT6323_EFUSE_DOUT_48_63   0x062C
> +#define MT6323_EFUSE_DOUT_64_79   0x062E
> +#define MT6323_EFUSE_DOUT_80_95   0x0630
> +#define MT6323_EFUSE_DOUT_96_111  0x0632
> +#define MT6323_EFUSE_DOUT_112_127 0x0634
> +#define MT6323_EFUSE_DOUT_128_143 0x0636
> +#define MT6323_EFUSE_DOUT_144_159 0x0638
> +#define MT6323_EFUSE_DOUT_160_175 0x063A
> +#define MT6323_EFUSE_DOUT_176_191 0x063C
> +#define MT6323_EFUSE_CON7         0x063E
> +#define MT6323_EFUSE_CON8         0x0640
> +#define MT6323_EFUSE_CON9         0x0642
> +#define MT6323_RTC_MIX_CON0       0x0644
> +#define MT6323_RTC_MIX_CON1       0x0646
> +#define MT6323_AUDTOP_CON0        0x0700
> +#define MT6323_AUDTOP_CON1        0x0702
> +#define MT6323_AUDTOP_CON2        0x0704
> +#define MT6323_AUDTOP_CON3        0x0706
> +#define MT6323_AUDTOP_CON4        0x0708
> +#define MT6323_AUDTOP_CON5        0x070A
> +#define MT6323_AUDTOP_CON6        0x070C
> +#define MT6323_AUDTOP_CON7        0x070E
> +#define MT6323_AUDTOP_CON8        0x0710
> +#define MT6323_AUDTOP_CON9        0x0712
> +#define MT6323_AUXADC_ADC0        0x0714
> +#define MT6323_AUXADC_ADC1        0x0716
> +#define MT6323_AUXADC_ADC2        0x0718
> +#define MT6323_AUXADC_ADC3        0x071A
> +#define MT6323_AUXADC_ADC4        0x071C
> +#define MT6323_AUXADC_ADC5        0x071E
> +#define MT6323_AUXADC_ADC6        0x0720
> +#define MT6323_AUXADC_ADC7        0x0722
> +#define MT6323_AUXADC_ADC8        0x0724
> +#define MT6323_AUXADC_ADC9        0x0726
> +#define MT6323_AUXADC_ADC10       0x0728
> +#define MT6323_AUXADC_ADC11       0x072A
> +#define MT6323_AUXADC_ADC12       0x072C
> +#define MT6323_AUXADC_ADC13       0x072E
> +#define MT6323_AUXADC_ADC14       0x0730
> +#define MT6323_AUXADC_ADC15       0x0732
> +#define MT6323_AUXADC_ADC16       0x0734
> +#define MT6323_AUXADC_ADC17       0x0736
> +#define MT6323_AUXADC_ADC18       0x0738
> +#define MT6323_AUXADC_ADC19       0x073A
> +#define MT6323_AUXADC_ADC20       0x073C
> +#define MT6323_AUXADC_RSV1        0x073E
> +#define MT6323_AUXADC_RSV2        0x0740
> +#define MT6323_AUXADC_CON0        0x0742
> +#define MT6323_AUXADC_CON1        0x0744
> +#define MT6323_AUXADC_CON2        0x0746
> +#define MT6323_AUXADC_CON3        0x0748
> +#define MT6323_AUXADC_CON4        0x074A
> +#define MT6323_AUXADC_CON5        0x074C
> +#define MT6323_AUXADC_CON6        0x074E
> +#define MT6323_AUXADC_CON7        0x0750
> +#define MT6323_AUXADC_CON8        0x0752
> +#define MT6323_AUXADC_CON9        0x0754
> +#define MT6323_AUXADC_CON10       0x0756
> +#define MT6323_AUXADC_CON11       0x0758
> +#define MT6323_AUXADC_CON12       0x075A
> +#define MT6323_AUXADC_CON13       0x075C
> +#define MT6323_AUXADC_CON14       0x075E
> +#define MT6323_AUXADC_CON15       0x0760
> +#define MT6323_AUXADC_CON16       0x0762
> +#define MT6323_AUXADC_CON17       0x0764
> +#define MT6323_AUXADC_CON18       0x0766
> +#define MT6323_AUXADC_CON19       0x0768
> +#define MT6323_AUXADC_CON20       0x076A
> +#define MT6323_AUXADC_CON21       0x076C
> +#define MT6323_AUXADC_CON22       0x076E
> +#define MT6323_AUXADC_CON23       0x0770
> +#define MT6323_AUXADC_CON24       0x0772
> +#define MT6323_AUXADC_CON25       0x0774
> +#define MT6323_AUXADC_CON26       0x0776
> +#define MT6323_AUXADC_CON27       0x0778
> +#define MT6323_ACCDET_CON0        0x077A
> +#define MT6323_ACCDET_CON1        0x077C
> +#define MT6323_ACCDET_CON2        0x077E
> +#define MT6323_ACCDET_CON3        0x0780
> +#define MT6323_ACCDET_CON4        0x0782
> +#define MT6323_ACCDET_CON5        0x0784
> +#define MT6323_ACCDET_CON6        0x0786
> +#define MT6323_ACCDET_CON7        0x0788
> +#define MT6323_ACCDET_CON8        0x078A
> +#define MT6323_ACCDET_CON9        0x078C
> +#define MT6323_ACCDET_CON10       0x078E
> +#define MT6323_ACCDET_CON11       0x0790
> +#define MT6323_ACCDET_CON12       0x0792
> +#define MT6323_ACCDET_CON13       0x0794
> +#define MT6323_ACCDET_CON14       0x0796
> +#define MT6323_ACCDET_CON15       0x0798
> +#define MT6323_ACCDET_CON16       0x079A
> +
> +#endif /* __MFD_MT6323_REGISTERS_H__ */

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From marc.zyngier at arm.com  Wed Feb 10 08:59:54 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 16:59:54 +0000
Subject: [RFC PATCH 0/5] arm/arm64: Making HYP vgic/timer save/restore
 common
In-Reply-To: <20160209203803.GD5171@cbox>
References: <1453996565-19666-1-git-send-email-marc.zyngier@arm.com>
 <20160209203803.GD5171@cbox>
Message-ID: <56BB6C8A.1080109@arm.com>

On 09/02/16 20:38, Christoffer Dall wrote:
> On Thu, Jan 28, 2016 at 03:56:00PM +0000, Marc Zyngier wrote:
>> With the current state of the C conversion of arm and arm64 world
>> switches, we are still unable to share some of the most obvious
>> candidates (GIC and timer save/restore). In order to reduce the bloat,
>> let's move these files to a common location (virt/kvm/arm/hyp).
>>
>> The changes are extremely mechanical, with a small hack to deal with
>> system register names on the 32bit side (I've decided to align on the
>> 64bit names).
>>
>> I'd like to know what people think of the common location. Does it
>> makes sense to have a "hyp" subdirectory to indicate that this is not
>> "normal" kernel code?
>>
>> These patches are on top of 4.5-rc1, plus the VHE and 32bit WS rewrite
>> patches, and I've pushed out a branch at
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/mov-hyp
>>
> 
> ack on this series, tested on TC2 and Mustang as well.

Thanks for all the reviewing!

I'll rebase it once the dust settles on VHE and WSINC, and that will
form one bloody long series...

	M.
-- 
Jazz is not dead. It just smells funny...


From lee.jones at linaro.org  Wed Feb 10 09:01:27 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Wed, 10 Feb 2016 17:01:27 +0000
Subject: [PATCH V3 1/4] dt-bindings: mfd: Add bindings for the MediaTek
 MT6323 PMIC
In-Reply-To: <1453895258-44369-1-git-send-email-blogic@openwrt.org>
References: <1453895258-44369-1-git-send-email-blogic@openwrt.org>
Message-ID: <20160210170127.GW3782@x1>

If you're submitting a set of patches like this, you really ought to
be providing a cover-letter.

Also, when submitting patches, please do so in the style expected by
the subsystem.  I will fix these once up for now, but please bear that
in mind in the future.

`git log --oneline -- <subsystem>` works well for this.

> Signed-off-by: John Crispin <blogic at openwrt.org>
> Cc: devicetree at vger.kernel.org
> ---
>  Documentation/devicetree/bindings/mfd/mt6397.txt |   10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt
> index 15043e6..949c85f 100644
> --- a/Documentation/devicetree/bindings/mfd/mt6397.txt
> +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
> @@ -1,6 +1,6 @@
> -MediaTek MT6397 Multifunction Device Driver
> +MediaTek MT6397/MT6323 Multifunction Device Driver
>  
> -MT6397 is a multifunction device with the following sub modules:
> +MT6397/MT6323 is a multifunction device with the following sub modules:
>  - Regulator
>  - RTC
>  - Audio codec
> @@ -8,14 +8,14 @@ MT6397 is a multifunction device with the following sub modules:
>  - Clock
>  
>  It is interfaced to host controller using SPI interface by a proprietary hardware
> -called PMIC wrapper or pwrap. MT6397 MFD is a child device of pwrap.
> +called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap.
>  See the following for pwarp node definitions:
>  Documentation/devicetree/bindings/soc/pwrap.txt
>  
>  This document describes the binding for MFD device and its sub module.
>  
>  Required properties:
> -compatible: "mediatek,mt6397"
> +compatible: "mediatek,mt6397" or "mediatek,mt6323"
>  
>  Optional subnodes:
>  
> @@ -26,6 +26,8 @@ Optional subnodes:
>  	Required properties:
>  		- compatible: "mediatek,mt6397-regulator"
>  	see Documentation/devicetree/bindings/regulator/mt6397-regulator.txt
> +		- compatible: "mediatek,mt6323-regulator"
> +	see Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
>  - codec
>  	Required properties:
>  		- compatible: "mediatek,mt6397-codec"

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From moinejf at free.fr  Wed Feb 10 09:04:20 2016
From: moinejf at free.fr (Jean-Francois Moine)
Date: Wed, 10 Feb 2016 18:04:20 +0100
Subject: [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused
In-Reply-To: <20160210125333.GC31506@lukather>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <20160204120507.GC4270@lukather>
 <20160204162545.f806fcb64a826d2c3313985b@free.fr>
 <20160210125333.GC31506@lukather>
Message-ID: <20160210180420.0968c2018bf5fbe54a28a505@free.fr>

On Wed, 10 Feb 2016 13:53:33 +0100
Maxime Ripard <maxime.ripard at free-electrons.com> wrote:

> > I don't agree:
> > - you changed the DTs of many SoCs without any valid reason,
> 
> I did give you a significant number of reasons [1]. The fact that you
> chose to ignore them is up to you.

Sorry, I don't see any reason for changing the DT definition of the pll6.
The clock is named "pll6" with "#clock-cells = <1>;" in all DTs,
and it works as it is.
If you want an other clock as "pll8", with the same HW description,
you must add new code for this clock.

> Except that it doesn't match the hardware and that the parenthood
> relationship is inversed. The pll6 output is 24 MHz * n * k / 2, as
> seen in any datasheet that uses it. Your clock driver doesn't
> represent that fact.

The datasheet says that the pll6x2 output is 24 MHz * n * k, then, if
I remember correctly my lessons at primary school, defining pll6 as
(pll6x2 / 2) gives 24 MHz * n * k / 2 as the pll6 output. No?

-- 
Ken ar c'henta?	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/



From marc.zyngier at arm.com  Wed Feb 10 09:08:48 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 17:08:48 +0000
Subject: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot
 for X-Gene v1
In-Reply-To: <1455069384-22323-1-git-send-email-dhdang@apm.com>
References: <1455069384-22323-1-git-send-email-dhdang@apm.com>
Message-ID: <56BB6EA0.7060706@arm.com>

On 10/02/16 01:56, Duc Dang wrote:
> This patch makes pci-xgene-msi driver ACPI-aware and provides
> MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode.
> 
> Signed-off-by: Duc Dang <dhdang at apm.com>

Another nail on the ACPI "standardization" coffin, I suppose... Oh well.

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

	M.
-- 
Jazz is not dead. It just smells funny...


From horms at verge.net.au  Wed Feb 10 09:14:55 2016
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Feb 2016 18:14:55 +0100
Subject: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
In-Reply-To: <874mdhtn7d.wl%kuninori.morimoto.gx@renesas.com>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
 <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
 <874mdhtn7d.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <20160210171455.GB17671@verge.net.au>

On Wed, Feb 10, 2016 at 12:41:30AM +0000, Kuninori Morimoto wrote:
> 
> Hi Sergei
> 
> Sorry for my un-ordered response
> 
> > Define the generic R8A7794 part of  the sound device node.
> > This sound device  is a complex one and comprises the Audio Clock Generator
> > (ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
> > (SSI[U]), and Audio DMAC-Peripheral-Peripheral.
> > It is up  to the board file to enable the device.
> > 
> > This patch is based on the R8A7791 sound work by Kuninori Morimoto.
> > 
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> (snip)
> > +		rcar_sound,src {
> > +			src1: src at 1 {
> > +				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
> > +				dmas = <&audma0 0x87>, <&audma0 0x9c>;
> > +				dma-names = "rx", "tx";
> > +			};
> > +			src2: src at 2 {
> > +				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
> > +				dmas = <&audma0 0x89>, <&audma0 0x9e>;
> > +				dma-names = "rx", "tx";
> > +			};
> > +			src3: src at 3 {
> > +				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
> > +				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
> > +				dma-names = "rx", "tx";
> > +			};
> > +			src4: src at 4 {
> > +				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
> > +				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
> > +				dma-names = "rx", "tx";
> > +			};
> > +			src5: src at 5 {
> > +				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
> > +				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
> > +				dma-names = "rx", "tx";
> > +			};
> > +			src6: src at 6 {
> > +				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> > +				dmas = <&audma0 0x91>, <&audma0 0xb4>;
> > +				dma-names = "rx", "tx";
> > +			};
> > +		};
> 
> I think this can't work correctly, because driver is assuming
> DT has all channles (from 0). (see linux/sound/soc/sh/rcar/src.c :: rsnd_src_probe)
> Can you adds dummy src0 with some comments ? or fix src.c driver ?

I would prefer the driver to be fixed (I had a similar patchset locally
and I found it doesn't work). The reason is that DT should describe
the hardware rather than the current state of the software.


From andrew at lunn.ch  Wed Feb 10 09:17:38 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 10 Feb 2016 18:17:38 +0100
Subject: [PATCH v2 1/2] ARM: mvebu: use armada-370-sata for SATA on
 Armada 375
In-Reply-To: <1455121756-20804-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455121756-20804-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20160210171738.GC9492@lunn.ch>

On Wed, Feb 10, 2016 at 05:29:15PM +0100, Thomas Petazzoni wrote:
> From: Lior Amsalem <alior at marvell.com>
> 
> The Armada 375 has the same SATA IP as Armada 370 and Armada XP, which
> requires the PHY speed to be set in the LP_PHY_CTL register for SATA
> hotplug to work.
> 
> Therefore, this commit updates the compatible string used to describe
> the SATA IP in Armada 375 from marvell,orion-sata to
> marvell,armada-370-sata.
> 
> Fixes: 4de59085091f753d08c8429d756b46756ab94665 ("ARM: mvebu: add Device Tree description of the Armada 375 SoC")
> Cc: <stable at vger.kernel.org>
> Signed-off-by: Lior Amsalem <alior at marvell.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

Thanks for adding the tags,
       
       Andrew

> ---
> Changes since v1:
>  - Add Fixes: tag, and add stable@ in Cc, as suggested by Andrew Lunn.
> ---
>  arch/arm/boot/dts/armada-375.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
> index 7ccce75..cc952cf 100644
> --- a/arch/arm/boot/dts/armada-375.dtsi
> +++ b/arch/arm/boot/dts/armada-375.dtsi
> @@ -529,7 +529,7 @@
>  			};
>  
>  			sata at a0000 {
> -				compatible = "marvell,orion-sata";
> +				compatible = "marvell,armada-370-sata";
>  				reg = <0xa0000 0x5000>;
>  				interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
>  				clocks = <&gateclk 14>, <&gateclk 20>;
> -- 
> 2.6.4
> 


From andrew at lunn.ch  Wed Feb 10 09:18:51 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 10 Feb 2016 18:18:51 +0100
Subject: [PATCH v2 2/2] ARM: mvebu: add NAND description to Armada 370 DB
 and Armada XP DB
In-Reply-To: <1455121756-20804-2-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455121756-20804-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455121756-20804-2-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20160210171851.GD9492@lunn.ch>

On Wed, Feb 10, 2016 at 05:29:16PM +0100, Thomas Petazzoni wrote:
> This commit adds the Device Tree description for the 1GB NAND flash
> present in the Armada 370 DB and Armada XP DB evaluation boards from
> Marvell.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

Thanks
	Andrew

> ---
> Changes since v1:
>  - Use the new MTD partitions DT binding, with all partitions grouped
>    into a 'partitions' subnode. Suggested by Andrew Lunn.
> ---
>  arch/arm/boot/dts/armada-370-db.dts | 27 +++++++++++++++++++++++++++
>  arch/arm/boot/dts/armada-xp-db.dts  | 28 ++++++++++++++++++++++++++++
>  2 files changed, 55 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
> index bb280de..2364fc5 100644
> --- a/arch/arm/boot/dts/armada-370-db.dts
> +++ b/arch/arm/boot/dts/armada-370-db.dts
> @@ -168,6 +168,33 @@
>  					spi-max-frequency = <50000000>;
>  				};
>  			};
> +
> +			nand at d0000 {
> +				status = "okay";
> +				num-cs = <1>;
> +				marvell,nand-keep-config;
> +				marvell,nand-enable-arbiter;
> +				nand-on-flash-bbt;
> +
> +				partitions {
> +					compatible = "fixed-partitions";
> +					#address-cells = <1>;
> +					#size-cells = <1>;
> +
> +					partition at 0 {
> +						label = "U-Boot";
> +						reg = <0 0x800000>;
> +					};
> +					partition at 800000 {
> +						label = "Linux";
> +						reg = <0x800000 0x800000>;
> +					};
> +					partition at 1000000 {
> +						label = "Filesystem";
> +						reg = <0x1000000 0x3f000000>;
> +					};
> +				};
> +			};
>  		};
>  
>  		pcie-controller {
> diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
> index f774101..96aaaed 100644
> --- a/arch/arm/boot/dts/armada-xp-db.dts
> +++ b/arch/arm/boot/dts/armada-xp-db.dts
> @@ -229,6 +229,34 @@
>  					spi-max-frequency = <20000000>;
>  				};
>  			};
> +
> +			nand at d0000 {
> +				status = "okay";
> +				num-cs = <1>;
> +				marvell,nand-keep-config;
> +				marvell,nand-enable-arbiter;
> +				nand-on-flash-bbt;
> +
> +				partitions {
> +					compatible = "fixed-partitions";
> +					#address-cells = <1>;
> +					#size-cells = <1>;
> +
> +					partition at 0 {
> +						label = "U-Boot";
> +						reg = <0 0x800000>;
> +					};
> +					partition at 800000 {
> +						label = "Linux";
> +						reg = <0x800000 0x800000>;
> +					};
> +					partition at 1000000 {
> +						label = "Filesystem";
> +						reg = <0x1000000 0x3f000000>;
> +
> +					};
> +				};
> +			};
>  		};
>  	};
>  };
> -- 
> 2.6.4
> 


From marc.zyngier at arm.com  Wed Feb 10 09:19:22 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 17:19:22 +0000
Subject: [PATCH v2 1/7] irqchip/gic-v3: always return IRQ_SET_MASK_OK_DONE
 in gic_set_affinity
In-Reply-To: <1455110583-19515-2-git-send-email-antoine.tenart@free-electrons.com>
References: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
 <1455110583-19515-2-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <56BB711A.2070301@arm.com>

On 10/02/16 13:22, Antoine Tenart wrote:
> Always return IRQ_SET_MASK_OK_DONE instead of IRQ_SET_MASK_OK when the
> affinity has been updated. When using stacked irqchips, returning
> IRQ_SET_MASK_OK_DONE means skipping all descendant irqchips.
> 
> Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

	M.
-- 
Jazz is not dead. It just smells funny...


From stefan.wahren at i2se.com  Wed Feb 10 09:21:31 2016
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Wed, 10 Feb 2016 18:21:31 +0100
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in
 console
In-Reply-To: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
References: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
Message-ID: <56BB719B.8070007@i2se.com>

Hi,

Am 10.02.2016 um 16:12 schrieb Martin Sperl:
> Hi!
>
> I got a strange effect when using the auxiliar UART as the logging console:
>
> The kernel is configured for drivers/tty/serial/8250/8250_bcm2835aux.c to
> get linked into the main kernel (requires also 8250.c to be linked in).
>
> As long as I boot using the main UART (PL011) in the kernel parameters:
>   earlyprintk consoleblank=0 console=ttyAMA0 root=/dev/mmcblk0p2 rootwait
>
> Everything works fine - early_printk works and normal logging works as well.
> Both configured ttys (/dev/ttyAMA0 and /dev/ttyS0) in /etc/initttab
> work fine.
>
> Now when I switch the console to use the auxiliar UART
> (which right now does not support early_printk) like this:
>   earlyprintk consoleblank=0 console=ttyS0,115200n1 root=/dev/mmcblk0p2 rootwait
>
> I get the situation where:
> * u-boot starts and writes to the main UART
> * Kernel boots using early_printk logging to the main UART until we get to:
>   [    2.657090] bootconsole [earlycon0] disabled
> * then we see the earlyprintk buffer dumped on the aux-uart
> * then booting continues and logging happens on the aux-uart:
>   [    2.657090] bootconsole [earlycon0] disabled
>   [    2.662673] 20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
>   [    2.663793] console [ttyS0] disabled
>   [    2.663899] 20215040.serial: ttyS0 at MMIO 0x0 (irq = 53, base_baud = 31224999) is a 16550
>   [    3.384166] console [ttyS0] enabled
> * everything works fine and I get networking and everything up
>   [....] Starting NTP server: ntpd. ok
>   [....] Starting OpenBSD Secure Shell server: sshd. ok
>   My IP address is 10.10.10.41 ::127.0.0.1
>
>   Raspbian GNU/Linux 7 raspcm.intern.sperl.org ttyS0
> * I can even log in via SSH and networking works.
>   Note that I have the getty for ttyAMA0 disabled in inittab
> * when I then enable the tty on the main UART like this:
>   root at raspcm:~# /sbin/getty -a root -L ttyAMA0 115200 vt100
> * I get the following:
>   [   72.962845] uart-pl011 20201000.serial: no DMA platform data
> * the system freezes?
> * sometimes I still get the following on the auxiliar UART before the system ?crashes":
>   (at least when starting the tty from inittab)
>   [   73.072985] bcm2835-clk 20101000.cprman: plld: couldn't lock PLL
>   [   73.079132] ------------[ cut here ]------------
>   [   73.083848] WARNING: CPU: 0 PID: 2329 at drivers/clk/clk.c:680 clk_core_disable+0x34/0xf0()
>   [   73.093067] ---[ end trace 416e78cea88f5fb5 ]---
>   [   73.097848] ------------[ cut here ]------------
>   [   73.102616] WARNING: CPU: 0 PID: 2329 at drivers/clk/clk.c:575 clk_core_unprepare+0x34/0x110()
>   [   73.112219] ---[ end trace 416e78cea88f5fb6 ]---
>
> A similar effect I get when using stty: 
>   root at raspcm:~# stty -F /dev/ttyAMA0
>   [  128.878127] uart-pl011 20201000.serial: no DMA platform data
>   speed 9600 baud; line = 0;
>   -brkint -imaxbel
> Then the system freezes.
>
> As if the plld does not lock - even if it (probably) is already locked.
>
> Or the message actually comes from bcm2835_clock_wait_busy which also
> produces this message - so maybe we should better identify the message.
>
> Note that the same also applies if I remove earlyprintk with
> the only difference being that I do not get the initial boot
> messages on the main UART.
> (at that time only: "Uncompressing Linux... done, booting the kernel.?
> shows on the main uart after u-boot start..)
>
> Unfortunately it is only possible to really test this on a
> rpi-Compute module, as only there we can expose both uarts
> on distinct GPIOs at the same time:
>   GPIO 14: level=1 fsel=4 alt=0 func=TXD0
>   GPIO 15: level=1 fsel=4 alt=0 func=RXD0
>   GPIO 32: level=1 fsel=2 alt=5 func=TXD1
>   GPIO 33: level=1 fsel=2 alt=5 func=RXD1
>
> Here the commits I have used based on spi/for-next (based on 4.4.0)
> with the patches (* prefix) for the driver for aux-uart
> added separately as they are not in the tree I have used:
> * a96f6c7 serial: bcm2835: add driver for bcm2835-aux-uart
> * 464e876 clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.
> * 1af1b28 clk: bcm2835: Add a driver for the auxiliary peripheral clock gates.
> ece19b8 Merge remote-tracking branch 'spi/fix/loopback' into spi-linus
> 887e6a3 Merge tag 'spi-v4.5' into spi-linus
> ebea7c0 spi: fix counting in spi-loopback-test code
> cabeea9 Merge remote-tracking branches 'spi/topic/sun4i', 'spi/topic/topcliff-pc
> 4f95307 Merge remote-tracking branches 'spi/topic/overlay', 'spi/topic/pxa2xx',
> 41d5a70 Merge remote-tracking branches 'spi/topic/lm70llp', 'spi/topic/loopback'
> 635b9b2 Merge remote-tracking branches 'spi/topic/dw', 'spi/topic/dw-mid', 'spi/
> 3c27892 Merge remote-tracking branches 'spi/topic/bcm63xx', 'spi/topic/butterfly
> 9b17e80 Merge remote-tracking branch 'spi/topic/sunxi' into spi-next
> 174c211 Merge remote-tracking branch 'spi/topic/core' into spi-next
> f30f072 Merge remote-tracking branch 'spi/fix/mtk' into spi-linus
> afd2ff9 Linux 4.4
>
> Maybe someone has gotten any idea?

this sounds like an issue i had with the compute module here:

http://permalink.gmane.org/gmane.linux.kernel.rpi/2197

Unfortunately i don't have the cm anymore.

Maybe you can try this downstream patch:

https://github.com/raspberrypi/linux/commit/09041f7ccbd1cde792edae91c41266886d5d1382

Regards




From christoffer.dall at linaro.org  Wed Feb 10 09:23:21 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 10 Feb 2016 18:23:21 +0100
Subject: [PATCH v2 18/28] ARM: KVM: Add HYP mode entry code
In-Reply-To: <56BB5F06.9000606@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-19-git-send-email-marc.zyngier@arm.com>
 <20160209170042.GA5171@cbox> <56BB5F06.9000606@arm.com>
Message-ID: <20160210172321.GP5171@cbox>

On Wed, Feb 10, 2016 at 04:02:14PM +0000, Marc Zyngier wrote:
> On 09/02/16 17:00, Christoffer Dall wrote:
> > On Thu, Feb 04, 2016 at 11:00:35AM +0000, Marc Zyngier wrote:
> >> This part is almost entierely borrowed from the existing code, just
> >> slightly simplifying the HYP function call (as we now save SPSR_hyp
> >> in the world switch).
> >>
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >> ---
> >>  arch/arm/kvm/hyp/Makefile    |   1 +
> >>  arch/arm/kvm/hyp/hyp-entry.S | 157 +++++++++++++++++++++++++++++++++++++++++++
> >>  arch/arm/kvm/hyp/hyp.h       |   2 +
> >>  3 files changed, 160 insertions(+)
> >>  create mode 100644 arch/arm/kvm/hyp/hyp-entry.S
> >>
> >> diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
> >> index cfab402..a7d3a7e 100644
> >> --- a/arch/arm/kvm/hyp/Makefile
> >> +++ b/arch/arm/kvm/hyp/Makefile
> >> @@ -9,4 +9,5 @@ obj-$(CONFIG_KVM_ARM_HOST) += vgic-v2-sr.o
> >>  obj-$(CONFIG_KVM_ARM_HOST) += vfp.o
> >>  obj-$(CONFIG_KVM_ARM_HOST) += banked-sr.o
> >>  obj-$(CONFIG_KVM_ARM_HOST) += entry.o
> >> +obj-$(CONFIG_KVM_ARM_HOST) += hyp-entry.o
> >>  obj-$(CONFIG_KVM_ARM_HOST) += switch.o
> >> diff --git a/arch/arm/kvm/hyp/hyp-entry.S b/arch/arm/kvm/hyp/hyp-entry.S
> >> new file mode 100644
> >> index 0000000..44bc11f
> >> --- /dev/null
> >> +++ b/arch/arm/kvm/hyp/hyp-entry.S
> >> @@ -0,0 +1,157 @@
> >> +/*
> >> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> >> + * Author: Christoffer Dall <c.dall at virtualopensystems.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, write to the Free Software
> >> + * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
> >> + */
> >> +
> >> +#include <linux/linkage.h>
> >> +#include <asm/kvm_arm.h>
> >> +#include <asm/kvm_asm.h>
> >> +
> >> +	.arch_extension     virt
> >> +
> >> +	.text
> >> +	.pushsection	.hyp.text, "ax"
> >> +
> >> +.macro load_vcpu	reg
> >> +	mrc	p15, 4, \reg, c13, c0, 2	@ HTPIDR
> >> +.endm
> >> +
> >> +/********************************************************************
> >> + * Hypervisor exception vector and handlers
> >> + *
> >> + *
> >> + * The KVM/ARM Hypervisor ABI is defined as follows:
> >> + *
> >> + * Entry to Hyp mode from the host kernel will happen _only_ when an HVC
> >> + * instruction is issued since all traps are disabled when running the host
> >> + * kernel as per the Hyp-mode initialization at boot time.
> >> + *
> >> + * HVC instructions cause a trap to the vector page + offset 0x14 (see hyp_hvc
> >> + * below) when the HVC instruction is called from SVC mode (i.e. a guest or the
> >> + * host kernel) and they cause a trap to the vector page + offset 0x8 when HVC
> >> + * instructions are called from within Hyp-mode.
> >> + *
> >> + * Hyp-ABI: Calling HYP-mode functions from host (in SVC mode):
> >> + *    Switching to Hyp mode is done through a simple HVC #0 instruction. The
> >> + *    exception vector code will check that the HVC comes from VMID==0.
> >> + *    - r0 contains a pointer to a HYP function
> >> + *    - r1, r2, and r3 contain arguments to the above function.
> >> + *    - The HYP function will be called with its arguments in r0, r1 and r2.
> >> + *    On HYP function return, we return directly to SVC.
> >> + *
> >> + * Note that the above is used to execute code in Hyp-mode from a host-kernel
> >> + * point of view, and is a different concept from performing a world-switch and
> >> + * executing guest code SVC mode (with a VMID != 0).
> >> + */
> >> +
> >> +	.align 5
> >> +__hyp_vector:
> >> +	.global	__hyp_vector
> >> +__kvm_hyp_vector:
> >> +	.weak __kvm_hyp_vector
> >> +
> >> +	@ Hyp-mode exception vector
> >> +	W(b)	hyp_reset
> >> +	W(b)	hyp_undef
> >> +	W(b)	hyp_svc
> >> +	W(b)	hyp_pabt
> >> +	W(b)	hyp_dabt
> >> +	W(b)	hyp_hvc
> >> +	W(b)	hyp_irq
> >> +	W(b)	hyp_fiq
> >> +
> >> +.macro invalid_vector label, cause
> >> +	.align
> >> +\label:	b	.
> >> +.endm
> >> +
> >> +	invalid_vector	hyp_reset
> >> +	invalid_vector	hyp_undef
> >> +	invalid_vector	hyp_svc
> >> +	invalid_vector	hyp_pabt
> >> +	invalid_vector	hyp_dabt
> >> +	invalid_vector	hyp_fiq
> >> +
> >> +hyp_hvc:
> >> +	/*
> >> +	 * Getting here is either because of a trap from a guest,
> >> +	 * or from executing HVC from the host kernel, which means
> >> +	 * "do something in Hyp mode".
> >> +	 */
> >> +	push	{r0, r1, r2}
> >> +
> >> +	@ Check syndrome register
> >> +	mrc	p15, 4, r1, c5, c2, 0	@ HSR
> >> +	lsr	r0, r1, #HSR_EC_SHIFT
> >> +	cmp	r0, #HSR_EC_HVC
> >> +	bne	guest_trap		@ Not HVC instr.
> >> +
> >> +	/*
> >> +	 * Let's check if the HVC came from VMID 0 and allow simple
> >> +	 * switch to Hyp mode
> >> +	 */
> >> +	mrrc    p15, 6, r0, r2, c2
> >> +	lsr     r2, r2, #16
> >> +	and     r2, r2, #0xff
> >> +	cmp     r2, #0
> >> +	bne	guest_trap		@ Guest called HVC
> >> +
> >> +	/*
> >> +	 * Getting here means host called HVC, we shift parameters and branch
> >> +	 * to Hyp function.
> >> +	 */
> >> +	pop	{r0, r1, r2}
> >> +
> >> +	/* Check for __hyp_get_vectors */
> >> +	cmp	r0, #-1
> >> +	mrceq	p15, 4, r0, c12, c0, 0	@ get HVBAR
> >> +	beq	1f
> >> +
> >> +	push	{lr}
> >> +
> >> +	mov	lr, r0
> >> +	mov	r0, r1
> >> +	mov	r1, r2
> >> +	mov	r2, r3
> >> +
> >> +THUMB(	orr	lr, #1)
> >> +	blx	lr			@ Call the HYP function
> >> +
> >> +	pop	{lr}
> >> +1:	eret
> >> +
> >> +guest_trap:
> >> +	load_vcpu r0			@ Load VCPU pointer to r0
> >> +
> >> +	@ Check if we need the fault information
> > 
> > nit: this is not about faults at this point, so this comment should
> > either go or be reworded to "let's check if we trapped on guest VFP
> > access"
> > 
> > and I think the lsr can be moved into the ifdef as well.
> 
> Yes, both good points.
> 
fixing that, you can also have my

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>

if I didn't give it already.

-Christoffer


From christoffer.dall at linaro.org  Wed Feb 10 09:25:39 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 10 Feb 2016 18:25:39 +0100
Subject: [PATCH v2 07/28] ARM: KVM: Add system register accessor macros
In-Reply-To: <1454583645-10144-8-git-send-email-marc.zyngier@arm.com>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-8-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160210172539.GQ5171@cbox>

On Thu, Feb 04, 2016 at 11:00:24AM +0000, Marc Zyngier wrote:
> In order to move system register (CP15, mostly) access to C code,
> add a few macros to facilitate this, and minimize the difference
> between 32 and 64bit CP15 registers.
> 
> This will get heavily used in the following patches.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kvm/hyp/hyp.h | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
> index c723870..727089f 100644
> --- a/arch/arm/kvm/hyp/hyp.h
> +++ b/arch/arm/kvm/hyp/hyp.h
> @@ -27,4 +27,19 @@
>  #define kern_hyp_va(v) (v)
>  #define hyp_kern_va(v) (v)
>  
> +#define __ACCESS_CP15(CRn, Op1, CRm, Op2)	\
> +	"mrc", "mcr", __stringify(p15, Op1, %0, CRn, CRm, Op2), u32
> +#define __ACCESS_CP15_64(Op1, CRm)		\
> +	"mrrc", "mcrr", __stringify(p15, Op1, %Q0, %R0, CRm), u64
> +
> +#define __write_sysreg(v, r, w, c, t)	asm volatile(w " " c : : "r" ((t)(v)))
> +#define write_sysreg(v, ...)		__write_sysreg(v, __VA_ARGS__)
> +
> +#define __read_sysreg(r, w, c, t) ({				\
> +	t __val;						\
> +	asm volatile(r " " c : "=r" (__val));			\
> +	__val;							\
> +})
> +#define read_sysreg(...)		__read_sysreg(__VA_ARGS__)
> +
>  #endif /* __ARM_KVM_HYP_H__ */
> -- 
> 2.1.4
> 

I sort of figured that a reviewed-by tag on patches that actually use
these macros would be an implicit review of this code.

not feeling comfortable enough that I read this jibberish perfectly in
isolation, but given that the stuff compiles and works, I'll just ack
it:

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>


From paul.burton at imgtec.com  Wed Feb 10 09:27:07 2016
From: paul.burton at imgtec.com (Paul Burton)
Date: Wed, 10 Feb 2016 09:27:07 -0800
Subject: [PATCH V3 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge
 driver to work on both  Zynq and Microblaze
In-Reply-To: <8520D5D51A55D047800579B09414719825881780@XAP-PVEXMBX01.xlnx.xilinx.com>
References: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
 <1455014518-8708-4-git-send-email-bharatku@xilinx.com>
 <20160209161134.GA24244@NP-P-BURTON>
 <8520D5D51A55D047800579B09414719825881780@XAP-PVEXMBX01.xlnx.xilinx.com>
Message-ID: <20160210172707.GA29590@NP-P-BURTON>

On Wed, Feb 10, 2016 at 05:55:51AM +0000, Bharat Kumar Gogada wrote:
> > On Tue, Feb 09, 2016 at 04:11:56PM +0530, Bharat Kumar Gogada wrote:
> > > Modifying Xilinx AXI PCIe Host Bridge Soft IP driver to work on both
> > > Zynq and Microblaze Architectures.
> > > With these modifications drivers/pci/host/pcie-xilinx.c, will work on
> > > both Zynq and Microblaze Architectures.
> > >
> > > Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> > > Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
> > > ---
> > > Changes:
> > > Removed unneccessary architecture dependent number of MSI's.
> > > Added #ifdef to pci_fixup_irqs which is ARM specific API.
> > 
> > Hi Bharat,
> > 
> > Why do you say pci_fixup_irqs is ARM-specific? It's declared in
> > include/linux/pci.h, defined in drivers/pci/setup-irq.c & used by multiple
> > architectures (alpha, arm, m68k, mips, sh, sparc, tile,
> > unicore32 from a quick grep).
> > 
> > Will you not break INTX-style interrupts by removing this?
> > 
> I meant to say ARM specific w.r.t Microblaze architecture, which is
> what this patch series are for. This has been already discussed in my
> previous patch by  Arnd Bergmann and Lorenzo Pieralisi .
> (https://lkml.org/lkml/2016/1/12/707)

Hi Bharat,

Ok, so you don't need it for microblaze but do need it for zynq/ARM. We
also need it for MIPS, where my recent patches enable this driver. So if
#ifdef'ing this is the current way forwards could you please invert the
condition to #ifndef CONFIG_MICROBLAZE?

Thanks,
    Paul


From christoffer.dall at linaro.org  Wed Feb 10 09:30:54 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 10 Feb 2016 18:30:54 +0100
Subject: [PATCH 7/8] KVM: arm/arm64: Avoid accessing GICH registers
In-Reply-To: <56BB3C74.9000105@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <1454931622-14902-8-git-send-email-marc.zyngier@arm.com>
 <20160210124506.GN5171@cbox> <56BB3C74.9000105@arm.com>
Message-ID: <20160210173054.GR5171@cbox>

On Wed, Feb 10, 2016 at 01:34:44PM +0000, Marc Zyngier wrote:
> On 10/02/16 12:45, Christoffer Dall wrote:
> > On Mon, Feb 08, 2016 at 11:40:21AM +0000, Marc Zyngier wrote:
> >> GICv2 registers are *slow*. As in "terrifyingly slow". Which is bad.
> >> But we're equaly bad, as we make a point in accessing them even if
> >> we don't have any interrupt in flight.
> >>
> >> A good solution is to first find out if we have anything useful to
> >> write into the GIC, and if we don't, to simply not do it. This
> >> involves tracking which LRs actually have something valid there.
> >>
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >> ---
> >>  arch/arm64/kvm/hyp/vgic-v2-sr.c | 71 ++++++++++++++++++++++++++++-------------
> >>  include/kvm/arm_vgic.h          |  2 ++
> >>  2 files changed, 51 insertions(+), 22 deletions(-)
> >>
> >> diff --git a/arch/arm64/kvm/hyp/vgic-v2-sr.c b/arch/arm64/kvm/hyp/vgic-v2-sr.c
> >> index e717612..874a08d 100644
> >> --- a/arch/arm64/kvm/hyp/vgic-v2-sr.c
> >> +++ b/arch/arm64/kvm/hyp/vgic-v2-sr.c
> >> @@ -38,28 +38,40 @@ void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
> >>  
> >>  	nr_lr = vcpu->arch.vgic_cpu.nr_lr;
> >>  	cpu_if->vgic_vmcr = readl_relaxed(base + GICH_VMCR);
> >> -	cpu_if->vgic_misr = readl_relaxed(base + GICH_MISR);
> >> -	eisr0  = readl_relaxed(base + GICH_EISR0);
> >> -	elrsr0 = readl_relaxed(base + GICH_ELRSR0);
> >> -	if (unlikely(nr_lr > 32)) {
> >> -		eisr1  = readl_relaxed(base + GICH_EISR1);
> >> -		elrsr1 = readl_relaxed(base + GICH_ELRSR1);
> >> -	} else {
> >> -		eisr1 = elrsr1 = 0;
> >> -	}
> >> +
> >> +	if (vcpu->arch.vgic_cpu.live_lrs) {
> >> +		eisr0  = readl_relaxed(base + GICH_EISR0);
> >> +		elrsr0 = readl_relaxed(base + GICH_ELRSR0);
> >> +		cpu_if->vgic_misr = readl_relaxed(base + GICH_MISR);
> >> +		cpu_if->vgic_apr    = readl_relaxed(base + GICH_APR);
> >> +
> >> +		if (unlikely(nr_lr > 32)) {
> >> +			eisr1  = readl_relaxed(base + GICH_EISR1);
> >> +			elrsr1 = readl_relaxed(base + GICH_ELRSR1);
> >> +		} else {
> >> +			eisr1 = elrsr1 = 0;
> >> +		}
> >> +
> >>  #ifdef CONFIG_CPU_BIG_ENDIAN
> >> -	cpu_if->vgic_eisr  = ((u64)eisr0 << 32) | eisr1;
> >> -	cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
> >> +		cpu_if->vgic_eisr  = ((u64)eisr0 << 32) | eisr1;
> >> +		cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
> >>  #else
> >> -	cpu_if->vgic_eisr  = ((u64)eisr1 << 32) | eisr0;
> >> -	cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
> >> +		cpu_if->vgic_eisr  = ((u64)eisr1 << 32) | eisr0;
> >> +		cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
> >>  #endif
> >> -	cpu_if->vgic_apr    = readl_relaxed(base + GICH_APR);
> >>  
> >> -	writel_relaxed(0, base + GICH_HCR);
> >> +		for (i = 0; i < nr_lr; i++)
> >> +			if (vcpu->arch.vgic_cpu.live_lrs & (1UL << i))
> >> +				cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
> >>  
> >> -	for (i = 0; i < nr_lr; i++)
> >> -		cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
> >> +		writel_relaxed(0, base + GICH_HCR);
> >> +
> >> +		vcpu->arch.vgic_cpu.live_lrs = 0;
> >> +	} else {
> >> +		cpu_if->vgic_eisr = 0;
> >> +		cpu_if->vgic_elrsr = ~0UL;
> >> +		cpu_if->vgic_misr = 0;
> >> +	}
> >>  }
> >>  
> >>  /* vcpu is already in the HYP VA space */
> >> @@ -70,15 +82,30 @@ void __hyp_text __vgic_v2_restore_state(struct kvm_vcpu *vcpu)
> >>  	struct vgic_dist *vgic = &kvm->arch.vgic;
> >>  	void __iomem *base = kern_hyp_va(vgic->vctrl_base);
> >>  	int i, nr_lr;
> >> +	u64 live_lrs = 0;
> >>  
> >>  	if (!base)
> >>  		return;
> >>  
> >> -	writel_relaxed(cpu_if->vgic_hcr, base + GICH_HCR);
> >> -	writel_relaxed(cpu_if->vgic_vmcr, base + GICH_VMCR);
> >> -	writel_relaxed(cpu_if->vgic_apr, base + GICH_APR);
> >> -
> >>  	nr_lr = vcpu->arch.vgic_cpu.nr_lr;
> >> +
> >>  	for (i = 0; i < nr_lr; i++)
> >> -		writel_relaxed(cpu_if->vgic_lr[i], base + GICH_LR0 + (i * 4));
> >> +		if (cpu_if->vgic_lr[i] & GICH_LR_STATE)
> >> +			live_lrs |= 1UL << i;
> >> +
> >> +	if (live_lrs) {
> >> +		writel_relaxed(cpu_if->vgic_hcr, base + GICH_HCR);
> >> +		writel_relaxed(cpu_if->vgic_apr, base + GICH_APR);
> >> +		for (i = 0; i < nr_lr; i++) {
> >> +			u32 val = 0;
> >> +
> >> +			if (live_lrs & (1UL << i))
> >> +				val = cpu_if->vgic_lr[i];
> >> +
> >> +			writel_relaxed(val, base + GICH_LR0 + (i * 4));
> >> +		}
> >> +	}
> >> +
> >> +	writel_relaxed(cpu_if->vgic_vmcr, base + GICH_VMCR);
> > 
> > couldn't you optimize this out by storing the last read value and
> > compare if anything changed?  (you'd have to invalidate the cached value
> > on vcpu_put obviously).
> 
> Yeah, very good point. Only the guest can update this, so we could even
> move it to vcpu_load/vcpu_put entirely, and never save/restore it inside
> the run loop.

If vcpu_load is called *after* loading incoming state on migration, this
should work, yes.

> 
> I'll keep that for a further patch, as it requires a bit of infrastructure.
> 
Sounds good.

We can probably also optimize the writing of the LRs further, but I
figure it's not worth it as the interrupt delivery path is the slow path
anyway and we should care about optimizing the common case.

I wouldn't think saving 2-3 writes to some LRs would be measurable for
interrupt delivery anyhow.

-Christoffer


From marc.zyngier at arm.com  Wed Feb 10 09:32:24 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 17:32:24 +0000
Subject: [PATCH v2 07/28] ARM: KVM: Add system register accessor macros
In-Reply-To: <20160210172539.GQ5171@cbox>
References: <1454583645-10144-1-git-send-email-marc.zyngier@arm.com>
 <1454583645-10144-8-git-send-email-marc.zyngier@arm.com>
 <20160210172539.GQ5171@cbox>
Message-ID: <56BB7428.1010506@arm.com>

On 10/02/16 17:25, Christoffer Dall wrote:
> On Thu, Feb 04, 2016 at 11:00:24AM +0000, Marc Zyngier wrote:
>> In order to move system register (CP15, mostly) access to C code,
>> add a few macros to facilitate this, and minimize the difference
>> between 32 and 64bit CP15 registers.
>>
>> This will get heavily used in the following patches.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm/kvm/hyp/hyp.h | 15 +++++++++++++++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/arm/kvm/hyp/hyp.h b/arch/arm/kvm/hyp/hyp.h
>> index c723870..727089f 100644
>> --- a/arch/arm/kvm/hyp/hyp.h
>> +++ b/arch/arm/kvm/hyp/hyp.h
>> @@ -27,4 +27,19 @@
>>  #define kern_hyp_va(v) (v)
>>  #define hyp_kern_va(v) (v)
>>  
>> +#define __ACCESS_CP15(CRn, Op1, CRm, Op2)	\
>> +	"mrc", "mcr", __stringify(p15, Op1, %0, CRn, CRm, Op2), u32
>> +#define __ACCESS_CP15_64(Op1, CRm)		\
>> +	"mrrc", "mcrr", __stringify(p15, Op1, %Q0, %R0, CRm), u64
>> +
>> +#define __write_sysreg(v, r, w, c, t)	asm volatile(w " " c : : "r" ((t)(v)))
>> +#define write_sysreg(v, ...)		__write_sysreg(v, __VA_ARGS__)
>> +
>> +#define __read_sysreg(r, w, c, t) ({				\
>> +	t __val;						\
>> +	asm volatile(r " " c : "=r" (__val));			\
>> +	__val;							\
>> +})
>> +#define read_sysreg(...)		__read_sysreg(__VA_ARGS__)
>> +
>>  #endif /* __ARM_KVM_HYP_H__ */
>> -- 
>> 2.1.4
>>
> 
> I sort of figured that a reviewed-by tag on patches that actually use
> these macros would be an implicit review of this code.
> 
> not feeling comfortable enough that I read this jibberish perfectly in
> isolation, but given that the stuff compiles and works, I'll just ack
> it:
> 
> Acked-by: Christoffer Dall <christoffer.dall at linaro.org>
> 

Yeah, this is admittedly cryptic. Despite my efforts, I'm still
considering C (and the preprocessor) as an evolved macro-assembler.

I guess next time, I'll rewrite it in OCaml.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From kernel at martin.sperl.org  Wed Feb 10 09:42:53 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Wed, 10 Feb 2016 18:42:53 +0100
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in
 console
In-Reply-To: <56BB719B.8070007@i2se.com>
References: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
 <56BB719B.8070007@i2se.com>
Message-ID: <3C1ABADD-C0B2-430A-99B3-EAF9B56D0A49@martin.sperl.org>


> On 10.02.2016, at 18:21, Stefan Wahren <stefan.wahren at i2se.com> wrote:
> 
> Hi,
>> Maybe someone has gotten any idea?
> 
> this sounds like an issue i had with the compute module here:
> 
> http://permalink.gmane.org/gmane.linux.kernel.rpi/2197
> 
This one was fixed - if I remember correctly.

> Unfortunately i don't have the cm anymore.
> 
> Maybe you can try this downstream patch:
> 
> https://github.com/raspberrypi/linux/commit/09041f7ccbd1cde792edae91c41266886d5d1382
> 
I wonder if it is really interrupts that are the root cause
to mee it looks like a clock problem - especially as it actually
impacts the PL011 driver and not the aux driver?

And initializing the other way (pl011 is console, aux as tty)
works without any issues - so it HAS to do with accessing the
PL011 or the clock framework.

Martin



From marc.zyngier at arm.com  Wed Feb 10 09:43:54 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 10 Feb 2016 17:43:54 +0000
Subject: [PATCH 7/8] KVM: arm/arm64: Avoid accessing GICH registers
In-Reply-To: <20160210173054.GR5171@cbox>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <1454931622-14902-8-git-send-email-marc.zyngier@arm.com>
 <20160210124506.GN5171@cbox> <56BB3C74.9000105@arm.com>
 <20160210173054.GR5171@cbox>
Message-ID: <56BB76DA.4080905@arm.com>

On 10/02/16 17:30, Christoffer Dall wrote:
> On Wed, Feb 10, 2016 at 01:34:44PM +0000, Marc Zyngier wrote:
>> On 10/02/16 12:45, Christoffer Dall wrote:
>>> On Mon, Feb 08, 2016 at 11:40:21AM +0000, Marc Zyngier wrote:
>>>> GICv2 registers are *slow*. As in "terrifyingly slow". Which is bad.
>>>> But we're equaly bad, as we make a point in accessing them even if
>>>> we don't have any interrupt in flight.
>>>>
>>>> A good solution is to first find out if we have anything useful to
>>>> write into the GIC, and if we don't, to simply not do it. This
>>>> involves tracking which LRs actually have something valid there.
>>>>
>>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>>> ---
>>>>  arch/arm64/kvm/hyp/vgic-v2-sr.c | 71 ++++++++++++++++++++++++++++-------------
>>>>  include/kvm/arm_vgic.h          |  2 ++
>>>>  2 files changed, 51 insertions(+), 22 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/kvm/hyp/vgic-v2-sr.c b/arch/arm64/kvm/hyp/vgic-v2-sr.c
>>>> index e717612..874a08d 100644
>>>> --- a/arch/arm64/kvm/hyp/vgic-v2-sr.c
>>>> +++ b/arch/arm64/kvm/hyp/vgic-v2-sr.c
>>>> @@ -38,28 +38,40 @@ void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
>>>>  
>>>>  	nr_lr = vcpu->arch.vgic_cpu.nr_lr;
>>>>  	cpu_if->vgic_vmcr = readl_relaxed(base + GICH_VMCR);
>>>> -	cpu_if->vgic_misr = readl_relaxed(base + GICH_MISR);
>>>> -	eisr0  = readl_relaxed(base + GICH_EISR0);
>>>> -	elrsr0 = readl_relaxed(base + GICH_ELRSR0);
>>>> -	if (unlikely(nr_lr > 32)) {
>>>> -		eisr1  = readl_relaxed(base + GICH_EISR1);
>>>> -		elrsr1 = readl_relaxed(base + GICH_ELRSR1);
>>>> -	} else {
>>>> -		eisr1 = elrsr1 = 0;
>>>> -	}
>>>> +
>>>> +	if (vcpu->arch.vgic_cpu.live_lrs) {
>>>> +		eisr0  = readl_relaxed(base + GICH_EISR0);
>>>> +		elrsr0 = readl_relaxed(base + GICH_ELRSR0);
>>>> +		cpu_if->vgic_misr = readl_relaxed(base + GICH_MISR);
>>>> +		cpu_if->vgic_apr    = readl_relaxed(base + GICH_APR);
>>>> +
>>>> +		if (unlikely(nr_lr > 32)) {
>>>> +			eisr1  = readl_relaxed(base + GICH_EISR1);
>>>> +			elrsr1 = readl_relaxed(base + GICH_ELRSR1);
>>>> +		} else {
>>>> +			eisr1 = elrsr1 = 0;
>>>> +		}
>>>> +
>>>>  #ifdef CONFIG_CPU_BIG_ENDIAN
>>>> -	cpu_if->vgic_eisr  = ((u64)eisr0 << 32) | eisr1;
>>>> -	cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
>>>> +		cpu_if->vgic_eisr  = ((u64)eisr0 << 32) | eisr1;
>>>> +		cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
>>>>  #else
>>>> -	cpu_if->vgic_eisr  = ((u64)eisr1 << 32) | eisr0;
>>>> -	cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
>>>> +		cpu_if->vgic_eisr  = ((u64)eisr1 << 32) | eisr0;
>>>> +		cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
>>>>  #endif
>>>> -	cpu_if->vgic_apr    = readl_relaxed(base + GICH_APR);
>>>>  
>>>> -	writel_relaxed(0, base + GICH_HCR);
>>>> +		for (i = 0; i < nr_lr; i++)
>>>> +			if (vcpu->arch.vgic_cpu.live_lrs & (1UL << i))
>>>> +				cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
>>>>  
>>>> -	for (i = 0; i < nr_lr; i++)
>>>> -		cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
>>>> +		writel_relaxed(0, base + GICH_HCR);
>>>> +
>>>> +		vcpu->arch.vgic_cpu.live_lrs = 0;
>>>> +	} else {
>>>> +		cpu_if->vgic_eisr = 0;
>>>> +		cpu_if->vgic_elrsr = ~0UL;
>>>> +		cpu_if->vgic_misr = 0;
>>>> +	}
>>>>  }
>>>>  
>>>>  /* vcpu is already in the HYP VA space */
>>>> @@ -70,15 +82,30 @@ void __hyp_text __vgic_v2_restore_state(struct kvm_vcpu *vcpu)
>>>>  	struct vgic_dist *vgic = &kvm->arch.vgic;
>>>>  	void __iomem *base = kern_hyp_va(vgic->vctrl_base);
>>>>  	int i, nr_lr;
>>>> +	u64 live_lrs = 0;
>>>>  
>>>>  	if (!base)
>>>>  		return;
>>>>  
>>>> -	writel_relaxed(cpu_if->vgic_hcr, base + GICH_HCR);
>>>> -	writel_relaxed(cpu_if->vgic_vmcr, base + GICH_VMCR);
>>>> -	writel_relaxed(cpu_if->vgic_apr, base + GICH_APR);
>>>> -
>>>>  	nr_lr = vcpu->arch.vgic_cpu.nr_lr;
>>>> +
>>>>  	for (i = 0; i < nr_lr; i++)
>>>> -		writel_relaxed(cpu_if->vgic_lr[i], base + GICH_LR0 + (i * 4));
>>>> +		if (cpu_if->vgic_lr[i] & GICH_LR_STATE)
>>>> +			live_lrs |= 1UL << i;
>>>> +
>>>> +	if (live_lrs) {
>>>> +		writel_relaxed(cpu_if->vgic_hcr, base + GICH_HCR);
>>>> +		writel_relaxed(cpu_if->vgic_apr, base + GICH_APR);
>>>> +		for (i = 0; i < nr_lr; i++) {
>>>> +			u32 val = 0;
>>>> +
>>>> +			if (live_lrs & (1UL << i))
>>>> +				val = cpu_if->vgic_lr[i];
>>>> +
>>>> +			writel_relaxed(val, base + GICH_LR0 + (i * 4));
>>>> +		}
>>>> +	}
>>>> +
>>>> +	writel_relaxed(cpu_if->vgic_vmcr, base + GICH_VMCR);
>>>
>>> couldn't you optimize this out by storing the last read value and
>>> compare if anything changed?  (you'd have to invalidate the cached value
>>> on vcpu_put obviously).
>>
>> Yeah, very good point. Only the guest can update this, so we could even
>> move it to vcpu_load/vcpu_put entirely, and never save/restore it inside
>> the run loop.
> 
> If vcpu_load is called *after* loading incoming state on migration, this
> should work, yes.

Hmmm. That could be an issue, actually. I need to check if we do a
vcpu_load on SET_ONE_REG access. If we do, then vcpu_put will overwrite
the value we've written in the shadow copies by reading back the old
value from the HW.

I'll investigate when I get the time.

>>
>> I'll keep that for a further patch, as it requires a bit of infrastructure.
>>
> Sounds good.
> 
> We can probably also optimize the writing of the LRs further, but I
> figure it's not worth it as the interrupt delivery path is the slow path
> anyway and we should care about optimizing the common case.
> 
> I wouldn't think saving 2-3 writes to some LRs would be measurable for
> interrupt delivery anyhow.

I found out that some other simple optimizations did save about 800
cycles for a single interrupt injection, which is about 10% of the
complete exit/enter path.

Guilty ones are the maintenance interrupt status registers (MISR, EISR),
and zeroing of LRs. That's with GICv2 though, and GICv3 seems less
sensitive to that kind of thing...

But I agree with you: this is a fairly slow path overall, and we'll
quickly approach the point of diminishing returns.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From will.deacon at arm.com  Wed Feb 10 09:44:55 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 17:44:55 +0000
Subject: [PATCH V1 0/6] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64
In-Reply-To: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
References: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
Message-ID: <20160210174454.GS1052@arm.com>

On Fri, Feb 05, 2016 at 12:13:22PM -0700, Tyler Baicar wrote:
> Add support for Generic Hardware Error Source (GHES) v2, which introduces the
> capability for the OS to acknowledge the consumption of the error record
> generated by the Reliability, Availability and Serviceability (RAS) controller.
> This eliminates potential race conditions between the OS and the RAS controller.
> 
> Add support for the timestamp field added to the Generic Error Data Entry v3,
> allowing the OS to log the time that the error is generated by the firmware,
> rather than the time the error is consumed. This improves the correctness of
> event sequences when analyzing error logs. The timestamp is added in
> ACPI 6.1, reference Table 18-343 Generic Error Data Entry.
> 
> Add support for ARMv8 Common Platform Error Record (CPER) per UEFI 2.6
> specification. ARMv8 specific processor error information is reported as part of
> the CPER records.  This provides more detail on for processor error logs.
> 
> Synchronous External Abort (SEA) represents a specific processor error condition
> in ARM systems. A handler is added to recognize SEA errors, and a notifier is
> added to parse and report the errors before the process is killed. Refer to
> section N.2.1.1 in the Common Platform Error Record appendix of the UEFI 2.6
> specification.
> 
> Depends on: [PATCH v5] acpi, apei, arm64: APEI initial support for aarch64.
>             https://lkml.org/lkml/2015/12/10/131

Did the TLB flushing issue ever get sorted out with that series?

http://marc.info/?l=linux-arm-kernel&m=145009373307418&w=2

It doesn't affect arm64, but I think it's a real issue for x86 when local
invalidation is in effect to avoid IPIs from interrupt context.

Will


From matthias.bgg at gmail.com  Wed Feb 10 09:48:35 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Wed, 10 Feb 2016 18:48:35 +0100
Subject: [PATCH v2 3/3] dts: arm64: Add EFUSE device node
In-Reply-To: <1447930014-19579-4-git-send-email-andrew-ct.chen@mediatek.com>
References: <1447930014-19579-1-git-send-email-andrew-ct.chen@mediatek.com>
 <1447930014-19579-4-git-send-email-andrew-ct.chen@mediatek.com>
Message-ID: <56BB77F3.7030804@gmail.com>

On 19/11/15 11:46, Andrew-CT Chen wrote:
> Add Mediatek MT8173 EFUSE device node
>
> Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
> ---

Applied, thanks.


From ard.biesheuvel at linaro.org  Wed Feb 10 09:55:01 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 10 Feb 2016 18:55:01 +0100
Subject: [PATCH v5sub3 0/4] arm64: KASLR: EFI stub part
Message-ID: <1455126905-22688-1-git-send-email-ard.biesheuvel@linaro.org>

This subseries contains the EFI stub specific changes of my KASLR series
for arm64. The original v4 series can be found here:
http://thread.gmane.org/gmane.linux.kernel/2135931

This series consists of the patches that result in the kernel to be allocated
at a random physical offset on UEFI systems that implement the EFI_RNG_PROTOCOL
protocol (if so configured), and pass a random value in /chosen/kaslr-seed in
the device tree, to be used by the kernel proper to randomize the layout of
the kernel virtual address space.

Changes since v4:
- added R-b's from Matt and Kees (#2
- removed a redundant efi_status_t initializer (#2)
- fixed an issue in update_fdt() (#4) where 'int status' was mistaken for a
  efi_status_t

Patch #1 implements efi_get_random_bytes() based on the EFI_RNG_PROTOCOL

Patch #2 implements efi_random_alloc()

Patch #3 moves the allocation for the converted command line (UTF-16 to ASCII)
away from the base of memory. This is necessary since for parsing the command
line before allocating the kernel image.

Patch #4 implements the actual KASLR, by randomizing the kernel physical
address, and passing entropy in /chosen/kaslr-seed so that the kernel proper can
relocate itself virtually.

Ard Biesheuvel (4):
  efi: stub: implement efi_get_random_bytes() based on EFI_RNG_PROTOCOL
  efi: stub: add implementation of efi_random_alloc()
  efi: stub: use high allocation for converted command line
  arm64: efi: invoke EFI_RNG_PROTOCOL to supply KASLR randomness

 arch/arm64/Kconfig                             |   5 +
 arch/x86/include/asm/efi.h                     |   2 +
 drivers/firmware/efi/libstub/Makefile          |   2 +-
 drivers/firmware/efi/libstub/arm-stub.c        |  40 ++++--
 drivers/firmware/efi/libstub/arm64-stub.c      |  78 +++++++----
 drivers/firmware/efi/libstub/efi-stub-helper.c |   7 +-
 drivers/firmware/efi/libstub/efistub.h         |   7 +
 drivers/firmware/efi/libstub/fdt.c             |  14 ++
 drivers/firmware/efi/libstub/random.c          | 135 ++++++++++++++++++++
 include/linux/efi.h                            |   5 +-
 10 files changed, 257 insertions(+), 38 deletions(-)
 create mode 100644 drivers/firmware/efi/libstub/random.c

-- 
2.5.0



From ard.biesheuvel at linaro.org  Wed Feb 10 09:55:04 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 10 Feb 2016 18:55:04 +0100
Subject: [PATCH v5sub3 3/4] efi: stub: use high allocation for converted
 command line
In-Reply-To: <1455126905-22688-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455126905-22688-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455126905-22688-4-git-send-email-ard.biesheuvel@linaro.org>

Before we can move the command line processing before the allocation
of the kernel, which is required for detecting the 'nokaslr' option
which controls that allocation, move the converted command line higher
up in memory, to prevent it from interfering with the kernel itself.

Since x86 needs the address to fit in 32 bits, use UINT_MAX as the upper
bound there. Otherwise, use ULONG_MAX (i.e., no limit)

Reviewed-by: Matt Fleming <matt at codeblueprint.co.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/x86/include/asm/efi.h                     | 2 ++
 drivers/firmware/efi/libstub/efi-stub-helper.c | 7 ++++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 0010c78c4998..08b1f2f6ea50 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -25,6 +25,8 @@
 #define EFI32_LOADER_SIGNATURE	"EL32"
 #define EFI64_LOADER_SIGNATURE	"EL64"
 
+#define MAX_CMDLINE_ADDRESS	UINT_MAX
+
 #ifdef CONFIG_X86_32
 
 
diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c b/drivers/firmware/efi/libstub/efi-stub-helper.c
index f07d4a67fa76..29ed2f9b218c 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -649,6 +649,10 @@ static u8 *efi_utf16_to_utf8(u8 *dst, const u16 *src, int n)
 	return dst;
 }
 
+#ifndef MAX_CMDLINE_ADDRESS
+#define MAX_CMDLINE_ADDRESS	ULONG_MAX
+#endif
+
 /*
  * Convert the unicode UEFI command line to ASCII to pass to kernel.
  * Size of memory allocated return in *cmd_line_len.
@@ -684,7 +688,8 @@ char *efi_convert_cmdline(efi_system_table_t *sys_table_arg,
 
 	options_bytes++;	/* NUL termination */
 
-	status = efi_low_alloc(sys_table_arg, options_bytes, 0, &cmdline_addr);
+	status = efi_high_alloc(sys_table_arg, options_bytes, 0,
+				&cmdline_addr, MAX_CMDLINE_ADDRESS);
 	if (status != EFI_SUCCESS)
 		return NULL;
 
-- 
2.5.0



From ard.biesheuvel at linaro.org  Wed Feb 10 09:55:02 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 10 Feb 2016 18:55:02 +0100
Subject: [PATCH v5sub3 1/4] efi: stub: implement efi_get_random_bytes() based
 on EFI_RNG_PROTOCOL
In-Reply-To: <1455126905-22688-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455126905-22688-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455126905-22688-2-git-send-email-ard.biesheuvel@linaro.org>

This exposes the firmware's implementation of EFI_RNG_PROTOCOL via a new
function efi_get_random_bytes().

Reviewed-by: Matt Fleming <matt at codeblueprint.co.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/firmware/efi/libstub/Makefile  |  2 +-
 drivers/firmware/efi/libstub/efistub.h |  3 ++
 drivers/firmware/efi/libstub/random.c  | 35 ++++++++++++++++++++
 include/linux/efi.h                    |  5 ++-
 4 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index aaf9c0bab42e..ad077944aa0e 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -36,7 +36,7 @@ lib-$(CONFIG_EFI_ARMSTUB)	+= arm-stub.o fdt.o string.o \
 				   $(patsubst %.c,lib-%.o,$(arm-deps))
 
 lib-$(CONFIG_ARM)		+= arm32-stub.o
-lib-$(CONFIG_ARM64)		+= arm64-stub.o
+lib-$(CONFIG_ARM64)		+= arm64-stub.o random.o
 CFLAGS_arm64-stub.o 		:= -DTEXT_OFFSET=$(TEXT_OFFSET)
 
 #
diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 6b6548fda089..206b7252b9d1 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -43,4 +43,7 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
 		     unsigned long desc_size, efi_memory_desc_t *runtime_map,
 		     int *count);
 
+efi_status_t efi_get_random_bytes(efi_system_table_t *sys_table,
+				  unsigned long size, u8 *out);
+
 #endif
diff --git a/drivers/firmware/efi/libstub/random.c b/drivers/firmware/efi/libstub/random.c
new file mode 100644
index 000000000000..97941ee5954f
--- /dev/null
+++ b/drivers/firmware/efi/libstub/random.c
@@ -0,0 +1,35 @@
+/*
+ * Copyright (C) 2016 Linaro Ltd;  <ard.biesheuvel at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/efi.h>
+#include <asm/efi.h>
+
+#include "efistub.h"
+
+struct efi_rng_protocol {
+	efi_status_t (*get_info)(struct efi_rng_protocol *,
+				 unsigned long *, efi_guid_t *);
+	efi_status_t (*get_rng)(struct efi_rng_protocol *,
+				efi_guid_t *, unsigned long, u8 *out);
+};
+
+efi_status_t efi_get_random_bytes(efi_system_table_t *sys_table_arg,
+				  unsigned long size, u8 *out)
+{
+	efi_guid_t rng_proto = EFI_RNG_PROTOCOL_GUID;
+	efi_status_t status;
+	struct efi_rng_protocol *rng;
+
+	status = efi_call_early(locate_protocol, &rng_proto, NULL,
+				(void **)&rng);
+	if (status != EFI_SUCCESS)
+		return status;
+
+	return rng->get_rng(rng, NULL, size, out);
+}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 569b5a866bb1..13783fdc9bdd 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -299,7 +299,7 @@ typedef struct {
 	void *open_protocol_information;
 	void *protocols_per_handle;
 	void *locate_handle_buffer;
-	void *locate_protocol;
+	efi_status_t (*locate_protocol)(efi_guid_t *, void *, void **);
 	void *install_multiple_protocol_interfaces;
 	void *uninstall_multiple_protocol_interfaces;
 	void *calculate_crc32;
@@ -599,6 +599,9 @@ void efi_native_runtime_setup(void);
 #define EFI_PROPERTIES_TABLE_GUID \
     EFI_GUID(  0x880aaca3, 0x4adc, 0x4a04, 0x90, 0x79, 0xb7, 0x47, 0x34, 0x08, 0x25, 0xe5 )
 
+#define EFI_RNG_PROTOCOL_GUID \
+    EFI_GUID(  0x3152bca5, 0xeade, 0x433d, 0x86, 0x2e, 0xc0, 0x1c, 0xdc, 0x29, 0x1f, 0x44 )
+
 typedef struct {
 	efi_guid_t guid;
 	u64 table;
-- 
2.5.0



From ard.biesheuvel at linaro.org  Wed Feb 10 09:55:03 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 10 Feb 2016 18:55:03 +0100
Subject: [PATCH v5sub3 2/4] efi: stub: add implementation of efi_random_alloc()
In-Reply-To: <1455126905-22688-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455126905-22688-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455126905-22688-3-git-send-email-ard.biesheuvel@linaro.org>

This implements efi_random_alloc(), which allocates a chunk of memory of
a certain size at a certain alignment, and uses the random_seed argument
it receives to randomize the address of the allocation.

This is implemented by iterating over the UEFI memory map, counting the
number of suitable slots (aligned offsets) within each region, and picking
a random number between 0 and 'number of slots - 1' to select the slot,
This should guarantee that each possible offset is chosen equally likely.

Suggested-by: Kees Cook <keescook at chromium.org>
Reviewed-by: Matt Fleming <matt at codeblueprint.co.uk>
Reviewed-by: Kees Cook <keescook at chromium.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/firmware/efi/libstub/efistub.h |   4 +
 drivers/firmware/efi/libstub/random.c  | 100 ++++++++++++++++++++
 2 files changed, 104 insertions(+)

diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
index 206b7252b9d1..5ed3d3f38166 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -46,4 +46,8 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
 efi_status_t efi_get_random_bytes(efi_system_table_t *sys_table,
 				  unsigned long size, u8 *out);
 
+efi_status_t efi_random_alloc(efi_system_table_t *sys_table_arg,
+			      unsigned long size, unsigned long align,
+			      unsigned long *addr, unsigned long random_seed);
+
 #endif
diff --git a/drivers/firmware/efi/libstub/random.c b/drivers/firmware/efi/libstub/random.c
index 97941ee5954f..53f6d3fe6d86 100644
--- a/drivers/firmware/efi/libstub/random.c
+++ b/drivers/firmware/efi/libstub/random.c
@@ -33,3 +33,103 @@ efi_status_t efi_get_random_bytes(efi_system_table_t *sys_table_arg,
 
 	return rng->get_rng(rng, NULL, size, out);
 }
+
+/*
+ * Return the number of slots covered by this entry, i.e., the number of
+ * addresses it covers that are suitably aligned and supply enough room
+ * for the allocation.
+ */
+static unsigned long get_entry_num_slots(efi_memory_desc_t *md,
+					 unsigned long size,
+					 unsigned long align)
+{
+	u64 start, end;
+
+	if (md->type != EFI_CONVENTIONAL_MEMORY)
+		return 0;
+
+	start = round_up(md->phys_addr, align);
+	end = round_down(md->phys_addr + md->num_pages * EFI_PAGE_SIZE - size,
+			 align);
+
+	if (start > end)
+		return 0;
+
+	return (end - start + 1) / align;
+}
+
+/*
+ * The UEFI memory descriptors have a virtual address field that is only used
+ * when installing the virtual mapping using SetVirtualAddressMap(). Since it
+ * is unused here, we can reuse it to keep track of each descriptor's slot
+ * count.
+ */
+#define MD_NUM_SLOTS(md)	((md)->virt_addr)
+
+efi_status_t efi_random_alloc(efi_system_table_t *sys_table_arg,
+			      unsigned long size,
+			      unsigned long align,
+			      unsigned long *addr,
+			      unsigned long random_seed)
+{
+	unsigned long map_size, desc_size, total_slots = 0, target_slot;
+	efi_status_t status;
+	efi_memory_desc_t *memory_map;
+	int map_offset;
+
+	status = efi_get_memory_map(sys_table_arg, &memory_map, &map_size,
+				    &desc_size, NULL, NULL);
+	if (status != EFI_SUCCESS)
+		return status;
+
+	if (align < EFI_ALLOC_ALIGN)
+		align = EFI_ALLOC_ALIGN;
+
+	/* count the suitable slots in each memory map entry */
+	for (map_offset = 0; map_offset < map_size; map_offset += desc_size) {
+		efi_memory_desc_t *md = (void *)memory_map + map_offset;
+		unsigned long slots;
+
+		slots = get_entry_num_slots(md, size, align);
+		MD_NUM_SLOTS(md) = slots;
+		total_slots += slots;
+	}
+
+	/* find a random number between 0 and total_slots */
+	target_slot = (total_slots * (u16)random_seed) >> 16;
+
+	/*
+	 * target_slot is now a value in the range [0, total_slots), and so
+	 * it corresponds with exactly one of the suitable slots we recorded
+	 * when iterating over the memory map the first time around.
+	 *
+	 * So iterate over the memory map again, subtracting the number of
+	 * slots of each entry at each iteration, until we have found the entry
+	 * that covers our chosen slot. Use the residual value of target_slot
+	 * to calculate the randomly chosen address, and allocate it directly
+	 * using EFI_ALLOCATE_ADDRESS.
+	 */
+	for (map_offset = 0; map_offset < map_size; map_offset += desc_size) {
+		efi_memory_desc_t *md = (void *)memory_map + map_offset;
+		efi_physical_addr_t target;
+		unsigned long pages;
+
+		if (target_slot >= MD_NUM_SLOTS(md)) {
+			target_slot -= MD_NUM_SLOTS(md);
+			continue;
+		}
+
+		target = round_up(md->phys_addr, align) + target_slot * align;
+		pages = round_up(size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
+
+		status = efi_call_early(allocate_pages, EFI_ALLOCATE_ADDRESS,
+					EFI_LOADER_DATA, pages, &target);
+		if (status == EFI_SUCCESS)
+			*addr = target;
+		break;
+	}
+
+	efi_call_early(free_pool, memory_map);
+
+	return status;
+}
-- 
2.5.0



From ard.biesheuvel at linaro.org  Wed Feb 10 09:55:05 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 10 Feb 2016 18:55:05 +0100
Subject: [PATCH v5sub3 4/4] arm64: efi: invoke EFI_RNG_PROTOCOL to supply
 KASLR randomness
In-Reply-To: <1455126905-22688-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455126905-22688-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455126905-22688-5-git-send-email-ard.biesheuvel@linaro.org>

Since arm64 does not use a decompressor that supplies an execution
environment where it is feasible to some extent to provide a source of
randomness, the arm64 KASLR kernel depends on the bootloader to supply
some random bits in the /chosen/kaslr-seed DT property upon kernel entry.

On UEFI systems, we can use the EFI_RNG_PROTOCOL, if supplied, to obtain
some random bits. At the same time, use it to randomize the offset of the
kernel Image in physical memory.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/Kconfig                        |  5 ++
 drivers/firmware/efi/libstub/arm-stub.c   | 40 ++++++----
 drivers/firmware/efi/libstub/arm64-stub.c | 78 ++++++++++++++------
 drivers/firmware/efi/libstub/fdt.c        | 14 ++++
 4 files changed, 102 insertions(+), 35 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 666aacc4c763..630b078a0f73 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -785,6 +785,11 @@ config RANDOMIZE_BASE
 	  It is the bootloader's job to provide entropy, by passing a
 	  random u64 value in /chosen/kaslr-seed at kernel entry.
 
+	  When booting via the UEFI stub, it will invoke the firmware's
+	  EFI_RNG_PROTOCOL implementation (if available) to supply entropy
+	  to the kernel proper. In addition, it will randomise the physical
+	  location of the kernel Image as well.
+
 	  If unsure, say N.
 
 config RANDOMIZE_MODULE_REGION_FULL
diff --git a/drivers/firmware/efi/libstub/arm-stub.c b/drivers/firmware/efi/libstub/arm-stub.c
index 3397902e4040..4deb3e7faa0e 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -18,6 +18,8 @@
 
 #include "efistub.h"
 
+bool __nokaslr;
+
 static int efi_secureboot_enabled(efi_system_table_t *sys_table_arg)
 {
 	static efi_guid_t const var_guid = EFI_GLOBAL_VARIABLE_GUID;
@@ -207,14 +209,6 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
 		pr_efi_err(sys_table, "Failed to find DRAM base\n");
 		goto fail;
 	}
-	status = handle_kernel_image(sys_table, image_addr, &image_size,
-				     &reserve_addr,
-				     &reserve_size,
-				     dram_base, image);
-	if (status != EFI_SUCCESS) {
-		pr_efi_err(sys_table, "Failed to relocate kernel\n");
-		goto fail;
-	}
 
 	/*
 	 * Get the command line from EFI, using the LOADED_IMAGE
@@ -224,7 +218,28 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
 	cmdline_ptr = efi_convert_cmdline(sys_table, image, &cmdline_size);
 	if (!cmdline_ptr) {
 		pr_efi_err(sys_table, "getting command line via LOADED_IMAGE_PROTOCOL\n");
-		goto fail_free_image;
+		goto fail;
+	}
+
+	/* check whether 'nokaslr' was passed on the command line */
+	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
+		static const u8 default_cmdline[] = CONFIG_CMDLINE;
+		const u8 *str, *cmdline = cmdline_ptr;
+
+		if (IS_ENABLED(CONFIG_CMDLINE_FORCE))
+			cmdline = default_cmdline;
+		str = strstr(cmdline, "nokaslr");
+		if (str == cmdline || (str > cmdline && *(str - 1) == ' '))
+			__nokaslr = true;
+	}
+
+	status = handle_kernel_image(sys_table, image_addr, &image_size,
+				     &reserve_addr,
+				     &reserve_size,
+				     dram_base, image);
+	if (status != EFI_SUCCESS) {
+		pr_efi_err(sys_table, "Failed to relocate kernel\n");
+		goto fail_free_cmdline;
 	}
 
 	status = efi_parse_options(cmdline_ptr);
@@ -244,7 +259,7 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
 
 		if (status != EFI_SUCCESS) {
 			pr_efi_err(sys_table, "Failed to load device tree!\n");
-			goto fail_free_cmdline;
+			goto fail_free_image;
 		}
 	}
 
@@ -286,12 +301,11 @@ unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
 	efi_free(sys_table, initrd_size, initrd_addr);
 	efi_free(sys_table, fdt_size, fdt_addr);
 
-fail_free_cmdline:
-	efi_free(sys_table, cmdline_size, (unsigned long)cmdline_ptr);
-
 fail_free_image:
 	efi_free(sys_table, image_size, *image_addr);
 	efi_free(sys_table, reserve_size, reserve_addr);
+fail_free_cmdline:
+	efi_free(sys_table, cmdline_size, (unsigned long)cmdline_ptr);
 fail:
 	return EFI_ERROR;
 }
diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c
index 78dfbd34b6bf..e0e6b74fef8f 100644
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -13,6 +13,10 @@
 #include <asm/efi.h>
 #include <asm/sections.h>
 
+#include "efistub.h"
+
+extern bool __nokaslr;
+
 efi_status_t __init handle_kernel_image(efi_system_table_t *sys_table_arg,
 					unsigned long *image_addr,
 					unsigned long *image_size,
@@ -23,26 +27,52 @@ efi_status_t __init handle_kernel_image(efi_system_table_t *sys_table_arg,
 {
 	efi_status_t status;
 	unsigned long kernel_size, kernel_memsize = 0;
-	unsigned long nr_pages;
 	void *old_image_addr = (void *)*image_addr;
 	unsigned long preferred_offset;
+	u64 phys_seed = 0;
+
+	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
+		if (!__nokaslr) {
+			status = efi_get_random_bytes(sys_table_arg,
+						      sizeof(phys_seed),
+						      (u8 *)&phys_seed);
+			if (status == EFI_NOT_FOUND) {
+				pr_efi(sys_table_arg, "EFI_RNG_PROTOCOL unavailable, no randomness supplied\n");
+			} else if (status != EFI_SUCCESS) {
+				pr_efi_err(sys_table_arg, "efi_get_random_bytes() failed\n");
+				return status;
+			}
+		} else {
+			pr_efi(sys_table_arg, "KASLR disabled on kernel command line\n");
+		}
+	}
 
 	/*
 	 * The preferred offset of the kernel Image is TEXT_OFFSET bytes beyond
 	 * a 2 MB aligned base, which itself may be lower than dram_base, as
 	 * long as the resulting offset equals or exceeds it.
 	 */
-	preferred_offset = round_down(dram_base, SZ_2M) + TEXT_OFFSET;
+	preferred_offset = round_down(dram_base, MIN_KIMG_ALIGN) + TEXT_OFFSET;
 	if (preferred_offset < dram_base)
-		preferred_offset += SZ_2M;
+		preferred_offset += MIN_KIMG_ALIGN;
 
-	/* Relocate the image, if required. */
 	kernel_size = _edata - _text;
-	if (*image_addr != preferred_offset) {
-		kernel_memsize = kernel_size + (_end - _edata);
+	kernel_memsize = kernel_size + (_end - _edata);
+
+	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE) && phys_seed != 0) {
+		/*
+		 * If KASLR is enabled, and we have some randomness available,
+		 * locate the kernel at a randomized offset in physical memory.
+		 */
+		*reserve_size = kernel_memsize + TEXT_OFFSET;
+		status = efi_random_alloc(sys_table_arg, *reserve_size,
+					  MIN_KIMG_ALIGN, reserve_addr,
+					  phys_seed);
 
+		*image_addr = *reserve_addr + TEXT_OFFSET;
+	} else {
 		/*
-		 * First, try a straight allocation at the preferred offset.
+		 * Else, try a straight allocation at the preferred offset.
 		 * This will work around the issue where, if dram_base == 0x0,
 		 * efi_low_alloc() refuses to allocate at 0x0 (to prevent the
 		 * address of the allocation to be mistaken for a FAIL return
@@ -52,27 +82,31 @@ efi_status_t __init handle_kernel_image(efi_system_table_t *sys_table_arg,
 		 * Mustang), we can still place the kernel at the address
 		 * 'dram_base + TEXT_OFFSET'.
 		 */
+		if (*image_addr == preferred_offset)
+			return EFI_SUCCESS;
+
 		*image_addr = *reserve_addr = preferred_offset;
-		nr_pages = round_up(kernel_memsize, EFI_ALLOC_ALIGN) /
-			   EFI_PAGE_SIZE;
+		*reserve_size = round_up(kernel_memsize, EFI_ALLOC_ALIGN);
+
 		status = efi_call_early(allocate_pages, EFI_ALLOCATE_ADDRESS,
-					EFI_LOADER_DATA, nr_pages,
+					EFI_LOADER_DATA,
+					*reserve_size / EFI_PAGE_SIZE,
 					(efi_physical_addr_t *)reserve_addr);
-		if (status != EFI_SUCCESS) {
-			kernel_memsize += TEXT_OFFSET;
-			status = efi_low_alloc(sys_table_arg, kernel_memsize,
-					       SZ_2M, reserve_addr);
+	}
 
-			if (status != EFI_SUCCESS) {
-				pr_efi_err(sys_table_arg, "Failed to relocate kernel\n");
-				return status;
-			}
-			*image_addr = *reserve_addr + TEXT_OFFSET;
+	if (status != EFI_SUCCESS) {
+		*reserve_size = kernel_memsize + TEXT_OFFSET;
+		status = efi_low_alloc(sys_table_arg, *reserve_size,
+				       MIN_KIMG_ALIGN, reserve_addr);
+
+		if (status != EFI_SUCCESS) {
+			pr_efi_err(sys_table_arg, "Failed to relocate kernel\n");
+			*reserve_size = 0;
+			return status;
 		}
-		memcpy((void *)*image_addr, old_image_addr, kernel_size);
-		*reserve_size = kernel_memsize;
+		*image_addr = *reserve_addr + TEXT_OFFSET;
 	}
-
+	memcpy((void *)*image_addr, old_image_addr, kernel_size);
 
 	return EFI_SUCCESS;
 }
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index cf7b7d46302a..6dba78aef337 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -147,6 +147,20 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
 	if (status)
 		goto fdt_set_fail;
 
+	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
+		efi_status_t efi_status;
+
+		efi_status = efi_get_random_bytes(sys_table, sizeof(fdt_val64),
+						  (u8 *)&fdt_val64);
+		if (efi_status == EFI_SUCCESS) {
+			status = fdt_setprop(fdt, node, "kaslr-seed",
+					     &fdt_val64, sizeof(fdt_val64));
+			if (status)
+				goto fdt_set_fail;
+		} else if (efi_status != EFI_NOT_FOUND) {
+			return efi_status;
+		}
+	}
 	return EFI_SUCCESS;
 
 fdt_set_fail:
-- 
2.5.0



From horms at verge.net.au  Wed Feb 10 09:55:59 2016
From: horms at verge.net.au (Simon Horman)
Date: Wed, 10 Feb 2016 18:55:59 +0100
Subject: [PATCH v3 7/8] ARM: dts: r8a7790: add iommus to dmac0 and dmac1
In-Reply-To: <1455065878-11906-8-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <1455065878-11906-8-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <20160210175559.GD17671@verge.net.au>

Hi Niklas,

I am deferring accepting this and the similar patch for the r8a7791 pending
acceptance of the driver changes earlier in this series. Please let me know
if you prefer a different course of action.

I notice that the devel branch of there renesas tree there are
dmac nodes for the r8a7793, r8a7794 and r8a7795. Is this change,
also suitable for those SoCs? If so, do you plan to update them?
If not I'll add it to my todo list.


From dhdang at apm.com  Wed Feb 10 09:58:32 2016
From: dhdang at apm.com (Duc Dang)
Date: Wed, 10 Feb 2016 09:58:32 -0800
Subject: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot
 for X-Gene v1
In-Reply-To: <56BB6EA0.7060706@arm.com>
References: <1455069384-22323-1-git-send-email-dhdang@apm.com>
 <56BB6EA0.7060706@arm.com>
Message-ID: <CADaLNDmsSvxSkvM8mG-TRYrmOMTFEKArsL0X=y1zb=20M27iaw@mail.gmail.com>

On Wed, Feb 10, 2016 at 9:08 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 10/02/16 01:56, Duc Dang wrote:
>> This patch makes pci-xgene-msi driver ACPI-aware and provides
>> MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode.
>>
>> Signed-off-by: Duc Dang <dhdang at apm.com>
>
> Another nail on the ACPI "standardization" coffin, I suppose... Oh well.
>
> Acked-by: Marc Zyngier <marc.zyngier at arm.com>

Thanks, Marc.

Regards,
Duc Dang.
>
>         M.
> --
> Jazz is not dead. It just smells funny...


From jonathanh at nvidia.com  Wed Feb 10 10:01:24 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Wed, 10 Feb 2016 18:01:24 +0000
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
Message-ID: <56BB7AF4.8040708@nvidia.com>


On 04/02/16 15:44, Ulf Hansson wrote:
> On 28 January 2016 at 17:33, Jon Hunter <jonathanh at nvidia.com> wrote:
>> Adds generic PM support to the PMC driver where the PM domains are
>> populated from device-tree and the PM domain consumer devices are
>> bound to their relevant PM domains via device-tree as well.
>>
>> Update the tegra_powergate_sequence_power_up() API so that internally
>> it calls the same tegra_powergate_xxx functions that are used by the
>> tegra generic power domain code for consistency.
>>
>> This is based upon work by Thierry Reding <treding at nvidia.com>
>> and Vince Hsu <vinceh at nvidia.com>.
>>
>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
>> ---
>>  drivers/soc/tegra/pmc.c                     | 470 ++++++++++++++++++++++++++--
>>  include/dt-bindings/power/tegra-powergate.h |  36 +++
>>  include/soc/tegra/pmc.h                     |  39 +--
> 
> I suggest you split the header changes into a separate patch.
> 
> Moreover, these new DT definitions should be documented in the patch
> describing the new powergate DT bindings. At least a simple list
> providing the available options.

Ok.

> [...]
> 
>>
>> +static void tegra_powergate_disable_clocks(struct tegra_powergate *pg)
>> +{
>> +       unsigned int i;
>> +
>> +       for (i = 0; i < pg->num_clks; i++)
>> +               clk_disable_unprepare(pg->clks[i]);
>> +}
>> +
>> +static int tegra_powergate_enable_clocks(struct tegra_powergate *pg)
>> +{
>> +       unsigned int i;
>> +       int err;
>> +
>> +       for (i = 0; i < pg->num_clks; i++) {
>> +               err = clk_prepare_enable(pg->clks[i]);
>> +               if (err)
>> +                       goto out;
>> +       }
>> +
>> +       return 0;
>> +
>> +out:
>> +       while (i--)
>> +               clk_disable_unprepare(pg->clks[i]);
>> +
>> +       return err;
>> +}
> 
> I have seen similar code around in other PM domains, dealing with
> enabling/disabling a *list* of clocks.
> Perhaps we should invent a new clock API that helps with this to
> prevents code duplication!?

Yes, I have been thinking about that as well. I will have a look at that.

> [...]
> 
>>  /**
>>   * tegra_powergate_power_on() - power on partition
>>   * @id: partition ID
>> @@ -319,35 +512,20 @@ EXPORT_SYMBOL(tegra_powergate_remove_clamping);
>>  int tegra_powergate_sequence_power_up(unsigned int id, struct clk *clk,
>>                                       struct reset_control *rst)
> 
> There seems to be two viable ways for a driver to control tegra powergates.
> 
> 1)
> $Subject patch enables the use of runtime PM.
> 
> 2)
> The current tegra_powergate_sequence_power_up() and
> tegra_powergate_power_off() API.
> 
> It seems fragile to allow both options, but perhaps your are
> protecting this with some lock to prevent concurrent accesses?

There is a lock protecting accesses to the PMC registers which
ultimately control the power domain. However, may be it would be better
to ensure that any power-domain registered with genpd cannot be
controlled by the legacy APIs. I have added a bitmap to mark valid
power-domains to ensure that only valid power domains can be controlled
by these legacy APIs. I could mark the power-domain invalid after
registering with genpd to ensure that it cannot be accessed by the
legacy APIs.

> Also, I assume you need the two options in a transition phase, before
> you have deployed runtime PM for these drivers?

Right and some of the legacy APIs are entrenched in some drivers. So to
keep the patch set manageable it seems best to get some support in place
then start migrating the drivers.

> [...]
> 
>> +static int tegra_powergate_of_get_clks(struct device *dev,
>> +                                      struct tegra_powergate *pg)
>> +{
>> +       struct clk *clk;
>> +       unsigned int i;
>> +       int err;
>> +
>> +       pg->num_clks = of_count_phandle_with_args(pg->of_node, "clocks",
>> +                                                 "#clock-cells");
>> +       if (pg->num_clks == 0)
>> +               return -ENODEV;
>> +
>> +       pg->clks = devm_kcalloc(dev, pg->num_clks, sizeof(clk), GFP_KERNEL);
>> +       if (!pg->clks)
>> +               return -ENOMEM;
>> +
>> +       for (i = 0; i < pg->num_clks; i++) {
>> +               pg->clks[i] = of_clk_get(pg->of_node, i);
>> +               if (IS_ERR(pg->clks[i])) {
>> +                       err = PTR_ERR(pg->clks[i]);
>> +                       goto err;
>> +               }
>> +       }
>> +
>> +       return 0;
>> +
>> +err:
>> +       while (i--)
>> +               clk_put(pg->clks[i]);
>> +
>> +       pg->num_clks = 0;
>> +
>> +       return err;
>> +}
> 
> Fetching clocks like above function does, seems to be a quite common case.
> 
> As I suggested to add an enable/disable API for a clock list, the
> similar can be done for creating the clock list.
> 
> Just an idea...

Ok.

> [...]
> 
>> +
>> +static void tegra_powergate_remove(struct tegra_pmc *pmc)
>> +{
>> +       struct tegra_powergate *pg, *n;
>> +
>> +       list_for_each_entry_safe(pg, n, &pmc->powergates_list, node) {
> 
> The tegra powergate driver will hold a list of nvidia powergates
> domains, and the generic PM domain will hold a list of all generic PM
> domains.
> 
> Perhaps there's a way to allow the generic PM domain to control this
> by itself. If we for example used the struct device corresponding to
> the powergate driver, genpd could use it to distinguish between
> various instances of genpd structs..!? Maybe it would simplify the way
> to deal with removing domains?

Yes, that would be ideal. However, would have require changing
genpd_init()? I am not sure how genpd would be able to access the device
struct for the powergate driver because we don't provide this via any
API I am aware of? And I am guessing that you don't wish to expose the
gpd_list to the world either.

If there is an easy way, I am open to it, but looking at it today, I am
not sure I see a simple way in which we could add a new API to do this.
However, may be I am missing something!

Cheers
Jon



From ldewangan at nvidia.com  Wed Feb 10 09:50:29 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 10 Feb 2016 23:20:29 +0530
Subject: [PATCH v2] mfd: Provide MACRO to declare commonly defined MFD
 cell attributes
In-Reply-To: <20160210153846.GB26950@x1>
References: <1455028027-1527-1-git-send-email-lee.jones@linaro.org>
 <20160210153846.GB26950@x1>
Message-ID: <56BB7865.3060004@nvidia.com>


On Wednesday 10 February 2016 09:08 PM, Lee Jones wrote:
> mfd: Provide MACRO to declare commonly defined MFD cell attributes
>      
> Cc: Laxman Dewangan <ldewangan at nvidia.com>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Build passed with this patch when using it.

Acked-by: Laxman Dewangan <ldewangan at nvidia.com>

Please let me know if you applying this. I am going to use the macro 
from this patch on max77620 series on next spin.


From will.deacon at arm.com  Wed Feb 10 10:02:11 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 18:02:11 +0000
Subject: [PATCH V1 5/6] arm64: exception: handle instruction abort at
 current EL
In-Reply-To: <1454699608-22760-6-git-send-email-tbaicar@codeaurora.org>
References: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
 <1454699608-22760-6-git-send-email-tbaicar@codeaurora.org>
Message-ID: <20160210180210.GT1052@arm.com>

On Fri, Feb 05, 2016 at 12:13:27PM -0700, Tyler Baicar wrote:
> Add a handler for instruction aborts at the current EL
> (ESR_ELx_EC_IABT_CUR) so they are no longer handled in el1_inv.
> This allows firmware first handling for possible SEA
> (Synchronous External Abort) caused instruction abort at
> current EL.
> 
> Signed-off-by: Tyler Baicar <tbaicar at codeaurora.org>
> Signed-off-by: Naveen Kaje <nkaje at codeaurora.org>
> ---
>  arch/arm64/kernel/entry.S | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 1f7f5a2..6b7fb14 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -336,6 +336,8 @@ el1_sync:
>  	lsr	x24, x1, #ESR_ELx_EC_SHIFT	// exception class
>  	cmp	x24, #ESR_ELx_EC_DABT_CUR	// data abort in EL1
>  	b.eq	el1_da
> +	cmp	x24, #ESR_ELx_EC_IABT_CUR	// instruction abort in EL1
> +	b.eq	el1_ia
>  	cmp	x24, #ESR_ELx_EC_SYS64		// configurable trap
>  	b.eq	el1_undef
>  	cmp	x24, #ESR_ELx_EC_SP_ALIGN	// stack alignment exception
> @@ -363,6 +365,23 @@ el1_da:
>  	// disable interrupts before pulling preserved data off the stack
>  	disable_irq
>  	kernel_exit 1
> +el1_ia:
> +	/*
> +	 * Instruction abort handling
> +	 */
> +	mrs	x0, far_el1
> +	enable_dbg
> +	// re-enable interrupts if they were enabled in the aborted context
> +	tbnz	x23, #7, 1f			// PSR_I_BIT
> +	enable_irq
> +1:
> +	orr	x1, x1, #1 << 24		// use reserved ISS bit for instruction aborts

Do we actually need to set this bit (ESR_LNX_EXEC) for aborts from EL1?
If not, could we just use the same entry code as el1_da?

Will


From will.deacon at arm.com  Wed Feb 10 10:03:33 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 18:03:33 +0000
Subject: [PATCH V1 6/6] acpi: apei: handle SEA notification type for ARMv8
In-Reply-To: <1454699608-22760-7-git-send-email-tbaicar@codeaurora.org>
References: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
 <1454699608-22760-7-git-send-email-tbaicar@codeaurora.org>
Message-ID: <20160210180332.GU1052@arm.com>

On Fri, Feb 05, 2016 at 12:13:28PM -0700, Tyler Baicar wrote:
> ARM APEI extension proposal added SEA (Synchrounous External
> Abort) notification type for ARMv8.
> 
> Add a new GHES error source handling function for SEA. If an error
> source's notification type is SEA, then this function can be registered
> into the SEA exception handler. That way GHES will parse and report
> SEA exceptions when they occur.
> 
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang at codeaurora.org>
> Signed-off-by: Tyler Baicar <tbaicar at codeaurora.org>
> Signed-off-by: Naveen Kaje <nkaje at codeaurora.org>
> ---
>  arch/arm64/Kconfig        |  1 +
>  drivers/acpi/apei/Kconfig | 13 ++++++++
>  drivers/acpi/apei/ghes.c  | 83 +++++++++++++++++++++++++++++++++++++++++++++++
>  include/acpi/actbl1.h     |  6 +++-
>  4 files changed, 102 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 6e4a4f4..236f398 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -6,6 +6,7 @@ config ARM64
>  	select ACPI_REDUCED_HARDWARE_ONLY if ACPI
>  	select ARCH_HAS_DEVMEM_IS_ALLOWED
>  	select HAVE_ACPI_APEI if ACPI
> +	select HAVE_ACPI_APEI_SEA if ACPI
>  	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
>  	select ARCH_HAS_ELF_RANDOMIZE
>  	select ARCH_HAS_GCOV_PROFILE_ALL
> diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
> index a60bb00..bfcbb9e 100644
> --- a/drivers/acpi/apei/Kconfig
> +++ b/drivers/acpi/apei/Kconfig
> @@ -7,6 +7,19 @@ config HAVE_ACPI_APEI_NMI
>  config HAVE_ACPI_APEI_HEST_IA32
>  	bool
>  
> +config HAVE_ACPI_APEI_SEA
> +	bool "APEI Synchronous External Abort logging/recovering support"
> +	help
> +	  This option should be enabled if the system supports
> +	  firmware first handling of SEA (Synchronous External Abort).
> +	  SEA happens with certain faults of data abort or instruction
> +	  abort synchronous exceptions on ARMv8 systems. If a system
> +	  supports firmware first handling of SEA, the platform analyzes
> +	  and handles hardware error notifications with SEA, and it may then
> +	  form a HW error record for the OS to parse and handle. This
> +	  option allows the OS to look for such HW error record, and
> +	  take appropriate action.
> +
>  config ACPI_APEI
>  	bool "ACPI Platform Error Interface (APEI)"
>  	select MISC_FILESYSTEMS
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 6c68100..ed64b97 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -50,6 +50,10 @@
>  #include <acpi/apei.h>
>  #include <asm/tlbflush.h>
>  
> +#ifdef CONFIG_HAVE_ACPI_APEI_SEA
> +#include <asm/system_misc.h>
> +#endif
> +
>  #include "apei-internal.h"
>  
>  #define GHES_PFX	"GHES: "
> @@ -784,6 +788,62 @@ static struct notifier_block ghes_notifier_sci = {
>  	.notifier_call = ghes_notify_sci,
>  };
>  
> +#ifdef CONFIG_HAVE_ACPI_APEI_SEA
> +static LIST_HEAD(ghes_sea);
> +
> +static int ghes_notify_sea(struct notifier_block *this,
> +				  unsigned long event, void *data)
> +{
> +	struct ghes *ghes;
> +	int ret = NOTIFY_DONE;
> +
> +	rcu_read_lock();
> +	list_for_each_entry_rcu(ghes, &ghes_sea, list) {
> +		if (!ghes_proc(ghes))
> +			ret = NOTIFY_OK;
> +	}
> +	rcu_read_unlock();
> +
> +	return ret;
> +}
> +
> +static struct notifier_block ghes_notifier_sea = {
> +	.notifier_call = ghes_notify_sea,
> +};
> +
> +static int ghes_sea_add(struct ghes *ghes)
> +{
> +	mutex_lock(&ghes_list_mutex);

Can you just use spin_lock, to be consistent with our other excception
hooks?

> +	if (list_empty(&ghes_sea))
> +		sea_register_handler_chain(&ghes_notifier_sea);
> +	list_add_rcu(&ghes->list, &ghes_sea);
> +	mutex_unlock(&ghes_list_mutex);
> +	return 0;
> +}
> +
> +static void ghes_sea_remove(struct ghes *ghes)
> +{
> +	mutex_lock(&ghes_list_mutex);
> +	list_del_rcu(&ghes->list);
> +	if (list_empty(&ghes_sea))
> +		sea_unregister_handler_chain(&ghes_notifier_sea);
> +	mutex_unlock(&ghes_list_mutex);
> +}
> +#else /* CONFIG_HAVE_ACPI_APEI_SEA */
> +static inline int ghes_sea_add(struct ghes *ghes)
> +{
> +	pr_err(GHES_PFX "ID: %d, trying to add SEA notification which is not supported\n",
> +	       ghes->generic->header.source_id);
> +	return -ENOTSUPP;
> +}
> +
> +static inline void ghes_sea_remove(struct ghes *ghes)
> +{
> +	pr_err(GHES_PFX "ID: %d, trying to remove SEA notification which is not supported\n",
> +	       ghes->generic->header.source_id);
> +}

Why are these getting called if !CONFIG_HAVE_ACPI_APEI_SEA?

Will


From will.deacon at arm.com  Wed Feb 10 10:03:45 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 18:03:45 +0000
Subject: [PATCH V1 4/6] arm64: exception: handle Synchronous External Abort
In-Reply-To: <1454699608-22760-5-git-send-email-tbaicar@codeaurora.org>
References: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
 <1454699608-22760-5-git-send-email-tbaicar@codeaurora.org>
Message-ID: <20160210180344.GV1052@arm.com>

On Fri, Feb 05, 2016 at 12:13:26PM -0700, Tyler Baicar wrote:
> SEA exceptions are often caused by an uncorrected hardware
> error and are handled when data abort and instruction abort
> exception classes have specific values for their Fault Status
> Code.
> 
> When SEA occurs, before killing the process, go through
> the handlers registered in the notification list.
> 
> Update fault_info[] with specific SEA faults so that the
> new SEA handler is used.
> 
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang at codeaurora.org>
> Signed-off-by: Tyler Baicar <tbaicar at codeaurora.org>
> Signed-off-by: Naveen Kaje <nkaje at codeaurora.org>
> ---
>  arch/arm64/include/asm/system_misc.h | 13 ++++++++
>  arch/arm64/mm/fault.c                | 58 +++++++++++++++++++++++++++++-------
>  2 files changed, 61 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
> index 57f110b..90daf4a 100644
> --- a/arch/arm64/include/asm/system_misc.h
> +++ b/arch/arm64/include/asm/system_misc.h
> @@ -64,4 +64,17 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
>  
>  #endif	/* __ASSEMBLY__ */
>  
> +/*
> + * The functions below are used to register and unregister callbacks
> + * that are to be invoked when a Synchronous External Abort (SEA)
> + * occurs. An SEA is raised by certain fault status codes that have
> + * either data or instruction abort as the exception class, and
> + * callbacks may be registered to parse or handle such hardware errors.
> + *
> + * Registered callbacks are run in an interrupt/atomic context. They
> + * are not allowed to block or sleep.
> + */
> +int sea_register_handler_chain(struct notifier_block *nb);
> +void sea_unregister_handler_chain(struct notifier_block *nb);
> +
>  #endif	/* __ASM_SYSTEM_MISC_H */
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 92ddac1..d6fa691 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -39,6 +39,22 @@
>  #include <asm/pgtable.h>
>  #include <asm/tlbflush.h>
>  
> +/*
> + * GHES SEA handler code may register a notifier call here to
> + * handle HW error record passed from platform.
> + */
> +static ATOMIC_NOTIFIER_HEAD(sea_handler_chain);
> +
> +int sea_register_handler_chain(struct notifier_block *nb)
> +{
> +	return atomic_notifier_chain_register(&sea_handler_chain, nb);
> +}
> +
> +void sea_unregister_handler_chain(struct notifier_block *nb)
> +{
> +	atomic_notifier_chain_unregister(&sea_handler_chain, nb);
> +}
> +
>  static const char *fault_name(unsigned int esr);
>  
>  /*
> @@ -379,6 +395,28 @@ static int do_bad(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>  	return 1;
>  }
>  
> +/*
> + * This abort handler deals with Synchronous External Abort.
> + * It calls notifiers, and then returns "fault".
> + */
> +static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
> +{
> +	struct siginfo info;
> +
> +	atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
> +
> +	pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
> +		 fault_name(esr), esr, addr);
> +
> +	info.si_signo = SIGBUS;
> +	info.si_errno = 0;
> +	info.si_code  = 0;
> +	info.si_addr  = (void __user *)addr;
> +	arm64_notify_die("", regs, &info, esr);

Surely we don't want to call this if the notifier chain handled the
exception?

Will


From matthias.bgg at gmail.com  Wed Feb 10 10:06:27 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Wed, 10 Feb 2016 19:06:27 +0100
Subject: [PATCH 1/2] serial: 8250: fix building mediatek with SERIAL_8250=m
In-Reply-To: <1454935947-2743255-1-git-send-email-arnd@arndb.de>
References: <1454935947-2743255-1-git-send-email-arnd@arndb.de>
Message-ID: <56BB7C23.5070600@gmail.com>



On 08/02/16 13:51, Arnd Bergmann wrote:
> The Mediatek 8250 driver has a 'bool' Kconfig symbol, but that
> breaks when SERIAL_8250 is a loadable module:
>
> drivers/tty/built-in.o: In function `mtk8250_set_termios':
> 8250_ingenic.c:(.text+0x1bee8): undefined reference to `serial8250_do_set_termios'
> 8250_ingenic.c:(.text+0x1bf10): undefined reference to `uart_get_baud_rate'
> 8250_ingenic.c:(.text+0x1c09c): undefined reference to `uart_get_divisor'
> drivers/tty/built-in.o: In function `mtk8250_do_pm':
> 8250_ingenic.c:(.text+0x1c0d0): undefined reference to `serial8250_do_pm'
> drivers/tty/built-in.o: In function `mtk8250_probe':
> 8250_ingenic.c:(.text+0x1c2e4): undefined reference to `serial8250_register_8250_port'
> serial/8250/8250_mtk.c:287:242: error: data definition has no type or storage class [-Werror]
> serial/8250/8250_mtk.c:287:122: error: 'mtk8250_platform_driver_init' defined but not used [-Werror=unused-function]
>
> This changes the symbol to a 'tristate', so the dependency on
> SERIAL_8250 also works when that is set to 'm'.
> To actually build the driver, we also need to include <linux/module.h>.
>
> Note that the driver uses builtin_platform_driver() and implements
> no .remove() callback, so unloading the module is not possible.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---

I tried this with:
commit 2178cbc68f3602dc0b5949b9be2c8383ad3d93ef

$ grep 8250 .config
CONFIG_SERIAL_8250=m
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_PCI=m
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_RT288X is not set
CONFIG_SERIAL_8250_MT6577=y
# CONFIG_SERIAL_8250_INGENIC is not set
# CONFIG_SERIAL_8250_MID is not set

$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- drivers/tty/

compiles just fine.

Do I missing something?

Regards,
Matthias


From ddaney at caviumnetworks.com  Wed Feb 10 10:08:17 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Wed, 10 Feb 2016 10:08:17 -0800
Subject: [PATCH] arm64: Add workaround for Cavium erratum 27456
In-Reply-To: <20160210092822.GA1052@arm.com>
References: <1455046156-10582-1-git-send-email-ddaney.cavm@gmail.com>
 <20160210092822.GA1052@arm.com>
Message-ID: <56BB7C91.5010205@caviumnetworks.com>

On 02/10/2016 01:28 AM, Will Deacon wrote:
> On Tue, Feb 09, 2016 at 11:29:16AM -0800, David Daney wrote:
>> From: Andrew Pinski <apinski at cavium.com>
>>
>> On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
>> instructions may cause the icache to become invalid if it contains
>> data for a non-current ASID.
>>
>> This patch implements the workaround (which flushes the local icache
>> when switching the mm) by using code patching.
>
> So, to be clear, is this "just" a performance problem as opposed to a
> correctness issue?

No.  It is a correctness issue.  Without this workaround in place, 
userspace programs end up executing the wrong instructions, which leads 
to unpredictable behavior and program crashes.


> If so, do you have any numbers with and without this
> change?

We tried to measure it, but the impact is not measurable in the tests we 
have done.  Switching the mm is not often done so the extra ICache 
invalidation is rare.

Also note that for the non-workaround case, the code path is unchanged. 
  Since the following function (__cpu_setup()) is not on the hot path of 
anything, any extra ICache pressure from the three NOPs is unlikely to 
matter.

>
> Will
>



From sergei.shtylyov at cogentembedded.com  Wed Feb 10 10:09:06 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Feb 2016 21:09:06 +0300
Subject: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
In-Reply-To: <874mdhtn7d.wl%kuninori.morimoto.gx@renesas.com>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
 <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
 <874mdhtn7d.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <56BB7CC2.1060706@cogentembedded.com>

Hello.

On 02/10/2016 03:41 AM, Kuninori Morimoto wrote:

> Sorry for my un-ordered response

    Not sure what you mean by that. :-)

>> Define the generic R8A7794 part of  the sound device node.
>> This sound device  is a complex one and comprises the Audio Clock Generator
>> (ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
>> (SSI[U]), and Audio DMAC-Peripheral-Peripheral.
>> It is up  to the board file to enable the device.
>>
>> This patch is based on the R8A7791 sound work by Kuninori Morimoto.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> (snip)
>> +		rcar_sound,src {
>> +			src1: src at 1 {
>> +				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x87>, <&audma0 0x9c>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +			src2: src at 2 {
>> +				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x89>, <&audma0 0x9e>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +			src3: src at 3 {
>> +				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +			src4: src at 4 {
>> +				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +			src5: src at 5 {
>> +				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +			src6: src at 6 {
>> +				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
>> +				dmas = <&audma0 0x91>, <&audma0 0xb4>;
>> +				dma-names = "rx", "tx";
>> +			};
>> +		};
>
> I think this can't work correctly, because driver is assuming
> DT has all channles (from 0). (see linux/sound/soc/sh/rcar/src.c :: rsnd_src_probe)

    At least it doesn't crash and burn. :-)
    Playback and recording still work too.

> Can you adds dummy src0 with some comments ?

    Don't think that's an option. We are supposed to describe the hardware, 
not the driver's behavior.

> or fix src.c driver ?

    Will try to look into it...

MBR, Sergei



From gregory.clement at free-electrons.com  Wed Feb 10 10:09:20 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed, 10 Feb 2016 19:09:20 +0100
Subject: [PATCH v2 0/6] irqchip: irq-armada-370-xp: generic MSI
 infrastructure and assorted fixes
In-Reply-To: <20160210153829.GA5183@io.lakedaemon.net> (Jason Cooper's message
 of "Wed, 10 Feb 2016 15:38:29 +0000")
References: <1453899395-3532-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160210150046.118fc991@free-electrons.com>
 <56BB4451.3070707@arm.com> <20160210153829.GA5183@io.lakedaemon.net>
Message-ID: <87mvr8xwrz.fsf@free-electrons.com>

Hi Jason,
 
 On mer., f?vr. 10 2016, Jason Cooper <jason at lakedaemon.net> wrote:

> On Wed, Feb 10, 2016 at 02:08:17PM +0000, Marc Zyngier wrote:
>> On 10/02/16 14:00, Thomas Petazzoni wrote:
>> > Hello,
>> > 
>> > On Wed, 27 Jan 2016 13:56:29 +0100, Thomas Petazzoni wrote:
>> > 
>> >> Thomas Petazzoni (6):
>> >>   irqchip: irq-armada-370-xp: add Kconfig option for the driver
>> >>   irqchip: irq-armada-370-xp: use the generic MSI infrastructure
>> >>   irqchip: irq-armada-370-xp: use PCI_MSI_DOORBELL_START where
>> >>     appropriate
>> >>   irqchip: irq-armada-370-xp: use shorter names for irq_chip
>> >>   irqchip: irq-armada-370-xp: allow allocation of multiple MSIs
>> >>   ARM: mvebu: use the ARMADA_370_XP_IRQ option
>> > 
>> > Jason, Thomas, any chance to get this applied soonish?
>> > 
>> > The core patch of the series, which migrates the irq-armada-370-xp
>> > driver to use the generic MSI infrastructure has been Reviewed-by: Marc
>> > Zyngier, and the other patches in the series have Acked-by/Reviewed-by
>> > from Gregory Clement.
>> > 
>> > Of course, if there's anything left to be changed, I'd be happy to
>> > respin a new version of this series.
>> > 
>> 
>> Noticing the distribution list, it would be good to repost these patches
>> with acks and co to LKML...
>
> agreed, and I'll pick it up within the next day or so.  Still getting my
> home network setup... too much wifi. :(

I proposed that you take the 6th patch to ensure that this driver will
always be selected for the mvebu platform which need it. It is still OK
but, since this offer, I sent a series which depend of the 1st patch:
http://thread.gmane.org/gmane.linux.ide/61178

Would you agree to provide an immutable tag containing the first patch?
Thanks to this I will be able to provide it to the arm-soc maintainer
for my pull request.

Thanks,

Gregory

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From sergei.shtylyov at cogentembedded.com  Wed Feb 10 10:10:43 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 10 Feb 2016 21:10:43 +0300
Subject: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
In-Reply-To: <87lh6ts1o0.wl%kuninori.morimoto.gx@renesas.com>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
 <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
 <87lh6ts1o0.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <56BB7D23.3010005@cogentembedded.com>

On 02/10/2016 06:12 AM, Kuninori Morimoto wrote:

>> Define the generic R8A7794 part of  the sound device node.
>> This sound device  is a complex one and comprises the Audio Clock Generator
>> (ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
>> (SSI[U]), and Audio DMAC-Peripheral-Peripheral.
>> It is up  to the board file to enable the device.
>>
>> This patch is based on the R8A7791 sound work by Kuninori Morimoto.
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> (snip)
>> +		clocks = <&mstp10_clks R8A7794_CLK_SSI_ALL>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI9>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI8>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI7>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI6>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI5>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI4>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI3>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI2>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI1>,
>> +			 <&mstp10_clks R8A7794_CLK_SSI0>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC9>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC8>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC7>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC6>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC5>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC4>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC3>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC2>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC1>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_SRC0>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU0_MIX0>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_CTU1_MIX1>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_DVC0>,
>> +			 <&mstp10_clks R8A7794_CLK_SCU_DVC1>,
>> +			 <&audio_clka>, <&audio_clkb>, <&audio_clkc>,
>> +			 <&m2_clk>;
>> +		clock-names = "ssi-all",
>> +			      "ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
>> +			      "ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0",
>> +			      "src.9", "src.8", "src.7", "src.6", "src.5",
>> +			      "src.4", "src.3", "src.2", "src.1", "src.0",
>> +			      "ctu.0", "ctu.1",
>> +			      "mix.0", "mix.1",
>> +			      "dvc.0", "dvc.1",
>> +			      "clk_a", "clk_b", "clk_c", "clk_i";
>
> I'm sorry about my previous email. I think I made you confuse.
> I meant you can remove CTU/MIX field if your patch doesn't care these.

    No, I got your idea right.
    But I decided to go for a more complete hardware representation, on par 
with the other R-Car SoCs.

MBR, Sergei



From yang.shi at linaro.org  Wed Feb 10 10:12:11 2016
From: yang.shi at linaro.org (Shi, Yang)
Date: Wed, 10 Feb 2016 10:12:11 -0800
Subject: [PATCH] arm64: use raw_smp_processor_id in stack backtrace dump
In-Reply-To: <20160210121030.GH1052@arm.com>
References: <1455053182-31404-1-git-send-email-yang.shi@linaro.org>
 <20160210102939.GD1052@arm.com> <56BB247F.6040202@arm.com>
 <20160210121030.GH1052@arm.com>
Message-ID: <56BB7D7B.4060002@linaro.org>

On 2/10/2016 4:10 AM, Will Deacon wrote:
> On Wed, Feb 10, 2016 at 11:52:31AM +0000, James Morse wrote:
>> On 10/02/16 10:29, Will Deacon wrote:
>>> On Tue, Feb 09, 2016 at 01:26:22PM -0800, Yang Shi wrote:
>>>> dump_backtrace may be called in kthread context, which is not bound to a single
>>>> cpu, i.e. khungtaskd, then calling smp_processor_id may trigger the below bug
>>>> report:
>>>
>>> If we're preemptible here, it means that our irq_stack_ptr is potentially
>>> bogus. Whilst this isn't an issue for kthreads, it does feel like we
>>> could make this slightly more robust in the face of potential frame
>>> corruption. Maybe just zero the IRQ stack pointer if we're in preemptible
>>> context?
>>
>> Switching between stacks is only valid if we are tracing ourselves while on the
>> irq_stack, we should probably prevent it for other tasks too.
>>
>> Something like (untested):
>> ---------------------
>> if (tsk == current && in_atomic())
>> 	irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());

One follow up question, is it possible to have both tsk != current and 
on_irq_stack is true at the same time? If it is possible, this may be a 
problem in unwind_frame called by profile_pc which has tsk being NULL.

Thanks,
Yang

>> else
>> 	irq_stack_ptr = 0;
>> ---------------------
>>
>> This would work when we trace ourselves while on the irq_stack, but break*
>> tracing a running task on a remote cpu (khungtaskd doesn't do this).
>>
>> The same fix would apply to unwind_frame(), we have 'tsk' in both functions.
>>
>> Thoughts?
>
> in_atomic is a misnomer:
>
>    https://lwn.net/Articles/274695/
>
> ;)
>
> So we might be better off zeroing the pointer if tsk != current ||
> preemptible(). But yeah, I think we're in general agreement about this.
>
> Will
>



From jason at lakedaemon.net  Wed Feb 10 10:13:26 2016
From: jason at lakedaemon.net (Jason Cooper)
Date: Wed, 10 Feb 2016 18:13:26 +0000
Subject: [PATCH v2 0/6] irqchip: irq-armada-370-xp: generic MSI
 infrastructure and assorted fixes
In-Reply-To: <87mvr8xwrz.fsf@free-electrons.com>
References: <1453899395-3532-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160210150046.118fc991@free-electrons.com>
 <56BB4451.3070707@arm.com>
 <20160210153829.GA5183@io.lakedaemon.net>
 <87mvr8xwrz.fsf@free-electrons.com>
Message-ID: <20160210181325.GB5183@io.lakedaemon.net>

On Wed, Feb 10, 2016 at 07:09:20PM +0100, Gregory CLEMENT wrote:
> Hi Jason,
>  
>  On mer., f?vr. 10 2016, Jason Cooper <jason at lakedaemon.net> wrote:
> 
> > On Wed, Feb 10, 2016 at 02:08:17PM +0000, Marc Zyngier wrote:
> >> On 10/02/16 14:00, Thomas Petazzoni wrote:
> >> > Hello,
> >> > 
> >> > On Wed, 27 Jan 2016 13:56:29 +0100, Thomas Petazzoni wrote:
> >> > 
> >> >> Thomas Petazzoni (6):
> >> >>   irqchip: irq-armada-370-xp: add Kconfig option for the driver
> >> >>   irqchip: irq-armada-370-xp: use the generic MSI infrastructure
> >> >>   irqchip: irq-armada-370-xp: use PCI_MSI_DOORBELL_START where
> >> >>     appropriate
> >> >>   irqchip: irq-armada-370-xp: use shorter names for irq_chip
> >> >>   irqchip: irq-armada-370-xp: allow allocation of multiple MSIs
> >> >>   ARM: mvebu: use the ARMADA_370_XP_IRQ option
> >> > 
> >> > Jason, Thomas, any chance to get this applied soonish?
> >> > 
> >> > The core patch of the series, which migrates the irq-armada-370-xp
> >> > driver to use the generic MSI infrastructure has been Reviewed-by: Marc
> >> > Zyngier, and the other patches in the series have Acked-by/Reviewed-by
> >> > from Gregory Clement.
> >> > 
> >> > Of course, if there's anything left to be changed, I'd be happy to
> >> > respin a new version of this series.
> >> > 
> >> 
> >> Noticing the distribution list, it would be good to repost these patches
> >> with acks and co to LKML...
> >
> > agreed, and I'll pick it up within the next day or so.  Still getting my
> > home network setup... too much wifi. :(
> 
> I proposed that you take the 6th patch to ensure that this driver will
> always be selected for the mvebu platform which need it. It is still OK
> but, since this offer, I sent a series which depend of the 1st patch:
> http://thread.gmane.org/gmane.linux.ide/61178

I saw that. ;-)

> Would you agree to provide an immutable tag containing the first patch?
> Thanks to this I will be able to provide it to the arm-soc maintainer
> for my pull request.

Sure, that's my default MO since most of the time, people only touch
irqchip drivers when they are changing something else.  Thus, there's
usually a dependency on the irqchip changes.

thx,

Jason.


From will.deacon at arm.com  Wed Feb 10 10:15:22 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 10 Feb 2016 18:15:22 +0000
Subject: [PATCH] arm64: Add workaround for Cavium erratum 27456
In-Reply-To: <56BB7C91.5010205@caviumnetworks.com>
References: <1455046156-10582-1-git-send-email-ddaney.cavm@gmail.com>
 <20160210092822.GA1052@arm.com>
 <56BB7C91.5010205@caviumnetworks.com>
Message-ID: <20160210181522.GW1052@arm.com>

On Wed, Feb 10, 2016 at 10:08:17AM -0800, David Daney wrote:
> On 02/10/2016 01:28 AM, Will Deacon wrote:
> >On Tue, Feb 09, 2016 at 11:29:16AM -0800, David Daney wrote:
> >>From: Andrew Pinski <apinski at cavium.com>
> >>
> >>On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
> >>instructions may cause the icache to become invalid if it contains
> >>data for a non-current ASID.
> >>
> >>This patch implements the workaround (which flushes the local icache
> >>when switching the mm) by using code patching.
> >
> >So, to be clear, is this "just" a performance problem as opposed to a
> >correctness issue?
> 
> No.  It is a correctness issue.  Without this workaround in place, userspace
> programs end up executing the wrong instructions, which leads to
> unpredictable behavior and program crashes.

Ok, so I think the description in the commit log isn't quite right. An
"invalid" line in i-cache simply means that it needs to be refetched.
What you're talking about sounds like data corruption.

I also don't understand how the workaround fixes things like TLBIs due
to copy-on-write faults triggered by another core. Also, what's the
interaction with virtual machines, or is the VMID not affected in the
same way as the ASID?

Sorry to be a pain on this, but we need to understand the issue well
enough to maintain the workaround in the future!

> >If so, do you have any numbers with and without this
> >change?
> 
> We tried to measure it, but the impact is not measurable in the tests we
> have done.  Switching the mm is not often done so the extra ICache
> invalidation is rare.

Oh, sure. I was only interested in perf figures if this was a performance
problem rather than a functional one.

Will


From ivo.g.dimitrov.75 at gmail.com  Wed Feb 10 10:23:02 2016
From: ivo.g.dimitrov.75 at gmail.com (Ivaylo Dimitrov)
Date: Wed, 10 Feb 2016 20:23:02 +0200
Subject: [PATCH v1] ARM: RX51: Set system_rev from ATAGS
In-Reply-To: <20160209161659.GJ19432@atomide.com>
References: <20160209161659.GJ19432@atomide.com>
Message-ID: <1455128582-25669-1-git-send-email-ivo.g.dimitrov.75@gmail.com>

This fixed a regression with DT boot compared to legacy boot.

Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com>
---
 arch/arm/mach-omap2/board-generic.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 8098272..bab814d 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -18,6 +18,7 @@
 
 #include <asm/setup.h>
 #include <asm/mach/arch.h>
+#include <asm/system_info.h>
 
 #include "common.h"
 
@@ -77,12 +78,31 @@ static const char *const n900_boards_compat[] __initconst = {
 	NULL,
 };
 
+/* Set system_rev from atags */
+static void __init rx51_set_system_rev(const struct tag *tags)
+{
+	const struct tag *tag;
+
+	if (tags->hdr.tag != ATAG_CORE)
+		return;
+
+	for_each_tag(tag, tags) {
+		if (tag->hdr.tag == ATAG_REVISION) {
+			system_rev = tag->u.revision.rev;
+			break;
+		}
+	}
+}
+
 /* Legacy userspace on Nokia N900 needs ATAGS exported in /proc/atags,
  * save them while the data is still not overwritten
  */
 static void __init rx51_reserve(void)
 {
-	save_atags((const struct tag *)(PAGE_OFFSET + 0x100));
+	const struct tag *tags = (const struct tag *)(PAGE_OFFSET + 0x100);
+
+	save_atags(tags);
+	rx51_set_system_rev(tags);
 	omap_reserve();
 }
 
-- 
1.9.1



From ulf.hansson at linaro.org  Wed Feb 10 10:25:08 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Wed, 10 Feb 2016 19:25:08 +0100
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <56BB7AF4.8040708@nvidia.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
 <56BB7AF4.8040708@nvidia.com>
Message-ID: <CAPDyKFrZ6tWBsQC0tyWWeChiZja3h_zcbaiX25ak-Zyp4MzqVw@mail.gmail.com>

[...]

>>
>>>  /**
>>>   * tegra_powergate_power_on() - power on partition
>>>   * @id: partition ID
>>> @@ -319,35 +512,20 @@ EXPORT_SYMBOL(tegra_powergate_remove_clamping);
>>>  int tegra_powergate_sequence_power_up(unsigned int id, struct clk *clk,
>>>                                       struct reset_control *rst)
>>
>> There seems to be two viable ways for a driver to control tegra powergates.
>>
>> 1)
>> $Subject patch enables the use of runtime PM.
>>
>> 2)
>> The current tegra_powergate_sequence_power_up() and
>> tegra_powergate_power_off() API.
>>
>> It seems fragile to allow both options, but perhaps your are
>> protecting this with some lock to prevent concurrent accesses?
>
> There is a lock protecting accesses to the PMC registers which
> ultimately control the power domain. However, may be it would be better
> to ensure that any power-domain registered with genpd cannot be
> controlled by the legacy APIs. I have added a bitmap to mark valid
> power-domains to ensure that only valid power domains can be controlled
> by these legacy APIs. I could mark the power-domain invalid after
> registering with genpd to ensure that it cannot be accessed by the
> legacy APIs.

That seems like a good way of making it more robust!

>
>> Also, I assume you need the two options in a transition phase, before
>> you have deployed runtime PM for these drivers?
>
> Right and some of the legacy APIs are entrenched in some drivers. So to
> keep the patch set manageable it seems best to get some support in place
> then start migrating the drivers.

Thanks for elaborating on this! I get and like the idea of moving forward!

[...]

>>> +
>>> +static void tegra_powergate_remove(struct tegra_pmc *pmc)
>>> +{
>>> +       struct tegra_powergate *pg, *n;
>>> +
>>> +       list_for_each_entry_safe(pg, n, &pmc->powergates_list, node) {
>>
>> The tegra powergate driver will hold a list of nvidia powergates
>> domains, and the generic PM domain will hold a list of all generic PM
>> domains.
>>
>> Perhaps there's a way to allow the generic PM domain to control this
>> by itself. If we for example used the struct device corresponding to
>> the powergate driver, genpd could use it to distinguish between
>> various instances of genpd structs..!? Maybe it would simplify the way
>> to deal with removing domains?
>
> Yes, that would be ideal. However, would have require changing
> genpd_init()? I am not sure how genpd would be able to access the device
> struct for the powergate driver because we don't provide this via any
> API I am aware of? And I am guessing that you don't wish to expose the
> gpd_list to the world either.
>
> If there is an easy way, I am open to it, but looking at it today, I am
> not sure I see a simple way in which we could add a new API to do this.
> However, may be I am missing something!

If we add a new __pm_genpd_init() API, that could require a struct
device to be provided. That API will thus invoke the existing
pm_genpd_init() but also deal with the extra things needed here.

I would also allow such an API to return an error code.

Correspondingly, pm_genpd_remove() could be required to be provided
with a struct device.

Existing users of pm_genpd_init() can then convert to
__pm_genpd_init() whenever suitable.

Of course, another option is just to add new member in the genpd
struct for the struct *device. The caller of pm_genpd_init() could
check it, but allow it to be NULL. Although, the pm_genpd_remove() API
would require that pointer to the struct device to be set...

What do you think?

Kind regards
Uffe


From sboyd at codeaurora.org  Wed Feb 10 10:35:04 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 10 Feb 2016 10:35:04 -0800
Subject: [PATCH 01/14] mfd: intel_quark_i2c_gpio: Use clkdev_create()
In-Reply-To: <20160210162349.GJ3782@x1>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
 <1454982341-22715-2-git-send-email-sboyd@codeaurora.org>
 <20160210162349.GJ3782@x1>
Message-ID: <20160210183504.GG30978@codeaurora.org>

On 02/10, Lee Jones wrote:
> On Mon, 08 Feb 2016, Stephen Boyd wrote:
> 
> > Convert this driver to use clkdev_create() instead of
> > clk_register_clkdevs(). The latter API is only used by this driver,
> > although this driver only allocates one clk to add anyway.
> > Furthermore, this driver allocates the clk_lookup structure with
> > devm, but clkdev_drop() will free that structure when passed,
> > leading to a double free when this driver is removed. Clean it
> > all up and pave the way for the removal of clk_register_clkdevs().
> > 
> > Cc: Lee Jones <lee.jones at linaro.org>
> > Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> > Cc: Russell King <linux at arm.linux.org.uk>
> > Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> > ---
> >  drivers/mfd/intel_quark_i2c_gpio.c | 26 +++++++++-----------------
> >  1 file changed, 9 insertions(+), 17 deletions(-)
> 
> I never much liked this code [0]
> 
> Glad for it to be simplified.
> 
> Applied, thanks.
> 

Can you please ack the patch instead? I'd like to take it through
the clk tree so that I can remove clk_register_clkdevs() as well.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From shaun.ren at linux.com  Wed Feb 10 10:38:20 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Wed, 10 Feb 2016 10:38:20 -0800
Subject: [PATCH v2 7/9] Staging: rts5208: rtsx_transport.c: Remove
 unnecessary parentheses
In-Reply-To: <20160210052641.GC27755@sudip-pc>
References: <1453775248-15965-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-1-git-send-email-shaun.ren@linux.com>
 <1454981485-15686-8-git-send-email-shaun.ren@linux.com>
 <20160210052641.GC27755@sudip-pc>
Message-ID: <87k2mc76ni.fsf@linux.com>


On Tue 2016-02-09 at 21:26 (-0800), Sudip Mukherjee wrote:
> On Mon, Feb 08, 2016 at 05:31:23PM -0800, Shaun Ren wrote:
>> This patch removes all unnecessary parentheses found by checkpatch.pl.
>> 
>> Signed-off-by: Shaun Ren <shaun.ren at linux.com>
>
> This will not apply anymore because of some other changes done by:
> 9a66d05d82db ("Staging: rts5208: fix check for dma mapping error")

I don't see that commit anywhere. Is it in linux-next?

Regards,
--
Shaun Ren



From thomas at schloeter.net  Wed Feb 10 10:40:54 2016
From: thomas at schloeter.net (=?utf-8?Q?Thomas_Schl=C3=B6ter?=)
Date: Wed, 10 Feb 2016 19:40:54 +0100
Subject: net: mv643xx: interface does not transmit after some time
In-Reply-To: <312E318A-CAE1-45B1-AB13-EA147B48E315@schloeter.net>
References: <E4F9E0D0-9DA8-4E33-9F89-B49E47F11CE0@schloeter.net>
 <20160206183414.GD17218@lunn.ch> <20160206231935.GA30734@jirafa.cyrius.com>
 <2ACB3A0B-DD51-43C1-A56E-E7C175645554@schloeter.net>
 <20160207203545.GB29107@lunn.ch>
 <A21B89D4-5826-4F97-A1C9-E62E5B724082@schloeter.net>
 <312E318A-CAE1-45B1-AB13-EA147B48E315@schloeter.net>
Message-ID: <A6128DBC-59DB-4231-A08D-B84C1D8C26CC@schloeter.net>


> Am 08.02.2016 um 19:49 schrieb Thomas Schl?ter <thomas at schloeter.net>:
> 
> 
>> Am 07.02.2016 um 22:07 schrieb Thomas Schl?ter <thomas at schloeter.net>:
>> 
>> Am 07.02.2016 um 21:35 schrieb Andrew Lunn <andrew at lunn.ch>:
>>> 
>>>>> FWIW, we had a similar bug report in Debian recently:
>>>>> https://lists.debian.org/debian-arm/2016/01/msg00098.html
>>> 
>>> Hi Thomas
>>> 
>>> I this thread, Ian Campbell mentions a patch. Please could you try
>>> that patch and see if it fixes your problem.
>>> 
>>> Thanks
>>> 	Andrew
>> 
>> Hi Andrew,
>> 
>> I just applied the patch and the NAS is now running it. I?ll try to crash it tonight and keep you informed whether it worked.
>> 
>> Thanks
>> 	Thomas
> 
> Hi Andrew,
> 
> the patch did not fix the problem. After 1.2 GiB RX and 950 MiB TX, the interface crashed again.
> 
> Now I switched off RX/TX offload just to make sure we are talking about the same problem. If we are, the interface should be stable without offload, right?
> 
> 	Thomas

Okay, so I have installed ethtool and switched off all offload features available. Now the NAS is running rock solid for two days. I backed up my Mac using Time Machine / netatalk (450 GiB transferred) and some Linux machines via NFS (100 GiB total) without a problem.

How much code is used for mv643xx offload functionality?
Is it possible to debug things in the driver and figure out what happens during the crash?
Is the hardware offload interface proprietary or reverse engineered or is it a well known API that can be analyzed?

	Thomas

From mark.rutland at arm.com  Wed Feb 10 10:41:12 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 10 Feb 2016 18:41:12 +0000
Subject: [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused
In-Reply-To: <20160210125936.GD31506@lukather>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <20160210125936.GD31506@lukather>
Message-ID: <20160210184112.GC28728@leverpostej>

On Wed, Feb 10, 2016 at 01:59:36PM +0100, Maxime Ripard wrote:
> > Also this totally ignores any other DT user (U-Boot, FreeBSD, you
> > name it).
> 
> Which all have their own DT copies, with their own bindings, that we
> (ie Linux) never agreed on.

The FreeBSD guys are actually trying to align with the Linux DTs, which
they periodically import (at least for arm64). From everything I've seen
the U-Boot guys generally want to align with Linux, and have been
attempting to some extent to do so (e.g. submitting bindings).

So if anything, Linux DTs are being used by others who didn't have much
say on them, rather than the other way around.

Regardless, the existece of fragmentation is not a good argument for
more fragmentation.

Thanks,
Mark.


From ddaney at caviumnetworks.com  Wed Feb 10 10:42:18 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Wed, 10 Feb 2016 10:42:18 -0800
Subject: [PATCH] arm64: Add workaround for Cavium erratum 27456
In-Reply-To: <20160210181522.GW1052@arm.com>
References: <1455046156-10582-1-git-send-email-ddaney.cavm@gmail.com>
 <20160210092822.GA1052@arm.com> <56BB7C91.5010205@caviumnetworks.com>
 <20160210181522.GW1052@arm.com>
Message-ID: <56BB848A.6060603@caviumnetworks.com>

On 02/10/2016 10:15 AM, Will Deacon wrote:
> On Wed, Feb 10, 2016 at 10:08:17AM -0800, David Daney wrote:
>> On 02/10/2016 01:28 AM, Will Deacon wrote:
>>> On Tue, Feb 09, 2016 at 11:29:16AM -0800, David Daney wrote:
>>>> From: Andrew Pinski <apinski at cavium.com>
>>>>
>>>> On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
>>>> instructions may cause the icache to become invalid if it contains
>>>> data for a non-current ASID.
>>>>
>>>> This patch implements the workaround (which flushes the local icache
>>>> when switching the mm) by using code patching.
>>>
>>> So, to be clear, is this "just" a performance problem as opposed to a
>>> correctness issue?
>>
>> No.  It is a correctness issue.  Without this workaround in place, userspace
>> programs end up executing the wrong instructions, which leads to
>> unpredictable behavior and program crashes.
>
> Ok, so I think the description in the commit log isn't quite right. An
> "invalid" line in i-cache simply means that it needs to be refetched.
> What you're talking about sounds like data corruption.

Yes.  I guess I will be sending v3 with an improved description.

>
> I also don't understand how the workaround fixes things like TLBIs due
> to copy-on-write faults triggered by another core.

Caveat: I don't fully understand the internal ICache implementation 
details.  But ...

External broadcast TLBIs arriving for the current ASID (as set in 
TTBR0_EL1) are handled properly.  The issue is that cached data for 
other ASIDs, under some circumstances, may be inadvertently "blessed" 
into the current ASID.  If we take care that no data for "foreign" ASIDs 
is in the Icache, the problematical case can never occur.

> Also, what's the
> interaction with virtual machines, or is the VMID not affected in the
> same way as the ASID?

Ah, the $10^6 question.  Current information on how this interacts with 
KVM is less well developed.  We think the workaround doesn't cause 
failures in virtual machines.

I realize that this is different than asserting that virtual machines 
are guaranteed to operate error free.

>
> Sorry to be a pain on this, but we need to understand the issue well
> enough to maintain the workaround in the future!
>
>>> If so, do you have any numbers with and without this
>>> change?
>>
>> We tried to measure it, but the impact is not measurable in the tests we
>> have done.  Switching the mm is not often done so the extra ICache
>> invalidation is rare.
>
> Oh, sure. I was only interested in perf figures if this was a performance
> problem rather than a functional one.
>
> Will
>



From tchalamarla at caviumnetworks.com  Wed Feb 10 10:46:53 2016
From: tchalamarla at caviumnetworks.com (tchalamarla at caviumnetworks.com)
Date: Wed, 10 Feb 2016 10:46:53 -0800
Subject: [PATCH] arm64: KVM: Configure TCR_EL2.PS at runtime
Message-ID: <1455130013-28644-1-git-send-email-tchalamarla@caviumnetworks.com>

From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>

Setting TCR_EL2.PS to 40 bits is wrong on systems with PS size is
less than 40 bits. and with systems where RAM is at higher address,
this will break KVM.

This patch sets TCR_EL2.PS at runtime similar to VTCR_EL2.PS

changes form V2:
	- Modified subject line and commit message.
	- Removed TCR_EL2_FLAGS.

changes from V1:
        - Moved to dynamic configuration.

Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
---
 arch/arm64/include/asm/kvm_arm.h |  2 --
 arch/arm64/kvm/hyp-init.S        | 12 +++++++-----
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 738a95f..3776db0 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -107,8 +107,6 @@
 #define TCR_EL2_MASK	(TCR_EL2_TG0 | TCR_EL2_SH0 | \
 			 TCR_EL2_ORGN0 | TCR_EL2_IRGN0 | TCR_EL2_T0SZ)
 
-#define TCR_EL2_FLAGS	(TCR_EL2_RES1 | TCR_EL2_PS_40B)
-
 /* VTCR_EL2 Registers bits */
 #define VTCR_EL2_RES1		(1 << 31)
 #define VTCR_EL2_PS_MASK	(7 << 16)
diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
index 3e568dc..b5ab1b0 100644
--- a/arch/arm64/kvm/hyp-init.S
+++ b/arch/arm64/kvm/hyp-init.S
@@ -64,7 +64,7 @@ __do_hyp_init:
 	mrs	x4, tcr_el1
 	ldr	x5, =TCR_EL2_MASK
 	and	x4, x4, x5
-	ldr	x5, =TCR_EL2_FLAGS
+	ldr	x5, =TCR_EL2_RES1
 	orr	x4, x4, x5
 
 #ifndef CONFIG_ARM64_VA_BITS_48
@@ -85,15 +85,17 @@ __do_hyp_init:
 	ldr_l	x5, idmap_t0sz
 	bfi	x4, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH
 #endif
-	msr	tcr_el2, x4
-
-	ldr	x4, =VTCR_EL2_FLAGS
 	/*
 	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
-	 * VTCR_EL2.
+	 * TCR_EL2 and VTCR_EL2.
 	 */
 	mrs	x5, ID_AA64MMFR0_EL1
 	bfi	x4, x5, #16, #3
+
+	msr	tcr_el2, x4
+
+	ldr	x4, =VTCR_EL2_FLAGS
+	bfi	x4, x5, #16, #3
 	/*
 	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS bit in
 	 * VTCR_EL2.
-- 
2.1.0



From eric at anholt.net  Wed Feb 10 10:51:55 2016
From: eric at anholt.net (Eric Anholt)
Date: Wed, 10 Feb 2016 10:51:55 -0800
Subject: [GIT PULL] bcm2835 DT changes for 4.6
In-Reply-To: <DDFB1D8B-805B-488F-9582-796EBCEF287B@sperl.org>
References: <1454977978-17491-1-git-send-email-eric@anholt.net>
 <DDFB1D8B-805B-488F-9582-796EBCEF287B@sperl.org>
Message-ID: <87d1s42yb8.fsf@eliezer.anholt.net>

Martin Sperl <martin at sperl.org> writes:

>> On 09.02.2016, at 01:32, Eric Anholt <eric at anholt.net> wrote:
>> 
>> Hi Florian.  Here's the first set of patches for bcm2835 for 4.6.
>> We've got more DT patches that are going to happen for new boards,
>> too, but they're still getting polished.
>> 
>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>> 
>>  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>> 
>> are available in the git repository at:
>> 
>>  git at github.com:anholt/linux.git tags/bcm2835-dt-next-2016-02-04
>> 
>> for you to fetch changes up to 5ec6f2cd8ec4bcd38ba199ea8711a5ec906d85e7:
>> 
>>  ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT. (2016-02-02 20:02:45 -0800)
>> 
>> ----------------------------------------------------------------
>> This pull request covers mostly DT changes that didn't make it into
>> 4.5 because required header files went through other trees.
>> 
>> ----------------------------------------------------------------
>> Alexander Aring (1):
>>      ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
>> 
>> Lubomir Rintel (1):
>>      ARM: bcm2835: dt: Add Raspberry Pi Model A
>> 
>> Martin Sperl (2):
>>      ARM: bcm2835: add the auxiliary spi1 and spi2 to the device tree
>>      ARM: bcm2835: follow dt uart node-naming convention
>
> Do you want me to resend a rebased version of:
>      ARM: bcm2835: add bcm2835-aux-uart support to default DT
>
> The corresponding driver has been added to tty/tty-next.

It hadn't landed last time I checked.  A rebased version that you've
tested would be great!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160210/48eedbe7/attachment.sig>

From stripathi at apm.com  Wed Feb 10 10:59:31 2016
From: stripathi at apm.com (Suman Tripathi)
Date: Wed, 10 Feb 2016 10:59:31 -0800
Subject: [PATCH v4 0/3] ata: Fixes related to edge trigger latch for the
 ahci_xgene_driver.
In-Reply-To: <20160210162547.GJ3741@mtj.duckdns.org>
References: <1454738124-9351-1-git-send-email-stripathi@apm.com>
 <20160210162547.GJ3741@mtj.duckdns.org>
Message-ID: <CAOHikRBNL2gLJwhB2SEKJXZtOpmqwBET4P9RgRrPdhyH4bn0zA@mail.gmail.com>

Hi Tejun,

On Wed, Feb 10, 2016 at 8:25 AM, Tejun Heo <tj at kernel.org> wrote:
> On Sat, Feb 06, 2016 at 11:25:21AM +0530, suman Tripathi wrote:
>> From: Suman Tripathi <stripathi at apm.com>
>>
>> This patch set implements a workaround for an errate in the APM
>> X-Gene SATA host controller with edge interrupt. The HOST_IRQ_STAT
>> misses the edge interrupt from the PORT_IRQ_STAT when clearing the
>> HOST_IRQ_STAT and reporting the PORT_IRQ_STAT happens in same clock
>> cycle. It also implements the capability to override generic interrupt
>> handler.
>
> Applied 1-3 to libata/for-4.6 with minor updates.

will this patchset  go to 4.5 ?

>
> Thanks.
>
> --
> tejun



-- 
Thanks,
with regards,
Suman Tripathi


From eric at anholt.net  Wed Feb 10 10:59:29 2016
From: eric at anholt.net (Eric Anholt)
Date: Wed, 10 Feb 2016 10:59:29 -0800
Subject: [PATCH 3/4] spi: bcm2835aux: set up spi-mode before asserting
 cs-gpio
In-Reply-To: <20160210080149.GQ13270@sirena.org.uk>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <1455041435-8015-4-git-send-email-stephanolbrich@gmx.de>
 <87d1s54f7f.fsf@eliezer.anholt.net> <20160210080149.GQ13270@sirena.org.uk>
Message-ID: <878u2s2xym.fsf@eliezer.anholt.net>

Mark Brown <broonie at kernel.org> writes:

> On Tue, Feb 09, 2016 at 03:49:24PM -0800, Eric Anholt wrote:
>
>> This patch surprised me.  I would have thought that the solution was to
>> just write the updated CNTL bits for CPOL and wait a moment whenever it
>> changes.  The CS only gets asserted later on when we get some data in
>> the TX FIFO, so I think you're just reducing the chance of losing the
>> race to get our inverted clock noticed by the device before the CS gets
>> asserted.
>
> We support (and generally want to use since hardware chip selects are
> often very limited in what they do) chip select on GPIO.

Oops, this makes more sense now.  Subject even mentioned gpio, and a
GPIO CS must be getting set around the transfer_one call.  I'll be ready
to send an r-b for a v2 with the speed update bug fixed (unless transfer
speeds are guaranteed to be constant between a prepare and unprepare).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160210/01477724/attachment.sig>

From broonie at kernel.org  Wed Feb 10 11:02:04 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 10 Feb 2016 19:02:04 +0000
Subject: [PATCH 3/4] spi: bcm2835aux: set up spi-mode before asserting
 cs-gpio
In-Reply-To: <878u2s2xym.fsf@eliezer.anholt.net>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <1455041435-8015-4-git-send-email-stephanolbrich@gmx.de>
 <87d1s54f7f.fsf@eliezer.anholt.net>
 <20160210080149.GQ13270@sirena.org.uk>
 <878u2s2xym.fsf@eliezer.anholt.net>
Message-ID: <20160210190204.GD13270@sirena.org.uk>

On Wed, Feb 10, 2016 at 10:59:29AM -0800, Eric Anholt wrote:

> Oops, this makes more sense now.  Subject even mentioned gpio, and a
> GPIO CS must be getting set around the transfer_one call.  I'll be ready
> to send an r-b for a v2 with the speed update bug fixed (unless transfer
> speeds are guaranteed to be constant between a prepare and unprepare).

No guarantee that they'll not change, especially in a situation where we
have two devices on different speeds on a bus working at the same time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160210/80c1d3df/attachment.sig>

From tj at kernel.org  Wed Feb 10 11:05:07 2016
From: tj at kernel.org (Tejun Heo)
Date: Wed, 10 Feb 2016 14:05:07 -0500
Subject: [PATCH v4 0/3] ata: Fixes related to edge trigger latch for the
 ahci_xgene_driver.
In-Reply-To: <CAOHikRBNL2gLJwhB2SEKJXZtOpmqwBET4P9RgRrPdhyH4bn0zA@mail.gmail.com>
References: <1454738124-9351-1-git-send-email-stripathi@apm.com>
 <20160210162547.GJ3741@mtj.duckdns.org>
 <CAOHikRBNL2gLJwhB2SEKJXZtOpmqwBET4P9RgRrPdhyH4bn0zA@mail.gmail.com>
Message-ID: <20160210190507.GS3741@mtj.duckdns.org>

On Wed, Feb 10, 2016 at 10:59:31AM -0800, Suman Tripathi wrote:
> Hi Tejun,
> 
> On Wed, Feb 10, 2016 at 8:25 AM, Tejun Heo <tj at kernel.org> wrote:
> > On Sat, Feb 06, 2016 at 11:25:21AM +0530, suman Tripathi wrote:
> >> From: Suman Tripathi <stripathi at apm.com>
> >>
> >> This patch set implements a workaround for an errate in the APM
> >> X-Gene SATA host controller with edge interrupt. The HOST_IRQ_STAT
> >> misses the edge interrupt from the PORT_IRQ_STAT when clearing the
> >> HOST_IRQ_STAT and reporting the PORT_IRQ_STAT happens in same clock
> >> cycle. It also implements the capability to override generic interrupt
> >> handler.
> >
> > Applied 1-3 to libata/for-4.6 with minor updates.
> 
> will this patchset  go to 4.5 ?

I applied them to for-4.6 but it can go through for-4.5-fixes if
necessary.  Is it necessary?

Thanks.

-- 
tejun


From stripathi at apm.com  Wed Feb 10 11:08:27 2016
From: stripathi at apm.com (Suman Tripathi)
Date: Wed, 10 Feb 2016 11:08:27 -0800
Subject: [PATCH v4 0/3] ata: Fixes related to edge trigger latch for the
 ahci_xgene_driver.
In-Reply-To: <20160210190507.GS3741@mtj.duckdns.org>
References: <1454738124-9351-1-git-send-email-stripathi@apm.com>
 <20160210162547.GJ3741@mtj.duckdns.org>
 <CAOHikRBNL2gLJwhB2SEKJXZtOpmqwBET4P9RgRrPdhyH4bn0zA@mail.gmail.com>
 <20160210190507.GS3741@mtj.duckdns.org>
Message-ID: <CAOHikRDcChOdP9v2_0a515XAXeG3kZOaLe==mymTJTpmog-6Ow@mail.gmail.com>

Hi Tejun,

On Wed, Feb 10, 2016 at 11:05 AM, Tejun Heo <tj at kernel.org> wrote:
> On Wed, Feb 10, 2016 at 10:59:31AM -0800, Suman Tripathi wrote:
>> Hi Tejun,
>>
>> On Wed, Feb 10, 2016 at 8:25 AM, Tejun Heo <tj at kernel.org> wrote:
>> > On Sat, Feb 06, 2016 at 11:25:21AM +0530, suman Tripathi wrote:
>> >> From: Suman Tripathi <stripathi at apm.com>
>> >>
>> >> This patch set implements a workaround for an errate in the APM
>> >> X-Gene SATA host controller with edge interrupt. The HOST_IRQ_STAT
>> >> misses the edge interrupt from the PORT_IRQ_STAT when clearing the
>> >> HOST_IRQ_STAT and reporting the PORT_IRQ_STAT happens in same clock
>> >> cycle. It also implements the capability to override generic interrupt
>> >> handler.
>> >
>> > Applied 1-3 to libata/for-4.6 with minor updates.
>>
>> will this patchset  go to 4.5 ?
>
> I applied them to for-4.6 but it can go through for-4.5-fixes if
> necessary.  Is it necessary?

It would be nice because our vendors are using 4.5.

>
> Thanks.
>
> --
> tejun



-- 
Thanks,
with regards,
Suman Tripathi


From tthayer at opensource.altera.com  Wed Feb 10 11:26:22 2016
From: tthayer at opensource.altera.com (tthayer at opensource.altera.com)
Date: Wed, 10 Feb 2016 13:26:22 -0600
Subject: [PATCHv10 2/4] ARM: dts: Add Altera L2 Cache and OCRAM EDAC entries
In-Reply-To: <1455132384-17108-1-git-send-email-tthayer@opensource.altera.com>
References: <1455132384-17108-1-git-send-email-tthayer@opensource.altera.com>
Message-ID: <1455132384-17108-2-git-send-email-tthayer@opensource.altera.com>

From: Thor Thayer <tthayer at opensource.altera.com>

Adding the device tree entries and bindings needed to support
the Altera L2 cache and On-Chip RAM EDAC. This patch relies upon
an earlier patch to declare and setup On-chip RAM properly.
http://www.spinics.net/lists/devicetree/msg51117.html

Signed-off-by: Thor Thayer <tthayer at opensource.altera.com>
Acked-by: Rob Herring <robh at kernel.org>
---
v10: No change
v9:  Remove 0x from ecc-manager in bindings and dts.
v8:  Fix node names to include chip family and use ecc manager
     to better describe the driver. Rename socfpga-edac.txt to
     socfpga-eccmgr.txt.
v7:  No Change
v6:  Change to nested EDAC device nodes based on community
     feedback. Remove L2 syscon. Use consolidated binding.
v3-5: No Change
v2:  Remove OCRAM declaration and reference prior patch.
---
 .../bindings/arm/altera/socfpga-eccmgr.txt         |   49 ++++++++++++++++++++
 arch/arm/boot/dts/socfpga.dtsi                     |   20 ++++++++
 2 files changed, 69 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt

diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
new file mode 100644
index 0000000..885f93d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
@@ -0,0 +1,49 @@
+Altera SoCFPGA ECC Manager
+This driver uses the EDAC framework to implement the SOCFPGA ECC Manager.
+The ECC Manager counts and corrects single bit errors and counts/handles
+double bit errors which are uncorrectable.
+
+Required Properties:
+- compatible : Should be "altr,socfpga-ecc-manager"
+- #address-cells: must be 1
+- #size-cells: must be 1
+- ranges : standard definition, should translate from local addresses
+
+Subcomponents:
+
+L2 Cache ECC
+Required Properties:
+- compatible : Should be "altr,socfpga-l2-ecc"
+- reg : Address and size for ECC error interrupt clear registers.
+- interrupts : Should be single bit error interrupt, then double bit error
+	interrupt. Note the rising edge type.
+
+On Chip RAM ECC
+Required Properties:
+- compatible : Should be "altr,socfpga-ocram-ecc"
+- reg : Address and size for ECC error interrupt clear registers.
+- iram : phandle to On-Chip RAM definition.
+- interrupts : Should be single bit error interrupt, then double bit error
+	interrupt. Note the rising edge type.
+
+Example:
+
+	eccmgr: eccmgr at ffd08140 {
+		compatible = "altr,socfpga-ecc-manager";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		l2-ecc at ffd08140 {
+			compatible = "altr,socfpga-l2-ecc";
+			reg = <0xffd08140 0x4>;
+			interrupts = <0 36 1>, <0 37 1>;
+		};
+
+		ocram-ecc at ffd08144 {
+			compatible = "altr,socfpga-ocram-ecc";
+			reg = <0xffd08144 0x4>;
+			iram = <&ocram>;
+			interrupts = <0 178 1>, <0 179 1>;
+		};
+	};
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 3ed4abd..15cbc74 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -656,6 +656,26 @@
 			status = "disabled";
 		};
 
+		eccmgr: eccmgr at ffd08140 {
+			compatible = "altr,socfpga-ecc-manager";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			l2-ecc at ffd08140 {
+				compatible = "altr,socfpga-l2-ecc";
+				reg = <0xffd08140 0x4>;
+				interrupts = <0 36 1>, <0 37 1>;
+			};
+
+			ocram-ecc at ffd08144 {
+				compatible = "altr,socfpga-ocram-ecc";
+				reg = <0xffd08144 0x4>;
+				iram = <&ocram>;
+				interrupts = <0 178 1>, <0 179 1>;
+			};
+		};
+
 		L2: l2-cache at fffef000 {
 			compatible = "arm,pl310-cache";
 			reg = <0xfffef000 0x1000>;
-- 
1.7.9.5



From tthayer at opensource.altera.com  Wed Feb 10 11:26:21 2016
From: tthayer at opensource.altera.com (tthayer at opensource.altera.com)
Date: Wed, 10 Feb 2016 13:26:21 -0600
Subject: [PATCHv10 1/4] EDAC,
 altera: Add Altera L2 Cache and OCRAM EDAC Support
Message-ID: <1455132384-17108-1-git-send-email-tthayer@opensource.altera.com>

From: Thor Thayer <tthayer at opensource.altera.com>

Adding L2 Cache and On-Chip RAM EDAC support for the
Altera SoCs using the EDAC device  model. The SDRAM
controller is using the Memory Controller model.

Each type of ECC is individually configurable.

Signed-off-by: Thor Thayer <tthayer at opensource.altera.com>
---
v10: Changes noted by maintainer included: Fix tear-down of debugfs
     error path- remove specific device debugfs dirs. Addition of
     warning if neither IRQ triggered. Cleanup of comments.
     Better function naming. Cleaner alloc functions.
v9:  Improve device tree node release. Free managed resources
     on error path. Fix ocram memory leak.
v8:  Remove MASK from single bit mask names.
     s/altr,edac/altr,socfpga-ecc-manager
     Use debugfs instead of sysfs.
     Add chip family name to match string.
     Fix header year.
     Fix build dependencies & change commit accordingly.
     s/CONFIG_EDAC_ALTERA_MC/CONFIG_EDAC_ALTERA
v7:  s/of_get_named_gen_pool/of_gen_pool_get
     Remove #ifdef for EDAC_DEBUG
     Use -ENODEV instead of EPROBE_DEFER
v6:  Convert to nested EDAC in device tree. Force L2 cache
     on for L2Cache ECC & remove L2 cache syscon for checking
     enable bit. Update year in header.
v5:  No change.
v4:  Change mask defines to use BIT().
     Fix comment style to agree with kernel coding style.
     Better printk description for read != write in trigger.
     Remove SysFS debugging message.
     Better dci->mod_name
     Move gen_pool pointer assignment to end of function.
     Invert logic to reduce indent in ocram depenency check.
     Change from dev_err() to edac_printk()
     Replace magic numbers with defines & comments.
     Improve error injection test.
     Change Makefile intermediary name to altr (from alt)
v3:  Move OCRAM and L2 cache EDAC functions into altera_edac.c
     instead of separate files.
v2:  Fix L2 dependency comments.
---
 drivers/edac/Kconfig       |   26 ++-
 drivers/edac/Makefile      |    2 +-
 drivers/edac/altera_edac.c |  492 +++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 512 insertions(+), 8 deletions(-)

diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index ef25000..37755e6 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -367,14 +367,30 @@ config EDAC_OCTEON_PCI
 	  Support for error detection and correction on the
 	  Cavium Octeon family of SOCs.
 
-config EDAC_ALTERA_MC
-	bool "Altera SDRAM Memory Controller EDAC"
+config EDAC_ALTERA
+	bool "Altera SOCFPGA ECC"
 	depends on EDAC_MM_EDAC=y && ARCH_SOCFPGA
 	help
 	  Support for error detection and correction on the
-	  Altera SDRAM memory controller. Note that the
-	  preloader must initialize the SDRAM before loading
-	  the kernel.
+	  Altera SOCs. This must be selected for SDRAM ECC.
+	  Note that the preloader must initialize the SDRAM
+	  before loading the kernel.
+
+config EDAC_ALTERA_L2C
+	bool "Altera L2 Cache ECC"
+	depends on EDAC_ALTERA=y
+	select CACHE_L2X0
+	help
+	  Support for error detection and correction on the
+	  Altera L2 cache Memory for Altera SoCs. This option
+	  requires L2 cache so it will force that selection.
+
+config EDAC_ALTERA_OCRAM
+	bool "Altera On-Chip RAM ECC"
+	depends on EDAC_ALTERA=y && SRAM && GENERIC_ALLOCATOR
+	help
+	  Support for error detection and correction on the
+	  Altera On-Chip RAM Memory for Altera SoCs.
 
 config EDAC_SYNOPSYS
 	tristate "Synopsys DDR Memory Controller"
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index be163e2..f9e4a3e 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -67,6 +67,6 @@ obj-$(CONFIG_EDAC_OCTEON_L2C)		+= octeon_edac-l2c.o
 obj-$(CONFIG_EDAC_OCTEON_LMC)		+= octeon_edac-lmc.o
 obj-$(CONFIG_EDAC_OCTEON_PCI)		+= octeon_edac-pci.o
 
-obj-$(CONFIG_EDAC_ALTERA_MC)		+= altera_edac.o
+obj-$(CONFIG_EDAC_ALTERA)		+= altera_edac.o
 obj-$(CONFIG_EDAC_SYNOPSYS)		+= synopsys_edac.o
 obj-$(CONFIG_EDAC_XGENE)		+= xgene_edac.o
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index 9296409..63e4209 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -1,5 +1,5 @@
 /*
- *  Copyright Altera Corporation (C) 2014-2015. All rights reserved.
+ *  Copyright Altera Corporation (C) 2014-2016. All rights reserved.
  *  Copyright 2011-2012 Calxeda, Inc.
  *
  * This program is free software; you can redistribute it and/or modify it
@@ -17,8 +17,10 @@
  * Adapted from the highbank_mc_edac driver.
  */
 
+#include <asm/cacheflush.h>
 #include <linux/ctype.h>
 #include <linux/edac.h>
+#include <linux/genalloc.h>
 #include <linux/interrupt.h>
 #include <linux/kernel.h>
 #include <linux/mfd/syscon.h>
@@ -34,6 +36,7 @@
 
 #define EDAC_MOD_STR		"altera_edac"
 #define EDAC_VERSION		"1"
+#define EDAC_DEVICE		"Altera"
 
 static const struct altr_sdram_prv_data c5_data = {
 	.ecc_ctrl_offset    = CV_CTLCFG_OFST,
@@ -75,6 +78,31 @@ static const struct altr_sdram_prv_data a10_data = {
 	.ue_set_mask        = A10_DIAGINT_TDERRA_MASK,
 };
 
+/************************** EDAC Device Defines **************************/
+
+/* OCRAM ECC Management Group Defines */
+#define ALTR_MAN_GRP_OCRAM_ECC_OFFSET   0x04
+#define ALTR_OCR_ECC_EN                 BIT(0)
+#define ALTR_OCR_ECC_INJS               BIT(1)
+#define ALTR_OCR_ECC_INJD               BIT(2)
+#define ALTR_OCR_ECC_SERR               BIT(3)
+#define ALTR_OCR_ECC_DERR               BIT(4)
+
+/* L2 ECC Management Group Defines */
+#define ALTR_MAN_GRP_L2_ECC_OFFSET      0x00
+#define ALTR_L2_ECC_EN                  BIT(0)
+#define ALTR_L2_ECC_INJS                BIT(1)
+#define ALTR_L2_ECC_INJD                BIT(2)
+
+#define ALTR_UE_TRIGGER_CHAR            'U'   /* Trigger for UE */
+#define ALTR_TRIGGER_READ_WRD_CNT       32    /* Line size x 4 */
+#define ALTR_TRIG_OCRAM_BYTE_SIZE       128   /* Line size x 4 */
+#define ALTR_TRIG_L2C_BYTE_SIZE         4096  /* Full Page */
+
+/*********************** EDAC Memory Controller Functions ****************/
+
+/* The SDRAM controller uses the EDAC Memory Controller framework.       */
+
 static irqreturn_t altr_sdram_mc_err_handler(int irq, void *dev_id)
 {
 	struct mem_ctl_info *mci = dev_id;
@@ -504,6 +532,466 @@ static struct platform_driver altr_sdram_edac_driver = {
 
 module_platform_driver(altr_sdram_edac_driver);
 
+/************************* EDAC Parent Probe *************************/
+
+static const struct of_device_id altr_edac_device_of_match[];
+
+static const struct of_device_id altr_edac_of_match[] = {
+	{ .compatible = "altr,socfpga-ecc-manager" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, altr_edac_of_match);
+
+static int altr_edac_probe(struct platform_device *pdev)
+{
+	of_platform_populate(pdev->dev.of_node, altr_edac_device_of_match,
+			     NULL, &pdev->dev);
+	return 0;
+}
+
+static struct platform_driver altr_edac_driver = {
+	.probe =  altr_edac_probe,
+	.driver = {
+		.name = "socfpga_ecc_manager",
+		.of_match_table = altr_edac_of_match,
+	},
+};
+module_platform_driver(altr_edac_driver);
+
+/************************* EDAC Device Functions *************************/
+
+/*
+ * EDAC Device Functions (shared between various IPs).
+ * The discrete memories use the EDAC Device framework. The probe
+ * and error handling functions are very similar between memories
+ * so they are shared. The memory allocation and freeing for EDAC
+ * trigger testing are different for each memory.
+ */
+
+const struct edac_device_prv_data ocramecc_data;
+const struct edac_device_prv_data l2ecc_data;
+
+struct edac_device_prv_data {
+	int (*setup)(struct platform_device *pdev, void __iomem *base);
+	int ce_clear_mask;
+	int ue_clear_mask;
+	char dbgfs_name[20];
+	void * (*alloc_mem)(size_t size, void **other);
+	void (*free_mem)(void *p, size_t size, void *other);
+	int ecc_enable_mask;
+	int ce_set_mask;
+	int ue_set_mask;
+	int trig_alloc_sz;
+};
+
+struct altr_edac_device_dev {
+	void __iomem *base;
+	int sb_irq;
+	int db_irq;
+	const struct edac_device_prv_data *data;
+	struct dentry *debugfs_dir;
+	char *edac_dev_name;
+};
+
+static irqreturn_t altr_edac_device_handler(int irq, void *dev_id)
+{
+	irqreturn_t ret_value = IRQ_NONE;
+	struct edac_device_ctl_info *dci = dev_id;
+	struct altr_edac_device_dev *drvdata = dci->pvt_info;
+	const struct edac_device_prv_data *priv = drvdata->data;
+
+	if (irq == drvdata->sb_irq) {
+		if (priv->ce_clear_mask)
+			writel(priv->ce_clear_mask, drvdata->base);
+		edac_device_handle_ce(dci, 0, 0, drvdata->edac_dev_name);
+		ret_value = IRQ_HANDLED;
+	} else if (irq == drvdata->db_irq) {
+		if (priv->ue_clear_mask)
+			writel(priv->ue_clear_mask, drvdata->base);
+		edac_device_handle_ue(dci, 0, 0, drvdata->edac_dev_name);
+		panic("\nEDAC:ECC_DEVICE[Uncorrectable errors]\n");
+		ret_value = IRQ_HANDLED;
+	} else {
+		WARN_ON(1);
+	}
+
+	return ret_value;
+}
+
+static ssize_t altr_edac_device_trig(struct file *file,
+				     const char __user *user_buf,
+				     size_t count, loff_t *ppos)
+
+{
+	u32 *ptemp, i, error_mask;
+	int result = 0;
+	u8 trig_type;
+	unsigned long flags;
+	struct edac_device_ctl_info *edac_dci = file->private_data;
+	struct altr_edac_device_dev *drvdata = edac_dci->pvt_info;
+	const struct edac_device_prv_data *priv = drvdata->data;
+	void *generic_ptr = edac_dci->dev;
+
+	if (!user_buf || get_user(trig_type, user_buf))
+		return -EFAULT;
+
+	if (!priv->alloc_mem)
+		return -ENOMEM;
+
+	/*
+	 * Note that generic_ptr is initialized to the device * but in
+	 * some alloc_functions, this is overridden and returns data.
+	 */
+	ptemp = priv->alloc_mem(priv->trig_alloc_sz, &generic_ptr);
+	if (!ptemp) {
+		edac_printk(KERN_ERR, EDAC_DEVICE,
+			    "Inject: Buffer Allocation error\n");
+		return -ENOMEM;
+	}
+
+	if (trig_type == ALTR_UE_TRIGGER_CHAR)
+		error_mask = priv->ue_set_mask;
+	else
+		error_mask = priv->ce_set_mask;
+
+	edac_printk(KERN_ALERT, EDAC_DEVICE,
+		    "Trigger Error Mask (0x%X)\n", error_mask);
+
+	local_irq_save(flags);
+	/* write ECC corrupted data out. */
+	for (i = 0; i < (priv->trig_alloc_sz / sizeof(*ptemp)); i++) {
+		/* Read data so we're in the correct state */
+		rmb();
+		if (ACCESS_ONCE(ptemp[i]))
+			result = -1;
+		/* Toggle Error bit (it is latched), leave ECC enabled */
+		writel(error_mask, drvdata->base);
+		writel(priv->ecc_enable_mask, drvdata->base);
+		ptemp[i] = i;
+	}
+	/* Ensure it has been written out */
+	wmb();
+	local_irq_restore(flags);
+
+	if (result)
+		edac_printk(KERN_ERR, EDAC_DEVICE, "Mem Not Cleared\n");
+
+	/* Read out written data. ECC error caused here */
+	for (i = 0; i < ALTR_TRIGGER_READ_WRD_CNT; i++)
+		if (ACCESS_ONCE(ptemp[i]) != i)
+			edac_printk(KERN_ERR, EDAC_DEVICE,
+				    "Read doesn't match written data\n");
+
+	if (priv->free_mem)
+		priv->free_mem(ptemp, priv->trig_alloc_sz, generic_ptr);
+
+	return count;
+}
+
+static const struct file_operations altr_edac_device_inject_fops = {
+	.open = simple_open,
+	.write = altr_edac_device_trig,
+	.llseek = generic_file_llseek,
+};
+
+static void altr_create_edacdev_dbgfs(struct edac_device_ctl_info *edac_dci,
+				      const struct edac_device_prv_data *priv)
+{
+	struct altr_edac_device_dev *drvdata = edac_dci->pvt_info;
+
+	if (!IS_ENABLED(CONFIG_EDAC_DEBUG))
+		return;
+
+	drvdata->debugfs_dir = edac_debugfs_create_dir(drvdata->edac_dev_name);
+	if (!drvdata->debugfs_dir)
+		return;
+
+	if (!edac_debugfs_create_file(priv->dbgfs_name, S_IWUSR,
+				      drvdata->debugfs_dir, edac_dci,
+				      &altr_edac_device_inject_fops))
+		debugfs_remove_recursive(drvdata->debugfs_dir);
+}
+
+static const struct of_device_id altr_edac_device_of_match[] = {
+#ifdef CONFIG_EDAC_ALTERA_L2C
+	{ .compatible = "altr,socfpga-l2-ecc", .data = (void *)&l2ecc_data },
+#endif
+#ifdef CONFIG_EDAC_ALTERA_OCRAM
+	{ .compatible = "altr,socfpga-ocram-ecc",
+	  .data = (void *)&ocramecc_data },
+#endif
+	{},
+};
+MODULE_DEVICE_TABLE(of, altr_edac_device_of_match);
+
+/*
+ * altr_edac_device_probe()
+ *	This is a generic EDAC device driver that will support
+ *	various Altera memory devices such as the L2 cache ECC and
+ *	OCRAM ECC as well as the memories for other peripherals.
+ *	Module specific initialization is done by passing the
+ *	function index in the device tree.
+ */
+static int altr_edac_device_probe(struct platform_device *pdev)
+{
+	struct edac_device_ctl_info *dci;
+	struct altr_edac_device_dev *drvdata;
+	struct resource *r;
+	int res = 0;
+	struct device_node *np = pdev->dev.of_node;
+	char *ecc_name = (char *)np->name;
+	static int dev_instance;
+
+	if (!devres_open_group(&pdev->dev, NULL, GFP_KERNEL)) {
+		edac_printk(KERN_ERR, EDAC_DEVICE,
+			    "Unable to open devm\n");
+		return -ENOMEM;
+	}
+
+	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!r) {
+		edac_printk(KERN_ERR, EDAC_DEVICE,
+			    "Unable to get mem resource\n");
+		res = -ENODEV;
+		goto fail;
+	}
+
+	if (!devm_request_mem_region(&pdev->dev, r->start, resource_size(r),
+				     dev_name(&pdev->dev))) {
+		edac_printk(KERN_ERR, EDAC_DEVICE,
+			    "%s:Error requesting mem region\n", ecc_name);
+		res = -EBUSY;
+		goto fail;
+	}
+
+	dci = edac_device_alloc_ctl_info(sizeof(*drvdata), ecc_name,
+					 1, ecc_name, 1, 0, NULL, 0,
+					 dev_instance++);
+
+	if (!dci) {
+		edac_printk(KERN_ERR, EDAC_DEVICE,
+			    "%s: Unable to allocate EDAC device\n", ecc_name);
+		res = -ENOMEM;
+		goto fail;
+	}
+
+	drvdata = dci->pvt_info;
+	dci->dev = &pdev->dev;
+	platform_set_drvdata(pdev, dci);
+	drvdata->edac_dev_name = ecc_name;
+
+	drvdata->base = devm_ioremap(&pdev->dev, r->start, resource_size(r));
+	if (!drvdata->base)
+		goto fail1;
+
+	/* Get driver specific data for this EDAC device */
+	drvdata->data = of_match_node(altr_edac_device_of_match, np)->data;
+
+	/* Check specific dependencies for the module */
+	if (drvdata->data->setup) {
+		res = drvdata->data->setup(pdev, drvdata->base);
+		if (res)
+			goto fail1;
+	}
+
+	drvdata->sb_irq = platform_get_irq(pdev, 0);
+	res = devm_request_irq(&pdev->dev, drvdata->sb_irq,
+			       altr_edac_device_handler,
+			       0, dev_name(&pdev->dev), dci);
+	if (res)
+		goto fail1;
+
+	drvdata->db_irq = platform_get_irq(pdev, 1);
+	res = devm_request_irq(&pdev->dev, drvdata->db_irq,
+			       altr_edac_device_handler,
+			       0, dev_name(&pdev->dev), dci);
+	if (res)
+		goto fail1;
+
+	dci->mod_name = "Altera ECC Manager";
+	dci->dev_name = drvdata->edac_dev_name;
+
+	res = edac_device_add_device(dci);
+	if (res)
+		goto fail1;
+
+	altr_create_edacdev_dbgfs(dci, drvdata->data);
+
+	devres_close_group(&pdev->dev, NULL);
+
+	return 0;
+
+fail1:
+	edac_device_free_ctl_info(dci);
+fail:
+	devres_release_group(&pdev->dev, NULL);
+	edac_printk(KERN_ERR, EDAC_DEVICE,
+		    "%s:Error setting up EDAC device: %d\n", ecc_name, res);
+
+	return res;
+}
+
+static int altr_edac_device_remove(struct platform_device *pdev)
+{
+	struct edac_device_ctl_info *dci = platform_get_drvdata(pdev);
+	struct altr_edac_device_dev *drvdata = dci->pvt_info;
+
+	debugfs_remove_recursive(drvdata->debugfs_dir);
+	edac_device_del_device(&pdev->dev);
+	edac_device_free_ctl_info(dci);
+
+	return 0;
+}
+
+static struct platform_driver altr_edac_device_driver = {
+	.probe =  altr_edac_device_probe,
+	.remove = altr_edac_device_remove,
+	.driver = {
+		.name = "altr_edac_device",
+		.of_match_table = altr_edac_device_of_match,
+	},
+};
+module_platform_driver(altr_edac_device_driver);
+
+/*********************** OCRAM EDAC Device Functions *********************/
+
+#ifdef CONFIG_EDAC_ALTERA_OCRAM
+
+static void *ocram_alloc_mem(size_t size, void **other)
+{
+	struct device_node *np;
+	struct gen_pool *gp;
+	void *sram_addr;
+
+	np = of_find_compatible_node(NULL, NULL, "altr,socfpga-ocram-ecc");
+	if (!np)
+		return NULL;
+
+	gp = of_gen_pool_get(np, "iram", 0);
+	of_node_put(np);
+	if (!gp)
+		return NULL;
+
+	sram_addr = (void *)gen_pool_alloc(gp, size);
+	if (!sram_addr)
+		return NULL;
+
+	memset(sram_addr, 0, size);
+	/* Ensure data is written out */
+	wmb();
+
+	/* Remember this handle for freeing  later */
+	*other = gp;
+
+	return sram_addr;
+}
+
+static void ocram_free_mem(void *p, size_t size, void *other)
+{
+	gen_pool_free((struct gen_pool *)other, (u32)p, size);
+}
+
+/*
+ * altr_ocram_check_deps()
+ *	Test for OCRAM cache ECC dependencies upon entry because
+ *	platform specific startup should have initialized the
+ *	On-Chip RAM memory and enabled the ECC.
+ *	Can't turn on ECC here because accessing un-initialized
+ *	memory will cause CE/UE errors possibly causing an ABORT.
+ */
+static int altr_ocram_check_deps(struct platform_device *pdev,
+				 void __iomem *base)
+{
+	if (readl(base) & ALTR_OCR_ECC_EN)
+		return 0;
+
+	edac_printk(KERN_ERR, EDAC_DEVICE,
+		    "OCRAM: No ECC present or ECC disabled.\n");
+	return -ENODEV;
+}
+
+const struct edac_device_prv_data ocramecc_data = {
+	.setup = altr_ocram_check_deps,
+	.ce_clear_mask = (ALTR_OCR_ECC_EN | ALTR_OCR_ECC_SERR),
+	.ue_clear_mask = (ALTR_OCR_ECC_EN | ALTR_OCR_ECC_DERR),
+	.dbgfs_name = "altr_ocram_trigger",
+	.alloc_mem = ocram_alloc_mem,
+	.free_mem = ocram_free_mem,
+	.ecc_enable_mask = ALTR_OCR_ECC_EN,
+	.ce_set_mask = (ALTR_OCR_ECC_EN | ALTR_OCR_ECC_INJS),
+	.ue_set_mask = (ALTR_OCR_ECC_EN | ALTR_OCR_ECC_INJD),
+	.trig_alloc_sz = ALTR_TRIG_OCRAM_BYTE_SIZE,
+};
+
+#endif	/* CONFIG_EDAC_ALTERA_OCRAM */
+
+/********************* L2 Cache EDAC Device Functions ********************/
+
+#ifdef CONFIG_EDAC_ALTERA_L2C
+
+static void *l2_alloc_mem(size_t size, void **other)
+{
+	struct device *dev = *other;
+	void *ptemp = devm_kzalloc(dev, size, GFP_KERNEL);
+
+	if (!ptemp)
+		return NULL;
+
+	/* Make sure everything is written out */
+	wmb();
+
+	/*
+	 * Clean all cache levels up to LoC (includes L2)
+	 * This ensures the corrupted data is written into
+	 * L2 cache for readback test (which causes ECC error).
+	 */
+	flush_cache_all();
+
+	return ptemp;
+}
+
+static void l2_free_mem(void *p, size_t size, void *other)
+{
+	struct device *dev = other;
+
+	if (dev && p)
+		devm_kfree(dev, p);
+}
+
+/*
+ * altr_l2_check_deps()
+ *	Test for L2 cache ECC dependencies upon entry because
+ *	platform specific startup should have initialized the L2
+ *	memory and enabled the ECC.
+ *	Bail if ECC is not enabled.
+ *	Note that L2 Cache Enable is forced at build time.
+ */
+static int altr_l2_check_deps(struct platform_device *pdev,
+			      void __iomem *base)
+{
+	if (readl(base) & ALTR_L2_ECC_EN)
+		return 0;
+
+	edac_printk(KERN_ERR, EDAC_DEVICE,
+		    "L2: No ECC present, or ECC disabled\n");
+	return -ENODEV;
+}
+
+const struct edac_device_prv_data l2ecc_data = {
+	.setup = altr_l2_check_deps,
+	.ce_clear_mask = 0,
+	.ue_clear_mask = 0,
+	.dbgfs_name = "altr_l2_trigger",
+	.alloc_mem = l2_alloc_mem,
+	.free_mem = l2_free_mem,
+	.ecc_enable_mask = ALTR_L2_ECC_EN,
+	.ce_set_mask = (ALTR_L2_ECC_EN | ALTR_L2_ECC_INJS),
+	.ue_set_mask = (ALTR_L2_ECC_EN | ALTR_L2_ECC_INJD),
+	.trig_alloc_sz = ALTR_TRIG_L2C_BYTE_SIZE,
+};
+
+#endif	/* CONFIG_EDAC_ALTERA_L2C */
+
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Thor Thayer");
-MODULE_DESCRIPTION("EDAC Driver for Altera SDRAM Controller");
+MODULE_DESCRIPTION("EDAC Driver for Altera Memories");
-- 
1.7.9.5



From tthayer at opensource.altera.com  Wed Feb 10 11:26:23 2016
From: tthayer at opensource.altera.com (tthayer at opensource.altera.com)
Date: Wed, 10 Feb 2016 13:26:23 -0600
Subject: [PATCHv10 3/4] ARM: socfpga: enable L2 cache ECC on startup
In-Reply-To: <1455132384-17108-1-git-send-email-tthayer@opensource.altera.com>
References: <1455132384-17108-1-git-send-email-tthayer@opensource.altera.com>
Message-ID: <1455132384-17108-3-git-send-email-tthayer@opensource.altera.com>

From: Thor Thayer <tthayer at opensource.altera.com>

This patch enables the ECC for L2 cache on machine startup. The ECC has to
be enabled before data is stored in memory otherwise the ECC will fail on
reads.

Signed-off-by: Thor Thayer <tthayer at opensource.altera.com>
Acked-by: Dinh Nguyen <dinguyen at opensource.altera.com>
---
v10: No change
v9:  Improve node put handling.
v8:  Address community suggestions for strings. Fix string based on
     maintainer feedback. Update year in header.
v7:  unmap locally scoped mapped_l2_edac_addr and add of_node_put(np)
v6:  Remove pr_debug() & update year in header.
---
 arch/arm/mach-socfpga/Makefile   |    1 +
 arch/arm/mach-socfpga/core.h     |    1 +
 arch/arm/mach-socfpga/l2_cache.c |   41 ++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-socfpga/socfpga.c  |    2 ++
 4 files changed, 45 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/l2_cache.c

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index b8f9e23..e9ab7c9 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -5,3 +5,4 @@
 obj-y					:= socfpga.o
 obj-$(CONFIG_SMP)	+= headsmp.o platsmp.o
 obj-$(CONFIG_SOCFPGA_SUSPEND)	+= pm.o self-refresh.o
+obj-$(CONFIG_EDAC_ALTERA_L2C)	+= l2_cache.o
diff --git a/arch/arm/mach-socfpga/core.h b/arch/arm/mach-socfpga/core.h
index 5bc6ea8..eb55d66 100644
--- a/arch/arm/mach-socfpga/core.h
+++ b/arch/arm/mach-socfpga/core.h
@@ -36,6 +36,7 @@
 
 extern void socfpga_init_clocks(void);
 extern void socfpga_sysmgr_init(void);
+void socfpga_init_l2_ecc(void);
 
 extern void __iomem *sys_manager_base_addr;
 extern void __iomem *rst_manager_base_addr;
diff --git a/arch/arm/mach-socfpga/l2_cache.c b/arch/arm/mach-socfpga/l2_cache.c
new file mode 100644
index 0000000..e3907ab
--- /dev/null
+++ b/arch/arm/mach-socfpga/l2_cache.c
@@ -0,0 +1,41 @@
+/*
+ * Copyright Altera Corporation (C) 2016. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * 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/io.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+
+void socfpga_init_l2_ecc(void)
+{
+	struct device_node *np;
+	void __iomem *mapped_l2_edac_addr;
+
+	np = of_find_compatible_node(NULL, NULL, "altr,socfpga-l2-ecc");
+	if (!np) {
+		pr_err("Unable to find socfpga-l2-ecc in dtb\n");
+		return;
+	}
+
+	mapped_l2_edac_addr = of_iomap(np, 0);
+	of_node_put(np);
+	if (!mapped_l2_edac_addr) {
+		pr_err("Unable to find L2 ECC mapping in dtb\n");
+		return;
+	}
+
+	/* Enable ECC */
+	writel(0x01, mapped_l2_edac_addr);
+	iounmap(mapped_l2_edac_addr);
+}
diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index a1c0efa..dd1ff07 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -59,6 +59,8 @@ static void __init socfpga_init_irq(void)
 {
 	irqchip_init();
 	socfpga_sysmgr_init();
+	if (IS_ENABLED(CONFIG_EDAC_ALTERA_L2C))
+		socfpga_init_l2_ecc();
 }
 
 static void socfpga_cyclone5_restart(enum reboot_mode mode, const char *cmd)
-- 
1.7.9.5



From tthayer at opensource.altera.com  Wed Feb 10 11:26:24 2016
From: tthayer at opensource.altera.com (tthayer at opensource.altera.com)
Date: Wed, 10 Feb 2016 13:26:24 -0600
Subject: [PATCHv10 4/4] ARM: socfpga: Enable OCRAM ECC on startup
In-Reply-To: <1455132384-17108-1-git-send-email-tthayer@opensource.altera.com>
References: <1455132384-17108-1-git-send-email-tthayer@opensource.altera.com>
Message-ID: <1455132384-17108-4-git-send-email-tthayer@opensource.altera.com>

From: Thor Thayer <tthayer at opensource.altera.com>

This patch enables the ECC for On-Chip RAM on machine startup. The ECC
has to be enabled before data is stored in memory otherwise the ECC will
fail on reads.

Signed-off-by: Thor Thayer <tthayer at opensource.altera.com>
Acked-by: Dinh Nguyen <dinguyen at opensource.altera.com>
---
v10: No change
v9:  Improve node release handling.
v8:  Address community comments on strings. Fix match strings based
     on maintainer feedback. Update year in header.
v7:  enable OCRAM ECC during platform init
v6:  Implement OCRAM discovery changes from community. Add
     of_node_put(). Remove be32_to_cpup(). Use __init() which
     allows removal of .init_machine(). Update year in header.
---
 arch/arm/mach-socfpga/Makefile  |    1 +
 arch/arm/mach-socfpga/core.h    |    1 +
 arch/arm/mach-socfpga/ocram.c   |   49 +++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-socfpga/socfpga.c |    3 +++
 4 files changed, 54 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/ocram.c

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index e9ab7c9..ed15db1 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -6,3 +6,4 @@ obj-y					:= socfpga.o
 obj-$(CONFIG_SMP)	+= headsmp.o platsmp.o
 obj-$(CONFIG_SOCFPGA_SUSPEND)	+= pm.o self-refresh.o
 obj-$(CONFIG_EDAC_ALTERA_L2C)	+= l2_cache.o
+obj-$(CONFIG_EDAC_ALTERA_OCRAM)	+= ocram.o
diff --git a/arch/arm/mach-socfpga/core.h b/arch/arm/mach-socfpga/core.h
index eb55d66..575195b 100644
--- a/arch/arm/mach-socfpga/core.h
+++ b/arch/arm/mach-socfpga/core.h
@@ -37,6 +37,7 @@
 extern void socfpga_init_clocks(void);
 extern void socfpga_sysmgr_init(void);
 void socfpga_init_l2_ecc(void);
+void socfpga_init_ocram_ecc(void);
 
 extern void __iomem *sys_manager_base_addr;
 extern void __iomem *rst_manager_base_addr;
diff --git a/arch/arm/mach-socfpga/ocram.c b/arch/arm/mach-socfpga/ocram.c
new file mode 100644
index 0000000..60ec643
--- /dev/null
+++ b/arch/arm/mach-socfpga/ocram.c
@@ -0,0 +1,49 @@
+/*
+ * Copyright Altera Corporation (C) 2016. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * 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/io.h>
+#include <linux/genalloc.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+
+#define ALTR_OCRAM_CLEAR_ECC          0x00000018
+#define ALTR_OCRAM_ECC_EN             0x00000019
+
+void socfpga_init_ocram_ecc(void)
+{
+	struct device_node *np;
+	void __iomem *mapped_ocr_edac_addr;
+
+	/* Find the OCRAM EDAC device tree node */
+	np = of_find_compatible_node(NULL, NULL, "altr,socfpga-ocram-ecc");
+	if (!np) {
+		pr_err("Unable to find socfpga-ocram-ecc\n");
+		return;
+	}
+
+	mapped_ocr_edac_addr = of_iomap(np, 0);
+	of_node_put(np);
+	if (!mapped_ocr_edac_addr) {
+		pr_err("Unable to map OCRAM ecc regs.\n");
+		return;
+	}
+
+	/* Clear any pending OCRAM ECC interrupts, then enable ECC */
+	writel(ALTR_OCRAM_CLEAR_ECC, mapped_ocr_edac_addr);
+	writel(ALTR_OCRAM_ECC_EN, mapped_ocr_edac_addr);
+
+	iounmap(mapped_ocr_edac_addr);
+}
diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index dd1ff07..7e0aad2 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -61,6 +61,9 @@ static void __init socfpga_init_irq(void)
 	socfpga_sysmgr_init();
 	if (IS_ENABLED(CONFIG_EDAC_ALTERA_L2C))
 		socfpga_init_l2_ecc();
+
+	if (IS_ENABLED(CONFIG_EDAC_ALTERA_OCRAM))
+		socfpga_init_ocram_ecc();
 }
 
 static void socfpga_cyclone5_restart(enum reboot_mode mode, const char *cmd)
-- 
1.7.9.5



From tj at kernel.org  Wed Feb 10 11:24:55 2016
From: tj at kernel.org (Tejun Heo)
Date: Wed, 10 Feb 2016 14:24:55 -0500
Subject: [PATCH v4 0/3] ata: Fixes related to edge trigger latch for the
 ahci_xgene_driver.
In-Reply-To: <CAOHikRDcChOdP9v2_0a515XAXeG3kZOaLe==mymTJTpmog-6Ow@mail.gmail.com>
References: <1454738124-9351-1-git-send-email-stripathi@apm.com>
 <20160210162547.GJ3741@mtj.duckdns.org>
 <CAOHikRBNL2gLJwhB2SEKJXZtOpmqwBET4P9RgRrPdhyH4bn0zA@mail.gmail.com>
 <20160210190507.GS3741@mtj.duckdns.org>
 <CAOHikRDcChOdP9v2_0a515XAXeG3kZOaLe==mymTJTpmog-6Ow@mail.gmail.com>
Message-ID: <CAOS58YO+OOopQjHDjcO=evV=ujcwGQ66G=+TgrUx=V1FAujqxQ@mail.gmail.com>

On Wed, Feb 10, 2016 at 2:08 PM, Suman Tripathi <stripathi at apm.com> wrote:
>> I applied them to for-4.6 but it can go through for-4.5-fixes if
>> necessary.  Is it necessary?
>
> It would be nice because our vendors are using 4.5.

Sure thing.  Moving to for-4.5-fixes.

Thanks.

-- 
tejun


From stripathi at apm.com  Wed Feb 10 11:34:33 2016
From: stripathi at apm.com (Suman Tripathi)
Date: Wed, 10 Feb 2016 11:34:33 -0800
Subject: [PATCH v4 0/3] ata: Fixes related to edge trigger latch for the
 ahci_xgene_driver.
In-Reply-To: <CAOS58YO+OOopQjHDjcO=evV=ujcwGQ66G=+TgrUx=V1FAujqxQ@mail.gmail.com>
References: <1454738124-9351-1-git-send-email-stripathi@apm.com>
 <20160210162547.GJ3741@mtj.duckdns.org>
 <CAOHikRBNL2gLJwhB2SEKJXZtOpmqwBET4P9RgRrPdhyH4bn0zA@mail.gmail.com>
 <20160210190507.GS3741@mtj.duckdns.org>
 <CAOHikRDcChOdP9v2_0a515XAXeG3kZOaLe==mymTJTpmog-6Ow@mail.gmail.com>
 <CAOS58YO+OOopQjHDjcO=evV=ujcwGQ66G=+TgrUx=V1FAujqxQ@mail.gmail.com>
Message-ID: <CAOHikRAW8y52u8sC+FFO9hpbCTUx=qe+O=GYUOridBj7x322Bw@mail.gmail.com>

On Wed, Feb 10, 2016 at 11:24 AM, Tejun Heo <tj at kernel.org> wrote:
> On Wed, Feb 10, 2016 at 2:08 PM, Suman Tripathi <stripathi at apm.com> wrote:
>>> I applied them to for-4.6 but it can go through for-4.5-fixes if
>>> necessary.  Is it necessary?
>>
>> It would be nice because our vendors are using 4.5.
>
> Sure thing.  Moving to for-4.5-fixes.
>
> Thanks.

Thanks a lot Tejun !!
>
> --
> tejun



-- 
Thanks,
with regards,
Suman Tripathi


From arnd at arndb.de  Wed Feb 10 11:52:11 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 20:52:11 +0100
Subject: [PATCH 1/2] serial: 8250: fix building mediatek with SERIAL_8250=m
In-Reply-To: <56BB7C23.5070600@gmail.com>
References: <1454935947-2743255-1-git-send-email-arnd@arndb.de>
 <56BB7C23.5070600@gmail.com>
Message-ID: <7590955.HIrRGSSVmH@wuerfel>

On Wednesday 10 February 2016 19:06:27 Matthias Brugger wrote:
> > ---
> 
> I tried this with:
> commit 2178cbc68f3602dc0b5949b9be2c8383ad3d93ef
> 
> $ grep 8250 .config
> CONFIG_SERIAL_8250=m
> # CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
> CONFIG_SERIAL_8250_PCI=m
> CONFIG_SERIAL_8250_NR_UARTS=4
> CONFIG_SERIAL_8250_RUNTIME_UARTS=4
> # CONFIG_SERIAL_8250_EXTENDED is not set
> # CONFIG_SERIAL_8250_DW is not set
> # CONFIG_SERIAL_8250_RT288X is not set
> CONFIG_SERIAL_8250_MT6577=y
> # CONFIG_SERIAL_8250_INGENIC is not set
> # CONFIG_SERIAL_8250_MID is not set
> 
> $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- drivers/tty/
> 
> compiles just fine.
> 
> Do I missing something?
> 

I was simplifying the situation in the patch description: When CONFIG_SERIAL_8250=m,
Kbuild does not actually descend into drivers/tty/serial/8250/ while building
built-in code, so none of the built-in subdrivers actually get built.

After spotting the problem, I was building with this patch that I considered
submitting:

diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index ceba33c4ebb4..28121885e78e 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_SERIAL_SUNSU) += sunsu.o
 obj-$(CONFIG_SERIAL_SUNSAB) += sunsab.o
 
 # Now bring in any enabled 8250/16450/16550 type drivers.
-obj-$(CONFIG_SERIAL_8250) += 8250/
+obj-y += 8250/
 
 obj-$(CONFIG_SERIAL_AMBA_PL010) += amba-pl010.o
 obj-$(CONFIG_SERIAL_AMBA_PL011) += amba-pl011.o

However, after the other problems are fixed, it's not actually needed
any more, so I did not submit it.

	Arnd


From mturquette at baylibre.com  Wed Feb 10 12:08:53 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Wed, 10 Feb 2016 12:08:53 -0800
Subject: [PATCH v6 4/7] clk: mediatek: Add MT2701 clock support
In-Reply-To: <1454665050-37776-5-git-send-email-jamesjj.liao@mediatek.com>
References: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
 <1454665050-37776-5-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <20160210200853.26445.15165@quark.deferred.io>

Quoting James Liao (2016-02-05 01:37:27)
> +CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt2701-topckgen", mtk_topckgen_init);
> +CLK_OF_DECLARE(mtk_infrasys, "mediatek,mt2701-infracfg", mtk_infrasys_init);
> +CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt2701-pericfg", mtk_pericfg_init);
> +CLK_OF_DECLARE(mtk_mmsys, "mediatek,mt2701-mmsys", mtk_mmsys_init);
> +CLK_OF_DECLARE(mtk_imgsys, "mediatek,mt2701-imgsys", mtk_imgsys_init);
> +CLK_OF_DECLARE(mtk_vdecsys, "mediatek,mt2701-vdecsys", mtk_vdecsys_init);
> +CLK_OF_DECLARE(mtk_hifsys, "mediatek,mt2701-hifsys", mtk_hifsys_init);
> +CLK_OF_DECLARE(mtk_ethsys, "mediatek,mt2701-ethsys", mtk_ethsys_init);
> +CLK_OF_DECLARE(mtk_bdpsys, "mediatek,mt2701-bdpsys", mtk_bdpsys_init);
> +CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt2701-apmixedsys",

:-/

This is way too much CLK_OF_DECLARE and not enough Linux Driver Model.

I understand that some platforms really must initialize some clocks very
early, but can we please separate those into one table and call
CLK_OF_DECLARE on only that set, and then register the rest through a
platform_driver later on?

Best regards,
Mike


From stephanolbrich at gmx.de  Wed Feb 10 12:08:55 2016
From: stephanolbrich at gmx.de (Stephan Olbrich)
Date: Wed, 10 Feb 2016 21:08:55 +0100
Subject: [PATCH 1/4] spi: bcm2835aux: fix bitmask defines
In-Reply-To: <56BA43DB.7030209@lategoodbye.de>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <1455041435-8015-2-git-send-email-stephanolbrich@gmx.de>
 <56BA43DB.7030209@lategoodbye.de>
Message-ID: <14130392.6x8cIOuJmD@chaos-desktop>

Hi Stefan

Am Tuesday 09 February 2016, 20:54:03 schrieb Stefan Wahren:
> Hi Stephan,
> 
> Am 09.02.2016 um 19:10 schrieb stephanolbrich at gmx.de:
> > From: Stephan Olbrich <stephanolbrich at gmx.de>
> > 
> > The bitmasks for txempty and idle interrupts were interchanged.
> > 
> > Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
> > ---
> > 
> >   drivers/spi/spi-bcm2835aux.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
> > index 7de6f84..ecc73c0 100644
> > --- a/drivers/spi/spi-bcm2835aux.c
> > +++ b/drivers/spi/spi-bcm2835aux.c
> > @@ -73,8 +73,8 @@
> > 
> >   /* Bitfields in CNTL1 */
> >   #define BCM2835_AUX_SPI_CNTL1_CSHIGH	0x00000700
> > 
> > -#define BCM2835_AUX_SPI_CNTL1_IDLE	0x00000080
> > -#define BCM2835_AUX_SPI_CNTL1_TXEMPTY	0x00000040
> 
> according to a comment in this file these values are from
> brcm_usrlib/dag/vmcsx/vcinclude/bcm2708_chip/aux_io.h.
> 
> So you want to say that at least these 2 are wrong and you took the
> values from BCM2835-ARM-Peripherals.pdf [1]?
> 
> I think it's worth to mention it.

Actually I stumbled across this while writing the second patch in this series 
and the wrong interrupt got disabled but BCM2835-ARM-Peripherals.pdf did 
confirm my findings.
As Mark has already applied this patch I can't add any comment to it anymore, 
right?

> [1] -
> https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Periphera
> ls.pdf
> > +#define BCM2835_AUX_SPI_CNTL1_TXEMPTY	0x00000080
> > +#define BCM2835_AUX_SPI_CNTL1_IDLE	0x00000040
> > 
> >   #define BCM2835_AUX_SPI_CNTL1_MSBF_IN	0x00000002
> >   #define BCM2835_AUX_SPI_CNTL1_KEEP_IN	0x00000001
> 
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel



From festevam at gmail.com  Wed Feb 10 12:10:18 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 10 Feb 2016 18:10:18 -0200
Subject: noise issues when recording sound on i.MX28
In-Reply-To: <20160210150315.GC13664@pengutronix.de>
References: <20160127105613.GC13664@pengutronix.de>
 <CAOMZO5BpLen517q2heramSta-R6pdESkjM6w=7FRMZebY6ue-Q@mail.gmail.com>
 <20160127144340.GD13664@pengutronix.de>
 <CAOMZO5AE6HwBYz7kOFORt0HTojJLSb0MYUbkb_HCshDHy=d27g@mail.gmail.com>
 <20160210150315.GC13664@pengutronix.de>
Message-ID: <CAOMZO5D5H4F90nse9kyW9KvsJStN-sCGktup4FDPw_zTeNfS2g@mail.gmail.com>

Hi Uwe,

On Wed, Feb 10, 2016 at 1:03 PM, Uwe Kleine-K?nig
<u.kleine-koenig at pengutronix.de> wrote:
> Hello Fabio,
>
> On Tue, Feb 02, 2016 at 11:00:33AM -0200, Fabio Estevam wrote:
>> On Wed, Jan 27, 2016 at 12:43 PM, Uwe Kleine-K?nig
>> <u.kleine-koenig at pengutronix.de> wrote:
>>
>> > So you didn't hit the problem that resetting a saif didn't work, right?
>>
>> No, we haven't seen this reset issue.
>>
>> > Do you have a few more technical details here? A usecase of my machine
>>
>> Let me find out as it has been several years I worked on this problem.
>> Will let you know.
>
> Anything new on your end? I know from Lothar that he invested quite some
> time to debug his hardware setup, tested the codec instead of the i.MX28
> as clock provider and several more things. I also spend some time on
> this issue and we both hope that Freescale/NXP can help in better
> understanding the issue and hopefully can come up with a recipe to make
> concurrent recording and playback on i.MX28 work.
>
> Lothar is in contact with Freescale, too, but up to now with little
> success. The company I'm working for at the moment would also welcome a
> solution here.

Sorry for the delay. I have been on holidays.

Can you confirm you have both SAIF interfaces being clocked from ref_pll?


From s-anna at ti.com  Wed Feb 10 12:13:40 2016
From: s-anna at ti.com (Suman Anna)
Date: Wed, 10 Feb 2016 14:13:40 -0600
Subject: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager
In-Reply-To: <20160209181031.GA23603@kahuna>
References: <1454690044-2560-1-git-send-email-nm@ti.com>
 <1454690044-2560-2-git-send-email-nm@ti.com>
 <CABb+yY3kGq_R49Xx4fK3UMqtuFiuv-pXJWvjkEFLPL9xRu5T4A@mail.gmail.com>
 <56B9DC30.5040806@ti.com>
 <CABb+yY24XzsWaSGLMCE4_nvgWx0OhhQmcaP41g06FxdjQYFchg@mail.gmail.com>
 <CAGo_u6qGaQj9Qvjwrm7cD=cr2UjLN+62tcquXYPsQrRjYD=UCw@mail.gmail.com>
 <20160209181031.GA23603@kahuna>
Message-ID: <56BB99F4.3040702@ti.com>

Hi Nishanth,

On 02/09/2016 12:10 PM, Menon, Nishanth wrote:
> On 09:43-20160209, Nishanth Menon wrote:
>> On Tue, Feb 9, 2016 at 8:54 AM, Jassi Brar <jassisinghbrar at gmail.com> wrote:
> [..]
>> Let me prototype this as part of of_xlate and see if I can pull the
>> qinst data back out.. obviously one negative will be that I will
>> register *all* valid channels as part of probe.. at least based on
>> initial code i wrote today morning..
> 
> OK - I believe I have it working now. How does the following look? If
> this looks fine to you, then I will post a v2 including the driver
> update.
> Changes here:
> 	- dropped the generic message-manager compatible
> 	- dropped child nodes
> 	- moved the valid queue information to driver (no longer in dts)
> 	- rx interrupts per SoC are explicitly named list in binding(and
> 	  dts)
> 
> Texas Instruments' Message Manager Driver
> ========================================
> 
> The Texas Instruments' Message Manager is a mailbox controller that has
> configurable queues selectable at SoC(System on Chip) integration. The Message
> manager is broken up into queues in different address regions that are called
> "proxies" - each instance is unidirectional and is instantiated at SoC
> integration level to indicate receive or transmit path.
> 
> Message Manager Device Node:
> ===========================
> Required properties:
> --------------------
> - compatible:		Shall be: "ti,k2g-message-manager"
> - reg-names 		queue_proxy_region - Map the queue proxy region.
> 			queue_state_debug_region - Map the queue state debug
> 			region.
> - reg:			Contains the register map per reg-names.
> - #mbox-cells		Shall be 2. Contains the queue ID and proxy ID in that
> 		        order referring to the transfer path.
> - interrupt-names:	Contains interrupt names matching the rx transfer path
> 			for a given SoC. Receive interrupts shall be of the
> 			format: "rx_<QID>_<PID>".
> 			For ti,k2g-message-manager, this shall contain:
> 				"rx_005_002", "rx_057_002"

Are these the only two that will ever be supported for
ti,k2g-message-manager or there can be more in the future? You did
mention about 11 possible valid qid_pid values for the ARM, and the
driver match data is
registering all of those mboxes.

> - interrupts:		Contains the interrupt information corresponding to
> 			interrupt-names property.
> 
> Example(K2G):
> ------------
> 
> 	msgmgr: msgmgr at 02a00000 {
> 		compatible = "ti,k2g-message-manager";
> 		#mbox-cells = <2>;
> 		reg-names = "queue_proxy_region", "queue_state_debug_region";
> 		reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
> 		interrupt-names = "rx_005_002",
> 				  "rx_057_002";
> 		interrupts = <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
> 			     <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
> 	};
> 
> 	pmmc: pmmc {
> 		[...]
> 		mbox-names = "rx", "tx";
> 		# RX queue ID is 5, proxy ID is 2
> 		# TX queue ID is 0, proxy ID is 0
> 		mboxes= <&msgmgr 5 2>,
> 			<&msgmgr 0 0>;
> 		[...]
> 	};

Yeah, this will also work. I am fine with this approach - my only
concern was that the probe doesn't have to go parsing all the nodes to
be able to register the mailbox channels with the mailbox core. Since
you are registering them using match data, that is not a concern anymore.

Anyway, will let Rob give the final ACK.

regards
Suman




From linus.walleij at linaro.org  Wed Feb 10 12:20:18 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 10 Feb 2016 21:20:18 +0100
Subject: [PATCH 1/2] ARM: l2x0: add three special L210 aux control flags
In-Reply-To: <1453933437-6666-1-git-send-email-linus.walleij@linaro.org>
References: <1453933437-6666-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <CACRpkdYFsTbPnbAcbw2FV7MmKJS7N9B8_pQvtX2fsoSHzJkdvQ@mail.gmail.com>

Argh, missed to cross-post this to devicetree at vger.kernel.org, I see my
mistake now.

Rob, care to take a quick look?

On Wed, Jan 27, 2016 at 11:23 PM, Linus Walleij
<linus.walleij at linaro.org> wrote:

> This adds support for setting the flag bits "wrap access disable",
> "write allocate override" and "exclusive abort disable" to the L210
> variant from the device tree.
>
> The "write allocate override" bit was used on the Nomadik and
> necessary to properly make use of the L210 cache on that machine
> without sporadic crashes.
>
> I took this oppportunity to add all three flags so we avoid excess
> patching for each one.
>
> Cc: Russell King <linux at arm.linux.org.uk>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
>  Documentation/devicetree/bindings/arm/l2c2x0.txt | 10 ++++++++++
>  arch/arm/mm/cache-l2x0.c                         | 18 ++++++++++++++++++
>  2 files changed, 28 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/l2c2x0.txt b/Documentation/devicetree/bindings/arm/l2c2x0.txt
> index fe0398c5c77b..975d1ae304d4 100644
> --- a/Documentation/devicetree/bindings/arm/l2c2x0.txt
> +++ b/Documentation/devicetree/bindings/arm/l2c2x0.txt
> @@ -74,6 +74,16 @@ Optional properties:
>    or "write through no write allocate" (for writes).
>    On systems where this may cause DMA buffer corruption, this property must be
>    specified to indicate that such transforms are precluded.
> +- arm,wrap-access-disable : (L210 only) if this flag is set, wrap accesses
> +  requested on slave ports are converted to linear acesses on master ports.
> +- arm,write-allocate-override : (L210 only) normally the L210 will use HPROT
> +  attributes, setting this bit overrides that behaviour and cause the cache
> +  to make all write-through and write-back accesses into read-write-allocate
> +  accesses.
> +- arm,exclusive-abort-disable : (L210 only) normally the cache controller sends
> +  an ERROR response back to exclusive access in a cacheable, shared memory
> +  region with the shared override bit set, but setting this flag disables the
> +  abort generation and the access is instead treated as cacheable, non-shared.
>  - arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310).
>  - arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310).
>  - arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index 9f9d54271aad..301c3c2dc09f 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -1076,6 +1076,24 @@ static void __init l2x0_of_parse(const struct device_node *np,
>                 val |= L2C_AUX_CTRL_SHARED_OVERRIDE;
>         }
>
> +       /* L210-specific aux control flags */
> +       if (of_device_is_compatible(np, "arm,l210-cache")) {
> +               if (of_property_read_bool(np, "arm,wrap-access-disable")) {
> +                       mask &= ~L210_AUX_CTRL_WRAP_DISABLE;
> +                       val |= L210_AUX_CTRL_WRAP_DISABLE;
> +               }
> +
> +               if (of_property_read_bool(np, "arm,write-allocate-override")) {
> +                       mask &= ~L210_AUX_CTRL_WA_OVERRIDE;
> +                       val |= L210_AUX_CTRL_WA_OVERRIDE;
> +               }
> +
> +               if (of_property_read_bool(np, "arm,exclusive-abort-disable")) {
> +                       mask &= ~L210_AUX_CTRL_EXCLUSIVE_ABORT;
> +                       val |= L210_AUX_CTRL_EXCLUSIVE_ABORT;
> +               }
> +       }
> +
>         ret = l2x0_cache_size_of_parse(np, aux_val, aux_mask, &assoc, SZ_256K);
>         if (ret)
>                 return;
> --
> 2.4.3
>

Yours,
Linus Walleij


From stephanolbrich at gmx.de  Wed Feb 10 12:26:05 2016
From: stephanolbrich at gmx.de (Stephan Olbrich)
Date: Wed, 10 Feb 2016 21:26:05 +0100
Subject: [PATCH 3/4] spi: bcm2835aux: set up spi-mode before asserting
 cs-gpio
In-Reply-To: <20160210190204.GD13270@sirena.org.uk>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <878u2s2xym.fsf@eliezer.anholt.net> <20160210190204.GD13270@sirena.org.uk>
Message-ID: <2743238.b2UJKq0efN@chaos-desktop>

Am Wednesday 10 February 2016, 19:02:04 schrieb Mark Brown:
> On Wed, Feb 10, 2016 at 10:59:29AM -0800, Eric Anholt wrote:
> > Oops, this makes more sense now.  Subject even mentioned gpio, and a
> > GPIO CS must be getting set around the transfer_one call.  I'll be ready
> > to send an r-b for a v2 with the speed update bug fixed (unless transfer
> > speeds are guaranteed to be constant between a prepare and unprepare).
> 
> No guarantee that they'll not change, especially in a situation where we
> have two devices on different speeds on a bus working at the same time.
Are you saying, that between a prepare and unprepare there could be transfers 
for another device? Then all the clock setting couldn't be done in prepare 
either.
Apart from that, if two transfers in the same message are not guarantied to 
have the same speed, this still needs to be fixed. I'll roll a v2.


From christoffer.dall at linaro.org  Wed Feb 10 12:40:12 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 10 Feb 2016 21:40:12 +0100
Subject: [PATCH 0/8] KVM/ARM: Guest Entry/Exit optimizations
In-Reply-To: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160210204012.GS5171@cbox>

On Mon, Feb 08, 2016 at 11:40:14AM +0000, Marc Zyngier wrote:
> I've recently been looking at our entry/exit costs, and profiling
> figures did show some very low hanging fruits.
> 
> The most obvious cost is that accessing the GIC HW is slow. As in
> "deadly slow", specially when GICv2 is involved. So not hammering the
> HW when there is nothing to write is immediately beneficial, as this
> is the most common cases (whatever people seem to think, interrupts
> are a *rare* event).
> 
> Another easy thing to fix is the way we handle trapped system
> registers. We do insist on (mostly) sorting them, but we do perform a
> linear search on trap. We can switch to a binary search for free, and
> get immediate benefits (the PMU code, being extremely trap-happy,
> benefits immediately from this).
> 
> With these in place, I see an improvement of 20 to 30% (depending on
> the platform) on our world-switch cycle count when running a set of
> hand-crafted guests that are designed to only perform traps.
> 

By the way, I took this whole stack of changes (wsinc, vhe, and
optimizations) and ran it on Mustang and fired up UEFI and did a reboot
and things seem to work, so that's a small shallow
'tested-by-something-else-than-a-linux-guest' statement from me.

-Christoffer


From arnd at arndb.de  Wed Feb 10 12:40:11 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 21:40:11 +0100
Subject: [PATCH V3 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver
 to work on both Zynq and Microblaze
In-Reply-To: <20160210172707.GA29590@NP-P-BURTON>
References: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
 <8520D5D51A55D047800579B09414719825881780@XAP-PVEXMBX01.xlnx.xilinx.com>
 <20160210172707.GA29590@NP-P-BURTON>
Message-ID: <2818168.2fmZIs86hN@wuerfel>

On Wednesday 10 February 2016 09:27:07 Paul Burton wrote:
> On Wed, Feb 10, 2016 at 05:55:51AM +0000, Bharat Kumar Gogada wrote:
> > > On Tue, Feb 09, 2016 at 04:11:56PM +0530, Bharat Kumar Gogada wrote:
> > > > Modifying Xilinx AXI PCIe Host Bridge Soft IP driver to work on both
> > > > Zynq and Microblaze Architectures.
> > > > With these modifications drivers/pci/host/pcie-xilinx.c, will work on
> > > > both Zynq and Microblaze Architectures.
> > > >
> > > > Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> > > > Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
> > > > ---
> > > > Changes:
> > > > Removed unneccessary architecture dependent number of MSI's.
> > > > Added #ifdef to pci_fixup_irqs which is ARM specific API.
> > > 
> > > Hi Bharat,
> > > 
> > > Why do you say pci_fixup_irqs is ARM-specific? It's declared in
> > > include/linux/pci.h, defined in drivers/pci/setup-irq.c & used by multiple
> > > architectures (alpha, arm, m68k, mips, sh, sparc, tile,
> > > unicore32 from a quick grep).
> > > 
> > > Will you not break INTX-style interrupts by removing this?
> > > 
> > I meant to say ARM specific w.r.t Microblaze architecture, which is
> > what this patch series are for. This has been already discussed in my
> > previous patch by  Arnd Bergmann and Lorenzo Pieralisi .
> > (https://lkml.org/lkml/2016/1/12/707)
> 
> Hi Bharat,
> 
> Ok, so you don't need it for microblaze but do need it for zynq/ARM. We
> also need it for MIPS, where my recent patches enable this driver. So if
> #ifdef'ing this is the current way forwards could you please invert the
> condition to #ifndef CONFIG_MICROBLAZE?

I think we are getting to the point where we should try much harder
to make sure nobody needs that hack and it all works out of the box.

	Arnd


From Jean-Philippe.Brucker at arm.com  Wed Feb 10 12:42:21 2016
From: Jean-Philippe.Brucker at arm.com (Jean-Philippe Brucker)
Date: Wed, 10 Feb 2016 20:42:21 +0000
Subject: [PATCH] ARM: virt: enable GICv3 system registers
In-Reply-To: <1453721639-24733-1-git-send-email-jean-philippe.brucker@arm.com>
References: <1453721639-24733-1-git-send-email-jean-philippe.brucker@arm.com>
Message-ID: <20160210204221.GA2749@e106794-lin.cambridge.arm.com>

On Mon, Jan 25, 2016 at 11:33:59AM +0000, Jean-Philippe Brucker wrote:
> ARMv8 introduces system registers for the Generic Interrupt Controller's
> CPU and virtual interfaces.
> When GICv3 is implemented, EL2 needs to allow the kernel to use those
> registers, by changing the value of ICC_HSRE.
> 
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker at arm.com>
> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>

Russell, does this look OK for your tree?

Thanks,
Jean-Philippe

> ---
>  arch/arm/kernel/hyp-stub.S |   24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S
> index 2a55373..0b1e4a9 100644
> --- a/arch/arm/kernel/hyp-stub.S
> +++ b/arch/arm/kernel/hyp-stub.S
> @@ -17,6 +17,7 @@
>   */
>  
>  #include <linux/init.h>
> +#include <linux/irqchip/arm-gic-v3.h>
>  #include <linux/linkage.h>
>  #include <asm/assembler.h>
>  #include <asm/virt.h>
> @@ -161,6 +162,29 @@ ARM_BE8(orr	r7, r7, #(1 << 25))     @ HSCTLR.EE
>  1:
>  #endif
>  
> +#ifdef CONFIG_ARM_GIC_V3
> +	@ Check whether GICv3 system registers are available
> +	mrc	p15, 0, r7, c0, c1, 1	@ ID_PFR1
> +	ubfx	r7, r7, #28, #4
> +	cmp	r7, #1
> +	bne	2f
> +
> +	@ Enable system register accesses
> +	mrc	p15, 4, r7, c12, c9, 5	@ ICC_HSRE
> +	orr	r7, r7, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
> +	mcr	p15, 4, r7, c12, c9, 5	@ ICC_HSRE
> +	isb
> +
> +	@ SRE bit could be forced to 0 by firmware.
> +	@ Check whether it sticks before accessing any other sysreg
> +	mrc	p15, 4, r7, c12, c9, 5	@ ICC_HSRE
> +	tst	r7, #ICC_SRE_EL2_SRE
> +	beq	2f
> +	mov	r7, #0
> +	mcr	p15, 4, r7, c12, c11, 0	@ ICH_HCR
> +2:
> +#endif
> +
>  	bx	lr			@ The boot CPU mode is left in r4.
>  ENDPROC(__hyp_stub_install_secondary)
>  
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From stephanolbrich at gmx.de  Wed Feb 10 12:45:27 2016
From: stephanolbrich at gmx.de (Stephan Olbrich)
Date: Wed, 10 Feb 2016 21:45:27 +0100
Subject: [PATCH 4/4] spi: bcm2835aux: fix CPOL/CPHA setting
In-Reply-To: <87a8n94e3x.fsf@eliezer.anholt.net>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <1455041435-8015-5-git-send-email-stephanolbrich@gmx.de>
 <87a8n94e3x.fsf@eliezer.anholt.net>
Message-ID: <7621387.PU4Z2tGlUh@chaos-desktop>

Am Tuesday 09 February 2016, 16:13:06 schrieb Eric Anholt:
> stephanolbrich at gmx.de writes:
> > From: Stephan Olbrich <stephanolbrich at gmx.de>
> > 
> > The auxiliary spi supports only CPHA=0 modes as the first bit is
> > always output to the pin before the first clock cycle. In CPHA=1
> > modes the first clock edge outputs the second bit hence the slave
> > can never read the first bit.
> > 
> > Also the CPHA registers switch between clocking data in/out on
> > rising/falling edge hence depend on the CPOL setting.
> > 
> > Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
> > ---
> > 
> >  drivers/spi/spi-bcm2835aux.c | 10 +++++-----
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
> > index b90aa34..169f521 100644
> > --- a/drivers/spi/spi-bcm2835aux.c
> > +++ b/drivers/spi/spi-bcm2835aux.c
> > @@ -386,12 +386,12 @@ static int bcm2835aux_spi_prepare_message(struct
> > spi_master *master,> 
> >  	bs->cntl[1] = BCM2835_AUX_SPI_CNTL1_MSBF_IN;
> >  	
> >  	/* handle all the modes */
> > 
> > -	if (spi->mode & SPI_CPOL)
> > +	if (spi->mode & SPI_CPOL) {
> > 
> >  		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPOL;
> > 
> > -	if (spi->mode & SPI_CPHA)
> > -		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT |
> > -			       BCM2835_AUX_SPI_CNTL0_CPHA_IN;
> > -
> > +		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT;
> > +	} else {
> > +		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_IN;
> > +	}
> > 
> >  	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1]);
> >  	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL0, bs->cntl[0]);
> 
> (Note for other readers: A better name for CNTL0_CPHA_* would be
> CNTL0_*_RISING).

Should I rename them? 

> I think you're right about not actually supporting CPHA.  I don't see
> wany way to keep bit 1 out lasting through the first full clock cycle.
> I think Stefan's right that we should drop CPHA from MODE_BITS
> (actually, MODE_BITS would be nicer if we just merged it into its one
> user, I think).

You are right. I'll fix that.



From nm at ti.com  Wed Feb 10 12:51:25 2016
From: nm at ti.com (Nishanth Menon)
Date: Wed, 10 Feb 2016 14:51:25 -0600
Subject: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager
In-Reply-To: <56BB99F4.3040702@ti.com>
References: <1454690044-2560-1-git-send-email-nm@ti.com>
 <1454690044-2560-2-git-send-email-nm@ti.com>
 <CABb+yY3kGq_R49Xx4fK3UMqtuFiuv-pXJWvjkEFLPL9xRu5T4A@mail.gmail.com>
 <56B9DC30.5040806@ti.com>
 <CABb+yY24XzsWaSGLMCE4_nvgWx0OhhQmcaP41g06FxdjQYFchg@mail.gmail.com>
 <CAGo_u6qGaQj9Qvjwrm7cD=cr2UjLN+62tcquXYPsQrRjYD=UCw@mail.gmail.com>
 <20160209181031.GA23603@kahuna> <56BB99F4.3040702@ti.com>
Message-ID: <CAGo_u6oNKsDr3yO8KXhpdc9qQYXE7TJv4=Nu3fsmAYt+EFeNBw@mail.gmail.com>

On Wed, Feb 10, 2016 at 2:13 PM, Suman Anna <s-anna at ti.com> wrote:
> Hi Nishanth,
>
> On 02/09/2016 12:10 PM, Menon, Nishanth wrote:
>> On 09:43-20160209, Nishanth Menon wrote:
>>> On Tue, Feb 9, 2016 at 8:54 AM, Jassi Brar <jassisinghbrar at gmail.com> wrote:
>> [..]
>>> Let me prototype this as part of of_xlate and see if I can pull the
>>> qinst data back out.. obviously one negative will be that I will
>>> register *all* valid channels as part of probe.. at least based on
>>> initial code i wrote today morning..
>>
>> OK - I believe I have it working now. How does the following look? If
>> this looks fine to you, then I will post a v2 including the driver
>> update.
>> Changes here:
>>       - dropped the generic message-manager compatible
>>       - dropped child nodes
>>       - moved the valid queue information to driver (no longer in dts)
>>       - rx interrupts per SoC are explicitly named list in binding(and
>>         dts)
>>
>> Texas Instruments' Message Manager Driver
>> ========================================
>>
>> The Texas Instruments' Message Manager is a mailbox controller that has
>> configurable queues selectable at SoC(System on Chip) integration. The Message
>> manager is broken up into queues in different address regions that are called
>> "proxies" - each instance is unidirectional and is instantiated at SoC
>> integration level to indicate receive or transmit path.
>>
>> Message Manager Device Node:
>> ===========================
>> Required properties:
>> --------------------
>> - compatible:         Shall be: "ti,k2g-message-manager"
>> - reg-names           queue_proxy_region - Map the queue proxy region.
>>                       queue_state_debug_region - Map the queue state debug
>>                       region.
>> - reg:                        Contains the register map per reg-names.
>> - #mbox-cells         Shall be 2. Contains the queue ID and proxy ID in that
>>                       order referring to the transfer path.
>> - interrupt-names:    Contains interrupt names matching the rx transfer path
>>                       for a given SoC. Receive interrupts shall be of the
>>                       format: "rx_<QID>_<PID>".
>>                       For ti,k2g-message-manager, this shall contain:
>>                               "rx_005_002", "rx_057_002"
>
> Are these the only two that will ever be supported for
> ti,k2g-message-manager or there can be more in the future? You did
> mention about 11 possible valid qid_pid values for the ARM, and the
> driver match data is
> registering all of those mboxes.


As per the internal TRM, there *only* 2 rx interrupts to the public
world ARM on K2G. I just noticed that the public TRM conveniently
stripped out every single useful information and replaced with
TRM!!!!!*&^*&^&*%&^%&%&!!! Anyways, checked internal documentation to
verify as well. we have multiple output paths to various compute
systems, but only 2 receive paths.

Ofcourse a different SoC will have different integration, which why
the interrupt list will have to be compatible property.

>
>> - interrupts:         Contains the interrupt information corresponding to
>>                       interrupt-names property.
>>
>> Example(K2G):
>> ------------
>>
>>       msgmgr: msgmgr at 02a00000 {
>>               compatible = "ti,k2g-message-manager";
>>               #mbox-cells = <2>;
>>               reg-names = "queue_proxy_region", "queue_state_debug_region";
>>               reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
>>               interrupt-names = "rx_005_002",
>>                                 "rx_057_002";
>>               interrupts = <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
>>                            <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
>>       };
>>
>>       pmmc: pmmc {
>>               [...]
>>               mbox-names = "rx", "tx";
>>               # RX queue ID is 5, proxy ID is 2
>>               # TX queue ID is 0, proxy ID is 0
>>               mboxes= <&msgmgr 5 2>,
>>                       <&msgmgr 0 0>;
>>               [...]
>>       };
>
> Yeah, this will also work. I am fine with this approach - my only
> concern was that the probe doesn't have to go parsing all the nodes to
> be able to register the mailbox channels with the mailbox core. Since
> you are registering them using match data, that is not a concern anymore.
>
> Anyway, will let Rob give the final ACK.


Thanks for the review. will wait for Rob and Jassi or post a new rev on monday.

---
Regards,
Nishanth Menon


From Suravee.Suthikulpanit at amd.com  Wed Feb 10 12:56:16 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Thu, 11 Feb 2016 03:56:16 +0700
Subject: [PATCH v11 3/4] ARM64: add SBSA Generic Watchdog device node in
 amd-seattle-soc.dtsi
In-Reply-To: <1455037240-16192-4-git-send-email-fu.wei@linaro.org>
References: <1455037240-16192-1-git-send-email-fu.wei@linaro.org>
 <1455037240-16192-4-git-send-email-fu.wei@linaro.org>
Message-ID: <56BBA3F0.4010908@amd.com>

Hi Fu Wei,

On 2/10/16 00:00, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei at linaro.org>
>
> This can be a example of adding SBSA Generic Watchdog device node
> into some dts files for the Soc which contains SBSA Generic Watchdog.
>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
> Signed-off-by: Fu Wei <fu.wei at linaro.org>
> ---
>   arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 9 +++++++++
>   1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
> index 2874d92..67eb636 100644
> --- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
> +++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
> @@ -84,6 +84,15 @@
>   			clock-names = "uartclk", "apb_pclk";
>   		};
>
> +		watchdog0: watchdog at e0bb0000 {
> +			compatible = "arm,sbsa-gwdt";
> +			reg = <0x0 0xe0bc0000 0 0x1000>,
> +				<0x0 0xe0bb0000 0 0x1000>;
> +			interrupts = <0 337 4>;
> +			timeout-sec = <15>;
> +			status = "disabled";

Could you please remove this status line? I do not think it is necessary 
for this one here anymore.

Thanks,
Suravee

> +		};
> +
>   		spi0: ssp at e1020000 {
>   			status = "disabled";
>   			compatible = "arm,pl022", "arm,primecell";
>


From tn at semihalf.com  Wed Feb 10 13:09:34 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Wed, 10 Feb 2016 22:09:34 +0100
Subject: [PATCH V4 11/23] pci, acpi: Move ACPI host bridge device
 companion assignment to core code.
In-Reply-To: <20160209180227.GC22868@red-moon>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
 <1454606941-9523-12-git-send-email-tn@semihalf.com>
 <20160209180227.GC22868@red-moon>
Message-ID: <56BBA70E.908@semihalf.com>

On 02/09/2016 07:02 PM, Lorenzo Pieralisi wrote:
> On Thu, Feb 04, 2016 at 06:28:49PM +0100, Tomasz Nowicki wrote:
>> Currently we have two platforms (x86 & ia64) capable of PCI ACPI host
>> bridge initialization. They both use sysdata to pass down parent
>> device reference and both rely on NULL parent in pci_create_root_bus()
>> to validate sysdata content.
>>
>> It looks hacky and prevents us from getting some firmware specific
>> info for PCI host controller e.g. PCI bus domain number.
>> However, we overcome that blocker by passing down parent
>> device via pci_create_root_bus parameter (as the ACPI device type)
>> and using ACPI_COMPANION_SET in core code for ACPI boot method.
>> ACPI_COMPANION_SET is safe to run for all cases DT, ACPI and DT&ACPI.
>>
>> Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
>> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
>> Tested-by: Duc Dang <dhdang at apm.com>
>> Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
>> Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
>> Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
>> Tested-by: Sinan Kaya <okaya at codeaurora.org>
>> ---
>>   drivers/acpi/pci_root.c | 5 ++++-
>>   drivers/pci/probe.c     | 2 ++
>>   2 files changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
>> index ae3fe4e..a65c8c2 100644
>> --- a/drivers/acpi/pci_root.c
>> +++ b/drivers/acpi/pci_root.c
>> @@ -846,7 +846,10 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>>   
>>   	pci_acpi_root_add_resources(info);
>>   	pci_add_resource(&info->resources, &root->secondary);
>> -	bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
>> +
>> +	/* Root bridge device needs to be sure of parent ACPI type */
> You can improve the comment.
>
> "pci_create_root_bus() needs to detect the parent device type,
> so initialize its companion data accordingly".
Agree, I will change comment.
>
>> +	ACPI_COMPANION_SET(&device->dev, device);
>> +	bus = pci_create_root_bus(&device->dev, busnum, ops->pci_ops,
>>   				  sysdata, &info->resources);
>>   	if (!bus)
>>   		goto out_release_info;
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 6d7ab9b..81dd3a2 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -2100,6 +2100,8 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
>>   	bridge->dev.parent = parent;
>>   	bridge->dev.release = pci_release_host_bridge_dev;
>>   	dev_set_name(&bridge->dev, "pci%04x:%02x", pci_domain_nr(b), bus);
>> +	ACPI_COMPANION_SET(&bridge->dev,
>> +			   parent ? to_acpi_device_node(parent->fwnode) : NULL);
> if (parent)
> 	ACPI_COMPANION_SET(&bridge->dev, ACPI_COMPANION(parent));
>
> ?
Looks better.
>
> It seems fine to me, hopefully Rafael can have a look to countercheck.
>
> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Thanks,
Tomasz



From aaro.koskinen at iki.fi  Wed Feb 10 13:12:26 2016
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Wed, 10 Feb 2016 23:12:26 +0200
Subject: [PATCH] ARM: OMAP2+: Fix onenand initialization to avoid
 filesystem corruption
In-Reply-To: <20160208193644.GU19432@atomide.com>
References: <linux-kernel@vger.kernel.org>
 <1454683028-4193-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
 <20160208193644.GU19432@atomide.com>
Message-ID: <20160210211226.GB1640@darkstar.musicnaut.iki.fi>

Hi,

On Mon, Feb 08, 2016 at 11:36:45AM -0800, Tony Lindgren wrote:
> * Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com> [160205 06:38]:
> > Commit <e7b11dc7b77bfce0a351230a5feeadc1d0bba997> ("ARM: OMAP2+: Fix
> > onenand rate detection to avoid filesystem corruption") partially fixed
> > onenand configuration when GPMC module is reset. Finish the job by also
> > providing the correct values in ONENAND_REG_SYS_CFG1 register.
> 
> OK. So probably the INT or RDY polarity made the ECC not work.
> 
> Aaro, care to dump out also the nolo configured CFG1 value from
> n8x0 and n9(50)?
> 
> You can do it by adding something like this to the beginning
> of set_onenand_cfg():
> 
> pr_info("CFG1: 0x%04x\n", readw(onenand_base + ONENAND_REG_SYS_CFG1));
> 
> And presumably the values are the same as on n900. If not, we
> should do the legacy file system flash test on all of them
> before committing this fix.

I got these (with CONFIG_OMAP_GPMC_DEBUG also enabled):

N800:
[    2.803100] CFG1: 0x46c0
[    3.150115] CFG1: 0x06c0

N810:
[    2.802368] CFG1: 0x46c0
[    3.148620] CFG1: 0x06c0

N900:
[    4.965576] CFG1: 0x46c0
[    5.333740] CFG1: 0x06c0

N950:
[    4.217193] CFG1: 0x66c4
[    4.583221] CFG1: 0x06c0

N9:
[    4.212677] CFG1: 0x66c4
[    4.578613] CFG1: 0x06c0

A.


From Suravee.Suthikulpanit at amd.com  Wed Feb 10 13:13:50 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Thu, 11 Feb 2016 04:13:50 +0700
Subject: [PATCH V2 03/12] dtb: amd: Fix DMA ranges in device tree
In-Reply-To: <2845776.WTPtnQzg8d@wuerfel>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
 <1454954357-8395-4-git-send-email-Suravee.Suthikulpanit@amd.com>
 <2845776.WTPtnQzg8d@wuerfel>
Message-ID: <56BBA80E.6090205@amd.com>

Hi Arnd,

On 2/9/16 21:57, Arnd Bergmann wrote:
> On Monday 08 February 2016 11:59:08 Suravee Suthikulpanit wrote:
>> From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
>>
>> Fix DMA ranges of smb0 and pcie0 nodes in AMD Seattle SOC.
>>
>> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
>>
>
> This could use a changelog text to explain why it's broken and how the
> fix works.
>
> 	Arnd
>

So, I have not experience the breakage. However, IIUC, the GICv2m MSI 
frame is also considered DMA-able. So, I think it should be included in 
the dma-range specified here. Please let me know if my assumption is 
incorrect. Otherwise, I will include more description in the commit log 
in my next rev.

Thanks,
Suravee


From arnd at arndb.de  Wed Feb 10 13:19:51 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 10 Feb 2016 22:19:51 +0100
Subject: [PATCH V2 03/12] dtb: amd: Fix DMA ranges in device tree
In-Reply-To: <56BBA80E.6090205@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
 <2845776.WTPtnQzg8d@wuerfel> <56BBA80E.6090205@amd.com>
Message-ID: <5986200.Q9dxHf9bIM@wuerfel>

On Thursday 11 February 2016 04:13:50 Suravee Suthikulpanit wrote:
> 
> On 2/9/16 21:57, Arnd Bergmann wrote:
> > On Monday 08 February 2016 11:59:08 Suravee Suthikulpanit wrote:
> >> From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
> >>
> >> Fix DMA ranges of smb0 and pcie0 nodes in AMD Seattle SOC.
> >>
> >> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
> >>
> >
> > This could use a changelog text to explain why it's broken and how the
> > fix works.
> >
> >       Arnd
> >
> 
> So, I have not experience the breakage. However, IIUC, the GICv2m MSI 
> frame is also considered DMA-able. So, I think it should be included in 
> the dma-range specified here. Please let me know if my assumption is 
> incorrect. Otherwise, I will include more description in the commit log 
> in my next rev.

No, I think this makes sense. Just put a more explanation into the changelog
when those things are not obvious from looking at the change.

	Arnd


From tn at semihalf.com  Wed Feb 10 13:21:15 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Wed, 10 Feb 2016 22:21:15 +0100
Subject: [PATCH V4 12/23] x86, ia64, pci: Remove ACPI companion device
 from platform specific data.
In-Reply-To: <20160209172800.GB22868@red-moon>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
 <1454606941-9523-13-git-send-email-tn@semihalf.com>
 <20160209172800.GB22868@red-moon>
Message-ID: <56BBA9CB.5060407@semihalf.com>

On 02/09/2016 06:28 PM, Lorenzo Pieralisi wrote:
> This patch has to be squashed with the previous one otherwise it
> has bisectability issues (ie the previous patch passes the parent
> to the pci_create_root_bus() call so, without this patch applied,
> the companion initialization would fail).
I do not think so. The previous patch passes the parent to the 
pci_create_root_bus(), indeed, so pci_create_root_bus() set companion 
device before calling pcibios_root_bridge_prepare() (for both cases x86 
and ia64). In turn, pcibios_root_bridge_prepare() will do nothing, since 
bridge->dev.parent != NULL. After all, pcibios_root_bridge_prepare() is 
dead code.
>
> Other than that:
>
> Reviewed-by: Lorenzo Pieralisi<lorenzo.pieralisi at arm.com>
Thanks!

Tomasz


From eric at anholt.net  Wed Feb 10 13:24:37 2016
From: eric at anholt.net (Eric Anholt)
Date: Wed, 10 Feb 2016 13:24:37 -0800
Subject: [PATCH 4/4] spi: bcm2835aux: fix CPOL/CPHA setting
In-Reply-To: <7621387.PU4Z2tGlUh@chaos-desktop>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <1455041435-8015-5-git-send-email-stephanolbrich@gmx.de>
 <87a8n94e3x.fsf@eliezer.anholt.net> <7621387.PU4Z2tGlUh@chaos-desktop>
Message-ID: <871t8k9s2y.fsf@eliezer.anholt.net>

Stephan Olbrich <stephanolbrich at gmx.de> writes:

> Am Tuesday 09 February 2016, 16:13:06 schrieb Eric Anholt:
>> stephanolbrich at gmx.de writes:
>> > From: Stephan Olbrich <stephanolbrich at gmx.de>
>> > 
>> > The auxiliary spi supports only CPHA=0 modes as the first bit is
>> > always output to the pin before the first clock cycle. In CPHA=1
>> > modes the first clock edge outputs the second bit hence the slave
>> > can never read the first bit.
>> > 
>> > Also the CPHA registers switch between clocking data in/out on
>> > rising/falling edge hence depend on the CPOL setting.
>> > 
>> > Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
>> > ---
>> > 
>> >  drivers/spi/spi-bcm2835aux.c | 10 +++++-----
>> >  1 file changed, 5 insertions(+), 5 deletions(-)
>> > 
>> > diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
>> > index b90aa34..169f521 100644
>> > --- a/drivers/spi/spi-bcm2835aux.c
>> > +++ b/drivers/spi/spi-bcm2835aux.c
>> > @@ -386,12 +386,12 @@ static int bcm2835aux_spi_prepare_message(struct
>> > spi_master *master,> 
>> >  	bs->cntl[1] = BCM2835_AUX_SPI_CNTL1_MSBF_IN;
>> >  	
>> >  	/* handle all the modes */
>> > 
>> > -	if (spi->mode & SPI_CPOL)
>> > +	if (spi->mode & SPI_CPOL) {
>> > 
>> >  		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPOL;
>> > 
>> > -	if (spi->mode & SPI_CPHA)
>> > -		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT |
>> > -			       BCM2835_AUX_SPI_CNTL0_CPHA_IN;
>> > -
>> > +		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT;
>> > +	} else {
>> > +		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_IN;
>> > +	}
>> > 
>> >  	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1]);
>> >  	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL0, bs->cntl[0]);
>> 
>> (Note for other readers: A better name for CNTL0_CPHA_* would be
>> CNTL0_*_RISING).
>
> Should I rename them? 

Up to you.  I'm happy to see the work you've done fixing the driver
here, and I don't want to pile things on.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160210/3685dd6e/attachment.sig>

From tony at atomide.com  Wed Feb 10 13:35:07 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Feb 2016 13:35:07 -0800
Subject: [PATCH] ARM: OMAP3: Fix imprecise external abort for off mode on 36xx
Message-ID: <1455140107-3328-1-git-send-email-tony@atomide.com>

With CONFIG_DEBUG_RODATA enabled I started noticing imprecise external
aborts on a dm3730 when hitting off idle. These don't seem to happen
on 34xx.

Pretty much changing anything in the code made these go away, like
changing .config options. At first I though it might be an alignment
issue in the 36xx specific assembly code in sleep34xx.S, or something
related to the recent rodata fixes. But that does not seem to be
the case. It seems to be a timing issue instead.

Adding few extra nop instructions after the wfi seems to fix the
issue. When adding 5 nops, the errors showed up less often. With
add ed 6 nops, I don't seem to get them at all any longer.

Cc: Grygorii Strashko <grygorii.strashko at ti.com>
Cc: Nishanth Menon <nm at ti.com>
Cc: Richard Woodruff <r-woodruff2 at ti.com>
Cc: Tero Kristo <t-kristo at ti.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---

Anybody else seen this issue before?

---
 arch/arm/mach-omap2/sleep34xx.S | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 1b9f052..0fbaa08 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -264,6 +264,12 @@ ENTRY(omap3_do_wfi)
 	nop
 	nop
 	nop
+	nop
+	nop
+	nop
+	nop
+	nop
+	nop
 
 /*
  * This function implements the erratum ID i581 WA:
-- 
2.7.0



From david.brown at linaro.org  Wed Feb 10 13:52:22 2016
From: david.brown at linaro.org (David Brown)
Date: Wed, 10 Feb 2016 13:52:22 -0800
Subject: [PATCH] arm64: vdso: Mark vDSO code as read-only
Message-ID: <1455141142-6838-1-git-send-email-david.brown@linaro.org>

Although the arm64 vDSO is cleanly separated by code/data with the
code being read-only in userspace mappings, the code page is still
writable from the kernel.  There have been exploits (such as
http://itszn.com/blog/?p=21) that take advantage of this on x86 to go
from a bad kernel write to full root.

Prevent this specific exploit on arm64 by putting the vDSO code page
in read-only memory as well.

Before the change:
[    3.138366] vdso: 2 pages (1 code @ ffffffc000a71000, 1 data @ ffffffc000a70000)
---[ Kernel Mapping ]---
0xffffffc000000000-0xffffffc000082000         520K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc000082000-0xffffffc000200000        1528K     ro x  SHD AF            UXN MEM/NORMAL
0xffffffc000200000-0xffffffc000800000           6M     ro x  SHD AF        BLK UXN MEM/NORMAL
0xffffffc000800000-0xffffffc0009b6000        1752K     ro x  SHD AF            UXN MEM/NORMAL
0xffffffc0009b6000-0xffffffc000c00000        2344K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc000c00000-0xffffffc008000000         116M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc00c000000-0xffffffc07f000000        1840M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc800000000-0xffffffc840000000           1G     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc840000000-0xffffffc87ae00000         942M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc87ae00000-0xffffffc87ae70000         448K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc87af80000-0xffffffc87af8a000          40K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc87af8b000-0xffffffc87b000000         468K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc87b000000-0xffffffc87fe00000          78M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc87fe00000-0xffffffc87ff50000        1344K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc87ff90000-0xffffffc87ffa0000          64K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc87fff0000-0xffffffc880000000          64K     RW NX SHD AF            UXN MEM/NORMAL

After:
[    3.138368] vdso: 2 pages (1 code @ ffffffc0006de000, 1 data @ ffffffc000a74000)
---[ Kernel Mapping ]---
0xffffffc000000000-0xffffffc000082000         520K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc000082000-0xffffffc000200000        1528K     ro x  SHD AF            UXN MEM/NORMAL
0xffffffc000200000-0xffffffc000800000           6M     ro x  SHD AF        BLK UXN MEM/NORMAL
0xffffffc000800000-0xffffffc0009b8000        1760K     ro x  SHD AF            UXN MEM/NORMAL
0xffffffc0009b8000-0xffffffc000c00000        2336K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc000c00000-0xffffffc008000000         116M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc00c000000-0xffffffc07f000000        1840M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc800000000-0xffffffc840000000           1G     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc840000000-0xffffffc87ae00000         942M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc87ae00000-0xffffffc87ae70000         448K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc87af80000-0xffffffc87af8a000          40K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc87af8b000-0xffffffc87b000000         468K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc87b000000-0xffffffc87fe00000          78M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc87fe00000-0xffffffc87ff50000        1344K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc87ff90000-0xffffffc87ffa0000          64K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc87fff0000-0xffffffc880000000          64K     RW NX SHD AF            UXN MEM/NORMAL

Inspired by https://lkml.org/lkml/2016/1/19/494 based on work by the
PaX Team, Brad Spengler, and Kees Cook.

Signed-off-by: David Brown <david.brown at linaro.org>
---
 arch/arm64/kernel/vdso/vdso.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/kernel/vdso/vdso.S b/arch/arm64/kernel/vdso/vdso.S
index 60c1db5..db7c0f2 100644
--- a/arch/arm64/kernel/vdso/vdso.S
+++ b/arch/arm64/kernel/vdso/vdso.S
@@ -24,6 +24,7 @@
 	__PAGE_ALIGNED_DATA
 
 	.globl vdso_start, vdso_end
+	.section .rodata
 	.balign PAGE_SIZE
 vdso_start:
 	.incbin "arch/arm64/kernel/vdso/vdso.so"
-- 
2.7.1



From f.fainelli at gmail.com  Wed Feb 10 14:08:07 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Wed, 10 Feb 2016 14:08:07 -0800
Subject: [PATCH 4/6] dt-bindings: watchdog: Add ARM SP805 DT bindings
In-Reply-To: <1455084651-29325-5-git-send-email-anup.patel@broadcom.com>
References: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
 <1455084651-29325-5-git-send-email-anup.patel@broadcom.com>
Message-ID: <56BBB4C7.9040209@gmail.com>

On 09/02/16 22:10, Anup Patel wrote:
> The ARM SP805 DT node is already present in various DTS files.
> This patch adds missing DT bindings documentation for ARM SP805.
> 
> Signed-off-by: Anup Patel <anup.patel at broadcom.com>
> Reviewed-by: Ray Jui <rjui at broadcom.com>
> Reviewed-by: Vikram Prakash <vikramp at broadcom.com>
> Reviewed-by: Scott Branden <sbranden at broadcom.com>

Rob, we would probably want an Ack from you on this one, but should we
route this through an arm-soc pull request for Broadcom SoCs, or do you
want to pick it in your tree directly?

Thanks!

> ---
>  .../devicetree/bindings/watchdog/arm,sp805.txt          | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/watchdog/arm,sp805.txt
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/arm,sp805.txt b/Documentation/devicetree/bindings/watchdog/arm,sp805.txt
> new file mode 100644
> index 0000000..6ebb77d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/arm,sp805.txt
> @@ -0,0 +1,17 @@
> +ARM AMBA Primecell SP805 Watchdog
> +
> +Required properties:
> +- compatible: Should be "arm,sp805" & "arm,primecell"
> +- reg: Should contain location and length for watchdog timer register.
> +- interrupts: Should contain the list of watchdog timer interrupts.
> +- clocks: clocks driving the watchdog timer hardware. This list should be 2
> +	clocks. With 2 clocks, the order is wdogclk clock, apb_pclk.
> +
> +Example:
> +	wdt at 66090000 {
> +		compatible = "arm,sp805", "arm,primecell";
> +		reg = <0x66090000 0x1000>;
> +		interrupts = <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>;
> +		clocks = <&apb_pclk>,<&apb_pclk>;
> +		clock-names = "wdogclk", "apb_pclk";
> +	};
> 


-- 
Florian


From rjw at rjwysocki.net  Wed Feb 10 14:29:31 2016
From: rjw at rjwysocki.net (Rafael J. Wysocki)
Date: Wed, 10 Feb 2016 23:29:31 +0100
Subject: [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen
In-Reply-To: <alpine.DEB.2.02.1602091116240.27008@kaball.uk.xensource.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
 <2213954.ztOe55fprN@vostro.rjw.lan>
 <alpine.DEB.2.02.1602091116240.27008@kaball.uk.xensource.com>
Message-ID: <44113385.2QnPtvxQx0@vostro.rjw.lan>

On Tuesday, February 09, 2016 11:19:02 AM Stefano Stabellini wrote:
> On Mon, 8 Feb 2016, Rafael J. Wysocki wrote:
> > On Monday, February 08, 2016 10:57:01 AM Stefano Stabellini wrote:
> > > On Sat, 6 Feb 2016, Rafael J. Wysocki wrote:
> > > > On Fri, Feb 5, 2016 at 4:05 AM, Shannon Zhao <zhaoshenglong at huawei.com> wrote:
> > > > > From: Shannon Zhao <shannon.zhao at linaro.org>
> > > > >
> > > > > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > > > > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > > > > UART is used by Xen. So here it hides UART from Dom0.
> > > > >
> > > > > Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> > > > > Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> > > > 
> > > > Well, this doesn't look right to me.
> > > > 
> > > > We need to find a nicer way to achieve what you want.
> > > 
> > > I take that you are talking about how to honor the STAO table in Linux.
> > > Do you have any concrete suggestions?
> > 
> > I do.
> > 
> > The last hunk of the patch is likely what it needs to be, although I'm
> > not sure if the place it is added to is the right one.  That's a minor thing,
> > though.
> > 
> > The other part is problematic.  Not that as it doesn't work, but because of
> > how it works.  With these changes the device will be visible to the OS (in
> > fact to user space even), but will never be "present".  I'm not sure if
> > that's what you want?
> > 
> > It might be better to add a check to acpi_bus_type_and_status() that will
> > evaluate the "should ignore?" thing and return -ENODEV if this is true.  This
> > way the device won't be visible at all.
> 
> Something like below?  Actually your suggestion is better, thank you!
> 
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 78d5f02..4778c51 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1455,6 +1455,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
>  	if (ACPI_FAILURE(status))
>  		return -ENODEV;
>  
> +	if (acpi_check_device_is_ignored(handle))
> +		return -ENODEV;
> +
>  	switch (acpi_type) {
>  	case ACPI_TYPE_ANY:		/* for ACPI_ROOT_OBJECT */
>  	case ACPI_TYPE_DEVICE:
> 

I thought about doing that under ACPI_TYPE_DEVICE, because it shouldn't be
applicable to the other types.  But generally, yes.

Plus I'd move the table checks to acpi_scan_init(), so the UART address can
be a static variable in scan.c.

Also maybe rename acpi_check_device_is_ignored() to something like
acpi_device_should_be_hidden().

Thanks,
Rafael



From andrew at lunn.ch  Wed Feb 10 14:57:17 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Wed, 10 Feb 2016 23:57:17 +0100
Subject: net: mv643xx: interface does not transmit after some time
In-Reply-To: <A6128DBC-59DB-4231-A08D-B84C1D8C26CC@schloeter.net>
References: <E4F9E0D0-9DA8-4E33-9F89-B49E47F11CE0@schloeter.net>
 <20160206183414.GD17218@lunn.ch>
 <20160206231935.GA30734@jirafa.cyrius.com>
 <2ACB3A0B-DD51-43C1-A56E-E7C175645554@schloeter.net>
 <20160207203545.GB29107@lunn.ch>
 <A21B89D4-5826-4F97-A1C9-E62E5B724082@schloeter.net>
 <312E318A-CAE1-45B1-AB13-EA147B48E315@schloeter.net>
 <A6128DBC-59DB-4231-A08D-B84C1D8C26CC@schloeter.net>
Message-ID: <20160210225717.GD14610@lunn.ch>

On Wed, Feb 10, 2016 at 07:40:54PM +0100, Thomas Schl?ter wrote:
> 
> > Am 08.02.2016 um 19:49 schrieb Thomas Schl?ter <thomas at schloeter.net>:
> > 
> > 
> >> Am 07.02.2016 um 22:07 schrieb Thomas Schl?ter <thomas at schloeter.net>:
> >> 
> >> Am 07.02.2016 um 21:35 schrieb Andrew Lunn <andrew at lunn.ch>:
> >>> 
> >>>>> FWIW, we had a similar bug report in Debian recently:
> >>>>> https://lists.debian.org/debian-arm/2016/01/msg00098.html
> >>> 
> >>> Hi Thomas
> >>> 
> >>> I this thread, Ian Campbell mentions a patch. Please could you try
> >>> that patch and see if it fixes your problem.
> >>> 
> >>> Thanks
> >>> 	Andrew
> >> 
> >> Hi Andrew,
> >> 
> >> I just applied the patch and the NAS is now running it. I???ll try to crash it tonight and keep you informed whether it worked.
> >> 
> >> Thanks
> >> 	Thomas
> > 
> > Hi Andrew,
> > 
> > the patch did not fix the problem. After 1.2 GiB RX and 950 MiB TX, the interface crashed again.
> > 
> > Now I switched off RX/TX offload just to make sure we are talking about the same problem. If we are, the interface should be stable without offload, right?
> > 
> > 	Thomas
> 
> Okay, so I have installed ethtool and switched off all offload features available. Now the NAS is running rock solid for two days. I backed up my Mac using Time Machine / netatalk (450 GiB transferred) and some Linux machines via NFS (100 GiB total) without a problem.
> 
> How much code is used for mv643xx offload functionality?
> Is it possible to debug things in the driver and figure out what happens during the crash?
> Is the hardware offload interface proprietary or reverse engineered or is it a well known API that can be analyzed?

Hi Thomas

Ezequiel Garcia probably knows this part of the driver and hardware
the best...

    Andrew


From tony at atomide.com  Wed Feb 10 15:02:43 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Feb 2016 15:02:43 -0800
Subject: [PATCH 0/7] PM runtime regression fixes for omaps
Message-ID: <1455145370-20301-1-git-send-email-tony@atomide.com>

Hi all,

Here are some PM runtime regression fixes for omaps after recent
pm_runtime_reinit changes.

We basically have to use pm_runtime_put_sync_suspend() or
a combination of pm_runtime_dont_use_autosuspend() and
pm_runtime_put_sync() if the driver has enabled autoidle.

If no objections, I'd like to merge this whole series via
the ARM SoC tree.

Regards,

Tony


Tony Lindgren (7):
  mmc: omap_hsmmc: Fix PM regression with deferred probe for
    pm_runtime_reinit
  i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit
  spi: omap2-mcspi: Fix PM regression with deferred probe for
    pm_runtime_reinit
  serial: 8250_omap: Fix PM regression with deferred probe for
    pm_runtime_reinit
  serial: omap: Fix PM regression with deferred probe for
    pm_runtime_reinit
  ARM: OMAP2+: Improve omap_device error for driver writers
  ARM: OMAP2+: Fix omap_device for module reload on PM runtime forbid

 arch/arm/mach-omap2/omap_device.c   | 14 +++++++++++++-
 drivers/i2c/busses/i2c-omap.c       |  4 +++-
 drivers/mmc/host/omap_hsmmc.c       |  6 ++++--
 drivers/spi/spi-omap2-mcspi.c       |  3 +++
 drivers/tty/serial/8250/8250_omap.c |  4 +++-
 drivers/tty/serial/omap-serial.c    |  4 +++-
 6 files changed, 29 insertions(+), 6 deletions(-)

-- 
2.7.0



From tony at atomide.com  Wed Feb 10 15:02:45 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Feb 2016 15:02:45 -0800
Subject: [PATCH 2/7] i2c: omap: Fix PM regression with deferred probe for
 pm_runtime_reinit
In-Reply-To: <1455145370-20301-1-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
Message-ID: <1455145370-20301-3-git-send-email-tony@atomide.com>

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-i2c at vger.kernel.org
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Kevin Hilman <khilman at baylibre.com>
Cc: Nishanth Menon <nm at ti.com>
Cc: Rafael J. Wysocki <rafael at kernel.org>
Cc: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Tero Kristo <t-kristo at ti.com>
Cc: Wolfram Sang <wsa at the-dreams.de>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---

Wolfram, I'd like to merge this along with other related fixes via
the ARM SoC tree if no objections, please review and ack if this
look OK to you.


---

 drivers/i2c/busses/i2c-omap.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 08d26ba..13c4529 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1450,7 +1450,8 @@ omap_i2c_probe(struct platform_device *pdev)
 
 err_unuse_clocks:
 	omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
-	pm_runtime_put(omap->dev);
+	pm_runtime_dont_use_autosuspend(omap->dev);
+	pm_runtime_put_sync(omap->dev);
 	pm_runtime_disable(&pdev->dev);
 err_free_mem:
 
@@ -1468,6 +1469,7 @@ static int omap_i2c_remove(struct platform_device *pdev)
 		return ret;
 
 	omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
 	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	return 0;
-- 
2.7.0



From tony at atomide.com  Wed Feb 10 15:02:46 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Feb 2016 15:02:46 -0800
Subject: [PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred probe
 for pm_runtime_reinit
In-Reply-To: <1455145370-20301-1-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
Message-ID: <1455145370-20301-4-git-send-email-tony@atomide.com>

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-spi at vger.kernel.org
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Kevin Hilman <khilman at baylibre.com>
Cc: Mark Brown <broonie at kernel.org>
Cc: Nishanth Menon <nm at ti.com>
Cc: Rafael J. Wysocki <rafael at kernel.org>
Cc: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Tero Kristo <t-kristo at ti.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---

Mark, I'd like to merge this along with other related fixes via
the ARM SoC tree if no objections, please review and ack if this
look OK to you.


---
 drivers/spi/spi-omap2-mcspi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 7273820..0caa3c8 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1490,6 +1490,8 @@ static int omap2_mcspi_probe(struct platform_device *pdev)
 	return status;
 
 disable_pm:
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
+	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 free_master:
 	spi_master_put(master);
@@ -1501,6 +1503,7 @@ static int omap2_mcspi_remove(struct platform_device *pdev)
 	struct spi_master *master = platform_get_drvdata(pdev);
 	struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
 
+	pm_runtime_dont_use_autosuspend(mcspi->dev);
 	pm_runtime_put_sync(mcspi->dev);
 	pm_runtime_disable(&pdev->dev);
 
-- 
2.7.0



From tony at atomide.com  Wed Feb 10 15:02:47 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Feb 2016 15:02:47 -0800
Subject: [PATCH 4/7] serial: 8250_omap: Fix PM regression with deferred probe
 for pm_runtime_reinit
In-Reply-To: <1455145370-20301-1-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
Message-ID: <1455145370-20301-5-git-send-email-tony@atomide.com>

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-serial at vger.kernel.org
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Kevin Hilman <khilman at baylibre.com>
Cc: Nishanth Menon <nm at ti.com>
Cc: Peter Hurley <peter at hurleysoftware.com>
Cc: Rafael J. Wysocki <rafael at kernel.org>
Cc: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Tero Kristo <t-kristo at ti.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---

Greg & Peter, I'd like to merge this along with other related fixes
via the ARM SoC tree if no objections, please review and ack if this
look OK to you.

---
 drivers/tty/serial/8250/8250_omap.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index a2c0734..81ff337 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1235,7 +1235,8 @@ static int omap8250_probe(struct platform_device *pdev)
 	pm_runtime_put_autosuspend(&pdev->dev);
 	return 0;
 err:
-	pm_runtime_put(&pdev->dev);
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
+	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	return ret;
 }
@@ -1244,6 +1245,7 @@ static int omap8250_remove(struct platform_device *pdev)
 {
 	struct omap8250_priv *priv = platform_get_drvdata(pdev);
 
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
 	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	serial8250_unregister_port(priv->line);
-- 
2.7.0



From tony at atomide.com  Wed Feb 10 15:02:44 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Feb 2016 15:02:44 -0800
Subject: [PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe
 for pm_runtime_reinit
In-Reply-To: <1455145370-20301-1-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
Message-ID: <1455145370-20301-2-git-send-email-tony@atomide.com>

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-mmc at vger.kernel.org
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Kevin Hilman <khilman at baylibre.com>
Cc: Nishanth Menon <nm at ti.com>
Cc: Rafael J. Wysocki <rafael at kernel.org>
Cc: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Tero Kristo <t-kristo at ti.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---

Ulf, I'd like to merge this along with other related fixes via the
ARM SoC tree if no objections, please review and ack if this look OK
to you.

---
 drivers/mmc/host/omap_hsmmc.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b6639ea..32bc112 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1247,7 +1247,7 @@ static int omap_hsmmc_switch_opcond(struct omap_hsmmc_host *host, int vdd)
 	int ret;
 
 	/* Disable the clocks */
-	pm_runtime_put_sync(host->dev);
+	pm_runtime_put_sync_suspend(host->dev);
 	if (host->dbclk)
 		clk_disable_unprepare(host->dbclk);
 
@@ -2232,6 +2232,7 @@ err_irq:
 		dma_release_channel(host->tx_chan);
 	if (host->rx_chan)
 		dma_release_channel(host->rx_chan);
+	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);
 	if (host->dbclk)
@@ -2253,6 +2254,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
 	dma_release_channel(host->tx_chan);
 	dma_release_channel(host->rx_chan);
 
+	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);
 	device_init_wakeup(&pdev->dev, false);
@@ -2285,7 +2287,7 @@ static int omap_hsmmc_suspend(struct device *dev)
 	if (host->dbclk)
 		clk_disable_unprepare(host->dbclk);
 
-	pm_runtime_put_sync(host->dev);
+	pm_runtime_put_sync_suspend(host->dev);
 	return 0;
 }
 
-- 
2.7.0



From tony at atomide.com  Wed Feb 10 15:02:48 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Feb 2016 15:02:48 -0800
Subject: [PATCH 5/7] serial: omap: Fix PM regression with deferred probe for
 pm_runtime_reinit
In-Reply-To: <1455145370-20301-1-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
Message-ID: <1455145370-20301-6-git-send-email-tony@atomide.com>

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-serial at vger.kernel.org
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
Cc: Kevin Hilman <khilman at baylibre.com>
Cc: Nishanth Menon <nm at ti.com>
Cc: Rafael J. Wysocki <rafael at kernel.org>
Cc: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Tero Kristo <t-kristo at ti.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---

Greg & Peter, I'd like to merge this along with other related fixes
via the ARM SoC tree if no objections, please review and ack if
this look OK to you.

---
 drivers/tty/serial/omap-serial.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index b645f92..5c43f75 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1708,7 +1708,8 @@ static int serial_omap_probe(struct platform_device *pdev)
 	return 0;
 
 err_add_port:
-	pm_runtime_put(&pdev->dev);
+	pm_runtime_dont_use_autosuspend(&pdev->dev);
+	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	pm_qos_remove_request(&up->pm_qos_request);
 	device_init_wakeup(up->dev, false);
@@ -1721,6 +1722,7 @@ static int serial_omap_remove(struct platform_device *dev)
 {
 	struct uart_omap_port *up = platform_get_drvdata(dev);
 
+	pm_runtime_dont_use_autosuspend(up->dev);
 	pm_runtime_put_sync(up->dev);
 	pm_runtime_disable(up->dev);
 	uart_remove_one_port(&serial_omap_reg, &up->port);
-- 
2.7.0



From tony at atomide.com  Wed Feb 10 15:02:50 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Feb 2016 15:02:50 -0800
Subject: [PATCH 7/7] ARM: OMAP2+: Fix omap_device for module reload on PM
 runtime forbid
In-Reply-To: <1455145370-20301-1-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
Message-ID: <1455145370-20301-8-git-send-email-tony@atomide.com>

If a driver PM runtime is disabled via sysfs, and the module is
unloaded, PM runtime can't do anything to disable the device. Let's
let the interconnect disable the device on BUS_NOTIFY_UNBOUND_DRIVER.

Otherwise omap_device will produce and error on the following module
reload. This can be easily tested with something like:

# modprobe omap_hsmmc
# echo on > /sys/devices/platform/68000000.ocp/4809c000.mmc/power/control
# rmmod omap_hsmmc
# modprobe omap_hsmmc

Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Kevin Hilman <khilman at baylibre.com>
Cc: Nishanth Menon <nm at ti.com>
Cc: Rafael J. Wysocki <rafael at kernel.org>
Cc: Tero Kristo <t-kristo at ti.com>
Reported-by: Ulf Hansson <ulf.hansson at linaro.org>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/mach-omap2/omap_device.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index ebd8369..f7ff3b9 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -191,12 +191,22 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
 {
 	struct platform_device *pdev = to_platform_device(dev);
 	struct omap_device *od;
+	int err;
 
 	switch (event) {
 	case BUS_NOTIFY_DEL_DEVICE:
 		if (pdev->archdata.od)
 			omap_device_delete(pdev->archdata.od);
 		break;
+	case BUS_NOTIFY_UNBOUND_DRIVER:
+		od = to_omap_device(pdev);
+		if (od && (od->_state == OMAP_DEVICE_STATE_ENABLED)) {
+			dev_info(dev, "enabled after unload, idling\n");
+			err = omap_device_idle(pdev);
+			if (err)
+				dev_err(dev, "failed to idle\n");
+		}
+		break;
 	case BUS_NOTIFY_ADD_DEVICE:
 		if (pdev->dev.of_node)
 			omap_device_build_from_dt(pdev);
-- 
2.7.0



From tony at atomide.com  Wed Feb 10 15:02:49 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Feb 2016 15:02:49 -0800
Subject: [PATCH 6/7] ARM: OMAP2+: Improve omap_device error for driver writers
In-Reply-To: <1455145370-20301-1-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
Message-ID: <1455145370-20301-7-git-send-email-tony@atomide.com>

Drivers using pm_runtime_use_autosuspend() may not get disabled after
-EPROBE_DEFER. On the following device driver probe, hardware state
is different from the PM runtime state causing omap_device to produce
the following error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

Let's add a proper error message so driver writers can easily fix
their drivers for PM.

In general, the solution is to fix the drivers to follow the PM
runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Let's not return with 0 from _od_runtime_resume() as that will
eventually lead into new drivers with broken PM runtime that will
block deeper idle states on omaps.

Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Kevin Hilman <khilman at baylibre.com>
Cc: Nishanth Menon <nm at ti.com>
Cc: Rafael J. Wysocki <rafael at kernel.org>
Cc: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Tero Kristo <t-kristo at ti.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/mach-omap2/omap_device.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 0437537..ebd8369 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -602,8 +602,10 @@ static int _od_runtime_resume(struct device *dev)
 	int ret;
 
 	ret = omap_device_enable(pdev);
-	if (ret)
+	if (ret) {
+		dev_err(dev, "use pm_runtime_put_sync_suspend() in driver?\n");
 		return ret;
+	}
 
 	return pm_generic_runtime_resume(dev);
 }
-- 
2.7.0



From martin at sperl.org  Wed Feb 10 15:19:39 2016
From: martin at sperl.org (Martin Sperl)
Date: Thu, 11 Feb 2016 00:19:39 +0100
Subject: [PATCH 3/4] spi: bcm2835aux: set up spi-mode before asserting
 cs-gpio
In-Reply-To: <2743238.b2UJKq0efN@chaos-desktop>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <878u2s2xym.fsf@eliezer.anholt.net> <20160210190204.GD13270@sirena.org.uk>
 <2743238.b2UJKq0efN@chaos-desktop>
Message-ID: <7B5ED5ED-EF09-4D44-8989-1BBCD7C01463@sperl.org>


> On 10.02.2016, at 21:26, Stephan Olbrich <stephanolbrich at gmx.de> wrote:
> 
> Am Wednesday 10 February 2016, 19:02:04 schrieb Mark Brown:
>> On Wed, Feb 10, 2016 at 10:59:29AM -0800, Eric Anholt wrote:
>>> Oops, this makes more sense now.  Subject even mentioned gpio, and a
>>> GPIO CS must be getting set around the transfer_one call.  I'll be ready
>>> to send an r-b for a v2 with the speed update bug fixed (unless transfer
>>> speeds are guaranteed to be constant between a prepare and unprepare).
>> 
>> No guarantee that they'll not change, especially in a situation where we
>> have two devices on different speeds on a bus working at the same time.
> Are you saying, that between a prepare and unprepare there could be transfers 
> for another device? Then all the clock setting couldn't be done in prepare 
> either.
> Apart from that, if two transfers in the same message are not guarantied to 
> have the same speed, this still needs to be fixed. I'll roll a v2.

Prepare/unprepare is always called when processing an spi message.
there is never a phase where two spi_messages are prepared concurrently
for the same spi bus.

See the implementation of __spi_pump_messages

The sequence for processing is:
* master->prepare_hardware
* master->prepare_message
* spi_map_message
* master->transfer_one_message
  * spi_set_cs(true)
  at end of message:
  * spi_finalize_current_message
    * spi_set_cs(false)
    * master->unprepare_message 

So the use of prepare_message in this context is valid.

Otherwise we would need to add an additional method to setup
polarity/cs prior to spi_set_cs(true).

Ciao,
	Martin

From linux at baker-net.org.uk  Wed Feb 10 15:33:41 2016
From: linux at baker-net.org.uk (Adam Baker)
Date: Wed, 10 Feb 2016 23:33:41 +0000
Subject: [PATCH 0/3] ARM: mvebu: Add driver for the Zyxel NSA3XX hwmon MCU
Message-ID: <1455147224-6742-1-git-send-email-linux@baker-net.org.uk>

This patch series adds a driver to support the hardware monitoring MCU
that is present in some models of the Zyxel NSA3xx series of NAS units.

A patch is included to add it to the device tree for the NSA320 model,
patches to the other device trees will be included if testers come
forward (I already have a possible tester for NSA325).

There are no dependencies between the patches so I guess the first two
should go via the hardware monitoring maintainers and the third via
the ARM mvebu maintainers.

 [PATCH 1/3] Define a binding for the hardware monitoring chip present
 [PATCH 2/3] Create a driver to support the hardware monitoring chip
 [PATCH 3/3] Add an entry for the hardware monitoring MCU

 Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt |  21 ++++++++
 arch/arm/boot/dts/kirkwood-nsa320.dts                  |  13 ++++-
 drivers/hwmon/Kconfig                                  |  13 +++++
 drivers/hwmon/Makefile                                 |   1 +
 drivers/hwmon/nsa3xx-hwmon.c                           | 223 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 269 insertions(+), 2 deletions(-)


From linux at baker-net.org.uk  Wed Feb 10 15:33:44 2016
From: linux at baker-net.org.uk (Adam Baker)
Date: Wed, 10 Feb 2016 23:33:44 +0000
Subject: [PATCH 3/3] ARM: mvebu: Add the hardware monitor to the NSA320 device
 tree
In-Reply-To: <1455147224-6742-1-git-send-email-linux@baker-net.org.uk>
References: <1455147224-6742-1-git-send-email-linux@baker-net.org.uk>
Message-ID: <1455147224-6742-4-git-send-email-linux@baker-net.org.uk>

Add an entry for the hardware monitoring MCU

Signed-off-by: Adam Baker <linux at baker-net.org.uk>
---
 arch/arm/boot/dts/kirkwood-nsa320.dts | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-nsa320.dts b/arch/arm/boot/dts/kirkwood-nsa320.dts
index 24f686d..2a935e9 100644
--- a/arch/arm/boot/dts/kirkwood-nsa320.dts
+++ b/arch/arm/boot/dts/kirkwood-nsa320.dts
@@ -193,10 +193,19 @@
 		};
 	};
 
+	hwmon {
+		compatible = "zyxel,nsa320-mcu";
+		pinctrl-0 = <&pmx_mcu_data &pmx_mcu_clk &pmx_mcu_act>;
+		pinctrl-names = "default";
+
+		data-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+		clk-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
+		act-gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
+	};
+
 	/* The following pins are currently not assigned to a driver,
 	   some of them should be configured as inputs.
-	pinctrl-0 = <&pmx_mcu_data &pmx_mcu_clk &pmx_mcu_act
-		     &pmx_htp &pmx_vid_b1
+	pinctrl-0 = <&pmx_htp &pmx_vid_b1
 		     &pmx_power_resume_data &pmx_power_resume_clk>; */
 };
 
-- 
2.1.4



From linux at baker-net.org.uk  Wed Feb 10 15:33:42 2016
From: linux at baker-net.org.uk (Adam Baker)
Date: Wed, 10 Feb 2016 23:33:42 +0000
Subject: [PATCH 1/3] ARM: mvebu: Define binding for the nsa3xx-hwmon driver
In-Reply-To: <1455147224-6742-1-git-send-email-linux@baker-net.org.uk>
References: <1455147224-6742-1-git-send-email-linux@baker-net.org.uk>
Message-ID: <1455147224-6742-2-git-send-email-linux@baker-net.org.uk>

Define a binding for the hardware monitoring chip present in several
variants of the Zyxel NSA3xx NAS devices.

Signed-off-by: Adam Baker <linux at baker-net.org.uk>
---
 .../devicetree/bindings/hwmon/nsa320-mcu.txt        | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt

diff --git a/Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt b/Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt
new file mode 100644
index 0000000..7b346d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt
@@ -0,0 +1,21 @@
+Bindings for the fan / temperature monitor microcontroller used on
+the Zyxel NSA 320 and several subsequent models.
+
+Required properties:
+- compatible	: "zyxel,nsa320-mcu"
+- data-gpios	: The GPIO pin connected to the data line on the MCU
+- clk-gpios	: The GPIO pin connected to the clock line on the MCU
+- act-gpios	: The GPIO pin connected to the active line on the MCU
+
+Example:
+
+	hwmon {
+		compatible = "zyxel,nsa320-mcu";
+		pinctrl-0 = <&pmx_mcu_data &pmx_mcu_clk &pmx_mcu_act>;
+		pinctrl-names = "default";
+
+		data-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+		clk-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
+		act-gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
+	};
+
-- 
2.1.4



From linux at baker-net.org.uk  Wed Feb 10 15:33:43 2016
From: linux at baker-net.org.uk (Adam Baker)
Date: Wed, 10 Feb 2016 23:33:43 +0000
Subject: [PATCH 2/3] ARM: mvebu: Create a NSA3xx hardware monitoring driver
In-Reply-To: <1455147224-6742-1-git-send-email-linux@baker-net.org.uk>
References: <1455147224-6742-1-git-send-email-linux@baker-net.org.uk>
Message-ID: <1455147224-6742-3-git-send-email-linux@baker-net.org.uk>

Create a driver to support the hardware monitoring chip present in
several models of Zyxel NSA3xx NAS devices.

The driver reads fan speed and temperature from a suitably programmed
MCU on the device.

Signed-off-by: Adam Baker <linux at baker-net.org.uk>
---
I've tested this on an NSA-320, I've had someone offer to test it on
NSA-325 so hopefully I will get a tested by back.
---
 drivers/hwmon/Kconfig        |  13 +++
 drivers/hwmon/Makefile       |   1 +
 drivers/hwmon/nsa3xx-hwmon.c | 223 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 237 insertions(+)
 create mode 100644 drivers/hwmon/nsa3xx-hwmon.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 80a73bf..8801b78 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1757,6 +1757,19 @@ config SENSORS_ULTRA45
 	  This driver provides support for the Ultra45 workstation environmental
 	  sensors.
 
+config SENSORS_NSA3XX
+	tristate "ZyXEL NSA3xx fan speed and temperature sensors"
+	depends on GPIOLIB && OF
+	help
+	  If you say yes here you get support for hardware monitoring
+	  for the ZyXEL NSA3XX Media Servers.
+
+	  The sensor data is taken from a Holtek HT46R065 microcontroller
+	  connected to GPIO lines.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called nsa3xx-hwmon.
+
 if ACPI
 
 comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 12a3239..e85414a 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -118,6 +118,7 @@ obj-$(CONFIG_SENSORS_MAX6650)	+= max6650.o
 obj-$(CONFIG_SENSORS_MAX6697)	+= max6697.o
 obj-$(CONFIG_SENSORS_MAX31790)	+= max31790.o
 obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
+obj-$(CONFIG_SENSORS_NSA3XX)	+= nsa3xx-hwmon.o
 obj-$(CONFIG_SENSORS_MCP3021)	+= mcp3021.o
 obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o
 obj-$(CONFIG_SENSORS_NCT6683)	+= nct6683.o
diff --git a/drivers/hwmon/nsa3xx-hwmon.c b/drivers/hwmon/nsa3xx-hwmon.c
new file mode 100644
index 0000000..0fbf118
--- /dev/null
+++ b/drivers/hwmon/nsa3xx-hwmon.c
@@ -0,0 +1,223 @@
+/*
+ * drivers/hwmon/nsa3xx-hwmon.c
+ *
+ * ZyXEL NSA3xx Media Servers
+ * hardware monitoring
+ *
+ * Copyright (C) 2016 Adam Baker <linux at baker-net.org.uk>
+ * based on a board file driver
+ * Copyright (C) 2012 Peter Schildmann <linux at schildmann.info>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License v2 as published by the
+ * Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/jiffies.h>
+#include <linux/delay.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+
+#define MAGIC_NUMBER 0x55
+
+/*
+ * The Zyxel hwmon MCU is a Holtek HT46R065 that is factory programmed
+ * to perform temperature and fan speed monitoring. It is read by taking
+ * the active pin low. The 32 bit output word is then clocked onto the
+ * data line. The MSB of the data word is a magic nuber to indicate it
+ * has been read correctly, the next byte is the fan speed (in hundreds
+ * of RPM) and the last two bytes are the temperature (in tenths of a
+ * degree)
+ */
+
+struct nsa3xx_hwmon {
+	struct device		*classdev;
+	struct mutex		update_lock;	/* lock GPIO operations */
+	unsigned long		last_updated;	/* jiffies */
+	u32			mcu_data;
+	struct gpio_desc	*act;
+	struct gpio_desc	*clk;
+	struct gpio_desc	*data;
+};
+
+enum nsa3xx_inputs {
+	NSA3XX_FAN = 1,
+	NSA3XX_TEMP = 0,
+};
+
+static const char * const nsa3xx_input_names[] = {
+	[NSA3XX_FAN] = "Chassis Fan",
+	[NSA3XX_TEMP] = "System Temperature",
+};
+
+/* Although this protocol looks similar to SPI the long delay
+ * between the active (aka chip select) signal and the shorter
+ * delay between clock pulses are needed for reliable operation.
+ * The delays provided are taken from the manufacturer kernel,
+ * testing suggest they probably incorporate a reasonable safety
+ * margin. (The single device tested became unreliable if the
+ * delay was reduced to 1/10th of this value.)
+ */
+static unsigned long nsa3xx_hwmon_update(struct device *dev)
+{
+	u32 mcu_data;
+	u32 mask;
+	struct nsa3xx_hwmon *hwmon = dev_get_drvdata(dev);
+
+	mutex_lock(&hwmon->update_lock);
+
+	mcu_data = hwmon->mcu_data;
+
+	if (time_after(jiffies, hwmon->last_updated + HZ) ||
+							mcu_data == 0) {
+
+		gpiod_set_value(hwmon->act, 1);
+		msleep(100);
+
+		for (mask = BIT(31); mask; mask >>= 1) {
+			gpiod_set_value(hwmon->clk, 0);
+			usleep_range(100, 200);
+			gpiod_set_value(hwmon->clk, 1);
+			usleep_range(100, 200);
+			if (gpiod_get_value(hwmon->data))
+				mcu_data |= mask;
+		}
+
+		gpiod_set_value(hwmon->act, 0);
+		dev_dbg(dev, "Read raw MCU data %08x\n", mcu_data);
+
+		if ((mcu_data >> 24) != MAGIC_NUMBER) {
+			dev_err(dev, "Read invalid MCU data %08x\n", mcu_data);
+			mcu_data = 0;
+		}
+
+		hwmon->mcu_data = mcu_data;
+		hwmon->last_updated = jiffies;
+	}
+
+	mutex_unlock(&hwmon->update_lock);
+
+	return mcu_data;
+}
+
+static ssize_t show_label(struct device *dev,
+			  struct device_attribute *attr, char *buf)
+{
+	int channel = to_sensor_dev_attr(attr)->index;
+
+	return sprintf(buf, "%s\n", nsa3xx_input_names[channel]);
+}
+
+static ssize_t show_value(struct device *dev,
+			  struct device_attribute *attr, char *buf)
+{
+	int channel = to_sensor_dev_attr(attr)->index;
+	unsigned long mcu_data = nsa3xx_hwmon_update(dev);
+	unsigned long value = 0;
+
+	pr_debug("channel value 0x%02x!\n", channel);
+	switch (channel) {
+	case NSA3XX_TEMP:
+		value = (mcu_data & 0xffff) * 100;
+		break;
+	case NSA3XX_FAN:
+		value = ((mcu_data & 0xff0000) >> 16) * 100;
+		break;
+	}
+	return sprintf(buf, "%lu\n", value);
+}
+
+static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, show_label, NULL, NSA3XX_TEMP);
+static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_value, NULL, NSA3XX_TEMP);
+static SENSOR_DEVICE_ATTR(fan1_label, S_IRUGO, show_label, NULL, NSA3XX_FAN);
+static SENSOR_DEVICE_ATTR(fan1_input, S_IRUGO, show_value, NULL, NSA3XX_FAN);
+
+static struct attribute *nsa3xx_attrs[] = {
+	&sensor_dev_attr_temp1_label.dev_attr.attr,
+	&sensor_dev_attr_temp1_input.dev_attr.attr,
+	&sensor_dev_attr_fan1_label.dev_attr.attr,
+	&sensor_dev_attr_fan1_input.dev_attr.attr,
+	NULL
+};
+
+ATTRIBUTE_GROUPS(nsa3xx);
+
+static const struct of_device_id of_nsa3xx_hwmon_match[] = {
+	{ .compatible = "zyxel,nsa320-mcu", },
+	{ },
+};
+
+static int nsa3xx_hwmon_probe(struct platform_device *pdev)
+{
+	struct nsa3xx_hwmon *hwmon;
+
+	hwmon = devm_kzalloc(&pdev->dev, sizeof(*hwmon), GFP_KERNEL);
+	if (!hwmon)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, hwmon);
+
+	/* Look up the GPIO pins to use */
+	hwmon->act = devm_gpiod_get(&pdev->dev, "act", GPIOD_OUT_LOW);
+	hwmon->clk = devm_gpiod_get(&pdev->dev, "clk", GPIOD_OUT_HIGH);
+	hwmon->data = devm_gpiod_get(&pdev->dev, "data", GPIOD_IN);
+
+	if (IS_ERR(hwmon->act))
+		return PTR_ERR(hwmon->act);
+	if (IS_ERR(hwmon->clk))
+		return PTR_ERR(hwmon->clk);
+	if (IS_ERR(hwmon->data))
+		return PTR_ERR(hwmon->data);
+
+	mutex_init(&hwmon->update_lock);
+
+	hwmon->classdev = devm_hwmon_device_register_with_groups(&pdev->dev,
+					"nsa3xx", hwmon, nsa3xx_groups);
+	if (IS_ERR(hwmon->classdev))
+		return PTR_ERR(hwmon->classdev);
+
+	dev_dbg(&pdev->dev, "initialized\n");
+
+	return 0;
+}
+
+static int nsa3xx_hwmon_remove(struct platform_device *pdev)
+{
+	/* All resources are allocated with devm_*() so
+	 * there is nothing to do here.
+	 */
+
+	return 0;
+}
+
+static struct platform_driver nsa3xx_hwmon_driver = {
+	.probe = nsa3xx_hwmon_probe,
+	.remove = nsa3xx_hwmon_remove,
+	.driver = {
+		.name = "nsa3xx-hwmon",
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(of_nsa3xx_hwmon_match),
+	},
+};
+
+module_platform_driver(nsa3xx_hwmon_driver);
+
+MODULE_DEVICE_TABLE(of, of_nsa3xx_hwmon_match);
+MODULE_AUTHOR("Peter Schildmann <linux at schildmann.info>");
+MODULE_AUTHOR("Adam Baker <linux at baker-net.org.uk>");
+MODULE_DESCRIPTION("NSA3XX Hardware Monitoring");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:nsa3xx-hwmon");
-- 
2.1.4



From ahs3 at redhat.com  Wed Feb 10 15:39:27 2016
From: ahs3 at redhat.com (Al Stone)
Date: Wed, 10 Feb 2016 16:39:27 -0700
Subject: [PATCH 0/3] ACPI: parse the SPCR table
In-Reply-To: <56A8B570.2060501@linaro.org>
References: <1453722324-22407-1-git-send-email-aleksey.makarov@linaro.org>
 <56A6494E.3090303@hurleysoftware.com> <56A8B570.2060501@linaro.org>
Message-ID: <56BBCA2F.3020604@redhat.com>

On 01/27/2016 05:17 AM, Aleksey Makarov wrote:
> 
> 
> On 01/25/2016 07:11 PM, Peter Hurley wrote:
>> On 01/25/2016 03:45 AM, Aleksey Makarov wrote:
>>> This patchset is based on the patchset by Leif Lindholm [1]
>>>
>>> 'ARM Server Base Boot Requirements' [2] mention SPCR 
>>> (Serial Port Console Redirection Table) [3] as a mandatory
>>> ACPI table that specifies the configuration of serial console.
>>>
>>> Licensing concerns have prevented implementing it in the past, but as of
>>> 10 August 2015, these tables have both been released also under 
>>> OWF 1.0 [4].
>>
>> This license has a patent retaliation provision, which makes it
>> incompatible with GPLv2.
>>
>> *If the license applies to this code*, then this patch set does not
>> meet the criteria for submission.
> 
> The license applies not to this code but to the document describing the tables.

Just for the record, the SPCR table struct definition has been part
of the Linux kernel since at least commit b24aad44 on 2009-07-24
(line 1112 of include/acpi/actbl2.h) -- or so git blame tells me.

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3 at redhat.com
-----------------------------------


From laurent.pinchart at ideasonboard.com  Wed Feb 10 16:02:11 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 11 Feb 2016 02:02:11 +0200
Subject: [PATCH v3 1/8] iommu: Add MMIO mapping type
In-Reply-To: <1455065878-11906-2-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <1455065878-11906-2-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <13740597.5lZXKsEG19@avalon>

Hi Niklas,

Thank you for the patch.

On Wednesday 10 February 2016 01:57:51 Niklas S?derlund wrote:
> From: Robin Murphy <robin.murphy at arm.com>
> 
> On some platforms, MMIO regions might need slightly different treatment
> compared to mapping regular memory; add the notion of MMIO mappings to
> the IOMMU API's memory type flags, so that callers can let the IOMMU
> drivers know to do the right thing.
> 
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

Answering the question from the cover letter, yes, it's totally fine to pick 
the ack, that's actually expected.

> ---
>  drivers/iommu/io-pgtable-arm.c | 4 +++-
>  include/linux/iommu.h          | 1 +

You might be asked to split this patch in two.

>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 381ca5a..3ff4f87 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -364,7 +364,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
> arm_lpae_io_pgtable *data, pte |= ARM_LPAE_PTE_HAP_READ;
>  		if (prot & IOMMU_WRITE)
>  			pte |= ARM_LPAE_PTE_HAP_WRITE;
> -		if (prot & IOMMU_CACHE)
> +		if (prot & IOMMU_MMIO)
> +			pte |= ARM_LPAE_PTE_MEMATTR_DEV;
> +		else if (prot & IOMMU_CACHE)
>  			pte |= ARM_LPAE_PTE_MEMATTR_OIWB;
>  		else
>  			pte |= ARM_LPAE_PTE_MEMATTR_NC;
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index a5c539f..34b6432 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -30,6 +30,7 @@
>  #define IOMMU_WRITE	(1 << 1)
>  #define IOMMU_CACHE	(1 << 2) /* DMA cache coherency */
>  #define IOMMU_NOEXEC	(1 << 3)
> +#define IOMMU_MMIO	(1 << 4) /* e.g. things like MSI doorbells */
> 
>  struct iommu_ops;
>  struct iommu_group;

-- 
Regards,

Laurent Pinchart



From stefan at agner.ch  Wed Feb 10 16:02:26 2016
From: stefan at agner.ch (Stefan Agner)
Date: Wed, 10 Feb 2016 16:02:26 -0800
Subject: [PATCH 2/2] ARM: dts: vf-colibri: assign Ethernet clock explicitly
In-Reply-To: <1455148946-26903-1-git-send-email-stefan@agner.ch>
References: <1455148946-26903-1-git-send-email-stefan@agner.ch>
Message-ID: <1455148946-26903-2-git-send-email-stefan@agner.ch>

Assign Ethernet clock parents explicitly. The Colibri VF61
uses the 50MHz Ethernet clock provided by PLL5.

The Vybrid SoC has two ethernet interfaces (fec0 and fec1) which
use the same clock source (VF610_CLK_ENET). Therefore this parent
configuration affects multiple consumer devices and need to be
specified in the clock provider node.

Signed-off-by: Stefan Agner <stefan at agner.ch>
---
 arch/arm/boot/dts/vf-colibri.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi b/arch/arm/boot/dts/vf-colibri.dtsi
index c4312c4..8a889af 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -38,6 +38,13 @@
 	status = "disabled";
 };
 
+&clks {
+	assigned-clocks = <&clks VF610_CLK_ENET_SEL>,
+			  <&clks VF610_CLK_ENET_TS_SEL>;
+	assigned-clock-parents = <&clks VF610_CLK_ENET_50M>,
+				 <&clks VF610_CLK_ENET_50M>;
+};
+
 &dspi1 {
 	bus-num = <1>;
 	pinctrl-names = "default";
-- 
2.7.1



From stefan at agner.ch  Wed Feb 10 16:02:25 2016
From: stefan at agner.ch (Stefan Agner)
Date: Wed, 10 Feb 2016 16:02:25 -0800
Subject: [PATCH 1/2] ARM: dts: vf610twr: assign Ethernet clock explicitly
Message-ID: <1455148946-26903-1-git-send-email-stefan@agner.ch>

Assign Ethernet clock parents explicitly. The VF610 Tower Board
uses the external Ethernet clock input which is connected to
a 50MHz clock.

The Vybrid SoC has two ethernet interfaces (fec0 and fec1) which
use the same clock source (VF610_CLK_ENET). Therefore this parent
configuration affects multiple consumer devices and need to be
specified in the clock provider node.

Signed-off-by: Stefan Agner <stefan at agner.ch>
---
So far we rely on the boot loader to configure this, however it
can be problematic e.g. for suspend/resume...

--
Stefan

 arch/arm/boot/dts/vf610-twr.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 5438ee4..8419c06 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -96,6 +96,10 @@
 &clks {
 	clocks = <&sxosc>, <&fxosc>, <&enet_ext>, <&audio_ext>;
 	clock-names = "sxosc", "fxosc", "enet_ext", "audio_ext";
+	assigned-clocks = <&clks VF610_CLK_ENET_SEL>,
+			  <&clks VF610_CLK_ENET_TS_SEL>;
+	assigned-clock-parents = <&clks VF610_CLK_ENET_EXT>,
+				 <&clks VF610_CLK_ENET_EXT>;
 };
 
 &dspi0 {
-- 
2.7.1



From laurent.pinchart at ideasonboard.com  Wed Feb 10 16:03:40 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 11 Feb 2016 02:03:40 +0200
Subject: [PATCH v3 2/8] dma-mapping: add {map,
 unmap}_resource to dma_map_ops
In-Reply-To: <1455065878-11906-3-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <1455065878-11906-3-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1751306.gvBkWbovht@avalon>

Hi Niklas,

Thank you for the patch.

On Wednesday 10 February 2016 01:57:52 Niklas S?derlund wrote:
> Add methods to handle mapping of device resources from a physical
> address. This is needed for example to map be able to map MMIO FIFO
> registers to a IOMMU.
> 
> Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>

Apart from the typo in the commit message that Sergei already pointed out,

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> ---
>  include/linux/dma-mapping.h | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 75857cd..e3aba4e 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -49,6 +49,12 @@ struct dma_map_ops {
>  			 struct scatterlist *sg, int nents,
>  			 enum dma_data_direction dir,
>  			 struct dma_attrs *attrs);
> +	dma_addr_t (*map_resource)(struct device *dev, phys_addr_t phys_addr,
> +			       size_t size, enum dma_data_direction dir,
> +			       struct dma_attrs *attrs);
> +	void (*unmap_resource)(struct device *dev, dma_addr_t dma_handle,
> +			   size_t size, enum dma_data_direction dir,
> +			   struct dma_attrs *attrs);
>  	void (*sync_single_for_cpu)(struct device *dev,
>  				    dma_addr_t dma_handle, size_t size,
>  				    enum dma_data_direction dir);

-- 
Regards,

Laurent Pinchart



From laurent.pinchart at ideasonboard.com  Wed Feb 10 16:12:13 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 11 Feb 2016 02:12:13 +0200
Subject: [PATCH v3 4/8] arm: dma-mapping: add {map,
 unmap}_resource for iommu ops
In-Reply-To: <1455065878-11906-5-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <1455065878-11906-5-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <3988595.8dtuaVHoSu@avalon>

Hi Niklas,

Thank you for the patch.

On Wednesday 10 February 2016 01:57:54 Niklas S?derlund wrote:
> Add methods to map/unmap device resources addresses for dma_map_ops that
> are IOMMU aware. This is needed to map a device MMIO register from a
> physical address.
> 
> Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> ---
>  arch/arm/mm/dma-mapping.c | 63 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 63 insertions(+)
> 
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 0eca381..ae2b175 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1814,6 +1814,63 @@ static void arm_iommu_unmap_page(struct device *dev,
> dma_addr_t handle, __free_iova(mapping, iova, len);
>  }
> 
> +/**
> + * arm_iommu_map_resource - map a device resource for DMA
> + * @dev: valid struct device pointer
> + * @phys_addr: physical address of resource
> + * @size: size of resource to map
> + * @dir: DMA transfer direction
> + */
> +static dma_addr_t arm_iommu_map_resource(struct device *dev,
> +		phys_addr_t phys_addr, size_t size,
> +		enum dma_data_direction dir, struct dma_attrs *attrs)
> +{
> +	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
> +	dma_addr_t dma_addr;
> +	int ret, prot;
> +	phys_addr_t addr = phys_addr & PAGE_MASK;
> +	int offset = phys_addr & ~PAGE_MASK;
> +	int len = PAGE_ALIGN(size + offset);
> +
> +	dma_addr = __alloc_iova(mapping, size);
> +	if (dma_addr == DMA_ERROR_CODE)
> +		return dma_addr;
> +
> +	prot = __dma_direction_to_prot(dir) | IOMMU_MMIO;
> +
> +	ret = iommu_map(mapping->domain, dma_addr, addr, len, prot);
> +	if (ret < 0)
> +		goto fail;
> +
> +	return dma_addr + offset;
> +fail:
> +	__free_iova(mapping, dma_addr, size);
> +	return DMA_ERROR_CODE;
> +}
> +
> +/**
> + * arm_iommu_unmap_resource - unmap a device DMA resource
> + * @dev: valid struct device pointer
> + * @dma_handle: DMA address to resource
> + * @size: size of resource to map
> + * @dir: DMA transfer direction
> + */
> +static void arm_iommu_unmap_resource(struct device *dev, dma_addr_t
> dma_handle, +		size_t size, enum dma_data_direction dir,
> +		struct dma_attrs *attrs)
> +{
> +	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
> +	dma_addr_t iova = dma_handle & PAGE_MASK;
> +	int offset = dma_handle & ~PAGE_MASK;
> +	int len = PAGE_ALIGN(size + offset);
> +
> +	if (!iova)
> +		return;
> +
> +	iommu_unmap(mapping->domain, iova, len);
> +	__free_iova(mapping, iova, len);
> +}
> +
>  static void arm_iommu_sync_single_for_cpu(struct device *dev,
>  		dma_addr_t handle, size_t size, enum dma_data_direction dir)
>  {
> @@ -1858,6 +1915,9 @@ struct dma_map_ops iommu_ops = {
>  	.sync_sg_for_cpu	= arm_iommu_sync_sg_for_cpu,
>  	.sync_sg_for_device	= arm_iommu_sync_sg_for_device,
> 
> +	.map_resource		= arm_iommu_map_resource,
> +	.unmap_resource		= arm_iommu_unmap_resource,
> +
>  	.set_dma_mask		= arm_dma_set_mask,
>  };
> 
> @@ -1873,6 +1933,9 @@ struct dma_map_ops iommu_coherent_ops = {
>  	.map_sg		= arm_coherent_iommu_map_sg,
>  	.unmap_sg	= arm_coherent_iommu_unmap_sg,
> 
> +	.map_resource	= arm_iommu_map_resource,
> +	.unmap_resource	= arm_iommu_unmap_resource,
> +
>  	.set_dma_mask	= arm_dma_set_mask,
>  };

-- 
Regards,

Laurent Pinchart



From tony at atomide.com  Wed Feb 10 16:12:21 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Feb 2016 16:12:21 -0800
Subject: [PATCH] ARM: OMAP2+: Fix onenand initialization to avoid
 filesystem corruption
In-Reply-To: <20160210211226.GB1640@darkstar.musicnaut.iki.fi>
References: <linux-kernel@vger.kernel.org>
 <1454683028-4193-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
 <20160208193644.GU19432@atomide.com>
 <20160210211226.GB1640@darkstar.musicnaut.iki.fi>
Message-ID: <20160211001220.GM19432@atomide.com>

* Aaro Koskinen <aaro.koskinen at iki.fi> [160210 13:13]:
> Hi,
> 
> On Mon, Feb 08, 2016 at 11:36:45AM -0800, Tony Lindgren wrote:
> > * Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com> [160205 06:38]:
> > > Commit <e7b11dc7b77bfce0a351230a5feeadc1d0bba997> ("ARM: OMAP2+: Fix
> > > onenand rate detection to avoid filesystem corruption") partially fixed
> > > onenand configuration when GPMC module is reset. Finish the job by also
> > > providing the correct values in ONENAND_REG_SYS_CFG1 register.
> > 
> > OK. So probably the INT or RDY polarity made the ECC not work.
> > 
> > Aaro, care to dump out also the nolo configured CFG1 value from
> > n8x0 and n9(50)?
> > 
> > You can do it by adding something like this to the beginning
> > of set_onenand_cfg():
> > 
> > pr_info("CFG1: 0x%04x\n", readw(onenand_base + ONENAND_REG_SYS_CFG1));
> > 
> > And presumably the values are the same as on n900. If not, we
> > should do the legacy file system flash test on all of them
> > before committing this fix.
> 
> I got these (with CONFIG_OMAP_GPMC_DEBUG also enabled):
> 
> N800:
> [    2.803100] CFG1: 0x46c0
> [    3.150115] CFG1: 0x06c0
> 
> N810:
> [    2.802368] CFG1: 0x46c0
> [    3.148620] CFG1: 0x06c0
> 
> N900:
> [    4.965576] CFG1: 0x46c0
> [    5.333740] CFG1: 0x06c0

Thanks, so these all should be fine with Ivaylo's patch.

> N950:
> [    4.217193] CFG1: 0x66c4
> [    4.583221] CFG1: 0x06c0
> 
> N9:
> [    4.212677] CFG1: 0x66c4
> [    4.578613] CFG1: 0x06c0

Aaro, care to do one more test on n9(50) like Ivaylo posted
earlier:

1. Flash original maemo rootfs

2. Boot mainline kernel with Ivaylo's patch and mount onenand

3. Boot original maemo kernel and check dmesg there's no
   file corruption

Also.. There's a chance somebody has created a onenand file system
with recent mainline kernels that did the reset and disabled ECC.
So with Ivaylo's patch fixing that, those may not mount properly
any longer. Most likely people just keep their maemo rootfs there
though with the MMC being available.

Regards,

Tony


From laurent.pinchart at ideasonboard.com  Wed Feb 10 16:14:35 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 11 Feb 2016 02:14:35 +0200
Subject: [PATCH v3 5/8] dmaengine: rcar-dmac: group slave configuration
In-Reply-To: <1455065878-11906-6-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <1455065878-11906-6-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <2394364.dCGqmLNa8V@avalon>

Hi Niklas,

Thank you for the patch.

On Wednesday 10 February 2016 01:57:55 Niklas S?derlund wrote:
> Group slave address and transfer size in own structs for source and
> destination. This is in preparation for hooking up the dma-mapping API
> to the slave addresses.
> 
> Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> ---
>  drivers/dma/sh/rcar-dmac.c | 37 +++++++++++++++++++++----------------
>  1 file changed, 21 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index 7820d07..743873c 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -118,14 +118,21 @@ struct rcar_dmac_desc_page {
>  	sizeof(struct rcar_dmac_xfer_chunk))
> 
>  /*
> + * @slave_addr: slave memory address
> + * @xfer_size: size (in bytes) of hardware transfers
> + */
> +struct rcar_dmac_chan_slave {
> +	dma_addr_t slave_addr;
> +	unsigned int xfer_size;
> +};
> +
> +/*
>   * struct rcar_dmac_chan - R-Car Gen2 DMA Controller Channel
>   * @chan: base DMA channel object
>   * @iomem: channel I/O memory base
>   * @index: index of this channel in the controller
> - * @src_xfer_size: size (in bytes) of hardware transfers on the source side
> - * @dst_xfer_size: size (in bytes) of hardware transfers on the
> destination side - * @src_slave_addr: slave source memory address
> - * @dst_slave_addr: slave destination memory address
> + * @src: slave memory address and size on the source side
> + * @dst: slave memory address and size on the destination side
>   * @mid_rid: hardware MID/RID for the DMA client using this channel
>   * @lock: protects the channel CHCR register and the desc members
>   * @desc.free: list of free descriptors
> @@ -142,10 +149,8 @@ struct rcar_dmac_chan {
>  	void __iomem *iomem;
>  	unsigned int index;
> 
> -	unsigned int src_xfer_size;
> -	unsigned int dst_xfer_size;
> -	dma_addr_t src_slave_addr;
> -	dma_addr_t dst_slave_addr;
> +	struct rcar_dmac_chan_slave src;
> +	struct rcar_dmac_chan_slave dst;
>  	int mid_rid;
> 
>  	spinlock_t lock;
> @@ -793,13 +798,13 @@ static void rcar_dmac_chan_configure_desc(struct
> rcar_dmac_chan *chan, case DMA_DEV_TO_MEM:
>  		chcr = RCAR_DMACHCR_DM_INC | RCAR_DMACHCR_SM_FIXED
> 
>  		     | RCAR_DMACHCR_RS_DMARS;
> 
> -		xfer_size = chan->src_xfer_size;
> +		xfer_size = chan->src.xfer_size;
>  		break;
> 
>  	case DMA_MEM_TO_DEV:
>  		chcr = RCAR_DMACHCR_DM_FIXED | RCAR_DMACHCR_SM_INC
> 
>  		     | RCAR_DMACHCR_RS_DMARS;
> 
> -		xfer_size = chan->dst_xfer_size;
> +		xfer_size = chan->dst.xfer_size;
>  		break;
> 
>  	case DMA_MEM_TO_MEM:
> @@ -1038,7 +1043,7 @@ rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct
> scatterlist *sgl, }
> 
>  	dev_addr = dir == DMA_DEV_TO_MEM
> -		 ? rchan->src_slave_addr : rchan->dst_slave_addr;
> +		 ? rchan->src.slave_addr : rchan->dst.slave_addr;
>  	return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
>  				      dir, flags, false);
>  }
> @@ -1093,7 +1098,7 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan,
> dma_addr_t buf_addr, }
> 
>  	dev_addr = dir == DMA_DEV_TO_MEM
> -		 ? rchan->src_slave_addr : rchan->dst_slave_addr;
> +		 ? rchan->src.slave_addr : rchan->dst.slave_addr;
>  	desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
>  				      dir, flags, true);
> 
> @@ -1110,10 +1115,10 @@ static int rcar_dmac_device_config(struct dma_chan
> *chan, * We could lock this, but you shouldn't be configuring the
>  	 * channel, while using it...
>  	 */
> -	rchan->src_slave_addr = cfg->src_addr;
> -	rchan->dst_slave_addr = cfg->dst_addr;
> -	rchan->src_xfer_size = cfg->src_addr_width;
> -	rchan->dst_xfer_size = cfg->dst_addr_width;
> +	rchan->src.slave_addr = cfg->src_addr;
> +	rchan->dst.slave_addr = cfg->dst_addr;
> +	rchan->src.xfer_size = cfg->src_addr_width;
> +	rchan->dst.xfer_size = cfg->dst_addr_width;
> 
>  	return 0;
>  }

-- 
Regards,

Laurent Pinchart



From tony at atomide.com  Wed Feb 10 16:19:43 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Feb 2016 16:19:43 -0800
Subject: [PATCH v1] ARM: RX51: Set system_rev from ATAGS
In-Reply-To: <1455128582-25669-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
References: <20160209161659.GJ19432@atomide.com>
 <1455128582-25669-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
Message-ID: <20160211001942.GN19432@atomide.com>

* Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com> [160210 10:24]:
> This fixed a regression with DT boot compared to legacy boot.
> 
> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com>

Thanks, applying into omap-for-v4.5/fixes with Pali's ack.

Regards,

Tony

> ---
>  arch/arm/mach-omap2/board-generic.c | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
> index 8098272..bab814d 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -18,6 +18,7 @@
>  
>  #include <asm/setup.h>
>  #include <asm/mach/arch.h>
> +#include <asm/system_info.h>
>  
>  #include "common.h"
>  
> @@ -77,12 +78,31 @@ static const char *const n900_boards_compat[] __initconst = {
>  	NULL,
>  };
>  
> +/* Set system_rev from atags */
> +static void __init rx51_set_system_rev(const struct tag *tags)
> +{
> +	const struct tag *tag;
> +
> +	if (tags->hdr.tag != ATAG_CORE)
> +		return;
> +
> +	for_each_tag(tag, tags) {
> +		if (tag->hdr.tag == ATAG_REVISION) {
> +			system_rev = tag->u.revision.rev;
> +			break;
> +		}
> +	}
> +}
> +
>  /* Legacy userspace on Nokia N900 needs ATAGS exported in /proc/atags,
>   * save them while the data is still not overwritten
>   */
>  static void __init rx51_reserve(void)
>  {
> -	save_atags((const struct tag *)(PAGE_OFFSET + 0x100));
> +	const struct tag *tags = (const struct tag *)(PAGE_OFFSET + 0x100);
> +
> +	save_atags(tags);
> +	rx51_set_system_rev(tags);
>  	omap_reserve();
>  }
>  
> -- 
> 1.9.1
> 


From tony at atomide.com  Wed Feb 10 16:22:47 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Feb 2016 16:22:47 -0800
Subject: [PATCH] ARM: dts: am335x/am57xx: replace gpio-key,wakeup with
 wakeup-source property
In-Reply-To: <1454968553-12088-1-git-send-email-sudeep.holla@arm.com>
References: <1454968553-12088-1-git-send-email-sudeep.holla@arm.com>
Message-ID: <20160211002247.GO19432@atomide.com>

* Sudeep Holla <sudeep.holla at arm.com> [160208 13:57]:
> Commit 3efda00129bd ("ARM: dts: am335x: replace gpio-key,wakeup with
> wakeup-source property") replaces all the legacy "gpio-key,wakeup" with
> the unified  "wakeup-source" property to prevent any further copy-paste
> duplication.
> 
> However couple of use of these legacy property sneaked in during the
> merge window. This patch replaces them too.
> 
> Cc: "Beno?t Cousson" <bcousson at baylibre.com>
> Cc: Tony Lindgren <tony at atomide.com>
> Cc: linux-omap at vger.kernel.org
> Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
> ---
>  arch/arm/boot/dts/am335x-shc.dts          | 4 ++--
>  arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> Hi Tony,
> 
> I see these files got introduced during v4.5 merge window and we could
> not stop the copy-paste from the earlier versions files from which they
> were copied.

OK thanks for checking, applying this into omap-for-v4.5/fixes.

Regards,

Tony

> diff --git a/arch/arm/boot/dts/am335x-shc.dts b/arch/arm/boot/dts/am335x-shc.dts
> index 1b5b044fcd91..865de8500f1c 100644
> --- a/arch/arm/boot/dts/am335x-shc.dts
> +++ b/arch/arm/boot/dts/am335x-shc.dts
> @@ -46,7 +46,7 @@
>  			gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
>  			linux,code = <KEY_BACK>;
>  			debounce-interval = <1000>;
> -			gpio-key,wakeup;
> +			wakeup-source;
>  		};
>  
>  		front_button {
> @@ -54,7 +54,7 @@
>  			gpios = <&gpio1 25 GPIO_ACTIVE_HIGH>;
>  			linux,code = <KEY_FRONT>;
>  			debounce-interval = <1000>;
> -			gpio-key,wakeup;
> +			wakeup-source;
>  		};
>  	};
>  
> diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> index c53882643ae9..497eb07ced19 100644
> --- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> +++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> @@ -545,7 +545,7 @@
>  		ti,debounce-tol = /bits/ 16 <10>;
>  		ti,debounce-rep = /bits/ 16 <1>;
>  
> -		linux,wakeup;
> +		wakeup-source;
>  	};
>  };
>  
> -- 
> 1.9.1
> 


From tony at atomide.com  Wed Feb 10 16:25:58 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Feb 2016 16:25:58 -0800
Subject: [PATCH] ARM: DTS: am57xx-beagle-x15: Select SYS_CLK2 for audio
 clocks
In-Reply-To: <1455018417-2608-1-git-send-email-peter.ujfalusi@ti.com>
References: <1455018417-2608-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <20160211002558.GP19432@atomide.com>

* Peter Ujfalusi <peter.ujfalusi at ti.com> [160209 03:48]:
> The tlv320aic3104 codec's master clock is coming from the SoC's CLKOUT2.
> Select the SYS_CLK2 (via divider) as parent clock for CLKOUT2 and select
> the same clock (SYS_CLK2) for McASP3 AHCLKX clock as well.
> SYS_CLK2 is sourced from an external oscillator running 22.5792MHz and it
> is coming in to the SoC via the X1_OSC1.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>

Applying into omap-for-v4.5/fixes thanks.

Tony

> ---
>  arch/arm/boot/dts/am57xx-beagle-x15.dts | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> index c37a5193f199..592e65c3a4e0 100644
> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> @@ -173,6 +173,8 @@
>  
>  		sound0_master: simple-audio-card,codec {
>  			sound-dai = <&tlv320aic3104>;
> +			assigned-clocks = <&clkoutmux2_clk_mux>;
> +			assigned-clock-parents = <&sys_clk2_dclk_div>;
>  			clocks = <&clkout2_clk>;
>  		};
>  	};
> @@ -795,6 +797,8 @@
>  	pinctrl-names = "default", "sleep";
>  	pinctrl-0 = <&mcasp3_pins_default>;
>  	pinctrl-1 = <&mcasp3_pins_sleep>;
> +	assigned-clocks = <&mcasp3_ahclkx_mux>;
> +	assigned-clock-parents = <&sys_clkin2>;
>  	status = "okay";
>  
>  	op-mode = <0>;	/* MCASP_IIS_MODE */
> -- 
> 2.7.1
> 


From laurent.pinchart at ideasonboard.com  Wed Feb 10 16:33:30 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 11 Feb 2016 02:33:30 +0200
Subject: [PATCH v3 6/8] dmaengine: rcar-dmac: add iommu support for slave
 transfers
In-Reply-To: <1455065878-11906-7-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <1455065878-11906-7-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <7836168.xWoq7RJUyE@avalon>

Hi Niklas,

Thank you for the patch.

On Wednesday 10 February 2016 01:57:56 Niklas S?derlund wrote:
> Enable slave transfers to devices behind IPMMU:s by mapping the slave
> addresses using the dma-mapping API.
> 
> Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
> ---
>  drivers/dma/sh/rcar-dmac.c | 57 +++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 52 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index 743873c..268407c 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -1106,21 +1106,68 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan,
> dma_addr_t buf_addr, return desc;
>  }
> 
> +static int rcar_dmac_set_slave_addr(struct dma_chan *chan,
> +				     struct rcar_dmac_chan_slave *slave,
> +				     phys_addr_t addr, size_t size)
> +{
> +	struct dma_attrs attrs;
> +	enum dma_data_direction dir;
> +
> +	init_dma_attrs(&attrs);
> +	dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &attrs);
> +	dma_set_attr(DMA_ATTR_SKIP_CPU_SYNC, &attrs);
> +
> +	/*
> +	 * We can't know the direction at this time, see documentation for
> +	 * 'direction' in struct dma_slave_config.
> +	 */
> +	dir = DMA_BIDIRECTIONAL;
> +
> +	if (slave->xfer_size) {
> +		dma_unmap_resource(chan->device->dev, slave->slave_addr,
> +				slave->xfer_size, dir, &attrs);

Nitpicking, you can align slave with chan on the previous line.

> +		slave->slave_addr = 0;
> +		slave->xfer_size = 0;
> +	}
> +
> +	if (size) {
> +		slave->slave_addr = dma_map_resource(chan->device->dev, addr,
> +				size, dir, &attrs);
> +
> +		if (dma_mapping_error(chan->device->dev, slave->slave_addr)) {
> +			struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
> +
> +			dev_err(chan->device->dev,
> +					"chan%u: failed to map %zx@%pap",
> +					rchan->index, size, &addr);

Indentation looks weird to me.

> +			return -EIO;
> +		}
> +
> +		slave->xfer_size = size;
> +	}
> +
> +	return 0;
> +}
> +
>  static int rcar_dmac_device_config(struct dma_chan *chan,
>  				   struct dma_slave_config *cfg)
>  {
>  	struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
> +	int ret;
> 
>  	/*
>  	 * We could lock this, but you shouldn't be configuring the
>  	 * channel, while using it...
>  	 */
> -	rchan->src.slave_addr = cfg->src_addr;
> -	rchan->dst.slave_addr = cfg->dst_addr;
> -	rchan->src.xfer_size = cfg->src_addr_width;
> -	rchan->dst.xfer_size = cfg->dst_addr_width;
> 
> -	return 0;
> +	ret = rcar_dmac_set_slave_addr(chan, &rchan->src, cfg->src_addr,
> +			cfg->src_addr_width);
> +	if (ret)
> +		return ret;
> +
> +	ret = rcar_dmac_set_slave_addr(chan, &rchan->dst, cfg->dst_addr,
> +			cfg->dst_addr_width);

You could align cfg with chan on the previous line (twice).

With this fixed and the attributes removed as explained by Robin,

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> +	return ret;
>  }
> 
>  static int rcar_dmac_chan_terminate_all(struct dma_chan *chan)

-- 
Regards,

Laurent Pinchart



From mturquette at baylibre.com  Wed Feb 10 16:38:30 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Wed, 10 Feb 2016 16:38:30 -0800
Subject: [PATCH 3/3] clk: Provide OF helper to mark clocks as CRITICAL
In-Reply-To: <20160201082245.GV3368@x1>
References: <1453127331-20616-1-git-send-email-lee.jones@linaro.org>
 <1453127331-20616-4-git-send-email-lee.jones@linaro.org>
 <56A95811.8010200@arm.com> <20160201063256.GE32462@lukather>
 <20160201082245.GV3368@x1>
Message-ID: <20160211003830.26445.88202@quark.deferred.io>

Quoting Lee Jones (2016-02-01 00:22:45)
> On Mon, 01 Feb 2016, Maxime Ripard wrote:
> > On Wed, Jan 27, 2016 at 11:51:45PM +0000, Andr? Przywara wrote:
> > > Hi,
> > > 
> > > On 18/01/16 14:28, Lee Jones wrote:
> > > > This call matches clocks which have been marked as critical in DT
> > > > and sets the appropriate flag.  These flags can then be used to
> > > > mark the clock core flags appropriately prior to registration.
> > > 
> > > I like the idea of having a generic property very much. Also this solves
> > > a problem I have in a very elegant way.
> > 
> > Not really. It has a significant set of drawbacks that we already
> > detailed in the initial thread, which are mostly related to the fact
> > that the clocks are to be left on is something that totally depends on
> > the software support in the kernel. Some clocks should be reported as
> > critical because they are simply missing a driver for it, some should
> > be because the driver for it as not been compiled, some should because
> > we don't have the proper clocks drivers yet for one of their
> > downstream clocks.
> 
> Exactly.  This is a not a CLK_DRIVER_NOT_{AUTHORED|UPSTREAM} or
> CLK_DRIVER_NOT_ENABLED implementation, it's for CLK_CRITICALs.
> Critical clocks must _never_ be turned off, no matter what, else
> something really bad will happen.  In our use-case, if the clocks are
> turned of, it will be catastrophic to the running system.
> 
> > Basically, it all boils down to this: some clocks should never ever be
> > shutdown because <hardware reason>, and I believe it's the case Lee is
> > in. But most of the current code that would use it might, and might
> > even need at some point to shut down such a clock.

Handoff clocks solved both the handoff clock problem (which Rhyland's
thread[0] brings back up) and the critical clock problem entirely except
for a single corner case: if a *critical* clk is enabled at boot via the
HANDOFF flag and then a driver get's that clk and enables/disables it.
Then we lose the refcount and the critical clock (which must never be
gated) will be gated.

That is the executive summary of my discussion with Lee last year. I'm
fine to merge both critical clocks and handoff clocks into the clk core
to cover all corner cases.

I'll post a series combining both sets of patches later today for
review.

> > 
> > Mike's solution with the flags + handover was solving all this, I'm
> > not sure why he's not pushed it forward.

Because I was super busy. I'm still super busy but now I will ignore
other important things and catch up on clk land. ;-)

[0] https://lkml.org/lkml/2016/2/9/817

Regards,
Mike

> 
> Right, but I think you are missing part of the conversation.  Mike and
> I had a face-to-face meeting in San Francisco last year.  The
> conclusion was that the CLK_CRITICAL and CLK_HANDOVER solutions should
> be separated.  Different handling, different code.  This submission
> only solves the former problem.  I believe Mike was going to submit
> and follow-up on the CLK_HANDOVER solution separately.
> 
> -- 
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog


From laurent.pinchart at ideasonboard.com  Wed Feb 10 16:41:28 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 11 Feb 2016 02:41:28 +0200
Subject: [PATCH v3 7/8] ARM: dts: r8a7790: add iommus to dmac0 and dmac1
In-Reply-To: <1455065878-11906-8-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <1455065878-11906-8-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1704813.5Ff44u3Kaz@avalon>

Hi Niklas,

Thank you for the patch.

On Wednesday 10 February 2016 01:57:57 Niklas S?derlund wrote:

No commit message ? I'd at least mention that as a side effect of this patch 
channel 0 and 15 are disabled, reducing the effective number of channels to 14 
per DMAC.

> Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>

Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

Same comment and ack for patch 8/8.

Note that we should still try to find a way to selectively enable the IOMMU in 
a per-device fashion, as system integrators might want it to be disabled for 
some devices. There's no urgency though.

> ---
>  arch/arm/boot/dts/r8a7790.dtsi | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
> index 7dfd393..048bbf8 100644
> --- a/arch/arm/boot/dts/r8a7790.dtsi
> +++ b/arch/arm/boot/dts/r8a7790.dtsi
> @@ -294,6 +294,21 @@
>  		power-domains = <&cpg_clocks>;
>  		#dma-cells = <1>;
>  		dma-channels = <15>;
> +		iommus = <&ipmmu_ds 0>,
> +			 <&ipmmu_ds 1>,
> +			 <&ipmmu_ds 2>,
> +			 <&ipmmu_ds 3>,
> +			 <&ipmmu_ds 4>,
> +			 <&ipmmu_ds 5>,
> +			 <&ipmmu_ds 6>,
> +			 <&ipmmu_ds 7>,
> +			 <&ipmmu_ds 8>,
> +			 <&ipmmu_ds 9>,
> +			 <&ipmmu_ds 10>,
> +			 <&ipmmu_ds 11>,
> +			 <&ipmmu_ds 12>,
> +			 <&ipmmu_ds 13>,
> +			 <&ipmmu_ds 14>;
>  	};
> 
>  	dmac1: dma-controller at e6720000 {
> @@ -325,6 +340,21 @@
>  		power-domains = <&cpg_clocks>;
>  		#dma-cells = <1>;
>  		dma-channels = <15>;
> +		iommus = <&ipmmu_ds 15>,
> +			 <&ipmmu_ds 16>,
> +			 <&ipmmu_ds 17>,
> +			 <&ipmmu_ds 18>,
> +			 <&ipmmu_ds 19>,
> +			 <&ipmmu_ds 20>,
> +			 <&ipmmu_ds 21>,
> +			 <&ipmmu_ds 22>,
> +			 <&ipmmu_ds 23>,
> +			 <&ipmmu_ds 24>,
> +			 <&ipmmu_ds 25>,
> +			 <&ipmmu_ds 26>,
> +			 <&ipmmu_ds 27>,
> +			 <&ipmmu_ds 28>,
> +			 <&ipmmu_ds 29>;
>  	};
> 
>  	audma0: dma-controller at ec700000 {

-- 
Regards,

Laurent Pinchart



From mturquette at baylibre.com  Wed Feb 10 16:41:24 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Wed, 10 Feb 2016 16:41:24 -0800
Subject: [PATCH 1/3] clk: Allow clocks to be marked as CRITICAL
In-Reply-To: <1453127331-20616-2-git-send-email-lee.jones@linaro.org>
References: <1453127331-20616-1-git-send-email-lee.jones@linaro.org>
 <1453127331-20616-2-git-send-email-lee.jones@linaro.org>
Message-ID: <20160211004124.26445.47437@quark.deferred.io>

Quoting Lee Jones (2016-01-18 06:28:49)
> Critical clocks are those which must not be gated, else undefined
> or catastrophic failure would occur.  Here we have chosen to
> ensure the prepare/enable counts are correctly incremented, so as
> not to confuse users with enabled clocks with no visible users.
> 
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  drivers/clk/clk.c            | 7 ++++++-
>  include/linux/clk-provider.h | 1 +
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index f13c3f4..835cb85 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2576,8 +2576,13 @@ struct clk *clk_register(struct device *dev, struct clk_hw *hw)
>         }
>  
>         ret = __clk_init(dev, hw->clk);
> -       if (!ret)
> +       if (!ret) {
> +               if (core->flags & CLK_IS_CRITICAL) {
> +                       clk_core_prepare(core);
> +                       clk_core_enable(core);
> +               }
>                 return hw->clk;
> +       }

I moved the above code into __clk_init where we do similar sort of clk
init-y type things. Modified patch below.

Best regards,
Mike



From 83b4f533b581a386341cd0cf9dbce92286e41e75 Mon Sep 17 00:00:00 2001
From: Lee Jones <lee.jones at linaro.org>
Date: Mon, 18 Jan 2016 14:28:49 +0000
Subject: [PATCH 1/6] clk: Allow clocks to be marked as CRITICAL

Critical clocks are those which must not be gated, else undefined
or catastrophic failure would occur.  Here we have chosen to
ensure the prepare/enable counts are correctly incremented, so as
not to confuse users with enabled clocks with no visible users.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
Signed-off-by: Michael Turquette <mturquette at baylibre.com>
---
 drivers/clk/clk.c            | 5 +++++
 include/linux/clk-provider.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index b4db67a..993f775 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2484,6 +2484,11 @@ static int __clk_init(struct device *dev, struct clk *clk_user)
 	if (core->ops->init)
 		core->ops->init(core->hw);
 
+	if (core->flags & CLK_IS_CRITICAL) {
+		clk_core_prepare(core);
+		clk_core_enable(core);
+	}
+
 	kref_init(&core->ref);
 out:
 	clk_prepare_unlock();
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1143e38..1d986ea 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -32,6 +32,7 @@
 #define CLK_GET_ACCURACY_NOCACHE BIT(8) /* do not use the cached clk accuracy */
 #define CLK_RECALC_NEW_RATES	BIT(9) /* recalc rates after notifications */
 #define CLK_SET_RATE_UNGATE	BIT(10) /* clock needs to run to set rate */
+#define CLK_IS_CRITICAL		BIT(11) /* do not gate, ever */
 
 struct clk;
 struct clk_hw;
-- 
2.1.4



From mturquette at baylibre.com  Wed Feb 10 16:43:27 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Wed, 10 Feb 2016 16:43:27 -0800
Subject: [PATCH 2/3] clk: WARN_ON about to disable a critical clock
In-Reply-To: <1453127331-20616-3-git-send-email-lee.jones@linaro.org>
References: <1453127331-20616-1-git-send-email-lee.jones@linaro.org>
 <1453127331-20616-3-git-send-email-lee.jones@linaro.org>
Message-ID: <20160211004327.26445.27416@quark.deferred.io>

Quoting Lee Jones (2016-01-18 06:28:50)
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Looks good to me.

Regards,
Mike

> ---
>  drivers/clk/clk.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 835cb85..178b364 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -575,6 +575,9 @@ static void clk_core_unprepare(struct clk_core *core)
>         if (WARN_ON(core->prepare_count == 0))
>                 return;
>  
> +       if (WARN_ON(core->prepare_count == 1 && core->flags & CLK_IS_CRITICAL))
> +               return;
> +
>         if (--core->prepare_count > 0)
>                 return;
>  
> @@ -680,6 +683,9 @@ static void clk_core_disable(struct clk_core *core)
>         if (WARN_ON(core->enable_count == 0))
>                 return;
>  
> +       if (WARN_ON(core->enable_count == 1 && core->flags & CLK_IS_CRITICAL))
> +               return;
> +
>         if (--core->enable_count > 0)
>                 return;
>  
> -- 
> 1.9.1
> 


From mturquette at baylibre.com  Wed Feb 10 16:48:53 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Wed, 10 Feb 2016 16:48:53 -0800
Subject: [PATCH 3/3] clk: Provide OF helper to mark clocks as CRITICAL
In-Reply-To: <1453127331-20616-4-git-send-email-lee.jones@linaro.org>
References: <1453127331-20616-1-git-send-email-lee.jones@linaro.org>
 <1453127331-20616-4-git-send-email-lee.jones@linaro.org>
Message-ID: <20160211004853.26445.85326@quark.deferred.io>

Quoting Lee Jones (2016-01-18 06:28:51)
> This call matches clocks which have been marked as critical in DT
> and sets the appropriate flag.  These flags can then be used to
> mark the clock core flags appropriately prior to registration.
> 
> Signed-off-by: Lee Jones <lee.jones at linaro.org>
> ---
>  include/linux/clk-provider.h | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index ffa0b2e..6f178b7 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -707,6 +707,23 @@ const char *of_clk_get_parent_name(struct device_node *np, int index);
>  
>  void of_clk_init(const struct of_device_id *matches);
>  

Added kerneldoc here outlining who should use this (legacy DT bindings
and no one else).

> +static inline int of_clk_mark_if_critical(struct device_node *np,
> +                                         int index, unsigned long *flags)

Moved this to clk.c, uninlined it and unstaticized it. Renamed beastly
function name to of_clk_detect_critical.

> +{
> +       struct property *prop;
> +       const __be32 *cur;
> +       uint32_t idx;
> +
> +       if (!np || !flags)
> +               return -EINVAL;
> +
> +       of_property_for_each_u32(np, "critical-clock", prop, cur, idx)

Changed property name to clock-critical to better match its siblings.

Modified patch below.

Best regards,
Mike



From 42df0a24d3c0bfd321e867e4113214160f17fadc Mon Sep 17 00:00:00 2001
From: Lee Jones <lee.jones at linaro.org>
Date: Mon, 18 Jan 2016 14:28:51 +0000
Subject: [PATCH 3/6] clk: Provide OF helper to mark clocks as CRITICAL

This call matches clocks which have been marked as critical in DT
and sets the appropriate flag.  These flags can then be used to
mark the clock core flags appropriately prior to registration.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
Signed-off-by: Michael Turquette <mturquette at baylibre.com>
---
 drivers/clk/clk.c            | 35 +++++++++++++++++++++++++++++++++++
 include/linux/clk-provider.h |  8 +++++++-
 2 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 39f9527..5181a15 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3202,6 +3202,41 @@ static int parent_ready(struct device_node *np)
 }
 
 /**
+ * of_clk_detect_critical() - set CLK_IS_CRITICAL flag from Device Tree
+ * @np: Device node pointer associated with clock provider
+ * @index: clock index
+ * @flags: pointer to clk_core->flags
+ *
+ * Detects if the clock-critical property exists and, if so, sets the
+ * corresponding CLK_IS_CRITICAL flag.
+ *
+ * Do not use this function. It exists only for legacy Device Tree
+ * bindings, such as the one-clock-per-node style that are outdated.
+ * Those bindings typically put all clock data into .dts and the Linux
+ * driver has no clock data, thus making it impossible to set this flag
+ * correctly from the driver. Only those drivers may call
+ * of_clk_detect_critical from their setup functions.
+ *
+ * Return: error code or zero on success
+ */
+int of_clk_mark_if_critical(struct device_node *np,
+					  int index, unsigned long *flags)
+{
+	struct property *prop;
+	const __be32 *cur;
+	uint32_t idx;
+
+	if (!np || !flags)
+		return -EINVAL;
+
+	of_property_for_each_u32(np, "clock-critical", prop, cur, idx)
+		if (index == idx)
+			*flags |= CLK_IS_CRITICAL;
+
+	return 0;
+}
+
+/**
  * of_clk_init() - Scan and init clock providers from the DT
  * @matches: array of compatible values and init functions for providers.
  *
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1d986ea..d15d3cc 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -705,7 +705,8 @@ int of_clk_get_parent_count(struct device_node *np);
 int of_clk_parent_fill(struct device_node *np, const char **parents,
 		       unsigned int size);
 const char *of_clk_get_parent_name(struct device_node *np, int index);
-
+int of_clk_mark_if_critical(struct device_node *np, int index,
+			    unsigned long *flags);
 void of_clk_init(const struct of_device_id *matches);
 
 #else /* !CONFIG_OF */
@@ -742,6 +743,11 @@ static inline const char *of_clk_get_parent_name(struct device_node *np,
 {
 	return NULL;
 }
+static inline int of_clk_mark_if_critical(struct device_node *np, int index,
+					  unsigned long *flags)
+{
+	return 0;
+}
 static inline void of_clk_init(const struct of_device_id *matches) {}
 #endif /* CONFIG_OF */
 
-- 
2.1.4



From niklas.soderlund at ragnatech.se  Wed Feb 10 16:50:52 2016
From: niklas.soderlund at ragnatech.se (Niklas =?iso-8859-1?Q?S=F6derlund?=)
Date: Thu, 11 Feb 2016 01:50:52 +0100
Subject: [PATCH v3 7/8] ARM: dts: r8a7790: add iommus to dmac0 and dmac1
In-Reply-To: <20160210175559.GD17671@verge.net.au>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <1455065878-11906-8-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <20160210175559.GD17671@verge.net.au>
Message-ID: <20160211005052.GD19813@bigcity.dyn.berto.se>

Hi Simon,

* Simon Horman <horms at verge.net.au> [2016-02-10 18:55:59 +0100]:

> Hi Niklas,
>
> I am deferring accepting this and the similar patch for the r8a7791 pending
> acceptance of the driver changes earlier in this series. Please let me know
> if you prefer a different course of action.

That sounds good, thanks.

>
> I notice that the devel branch of there renesas tree there are
> dmac nodes for the r8a7793, r8a7794 and r8a7795. Is this change,
> also suitable for those SoCs? If so, do you plan to update them?
> If not I'll add it to my todo list.

I planed to update all effected SoCs once the dependencies for this
series where accepted. But if you want to keep track of this I'm happy.


From mturquette at baylibre.com  Wed Feb 10 17:00:58 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Wed, 10 Feb 2016 17:00:58 -0800
Subject: [PATCH 0/3] clk: Add support for critical clocks
In-Reply-To: <1453127331-20616-1-git-send-email-lee.jones@linaro.org>
References: <1453127331-20616-1-git-send-email-lee.jones@linaro.org>
Message-ID: <20160211010058.26445.37542@quark.deferred.io>

Hi Lee,

Quoting Lee Jones (2016-01-18 06:28:48)
> Some platforms contain clocks which if gated, will cause undefined or
> catastrophic behaviours.  As such they are not to be turned off, ever.
> Many of these such clocks do not have devices, thus device drivers
> where clocks may be enabled and references taken to ensure they stay
> enabled do not exist.  Therefore, we must handle these such cases in
> the core.
> 
> This patchset defines an CLK_IS_CRITICAL flag which the core can use
> to identify critical clocks and subsequently refuse to gate them.
> Once a clock has been recognised as critical, we take extra
> references to ensure the continued functionality of the clock
> whatever else happens.
> 
> Mike,
> 
> It's been 17 weeks since our meeting in San Francisco and I'm keen to
> move this forward.  As per our meeting, the plan is to separate our
> two requirements, as users who require both critical clocks AND the
> hand-off feature do not currently exist.  If you'd like to continue
> enablement of the hand-off functionality you were interested in, I'll
> continue on with critical clocks, as we still need this for our
> platform.
> 
> I'm hoping this isn't the wrong approach, but if it is, let me know
> how it can be improved and I'll re-roll.

Thanks for getting this going again. I've made tiny modifications to
your patches and reposted in this thread (w/ attribution to you of
course). Please let me know what you think.

Regarding Architecting The Perfect Solution, my take away from our
face-to-face discussion wass that handoff clocks covered every need of
critical (always on) clocks with a single exception, and that exception
is enough to merit supporting both.

The one area where we disagree is support for the DT property. You need
this because at least one of the platforms you care about use an
unfortunate, legacy clock binding style that came from a time before we
knew any better.

I definitely will never add a critical-clock property to the common
clock binding, but I cannot leave you without a solution either. I've
added kerneldoc around the function that sets the critical clock flag
making it clear that it should only be called from the setup functions
for clocks using the legacy binding style. It won't be called from
clk_register, __clk_init, or otherwise, but on a per-driver basis. This
removes the need for drivers to open code a solution where they match on
clk string name and add the flag or something super gross like that.

I will also repost my 3 handoff patches, rebased on top of your 3
critical clock patches. I'm sure they'll be pals and get along just
great.

Best regards,
Mike

> 
> Kind regards,
> Lee
> 
> Lee Jones (3):
>   clk: Allow clocks to be marked as CRITICAL
>   clk: WARN_ON about to disable a critical clock
>   clk: Provide OF helper to mark clocks as CRITICAL
> 
>  drivers/clk/clk.c            | 13 ++++++++++++-
>  include/linux/clk-provider.h | 23 +++++++++++++++++++++++
>  2 files changed, 35 insertions(+), 1 deletion(-)
> 
> -- 
> 1.9.1
> 


From tony at atomide.com  Wed Feb 10 17:08:18 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 10 Feb 2016 17:08:18 -0800
Subject: N900 sleep mode (in 4.5-rc0, if that matters)
In-Reply-To: <20160209172403.GK19432@atomide.com>
References: <20160126140010.GA29723@amd> <20160126172527.GY3500@atomide.com>
 <20160130200244.GA30429@amd> <20160130201452.GC30429@amd>
 <20160130221509.GA28644@amd> <20160201181316.GM19432@atomide.com>
 <20160201211736.GA11283@amd> <20160201221111.GP19432@atomide.com>
 <20160207212316.GA6147@amd> <20160209172403.GK19432@atomide.com>
Message-ID: <20160211010818.GQ19432@atomide.com>

* Tony Lindgren <tony at atomide.com> [160209 09:26]:
> * Pavel Machek <pavel at ucw.cz> [160207 13:24]:
> 
> > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042
> > 0000000d 48004a28 (fa004a28) cm_idlest3_core
> 
> Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go
> down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ?
> 
> If not, the're PM runtime missing or broken somewhere.

Just tested n900 wlan here and it's working for me with Emil's
patch from the "" thread and the PM runtime regression fix for
hsmmc I posted earlier today. Looks like n900 is hitting off
mode just fine with wlan0 configured.

It does not wake up to pings from outside from off mode though
until the system wakes up.

I'll take a look and send a patch for that separately.

Regards,

Tony


From martin.petersen at oracle.com  Wed Feb 10 17:24:21 2016
From: martin.petersen at oracle.com (Martin K. Petersen)
Date: Wed, 10 Feb 2016 20:24:21 -0500
Subject: [PATCH 0/7] SCSI bug fixes for 4.6
In-Reply-To: <1453910247-3447628-1-git-send-email-arnd@arndb.de> (Arnd
 Bergmann's message of "Wed, 27 Jan 2016 16:57:16 +0100")
References: <1453910247-3447628-1-git-send-email-arnd@arndb.de>
Message-ID: <yq1si1082ey.fsf@sermon.lab.mkp.net>

>>>>> "Arnd" == Arnd Bergmann <arnd at arndb.de> writes:

Arnd> Here are a bunch of fixes for harmless bugs I found during ARM
Arnd> randconfig testing. It would be nice to get them mered in 4.6, but
Arnd> there is no need to have them in 4.5 as no incorrect behavior
Arnd> results from the current code, and the warnings are all hard to
Arnd> trigger.

Applied to 4.6/scsi-queue.

-- 
Martin K. Petersen	Oracle Linux Engineering


From vz at mleia.com  Wed Feb 10 17:41:58 2016
From: vz at mleia.com (Vladimir Zapolskiy)
Date: Thu, 11 Feb 2016 03:41:58 +0200
Subject: [GIT PULL] NXP LPC32xx Platform Updates for v4.6 #1
Message-ID: <56BBE6E6.4080802@mleia.com>

Hi Arnd, Olof, Kevin,

please consider to include NXP LPC32xx platfrom updates (#1) for v4.6.

The main change is a switchover to a common clock framework driver
for LPC32xx, this also allows to reuse a shared LPC32xx clockevent
driver, and hence remove legacy clock and timer drivers from
arch/arm/mach-lpc32xx.

I'm adding an official LPC32xx maintainer Roland to Cc, however
he seems to be unresponsive for a quite long time (since 2014).

----------------------------------------------------------------

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  https://github.com/vzapolskiy/linux.git lpc32xx/soc

for you to fetch changes up to 0ac1a101f5dd28c3894be3c0230ee7ea2e05e8aa:

  arm: lpc32xx: remove direct control of GPIOs from shared mach file (2016-02-11 02:27:04 +0200)

----------------------------------------------------------------

Vladimir Zapolskiy (3):
      arm: lpc32xx: switch to common clock framework
      arm: lpc32xx: remove selected HAVE_IDE
      arm: lpc32xx: remove direct control of GPIOs from shared mach file

 arch/arm/Kconfig                |    4 +-
 arch/arm/mach-lpc32xx/Makefile  |    3 +-
 arch/arm/mach-lpc32xx/clock.c   | 1284 ---------------------------------------
 arch/arm/mach-lpc32xx/phy3250.c |   53 --
 arch/arm/mach-lpc32xx/serial.c  |    3 -
 arch/arm/mach-lpc32xx/timer.c   |  144 -----
 6 files changed, 3 insertions(+), 1488 deletions(-)
 delete mode 100644 arch/arm/mach-lpc32xx/clock.c
 delete mode 100644 arch/arm/mach-lpc32xx/timer.c


From vz at mleia.com  Wed Feb 10 17:42:01 2016
From: vz at mleia.com (Vladimir Zapolskiy)
Date: Thu, 11 Feb 2016 03:42:01 +0200
Subject: [GIT PULL] NXP LPC32xx DT Updates for v4.6 #1
Message-ID: <56BBE6E9.1080509@mleia.com>

Hi Arnd, Olof, Kevin,

please consider to include NXP LPC32xx DT updates (#1) for v4.6.

The changes add description of clock providers and clock consumers,
define default irq types of SoC controllers and add PHY3250 board
regulators.

I'm adding an official LPC32xx maintainer Roland to Cc, however
he seems to be unresponsive for a quite long time (since 2014).

----------------------------------------------------------------

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  https://github.com/vzapolskiy/linux.git lpc32xx/dt

for you to fetch changes up to d06670e96267d1f1a771f71f5719c0a2c0092ec1:

  arm: dts: phy3250: add SD fixed regulator (2016-02-11 03:06:36 +0200)

----------------------------------------------------------------

Vladimir Zapolskiy (9):
      dt-bindings: create arm/nxp folder and move LPC32xx SoC description to it
      arm: dts: lpc32xx: add device nodes for external oscillators
      arm: dts: lpc32xx: add clock controller device node
      arm: dts: lpc32xx: add clock properties to device nodes
      arm: dts: lpc32xx: add USB clock controller
      arm: dts: lpc32xx: remove clock frequency property from UART device nodes
      arm: dts: lpc32xx: assign interrupt types
      arm: dts: phy3250: add lcd and backlight fixed regulators
      arm: dts: phy3250: add SD fixed regulator

 .../devicetree/bindings/arm/{ => nxp}/lpc32xx.txt  |   0
 arch/arm/boot/dts/lpc32xx.dtsi                     | 150 ++++++++++++++++-----
 arch/arm/boot/dts/phy3250.dts                      |  32 +++++
 3 files changed, 149 insertions(+), 33 deletions(-)
 rename Documentation/devicetree/bindings/arm/{ => nxp}/lpc32xx.txt (100%)


From stefan at agner.ch  Wed Feb 10 18:08:18 2016
From: stefan at agner.ch (Stefan Agner)
Date: Wed, 10 Feb 2016 18:08:18 -0800
Subject: [PATCH] ARM: imx_v6_v7_defconfig: enable useful configurations for
 Vybrid
Message-ID: <1455156498-29949-1-git-send-email-stefan@agner.ch>

Enable configuration options useful for Vybrid:
- NFC NAND driver
- USB dual-role controller support
- FTM PWM driver
- DSPI SPI driver
- Colibri VF50 Touchscreen support.

Beside that, enable useful configurations such as IIO hwmon support
(used in i.MX 23/28, patch pending for Vybrid), PWM LED support and
CPU idle support.

Regenerated config using savedefconfig (which removes some configs
which are now enabled by default).

Signed-off-by: Stefan Agner <stefan at agner.ch>
---
 arch/arm/configs/imx_v6_v7_defconfig | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 25a6066..dc7dc5c 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -57,6 +57,7 @@ CONFIG_KEXEC=y
 CONFIG_CPU_FREQ=y
 CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
 CONFIG_ARM_IMX6Q_CPUFREQ=y
+CONFIG_CPU_IDLE=y
 CONFIG_VFP=y
 CONFIG_NEON=y
 CONFIG_BINFMT_MISC=m
@@ -72,7 +73,6 @@ CONFIG_IP_PNP_DHCP=y
 # CONFIG_INET_XFRM_MODE_TUNNEL is not set
 # CONFIG_INET_XFRM_MODE_BEET is not set
 # CONFIG_INET_LRO is not set
-CONFIG_IPV6=y
 CONFIG_NETFILTER=y
 CONFIG_CAN=y
 CONFIG_CAN_FLEXCAN=y
@@ -104,10 +104,13 @@ CONFIG_MTD_M25P80=y
 CONFIG_MTD_SST25L=y
 CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_GPMI_NAND=y
+CONFIG_MTD_NAND_VF610_NFC=y
 CONFIG_MTD_NAND_MXC=y
 CONFIG_MTD_SPI_NOR=y
 CONFIG_SPI_FSL_QUADSPI=y
 CONFIG_MTD_UBI=y
+CONFIG_MTD_UBI_FASTMAP=y
+CONFIG_MTD_UBI_BLOCK=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_SIZE=65536
@@ -145,7 +148,6 @@ CONFIG_USB_RTL8152=m
 CONFIG_USB_USBNET=m
 CONFIG_USB_NET_CDC_EEM=m
 CONFIG_BRCMFMAC=m
-CONFIG_WL_TI=y
 CONFIG_WL12XX=m
 CONFIG_WLCORE_SDIO=m
 # CONFIG_WILINK_PLATFORM_DATA is not set
@@ -164,6 +166,7 @@ CONFIG_TOUCHSCREEN_MC13783=y
 CONFIG_TOUCHSCREEN_TSC2007=y
 CONFIG_TOUCHSCREEN_STMPE=y
 CONFIG_TOUCHSCREEN_SX8654=y
+CONFIG_TOUCHSCREEN_COLIBRI_VF50=y
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_MMA8450=y
 CONFIG_SERIO_SERPORT=m
@@ -173,7 +176,6 @@ CONFIG_SERIAL_IMX=y
 CONFIG_SERIAL_IMX_CONSOLE=y
 CONFIG_SERIAL_FSL_LPUART=y
 CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
-CONFIG_HW_RANDOM=y
 # CONFIG_I2C_COMPAT is not set
 CONFIG_I2C_CHARDEV=y
 # CONFIG_I2C_HELPER_AUTO is not set
@@ -182,6 +184,7 @@ CONFIG_I2C_ALGOPCA=m
 CONFIG_I2C_IMX=y
 CONFIG_SPI=y
 CONFIG_SPI_IMX=y
+CONFIG_SPI_FSL_DSPI=y
 CONFIG_GPIO_SYSFS=y
 CONFIG_GPIO_MC9S08DZ60=y
 CONFIG_GPIO_PCA953X=y
@@ -192,6 +195,7 @@ CONFIG_POWER_RESET_IMX=y
 CONFIG_POWER_RESET_SYSCON=y
 CONFIG_POWER_RESET_SYSCON_POWEROFF=y
 CONFIG_SENSORS_GPIO_FAN=y
+CONFIG_SENSORS_IIO_HWMON=y
 CONFIG_THERMAL=y
 CONFIG_CPU_THERMAL=y
 CONFIG_IMX_THERMAL=y
@@ -227,7 +231,6 @@ CONFIG_DRM=y
 CONFIG_DRM_PANEL_SIMPLE=y
 CONFIG_DRM_DW_HDMI_AHB_AUDIO=m
 CONFIG_DRM_IMX=y
-CONFIG_DRM_IMX_FB_HELPER=y
 CONFIG_DRM_IMX_PARALLEL_DISPLAY=y
 CONFIG_DRM_IMX_TVE=y
 CONFIG_DRM_IMX_LDB=y
@@ -271,6 +274,7 @@ CONFIG_USB_EHSET_TEST_FIXTURE=m
 CONFIG_NOP_USB_XCEIV=y
 CONFIG_USB_MXS_PHY=y
 CONFIG_USB_GADGET=y
+CONFIG_USB_FSL_USB2=y
 CONFIG_USB_CONFIGFS=m
 CONFIG_USB_CONFIGFS_SERIAL=y
 CONFIG_USB_CONFIGFS_ACM=y
@@ -296,6 +300,7 @@ CONFIG_MMC_SDHCI_ESDHC_IMX=y
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_PWM=y
 CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=y
 CONFIG_LEDS_TRIGGER_ONESHOT=y
@@ -312,14 +317,15 @@ CONFIG_RTC_DRV_MC13XXX=y
 CONFIG_RTC_DRV_MXC=y
 CONFIG_RTC_DRV_SNVS=y
 CONFIG_DMADEVICES=y
+CONFIG_FSL_EDMA=y
 CONFIG_IMX_SDMA=y
 CONFIG_MXS_DMA=y
-CONFIG_FSL_EDMA=y
 CONFIG_STAGING=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_IIO=y
 CONFIG_VF610_ADC=y
 CONFIG_PWM=y
+CONFIG_PWM_FSL_FTM=y
 CONFIG_PWM_IMX=y
 CONFIG_NVMEM=y
 CONFIG_NVMEM_IMX_OCOTP=y
@@ -330,9 +336,6 @@ CONFIG_EXT2_FS_SECURITY=y
 CONFIG_EXT3_FS=y
 CONFIG_EXT3_FS_POSIX_ACL=y
 CONFIG_EXT3_FS_SECURITY=y
-CONFIG_EXT4_FS=y
-CONFIG_EXT4_FS_POSIX_ACL=y
-CONFIG_EXT4_FS_SECURITY=y
 CONFIG_QUOTA=y
 CONFIG_QUOTA_NETLINK_INTERFACE=y
 # CONFIG_PRINT_QUOTA_WARNING is not set
-- 
2.7.1



From stefan at agner.ch  Wed Feb 10 18:10:52 2016
From: stefan at agner.ch (Stefan Agner)
Date: Wed, 10 Feb 2016 18:10:52 -0800
Subject: [PATCH] ARM: multi_v7_defconfig: enable useful configurations for
 Vybrid
Message-ID: <1455156652-6950-1-git-send-email-stefan@agner.ch>

Enable configuration options useful for Vybrid:
- NFC NAND driver
- USB dual-role controller (and Chipidea Gadget support)
- Built-in EDMA DMA driver (to be available at LPUART probe)
- Vybrid ADC driver
- IIO hwmon support (used in i.MX 23/28, patch pending for Vybrid)

Signed-off-by: Stefan Agner <stefan at agner.ch>
---
 arch/arm/configs/multi_v7_defconfig | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 314f6be..98ae019 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -182,6 +182,7 @@ CONFIG_MTD_M25P80=y
 CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_ATMEL=y
 CONFIG_MTD_NAND_BRCMNAND=y
+CONFIG_MTD_NAND_VF610_NFC=y
 CONFIG_MTD_NAND_DAVINCI=y
 CONFIG_MTD_SPI_NOR=y
 CONFIG_SPI_FSL_QUADSPI=m
@@ -403,6 +404,7 @@ CONFIG_POWER_RESET_KEYSTONE=y
 CONFIG_POWER_RESET_RMOBILE=y
 CONFIG_POWER_AVS=y
 CONFIG_ROCKCHIP_IODOMAIN=y
+CONFIG_SENSORS_IIO_HWMON=y
 CONFIG_SENSORS_LM90=y
 CONFIG_SENSORS_LM95245=y
 CONFIG_SENSORS_NTC_THERMISTOR=m
@@ -594,6 +596,7 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC2=m
 CONFIG_USB_CHIPIDEA=y
+CONFIG_USB_CHIPIDEA_UDC=y
 CONFIG_USB_CHIPIDEA_HOST=y
 CONFIG_AB8500_USB=y
 CONFIG_KEYSTONE_USB_PHY=y
@@ -603,6 +606,7 @@ CONFIG_USB_ISP1301=y
 CONFIG_USB_MSM_OTG=m
 CONFIG_USB_MXS_PHY=y
 CONFIG_USB_GADGET=y
+CONFIG_USB_FSL_USB2=y
 CONFIG_USB_RENESAS_USBHS_UDC=m
 CONFIG_USB_ETH=m
 CONFIG_MMC=y
@@ -690,7 +694,7 @@ CONFIG_DMADEVICES=y
 CONFIG_DW_DMAC=y
 CONFIG_AT_HDMAC=y
 CONFIG_AT_XDMAC=y
-CONFIG_FSL_EDMA=m
+CONFIG_FSL_EDMA=y
 CONFIG_MV_XOR=y
 CONFIG_TEGRA20_APB_DMA=y
 CONFIG_SH_DMAE=y
@@ -749,6 +753,7 @@ CONFIG_IIO=y
 CONFIG_AT91_ADC=m
 CONFIG_BERLIN2_ADC=m
 CONFIG_EXYNOS_ADC=m
+CONFIG_VF610_ADC=m
 CONFIG_XILINX_XADC=y
 CONFIG_AK8975=y
 CONFIG_PWM=y
-- 
2.7.1



From harba at codeaurora.org  Wed Feb 10 18:40:44 2016
From: harba at codeaurora.org (Abdulhamid, Harb)
Date: Wed, 10 Feb 2016 21:40:44 -0500
Subject: [PATCH V1 4/6] arm64: exception: handle Synchronous External Abort
In-Reply-To: <20160210180344.GV1052@arm.com>
References: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
 <1454699608-22760-5-git-send-email-tbaicar@codeaurora.org>
 <20160210180344.GV1052@arm.com>
Message-ID: <56BBF4AC.7000208@codeaurora.org>

On 2/10/2016 1:03 PM, Will Deacon wrote:
> On Fri, Feb 05, 2016 at 12:13:26PM -0700, Tyler Baicar wrote:

<snip>

>> +static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>> +{
>> +	struct siginfo info;
>> +
>> +	atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
>> +
>> +	pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
>> +		 fault_name(esr), esr, addr);
>> +
>> +	info.si_signo = SIGBUS;
>> +	info.si_errno = 0;
>> +	info.si_code  = 0;
>> +	info.si_addr  = (void __user *)addr;
>> +	arm64_notify_die("", regs, &info, esr);
> 
> Surely we don't want to call this if the notifier chain handled the
> exception?
You are correct, Ideally you should not die if the notifier chain
handled the exception (e.g. via memory fault handling).  However, this
patch was intended as a first step to provide the user with more useful
information about the hardware error (e.g. details of a cache error, bus
error, or memory error that led to the SEA).

The thought was to do what your suggesting as a next step (i.e. adding
actually recovery mechanisms in the SEA handler). However, there are a
couple of questions enumerated below that I think need more discussion.

First, you need a way to get information returned from the notifier
chain to understand whether or not it recovered from the error. (If this
easier than I'm making it out to be, please set me straight here, as it
was not clear to me at first glance on how to do that)

Second, you need a way to kill/abort the thread that encountered this
error, which (I assume) would only be valid/possible thing to do if it
was a user thread that encountered the hardware error.

For example, let's say we encounter an SEA due to a memory error that
was successfully handled by the memory fault handling code (e.g. offline
a page owned by some user application).  Since this is a synchronous
error that may have occurred either on a load, store, or instruction
fetch, the SEA handler must also know to kill the user thread that
encountered that hardware error.  It is not clear to me how we do that
cleanly, and what the repercussions would be. Would it get handled
naturally after the page has become invalid (e.g. it would just result
in a translation fault when attempting to continue the thread, existing
kernel software error handling takes it from there)?

Also, keep in mind that our current assumption is that *all* kernel data
and threads should be considered critical, and any
corruption/termination of kernel data/threads should always be treated
as fatal.  Please let us know if you disagree.

Harb
-- 
Qualcomm Technologies, Inc.
on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From harba at codeaurora.org  Wed Feb 10 19:03:54 2016
From: harba at codeaurora.org (Abdulhamid, Harb)
Date: Wed, 10 Feb 2016 22:03:54 -0500
Subject: [PATCH V1 5/6] arm64: exception: handle instruction abort at
 current EL
In-Reply-To: <20160210180210.GT1052@arm.com>
References: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
 <1454699608-22760-6-git-send-email-tbaicar@codeaurora.org>
 <20160210180210.GT1052@arm.com>
Message-ID: <56BBFA1A.7000100@codeaurora.org>

On 2/10/2016 1:02 PM, Will Deacon wrote:
> On Fri, Feb 05, 2016 at 12:13:27PM -0700, Tyler Baicar wrote:
>> Add a handler for instruction aborts at the current EL
>> (ESR_ELx_EC_IABT_CUR) so they are no longer handled in el1_inv.
>> This allows firmware first handling for possible SEA
>> (Synchronous External Abort) caused instruction abort at
>> current EL.
>>
>> Signed-off-by: Tyler Baicar <tbaicar at codeaurora.org>
>> Signed-off-by: Naveen Kaje <nkaje at codeaurora.org>
>> ---
>>  arch/arm64/kernel/entry.S | 19 +++++++++++++++++++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>> index 1f7f5a2..6b7fb14 100644
>> --- a/arch/arm64/kernel/entry.S
>> +++ b/arch/arm64/kernel/entry.S
>> @@ -336,6 +336,8 @@ el1_sync:
>>  	lsr	x24, x1, #ESR_ELx_EC_SHIFT	// exception class
>>  	cmp	x24, #ESR_ELx_EC_DABT_CUR	// data abort in EL1
>>  	b.eq	el1_da
>> +	cmp	x24, #ESR_ELx_EC_IABT_CUR	// instruction abort in EL1
>> +	b.eq	el1_ia
>>  	cmp	x24, #ESR_ELx_EC_SYS64		// configurable trap
>>  	b.eq	el1_undef
>>  	cmp	x24, #ESR_ELx_EC_SP_ALIGN	// stack alignment exception
>> @@ -363,6 +365,23 @@ el1_da:
>>  	// disable interrupts before pulling preserved data off the stack
>>  	disable_irq
>>  	kernel_exit 1
>> +el1_ia:
>> +	/*
>> +	 * Instruction abort handling
>> +	 */
>> +	mrs	x0, far_el1
>> +	enable_dbg
>> +	// re-enable interrupts if they were enabled in the aborted context
>> +	tbnz	x23, #7, 1f			// PSR_I_BIT
>> +	enable_irq
>> +1:
>> +	orr	x1, x1, #1 << 24		// use reserved ISS bit for instruction aborts
> 
> Do we actually need to set this bit (ESR_LNX_EXEC) for aborts from EL1?
> If not, could we just use the same entry code as el1_da?
> 
This is based on what you already do in el0_ia, so the assumption was
that it would be necessary for el1_ia.  Here is an example call flow to
help illustrate why I think this would be needed:
--> el1_ia
  --> do_mem_abort(): determines its a translation fault
    --> do_page_fault(): sets VM_EXEC in vm_flags based on ESR_LNX_EXEC

I admit that I have no idea how the VM_EXEC flag would be used later on
in the guts of the kernel page fault handling code, but we assumed there
is some need to differentiate between instruction and data faults based
on the existence of this flag.

Are you suggesting that this flag does not get used, or is it not really
needed?  If you think this flag adds no value, then we'll do whatever
you suggest.

Harb
-- 
Qualcomm Technologies, Inc.
on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From harba at codeaurora.org  Wed Feb 10 19:22:00 2016
From: harba at codeaurora.org (Abdulhamid, Harb)
Date: Wed, 10 Feb 2016 22:22:00 -0500
Subject: [PATCH V1 6/6] acpi: apei: handle SEA notification type for ARMv8
In-Reply-To: <20160210180332.GU1052@arm.com>
References: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
 <1454699608-22760-7-git-send-email-tbaicar@codeaurora.org>
 <20160210180332.GU1052@arm.com>
Message-ID: <56BBFE58.7020007@codeaurora.org>

On 2/10/2016 1:03 PM, Will Deacon wrote:
> On Fri, Feb 05, 2016 at 12:13:28PM -0700, Tyler Baicar wrote:

>> +#else /* CONFIG_HAVE_ACPI_APEI_SEA */
>> +static inline int ghes_sea_add(struct ghes *ghes)
>> +{
>> +	pr_err(GHES_PFX "ID: %d, trying to add SEA notification which is not supported\n",
>> +	       ghes->generic->header.source_id);
>> +	return -ENOTSUPP;
>> +}
>> +
>> +static inline void ghes_sea_remove(struct ghes *ghes)
>> +{
>> +	pr_err(GHES_PFX "ID: %d, trying to remove SEA notification which is not supported\n",
>> +	       ghes->generic->header.source_id);
>> +}
> 
> Why are these getting called if !CONFIG_HAVE_ACPI_APEI_SEA?
> 
This was added to catch firmware bugs (i.e. bad ACPI tables).  Since
"SEA" is a valid GHES notify type in ACPI, it's just a number in an ACPI
table.  If someone incorrectly set SEA as their notify type in their
HEST table on an Intel system, this would catch that error here.

We may do this with less code by getting rid of the #else (as you
suggest), but we need to add #ifdefs to eliminate the calls to
ghes_sea_add and ghes_sea_remove to avoid compiler errors.  Does the
below change look better?

>>@@ -1093,6 +1168,11 @@ static int ghes_probe(struct platform_device
>>*ghes_dev)
>> 		list_add_rcu(&ghes->list, &ghes_sci);
>> 		mutex_unlock(&ghes_list_mutex);
>> 		break;
>>

+#ifdef CONFIG_HAVE_ACPI_APEI_SEA

>>+	case ACPI_HEST_NOTIFY_SEA:
>>+		rc = ghes_sea_add(ghes);
>>+		if (rc)
>>+			goto err_edac_unreg;
>>+		break;

+#endif

...

>>@@ -1135,6 +1215,9 @@ static int ghes_remove(struct platform_device
>>*ghes_dev)
>> 			>>unregister_acpi_hed_notifier(&ghes_notifier_sci);
>> 		mutex_unlock(&ghes_list_mutex);
>> 		break;


+#ifdef CONFIG_HAVE_ACPI_APEI_SEA

>>+	case ACPI_HEST_NOTIFY_SEA:
>>+		ghes_sea_remove(ghes);
>>+		break;

+#endif

Harb
-- 
Qualcomm Technologies, Inc.
on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From linux at roeck-us.net  Wed Feb 10 19:38:19 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Wed, 10 Feb 2016 19:38:19 -0800
Subject: [PATCH] tty/serial: digicolor: Fix bad usage of IS_ERR_VALUE
In-Reply-To: <2606061.l722KO95iI@wuerfel>
References: <1455030539-10798-1-git-send-email-linux@roeck-us.net>
 <4571887.rTPndCnv20@wuerfel> <56BAA27A.9050605@roeck-us.net>
 <2606061.l722KO95iI@wuerfel>
Message-ID: <56BC022B.7030004@roeck-us.net>

On 02/10/2016 07:21 AM, Arnd Bergmann wrote:
> On Tuesday 09 February 2016 18:37:46 Guenter Roeck wrote:
>> On 02/09/2016 07:26 AM, Arnd Bergmann wrote:
>>> On Tuesday 09 February 2016 07:08:59 Guenter Roeck wrote:
>>>> IS_ERR_VALUE() assumes that its parameter is an unsigned long.
>>>> It can not be used to check if an unsigned int reflects an error.
>>>> Doing so can result in the following build warning.
>>>>
>>>> drivers/tty/serial/digicolor-usart.c: In function ?digicolor_uart_probe?:
>>>> include/linux/err.h:21:38: warning:
>>>>           comparison is always false due to limited range of data type
>>>> drivers/tty/serial/digicolor-usart.c:485:6: note:
>>>>           in expansion of macro ?IS_ERR_VALUE?
>>>>
>>>> If that warning is seen, an error return from platform_get_irq() is missed.
>>>>
>>>>
>>>
>>> The patch looks correct to me, but what compiler version and which kernel
>>> tree is it that triggered the warning?
>>>
>>> Andrzej Hajda just modified the definition of IS_ERR_VALUE(), and the
>>> changes are still under discussion, but I don't see that warning with
>>> any of the versions.
>>>
>> I see it with gcc 5.1 and 5.2 (and W=1). I did not see / notice Andrzej's patch.
>>
>> I agree that fixing the problem in IS_ERR_VALUE() is preferrable.
>>
>>
>
> Ah, W=1 explains it. We are still debating about the proper solution. Al Viro
> pointed out that most users of IS_ERR_VALUE() shouldn't be using it at all,
> so your patch is probably best here after all.
>

Yes, after looking into it some more I agree. Coccinelle should be able to handle
most of the conversions automatically. I actually tried to write a script, just
for the fun of it, but it misses some of the problem cases in patch mode.
Maybe I get it working tonight.

Guenter



From Suravee.Suthikulpanit at amd.com  Wed Feb 10 19:50:59 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Wed, 10 Feb 2016 21:50:59 -0600
Subject: [PATCH V3 00/12] dtb: amd: Miscellaneous Updates for AMD Seattle DTS
Message-ID: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

This patch series contains several updates for the AMD Seattle SOC DTS files.
It also adds new board files for newer Overdrive and Linaro 96boards (Husky)
platforms.

Olof,

You mentioned that you have already applied the V2 of the series
to next/dt64. Do you think we can just take the V3 instead if we don't
have any other issues/concerns?

Thanks,
Suravee

Changes from V2 (https://lkml.org/lkml/2016/2/8/692):
  * Remove KCS interrupt name (per Arnd's suggestion)
  * Fix ccn node address (per Arnd's suggestion)
  * Add more description in git commit message for patch 3/12
    (per Arnd's suggestion) 

Changes from V1 (https://lkml.org/lkml/2016/1/27/1251):
  * Fix duplication in MAINTAINERS file (per Martin review comment)
  * Remove the PCIe SMMU device tree node for now to rework
    (based on the discussion in the thread).

Brijesh Singh (2):
  dtb: amd: Fix GICv2 hypervisor and virtual interface sizes
  dtb: amd: Add KCS device tree node

Suravee Suthikulpanit (9):
  MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree
  dtb: amd: Fix DMA ranges of smb0 and pcie0
  dtb: amd: Fix typo in SPI device nodes
  dtb: amd: Misc changes for I2C device nodes
  dtb: amd: Misc changes for SATA device tree nodes
  dtb: amd: Misc changes for GPIO devices
  dtb: amd: Add PERF CCN-504 device tree node
  dtb: amd: Add support for new AMD Overdrive boards
  dtb: amd: Add support for AMD/Linaro 96Boards Enterprise Edition
    Server board

Tom Lendacky (1):
  dtb: amd: Add AMD XGBE device tree file

 MAINTAINERS                                      |   8 ++
 arch/arm64/boot/dts/amd/Makefile                 |   4 +-
 arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts |  87 +++++++++++++++++
 arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts |  91 ++++++++++++++++++
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi     | 104 +++++++++++++++++---
 arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi  | 117 +++++++++++++++++++++++
 arch/arm64/boot/dts/amd/husky.dts                |  83 ++++++++++++++++
 7 files changed, 480 insertions(+), 14 deletions(-)
 create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts
 create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts
 create mode 100644 arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi
 create mode 100644 arch/arm64/boot/dts/amd/husky.dts

-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Wed Feb 10 19:51:00 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Wed, 10 Feb 2016 21:51:00 -0600
Subject: [PATCH V3 01/12] MAINTAINERS: Adding Maintainers for AMD Seattle
 Device Tree
In-Reply-To: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1455162671-16044-2-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Adding maintainers for AMD Seattle device tree.

Signed-off-by: Brijesh Singh <brijeshkumar.singh at amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com>
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7f1fa4f..e349a32 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -673,6 +673,13 @@ F:	drivers/gpu/drm/radeon/radeon_kfd.c
 F:	drivers/gpu/drm/radeon/radeon_kfd.h
 F:	include/uapi/linux/kfd_ioctl.h
 
+AMD SEATTLE DEVICE TREE SUPPORT
+M:	Brijesh Singh <brijeshkumar.singh at amd.com>
+M:	Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
+M:	Tom Lendacky <thomas.lendacky at amd.com>
+S:	Supported
+F:	arch/arm64/boot/dts/amd/
+
 AMD XGBE DRIVER
 M:	Tom Lendacky <thomas.lendacky at amd.com>
 L:	netdev at vger.kernel.org
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Wed Feb 10 19:51:01 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Wed, 10 Feb 2016 21:51:01 -0600
Subject: [PATCH V3 02/12] dtb: amd: Fix GICv2 hypervisor and virtual interface
 sizes
In-Reply-To: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1455162671-16044-3-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Brijesh Singh <brijeshkumar.singh at amd.com>

This patch fixes incorrect sizes of the GICv2 device tree node.
This has triggered error message when booting Xen hypervisor.

Signed-off-by: Brijesh Singh <brijeshkumar.singh at amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 2874d92..fdd0c96 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -18,8 +18,8 @@
 		#size-cells = <2>;
 		reg = <0x0 0xe1110000 0 0x1000>,
 		      <0x0 0xe112f000 0 0x2000>,
-		      <0x0 0xe1140000 0 0x10000>,
-		      <0x0 0xe1160000 0 0x10000>;
+		      <0x0 0xe1140000 0 0x2000>,
+		      <0x0 0xe1160000 0 0x2000>;
 		interrupts = <1 9 0xf04>;
 		ranges = <0 0 0 0xe1100000 0 0x100000>;
 		v2m0: v2m at e0080000 {
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Wed Feb 10 19:51:02 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Wed, 10 Feb 2016 21:51:02 -0600
Subject: [PATCH V3 03/12] dtb: amd: Fix DMA ranges of smb0 and pcie0
In-Reply-To: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1455162671-16044-4-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Since GICv2m MSI frame is also considered DMA-able, we should also
include this range in the dma-range DT property as well. Therefore,
this patch fixes the smb0 and pcie0 dma-range properties.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index fdd0c96..5c73117 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -55,8 +55,12 @@
 		#size-cells = <2>;
 		ranges;
 
-		/* DDR range is 40-bit addressing */
-		dma-ranges = <0x80 0x0 0x80 0x0 0x7f 0xffffffff>;
+		/*
+		 * dma-ranges is 40-bit address space containing:
+		 * - GICv2m MSI register is at 0xe0080000
+		 * - DRAM range [0x8000000000 to 0xffffffffff]
+		 */
+		dma-ranges = <0x0 0x0 0x0 0x0 0x100 0x0>;
 
 		/include/ "amd-seattle-clks.dtsi"
 
@@ -159,7 +163,7 @@
 				<0x1000 0x0 0x0 0x4 &gic0 0x0 0x0 0x0 0x123 0x1>;
 
 			dma-coherent;
-			dma-ranges = <0x43000000 0x80 0x0 0x80 0x0 0x7f 0xffffffff>;
+			dma-ranges = <0x43000000 0x0 0x0 0x0 0x0 0x100 0x0>;
 			ranges =
 				/* I/O Memory (size=64K) */
 				<0x01000000 0x00 0x00000000 0x00 0xefff0000 0x00 0x00010000>,
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Wed Feb 10 19:51:03 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Wed, 10 Feb 2016 21:51:03 -0600
Subject: [PATCH V3 04/12] dtb: amd: Fix typo in SPI device nodes
In-Reply-To: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1455162671-16044-5-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Remove invalid entry in the SPI device nodes.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 5c73117..c7c759a 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -91,7 +91,6 @@
 		spi0: ssp at e1020000 {
 			status = "disabled";
 			compatible = "arm,pl022", "arm,primecell";
-			#gpio-cells = <2>;
 			reg = <0 0xe1020000 0 0x1000>;
 			spi-controller;
 			interrupts = <0 330 4>;
@@ -102,7 +101,6 @@
 		spi1: ssp at e1030000 {
 			status = "disabled";
 			compatible = "arm,pl022", "arm,primecell";
-			#gpio-cells = <2>;
 			reg = <0 0xe1030000 0 0x1000>;
 			spi-controller;
 			interrupts = <0 329 4>;
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Wed Feb 10 19:51:04 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Wed, 10 Feb 2016 21:51:04 -0600
Subject: [PATCH V3 05/12] dtb: amd: Misc changes for I2C device nodes
In-Reply-To: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1455162671-16044-6-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Add new i2c1 device node, and fix the incorrect clock frequency.

Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index c7c759a..4be36fd 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -77,7 +77,15 @@
 			compatible = "snps,designware-i2c";
 			reg = <0 0xe1000000 0 0x1000>;
 			interrupts = <0 357 4>;
-			clocks = <&uartspiclk_100mhz>;
+			clocks = <&miscclk_250mhz>;
+		};
+
+		i2c1: i2c at e0050000 {
+			status = "disabled";
+			compatible = "snps,designware-i2c";
+			reg = <0 0xe0050000 0 0x1000>;
+			interrupts = <0 340 4>;
+			clocks = <&miscclk_250mhz>;
 		};
 
 		serial0: serial at e1010000 {
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Wed Feb 10 19:51:05 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Wed, 10 Feb 2016 21:51:05 -0600
Subject: [PATCH V3 06/12] dtb: amd: Misc changes for SATA device tree nodes
In-Reply-To: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1455162671-16044-7-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Add new SATA1 device node, and fix the register range size of SATA0.

Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 4be36fd..9f59381 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -66,12 +66,22 @@
 
 		sata0: sata at e0300000 {
 			compatible = "snps,dwc-ahci";
-			reg = <0 0xe0300000 0 0x800>;
+			reg = <0 0xe0300000 0 0xf0000>;
 			interrupts = <0 355 4>;
 			clocks = <&sataclk_333mhz>;
 			dma-coherent;
 		};
 
+		/* This is for Rev B only */
+		sata1: sata at e0d00000 {
+			status = "disabled";
+			compatible = "snps,dwc-ahci";
+			reg = <0 0xe0d00000 0 0xf0000>;
+			interrupts = <0 354 4>;
+			clocks = <&sataclk_333mhz>;
+			dma-coherent;
+		};
+
 		i2c0: i2c at e1000000 {
 			status = "disabled";
 			compatible = "snps,designware-i2c";
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Wed Feb 10 19:51:06 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Wed, 10 Feb 2016 21:51:06 -0600
Subject: [PATCH V3 07/12] dtb: amd: Misc changes for GPIO devices
In-Reply-To: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1455162671-16044-8-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Add new GPIO device nodes and fix clock on gpio0.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 49 +++++++++++++++++++++++++---
 1 file changed, 45 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 9f59381..ba455d1 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -129,7 +129,7 @@
 			#size-cells = <0>;
 		};
 
-		gpio0: gpio at e1040000 {
+		gpio0: gpio at e1040000 { /* Not available to OS for B0 */
 			status = "disabled";
 			compatible = "arm,pl061", "arm,primecell";
 			#gpio-cells = <2>;
@@ -138,18 +138,59 @@
 			interrupts = <0 359 4>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
-			clocks = <&uartspiclk_100mhz>;
+			clocks = <&miscclk_250mhz>;
 			clock-names = "apb_pclk";
 		};
 
-		gpio1: gpio at e1050000 {
+		gpio1: gpio at e1050000 { /* [0:7] */
 			status = "disabled";
 			compatible = "arm,pl061", "arm,primecell";
 			#gpio-cells = <2>;
 			reg = <0 0xe1050000 0 0x1000>;
 			gpio-controller;
+			interrupt-controller;
+			#interrupt-cells = <2>;
 			interrupts = <0 358 4>;
-			clocks = <&uartspiclk_100mhz>;
+			clocks = <&miscclk_250mhz>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio2: gpio at e0020000 { /* [8:15] */
+			status = "disabled";
+			compatible = "arm,pl061", "arm,primecell";
+			#gpio-cells = <2>;
+			reg = <0 0xe0020000 0 0x1000>;
+			gpio-controller;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			interrupts = <0 366 4>;
+			clocks = <&miscclk_250mhz>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio3: gpio at e0030000 { /* [16:23] */
+			status = "disabled";
+			compatible = "arm,pl061", "arm,primecell";
+			#gpio-cells = <2>;
+			reg = <0 0xe0030000 0 0x1000>;
+			gpio-controller;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			interrupts = <0 365 4>;
+			clocks = <&miscclk_250mhz>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio4: gpio at e0080000 { /* [24] */
+			status = "disabled";
+			compatible = "arm,pl061", "arm,primecell";
+			#gpio-cells = <2>;
+			reg = <0 0xe0080000 0 0x1000>;
+			gpio-controller;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			interrupts = <0 361 4>;
+			clocks = <&miscclk_250mhz>;
 			clock-names = "apb_pclk";
 		};
 
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Wed Feb 10 19:51:07 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Wed, 10 Feb 2016 21:51:07 -0600
Subject: [PATCH V3 08/12] dtb: amd: Add PERF CCN-504 device tree node
In-Reply-To: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1455162671-16044-9-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Add PERF CCN-504 device tree node.

Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index ba455d1..70f407d 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -229,5 +229,12 @@
 				/* 64-bit MMIO (size= 124G) */
 				<0x03000000 0x01 0x00000000 0x01 0x00000000 0x7f 0x00000000>;
 		};
+
+		/* Perf CCN504 PMU */
+		ccn: ccn at e8000000 {
+			compatible = "arm,ccn-504";
+			reg = <0x0 0xe8000000 0 0x1000000>;
+			interrupts = <0 380 4>;
+		};
 	};
 };
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Wed Feb 10 19:51:08 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Wed, 10 Feb 2016 21:51:08 -0600
Subject: [PATCH V3 09/12] dtb: amd: Add KCS device tree node
In-Reply-To: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1455162671-16044-10-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Brijesh Singh <brijeshkumar.singh at amd.com>

Add KCS device node to support IPMI solution on Overdrive
system.

Signed-off-by: Brijesh Singh <brijeshkumar.singh at amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 70f407d..bd3adea 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -236,5 +236,15 @@
 			reg = <0x0 0xe8000000 0 0x1000000>;
 			interrupts = <0 380 4>;
 		};
+
+		ipmi_kcs: kcs at e0010000 {
+			status = "disabled";
+			compatible = "ipmi-kcs";
+			device_type = "ipmi";
+			reg = <0x0 0xe0010000 0 0x8>;
+			interrupts = <0 389 4>;
+			reg-size = <1>;
+			reg-spacing = <4>;
+		};
 	};
 };
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Wed Feb 10 19:51:09 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Wed, 10 Feb 2016 21:51:09 -0600
Subject: [PATCH V3 10/12] dtb: amd: Add AMD XGBE device tree file
In-Reply-To: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1455162671-16044-11-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Tom Lendacky <thomas.lendacky at amd.com>

Add AMD XGBE device tree file, which is available in AMD Seattle RevB.

Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com>
---
 MAINTAINERS                                     |   1 +
 arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi | 117 ++++++++++++++++++++++++
 2 files changed, 118 insertions(+)
 create mode 100644 arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi

diff --git a/MAINTAINERS b/MAINTAINERS
index e349a32..9547a68 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -685,6 +685,7 @@ M:	Tom Lendacky <thomas.lendacky at amd.com>
 L:	netdev at vger.kernel.org
 S:	Supported
 F:	drivers/net/ethernet/amd/xgbe/
+F:	arch/arm64/boot/dts/amd/amd-seattle-xgbe*.dtsi
 
 AMS (Apple Motion Sensor) DRIVER
 M:	Michael Hanselmann <linux-kernel at hansmi.ch>
diff --git a/arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi
new file mode 100644
index 0000000..8e86319
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/amd-seattle-xgbe-b.dtsi
@@ -0,0 +1,117 @@
+/*
+ * DTS file for AMD Seattle XGBE (RevB)
+ *
+ * Copyright (C) 2015 Advanced Micro Devices, Inc.
+ */
+
+	xgmacclk0_dma_250mhz: clk250mhz_0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <250000000>;
+		clock-output-names = "xgmacclk0_dma_250mhz";
+	};
+
+	xgmacclk0_ptp_250mhz: clk250mhz_1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <250000000>;
+		clock-output-names = "xgmacclk0_ptp_250mhz";
+	};
+
+	xgmacclk1_dma_250mhz: clk250mhz_2 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <250000000>;
+		clock-output-names = "xgmacclk1_dma_250mhz";
+	};
+
+	xgmacclk1_ptp_250mhz: clk250mhz_3 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <250000000>;
+		clock-output-names = "xgmacclk1_ptp_250mhz";
+	};
+
+	xgmac0: xgmac at e0700000 {
+		compatible = "amd,xgbe-seattle-v1a";
+		reg = <0 0xe0700000 0 0x80000>,
+		      <0 0xe0780000 0 0x80000>,
+		      <0 0xe1240800 0 0x00400>, /* SERDES RX/TX0 */
+		      <0 0xe1250000 0 0x00060>, /* SERDES IR 1/2 */
+		      <0 0xe12500f8 0 0x00004>; /* SERDES IR 2/2 */
+		interrupts = <0 325 4>,
+			     <0 346 1>, <0 347 1>, <0 348 1>, <0 349 1>,
+			     <0 323 4>;
+		amd,per-channel-interrupt;
+		amd,speed-set = <0>;
+		amd,serdes-blwc = <1>, <1>, <0>;
+		amd,serdes-cdr-rate = <2>, <2>, <7>;
+		amd,serdes-pq-skew = <10>, <10>, <18>;
+		amd,serdes-tx-amp = <0>, <0>, <0>;
+		amd,serdes-dfe-tap-config = <3>, <3>, <3>;
+		amd,serdes-dfe-tap-enable = <0>, <0>, <7>;
+		mac-address = [ 02 A1 A2 A3 A4 A5 ];
+		clocks = <&xgmacclk0_dma_250mhz>, <&xgmacclk0_ptp_250mhz>;
+		clock-names = "dma_clk", "ptp_clk";
+		phy-mode = "xgmii";
+		#stream-id-cells = <16>;
+		dma-coherent;
+	};
+
+	xgmac1: xgmac at e0900000 {
+		compatible = "amd,xgbe-seattle-v1a";
+		reg = <0 0xe0900000 0 0x80000>,
+		      <0 0xe0980000 0 0x80000>,
+		      <0 0xe1240c00 0 0x00400>, /* SERDES RX/TX1 */
+		      <0 0xe1250080 0 0x00060>, /* SERDES IR 1/2 */
+		      <0 0xe12500fc 0 0x00004>; /* SERDES IR 2/2 */
+		interrupts = <0 324 4>,
+			     <0 341 1>, <0 342 1>, <0 343 1>, <0 344 1>,
+			     <0 322 4>;
+		amd,per-channel-interrupt;
+		amd,speed-set = <0>;
+		amd,serdes-blwc = <1>, <1>, <0>;
+		amd,serdes-cdr-rate = <2>, <2>, <7>;
+		amd,serdes-pq-skew = <10>, <10>, <18>;
+		amd,serdes-tx-amp = <0>, <0>, <0>;
+		amd,serdes-dfe-tap-config = <3>, <3>, <3>;
+		amd,serdes-dfe-tap-enable = <0>, <0>, <7>;
+		mac-address = [ 02 B1 B2 B3 B4 B5 ];
+		clocks = <&xgmacclk1_dma_250mhz>, <&xgmacclk1_ptp_250mhz>;
+		clock-names = "dma_clk", "ptp_clk";
+		phy-mode = "xgmii";
+		#stream-id-cells = <16>;
+		dma-coherent;
+	};
+
+	xgmac0_smmu: smmu at e0600000 {
+		 compatible = "arm,mmu-401";
+		 reg = <0 0xe0600000 0 0x10000>;
+		 #global-interrupts = <1>;
+		 interrupts = /* Uses combined intr for both
+			       * global and context
+			       */
+			      <0 336 4>,
+			      <0 336 4>;
+
+		 mmu-masters = <&xgmac0
+			  0  1  2  3  4  5  6  7
+			 16 17 18 19 20 21 22 23
+		 >;
+	 };
+
+	 xgmac1_smmu: smmu at e0800000 {
+		 compatible = "arm,mmu-401";
+		 reg = <0 0xe0800000 0 0x10000>;
+		 #global-interrupts = <1>;
+		 interrupts = /* Uses combined intr for both
+			       * global and context
+			       */
+			      <0 335 4>,
+			      <0 335 4>;
+
+		 mmu-masters = <&xgmac1
+			  0  1  2  3  4  5  6  7
+			 16 17 18 19 20 21 22 23
+		 >;
+	 };
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Wed Feb 10 19:51:10 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Wed, 10 Feb 2016 21:51:10 -0600
Subject: [PATCH V3 11/12] dtb: amd: Add support for new AMD Overdrive boards
In-Reply-To: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1455162671-16044-12-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Add device tree files for AMD Overdrive boards which comes with
AMD Seattle Revision B0 and B1 SOCs.

Signed-off-by: Tom Lendacky <thomas.lendacky at amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/Makefile                 |  3 +-
 arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts | 87 ++++++++++++++++++++++
 arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts | 91 ++++++++++++++++++++++++
 3 files changed, 180 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts
 create mode 100644 arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts

diff --git a/arch/arm64/boot/dts/amd/Makefile b/arch/arm64/boot/dts/amd/Makefile
index cfdf701..db03293 100644
--- a/arch/arm64/boot/dts/amd/Makefile
+++ b/arch/arm64/boot/dts/amd/Makefile
@@ -1,4 +1,5 @@
-dtb-$(CONFIG_ARCH_SEATTLE) += amd-overdrive.dtb
+dtb-$(CONFIG_ARCH_SEATTLE) += amd-overdrive.dtb \
+			amd-overdrive-rev-b0.dtb amd-overdrive-rev-b1.dtb
 
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
diff --git a/arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts b/arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts
new file mode 100644
index 0000000..8e3074a
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/amd-overdrive-rev-b0.dts
@@ -0,0 +1,87 @@
+/*
+ * DTS file for AMD Seattle Overdrive Development Board
+ * Note: For Seattle Rev.B0
+ *
+ * Copyright (C) 2015 Advanced Micro Devices, Inc.
+ */
+
+/dts-v1/;
+
+/include/ "amd-seattle-soc.dtsi"
+
+/ {
+	model = "AMD Seattle (Rev.B0) Development Board (Overdrive)";
+	compatible = "amd,seattle-overdrive", "amd,seattle";
+
+	chosen {
+		stdout-path = &serial0;
+	};
+
+	psci {
+		compatible   = "arm,psci-0.2";
+		method       = "smc";
+	};
+};
+
+&ccp0 {
+	status = "ok";
+	amd,zlib-support = <1>;
+};
+
+/**
+ * NOTE: In Rev.B, gpio0 is reserved.
+ */
+&gpio1 {
+	status = "ok";
+};
+
+&gpio2 {
+	status = "ok";
+};
+
+&gpio3 {
+	status = "ok";
+};
+
+&gpio4 {
+	status = "ok";
+};
+
+&i2c0 {
+	status = "ok";
+};
+
+&i2c1 {
+	status = "ok";
+};
+
+&pcie0 {
+	status = "ok";
+};
+
+&spi0 {
+	status = "ok";
+};
+
+&spi1 {
+	status = "ok";
+	sdcard0: sdcard at 0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		spi-max-frequency = <20000000>;
+		voltage-ranges = <3200 3400>;
+		pl022,hierarchy = <0>;
+		pl022,interface = <0>;
+		pl022,com-mode = <0x0>;
+		pl022,rx-level-trig = <0>;
+		pl022,tx-level-trig = <0>;
+	};
+};
+
+&ipmi_kcs {
+	status = "ok";
+};
+
+&smb0 {
+	/include/ "amd-seattle-xgbe-b.dtsi"
+};
diff --git a/arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts b/arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts
new file mode 100644
index 0000000..ed5e043
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/amd-overdrive-rev-b1.dts
@@ -0,0 +1,91 @@
+/*
+ * DTS file for AMD Seattle Overdrive Development Board
+ * Note: For Seattle Rev.B1
+ *
+ * Copyright (C) 2015 Advanced Micro Devices, Inc.
+ */
+
+/dts-v1/;
+
+/include/ "amd-seattle-soc.dtsi"
+
+/ {
+	model = "AMD Seattle (Rev.B1) Development Board (Overdrive)";
+	compatible = "amd,seattle-overdrive", "amd,seattle";
+
+	chosen {
+		stdout-path = &serial0;
+	};
+
+	psci {
+		compatible   = "arm,psci-0.2";
+		method       = "smc";
+	};
+};
+
+&ccp0 {
+	status = "ok";
+	amd,zlib-support = <1>;
+};
+
+/**
+ * NOTE: In Rev.B, gpio0 is reserved.
+ */
+&gpio1 {
+	status = "ok";
+};
+
+&gpio2 {
+	status = "ok";
+};
+
+&gpio3 {
+	status = "ok";
+};
+
+&gpio4 {
+	status = "ok";
+};
+
+&i2c0 {
+	status = "ok";
+};
+
+&i2c1 {
+	status = "ok";
+};
+
+&pcie0 {
+	status = "ok";
+};
+
+&sata1 {
+	status = "ok";
+};
+
+&spi0 {
+	status = "ok";
+};
+
+&spi1 {
+	status = "ok";
+	sdcard0: sdcard at 0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		spi-max-frequency = <20000000>;
+		voltage-ranges = <3200 3400>;
+		pl022,hierarchy = <0>;
+		pl022,interface = <0>;
+		pl022,com-mode = <0x0>;
+		pl022,rx-level-trig = <0>;
+		pl022,tx-level-trig = <0>;
+	};
+};
+
+&ipmi_kcs {
+	status = "ok";
+};
+
+&smb0 {
+	/include/ "amd-seattle-xgbe-b.dtsi"
+};
-- 
2.5.0



From Suravee.Suthikulpanit at amd.com  Wed Feb 10 19:51:11 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Wed, 10 Feb 2016 21:51:11 -0600
Subject: [PATCH V3 12/12] dtb: amd: Add support for AMD/Linaro 96Boards
 Enterprise Edition Server board
In-Reply-To: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1455162671-16044-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <1455162671-16044-13-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Add device tree file for AMD/Linaro 96Boards Enterprise Edition Server
(Husky) Board. This is based on the AMD Seattle Rev.B0 system

Signed-off-by: Leo Duran <leo.duran at amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 arch/arm64/boot/dts/amd/Makefile  |  3 +-
 arch/arm64/boot/dts/amd/husky.dts | 83 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 85 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/amd/husky.dts

diff --git a/arch/arm64/boot/dts/amd/Makefile b/arch/arm64/boot/dts/amd/Makefile
index db03293..ba84770 100644
--- a/arch/arm64/boot/dts/amd/Makefile
+++ b/arch/arm64/boot/dts/amd/Makefile
@@ -1,5 +1,6 @@
 dtb-$(CONFIG_ARCH_SEATTLE) += amd-overdrive.dtb \
-			amd-overdrive-rev-b0.dtb amd-overdrive-rev-b1.dtb
+			amd-overdrive-rev-b0.dtb amd-overdrive-rev-b1.dtb \
+			husky.dtb
 
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
diff --git a/arch/arm64/boot/dts/amd/husky.dts b/arch/arm64/boot/dts/amd/husky.dts
new file mode 100644
index 0000000..1381d4b
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/husky.dts
@@ -0,0 +1,83 @@
+/*
+ * DTS file for AMD/Linaro 96Boards Enterprise Edition Server (Husky) Board
+ * Note: Based-on AMD Seattle Rev.B0
+ *
+ * Copyright (C) 2015 Advanced Micro Devices, Inc.
+ */
+
+/dts-v1/;
+
+/include/ "amd-seattle-soc.dtsi"
+
+/ {
+	model = "Linaro 96Boards Enterprise Edition Server (Husky) Board";
+	compatible = "amd,seattle-overdrive", "amd,seattle";
+
+	chosen {
+		stdout-path = &serial0;
+	};
+
+	psci {
+		compatible   = "arm,psci-0.2";
+		method       = "smc";
+	};
+};
+
+&ccp0 {
+	status = "ok";
+	amd,zlib-support = <1>;
+};
+
+/**
+ * NOTE: In Rev.B, gpio0 is reserved.
+ */
+&gpio1 {
+	status = "ok";
+};
+
+&gpio2 {
+	status = "ok";
+};
+
+&gpio3 {
+	status = "ok";
+};
+
+&gpio4 {
+	status = "ok";
+};
+
+&i2c0 {
+	status = "ok";
+};
+
+&i2c1 {
+	status = "ok";
+};
+
+&pcie0 {
+	status = "ok";
+};
+
+&spi0 {
+	status = "ok";
+};
+
+&spi1 {
+	status = "ok";
+	sdcard0: sdcard at 0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		spi-max-frequency = <20000000>;
+		voltage-ranges = <3200 3400>;
+		pl022,hierarchy = <0>;
+		pl022,interface = <0>;
+		pl022,com-mode = <0x0>;
+		pl022,rx-level-trig = <0>;
+		pl022,tx-level-trig = <0>;
+	};
+};
+
+&smb0 {
+	/include/ "amd-seattle-xgbe-b.dtsi"
+};
-- 
2.5.0



From olof at lixom.net  Wed Feb 10 19:55:30 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 10 Feb 2016 19:55:30 -0800
Subject: [GIT PULL] Renesas ARM Based SoC DT Updates for v4.6
In-Reply-To: <20160209183921.GA1089@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
 <20160208215130.GJ25468@localhost>
 <CAMuHMdVWYVEHTvGYEZkEXpEaMzfZ_NfMAb0o8HtVcJM+GDdfmA@mail.gmail.com>
 <20160209183921.GA1089@verge.net.au>
Message-ID: <CAOesGMjeyah0qpwWR=RJOF61dVGGqkxmGUJrE0qYNuCOwoPFjQ@mail.gmail.com>

Hi,

On Tue, Feb 9, 2016 at 10:39 AM, Simon Horman <horms at verge.net.au> wrote:
> On Tue, Feb 09, 2016 at 08:39:31AM +0100, Geert Uytterhoeven wrote:
>> Hi Olof,
>>
>> On Mon, Feb 8, 2016 at 10:51 PM, Olof Johansson <olof at lixom.net> wrote:
>> > On Thu, Feb 04, 2016 at 03:30:02PM +0100, Simon Horman wrote:
>> >> Please consider these Renesas ARM based SoC DT updates for v4.6.
>> >>
>> >>
>> >> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>> >>
>> >>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>> >>
>> >> are available in the git repository at:
>> >>
>> >>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-for-v4.6
>> >>
>> >> for you to fetch changes up to d7a11140d0a659e5c1f83627792f95b6713030a2:
>> >>
>> >>   ARM: dts: silk: Enable SCIF_CLK frequency and pins (2016-02-02 14:02:28 +0100)
>> >>
>> >> ----------------------------------------------------------------
>> >> Renesas ARM Based SoC DT Updates for v4.6
>> >>
>> >> * Use SCIF and USBHS fallback compatibility strings
>> >> * Add Baud Rate Generator (BRG) support for (H)SCIF
>> >> * Enable SCIF_CLK frequency and pins
>> >> * Use GIC_* defines
>> >> * Migrate to generic l2c OF initialization on r8a7740
>> >> * Enable audio on r8a7793/gose
>> >> * Enable HDMI vidio out on r8a7793
>> >> * Enable i2c on r8a7793/gose
>> >> * Enable QSPI on alt
>> >> * Enable GPIO keys and leds on gise
>> >> * Enable audio on porter
>> >> * Enable DU on porter
>> >>
>> >> ----------------------------------------------------------------
>> >> Geert Uytterhoeven (22):
>> >>       ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization
>> >>       ARM: shmobile: r8a7740: Remove mapping of L2 cache controller registers
>> >
>> > Hmm. Those aren't DT changes. There's also nothing for r8a7740 to convert
>> > L2 init to DT earlier in this branch, which makes this look like it's just
>> > a generic cleanup that should go in independently in your cleanup branch.
>> >
>> > Or am I missing some dependency that isn't obvious? If I'm not, then please
>> > respin this branch and move those to the place they belong (cleanup).
>>
>> The dependency is commit 374e70075e58acfe ("ARM: shmobile: r8a7740 dtsi: Add
>> L2 cache-controller node"), which has already entered mainline in v4.5-rc1.
>>
>> So I agree with your comments.
>
> Sorry for the mix-up.
> I'll see about respinning this.

I've merged the patches, so respinning won't work. Instead, please
follow up with incremental fixes instead.


-Olof


From jassisinghbrar at gmail.com  Wed Feb 10 20:23:29 2016
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Thu, 11 Feb 2016 09:53:29 +0530
Subject: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager
In-Reply-To: <20160209181031.GA23603@kahuna>
References: <1454690044-2560-1-git-send-email-nm@ti.com>
 <1454690044-2560-2-git-send-email-nm@ti.com>
 <CABb+yY3kGq_R49Xx4fK3UMqtuFiuv-pXJWvjkEFLPL9xRu5T4A@mail.gmail.com>
 <56B9DC30.5040806@ti.com>
 <CABb+yY24XzsWaSGLMCE4_nvgWx0OhhQmcaP41g06FxdjQYFchg@mail.gmail.com>
 <CAGo_u6qGaQj9Qvjwrm7cD=cr2UjLN+62tcquXYPsQrRjYD=UCw@mail.gmail.com>
 <20160209181031.GA23603@kahuna>
Message-ID: <CABb+yY3nSZCbF7G1LP_7cGkKJpdJ1fko_6d3UkrF_vNpHk4uBg@mail.gmail.com>

On Tue, Feb 9, 2016 at 11:40 PM, Nishanth Menon <nm at ti.com> wrote:
> On 09:43-20160209, Nishanth Menon wrote:
>> On Tue, Feb 9, 2016 at 8:54 AM, Jassi Brar <jassisinghbrar at gmail.com> wrote:
> [..]
>> Let me prototype this as part of of_xlate and see if I can pull the
>> qinst data back out.. obviously one negative will be that I will
>> register *all* valid channels as part of probe.. at least based on
>> initial code i wrote today morning..
>
> OK - I believe I have it working now. How does the following look? If
> this looks fine to you, then I will post a v2 including the driver
> update.
> Changes here:
>         - dropped the generic message-manager compatible
>         - dropped child nodes
>         - moved the valid queue information to driver (no longer in dts)
>         - rx interrupts per SoC are explicitly named list in binding(and
>           dts)
>
> Texas Instruments' Message Manager Driver
> ========================================
>
> The Texas Instruments' Message Manager is a mailbox controller that has
> configurable queues selectable at SoC(System on Chip) integration. The Message
> manager is broken up into queues in different address regions that are called
> "proxies" - each instance is unidirectional and is instantiated at SoC
> integration level to indicate receive or transmit path.
>
> Message Manager Device Node:
> ===========================
> Required properties:
> --------------------
> - compatible:           Shall be: "ti,k2g-message-manager"
> - reg-names             queue_proxy_region - Map the queue proxy region.
>                         queue_state_debug_region - Map the queue state debug
>                         region.
> - reg:                  Contains the register map per reg-names.
> - #mbox-cells           Shall be 2. Contains the queue ID and proxy ID in that
>                         order referring to the transfer path.
> - interrupt-names:      Contains interrupt names matching the rx transfer path
>                         for a given SoC. Receive interrupts shall be of the
>                         format: "rx_<QID>_<PID>".
>                         For ti,k2g-message-manager, this shall contain:
>                                 "rx_005_002", "rx_057_002"
> - interrupts:           Contains the interrupt information corresponding to
>                         interrupt-names property.
>
> Example(K2G):
> ------------
>
>         msgmgr: msgmgr at 02a00000 {
>                 compatible = "ti,k2g-message-manager";
>                 #mbox-cells = <2>;
>                 reg-names = "queue_proxy_region", "queue_state_debug_region";
>                 reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
>                 interrupt-names = "rx_005_002",
>                                   "rx_057_002";
>
Looking at figure in page-1445, it seems QID is the h/w channel id,
while proxy is its programming parameter. So maybe we need to list all
the ARM irq's as a list here, matched only by the qid asked by the
consumer ... assuming no two channels could have the same qid (?).

  interrupt-names = "irq_005", "irq_037", "irq_049", "irq_057",
"perr", "ferr", "eerr";

I may be slightly off, but the idea remains to not have to encode any
consumer specific info in the provider node.

>         pmmc: pmmc {
>                 [...]
>                 mbox-names = "rx", "tx";
>                 # RX queue ID is 5, proxy ID is 2
>                 # TX queue ID is 0, proxy ID is 0
>                 mboxes= <&msgmgr 5 2>,
>                         <&msgmgr 0 0>;
>                 [...]
>         };


From nm at ti.com  Wed Feb 10 21:03:19 2016
From: nm at ti.com (Nishanth Menon)
Date: Wed, 10 Feb 2016 23:03:19 -0600
Subject: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager
In-Reply-To: <CABb+yY3nSZCbF7G1LP_7cGkKJpdJ1fko_6d3UkrF_vNpHk4uBg@mail.gmail.com>
References: <1454690044-2560-1-git-send-email-nm@ti.com>
 <1454690044-2560-2-git-send-email-nm@ti.com>
 <CABb+yY3kGq_R49Xx4fK3UMqtuFiuv-pXJWvjkEFLPL9xRu5T4A@mail.gmail.com>
 <56B9DC30.5040806@ti.com>
 <CABb+yY24XzsWaSGLMCE4_nvgWx0OhhQmcaP41g06FxdjQYFchg@mail.gmail.com>
 <CAGo_u6qGaQj9Qvjwrm7cD=cr2UjLN+62tcquXYPsQrRjYD=UCw@mail.gmail.com>
 <20160209181031.GA23603@kahuna>
 <CABb+yY3nSZCbF7G1LP_7cGkKJpdJ1fko_6d3UkrF_vNpHk4uBg@mail.gmail.com>
Message-ID: <56BC1617.3090204@ti.com>

Hi Jassi,

On 02/10/2016 10:23 PM, Jassi Brar wrote:
[...]


Thanks for taking the time and checking the TRM, I apologize that the
actual details of the hardware block which was supposed to be in
sections 8.1.3 and 8.1.4 has unfortunately been dropped since the last
time I reviewed in the spec Vs what actually went out into public
domain! I do realize the problem of doing a review without comprehensive
and accurate documentation - ugghh.. :(

But, I am trying to get our internal guys to upload the proper TRM
chapter in public domain -> hopefully we will get it done some time soon.


>>         msgmgr: msgmgr at 02a00000 {
>>                 compatible = "ti,k2g-message-manager";
>>                 #mbox-cells = <2>;
>>                 reg-names = "queue_proxy_region", "queue_state_debug_region";
>>                 reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
>>                 interrupt-names = "rx_005_002",
>>                                   "rx_057_002";
>>
> Looking at figure in page-1445, it seems QID is the h/w channel id,
> while proxy is its programming parameter. So maybe we need to list all
> the ARM irq's as a list here, matched only by the qid asked by the
> consumer ... assuming no two channels could have the same qid (?).

The overall story is something like what you already figured out..
message manager has a queue engine and a ram for data buffers, and n
queues. Each of these queues have a memory map corresponding to the
processor view.. we can call that programming paramater as well.

>   interrupt-names = "irq_005", "irq_037", "irq_049", "irq_057",
> "perr", "ferr", "eerr";

proxy error (perr), free index error(ferr) and ECC error(eerr) cannot be
handled by a slave, since it involves controlling a shared register set
for a single message manager instance. in the case of K2G, the master of
the message manager is actually PMMC, and not the compute processors -
it has error handling logic to handle things there - a slave can only
report these errors without ability to even expect reliable detection
(for example PMMC reacting even before any of  these cores have come up
from low power state).

irq_37 and irq_49 go to the secure world and we have no access from ARM
"non secure" world. the "missing documentation" would have helped
clarify that :(..

> 
> I may be slightly off, but the idea remains to not have to encode any
> consumer specific info in the provider node.

I do realize the reasoning behind your suggestion here. the reasoning
for providing rx_qid_pid as the interrupt name was as follows: I was
hoping to get a future SoC to provide proxy specific error instead of a
global error which is really useless since the processor generating
error should be the guy actually be notified.. queue specific interrupts
as well.. the reason for naming interrupts with the proxy id information
was primarily to let the dtb ABI stay compatible with only additional
properties defined when the new SoC gets supported.

I can make it compatible for today's SoC, but based on what i explained,
how about just "rx_<qid>" for the interrupt names?
interrupt-names = "rx_005", "rx_057" (I kinda feel using "irq" for
interrupt-names is actually redundant information)?

*if* i manage to convince to get a new IP with proxy specific
interrupts, then "perr_qid_pid" could then be introduced for that new
compatible type..

[...]
-- 
Regards,
Nishanth Menon


From vigneshr at ti.com  Wed Feb 10 21:33:50 2016
From: vigneshr at ti.com (Vignesh R)
Date: Thu, 11 Feb 2016 11:03:50 +0530
Subject: [PATCH v5 3/5] mtd: devices: m25p80: add support for mmap read
 request
In-Reply-To: <20160209193616.GN13270@sirena.org.uk>
References: <1449807000-6457-1-git-send-email-vigneshr@ti.com>
 <1449807000-6457-4-git-send-email-vigneshr@ti.com>
 <20160209193616.GN13270@sirena.org.uk>
Message-ID: <56BC1D3E.5020203@ti.com>



On 02/10/2016 01:06 AM, Mark Brown wrote:
> On Fri, Dec 11, 2015 at 09:39:58AM +0530, Vignesh R wrote:
> 
>> +	if (spi_flash_read_supported(spi)) {
>> +		struct spi_flash_read_message msg;
>> +		int ret;
>> +
>> +		msg.buf = buf;
>> +		msg.from = from;
>> +		msg.len = len;
>> +		msg.read_opcode = nor->read_opcode;
>> +		msg.addr_width = nor->addr_width;
>> +		msg.dummy_bytes = dummy;
>> +		/* TODO: Support other combinations */
>> +		msg.opcode_nbits = SPI_NBITS_SINGLE;
>> +		msg.addr_nbits = SPI_NBITS_SINGLE;
>> +		msg.data_nbits = m25p80_rx_nbits(nor);
>> +
>> +		ret = spi_flash_read(spi, &msg);
>> +		*retlen = msg.retlen;
>> +		return ret;
> 
> Looking at this I can't help but think that spi_flash_read() ought to
> have the stub in rather than the caller.  But given that we're pretty
> much only ever expecting one user I'm not 100% sure it actually matters.

Well, my initial patch set passed long list of arguments to
spi_flash_read(), but Brian suggested to use struct[1] in order to avoid
unnecessary churn when things need changed in the API.


[1] https://lkml.org/lkml/2015/11/11/454

-- 
Regards
Vignesh


From bharat.kumar.gogada at xilinx.com  Wed Feb 10 21:37:04 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Thu, 11 Feb 2016 05:37:04 +0000
Subject: [PATCH V3 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge
 driver to work on both  Zynq and Microblaze
In-Reply-To: <2818168.2fmZIs86hN@wuerfel>
References: <1455014518-8708-1-git-send-email-bharatku@xilinx.com>
 <8520D5D51A55D047800579B09414719825881780@XAP-PVEXMBX01.xlnx.xilinx.com>
 <20160210172707.GA29590@NP-P-BURTON> <2818168.2fmZIs86hN@wuerfel>
Message-ID: <8520D5D51A55D047800579B09414719825881ACE@XAP-PVEXMBX01.xlnx.xilinx.com>

> Subject: Re: [PATCH V3 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver
> to work on both Zynq and Microblaze
> 
> On Wednesday 10 February 2016 09:27:07 Paul Burton wrote:
> > On Wed, Feb 10, 2016 at 05:55:51AM +0000, Bharat Kumar Gogada wrote:
> > > > On Tue, Feb 09, 2016 at 04:11:56PM +0530, Bharat Kumar Gogada
> wrote:
> > > > > Modifying Xilinx AXI PCIe Host Bridge Soft IP driver to work on
> > > > > both Zynq and Microblaze Architectures.
> > > > > With these modifications drivers/pci/host/pcie-xilinx.c, will
> > > > > work on both Zynq and Microblaze Architectures.
> > > > >
> > > > > Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> > > > > Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
> > > > > ---
> > > > > Changes:
> > > > > Removed unneccessary architecture dependent number of MSI's.
> > > > > Added #ifdef to pci_fixup_irqs which is ARM specific API.
> > > >
> > > > Hi Bharat,
> > > >
> > > > Why do you say pci_fixup_irqs is ARM-specific? It's declared in
> > > > include/linux/pci.h, defined in drivers/pci/setup-irq.c & used by
> > > > multiple architectures (alpha, arm, m68k, mips, sh, sparc, tile,
> > > > unicore32 from a quick grep).
> > > >
> > > > Will you not break INTX-style interrupts by removing this?
> > > >
> > > I meant to say ARM specific w.r.t Microblaze architecture, which is
> > > what this patch series are for. This has been already discussed in
> > > my previous patch by  Arnd Bergmann and Lorenzo Pieralisi .
> > > (https://lkml.org/lkml/2016/1/12/707)
> >
> > Hi Bharat,
> >
> > Ok, so you don't need it for microblaze but do need it for zynq/ARM.
> > We also need it for MIPS, where my recent patches enable this driver.
> > So if #ifdef'ing this is the current way forwards could you please
> > invert the condition to #ifndef CONFIG_MICROBLAZE?
> 
> I think we are getting to the point where we should try much harder to make
> sure nobody needs that hack and it all works out of the box.

Ok I will invert to this condition and resend the patches.

Bharat


From bharat.kumar.gogada at xilinx.com  Wed Feb 10 21:42:30 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Thu, 11 Feb 2016 05:42:30 +0000
Subject: [PATCH v3 2/6] PCI: xilinx: Unify INTx & MSI interrupt FIFO decode
In-Reply-To: <1454602213-967-3-git-send-email-paul.burton@imgtec.com>
References: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>
 <1454602213-967-3-git-send-email-paul.burton@imgtec.com>
Message-ID: <8520D5D51A55D047800579B09414719825881ADE@XAP-PVEXMBX01.xlnx.xilinx.com>

> Subject: [PATCH v3 2/6] PCI: xilinx: Unify INTx & MSI interrupt FIFO decode
> 
> When decoding either an INTx or MSI interrupt, the driver has no way to
> know which it will pull out of the interrupt FIFO. If both were pending then
> this would lead to either the interrupt being handled incorrectly (MSI
> interrupt treated as INTx) or not at all (INTx interrupt dropped by MSI path).
> Unify the reading of the interrupt FIFO & act according to the type of
> interrupt actually read.
> 
> Signed-off-by: Paul Burton <paul.burton at imgtec.com>
> Fixes: 8961def56845 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver")
> 
> ---
> 
> Changes in v3:
> - Split out from Boston patchset.
> 
> Changes in v2:
> - Add Fixes tag.
> 
>  drivers/pci/host/pcie-xilinx.c | 47 +++++++++++++-----------------------------
>  1 file changed, 14 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c index
> 1490bd1..afdfb09 100644
> --- a/drivers/pci/host/pcie-xilinx.c
> +++ b/drivers/pci/host/pcie-xilinx.c
> @@ -397,7 +397,7 @@ static const struct irq_domain_ops intx_domain_ops
> = {  static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)  {
>  	struct xilinx_pcie_port *port = (struct xilinx_pcie_port *)data;
> -	u32 val, mask, status, msi_data;
> +	u32 val, mask, status;
> 
>  	/* Read interrupt decode and mask registers */
>  	val = pcie_read(port, XILINX_PCIE_REG_IDR); @@ -437,8 +437,8 @@
> static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
>  		xilinx_pcie_clear_err_interrupts(port);
>  	}
> 
> -	if (status & XILINX_PCIE_INTR_INTX) {
> -		/* INTx interrupt received */
> +	if (status & (XILINX_PCIE_INTR_INTX | XILINX_PCIE_INTR_MSI)) {
> +		/* Interrupt received */
>  		val = pcie_read(port, XILINX_PCIE_REG_RPIFR1);
> 
>  		/* Check whether interrupt valid */
> @@ -447,41 +447,22 @@ static irqreturn_t xilinx_pcie_intr_handler(int irq,
> void *data)
>  			return IRQ_HANDLED;
>  		}
> 
> -		if (!(val & XILINX_PCIE_RPIFR1_MSI_INTR)) {
> -			/* Clear interrupt FIFO register 1 */
> -			pcie_write(port, XILINX_PCIE_RPIFR1_ALL_MASK,
> -				   XILINX_PCIE_REG_RPIFR1);
> -
> -			/* Handle INTx Interrupt */
> +		if (val & XILINX_PCIE_RPIFR1_MSI_INTR) {
> +			irq = pcie_read(port, XILINX_PCIE_REG_RPIFR2) &
> +				XILINX_PCIE_RPIFR2_MSG_DATA;
> +		} else {
>  			val = ((val & XILINX_PCIE_RPIFR1_INTR_MASK) >>
>  				XILINX_PCIE_RPIFR1_INTR_SHIFT) + 1;
> -			generic_handle_irq(irq_find_mapping(port-
> >irq_domain,
> -							    val));
> +			irq = irq_find_mapping(port->irq_domain, val);
>  		}
> -	}
> 
> -	if (status & XILINX_PCIE_INTR_MSI) {
> -		/* MSI Interrupt */
> -		val = pcie_read(port, XILINX_PCIE_REG_RPIFR1);
> +		/* Clear interrupt FIFO register 1 */
> +		pcie_write(port, XILINX_PCIE_RPIFR1_ALL_MASK,
> +			   XILINX_PCIE_REG_RPIFR1);
> 
> -		if (!(val & XILINX_PCIE_RPIFR1_INTR_VALID)) {
> -			dev_warn(port->dev, "RP Intr FIFO1 read error\n");
> -			return IRQ_HANDLED;
> -		}
> -
> -		if (val & XILINX_PCIE_RPIFR1_MSI_INTR) {
> -			msi_data = pcie_read(port,
> XILINX_PCIE_REG_RPIFR2) &
> -				   XILINX_PCIE_RPIFR2_MSG_DATA;
> -
> -			/* Clear interrupt FIFO register 1 */
> -			pcie_write(port, XILINX_PCIE_RPIFR1_ALL_MASK,
> -				   XILINX_PCIE_REG_RPIFR1);
> -
> -			if (IS_ENABLED(CONFIG_PCI_MSI)) {
> -				/* Handle MSI Interrupt */
> -				generic_handle_irq(msi_data);
> -			}
> -		}
> +		if (IS_ENABLED(CONFIG_PCI_MSI) ||
> +			!(val & XILINX_PCIE_RPIFR1_MSI_INTR))
> +			generic_handle_irq(irq);
>  	}
> 
>  	if (status & XILINX_PCIE_INTR_SLV_UNSUPP)
> --

Hi Paul,

Even with above condition you are still missing either MSI or legacy interrupt handling, when both MSI and legacy interrupts occurred.

Bharat


From bharat.kumar.gogada at xilinx.com  Wed Feb 10 21:50:54 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Thu, 11 Feb 2016 05:50:54 +0000
Subject: [PATCH v3 2/6] PCI: xilinx: Unify INTx & MSI interrupt FIFO decode
In-Reply-To: <8520D5D51A55D047800579B09414719825881ADE@XAP-PVEXMBX01.xlnx.xilinx.com>
References: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>
 <1454602213-967-3-git-send-email-paul.burton@imgtec.com>
 <8520D5D51A55D047800579B09414719825881ADE@XAP-PVEXMBX01.xlnx.xilinx.com>
Message-ID: <8520D5D51A55D047800579B09414719825881B00@XAP-PVEXMBX01.xlnx.xilinx.com>

> > Subject: [PATCH v3 2/6] PCI: xilinx: Unify INTx & MSI interrupt FIFO
> > decode
> >
> > When decoding either an INTx or MSI interrupt, the driver has no way
> > to know which it will pull out of the interrupt FIFO. If both were
> > pending then this would lead to either the interrupt being handled
> > incorrectly (MSI interrupt treated as INTx) or not at all (INTx interrupt
> dropped by MSI path).
> > Unify the reading of the interrupt FIFO & act according to the type of
> > interrupt actually read.
> >
> > Signed-off-by: Paul Burton <paul.burton at imgtec.com>
> > Fixes: 8961def56845 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP
> > driver")
> >
> > ---
> >
> > Changes in v3:
> > - Split out from Boston patchset.
> >
> > Changes in v2:
> > - Add Fixes tag.
> >
> >  drivers/pci/host/pcie-xilinx.c | 47
> > +++++++++++++-----------------------------
> >  1 file changed, 14 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/pci/host/pcie-xilinx.c
> > b/drivers/pci/host/pcie-xilinx.c index
> > 1490bd1..afdfb09 100644
> > --- a/drivers/pci/host/pcie-xilinx.c
> > +++ b/drivers/pci/host/pcie-xilinx.c
> > @@ -397,7 +397,7 @@ static const struct irq_domain_ops
> intx_domain_ops
> > = {  static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)  {
> >  	struct xilinx_pcie_port *port = (struct xilinx_pcie_port *)data;
> > -	u32 val, mask, status, msi_data;
> > +	u32 val, mask, status;
> >
> >  	/* Read interrupt decode and mask registers */
> >  	val = pcie_read(port, XILINX_PCIE_REG_IDR); @@ -437,8 +437,8 @@
> > static irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
> >  		xilinx_pcie_clear_err_interrupts(port);
> >  	}
> >
> > -	if (status & XILINX_PCIE_INTR_INTX) {
> > -		/* INTx interrupt received */
> > +	if (status & (XILINX_PCIE_INTR_INTX | XILINX_PCIE_INTR_MSI)) {
> > +		/* Interrupt received */
> >  		val = pcie_read(port, XILINX_PCIE_REG_RPIFR1);
> >
> >  		/* Check whether interrupt valid */ @@ -447,41 +447,22 @@
> static
> > irqreturn_t xilinx_pcie_intr_handler(int irq, void *data)
> >  			return IRQ_HANDLED;
> >  		}
> >
> > -		if (!(val & XILINX_PCIE_RPIFR1_MSI_INTR)) {
> > -			/* Clear interrupt FIFO register 1 */
> > -			pcie_write(port, XILINX_PCIE_RPIFR1_ALL_MASK,
> > -				   XILINX_PCIE_REG_RPIFR1);
> > -
> > -			/* Handle INTx Interrupt */
> > +		if (val & XILINX_PCIE_RPIFR1_MSI_INTR) {
> > +			irq = pcie_read(port, XILINX_PCIE_REG_RPIFR2) &
> > +				XILINX_PCIE_RPIFR2_MSG_DATA;
> > +		} else {
> >  			val = ((val & XILINX_PCIE_RPIFR1_INTR_MASK) >>
> >  				XILINX_PCIE_RPIFR1_INTR_SHIFT) + 1;
> > -			generic_handle_irq(irq_find_mapping(port-
> > >irq_domain,
> > -							    val));
> > +			irq = irq_find_mapping(port->irq_domain, val);
> >  		}
> > -	}
> >
> > -	if (status & XILINX_PCIE_INTR_MSI) {
> > -		/* MSI Interrupt */
> > -		val = pcie_read(port, XILINX_PCIE_REG_RPIFR1);
> > +		/* Clear interrupt FIFO register 1 */
> > +		pcie_write(port, XILINX_PCIE_RPIFR1_ALL_MASK,
> > +			   XILINX_PCIE_REG_RPIFR1);
> >
> > -		if (!(val & XILINX_PCIE_RPIFR1_INTR_VALID)) {
> > -			dev_warn(port->dev, "RP Intr FIFO1 read error\n");
> > -			return IRQ_HANDLED;
> > -		}
> > -
> > -		if (val & XILINX_PCIE_RPIFR1_MSI_INTR) {
> > -			msi_data = pcie_read(port,
> > XILINX_PCIE_REG_RPIFR2) &
> > -				   XILINX_PCIE_RPIFR2_MSG_DATA;
> > -
> > -			/* Clear interrupt FIFO register 1 */
> > -			pcie_write(port, XILINX_PCIE_RPIFR1_ALL_MASK,
> > -				   XILINX_PCIE_REG_RPIFR1);
> > -
> > -			if (IS_ENABLED(CONFIG_PCI_MSI)) {
> > -				/* Handle MSI Interrupt */
> > -				generic_handle_irq(msi_data);
> > -			}
> > -		}
> > +		if (IS_ENABLED(CONFIG_PCI_MSI) ||
> > +			!(val & XILINX_PCIE_RPIFR1_MSI_INTR))
> > +			generic_handle_irq(irq);
> >  	}
> >
> >  	if (status & XILINX_PCIE_INTR_SLV_UNSUPP)
> > --
> 
> Hi Paul,
> 
> Even with above condition you are still missing either MSI or legacy interrupt
> handling, when both MSI and legacy interrupts occurred.

It would be better if the condition when both legacy and MSI interrupts occurred can be handled separately, leaving the current individual interrupt cases as they are.

Bharat


From bharat.kumar.gogada at xilinx.com  Wed Feb 10 22:20:42 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Thu, 11 Feb 2016 06:20:42 +0000
Subject: [PATCH v3 4/6] PCI: xilinx: Clear interrupt FIFO during probe
In-Reply-To: <1454602213-967-5-git-send-email-paul.burton@imgtec.com>
References: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>
 <1454602213-967-5-git-send-email-paul.burton@imgtec.com>
Message-ID: <8520D5D51A55D047800579B09414719825881B1B@XAP-PVEXMBX01.xlnx.xilinx.com>

 > xilinx_pcie_init_port clears the pending interrupts in the interrupt decode
> register, but does not clear the interrupt FIFO. This would lead to spurious
> interrupts if any were present in the FIFO at probe time.
> Clear the interrupt FIFO prior to the interrupt decode register in order to
> start with a clean slate as expected.
> 
> Signed-off-by: Paul Burton <paul.burton at imgtec.com>
> Fixes: 8961def56845 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver")
> 
> ---
> 
> Changes in v3:
> - Split out from Boston patchset.
> 
> Changes in v2:
> - Add Fixes tag.
> 
>  drivers/pci/host/pcie-xilinx.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c index
> 1eb74a2..6c5a503 100644
> --- a/drivers/pci/host/pcie-xilinx.c
> +++ b/drivers/pci/host/pcie-xilinx.c
> @@ -568,6 +568,8 @@ static int xilinx_pcie_init_irq_domain(struct
> xilinx_pcie_port *port)
>   */
>  static void xilinx_pcie_init_port(struct xilinx_pcie_port *port)  {
> +	u32 val;
> +
>  	if (xilinx_pcie_link_is_up(port))
>  		dev_info(port->dev, "PCIe Link is UP\n");
>  	else
> @@ -577,6 +579,17 @@ static void xilinx_pcie_init_port(struct
> xilinx_pcie_port *port)
>  	pcie_write(port, ~XILINX_PCIE_IDR_ALL_MASK,
>  		   XILINX_PCIE_REG_IMR);
> 
> +	/* Clear interrupt FIFO */
> +	while (1) {
> +		val = pcie_read(port, XILINX_PCIE_REG_RPIFR1);
> +
> +		if (!(val & XILINX_PCIE_RPIFR1_INTR_VALID))
> +			break;
> +
> +		pcie_write(port, XILINX_PCIE_RPIFR1_ALL_MASK,
> +			   XILINX_PCIE_REG_RPIFR1);
> +	}
> +
Hi Paul,

This case will create problem with error case, suppose if we have continuous correctable errors on link this will always be while loop.

Bharat


From a.hajda at samsung.com  Wed Feb 10 22:45:11 2016
From: a.hajda at samsung.com (Andrzej Hajda)
Date: Thu, 11 Feb 2016 07:45:11 +0100
Subject: [PATCH] tty/serial: digicolor: Fix bad usage of IS_ERR_VALUE
In-Reply-To: <56BC022B.7030004@roeck-us.net>
References: <1455030539-10798-1-git-send-email-linux@roeck-us.net>
 <4571887.rTPndCnv20@wuerfel> <56BAA27A.9050605@roeck-us.net>
 <2606061.l722KO95iI@wuerfel> <56BC022B.7030004@roeck-us.net>
Message-ID: <56BC2DF7.20803@samsung.com>

On 02/11/2016 04:38 AM, Guenter Roeck wrote:
> On 02/10/2016 07:21 AM, Arnd Bergmann wrote:
>> On Tuesday 09 February 2016 18:37:46 Guenter Roeck wrote:
>>> On 02/09/2016 07:26 AM, Arnd Bergmann wrote:
>>>> On Tuesday 09 February 2016 07:08:59 Guenter Roeck wrote:
>>>>> IS_ERR_VALUE() assumes that its parameter is an unsigned long.
>>>>> It can not be used to check if an unsigned int reflects an error.
>>>>> Doing so can result in the following build warning.
>>>>>
>>>>> drivers/tty/serial/digicolor-usart.c: In function ?digicolor_uart_probe?:
>>>>> include/linux/err.h:21:38: warning:
>>>>>           comparison is always false due to limited range of data type
>>>>> drivers/tty/serial/digicolor-usart.c:485:6: note:
>>>>>           in expansion of macro ?IS_ERR_VALUE?
>>>>>
>>>>> If that warning is seen, an error return from platform_get_irq() is missed.
>>>>>
>>>>>
>>>> The patch looks correct to me, but what compiler version and which kernel
>>>> tree is it that triggered the warning?
>>>>
>>>> Andrzej Hajda just modified the definition of IS_ERR_VALUE(), and the
>>>> changes are still under discussion, but I don't see that warning with
>>>> any of the versions.
>>>>
>>> I see it with gcc 5.1 and 5.2 (and W=1). I did not see / notice Andrzej's patch.
>>>
>>> I agree that fixing the problem in IS_ERR_VALUE() is preferrable.
>>>
>>>
>> Ah, W=1 explains it. We are still debating about the proper solution. Al Viro
>> pointed out that most users of IS_ERR_VALUE() shouldn't be using it at all,
>> so your patch is probably best here after all.
>>
> Yes, after looking into it some more I agree. Coccinelle should be able to handle
> most of the conversions automatically. I actually tried to write a script, just
> for the fun of it, but it misses some of the problem cases in patch mode.
> Maybe I get it working tonight.
>
> Guenter
>

Maybe it can be helpful. The script which classifies all IS_ERR_VALUE
usages as
correct, signed, incorrect and unknown (cocci was not able to detect type).
Adding patch mode should be quite simple.

// Options: --all-includes --include
include/uapi/linux/netfilter_ipv6/ip6_tables.h --include
include/uapi/linux/netfilter_ipv4/ip_tables.h --include
include/uapi/linux/netfilter_arp/arp_tables.h --include
include/uapi/linux/netfilter/x_tables.h --include include/linux/mm_types.h

virtual context
virtual report

@r@
typedef bool, u8, u16, u32, u64, s8, s16, s32, s64, __u64, dma_addr_t,
Elf32_Addr, Elf64_Addr;
{unsigned long, size_t} ev;
{short, int, long, s16, s32, ssize_t} ew;
{char, unsigned char, unsigned short, unsigned int, long long, unsigned
long long, bool, u8, u16, u32, u64, s64, __u64, dma_addr_t, Elf32_Addr,
Elf64_Addr} ei;
expression eu;
position p;
@@

IS_ERR_VALUE(\(ev \| ew \| ei \| eu \))@p

@script:python depends on report@
p << r.p = [];
ev << r.ev = "";
ew << r.ew = "";
ei << r.ei = "";
eu << r.eu = "";
@@

t = ""
if ev: t = "correct"
if ew: t = "signed"
if ei: t = "incorrect"
if eu: t = "unknown"


e = ev + ew + ei + eu;
if t:
    msg = "WARNING: %s argument type in IS_ERR_VALUE(%s)" % (t, e)
    coccilib.report.print_report(p[0], msg)




From baruch at tkos.co.il  Wed Feb 10 22:50:57 2016
From: baruch at tkos.co.il (Baruch Siach)
Date: Thu, 11 Feb 2016 08:50:57 +0200
Subject: [PATCH] tty/serial: digicolor: Fix bad usage of IS_ERR_VALUE
In-Reply-To: <1455030539-10798-1-git-send-email-linux@roeck-us.net>
References: <1455030539-10798-1-git-send-email-linux@roeck-us.net>
Message-ID: <20160211065057.GA17047@tarshish>

Hi Guenter,

On Tue, Feb 09, 2016 at 07:08:59AM -0800, Guenter Roeck wrote:
> IS_ERR_VALUE() assumes that its parameter is an unsigned long.
> It can not be used to check if an unsigned int reflects an error.
> Doing so can result in the following build warning.
> 
> drivers/tty/serial/digicolor-usart.c: In function ?digicolor_uart_probe?:
> include/linux/err.h:21:38: warning:
> 	comparison is always false due to limited range of data type
> drivers/tty/serial/digicolor-usart.c:485:6: note:
> 	in expansion of macro ?IS_ERR_VALUE?
> 
> If that warning is seen, an error return from platform_get_irq() is missed.
> 
> Signed-off-by: Guenter Roeck <linux at roeck-us.net>

Acked-by: Baruch Siach <baruch at tkos.co.il>

Thanks,
baruch

> ---
>  drivers/tty/serial/digicolor-usart.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/tty/serial/digicolor-usart.c b/drivers/tty/serial/digicolor-usart.c
> index a80cdad114f3..02ad6953b167 100644
> --- a/drivers/tty/serial/digicolor-usart.c
> +++ b/drivers/tty/serial/digicolor-usart.c
> @@ -453,7 +453,7 @@ static struct uart_driver digicolor_uart = {
>  static int digicolor_uart_probe(struct platform_device *pdev)
>  {
>  	struct device_node *np = pdev->dev.of_node;
> -	int ret, index;
> +	int irq, ret, index;
>  	struct digicolor_port *dp;
>  	struct resource *res;
>  	struct clk *uart_clk;
> @@ -481,9 +481,10 @@ static int digicolor_uart_probe(struct platform_device *pdev)
>  	if (IS_ERR(dp->port.membase))
>  		return PTR_ERR(dp->port.membase);
>  
> -	dp->port.irq = platform_get_irq(pdev, 0);
> -	if (IS_ERR_VALUE(dp->port.irq))
> -		return dp->port.irq;
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq < 0)
> +		return irq;
> +	dp->port.irq = irq;
>  
>  	dp->port.iotype = UPIO_MEM;
>  	dp->port.uartclk = clk_get_rate(uart_clk);

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -


From gnurou at gmail.com  Thu Feb 11 00:32:13 2016
From: gnurou at gmail.com (Alexandre Courbot)
Date: Thu, 11 Feb 2016 17:32:13 +0900
Subject: [PATCH V3] ARM64: tegra: Add support for Google Pixel C
In-Reply-To: <1455020809-17531-1-git-send-email-jonathanh@nvidia.com>
References: <1454949199-27050-1-git-send-email-jonathanh@nvidia.com>
 <1455020809-17531-1-git-send-email-jonathanh@nvidia.com>
Message-ID: <CAAVeFuJt+VdJb4S3PC-RXVFYhLnq7yF+dV_w5or=0ebG+LnnGw@mail.gmail.com>

On Tue, Feb 9, 2016 at 9:26 PM, Jon Hunter <jonathanh at nvidia.com> wrote:
> Add initial device-tree support for Google Pixel C (a.k.a. Smaug) based
> upon Tegra210 SoC with 3 GiB of LPDDR4 RAM.
>
> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>

I need to add "clk_ignore_unused=1" to the bootargs in order to avoid
a hang during boot, but otherwise can reach a serial console.

Tested-by: Alexandre Courbot <acourbot at nvidia.com>


From u.kleine-koenig at pengutronix.de  Thu Feb 11 00:40:29 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Thu, 11 Feb 2016 09:40:29 +0100
Subject: noise issues when recording sound on i.MX28
In-Reply-To: <CAOMZO5D5H4F90nse9kyW9KvsJStN-sCGktup4FDPw_zTeNfS2g@mail.gmail.com>
References: <20160127105613.GC13664@pengutronix.de>
 <CAOMZO5BpLen517q2heramSta-R6pdESkjM6w=7FRMZebY6ue-Q@mail.gmail.com>
 <20160127144340.GD13664@pengutronix.de>
 <CAOMZO5AE6HwBYz7kOFORt0HTojJLSb0MYUbkb_HCshDHy=d27g@mail.gmail.com>
 <20160210150315.GC13664@pengutronix.de>
 <CAOMZO5D5H4F90nse9kyW9KvsJStN-sCGktup4FDPw_zTeNfS2g@mail.gmail.com>
Message-ID: <20160211084029.GE13664@pengutronix.de>

On Wed, Feb 10, 2016 at 06:10:18PM -0200, Fabio Estevam wrote:
> Hi Uwe,
> 
> On Wed, Feb 10, 2016 at 1:03 PM, Uwe Kleine-K?nig
> <u.kleine-koenig at pengutronix.de> wrote:
> > Hello Fabio,
> >
> > On Tue, Feb 02, 2016 at 11:00:33AM -0200, Fabio Estevam wrote:
> >> On Wed, Jan 27, 2016 at 12:43 PM, Uwe Kleine-K?nig
> >> <u.kleine-koenig at pengutronix.de> wrote:
> >>
> >> > So you didn't hit the problem that resetting a saif didn't work, right?
> >>
> >> No, we haven't seen this reset issue.
> >>
> >> > Do you have a few more technical details here? A usecase of my machine
> >>
> >> Let me find out as it has been several years I worked on this problem.
> >> Will let you know.
> >
> > Anything new on your end? I know from Lothar that he invested quite some
> > time to debug his hardware setup, tested the codec instead of the i.MX28
> > as clock provider and several more things. I also spend some time on
> > this issue and we both hope that Freescale/NXP can help in better
> > understanding the issue and hopefully can come up with a recipe to make
> > concurrent recording and playback on i.MX28 work.
> >
> > Lothar is in contact with Freescale, too, but up to now with little
> > success. The company I'm working for at the moment would also welcome a
> > solution here.
> 
> Sorry for the delay. I have been on holidays.

I wonder who granted you to go on holidays given that we have
problems :-)

> Can you confirm you have both SAIF interfaces being clocked from ref_pll?

root at hostname:/sys/kernel/debug/clk find -name saif?_sel
./ref_xtal/pll0/saif0_sel
./ref_xtal/pll0/saif1_sel

root at hostname:/sys/kernel/debug/clk cat ./ref_xtal/pll0/saif?_sel/clk_rate 
480000000
480000000

This is based on 3.10 (but I hope to update soon to 4.4ish). I know that
Lothar uses 4.4. Also Lothar noticed that disabling one of these
saif_sel clocks doesn't make an impression on the interfaces, they just
continue to run. Maybe a clock is routed in a wrong way?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From christoffer.dall at linaro.org  Thu Feb 11 00:43:47 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Thu, 11 Feb 2016 09:43:47 +0100
Subject: [PATCH] arm/arm64: KVM: Handle out-of-RAM cache maintenance as a
 NOP
In-Reply-To: <1454942245-18452-1-git-send-email-marc.zyngier@arm.com>
References: <1454942245-18452-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160211084347.GT5171@cbox>

On Mon, Feb 08, 2016 at 02:37:25PM +0000, Marc Zyngier wrote:
> So far, our handling of cache maintenance by VA has been pretty
> simple: Either the access is in the guest RAM and generates a S2
> fault, which results in the page being mapped RW, or we go down
> the io_mem_abort() path, and nuke the guest.
> 
> The first one is fine, but the second one is extremely weird.
> Treating the CM as an I/O is wrong, and nothing in the ARM ARM
> indicates that we should generate a fault for something that
> cannot end-up in the cache anyway (even if the guest maps it,
> it will keep on faulting at stage-2 for emulation).
> 
> So let's just skip this instruction, and let the guest get away
> with it.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/include/asm/kvm_emulate.h   |  5 +++++
>  arch/arm/kvm/mmu.c                   | 17 +++++++++++++++++
>  arch/arm64/include/asm/kvm_emulate.h |  5 +++++
>  3 files changed, 27 insertions(+)
> 
> diff --git a/arch/arm/include/asm/kvm_emulate.h b/arch/arm/include/asm/kvm_emulate.h
> index 3095df0..f768797 100644
> --- a/arch/arm/include/asm/kvm_emulate.h
> +++ b/arch/arm/include/asm/kvm_emulate.h
> @@ -143,6 +143,11 @@ static inline bool kvm_vcpu_dabt_iss1tw(struct kvm_vcpu *vcpu)
>  	return kvm_vcpu_get_hsr(vcpu) & HSR_DABT_S1PTW;
>  }
>  
> +static inline bool kvm_vcpu_dabt_iscm(struct kvm_vcpu *vcpu)
> +{
> +	return !!(kvm_vcpu_get_hsr(vcpu) & HSR_DABT_CM);
> +}
> +
>  /* Get Access Size from a data abort */
>  static inline int kvm_vcpu_dabt_get_as(struct kvm_vcpu *vcpu)
>  {
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index aba61fd..1a5f2ea 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -1431,6 +1431,23 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  		}
>  
>  		/*
> +		 * Check for a cache maintenance operation. Since we
> +		 * ended-up here, we know it is outside of any memory
> +		 * slot. But we can't find out if that is for a device,
> +		 * or if the guest is just being stupid (going all the
> +		 * way to userspace is not an option - what would you
> +		 * write?).

I'm not sure what the stuff about "what would you write?" means, I'm
assuming it means that the ISV bit is clear.

I think the point is more that if there's no S2 mapping, then there
could never be any cache entries as a result of memory accesses using
the GVA in question, so there's nothing to invalidate (like you state in
your commit message).

> +		 *
> +		 * So let's assume that the guest is just being
> +		 * cautious, and skip the instruction.
> +		 */
> +		if (kvm_vcpu_dabt_iscm(vcpu)) {
> +			kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
> +			ret = 1;
> +			goto out_unlock;
> +		}
> +
> +		/*
>  		 * The IPA is reported as [MAX:12], so we need to
>  		 * complement it with the bottom 12 bits from the
>  		 * faulting VA. This is always 12 bits, irrespective
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index 3066328..01cdf5f 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -185,6 +185,11 @@ static inline bool kvm_vcpu_dabt_iss1tw(const struct kvm_vcpu *vcpu)
>  	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_S1PTW);
>  }
>  
> +static inline bool kvm_vcpu_dabt_iscm(const struct kvm_vcpu *vcpu)
> +{
> +	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_CM);
> +}
> +
>  static inline int kvm_vcpu_dabt_get_as(const struct kvm_vcpu *vcpu)
>  {
>  	return 1 << ((kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SAS) >> ESR_ELx_SAS_SHIFT);
> -- 
> 2.1.4
> 

some nitpicking: if you modify anything here, I think is_cm is more clear than iscm.

But besides the cosmetics:

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From jonathanh at nvidia.com  Thu Feb 11 00:55:45 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Thu, 11 Feb 2016 08:55:45 +0000
Subject: [PATCH V3] ARM64: tegra: Add support for Google Pixel C
In-Reply-To: <CAAVeFuJt+VdJb4S3PC-RXVFYhLnq7yF+dV_w5or=0ebG+LnnGw@mail.gmail.com>
References: <1454949199-27050-1-git-send-email-jonathanh@nvidia.com>
 <1455020809-17531-1-git-send-email-jonathanh@nvidia.com>
 <CAAVeFuJt+VdJb4S3PC-RXVFYhLnq7yF+dV_w5or=0ebG+LnnGw@mail.gmail.com>
Message-ID: <56BC4C91.6070409@nvidia.com>


On 11/02/16 08:32, Alexandre Courbot wrote:
> On Tue, Feb 9, 2016 at 9:26 PM, Jon Hunter <jonathanh at nvidia.com> wrote:
>> Add initial device-tree support for Google Pixel C (a.k.a. Smaug) based
>> upon Tegra210 SoC with 3 GiB of LPDDR4 RAM.
>>
>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
> 
> I need to add "clk_ignore_unused=1" to the bootargs in order to avoid
> a hang during boot, but otherwise can reach a serial console.

Were you testing on -next? If so, you should not need that. Otherwise,
please make sure you have this patch [0]. Thierry has included this in a
clock fixes series that should turn up in main soon.

> Tested-by: Alexandre Courbot <acourbot at nvidia.com>

Thanks
Jon

[0] https://lkml.org/lkml/2015/12/18/390



From peter.ujfalusi at ti.com  Thu Feb 11 00:54:32 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 11 Feb 2016 10:54:32 +0200
Subject: [PATCH] dmaengine: edma: Implement device_synchronize callback
Message-ID: <1455180872-2620-1-git-send-email-peter.ujfalusi@ti.com>

We need the callback to support the dmaengine_terminate_sync().

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 drivers/dma/edma.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2dac314a2d7a..ea0d919a3318 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -869,6 +869,13 @@ static int edma_terminate_all(struct dma_chan *chan)
 	return 0;
 }
 
+static void edma_synchronize(struct dma_chan *c)
+{
+	struct edma_chan *echan = to_edma_chan(chan);
+
+	vchan_synchronize(&echan->vchan);
+}
+
 static int edma_slave_config(struct dma_chan *chan,
 	struct dma_slave_config *cfg)
 {
@@ -1808,6 +1815,7 @@ static void edma_dma_init(struct edma_cc *ecc, bool legacy_mode)
 	s_ddev->device_pause = edma_dma_pause;
 	s_ddev->device_resume = edma_dma_resume;
 	s_ddev->device_terminate_all = edma_terminate_all;
+	s_ddev->device_synchronize = edma_synchronize;
 
 	s_ddev->src_addr_widths = EDMA_DMA_BUSWIDTHS;
 	s_ddev->dst_addr_widths = EDMA_DMA_BUSWIDTHS;
@@ -1833,6 +1841,7 @@ static void edma_dma_init(struct edma_cc *ecc, bool legacy_mode)
 		m_ddev->device_pause = edma_dma_pause;
 		m_ddev->device_resume = edma_dma_resume;
 		m_ddev->device_terminate_all = edma_terminate_all;
+		m_ddev->device_synchronize = edma_synchronize;
 
 		m_ddev->src_addr_widths = EDMA_DMA_BUSWIDTHS;
 		m_ddev->dst_addr_widths = EDMA_DMA_BUSWIDTHS;
-- 
2.7.1



From peter.ujfalusi at ti.com  Thu Feb 11 00:54:54 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 11 Feb 2016 10:54:54 +0200
Subject: [PATCH] dmaengine: omap-dma: Implement device_synchronize callback
Message-ID: <1455180894-2672-1-git-send-email-peter.ujfalusi@ti.com>

We need the callback to support the dmaengine_terminate_sync().

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 drivers/dma/omap-dma.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index e691f48f9d73..7c6a300b6b57 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1007,6 +1007,13 @@ static int omap_dma_terminate_all(struct dma_chan *chan)
 	return 0;
 }
 
+static void omap_dma_synchronize(struct dma_chan *c)
+{
+	struct omap_chan *c = to_omap_dma_chan(chan);
+
+	vchan_synchronize(&c->vc);
+}
+
 static int omap_dma_pause(struct dma_chan *chan)
 {
 	struct omap_chan *c = to_omap_dma_chan(chan);
@@ -1110,6 +1117,7 @@ static int omap_dma_probe(struct platform_device *pdev)
 	od->ddev.device_pause = omap_dma_pause;
 	od->ddev.device_resume = omap_dma_resume;
 	od->ddev.device_terminate_all = omap_dma_terminate_all;
+	od-ddev.device_synchronize = omap_dma_synchronize;
 	od->ddev.src_addr_widths = OMAP_DMA_BUSWIDTHS;
 	od->ddev.dst_addr_widths = OMAP_DMA_BUSWIDTHS;
 	od->ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
-- 
2.7.1



From peter.ujfalusi at ti.com  Thu Feb 11 01:00:47 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 11 Feb 2016 11:00:47 +0200
Subject: [PATCH] dmaengine: omap-dma: Implement device_synchronize callback
In-Reply-To: <1455180894-2672-1-git-send-email-peter.ujfalusi@ti.com>
References: <1455180894-2672-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <56BC4DBF.8080605@ti.com>

On 02/11/2016 10:54 AM, Peter Ujfalusi wrote:
> We need the callback to support the dmaengine_terminate_sync().

I have made some typos and I only compiled the kernel after sending the patch..
Resending.

> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> ---
>  drivers/dma/omap-dma.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> index e691f48f9d73..7c6a300b6b57 100644
> --- a/drivers/dma/omap-dma.c
> +++ b/drivers/dma/omap-dma.c
> @@ -1007,6 +1007,13 @@ static int omap_dma_terminate_all(struct dma_chan *chan)
>  	return 0;
>  }
>  
> +static void omap_dma_synchronize(struct dma_chan *c)
> +{
> +	struct omap_chan *c = to_omap_dma_chan(chan);
> +
> +	vchan_synchronize(&c->vc);
> +}
> +
>  static int omap_dma_pause(struct dma_chan *chan)
>  {
>  	struct omap_chan *c = to_omap_dma_chan(chan);
> @@ -1110,6 +1117,7 @@ static int omap_dma_probe(struct platform_device *pdev)
>  	od->ddev.device_pause = omap_dma_pause;
>  	od->ddev.device_resume = omap_dma_resume;
>  	od->ddev.device_terminate_all = omap_dma_terminate_all;
> +	od-ddev.device_synchronize = omap_dma_synchronize;
>  	od->ddev.src_addr_widths = OMAP_DMA_BUSWIDTHS;
>  	od->ddev.dst_addr_widths = OMAP_DMA_BUSWIDTHS;
>  	od->ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
> 


-- 
P?ter


From peter.ujfalusi at ti.com  Thu Feb 11 01:00:57 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 11 Feb 2016 11:00:57 +0200
Subject: [PATCH] dmaengine: edma: Implement device_synchronize callback
In-Reply-To: <1455180872-2620-1-git-send-email-peter.ujfalusi@ti.com>
References: <1455180872-2620-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <56BC4DC9.6000309@ti.com>

On 02/11/2016 10:54 AM, Peter Ujfalusi wrote:
> We need the callback to support the dmaengine_terminate_sync().

I have made some typos and I only compiled the kernel after sending the patch..
Resending.

> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> ---
>  drivers/dma/edma.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index 2dac314a2d7a..ea0d919a3318 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -869,6 +869,13 @@ static int edma_terminate_all(struct dma_chan *chan)
>  	return 0;
>  }
>  
> +static void edma_synchronize(struct dma_chan *c)
> +{
> +	struct edma_chan *echan = to_edma_chan(chan);
> +
> +	vchan_synchronize(&echan->vchan);
> +}
> +
>  static int edma_slave_config(struct dma_chan *chan,
>  	struct dma_slave_config *cfg)
>  {
> @@ -1808,6 +1815,7 @@ static void edma_dma_init(struct edma_cc *ecc, bool legacy_mode)
>  	s_ddev->device_pause = edma_dma_pause;
>  	s_ddev->device_resume = edma_dma_resume;
>  	s_ddev->device_terminate_all = edma_terminate_all;
> +	s_ddev->device_synchronize = edma_synchronize;
>  
>  	s_ddev->src_addr_widths = EDMA_DMA_BUSWIDTHS;
>  	s_ddev->dst_addr_widths = EDMA_DMA_BUSWIDTHS;
> @@ -1833,6 +1841,7 @@ static void edma_dma_init(struct edma_cc *ecc, bool legacy_mode)
>  		m_ddev->device_pause = edma_dma_pause;
>  		m_ddev->device_resume = edma_dma_resume;
>  		m_ddev->device_terminate_all = edma_terminate_all;
> +		m_ddev->device_synchronize = edma_synchronize;
>  
>  		m_ddev->src_addr_widths = EDMA_DMA_BUSWIDTHS;
>  		m_ddev->dst_addr_widths = EDMA_DMA_BUSWIDTHS;
> 


-- 
P?ter


From lee.jones at linaro.org  Thu Feb 11 01:09:46 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 11 Feb 2016 09:09:46 +0000
Subject: [PATCH 01/14] mfd: intel_quark_i2c_gpio: Use clkdev_create()
In-Reply-To: <20160210183504.GG30978@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
 <1454982341-22715-2-git-send-email-sboyd@codeaurora.org>
 <20160210162349.GJ3782@x1> <20160210183504.GG30978@codeaurora.org>
Message-ID: <20160211090946.GY3782@x1>

On Wed, 10 Feb 2016, Stephen Boyd wrote:

> On 02/10, Lee Jones wrote:
> > On Mon, 08 Feb 2016, Stephen Boyd wrote:
> > 
> > > Convert this driver to use clkdev_create() instead of
> > > clk_register_clkdevs(). The latter API is only used by this driver,
> > > although this driver only allocates one clk to add anyway.
> > > Furthermore, this driver allocates the clk_lookup structure with
> > > devm, but clkdev_drop() will free that structure when passed,
> > > leading to a double free when this driver is removed. Clean it
> > > all up and pave the way for the removal of clk_register_clkdevs().
> > > 
> > > Cc: Lee Jones <lee.jones at linaro.org>
> > > Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> > > Cc: Russell King <linux at arm.linux.org.uk>
> > > Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> > > ---
> > >  drivers/mfd/intel_quark_i2c_gpio.c | 26 +++++++++-----------------
> > >  1 file changed, 9 insertions(+), 17 deletions(-)
> > 
> > I never much liked this code [0]
> > 
> > Glad for it to be simplified.
> > 
> > Applied, thanks.
> > 
> 
> Can you please ack the patch instead? I'd like to take it through
> the clk tree so that I can remove clk_register_clkdevs() as well.

I'll make a branch you can pull from.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From peter.ujfalusi at ti.com  Thu Feb 11 01:08:34 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 11 Feb 2016 11:08:34 +0200
Subject: [PATCH v2] dmaengine: omap-dma: Implement device_synchronize callback
Message-ID: <1455181714-32057-1-git-send-email-peter.ujfalusi@ti.com>

We need the callback to support the dmaengine_terminate_sync().

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 drivers/dma/omap-dma.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index e691f48f9d73..bfdf29aa3428 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1007,6 +1007,13 @@ static int omap_dma_terminate_all(struct dma_chan *chan)
 	return 0;
 }
 
+static void omap_dma_synchronize(struct dma_chan *chan)
+{
+	struct omap_chan *c = to_omap_dma_chan(chan);
+
+	vchan_synchronize(&c->vc);
+}
+
 static int omap_dma_pause(struct dma_chan *chan)
 {
 	struct omap_chan *c = to_omap_dma_chan(chan);
@@ -1110,6 +1117,7 @@ static int omap_dma_probe(struct platform_device *pdev)
 	od->ddev.device_pause = omap_dma_pause;
 	od->ddev.device_resume = omap_dma_resume;
 	od->ddev.device_terminate_all = omap_dma_terminate_all;
+	od->ddev.device_synchronize = omap_dma_synchronize;
 	od->ddev.src_addr_widths = OMAP_DMA_BUSWIDTHS;
 	od->ddev.dst_addr_widths = OMAP_DMA_BUSWIDTHS;
 	od->ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
-- 
2.7.1



From arnd at arndb.de  Thu Feb 11 01:10:00 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 10:10:00 +0100
Subject: [PATCH] drm/msm: remove unused variable
Message-ID: <1455181810-3910161-1-git-send-email-arnd@arndb.de>

After the drm_device_is_unplugged() was removed, the 'dev' variable is now
unused, and we get a warning for that:

drivers/gpu/drm/msm/msm_fbdev.c: In function 'msm_fbdev_mmap':
drivers/gpu/drm/msm/msm_fbdev.c:65:21: error: unused variable 'dev' [-Werror=unused-variable]

This removes the variable as well.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: e9f8250f2f92 ("drm/msm: remove the drm_device_is_unplugged check")
---
 drivers/gpu/drm/msm/msm_fbdev.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
index e119c2979509..d9759bf3482e 100644
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -62,7 +62,6 @@ static int msm_fbdev_mmap(struct fb_info *info, struct vm_area_struct *vma)
 	struct drm_fb_helper *helper = (struct drm_fb_helper *)info->par;
 	struct msm_fbdev *fbdev = to_msm_fbdev(helper);
 	struct drm_gem_object *drm_obj = fbdev->bo;
-	struct drm_device *dev = helper->dev;
 	int ret = 0;
 
 	ret = drm_gem_mmap_obj(drm_obj, drm_obj->size, vma);
-- 
2.7.0



From peter.ujfalusi at ti.com  Thu Feb 11 01:08:42 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 11 Feb 2016 11:08:42 +0200
Subject: [PATCH v2] dmaengine: edma: Implement device_synchronize callback
Message-ID: <1455181722-32099-1-git-send-email-peter.ujfalusi@ti.com>

We need the callback to support the dmaengine_terminate_sync().

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 drivers/dma/edma.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2dac314a2d7a..290e1a721c5b 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -869,6 +869,13 @@ static int edma_terminate_all(struct dma_chan *chan)
 	return 0;
 }
 
+static void edma_synchronize(struct dma_chan *chan)
+{
+	struct edma_chan *echan = to_edma_chan(chan);
+
+	vchan_synchronize(&echan->vchan);
+}
+
 static int edma_slave_config(struct dma_chan *chan,
 	struct dma_slave_config *cfg)
 {
@@ -1808,6 +1815,7 @@ static void edma_dma_init(struct edma_cc *ecc, bool legacy_mode)
 	s_ddev->device_pause = edma_dma_pause;
 	s_ddev->device_resume = edma_dma_resume;
 	s_ddev->device_terminate_all = edma_terminate_all;
+	s_ddev->device_synchronize = edma_synchronize;
 
 	s_ddev->src_addr_widths = EDMA_DMA_BUSWIDTHS;
 	s_ddev->dst_addr_widths = EDMA_DMA_BUSWIDTHS;
@@ -1833,6 +1841,7 @@ static void edma_dma_init(struct edma_cc *ecc, bool legacy_mode)
 		m_ddev->device_pause = edma_dma_pause;
 		m_ddev->device_resume = edma_dma_resume;
 		m_ddev->device_terminate_all = edma_terminate_all;
+		m_ddev->device_synchronize = edma_synchronize;
 
 		m_ddev->src_addr_widths = EDMA_DMA_BUSWIDTHS;
 		m_ddev->dst_addr_widths = EDMA_DMA_BUSWIDTHS;
-- 
2.7.1



From lee.jones at linaro.org  Thu Feb 11 01:10:36 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 11 Feb 2016 09:10:36 +0000
Subject: [PATCH v2] mfd: Provide MACRO to declare commonly defined MFD
 cell attributes
In-Reply-To: <56BB7865.3060004@nvidia.com>
References: <1455028027-1527-1-git-send-email-lee.jones@linaro.org>
 <20160210153846.GB26950@x1> <56BB7865.3060004@nvidia.com>
Message-ID: <20160211091036.GZ3782@x1>

On Wed, 10 Feb 2016, Laxman Dewangan wrote:

> 
> On Wednesday 10 February 2016 09:08 PM, Lee Jones wrote:
> >mfd: Provide MACRO to declare commonly defined MFD cell attributes
> >Cc: Laxman Dewangan <ldewangan at nvidia.com>
> >Signed-off-by: Lee Jones <lee.jones at linaro.org>
> 
> Build passed with this patch when using it.
> 
> Acked-by: Laxman Dewangan <ldewangan at nvidia.com>
> 
> Please let me know if you applying this. I am going to use the macro
> from this patch on max77620 series on next spin.

As you are the first user, just submit it as 0/1 of your set.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From ldewangan at nvidia.com  Thu Feb 11 01:01:45 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Thu, 11 Feb 2016 14:31:45 +0530
Subject: [PATCH v2] mfd: Provide MACRO to declare commonly defined MFD
 cell attributes
In-Reply-To: <20160211091036.GZ3782@x1>
References: <1455028027-1527-1-git-send-email-lee.jones@linaro.org>
 <20160210153846.GB26950@x1> <56BB7865.3060004@nvidia.com>
 <20160211091036.GZ3782@x1>
Message-ID: <56BC4DF9.7050402@nvidia.com>


On Thursday 11 February 2016 02:40 PM, Lee Jones wrote:
> On Wed, 10 Feb 2016, Laxman Dewangan wrote:
>
>> On Wednesday 10 February 2016 09:08 PM, Lee Jones wrote:
>>> mfd: Provide MACRO to declare commonly defined MFD cell attributes
>>> Cc: Laxman Dewangan <ldewangan at nvidia.com>
>>> Signed-off-by: Lee Jones <lee.jones at linaro.org>
>> Build passed with this patch when using it.
>>
>> Acked-by: Laxman Dewangan <ldewangan at nvidia.com>
>>
>> Please let me know if you applying this. I am going to use the macro
>> from this patch on max77620 series on next spin.
> As you are the first user, just submit it as 0/1 of your set.
>

I saw that it is merged and available in linux-next 20160211.
So it is fine to not submit this patch again and modify my patch 
assuming it is on tree.



From jonathanh at nvidia.com  Thu Feb 11 01:13:38 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Thu, 11 Feb 2016 09:13:38 +0000
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <CAPDyKFrZ6tWBsQC0tyWWeChiZja3h_zcbaiX25ak-Zyp4MzqVw@mail.gmail.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
 <56BB7AF4.8040708@nvidia.com>
 <CAPDyKFrZ6tWBsQC0tyWWeChiZja3h_zcbaiX25ak-Zyp4MzqVw@mail.gmail.com>
Message-ID: <56BC50C2.7050609@nvidia.com>


On 10/02/16 18:25, Ulf Hansson wrote:

[snip]

>>> Perhaps there's a way to allow the generic PM domain to control this
>>> by itself. If we for example used the struct device corresponding to
>>> the powergate driver, genpd could use it to distinguish between
>>> various instances of genpd structs..!? Maybe it would simplify the way
>>> to deal with removing domains?
>>
>> Yes, that would be ideal. However, would have require changing
>> genpd_init()? I am not sure how genpd would be able to access the device
>> struct for the powergate driver because we don't provide this via any
>> API I am aware of? And I am guessing that you don't wish to expose the
>> gpd_list to the world either.
>>
>> If there is an easy way, I am open to it, but looking at it today, I am
>> not sure I see a simple way in which we could add a new API to do this.
>> However, may be I am missing something!
> 
> If we add a new __pm_genpd_init() API, that could require a struct
> device to be provided. That API will thus invoke the existing
> pm_genpd_init() but also deal with the extra things needed here.
> 
> I would also allow such an API to return an error code.
> 
> Correspondingly, pm_genpd_remove() could be required to be provided
> with a struct device.
> 
> Existing users of pm_genpd_init() can then convert to
> __pm_genpd_init() whenever suitable.
> 
> Of course, another option is just to add new member in the genpd
> struct for the struct *device. The caller of pm_genpd_init() could
> check it, but allow it to be NULL. Although, the pm_genpd_remove() API
> would require that pointer to the struct device to be set...
> 
> What do you think?

Yes, sounds good. May be it is simpler just to add a new member and let
the platform genpd driver handle it.

I am wondering if in addition to pm_genpd_remove(), we then just have a
function called pm_genpd_remove_tail(), which allows you to pass the
struct device pointer and will remove the last pm-domain from the
gpd_list and return the genpd pointer if successful. Internally, it will
call pm_genpd_remove(). It seems to me that if there are nested
pm-domains, then we probably want to remove them starting from the tail
as opposed to the head.

How does that sound?

Cheers
Jon


From arnd at arndb.de  Thu Feb 11 01:38:08 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 10:38:08 +0100
Subject: [PATCH] regulator: qcom-saw: avoid uninitialized variable warning
Message-ID: <1455183497-299798-1-git-send-email-arnd@arndb.de>

gcc cannot know that a for_each_possible_cpu() loop always executes
at least once, so it warns about the use of the "found" variable
in qcom_saw_regulator_probe:

drivers/regulator/qcom_saw-regulator.c: In function 'qcom_saw_regulator_probe':
drivers/regulator/qcom_saw-regulator.c:154:5: error: 'found' is used uninitialized in this function [-Werror=uninitialized]

This adds an explicit initialization to avoid the warning.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 18bba3b50355 ("regulator: qcom-saw: Add support for SAW regulators")
---
 drivers/regulator/qcom_saw-regulator.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/qcom_saw-regulator.c b/drivers/regulator/qcom_saw-regulator.c
index c800f16adaf0..30af1d380f9f 100644
--- a/drivers/regulator/qcom_saw-regulator.c
+++ b/drivers/regulator/qcom_saw-regulator.c
@@ -137,7 +137,7 @@ static struct saw_vreg *saw_get_drv(struct platform_device *pdev,
 	struct saw_vreg *vreg = NULL;
 	struct device_node *cpu_node, *saw_node;
 	int cpu;
-	bool found;
+	bool found = 0;
 
 	for_each_possible_cpu(cpu) {
 		cpu_node = of_cpu_device_node_get(cpu);
-- 
2.7.0



From maxime.ripard at free-electrons.com  Thu Feb 11 01:41:03 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Feb 2016 10:41:03 +0100
Subject: [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused
In-Reply-To: <CABGGisxORFOxLVQiTZ=gEr6j2JnVcjQxTLJFPa7uG93g46CKwg@mail.gmail.com>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <20160210125936.GD31506@lukather>
 <CABGGisxORFOxLVQiTZ=gEr6j2JnVcjQxTLJFPa7uG93g46CKwg@mail.gmail.com>
Message-ID: <20160211094103.GI31506@lukather>

On Wed, Feb 10, 2016 at 08:02:45AM -0600, Rob Herring wrote:
> On Wed, Feb 10, 2016 at 6:59 AM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > Hi,
> >
> > On Fri, Feb 05, 2016 at 05:59:23PM +0000, Andre Przywara wrote:
> >> Hi Maxime,
> >>
> >> just found this while looking at your current git branch, so sorry for
> >> the late reply.
> >>
> >> CC:ing DT people, since you touch both existing DTs(!) and the binding doc.
> 
> [...]
> 
> >> So are you really breaking all those systems by changing the DT and the
> >> driver in an incompatible way?
> >
> > Yes.
> >
> >> Please correct me if this assessment is wrong, but to me it looks like
> >> any user out there is either stuck with 4.5 at best _or_ will only be
> >> able to run 4.6 and later (depending on which version of the DT she is
> >> using)? And no, switching DTs along with the kernel is _not_ an option.
> >
> > It is. And it is one that every other ARM platform chose. And so did
> > every distribution.
> 
> I do leave it to platform maintainers judgement (perhaps that should
> be reconsidered), but it should still be case by case basis not an all
> out disregard for the ABI. If you decide to ignore the ABI, then there
> is no decision for the distros or other users.
> 
> >> That is not how I understand DT.
> >
> > I'm sorry for that. This has never been something we said was
> > happening.
> >
> >> Also this totally ignores any other DT user (U-Boot, FreeBSD, you
> >> name it).
> >
> > Which all have their own DT copies, with their own bindings, that we
> > (ie Linux) never agreed on.
> 
> That is not really true. There are some differences ATM, but they are
> largely derivatives of the kernel copy and the goal is to align them.
> If we don't maintain an ABI, that will never happen.

At least for us, this is definitely true. The SoCs impacted by this
change are not supported by FreeBSD at all, and the one that are
supported have bindings that do not match the one we have in the
kernel:
https://github.com/freebsd/freebsd/blob/master/sys/boot/fdt/dts/arm/sun4i-a10.dtsi

Over the 10 compatibles used there, 3 are totally different (watchdog,
the SRAM controller and the clock hardware block) and two deviates in
incompatible ways (timer and pinctrl) and one has property that we'd
probably deny (UART, and its current-speed). 6 out of 10 overall.

And U-boot never had any issue in the past with that policy. Tom said
it on several occasions, and it worked for us too, with some minor
compromises we needed, such as keeping some node pathes that U-Boot
was using, even though it turned out to be wrong.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun7i-a20.dtsi#n615

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/e0c1cd6a/attachment.sig>

From lee.jones at linaro.org  Thu Feb 11 01:46:23 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 11 Feb 2016 09:46:23 +0000
Subject: [PATCH v2] mfd: Provide MACRO to declare commonly defined MFD
 cell attributes
In-Reply-To: <56BC4DF9.7050402@nvidia.com>
References: <1455028027-1527-1-git-send-email-lee.jones@linaro.org>
 <20160210153846.GB26950@x1> <56BB7865.3060004@nvidia.com>
 <20160211091036.GZ3782@x1> <56BC4DF9.7050402@nvidia.com>
Message-ID: <20160211094623.GH3782@x1>

On Thu, 11 Feb 2016, Laxman Dewangan wrote:

> 
> On Thursday 11 February 2016 02:40 PM, Lee Jones wrote:
> >On Wed, 10 Feb 2016, Laxman Dewangan wrote:
> >
> >>On Wednesday 10 February 2016 09:08 PM, Lee Jones wrote:
> >>>mfd: Provide MACRO to declare commonly defined MFD cell attributes
> >>>Cc: Laxman Dewangan <ldewangan at nvidia.com>
> >>>Signed-off-by: Lee Jones <lee.jones at linaro.org>
> >>Build passed with this patch when using it.
> >>
> >>Acked-by: Laxman Dewangan <ldewangan at nvidia.com>
> >>
> >>Please let me know if you applying this. I am going to use the macro
> >>from this patch on max77620 series on next spin.
> >As you are the first user, just submit it as 0/1 of your set.
> >
> 
> I saw that it is merged and available in linux-next 20160211.
> So it is fine to not submit this patch again and modify my patch
> assuming it is on tree.

I was going to handle that, but as you wish, either way is fine by
me.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From maxime.ripard at free-electrons.com  Thu Feb 11 01:53:15 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Feb 2016 10:53:15 +0100
Subject: [PATCH v4] clk: sunxi: Refactor A31 PLL6 so that it can be reused
In-Reply-To: <20160210180420.0968c2018bf5fbe54a28a505@free.fr>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <20160204120507.GC4270@lukather>
 <20160204162545.f806fcb64a826d2c3313985b@free.fr>
 <20160210125333.GC31506@lukather>
 <20160210180420.0968c2018bf5fbe54a28a505@free.fr>
Message-ID: <20160211095315.GJ31506@lukather>

Hi,

On Wed, Feb 10, 2016 at 06:04:20PM +0100, Jean-Francois Moine wrote:
> On Wed, 10 Feb 2016 13:53:33 +0100
> Maxime Ripard <maxime.ripard at free-electrons.com> wrote:
> 
> > > I don't agree:
> > > - you changed the DTs of many SoCs without any valid reason,
> > 
> > I did give you a significant number of reasons [1]. The fact that you
> > chose to ignore them is up to you.
> 
> Sorry, I don't see any reason for changing the DT definition of the pll6.
> The clock is named "pll6" with "#clock-cells = <1>;" in all DTs,
> and it works as it is.
> If you want an other clock as "pll8", with the same HW description,
> you must add new code for this clock.

That's not how it works. If an hardware block is strictly identical,
then it should use the same compatible.

The PLL8 is exactly the same one than PLL6, therefore it should use
the same compatible.

> > Except that it doesn't match the hardware and that the parenthood
> > relationship is inversed. The pll6 output is 24 MHz * n * k / 2, as
> > seen in any datasheet that uses it. Your clock driver doesn't
> > represent that fact.
> 
> The datasheet says that the pll6x2 output is 24 MHz * n * k, then, if
> I remember correctly my lessons at primary school, defining pll6 as
> (pll6x2 / 2) gives 24 MHz * n * k / 2 as the pll6 output. No?

Or, you could keep the same parenting relationship that we had and use
a simpler model. Ever heard of Occam's razor (and quite literally for
once)?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/3ad2c0ce/attachment.sig>

From ulf.hansson at linaro.org  Thu Feb 11 01:57:30 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 11 Feb 2016 10:57:30 +0100
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <56BC50C2.7050609@nvidia.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
 <56BB7AF4.8040708@nvidia.com>
 <CAPDyKFrZ6tWBsQC0tyWWeChiZja3h_zcbaiX25ak-Zyp4MzqVw@mail.gmail.com>
 <56BC50C2.7050609@nvidia.com>
Message-ID: <CAPDyKFrdmufsMqNL0U7q5gPEUqsg3SrkrNChcziQjEOjvd30Ng@mail.gmail.com>

On 11 February 2016 at 10:13, Jon Hunter <jonathanh at nvidia.com> wrote:
>
> On 10/02/16 18:25, Ulf Hansson wrote:
>
> [snip]
>
>>>> Perhaps there's a way to allow the generic PM domain to control this
>>>> by itself. If we for example used the struct device corresponding to
>>>> the powergate driver, genpd could use it to distinguish between
>>>> various instances of genpd structs..!? Maybe it would simplify the way
>>>> to deal with removing domains?
>>>
>>> Yes, that would be ideal. However, would have require changing
>>> genpd_init()? I am not sure how genpd would be able to access the device
>>> struct for the powergate driver because we don't provide this via any
>>> API I am aware of? And I am guessing that you don't wish to expose the
>>> gpd_list to the world either.
>>>
>>> If there is an easy way, I am open to it, but looking at it today, I am
>>> not sure I see a simple way in which we could add a new API to do this.
>>> However, may be I am missing something!
>>
>> If we add a new __pm_genpd_init() API, that could require a struct
>> device to be provided. That API will thus invoke the existing
>> pm_genpd_init() but also deal with the extra things needed here.
>>
>> I would also allow such an API to return an error code.
>>
>> Correspondingly, pm_genpd_remove() could be required to be provided
>> with a struct device.
>>
>> Existing users of pm_genpd_init() can then convert to
>> __pm_genpd_init() whenever suitable.
>>
>> Of course, another option is just to add new member in the genpd
>> struct for the struct *device. The caller of pm_genpd_init() could
>> check it, but allow it to be NULL. Although, the pm_genpd_remove() API
>> would require that pointer to the struct device to be set...
>>
>> What do you think?
>
> Yes, sounds good. May be it is simpler just to add a new member and let
> the platform genpd driver handle it.
>
> I am wondering if in addition to pm_genpd_remove(), we then just have a
> function called pm_genpd_remove_tail(), which allows you to pass the
> struct device pointer and will remove the last pm-domain from the
> gpd_list and return the genpd pointer if successful. Internally, it will
> call pm_genpd_remove(). It seems to me that if there are nested
> pm-domains, then we probably want to remove them starting from the tail
> as opposed to the head.
>
> How does that sound?

Why not make pm_genpd_remove() to behave as you describe for
pm_genpd_remove_tail()?
That's probably the only sane way to remove genpds anyhow!?

Kind regards
Uffe


From maxime.ripard at free-electrons.com  Thu Feb 11 02:00:48 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Feb 2016 11:00:48 +0100
Subject: breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi:
 Refactor A31 PLL6 so that it can be reused)
In-Reply-To: <20160210163001.GG2632@leverpostej>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <56BB2D79.6090402@arm.com>
 <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
 <20160210143755.GE31506@lukather>
 <20160210163001.GG2632@leverpostej>
Message-ID: <20160211100048.GK31506@lukather>

On Wed, Feb 10, 2016 at 04:30:01PM +0000, Mark Rutland wrote:
> On Wed, Feb 10, 2016 at 03:37:55PM +0100, Maxime Ripard wrote:
> > Hi Rob,
> > 
> > On Wed, Feb 10, 2016 at 07:42:02AM -0600, Rob Herring wrote:
> > > On Wed, Feb 10, 2016 at 6:30 AM, Andre Przywara <andre.przywara at arm.com> wrote:
> > > > Hi,
> > > >
> > > > just a ping:
> > > >
> > > > Are we really OK with breaking existing DTs in 4.6? (per the code in
> > > > -next: f7d372ba54ea04d528a291b8dbe34716507bb60b, which is this patch).
> > > 
> > > I only warn and make sure people are aware of the issue. I leave that
> > > up to platform maintainers to decide. It depends on the maturity of
> > > the platform and users.
> > 
> > The impacted SoCs support is really partial. For the most supported
> > one, big things like display or sound are totally missing, and we
> > still update them on a regular basis to add support for new
> > devices. As such, users are very likely to upgrade the DT from one
> > version to another just because there's new devices available to
> > them. And the newest SoC impacted just got introduced in 4.5, and only
> > has the UART and MMC devices available.
> > 
> > > If people complain about it then it's their mess. For platforms
> > > supported in distros such as debian or fedora, I would strongly
> > > recommend against breaking compatibility.
> > 
> > None of them are officially supported:
> > https://www.debian.org/releases/stable/armhf/ch02s01.html.en
> > https://fedoraproject.org/wiki/Architectures/ARM#Fedora_23
> > 
> > Only the older one are, and they are not affected by this patch.
> > 
> > > They do ship dtbs, but it's a chicken and egg problem. If dtbs were
> > > stable and provided by firmware, then they wouldn't have to provide
> > > them. If dtbs are unstable, then they have no choice.
> > 
> > And while it might work great on platforms that have all the needed
> > documentation, or a perfect one, which is our case. Almost each
> > release, we discover that something is not working as it was
> > documented, when it was documented in the first place.
> > 
> > It also seems that even on well documented platforms, supported by the
> > vendors, the stable ABI dream is not going to happen:
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Atmel/README#n105
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/arm/marvell,berlin.txt#n4
> 
> To be quite frank, I completely disagree with that stance.
> 
> It seems like the only reason DT bindings aren't remaining stable is
> because people are deliberately ignoring the requirement and reasoning
> for doing so.

And for DT maintainers saying on multiple occasions that it's bad but
ok to break it and / or that they never actually said that it was a
stable ABI...

I'm guessing it could be a stable ABI if there was bindings
reviews. Rob actually started to review a significant amount of
bindings lately, and that's really appreciated, but if you don't
review all the bindings, then we're going to make mistakes.

> I agree that it can be painful, and that we cannot predict the future.
> There will always be bugs.

In our case, we can't even predict the present.

> Having code in mainline comes with responsibilities. One of those is to
> keep said code working for existing users. Otherwise, why bother having
> it in mainline at all?

None of our existing users ever complained.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/395efda0/attachment-0001.sig>

From lars at metafoo.de  Thu Feb 11 01:41:45 2016
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Thu, 11 Feb 2016 10:41:45 +0100
Subject: [PATCH v2] dmaengine: edma: Implement device_synchronize callback
In-Reply-To: <1455181722-32099-1-git-send-email-peter.ujfalusi@ti.com>
References: <1455181722-32099-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <56BC5759.80000@metafoo.de>

On 02/11/2016 10:08 AM, Peter Ujfalusi wrote:
> We need the callback to support the dmaengine_terminate_sync().
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>

Looks good, but I noticed a slight race condition in
edma_completion_handler(). You need to fetch echan->desc while holding the
vchan.lock. Otherwise this can race against terminate_all() and the callback
might get scheduled even though terminate_all() completed and then there is
a race where the synchronize() operation could be called before the callback
gets scheduled, which means it doesn't do its intended job. Highly unlikely
to happen, but theoretically possible.


From jonathanh at nvidia.com  Thu Feb 11 02:13:52 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Thu, 11 Feb 2016 10:13:52 +0000
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <CAPDyKFrdmufsMqNL0U7q5gPEUqsg3SrkrNChcziQjEOjvd30Ng@mail.gmail.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
 <56BB7AF4.8040708@nvidia.com>
 <CAPDyKFrZ6tWBsQC0tyWWeChiZja3h_zcbaiX25ak-Zyp4MzqVw@mail.gmail.com>
 <56BC50C2.7050609@nvidia.com>
 <CAPDyKFrdmufsMqNL0U7q5gPEUqsg3SrkrNChcziQjEOjvd30Ng@mail.gmail.com>
Message-ID: <56BC5EE0.2040804@nvidia.com>


On 11/02/16 09:57, Ulf Hansson wrote:
> On 11 February 2016 at 10:13, Jon Hunter <jonathanh at nvidia.com> wrote:
>>
>> On 10/02/16 18:25, Ulf Hansson wrote:
>>
>> [snip]
>>
>>>>> Perhaps there's a way to allow the generic PM domain to control this
>>>>> by itself. If we for example used the struct device corresponding to
>>>>> the powergate driver, genpd could use it to distinguish between
>>>>> various instances of genpd structs..!? Maybe it would simplify the way
>>>>> to deal with removing domains?
>>>>
>>>> Yes, that would be ideal. However, would have require changing
>>>> genpd_init()? I am not sure how genpd would be able to access the device
>>>> struct for the powergate driver because we don't provide this via any
>>>> API I am aware of? And I am guessing that you don't wish to expose the
>>>> gpd_list to the world either.
>>>>
>>>> If there is an easy way, I am open to it, but looking at it today, I am
>>>> not sure I see a simple way in which we could add a new API to do this.
>>>> However, may be I am missing something!
>>>
>>> If we add a new __pm_genpd_init() API, that could require a struct
>>> device to be provided. That API will thus invoke the existing
>>> pm_genpd_init() but also deal with the extra things needed here.
>>>
>>> I would also allow such an API to return an error code.
>>>
>>> Correspondingly, pm_genpd_remove() could be required to be provided
>>> with a struct device.
>>>
>>> Existing users of pm_genpd_init() can then convert to
>>> __pm_genpd_init() whenever suitable.
>>>
>>> Of course, another option is just to add new member in the genpd
>>> struct for the struct *device. The caller of pm_genpd_init() could
>>> check it, but allow it to be NULL. Although, the pm_genpd_remove() API
>>> would require that pointer to the struct device to be set...
>>>
>>> What do you think?
>>
>> Yes, sounds good. May be it is simpler just to add a new member and let
>> the platform genpd driver handle it.
>>
>> I am wondering if in addition to pm_genpd_remove(), we then just have a
>> function called pm_genpd_remove_tail(), which allows you to pass the
>> struct device pointer and will remove the last pm-domain from the
>> gpd_list and return the genpd pointer if successful. Internally, it will
>> call pm_genpd_remove(). It seems to me that if there are nested
>> pm-domains, then we probably want to remove them starting from the tail
>> as opposed to the head.
>>
>> How does that sound?
> 
> Why not make pm_genpd_remove() to behave as you describe for
> pm_genpd_remove_tail()?
> That's probably the only sane way to remove genpds anyhow!?

Simply to offer flexibility. I could see that for some devices that have
no dependencies between pm-domains and have a static list of pm-domains,
they can simply call pm_genpd_remove() for a given pm-domain. However,
that said, I can envision a case where a single pm-domain would be
removed by itself and so may be there is no benefit?

Cheers
Jon


From maxime.ripard at free-electrons.com  Thu Feb 11 02:16:21 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Feb 2016 11:16:21 +0100
Subject: breaking DT compatibility
In-Reply-To: <56BB61EA.1030805@arm.com>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <56BB2D79.6090402@arm.com>
 <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
 <20160210143755.GE31506@lukather> <56BB61EA.1030805@arm.com>
Message-ID: <20160211101621.GL31506@lukather>

On Wed, Feb 10, 2016 at 04:14:34PM +0000, Andre Przywara wrote:
> > On Wed, Feb 10, 2016 at 07:42:02AM -0600, Rob Herring wrote:
> >> On Wed, Feb 10, 2016 at 6:30 AM, Andre Przywara <andre.przywara at arm.com> wrote:
> >>> Hi,
> >>>
> >>> just a ping:
> >>>
> >>> Are we really OK with breaking existing DTs in 4.6? (per the code in
> >>> -next: f7d372ba54ea04d528a291b8dbe34716507bb60b, which is this patch).
> >>
> >> I only warn and make sure people are aware of the issue. I leave that
> >> up to platform maintainers to decide. It depends on the maturity of
> >> the platform and users.
> > 
> > The impacted SoCs support is really partial. For the most supported
> > one, big things like display or sound are totally missing, and we
> > still update them on a regular basis to add support for new
> > devices. As such, users are very likely to upgrade the DT from one
> > version to another just because there's new devices available to
> > them. And the newest SoC impacted just got introduced in 4.5, and only
> > has the UART and MMC devices available.
> 
> But I still don't see why we have to break things - can't we just
> improve support _without_ breaking compatibility? For instance keeping
> the old behaviour around? I can dig out my old x86 hat and find a
> _compatible_ solution for this, if you prefer ;-)
> Actually doesn't Jean-Francois' patch fixes the PLL8 issue without
> breaking anything?

Are you convinced that merging code that is not going to be used or
tested (and thus maintained) by anyone is a good idea?

Using X86 as an example is quite funny, since I remember on a few
occasions having to reflash my BIOS/UEFI to fix some issues in Linux
(and as it turns out, the last occurence was two weeks ago).

> Also were do you want to draw the line for "partial support"? The
> sun6i-a31.dtsi is around since 3.12, which was released more than 2
> years ago.
> If we want to wait for "stabilization", we will probably wait forever. I
> find discussions about DT stabilization going back to the very beginning
> of DT for ARM - as well as the request for moving the DT bindings out of
> the kernel (which I think we should really eventually do now).

I'd say when we have merged everything that makes it work as it was
intented to?

In this case, it's a multimedia SoCs. So I'd draw the line at once we
had display, sound and VPU. Display is coming, sound seems to be
gaining traction lately, so that doesn't sound that far off.

> Frankly I don't care so much about these particular boards, but just
> want avoid to set a bad example for the future - in particular sneaking
> this behaviour into the arm64 world, where DTs _really_ come with the
> board or are even generated by the (UEFI-)firmware.

Ok, that's a good thing to know, and we'll make sure it won't
happen. What's the policy when the provided DT comes from a vendor in
that case?

> U-Boot already can embed a device tree, sounds like a perfect place to
> have it stored for me - as long as there is _one_ best version of it.

So far, they've been using their own, with some custom properties that
were rejected last time they were submitted.

http://lists.infradead.org/pipermail/linux-rpi-kernel/2015-August/002122.html

So I'm a bit pessimistic about that.

> >> If people complain about it then it's their mess. For platforms
> >> supported in distros such as debian or fedora, I would strongly
> >> recommend against breaking compatibility.
> > 
> > None of them are officially supported:
> > https://www.debian.org/releases/stable/armhf/ch02s01.html.en
> > https://fedoraproject.org/wiki/Architectures/ARM#Fedora_23
> > 
> > Only the older one are, and they are not affected by this patch.
> > 
> >> They do ship dtbs, but it's a chicken and egg problem. If dtbs were
> >> stable and provided by firmware, then they wouldn't have to provide
> >> them. If dtbs are unstable, then they have no choice.
> > 
> > And while it might work great on platforms that have all the needed
> > documentation, or a perfect one, which is our case. Almost each
> > release, we discover that something is not working as it was
> > documented, when it was documented in the first place.
> 
> I understand that it's not an ideal situation for those Allwinner
> chips - but nevertheless I would like us to at least _try_ to comply
> with this idea. As said before: this patch is a nice rework/cleanup
> - but definitely not a good reason to break compatibility.

To be fair, I really want to tend to keep a DT ABI as stable as
possible. I just don't want to commit to it. If it comes in the way of
a nice rework/cleanup, then it shouldn't matter.

But that doesn't make me want to break everything every kernel release
either.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/02d8c8a3/attachment.sig>

From ulf.hansson at linaro.org  Thu Feb 11 02:18:34 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 11 Feb 2016 11:18:34 +0100
Subject: [PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred
 probe for pm_runtime_reinit
In-Reply-To: <1455145370-20301-2-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-2-git-send-email-tony@atomide.com>
Message-ID: <CAPDyKFpAcsfLgtu93P45fTEg11MjdGwREcyeGSS7vt6GWbNu_w@mail.gmail.com>

On 11 February 2016 at 00:02, Tony Lindgren <tony at atomide.com> wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-mmc at vger.kernel.org
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Kevin Hilman <khilman at baylibre.com>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Rafael J. Wysocki <rafael at kernel.org>
> Cc: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Tero Kristo <t-kristo at ti.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> ---
>
> Ulf, I'd like to merge this along with other related fixes via the
> ARM SoC tree if no objections, please review and ack if this look OK
> to you.

I have some other omap_hsmmc patches queued for 4.6, so I prefer to
send this via my mmc tree.

I guess that's okay as well!?

>
> ---
>  drivers/mmc/host/omap_hsmmc.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index b6639ea..32bc112 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1247,7 +1247,7 @@ static int omap_hsmmc_switch_opcond(struct omap_hsmmc_host *host, int vdd)
>         int ret;
>
>         /* Disable the clocks */
> -       pm_runtime_put_sync(host->dev);
> +       pm_runtime_put_sync_suspend(host->dev);

This has no effect.

The mmc core holds a runtime PM usage count for the device anyway, so
the clock won't be disabled.
Please remove this change from the patch.

>         if (host->dbclk)
>                 clk_disable_unprepare(host->dbclk);
>
> @@ -2232,6 +2232,7 @@ err_irq:
>                 dma_release_channel(host->tx_chan);
>         if (host->rx_chan)
>                 dma_release_channel(host->rx_chan);
> +       pm_runtime_dont_use_autosuspend(host->dev);
>         pm_runtime_put_sync(host->dev);
>         pm_runtime_disable(host->dev);
>         if (host->dbclk)
> @@ -2253,6 +2254,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
>         dma_release_channel(host->tx_chan);
>         dma_release_channel(host->rx_chan);
>
> +       pm_runtime_dont_use_autosuspend(host->dev);
>         pm_runtime_put_sync(host->dev);
>         pm_runtime_disable(host->dev);
>         device_init_wakeup(&pdev->dev, false);
> @@ -2285,7 +2287,7 @@ static int omap_hsmmc_suspend(struct device *dev)
>         if (host->dbclk)
>                 clk_disable_unprepare(host->dbclk);
>
> -       pm_runtime_put_sync(host->dev);
> +       pm_runtime_put_sync_suspend(host->dev);

This has no effect, as the PM core prevents runtime suspend during the
system PM phase.
It does so, by increasing the runtime PM usage count
(pm_runtime_get_noresume()).

Please remove this change from patch.

>         return 0;
>  }
>
> --
> 2.7.0
>

Kind regards
Uffe


From jonathanh at nvidia.com  Thu Feb 11 02:26:53 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Thu, 11 Feb 2016 10:26:53 +0000
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <56BC5EE0.2040804@nvidia.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
 <56BB7AF4.8040708@nvidia.com>
 <CAPDyKFrZ6tWBsQC0tyWWeChiZja3h_zcbaiX25ak-Zyp4MzqVw@mail.gmail.com>
 <56BC50C2.7050609@nvidia.com>
 <CAPDyKFrdmufsMqNL0U7q5gPEUqsg3SrkrNChcziQjEOjvd30Ng@mail.gmail.com>
 <56BC5EE0.2040804@nvidia.com>
Message-ID: <56BC61ED.6000201@nvidia.com>



On 11/02/16 10:13, Jon Hunter wrote:
> 
> On 11/02/16 09:57, Ulf Hansson wrote:
>> On 11 February 2016 at 10:13, Jon Hunter <jonathanh at nvidia.com> wrote:
>>>
>>> On 10/02/16 18:25, Ulf Hansson wrote:
>>>
>>> [snip]
>>>
>>>>>> Perhaps there's a way to allow the generic PM domain to control this
>>>>>> by itself. If we for example used the struct device corresponding to
>>>>>> the powergate driver, genpd could use it to distinguish between
>>>>>> various instances of genpd structs..!? Maybe it would simplify the way
>>>>>> to deal with removing domains?
>>>>>
>>>>> Yes, that would be ideal. However, would have require changing
>>>>> genpd_init()? I am not sure how genpd would be able to access the device
>>>>> struct for the powergate driver because we don't provide this via any
>>>>> API I am aware of? And I am guessing that you don't wish to expose the
>>>>> gpd_list to the world either.
>>>>>
>>>>> If there is an easy way, I am open to it, but looking at it today, I am
>>>>> not sure I see a simple way in which we could add a new API to do this.
>>>>> However, may be I am missing something!
>>>>
>>>> If we add a new __pm_genpd_init() API, that could require a struct
>>>> device to be provided. That API will thus invoke the existing
>>>> pm_genpd_init() but also deal with the extra things needed here.
>>>>
>>>> I would also allow such an API to return an error code.
>>>>
>>>> Correspondingly, pm_genpd_remove() could be required to be provided
>>>> with a struct device.
>>>>
>>>> Existing users of pm_genpd_init() can then convert to
>>>> __pm_genpd_init() whenever suitable.
>>>>
>>>> Of course, another option is just to add new member in the genpd
>>>> struct for the struct *device. The caller of pm_genpd_init() could
>>>> check it, but allow it to be NULL. Although, the pm_genpd_remove() API
>>>> would require that pointer to the struct device to be set...
>>>>
>>>> What do you think?
>>>
>>> Yes, sounds good. May be it is simpler just to add a new member and let
>>> the platform genpd driver handle it.
>>>
>>> I am wondering if in addition to pm_genpd_remove(), we then just have a
>>> function called pm_genpd_remove_tail(), which allows you to pass the
>>> struct device pointer and will remove the last pm-domain from the
>>> gpd_list and return the genpd pointer if successful. Internally, it will
>>> call pm_genpd_remove(). It seems to me that if there are nested
>>> pm-domains, then we probably want to remove them starting from the tail
>>> as opposed to the head.
>>>
>>> How does that sound?
>>
>> Why not make pm_genpd_remove() to behave as you describe for
>> pm_genpd_remove_tail()?
>> That's probably the only sane way to remove genpds anyhow!?
> 
> Simply to offer flexibility. I could see that for some devices that have
> no dependencies between pm-domains and have a static list of pm-domains,
> they can simply call pm_genpd_remove() for a given pm-domain. However,
> that said, I can envision a case where a single pm-domain would be
> removed by itself and so may be there is no benefit?

By the way, do you think that instead of passing the struct device * to
pm_genpd_remove(), we should just have a void *dev_id in the same way
the request_irq()/free_irq() work? In other words, it would allow people
to use the struct device or struct device_node, etc?

Cheers
Jon


From ulf.hansson at linaro.org  Thu Feb 11 02:28:19 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 11 Feb 2016 11:28:19 +0100
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <56BC5EE0.2040804@nvidia.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
 <56BB7AF4.8040708@nvidia.com>
 <CAPDyKFrZ6tWBsQC0tyWWeChiZja3h_zcbaiX25ak-Zyp4MzqVw@mail.gmail.com>
 <56BC50C2.7050609@nvidia.com>
 <CAPDyKFrdmufsMqNL0U7q5gPEUqsg3SrkrNChcziQjEOjvd30Ng@mail.gmail.com>
 <56BC5EE0.2040804@nvidia.com>
Message-ID: <CAPDyKFq_0t4tcvkgMBW8p8ubJDALWMjdhgGM+_Z6auRxEkSPdA@mail.gmail.com>

On 11 February 2016 at 11:13, Jon Hunter <jonathanh at nvidia.com> wrote:
>
> On 11/02/16 09:57, Ulf Hansson wrote:
>> On 11 February 2016 at 10:13, Jon Hunter <jonathanh at nvidia.com> wrote:
>>>
>>> On 10/02/16 18:25, Ulf Hansson wrote:
>>>
>>> [snip]
>>>
>>>>>> Perhaps there's a way to allow the generic PM domain to control this
>>>>>> by itself. If we for example used the struct device corresponding to
>>>>>> the powergate driver, genpd could use it to distinguish between
>>>>>> various instances of genpd structs..!? Maybe it would simplify the way
>>>>>> to deal with removing domains?
>>>>>
>>>>> Yes, that would be ideal. However, would have require changing
>>>>> genpd_init()? I am not sure how genpd would be able to access the device
>>>>> struct for the powergate driver because we don't provide this via any
>>>>> API I am aware of? And I am guessing that you don't wish to expose the
>>>>> gpd_list to the world either.
>>>>>
>>>>> If there is an easy way, I am open to it, but looking at it today, I am
>>>>> not sure I see a simple way in which we could add a new API to do this.
>>>>> However, may be I am missing something!
>>>>
>>>> If we add a new __pm_genpd_init() API, that could require a struct
>>>> device to be provided. That API will thus invoke the existing
>>>> pm_genpd_init() but also deal with the extra things needed here.
>>>>
>>>> I would also allow such an API to return an error code.
>>>>
>>>> Correspondingly, pm_genpd_remove() could be required to be provided
>>>> with a struct device.
>>>>
>>>> Existing users of pm_genpd_init() can then convert to
>>>> __pm_genpd_init() whenever suitable.
>>>>
>>>> Of course, another option is just to add new member in the genpd
>>>> struct for the struct *device. The caller of pm_genpd_init() could
>>>> check it, but allow it to be NULL. Although, the pm_genpd_remove() API
>>>> would require that pointer to the struct device to be set...
>>>>
>>>> What do you think?
>>>
>>> Yes, sounds good. May be it is simpler just to add a new member and let
>>> the platform genpd driver handle it.
>>>
>>> I am wondering if in addition to pm_genpd_remove(), we then just have a
>>> function called pm_genpd_remove_tail(), which allows you to pass the
>>> struct device pointer and will remove the last pm-domain from the
>>> gpd_list and return the genpd pointer if successful. Internally, it will
>>> call pm_genpd_remove(). It seems to me that if there are nested
>>> pm-domains, then we probably want to remove them starting from the tail
>>> as opposed to the head.
>>>
>>> How does that sound?
>>
>> Why not make pm_genpd_remove() to behave as you describe for
>> pm_genpd_remove_tail()?
>> That's probably the only sane way to remove genpds anyhow!?
>
> Simply to offer flexibility. I could see that for some devices that have
> no dependencies between pm-domains and have a static list of pm-domains,
> they can simply call pm_genpd_remove() for a given pm-domain. However,
> that said, I can envision a case where a single pm-domain would be
> removed by itself and so may be there is no benefit?

If I understand correctly, you agree to try with the most simple
approach first and thus without providing too much flexibility.

Anyway, I am looking forward to review your next version of the patchset! :-)

Kind regards
Uffe


From lkp at intel.com  Thu Feb 11 02:28:03 2016
From: lkp at intel.com (kbuild test robot)
Date: Thu, 11 Feb 2016 18:28:03 +0800
Subject: [PATCH] dmaengine: omap-dma: Implement device_synchronize callback
In-Reply-To: <1455180894-2672-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <201602111822.fILxzr2p%fengguang.wu@intel.com>

Hi Peter,

[auto build test ERROR on slave-dma/next]
[also build test ERROR on v4.5-rc3 next-20160211]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Peter-Ujfalusi/dmaengine-omap-dma-Implement-device_synchronize-callback/20160211-165914
base:   https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git next
config: arm-multi_v7_defconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/dma/omap-dma.c: In function 'omap_dma_synchronize':
>> drivers/dma/omap-dma.c:1014:20: error: 'c' redeclared as different kind of symbol
     struct omap_chan *c = to_omap_dma_chan(chan);
                       ^
   drivers/dma/omap-dma.c:1012:51: note: previous definition of 'c' was here
    static void omap_dma_synchronize(struct dma_chan *c)
                                                      ^
>> drivers/dma/omap-dma.c:1014:41: error: 'chan' undeclared (first use in this function)
     struct omap_chan *c = to_omap_dma_chan(chan);
                                            ^
   drivers/dma/omap-dma.c:1014:41: note: each undeclared identifier is reported only once for each function it appears in
   drivers/dma/omap-dma.c: In function 'omap_dma_probe':
>> drivers/dma/omap-dma.c:1122:5: error: 'ddev' undeclared (first use in this function)
     od-ddev.device_synchronize = omap_dma_synchronize;
        ^

vim +/c +1014 drivers/dma/omap-dma.c

  1006		spin_unlock_irqrestore(&c->vc.lock, flags);
  1007		vchan_dma_desc_free_list(&c->vc, &head);
  1008	
  1009		return 0;
  1010	}
  1011	
> 1012	static void omap_dma_synchronize(struct dma_chan *c)
  1013	{
> 1014		struct omap_chan *c = to_omap_dma_chan(chan);
  1015	
  1016		vchan_synchronize(&c->vc);
  1017	}
  1018	
  1019	static int omap_dma_pause(struct dma_chan *chan)
  1020	{
  1021		struct omap_chan *c = to_omap_dma_chan(chan);
  1022	
  1023		/* Pause/Resume only allowed with cyclic mode */
  1024		if (!c->cyclic)
  1025			return -EINVAL;
  1026	
  1027		if (!c->paused) {
  1028			omap_dma_stop(c);
  1029			c->paused = true;
  1030		}
  1031	
  1032		return 0;
  1033	}
  1034	
  1035	static int omap_dma_resume(struct dma_chan *chan)
  1036	{
  1037		struct omap_chan *c = to_omap_dma_chan(chan);
  1038	
  1039		/* Pause/Resume only allowed with cyclic mode */
  1040		if (!c->cyclic)
  1041			return -EINVAL;
  1042	
  1043		if (c->paused) {
  1044			mb();
  1045	
  1046			/* Restore channel link register */
  1047			omap_dma_chan_write(c, CLNK_CTRL, c->desc->clnk_ctrl);
  1048	
  1049			omap_dma_start(c, c->desc);
  1050			c->paused = false;
  1051		}
  1052	
  1053		return 0;
  1054	}
  1055	
  1056	static int omap_dma_chan_init(struct omap_dmadev *od)
  1057	{
  1058		struct omap_chan *c;
  1059	
  1060		c = kzalloc(sizeof(*c), GFP_KERNEL);
  1061		if (!c)
  1062			return -ENOMEM;
  1063	
  1064		c->reg_map = od->reg_map;
  1065		c->vc.desc_free = omap_dma_desc_free;
  1066		vchan_init(&c->vc, &od->ddev);
  1067	
  1068		return 0;
  1069	}
  1070	
  1071	static void omap_dma_free(struct omap_dmadev *od)
  1072	{
  1073		while (!list_empty(&od->ddev.channels)) {
  1074			struct omap_chan *c = list_first_entry(&od->ddev.channels,
  1075				struct omap_chan, vc.chan.device_node);
  1076	
  1077			list_del(&c->vc.chan.device_node);
  1078			tasklet_kill(&c->vc.task);
  1079			kfree(c);
  1080		}
  1081	}
  1082	
  1083	#define OMAP_DMA_BUSWIDTHS	(BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
  1084					 BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
  1085					 BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
  1086	
  1087	static int omap_dma_probe(struct platform_device *pdev)
  1088	{
  1089		struct omap_dmadev *od;
  1090		struct resource *res;
  1091		int rc, i, irq;
  1092	
  1093		od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
  1094		if (!od)
  1095			return -ENOMEM;
  1096	
  1097		res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
  1098		od->base = devm_ioremap_resource(&pdev->dev, res);
  1099		if (IS_ERR(od->base))
  1100			return PTR_ERR(od->base);
  1101	
  1102		od->plat = omap_get_plat_info();
  1103		if (!od->plat)
  1104			return -EPROBE_DEFER;
  1105	
  1106		od->reg_map = od->plat->reg_map;
  1107	
  1108		dma_cap_set(DMA_SLAVE, od->ddev.cap_mask);
  1109		dma_cap_set(DMA_CYCLIC, od->ddev.cap_mask);
  1110		dma_cap_set(DMA_MEMCPY, od->ddev.cap_mask);
  1111		od->ddev.device_alloc_chan_resources = omap_dma_alloc_chan_resources;
  1112		od->ddev.device_free_chan_resources = omap_dma_free_chan_resources;
  1113		od->ddev.device_tx_status = omap_dma_tx_status;
  1114		od->ddev.device_issue_pending = omap_dma_issue_pending;
  1115		od->ddev.device_prep_slave_sg = omap_dma_prep_slave_sg;
  1116		od->ddev.device_prep_dma_cyclic = omap_dma_prep_dma_cyclic;
  1117		od->ddev.device_prep_dma_memcpy = omap_dma_prep_dma_memcpy;
  1118		od->ddev.device_config = omap_dma_slave_config;
  1119		od->ddev.device_pause = omap_dma_pause;
  1120		od->ddev.device_resume = omap_dma_resume;
  1121		od->ddev.device_terminate_all = omap_dma_terminate_all;
> 1122		od-ddev.device_synchronize = omap_dma_synchronize;
  1123		od->ddev.src_addr_widths = OMAP_DMA_BUSWIDTHS;
  1124		od->ddev.dst_addr_widths = OMAP_DMA_BUSWIDTHS;
  1125		od->ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 36561 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/7c8db97c/attachment-0001.obj>

From maxime.ripard at free-electrons.com  Thu Feb 11 02:32:30 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Feb 2016 11:32:30 +0100
Subject: [PATCH 11/11] arm64: dts: add Pine64 support
In-Reply-To: <56B47391.1040709@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-12-git-send-email-andre.przywara@arm.com>
 <20160205090337.GB1139@lukather> <56B47391.1040709@arm.com>
Message-ID: <20160211103230.GM31506@lukather>

Hi Andre,

On Fri, Feb 05, 2016 at 10:04:01AM +0000, Andre Przywara wrote:
> >> +&uart0 {
> >> +	pinctrl-names = "default";
> >> +	pinctrl-0 = <&uart0_pins_a>;
> >> +	status = "okay";
> >> +};
> >> +
> >> +&uart2 {
> >> +	pinctrl-names = "default";
> >> +	pinctrl-0 = <&uart2_pins>;
> >> +	status = "okay";
> >> +};
> >> +
> >> +&uart3 {
> >> +	pinctrl-names = "default";
> >> +	pinctrl-0 = <&uart3_pins_a>;
> >> +	status = "okay";
> >> +};
> >> +
> >> +&uart4 {
> >> +	pinctrl-names = "default";
> >> +	pinctrl-0 = <&uart4_pins>;
> >> +	status = "okay";
> >> +};
> > 
> > Our policy for boards with "open" pin headers the user can plug
> > anything he wants is that unless the pin is explicitly dedicated to
> > that usage, we simply leave them aside so that we don't enforce
> > anything.
> 
> Makes sense, I just wonder what a user is expected to do if she wants to
> use the serial ports?
> Hack the DT?
> Use U-Boot to create those nodes on the fly?
> Use overlays?
> Directly setup serial ports from userland? (thinking of this bloody
> mechanism x86 (used to?) have)

Until we have a configfs overlay interface, then yeah, we have to hack
the DT.

That's not very much different than what you'd have to do if you
wanted some other bus exposed on those pins though.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/c788c0f6/attachment.sig>

From lkp at intel.com  Thu Feb 11 02:36:02 2016
From: lkp at intel.com (kbuild test robot)
Date: Thu, 11 Feb 2016 18:36:02 +0800
Subject: [PATCH] dmaengine: edma: Implement device_synchronize callback
In-Reply-To: <1455180872-2620-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <201602111850.mRht8PrT%fengguang.wu@intel.com>

Hi Peter,

[auto build test ERROR on slave-dma/next]
[also build test ERROR on v4.5-rc3 next-20160211]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Peter-Ujfalusi/dmaengine-edma-Implement-device_synchronize-callback/20160211-170011
base:   https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git next
config: arm-multi_v7_defconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/dma/edma.c: In function 'edma_synchronize':
>> drivers/dma/edma.c:874:41: error: 'chan' undeclared (first use in this function)
     struct edma_chan *echan = to_edma_chan(chan);
                                            ^
   drivers/dma/edma.c:874:41: note: each undeclared identifier is reported only once for each function it appears in

vim +/chan +874 drivers/dma/edma.c

   868	
   869		return 0;
   870	}
   871	
   872	static void edma_synchronize(struct dma_chan *c)
   873	{
 > 874		struct edma_chan *echan = to_edma_chan(chan);
   875	
   876		vchan_synchronize(&echan->vchan);
   877	}

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 36561 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/f59a88ae/attachment-0001.obj>

From ulf.hansson at linaro.org  Thu Feb 11 02:37:53 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 11 Feb 2016 11:37:53 +0100
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <56BC61ED.6000201@nvidia.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
 <56BB7AF4.8040708@nvidia.com>
 <CAPDyKFrZ6tWBsQC0tyWWeChiZja3h_zcbaiX25ak-Zyp4MzqVw@mail.gmail.com>
 <56BC50C2.7050609@nvidia.com>
 <CAPDyKFrdmufsMqNL0U7q5gPEUqsg3SrkrNChcziQjEOjvd30Ng@mail.gmail.com>
 <56BC5EE0.2040804@nvidia.com> <56BC61ED.6000201@nvidia.com>
Message-ID: <CAPDyKFrhVqrJEx2W8E8At=tTiOVc_EN33T+Ozf6Y9o__pkrxuw@mail.gmail.com>

[...]

>>>
>>> Why not make pm_genpd_remove() to behave as you describe for
>>> pm_genpd_remove_tail()?
>>> That's probably the only sane way to remove genpds anyhow!?
>>
>> Simply to offer flexibility. I could see that for some devices that have
>> no dependencies between pm-domains and have a static list of pm-domains,
>> they can simply call pm_genpd_remove() for a given pm-domain. However,
>> that said, I can envision a case where a single pm-domain would be
>> removed by itself and so may be there is no benefit?
>
> By the way, do you think that instead of passing the struct device * to
> pm_genpd_remove(), we should just have a void *dev_id in the same way
> the request_irq()/free_irq() work? In other words, it would allow people
> to use the struct device or struct device_node, etc?

Hmm. Do you think that would make a difference for the power controller drivers?

I am thinking that genpd might perhaps benefit from being able to use
the device pointer for other purposes as well!?
Giving a void *, will prevent that, won't it?

Kind regards
Uffe


From james.morse at arm.com  Thu Feb 11 02:41:08 2016
From: james.morse at arm.com (James Morse)
Date: Thu, 11 Feb 2016 10:41:08 +0000
Subject: [PATCH] arm64: use raw_smp_processor_id in stack backtrace dump
In-Reply-To: <56BB7D7B.4060002@linaro.org>
References: <1455053182-31404-1-git-send-email-yang.shi@linaro.org>
 <20160210102939.GD1052@arm.com> <56BB247F.6040202@arm.com>
 <20160210121030.GH1052@arm.com> <56BB7D7B.4060002@linaro.org>
Message-ID: <56BC6544.70001@arm.com>

Hi!

On 10/02/16 18:12, Shi, Yang wrote:
> On 2/10/2016 4:10 AM, Will Deacon wrote:
>> On Wed, Feb 10, 2016 at 11:52:31AM +0000, James Morse wrote:
>>> On 10/02/16 10:29, Will Deacon wrote:
>>>> On Tue, Feb 09, 2016 at 01:26:22PM -0800, Yang Shi wrote:
>>>>> dump_backtrace may be called in kthread context, which is not bound to a
>>>>> single
>>>>> cpu, i.e. khungtaskd, then calling smp_processor_id may trigger the below bug
>>>>> report:
>>>>
>>>> If we're preemptible here, it means that our irq_stack_ptr is potentially
>>>> bogus. Whilst this isn't an issue for kthreads, it does feel like we
>>>> could make this slightly more robust in the face of potential frame
>>>> corruption. Maybe just zero the IRQ stack pointer if we're in preemptible
>>>> context?
>>>
>>> Switching between stacks is only valid if we are tracing ourselves while on the
>>> irq_stack, we should probably prevent it for other tasks too.
>>>
>>> Something like (untested):
>>> ---------------------
>>> if (tsk == current && in_atomic())
>>>     irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
> 
> One follow up question, is it possible to have both tsk != current and
> on_irq_stack is true at the same time?

No. If you are tracing an irq stack, it must be your own stack.

If this weren't the case, it would be the stack of a running task on a remote
CPU, and you would be racing with the remote CPU changing the values you are
reading. Fortunately nothing tries to do this.

(The third case would be tracing a sleeping irq stack - this doesn't happen
 either, as we switch back to the original stack before calling schedule()).


> If it is possible, this may be a problem
> in unwind_frame called by profile_pc which has tsk being NULL.

Ah, well spotted. I guess there should also be a != NULL comparison thrown into
the mix. I don't think it will be a problem for profile_pc() as it should always
find a !in_lock_functions() frame before it needs to switch stack, (which we are
preventing it from doing). If this ever did happen, it will return 0.


Thanks,

James


From marc.zyngier at arm.com  Thu Feb 11 02:44:18 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 10:44:18 +0000
Subject: [PULL] GIC fixes for 4.5-rc4
Message-ID: <1455187458-28775-1-git-send-email-marc.zyngier@arm.com>

Hi Thomas,

Please find below a pull request for a few GIC fixes that have been on
the list recently, and that I'd like to go in 4.5-rc4.

Thanks,

	M.

The following changes since commit 1a485f4d2e28efd77075b2952926683d6c245633:

  irqchip/gicv3-its: Fix memory leak in its_free_tables() (2016-02-04 15:14:50 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git tags/gic-fixes-4.5-rc4

for you to fetch changes up to 1a1ebd5fb1e203ee8cc73508cc7a38ac4b804596:

  irqchip/gic-v3: Make sure read from ICC_IAR1_EL1 is visible on redestributor (2016-02-11 10:20:02 +0000)

----------------------------------------------------------------
GIC fixes for 4.5-rc4:

- Two fixes addressing cascaded GICv1/GICv2 (affinity setting, EOImode)
- One fix addressing possible missed interrupts on GICv3

----------------------------------------------------------------
Jon Hunter (2):
      irqchip/gic: Only populate set_affinity for the root controller
      irqchip/gic: Only set the EOImodeNS bit for the root controller

Tirumalesh Chalamarla (1):
      irqchip/gic-v3: Make sure read from ICC_IAR1_EL1 is visible on redestributor

 arch/arm64/include/asm/arch_gicv3.h |  1 +
 drivers/irqchip/irq-gic.c           | 13 ++++++-------
 2 files changed, 7 insertions(+), 7 deletions(-)


From linux at arm.linux.org.uk  Thu Feb 11 02:46:50 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 11 Feb 2016 10:46:50 +0000
Subject: [PATCH] tty/serial: digicolor: Fix bad usage of IS_ERR_VALUE
In-Reply-To: <56BAA27A.9050605@roeck-us.net>
References: <1455030539-10798-1-git-send-email-linux@roeck-us.net>
 <4571887.rTPndCnv20@wuerfel> <56BAA27A.9050605@roeck-us.net>
Message-ID: <20160211104650.GU10826@n2100.arm.linux.org.uk>

On Tue, Feb 09, 2016 at 06:37:46PM -0800, Guenter Roeck wrote:
> On 02/09/2016 07:26 AM, Arnd Bergmann wrote:
> >On Tuesday 09 February 2016 07:08:59 Guenter Roeck wrote:
> >>IS_ERR_VALUE() assumes that its parameter is an unsigned long.
> >>It can not be used to check if an unsigned int reflects an error.
> >>Doing so can result in the following build warning.
> >>
> >>drivers/tty/serial/digicolor-usart.c: In function ?digicolor_uart_probe?:
> >>include/linux/err.h:21:38: warning:
> >>         comparison is always false due to limited range of data type
> >>drivers/tty/serial/digicolor-usart.c:485:6: note:
> >>         in expansion of macro ?IS_ERR_VALUE?
> >>
> >>If that warning is seen, an error return from platform_get_irq() is missed.
> >>
> >>
> >
> >The patch looks correct to me, but what compiler version and which kernel
> >tree is it that triggered the warning?
> >
> >Andrzej Hajda just modified the definition of IS_ERR_VALUE(), and the
> >changes are still under discussion, but I don't see that warning with
> >any of the versions.
> >
> I see it with gcc 5.1 and 5.2 (and W=1). I did not see / notice Andrzej's patch.
> 
> I agree that fixing the problem in IS_ERR_VALUE() is preferrable.

I disagree.  What happens if (eg) you decide to do this:

	u8 irq;

	irq = platform_get_irq(...);
	if (IS_ERR_VALUE(irq))
		...

is that the fault of IS_ERR_VALUE() that it will never be true?  No, it's
a programming error in the caller, because the caller is using the wrong
type here - in fact, you can't do anything in IS_ERR_VALUE() to correct
that.

The same is true if you assign an error value to an unsigned int: the
problem is in the caller, not in IS_ERR_VALUE().

What would be preferable is if there was some way IS_ERR_VALUE() could
detect if it's used on something that isn't at least a short, and is
signed, but I suspect coccinelle can do that much better than trying to
work out some way to get the C compiler to check that.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From daniel at ffwll.ch  Thu Feb 11 02:49:21 2016
From: daniel at ffwll.ch (Daniel Vetter)
Date: Thu, 11 Feb 2016 11:49:21 +0100
Subject: [PATCH] drm/msm: remove unused variable
In-Reply-To: <1455181810-3910161-1-git-send-email-arnd@arndb.de>
References: <1455181810-3910161-1-git-send-email-arnd@arndb.de>
Message-ID: <20160211104921.GT11240@phenom.ffwll.local>

On Thu, Feb 11, 2016 at 10:10:00AM +0100, Arnd Bergmann wrote:
> After the drm_device_is_unplugged() was removed, the 'dev' variable is now
> unused, and we get a warning for that:
> 
> drivers/gpu/drm/msm/msm_fbdev.c: In function 'msm_fbdev_mmap':
> drivers/gpu/drm/msm/msm_fbdev.c:65:21: error: unused variable 'dev' [-Werror=unused-variable]
> 
> This removes the variable as well.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: e9f8250f2f92 ("drm/msm: remove the drm_device_is_unplugged check")

Applied, thanks.
-Daniel

> ---
>  drivers/gpu/drm/msm/msm_fbdev.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
> index e119c2979509..d9759bf3482e 100644
> --- a/drivers/gpu/drm/msm/msm_fbdev.c
> +++ b/drivers/gpu/drm/msm/msm_fbdev.c
> @@ -62,7 +62,6 @@ static int msm_fbdev_mmap(struct fb_info *info, struct vm_area_struct *vma)
>  	struct drm_fb_helper *helper = (struct drm_fb_helper *)info->par;
>  	struct msm_fbdev *fbdev = to_msm_fbdev(helper);
>  	struct drm_gem_object *drm_obj = fbdev->bo;
> -	struct drm_device *dev = helper->dev;
>  	int ret = 0;
>  
>  	ret = drm_gem_mmap_obj(drm_obj, drm_obj->size, vma);
> -- 
> 2.7.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From marc.zyngier at arm.com  Thu Feb 11 02:49:03 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 10:49:03 +0000
Subject: [PATCH] arm/arm64: KVM: Handle out-of-RAM cache maintenance as a
 NOP
In-Reply-To: <20160211084347.GT5171@cbox>
References: <1454942245-18452-1-git-send-email-marc.zyngier@arm.com>
 <20160211084347.GT5171@cbox>
Message-ID: <56BC671F.2070108@arm.com>

On 11/02/16 08:43, Christoffer Dall wrote:
> On Mon, Feb 08, 2016 at 02:37:25PM +0000, Marc Zyngier wrote:
>> So far, our handling of cache maintenance by VA has been pretty
>> simple: Either the access is in the guest RAM and generates a S2
>> fault, which results in the page being mapped RW, or we go down
>> the io_mem_abort() path, and nuke the guest.
>>
>> The first one is fine, but the second one is extremely weird.
>> Treating the CM as an I/O is wrong, and nothing in the ARM ARM
>> indicates that we should generate a fault for something that
>> cannot end-up in the cache anyway (even if the guest maps it,
>> it will keep on faulting at stage-2 for emulation).
>>
>> So let's just skip this instruction, and let the guest get away
>> with it.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm/include/asm/kvm_emulate.h   |  5 +++++
>>  arch/arm/kvm/mmu.c                   | 17 +++++++++++++++++
>>  arch/arm64/include/asm/kvm_emulate.h |  5 +++++
>>  3 files changed, 27 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/kvm_emulate.h b/arch/arm/include/asm/kvm_emulate.h
>> index 3095df0..f768797 100644
>> --- a/arch/arm/include/asm/kvm_emulate.h
>> +++ b/arch/arm/include/asm/kvm_emulate.h
>> @@ -143,6 +143,11 @@ static inline bool kvm_vcpu_dabt_iss1tw(struct kvm_vcpu *vcpu)
>>  	return kvm_vcpu_get_hsr(vcpu) & HSR_DABT_S1PTW;
>>  }
>>  
>> +static inline bool kvm_vcpu_dabt_iscm(struct kvm_vcpu *vcpu)
>> +{
>> +	return !!(kvm_vcpu_get_hsr(vcpu) & HSR_DABT_CM);
>> +}
>> +
>>  /* Get Access Size from a data abort */
>>  static inline int kvm_vcpu_dabt_get_as(struct kvm_vcpu *vcpu)
>>  {
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index aba61fd..1a5f2ea 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -1431,6 +1431,23 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>  		}
>>  
>>  		/*
>> +		 * Check for a cache maintenance operation. Since we
>> +		 * ended-up here, we know it is outside of any memory
>> +		 * slot. But we can't find out if that is for a device,
>> +		 * or if the guest is just being stupid (going all the
>> +		 * way to userspace is not an option - what would you
>> +		 * write?).
> 
> I'm not sure what the stuff about "what would you write?" means, I'm
> assuming it means that the ISV bit is clear.

What I was trying to say that is that if you really wanted to find out
whether the range the guest is trying to access is a device or just a
non-existent address, you'd have to go all the way to userspace to check
that there is actually a device there. But then, what should the access
be? Read or Write? We don't have a non-destructive "check access" operation.

> I think the point is more that if there's no S2 mapping, then there
> could never be any cache entries as a result of memory accesses using
> the GVA in question, so there's nothing to invalidate (like you state in
> your commit message).

Agreed. I may just write that instead.

> 
>> +		 *
>> +		 * So let's assume that the guest is just being
>> +		 * cautious, and skip the instruction.
>> +		 */
>> +		if (kvm_vcpu_dabt_iscm(vcpu)) {
>> +			kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
>> +			ret = 1;
>> +			goto out_unlock;
>> +		}
>> +
>> +		/*
>>  		 * The IPA is reported as [MAX:12], so we need to
>>  		 * complement it with the bottom 12 bits from the
>>  		 * faulting VA. This is always 12 bits, irrespective
>> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
>> index 3066328..01cdf5f 100644
>> --- a/arch/arm64/include/asm/kvm_emulate.h
>> +++ b/arch/arm64/include/asm/kvm_emulate.h
>> @@ -185,6 +185,11 @@ static inline bool kvm_vcpu_dabt_iss1tw(const struct kvm_vcpu *vcpu)
>>  	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_S1PTW);
>>  }
>>  
>> +static inline bool kvm_vcpu_dabt_iscm(const struct kvm_vcpu *vcpu)
>> +{
>> +	return !!(kvm_vcpu_get_hsr(vcpu) & ESR_ELx_CM);
>> +}
>> +
>>  static inline int kvm_vcpu_dabt_get_as(const struct kvm_vcpu *vcpu)
>>  {
>>  	return 1 << ((kvm_vcpu_get_hsr(vcpu) & ESR_ELx_SAS) >> ESR_ELx_SAS_SHIFT);
>> -- 
>> 2.1.4
>>
> 
> some nitpicking: if you modify anything here, I think is_cm is more clear than iscm.

Fair enough, I'll amend it.

> 
> But besides the cosmetics:
> 
> Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
> 

Thanks!

	M.
-- 
Jazz is not dead. It just smells funny...


From jonathanh at nvidia.com  Thu Feb 11 02:52:31 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Thu, 11 Feb 2016 10:52:31 +0000
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <CAPDyKFrhVqrJEx2W8E8At=tTiOVc_EN33T+Ozf6Y9o__pkrxuw@mail.gmail.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
 <56BB7AF4.8040708@nvidia.com>
 <CAPDyKFrZ6tWBsQC0tyWWeChiZja3h_zcbaiX25ak-Zyp4MzqVw@mail.gmail.com>
 <56BC50C2.7050609@nvidia.com>
 <CAPDyKFrdmufsMqNL0U7q5gPEUqsg3SrkrNChcziQjEOjvd30Ng@mail.gmail.com>
 <56BC5EE0.2040804@nvidia.com> <56BC61ED.6000201@nvidia.com>
 <CAPDyKFrhVqrJEx2W8E8At=tTiOVc_EN33T+Ozf6Y9o__pkrxuw@mail.gmail.com>
Message-ID: <56BC67EF.4080206@nvidia.com>


On 11/02/16 10:37, Ulf Hansson wrote:
> [...]
> 
>>>>
>>>> Why not make pm_genpd_remove() to behave as you describe for
>>>> pm_genpd_remove_tail()?
>>>> That's probably the only sane way to remove genpds anyhow!?
>>>
>>> Simply to offer flexibility. I could see that for some devices that have
>>> no dependencies between pm-domains and have a static list of pm-domains,
>>> they can simply call pm_genpd_remove() for a given pm-domain. However,
>>> that said, I can envision a case where a single pm-domain would be
>>> removed by itself and so may be there is no benefit?
>>
>> By the way, do you think that instead of passing the struct device * to
>> pm_genpd_remove(), we should just have a void *dev_id in the same way
>> the request_irq()/free_irq() work? In other words, it would allow people
>> to use the struct device or struct device_node, etc?
> 
> Hmm. Do you think that would make a difference for the power controller drivers?
> 
> I am thinking that genpd might perhaps benefit from being able to use
> the device pointer for other purposes as well!?
> Giving a void *, will prevent that, won't it?

Yes it will. Ok, let's stick with struct device for now.

Cheers
Jon


From matthias.bgg at gmail.com  Thu Feb 11 02:55:18 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 11 Feb 2016 11:55:18 +0100
Subject: [PATCH v4 5/5] arm: dts: Add pinctrl/GPIO/EINT node for mt2701
In-Reply-To: <1453857883-28436-6-git-send-email-biao.huang@mediatek.com>
References: <1453857883-28436-1-git-send-email-biao.huang@mediatek.com>
 <1453857883-28436-6-git-send-email-biao.huang@mediatek.com>
Message-ID: <56BC6896.6070108@gmail.com>



On 27/01/16 02:24, Biao Huang wrote:
> Add pinctrl and GPIO node to mt2701.dtsi
>
> Signed-off-by: Biao Huang <biao.huang at mediatek.com>
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> ---

Applied, thanks.


From marc.zyngier at arm.com  Thu Feb 11 03:04:26 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 11:04:26 +0000
Subject: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
In-Reply-To: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
References: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
Message-ID: <56BC6ABA.5020605@arm.com>

On 09/02/16 11:04, Robin Murphy wrote:
> The existing msi-map code is fine for shifting the entire RID space
> upwards, but attempting finer-grained remapping reveals a bug. It turns
> out that we are mistakenly treating the msi-base part as an offset, not
> as a new base to remap onto, so things get squiffy when rid-base is
> nonzero. Fix this, and at the same time add a sanity check against
> having msi-map-mask clash with a nonzero rid-base, as that's another
> thing one can easily get wrong.
> 
> CC: <stable at vger.kernel.org>
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>

Rob, Frank,

Are you willing to take this one through the OF tree? Or should we route
it through the IRQ tree? It'd be good if it make it into 4.5.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From lee.jones at linaro.org  Thu Feb 11 03:08:38 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 11 Feb 2016 11:08:38 +0000
Subject: [PATCH 01/14] mfd: intel_quark_i2c_gpio: Use clkdev_create()
In-Reply-To: <1454982341-22715-2-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
 <1454982341-22715-2-git-send-email-sboyd@codeaurora.org>
Message-ID: <20160211110838.GI3782@x1>

Stephen,

The upstream patch.  Enjoy!

The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3:

  Linux 4.5-rc2 (2016-01-31 18:12:16 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/ib-mfd-clk-v4.6

for you to fetch changes up to c4726abce63bf9b1887ce68fdf012a823bd94ec3:

  mfd: intel_quark_i2c_gpio: Use clkdev_create() (2016-02-11 11:03:07 +0000)

----------------------------------------------------------------
Immutable branch between MFD and Clk due for v4.6

----------------------------------------------------------------
Stephen Boyd (1):
      mfd: intel_quark_i2c_gpio: Use clkdev_create()

 drivers/mfd/intel_quark_i2c_gpio.c | 26 +++++++++-----------------
 1 file changed, 9 insertions(+), 17 deletions(-)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From peter.ujfalusi at ti.com  Thu Feb 11 03:12:20 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 11 Feb 2016 13:12:20 +0200
Subject: [PATCH v2] dmaengine: edma: Implement device_synchronize callback
In-Reply-To: <56BC5759.80000@metafoo.de>
References: <1455181722-32099-1-git-send-email-peter.ujfalusi@ti.com>
 <56BC5759.80000@metafoo.de>
Message-ID: <56BC6C94.1060409@ti.com>

On 02/11/2016 11:41 AM, Lars-Peter Clausen wrote:
> On 02/11/2016 10:08 AM, Peter Ujfalusi wrote:
>> We need the callback to support the dmaengine_terminate_sync().
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> 
> Looks good, but I noticed a slight race condition in
> edma_completion_handler(). You need to fetch echan->desc while holding the
> vchan.lock. Otherwise this can race against terminate_all() and the callback
> might get scheduled even though terminate_all() completed and then there is
> a race where the synchronize() operation could be called before the callback
> gets scheduled, which means it doesn't do its intended job. Highly unlikely
> to happen, but theoretically possible.

Right, actually I had (have) another series fixing the very same race in a
different way - patching the terminate_all (series attached).
We have seen race with RT kernel on uniprocessor setup.

The tasklet_kill after the terminate_all will execute the scheduled task
unconditionally, so the vchan_complete() will run after we have terminated the
channel, which might be not what we want.
I have also seen a race condition as explained in the first patch. The only
way I was able to fix that by using the attached patches. Unfortunately I can
not test RT with mainline yet, so I'm not 100% sure if by using the
dmaengine_terminate_sync() in drivers will fix the issue.

-- 
P?ter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dmaengine-virt-dma-Support-for-ignoring-callback-aft.patch
Type: text/x-patch
Size: 4081 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/26d818cd/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-dmaengine-omap-dma-Prevent-race-between-vchan_comple.patch
Type: text/x-patch
Size: 1215 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/26d818cd/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-dmaengine-edma-Prevent-race-between-vchan_complete-a.patch
Type: text/x-patch
Size: 1230 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/26d818cd/attachment-0005.bin>

From davem at davemloft.net  Thu Feb 11 03:15:27 2016
From: davem at davemloft.net (David Miller)
Date: Thu, 11 Feb 2016 06:15:27 -0500 (EST)
Subject: [PATCH net-next V2 0/8] net: fec: cleanup/fixes
In-Reply-To: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <20160211.061527.2243215315106334340.davem@davemloft.net>

From: Troy Kisky <troy.kisky at boundarydevices.com>
Date: Fri,  5 Feb 2016 14:52:42 -0700

> 
> V2 is a rebase on top of johannes endian-safe patch and
> is only the 1st eight patches.
> The testing for this series was done on a nitrogen6x.
> The base commit was
> commit b45efa30a626e915192a6c548cd8642379cd47cc
>     Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> 
> Testing showed no change in performance.
> Testing used imx_v6_v7_defconfig + CONFIG_MICREL_PHY.
> The processor was running at 996Mhz.
> The following commands were used to get the transfer rates.
> 
> On an x86 ubunto system,
> iperf -s -i.5 -u
> 
> 
> On a nitrogen6x board, running via SD Card.
> I first stopped some background processes
> 
> stop cron
> stop upstart-file-bridge
> stop upstart-socket-bridge
> stop upstart-udev-bridge
> stop rsyslog
> stop dbus
> killall dhclient
> echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> 
> taskset 0x2 iperf -c 192.168.0.201 -u -t60 -b500M -r
> 
> There is a branch available on github with this series, and the rest of
> my fec patches, for those who would like to test it.
> https://github.com:boundarydevices/linux-imx6.git branch net-next_master

Series applied, thanks.


From matthias.bgg at gmail.com  Thu Feb 11 03:25:07 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 11 Feb 2016 12:25:07 +0100
Subject: [PATCH V5 09/11] soc: mediatek: PMIC wrap: add a slave specific
 struct
In-Reply-To: <1454841778-35529-10-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
 <1454841778-35529-10-git-send-email-blogic@openwrt.org>
Message-ID: <56BC6F93.8020600@gmail.com>



On 07/02/16 11:42, John Crispin wrote:
> This patch adds a new struct pwrap_slv_type that we use to store the slave
> specific data. The patch adds 2 new helper functions to access the dew
> registers. The slave type is looked up via the wrappers child node.
>
> Signed-off-by: John Crispin <blogic at openwrt.org>
> ---
> Changes in V5
> * drop the dew i/o wrappers
>
> Changed in V4
> * drop unused MT8173 specifc variable declarations
>
>   drivers/soc/mediatek/mtk-pmic-wrap.c |  157 ++++++++++++++++++++++++----------
>   1 file changed, 110 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index fbf94e4..2628271 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -69,33 +69,52 @@
>   					  PWRAP_WDT_SRC_EN_HARB_STAUPD_DLE | \
>   					  PWRAP_WDT_SRC_EN_HARB_STAUPD_ALE)
>
> -/* macro for slave device wrapper registers */
> -#define PWRAP_DEW_BASE			0xbc00
> -#define PWRAP_DEW_EVENT_OUT_EN		(PWRAP_DEW_BASE + 0x0)
> -#define PWRAP_DEW_DIO_EN		(PWRAP_DEW_BASE + 0x2)
> -#define PWRAP_DEW_EVENT_SRC_EN		(PWRAP_DEW_BASE + 0x4)
> -#define PWRAP_DEW_EVENT_SRC		(PWRAP_DEW_BASE + 0x6)
> -#define PWRAP_DEW_EVENT_FLAG		(PWRAP_DEW_BASE + 0x8)
> -#define PWRAP_DEW_READ_TEST		(PWRAP_DEW_BASE + 0xa)
> -#define PWRAP_DEW_WRITE_TEST		(PWRAP_DEW_BASE + 0xc)
> -#define PWRAP_DEW_CRC_EN		(PWRAP_DEW_BASE + 0xe)
> -#define PWRAP_DEW_CRC_VAL		(PWRAP_DEW_BASE + 0x10)
> -#define PWRAP_DEW_MON_GRP_SEL		(PWRAP_DEW_BASE + 0x12)
> -#define PWRAP_DEW_MON_FLAG_SEL		(PWRAP_DEW_BASE + 0x14)
> -#define PWRAP_DEW_EVENT_TEST		(PWRAP_DEW_BASE + 0x16)
> -#define PWRAP_DEW_CIPHER_KEY_SEL	(PWRAP_DEW_BASE + 0x18)
> -#define PWRAP_DEW_CIPHER_IV_SEL		(PWRAP_DEW_BASE + 0x1a)
> -#define PWRAP_DEW_CIPHER_LOAD		(PWRAP_DEW_BASE + 0x1c)
> -#define PWRAP_DEW_CIPHER_START		(PWRAP_DEW_BASE + 0x1e)
> -#define PWRAP_DEW_CIPHER_RDY		(PWRAP_DEW_BASE + 0x20)
> -#define PWRAP_DEW_CIPHER_MODE		(PWRAP_DEW_BASE + 0x22)
> -#define PWRAP_DEW_CIPHER_SWRST		(PWRAP_DEW_BASE + 0x24)
> -#define PWRAP_MT8173_DEW_CIPHER_IV0	(PWRAP_DEW_BASE + 0x26)
> -#define PWRAP_MT8173_DEW_CIPHER_IV1	(PWRAP_DEW_BASE + 0x28)
> -#define PWRAP_MT8173_DEW_CIPHER_IV2	(PWRAP_DEW_BASE + 0x2a)
> -#define PWRAP_MT8173_DEW_CIPHER_IV3	(PWRAP_DEW_BASE + 0x2c)
> -#define PWRAP_MT8173_DEW_CIPHER_IV4	(PWRAP_DEW_BASE + 0x2e)
> -#define PWRAP_MT8173_DEW_CIPHER_IV5	(PWRAP_DEW_BASE + 0x30)
> +/* defines for slave device wrapper registers */
> +enum dew_regs {
> +	PWRAP_DEW_BASE,
> +	PWRAP_DEW_EVENT_OUT_EN,
> +	PWRAP_DEW_DIO_EN,
> +	PWRAP_DEW_EVENT_SRC_EN,
> +	PWRAP_DEW_EVENT_SRC,
> +	PWRAP_DEW_EVENT_FLAG,
> +	PWRAP_DEW_READ_TEST,
> +	PWRAP_DEW_WRITE_TEST,
> +	PWRAP_DEW_CRC_EN,
> +	PWRAP_DEW_CRC_VAL,
> +	PWRAP_DEW_MON_GRP_SEL,
> +	PWRAP_DEW_MON_FLAG_SEL,
> +	PWRAP_DEW_EVENT_TEST,
> +	PWRAP_DEW_CIPHER_KEY_SEL,
> +	PWRAP_DEW_CIPHER_IV_SEL,
> +	PWRAP_DEW_CIPHER_LOAD,
> +	PWRAP_DEW_CIPHER_START,
> +	PWRAP_DEW_CIPHER_RDY,
> +	PWRAP_DEW_CIPHER_MODE,
> +	PWRAP_DEW_CIPHER_SWRST,
> +};

Comparing with the implementation of MT6323, the following registers 
seem MT6397 only:
PWRAP_DEW_EVENT_OUT_EN
PWRAP_DEW_EVENT_SRC_EN,
PWRAP_DEW_EVENT_SRC
PWRAP_DEW_EVENT_FLAG
PWRAP_DEW_MON_FLAG_SEL
PWRAP_DEW_EVENT_TEST
PWRAP_DEW_CIPHER_LOAD
PWRAP_DEW_CIPHER_START

Can you please check that and put the ones which are really MT6397 only 
in a separate paragraph?

Thanks,
Matthias


From matthias.bgg at gmail.com  Thu Feb 11 03:27:41 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 11 Feb 2016 12:27:41 +0100
Subject: [PATCH V5 10/11] soc: mediatek: PMIC wrap: add mt6323 slave
 support
In-Reply-To: <1454841778-35529-11-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
 <1454841778-35529-11-git-send-email-blogic@openwrt.org>
Message-ID: <56BC702D.8030806@gmail.com>



On 07/02/16 11:42, John Crispin wrote:
> Add support for MT6323 slaves. This PMIC can be found on MT2701 and MT7623
> EVB. The only function that we need to touch is pwrap_init_cipher().
>
> Signed-off-by: John Crispin <blogic at openwrt.org>
> ---
>   drivers/soc/mediatek/mtk-pmic-wrap.c |   47 ++++++++++++++++++++++++++++++++++
>   1 file changed, 47 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index 2628271..5fbdd5c 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -91,6 +91,31 @@ enum dew_regs {
>   	PWRAP_DEW_CIPHER_RDY,
>   	PWRAP_DEW_CIPHER_MODE,
>   	PWRAP_DEW_CIPHER_SWRST,
> +
> +	/* MT6323 only regs */
> +	PWRAP_DEW_CRC_SWRST,
> +	PWRAP_DEW_CIPHER_EN,
> +	PWRAP_DEW_RDDMY_NO,
> +	PWRAP_DEW_RDATA_DLY_SEL,
> +};

We just use PWRAP_DEW_CIPHER_EN, right?
I think it makes the code more readable if we just declare the registers 
we actually need.

Thanks,
Matthias


From bp at alien8.de  Thu Feb 11 03:27:58 2016
From: bp at alien8.de (Borislav Petkov)
Date: Thu, 11 Feb 2016 12:27:58 +0100
Subject: [PATCHv10 2/4] ARM: dts: Add Altera L2 Cache and OCRAM EDAC
 entries
In-Reply-To: <1455132384-17108-2-git-send-email-tthayer@opensource.altera.com>
References: <1455132384-17108-1-git-send-email-tthayer@opensource.altera.com>
 <1455132384-17108-2-git-send-email-tthayer@opensource.altera.com>
Message-ID: <20160211112758.GA5565@pd.tnic>

On Wed, Feb 10, 2016 at 01:26:22PM -0600, tthayer at opensource.altera.com wrote:
> From: Thor Thayer <tthayer at opensource.altera.com>
> 
> Adding the device tree entries and bindings needed to support
> the Altera L2 cache and On-Chip RAM EDAC. This patch relies upon
> an earlier patch to declare and setup On-chip RAM properly.
> http://www.spinics.net/lists/devicetree/msg51117.html

For the future, please use git commit IDs and not some, probably
unstable URLs:

  8b907c8b62ac ("arm: dts: socfpga: Add OCRAM node")

I've fixed it now while applying.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.


From bp at alien8.de  Thu Feb 11 03:35:54 2016
From: bp at alien8.de (Borislav Petkov)
Date: Thu, 11 Feb 2016 12:35:54 +0100
Subject: [PATCHv10 1/4] EDAC, altera: Add Altera L2 Cache and OCRAM EDAC
 Support
In-Reply-To: <1455132384-17108-1-git-send-email-tthayer@opensource.altera.com>
References: <1455132384-17108-1-git-send-email-tthayer@opensource.altera.com>
Message-ID: <20160211113554.GB5565@pd.tnic>

On Wed, Feb 10, 2016 at 01:26:21PM -0600, tthayer at opensource.altera.com wrote:
> From: Thor Thayer <tthayer at opensource.altera.com>
> 
> Adding L2 Cache and On-Chip RAM EDAC support for the
> Altera SoCs using the EDAC device  model. The SDRAM
> controller is using the Memory Controller model.
> 
> Each type of ECC is individually configurable.

All 4 applied, thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.


From gnurou at gmail.com  Thu Feb 11 03:35:44 2016
From: gnurou at gmail.com (Alexandre Courbot)
Date: Thu, 11 Feb 2016 20:35:44 +0900
Subject: [PATCH V3] ARM64: tegra: Add support for Google Pixel C
In-Reply-To: <56BC4C91.6070409@nvidia.com>
References: <1454949199-27050-1-git-send-email-jonathanh@nvidia.com>
 <1455020809-17531-1-git-send-email-jonathanh@nvidia.com>
 <CAAVeFuJt+VdJb4S3PC-RXVFYhLnq7yF+dV_w5or=0ebG+LnnGw@mail.gmail.com>
 <56BC4C91.6070409@nvidia.com>
Message-ID: <CAAVeFuKKGW9-0bO6wkCL=i7P0XJ4Mx44BD3A5EvN8G4sS1NyXA@mail.gmail.com>

On Thu, Feb 11, 2016 at 5:55 PM, Jon Hunter <jonathanh at nvidia.com> wrote:
>
> On 11/02/16 08:32, Alexandre Courbot wrote:
>> On Tue, Feb 9, 2016 at 9:26 PM, Jon Hunter <jonathanh at nvidia.com> wrote:
>>> Add initial device-tree support for Google Pixel C (a.k.a. Smaug) based
>>> upon Tegra210 SoC with 3 GiB of LPDDR4 RAM.
>>>
>>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
>>
>> I need to add "clk_ignore_unused=1" to the bootargs in order to avoid
>> a hang during boot, but otherwise can reach a serial console.
>
> Were you testing on -next? If so, you should not need that. Otherwise,
> please make sure you have this patch [0]. Thierry has included this in a
> clock fixes series that should turn up in main soon.

In one of my moments of stupidity, I was on 4.5-rc3. Adding the patch
you mention makes boot complete without issues.

Thanks,
Alex.


From matthias.bgg at gmail.com  Thu Feb 11 03:41:51 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 11 Feb 2016 12:41:51 +0100
Subject: [PATCH V5 11/11] soc: mediatek: PMIC wrap: add MT2701/7623 support
In-Reply-To: <1454841778-35529-12-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
 <1454841778-35529-12-git-send-email-blogic@openwrt.org>
Message-ID: <56BC737F.9070503@gmail.com>



On 07/02/16 11:42, John Crispin wrote:
> Add the registers, callbacks and data structures required to make the
> wrapper work on MT2701 and MT7623.
>
> Signed-off-by: John Crispin <blogic at openwrt.org>
> ---
>   drivers/soc/mediatek/mtk-pmic-wrap.c |  162 ++++++++++++++++++++++++++++++++++
>   1 file changed, 162 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index 5fbdd5c..ee6d917 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -52,6 +52,7 @@
>   #define PWRAP_DEW_WRITE_TEST_VAL	0xa55a
>
>   /* macro for manual command */
> +#define PWRAP_MAN_CMD_SPI_WRITE_NEW	(1 << 14)
>   #define PWRAP_MAN_CMD_SPI_WRITE		(1 << 13)
>   #define PWRAP_MAN_CMD_OP_CSH		(0x0 << 8)
>   #define PWRAP_MAN_CMD_OP_CSL		(0x1 << 8)
> @@ -202,6 +203,17 @@ enum pwrap_regs {
>   	PWRAP_DCM_EN,
>   	PWRAP_DCM_DBC_PRD,
>
> +	/* MT2701 only regs */
> +	PWRAP_OP_TYPE,
> +	PWRAP_MSB_FIRST,
> +	PWRAP_GPS_STA,
> +	PWRAP_ADC_CMD_ADDR,
> +	PWRAP_PWRAP_ADC_CMD,
> +	PWRAP_ADC_RDY_ADDR,
> +	PWRAP_ADC_RDATA_ADDR1,
> +	PWRAP_ADC_RDATA_ADDR2,
> +	PWRAP_ADC_WRAP_SEL,
> +

Same here, we should just declare the registers actually used.

Thanks,
Matthias


From robert.richter at caviumnetworks.com  Thu Feb 11 03:42:04 2016
From: robert.richter at caviumnetworks.com (Robert Richter)
Date: Thu, 11 Feb 2016 12:42:04 +0100
Subject: [PATCH v4 0/6] arm64 UEFI early FDT handling
In-Reply-To: <CAKv+Gu-osoi53cpikDtZitJJX2gtZyhOMuvYf=cfeZi8zJ-LDg@mail.gmail.com>
References: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
 <CAKv+Gu-osoi53cpikDtZitJJX2gtZyhOMuvYf=cfeZi8zJ-LDg@mail.gmail.com>
Message-ID: <20160211114204.GO24726@rric.localdomain>

(+RobH and MarkR)

On 09.02.16 15:35:42, Ard Biesheuvel wrote:
> (+ Grant)
> 
> On 9 February 2016 at 14:53, Robert Richter <rrichter at caviumnetworks.com> wrote:
> > From: Robert Richter <rrichter at cavium.com>
> >
> > Reposting an updated version of this patches ported to 4.5-rc1. It is
> > a followup to the version 3 from:
> >
> >  http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel at linaro.org
> >
> > The series is essential for NUMA on arm64. Early FDT handling is
> > required to make system topology data from firmware, esp. for cpus and
> > memory available to the early boot process. Ganapat's numa patches
> > depend on it. This series has been tested with his series v10 posted
> > here:
> >
> >  http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni at caviumnetworks.com
> >
> 
> Hello Robert,
> 
> This series does not reflect anymore what we think is the best way to
> deal with memory nodes and memreserves on UEFI systems.
> Please refer to this thread:
> http://thread.gmane.org/gmane.linux.kernel.efi/6464
> 
> As far as the memory nodes are concerned, if it is the best place to
> store these NUMA annotations, then we should indeed preserve them, but
> I think the discussion stalled without any conclusion having been
> reached. As far as the /reserved-memory node is concerned, that one we
> should really keep, so at least patch 6/6 of this series should be
> replaced with something based on the series above.

Ard,

Mark R and Rob have agreed for numa dt binding for mem nodes. So do
you think we can at least reuse parts of this series to solve the NUMA
issue and try to find a solution for patch #6 which aligns with your
alternative approach?

Thanks,

-Robert

> 
> Thanks,
> Ard.
> 
> 
> > A number of minor issues exist in the early UEFI/FDT handling path, such as:
> > - when booting via UEFI, memreserve entries are removed from the device tree but
> >   the /reserved-memory node is not
> > - memory nodes are removed from the device tree in a way that is not officially
> >   supported by the libfdt API (i.e., you cannot delete nodes while traversing
> >   the tree)
> > - removal of memory nodes may discard annotations (such as NUMA topology) that
> >   should ideally be retained, or may corrupt the tree by discarding nodes
> >   referenced by phandles.
> >
> > Patches #1 and #2 introduce an arm64 specific version of
> > early_init_dt_add_memory_arch() so that we can modify it later to ignore DT
> > memory nodes if booting via UEFI.
> >
> > Patch #3 moves some UEFI+FDT init code around before making changes to it.
> >
> > Patch #4 moves the UEFI initialization to before the early FDT scanning so we
> > know at that point whether we are booting via UEFI or not.
> >
> > Patch #5 changes the UEFI init code so that memory nodes are simply ignored, so
> > that they don't have to be removed by the stub anymore.
> >
> > Patch #6 does the same as #5, but for memreserves and the /reserved-memory
> > node.
> >
> > Changes since v3:
> > - prorted to v4.5-rc1
> >
> > Changes since v2:
> > - instead of copying the generic implementation, turn
> >   early_init_dt_add_memory_arch() into a weak alias so that it is still
> >   accessible to overrides
> >
> > Changes since v1:
> > - dropped first two patches, they have been merged into v4.2-rc1
> > - dropped last patch regarding FDT placement by the stub, this is not entirely
> >   relevant to the primary issue targeted by this series
> > - rebased onto for-next/core (arm64) as of today
> >
> > Ard Biesheuvel (6):
> >   of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
> >   arm64: override generic version of early_init_dt_add_memory_arch()
> >   efi: move FDT handling to separate object file
> >   arm64/efi: move EFI /chosen node parsing before early FDT processing
> >   arm64/efi: ignore DT memory nodes instead of removing them
> >   arm64/efi: ignore DT memreserve entries instead of removing them
> >
> >  arch/arm64/include/asm/efi.h       |  2 +
> >  arch/arm64/kernel/setup.c          |  3 ++
> >  arch/arm64/mm/init.c               | 12 +++++-
> >  drivers/firmware/efi/Makefile      |  1 +
> >  drivers/firmware/efi/arm-init.c    | 36 ++++++++++------
> >  drivers/firmware/efi/efi-fdt.c     | 73 +++++++++++++++++++++++++++++++++
> >  drivers/firmware/efi/efi.c         | 84 --------------------------------------
> >  drivers/firmware/efi/libstub/fdt.c | 33 +--------------
> >  drivers/of/fdt.c                   |  7 +++-
> >  include/linux/efi.h                |  2 +-
> >  include/linux/of_fdt.h             |  1 +
> >  11 files changed, 121 insertions(+), 133 deletions(-)
> >  create mode 100644 drivers/firmware/efi/efi-fdt.c
> >
> > --
> > 2.7.0.rc3


From mark.rutland at arm.com  Thu Feb 11 03:44:10 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 11 Feb 2016 11:44:10 +0000
Subject: breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi:
 Refactor A31 PLL6 so that it can be reused)
In-Reply-To: <20160211100048.GK31506@lukather>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <56BB2D79.6090402@arm.com>
 <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
 <20160210143755.GE31506@lukather>
 <20160210163001.GG2632@leverpostej>
 <20160211100048.GK31506@lukather>
Message-ID: <20160211114410.GA32535@leverpostej>

On Thu, Feb 11, 2016 at 11:00:48AM +0100, Maxime Ripard wrote:
> On Wed, Feb 10, 2016 at 04:30:01PM +0000, Mark Rutland wrote:
> > On Wed, Feb 10, 2016 at 03:37:55PM +0100, Maxime Ripard wrote:
> > > Hi Rob,
> > > 
> > > On Wed, Feb 10, 2016 at 07:42:02AM -0600, Rob Herring wrote:
> > > > On Wed, Feb 10, 2016 at 6:30 AM, Andre Przywara <andre.przywara at arm.com> wrote:
> > > > > Hi,
> > > > >
> > > > > just a ping:
> > > > >
> > > > > Are we really OK with breaking existing DTs in 4.6? (per the code in
> > > > > -next: f7d372ba54ea04d528a291b8dbe34716507bb60b, which is this patch).
> > > > 
> > > > I only warn and make sure people are aware of the issue. I leave that
> > > > up to platform maintainers to decide. It depends on the maturity of
> > > > the platform and users.
> > > 
> > > The impacted SoCs support is really partial. For the most supported
> > > one, big things like display or sound are totally missing, and we
> > > still update them on a regular basis to add support for new
> > > devices. As such, users are very likely to upgrade the DT from one
> > > version to another just because there's new devices available to
> > > them. And the newest SoC impacted just got introduced in 4.5, and only
> > > has the UART and MMC devices available.
> > > 
> > > > If people complain about it then it's their mess. For platforms
> > > > supported in distros such as debian or fedora, I would strongly
> > > > recommend against breaking compatibility.
> > > 
> > > None of them are officially supported:
> > > https://www.debian.org/releases/stable/armhf/ch02s01.html.en
> > > https://fedoraproject.org/wiki/Architectures/ARM#Fedora_23
> > > 
> > > Only the older one are, and they are not affected by this patch.
> > > 
> > > > They do ship dtbs, but it's a chicken and egg problem. If dtbs were
> > > > stable and provided by firmware, then they wouldn't have to provide
> > > > them. If dtbs are unstable, then they have no choice.
> > > 
> > > And while it might work great on platforms that have all the needed
> > > documentation, or a perfect one, which is our case. Almost each
> > > release, we discover that something is not working as it was
> > > documented, when it was documented in the first place.
> > > 
> > > It also seems that even on well documented platforms, supported by the
> > > vendors, the stable ABI dream is not going to happen:
> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Atmel/README#n105
> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/arm/marvell,berlin.txt#n4
> > 
> > To be quite frank, I completely disagree with that stance.
> > 
> > It seems like the only reason DT bindings aren't remaining stable is
> > because people are deliberately ignoring the requirement and reasoning
> > for doing so.
> 
> And for DT maintainers saying on multiple occasions that it's bad but
> ok to break it and / or that they never actually said that it was a
> stable ABI...

Evidently there is a communication failure. Generally, the statement has
been that old DTBs should continue to work. That's even documented, as
Andre pointed out:

Documentation/devicetree/bindings/ABI.txt

There are obviously shades of grey, and _rarely_ it might be necessary
to deliberately break a binding. However, that should be the rare
last-resort case, rather than a crutch for development.

Saying "bad but ok" underplays the "bad" and overplays the "ok".

> I'm guessing it could be a stable ABI if there was bindings
> reviews. Rob actually started to review a significant amount of
> bindings lately, and that's really appreciated, but if you don't
> review all the bindings, then we're going to make mistakes.

I agree that it is unfortunate that we cannot provide the level of
review that we want to.

Mistakes will happen even with review; that doesn't necessitate removing
support for a binding.

> > I agree that it can be painful, and that we cannot predict the future.
> > There will always be bugs.
> 
> In our case, we can't even predict the present.
> 
> > Having code in mainline comes with responsibilities. One of those is to
> > keep said code working for existing users. Otherwise, why bother having
> > it in mainline at all?
> 
> None of our existing users ever complained.

I believe that in this case, Andre was complaining about this particular
breakage, unless I have misunderstood.

To be clear, I'm arguing for the strategy going forward. If no-one has
complained about the stuff broken up to this point, let's not waste time
restoring that.

Going forward we need to keep old DTBs supported.

Thanks,
Mark.


From matthias.bgg at gmail.com  Thu Feb 11 03:46:17 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 11 Feb 2016 12:46:17 +0100
Subject: [PATCH V5 00/11] soc: mediatek: PMIC wrap: add MT6323/2701/7623
 support
In-Reply-To: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
Message-ID: <56BC7489.8030402@gmail.com>

Hi John,

On 07/02/16 11:42, John Crispin wrote:
> This series adds support for a new PMIC (MT6323) and 2 new SoCs
> (MT2701/7623) to the pmic-wrap driver.
>
>
> John Crispin (11):
>    dt-bindings: ARM: Mediatek: add MT2701/7623 string to the PMIC
>      wrapper doc
>    soc: mediatek: PMIC wrap: don't duplicate the wrapper data
>    soc: mediatek: PMIC wrap: add wrapper callbacks for init_reg_clock
>    soc: mediatek: PMIC wrap: split SoC specific init into callback
>    soc: mediatek: PMIC wrap: WRAP_INT_EN needs a different bitmask for
>      MT2701/7623
>    soc: mediatek: PMIC wrap: SPI_WRITE needs a different bitmask for
>      MT2701/7623
>    soc: mediatek: PMIC wrap: move wdt_src into the pmic_wrapper_type
>      struct
>    soc: mediatek: PMIC wrap: remove pwrap_is_mt8135() and
>      pwrap_is_mt8173()
>    soc: mediatek: PMIC wrap: add a slave specific struct
>    soc: mediatek: PMIC wrap: add mt6323 slave support
>    soc: mediatek: PMIC wrap: add MT2701/7623 support
>
>   .../devicetree/bindings/soc/mediatek/pwrap.txt     |    1 +
>   drivers/soc/mediatek/mtk-pmic-wrap.c               |  554 +++++++++++++++-----
>   2 files changed, 424 insertions(+), 131 deletions(-)
>

In the future, can you please add one liners to explain what you changed 
in comparison to the former version, this helps pretty much when 
reviewing patch series.

The whole series is in a pretty good shape, I have just some minor comments.

Regards,
Matthias


From marc.zyngier at arm.com  Thu Feb 11 03:47:22 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 11:47:22 +0000
Subject: [PATCH V3 00/10] Introduce ACPI world to GICv3 & ITS irqchip
In-Reply-To: <1453209083-3358-1-git-send-email-tn@semihalf.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
Message-ID: <56BC74CA.3020003@arm.com>

Thomas, Hanjun,

On 19/01/16 13:11, Tomasz Nowicki wrote:
> Patches base on Suravee's ACPI GICv2m support:
> https://lkml.org/lkml/2015/12/10/475
> 
> The following git branch contains submitted patches along with
> the useful patches from the test point of view (mainly ACPI ARM64 PCI support).
> https://github.com/semihalf-nowicki-tomasz/linux.git (gicv3-its-acpi-v3)
> 
> Series has been tested on Cavium ThunderX server.
> 
> v2 -> v3
> - rebased on top of 4.4
> - fixes and improvements for redistributor init via GICC structures
> - fixes as per kbuild reports
> 
> v1 -> v2
> - rebased on top of 4.4-rc4
> - use pci_msi_domain_get_msi_rid for requester ID to device ID translation
> 
> Hanjun Guo (1):
>   irqchip / GICv3: remove gic root node in ITS
> 
> Tomasz Nowicki (9):
>   irqchip / GICv3: Refactor gic_of_init() for GICv3 driver
>   irqchip / GICv3: Add ACPI support for GICv3+ initialization
>   irqchip,GICv3,ACPI: Add redistributor support via GICC structures.
>   irqchip, gicv3, its: Mark its_init() and its children as __init
>   irqchip, GICv3, ITS: Refator ITS dt init code to prepare for ACPI.
>   ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support.
>   irqchip, gicv3, its: Probe ITS in the ACPI way.
>   acpi, gicv3, msi: Factor out code that might be reused for ACPI
>     equivalent.
>   acpi, gicv3, its: Use MADT ITS subtable to do PCI/MSI domain
>     initialization.
> 
>  drivers/acpi/Kconfig                     |   3 +
>  drivers/acpi/Makefile                    |   1 +
>  drivers/acpi/iort.c                      | 326 +++++++++++++++++++++++++++++
>  drivers/irqchip/Kconfig                  |   1 +
>  drivers/irqchip/irq-gic-v3-its-pci-msi.c |  85 ++++++--
>  drivers/irqchip/irq-gic-v3-its.c         | 143 +++++++++----
>  drivers/irqchip/irq-gic-v3.c             | 344 ++++++++++++++++++++++++++-----
>  drivers/pci/msi.c                        |   3 +
>  include/linux/iort.h                     |  38 ++++
>  include/linux/irqchip/arm-gic-v3.h       |   2 +-
>  10 files changed, 845 insertions(+), 101 deletions(-)
>  create mode 100644 drivers/acpi/iort.c
>  create mode 100644 include/linux/iort.h
> 

I've so far queued the first 5 patches of this series (basic ACPI
support for GICv3 and associated cleanups). The rest needs additional
discussion (see my comments on patch 10), and requires some form of Ack
from the ACPI maintainers (at least for patch 7).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From broonie at kernel.org  Thu Feb 11 03:51:28 2016
From: broonie at kernel.org (Mark Brown)
Date: Thu, 11 Feb 2016 11:51:28 +0000
Subject: [PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred
 probe for pm_runtime_reinit
In-Reply-To: <1455145370-20301-4-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-4-git-send-email-tony@atomide.com>
Message-ID: <20160211115128.GF13270@sirena.org.uk>

On Wed, Feb 10, 2016 at 03:02:46PM -0800, Tony Lindgren wrote:

> Mark, I'd like to merge this along with other related fixes via
> the ARM SoC tree if no objections, please review and ack if this
> look OK to you.

Why, I'm not seeing any dependencies here?  I'd also expect to be seeing
an awful lot more changes like this, this shouldn't be an OMAP thing -
do we need to fix the core API and then roll out the transition in a
different way?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/735c9e60/attachment.sig>

From matthias.bgg at gmail.com  Thu Feb 11 03:54:28 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 11 Feb 2016 12:54:28 +0100
Subject: [PATCH V5 04/11] soc: mediatek: PMIC wrap: split SoC specific
 init into callback
In-Reply-To: <1454841778-35529-5-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
 <1454841778-35529-5-git-send-email-blogic@openwrt.org>
Message-ID: <56BC7674.9030706@gmail.com>



On 07/02/16 11:42, John Crispin wrote:
> This patch moves the SoC specific wrapper init code into separate callback
> to avoid pwrap_init() getting too large.
>

Please explain a bit more, what the patch does.

> Signed-off-by: John Crispin <blogic at openwrt.org>
> ---
> Changes in V5
> * only check the return code of init_special() if the function is
>    actually called
>
>   drivers/soc/mediatek/mtk-pmic-wrap.c |   67 +++++++++++++++++++++-------------
>   1 file changed, 42 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> index b22b664..e3bbee5 100644
> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> @@ -372,6 +372,7 @@ struct pmic_wrapper_type {
>   	enum pwrap_type type;
>   	u32 arb_en_all;
>   	int (*init_reg_clock)(struct pmic_wrapper *wrp);
> +	int (*init_special)(struct pmic_wrapper *wrp);

Nit:
I wonder if we can find a better name for the callback, as init_special 
sounds quite generic to me.

Thanks,
Matthias

>   };
>
>   static inline int pwrap_is_mt8135(struct pmic_wrapper *wrp)
> @@ -665,6 +666,41 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
>   	return 0;
>   }
>
> +static int pwrap_mt8135_init_special(struct pmic_wrapper *wrp)
> +{
> +	/* enable pwrap events and pwrap bridge in AP side */
> +	pwrap_writel(wrp, 0x1, PWRAP_EVENT_IN_EN);
> +	pwrap_writel(wrp, 0xffff, PWRAP_EVENT_DST_EN);
> +	writel(0x7f, wrp->bridge_base + PWRAP_MT8135_BRIDGE_IORD_ARB_EN);
> +	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS3_EN);
> +	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS4_EN);
> +	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_UNIT);
> +	writel(0xffff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_SRC_EN);
> +	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_TIMER_EN);
> +	writel(0x7ff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INT_EN);
> +
> +	/* enable PMIC event out and sources */
> +	if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
> +		pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
> +		dev_err(wrp->dev, "enable dewrap fail\n");
> +		return -EFAULT;
> +	}
> +
> +	return 0;
> +}
> +
> +static int pwrap_mt8173_init_special(struct pmic_wrapper *wrp)
> +{
> +	/* PMIC_DEWRAP enables */
> +	if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
> +		pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
> +		dev_err(wrp->dev, "enable dewrap fail\n");
> +		return -EFAULT;
> +	}
> +
> +	return 0;
> +}
> +
>   static int pwrap_init(struct pmic_wrapper *wrp)
>   {
>   	int ret;
> @@ -743,31 +779,10 @@ static int pwrap_init(struct pmic_wrapper *wrp)
>   	pwrap_writel(wrp, 0x5, PWRAP_STAUPD_PRD);
>   	pwrap_writel(wrp, 0xff, PWRAP_STAUPD_GRPEN);
>
> -	if (pwrap_is_mt8135(wrp)) {
> -		/* enable pwrap events and pwrap bridge in AP side */
> -		pwrap_writel(wrp, 0x1, PWRAP_EVENT_IN_EN);
> -		pwrap_writel(wrp, 0xffff, PWRAP_EVENT_DST_EN);
> -		writel(0x7f, wrp->bridge_base + PWRAP_MT8135_BRIDGE_IORD_ARB_EN);
> -		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS3_EN);
> -		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS4_EN);
> -		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_UNIT);
> -		writel(0xffff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_SRC_EN);
> -		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_TIMER_EN);
> -		writel(0x7ff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INT_EN);
> -
> -		/* enable PMIC event out and sources */
> -		if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
> -				pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
> -			dev_err(wrp->dev, "enable dewrap fail\n");
> -			return -EFAULT;
> -		}
> -	} else {
> -		/* PMIC_DEWRAP enables */
> -		if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
> -				pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
> -			dev_err(wrp->dev, "enable dewrap fail\n");
> -			return -EFAULT;
> -		}
> +	if (wrp->master->init_special) {
> +		ret = wrp->master->init_special(wrp);
> +		if (ret)
> +			return ret;
>   	}
>
>   	/* Setup the init done registers */
> @@ -811,6 +826,7 @@ static struct pmic_wrapper_type pwrap_mt8135 = {
>   	.type = PWRAP_MT8135,
>   	.arb_en_all = 0x1ff,
>   	.init_reg_clock = pwrap_mt8135_init_reg_clock,
> +	.init_special = pwrap_mt8135_init_special,
>   };
>
>   static struct pmic_wrapper_type pwrap_mt8173 = {
> @@ -818,6 +834,7 @@ static struct pmic_wrapper_type pwrap_mt8173 = {
>   	.type = PWRAP_MT8173,
>   	.arb_en_all = 0x3f,
>   	.init_reg_clock = pwrap_mt8173_init_reg_clock,
> +	.init_special = pwrap_mt8173_init_special,
>   };
>
>   static struct of_device_id of_pwrap_match_tbl[] = {
>


From lorenzo.pieralisi at arm.com  Thu Feb 11 03:58:53 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 11 Feb 2016 11:58:53 +0000
Subject: [PATCH V4 22/23] arm64, pci, acpi: Assign legacy IRQs once
 device is enable.
In-Reply-To: <1454606941-9523-23-git-send-email-tn@semihalf.com>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
 <1454606941-9523-23-git-send-email-tn@semihalf.com>
Message-ID: <20160211115843.GA24136@red-moon>

On Thu, Feb 04, 2016 at 06:29:00PM +0100, Tomasz Nowicki wrote:
> This is the last step before enabling generic ACPI PCI host controller
> for ARM64. We need to take care of legacy IRQ mapping for non-MSI(X)
> PCI devices. pcibios_enable_device() boot order is not sensitive to
> ACPI device enumeration, so it is the best place to assign device's IRQs.

I guess you are referring to:

https://lists.linaro.org/pipermail/linaro-acpi/2015-October/005944.html

It is weird that the dependency can't be enforced, I will have a look
into this, it would be nice to have DT and ACPI legacy IRQs mapping
confined in pcibios_add_device() so that we can remove them in one go
when Matthew's series is merged.

As for the MSI check, by reading commit history its need I think
it harks back to bba6f6fc, which was supposed to be a quick hack and it
has been in the kernel for 9 years :), is it really needed ?

> NOTE: *This is going to be temporary solution*. There is ongoing work
> which aims for cleaning legacy IRQ allocation, see [1].
> We can consider this patch as the necessary evil which will be removed
> once [1] series hits mailnline in the near future.
> 
> 1. http://comments.gmane.org/gmane.linux.kernel.pci/46461
> 
> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
> ---
>  arch/arm64/kernel/pci.c | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 023b983..d1a701f 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -39,16 +39,26 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
>  }
>  
>  /**
> - * pcibios_enable_device - Enable I/O and memory.
> + * pcibios_enable_device - Enable I/O, memory and legacy IRQs for ACPI.
>   * @dev: PCI device to be enabled
>   * @mask: bitmask of BARs to enable
>   */
>  int pcibios_enable_device(struct pci_dev *dev, int mask)
>  {
> +	int ret;
> +
>  	if (pci_has_flag(PCI_PROBE_ONLY))
>  		return 0;
>  
> -	return pci_enable_resources(dev, mask);
> +	ret = pci_enable_resources(dev, mask);
> +	if (ret < 0)
> +		return ret;
> +
> +#ifdef CONFIG_ACPI
> +	if (!pci_dev_msi_enabled(dev))
> +		return acpi_pci_irq_enable(dev);

You need a guard here anyway, we do not want to probe ACPI IRQ if
it is disabled (ie acpi_pci_disabled). Same goes for DT in
pcibios_add_device(), which is not making this code any nicer.

Lorenzo

> +#endif
> +	return 0;
>  }
>  
>  /*
> -- 
> 1.9.1
> 


From matthias.bgg at gmail.com  Thu Feb 11 03:59:03 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 11 Feb 2016 12:59:03 +0100
Subject: [PATCH V5 06/11] soc: mediatek: PMIC wrap: SPI_WRITE needs a
 different bitmask for MT2701/7623
In-Reply-To: <1454841778-35529-7-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
 <1454841778-35529-7-git-send-email-blogic@openwrt.org>
Message-ID: <56BC7787.8070308@gmail.com>



On 07/02/16 11:42, John Crispin wrote:
> MT2701 and MT7623 use a different bitmask for the SPI_WRITE command.
>

Something like:
Different SoCs will use different bitmask for the SPI_WRITE command. 
This patch defines the bitmask in the pmic_wrapper_type to allow an easy 
addition.

Well you are the native speaker, so maybe it's not the best to just use 
my version ;)

Regards,
Matthias


From linus.walleij at linaro.org  Thu Feb 11 03:59:47 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Feb 2016 12:59:47 +0100
Subject: [PATCH 01/14] pinctrl: sunxi: Add A83T R_PIO controller support
In-Reply-To: <1454203266-4450-2-git-send-email-vishnupatekar0510@gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-2-git-send-email-vishnupatekar0510@gmail.com>
Message-ID: <CACRpkdbCgOBQw28d=qc1fAURY3x8UdoWqiMtXMZ=uWLaQj-nbg@mail.gmail.com>

On Sun, Jan 31, 2016 at 2:20 AM, Vishnu Patekar
<vishnupatekar0510 at gmail.com> wrote:

> The A83T has R_PIO pin controller, it's same as A23, execpt A83T
> interrupt bit is 6th and A83T has one extra pin PL12.
>
> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>

Maxime, can you look at this patch?

Yours,
Linus Walleij


From matthias.bgg at gmail.com  Thu Feb 11 04:00:41 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 11 Feb 2016 13:00:41 +0100
Subject: [PATCH V5 07/11] soc: mediatek: PMIC wrap: move wdt_src into the
 pmic_wrapper_type struct
In-Reply-To: <1454841778-35529-8-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
 <1454841778-35529-8-git-send-email-blogic@openwrt.org>
Message-ID: <56BC77E9.2080403@gmail.com>



On 07/02/16 11:42, John Crispin wrote:
> Make the handling of wdt_src consitent with the rest of the code.
>

Same here, please explain what the patch is doing. Or just squash 6 and 
7, as you like.


From linus.walleij at linaro.org  Thu Feb 11 04:01:32 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Feb 2016 13:01:32 +0100
Subject: [PATCH] pinctrl: sunxi: H3 requires irq_read_needs_mux
In-Reply-To: <20160202100217.GA7483@box2.japko.eu>
References: <20160202100217.GA7483@box2.japko.eu>
Message-ID: <CACRpkdbp2J5eVwsJpuyxkjv72mB4ojcauXoDn1_iei7XB0yzxg@mail.gmail.com>

On Tue, Feb 2, 2016 at 11:03 AM, Krzysztof Adamski
<krzysztof.adamski at sonymobile.com> wrote:

> It seems that on H3, just like on A10, when GPIOs are configured as
> external interrupt data registers does not contain their value.  When
> value is read, GPIO function must be temporary switched to input for
> reads.
>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

Patch applied for fixes with Maxime's ACK.

Yours,
Linus Walleij


From matthias.bgg at gmail.com  Thu Feb 11 04:01:36 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 11 Feb 2016 13:01:36 +0100
Subject: [PATCH V5 08/11] soc: mediatek: PMIC wrap: remove
 pwrap_is_mt8135() and pwrap_is_mt8173()
In-Reply-To: <1454841778-35529-9-git-send-email-blogic@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
 <1454841778-35529-9-git-send-email-blogic@openwrt.org>
Message-ID: <56BC7820.6040203@gmail.com>



On 07/02/16 11:42, John Crispin wrote:
> With more SoCs being added the list of helper functions like these would
> grow. While at it also add a new flag "has_bridge" and use that instead of
> pwrap_is_mt8173() where appropriate.
>
> Signed-off-by: John Crispin <blogic at openwrt.org>
> ---

Same here, please explain better what the code does.

Thanks.
Matthias


From matthias.bgg at gmail.com  Thu Feb 11 04:07:01 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 11 Feb 2016 13:07:01 +0100
Subject: [PATCH] 8250: mediatek: mark PM functions as __maybe_unused
In-Reply-To: <1454938591-2743892-1-git-send-email-arnd@arndb.de>
References: <1454938591-2743892-1-git-send-email-arnd@arndb.de>
Message-ID: <56BC7965.90404@gmail.com>



On 08/02/16 14:36, Arnd Bergmann wrote:
> The mtk8250_runtime_suspend function is not used when runtime PM is
> disabled, so we get a warning about an unused function:
>
> drivers/tty/serial/8250/8250_mtk.c:119:12: error: 'mtk8250_runtime_suspend' defined but not used [-Werror=unused-function]
>   static int mtk8250_runtime_suspend(struct device *dev)
>
> This marks all the PM functions as __maybe_unused to avoid the warning,
> and removes the #ifdef around the PM_SLEEP functions for consistency.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---

Acked-by: Matthias Brugger <matthias.bgg at gmail.com>

>   drivers/tty/serial/8250/8250_mtk.c | 10 ++++------
>   1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
> index 0e590b233f03..9038843cadc7 100644
> --- a/drivers/tty/serial/8250/8250_mtk.c
> +++ b/drivers/tty/serial/8250/8250_mtk.c
> @@ -116,7 +116,7 @@ mtk8250_set_termios(struct uart_port *port, struct ktermios *termios,
>   		tty_termios_encode_baud_rate(termios, baud, baud);
>   }
>
> -static int mtk8250_runtime_suspend(struct device *dev)
> +static int __maybe_unused mtk8250_runtime_suspend(struct device *dev)
>   {
>   	struct mtk8250_data *data = dev_get_drvdata(dev);
>
> @@ -126,7 +126,7 @@ static int mtk8250_runtime_suspend(struct device *dev)
>   	return 0;
>   }
>
> -static int mtk8250_runtime_resume(struct device *dev)
> +static int __maybe_unused mtk8250_runtime_resume(struct device *dev)
>   {
>   	struct mtk8250_data *data = dev_get_drvdata(dev);
>   	int err;
> @@ -245,8 +245,7 @@ static int mtk8250_probe(struct platform_device *pdev)
>   	return 0;
>   }
>
> -#ifdef CONFIG_PM_SLEEP
> -static int mtk8250_suspend(struct device *dev)
> +static int __maybe_unused mtk8250_suspend(struct device *dev)
>   {
>   	struct mtk8250_data *data = dev_get_drvdata(dev);
>
> @@ -255,7 +254,7 @@ static int mtk8250_suspend(struct device *dev)
>   	return 0;
>   }
>
> -static int mtk8250_resume(struct device *dev)
> +static int __maybe_unused mtk8250_resume(struct device *dev)
>   {
>   	struct mtk8250_data *data = dev_get_drvdata(dev);
>
> @@ -263,7 +262,6 @@ static int mtk8250_resume(struct device *dev)
>
>   	return 0;
>   }
> -#endif /* CONFIG_PM_SLEEP */
>
>   static const struct dev_pm_ops mtk8250_pm_ops = {
>   	SET_SYSTEM_SLEEP_PM_OPS(mtk8250_suspend, mtk8250_resume)
>


From ard.biesheuvel at linaro.org  Thu Feb 11 04:14:45 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 11 Feb 2016 13:14:45 +0100
Subject: [PATCH v4 0/6] arm64 UEFI early FDT handling
In-Reply-To: <20160211114204.GO24726@rric.localdomain>
References: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
 <CAKv+Gu-osoi53cpikDtZitJJX2gtZyhOMuvYf=cfeZi8zJ-LDg@mail.gmail.com>
 <20160211114204.GO24726@rric.localdomain>
Message-ID: <CAKv+Gu-KpasM9QZ8qrZEk_pUJpf3TceaenLYTx_eAHW6AUmutA@mail.gmail.com>

On 11 February 2016 at 12:42, Robert Richter
<robert.richter at caviumnetworks.com> wrote:
> (+RobH and MarkR)
>
> On 09.02.16 15:35:42, Ard Biesheuvel wrote:
>> (+ Grant)
>>
>> On 9 February 2016 at 14:53, Robert Richter <rrichter at caviumnetworks.com> wrote:
>> > From: Robert Richter <rrichter at cavium.com>
>> >
>> > Reposting an updated version of this patches ported to 4.5-rc1. It is
>> > a followup to the version 3 from:
>> >
>> >  http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel at linaro.org
>> >
>> > The series is essential for NUMA on arm64. Early FDT handling is
>> > required to make system topology data from firmware, esp. for cpus and
>> > memory available to the early boot process. Ganapat's numa patches
>> > depend on it. This series has been tested with his series v10 posted
>> > here:
>> >
>> >  http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni at caviumnetworks.com
>> >
>>
>> Hello Robert,
>>
>> This series does not reflect anymore what we think is the best way to
>> deal with memory nodes and memreserves on UEFI systems.
>> Please refer to this thread:
>> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>>
>> As far as the memory nodes are concerned, if it is the best place to
>> store these NUMA annotations, then we should indeed preserve them, but
>> I think the discussion stalled without any conclusion having been
>> reached. As far as the /reserved-memory node is concerned, that one we
>> should really keep, so at least patch 6/6 of this series should be
>> replaced with something based on the series above.
>
> Ard,
>
> Mark R and Rob have agreed for numa dt binding for mem nodes. So do
> you think we can at least reuse parts of this series to solve the NUMA
> issue and try to find a solution for patch #6 which aligns with your
> alternative approach?
>

OK, if we are all in agreement that NUMA annotations belong in memory
nodes, which are otherwise ignored completely on UEFI systems, I am
fine with this as well.

However, we have to think about what it means if the memory nodes are
out of sync with the UEFI memory map, both on NUMA and ordinary
systems. I know very little about NUMA, but I could imagine that on
any UEFI system, the UEFI memory map remains authoritative, and memory
nodes are only used to annotate regions that are already known to
exist. Alternatively, some sanity check could be appropriate (such as
the one I proposed for the /reserved-memory node in the link above),
but we need to consider carefully how the firmware is supposed to
produce memory nodes and a UEFI memory map that are mutually
consistent.

I think we can replace 6/6 with the series above, i.e., honour the
allocations after establishing that the fixed allocations are either
still available, or entirely disjoint from what the UEFI memory map
describes.

-- 
Ard.


From michal.simek at xilinx.com  Thu Feb 11 04:26:26 2016
From: michal.simek at xilinx.com (Michal Simek)
Date: Thu, 11 Feb 2016 13:26:26 +0100
Subject: [PATCH 1/3] ARM64: zynqmp: Keep gpio node alphabetically sorted
Message-ID: <2f160e012080d5d6de11238ade239bb0bb224f64.1455193571.git.michal.simek@xilinx.com>

No functional change.

Signed-off-by: Michal Simek <michal.simek at xilinx.com>
---

 arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 200fb588d0f5..7bc65e391530 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -126,18 +126,6 @@
 			clock-frequency = <25000000>;
 		};
 
-		gpio: gpio at ff0a0000 {
-			compatible = "xlnx,zynqmp-gpio-1.0";
-			status = "disabled";
-			#gpio-cells = <0x2>;
-			clocks = <&misc_clk>;
-			interrupt-parent = <&gic>;
-			interrupts = <0 16 4>;
-			interrupt-controller;
-			#interrupt-cells = <2>;
-			reg = <0x0 0xff0a0000 0x1000>;
-		};
-
 		gem0: ethernet at ff0b0000 {
 			compatible = "cdns,gem";
 			status = "disabled";
@@ -186,6 +174,18 @@
 			#size-cells = <0>;
 		};
 
+		gpio: gpio at ff0a0000 {
+			compatible = "xlnx,zynqmp-gpio-1.0";
+			status = "disabled";
+			#gpio-cells = <0x2>;
+			clocks = <&misc_clk>;
+			interrupt-parent = <&gic>;
+			interrupts = <0 16 4>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			reg = <0x0 0xff0a0000 0x1000>;
+		};
+
 		i2c_clk: i2c_clk {
 			compatible = "fixed-clock";
 			#clock-cells = <0x0>;
-- 
1.9.1



From michal.simek at xilinx.com  Thu Feb 11 04:26:28 2016
From: michal.simek at xilinx.com (Michal Simek)
Date: Thu, 11 Feb 2016 13:26:28 +0100
Subject: [PATCH 3/3] ARM64: zynqmp: Use 64bit size cell format
In-Reply-To: <2f160e012080d5d6de11238ade239bb0bb224f64.1455193571.git.michal.simek@xilinx.com>
References: <2f160e012080d5d6de11238ade239bb0bb224f64.1455193571.git.michal.simek@xilinx.com>
Message-ID: <36fb9c4c9b2019b854e84dc0a9a01252a6de2337.1455193571.git.michal.simek@xilinx.com>

Use 64bit size cell format instead of 32bit for memory
description. Change 64bit sizes also for all others IPs.

Signed-off-by: Michal Simek <michal.simek at xilinx.com>
---

 arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts |  2 +-
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi      | 63 ++++++++++++++---------------
 2 files changed, 32 insertions(+), 33 deletions(-)

diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
index acb0527fdc4a..358089687a69 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
@@ -29,7 +29,7 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x0 0x0 0x40000000>;
+		reg = <0x0 0x0 0x0 0x40000000>;
 	};
 };
 
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index e595f22e7e4b..ef8fe8e6c868 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -14,7 +14,7 @@
 / {
 	compatible = "xlnx,zynqmp";
 	#address-cells = <2>;
-	#size-cells = <1>;
+	#size-cells = <2>;
 
 	cpus {
 		#address-cells = <1>;
@@ -74,16 +74,15 @@
 	amba_apu {
 		compatible = "simple-bus";
 		#address-cells = <2>;
-		#size-cells = <1>;
+		#size-cells = <2>;
 		ranges;
-
 		gic: interrupt-controller at f9010000 {
 			compatible = "arm,gic-400", "arm,cortex-a15-gic";
 			#interrupt-cells = <3>;
-			reg = <0x0 0xf9010000 0x10000>,
-			      <0x0 0xf902f000 0x2000>,
-			      <0x0 0xf9040000 0x20000>,
-			      <0x0 0xf906f000 0x2000>;
+			reg = <0x0 0xf9010000 0x0 0x10000>,
+			      <0x0 0xf902f000 0x0 0x2000>,
+			      <0x0 0xf9040000 0x0 0x20000>,
+			      <0x0 0xf906f000 0x0 0x2000>;
 			interrupt-controller;
 			interrupt-parent = <&gic>;
 			interrupts = <1 9 0xf04>;
@@ -93,14 +92,14 @@
 	amba: amba {
 		compatible = "simple-bus";
 		#address-cells = <2>;
-		#size-cells = <1>;
+		#size-cells = <2>;
 		ranges;
 
 		can0: can at ff060000 {
 			compatible = "xlnx,zynq-can-1.0";
 			status = "disabled";
 			clock-names = "can_clk", "pclk";
-			reg = <0x0 0xff060000 0x1000>;
+			reg = <0x0 0xff060000 0x0 0x1000>;
 			interrupts = <0 23 4>;
 			interrupt-parent = <&gic>;
 			tx-fifo-depth = <0x40>;
@@ -111,7 +110,7 @@
 			compatible = "xlnx,zynq-can-1.0";
 			status = "disabled";
 			clock-names = "can_clk", "pclk";
-			reg = <0x0 0xff070000 0x1000>;
+			reg = <0x0 0xff070000 0x0 0x1000>;
 			interrupts = <0 24 4>;
 			interrupt-parent = <&gic>;
 			tx-fifo-depth = <0x40>;
@@ -123,7 +122,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 57 4>, <0 57 4>;
-			reg = <0x0 0xff0b0000 0x1000>;
+			reg = <0x0 0xff0b0000 0x0 0x1000>;
 			clock-names = "pclk", "hclk", "tx_clk";
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -134,7 +133,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 59 4>, <0 59 4>;
-			reg = <0x0 0xff0c0000 0x1000>;
+			reg = <0x0 0xff0c0000 0x0 0x1000>;
 			clock-names = "pclk", "hclk", "tx_clk";
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -145,7 +144,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 61 4>, <0 61 4>;
-			reg = <0x0 0xff0d0000 0x1000>;
+			reg = <0x0 0xff0d0000 0x0 0x1000>;
 			clock-names = "pclk", "hclk", "tx_clk";
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -156,7 +155,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 63 4>, <0 63 4>;
-			reg = <0x0 0xff0e0000 0x1000>;
+			reg = <0x0 0xff0e0000 0x0 0x1000>;
 			clock-names = "pclk", "hclk", "tx_clk";
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -170,7 +169,7 @@
 			interrupts = <0 16 4>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
-			reg = <0x0 0xff0a0000 0x1000>;
+			reg = <0x0 0xff0a0000 0x0 0x1000>;
 		};
 
 		i2c0: i2c at ff020000 {
@@ -178,7 +177,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 17 4>;
-			reg = <0x0 0xff020000 0x1000>;
+			reg = <0x0 0xff020000 0x0 0x1000>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 		};
@@ -188,7 +187,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 18 4>;
-			reg = <0x0 0xff030000 0x1000>;
+			reg = <0x0 0xff030000 0x0 0x1000>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 		};
@@ -196,7 +195,7 @@
 		sata: ahci at fd0c0000 {
 			compatible = "ceva,ahci-1v84";
 			status = "disabled";
-			reg = <0x0 0xfd0c0000 0x2000>;
+			reg = <0x0 0xfd0c0000 0x0 0x2000>;
 			interrupt-parent = <&gic>;
 			interrupts = <0 133 4>;
 		};
@@ -206,7 +205,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 48 4>;
-			reg = <0x0 0xff160000 0x1000>;
+			reg = <0x0 0xff160000 0x0 0x1000>;
 			clock-names = "clk_xin", "clk_ahb";
 		};
 
@@ -215,13 +214,13 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 49 4>;
-			reg = <0x0 0xff170000 0x1000>;
+			reg = <0x0 0xff170000 0x0 0x1000>;
 			clock-names = "clk_xin", "clk_ahb";
 		};
 
 		smmu: smmu at fd800000 {
 			compatible = "arm,mmu-500";
-			reg = <0x0 0xfd800000 0x20000>;
+			reg = <0x0 0xfd800000 0x0 0x20000>;
 			#global-interrupts = <1>;
 			interrupt-parent = <&gic>;
 			interrupts = <0 157 4>,
@@ -236,7 +235,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 19 4>;
-			reg = <0x0 0xff040000 0x1000>;
+			reg = <0x0 0xff040000 0x0 0x1000>;
 			clock-names = "ref_clk", "pclk";
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -247,7 +246,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 20 4>;
-			reg = <0x0 0xff050000 0x1000>;
+			reg = <0x0 0xff050000 0x0 0x1000>;
 			clock-names = "ref_clk", "pclk";
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -258,7 +257,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 36 4>, <0 37 4>, <0 38 4>;
-			reg = <0x0 0xff110000 0x1000>;
+			reg = <0x0 0xff110000 0x0 0x1000>;
 			timer-width = <32>;
 		};
 
@@ -267,7 +266,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 39 4>, <0 40 4>, <0 41 4>;
-			reg = <0x0 0xff120000 0x1000>;
+			reg = <0x0 0xff120000 0x0 0x1000>;
 			timer-width = <32>;
 		};
 
@@ -276,7 +275,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 42 4>, <0 43 4>, <0 44 4>;
-			reg = <0x0 0xff130000 0x1000>;
+			reg = <0x0 0xff130000 0x0 0x1000>;
 			timer-width = <32>;
 		};
 
@@ -285,7 +284,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 45 4>, <0 46 4>, <0 47 4>;
-			reg = <0x0 0xff140000 0x1000>;
+			reg = <0x0 0xff140000 0x0 0x1000>;
 			timer-width = <32>;
 		};
 
@@ -294,7 +293,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 21 4>;
-			reg = <0x0 0xff000000 0x1000>;
+			reg = <0x0 0xff000000 0x0 0x1000>;
 			clock-names = "uart_clk", "pclk";
 		};
 
@@ -303,7 +302,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 22 4>;
-			reg = <0x0 0xff010000 0x1000>;
+			reg = <0x0 0xff010000 0x0 0x1000>;
 			clock-names = "uart_clk", "pclk";
 		};
 
@@ -312,7 +311,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 65 4>;
-			reg = <0x0 0xfe200000 0x40000>;
+			reg = <0x0 0xfe200000 0x0 0x40000>;
 			clock-names = "clk_xin", "clk_ahb";
 		};
 
@@ -321,7 +320,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 70 4>;
-			reg = <0x0 0xfe300000 0x40000>;
+			reg = <0x0 0xfe300000 0x0 0x40000>;
 			clock-names = "clk_xin", "clk_ahb";
 		};
 
@@ -330,7 +329,7 @@
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 52 1>;
-			reg = <0x0 0xfd4d0000 0x1000>;
+			reg = <0x0 0xfd4d0000 0x0 0x1000>;
 			timeout-sec = <10>;
 		};
 	};
-- 
1.9.1



From michal.simek at xilinx.com  Thu Feb 11 04:26:27 2016
From: michal.simek at xilinx.com (Michal Simek)
Date: Thu, 11 Feb 2016 13:26:27 +0100
Subject: [PATCH 2/3] ARM64: zynqmp: Extract clock information from EP108
In-Reply-To: <2f160e012080d5d6de11238ade239bb0bb224f64.1455193571.git.michal.simek@xilinx.com>
References: <2f160e012080d5d6de11238ade239bb0bb224f64.1455193571.git.michal.simek@xilinx.com>
Message-ID: <9232f2d8a45114a6d26b6fc18d454723930cadca.1455193571.git.michal.simek@xilinx.com>

Extract clocks and put it specific file to help with platform
autogeneration.

Signed-off-by: Michal Simek <michal.simek at xilinx.com>
---

 arch/arm64/boot/dts/xilinx/zynqmp-ep108-clk.dtsi | 88 ++++++++++++++++++++++++
 arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts      |  1 +
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi           | 43 +-----------
 3 files changed, 90 insertions(+), 42 deletions(-)
 create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-ep108-clk.dtsi

diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ep108-clk.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp-ep108-clk.dtsi
new file mode 100644
index 000000000000..cdc6a437dcc7
--- /dev/null
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-ep108-clk.dtsi
@@ -0,0 +1,88 @@
+/*
+ * clock specification for Xilinx ZynqMP ep108 development board
+ *
+ * (C) Copyright 2015, Xilinx, Inc.
+ *
+ * Michal Simek <michal.simek at xilinx.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+&amba {
+	misc_clk: misc_clk {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <25000000>;
+	};
+
+	i2c_clk: i2c_clk {
+		compatible = "fixed-clock";
+		#clock-cells = <0x0>;
+		clock-frequency = <111111111>;
+	};
+
+	sata_clk: sata_clk {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <75000000>;
+	};
+};
+
+&can0 {
+	clocks = <&misc_clk &misc_clk>;
+};
+
+&gem0 {
+	clocks = <&misc_clk>, <&misc_clk>, <&misc_clk>;
+};
+
+&gpio {
+	clocks = <&misc_clk>;
+};
+
+&i2c0 {
+	clocks = <&i2c_clk>;
+};
+
+&i2c1 {
+	clocks = <&i2c_clk>;
+};
+
+&sata {
+	clocks = <&sata_clk>;
+};
+
+&sdhci0 {
+	clocks = <&misc_clk>, <&misc_clk>;
+};
+
+&sdhci1 {
+	clocks = <&misc_clk>, <&misc_clk>;
+};
+
+&spi0 {
+	clocks = <&misc_clk &misc_clk>;
+};
+
+&spi1 {
+	clocks = <&misc_clk &misc_clk>;
+};
+
+&uart0 {
+	clocks = <&misc_clk &misc_clk>;
+};
+
+&usb0 {
+	clocks = <&misc_clk>, <&misc_clk>;
+};
+
+&usb1 {
+	clocks = <&misc_clk>, <&misc_clk>;
+};
+
+&watchdog0 {
+	clocks= <&misc_clk>;
+};
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
index ce5d848251fa..acb0527fdc4a 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
@@ -14,6 +14,7 @@
 /dts-v1/;
 
 /include/ "zynqmp.dtsi"
+/include/ "zynqmp-ep108-clk.dtsi"
 
 / {
 	model = "ZynqMP EP108";
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 7bc65e391530..e595f22e7e4b 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -90,7 +90,7 @@
 		};
 	};
 
-	amba {
+	amba: amba {
 		compatible = "simple-bus";
 		#address-cells = <2>;
 		#size-cells = <1>;
@@ -99,7 +99,6 @@
 		can0: can at ff060000 {
 			compatible = "xlnx,zynq-can-1.0";
 			status = "disabled";
-			clocks = <&misc_clk &misc_clk>;
 			clock-names = "can_clk", "pclk";
 			reg = <0x0 0xff060000 0x1000>;
 			interrupts = <0 23 4>;
@@ -111,7 +110,6 @@
 		can1: can at ff070000 {
 			compatible = "xlnx,zynq-can-1.0";
 			status = "disabled";
-			clocks = <&misc_clk &misc_clk>;
 			clock-names = "can_clk", "pclk";
 			reg = <0x0 0xff070000 0x1000>;
 			interrupts = <0 24 4>;
@@ -120,12 +118,6 @@
 			rx-fifo-depth = <0x40>;
 		};
 
-		misc_clk: misc_clk {
-			compatible = "fixed-clock";
-			#clock-cells = <0>;
-			clock-frequency = <25000000>;
-		};
-
 		gem0: ethernet at ff0b0000 {
 			compatible = "cdns,gem";
 			status = "disabled";
@@ -133,7 +125,6 @@
 			interrupts = <0 57 4>, <0 57 4>;
 			reg = <0x0 0xff0b0000 0x1000>;
 			clock-names = "pclk", "hclk", "tx_clk";
-			clocks = <&misc_clk>, <&misc_clk>, <&misc_clk>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 		};
@@ -145,7 +136,6 @@
 			interrupts = <0 59 4>, <0 59 4>;
 			reg = <0x0 0xff0c0000 0x1000>;
 			clock-names = "pclk", "hclk", "tx_clk";
-			clocks = <&misc_clk>, <&misc_clk>, <&misc_clk>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 		};
@@ -157,7 +147,6 @@
 			interrupts = <0 61 4>, <0 61 4>;
 			reg = <0x0 0xff0d0000 0x1000>;
 			clock-names = "pclk", "hclk", "tx_clk";
-			clocks = <&misc_clk>, <&misc_clk>, <&misc_clk>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 		};
@@ -169,7 +158,6 @@
 			interrupts = <0 63 4>, <0 63 4>;
 			reg = <0x0 0xff0e0000 0x1000>;
 			clock-names = "pclk", "hclk", "tx_clk";
-			clocks = <&misc_clk>, <&misc_clk>, <&misc_clk>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 		};
@@ -178,7 +166,6 @@
 			compatible = "xlnx,zynqmp-gpio-1.0";
 			status = "disabled";
 			#gpio-cells = <0x2>;
-			clocks = <&misc_clk>;
 			interrupt-parent = <&gic>;
 			interrupts = <0 16 4>;
 			interrupt-controller;
@@ -186,19 +173,12 @@
 			reg = <0x0 0xff0a0000 0x1000>;
 		};
 
-		i2c_clk: i2c_clk {
-			compatible = "fixed-clock";
-			#clock-cells = <0x0>;
-			clock-frequency = <111111111>;
-		};
-
 		i2c0: i2c at ff020000 {
 			compatible = "cdns,i2c-r1p10";
 			status = "disabled";
 			interrupt-parent = <&gic>;
 			interrupts = <0 17 4>;
 			reg = <0x0 0xff020000 0x1000>;
-			clocks = <&i2c_clk>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 		};
@@ -209,24 +189,16 @@
 			interrupt-parent = <&gic>;
 			interrupts = <0 18 4>;
 			reg = <0x0 0xff030000 0x1000>;
-			clocks = <&i2c_clk>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 		};
 
-		sata_clk: sata_clk {
-			compatible = "fixed-clock";
-			#clock-cells = <0>;
-			clock-frequency = <75000000>;
-		};
-
 		sata: ahci at fd0c0000 {
 			compatible = "ceva,ahci-1v84";
 			status = "disabled";
 			reg = <0x0 0xfd0c0000 0x2000>;
 			interrupt-parent = <&gic>;
 			interrupts = <0 133 4>;
-			clocks = <&sata_clk>;
 		};
 
 		sdhci0: sdhci at ff160000 {
@@ -236,7 +208,6 @@
 			interrupts = <0 48 4>;
 			reg = <0x0 0xff160000 0x1000>;
 			clock-names = "clk_xin", "clk_ahb";
-			clocks = <&misc_clk>, <&misc_clk>;
 		};
 
 		sdhci1: sdhci at ff170000 {
@@ -246,7 +217,6 @@
 			interrupts = <0 49 4>;
 			reg = <0x0 0xff170000 0x1000>;
 			clock-names = "clk_xin", "clk_ahb";
-			clocks = <&misc_clk>, <&misc_clk>;
 		};
 
 		smmu: smmu at fd800000 {
@@ -268,7 +238,6 @@
 			interrupts = <0 19 4>;
 			reg = <0x0 0xff040000 0x1000>;
 			clock-names = "ref_clk", "pclk";
-			clocks = <&misc_clk &misc_clk>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 		};
@@ -280,7 +249,6 @@
 			interrupts = <0 20 4>;
 			reg = <0x0 0xff050000 0x1000>;
 			clock-names = "ref_clk", "pclk";
-			clocks = <&misc_clk &misc_clk>;
 			#address-cells = <1>;
 			#size-cells = <0>;
 		};
@@ -291,7 +259,6 @@
 			interrupt-parent = <&gic>;
 			interrupts = <0 36 4>, <0 37 4>, <0 38 4>;
 			reg = <0x0 0xff110000 0x1000>;
-			clocks = <&misc_clk>;
 			timer-width = <32>;
 		};
 
@@ -301,7 +268,6 @@
 			interrupt-parent = <&gic>;
 			interrupts = <0 39 4>, <0 40 4>, <0 41 4>;
 			reg = <0x0 0xff120000 0x1000>;
-			clocks = <&misc_clk>;
 			timer-width = <32>;
 		};
 
@@ -311,7 +277,6 @@
 			interrupt-parent = <&gic>;
 			interrupts = <0 42 4>, <0 43 4>, <0 44 4>;
 			reg = <0x0 0xff130000 0x1000>;
-			clocks = <&misc_clk>;
 			timer-width = <32>;
 		};
 
@@ -321,7 +286,6 @@
 			interrupt-parent = <&gic>;
 			interrupts = <0 45 4>, <0 46 4>, <0 47 4>;
 			reg = <0x0 0xff140000 0x1000>;
-			clocks = <&misc_clk>;
 			timer-width = <32>;
 		};
 
@@ -332,7 +296,6 @@
 			interrupts = <0 21 4>;
 			reg = <0x0 0xff000000 0x1000>;
 			clock-names = "uart_clk", "pclk";
-			clocks = <&misc_clk &misc_clk>;
 		};
 
 		uart1: serial at ff010000 {
@@ -342,7 +305,6 @@
 			interrupts = <0 22 4>;
 			reg = <0x0 0xff010000 0x1000>;
 			clock-names = "uart_clk", "pclk";
-			clocks = <&misc_clk &misc_clk>;
 		};
 
 		usb0: usb at fe200000 {
@@ -352,7 +314,6 @@
 			interrupts = <0 65 4>;
 			reg = <0x0 0xfe200000 0x40000>;
 			clock-names = "clk_xin", "clk_ahb";
-			clocks = <&misc_clk>, <&misc_clk>;
 		};
 
 		usb1: usb at fe300000 {
@@ -362,13 +323,11 @@
 			interrupts = <0 70 4>;
 			reg = <0x0 0xfe300000 0x40000>;
 			clock-names = "clk_xin", "clk_ahb";
-			clocks = <&misc_clk>, <&misc_clk>;
 		};
 
 		watchdog0: watchdog at fd4d0000 {
 			compatible = "cdns,wdt-r1p2";
 			status = "disabled";
-			clocks= <&misc_clk>;
 			interrupt-parent = <&gic>;
 			interrupts = <0 52 1>;
 			reg = <0x0 0xfd4d0000 0x1000>;
-- 
1.9.1



From broonie at kernel.org  Thu Feb 11 04:27:36 2016
From: broonie at kernel.org (Mark Brown)
Date: Thu, 11 Feb 2016 12:27:36 +0000
Subject: [PATCH 3/4] spi: bcm2835aux: set up spi-mode before asserting
 cs-gpio
In-Reply-To: <2743238.b2UJKq0efN@chaos-desktop>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <878u2s2xym.fsf@eliezer.anholt.net>
 <20160210190204.GD13270@sirena.org.uk>
 <2743238.b2UJKq0efN@chaos-desktop>
Message-ID: <20160211122736.GH13270@sirena.org.uk>

On Wed, Feb 10, 2016 at 09:26:05PM +0100, Stephan Olbrich wrote:
> Am Wednesday 10 February 2016, 19:02:04 schrieb Mark Brown:

> > No guarantee that they'll not change, especially in a situation where we
> > have two devices on different speeds on a bus working at the same time.

> Are you saying, that between a prepare and unprepare there could be transfers 
> for another device? Then all the clock setting couldn't be done in prepare 
> either.
> Apart from that, if two transfers in the same message are not guarantied to 
> have the same speed, this still needs to be fixed. I'll roll a v2.

There are two prepares, I don't know which you're talking about.  The
most common is prepare_transfer_hardware() which is used to power up the
hardware and may have many transfers for many devices before it is
reversed.  The other is prepare_message() which is called once per
message.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/21540ab2/attachment-0001.sig>

From andre.przywara at arm.com  Thu Feb 11 04:29:46 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 11 Feb 2016 12:29:46 +0000
Subject: breaking DT compatibility
In-Reply-To: <20160211114410.GA32535@leverpostej>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <56BB2D79.6090402@arm.com>
 <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
 <20160210143755.GE31506@lukather> <20160210163001.GG2632@leverpostej>
 <20160211100048.GK31506@lukather> <20160211114410.GA32535@leverpostej>
Message-ID: <56BC7EBA.9030101@arm.com>

Hi,

On 11/02/16 11:44, Mark Rutland wrote:
> On Thu, Feb 11, 2016 at 11:00:48AM +0100, Maxime Ripard wrote:
>> On Wed, Feb 10, 2016 at 04:30:01PM +0000, Mark Rutland wrote:
>>> On Wed, Feb 10, 2016 at 03:37:55PM +0100, Maxime Ripard wrote:
>>>> Hi Rob,
>>>>
>>>> On Wed, Feb 10, 2016 at 07:42:02AM -0600, Rob Herring wrote:
>>>>> On Wed, Feb 10, 2016 at 6:30 AM, Andre Przywara <andre.przywara at arm.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> just a ping:
>>>>>>
>>>>>> Are we really OK with breaking existing DTs in 4.6? (per the code in
>>>>>> -next: f7d372ba54ea04d528a291b8dbe34716507bb60b, which is this patch).
>>>>>
>>>>> I only warn and make sure people are aware of the issue. I leave that
>>>>> up to platform maintainers to decide. It depends on the maturity of
>>>>> the platform and users.
>>>>
>>>> The impacted SoCs support is really partial. For the most supported
>>>> one, big things like display or sound are totally missing, and we
>>>> still update them on a regular basis to add support for new
>>>> devices. As such, users are very likely to upgrade the DT from one
>>>> version to another just because there's new devices available to
>>>> them. And the newest SoC impacted just got introduced in 4.5, and only
>>>> has the UART and MMC devices available.
>>>>
>>>>> If people complain about it then it's their mess. For platforms
>>>>> supported in distros such as debian or fedora, I would strongly
>>>>> recommend against breaking compatibility.
>>>>
>>>> None of them are officially supported:
>>>> https://www.debian.org/releases/stable/armhf/ch02s01.html.en
>>>> https://fedoraproject.org/wiki/Architectures/ARM#Fedora_23
>>>>
>>>> Only the older one are, and they are not affected by this patch.
>>>>
>>>>> They do ship dtbs, but it's a chicken and egg problem. If dtbs were
>>>>> stable and provided by firmware, then they wouldn't have to provide
>>>>> them. If dtbs are unstable, then they have no choice.
>>>>
>>>> And while it might work great on platforms that have all the needed
>>>> documentation, or a perfect one, which is our case. Almost each
>>>> release, we discover that something is not working as it was
>>>> documented, when it was documented in the first place.
>>>>
>>>> It also seems that even on well documented platforms, supported by the
>>>> vendors, the stable ABI dream is not going to happen:
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Atmel/README#n105
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/arm/marvell,berlin.txt#n4
>>>
>>> To be quite frank, I completely disagree with that stance.
>>>
>>> It seems like the only reason DT bindings aren't remaining stable is
>>> because people are deliberately ignoring the requirement and reasoning
>>> for doing so.
>>
>> And for DT maintainers saying on multiple occasions that it's bad but
>> ok to break it and / or that they never actually said that it was a
>> stable ABI...
> 
> Evidently there is a communication failure. Generally, the statement has
> been that old DTBs should continue to work. That's even documented, as
> Andre pointed out:
> 
> Documentation/devicetree/bindings/ABI.txt
> 
> There are obviously shades of grey, and _rarely_ it might be necessary
> to deliberately break a binding. However, that should be the rare
> last-resort case, rather than a crutch for development.
> 
> Saying "bad but ok" underplays the "bad" and overplays the "ok".
> 
>> I'm guessing it could be a stable ABI if there was bindings
>> reviews. Rob actually started to review a significant amount of
>> bindings lately, and that's really appreciated, but if you don't
>> review all the bindings, then we're going to make mistakes.
> 
> I agree that it is unfortunate that we cannot provide the level of
> review that we want to.
> 
> Mistakes will happen even with review; that doesn't necessitate removing
> support for a binding.
> 
>>> I agree that it can be painful, and that we cannot predict the future.
>>> There will always be bugs.
>>
>> In our case, we can't even predict the present.
>>
>>> Having code in mainline comes with responsibilities. One of those is to
>>> keep said code working for existing users. Otherwise, why bother having
>>> it in mainline at all?
>>
>> None of our existing users ever complained.
> 
> I believe that in this case, Andre was complaining about this particular
> breakage, unless I have misunderstood.
> 
> To be clear, I'm arguing for the strategy going forward. If no-one has
> complained about the stuff broken up to this point, let's not waste time
> restoring that.
> 
> Going forward we need to keep old DTBs supported.

FWIW: I had a chat with Maxime and we exchanged ideas on how to go on
from here, by reworking this commit to be both compatible and fixing the
issue we are having with the current PLL6 binding. I will look at
generating patches for this shortly.

So I guess we can move the discussion more to a code level from here on.

Cheers,
Andre.


From lars at metafoo.de  Thu Feb 11 04:13:28 2016
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Thu, 11 Feb 2016 13:13:28 +0100
Subject: [PATCH v2] dmaengine: edma: Implement device_synchronize callback
In-Reply-To: <56BC6C94.1060409@ti.com>
References: <1455181722-32099-1-git-send-email-peter.ujfalusi@ti.com>
 <56BC5759.80000@metafoo.de> <56BC6C94.1060409@ti.com>
Message-ID: <56BC7AE8.2070009@metafoo.de>

On 02/11/2016 12:12 PM, Peter Ujfalusi wrote:
> On 02/11/2016 11:41 AM, Lars-Peter Clausen wrote:
>> On 02/11/2016 10:08 AM, Peter Ujfalusi wrote:
>>> We need the callback to support the dmaengine_terminate_sync().
>>>
>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
>>
>> Looks good, but I noticed a slight race condition in
>> edma_completion_handler(). You need to fetch echan->desc while holding the
>> vchan.lock. Otherwise this can race against terminate_all() and the callback
>> might get scheduled even though terminate_all() completed and then there is
>> a race where the synchronize() operation could be called before the callback
>> gets scheduled, which means it doesn't do its intended job. Highly unlikely
>> to happen, but theoretically possible.
> 
> Right, actually I had (have) another series fixing the very same race in a
> different way - patching the terminate_all (series attached).
> We have seen race with RT kernel on uniprocessor setup.
> 
> The tasklet_kill after the terminate_all will execute the scheduled task
> unconditionally, so the vchan_complete() will run after we have terminated the
> channel, which might be not what we want.
> I have also seen a race condition as explained in the first patch. The only
> way I was able to fix that by using the attached patches. Unfortunately I can
> not test RT with mainline yet, so I'm not 100% sure if by using the
> dmaengine_terminate_sync() in drivers will fix the issue.
> 

Yes, dmaengine_terminate_sync() is supposed to fix the same issue. One of
the problems when implementing this was that e.g. for audio it might happen
that we terminate the transfer from within the tasklet callback itself. In
that case doing tasklet_disable() will deadlock since it will wait until the
tasklet has finished from within the tasklet.

This is why the synchronize API has two primitives. Terminate and
synchronize, so you can split them if necessary.

The only thing you need to make sure is that the implementation of
synchronize() is correct. In the EDMA case echan->desc is read without
holding a lock which still keeps the race condition open.

- Lars


From maxime.ripard at free-electrons.com  Thu Feb 11 04:36:48 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Feb 2016 13:36:48 +0100
Subject: [PATCH 01/14] pinctrl: sunxi: Add A83T R_PIO controller support
In-Reply-To: <CACRpkdbCgOBQw28d=qc1fAURY3x8UdoWqiMtXMZ=uWLaQj-nbg@mail.gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-2-git-send-email-vishnupatekar0510@gmail.com>
 <CACRpkdbCgOBQw28d=qc1fAURY3x8UdoWqiMtXMZ=uWLaQj-nbg@mail.gmail.com>
Message-ID: <20160211123648.GN31506@lukather>

Hi Linus,

On Thu, Feb 11, 2016 at 12:59:47PM +0100, Linus Walleij wrote:
> On Sun, Jan 31, 2016 at 2:20 AM, Vishnu Patekar
> <vishnupatekar0510 at gmail.com> wrote:
> 
> > The A83T has R_PIO pin controller, it's same as A23, execpt A83T
> > interrupt bit is 6th and A83T has one extra pin PL12.
> >
> > Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
> 
> Maxime, can you look at this patch?

Chen-Yu had one minor comment on it, and he's also the Allwinner
maintainer now, so you can trust his Acked-by just like you would
trust mine ;)

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/f0fd5ef1/attachment.sig>

From broonie at kernel.org  Thu Feb 11 04:50:04 2016
From: broonie at kernel.org (Mark Brown)
Date: Thu, 11 Feb 2016 12:50:04 +0000
Subject: [PATCH] coresight: etb: Remove simple announcement message
Message-ID: <1455195004-30214-1-git-send-email-broonie@kernel.org>

It's generally preferred that drivers not print initialisation messages on
startup that don't contain information gained at runtime such as specific
hardware revision information. This provides a small speedup on systems
with serial consoles and keeps the boot less noisy.

Signed-off-by: Mark Brown <broonie at kernel.org>
---
 drivers/hwtracing/coresight/coresight-etb10.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 92969dae739d..18c55d1c428c 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -481,7 +481,6 @@ static int etb_probe(struct amba_device *adev, const struct amba_id *id)
 	if (ret)
 		goto err_misc_register;
 
-	dev_info(dev, "ETB initialized\n");
 	return 0;
 
 err_misc_register:
-- 
2.7.0



From heiko at sntech.de  Thu Feb 11 04:53:59 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Thu, 11 Feb 2016 13:53:59 +0100
Subject: [PATCH] ARM: dts: cros-ec-keyboard: Add LOCK key to keyboard
 matrix
In-Reply-To: <1454121504-12683-1-git-send-email-djkurtz@chromium.org>
References: <1454121504-12683-1-git-send-email-djkurtz@chromium.org>
Message-ID: <3118190.LxA1oBmXCc@phil>

Am Samstag, 30. Januar 2016, 10:38:24 schrieb Daniel Kurtz:
> From: James Chao <james_chao at asus.com>
> 
> The LOCK key is at KSO9/KSI3 for Chromebook Flip and other devices
> that use the Chrome OS EC keyboard matrix.
> 
> Signed-off-by: James Chao <james_chao at asus.com>
> Signed-off-by: Daniel Kurtz <djkurtz at chromium.org>
> Signed-off-by: YH Huang <yh.huang at mediatek.com>

applied to my dts32 branch for 4.6


From gpkulkarni at gmail.com  Thu Feb 11 05:03:12 2016
From: gpkulkarni at gmail.com (Ganapatrao Kulkarni)
Date: Thu, 11 Feb 2016 18:33:12 +0530
Subject: [PATCH v4 0/6] arm64 UEFI early FDT handling
In-Reply-To: <CAKv+Gu-KpasM9QZ8qrZEk_pUJpf3TceaenLYTx_eAHW6AUmutA@mail.gmail.com>
References: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
 <CAKv+Gu-osoi53cpikDtZitJJX2gtZyhOMuvYf=cfeZi8zJ-LDg@mail.gmail.com>
 <20160211114204.GO24726@rric.localdomain>
 <CAKv+Gu-KpasM9QZ8qrZEk_pUJpf3TceaenLYTx_eAHW6AUmutA@mail.gmail.com>
Message-ID: <CAFpQJXX2vGog9q=684uOMhggj3A90G8piUSV9gE5pDJm_AZeNQ@mail.gmail.com>

Hi Ard,

On Thu, Feb 11, 2016 at 5:44 PM, Ard Biesheuvel
<ard.biesheuvel at linaro.org> wrote:
> On 11 February 2016 at 12:42, Robert Richter
> <robert.richter at caviumnetworks.com> wrote:
>> (+RobH and MarkR)
>>
>> On 09.02.16 15:35:42, Ard Biesheuvel wrote:
>>> (+ Grant)
>>>
>>> On 9 February 2016 at 14:53, Robert Richter <rrichter at caviumnetworks.com> wrote:
>>> > From: Robert Richter <rrichter at cavium.com>
>>> >
>>> > Reposting an updated version of this patches ported to 4.5-rc1. It is
>>> > a followup to the version 3 from:
>>> >
>>> >  http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel at linaro.org
>>> >
>>> > The series is essential for NUMA on arm64. Early FDT handling is
>>> > required to make system topology data from firmware, esp. for cpus and
>>> > memory available to the early boot process. Ganapat's numa patches
>>> > depend on it. This series has been tested with his series v10 posted
>>> > here:
>>> >
>>> >  http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni at caviumnetworks.com
>>> >
>>>
>>> Hello Robert,
>>>
>>> This series does not reflect anymore what we think is the best way to
>>> deal with memory nodes and memreserves on UEFI systems.
>>> Please refer to this thread:
>>> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>>>
>>> As far as the memory nodes are concerned, if it is the best place to
>>> store these NUMA annotations, then we should indeed preserve them, but
>>> I think the discussion stalled without any conclusion having been
>>> reached. As far as the /reserved-memory node is concerned, that one we
>>> should really keep, so at least patch 6/6 of this series should be
>>> replaced with something based on the series above.
>>
>> Ard,
>>
>> Mark R and Rob have agreed for numa dt binding for mem nodes. So do
>> you think we can at least reuse parts of this series to solve the NUMA
>> issue and try to find a solution for patch #6 which aligns with your
>> alternative approach?
>>
>
> OK, if we are all in agreement that NUMA annotations belong in memory
> nodes, which are otherwise ignored completely on UEFI systems, I am
> fine with this as well.
>
> However, we have to think about what it means if the memory nodes are
> out of sync with the UEFI memory map, both on NUMA and ordinary
> systems. I know very little about NUMA, but I could imagine that on
> any UEFI system, the UEFI memory map remains authoritative, and memory
> nodes are only used to annotate regions that are already known to
> exist. Alternatively, some sanity check could be appropriate (such as
> the one I proposed for the /reserved-memory node in the link above),
> but we need to consider carefully how the firmware is supposed to
> produce memory nodes and a UEFI memory map that are mutually
> consistent.

Yes memory nodes are updated at runtime from the firmware/uefi with
actual size and
is aligned to efi memory table.
in NUMA patches it is taken care to fail, if memory table and memory
nodes(also ACPI SRAT table) are not aligned.

On thunderx, in uefi,  we do update memory nodes based on actual
memory present on each
nodes, which is not fixed on every board and varies based on number of
DIMMs etc present on board.

Same is done for ACPI SRAT table which is updated at runtime from uefi
with actual memory size of each node.

it is reasonable expectation from firmware to create/update dt or acpi
tables at runtime for a server platform.

for non-NUMA systems, dummy single node(node 0) numa system is created
using all available memory on system.
if kernel is compiled with CONFIG_NUMA=y and it dont have any numa bindings.
>
> I think we can replace 6/6 with the series above, i.e., honour the
> allocations after establishing that the fixed allocations are either
> still available, or entirely disjoint from what the UEFI memory map
> describes.
>
> --
> Ard.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

thanks
Ganapat


From will.deacon at arm.com  Thu Feb 11 05:07:20 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 11 Feb 2016 13:07:20 +0000
Subject: [PATCH] arm64: Add workaround for Cavium erratum 27456
In-Reply-To: <56BB848A.6060603@caviumnetworks.com>
References: <1455046156-10582-1-git-send-email-ddaney.cavm@gmail.com>
 <20160210092822.GA1052@arm.com>
 <56BB7C91.5010205@caviumnetworks.com>
 <20160210181522.GW1052@arm.com>
 <56BB848A.6060603@caviumnetworks.com>
Message-ID: <20160211130720.GD32084@arm.com>

Hi David,

Thanks for the reply.

On Wed, Feb 10, 2016 at 10:42:18AM -0800, David Daney wrote:
> On 02/10/2016 10:15 AM, Will Deacon wrote:
> >On Wed, Feb 10, 2016 at 10:08:17AM -0800, David Daney wrote:
> >>On 02/10/2016 01:28 AM, Will Deacon wrote:
> >>>On Tue, Feb 09, 2016 at 11:29:16AM -0800, David Daney wrote:
> >>>>From: Andrew Pinski <apinski at cavium.com>
> >>>>
> >>>>On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
> >>>>instructions may cause the icache to become invalid if it contains
> >>>>data for a non-current ASID.
> >>>>
> >>>>This patch implements the workaround (which flushes the local icache
> >>>>when switching the mm) by using code patching.
> >>>
> >>>So, to be clear, is this "just" a performance problem as opposed to a
> >>>correctness issue?
> >>
> >>No.  It is a correctness issue.  Without this workaround in place, userspace
> >>programs end up executing the wrong instructions, which leads to
> >>unpredictable behavior and program crashes.
> >
> >Ok, so I think the description in the commit log isn't quite right. An
> >"invalid" line in i-cache simply means that it needs to be refetched.
> >What you're talking about sounds like data corruption.
> 
> Yes.  I guess I will be sending v3 with an improved description.

Yes, please!

> >I also don't understand how the workaround fixes things like TLBIs due
> >to copy-on-write faults triggered by another core.
> 
> Caveat: I don't fully understand the internal ICache implementation details.
> But ...
> 
> External broadcast TLBIs arriving for the current ASID (as set in TTBR0_EL1)
> are handled properly.  The issue is that cached data for other ASIDs, under
> some circumstances, may be inadvertently "blessed" into the current ASID.
> If we take care that no data for "foreign" ASIDs is in the Icache, the
> problematical case can never occur.

Ok, that makes sense. Maybe include this in the description too.

> >Also, what's the
> >interaction with virtual machines, or is the VMID not affected in the
> >same way as the ASID?
> 
> Ah, the $10^6 question.  Current information on how this interacts with KVM
> is less well developed.  We think the workaround doesn't cause failures in
> virtual machines.
> 
> I realize that this is different than asserting that virtual machines are
> guaranteed to operate error free.

So, to confirm, we don't need to flush the I-cache on world-switch in
KVM?

Will


From martin at sperl.org  Thu Feb 11 05:15:10 2016
From: martin at sperl.org (Martin Sperl)
Date: Thu, 11 Feb 2016 14:15:10 +0100
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in
 console
In-Reply-To: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
References: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
Message-ID: <56BC895E.2010108@sperl.org>


On 10.02.2016 16:12, Martin Sperl wrote:
> Hi!
>
> I got a strange effect when using the auxiliar UART as the logging console:
>
> The kernel is configured for drivers/tty/serial/8250/8250_bcm2835aux.c to
> get linked into the main kernel (requires also 8250.c to be linked in).
>
> As long as I boot using the main UART (PL011) in the kernel parameters:
>    earlyprintk consoleblank=0 console=ttyAMA0 root=/dev/mmcblk0p2 rootwait
>
> Everything works fine - early_printk works and normal logging works as well.
> Both configured ttys (/dev/ttyAMA0 and /dev/ttyS0) in /etc/initttab
> work fine.
>
> Now when I switch the console to use the auxiliar UART
> (which right now does not support early_printk) like this:
>    earlyprintk consoleblank=0 console=ttyS0,115200n1 root=/dev/mmcblk0p2 rootwait
>
> I get the situation where:
> * u-boot starts and writes to the main UART
> * Kernel boots using early_printk logging to the main UART until we get to:
>    [    2.657090] bootconsole [earlycon0] disabled
> * then we see the earlyprintk buffer dumped on the aux-uart
> * then booting continues and logging happens on the aux-uart:
>    [    2.657090] bootconsole [earlycon0] disabled
>    [    2.662673] 20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
>    [    2.663793] console [ttyS0] disabled
>    [    2.663899] 20215040.serial: ttyS0 at MMIO 0x0 (irq = 53, base_baud = 31224999) is a 16550
>    [    3.384166] console [ttyS0] enabled
> * everything works fine and I get networking and everything up
>    [....] Starting NTP server: ntpd. ok
>    [....] Starting OpenBSD Secure Shell server: sshd. ok
>    My IP address is 10.10.10.41 ::127.0.0.1
>
>    Raspbian GNU/Linux 7 raspcm.intern.sperl.org ttyS0
> * I can even log in via SSH and networking works.
>    Note that I have the getty for ttyAMA0 disabled in inittab
> * when I then enable the tty on the main UART like this:
>    root at raspcm:~# /sbin/getty -a root -L ttyAMA0 115200 vt100
> * I get the following:
>    [   72.962845] uart-pl011 20201000.serial: no DMA platform data
> * the system freezes?
> * sometimes I still get the following on the auxiliar UART before the system ?crashes":
>    (at least when starting the tty from inittab)
>    [   73.072985] bcm2835-clk 20101000.cprman: plld: couldn't lock PLL
>    [   73.079132] ------------[ cut here ]------------
>    [   73.083848] WARNING: CPU: 0 PID: 2329 at drivers/clk/clk.c:680 clk_core_disable+0x34/0xf0()
>    [   73.093067] ---[ end trace 416e78cea88f5fb5 ]---
>    [   73.097848] ------------[ cut here ]------------
>    [   73.102616] WARNING: CPU: 0 PID: 2329 at drivers/clk/clk.c:575 clk_core_unprepare+0x34/0x110()
>    [   73.112219] ---[ end trace 416e78cea88f5fb6 ]---
>
> A similar effect I get when using stty:
>    root at raspcm:~# stty -F /dev/ttyAMA0
>    [  128.878127] uart-pl011 20201000.serial: no DMA platform data
>    speed 9600 baud; line = 0;
>    -brkint -imaxbel
> Then the system freezes.
>
> As if the plld does not lock - even if it (probably) is already locked.
>
> Or the message actually comes from bcm2835_clock_wait_busy which also
> produces this message - so maybe we should better identify the message.
>
> Note that the same also applies if I remove earlyprintk with
> the only difference being that I do not get the initial boot
> messages on the main UART.
> (at that time only: "Uncompressing Linux... done, booting the kernel.?
> shows on the main uart after u-boot start..)
>
> Unfortunately it is only possible to really test this on a
> rpi-Compute module, as only there we can expose both uarts
> on distinct GPIOs at the same time:
>    GPIO 14: level=1 fsel=4 alt=0 func=TXD0
>    GPIO 15: level=1 fsel=4 alt=0 func=RXD0
>    GPIO 32: level=1 fsel=2 alt=5 func=TXD1
>    GPIO 33: level=1 fsel=2 alt=5 func=RXD1
>
> Here the commits I have used based on spi/for-next (based on 4.4.0)
> with the patches (* prefix) for the driver for aux-uart
> added separately as they are not in the tree I have used:
> * a96f6c7 serial: bcm2835: add driver for bcm2835-aux-uart
> * 464e876 clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.
> * 1af1b28 clk: bcm2835: Add a driver for the auxiliary peripheral clock gates.
> ece19b8 Merge remote-tracking branch 'spi/fix/loopback' into spi-linus
> 887e6a3 Merge tag 'spi-v4.5' into spi-linus
> ebea7c0 spi: fix counting in spi-loopback-test code
> cabeea9 Merge remote-tracking branches 'spi/topic/sun4i', 'spi/topic/topcliff-pc
> 4f95307 Merge remote-tracking branches 'spi/topic/overlay', 'spi/topic/pxa2xx',
> 41d5a70 Merge remote-tracking branches 'spi/topic/lm70llp', 'spi/topic/loopback'
> 635b9b2 Merge remote-tracking branches 'spi/topic/dw', 'spi/topic/dw-mid', 'spi/
> 3c27892 Merge remote-tracking branches 'spi/topic/bcm63xx', 'spi/topic/butterfly
> 9b17e80 Merge remote-tracking branch 'spi/topic/sunxi' into spi-next
> 174c211 Merge remote-tracking branch 'spi/topic/core' into spi-next
> f30f072 Merge remote-tracking branch 'spi/fix/mtk' into spi-linus
> afd2ff9 Linux 4.4
>
> Maybe someone has gotten any idea?
>
> In the meantime I will try to reproduce on a 4.5-rc3 based branch.
Same issue with 4.5-rc3 - here the commits:
* bec2300c serial: bcm2835: add driver for bcm2835-aux-uart
388f7b1 Linux 4.5-rc3

Here the clock calls I have instrumented for the console=ttyAMA0 case:
[    1.884107] bcm2835-clk 20101000.cprman: bcm2835_pll_get_rate - plla
[    1.890723] bcm2835-clk 20101000.cprman: bcm2835_pll_get_rate - pllb
[    1.897308] bcm2835-clk 20101000.cprman: bcm2835_pll_get_rate - pllc
[    1.903849] bcm2835-clk 20101000.cprman: bcm2835_pll_get_rate - plld
[    1.910429] bcm2835-clk 20101000.cprman: bcm2835_pll_get_rate - pllh
[    1.917184] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - timer
[    1.924143] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - timer
[    1.931237] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - otp
[    1.938081] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - otp
[    1.944757] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - tsens
[    1.951714] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - tsens
[    1.958605] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - vpu
[    1.965429] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - vpu
[    1.972088] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - v3d
[    1.978909] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - v3d
[    1.985622] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - isp
[    1.992405] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - isp
[    1.999101] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - h264
[    2.006011] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - h264
[    2.012774] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - sdram
[    2.019772] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - sdram
[    2.026848] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - uart
[    2.033725] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - uart
[    2.040521] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - vec
[    2.047366] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - vec
[    2.054207] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.061065] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - hsm
[    2.067720] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.074699] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - emmc
[    2.081574] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - emmc
[    2.088316] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.095253] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.102112] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - pwm
[    2.108951] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - pwm
[    2.115594] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - pwm
[    2.122374] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.129667] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - pwm
[    2.136523] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.143329] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - pwm
[    2.150148] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.157157] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - pwm
[    2.163942] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.230330] bcm2835-clk 20101000.cprman: bcm2835_pll_on - pllc
[    2.245552] bcm2835-clk 20101000.cprman: bcm2835_pll_on - plld
[    2.251559] bcm2835-clk 20101000.cprman: bcm2835_clock_on - uart
[    2.284246] bcm2835-clk 20101000.cprman: bcm2835_clock_on - emmc

And for the console=ttyS0,115200 case:
[    1.884106] bcm2835-clk 20101000.cprman: bcm2835_pll_get_rate - plla
[    1.890721] bcm2835-clk 20101000.cprman: bcm2835_pll_get_rate - pllb
[    1.897307] bcm2835-clk 20101000.cprman: bcm2835_pll_get_rate - pllc
[    1.903849] bcm2835-clk 20101000.cprman: bcm2835_pll_get_rate - plld
[    1.910429] bcm2835-clk 20101000.cprman: bcm2835_pll_get_rate - pllh
[    1.917183] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - timer
[    1.924143] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - timer
[    1.931234] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - otp
[    1.938077] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - otp
[    1.944759] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - tsens
[    1.951717] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - tsens
[    1.958607] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - vpu
[    1.965429] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - vpu
[    1.972089] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - v3d
[    1.978908] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - v3d
[    1.985620] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - isp
[    1.992406] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - isp
[    1.999102] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - h264
[    2.006010] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - h264
[    2.012772] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - sdram
[    2.019769] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - sdram
[    2.026842] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - uart
[    2.033719] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - uart
[    2.040518] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - vec
[    2.047362] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - vec
[    2.054199] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.061052] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - hsm
[    2.067706] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.074688] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - emmc
[    2.081561] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - emmc
[    2.088303] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.095241] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.102100] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - pwm
[    2.108938] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - pwm
[    2.115582] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - pwm
[    2.122362] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.129648] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - pwm
[    2.136509] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.143315] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - pwm
[    2.150135] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.157145] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - pwm
[    2.163929] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.230333] bcm2835-clk 20101000.cprman: bcm2835_pll_on - pllc
[    2.275803] bcm2835-clk 20101000.cprman: bcm2835_clock_on - emmc

The only real difference is this diff:
@@ -41,6 +41,4 @@
   20101000.cprman: bcm2835_clock_get_parent - pwm
   20101000.cprman: bcm2835_clock_get_parent - hsm
   20101000.cprman: bcm2835_pll_on - pllc
- 20101000.cprman: bcm2835_pll_on - plld
- 20101000.cprman: bcm2835_clock_on - uart
   20101000.cprman: bcm2835_clock_on - emmc

so plld and uart are not started for the console=ttyS0 case.

After I instrumented clk-bcm2835.c to see what happens in the driver
and running: /sbin/getty -a root -L ttyAMA0 115200 vt100

I get the following:
[  146.342341] bcm2835-clk 20101000.cprman: bcm2835_pll_on - plld
[  146.348426] bcm2835-clk 20101000.cprman: bcm2835_clock_on - uart
[  146.354639] uart-pl011 20201000.uart: no DMA platform data
[  146.375535] bcm2835-clk 20101000.cprman: bcm2835_clock_off - uart
[  146.381776] bcm2835-clk 20101000.cprman: bcm2835_clock_wait_busy - uart
[  146.388595] bcm2835-clk 20101000.cprman: bcm2835_pll_off - plld
[  146.396574] bcm2835-clk 20101000.cprman: bcm2835_pll_on - plld
[  146.502551] bcm2835-clk 20101000.cprman: plld: couldn't lock PLL
[  146.508726] ------------[ cut here ]------------
[  146.513448] WARNING: CPU: 0 PID: 2349 at drivers/clk/clk.c:680 
clk_core_disa)
[  146.522673] ---[ end trace 33268753126338e9 ]---
[  146.527478] ------------[ cut here ]------------
[  146.532224] WARNING: CPU: 0 PID: 2349 at drivers/clk/clk.c:575 
clk_core_unpr)
[  146.541866] ---[ end trace 33268753126338ea ]---

So I wonder why we would disable and reenable the plld and uart clock

Note that just adding a return in bcm2835_pll_off like this:
@@ -900,6 +905,9 @@ static void bcm2835_pll_off(struct clk_hw *hw)
      struct bcm2835_cprman *cprman = pll->cprman;
      const struct bcm2835_pll_data *data = pll->data;

+    dev_err(cprman->dev, "%s - %s\n", __FUNCTION__, clk_hw_get_name(hw));
+    return;
+
      cprman_write(cprman, data->cm_ctrl_reg, CM_PLL_ANARST);
      cprman_write(cprman, data->a2w_ctrl_reg, A2W_PLL_CTRL_PWRDN);
  }

avoids the crash, but the tty is non-functional.

Calling sequence of the clock driver is:
[  145.022546] bcm2835-clk 20101000.cprman: bcm2835_pll_on - plld
[  145.028619] bcm2835-clk 20101000.cprman: bcm2835_clock_on - uart
[  145.034807] uart-pl011 20201000.uart: no DMA platform data
[  145.045089] bcm2835-clk 20101000.cprman: bcm2835_clock_off - uart
[  145.051418] bcm2835-clk 20101000.cprman: bcm2835_clock_wait_busy - uart
[  145.058215] bcm2835-clk 20101000.cprman: bcm2835_pll_off - plld
[  145.065779] bcm2835-clk 20101000.cprman: bcm2835_pll_on - plld
[  145.071761] bcm2835-clk 20101000.cprman: bcm2835_clock_on - uart

debugfs shows the following after the above:
root at raspcm:~# head /sys/kernel/debug/clk/uart*/clk_rate
==> /sys/kernel/debug/clk/uart0_pclk/clk_rate <==
3000000

==> /sys/kernel/debug/clk/uart1_pclk/clk_rate <==
125000000

==> /sys/kernel/debug/clk/uart/clk_rate <==
2997598

Is this maybe related to the uart0_pclk, uart1_pclk, apb_pclk
clocks created and registered in bcm2835_init_clocks?

Any Ideas?

Thanks,
                 Martin


From arnd at arndb.de  Thu Feb 11 05:16:27 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 14:16:27 +0100
Subject: [PATCH] libata: fix HDIO_GET_32BIT ioctl
Message-ID: <1455196595-3466120-1-git-send-email-arnd@arndb.de>

As reported by Soohoon Lee, the HDIO_GET_32BIT ioctl does not
work correctly in compat mode with libata.

I have investigated the issue further and found multiple problems
that all appeared with the same commit that originally introduced
HDIO_GET_32BIT handling in libata back in linux-2.6.8 and presumably
also linux-2.4, as the code uses "copy_to_user(arg, &val, 1)" to copy
a 'long' variable containing either 0 or 1 to user space.

The problems with this are:

* On big-endian machines, this will always write a zero because it
  stores the wrong byte into user space.

* In compat mode, the upper three bytes of the variable are updated
  by the compat_hdio_ioctl() function, but they now contain
  uninitialized stack data.

* The hdparm tool calling this ioctl uses a 'static long' variable
  to store the result. This means at least the upper bytes are
  initialized to zero, but calling another ioctl like HDIO_GET_MULTCOUNT
  would fill them with data that remains stale when the low byte
  is overwritten. Fortunately libata doesn't implement any of the
  affected ioctl commands, so this would only happen when we query
  both an IDE and an ATA device in the same command such as
  "hdparm -N -c /dev/hda /dev/sda"

* The libata code for unknown reasons started using ATA_IOC_GET_IO32
  and ATA_IOC_SET_IO32 as aliases for HDIO_GET_32BIT and HDIO_SET_32BIT,
  while the ioctl commands that were added later use the normal
  HDIO_* names. This is harmless but rather confusing.

This addresses all four issues by changing the code to use put_user()
on an 'unsigned long' variable in HDIO_GET_32BIT, like the IDE subsystem
does, and by clarifying the names of the ioctl commands.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reported-by: Soohoon Lee <Soohoon.Lee at f5.com>
Tested-by: Soohoon Lee <Soohoon.Lee at f5.com>
Cc: stable at vger.kernel.org
---
 drivers/ata/libata-scsi.c | 11 +++++------
 include/linux/ata.h       |  4 ++--
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 7e959f90c020..e417e1a1d02c 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -675,19 +675,18 @@ static int ata_ioc32(struct ata_port *ap)
 int ata_sas_scsi_ioctl(struct ata_port *ap, struct scsi_device *scsidev,
 		     int cmd, void __user *arg)
 {
-	int val = -EINVAL, rc = -EINVAL;
+	unsigned long val;
+	int rc = -EINVAL;
 	unsigned long flags;
 
 	switch (cmd) {
-	case ATA_IOC_GET_IO32:
+	case HDIO_GET_32BIT:
 		spin_lock_irqsave(ap->lock, flags);
 		val = ata_ioc32(ap);
 		spin_unlock_irqrestore(ap->lock, flags);
-		if (copy_to_user(arg, &val, 1))
-			return -EFAULT;
-		return 0;
+		return put_user(val, (unsigned long __user *)arg);
 
-	case ATA_IOC_SET_IO32:
+	case HDIO_SET_32BIT:
 		val = (unsigned long) arg;
 		rc = 0;
 		spin_lock_irqsave(ap->lock, flags);
diff --git a/include/linux/ata.h b/include/linux/ata.h
index d2992bfa1706..c1a2f345cbe6 100644
--- a/include/linux/ata.h
+++ b/include/linux/ata.h
@@ -487,8 +487,8 @@ enum ata_tf_protocols {
 };
 
 enum ata_ioctls {
-	ATA_IOC_GET_IO32	= 0x309,
-	ATA_IOC_SET_IO32	= 0x324,
+	ATA_IOC_GET_IO32	= 0x309, /* HDIO_GET_32BIT */
+	ATA_IOC_SET_IO32	= 0x324, /* HDIO_SET_32BIT */
 };
 
 /* core structures */
-- 
2.7.0



From linus.walleij at linaro.org  Thu Feb 11 05:17:41 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Feb 2016 14:17:41 +0100
Subject: [PATCH v2 5/5] pinctrl: sunxi: Use pin number when calling
 sunxi_pmx_set
In-Reply-To: <1454448113-18810-6-git-send-email-k@japko.eu>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
 <1454448113-18810-6-git-send-email-k@japko.eu>
Message-ID: <CACRpkdbc0SfKiCGwUGA2fAPPsUhGv=qGV607Lht6ByYKKgTHjA@mail.gmail.com>

On Tue, Feb 2, 2016 at 10:21 PM, Krzysztof Adamski <k at japko.eu> wrote:

> sunxi_pmx_set accepts pin number and then calculates offset by
> subtracting pin_base from it. sunxi_pinctrl_gpio_get, on the other hand,
> gets offset so we have to convert it to pin number so we won't get
> negative value in sunxi_pmx_set.
>
> This was only used on A10 so far, where there is only one GPIO chip with
> pin_base set to 0 so it didn't matter. However H3 also requires this
> workaround but have two pinmux sections, triggering problem for PL port.
>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

Waiting for Maxime to review this. I guess this patch can be merged
independently of the other patches?

Yours,
Linus Walleij


From peter.ujfalusi at ti.com  Thu Feb 11 05:17:48 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 11 Feb 2016 15:17:48 +0200
Subject: [PATCH] dmaengine: edma: Fetch echan->edesc while holding lock in
 edma_comletion_handler
Message-ID: <1455196668-9327-1-git-send-email-peter.ujfalusi@ti.com>

In order to avoid possible race condition when client drivers are using
dmaengine_terminate_sync() call to disable the channel.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
Suggested-by: Lars-Peter Clausen <lars at metafoo.de>
---
 drivers/dma/edma.c | 54 +++++++++++++++++++++++++++---------------------------
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 290e1a721c5b..13b6a23dc06b 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1372,36 +1372,36 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
 static void edma_completion_handler(struct edma_chan *echan)
 {
 	struct device *dev = echan->vchan.chan.device->dev;
-	struct edma_desc *edesc = echan->edesc;
-
-	if (!edesc)
-		return;
+	struct edma_desc *edesc;
 
 	spin_lock(&echan->vchan.lock);
-	if (edesc->cyclic) {
-		vchan_cyclic_callback(&edesc->vdesc);
-		spin_unlock(&echan->vchan.lock);
-		return;
-	} else if (edesc->processed == edesc->pset_nr) {
-		edesc->residue = 0;
-		edma_stop(echan);
-		vchan_cookie_complete(&edesc->vdesc);
-		echan->edesc = NULL;
-
-		dev_dbg(dev, "Transfer completed on channel %d\n",
-			echan->ch_num);
-	} else {
-		dev_dbg(dev, "Sub transfer completed on channel %d\n",
-			echan->ch_num);
-
-		edma_pause(echan);
-
-		/* Update statistics for tx_status */
-		edesc->residue -= edesc->sg_len;
-		edesc->residue_stat = edesc->residue;
-		edesc->processed_stat = edesc->processed;
+	edesc = echan->edesc;
+	if (edesc) {
+		if (edesc->cyclic) {
+			vchan_cyclic_callback(&edesc->vdesc);
+			spin_unlock(&echan->vchan.lock);
+			return;
+		} else if (edesc->processed == edesc->pset_nr) {
+			edesc->residue = 0;
+			edma_stop(echan);
+			vchan_cookie_complete(&edesc->vdesc);
+			echan->edesc = NULL;
+
+			dev_dbg(dev, "Transfer completed on channel %d\n",
+				echan->ch_num);
+		} else {
+			dev_dbg(dev, "Sub transfer completed on channel %d\n",
+				echan->ch_num);
+
+			edma_pause(echan);
+
+			/* Update statistics for tx_status */
+			edesc->residue -= edesc->sg_len;
+			edesc->residue_stat = edesc->residue;
+			edesc->processed_stat = edesc->processed;
+		}
+		edma_execute(echan);
 	}
-	edma_execute(echan);
 
 	spin_unlock(&echan->vchan.lock);
 }
-- 
2.7.1



From linus.walleij at linaro.org  Thu Feb 11 05:21:15 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Feb 2016 14:21:15 +0100
Subject: [PATCH v2 3/5] pinctrl: sunxi: Add H3 R_PIO controller support
In-Reply-To: <1454448113-18810-4-git-send-email-k@japko.eu>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
 <1454448113-18810-4-git-send-email-k@japko.eu>
Message-ID: <CACRpkdZkSzcb0fmghkvsfRHpsU-SsSGPP6YvstAW7387HS0xJw@mail.gmail.com>

On Tue, Feb 2, 2016 at 10:21 PM, Krzysztof Adamski <k at japko.eu> wrote:

> H3 has additional PIO controller similar to what we can find on A23.
> It's a 12 pin port, described in H3 Datasheet rev 1.1, pages 345-350.
>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

Patch applied with Maxime's ACK.

Yours,
Linus Walleij


From mcoquelin.stm32 at gmail.com  Thu Feb 11 05:21:27 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Thu, 11 Feb 2016 14:21:27 +0100
Subject: [GIT PULL] STM32 DT updates for v4.6 #1
Message-ID: <56BC8AD7.30607@gmail.com>

Hi Olof, Anrd and Kevin,

Please consider this first round of STM32 DT updates for v4.6:

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/mcoquelin/stm32.git 
tags/stm32-dt-for-v4.6-1

for you to fetch changes up to b2aa7f7741f511c6a1ea266d62d203662f121ea7:

   ARM: dts: stm32f429: Boost perfs by remapping SDRAM Bank 1 to 0x0 
(2016-02-11 12:02:59 +0100)

----------------------------------------------------------------
Highlights:
-----------
  - Add DMA controller node to stm32f429 MCU
  - Add pinctrl & gpio nodes to stm32f429 MCU
  - Remap stm32429-eval board SD-Ram to 0x0 for performance boost

----------------------------------------------------------------
M'boumba Cedric Madianga (1):
       ARM: dts: Add STM32 DMA support for STM32F429 MCU

Maxime Coquelin (5):
       includes: dt-bindings: Add STM32F429 pinctrl DT bindings
       ARM: dts: Add pinctrl node to STM32F429
       ARM: dts: Add USART1 pin config to STM32F429 boards
       ARM: dts: Add leds support to STM32F429 boards
       ARM: dts: stm32f429: Boost perfs by remapping SDRAM Bank 1 to 0x0

  arch/arm/boot/dts/stm32429i-eval.dts            |   21 +-
  arch/arm/boot/dts/stm32f429-disco.dts           |   13 +
  arch/arm/boot/dts/stm32f429.dtsi                |  143 +++
  include/dt-bindings/pinctrl/stm32f429-pinfunc.h | 1239 
+++++++++++++++++++++++
  4 files changed, 1415 insertions(+), 1 deletion(-)
  create mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.h


From k at japko.eu  Thu Feb 11 05:20:54 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Thu, 11 Feb 2016 14:20:54 +0100
Subject: [linux-sunxi] Re: [PATCH v2 5/5] pinctrl: sunxi: Use pin number
 when calling sunxi_pmx_set
In-Reply-To: <CACRpkdbc0SfKiCGwUGA2fAPPsUhGv=qGV607Lht6ByYKKgTHjA@mail.gmail.com>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
 <1454448113-18810-6-git-send-email-k@japko.eu>
 <CACRpkdbc0SfKiCGwUGA2fAPPsUhGv=qGV607Lht6ByYKKgTHjA@mail.gmail.com>
Message-ID: <20160211132054.GC19622@box2.japko.eu>

On Thu, Feb 11, 2016 at 02:17:41PM +0100, Linus Walleij wrote:
>On Tue, Feb 2, 2016 at 10:21 PM, Krzysztof Adamski <k at japko.eu> wrote:
>
>> sunxi_pmx_set accepts pin number and then calculates offset by
>> subtracting pin_base from it. sunxi_pinctrl_gpio_get, on the other hand,
>> gets offset so we have to convert it to pin number so we won't get
>> negative value in sunxi_pmx_set.
>>
>> This was only used on A10 so far, where there is only one GPIO chip with
>> pin_base set to 0 so it didn't matter. However H3 also requires this
>> workaround but have two pinmux sections, triggering problem for PL port.
>>
>> Signed-off-by: Krzysztof Adamski <k at japko.eu>
>
>Waiting for Maxime to review this. I guess this patch can be merged
>independently of the other patches?

Yes it can but it won't have any effect, as stated in the commit 
message, since other SoCs either don't use this flag or have only one 
port so theri pin_base=0.

Best regards,
Krzysztof Adamski


From wens at csie.org  Thu Feb 11 05:21:05 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Thu, 11 Feb 2016 21:21:05 +0800
Subject: [PATCH v2 5/5] pinctrl: sunxi: Use pin number when calling
 sunxi_pmx_set
In-Reply-To: <CACRpkdbc0SfKiCGwUGA2fAPPsUhGv=qGV607Lht6ByYKKgTHjA@mail.gmail.com>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
 <1454448113-18810-6-git-send-email-k@japko.eu>
 <CACRpkdbc0SfKiCGwUGA2fAPPsUhGv=qGV607Lht6ByYKKgTHjA@mail.gmail.com>
Message-ID: <CAGb2v659R2SjZW2aTrycv28uyepQCfcGa9HqFg8z923RA3EObA@mail.gmail.com>

Hi,

On Thu, Feb 11, 2016 at 9:17 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Tue, Feb 2, 2016 at 10:21 PM, Krzysztof Adamski <k at japko.eu> wrote:
>
>> sunxi_pmx_set accepts pin number and then calculates offset by
>> subtracting pin_base from it. sunxi_pinctrl_gpio_get, on the other hand,
>> gets offset so we have to convert it to pin number so we won't get
>> negative value in sunxi_pmx_set.
>>
>> This was only used on A10 so far, where there is only one GPIO chip with
>> pin_base set to 0 so it didn't matter. However H3 also requires this
>> workaround but have two pinmux sections, triggering problem for PL port.
>>
>> Signed-off-by: Krzysztof Adamski <k at japko.eu>
>
> Waiting for Maxime to review this. I guess this patch can be merged
> independently of the other patches?

FYI there's a v4 of this patch that both Maxime and I acked.

ChenYu


From mcoquelin.stm32 at gmail.com  Thu Feb 11 05:22:05 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Thu, 11 Feb 2016 14:22:05 +0100
Subject: [GIT PULL] STM32 SoC updates for v4.6 #1
Message-ID: <56BC8AFD.7000800@gmail.com>

Hi Olof, Arnd and Kevin,

Please consider this first round of STM32 SoC updates for v4.6:

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/mcoquelin/stm32.git 
tags/stm32-soc-for-v4.6-1

for you to fetch changes up to f64e980450027e15dce5e9ec4ee19bab98aee4c5:

   ARM: mach-stm32: Select pinctrl (2016-01-27 19:45:57 +0100)

----------------------------------------------------------------
Highlights:
-----------
  - Make STM32 to select PINCTRL
  - Introduce MACH_STM32F429 flag

----------------------------------------------------------------
Maxime Coquelin (2):
       ARM: Kconfig: Introduce MACH_STM32F429 flag
       ARM: mach-stm32: Select pinctrl

  arch/arm/Kconfig | 6 ++++++
  1 file changed, 6 insertions(+


From christoffer.dall at linaro.org  Thu Feb 11 05:27:08 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Thu, 11 Feb 2016 14:27:08 +0100
Subject: [PATCH] arm64: KVM: Configure TCR_EL2.PS at runtime
In-Reply-To: <1455130013-28644-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1455130013-28644-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <20160211132708.GU5171@cbox>

On Wed, Feb 10, 2016 at 10:46:53AM -0800, tchalamarla at caviumnetworks.com wrote:
> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> 
> Setting TCR_EL2.PS to 40 bits is wrong on systems with PS size is
> less than 40 bits. and with systems where RAM is at higher address,
> this will break KVM.
> 
> This patch sets TCR_EL2.PS at runtime similar to VTCR_EL2.PS
> 
> changes form V2:
> 	- Modified subject line and commit message.
> 	- Removed TCR_EL2_FLAGS.
> 
> changes from V1:
>         - Moved to dynamic configuration.
> 
> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> ---
>  arch/arm64/include/asm/kvm_arm.h |  2 --
>  arch/arm64/kvm/hyp-init.S        | 12 +++++++-----
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 738a95f..3776db0 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -107,8 +107,6 @@
>  #define TCR_EL2_MASK	(TCR_EL2_TG0 | TCR_EL2_SH0 | \
>  			 TCR_EL2_ORGN0 | TCR_EL2_IRGN0 | TCR_EL2_T0SZ)
>  
> -#define TCR_EL2_FLAGS	(TCR_EL2_RES1 | TCR_EL2_PS_40B)
> -
>  /* VTCR_EL2 Registers bits */
>  #define VTCR_EL2_RES1		(1 << 31)
>  #define VTCR_EL2_PS_MASK	(7 << 16)
> diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
> index 3e568dc..b5ab1b0 100644
> --- a/arch/arm64/kvm/hyp-init.S
> +++ b/arch/arm64/kvm/hyp-init.S
> @@ -64,7 +64,7 @@ __do_hyp_init:
>  	mrs	x4, tcr_el1
>  	ldr	x5, =TCR_EL2_MASK
>  	and	x4, x4, x5
> -	ldr	x5, =TCR_EL2_FLAGS
> +	ldr	x5, =TCR_EL2_RES1
>  	orr	x4, x4, x5
>  
>  #ifndef CONFIG_ARM64_VA_BITS_48
> @@ -85,15 +85,17 @@ __do_hyp_init:
>  	ldr_l	x5, idmap_t0sz
>  	bfi	x4, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH
>  #endif
> -	msr	tcr_el2, x4
> -
> -	ldr	x4, =VTCR_EL2_FLAGS
>  	/*
>  	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
> -	 * VTCR_EL2.
> +	 * TCR_EL2 and VTCR_EL2.
>  	 */
>  	mrs	x5, ID_AA64MMFR0_EL1
>  	bfi	x4, x5, #16, #3
> +
> +	msr	tcr_el2, x4
> +
> +	ldr	x4, =VTCR_EL2_FLAGS
> +	bfi	x4, x5, #16, #3
>  	/*
>  	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS bit in
>  	 * VTCR_EL2.
> -- 
> 2.1.0
> 

This looks reasonable enough for me.  Did we limit Linux to PS=40 bits
in the past and have lifted this restriction, or why did we have this
limitation for EL2 translations in the past?

Thanks,
-Christoffer


From sunil.kovvuri at gmail.com  Thu Feb 11 05:26:48 2016
From: sunil.kovvuri at gmail.com (Sunil Kovvuri)
Date: Thu, 11 Feb 2016 18:56:48 +0530
Subject: [PATCH 0/6] net: thunderx: Setting IRQ affinity hints and other
 optimizations
In-Reply-To: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <CA+sq2CdXHcWM=PrimSvoQ6dJyCPi0QsiiDzA5=YKKn6zHVsojg@mail.gmail.com>

Hi David,

If time permits, can you please look at this patchset.

Thanks,
Sunil.

On Mon, Feb 8, 2016 at 5:37 PM,  <sunil.kovvuri at gmail.com> wrote:
> From: Sunil Goutham <sgoutham at cavium.com>
>
> This patch series contains changes
> - To add support for virtual function's irq affinity hint
> - Replace napi_schedule() with napi_schedule_irqoff()
> - Reduce page allocation overhead by allocating pages
>   of higher order when pagesize is 4KB.
> - Add couple of stats which helps in debugging
> - Some miscellaneous changes to BGX driver.
>
>
> David Daney (1):
>   net: thunderx: bgx: Use standard firmware node infrastructure.
>
> Robert Richter (1):
>   net: thunderx: bgx: Add log message when setting mac address
>
> Sunil Goutham (3):
>   net: thunderx: Use napi_schedule_irqoff()
>   net: thunderx: Assign affinity hints to vf's interrupts
>   net: thunderx: Alloc higher order pages when pagesize is small
>
> Thanneeru Srinivasulu (1):
>   net, thunderx: Add TX timeout and RX buffer alloc failure stats.
>
>  drivers/net/ethernet/cavium/thunder/nic.h          |    4 ++
>  .../net/ethernet/cavium/thunder/nicvf_ethtool.c    |    2 +
>  drivers/net/ethernet/cavium/thunder/nicvf_main.c   |   40 ++++++++++++++++++-
>  drivers/net/ethernet/cavium/thunder/nicvf_queues.c |    5 +-
>  drivers/net/ethernet/cavium/thunder/thunder_bgx.c  |   38 +++++++++++--------
>  5 files changed, 67 insertions(+), 22 deletions(-)
>


From marc.zyngier at arm.com  Thu Feb 11 05:27:46 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 13:27:46 +0000
Subject: [PATCH v2 2/7] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <1455110583-19515-3-git-send-email-antoine.tenart@free-electrons.com>
References: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
 <1455110583-19515-3-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <56BC8C52.7000102@arm.com>

On 10/02/16 13:22, Antoine Tenart wrote:
> This patch adds the Alpine MSIX interrupt controller driver.
> 
> Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
> Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

	M.
-- 
Jazz is not dead. It just smells funny...


From jglauber at cavium.com  Thu Feb 11 05:28:34 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Thu, 11 Feb 2016 14:28:34 +0100
Subject: [PATCH v3 0/5] Cavium ThunderX PMU support
In-Reply-To: <cover.1454516082.git.jglauber@cavium.com>
References: <cover.1454516082.git.jglauber@cavium.com>
Message-ID: <20160211132833.GA16164@wintermute>

On Wed, Feb 03, 2016 at 06:11:55PM +0100, Jan Glauber wrote:
> Hi,
> 
> I'm reposting the whole series just in case my previous attempt to
> repost only the broken patch was confusing. Patches are based on
> 4.5-rc2.

Can I get a review for these patches?

thanks,
Jan

> Patches 1-3 add support for ThunderX specific PMU events.
> 
> Patch 4 changes the cycle counter to overflow on 64 bit but tries to minimize
> code changes. Without this change perf does not work at all on ThunderX.
> 
> Patch 5 extends the event mask according to ARMv8.1 and also affects arm32.
> 
> Changes to v2:
> - fixed arm compile errors
> 
> Changes to v1:
> - renamed thunderx dt pmu binding to thunder
> 
> --Jan
> 
> Jan Glauber (5):
>   arm64/perf: Rename Cortex A57 events
>   arm64/perf: Add Cavium ThunderX PMU support
>   arm64: dts: Add Cavium ThunderX specific PMU
>   arm64/perf: Enable PMCR long cycle counter bit
>   arm64/perf: Extend event mask for ARMv8.1
> 
>  Documentation/devicetree/bindings/arm/pmu.txt |   1 +
>  arch/arm/kernel/perf_event_v6.c               |   6 +-
>  arch/arm/kernel/perf_event_v7.c               |  29 ++++--
>  arch/arm/kernel/perf_event_xscale.c           |   4 +-
>  arch/arm64/boot/dts/cavium/thunder-88xx.dtsi  |   5 +
>  arch/arm64/kernel/perf_event.c                | 145 ++++++++++++++++++++------
>  drivers/perf/arm_pmu.c                        |   5 +-
>  include/linux/perf/arm_pmu.h                  |   4 +-
>  8 files changed, 151 insertions(+), 48 deletions(-)
> 
> -- 
> 1.9.1


From linus.walleij at linaro.org  Thu Feb 11 05:28:58 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Feb 2016 14:28:58 +0100
Subject: [PATCH v2] pinctrl: sunxi: H3 requires irq_read_needs_mux
In-Reply-To: <CAGb2v65ZTBQZhFvesHPdwXDbwuVWcOQ+KUu82DWae6K8ycAxMA@mail.gmail.com>
References: <20160203075713.GA23312@box2.japko.eu>
 <CACRpkdbVtLYRku03bbnT=f7Ex1FoJqBv4Z6nY7pWkHy6wvHUfg@mail.gmail.com>
 <CAGb2v65ZTBQZhFvesHPdwXDbwuVWcOQ+KUu82DWae6K8ycAxMA@mail.gmail.com>
Message-ID: <CACRpkdZ3Spw3+bz1=ou-f4JurSvFWMbPPZBz3gA2BkTbMs4eaw@mail.gmail.com>

On Fri, Feb 5, 2016 at 2:51 PM, Chen-Yu Tsai <wens at csie.org> wrote:
> On Fri, Feb 5, 2016 at 9:39 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
>> On Wed, Feb 3, 2016 at 8:57 AM, Krzysztof Adamski <k at japko.eu> wrote:
>>
>>> It seems that on H3, just like on A10, when GPIOs are configured as
>>> external interrupt data registers does not contain their value.  When
>>> value is read, GPIO function must be temporary switched to input for
>>> reads.
>>>
>>> Signed-off-by: Krzysztof Adamski <k at japko.eu>
>>
>> 1. Waiting for Maxime's ACK on this patch.
>
> Maxime already acked v1.
>
> Acked-by: Chen-Yu Tsai <wens at csie.org>
>
>> 2. Is this a regression that need to go in to fixes?
>
> This driver was introduced in 4.5-rc1. It'd be nice if this fix could make
> it in 4.5. :)

OK ooops merged the v1 version, undoing and merging this version
instead.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Feb 11 05:30:57 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Feb 2016 14:30:57 +0100
Subject: [PATCH v4 5/5] pinctrl: sunxi: Use pin number when calling
 sunxi_pmx_set
In-Reply-To: <1455029929-18547-6-git-send-email-k@japko.eu>
References: <1455029929-18547-1-git-send-email-k@japko.eu>
 <1455029929-18547-6-git-send-email-k@japko.eu>
Message-ID: <CACRpkdbKVVxFs7aSE_2gRgtNSUJ0hsE++FATyD6uWcwxXvTjTw@mail.gmail.com>

On Tue, Feb 9, 2016 at 3:58 PM, Krzysztof Adamski
<krzysztof.adamski at tieto.com> wrote:

> sunxi_pmx_set accepts pin number and then calculates offset by
> subtracting pin_base from it. sunxi_pinctrl_gpio_get, on the other hand,
> gets offset so we have to convert it to pin number so we won't get
> negative value in sunxi_pmx_set.
>
> This was only used on A10 so far, where there is only one GPIO chip with
> pin_base set to 0 so it didn't matter. However H3 also requires this
> workaround but have two pinmux sections, triggering problem for PL port.
>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>
> Acked-by: Chen-Yu Tsai <wens at csie.org>
> Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

OK applied this version that has Maxime's ACK.

Yours,
Linus Walleij


From marc.zyngier at arm.com  Thu Feb 11 05:32:08 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 13:32:08 +0000
Subject: [PATCH v2 3/7] Documentation: bindings: document the Alpine MSIX
 driver
In-Reply-To: <1455110583-19515-4-git-send-email-antoine.tenart@free-electrons.com>
References: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
 <1455110583-19515-4-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <56BC8D58.8050005@arm.com>

On 10/02/16 13:22, Antoine Tenart wrote:
> Following the addition of the Alpine MSIX driver, this patch adds the
> corresponding bindings documentation.
> 
> Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
> Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
> ---
>  .../interrupt-controller/al,alpine-msix.txt        | 24 ++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
> 
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt b/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
> new file mode 100644
> index 000000000000..c7d3d0192f5d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
> @@ -0,0 +1,24 @@
> +Alpine MSIX controller
> +
> +Required properties:
> +
> +- compatible: should be "al,alpine-msix"
> +- reg: physical base address and size of the registers
> +- interrupt-parent: specifies the parent interrupt controller.
> +- interrupt-controller: identifies the node as an interrupt controller
> +- msi-controller: identifies the node as an PCI Message Signaled Interrupt
> +		  controller
> +- al,msi-base-spi: SPI base of the MSI frame
> +- al,msi-num-spis: number of SPIs assigned to the MSI frame

It would probably be good to reference the GIC bindings so that the
"SPI" acronym makes actual sense. It will also disambiguate the "base"
aspect (is this number relative to IRQ0? or SPI0? - I assume the latter,
but that's by looking at the code).

> +
> +Example:
> +
> +msix: msix {
> +	compatible = "al,alpine-msix";
> +	reg = <0x0 0xfbe00000 0x0 0x100000>;
> +	interrupt-parent = <&gic>;
> +	interrupt-controller;
> +	msi-controller;
> +	al,msi-base-spi = <160>;
> +	al,msi-num-spis = <160>;
> +};
> 

Otherwise looks good to me.

	M.
-- 
Jazz is not dead. It just smells funny...


From christoffer.dall at linaro.org  Thu Feb 11 05:34:01 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Thu, 11 Feb 2016 14:34:01 +0100
Subject: [PATCH] arm64: KVM: Configure TCR_EL2.PS at runtime
In-Reply-To: <20160211132708.GU5171@cbox>
References: <1455130013-28644-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160211132708.GU5171@cbox>
Message-ID: <20160211133401.GV5171@cbox>

On Thu, Feb 11, 2016 at 02:27:08PM +0100, Christoffer Dall wrote:
> On Wed, Feb 10, 2016 at 10:46:53AM -0800, tchalamarla at caviumnetworks.com wrote:
> > From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> > 
> > Setting TCR_EL2.PS to 40 bits is wrong on systems with PS size is
> > less than 40 bits. and with systems where RAM is at higher address,
> > this will break KVM.
> > 
> > This patch sets TCR_EL2.PS at runtime similar to VTCR_EL2.PS
> > 
> > changes form V2:
> > 	- Modified subject line and commit message.
> > 	- Removed TCR_EL2_FLAGS.
> > 
> > changes from V1:
> >         - Moved to dynamic configuration.
> > 
> > Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> > ---
> >  arch/arm64/include/asm/kvm_arm.h |  2 --
> >  arch/arm64/kvm/hyp-init.S        | 12 +++++++-----
> >  2 files changed, 7 insertions(+), 7 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> > index 738a95f..3776db0 100644
> > --- a/arch/arm64/include/asm/kvm_arm.h
> > +++ b/arch/arm64/include/asm/kvm_arm.h
> > @@ -107,8 +107,6 @@
> >  #define TCR_EL2_MASK	(TCR_EL2_TG0 | TCR_EL2_SH0 | \
> >  			 TCR_EL2_ORGN0 | TCR_EL2_IRGN0 | TCR_EL2_T0SZ)
> >  
> > -#define TCR_EL2_FLAGS	(TCR_EL2_RES1 | TCR_EL2_PS_40B)
> > -
> >  /* VTCR_EL2 Registers bits */
> >  #define VTCR_EL2_RES1		(1 << 31)
> >  #define VTCR_EL2_PS_MASK	(7 << 16)
> > diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
> > index 3e568dc..b5ab1b0 100644
> > --- a/arch/arm64/kvm/hyp-init.S
> > +++ b/arch/arm64/kvm/hyp-init.S
> > @@ -64,7 +64,7 @@ __do_hyp_init:
> >  	mrs	x4, tcr_el1
> >  	ldr	x5, =TCR_EL2_MASK
> >  	and	x4, x4, x5
> > -	ldr	x5, =TCR_EL2_FLAGS
> > +	ldr	x5, =TCR_EL2_RES1
> >  	orr	x4, x4, x5
> >  
> >  #ifndef CONFIG_ARM64_VA_BITS_48
> > @@ -85,15 +85,17 @@ __do_hyp_init:
> >  	ldr_l	x5, idmap_t0sz
> >  	bfi	x4, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH
> >  #endif
> > -	msr	tcr_el2, x4
> > -
> > -	ldr	x4, =VTCR_EL2_FLAGS
> >  	/*
> >  	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
> > -	 * VTCR_EL2.
> > +	 * TCR_EL2 and VTCR_EL2.
> >  	 */
> >  	mrs	x5, ID_AA64MMFR0_EL1
> >  	bfi	x4, x5, #16, #3
> > +
> > +	msr	tcr_el2, x4
> > +
> > +	ldr	x4, =VTCR_EL2_FLAGS
> > +	bfi	x4, x5, #16, #3
> >  	/*
> >  	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS bit in
> >  	 * VTCR_EL2.
> > -- 
> > 2.1.0
> > 
> 
> This looks reasonable enough for me.  Did we limit Linux to PS=40 bits
> in the past and have lifted this restriction, or why did we have this
> limitation for EL2 translations in the past?
> 
Hmm, just went back and looked at my comments [1] on Suzuki's 16K page
series, and regarding our stage-2 page table configuration I wrote this:

<quote>
... the constraints of
this whole thing is, and make sure we agree on this:

1. We fix the IPA max width to 40 bits
2. We don't support systems with a PARange smaller than 40 bits (do we
   check this anywhere or document this anywhere?)
   3. We always assume we are running on a system with PARange of 40
   bits
      and we are therefore constrained to use concatination.
</quote>

So this change is actually making a bit nervous...  Marc, did you check
if all the stuff in arch/arm64/include/asm/kvm_mmu.h still holds after
we relax this?

Thanks,
-Christoffer

[1]: https://lkml.org/lkml/2015/10/10/96


From will.deacon at arm.com  Thu Feb 11 05:35:16 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 11 Feb 2016 13:35:16 +0000
Subject: [PATCH] arm64: mm: keep gcc and sparse happy when !CONFIG_DEBUG_RODATA
Message-ID: <1455197716-28665-1-git-send-email-will.deacon@arm.com>

init/main.c defines an empty static inline mark_rodata_ro #ifndef
CONFIG_DEBUG_RODATA, which clashes with the unconditional definition
in the arm64 backend, which has an IS_ENABLED check in the code.

Whilst this doesn't cause any problems in practice (the static inline
version is used in preference and the out-of-line version has no
prototype), GCC moans with:

  warning: no previous prototype for ?mark_rodata_ro? [-Wmissing-prototypes]

and sparse with:

  warning: symbol 'mark_rodata_ro' was not declared. Should it be static? [sparse]

so keep them happy by replacing the IS_ENABLED check with an #ifdef
around the function instead.

Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm64/mm/mmu.c | 29 ++++++++++++++---------------
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index c3e5df62671e..4a330018ce8f 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -372,19 +372,6 @@ void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
 			     late_pgtable_alloc);
 }
 
-static void create_mapping_late(phys_addr_t phys, unsigned long virt,
-				  phys_addr_t size, pgprot_t prot)
-{
-	if (virt < VMALLOC_START) {
-		pr_warn("BUG: not creating mapping for %pa at 0x%016lx - outside kernel range\n",
-			&phys, virt);
-		return;
-	}
-
-	__create_pgd_mapping(init_mm.pgd, phys, virt, size, prot,
-			     late_pgtable_alloc);
-}
-
 static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end)
 {
 
@@ -438,15 +425,27 @@ static void __init map_mem(pgd_t *pgd)
 	}
 }
 
-void mark_rodata_ro(void)
+#ifdef CONFIG_DEBUG_RODATA
+static void create_mapping_late(phys_addr_t phys, unsigned long virt,
+				  phys_addr_t size, pgprot_t prot)
 {
-	if (!IS_ENABLED(CONFIG_DEBUG_RODATA))
+	if (virt < VMALLOC_START) {
+		pr_warn("BUG: not creating mapping for %pa at 0x%016lx - outside kernel range\n",
+			&phys, virt);
 		return;
+	}
 
+	__create_pgd_mapping(init_mm.pgd, phys, virt, size, prot,
+			     late_pgtable_alloc);
+}
+
+void mark_rodata_ro(void)
+{
 	create_mapping_late(__pa(_stext), (unsigned long)_stext,
 				(unsigned long)_etext - (unsigned long)_stext,
 				PAGE_KERNEL_ROX);
 }
+#endif
 
 void fixup_init(void)
 {
-- 
2.1.4



From ashoks at broadcom.com  Thu Feb 11 05:38:53 2016
From: ashoks at broadcom.com (Ashok Kumar)
Date: Thu, 11 Feb 2016 05:38:53 -0800
Subject: [PATCH] irqchip/gic-v3-its: Fix double EOIR write for LPI in
 EOImode==1
Message-ID: <1455197933-26141-1-git-send-email-ashoks@broadcom.com>

CPU receives SError exception EOI1_NO_INTS_ACTIVE when EOIR
is written twice in gic_handle_irq and in its_eoi_irq for a
single LPI in EOImode == 1.

Now irq_eoi of its_irq_chip calls parent irqchip's(gic_eoimode1_chip/gic_chip)
irq_eoi handler which handles EOImode 0 and 1 separately.

This is introduced by
commit 0b996fd35957a ("irqchip/GICv3: Convert to EOImode == 1")

Signed-off-by: Ashok Kumar <ashoks at broadcom.com>
---
 drivers/irqchip/irq-gic-v3-its.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index e23d1d1..a159529f 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -597,11 +597,6 @@ static void its_unmask_irq(struct irq_data *d)
 	lpi_set_config(d, true);
 }
 
-static void its_eoi_irq(struct irq_data *d)
-{
-	gic_write_eoir(d->hwirq);
-}
-
 static int its_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
 			    bool force)
 {
@@ -638,7 +633,7 @@ static struct irq_chip its_irq_chip = {
 	.name			= "ITS",
 	.irq_mask		= its_mask_irq,
 	.irq_unmask		= its_unmask_irq,
-	.irq_eoi		= its_eoi_irq,
+	.irq_eoi		= irq_chip_eoi_parent,
 	.irq_set_affinity	= its_set_affinity,
 	.irq_compose_msi_msg	= its_irq_compose_msi_msg,
 };
-- 
2.1.0



From marc.zyngier at arm.com  Thu Feb 11 05:41:48 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 13:41:48 +0000
Subject: [PATCH v2 0/7] irqchip: introduce the Alpine MSIX driver
In-Reply-To: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <56BC8F9C.3060505@arm.com>

Antoine,

On 10/02/16 13:22, Antoine Tenart wrote:
> Hi all,
> 
> This series introduce the Alpine MSIX driver, and enables it in both
> the Alpine v1 and Alpine v2 device trees.
> 
> This series depends on "[PATCH v2 0/3] arm64: introduce the Alpine support":
> https://lkml.org/lkml/2016/2/10/83
> 
> You can find the series at:
> https://github.com/atenart/linux.git 4.5-rc1/alpinev2-msix

So I'm quite happy with this as it is (modulo the documentation fix on
patch 3). I can take the first 3 patches through my GIC tree, but the
last 4 patches depend on your other series.

Would it be a problem to get these 4 patches merged after 4.6-rc1, so
that all the code can be merged before?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From will.deacon at arm.com  Thu Feb 11 05:47:03 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 11 Feb 2016 13:47:03 +0000
Subject: [PATCH] arm64: vdso: Mark vDSO code as read-only
In-Reply-To: <1455141142-6838-1-git-send-email-david.brown@linaro.org>
References: <1455141142-6838-1-git-send-email-david.brown@linaro.org>
Message-ID: <20160211134702.GE32084@arm.com>

On Wed, Feb 10, 2016 at 01:52:22PM -0800, David Brown wrote:
> Although the arm64 vDSO is cleanly separated by code/data with the
> code being read-only in userspace mappings, the code page is still
> writable from the kernel.  There have been exploits (such as
> http://itszn.com/blog/?p=21) that take advantage of this on x86 to go
> from a bad kernel write to full root.
> 
> Prevent this specific exploit on arm64 by putting the vDSO code page
> in read-only memory as well.
> 
> Before the change:
> [    3.138366] vdso: 2 pages (1 code @ ffffffc000a71000, 1 data @ ffffffc000a70000)
> ---[ Kernel Mapping ]---
> 0xffffffc000000000-0xffffffc000082000         520K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc000082000-0xffffffc000200000        1528K     ro x  SHD AF            UXN MEM/NORMAL
> 0xffffffc000200000-0xffffffc000800000           6M     ro x  SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc000800000-0xffffffc0009b6000        1752K     ro x  SHD AF            UXN MEM/NORMAL
> 0xffffffc0009b6000-0xffffffc000c00000        2344K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc000c00000-0xffffffc008000000         116M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc00c000000-0xffffffc07f000000        1840M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc800000000-0xffffffc840000000           1G     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc840000000-0xffffffc87ae00000         942M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc87ae00000-0xffffffc87ae70000         448K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87af80000-0xffffffc87af8a000          40K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87af8b000-0xffffffc87b000000         468K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87b000000-0xffffffc87fe00000          78M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc87fe00000-0xffffffc87ff50000        1344K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87ff90000-0xffffffc87ffa0000          64K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87fff0000-0xffffffc880000000          64K     RW NX SHD AF            UXN MEM/NORMAL
> 
> After:
> [    3.138368] vdso: 2 pages (1 code @ ffffffc0006de000, 1 data @ ffffffc000a74000)
> ---[ Kernel Mapping ]---
> 0xffffffc000000000-0xffffffc000082000         520K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc000082000-0xffffffc000200000        1528K     ro x  SHD AF            UXN MEM/NORMAL
> 0xffffffc000200000-0xffffffc000800000           6M     ro x  SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc000800000-0xffffffc0009b8000        1760K     ro x  SHD AF            UXN MEM/NORMAL
> 0xffffffc0009b8000-0xffffffc000c00000        2336K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc000c00000-0xffffffc008000000         116M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc00c000000-0xffffffc07f000000        1840M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc800000000-0xffffffc840000000           1G     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc840000000-0xffffffc87ae00000         942M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc87ae00000-0xffffffc87ae70000         448K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87af80000-0xffffffc87af8a000          40K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87af8b000-0xffffffc87b000000         468K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87b000000-0xffffffc87fe00000          78M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc87fe00000-0xffffffc87ff50000        1344K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87ff90000-0xffffffc87ffa0000          64K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87fff0000-0xffffffc880000000          64K     RW NX SHD AF            UXN MEM/NORMAL
> 
> Inspired by https://lkml.org/lkml/2016/1/19/494 based on work by the
> PaX Team, Brad Spengler, and Kees Cook.
> 
> Signed-off-by: David Brown <david.brown at linaro.org>
> ---
>  arch/arm64/kernel/vdso/vdso.S | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/kernel/vdso/vdso.S b/arch/arm64/kernel/vdso/vdso.S
> index 60c1db5..db7c0f2 100644
> --- a/arch/arm64/kernel/vdso/vdso.S
> +++ b/arch/arm64/kernel/vdso/vdso.S
> @@ -24,6 +24,7 @@
>  	__PAGE_ALIGNED_DATA
>  
>  	.globl vdso_start, vdso_end
> +	.section .rodata
>  	.balign PAGE_SIZE
>  vdso_start:
>  	.incbin "arch/arm64/kernel/vdso/vdso.so"

Nice, I wish I'd thought of that!

Acked-by: Will Deacon <will.deacon at arm.com>

As an aside, I wonder whether we should be printing the code/data
addresses out in dmesg at all.

Will


From linus.walleij at linaro.org  Thu Feb 11 05:47:57 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Feb 2016 14:47:57 +0100
Subject: [PATCH 01/14] pinctrl: sunxi: Add A83T R_PIO controller support
In-Reply-To: <20160211123648.GN31506@lukather>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-2-git-send-email-vishnupatekar0510@gmail.com>
 <CACRpkdbCgOBQw28d=qc1fAURY3x8UdoWqiMtXMZ=uWLaQj-nbg@mail.gmail.com>
 <20160211123648.GN31506@lukather>
Message-ID: <CACRpkdaGZ4-S1A9zUUaBXXEazyJf_uZ4ESiBhw-CpozXMxfDHg@mail.gmail.com>

On Thu, Feb 11, 2016 at 1:36 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> On Thu, Feb 11, 2016 at 12:59:47PM +0100, Linus Walleij wrote:
>> On Sun, Jan 31, 2016 at 2:20 AM, Vishnu Patekar
>> <vishnupatekar0510 at gmail.com> wrote:
>>
>> > The A83T has R_PIO pin controller, it's same as A23, execpt A83T
>> > interrupt bit is 6th and A83T has one extra pin PL12.
>> >
>> > Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
>>
>> Maxime, can you look at this patch?
>
> Chen-Yu had one minor comment on it,

OK waiting for a new version.

> and he's also the Allwinner
> maintainer now, so you can trust his Acked-by just like you would
> trust mine ;)

Can you guys supply a MAINTAINERS entry for the sunxi
stuff?

Yours,
Linus Walleij


From arnd at arndb.de  Thu Feb 11 05:49:43 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 14:49:43 +0100
Subject: [PATCH 1/2] serial: 8250: fix building mediatek with SERIAL_8250=m
In-Reply-To: <20160208165535.GZ23093@windriver.com>
References: <1454935947-2743255-1-git-send-email-arnd@arndb.de>
 <20160208165535.GZ23093@windriver.com>
Message-ID: <4992215.sKvb0IIruL@wuerfel>

On Monday 08 February 2016 11:55:35 Paul Gortmaker wrote:
> > drivers/tty/built-in.o: In function `mtk8250_set_termios':
> > 8250_ingenic.c:(.text+0x1bee8): undefined reference to `serial8250_do_set_termios'
> > 8250_ingenic.c:(.text+0x1bf10): undefined reference to `uart_get_baud_rate'
> > 8250_ingenic.c:(.text+0x1c09c): undefined reference to `uart_get_divisor'
> > drivers/tty/built-in.o: In function `mtk8250_do_pm':
> > 8250_ingenic.c:(.text+0x1c0d0): undefined reference to `serial8250_do_pm'
> > drivers/tty/built-in.o: In function `mtk8250_probe':
> > 8250_ingenic.c:(.text+0x1c2e4): undefined reference to `serial8250_register_8250_port'
> > serial/8250/8250_mtk.c:287:242: error: data definition has no type or storage class [-Werror]
> > serial/8250/8250_mtk.c:287:122: error: 'mtk8250_platform_driver_init' defined but not used [-Werror=unused-function]
> 
> Probably should drop the ingenic lines above ; assuming they are make -j N
> related and that mtk doesn't depend on or build ingenic.

I looked at these again and noticed that this is just being misreported
by the linker. I don't know exactly what happens here but I see it a lot:
the function names ("mtk8250_set_termios") are all correct, but the file
names ("8250_ingenic.c") are wrong. I normally edit out the file names
manually but forgot that here. I'll fix it up when resending.

	Arnd


From linus.walleij at linaro.org  Thu Feb 11 05:50:43 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Feb 2016 14:50:43 +0100
Subject: [linux-sunxi] Re: [PATCH v2 5/5] pinctrl: sunxi: Use pin number
 when calling sunxi_pmx_set
In-Reply-To: <20160211132054.GC19622@box2.japko.eu>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
 <1454448113-18810-6-git-send-email-k@japko.eu>
 <CACRpkdbc0SfKiCGwUGA2fAPPsUhGv=qGV607Lht6ByYKKgTHjA@mail.gmail.com>
 <20160211132054.GC19622@box2.japko.eu>
Message-ID: <CACRpkdZ889rktgaR3o--9cSsouORocV8TeBRGVkiwHpK3VNSGw@mail.gmail.com>

On Thu, Feb 11, 2016 at 2:20 PM, Krzysztof Adamski <k at japko.eu> wrote:
> On Thu, Feb 11, 2016 at 02:17:41PM +0100, Linus Walleij wrote:
>>
>> On Tue, Feb 2, 2016 at 10:21 PM, Krzysztof Adamski <k at japko.eu> wrote:
>>
>>> sunxi_pmx_set accepts pin number and then calculates offset by
>>> subtracting pin_base from it. sunxi_pinctrl_gpio_get, on the other hand,
>>> gets offset so we have to convert it to pin number so we won't get
>>> negative value in sunxi_pmx_set.
>>>
>>> This was only used on A10 so far, where there is only one GPIO chip with
>>> pin_base set to 0 so it didn't matter. However H3 also requires this
>>> workaround but have two pinmux sections, triggering problem for PL port.
>>>
>>> Signed-off-by: Krzysztof Adamski <k at japko.eu>
>>
>>
>> Waiting for Maxime to review this. I guess this patch can be merged
>> independently of the other patches?
>
> Yes it can but it won't have any effect, as stated in the commit message,
> since other SoCs either don't use this flag or have only one port so theri
> pin_base=0.

Who cares as long as it will be used eventually.

Merged v4 as stated earlier.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Feb 11 05:52:42 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 11 Feb 2016 14:52:42 +0100
Subject: [PATCH v3 2/2] dt-bindings: rockchip-pinctrl: Support the RK3399
 SoCs compatible
In-Reply-To: <14543443.RsRWh5K5Uv@phil>
References: <1451997055-47655-1-git-send-email-wdc@rock-chips.com>
 <1454153517-52969-1-git-send-email-david.wu@rock-chips.com>
 <1454153517-52969-3-git-send-email-david.wu@rock-chips.com>
 <14543443.RsRWh5K5Uv@phil>
Message-ID: <CACRpkdZvS2RY2LqFQ1dMz8vecMgG7zmxw8JEj5KLTiqYCSsJ=w@mail.gmail.com>

On Sat, Jan 30, 2016 at 1:16 PM, Heiko Stuebner <heiko at sntech.de> wrote:
> Hi David,
>
> Am Samstag, 30. Januar 2016, 19:31:57 schrieb David Wu:
>> Change-Id: Ic1bdb3dc358837e97d7b48dd58be2f8d9d08d766
>
> please no Change-Id, it's missing the Signed-off, and as Linus Walleij said,
> the compatible addition to the documentation can maybe stay in the pinctrl-
> patch itself.
>
> I think both Linus and me overlooked that the binding-doc-addition was
> already correctly included in your v2 patch at the top :-)

Yeah I merged that now anyways so the string is there.

Yours,
Linus Walleij


From will.deacon at arm.com  Thu Feb 11 05:54:36 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 11 Feb 2016 13:54:36 +0000
Subject: [PATCH] arm64: reenable interrupt when handling ptrace breakpoint
In-Reply-To: <56B5135B.3050801@linaro.org>
References: <5671CD5B.9030907@linaro.org> <20151221104818.GF23092@arm.com>
 <alpine.DEB.2.11.1512211749180.28591@nanos>
 <20151221170028.GT23092@arm.com> <56955B3A.5010303@linaro.org>
 <20160113102622.GC25458@arm.com> <569686BA.6050703@linaro.org>
 <20160113172303.GH25458@arm.com> <56969312.7070309@linaro.org>
 <56B5135B.3050801@linaro.org>
Message-ID: <20160211135435.GG32084@arm.com>

On Fri, Feb 05, 2016 at 01:25:47PM -0800, Shi, Yang wrote:
> On 1/13/2016 10:10 AM, Shi, Yang wrote:
> >On 1/13/2016 9:23 AM, Will Deacon wrote:
> >>On Wed, Jan 13, 2016 at 09:17:46AM -0800, Shi, Yang wrote:
> >>>On 1/13/2016 2:26 AM, Will Deacon wrote:
> >>>>On Tue, Jan 12, 2016 at 11:59:54AM -0800, Shi, Yang wrote:
> >>>>>This might be buried in email storm during the holiday. Just want
> >>>>>to double
> >>>>>check the status. I'm supposed there is no objection for getting it
> >>>>>merged
> >>>>>in upstream?
> >>>>
> >>>>Sorry, when you replied with:
> >>>>
> >>>>>I think we could just extend the "signal delay send" approach from
> >>>>>x86-64
> >>>>>to arm64, which is currently used by x86-64 on -rt kernel only.
> >>>>
> >>>>I understood that you were going to fix -rt, so I dropped this pending
> >>>>anything more from you.
> >>>>
> >>>>What's the plan?
> >>>
> >>>Sorry for the confusion. The "signal delay send" approach used by
> >>>x86-64 -rt
> >>>should be not necessary for arm64 right now. Reenabling interrupt is
> >>>still
> >>>the preferred approach.
> >>>
> >>>Since x86-64 has per-CPU IST exception stack, so preemption has to be
> >>>disabled all the time. However, it is not applicable to other
> >>>architectures
> >>>for now, including arm64.
> >>
> >>Actually, we grew support for a separate IRQ stack in the recent merge
> >>window. Does that change things here, or are you referring to something
> >>else?
> >
> >Had a quick look at the patches, it looks the irq stack is not nestable
> >and it switches back to the original stack as long as irq handler is
> >done before preempt happens. So, it sounds it won't change things here.
> 
> 
> Just had a quick test on 4.5-rc1. It survives with kgdbts, ptrace and ltp.
> So, it sounds safe with the "separate IRQ stack" change.

I quite liked the sigtrap consolidation in my earlier (broken) approach.
Does the following work for you?

Will

--->8

>From e04a28d45ff343b47a4ffc4dee3a3e279e76ddfa Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon at arm.com>
Date: Wed, 10 Feb 2016 16:05:28 +0000
Subject: [PATCH] arm64: debug: re-enable irqs before sending breakpoint
 SIGTRAP

force_sig_info can sleep under an -rt kernel, so attempting to send a
breakpoint SIGTRAP with interrupts disabled yields the following BUG:

  BUG: sleeping function called from invalid context at
  /kernel-source/kernel/locking/rtmutex.c:917
  in_atomic(): 0, irqs_disabled(): 128, pid: 551, name: test.sh
  CPU: 5 PID: 551 Comm: test.sh Not tainted 4.1.13-rt13 #7
  Hardware name: Freescale Layerscape 2085a RDB Board (DT)
  Call trace:
	 dump_backtrace+0x0/0x128
	 show_stack+0x24/0x30
	 dump_stack+0x80/0xa0
	 ___might_sleep+0x128/0x1a0
	 rt_spin_lock+0x2c/0x40
	 force_sig_info+0xcc/0x210
	 brk_handler.part.2+0x6c/0x80
	 brk_handler+0xd8/0xe8
	 do_debug_exception+0x58/0xb8

This patch fixes the problem by ensuring that interrupts are enabled
prior to sending the SIGTRAP if they were already enabled in the user
context.

Reported-by: Yang Shi <yang.shi at linaro.org>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 arch/arm64/kernel/debug-monitors.c | 48 +++++++++++++++++---------------------
 1 file changed, 22 insertions(+), 26 deletions(-)

diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index 8aee3aeec3e6..c536c9e307b9 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -226,11 +226,28 @@ static int call_step_hook(struct pt_regs *regs, unsigned int esr)
 	return retval;
 }
 
+static void send_user_sigtrap(int si_code)
+{
+	struct pt_regs *regs = current_pt_regs();
+	siginfo_t info = {
+		.si_signo	= SIGTRAP,
+		.si_errno	= 0,
+		.si_code	= si_code,
+		.si_addr	= (void __user *)instruction_pointer(regs),
+	};
+
+	if (WARN_ON(!user_mode(regs)))
+		return;
+
+	if (interrupts_enabled(regs))
+		local_irq_enable();
+
+	force_sig_info(SIGTRAP, &info, current);
+}
+
 static int single_step_handler(unsigned long addr, unsigned int esr,
 			       struct pt_regs *regs)
 {
-	siginfo_t info;
-
 	/*
 	 * If we are stepping a pending breakpoint, call the hw_breakpoint
 	 * handler first.
@@ -239,11 +256,7 @@ static int single_step_handler(unsigned long addr, unsigned int esr,
 		return 0;
 
 	if (user_mode(regs)) {
-		info.si_signo = SIGTRAP;
-		info.si_errno = 0;
-		info.si_code  = TRAP_HWBKPT;
-		info.si_addr  = (void __user *)instruction_pointer(regs);
-		force_sig_info(SIGTRAP, &info, current);
+		send_user_sigtrap(TRAP_HWBKPT);
 
 		/*
 		 * ptrace will disable single step unless explicitly
@@ -307,17 +320,8 @@ static int call_break_hook(struct pt_regs *regs, unsigned int esr)
 static int brk_handler(unsigned long addr, unsigned int esr,
 		       struct pt_regs *regs)
 {
-	siginfo_t info;
-
 	if (user_mode(regs)) {
-		info = (siginfo_t) {
-			.si_signo = SIGTRAP,
-			.si_errno = 0,
-			.si_code  = TRAP_BRKPT,
-			.si_addr  = (void __user *)instruction_pointer(regs),
-		};
-
-		force_sig_info(SIGTRAP, &info, current);
+		send_user_sigtrap(TRAP_BRKPT);
 	} else if (call_break_hook(regs, esr) != DBG_HOOK_HANDLED) {
 		pr_warning("Unexpected kernel BRK exception at EL1\n");
 		return -EFAULT;
@@ -328,7 +332,6 @@ static int brk_handler(unsigned long addr, unsigned int esr,
 
 int aarch32_break_handler(struct pt_regs *regs)
 {
-	siginfo_t info;
 	u32 arm_instr;
 	u16 thumb_instr;
 	bool bp = false;
@@ -359,14 +362,7 @@ int aarch32_break_handler(struct pt_regs *regs)
 	if (!bp)
 		return -EFAULT;
 
-	info = (siginfo_t) {
-		.si_signo = SIGTRAP,
-		.si_errno = 0,
-		.si_code  = TRAP_BRKPT,
-		.si_addr  = pc,
-	};
-
-	force_sig_info(SIGTRAP, &info, current);
+	send_user_sigtrap(TRAP_BRKPT);
 	return 0;
 }
 
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 05:55:13 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 13:55:13 +0000
Subject: [PATCH] arm64: KVM: Configure TCR_EL2.PS at runtime
In-Reply-To: <20160211133401.GV5171@cbox>
References: <1455130013-28644-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160211132708.GU5171@cbox> <20160211133401.GV5171@cbox>
Message-ID: <56BC92C1.8060201@arm.com>

On 11/02/16 13:34, Christoffer Dall wrote:
> On Thu, Feb 11, 2016 at 02:27:08PM +0100, Christoffer Dall wrote:
>> On Wed, Feb 10, 2016 at 10:46:53AM -0800, tchalamarla at caviumnetworks.com wrote:
>>> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>>>
>>> Setting TCR_EL2.PS to 40 bits is wrong on systems with PS size is
>>> less than 40 bits. and with systems where RAM is at higher address,
>>> this will break KVM.
>>>
>>> This patch sets TCR_EL2.PS at runtime similar to VTCR_EL2.PS
>>>
>>> changes form V2:
>>> 	- Modified subject line and commit message.
>>> 	- Removed TCR_EL2_FLAGS.
>>>
>>> changes from V1:
>>>         - Moved to dynamic configuration.
>>>
>>> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>>> ---
>>>  arch/arm64/include/asm/kvm_arm.h |  2 --
>>>  arch/arm64/kvm/hyp-init.S        | 12 +++++++-----
>>>  2 files changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
>>> index 738a95f..3776db0 100644
>>> --- a/arch/arm64/include/asm/kvm_arm.h
>>> +++ b/arch/arm64/include/asm/kvm_arm.h
>>> @@ -107,8 +107,6 @@
>>>  #define TCR_EL2_MASK	(TCR_EL2_TG0 | TCR_EL2_SH0 | \
>>>  			 TCR_EL2_ORGN0 | TCR_EL2_IRGN0 | TCR_EL2_T0SZ)
>>>  
>>> -#define TCR_EL2_FLAGS	(TCR_EL2_RES1 | TCR_EL2_PS_40B)
>>> -
>>>  /* VTCR_EL2 Registers bits */
>>>  #define VTCR_EL2_RES1		(1 << 31)
>>>  #define VTCR_EL2_PS_MASK	(7 << 16)
>>> diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
>>> index 3e568dc..b5ab1b0 100644
>>> --- a/arch/arm64/kvm/hyp-init.S
>>> +++ b/arch/arm64/kvm/hyp-init.S
>>> @@ -64,7 +64,7 @@ __do_hyp_init:
>>>  	mrs	x4, tcr_el1
>>>  	ldr	x5, =TCR_EL2_MASK
>>>  	and	x4, x4, x5
>>> -	ldr	x5, =TCR_EL2_FLAGS
>>> +	ldr	x5, =TCR_EL2_RES1
>>>  	orr	x4, x4, x5
>>>  
>>>  #ifndef CONFIG_ARM64_VA_BITS_48
>>> @@ -85,15 +85,17 @@ __do_hyp_init:
>>>  	ldr_l	x5, idmap_t0sz
>>>  	bfi	x4, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH
>>>  #endif
>>> -	msr	tcr_el2, x4
>>> -
>>> -	ldr	x4, =VTCR_EL2_FLAGS
>>>  	/*
>>>  	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
>>> -	 * VTCR_EL2.
>>> +	 * TCR_EL2 and VTCR_EL2.
>>>  	 */
>>>  	mrs	x5, ID_AA64MMFR0_EL1
>>>  	bfi	x4, x5, #16, #3
>>> +
>>> +	msr	tcr_el2, x4
>>> +
>>> +	ldr	x4, =VTCR_EL2_FLAGS
>>> +	bfi	x4, x5, #16, #3
>>>  	/*
>>>  	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS bit in
>>>  	 * VTCR_EL2.
>>> -- 
>>> 2.1.0
>>>
>>
>> This looks reasonable enough for me.  Did we limit Linux to PS=40 bits
>> in the past and have lifted this restriction, or why did we have this
>> limitation for EL2 translations in the past?
>>
> Hmm, just went back and looked at my comments [1] on Suzuki's 16K page
> series, and regarding our stage-2 page table configuration I wrote this:
> 
> <quote>
> ... the constraints of
> this whole thing is, and make sure we agree on this:
> 
> 1. We fix the IPA max width to 40 bits
> 2. We don't support systems with a PARange smaller than 40 bits (do we
>    check this anywhere or document this anywhere?)
>    3. We always assume we are running on a system with PARange of 40
>    bits
>       and we are therefore constrained to use concatination.
> </quote>
> 
> So this change is actually making a bit nervous...  Marc, did you check
> if all the stuff in arch/arm64/include/asm/kvm_mmu.h still holds after
> we relax this?

I believe this still works for the following reasons:

- This only affects the output address of EL2 Stage-1, and basically
only allows EL2 to reach the same memory as the rest of the host kernel.

- Stage-2 translation already does the same thing, for similar reasons.

- We enforce 40bit IPA by not providing page tables above 40 bits (by
setting T0SZ to 64-40=24). This has the effect of denying accesses above
40bit IPA to the guest.

So I'm quite confident that we're safe here.

Thoughts?

	M.
-- 
Jazz is not dead. It just smells funny...


From lars.persson at axis.com  Thu Feb 11 06:04:34 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 15:04:34 +0100
Subject: [PATCH v2 0/8] arm: Add Artpec-6 SoC
Message-ID: <cover.1455198819.git.larper@axis.com>

Basic support for the Axis Artpec-6 ARM SoC. Timers, interrupts, UARTs and
ethernet are wired up.

Changes since v1:
- Corrected bindings for axis,artpec6-pll1-clock.
- Moved the uart aliases to the board dts.
- Kconfig cleanup.
- Added a device tree binding for the dma configuration.
- Added CONFIG_SYNOPSYS_DWC_ETH_QOS to multi_v7_defconfig.
- Added binding documentation for axis,artpec6-dev-board.

Lars Persson (8):
  clk: add device tree binding for artpec-6 pll1 clock
  clk: add artpec-6 pll1 clock driver
  arm: add device-tree SoC bindings for Axis Artpec-6
  arm: dts: add Artpec-6 SoC dtsi file
  arm: dts: add Artpec-6 development board dts
  arm: initial machine port for artpec-6 SoC
  arm: multi_v7_defconfig: add MACH_ARTPEC6
  arm: mach-artpec: add entry to MAINTAINERS

 Documentation/devicetree/bindings/arm/axis.txt     |  29 +++
 .../devicetree/bindings/clock/artpec6.txt          |  16 ++
 MAINTAINERS                                        |  10 +
 arch/arm/Kconfig                                   |   2 +
 arch/arm/Makefile                                  |   1 +
 arch/arm/boot/dts/Makefile                         |   2 +
 arch/arm/boot/dts/artpec6-devboard.dts             |  64 ++++++
 arch/arm/boot/dts/artpec6.dtsi                     | 236 +++++++++++++++++++++
 arch/arm/configs/multi_v7_defconfig                |   3 +
 arch/arm/mach-artpec/Kconfig                       |  20 ++
 arch/arm/mach-artpec/Makefile                      |   1 +
 arch/arm/mach-artpec/board-artpec6.c               |  72 +++++++
 drivers/clk/Makefile                               |   1 +
 drivers/clk/clk-artpec6.c                          |  70 ++++++
 14 files changed, 527 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/axis.txt
 create mode 100644 Documentation/devicetree/bindings/clock/artpec6.txt
 create mode 100644 arch/arm/boot/dts/artpec6-devboard.dts
 create mode 100644 arch/arm/boot/dts/artpec6.dtsi
 create mode 100644 arch/arm/mach-artpec/Kconfig
 create mode 100644 arch/arm/mach-artpec/Makefile
 create mode 100644 arch/arm/mach-artpec/board-artpec6.c
 create mode 100644 drivers/clk/clk-artpec6.c

-- 
2.1.4



From lars.persson at axis.com  Thu Feb 11 06:04:39 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 15:04:39 +0100
Subject: [PATCH v2 5/8] arm: dts: add Artpec-6 development board dts
In-Reply-To: <cover.1455198819.git.larper@axis.com>
References: <cover.1455198819.git.larper@axis.com>
Message-ID: <7cb2fe1c0e188ae9eb478a8ec6ee6aa226491bc6.1455198819.git.larper@axis.com>

Signed-off-by: Lars Persson <larper at axis.com>
---
 arch/arm/boot/dts/Makefile             |  2 ++
 arch/arm/boot/dts/artpec6-devboard.dts | 64 ++++++++++++++++++++++++++++++++++
 2 files changed, 66 insertions(+)
 create mode 100644 arch/arm/boot/dts/artpec6-devboard.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..2ebe99c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -2,6 +2,8 @@ ifeq ($(CONFIG_OF),y)
 
 dtb-$(CONFIG_ARCH_ALPINE) += \
 	alpine-db.dtb
+dtb-$(CONFIG_MACH_ARTPEC6) += \
+	artpec6-devboard.dtb
 dtb-$(CONFIG_MACH_ASM9260) += \
 	alphascale-asm9260-devkit.dtb
 # Keep at91 dtb files sorted alphabetically for each SoC
diff --git a/arch/arm/boot/dts/artpec6-devboard.dts b/arch/arm/boot/dts/artpec6-devboard.dts
new file mode 100644
index 0000000..f823ed3
--- /dev/null
+++ b/arch/arm/boot/dts/artpec6-devboard.dts
@@ -0,0 +1,64 @@
+/*
+ * Axis ARTPEC-6 development board.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "artpec6.dtsi"
+
+/ {
+	model = "ARTPEC-6 development board";
+	compatible = "axis,artpec6-dev-board", "axis,artpec6";
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+	};
+
+	chosen {
+		stdout-path = "serial3:115200n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x0 0x10000000>;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart1 {
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&uart3 {
+	status = "okay";
+};
+
+&ethernet {
+	status = "okay";
+
+	phy-handle = <&phy1>;
+	phy-mode = "gmii";
+
+	mdio {
+		#address-cells = <0x1>;
+		#size-cells = <0x0>;
+		phy1: phy at 0 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			device_type = "ethernet-phy";
+			reg = <0x0>;
+		};
+	};
+};
-- 
2.1.4



From tn at semihalf.com  Thu Feb 11 06:02:51 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu, 11 Feb 2016 15:02:51 +0100
Subject: [PATCH V3 00/10] Introduce ACPI world to GICv3 & ITS irqchip
In-Reply-To: <56BC74CA.3020003@arm.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
 <56BC74CA.3020003@arm.com>
Message-ID: <56BC948B.6030206@semihalf.com>

On 11.02.2016 12:47, Marc Zyngier wrote:
> Thomas, Hanjun,
>
> On 19/01/16 13:11, Tomasz Nowicki wrote:
>> Patches base on Suravee's ACPI GICv2m support:
>> https://lkml.org/lkml/2015/12/10/475
>>
>> The following git branch contains submitted patches along with
>> the useful patches from the test point of view (mainly ACPI ARM64 PCI support).
>> https://github.com/semihalf-nowicki-tomasz/linux.git (gicv3-its-acpi-v3)
>>
>> Series has been tested on Cavium ThunderX server.
>>
>> v2 -> v3
>> - rebased on top of 4.4
>> - fixes and improvements for redistributor init via GICC structures
>> - fixes as per kbuild reports
>>
>> v1 -> v2
>> - rebased on top of 4.4-rc4
>> - use pci_msi_domain_get_msi_rid for requester ID to device ID translation
>>
>> Hanjun Guo (1):
>>    irqchip / GICv3: remove gic root node in ITS
>>
>> Tomasz Nowicki (9):
>>    irqchip / GICv3: Refactor gic_of_init() for GICv3 driver
>>    irqchip / GICv3: Add ACPI support for GICv3+ initialization
>>    irqchip,GICv3,ACPI: Add redistributor support via GICC structures.
>>    irqchip, gicv3, its: Mark its_init() and its children as __init
>>    irqchip, GICv3, ITS: Refator ITS dt init code to prepare for ACPI.
>>    ARM64, ACPI, PCI: I/O Remapping Table (IORT) initial support.
>>    irqchip, gicv3, its: Probe ITS in the ACPI way.
>>    acpi, gicv3, msi: Factor out code that might be reused for ACPI
>>      equivalent.
>>    acpi, gicv3, its: Use MADT ITS subtable to do PCI/MSI domain
>>      initialization.
>>
>>   drivers/acpi/Kconfig                     |   3 +
>>   drivers/acpi/Makefile                    |   1 +
>>   drivers/acpi/iort.c                      | 326 +++++++++++++++++++++++++++++
>>   drivers/irqchip/Kconfig                  |   1 +
>>   drivers/irqchip/irq-gic-v3-its-pci-msi.c |  85 ++++++--
>>   drivers/irqchip/irq-gic-v3-its.c         | 143 +++++++++----
>>   drivers/irqchip/irq-gic-v3.c             | 344 ++++++++++++++++++++++++++-----
>>   drivers/pci/msi.c                        |   3 +
>>   include/linux/iort.h                     |  38 ++++
>>   include/linux/irqchip/arm-gic-v3.h       |   2 +-
>>   10 files changed, 845 insertions(+), 101 deletions(-)
>>   create mode 100644 drivers/acpi/iort.c
>>   create mode 100644 include/linux/iort.h
>>
>
> I've so far queued the first 5 patches of this series (basic ACPI
> support for GICv3 and associated cleanups). The rest needs additional
> discussion (see my comments on patch 10), and requires some form of Ack
> from the ACPI maintainers (at least for patch 7).
>
Thanks Marc!

I will respond to the rest of your comments shortly.

Tomasz


From lars.persson at axis.com  Thu Feb 11 06:04:37 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 15:04:37 +0100
Subject: [PATCH v2 3/8] arm: add device-tree SoC bindings for Axis Artpec-6
In-Reply-To: <cover.1455198819.git.larper@axis.com>
References: <cover.1455198819.git.larper@axis.com>
Message-ID: <0f096d1ad277cf94032ca274ced0cb35cb5d967c.1455198819.git.larper@axis.com>

This adds device tree bindings for the Artpec-6 SoC.

Signed-off-by: Lars Persson <larper at axis.com>
---
 Documentation/devicetree/bindings/arm/axis.txt | 29 ++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/axis.txt

diff --git a/Documentation/devicetree/bindings/arm/axis.txt b/Documentation/devicetree/bindings/arm/axis.txt
new file mode 100644
index 0000000..203a305
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/axis.txt
@@ -0,0 +1,29 @@
+Axis Communications AB
+ARTPEC series SoC Device Tree Bindings
+
+ARTPEC-6 ARM SoC
+================
+
+Required root node properties:
+- compatible = "axis,artpec6";
+
+ARTPEC-6 DMA Configuration
+--------------------------
+
+The DMA configuration unit muxes dma request lines between single and burst
+alternatives.
+
+Required properties:
+- compatible: axis,artpec6-dmacfg
+- reg: Address and length of DMACFG register.
+
+Example:
+	dmacfg {
+		compatible = "axis,artpec6-dmacfg";
+		reg = <0xf8000010 4>;
+	};
+
+ARTPEC-6 Development board:
+---------------------------
+Required root node properties:
+- compatible = "axis,artpec6-dev-board", "axis,artpec6";
-- 
2.1.4



From lars.persson at axis.com  Thu Feb 11 06:04:35 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 15:04:35 +0100
Subject: [PATCH v2 1/8] clk: add device tree binding for artpec-6 pll1 clock
In-Reply-To: <cover.1455198819.git.larper@axis.com>
References: <cover.1455198819.git.larper@axis.com>
Message-ID: <2686b3bbb9ec1c86828b365645bd7f997a9780b4.1455198819.git.larper@axis.com>

Add device tree documentation for the main PLL in the Artpec-6 SoC.

Signed-off-by: Lars Persson <larper at axis.com>
---
 Documentation/devicetree/bindings/clock/artpec6.txt | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/artpec6.txt

diff --git a/Documentation/devicetree/bindings/clock/artpec6.txt b/Documentation/devicetree/bindings/clock/artpec6.txt
new file mode 100644
index 0000000..521fec8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/artpec6.txt
@@ -0,0 +1,16 @@
+* Clock bindings for Axis ARTPEC-6 chip
+
+Required properties:
+- #clock-cells: Should be <0>
+- compatible: Should be "axis,artpec6-pll1-clock"
+- reg: Address and length of the DEVSTAT register.
+- clocks: The PLL's input clock.
+
+Examples:
+
+pll1_clk: pll1_clk {
+	#clock-cells = <0>;
+	compatible = "axis,artpec6-pll1-clock";
+	reg = <0xf8000000 4>;
+	clocks = <&ext_clk>;
+};
-- 
2.1.4



From lars.persson at axis.com  Thu Feb 11 06:04:38 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 15:04:38 +0100
Subject: [PATCH v2 4/8] arm: dts: add Artpec-6 SoC dtsi file
In-Reply-To: <cover.1455198819.git.larper@axis.com>
References: <cover.1455198819.git.larper@axis.com>
Message-ID: <e95951f1aef4e6526a231c9011009005aadc46ba.1455198819.git.larper@axis.com>

Initial device tree for the Artpec-6 SoC.

Signed-off-by: Lars Persson <larper at axis.com>
---
 arch/arm/boot/dts/artpec6.dtsi | 236 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 arch/arm/boot/dts/artpec6.dtsi

diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/arm/boot/dts/artpec6.dtsi
new file mode 100644
index 0000000..8b28f72
--- /dev/null
+++ b/arch/arm/boot/dts/artpec6.dtsi
@@ -0,0 +1,236 @@
+/*
+ * Device Tree Source for the Axis ARTPEC-6 SoC
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "skeleton.dtsi"
+
+/ {
+	compatible = "axis,artpec6";
+	interrupt-parent = <&intc>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+			next-level-cache = <&pl310>;
+		};
+
+		cpu1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <1>;
+			next-level-cache = <&pl310>;
+		};
+	};
+
+	dmacfg {
+		compatible = "axis,artpec6-dmacfg";
+		reg = <0xf8000010 4>;
+	};
+
+	psci {
+		compatible = "arm,psci-0.2", "arm,psci";
+		method = "smc";
+		psci_version = <0x84000000>;
+		cpu_on = <0x84000003>;
+		system_reset = <0x84000009>;
+	};
+
+	scu at faf00000 {
+		compatible = "arm,cortex-a9-scu";
+		reg = <0xfaf00000 0x58>;
+	};
+
+	/* Main external clock driving CPU and peripherals */
+	ext_clk: ext_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <50000000>;
+	};
+
+	/* PLL1 is used by CPU and some peripherals */
+	pll1_clk: pll1_clk at f8000000 {
+		#clock-cells = <0>;
+		compatible = "axis,artpec6-pll1-clock";
+		reg = <0xf8000000 4>;
+		clocks = <&ext_clk>;
+	};
+
+	cpu_clk: cpu_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&pll1_clk>;
+		clock-output-names = "cpu_clk";
+	};
+
+	cpu_clkdiv2: cpu_clkdiv2 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <2>;
+		clock-mult = <1>;
+		clocks = <&cpu_clk>;
+	};
+
+	cpu_clkdiv4: cpu_clkdiv4 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <4>;
+		clock-mult = <1>;
+		clocks = <&cpu_clk>;
+	};
+
+	apb_pclk: apb_pclk {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <8>;
+		clock-mult = <1>;
+		clocks = <&cpu_clk>;
+		clock-output-names = "apb_pclk";
+	};
+
+	/* PLL2 is used by a number of peripherals, including UDL */
+	pll2: pll2 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <24>;
+		clocks = <&ext_clk>;
+	};
+
+	/* PLL2DIV2 is used by the Fractional Clock Divider, for i2s */
+	pll2div2: pll2div2 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <2>;
+		clock-mult = <1>;
+		clocks = <&pll2>;
+	};
+
+	pll2div12: pll2div12 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <12>;
+		clock-mult = <1>;
+		clocks = <&pll2>;
+	};
+
+	pll2div24: pll2div24 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <24>;
+		clock-mult = <1>;
+		clocks = <&pll2>;
+		clock-output-names = "uart_clk";
+	};
+
+
+	gtimer at faf00200 {
+		compatible = "arm,cortex-a9-global-timer";
+		reg = <0xfaf00200 0x20>;
+		interrupts = <GIC_PPI 11 0xf01>;
+		clocks = <&cpu_clkdiv2>;
+	};
+
+	timer at faf00600 {
+		compatible = "arm,cortex-a9-twd-timer";
+		reg = <0xfaf00600 0x20>;
+		interrupts = <GIC_PPI 13 0xf04>;
+		clocks = <&cpu_clkdiv2>;
+		status = "disabled";
+	};
+
+	intc: interrupt-controller at faf01000 {
+		interrupt-controller;
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		reg = < 0xfaf01000 0x1000 >, < 0xfaf00100 0x0100 >;
+	};
+
+	pl310: cache-controller at faf10000 {
+		compatible = "arm,pl310-cache";
+		cache-unified;
+		cache-level = <2>;
+		reg = <0xfaf10000 0x1000>;
+		interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+		arm,data-latency = <1 1 1>;
+		arm,tag-latency = <1 1 1>;
+		arm,filter-ranges = <0x0 0x80000000>;
+	};
+
+	pmu {
+		compatible = "arm,cortex-a9-pmu";
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			<GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-parent = <&intc>;
+	};
+
+	amba at 0 {
+		compatible = "simple-bus";
+		#address-cells = <0x1>;
+		#size-cells = <0x1>;
+		interrupt-parent = <&intc>;
+		ranges;
+		dma-ranges = <0x80000000 0x00000000 0x40000000>;
+		dma-coherent;
+
+		ethernet: ethernet at f8010000 {
+			clock-names = "phy_ref_clk", "apb_pclk";
+			clocks = <&ext_clk>, <&apb_pclk>;
+			compatible = "snps,dwc-qos-ethernet-4.10";
+			interrupt-parent = <&intc>;
+			interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+			reg = <0xf8010000 0x4000>;
+
+			snps,write-requests = <2>;
+			snps,read-requests = <16>;
+			snps,txpbl = <8>;
+			snps,rxpbl = <2>;
+
+			status = "disabled";
+		};
+
+		uart0: serial at f8036000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xf8036000 0x1000>;
+			interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pll2div24>, <&apb_pclk>;
+			clock-names = "uart_clk", "apb_pclk";
+			status = "disabled";
+		};
+		uart1: serial at f8037000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xf8037000 0x1000>;
+			interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pll2div24>, <&apb_pclk>;
+			clock-names = "uart_clk", "apb_pclk";
+			status = "disabled";
+		};
+		uart2: serial at f8038000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xf8038000 0x1000>;
+			interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pll2div24>, <&apb_pclk>;
+			clock-names = "uart_clk", "apb_pclk";
+			status = "disabled";
+		};
+		uart3: serial at f8039000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xf8039000 0x1000>;
+			interrupts = <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pll2div24>, <&apb_pclk>;
+			clock-names = "uart_clk", "apb_pclk";
+			status = "disabled";
+		};
+	};
+};
-- 
2.1.4



From lars.persson at axis.com  Thu Feb 11 06:04:41 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 15:04:41 +0100
Subject: [PATCH v2 7/8] arm: multi_v7_defconfig: add MACH_ARTPEC6
In-Reply-To: <cover.1455198819.git.larper@axis.com>
References: <cover.1455198819.git.larper@axis.com>
Message-ID: <59ff2b8e89d207ffb14e5c77803280c5586a893f.1455198819.git.larper@axis.com>

Signed-off-by: Lars Persson <larper at axis.com>
---
 arch/arm/configs/multi_v7_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 8e8b2ac..1149642 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -16,6 +16,8 @@ CONFIG_ARCH_MULTI_V7=y
 # CONFIG_ARCH_MULTI_V4 is not set
 CONFIG_ARCH_VIRT=y
 CONFIG_ARCH_ALPINE=y
+CONFIG_ARCH_ARTPEC=y
+CONFIG_MACH_ARTPEC6=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_375=y
@@ -227,6 +229,7 @@ CONFIG_R8169=y
 CONFIG_SH_ETH=y
 CONFIG_SMSC911X=y
 CONFIG_STMMAC_ETH=y
+CONFIG_SYNOPSYS_DWC_ETH_QOS=y
 CONFIG_TI_CPSW=y
 CONFIG_XILINX_EMACLITE=y
 CONFIG_AT803X_PHY=y
-- 
2.1.4



From lars.persson at axis.com  Thu Feb 11 06:04:42 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 15:04:42 +0100
Subject: [PATCH v2 8/8] arm: mach-artpec: add entry to MAINTAINERS
In-Reply-To: <cover.1455198819.git.larper@axis.com>
References: <cover.1455198819.git.larper@axis.com>
Message-ID: <b5adeda17294fceb282d14446ab684316fc3028b.1455198819.git.larper@axis.com>

Signed-off-by: Lars Persson <larper at axis.com>
Signed-off-by: Jesper Nilsson <jesper.nilsson at axis.com>
---
 MAINTAINERS | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7f1fa4f..d32c1aa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -932,6 +932,16 @@ M:	Tsahee Zidenberg <tsahee at annapurnalabs.com>
 S:	Maintained
 F:	arch/arm/mach-alpine/
 
+ARM/ARTPEC MACHINE SUPPORT
+M:	Jesper Nilsson <jesper.nilsson at axis.com>
+M:	Lars Persson <lars.persson at axis.com>
+M:	Niklas Cassel <niklas.cassel at axis.com>
+S:	Maintained
+L:	linux-arm-kernel at axis.com
+F:	arch/arm/mach-artpec
+F:	arch/arm/boot/dts/artpec6*
+F:	drivers/clk/clk-artpec6.c
+
 ARM/ATMEL AT91RM9200, AT91SAM9 AND SAMA5 SOC SUPPORT
 M:	Nicolas Ferre <nicolas.ferre at atmel.com>
 M:	Alexandre Belloni <alexandre.belloni at free-electrons.com>
-- 
2.1.4



From lars.persson at axis.com  Thu Feb 11 06:04:36 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 15:04:36 +0100
Subject: [PATCH v2 2/8] clk: add artpec-6 pll1 clock driver
In-Reply-To: <cover.1455198819.git.larper@axis.com>
References: <cover.1455198819.git.larper@axis.com>
Message-ID: <6d47cfe5ab7596e91a7fcc5647c5907cc12a4d83.1455198819.git.larper@axis.com>

The PLL1 clock is a fixed-factor clock with factors derived from boot
mode pins. This driver is a simple wrapper to register the fixed
factor clock according to the pin settings.

Signed-off-by: Lars Persson <larper at axis.com>
---
 drivers/clk/Makefile      |  1 +
 drivers/clk/clk-artpec6.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 71 insertions(+)
 create mode 100644 drivers/clk/clk-artpec6.c

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index b038e36..388f0cf 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -17,6 +17,7 @@ endif
 
 # hardware specific clock types
 # please keep this section sorted lexicographically by file/directory path name
+obj-$(CONFIG_MACH_ARTPEC6)		+= clk-artpec6.o
 obj-$(CONFIG_MACH_ASM9260)		+= clk-asm9260.o
 obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)	+= clk-axi-clkgen.o
 obj-$(CONFIG_ARCH_AXXIA)		+= clk-axm5516.o
diff --git a/drivers/clk/clk-artpec6.c b/drivers/clk/clk-artpec6.c
new file mode 100644
index 0000000..3664c44
--- /dev/null
+++ b/drivers/clk/clk-artpec6.c
@@ -0,0 +1,70 @@
+/*
+ * ARTPEC-6 clock initialization
+ *
+ * Copyright 2015 Axis Comunications AB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+static void __init of_artpec6_pll1_setup(struct device_node *np)
+{
+	void __iomem *devstat;
+	struct clk *clk;
+	const char *clk_name = np->name;
+	const char *parent_name;
+	u32 pll_mode, pll_m, pll_n;
+
+	parent_name = of_clk_get_parent_name(np, 0);
+
+	devstat = of_iomap(np, 0);
+	if (devstat == NULL) {
+		pr_err("error to ioremap DEVSTAT\n");
+		return;
+	}
+
+	/* DEVSTAT register contains PLL settings */
+	pll_mode = (readl(devstat) >> 6) & 3;
+	iounmap(devstat);
+
+	/*
+	 * pll1 settings are designed for different DDR speeds using a fixed
+	 * 50MHz external clock. However, a different external clock could be
+	 * used on different boards.
+	 * CPU clock is half the DDR clock.
+	 */
+	switch (pll_mode) {
+	case 0: /* DDR3-2133 mode */
+		pll_m = 4;
+		pll_n = 85;
+		break;
+	case 1: /* DDR3-1866 mode */
+		pll_m = 6;
+		pll_n = 112;
+		break;
+	case 2: /* DDR3-1600 mode */
+		pll_m = 4;
+		pll_n = 64;
+		break;
+	case 3: /* DDR3-1333 mode */
+		pll_m = 8;
+		pll_n = 106;
+		break;
+	}
+	/* ext_clk is defined in device tree */
+	clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
+			pll_n, pll_m);
+	if (IS_ERR(clk)) {
+		pr_err("%s not registered\n", clk_name);
+		return;
+	}
+	of_clk_add_provider(np, of_clk_src_simple_get, clk);
+}
+CLK_OF_DECLARE(artpec6_pll1, "axis,artpec6-pll1-clock", of_artpec6_pll1_setup);
-- 
2.1.4



From s.trumtrar at pengutronix.de  Thu Feb 11 06:04:45 2016
From: s.trumtrar at pengutronix.de (Steffen Trumtrar)
Date: Thu, 11 Feb 2016 15:04:45 +0100
Subject: [PATCH 3/3] crypto: add basic driver for the MXC SCC
In-Reply-To: <1455199485-24458-1-git-send-email-s.trumtrar@pengutronix.de>
References: <1455199485-24458-1-git-send-email-s.trumtrar@pengutronix.de>
Message-ID: <1455199485-24458-3-git-send-email-s.trumtrar@pengutronix.de>

According to the Freescale GPL driver code, there are two different
Security Controller (SCC) versions: SCC and SCC2.

The SCC is found on older i.MX SoCs, e.g. the i.MX25. This is the
version implemented and tested here.

As there is no publicly available documentation for this IP core,
all information about this unit is gathered from the GPL'ed driver
from Freescale.

Signed-off-by: Steffen Trumtrar <s.trumtrar at pengutronix.de>
---
 drivers/crypto/Kconfig   |   9 +
 drivers/crypto/Makefile  |   1 +
 drivers/crypto/mxc-scc.c | 756 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 766 insertions(+)
 create mode 100644 drivers/crypto/mxc-scc.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 07d494276aad..ece3e231ee4d 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -339,6 +339,15 @@ config CRYPTO_DEV_SAHARA
 	  This option enables support for the SAHARA HW crypto accelerator
 	  found in some Freescale i.MX chips.
 
+config CRYPTO_DEV_MXC_SCC
+	tristate "Support for Freescale Security Controller (SCC)"
+	depends on ARCH_MXC && OF
+	select CRYPTO_BLKCIPHER
+	select CRYPTO_DES
+	help
+	  This option enables support for the Security Controller (SCC)
+	  found in Freescale i.MX25 chips.
+
 config CRYPTO_DEV_S5P
 	tristate "Support for Samsung S5PV210/Exynos crypto accelerator"
 	depends on ARCH_S5PV210 || ARCH_EXYNOS
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 713de9d11148..3c6432dd09d9 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_CRYPTO_DEV_PICOXCELL) += picoxcell_crypto.o
 obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/
 obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o
 obj-$(CONFIG_CRYPTO_DEV_SAHARA) += sahara.o
+obj-$(CONFIG_CRYPTO_DEV_MXC_SCC) += mxc-scc.o
 obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
 obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
 obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
diff --git a/drivers/crypto/mxc-scc.c b/drivers/crypto/mxc-scc.c
new file mode 100644
index 000000000000..f8cc00d1d92e
--- /dev/null
+++ b/drivers/crypto/mxc-scc.c
@@ -0,0 +1,756 @@
+/*
+ * Copyright (C) 2016 Pengutronix, Steffen Trumtrar <kernel at pengutronix.de>
+ *
+ * The driver is based on information gathered from
+ * drivers/mxc/security/mxc_scc.c which can be found in
+ * the Freescale linux-2.6-imx.git in the imx_2.6.35_maintain branch.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/clk.h>
+#include <linux/crypto.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+
+#include <crypto/algapi.h>
+#include <crypto/des.h>
+
+/* Secure Memory (SCM) registers */
+#define SCC_SCM_RED_START		0x0000
+#define SCC_SCM_BLACK_START		0x0004
+#define SCC_SCM_LENGTH			0x0008
+#define SCC_SCM_CTRL			0x000C
+#define SCC_SCM_STATUS			0x0010
+#define SCC_SCM_ERROR_STATUS		0x0014
+#define SCC_SCM_INTR_CTRL		0x0018
+#define SCC_SCM_CFG			0x001C
+#define SCC_SCM_INIT_VECTOR_0		0x0020
+#define SCC_SCM_INIT_VECTOR_1		0x0024
+#define SCC_SCM_RED_MEMORY		0x0400
+#define SCC_SCM_BLACK_MEMORY		0x0800
+
+/* Security Monitor (SMN) Registers */
+#define SCC_SMN_STATUS			0x1000
+#define SCC_SMN_COMMAND		0x1004
+#define SCC_SMN_SEQ_START		0x1008
+#define SCC_SMN_SEQ_END		0x100C
+#define SCC_SMN_SEQ_CHECK		0x1010
+#define SCC_SMN_BIT_COUNT		0x1014
+#define SCC_SMN_BITBANK_INC_SIZE	0x1018
+#define SCC_SMN_BITBANK_DECREMENT	0x101C
+#define SCC_SMN_COMPARE_SIZE		0x1020
+#define SCC_SMN_PLAINTEXT_CHECK	0x1024
+#define SCC_SMN_CIPHERTEXT_CHECK	0x1028
+#define SCC_SMN_TIMER_IV		0x102C
+#define SCC_SMN_TIMER_CONTROL		0x1030
+#define SCC_SMN_DEBUG_DETECT_STAT	0x1034
+#define SCC_SMN_TIMER			0x1038
+
+#define SCC_SCM_CTRL_START_CIPHER	BIT(2)
+#define SCC_SCM_CTRL_CBC_MODE		BIT(1)
+#define SCC_SCM_CTRL_DECRYPT_MODE	BIT(0)
+
+#define SCC_SCM_STATUS_LEN_ERR		BIT(12)
+#define SCC_SCM_STATUS_SMN_UNBLOCKED	BIT(11)
+#define SCC_SCM_STATUS_CIPHERING_DONE	BIT(10)
+#define SCC_SCM_STATUS_ZEROIZING_DONE	BIT(9)
+#define SCC_SCM_STATUS_INTR_STATUS	BIT(8)
+#define SCC_SCM_STATUS_SEC_KEY		BIT(7)
+#define SCC_SCM_STATUS_INTERNAL_ERR	BIT(6)
+#define SCC_SCM_STATUS_BAD_SEC_KEY	BIT(5)
+#define SCC_SCM_STATUS_ZEROIZE_FAIL	BIT(4)
+#define SCC_SCM_STATUS_SMN_BLOCKED	BIT(3)
+#define SCC_SCM_STATUS_CIPHERING	BIT(2)
+#define SCC_SCM_STATUS_ZEROIZING	BIT(1)
+#define SCC_SCM_STATUS_BUSY		BIT(0)
+
+#define SCC_SMN_STATUS_STATE_MASK	0x0000001F
+#define SCC_SMN_STATE_START		0x0
+/* The SMN is zeroizing its RAM during reset */
+#define SCC_SMN_STATE_ZEROIZE_RAM	0x5
+/* SMN has passed internal checks */
+#define SCC_SMN_STATE_HEALTH_CHECK	0x6
+/* Fatal Security Violation. SMN is locked, SCM is inoperative. */
+#define SCC_SMN_STATE_FAIL		0x9
+/* SCC is in secure state. SCM is using secret key. */
+#define SCC_SMN_STATE_SECURE		0xA
+/* SCC is not secure. SCM is using default key. */
+#define SCC_SMN_STATE_NON_SECURE	0xC
+
+#define SCC_SCM_INTR_CTRL_ZEROIZE_MEM	BIT(2)
+#define SCC_SCM_INTR_CTRL_CLR_INTR	BIT(1)
+#define SCC_SCM_INTR_CTRL_MASK_INTR	BIT(0)
+
+/* Size, in blocks, of Red memory. */
+#define SCC_SCM_CFG_BLACK_SIZE_MASK	0x07fe0000
+#define SCC_SCM_CFG_BLACK_SIZE_SHIFT	17
+/* Size, in blocks, of Black memory. */
+#define SCC_SCM_CFG_RED_SIZE_MASK	0x0001ff80
+#define SCC_SCM_CFG_RED_SIZE_SHIFT	7
+/* Number of bytes per block. */
+#define SCC_SCM_CFG_BLOCK_SIZE_MASK	0x0000007f
+
+#define SCC_SMN_COMMAND_TAMPER_LOCK	BIT(4)
+#define SCC_SMN_COMMAND_CLR_INTR	BIT(3)
+#define SCC_SMN_COMMAND_CLR_BIT_BANK	BIT(2)
+#define SCC_SMN_COMMAND_EN_INTR	BIT(1)
+#define SCC_SMN_COMMAND_SET_SOFTWARE_ALARM  BIT(0)
+
+#define SCC_KEY_SLOTS			20
+#define SCC_MAX_KEY_SIZE		32
+#define SCC_KEY_SLOT_SIZE		32
+
+#define SCC_CRC_CCITT_START		0xFFFF
+
+/*
+ * Offset into each RAM of the base of the area which is not
+ * used for Stored Keys.
+ */
+#define SCC_NON_RESERVED_OFFSET	(SCC_KEY_SLOTS * SCC_KEY_SLOT_SIZE)
+
+/* Fixed padding for appending to plaintext to fill out a block */
+static char scc_block_padding[8] = { 0x80, 0, 0, 0, 0, 0, 0, 0 };
+
+enum mxc_scc_state {
+	SCC_STATE_OK,
+	SCC_STATE_UNIMPLEMENTED,
+	SCC_STATE_FAILED
+};
+
+struct mxc_scc {
+	struct device		*dev;
+	void __iomem		*base;
+	struct clk		*clk;
+	struct mutex		mutex;
+	spinlock_t		lock;
+	struct crypto_queue	queue;
+	struct crypto_async_request *req;
+	int			block_size_bytes;
+	int			black_ram_size_blocks;
+	int			memory_size_bytes;
+	int			bytes_remaining;
+
+	void __iomem		*red_memory;
+	void __iomem		*black_memory;
+};
+
+struct mxc_scc_ctx {
+	struct mxc_scc		*scc;
+	struct scatterlist	*sg_src;
+	size_t			src_nents;
+	struct scatterlist	*sg_dst;
+	size_t			dst_nents;
+	unsigned int		offset;
+	unsigned int		size;
+	unsigned int		ctrl;
+};
+
+struct mxc_scc_crypto_tmpl {
+	struct mxc_scc *scc;
+	struct crypto_alg alg;
+};
+
+static int mxc_scc_get_data(struct mxc_scc_ctx *ctx,
+			    struct crypto_async_request *req)
+{
+	struct ablkcipher_request *ablkreq = ablkcipher_request_cast(req);
+	struct mxc_scc *scc = ctx->scc;
+	size_t len;
+	void __iomem *from;
+
+	if (ctx->ctrl & SCC_SCM_CTRL_DECRYPT_MODE)
+		from = scc->red_memory;
+	else
+		from = scc->black_memory;
+
+	dev_dbg(scc->dev, "pcopy: from 0x%p %d bytes\n", from,
+		ctx->dst_nents * 8);
+	len = sg_pcopy_from_buffer(ablkreq->dst, ctx->dst_nents,
+				   from, ctx->size, ctx->offset);
+	if (!len) {
+		dev_err(scc->dev, "pcopy err from 0x%p (len=%d)\n", from, len);
+		return -EINVAL;
+	}
+
+#ifdef DEBUG
+	print_hex_dump(KERN_ERR,
+		       "red memory@"__stringify(__LINE__)": ",
+		       DUMP_PREFIX_ADDRESS, 16, 4,
+		       scc->red_memory, ctx->size, 1);
+	print_hex_dump(KERN_ERR,
+		       "black memory@"__stringify(__LINE__)": ",
+		       DUMP_PREFIX_ADDRESS, 16, 4,
+		       scc->black_memory, ctx->size, 1);
+#endif
+
+	ctx->offset += len;
+
+	if (ctx->offset < ablkreq->nbytes)
+		return -EINPROGRESS;
+
+	return 0;
+}
+
+static int mxc_scc_ablkcipher_req_init(struct ablkcipher_request *req,
+				       struct mxc_scc_ctx *ctx)
+{
+	struct mxc_scc *scc = ctx->scc;
+
+	ctx->src_nents = sg_nents_for_len(req->src, req->nbytes);
+	if (ctx->src_nents < 0) {
+		dev_err(scc->dev, "Invalid number of src SC");
+		return ctx->src_nents;
+	}
+
+	ctx->dst_nents = sg_nents_for_len(req->dst, req->nbytes);
+	if (ctx->dst_nents < 0) {
+		dev_err(scc->dev, "Invalid number of dst SC");
+		return ctx->dst_nents;
+	}
+
+	ctx->size = 0;
+	ctx->offset = 0;
+
+	return 0;
+}
+
+static int mxc_scc_put_data(struct mxc_scc_ctx *ctx,
+			     struct ablkcipher_request *req)
+{
+	u8 padding_buffer[sizeof(u16) + sizeof(scc_block_padding)];
+	size_t len = min_t(size_t, req->nbytes - ctx->offset,
+			   ctx->scc->bytes_remaining);
+	unsigned int padding_byte_count = 0;
+	struct mxc_scc *scc = ctx->scc;
+	void __iomem *to;
+
+	if (ctx->ctrl & SCC_SCM_CTRL_DECRYPT_MODE)
+		to = scc->black_memory;
+	else
+		to = scc->red_memory;
+
+	if (ctx->ctrl & SCC_SCM_CTRL_CBC_MODE && req->info)
+		memcpy(scc->base + SCC_SCM_INIT_VECTOR_0, req->info,
+		       scc->block_size_bytes);
+
+	len = sg_pcopy_to_buffer(req->src, ctx->src_nents,
+				 to, len, ctx->offset);
+	if (!len) {
+		dev_err(scc->dev, "pcopy err to 0x%p (len=%d)\n", to, len);
+		return -EINVAL;
+	}
+
+	ctx->size = len;
+
+#ifdef DEBUG
+	dev_dbg(scc->dev, "copied %d bytes to 0x%p\n", len, to);
+	print_hex_dump(KERN_ERR,
+		       "init vector0@"__stringify(__LINE__)": ",
+		       DUMP_PREFIX_ADDRESS, 16, 4,
+		       scc->base + SCC_SCM_INIT_VECTOR_0, scc->block_size_bytes,
+		       1);
+	print_hex_dump(KERN_ERR,
+		       "red memory@"__stringify(__LINE__)": ",
+		       DUMP_PREFIX_ADDRESS, 16, 4,
+		       scc->red_memory, ctx->size, 1);
+	print_hex_dump(KERN_ERR,
+		       "black memory@"__stringify(__LINE__)": ",
+		       DUMP_PREFIX_ADDRESS, 16, 4,
+		       scc->black_memory, ctx->size, 1);
+#endif
+
+	scc->bytes_remaining -= len;
+
+	padding_byte_count = len % scc->block_size_bytes;
+
+	if (padding_byte_count) {
+		memcpy(padding_buffer, scc_block_padding, padding_byte_count);
+		memcpy(to + len, padding_buffer, padding_byte_count);
+		ctx->size += padding_byte_count;
+	}
+
+#ifdef DEBUG
+	print_hex_dump(KERN_ERR,
+		       "data to encrypt@"__stringify(__LINE__)": ",
+		       DUMP_PREFIX_ADDRESS, 16, 4,
+		       to, ctx->size, 1);
+#endif
+
+	return 0;
+}
+
+static void mxc_scc_ablkcipher_next(struct mxc_scc_ctx *ctx,
+				    struct crypto_async_request *req)
+{
+	struct ablkcipher_request *ablkreq = ablkcipher_request_cast(req);
+	struct mxc_scc *scc = ctx->scc;
+	int err;
+
+	mutex_lock(&scc->mutex);
+
+	dev_dbg(scc->dev, "dispatch request (nbytes=%d, src=%p, dst=%p)\n",
+		ablkreq->nbytes, ablkreq->src, ablkreq->dst);
+
+	writel(0, scc->base + SCC_SCM_ERROR_STATUS);
+
+	err = mxc_scc_put_data(ctx, ablkreq);
+	if (err)
+		mutex_unlock(&scc->mutex);
+
+	dev_dbg(scc->dev, "Start encryption (0x%p/0x%p)\n",
+		(void *)readl(scc->base + SCC_SCM_RED_START),
+		(void *)readl(scc->base + SCC_SCM_BLACK_START));
+
+	/* clear interrupt control registers */
+	writel(SCC_SCM_INTR_CTRL_CLR_INTR,
+	       scc->base + SCC_SCM_INTR_CTRL);
+
+	writel((ctx->size / ctx->scc->block_size_bytes) - 1,
+	       scc->base + SCC_SCM_LENGTH);
+
+	dev_dbg(scc->dev, "Process %d block(s) in 0x%p\n",
+		ctx->size / ctx->scc->block_size_bytes,
+		(ctx->ctrl & SCC_SCM_CTRL_DECRYPT_MODE) ? scc->black_memory :
+		scc->red_memory);
+
+	writel(ctx->ctrl, scc->base + SCC_SCM_CTRL);
+}
+
+static irqreturn_t mxc_scc_int(int irq, void *priv)
+{
+	struct crypto_async_request *req;
+	struct mxc_scc_ctx *ctx;
+	struct mxc_scc *scc = priv;
+	int status;
+	int ret;
+
+	status = readl(scc->base + SCC_SCM_STATUS);
+
+	/* clear interrupt control registers */
+	writel(SCC_SCM_INTR_CTRL_CLR_INTR, scc->base + SCC_SCM_INTR_CTRL);
+
+	if (status & SCC_SCM_STATUS_BUSY)
+		return IRQ_NONE;
+
+	spin_lock_bh(&scc->lock);
+	req = scc->req;
+	spin_unlock_bh(&scc->lock);
+	if (req) {
+		ctx = crypto_tfm_ctx(req->tfm);
+		ret = mxc_scc_get_data(ctx, req);
+		if (ret != -EINPROGRESS) {
+			scc->req = NULL;
+			scc->bytes_remaining = scc->memory_size_bytes;
+			req->complete(req, ret);
+			mutex_unlock(&scc->mutex);
+		} else {
+			mxc_scc_ablkcipher_next(ctx, req);
+		}
+	}
+
+	return IRQ_HANDLED;
+}
+
+static int mxc_scc_cra_init(struct crypto_tfm *tfm)
+{
+	struct mxc_scc_ctx *ctx = crypto_tfm_ctx(tfm);
+	struct crypto_alg *alg = tfm->__crt_alg;
+	struct mxc_scc_crypto_tmpl *algt;
+
+	algt = container_of(alg, struct mxc_scc_crypto_tmpl, alg);
+
+	ctx->scc = algt->scc;
+	return 0;
+}
+
+static void mxc_scc_dequeue_req_unlocked(struct mxc_scc_ctx *ctx)
+{
+	struct crypto_async_request *req, *backlog;
+
+	spin_lock_bh(&ctx->scc->lock);
+	backlog = crypto_get_backlog(&ctx->scc->queue);
+	req = crypto_dequeue_request(&ctx->scc->queue);
+	ctx->scc->req = req;
+	spin_unlock_bh(&ctx->scc->lock);
+
+	if (!req)
+		return;
+
+	if (backlog)
+		backlog->complete(backlog, -EINPROGRESS);
+
+	ctx = crypto_tfm_ctx(req->tfm);
+	mxc_scc_ablkcipher_next(ctx, req);
+}
+
+
+static int mxc_scc_queue_req(struct mxc_scc_ctx *ctx,
+			     struct crypto_async_request *req)
+{
+	int ret;
+
+	spin_lock_bh(&ctx->scc->lock);
+	ret = crypto_enqueue_request(&ctx->scc->queue, req);
+	spin_unlock_bh(&ctx->scc->lock);
+
+	if (ret != -EINPROGRESS)
+		return ret;
+
+	mxc_scc_dequeue_req_unlocked(ctx);
+
+	return -EINPROGRESS;
+}
+
+
+static int mxc_scc_des3_op(struct mxc_scc_ctx *ctx,
+			   struct ablkcipher_request *req)
+{
+	int err;
+
+	err = mxc_scc_ablkcipher_req_init(req, ctx);
+	if (err)
+		return err;
+
+	return mxc_scc_queue_req(ctx, &req->base);
+}
+
+static int mxc_scc_ecb_des_encrypt(struct ablkcipher_request *req)
+{
+	struct crypto_ablkcipher *cipher = crypto_ablkcipher_reqtfm(req);
+	struct mxc_scc_ctx *ctx = crypto_ablkcipher_ctx(cipher);
+
+	ctx->ctrl = SCC_SCM_CTRL_START_CIPHER;
+
+	return mxc_scc_des3_op(ctx, req);
+}
+
+static int mxc_scc_ecb_des_decrypt(struct ablkcipher_request *req)
+{
+	struct crypto_ablkcipher *cipher = crypto_ablkcipher_reqtfm(req);
+	struct mxc_scc_ctx *ctx = crypto_ablkcipher_ctx(cipher);
+
+	ctx->ctrl = SCC_SCM_CTRL_START_CIPHER;
+	ctx->ctrl |= SCC_SCM_CTRL_DECRYPT_MODE;
+
+	return mxc_scc_des3_op(ctx, req);
+}
+
+static int mxc_scc_cbc_des_encrypt(struct ablkcipher_request *req)
+{
+	struct crypto_ablkcipher *cipher = crypto_ablkcipher_reqtfm(req);
+	struct mxc_scc_ctx *ctx = crypto_ablkcipher_ctx(cipher);
+
+	ctx->ctrl = SCC_SCM_CTRL_START_CIPHER;
+	ctx->ctrl |= SCC_SCM_CTRL_CBC_MODE;
+
+	return mxc_scc_des3_op(ctx, req);
+}
+
+static int mxc_scc_cbc_des_decrypt(struct ablkcipher_request *req)
+{
+	struct crypto_ablkcipher *cipher = crypto_ablkcipher_reqtfm(req);
+	struct mxc_scc_ctx *ctx = crypto_ablkcipher_ctx(cipher);
+
+	ctx->ctrl = SCC_SCM_CTRL_START_CIPHER;
+	ctx->ctrl |= SCC_SCM_CTRL_CBC_MODE;
+	ctx->ctrl |= SCC_SCM_CTRL_DECRYPT_MODE;
+
+	return mxc_scc_des3_op(ctx, req);
+}
+
+static void mxc_scc_hw_init(struct mxc_scc *scc)
+{
+	int offset;
+
+	offset = SCC_NON_RESERVED_OFFSET / scc->block_size_bytes;
+
+	/* Fill the RED_START register */
+	writel(offset, scc->base + SCC_SCM_RED_START);
+
+	/* Fill the BLACK_START register */
+	writel(offset, scc->base + SCC_SCM_BLACK_START);
+
+	scc->red_memory = scc->base + SCC_SCM_RED_MEMORY +
+			  SCC_NON_RESERVED_OFFSET;
+
+	scc->black_memory = scc->base + SCC_SCM_BLACK_MEMORY +
+			    SCC_NON_RESERVED_OFFSET;
+
+	scc->bytes_remaining = scc->memory_size_bytes;
+}
+
+static int mxc_scc_get_config(struct mxc_scc *scc)
+{
+	int config;
+
+	config = readl(scc->base + SCC_SCM_CFG);
+
+	scc->block_size_bytes = config & SCC_SCM_CFG_BLOCK_SIZE_MASK;
+
+	scc->black_ram_size_blocks = (config & SCC_SCM_CFG_BLACK_SIZE_MASK);
+
+	scc->memory_size_bytes = (scc->block_size_bytes *
+				  scc->black_ram_size_blocks) -
+				  SCC_NON_RESERVED_OFFSET;
+
+	return 0;
+}
+
+static enum mxc_scc_state mxc_scc_get_state(struct mxc_scc *scc)
+{
+	enum mxc_scc_state state;
+	int status;
+
+	status = readl(scc->base + SCC_SMN_STATUS) &
+		       SCC_SMN_STATUS_STATE_MASK;
+
+	/* If in Health Check, try to bringup to secure state */
+	if (status & SCC_SMN_STATE_HEALTH_CHECK) {
+		/*
+		 * Write a simple algorithm to the Algorithm Sequence
+		 * Checker (ASC)
+		 */
+		writel(0xaaaa, scc->base + SCC_SMN_SEQ_START);
+		writel(0x5555, scc->base + SCC_SMN_SEQ_END);
+		writel(0x5555, scc->base + SCC_SMN_SEQ_CHECK);
+
+		status = readl(scc->base + SCC_SMN_STATUS) &
+			       SCC_SMN_STATUS_STATE_MASK;
+	}
+
+	switch (status) {
+	case SCC_SMN_STATE_NON_SECURE:
+	case SCC_SMN_STATE_SECURE:
+		state = SCC_STATE_OK;
+		break;
+	case SCC_SMN_STATE_FAIL:
+		state = SCC_STATE_FAILED;
+		break;
+	default:
+		state = SCC_STATE_UNIMPLEMENTED;
+		break;
+	}
+
+	return state;
+}
+
+static struct mxc_scc_crypto_tmpl scc_ecb_des = {
+	.alg = {
+		.cra_name = "ecb(des3_ede)",
+		.cra_driver_name = "ecb-des3-scc",
+		.cra_priority = 300,
+		.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER,
+		.cra_blocksize = DES3_EDE_BLOCK_SIZE,
+		.cra_ctxsize = sizeof(struct mxc_scc_ctx),
+		.cra_alignmask = 0,
+		.cra_type = &crypto_ablkcipher_type,
+		.cra_module = THIS_MODULE,
+		.cra_init = mxc_scc_cra_init,
+		.cra_u.ablkcipher = {
+			.min_keysize = DES3_EDE_KEY_SIZE,
+			.max_keysize = DES3_EDE_KEY_SIZE,
+			.encrypt = mxc_scc_ecb_des_encrypt,
+			.decrypt = mxc_scc_ecb_des_decrypt,
+		}
+	}
+};
+
+static struct mxc_scc_crypto_tmpl scc_cbc_des = {
+	.alg = {
+		.cra_name = "cbc(des3_ede)",
+		.cra_driver_name = "cbc-des3-scc",
+		.cra_priority = 300,
+		.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER,
+		.cra_blocksize = DES3_EDE_BLOCK_SIZE,
+		.cra_ctxsize = sizeof(struct mxc_scc_ctx),
+		.cra_alignmask = 0,
+		.cra_type = &crypto_ablkcipher_type,
+		.cra_module = THIS_MODULE,
+		.cra_init = mxc_scc_cra_init,
+		.cra_u.ablkcipher = {
+			.min_keysize = DES3_EDE_KEY_SIZE,
+			.max_keysize = DES3_EDE_KEY_SIZE,
+			.encrypt = mxc_scc_cbc_des_encrypt,
+			.decrypt = mxc_scc_cbc_des_decrypt,
+		}
+	}
+};
+
+static struct mxc_scc_crypto_tmpl *scc_crypto_algs[] = {
+	&scc_ecb_des,
+	&scc_cbc_des,
+};
+
+static int mxc_scc_crypto_register(struct mxc_scc *scc)
+{
+	unsigned int i, k;
+	int err = 0;
+
+	for (i = 0; i < ARRAY_SIZE(scc_crypto_algs); i++) {
+		scc_crypto_algs[i]->scc = scc;
+		err = crypto_register_alg(&scc_crypto_algs[i]->alg);
+		if (err)
+			goto err_out;
+	}
+
+	return 0;
+err_out:
+	for (k = 0; k < i; k++)
+		crypto_unregister_alg(&scc_crypto_algs[k]->alg);
+	return err;
+}
+
+static void mxc_scc_crypto_unregister(void)
+{
+	unsigned int i;
+
+	for (i = 0; i < ARRAY_SIZE(scc_crypto_algs); i++)
+		crypto_unregister_alg(&scc_crypto_algs[i]->alg);
+}
+
+static int mxc_scc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct resource *res;
+	struct mxc_scc *scc;
+	enum mxc_scc_state state;
+	int irq;
+	int ret;
+
+	scc = devm_kzalloc(dev, sizeof(*scc), GFP_KERNEL);
+	if (!scc)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res)
+		return -ENOENT;
+
+	scc->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(scc->base))
+		return PTR_ERR(scc->base);
+
+	scc->clk = devm_clk_get(&pdev->dev, "ipg");
+	if (IS_ERR(scc->clk)) {
+		dev_err(dev, "Could not get ipg clock\n");
+		return PTR_ERR(scc->clk);
+	}
+
+	clk_prepare_enable(scc->clk);
+
+	/* clear error status register */
+	writel(0x0, scc->base + SCC_SCM_ERROR_STATUS);
+
+	/* clear interrupt control registers */
+	writel(SCC_SCM_INTR_CTRL_CLR_INTR |
+	       SCC_SCM_INTR_CTRL_MASK_INTR,
+	       scc->base + SCC_SCM_INTR_CTRL);
+
+	writel(SCC_SMN_COMMAND_CLR_INTR |
+	       SCC_SMN_COMMAND_EN_INTR,
+	       scc->base + SCC_SMN_COMMAND);
+
+	scc->dev = dev;
+	platform_set_drvdata(pdev, scc);
+
+	ret = mxc_scc_get_config(scc);
+	if (ret)
+		goto err_out;
+
+	state = mxc_scc_get_state(scc);
+
+	if (state != SCC_STATE_OK) {
+		dev_err(dev, "SCC in unusable state %d\n", state);
+		ret = -EINVAL;
+		goto err_out;
+	}
+
+	mxc_scc_hw_init(scc);
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(dev, "failed to get irq resource\n");
+		goto err_out;
+	}
+
+	ret = devm_request_threaded_irq(dev, irq, NULL, mxc_scc_int,
+					IRQF_ONESHOT, dev_name(dev), scc);
+	if (ret)
+		goto err_out;
+
+	irq = platform_get_irq(pdev, 1);
+	if (irq < 0) {
+		dev_err(dev, "failed to get irq resource\n");
+		goto err_out;
+	}
+
+	mutex_init(&scc->mutex);
+	spin_lock_init(&scc->lock);
+	/* FIXME: calculate queue from RAM slots */
+	crypto_init_queue(&scc->queue, 50);
+
+	ret = devm_request_threaded_irq(dev, irq, NULL, mxc_scc_int,
+					IRQF_ONESHOT, dev_name(dev), scc);
+	if (ret)
+		goto err_out;
+
+	ret = mxc_scc_crypto_register(scc);
+	if (ret) {
+		dev_err(dev, "could not register algorithms");
+		goto err_out;
+	}
+
+	dev_info(dev, "registered successfully.\n");
+
+	return 0;
+
+err_out:
+	clk_disable_unprepare(scc->clk);
+
+	return ret;
+}
+
+static int mxc_scc_remove(struct platform_device *pdev)
+{
+	struct mxc_scc *scc = platform_get_drvdata(pdev);
+
+	mxc_scc_crypto_unregister();
+
+	clk_disable_unprepare(scc->clk);
+
+	return 0;
+}
+
+static const struct of_device_id mxc_scc_dt_ids[] = {
+	{ .compatible = "fsl,imx25-scc", .data = NULL, },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mxc_scc_dt_ids);
+
+static struct platform_driver mxc_scc_driver = {
+	.probe	= mxc_scc_probe,
+	.remove	= mxc_scc_remove,
+	.driver	= {
+		.name		= "mxc-scc",
+		.of_match_table	= mxc_scc_dt_ids,
+	},
+};
+
+module_platform_driver(mxc_scc_driver);
+MODULE_AUTHOR("Steffen Trumtrar <kernel at pengutronix.de>");
+MODULE_DESCRIPTION("Freescale i.MX25 SCC Crypto driver");
+MODULE_LICENSE("GPL v2");
-- 
2.7.0.rc3



From s.trumtrar at pengutronix.de  Thu Feb 11 06:04:44 2016
From: s.trumtrar at pengutronix.de (Steffen Trumtrar)
Date: Thu, 11 Feb 2016 15:04:44 +0100
Subject: [PATCH 2/3] ARM: i.MX25: add scc module to dtsi
In-Reply-To: <1455199485-24458-1-git-send-email-s.trumtrar@pengutronix.de>
References: <1455199485-24458-1-git-send-email-s.trumtrar@pengutronix.de>
Message-ID: <1455199485-24458-2-git-send-email-s.trumtrar@pengutronix.de>

Add the Security Controller (SCC) module to the dtsi.

Signed-off-by: Steffen Trumtrar <s.trumtrar at pengutronix.de>
---
 arch/arm/boot/dts/imx25.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index cde329e9b9e3..73118aba4cc4 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -397,6 +397,15 @@
 				interrupts = <41>;
 			};
 
+			scc: crypto at 53fac000 {
+				compatible = "fsl,imx25-scc";
+				reg = <0x53fac000 0x4000>;
+				clocks = <&clks 111>;
+				clock-names = "ipg";
+				interrupts = <49>, <50>;
+				interrupt-names = "scm", "smn";
+			};
+
 			esdhc1: esdhc at 53fb4000 {
 				compatible = "fsl,imx25-esdhc";
 				reg = <0x53fb4000 0x4000>;
-- 
2.7.0.rc3



From s.trumtrar at pengutronix.de  Thu Feb 11 06:04:43 2016
From: s.trumtrar at pengutronix.de (Steffen Trumtrar)
Date: Thu, 11 Feb 2016 15:04:43 +0100
Subject: [PATCH 1/3] Documentation: devicetree: add Freescale SCC bindings
Message-ID: <1455199485-24458-1-git-send-email-s.trumtrar@pengutronix.de>

Add documentation for the Freescale Security Controller (SCC)
found on i.MX25 SoCs.

Signed-off-by: Steffen Trumtrar <s.trumtrar at pengutronix.de>
---
 .../devicetree/bindings/crypto/fsl-imx-scc.txt          | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt

diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
new file mode 100644
index 000000000000..9a15ab8da94f
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
@@ -0,0 +1,17 @@
+Freescale Security Controller (SCC)
+
+Required properties:
+- compatible : Should be "fsl,imx25-scc".
+- reg : Should contain register location and length.
+- interrupts : Should contain interrupt numbers for SCM IRQ and SMN IRQ.
+
+Example:
+
+	scc: crypto at 53fac000 {
+		compatible = "fsl,imx25-scc";
+		reg = <0x53fac000 0x4000>;
+		clocks = <&clks 111>;
+		clock-names = "ipg";
+		interrupts = <49>, <50>;
+		interrupt-names = "scm", "smn";
+	};
-- 
2.7.0.rc3



From lars.persson at axis.com  Thu Feb 11 06:04:40 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 15:04:40 +0100
Subject: [PATCH v2 6/8] arm: initial machine port for artpec-6 SoC
In-Reply-To: <cover.1455198819.git.larper@axis.com>
References: <cover.1455198819.git.larper@axis.com>
Message-ID: <326c3d195bd2011e08509fe8bdcc32e48df13b86.1455198819.git.larper@axis.com>

Basic machine port for the Artpec-6 SoC from Axis
Communications.

Signed-off-by: Lars Persson <larper at axis.com>
---
 arch/arm/Kconfig                     |  2 +
 arch/arm/Makefile                    |  1 +
 arch/arm/mach-artpec/Kconfig         | 20 ++++++++++
 arch/arm/mach-artpec/Makefile        |  1 +
 arch/arm/mach-artpec/board-artpec6.c | 72 ++++++++++++++++++++++++++++++++++++
 5 files changed, 96 insertions(+)
 create mode 100644 arch/arm/mach-artpec/Kconfig
 create mode 100644 arch/arm/mach-artpec/Makefile
 create mode 100644 arch/arm/mach-artpec/board-artpec6.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4f799e5..e1565dd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -724,6 +724,8 @@ source "arch/arm/mach-mvebu/Kconfig"
 
 source "arch/arm/mach-alpine/Kconfig"
 
+source "arch/arm/mach-artpec/Kconfig"
+
 source "arch/arm/mach-asm9260/Kconfig"
 
 source "arch/arm/mach-at91/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index fe25410..4eb24c6 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -154,6 +154,7 @@ textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
 # Machine directory name.  This list is sorted alphanumerically
 # by CONFIG_* macro name.
 machine-$(CONFIG_ARCH_ALPINE)		+= alpine
+machine-$(CONFIG_ARCH_ARTPEC)		+= artpec
 machine-$(CONFIG_ARCH_AT91)		+= at91
 machine-$(CONFIG_ARCH_AXXIA)		+= axxia
 machine-$(CONFIG_ARCH_BCM)		+= bcm
diff --git a/arch/arm/mach-artpec/Kconfig b/arch/arm/mach-artpec/Kconfig
new file mode 100644
index 0000000..6cbe5a2
--- /dev/null
+++ b/arch/arm/mach-artpec/Kconfig
@@ -0,0 +1,20 @@
+menuconfig ARCH_ARTPEC
+	bool "Axis Communications ARM based ARTPEC SoCs"
+	depends on ARCH_MULTI_V7
+
+if ARCH_ARTPEC
+
+config MACH_ARTPEC6
+	bool "Axis ARTPEC-6 ARM Cortex A9 Platform"
+	depends on ARCH_MULTI_V7
+	select ARM_AMBA
+	select ARM_GIC
+	select ARM_GLOBAL_TIMER
+	select ARM_PSCI
+	select HAVE_ARM_ARCH_TIMER
+	select HAVE_ARM_SCU
+	select HAVE_ARM_TWD if SMP
+	help
+	  Support for Axis ARTPEC-6 ARM Cortex A9 Platform
+
+endif
diff --git a/arch/arm/mach-artpec/Makefile b/arch/arm/mach-artpec/Makefile
new file mode 100644
index 0000000..78325f0
--- /dev/null
+++ b/arch/arm/mach-artpec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MACH_ARTPEC6)		:= board-artpec6.o
diff --git a/arch/arm/mach-artpec/board-artpec6.c b/arch/arm/mach-artpec/board-artpec6.c
new file mode 100644
index 0000000..d486217
--- /dev/null
+++ b/arch/arm/mach-artpec/board-artpec6.c
@@ -0,0 +1,72 @@
+/*
+ * ARTPEC-6 device support.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/amba/bus.h>
+#include <linux/clocksource.h>
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/of_platform.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/clk-provider.h>
+#include <linux/smp.h>
+#include <asm/smp_scu.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/psci.h>
+#include <linux/arm-smccc.h>
+
+#define ARTPEC6_DMACFG_UARTS_BURST 0xff
+
+#define SECURE_OP_L2C_WRITEREG 0xb4000001
+
+static void __init artpec6_init_machine(void)
+{
+	void __iomem *dmacfg;
+	struct device_node *np;
+
+	np = of_find_compatible_node(NULL, NULL, "axis,artpec6-dmacfg");
+	if (np) {
+		/* Use PL011 DMA Burst Request signal instead of DMA
+		 *  Single Request
+		 */
+		dmacfg = of_iomap(np, 0);
+		BUG_ON(!dmacfg);
+
+		writel(ARTPEC6_DMACFG_UARTS_BURST, dmacfg);
+		iounmap(dmacfg);
+		of_node_put(np);
+	};
+
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static void artpec6_l2c310_write_sec(unsigned long val, unsigned reg)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_smc(SECURE_OP_L2C_WRITEREG, reg, val, 0,
+		      0, 0, 0, 0, &res);
+
+	WARN_ON(res.a0);
+}
+
+static const char * const artpec6_dt_match[] = {
+	"axis,artpec6",
+	NULL
+};
+
+DT_MACHINE_START(ARTPEC6, "Axis ARTPEC-6 Platform")
+	.l2c_aux_val	= 0x0C000000,
+	.l2c_aux_mask	= 0xF3FFFFFF,
+	.l2c_write_sec  = artpec6_l2c310_write_sec,
+	.init_machine	= artpec6_init_machine,
+	.dt_compat	= artpec6_dt_match,
+MACHINE_END
-- 
2.1.4



From arnd at arndb.de  Thu Feb 11 06:14:56 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 15:14:56 +0100
Subject: [PATCH v2 3/8] arm: add device-tree SoC bindings for Axis Artpec-6
In-Reply-To: <0f096d1ad277cf94032ca274ced0cb35cb5d967c.1455198819.git.larper@axis.com>
References: <cover.1455198819.git.larper@axis.com>
 <0f096d1ad277cf94032ca274ced0cb35cb5d967c.1455198819.git.larper@axis.com>
Message-ID: <7242985.WgQduhPVkk@wuerfel>

On Thursday 11 February 2016 15:04:37 Lars Persson wrote:
> +
> +The DMA configuration unit muxes dma request lines between single and burst
> +alternatives.
> +
> +Required properties:
> +- compatible: axis,artpec6-dmacfg
> +- reg: Address and length of DMACFG register.
> +
> +Example:
> +       dmacfg {
> +               compatible = "axis,artpec6-dmacfg";
> +               reg = <0xf8000010 4>;
> +       };
> +


This method looks better than before, but putting a single register
into DT looks wrong. I can almost guarantee that there are more
registers at 0xf8000000-0xf8000fff (or more) that belong to either
some system controller or a DMA controller.

Whatever it is, please describe it in the DT in a sensible way based
on what the hardware does and what other resources it uses (interrupts
etc) rather than what today's kernel happens to need.

	Arnd


From ulf.hansson at linaro.org  Thu Feb 11 06:14:59 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 11 Feb 2016 15:14:59 +0100
Subject: [PATCH] MAINTAINERS: mmc: Add Adrian Hunter as the maintainer for
 SDHCI
Message-ID: <1455200099-5306-1-git-send-email-ulf.hansson@linaro.org>

>From discussions on linux-mmc I have been encouraging someone to pick
up the maintainer role for SDHCI. I am very pleased that Adrian Hunter
volunteered and accepted the challenge!

The SDHCI code is currently in quite poor quality, but we have agreed on
a way forward to try to reach a point where the SDHCI core becomes more of
a set of library functions. Each SDHCI driver variant can then decide
which functions to use and allows it to implement variant specific code,
without needing to also change SDHCI core code.

In the end we aim to get better optimized and maintainable code.

Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
---
 MAINTAINERS | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 30aca4a..5511069 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9706,10 +9706,11 @@ S:	Maintained
 F:	drivers/mmc/host/sdricoh_cs.c
 
 SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) DRIVER
+M:	Adrian Hunter <adrian.hunter at intel.com>
 L:	linux-mmc at vger.kernel.org
-S:	Orphan
-F:	drivers/mmc/host/sdhci.*
-F:	drivers/mmc/host/sdhci-pltfm.[ch]
+S:	Maintained
+F:	drivers/mmc/host/sdhci*
+F:	include/linux/mmc/sdhci*
 
 SECURE COMPUTING
 M:	Kees Cook <keescook at chromium.org>
-- 
1.9.1



From arnd at arndb.de  Thu Feb 11 06:17:30 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 15:17:30 +0100
Subject: [PATCH v2 0/8] arm: Add Artpec-6 SoC
In-Reply-To: <cover.1455198819.git.larper@axis.com>
References: <cover.1455198819.git.larper@axis.com>
Message-ID: <13460858.PmVpFaRWcp@wuerfel>

On Thursday 11 February 2016 15:04:34 Lars Persson wrote:
> Basic support for the Axis Artpec-6 ARM SoC. Timers, interrupts, UARTs and
> ethernet are wired up.
> 
> Changes since v1:
> - Corrected bindings for axis,artpec6-pll1-clock.
> - Moved the uart aliases to the board dts.
> - Kconfig cleanup.
> - Added a device tree binding for the dma configuration.
> - Added CONFIG_SYNOPSYS_DWC_ETH_QOS to multi_v7_defconfig.
> - Added binding documentation for axis,artpec6-dev-board.
> 
> Lars Persson (8):
>   clk: add device tree binding for artpec-6 pll1 clock
>   clk: add artpec-6 pll1 clock driver
>   arm: add device-tree SoC bindings for Axis Artpec-6
>   arm: dts: add Artpec-6 SoC dtsi file
>   arm: dts: add Artpec-6 development board dts
>   arm: initial machine port for artpec-6 SoC
>   arm: multi_v7_defconfig: add MACH_ARTPEC6
>   arm: mach-artpec: add entry to MAINTAINERS

Looks good except for the one issue I pointed out in patch 3 (and also 6).
Once that is resolved, please submit the new platform for inclusion by sending
it to arm at kernel.org.

The first two patches should get merged through the drivers/clk maintainer tree,
please submit them separately there.

	Arnd


From ard.biesheuvel at linaro.org  Thu Feb 11 06:19:20 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 11 Feb 2016 15:19:20 +0100
Subject: [kernel-hardening] [PATCH] arm64: vdso: Mark vDSO code as
 read-only
In-Reply-To: <1455141142-6838-1-git-send-email-david.brown@linaro.org>
References: <1455141142-6838-1-git-send-email-david.brown@linaro.org>
Message-ID: <CAKv+Gu8ArOYqxDGKb=Tv3NsiB2qWWCdD_zMx55m6+hEwLJR4CA@mail.gmail.com>

Hi David,

Nice find!

On 10 February 2016 at 22:52, David Brown <david.brown at linaro.org> wrote:
> Although the arm64 vDSO is cleanly separated by code/data with the
> code being read-only in userspace mappings, the code page is still
> writable from the kernel.  There have been exploits (such as
> http://itszn.com/blog/?p=21) that take advantage of this on x86 to go
> from a bad kernel write to full root.
>
> Prevent this specific exploit on arm64 by putting the vDSO code page
> in read-only memory as well.
>
> Before the change:
> [    3.138366] vdso: 2 pages (1 code @ ffffffc000a71000, 1 data @ ffffffc000a70000)
> ---[ Kernel Mapping ]---
> 0xffffffc000000000-0xffffffc000082000         520K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc000082000-0xffffffc000200000        1528K     ro x  SHD AF            UXN MEM/NORMAL
> 0xffffffc000200000-0xffffffc000800000           6M     ro x  SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc000800000-0xffffffc0009b6000        1752K     ro x  SHD AF            UXN MEM/NORMAL
> 0xffffffc0009b6000-0xffffffc000c00000        2344K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc000c00000-0xffffffc008000000         116M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc00c000000-0xffffffc07f000000        1840M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc800000000-0xffffffc840000000           1G     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc840000000-0xffffffc87ae00000         942M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc87ae00000-0xffffffc87ae70000         448K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87af80000-0xffffffc87af8a000          40K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87af8b000-0xffffffc87b000000         468K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87b000000-0xffffffc87fe00000          78M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc87fe00000-0xffffffc87ff50000        1344K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87ff90000-0xffffffc87ffa0000          64K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87fff0000-0xffffffc880000000          64K     RW NX SHD AF            UXN MEM/NORMAL
>
> After:
> [    3.138368] vdso: 2 pages (1 code @ ffffffc0006de000, 1 data @ ffffffc000a74000)
> ---[ Kernel Mapping ]---
> 0xffffffc000000000-0xffffffc000082000         520K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc000082000-0xffffffc000200000        1528K     ro x  SHD AF            UXN MEM/NORMAL
> 0xffffffc000200000-0xffffffc000800000           6M     ro x  SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc000800000-0xffffffc0009b8000        1760K     ro x  SHD AF            UXN MEM/NORMAL
> 0xffffffc0009b8000-0xffffffc000c00000        2336K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc000c00000-0xffffffc008000000         116M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc00c000000-0xffffffc07f000000        1840M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc800000000-0xffffffc840000000           1G     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc840000000-0xffffffc87ae00000         942M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc87ae00000-0xffffffc87ae70000         448K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87af80000-0xffffffc87af8a000          40K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87af8b000-0xffffffc87b000000         468K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87b000000-0xffffffc87fe00000          78M     RW NX SHD AF        BLK UXN MEM/NORMAL
> 0xffffffc87fe00000-0xffffffc87ff50000        1344K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87ff90000-0xffffffc87ffa0000          64K     RW NX SHD AF            UXN MEM/NORMAL
> 0xffffffc87fff0000-0xffffffc880000000          64K     RW NX SHD AF            UXN MEM/NORMAL
>
> Inspired by https://lkml.org/lkml/2016/1/19/494 based on work by the
> PaX Team, Brad Spengler, and Kees Cook.
>
> Signed-off-by: David Brown <david.brown at linaro.org>
> ---
>  arch/arm64/kernel/vdso/vdso.S | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/kernel/vdso/vdso.S b/arch/arm64/kernel/vdso/vdso.S
> index 60c1db5..db7c0f2 100644
> --- a/arch/arm64/kernel/vdso/vdso.S
> +++ b/arch/arm64/kernel/vdso/vdso.S
> @@ -24,6 +24,7 @@
>         __PAGE_ALIGNED_DATA

^^ You can get rid of this now as well

Acked-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

>
>         .globl vdso_start, vdso_end
> +       .section .rodata
>         .balign PAGE_SIZE
>  vdso_start:
>         .incbin "arch/arm64/kernel/vdso/vdso.so"
> --
> 2.7.1
>


From arnd at arndb.de  Thu Feb 11 06:23:51 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 15:23:51 +0100
Subject: [PATCH] firmware: qemu config needs I/O ports
Message-ID: <1455200650-4030091-1-git-send-email-arnd@arndb.de>

Not all machines have PCI style I/O port memory, or they do not allow
mapping it using the ioport_map() function, whcih results in a
build error with the newly added qemu firmware code:

drivers/firmware/built-in.o: In function `fw_cfg_io_cleanup':
qemu_fw_cfg.c:(.text+0x144): undefined reference to `ioport_unmap'
drivers/firmware/built-in.o: In function `fw_cfg_sysfs_probe':
qemu_fw_cfg.c:(.text+0xb18): undefined reference to `ioport_map'

This adds a Kconfig dependency to ensure the driver can only
be built on platforms that support it.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 75f3e8e47f38 ("firmware: introduce sysfs driver for QEMU's fw_cfg device")
---
 drivers/firmware/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 5130f74ae3bd..6664f1108c7c 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -164,6 +164,7 @@ config RASPBERRYPI_FIRMWARE
 config FW_CFG_SYSFS
 	tristate "QEMU fw_cfg device support in sysfs"
 	depends on SYSFS && (ARM || ARM64 || PPC_PMAC || SPARC || X86)
+	depends on HAS_IOPORT_MAP
 	default n
 	help
 	  Say Y or M here to enable the exporting of the QEMU firmware
-- 
2.7.0



From LW at KARO-electronics.de  Thu Feb 11 06:25:22 2016
From: LW at KARO-electronics.de (Lothar =?UTF-8?B?V2HDn21hbm4=?=)
Date: Thu, 11 Feb 2016 15:25:22 +0100
Subject: noise issues when recording sound on i.MX28
In-Reply-To: <20160211084029.GE13664@pengutronix.de>
References: <20160127105613.GC13664@pengutronix.de>
 <CAOMZO5BpLen517q2heramSta-R6pdESkjM6w=7FRMZebY6ue-Q@mail.gmail.com>
 <20160127144340.GD13664@pengutronix.de>
 <CAOMZO5AE6HwBYz7kOFORt0HTojJLSb0MYUbkb_HCshDHy=d27g@mail.gmail.com>
 <20160210150315.GC13664@pengutronix.de>
 <CAOMZO5D5H4F90nse9kyW9KvsJStN-sCGktup4FDPw_zTeNfS2g@mail.gmail.com>
 <20160211084029.GE13664@pengutronix.de>
Message-ID: <20160211152522.75faf7fa@ipc1.ka-ro>

Hi,

On Thu, 11 Feb 2016 09:40:29 +0100 Uwe Kleine-K?nig wrote:
> On Wed, Feb 10, 2016 at 06:10:18PM -0200, Fabio Estevam wrote:
> > Hi Uwe,
> > 
> > On Wed, Feb 10, 2016 at 1:03 PM, Uwe Kleine-K?nig
> > <u.kleine-koenig at pengutronix.de> wrote:
> > > Hello Fabio,
> > >
> > > On Tue, Feb 02, 2016 at 11:00:33AM -0200, Fabio Estevam wrote:
> > >> On Wed, Jan 27, 2016 at 12:43 PM, Uwe Kleine-K?nig
> > >> <u.kleine-koenig at pengutronix.de> wrote:
> > >>
> > >> > So you didn't hit the problem that resetting a saif didn't work, right?
> > >>
> > >> No, we haven't seen this reset issue.
> > >>
> > >> > Do you have a few more technical details here? A usecase of my machine
> > >>
> > >> Let me find out as it has been several years I worked on this problem.
> > >> Will let you know.
> > >
> > > Anything new on your end? I know from Lothar that he invested quite some
> > > time to debug his hardware setup, tested the codec instead of the i.MX28
> > > as clock provider and several more things. I also spend some time on
> > > this issue and we both hope that Freescale/NXP can help in better
> > > understanding the issue and hopefully can come up with a recipe to make
> > > concurrent recording and playback on i.MX28 work.
> > >
> > > Lothar is in contact with Freescale, too, but up to now with little
> > > success. The company I'm working for at the moment would also welcome a
> > > solution here.
> > 
> > Sorry for the delay. I have been on holidays.
> 
> I wonder who granted you to go on holidays given that we have
> problems :-)
> 
> > Can you confirm you have both SAIF interfaces being clocked from ref_pll?
> 
> root at hostname:/sys/kernel/debug/clk find -name saif?_sel
> ./ref_xtal/pll0/saif0_sel
> ./ref_xtal/pll0/saif1_sel
> 
> root at hostname:/sys/kernel/debug/clk cat ./ref_xtal/pll0/saif?_sel/clk_rate 
> 480000000
> 480000000
> 
> This is based on 3.10 (but I hope to update soon to 4.4ish). I know that
> Lothar uses 4.4. Also Lothar noticed that disabling one of these
> saif_sel clocks doesn't make an impression on the interfaces, they just
> continue to run. Maybe a clock is routed in a wrong way?
> 
That's obviously some misunderstanding.
What I observed is, that by selectively disabling and re-enabling one of
the SAIF clocks in any way (toggling the CLKGATE bit in the
CLKCTRL_SAIF# register, toggling the RUN bit in the SAIF_CTRL register
or even toggling the SLAVE_MODE bit in the SAIF_CTRL register) the SAIF
interfaces get out of sync (if they happened to be in sync in the first
place) with no way to deterministically get them in sync again.

Since the SAIF0 clock is routed to the codec, sampling the data on the
SAIF1 interface is not in sync with the data sent by the codec.

I also tried tying the BITCLK resp. LRCLK of both SAIFs together and
selecting the SAIF1 inputs as source via the SAIF_CLKMUX_SEL field in
the DIGCTL_CTRL register. Even with this setup there is no way to get
consistent data sampled on the SAIF1 interface.


Lothar Wa?mann


From gpkulkarni at gmail.com  Thu Feb 11 06:26:47 2016
From: gpkulkarni at gmail.com (Ganapatrao Kulkarni)
Date: Thu, 11 Feb 2016 19:56:47 +0530
Subject: [PATCH v4 0/6] arm64 UEFI early FDT handling
In-Reply-To: <CAFpQJXX2vGog9q=684uOMhggj3A90G8piUSV9gE5pDJm_AZeNQ@mail.gmail.com>
References: <1455026026-11571-1-git-send-email-rrichter@caviumnetworks.com>
 <CAKv+Gu-osoi53cpikDtZitJJX2gtZyhOMuvYf=cfeZi8zJ-LDg@mail.gmail.com>
 <20160211114204.GO24726@rric.localdomain>
 <CAKv+Gu-KpasM9QZ8qrZEk_pUJpf3TceaenLYTx_eAHW6AUmutA@mail.gmail.com>
 <CAFpQJXX2vGog9q=684uOMhggj3A90G8piUSV9gE5pDJm_AZeNQ@mail.gmail.com>
Message-ID: <CAFpQJXVjZodLfc4C-Rj+jxszOpQ6d9os6NqSACrvqvxDe_TvyA@mail.gmail.com>

adding RobH
(sorry, accidentally dropped Rob id in previous email)

On Thu, Feb 11, 2016 at 6:33 PM, Ganapatrao Kulkarni
<gpkulkarni at gmail.com> wrote:
> Hi Ard,
>
> On Thu, Feb 11, 2016 at 5:44 PM, Ard Biesheuvel
> <ard.biesheuvel at linaro.org> wrote:
>> On 11 February 2016 at 12:42, Robert Richter
>> <robert.richter at caviumnetworks.com> wrote:
>>> (+RobH and MarkR)
>>>
>>> On 09.02.16 15:35:42, Ard Biesheuvel wrote:
>>>> (+ Grant)
>>>>
>>>> On 9 February 2016 at 14:53, Robert Richter <rrichter at caviumnetworks.com> wrote:
>>>> > From: Robert Richter <rrichter at cavium.com>
>>>> >
>>>> > Reposting an updated version of this patches ported to 4.5-rc1. It is
>>>> > a followup to the version 3 from:
>>>> >
>>>> >  http://lkml.kernel.org/r/1442881288-13962-1-git-send-email-ard.biesheuvel at linaro.org
>>>> >
>>>> > The series is essential for NUMA on arm64. Early FDT handling is
>>>> > required to make system topology data from firmware, esp. for cpus and
>>>> > memory available to the early boot process. Ganapat's numa patches
>>>> > depend on it. This series has been tested with his series v10 posted
>>>> > here:
>>>> >
>>>> >  http://lkml.kernel.org/r/1454407763-1017-1-git-send-email-gkulkarni at caviumnetworks.com
>>>> >
>>>>
>>>> Hello Robert,
>>>>
>>>> This series does not reflect anymore what we think is the best way to
>>>> deal with memory nodes and memreserves on UEFI systems.
>>>> Please refer to this thread:
>>>> http://thread.gmane.org/gmane.linux.kernel.efi/6464
>>>>
>>>> As far as the memory nodes are concerned, if it is the best place to
>>>> store these NUMA annotations, then we should indeed preserve them, but
>>>> I think the discussion stalled without any conclusion having been
>>>> reached. As far as the /reserved-memory node is concerned, that one we
>>>> should really keep, so at least patch 6/6 of this series should be
>>>> replaced with something based on the series above.
>>>
>>> Ard,
>>>
>>> Mark R and Rob have agreed for numa dt binding for mem nodes. So do
>>> you think we can at least reuse parts of this series to solve the NUMA
>>> issue and try to find a solution for patch #6 which aligns with your
>>> alternative approach?
>>>
>>
>> OK, if we are all in agreement that NUMA annotations belong in memory
>> nodes, which are otherwise ignored completely on UEFI systems, I am
>> fine with this as well.
>>
>> However, we have to think about what it means if the memory nodes are
>> out of sync with the UEFI memory map, both on NUMA and ordinary
>> systems. I know very little about NUMA, but I could imagine that on
>> any UEFI system, the UEFI memory map remains authoritative, and memory
>> nodes are only used to annotate regions that are already known to
>> exist. Alternatively, some sanity check could be appropriate (such as
>> the one I proposed for the /reserved-memory node in the link above),
>> but we need to consider carefully how the firmware is supposed to
>> produce memory nodes and a UEFI memory map that are mutually
>> consistent.
>
> Yes memory nodes are updated at runtime from the firmware/uefi with
> actual size and
> is aligned to efi memory table.
> in NUMA patches it is taken care to fail, if memory table and memory
> nodes(also ACPI SRAT table) are not aligned.
>
> On thunderx, in uefi,  we do update memory nodes based on actual
> memory present on each
> nodes, which is not fixed on every board and varies based on number of
> DIMMs etc present on board.
>
> Same is done for ACPI SRAT table which is updated at runtime from uefi
> with actual memory size of each node.
>
> it is reasonable expectation from firmware to create/update dt or acpi
> tables at runtime for a server platform.
>
> for non-NUMA systems, dummy single node(node 0) numa system is created
> using all available memory on system.
> if kernel is compiled with CONFIG_NUMA=y and it dont have any numa bindings.
>>
>> I think we can replace 6/6 with the series above, i.e., honour the
>> allocations after establishing that the fixed allocations are either
>> still available, or entirely disjoint from what the UEFI memory map
>> describes.
>>
>> --
>> Ard.
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> thanks
> Ganapat

Ganapat


From davem at davemloft.net  Thu Feb 11 06:33:41 2016
From: davem at davemloft.net (David Miller)
Date: Thu, 11 Feb 2016 09:33:41 -0500 (EST)
Subject: [PATCH 0/6] net: thunderx: Setting IRQ affinity hints and
 other optimizations
In-Reply-To: <CA+sq2CdXHcWM=PrimSvoQ6dJyCPi0QsiiDzA5=YKKn6zHVsojg@mail.gmail.com>
References: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
 <CA+sq2CdXHcWM=PrimSvoQ6dJyCPi0QsiiDzA5=YKKn6zHVsojg@mail.gmail.com>
Message-ID: <20160211.093341.2157216466193671957.davem@davemloft.net>

From: Sunil Kovvuri <sunil.kovvuri at gmail.com>
Date: Thu, 11 Feb 2016 18:56:48 +0530

> If time permits, can you please look at this patchset.

You were given feedback and I expect you to address that feedback
and resubmit this series.

This is what the "Changed Requested" state in patchwork means.


From somlo at cmu.edu  Thu Feb 11 06:34:04 2016
From: somlo at cmu.edu (Gabriel L. Somlo)
Date: Thu, 11 Feb 2016 09:34:04 -0500
Subject: [PATCH] firmware: qemu config needs I/O ports
In-Reply-To: <1455200650-4030091-1-git-send-email-arnd@arndb.de>
References: <1455200650-4030091-1-git-send-email-arnd@arndb.de>
Message-ID: <20160211143404.GM16357@HEDWIG.INI.CMU.EDU>

On Thu, Feb 11, 2016 at 03:23:51PM +0100, Arnd Bergmann wrote:
> Not all machines have PCI style I/O port memory, or they do not allow
> mapping it using the ioport_map() function, whcih results in a
> build error with the newly added qemu firmware code:
> 
> drivers/firmware/built-in.o: In function `fw_cfg_io_cleanup':
> qemu_fw_cfg.c:(.text+0x144): undefined reference to `ioport_unmap'
> drivers/firmware/built-in.o: In function `fw_cfg_sysfs_probe':
> qemu_fw_cfg.c:(.text+0xb18): undefined reference to `ioport_map'
> 
> This adds a Kconfig dependency to ensure the driver can only
> be built on platforms that support it.

Thanks for catching this; as it turns out, an IOPORT_MAP-less machine
wasn't among the things I tried when testing the build process on
various architectures...

Acked-by: Gabriel Somlo <somlo at cmu.edu>

> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 75f3e8e47f38 ("firmware: introduce sysfs driver for QEMU's fw_cfg device")
> ---
>  drivers/firmware/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 5130f74ae3bd..6664f1108c7c 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -164,6 +164,7 @@ config RASPBERRYPI_FIRMWARE
>  config FW_CFG_SYSFS
>  	tristate "QEMU fw_cfg device support in sysfs"
>  	depends on SYSFS && (ARM || ARM64 || PPC_PMAC || SPARC || X86)
> +	depends on HAS_IOPORT_MAP
>  	default n
>  	help
>  	  Say Y or M here to enable the exporting of the QEMU firmware
> -- 
> 2.7.0
> 


From eric.auger at linaro.org  Thu Feb 11 06:34:07 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:07 +0000
Subject: [RFC v2 00/15] KVM PCIe/MSI passthrough on ARM/ARM64
Message-ID: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>

This series addresses KVM PCIe passthrough with MSI enabled on ARM/ARM64.
It pursues the efforts done on [1], [2], [3]. It also aims at covering the
same need on PowerPC platforms although the same kind of integration
should be carried out.

On x86 all accesses to the 1MB PA region [FEE0_0000h - FEF0_000h] are directed
as interrupt messages: accesses to this special PA window directly target the
APIC configuration space and not DRAM, meaning the downstream IOMMU is bypassed.

This is not the case on above mentionned platforms where MSI messages emitted
by devices are conveyed through the IOMMU. This means an IOVA/host PA mapping
must exist for the MSI to reach the MSI controller. Normal way to create
IOVA bindings consists in using VFIO DMA MAP API. However in this case
the MSI IOVA is not mapped onto guest RAM but on host physical page (the MSI
controller frame).

In a nutshell, this series does:
- introduce an IOMMU API to register a IOVA window usable for reserved mapping
- reuse VFIO DMA MAP ioctl with a new flag to plug onto that new API
- check if the device MSI-parent controllers allow IRQ remapping
  (allow unsafe interrupt modality) for a given group
- introduce a new IOMMU API to allocate reserved IOVAs and bind them onto
  a physical address
- allow the GICv2M and GICv3-ITS PCI irqchip to map/unmap the MSI frame
  on irq_write_msi_msg

Best Regards

Eric

Testing:
- functional on ARM64 AMD Overdrive HW (single GICv2m frame) with an e1000e
  PCIe card.
- tested there is no regresion on
  x non assigned PCIe driver
  x platform device passthrough
- Not tested: ARM with SR-IOV, ARM GICv3 ITS

References:
[1] [RFC 0/2] VFIO: Add virtual MSI doorbell support
    (https://lkml.org/lkml/2015/7/24/135)
[2] [RFC PATCH 0/6] vfio: Add interface to map MSI pages
    (https://lists.cs.columbia.edu/pipermail/kvmarm/2015-September/016607.html)
[3] [PATCH v2 0/3] Introduce MSI hardware mapping for VFIO
    (http://permalink.gmane.org/gmane.comp.emulators.kvm.arm.devel/3858)

Git:
https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.5-rc3-pcie-passthrough-rfcv2

previous version at
https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.5-rc1-pcie-passthrough-v1

QEMU Integration:
[RFC v2 0/8] KVM PCI/MSI passthrough with mach-virt
(http://lists.gnu.org/archive/html/qemu-arm/2016-01/msg00444.html)
https://git.linaro.org/people/eric.auger/qemu.git/shortlog/refs/heads/v2.5.0-pci-passthrough-rfc-v2

User Hints:
To allow PCI/MSI passthrough with GICv2M, compile VFIO as a module and
load the vfio_iommu_type1 module with allow_unsafe_interrupts param:
sudo modprobe -v vfio_iommu_type1 allow_unsafe_interrupts=1
sudo modprobe -v vfio-pci

History:

PATCH v1 -> RFC v2:
- reverted to RFC since it looks more reasonable ;-) the code is split
  between VFIO, IOMMU, MSI controller and I am not sure I did the right
  choices. Also API need to be further discussed.
- iova API usage in arm-smmu.c.
- MSI controller natively programs the MSI addr with either the PA or IOVA.
  This is not done anymore in vfio-pci driver as suggested by Alex.
- check irq remapping capability of the group

RFC v1 [2] -> PATCH v1:
- use the existing dma map/unmap ioctl interface with a flag to register a
  reserved IOVA range. Use the legacy Rb to store this special vfio_dma.
- a single reserved IOVA contiguous region now is allowed
- use of an RB tree indexed by PA to store allocated reserved slots
- use of a vfio_domain iova_domain to manage iova allocation within the
  window provided by the userspace
- vfio alloc_map/unmap_free take a vfio_group handle
- vfio_group handle is cached in vfio_pci_device
- add ref counting to bindings
- user modality enabled at the end of the series


Eric Auger (15):
  iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute
  vfio: expose MSI mapping requirement through VFIO_IOMMU_GET_INFO
  vfio: introduce VFIO_IOVA_RESERVED vfio_dma type
  iommu: add alloc/free_reserved_iova_domain
  iommu/arm-smmu: implement alloc/free_reserved_iova_domain
  iommu/arm-smmu: add a reserved binding RB tree
  iommu: iommu_get/put_single_reserved
  iommu/arm-smmu: implement iommu_get/put_single_reserved
  iommu/arm-smmu: relinquish reserved resources on domain deletion
  vfio: allow the user to register reserved iova range for MSI mapping
  msi: Add a new MSI_FLAG_IRQ_REMAPPING flag
  msi: export msi_get_domain_info
  vfio/type1: also check IRQ remapping capability at msi domain
  iommu/arm-smmu: do not advertise IOMMU_CAP_INTR_REMAP
  irqchip/gicv2m/v3-its-pci-msi: IOMMU map the MSI frame when needed

 drivers/iommu/arm-smmu.c                 | 292 +++++++++++++++++++++++++++++--
 drivers/iommu/fsl_pamu_domain.c          |   2 +
 drivers/iommu/iommu.c                    |  43 +++++
 drivers/irqchip/irq-gic-common.c         |  60 +++++++
 drivers/irqchip/irq-gic-common.h         |   5 +
 drivers/irqchip/irq-gic-v2m.c            |   3 +-
 drivers/irqchip/irq-gic-v3-its-pci-msi.c |   3 +-
 drivers/irqchip/irq-gic-v3-its.c         |   1 +
 drivers/vfio/vfio_iommu_type1.c          | 156 ++++++++++++++++-
 include/linux/iommu.h                    |  53 ++++++
 include/linux/msi.h                      |   6 +
 include/uapi/linux/vfio.h                |  10 ++
 kernel/irq/msi.c                         |   1 +
 13 files changed, 613 insertions(+), 22 deletions(-)

-- 
1.9.1



From eric.auger at linaro.org  Thu Feb 11 06:34:08 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:08 +0000
Subject: [RFC v2 01/15] iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute
In-Reply-To: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
References: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455201262-5259-2-git-send-email-eric.auger@linaro.org>

Introduce new DOMAIN_ATTR_MSI_MAPPING domain attribute. If supported,
this means the MSI addresses need to be mapped in the IOMMU. ARM SMMUS
and FSL PAMU, at least expose this attribute.

x86 IOMMUs typically don't expose the attribute since on x86, MSI write
transaction addresses always are within the 1MB PA region [FEE0_0000h -
FEF0_000h] window which directly targets the APIC configuration space and
hence bypass the sMMU.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan at freescale.com>
Signed-off-by: Eric Auger <eric.auger at linaro.org>

---

RFC v1 -> v1:
- the data field is not used
- for this attribute domain_get_attr simply returns 0 if the MSI_MAPPING
  capability if needed or <0 if not.
- removed struct iommu_domain_msi_maps
---
 drivers/iommu/arm-smmu.c        | 2 ++
 drivers/iommu/fsl_pamu_domain.c | 2 ++
 include/linux/iommu.h           | 1 +
 3 files changed, 5 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 59ee4b8..c8b7e71 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1409,6 +1409,8 @@ static int arm_smmu_domain_get_attr(struct iommu_domain *domain,
 	case DOMAIN_ATTR_NESTING:
 		*(int *)data = (smmu_domain->stage == ARM_SMMU_DOMAIN_NESTED);
 		return 0;
+	case DOMAIN_ATTR_MSI_MAPPING:
+		return 0;
 	default:
 		return -ENODEV;
 	}
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index da0e1e3..46d5c6a 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -856,6 +856,8 @@ static int fsl_pamu_get_domain_attr(struct iommu_domain *domain,
 	case DOMAIN_ATTR_FSL_PAMUV1:
 		*(int *)data = DOMAIN_ATTR_FSL_PAMUV1;
 		break;
+	case DOMAIN_ATTR_MSI_MAPPING:
+		break;
 	default:
 		pr_debug("Unsupported attribute type\n");
 		ret = -EINVAL;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index a5c539f..a4fe04a 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -112,6 +112,7 @@ enum iommu_attr {
 	DOMAIN_ATTR_FSL_PAMU_ENABLE,
 	DOMAIN_ATTR_FSL_PAMUV1,
 	DOMAIN_ATTR_NESTING,	/* two stages of translation */
+	DOMAIN_ATTR_MSI_MAPPING, /* Require MSIs mapping in iommu */
 	DOMAIN_ATTR_MAX,
 };
 
-- 
1.9.1



From eric.auger at linaro.org  Thu Feb 11 06:34:09 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:09 +0000
Subject: [RFC v2 02/15] vfio: expose MSI mapping requirement through
 VFIO_IOMMU_GET_INFO
In-Reply-To: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
References: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455201262-5259-3-git-send-email-eric.auger@linaro.org>

This patch allows the user-space to retrieve whether msi write
transaction addresses must be mapped. This is returned through the
VFIO_IOMMU_GET_INFO API and its new flag: VFIO_IOMMU_INFO_REQUIRE_MSI_MAP.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan at freescale.com>
Signed-off-by: Eric Auger <eric.auger at linaro.org>

---

RFC v1 -> v1:
- derived from
  [RFC PATCH 3/6] vfio: Extend iommu-info to return MSIs automap state
- renamed allow_msi_reconfig into require_msi_mapping
- fixed VFIO_IOMMU_GET_INFO
---
 drivers/vfio/vfio_iommu_type1.c | 26 ++++++++++++++++++++++++++
 include/uapi/linux/vfio.h       |  1 +
 2 files changed, 27 insertions(+)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 6f1ea3d..c5b57e1 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -255,6 +255,29 @@ static int vaddr_get_pfn(unsigned long vaddr, int prot, unsigned long *pfn)
 }
 
 /*
+ * vfio_domains_require_msi_mapping: indicates whether MSI write transaction
+ * addresses must be mapped
+ *
+ * returns true if it does
+ */
+static bool vfio_domains_require_msi_mapping(struct vfio_iommu *iommu)
+{
+	struct vfio_domain *d;
+	bool ret;
+
+	mutex_lock(&iommu->lock);
+	/* All domains have same require_msi_map property, pick first */
+	d = list_first_entry(&iommu->domain_list, struct vfio_domain, next);
+	if (iommu_domain_get_attr(d->domain, DOMAIN_ATTR_MSI_MAPPING, NULL) < 0)
+		ret = false;
+	else
+		ret = true;
+	mutex_unlock(&iommu->lock);
+
+	return ret;
+}
+
+/*
  * Attempt to pin pages.  We really don't want to track all the pfns and
  * the iommu can only map chunks of consecutive pfns anyway, so get the
  * first page and all consecutive pages with the same locking.
@@ -997,6 +1020,9 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
 
 		info.flags = VFIO_IOMMU_INFO_PGSIZES;
 
+		if (vfio_domains_require_msi_mapping(iommu))
+			info.flags |= VFIO_IOMMU_INFO_REQUIRE_MSI_MAP;
+
 		info.iova_pgsizes = vfio_pgsize_bitmap(iommu);
 
 		return copy_to_user((void __user *)arg, &info, minsz);
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 7d7a4c6..43e183b 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -400,6 +400,7 @@ struct vfio_iommu_type1_info {
 	__u32	argsz;
 	__u32	flags;
 #define VFIO_IOMMU_INFO_PGSIZES (1 << 0)	/* supported page sizes info */
+#define VFIO_IOMMU_INFO_REQUIRE_MSI_MAP (1 << 1)/* MSI must be mapped */
 	__u64	iova_pgsizes;		/* Bitmap of supported page sizes */
 };
 
-- 
1.9.1



From eric.auger at linaro.org  Thu Feb 11 06:34:10 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:10 +0000
Subject: [RFC v2 03/15] vfio: introduce VFIO_IOVA_RESERVED vfio_dma type
In-Reply-To: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
References: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455201262-5259-4-git-send-email-eric.auger@linaro.org>

We introduce a vfio_dma type since we will need to discriminate
legacy vfio_dma's from new reserved ones. Since those latter are
not mapped at registration, some treatments need to be reworked:
removal, replay. Currently they are unplugged. In subsequent patches
they will be reworked.

Signed-off-by: Eric Auger <eric.auger at linaro.org>
---
 drivers/vfio/vfio_iommu_type1.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index c5b57e1..b9326c9 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -53,6 +53,15 @@ module_param_named(disable_hugepages,
 MODULE_PARM_DESC(disable_hugepages,
 		 "Disable VFIO IOMMU support for IOMMU hugepages.");
 
+enum vfio_iova_type {
+	VFIO_IOVA_USER = 0, /* standard IOVA used to map user vaddr */
+	/*
+	 * IOVA reserved to map special host physical addresses,
+	 * MSI frames for instance
+	 */
+	VFIO_IOVA_RESERVED,
+};
+
 struct vfio_iommu {
 	struct list_head	domain_list;
 	struct mutex		lock;
@@ -75,6 +84,7 @@ struct vfio_dma {
 	unsigned long		vaddr;		/* Process virtual addr */
 	size_t			size;		/* Map size (bytes) */
 	int			prot;		/* IOMMU_READ/WRITE */
+	enum vfio_iova_type	type;		/* type of IOVA */
 };
 
 struct vfio_group {
@@ -418,7 +428,8 @@ static void vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma *dma)
 
 static void vfio_remove_dma(struct vfio_iommu *iommu, struct vfio_dma *dma)
 {
-	vfio_unmap_unpin(iommu, dma);
+	if (likely(dma->type != VFIO_IOVA_RESERVED))
+		vfio_unmap_unpin(iommu, dma);
 	vfio_unlink_dma(iommu, dma);
 	kfree(dma);
 }
@@ -694,6 +705,10 @@ static int vfio_iommu_replay(struct vfio_iommu *iommu,
 		dma_addr_t iova;
 
 		dma = rb_entry(n, struct vfio_dma, node);
+
+		if (unlikely(dma->type == VFIO_IOVA_RESERVED))
+			continue;
+
 		iova = dma->iova;
 
 		while (iova < dma->iova + dma->size) {
-- 
1.9.1



From eric.auger at linaro.org  Thu Feb 11 06:34:11 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:11 +0000
Subject: [RFC v2 04/15] iommu: add alloc/free_reserved_iova_domain
In-Reply-To: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
References: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455201262-5259-5-git-send-email-eric.auger@linaro.org>

Introduce alloc/free_reserved_iova_domain in the IOMMU API.
alloc_reserved_iova_domain initializes an iova domain at a given
iova base address and with a given size. This iova domain will
be used to allocate iova within that window. Those IOVAs will be reserved
for special purpose, typically MSI frame binding. Allocation function
within the reserved iova domain will be introduced in subsequent patches.

This is the responsability of the API user to make sure any IOVA
belonging to that domain are allocated with those allocation functions.

Signed-off-by: Eric Auger <eric.auger at linaro.org>

---

v1 -> v2:
- moved from vfio API to IOMMU API
---
 drivers/iommu/iommu.c | 22 ++++++++++++++++++++++
 include/linux/iommu.h | 21 +++++++++++++++++++++
 2 files changed, 43 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 0e3b009..a994f34 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1557,6 +1557,28 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
 }
 EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
 
+int iommu_alloc_reserved_iova_domain(struct iommu_domain *domain,
+				     dma_addr_t iova, size_t size,
+				     unsigned long order)
+{
+	int ret;
+
+	if (!domain->ops->alloc_reserved_iova_domain)
+		return -EINVAL;
+	ret = domain->ops->alloc_reserved_iova_domain(domain, iova,
+						      size, order);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_alloc_reserved_iova_domain);
+
+void iommu_free_reserved_iova_domain(struct iommu_domain *domain)
+{
+	if (!domain->ops->free_reserved_iova_domain)
+		return;
+	domain->ops->free_reserved_iova_domain(domain);
+}
+EXPORT_SYMBOL_GPL(iommu_free_reserved_iova_domain);
+
 void iommu_get_dm_regions(struct device *dev, struct list_head *list)
 {
 	const struct iommu_ops *ops = dev->bus->iommu_ops;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index a4fe04a..32c1a4e 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -195,6 +195,12 @@ struct iommu_ops {
 	int (*domain_set_windows)(struct iommu_domain *domain, u32 w_count);
 	/* Get the number of windows per domain */
 	u32 (*domain_get_windows)(struct iommu_domain *domain);
+	/* allocates the reserved iova domain */
+	int (*alloc_reserved_iova_domain)(struct iommu_domain *domain,
+					  dma_addr_t iova, size_t size,
+					  unsigned long order);
+	/* frees the reserved iova domain */
+	void (*free_reserved_iova_domain)(struct iommu_domain *domain);
 
 #ifdef CONFIG_OF_IOMMU
 	int (*of_xlate)(struct device *dev, struct of_phandle_args *args);
@@ -266,6 +272,10 @@ extern int iommu_domain_get_attr(struct iommu_domain *domain, enum iommu_attr,
 				 void *data);
 extern int iommu_domain_set_attr(struct iommu_domain *domain, enum iommu_attr,
 				 void *data);
+extern int iommu_alloc_reserved_iova_domain(struct iommu_domain *domain,
+					    dma_addr_t iova, size_t size,
+					    unsigned long order);
+extern void iommu_free_reserved_iova_domain(struct iommu_domain *domain);
 struct device *iommu_device_create(struct device *parent, void *drvdata,
 				   const struct attribute_group **groups,
 				   const char *fmt, ...) __printf(4, 5);
@@ -541,6 +551,17 @@ static inline void iommu_device_unlink(struct device *dev, struct device *link)
 {
 }
 
+static int iommu_alloc_reserved_iova_domain(struct iommu_domain *domain,
+					    dma_addr_t iova, size_t size,
+					    unsigned long order)
+{
+	return -EINVAL;
+}
+
+static void iommu_free_reserved_iova_domain(struct iommu_domain *domain)
+{
+}
+
 #endif /* CONFIG_IOMMU_API */
 
 #endif /* __LINUX_IOMMU_H */
-- 
1.9.1



From eric.auger at linaro.org  Thu Feb 11 06:34:12 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:12 +0000
Subject: [RFC v2 05/15] iommu/arm-smmu: implement
 alloc/free_reserved_iova_domain
In-Reply-To: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
References: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455201262-5259-6-git-send-email-eric.auger@linaro.org>

Implement alloc/free_reserved_iova_domain for arm-smmu. we use
the iova allocator (iova.c). The iova_domain is attached to the
arm_smmu_domain struct. A mutex is introduced to protect it.

Signed-off-by: Eric Auger <eric.auger at linaro.org>

---

v1 -> v2:
- formerly implemented in vfio_iommu_type1
---
 drivers/iommu/arm-smmu.c | 87 +++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 72 insertions(+), 15 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index c8b7e71..f42341d 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -42,6 +42,7 @@
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include <linux/iova.h>
 
 #include <linux/amba/bus.h>
 
@@ -347,6 +348,9 @@ struct arm_smmu_domain {
 	enum arm_smmu_domain_stage	stage;
 	struct mutex			init_mutex; /* Protects smmu pointer */
 	struct iommu_domain		domain;
+	struct iova_domain		*reserved_iova_domain;
+	/* protects reserved domain manipulation */
+	struct mutex			reserved_mutex;
 };
 
 static struct iommu_ops arm_smmu_ops;
@@ -975,6 +979,7 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
 		return NULL;
 
 	mutex_init(&smmu_domain->init_mutex);
+	mutex_init(&smmu_domain->reserved_mutex);
 	spin_lock_init(&smmu_domain->pgtbl_lock);
 
 	return &smmu_domain->domain;
@@ -1446,22 +1451,74 @@ out_unlock:
 	return ret;
 }
 
+static int arm_smmu_alloc_reserved_iova_domain(struct iommu_domain *domain,
+					       dma_addr_t iova, size_t size,
+					       unsigned long order)
+{
+	unsigned long granule, mask;
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	int ret = 0;
+
+	granule = 1UL << order;
+	mask = granule - 1;
+	if (iova & mask || (!size) || (size & mask))
+		return -EINVAL;
+
+	if (smmu_domain->reserved_iova_domain)
+		return -EEXIST;
+
+	mutex_lock(&smmu_domain->reserved_mutex);
+
+	smmu_domain->reserved_iova_domain =
+		kzalloc(sizeof(struct iova_domain), GFP_KERNEL);
+	if (!smmu_domain->reserved_iova_domain) {
+		ret = -ENOMEM;
+		goto unlock;
+	}
+
+	init_iova_domain(smmu_domain->reserved_iova_domain,
+			 granule, iova >> order, (iova + size - 1) >> order);
+
+unlock:
+	mutex_unlock(&smmu_domain->reserved_mutex);
+	return ret;
+}
+
+static void arm_smmu_free_reserved_iova_domain(struct iommu_domain *domain)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	struct iova_domain *iovad = smmu_domain->reserved_iova_domain;
+
+	if (!iovad)
+		return;
+
+	mutex_lock(&smmu_domain->reserved_mutex);
+
+	put_iova_domain(iovad);
+	kfree(iovad);
+
+	mutex_unlock(&smmu_domain->reserved_mutex);
+}
+
 static struct iommu_ops arm_smmu_ops = {
-	.capable		= arm_smmu_capable,
-	.domain_alloc		= arm_smmu_domain_alloc,
-	.domain_free		= arm_smmu_domain_free,
-	.attach_dev		= arm_smmu_attach_dev,
-	.detach_dev		= arm_smmu_detach_dev,
-	.map			= arm_smmu_map,
-	.unmap			= arm_smmu_unmap,
-	.map_sg			= default_iommu_map_sg,
-	.iova_to_phys		= arm_smmu_iova_to_phys,
-	.add_device		= arm_smmu_add_device,
-	.remove_device		= arm_smmu_remove_device,
-	.device_group		= arm_smmu_device_group,
-	.domain_get_attr	= arm_smmu_domain_get_attr,
-	.domain_set_attr	= arm_smmu_domain_set_attr,
-	.pgsize_bitmap		= -1UL, /* Restricted during device attach */
+	.capable			= arm_smmu_capable,
+	.domain_alloc			= arm_smmu_domain_alloc,
+	.domain_free			= arm_smmu_domain_free,
+	.attach_dev			= arm_smmu_attach_dev,
+	.detach_dev			= arm_smmu_detach_dev,
+	.map				= arm_smmu_map,
+	.unmap				= arm_smmu_unmap,
+	.map_sg				= default_iommu_map_sg,
+	.iova_to_phys			= arm_smmu_iova_to_phys,
+	.add_device			= arm_smmu_add_device,
+	.remove_device			= arm_smmu_remove_device,
+	.device_group			= arm_smmu_device_group,
+	.domain_get_attr		= arm_smmu_domain_get_attr,
+	.domain_set_attr		= arm_smmu_domain_set_attr,
+	.alloc_reserved_iova_domain	= arm_smmu_alloc_reserved_iova_domain,
+	.free_reserved_iova_domain	= arm_smmu_free_reserved_iova_domain,
+	/* Page size bitmap, restricted during device attach */
+	.pgsize_bitmap			= -1UL,
 };
 
 static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
-- 
1.9.1



From eric.auger at linaro.org  Thu Feb 11 06:34:14 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:14 +0000
Subject: [RFC v2 07/15] iommu: iommu_get/put_single_reserved
In-Reply-To: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
References: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455201262-5259-8-git-send-email-eric.auger@linaro.org>

This patch introduces iommu_get/put_single_reserved.

iommu_get_single_reserved allows to allocate a new reserved iova page
and map it onto the physical page that contains a given physical address.
It returns the iova that is mapped onto the provided physical address.
Hence the physical address passed in argument does not need to be aligned.

In case a mapping already exists between both pages, the IOVA mapped
to the PA is directly returned.

Each time an iova is successfully returned a binding ref count is
incremented.

iommu_put_single_reserved decrements the ref count and when this latter
is null, the mapping is destroyed and the iova is released.

Signed-off-by: Eric Auger <eric.auger at linaro.org>
Signed-off-by: Ankit Jindal <ajindal at apm.com>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
Signed-off-by: Bharat Bhushan <Bharat.Bhushan at freescale.com>

---

Currently the ref counting is does not really used. All bindings will be
destroyed when the domain is killed.

v1 -> v2:
- previously a VFIO API, named vfio_alloc_map/unmap_free_reserved_iova
---
 drivers/iommu/iommu.c | 21 +++++++++++++++++++++
 include/linux/iommu.h | 31 +++++++++++++++++++++++++++++++
 2 files changed, 52 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index a994f34..14ebde1 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1415,6 +1415,27 @@ size_t iommu_unmap(struct iommu_domain *domain, unsigned long iova, size_t size)
 	return unmapped;
 }
 EXPORT_SYMBOL_GPL(iommu_unmap);
+int iommu_get_single_reserved(struct iommu_domain *domain,
+			      phys_addr_t addr, int prot,
+			      dma_addr_t *iova)
+{
+	if (!domain->ops->get_single_reserved)
+		return  -ENODEV;
+
+	return domain->ops->get_single_reserved(domain, addr, prot, iova);
+
+}
+EXPORT_SYMBOL_GPL(iommu_get_single_reserved);
+
+void iommu_put_single_reserved(struct iommu_domain *domain,
+			       dma_addr_t iova)
+{
+	if (!domain->ops->put_single_reserved)
+		return;
+
+	domain->ops->put_single_reserved(domain, iova);
+}
+EXPORT_SYMBOL_GPL(iommu_put_single_reserved);
 
 size_t default_iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
 			 struct scatterlist *sg, unsigned int nents, int prot)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 32c1a4e..148465b8 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -201,6 +201,21 @@ struct iommu_ops {
 					  unsigned long order);
 	/* frees the reserved iova domain */
 	void (*free_reserved_iova_domain)(struct iommu_domain *domain);
+	/**
+	 * allocate a reserved iova page and bind it onto the page that
+	 * contains a physical address (@addr), returns the @iova bound to
+	 * @addr. In case the 2 pages already are bound simply return @iova
+	 * and increment a ref count.
+	 */
+	int (*get_single_reserved)(struct iommu_domain *domain,
+					 phys_addr_t addr, int prot,
+					 dma_addr_t *iova);
+	/**
+	 * decrement a ref count of the iova page. If null, unmap the iova page
+	 * and release the iova
+	 */
+	void (*put_single_reserved)(struct iommu_domain *domain,
+					   dma_addr_t iova);
 
 #ifdef CONFIG_OF_IOMMU
 	int (*of_xlate)(struct device *dev, struct of_phandle_args *args);
@@ -276,6 +291,11 @@ extern int iommu_alloc_reserved_iova_domain(struct iommu_domain *domain,
 					    dma_addr_t iova, size_t size,
 					    unsigned long order);
 extern void iommu_free_reserved_iova_domain(struct iommu_domain *domain);
+extern int iommu_get_single_reserved(struct iommu_domain *domain,
+				     phys_addr_t paddr, int prot,
+				     dma_addr_t *iova);
+extern void iommu_put_single_reserved(struct iommu_domain *domain,
+				      dma_addr_t iova);
 struct device *iommu_device_create(struct device *parent, void *drvdata,
 				   const struct attribute_group **groups,
 				   const char *fmt, ...) __printf(4, 5);
@@ -562,6 +582,17 @@ static void iommu_free_reserved_iova_domain(struct iommu_domain *domain)
 {
 }
 
+static int iommu_get_single_reserved(struct iommu_domain *domain,
+				     phys_addr_t paddr, int prot,
+				     dma_addr_t *iova)
+{
+	return -EINVAL;
+}
+static void iommu_put_single_reserved(struct iommu_domain *domain,
+				      dma_addr_t iova)
+{
+}
+
 #endif /* CONFIG_IOMMU_API */
 
 #endif /* __LINUX_IOMMU_H */
-- 
1.9.1



From eric.auger at linaro.org  Thu Feb 11 06:34:15 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:15 +0000
Subject: [RFC v2 08/15] iommu/arm-smmu: implement iommu_get/put_single_reserved
In-Reply-To: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
References: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455201262-5259-9-git-send-email-eric.auger@linaro.org>

Implement the iommu_get/put_single_reserved API in arm-smmu.

In order to track which physical address is already mapped we
use the RB tree indexed by PA.

Signed-off-by: Eric Auger <eric.auger at linaro.org>

---

v1 -> v2:
- previously in vfio_iommu_type1.c
---
 drivers/iommu/arm-smmu.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 114 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 729a4c6..9961bfd 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1563,6 +1563,118 @@ static void arm_smmu_free_reserved_iova_domain(struct iommu_domain *domain)
 	mutex_unlock(&smmu_domain->reserved_mutex);
 }
 
+static int arm_smmu_get_single_reserved(struct iommu_domain *domain,
+					phys_addr_t addr, int prot,
+					dma_addr_t *iova)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	unsigned long order = __ffs(domain->ops->pgsize_bitmap);
+	size_t page_size = 1 << order;
+	phys_addr_t mask = page_size - 1;
+	phys_addr_t aligned_addr = addr & ~mask;
+	phys_addr_t offset  = addr - aligned_addr;
+	struct arm_smmu_reserved_binding *b;
+	struct iova *p_iova;
+	struct iova_domain *iovad = smmu_domain->reserved_iova_domain;
+	int ret;
+
+	if (!iovad)
+		return -EINVAL;
+
+	mutex_lock(&smmu_domain->reserved_mutex);
+
+	b = find_reserved_binding(smmu_domain, aligned_addr, page_size);
+	if (b) {
+		*iova = b->iova + offset;
+		kref_get(&b->kref);
+		ret = 0;
+		goto unlock;
+	}
+
+	/* there is no existing reserved iova for this pa */
+	p_iova = alloc_iova(iovad, 1, iovad->dma_32bit_pfn, true);
+	if (!p_iova) {
+		ret = -ENOMEM;
+		goto unlock;
+	}
+	*iova = p_iova->pfn_lo << order;
+
+	b = kzalloc(sizeof(*b), GFP_KERNEL);
+	if (!b) {
+		ret = -ENOMEM;
+		goto free_iova_unlock;
+	}
+
+	ret = arm_smmu_map(domain, *iova, aligned_addr, page_size, prot);
+	if (ret)
+		goto free_binding_iova_unlock;
+
+	kref_init(&b->kref);
+	kref_get(&b->kref);
+	b->domain = smmu_domain;
+	b->addr = aligned_addr;
+	b->iova = *iova;
+	b->size = page_size;
+
+	link_reserved_binding(smmu_domain, b);
+
+	*iova += offset;
+	goto unlock;
+
+free_binding_iova_unlock:
+	kfree(b);
+free_iova_unlock:
+	free_iova(smmu_domain->reserved_iova_domain, *iova >> order);
+unlock:
+	mutex_unlock(&smmu_domain->reserved_mutex);
+	return ret;
+}
+
+/* called with reserved_mutex locked */
+static void reserved_binding_release(struct kref *kref)
+{
+	struct arm_smmu_reserved_binding *b =
+		container_of(kref, struct arm_smmu_reserved_binding, kref);
+	struct arm_smmu_domain *smmu_domain = b->domain;
+	struct iommu_domain *d = &smmu_domain->domain;
+	unsigned long order = __ffs(b->size);
+
+
+	arm_smmu_unmap(d, b->iova, b->size);
+	free_iova(smmu_domain->reserved_iova_domain, b->iova >> order);
+	unlink_reserved_binding(smmu_domain, b);
+	kfree(b);
+}
+
+static void arm_smmu_put_single_reserved(struct iommu_domain *domain,
+					 dma_addr_t iova)
+{
+	unsigned long order;
+	phys_addr_t aligned_addr;
+	dma_addr_t aligned_iova, page_size, mask, offset;
+	struct arm_smmu_reserved_binding *b;
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+
+	order = __ffs(domain->ops->pgsize_bitmap);
+	page_size = (uint64_t)1 << order;
+	mask = page_size - 1;
+
+	aligned_iova = iova & ~mask;
+	offset = iova - aligned_iova;
+
+	aligned_addr = iommu_iova_to_phys(domain, aligned_iova);
+
+	mutex_lock(&smmu_domain->reserved_mutex);
+
+	b = find_reserved_binding(smmu_domain, aligned_addr, page_size);
+	if (!b)
+		goto unlock;
+	kref_put(&b->kref, reserved_binding_release);
+
+unlock:
+	mutex_unlock(&smmu_domain->reserved_mutex);
+}
+
 static struct iommu_ops arm_smmu_ops = {
 	.capable			= arm_smmu_capable,
 	.domain_alloc			= arm_smmu_domain_alloc,
@@ -1580,6 +1692,8 @@ static struct iommu_ops arm_smmu_ops = {
 	.domain_set_attr		= arm_smmu_domain_set_attr,
 	.alloc_reserved_iova_domain	= arm_smmu_alloc_reserved_iova_domain,
 	.free_reserved_iova_domain	= arm_smmu_free_reserved_iova_domain,
+	.get_single_reserved		= arm_smmu_get_single_reserved,
+	.put_single_reserved		= arm_smmu_put_single_reserved,
 	/* Page size bitmap, restricted during device attach */
 	.pgsize_bitmap			= -1UL,
 };
-- 
1.9.1



From eric.auger at linaro.org  Thu Feb 11 06:34:13 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:13 +0000
Subject: [RFC v2 06/15] iommu/arm-smmu: add a reserved binding RB tree
In-Reply-To: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
References: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455201262-5259-7-git-send-email-eric.auger@linaro.org>

we will need to track which host physical addresses are mapped to
reserved IOVA. In that prospect we introduce a new RB tree indexed
by physical address. This RB tree only is used for reserved IOVA
bindings.

It is expected this RB tree will contain very few bindings. Those
generally correspond to single page mapping one MSI frame (GICv2m
frame or ITS GITS_TRANSLATER frame).

Signed-off-by: Eric Auger <eric.auger at linaro.org>
---
 drivers/iommu/arm-smmu.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 64 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index f42341d..729a4c6 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -349,10 +349,21 @@ struct arm_smmu_domain {
 	struct mutex			init_mutex; /* Protects smmu pointer */
 	struct iommu_domain		domain;
 	struct iova_domain		*reserved_iova_domain;
-	/* protects reserved domain manipulation */
+	/* rb tree indexed by PA, for reserved bindings only */
+	struct rb_root			reserved_binding_list;
+	/* protects reserved domain and rbtree manipulation */
 	struct mutex			reserved_mutex;
 };
 
+struct arm_smmu_reserved_binding {
+	struct kref		kref;
+	struct rb_node		node;
+	struct arm_smmu_domain	*domain;
+	phys_addr_t		addr;
+	dma_addr_t		iova;
+	size_t			size;
+};
+
 static struct iommu_ops arm_smmu_ops;
 
 static DEFINE_SPINLOCK(arm_smmu_devices_lock);
@@ -400,6 +411,57 @@ static struct device_node *dev_get_dev_node(struct device *dev)
 	return dev->of_node;
 }
 
+/* Reserved binding RB-tree manipulation */
+
+static struct arm_smmu_reserved_binding *find_reserved_binding(
+				    struct arm_smmu_domain *d,
+				    phys_addr_t start, size_t size)
+{
+	struct rb_node *node = d->reserved_binding_list.rb_node;
+
+	while (node) {
+		struct arm_smmu_reserved_binding *binding =
+			rb_entry(node, struct arm_smmu_reserved_binding, node);
+
+		if (start + size <= binding->addr)
+			node = node->rb_left;
+		else if (start >= binding->addr + binding->size)
+			node = node->rb_right;
+		else
+			return binding;
+	}
+
+	return NULL;
+}
+
+static void link_reserved_binding(struct arm_smmu_domain *d,
+				  struct arm_smmu_reserved_binding *new)
+{
+	struct rb_node **link = &d->reserved_binding_list.rb_node;
+	struct rb_node *parent = NULL;
+	struct arm_smmu_reserved_binding *binding;
+
+	while (*link) {
+		parent = *link;
+		binding = rb_entry(parent, struct arm_smmu_reserved_binding,
+				   node);
+
+		if (new->addr + new->size <= binding->addr)
+			link = &(*link)->rb_left;
+		else
+			link = &(*link)->rb_right;
+	}
+
+	rb_link_node(&new->node, parent, link);
+	rb_insert_color(&new->node, &d->reserved_binding_list);
+}
+
+static void unlink_reserved_binding(struct arm_smmu_domain *d,
+				    struct arm_smmu_reserved_binding *old)
+{
+	rb_erase(&old->node, &d->reserved_binding_list);
+}
+
 static struct arm_smmu_master *find_smmu_master(struct arm_smmu_device *smmu,
 						struct device_node *dev_node)
 {
@@ -981,6 +1043,7 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
 	mutex_init(&smmu_domain->init_mutex);
 	mutex_init(&smmu_domain->reserved_mutex);
 	spin_lock_init(&smmu_domain->pgtbl_lock);
+	smmu_domain->reserved_binding_list = RB_ROOT;
 
 	return &smmu_domain->domain;
 }
-- 
1.9.1



From eric.auger at linaro.org  Thu Feb 11 06:34:16 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:16 +0000
Subject: [RFC v2 09/15] iommu/arm-smmu: relinquish reserved resources on
 domain deletion
In-Reply-To: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
References: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455201262-5259-10-git-send-email-eric.auger@linaro.org>

arm_smmu_unmap_reserved releases all reserved binding resources:
destroy all bindings, free iova, free iova_domain. This happens
on domain deletion.

Signed-off-by: Eric Auger <eric.auger at linaro.org>
---
 drivers/iommu/arm-smmu.c | 34 +++++++++++++++++++++++++++++-----
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 9961bfd..ae8a97d 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -363,6 +363,7 @@ struct arm_smmu_reserved_binding {
 	dma_addr_t		iova;
 	size_t			size;
 };
+static void arm_smmu_unmap_reserved(struct iommu_domain *domain);
 
 static struct iommu_ops arm_smmu_ops;
 
@@ -1057,6 +1058,7 @@ static void arm_smmu_domain_free(struct iommu_domain *domain)
 	 * already been detached.
 	 */
 	arm_smmu_destroy_domain_context(domain);
+	arm_smmu_unmap_reserved(domain);
 	kfree(smmu_domain);
 }
 
@@ -1547,19 +1549,23 @@ unlock:
 	return ret;
 }
 
-static void arm_smmu_free_reserved_iova_domain(struct iommu_domain *domain)
+static void __arm_smmu_free_reserved_iova_domain(struct arm_smmu_domain *sd)
 {
-	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
-	struct iova_domain *iovad = smmu_domain->reserved_iova_domain;
+	struct iova_domain *iovad = sd->reserved_iova_domain;
 
 	if (!iovad)
 		return;
 
-	mutex_lock(&smmu_domain->reserved_mutex);
-
 	put_iova_domain(iovad);
 	kfree(iovad);
+}
 
+static void arm_smmu_free_reserved_iova_domain(struct iommu_domain *domain)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+
+	mutex_lock(&smmu_domain->reserved_mutex);
+	__arm_smmu_free_reserved_iova_domain(smmu_domain);
 	mutex_unlock(&smmu_domain->reserved_mutex);
 }
 
@@ -1675,6 +1681,24 @@ unlock:
 	mutex_unlock(&smmu_domain->reserved_mutex);
 }
 
+static void arm_smmu_unmap_reserved(struct iommu_domain *domain)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	struct rb_node *node;
+
+	mutex_lock(&smmu_domain->reserved_mutex);
+	while ((node = rb_first(&smmu_domain->reserved_binding_list))) {
+		struct arm_smmu_reserved_binding *b =
+			rb_entry(node, struct arm_smmu_reserved_binding, node);
+
+		while (!kref_put(&b->kref, reserved_binding_release))
+			;
+	}
+	smmu_domain->reserved_binding_list = RB_ROOT;
+	__arm_smmu_free_reserved_iova_domain(smmu_domain);
+	mutex_unlock(&smmu_domain->reserved_mutex);
+}
+
 static struct iommu_ops arm_smmu_ops = {
 	.capable			= arm_smmu_capable,
 	.domain_alloc			= arm_smmu_domain_alloc,
-- 
1.9.1



From eric.auger at linaro.org  Thu Feb 11 06:34:17 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:17 +0000
Subject: [RFC v2 10/15] vfio: allow the user to register reserved iova range
 for MSI mapping
In-Reply-To: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
References: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455201262-5259-11-git-send-email-eric.auger@linaro.org>

The user is allowed to register a reserved IOVA range by using the
DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA.
It provides the base address and the size. This region is stored in the
vfio_dma rb tree. At that point the iova range is not mapped to any target
address yet. The host kernel will use those iova when needed, typically
when the VFIO-PCI device allocates its MSI's.

This patch also handles the destruction of the reserved binding RB-tree and
domain's iova_domains.

Signed-off-by: Eric Auger <eric.auger at linaro.org>
Signed-off-by: Bharat Bhushan <Bharat.Bhushan at freescale.com>

---

v1 -> v2:
- set returned value according to alloc_reserved_iova_domain result
- free the iova domains in case any error occurs

RFC v1 -> v1:
- takes into account Alex comments, based on
  [RFC PATCH 1/6] vfio: Add interface for add/del reserved iova region:
- use the existing dma map/unmap ioctl interface with a flag to register
  a reserved IOVA range. A single reserved iova region is allowed.
---
 drivers/vfio/vfio_iommu_type1.c | 75 ++++++++++++++++++++++++++++++++++++++++-
 include/uapi/linux/vfio.h       |  9 +++++
 2 files changed, 83 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index b9326c9..c5d3b48 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -673,6 +673,75 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,
 	return ret;
 }
 
+static int vfio_register_reserved_iova_range(struct vfio_iommu *iommu,
+			   struct vfio_iommu_type1_dma_map *map)
+{
+	dma_addr_t iova = map->iova;
+	size_t size = map->size;
+	uint64_t mask;
+	struct vfio_dma *dma;
+	int ret = 0;
+	struct vfio_domain *d;
+	unsigned long order;
+
+	/* Verify that none of our __u64 fields overflow */
+	if (map->size != size || map->iova != iova)
+		return -EINVAL;
+
+	order =  __ffs(vfio_pgsize_bitmap(iommu));
+	mask = ((uint64_t)1 << order) - 1;
+
+	WARN_ON(mask & PAGE_MASK);
+
+	/* we currently only support MSI_RESERVED_IOVA */
+	if (!(map->flags & VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA))
+		return -EINVAL;
+
+	if (!size || (size | iova) & mask)
+		return -EINVAL;
+
+	/* Don't allow IOVA address wrap */
+	if (iova + size - 1 < iova)
+		return -EINVAL;
+
+	mutex_lock(&iommu->lock);
+
+	/* check if the iova domain has not been instantiated already*/
+	d = list_first_entry(&iommu->domain_list,
+				  struct vfio_domain, next);
+
+	if (vfio_find_dma(iommu, iova, size)) {
+		ret =  -EEXIST;
+		goto out;
+	}
+
+	dma = kzalloc(sizeof(*dma), GFP_KERNEL);
+	if (!dma) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	dma->iova = iova;
+	dma->size = size;
+	dma->type = VFIO_IOVA_RESERVED;
+
+	list_for_each_entry(d, &iommu->domain_list, next)
+		ret |= iommu_alloc_reserved_iova_domain(d->domain, iova,
+							size, order);
+
+	if (ret) {
+		list_for_each_entry(d, &iommu->domain_list, next)
+			iommu_free_reserved_iova_domain(d->domain);
+		goto out;
+	}
+
+	vfio_link_dma(iommu, dma);
+
+out:
+	mutex_unlock(&iommu->lock);
+	return ret;
+}
+
 static int vfio_bus_type(struct device *dev, void *data)
 {
 	struct bus_type **bus = data;
@@ -1045,7 +1114,8 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
 	} else if (cmd == VFIO_IOMMU_MAP_DMA) {
 		struct vfio_iommu_type1_dma_map map;
 		uint32_t mask = VFIO_DMA_MAP_FLAG_READ |
-				VFIO_DMA_MAP_FLAG_WRITE;
+				VFIO_DMA_MAP_FLAG_WRITE |
+				VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA;
 
 		minsz = offsetofend(struct vfio_iommu_type1_dma_map, size);
 
@@ -1055,6 +1125,9 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
 		if (map.argsz < minsz || map.flags & ~mask)
 			return -EINVAL;
 
+		if (map.flags & VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA)
+			return vfio_register_reserved_iova_range(iommu, &map);
+
 		return vfio_dma_do_map(iommu, &map);
 
 	} else if (cmd == VFIO_IOMMU_UNMAP_DMA) {
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 43e183b..982e326 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -411,12 +411,21 @@ struct vfio_iommu_type1_info {
  *
  * Map process virtual addresses to IO virtual addresses using the
  * provided struct vfio_dma_map. Caller sets argsz. READ &/ WRITE required.
+ *
+ * In case MSI_RESERVED_IOVA is set, the API only aims at registering an IOVA
+ * region which will be used on some platforms to map the host MSI frame.
+ * in that specific case, vaddr and prot are ignored. The requirement for
+ * provisioning such IOVA range can be checked by calling VFIO_IOMMU_GET_INFO
+ * with the VFIO_IOMMU_INFO_REQUIRE_MSI_MAP attribute. A single
+ * MSI_RESERVED_IOVA region can be registered
  */
 struct vfio_iommu_type1_dma_map {
 	__u32	argsz;
 	__u32	flags;
 #define VFIO_DMA_MAP_FLAG_READ (1 << 0)		/* readable from device */
 #define VFIO_DMA_MAP_FLAG_WRITE (1 << 1)	/* writable from device */
+/* reserved iova for MSI vectors*/
+#define VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA (1 << 2)
 	__u64	vaddr;				/* Process virtual address */
 	__u64	iova;				/* IO virtual address */
 	__u64	size;				/* Size of mapping (bytes) */
-- 
1.9.1



From eric.auger at linaro.org  Thu Feb 11 06:34:18 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:18 +0000
Subject: [RFC v2 11/15] msi: Add a new MSI_FLAG_IRQ_REMAPPING flag
In-Reply-To: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
References: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455201262-5259-12-git-send-email-eric.auger@linaro.org>

Let's introduce a new msi_domain_info flag value, MSI_FLAG_IRQ_REMAPPING
meant to tell the domain supports IRQ REMAPPING, also known as Interrupt
Translation Service. On Intel HW this capability is abstracted on IOMMU
side while on ARM it is abstracted on MSI controller side.

GICv3 ITS HW is the first HW advertising that feature.

Signed-off-by: Eric Auger <eric.auger at linaro.org>
---
 drivers/irqchip/irq-gic-v3-its.c | 1 +
 include/linux/msi.h              | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 3447549..a5e0d8b 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1544,6 +1544,7 @@ static int its_probe(struct device_node *node, struct irq_domain *parent)
 		inner_domain->parent = parent;
 		inner_domain->bus_token = DOMAIN_BUS_NEXUS;
 		info->ops = &its_msi_domain_ops;
+		info->flags |= MSI_FLAG_IRQ_REMAPPING;
 		info->data = its;
 		inner_domain->host_data = info;
 	}
diff --git a/include/linux/msi.h b/include/linux/msi.h
index a2a0068..03eda72 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -261,6 +261,8 @@ enum {
 	MSI_FLAG_MULTI_PCI_MSI		= (1 << 3),
 	/* Support PCI MSIX interrupts */
 	MSI_FLAG_PCI_MSIX		= (1 << 4),
+	/* Support MSI IRQ remapping service */
+	MSI_FLAG_IRQ_REMAPPING		= (1 << 5),
 };
 
 int msi_domain_set_affinity(struct irq_data *data, const struct cpumask *mask,
-- 
1.9.1



From eric.auger at linaro.org  Thu Feb 11 06:34:19 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:19 +0000
Subject: [RFC v2 12/15] msi: export msi_get_domain_info
In-Reply-To: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
References: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455201262-5259-13-git-send-email-eric.auger@linaro.org>

We plan to use msi_get_domain_info in VFIO module so let's export it.

Signed-off-by: Eric Auger <eric.auger at linaro.org>
---
 include/linux/msi.h | 4 ++++
 kernel/irq/msi.c    | 1 +
 2 files changed, 5 insertions(+)

diff --git a/include/linux/msi.h b/include/linux/msi.h
index 03eda72..df19315 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -323,6 +323,10 @@ static inline struct irq_domain *pci_msi_get_device_domain(struct pci_dev *pdev)
 {
 	return NULL;
 }
+static struct msi_domain_info *msi_get_domain_info(struct irq_domain *domain)
+{
+	return NULL;
+}
 #endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
 
 #endif /* LINUX_MSI_H */
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 38e89ce..9b0ba4a 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -400,5 +400,6 @@ struct msi_domain_info *msi_get_domain_info(struct irq_domain *domain)
 {
 	return (struct msi_domain_info *)domain->host_data;
 }
+EXPORT_SYMBOL_GPL(msi_get_domain_info);
 
 #endif /* CONFIG_GENERIC_MSI_IRQ_DOMAIN */
-- 
1.9.1



From eric.auger at linaro.org  Thu Feb 11 06:34:21 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:21 +0000
Subject: [RFC v2 14/15] iommu/arm-smmu: do not advertise IOMMU_CAP_INTR_REMAP
In-Reply-To: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
References: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455201262-5259-15-git-send-email-eric.auger@linaro.org>

Do not advertise IOMMU_CAP_INTR_REMAP for arm-smmu. Indeed the
irq_remapping capability is abstracted on irqchip side for ARM as
opposed to Intel IOMMU featuring IRQ remapping HW.

So to check IRQ remmapping capability, the msi domain needs to be
checked instead.

Signed-off-by: Eric Auger <eric.auger at linaro.org>
---
 drivers/iommu/arm-smmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index ae8a97d..9a83285 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1354,7 +1354,7 @@ static bool arm_smmu_capable(enum iommu_cap cap)
 		 */
 		return true;
 	case IOMMU_CAP_INTR_REMAP:
-		return true; /* MSIs are just memory writes */
+		return false; /* MSIs are just memory writes */
 	case IOMMU_CAP_NOEXEC:
 		return true;
 	default:
-- 
1.9.1



From eric.auger at linaro.org  Thu Feb 11 06:34:20 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:20 +0000
Subject: [RFC v2 13/15] vfio/type1: also check IRQ remapping capability at msi
 domain
In-Reply-To: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
References: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455201262-5259-14-git-send-email-eric.auger@linaro.org>

On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted
by the msi controller. vfio_msi_parent_irq_remapping_capable allows to
check whether interrupts are "safe" for a given device. There are if the device
does not use MSI or if the device uses MSI and the msi-parent controller
supports IRQ remapping.

Then we check at group level if all devices have safe interrupts: if not
only allow the group to be attached if allow_unsafe_interrupts is set.

At this point ARM sMMU still advertises IOMMU_CAP_INTR_REMAP. This is
changed in next patch.

Signed-off-by: Eric Auger <eric.auger at linaro.org>
---
 drivers/vfio/vfio_iommu_type1.c | 38 ++++++++++++++++++++++++++++++++++++--
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index c5d3b48..080321b 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -36,6 +36,8 @@
 #include <linux/uaccess.h>
 #include <linux/vfio.h>
 #include <linux/workqueue.h>
+#include <linux/irqdomain.h>
+#include <linux/msi.h>
 
 #define DRIVER_VERSION  "0.2"
 #define DRIVER_AUTHOR   "Alex Williamson <alex.williamson at redhat.com>"
@@ -754,6 +756,31 @@ static int vfio_bus_type(struct device *dev, void *data)
 	return 0;
 }
 
+/**
+ * vfio_msi_parent_irq_remapping_capable: returns whether the device msi-parent
+ * controller supports IRQ remapping, aka interrupt translation
+ *
+ * @dev: device handle
+ * @data: unused
+ * returns 0 if irq remapping is supported or -1 if not supported.
+ */
+static int vfio_msi_parent_irq_remapping_capable(struct device *dev, void *data)
+{
+	struct irq_domain *domain;
+	struct msi_domain_info *info;
+
+	domain = dev_get_msi_domain(dev);
+	if (!domain)
+		return 0;
+
+	info = msi_get_domain_info(domain);
+
+	if (!(info->flags & MSI_FLAG_IRQ_REMAPPING))
+		return -1;
+
+	return 0;
+}
+
 static int vfio_iommu_replay(struct vfio_iommu *iommu,
 			     struct vfio_domain *domain)
 {
@@ -848,7 +875,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
 	struct vfio_group *group, *g;
 	struct vfio_domain *domain, *d;
 	struct bus_type *bus = NULL;
-	int ret;
+	int ret, irq_remapping;
 
 	mutex_lock(&iommu->lock);
 
@@ -871,6 +898,13 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
 
 	group->iommu_group = iommu_group;
 
+	/*
+	 * Determine if all the devices of the group has an MSI-parent that
+	 * supports irq remapping
+	 */
+	irq_remapping = !iommu_group_for_each_dev(iommu_group, &bus,
+				       vfio_msi_parent_irq_remapping_capable);
+
 	/* Determine bus_type in order to allocate a domain */
 	ret = iommu_group_for_each_dev(iommu_group, &bus, vfio_bus_type);
 	if (ret)
@@ -899,7 +933,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
 	list_add(&group->next, &domain->group_list);
 
 	if (!allow_unsafe_interrupts &&
-	    !iommu_capable(bus, IOMMU_CAP_INTR_REMAP)) {
+	    (!iommu_capable(bus, IOMMU_CAP_INTR_REMAP) && !irq_remapping)) {
 		pr_warn("%s: No interrupt remapping support.  Use the module param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this platform\n",
 		       __func__);
 		ret = -EPERM;
-- 
1.9.1



From eric.auger at linaro.org  Thu Feb 11 06:34:22 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 11 Feb 2016 14:34:22 +0000
Subject: [RFC v2 15/15] irqchip/gicv2m/v3-its-pci-msi: IOMMU map the MSI frame
 when needed
In-Reply-To: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
References: <1455201262-5259-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455201262-5259-16-git-send-email-eric.auger@linaro.org>

In case the msi_desc references a device attached to an iommu
domain, the msi address needs to be mapped in the IOMMU. Else any
MSI write transaction will cause a fault.

gic_set_msi_addr detects that case and allocates an iova bound
to the physical address page comprising the MSI frame. This iova
then is used as the msi_msg address. Unset operation decrements the
reference on the binding.

The functions are called in the irq_write_msi_msg ops implementation.
At that time we can recognize whether the msi is setup or teared down
looking at the msi_msg content. Indeed msi_domain_deactivate zeroes all
the fields.

Signed-off-by: Eric Auger <eric.auger at linaro.org>
---
 drivers/irqchip/irq-gic-common.c         | 60 ++++++++++++++++++++++++++++++++
 drivers/irqchip/irq-gic-common.h         |  5 +++
 drivers/irqchip/irq-gic-v2m.c            |  3 +-
 drivers/irqchip/irq-gic-v3-its-pci-msi.c |  3 +-
 4 files changed, 69 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
index f174ce0..690802b 100644
--- a/drivers/irqchip/irq-gic-common.c
+++ b/drivers/irqchip/irq-gic-common.c
@@ -18,6 +18,8 @@
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/irqchip/arm-gic.h>
+#include <linux/iommu.h>
+#include <linux/msi.h>
 
 #include "irq-gic-common.h"
 
@@ -121,3 +123,61 @@ void gic_cpu_config(void __iomem *base, void (*sync_access)(void))
 	if (sync_access)
 		sync_access();
 }
+
+int gic_set_msi_addr(struct irq_data *data, struct msi_msg *msg)
+{
+	struct msi_desc *desc = irq_data_get_msi_desc(data);
+	struct device *dev = msi_desc_to_dev(desc);
+	struct iommu_domain *d;
+	phys_addr_t addr;
+	dma_addr_t iova;
+	int ret;
+
+	d = iommu_get_domain_for_dev(dev);
+	if (!d)
+		return 0;
+
+	addr = ((phys_addr_t)(msg->address_hi) << 32) |
+		msg->address_lo;
+
+	ret = iommu_get_single_reserved(d, addr, IOMMU_WRITE, &iova);
+
+	if (!ret) {
+		msg->address_lo = lower_32_bits(iova);
+		msg->address_hi = upper_32_bits(iova);
+	}
+	return ret;
+}
+
+
+void gic_unset_msi_addr(struct irq_data *data)
+{
+	struct msi_desc *desc = irq_data_get_msi_desc(data);
+	struct device *dev;
+	struct iommu_domain *d;
+	dma_addr_t iova;
+
+	iova = ((dma_addr_t)(desc->msg.address_hi) << 32) |
+		desc->msg.address_lo;
+
+	dev = msi_desc_to_dev(desc);
+	if (!dev)
+		return;
+
+	d = iommu_get_domain_for_dev(dev);
+	if (!d)
+		return;
+
+	iommu_put_single_reserved(d, iova);
+}
+
+void gic_pci_msi_domain_write_msg(struct irq_data *irq_data,
+				  struct msi_msg *msg)
+{
+	if (!msg->address_hi && !msg->address_lo && !msg->data)
+		gic_unset_msi_addr(irq_data); /* deactivate */
+	else
+		gic_set_msi_addr(irq_data, msg); /* activate, set_affinity */
+
+	pci_msi_domain_write_msg(irq_data, msg);
+}
diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
index fff697d..e99e321 100644
--- a/drivers/irqchip/irq-gic-common.h
+++ b/drivers/irqchip/irq-gic-common.h
@@ -35,4 +35,9 @@ void gic_cpu_config(void __iomem *base, void (*sync_access)(void));
 void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
 		void *data);
 
+int gic_set_msi_addr(struct irq_data *data, struct msi_msg *msg);
+void gic_unset_msi_addr(struct irq_data *data);
+void gic_pci_msi_domain_write_msg(struct irq_data *irq_data,
+				  struct msi_msg *msg);
+
 #endif /* _IRQ_GIC_COMMON_H */
diff --git a/drivers/irqchip/irq-gic-v2m.c b/drivers/irqchip/irq-gic-v2m.c
index c779f83..5d7b89f 100644
--- a/drivers/irqchip/irq-gic-v2m.c
+++ b/drivers/irqchip/irq-gic-v2m.c
@@ -24,6 +24,7 @@
 #include <linux/of_pci.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include "irq-gic-common.h"
 
 /*
 * MSI_TYPER:
@@ -83,7 +84,7 @@ static struct irq_chip gicv2m_msi_irq_chip = {
 	.irq_mask		= gicv2m_mask_msi_irq,
 	.irq_unmask		= gicv2m_unmask_msi_irq,
 	.irq_eoi		= irq_chip_eoi_parent,
-	.irq_write_msi_msg	= pci_msi_domain_write_msg,
+	.irq_write_msi_msg	= gic_pci_msi_domain_write_msg,
 };
 
 static struct msi_domain_info gicv2m_msi_domain_info = {
diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index aee60ed..6d5cbce 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -19,6 +19,7 @@
 #include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/of_pci.h>
+#include "irq-gic-common.h"
 
 static void its_mask_msi_irq(struct irq_data *d)
 {
@@ -37,7 +38,7 @@ static struct irq_chip its_msi_irq_chip = {
 	.irq_unmask		= its_unmask_msi_irq,
 	.irq_mask		= its_mask_msi_irq,
 	.irq_eoi		= irq_chip_eoi_parent,
-	.irq_write_msi_msg	= pci_msi_domain_write_msg,
+	.irq_write_msi_msg	= gic_pci_msi_domain_write_msg,
 };
 
 struct its_pci_alias {
-- 
1.9.1



From ezequiel at vanguardiasur.com.ar  Thu Feb 11 06:38:07 2016
From: ezequiel at vanguardiasur.com.ar (Ezequiel Garcia)
Date: Thu, 11 Feb 2016 11:38:07 -0300
Subject: net: mv643xx: interface does not transmit after some time
In-Reply-To: <20160210225717.GD14610@lunn.ch>
References: <E4F9E0D0-9DA8-4E33-9F89-B49E47F11CE0@schloeter.net>
 <20160206183414.GD17218@lunn.ch>
 <20160206231935.GA30734@jirafa.cyrius.com>
 <2ACB3A0B-DD51-43C1-A56E-E7C175645554@schloeter.net>
 <20160207203545.GB29107@lunn.ch>
 <A21B89D4-5826-4F97-A1C9-E62E5B724082@schloeter.net>
 <312E318A-CAE1-45B1-AB13-EA147B48E315@schloeter.net>
 <A6128DBC-59DB-4231-A08D-B84C1D8C26CC@schloeter.net>
 <20160210225717.GD14610@lunn.ch>
Message-ID: <CAAEAJfBFNEPRd+AaKpRAh6sKFJ=trO+mAD_DAAj3dzhAbbreqg@mail.gmail.com>

(let's expand the Cc a bit)

On 10 February 2016 at 19:57, Andrew Lunn <andrew at lunn.ch> wrote:
> On Wed, Feb 10, 2016 at 07:40:54PM +0100, Thomas Schl?ter wrote:
>>
>> > Am 08.02.2016 um 19:49 schrieb Thomas Schl?ter <thomas at schloeter.net>:
>> >
>> >
>> >> Am 07.02.2016 um 22:07 schrieb Thomas Schl?ter <thomas at schloeter.net>:
>> >>
>> >> Am 07.02.2016 um 21:35 schrieb Andrew Lunn <andrew at lunn.ch>:
>> >>>
>> >>>>> FWIW, we had a similar bug report in Debian recently:
>> >>>>> https://lists.debian.org/debian-arm/2016/01/msg00098.html
>> >>>
>> >>> Hi Thomas
>> >>>
>> >>> I this thread, Ian Campbell mentions a patch. Please could you try
>> >>> that patch and see if it fixes your problem.
>> >>>
>> >>> Thanks
>> >>>   Andrew
>> >>
>> >> Hi Andrew,
>> >>
>> >> I just applied the patch and the NAS is now running it. I???ll try to crash it tonight and keep you informed whether it worked.
>> >>
>> >> Thanks
>> >>    Thomas
>> >
>> > Hi Andrew,
>> >
>> > the patch did not fix the problem. After 1.2 GiB RX and 950 MiB TX, the interface crashed again.
>> >
>> > Now I switched off RX/TX offload just to make sure we are talking about the same problem. If we are, the interface should be stable without offload, right?
>> >
>> >     Thomas
>>
>> Okay, so I have installed ethtool and switched off all offload features available. Now the NAS is running rock solid for two days. I backed up my Mac using Time Machine / netatalk (450 GiB transferred) and some Linux machines via NFS (100 GiB total) without a problem.
>>
>> How much code is used for mv643xx offload functionality?
>> Is it possible to debug things in the driver and figure out what happens during the crash?
>> Is the hardware offload interface proprietary or reverse engineered or is it a well known API that can be analyzed?
>
> Hi Thomas
>
> Ezequiel Garcia probably knows this part of the driver and hardware
> the best...
>

The TCP segmentation offload (TSO) implemented in this driver is
mostly a software thing.

I'm CCing Karl and Philipp, who have fixed subtle issues in the TSO
path, and may be able to help figure this one out.

-- 
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar


From will.deacon at arm.com  Thu Feb 11 06:40:24 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 11 Feb 2016 14:40:24 +0000
Subject: [PATCH v2 0/2] Misc ARM optimizations
In-Reply-To: <1453980229-5678-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1453980229-5678-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20160211144023.GI32084@arm.com>

On Thu, Jan 28, 2016 at 12:23:47PM +0100, Thomas Petazzoni wrote:
> Here is a set of two patches that I already sent on March 2015 (first
> patch) and June 2015 (second patch).
> 
> The first patch hasn't gotten any feedback.
> 
> The second patch received some feedback: Russell said he would like
> this to be merged at the beginning of a cycle, to give it enough time
> for testing. And we are precisely at the beginning of a cycle :-) Rob
> Herring had some comments, which I also addressed in a reply.
> 
> Would it be possible to either get those patches merged, or a decision
> be taken that they are not acceptable, so that I can stop worrying
> about them ? :-)

There's a PL310 erratum [(729806) Speculative reads from the Cortex-A9
MPCore processor can cause deadlock] that requires both speculative
linefills and L1 prefetch to be disabled, otherwise there is scope for
deadlock.

So, these need to be predicated on a Kconfig option if nothing else,
otherwise we may run into nasty regressions on things like OMAP4 (and
anything else with PL310 r3p0 afaict).

Will


From christoffer.dall at linaro.org  Thu Feb 11 06:41:21 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Thu, 11 Feb 2016 15:41:21 +0100
Subject: [PATCH] arm64: KVM: Configure TCR_EL2.PS at runtime
In-Reply-To: <56BC92C1.8060201@arm.com>
References: <1455130013-28644-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160211132708.GU5171@cbox> <20160211133401.GV5171@cbox>
 <56BC92C1.8060201@arm.com>
Message-ID: <20160211144121.GA5750@cbox>

On Thu, Feb 11, 2016 at 01:55:13PM +0000, Marc Zyngier wrote:
> On 11/02/16 13:34, Christoffer Dall wrote:
> > On Thu, Feb 11, 2016 at 02:27:08PM +0100, Christoffer Dall wrote:
> >> On Wed, Feb 10, 2016 at 10:46:53AM -0800, tchalamarla at caviumnetworks.com wrote:
> >>> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> >>>
> >>> Setting TCR_EL2.PS to 40 bits is wrong on systems with PS size is
> >>> less than 40 bits. and with systems where RAM is at higher address,
> >>> this will break KVM.
> >>>
> >>> This patch sets TCR_EL2.PS at runtime similar to VTCR_EL2.PS
> >>>
> >>> changes form V2:
> >>> 	- Modified subject line and commit message.
> >>> 	- Removed TCR_EL2_FLAGS.
> >>>
> >>> changes from V1:
> >>>         - Moved to dynamic configuration.
> >>>
> >>> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> >>> ---
> >>>  arch/arm64/include/asm/kvm_arm.h |  2 --
> >>>  arch/arm64/kvm/hyp-init.S        | 12 +++++++-----
> >>>  2 files changed, 7 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> >>> index 738a95f..3776db0 100644
> >>> --- a/arch/arm64/include/asm/kvm_arm.h
> >>> +++ b/arch/arm64/include/asm/kvm_arm.h
> >>> @@ -107,8 +107,6 @@
> >>>  #define TCR_EL2_MASK	(TCR_EL2_TG0 | TCR_EL2_SH0 | \
> >>>  			 TCR_EL2_ORGN0 | TCR_EL2_IRGN0 | TCR_EL2_T0SZ)
> >>>  
> >>> -#define TCR_EL2_FLAGS	(TCR_EL2_RES1 | TCR_EL2_PS_40B)
> >>> -
> >>>  /* VTCR_EL2 Registers bits */
> >>>  #define VTCR_EL2_RES1		(1 << 31)
> >>>  #define VTCR_EL2_PS_MASK	(7 << 16)
> >>> diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
> >>> index 3e568dc..b5ab1b0 100644
> >>> --- a/arch/arm64/kvm/hyp-init.S
> >>> +++ b/arch/arm64/kvm/hyp-init.S
> >>> @@ -64,7 +64,7 @@ __do_hyp_init:
> >>>  	mrs	x4, tcr_el1
> >>>  	ldr	x5, =TCR_EL2_MASK
> >>>  	and	x4, x4, x5
> >>> -	ldr	x5, =TCR_EL2_FLAGS
> >>> +	ldr	x5, =TCR_EL2_RES1
> >>>  	orr	x4, x4, x5
> >>>  
> >>>  #ifndef CONFIG_ARM64_VA_BITS_48
> >>> @@ -85,15 +85,17 @@ __do_hyp_init:
> >>>  	ldr_l	x5, idmap_t0sz
> >>>  	bfi	x4, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH
> >>>  #endif
> >>> -	msr	tcr_el2, x4
> >>> -
> >>> -	ldr	x4, =VTCR_EL2_FLAGS
> >>>  	/*
> >>>  	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
> >>> -	 * VTCR_EL2.
> >>> +	 * TCR_EL2 and VTCR_EL2.
> >>>  	 */
> >>>  	mrs	x5, ID_AA64MMFR0_EL1
> >>>  	bfi	x4, x5, #16, #3
> >>> +
> >>> +	msr	tcr_el2, x4
> >>> +
> >>> +	ldr	x4, =VTCR_EL2_FLAGS
> >>> +	bfi	x4, x5, #16, #3
> >>>  	/*
> >>>  	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS bit in
> >>>  	 * VTCR_EL2.
> >>> -- 
> >>> 2.1.0
> >>>
> >>
> >> This looks reasonable enough for me.  Did we limit Linux to PS=40 bits
> >> in the past and have lifted this restriction, or why did we have this
> >> limitation for EL2 translations in the past?
> >>
> > Hmm, just went back and looked at my comments [1] on Suzuki's 16K page
> > series, and regarding our stage-2 page table configuration I wrote this:
> > 
> > <quote>
> > ... the constraints of
> > this whole thing is, and make sure we agree on this:
> > 
> > 1. We fix the IPA max width to 40 bits
> > 2. We don't support systems with a PARange smaller than 40 bits (do we
> >    check this anywhere or document this anywhere?)
> >    3. We always assume we are running on a system with PARange of 40
> >    bits
> >       and we are therefore constrained to use concatination.
> > </quote>
> > 
> > So this change is actually making a bit nervous...  Marc, did you check
> > if all the stuff in arch/arm64/include/asm/kvm_mmu.h still holds after
> > we relax this?
> 
> I believe this still works for the following reasons:
> 
> - This only affects the output address of EL2 Stage-1, and basically
> only allows EL2 to reach the same memory as the rest of the host kernel.
> 
> - Stage-2 translation already does the same thing, for similar reasons.
> 
> - We enforce 40bit IPA by not providing page tables above 40 bits (by
> setting T0SZ to 64-40=24). This has the effect of denying accesses above
> 40bit IPA to the guest.
> 
> So I'm quite confident that we're safe here.
> 
> Thoughts?
> 

This patch is indeed harmless as it only touches the EL2 translation
regime to be in line with the rest of the kernel, so we can merge this
patch.

I'm more concerned about the assumptions we had for the Stage-2 page
table not being valid anymore and therefore deserving a second look.

But we can have a review of that whole thing some other day.

Thanks,
-Christoffer


From ard.biesheuvel at linaro.org  Thu Feb 11 06:41:21 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 11 Feb 2016 15:41:21 +0100
Subject: [PATCH] arm64: defer __va() translations of initrd_start and
 initrd_end
Message-ID: <1455201681-29972-1-git-send-email-ard.biesheuvel@linaro.org>

Commit 66f51676a095 ("arm64: allow kernel Image to be loaded anywhere in
physical memory") defers the assignment of memstart_addr to the point where
all memory has been discovered and possibly clipped based on the size of
the linear region and the presence of a mem= command line parameter.

However, this results in __va() translations that have been performed up
to this point to have been carried out with a preliminary, incorrect value
of memstart_addr, and these values need to be fixed up.

To make this more transparent, change the initial value of memstart_addr to
PAGE_OFFSET so that __va() translations are effectively identity functions,
and fix up the values of initrd_start and initrd_end before use.

Tested-by: Laurentiu Tudor <laurentiu.tudor at nxp.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---

This is the least ugly way to address this issue in the short term (since the
offending patch is already in -next). The preferred way of dealing with this
would be to parametrise early_init_dt_check_for_initrd() in such a way that
we can decide per-arch whether it should perform the __va() translation or
not. If this is the preferred approach also for the short term, I am happy
to code that up as well.

 arch/arm64/mm/init.c | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 3a9fc46cbf80..bb53236e54d9 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -48,7 +48,13 @@
 
 #include "mm.h"
 
-phys_addr_t memstart_addr __read_mostly = 0;
+/*
+ * Initialize memstart_addr to PAGE_OFFSET so that __va() translations
+ * performed before arm64_memblock_init() executes (i.e., assignments
+ * of initrd_start and initrd_end in the early FDT parsing code) are
+ * effectively identity functions.
+ */
+phys_addr_t memstart_addr __read_mostly = PAGE_OFFSET;
 phys_addr_t arm64_dma_phys_limit __read_mostly;
 
 #ifdef CONFIG_BLK_DEV_INITRD
@@ -61,8 +67,8 @@ static int __init early_initrd(char *p)
 	if (*endp == ',') {
 		size = memparse(endp + 1, NULL);
 
-		initrd_start = (unsigned long)__va(start);
-		initrd_end = (unsigned long)__va(start + size);
+		initrd_start = start;
+		initrd_end = start + size;
 	}
 	return 0;
 }
@@ -213,8 +219,12 @@ void __init arm64_memblock_init(void)
 	 */
 	memblock_reserve(__pa(_text), _end - _text);
 #ifdef CONFIG_BLK_DEV_INITRD
-	if (initrd_start)
-		memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
+	if (initrd_start) {
+		memblock_reserve(initrd_start, initrd_end - initrd_start);
+
+		initrd_start = phys_to_virt(initrd_start);
+		initrd_end = phys_to_virt(initrd_end);
+	}
 #endif
 
 	early_init_fdt_scan_reserved_mem();
-- 
2.5.0



From pali.rohar at gmail.com  Thu Feb 11 06:43:47 2016
From: pali.rohar at gmail.com (Pali =?utf-8?B?Um9ow6Fy?=)
Date: Thu, 11 Feb 2016 15:43:47 +0100
Subject: USB Ethernet gadget on Nokia n900
In-Reply-To: <201601192158.19810@pali>
References: <20141019090107.GA19132@amd> <20150707074626.GB12087@pali>
 <20150707114658.GT10705@atomide.com> <201601192158.19810@pali>
Message-ID: <20160211144347.GY30075@pali>

On Tuesday 19 January 2016 21:58:19 Pali Roh?r wrote:
> On Tuesday 07 July 2015 13:46:59 Tony Lindgren wrote:
> > * Pali Roh?r <pali.rohar at gmail.com> [150707 00:48]:
> > > On Monday 06 July 2015 06:53:18 Tony Lindgren wrote:
> > > > * Pali Roh?r <pali.rohar at gmail.com> [150706 06:27]:
> > > > > On Tuesday 28 October 2014 23:26:41 Tony Lindgren wrote:
> > > > > > * Pavel Machek <pavel at ucw.cz> [141028 15:22]:
> > > > > > > On Tue 2014-10-28 23:04:50, Pavel Machek wrote:
> > > > > > > > Networking now works against 3.17-based kernel. Thanks!
> > > > > > > 
> > > > > > > It works on 3.18-rc1 kernel, too. (I had to hand-modify
> > > > > > > patch to apply to 3.17, no changes needed for 3.18-rc1.)
> > > > > > > 
> > > > > > > Tested-by: Pavel Machek <pavel at ucw.cz>
> > > > > > 
> > > > > > Whatever we decice to do to fix this regression, it should
> > > > > > probably be backported to at least v3.16 stable for distro
> > > > > > use, maybe earlier too. I'd assume this is broken on
> > > > > > multiple platforms currently.
> > > > > 
> > > > > it looks like this patch was not included into any kernel
> > > > > version... I'm still using it on top of 4.x kernels. Are you
> > > > > going to send this patch into upstream? Or do you have another
> > > > > fix for this problem?
> > > > 
> > > > I think Felipe mentioned a better built-in gether fix that's been
> > > > reviewed on linux-usb list.
> > > 
> > > Do you have link to that email thread? Or was Felipe's fix already
> > > merged into mainline kernel?
> > 
> > Sorry I don't have a link, maybe Felipe can point you to the right
> > patch.
> > 
> > Regards,
> > 
> > Tony
> 
> Felipe, ping
> 

PING?

-- 
Pali Roh?r
pali.rohar at gmail.com


From heiko at sntech.de  Thu Feb 11 06:47:12 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Thu, 11 Feb 2016 15:47:12 +0100
Subject: [GIT PULL 1/4] rockchip soc-driver changes for 4.6
Message-ID: <1734524.3yNt5L3F1F@phil>

Hi Arnd, Olof, Kevin,

please find below soc driver changes for Rockchip for 4.6
The tag describes the changes a little bit more.


Thanks
Heiko


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.6-rockchip-drivers1

for you to fetch changes up to 1d961f11a108af9f7fbe89cc950a8d16ddbdbb28:

  soc: rockchip: power-domain: fix err handle while probing (2016-02-02 22:18:31 +0100)

----------------------------------------------------------------
Support for the power-domains on rk3368 and a fix for
a wrong handling of for_each_available_child_of_node.

----------------------------------------------------------------
Heiko Stuebner (1):
      Merge branch 'v4.6-shared/pdids' into v4.6-armsoc/drivers

Shawn Lin (1):
      soc: rockchip: power-domain: fix err handle while probing

zhangqing (3):
      dt-bindings: add power-domain header for RK3368 SoCs
      dt-bindings: modify document of Rockchip power domains
      soc: rockchip: power-domain: Modify power domain driver for rk3368

 .../bindings/soc/rockchip/power_domain.txt         | 21 +++++++++++++
 drivers/soc/rockchip/pm_domains.c                  | 34 ++++++++++++++++++++++
 include/dt-bindings/power/rk3368-power.h           | 28 ++++++++++++++++++
 3 files changed, 83 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3368-power.h



From heiko at sntech.de  Thu Feb 11 06:49:12 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Thu, 11 Feb 2016 15:49:12 +0100
Subject: [GIT PULL 1/4] rockchip soc-driver changes for 4.6
In-Reply-To: <1734524.3yNt5L3F1F@phil>
References: <1734524.3yNt5L3F1F@phil>
Message-ID: <2006551.mXAMdNYBE2@phil>

Hi Arnd, Olof, Kevin,

This one change enables the rockchip timer driver on 64bit socs as well,
after it got fixed to actually work on 64bit in 4.5-rc1.
 
Thanks
Heiko


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.6-rockchip-soc64-1

for you to fetch changes up to c840f28bbf643c361c463bcb8fb815d0b2dad4e8:

  arm64: Enable the timer on Rockchip architecture (2016-01-24 23:33:14 +0100)

----------------------------------------------------------------
Enable the rockchip-specific timers on arm64 rockchip platforms.
The driver got reworked to not use arm32-specific dsb calls in
4.5-rc1, so now we can safely enable it.

----------------------------------------------------------------
Caesar Wang (1):
      arm64: Enable the timer on Rockchip architecture

 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)



From antoine.tenart at free-electrons.com  Thu Feb 11 06:45:44 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Thu, 11 Feb 2016 15:45:44 +0100
Subject: [PATCH v2 0/7] irqchip: introduce the Alpine MSIX driver
In-Reply-To: <56BC8F9C.3060505@arm.com>
References: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
 <56BC8F9C.3060505@arm.com>
Message-ID: <20160211144544.GC5820@kwain>

Hello Marc,

On Thu, Feb 11, 2016 at 01:41:48PM +0000, Marc Zyngier wrote:
> On 10/02/16 13:22, Antoine Tenart wrote:
> > 
> > This series introduce the Alpine MSIX driver, and enables it in both
> > the Alpine v1 and Alpine v2 device trees.
> > 
> > This series depends on "[PATCH v2 0/3] arm64: introduce the Alpine support":
> > https://lkml.org/lkml/2016/2/10/83
> > 
> > You can find the series at:
> > https://github.com/atenart/linux.git 4.5-rc1/alpinev2-msix
> 
> So I'm quite happy with this as it is (modulo the documentation fix on
> patch 3). I can take the first 3 patches through my GIC tree, but the
> last 4 patches depend on your other series.

I'll fix the documentation.

> Would it be a problem to get these 4 patches merged after 4.6-rc1, so
> that all the code can be merged before?

I think we can live with that :)

Thanks,

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/062ef4de/attachment.sig>

From pali.rohar at gmail.com  Thu Feb 11 06:50:43 2016
From: pali.rohar at gmail.com (Pali =?utf-8?B?Um9ow6Fy?=)
Date: Thu, 11 Feb 2016 15:50:43 +0100
Subject: USB Ethernet gadget on Nokia n900
In-Reply-To: <20160211144347.GY30075@pali>
References: <20141019090107.GA19132@amd> <20150707074626.GB12087@pali>
 <20150707114658.GT10705@atomide.com> <201601192158.19810@pali>
 <20160211144347.GY30075@pali>
Message-ID: <20160211145043.GZ30075@pali>

On Thursday 11 February 2016 15:43:47 Pali Roh?r wrote:
> On Tuesday 19 January 2016 21:58:19 Pali Roh?r wrote:
> > On Tuesday 07 July 2015 13:46:59 Tony Lindgren wrote:
> > > * Pali Roh?r <pali.rohar at gmail.com> [150707 00:48]:
> > > > On Monday 06 July 2015 06:53:18 Tony Lindgren wrote:
> > > > > * Pali Roh?r <pali.rohar at gmail.com> [150706 06:27]:
> > > > > > On Tuesday 28 October 2014 23:26:41 Tony Lindgren wrote:
> > > > > > > * Pavel Machek <pavel at ucw.cz> [141028 15:22]:
> > > > > > > > On Tue 2014-10-28 23:04:50, Pavel Machek wrote:
> > > > > > > > > Networking now works against 3.17-based kernel. Thanks!
> > > > > > > > 
> > > > > > > > It works on 3.18-rc1 kernel, too. (I had to hand-modify
> > > > > > > > patch to apply to 3.17, no changes needed for 3.18-rc1.)
> > > > > > > > 
> > > > > > > > Tested-by: Pavel Machek <pavel at ucw.cz>
> > > > > > > 
> > > > > > > Whatever we decice to do to fix this regression, it should
> > > > > > > probably be backported to at least v3.16 stable for distro
> > > > > > > use, maybe earlier too. I'd assume this is broken on
> > > > > > > multiple platforms currently.
> > > > > > 
> > > > > > it looks like this patch was not included into any kernel
> > > > > > version... I'm still using it on top of 4.x kernels. Are you
> > > > > > going to send this patch into upstream? Or do you have another
> > > > > > fix for this problem?
> > > > > 
> > > > > I think Felipe mentioned a better built-in gether fix that's been
> > > > > reviewed on linux-usb list.
> > > > 
> > > > Do you have link to that email thread? Or was Felipe's fix already
> > > > merged into mainline kernel?
> > > 
> > > Sorry I don't have a link, maybe Felipe can point you to the right
> > > patch.
> > > 
> > > Regards,
> > > 
> > > Tony
> > 
> > Felipe, ping
> > 
> 
> PING?
> 

Ok, Felipe address is dead:
550 Invalid recipient <balbi at ti.com> (#5.1.1)

-- 
Pali Roh?r
pali.rohar at gmail.com


From heiko at sntech.de  Thu Feb 11 06:50:51 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Thu, 11 Feb 2016 15:50:51 +0100
Subject: [GIT PULL 2/4] rockchip arm64 changes for 4.6
In-Reply-To: <1734524.3yNt5L3F1F@phil>
References: <1734524.3yNt5L3F1F@phil>
Message-ID: <2157996.gfpT01ltKJ@phil>

Hi Arnd, Olof, Kevin,

This one change enables the rockchip timer driver on 64bit socs as well,
after it got fixed to actually work on 64bit in 4.5-rc1.

This time I actually also updated the subject from my previous send-attempt, 
so here it is again.

Thanks
Heiko


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git 
tags/v4.6-rockchip-soc64-1

for you to fetch changes up to c840f28bbf643c361c463bcb8fb815d0b2dad4e8:

  arm64: Enable the timer on Rockchip architecture (2016-01-24 23:33:14 
+0100)

----------------------------------------------------------------
Enable the rockchip-specific timers on arm64 rockchip platforms.
The driver got reworked to not use arm32-specific dsb calls in
4.5-rc1, so now we can safely enable it.

----------------------------------------------------------------
Caesar Wang (1):
      arm64: Enable the timer on Rockchip architecture

 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)


From robh+dt at kernel.org  Thu Feb 11 06:50:41 2016
From: robh+dt at kernel.org (Rob Herring)
Date: Thu, 11 Feb 2016 08:50:41 -0600
Subject: [PATCH v10 3/8] dt, numa: adding numa dt binding implementation.
In-Reply-To: <1454407763-1017-4-git-send-email-gkulkarni@caviumnetworks.com>
References: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
 <1454407763-1017-4-git-send-email-gkulkarni@caviumnetworks.com>
Message-ID: <CAL_JsqK5HV9yzBE+ANnTw26eVR7Dy+B8OkwQ-7WF8KDa86Fd9g@mail.gmail.com>

On Tue, Feb 2, 2016 at 4:09 AM, Ganapatrao Kulkarni
<gkulkarni at caviumnetworks.com> wrote:
> dt node parsing for numa topology is done using device property
> numa-node-id and device node distance-map.

How is it that powerpc doesn't need flat DT parsing for NUMA? Both
arches are memblock based and the binding is similar IIRC, so you
should be able to find a way to do this with the unflattened tree.
Ideally, there should be some common code shared as well.

Do you have a git tree with this series?

Rob


From richardcochran at gmail.com  Thu Feb 11 06:51:58 2016
From: richardcochran at gmail.com (Richard Cochran)
Date: Thu, 11 Feb 2016 15:51:58 +0100
Subject: breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi:
 Refactor A31 PLL6 so that it can be reused)
In-Reply-To: <20160211100048.GK31506@lukather>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <56BB2D79.6090402@arm.com>
 <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
 <20160210143755.GE31506@lukather>
 <20160210163001.GG2632@leverpostej>
 <20160211100048.GK31506@lukather>
Message-ID: <20160211145158.GA8824@localhost.localdomain>

On Thu, Feb 11, 2016 at 11:00:48AM +0100, Maxime Ripard wrote:
> None of our existing users ever complained.

Note to self:

   Avoid choosing this SoC for new projects.  The maintainers do not
   care about the end users.

Thanks,
Richard


From tony at atomide.com  Thu Feb 11 07:02:41 2016
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 11 Feb 2016 07:02:41 -0800
Subject: [PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred
 probe for pm_runtime_reinit
In-Reply-To: <CAPDyKFpAcsfLgtu93P45fTEg11MjdGwREcyeGSS7vt6GWbNu_w@mail.gmail.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-2-git-send-email-tony@atomide.com>
 <CAPDyKFpAcsfLgtu93P45fTEg11MjdGwREcyeGSS7vt6GWbNu_w@mail.gmail.com>
Message-ID: <20160211150240.GR19432@atomide.com>

* Ulf Hansson <ulf.hansson at linaro.org> [160211 02:19]:
> On 11 February 2016 at 00:02, Tony Lindgren <tony at atomide.com> wrote:
> >
> > Ulf, I'd like to merge this along with other related fixes via the
> > ARM SoC tree if no objections, please review and ack if this look OK
> > to you.
> 
> I have some other omap_hsmmc patches queued for 4.6, so I prefer to
> send this via my mmc tree.
> 
> I guess that's okay as well!?

Naturally yes, please go ahead thanks!

Regards,

Tony


From tony at atomide.com  Thu Feb 11 07:08:06 2016
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 11 Feb 2016 07:08:06 -0800
Subject: [PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred
 probe for pm_runtime_reinit
In-Reply-To: <20160211115128.GF13270@sirena.org.uk>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-4-git-send-email-tony@atomide.com>
 <20160211115128.GF13270@sirena.org.uk>
Message-ID: <20160211150806.GS19432@atomide.com>

* Mark Brown <broonie at kernel.org> [160211 03:52]:
> On Wed, Feb 10, 2016 at 03:02:46PM -0800, Tony Lindgren wrote:
> 
> > Mark, I'd like to merge this along with other related fixes via
> > the ARM SoC tree if no objections, please review and ack if this
> > look OK to you.
> 
> Why, I'm not seeing any dependencies here?  I'd also expect to be seeing
> an awful lot more changes like this, this shouldn't be an OMAP thing -
> do we need to fix the core API and then roll out the transition in a
> different way?

Please feel free to pick up this one if you have other fixes
lined up, nothing stopping that.

There will be likely more fixes like this to make drivers follow
the PM runtime API documentation. These were just the initial
ones that were obvious.

Regards,

Tony


From heiko at sntech.de  Thu Feb 11 06:52:40 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Thu, 11 Feb 2016 15:52:40 +0100
Subject: [GIT PULL 3/4] rockchip dts64 changes for 4.6
In-Reply-To: <1734524.3yNt5L3F1F@phil>
References: <1734524.3yNt5L3F1F@phil>
Message-ID: <29700148.FpDzERqiyH@phil>

Hi Arnd, Olof, Kevin,

some small 64bit devicetree changes for 4.6 that allow mmc tuning and
use the newer wakeup-source property for the gpio-keys.


Thanks
Heiko

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.6-rockchip-dts64-1

for you to fetch changes up to e6f49b118f73a769ec51ed28a085e9dccd67f9a1:

  arm64: dts: rockchip: replace gpio-key,wakeup with wakeup-source property (2016-02-10 00:23:24 +0100)

----------------------------------------------------------------
Define the tuning-related mmc clocks and move from
gpio-key,wakeup to the more generic wakeup-source property.

----------------------------------------------------------------
Shawn Lin (1):
      arm64: dts: rockchip: add rk3368 tuning clk for emmc and sdmmc

Sudeep Holla (1):
      arm64: dts: rockchip: replace gpio-key,wakeup with wakeup-source property

 arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi |  2 +-
 arch/arm64/boot/dts/rockchip/rk3368-r88.dts  |  2 +-
 arch/arm64/boot/dts/rockchip/rk3368.dtsi     | 10 ++++++----
 3 files changed, 8 insertions(+), 6 deletions(-)



From tj at kernel.org  Thu Feb 11 07:10:30 2016
From: tj at kernel.org (Tejun Heo)
Date: Thu, 11 Feb 2016 10:10:30 -0500
Subject: [PATCH] libata: fix HDIO_GET_32BIT ioctl
In-Reply-To: <1455196595-3466120-1-git-send-email-arnd@arndb.de>
References: <1455196595-3466120-1-git-send-email-arnd@arndb.de>
Message-ID: <20160211151030.GW3741@mtj.duckdns.org>

On Thu, Feb 11, 2016 at 02:16:27PM +0100, Arnd Bergmann wrote:
> As reported by Soohoon Lee, the HDIO_GET_32BIT ioctl does not
> work correctly in compat mode with libata.
> 
> I have investigated the issue further and found multiple problems
> that all appeared with the same commit that originally introduced
> HDIO_GET_32BIT handling in libata back in linux-2.6.8 and presumably
> also linux-2.4, as the code uses "copy_to_user(arg, &val, 1)" to copy
> a 'long' variable containing either 0 or 1 to user space.

Applied to libata/for-4.5-fixes.

Thanks a lot!

-- 
tejun


From thomas.petazzoni at free-electrons.com  Thu Feb 11 06:59:28 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 11 Feb 2016 15:59:28 +0100
Subject: [PATCH v2 0/7] irqchip: introduce the Alpine MSIX driver
In-Reply-To: <20160211144544.GC5820@kwain>
References: <1455110583-19515-1-git-send-email-antoine.tenart@free-electrons.com>
 <56BC8F9C.3060505@arm.com> <20160211144544.GC5820@kwain>
Message-ID: <20160211155928.10695bb0@free-electrons.com>

Hello,

On Thu, 11 Feb 2016 15:45:44 +0100, Antoine Tenart wrote:

> On Thu, Feb 11, 2016 at 01:41:48PM +0000, Marc Zyngier wrote:
> > On 10/02/16 13:22, Antoine Tenart wrote:
> > > 
> > > This series introduce the Alpine MSIX driver, and enables it in both
> > > the Alpine v1 and Alpine v2 device trees.
> > > 
> > > This series depends on "[PATCH v2 0/3] arm64: introduce the Alpine support":
> > > https://lkml.org/lkml/2016/2/10/83
> > > 
> > > You can find the series at:
> > > https://github.com/atenart/linux.git 4.5-rc1/alpinev2-msix
> > 
> > So I'm quite happy with this as it is (modulo the documentation fix on
> > patch 3). I can take the first 3 patches through my GIC tree, but the
> > last 4 patches depend on your other series.
> 
> I'll fix the documentation.
> 
> > Would it be a problem to get these 4 patches merged after 4.6-rc1, so
> > that all the code can be merged before?
> 
> I think we can live with that :)

Practically speaking, patches 4-7 have no build dependency on patches
1-3, so they can be merged independently. As long as the DT binding
introduced in patches 1-3 is validated, then patches 4-7 can be merged
in parallel.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From heiko at sntech.de  Thu Feb 11 07:12:35 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Thu, 11 Feb 2016 16:12:35 +0100
Subject: [GIT PULL 4/4] rockchip dts32 changes for 4.6
In-Reply-To: <1734524.3yNt5L3F1F@phil>
References: <1734524.3yNt5L3F1F@phil>
Message-ID: <22050679.RDDVtpO0ps@phil>

Hi Arnd, Olof, Kevin,

and finally this is the biggest set ... 32bit devicetree changes.
For the clock-ids this includes a shared branch that gets shared
with the clock-branch sent to the clock-maintainers.

As the tag describes, contents are pretty diverse but simple changes.


Thanks
Heiko


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.6-rockchip-dts32-1

for you to fetch changes up to 741d3b0c1f6187dbf9b509b6776c77828d4c66d5:

  ARM: dts: cros-ec-keyboard: Add LOCK key to keyboard matrix (2016-02-10 22:41:53 +0100)

----------------------------------------------------------------
Assorted bunch of 32bit Rockchip devicetree changes. More clocks,
nodes and fixes like the increased drive-strength on the firefly.
Most interesting is maybe the enablement of the pl330 option
for handling the broken flushp operation that is present on the
current Rockchip SoCs. Together with the driver-side enablement
this should give us working dma finally.

----------------------------------------------------------------
Addy Ke (1):
      ARM: dts: rockchip: Add arm, pl330-broken-no-flushp quirk for rk3288 platform

Andy Yan (2):
      ARM: dts: rockchip: enable pwm3 as pwm regulator for rk3066a based boards
      ARM: dts: rockchip: increase vdd_arm voltage for rk3066a based boards

Caesar Wang (11):
      ARM: dts: rockchip: set the pinctrl default setting for rk3036 i2s
      ARM: dts: rockchip: add the sound setup for rk3036-kylin board
      ARM: dts: rockchip: enable the uart0 for kylin board
      ARM: dts: rockchip: enable the high speed on sdio for kylin board
      ARM: dts: rockchip: add the sdio power sequence for kylin board
      ARM: dts: rockchip: add the sdmmc for kylin board
      ARM: dts: rockchip: add soc-specific compatibles for rk3036 SoCs
      ARM: dts: rockchip: add the leds control for rk3036-kylin board
      ARM: dts: rockchip: add mclk for rt5616 on rk3036 kylin board
      ARM: dts: rockchip: support the spi for rk3036
      ARM: dts: rockchip: add arm,pl330-broken-no-flushp quirk for rk3036 SoCs

Chris Zhong (1):
      ARM: dts: rockchip: add rk3288 mipi_dsi nodes

Heiko Stuebner (3):
      ARM: dts: rockchip: swap i2s clock ordering on rk3036
      ARM: dts: rockchip: add clock-cells for usb phy nodes
      Merge branch 'v4.6-shared/clkids' into v4.6-armsoc/dts32

James Chao (1):
      ARM: dts: cros-ec-keyboard: Add LOCK key to keyboard matrix

Pawe? Jarosz (2):
      clk: rockchip: Add new id for rk3066 tsadc clock
      ARM: dts: rockchip: add tsadc node

Romain Perier (1):
      ARM: dts: rockchip: Add LEDs via gpio-leds for Radxa Rock2 Square

Shawn Lin (3):
      dt-bindings: rockchip-dw-mshc: add RK3368 dw-mshc description
      dt-bindings: rockchip-dw-mshc: add RK3036 dw-mshc description
      ARM: dts: rockchip: Add arm, pl330-broken-no-flushp quirk for rk3xxx platform

Sjoerd Simons (3):
      ARM: dts: rockchip: Add the iodomains for the Rock2 SOM
      ARM: dts: rockchip: Add the SDIO wifi on Radxa Rock2 square
      ARM: dts: rockchip: Assign RK3288 EDP_24M input centrally

Sudeep Holla (1):
      ARM: dts: rockchip: replace gpio-key,wakeup with wakeup-source property

Wadim Egorov (1):
      ARM: dts: rockchip: Bump sd card pin drive strength up on firefly boards

Xing Zheng (1):
      ARM: dts: rockchip: increase the mclk_fs to 512 for kylin board

 .../devicetree/bindings/mmc/rockchip-dw-mshc.txt   |   2 +
 arch/arm/boot/dts/cros-ec-keyboard.dtsi            |   1 +
 arch/arm/boot/dts/rk3036-kylin.dts                 | 104 +++++++++++++++++++++
 arch/arm/boot/dts/rk3036.dtsi                      |  69 +++++++++++---
 arch/arm/boot/dts/rk3066a-bqcurie2.dts             |  19 +++-
 arch/arm/boot/dts/rk3066a-marsboard.dts            |  16 ++++
 arch/arm/boot/dts/rk3066a-rayeager.dts             |  18 +++-
 arch/arm/boot/dts/rk3066a.dtsi                     |  24 ++++-
 arch/arm/boot/dts/rk3188-radxarock.dts             |   2 +-
 arch/arm/boot/dts/rk3188.dtsi                      |   2 +
 arch/arm/boot/dts/rk3288-evb.dtsi                  |   2 +-
 arch/arm/boot/dts/rk3288-firefly.dtsi              |  26 +++++-
 arch/arm/boot/dts/rk3288-popmetal.dts              |   2 +-
 arch/arm/boot/dts/rk3288-r89.dts                   |   2 +-
 arch/arm/boot/dts/rk3288-rock2-som.dtsi            |  26 ++++++
 arch/arm/boot/dts/rk3288-rock2-square.dts          |  48 +++++++++-
 arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi    |   2 +-
 arch/arm/boot/dts/rk3288-veyron.dtsi               |   7 +-
 arch/arm/boot/dts/rk3288.dtsi                      |  48 ++++++++++
 arch/arm/boot/dts/rk3xxx.dtsi                      |   3 +
 include/dt-bindings/clock/rk3188-cru-common.h      |   1 +
 21 files changed, 389 insertions(+), 35 deletions(-)



From robert.richter at caviumnetworks.com  Thu Feb 11 07:12:51 2016
From: robert.richter at caviumnetworks.com (Robert Richter)
Date: Thu, 11 Feb 2016 16:12:51 +0100
Subject: [PATCH 0/6] net: thunderx: Setting IRQ affinity hints and other
 optimizations
In-Reply-To: <20160211.093341.2157216466193671957.davem@davemloft.net>
References: <1454933272-45005-1-git-send-email-sunil.kovvuri@gmail.com>
 <CA+sq2CdXHcWM=PrimSvoQ6dJyCPi0QsiiDzA5=YKKn6zHVsojg@mail.gmail.com>
 <20160211.093341.2157216466193671957.davem@davemloft.net>
Message-ID: <20160211151251.GQ24726@rric.localdomain>

On 11.02.16 09:33:41, David Miller wrote:
> From: Sunil Kovvuri <sunil.kovvuri at gmail.com>
> Date: Thu, 11 Feb 2016 18:56:48 +0530
> 
> > If time permits, can you please look at this patchset.
> 
> You were given feedback and I expect you to address that feedback
> and resubmit this series.
> 
> This is what the "Changed Requested" state in patchwork means.

Sunil, should I send a reworked version of my patch to you, or do you
just want to change it to dev_err() for me?

Thanks,

-Robert


From ulf.hansson at linaro.org  Thu Feb 11 07:13:44 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 11 Feb 2016 16:13:44 +0100
Subject: [PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred
 probe for pm_runtime_reinit
In-Reply-To: <20160211150240.GR19432@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-2-git-send-email-tony@atomide.com>
 <CAPDyKFpAcsfLgtu93P45fTEg11MjdGwREcyeGSS7vt6GWbNu_w@mail.gmail.com>
 <20160211150240.GR19432@atomide.com>
Message-ID: <CAPDyKFo4Jyjwyvr3P5VHfDhQ87K9mnR01N-NtKz-yx2ycnfOLg@mail.gmail.com>

On 11 February 2016 at 16:02, Tony Lindgren <tony at atomide.com> wrote:
> * Ulf Hansson <ulf.hansson at linaro.org> [160211 02:19]:
>> On 11 February 2016 at 00:02, Tony Lindgren <tony at atomide.com> wrote:
>> >
>> > Ulf, I'd like to merge this along with other related fixes via the
>> > ARM SoC tree if no objections, please review and ack if this look OK
>> > to you.
>>
>> I have some other omap_hsmmc patches queued for 4.6, so I prefer to
>> send this via my mmc tree.
>>
>> I guess that's okay as well!?
>
> Naturally yes, please go ahead thanks!

Okay!

BTW, did you notice my other comments to the patch?

I can fix them before applying, unless you want to send a v2?

Kind regards
Uffe


From linux at roeck-us.net  Thu Feb 11 07:13:22 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 11 Feb 2016 07:13:22 -0800
Subject: [PATCH] tty/serial: digicolor: Fix bad usage of IS_ERR_VALUE
In-Reply-To: <20160211104650.GU10826@n2100.arm.linux.org.uk>
References: <1455030539-10798-1-git-send-email-linux@roeck-us.net>
 <4571887.rTPndCnv20@wuerfel> <56BAA27A.9050605@roeck-us.net>
 <20160211104650.GU10826@n2100.arm.linux.org.uk>
Message-ID: <20160211151322.GA30389@roeck-us.net>

On Thu, Feb 11, 2016 at 10:46:50AM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 09, 2016 at 06:37:46PM -0800, Guenter Roeck wrote:
> > On 02/09/2016 07:26 AM, Arnd Bergmann wrote:
> > >On Tuesday 09 February 2016 07:08:59 Guenter Roeck wrote:
> > >>IS_ERR_VALUE() assumes that its parameter is an unsigned long.
> > >>It can not be used to check if an unsigned int reflects an error.
> > >>Doing so can result in the following build warning.
> > >>
> > >>drivers/tty/serial/digicolor-usart.c: In function ?digicolor_uart_probe?:
> > >>include/linux/err.h:21:38: warning:
> > >>         comparison is always false due to limited range of data type
> > >>drivers/tty/serial/digicolor-usart.c:485:6: note:
> > >>         in expansion of macro ?IS_ERR_VALUE?
> > >>
> > >>If that warning is seen, an error return from platform_get_irq() is missed.
> > >>
> > >>
> > >
> > >The patch looks correct to me, but what compiler version and which kernel
> > >tree is it that triggered the warning?
> > >
> > >Andrzej Hajda just modified the definition of IS_ERR_VALUE(), and the
> > >changes are still under discussion, but I don't see that warning with
> > >any of the versions.
> > >
> > I see it with gcc 5.1 and 5.2 (and W=1). I did not see / notice Andrzej's patch.
> > 
> > I agree that fixing the problem in IS_ERR_VALUE() is preferrable.
> 
> I disagree.  What happens if (eg) you decide to do this:
> 
> 	u8 irq;
> 
> 	irq = platform_get_irq(...);
> 	if (IS_ERR_VALUE(irq))
> 		...
> 
> is that the fault of IS_ERR_VALUE() that it will never be true?  No, it's
> a programming error in the caller, because the caller is using the wrong
> type here - in fact, you can't do anything in IS_ERR_VALUE() to correct
> that.
> 
Yes, I think we all reached that conclusion by now.

Thanks,
Guenter


From andre.przywara at arm.com  Thu Feb 11 07:16:29 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 11 Feb 2016 15:16:29 +0000
Subject: breaking DT compatibility
In-Reply-To: <20160211145158.GA8824@localhost.localdomain>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <56BB2D79.6090402@arm.com>
 <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
 <20160210143755.GE31506@lukather> <20160210163001.GG2632@leverpostej>
 <20160211100048.GK31506@lukather>
 <20160211145158.GA8824@localhost.localdomain>
Message-ID: <56BCA5CD.3080008@arm.com>

Hi,

On 11/02/16 14:51, Richard Cochran wrote:
> On Thu, Feb 11, 2016 at 11:00:48AM +0100, Maxime Ripard wrote:
>> None of our existing users ever complained.
> 
> Note to self:
> 
>    Avoid choosing this SoC for new projects.  The maintainers do not
>    care about the end users.

Now that's a bit harsh, I think.
Maxime is doing a great job for maintaining this admittedly not very
well architected and documented SoC "family" - in his spare time.

Also the actual end user experience is probably just fine (despite
broken DT compatibility), since on these storage-less boards the
distributions usually ship DT, firmware (U-Boot) and kernel bundled
together.
This does not qualify for breaking the DT deliberately, but we are about
to fix this as we speak.

Also my concern was just that I wanted to move away from this being the
only way of running Linux on those boards.

We may think about collecting DTBs and firmware for those boards in a
central place without direct connection to a certain Linux version or
distribution. This would make the whole idea more visible and would make
compatibility breaks more evident.

Cheers,
Andre.


From maxime.ripard at free-electrons.com  Thu Feb 11 07:12:46 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Feb 2016 16:12:46 +0100
Subject: [PATCH 01/14] pinctrl: sunxi: Add A83T R_PIO controller support
In-Reply-To: <CACRpkdaGZ4-S1A9zUUaBXXEazyJf_uZ4ESiBhw-CpozXMxfDHg@mail.gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-2-git-send-email-vishnupatekar0510@gmail.com>
 <CACRpkdbCgOBQw28d=qc1fAURY3x8UdoWqiMtXMZ=uWLaQj-nbg@mail.gmail.com>
 <20160211123648.GN31506@lukather>
 <CACRpkdaGZ4-S1A9zUUaBXXEazyJf_uZ4ESiBhw-CpozXMxfDHg@mail.gmail.com>
Message-ID: <20160211151246.GO31506@lukather>

Hi Linus,

On Thu, Feb 11, 2016 at 02:47:57PM +0100, Linus Walleij wrote:
> On Thu, Feb 11, 2016 at 1:36 PM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > On Thu, Feb 11, 2016 at 12:59:47PM +0100, Linus Walleij wrote:
> >> On Sun, Jan 31, 2016 at 2:20 AM, Vishnu Patekar
> >> <vishnupatekar0510 at gmail.com> wrote:
> >>
> >> > The A83T has R_PIO pin controller, it's same as A23, execpt A83T
> >> > interrupt bit is 6th and A83T has one extra pin PL12.
> >> >
> >> > Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
> >>
> >> Maxime, can you look at this patch?
> >
> > Chen-Yu had one minor comment on it,
> 
> OK waiting for a new version.
> 
> > and he's also the Allwinner
> > maintainer now, so you can trust his Acked-by just like you would
> > trust mine ;)
> 
> Can you guys supply a MAINTAINERS entry for the sunxi
> stuff?

We have one, and Chen-Yu is listed as co-maintainer:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n911

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/29c69084/attachment.sig>

From lee.jones at linaro.org  Thu Feb 11 07:24:18 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 11 Feb 2016 15:24:18 +0000
Subject: [PATCH v7 04/10] mfd: axp20x: Add missing copyright notice
In-Reply-To: <20160125143957.GS3368@x1>
References: <1452655854-1528-1-git-send-email-wens@csie.org>
 <1452655854-1528-5-git-send-email-wens@csie.org>
 <20160125143957.GS3368@x1>
Message-ID: <20160211152418.GA20693@x1>

On Mon, 25 Jan 2016, Lee Jones wrote:

> On Wed, 13 Jan 2016, Chen-Yu Tsai wrote:
> 
> > When the driver was merged, the original author did not include a proper
> > copyright notice. This patch adds the notice, backdated to when the
> > driver was merged.
> 
> This is very wordy. 
> 
> "Supply a backdated copyright notice."

Can you re-submit this set with this fixed and the Acks you collected?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From laurentiu.tudor at nxp.com  Thu Feb 11 07:24:26 2016
From: laurentiu.tudor at nxp.com (Laurentiu Tudor)
Date: Thu, 11 Feb 2016 15:24:26 +0000
Subject: [PATCH] arm64: defer __va() translations of initrd_start and
 initrd_end
In-Reply-To: <1455201681-29972-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455201681-29972-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <56BCA7A9.60806@nxp.com>

Hi Ard,

On 02/11/2016 04:41 PM, Ard Biesheuvel wrote:
> Commit 66f51676a095 ("arm64: allow kernel Image to be loaded anywhere in
> physical memory") defers the assignment of memstart_addr to the point where
> all memory has been discovered and possibly clipped based on the size of
> the linear region and the presence of a mem= command line parameter.
> 
> However, this results in __va() translations that have been performed up
> to this point to have been carried out with a preliminary, incorrect value
> of memstart_addr, and these values need to be fixed up.
> 
> To make this more transparent, change the initial value of memstart_addr to
> PAGE_OFFSET so that __va() translations are effectively identity functions,
> and fix up the values of initrd_start and initrd_end before use.
> 
> Tested-by: Laurentiu Tudor <laurentiu.tudor at nxp.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
> 
> This is the least ugly way to address this issue in the short term (since the
> offending patch is already in -next). The preferred way of dealing with this
> would be to parametrise early_init_dt_check_for_initrd() in such a way that
> we can decide per-arch whether it should perform the __va() translation or
> not. If this is the preferred approach also for the short term, I am happy
> to code that up as well.
> 
>  arch/arm64/mm/init.c | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 3a9fc46cbf80..bb53236e54d9 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -48,7 +48,13 @@
>  
>  #include "mm.h"
>  
> -phys_addr_t memstart_addr __read_mostly = 0;
> +/*
> + * Initialize memstart_addr to PAGE_OFFSET so that __va() translations
> + * performed before arm64_memblock_init() executes (i.e., assignments
> + * of initrd_start and initrd_end in the early FDT parsing code) are
> + * effectively identity functions.
> + */
> +phys_addr_t memstart_addr __read_mostly = PAGE_OFFSET;
>  phys_addr_t arm64_dma_phys_limit __read_mostly;
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> @@ -61,8 +67,8 @@ static int __init early_initrd(char *p)
>  	if (*endp == ',') {
>  		size = memparse(endp + 1, NULL);
>  
> -		initrd_start = (unsigned long)__va(start);
> -		initrd_end = (unsigned long)__va(start + size);
> +		initrd_start = start;
> +		initrd_end = start + size;
>  	}
>  	return 0;
>  }
> @@ -213,8 +219,12 @@ void __init arm64_memblock_init(void)
>  	 */
>  	memblock_reserve(__pa(_text), _end - _text);
>  #ifdef CONFIG_BLK_DEV_INITRD
> -	if (initrd_start)
> -		memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
> +	if (initrd_start) {
> +		memblock_reserve(initrd_start, initrd_end - initrd_start);
> +
> +		initrd_start = phys_to_virt(initrd_start);
> +		initrd_end = phys_to_virt(initrd_end);

There are some warnings here so I think you need to cast these to 'unsigned long'.

arch/arm64/mm/init.c: In function 'arm64_memblock_init':
arch/arm64/mm/init.c:225:16: warning: assignment makes integer from pointer without a cast [enabled by default]
   initrd_start = phys_to_virt(initrd_start);
                ^
arch/arm64/mm/init.c:226:14: warning: assignment makes integer from pointer without a cast [enabled by default]
   initrd_end = phys_to_virt(initrd_end);
              ^
---
Thanks & Best Regards, Laurentiu

From martin at sperl.org  Thu Feb 11 07:25:43 2016
From: martin at sperl.org (Martin Sperl)
Date: Thu, 11 Feb 2016 16:25:43 +0100
Subject: [PATCH 4/4] spi: bcm2835aux: fix CPOL/CPHA setting
In-Reply-To: <87a8n94e3x.fsf@eliezer.anholt.net>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <1455041435-8015-5-git-send-email-stephanolbrich@gmx.de>
 <87a8n94e3x.fsf@eliezer.anholt.net>
Message-ID: <16A848EA-6E08-48C4-B3DD-DF27333B7458@sperl.org>


> On 10.02.2016, at 01:13, Eric Anholt <eric at anholt.net> wrote:
> 
> stephanolbrich at gmx.de writes:
> 
>> From: Stephan Olbrich <stephanolbrich at gmx.de>
>> 
>> The auxiliary spi supports only CPHA=0 modes as the first bit is
>> always output to the pin before the first clock cycle. In CPHA=1
>> modes the first clock edge outputs the second bit hence the slave
>> can never read the first bit.
>> 
>> Also the CPHA registers switch between clocking data in/out on
>> rising/falling edge hence depend on the CPOL setting.
>> 
>> Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
>> ---
>> drivers/spi/spi-bcm2835aux.c | 10 +++++-----
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
>> index b90aa34..169f521 100644
>> --- a/drivers/spi/spi-bcm2835aux.c
>> +++ b/drivers/spi/spi-bcm2835aux.c
>> @@ -386,12 +386,12 @@ static int bcm2835aux_spi_prepare_message(struct spi_master *master,
>> 	bs->cntl[1] = BCM2835_AUX_SPI_CNTL1_MSBF_IN;
>> 
>> 	/* handle all the modes */
>> -	if (spi->mode & SPI_CPOL)
>> +	if (spi->mode & SPI_CPOL) {
>> 		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPOL;
>> -	if (spi->mode & SPI_CPHA)
>> -		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT |
>> -			       BCM2835_AUX_SPI_CNTL0_CPHA_IN;
>> -
>> +		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT;
>> +	} else {
>> +		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_IN;
>> +	}
>> 	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1]);
>> 	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL0, bs->cntl[0]);
> 
> (Note for other readers: A better name for CNTL0_CPHA_* would be
> CNTL0_*_RISING).
> 
> I think you're right about not actually supporting CPHA.  I don't see
> wany way to keep bit 1 out lasting through the first full clock cycle.
> I think Stefan's right that we should drop CPHA from MODE_BITS
> (actually, MODE_BITS would be nicer if we just merged it into its one
> user, I think).
> 
> However, this hunk appears to be correct and would fix the timing of our
> data going out in the CPOL=0 case and of sampling IN data for CPOL=1.

Are you sure that CPHA is not working?

I have used the following to test all combinations:
 for C in "" "-C"; do
  for O in "" "-O"; do
   for H in "" "-H"; do
    spidev_test -vD /dev/*.1 $H $O -p "\x00\x82\x00" -s 1000000;
   done
  done
 done

I have tested with the 4.5-rc3 kernel without any of your patches.

And looked at the logic-analyzer: I see distinct waveform pattern
for clk and data for all events!

The bug with regards to clock polarity needs to get fixed!

I will now apply patch4 only and see how it looks then...

Thanks,
	Martin







From ard.biesheuvel at linaro.org  Thu Feb 11 07:27:07 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 11 Feb 2016 16:27:07 +0100
Subject: [PATCH] arm64: defer __va() translations of initrd_start and
 initrd_end
In-Reply-To: <56BCA7A9.60806@nxp.com>
References: <1455201681-29972-1-git-send-email-ard.biesheuvel@linaro.org>
 <56BCA7A9.60806@nxp.com>
Message-ID: <CAKv+Gu8ByxMU50W_FaAQdVcrkDnQWnB3J8reRb_-m3ngyRVJJw@mail.gmail.com>

On 11 February 2016 at 16:24, Laurentiu Tudor <laurentiu.tudor at nxp.com> wrote:
> Hi Ard,
>
> On 02/11/2016 04:41 PM, Ard Biesheuvel wrote:
>> Commit 66f51676a095 ("arm64: allow kernel Image to be loaded anywhere in
>> physical memory") defers the assignment of memstart_addr to the point where
>> all memory has been discovered and possibly clipped based on the size of
>> the linear region and the presence of a mem= command line parameter.
>>
>> However, this results in __va() translations that have been performed up
>> to this point to have been carried out with a preliminary, incorrect value
>> of memstart_addr, and these values need to be fixed up.
>>
>> To make this more transparent, change the initial value of memstart_addr to
>> PAGE_OFFSET so that __va() translations are effectively identity functions,
>> and fix up the values of initrd_start and initrd_end before use.
>>
>> Tested-by: Laurentiu Tudor <laurentiu.tudor at nxp.com>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> ---
>>
>> This is the least ugly way to address this issue in the short term (since the
>> offending patch is already in -next). The preferred way of dealing with this
>> would be to parametrise early_init_dt_check_for_initrd() in such a way that
>> we can decide per-arch whether it should perform the __va() translation or
>> not. If this is the preferred approach also for the short term, I am happy
>> to code that up as well.
>>
>>  arch/arm64/mm/init.c | 20 +++++++++++++++-----
>>  1 file changed, 15 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 3a9fc46cbf80..bb53236e54d9 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -48,7 +48,13 @@
>>
>>  #include "mm.h"
>>
>> -phys_addr_t memstart_addr __read_mostly = 0;
>> +/*
>> + * Initialize memstart_addr to PAGE_OFFSET so that __va() translations
>> + * performed before arm64_memblock_init() executes (i.e., assignments
>> + * of initrd_start and initrd_end in the early FDT parsing code) are
>> + * effectively identity functions.
>> + */
>> +phys_addr_t memstart_addr __read_mostly = PAGE_OFFSET;
>>  phys_addr_t arm64_dma_phys_limit __read_mostly;
>>
>>  #ifdef CONFIG_BLK_DEV_INITRD
>> @@ -61,8 +67,8 @@ static int __init early_initrd(char *p)
>>       if (*endp == ',') {
>>               size = memparse(endp + 1, NULL);
>>
>> -             initrd_start = (unsigned long)__va(start);
>> -             initrd_end = (unsigned long)__va(start + size);
>> +             initrd_start = start;
>> +             initrd_end = start + size;
>>       }
>>       return 0;
>>  }
>> @@ -213,8 +219,12 @@ void __init arm64_memblock_init(void)
>>        */
>>       memblock_reserve(__pa(_text), _end - _text);
>>  #ifdef CONFIG_BLK_DEV_INITRD
>> -     if (initrd_start)
>> -             memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
>> +     if (initrd_start) {
>> +             memblock_reserve(initrd_start, initrd_end - initrd_start);
>> +
>> +             initrd_start = phys_to_virt(initrd_start);
>> +             initrd_end = phys_to_virt(initrd_end);
>
> There are some warnings here so I think you need to cast these to 'unsigned long'.
>
> arch/arm64/mm/init.c: In function 'arm64_memblock_init':
> arch/arm64/mm/init.c:225:16: warning: assignment makes integer from pointer without a cast [enabled by default]
>    initrd_start = phys_to_virt(initrd_start);
>                 ^
> arch/arm64/mm/init.c:226:14: warning: assignment makes integer from pointer without a cast [enabled by default]
>    initrd_end = phys_to_virt(initrd_end);
>               ^

Thanks for catching that. I should have used the __phys_to_virt()
variant instead.

Thanks,
Ard.


From arnd at arndb.de  Thu Feb 11 07:30:56 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 16:30:56 +0100
Subject: [PATCH] ARM: exynos: clarify KEYBOARD_SAMSUNG selection
Message-ID: <1455204662-1017820-1-git-send-email-arnd@arndb.de>

The samsung-keypad driver is implicitly selected by ARCH_EXYNOS4 (why?),
but this fails if CONFIG_INPUT is a loadable module:

drivers/input/built-in.o: In function `samsung_keypad_remove':
drivers/input/keyboard/samsung-keypad.c:461: undefined reference to `input_unregister_device'
drivers/input/built-in.o: In function `samsung_keypad_irq':
drivers/input/keyboard/samsung-keypad.c:137: undefined reference to `input_event'
drivers/input/built-in.o: In function `samsung_keypad_irq':
include/linux/input.h:389: undefined reference to `input_event'
drivers/input/built-in.o: In function `samsung_keypad_probe':
drivers/input/keyboard/samsung-keypad.c:358: undefined reference to `devm_input_allocate_device'
drivers/input/built-in.o:(.debug_addr+0x34): undefined reference to `input_set_capability'

This changes the 'select' statement so we don't do it if CONFIG_INPUT=m.
The problem does not happen on mainline kernels, as we don't normally
build built-in input drivers when CONFIG_INPUT=m, but I am experimenting
with a patch to change this, and the samsung keypad driver showed up
as one example that was silently broken before.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-exynos/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 8434a0f6334c..b63e64581c24 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -59,7 +59,7 @@ config ARCH_EXYNOS4
 	select CLKSRC_SAMSUNG_PWM if CPU_EXYNOS4210
 	select CPU_EXYNOS4210
 	select GIC_NON_BANKED
-	select KEYBOARD_SAMSUNG if INPUT_KEYBOARD
+	select KEYBOARD_SAMSUNG if INPUT=y && INPUT_KEYBOARD
 	select MIGHT_HAVE_CACHE_L2X0
 	help
 	  Samsung EXYNOS4 (Cortex-A9) SoC based systems
-- 
2.7.0



From linux at roeck-us.net  Thu Feb 11 07:32:43 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 11 Feb 2016 07:32:43 -0800
Subject: [PATCH] tty/serial: digicolor: Fix bad usage of IS_ERR_VALUE
In-Reply-To: <56BC2DF7.20803@samsung.com>
References: <1455030539-10798-1-git-send-email-linux@roeck-us.net>
 <4571887.rTPndCnv20@wuerfel> <56BAA27A.9050605@roeck-us.net>
 <2606061.l722KO95iI@wuerfel> <56BC022B.7030004@roeck-us.net>
 <56BC2DF7.20803@samsung.com>
Message-ID: <20160211153243.GA3076@roeck-us.net>

On Thu, Feb 11, 2016 at 07:45:11AM +0100, Andrzej Hajda wrote:
> On 02/11/2016 04:38 AM, Guenter Roeck wrote:
> > On 02/10/2016 07:21 AM, Arnd Bergmann wrote:
> >> On Tuesday 09 February 2016 18:37:46 Guenter Roeck wrote:
> >>> On 02/09/2016 07:26 AM, Arnd Bergmann wrote:
> >>>> On Tuesday 09 February 2016 07:08:59 Guenter Roeck wrote:
> >>>>> IS_ERR_VALUE() assumes that its parameter is an unsigned long.
> >>>>> It can not be used to check if an unsigned int reflects an error.
> >>>>> Doing so can result in the following build warning.
> >>>>>
> >>>>> drivers/tty/serial/digicolor-usart.c: In function ?digicolor_uart_probe?:
> >>>>> include/linux/err.h:21:38: warning:
> >>>>>           comparison is always false due to limited range of data type
> >>>>> drivers/tty/serial/digicolor-usart.c:485:6: note:
> >>>>>           in expansion of macro ?IS_ERR_VALUE?
> >>>>>
> >>>>> If that warning is seen, an error return from platform_get_irq() is missed.
> >>>>>
> >>>>>
> >>>> The patch looks correct to me, but what compiler version and which kernel
> >>>> tree is it that triggered the warning?
> >>>>
> >>>> Andrzej Hajda just modified the definition of IS_ERR_VALUE(), and the
> >>>> changes are still under discussion, but I don't see that warning with
> >>>> any of the versions.
> >>>>
> >>> I see it with gcc 5.1 and 5.2 (and W=1). I did not see / notice Andrzej's patch.
> >>>
> >>> I agree that fixing the problem in IS_ERR_VALUE() is preferrable.
> >>>
> >>>
> >> Ah, W=1 explains it. We are still debating about the proper solution. Al Viro
> >> pointed out that most users of IS_ERR_VALUE() shouldn't be using it at all,
> >> so your patch is probably best here after all.
> >>
> > Yes, after looking into it some more I agree. Coccinelle should be able to handle
> > most of the conversions automatically. I actually tried to write a script, just
> > for the fun of it, but it misses some of the problem cases in patch mode.
> > Maybe I get it working tonight.
> >
> > Guenter
> >
> 
> Maybe it can be helpful. The script which classifies all IS_ERR_VALUE
> usages as
> correct, signed, incorrect and unknown (cocci was not able to detect type).
> Adding patch mode should be quite simple.
> 
> // Options: --all-includes --include
> include/uapi/linux/netfilter_ipv6/ip6_tables.h --include
> include/uapi/linux/netfilter_ipv4/ip_tables.h --include
> include/uapi/linux/netfilter_arp/arp_tables.h --include
> include/uapi/linux/netfilter/x_tables.h --include include/linux/mm_types.h
> 
> virtual context
> virtual report
> 
> @r@
> typedef bool, u8, u16, u32, u64, s8, s16, s32, s64, __u64, dma_addr_t,
> Elf32_Addr, Elf64_Addr;
> {unsigned long, size_t} ev;
> {short, int, long, s16, s32, ssize_t} ew;
> {char, unsigned char, unsigned short, unsigned int, long long, unsigned
> long long, bool, u8, u16, u32, u64, s64, __u64, dma_addr_t, Elf32_Addr,
> Elf64_Addr} ei;
> expression eu;
> position p;
> @@
> 
> IS_ERR_VALUE(\(ev \| ew \| ei \| eu \))@p
> 
> @script:python depends on report@
> p << r.p = [];
> ev << r.ev = "";
> ew << r.ew = "";
> ei << r.ei = "";
> eu << r.eu = "";

This doesn't work for me; it bails out at the assignments. If I remove
the assignments, it does not report anything.

Any idea what might be wrong ?

Thanks,
Guenter

> @@
> 
> t = ""
> if ev: t = "correct"
> if ew: t = "signed"
> if ei: t = "incorrect"
> if eu: t = "unknown"
> 
> 
> e = ev + ew + ei + eu;
> if t:
>     msg = "WARNING: %s argument type in IS_ERR_VALUE(%s)" % (t, e)
>     coccilib.report.print_report(p[0], msg)
> 
> 


From robert.richter at caviumnetworks.com  Thu Feb 11 07:32:55 2016
From: robert.richter at caviumnetworks.com (Robert Richter)
Date: Thu, 11 Feb 2016 16:32:55 +0100
Subject: [PATCH v10 3/8] dt, numa: adding numa dt binding implementation.
In-Reply-To: <CAL_JsqK5HV9yzBE+ANnTw26eVR7Dy+B8OkwQ-7WF8KDa86Fd9g@mail.gmail.com>
References: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
 <1454407763-1017-4-git-send-email-gkulkarni@caviumnetworks.com>
 <CAL_JsqK5HV9yzBE+ANnTw26eVR7Dy+B8OkwQ-7WF8KDa86Fd9g@mail.gmail.com>
Message-ID: <20160211153255.GR24726@rric.localdomain>

On 11.02.16 08:50:41, Rob Herring wrote:
> On Tue, Feb 2, 2016 at 4:09 AM, Ganapatrao Kulkarni
> <gkulkarni at caviumnetworks.com> wrote:
> > dt node parsing for numa topology is done using device property
> > numa-node-id and device node distance-map.
> 
> How is it that powerpc doesn't need flat DT parsing for NUMA? Both
> arches are memblock based and the binding is similar IIRC, so you
> should be able to find a way to do this with the unflattened tree.
> Ideally, there should be some common code shared as well.
> 
> Do you have a git tree with this series?

I have pushed it here for you:

 https://git.kernel.org/cgit/linux/kernel/git/rric/linux.git/log/?h=thunder/numa-v10

-Robert


From julien.grall at arm.com  Thu Feb 11 07:33:18 2016
From: julien.grall at arm.com (Julien Grall)
Date: Thu, 11 Feb 2016 15:33:18 +0000
Subject: [PATCH v2 0/6] arm64: Add support of KVM with ACPI
Message-ID: <1455204804-31830-1-git-send-email-julien.grall@arm.com>

Hello,

This small series allows an ARM64 ACPI based platform to use KVM.

Currently the KVM code has to parse the firmware table to get the necessary
information to setup the virtual timer and virtual GIC.

However the parsing of those tables are already done in the GIC and arch
timer drivers.

This patch series introduces different helpers to retrieve the information
from different drivers avoiding to duplicate the parsing code.

Note there is patch series ([1] and [2]) adding support of KVM on ACPI,
although the approach chosen is completely different. The code to parse
the firmware tables are duplicated which I think make more complex to
support new firmware tables.

See the changes since v1 in the different patches.

Regards,

[1] https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018482.html
[2] https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018355.html

Julien Grall (6):
  KVM: arm/arm64: arch_timer: Gather KVM specific information in a
    structure
  KVM: arm/arm64: arch_timer: Rely on the arch timer to parse the
    firmware tables
  irqchip/gic-v2: Gather ACPI specific data in a single structure
  irqchip/gic-v2: Parse and export virtual GIC information
  irqchip/gic-v3: Parse and export virtual GIC information
  KVM: arm/arm64: vgic: Rely on the GIC driver to parse the firmware
    tables

 drivers/clocksource/arm_arch_timer.c   | 11 ++--
 drivers/irqchip/irq-gic-common.c       | 13 +++++
 drivers/irqchip/irq-gic-common.h       |  3 ++
 drivers/irqchip/irq-gic-v3.c           | 36 ++++++++++++++
 drivers/irqchip/irq-gic.c              | 91 ++++++++++++++++++++++++++++++++--
 include/clocksource/arm_arch_timer.h   | 13 ++---
 include/kvm/arm_vgic.h                 |  7 +--
 include/linux/irqchip/arm-gic-common.h | 34 +++++++++++++
 virt/kvm/arm/arch_timer.c              | 39 ++++-----------
 virt/kvm/arm/vgic-v2.c                 | 67 +++++++++----------------
 virt/kvm/arm/vgic-v3.c                 | 45 +++++------------
 virt/kvm/arm/vgic.c                    | 50 ++++++++++---------
 12 files changed, 264 insertions(+), 145 deletions(-)
 create mode 100644 include/linux/irqchip/arm-gic-common.h

-- 
1.9.1



From julien.grall at arm.com  Thu Feb 11 07:33:19 2016
From: julien.grall at arm.com (Julien Grall)
Date: Thu, 11 Feb 2016 15:33:19 +0000
Subject: [PATCH v2 1/6] KVM: arm/arm64: arch_timer: Gather KVM specific
 information in a structure
In-Reply-To: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
References: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
Message-ID: <1455204804-31830-2-git-send-email-julien.grall@arm.com>

Introduce a structure which are filled up by the arch timer driver and
used by the virtual timer in KVM.

The first member of this structure will be the timecounter. More members
will be added later.

This is also dropping arch_timer_get_timecounter as it was only used by
the KVM code. Furthermore, a stub for the new helper hasn't been
introduced because KVM is requiring the arch timer for both ARM64 and
ARM32.

Signed-off-by: Julien Grall <julien.grall at arm.com>

---
Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Christoffer Dall <christoffer.dall at linaro.org>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: Gleb Natapov <gleb at kernel.org>
Cc: Paolo Bonzini <pbonzini at redhat.com>
---
 drivers/clocksource/arm_arch_timer.c |  9 +++++----
 include/clocksource/arm_arch_timer.h | 12 ++++++------
 virt/kvm/arm/arch_timer.c            |  6 +++---
 3 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index c64d543..6eb2c5d 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -447,11 +447,11 @@ static struct cyclecounter cyclecounter = {
 	.mask	= CLOCKSOURCE_MASK(56),
 };
 
-static struct timecounter timecounter;
+static struct arch_timer_kvm_info arch_timer_kvm_info;
 
-struct timecounter *arch_timer_get_timecounter(void)
+struct arch_timer_kvm_info *arch_timer_get_kvm_info(void)
 {
-	return &timecounter;
+	return &arch_timer_kvm_info;
 }
 
 static void __init arch_counter_register(unsigned type)
@@ -479,7 +479,8 @@ static void __init arch_counter_register(unsigned type)
 	clocksource_register_hz(&clocksource_counter, arch_timer_rate);
 	cyclecounter.mult = clocksource_counter.mult;
 	cyclecounter.shift = clocksource_counter.shift;
-	timecounter_init(&timecounter, &cyclecounter, start_count);
+	timecounter_init(&arch_timer_kvm_info.timecounter,
+			 &cyclecounter, start_count);
 
 	/* 56 bits minimum, so we assume worst case rollover */
 	sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate);
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index 25d0914..4d487f8 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -49,11 +49,16 @@ enum arch_timer_reg {
 
 #define ARCH_TIMER_EVT_STREAM_FREQ	10000	/* 100us */
 
+struct arch_timer_kvm_info {
+	struct timecounter timecounter;
+};
+
 #ifdef CONFIG_ARM_ARCH_TIMER
 
 extern u32 arch_timer_get_rate(void);
 extern u64 (*arch_timer_read_counter)(void);
-extern struct timecounter *arch_timer_get_timecounter(void);
+
+extern struct arch_timer_kvm_info *arch_timer_get_kvm_info(void);
 
 #else
 
@@ -67,11 +72,6 @@ static inline u64 arch_timer_read_counter(void)
 	return 0;
 }
 
-static inline struct timecounter *arch_timer_get_timecounter(void)
-{
-	return NULL;
-}
-
 #endif
 
 #endif
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 69bca18..a669c6a 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -385,11 +385,11 @@ int kvm_timer_hyp_init(void)
 {
 	struct device_node *np;
 	unsigned int ppi;
+	struct arch_timer_kvm_info *info;
 	int err;
 
-	timecounter = arch_timer_get_timecounter();
-	if (!timecounter)
-		return -ENODEV;
+	info = arch_timer_get_kvm_info();
+	timecounter = &info->timecounter;
 
 	np = of_find_matching_node(NULL, arch_timer_of_match);
 	if (!np) {
-- 
1.9.1



From julien.grall at arm.com  Thu Feb 11 07:33:20 2016
From: julien.grall at arm.com (Julien Grall)
Date: Thu, 11 Feb 2016 15:33:20 +0000
Subject: [PATCH v2 2/6] KVM: arm/arm64: arch_timer: Rely on the arch timer to
 parse the firmware tables
In-Reply-To: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
References: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
Message-ID: <1455204804-31830-3-git-send-email-julien.grall@arm.com>

The firmware table is currently parsed by the virt timer code in order
to retrieve the virtual interrupt. However, this is already done by the
arch timer driver and therefore make the parsing code duplicated twice.

Introduce an helper to get the virtual interrupt number and use it in
the virtual timer code.

With this changes, the support for ACPI is coming free.

Signed-off-by: Julien Grall <julien.grall at arm.com>

---
Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Christoffer Dall <christoffer.dall at linaro.org>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: Gleb Natapov <gleb at kernel.org>
Cc: Paolo Bonzini <pbonzini at redhat.com>
---
 drivers/clocksource/arm_arch_timer.c |  2 ++
 include/clocksource/arm_arch_timer.h |  1 +
 virt/kvm/arm/arch_timer.c            | 33 +++++++--------------------------
 3 files changed, 10 insertions(+), 26 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 6eb2c5d..3cdbefd 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -451,6 +451,8 @@ static struct arch_timer_kvm_info arch_timer_kvm_info;
 
 struct arch_timer_kvm_info *arch_timer_get_kvm_info(void)
 {
+	arch_timer_kvm_info.virtual_irq = arch_timer_ppi[VIRT_PPI];
+
 	return &arch_timer_kvm_info;
 }
 
diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
index 4d487f8..8890552 100644
--- a/include/clocksource/arm_arch_timer.h
+++ b/include/clocksource/arm_arch_timer.h
@@ -51,6 +51,7 @@ enum arch_timer_reg {
 
 struct arch_timer_kvm_info {
 	struct timecounter timecounter;
+	int virtual_irq;
 };
 
 #ifdef CONFIG_ARM_ARCH_TIMER
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index a669c6a..e4de549 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -17,7 +17,6 @@
  */
 
 #include <linux/cpu.h>
-#include <linux/of_irq.h>
 #include <linux/kvm.h>
 #include <linux/kvm_host.h>
 #include <linux/interrupt.h>
@@ -375,45 +374,28 @@ static struct notifier_block kvm_timer_cpu_nb = {
 	.notifier_call = kvm_timer_cpu_notify,
 };
 
-static const struct of_device_id arch_timer_of_match[] = {
-	{ .compatible	= "arm,armv7-timer",	},
-	{ .compatible	= "arm,armv8-timer",	},
-	{},
-};
-
 int kvm_timer_hyp_init(void)
 {
-	struct device_node *np;
-	unsigned int ppi;
 	struct arch_timer_kvm_info *info;
 	int err;
 
 	info = arch_timer_get_kvm_info();
 	timecounter = &info->timecounter;
 
-	np = of_find_matching_node(NULL, arch_timer_of_match);
-	if (!np) {
-		kvm_err("kvm_arch_timer: can't find DT node\n");
+	host_vtimer_irq = info->virtual_irq;
+	if (host_vtimer_irq <= 0) {
+		kvm_err("kvm_arch_timer: can't find virtual timer info or config virtual timer interrupt\n");
 		return -ENODEV;
 	}
 
-	ppi = irq_of_parse_and_map(np, 2);
-	if (!ppi) {
-		kvm_err("kvm_arch_timer: no virtual timer interrupt\n");
-		err = -EINVAL;
-		goto out;
-	}
-
-	err = request_percpu_irq(ppi, kvm_arch_timer_handler,
+	err = request_percpu_irq(host_vtimer_irq, kvm_arch_timer_handler,
 				 "kvm guest timer", kvm_get_running_vcpus());
 	if (err) {
 		kvm_err("kvm_arch_timer: can't request interrupt %d (%d)\n",
-			ppi, err);
+			host_vtimer_irq, err);
 		goto out;
 	}
 
-	host_vtimer_irq = ppi;
-
 	err = __register_cpu_notifier(&kvm_timer_cpu_nb);
 	if (err) {
 		kvm_err("Cannot register timer CPU notifier\n");
@@ -426,14 +408,13 @@ int kvm_timer_hyp_init(void)
 		goto out_free;
 	}
 
-	kvm_info("%s IRQ%d\n", np->name, ppi);
+	kvm_info("vtimer IRQ%d\n", host_vtimer_irq);
 	on_each_cpu(kvm_timer_init_interrupt, NULL, 1);
 
 	goto out;
 out_free:
-	free_percpu_irq(ppi, kvm_get_running_vcpus());
+	free_percpu_irq(host_vtimer_irq, kvm_get_running_vcpus());
 out:
-	of_node_put(np);
 	return err;
 }
 
-- 
1.9.1



From julien.grall at arm.com  Thu Feb 11 07:33:21 2016
From: julien.grall at arm.com (Julien Grall)
Date: Thu, 11 Feb 2016 15:33:21 +0000
Subject: [PATCH v2 3/6] irqchip/gic-v2: Gather ACPI specific data in a single
 structure
In-Reply-To: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
References: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
Message-ID: <1455204804-31830-4-git-send-email-julien.grall@arm.com>

For now, there is only one member. More member will be added later.

Signed-off-by: Julien Grall <julien.grall at arm.com>

---
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier at arm.com>

    Changes in v2:
        - Patch added
---
 drivers/irqchip/irq-gic.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 911758c..d6131c4 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -1246,7 +1246,10 @@ IRQCHIP_DECLARE(pl390, "arm,pl390", gic_of_init);
 #endif
 
 #ifdef CONFIG_ACPI
-static phys_addr_t cpu_phy_base __initdata;
+static struct
+{
+	phys_addr_t cpu_phy_base;
+} acpi_data __initdata;
 
 static int __init
 gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
@@ -1266,10 +1269,10 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
 	 * All CPU interface addresses have to be the same.
 	 */
 	gic_cpu_base = processor->base_address;
-	if (cpu_base_assigned && gic_cpu_base != cpu_phy_base)
+	if (cpu_base_assigned && gic_cpu_base != acpi_data.cpu_phy_base)
 		return -EINVAL;
 
-	cpu_phy_base = gic_cpu_base;
+	acpi_data.cpu_phy_base = gic_cpu_base;
 	cpu_base_assigned = 1;
 	return 0;
 }
@@ -1317,7 +1320,7 @@ static int __init gic_v2_acpi_init(struct acpi_subtable_header *header,
 		return -EINVAL;
 	}
 
-	cpu_base = ioremap(cpu_phy_base, ACPI_GIC_CPU_IF_MEM_SIZE);
+	cpu_base = ioremap(acpi_data.cpu_phy_base, ACPI_GIC_CPU_IF_MEM_SIZE);
 	if (!cpu_base) {
 		pr_err("Unable to map GICC registers\n");
 		return -ENOMEM;
-- 
1.9.1



From julien.grall at arm.com  Thu Feb 11 07:33:22 2016
From: julien.grall at arm.com (Julien Grall)
Date: Thu, 11 Feb 2016 15:33:22 +0000
Subject: [PATCH v2 4/6] irqchip/gic-v2: Parse and export virtual GIC
 information
In-Reply-To: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
References: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
Message-ID: <1455204804-31830-5-git-send-email-julien.grall@arm.com>

For now, the firmware tables are parsed 2 times: once in the GIC
drivers, the other timer when initializing the vGIC. It means code
duplication and make more tedious to add the support for another
firmware table (like ACPI).

Introduce a new structure and set of helpers to get/set the virtual GIC
information. Also fill up the structure for GICv2.

Signed-off-by: Julien Grall <julien.grall at arm.com>

---
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier at arm.com>

    Changes in v2:
        - Use 0 rather than a negative value to know when the maintenance IRQ
        is not present.
        - Use resource for vcpu and vctrl
---
 drivers/irqchip/irq-gic-common.c       | 13 ++++++
 drivers/irqchip/irq-gic-common.h       |  3 ++
 drivers/irqchip/irq-gic.c              | 80 +++++++++++++++++++++++++++++++++-
 include/linux/irqchip/arm-gic-common.h | 33 ++++++++++++++
 4 files changed, 128 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/irqchip/arm-gic-common.h

diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
index f174ce0..704caf4 100644
--- a/drivers/irqchip/irq-gic-common.c
+++ b/drivers/irqchip/irq-gic-common.c
@@ -21,6 +21,19 @@
 
 #include "irq-gic-common.h"
 
+static const struct gic_kvm_info *gic_kvm_info;
+
+const struct gic_kvm_info *gic_get_kvm_info(void)
+{
+	return gic_kvm_info;
+}
+
+void gic_set_kvm_info(const struct gic_kvm_info *info)
+{
+	WARN(gic_kvm_info != NULL, "gic_kvm_info already set\n");
+	gic_kvm_info = info;
+}
+
 void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
 		void *data)
 {
diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
index fff697d..205e5fd 100644
--- a/drivers/irqchip/irq-gic-common.h
+++ b/drivers/irqchip/irq-gic-common.h
@@ -19,6 +19,7 @@
 
 #include <linux/of.h>
 #include <linux/irqdomain.h>
+#include <linux/irqchip/arm-gic-common.h>
 
 struct gic_quirk {
 	const char *desc;
@@ -35,4 +36,6 @@ void gic_cpu_config(void __iomem *base, void (*sync_access)(void));
 void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
 		void *data);
 
+void gic_set_kvm_info(const struct gic_kvm_info *info);
+
 #endif /* _IRQ_GIC_COMMON_H */
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index d6131c4..b794fd0 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -102,6 +102,8 @@ static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;
 
 static struct gic_chip_data gic_data[CONFIG_ARM_GIC_MAX_NR] __read_mostly;
 
+static struct gic_kvm_info gic_v2_kvm_info;
+
 #ifdef CONFIG_GIC_NON_BANKED
 static void __iomem *gic_get_percpu_base(union gic_base *base)
 {
@@ -1190,6 +1192,35 @@ static bool gic_check_eoimode(struct device_node *node, void __iomem **base)
 	return true;
 }
 
+static void __init gic_of_setup_kvm_info(struct device_node *node)
+{
+	int ret;
+	struct resource r;
+
+	gic_v2_kvm_info.type = GIC_V2;
+
+	gic_v2_kvm_info.maint_irq = irq_of_parse_and_map(node, 0);
+
+	ret = of_address_to_resource(node, 2, &r);
+	if (!ret)
+		gic_v2_kvm_info.vctrl = r;
+
+	ret = of_address_to_resource(node, 3, &r);
+	if (!ret) {
+		if (!PAGE_ALIGNED(r.start))
+			pr_warn("GICV physical address 0x%llx not page aligned\n",
+				(unsigned long long)r.start);
+		else if (!PAGE_ALIGNED(resource_size(&r)))
+			pr_warn("GICV size 0x%llx not a multiple of page size 0x%lx\n",
+				(unsigned long long)resource_size(&r),
+				PAGE_SIZE);
+		else
+			gic_v2_kvm_info.vcpu = r;
+	}
+
+	gic_set_kvm_info(&gic_v2_kvm_info);
+}
+
 int __init
 gic_of_init(struct device_node *node, struct device_node *parent)
 {
@@ -1219,8 +1250,10 @@ gic_of_init(struct device_node *node, struct device_node *parent)
 
 	__gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset,
 			 &node->fwnode);
-	if (!gic_cnt)
+	if (!gic_cnt) {
 		gic_init_physaddr(node);
+		gic_of_setup_kvm_info(node);
+	}
 
 	if (parent) {
 		irq = irq_of_parse_and_map(node, 0);
@@ -1249,6 +1282,10 @@ IRQCHIP_DECLARE(pl390, "arm,pl390", gic_of_init);
 static struct
 {
 	phys_addr_t cpu_phy_base;
+	u32 maint_irq;
+	int maint_irq_mode;
+	phys_addr_t vctrl_base;
+	phys_addr_t vcpu_base;
 } acpi_data __initdata;
 
 static int __init
@@ -1273,6 +1310,12 @@ gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
 		return -EINVAL;
 
 	acpi_data.cpu_phy_base = gic_cpu_base;
+	acpi_data.maint_irq = processor->vgic_interrupt;
+	acpi_data.maint_irq_mode = (processor->flags & ACPI_MADT_VGIC_IRQ_MODE) ?
+				    ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
+	acpi_data.vctrl_base = processor->gich_base_address;
+	acpi_data.vcpu_base = processor->gicv_base_address;
+
 	cpu_base_assigned = 1;
 	return 0;
 }
@@ -1303,6 +1346,39 @@ static bool __init gic_validate_dist(struct acpi_subtable_header *header,
 
 #define ACPI_GICV2_DIST_MEM_SIZE	(SZ_4K)
 #define ACPI_GIC_CPU_IF_MEM_SIZE	(SZ_8K)
+#define ACPI_GICV2_VCTRL_MEM_SIZE	(SZ_4K)
+#define ACPI_GICV2_VCPU_MEM_SIZE	(SZ_8K)
+
+static void __init gic_acpi_setup_kvm_info(void)
+{
+	int irq;
+
+	gic_v2_kvm_info.type = GIC_V2;
+
+	irq = acpi_register_gsi(NULL, acpi_data.maint_irq,
+				acpi_data.maint_irq_mode,
+				ACPI_ACTIVE_HIGH);
+	if (irq > 0)
+		gic_v2_kvm_info.maint_irq = irq;
+
+	if (acpi_data.vctrl_base) {
+		struct resource *vctrl = &gic_v2_kvm_info.vctrl;
+
+		vctrl->flags = IORESOURCE_MEM;
+		vctrl->start = acpi_data.vctrl_base;
+		vctrl->end = vctrl->start + ACPI_GICV2_VCTRL_MEM_SIZE - 1;
+	}
+
+	if (acpi_data.vcpu_base) {
+		struct resource *vcpu = &gic_v2_kvm_info.vcpu;
+
+		vcpu->flags = IORESOURCE_MEM;
+		vcpu->start = acpi_data.vcpu_base;
+		vcpu->end = vcpu->start + ACPI_GICV2_VCPU_MEM_SIZE - 1;
+	}
+
+	gic_set_kvm_info(&gic_v2_kvm_info);
+}
 
 static int __init gic_v2_acpi_init(struct acpi_subtable_header *header,
 				   const unsigned long end)
@@ -1360,6 +1436,8 @@ static int __init gic_v2_acpi_init(struct acpi_subtable_header *header,
 	if (IS_ENABLED(CONFIG_ARM_GIC_V2M))
 		gicv2m_init(NULL, gic_data[0].domain);
 
+	gic_acpi_setup_kvm_info();
+
 	return 0;
 }
 IRQCHIP_ACPI_DECLARE(gic_v2, ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR,
diff --git a/include/linux/irqchip/arm-gic-common.h b/include/linux/irqchip/arm-gic-common.h
new file mode 100644
index 0000000..f7723b9
--- /dev/null
+++ b/include/linux/irqchip/arm-gic-common.h
@@ -0,0 +1,33 @@
+/*
+ * include/linux/irqchip/arm-gic-common.h
+ *
+ * Copyright (C) 2016 ARM Limited, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __LINUX_IRQCHIP_ARM_GIC_COMMON_H
+#define __LINUX_IRQCHIP_ARM_GIC_COMMON_H
+
+#include <linux/types.h>
+#include <linux/ioport.h>
+
+enum gic_type {
+	GIC_V2,
+};
+
+struct gic_kvm_info {
+	/* GIC type */
+	enum gic_type	type;
+	/* Physical address & size of virtual cpu interface */
+	struct resource vcpu;
+	/* Interrupt number */
+	unsigned int	maint_irq;
+	/* Physical address & size of virtual control interface */
+	struct resource vctrl;
+};
+
+const struct gic_kvm_info *gic_get_kvm_info(void);
+
+#endif /* __LINUX_IRQCHIP_ARM_GIC_COMMON_H */
-- 
1.9.1



From julien.grall at arm.com  Thu Feb 11 07:33:24 2016
From: julien.grall at arm.com (Julien Grall)
Date: Thu, 11 Feb 2016 15:33:24 +0000
Subject: [PATCH v2 6/6] KVM: arm/arm64: vgic: Rely on the GIC driver to parse
 the firmware tables
In-Reply-To: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
References: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
Message-ID: <1455204804-31830-7-git-send-email-julien.grall@arm.com>

For now, the firmware tables are parsed 2 times: once in the GIC
drivers, the other time when initializing the vGIC. It means code
duplication and make more tedious to add the support for another
firmware table (like ACPI).

Use the recently introduced helper gic_get_kvm_info() to retrieve
information about the virtual GIC.

With this change, the virtual GIC becomes agnostic to the firmware
table and KVM will be able to initialize the vGIC on ACPI.

Signed-off-by: Julien Grall <julien.grall at arm.com>

---
Cc: Christoffer Dall <christoffer.dall at linaro.org>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: Gleb Natapov <gleb at kernel.org>
Cc: Paolo Bonzini <pbonzini at redhat.com>

    Changes in v2:
        - Use 0 rather than a negative value to know when the maintenance IRQ
        is not present.
        - Use resource for vcpu and vctrl
---
 include/kvm/arm_vgic.h |  7 +++---
 virt/kvm/arm/vgic-v2.c | 67 ++++++++++++++++++--------------------------------
 virt/kvm/arm/vgic-v3.c | 45 ++++++++++-----------------------
 virt/kvm/arm/vgic.c    | 50 ++++++++++++++++++++-----------------
 4 files changed, 68 insertions(+), 101 deletions(-)

diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 13a3d53..ed62772 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -25,6 +25,7 @@
 #include <linux/spinlock.h>
 #include <linux/types.h>
 #include <kvm/iodev.h>
+#include <linux/irqchip/arm-gic-common.h>
 
 #define VGIC_NR_IRQS_LEGACY	256
 #define VGIC_NR_SGIS		16
@@ -357,15 +358,15 @@ bool kvm_vgic_map_is_active(struct kvm_vcpu *vcpu, struct irq_phys_map *map);
 #define vgic_initialized(k)	(!!((k)->arch.vgic.nr_cpus))
 #define vgic_ready(k)		((k)->arch.vgic.ready)
 
-int vgic_v2_probe(struct device_node *vgic_node,
+int vgic_v2_probe(const struct gic_kvm_info *gic_kvm_info,
 		  const struct vgic_ops **ops,
 		  const struct vgic_params **params);
 #ifdef CONFIG_KVM_ARM_VGIC_V3
-int vgic_v3_probe(struct device_node *vgic_node,
+int vgic_v3_probe(const struct gic_kvm_info *gic_kvm_info,
 		  const struct vgic_ops **ops,
 		  const struct vgic_params **params);
 #else
-static inline int vgic_v3_probe(struct device_node *vgic_node,
+static inline int vgic_v3_probe(const struct gic_kvm_info *gic_kvm_info,
 				const struct vgic_ops **ops,
 				const struct vgic_params **params)
 {
diff --git a/virt/kvm/arm/vgic-v2.c b/virt/kvm/arm/vgic-v2.c
index ff02f08..3598cd4 100644
--- a/virt/kvm/arm/vgic-v2.c
+++ b/virt/kvm/arm/vgic-v2.c
@@ -20,9 +20,6 @@
 #include <linux/kvm_host.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
 
 #include <linux/irqchip/arm-gic.h>
 
@@ -177,38 +174,38 @@ static const struct vgic_ops vgic_v2_ops = {
 static struct vgic_params vgic_v2_params;
 
 /**
- * vgic_v2_probe - probe for a GICv2 compatible interrupt controller in DT
- * @node:	pointer to the DT node
- * @ops: 	address of a pointer to the GICv2 operations
- * @params:	address of a pointer to HW-specific parameters
+ * vgic_v2_probe - probe for a GICv2 compatible interrupt controller
+ * @gic_kvm_info:	pointer to the GIC description
+ * @ops:		address of a pointer to the GICv2 operations
+ * @params:		address of a pointer to HW-specific parameters
  *
  * Returns 0 if a GICv2 has been found, with the low level operations
  * in *ops and the HW parameters in *params. Returns an error code
  * otherwise.
  */
-int vgic_v2_probe(struct device_node *vgic_node,
-		  const struct vgic_ops **ops,
-		  const struct vgic_params **params)
+int vgic_v2_probe(const struct gic_kvm_info *gic_kvm_info,
+		   const struct vgic_ops **ops,
+		   const struct vgic_params **params)
 {
 	int ret;
-	struct resource vctrl_res;
-	struct resource vcpu_res;
 	struct vgic_params *vgic = &vgic_v2_params;
+	resource_size_t vctrl_size = resource_size(&gic_kvm_info->vctrl);
 
-	vgic->maint_irq = irq_of_parse_and_map(vgic_node, 0);
-	if (!vgic->maint_irq) {
-		kvm_err("error getting vgic maintenance irq from DT\n");
+	if (!gic_kvm_info->maint_irq) {
+		kvm_err("error getting vgic maintenance irq\n");
 		ret = -ENXIO;
 		goto out;
 	}
+	vgic->maint_irq = gic_kvm_info->maint_irq;
 
-	ret = of_address_to_resource(vgic_node, 2, &vctrl_res);
-	if (ret) {
-		kvm_err("Cannot obtain GICH resource\n");
+	if (!gic_kvm_info->vctrl.start) {
+		kvm_err("GICH not present in the firmware table\n");
+		ret = -ENXIO;
 		goto out;
 	}
 
-	vgic->vctrl_base = of_iomap(vgic_node, 2);
+	vgic->vctrl_base = ioremap(gic_kvm_info->vctrl.start,
+				   resource_size(&gic_kvm_info->vctrl));
 	if (!vgic->vctrl_base) {
 		kvm_err("Cannot ioremap GICH\n");
 		ret = -ENOMEM;
@@ -219,30 +216,15 @@ int vgic_v2_probe(struct device_node *vgic_node,
 	vgic->nr_lr = (vgic->nr_lr & 0x3f) + 1;
 
 	ret = create_hyp_io_mappings(vgic->vctrl_base,
-				     vgic->vctrl_base + resource_size(&vctrl_res),
-				     vctrl_res.start);
+				     vgic->vctrl_base + vctrl_size,
+				     gic_kvm_info->vctrl.start);
 	if (ret) {
-		kvm_err("Cannot map VCTRL into hyp\n");
-		goto out_unmap;
-	}
-
-	if (of_address_to_resource(vgic_node, 3, &vcpu_res)) {
-		kvm_err("Cannot obtain GICV resource\n");
-		ret = -ENXIO;
-		goto out_unmap;
-	}
-
-	if (!PAGE_ALIGNED(vcpu_res.start)) {
-		kvm_err("GICV physical address 0x%llx not page aligned\n",
-			(unsigned long long)vcpu_res.start);
-		ret = -ENXIO;
+		kvm_err("Cannot map VCTLR into hyp\n");
 		goto out_unmap;
 	}
 
-	if (!PAGE_ALIGNED(resource_size(&vcpu_res))) {
-		kvm_err("GICV size 0x%llx not a multiple of page size 0x%lx\n",
-			(unsigned long long)resource_size(&vcpu_res),
-			PAGE_SIZE);
+	if (!gic_kvm_info->vcpu.start) {
+		kvm_err("GICV not present in the firmware table\n");
 		ret = -ENXIO;
 		goto out_unmap;
 	}
@@ -250,10 +232,10 @@ int vgic_v2_probe(struct device_node *vgic_node,
 	vgic->can_emulate_gicv2 = true;
 	kvm_register_device_ops(&kvm_arm_vgic_v2_ops, KVM_DEV_TYPE_ARM_VGIC_V2);
 
-	vgic->vcpu_base = vcpu_res.start;
+	vgic->vcpu_base = gic_kvm_info->vcpu.start;
 
-	kvm_info("%s@%llx IRQ%d\n", vgic_node->name,
-		 vctrl_res.start, vgic->maint_irq);
+	kvm_info("GICH base=0x%llx, GICV base=0x%llx, IRQ=%d\n",
+		 gic_kvm_info->vctrl.start, vgic->vcpu_base, vgic->maint_irq);
 
 	vgic->type = VGIC_V2;
 	vgic->max_gic_vcpus = VGIC_V2_MAX_CPUS;
@@ -264,6 +246,5 @@ int vgic_v2_probe(struct device_node *vgic_node,
 out_unmap:
 	iounmap(vgic->vctrl_base);
 out:
-	of_node_put(vgic_node);
 	return ret;
 }
diff --git a/virt/kvm/arm/vgic-v3.c b/virt/kvm/arm/vgic-v3.c
index 453eafd..92c1f04 100644
--- a/virt/kvm/arm/vgic-v3.c
+++ b/virt/kvm/arm/vgic-v3.c
@@ -20,11 +20,9 @@
 #include <linux/kvm_host.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
 
 #include <linux/irqchip/arm-gic-v3.h>
+#include <linux/irqchip/arm-gic-common.h>
 
 #include <asm/kvm_emulate.h>
 #include <asm/kvm_arm.h>
@@ -217,30 +215,28 @@ static const struct vgic_ops vgic_v3_ops = {
 static struct vgic_params vgic_v3_params;
 
 /**
- * vgic_v3_probe - probe for a GICv3 compatible interrupt controller in DT
- * @node:	pointer to the DT node
- * @ops: 	address of a pointer to the GICv3 operations
- * @params:	address of a pointer to HW-specific parameters
+ * vgic_v3_probe - probe for a GICv3 compatible interrupt controller
+ * @gic_kvm_info:	pointer to the GIC description
+ * @ops:		address of a pointer to the GICv3 operations
+ * @params:		address of a pointer to HW-specific parameters
  *
  * Returns 0 if a GICv3 has been found, with the low level operations
  * in *ops and the HW parameters in *params. Returns an error code
  * otherwise.
  */
-int vgic_v3_probe(struct device_node *vgic_node,
+int vgic_v3_probe(const struct gic_kvm_info *gic_kvm_info,
 		  const struct vgic_ops **ops,
 		  const struct vgic_params **params)
 {
 	int ret = 0;
-	u32 gicv_idx;
-	struct resource vcpu_res;
 	struct vgic_params *vgic = &vgic_v3_params;
 
-	vgic->maint_irq = irq_of_parse_and_map(vgic_node, 0);
-	if (!vgic->maint_irq) {
-		kvm_err("error getting vgic maintenance irq from DT\n");
+	if (!gic_kvm_info->maint_irq) {
+		kvm_err("error getting vgic maintenance irq\n");
 		ret = -ENXIO;
 		goto out;
 	}
+	vgic->maint_irq = gic_kvm_info->maint_irq;
 
 	ich_vtr_el2 = kvm_call_hyp(__vgic_v3_get_ich_vtr_el2);
 
@@ -251,24 +247,11 @@ int vgic_v3_probe(struct device_node *vgic_node,
 	vgic->nr_lr = (ich_vtr_el2 & 0xf) + 1;
 	vgic->can_emulate_gicv2 = false;
 
-	if (of_property_read_u32(vgic_node, "#redistributor-regions", &gicv_idx))
-		gicv_idx = 1;
-
-	gicv_idx += 3; /* Also skip GICD, GICC, GICH */
-	if (of_address_to_resource(vgic_node, gicv_idx, &vcpu_res)) {
+	if (!gic_kvm_info->vcpu.start) {
 		kvm_info("GICv3: no GICV resource entry\n");
 		vgic->vcpu_base = 0;
-	} else if (!PAGE_ALIGNED(vcpu_res.start)) {
-		pr_warn("GICV physical address 0x%llx not page aligned\n",
-			(unsigned long long)vcpu_res.start);
-		vgic->vcpu_base = 0;
-	} else if (!PAGE_ALIGNED(resource_size(&vcpu_res))) {
-		pr_warn("GICV size 0x%llx not a multiple of page size 0x%lx\n",
-			(unsigned long long)resource_size(&vcpu_res),
-			PAGE_SIZE);
-		vgic->vcpu_base = 0;
 	} else {
-		vgic->vcpu_base = vcpu_res.start;
+		vgic->vcpu_base = gic_kvm_info->vcpu.start;
 		vgic->can_emulate_gicv2 = true;
 		kvm_register_device_ops(&kvm_arm_vgic_v2_ops,
 					KVM_DEV_TYPE_ARM_VGIC_V2);
@@ -281,13 +264,11 @@ int vgic_v3_probe(struct device_node *vgic_node,
 	vgic->type = VGIC_V3;
 	vgic->max_gic_vcpus = VGIC_V3_MAX_CPUS;
 
-	kvm_info("%s@%llx IRQ%d\n", vgic_node->name,
-		 vcpu_res.start, vgic->maint_irq);
-
+	kvm_info("GICV base=0x%llx, IRQ=%d\n",
+		 vgic->vcpu_base, vgic->maint_irq);
 	*ops = &vgic_v3_ops;
 	*params = vgic;
 
 out:
-	of_node_put(vgic_node);
 	return ret;
 }
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 043032c..748cb2f 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -21,9 +21,7 @@
 #include <linux/kvm_host.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-#include <linux/of_irq.h>
+#include <linux/irq.h>
 #include <linux/rculist.h>
 #include <linux/uaccess.h>
 
@@ -33,6 +31,7 @@
 #include <trace/events/kvm.h>
 #include <asm/kvm.h>
 #include <kvm/iodev.h>
+#include <linux/irqchip/arm-gic-common.h>
 
 #define CREATE_TRACE_POINTS
 #include "trace.h"
@@ -2389,33 +2388,38 @@ static struct notifier_block vgic_cpu_nb = {
 	.notifier_call = vgic_cpu_notify,
 };
 
-static const struct of_device_id vgic_ids[] = {
-	{ .compatible = "arm,cortex-a15-gic",	.data = vgic_v2_probe, },
-	{ .compatible = "arm,cortex-a7-gic",	.data = vgic_v2_probe, },
-	{ .compatible = "arm,gic-400",		.data = vgic_v2_probe, },
-	{ .compatible = "arm,gic-v3",		.data = vgic_v3_probe, },
-	{},
-};
-
-int kvm_vgic_hyp_init(void)
+static int kvm_vgic_probe(void)
 {
-	const struct of_device_id *matched_id;
-	const int (*vgic_probe)(struct device_node *,const struct vgic_ops **,
-				const struct vgic_params **);
-	struct device_node *vgic_node;
+	const struct gic_kvm_info *gic_kvm_info;
 	int ret;
 
-	vgic_node = of_find_matching_node_and_match(NULL,
-						    vgic_ids, &matched_id);
-	if (!vgic_node) {
-		kvm_err("error: no compatible GIC node found\n");
+	gic_kvm_info = gic_get_kvm_info();
+	if (!gic_kvm_info)
 		return -ENODEV;
+
+	switch (gic_kvm_info->type) {
+	case GIC_V2:
+		ret = vgic_v2_probe(gic_kvm_info, &vgic_ops, &vgic);
+		break;
+	case GIC_V3:
+		ret = vgic_v3_probe(gic_kvm_info, &vgic_ops, &vgic);
+		break;
+	default:
+		ret = -ENODEV;
 	}
 
-	vgic_probe = matched_id->data;
-	ret = vgic_probe(vgic_node, &vgic_ops, &vgic);
-	if (ret)
+	return ret;
+}
+
+int kvm_vgic_hyp_init(void)
+{
+	int ret;
+
+	ret = kvm_vgic_probe();
+	if (ret) {
+		kvm_err("error: KVM vGIC probing failed\n");
 		return ret;
+	}
 
 	ret = request_percpu_irq(vgic->maint_irq, vgic_maintenance_handler,
 				 "vgic", kvm_get_running_vcpus());
-- 
1.9.1



From arnd at arndb.de  Thu Feb 11 07:41:26 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 16:41:26 +0100
Subject: [PATCH v2 0/6] serial: 8250: fixes for modular build
Message-ID: <1455205297-1021302-1-git-send-email-arnd@arndb.de>

This is a re-send of three patches I sent a couple of days ago,
with a revert of two patches that Paul did, taking the code in
the opposite direction now, towards ensuring the drivers actually
work as loadable modules, which helps with 'allmodconfig' build
testing.

I've also added another patch for uniphier, and fixed smaller
related issues that came up in further testing.

	Arnd



From arnd at arndb.de  Thu Feb 11 07:41:27 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 16:41:27 +0100
Subject: [PATCH v2 1/6] Revert "drivers/tty/serial: make 8250/8250_mtk.c
 explicitly non-modular"
In-Reply-To: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
Message-ID: <1455205297-1021302-2-git-send-email-arnd@arndb.de>

This reverts commit d72d391c126e, which tried to remove dead code but
left the driver in a useless state when the main 8250 driver is a
loadable module. This would normally result in a link error, but
as the entire drivers/tty/serial/8250/ directory is only entered
when CONFIG_SERIAL_8250 is set, we never notice that the driver does
not get built in this configuration.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: d72d391c126e ("drivers/tty/serial: make 8250/8250_mtk.c explicitly non-modular")
---
 drivers/tty/serial/8250/8250_mtk.c | 35 ++++++++++++++++++++++++++++-------
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
index 0e590b233f03..78883ca64ddd 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -16,7 +16,7 @@
  */
 #include <linux/clk.h>
 #include <linux/io.h>
-#include <linux/init.h>
+#include <linux/module.h>
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
@@ -245,6 +245,23 @@ static int mtk8250_probe(struct platform_device *pdev)
 	return 0;
 }
 
+static int mtk8250_remove(struct platform_device *pdev)
+{
+	struct mtk8250_data *data = platform_get_drvdata(pdev);
+
+	pm_runtime_get_sync(&pdev->dev);
+
+	serial8250_unregister_port(data->line);
+
+	pm_runtime_disable(&pdev->dev);
+	pm_runtime_put_noidle(&pdev->dev);
+
+	if (!pm_runtime_status_suspended(&pdev->dev))
+		mtk8250_runtime_suspend(&pdev->dev);
+
+	return 0;
+}
+
 #ifdef CONFIG_PM_SLEEP
 static int mtk8250_suspend(struct device *dev)
 {
@@ -275,18 +292,18 @@ static const struct of_device_id mtk8250_of_match[] = {
 	{ .compatible = "mediatek,mt6577-uart" },
 	{ /* Sentinel */ }
 };
+MODULE_DEVICE_TABLE(of, mtk8250_of_match);
 
 static struct platform_driver mtk8250_platform_driver = {
 	.driver = {
-		.name			= "mt6577-uart",
-		.pm			= &mtk8250_pm_ops,
-		.of_match_table		= mtk8250_of_match,
-		.suppress_bind_attrs	= true,
-
+		.name		= "mt6577-uart",
+		.pm		= &mtk8250_pm_ops,
+		.of_match_table	= mtk8250_of_match,
 	},
 	.probe			= mtk8250_probe,
+	.remove			= mtk8250_remove,
 };
-builtin_platform_driver(mtk8250_platform_driver);
+module_platform_driver(mtk8250_platform_driver);
 
 #ifdef CONFIG_SERIAL_8250_CONSOLE
 static int __init early_mtk8250_setup(struct earlycon_device *device,
@@ -302,3 +319,7 @@ static int __init early_mtk8250_setup(struct earlycon_device *device,
 
 OF_EARLYCON_DECLARE(mtk8250, "mediatek,mt6577-uart", early_mtk8250_setup);
 #endif
+
+MODULE_AUTHOR("Matthias Brugger");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Mediatek 8250 serial port driver");
-- 
2.7.0



From arnd at arndb.de  Thu Feb 11 07:41:28 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 16:41:28 +0100
Subject: [PATCH v2 2/6] Revert "drivers/tty/serial: make 8250/8250_ingenic.c
 explicitly non-modular"
In-Reply-To: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
Message-ID: <1455205297-1021302-3-git-send-email-arnd@arndb.de>

This reverts commit cafe1ac64023, which tried to remove dead code but
left the driver in a useless state when the main 8250 driver is a
loadable module. This would normally result in a link error, but
as the entire drivers/tty/serial/8250/ directory is only entered
when CONFIG_SERIAL_8250 is set, we never notice that the driver does
not get built in this configuration.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: cafe1ac64023 ("drivers/tty: make serial 8250_ingenic.c explicitly non-modular")
---
 drivers/tty/serial/8250/8250_ingenic.c | 28 +++++++++++++++++++++-------
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_ingenic.c b/drivers/tty/serial/8250/8250_ingenic.c
index b4e1d39805b2..97b78558caed 100644
--- a/drivers/tty/serial/8250/8250_ingenic.c
+++ b/drivers/tty/serial/8250/8250_ingenic.c
@@ -4,8 +4,6 @@
  *
  * Ingenic SoC UART support
  *
- * Author: Paul Burton <paul.burton at imgtec.com>
- *
  * This program is free software; you can redistribute	 it and/or modify it
  * under  the terms of	 the GNU General  Public License as published by the
  * Free Software Foundation;  either version 2 of the	License, or (at your
@@ -20,7 +18,7 @@
 #include <linux/console.h>
 #include <linux/io.h>
 #include <linux/libfdt.h>
-#include <linux/init.h>
+#include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_fdt.h>
 #include <linux/of_device.h>
@@ -303,6 +301,16 @@ out:
 	return err;
 }
 
+static int ingenic_uart_remove(struct platform_device *pdev)
+{
+	struct ingenic_uart_data *data = platform_get_drvdata(pdev);
+
+	serial8250_unregister_port(data->line);
+	clk_disable_unprepare(data->clk_module);
+	clk_disable_unprepare(data->clk_baud);
+	return 0;
+}
+
 static const struct ingenic_uart_config jz4740_uart_config = {
 	.tx_loadsz = 8,
 	.fifosize = 16,
@@ -325,13 +333,19 @@ static const struct of_device_id of_match[] = {
 	{ .compatible = "ingenic,jz4780-uart", .data = &jz4780_uart_config },
 	{ /* sentinel */ }
 };
+MODULE_DEVICE_TABLE(of, of_match);
 
 static struct platform_driver ingenic_uart_platform_driver = {
 	.driver = {
-		.name			= "ingenic-uart",
-		.of_match_table		= of_match,
-		.suppress_bind_attrs	= true,
+		.name		= "ingenic-uart",
+		.of_match_table	= of_match,
 	},
 	.probe			= ingenic_uart_probe,
+	.remove			= ingenic_uart_remove,
 };
-builtin_platform_driver(ingenic_uart_platform_driver);
+
+module_platform_driver(ingenic_uart_platform_driver);
+
+MODULE_AUTHOR("Paul Burton");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Ingenic SoC UART driver");
-- 
2.7.0



From arnd at arndb.de  Thu Feb 11 07:41:29 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 16:41:29 +0100
Subject: [PATCH v2 3/6] serial: 8250/mediatek: mark PM functions as
 __maybe_unused
In-Reply-To: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
Message-ID: <1455205297-1021302-4-git-send-email-arnd@arndb.de>

The mtk8250_runtime_suspend function is not used when runtime PM is
disabled, so we get a warning about an unused function:

drivers/tty/serial/8250/8250_mtk.c:119:12: error: 'mtk8250_runtime_suspend' defined but not used [-Werror=unused-function]
 static int mtk8250_runtime_suspend(struct device *dev)

This marks all the PM functions as __maybe_unused to avoid the warning,
and removes the #ifdef around the PM_SLEEP functions for consistency.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Matthias Brugger <matthias.bgg at gmail.com>
---
 drivers/tty/serial/8250/8250_mtk.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
index 78883ca64ddd..6ecc6e3e82dc 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -116,7 +116,7 @@ mtk8250_set_termios(struct uart_port *port, struct ktermios *termios,
 		tty_termios_encode_baud_rate(termios, baud, baud);
 }
 
-static int mtk8250_runtime_suspend(struct device *dev)
+static int __maybe_unused mtk8250_runtime_suspend(struct device *dev)
 {
 	struct mtk8250_data *data = dev_get_drvdata(dev);
 
@@ -126,7 +126,7 @@ static int mtk8250_runtime_suspend(struct device *dev)
 	return 0;
 }
 
-static int mtk8250_runtime_resume(struct device *dev)
+static int __maybe_unused mtk8250_runtime_resume(struct device *dev)
 {
 	struct mtk8250_data *data = dev_get_drvdata(dev);
 	int err;
@@ -262,8 +262,7 @@ static int mtk8250_remove(struct platform_device *pdev)
 	return 0;
 }
 
-#ifdef CONFIG_PM_SLEEP
-static int mtk8250_suspend(struct device *dev)
+static int __maybe_unused mtk8250_suspend(struct device *dev)
 {
 	struct mtk8250_data *data = dev_get_drvdata(dev);
 
@@ -272,7 +271,7 @@ static int mtk8250_suspend(struct device *dev)
 	return 0;
 }
 
-static int mtk8250_resume(struct device *dev)
+static int __maybe_unused mtk8250_resume(struct device *dev)
 {
 	struct mtk8250_data *data = dev_get_drvdata(dev);
 
@@ -280,7 +279,6 @@ static int mtk8250_resume(struct device *dev)
 
 	return 0;
 }
-#endif /* CONFIG_PM_SLEEP */
 
 static const struct dev_pm_ops mtk8250_pm_ops = {
 	SET_SYSTEM_SLEEP_PM_OPS(mtk8250_suspend, mtk8250_resume)
-- 
2.7.0



From arnd at arndb.de  Thu Feb 11 07:41:30 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 16:41:30 +0100
Subject: [PATCH v2 4/6] serial: 8250/uniphier: fix modular build
In-Reply-To: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
Message-ID: <1455205297-1021302-5-git-send-email-arnd@arndb.de>

The newly added uniphier serial port driver fails to build as
a loadable module when the base 8250 driver is built-in and
its console support enabled:

ERROR: "early_serial8250_setup" [drivers/tty/serial/8250/8250_uniphier.ko] undefined!

This changes the driver to only provide the early console support
if it is built-in itself as well.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/tty/serial/8250/8250_uniphier.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_uniphier.c b/drivers/tty/serial/8250/8250_uniphier.c
index bab6b3ae2540..1b7bd26555b7 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -35,7 +35,7 @@ struct uniphier8250_priv {
 	spinlock_t atomic_write_lock;
 };
 
-#ifdef CONFIG_SERIAL_8250_CONSOLE
+#if defined(CONFIG_SERIAL_8250_CONSOLE) && !defined(MODULE)
 static int __init uniphier_early_console_setup(struct earlycon_device *device,
 					       const char *options)
 {
-- 
2.7.0



From arnd at arndb.de  Thu Feb 11 07:41:31 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 16:41:31 +0100
Subject: [PATCH v2 5/6] serial: 8250/mediatek: fix building with SERIAL_8250=m
In-Reply-To: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
Message-ID: <1455205297-1021302-6-git-send-email-arnd@arndb.de>

The Mediatek 8250 driver has a 'bool' Kconfig symbol, but that
breaks when SERIAL_8250 is a loadable module:

drivers/tty/built-in.o: In function `mtk8250_set_termios':
:(.text+0x1bee8): undefined reference to `serial8250_do_set_termios'
:(.text+0x1bf10): undefined reference to `uart_get_baud_rate'
:(.text+0x1c09c): undefined reference to `uart_get_divisor'
drivers/tty/built-in.o: In function `mtk8250_do_pm':
:(.text+0x1c0d0): undefined reference to `serial8250_do_pm'
drivers/tty/built-in.o: In function `mtk8250_probe':
:(.text+0x1c2e4): undefined reference to `serial8250_register_8250_port'
serial/8250/8250_mtk.c:287:242: error: data definition has no type or storage class [-Werror]
serial/8250/8250_mtk.c:287:122: error: 'mtk8250_platform_driver_init' defined but not used [-Werror=unused-function]

This changes the symbol to a 'tristate', so the dependency on
SERIAL_8250 also works when that is set to 'm'.
To actually build the driver, we also need to include <linux/module.h>.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/tty/serial/8250/8250_mtk.c | 3 ++-
 drivers/tty/serial/8250/Kconfig    | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
index 6ecc6e3e82dc..55be90c1d85e 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -19,6 +19,7 @@
 #include <linux/module.h>
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
+#include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/serial_8250.h>
@@ -303,7 +304,7 @@ static struct platform_driver mtk8250_platform_driver = {
 };
 module_platform_driver(mtk8250_platform_driver);
 
-#ifdef CONFIG_SERIAL_8250_CONSOLE
+#if defined(CONFIG_SERIAL_8250_CONSOLE) && !defined(MODULE)
 static int __init early_mtk8250_setup(struct earlycon_device *device,
 					const char *options)
 {
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index 67ad6b0d595b..6ae0fae4f796 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -370,7 +370,7 @@ config SERIAL_8250_LPC18XX
 	  serial port, say Y to this option. If unsure, say Y.
 
 config SERIAL_8250_MT6577
-	bool "Mediatek serial port support"
+	tristate "Mediatek serial port support"
 	depends on SERIAL_8250 && ARCH_MEDIATEK
 	help
 	  If you have a Mediatek based board and want to use the
-- 
2.7.0



From arnd at arndb.de  Thu Feb 11 07:41:32 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 16:41:32 +0100
Subject: [PATCH v2 6/6] serial: 8250/ingenic: fix building with SERIAL_8250=m
In-Reply-To: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
Message-ID: <1455205297-1021302-7-git-send-email-arnd@arndb.de>

The Ingenic 8250 driver has a 'bool' Kconfig symbol, but that
breaks when SERIAL_8250 is a loadable module:

drivers/tty/built-in.o: In function `ingenic_uart_probe':
8250_ingenic.c:(.text+0x1c1a0): undefined reference to `serial8250_register_8250_port'

This changes the symbol to a 'tristate', plus a dependency on
SERIAL_8250, which makes it work again. Unlike the other
soc-specific backends, this one has no dependency on an
architecture or a platform. I'm adding a dependency on
MIPS || COMPILE_TEST as well here, to avoid showing the driver
on architectures that are not interested in it.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/tty/serial/8250/8250_ingenic.c | 2 +-
 drivers/tty/serial/8250/Kconfig        | 7 ++++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_ingenic.c b/drivers/tty/serial/8250/8250_ingenic.c
index 97b78558caed..b0677f610863 100644
--- a/drivers/tty/serial/8250/8250_ingenic.c
+++ b/drivers/tty/serial/8250/8250_ingenic.c
@@ -48,7 +48,7 @@ static const struct of_device_id of_match[];
 #define UART_MCR_MDCE	BIT(7)
 #define UART_MCR_FCM	BIT(6)
 
-#ifdef CONFIG_SERIAL_EARLYCON
+#if defined(CONFIG_SERIAL_EARLYCON) && !defined(MODULE)
 static struct earlycon_device *early_device;
 
 static uint8_t __init early_in(struct uart_port *port, int offset)
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index 6ae0fae4f796..32df7d5a1733 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -384,9 +384,10 @@ config SERIAL_8250_UNIPHIER
 	  serial ports, say Y to this option. If unsure, say N.
 
 config SERIAL_8250_INGENIC
-	bool "Support for Ingenic SoC serial ports"
-	depends on OF_FLATTREE
-	select LIBFDT
+	tristate "Support for Ingenic SoC serial ports"
+	depends on SERIAL_8250
+	depends on (OF_FLATTREE && SERIAL_8250_CONSOLE) || !SERIAL_8250_CONSOLE
+	depends on MIPS || COMPILE_TEST
 	help
 	  If you have a system using an Ingenic SoC and wish to make use of
 	  its UARTs, say Y to this option. If unsure, say N.
-- 
2.7.0



From marc.zyngier at arm.com  Thu Feb 11 07:45:26 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 15:45:26 +0000
Subject: [PATCH] irqchip/gic-v3-its: Fix double EOIR write for LPI in
 EOImode==1
In-Reply-To: <1455197933-26141-1-git-send-email-ashoks@broadcom.com>
References: <1455197933-26141-1-git-send-email-ashoks@broadcom.com>
Message-ID: <56BCAC96.7040509@arm.com>

On 11/02/16 13:38, Ashok Kumar wrote:
> CPU receives SError exception EOI1_NO_INTS_ACTIVE when EOIR
> is written twice in gic_handle_irq and in its_eoi_irq for a
> single LPI in EOImode == 1.
> 
> Now irq_eoi of its_irq_chip calls parent irqchip's(gic_eoimode1_chip/gic_chip)
> irq_eoi handler which handles EOImode 0 and 1 separately.
> 
> This is introduced by
> commit 0b996fd35957a ("irqchip/GICv3: Convert to EOImode == 1")
> 
> Signed-off-by: Ashok Kumar <ashoks at broadcom.com>

Ah, really good catch!

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

I'll try to queue that for -rc4, but it is more likely that it will land
in -rc5...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From LW at KARO-electronics.de  Thu Feb 11 07:45:54 2016
From: LW at KARO-electronics.de (Lothar =?UTF-8?B?V2HDn21hbm4=?=)
Date: Thu, 11 Feb 2016 16:45:54 +0100
Subject: [PATCH 3/3] crypto: add basic driver for the MXC SCC
In-Reply-To: <1455199485-24458-3-git-send-email-s.trumtrar@pengutronix.de>
References: <1455199485-24458-1-git-send-email-s.trumtrar@pengutronix.de>
 <1455199485-24458-3-git-send-email-s.trumtrar@pengutronix.de>
Message-ID: <20160211164554.4091ab73@ipc1.ka-ro>

Hi,

On Thu, 11 Feb 2016 15:04:45 +0100 Steffen Trumtrar wrote:
> According to the Freescale GPL driver code, there are two different
> Security Controller (SCC) versions: SCC and SCC2.
> 
> The SCC is found on older i.MX SoCs, e.g. the i.MX25. This is the
> version implemented and tested here.
> 
> As there is no publicly available documentation for this IP core,
> all information about this unit is gathered from the GPL'ed driver
> from Freescale.
> 
> Signed-off-by: Steffen Trumtrar <s.trumtrar at pengutronix.de>
> ---
>  drivers/crypto/Kconfig   |   9 +
>  drivers/crypto/Makefile  |   1 +
>  drivers/crypto/mxc-scc.c | 756 +++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 766 insertions(+)
>  create mode 100644 drivers/crypto/mxc-scc.c
> 
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 07d494276aad..ece3e231ee4d 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -339,6 +339,15 @@ config CRYPTO_DEV_SAHARA
>  	  This option enables support for the SAHARA HW crypto accelerator
>  	  found in some Freescale i.MX chips.
>  
> +config CRYPTO_DEV_MXC_SCC
> +	tristate "Support for Freescale Security Controller (SCC)"
> +	depends on ARCH_MXC && OF
> +	select CRYPTO_BLKCIPHER
> +	select CRYPTO_DES
> +	help
> +	  This option enables support for the Security Controller (SCC)
> +	  found in Freescale i.MX25 chips.
> +
>  config CRYPTO_DEV_S5P
>  	tristate "Support for Samsung S5PV210/Exynos crypto accelerator"
>  	depends on ARCH_S5PV210 || ARCH_EXYNOS
> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
> index 713de9d11148..3c6432dd09d9 100644
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_CRYPTO_DEV_PICOXCELL) += picoxcell_crypto.o
>  obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/
>  obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o
>  obj-$(CONFIG_CRYPTO_DEV_SAHARA) += sahara.o
> +obj-$(CONFIG_CRYPTO_DEV_MXC_SCC) += mxc-scc.o
>  obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
>  obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
>  obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
> diff --git a/drivers/crypto/mxc-scc.c b/drivers/crypto/mxc-scc.c
> new file mode 100644
> index 000000000000..f8cc00d1d92e
> --- /dev/null
> +++ b/drivers/crypto/mxc-scc.c
> @@ -0,0 +1,756 @@
> +/*
> + * Copyright (C) 2016 Pengutronix, Steffen Trumtrar <kernel at pengutronix.de>
> + *
> + * The driver is based on information gathered from
> + * drivers/mxc/security/mxc_scc.c which can be found in
> + * the Freescale linux-2.6-imx.git in the imx_2.6.35_maintain branch.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include <linux/clk.h>
> +#include <linux/crypto.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/irq.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +
> +#include <crypto/algapi.h>
> +#include <crypto/des.h>
> +
> +/* Secure Memory (SCM) registers */
> +#define SCC_SCM_RED_START		0x0000
> +#define SCC_SCM_BLACK_START		0x0004
> +#define SCC_SCM_LENGTH			0x0008
> +#define SCC_SCM_CTRL			0x000C
> +#define SCC_SCM_STATUS			0x0010
> +#define SCC_SCM_ERROR_STATUS		0x0014
> +#define SCC_SCM_INTR_CTRL		0x0018
> +#define SCC_SCM_CFG			0x001C
> +#define SCC_SCM_INIT_VECTOR_0		0x0020
> +#define SCC_SCM_INIT_VECTOR_1		0x0024
> +#define SCC_SCM_RED_MEMORY		0x0400
> +#define SCC_SCM_BLACK_MEMORY		0x0800
> +
> +/* Security Monitor (SMN) Registers */
> +#define SCC_SMN_STATUS			0x1000
> +#define SCC_SMN_COMMAND		0x1004
> +#define SCC_SMN_SEQ_START		0x1008
> +#define SCC_SMN_SEQ_END		0x100C
> +#define SCC_SMN_SEQ_CHECK		0x1010
> +#define SCC_SMN_BIT_COUNT		0x1014
> +#define SCC_SMN_BITBANK_INC_SIZE	0x1018
> +#define SCC_SMN_BITBANK_DECREMENT	0x101C
> +#define SCC_SMN_COMPARE_SIZE		0x1020
> +#define SCC_SMN_PLAINTEXT_CHECK	0x1024
> +#define SCC_SMN_CIPHERTEXT_CHECK	0x1028
> +#define SCC_SMN_TIMER_IV		0x102C
> +#define SCC_SMN_TIMER_CONTROL		0x1030
> +#define SCC_SMN_DEBUG_DETECT_STAT	0x1034
> +#define SCC_SMN_TIMER			0x1038
> +
> +#define SCC_SCM_CTRL_START_CIPHER	BIT(2)
> +#define SCC_SCM_CTRL_CBC_MODE		BIT(1)
> +#define SCC_SCM_CTRL_DECRYPT_MODE	BIT(0)
> +
> +#define SCC_SCM_STATUS_LEN_ERR		BIT(12)
> +#define SCC_SCM_STATUS_SMN_UNBLOCKED	BIT(11)
> +#define SCC_SCM_STATUS_CIPHERING_DONE	BIT(10)
> +#define SCC_SCM_STATUS_ZEROIZING_DONE	BIT(9)
> +#define SCC_SCM_STATUS_INTR_STATUS	BIT(8)
> +#define SCC_SCM_STATUS_SEC_KEY		BIT(7)
> +#define SCC_SCM_STATUS_INTERNAL_ERR	BIT(6)
> +#define SCC_SCM_STATUS_BAD_SEC_KEY	BIT(5)
> +#define SCC_SCM_STATUS_ZEROIZE_FAIL	BIT(4)
> +#define SCC_SCM_STATUS_SMN_BLOCKED	BIT(3)
> +#define SCC_SCM_STATUS_CIPHERING	BIT(2)
> +#define SCC_SCM_STATUS_ZEROIZING	BIT(1)
> +#define SCC_SCM_STATUS_BUSY		BIT(0)
> +
> +#define SCC_SMN_STATUS_STATE_MASK	0x0000001F
> +#define SCC_SMN_STATE_START		0x0
> +/* The SMN is zeroizing its RAM during reset */
> +#define SCC_SMN_STATE_ZEROIZE_RAM	0x5
> +/* SMN has passed internal checks */
> +#define SCC_SMN_STATE_HEALTH_CHECK	0x6
> +/* Fatal Security Violation. SMN is locked, SCM is inoperative. */
> +#define SCC_SMN_STATE_FAIL		0x9
> +/* SCC is in secure state. SCM is using secret key. */
> +#define SCC_SMN_STATE_SECURE		0xA
> +/* SCC is not secure. SCM is using default key. */
> +#define SCC_SMN_STATE_NON_SECURE	0xC
> +
> +#define SCC_SCM_INTR_CTRL_ZEROIZE_MEM	BIT(2)
> +#define SCC_SCM_INTR_CTRL_CLR_INTR	BIT(1)
> +#define SCC_SCM_INTR_CTRL_MASK_INTR	BIT(0)
> +
> +/* Size, in blocks, of Red memory. */
> +#define SCC_SCM_CFG_BLACK_SIZE_MASK	0x07fe0000
> +#define SCC_SCM_CFG_BLACK_SIZE_SHIFT	17
> +/* Size, in blocks, of Black memory. */
> +#define SCC_SCM_CFG_RED_SIZE_MASK	0x0001ff80
> +#define SCC_SCM_CFG_RED_SIZE_SHIFT	7
> +/* Number of bytes per block. */
> +#define SCC_SCM_CFG_BLOCK_SIZE_MASK	0x0000007f
> +
> +#define SCC_SMN_COMMAND_TAMPER_LOCK	BIT(4)
> +#define SCC_SMN_COMMAND_CLR_INTR	BIT(3)
> +#define SCC_SMN_COMMAND_CLR_BIT_BANK	BIT(2)
> +#define SCC_SMN_COMMAND_EN_INTR	BIT(1)
> +#define SCC_SMN_COMMAND_SET_SOFTWARE_ALARM  BIT(0)
> +
> +#define SCC_KEY_SLOTS			20
> +#define SCC_MAX_KEY_SIZE		32
> +#define SCC_KEY_SLOT_SIZE		32
> +
> +#define SCC_CRC_CCITT_START		0xFFFF
> +
> +/*
> + * Offset into each RAM of the base of the area which is not
> + * used for Stored Keys.
> + */
> +#define SCC_NON_RESERVED_OFFSET	(SCC_KEY_SLOTS * SCC_KEY_SLOT_SIZE)
> +
> +/* Fixed padding for appending to plaintext to fill out a block */
> +static char scc_block_padding[8] = { 0x80, 0, 0, 0, 0, 0, 0, 0 };
> +
> +enum mxc_scc_state {
> +	SCC_STATE_OK,
> +	SCC_STATE_UNIMPLEMENTED,
> +	SCC_STATE_FAILED
> +};
> +
> +struct mxc_scc {
> +	struct device		*dev;
> +	void __iomem		*base;
> +	struct clk		*clk;
> +	struct mutex		mutex;
> +	spinlock_t		lock;
> +	struct crypto_queue	queue;
> +	struct crypto_async_request *req;
> +	int			block_size_bytes;
> +	int			black_ram_size_blocks;
> +	int			memory_size_bytes;
> +	int			bytes_remaining;
> +
> +	void __iomem		*red_memory;
> +	void __iomem		*black_memory;
> +};
> +
> +struct mxc_scc_ctx {
> +	struct mxc_scc		*scc;
> +	struct scatterlist	*sg_src;
> +	size_t			src_nents;
> +	struct scatterlist	*sg_dst;
> +	size_t			dst_nents;
> +	unsigned int		offset;
> +	unsigned int		size;
> +	unsigned int		ctrl;
> +};
> +
> +struct mxc_scc_crypto_tmpl {
> +	struct mxc_scc *scc;
> +	struct crypto_alg alg;
> +};
> +
> +static int mxc_scc_get_data(struct mxc_scc_ctx *ctx,
> +			    struct crypto_async_request *req)
> +{
> +	struct ablkcipher_request *ablkreq = ablkcipher_request_cast(req);
> +	struct mxc_scc *scc = ctx->scc;
> +	size_t len;
> +	void __iomem *from;
> +
> +	if (ctx->ctrl & SCC_SCM_CTRL_DECRYPT_MODE)
> +		from = scc->red_memory;
> +	else
> +		from = scc->black_memory;
> +
> +	dev_dbg(scc->dev, "pcopy: from 0x%p %d bytes\n", from,
> +		ctx->dst_nents * 8);
> +	len = sg_pcopy_from_buffer(ablkreq->dst, ctx->dst_nents,
> +				   from, ctx->size, ctx->offset);
> +	if (!len) {
> +		dev_err(scc->dev, "pcopy err from 0x%p (len=%d)\n", from, len);
> +		return -EINVAL;
> +	}
> +
> +#ifdef DEBUG
> +	print_hex_dump(KERN_ERR,
> +		       "red memory@"__stringify(__LINE__)": ",
> +		       DUMP_PREFIX_ADDRESS, 16, 4,
> +		       scc->red_memory, ctx->size, 1);
> +	print_hex_dump(KERN_ERR,
> +		       "black memory@"__stringify(__LINE__)": ",
> +		       DUMP_PREFIX_ADDRESS, 16, 4,
> +		       scc->black_memory, ctx->size, 1);
> +#endif
> +
> +	ctx->offset += len;
> +
> +	if (ctx->offset < ablkreq->nbytes)
> +		return -EINPROGRESS;
> +
> +	return 0;
> +}
> +
> +static int mxc_scc_ablkcipher_req_init(struct ablkcipher_request *req,
> +				       struct mxc_scc_ctx *ctx)
> +{
> +	struct mxc_scc *scc = ctx->scc;
> +
> +	ctx->src_nents = sg_nents_for_len(req->src, req->nbytes);
> +	if (ctx->src_nents < 0) {
> +		dev_err(scc->dev, "Invalid number of src SC");
> +		return ctx->src_nents;
> +	}
> +
> +	ctx->dst_nents = sg_nents_for_len(req->dst, req->nbytes);
> +	if (ctx->dst_nents < 0) {
> +		dev_err(scc->dev, "Invalid number of dst SC");
> +		return ctx->dst_nents;
> +	}
> +
> +	ctx->size = 0;
> +	ctx->offset = 0;
> +
> +	return 0;
> +}
> +
> +static int mxc_scc_put_data(struct mxc_scc_ctx *ctx,
> +			     struct ablkcipher_request *req)
> +{
> +	u8 padding_buffer[sizeof(u16) + sizeof(scc_block_padding)];
> +	size_t len = min_t(size_t, req->nbytes - ctx->offset,
> +			   ctx->scc->bytes_remaining);
> +	unsigned int padding_byte_count = 0;
> +	struct mxc_scc *scc = ctx->scc;
> +	void __iomem *to;
> +
> +	if (ctx->ctrl & SCC_SCM_CTRL_DECRYPT_MODE)
> +		to = scc->black_memory;
> +	else
> +		to = scc->red_memory;
> +
> +	if (ctx->ctrl & SCC_SCM_CTRL_CBC_MODE && req->info)
> +		memcpy(scc->base + SCC_SCM_INIT_VECTOR_0, req->info,
> +		       scc->block_size_bytes);
> +
> +	len = sg_pcopy_to_buffer(req->src, ctx->src_nents,
> +				 to, len, ctx->offset);
> +	if (!len) {
> +		dev_err(scc->dev, "pcopy err to 0x%p (len=%d)\n", to, len);
> +		return -EINVAL;
> +	}
> +
> +	ctx->size = len;
> +
> +#ifdef DEBUG
> +	dev_dbg(scc->dev, "copied %d bytes to 0x%p\n", len, to);
> +	print_hex_dump(KERN_ERR,
> +		       "init vector0@"__stringify(__LINE__)": ",
> +		       DUMP_PREFIX_ADDRESS, 16, 4,
> +		       scc->base + SCC_SCM_INIT_VECTOR_0, scc->block_size_bytes,
> +		       1);
> +	print_hex_dump(KERN_ERR,
> +		       "red memory@"__stringify(__LINE__)": ",
> +		       DUMP_PREFIX_ADDRESS, 16, 4,
> +		       scc->red_memory, ctx->size, 1);
> +	print_hex_dump(KERN_ERR,
> +		       "black memory@"__stringify(__LINE__)": ",
> +		       DUMP_PREFIX_ADDRESS, 16, 4,
> +		       scc->black_memory, ctx->size, 1);
> +#endif
> +
> +	scc->bytes_remaining -= len;
> +
> +	padding_byte_count = len % scc->block_size_bytes;
> +
> +	if (padding_byte_count) {
> +		memcpy(padding_buffer, scc_block_padding, padding_byte_count);
> +		memcpy(to + len, padding_buffer, padding_byte_count);
> +		ctx->size += padding_byte_count;
> +	}
> +
> +#ifdef DEBUG
> +	print_hex_dump(KERN_ERR,
> +		       "data to encrypt@"__stringify(__LINE__)": ",
> +		       DUMP_PREFIX_ADDRESS, 16, 4,
> +		       to, ctx->size, 1);
> +#endif
> +
> +	return 0;
> +}
> +
> +static void mxc_scc_ablkcipher_next(struct mxc_scc_ctx *ctx,
> +				    struct crypto_async_request *req)
> +{
> +	struct ablkcipher_request *ablkreq = ablkcipher_request_cast(req);
> +	struct mxc_scc *scc = ctx->scc;
> +	int err;
> +
> +	mutex_lock(&scc->mutex);
> +
> +	dev_dbg(scc->dev, "dispatch request (nbytes=%d, src=%p, dst=%p)\n",
> +		ablkreq->nbytes, ablkreq->src, ablkreq->dst);
> +
> +	writel(0, scc->base + SCC_SCM_ERROR_STATUS);
> +
> +	err = mxc_scc_put_data(ctx, ablkreq);
> +	if (err)
> +		mutex_unlock(&scc->mutex);
> +
Did you really intend to continue with the mutex unlocked in case of
error, or should the error condition be conveyed to the caller somehow?

> +	dev_dbg(scc->dev, "Start encryption (0x%p/0x%p)\n",
> +		(void *)readl(scc->base + SCC_SCM_RED_START),
> +		(void *)readl(scc->base + SCC_SCM_BLACK_START));
> +
> +	/* clear interrupt control registers */
> +	writel(SCC_SCM_INTR_CTRL_CLR_INTR,
> +	       scc->base + SCC_SCM_INTR_CTRL);
> +
> +	writel((ctx->size / ctx->scc->block_size_bytes) - 1,
> +	       scc->base + SCC_SCM_LENGTH);
> +
> +	dev_dbg(scc->dev, "Process %d block(s) in 0x%p\n",
> +		ctx->size / ctx->scc->block_size_bytes,
> +		(ctx->ctrl & SCC_SCM_CTRL_DECRYPT_MODE) ? scc->black_memory :
> +		scc->red_memory);
> +
> +	writel(ctx->ctrl, scc->base + SCC_SCM_CTRL);
> +}
> +
> +static irqreturn_t mxc_scc_int(int irq, void *priv)
> +{
> +	struct crypto_async_request *req;
> +	struct mxc_scc_ctx *ctx;
> +	struct mxc_scc *scc = priv;
> +	int status;
> +	int ret;
> +
> +	status = readl(scc->base + SCC_SCM_STATUS);
> +
> +	/* clear interrupt control registers */
> +	writel(SCC_SCM_INTR_CTRL_CLR_INTR, scc->base + SCC_SCM_INTR_CTRL);
> +
> +	if (status & SCC_SCM_STATUS_BUSY)
> +		return IRQ_NONE;
> +
> +	spin_lock_bh(&scc->lock);
> +	req = scc->req;
> +	spin_unlock_bh(&scc->lock);
>
What is the purpos of this locking?

> +	if (req) {
> +		ctx = crypto_tfm_ctx(req->tfm);
> +		ret = mxc_scc_get_data(ctx, req);
> +		if (ret != -EINPROGRESS) {
> +			scc->req = NULL;
> +			scc->bytes_remaining = scc->memory_size_bytes;
> +			req->complete(req, ret);
> +			mutex_unlock(&scc->mutex);
> +		} else {
> +			mxc_scc_ablkcipher_next(ctx, req);
> +		}
> +	}
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int mxc_scc_cra_init(struct crypto_tfm *tfm)
> +{
> +	struct mxc_scc_ctx *ctx = crypto_tfm_ctx(tfm);
> +	struct crypto_alg *alg = tfm->__crt_alg;
> +	struct mxc_scc_crypto_tmpl *algt;
> +
> +	algt = container_of(alg, struct mxc_scc_crypto_tmpl, alg);
> +
> +	ctx->scc = algt->scc;
> +	return 0;
> +}
> +
> +static void mxc_scc_dequeue_req_unlocked(struct mxc_scc_ctx *ctx)
> +{
> +	struct crypto_async_request *req, *backlog;
> +
> +	spin_lock_bh(&ctx->scc->lock);
> +	backlog = crypto_get_backlog(&ctx->scc->queue);
> +	req = crypto_dequeue_request(&ctx->scc->queue);
> +	ctx->scc->req = req;
> +	spin_unlock_bh(&ctx->scc->lock);
> +
> +	if (!req)
> +		return;
> +
> +	if (backlog)
> +		backlog->complete(backlog, -EINPROGRESS);
> +
> +	ctx = crypto_tfm_ctx(req->tfm);
> +	mxc_scc_ablkcipher_next(ctx, req);
> +}
> +
> +
One blank line is sufficient.
 
> +static int mxc_scc_queue_req(struct mxc_scc_ctx *ctx,
> +			     struct crypto_async_request *req)
> +{
> +	int ret;
> +
> +	spin_lock_bh(&ctx->scc->lock);
> +	ret = crypto_enqueue_request(&ctx->scc->queue, req);
> +	spin_unlock_bh(&ctx->scc->lock);
> +
> +	if (ret != -EINPROGRESS)
> +		return ret;
> +
> +	mxc_scc_dequeue_req_unlocked(ctx);
> +
> +	return -EINPROGRESS;
> +}
> +
> +
dto.

> +static int mxc_scc_des3_op(struct mxc_scc_ctx *ctx,
> +			   struct ablkcipher_request *req)
> +{
> +	int err;
> +
> +	err = mxc_scc_ablkcipher_req_init(req, ctx);
> +	if (err)
> +		return err;
> +
> +	return mxc_scc_queue_req(ctx, &req->base);
> +}
> +
> +static int mxc_scc_ecb_des_encrypt(struct ablkcipher_request *req)
> +{
> +	struct crypto_ablkcipher *cipher = crypto_ablkcipher_reqtfm(req);
> +	struct mxc_scc_ctx *ctx = crypto_ablkcipher_ctx(cipher);
> +
> +	ctx->ctrl = SCC_SCM_CTRL_START_CIPHER;
> +
> +	return mxc_scc_des3_op(ctx, req);
> +}
> +
> +static int mxc_scc_ecb_des_decrypt(struct ablkcipher_request *req)
> +{
> +	struct crypto_ablkcipher *cipher = crypto_ablkcipher_reqtfm(req);
> +	struct mxc_scc_ctx *ctx = crypto_ablkcipher_ctx(cipher);
> +
> +	ctx->ctrl = SCC_SCM_CTRL_START_CIPHER;
> +	ctx->ctrl |= SCC_SCM_CTRL_DECRYPT_MODE;
> +
> +	return mxc_scc_des3_op(ctx, req);
> +}
> +
> +static int mxc_scc_cbc_des_encrypt(struct ablkcipher_request *req)
> +{
> +	struct crypto_ablkcipher *cipher = crypto_ablkcipher_reqtfm(req);
> +	struct mxc_scc_ctx *ctx = crypto_ablkcipher_ctx(cipher);
> +
> +	ctx->ctrl = SCC_SCM_CTRL_START_CIPHER;
> +	ctx->ctrl |= SCC_SCM_CTRL_CBC_MODE;
> +
> +	return mxc_scc_des3_op(ctx, req);
> +}
> +
> +static int mxc_scc_cbc_des_decrypt(struct ablkcipher_request *req)
> +{
> +	struct crypto_ablkcipher *cipher = crypto_ablkcipher_reqtfm(req);
> +	struct mxc_scc_ctx *ctx = crypto_ablkcipher_ctx(cipher);
> +
> +	ctx->ctrl = SCC_SCM_CTRL_START_CIPHER;
> +	ctx->ctrl |= SCC_SCM_CTRL_CBC_MODE;
> +	ctx->ctrl |= SCC_SCM_CTRL_DECRYPT_MODE;
> +
> +	return mxc_scc_des3_op(ctx, req);
> +}
> +
> +static void mxc_scc_hw_init(struct mxc_scc *scc)
> +{
> +	int offset;
> +
> +	offset = SCC_NON_RESERVED_OFFSET / scc->block_size_bytes;
> +
> +	/* Fill the RED_START register */
> +	writel(offset, scc->base + SCC_SCM_RED_START);
> +
> +	/* Fill the BLACK_START register */
> +	writel(offset, scc->base + SCC_SCM_BLACK_START);
> +
> +	scc->red_memory = scc->base + SCC_SCM_RED_MEMORY +
> +			  SCC_NON_RESERVED_OFFSET;
> +
> +	scc->black_memory = scc->base + SCC_SCM_BLACK_MEMORY +
> +			    SCC_NON_RESERVED_OFFSET;
> +
> +	scc->bytes_remaining = scc->memory_size_bytes;
> +}
> +
> +static int mxc_scc_get_config(struct mxc_scc *scc)
> +{
> +	int config;
> +
> +	config = readl(scc->base + SCC_SCM_CFG);
> +
> +	scc->block_size_bytes = config & SCC_SCM_CFG_BLOCK_SIZE_MASK;
> +
> +	scc->black_ram_size_blocks = (config & SCC_SCM_CFG_BLACK_SIZE_MASK);
>
useless parens.

[...]
> +static int mxc_scc_crypto_register(struct mxc_scc *scc)
> +{
> +	unsigned int i, k;
> +	int err = 0;
> +
> +	for (i = 0; i < ARRAY_SIZE(scc_crypto_algs); i++) {
> +		scc_crypto_algs[i]->scc = scc;
> +		err = crypto_register_alg(&scc_crypto_algs[i]->alg);
> +		if (err)
> +			goto err_out;
> +	}
> +
> +	return 0;
> +err_out:
>
blank line before label?

> +	for (k = 0; k < i; k++)
> +		crypto_unregister_alg(&scc_crypto_algs[k]->alg);
>
You could decrement i back to zero instead of using another loop index.

[...]
> +static int mxc_scc_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct resource *res;
> +	struct mxc_scc *scc;
> +	enum mxc_scc_state state;
> +	int irq;
> +	int ret;
> +
> +	scc = devm_kzalloc(dev, sizeof(*scc), GFP_KERNEL);
> +	if (!scc)
> +		return -ENOMEM;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res)
> +		return -ENOENT;
>
No need for this check, devm_ioremap_resource() will take care of it.

> +	scc->base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(scc->base))
> +		return PTR_ERR(scc->base);
> +
> +	scc->clk = devm_clk_get(&pdev->dev, "ipg");
> +	if (IS_ERR(scc->clk)) {
> +		dev_err(dev, "Could not get ipg clock\n");
> +		return PTR_ERR(scc->clk);
> +	}
> +
> +	clk_prepare_enable(scc->clk);
> +
> +	/* clear error status register */
> +	writel(0x0, scc->base + SCC_SCM_ERROR_STATUS);
> +
> +	/* clear interrupt control registers */
> +	writel(SCC_SCM_INTR_CTRL_CLR_INTR |
> +	       SCC_SCM_INTR_CTRL_MASK_INTR,
> +	       scc->base + SCC_SCM_INTR_CTRL);
> +
> +	writel(SCC_SMN_COMMAND_CLR_INTR |
> +	       SCC_SMN_COMMAND_EN_INTR,
> +	       scc->base + SCC_SMN_COMMAND);
> +
> +	scc->dev = dev;
> +	platform_set_drvdata(pdev, scc);
> +
> +	ret = mxc_scc_get_config(scc);
> +	if (ret)
> +		goto err_out;
> +
> +	state = mxc_scc_get_state(scc);
> +
> +	if (state != SCC_STATE_OK) {
> +		dev_err(dev, "SCC in unusable state %d\n", state);
> +		ret = -EINVAL;
> +		goto err_out;
> +	}
> +
> +	mxc_scc_hw_init(scc);
> +
> +	irq = platform_get_irq(pdev, 0);
> +	if (irq < 0) {
> +		dev_err(dev, "failed to get irq resource\n");
> +		goto err_out;
> +	}
> +
> +	ret = devm_request_threaded_irq(dev, irq, NULL, mxc_scc_int,
> +					IRQF_ONESHOT, dev_name(dev), scc);
> +	if (ret)
> +		goto err_out;
> +
This should be removed, as it is done below again after initializing
all data structures that might be used by the interrupt handler.

> +	irq = platform_get_irq(pdev, 1);
> +	if (irq < 0) {
> +		dev_err(dev, "failed to get irq resource\n");
> +		goto err_out;
> +	}
> +
> +	mutex_init(&scc->mutex);
> +	spin_lock_init(&scc->lock);
> +	/* FIXME: calculate queue from RAM slots */
> +	crypto_init_queue(&scc->queue, 50);
> +
> +	ret = devm_request_threaded_irq(dev, irq, NULL, mxc_scc_int,
> +					IRQF_ONESHOT, dev_name(dev), scc);
> +	if (ret)
> +		goto err_out;
> +
> +	ret = mxc_scc_crypto_register(scc);
> +	if (ret) {
> +		dev_err(dev, "could not register algorithms");
> +		goto err_out;
> +	}
> +
> +	dev_info(dev, "registered successfully.\n");
> +
> +	return 0;
> +
> +err_out:
> +	clk_disable_unprepare(scc->clk);
> +
> +	return ret;
> +}
> +
> +static int mxc_scc_remove(struct platform_device *pdev)
> +{
> +	struct mxc_scc *scc = platform_get_drvdata(pdev);
> +
> +	mxc_scc_crypto_unregister();
> +
> +	clk_disable_unprepare(scc->clk);
> +
> +	return 0;
> +}


Lothar Wa?mann


From julien.grall at arm.com  Thu Feb 11 07:33:23 2016
From: julien.grall at arm.com (Julien Grall)
Date: Thu, 11 Feb 2016 15:33:23 +0000
Subject: [PATCH v2 5/6] irqchip/gic-v3: Parse and export virtual GIC
 information
In-Reply-To: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
References: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
Message-ID: <1455204804-31830-6-git-send-email-julien.grall@arm.com>

Fill up the recently introduced gic_kvm_info with the virtual GIC
information.

Signed-off-by: Julien Grall <julien.grall at arm.com>

---
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Jason Cooper <jason at lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier at arm.com>

    Changes in v2:
        - Use 0 rather than a negative value to know when the maintenance IRQ
        is not present.
        - Use resource for vcpu and vctrl
---
 drivers/irqchip/irq-gic-v3.c           | 36 ++++++++++++++++++++++++++++++++++
 include/linux/irqchip/arm-gic-common.h |  1 +
 2 files changed, 37 insertions(+)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index d7be6dd..9992600 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -26,6 +26,7 @@
 #include <linux/slab.h>
 
 #include <linux/irqchip.h>
+#include <linux/irqchip/arm-gic-common.h>
 #include <linux/irqchip/arm-gic-v3.h>
 
 #include <asm/cputype.h>
@@ -53,6 +54,8 @@ struct gic_chip_data {
 static struct gic_chip_data gic_data __read_mostly;
 static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;
 
+static struct gic_kvm_info gic_v3_kvm_info;
+
 #define gic_data_rdist()		(this_cpu_ptr(gic_data.rdists.rdist))
 #define gic_data_rdist_rd_base()	(gic_data_rdist()->rd_base)
 #define gic_data_rdist_sgi_base()	(gic_data_rdist_rd_base() + SZ_64K)
@@ -811,6 +814,37 @@ static void gicv3_enable_quirks(void)
 #endif
 }
 
+static void __init gic_of_setup_kvm_info(struct device_node *node)
+{
+	int ret;
+	struct resource r;
+	u32 gicv_idx;
+
+	gic_v3_kvm_info.type = GIC_V3;
+
+	gic_v3_kvm_info.maint_irq = irq_of_parse_and_map(node, 0);
+
+	if (of_property_read_u32(node, "#redistributor-regions",
+				 &gicv_idx))
+		gicv_idx = 1;
+
+	gicv_idx += 3;	/* Also skip GICD, GICC, GICH */
+	ret = of_address_to_resource(node, gicv_idx, &r);
+	if (!ret) {
+		if (!PAGE_ALIGNED(r.start))
+			pr_warn("GICV physical address 0x%llx not page aligned\n",
+				(unsigned long long)r.start);
+		else if (!PAGE_ALIGNED(resource_size(&r)))
+			pr_warn("GICV size 0x%llx not a multiple of page size 0x%lx\n",
+				(unsigned long long)resource_size(&r),
+				PAGE_SIZE);
+		else
+			gic_v3_kvm_info.vcpu = r;
+	}
+
+	gic_set_kvm_info(&gic_v3_kvm_info);
+}
+
 static int __init gic_of_init(struct device_node *node, struct device_node *parent)
 {
 	void __iomem *dist_base;
@@ -908,6 +942,8 @@ static int __init gic_of_init(struct device_node *node, struct device_node *pare
 	gic_cpu_init();
 	gic_cpu_pm_init();
 
+	gic_of_setup_kvm_info(node);
+
 	return 0;
 
 out_free:
diff --git a/include/linux/irqchip/arm-gic-common.h b/include/linux/irqchip/arm-gic-common.h
index f7723b9..15d68c6 100644
--- a/include/linux/irqchip/arm-gic-common.h
+++ b/include/linux/irqchip/arm-gic-common.h
@@ -15,6 +15,7 @@
 
 enum gic_type {
 	GIC_V2,
+	GIC_V3,
 };
 
 struct gic_kvm_info {
-- 
1.9.1



From broonie at kernel.org  Thu Feb 11 07:52:55 2016
From: broonie at kernel.org (Mark Brown)
Date: Thu, 11 Feb 2016 15:52:55 +0000
Subject: [PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred
 probe for pm_runtime_reinit
In-Reply-To: <20160211150806.GS19432@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-4-git-send-email-tony@atomide.com>
 <20160211115128.GF13270@sirena.org.uk>
 <20160211150806.GS19432@atomide.com>
Message-ID: <20160211155255.GA1953@sirena.org.uk>

On Thu, Feb 11, 2016 at 07:08:06AM -0800, Tony Lindgren wrote:
> * Mark Brown <broonie at kernel.org> [160211 03:52]:

> > Why, I'm not seeing any dependencies here?  I'd also expect to be seeing
> > an awful lot more changes like this, this shouldn't be an OMAP thing -
> > do we need to fix the core API and then roll out the transition in a
> > different way?

> Please feel free to pick up this one if you have other fixes
> lined up, nothing stopping that.

I'll take it myself unless there is a strong reason to merge it as part
of another series.

> There will be likely more fixes like this to make drivers follow
> the PM runtime API documentation. These were just the initial
> ones that were obvious.

This does sound like there's been a change in the interface compared to
what users are actually doing - is this an actual problem or is it just
a divergence from docs?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/290ead7c/attachment-0001.sig>

From lee.jones at linaro.org  Thu Feb 11 07:56:33 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Thu, 11 Feb 2016 15:56:33 +0000
Subject: [GIT PULL] Immutable branch between MFD, Input and IIO
In-Reply-To: <1450101234-2191-1-git-send-email-mpa@pengutronix.de>
References: <1450101234-2191-1-git-send-email-mpa@pengutronix.de>
Message-ID: <20160211155633.GB20693@x1>

Enjoy!

The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3:

  Linux 4.5-rc2 (2016-01-31 18:12:16 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/ib-mfd-input-iio-v4.6

for you to fetch changes up to 4f7ed234f2a5dcc26fc56a6e8324d34bbc9afe23:

  Input: touchscreen: Add imx25 TCQ driver (2016-02-11 15:40:42 +0000)

----------------------------------------------------------------
Immutable branch between MFD, Input and IIO due for v4.6

----------------------------------------------------------------
Markus Pargmann (6):
      mfd: Add DT binding documentation for imx25 ADC/TSC
      iio: Add binding documentation for imx25 GCQ
      Input: add binding documentation for imx25 touchscreen controller
      mfd: fsl-imx25-tsadc: Register touchscreen ADC driver
      iio: adc: Add imx25-gcq ADC driver
      Input: touchscreen: Add imx25 TCQ driver

 .../devicetree/bindings/iio/adc/fsl,imx25-gcq.txt  |  58 ++
 .../bindings/input/touchscreen/fsl-mx25-tcq.txt    |  35 ++
 .../devicetree/bindings/mfd/fsl-imx25-tsadc.txt    |  47 ++
 drivers/iio/adc/Kconfig                            |   7 +
 drivers/iio/adc/Makefile                           |   1 +
 drivers/iio/adc/fsl-imx25-gcq.c                    | 417 ++++++++++++++
 drivers/input/touchscreen/Kconfig                  |   9 +
 drivers/input/touchscreen/Makefile                 |   1 +
 drivers/input/touchscreen/fsl-imx25-tcq.c          | 596 +++++++++++++++++++++
 drivers/mfd/Kconfig                                |   9 +
 drivers/mfd/Makefile                               |   2 +
 drivers/mfd/fsl-imx25-tsadc.c                      | 203 +++++++
 include/dt-bindings/iio/adc/fsl-imx25-gcq.h        |  18 +
 include/linux/mfd/imx25-tsadc.h                    | 140 +++++
 14 files changed, 1543 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
 create mode 100644 Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
 create mode 100644 drivers/iio/adc/fsl-imx25-gcq.c
 create mode 100644 drivers/input/touchscreen/fsl-imx25-tcq.c
 create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
 create mode 100644 include/dt-bindings/iio/adc/fsl-imx25-gcq.h
 create mode 100644 include/linux/mfd/imx25-tsadc.h

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From robin.murphy at arm.com  Thu Feb 11 07:57:26 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 11 Feb 2016 15:57:26 +0000
Subject: [PATCH v3 1/8] iommu: Add MMIO mapping type
In-Reply-To: <13740597.5lZXKsEG19@avalon>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <1455065878-11906-2-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <13740597.5lZXKsEG19@avalon>
Message-ID: <56BCAF66.8010206@arm.com>

On 11/02/16 00:02, Laurent Pinchart wrote:
> Hi Niklas,
>
> Thank you for the patch.
>
> On Wednesday 10 February 2016 01:57:51 Niklas S?derlund wrote:
>> From: Robin Murphy <robin.murphy at arm.com>
>>
>> On some platforms, MMIO regions might need slightly different treatment
>> compared to mapping regular memory; add the notion of MMIO mappings to
>> the IOMMU API's memory type flags, so that callers can let the IOMMU
>> drivers know to do the right thing.
>>
>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>> Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
>
> Answering the question from the cover letter, yes, it's totally fine to pick
> the ack, that's actually expected.
>
>> ---
>>   drivers/iommu/io-pgtable-arm.c | 4 +++-
>>   include/linux/iommu.h          | 1 +
>
> You might be asked to split this patch in two.

Worse than that, you might also be asked to fix it up when the silly 
author remembers that he did this on a stage-2-only ARM SMMU, and the 
attributes for the stage 1 tables that the IPMMU uses are in a different 
code path:

--->8---
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 5b5c299..7622c6e 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -354,7 +354,10 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct 
arm_lpae_io_pgtable *data,
                 if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
                         pte |= ARM_LPAE_PTE_AP_RDONLY;

-               if (prot & IOMMU_CACHE)
+               if (prot & IOMMU_MMIO)
+                       pte |= (ARM_LPAE_MAIR_ATTR_IDX_DEV
+                               << ARM_LPAE_PTE_ATTRINDX_SHIFT);
+               else if (prot & IOMMU_CACHE)
                         pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE
                                 << ARM_LPAE_PTE_ATTRINDX_SHIFT);
         } else {
--->8---

Sorry for the bother,
Robin.

>>   2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
>> index 381ca5a..3ff4f87 100644
>> --- a/drivers/iommu/io-pgtable-arm.c
>> +++ b/drivers/iommu/io-pgtable-arm.c
>> @@ -364,7 +364,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
>> arm_lpae_io_pgtable *data, pte |= ARM_LPAE_PTE_HAP_READ;
>>   		if (prot & IOMMU_WRITE)
>>   			pte |= ARM_LPAE_PTE_HAP_WRITE;
>> -		if (prot & IOMMU_CACHE)
>> +		if (prot & IOMMU_MMIO)
>> +			pte |= ARM_LPAE_PTE_MEMATTR_DEV;
>> +		else if (prot & IOMMU_CACHE)
>>   			pte |= ARM_LPAE_PTE_MEMATTR_OIWB;
>>   		else
>>   			pte |= ARM_LPAE_PTE_MEMATTR_NC;
>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>> index a5c539f..34b6432 100644
>> --- a/include/linux/iommu.h
>> +++ b/include/linux/iommu.h
>> @@ -30,6 +30,7 @@
>>   #define IOMMU_WRITE	(1 << 1)
>>   #define IOMMU_CACHE	(1 << 2) /* DMA cache coherency */
>>   #define IOMMU_NOEXEC	(1 << 3)
>> +#define IOMMU_MMIO	(1 << 4) /* e.g. things like MSI doorbells */
>>
>>   struct iommu_ops;
>>   struct iommu_group;
>



From gpkulkarni at gmail.com  Thu Feb 11 07:58:01 2016
From: gpkulkarni at gmail.com (Ganapatrao Kulkarni)
Date: Thu, 11 Feb 2016 21:28:01 +0530
Subject: [PATCH v10 3/8] dt, numa: adding numa dt binding implementation.
In-Reply-To: <20160211153255.GR24726@rric.localdomain>
References: <1454407763-1017-1-git-send-email-gkulkarni@caviumnetworks.com>
 <1454407763-1017-4-git-send-email-gkulkarni@caviumnetworks.com>
 <CAL_JsqK5HV9yzBE+ANnTw26eVR7Dy+B8OkwQ-7WF8KDa86Fd9g@mail.gmail.com>
 <20160211153255.GR24726@rric.localdomain>
Message-ID: <CAFpQJXU+fon8DY--qhyZV=JDv9omqs=c9eSX34g1J2w2uudNKA@mail.gmail.com>

Hi Rob,

On Thu, Feb 11, 2016 at 9:02 PM, Robert Richter
<robert.richter at caviumnetworks.com> wrote:
> On 11.02.16 08:50:41, Rob Herring wrote:
>> On Tue, Feb 2, 2016 at 4:09 AM, Ganapatrao Kulkarni
>> <gkulkarni at caviumnetworks.com> wrote:
>> > dt node parsing for numa topology is done using device property
>> > numa-node-id and device node distance-map.
>>
>> How is it that powerpc doesn't need flat DT parsing for NUMA? Both
>> arches are memblock based and the binding is similar IIRC, so you
>> should be able to find a way to do this with the unflattened tree.
>> Ideally, there should be some common code shared as well.

powerpc has implemented numa binding using property named
"ibm,associativity", we too started adding using the same binding[
refer version V6]
however had discussion/review with Mark R about mapping and we could not map to
some of the topology like mesh and ring topology.

So we have defined and implemented this new binding which is simple
and scalable.
This binding is very much aligned to ACPI NUMA specification.

>>
>> Do you have a git tree with this series?
>
> I have pushed it here for you:
>
>  https://git.kernel.org/cgit/linux/kernel/git/rric/linux.git/log/?h=thunder/numa-v10

thanks Robert.
>
> -Robert

thanks
Ganapat


From marc.zyngier at arm.com  Thu Feb 11 07:59:44 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 15:59:44 +0000
Subject: [PULL] KVM/ARM fixes for 4.5-rc4
Message-ID: <1455206386-24997-1-git-send-email-marc.zyngier@arm.com>

Hi Paolo,

Please find below the KVM/ARM updates for 4.5-rc4. One fix for the
timer, and another for the HYP MMU setup.

Please pull!

Thanks,

	M.

The following changes since commit 6327f35a2010c06a3bc2bfb14202a38764fb9920:

  arm64: KVM: Fix guest dead loop when register accessor returns false (2016-01-24 21:56:01 +0000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvm-arm-for-4.5-rc4

for you to fetch changes up to 3c5b1d92b3b02be07873d611a27950addff544d3:

  arm64: KVM: Configure TCR_EL2.PS at runtime (2016-02-11 13:16:47 +0000)

----------------------------------------------------------------
KVM/ARM fixes for 4.5-rc4

- Fix for an unpleasant crash when the VM is created without a timer
- Allow HYP mode to access the full PA space, and not only 40bit

----------------------------------------------------------------
Andre Przywara (1):
      KVM: arm/arm64: Fix reference to uninitialised VGIC

Tirumalesh Chalamarla (1):
      arm64: KVM: Configure TCR_EL2.PS at runtime

 arch/arm64/include/asm/kvm_arm.h |  2 --
 arch/arm64/kvm/hyp-init.S        | 12 +++++++-----
 virt/kvm/arm/arch_timer.c        |  9 ++++++---
 3 files changed, 13 insertions(+), 10 deletions(-)


From marc.zyngier at arm.com  Thu Feb 11 07:59:45 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 15:59:45 +0000
Subject: [PATCH 1/2] KVM: arm/arm64: Fix reference to uninitialised VGIC
In-Reply-To: <1455206386-24997-1-git-send-email-marc.zyngier@arm.com>
References: <1455206386-24997-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455206386-24997-2-git-send-email-marc.zyngier@arm.com>

From: Andre Przywara <andre.przywara at arm.com>

Commit 4b4b4512da2a ("arm/arm64: KVM: Rework the arch timer to use
level-triggered semantics") brought the virtual architected timer
closer to the VGIC. There is one occasion were we don't properly
check for the VGIC actually having been initialized before, but
instead go on to check the active state of some IRQ number.
If userland hasn't instantiated a virtual GIC, we end up with a
kernel NULL pointer dereference:
=========
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = ffffffc9745c5000
[00000000] *pgd=00000009f631e003, *pud=00000009f631e003, *pmd=0000000000000000
Internal error: Oops: 96000006 [#2] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 2144 Comm: kvm_simplest-ar Tainted: G      D 4.5.0-rc2+ #1300
Hardware name: ARM Juno development board (r1) (DT)
task: ffffffc976da8000 ti: ffffffc976e28000 task.ti: ffffffc976e28000
PC is at vgic_bitmap_get_irq_val+0x78/0x90
LR is at kvm_vgic_map_is_active+0xac/0xc8
pc : [<ffffffc0000b7e28>] lr : [<ffffffc0000b972c>] pstate: 20000145
....
=========

Fix this by bailing out early of kvm_timer_flush_hwstate() if we don't
have a VGIC at all.

Reported-by: Cosmin Gorgovan <cosmin at linux-geek.org>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Andre Przywara <andre.przywara at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
Cc: <stable at vger.kernel.org> # 4.4.x
---
 virt/kvm/arm/arch_timer.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 69bca18..ea60646 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -143,7 +143,7 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level)
  * Check if there was a change in the timer state (should we raise or lower
  * the line level to the GIC).
  */
-static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
+static int kvm_timer_update_state(struct kvm_vcpu *vcpu)
 {
 	struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
 
@@ -154,10 +154,12 @@ static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
 	 * until we call this function from kvm_timer_flush_hwstate.
 	 */
 	if (!vgic_initialized(vcpu->kvm))
-	    return;
+		return -ENODEV;
 
 	if (kvm_timer_should_fire(vcpu) != timer->irq.level)
 		kvm_timer_update_irq(vcpu, !timer->irq.level);
+
+	return 0;
 }
 
 /*
@@ -218,7 +220,8 @@ void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu)
 	bool phys_active;
 	int ret;
 
-	kvm_timer_update_state(vcpu);
+	if (kvm_timer_update_state(vcpu))
+		return;
 
 	/*
 	* If we enter the guest with the virtual input level to the VGIC
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 07:59:46 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 15:59:46 +0000
Subject: [PATCH 2/2] arm64: KVM: Configure TCR_EL2.PS at runtime
In-Reply-To: <1455206386-24997-1-git-send-email-marc.zyngier@arm.com>
References: <1455206386-24997-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455206386-24997-3-git-send-email-marc.zyngier@arm.com>

From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>

Setting TCR_EL2.PS to 40 bits is wrong on systems with less that
less than 40 bits of physical addresses. and breaks KVM on systems
where the RAM is above 40 bits.

This patch uses ID_AA64MMFR0_EL1.PARange to set TCR_EL2.PS dynamically,
just like we already do for VTCR_EL2.PS.

[Marc: rewrote commit message, patch tidy up]

Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_arm.h |  2 --
 arch/arm64/kvm/hyp-init.S        | 12 +++++++-----
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index bef6e92..d201d4b 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -107,8 +107,6 @@
 #define TCR_EL2_MASK	(TCR_EL2_TG0 | TCR_EL2_SH0 | \
 			 TCR_EL2_ORGN0 | TCR_EL2_IRGN0 | TCR_EL2_T0SZ)
 
-#define TCR_EL2_FLAGS	(TCR_EL2_RES1 | TCR_EL2_PS_40B)
-
 /* VTCR_EL2 Registers bits */
 #define VTCR_EL2_RES1		(1 << 31)
 #define VTCR_EL2_PS_MASK	(7 << 16)
diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
index 3e568dc..d073b5a 100644
--- a/arch/arm64/kvm/hyp-init.S
+++ b/arch/arm64/kvm/hyp-init.S
@@ -64,7 +64,7 @@ __do_hyp_init:
 	mrs	x4, tcr_el1
 	ldr	x5, =TCR_EL2_MASK
 	and	x4, x4, x5
-	ldr	x5, =TCR_EL2_FLAGS
+	mov	x5, #TCR_EL2_RES1
 	orr	x4, x4, x5
 
 #ifndef CONFIG_ARM64_VA_BITS_48
@@ -85,15 +85,17 @@ __do_hyp_init:
 	ldr_l	x5, idmap_t0sz
 	bfi	x4, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH
 #endif
-	msr	tcr_el2, x4
-
-	ldr	x4, =VTCR_EL2_FLAGS
 	/*
 	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
-	 * VTCR_EL2.
+	 * TCR_EL2 and VTCR_EL2.
 	 */
 	mrs	x5, ID_AA64MMFR0_EL1
 	bfi	x4, x5, #16, #3
+
+	msr	tcr_el2, x4
+
+	ldr	x4, =VTCR_EL2_FLAGS
+	bfi	x4, x5, #16, #3
 	/*
 	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS bit in
 	 * VTCR_EL2.
-- 
2.1.4



From paul.gortmaker at windriver.com  Thu Feb 11 08:00:22 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Thu, 11 Feb 2016 11:00:22 -0500
Subject: [PATCH v2 1/6] Revert "drivers/tty/serial: make 8250/8250_mtk.c
 explicitly non-modular"
In-Reply-To: <1455205297-1021302-2-git-send-email-arnd@arndb.de>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
 <1455205297-1021302-2-git-send-email-arnd@arndb.de>
Message-ID: <20160211160021.GF28452@windriver.com>

[[PATCH v2 1/6] Revert "drivers/tty/serial: make 8250/8250_mtk.c explicitly non-modular"] On 11/02/2016 (Thu 16:41) Arnd Bergmann wrote:

> This reverts commit d72d391c126e, which tried to remove dead code but
> left the driver in a useless state when the main 8250 driver is a

Am I misunderstanding something?  The commit didn't cause the driver to
be in a useless state for 8250=m.  But rather isn't that it was a
pre-existing condition, independent of the change to 8250_mtk.c to
remove the dead code in d72d391c126e?

Since the commit did not touch Kconfig or Makefile, I can't see how it
could cause some new useless state that did not already exist, and hence
the "Fixes:" tag is invalid as well.

Paul.
--

> loadable module. This would normally result in a link error, but
> as the entire drivers/tty/serial/8250/ directory is only entered
> when CONFIG_SERIAL_8250 is set, we never notice that the driver does
> not get built in this configuration.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: d72d391c126e ("drivers/tty/serial: make 8250/8250_mtk.c explicitly non-modular")
> ---
>  drivers/tty/serial/8250/8250_mtk.c | 35 ++++++++++++++++++++++++++++-------
>  1 file changed, 28 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
> index 0e590b233f03..78883ca64ddd 100644
> --- a/drivers/tty/serial/8250/8250_mtk.c
> +++ b/drivers/tty/serial/8250/8250_mtk.c
> @@ -16,7 +16,7 @@
>   */
>  #include <linux/clk.h>
>  #include <linux/io.h>
> -#include <linux/init.h>
> +#include <linux/module.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_platform.h>
>  #include <linux/platform_device.h>
> @@ -245,6 +245,23 @@ static int mtk8250_probe(struct platform_device *pdev)
>  	return 0;
>  }
>  
> +static int mtk8250_remove(struct platform_device *pdev)
> +{
> +	struct mtk8250_data *data = platform_get_drvdata(pdev);
> +
> +	pm_runtime_get_sync(&pdev->dev);
> +
> +	serial8250_unregister_port(data->line);
> +
> +	pm_runtime_disable(&pdev->dev);
> +	pm_runtime_put_noidle(&pdev->dev);
> +
> +	if (!pm_runtime_status_suspended(&pdev->dev))
> +		mtk8250_runtime_suspend(&pdev->dev);
> +
> +	return 0;
> +}
> +
>  #ifdef CONFIG_PM_SLEEP
>  static int mtk8250_suspend(struct device *dev)
>  {
> @@ -275,18 +292,18 @@ static const struct of_device_id mtk8250_of_match[] = {
>  	{ .compatible = "mediatek,mt6577-uart" },
>  	{ /* Sentinel */ }
>  };
> +MODULE_DEVICE_TABLE(of, mtk8250_of_match);
>  
>  static struct platform_driver mtk8250_platform_driver = {
>  	.driver = {
> -		.name			= "mt6577-uart",
> -		.pm			= &mtk8250_pm_ops,
> -		.of_match_table		= mtk8250_of_match,
> -		.suppress_bind_attrs	= true,
> -
> +		.name		= "mt6577-uart",
> +		.pm		= &mtk8250_pm_ops,
> +		.of_match_table	= mtk8250_of_match,
>  	},
>  	.probe			= mtk8250_probe,
> +	.remove			= mtk8250_remove,
>  };
> -builtin_platform_driver(mtk8250_platform_driver);
> +module_platform_driver(mtk8250_platform_driver);
>  
>  #ifdef CONFIG_SERIAL_8250_CONSOLE
>  static int __init early_mtk8250_setup(struct earlycon_device *device,
> @@ -302,3 +319,7 @@ static int __init early_mtk8250_setup(struct earlycon_device *device,
>  
>  OF_EARLYCON_DECLARE(mtk8250, "mediatek,mt6577-uart", early_mtk8250_setup);
>  #endif
> +
> +MODULE_AUTHOR("Matthias Brugger");
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Mediatek 8250 serial port driver");
> -- 
> 2.7.0
> 


From paul.gortmaker at windriver.com  Thu Feb 11 08:02:39 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Thu, 11 Feb 2016 11:02:39 -0500
Subject: [PATCH v2 2/6] Revert "drivers/tty/serial: make
 8250/8250_ingenic.c explicitly non-modular"
In-Reply-To: <1455205297-1021302-3-git-send-email-arnd@arndb.de>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
 <1455205297-1021302-3-git-send-email-arnd@arndb.de>
Message-ID: <20160211160239.GG28452@windriver.com>

[[PATCH v2 2/6] Revert "drivers/tty/serial: make 8250/8250_ingenic.c explicitly non-modular"] On 11/02/2016 (Thu 16:41) Arnd Bergmann wrote:

> This reverts commit cafe1ac64023, which tried to remove dead code but
> left the driver in a useless state when the main 8250 driver is a
> loadable module. This would normally result in a link error, but
> as the entire drivers/tty/serial/8250/ directory is only entered
> when CONFIG_SERIAL_8250 is set, we never notice that the driver does
> not get built in this configuration.

Same comments apply here as per 1/6.

OTOH, if you were to say that 8250=m and this driver =y is a useless
configuration, and the easiest way to rectify that was to convert it
to tristate, and hence we revert cafe1ac64023 to regain some modular
code -- that would make more sense to me.

P.
--

> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: cafe1ac64023 ("drivers/tty: make serial 8250_ingenic.c explicitly non-modular")
> ---
>  drivers/tty/serial/8250/8250_ingenic.c | 28 +++++++++++++++++++++-------
>  1 file changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_ingenic.c b/drivers/tty/serial/8250/8250_ingenic.c
> index b4e1d39805b2..97b78558caed 100644
> --- a/drivers/tty/serial/8250/8250_ingenic.c
> +++ b/drivers/tty/serial/8250/8250_ingenic.c
> @@ -4,8 +4,6 @@
>   *
>   * Ingenic SoC UART support
>   *
> - * Author: Paul Burton <paul.burton at imgtec.com>
> - *
>   * This program is free software; you can redistribute	 it and/or modify it
>   * under  the terms of	 the GNU General  Public License as published by the
>   * Free Software Foundation;  either version 2 of the	License, or (at your
> @@ -20,7 +18,7 @@
>  #include <linux/console.h>
>  #include <linux/io.h>
>  #include <linux/libfdt.h>
> -#include <linux/init.h>
> +#include <linux/module.h>
>  #include <linux/of.h>
>  #include <linux/of_fdt.h>
>  #include <linux/of_device.h>
> @@ -303,6 +301,16 @@ out:
>  	return err;
>  }
>  
> +static int ingenic_uart_remove(struct platform_device *pdev)
> +{
> +	struct ingenic_uart_data *data = platform_get_drvdata(pdev);
> +
> +	serial8250_unregister_port(data->line);
> +	clk_disable_unprepare(data->clk_module);
> +	clk_disable_unprepare(data->clk_baud);
> +	return 0;
> +}
> +
>  static const struct ingenic_uart_config jz4740_uart_config = {
>  	.tx_loadsz = 8,
>  	.fifosize = 16,
> @@ -325,13 +333,19 @@ static const struct of_device_id of_match[] = {
>  	{ .compatible = "ingenic,jz4780-uart", .data = &jz4780_uart_config },
>  	{ /* sentinel */ }
>  };
> +MODULE_DEVICE_TABLE(of, of_match);
>  
>  static struct platform_driver ingenic_uart_platform_driver = {
>  	.driver = {
> -		.name			= "ingenic-uart",
> -		.of_match_table		= of_match,
> -		.suppress_bind_attrs	= true,
> +		.name		= "ingenic-uart",
> +		.of_match_table	= of_match,
>  	},
>  	.probe			= ingenic_uart_probe,
> +	.remove			= ingenic_uart_remove,
>  };
> -builtin_platform_driver(ingenic_uart_platform_driver);
> +
> +module_platform_driver(ingenic_uart_platform_driver);
> +
> +MODULE_AUTHOR("Paul Burton");
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Ingenic SoC UART driver");
> -- 
> 2.7.0
> 


From stefano.stabellini at eu.citrix.com  Thu Feb 11 08:04:14 2016
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Thu, 11 Feb 2016 16:04:14 +0000
Subject: [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen
In-Reply-To: <44113385.2QnPtvxQx0@vostro.rjw.lan>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
 <2213954.ztOe55fprN@vostro.rjw.lan>
 <alpine.DEB.2.02.1602091116240.27008@kaball.uk.xensource.com>
 <44113385.2QnPtvxQx0@vostro.rjw.lan>
Message-ID: <alpine.DEB.2.02.1602111557430.27008@kaball.uk.xensource.com>

On Wed, 10 Feb 2016, Rafael J. Wysocki wrote:
> On Tuesday, February 09, 2016 11:19:02 AM Stefano Stabellini wrote:
> > On Mon, 8 Feb 2016, Rafael J. Wysocki wrote:
> > > On Monday, February 08, 2016 10:57:01 AM Stefano Stabellini wrote:
> > > > On Sat, 6 Feb 2016, Rafael J. Wysocki wrote:
> > > > > On Fri, Feb 5, 2016 at 4:05 AM, Shannon Zhao <zhaoshenglong at huawei.com> wrote:
> > > > > > From: Shannon Zhao <shannon.zhao at linaro.org>
> > > > > >
> > > > > > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > > > > > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > > > > > UART is used by Xen. So here it hides UART from Dom0.
> > > > > >
> > > > > > Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> > > > > > Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> > > > > 
> > > > > Well, this doesn't look right to me.
> > > > > 
> > > > > We need to find a nicer way to achieve what you want.
> > > > 
> > > > I take that you are talking about how to honor the STAO table in Linux.
> > > > Do you have any concrete suggestions?
> > > 
> > > I do.
> > > 
> > > The last hunk of the patch is likely what it needs to be, although I'm
> > > not sure if the place it is added to is the right one.  That's a minor thing,
> > > though.
> > > 
> > > The other part is problematic.  Not that as it doesn't work, but because of
> > > how it works.  With these changes the device will be visible to the OS (in
> > > fact to user space even), but will never be "present".  I'm not sure if
> > > that's what you want?
> > > 
> > > It might be better to add a check to acpi_bus_type_and_status() that will
> > > evaluate the "should ignore?" thing and return -ENODEV if this is true.  This
> > > way the device won't be visible at all.
> > 
> > Something like below?  Actually your suggestion is better, thank you!
> > 
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 78d5f02..4778c51 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -1455,6 +1455,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> >  	if (ACPI_FAILURE(status))
> >  		return -ENODEV;
> >  
> > +	if (acpi_check_device_is_ignored(handle))
> > +		return -ENODEV;
> > +
> >  	switch (acpi_type) {
> >  	case ACPI_TYPE_ANY:		/* for ACPI_ROOT_OBJECT */
> >  	case ACPI_TYPE_DEVICE:
> > 
> 
> I thought about doing that under ACPI_TYPE_DEVICE, because it shouldn't be
> applicable to the other types.  But generally, yes.

I was pondering about it myself. Maybe an ACPI_TYPE_PROCESSOR object
could theoretically be hidden with the STAO? I added the check before
the switch because I thought that there would be no harm in being
caution about it.


> Plus I'd move the table checks to acpi_scan_init(), so the UART address can
> be a static variable in scan.c.
>
> Also maybe rename acpi_check_device_is_ignored() to something like
> acpi_device_should_be_hidden().

Both make sense. Shannon, are you happy to make these changes?


From paul.gortmaker at windriver.com  Thu Feb 11 08:04:38 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Thu, 11 Feb 2016 11:04:38 -0500
Subject: [PATCH v2 5/6] serial: 8250/mediatek: fix building with
 SERIAL_8250=m
In-Reply-To: <1455205297-1021302-6-git-send-email-arnd@arndb.de>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
 <1455205297-1021302-6-git-send-email-arnd@arndb.de>
Message-ID: <20160211160438.GH28452@windriver.com>

[[PATCH v2 5/6] serial: 8250/mediatek: fix building with SERIAL_8250=m] On 11/02/2016 (Thu 16:41) Arnd Bergmann wrote:

> The Mediatek 8250 driver has a 'bool' Kconfig symbol, but that
> breaks when SERIAL_8250 is a loadable module:
> 
> drivers/tty/built-in.o: In function `mtk8250_set_termios':
> :(.text+0x1bee8): undefined reference to `serial8250_do_set_termios'
> :(.text+0x1bf10): undefined reference to `uart_get_baud_rate'
> :(.text+0x1c09c): undefined reference to `uart_get_divisor'
> drivers/tty/built-in.o: In function `mtk8250_do_pm':
> :(.text+0x1c0d0): undefined reference to `serial8250_do_pm'
> drivers/tty/built-in.o: In function `mtk8250_probe':
> :(.text+0x1c2e4): undefined reference to `serial8250_register_8250_port'
> serial/8250/8250_mtk.c:287:242: error: data definition has no type or storage class [-Werror]
> serial/8250/8250_mtk.c:287:122: error: 'mtk8250_platform_driver_init' defined but not used [-Werror=unused-function]
> 
> This changes the symbol to a 'tristate', so the dependency on
> SERIAL_8250 also works when that is set to 'm'.
> To actually build the driver, we also need to include <linux/module.h>.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/tty/serial/8250/8250_mtk.c | 3 ++-
>  drivers/tty/serial/8250/Kconfig    | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
> index 6ecc6e3e82dc..55be90c1d85e 100644
> --- a/drivers/tty/serial/8250/8250_mtk.c
> +++ b/drivers/tty/serial/8250/8250_mtk.c
> @@ -19,6 +19,7 @@
>  #include <linux/module.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_platform.h>
> +#include <linux/module.h>

Something isn't right here ; I can see module.h three lines up in the
context.  Guessing your addition of the revert makes this addition no
longer required...

P.
--

>  #include <linux/platform_device.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/serial_8250.h>
> @@ -303,7 +304,7 @@ static struct platform_driver mtk8250_platform_driver = {
>  };
>  module_platform_driver(mtk8250_platform_driver);
>  
> -#ifdef CONFIG_SERIAL_8250_CONSOLE
> +#if defined(CONFIG_SERIAL_8250_CONSOLE) && !defined(MODULE)
>  static int __init early_mtk8250_setup(struct earlycon_device *device,
>  					const char *options)
>  {
> diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
> index 67ad6b0d595b..6ae0fae4f796 100644
> --- a/drivers/tty/serial/8250/Kconfig
> +++ b/drivers/tty/serial/8250/Kconfig
> @@ -370,7 +370,7 @@ config SERIAL_8250_LPC18XX
>  	  serial port, say Y to this option. If unsure, say Y.
>  
>  config SERIAL_8250_MT6577
> -	bool "Mediatek serial port support"
> +	tristate "Mediatek serial port support"
>  	depends on SERIAL_8250 && ARCH_MEDIATEK
>  	help
>  	  If you have a Mediatek based board and want to use the
> -- 
> 2.7.0
> 


From stephanolbrich at gmx.de  Thu Feb 11 08:05:56 2016
From: stephanolbrich at gmx.de (Stephan Olbrich)
Date: Thu, 11 Feb 2016 17:05:56 +0100
Subject: [PATCH 4/4] spi: bcm2835aux: fix CPOL/CPHA setting
In-Reply-To: <16A848EA-6E08-48C4-B3DD-DF27333B7458@sperl.org>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <87a8n94e3x.fsf@eliezer.anholt.net>
 <16A848EA-6E08-48C4-B3DD-DF27333B7458@sperl.org>
Message-ID: <10547867.CcbLVQlgyH@chaos-desktop>

Martin,

Am Thursday 11 February 2016, 16:25:43 schrieb Martin Sperl:
> > On 10.02.2016, at 01:13, Eric Anholt <eric at anholt.net> wrote:
> > 
> > stephanolbrich at gmx.de writes:
> >> From: Stephan Olbrich <stephanolbrich at gmx.de>
> >> 
> >> The auxiliary spi supports only CPHA=0 modes as the first bit is
> >> always output to the pin before the first clock cycle. In CPHA=1
> >> modes the first clock edge outputs the second bit hence the slave
> >> can never read the first bit.
> >> 
> >> Also the CPHA registers switch between clocking data in/out on
> >> rising/falling edge hence depend on the CPOL setting.
> >> 
> >> Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
> >> ---
> >> drivers/spi/spi-bcm2835aux.c | 10 +++++-----
> >> 1 file changed, 5 insertions(+), 5 deletions(-)
> >> 
> >> diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
> >> index b90aa34..169f521 100644
> >> --- a/drivers/spi/spi-bcm2835aux.c
> >> +++ b/drivers/spi/spi-bcm2835aux.c
> >> @@ -386,12 +386,12 @@ static int bcm2835aux_spi_prepare_message(struct
> >> spi_master *master,>> 
> >> 	bs->cntl[1] = BCM2835_AUX_SPI_CNTL1_MSBF_IN;
> >> 	
> >> 	/* handle all the modes */
> >> 
> >> -	if (spi->mode & SPI_CPOL)
> >> +	if (spi->mode & SPI_CPOL) {
> >> 
> >> 		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPOL;
> >> 
> >> -	if (spi->mode & SPI_CPHA)
> >> -		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT |
> >> -			       BCM2835_AUX_SPI_CNTL0_CPHA_IN;
> >> -
> >> +		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT;
> >> +	} else {
> >> +		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_IN;
> >> +	}
> >> 
> >> 	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1]);
> >> 	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL0, bs->cntl[0]);
> > 
> > (Note for other readers: A better name for CNTL0_CPHA_* would be
> > CNTL0_*_RISING).
> > 
> > I think you're right about not actually supporting CPHA.  I don't see
> > wany way to keep bit 1 out lasting through the first full clock cycle.
> > I think Stefan's right that we should drop CPHA from MODE_BITS
> > (actually, MODE_BITS would be nicer if we just merged it into its one
> > user, I think).
> > 
> > However, this hunk appears to be correct and would fix the timing of our
> > data going out in the CPOL=0 case and of sampling IN data for CPOL=1.
> 
> Are you sure that CPHA is not working?
> 
> I have used the following to test all combinations:
>  for C in "" "-C"; do
>   for O in "" "-O"; do
>    for H in "" "-H"; do
>     spidev_test -vD /dev/*.1 $H $O -p "\x00\x82\x00" -s 1000000;
>    done
>   done
>  done
> 
> I have tested with the 4.5-rc3 kernel without any of your patches.
> 
> And looked at the logic-analyzer: I see distinct waveform pattern
> for clk and data for all events!

The problem I see, is not that there is no waveform but that it has the wrong 
timing.
I'll make an example:
Data is 0xAA,0xFF, CPOL=1, CPHA=1
What happens is this:
CS goes active and MOSI goes high (first bit in 1)
After a short time, SCLK goes from low to high and MOSI goes to low (second 
bit is 0)
Then SCLK goes low (sampling data)
Then SCLK goes high and MOSI goes high (third bit is 1) 
and so on.
At the end with the last rising edge of SCLK MOSI goes to low and stays there 
while SCLK goes to low and then CS to inactive.

So the slave has no chance to get the first bit but gets an additional 0 at the 
end.
It may not be easy visible with 0x00,0x82,0x00 as data, so could you repeat 
your test with 0xAA,0xFF if you see the same as I do or not?

Thanks,
Stephan



From lars.persson at axis.com  Thu Feb 11 08:06:16 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 17:06:16 +0100
Subject: [PATCH v3 1/6] arm: add device-tree SoC bindings for Axis Artpec-6
In-Reply-To: <cover.1455205057.git.larper@axis.com>
References: <cover.1455205057.git.larper@axis.com>
Message-ID: <0a38251ad8ad1895a1744f43a58f6b161676af09.1455205057.git.larper@axis.com>

This adds device tree bindings for the Artpec-6 SoC.

Signed-off-by: Lars Persson <larper at axis.com>
---
 Documentation/devicetree/bindings/arm/axis.txt | 29 ++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/axis.txt

diff --git a/Documentation/devicetree/bindings/arm/axis.txt b/Documentation/devicetree/bindings/arm/axis.txt
new file mode 100644
index 0000000..ae345e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/axis.txt
@@ -0,0 +1,29 @@
+Axis Communications AB
+ARTPEC series SoC Device Tree Bindings
+
+ARTPEC-6 ARM SoC
+================
+
+Required root node properties:
+- compatible = "axis,artpec6";
+
+ARTPEC-6 System Controller
+--------------------------
+
+The ARTPEC-6 has a system controller with mixed functions controlling DMA, PCIe
+and resets.
+
+Required properties:
+- compatible: "axis,artpec6-syscon", "syscon"
+- reg: Address and length of the register bank.
+
+Example:
+	syscon {
+		compatible = "axis,artpec6-syscon", "syscon";
+		reg = <0xf8000000 0x48>;
+	};
+
+ARTPEC-6 Development board:
+---------------------------
+Required root node properties:
+- compatible = "axis,artpec6-dev-board", "axis,artpec6";
-- 
2.1.4



From lars.persson at axis.com  Thu Feb 11 08:06:20 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 17:06:20 +0100
Subject: [PATCH v3 5/6] arm: multi_v7_defconfig: add MACH_ARTPEC6
In-Reply-To: <cover.1455205057.git.larper@axis.com>
References: <cover.1455205057.git.larper@axis.com>
Message-ID: <2ad1a7abcbbfc0861ac788d2df16241a501880d8.1455205057.git.larper@axis.com>

Signed-off-by: Lars Persson <larper at axis.com>
---
 arch/arm/configs/multi_v7_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 8e8b2ac..1149642 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -16,6 +16,8 @@ CONFIG_ARCH_MULTI_V7=y
 # CONFIG_ARCH_MULTI_V4 is not set
 CONFIG_ARCH_VIRT=y
 CONFIG_ARCH_ALPINE=y
+CONFIG_ARCH_ARTPEC=y
+CONFIG_MACH_ARTPEC6=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_375=y
@@ -227,6 +229,7 @@ CONFIG_R8169=y
 CONFIG_SH_ETH=y
 CONFIG_SMSC911X=y
 CONFIG_STMMAC_ETH=y
+CONFIG_SYNOPSYS_DWC_ETH_QOS=y
 CONFIG_TI_CPSW=y
 CONFIG_XILINX_EMACLITE=y
 CONFIG_AT803X_PHY=y
-- 
2.1.4



From lars.persson at axis.com  Thu Feb 11 08:06:15 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 17:06:15 +0100
Subject: [PATCH v3 0/6] arm: Add Artpec-6 SoC
Message-ID: <cover.1455205057.git.larper@axis.com>

Basic support for the Axis Artpec-6 ARM SoC. Timers, interrupts, UARTs and
ethernet are wired up.

Changes since v2:
- Create a syscon binding for the system controller.
- Clock patches split out to new patch series "clk: Add Artpec-6 SoC support".

Changes since v1:
- Corrected bindings for axis,artpec6-pll1-clock.
- Moved the uart aliases to the board dts.
- Kconfig cleanup.
- Added a device tree binding for the dma configuration.
- Added CONFIG_SYNOPSYS_DWC_ETH_QOS to multi_v7_defconfig.
- Added binding documentation for axis,artpec6-dev-board.

Lars Persson (6):
  arm: add device-tree SoC bindings for Axis Artpec-6
  arm: dts: add Artpec-6 SoC dtsi file
  arm: dts: add Artpec-6 development board dts
  arm: initial machine port for artpec-6 SoC
  arm: multi_v7_defconfig: add MACH_ARTPEC6
  arm: mach-artpec: add entry to MAINTAINERS

 Documentation/devicetree/bindings/arm/axis.txt |  29 +++
 MAINTAINERS                                    |  10 ++
 arch/arm/Kconfig                               |   2 +
 arch/arm/Makefile                              |   1 +
 arch/arm/boot/dts/Makefile                     |   2 +
 arch/arm/boot/dts/artpec6-devboard.dts         |  64 +++++++
 arch/arm/boot/dts/artpec6.dtsi                 | 236 +++++++++++++++++++++++++
 arch/arm/configs/multi_v7_defconfig            |   3 +
 arch/arm/mach-artpec/Kconfig                   |  20 +++
 arch/arm/mach-artpec/Makefile                  |   1 +
 arch/arm/mach-artpec/board-artpec6.c           |  72 ++++++++
 11 files changed, 440 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/axis.txt
 create mode 100644 arch/arm/boot/dts/artpec6-devboard.dts
 create mode 100644 arch/arm/boot/dts/artpec6.dtsi
 create mode 100644 arch/arm/mach-artpec/Kconfig
 create mode 100644 arch/arm/mach-artpec/Makefile
 create mode 100644 arch/arm/mach-artpec/board-artpec6.c

-- 
2.1.4



From lars.persson at axis.com  Thu Feb 11 08:06:18 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 17:06:18 +0100
Subject: [PATCH v3 3/6] arm: dts: add Artpec-6 development board dts
In-Reply-To: <cover.1455205057.git.larper@axis.com>
References: <cover.1455205057.git.larper@axis.com>
Message-ID: <8f47493c9ed0044d17333a99c07e9067861ee96b.1455205057.git.larper@axis.com>

Signed-off-by: Lars Persson <larper at axis.com>
---
 arch/arm/boot/dts/Makefile             |  2 ++
 arch/arm/boot/dts/artpec6-devboard.dts | 64 ++++++++++++++++++++++++++++++++++
 2 files changed, 66 insertions(+)
 create mode 100644 arch/arm/boot/dts/artpec6-devboard.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..2ebe99c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -2,6 +2,8 @@ ifeq ($(CONFIG_OF),y)
 
 dtb-$(CONFIG_ARCH_ALPINE) += \
 	alpine-db.dtb
+dtb-$(CONFIG_MACH_ARTPEC6) += \
+	artpec6-devboard.dtb
 dtb-$(CONFIG_MACH_ASM9260) += \
 	alphascale-asm9260-devkit.dtb
 # Keep at91 dtb files sorted alphabetically for each SoC
diff --git a/arch/arm/boot/dts/artpec6-devboard.dts b/arch/arm/boot/dts/artpec6-devboard.dts
new file mode 100644
index 0000000..f823ed3
--- /dev/null
+++ b/arch/arm/boot/dts/artpec6-devboard.dts
@@ -0,0 +1,64 @@
+/*
+ * Axis ARTPEC-6 development board.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "artpec6.dtsi"
+
+/ {
+	model = "ARTPEC-6 development board";
+	compatible = "axis,artpec6-dev-board", "axis,artpec6";
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+	};
+
+	chosen {
+		stdout-path = "serial3:115200n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x0 0x10000000>;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart1 {
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&uart3 {
+	status = "okay";
+};
+
+&ethernet {
+	status = "okay";
+
+	phy-handle = <&phy1>;
+	phy-mode = "gmii";
+
+	mdio {
+		#address-cells = <0x1>;
+		#size-cells = <0x0>;
+		phy1: phy at 0 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			device_type = "ethernet-phy";
+			reg = <0x0>;
+		};
+	};
+};
-- 
2.1.4



From lars.persson at axis.com  Thu Feb 11 08:06:21 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 17:06:21 +0100
Subject: [PATCH v3 6/6] arm: mach-artpec: add entry to MAINTAINERS
In-Reply-To: <cover.1455205057.git.larper@axis.com>
References: <cover.1455205057.git.larper@axis.com>
Message-ID: <164f1c0049b0e1564e133a293ea18920019e3328.1455205057.git.larper@axis.com>

Signed-off-by: Lars Persson <larper at axis.com>
Signed-off-by: Jesper Nilsson <jesper.nilsson at axis.com>
---
 MAINTAINERS | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7f1fa4f..d32c1aa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -932,6 +932,16 @@ M:	Tsahee Zidenberg <tsahee at annapurnalabs.com>
 S:	Maintained
 F:	arch/arm/mach-alpine/
 
+ARM/ARTPEC MACHINE SUPPORT
+M:	Jesper Nilsson <jesper.nilsson at axis.com>
+M:	Lars Persson <lars.persson at axis.com>
+M:	Niklas Cassel <niklas.cassel at axis.com>
+S:	Maintained
+L:	linux-arm-kernel at axis.com
+F:	arch/arm/mach-artpec
+F:	arch/arm/boot/dts/artpec6*
+F:	drivers/clk/clk-artpec6.c
+
 ARM/ATMEL AT91RM9200, AT91SAM9 AND SAMA5 SOC SUPPORT
 M:	Nicolas Ferre <nicolas.ferre at atmel.com>
 M:	Alexandre Belloni <alexandre.belloni at free-electrons.com>
-- 
2.1.4



From lars.persson at axis.com  Thu Feb 11 08:06:19 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 17:06:19 +0100
Subject: [PATCH v3 4/6] arm: initial machine port for artpec-6 SoC
In-Reply-To: <cover.1455205057.git.larper@axis.com>
References: <cover.1455205057.git.larper@axis.com>
Message-ID: <3c22d68c2d091990c0f54df76344e1e7c16dd408.1455205057.git.larper@axis.com>

Basic machine port for the Artpec-6 SoC from Axis
Communications.

Signed-off-by: Lars Persson <larper at axis.com>
---
 arch/arm/Kconfig                     |  2 +
 arch/arm/Makefile                    |  1 +
 arch/arm/mach-artpec/Kconfig         | 20 ++++++++++
 arch/arm/mach-artpec/Makefile        |  1 +
 arch/arm/mach-artpec/board-artpec6.c | 72 ++++++++++++++++++++++++++++++++++++
 5 files changed, 96 insertions(+)
 create mode 100644 arch/arm/mach-artpec/Kconfig
 create mode 100644 arch/arm/mach-artpec/Makefile
 create mode 100644 arch/arm/mach-artpec/board-artpec6.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4f799e5..e1565dd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -724,6 +724,8 @@ source "arch/arm/mach-mvebu/Kconfig"
 
 source "arch/arm/mach-alpine/Kconfig"
 
+source "arch/arm/mach-artpec/Kconfig"
+
 source "arch/arm/mach-asm9260/Kconfig"
 
 source "arch/arm/mach-at91/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index fe25410..4eb24c6 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -154,6 +154,7 @@ textofs-$(CONFIG_ARCH_AXXIA) := 0x00308000
 # Machine directory name.  This list is sorted alphanumerically
 # by CONFIG_* macro name.
 machine-$(CONFIG_ARCH_ALPINE)		+= alpine
+machine-$(CONFIG_ARCH_ARTPEC)		+= artpec
 machine-$(CONFIG_ARCH_AT91)		+= at91
 machine-$(CONFIG_ARCH_AXXIA)		+= axxia
 machine-$(CONFIG_ARCH_BCM)		+= bcm
diff --git a/arch/arm/mach-artpec/Kconfig b/arch/arm/mach-artpec/Kconfig
new file mode 100644
index 0000000..6cbe5a2
--- /dev/null
+++ b/arch/arm/mach-artpec/Kconfig
@@ -0,0 +1,20 @@
+menuconfig ARCH_ARTPEC
+	bool "Axis Communications ARM based ARTPEC SoCs"
+	depends on ARCH_MULTI_V7
+
+if ARCH_ARTPEC
+
+config MACH_ARTPEC6
+	bool "Axis ARTPEC-6 ARM Cortex A9 Platform"
+	depends on ARCH_MULTI_V7
+	select ARM_AMBA
+	select ARM_GIC
+	select ARM_GLOBAL_TIMER
+	select ARM_PSCI
+	select HAVE_ARM_ARCH_TIMER
+	select HAVE_ARM_SCU
+	select HAVE_ARM_TWD if SMP
+	help
+	  Support for Axis ARTPEC-6 ARM Cortex A9 Platform
+
+endif
diff --git a/arch/arm/mach-artpec/Makefile b/arch/arm/mach-artpec/Makefile
new file mode 100644
index 0000000..78325f0
--- /dev/null
+++ b/arch/arm/mach-artpec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MACH_ARTPEC6)		:= board-artpec6.o
diff --git a/arch/arm/mach-artpec/board-artpec6.c b/arch/arm/mach-artpec/board-artpec6.c
new file mode 100644
index 0000000..71513df
--- /dev/null
+++ b/arch/arm/mach-artpec/board-artpec6.c
@@ -0,0 +1,72 @@
+/*
+ * ARTPEC-6 device support.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/amba/bus.h>
+#include <linux/clocksource.h>
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of_platform.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/clk-provider.h>
+#include <linux/regmap.h>
+#include <linux/smp.h>
+#include <asm/smp_scu.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/psci.h>
+#include <linux/arm-smccc.h>
+
+
+#define ARTPEC6_DMACFG_REGNUM 0x10
+#define ARTPEC6_DMACFG_UARTS_BURST 0xff
+
+#define SECURE_OP_L2C_WRITEREG 0xb4000001
+
+static void __init artpec6_init_machine(void)
+{
+	struct regmap *regmap;
+
+	regmap = syscon_regmap_lookup_by_compatible("axis,artpec6-syscon");
+
+	if (!IS_ERR(regmap)) {
+		/* Use PL011 DMA Burst Request signal instead of DMA
+		 *  Single Request
+		 */
+		regmap_write(regmap, ARTPEC6_DMACFG_REGNUM,
+			     ARTPEC6_DMACFG_UARTS_BURST);
+	};
+
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static void artpec6_l2c310_write_sec(unsigned long val, unsigned reg)
+{
+	struct arm_smccc_res res;
+
+	arm_smccc_smc(SECURE_OP_L2C_WRITEREG, reg, val, 0,
+		      0, 0, 0, 0, &res);
+
+	WARN_ON(res.a0);
+}
+
+static const char * const artpec6_dt_match[] = {
+	"axis,artpec6",
+	NULL
+};
+
+DT_MACHINE_START(ARTPEC6, "Axis ARTPEC-6 Platform")
+	.l2c_aux_val	= 0x0C000000,
+	.l2c_aux_mask	= 0xF3FFFFFF,
+	.l2c_write_sec  = artpec6_l2c310_write_sec,
+	.init_machine	= artpec6_init_machine,
+	.dt_compat	= artpec6_dt_match,
+MACHINE_END
-- 
2.1.4



From lars.persson at axis.com  Thu Feb 11 08:06:17 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 11 Feb 2016 17:06:17 +0100
Subject: [PATCH v3 2/6] arm: dts: add Artpec-6 SoC dtsi file
In-Reply-To: <cover.1455205057.git.larper@axis.com>
References: <cover.1455205057.git.larper@axis.com>
Message-ID: <9d3b8e80eeb56ca0808aae62eabd82af23ddb5c5.1455205057.git.larper@axis.com>

Initial device tree for the Artpec-6 SoC.

Signed-off-by: Lars Persson <larper at axis.com>
---
 arch/arm/boot/dts/artpec6.dtsi | 236 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 arch/arm/boot/dts/artpec6.dtsi

diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/arm/boot/dts/artpec6.dtsi
new file mode 100644
index 0000000..f2a7e4a
--- /dev/null
+++ b/arch/arm/boot/dts/artpec6.dtsi
@@ -0,0 +1,236 @@
+/*
+ * Device Tree Source for the Axis ARTPEC-6 SoC
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "skeleton.dtsi"
+
+/ {
+	compatible = "axis,artpec6";
+	interrupt-parent = <&intc>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+			next-level-cache = <&pl310>;
+		};
+
+		cpu1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <1>;
+			next-level-cache = <&pl310>;
+		};
+	};
+
+	syscon {
+		compatible = "axis,artpec6-syscon", "syscon";
+		reg = <0xf8000000 0x48>;
+	};
+
+	psci {
+		compatible = "arm,psci-0.2", "arm,psci";
+		method = "smc";
+		psci_version = <0x84000000>;
+		cpu_on = <0x84000003>;
+		system_reset = <0x84000009>;
+	};
+
+	scu at faf00000 {
+		compatible = "arm,cortex-a9-scu";
+		reg = <0xfaf00000 0x58>;
+	};
+
+	/* Main external clock driving CPU and peripherals */
+	ext_clk: ext_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <50000000>;
+	};
+
+	/* PLL1 is used by CPU and some peripherals */
+	pll1_clk: pll1_clk at f8000000 {
+		#clock-cells = <0>;
+		compatible = "axis,artpec6-pll1-clock";
+		reg = <0xf8000000 4>;
+		clocks = <&ext_clk>;
+	};
+
+	cpu_clk: cpu_clk {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&pll1_clk>;
+		clock-output-names = "cpu_clk";
+	};
+
+	cpu_clkdiv2: cpu_clkdiv2 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <2>;
+		clock-mult = <1>;
+		clocks = <&cpu_clk>;
+	};
+
+	cpu_clkdiv4: cpu_clkdiv4 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <4>;
+		clock-mult = <1>;
+		clocks = <&cpu_clk>;
+	};
+
+	apb_pclk: apb_pclk {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <8>;
+		clock-mult = <1>;
+		clocks = <&cpu_clk>;
+		clock-output-names = "apb_pclk";
+	};
+
+	/* PLL2 is used by a number of peripherals, including UDL */
+	pll2: pll2 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <24>;
+		clocks = <&ext_clk>;
+	};
+
+	/* PLL2DIV2 is used by the Fractional Clock Divider, for i2s */
+	pll2div2: pll2div2 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <2>;
+		clock-mult = <1>;
+		clocks = <&pll2>;
+	};
+
+	pll2div12: pll2div12 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <12>;
+		clock-mult = <1>;
+		clocks = <&pll2>;
+	};
+
+	pll2div24: pll2div24 {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <24>;
+		clock-mult = <1>;
+		clocks = <&pll2>;
+		clock-output-names = "uart_clk";
+	};
+
+
+	gtimer at faf00200 {
+		compatible = "arm,cortex-a9-global-timer";
+		reg = <0xfaf00200 0x20>;
+		interrupts = <GIC_PPI 11 0xf01>;
+		clocks = <&cpu_clkdiv2>;
+	};
+
+	timer at faf00600 {
+		compatible = "arm,cortex-a9-twd-timer";
+		reg = <0xfaf00600 0x20>;
+		interrupts = <GIC_PPI 13 0xf04>;
+		clocks = <&cpu_clkdiv2>;
+		status = "disabled";
+	};
+
+	intc: interrupt-controller at faf01000 {
+		interrupt-controller;
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		reg = < 0xfaf01000 0x1000 >, < 0xfaf00100 0x0100 >;
+	};
+
+	pl310: cache-controller at faf10000 {
+		compatible = "arm,pl310-cache";
+		cache-unified;
+		cache-level = <2>;
+		reg = <0xfaf10000 0x1000>;
+		interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+		arm,data-latency = <1 1 1>;
+		arm,tag-latency = <1 1 1>;
+		arm,filter-ranges = <0x0 0x80000000>;
+	};
+
+	pmu {
+		compatible = "arm,cortex-a9-pmu";
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			<GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-parent = <&intc>;
+	};
+
+	amba at 0 {
+		compatible = "simple-bus";
+		#address-cells = <0x1>;
+		#size-cells = <0x1>;
+		interrupt-parent = <&intc>;
+		ranges;
+		dma-ranges = <0x80000000 0x00000000 0x40000000>;
+		dma-coherent;
+
+		ethernet: ethernet at f8010000 {
+			clock-names = "phy_ref_clk", "apb_pclk";
+			clocks = <&ext_clk>, <&apb_pclk>;
+			compatible = "snps,dwc-qos-ethernet-4.10";
+			interrupt-parent = <&intc>;
+			interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+			reg = <0xf8010000 0x4000>;
+
+			snps,write-requests = <2>;
+			snps,read-requests = <16>;
+			snps,txpbl = <8>;
+			snps,rxpbl = <2>;
+
+			status = "disabled";
+		};
+
+		uart0: serial at f8036000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xf8036000 0x1000>;
+			interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pll2div24>, <&apb_pclk>;
+			clock-names = "uart_clk", "apb_pclk";
+			status = "disabled";
+		};
+		uart1: serial at f8037000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xf8037000 0x1000>;
+			interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pll2div24>, <&apb_pclk>;
+			clock-names = "uart_clk", "apb_pclk";
+			status = "disabled";
+		};
+		uart2: serial at f8038000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xf8038000 0x1000>;
+			interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pll2div24>, <&apb_pclk>;
+			clock-names = "uart_clk", "apb_pclk";
+			status = "disabled";
+		};
+		uart3: serial at f8039000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0xf8039000 0x1000>;
+			interrupts = <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pll2div24>, <&apb_pclk>;
+			clock-names = "uart_clk", "apb_pclk";
+			status = "disabled";
+		};
+	};
+};
-- 
2.1.4



From arnd at arndb.de  Thu Feb 11 08:06:32 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 17:06:32 +0100
Subject: [PATCH v2 1/6] Revert "drivers/tty/serial: make 8250/8250_mtk.c
 explicitly non-modular"
In-Reply-To: <20160211160021.GF28452@windriver.com>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
 <1455205297-1021302-2-git-send-email-arnd@arndb.de>
 <20160211160021.GF28452@windriver.com>
Message-ID: <3873766.I9XIY0R8gT@wuerfel>

On Thursday 11 February 2016 11:00:22 Paul Gortmaker wrote:
> [[PATCH v2 1/6] Revert "drivers/tty/serial: make 8250/8250_mtk.c explicitly non-modular"] On 11/02/2016 (Thu 16:41) Arnd Bergmann wrote:
> 
> > This reverts commit d72d391c126e, which tried to remove dead code but
> > left the driver in a useless state when the main 8250 driver is a
> 
> Am I misunderstanding something?  The commit didn't cause the driver to
> be in a useless state for 8250=m.  But rather isn't that it was a
> pre-existing condition, independent of the change to 8250_mtk.c to
> remove the dead code in d72d391c126e?
> 
> Since the commit did not touch Kconfig or Makefile, I can't see how it
> could cause some new useless state that did not already exist, and hence
> the "Fixes:" tag is invalid as well.

My wording may have been bad here. What I meant to say is that it
was broken before the patch, and still broken after the patch.

The Fixes tag was meant to just be a reference to the commit I'm
reverting.

	Arnd


From robin.murphy at arm.com  Thu Feb 11 08:13:45 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 11 Feb 2016 16:13:45 +0000
Subject: [PATCH 4/3] iommu/io-pgtable: Rationalise quirk handling
In-Reply-To: <20160210154815.GO1052@arm.com>
References: <cover.1453723096.git.robin.murphy@arm.com>
 <066c4af0e29c9cc658bd5e48edc5e2d7ba7140a1.1453723096.git.robin.murphy@arm.com>
 <20160210154815.GO1052@arm.com>
Message-ID: <ea1f3d3feec0dc9c18d43393678370b50b1275f5.1455206840.git.robin.murphy@arm.com>

As the number of io-pgtable implementations grows beyond 1, it's time
to rationalise the quirks mechanism before things have a chance to
start getting really ugly and out-of-hand.

To that end:
- Indicate exactly which quirks each format can/does support.
- Fail creating a table if a caller wants unsupported quirks.
- Properly document where each quirk applies and why.

Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---
 drivers/iommu/io-pgtable-arm-v7s.c |  3 +++
 drivers/iommu/io-pgtable-arm.c     |  2 ++
 drivers/iommu/io-pgtable.c         |  3 +++
 drivers/iommu/io-pgtable.h         | 24 ++++++++++++++++++++----
 4 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index d39a021..9bc607a 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -690,6 +690,9 @@ out_free_data:
 struct io_pgtable_init_fns io_pgtable_arm_v7s_init_fns = {
 	.alloc	= arm_v7s_alloc_pgtable,
 	.free	= arm_v7s_free_pgtable,
+	.supported_quirks = IO_PGTABLE_QUIRK_ARM_NS |
+			    IO_PGTABLE_QUIRK_NO_PERMS |
+			    IO_PGTABLE_QUIRK_TLBI_ON_MAP,
 };
 
 #ifdef CONFIG_IOMMU_IO_PGTABLE_ARMV7S_SELFTEST
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 4095af2..32f94f1 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -863,6 +863,7 @@ arm_32_lpae_alloc_pgtable_s2(struct io_pgtable_cfg *cfg, void *cookie)
 struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s1_init_fns = {
 	.alloc	= arm_64_lpae_alloc_pgtable_s1,
 	.free	= arm_lpae_free_pgtable,
+	.supported_quirks = IO_PGTABLE_QUIRK_ARM_NS,
 };
 
 struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s2_init_fns = {
@@ -873,6 +874,7 @@ struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s2_init_fns = {
 struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s1_init_fns = {
 	.alloc	= arm_32_lpae_alloc_pgtable_s1,
 	.free	= arm_lpae_free_pgtable,
+	.supported_quirks = IO_PGTABLE_QUIRK_ARM_NS,
 };
 
 struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s2_init_fns = {
diff --git a/drivers/iommu/io-pgtable.c b/drivers/iommu/io-pgtable.c
index 876f6a7..0f57a45 100644
--- a/drivers/iommu/io-pgtable.c
+++ b/drivers/iommu/io-pgtable.c
@@ -52,6 +52,9 @@ struct io_pgtable_ops *alloc_io_pgtable_ops(enum io_pgtable_fmt fmt,
 	if (!fns)
 		return NULL;
 
+	if (cfg->quirks & ~fns->supported_quirks)
+		return NULL;
+
 	iop = fns->alloc(cfg, cookie);
 	if (!iop)
 		return NULL;
diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
index 4faee7d..6e7f11e 100644
--- a/drivers/iommu/io-pgtable.h
+++ b/drivers/iommu/io-pgtable.h
@@ -47,10 +47,24 @@ struct iommu_gather_ops {
  *                 page table walker.
  */
 struct io_pgtable_cfg {
-	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0) /* Set NS bit in PTEs */
-	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1) /* No AP/XN bits */
-	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2) /* TLB Inv. on map */
-	int				quirks;
+	/*
+	 * IO_PGTABLE_QUIRK_ARM_NS: (ARM formats) Set NS and NSTABLE bits in
+	 *	stage 1 PTEs, for hardware which insists on validating them
+	 *	even in	non-secure state where they should normally be ignored.
+	 *
+	 * IO_PGTABLE_QUIRK_NO_PERMS: Ignore the IOMMU_READ, IOMMU_WRITE and
+	 *	IOMMU_NOEXEC flags and map everything with full access, for
+	 *	hardware which does not implement the permissions of a given
+	 *	format, and/or requires some format-specific default value.
+	 *
+	 * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching invalid
+	 *	(unmapped) entries but the hardware might do so anyway, perform
+	 *	TLB maintenance when mapping as well as when unmapping.
+	 */
+	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
+	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
+	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2)
+	unsigned int			quirks;
 	unsigned long			pgsize_bitmap;
 	unsigned int			ias;
 	unsigned int			oas;
@@ -173,10 +187,12 @@ static inline void io_pgtable_tlb_sync(struct io_pgtable *iop)
  *
  * @alloc: Allocate a set of page tables described by cfg.
  * @free:  Free the page tables associated with iop.
+ * @supported_quirks: Bitmap of quirks supported by the format.
  */
 struct io_pgtable_init_fns {
 	struct io_pgtable *(*alloc)(struct io_pgtable_cfg *cfg, void *cookie);
 	void (*free)(struct io_pgtable *iop);
+	unsigned int supported_quirks;
 };
 
 extern struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s1_init_fns;
-- 
2.7.0.25.gfc10eb5.dirty



From robh+dt at kernel.org  Thu Feb 11 08:13:53 2016
From: robh+dt at kernel.org (Rob Herring)
Date: Thu, 11 Feb 2016 10:13:53 -0600
Subject: [PATCH 3/3] ARM64: zynqmp: Use 64bit size cell format
In-Reply-To: <36fb9c4c9b2019b854e84dc0a9a01252a6de2337.1455193571.git.michal.simek@xilinx.com>
References: <2f160e012080d5d6de11238ade239bb0bb224f64.1455193571.git.michal.simek@xilinx.com>
 <36fb9c4c9b2019b854e84dc0a9a01252a6de2337.1455193571.git.michal.simek@xilinx.com>
Message-ID: <CAL_JsqK0=LaXqJyr_rGKCzGgt5kFy79-4ARocTGpKved3JU-Ug@mail.gmail.com>

On Thu, Feb 11, 2016 at 6:26 AM, Michal Simek <michal.simek at xilinx.com> wrote:
> Use 64bit size cell format instead of 32bit for memory
> description. Change 64bit sizes also for all others IPs.

Why? As is, this change is completely pointless because nothing needs
a >4GB size. Do you have peripherals with >4GB size?

> Signed-off-by: Michal Simek <michal.simek at xilinx.com>
> ---
>
>  arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts |  2 +-
>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi      | 63 ++++++++++++++---------------
>  2 files changed, 32 insertions(+), 33 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
> index acb0527fdc4a..358089687a69 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
> @@ -29,7 +29,7 @@
>
>         memory {
>                 device_type = "memory";
> -               reg = <0x0 0x0 0x40000000>;
> +               reg = <0x0 0x0 0x0 0x40000000>;
>         };
>  };
>
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> index e595f22e7e4b..ef8fe8e6c868 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> @@ -14,7 +14,7 @@
>  / {
>         compatible = "xlnx,zynqmp";
>         #address-cells = <2>;
> -       #size-cells = <1>;
> +       #size-cells = <2>;
>
>         cpus {
>                 #address-cells = <1>;
> @@ -74,16 +74,15 @@
>         amba_apu {
>                 compatible = "simple-bus";
>                 #address-cells = <2>;
> -               #size-cells = <1>;
> +               #size-cells = <2>;
>                 ranges;
> -
>                 gic: interrupt-controller at f9010000 {
>                         compatible = "arm,gic-400", "arm,cortex-a15-gic";
>                         #interrupt-cells = <3>;
> -                       reg = <0x0 0xf9010000 0x10000>,
> -                             <0x0 0xf902f000 0x2000>,
> -                             <0x0 0xf9040000 0x20000>,
> -                             <0x0 0xf906f000 0x2000>;
> +                       reg = <0x0 0xf9010000 0x0 0x10000>,
> +                             <0x0 0xf902f000 0x0 0x2000>,
> +                             <0x0 0xf9040000 0x0 0x20000>,
> +                             <0x0 0xf906f000 0x0 0x2000>;
>                         interrupt-controller;
>                         interrupt-parent = <&gic>;
>                         interrupts = <1 9 0xf04>;
> @@ -93,14 +92,14 @@
>         amba: amba {
>                 compatible = "simple-bus";
>                 #address-cells = <2>;
> -               #size-cells = <1>;
> +               #size-cells = <2>;
>                 ranges;
>
>                 can0: can at ff060000 {
>                         compatible = "xlnx,zynq-can-1.0";
>                         status = "disabled";
>                         clock-names = "can_clk", "pclk";
> -                       reg = <0x0 0xff060000 0x1000>;
> +                       reg = <0x0 0xff060000 0x0 0x1000>;
>                         interrupts = <0 23 4>;
>                         interrupt-parent = <&gic>;
>                         tx-fifo-depth = <0x40>;
> @@ -111,7 +110,7 @@
>                         compatible = "xlnx,zynq-can-1.0";
>                         status = "disabled";
>                         clock-names = "can_clk", "pclk";
> -                       reg = <0x0 0xff070000 0x1000>;
> +                       reg = <0x0 0xff070000 0x0 0x1000>;
>                         interrupts = <0 24 4>;
>                         interrupt-parent = <&gic>;
>                         tx-fifo-depth = <0x40>;
> @@ -123,7 +122,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 57 4>, <0 57 4>;
> -                       reg = <0x0 0xff0b0000 0x1000>;
> +                       reg = <0x0 0xff0b0000 0x0 0x1000>;
>                         clock-names = "pclk", "hclk", "tx_clk";
>                         #address-cells = <1>;
>                         #size-cells = <0>;
> @@ -134,7 +133,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 59 4>, <0 59 4>;
> -                       reg = <0x0 0xff0c0000 0x1000>;
> +                       reg = <0x0 0xff0c0000 0x0 0x1000>;
>                         clock-names = "pclk", "hclk", "tx_clk";
>                         #address-cells = <1>;
>                         #size-cells = <0>;
> @@ -145,7 +144,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 61 4>, <0 61 4>;
> -                       reg = <0x0 0xff0d0000 0x1000>;
> +                       reg = <0x0 0xff0d0000 0x0 0x1000>;
>                         clock-names = "pclk", "hclk", "tx_clk";
>                         #address-cells = <1>;
>                         #size-cells = <0>;
> @@ -156,7 +155,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 63 4>, <0 63 4>;
> -                       reg = <0x0 0xff0e0000 0x1000>;
> +                       reg = <0x0 0xff0e0000 0x0 0x1000>;
>                         clock-names = "pclk", "hclk", "tx_clk";
>                         #address-cells = <1>;
>                         #size-cells = <0>;
> @@ -170,7 +169,7 @@
>                         interrupts = <0 16 4>;
>                         interrupt-controller;
>                         #interrupt-cells = <2>;
> -                       reg = <0x0 0xff0a0000 0x1000>;
> +                       reg = <0x0 0xff0a0000 0x0 0x1000>;
>                 };
>
>                 i2c0: i2c at ff020000 {
> @@ -178,7 +177,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 17 4>;
> -                       reg = <0x0 0xff020000 0x1000>;
> +                       reg = <0x0 0xff020000 0x0 0x1000>;
>                         #address-cells = <1>;
>                         #size-cells = <0>;
>                 };
> @@ -188,7 +187,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 18 4>;
> -                       reg = <0x0 0xff030000 0x1000>;
> +                       reg = <0x0 0xff030000 0x0 0x1000>;
>                         #address-cells = <1>;
>                         #size-cells = <0>;
>                 };
> @@ -196,7 +195,7 @@
>                 sata: ahci at fd0c0000 {
>                         compatible = "ceva,ahci-1v84";
>                         status = "disabled";
> -                       reg = <0x0 0xfd0c0000 0x2000>;
> +                       reg = <0x0 0xfd0c0000 0x0 0x2000>;
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 133 4>;
>                 };
> @@ -206,7 +205,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 48 4>;
> -                       reg = <0x0 0xff160000 0x1000>;
> +                       reg = <0x0 0xff160000 0x0 0x1000>;
>                         clock-names = "clk_xin", "clk_ahb";
>                 };
>
> @@ -215,13 +214,13 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 49 4>;
> -                       reg = <0x0 0xff170000 0x1000>;
> +                       reg = <0x0 0xff170000 0x0 0x1000>;
>                         clock-names = "clk_xin", "clk_ahb";
>                 };
>
>                 smmu: smmu at fd800000 {
>                         compatible = "arm,mmu-500";
> -                       reg = <0x0 0xfd800000 0x20000>;
> +                       reg = <0x0 0xfd800000 0x0 0x20000>;
>                         #global-interrupts = <1>;
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 157 4>,
> @@ -236,7 +235,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 19 4>;
> -                       reg = <0x0 0xff040000 0x1000>;
> +                       reg = <0x0 0xff040000 0x0 0x1000>;
>                         clock-names = "ref_clk", "pclk";
>                         #address-cells = <1>;
>                         #size-cells = <0>;
> @@ -247,7 +246,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 20 4>;
> -                       reg = <0x0 0xff050000 0x1000>;
> +                       reg = <0x0 0xff050000 0x0 0x1000>;
>                         clock-names = "ref_clk", "pclk";
>                         #address-cells = <1>;
>                         #size-cells = <0>;
> @@ -258,7 +257,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 36 4>, <0 37 4>, <0 38 4>;
> -                       reg = <0x0 0xff110000 0x1000>;
> +                       reg = <0x0 0xff110000 0x0 0x1000>;
>                         timer-width = <32>;
>                 };
>
> @@ -267,7 +266,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 39 4>, <0 40 4>, <0 41 4>;
> -                       reg = <0x0 0xff120000 0x1000>;
> +                       reg = <0x0 0xff120000 0x0 0x1000>;
>                         timer-width = <32>;
>                 };
>
> @@ -276,7 +275,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 42 4>, <0 43 4>, <0 44 4>;
> -                       reg = <0x0 0xff130000 0x1000>;
> +                       reg = <0x0 0xff130000 0x0 0x1000>;
>                         timer-width = <32>;
>                 };
>
> @@ -285,7 +284,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 45 4>, <0 46 4>, <0 47 4>;
> -                       reg = <0x0 0xff140000 0x1000>;
> +                       reg = <0x0 0xff140000 0x0 0x1000>;
>                         timer-width = <32>;
>                 };
>
> @@ -294,7 +293,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 21 4>;
> -                       reg = <0x0 0xff000000 0x1000>;
> +                       reg = <0x0 0xff000000 0x0 0x1000>;
>                         clock-names = "uart_clk", "pclk";
>                 };
>
> @@ -303,7 +302,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 22 4>;
> -                       reg = <0x0 0xff010000 0x1000>;
> +                       reg = <0x0 0xff010000 0x0 0x1000>;
>                         clock-names = "uart_clk", "pclk";
>                 };
>
> @@ -312,7 +311,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 65 4>;
> -                       reg = <0x0 0xfe200000 0x40000>;
> +                       reg = <0x0 0xfe200000 0x0 0x40000>;
>                         clock-names = "clk_xin", "clk_ahb";
>                 };
>
> @@ -321,7 +320,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 70 4>;
> -                       reg = <0x0 0xfe300000 0x40000>;
> +                       reg = <0x0 0xfe300000 0x0 0x40000>;
>                         clock-names = "clk_xin", "clk_ahb";
>                 };
>
> @@ -330,7 +329,7 @@
>                         status = "disabled";
>                         interrupt-parent = <&gic>;
>                         interrupts = <0 52 1>;
> -                       reg = <0x0 0xfd4d0000 0x1000>;
> +                       reg = <0x0 0xfd4d0000 0x0 0x1000>;
>                         timeout-sec = <10>;
>                 };
>         };
> --
> 1.9.1
>


From matt at codeblueprint.co.uk  Thu Feb 11 08:16:21 2016
From: matt at codeblueprint.co.uk (Matt Fleming)
Date: Thu, 11 Feb 2016 16:16:21 +0000
Subject: [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks
In-Reply-To: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160211161621.GM4134@codeblueprint.co.uk>

On Thu, 04 Feb, at 04:50:23PM, Ard Biesheuvel wrote:
> I merged two EFI/ARM related series, whose v1's I sent out last week:
> 
> Changes since v1:
> - added various tags from various people
> - new patch #3 to undefine __init
> 
> @Matt: are you happy with all of this going through the arm64 tree? I don't
> think it clashes with anything else we've got queued up for v4.6 in tip/efi/core

How come this is going through the arm64 tree? Are there other patch
series that this depends on or that depend on it?

If it makes the most sense to take it through that tree, then I'm fine
with it but I'd like to hear a rationale.


From sunil.kovvuri at gmail.com  Thu Feb 11 08:20:20 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Thu, 11 Feb 2016 21:50:20 +0530
Subject: [PATCH v2 0/6] net: thunderx: Setting IRQ affinity hints and other
 optimizations
Message-ID: <1455207626-35488-1-git-send-email-sunil.kovvuri@gmail.com>

From: Sunil Goutham <sgoutham at cavium.com>

This patch series contains changes
- To add support for virtual function's irq affinity hint
- Replace napi_schedule() with napi_schedule_irqoff()
- Reduce page allocation overhead by allocating pages
  of higher order when pagesize is 4KB.
- Add couple of stats which helps in debugging
- Some miscellaneous changes to BGX driver.

Changes from v1:
- As suggested changed MAC address invalid log message 
  to dev_err() instead of dev_warn().

David Daney (1):
  net: thunderx: bgx: Use standard firmware node infrastructure.

Robert Richter (1):
  net: thunderx: bgx: Add log message when setting mac address

Sunil Goutham (3):
  net: thunderx: Use napi_schedule_irqoff()
  net: thunderx: Assign affinity hints to vf's interrupts
  net: thunderx: Alloc higher order pages when pagesize is small

Thanneeru Srinivasulu (1):
  net, thunderx: Add TX timeout and RX buffer alloc failure stats.

 drivers/net/ethernet/cavium/thunder/nic.h          |    4 ++
 .../net/ethernet/cavium/thunder/nicvf_ethtool.c    |    2 +
 drivers/net/ethernet/cavium/thunder/nicvf_main.c   |   40 ++++++++++++++++++-
 drivers/net/ethernet/cavium/thunder/nicvf_queues.c |    5 +-
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c  |   38 +++++++++++--------
 5 files changed, 67 insertions(+), 22 deletions(-)



From sunil.kovvuri at gmail.com  Thu Feb 11 08:20:21 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Thu, 11 Feb 2016 21:50:21 +0530
Subject: [PATCH v2 1/6] net,
 thunderx: Add TX timeout and RX buffer alloc failure stats.
In-Reply-To: <1455207626-35488-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1455207626-35488-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <1455207626-35488-2-git-send-email-sunil.kovvuri@gmail.com>

From: Thanneeru Srinivasulu <tsrinivasulu at caviumnetworks.com>

When system is low on atomic memory, too many error messages are logged.
Since this is not a total failure but a simple switch to non-atomic allocation
better to have a stat.

Also add a stat for reset, kicked due to transmit watchdog timeout.

Signed-off-by: Thanneeru Srinivasulu <tsrinivasulu at caviumnetworks.com>
Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/nic.h          |    3 +++
 .../net/ethernet/cavium/thunder/nicvf_ethtool.c    |    2 ++
 drivers/net/ethernet/cavium/thunder/nicvf_main.c   |    1 +
 drivers/net/ethernet/cavium/thunder/nicvf_queues.c |    3 +--
 4 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nic.h b/drivers/net/ethernet/cavium/thunder/nic.h
index 6888288..8af363a 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -248,10 +248,13 @@ struct nicvf_drv_stats {
 	u64 rx_frames_jumbo;
 	u64 rx_drops;
 
+	u64 rcv_buffer_alloc_failures;
+
 	/* Tx */
 	u64 tx_frames_ok;
 	u64 tx_drops;
 	u64 tx_tso;
+	u64 tx_timeout;
 	u64 txq_stop;
 	u64 txq_wake;
 };
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
index a12b2e3..d2d8ef2 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
@@ -89,9 +89,11 @@ static const struct nicvf_stat nicvf_drv_stats[] = {
 	NICVF_DRV_STAT(rx_frames_1518),
 	NICVF_DRV_STAT(rx_frames_jumbo),
 	NICVF_DRV_STAT(rx_drops),
+	NICVF_DRV_STAT(rcv_buffer_alloc_failures),
 	NICVF_DRV_STAT(tx_frames_ok),
 	NICVF_DRV_STAT(tx_tso),
 	NICVF_DRV_STAT(tx_drops),
+	NICVF_DRV_STAT(tx_timeout),
 	NICVF_DRV_STAT(txq_stop),
 	NICVF_DRV_STAT(txq_wake),
 };
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index c24cb2a..95db6b7 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -1394,6 +1394,7 @@ static void nicvf_tx_timeout(struct net_device *dev)
 		netdev_warn(dev, "%s: Transmit timed out, resetting\n",
 			    dev->name);
 
+	nic->drv_stats.tx_timeout++;
 	schedule_work(&nic->reset_task);
 }
 
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index d0d1b54..50ab6f4 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -96,8 +96,7 @@ static inline int nicvf_alloc_rcv_buffer(struct nicvf *nic, gfp_t gfp,
 		nic->rb_page = alloc_pages(gfp | __GFP_COMP | __GFP_NOWARN,
 					   order);
 		if (!nic->rb_page) {
-			netdev_err(nic->netdev,
-				   "Failed to allocate new rcv buffer\n");
+			nic->drv_stats.rcv_buffer_alloc_failures++;
 			return -ENOMEM;
 		}
 		nic->rb_page_offset = 0;
-- 
1.7.1



From sunil.kovvuri at gmail.com  Thu Feb 11 08:20:22 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Thu, 11 Feb 2016 21:50:22 +0530
Subject: [PATCH v2 2/6] net: thunderx: Use napi_schedule_irqoff()
In-Reply-To: <1455207626-35488-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1455207626-35488-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <1455207626-35488-3-git-send-email-sunil.kovvuri@gmail.com>

From: Sunil Goutham <sgoutham at cavium.com>

napi_schedule is being called from hard irq context, hence
switch to napi_schedule_irqoff which avoids unneeded call
to local_irq_save and local_irq_restore.

Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/nicvf_main.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 95db6b7..c6f146c 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -828,7 +828,7 @@ static irqreturn_t nicvf_intr_handler(int irq, void *cq_irq)
 	nicvf_disable_intr(nic, NICVF_INTR_CQ, qidx);
 
 	/* Schedule NAPI */
-	napi_schedule(&cq_poll->napi);
+	napi_schedule_irqoff(&cq_poll->napi);
 
 	/* Clear interrupt */
 	nicvf_clear_intr(nic, NICVF_INTR_CQ, qidx);
-- 
1.7.1



From sunil.kovvuri at gmail.com  Thu Feb 11 08:20:23 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Thu, 11 Feb 2016 21:50:23 +0530
Subject: [PATCH v2 3/6] net: thunderx: Assign affinity hints to vf's interrupts
In-Reply-To: <1455207626-35488-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1455207626-35488-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <1455207626-35488-4-git-send-email-sunil.kovvuri@gmail.com>

From: Sunil Goutham <sgoutham at cavium.com>

This affinity hint can be used by user space irqbalance tool to set
preferred CPU mask for irqs registered by this VF. Irqbalance needs
to be in 'exact' mode to set irq affinity same as indicated by
affinity hint.

Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/nic.h        |    1 +
 drivers/net/ethernet/cavium/thunder/nicvf_main.c |   37 ++++++++++++++++++++-
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nic.h b/drivers/net/ethernet/cavium/thunder/nic.h
index 8af363a..00cc915 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -309,6 +309,7 @@ struct nicvf {
 	struct msix_entry	msix_entries[NIC_VF_MSIX_VECTORS];
 	char			irq_name[NIC_VF_MSIX_VECTORS][20];
 	bool			irq_allocated[NIC_VF_MSIX_VECTORS];
+	cpumask_var_t		affinity_mask[NIC_VF_MSIX_VECTORS];
 
 	/* VF <-> PF mailbox communication */
 	bool			pf_acked;
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index c6f146c..90ce93e 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -899,6 +899,31 @@ static void nicvf_disable_msix(struct nicvf *nic)
 	}
 }
 
+static void nicvf_set_irq_affinity(struct nicvf *nic)
+{
+	int vec, cpu;
+	int irqnum;
+
+	for (vec = 0; vec < nic->num_vec; vec++) {
+		if (!nic->irq_allocated[vec])
+			continue;
+
+		if (!zalloc_cpumask_var(&nic->affinity_mask[vec], GFP_KERNEL))
+			return;
+		 /* CQ interrupts */
+		if (vec < NICVF_INTR_ID_SQ)
+			/* Leave CPU0 for RBDR and other interrupts */
+			cpu = nicvf_netdev_qidx(nic, vec) + 1;
+		else
+			cpu = 0;
+
+		cpumask_set_cpu(cpumask_local_spread(cpu, nic->node),
+				nic->affinity_mask[vec]);
+		irqnum = nic->msix_entries[vec].vector;
+		irq_set_affinity_hint(irqnum, nic->affinity_mask[vec]);
+	}
+}
+
 static int nicvf_register_interrupts(struct nicvf *nic)
 {
 	int irq, ret = 0;
@@ -944,8 +969,13 @@ static int nicvf_register_interrupts(struct nicvf *nic)
 	ret = request_irq(nic->msix_entries[irq].vector,
 			  nicvf_qs_err_intr_handler,
 			  0, nic->irq_name[irq], nic);
-	if (!ret)
-		nic->irq_allocated[irq] = true;
+	if (ret)
+		goto err;
+
+	nic->irq_allocated[irq] = true;
+
+	/* Set IRQ affinities */
+	nicvf_set_irq_affinity(nic);
 
 err:
 	if (ret)
@@ -963,6 +993,9 @@ static void nicvf_unregister_interrupts(struct nicvf *nic)
 		if (!nic->irq_allocated[irq])
 			continue;
 
+		irq_set_affinity_hint(nic->msix_entries[irq].vector, NULL);
+		free_cpumask_var(nic->affinity_mask[irq]);
+
 		if (irq < NICVF_INTR_ID_SQ)
 			free_irq(nic->msix_entries[irq].vector, nic->napi[irq]);
 		else
-- 
1.7.1



From sunil.kovvuri at gmail.com  Thu Feb 11 08:20:24 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Thu, 11 Feb 2016 21:50:24 +0530
Subject: [PATCH v2 4/6] net: thunderx: bgx: Use standard firmware node
 infrastructure.
In-Reply-To: <1455207626-35488-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1455207626-35488-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <1455207626-35488-5-git-send-email-sunil.kovvuri@gmail.com>

From: David Daney <david.daney at cavium.com>

In the case of OF device tree, the firmware information is attached to
the BGX device structure in the standard manner, so use the firmware
iterators and accessors where possible.

Signed-off-by: David Daney <david.daney at cavium.com>
Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c |   27 +++++++++++----------
 1 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 9df26c2..111835b 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -968,26 +968,27 @@ static int bgx_init_acpi_phy(struct bgx *bgx)
 
 static int bgx_init_of_phy(struct bgx *bgx)
 {
-	struct device_node *np;
-	struct device_node *np_child;
+	struct fwnode_handle *fwn;
 	u8 lmac = 0;
-	char bgx_sel[5];
 	const char *mac;
 
-	/* Get BGX node from DT */
-	snprintf(bgx_sel, 5, "bgx%d", bgx->bgx_id);
-	np = of_find_node_by_name(NULL, bgx_sel);
-	if (!np)
-		return -ENODEV;
+	device_for_each_child_node(&bgx->pdev->dev, fwn) {
+		struct device_node *phy_np;
+		struct device_node *node = to_of_node(fwn);
+
+		/* If it is not an OF node we cannot handle it yet, so
+		 * exit the loop.
+		 */
+		if (!node)
+			break;
 
-	for_each_child_of_node(np, np_child) {
-		struct device_node *phy_np = of_parse_phandle(np_child,
-							      "phy-handle", 0);
+		phy_np = of_parse_phandle(node, "phy-handle", 0);
 		if (!phy_np)
 			continue;
+
 		bgx->lmac[lmac].phydev = of_phy_find_device(phy_np);
 
-		mac = of_get_mac_address(np_child);
+		mac = of_get_mac_address(node);
 		if (mac)
 			ether_addr_copy(bgx->lmac[lmac].mac, mac);
 
@@ -995,7 +996,7 @@ static int bgx_init_of_phy(struct bgx *bgx)
 		bgx->lmac[lmac].lmacid = lmac;
 		lmac++;
 		if (lmac == MAX_LMAC_PER_BGX) {
-			of_node_put(np_child);
+			of_node_put(node);
 			break;
 		}
 	}
-- 
1.7.1



From sunil.kovvuri at gmail.com  Thu Feb 11 08:20:26 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Thu, 11 Feb 2016 21:50:26 +0530
Subject: [PATCH v2 6/6] net: thunderx: Alloc higher order pages when pagesize
 is small
In-Reply-To: <1455207626-35488-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1455207626-35488-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <1455207626-35488-7-git-send-email-sunil.kovvuri@gmail.com>

From: Sunil Goutham <sgoutham at cavium.com>

Allocate higher order pages when pagesize is small, this will
reduce number of calls to page allocator and wastage of memory.

Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/nicvf_queues.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index 50ab6f4..5adb208 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -78,7 +78,7 @@ static void nicvf_free_q_desc_mem(struct nicvf *nic, struct q_desc_mem *dmem)
 static inline int nicvf_alloc_rcv_buffer(struct nicvf *nic, gfp_t gfp,
 					 u32 buf_len, u64 **rbuf)
 {
-	int order = get_order(buf_len);
+	int order = (PAGE_SIZE <= 4096) ?  PAGE_ALLOC_COSTLY_ORDER : 0;
 
 	/* Check if request can be accomodated in previous allocated page */
 	if (nic->rb_page) {
-- 
1.7.1



From sunil.kovvuri at gmail.com  Thu Feb 11 08:20:25 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Thu, 11 Feb 2016 21:50:25 +0530
Subject: [PATCH v2 5/6] net: thunderx: bgx: Add log message when setting mac
 address
In-Reply-To: <1455207626-35488-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1455207626-35488-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <1455207626-35488-6-git-send-email-sunil.kovvuri@gmail.com>

From: Robert Richter <rrichter at cavium.com>

Signed-off-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 111835b..f8abdff 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -886,7 +886,8 @@ static void bgx_get_qlm_mode(struct bgx *bgx)
 
 #ifdef CONFIG_ACPI
 
-static int acpi_get_mac_address(struct acpi_device *adev, u8 *dst)
+static int acpi_get_mac_address(struct device *dev, struct acpi_device *adev,
+				u8 *dst)
 {
 	u8 mac[ETH_ALEN];
 	int ret;
@@ -897,10 +898,13 @@ static int acpi_get_mac_address(struct acpi_device *adev, u8 *dst)
 		goto out;
 
 	if (!is_valid_ether_addr(mac)) {
+		dev_err(dev, "MAC address invalid: %pM\n", mac);
 		ret = -EINVAL;
 		goto out;
 	}
 
+	dev_info(dev, "MAC address set to: %pM\n", mac);
+
 	memcpy(dst, mac, ETH_ALEN);
 out:
 	return ret;
@@ -911,14 +915,15 @@ static acpi_status bgx_acpi_register_phy(acpi_handle handle,
 					 u32 lvl, void *context, void **rv)
 {
 	struct bgx *bgx = context;
+	struct device *dev = &bgx->pdev->dev;
 	struct acpi_device *adev;
 
 	if (acpi_bus_get_device(handle, &adev))
 		goto out;
 
-	acpi_get_mac_address(adev, bgx->lmac[bgx->lmac_count].mac);
+	acpi_get_mac_address(dev, adev, bgx->lmac[bgx->lmac_count].mac);
 
-	SET_NETDEV_DEV(&bgx->lmac[bgx->lmac_count].netdev, &bgx->pdev->dev);
+	SET_NETDEV_DEV(&bgx->lmac[bgx->lmac_count].netdev, dev);
 
 	bgx->lmac[bgx->lmac_count].lmacid = bgx->lmac_count;
 out:
-- 
1.7.1



From ard.biesheuvel at linaro.org  Thu Feb 11 08:18:12 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 11 Feb 2016 17:18:12 +0100
Subject: [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks
In-Reply-To: <20160211161621.GM4134@codeblueprint.co.uk>
References: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160211161621.GM4134@codeblueprint.co.uk>
Message-ID: <CAKv+Gu-kZrcLYhF7i0u8F2TOMqEVKp==jNoBc+Rfk61cwSkDhQ@mail.gmail.com>

On 11 February 2016 at 17:16, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> On Thu, 04 Feb, at 04:50:23PM, Ard Biesheuvel wrote:
>> I merged two EFI/ARM related series, whose v1's I sent out last week:
>>
>> Changes since v1:
>> - added various tags from various people
>> - new patch #3 to undefine __init
>>
>> @Matt: are you happy with all of this going through the arm64 tree? I don't
>> think it clashes with anything else we've got queued up for v4.6 in tip/efi/core
>
> How come this is going through the arm64 tree? Are there other patch
> series that this depends on or that depend on it?
>
> If it makes the most sense to take it through that tree, then I'm fine
> with it but I'd like to hear a rationale.

I simply thought it would be most convenient, since it touches
ARM-specific files only. But if you feel it should go via the EFI tree
instead, that is also fine by me.

Thanks,
Ard.


From martin at sperl.org  Thu Feb 11 08:19:45 2016
From: martin at sperl.org (Martin Sperl)
Date: Thu, 11 Feb 2016 17:19:45 +0100
Subject: [PATCH 4/4] spi: bcm2835aux: fix CPOL/CPHA setting
In-Reply-To: <10547867.CcbLVQlgyH@chaos-desktop>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <87a8n94e3x.fsf@eliezer.anholt.net>
 <16A848EA-6E08-48C4-B3DD-DF27333B7458@sperl.org>
 <10547867.CcbLVQlgyH@chaos-desktop>
Message-ID: <50D0ECA7-8116-4248-AC85-6E1C8002A185@sperl.org>


> On 11.02.2016, at 17:05, Stephan Olbrich <stephanolbrich at gmx.de> wrote:
> 
> Martin,
> 
> Am Thursday 11 February 2016, 16:25:43 schrieb Martin Sperl:
>>> On 10.02.2016, at 01:13, Eric Anholt <eric at anholt.net> wrote:
>>> 
>>> stephanolbrich at gmx.de writes:
>>>> From: Stephan Olbrich <stephanolbrich at gmx.de>
>>>> 
>>>> The auxiliary spi supports only CPHA=0 modes as the first bit is
>>>> always output to the pin before the first clock cycle. In CPHA=1
>>>> modes the first clock edge outputs the second bit hence the slave
>>>> can never read the first bit.
>>>> 
>>>> Also the CPHA registers switch between clocking data in/out on
>>>> rising/falling edge hence depend on the CPOL setting.
>>>> 
>>>> Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
>>>> ---
>>>> drivers/spi/spi-bcm2835aux.c | 10 +++++-----
>>>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>>> 
>>>> diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
>>>> index b90aa34..169f521 100644
>>>> --- a/drivers/spi/spi-bcm2835aux.c
>>>> +++ b/drivers/spi/spi-bcm2835aux.c
>>>> @@ -386,12 +386,12 @@ static int bcm2835aux_spi_prepare_message(struct
>>>> spi_master *master,>> 
>>>> 	bs->cntl[1] = BCM2835_AUX_SPI_CNTL1_MSBF_IN;
>>>> 	
>>>> 	/* handle all the modes */
>>>> 
>>>> -	if (spi->mode & SPI_CPOL)
>>>> +	if (spi->mode & SPI_CPOL) {
>>>> 
>>>> 		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPOL;
>>>> 
>>>> -	if (spi->mode & SPI_CPHA)
>>>> -		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT |
>>>> -			       BCM2835_AUX_SPI_CNTL0_CPHA_IN;
>>>> -
>>>> +		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT;
>>>> +	} else {
>>>> +		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_IN;
>>>> +	}
>>>> 
>>>> 	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1]);
>>>> 	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL0, bs->cntl[0]);
>>> 
>>> (Note for other readers: A better name for CNTL0_CPHA_* would be
>>> CNTL0_*_RISING).
>>> 
>>> I think you're right about not actually supporting CPHA.  I don't see
>>> wany way to keep bit 1 out lasting through the first full clock cycle.
>>> I think Stefan's right that we should drop CPHA from MODE_BITS
>>> (actually, MODE_BITS would be nicer if we just merged it into its one
>>> user, I think).
>>> 
>>> However, this hunk appears to be correct and would fix the timing of our
>>> data going out in the CPOL=0 case and of sampling IN data for CPOL=1.
>> 
>> Are you sure that CPHA is not working?
>> 
>> I have used the following to test all combinations:
>> for C in "" "-C"; do
>>  for O in "" "-O"; do
>>   for H in "" "-H"; do
>>    spidev_test -vD /dev/*.1 $H $O -p "\x00\x82\x00" -s 1000000;
>>   done
>>  done
>> done
>> 
>> I have tested with the 4.5-rc3 kernel without any of your patches.
>> 
>> And looked at the logic-analyzer: I see distinct waveform pattern
>> for clk and data for all events!
> 
> The problem I see, is not that there is no waveform but that it has the wrong 
> timing.
> I'll make an example:
> Data is 0xAA,0xFF, CPOL=1, CPHA=1
> What happens is this:
> CS goes active and MOSI goes high (first bit in 1)
> After a short time, SCLK goes from low to high and MOSI goes to low (second 
> bit is 0)
> Then SCLK goes low (sampling data)
> Then SCLK goes high and MOSI goes high (third bit is 1) 
> and so on.
> At the end with the last rising edge of SCLK MOSI goes to low and stays there 
> while SCLK goes to low and then CS to inactive.
> 
> So the slave has no chance to get the first bit but gets an additional 0 at the 
> end.
> It may not be easy visible with 0x00,0x82,0x00 as data, so could you repeat 
> your test with 0xAA,0xFF if you see the same as I do or not?

I did retest also with 0x81,0x00,0x81 and saw my expected behavior - but maybe
me understanding of those modes is wrong.

I will send you the images for the pattern I have generated with 
0x81, 0x00, 0x81 as a personal email.

Martin

From arnd at arndb.de  Thu Feb 11 08:20:27 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 17:20:27 +0100
Subject: [PATCH v3 0/6] arm: Add Artpec-6 SoC
In-Reply-To: <cover.1455205057.git.larper@axis.com>
References: <cover.1455205057.git.larper@axis.com>
Message-ID: <2697188.EpDoHh0fx4@wuerfel>

On Thursday 11 February 2016 17:06:15 Lars Persson wrote:
> Basic support for the Axis Artpec-6 ARM SoC. Timers, interrupts, UARTs and
> ethernet are wired up.
> 
> Changes since v2:
> - Create a syscon binding for the system controller.
> - Clock patches split out to new patch series "clk: Add Artpec-6 SoC support".

Looks all good to me now, impressive for v3 on a new platform port!

We'll apply it in the next few days, unless further review comments come in.

If you end up resending, please add my

Reviewed-by: Arnd Bergmann <arnd at arndb.de>

	Arnd


From bharat.kumar.gogada at xilinx.com  Thu Feb 11 08:28:06 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Thu, 11 Feb 2016 21:58:06 +0530
Subject: [PATCH V4 0/5] PCIe Xilinx generic driver for Microblaze and 
Message-ID: <1455208091-15556-1-git-send-email-bharatku@xilinx.com>

This patch series does modifications to pcie-xilinx.c, to support common
driver on both Zynq and Microblaze architectures.
Microblaze pci-common.c has been modified to support generic driver.

Bharat Kumar Gogada (5):
  PCI: xilinx: Removing xilinx_pcie_parse_and_add_res function
  PCI: xilinx: Removing struct hw_pci structure.
  PCI: xilinx: Modifying AXI PCIe Host Bridge driver to work on both
     Zynq and Microblaze
  PCI: xilinx: Updating Zynq PCI binding documentation with 
    Microblaze node.
  Microblaze: Modifying microblaze PCI subsytem to support  generic
    Xilinx  AXI PCIe Host Bridge IP driver

 .../devicetree/bindings/pci/xilinx-pcie.txt        |  32 +++-
 arch/microblaze/Kconfig                            |   3 +
 arch/microblaze/pci/pci-common.c                   |  56 ++----
 drivers/pci/host/Kconfig                           |   2 +-
 drivers/pci/host/pcie-xilinx.c                     | 191 +++------------------
 5 files changed, 66 insertions(+), 218 deletions(-)

-- 
2.1.1



From bharat.kumar.gogada at xilinx.com  Thu Feb 11 08:28:07 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Thu, 11 Feb 2016 21:58:07 +0530
Subject: [PATCH V4 1/5] PCI: xilinx: Removing xilinx_pcie_parse_and_add_res
 function
In-Reply-To: <1455208091-15556-1-git-send-email-bharatku@xilinx.com>
References: <1455208091-15556-1-git-send-email-bharatku@xilinx.com>
Message-ID: <1455208091-15556-2-git-send-email-bharatku@xilinx.com>

Removing xilinx_pcie_parse_and_add_res function replacing with
of_pci_get_host_bridge_resources API.

Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>

Reviewed-by: Arnd Bergmann <arnd at arndb.de>
---
Changes:
Removing xilinx_pcie_parse_and_add_res function and replacing it
with of_pci_get_host_bridge_resources kernel API which does the same.
---
 drivers/pci/host/pcie-xilinx.c | 107 ++---------------------------------------
 1 file changed, 5 insertions(+), 102 deletions(-)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 3c7a0d5..627878d 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -94,9 +94,6 @@
 /* Number of MSI IRQs */
 #define XILINX_NUM_MSI_IRQS		128
 
-/* Number of Memory Resources */
-#define XILINX_MAX_NUM_RESOURCES	3
-
 /**
  * struct xilinx_pcie_port - PCIe port information
  * @reg_base: IO Mapped Register Base
@@ -105,7 +102,6 @@
  * @root_busno: Root Bus number
  * @dev: Device pointer
  * @irq_domain: IRQ domain pointer
- * @bus_range: Bus range
  * @resources: Bus Resources
  */
 struct xilinx_pcie_port {
@@ -659,97 +655,6 @@ static struct pci_bus *xilinx_pcie_scan_bus(int nr, struct pci_sys_data *sys)
 }
 
 /**
- * xilinx_pcie_parse_and_add_res - Add resources by parsing ranges
- * @port: PCIe port information
- *
- * Return: '0' on success and error value on failure
- */
-static int xilinx_pcie_parse_and_add_res(struct xilinx_pcie_port *port)
-{
-	struct device *dev = port->dev;
-	struct device_node *node = dev->of_node;
-	struct resource *mem;
-	resource_size_t offset;
-	struct of_pci_range_parser parser;
-	struct of_pci_range range;
-	struct resource_entry *win;
-	int err = 0, mem_resno = 0;
-
-	/* Get the ranges */
-	if (of_pci_range_parser_init(&parser, node)) {
-		dev_err(dev, "missing \"ranges\" property\n");
-		return -EINVAL;
-	}
-
-	/* Parse the ranges and add the resources found to the list */
-	for_each_of_pci_range(&parser, &range) {
-
-		if (mem_resno >= XILINX_MAX_NUM_RESOURCES) {
-			dev_err(dev, "Maximum memory resources exceeded\n");
-			return -EINVAL;
-		}
-
-		mem = devm_kmalloc(dev, sizeof(*mem), GFP_KERNEL);
-		if (!mem) {
-			err = -ENOMEM;
-			goto free_resources;
-		}
-
-		of_pci_range_to_resource(&range, node, mem);
-
-		switch (mem->flags & IORESOURCE_TYPE_BITS) {
-		case IORESOURCE_MEM:
-			offset = range.cpu_addr - range.pci_addr;
-			mem_resno++;
-			break;
-		default:
-			err = -EINVAL;
-			break;
-		}
-
-		if (err < 0) {
-			dev_warn(dev, "Invalid resource found %pR\n", mem);
-			continue;
-		}
-
-		err = request_resource(&iomem_resource, mem);
-		if (err)
-			goto free_resources;
-
-		pci_add_resource_offset(&port->resources, mem, offset);
-	}
-
-	/* Get the bus range */
-	if (of_pci_parse_bus_range(node, &port->bus_range)) {
-		u32 val = pcie_read(port, XILINX_PCIE_REG_BIR);
-		u8 last;
-
-		last = (val & XILINX_PCIE_BIR_ECAM_SZ_MASK) >>
-			XILINX_PCIE_BIR_ECAM_SZ_SHIFT;
-
-		port->bus_range = (struct resource) {
-			.name	= node->name,
-			.start	= 0,
-			.end	= last,
-			.flags	= IORESOURCE_BUS,
-		};
-	}
-
-	/* Register bus resource */
-	pci_add_resource(&port->resources, &port->bus_range);
-
-	return 0;
-
-free_resources:
-	release_child_resources(&iomem_resource);
-	resource_list_for_each_entry(win, &port->resources)
-		devm_kfree(dev, win->res);
-	pci_free_resource_list(&port->resources);
-
-	return err;
-}
-
-/**
  * xilinx_pcie_parse_dt - Parse Device tree
  * @port: PCIe port information
  *
@@ -802,6 +707,8 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
 	struct hw_pci hw;
 	struct device *dev = &pdev->dev;
 	int err;
+	resource_size_t iobase = 0;
+	LIST_HEAD(res);
 
 	if (!dev->of_node)
 		return -ENODEV;
@@ -826,14 +733,10 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
 		return err;
 	}
 
-	/*
-	 * Parse PCI ranges, configuration bus range and
-	 * request their resources
-	 */
-	INIT_LIST_HEAD(&port->resources);
-	err = xilinx_pcie_parse_and_add_res(port);
+	err = of_pci_get_host_bridge_resources(dev->of_node, 0, 0xff, &res,
+					       &iobase);
 	if (err) {
-		dev_err(dev, "Failed adding resources\n");
+		dev_err(dev, "Getting bridge resources failed\n");
 		return err;
 	}
 
-- 
2.1.1



From bharat.kumar.gogada at xilinx.com  Thu Feb 11 08:28:10 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Thu, 11 Feb 2016 21:58:10 +0530
Subject: [PATCH V4 4/5] PCI: xilinx: Updating Zynq PCI binding documentation
 with Microblaze node.
In-Reply-To: <1455208091-15556-1-git-send-email-bharatku@xilinx.com>
References: <1455208091-15556-1-git-send-email-bharatku@xilinx.com>
Message-ID: <1455208091-15556-5-git-send-email-bharatku@xilinx.com>

Updated Zynq PCI binding documentation with Microblaze node.

Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>

Acked-by: Rob Herring <robh at kernel.org>
---
Changes:
Adding Microblaze device tree node Documnetation.
---
 .../devicetree/bindings/pci/xilinx-pcie.txt        | 32 ++++++++++++++++++++--
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/xilinx-pcie.txt b/Documentation/devicetree/bindings/pci/xilinx-pcie.txt
index 02f979a..ad7c7bf 100644
--- a/Documentation/devicetree/bindings/pci/xilinx-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/xilinx-pcie.txt
@@ -17,7 +17,7 @@ Required properties:
 	Please refer to the standard PCI bus binding document for a more
 	detailed explanation
 
-Optional properties:
+Optional properties for Zynq/Microblaze:
 - bus-range: PCI bus numbers covered
 
 Interrupt controller child node
@@ -38,13 +38,13 @@ the four INTx interrupts in ISR and route them to this domain.
 
 Example:
 ++++++++
-
+Zynq:
 	pci_express: axi-pcie at 50000000 {
 		#address-cells = <3>;
 		#size-cells = <2>;
 		#interrupt-cells = <1>;
 		compatible = "xlnx,axi-pcie-host-1.00.a";
-		reg = < 0x50000000 0x10000000 >;
+		reg = < 0x50000000 0x1000000 >;
 		device_type = "pci";
 		interrupts = < 0 52 4 >;
 		interrupt-map-mask = <0 0 0 7>;
@@ -60,3 +60,29 @@ Example:
 			#interrupt-cells = <1>;
 		};
 	};
+
+
+Microblaze:
+	pci_express: axi-pcie at 10000000 {
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		compatible = "xlnx,axi-pcie-host-1.00.a";
+		reg = <0x10000000 0x4000000>;
+		device_type = "pci";
+		interrupt-parent = <&microbalze_0_intc>;
+		interrupts = <1 2>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie_intc 1>,
+				<0 0 0 2 &pcie_intc 2>,
+				<0 0 0 3 &pcie_intc 3>,
+				<0 0 0 4 &pcie_intc 4>;
+		ranges = <0x02000000 0x00000000 0x80000000 0x80000000 0x00000000 0x10000000>;
+
+		pcie_intc: interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
+			#interrupt-cells = <1>;
+		};
+
+	};
-- 
2.1.1



From bharat.kumar.gogada at xilinx.com  Thu Feb 11 08:28:09 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Thu, 11 Feb 2016 21:58:09 +0530
Subject: [PATCH V4 3/5] PCI: xilinx: Modifying AXI PCIe Host Bridge driver to
 work on both Zynq and Microblaze
In-Reply-To: <1455208091-15556-1-git-send-email-bharatku@xilinx.com>
References: <1455208091-15556-1-git-send-email-bharatku@xilinx.com>
Message-ID: <1455208091-15556-4-git-send-email-bharatku@xilinx.com>

Modifying Xilinx AXI PCIe Host Bridge Soft IP driver to work on both
Zynq and Microblaze Architectures.
With these modifications drivers/pci/host/pcie-xilinx.c, will
work on both Zynq and Microblaze Architectures.

Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>

Reviewed-by: Arnd Bergmann <arnd at arndb.de>
---
Changes:
Added #ifdef to pci_fixup_irqs which is ARM specific API.
---
 drivers/pci/host/pcie-xilinx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 13fec35..8ad50fe 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -704,7 +704,9 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
 #endif
 	pci_scan_child_bus(bus);
 	pci_assign_unassigned_bus_resources(bus);
+#ifndef CONFIG_MICROBLAZE
 	pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
+#endif
 	pci_bus_add_devices(bus);
 	platform_set_drvdata(pdev, port);
 
-- 
2.1.1



From bharat.kumar.gogada at xilinx.com  Thu Feb 11 08:28:08 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Thu, 11 Feb 2016 21:58:08 +0530
Subject: [PATCH V4 2/5] PCI: xilinx: Removing struct hw_pci structure.
In-Reply-To: <1455208091-15556-1-git-send-email-bharatku@xilinx.com>
References: <1455208091-15556-1-git-send-email-bharatku@xilinx.com>
Message-ID: <1455208091-15556-3-git-send-email-bharatku@xilinx.com>

Removing struct hw_pci and adding generic PCI core API's.

Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>

Reviewed-by: Arnd Bergmann <arnd at arndb.de>
---
Changes:
Removing architecure dependecy structure struct hw_pci which is ARM 32-bit
specific structure, and adding generic PCI core API's to register to
PCI subsytem.
Removing funtions which are not being used with generic API's.
---
 drivers/pci/host/pcie-xilinx.c | 82 +++++++++---------------------------------
 1 file changed, 16 insertions(+), 66 deletions(-)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 627878d..13fec35 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -111,17 +111,11 @@ struct xilinx_pcie_port {
 	u8 root_busno;
 	struct device *dev;
 	struct irq_domain *irq_domain;
-	struct resource bus_range;
 	struct list_head resources;
 };
 
 static DECLARE_BITMAP(msi_irq_in_use, XILINX_NUM_MSI_IRQS);
 
-static inline struct xilinx_pcie_port *sys_to_pcie(struct pci_sys_data *sys)
-{
-	return sys->private_data;
-}
-
 static inline u32 pcie_read(struct xilinx_pcie_port *port, u32 reg)
 {
 	return readl(port->reg_base + reg);
@@ -163,7 +157,7 @@ static void xilinx_pcie_clear_err_interrupts(struct xilinx_pcie_port *port)
  */
 static bool xilinx_pcie_valid_device(struct pci_bus *bus, unsigned int devfn)
 {
-	struct xilinx_pcie_port *port = sys_to_pcie(bus->sysdata);
+	struct xilinx_pcie_port *port = bus->sysdata;
 
 	/* Check if link is up when trying to access downstream ports */
 	if (bus->number != port->root_busno)
@@ -196,7 +190,7 @@ static bool xilinx_pcie_valid_device(struct pci_bus *bus, unsigned int devfn)
 static void __iomem *xilinx_pcie_map_bus(struct pci_bus *bus,
 					 unsigned int devfn, int where)
 {
-	struct xilinx_pcie_port *port = sys_to_pcie(bus->sysdata);
+	struct xilinx_pcie_port *port = bus->sysdata;
 	int relbus;
 
 	if (!xilinx_pcie_valid_device(bus, devfn))
@@ -228,7 +222,7 @@ static void xilinx_pcie_destroy_msi(unsigned int irq)
 
 	if (!test_bit(irq, msi_irq_in_use)) {
 		msi = irq_get_msi_desc(irq);
-		port = sys_to_pcie(msi_desc_to_pci_sysdata(msi));
+		port = msi_desc_to_pci_sysdata(msi);
 		dev_err(port->dev, "Trying to free unused MSI#%d\n", irq);
 	} else {
 		clear_bit(irq, msi_irq_in_use);
@@ -277,7 +271,7 @@ static int xilinx_pcie_msi_setup_irq(struct msi_controller *chip,
 				     struct pci_dev *pdev,
 				     struct msi_desc *desc)
 {
-	struct xilinx_pcie_port *port = sys_to_pcie(pdev->bus->sysdata);
+	struct xilinx_pcie_port *port = pdev->bus->sysdata;
 	unsigned int irq;
 	int hwirq;
 	struct msi_msg msg;
@@ -614,47 +608,6 @@ static void xilinx_pcie_init_port(struct xilinx_pcie_port *port)
 }
 
 /**
- * xilinx_pcie_setup - Setup memory resources
- * @nr: Bus number
- * @sys: Per controller structure
- *
- * Return: '1' on success and error value on failure
- */
-static int xilinx_pcie_setup(int nr, struct pci_sys_data *sys)
-{
-	struct xilinx_pcie_port *port = sys_to_pcie(sys);
-
-	list_splice_init(&port->resources, &sys->resources);
-
-	return 1;
-}
-
-/**
- * xilinx_pcie_scan_bus - Scan PCIe bus for devices
- * @nr: Bus number
- * @sys: Per controller structure
- *
- * Return: Valid Bus pointer on success and NULL on failure
- */
-static struct pci_bus *xilinx_pcie_scan_bus(int nr, struct pci_sys_data *sys)
-{
-	struct xilinx_pcie_port *port = sys_to_pcie(sys);
-	struct pci_bus *bus;
-
-	port->root_busno = sys->busnr;
-
-	if (IS_ENABLED(CONFIG_PCI_MSI))
-		bus = pci_scan_root_bus_msi(port->dev, sys->busnr,
-					    &xilinx_pcie_ops, sys,
-					    &sys->resources,
-					    &xilinx_pcie_msi_chip);
-	else
-		bus = pci_scan_root_bus(port->dev, sys->busnr,
-					&xilinx_pcie_ops, sys, &sys->resources);
-	return bus;
-}
-
-/**
  * xilinx_pcie_parse_dt - Parse Device tree
  * @port: PCIe port information
  *
@@ -704,8 +657,9 @@ static int xilinx_pcie_parse_dt(struct xilinx_pcie_port *port)
 static int xilinx_pcie_probe(struct platform_device *pdev)
 {
 	struct xilinx_pcie_port *port;
-	struct hw_pci hw;
 	struct device *dev = &pdev->dev;
+	struct pci_bus *bus;
+
 	int err;
 	resource_size_t iobase = 0;
 	LIST_HEAD(res);
@@ -739,24 +693,20 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
 		dev_err(dev, "Getting bridge resources failed\n");
 		return err;
 	}
-
-	platform_set_drvdata(pdev, port);
-
-	/* Register the device */
-	memset(&hw, 0, sizeof(hw));
-	hw = (struct hw_pci) {
-		.nr_controllers	= 1,
-		.private_data	= (void **)&port,
-		.setup		= xilinx_pcie_setup,
-		.map_irq	= of_irq_parse_and_map_pci,
-		.scan		= xilinx_pcie_scan_bus,
-		.ops		= &xilinx_pcie_ops,
-	};
+	bus = pci_create_root_bus(&pdev->dev, 0,
+				  &xilinx_pcie_ops, port, &res);
+	if (!bus)
+		return -ENOMEM;
 
 #ifdef CONFIG_PCI_MSI
 	xilinx_pcie_msi_chip.dev = port->dev;
+	bus->msi = &xilinx_pcie_msi_chip;
 #endif
-	pci_common_init_dev(dev, &hw);
+	pci_scan_child_bus(bus);
+	pci_assign_unassigned_bus_resources(bus);
+	pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
+	pci_bus_add_devices(bus);
+	platform_set_drvdata(pdev, port);
 
 	return 0;
 }
-- 
2.1.1



From bharat.kumar.gogada at xilinx.com  Thu Feb 11 08:28:11 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Thu, 11 Feb 2016 21:58:11 +0530
Subject: [PATCH V4 5/5] Microblaze: Modifying microblaze PCI subsytem to
 support generic Xilinx AXI PCIe Host Bridge IP driver
In-Reply-To: <1455208091-15556-1-git-send-email-bharatku@xilinx.com>
References: <1455208091-15556-1-git-send-email-bharatku@xilinx.com>
Message-ID: <1455208091-15556-6-git-send-email-bharatku@xilinx.com>

This patch does required modifications to microblaze PCI subsystem, to
work with generic driver (drivers/pci/host/pcie-xilinx.c) on Microblaze
and Zynq.

Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
---
Changes:
Removed pcibios_get_phb_of_node in pci-common.c, using generic version
instead.
Modified pcibios_fixup_bus in pci-common.c, as per generic architecuture.
Modified pcibios_align_resource in pci-common.c, as per generic
architecuture, removed temporary variable.
Removed pci_domain_nr in pci-common.c, instead using generic code.
Added pcibios_add_device in pci-common.c, as per generic architecuture.
Adding Kernel configuration in arch/microblaze as required for generic PCI
domains.
Added kernel configuration for driver to support Microblaze.
---
 arch/microblaze/Kconfig          |  3 +++
 arch/microblaze/pci/pci-common.c | 56 +++++++---------------------------------
 drivers/pci/host/Kconfig         |  2 +-
 3 files changed, 14 insertions(+), 47 deletions(-)

diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 0bce820..c3702b9 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -271,6 +271,9 @@ config PCI
 config PCI_DOMAINS
 	def_bool PCI
 
+config PCI_DOMAINS_GENERIC
+	def_bool PCI_DOMAINS
+
 config PCI_SYSCALL
 	def_bool PCI
 
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index ae838ed..35654be 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -123,17 +123,6 @@ unsigned long pci_address_to_pio(phys_addr_t address)
 }
 EXPORT_SYMBOL_GPL(pci_address_to_pio);
 
-/*
- * Return the domain number for this bus.
- */
-int pci_domain_nr(struct pci_bus *bus)
-{
-	struct pci_controller *hose = pci_bus_to_host(bus);
-
-	return hose->global_number;
-}
-EXPORT_SYMBOL(pci_domain_nr);
-
 /* This routine is meant to be used early during boot, when the
  * PCI bus numbers have not yet been assigned, and you need to
  * issue PCI config cycles to an OF device.
@@ -863,26 +852,10 @@ void pcibios_setup_bus_devices(struct pci_bus *bus)
 
 void pcibios_fixup_bus(struct pci_bus *bus)
 {
-	/* When called from the generic PCI probe, read PCI<->PCI bridge
-	 * bases. This is -not- called when generating the PCI tree from
-	 * the OF device-tree.
-	 */
-	if (bus->self != NULL)
-		pci_read_bridge_bases(bus);
-
-	/* Now fixup the bus bus */
-	pcibios_setup_bus_self(bus);
-
-	/* Now fixup devices on that bus */
-	pcibios_setup_bus_devices(bus);
+	/* nothing to do */
 }
 EXPORT_SYMBOL(pcibios_fixup_bus);
 
-static int skip_isa_ioresource_align(struct pci_dev *dev)
-{
-	return 0;
-}
-
 /*
  * We need to avoid collisions with `mirrored' VGA ports
  * and other strange ISA hardware, so we always want the
@@ -899,20 +872,18 @@ static int skip_isa_ioresource_align(struct pci_dev *dev)
 resource_size_t pcibios_align_resource(void *data, const struct resource *res,
 				resource_size_t size, resource_size_t align)
 {
-	struct pci_dev *dev = data;
-	resource_size_t start = res->start;
-
-	if (res->flags & IORESOURCE_IO) {
-		if (skip_isa_ioresource_align(dev))
-			return start;
-		if (start & 0x300)
-			start = (start + 0x3ff) & ~0x3ff;
-	}
-
-	return start;
+	return res->start;
 }
 EXPORT_SYMBOL(pcibios_align_resource);
 
+int pcibios_add_device(struct pci_dev *dev)
+{
+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
+
+	return 0;
+}
+EXPORT_SYMBOL(pcibios_add_device);
+
 /*
  * Reparent resource children of pr that conflict with res
  * under res, and make res replace those children.
@@ -1333,13 +1304,6 @@ static void pcibios_setup_phb_resources(struct pci_controller *hose,
 		 (unsigned long)hose->io_base_virt - _IO_BASE);
 }
 
-struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)
-{
-	struct pci_controller *hose = bus->sysdata;
-
-	return of_node_get(hose->dn);
-}
-
 static void pcibios_scan_phb(struct pci_controller *hose)
 {
 	LIST_HEAD(resources);
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..7c56c2e 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -79,7 +79,7 @@ config PCI_KEYSTONE
 
 config PCIE_XILINX
 	bool "Xilinx AXI PCIe host bridge support"
-	depends on ARCH_ZYNQ
+	depends on ARCH_ZYNQ || MICROBLAZE
 	help
 	  Say 'Y' here if you want kernel to support the Xilinx AXI PCIe
 	  Host Bridge driver.
-- 
2.1.1



From matt at codeblueprint.co.uk  Thu Feb 11 08:29:20 2016
From: matt at codeblueprint.co.uk (Matt Fleming)
Date: Thu, 11 Feb 2016 16:29:20 +0000
Subject: [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks
In-Reply-To: <CAKv+Gu-kZrcLYhF7i0u8F2TOMqEVKp==jNoBc+Rfk61cwSkDhQ@mail.gmail.com>
References: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160211161621.GM4134@codeblueprint.co.uk>
 <CAKv+Gu-kZrcLYhF7i0u8F2TOMqEVKp==jNoBc+Rfk61cwSkDhQ@mail.gmail.com>
Message-ID: <20160211162920.GN4134@codeblueprint.co.uk>

On Thu, 11 Feb, at 05:18:12PM, Ard Biesheuvel wrote:
> On 11 February 2016 at 17:16, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> > On Thu, 04 Feb, at 04:50:23PM, Ard Biesheuvel wrote:
> >> I merged two EFI/ARM related series, whose v1's I sent out last week:
> >>
> >> Changes since v1:
> >> - added various tags from various people
> >> - new patch #3 to undefine __init
> >>
> >> @Matt: are you happy with all of this going through the arm64 tree? I don't
> >> think it clashes with anything else we've got queued up for v4.6 in tip/efi/core
> >
> > How come this is going through the arm64 tree? Are there other patch
> > series that this depends on or that depend on it?
> >
> > If it makes the most sense to take it through that tree, then I'm fine
> > with it but I'd like to hear a rationale.
> 
> I simply thought it would be most convenient, since it touches
> ARM-specific files only. But if you feel it should go via the EFI tree
> instead, that is also fine by me.

Since the diff stat is heavily weighted towards drivers/firmware/efi I
think it should go via the EFI tree. So I'll pick this up (the changes
look fine) unless Will or Catalin complain otherwise.

I'm also keen to allay any concerns that the EFI tree is somehow
x86-specific.


From paul.gortmaker at windriver.com  Thu Feb 11 08:28:52 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Thu, 11 Feb 2016 11:28:52 -0500
Subject: [PATCH v2 1/6] Revert "drivers/tty/serial: make 8250/8250_mtk.c
 explicitly non-modular"
In-Reply-To: <3873766.I9XIY0R8gT@wuerfel>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
 <1455205297-1021302-2-git-send-email-arnd@arndb.de>
 <20160211160021.GF28452@windriver.com> <3873766.I9XIY0R8gT@wuerfel>
Message-ID: <20160211162852.GJ28452@windriver.com>

[Re: [PATCH v2 1/6] Revert "drivers/tty/serial: make 8250/8250_mtk.c explicitly non-modular"] On 11/02/2016 (Thu 17:06) Arnd Bergmann wrote:

> On Thursday 11 February 2016 11:00:22 Paul Gortmaker wrote:
> > [[PATCH v2 1/6] Revert "drivers/tty/serial: make 8250/8250_mtk.c explicitly non-modular"] On 11/02/2016 (Thu 16:41) Arnd Bergmann wrote:
> > 
> > > This reverts commit d72d391c126e, which tried to remove dead code but
> > > left the driver in a useless state when the main 8250 driver is a
> > 
> > Am I misunderstanding something?  The commit didn't cause the driver to
> > be in a useless state for 8250=m.  But rather isn't that it was a
> > pre-existing condition, independent of the change to 8250_mtk.c to
> > remove the dead code in d72d391c126e?
> > 
> > Since the commit did not touch Kconfig or Makefile, I can't see how it
> > could cause some new useless state that did not already exist, and hence
> > the "Fixes:" tag is invalid as well.
> 
> My wording may have been bad here. What I meant to say is that it
> was broken before the patch, and still broken after the patch.

OK, no problem. I just didn't want Greg/Jiri to think I was sending them
broken commits.   Will need a v3 to get rid of the extra module.h
anyway, so that gives you a chance to reword.

> 
> The Fixes tag was meant to just be a reference to the commit I'm
> reverting.

Yeah, but since the stable people trigger off of that, and since the
revert doesn't really fix anything, that is probably best removed.
The stable trees don't need the revert.

Thanks,
Paul.
--
> 
> 	Arnd


From davem at davemloft.net  Thu Feb 11 08:30:53 2016
From: davem at davemloft.net (David Miller)
Date: Thu, 11 Feb 2016 11:30:53 -0500 (EST)
Subject: [PATCH v2 0/6] net: thunderx: Setting IRQ affinity hints and
 other optimizations
In-Reply-To: <1455207626-35488-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1455207626-35488-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <20160211.113053.1221794797998213409.davem@davemloft.net>

From: sunil.kovvuri at gmail.com
Date: Thu, 11 Feb 2016 21:50:20 +0530

> This patch series contains changes
> - To add support for virtual function's irq affinity hint
> - Replace napi_schedule() with napi_schedule_irqoff()
> - Reduce page allocation overhead by allocating pages
>   of higher order when pagesize is 4KB.
> - Add couple of stats which helps in debugging
> - Some miscellaneous changes to BGX driver.
> 
> Changes from v1:
> - As suggested changed MAC address invalid log message 
>   to dev_err() instead of dev_warn().

Series applied, thanks.


From arnd at arndb.de  Thu Feb 11 08:32:17 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 17:32:17 +0100
Subject: [PATCH v2 1/6] Revert "drivers/tty/serial: make 8250/8250_mtk.c
 explicitly non-modular"
In-Reply-To: <20160211162852.GJ28452@windriver.com>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
 <3873766.I9XIY0R8gT@wuerfel> <20160211162852.GJ28452@windriver.com>
Message-ID: <2425581.FEKcoTMtxH@wuerfel>

On Thursday 11 February 2016 11:28:52 Paul Gortmaker wrote:
> [Re: [PATCH v2 1/6] Revert "drivers/tty/serial: make 8250/8250_mtk.c explicitly non-modular"] On 11/02/2016 (Thu 17:06) Arnd Bergmann wrote:
> 
> > On Thursday 11 February 2016 11:00:22 Paul Gortmaker wrote:
> > > [[PATCH v2 1/6] Revert "drivers/tty/serial: make 8250/8250_mtk.c explicitly non-modular"] On 11/02/2016 (Thu 16:41) Arnd Bergmann wrote:
> > > 
> > > > This reverts commit d72d391c126e, which tried to remove dead code but
> > > > left the driver in a useless state when the main 8250 driver is a
> > > 
> > > Am I misunderstanding something?  The commit didn't cause the driver to
> > > be in a useless state for 8250=m.  But rather isn't that it was a
> > > pre-existing condition, independent of the change to 8250_mtk.c to
> > > remove the dead code in d72d391c126e?
> > > 
> > > Since the commit did not touch Kconfig or Makefile, I can't see how it
> > > could cause some new useless state that did not already exist, and hence
> > > the "Fixes:" tag is invalid as well.
> > 
> > My wording may have been bad here. What I meant to say is that it
> > was broken before the patch, and still broken after the patch.
> 
> OK, no problem. I just didn't want Greg/Jiri to think I was sending them
> broken commits.   Will need a v3 to get rid of the extra module.h
> anyway, so that gives you a chance to reword.

Sure.

> > 
> > The Fixes tag was meant to just be a reference to the commit I'm
> > reverting.
> 
> Yeah, but since the stable people trigger off of that, and since the
> revert doesn't really fix anything, that is probably best removed.
> The stable trees don't need the revert.

Yes, good point.

	Arnd


From arnd at arndb.de  Thu Feb 11 08:31:56 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 17:31:56 +0100
Subject: [PATCH v2 5/6] serial: 8250/mediatek: fix building with
 SERIAL_8250=m
In-Reply-To: <20160211160438.GH28452@windriver.com>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
 <1455205297-1021302-6-git-send-email-arnd@arndb.de>
 <20160211160438.GH28452@windriver.com>
Message-ID: <4817391.g2eX6rsJJ6@wuerfel>

On Thursday 11 February 2016 11:04:38 you wrote:
> > diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
> > index 6ecc6e3e82dc..55be90c1d85e 100644
> > --- a/drivers/tty/serial/8250/8250_mtk.c
> > +++ b/drivers/tty/serial/8250/8250_mtk.c
> > @@ -19,6 +19,7 @@
> >  #include <linux/module.h>
> >  #include <linux/of_irq.h>
> >  #include <linux/of_platform.h>
> > +#include <linux/module.h>
> 
> Something isn't right here ; I can see module.h three lines up in the
> context.  Guessing your addition of the revert makes this addition no
> longer required...
> 

Ok, thanks for noticing this. Also, I really should know my alphabet
at this point. I saw that the headers were sorted alphabetically and
thought I had added it in the right place, which would have worked fine
after the revert. Oh well.

	Arnd


From will.deacon at arm.com  Thu Feb 11 08:32:31 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 11 Feb 2016 16:32:31 +0000
Subject: [PATCH v2 0/7] ARM/efi minor fixes + stub pre-boot compat checks
In-Reply-To: <20160211162920.GN4134@codeblueprint.co.uk>
References: <1454601030-9093-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160211161621.GM4134@codeblueprint.co.uk>
 <CAKv+Gu-kZrcLYhF7i0u8F2TOMqEVKp==jNoBc+Rfk61cwSkDhQ@mail.gmail.com>
 <20160211162920.GN4134@codeblueprint.co.uk>
Message-ID: <20160211163231.GB20077@arm.com>

On Thu, Feb 11, 2016 at 04:29:20PM +0000, Matt Fleming wrote:
> On Thu, 11 Feb, at 05:18:12PM, Ard Biesheuvel wrote:
> > On 11 February 2016 at 17:16, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> > > On Thu, 04 Feb, at 04:50:23PM, Ard Biesheuvel wrote:
> > >> I merged two EFI/ARM related series, whose v1's I sent out last week:
> > >>
> > >> Changes since v1:
> > >> - added various tags from various people
> > >> - new patch #3 to undefine __init
> > >>
> > >> @Matt: are you happy with all of this going through the arm64 tree? I don't
> > >> think it clashes with anything else we've got queued up for v4.6 in tip/efi/core
> > >
> > > How come this is going through the arm64 tree? Are there other patch
> > > series that this depends on or that depend on it?
> > >
> > > If it makes the most sense to take it through that tree, then I'm fine
> > > with it but I'd like to hear a rationale.
> > 
> > I simply thought it would be most convenient, since it touches
> > ARM-specific files only. But if you feel it should go via the EFI tree
> > instead, that is also fine by me.
> 
> Since the diff stat is heavily weighted towards drivers/firmware/efi I
> think it should go via the EFI tree. So I'll pick this up (the changes
> look fine) unless Will or Catalin complain otherwise.

No complaints here (the arm64 bits are all acked).

Will


From jonathanh at nvidia.com  Thu Feb 11 08:38:36 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Thu, 11 Feb 2016 16:38:36 +0000
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <CAPDyKFq_0t4tcvkgMBW8p8ubJDALWMjdhgGM+_Z6auRxEkSPdA@mail.gmail.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
 <56BB7AF4.8040708@nvidia.com>
 <CAPDyKFrZ6tWBsQC0tyWWeChiZja3h_zcbaiX25ak-Zyp4MzqVw@mail.gmail.com>
 <56BC50C2.7050609@nvidia.com>
 <CAPDyKFrdmufsMqNL0U7q5gPEUqsg3SrkrNChcziQjEOjvd30Ng@mail.gmail.com>
 <56BC5EE0.2040804@nvidia.com>
 <CAPDyKFq_0t4tcvkgMBW8p8ubJDALWMjdhgGM+_Z6auRxEkSPdA@mail.gmail.com>
Message-ID: <56BCB90C.8000302@nvidia.com>


On 11/02/16 10:28, Ulf Hansson wrote:
> On 11 February 2016 at 11:13, Jon Hunter <jonathanh at nvidia.com> wrote:
>>
>> On 11/02/16 09:57, Ulf Hansson wrote:
>>> On 11 February 2016 at 10:13, Jon Hunter <jonathanh at nvidia.com> wrote:
>>>>
>>>> On 10/02/16 18:25, Ulf Hansson wrote:
>>>>
>>>> [snip]
>>>>
>>>>>>> Perhaps there's a way to allow the generic PM domain to control this
>>>>>>> by itself. If we for example used the struct device corresponding to
>>>>>>> the powergate driver, genpd could use it to distinguish between
>>>>>>> various instances of genpd structs..!? Maybe it would simplify the way
>>>>>>> to deal with removing domains?
>>>>>>
>>>>>> Yes, that would be ideal. However, would have require changing
>>>>>> genpd_init()? I am not sure how genpd would be able to access the device
>>>>>> struct for the powergate driver because we don't provide this via any
>>>>>> API I am aware of? And I am guessing that you don't wish to expose the
>>>>>> gpd_list to the world either.
>>>>>>
>>>>>> If there is an easy way, I am open to it, but looking at it today, I am
>>>>>> not sure I see a simple way in which we could add a new API to do this.
>>>>>> However, may be I am missing something!
>>>>>
>>>>> If we add a new __pm_genpd_init() API, that could require a struct
>>>>> device to be provided. That API will thus invoke the existing
>>>>> pm_genpd_init() but also deal with the extra things needed here.
>>>>>
>>>>> I would also allow such an API to return an error code.
>>>>>
>>>>> Correspondingly, pm_genpd_remove() could be required to be provided
>>>>> with a struct device.
>>>>>
>>>>> Existing users of pm_genpd_init() can then convert to
>>>>> __pm_genpd_init() whenever suitable.
>>>>>
>>>>> Of course, another option is just to add new member in the genpd
>>>>> struct for the struct *device. The caller of pm_genpd_init() could
>>>>> check it, but allow it to be NULL. Although, the pm_genpd_remove() API
>>>>> would require that pointer to the struct device to be set...
>>>>>
>>>>> What do you think?
>>>>
>>>> Yes, sounds good. May be it is simpler just to add a new member and let
>>>> the platform genpd driver handle it.
>>>>
>>>> I am wondering if in addition to pm_genpd_remove(), we then just have a
>>>> function called pm_genpd_remove_tail(), which allows you to pass the
>>>> struct device pointer and will remove the last pm-domain from the
>>>> gpd_list and return the genpd pointer if successful. Internally, it will
>>>> call pm_genpd_remove(). It seems to me that if there are nested
>>>> pm-domains, then we probably want to remove them starting from the tail
>>>> as opposed to the head.
>>>>
>>>> How does that sound?
>>>
>>> Why not make pm_genpd_remove() to behave as you describe for
>>> pm_genpd_remove_tail()?
>>> That's probably the only sane way to remove genpds anyhow!?
>>
>> Simply to offer flexibility. I could see that for some devices that have
>> no dependencies between pm-domains and have a static list of pm-domains,
>> they can simply call pm_genpd_remove() for a given pm-domain. However,
>> that said, I can envision a case where a single pm-domain would be
>> removed by itself and so may be there is no benefit?
> 
> If I understand correctly, you agree to try with the most simple
> approach first and thus without providing too much flexibility.
> 
> Anyway, I am looking forward to review your next version of the patchset! :-)

So one snag I hit with this, is that in order to remove a pm-domain, I
first need to check if it is a subdomain of any other domains and if so
remove it as a subdomain first. Before, this was simple because I called
pm_genpd_remove_subdomain if the domain had a parent, and then called
pm_genpd_remove().

With the proposal we have discussed, I no longer have any knowledge of
whether the pm-domain is a subdomain or not because pm_genpd_remove()
would remove the tail and then return it. So this means that I now need
to handle the removal of the subdomain within pm_genpd_remove(), which
is ok, but creates more changes as I need to parse the slave_links list,
etc.

I am wondering if it would be better to add a simple function called
pm_genpd_list_get_tail(struct device *dev) that would return the last
pm-domain register for a given device and then simply call
pm_genpd_remove_subdomain() (if needed) and pm_genpd_remove()?

Let me know what you think.

Cheers
Jon


From qnguyen at apm.com  Thu Feb 11 08:35:36 2016
From: qnguyen at apm.com (Quan Nguyen)
Date: Thu, 11 Feb 2016 23:35:36 +0700
Subject: [PATCH v5 1/3] gpio: xgene: Enable X-Gene standby GPIO as
 interrupt controller
In-Reply-To: <56BB52B8.4040501@arm.com>
References: <1454041735-8434-1-git-send-email-qnguyen@apm.com>
 <1454041735-8434-2-git-send-email-qnguyen@apm.com>
 <56BB52B8.4040501@arm.com>
Message-ID: <CAFopSPSDdc4PQwdhkMM=vsGKuDfoObywA7hmQa+B44pSjGKA5w@mail.gmail.com>

On Wed, Feb 10, 2016 at 10:09 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> Quan,
>
> This is getting better. Some comments below.
>
> On 29/01/16 04:28, Quan Nguyen wrote:
>> Enable X-Gene standby GPIO controller as interrupt controller to provide
>> its own resources. This avoids ambiguity where GIC interrupt resource is
>> use as X-Gene standby GPIO interrupt resource in user driver.
>>
>> Signed-off-by: Y Vo <yvo at apm.com>
>> Signed-off-by: Quan Nguyen <qnguyen at apm.com>
>> ---
>>  drivers/gpio/gpio-xgene-sb.c | 275 ++++++++++++++++++++++++++++++++++++++-----
>>  1 file changed, 243 insertions(+), 32 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-xgene-sb.c b/drivers/gpio/gpio-xgene-sb.c
>> index 282004d..026da90 100644
>> --- a/drivers/gpio/gpio-xgene-sb.c
>> +++ b/drivers/gpio/gpio-xgene-sb.c
>> @@ -2,8 +2,9 @@
>>   * AppliedMicro X-Gene SoC GPIO-Standby Driver
>>   *
>>   * Copyright (c) 2014, Applied Micro Circuits Corporation
>> - * Author:   Tin Huynh <tnhuynh at apm.com>.
>> - *           Y Vo <yvo at apm.com>.
>> + * Author:   Tin Huynh <tnhuynh at apm.com>.
>> + *           Y Vo <yvo at apm.com>.
>> + *           Quan Nguyen <qnguyen at apm.com>.
>>   *
>>   * This program is free software; you can redistribute  it and/or modify it
>>   * under  the terms of  the GNU General  Public License as published by the
>> @@ -28,9 +29,14 @@
>>
>>  #include "gpiolib.h"
>>
>> -#define XGENE_MAX_GPIO_DS            22
>> -#define XGENE_MAX_GPIO_DS_IRQ                6
>> +/* Common property names */
>> +#define XGENE_NIRQ_PROPERTY          "apm,nr-irqs"
>> +#define XGENE_NGPIO_PROPERTY         "apm,nr-gpios"
>> +#define XGENE_IRQ_START_PROPERTY     "apm,irq-start"
>>
>> +#define XGENE_DFLT_MAX_NGPIO         22
>> +#define XGENE_DFLT_MAX_NIRQ          6
>> +#define XGENE_DFLT_IRQ_START_PIN     8
>>  #define GPIO_MASK(x)                 (1U << ((x) % 32))
>>
>>  #define MPA_GPIO_INT_LVL             0x0290
>> @@ -39,19 +45,32 @@
>>  #define MPA_GPIO_IN_ADDR             0x02a4
>>  #define MPA_GPIO_SEL_LO              0x0294
>>
>> +#define GPIO_INT_LEVEL_H     0x000001
>> +#define GPIO_INT_LEVEL_L     0x000000
>> +
>>  /**
>>   * struct xgene_gpio_sb - GPIO-Standby private data structure.
>>   * @gc:                              memory-mapped GPIO controllers.
>> - * @irq:                     Mapping GPIO pins and interrupt number
>> - * nirq:                     Number of GPIO pins that supports interrupt
>> + * @regs:                    GPIO register base offset
>> + * @irq_domain:                      GPIO interrupt domain
>> + * @irq_start:                       GPIO pin that start support interrupt
>> + * @nirq:                    Number of GPIO pins that supports interrupt
>> + * @parent_irq_base:         Start parent HWIRQ
>>   */
>>  struct xgene_gpio_sb {
>>       struct gpio_chip        gc;
>> -     u32 *irq;
>> -     u32 nirq;
>> +     void __iomem            *regs;
>> +     struct irq_domain       *irq_domain;
>> +     u16                     irq_start;
>> +     u16                     nirq;
>> +     u16                     parent_irq_base;
>>  };
>>
>> -static void xgene_gpio_set_bit(struct gpio_chip *gc, void __iomem *reg, u32 gpio, int val)
>> +#define HWIRQ_TO_GPIO(priv, hwirq) ((hwirq) + (priv)->irq_start)
>> +#define GPIO_TO_HWIRQ(priv, gpio) ((gpio) - (priv)->irq_start)
>> +
>> +static void xgene_gpio_set_bit(struct gpio_chip *gc,
>> +                             void __iomem *reg, u32 gpio, int val)
>>  {
>>       u32 data;
>>
>> @@ -63,23 +82,180 @@ static void xgene_gpio_set_bit(struct gpio_chip *gc, void __iomem *reg, u32 gpio
>>       gc->write_reg(reg, data);
>>  }
>>
>> -static int apm_gpio_sb_to_irq(struct gpio_chip *gc, u32 gpio)
>> +static int xgene_gpio_sb_irq_set_type(struct irq_data *d, unsigned int type)
>> +{
>> +     struct xgene_gpio_sb *priv = irq_data_get_irq_chip_data(d);
>> +     int gpio = HWIRQ_TO_GPIO(priv, d->hwirq);
>> +     int lvl_type = GPIO_INT_LEVEL_H;
>> +
>> +     switch (type & IRQ_TYPE_SENSE_MASK) {
>> +     case IRQ_TYPE_EDGE_RISING:
>> +     case IRQ_TYPE_LEVEL_HIGH:
>> +             lvl_type = GPIO_INT_LEVEL_H;
>> +             break;
>> +     case IRQ_TYPE_EDGE_FALLING:
>> +     case IRQ_TYPE_LEVEL_LOW:
>> +             lvl_type = GPIO_INT_LEVEL_L;
>> +             break;
>> +     default:
>> +             break;
>> +     }
>> +
>> +     xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_SEL_LO,
>> +                     gpio * 2, 1);
>> +     xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_INT_LVL,
>> +                     d->hwirq, lvl_type);
>> +
>> +     /* Propagate IRQ type setting to parent */
>> +     if (type & IRQ_TYPE_EDGE_BOTH)
>> +             return irq_chip_set_type_parent(d, IRQ_TYPE_EDGE_RISING);
>> +     else
>> +             return irq_chip_set_type_parent(d, IRQ_TYPE_LEVEL_HIGH);
>> +}
>> +
>> +static void xgene_gpio_sb_irq_shutdown(struct irq_data *d)
>> +{
>> +     struct xgene_gpio_sb *priv = irq_data_get_irq_chip_data(d);
>> +
>> +     gpiochip_unlock_as_irq(&priv->gc, HWIRQ_TO_GPIO(priv, d->hwirq));
>> +}
>> +
>> +static struct irq_chip xgene_gpio_sb_irq_chip = {
>> +     .name           = "sbgpio",
>> +     .irq_ack        = irq_chip_ack_parent,
>
> There is no point calling irq_chip_ack_parent, as the GIC doesn't
> implement an irq_ack method at all.
>

Thanks Marc, let me remove it.

>> +     .irq_eoi        = irq_chip_eoi_parent,
>> +     .irq_mask       = irq_chip_mask_parent,
>> +     .irq_unmask     = irq_chip_unmask_parent,
>> +     .irq_set_type   = xgene_gpio_sb_irq_set_type,
>> +     .irq_shutdown   = xgene_gpio_sb_irq_shutdown,
>> +};
>> +
>> +static int xgene_gpio_sb_to_irq(struct gpio_chip *gc, u32 gpio)
>>  {
>>       struct xgene_gpio_sb *priv = gpiochip_get_data(gc);
>> +     struct irq_fwspec fwspec;
>> +
>> +     if ((gpio < priv->irq_start) ||
>> +                     (gpio > HWIRQ_TO_GPIO(priv, priv->nirq)))
>> +             return -ENXIO;
>> +
>> +     if (gc->parent->of_node)
>> +             fwspec.fwnode = of_node_to_fwnode(gc->parent->of_node);
>> +     else
>> +             fwspec.fwnode = gc->parent->fwnode;
>> +     fwspec.param_count = 2;
>> +     fwspec.param[0] = GPIO_TO_HWIRQ(priv, gpio);
>> +     fwspec.param[1] = IRQ_TYPE_NONE;
>> +     return irq_create_fwspec_mapping(&fwspec);
>> +}
>> +
>> +static void xgene_gpio_sb_domain_activate(struct irq_domain *d,
>> +             struct irq_data *irq_data)
>> +{
>> +     struct xgene_gpio_sb *priv = d->host_data;
>> +     u32 gpio = HWIRQ_TO_GPIO(priv, irq_data->hwirq);
>> +
>> +     if (gpiochip_lock_as_irq(&priv->gc, gpio)) {
>> +             dev_err(priv->gc.parent,
>> +             "Unable to configure XGene GPIO standby pin %d as IRQ\n",
>> +                             gpio);
>> +             return;
>> +     }
>> +
>> +     xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_SEL_LO,
>> +                     gpio * 2, 1);
>> +}
>> +
>> +static void xgene_gpio_sb_domain_deactivate(struct irq_domain *d,
>> +             struct irq_data *irq_data)
>> +{
>> +     struct xgene_gpio_sb *priv = d->host_data;
>> +     u32 gpio = HWIRQ_TO_GPIO(priv, irq_data->hwirq);
>> +
>> +     gpiochip_unlock_as_irq(&priv->gc, gpio);
>
> Is it right to do the unlock both in irq_shutdown and domain_deactivate?
> This seems a bit odd to me to have such an inbalance. My hunch is that
> you should either implement irq_startup, do the locking there and drop
> the unlock drop deactivate, or kill irq_shutdown.
>
> Linus, what do you think?
>

I refer to kill irq_shutdown.

>> +     xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_SEL_LO,
>> +                     gpio * 2, 0);
>> +}
>>
>> -     if (priv->irq[gpio])
>> -             return priv->irq[gpio];
>> +static int xgene_gpio_sb_domain_translate(struct irq_domain *d,
>> +             struct irq_fwspec *fwspec,
>> +             unsigned long *hwirq,
>> +             unsigned int *type)
>> +{
>> +     struct xgene_gpio_sb *priv = d->host_data;
>> +
>> +     if ((fwspec->param_count != 2) ||
>> +             (fwspec->param[0] >= priv->nirq))
>> +             return -EINVAL;
>> +     *hwirq = fwspec->param[0];
>> +     *type = fwspec->param[1];
>> +     return 0;
>> +}
>> +
>> +static int xgene_gpio_sb_domain_alloc(struct irq_domain *domain,
>> +                                     unsigned int virq,
>> +                                     unsigned int nr_irqs, void *data)
>> +{
>> +     struct irq_fwspec *fwspec = data;
>> +     struct irq_fwspec parent_fwspec;
>> +     struct xgene_gpio_sb *priv = domain->host_data;
>> +     irq_hw_number_t hwirq;
>> +     unsigned int i;
>> +
>> +     hwirq = fwspec->param[0];
>> +     for (i = 0; i < nr_irqs; i++)
>> +             irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
>> +                             &xgene_gpio_sb_irq_chip, priv);
>> +
>> +     if (is_of_node(domain->parent->fwnode)) {
>> +             parent_fwspec.fwnode = domain->parent->fwnode;
>> +             parent_fwspec.param_count = 3;
>> +             parent_fwspec.param[0] = 0;/* SPI */
>> +             /* Skip SGIs and PPIs*/
>> +             parent_fwspec.param[1] = hwirq + priv->parent_irq_base - 32;
>> +             parent_fwspec.param[2] = fwspec->param[1];
>> +     } else if (is_fwnode_irqchip(domain->parent->fwnode)) {
>> +             parent_fwspec.fwnode = domain->parent->fwnode;
>
> nit: You can move this out of the if/else, and always assign the fwnode.

Thanks Marc, let me change it.

>
>> +             parent_fwspec.param_count = 2;
>> +             parent_fwspec.param[0] = hwirq + priv->parent_irq_base;
>> +             parent_fwspec.param[1] = fwspec->param[1];
>> +     } else
>> +             return -EINVAL;
>>
>> -     return -ENXIO;
>> +     return irq_domain_alloc_irqs_parent(domain, virq, nr_irqs,
>> +                     &parent_fwspec);
>>  }
>>
>> +static void xgene_gpio_sb_domain_free(struct irq_domain *domain,
>> +             unsigned int virq,
>> +             unsigned int nr_irqs)
>> +{
>> +     struct irq_data *d;
>> +     unsigned int i;
>> +
>> +     for (i = 0; i < nr_irqs; i++) {
>> +             d = irq_domain_get_irq_data(domain, virq + i);
>> +             irq_domain_reset_irq_data(d);
>> +     }
>> +}
>> +
>> +static const struct irq_domain_ops xgene_gpio_sb_domain_ops = {
>> +     .translate      = xgene_gpio_sb_domain_translate,
>> +     .alloc          = xgene_gpio_sb_domain_alloc,
>> +     .free           = xgene_gpio_sb_domain_free,
>> +     .activate       = xgene_gpio_sb_domain_activate,
>> +     .deactivate     = xgene_gpio_sb_domain_deactivate,
>> +};
>> +
>>  static int xgene_gpio_sb_probe(struct platform_device *pdev)
>>  {
>>       struct xgene_gpio_sb *priv;
>> -     u32 ret, i;
>> -     u32 default_lines[] = {0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D};
>> +     u32 ret;
>>       struct resource *res;
>>       void __iomem *regs;
>> +     struct irq_domain *parent_domain = NULL;
>> +     struct fwnode_handle *fwnode;
>> +     u32 val32;
>>
>>       priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>>       if (!priv)
>> @@ -90,6 +266,18 @@ static int xgene_gpio_sb_probe(struct platform_device *pdev)
>>       if (IS_ERR(regs))
>>               return PTR_ERR(regs);
>>
>> +     priv->regs = regs;
>> +
>> +     ret = platform_get_irq(pdev, 0);
>> +     if (ret > 0) {
>> +             priv->parent_irq_base = irq_get_irq_data(ret)->hwirq;
>> +             parent_domain = irq_get_irq_data(ret)->domain;
>> +     }
>> +     if (!parent_domain) {
>> +             dev_err(&pdev->dev, "unable to obtain parent domain\n");
>> +             return -ENODEV;
>> +     }
>> +
>>       ret = bgpio_init(&priv->gc, &pdev->dev, 4,
>>                       regs + MPA_GPIO_IN_ADDR,
>>                       regs + MPA_GPIO_OUT_ADDR, NULL,
>> @@ -97,30 +285,51 @@ static int xgene_gpio_sb_probe(struct platform_device *pdev)
>>          if (ret)
>>                  return ret;
>>
>> -     priv->gc.to_irq = apm_gpio_sb_to_irq;
>> -     priv->gc.ngpio = XGENE_MAX_GPIO_DS;
>> +     priv->gc.to_irq = xgene_gpio_sb_to_irq;
>>
>> -     priv->nirq = XGENE_MAX_GPIO_DS_IRQ;
>> +     /* Retrieve start irq pin, use default if property not found */
>> +     priv->irq_start = XGENE_DFLT_IRQ_START_PIN;
>> +     if (!device_property_read_u32(&pdev->dev,
>> +                                     XGENE_IRQ_START_PROPERTY, &val32))
>
> Is that for ACPI as well?
>

Yes, Marc.

>> +             priv->irq_start = val32;
>>
>> -     priv->irq = devm_kzalloc(&pdev->dev, sizeof(u32) * XGENE_MAX_GPIO_DS,
>> -                                GFP_KERNEL);
>> -     if (!priv->irq)
>> -             return -ENOMEM;
>> +     /* Retrieve number irqs, use default if property not found */
>> +     priv->nirq = XGENE_DFLT_MAX_NIRQ;
>> +     if (!device_property_read_u32(&pdev->dev, XGENE_NIRQ_PROPERTY, &val32))
>> +             priv->nirq = val32;
>>
>> -     for (i = 0; i < priv->nirq; i++) {
>> -             priv->irq[default_lines[i]] = platform_get_irq(pdev, i);
>> -             xgene_gpio_set_bit(&priv->gc, regs + MPA_GPIO_SEL_LO,
>> -                                   default_lines[i] * 2, 1);
>> -             xgene_gpio_set_bit(&priv->gc, regs + MPA_GPIO_INT_LVL, i, 1);
>> -     }
>> +     /* Retrieve number gpio, use default if property not found */
>> +     priv->gc.ngpio = XGENE_DFLT_MAX_NGPIO;
>> +     if (!device_property_read_u32(&pdev->dev, XGENE_NGPIO_PROPERTY, &val32))
>> +             priv->gc.ngpio = val32;
>> +
>> +     dev_info(&pdev->dev, "Support %d gpios, %d irqs start from pin %d\n",
>> +                     priv->gc.ngpio, priv->nirq, priv->irq_start);
>>
>>       platform_set_drvdata(pdev, priv);
>>
>> -     ret = gpiochip_add_data(&priv->gc, priv);
>> -     if (ret)
>> -             dev_err(&pdev->dev, "failed to register X-Gene GPIO Standby driver\n");
>> +     if (pdev->dev.of_node)
>> +             fwnode = of_node_to_fwnode(pdev->dev.of_node);
>>       else
>> -             dev_info(&pdev->dev, "X-Gene GPIO Standby driver registered\n");
>> +             fwnode = pdev->dev.fwnode;
>> +
>> +     priv->irq_domain = irq_domain_create_hierarchy(parent_domain,
>> +                                     0, priv->nirq, fwnode,
>> +                                     &xgene_gpio_sb_domain_ops, priv);
>> +     if (!priv->irq_domain)
>> +             return -ENODEV;
>> +
>> +     priv->gc.irqdomain = priv->irq_domain;
>> +
>> +     ret = gpiochip_add_data(&priv->gc, priv);
>> +     if (ret) {
>> +             dev_err(&pdev->dev,
>> +                     "failed to register X-Gene GPIO Standby driver\n");
>> +             irq_domain_remove(priv->irq_domain);
>> +             return ret;
>> +     }
>> +
>> +     dev_info(&pdev->dev, "X-Gene GPIO Standby driver registered\n");
>>
>>       if (priv->nirq > 0) {
>>               /* Register interrupt handlers for gpio signaled acpi events */
>> @@ -138,6 +347,8 @@ static int xgene_gpio_sb_remove(struct platform_device *pdev)
>>               acpi_gpiochip_free_interrupts(&priv->gc);
>>       }
>>
>> +     irq_domain_remove(priv->irq_domain);
>> +
>>       gpiochip_remove(&priv->gc);
>>       return 0;
>>  }
>>
>
> Thanks,
>
>         M.
> --
> Jazz is not dead. It just smells funny...


From gregory.clement at free-electrons.com  Thu Feb 11 08:45:38 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 11 Feb 2016 17:45:38 +0100
Subject: [GIT PULL] ARM: mvebu: fixes for v4.5 (#2)
Message-ID: <874mdfxkjx.fsf@free-electrons.com>

Hi,

Here is the second pull request for fixes for mvebu for v4.5.

Gregory

The following changes since commit ff61ee84e7aa5842d9e33c0b442f0b43a6a44eaf:

  ARM: dts: orion5x: gpio pin fixes for linkstation lswtgl (2016-01-25 16:22:59 +0100)

are available in the git repository at:

  git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-4.5-2

for you to fetch changes up to 44361a2cc13493fc41216d33bb9a562ec3a9cc4e:

  ARM: dts: orion5x: fix the missing mtd flash on linkstation lswtgl (2016-02-09 11:17:53 +0100)

----------------------------------------------------------------
mvebu fixes for 4.5 (part 2)

- Fix the missing mtd flash on linkstation lswtgl
- Use unique machine name for the kirkwood ds112 (for Debian flash-kernel tool)

----------------------------------------------------------------
Heinrich Schuchardt (1):
      ARM: dts: kirkwood: use unique machine name for ds112

Roger Shimizu (1):
      ARM: dts: orion5x: fix the missing mtd flash on linkstation lswtgl

 arch/arm/boot/dts/kirkwood-ds112.dts             |  2 +-
 arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts | 31 ++++++++++++++++++++++++
 2 files changed, 32 insertions(+), 1 deletion(-)


From ard.biesheuvel at linaro.org  Thu Feb 11 08:47:59 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 11 Feb 2016 17:47:59 +0100
Subject: [PATCH v2 0/3] arm64: avoid early __va translations
Message-ID: <1455209282-9596-1-git-send-email-ard.biesheuvel@linaro.org>

This is a somewhat cleaner approach for dealing with the issue that the
early FDT performs __va() translations before the linear mapping has been
set up. Being able to defer the assignment of memstart_addr until after we
have discovered all of memory is an important piece of functionality, not
only for KASLR but also for mapping the linear region as efficiently as
possible.

Patch #1 refactors the early FDT code so that the actual assignment of
initrd_start and initrd_end (which is where the __va() translations are
performed) is moved into a __weak function which can be overridden.

Patch #2 overrides the __weak function to only record the physical addresses
as they are found in the /chosen node, or on the command line, and defers
the __va() translation until after memstart_addr has been assigned.

Patch #3 is some test code I used to verify that all __va() translations
are gone. Note that the open coded BUG_ON() implementation is required to
avoid .h dependency hell.

Ard Biesheuvel (3):
  of/fdt: factor out assignment of initrd_start/initrd_end
  arm64: defer __va translation of initrd_start and initrd_end
  arm64: prevent __va() translations before memstart_addr is assigned

 arch/arm64/include/asm/memory.h | 10 +++++++++-
 arch/arm64/mm/init.c            | 21 +++++++++++++++-----
 drivers/of/fdt.c                | 12 ++++++++---
 3 files changed, 34 insertions(+), 9 deletions(-)

-- 
2.5.0



From ard.biesheuvel at linaro.org  Thu Feb 11 08:48:00 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 11 Feb 2016 17:48:00 +0100
Subject: [PATCH v2 1/3] of/fdt: factor out assignment of
 initrd_start/initrd_end
In-Reply-To: <1455209282-9596-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455209282-9596-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455209282-9596-2-git-send-email-ard.biesheuvel@linaro.org>

Since architectures may not yet have their linear mapping up and running
when the initrd address is discovered from the DT, factor out the
assignment of initrd_start and initrd_end, so that an architecture can
override it and use the translation it needs.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/of/fdt.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 1f98156f8996..d1dd23127085 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -760,6 +760,14 @@ const void * __init of_flat_dt_match_machine(const void *default_match,
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
+void __weak __early_init_dt_declare_initrd(unsigned long start,
+					   unsigned long end)
+{
+	initrd_start = (unsigned long)__va(start);
+	initrd_end = (unsigned long)__va(end);
+	initrd_below_start_ok = 1;
+}
+
 /**
  * early_init_dt_check_for_initrd - Decode initrd location from flat tree
  * @node: reference to node containing initrd location ('chosen')
@@ -782,9 +790,7 @@ static void __init early_init_dt_check_for_initrd(unsigned long node)
 		return;
 	end = of_read_number(prop, len/4);
 
-	initrd_start = (unsigned long)__va(start);
-	initrd_end = (unsigned long)__va(end);
-	initrd_below_start_ok = 1;
+	__early_init_dt_declare_initrd(start, end);
 
 	pr_debug("initrd_start=0x%llx  initrd_end=0x%llx\n",
 		 (unsigned long long)start, (unsigned long long)end);
-- 
2.5.0



From ard.biesheuvel at linaro.org  Thu Feb 11 08:48:01 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 11 Feb 2016 17:48:01 +0100
Subject: [PATCH v2 2/3] arm64: defer __va translation of initrd_start and
 initrd_end
In-Reply-To: <1455209282-9596-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455209282-9596-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455209282-9596-3-git-send-email-ard.biesheuvel@linaro.org>

Commit 66f51676a095 ("arm64: allow kernel Image to be loaded anywhere in
physical memory") defers the assignment of memstart_addr to the point where
all memory has been discovered and possibly clipped based on the size of
the linear region and the presence of a mem= command line parameter.

However, this results in __va() translations that have been performed up
to this point to have been carried out with a preliminary, incorrect value
of memstart_addr, and these values need to be fixed up. So wire up the
generic support to declare the initrd addresses, and implement it without
__va() translations, and perform the translation after memstart_addr has
been assigned.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/mm/init.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 3a9fc46cbf80..eff4751f8761 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -61,12 +61,18 @@ static int __init early_initrd(char *p)
 	if (*endp == ',') {
 		size = memparse(endp + 1, NULL);
 
-		initrd_start = (unsigned long)__va(start);
-		initrd_end = (unsigned long)__va(start + size);
+		initrd_start = start;
+		initrd_end = start + size;
 	}
 	return 0;
 }
 early_param("initrd", early_initrd);
+
+void __early_init_dt_declare_initrd(unsigned long start, unsigned long end)
+{
+	initrd_start = start;
+	initrd_end = end;
+}
 #endif
 
 /*
@@ -213,8 +219,13 @@ void __init arm64_memblock_init(void)
 	 */
 	memblock_reserve(__pa(_text), _end - _text);
 #ifdef CONFIG_BLK_DEV_INITRD
-	if (initrd_start)
-		memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
+	if (initrd_start) {
+		memblock_reserve(initrd_start, initrd_end - initrd_start);
+
+		/* the generic initrd code expects virtual addresses */
+		initrd_start = __phys_to_virt(initrd_start);
+		initrd_end = __phys_to_virt(initrd_end);
+	}
 #endif
 
 	early_init_fdt_scan_reserved_mem();
-- 
2.5.0



From ard.biesheuvel at linaro.org  Thu Feb 11 08:48:02 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 11 Feb 2016 17:48:02 +0100
Subject: [PATCH v2 3/3] arm64: prevent __va() translations before
 memstart_addr is assigned
In-Reply-To: <1455209282-9596-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455209282-9596-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455209282-9596-4-git-send-email-ard.biesheuvel@linaro.org>

Just a hack to check whether all early __va() calls are gone.
---
 arch/arm64/include/asm/memory.h | 10 +++++++++-
 arch/arm64/mm/init.c            |  2 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 083361531a61..0d4d1b3b9695 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -90,7 +90,9 @@
 	__x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :	\
 			     (__x - kimage_voffset); })
 
-#define __phys_to_virt(x)	((unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET))
+#define __phys_to_virt(x) ({						\
+	assert_memstart_addr_assigned();				\
+	(unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET); })
 #define __phys_to_kimg(x)	((unsigned long)((x) + kimage_voffset))
 
 /*
@@ -133,6 +135,12 @@ extern u64			kimage_vaddr;
 /* the offset between the kernel virtual and physical mappings */
 extern u64			kimage_voffset;
 
+static inline void assert_memstart_addr_assigned(void)
+{
+	if (unlikely(memstart_addr == (phys_addr_t)-1))
+		asm("brk #%0" :: "I"(0x800));
+}
+
 /*
  * Allow all memory at the discovery stage. We will clip it later.
  */
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index eff4751f8761..e88db8acd181 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -48,7 +48,7 @@
 
 #include "mm.h"
 
-phys_addr_t memstart_addr __read_mostly = 0;
+phys_addr_t memstart_addr __read_mostly = (phys_addr_t)-1;
 phys_addr_t arm64_dma_phys_limit __read_mostly;
 
 #ifdef CONFIG_BLK_DEV_INITRD
-- 
2.5.0



From mathieu.poirier at linaro.org  Thu Feb 11 08:59:51 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 11 Feb 2016 09:59:51 -0700
Subject: [PATCH V3 6/6] coresight-stm: adding driver for CoreSight STM
 component
In-Reply-To: <1454756672-12790-7-git-send-email-zhang.chunyan@linaro.org>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
 <1454756672-12790-7-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <CANLsYkxvLFu1C+_H9c0EoMebLQu1gnwt9bqY6_R3j+ua2w+xMg@mail.gmail.com>

On 6 February 2016 at 04:04, Chunyan Zhang <zhang.chunyan at linaro.org> wrote:
> From: Pratik Patel <pratikp at codeaurora.org>
>
> This driver adds support for the STM CoreSight IP block, allowing any
> system compoment (HW or SW) to log and aggregate messages via a
> single entity.
>
> The CoreSight STM exposes an application defined number of channels
> called stimulus port.  Configuration is done using entries in sysfs
> and channels made available to userspace via configfs.
>
> Signed-off-by: Pratik Patel <pratikp at codeaurora.org>
> Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
> Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
> ---
>  .../ABI/testing/sysfs-bus-coresight-devices-stm    |  53 ++
>  Documentation/trace/coresight.txt                  |  37 +-
>  drivers/hwtracing/coresight/Kconfig                |  11 +
>  drivers/hwtracing/coresight/Makefile               |   1 +
>  drivers/hwtracing/coresight/coresight-stm.c        | 928 +++++++++++++++++++++
>  include/linux/coresight-stm.h                      |   6 +
>  include/uapi/linux/coresight-stm.h                 |  12 +
>  7 files changed, 1046 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>  create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
>  create mode 100644 include/linux/coresight-stm.h
>  create mode 100644 include/uapi/linux/coresight-stm.h
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
> new file mode 100644
> index 0000000..a1d7022
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
> @@ -0,0 +1,53 @@
> +What:          /sys/bus/coresight/devices/<memory_map>.stm/enable_source
> +Date:          February 2016
> +KernelVersion: 4.5
> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
> +Description:   (RW) Enable/disable tracing on this specific trace macrocell.
> +               Enabling the trace macrocell implies it has been configured
> +               properly and a sink has been identidifed for it.  The path
> +               of coresight components linking the source to the sink is
> +               configured and managed automatically by the coresight framework.
> +
> +What:          /sys/bus/coresight/devices/<memory_map>.stm/hwevent_enable
> +Date:          February 2016
> +KernelVersion: 4.5
> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
> +Description:   (RW) Provides access to the HW event enable register, used in
> +               conjunction with HW event bank select register.
> +
> +What:          /sys/bus/coresight/devices/<memory_map>.stm/hwevent_select
> +Date:          February 2016
> +KernelVersion: 4.5
> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
> +Description:   (RW) Gives access to the HW event block select register
> +               (STMHEBSR) in order to configure up to 256 channels.  Used in
> +               conjunction with "hwevent_enable" register as described above.
> +
> +What:          /sys/bus/coresight/devices/<memory_map>.stm/port_enable
> +Date:          February 2016
> +KernelVersion: 4.5
> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
> +Description:   (RW) Provides access to the stimlus port enable register
> +               (STMSPER).  Used in conjunction with "port_select" described
> +               below.
> +
> +What:          /sys/bus/coresight/devices/<memory_map>.stm/port_select
> +Date:          February 2016
> +KernelVersion: 4.5
> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
> +Description:   (RW) Used to determine which bank of stimulus port bit in
> +               register STMSPER (see above) apply to.
> +
> +What:          /sys/bus/coresight/devices/<memory_map>.stm/status
> +Date:          February 2016
> +KernelVersion: 4.5
> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
> +Description:   (R) List various control and status registers.  The specific
> +               layout and content is driver specific.
> +
> +What:          /sys/bus/coresight/devices/<memory_map>.stm/traceid
> +Date:          February 2016
> +KernelVersion: 4.5
> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
> +Description:   (RW) Holds the trace ID that will appear in the trace stream
> +               coming from this trace entity.
> diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
> index 0a5c329..a33c88c 100644
> --- a/Documentation/trace/coresight.txt
> +++ b/Documentation/trace/coresight.txt
> @@ -190,8 +190,8 @@ expected to be accessed and controlled using those entries.
>  Last but not least, "struct module *owner" is expected to be set to reflect
>  the information carried in "THIS_MODULE".
>
> -How to use
> -----------
> +How to use the tracer modules
> +-----------------------------
>
>  Before trace collection can start, a coresight sink needs to be identify.
>  There is no limit on the amount of sinks (nor sources) that can be enabled at
> @@ -297,3 +297,36 @@ Info                                    Tracing enabled
>  Instruction     13570831        0x8026B584      E28DD00C        false   ADD      sp,sp,#0xc
>  Instruction     0       0x8026B588      E8BD8000        true    LDM      sp!,{pc}
>  Timestamp                                       Timestamp: 17107041535
> +
> +How to use the STM module
> +-------------------------
> +
> +Using the System Trace Macrocell module is the same as the tracers - the only
> +difference is that clients are driving the trace capture rather
> +than the program flow through the code.
> +
> +As with any other CoreSight component, specifics about the STM tracer can be
> +found in sysfs with more information on each entry being found in [1]:
> +
> +root at genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
> +enable_source   hwevent_select  port_enable     subsystem       uevent
> +hwevent_enable  mgmt            port_select     traceid
> +root at genericarmv8:~#
> +
> +Like any other source a sink needs to be identified and the STM enabled before
> +being used:
> +
> +root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
> +root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
> +
> +From there user space applications can request and use channels using the devfs
> +interface provided for that purpose by the generic STM API:
> +
> +root at genericarmv8:~# ls -l /dev/20100000.stm
> +crw-------    1 root     root       10,  61 Jan  3 18:11 /dev/20100000.stm
> +root at genericarmv8:~#
> +
> +Details on how to use the generic STM API can be found here [2].
> +
> +[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
> +[2]. Documentation/trace/stm.txt
> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
> index c85935f..f4a8bfa 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -77,4 +77,15 @@ config CORESIGHT_QCOM_REPLICATOR
>           programmable ATB replicator sends the ATB trace stream from the
>           ETB/ETF to the TPIUi and ETR.
>
> +config CORESIGHT_STM
> +       bool "CoreSight System Trace Macrocell driver"
> +       depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) || ARM64
> +       select CORESIGHT_LINKS_AND_SINKS
> +       select STM
> +       help
> +         This driver provides support for hardware assisted software
> +         instrumentation based tracing. This is primarily used for
> +         logging useful software events or data coming from various entities
> +         in the system, possibly running different OSs
> +
>  endif
> diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
> index 99f8e5f..1f6eaec 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_CORESIGHT_LINKS_AND_SINKS) += coresight-funnel.o \
>  obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o coresight-etm-cp14.o
>  obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
>  obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
> +obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
> diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
> new file mode 100644
> index 0000000..01b3521
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-stm.c
> @@ -0,0 +1,928 @@
> +/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Initial implementation by Pratik Patel
> + * (C) 2014-2015 Pratik Patel <pratikp at codeaurora.org>
> + *
> + * Serious refactoring, code cleanup and upgrading to the Coresight upstream
> + * framework by Mathieu Poirier
> + * (C) 2015-2016 Mathieu Poirier <mathieu.poirier at linaro.org>
> + *
> + * Guaranteed timing and support for various packet type coming from the
> + * generic STM API by Chunyan Zhang
> + * (C) 2015-2016 Chunyan Zhang <zhang.chunyan at linaro.org>
> + */
> +#include <linux/amba/bus.h>
> +#include <linux/bitmap.h>
> +#include <linux/clk.h>
> +#include <linux/coresight.h>
> +#include <linux/coresight-stm.h>
> +#include <linux/err.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/stm.h>
> +
> +#include "coresight-priv.h"
> +
> +#define STMDMASTARTR                   0xc04
> +#define STMDMASTOPR                    0xc08
> +#define STMDMASTATR                    0xc0c
> +#define STMDMACTLR                     0xc10
> +#define STMDMAIDR                      0xcfc
> +#define STMHEER                                0xd00
> +#define STMHETER                       0xd20
> +#define STMHEBSR                       0xd60
> +#define STMHEMCR                       0xd64
> +#define STMHEMASTR                     0xdf4
> +#define STMHEFEAT1R                    0xdf8
> +#define STMHEIDR                       0xdfc
> +#define STMSPER                                0xe00
> +#define STMSPTER                       0xe20
> +#define STMPRIVMASKR                   0xe40
> +#define STMSPSCR                       0xe60
> +#define STMSPMSCR                      0xe64
> +#define STMSPOVERRIDER                 0xe68
> +#define STMSPMOVERRIDER                        0xe6c
> +#define STMSPTRIGCSR                   0xe70
> +#define STMTCSR                                0xe80
> +#define STMTSSTIMR                     0xe84
> +#define STMTSFREQR                     0xe8c
> +#define STMSYNCR                       0xe90
> +#define STMAUXCR                       0xe94
> +#define STMSPFEAT1R                    0xea0
> +#define STMSPFEAT2R                    0xea4
> +#define STMSPFEAT3R                    0xea8
> +#define STMITTRIGGER                   0xee8
> +#define STMITATBDATA0                  0xeec
> +#define STMITATBCTR2                   0xef0
> +#define STMITATBID                     0xef4
> +#define STMITATBCTR0                   0xef8
> +
> +#define STM_32_CHANNEL                 32
> +#define BYTES_PER_CHANNEL              256
> +#define STM_TRACE_BUF_SIZE             4096
> +#define STM_SW_MASTER_END              127
> +
> +/* Register bit definition */
> +#define STMTCSR_BUSY_BIT               23
> +/* Reserve the first 10 channels for kernel usage */
> +#define STM_CHANNEL_OFFSET             0
> +
> +enum stm_pkt_type {
> +       STM_PKT_TYPE_DATA       = 0x98,
> +       STM_PKT_TYPE_FLAG       = 0xE8,
> +       STM_PKT_TYPE_TRIG       = 0xF8,
> +};
> +
> +#define stm_channel_addr(drvdata, ch)  (drvdata->chs.base +    \
> +                                       (ch * BYTES_PER_CHANNEL))
> +#define stm_channel_off(type, opts)    (type & ~opts)
> +
> +static int boot_nr_channel;
> +
> +module_param_named(
> +       boot_nr_channel, boot_nr_channel, int, S_IRUGO
> +);
> +
> +/**
> + * struct channel_space - central management entity for extended ports
> + * @base:              memory mapped base address where channels start.
> + * @guaraneed:         is the channel delivery guaranteed.
> + */
> +struct channel_space {
> +       void __iomem            *base;
> +       unsigned long           *guaranteed;
> +};
> +
> +/**
> + * struct stm_drvdata - specifics associated to an STM component
> + * @base:              memory mapped base address for this component.
> + * @dev:               the device entity associated to this component.
> + * @atclk:             optional clock for the core parts of the STM.
> + * @csdev:             component vitals needed by the framework.
> + * @spinlock:          only one at a time pls.
> + * @chs:               the channels accociated to this STM.
> + * @stm:               structure associated to the generic STM interface.
> + * @enable:            this STM is being used.
> + * @traceid:           value of the current ID for this component.
> + * @write_max:         Maximus bytes this STM can write at a time.
> + * @write_64bit:       whether this STM supports 64 bit access.
> + * @stmsper:           settings for register STMSPER.
> + * @stmspscr:          settings for register STMSPSCR.
> + * @numsp:             the total number of stimulus port support by this STM.
> + * @stmheer:           settings for register STMHEER.
> + * @stmheter:          settings for register STMHETER.
> + * @stmhebsr:          settings for register STMHEBSR.
> + */
> +struct stm_drvdata {
> +       void __iomem            *base;
> +       struct device           *dev;
> +       struct clk              *atclk;
> +       struct coresight_device *csdev;
> +       spinlock_t              spinlock;
> +       struct channel_space    chs;
> +       struct stm_data         stm;
> +       bool                    enable;
> +       u8                      traceid;
> +       u8                      write_max;
> +       u32                     write_64bit;
> +       u32                     stmsper;
> +       u32                     stmspscr;
> +       u32                     numsp;
> +       u32                     stmheer;
> +       u32                     stmheter;
> +       u32                     stmhebsr;
> +};
> +
> +static void stm_hwevent_enable_hw(struct stm_drvdata *drvdata)
> +{
> +       CS_UNLOCK(drvdata->base);
> +
> +       writel_relaxed(drvdata->stmhebsr, drvdata->base + STMHEBSR);
> +       writel_relaxed(drvdata->stmheter, drvdata->base + STMHETER);
> +       writel_relaxed(drvdata->stmheer, drvdata->base + STMHEER);
> +       writel_relaxed(0x01 |   /* Enable HW event tracing */
> +                      0x04,    /* Error detection on event tracing */
> +                      drvdata->base + STMHEMCR);
> +
> +       CS_LOCK(drvdata->base);
> +}
> +
> +static void stm_port_enable_hw(struct stm_drvdata *drvdata)
> +{
> +       CS_UNLOCK(drvdata->base);
> +       /* ATB trigger enable on direct writes to TRIG locations */
> +       writel_relaxed(0x10,
> +                      drvdata->base + STMSPTRIGCSR);
> +       writel_relaxed(drvdata->stmspscr, drvdata->base + STMSPSCR);
> +       writel_relaxed(drvdata->stmsper, drvdata->base + STMSPER);
> +
> +       CS_LOCK(drvdata->base);
> +}
> +
> +static void stm_enable_hw(struct stm_drvdata *drvdata)
> +{
> +       if (drvdata->stmheer)
> +               stm_hwevent_enable_hw(drvdata);
> +
> +       stm_port_enable_hw(drvdata);
> +
> +       CS_UNLOCK(drvdata->base);
> +
> +       /* 4096 byte between synchronisation packets */
> +       writel_relaxed(0xFFF, drvdata->base + STMSYNCR);
> +       writel_relaxed((drvdata->traceid << 16 | /* trace id */
> +                       0x02 |                   /* timestamp enable */
> +                       0x01),                   /* global STM enable */
> +                       drvdata->base + STMTCSR);
> +
> +       CS_LOCK(drvdata->base);
> +}
> +
> +static int stm_enable(struct coresight_device *csdev)
> +{
> +       struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> +
> +       pm_runtime_get_sync(drvdata->dev);
> +
> +       spin_lock(&drvdata->spinlock);
> +       stm_enable_hw(drvdata);
> +       drvdata->enable = true;
> +       spin_unlock(&drvdata->spinlock);
> +
> +       dev_info(drvdata->dev, "STM tracing enabled\n");
> +       return 0;
> +}
> +
> +static void stm_hwevent_disable_hw(struct stm_drvdata *drvdata)
> +{
> +       CS_UNLOCK(drvdata->base);
> +
> +       writel_relaxed(0x0, drvdata->base + STMHEMCR);
> +       writel_relaxed(0x0, drvdata->base + STMHEER);
> +       writel_relaxed(0x0, drvdata->base + STMHETER);
> +
> +       CS_LOCK(drvdata->base);
> +}
> +
> +static void stm_port_disable_hw(struct stm_drvdata *drvdata)
> +{
> +       CS_UNLOCK(drvdata->base);
> +
> +       writel_relaxed(0x0, drvdata->base + STMSPER);
> +       writel_relaxed(0x0, drvdata->base + STMSPTRIGCSR);
> +
> +       CS_LOCK(drvdata->base);
> +}
> +
> +static void stm_disable_hw(struct stm_drvdata *drvdata)
> +{
> +       u32 val;
> +
> +       CS_UNLOCK(drvdata->base);
> +
> +       val = readl_relaxed(drvdata->base + STMTCSR);
> +       val &= ~0x1; /* clear global STM enable [0] */
> +       writel_relaxed(val, drvdata->base + STMTCSR);
> +
> +       CS_LOCK(drvdata->base);
> +
> +       stm_port_disable_hw(drvdata);
> +       if (drvdata->stmheer)
> +               stm_hwevent_disable_hw(drvdata);
> +}
> +
> +static void stm_disable(struct coresight_device *csdev)
> +{
> +       struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> +
> +       spin_lock(&drvdata->spinlock);
> +       stm_disable_hw(drvdata);
> +       drvdata->enable = false;
> +       spin_unlock(&drvdata->spinlock);
> +
> +       /* Wait until the engine has completely stopped */
> +       coresight_timeout(drvdata, STMTCSR, STMTCSR_BUSY_BIT, 0);
> +
> +       pm_runtime_put(drvdata->dev);
> +
> +       dev_info(drvdata->dev, "STM tracing disabled\n");
> +}
> +
> +static int stm_trace_id(struct coresight_device *csdev)
> +{
> +       struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
> +
> +       return drvdata->traceid;
> +}
> +
> +static const struct coresight_ops_source stm_source_ops = {
> +       .trace_id       = stm_trace_id,
> +       .enable         = stm_enable,
> +       .disable        = stm_disable,
> +};
> +
> +static const struct coresight_ops stm_cs_ops = {
> +       .source_ops     = &stm_source_ops,
> +};
> +
> +static inline bool stm_addr_unaligned(const void *addr, u8 max)
> +{
> +       return ((unsigned long)addr & (max - 1));
> +}
> +
> +static int stm_send(void *addr, const void *data, u32 size, u8 max)
> +{
> +       u32 len = size;
> +       u8 paload[8];
> +
> +       if (stm_addr_unaligned(data, max)) {
> +               memcpy(paload, data, size);
> +               data = paload;
> +       }
> +
> +       /* now we are 64bit/32bit aligned */
> +#ifdef CONFIG_64BIT
> +       if (size == 8)
> +               writeq_relaxed(*(u64 *)data, addr);
> +#endif

We probably don't need an #ifdef here.  Checking the size of the
transfer against the fundamental data size will result in the same
outcome, i.e preventing 64 bit transfers on a 32 bit architecture.  An
error (understandable by the caller) should probably be returned in
this case.

> +       if (size >= 4) {
> +               writel_relaxed(*(u32 *)data, addr);
> +               data += 4;
> +               size -= 4;
> +       }
> +
> +       if (size >= 2) {
> +               writew_relaxed(*(u16 *)data, addr);
> +               data += 2;
> +               size -= 2;
> +       }
> +
> +       if (size == 1)
> +               writeb_relaxed(*(u8 *)data, addr);
> +
> +       return len;
> +}
> +
> +static int stm_generic_link(struct stm_data *stm_data,
> +                           unsigned int master,  unsigned int channel)
> +{
> +       struct stm_drvdata *drvdata = container_of(stm_data,
> +                                                  struct stm_drvdata, stm);
> +       if (!drvdata || !drvdata->csdev)
> +               return -EINVAL;
> +
> +       return coresight_enable(drvdata->csdev);
> +}
> +
> +static void stm_generic_unlink(struct stm_data *stm_data,
> +                              unsigned int master,  unsigned int channel)
> +{
> +       struct stm_drvdata *drvdata = container_of(stm_data,
> +                                                  struct stm_drvdata, stm);
> +       if (!drvdata || !drvdata->csdev)
> +               return;
> +
> +       stm_disable(drvdata->csdev);
> +}
> +
> +static long stm_generic_set_options(struct stm_data *stm_data,
> +                                   unsigned int master,
> +                                   unsigned int channel,
> +                                   unsigned int nr_chans,
> +                                   unsigned long options)
> +{
> +       struct stm_drvdata *drvdata = container_of(stm_data,
> +                                                  struct stm_drvdata, stm);
> +       if (!(drvdata && drvdata->enable))
> +               return -EINVAL;
> +
> +       if (channel >= drvdata->numsp)
> +               return -EINVAL;
> +
> +       switch (options) {
> +       case STM_OPTION_GUARANTEED:
> +               set_bit(channel, drvdata->chs.guaranteed);
> +               break;
> +
> +       case STM_OPTION_INVARIANT:
> +               clear_bit(channel, drvdata->chs.guaranteed);
> +               break;
> +
> +       default:
> +               return -EINVAL;
> +       }
> +
> +       return 0;
> +}
> +
> +static long stm_generic_get_options(struct stm_data *stm_data,
> +                                   unsigned int master,
> +                                   unsigned int channel,
> +                                   unsigned int nr_chans,
> +                                   u64 *options)
> +{
> +       struct stm_drvdata *drvdata = container_of(stm_data,
> +                                                  struct stm_drvdata, stm);
> +       if (!(drvdata && drvdata->enable))
> +               return -EINVAL;
> +
> +       if (channel >= drvdata->numsp)
> +               return -EINVAL;
> +
> +       switch (*options) {
> +       case STM_OPTION_GUARANTEED:
> +               *options = test_bit(channel, drvdata->chs.guaranteed);
> +               break;
> +
> +       default:
> +               return -EINVAL;
> +       }
> +
> +       return 0;
> +}
> +
> +static ssize_t stm_generic_packet(struct stm_data *stm_data,
> +                                 unsigned int master,
> +                                 unsigned int channel,
> +                                 unsigned int packet,
> +                                 unsigned int flags,
> +                                 unsigned int size,
> +                                 const unsigned char *payload)
> +{
> +       unsigned long ch_addr;
> +       struct stm_drvdata *drvdata = container_of(stm_data,
> +                                                  struct stm_drvdata, stm);
> +
> +       if (!(drvdata && drvdata->enable))
> +               return 0;
> +
> +       if (channel >= drvdata->numsp)
> +               return 0;
> +
> +       ch_addr = (unsigned long)stm_channel_addr(drvdata, channel);
> +
> +       flags = (flags == STP_PACKET_TIMESTAMPED) ? STM_FLAG_TIMESTAMPED : 0;
> +       flags |= test_bit(channel, drvdata->chs.guaranteed) ?
> +                          STM_FLAG_GUARANTEED : 0;
> +
> +       if (size > drvdata->write_max)
> +               size = drvdata->write_max;
> +
> +       switch (packet) {
> +       case STP_PACKET_FLAG:
> +               ch_addr |= stm_channel_off(STM_PKT_TYPE_FLAG, flags);
> +
> +               /* the generic STM API set a size of zero on flag packets. */
> +               size = 1;
> +               break;
> +
> +       case STP_PACKET_DATA:
> +               ch_addr |= stm_channel_off(STM_PKT_TYPE_DATA, flags);
> +               break;
> +
> +       default:
> +               return 0;
> +       }
> +
> +       return stm_send((void *)ch_addr, payload, size, drvdata->write_max);
> +}
> +
> +static ssize_t hwevent_enable_show(struct device *dev,
> +                                  struct device_attribute *attr, char *buf)
> +{
> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +       unsigned long val = drvdata->stmheer;
> +
> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +
> +static ssize_t hwevent_enable_store(struct device *dev,
> +                                   struct device_attribute *attr,
> +                                   const char *buf, size_t size)
> +{
> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +       unsigned long val;
> +       int ret = 0;
> +
> +       ret = kstrtoul(buf, 16, &val);
> +       if (ret)
> +               return -EINVAL;
> +
> +       drvdata->stmheer = val;
> +       /* HW event enable and trigger go hand in hand */
> +       drvdata->stmheter = val;
> +
> +       return size;
> +}
> +static DEVICE_ATTR_RW(hwevent_enable);
> +
> +static ssize_t hwevent_select_show(struct device *dev,
> +                                  struct device_attribute *attr, char *buf)
> +{
> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +       unsigned long val = drvdata->stmhebsr;
> +
> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +
> +static ssize_t hwevent_select_store(struct device *dev,
> +                                   struct device_attribute *attr,
> +                                   const char *buf, size_t size)
> +{
> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +       unsigned long val;
> +       int ret = 0;
> +
> +       ret = kstrtoul(buf, 16, &val);
> +       if (ret)
> +               return -EINVAL;
> +
> +       drvdata->stmhebsr = val;
> +
> +       return size;
> +}
> +static DEVICE_ATTR_RW(hwevent_select);
> +
> +static ssize_t port_select_show(struct device *dev,
> +                               struct device_attribute *attr, char *buf)
> +{
> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +       unsigned long val;
> +
> +       if (!drvdata->enable) {
> +               val = drvdata->stmspscr;
> +       } else {
> +               spin_lock(&drvdata->spinlock);
> +               val = readl_relaxed(drvdata->base + STMSPSCR);
> +               spin_unlock(&drvdata->spinlock);
> +       }
> +
> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +
> +static ssize_t port_select_store(struct device *dev,
> +                                struct device_attribute *attr,
> +                                const char *buf, size_t size)
> +{
> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +       unsigned long val, stmsper;
> +       int ret = 0;
> +
> +       ret = kstrtoul(buf, 16, &val);
> +       if (ret)
> +               return ret;
> +
> +       spin_lock(&drvdata->spinlock);
> +       drvdata->stmspscr = val;
> +
> +       if (drvdata->enable) {
> +               CS_UNLOCK(drvdata->base);
> +               /* Process as per ARM's TRM recommendation */
> +               stmsper = readl_relaxed(drvdata->base + STMSPER);
> +               writel_relaxed(0x0, drvdata->base + STMSPER);
> +               writel_relaxed(drvdata->stmspscr, drvdata->base + STMSPSCR);
> +               writel_relaxed(stmsper, drvdata->base + STMSPER);
> +               CS_LOCK(drvdata->base);
> +       }
> +       spin_unlock(&drvdata->spinlock);
> +
> +       return size;
> +}
> +static DEVICE_ATTR_RW(port_select);
> +
> +static ssize_t port_enable_show(struct device *dev,
> +                               struct device_attribute *attr, char *buf)
> +{
> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +       unsigned long val;
> +
> +       if (!drvdata->enable) {
> +               val = drvdata->stmsper;
> +       } else {
> +               spin_lock(&drvdata->spinlock);
> +               val = readl_relaxed(drvdata->base + STMSPER);
> +               spin_unlock(&drvdata->spinlock);
> +       }
> +
> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
> +}
> +
> +static ssize_t port_enable_store(struct device *dev,
> +                                struct device_attribute *attr,
> +                                const char *buf, size_t size)
> +{
> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +       unsigned long val;
> +       int ret = 0;
> +
> +       ret = kstrtoul(buf, 16, &val);
> +       if (ret)
> +               return ret;
> +
> +       spin_lock(&drvdata->spinlock);
> +       drvdata->stmsper = val;
> +
> +       if (drvdata->enable) {
> +               CS_UNLOCK(drvdata->base);
> +               writel_relaxed(drvdata->stmsper, drvdata->base + STMSPER);
> +               CS_LOCK(drvdata->base);
> +       }
> +       spin_unlock(&drvdata->spinlock);
> +
> +       return size;
> +}
> +static DEVICE_ATTR_RW(port_enable);
> +
> +static ssize_t traceid_show(struct device *dev,
> +                           struct device_attribute *attr, char *buf)
> +{
> +       unsigned long val;
> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +
> +       val = drvdata->traceid;
> +       return sprintf(buf, "%#lx\n", val);
> +}
> +
> +static ssize_t traceid_store(struct device *dev,
> +                            struct device_attribute *attr,
> +                            const char *buf, size_t size)
> +{
> +       int ret;
> +       unsigned long val;
> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +
> +       ret = kstrtoul(buf, 16, &val);
> +       if (ret)
> +               return ret;
> +
> +       /* traceid field is 7bit wide on STM32 */
> +       drvdata->traceid = val & 0x7f;
> +       return size;
> +}
> +static DEVICE_ATTR_RW(traceid);
> +
> +#define coresight_simple_func(type, name, offset)                      \
> +static ssize_t name##_show(struct device *_dev,                                \
> +                          struct device_attribute *attr, char *buf)    \
> +{                                                                      \
> +       type *drvdata = dev_get_drvdata(_dev->parent);                  \
> +       return scnprintf(buf, PAGE_SIZE, "0x%08x\n",                    \
> +                        readl_relaxed(drvdata->base + offset));        \
> +}                                                                      \
> +DEVICE_ATTR_RO(name)
> +
> +#define coresight_stm_simple_func(name, offset)        \
> +       coresight_simple_func(struct stm_drvdata, name, offset)
> +
> +coresight_stm_simple_func(tcsr, STMTCSR);
> +coresight_stm_simple_func(tsfreqr, STMTSFREQR);
> +coresight_stm_simple_func(syncr, STMSYNCR);
> +coresight_stm_simple_func(sper, STMSPER);
> +coresight_stm_simple_func(spter, STMSPTER);
> +coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
> +coresight_stm_simple_func(spscr, STMSPSCR);
> +coresight_stm_simple_func(spmscr, STMSPMSCR);
> +coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
> +coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
> +coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
> +coresight_stm_simple_func(devid, CORESIGHT_DEVID);
> +
> +static struct attribute *coresight_stm_attrs[] = {
> +       &dev_attr_hwevent_enable.attr,
> +       &dev_attr_hwevent_select.attr,
> +       &dev_attr_port_enable.attr,
> +       &dev_attr_port_select.attr,
> +       &dev_attr_traceid.attr,
> +       NULL,
> +};
> +
> +static struct attribute *coresight_stm_mgmt_attrs[] = {
> +       &dev_attr_tcsr.attr,
> +       &dev_attr_tsfreqr.attr,
> +       &dev_attr_syncr.attr,
> +       &dev_attr_sper.attr,
> +       &dev_attr_spter.attr,
> +       &dev_attr_privmaskr.attr,
> +       &dev_attr_spscr.attr,
> +       &dev_attr_spmscr.attr,
> +       &dev_attr_spfeat1r.attr,
> +       &dev_attr_spfeat2r.attr,
> +       &dev_attr_spfeat3r.attr,
> +       &dev_attr_devid.attr,
> +       NULL,
> +};
> +
> +static const struct attribute_group coresight_stm_group = {
> +       .attrs = coresight_stm_attrs,
> +};
> +
> +static const struct attribute_group coresight_stm_mgmt_group = {
> +       .attrs = coresight_stm_mgmt_attrs,
> +       .name = "mgmt",
> +};
> +
> +static const struct attribute_group *coresight_stm_groups[] = {
> +       &coresight_stm_group,
> +       &coresight_stm_mgmt_group,
> +       NULL,
> +};
> +
> +static int stm_get_resource_byname(struct device_node *np,
> +                                  char *ch_base, struct resource *res)
> +{
> +       const char *name = NULL;
> +       int index = 0, found = 0;
> +
> +       while (!of_property_read_string_index(np, "reg-names", index, &name)) {
> +               if (strcmp(ch_base, name)) {
> +                       index++;
> +                       continue;
> +               }
> +
> +               /* We have a match and @index is where it's at */
> +               found = 1;
> +               break;
> +       }
> +
> +       if (!found)
> +               return -EINVAL;
> +
> +       return of_address_to_resource(np, index, res);
> +}
> +
> +static u32 stm_fundamental_data_size(struct stm_drvdata *drvdata)
> +{
> +       u32 stmspfeat2r;
> +
> +       stmspfeat2r = readl_relaxed(drvdata->base + STMSPFEAT2R);
> +       return BMVAL(stmspfeat2r, 12, 15);
> +}
> +
> +static u32 stm_num_stimulus_port(struct stm_drvdata *drvdata)
> +{
> +       u32 numsp;
> +
> +       numsp = readl_relaxed(drvdata->base + CORESIGHT_DEVID);
> +       /*
> +        * NUMPS in STMDEVID is 17 bit long and if equal to 0x0,
> +        * 32 stimulus ports are supported.
> +        */
> +       numsp &= 0x1ffff;
> +       if (!numsp)
> +               numsp = STM_32_CHANNEL;
> +       return numsp;
> +}
> +
> +static void stm_init_default_data(struct stm_drvdata *drvdata)
> +{
> +       /* Don't use port selection */
> +       drvdata->stmspscr = 0x0;
> +       /*
> +        * Enable all channel regardless of their number.  When port
> +        * selection isn't used (see above) STMSPER applies to all
> +        * 32 channel group available, hence setting all 32 bits to 1
> +        */
> +       drvdata->stmsper = ~0x0;
> +
> +       /*
> +        * Select arbitrary value to start with.  If there is a conflict
> +        * with other tracers the framework will deal with it.
> +        */
> +       drvdata->traceid = 0x20;
> +
> +       /* Set invariant transaction timing on all channels */
> +       bitmap_clear(drvdata->chs.guaranteed, 0, drvdata->numsp);
> +}
> +
> +static void stm_init_generic_data(struct stm_drvdata *drvdata)
> +{
> +       drvdata->stm.name = dev_name(drvdata->dev);
> +       drvdata->stm.mstatic = true;
> +       drvdata->stm.sw_nchannels = drvdata->numsp;
> +       drvdata->stm.packet = stm_generic_packet;
> +       drvdata->stm.link = stm_generic_link;
> +       drvdata->stm.unlink = stm_generic_unlink;
> +       drvdata->stm.set_options = stm_generic_set_options;
> +       drvdata->stm.get_options = stm_generic_get_options;
> +}
> +
> +static int stm_probe(struct amba_device *adev, const struct amba_id *id)
> +{
> +       int ret;
> +       void __iomem *base;
> +       unsigned long *guaranteed;
> +       struct device *dev = &adev->dev;
> +       struct coresight_platform_data *pdata = NULL;
> +       struct stm_drvdata *drvdata;
> +       struct resource *res = &adev->res;
> +       struct resource ch_res;
> +       size_t res_size, bitmap_size;
> +       struct coresight_desc *desc;
> +       struct device_node *np = adev->dev.of_node;
> +
> +       if (np) {
> +               pdata = of_get_coresight_platform_data(dev, np);
> +               if (IS_ERR(pdata))
> +                       return PTR_ERR(pdata);
> +               adev->dev.platform_data = pdata;
> +       }
> +       drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> +       if (!drvdata)
> +               return -ENOMEM;
> +
> +       drvdata->dev = &adev->dev;
> +       drvdata->atclk = devm_clk_get(&adev->dev, "atclk"); /* optional */
> +       if (!IS_ERR(drvdata->atclk)) {
> +               ret = clk_prepare_enable(drvdata->atclk);
> +               if (ret)
> +                       return ret;
> +       }
> +       dev_set_drvdata(dev, drvdata);
> +
> +       base = devm_ioremap_resource(dev, res);
> +       if (IS_ERR(base))
> +               return PTR_ERR(base);
> +       drvdata->base = base;
> +
> +       ret = stm_get_resource_byname(np, "stm-stimulus-base", &ch_res);
> +       if (ret)
> +               return ret;
> +
> +       base = devm_ioremap_resource(dev, &ch_res);
> +       if (IS_ERR(base))
> +               return PTR_ERR(base);
> +       drvdata->chs.base = base;
> +
> +       drvdata->write_max = sizeof(u32);

Isn't the fundamental data size the maximum an architecture can stand?
 Why not simply use that rather than adding another variable?

> +       drvdata->write_64bit = stm_fundamental_data_size(drvdata);
> +
> +#ifndef CONFIG_64BIT
> +       if (drvdata->write_64bit)
> +               drvdata->write_max = sizeof(u64);
> +#endif

In most cases the fundamental data size will follow the architecture
size, i.e, 32 bit architecture with 32 bit fundamental data size, 64
bit architecture with 64 bit fundamental data size.  A fundamental
data size of 32 is also possible on a 64 bit architecture.

What needs to be prevented is a 32 bit architecture with a fundamental
data size of 64.  In those cases the fundamental data size should be
adjusted to be 32 bit.  To do that I suggest to modify
stm_fundamental_data_size() to probe the STM's fundamental data size
but to adjust it down if on a 32 bit system.  Knowing whether running
on a 32/64 bit system is easy when using the IS_ENABLED() macro.

> +
> +       if (boot_nr_channel) {
> +               drvdata->numsp = boot_nr_channel;
> +               res_size = min((resource_size_t)(boot_nr_channel *
> +                                 BYTES_PER_CHANNEL), resource_size(res));
> +       } else {
> +               drvdata->numsp = stm_num_stimulus_port(drvdata);
> +               res_size = min((resource_size_t)(drvdata->numsp *
> +                                BYTES_PER_CHANNEL), resource_size(res));
> +       }
> +       bitmap_size = BITS_TO_LONGS(drvdata->numsp) * sizeof(long);
> +
> +       guaranteed = devm_kzalloc(dev, bitmap_size, GFP_KERNEL);
> +       if (!guaranteed)
> +               return -ENOMEM;
> +       drvdata->chs.guaranteed = guaranteed;
> +
> +       spin_lock_init(&drvdata->spinlock);
> +
> +       stm_init_default_data(drvdata);
> +       stm_init_generic_data(drvdata);
> +
> +       if (stm_register_device(dev, &drvdata->stm, THIS_MODULE)) {
> +               dev_info(dev,
> +                        "stm_register_device failed, probing deffered\n");
> +               return -EPROBE_DEFER;
> +       }
> +
> +       desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
> +       if (!desc) {
> +               ret = -ENOMEM;
> +               goto stm_unregister;
> +       }
> +
> +       desc->type = CORESIGHT_DEV_TYPE_SOURCE;
> +       desc->subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE;
> +       desc->ops = &stm_cs_ops;
> +       desc->pdata = pdata;
> +       desc->dev = dev;
> +       desc->groups = coresight_stm_groups;
> +       drvdata->csdev = coresight_register(desc);
> +       if (IS_ERR(drvdata->csdev)) {
> +               ret = PTR_ERR(drvdata->csdev);
> +               goto stm_unregister;
> +       }
> +
> +       pm_runtime_put(&adev->dev);
> +
> +       dev_info(dev, "%s initialized\n", (char *)id->data);
> +       return 0;
> +
> +stm_unregister:
> +       stm_unregister_device(&drvdata->stm);
> +       return ret;
> +}
> +
> +static int stm_remove(struct amba_device *adev)
> +{
> +       struct stm_drvdata *drvdata = amba_get_drvdata(adev);
> +
> +       stm_unregister_device(&drvdata->stm);
> +       coresight_unregister(drvdata->csdev);
> +       return 0;
> +}

The xyz_remove() functions is not needed for coresight devices -
unbinding a device from its driver will no longer be possible in the
4.6 cycle.

> +
> +#ifdef CONFIG_PM
> +static int stm_runtime_suspend(struct device *dev)
> +{
> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +       if (drvdata && !IS_ERR(drvdata->atclk))
> +               clk_disable_unprepare(drvdata->atclk);
> +
> +       return 0;
> +}
> +
> +static int stm_runtime_resume(struct device *dev)
> +{
> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev);
> +
> +       if (drvdata && !IS_ERR(drvdata->atclk))
> +               clk_prepare_enable(drvdata->atclk);
> +
> +       return 0;
> +}
> +#endif
> +
> +static const struct dev_pm_ops stm_dev_pm_ops = {
> +       SET_RUNTIME_PM_OPS(stm_runtime_suspend, stm_runtime_resume, NULL)
> +};
> +
> +static struct amba_id stm_ids[] = {
> +       {
> +               .id     = 0x0003b962,
> +               .mask   = 0x0003ffff,
> +               .data   = "STM32",
> +       },
> +       { 0, 0},
> +};
> +
> +static struct amba_driver stm_driver = {
> +       .drv = {
> +               .name   = "coresight-stm",
> +               .owner  = THIS_MODULE,
> +               .pm     = &stm_dev_pm_ops,
> +       },
> +       .probe          = stm_probe,
> +       .remove         = stm_remove,
> +       .id_table       = stm_ids,
> +};
> +
> +module_amba_driver(stm_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("CoreSight System Trace Macrocell driver");
> diff --git a/include/linux/coresight-stm.h b/include/linux/coresight-stm.h
> new file mode 100644
> index 0000000..a978bb8
> --- /dev/null
> +++ b/include/linux/coresight-stm.h
> @@ -0,0 +1,6 @@
> +#ifndef __LINUX_CORESIGHT_STM_H_
> +#define __LINUX_CORESIGHT_STM_H_
> +
> +#include <uapi/linux/coresight-stm.h>
> +
> +#endif
> diff --git a/include/uapi/linux/coresight-stm.h b/include/uapi/linux/coresight-stm.h
> new file mode 100644
> index 0000000..fa35f0b
> --- /dev/null
> +++ b/include/uapi/linux/coresight-stm.h
> @@ -0,0 +1,12 @@
> +#ifndef __UAPI_CORESIGHT_STM_H_
> +#define __UAPI_CORESIGHT_STM_H_
> +
> +#define STM_FLAG_TIMESTAMPED   BIT(3)
> +#define STM_FLAG_GUARANTEED    BIT(7)
> +
> +enum {
> +       STM_OPTION_GUARANTEED = 0,
> +       STM_OPTION_INVARIANT,
> +};
> +
> +#endif
> --
> 1.9.1
>


From robh at kernel.org  Thu Feb 11 09:04:57 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 11 Feb 2016 11:04:57 -0600
Subject: [PATCH v3 1/4] dt-bindings: power: reset: add document for
 reboot-mode driver
In-Reply-To: <CALAqxLUnbFHjTuJXYXSruV3W0JJ09Fxz=KBe69tZDTd_3_+rxw@mail.gmail.com>
References: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
 <1454407151-4751-1-git-send-email-andy.yan@rock-chips.com>
 <20160204230814.GA4847@rob-hp-laptop>
 <CALAqxLVyznpLd2MLgGr28TDECpLZ=RpmhxH-SHqntXfBsctcmQ@mail.gmail.com>
 <20160205043507.GB4847@rob-hp-laptop>
 <CALAqxLUnbFHjTuJXYXSruV3W0JJ09Fxz=KBe69tZDTd_3_+rxw@mail.gmail.com>
Message-ID: <20160211170457.GA19851@rob-hp-laptop>

On Thu, Feb 04, 2016 at 09:03:44PM -0800, John Stultz wrote:
> On Thu, Feb 4, 2016 at 8:35 PM, Rob Herring <robh at kernel.org> wrote:
> > On Thu, Feb 04, 2016 at 03:46:15PM -0800, John Stultz wrote:
> >> On Thu, Feb 4, 2016 at 3:08 PM, Rob Herring <robh at kernel.org> wrote:
> >> > On Tue, Feb 02, 2016 at 05:59:11PM +0800, Andy Yan wrote:
> >> >> +Example:
> >> >> +     reboot-mode {
> >> >> +             mode-normal = <BOOT_NORMAL>;
> >> >> +             mode-recovery = <BOOT_RECOVERY>;
> >> >> +             mode-fastboot = <BOOT_FASTBOOT>;
> >> >
> >> > I tend to agree with John on calling this mode-bootloader.
> >> >
> >> > OTOH, fastboot is more specific about what the mode is. The name in DT
> >> > and the userspace name don't necessarily have to be the same.
> >>
> >> Wait. This is a bit confusing. The utility of adding a property name
> >> and using that name be the reboot command parsed for made sense
> >> (compared to earlier versions which had command strings) as it made
> >> the dts more terse.   But it sounds here like you're suggesting we
> >> should have some logic in the driver that translates "reboot fastboot"
> >> to mode-bootloader or vice versa.
> >
> > I said early on the DT names and kernel-userspace names should not
> > necessarily be linked. They can be, but we shouldn't require that.
> 
> Sigh. Ok. It seemed it was due to earlier comments (maybe from others,
> but I thought it was you), that we moved from specifying a command
> string, to using the label. But if you think the label name and the
> commands shouldn't be linked, it seems like we should re-introduce
> that. No?
> 
> Unless your thinking we need some sort of static in-kernel mapping of
> commands to label names? But that just seems painfully indirect for
> little gain ("Its obvious! For that mode, you use this term here, and
> that different term over there!").

Tying it to a Linux ABI makes the binding Linux specific. I don't have a 
problem that the strings happen to be the same, but we should have some 
understanding that they may not be and allow for that.

> > My concern with mode-bootloader is what if you can boot into multiple
> > bootloader modes. Say USB mass storage is one option. "bootloader" is
> > not real specific.
> 
> True. But as I think we agreed below, "bootloader" and "recovery" are
> basically defacto standards, and I think it would be a bad idea to try
> to declare all the existing android tooling and docs wrong just
> because the command is vague, technically.

Okay, as long as they are clearly documented what they mean.


> >> >> +             mode-loader = <BOOT_LOADER>;
> >> >
> >> > This one needs a better name. Maybe it should be 'rockchip,mode-loader'
> >> > as it is vendor specific. Either way, loader is vague. Perhaps
> >> > rockchip,mode-bl-download?
> >>
> >> Hrm. So how what reboot command do you expect to trigger that?
> >
> > Whatever your OS has defined to map to that.
> >
> > We could just decide the kernel will strip <vendor> and 'mode-' and
> > match commands against what remains.
> 
> That part sounds sane, although I do think having vendor prefixes are
> reasonable for actual commands as well.

Well, you could still have "rockchip,mode-rockchip-bl-download"... 

We can bikeshed that when get there.

The other way random custom modes could be done is just allow the raw 
value to be passed from userspace converting the string to a number. 
Then we have no abstraction rather than half way abstracting it.

> >> I think one of the difficult things here is that there's no real
> >> standards for all bios/bootloader modes. So they are somewhat
> >> firmware/bootloader/device specific, and thus we need something that
> >> is flexible enough to allow lots of different modes to be easily
> >> specified.  That said, this does expose a userspace interface (though
> >> one could argue kernel ABI doesn't cross reboots :) so we should try
> >> to have some consistency so the same userspace can work on various
> >> devices.
> >
> > There is: UEFI. Boot mode efivars are standard. But then they are pretty
> > much PC oriented though. It is more which device to boot off of, but
> > there is network boot or boot to bios setup.
> 
> Well, there's a partial standard there.  I'm told for android on x86,
> there is no UEFI standard way to communicate rebooting to fastboot or
> recovery. Every device does its own device specific driver.

So much for standards. However, while these specific modes have not been 
standardized, there is a set of standard modes and these could have been 
added to the existing mechanism. So there at least exists some model to 
draw inspiration from.

Rob


From maxime.ripard at free-electrons.com  Thu Feb 11 09:08:20 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 11 Feb 2016 18:08:20 +0100
Subject: breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi:
 Refactor A31 PLL6 so that it can be reused)
In-Reply-To: <20160211114410.GA32535@leverpostej>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <56BB2D79.6090402@arm.com>
 <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
 <20160210143755.GE31506@lukather>
 <20160210163001.GG2632@leverpostej>
 <20160211100048.GK31506@lukather>
 <20160211114410.GA32535@leverpostej>
Message-ID: <20160211170820.GP31506@lukather>

On Thu, Feb 11, 2016 at 11:44:10AM +0000, Mark Rutland wrote:
> On Thu, Feb 11, 2016 at 11:00:48AM +0100, Maxime Ripard wrote:
> > On Wed, Feb 10, 2016 at 04:30:01PM +0000, Mark Rutland wrote:
> > > On Wed, Feb 10, 2016 at 03:37:55PM +0100, Maxime Ripard wrote:
> > > > Hi Rob,
> > > > 
> > > > On Wed, Feb 10, 2016 at 07:42:02AM -0600, Rob Herring wrote:
> > > > > On Wed, Feb 10, 2016 at 6:30 AM, Andre Przywara <andre.przywara at arm.com> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > just a ping:
> > > > > >
> > > > > > Are we really OK with breaking existing DTs in 4.6? (per the code in
> > > > > > -next: f7d372ba54ea04d528a291b8dbe34716507bb60b, which is this patch).
> > > > > 
> > > > > I only warn and make sure people are aware of the issue. I leave that
> > > > > up to platform maintainers to decide. It depends on the maturity of
> > > > > the platform and users.
> > > > 
> > > > The impacted SoCs support is really partial. For the most supported
> > > > one, big things like display or sound are totally missing, and we
> > > > still update them on a regular basis to add support for new
> > > > devices. As such, users are very likely to upgrade the DT from one
> > > > version to another just because there's new devices available to
> > > > them. And the newest SoC impacted just got introduced in 4.5, and only
> > > > has the UART and MMC devices available.
> > > > 
> > > > > If people complain about it then it's their mess. For platforms
> > > > > supported in distros such as debian or fedora, I would strongly
> > > > > recommend against breaking compatibility.
> > > > 
> > > > None of them are officially supported:
> > > > https://www.debian.org/releases/stable/armhf/ch02s01.html.en
> > > > https://fedoraproject.org/wiki/Architectures/ARM#Fedora_23
> > > > 
> > > > Only the older one are, and they are not affected by this patch.
> > > > 
> > > > > They do ship dtbs, but it's a chicken and egg problem. If dtbs were
> > > > > stable and provided by firmware, then they wouldn't have to provide
> > > > > them. If dtbs are unstable, then they have no choice.
> > > > 
> > > > And while it might work great on platforms that have all the needed
> > > > documentation, or a perfect one, which is our case. Almost each
> > > > release, we discover that something is not working as it was
> > > > documented, when it was documented in the first place.
> > > > 
> > > > It also seems that even on well documented platforms, supported by the
> > > > vendors, the stable ABI dream is not going to happen:
> > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Atmel/README#n105
> > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/arm/marvell,berlin.txt#n4
> > > 
> > > To be quite frank, I completely disagree with that stance.
> > > 
> > > It seems like the only reason DT bindings aren't remaining stable is
> > > because people are deliberately ignoring the requirement and reasoning
> > > for doing so.
> > 
> > And for DT maintainers saying on multiple occasions that it's bad but
> > ok to break it and / or that they never actually said that it was a
> > stable ABI...
> 
> Evidently there is a communication failure. Generally, the statement has
> been that old DTBs should continue to work. That's even documented, as
> Andre pointed out:
> 
> Documentation/devicetree/bindings/ABI.txt
> 
> There are obviously shades of grey, and _rarely_ it might be necessary
> to deliberately break a binding. However, that should be the rare
> last-resort case, rather than a crutch for development.
> 
> Saying "bad but ok" underplays the "bad" and overplays the "ok".

Not all of the DT maintainers have the same position I'm afraid.

> > I'm guessing it could be a stable ABI if there was bindings
> > reviews. Rob actually started to review a significant amount of
> > bindings lately, and that's really appreciated, but if you don't
> > review all the bindings, then we're going to make mistakes.
> 
> I agree that it is unfortunate that we cannot provide the level of
> review that we want to.
> 
> Mistakes will happen even with review; that doesn't necessitate removing
> support for a binding.

Yet they will be much more likely to be made if no review is made.

> > > I agree that it can be painful, and that we cannot predict the future.
> > > There will always be bugs.
> > 
> > In our case, we can't even predict the present.
> > 
> > > Having code in mainline comes with responsibilities. One of those is to
> > > keep said code working for existing users. Otherwise, why bother having
> > > it in mainline at all?
> > 
> > None of our existing users ever complained.
> 
> I believe that in this case, Andre was complaining about this particular
> breakage, unless I have misunderstood.
> 
> To be clear, I'm arguing for the strategy going forward. If no-one has
> complained about the stuff broken up to this point, let's not waste time
> restoring that.
> 
> Going forward we need to keep old DTBs supported.

I find that stand a bit dishonest.

You, DT maintainers, admit that you're not doing your job properly,
and that burden relies on the platform maintainers? Or should I take
it as you volunteering to maintain that code?

But ok. Let's do that. Make sure that the other platform maintainers
are aware that this is the rule too though. I surely don't want to be
alone in that boat.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/4d5b25cc/attachment.sig>

From jens.wiklander at linaro.org  Thu Feb 11 09:14:33 2016
From: jens.wiklander at linaro.org (Jens Wiklander)
Date: Thu, 11 Feb 2016 18:14:33 +0100
Subject: [PATCH v8 0/4] generic TEE subsystem
Message-ID: <1455210877-15748-1-git-send-email-jens.wiklander@linaro.org>

Hi,

This patch set introduces a generic TEE subsystem. The TEE subsystem will
contain drivers for various TEE implementations. A TEE (Trusted Execution
Environment) is a trusted OS running in some secure environment, for
example, TrustZone on ARM CPUs, or a separate secure co-processor etc.

Regarding use cases, TrustZone has traditionally been used for
offloading secure tasks to the secure world. Examples include: 
- Secure key handling where the OS may or may not have direct access to key
  material.
- E-commerce and payment technologies. Credentials, credit card numbers etc
  could be stored in a more secure environment.
- Trusted User Interface (TUI) to ensure that no-one can snoop PIN-codes
  etc.
- Secure boot to ensure that loaded binaries haven?t been tampered with.
  It?s not strictly needed for secure boot, but you could enhance security
  by leveraging a TEE during boot.
- Digital Rights Management (DRM), the studios provides content with
  different resolution depending on the security of the device. Higher
  security means higher resolution.

A TEE could also be used in existing and new technologies. For example IMA
(Integrity Measurement Architecture) which has been in the kernel for quite
a while. Today you can enhance security by using a TPM-chip to sign the IMA
measurement list. This is something that you also could do by leveraging a
TEE.

Another example could be in 2-factor authentication which is becoming
increasingly more important. FIDO (https://fidoalliance.org) for example
are using public key cryptography in their 2-factor authentication standard
(U2F). With FIDO, a private and public key pair will be generated for every
site you visit and the private key should never leave the local device.
This is an example where you could use secure storage in a TEE for the
private key.

Today you will find a quite a few different out of tree implementations of
TEE drivers which tends to fragment the TEE ecosystem and development. We
think it would be a good idea to have a generic TEE driver integrated in
the kernel which would serve as a base for several different TEE solutions,
no matter if they are on-chip like TrustZone or if they are on a separate
crypto co-processor.

To develop this TEE subsystem we have been using the open source TEE called
OP-TEE (https://github.com/OP-TEE/optee_os) and therefore this would be the
first TEE solution supported by this new subsystem. OP-TEE is a
GlobalPlatform compliant TEE, however this TEE subsystem is not limited to
only GlobalPlatform TEEs, instead we have tried to design it so that it
should work with other TEE solutions also.

"tee: generic TEE subsystem" brings in the generic TEE subsystem which
helps when writing a driver for a specific TEE, for example, OP-TEE.

"tee: add OP-TEE driver" is an OP-TEE driver which uses the subsystem to do
its work.

This patch set has been prepared in cooperation with Javier Gonz?lez who
proposed "Generic TrustZone Driver in Linux Kernel" patches 28 Nov 2014,
https://lwn.net/Articles/623380/ . We've since then changed the scope to
TEE instead of TrustZone.

We have discussed the design on tee-dev at lists.linaro.org (archive at
https://lists.linaro.org/pipermail/tee-dev/) with people from other
companies, including Valentin Manea <valentin.manea at huawei.com>,
Emmanuel MICHEL <emmanuel.michel at st.com>,
Jean-michel DELORME <jean-michel.delorme at st.com>,
and Joakim Bech <joakim.bech at linaro.org>. Our main concern has been to
agree on something that is generic enough to support many different
TEEs while still keeping the interface together.

v8:
* Rebased on v4.5-rc3
* dt/bindings: add bindings for optee
  Acked-by: Rob Herring <robh at kernel.org>
* Fixes build error for X86
* Fixes spell error in "dt/bindings: add bindings for optee"

v7:
* Rebased on v4.5-rc2
* Moved the ARM SMC Calling Convention support into a separate patch
  set, which is now merged

v6:
* Rebased on v4.3-rc7
* Changed smccc interface to let the compiler marshal most of the
  parameters
* Added ARCH64 capability for smccc interface
* Changed the PSCI firmware calls (both arm and arm64) to use the new
  generic smccc interface instead instead of own assembly functions.
* Move optee DT bindings to below arm/firmware
* Defines method for OP-TEE driver to call secure world in DT, smc or hvc
* Exposes implementation id of a TEE driver in sysfs
  to easily spawn corresponding tee-supplicant when device is ready
* Update OP-TEE Message Protocol to better cope with fragmented physical
  memory
* Read time directly from OP-TEE driver instead of forwarding the RPC
  request to tee-supplicant

v5:
* Replaced kref reference counting for the device with a size_t instead as
  the counter is always protected by a mutex

v4:
* Rebased on 4.1
* Redesigned the synchronization around entry exit of normal SMC
* Replaced rwsem on the driver instance with kref and completion since
  rwsem wasn't intended to be used in this way
* Expanded the TEE_IOCTL_PARAM_ATTR_TYPE_MASK to make room for
  future additional parameter types
* Documents TEE subsystem and OP-TEE driver
* Replaced TEE_IOC_CMD with TEE_IOC_OPEN_SESSION, TEE_IOC_INVOKE,
  TEE_IOC_CANCEL and TEE_IOC_CLOSE_SESSION
* DT bindings in a separate patch
* Assembly parts moved to arch/arm and arch/arm64 respectively, in a
  separate patch
* Redefined/clarified the meaning of OPTEE_SMC_SHM_CACHED
* Removed CMA usage to limit the scope of the patch set

v3:
* Rebased on 4.1-rc3 (dma_buf_export() API change)
* A couple of small sparse fixes
* Documents bindings for OP-TEE driver
* Updated MAINTAINERS

v2:
* Replaced the stubbed OP-TEE driver with a real OP-TEE driver
* Removed most APIs not needed by OP-TEE in current state
* Update Documentation/ioctl/ioctl-number.txt with correct path to tee.h
* Rename tee_shm_pool_alloc_cma() to tee_shm_pool_alloc()
* Moved tee.h into include/uapi/linux/
* Redefined tee.h IOCTL macros to be directly based on _IOR and friends
* Removed version info on the API to user space, a data blob which
  can contain an UUID is left for user space to be able to tell which
  protocol to use in TEE_IOC_CMD
* Changed user space exposed structures to only have types with __ prefix
* Dropped THIS_MODULE from tee_fops
* Reworked how the driver is registered and ref counted:
  - moved from using an embedded struct miscdevice to an embedded struct
    device.
  - uses an struct rw_semaphore as synchronization for driver detachment
  - uses alloc/register pattern from TPM

Thanks,
Jens



Jens Wiklander (4):
  dt/bindings: add bindings for optee
  tee: generic TEE subsystem
  tee: add OP-TEE driver
  Documentation: tee subsystem and op-tee driver

 Documentation/00-INDEX                             |   2 +
 .../bindings/arm/firmware/linaro,optee-tz.txt      |  31 +
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 Documentation/ioctl/ioctl-number.txt               |   1 +
 Documentation/tee.txt                              | 117 +++
 MAINTAINERS                                        |  13 +
 drivers/Kconfig                                    |   2 +
 drivers/Makefile                                   |   1 +
 drivers/tee/Kconfig                                |  19 +
 drivers/tee/Makefile                               |   4 +
 drivers/tee/optee/Kconfig                          |   8 +
 drivers/tee/optee/Makefile                         |   5 +
 drivers/tee/optee/call.c                           | 400 ++++++++++
 drivers/tee/optee/core.c                           | 522 ++++++++++++
 drivers/tee/optee/optee_msg.h                      | 423 ++++++++++
 drivers/tee/optee/optee_private.h                  | 146 ++++
 drivers/tee/optee/optee_smc.h                      | 418 ++++++++++
 drivers/tee/optee/rpc.c                            | 322 ++++++++
 drivers/tee/optee/supp.c                           | 212 +++++
 drivers/tee/tee.c                                  | 873 +++++++++++++++++++++
 drivers/tee/tee_private.h                          |  80 ++
 drivers/tee/tee_shm.c                              | 324 ++++++++
 drivers/tee/tee_shm_pool.c                         | 133 ++++
 include/linux/tee_drv.h                            | 299 +++++++
 include/uapi/linux/tee.h                           | 383 +++++++++
 25 files changed, 4739 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
 create mode 100644 Documentation/tee.txt
 create mode 100644 drivers/tee/Kconfig
 create mode 100644 drivers/tee/Makefile
 create mode 100644 drivers/tee/optee/Kconfig
 create mode 100644 drivers/tee/optee/Makefile
 create mode 100644 drivers/tee/optee/call.c
 create mode 100644 drivers/tee/optee/core.c
 create mode 100644 drivers/tee/optee/optee_msg.h
 create mode 100644 drivers/tee/optee/optee_private.h
 create mode 100644 drivers/tee/optee/optee_smc.h
 create mode 100644 drivers/tee/optee/rpc.c
 create mode 100644 drivers/tee/optee/supp.c
 create mode 100644 drivers/tee/tee.c
 create mode 100644 drivers/tee/tee_private.h
 create mode 100644 drivers/tee/tee_shm.c
 create mode 100644 drivers/tee/tee_shm_pool.c
 create mode 100644 include/linux/tee_drv.h
 create mode 100644 include/uapi/linux/tee.h

-- 
1.9.1



From jens.wiklander at linaro.org  Thu Feb 11 09:14:34 2016
From: jens.wiklander at linaro.org (Jens Wiklander)
Date: Thu, 11 Feb 2016 18:14:34 +0100
Subject: [PATCH v8 1/4] dt/bindings: add bindings for optee
In-Reply-To: <1455210877-15748-1-git-send-email-jens.wiklander@linaro.org>
References: <1455210877-15748-1-git-send-email-jens.wiklander@linaro.org>
Message-ID: <1455210877-15748-2-git-send-email-jens.wiklander@linaro.org>

Introduces linaro prefix and adds bindings for ARM TrustZone based OP-TEE
implementation.

Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Jens Wiklander <jens.wiklander at linaro.org>
---
 .../bindings/arm/firmware/linaro,optee-tz.txt      | 31 ++++++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.txt        |  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt

diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
new file mode 100644
index 0000000..d38834c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
@@ -0,0 +1,31 @@
+OP-TEE Device Tree Bindings
+
+OP-TEE is a piece of software using hardware features to provide a Trusted
+Execution Environment. The security can be provided with ARM TrustZone, but
+also by virtualization or a separate chip.
+
+We're using "linaro" as the first part of the compatible property for
+the reference implementation maintained by Linaro.
+
+* OP-TEE based on ARM TrustZone required properties:
+
+- compatible     : should contain "linaro,optee-tz"
+
+- method         : The method of calling the OP-TEE Trusted OS. Permitted
+                   values are:
+
+                   "smc" : SMC #0, with the register assignments specified
+		           in drivers/tee/optee/optee_smc.h
+
+                   "hvc" : HVC #0, with the register assignments specified
+		           in drivers/tee/optee/optee_smc.h
+
+
+
+Example:
+	firmware {
+		optee {
+			compatible = "linaro,optee-tz";
+			method = "smc";
+		};
+	};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 72e2c5a..0c1e2f2 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -130,6 +130,7 @@ lacie	LaCie
 lantiq	Lantiq Semiconductor
 lenovo	Lenovo Group Ltd.
 lg	LG Corporation
+linaro	Linaro Limited
 linux	Linux-specific binding
 lsi	LSI Corp. (LSI Logic)
 lltc	Linear Technology Corporation
-- 
1.9.1



From jens.wiklander at linaro.org  Thu Feb 11 09:14:35 2016
From: jens.wiklander at linaro.org (Jens Wiklander)
Date: Thu, 11 Feb 2016 18:14:35 +0100
Subject: [PATCH v8 2/4] tee: generic TEE subsystem
In-Reply-To: <1455210877-15748-1-git-send-email-jens.wiklander@linaro.org>
References: <1455210877-15748-1-git-send-email-jens.wiklander@linaro.org>
Message-ID: <1455210877-15748-3-git-send-email-jens.wiklander@linaro.org>

Initial patch for generic TEE subsystem.
This subsystem provides:
* Registration/un-registration of TEE drivers.
* Shared memory between normal world and secure world.
* Ioctl interface for interaction with user space.
* Sysfs implementation_id of TEE driver

A TEE (Trusted Execution Environment) driver is a driver that interfaces
with a trusted OS running in some secure environment, for example,
TrustZone on ARM cpus, or a separate secure co-processor etc.

The TEE subsystem can serve a TEE driver for a Global Platform compliant
TEE, but it's not limited to only Global Platform TEEs.

This patch builds on other similar implementations trying to solve
the same problem:
* "optee_linuxdriver" by among others
  Jean-michel DELORME<jean-michel.delorme at st.com> and
  Emmanuel MICHEL <emmanuel.michel at st.com>
* "Generic TrustZone Driver" by Javier Gonz?lez <javier at javigon.com>

Signed-off-by: Jens Wiklander <jens.wiklander at linaro.org>
---
 Documentation/ioctl/ioctl-number.txt |   1 +
 MAINTAINERS                          |   7 +
 drivers/Kconfig                      |   2 +
 drivers/Makefile                     |   1 +
 drivers/tee/Kconfig                  |   9 +
 drivers/tee/Makefile                 |   3 +
 drivers/tee/tee.c                    | 873 +++++++++++++++++++++++++++++++++++
 drivers/tee/tee_private.h            |  80 ++++
 drivers/tee/tee_shm.c                | 324 +++++++++++++
 drivers/tee/tee_shm_pool.c           | 133 ++++++
 include/linux/tee_drv.h              | 299 ++++++++++++
 include/uapi/linux/tee.h             | 383 +++++++++++++++
 12 files changed, 2115 insertions(+)
 create mode 100644 drivers/tee/Kconfig
 create mode 100644 drivers/tee/Makefile
 create mode 100644 drivers/tee/tee.c
 create mode 100644 drivers/tee/tee_private.h
 create mode 100644 drivers/tee/tee_shm.c
 create mode 100644 drivers/tee/tee_shm_pool.c
 create mode 100644 include/linux/tee_drv.h
 create mode 100644 include/uapi/linux/tee.h

diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 91261a3..b5ce7b6 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -307,6 +307,7 @@ Code  Seq#(hex)	Include File		Comments
 0xA3	80-8F	Port ACL		in development:
 					<mailto:tlewis at mindspring.com>
 0xA3	90-9F	linux/dtlk.h
+0xA4	00-1F	uapi/linux/tee.h	Generic TEE subsystem
 0xAA	00-3F	linux/uapi/linux/userfaultfd.h
 0xAB	00-1F	linux/nbd.h
 0xAC	00-1F	linux/raw.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 7f1fa4f..b2bae0e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9561,6 +9561,13 @@ F:	drivers/hwtracing/stm/
 F:	include/linux/stm.h
 F:	include/uapi/linux/stm.h
 
+TEE SUBSYSTEM
+M:	Jens Wiklander <jens.wiklander at linaro.org>
+S:	Maintained
+F:	include/linux/tee_drv.h
+F:	include/uapi/linux/tee.h
+F:	drivers/tee/
+
 THUNDERBOLT DRIVER
 M:	Andreas Noever <andreas.noever at gmail.com>
 S:	Maintained
diff --git a/drivers/Kconfig b/drivers/Kconfig
index d2ac339..63baceb 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -198,4 +198,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
 
 source "drivers/fpga/Kconfig"
 
+source "drivers/tee/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 8f5d076..231b409 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -172,3 +172,4 @@ obj-$(CONFIG_STM)		+= hwtracing/stm/
 obj-$(CONFIG_ANDROID)		+= android/
 obj-$(CONFIG_NVMEM)		+= nvmem/
 obj-$(CONFIG_FPGA)		+= fpga/
+obj-$(CONFIG_TEE)		+= tee/
diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
new file mode 100644
index 0000000..f3ba154
--- /dev/null
+++ b/drivers/tee/Kconfig
@@ -0,0 +1,9 @@
+# Generic Trusted Execution Environment Configuration
+config TEE
+	bool "Trusted Execution Environment support"
+	default n
+	select DMA_SHARED_BUFFER
+	select GENERIC_ALLOCATOR
+	help
+	  This implements a generic interface towards a Trusted Execution
+	  Environment (TEE).
diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
new file mode 100644
index 0000000..60d2dab
--- /dev/null
+++ b/drivers/tee/Makefile
@@ -0,0 +1,3 @@
+obj-y += tee.o
+obj-y += tee_shm.o
+obj-y += tee_shm_pool.o
diff --git a/drivers/tee/tee.c b/drivers/tee/tee.c
new file mode 100644
index 0000000..b8a1c76
--- /dev/null
+++ b/drivers/tee/tee.c
@@ -0,0 +1,873 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/device.h>
+#include <linux/cdev.h>
+#include <linux/fs.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <linux/tee_drv.h>
+#include "tee_private.h"
+
+#define TEE_NUM_DEVICES	32
+
+#define TEE_IOCTL_PARAM_SIZE(x) (sizeof(struct tee_param) * (x))
+
+/*
+ * Unprivileged devices in the in the lower half range and privileged
+ * devices in the upper half range.
+ */
+static DECLARE_BITMAP(dev_mask, TEE_NUM_DEVICES);
+static DEFINE_SPINLOCK(driver_lock);
+
+static struct class *tee_class;
+static dev_t tee_devt;
+
+static int tee_open(struct inode *inode, struct file *filp)
+{
+	int rc;
+	struct tee_device *teedev;
+	struct tee_context *ctx;
+
+	teedev = container_of(inode->i_cdev, struct tee_device, cdev);
+	if (!tee_device_get(teedev))
+		return -EINVAL;
+
+	ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+	if (!ctx) {
+		rc = -ENOMEM;
+		goto err;
+	}
+
+	ctx->teedev = teedev;
+	filp->private_data = ctx;
+	rc = teedev->desc->ops->open(ctx);
+	if (rc)
+		goto err;
+
+	return 0;
+err:
+	kfree(ctx);
+	tee_device_put(teedev);
+	return rc;
+}
+
+static int tee_release(struct inode *inode, struct file *filp)
+{
+	struct tee_context *ctx = filp->private_data;
+	struct tee_device *teedev = ctx->teedev;
+
+	ctx->teedev->desc->ops->release(ctx);
+	kfree(ctx);
+	tee_device_put(teedev);
+	return 0;
+}
+
+static int tee_ioctl_version(struct tee_context *ctx,
+		struct tee_ioctl_version_data __user *uvers)
+{
+	struct tee_ioctl_version_data vers;
+
+	ctx->teedev->desc->ops->get_version(ctx->teedev, &vers);
+	if (copy_to_user(uvers, &vers, sizeof(vers)))
+		return -EFAULT;
+	return 0;
+}
+
+static int tee_ioctl_shm_alloc(struct tee_context *ctx,
+		struct tee_ioctl_shm_alloc_data __user *udata)
+{
+	long ret;
+	struct tee_ioctl_shm_alloc_data data;
+	struct tee_shm *shm;
+
+	if (copy_from_user(&data, udata, sizeof(data)))
+		return -EFAULT;
+
+	/* Currently no input flags are supported */
+	if (data.flags)
+		return -EINVAL;
+
+	data.fd = -1;
+
+	shm = tee_shm_alloc(ctx->teedev, data.size,
+			    TEE_SHM_MAPPED | TEE_SHM_DMA_BUF);
+	if (IS_ERR(shm))
+		return PTR_ERR(shm);
+
+	data.flags = shm->flags;
+	data.size = shm->size;
+	data.fd = tee_shm_get_fd(shm);
+	if (data.fd < 0) {
+		ret = data.fd;
+		goto err;
+	}
+
+	if (copy_to_user(udata, &data, sizeof(data))) {
+		ret = -EFAULT;
+		goto err;
+	}
+	/*
+	 * When user space closes the file descriptor the shared memory
+	 * should be freed
+	 */
+	tee_shm_put(shm);
+	return 0;
+err:
+	if (data.fd >= 0)
+		tee_shm_put_fd(data.fd);
+	tee_shm_free(shm);
+	return ret;
+}
+
+static int params_from_user(struct tee_param *params, size_t num_params,
+		struct tee_ioctl_param __user *uparams)
+{
+	size_t n;
+
+	for (n = 0; n < num_params; n++) {
+		struct tee_shm *shm;
+		struct tee_ioctl_param ip;
+
+		if (copy_from_user(&ip, uparams + n, sizeof(ip)))
+			return -EFAULT;
+
+		/* All unused attribute bits has to be zero */
+		if (ip.attr & ~TEE_IOCTL_PARAM_ATTR_TYPE_MASK)
+			return -EINVAL;
+
+		params[n].attr = ip.attr;
+		switch (ip.attr) {
+		case TEE_IOCTL_PARAM_ATTR_TYPE_NONE:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT:
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT:
+			params[n].u.value.a = ip.u.value.a;
+			params[n].u.value.b = ip.u.value.b;
+			params[n].u.value.c = ip.u.value.c;
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT:
+			/*
+			 * If we fail to get a pointer to a shared memory
+			 * object (and increase the ref count) from a file
+			 * descriptor we return an error. All pointers that
+			 * has been added in params have an increased ref
+			 * count. It's the callers responibility to do
+			 * tee_shm_put() on all resolved pointers.
+			 */
+			shm = tee_shm_get_from_fd(ip.u.memref.shm_fd);
+			if (IS_ERR(shm))
+				return PTR_ERR(shm);
+
+			params[n].u.memref.shm_offs = ip.u.memref.shm_offs;
+			params[n].u.memref.size = ip.u.memref.size;
+			params[n].u.memref.shm = shm;
+			break;
+		default:
+			/* Unknown attribute */
+			return -EINVAL;
+		}
+	}
+	return 0;
+}
+
+static int params_to_user(struct tee_ioctl_param __user *uparams,
+		size_t num_params, struct tee_param *params)
+{
+	size_t n;
+
+	for (n = 0; n < num_params; n++) {
+		struct tee_ioctl_param __user *up = uparams + n;
+		struct tee_param *p = params + n;
+
+		switch (p->attr) {
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT:
+			if (put_user(p->u.value.a, &up->u.value.a) ||
+			    put_user(p->u.value.b, &up->u.value.b) ||
+			    put_user(p->u.value.c, &up->u.value.c))
+				return -EFAULT;
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT:
+			if (put_user((u64)p->u.memref.size, &up->u.memref.size))
+				return -EFAULT;
+		default:
+			break;
+		}
+	}
+	return 0;
+}
+
+static bool param_is_memref(struct tee_param *param)
+{
+	switch (param->attr & TEE_IOCTL_PARAM_ATTR_TYPE_MASK) {
+	case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT:
+	case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT:
+	case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static int tee_ioctl_open_session(struct tee_context *ctx,
+		struct tee_ioctl_buf_data __user *ubuf)
+{
+	int rc;
+	size_t n;
+	struct tee_ioctl_buf_data buf;
+	struct tee_ioctl_open_session_arg __user *uarg;
+	struct tee_ioctl_open_session_arg arg;
+	struct tee_ioctl_param __user *uparams = NULL;
+	struct tee_param *params = NULL;
+	bool have_session = false;
+
+	if (!ctx->teedev->desc->ops->open_session)
+		return -EINVAL;
+
+	if (copy_from_user(&buf, ubuf, sizeof(buf)))
+		return -EFAULT;
+
+	if (buf.buf_len > TEE_MAX_ARG_SIZE ||
+	    buf.buf_len < sizeof(struct tee_ioctl_open_session_arg))
+		return -EINVAL;
+
+	uarg = (struct tee_ioctl_open_session_arg __user *)(unsigned long)
+		buf.buf_ptr;
+	rc = copy_from_user(&arg, uarg, sizeof(arg));
+	if (rc)
+		return rc;
+
+	if (sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len)
+		return -EINVAL;
+
+	if (arg.num_params) {
+		params = kcalloc(arg.num_params, sizeof(struct tee_param),
+				GFP_KERNEL);
+		if (!params)
+			return -ENOMEM;
+		uparams = (struct tee_ioctl_param __user *)(uarg + 1);
+		rc = params_from_user(params, arg.num_params, uparams);
+		if (rc)
+			goto out;
+	}
+
+	rc = ctx->teedev->desc->ops->open_session(ctx, &arg, params);
+	if (rc)
+		goto out;
+	have_session = true;
+
+	if (put_user(arg.session, &uarg->session) ||
+	    put_user(arg.ret, &uarg->ret) ||
+	    put_user(arg.ret_origin, &uarg->ret_origin)) {
+		rc = -EFAULT;
+		goto out;
+	}
+	rc = params_to_user(uparams, arg.num_params, params);
+out:
+	/*
+	 * If we've succeeded to open the session but failed to communicate
+	 * it back to user space, close the session again to avoid leakage.
+	 */
+	if (rc && have_session && ctx->teedev->desc->ops->close_session)
+		ctx->teedev->desc->ops->close_session(ctx, arg.session);
+
+	if (params) {
+		/* Decrease ref count for all valid shared memory pointers */
+		for (n = 0; n < arg.num_params; n++)
+			if (param_is_memref(params + n) &&
+			    params[n].u.memref.shm)
+				tee_shm_put(params[n].u.memref.shm);
+		kfree(params);
+	}
+
+	return rc;
+}
+
+static int tee_ioctl_invoke(struct tee_context *ctx,
+		struct tee_ioctl_buf_data __user *ubuf)
+{
+	int rc;
+	size_t n;
+	struct tee_ioctl_buf_data buf;
+	struct tee_ioctl_invoke_arg __user *uarg;
+	struct tee_ioctl_invoke_arg arg;
+	struct tee_ioctl_param __user *uparams = NULL;
+	struct tee_param *params = NULL;
+
+	if (!ctx->teedev->desc->ops->invoke_func)
+		return -EINVAL;
+
+	rc = copy_from_user(&buf, ubuf, sizeof(buf));
+	if (rc)
+		return rc;
+
+	if (buf.buf_len > TEE_MAX_ARG_SIZE ||
+	    buf.buf_len < sizeof(struct tee_ioctl_invoke_arg))
+		return -EINVAL;
+
+	uarg = (struct tee_ioctl_invoke_arg __user *)(unsigned long)buf.buf_ptr;
+	if (copy_from_user(&arg, uarg, sizeof(arg)))
+		return -EFAULT;
+
+	if (sizeof(arg) + TEE_IOCTL_PARAM_SIZE(arg.num_params) != buf.buf_len)
+		return -EINVAL;
+
+	if (arg.num_params) {
+		params = kcalloc(arg.num_params, sizeof(struct tee_param),
+				GFP_KERNEL);
+		if (!params)
+			return -ENOMEM;
+		uparams = (struct tee_ioctl_param __user *)(uarg + 1);
+		rc = params_from_user(params, arg.num_params, uparams);
+		if (rc)
+			goto out;
+	}
+
+	rc = ctx->teedev->desc->ops->invoke_func(ctx, &arg, params);
+	if (rc)
+		goto out;
+
+	if (put_user(arg.ret, &uarg->ret) ||
+	    put_user(arg.ret_origin, &uarg->ret_origin)) {
+		rc = -EFAULT;
+		goto out;
+	}
+	rc = params_to_user(uparams, arg.num_params, params);
+out:
+	if (params) {
+		/* Decrease ref count for all valid shared memory pointers */
+		for (n = 0; n < arg.num_params; n++)
+			if (param_is_memref(params + n) &&
+			    params[n].u.memref.shm)
+				tee_shm_put(params[n].u.memref.shm);
+		kfree(params);
+	}
+	return rc;
+}
+
+
+static int tee_ioctl_cancel(struct tee_context *ctx,
+		struct tee_ioctl_cancel_arg __user *uarg)
+{
+	struct tee_ioctl_cancel_arg arg;
+
+	if (!ctx->teedev->desc->ops->cancel_req)
+		return -EINVAL;
+
+	if (copy_from_user(&arg, uarg, sizeof(arg)))
+		return -EFAULT;
+
+	return ctx->teedev->desc->ops->cancel_req(ctx, arg.cancel_id,
+						  arg.session);
+}
+
+static int tee_ioctl_close_session(struct tee_context *ctx,
+		struct tee_ioctl_close_session_arg __user *uarg)
+{
+	struct tee_ioctl_close_session_arg arg;
+
+	if (!ctx->teedev->desc->ops->close_session)
+		return -EINVAL;
+
+	if (copy_from_user(&arg, uarg, sizeof(arg)))
+		return -EFAULT;
+
+	return ctx->teedev->desc->ops->close_session(ctx, arg.session);
+}
+
+static int params_to_supp(struct tee_ioctl_param __user *uparams,
+		size_t num_params, struct tee_param *params)
+{
+	int rc = 0;
+	size_t n;
+	int *fds = kmalloc_array(num_params, sizeof(int), GFP_KERNEL);
+
+	if (!fds)
+		return -ENOMEM;
+	for (n = 0; n < num_params; n++)
+		fds[n] = -1;
+
+	for (n = 0; n < num_params; n++) {
+		struct tee_ioctl_param ip;
+		struct tee_param *p = params + n;
+
+		ip.attr = p->attr & TEE_IOCTL_PARAM_ATTR_TYPE_MASK;
+		switch (p->attr) {
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT:
+			ip.u.value.a = p->u.value.a;
+			ip.u.value.b = p->u.value.b;
+			ip.u.value.c = p->u.value.c;
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT:
+			ip.u.memref.size = p->u.memref.size;
+			if (!p->u.memref.shm) {
+				ip.u.memref.shm_offs = 0;
+				ip.u.memref.shm_fd = -1;
+				break;
+			}
+			ip.u.memref.shm_offs = p->u.memref.shm_offs;
+			/*
+			 * This tee_shm_get_fd() is supposed to be matched
+			 * by a close(2) from tee-supplicant.
+			 */
+			fds[n] = tee_shm_get_fd(p->u.memref.shm);
+			if (fds[n] < 0) {
+				rc = fds[n];
+				goto out;
+			}
+			ip.u.memref.shm_fd = fds[n];
+			break;
+		default:
+			memset(&ip.u, 0, sizeof(ip.u));
+			break;
+		}
+
+		if (copy_to_user(uparams + n, &ip, sizeof(ip))) {
+			rc = -EFAULT;
+			goto out;
+		}
+	}
+out:
+	if (rc) {
+		for (n = 0; n < num_params; n++)
+			if (fds[n] >= 0)
+				tee_shm_put_fd(fds[n]);
+	}
+	kfree(fds);
+	return rc;
+}
+
+static int tee_ioctl_supp_recv(struct tee_context *ctx,
+		struct tee_ioctl_buf_data __user *ubuf)
+{
+	int rc;
+	struct tee_ioctl_buf_data buf;
+	struct tee_iocl_supp_recv_arg __user *uarg;
+	struct tee_param *params;
+	struct tee_ioctl_param __user *uparams;
+	u32 num_params;
+	u32 func;
+
+	if (!ctx->teedev->desc->ops->supp_recv)
+		return -EINVAL;
+
+	if (copy_from_user(&buf, ubuf, sizeof(buf)))
+		return -EFAULT;
+
+	if (buf.buf_len > TEE_MAX_ARG_SIZE ||
+	    buf.buf_len < sizeof(struct tee_iocl_supp_recv_arg))
+		return -EINVAL;
+
+	uarg = (struct tee_iocl_supp_recv_arg __user *)(unsigned long)
+		buf.buf_ptr;
+	if (get_user(num_params, &uarg->num_params))
+		return -EFAULT;
+
+	if (sizeof(*uarg) + TEE_IOCTL_PARAM_SIZE(num_params) != buf.buf_len)
+		return -EINVAL;
+
+	params = kcalloc(num_params, sizeof(struct tee_param), GFP_KERNEL);
+	if (!params)
+		return -ENOMEM;
+
+	rc = ctx->teedev->desc->ops->supp_recv(ctx, &func, &num_params, params);
+	if (rc)
+		goto out;
+
+	if (put_user(func, &uarg->func) ||
+	    put_user(num_params, &uarg->num_params)) {
+		rc = -EFAULT;
+		goto out;
+	}
+
+	uparams = (struct tee_ioctl_param __user *)(uarg + 1);
+	rc = params_to_supp(uparams, num_params, params);
+out:
+	kfree(params);
+	return rc;
+}
+
+static int params_from_supp(struct tee_param *params,
+		size_t num_params, struct tee_ioctl_param __user *uparams)
+{
+	size_t n;
+
+	for (n = 0; n < num_params; n++) {
+		struct tee_param *p = params + n;
+		struct tee_ioctl_param ip;
+
+		if (copy_from_user(&ip, uparams + n, sizeof(ip)))
+			return -EFAULT;
+
+		/* All unused attribute bits has to be zero */
+		if (ip.attr & ~TEE_IOCTL_PARAM_ATTR_TYPE_MASK)
+			return -EINVAL;
+
+		p->attr = ip.attr;
+		switch (ip.attr) {
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT:
+			/* Only out and in/out values can be updated */
+			p->u.value.a = ip.u.value.a;
+			p->u.value.b = ip.u.value.b;
+			p->u.value.c = ip.u.value.c;
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT:
+			/*
+			 * Only the size of the memref can be updated.
+			 * Since we don't have access to the original
+			 * parameters here, only store the supplied size.
+			 * The driver will copy the updated size into the
+			 * original parameters.
+			 */
+			p->u.memref.shm = NULL;
+			p->u.memref.shm_offs = 0;
+			p->u.memref.size = ip.u.memref.size;
+			break;
+		default:
+			memset(&p->u, 0, sizeof(p->u));
+			break;
+		}
+	}
+	return 0;
+}
+
+static int tee_ioctl_supp_send(struct tee_context *ctx,
+		struct tee_ioctl_buf_data __user *ubuf)
+{
+	long rc;
+	struct tee_ioctl_buf_data buf;
+	struct tee_iocl_supp_send_arg __user *uarg;
+	struct tee_param *params;
+	struct tee_ioctl_param __user *uparams;
+	u32 num_params;
+	u32 ret;
+
+	/* Not valid for this driver */
+	if (!ctx->teedev->desc->ops->supp_send)
+		return -EINVAL;
+
+	if (copy_from_user(&buf, ubuf, sizeof(buf)))
+		return -EFAULT;
+
+	if (buf.buf_len > TEE_MAX_ARG_SIZE ||
+	    buf.buf_len < sizeof(struct tee_iocl_supp_send_arg))
+		return -EINVAL;
+
+	uarg = (struct tee_iocl_supp_send_arg __user *)(unsigned long)
+		buf.buf_ptr;
+	if (get_user(ret, &uarg->ret) ||
+	    get_user(num_params, &uarg->num_params))
+		return -EFAULT;
+
+	if (sizeof(*uarg) + TEE_IOCTL_PARAM_SIZE(num_params) > buf.buf_len)
+		return -EINVAL;
+
+	params = kcalloc(num_params, sizeof(struct tee_param), GFP_KERNEL);
+	if (!params)
+		return -ENOMEM;
+
+	uparams = (struct tee_ioctl_param __user *)(uarg + 1);
+	rc = params_from_supp(params, num_params, uparams);
+	if (rc)
+		goto out;
+
+	rc = ctx->teedev->desc->ops->supp_send(ctx, ret, num_params, params);
+out:
+	kfree(params);
+	return rc;
+}
+
+
+static long tee_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
+{
+	struct tee_context *ctx = filp->private_data;
+	void __user *uarg = (void __user *)arg;
+
+	switch (cmd) {
+	case TEE_IOC_VERSION:
+		return tee_ioctl_version(ctx, uarg);
+	case TEE_IOC_SHM_ALLOC:
+		return tee_ioctl_shm_alloc(ctx, uarg);
+	case TEE_IOC_OPEN_SESSION:
+		return tee_ioctl_open_session(ctx, uarg);
+	case TEE_IOC_INVOKE:
+		return tee_ioctl_invoke(ctx, uarg);
+	case TEE_IOC_CANCEL:
+		return tee_ioctl_cancel(ctx, uarg);
+	case TEE_IOC_CLOSE_SESSION:
+		return tee_ioctl_close_session(ctx, uarg);
+	case TEE_IOC_SUPPL_RECV:
+		return tee_ioctl_supp_recv(ctx, uarg);
+	case TEE_IOC_SUPPL_SEND:
+		return tee_ioctl_supp_send(ctx, uarg);
+	default:
+		return -EINVAL;
+	}
+}
+
+static const struct file_operations tee_fops = {
+	.open = tee_open,
+	.release = tee_release,
+	.unlocked_ioctl = tee_ioctl,
+	.compat_ioctl = tee_ioctl,
+};
+
+static void tee_release_device(struct device *dev)
+{
+	struct tee_device *teedev = container_of(dev, struct tee_device, dev);
+
+	spin_lock(&driver_lock);
+	clear_bit(teedev->id, dev_mask);
+	spin_unlock(&driver_lock);
+	mutex_destroy(&teedev->mutex);
+	kfree(teedev);
+}
+
+struct tee_device *tee_device_alloc(const struct tee_desc *teedesc,
+			struct device *dev, struct tee_shm_pool *pool,
+			void *driver_data)
+{
+	struct tee_device *teedev;
+	void *ret;
+	int rc;
+	int offs = 0;
+
+	if (!teedesc || !teedesc->name || !teedesc->ops ||
+	    !teedesc->ops->get_version || !teedesc->ops->open ||
+	    !teedesc->ops->release || !dev || !pool)
+		return ERR_PTR(-EINVAL);
+
+	teedev = kzalloc(sizeof(*teedev), GFP_KERNEL);
+	if (!teedev) {
+		ret = ERR_PTR(-ENOMEM);
+		goto err;
+	}
+
+	if (teedesc->flags & TEE_DESC_PRIVILEGED)
+		offs = TEE_NUM_DEVICES / 2;
+
+	spin_lock(&driver_lock);
+	teedev->id = find_next_zero_bit(dev_mask, TEE_NUM_DEVICES, offs);
+	if (teedev->id < TEE_NUM_DEVICES)
+		set_bit(teedev->id, dev_mask);
+	spin_unlock(&driver_lock);
+
+	if (teedev->id >= TEE_NUM_DEVICES) {
+		ret = ERR_PTR(-ENOMEM);
+		goto err;
+	}
+
+	snprintf(teedev->name, sizeof(teedev->name), "tee%s%d",
+		 teedesc->flags & TEE_DESC_PRIVILEGED ? "priv" : "",
+		 teedev->id - offs);
+
+	teedev->dev.class = tee_class;
+	teedev->dev.release = tee_release_device;
+	teedev->dev.parent = dev;
+	teedev->dev.devt = MKDEV(MAJOR(tee_devt), teedev->id);
+
+	rc = dev_set_name(&teedev->dev, "%s", teedev->name);
+	if (rc) {
+		ret = ERR_PTR(rc);
+		goto err;
+	}
+
+	cdev_init(&teedev->cdev, &tee_fops);
+	teedev->cdev.owner = teedesc->owner;
+	teedev->cdev.kobj.parent = &teedev->dev.kobj;
+
+	dev_set_drvdata(&teedev->dev, driver_data);
+	device_initialize(&teedev->dev);
+
+	/* 1 as tee_device_unregister() does one final tee_device_put() */
+	teedev->num_users = 1;
+	init_completion(&teedev->c_no_users);
+	mutex_init(&teedev->mutex);
+
+	teedev->desc = teedesc;
+	teedev->pool = pool;
+	INIT_LIST_HEAD(&teedev->list_shm);
+
+	return teedev;
+err:
+	dev_err(dev, "could not register %s driver\n",
+		teedesc->flags & TEE_DESC_PRIVILEGED ? "privileged" : "client");
+	if (teedev && teedev->id < TEE_NUM_DEVICES) {
+		spin_lock(&driver_lock);
+		clear_bit(teedev->id, dev_mask);
+		spin_unlock(&driver_lock);
+	}
+	kfree(teedev);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(tee_device_alloc);
+
+static ssize_t implementation_id_show(struct device *dev,
+			struct device_attribute *attr, char *buf)
+{
+	struct tee_device *teedev = container_of(dev, struct tee_device, dev);
+	struct tee_ioctl_version_data vers;
+
+	teedev->desc->ops->get_version(teedev, &vers);
+	return scnprintf(buf, PAGE_SIZE, "%d\n", vers.impl_id);
+}
+static DEVICE_ATTR_RO(implementation_id);
+
+static struct attribute *tee_dev_attrs[] = {
+	&dev_attr_implementation_id.attr,
+	NULL
+};
+
+static const struct attribute_group tee_dev_group = {
+	.attrs = tee_dev_attrs,
+};
+
+int tee_device_register(struct tee_device *teedev)
+{
+	int rc;
+
+	/*
+	 * If the teedev already is registered, don't do it again. It's
+	 * obviously an error to try to register twice, but if we return
+	 * an error we'll force the driver to remove the teedev.
+	 */
+	if (teedev->flags & TEE_DEVICE_FLAG_REGISTERED) {
+		dev_err(&teedev->dev, "attempt to register twice\n");
+		return 0;
+	}
+
+	rc = cdev_add(&teedev->cdev, teedev->dev.devt, 1);
+	if (rc) {
+		dev_err(&teedev->dev,
+			"unable to cdev_add() %s, major %d, minor %d, err=%d\n",
+			teedev->name, MAJOR(teedev->dev.devt),
+			MINOR(teedev->dev.devt), rc);
+		return rc;
+	}
+
+	rc = device_add(&teedev->dev);
+	if (rc) {
+		dev_err(&teedev->dev,
+			"unable to device_add() %s, major %d, minor %d, err=%d\n",
+			teedev->name, MAJOR(teedev->dev.devt),
+			MINOR(teedev->dev.devt), rc);
+		goto err_device_add;
+	}
+
+	rc = sysfs_create_group(&teedev->dev.kobj, &tee_dev_group);
+	if (rc) {
+		dev_err(&teedev->dev,
+			"failed to create sysfs attributes, err=%d\n", rc);
+		goto err_sysfs_create_group;
+	}
+
+	teedev->flags |= TEE_DEVICE_FLAG_REGISTERED;
+	return 0;
+
+err_sysfs_create_group:
+	device_del(&teedev->dev);
+err_device_add:
+	cdev_del(&teedev->cdev);
+	return rc;
+
+}
+EXPORT_SYMBOL_GPL(tee_device_register);
+
+void tee_device_put(struct tee_device *teedev)
+{
+	mutex_lock(&teedev->mutex);
+	/* Shouldn't put in this state */
+	if (!WARN_ON(!teedev->desc)) {
+		teedev->num_users--;
+		if (!teedev->num_users) {
+			teedev->desc = NULL;
+			complete(&teedev->c_no_users);
+		}
+	}
+	mutex_unlock(&teedev->mutex);
+}
+
+bool tee_device_get(struct tee_device *teedev)
+{
+	mutex_lock(&teedev->mutex);
+	if (!teedev->desc) {
+		mutex_unlock(&teedev->mutex);
+		return false;
+	}
+	teedev->num_users++;
+	mutex_unlock(&teedev->mutex);
+	return true;
+}
+
+void tee_device_unregister(struct tee_device *teedev)
+{
+	if (!teedev)
+		return;
+
+	if (teedev->flags & TEE_DEVICE_FLAG_REGISTERED) {
+		sysfs_remove_group(&teedev->dev.kobj, &tee_dev_group);
+		cdev_del(&teedev->cdev);
+		device_del(&teedev->dev);
+	}
+
+	tee_device_put(teedev);
+	wait_for_completion(&teedev->c_no_users);
+
+	/*
+	 * No need to take a mutex any longer now since teedev->desc was
+	 * set to NULL before teedev->c_no_users was completed.
+	 */
+
+	teedev->pool = NULL;
+
+	put_device(&teedev->dev);
+}
+EXPORT_SYMBOL_GPL(tee_device_unregister);
+
+void *tee_get_drvdata(struct tee_device *teedev)
+{
+	return dev_get_drvdata(&teedev->dev);
+}
+EXPORT_SYMBOL_GPL(tee_get_drvdata);
+
+static int __init tee_init(void)
+{
+	int rc;
+
+	tee_class = class_create(THIS_MODULE, "tee");
+	if (IS_ERR(tee_class)) {
+		pr_err("couldn't create class\n");
+		return PTR_ERR(tee_class);
+	}
+
+	rc = alloc_chrdev_region(&tee_devt, 0, TEE_NUM_DEVICES, "tee");
+	if (rc < 0) {
+		pr_err("failed to allocate char dev region\n");
+		class_destroy(tee_class);
+		tee_class = NULL;
+	}
+
+	return rc;
+}
+
+subsys_initcall(tee_init);
diff --git a/drivers/tee/tee_private.h b/drivers/tee/tee_private.h
new file mode 100644
index 0000000..d32ac54
--- /dev/null
+++ b/drivers/tee/tee_private.h
@@ -0,0 +1,80 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#ifndef TEE_PRIVATE_H
+#define TEE_PRIVATE_H
+
+#include <linux/types.h>
+#include <linux/device.h>
+#include <linux/cdev.h>
+#include <linux/completion.h>
+#include <linux/mutex.h>
+#include <linux/kref.h>
+
+struct tee_device;
+
+struct tee_shm {
+	struct list_head list_node;
+	struct tee_device *teedev;
+	phys_addr_t paddr;
+	void *kaddr;
+	size_t size;
+	struct dma_buf *dmabuf;
+	u32 flags;
+};
+
+struct tee_shm_pool_mgr;
+struct tee_shm_pool_mgr_ops {
+	int (*alloc)(struct tee_shm_pool_mgr *poolmgr, struct tee_shm *shm,
+		     size_t size);
+	void (*free)(struct tee_shm_pool_mgr *poolmgr, struct tee_shm *shm);
+};
+
+struct tee_shm_pool_mgr {
+	const struct tee_shm_pool_mgr_ops *ops;
+	void *private_data;
+};
+
+struct tee_shm_pool {
+	struct tee_shm_pool_mgr private_mgr;
+	struct tee_shm_pool_mgr dma_buf_mgr;
+	void (*destroy)(struct tee_shm_pool *pool);
+	void *private_data;
+};
+
+#define TEE_DEVICE_FLAG_REGISTERED	0x1
+#define TEE_MAX_DEV_NAME_LEN		32
+
+struct tee_device {
+	char name[TEE_MAX_DEV_NAME_LEN];
+	const struct tee_desc *desc;
+	int id;
+	unsigned flags;
+
+	struct device dev;
+	struct cdev cdev;
+
+	size_t num_users;
+	struct completion c_no_users;
+	struct mutex mutex;
+
+	struct list_head list_shm;
+	struct tee_shm_pool *pool;
+};
+
+int tee_shm_init(void);
+
+bool tee_device_get(struct tee_device *teedev);
+void tee_device_put(struct tee_device *teedev);
+
+#endif /*TEE_PRIVATE_H*/
diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
new file mode 100644
index 0000000..6732e77
--- /dev/null
+++ b/drivers/tee/tee_shm.c
@@ -0,0 +1,324 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/device.h>
+#include <linux/fdtable.h>
+#include <linux/sched.h>
+#include <linux/dma-buf.h>
+#include <linux/slab.h>
+#include <linux/tee_drv.h>
+#include "tee_private.h"
+
+static void tee_shm_release(struct tee_shm *shm)
+{
+	struct tee_device *teedev = shm->teedev;
+	struct tee_shm_pool_mgr *poolm;
+
+	mutex_lock(&teedev->mutex);
+	list_del(&shm->list_node);
+	mutex_unlock(&teedev->mutex);
+
+	if (shm->flags & TEE_SHM_DMA_BUF)
+		poolm = &teedev->pool->dma_buf_mgr;
+	else
+		poolm = &teedev->pool->private_mgr;
+
+	poolm->ops->free(poolm, shm);
+	kfree(shm);
+
+	tee_device_put(teedev);
+}
+
+static struct sg_table *tee_shm_op_map_dma_buf(struct dma_buf_attachment
+			*attach, enum dma_data_direction dir)
+{
+	return NULL;
+}
+
+static void tee_shm_op_unmap_dma_buf(struct dma_buf_attachment *attach,
+			struct sg_table *table, enum dma_data_direction dir)
+{
+}
+
+static void tee_shm_op_release(struct dma_buf *dmabuf)
+{
+	struct tee_shm *shm = dmabuf->priv;
+
+	tee_shm_release(shm);
+}
+
+static void *tee_shm_op_kmap_atomic(struct dma_buf *dmabuf,
+			unsigned long pgnum)
+{
+	return NULL;
+}
+
+static void *tee_shm_op_kmap(struct dma_buf *dmabuf, unsigned long pgnum)
+{
+	return NULL;
+}
+
+static int tee_shm_op_mmap(struct dma_buf *dmabuf,
+			struct vm_area_struct *vma)
+{
+	struct tee_shm *shm = dmabuf->priv;
+	size_t size = vma->vm_end - vma->vm_start;
+
+	return remap_pfn_range(vma, vma->vm_start, shm->paddr >> PAGE_SHIFT,
+			       size, vma->vm_page_prot);
+}
+
+static struct dma_buf_ops tee_shm_dma_buf_ops = {
+	.map_dma_buf = tee_shm_op_map_dma_buf,
+	.unmap_dma_buf = tee_shm_op_unmap_dma_buf,
+	.release = tee_shm_op_release,
+	.kmap_atomic = tee_shm_op_kmap_atomic,
+	.kmap = tee_shm_op_kmap,
+	.mmap = tee_shm_op_mmap,
+};
+
+struct tee_shm *tee_shm_alloc(struct tee_device *teedev, size_t size,
+			u32 flags)
+{
+	struct tee_shm_pool_mgr *poolm = NULL;
+	struct tee_shm *shm;
+	void *ret;
+	int rc;
+
+	if (!(flags & TEE_SHM_MAPPED)) {
+		dev_err(teedev->dev.parent,
+			"only mapped allocations supported\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	if ((flags & ~(TEE_SHM_MAPPED|TEE_SHM_DMA_BUF))) {
+		dev_err(teedev->dev.parent, "invalid shm flags 0x%x", flags);
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (!tee_device_get(teedev))
+		return ERR_PTR(-EINVAL);
+
+	if (!teedev->pool) {
+		/* teedev has been detached from driver */
+		ret = ERR_PTR(-EINVAL);
+		goto err;
+	}
+
+	shm = kzalloc(sizeof(struct tee_shm), GFP_KERNEL);
+	if (!shm) {
+		ret = ERR_PTR(-ENOMEM);
+		goto err;
+	}
+
+	shm->flags = flags;
+	shm->teedev = teedev;
+	if (flags & TEE_SHM_DMA_BUF)
+		poolm = &teedev->pool->dma_buf_mgr;
+	else
+		poolm = &teedev->pool->private_mgr;
+
+	rc = poolm->ops->alloc(poolm, shm, size);
+	if (rc) {
+		ret = ERR_PTR(rc);
+		goto err;
+	}
+
+	mutex_lock(&teedev->mutex);
+	list_add_tail(&shm->list_node, &teedev->list_shm);
+	mutex_unlock(&teedev->mutex);
+
+	if (flags & TEE_SHM_DMA_BUF) {
+		DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+
+		exp_info.ops = &tee_shm_dma_buf_ops;
+		exp_info.size = shm->size;
+		exp_info.flags = O_RDWR;
+		exp_info.priv = shm;
+
+		shm->dmabuf = dma_buf_export(&exp_info);
+		if (IS_ERR(shm->dmabuf)) {
+			ret = ERR_CAST(shm->dmabuf);
+			goto err;
+		}
+	}
+
+	return shm;
+err:
+	if (poolm && shm && shm->kaddr)
+		poolm->ops->free(poolm, shm);
+	kfree(shm);
+	tee_device_put(teedev);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(tee_shm_alloc);
+
+int tee_shm_get_fd(struct tee_shm *shm)
+{
+	u32 req_flags = TEE_SHM_MAPPED | TEE_SHM_DMA_BUF;
+	int fd;
+
+	if ((shm->flags & req_flags) != req_flags)
+		return -EINVAL;
+
+	fd = dma_buf_fd(shm->dmabuf, O_CLOEXEC);
+	if (fd >= 0)
+		get_dma_buf(shm->dmabuf);
+	return fd;
+}
+EXPORT_SYMBOL_GPL(tee_shm_get_fd);
+
+int tee_shm_put_fd(int fd)
+{
+	return __close_fd(current->files, fd);
+}
+EXPORT_SYMBOL_GPL(tee_shm_put_fd);
+
+void tee_shm_free(struct tee_shm *shm)
+{
+
+	/*
+	 * dma_buf_put() decreases the dmabuf reference counter and will
+	 * call tee_shm_release() when the last reference is gone.
+	 *
+	 * In the case of driver private memory we call tee_shm_release
+	 * directly instead as it doesn't have a reference counter.
+	 */
+	if (shm->flags & TEE_SHM_DMA_BUF)
+		dma_buf_put(shm->dmabuf);
+	else
+		tee_shm_release(shm);
+}
+EXPORT_SYMBOL_GPL(tee_shm_free);
+
+static bool cmp_key_va(struct tee_shm *shm, uintptr_t va)
+{
+	uintptr_t shm_va = (uintptr_t)shm->kaddr;
+
+	return (va >= shm_va) && (va < (shm_va + shm->size));
+}
+
+static bool cmp_key_pa(struct tee_shm *shm, uintptr_t pa)
+{
+	return (pa >= shm->paddr) && (pa < (shm->paddr + shm->size));
+}
+
+static struct tee_shm *tee_shm_find_by_key(struct tee_device *teedev, u32 flags,
+			bool (*cmp)(struct tee_shm *shm, uintptr_t key),
+			uintptr_t key)
+{
+	struct tee_shm *ret = NULL;
+	struct tee_shm *shm;
+
+	mutex_lock(&teedev->mutex);
+	list_for_each_entry(shm, &teedev->list_shm, list_node) {
+		if (cmp(shm, key)) {
+			ret = shm;
+			break;
+		}
+	}
+	mutex_unlock(&teedev->mutex);
+
+	return ret;
+}
+
+struct tee_shm *tee_shm_find_by_va(struct tee_device *teedev, u32 flags,
+			void *va)
+{
+	return tee_shm_find_by_key(teedev, flags, cmp_key_va, (uintptr_t)va);
+}
+EXPORT_SYMBOL_GPL(tee_shm_find_by_va);
+
+struct tee_shm *tee_shm_find_by_pa(struct tee_device *teedev, u32 flags,
+			phys_addr_t pa)
+{
+	return tee_shm_find_by_key(teedev, flags, cmp_key_pa, pa);
+}
+EXPORT_SYMBOL_GPL(tee_shm_find_by_pa);
+
+int tee_shm_va2pa(struct tee_shm *shm, void *va, phys_addr_t *pa)
+{
+	/* Check that we're in the range of the shm */
+	if ((char *)va < (char *)shm->kaddr)
+		return -EINVAL;
+	if ((char *)va >= ((char *)shm->kaddr + shm->size))
+		return -EINVAL;
+
+	return tee_shm_get_pa(
+			shm, (unsigned long)va - (unsigned long)shm->kaddr, pa);
+}
+EXPORT_SYMBOL_GPL(tee_shm_va2pa);
+
+int tee_shm_pa2va(struct tee_shm *shm, phys_addr_t pa, void **va)
+{
+	/* Check that we're in the range of the shm */
+	if (pa < shm->paddr)
+		return -EINVAL;
+	if (pa >= (shm->paddr + shm->size))
+		return -EINVAL;
+
+	if (va) {
+		void *v = tee_shm_get_va(shm, pa - shm->paddr);
+
+		if (IS_ERR(v))
+			return PTR_ERR(v);
+		*va = v;
+	}
+	return 0;
+}
+EXPORT_SYMBOL_GPL(tee_shm_pa2va);
+
+void *tee_shm_get_va(struct tee_shm *shm, size_t offs)
+{
+	if (offs >= shm->size)
+		return ERR_PTR(-EINVAL);
+	return (char *)shm->kaddr + offs;
+}
+EXPORT_SYMBOL_GPL(tee_shm_get_va);
+
+int tee_shm_get_pa(struct tee_shm *shm, size_t offs, phys_addr_t *pa)
+{
+	if (offs >= shm->size)
+		return -EINVAL;
+	if (pa)
+		*pa = shm->paddr + offs;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(tee_shm_get_pa);
+
+static bool is_shm_dma_buf(struct dma_buf *dmabuf)
+{
+	return dmabuf->ops == &tee_shm_dma_buf_ops;
+}
+
+struct tee_shm *tee_shm_get_from_fd(int fd)
+{
+	struct dma_buf *dmabuf = dma_buf_get(fd);
+
+	if (IS_ERR(dmabuf))
+		return ERR_CAST(dmabuf);
+
+	if (!is_shm_dma_buf(dmabuf)) {
+		dma_buf_put(dmabuf);
+		return ERR_PTR(-EINVAL);
+	}
+	return dmabuf->priv;
+}
+EXPORT_SYMBOL_GPL(tee_shm_get_from_fd);
+
+void tee_shm_put(struct tee_shm *shm)
+{
+	if (shm->flags & TEE_SHM_DMA_BUF)
+		dma_buf_put(shm->dmabuf);
+}
+EXPORT_SYMBOL_GPL(tee_shm_put);
diff --git a/drivers/tee/tee_shm_pool.c b/drivers/tee/tee_shm_pool.c
new file mode 100644
index 0000000..2ef22bc
--- /dev/null
+++ b/drivers/tee/tee_shm_pool.c
@@ -0,0 +1,133 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/device.h>
+#include <linux/dma-buf.h>
+#include <linux/slab.h>
+#include <linux/genalloc.h>
+#include <linux/tee_drv.h>
+#include "tee_private.h"
+
+static int pool_op_gen_alloc(struct tee_shm_pool_mgr *poolm,
+			struct tee_shm *shm, size_t size)
+{
+	unsigned long va;
+	struct gen_pool *genpool = poolm->private_data;
+	size_t s = roundup(size, 1 << genpool->min_alloc_order);
+
+	va = gen_pool_alloc(genpool, s);
+	if (!va)
+		return -ENOMEM;
+	shm->kaddr = (void *)va;
+	shm->paddr = gen_pool_virt_to_phys(genpool, va);
+	shm->size = s;
+	return 0;
+}
+
+static void pool_op_gen_free(struct tee_shm_pool_mgr *poolm,
+			struct tee_shm *shm)
+{
+	gen_pool_free(poolm->private_data, (unsigned long)shm->kaddr,
+		      shm->size);
+	shm->kaddr = NULL;
+}
+
+static const struct tee_shm_pool_mgr_ops pool_ops_generic = {
+	.alloc = pool_op_gen_alloc,
+	.free = pool_op_gen_free,
+};
+
+static void pool_res_mem_destroy(struct tee_shm_pool *pool)
+{
+	gen_pool_destroy(pool->private_mgr.private_data);
+	gen_pool_destroy(pool->dma_buf_mgr.private_data);
+}
+
+static int pool_res_mem_mgr_init(struct tee_shm_pool_mgr *mgr,
+			struct tee_shm_pool_mem_info *info, int min_alloc_order)
+{
+	size_t page_mask = PAGE_SIZE - 1;
+	struct gen_pool *genpool = NULL;
+	int rc;
+
+	/*
+	 * Start and end must be page aligned
+	 */
+	if ((info->vaddr & page_mask) || (info->paddr & page_mask) ||
+	    (info->size & page_mask))
+		return -EINVAL;
+
+	genpool = gen_pool_create(min_alloc_order, -1);
+	if (!genpool)
+		return -ENOMEM;
+
+	gen_pool_set_algo(genpool, gen_pool_best_fit, NULL);
+	rc = gen_pool_add_virt(genpool, info->vaddr, info->paddr, info->size,
+			       -1);
+	if (rc) {
+		gen_pool_destroy(genpool);
+		return rc;
+	}
+
+	mgr->private_data = genpool;
+	mgr->ops = &pool_ops_generic;
+	return 0;
+}
+
+struct tee_shm_pool *tee_shm_pool_alloc_res_mem(struct device *dev,
+			struct tee_shm_pool_mem_info *priv_info,
+			struct tee_shm_pool_mem_info *dmabuf_info)
+{
+	struct tee_shm_pool *pool = NULL;
+	int ret;
+
+	pool = kzalloc(sizeof(*pool), GFP_KERNEL);
+	if (!pool) {
+		ret = -ENOMEM;
+		goto err;
+	}
+
+	/*
+	 * Create the pool for driver private shared memory
+	 */
+	ret = pool_res_mem_mgr_init(&pool->private_mgr, priv_info,
+				    3 /* 8 byte aligned */);
+	if (ret)
+		goto err;
+
+	/*
+	 * Create the pool for dma_buf shared memory
+	 */
+	ret = pool_res_mem_mgr_init(&pool->dma_buf_mgr, dmabuf_info,
+				    PAGE_SHIFT);
+	if (ret)
+		goto err;
+
+	pool->destroy = pool_res_mem_destroy;
+	return pool;
+err:
+	if (ret == -ENOMEM)
+		dev_err(dev, "can't allocate memory for res_mem shared memory pool\n");
+	if (pool && pool->private_mgr.private_data)
+		gen_pool_destroy(pool->private_mgr.private_data);
+	kfree(pool);
+	return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(tee_shm_pool_alloc_res_mem);
+
+void tee_shm_pool_free(struct tee_shm_pool *pool)
+{
+	pool->destroy(pool);
+	kfree(pool);
+}
+EXPORT_SYMBOL_GPL(tee_shm_pool_free);
diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h
new file mode 100644
index 0000000..06cffa6
--- /dev/null
+++ b/include/linux/tee_drv.h
@@ -0,0 +1,299 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __TEE_DRV_H
+#define __TEE_DRV_H
+
+#include <linux/types.h>
+#include <linux/list.h>
+#include <linux/tee.h>
+
+/*
+ * The file describes the API provided by the generic TEE driver to the
+ * specific TEE driver.
+ */
+
+#define TEE_SHM_MAPPED		0x1	/* Memory mapped by the kernel */
+#define TEE_SHM_DMA_BUF		0x2	/* Memory with dma-buf handle */
+
+struct tee_device;
+struct tee_shm;
+struct tee_shm_pool;
+
+/**
+ * struct tee_context - driver specific context on file pointer data
+ * @teedev:	pointer to this drivers struct tee_device
+ * @data:	driver specific context data, managed by the driver
+ */
+struct tee_context {
+	struct tee_device *teedev;
+	void *data;
+};
+
+struct tee_param_memref {
+	size_t shm_offs;
+	size_t size;
+	struct tee_shm *shm;
+};
+
+struct tee_param_value {
+	u64 a;
+	u64 b;
+	u64 c;
+};
+
+struct tee_param {
+	u64 attr;
+	union {
+		struct tee_param_memref memref;
+		struct tee_param_value value;
+	} u;
+};
+
+/**
+ * struct tee_driver_ops - driver operations vtable
+ * @get_version:	returns version of driver
+ * @open:		called when the device file is opened
+ * @release:		release this open file
+ */
+struct tee_driver_ops {
+	void (*get_version)(struct tee_device *teedev,
+			struct tee_ioctl_version_data *vers);
+	int (*open)(struct tee_context *ctx);
+	void (*release)(struct tee_context *ctx);
+	int (*open_session)(struct tee_context *ctx,
+			struct tee_ioctl_open_session_arg *arg,
+			struct tee_param *param);
+	int (*close_session)(struct tee_context *ctx, u32 session);
+	int (*invoke_func)(struct tee_context *ctx,
+			struct tee_ioctl_invoke_arg *arg,
+			struct tee_param *param);
+	int (*cancel_req)(struct tee_context *ctx, u32 cancel_id, u32 session);
+	int (*supp_recv)(struct tee_context *ctx, u32 *func, u32 *num_params,
+			struct tee_param *param);
+	int (*supp_send)(struct tee_context *ctx, u32 ret, u32 num_params,
+			struct tee_param *param);
+};
+
+/**
+ * struct tee_desc - Describes the TEE driver to the subsystem
+ * @name:	name of driver
+ * @ops:	driver operations vtable
+ * @owner:	module providing the driver
+ * @flags:	Extra properties of driver, defined by TEE_DESC_* below
+ */
+#define TEE_DESC_PRIVILEGED	0x1
+struct tee_desc {
+	const char *name;
+	const struct tee_driver_ops *ops;
+	struct module *owner;
+	u32 flags;
+};
+
+
+/**
+ * tee_device_alloc() - Allocate a new struct tee_device instance
+ * @teedesc:	Descriptor for this driver
+ * @dev:	Parent device for this device
+ * @pool:	Shared memory pool, NULL if not used
+ * @driver_data: Private driver data for this device
+ *
+ * Allocates a new struct tee_device instance. The device is
+ * removed by tee_device_unregister().
+ *
+ * @returns a pointer to a 'struct tee_device' or an ERR_PTR on failure
+ */
+struct tee_device *tee_device_alloc(const struct tee_desc *teedesc,
+			struct device *dev, struct tee_shm_pool *pool,
+			void *driver_data);
+
+/**
+ * tee_device_register() - Registers a TEE device
+ * @teedev:	Device to register
+ *
+ * tee_device_unregister() need to be called to remove the @teedev if
+ * this function fails.
+ *
+ * @returns < 0 on failure
+ */
+int tee_device_register(struct tee_device *teedev);
+
+/**
+ * tee_device_unregister() - Removes a TEE device
+ * @teedev:	Device to unregister
+ *
+ * This function should be called to remove the @teedev even if
+ * tee_device_register() hasn't been called yet. Does nothing if
+ * @teedev is NULL.
+ */
+void tee_device_unregister(struct tee_device *teedev);
+
+/**
+ * struct tee_shm_pool_mem_info - holds information needed to create a shared memory pool
+ * @vaddr:	Virtual address of start of pool
+ * @paddr:	Physical address of start of pool
+ * @size:	Size in bytes of the pool
+ */
+struct tee_shm_pool_mem_info {
+	unsigned long vaddr;
+	unsigned long paddr;
+	size_t size;
+};
+
+/**
+ * tee_shm_pool_alloc_res_mem() - Create a shared memory pool from reserved memory range
+ * @dev:	Device allocating the pool
+ * @priv_info:	Information for driver private shared memory pool
+ * @dmabuf_info: Information for dma-buf shared memory pool
+ *
+ * Start and end of pools will must be page aligned.
+ *
+ * Allocation with the flag TEE_SHM_DMA_BUF set will use the range supplied
+ * in @dmabuf, others will use the range provided by @priv.
+ *
+ * @returns pointer to a 'struct tee_shm_pool' or an ERR_PTR on failure.
+ */
+struct tee_shm_pool *tee_shm_pool_alloc_res_mem(struct device *dev,
+			struct tee_shm_pool_mem_info *priv_info,
+			struct tee_shm_pool_mem_info *dmabuf_info);
+
+/**
+ * tee_shm_pool_free() - Free a shared memory pool
+ * @pool:	The shared memory pool to free
+ *
+ * The must be no remaining shared memory allocated from this pool when
+ * this function is called.
+ */
+void tee_shm_pool_free(struct tee_shm_pool *pool);
+
+/**
+ * tee_get_drvdata() - Return driver_data pointer
+ * @returns the driver_data pointer supplied to tee_register().
+ */
+void *tee_get_drvdata(struct tee_device *teedev);
+
+/**
+ * tee_shm_alloc() - Allocate shared memory
+ * @teedev:	Driver that allocates the shared memory
+ * @size:	Requested size of shared memory
+ * @flags:	Flags setting properties for the requested shared memory.
+ *
+ * Memory allocated as global shared memory is automatically freed when the
+ * TEE file pointer is closed. The @flags field uses the bits defined by
+ * TEE_SHM_* above. TEE_SHM_MAPPED must currently always be set. If
+ * TEE_SHM_DMA_BUF global shared memory will be allocated and associated
+ * with a dma-buf handle, else driver private memory.
+ *
+ * @returns a pointer to 'struct tee_shm'
+ */
+struct tee_shm *tee_shm_alloc(struct tee_device *teedev, size_t size,
+			u32 flags);
+
+/**
+ * tee_shm_free() - Free shared memory
+ * @shm:	Handle to shared memory to free
+ */
+void tee_shm_free(struct tee_shm *shm);
+
+/**
+ * tee_shm_find_by_va() - Find a shared memory handle by a virtual address
+ * @teedev:	The device that owns the shared memory
+ * @flags:	Select which type of shared memory to locate, if
+ *		TEE_SHM_DMA_BUF global shared memory else driver private
+ *		shared memory.
+ * @va:		Virtual address covered by the shared memory
+ * @returns a Handle to shared memory
+ */
+struct tee_shm *tee_shm_find_by_va(struct tee_device *teedev, u32 flags,
+			void *va);
+/**
+ * tee_shm_find_by_pa() - Find a shared memory handle by a physical address
+ * @teedev:	The device that owns the shared memory
+ * @flags:	Select which type of shared memory to locate, if
+ *		TEE_SHM_DMA_BUF global shared memory else driver private
+ *		shared memory.
+ * @pa:		Physical address covered by the shared memory
+ * @returns a Handle to shared memory
+ */
+struct tee_shm *tee_shm_find_by_pa(struct tee_device *teedev, u32 flags,
+			phys_addr_t pa);
+
+/**
+ * tee_shm_va2pa() - Get physical address of a virtual address
+ * @shm:	Shared memory handle
+ * @va:		Virtual address to tranlsate
+ * @pa:		Returned physical address
+ * @returns 0 on success and < 0 on failure
+ */
+int tee_shm_va2pa(struct tee_shm *shm, void *va, phys_addr_t *pa);
+
+/**
+ * tee_shm_pa2va() - Get virtual address of a physical address
+ * @shm:	Shared memory handle
+ * @pa:		Physical address to tranlsate
+ * @va:		Returned virtual address
+ * @returns 0 on success and < 0 on failure
+ */
+int tee_shm_pa2va(struct tee_shm *shm, phys_addr_t pa, void **va);
+
+/**
+ * tee_shm_get_va() - Get virtual address of a shared memory plus an offset
+ * @shm:	Shared memory handle
+ * @offs:	Offset from start of this shared memory
+ * @returns virtual address of the shared memory + offs if offs is within
+ *	the bounds of this shared memory, else an ERR_PTR
+ */
+void *tee_shm_get_va(struct tee_shm *shm, size_t offs);
+
+/**
+ * tee_shm_get_pa() - Get physical address of a shared memory plus an offset
+ * @shm:	Shared memory handle
+ * @offs:	Offset from start of this shared memory
+ * @pa:		Physical address to return
+ * @returns 0 if offs is within the bounds of this shared memory, else an
+ *	error code.
+ */
+int tee_shm_get_pa(struct tee_shm *shm, size_t offs, phys_addr_t *pa);
+
+/**
+ * tee_shm_get_from_fd() - Get a shared memory handle from a file descriptor
+ * @fd:		A user space file descriptor
+ *
+ * This function increases the reference counter on the shared memory and
+ * returns a handle.
+ * @returns handle to shared memory
+ */
+struct tee_shm *tee_shm_get_from_fd(int fd);
+
+/**
+ * tee_shm_put() - Decrease reference count on a shared memory handle
+ * @shm:	Shared memory handle
+ */
+void tee_shm_put(struct tee_shm *shm);
+
+/**
+ * tee_shm_get_fd() - Increase reference count and return file descriptor
+ * @shm:	Shared memory handle
+ * @returns user space file descriptor to shared memory
+ */
+int tee_shm_get_fd(struct tee_shm *shm);
+
+/**
+ * tee_shm_put_fd() - Decrease reference count and close file descriptor
+ * @fd:		File descriptor to close
+ * @returns < 0 on failure
+ */
+int tee_shm_put_fd(int fd);
+
+#endif /*__TEE_DRV_H*/
diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h
new file mode 100644
index 0000000..319cc61
--- /dev/null
+++ b/include/uapi/linux/tee.h
@@ -0,0 +1,383 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __TEE_H
+#define __TEE_H
+
+#include <linux/ioctl.h>
+#include <linux/types.h>
+
+/*
+ * This file describes the API provided by a TEE driver to user space.
+ *
+ * Each TEE driver defines a TEE specific protocol which is used for the
+ * data passed back and forth using TEE_IOC_CMD.
+ */
+
+
+/* Helpers to make the ioctl defines */
+#define TEE_IOC_MAGIC	0xa4
+#define TEE_IOC_BASE	0
+
+/* Flags relating to shared memory */
+#define TEE_IOCTL_SHM_MAPPED	0x1	/* memory mapped in normal world */
+#define TEE_IOCTL_SHM_DMA_BUF	0x2	/* dma-buf handle on shared memory */
+
+#define TEE_MAX_ARG_SIZE	1024
+
+#define TEE_GEN_CAP_GP		(1 << 0)/* Global Platform compliant TEE */
+
+/*
+ * TEE Implementation ID
+ */
+#define TEE_IMPL_ID_OPTEE	1
+
+/*
+ * OP-TEE specific capabilities
+ */
+#define TEE_OPTEE_CAP_TZ	(1 << 0)
+
+/**
+ * struct tee_ioctl_version_data - TEE version
+ * @impl_id:	[out] TEE implementation id
+ * @impl_caps:	[out] Implementation specific capabilities
+ * @gen_caps:	[out] Generic capabilities, defined by TEE_GEN_CAPS_* above
+ *
+ * Identifies the TEE implementaion, @impl_id is one of TEE_IMPL_ID_* above.
+ * @impl_caps is implementation specific, for example TEE_OPTEE_CAP_*
+ * is valid when @impl_id == TEE_IMPL_ID_OPTEE.
+ */
+struct tee_ioctl_version_data {
+	__u32 impl_id;
+	__u32 impl_caps;
+	__u32 gen_caps;
+};
+/**
+ * TEE_IOC_VERSION - query version of TEE
+ *
+ * Takes a tee_version struct and returns with the TEE version data filled
+ * in.
+ */
+#define TEE_IOC_VERSION		_IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 0, \
+				     struct tee_ioctl_version_data)
+
+/**
+ * struct tee_ioctl_shm_alloc_data - Shared memory allocate argument
+ * @size:	[in/out] Size of shared memory to allocate
+ * @flags:	[in/out] Flags to/from allocation.
+ * @fd:		[out] dma_buf file descriptor of the shared memory
+ *
+ * The flags field should currently be zero as input. Updated by the call
+ * with actual flags as defined by TEE_IOCTL_SHM_* above.
+ * This structure is used as argument for TEE_IOC_SHM_ALLOC below.
+ */
+struct tee_ioctl_shm_alloc_data {
+	__u64 size;
+	__u32 flags;
+	__s32 fd;
+};
+/**
+ * TEE_IOC_SHM_ALLOC - allocate shared memory
+ *
+ * Allocates shared memory between the user space process and secure OS.
+ * The returned file descriptor is used to map the shared memory into user
+ * space. The shared memory is freed when the descriptor is closed and the
+ * memory is unmapped.
+ */
+#define TEE_IOC_SHM_ALLOC	_IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + 1, \
+				     struct tee_ioctl_shm_alloc_data)
+
+/**
+ * struct tee_ioctl_buf_data - Variable sized buffer
+ * @buf_ptr:	[in] A __user pointer to a buffer
+ * @buf_len:	[in] Length of the buffer above
+ *
+ * Used as argument for TEE_IOC_OPEN_SESSION, TEE_IOC_INVOKE,
+ * TEE_IOC_SUPPL_RECV, and TEE_IOC_SUPPL_SEND below.
+ */
+struct tee_ioctl_buf_data {
+	__u64 buf_ptr;
+	__u64 buf_len;
+};
+
+
+/*
+ * Attributes for struct tee_ioctl_param, selects field in the union
+ */
+#define TEE_IOCTL_PARAM_ATTR_TYPE_NONE		0	/* parameter not used */
+
+/*
+ * These defines value parameters (struct tee_ioctl_param_value)
+ */
+#define TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT	1
+#define TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT	2
+#define TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT	3	/* input and output */
+
+/*
+ * These defines shared memory reference parameters (struct
+ * tee_ioctl_param_memref)
+ */
+#define TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT	5
+#define TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT	6
+#define TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT	7	/* input and output */
+
+/*
+ * Mask for the type part of the attribute, leaves room for more types
+ */
+#define TEE_IOCTL_PARAM_ATTR_TYPE_MASK		0xff
+
+/*
+ * Matches TEEC_LOGIN_* in GP TEE Client API
+ * Is only defined for GP compliant TEEs
+ */
+#define TEE_IOCTL_LOGIN_PUBLIC			0
+#define TEE_IOCTL_LOGIN_USER			1
+#define TEE_IOCTL_LOGIN_GROUP			2
+#define TEE_IOCTL_LOGIN_APPLICATION		4
+#define TEE_IOCTL_LOGIN_USER_APPLICATION	5
+#define TEE_IOCTL_LOGIN_GROUP_APPLICATION	6
+
+/**
+ * struct tee_ioctl_param_memref - memory reference
+ * @shm_offs:	Offset into the shared memory object
+ * @size:	Size of the buffer
+ * @shm_fd:	Shared memory file descriptor
+ *
+ * Shared memory is allocated with TEE_IOC_SHM_ALLOC which returns a file
+ * descriptor connected to the shared memory object. A memref can reference
+ * a part of a shared memory by specifying an offset (@shm_offs) and @size
+ * of the object. To supply the entire shared memory object set @shm_offs to 0
+ * and @size to the previously returned size of the object.
+ */
+struct tee_ioctl_param_memref {
+	__u64 shm_offs;
+	__u64 size;
+	__s64 shm_fd;
+};
+
+/**
+ * struct tee_ioctl_param_value - values
+ * @a: first value
+ * @b: second value
+ * @c: third value
+ */
+struct tee_ioctl_param_value {
+	__u64 a;
+	__u64 b;
+	__u64 c;
+};
+
+/**
+ * struct tee_ioctl_param - parameter
+ * @attr: attributes
+ * @memref: a memory reference
+ * @value: a value
+ *
+ * @attr & TEE_PARAM_ATTR_TYPE_MASK indicates if memref or value is used in
+ * the union. TEE_PARAM_ATTR_TYPE_VALUE_* indicates value and
+ * TEE_PARAM_ATTR_TYPE_MEMREF_* indicates memref. TEE_PARAM_ATTR_TYPE_NONE
+ * indicates that none of the members are used.
+ */
+struct tee_ioctl_param {
+	__u64 attr;
+	union {
+		struct tee_ioctl_param_memref memref;
+		struct tee_ioctl_param_value value;
+	} u;
+};
+
+#define TEE_IOCTL_UUID_LEN		16
+
+/**
+ * struct tee_ioctl_open_session_arg - Open session argument
+ * @uuid:	[in] UUID of the Trusted Application
+ * @clnt_uuid:	[in] UUID of client
+ * @clnt_login:	[in] Login class of client, TEE_LOGIN_* above
+ * @cancel_id:	[in] Cancellation id, a unique value to identify this request
+ * @session:	[out] Session id
+ * @ret:	[out] return value
+ * @ret_origin	[out] origin of the return value
+ * @num_params	[in] number of parameters following this struct
+ */
+struct tee_ioctl_open_session_arg {
+	__u8 uuid[TEE_IOCTL_UUID_LEN];
+	__u8 clnt_uuid[TEE_IOCTL_UUID_LEN];
+	__u32 clnt_login;
+	__u32 cancel_id;
+	__u32 session;
+	__u32 ret;
+	__u32 ret_origin;
+	__u32 num_params;
+	/*
+	 * this struct is 8 byte aligned since the 'struct tee_ioctl_param'
+	 * which follows requires 8 byte alignment.
+	 *
+	 * Commented out element used to visualize the layout dynamic part
+	 * of the struct. This field is not available at all if
+	 * num_params == 0.
+	 *
+	 * struct tee_ioctl_param params[num_params];
+	 */
+} __aligned(8);
+
+/**
+ * TEE_IOC_OPEN_SESSION - opens a session to a Trusted Application
+ *
+ * Takes a struct tee_ioctl_buf_data which contains a struct
+ * tee_ioctl_open_session_arg followed by any array of struct
+ * tee_ioctl_param
+ */
+#define TEE_IOC_OPEN_SESSION	_IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 2, \
+				     struct tee_ioctl_buf_data)
+
+/**
+ * struct tee_ioctl_invoke_func_arg - Invokes a function in a Trusted Application
+ * @func:	[in] Trusted Application function, specific to the TA
+ * @session:	[in] Session id
+ * @cancel_id:	[in] Cancellation id, a unique value to identify this request
+ * @ret:	[out] return value
+ * @ret_origin	[out] origin of the return value
+ * @num_params	[in] number of parameters following this struct
+ */
+struct tee_ioctl_invoke_arg {
+	__u32 func;
+	__u32 session;
+	__u32 cancel_id;
+	__u32 ret;
+	__u32 ret_origin;
+	__u32 num_params;
+	/*
+	 * this struct is 8 byte aligned since the 'struct tee_ioctl_param'
+	 * which follows requires 8 byte alignment.
+	 *
+	 * Commented out element used to visualize the layout dynamic part
+	 * of the struct. This field is not available at all if
+	 * num_params == 0.
+	 *
+	 * struct tee_ioctl_param params[num_params];
+	 */
+} __aligned(8);
+
+/**
+ * TEE_IOC_INVOKE - Invokes a function in a Trusted Application
+ *
+ * Takes a struct tee_ioctl_buf_data which contains a struct
+ * tee_invoke_func_arg followed by any array of struct tee_param
+ */
+#define TEE_IOC_INVOKE		_IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 3, \
+				     struct tee_ioctl_buf_data)
+
+/**
+ * struct tee_ioctl_cancel_arg - Cancels an open session or invoke ioctl
+ * @cancel_id:	[in] Cancellation id, a unique value to identify this request
+ * @session:	[in] Session id, if the session is opened, else set to 0
+ */
+struct tee_ioctl_cancel_arg {
+	__u32 cancel_id;
+	__u32 session;
+};
+/**
+ * TEE_IOC_CANCEL - Cancels an open session or invoke
+ */
+#define TEE_IOC_CANCEL		_IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 4, \
+				     struct tee_ioctl_cancel_arg)
+
+/**
+ * struct tee_ioctl_close_session_arg - Closes an open session
+ * @session:	[in] Session id
+ */
+struct tee_ioctl_close_session_arg {
+	__u32 session;
+};
+/**
+ * TEE_IOC_CLOSE_SESSION - Closes a session
+ */
+#define TEE_IOC_CLOSE_SESSION	_IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 5, \
+				     struct tee_ioctl_close_session_arg)
+
+/**
+ * struct tee_iocl_supp_recv_arg - Receive a request for a supplicant function
+ * @func:	[in] supplicant function
+ * @num_params	[in/out] number of parameters following this struct
+ *
+ * @num_params is the number of params that tee-supplicant has room to
+ * receive when input, @num_params is the number of actual params
+ * tee-supplicant receives when output.
+ */
+struct tee_iocl_supp_recv_arg {
+	__u32 func;
+	__u32 num_params;
+	/*
+	 * this struct is 8 byte aligned since the 'struct tee_ioctl_param'
+	 * which follows requires 8 byte alignment.
+	 *
+	 * Commented out element used to visualize the layout dynamic part
+	 * of the struct. This field is not available at all if
+	 * num_params == 0.
+	 *
+	 * struct tee_ioctl_param params[num_params];
+	 */
+} __aligned(8);
+/**
+ * TEE_IOC_SUPPL_RECV - Receive a request for a supplicant function
+ *
+ * Takes a struct tee_ioctl_buf_data which contains a struct
+ * tee_iocl_supp_recv_arg followed by any array of struct tee_param
+ */
+#define TEE_IOC_SUPPL_RECV	_IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 6, \
+				     struct tee_ioctl_buf_data)
+
+
+/**
+ * struct tee_iocl_supp_send_arg - Send a response to a received request
+ * @ret:	[out] return value
+ * @num_params	[in] number of parameters following this struct
+ */
+struct tee_iocl_supp_send_arg {
+	__u32 ret;
+	__u32 num_params;
+	/*
+	 * this struct is 8 byte aligned since the 'struct tee_ioctl_param'
+	 * which follows requires 8 byte alignment.
+	 *
+	 * Commented out element used to visualize the layout dynamic part
+	 * of the struct. This field is not available at all if
+	 * num_params == 0.
+	 *
+	 * struct tee_ioctl_param params[num_params];
+	 */
+} __aligned(8);
+/**
+ * TEE_IOC_SUPPL_SEND - Receive a request for a supplicant function
+ *
+ * Takes a struct tee_ioctl_buf_data which contains a struct
+ * tee_iocl_supp_send_arg followed by any array of struct tee_param
+ */
+#define TEE_IOC_SUPPL_SEND	_IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 7, \
+				     struct tee_ioctl_buf_data)
+
+
+/*
+ * Five syscalls are used when communicating with the TEE driver.
+ * open(): opens the device associated with the driver
+ * ioctl(): as described above operating on the file descriptor from open()
+ * close(): two cases
+ *   - closes the device file descriptor
+ *   - closes a file descriptor connected to allocated shared memory
+ * mmap(): maps shared memory into user space using information from struct
+ *	   tee_ioctl_shm_alloc_data
+ * munmap(): unmaps previously shared memory
+ */
+
+#endif /*__TEE_H*/
-- 
1.9.1



From lorenzo.pieralisi at arm.com  Thu Feb 11 09:17:00 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 11 Feb 2016 17:17:00 +0000
Subject: [PATCH V4 22/23] arm64, pci, acpi: Assign legacy IRQs once
 device is enable.
In-Reply-To: <20160211115843.GA24136@red-moon>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
 <1454606941-9523-23-git-send-email-tn@semihalf.com>
 <20160211115843.GA24136@red-moon>
Message-ID: <20160211171700.GB25235@red-moon>

On Thu, Feb 11, 2016 at 11:58:53AM +0000, Lorenzo Pieralisi wrote:
> On Thu, Feb 04, 2016 at 06:29:00PM +0100, Tomasz Nowicki wrote:
> > This is the last step before enabling generic ACPI PCI host controller
> > for ARM64. We need to take care of legacy IRQ mapping for non-MSI(X)
> > PCI devices. pcibios_enable_device() boot order is not sensitive to
> > ACPI device enumeration, so it is the best place to assign device's IRQs.
> 
> I guess you are referring to:
> 
> https://lists.linaro.org/pipermail/linaro-acpi/2015-October/005944.html
> 
> It is weird that the dependency can't be enforced, I will have a look
> into this, it would be nice to have DT and ACPI legacy IRQs mapping
> confined in pcibios_add_device() so that we can remove them in one go
> when Matthew's series is merged.

One option, that is not ideal but has the merit of setting the stage
for pcibios_enable_device() AND pcibios_add_device() removal, is to add
IRQ mapping (by adding the call) in a pcibios_alloc_irq() callback (if
Bjorn does not remove it from core code before we manage to add it,
I think he is only reverting the x86 version).

https://lkml.org/lkml/2016/2/9/648

That's called at device probe time, it should not change DT probing path
(unless we use the irq number before the device is probed, which I doubt)
and should allow the ACPI scan handlers to be installed so that the ACPI
IRQ mapping can be effectively carried out.

pcibios_alloc_irq() replaces pcibios_add_device().

When Matthew's patchset lands in mainline, pcibios_alloc_irq() will
be removed too (at least we have a place where all legacy IRQ mappings
are carried out and I can obliterate it easily).

Other option is to change ACPI core code, I see no other way.

Tested on KVM PCI host generic (that uses pci_fixup_irqs() so it does
not really count for DT).

Here (on top of your series), ready for flak.

Lorenzo

-- >8 --
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 0b53262..26ee291 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -45,28 +45,23 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
  */
 int pcibios_enable_device(struct pci_dev *dev, int mask)
 {
-	int ret;
-
 	if (pci_has_flag(PCI_PROBE_ONLY))
 		return 0;
 
-	ret = pci_enable_resources(dev, mask);
-	if (ret < 0)
-		return ret;
-
-#ifdef CONFIG_ACPI
-	if (!pci_dev_msi_enabled(dev))
-		return acpi_pci_irq_enable(dev);
-#endif
-	return 0;
+	return pci_enable_resources(dev, mask);
 }
 
 /*
- * Try to assign the IRQ number from DT when adding a new device
+ * Try to assign the IRQ number when probing a new device
  */
-int pcibios_add_device(struct pci_dev *dev)
+int pcibios_alloc_irq(struct pci_dev *dev)
 {
-	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
+	if (acpi_disabled)
+		dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
+#ifdef CONFIG_ACPI
+	else
+		return acpi_pci_irq_enable(dev);
+#endif
 
 	return 0;
 }


From jens.wiklander at linaro.org  Thu Feb 11 09:14:37 2016
From: jens.wiklander at linaro.org (Jens Wiklander)
Date: Thu, 11 Feb 2016 18:14:37 +0100
Subject: [PATCH v8 4/4] Documentation: tee subsystem and op-tee driver
In-Reply-To: <1455210877-15748-1-git-send-email-jens.wiklander@linaro.org>
References: <1455210877-15748-1-git-send-email-jens.wiklander@linaro.org>
Message-ID: <1455210877-15748-5-git-send-email-jens.wiklander@linaro.org>

Signed-off-by: Jens Wiklander <jens.wiklander at linaro.org>
---
 Documentation/00-INDEX |   2 +
 Documentation/tee.txt  | 117 +++++++++++++++++++++++++++++++++++++++++++++++++
 MAINTAINERS            |   1 +
 3 files changed, 120 insertions(+)
 create mode 100644 Documentation/tee.txt

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index cd077ca..bd3f803 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -435,6 +435,8 @@ sysrq.txt
 	- info on the magic SysRq key.
 target/
 	- directory with info on generating TCM v4 fabric .ko modules
+tee.txt
+	- info on the TEE subsystem and drivers
 this_cpu_ops.txt
 	- List rationale behind and the way to use this_cpu operations.
 thermal/
diff --git a/Documentation/tee.txt b/Documentation/tee.txt
new file mode 100644
index 0000000..4ac91d2
--- /dev/null
+++ b/Documentation/tee.txt
@@ -0,0 +1,117 @@
+TEE subsystem
+This document describes the TEE subsystem in Linux
+
+A TEE (Trusted Execution Environment) is a trusted OS running in some
+secure environment, for example, TrustZone on ARM CPUs, or a separate
+secure co-processor etc. A TEE driver handles the details needed to
+communicate with the TEE.
+
+This subsystem deals with:
+
+- Registration of TEE drivers
+
+- Managing shared memory between Linux and the TEE
+
+- Providing a generic API to the TEE
+
+The TEE interface
+=================
+
+include/uapi/linux/tee.h defines the generic interface to a TEE.
+
+User space (the client) connects to the driver by opening /dev/tee[0-9]* or
+/dev/teepriv[0-9]*.
+
+- TEE_IOC_SHM_ALLOC allocates shared memory and returns a file descriptor which
+  user space can mmap. When user space doesn't need the file descriptor anymore
+  it should be closed. When shared memory isn't needed any longer it should be
+  unmapped with munmap() to allow the reuse of memory.
+
+- TEE_IOC_VERSION lets user space know which TEE this driver handles and
+  the its capabilities.
+
+- TEE_IOC_OPEN_SESSION opens a new session to a Trusted Application
+
+- TEE_IOC_INVOKE invokes a function in a Trusted Application
+
+- TEE_IOC_CANCEL may cancel an ongoing TEE_IOC_OPEN_SESSION or TEE_IOC_INVOKE
+
+- TEE_IOC_CLOSE_SESSION closes a session to a Trusted Application
+
+There are two classes of clients, normal clients and supplicants. The latter is
+a helper process for the TEE to access resources in Linux, for example file
+system access. A normal client opens /dev/tee[0-9]* and a supplicant opens
+/dev/teepriv[0-9].
+
+Much of the communication between clients and the TEE is opaque to the
+driver. The main job for the driver is to receive requests from the
+clients, forward them to the TEE and send back the results. In the case of
+supplicants the communication goes in the other direction, the TEE sends
+requests to the supplicant which then sends back the result.
+
+OP-TEE driver
+=============
+
+The OP-TEE driver handles OP-TEE [1] based TEEs. Currently it is only the ARM
+TrustZone based OP-TEE solution that is supported.
+
+Lowest level of communication with OP-TEE builds on ARM SMC Calling
+Convention (SMCCC) [2], which is the foundation for OP-TEE's SMC interface
+[3] used internally by the driver. Stacked on top of that is OP-TEE Message
+Protocol [4].
+
+OP-TEE SMC interface provides the basic functions required by SMCCC and some
+additional functions specific for OP-TEE. The most interesting functions are:
+
+- OPTEE_SMC_FUNCID_CALLS_UID (part of SMCCC) returns the version information
+  which is then returned by TEE_IOC_VERSION
+
+- OPTEE_SMC_CALL_GET_OS_UUID returns the particular OP-TEE implementation, used
+  to tell, for instance, a TrustZone OP-TEE apart from an OP-TEE running on a
+  separate secure co-processor.
+
+- OPTEE_SMC_CALL_WITH_ARG drives the OP-TEE message protocol
+
+- OPTEE_SMC_GET_SHM_CONFIG lets the driver and OP-TEE agree on which memory
+  range to used for shared memory between Linux and OP-TEE.
+
+The GlobalPlatform TEE Client API [5] is implemented on top of the generic
+TEE API.
+
+Picture of the relationship between the different components in the
+OP-TEE architecture.
+
+    User space                  Kernel                   Secure world
+    ~~~~~~~~~~                  ~~~~~~                   ~~~~~~~~~~~~
+ +--------+                                             +-------------+
+ | Client |                                             | Trusted     |
+ +--------+                                             | Application |
+    /\                                                  +-------------+
+    || +----------+                                           /\
+    || |tee-      |                                           ||
+    || |supplicant|                                           \/
+    || +----------+                                     +-------------+
+    \/      /\                                          | TEE Internal|
+ +-------+  ||                                          | API         |
+ + TEE   |  ||            +--------+--------+           +-------------+
+ | Client|  ||            | TEE    | OP-TEE |           | OP-TEE      |
+ | API   |  \/            | subsys | driver |           | Trusted OS  |
+ +-------+----------------+----+-------+----+-----------+-------------+
+ |      Generic TEE API        |       |     OP-TEE MSG               |
+ |      IOCTL (TEE_IOC_*)      |       |     SMCCC (OPTEE_SMC_CALL_*) |
+ +-----------------------------+       +------------------------------+
+
+RPC (Remote Procedure Call) are requests from secure world to kernel driver
+or tee-supplicant. An RPC is identified by a special range of SMCCC return
+values from OPTEE_SMC_CALL_WITH_ARG. RPC messages which are intended for the
+kernel are handled by the kernel driver. Other RPC messages will be forwarded to
+tee-supplicant without further involvement of the driver, except switching
+shared memory buffer representation.
+
+References:
+[1] https://github.com/OP-TEE/optee_os
+[2] http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
+[3] drivers/tee/optee/optee_smc.h
+[4] drivers/tee/optee/optee_msg.h
+[5] http://www.globalplatform.org/specificationsdevice.asp look for
+    "TEE Client API Specification v1.0" and click download.
diff --git a/MAINTAINERS b/MAINTAINERS
index f13414a..29af59a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9572,6 +9572,7 @@ S:	Maintained
 F:	include/linux/tee_drv.h
 F:	include/uapi/linux/tee.h
 F:	drivers/tee/
+F:	Documentation/tee.txt
 
 THUNDERBOLT DRIVER
 M:	Andreas Noever <andreas.noever at gmail.com>
-- 
1.9.1



From jens.wiklander at linaro.org  Thu Feb 11 09:14:36 2016
From: jens.wiklander at linaro.org (Jens Wiklander)
Date: Thu, 11 Feb 2016 18:14:36 +0100
Subject: [PATCH v8 3/4] tee: add OP-TEE driver
In-Reply-To: <1455210877-15748-1-git-send-email-jens.wiklander@linaro.org>
References: <1455210877-15748-1-git-send-email-jens.wiklander@linaro.org>
Message-ID: <1455210877-15748-4-git-send-email-jens.wiklander@linaro.org>

Adds a OP-TEE driver which also can be compiled as a loadable module.

* Targets ARM and ARM64
* Supports using reserved memory from OP-TEE as shared memory
* Probes OP-TEE version using SMCs
* Accepts requests on privileged and unprivileged device
* Uses OPTEE message protocol version 2 to communicate with secure world

Signed-off-by: Jens Wiklander <jens.wiklander at linaro.org>
---
 MAINTAINERS                       |   5 +
 drivers/tee/Kconfig               |  10 +
 drivers/tee/Makefile              |   1 +
 drivers/tee/optee/Kconfig         |   8 +
 drivers/tee/optee/Makefile        |   5 +
 drivers/tee/optee/call.c          | 400 +++++++++++++++++++++++++++++
 drivers/tee/optee/core.c          | 522 ++++++++++++++++++++++++++++++++++++++
 drivers/tee/optee/optee_msg.h     | 423 ++++++++++++++++++++++++++++++
 drivers/tee/optee/optee_private.h | 146 +++++++++++
 drivers/tee/optee/optee_smc.h     | 418 ++++++++++++++++++++++++++++++
 drivers/tee/optee/rpc.c           | 322 +++++++++++++++++++++++
 drivers/tee/optee/supp.c          | 212 ++++++++++++++++
 12 files changed, 2472 insertions(+)
 create mode 100644 drivers/tee/optee/Kconfig
 create mode 100644 drivers/tee/optee/Makefile
 create mode 100644 drivers/tee/optee/call.c
 create mode 100644 drivers/tee/optee/core.c
 create mode 100644 drivers/tee/optee/optee_msg.h
 create mode 100644 drivers/tee/optee/optee_private.h
 create mode 100644 drivers/tee/optee/optee_smc.h
 create mode 100644 drivers/tee/optee/rpc.c
 create mode 100644 drivers/tee/optee/supp.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b2bae0e..f13414a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8083,6 +8083,11 @@ F:	arch/*/oprofile/
 F:	drivers/oprofile/
 F:	include/linux/oprofile.h
 
+OP-TEE DRIVER
+M:	Jens Wiklander <jens.wiklander at linaro.org>
+S:	Maintained
+F:	drivers/tee/optee/
+
 ORACLE CLUSTER FILESYSTEM 2 (OCFS2)
 M:	Mark Fasheh <mfasheh at suse.com>
 M:	Joel Becker <jlbec at evilplan.org>
diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
index f3ba154..7228045 100644
--- a/drivers/tee/Kconfig
+++ b/drivers/tee/Kconfig
@@ -7,3 +7,13 @@ config TEE
 	help
 	  This implements a generic interface towards a Trusted Execution
 	  Environment (TEE).
+
+if TEE
+
+menu "TEE drivers"
+
+source "drivers/tee/optee/Kconfig"
+
+endmenu
+
+endif
diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
index 60d2dab..53f3c76 100644
--- a/drivers/tee/Makefile
+++ b/drivers/tee/Makefile
@@ -1,3 +1,4 @@
 obj-y += tee.o
 obj-y += tee_shm.o
 obj-y += tee_shm_pool.o
+obj-$(CONFIG_OPTEE) += optee/
diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
new file mode 100644
index 0000000..a7a8b71
--- /dev/null
+++ b/drivers/tee/optee/Kconfig
@@ -0,0 +1,8 @@
+# OP-TEE Trusted Execution Environment Configuration
+config OPTEE
+	tristate "OP-TEE"
+	default n
+	depends on HAVE_ARM_SMCCC
+	help
+	  This implements the OP-TEE Trusted Execution Environment (TEE)
+	  driver.
diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
new file mode 100644
index 0000000..92fe578
--- /dev/null
+++ b/drivers/tee/optee/Makefile
@@ -0,0 +1,5 @@
+obj-$(CONFIG_OPTEE) += optee.o
+optee-objs += core.o
+optee-objs += call.o
+optee-objs += rpc.o
+optee-objs += supp.o
diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
new file mode 100644
index 0000000..c567f98
--- /dev/null
+++ b/drivers/tee/optee/call.c
@@ -0,0 +1,400 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/types.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <linux/device.h>
+#include <linux/tee_drv.h>
+#include <linux/arm-smccc.h>
+#include "optee_private.h"
+#include "optee_smc.h"
+
+struct optee_call_waiter {
+	struct list_head list_node;
+	struct completion c;
+	bool completed;
+};
+
+static void optee_cq_wait_init(struct optee_call_queue *cq,
+			struct optee_call_waiter *w)
+{
+	mutex_lock(&cq->mutex);
+	/*
+	 * We add ourselves to the queue, but we don't wait. This
+	 * guarentees that we don't lose a completion if secure world
+	 * returns busy and another thread just exited and try to complete
+	 * someone.
+	 */
+	w->completed = false;
+	init_completion(&w->c);
+	list_add_tail(&w->list_node, &cq->waiters);
+	mutex_unlock(&cq->mutex);
+}
+
+static void optee_cq_wait_for_completion(struct optee_call_queue *cq,
+			struct optee_call_waiter *w)
+{
+	wait_for_completion(&w->c);
+
+	mutex_lock(&cq->mutex);
+
+	/* Move to end of list to get out of the way for other waiters */
+	list_del(&w->list_node);
+	w->completed = false;
+	reinit_completion(&w->c);
+	list_add_tail(&w->list_node, &cq->waiters);
+
+	mutex_unlock(&cq->mutex);
+}
+
+static void optee_cq_complete_one(struct optee_call_queue *cq)
+{
+	struct optee_call_waiter *w;
+
+	list_for_each_entry(w, &cq->waiters, list_node) {
+		if (!w->completed) {
+			complete(&w->c);
+			w->completed = true;
+			break;
+		}
+	}
+}
+
+static void optee_cq_wait_final(struct optee_call_queue *cq,
+			struct optee_call_waiter *w)
+{
+	mutex_lock(&cq->mutex);
+
+	/* Get out of the list */
+	list_del(&w->list_node);
+
+	optee_cq_complete_one(cq);
+	/*
+	 * If we're completed we've got a completion that some other task
+	 * could have used instead.
+	 */
+	if (w->completed)
+		optee_cq_complete_one(cq);
+
+	mutex_unlock(&cq->mutex);
+}
+
+/* Requires the filpstate mutex to be held */
+static struct optee_session *find_session(struct optee_context_data *ctxdata,
+			u32 session_id)
+{
+	struct optee_session *sess;
+
+	list_for_each_entry(sess, &ctxdata->sess_list, list_node)
+		if (sess->session_id == session_id)
+			return sess;
+	return NULL;
+}
+
+u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg)
+{
+	struct optee *optee = tee_get_drvdata(ctx->teedev);
+	struct optee_call_waiter w;
+	struct optee_rpc_param param = { };
+	u32 ret;
+
+	param.a0 = OPTEE_SMC_CALL_WITH_ARG;
+	reg_pair_from_64(&param.a1, &param.a2, parg);
+	/* Initialize waiter */
+	optee_cq_wait_init(&optee->call_queue, &w);
+	while (true) {
+		struct arm_smccc_res res;
+
+		optee->invoke_fn(param.a0, param.a1, param.a2, param.a3,
+				 param.a4, param.a5, param.a6, param.a7,
+				 &res);
+
+		if (res.a0 == OPTEE_SMC_RETURN_ETHREAD_LIMIT) {
+			/*
+			 * Out of threads in secure world, wait for a thread
+			 * become available.
+			 */
+			optee_cq_wait_for_completion(&optee->call_queue, &w);
+		} else if (OPTEE_SMC_RETURN_IS_RPC(res.a0)) {
+			param.a0 = res.a0;
+			param.a1 = res.a1;
+			param.a2 = res.a2;
+			param.a3 = res.a3;
+			optee_handle_rpc(ctx, &param);
+		} else {
+			ret = res.a0;
+			break;
+		}
+	}
+	/*
+	 * We're done with our thread in secure world, if there's any
+	 * thread waiters wake up one.
+	 */
+	optee_cq_wait_final(&optee->call_queue, &w);
+	return ret;
+}
+
+static struct tee_shm *get_msg_arg(struct tee_context *ctx, size_t num_params,
+			struct optee_msg_arg **msg_arg, phys_addr_t *msg_parg)
+{
+	int rc;
+	struct tee_shm *shm;
+	struct optee_msg_arg *ma;
+
+	shm = tee_shm_alloc(ctx->teedev, OPTEE_MSG_GET_ARG_SIZE(num_params),
+			    TEE_SHM_MAPPED);
+	if (IS_ERR(shm))
+		return shm;
+	ma = tee_shm_get_va(shm, 0);
+	if (IS_ERR(ma)) {
+		rc = PTR_ERR(ma);
+		goto out;
+	}
+	rc = tee_shm_get_pa(shm, 0, msg_parg);
+	if (rc)
+		goto out;
+
+	memset(ma, 0, OPTEE_MSG_GET_ARG_SIZE(num_params));
+	ma->num_params = num_params;
+	*msg_arg = ma;
+out:
+	if (rc) {
+		tee_shm_free(shm);
+		return ERR_PTR(rc);
+	}
+	return shm;
+}
+
+int optee_open_session(struct tee_context *ctx,
+			struct tee_ioctl_open_session_arg *arg,
+			struct tee_param *param)
+{
+	struct optee_context_data *ctxdata = ctx->data;
+	int rc;
+	struct tee_shm *shm;
+	struct optee_msg_arg *msg_arg;
+	phys_addr_t msg_parg;
+	struct optee_msg_param *msg_param;
+	struct optee_session *sess = NULL;
+
+	/* +2 for the meta parameters added below */
+	shm = get_msg_arg(ctx, arg->num_params + 2, &msg_arg, &msg_parg);
+	if (IS_ERR(shm))
+		return PTR_ERR(shm);
+
+	msg_arg->cmd = OPTEE_MSG_CMD_OPEN_SESSION;
+	msg_arg->cancel_id = arg->cancel_id;
+	msg_param = OPTEE_MSG_GET_PARAMS(msg_arg);
+
+	/*
+	 * Initialize and add the meta parameters needed when opening a
+	 * session.
+	 */
+	msg_param[0].attr = OPTEE_MSG_ATTR_TYPE_VALUE_INPUT |
+			    OPTEE_MSG_ATTR_META;
+	msg_param[1].attr = OPTEE_MSG_ATTR_TYPE_VALUE_INPUT |
+			    OPTEE_MSG_ATTR_META;
+	memcpy(&msg_param[0].u.value, arg->uuid, sizeof(arg->uuid));
+	memcpy(&msg_param[1].u.value, arg->uuid, sizeof(arg->clnt_uuid));
+	msg_param[1].u.value.c = arg->clnt_login;
+
+	rc = optee_to_msg_param(msg_param + 2, arg->num_params, param);
+	if (rc)
+		goto out;
+
+	sess = kzalloc(sizeof(struct optee_session), GFP_KERNEL);
+	if (!sess) {
+		rc = -ENOMEM;
+		goto out;
+	}
+
+	if (optee_do_call_with_arg(ctx, msg_parg)) {
+		msg_arg->ret = TEEC_ERROR_COMMUNICATION;
+		msg_arg->ret_origin = TEEC_ORIGIN_COMMS;
+	}
+
+	if (msg_arg->ret == TEEC_SUCCESS) {
+		/* A new session has been created, add it to the list. */
+		sess->session_id = msg_arg->session;
+		mutex_lock(&ctxdata->mutex);
+		list_add(&sess->list_node, &ctxdata->sess_list);
+		mutex_unlock(&ctxdata->mutex);
+		sess = NULL;
+	}
+
+	if (optee_from_msg_param(param, arg->num_params, msg_param + 2)) {
+		arg->ret = TEEC_ERROR_COMMUNICATION;
+		arg->ret_origin = TEEC_ORIGIN_COMMS;
+		/* Close session again to avoid leakage */
+		optee_close_session(ctx, msg_arg->session);
+	} else {
+		arg->session = msg_arg->session;
+		arg->ret = msg_arg->ret;
+		arg->ret_origin = msg_arg->ret_origin;
+	}
+out:
+	kfree(sess);
+	tee_shm_free(shm);
+	return rc;
+}
+
+int optee_close_session(struct tee_context *ctx, u32 session)
+{
+	struct optee_context_data *ctxdata = ctx->data;
+	struct tee_shm *shm;
+	struct optee_msg_arg *msg_arg;
+	phys_addr_t msg_parg;
+	struct optee_session *sess;
+
+	/* Check that the session is valid and remove it from the list */
+	mutex_lock(&ctxdata->mutex);
+	sess = find_session(ctxdata, session);
+	if (sess)
+		list_del(&sess->list_node);
+	mutex_unlock(&ctxdata->mutex);
+	if (!sess)
+		return -EINVAL;
+	kfree(sess);
+
+	shm = get_msg_arg(ctx, 0, &msg_arg, &msg_parg);
+	if (IS_ERR(shm))
+		return PTR_ERR(shm);
+
+	msg_arg->cmd = OPTEE_MSG_CMD_CLOSE_SESSION;
+	msg_arg->session = session;
+	optee_do_call_with_arg(ctx, msg_parg);
+
+	tee_shm_free(shm);
+	return 0;
+}
+
+int optee_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg,
+			struct tee_param *param)
+{
+	struct optee_context_data *ctxdata = ctx->data;
+	struct tee_shm *shm;
+	struct optee_msg_arg *msg_arg;
+	phys_addr_t msg_parg;
+	struct optee_msg_param *msg_param;
+	struct optee_session *sess;
+	int rc;
+
+	/* Check that the session is valid */
+	mutex_lock(&ctxdata->mutex);
+	sess = find_session(ctxdata, arg->session);
+	mutex_unlock(&ctxdata->mutex);
+	if (!sess)
+		return -EINVAL;
+
+	shm = get_msg_arg(ctx, arg->num_params, &msg_arg, &msg_parg);
+	if (IS_ERR(shm))
+		return PTR_ERR(shm);
+	msg_arg->cmd = OPTEE_MSG_CMD_INVOKE_COMMAND;
+	msg_arg->func = arg->func;
+	msg_arg->session = arg->session;
+	msg_arg->cancel_id = arg->cancel_id;
+	msg_param = OPTEE_MSG_GET_PARAMS(msg_arg);
+
+	rc = optee_to_msg_param(msg_param, arg->num_params, param);
+	if (rc)
+		goto out;
+
+	if (optee_do_call_with_arg(ctx, msg_parg)) {
+		msg_arg->ret = TEEC_ERROR_COMMUNICATION;
+		msg_arg->ret_origin = TEEC_ORIGIN_COMMS;
+	}
+
+	if (optee_from_msg_param(param, arg->num_params, msg_param)) {
+		msg_arg->ret = TEEC_ERROR_COMMUNICATION;
+		msg_arg->ret_origin = TEEC_ORIGIN_COMMS;
+	}
+
+	arg->ret = msg_arg->ret;
+	arg->ret_origin = msg_arg->ret_origin;
+out:
+	tee_shm_free(shm);
+	return rc;
+}
+
+int optee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session)
+{
+	struct optee_context_data *ctxdata = ctx->data;
+	struct tee_shm *shm;
+	struct optee_msg_arg *msg_arg;
+	phys_addr_t msg_parg;
+	struct optee_session *sess;
+
+	/* Check that the session is valid */
+	mutex_lock(&ctxdata->mutex);
+	sess = find_session(ctxdata, session);
+	mutex_unlock(&ctxdata->mutex);
+	if (!sess)
+		return -EINVAL;
+
+	shm = get_msg_arg(ctx, 0, &msg_arg, &msg_parg);
+	if (IS_ERR(shm))
+		return PTR_ERR(shm);
+
+	msg_arg->cmd = OPTEE_MSG_CMD_CANCEL;
+	msg_arg->session = session;
+	msg_arg->cancel_id = cancel_id;
+	optee_do_call_with_arg(ctx, msg_parg);
+
+	tee_shm_free(shm);
+	return 0;
+}
+
+void optee_enable_shm_cache(struct optee *optee)
+{
+	struct optee_call_waiter w;
+
+	/* We need to retry until secure world isn't busy. */
+	optee_cq_wait_init(&optee->call_queue, &w);
+	while (true) {
+		struct arm_smccc_res res;
+
+		optee->invoke_fn(OPTEE_SMC_ENABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0,
+				 0, &res);
+		if (res.a0 == OPTEE_SMC_RETURN_OK)
+			break;
+		optee_cq_wait_for_completion(&optee->call_queue, &w);
+	}
+	optee_cq_wait_final(&optee->call_queue, &w);
+}
+
+void optee_disable_shm_cache(struct optee *optee)
+{
+	struct optee_call_waiter w;
+
+	/* We need to retry until secure world isn't busy. */
+	optee_cq_wait_init(&optee->call_queue, &w);
+	while (true) {
+		struct arm_smccc_res res;
+
+		optee->invoke_fn(OPTEE_SMC_DISABLE_SHM_CACHE, 0, 0, 0, 0, 0, 0,
+				 0, &res);
+		if (res.a0 == OPTEE_SMC_RETURN_ENOTAVAIL)
+			break; /* All shm's freed */
+		if (res.a0 == OPTEE_SMC_RETURN_OK) {
+			struct tee_shm *shm;
+
+			shm = reg_pair_to_ptr(res.a1, res.a2);
+			tee_shm_free(shm);
+		} else
+			optee_cq_wait_for_completion(&optee->call_queue, &w);
+	}
+	optee_cq_wait_final(&optee->call_queue, &w);
+}
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
new file mode 100644
index 0000000..874550c
--- /dev/null
+++ b/drivers/tee/optee/core.c
@@ -0,0 +1,522 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/types.h>
+#include <linux/string.h>
+#include <linux/errno.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/tee_drv.h>
+#include "optee_private.h"
+#include "optee_smc.h"
+
+#define DRIVER_NAME "optee"
+
+#define OPTEE_SHM_NUM_PRIV_PAGES	1
+
+int optee_from_msg_param(struct tee_param *params, size_t num_params,
+			const struct optee_msg_param *msg_params)
+{
+	int rc;
+	size_t n;
+	struct tee_shm *shm;
+	phys_addr_t pa;
+
+	for (n = 0; n < num_params; n++) {
+		struct tee_param *p = params + n;
+		const struct optee_msg_param *mp = msg_params + n;
+		u32 attr = mp->attr & OPTEE_MSG_ATTR_TYPE_MASK;
+
+		switch (attr) {
+		case OPTEE_MSG_ATTR_TYPE_NONE:
+			p->attr = TEE_IOCTL_PARAM_ATTR_TYPE_NONE;
+			memset(&p->u, 0, sizeof(p->u));
+			break;
+		case OPTEE_MSG_ATTR_TYPE_VALUE_INPUT:
+		case OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT:
+		case OPTEE_MSG_ATTR_TYPE_VALUE_INOUT:
+			p->attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT +
+				  attr - OPTEE_MSG_ATTR_TYPE_VALUE_INPUT;
+			p->u.value.a = mp->u.value.a;
+			p->u.value.b = mp->u.value.b;
+			p->u.value.c = mp->u.value.c;
+			break;
+		case OPTEE_MSG_ATTR_TYPE_TMEM_INPUT:
+		case OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT:
+		case OPTEE_MSG_ATTR_TYPE_TMEM_INOUT:
+			p->attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT +
+				  attr - OPTEE_MSG_ATTR_TYPE_TMEM_INPUT;
+			p->u.memref.size = mp->u.tmem.size;
+			shm = (struct tee_shm *)(unsigned long)
+				mp->u.tmem.shm_ref;
+			if (!shm) {
+				p->u.memref.shm_offs = 0;
+				p->u.memref.shm = NULL;
+				break;
+			}
+			rc = tee_shm_get_pa(shm, 0, &pa);
+			if (rc)
+				return rc;
+			p->u.memref.shm_offs = pa - mp->u.tmem.buf_ptr;
+			p->u.memref.shm = shm;
+
+			/* Check that the memref is covered by the shm object */
+			if (p->u.memref.size) {
+				size_t o = p->u.memref.shm_offs +
+					   p->u.memref.size - 1;
+
+				rc = tee_shm_get_pa(shm, o, NULL);
+				if (rc)
+					return rc;
+			}
+			break;
+		default:
+			return -EINVAL;
+		}
+	}
+	return 0;
+}
+
+int optee_to_msg_param(struct optee_msg_param *msg_params, size_t num_params,
+			const struct tee_param *params)
+{
+	int rc;
+	size_t n;
+	phys_addr_t pa;
+
+	for (n = 0; n < num_params; n++) {
+		const struct tee_param *p = params + n;
+		struct optee_msg_param *mp = msg_params + n;
+
+		switch (p->attr) {
+		case TEE_IOCTL_PARAM_ATTR_TYPE_NONE:
+			mp->attr = TEE_IOCTL_PARAM_ATTR_TYPE_NONE;
+			memset(&mp->u, 0, sizeof(mp->u));
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT:
+			mp->attr = OPTEE_MSG_ATTR_TYPE_VALUE_INPUT + p->attr -
+				   TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
+			mp->u.value.a = p->u.value.a;
+			mp->u.value.b = p->u.value.b;
+			mp->u.value.c = p->u.value.c;
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT:
+			mp->attr = OPTEE_MSG_ATTR_TYPE_TMEM_INPUT +
+				   p->attr -
+				   TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT;
+			mp->u.tmem.shm_ref = (unsigned long)p->u.memref.shm;
+			mp->u.tmem.size = p->u.memref.size;
+			if (!p->u.memref.shm) {
+				mp->u.tmem.buf_ptr = 0;
+				break;
+			}
+			rc = tee_shm_get_pa(p->u.memref.shm,
+					    p->u.memref.shm_offs, &pa);
+			if (rc)
+				return rc;
+			mp->u.tmem.buf_ptr = pa;
+			mp->attr |= OPTEE_MSG_ATTR_CACHE_PREDEFINED <<
+					OPTEE_MSG_ATTR_CACHE_SHIFT;
+			break;
+		default:
+			return -EINVAL;
+		}
+	}
+	return 0;
+}
+
+static void optee_get_version(struct tee_device *teedev,
+			struct tee_ioctl_version_data *vers)
+{
+	struct tee_ioctl_version_data v = {
+		.impl_id = TEE_IMPL_ID_OPTEE,
+		.impl_caps = TEE_OPTEE_CAP_TZ,
+		.gen_caps = TEE_GEN_CAP_GP,
+	};
+	*vers = v;
+}
+
+static int optee_open(struct tee_context *ctx)
+{
+	struct optee_context_data *ctxdata;
+
+	ctxdata = kzalloc(sizeof(*ctxdata), GFP_KERNEL);
+	if (!ctxdata)
+		return -ENOMEM;
+
+	mutex_init(&ctxdata->mutex);
+	INIT_LIST_HEAD(&ctxdata->sess_list);
+
+	ctx->data = ctxdata;
+	return 0;
+}
+
+static void optee_release(struct tee_context *ctx)
+{
+	struct optee_context_data *ctxdata = ctx->data;
+	struct tee_shm *shm;
+	struct optee_msg_arg *arg = NULL;
+	phys_addr_t parg;
+
+	if (!ctxdata)
+		return;
+
+	shm = tee_shm_alloc(ctx->teedev, sizeof(struct optee_msg_arg),
+			    TEE_SHM_MAPPED);
+	if (!IS_ERR(shm)) {
+		arg = tee_shm_get_va(shm, 0);
+		/*
+		 * If va2pa fails for some reason, we can't call
+		 * optee_close_session(), only free the memory. Secure OS
+		 * will leak sessions and finally refuse more session, but
+		 * we will at least let normal world reclaim its memory.
+		 */
+		if (!IS_ERR(arg))
+			tee_shm_va2pa(shm, arg, &parg);
+	}
+
+	while (true) {
+		struct optee_session *sess;
+
+		sess = list_first_entry_or_null(&ctxdata->sess_list,
+						struct optee_session,
+						list_node);
+		if (!sess)
+			break;
+		list_del(&sess->list_node);
+		if (!IS_ERR_OR_NULL(arg)) {
+			memset(arg, 0, sizeof(*arg));
+			arg->cmd = OPTEE_MSG_CMD_CLOSE_SESSION;
+			arg->session = sess->session_id;
+			optee_do_call_with_arg(ctx, parg);
+		}
+		kfree(sess);
+	}
+	kfree(ctxdata);
+
+	if (!IS_ERR(shm))
+		tee_shm_free(shm);
+
+	ctx->data = NULL;
+}
+
+static struct tee_driver_ops optee_ops = {
+	.get_version = optee_get_version,
+	.open = optee_open,
+	.release = optee_release,
+	.open_session = optee_open_session,
+	.close_session = optee_close_session,
+	.invoke_func = optee_invoke_func,
+	.cancel_req = optee_cancel_req,
+};
+
+static struct tee_desc optee_desc = {
+	.name = DRIVER_NAME "-clnt",
+	.ops = &optee_ops,
+	.owner = THIS_MODULE,
+};
+
+static struct tee_driver_ops optee_supp_ops = {
+	.get_version = optee_get_version,
+	.open = optee_open,
+	.release = optee_release,
+	.supp_recv = optee_supp_recv,
+	.supp_send = optee_supp_send,
+};
+
+static struct tee_desc optee_supp_desc = {
+	.name = DRIVER_NAME "-supp",
+	.ops = &optee_supp_ops,
+	.owner = THIS_MODULE,
+	.flags = TEE_DESC_PRIVILEGED,
+};
+
+static bool optee_msg_api_uid_is_optee_api(optee_invoke_fn *invoke_fn)
+{
+	struct arm_smccc_res res;
+
+	invoke_fn(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, 0, &res);
+
+	if (res.a0 == OPTEE_MSG_UID_0 && res.a1 == OPTEE_MSG_UID_1 &&
+	    res.a2 == OPTEE_MSG_UID_2 && res.a3 == OPTEE_MSG_UID_3)
+		return true;
+	return false;
+}
+
+static bool optee_msg_api_revision_is_compatible(optee_invoke_fn *invoke_fn)
+{
+	struct arm_smccc_res res;
+
+	invoke_fn(OPTEE_SMC_CALLS_REVISION, 0, 0, 0, 0, 0, 0, 0, &res);
+
+	if (res.a0 == OPTEE_MSG_REVISION_MAJOR &&
+	    (int)res.a1 >= OPTEE_MSG_REVISION_MINOR)
+		return true;
+	return false;
+}
+
+static bool optee_msg_exchange_capabilities(optee_invoke_fn *invoke_fn,
+			u32 *sec_caps)
+{
+	struct arm_smccc_res res;
+	u32 a1 = 0;
+
+	/*
+	 * TODO This isn't enough to tell if it's UP system (from kernel
+	 * point of view) or not, is_smp() returns the the information
+	 * needed, but can't be called directly from here.
+	 */
+#ifndef CONFIG_SMP
+	a1 |= OPTEE_SMC_NSEC_CAP_UNIPROCESSOR;
+#endif
+
+	invoke_fn(OPTEE_SMC_EXCHANGE_CAPABILITIES, a1, 0, 0, 0, 0, 0, 0, &res);
+
+	if (res.a0 != OPTEE_SMC_RETURN_OK)
+		return false;
+
+	*sec_caps = res.a1;
+	return true;
+}
+
+static struct tee_shm_pool *optee_config_shm_ioremap(struct device *dev,
+			optee_invoke_fn *invoke_fn,
+			void __iomem **ioremaped_shm)
+{
+	struct arm_smccc_res res;
+	struct tee_shm_pool *pool;
+	unsigned long vaddr;
+	phys_addr_t paddr;
+	size_t size;
+	phys_addr_t begin;
+	phys_addr_t end;
+	void __iomem *va;
+	struct tee_shm_pool_mem_info priv_info;
+	struct tee_shm_pool_mem_info dmabuf_info;
+
+	invoke_fn(OPTEE_SMC_GET_SHM_CONFIG, 0, 0, 0, 0, 0, 0, 0, &res);
+	if (res.a0 != OPTEE_SMC_RETURN_OK) {
+		dev_info(dev, "shm service not available\n");
+		return ERR_PTR(-ENOENT);
+	}
+
+	if (res.a3 != OPTEE_SMC_SHM_CACHED) {
+		dev_err(dev, "only normal cached shared memory supported\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	begin = roundup(res.a1, PAGE_SIZE);
+	end = rounddown(res.a1 + res.a2, PAGE_SIZE);
+	paddr = begin;
+	size = end - begin;
+
+	if (size < 2 * OPTEE_SHM_NUM_PRIV_PAGES * PAGE_SIZE) {
+		dev_err(dev, "too small shared memory area\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	va = ioremap_cache(paddr, size);
+	if (!va) {
+		dev_err(dev, "shared memory ioremap failed\n");
+		return ERR_PTR(-EINVAL);
+	}
+	vaddr = (unsigned long)va;
+
+	priv_info.vaddr = vaddr;
+	priv_info.paddr = paddr;
+	priv_info.size = OPTEE_SHM_NUM_PRIV_PAGES * PAGE_SIZE;
+	dmabuf_info.vaddr = vaddr + OPTEE_SHM_NUM_PRIV_PAGES * PAGE_SIZE;
+	dmabuf_info.paddr = paddr + OPTEE_SHM_NUM_PRIV_PAGES * PAGE_SIZE;
+	dmabuf_info.size = size - OPTEE_SHM_NUM_PRIV_PAGES * PAGE_SIZE;
+
+	pool = tee_shm_pool_alloc_res_mem(dev, &priv_info, &dmabuf_info);
+	if (IS_ERR(pool))
+		iounmap(va);
+	else
+		*ioremaped_shm = va;
+	return pool;
+}
+
+static int get_invoke_func(struct device *dev, optee_invoke_fn **invoke_fn)
+{
+	struct device_node *np = dev->of_node;
+	const char *method;
+
+	dev_info(dev, "probing for conduit method from DT.\n");
+
+	if (of_property_read_string(np, "method", &method)) {
+		dev_warn(dev, "missing \"method\" property\n");
+		return -ENXIO;
+	}
+
+	if (!strcmp("hvc", method)) {
+		*invoke_fn = arm_smccc_hvc;
+	} else if (!strcmp("smc", method)) {
+		*invoke_fn = arm_smccc_smc;
+	} else {
+		dev_warn(dev, "invalid \"method\" property: %s\n", method);
+		return -EINVAL;
+	}
+	return 0;
+}
+
+static int optee_probe(struct platform_device *pdev)
+{
+	optee_invoke_fn *invoke_fn;
+	struct tee_shm_pool *pool;
+	struct optee *optee = NULL;
+	void __iomem *ioremaped_shm = NULL;
+	struct tee_device *teedev;
+	u32 sec_caps;
+	int rc;
+
+	rc = get_invoke_func(&pdev->dev, &invoke_fn);
+	if (rc)
+		return rc;
+
+	if (!optee_msg_api_uid_is_optee_api(invoke_fn) ||
+	    !optee_msg_api_revision_is_compatible(invoke_fn) ||
+	    !optee_msg_exchange_capabilities(invoke_fn, &sec_caps))
+		return -EINVAL;
+
+	/*
+	 * We have no other option for shared memory, if secure world
+	 * doesn't have any reserved memory we can use we can't continue.
+	 */
+	if (!(sec_caps & OPTEE_SMC_SEC_CAP_HAVE_RESERVERED_SHM))
+		return -EINVAL;
+
+	pool = optee_config_shm_ioremap(&pdev->dev, invoke_fn, &ioremaped_shm);
+	if (IS_ERR(pool))
+		return PTR_ERR(pool);
+
+	optee = devm_kzalloc(&pdev->dev, sizeof(*optee), GFP_KERNEL);
+	if (!optee) {
+		rc = -ENOMEM;
+		goto err;
+	}
+
+	optee->dev = &pdev->dev;
+	optee->invoke_fn = invoke_fn;
+
+	teedev = tee_device_alloc(&optee_desc, &pdev->dev, pool, optee);
+	if (IS_ERR(teedev)) {
+		rc = PTR_ERR(teedev);
+		goto err;
+	}
+	optee->teedev = teedev;
+
+	teedev = tee_device_alloc(&optee_supp_desc, &pdev->dev, pool, optee);
+	if (IS_ERR(teedev)) {
+		rc = PTR_ERR(teedev);
+		goto err;
+	}
+	optee->supp_teedev = teedev;
+
+	rc = tee_device_register(optee->teedev);
+	if (rc)
+		goto err;
+
+	rc = tee_device_register(optee->supp_teedev);
+	if (rc)
+		goto err;
+
+	mutex_init(&optee->call_queue.mutex);
+	INIT_LIST_HEAD(&optee->call_queue.waiters);
+	optee_wait_queue_init(&optee->wait_queue);
+	optee_supp_init(&optee->supp);
+	optee->ioremaped_shm = ioremaped_shm;
+	optee->pool = pool;
+
+	platform_set_drvdata(pdev, optee);
+
+	optee_enable_shm_cache(optee);
+
+	dev_info(&pdev->dev, "initialized driver\n");
+	return 0;
+err:
+	tee_device_unregister(optee->teedev);
+	tee_device_unregister(optee->supp_teedev);
+	if (pool)
+		tee_shm_pool_free(pool);
+	if (ioremaped_shm)
+		iounmap(optee->ioremaped_shm);
+	return rc;
+}
+
+static int optee_remove(struct platform_device *pdev)
+{
+	struct optee *optee = platform_get_drvdata(pdev);
+
+	optee_disable_shm_cache(optee);
+
+	tee_device_unregister(optee->teedev);
+	tee_device_unregister(optee->supp_teedev);
+	tee_shm_pool_free(optee->pool);
+	if (optee->ioremaped_shm)
+		iounmap(optee->ioremaped_shm);
+	optee_wait_queue_exit(&optee->wait_queue);
+	optee_supp_uninit(&optee->supp);
+	mutex_destroy(&optee->call_queue.mutex);
+	return 0;
+}
+
+static const struct of_device_id optee_match[] = {
+	{ .compatible = "linaro,optee-tz" },
+	{},
+};
+
+static struct platform_driver optee_driver = {
+	.driver = {
+		.name = DRIVER_NAME,
+		.of_match_table = optee_match,
+	},
+	.probe = optee_probe,
+	.remove = optee_remove,
+};
+
+static int __init optee_driver_init(void)
+{
+	struct device_node *node;
+
+	/*
+	 * Preferred path is /firmware/optee, but it's the matching that
+	 * matters.
+	 */
+	for_each_matching_node(node, optee_match)
+		of_platform_device_create(node, NULL, NULL);
+
+	return platform_driver_register(&optee_driver);
+}
+module_init(optee_driver_init);
+
+static void __exit optee_driver_exit(void)
+{
+	platform_driver_unregister(&optee_driver);
+}
+module_exit(optee_driver_exit);
+
+MODULE_AUTHOR("Linaro");
+MODULE_DESCRIPTION("OP-TEE driver");
+MODULE_SUPPORTED_DEVICE("");
+MODULE_VERSION("1.0");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h
new file mode 100644
index 0000000..58db178
--- /dev/null
+++ b/drivers/tee/optee/optee_msg.h
@@ -0,0 +1,423 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice,
+ * this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
+ * and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+#ifndef _OPTEE_MSG_H
+#define _OPTEE_MSG_H
+
+#include <linux/types.h>
+
+/*
+ * This file defines the OP-TEE message protocol used to communicate
+ * with an instance of OP-TEE running in secure world.
+ *
+ * This file is divided into three sections.
+ * 1. Formatting of messages.
+ * 2. Requests from normal world
+ * 3. Requests from secure world, Remote Procedure Call (RPC), handled by
+ *    tee-supplicant.
+ */
+
+/*****************************************************************************
+ * Part 1 - formatting of messages
+ *****************************************************************************/
+
+#define OPTEE_MSG_ATTR_TYPE_NONE		0x0
+#define OPTEE_MSG_ATTR_TYPE_VALUE_INPUT		0x1
+#define OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT	0x2
+#define OPTEE_MSG_ATTR_TYPE_VALUE_INOUT		0x3
+#define OPTEE_MSG_ATTR_TYPE_RMEM_INPUT		0x5
+#define OPTEE_MSG_ATTR_TYPE_RMEM_OUTPUT		0x6
+#define OPTEE_MSG_ATTR_TYPE_RMEM_INOUT		0x7
+#define OPTEE_MSG_ATTR_TYPE_TMEM_INPUT		0x9
+#define OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT		0xa
+#define OPTEE_MSG_ATTR_TYPE_TMEM_INOUT		0xb
+
+#define OPTEE_MSG_ATTR_TYPE_MASK		0xff
+
+/*
+ * Meta parameter to be absorbed by the Secure OS and not passed
+ * to the Trusted Application.
+ *
+ * Currently only used with OPTEE_MSG_CMD_OPEN_SESSION.
+ */
+#define OPTEE_MSG_ATTR_META			(1 << 8)
+
+/*
+ * The temporary shared memory object is not physically contigous and this
+ * temp memref is followed by another fragment until the last temp memref
+ * that doesn't have this bit set.
+ */
+#define OPTEE_MSG_ATTR_FRAGMENT			(1 << 9)
+
+/*
+ * Memory attributes for caching passed with temp memrefs. The actual value
+ * used is defined outside the message protocol with the exception of
+ * OPTEE_MSG_ATTR_CACHE_PREDEFINED which means the attributes already
+ * defined for the memory range should be used. If optee_smc.h is used as
+ * bearer of this protocol OPTEE_SMC_SHM_* is used for values.
+ */
+#define OPTEE_MSG_ATTR_CACHE_SHIFT		16
+#define OPTEE_MSG_ATTR_CACHE_MASK		0x7
+#define OPTEE_MSG_ATTR_CACHE_PREDEFINED		0
+
+/*
+ * Same values as TEE_LOGIN_* from TEE Internal API
+ */
+#define OPTEE_MSG_LOGIN_PUBLIC			0x00000000
+#define OPTEE_MSG_LOGIN_USER			0x00000001
+#define OPTEE_MSG_LOGIN_GROUP			0x00000002
+#define OPTEE_MSG_LOGIN_APPLICATION		0x00000004
+#define OPTEE_MSG_LOGIN_APPLICATION_USER	0x00000005
+#define OPTEE_MSG_LOGIN_APPLICATION_GROUP	0x00000006
+
+/**
+ * struct optee_msg_param_tmem - temporary memory reference
+ * @buf_ptr:	Address of the buffer
+ * @size:	Size of the buffer
+ * @shm_ref:	Temporary shared memory reference, pointer to a struct tee_shm
+ *
+ * Secure and normal world communicates pointers as physical address
+ * instead of the virtual address. This is because secure and normal world
+ * have completely independent memory mapping. Normal world can even have a
+ * hypervisor which need to translate the guest physical address (AKA IPA
+ * in ARM documentation) to a real physical address before passing the
+ * structure to secure world.
+ */
+struct optee_msg_param_tmem {
+	u64 buf_ptr;
+	u64 size;
+	u64 shm_ref;
+};
+
+/**
+ * struct optee_msg_param_rmem - registered memory reference
+ * @offs:	Offset into shared memory reference
+ * @size:	Size of the buffer
+ * @shm_ref:	Shared memory reference, pointer to a struct tee_shm
+ */
+struct optee_msg_param_rmem {
+	u64 offs;
+	u64 size;
+	u64 shm_ref;
+};
+
+/**
+ * struct optee_msg_param_value - values
+ * @a: first value
+ * @b: second value
+ * @c: third value
+ */
+struct optee_msg_param_value {
+	u64 a;
+	u64 b;
+	u64 c;
+};
+
+/**
+ * struct optee_msg_param - parameter
+ * @attr: attributes
+ * @memref: a memory reference
+ * @value: a value
+ *
+ * @attr & OPTEE_MSG_ATTR_TYPE_MASK indicates if tmem, rmem or value is used in
+ * the union. OPTEE_MSG_ATTR_TYPE_VALUE_* indicates value,
+ * OPTEE_MSG_ATTR_TYPE_TMEM_* indicates tmem and
+ * OPTEE_MSG_ATTR_TYPE_RMEM_* indicates rmem.
+ * OPTEE_MSG_ATTR_TYPE_NONE indicates that none of the members are used.
+ */
+struct optee_msg_param {
+	u64 attr;
+	union {
+		struct optee_msg_param_tmem tmem;
+		struct optee_msg_param_rmem rmem;
+		struct optee_msg_param_value value;
+	} u;
+};
+
+/**
+ * struct optee_msg_arg - call argument
+ * @cmd: Command, one of OPTEE_MSG_CMD_* or OPTEE_MSG_RPC_CMD_*
+ * @func: Trusted Application function, specific to the Trusted Application,
+ *	     used if cmd == OPTEE_MSG_CMD_INVOKE_COMMAND
+ * @session: In parameter for all OPTEE_MSG_CMD_* except
+ *	     OPTEE_MSG_CMD_OPEN_SESSION where it's an output parameter instead
+ * @cancel_id: Cancellation id, a unique value to identify this request
+ * @ret: return value
+ * @ret_origin: origin of the return value
+ * @num_params: number of parameters supplied to the OS Command
+ * @params: the parameters supplied to the OS Command
+ *
+ * All normal calls to Trusted OS uses this struct. If cmd requires further
+ * information than what these field holds it can be passed as a parameter
+ * tagged as meta (setting the OPTEE_MSG_ATTR_META bit in corresponding
+ * attrs field). All parameters tagged as meta has to come first.
+ *
+ * Temp memref parameters can be fragmented if supported by the Trusted OS
+ * (when optee_smc.h is bearer of this protocol this is indicated with
+ * OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM). If a logical memref parameter is
+ * fragmented then has all but the last fragment the
+ * OPTEE_MSG_ATTR_FRAGMENT bit set in attrs. Even if a memref is fragmented
+ * it will still be presented as a single logical memref to the Trusted
+ * Application.
+ */
+struct optee_msg_arg {
+	u32 cmd;
+	u32 func;
+	u32 session;
+	u32 cancel_id;
+	u32 pad;
+	u32 ret;
+	u32 ret_origin;
+	u32 num_params;
+
+	/*
+	 * this struct is 8 byte aligned since the 'struct optee_msg_param'
+	 * which follows requires 8 byte alignment.
+	 *
+	 * Commented out element used to visualize the layout dynamic part
+	 * of the struct. This field is not available at all if
+	 * num_params == 0.
+	 *
+	 * params is accessed through the macro OPTEE_MSG_GET_PARAMS
+	 *
+	 * struct optee_msg_param params[num_params];
+	 */
+} __aligned(8);
+
+/**
+ * OPTEE_MSG_GET_PARAMS - return pointer to struct optee_msg_param *
+ *
+ * @x: Pointer to a struct optee_msg_arg
+ *
+ * Returns a pointer to the params[] inside a struct optee_msg_arg.
+ */
+#define OPTEE_MSG_GET_PARAMS(x) \
+	(struct optee_msg_param *)(((struct optee_msg_arg *)(x)) + 1)
+
+/**
+ * OPTEE_MSG_GET_ARG_SIZE - return size of struct optee_msg_arg
+ *
+ * @num_params: Number of parameters embedded in the struct optee_msg_arg
+ *
+ * Returns the size of the struct optee_msg_arg together with the number
+ * of embedded parameters.
+ */
+#define OPTEE_MSG_GET_ARG_SIZE(num_params) \
+	(sizeof(struct optee_msg_arg) + \
+	 sizeof(struct optee_msg_param) * (num_params))
+
+/*****************************************************************************
+ * Part 2 - requests from normal world
+ *****************************************************************************/
+
+/*
+ * Return the following UID if using API specified in this file without
+ * further extentions:
+ * 384fb3e0-e7f8-11e3-af63-0002a5d5c51b.
+ * Represented in 4 32-bit words in OPTEE_MSG_UID_0, OPTEE_MSG_UID_1,
+ * OPTEE_MSG_UID_2, OPTEE_MSG_UID_3.
+ */
+#define OPTEE_MSG_UID_0			0x384fb3e0
+#define OPTEE_MSG_UID_1			0xe7f811e3
+#define OPTEE_MSG_UID_2			0xaf630002
+#define OPTEE_MSG_UID_3			0xa5d5c51b
+#define OPTEE_MSG_FUNCID_CALLS_UID	0xFF01
+
+/*
+ * Returns 2.0 if using API specified in this file without further
+ * extentions. Represented in 2 32-bit words in OPTEE_MSG_REVISION_MAJOR
+ * and OPTEE_MSG_REVISION_MINOR
+ */
+#define OPTEE_MSG_REVISION_MAJOR	2
+#define OPTEE_MSG_REVISION_MINOR	0
+#define OPTEE_MSG_FUNCID_CALLS_REVISION	0xFF03
+
+/*
+ * Get UUID of Trusted OS.
+ *
+ * Used by non-secure world to figure out which Trusted OS is installed.
+ * Note that returned UUID is the UUID of the Trusted OS, not of the API.
+ *
+ * Returns UUID in 4 32-bit words in the same way as
+ * OPTEE_MSG_FUNCID_CALLS_UID described above.
+ */
+#define OPTEE_MSG_OS_OPTEE_UUID_0	0x486178e0
+#define OPTEE_MSG_OS_OPTEE_UUID_1	0xe7f811e3
+#define OPTEE_MSG_OS_OPTEE_UUID_2	0xbc5e0002
+#define OPTEE_MSG_OS_OPTEE_UUID_3	0xa5d5c51b
+#define OPTEE_MSG_FUNCID_GET_OS_UUID	0x0000
+
+/*
+ * Get revision of Trusted OS.
+ *
+ * Used by non-secure world to figure out which version of the Trusted OS
+ * is installed. Note that the returned revision is the revision of the
+ * Trusted OS, not of the API.
+ *
+ * Returns revision in 2 32-bit words in the same way as
+ * OPTEE_MSG_CALLS_REVISION described above.
+ */
+#define OPTEE_MSG_OS_OPTEE_REVISION_MAJOR	1
+#define OPTEE_MSG_OS_OPTEE_REVISION_MINOR	0
+#define OPTEE_MSG_FUNCID_GET_OS_REVISION	0x0001
+
+/*
+ * Do a secure call with struct optee_msg_arg as argument
+ * The OPTEE_MSG_CMD_* below defines what goes in struct optee_msg_arg::cmd
+ *
+ * OPTEE_MSG_CMD_OPEN_SESSION opens a session to a Trusted Application.
+ * The first two parameters are tagged as meta, holding two value
+ * parameters to pass the following information:
+ * param[0].u.value.a-b uuid of Trusted Application
+ * param[1].u.value.a-b uuid of Client
+ * param[1].u.value.c Login class of client OPTEE_MSG_LOGIN_*
+ *
+ * OPTEE_MSG_CMD_INVOKE_COMMAND invokes a command a previously opened
+ * session to a Trusted Application.  struct optee_msg_arg::func is Trusted
+ * Application function, specific to the Trusted Application.
+ *
+ * OPTEE_MSG_CMD_CLOSE_SESSION closes a previously opened session to
+ * Trusted Application.
+ *
+ * OPTEE_MSG_CMD_CANCEL cancels a currently invoked command.
+ *
+ * OPTEE_MSG_CMD_REGISTER_SHM registers a shared memory reference. The
+ * information is passed as:
+ * [in] param[0].attr			OPTEE_MSG_ATTR_TYPE_TMEM_INPUT
+ *					[| OPTEE_MSG_ATTR_FRAGMENT]
+ * [in] param[0].u.tmem.buf_ptr		physical address (of first fragment)
+ * [in] param[0].u.tmem.size		size (of first fragment)
+ * [in] param[0].u.tmem.shm_ref		holds shared memory reference
+ * ...
+ * The shared memory can optionally be fragmented, temp memrefs can follow
+ * each other with all but the last with the OPTEE_MSG_ATTR_FRAGMENT bit set.
+ *
+ * OPTEE_MSG_CMD_UNREGISTER_SHM unregisteres a previously registered shared
+ * memory reference. The information is passed as:
+ * [in] param[0].attr			OPTEE_MSG_ATTR_TYPE_RMEM_INPUT
+ * [in] param[0].u.rmem.shm_ref		holds shared memory reference
+ * [in] param[0].u.rmem.offs		0
+ * [in] param[0].u.rmem.size		0
+ */
+#define OPTEE_MSG_CMD_OPEN_SESSION	0
+#define OPTEE_MSG_CMD_INVOKE_COMMAND	1
+#define OPTEE_MSG_CMD_CLOSE_SESSION	2
+#define OPTEE_MSG_CMD_CANCEL		3
+#define OPTEE_MSG_CMD_REGISTER_SHM	4
+#define OPTEE_MSG_CMD_UNREGISTER_SHM	5
+#define OPTEE_MSG_FUNCID_CALL_WITH_ARG	0x0004
+
+/*****************************************************************************
+ * Part 3 - Requests from secure world, RPC
+ *****************************************************************************/
+
+/*
+ * All RPC is done with a struct optee_msg_arg as bearer of information,
+ * struct optee_msg_arg::arg holds values defined by OPTEE_MSG_RPC_CMD_* below
+ *
+ * RPC communication with tee-supplicant is reversed compared to normal
+ * client communication desribed above. The supplicant receives requests
+ * and sends responses.
+ */
+
+/*
+ * Load a TA into memory, defined in tee-supplicant
+ */
+#define OPTEE_MSG_RPC_CMD_LOAD_TA	0
+
+/*
+ * Reserved
+ */
+#define OPTEE_MSG_RPC_CMD_RPMB		1
+
+/*
+ * File system access, defined in tee-supplicant
+ */
+#define OPTEE_MSG_RPC_CMD_FS		2
+
+/*
+ * Get time
+ *
+ * Returns number of seconds and nano seconds since the Epoch,
+ * 1970-01-01 00:00:00 +0000 (UTC).
+ *
+ * [out] param[0].u.value.a	Number of seconds
+ * [out] param[0].u.value.b	Number of nano seconds.
+ */
+#define OPTEE_MSG_RPC_CMD_GET_TIME	3
+
+/*
+ * Wait queue primitive, helper for secure world to implement a wait queue
+ *
+ * Waiting on a key
+ * [in] param[0].u.value.a OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP
+ * [in] param[0].u.value.b wait key
+ *
+ * Waking up a key
+ * [in] param[0].u.value.a OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP
+ * [in] param[0].u.value.b wakeup key
+ */
+#define OPTEE_MSG_RPC_CMD_WAIT_QUEUE	4
+#define OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP	0
+#define OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP	1
+
+/*
+ * Suspend execution
+ *
+ * [in] param[0].value	.a number of milliseconds to suspend
+ */
+#define OPTEE_MSG_RPC_CMD_SUSPEND	5
+
+/*
+ * Allocate a piece of shared memory
+ *
+ * Shared memory can optionally be fragmented, to support that additional
+ * spare param entries are allocated to make room for eventual fragments.
+ * The spare param entries has .attr = OPTEE_MSG_ATTR_TYPE_NONE when
+ * unused. All returned temp memrefs except the last should have the
+ * OPTEE_MSG_ATTR_FRAGMENT bit set in the attr field.
+ *
+ * [in]  param[0].u.value.a		type of memory one of
+ *					OPTEE_MSG_RPC_SHM_TYPE_* below
+ * [in]  param[0].u.value.b		requested size
+ * [in]  param[0].u.value.c		required alignment
+ *
+ * [out] param[0].u.tmem.buf_ptr	physical address (of first fragment)
+ * [out] param[0].u.tmem.size		size (of first fragment)
+ * [out] param[0].u.tmem.shm_ref	shared memory reference
+ * ...
+ * [out] param[n].u.tmem.buf_ptr	physical address
+ * [out] param[n].u.tmem.size		size
+ * [out] param[n].u.tmem.shm_ref	shared memory reference (same value
+ *					as in param[n-1].u.tmem.shm_ref)
+ */
+#define OPTEE_MSG_RPC_CMD_SHM_ALLOC	6
+/* Memory that can be shared with a non-secure user space application */
+#define OPTEE_MSG_RPC_SHM_TYPE_APPL	0
+/* Memory only shared with non-secure kernel */
+#define OPTEE_MSG_RPC_SHM_TYPE_KERNEL	1
+
+#endif /* _OPTEE_MSG_H */
diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h
new file mode 100644
index 0000000..7f13cb5
--- /dev/null
+++ b/drivers/tee/optee/optee_private.h
@@ -0,0 +1,146 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef OPTEE_PRIVATE_H
+#define OPTEE_PRIVATE_H
+
+#include <linux/types.h>
+#include <linux/semaphore.h>
+#include <linux/tee_drv.h>
+#include "optee_msg.h"
+#include <linux/arm-smccc.h>
+
+#define OPTEE_MAX_ARG_SIZE	1024
+
+/* Some Global Platform error codes used in this driver */
+#define TEEC_SUCCESS			0x00000000
+#define TEEC_ERROR_BAD_PARAMETERS	0xFFFF0006
+#define TEEC_ERROR_COMMUNICATION	0xFFFF000E
+#define TEEC_ERROR_OUT_OF_MEMORY	0xFFFF000C
+
+#define TEEC_ORIGIN_COMMS		0x00000002
+
+typedef void (optee_invoke_fn)(unsigned long, unsigned long, unsigned long,
+				unsigned long, unsigned long, unsigned long,
+				unsigned long, unsigned long,
+				struct arm_smccc_res *);
+
+struct optee_call_queue {
+	struct mutex mutex;
+	struct list_head waiters;
+};
+
+struct optee_wait_queue {
+	struct mutex mu;
+	struct list_head db;
+};
+
+struct optee_supp {
+	u32 func;
+	u32 ret;
+	size_t num_params;
+	struct tee_param *param;
+
+	bool req_posted;
+	bool supp_next_send;
+	struct mutex thrd_mutex;
+	struct mutex supp_mutex;
+	struct completion data_to_supp;
+	struct completion data_from_supp;
+};
+
+struct optee {
+	struct tee_device *supp_teedev;
+	struct tee_device *teedev;
+	struct device *dev;
+	optee_invoke_fn *invoke_fn;
+	struct optee_call_queue call_queue;
+	struct optee_wait_queue wait_queue;
+	struct optee_supp supp;
+	struct tee_shm_pool *pool;
+	void __iomem *ioremaped_shm;
+};
+
+struct optee_session {
+	struct list_head list_node;
+	u32 session_id;
+};
+
+struct optee_context_data {
+	struct mutex mutex;
+	struct list_head sess_list;
+};
+
+struct optee_rpc_param {
+	u32	a0;
+	u32	a1;
+	u32	a2;
+	u32	a3;
+	u32	a4;
+	u32	a5;
+	u32	a6;
+	u32	a7;
+};
+
+void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param);
+
+void optee_wait_queue_init(struct optee_wait_queue *wq);
+void optee_wait_queue_exit(struct optee_wait_queue *wq);
+
+u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params,
+			struct tee_param *param);
+
+int optee_supp_read(struct tee_context *ctx, void __user *buf, size_t len);
+int optee_supp_write(struct tee_context *ctx, void __user *buf, size_t len);
+void optee_supp_init(struct optee_supp *supp);
+void optee_supp_uninit(struct optee_supp *supp);
+
+int optee_supp_recv(struct tee_context *ctx, u32 *func, u32 *num_params,
+			struct tee_param *param);
+int optee_supp_send(struct tee_context *ctx, u32 ret, u32 num_params,
+			struct tee_param *param);
+
+u32 optee_do_call_with_arg(struct tee_context *ctx, phys_addr_t parg);
+int optee_open_session(struct tee_context *ctx,
+			struct tee_ioctl_open_session_arg *arg,
+			struct tee_param *param);
+int optee_close_session(struct tee_context *ctx, u32 session);
+int optee_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg,
+			struct tee_param *param);
+int optee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session);
+
+void optee_enable_shm_cache(struct optee *optee);
+void optee_disable_shm_cache(struct optee *optee);
+
+int optee_from_msg_param(struct tee_param *params, size_t num_params,
+			const struct optee_msg_param *msg_params);
+int optee_to_msg_param(struct optee_msg_param *msg_params, size_t num_params,
+			const struct tee_param *params);
+
+/*
+ * Small helpers
+ */
+
+static inline void *reg_pair_to_ptr(u32 reg0, u32 reg1)
+{
+	return (void *)(unsigned long)(((u64)reg0 << 32) | reg1);
+}
+
+static inline void reg_pair_from_64(u32 *reg0, u32 *reg1, u64 val)
+{
+	*reg0 = val >> 32;
+	*reg1 = val;
+}
+
+#endif /*OPTEE_PRIVATE_H*/
diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h
new file mode 100644
index 0000000..4aa20b9
--- /dev/null
+++ b/drivers/tee/optee/optee_smc.h
@@ -0,0 +1,418 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice,
+ * this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
+ * and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+#ifndef OPTEE_SMC_H
+#define OPTEE_SMC_H
+
+#include <linux/arm-smccc.h>
+
+#define OPTEE_SMC_STD_CALL_VAL(func_num) \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_STD_CALL, ARM_SMCCC_SMC_32, \
+			   ARM_SMCCC_OWNER_TRUSTED_OS, (func_num))
+#define OPTEE_SMC_FAST_CALL_VAL(func_num) \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \
+			   ARM_SMCCC_OWNER_TRUSTED_OS, (func_num))
+
+/*
+ * Function specified by SMC Calling convention.
+ */
+#define OPTEE_SMC_FUNCID_CALLS_COUNT	0xFF00
+#define OPTEE_SMC_CALLS_COUNT \
+	ARM_SMCCC_CALL_VAL(OPTEE_SMC_FAST_CALL, SMCCC_SMC_32, \
+			   SMCCC_OWNER_TRUSTED_OS_END, \
+			   OPTEE_SMC_FUNCID_CALLS_COUNT)
+
+/*
+ * Normal cached memory (write-back), shareable for SMP systems and not
+ * shareable for UP systems.
+ */
+#define OPTEE_SMC_SHM_CACHED		1
+
+/*
+ * a0..a7 is used as register names in the descriptions below, on arm32
+ * that translates to r0..r7 and on arm64 to w0..w7. In both cases it's
+ * 32-bit registers.
+ */
+
+/*
+ * Function specified by SMC Calling convention
+ *
+ * Return one of the following UIDs if using API specified in this file
+ * without further extentions:
+ * 65cb6b93-af0c-4617-8ed6-644a8d1140f8
+ * see also OPTEE_SMC_UID_* in optee_msg.h
+ */
+#define OPTEE_SMC_FUNCID_CALLS_UID OPTEE_MSG_FUNCID_CALLS_UID
+#define OPTEE_SMC_CALLS_UID \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \
+			   ARM_SMCCC_OWNER_TRUSTED_OS_END, \
+			   OPTEE_SMC_FUNCID_CALLS_UID)
+
+/*
+ * Function specified by SMC Calling convention
+ *
+ * Returns 2.0 if using API specified in this file without further extentions.
+ * see also OPTEE_MSG_REVISION_* in optee_msg.h
+ */
+#define OPTEE_SMC_FUNCID_CALLS_REVISION OPTEE_MSG_FUNCID_CALLS_REVISION
+#define OPTEE_SMC_CALLS_REVISION \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \
+			   ARM_SMCCC_OWNER_TRUSTED_OS_END, \
+			   OPTEE_SMC_FUNCID_CALLS_REVISION)
+
+/*
+ * Get UUID of Trusted OS.
+ *
+ * Used by non-secure world to figure out which Trusted OS is installed.
+ * Note that returned UUID is the UUID of the Trusted OS, not of the API.
+ *
+ * Returns UUID in a0-4 in the same way as OPTEE_SMC_CALLS_UID
+ * described above.
+ */
+#define OPTEE_SMC_FUNCID_GET_OS_UUID OPTEE_MSG_FUNCID_GET_OS_UUID
+#define OPTEE_SMC_CALL_GET_OS_UUID \
+	OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_GET_OS_UUID)
+
+/*
+ * Get revision of Trusted OS.
+ *
+ * Used by non-secure world to figure out which version of the Trusted OS
+ * is installed. Note that the returned revision is the revision of the
+ * Trusted OS, not of the API.
+ *
+ * Returns revision in a0-1 in the same way as OPTEE_SMC_CALLS_REVISION
+ * described above.
+ */
+#define OPTEE_SMC_FUNCID_GET_OS_REVISION OPTEE_MSG_FUNCID_GET_OS_REVISION
+#define OPTEE_SMC_CALL_GET_OS_REVISION \
+	OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_GET_OS_REVISION)
+
+/*
+ * Call with struct optee_msg_arg as argument
+ *
+ * Call register usage:
+ * a0	SMC Function ID, OPTEE_SMC*CALL_WITH_ARG
+ * a1	Upper 32bit of a 64bit physical pointer to a struct optee_msg_arg
+ * a2	Lower 32bit of a 64bit physical pointer to a struct optee_msg_arg
+ * a3	Cache settings, not used if physical pointer is in a predefined shared
+ *	memory area else per OPTEE_SMC_SHM_*
+ * a4-6	Not used
+ * a7	Hypervisor Client ID register
+ *
+ * Normal return register usage:
+ * a0	Return value, OPTEE_SMC_RETURN_*
+ * a1-3	Not used
+ * a4-7	Preserved
+ *
+ * OPTEE_SMC_RETURN_ETHREAD_LIMIT return register usage:
+ * a0	Return value, OPTEE_SMC_RETURN_ETHREAD_LIMIT
+ * a1-3	Preserved
+ * a4-7	Preserved
+ *
+ * RPC return register usage:
+ * a0	Return value, OPTEE_SMC_RETURN_IS_RPC(val)
+ * a1-2	RPC parameters
+ * a3-7	Resume information, must be preserved
+ *
+ * Possible return values:
+ * OPTEE_SMC_RETURN_UNKNOWN_FUNCTION	Trusted OS does not recognize this
+ *					function.
+ * OPTEE_SMC_RETURN_OK			Call completed, result updated in
+ *					the previously supplied struct
+ *					optee_msg_arg.
+ * OPTEE_SMC_RETURN_ETHREAD_LIMIT	Number of Trusted OS threads exceeded,
+ *					try again later.
+ * OPTEE_SMC_RETURN_EBADADDR		Bad physcial pointer to struct
+ *					optee_msg_arg.
+ * OPTEE_SMC_RETURN_EBADCMD		Bad/unknown cmd in struct optee_msg_arg
+ * OPTEE_SMC_RETURN_IS_RPC()		Call suspended by RPC call to normal
+ *					world.
+ */
+#define OPTEE_SMC_FUNCID_CALL_WITH_ARG OPTEE_MSG_FUNCID_CALL_WITH_ARG
+#define OPTEE_SMC_CALL_WITH_ARG \
+	OPTEE_SMC_STD_CALL_VAL(OPTEE_SMC_FUNCID_CALL_WITH_ARG)
+
+/*
+ * Get Shared Memory Config
+ *
+ * Returns the Secure/Non-secure shared memory config.
+ *
+ * Call register usage:
+ * a0	SMC Function ID, OPTEE_SMC_GET_SHM_CONFIG
+ * a1-6	Not used
+ * a7	Hypervisor Client ID register
+ *
+ * Have config return register usage:
+ * a0	OPTEE_SMC_RETURN_OK
+ * a1	Physical address of start of SHM
+ * a2	Size of of SHM
+ * a3	Cache settings of memory, as defined by the
+ *	OPTEE_SMC_SHM_* values above
+ * a4-7	Preserved
+ *
+ * Not available register usage:
+ * a0	OPTEE_SMC_RETURN_ENOTAVAIL
+ * a1-3 Not used
+ * a4-7	Preserved
+ */
+#define OPTEE_SMC_FUNCID_GET_SHM_CONFIG	7
+#define OPTEE_SMC_GET_SHM_CONFIG \
+	OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_GET_SHM_CONFIG)
+
+/*
+ * Exchanges capabilities between normal world and secure world
+ *
+ * Call register usage:
+ * a0	SMC Function ID, OPTEE_SMC_EXCHANGE_CAPABILITIES
+ * a1	bitfield of normal world capabilities OPTEE_SMC_NSEC_CAP_*
+ * a2-6	Not used
+ * a7	Hypervisor Client ID register
+ *
+ * Normal return register usage:
+ * a0	OPTEE_SMC_RETURN_OK
+ * a1	bitfield of secure world capabilities OPTEE_SMC_SEC_CAP_*
+ * a2-7	Preserved
+ *
+ * Error return register usage:
+ * a0	OPTEE_SMC_RETURN_ENOTAVAIL, can't use the capabilities from normal world
+ * a1	bitfield of secure world capabilities OPTEE_SMC_SEC_CAP_*
+ * a2-7 Preserved
+ */
+/* Normal world works as a uniprocessor system */
+#define OPTEE_SMC_NSEC_CAP_UNIPROCESSOR		(1 << 0)
+/* Secure world has reserved shared memory for normal world to use */
+#define OPTEE_SMC_SEC_CAP_HAVE_RESERVERED_SHM	(1 << 0)
+/* Secure world can communicate via previously unregistered shared memory */
+#define OPTEE_SMC_SEC_CAP_UNREGISTERED_SHM	(1 << 1)
+#define OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES	9
+#define OPTEE_SMC_EXCHANGE_CAPABILITIES \
+	OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES)
+
+/*
+ * Disable and empties cache of shared memory objects
+ *
+ * Secure world can cache frequently used shared memory objects, for
+ * example objects used as RPC arguments. When secure world is idle this
+ * function returns one shared memory reference to free. To disable the
+ * cache and free all cached objects this function has to be called until
+ * it returns OPTEE_SMC_RETURN_ENOTAVAIL.
+ *
+ * Call register usage:
+ * a0	SMC Function ID, OPTEE_SMC_DISABLE_SHM_CACHE
+ * a1-6	Not used
+ * a7	Hypervisor Client ID register
+ *
+ * Normal return register usage:
+ * a0	OPTEE_SMC_RETURN_OK
+ * a1	Upper 32bit of a 64bit Shared memory cookie
+ * a2	Lower 32bit of a 64bit Shared memory cookie
+ * a3-7	Preserved
+ *
+ * Cache empty return register usage:
+ * a0	OPTEE_SMC_RETURN_ENOTAVAIL
+ * a1-7	Preserved
+ *
+ * Not idle return register usage:
+ * a0	OPTEE_SMC_RETURN_EBUSY
+ * a1-7	Preserved
+ */
+#define OPTEE_SMC_FUNCID_DISABLE_SHM_CACHE	10
+#define OPTEE_SMC_DISABLE_SHM_CACHE \
+	OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_DISABLE_SHM_CACHE)
+
+
+/*
+ * Enable cache of shared memory objects
+ *
+ * Secure world can cache frequently used shared memory objects, for
+ * example objects used as RPC arguments. When secure world is idle this
+ * function returns OPTEE_SMC_RETURN_OK and the cache is enabled. If
+ * secure world isn't idle OPTEE_SMC_RETURN_EBUSY is returned.
+ *
+ * Call register usage:
+ * a0	SMC Function ID, OPTEE_SMC_ENABLE_SHM_CACHE
+ * a1-6	Not used
+ * a7	Hypervisor Client ID register
+ *
+ * Normal return register usage:
+ * a0	OPTEE_SMC_RETURN_OK
+ * a1-7	Preserved
+ *
+ * Not idle return register usage:
+ * a0	OPTEE_SMC_RETURN_EBUSY
+ * a1-7	Preserved
+ */
+#define OPTEE_SMC_FUNCID_ENABLE_SHM_CACHE	11
+#define OPTEE_SMC_ENABLE_SHM_CACHE \
+	OPTEE_SMC_FAST_CALL_VAL(OPTEE_SMC_FUNCID_ENABLE_SHM_CACHE)
+
+/*
+ * Resume from RPC (for example after processing an IRQ)
+ *
+ * Call register usage:
+ * a0	SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC
+ * a1-3	Value of a1-3 when OPTEE_SMC_CALL_WITH_ARG returned
+ *	OPTEE_SMC_RETURN_RPC in a0
+ *
+ * Return register usage is the same as for OPTEE_SMC_*CALL_WITH_ARG above.
+ *
+ * Possible return values
+ * OPTEE_SMC_RETURN_UNKNOWN_FUNCTION	Trusted OS does not recognize this
+ *					function.
+ * OPTEE_SMC_RETURN_OK			Original call completed, result
+ *					updated in the previously supplied.
+ *					struct optee_msg_arg
+ * OPTEE_SMC_RETURN_RPC			Call suspended by RPC call to normal
+ *					world.
+ * OPTEE_SMC_RETURN_ERESUME		Resume failed, the opaque resume
+ *					information was corrupt.
+ */
+#define OPTEE_SMC_FUNCID_RETURN_FROM_RPC	3
+#define OPTEE_SMC_CALL_RETURN_FROM_RPC \
+	OPTEE_SMC_STD_CALL_VAL(OPTEE_SMC_FUNCID_RETURN_FROM_RPC)
+
+#define OPTEE_SMC_RETURN_RPC_PREFIX_MASK	0xFFFF0000
+#define OPTEE_SMC_RETURN_RPC_PREFIX		0xFFFF0000
+#define OPTEE_SMC_RETURN_RPC_FUNC_MASK		0x0000FFFF
+
+#define OPTEE_SMC_RETURN_GET_RPC_FUNC(ret) \
+	((ret) & OPTEE_SMC_RETURN_RPC_FUNC_MASK)
+
+#define OPTEE_SMC_RPC_VAL(func)		((func) | OPTEE_SMC_RETURN_RPC_PREFIX)
+
+/*
+ * Allocate memory for RPC parameter passing. The memory is used to hold a
+ * struct optee_msg_arg.
+ *
+ * "Call" register usage:
+ * a0	This value, OPTEE_SMC_RETURN_RPC_ALLOC
+ * a1	Size in bytes of required argument memory
+ * a2	Not used
+ * a3	Resume information, must be preserved
+ * a4-5	Not used
+ * a6-7	Resume information, must be preserved
+ *
+ * "Return" register usage:
+ * a0	SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC.
+ * a1	Upper 32bits of 64bit physical pointer to allocated
+ *	memory, (a1 == 0 && a2 == 0) if size was 0 or if memory can't
+ *	be allocated.
+ * a2	Lower 32bits of 64bit physical pointer to allocated
+ *	memory, (a1 == 0 && a2 == 0) if size was 0 or if memory can't
+ *	be allocated
+ * a3	Preserved
+ * a4	Upper 32bits of 64bit Shared memory cookie used when freeing
+ *	the memory or doing an RPC
+ * a5	Lower 32bits of 64bit Shared memory cookie used when freeing
+ *	the memory or doing an RPC
+ * a6-7	Preserved
+ */
+#define OPTEE_SMC_RPC_FUNC_ALLOC	0
+#define OPTEE_SMC_RETURN_RPC_ALLOC \
+	OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_ALLOC)
+
+/*
+ * Free memory previously allocated by OPTEE_SMC_RETURN_RPC_ALLOC
+ *
+ * "Call" register usage:
+ * a0	This value, OPTEE_SMC_RETURN_RPC_FREE_ARG
+ * a1	Upper 32bits of 64bit shared memory cookie belonging to this
+ *	argument memory
+ * a2	Lower 32bits of 64bit shared memory cookie belonging to this
+ *	argument memory
+ * a3-7	Resume information, must be preserved
+ *
+ * "Return" register usage:
+ * a0	SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC.
+ * a1-2	Not used
+ * a3-7	Preserved
+ */
+#define OPTEE_SMC_RPC_FUNC_FREE		2
+#define OPTEE_SMC_RETURN_RPC_FREE \
+	OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_FREE)
+
+/*
+ * Deliver an IRQ in normal world.
+ *
+ * "Call" register usage:
+ * a0	OPTEE_SMC_RETURN_RPC_IRQ
+ * a1-7	Resume information, must be preserved
+ *
+ * "Return" register usage:
+ * a0	SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC.
+ * a1-7	Preserved
+ */
+#define OPTEE_SMC_RPC_FUNC_IRQ		4
+#define OPTEE_SMC_RETURN_RPC_IRQ \
+	OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_IRQ)
+
+/*
+ * Do an RPC request. The supplied struct optee_msg_arg tells which
+ * request to do and the parameters for the request. The following fields
+ * are used (the rest are unused):
+ * - cmd		the Request ID
+ * - ret		return value of the request, filled in by normal world
+ * - num_params		number of parameters for the request
+ * - params		the parameters
+ * - param_attrs	attributes of the parameters
+ *
+ * "Call" register usage:
+ * a0	OPTEE_SMC_RETURN_RPC_CMD
+ * a1	Upper 32bit of a 64bit Shared memory cookie holding a
+ *	struct optee_msg_arg, must be preserved, only the data should
+ *	be updated
+ * a2	Lower 32bit of a 64bit Shared memory cookie holding a
+ *	struct optee_msg_arg, must be preserved, only the data should
+ *	be updated
+ * a3-7	Resume information, must be preserved
+ *
+ * "Return" register usage:
+ * a0	SMC Function ID, OPTEE_SMC_CALL_RETURN_FROM_RPC.
+ * a1-2	Not used
+ * a3-7	Preserved
+ */
+#define OPTEE_SMC_RPC_FUNC_CMD		5
+#define OPTEE_SMC_RETURN_RPC_CMD \
+	OPTEE_SMC_RPC_VAL(OPTEE_SMC_RPC_FUNC_CMD)
+
+/* Returned in a0 */
+#define OPTEE_SMC_RETURN_UNKNOWN_FUNCTION 0xFFFFFFFF
+
+/* Returned in a0 only from Trusted OS functions */
+#define OPTEE_SMC_RETURN_OK		0x0
+#define OPTEE_SMC_RETURN_ETHREAD_LIMIT	0x1
+#define OPTEE_SMC_RETURN_EBUSY		0x2
+#define OPTEE_SMC_RETURN_ERESUME	0x3
+#define OPTEE_SMC_RETURN_EBADADDR	0x4
+#define OPTEE_SMC_RETURN_EBADCMD	0x5
+#define OPTEE_SMC_RETURN_ENOMEM		0x6
+#define OPTEE_SMC_RETURN_ENOTAVAIL	0x7
+#define OPTEE_SMC_RETURN_IS_RPC(ret) \
+	(((ret) != OPTEE_SMC_RETURN_UNKNOWN_FUNCTION) && \
+	((((ret) & OPTEE_SMC_RETURN_RPC_PREFIX_MASK) == \
+		OPTEE_SMC_RETURN_RPC_PREFIX)))
+
+#endif /* OPTEE_SMC_H */
diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
new file mode 100644
index 0000000..05716e9
--- /dev/null
+++ b/drivers/tee/optee/rpc.c
@@ -0,0 +1,322 @@
+
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/sched.h>
+#include <linux/tee_drv.h>
+#include "optee_private.h"
+#include "optee_smc.h"
+
+struct wq_entry {
+	struct list_head link;
+	struct completion c;
+	u32 key;
+};
+
+void optee_wait_queue_init(struct optee_wait_queue *priv)
+{
+	mutex_init(&priv->mu);
+	INIT_LIST_HEAD(&priv->db);
+}
+
+void optee_wait_queue_exit(struct optee_wait_queue *priv)
+{
+	mutex_destroy(&priv->mu);
+}
+
+static void handle_rpc_func_cmd_get_time(struct optee_msg_arg *arg)
+{
+	struct optee_msg_param *params;
+	struct timespec64 ts;
+
+	if (arg->num_params != 1)
+		goto bad;
+	params = OPTEE_MSG_GET_PARAMS(arg);
+	if ((params->attr & OPTEE_MSG_ATTR_TYPE_MASK) !=
+			OPTEE_MSG_ATTR_TYPE_VALUE_OUTPUT)
+		goto bad;
+
+	getnstimeofday64(&ts);
+	params->u.value.a = ts.tv_sec;
+	params->u.value.b = ts.tv_nsec;
+
+	arg->ret = TEEC_SUCCESS;
+	return;
+bad:
+	arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+}
+
+static struct wq_entry *wq_entry_get(struct optee_wait_queue *wq, u32 key)
+{
+	struct wq_entry *w;
+
+	mutex_lock(&wq->mu);
+
+	list_for_each_entry(w, &wq->db, link)
+		if (w->key == key)
+			goto out;
+
+	w = kmalloc(sizeof(struct wq_entry), GFP_KERNEL);
+	if (w) {
+		init_completion(&w->c);
+		w->key = key;
+		list_add_tail(&w->link, &wq->db);
+	}
+out:
+	mutex_unlock(&wq->mu);
+	return w;
+}
+
+static void wq_sleep(struct optee_wait_queue *wq, u32 key)
+{
+	struct wq_entry *w = wq_entry_get(wq, key);
+
+	if (w) {
+		wait_for_completion(&w->c);
+		mutex_lock(&wq->mu);
+		list_del(&w->link);
+		mutex_unlock(&wq->mu);
+		kfree(w);
+	}
+}
+
+static void wq_wakeup(struct optee_wait_queue *wq, u32 key)
+{
+	struct wq_entry *w = wq_entry_get(wq, key);
+
+	if (w)
+		complete(&w->c);
+}
+
+static void handle_rpc_func_cmd_wq(struct optee *optee,
+			struct optee_msg_arg *arg)
+{
+	struct optee_msg_param *params;
+
+	if (arg->num_params != 1)
+		goto bad;
+
+	params = OPTEE_MSG_GET_PARAMS(arg);
+	if ((params->attr & OPTEE_MSG_ATTR_TYPE_MASK) !=
+			OPTEE_MSG_ATTR_TYPE_VALUE_INPUT)
+		goto bad;
+
+	switch (params->u.value.a) {
+	case OPTEE_MSG_RPC_WAIT_QUEUE_SLEEP:
+		wq_sleep(&optee->wait_queue, params->u.value.b);
+		break;
+	case OPTEE_MSG_RPC_WAIT_QUEUE_WAKEUP:
+		wq_wakeup(&optee->wait_queue, params->u.value.b);
+		break;
+	default:
+		goto bad;
+	}
+
+	arg->ret = TEEC_SUCCESS;
+	return;
+bad:
+	arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+}
+
+static void handle_rpc_func_cmd_wait(struct optee_msg_arg *arg)
+{
+	struct optee_msg_param *params;
+	u32 msec_to_wait;
+
+	if (arg->num_params != 1)
+		goto bad;
+
+	params = OPTEE_MSG_GET_PARAMS(arg);
+	if ((params->attr & OPTEE_MSG_ATTR_TYPE_MASK) !=
+			OPTEE_MSG_ATTR_TYPE_VALUE_INPUT)
+		goto bad;
+
+	msec_to_wait = params->u.value.a;
+
+	/* set task's state to interruptible sleep */
+	set_current_state(TASK_INTERRUPTIBLE);
+
+	/* take a nap */
+	schedule_timeout(msecs_to_jiffies(msec_to_wait));
+
+	arg->ret = TEEC_SUCCESS;
+	return;
+bad:
+	arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+}
+
+static void handle_rpc_supp_cmd(struct tee_context *ctx,
+			struct optee_msg_arg *arg)
+{
+	struct tee_param *params;
+	struct optee_msg_param *msg_params = OPTEE_MSG_GET_PARAMS(arg);
+
+	arg->ret_origin = TEEC_ORIGIN_COMMS;
+
+	params = kmalloc_array(arg->num_params, sizeof(struct tee_param),
+			       GFP_KERNEL);
+	if (!params) {
+		arg->ret = TEEC_ERROR_OUT_OF_MEMORY;
+		return;
+	}
+
+	if (optee_from_msg_param(params, arg->num_params, msg_params)) {
+		arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+		goto out;
+	}
+
+	arg->ret = optee_supp_thrd_req(ctx, arg->cmd, arg->num_params, params);
+
+	if (optee_to_msg_param(msg_params, arg->num_params, params))
+		arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+out:
+	kfree(params);
+}
+
+static void handle_rpc_func_cmd_shm_alloc(struct tee_context *ctx,
+			struct optee_msg_arg *arg)
+{
+	struct tee_device *teedev = ctx->teedev;
+	struct optee_msg_param *params = OPTEE_MSG_GET_PARAMS(arg);
+	phys_addr_t pa;
+	struct tee_shm *shm;
+	u32 flags;
+	size_t sz;
+	size_t n;
+
+	arg->ret_origin = TEEC_ORIGIN_COMMS;
+
+	if (!arg->num_params ||
+	    params->attr != OPTEE_MSG_ATTR_TYPE_VALUE_INPUT) {
+		arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+		return;
+	}
+
+	for (n = 1; n < arg->num_params; n++) {
+		if (params[n].attr != OPTEE_MSG_ATTR_TYPE_NONE) {
+			arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+			return;
+		}
+	}
+
+	flags = TEE_SHM_MAPPED;
+	switch (params->u.value.a) {
+	case OPTEE_MSG_RPC_SHM_TYPE_APPL:
+		flags |= TEE_SHM_DMA_BUF;
+		break;
+	case OPTEE_MSG_RPC_SHM_TYPE_KERNEL:
+		break;
+	default:
+		arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+		return;
+	}
+	sz = params->u.value.b;
+	/* TODO pass alignment */
+	shm = tee_shm_alloc(teedev, params->u.value.b, flags);
+	if (IS_ERR(shm)) {
+		arg->ret = TEEC_ERROR_OUT_OF_MEMORY;
+		return;
+	}
+
+	if (tee_shm_get_pa(shm, 0, &pa)) {
+		arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+		goto bad;
+	}
+
+	params[0].attr = OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT;
+	params[0].u.tmem.buf_ptr = pa;
+	params[0].u.tmem.size = sz;
+	params[0].u.tmem.shm_ref = (unsigned long)shm;
+	arg->ret = TEEC_SUCCESS;
+	return;
+bad:
+	tee_shm_free(shm);
+}
+
+static void handle_rpc_func_cmd(struct tee_context *ctx, struct optee *optee,
+			struct tee_shm *shm)
+{
+	struct optee_msg_arg *arg;
+
+	arg = tee_shm_get_va(shm, 0);
+	if (IS_ERR(arg)) {
+		dev_err(optee->dev, "%s: tee_shm_get_va %p failed\n",
+			__func__, shm);
+		return;
+	}
+
+	switch (arg->cmd) {
+	case OPTEE_MSG_RPC_CMD_GET_TIME:
+		handle_rpc_func_cmd_get_time(arg);
+		break;
+	case OPTEE_MSG_RPC_CMD_WAIT_QUEUE:
+		handle_rpc_func_cmd_wq(optee, arg);
+		break;
+	case OPTEE_MSG_RPC_CMD_SUSPEND:
+		handle_rpc_func_cmd_wait(arg);
+		break;
+	case OPTEE_MSG_RPC_CMD_SHM_ALLOC:
+		handle_rpc_func_cmd_shm_alloc(ctx, arg);
+		break;
+	default:
+		handle_rpc_supp_cmd(ctx, arg);
+	}
+}
+
+void optee_handle_rpc(struct tee_context *ctx, struct optee_rpc_param *param)
+{
+	struct tee_device *teedev = ctx->teedev;
+	struct optee *optee = tee_get_drvdata(teedev);
+	struct tee_shm *shm;
+	phys_addr_t pa;
+
+	switch (OPTEE_SMC_RETURN_GET_RPC_FUNC(param->a0)) {
+	case OPTEE_SMC_RPC_FUNC_ALLOC:
+		shm = tee_shm_alloc(teedev, param->a1, TEE_SHM_MAPPED);
+		if (!IS_ERR(shm) && !tee_shm_get_pa(shm, 0, &pa)) {
+			reg_pair_from_64(&param->a1, &param->a2, pa);
+			reg_pair_from_64(&param->a4, &param->a5,
+					 (unsigned long)shm);
+		} else {
+			param->a1 = 0;
+			param->a2 = 0;
+			param->a4 = 0;
+			param->a5 = 0;
+		}
+		break;
+	case OPTEE_SMC_RPC_FUNC_FREE:
+		shm = reg_pair_to_ptr(param->a1, param->a2);
+		tee_shm_free(shm);
+		break;
+	case OPTEE_SMC_RPC_FUNC_IRQ:
+		/*
+		 * An IRQ was raised while secure world was executing,
+		 * since all IRQs a handled in Linux a dummy RPC is
+		 * performed to let Linux take the IRQ through the normal
+		 * vector.
+		 */
+		break;
+	case OPTEE_SMC_RPC_FUNC_CMD:
+		shm = reg_pair_to_ptr(param->a1, param->a2);
+		handle_rpc_func_cmd(ctx, optee, shm);
+		break;
+	default:
+		dev_warn(optee->dev, "Unknown RPC func 0x%x\n",
+			 (u32)OPTEE_SMC_RETURN_GET_RPC_FUNC(param->a0));
+		break;
+	}
+
+	param->a0 = OPTEE_SMC_CALL_RETURN_FROM_RPC;
+}
diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c
new file mode 100644
index 0000000..b6478b6
--- /dev/null
+++ b/drivers/tee/optee/supp.c
@@ -0,0 +1,212 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/device.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include "optee_private.h"
+
+void optee_supp_init(struct optee_supp *supp)
+{
+	memset(supp, 0, sizeof(*supp));
+	mutex_init(&supp->thrd_mutex);
+	mutex_init(&supp->supp_mutex);
+	init_completion(&supp->data_to_supp);
+	init_completion(&supp->data_from_supp);
+}
+
+void optee_supp_uninit(struct optee_supp *supp)
+{
+	mutex_destroy(&supp->thrd_mutex);
+	mutex_destroy(&supp->supp_mutex);
+}
+
+u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params,
+			struct tee_param *param)
+{
+	struct optee *optee = tee_get_drvdata(ctx->teedev);
+	struct optee_supp *supp = &optee->supp;
+	u32 ret;
+
+	/*
+	 * Other threads blocks here until we've copied our answer from
+	 * supplicant.
+	 */
+	mutex_lock(&supp->thrd_mutex);
+
+	/*
+	 * We have exclusive access now since the supplicant at this
+	 * point is either doing a
+	 * wait_for_completion_interruptible(data_to_supp) or is in
+	 * userspace still about to do the ioctl() to enter
+	 * optee_supp_read() below.
+	 */
+
+	supp->func = func;
+	supp->num_params = num_params;
+	supp->param = param;
+	supp->req_posted = true;
+
+	/* Let supplicant get the data */
+	complete(&supp->data_to_supp);
+
+	/*
+	 * Wait for supplicant to process and return result, once we've
+	 * returned from wait_for_completion(data_from_supp) we have
+	 * exclusive access again.
+	 */
+	wait_for_completion(&supp->data_from_supp);
+
+	ret = supp->ret;
+	supp->param = NULL;
+	supp->req_posted = false;
+
+	/* We're done, let someone else talk to the supplicant now. */
+	mutex_unlock(&supp->thrd_mutex);
+
+	return ret;
+}
+
+int optee_supp_recv(struct tee_context *ctx, u32 *func, u32 *num_params,
+		struct tee_param *param)
+{
+	struct tee_device *teedev = ctx->teedev;
+	struct optee *optee = tee_get_drvdata(teedev);
+	struct optee_supp *supp = &optee->supp;
+	int rc;
+
+	/*
+	 * In case two supplicants or two threads in one supplicant is
+	 * calling this function simultaneously we need to protect the
+	 * data with a mutex which we'll release before returning.
+	 */
+	mutex_lock(&supp->supp_mutex);
+
+	if (supp->supp_next_send) {
+		/*
+		 * optee_supp_recv() has been called again without
+		 * a optee_supp_send() in between. Supplicant has
+		 * probably been restarted before it was able to
+		 * write back last result. Abort last request and
+		 * wait for a new.
+		 */
+		if (supp->req_posted) {
+			supp->ret = TEEC_ERROR_COMMUNICATION;
+			supp->supp_next_send = false;
+			complete(&supp->data_from_supp);
+		}
+	}
+
+	/*
+	 * This is where supplicant will be hanging most of the
+	 * time, let's make this interruptable so we can easily
+	 * restart supplicant if needed.
+	 */
+	if (wait_for_completion_interruptible(&supp->data_to_supp)) {
+		rc = -ERESTARTSYS;
+		goto out;
+	}
+
+	/* We have exlusive access to the data */
+
+	if (*num_params < supp->num_params) {
+		/*
+		 * Not enough room for parameters, tell supplicant
+		 * it failed and abort last request.
+		 */
+		supp->ret = TEEC_ERROR_COMMUNICATION;
+		rc = -EINVAL;
+		complete(&supp->data_from_supp);
+		goto out;
+	}
+
+	*func = supp->func;
+	*num_params = supp->num_params;
+	memcpy(param, supp->param,
+	       sizeof(struct tee_param) * supp->num_params);
+
+	/* Allow optee_supp_send() below to do its work */
+	supp->supp_next_send = true;
+
+	rc = 0;
+out:
+	mutex_unlock(&supp->supp_mutex);
+	return rc;
+}
+
+int optee_supp_send(struct tee_context *ctx, u32 ret, u32 num_params,
+			struct tee_param *param)
+{
+	struct tee_device *teedev = ctx->teedev;
+	struct optee *optee = tee_get_drvdata(teedev);
+	struct optee_supp *supp = &optee->supp;
+	size_t n;
+	int rc = 0;
+
+	/*
+	 * We still have exclusive access to the data since that's how we
+	 * left it when returning from optee_supp_read().
+	 */
+
+	/* See comment on mutex in optee_supp_read() above */
+	mutex_lock(&supp->supp_mutex);
+
+	if (!supp->supp_next_send) {
+		/*
+		 * Something strange is going on, supplicant shouldn't
+		 * enter optee_supp_send() in this state
+		 */
+		rc = -ENOENT;
+		goto out;
+	}
+
+	if (num_params != supp->num_params) {
+		/*
+		 * Something is wrong, let supplicant restart. Next call to
+		 * optee_supp_recv() will give an error to the requesting
+		 * thread and release it.
+		 */
+		rc = -EINVAL;
+		goto out;
+	}
+
+	/* Update out and in/out parameters */
+	for (n = 0; n < num_params; n++) {
+		struct tee_param *p = supp->param + n;
+
+		switch (p->attr) {
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT:
+			p->u.value.a = param[n].u.value.a;
+			p->u.value.b = param[n].u.value.b;
+			p->u.value.c = param[n].u.value.c;
+			break;
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT:
+		case TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INOUT:
+			p->u.memref.size = param[n].u.memref.size;
+			break;
+		default:
+			break;
+		}
+	}
+	supp->ret = ret;
+
+	/* Allow optee_supp_recv() above to do its work */
+	supp->supp_next_send = false;
+
+	/* Let the requesting thread continue */
+	complete(&supp->data_from_supp);
+out:
+	mutex_unlock(&supp->supp_mutex);
+	return rc;
+}
-- 
1.9.1



From horms at verge.net.au  Thu Feb 11 09:22:18 2016
From: horms at verge.net.au (Simon Horman)
Date: Thu, 11 Feb 2016 18:22:18 +0100
Subject: [GIT PULL] Renesas ARM Based SoC DT Updates for v4.6
In-Reply-To: <CAOesGMjeyah0qpwWR=RJOF61dVGGqkxmGUJrE0qYNuCOwoPFjQ@mail.gmail.com>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
 <20160208215130.GJ25468@localhost>
 <CAMuHMdVWYVEHTvGYEZkEXpEaMzfZ_NfMAb0o8HtVcJM+GDdfmA@mail.gmail.com>
 <20160209183921.GA1089@verge.net.au>
 <CAOesGMjeyah0qpwWR=RJOF61dVGGqkxmGUJrE0qYNuCOwoPFjQ@mail.gmail.com>
Message-ID: <20160211172218.GD12080@verge.net.au>

On Wed, Feb 10, 2016 at 07:55:30PM -0800, Olof Johansson wrote:
> Hi,
> 
> On Tue, Feb 9, 2016 at 10:39 AM, Simon Horman <horms at verge.net.au> wrote:
> > On Tue, Feb 09, 2016 at 08:39:31AM +0100, Geert Uytterhoeven wrote:
> >> Hi Olof,
> >>
> >> On Mon, Feb 8, 2016 at 10:51 PM, Olof Johansson <olof at lixom.net> wrote:
> >> > On Thu, Feb 04, 2016 at 03:30:02PM +0100, Simon Horman wrote:
> >> >> Please consider these Renesas ARM based SoC DT updates for v4.6.
> >> >>
> >> >>
> >> >> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> >> >>
> >> >>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> >> >>
> >> >> are available in the git repository at:
> >> >>
> >> >>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-for-v4.6
> >> >>
> >> >> for you to fetch changes up to d7a11140d0a659e5c1f83627792f95b6713030a2:
> >> >>
> >> >>   ARM: dts: silk: Enable SCIF_CLK frequency and pins (2016-02-02 14:02:28 +0100)
> >> >>
> >> >> ----------------------------------------------------------------
> >> >> Renesas ARM Based SoC DT Updates for v4.6
> >> >>
> >> >> * Use SCIF and USBHS fallback compatibility strings
> >> >> * Add Baud Rate Generator (BRG) support for (H)SCIF
> >> >> * Enable SCIF_CLK frequency and pins
> >> >> * Use GIC_* defines
> >> >> * Migrate to generic l2c OF initialization on r8a7740
> >> >> * Enable audio on r8a7793/gose
> >> >> * Enable HDMI vidio out on r8a7793
> >> >> * Enable i2c on r8a7793/gose
> >> >> * Enable QSPI on alt
> >> >> * Enable GPIO keys and leds on gise
> >> >> * Enable audio on porter
> >> >> * Enable DU on porter
> >> >>
> >> >> ----------------------------------------------------------------
> >> >> Geert Uytterhoeven (22):
> >> >>       ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization
> >> >>       ARM: shmobile: r8a7740: Remove mapping of L2 cache controller registers
> >> >
> >> > Hmm. Those aren't DT changes. There's also nothing for r8a7740 to convert
> >> > L2 init to DT earlier in this branch, which makes this look like it's just
> >> > a generic cleanup that should go in independently in your cleanup branch.
> >> >
> >> > Or am I missing some dependency that isn't obvious? If I'm not, then please
> >> > respin this branch and move those to the place they belong (cleanup).
> >>
> >> The dependency is commit 374e70075e58acfe ("ARM: shmobile: r8a7740 dtsi: Add
> >> L2 cache-controller node"), which has already entered mainline in v4.5-rc1.
> >>
> >> So I agree with your comments.
> >
> > Sorry for the mix-up.
> > I'll see about respinning this.
> 
> I've merged the patches, so respinning won't work. Instead, please
> follow up with incremental fixes instead.

Hi Olof,

sorry once again for the mix-up.

If you have already pulled this pull request then I am happy.
However, I don't see it in the arm-soc tree and if you haven't pulled it
and it isn't too much trouble I would like to re-spin as I have a further
r8a7740 cleanup in the pipeline.


From tony at atomide.com  Thu Feb 11 09:26:32 2016
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 11 Feb 2016 09:26:32 -0800
Subject: [PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred
 probe for pm_runtime_reinit
In-Reply-To: <CAPDyKFo4Jyjwyvr3P5VHfDhQ87K9mnR01N-NtKz-yx2ycnfOLg@mail.gmail.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-2-git-send-email-tony@atomide.com>
 <CAPDyKFpAcsfLgtu93P45fTEg11MjdGwREcyeGSS7vt6GWbNu_w@mail.gmail.com>
 <20160211150240.GR19432@atomide.com>
 <CAPDyKFo4Jyjwyvr3P5VHfDhQ87K9mnR01N-NtKz-yx2ycnfOLg@mail.gmail.com>
Message-ID: <20160211172632.GT19432@atomide.com>

* Ulf Hansson <ulf.hansson at linaro.org> [160211 07:14]:
> On 11 February 2016 at 16:02, Tony Lindgren <tony at atomide.com> wrote:
> > * Ulf Hansson <ulf.hansson at linaro.org> [160211 02:19]:
> >> On 11 February 2016 at 00:02, Tony Lindgren <tony at atomide.com> wrote:
> >> >
> >> > Ulf, I'd like to merge this along with other related fixes via the
> >> > ARM SoC tree if no objections, please review and ack if this look OK
> >> > to you.
> >>
> >> I have some other omap_hsmmc patches queued for 4.6, so I prefer to
> >> send this via my mmc tree.
> >>
> >> I guess that's okay as well!?
> >
> > Naturally yes, please go ahead thanks!
> 
> Okay!
> 
> BTW, did you notice my other comments to the patch?
> 
> I can fix them before applying, unless you want to send a v2?

Oh sorry, no I missed the rest of your comments again, I really
need to recalibrate my reading habits obviously if I keep
missing comments on regular basis..

You comments make sense to me. Below is the patch with only
minimal changes. Seems to work just fine and hit off mode for
suspend too.

Regards,

Tony

8< -------------------
>From eb3c93421f01fb6198f76127262a92b527dd214c Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony at atomide.com>
Date: Tue, 9 Feb 2016 09:31:10 -0800
Subject: [PATCH] mmc: omap_hsmmc: Fix PM regression with deferred probe for
 pm_runtime_reinit

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-mmc at vger.kernel.org
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Kevin Hilman <khilman at baylibre.com>
Cc: Nishanth Menon <nm at ti.com>
Cc: Rafael J. Wysocki <rafael at kernel.org>
Cc: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Tero Kristo <t-kristo at ti.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>

--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2232,6 +2232,7 @@ err_irq:
 		dma_release_channel(host->tx_chan);
 	if (host->rx_chan)
 		dma_release_channel(host->rx_chan);
+	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);
 	if (host->dbclk)
@@ -2253,6 +2254,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
 	dma_release_channel(host->tx_chan);
 	dma_release_channel(host->rx_chan);
 
+	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);
 	device_init_wakeup(&pdev->dev, false);


From yang.shi at linaro.org  Thu Feb 11 09:29:57 2016
From: yang.shi at linaro.org (Shi, Yang)
Date: Thu, 11 Feb 2016 09:29:57 -0800
Subject: [PATCH] arm64: reenable interrupt when handling ptrace breakpoint
In-Reply-To: <20160211135435.GG32084@arm.com>
References: <5671CD5B.9030907@linaro.org> <20151221104818.GF23092@arm.com>
 <alpine.DEB.2.11.1512211749180.28591@nanos> <20151221170028.GT23092@arm.com>
 <56955B3A.5010303@linaro.org> <20160113102622.GC25458@arm.com>
 <569686BA.6050703@linaro.org> <20160113172303.GH25458@arm.com>
 <56969312.7070309@linaro.org> <56B5135B.3050801@linaro.org>
 <20160211135435.GG32084@arm.com>
Message-ID: <56BCC515.2030107@linaro.org>

On 2/11/2016 5:54 AM, Will Deacon wrote:
> On Fri, Feb 05, 2016 at 01:25:47PM -0800, Shi, Yang wrote:
>> On 1/13/2016 10:10 AM, Shi, Yang wrote:
>>> On 1/13/2016 9:23 AM, Will Deacon wrote:
>>>> On Wed, Jan 13, 2016 at 09:17:46AM -0800, Shi, Yang wrote:
>>>>> On 1/13/2016 2:26 AM, Will Deacon wrote:
>>>>>> On Tue, Jan 12, 2016 at 11:59:54AM -0800, Shi, Yang wrote:
>>>>>>> This might be buried in email storm during the holiday. Just want
>>>>>>> to double
>>>>>>> check the status. I'm supposed there is no objection for getting it
>>>>>>> merged
>>>>>>> in upstream?
>>>>>>
>>>>>> Sorry, when you replied with:
>>>>>>
>>>>>>> I think we could just extend the "signal delay send" approach from
>>>>>>> x86-64
>>>>>>> to arm64, which is currently used by x86-64 on -rt kernel only.
>>>>>>
>>>>>> I understood that you were going to fix -rt, so I dropped this pending
>>>>>> anything more from you.
>>>>>>
>>>>>> What's the plan?
>>>>>
>>>>> Sorry for the confusion. The "signal delay send" approach used by
>>>>> x86-64 -rt
>>>>> should be not necessary for arm64 right now. Reenabling interrupt is
>>>>> still
>>>>> the preferred approach.
>>>>>
>>>>> Since x86-64 has per-CPU IST exception stack, so preemption has to be
>>>>> disabled all the time. However, it is not applicable to other
>>>>> architectures
>>>>> for now, including arm64.
>>>>
>>>> Actually, we grew support for a separate IRQ stack in the recent merge
>>>> window. Does that change things here, or are you referring to something
>>>> else?
>>>
>>> Had a quick look at the patches, it looks the irq stack is not nestable
>>> and it switches back to the original stack as long as irq handler is
>>> done before preempt happens. So, it sounds it won't change things here.
>>
>>
>> Just had a quick test on 4.5-rc1. It survives with kgdbts, ptrace and ltp.
>> So, it sounds safe with the "separate IRQ stack" change.
>
> I quite liked the sigtrap consolidation in my earlier (broken) approach.
> Does the following work for you?

Yes, sure. One minor comment below.

>
> Will
>
> --->8
>
>  From e04a28d45ff343b47a4ffc4dee3a3e279e76ddfa Mon Sep 17 00:00:00 2001
> From: Will Deacon <will.deacon at arm.com>
> Date: Wed, 10 Feb 2016 16:05:28 +0000
> Subject: [PATCH] arm64: debug: re-enable irqs before sending breakpoint
>   SIGTRAP
>
> force_sig_info can sleep under an -rt kernel, so attempting to send a
> breakpoint SIGTRAP with interrupts disabled yields the following BUG:
>
>    BUG: sleeping function called from invalid context at
>    /kernel-source/kernel/locking/rtmutex.c:917
>    in_atomic(): 0, irqs_disabled(): 128, pid: 551, name: test.sh
>    CPU: 5 PID: 551 Comm: test.sh Not tainted 4.1.13-rt13 #7
>    Hardware name: Freescale Layerscape 2085a RDB Board (DT)
>    Call trace:
> 	 dump_backtrace+0x0/0x128
> 	 show_stack+0x24/0x30
> 	 dump_stack+0x80/0xa0
> 	 ___might_sleep+0x128/0x1a0
> 	 rt_spin_lock+0x2c/0x40
> 	 force_sig_info+0xcc/0x210
> 	 brk_handler.part.2+0x6c/0x80
> 	 brk_handler+0xd8/0xe8
> 	 do_debug_exception+0x58/0xb8
>
> This patch fixes the problem by ensuring that interrupts are enabled
> prior to sending the SIGTRAP if they were already enabled in the user
> context.
>
> Reported-by: Yang Shi <yang.shi at linaro.org>
> Signed-off-by: Will Deacon <will.deacon at arm.com>
> ---
>   arch/arm64/kernel/debug-monitors.c | 48 +++++++++++++++++---------------------
>   1 file changed, 22 insertions(+), 26 deletions(-)
>
> diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
> index 8aee3aeec3e6..c536c9e307b9 100644
> --- a/arch/arm64/kernel/debug-monitors.c
> +++ b/arch/arm64/kernel/debug-monitors.c
> @@ -226,11 +226,28 @@ static int call_step_hook(struct pt_regs *regs, unsigned int esr)
>   	return retval;
>   }
>
> +static void send_user_sigtrap(int si_code)
> +{
> +	struct pt_regs *regs = current_pt_regs();
> +	siginfo_t info = {
> +		.si_signo	= SIGTRAP,
> +		.si_errno	= 0,
> +		.si_code	= si_code,
> +		.si_addr	= (void __user *)instruction_pointer(regs),
> +	};
> +
> +	if (WARN_ON(!user_mode(regs)))

Maybe BUG_ON should be used here? Since send_user_sigtrap is called only 
when user_mode is positive, and interrupt is disabled at this point, so 
if it is not positive, it sounds list a bug.

Thanks,
Yang

> +		return;
> +
> +	if (interrupts_enabled(regs))
> +		local_irq_enable();
> +
> +	force_sig_info(SIGTRAP, &info, current);
> +}
> +
>   static int single_step_handler(unsigned long addr, unsigned int esr,
>   			       struct pt_regs *regs)
>   {
> -	siginfo_t info;
> -
>   	/*
>   	 * If we are stepping a pending breakpoint, call the hw_breakpoint
>   	 * handler first.
> @@ -239,11 +256,7 @@ static int single_step_handler(unsigned long addr, unsigned int esr,
>   		return 0;
>
>   	if (user_mode(regs)) {
> -		info.si_signo = SIGTRAP;
> -		info.si_errno = 0;
> -		info.si_code  = TRAP_HWBKPT;
> -		info.si_addr  = (void __user *)instruction_pointer(regs);
> -		force_sig_info(SIGTRAP, &info, current);
> +		send_user_sigtrap(TRAP_HWBKPT);
>
>   		/*
>   		 * ptrace will disable single step unless explicitly
> @@ -307,17 +320,8 @@ static int call_break_hook(struct pt_regs *regs, unsigned int esr)
>   static int brk_handler(unsigned long addr, unsigned int esr,
>   		       struct pt_regs *regs)
>   {
> -	siginfo_t info;
> -
>   	if (user_mode(regs)) {
> -		info = (siginfo_t) {
> -			.si_signo = SIGTRAP,
> -			.si_errno = 0,
> -			.si_code  = TRAP_BRKPT,
> -			.si_addr  = (void __user *)instruction_pointer(regs),
> -		};
> -
> -		force_sig_info(SIGTRAP, &info, current);
> +		send_user_sigtrap(TRAP_BRKPT);
>   	} else if (call_break_hook(regs, esr) != DBG_HOOK_HANDLED) {
>   		pr_warning("Unexpected kernel BRK exception at EL1\n");
>   		return -EFAULT;
> @@ -328,7 +332,6 @@ static int brk_handler(unsigned long addr, unsigned int esr,
>
>   int aarch32_break_handler(struct pt_regs *regs)
>   {
> -	siginfo_t info;
>   	u32 arm_instr;
>   	u16 thumb_instr;
>   	bool bp = false;
> @@ -359,14 +362,7 @@ int aarch32_break_handler(struct pt_regs *regs)
>   	if (!bp)
>   		return -EFAULT;
>
> -	info = (siginfo_t) {
> -		.si_signo = SIGTRAP,
> -		.si_errno = 0,
> -		.si_code  = TRAP_BRKPT,
> -		.si_addr  = pc,
> -	};
> -
> -	force_sig_info(SIGTRAP, &info, current);
> +	send_user_sigtrap(TRAP_BRKPT);
>   	return 0;
>   }
>
>



From wsa at the-dreams.de  Thu Feb 11 09:34:28 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Thu, 11 Feb 2016 18:34:28 +0100
Subject: [PATCH 2/7] i2c: omap: Fix PM regression with deferred probe for
 pm_runtime_reinit
In-Reply-To: <1455145370-20301-3-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-3-git-send-email-tony@atomide.com>
Message-ID: <20160211173427.GB1524@katana>


> Wolfram, I'd like to merge this along with other related fixes via
> the ARM SoC tree if no objections, please review and ack if this
> look OK to you.

Well, since most patches seem to be picked up individually now, I'd
prefer to do the same. This is v4.5 material, or?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/1252e49f/attachment.sig>

From tony at atomide.com  Thu Feb 11 09:36:20 2016
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 11 Feb 2016 09:36:20 -0800
Subject: [PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred
 probe for pm_runtime_reinit
In-Reply-To: <20160211155255.GA1953@sirena.org.uk>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-4-git-send-email-tony@atomide.com>
 <20160211115128.GF13270@sirena.org.uk>
 <20160211150806.GS19432@atomide.com>
 <20160211155255.GA1953@sirena.org.uk>
Message-ID: <20160211173620.GU19432@atomide.com>

* Mark Brown <broonie at kernel.org> [160211 07:54]:
> On Thu, Feb 11, 2016 at 07:08:06AM -0800, Tony Lindgren wrote:
> > * Mark Brown <broonie at kernel.org> [160211 03:52]:
> 
> > > Why, I'm not seeing any dependencies here?  I'd also expect to be seeing
> > > an awful lot more changes like this, this shouldn't be an OMAP thing -
> > > do we need to fix the core API and then roll out the transition in a
> > > different way?
> 
> > Please feel free to pick up this one if you have other fixes
> > lined up, nothing stopping that.
> 
> I'll take it myself unless there is a strong reason to merge it as part
> of another series.

OK thanks!

> > There will be likely more fixes like this to make drivers follow
> > the PM runtime API documentation. These were just the initial
> > ones that were obvious.
> 
> This does sound like there's been a change in the interface compared to
> what users are actually doing - is this an actual problem or is it just
> a divergence from docs?

It's an actual problem at least on omaps as the omap_device code
is very picky about the hardware state.

Depending how the PM runtime is implemented, it may be a problem
for some other cases too.

For non-omap cases, my guess is that it's mostly a divergence from
the docs and non-critical.

Regards,

Tony


From yang.shi at linaro.org  Thu Feb 11 09:36:52 2016
From: yang.shi at linaro.org (Shi, Yang)
Date: Thu, 11 Feb 2016 09:36:52 -0800
Subject: [PATCH] arm64: use raw_smp_processor_id in stack backtrace dump
In-Reply-To: <56BC6544.70001@arm.com>
References: <1455053182-31404-1-git-send-email-yang.shi@linaro.org>
 <20160210102939.GD1052@arm.com> <56BB247F.6040202@arm.com>
 <20160210121030.GH1052@arm.com> <56BB7D7B.4060002@linaro.org>
 <56BC6544.70001@arm.com>
Message-ID: <56BCC6B4.7060106@linaro.org>

On 2/11/2016 2:41 AM, James Morse wrote:
> Hi!
>
> On 10/02/16 18:12, Shi, Yang wrote:
>> On 2/10/2016 4:10 AM, Will Deacon wrote:
>>> On Wed, Feb 10, 2016 at 11:52:31AM +0000, James Morse wrote:
>>>> On 10/02/16 10:29, Will Deacon wrote:
>>>>> On Tue, Feb 09, 2016 at 01:26:22PM -0800, Yang Shi wrote:
>>>>>> dump_backtrace may be called in kthread context, which is not bound to a
>>>>>> single
>>>>>> cpu, i.e. khungtaskd, then calling smp_processor_id may trigger the below bug
>>>>>> report:
>>>>>
>>>>> If we're preemptible here, it means that our irq_stack_ptr is potentially
>>>>> bogus. Whilst this isn't an issue for kthreads, it does feel like we
>>>>> could make this slightly more robust in the face of potential frame
>>>>> corruption. Maybe just zero the IRQ stack pointer if we're in preemptible
>>>>> context?
>>>>
>>>> Switching between stacks is only valid if we are tracing ourselves while on the
>>>> irq_stack, we should probably prevent it for other tasks too.
>>>>
>>>> Something like (untested):
>>>> ---------------------
>>>> if (tsk == current && in_atomic())
>>>>      irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
>>
>> One follow up question, is it possible to have both tsk != current and
>> on_irq_stack is true at the same time?
>
> No. If you are tracing an irq stack, it must be your own stack.
>
> If this weren't the case, it would be the stack of a running task on a remote
> CPU, and you would be racing with the remote CPU changing the values you are
> reading. Fortunately nothing tries to do this.
>
> (The third case would be tracing a sleeping irq stack - this doesn't happen
>   either, as we switch back to the original stack before calling schedule()).
>
>
>> If it is possible, this may be a problem
>> in unwind_frame called by profile_pc which has tsk being NULL.
>
> Ah, well spotted. I guess there should also be a != NULL comparison thrown into
> the mix. I don't think it will be a problem for profile_pc() as it should always
> find a !in_lock_functions() frame before it needs to switch stack, (which we are
> preventing it from doing). If this ever did happen, it will return 0.

Thanks for the elaboration. I changed the logic a little bit to:

if (tsk == current && !preemptible())
                 irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
else
                 irq_stack_ptr = 0;

In this way, the NULL pointer will be covered by "else" too.

v2 patch will be sent out soon once I'm done some smoke testing.

Yang

>
>
> Thanks,
>
> James
>



From stefan.wahren at i2se.com  Thu Feb 11 09:55:06 2016
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Thu, 11 Feb 2016 18:55:06 +0100 (CET)
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in
 console
In-Reply-To: <56BC895E.2010108@sperl.org>
References: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
 <56BC895E.2010108@sperl.org>
Message-ID: <1617009200.323700.219000a8-c162-4594-aacc-a7e9894518b2.open-xchange@email.1und1.de>

Hi,

> Martin Sperl <martin at sperl.org> hat am 11. Februar 2016 um 14:15 geschrieben:
>
> The only real difference is this diff:
> @@ -41,6 +41,4 @@
> 20101000.cprman: bcm2835_clock_get_parent - pwm
> 20101000.cprman: bcm2835_clock_get_parent - hsm
> 20101000.cprman: bcm2835_pll_on - pllc
> - 20101000.cprman: bcm2835_pll_on - plld
> - 20101000.cprman: bcm2835_clock_on - uart
> 20101000.cprman: bcm2835_clock_on - emmc
>
> so plld and uart are not started for the console=ttyS0 case.
>
> After I instrumented clk-bcm2835.c to see what happens in the driver
> and running: /sbin/getty -a root -L ttyAMA0 115200 vt100
>
> I get the following:
> [ 146.342341] bcm2835-clk 20101000.cprman: bcm2835_pll_on - plld
> [ 146.348426] bcm2835-clk 20101000.cprman: bcm2835_clock_on - uart
> [ 146.354639] uart-pl011 20201000.uart: no DMA platform data
> [ 146.375535] bcm2835-clk 20101000.cprman: bcm2835_clock_off - uart
> [ 146.381776] bcm2835-clk 20101000.cprman: bcm2835_clock_wait_busy - uart
> [ 146.388595] bcm2835-clk 20101000.cprman: bcm2835_pll_off - plld
> [ 146.396574] bcm2835-clk 20101000.cprman: bcm2835_pll_on - plld
> [ 146.502551] bcm2835-clk 20101000.cprman: plld: couldn't lock PLL
> [ 146.508726] ------------[ cut here ]------------
> [ 146.513448] WARNING: CPU: 0 PID: 2349 at drivers/clk/clk.c:680
> clk_core_disa)
> [ 146.522673] ---[ end trace 33268753126338e9 ]---
> [ 146.527478] ------------[ cut here ]------------
> [ 146.532224] WARNING: CPU: 0 PID: 2349 at drivers/clk/clk.c:575
> clk_core_unpr)
> [ 146.541866] ---[ end trace 33268753126338ea ]---
>
> So I wonder why we would disable and reenable the plld and uart clock

I think the reason for this behavior can be found in the uart-pl011 driver which
plays with the clocks.

According to the clock tree "plld" seems to be critical and shouldn't be
disabled?

>
> Note that just adding a return in bcm2835_pll_off like this:
> @@ -900,6 +905,9 @@ static void bcm2835_pll_off(struct clk_hw *hw)
> struct bcm2835_cprman *cprman = pll->cprman;
> const struct bcm2835_pll_data *data = pll->data;
>
> + dev_err(cprman->dev, "%s - %s\n", __FUNCTION__, clk_hw_get_name(hw));
> + return;
> +
> cprman_write(cprman, data->cm_ctrl_reg, CM_PLL_ANARST);
> cprman_write(cprman, data->a2w_ctrl_reg, A2W_PLL_CTRL_PWRDN);
> }
>
> avoids the crash, but the tty is non-functional.
>
> Calling sequence of the clock driver is:
> [ 145.022546] bcm2835-clk 20101000.cprman: bcm2835_pll_on - plld
> [ 145.028619] bcm2835-clk 20101000.cprman: bcm2835_clock_on - uart
> [ 145.034807] uart-pl011 20201000.uart: no DMA platform data
> [ 145.045089] bcm2835-clk 20101000.cprman: bcm2835_clock_off - uart
> [ 145.051418] bcm2835-clk 20101000.cprman: bcm2835_clock_wait_busy - uart
> [ 145.058215] bcm2835-clk 20101000.cprman: bcm2835_pll_off - plld
> [ 145.065779] bcm2835-clk 20101000.cprman: bcm2835_pll_on - plld
> [ 145.071761] bcm2835-clk 20101000.cprman: bcm2835_clock_on - uart
>
> debugfs shows the following after the above:
> root at raspcm:~# head /sys/kernel/debug/clk/uart*/clk_rate
> ==> /sys/kernel/debug/clk/uart0_pclk/clk_rate <==
> 3000000
>
> ==> /sys/kernel/debug/clk/uart1_pclk/clk_rate <==
> 125000000
>
> ==> /sys/kernel/debug/clk/uart/clk_rate <==
> 2997598
>
> Is this maybe related to the uart0_pclk, uart1_pclk, apb_pclk
> clocks created and registered in bcm2835_init_clocks?

Related or not i think we should get the rid off them.

>
> Any Ideas?
>
> Thanks,
> Martin
>
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel


From tony at atomide.com  Thu Feb 11 09:56:58 2016
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 11 Feb 2016 09:56:58 -0800
Subject: [PATCH 2/7] i2c: omap: Fix PM regression with deferred probe for
 pm_runtime_reinit
In-Reply-To: <20160211173427.GB1524@katana>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-3-git-send-email-tony@atomide.com>
 <20160211173427.GB1524@katana>
Message-ID: <20160211175658.GW19432@atomide.com>

* Wolfram Sang <wsa at the-dreams.de> [160211 09:35]:
> 
> > Wolfram, I'd like to merge this along with other related fixes via
> > the ARM SoC tree if no objections, please review and ack if this
> > look OK to you.
> 
> Well, since most patches seem to be picked up individually now, I'd
> prefer to do the same. This is v4.5 material, or?

Sure please do, thanks. And yes for v4.5 please. Although
I've only seen this happen with the MMC driver so far, there's
still a slight chance of this happening with the other drivers
using omap_device.

Regards,

Tony




From linux at arm.linux.org.uk  Thu Feb 11 10:00:32 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 11 Feb 2016 18:00:32 +0000
Subject: [PATCH v2] ARM: mm: mark section-aligned portion of rodata NX
In-Reply-To: <CAGXu5jLDK8eVO2kUD1cB3TArL8k8pF=igc3O04Fa40QgQ2pwNw@mail.gmail.com>
References: <20151207223534.GA13722@www.outflux.net>
 <CAKv+Gu9EeKQk7GOAPV2cvff10=kD49u+oP-yEiOrJBPOF=QNtw@mail.gmail.com>
 <CAGXu5j+Pc7ucC4tmxHyDW7aW88pwQvMejuR2Ehdxp=vY+pv-5w@mail.gmail.com>
 <CAGXu5jLDK8eVO2kUD1cB3TArL8k8pF=igc3O04Fa40QgQ2pwNw@mail.gmail.com>
Message-ID: <20160211180032.GY10826@n2100.arm.linux.org.uk>

On Fri, Jan 22, 2016 at 01:19:03PM -0800, Kees Cook wrote:
> On Tue, Dec 8, 2015 at 10:38 AM, Kees Cook <keescook at chromium.org> wrote:
> > On Mon, Dec 7, 2015 at 11:47 PM, Ard Biesheuvel
> > <ard.biesheuvel at linaro.org> wrote:
> >> On 7 December 2015 at 23:35, Kees Cook <keescook at chromium.org> wrote:
> >>>  /*
> >>> + * Without CONFIG_DEBUG_ALIGN_RODATA, __start_rodata_section_aligned will
> >>> + * be the first section-aligned location after __start_rodata. Otherwise,
> >>> + * it will be equal to __start_rodata.
> >>> + */
> >>> +__start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
...

I'm afraid this causes build errors on two configurations:

./arch/arm/kernel/vmlinux.lds:701: undefined symbol `SECTION_SHIFT' referenced in expression

which I think is down to the new __start_rodata_section_aligned line.

Olof's builder errored out with this for both allnoconfig and
lpc18xx_defconfig builds.  Both probably due to CONFIG_MMU being
unset, and hence no definition for SECTION_SHIFT.

I think you need to make this conditional on CONFIG_MMU.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From kernel at martin.sperl.org  Thu Feb 11 10:06:43 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Thu, 11 Feb 2016 19:06:43 +0100
Subject: [PATCH 3/4] spi: bcm2835aux: set up spi-mode before asserting
 cs-gpio
In-Reply-To: <1455041435-8015-4-git-send-email-stephanolbrich@gmx.de>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <1455041435-8015-4-git-send-email-stephanolbrich@gmx.de>
Message-ID: <F75D5360-5D55-453F-89A7-7BB4B07427C5@martin.sperl.org>


> On 09.02.2016, at 19:10, stephanolbrich at gmx.de wrote:
> 
> From: Stephan Olbrich <stephanolbrich at gmx.de>
> 
> When using reverse polarity for clock (spi-cpol) on a device
> the clock line gets altered after chip-select has been asserted
> resulting in an additional clock beat, which confuses hardware.
> 
> To avoid this situation this patch moves the setup of polarity
> (spi-cpol and spi-cpha) outside of the chip-select into
> prepare_message, which is run prior to asserting chip-select.
> 
> Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
> ---
> drivers/spi/spi-bcm2835aux.c | 54 +++++++++++++++++++++++++++++++-------------
> 1 file changed, 38 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
> index d2f0067..b90aa34 100644
> --- a/drivers/spi/spi-bcm2835aux.c
> +++ b/drivers/spi/spi-bcm2835aux.c
> @@ -218,9 +218,9 @@ static irqreturn_t bcm2835aux_spi_interrupt(int irq, void *dev_id)
> 			BCM2835_AUX_SPI_CNTL1_IDLE);
> 	}
> 
> -	/* and if rx_len is 0 then wake up completion and disable spi */
> +	/* and if rx_len is 0 then disable interrupts and wake up completion */
> 	if (!bs->rx_len) {
> -		bcm2835aux_spi_reset_hw(bs);
> +		bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1]);
> 		complete(&master->xfer_completion);
> 	}
> 
> @@ -313,9 +313,6 @@ static int bcm2835aux_spi_transfer_one_poll(struct spi_master *master,
> 		}
> 	}
> 
> -	/* Transfer complete - reset SPI HW */
> -	bcm2835aux_spi_reset_hw(bs);
> -
> 	/* and return without waiting for completion */
> 	return 0;
> }
> @@ -336,10 +333,6 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master,
> 	 * resulting (potentially) in more interrupts when transferring
> 	 * more than 12 bytes
> 	 */
> -	bs->cntl[0] = BCM2835_AUX_SPI_CNTL0_ENABLE |
> -		      BCM2835_AUX_SPI_CNTL0_VAR_WIDTH |
> -		      BCM2835_AUX_SPI_CNTL0_MSBF_OUT;
> -	bs->cntl[1] = BCM2835_AUX_SPI_CNTL1_MSBF_IN;
> 
> 	/* set clock */
> 	spi_hz = tfr->speed_hz;
> @@ -358,13 +351,6 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master,
Note that here you need to explicitly mask out the clock!
otherwise spi messages with different clock speeds will fill up the 
bitfield of the clock divider with the wrong values.

This has not happened before because the values were re-computed every time
now we defer it to prepare

@@ -348,17 +345,12 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *
        } else { /* the slowest we can go */
                speed = BCM2835_AUX_SPI_CNTL0_SPEED_MAX;
        }
+	/* mask out old speed from previous spi_transfer */
+       bs->cntl[0] &= ~BCM2835_AUX_SPI_CNTL0_SPEED;
+	/* set the new speed */
        bs->cntl[0] |= speed << BCM2835_AUX_SPI_CNTL0_SPEED_SHIFT;

> 
> 	spi_used_hz = clk_hz / (2 * (speed + 1));
> 
> -	/* handle all the modes */
> -	if (spi->mode & SPI_CPOL)
> -		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPOL;
> -	if (spi->mode & SPI_CPHA)
> -		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT |
> -			       BCM2835_AUX_SPI_CNTL0_CPHA_IN;
> -
> 	/* set transmit buffers and length */
> 	bs->tx_buf = tfr->tx_buf;
> 	bs->rx_buf = tfr->rx_buf;



> @@ -388,6 +374,40 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master,
> 	return bcm2835aux_spi_transfer_one_irq(master, spi, tfr);
> }
> 
> +
> +static int bcm2835aux_spi_unprepare_message(struct spi_master *master,
> +					    struct spi_message *msg)
> +{
> +	struct bcm2835aux_spi *bs = spi_master_get_devdata(master);
> +
> +	bcm2835aux_spi_reset_hw(bs);
> +
> +	return 0;
> +}
> +

I was wondering a long time why we would need this - but after
some experimentation it became clear: with auxspi disabled driving
the gates so they go into their default states (low) before GPIO-cs
is de-asserted.

It may be worth mentioning that fact - others might wonder as
well later later.

With the above in place:
Reviewed-by: Martin Sperl <kernel at martin.sperl.org>
Tested-by: Martin Sperl <kernel at martin.sperl.org>

Martin




From frowand.list at gmail.com  Thu Feb 11 10:10:49 2016
From: frowand.list at gmail.com (Frank Rowand)
Date: Thu, 11 Feb 2016 10:10:49 -0800
Subject: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
In-Reply-To: <56BC6ABA.5020605@arm.com>
References: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
 <56BC6ABA.5020605@arm.com>
Message-ID: <56BCCEA9.4050509@gmail.com>

On 2/11/2016 3:04 AM, Marc Zyngier wrote:
> On 09/02/16 11:04, Robin Murphy wrote:
>> The existing msi-map code is fine for shifting the entire RID space
>> upwards, but attempting finer-grained remapping reveals a bug. It turns
>> out that we are mistakenly treating the msi-base part as an offset, not
>> as a new base to remap onto, so things get squiffy when rid-base is
>> nonzero. Fix this, and at the same time add a sanity check against
>> having msi-map-mask clash with a nonzero rid-base, as that's another
>> thing one can easily get wrong.
>>
>> CC: <stable at vger.kernel.org>
>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> 
> Rob, Frank,
> 
> Are you willing to take this one through the OF tree? Or should we route
> it through the IRQ tree? It'd be good if it make it into 4.5.
> 
> Thanks,
> 
> 	M.
> 

Just to be picky, I would like the patch to be split in two for easier
bisecting, but if Rob is happy with a single patch I'm ok with that.

Rob, will you pick this up?

Acked-by: Frank Rowand <frank.rowand at sonymobile.com>

-Frank



From gerald.schaefer at de.ibm.com  Thu Feb 11 10:22:23 2016
From: gerald.schaefer at de.ibm.com (Gerald Schaefer)
Date: Thu, 11 Feb 2016 19:22:23 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also on
 PowerPC and ARM)
Message-ID: <20160211192223.4b517057@thinkpad>

Hi,

Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
review of the THP rework patches, which cannot be bisected, revealed
commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
(and also similar commits for other archs).

This commit removes the THP splitting bit and also the architecture
implementation of pmdp_splitting_flush(), which took care of the IPI for
fast_gup serialization. The commit message says

    pmdp_splitting_flush() is not needed too: on splitting PMD we will do
    pmdp_clear_flush() + set_pte_at().  pmdp_clear_flush() will do IPI as
    needed for fast_gup

The assumption that a TLB flush will also produce an IPI is wrong on s390,
and maybe also on other architectures, and I thought that this was actually
the main reason for having an arch-specific pmdp_splitting_flush().

At least PowerPC and ARM also had an individual implementation of
pmdp_splitting_flush() that used kick_all_cpus_sync() instead of a TLB
flush to send the IPI, and those were also removed. Putting the arch
maintainers and mailing lists on cc to verify.

On s390 this will break the IPI serialization against fast_gup, which
would certainly explain the random kernel crashes, please revert or fix
the pmdp_splitting_flush() removal.

Regards,
Gerald



From broonie at kernel.org  Thu Feb 11 10:36:40 2016
From: broonie at kernel.org (Mark Brown)
Date: Thu, 11 Feb 2016 18:36:40 +0000
Subject: [PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred
 probe for pm_runtime_reinit
In-Reply-To: <20160211173620.GU19432@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-4-git-send-email-tony@atomide.com>
 <20160211115128.GF13270@sirena.org.uk>
 <20160211150806.GS19432@atomide.com>
 <20160211155255.GA1953@sirena.org.uk>
 <20160211173620.GU19432@atomide.com>
Message-ID: <20160211183640.GB1953@sirena.org.uk>

On Thu, Feb 11, 2016 at 09:36:20AM -0800, Tony Lindgren wrote:
> * Mark Brown <broonie at kernel.org> [160211 07:54]:

> > This does sound like there's been a change in the interface compared to
> > what users are actually doing - is this an actual problem or is it just
> > a divergence from docs?

> It's an actual problem at least on omaps as the omap_device code
> is very picky about the hardware state.

> Depending how the PM runtime is implemented, it may be a problem
> for some other cases too.

Or people just aren't testing mainline that well (if this is broken in
v4.5 that suggests nobody noticed in -next) - do you know when this
broke?  It really seems like we may need to spin round on how this is
deployed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/f1717419/attachment.sig>

From marc.zyngier at arm.com  Thu Feb 11 10:39:42 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:42 +0000
Subject: [PATCH v4 01/23] arm/arm64: KVM: Add hook for C-based stage2 init
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-2-git-send-email-marc.zyngier@arm.com>

As we're about to move the stage2 init to C code, introduce some
C hooks that will later be populated with arch-specific implementations.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/kvm_host.h   | 4 ++++
 arch/arm/kvm/arm.c                | 1 +
 arch/arm64/include/asm/kvm_host.h | 4 ++++
 3 files changed, 9 insertions(+)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index f9f2779..f1e86f1 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -220,6 +220,10 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
 	kvm_call_hyp((void*)hyp_stack_ptr, vector_ptr, pgd_ptr);
 }
 
+static inline void __cpu_init_stage2(void)
+{
+}
+
 static inline int kvm_arch_dev_ioctl_check_extension(long ext)
 {
 	return 0;
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dda1959..6b76e01 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -985,6 +985,7 @@ static void cpu_init_hyp_mode(void *dummy)
 	vector_ptr = (unsigned long)__kvm_hyp_vector;
 
 	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
+	__cpu_init_stage2();
 
 	kvm_arm_init_debug();
 }
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 689d4c9..fe86cf9 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -332,6 +332,10 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
 		     hyp_stack_ptr, vector_ptr);
 }
 
+static inline void __cpu_init_stage2(void)
+{
+}
+
 static inline void kvm_arch_hardware_disable(void) {}
 static inline void kvm_arch_hardware_unsetup(void) {}
 static inline void kvm_arch_sync_events(struct kvm *kvm) {}
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:43 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:43 +0000
Subject: [PATCH v4 02/23] arm64: KVM: Switch to C-based stage2 init
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-3-git-send-email-marc.zyngier@arm.com>

There is no real need to leave the stage2 initialization as part
of the early HYP bootstrap, and we can easily postpone it to
the point where we can safely run C code.

This will help VHE, which doesn't need any of this bootstrap.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_asm.h  |  2 ++
 arch/arm64/include/asm/kvm_host.h |  2 ++
 arch/arm64/kvm/hyp-init.S         | 18 ----------------
 arch/arm64/kvm/hyp/Makefile       |  1 +
 arch/arm64/kvm/hyp/s2-setup.c     | 44 +++++++++++++++++++++++++++++++++++++++
 5 files changed, 49 insertions(+), 18 deletions(-)
 create mode 100644 arch/arm64/kvm/hyp/s2-setup.c

diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 52b777b..67ac580 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -48,6 +48,8 @@ extern u64 __vgic_v3_get_ich_vtr_el2(void);
 
 extern u32 __kvm_get_mdcr_el2(void);
 
+extern void __init_stage2_translation(void);
+
 #endif
 
 #endif /* __ARM_KVM_ASM_H__ */
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index fe86cf9..43688d9 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -25,6 +25,7 @@
 #include <linux/types.h>
 #include <linux/kvm_types.h>
 #include <asm/kvm.h>
+#include <asm/kvm_asm.h>
 #include <asm/kvm_mmio.h>
 
 #define __KVM_HAVE_ARCH_INTC_INITIALIZED
@@ -334,6 +335,7 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
 
 static inline void __cpu_init_stage2(void)
 {
+	kvm_call_hyp(__init_stage2_translation);
 }
 
 static inline void kvm_arch_hardware_disable(void) {}
diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
index 3e568dc..80fda7e 100644
--- a/arch/arm64/kvm/hyp-init.S
+++ b/arch/arm64/kvm/hyp-init.S
@@ -87,24 +87,6 @@ __do_hyp_init:
 #endif
 	msr	tcr_el2, x4
 
-	ldr	x4, =VTCR_EL2_FLAGS
-	/*
-	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
-	 * VTCR_EL2.
-	 */
-	mrs	x5, ID_AA64MMFR0_EL1
-	bfi	x4, x5, #16, #3
-	/*
-	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS bit in
-	 * VTCR_EL2.
-	 */
-	mrs	x5, ID_AA64MMFR1_EL1
-	ubfx	x5, x5, #5, #1
-	lsl	x5, x5, #VTCR_EL2_VS
-	orr	x4, x4, x5
-
-	msr	vtcr_el2, x4
-
 	mrs	x4, mair_el1
 	msr	mair_el2, x4
 	isb
diff --git a/arch/arm64/kvm/hyp/Makefile b/arch/arm64/kvm/hyp/Makefile
index 826032b..5326e66 100644
--- a/arch/arm64/kvm/hyp/Makefile
+++ b/arch/arm64/kvm/hyp/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_KVM_ARM_HOST) += switch.o
 obj-$(CONFIG_KVM_ARM_HOST) += fpsimd.o
 obj-$(CONFIG_KVM_ARM_HOST) += tlb.o
 obj-$(CONFIG_KVM_ARM_HOST) += hyp-entry.o
+obj-$(CONFIG_KVM_ARM_HOST) += s2-setup.o
diff --git a/arch/arm64/kvm/hyp/s2-setup.c b/arch/arm64/kvm/hyp/s2-setup.c
new file mode 100644
index 0000000..17e8cc0
--- /dev/null
+++ b/arch/arm64/kvm/hyp/s2-setup.c
@@ -0,0 +1,44 @@
+/*
+ * Copyright (C) 2016 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier at arm.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/types.h>
+#include <asm/kvm_arm.h>
+#include <asm/kvm_asm.h>
+
+#include "hyp.h"
+
+void __hyp_text __init_stage2_translation(void)
+{
+	u64 val = VTCR_EL2_FLAGS;
+	u64 tmp;
+
+	/*
+	 * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS
+	 * bits in VTCR_EL2. Amusingly, the PARange is 4 bits, while
+	 * PS is only 3. Fortunately, bit 19 is RES0 in VTCR_EL2...
+	 */
+	val |= (read_sysreg(id_aa64mmfr0_el1) & 7) << 16;
+
+	/*
+	 * Read the VMIDBits bits from ID_AA64MMFR1_EL1 and set the VS
+	 * bit in VTCR_EL2.
+	 */
+	tmp = (read_sysreg(id_aa64mmfr1_el1) >> 4) & 0xf;
+	val |= (tmp == 2) ? VTCR_EL2_VS : 0;
+
+	write_sysreg(val, vtcr_el2);
+}
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:44 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:44 +0000
Subject: [PATCH v4 03/23] arm/arm64: Add new is_kernel_in_hyp_mode predicate
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-4-git-send-email-marc.zyngier@arm.com>

With ARMv8.1 VHE extension, it will be possible to run the kernel
at EL2 (aka HYP mode). In order for the kernel to easily find out
where it is running, add a new predicate that returns whether or
not the kernel is in HYP mode.

For completeness, the 32bit code also get such a predicate (always
returning false) so that code common to both architecture (timers,
KVM) can use it transparently.

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/include/asm/virt.h   |  5 +++++
 arch/arm64/include/asm/virt.h | 10 ++++++++++
 2 files changed, 15 insertions(+)

diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
index 4371f45..b6a3cef 100644
--- a/arch/arm/include/asm/virt.h
+++ b/arch/arm/include/asm/virt.h
@@ -74,6 +74,11 @@ static inline bool is_hyp_mode_mismatched(void)
 {
 	return !!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH);
 }
+
+static inline bool is_kernel_in_hyp_mode(void)
+{
+	return false;
+}
 #endif
 
 #endif /* __ASSEMBLY__ */
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 7a5df52..9f22dd6 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -23,6 +23,8 @@
 
 #ifndef __ASSEMBLY__
 
+#include <asm/ptrace.h>
+
 /*
  * __boot_cpu_mode records what mode CPUs were booted in.
  * A correctly-implemented bootloader must start all CPUs in the same mode:
@@ -50,6 +52,14 @@ static inline bool is_hyp_mode_mismatched(void)
 	return __boot_cpu_mode[0] != __boot_cpu_mode[1];
 }
 
+static inline bool is_kernel_in_hyp_mode(void)
+{
+	u64 el;
+
+	asm("mrs %0, CurrentEL" : "=r" (el));
+	return el == CurrentEL_EL2;
+}
+
 /* The section containing the hypervisor text */
 extern char __hyp_text_start[];
 extern char __hyp_text_end[];
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:45 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:45 +0000
Subject: [PATCH v4 04/23] arm64: Allow the arch timer to use the HYP timer
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-5-git-send-email-marc.zyngier@arm.com>

With the ARMv8.1 VHE, the kernel can run in HYP mode, and thus
use the HYP timer instead of the normal guest timer in a mostly
transparent way, except for the interrupt line.

This patch reworks the arch timer code to allow the selection of
the HYP PPI, possibly falling back to the guest timer if not
available.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 drivers/clocksource/arm_arch_timer.c | 96 ++++++++++++++++++++++--------------
 1 file changed, 59 insertions(+), 37 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index c64d543..ffe9d1c 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -67,7 +67,7 @@ static int arch_timer_ppi[MAX_TIMER_PPI];
 
 static struct clock_event_device __percpu *arch_timer_evt;
 
-static bool arch_timer_use_virtual = true;
+static enum ppi_nr arch_timer_uses_ppi = VIRT_PPI;
 static bool arch_timer_c3stop;
 static bool arch_timer_mem_use_virtual;
 
@@ -263,14 +263,20 @@ static void __arch_timer_setup(unsigned type,
 		clk->name = "arch_sys_timer";
 		clk->rating = 450;
 		clk->cpumask = cpumask_of(smp_processor_id());
-		if (arch_timer_use_virtual) {
-			clk->irq = arch_timer_ppi[VIRT_PPI];
+		clk->irq = arch_timer_ppi[arch_timer_uses_ppi];
+		switch (arch_timer_uses_ppi) {
+		case VIRT_PPI:
 			clk->set_state_shutdown = arch_timer_shutdown_virt;
 			clk->set_next_event = arch_timer_set_next_event_virt;
-		} else {
-			clk->irq = arch_timer_ppi[PHYS_SECURE_PPI];
+			break;
+		case PHYS_SECURE_PPI:
+		case PHYS_NONSECURE_PPI:
+		case HYP_PPI:
 			clk->set_state_shutdown = arch_timer_shutdown_phys;
 			clk->set_next_event = arch_timer_set_next_event_phys;
+			break;
+		default:
+			BUG();
 		}
 	} else {
 		clk->features |= CLOCK_EVT_FEAT_DYNIRQ;
@@ -338,17 +344,20 @@ static void arch_counter_set_user_access(void)
 	arch_timer_set_cntkctl(cntkctl);
 }
 
+static bool arch_timer_has_nonsecure_ppi(void)
+{
+	return (arch_timer_uses_ppi == PHYS_SECURE_PPI &&
+		arch_timer_ppi[PHYS_NONSECURE_PPI]);
+}
+
 static int arch_timer_setup(struct clock_event_device *clk)
 {
 	__arch_timer_setup(ARCH_CP15_TIMER, clk);
 
-	if (arch_timer_use_virtual)
-		enable_percpu_irq(arch_timer_ppi[VIRT_PPI], 0);
-	else {
-		enable_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI], 0);
-		if (arch_timer_ppi[PHYS_NONSECURE_PPI])
-			enable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI], 0);
-	}
+	enable_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi], 0);
+
+	if (arch_timer_has_nonsecure_ppi())
+		enable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI], 0);
 
 	arch_counter_set_user_access();
 	if (IS_ENABLED(CONFIG_ARM_ARCH_TIMER_EVTSTREAM))
@@ -390,7 +399,7 @@ static void arch_timer_banner(unsigned type)
 		     (unsigned long)arch_timer_rate / 1000000,
 		     (unsigned long)(arch_timer_rate / 10000) % 100,
 		     type & ARCH_CP15_TIMER ?
-			arch_timer_use_virtual ? "virt" : "phys" :
+		     (arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :
 			"",
 		     type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ?  "/" : "",
 		     type & ARCH_MEM_TIMER ?
@@ -460,7 +469,7 @@ static void __init arch_counter_register(unsigned type)
 
 	/* Register the CP15 based counter if we have one */
 	if (type & ARCH_CP15_TIMER) {
-		if (IS_ENABLED(CONFIG_ARM64) || arch_timer_use_virtual)
+		if (IS_ENABLED(CONFIG_ARM64) || arch_timer_uses_ppi == VIRT_PPI)
 			arch_timer_read_counter = arch_counter_get_cntvct;
 		else
 			arch_timer_read_counter = arch_counter_get_cntpct;
@@ -490,13 +499,9 @@ static void arch_timer_stop(struct clock_event_device *clk)
 	pr_debug("arch_timer_teardown disable IRQ%d cpu #%d\n",
 		 clk->irq, smp_processor_id());
 
-	if (arch_timer_use_virtual)
-		disable_percpu_irq(arch_timer_ppi[VIRT_PPI]);
-	else {
-		disable_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI]);
-		if (arch_timer_ppi[PHYS_NONSECURE_PPI])
-			disable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI]);
-	}
+	disable_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi]);
+	if (arch_timer_has_nonsecure_ppi())
+		disable_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI]);
 
 	clk->set_state_shutdown(clk);
 }
@@ -562,12 +567,14 @@ static int __init arch_timer_register(void)
 		goto out;
 	}
 
-	if (arch_timer_use_virtual) {
-		ppi = arch_timer_ppi[VIRT_PPI];
+	ppi = arch_timer_ppi[arch_timer_uses_ppi];
+	switch (arch_timer_uses_ppi) {
+	case VIRT_PPI:
 		err = request_percpu_irq(ppi, arch_timer_handler_virt,
 					 "arch_timer", arch_timer_evt);
-	} else {
-		ppi = arch_timer_ppi[PHYS_SECURE_PPI];
+		break;
+	case PHYS_SECURE_PPI:
+	case PHYS_NONSECURE_PPI:
 		err = request_percpu_irq(ppi, arch_timer_handler_phys,
 					 "arch_timer", arch_timer_evt);
 		if (!err && arch_timer_ppi[PHYS_NONSECURE_PPI]) {
@@ -578,6 +585,13 @@ static int __init arch_timer_register(void)
 				free_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI],
 						arch_timer_evt);
 		}
+		break;
+	case HYP_PPI:
+		err = request_percpu_irq(ppi, arch_timer_handler_phys,
+					 "arch_timer", arch_timer_evt);
+		break;
+	default:
+		BUG();
 	}
 
 	if (err) {
@@ -602,15 +616,10 @@ static int __init arch_timer_register(void)
 out_unreg_notify:
 	unregister_cpu_notifier(&arch_timer_cpu_nb);
 out_free_irq:
-	if (arch_timer_use_virtual)
-		free_percpu_irq(arch_timer_ppi[VIRT_PPI], arch_timer_evt);
-	else {
-		free_percpu_irq(arch_timer_ppi[PHYS_SECURE_PPI],
+	free_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi], arch_timer_evt);
+	if (arch_timer_has_nonsecure_ppi())
+		free_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI],
 				arch_timer_evt);
-		if (arch_timer_ppi[PHYS_NONSECURE_PPI])
-			free_percpu_irq(arch_timer_ppi[PHYS_NONSECURE_PPI],
-					arch_timer_evt);
-	}
 
 out_free:
 	free_percpu(arch_timer_evt);
@@ -697,12 +706,25 @@ static void __init arch_timer_init(void)
 	 *
 	 * If no interrupt provided for virtual timer, we'll have to
 	 * stick to the physical timer. It'd better be accessible...
+	 *
+	 * On ARMv8.1 with VH extensions, the kernel runs in HYP. VHE
+	 * accesses to CNTP_*_EL1 registers are silently redirected to
+	 * their CNTHP_*_EL2 counterparts, and use a different PPI
+	 * number.
 	 */
 	if (is_hyp_mode_available() || !arch_timer_ppi[VIRT_PPI]) {
-		arch_timer_use_virtual = false;
+		bool has_ppi;
+
+		if (is_kernel_in_hyp_mode()) {
+			arch_timer_uses_ppi = HYP_PPI;
+			has_ppi = !!arch_timer_ppi[HYP_PPI];
+		} else {
+			arch_timer_uses_ppi = PHYS_SECURE_PPI;
+			has_ppi = (!!arch_timer_ppi[PHYS_SECURE_PPI] ||
+				   !!arch_timer_ppi[PHYS_NONSECURE_PPI]);
+		}
 
-		if (!arch_timer_ppi[PHYS_SECURE_PPI] ||
-		    !arch_timer_ppi[PHYS_NONSECURE_PPI]) {
+		if (!has_ppi) {
 			pr_warn("arch_timer: No interrupt available, giving up\n");
 			return;
 		}
@@ -735,7 +757,7 @@ static void __init arch_timer_of_init(struct device_node *np)
 	 */
 	if (IS_ENABLED(CONFIG_ARM) &&
 	    of_property_read_bool(np, "arm,cpu-registers-not-fw-configured"))
-			arch_timer_use_virtual = false;
+		arch_timer_uses_ppi = PHYS_SECURE_PPI;
 
 	arch_timer_init();
 }
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:50 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:50 +0000
Subject: [PATCH v4 09/23] arm64: KVM: VHE: Introduce unified system register
 accessors
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-10-git-send-email-marc.zyngier@arm.com>

VHE brings its own bag of new system registers, or rather system
register accessors, as it define new ways to access both guest
and host system registers. For example, from the host:

- The host TCR_EL2 register is accessed using the TCR_EL1 accessor
- The guest TCR_EL1 register is accessed using the TCR_EL12 accessor

Obviously, this is confusing. A way to somehow reduce the complexity
of writing code for both ARMv8 and ARMv8.1 is to use a set of unified
accessors that will generate the right sysreg, depending on the mode
the CPU is running in. For example:

- read_sysreg_el1(tcr) will use TCR_EL1 on ARMv8, and TCR_EL12 on
  ARMv8.1 with VHE.
- read_sysreg_el2(tcr) will use TCR_EL2 on ARMv8, and TCR_EL1 on
  ARMv8.1 with VHE.

We end up with three sets of accessors ({read,write}_sysreg_el[012])
that can be directly used from C code. We take this opportunity to
also add the definition for the new VHE sysregs.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/hyp.h | 72 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
index fc502f3..744c919 100644
--- a/arch/arm64/kvm/hyp/hyp.h
+++ b/arch/arm64/kvm/hyp/hyp.h
@@ -48,6 +48,78 @@ static inline unsigned long __hyp_kern_va(unsigned long v)
 
 #define hyp_kern_va(v) (typeof(v))(__hyp_kern_va((unsigned long)(v)))
 
+#define read_sysreg_elx(r,nvh,vh)					\
+	({								\
+		u64 reg;						\
+		asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##nvh),\
+					 "mrs_s %0, " __stringify(r##vh),\
+					 ARM64_HAS_VIRT_HOST_EXTN)	\
+			     : "=r" (reg));				\
+		reg;							\
+	})
+
+#define write_sysreg_elx(v,r,nvh,vh)					\
+	do {								\
+		u64 __val = (u64)(v);					\
+		asm volatile(ALTERNATIVE("msr " __stringify(r##nvh) ", %x0",\
+					 "msr_s " __stringify(r##vh) ", %x0",\
+					 ARM64_HAS_VIRT_HOST_EXTN)	\
+					 : : "rZ" (__val));		\
+	} while (0)
+
+/*
+ * Unified accessors for registers that have a different encoding
+ * between VHE and non-VHE. They must be specified without their "ELx"
+ * encoding.
+ */
+#define read_sysreg_el2(r)						\
+	({								\
+		u64 reg;						\
+		asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##_EL2),\
+					 "mrs %0, " __stringify(r##_EL1),\
+					 ARM64_HAS_VIRT_HOST_EXTN)	\
+			     : "=r" (reg));				\
+		reg;							\
+	})
+
+#define write_sysreg_el2(v,r)						\
+	do {								\
+		u64 __val = (u64)(v);					\
+		asm volatile(ALTERNATIVE("msr " __stringify(r##_EL2) ", %x0",\
+					 "msr " __stringify(r##_EL1) ", %x0",\
+					 ARM64_HAS_VIRT_HOST_EXTN)	\
+					 : : "rZ" (__val));		\
+	} while (0)
+
+#define read_sysreg_el0(r)	read_sysreg_elx(r, _EL0, _EL02)
+#define write_sysreg_el0(v,r)	write_sysreg_elx(v, r, _EL0, _EL02)
+#define read_sysreg_el1(r)	read_sysreg_elx(r, _EL1, _EL12)
+#define write_sysreg_el1(v,r)	write_sysreg_elx(v, r, _EL1, _EL12)
+
+/* The VHE specific system registers and their encoding */
+#define sctlr_EL12              sys_reg(3, 5, 1, 0, 0)
+#define cpacr_EL12              sys_reg(3, 5, 1, 0, 2)
+#define ttbr0_EL12              sys_reg(3, 5, 2, 0, 0)
+#define ttbr1_EL12              sys_reg(3, 5, 2, 0, 1)
+#define tcr_EL12                sys_reg(3, 5, 2, 0, 2)
+#define afsr0_EL12              sys_reg(3, 5, 5, 1, 0)
+#define afsr1_EL12              sys_reg(3, 5, 5, 1, 1)
+#define esr_EL12                sys_reg(3, 5, 5, 2, 0)
+#define far_EL12                sys_reg(3, 5, 6, 0, 0)
+#define mair_EL12               sys_reg(3, 5, 10, 2, 0)
+#define amair_EL12              sys_reg(3, 5, 10, 3, 0)
+#define vbar_EL12               sys_reg(3, 5, 12, 0, 0)
+#define contextidr_EL12         sys_reg(3, 5, 13, 0, 1)
+#define cntkctl_EL12            sys_reg(3, 5, 14, 1, 0)
+#define cntp_tval_EL02          sys_reg(3, 5, 14, 2, 0)
+#define cntp_ctl_EL02           sys_reg(3, 5, 14, 2, 1)
+#define cntp_cval_EL02          sys_reg(3, 5, 14, 2, 2)
+#define cntv_tval_EL02          sys_reg(3, 5, 14, 3, 0)
+#define cntv_ctl_EL02           sys_reg(3, 5, 14, 3, 1)
+#define cntv_cval_EL02          sys_reg(3, 5, 14, 3, 2)
+#define spsr_EL12               sys_reg(3, 5, 4, 0, 0)
+#define elr_EL12                sys_reg(3, 5, 4, 0, 1)
+
 /**
  * hyp_alternate_select - Generates patchable code sequences that are
  * used to switch between two implementations of a function, depending
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:47 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:47 +0000
Subject: [PATCH v4 06/23] arm64: KVM: Skip HYP setup when already running in
 HYP
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-7-git-send-email-marc.zyngier@arm.com>

With the kernel running at EL2, there is no point trying to
configure page tables for HYP, as the kernel is already mapped.

Take this opportunity to refactor the whole init a bit, allowing
the various parts of the hypervisor bringup to be split across
multiple functions.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/arm.c | 173 +++++++++++++++++++++++++++++++++++------------------
 arch/arm/kvm/mmu.c |   7 +++
 2 files changed, 121 insertions(+), 59 deletions(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 6b76e01..58f89e3 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -967,6 +967,11 @@ long kvm_arch_vm_ioctl(struct file *filp,
 	}
 }
 
+static void cpu_init_stage2(void *dummy)
+{
+	__cpu_init_stage2();
+}
+
 static void cpu_init_hyp_mode(void *dummy)
 {
 	phys_addr_t boot_pgd_ptr;
@@ -1036,6 +1041,82 @@ static inline void hyp_cpu_pm_init(void)
 }
 #endif
 
+static void teardown_common_resources(void)
+{
+	free_percpu(kvm_host_cpu_state);
+}
+
+static int init_common_resources(void)
+{
+	kvm_host_cpu_state = alloc_percpu(kvm_cpu_context_t);
+	if (!kvm_host_cpu_state) {
+		kvm_err("Cannot allocate host CPU state\n");
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+static int init_subsystems(void)
+{
+	int err;
+
+	/*
+	 * Init HYP view of VGIC
+	 */
+	err = kvm_vgic_hyp_init();
+	switch (err) {
+	case 0:
+		vgic_present = true;
+		break;
+	case -ENODEV:
+	case -ENXIO:
+		vgic_present = false;
+		break;
+	default:
+		return err;
+	}
+
+	/*
+	 * Init HYP architected timer support
+	 */
+	err = kvm_timer_hyp_init();
+	if (err)
+		return err;
+
+	kvm_perf_init();
+	kvm_coproc_table_init();
+
+	return 0;
+}
+
+static void teardown_hyp_mode(void)
+{
+	int cpu;
+
+	if (is_kernel_in_hyp_mode())
+		return;
+
+	free_hyp_pgds();
+	for_each_possible_cpu(cpu)
+		free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
+}
+
+static int init_vhe_mode(void)
+{
+	/*
+	 * Execute the init code on each CPU.
+	 */
+	on_each_cpu(cpu_init_stage2, NULL, 1);
+
+	/* set size of VMID supported by CPU */
+	kvm_vmid_bits = kvm_get_vmid_bits();
+	kvm_info("%d-bit VMID\n", kvm_vmid_bits);
+
+	kvm_info("VHE mode initialized successfully\n");
+	return 0;
+}
+
 /**
  * Inits Hyp-mode on all online CPUs
  */
@@ -1066,7 +1147,7 @@ static int init_hyp_mode(void)
 		stack_page = __get_free_page(GFP_KERNEL);
 		if (!stack_page) {
 			err = -ENOMEM;
-			goto out_free_stack_pages;
+			goto out_err;
 		}
 
 		per_cpu(kvm_arm_hyp_stack_page, cpu) = stack_page;
@@ -1078,13 +1159,13 @@ static int init_hyp_mode(void)
 	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
 	if (err) {
 		kvm_err("Cannot map world-switch code\n");
-		goto out_free_mappings;
+		goto out_err;
 	}
 
 	err = create_hyp_mappings(__start_rodata, __end_rodata);
 	if (err) {
 		kvm_err("Cannot map rodata section\n");
-		goto out_free_mappings;
+		goto out_err;
 	}
 
 	/*
@@ -1096,20 +1177,10 @@ static int init_hyp_mode(void)
 
 		if (err) {
 			kvm_err("Cannot map hyp stack\n");
-			goto out_free_mappings;
+			goto out_err;
 		}
 	}
 
-	/*
-	 * Map the host CPU structures
-	 */
-	kvm_host_cpu_state = alloc_percpu(kvm_cpu_context_t);
-	if (!kvm_host_cpu_state) {
-		err = -ENOMEM;
-		kvm_err("Cannot allocate host CPU state\n");
-		goto out_free_mappings;
-	}
-
 	for_each_possible_cpu(cpu) {
 		kvm_cpu_context_t *cpu_ctxt;
 
@@ -1118,7 +1189,7 @@ static int init_hyp_mode(void)
 
 		if (err) {
 			kvm_err("Cannot map host CPU state: %d\n", err);
-			goto out_free_context;
+			goto out_err;
 		}
 	}
 
@@ -1127,34 +1198,22 @@ static int init_hyp_mode(void)
 	 */
 	on_each_cpu(cpu_init_hyp_mode, NULL, 1);
 
-	/*
-	 * Init HYP view of VGIC
-	 */
-	err = kvm_vgic_hyp_init();
-	switch (err) {
-	case 0:
-		vgic_present = true;
-		break;
-	case -ENODEV:
-	case -ENXIO:
-		vgic_present = false;
-		break;
-	default:
-		goto out_free_context;
-	}
-
-	/*
-	 * Init HYP architected timer support
-	 */
-	err = kvm_timer_hyp_init();
-	if (err)
-		goto out_free_context;
-
 #ifndef CONFIG_HOTPLUG_CPU
 	free_boot_hyp_pgd();
 #endif
 
-	kvm_perf_init();
+	cpu_notifier_register_begin();
+
+	err = __register_cpu_notifier(&hyp_init_cpu_nb);
+
+	cpu_notifier_register_done();
+
+	if (err) {
+		kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
+		goto out_err;
+	}
+
+	hyp_cpu_pm_init();
 
 	/* set size of VMID supported by CPU */
 	kvm_vmid_bits = kvm_get_vmid_bits();
@@ -1163,14 +1222,9 @@ static int init_hyp_mode(void)
 	kvm_info("Hyp mode initialized successfully\n");
 
 	return 0;
-out_free_context:
-	free_percpu(kvm_host_cpu_state);
-out_free_mappings:
-	free_hyp_pgds();
-out_free_stack_pages:
-	for_each_possible_cpu(cpu)
-		free_page(per_cpu(kvm_arm_hyp_stack_page, cpu));
+
 out_err:
+	teardown_hyp_mode();
 	kvm_err("error initializing Hyp mode: %d\n", err);
 	return err;
 }
@@ -1214,26 +1268,27 @@ int kvm_arch_init(void *opaque)
 		}
 	}
 
-	cpu_notifier_register_begin();
-
-	err = init_hyp_mode();
+	err = init_common_resources();
 	if (err)
-		goto out_err;
+		return err;
 
-	err = __register_cpu_notifier(&hyp_init_cpu_nb);
-	if (err) {
-		kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
+	if (is_kernel_in_hyp_mode())
+		err = init_vhe_mode();
+	else
+		err = init_hyp_mode();
+	if (err)
 		goto out_err;
-	}
-
-	cpu_notifier_register_done();
 
-	hyp_cpu_pm_init();
+	err = init_subsystems();
+	if (err)
+		goto out_hyp;
 
-	kvm_coproc_table_init();
 	return 0;
+
+out_hyp:
+	teardown_hyp_mode();
 out_err:
-	cpu_notifier_register_done();
+	teardown_common_resources();
 	return err;
 }
 
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index aba61fd..920d0c3 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -28,6 +28,7 @@
 #include <asm/kvm_mmio.h>
 #include <asm/kvm_asm.h>
 #include <asm/kvm_emulate.h>
+#include <asm/virt.h>
 
 #include "trace.h"
 
@@ -598,6 +599,9 @@ int create_hyp_mappings(void *from, void *to)
 	unsigned long start = KERN_TO_HYP((unsigned long)from);
 	unsigned long end = KERN_TO_HYP((unsigned long)to);
 
+	if (is_kernel_in_hyp_mode())
+		return 0;
+
 	start = start & PAGE_MASK;
 	end = PAGE_ALIGN(end);
 
@@ -630,6 +634,9 @@ int create_hyp_io_mappings(void *from, void *to, phys_addr_t phys_addr)
 	unsigned long start = KERN_TO_HYP((unsigned long)from);
 	unsigned long end = KERN_TO_HYP((unsigned long)to);
 
+	if (is_kernel_in_hyp_mode())
+		return 0;
+
 	/* Check for a valid kernel IO mapping */
 	if (!is_vmalloc_addr(from) || !is_vmalloc_addr(to - 1))
 		return -EINVAL;
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:58 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:58 +0000
Subject: [PATCH v4 17/23] arm64: KVM: VHE: Add fpsimd enabling on guest access
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-18-git-send-email-marc.zyngier@arm.com>

Despite the fact that a VHE enabled kernel runs at EL2, it uses
CPACR_EL1 to trap FPSIMD access. Add the required alternative
code to re-enable guest FPSIMD access when it has trapped to
EL2.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/entry.S | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
index fd0fbe9..ce9e5e5 100644
--- a/arch/arm64/kvm/hyp/entry.S
+++ b/arch/arm64/kvm/hyp/entry.S
@@ -130,9 +130,15 @@ ENDPROC(__guest_exit)
 ENTRY(__fpsimd_guest_restore)
 	stp	x4, lr, [sp, #-16]!
 
+alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
 	mrs	x2, cptr_el2
 	bic	x2, x2, #CPTR_EL2_TFP
 	msr	cptr_el2, x2
+alternative_else
+	mrs	x2, cpacr_el1
+	orr	x2, x2, #CPACR_EL1_FPEN
+	msr	cpacr_el1, x2
+alternative_endif
 	isb
 
 	mrs	x3, tpidr_el2
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:52 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:52 +0000
Subject: [PATCH v4 11/23] arm64: KVM: VHE: Split save/restore of registers
 shared between guest and host
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-12-git-send-email-marc.zyngier@arm.com>

A handful of system registers are still shared between host and guest,
even while using VHE (tpidr*_el[01] and actlr_el1).

Also, some of the vcpu state (sp_el0, PC and PSTATE) must be
save/restored on entry/exit, as they are used on the host as well.

In order to facilitate the introduction of a VHE-specific sysreg
save/restore, make move the access to these registers to their
own save/restore functions.

No functional change.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/sysreg-sr.c | 48 +++++++++++++++++++++++++++++-------------
 1 file changed, 33 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
index bd5b543..61bad17 100644
--- a/arch/arm64/kvm/hyp/sysreg-sr.c
+++ b/arch/arm64/kvm/hyp/sysreg-sr.c
@@ -23,13 +23,29 @@
 
 #include "hyp.h"
 
-/* ctxt is already in the HYP VA space */
+/*
+ * Non-VHE: Both host and guest must save everything.
+ *
+ * VHE: Host must save tpidr*_el[01], actlr_el1, sp0, pc, pstate, and
+ * guest must save everything.
+ */
+
+static void __hyp_text __sysreg_save_common_state(struct kvm_cpu_context *ctxt)
+{
+	ctxt->sys_regs[ACTLR_EL1]	= read_sysreg(actlr_el1);
+	ctxt->sys_regs[TPIDR_EL0]	= read_sysreg(tpidr_el0);
+	ctxt->sys_regs[TPIDRRO_EL0]	= read_sysreg(tpidrro_el0);
+	ctxt->sys_regs[TPIDR_EL1]	= read_sysreg(tpidr_el1);
+	ctxt->gp_regs.regs.sp		= read_sysreg(sp_el0);
+	ctxt->gp_regs.regs.pc		= read_sysreg(elr_el2);
+	ctxt->gp_regs.regs.pstate	= read_sysreg(spsr_el2);
+}
+
 static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
 {
 	ctxt->sys_regs[MPIDR_EL1]	= read_sysreg(vmpidr_el2);
 	ctxt->sys_regs[CSSELR_EL1]	= read_sysreg(csselr_el1);
 	ctxt->sys_regs[SCTLR_EL1]	= read_sysreg(sctlr_el1);
-	ctxt->sys_regs[ACTLR_EL1]	= read_sysreg(actlr_el1);
 	ctxt->sys_regs[CPACR_EL1]	= read_sysreg(cpacr_el1);
 	ctxt->sys_regs[TTBR0_EL1]	= read_sysreg(ttbr0_el1);
 	ctxt->sys_regs[TTBR1_EL1]	= read_sysreg(ttbr1_el1);
@@ -41,17 +57,11 @@ static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
 	ctxt->sys_regs[MAIR_EL1]	= read_sysreg(mair_el1);
 	ctxt->sys_regs[VBAR_EL1]	= read_sysreg(vbar_el1);
 	ctxt->sys_regs[CONTEXTIDR_EL1]	= read_sysreg(contextidr_el1);
-	ctxt->sys_regs[TPIDR_EL0]	= read_sysreg(tpidr_el0);
-	ctxt->sys_regs[TPIDRRO_EL0]	= read_sysreg(tpidrro_el0);
-	ctxt->sys_regs[TPIDR_EL1]	= read_sysreg(tpidr_el1);
 	ctxt->sys_regs[AMAIR_EL1]	= read_sysreg(amair_el1);
 	ctxt->sys_regs[CNTKCTL_EL1]	= read_sysreg(cntkctl_el1);
 	ctxt->sys_regs[PAR_EL1]		= read_sysreg(par_el1);
 	ctxt->sys_regs[MDSCR_EL1]	= read_sysreg(mdscr_el1);
 
-	ctxt->gp_regs.regs.sp		= read_sysreg(sp_el0);
-	ctxt->gp_regs.regs.pc		= read_sysreg(elr_el2);
-	ctxt->gp_regs.regs.pstate	= read_sysreg(spsr_el2);
 	ctxt->gp_regs.sp_el1		= read_sysreg(sp_el1);
 	ctxt->gp_regs.elr_el1		= read_sysreg(elr_el1);
 	ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg(spsr_el1);
@@ -60,11 +70,24 @@ static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
 void __hyp_text __sysreg_save_host_state(struct kvm_cpu_context *ctxt)
 {
 	__sysreg_save_state(ctxt);
+	__sysreg_save_common_state(ctxt);
 }
 
 void __hyp_text __sysreg_save_guest_state(struct kvm_cpu_context *ctxt)
 {
 	__sysreg_save_state(ctxt);
+	__sysreg_save_common_state(ctxt);
+}
+
+static void __hyp_text __sysreg_restore_common_state(struct kvm_cpu_context *ctxt)
+{
+	write_sysreg(ctxt->sys_regs[ACTLR_EL1],	  actlr_el1);
+	write_sysreg(ctxt->sys_regs[TPIDR_EL0],	  tpidr_el0);
+	write_sysreg(ctxt->sys_regs[TPIDRRO_EL0], tpidrro_el0);
+	write_sysreg(ctxt->sys_regs[TPIDR_EL1],	  tpidr_el1);
+	write_sysreg(ctxt->gp_regs.regs.sp,	  sp_el0);
+	write_sysreg(ctxt->gp_regs.regs.pc,	  elr_el2);
+	write_sysreg(ctxt->gp_regs.regs.pstate,	  spsr_el2);
 }
 
 static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
@@ -72,7 +95,6 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
 	write_sysreg(ctxt->sys_regs[MPIDR_EL1],	  vmpidr_el2);
 	write_sysreg(ctxt->sys_regs[CSSELR_EL1],  csselr_el1);
 	write_sysreg(ctxt->sys_regs[SCTLR_EL1],	  sctlr_el1);
-	write_sysreg(ctxt->sys_regs[ACTLR_EL1],	  actlr_el1);
 	write_sysreg(ctxt->sys_regs[CPACR_EL1],	  cpacr_el1);
 	write_sysreg(ctxt->sys_regs[TTBR0_EL1],	  ttbr0_el1);
 	write_sysreg(ctxt->sys_regs[TTBR1_EL1],	  ttbr1_el1);
@@ -84,17 +106,11 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
 	write_sysreg(ctxt->sys_regs[MAIR_EL1],	  mair_el1);
 	write_sysreg(ctxt->sys_regs[VBAR_EL1],	  vbar_el1);
 	write_sysreg(ctxt->sys_regs[CONTEXTIDR_EL1], contextidr_el1);
-	write_sysreg(ctxt->sys_regs[TPIDR_EL0],	  tpidr_el0);
-	write_sysreg(ctxt->sys_regs[TPIDRRO_EL0], tpidrro_el0);
-	write_sysreg(ctxt->sys_regs[TPIDR_EL1],	  tpidr_el1);
 	write_sysreg(ctxt->sys_regs[AMAIR_EL1],	  amair_el1);
 	write_sysreg(ctxt->sys_regs[CNTKCTL_EL1], cntkctl_el1);
 	write_sysreg(ctxt->sys_regs[PAR_EL1],	  par_el1);
 	write_sysreg(ctxt->sys_regs[MDSCR_EL1],	  mdscr_el1);
 
-	write_sysreg(ctxt->gp_regs.regs.sp,	sp_el0);
-	write_sysreg(ctxt->gp_regs.regs.pc,	elr_el2);
-	write_sysreg(ctxt->gp_regs.regs.pstate,	spsr_el2);
 	write_sysreg(ctxt->gp_regs.sp_el1,	sp_el1);
 	write_sysreg(ctxt->gp_regs.elr_el1,	elr_el1);
 	write_sysreg(ctxt->gp_regs.spsr[KVM_SPSR_EL1], spsr_el1);
@@ -103,11 +119,13 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
 void __hyp_text __sysreg_restore_host_state(struct kvm_cpu_context *ctxt)
 {
 	__sysreg_restore_state(ctxt);
+	__sysreg_restore_common_state(ctxt);
 }
 
 void __hyp_text __sysreg_restore_guest_state(struct kvm_cpu_context *ctxt)
 {
 	__sysreg_restore_state(ctxt);
+	__sysreg_restore_common_state(ctxt);
 }
 
 void __hyp_text __sysreg32_save_state(struct kvm_vcpu *vcpu)
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:46 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:46 +0000
Subject: [PATCH v4 05/23] arm64: Add ARM64_HAS_VIRT_HOST_EXTN feature
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-6-git-send-email-marc.zyngier@arm.com>

Add a new ARM64_HAS_VIRT_HOST_EXTN features to indicate that the
CPU has the ARMv8.1 VHE capability.

This will be used to trigger kernel patching in KVM.

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/cpufeature.h |  3 ++-
 arch/arm64/kernel/cpufeature.c      | 11 +++++++++++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 8f271b8..c705d6a 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -30,8 +30,9 @@
 #define ARM64_HAS_LSE_ATOMICS			5
 #define ARM64_WORKAROUND_CAVIUM_23154		6
 #define ARM64_WORKAROUND_834220			7
+#define ARM64_HAS_VIRT_HOST_EXTN		8
 
-#define ARM64_NCAPS				8
+#define ARM64_NCAPS				9
 
 #ifndef __ASSEMBLY__
 
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 5c90aa4..ba74519 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -26,6 +26,7 @@
 #include <asm/cpu_ops.h>
 #include <asm/processor.h>
 #include <asm/sysreg.h>
+#include <asm/virt.h>
 
 unsigned long elf_hwcap __read_mostly;
 EXPORT_SYMBOL_GPL(elf_hwcap);
@@ -621,6 +622,11 @@ static bool has_useable_gicv3_cpuif(const struct arm64_cpu_capabilities *entry)
 	return has_sre;
 }
 
+static bool runs_at_el2(const struct arm64_cpu_capabilities *entry)
+{
+	return is_kernel_in_hyp_mode();
+}
+
 static const struct arm64_cpu_capabilities arm64_features[] = {
 	{
 		.desc = "GIC system register CPU interface",
@@ -651,6 +657,11 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.min_field_value = 2,
 	},
 #endif /* CONFIG_AS_LSE && CONFIG_ARM64_LSE_ATOMICS */
+	{
+		.desc = "Virtualization Host Extensions",
+		.capability = ARM64_HAS_VIRT_HOST_EXTN,
+		.matches = runs_at_el2,
+	},
 	{},
 };
 
-- 
2.1.4



From tn at semihalf.com  Thu Feb 11 10:39:12 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu, 11 Feb 2016 19:39:12 +0100
Subject: [PATCH V4 22/23] arm64, pci, acpi: Assign legacy IRQs once device
 is enable.
In-Reply-To: <20160211171700.GB25235@red-moon>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
 <1454606941-9523-23-git-send-email-tn@semihalf.com>
 <20160211115843.GA24136@red-moon> <20160211171700.GB25235@red-moon>
Message-ID: <56BCD550.2050601@semihalf.com>

On 11.02.2016 18:17, Lorenzo Pieralisi wrote:
> Here (on top of your series), ready for flak.
>
> Lorenzo
>
> -- >8 --
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 0b53262..26ee291 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -45,28 +45,23 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
>    */
>   int pcibios_enable_device(struct pci_dev *dev, int mask)
>   {
> -	int ret;
> -
>   	if (pci_has_flag(PCI_PROBE_ONLY))
>   		return 0;
>
> -	ret = pci_enable_resources(dev, mask);
> -	if (ret < 0)
> -		return ret;
> -
> -#ifdef CONFIG_ACPI
> -	if (!pci_dev_msi_enabled(dev))
> -		return acpi_pci_irq_enable(dev);
> -#endif
> -	return 0;
> +	return pci_enable_resources(dev, mask);
>   }
>
>   /*
> - * Try to assign the IRQ number from DT when adding a new device
> + * Try to assign the IRQ number when probing a new device
>    */
> -int pcibios_add_device(struct pci_dev *dev)
> +int pcibios_alloc_irq(struct pci_dev *dev)
>   {
> -	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> +	if (acpi_disabled)
> +		dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> +#ifdef CONFIG_ACPI
> +	else
> +		return acpi_pci_irq_enable(dev);
> +#endif
>
>   	return 0;
>   }

I miss that way of solving the problem. OK lets try this way. I will 
integrate it.

Tomasz


From marc.zyngier at arm.com  Thu Feb 11 10:39:51 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:51 +0000
Subject: [PATCH v4 10/23] arm64: KVM: VHE: Differenciate host/guest sysreg
 save/restore
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-11-git-send-email-marc.zyngier@arm.com>

With ARMv8, host and guest share the same system register file,
making the save/restore procedure completely symetrical.
With VHE, host and guest now have different requirements, as they
use different sysregs.

In order to prepare for this, add split sysreg save/restore functions
for both host and guest. No functional changes yet.

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/hyp.h       |  6 ++++--
 arch/arm64/kvm/hyp/switch.c    | 10 +++++-----
 arch/arm64/kvm/hyp/sysreg-sr.c | 24 ++++++++++++++++++++++--
 3 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
index 744c919..5dfa883 100644
--- a/arch/arm64/kvm/hyp/hyp.h
+++ b/arch/arm64/kvm/hyp/hyp.h
@@ -153,8 +153,10 @@ void __vgic_v3_restore_state(struct kvm_vcpu *vcpu);
 void __timer_save_state(struct kvm_vcpu *vcpu);
 void __timer_restore_state(struct kvm_vcpu *vcpu);
 
-void __sysreg_save_state(struct kvm_cpu_context *ctxt);
-void __sysreg_restore_state(struct kvm_cpu_context *ctxt);
+void __sysreg_save_host_state(struct kvm_cpu_context *ctxt);
+void __sysreg_restore_host_state(struct kvm_cpu_context *ctxt);
+void __sysreg_save_guest_state(struct kvm_cpu_context *ctxt);
+void __sysreg_restore_guest_state(struct kvm_cpu_context *ctxt);
 void __sysreg32_save_state(struct kvm_vcpu *vcpu);
 void __sysreg32_restore_state(struct kvm_vcpu *vcpu);
 
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index f0e7bdf..68f3cba 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -102,7 +102,7 @@ static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
 	host_ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
 	guest_ctxt = &vcpu->arch.ctxt;
 
-	__sysreg_save_state(host_ctxt);
+	__sysreg_save_host_state(host_ctxt);
 	__debug_cond_save_host_state(vcpu);
 
 	__activate_traps(vcpu);
@@ -116,7 +116,7 @@ static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
 	 * to Cortex-A57 erratum #852523.
 	 */
 	__sysreg32_restore_state(vcpu);
-	__sysreg_restore_state(guest_ctxt);
+	__sysreg_restore_guest_state(guest_ctxt);
 	__debug_restore_state(vcpu, kern_hyp_va(vcpu->arch.debug_ptr), guest_ctxt);
 
 	/* Jump in the fire! */
@@ -125,7 +125,7 @@ static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
 
 	fp_enabled = __fpsimd_enabled();
 
-	__sysreg_save_state(guest_ctxt);
+	__sysreg_save_guest_state(guest_ctxt);
 	__sysreg32_save_state(vcpu);
 	__timer_save_state(vcpu);
 	__vgic_save_state(vcpu);
@@ -133,7 +133,7 @@ static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
 	__deactivate_traps(vcpu);
 	__deactivate_vm(vcpu);
 
-	__sysreg_restore_state(host_ctxt);
+	__sysreg_restore_host_state(host_ctxt);
 
 	if (fp_enabled) {
 		__fpsimd_save_state(&guest_ctxt->gp_regs.fp_regs);
@@ -165,7 +165,7 @@ void __hyp_text __noreturn __hyp_panic(void)
 		host_ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
 		__deactivate_traps(vcpu);
 		__deactivate_vm(vcpu);
-		__sysreg_restore_state(host_ctxt);
+		__sysreg_restore_host_state(host_ctxt);
 	}
 
 	/* Call panic for real */
diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
index 42563098..bd5b543 100644
--- a/arch/arm64/kvm/hyp/sysreg-sr.c
+++ b/arch/arm64/kvm/hyp/sysreg-sr.c
@@ -24,7 +24,7 @@
 #include "hyp.h"
 
 /* ctxt is already in the HYP VA space */
-void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
+static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
 {
 	ctxt->sys_regs[MPIDR_EL1]	= read_sysreg(vmpidr_el2);
 	ctxt->sys_regs[CSSELR_EL1]	= read_sysreg(csselr_el1);
@@ -57,7 +57,17 @@ void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
 	ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg(spsr_el1);
 }
 
-void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
+void __hyp_text __sysreg_save_host_state(struct kvm_cpu_context *ctxt)
+{
+	__sysreg_save_state(ctxt);
+}
+
+void __hyp_text __sysreg_save_guest_state(struct kvm_cpu_context *ctxt)
+{
+	__sysreg_save_state(ctxt);
+}
+
+static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
 {
 	write_sysreg(ctxt->sys_regs[MPIDR_EL1],	  vmpidr_el2);
 	write_sysreg(ctxt->sys_regs[CSSELR_EL1],  csselr_el1);
@@ -90,6 +100,16 @@ void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
 	write_sysreg(ctxt->gp_regs.spsr[KVM_SPSR_EL1], spsr_el1);
 }
 
+void __hyp_text __sysreg_restore_host_state(struct kvm_cpu_context *ctxt)
+{
+	__sysreg_restore_state(ctxt);
+}
+
+void __hyp_text __sysreg_restore_guest_state(struct kvm_cpu_context *ctxt)
+{
+	__sysreg_restore_state(ctxt);
+}
+
 void __hyp_text __sysreg32_save_state(struct kvm_vcpu *vcpu)
 {
 	u64 *spsr, *sysreg;
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:48 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:48 +0000
Subject: [PATCH v4 07/23] arm64: KVM: VHE: Patch out use of HVC
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-8-git-send-email-marc.zyngier@arm.com>

With VHE, the host never issues an HVC instruction to get into the
KVM code, as we can simply branch there.

Use runtime code patching to simplify things a bit.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp.S           |  7 +++++++
 arch/arm64/kvm/hyp/hyp-entry.S | 40 +++++++++++++++++++++++++++++++---------
 2 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index 0ccdcbb..0689a74 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -17,7 +17,9 @@
 
 #include <linux/linkage.h>
 
+#include <asm/alternative.h>
 #include <asm/assembler.h>
+#include <asm/cpufeature.h>
 
 /*
  * u64 kvm_call_hyp(void *hypfn, ...);
@@ -38,6 +40,11 @@
  * arch/arm64/kernel/hyp_stub.S.
  */
 ENTRY(kvm_call_hyp)
+alternative_if_not ARM64_HAS_VIRT_HOST_EXTN	
 	hvc	#0
 	ret
+alternative_else
+	b	__vhe_hyp_call
+	nop
+alternative_endif
 ENDPROC(kvm_call_hyp)
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
index 93e8d983..1bdeee7 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -38,6 +38,34 @@
 	ldp	x0, x1, [sp], #16
 .endm
 
+.macro do_el2_call
+	/*
+	 * Shuffle the parameters before calling the function
+	 * pointed to in x0. Assumes parameters in x[1,2,3].
+	 */
+	sub	sp, sp, #16
+	str	lr, [sp]
+	mov	lr, x0
+	mov	x0, x1
+	mov	x1, x2
+	mov	x2, x3
+	blr	lr
+	ldr	lr, [sp]
+	add	sp, sp, #16
+.endm
+
+ENTRY(__vhe_hyp_call)
+	do_el2_call
+	/*
+	 * We used to rely on having an exception return to get
+	 * an implicit isb. In the E2H case, we don't have it anymore.
+	 * rather than changing all the leaf functions, just do it here
+	 * before returning to the rest of the kernel.
+	 */
+	isb
+	ret
+ENDPROC(__vhe_hyp_call)
+	
 el1_sync:				// Guest trapped into EL2
 	save_x0_to_x3
 
@@ -58,19 +86,13 @@ el1_sync:				// Guest trapped into EL2
 	mrs	x0, vbar_el2
 	b	2f
 
-1:	stp	lr, xzr, [sp, #-16]!
-
+1:
 	/*
-	 * Compute the function address in EL2, and shuffle the parameters.
+	 * Perform the EL2 call
 	 */
 	kern_hyp_va	x0
-	mov	lr, x0
-	mov	x0, x1
-	mov	x1, x2
-	mov	x2, x3
-	blr	lr
+	do_el2_call
 
-	ldp	lr, xzr, [sp], #16
 2:	eret
 
 el1_trap:
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:49 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:49 +0000
Subject: [PATCH v4 08/23] arm64: KVM: VHE: Patch out kern_hyp_va
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-9-git-send-email-marc.zyngier@arm.com>

The kern_hyp_va macro is pretty meaninless with VHE, as there is
only one mapping - the kernel one.

In order to keep the code readable and efficient, use runtime
patching to replace the 'and' instruction used to compute the VA
with a 'nop'.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_mmu.h | 12 +++++++++++-
 arch/arm64/kvm/hyp/hyp.h         | 25 ++++++++++++++++++++++---
 2 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 7364339..9a9318a 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -23,13 +23,16 @@
 #include <asm/cpufeature.h>
 
 /*
- * As we only have the TTBR0_EL2 register, we cannot express
+ * As ARMv8.0 only has the TTBR0_EL2 register, we cannot express
  * "negative" addresses. This makes it impossible to directly share
  * mappings with the kernel.
  *
  * Instead, give the HYP mode its own VA region at a fixed offset from
  * the kernel by just masking the top bits (which are all ones for a
  * kernel address).
+ *
+ * ARMv8.1 (using VHE) does have a TTBR1_EL2, and doesn't use these
+ * macros (the entire kernel runs at EL2).
  */
 #define HYP_PAGE_OFFSET_SHIFT	VA_BITS
 #define HYP_PAGE_OFFSET_MASK	((UL(1) << HYP_PAGE_OFFSET_SHIFT) - 1)
@@ -56,12 +59,19 @@
 
 #ifdef __ASSEMBLY__
 
+#include <asm/alternative.h>
+#include <asm/cpufeature.h>
+
 /*
  * Convert a kernel VA into a HYP VA.
  * reg: VA to be converted.
  */
 .macro kern_hyp_va	reg
+alternative_if_not ARM64_HAS_VIRT_HOST_EXTN	
 	and	\reg, \reg, #HYP_PAGE_OFFSET_MASK
+alternative_else
+	nop
+alternative_endif
 .endm
 
 #else
diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
index fb27517..fc502f3 100644
--- a/arch/arm64/kvm/hyp/hyp.h
+++ b/arch/arm64/kvm/hyp/hyp.h
@@ -25,9 +25,28 @@
 
 #define __hyp_text __section(.hyp.text) notrace
 
-#define kern_hyp_va(v) (typeof(v))((unsigned long)(v) & HYP_PAGE_OFFSET_MASK)
-#define hyp_kern_va(v) (typeof(v))((unsigned long)(v) - HYP_PAGE_OFFSET \
-						      + PAGE_OFFSET)
+static inline unsigned long __kern_hyp_va(unsigned long v)
+{
+	asm volatile(ALTERNATIVE("and %0, %0, %1",
+				 "nop",
+				 ARM64_HAS_VIRT_HOST_EXTN)
+		     : "+r" (v) : "i" (HYP_PAGE_OFFSET_MASK));
+	return v;
+}
+
+#define kern_hyp_va(v) (typeof(v))(__kern_hyp_va((unsigned long)(v)))
+
+static inline unsigned long __hyp_kern_va(unsigned long v)
+{
+	u64 offset = PAGE_OFFSET - HYP_PAGE_OFFSET;
+	asm volatile(ALTERNATIVE("add %0, %0, %1",
+				 "nop",
+				 ARM64_HAS_VIRT_HOST_EXTN)
+		     : "+r" (v) : "r" (offset));
+	return v;
+}
+
+#define hyp_kern_va(v) (typeof(v))(__hyp_kern_va((unsigned long)(v)))
 
 /**
  * hyp_alternate_select - Generates patchable code sequences that are
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:55 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:55 +0000
Subject: [PATCH v4 14/23] arm64: KVM: VHE: Make __fpsimd_enabled VHE aware
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-15-git-send-email-marc.zyngier@arm.com>

As non-VHE and VHE have different ways to express the trapping of
FPSIMD registers to EL2, make __fpsimd_enabled a patchable predicate
and provide a VHE implementation.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_arm.h |  3 +++
 arch/arm64/kvm/hyp/hyp.h         |  5 +----
 arch/arm64/kvm/hyp/switch.c      | 19 +++++++++++++++++++
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index bef6e92..f416714 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -218,4 +218,7 @@
 	ECN(SOFTSTP_CUR), ECN(WATCHPT_LOW), ECN(WATCHPT_CUR), \
 	ECN(BKPT32), ECN(VECTOR32), ECN(BRK64)
 
+#define CPACR_EL1_FPEN		(3 << 20)
+#define CPACR_EL1_TTA		(1 << 28)
+
 #endif /* __ARM64_KVM_ARM_H__ */
diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
index 5dfa883..44eaff7 100644
--- a/arch/arm64/kvm/hyp/hyp.h
+++ b/arch/arm64/kvm/hyp/hyp.h
@@ -171,10 +171,7 @@ void __debug_cond_restore_host_state(struct kvm_vcpu *vcpu);
 
 void __fpsimd_save_state(struct user_fpsimd_state *fp_regs);
 void __fpsimd_restore_state(struct user_fpsimd_state *fp_regs);
-static inline bool __fpsimd_enabled(void)
-{
-	return !(read_sysreg(cptr_el2) & CPTR_EL2_TFP);
-}
+bool __fpsimd_enabled(void);
 
 u64 __guest_enter(struct kvm_vcpu *vcpu, struct kvm_cpu_context *host_ctxt);
 void __noreturn __hyp_do_panic(unsigned long, ...);
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 68f3cba..0d82ae9 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -17,6 +17,25 @@
 
 #include "hyp.h"
 
+static bool __hyp_text __fpsimd_enabled_nvhe(void)
+{
+	return !(read_sysreg(cptr_el2) & CPTR_EL2_TFP);
+}
+
+static bool __hyp_text __fpsimd_enabled_vhe(void)
+{
+	return !!(read_sysreg(cpacr_el1) & CPACR_EL1_FPEN);
+}
+
+static hyp_alternate_select(__fpsimd_is_enabled,
+			    __fpsimd_enabled_nvhe, __fpsimd_enabled_vhe,
+			    ARM64_HAS_VIRT_HOST_EXTN);
+
+bool __hyp_text __fpsimd_enabled(void)
+{
+	return __fpsimd_is_enabled()();
+}
+
 static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
 {
 	u64 val;
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:40:02 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:40:02 +0000
Subject: [PATCH v4 21/23] arm64: hw_breakpoint: Allow EL2 breakpoints if
 running in HYP
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-22-git-send-email-marc.zyngier@arm.com>

With VHE, we place kernel {watch,break}-points at EL2 to get things
like kgdb and "perf -e mem:..." working.

This requires a bit of repainting in the low-level encore/decode,
but is otherwise pretty simple.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/hw_breakpoint.h | 49 +++++++++++++++++++++-------------
 1 file changed, 31 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
index 9732908..4d8d5a8 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -18,6 +18,7 @@
 
 #include <asm/cputype.h>
 #include <asm/cpufeature.h>
+#include <asm/virt.h>
 
 #ifdef __KERNEL__
 
@@ -35,24 +36,6 @@ struct arch_hw_breakpoint {
 	struct arch_hw_breakpoint_ctrl ctrl;
 };
 
-static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
-{
-	return (ctrl.len << 5) | (ctrl.type << 3) | (ctrl.privilege << 1) |
-		ctrl.enabled;
-}
-
-static inline void decode_ctrl_reg(u32 reg,
-				   struct arch_hw_breakpoint_ctrl *ctrl)
-{
-	ctrl->enabled	= reg & 0x1;
-	reg >>= 1;
-	ctrl->privilege	= reg & 0x3;
-	reg >>= 2;
-	ctrl->type	= reg & 0x3;
-	reg >>= 2;
-	ctrl->len	= reg & 0xff;
-}
-
 /* Breakpoint */
 #define ARM_BREAKPOINT_EXECUTE	0
 
@@ -62,6 +45,7 @@ static inline void decode_ctrl_reg(u32 reg,
 #define AARCH64_ESR_ACCESS_MASK	(1 << 6)
 
 /* Privilege Levels */
+#define AARCH64_BREAKPOINT_EL2	0
 #define AARCH64_BREAKPOINT_EL1	1
 #define AARCH64_BREAKPOINT_EL0	2
 
@@ -76,6 +60,35 @@ static inline void decode_ctrl_reg(u32 reg,
 #define ARM_KERNEL_STEP_ACTIVE	1
 #define ARM_KERNEL_STEP_SUSPEND	2
 
+#define DBG_HMC_HYP		(1 << 13)
+#define DBG_SSC_HYP		(3 << 14)
+
+static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
+{
+	u32 val = (ctrl.len << 5) | (ctrl.type << 3) | ctrl.enabled;
+
+	if (is_kernel_in_hyp_mode() && ctrl.privilege == AARCH64_BREAKPOINT_EL1)
+		val |= DBG_HMC_HYP | DBG_SSC_HYP | (AARCH64_BREAKPOINT_EL2 << 1);
+	else
+		val |= ctrl.privilege << 1;
+
+	return val;
+}
+
+static inline void decode_ctrl_reg(u32 reg,
+				   struct arch_hw_breakpoint_ctrl *ctrl)
+{
+	ctrl->enabled	= reg & 0x1;
+	reg >>= 1;
+	ctrl->privilege	= reg & 0x3;
+	if (ctrl->privilege == AARCH64_BREAKPOINT_EL2)
+		ctrl->privilege	= AARCH64_BREAKPOINT_EL1;
+	reg >>= 2;
+	ctrl->type	= reg & 0x3;
+	reg >>= 2;
+	ctrl->len	= reg & 0xff;
+}
+
 /*
  * Limits.
  * Changing these will require modifications to the register accessors.
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:56 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:56 +0000
Subject: [PATCH v4 15/23] arm64: KVM: VHE: Implement VHE
 activate/deactivate_traps
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-16-git-send-email-marc.zyngier@arm.com>

Running the kernel in HYP mode requires the HCR_E2H bit to be set
at all times, and the HCR_TGE bit to be set when running as a host
(and cleared when running as a guest). At the same time, the vector
 must be set to the current role of the kernel (either host or
hypervisor), and a couple of system registers differ between VHE
and non-VHE.

We implement these by using another set of alternate functions
that get dynamically patched.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/kvm_arm.h     |  3 +-
 arch/arm64/include/asm/kvm_emulate.h |  3 ++
 arch/arm64/kvm/hyp/switch.c          | 53 ++++++++++++++++++++++++++++++++----
 3 files changed, 52 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index f416714..95ee31e 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -23,6 +23,7 @@
 #include <asm/types.h>
 
 /* Hyp Configuration Register (HCR) bits */
+#define HCR_E2H		(UL(1) << 34)
 #define HCR_ID		(UL(1) << 33)
 #define HCR_CD		(UL(1) << 32)
 #define HCR_RW_SHIFT	31
@@ -81,7 +82,7 @@
 			 HCR_AMO | HCR_SWIO | HCR_TIDCP | HCR_RW)
 #define HCR_VIRT_EXCP_MASK (HCR_VA | HCR_VI | HCR_VF)
 #define HCR_INT_OVERRIDE   (HCR_FMO | HCR_IMO)
-
+#define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H)
 
 /* Hyp System Control Register (SCTLR_EL2) bits */
 #define SCTLR_EL2_EE	(1 << 25)
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 779a587..ae7cdac 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -29,6 +29,7 @@
 #include <asm/kvm_mmio.h>
 #include <asm/ptrace.h>
 #include <asm/cputype.h>
+#include <asm/virt.h>
 
 unsigned long *vcpu_reg32(const struct kvm_vcpu *vcpu, u8 reg_num);
 unsigned long *vcpu_spsr32(const struct kvm_vcpu *vcpu);
@@ -43,6 +44,8 @@ void kvm_inject_pabt(struct kvm_vcpu *vcpu, unsigned long addr);
 static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu)
 {
 	vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
+	if (is_kernel_in_hyp_mode())
+		vcpu->arch.hcr_el2 |= HCR_E2H;
 	if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features))
 		vcpu->arch.hcr_el2 &= ~HCR_RW;
 }
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 0d82ae9..e609942 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -15,6 +15,8 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <asm/kvm_asm.h>
+
 #include "hyp.h"
 
 static bool __hyp_text __fpsimd_enabled_nvhe(void)
@@ -36,6 +38,31 @@ bool __hyp_text __fpsimd_enabled(void)
 	return __fpsimd_is_enabled()();
 }
 
+static void __hyp_text __activate_traps_vhe(void)
+{
+	u64 val;
+
+	val = read_sysreg(cpacr_el1);
+	val |= CPACR_EL1_TTA;
+	val &= ~CPACR_EL1_FPEN;
+	write_sysreg(val, cpacr_el1);
+
+	write_sysreg(__kvm_hyp_vector, vbar_el1);
+}
+
+static void __hyp_text __activate_traps_nvhe(void)
+{
+	u64 val;
+
+	val = CPTR_EL2_DEFAULT;
+	val |= CPTR_EL2_TTA | CPTR_EL2_TFP;
+	write_sysreg(val, cptr_el2);
+}
+
+static hyp_alternate_select(__activate_traps_arch,
+			    __activate_traps_nvhe, __activate_traps_vhe,
+			    ARM64_HAS_VIRT_HOST_EXTN);
+
 static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
 {
 	u64 val;
@@ -55,20 +82,34 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
 	write_sysreg(val, hcr_el2);
 	/* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
 	write_sysreg(1 << 15, hstr_el2);
+	write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
+	__activate_traps_arch()();
+}
 
-	val = CPTR_EL2_DEFAULT;
-	val |= CPTR_EL2_TTA | CPTR_EL2_TFP;
-	write_sysreg(val, cptr_el2);
+static void __hyp_text __deactivate_traps_vhe(void)
+{
+	extern char vectors[];	/* kernel exception vectors */
 
-	write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
+	write_sysreg(HCR_HOST_VHE_FLAGS, hcr_el2);
+	write_sysreg(CPACR_EL1_FPEN, cpacr_el1);
+	write_sysreg(vectors, vbar_el1);
 }
 
-static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
+static void __hyp_text __deactivate_traps_nvhe(void)
 {
 	write_sysreg(HCR_RW, hcr_el2);
+	write_sysreg(CPTR_EL2_DEFAULT, cptr_el2);
+}
+
+static hyp_alternate_select(__deactivate_traps_arch,
+			    __deactivate_traps_nvhe, __deactivate_traps_vhe,
+			    ARM64_HAS_VIRT_HOST_EXTN);
+
+static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
+{
+	__deactivate_traps_arch()();
 	write_sysreg(0, hstr_el2);
 	write_sysreg(read_sysreg(mdcr_el2) & MDCR_EL2_HPMN_MASK, mdcr_el2);
-	write_sysreg(CPTR_EL2_DEFAULT, cptr_el2);
 }
 
 static void __hyp_text __activate_vm(struct kvm_vcpu *vcpu)
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:40:04 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:40:04 +0000
Subject: [PATCH v4 23/23] arm64: Panic when VHE and non VHE CPUs coexist
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-24-git-send-email-marc.zyngier@arm.com>

Having both VHE and non-VHE capable CPUs in the same system
is likely to be a recipe for disaster.

If the boot CPU has VHE, but a secondary is not, we won't be
able to downgrade and run the kernel at EL1. Add CPU hotplug
to the mix, and this produces a terrifying mess.

Let's solve the problem once and for all. If you mix VHE and
non-VHE CPUs in the same system, you deserve to loose, and this
patch makes sure you don't get a chance.

This is implemented by storing the kernel execution level in
a global variable. Secondaries will park themselves in a
WFI loop if they observe a mismatch. Also, the primary CPU
will detect that the secondary CPU has died on a mismatched
execution level. Panic will follow.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/virt.h | 17 +++++++++++++++++
 arch/arm64/kernel/head.S      | 22 ++++++++++++++++++++++
 arch/arm64/kernel/smp.c       |  3 +++
 3 files changed, 42 insertions(+)

diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 9f22dd6..f81a345 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -36,6 +36,11 @@
  */
 extern u32 __boot_cpu_mode[2];
 
+/*
+ * __run_cpu_mode records the mode the boot CPU uses for the kernel.
+ */
+extern u32 __run_cpu_mode[2];
+
 void __hyp_set_vectors(phys_addr_t phys_vector_base);
 phys_addr_t __hyp_get_vectors(void);
 
@@ -60,6 +65,18 @@ static inline bool is_kernel_in_hyp_mode(void)
 	return el == CurrentEL_EL2;
 }
 
+static inline bool is_kernel_mode_mismatched(void)
+{
+	/*
+	 * A mismatched CPU will have written its own CurrentEL in
+	 * __run_cpu_mode[1] (initially set to zero) after failing to
+	 * match the value in __run_cpu_mode[0]. Thus, a non-zero
+	 * value in __run_cpu_mode[1] is enough to detect the
+	 * pathological case.
+	 */
+	return !!ACCESS_ONCE(__run_cpu_mode[1]);
+}
+
 /* The section containing the hypervisor text */
 extern char __hyp_text_start[];
 extern char __hyp_text_end[];
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 6f2f377..eb2ba55 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -578,7 +578,26 @@ ENTRY(set_cpu_boot_mode_flag)
 1:	str	w20, [x1]			// This CPU has booted in EL1
 	dmb	sy
 	dc	ivac, x1			// Invalidate potentially stale cache line
+	adr_l	x1, __run_cpu_mode
+	ldr	w0, [x1]
+	mrs	x20, CurrentEL
+	cbz	x0, skip_el_check
+	cmp	x0, x20
+	bne	mismatched_el
 	ret
+skip_el_check:			// Only the first CPU gets to set the rule
+	str	w20, [x1]
+	dmb	sy
+	dc	ivac, x1	// Invalidate potentially stale cache line
+	dsb	sy
+	ret
+mismatched_el:
+	str	w20, [x1, #4]
+	dmb	sy
+	dc	ivac, x1	// Invalidate potentially stale cache line
+	dsb	sy
+1:	wfi
+	b	1b
 ENDPROC(set_cpu_boot_mode_flag)
 
 /*
@@ -593,6 +612,9 @@ ENDPROC(set_cpu_boot_mode_flag)
 ENTRY(__boot_cpu_mode)
 	.long	BOOT_CPU_MODE_EL2
 	.long	BOOT_CPU_MODE_EL1
+ENTRY(__run_cpu_mode)
+	.long	0
+	.long	0
 	.popsection
 
 	/*
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index b1adc51..bc7650a 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -113,6 +113,9 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
 			pr_crit("CPU%u: failed to come online\n", cpu);
 			ret = -EIO;
 		}
+
+		if (is_kernel_mode_mismatched())
+			panic("CPU%u: incompatible execution level", cpu);
 	} else {
 		pr_err("CPU%u: failed to boot: %d\n", cpu, ret);
 	}
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:40:00 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:40:00 +0000
Subject: [PATCH v4 19/23] arm64: KVM: Move most of the fault decoding to C
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-20-git-send-email-marc.zyngier@arm.com>

The fault decoding process (including computing the IPA in the case
of a permission fault) would be much better done in C code, as we
have a reasonable infrastructure to deal with the VHE/non-VHE
differences.

Let's move the whole thing to C, including the workaround for
erratum 834220, and just patch the odd ESR_EL2 access remaining
in hyp-entry.S.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kernel/asm-offsets.c |  3 --
 arch/arm64/kvm/hyp/hyp-entry.S  | 69 +++------------------------------
 arch/arm64/kvm/hyp/switch.c     | 85 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 90 insertions(+), 67 deletions(-)

diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index fffa4ac6..b0ab4e9 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -110,9 +110,6 @@ int main(void)
   DEFINE(CPU_USER_PT_REGS,	offsetof(struct kvm_regs, regs));
   DEFINE(CPU_FP_REGS,		offsetof(struct kvm_regs, fp_regs));
   DEFINE(VCPU_FPEXC32_EL2,	offsetof(struct kvm_vcpu, arch.ctxt.sys_regs[FPEXC32_EL2]));
-  DEFINE(VCPU_ESR_EL2,		offsetof(struct kvm_vcpu, arch.fault.esr_el2));
-  DEFINE(VCPU_FAR_EL2,		offsetof(struct kvm_vcpu, arch.fault.far_el2));
-  DEFINE(VCPU_HPFAR_EL2,	offsetof(struct kvm_vcpu, arch.fault.hpfar_el2));
   DEFINE(VCPU_HOST_CONTEXT,	offsetof(struct kvm_vcpu, arch.host_cpu_context));
 #endif
 #ifdef CONFIG_CPU_PM
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
index 1bdeee7..3488894 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -19,7 +19,6 @@
 
 #include <asm/alternative.h>
 #include <asm/assembler.h>
-#include <asm/asm-offsets.h>
 #include <asm/cpufeature.h>
 #include <asm/kvm_arm.h>
 #include <asm/kvm_asm.h>
@@ -69,7 +68,11 @@ ENDPROC(__vhe_hyp_call)
 el1_sync:				// Guest trapped into EL2
 	save_x0_to_x3
 
+alternative_if_not ARM64_HAS_VIRT_HOST_EXTN
 	mrs	x1, esr_el2
+alternative_else
+	mrs	x1, esr_el1
+alternative_endif
 	lsr	x2, x1, #ESR_ELx_EC_SHIFT
 
 	cmp	x2, #ESR_ELx_EC_HVC64
@@ -105,72 +108,10 @@ el1_trap:
 	cmp	x2, #ESR_ELx_EC_FP_ASIMD
 	b.eq	__fpsimd_guest_restore
 
-	cmp	x2, #ESR_ELx_EC_DABT_LOW
-	mov	x0, #ESR_ELx_EC_IABT_LOW
-	ccmp	x2, x0, #4, ne
-	b.ne	1f		// Not an abort we care about
-
-	/* This is an abort. Check for permission fault */
-alternative_if_not ARM64_WORKAROUND_834220
-	and	x2, x1, #ESR_ELx_FSC_TYPE
-	cmp	x2, #FSC_PERM
-	b.ne	1f		// Not a permission fault
-alternative_else
-	nop			// Use the permission fault path to
-	nop			// check for a valid S1 translation,
-	nop			// regardless of the ESR value.
-alternative_endif
-
-	/*
-	 * Check for Stage-1 page table walk, which is guaranteed
-	 * to give a valid HPFAR_EL2.
-	 */
-	tbnz	x1, #7, 1f	// S1PTW is set
-
-	/* Preserve PAR_EL1 */
-	mrs	x3, par_el1
-	stp	x3, xzr, [sp, #-16]!
-
-	/*
-	 * Permission fault, HPFAR_EL2 is invalid.
-	 * Resolve the IPA the hard way using the guest VA.
-	 * Stage-1 translation already validated the memory access rights.
-	 * As such, we can use the EL1 translation regime, and don't have
-	 * to distinguish between EL0 and EL1 access.
-	 */
-	mrs	x2, far_el2
-	at	s1e1r, x2
-	isb
-
-	/* Read result */
-	mrs	x3, par_el1
-	ldp	x0, xzr, [sp], #16	// Restore PAR_EL1 from the stack
-	msr	par_el1, x0
-	tbnz	x3, #0, 3f		// Bail out if we failed the translation
-	ubfx	x3, x3, #12, #36	// Extract IPA
-	lsl	x3, x3, #4		// and present it like HPFAR
-	b	2f
-
-1:	mrs	x3, hpfar_el2
-	mrs	x2, far_el2
-
-2:	mrs	x0, tpidr_el2
-	str	w1, [x0, #VCPU_ESR_EL2]
-	str	x2, [x0, #VCPU_FAR_EL2]
-	str	x3, [x0, #VCPU_HPFAR_EL2]
-
+	mrs	x0, tpidr_el2
 	mov	x1, #ARM_EXCEPTION_TRAP
 	b	__guest_exit
 
-	/*
-	 * Translation failed. Just return to the guest and
-	 * let it fault again. Another CPU is probably playing
-	 * behind our back.
-	 */
-3:	restore_x0_to_x3
-
-	eret
-
 el1_irq:
 	save_x0_to_x3
 	mrs	x0, tpidr_el2
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 731f0a2..ecf5b05 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -15,6 +15,7 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/types.h>
 #include <asm/kvm_asm.h>
 
 #include "hyp.h"
@@ -149,6 +150,86 @@ static void __hyp_text __vgic_restore_state(struct kvm_vcpu *vcpu)
 	__vgic_call_restore_state()(vcpu);
 }
 
+static bool __hyp_text __true_value(void)
+{
+	return true;
+}
+
+static bool __hyp_text __false_value(void)
+{
+	return false;
+}
+
+static hyp_alternate_select(__check_arm_834220,
+			    __false_value, __true_value,
+			    ARM64_WORKAROUND_834220);
+
+static bool __hyp_text __translate_far_to_hpfar(u64 far, u64 *hpfar)
+{
+	u64 par, tmp;
+
+	/*
+	 * Resolve the IPA the hard way using the guest VA.
+	 *
+	 * Stage-1 translation already validated the memory access
+	 * rights. As such, we can use the EL1 translation regime, and
+	 * don't have to distinguish between EL0 and EL1 access.
+	 *
+	 * We do need to save/restore PAR_EL1 though, as we haven't
+	 * saved the guest context yet, and we may return early...
+	 */
+	par = read_sysreg(par_el1);
+	asm volatile("at s1e1r, %0" : : "r" (far));
+	isb();
+
+	tmp = read_sysreg(par_el1);
+	write_sysreg(par, par_el1);
+
+	if (unlikely(tmp & 1))
+		return false; /* Translation failed, back to guest */
+
+	/* Convert PAR to HPFAR format */
+	*hpfar = ((tmp >> 12) & ((1UL << 36) - 1)) << 4;
+	return true;
+}
+
+static bool __hyp_text __populate_fault_info(struct kvm_vcpu *vcpu)
+{
+	u64 esr = read_sysreg_el2(esr);
+	u8 ec = esr >> ESR_ELx_EC_SHIFT;
+	u64 hpfar, far;
+
+	vcpu->arch.fault.esr_el2 = esr;
+
+	if (ec != ESR_ELx_EC_DABT_LOW && ec != ESR_ELx_EC_IABT_LOW)
+		return true;
+
+	far = read_sysreg_el2(far);
+
+	/*
+	 * The HPFAR can be invalid if the stage 2 fault did not
+	 * happen during a stage 1 page table walk (the ESR_EL2.S1PTW
+	 * bit is clear) and one of the two following cases are true:
+	 *   1. The fault was due to a permission fault
+	 *   2. The processor carries errata 834220
+	 *
+	 * Therefore, for all non S1PTW faults where we either have a
+	 * permission fault or the errata workaround is enabled, we
+	 * resolve the IPA using the AT instruction.
+	 */
+	if (!(esr & ESR_ELx_S1PTW) &&
+	    (__check_arm_834220()() || (esr & ESR_ELx_FSC_TYPE) == FSC_PERM)) {
+		if (!__translate_far_to_hpfar(far, &hpfar))
+			return false;
+	} else {
+		hpfar = read_sysreg(hpfar_el2);
+	}
+
+	vcpu->arch.fault.far_el2 = far;
+	vcpu->arch.fault.hpfar_el2 = hpfar;
+	return true;
+}
+
 static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
 {
 	struct kvm_cpu_context *host_ctxt;
@@ -180,9 +261,13 @@ static int __hyp_text __guest_run(struct kvm_vcpu *vcpu)
 	__debug_restore_state(vcpu, kern_hyp_va(vcpu->arch.debug_ptr), guest_ctxt);
 
 	/* Jump in the fire! */
+again:
 	exit_code = __guest_enter(vcpu, host_ctxt);
 	/* And we're baaack! */
 
+	if (exit_code == ARM_EXCEPTION_TRAP && !__populate_fault_info(vcpu))
+		goto again;
+
 	fp_enabled = __fpsimd_enabled();
 
 	__sysreg_save_guest_state(guest_ctxt);
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:54 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:54 +0000
Subject: [PATCH v4 13/23] arm64: KVM: VHE: Enable minimal sysreg save/restore
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-14-git-send-email-marc.zyngier@arm.com>

We're now in a position where we can introduce VHE's minimal
save/restore, which is limited to the handful of shared sysregs.

Add the required alternative function calls that result in a
"do nothing" call on VHE, and the normal save/restore for non-VHE.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/sysreg-sr.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
index 7d7d757..74b5f81 100644
--- a/arch/arm64/kvm/hyp/sysreg-sr.c
+++ b/arch/arm64/kvm/hyp/sysreg-sr.c
@@ -23,6 +23,9 @@
 
 #include "hyp.h"
 
+/* Yes, this does nothing, on purpose */
+static void __hyp_text __sysreg_do_nothing(struct kvm_cpu_context *ctxt) { }
+
 /*
  * Non-VHE: Both host and guest must save everything.
  *
@@ -67,9 +70,13 @@ static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
 	ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg_el1(spsr);
 }
 
+static hyp_alternate_select(__sysreg_call_save_host_state,
+			    __sysreg_save_state, __sysreg_do_nothing,
+			    ARM64_HAS_VIRT_HOST_EXTN);
+
 void __hyp_text __sysreg_save_host_state(struct kvm_cpu_context *ctxt)
 {
-	__sysreg_save_state(ctxt);
+	__sysreg_call_save_host_state()(ctxt);
 	__sysreg_save_common_state(ctxt);
 }
 
@@ -116,9 +123,13 @@ static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
 	write_sysreg_el1(ctxt->gp_regs.spsr[KVM_SPSR_EL1],spsr);
 }
 
+static hyp_alternate_select(__sysreg_call_restore_host_state,
+			    __sysreg_restore_state, __sysreg_do_nothing,
+			    ARM64_HAS_VIRT_HOST_EXTN);
+
 void __hyp_text __sysreg_restore_host_state(struct kvm_cpu_context *ctxt)
 {
-	__sysreg_restore_state(ctxt);
+	__sysreg_call_restore_host_state()(ctxt);
 	__sysreg_restore_common_state(ctxt);
 }
 
-- 
2.1.4



From martin at sperl.org  Thu Feb 11 10:44:55 2016
From: martin at sperl.org (Martin Sperl)
Date: Thu, 11 Feb 2016 19:44:55 +0100
Subject: [PATCH 4/4] spi: bcm2835aux: fix CPOL/CPHA setting
In-Reply-To: <50D0ECA7-8116-4248-AC85-6E1C8002A185@sperl.org>
References: <1455041435-8015-1-git-send-email-stephanolbrich@gmx.de>
 <87a8n94e3x.fsf@eliezer.anholt.net>
 <16A848EA-6E08-48C4-B3DD-DF27333B7458@sperl.org>
 <10547867.CcbLVQlgyH@chaos-desktop>
 <50D0ECA7-8116-4248-AC85-6E1C8002A185@sperl.org>
Message-ID: <26830EBF-A5F2-4BE3-88A2-C9E0A97A4881@sperl.org>


> On 11.02.2016, at 17:19, Martin Sperl <martin at sperl.org> wrote:

>> At the end with the last rising edge of SCLK MOSI goes to low and stays there 
>> while SCLK goes to low and then CS to inactive.
>> 
>> So the slave has no chance to get the first bit but gets an additional 0 at the 
>> end.

Actually SPI says: sample AT the clock change - not shortly after.
So the behavior in principle is correct - even if it is not perfect...

>> It may not be easy visible with 0x00,0x82,0x00 as data, so could you repeat 
>> your test with 0xAA,0xFF if you see the same as I do or not?
> 
> I did retest also with 0x81,0x00,0x81 and saw my expected behavior - but maybe
> me understanding of those modes is wrong.
> 
> I will send you the images for the pattern I have generated with 
> 0x81, 0x00, 0x81 as a personal email.


There is a means to add an additional HOLD time of 1, 4 or 7
system-clock cycles (undivided) that extend the period
while MOSI is still driven with the old bit value after the
clock change.

This can get fixed like this (copy paste, so tabs are spaces):

diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
index bd490c0..6052628 100644
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -63,6 +63,10 @@
 #define BCM2835_AUX_SPI_CNTL0_VAR_CS   0x00008000
 #define BCM2835_AUX_SPI_CNTL0_VAR_WIDTH        0x00004000
 #define BCM2835_AUX_SPI_CNTL0_DOUTHOLD 0x00003000
+#define BCM2835_AUX_SPI_CNTL0_DOUTHOLD_0       0x00000000
+#define BCM2835_AUX_SPI_CNTL0_DOUTHOLD_1       0x00001000
+#define BCM2835_AUX_SPI_CNTL0_DOUTHOLD_4       0x00002000
+#define BCM2835_AUX_SPI_CNTL0_DOUTHOLD_7       0x00003000
 #define BCM2835_AUX_SPI_CNTL0_ENABLE   0x00000800
 #define BCM2835_AUX_SPI_CNTL0_CPHA_IN  0x00000400
 #define BCM2835_AUX_SPI_CNTL0_CLEARFIFO        0x00000200
@@ -341,10 +345,35 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *
        } else { /* the slowest we can go */
                speed = BCM2835_AUX_SPI_CNTL0_SPEED_MAX;
        }
+       /* mask out old speed from previous spi_transfer */
+       bs->cntl[0] &= ~BCM2835_AUX_SPI_CNTL0_SPEED;
+       /* and set speed for this round */
        bs->cntl[0] |= speed << BCM2835_AUX_SPI_CNTL0_SPEED_SHIFT;

        spi_used_hz = clk_hz / (2 * (speed + 1));

+       /* and configure hold time - needs to take speed into account */
+       /* first clear it */
+       bs->cntl[0] &= ~BCM2835_AUX_SPI_CNTL0_DOUTHOLD;
+       switch (speed) {
+       case 0: /* divider 2 */
+       case 1: /* divider 4 */
+               /* data hold time of 1 system clock cycle */
+               bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_DOUTHOLD_1;
+               break;
+       case 2: /* divider 6 */
+       case 3: /* divider 8 */
+       case 4: /* divider 10 */
+       case 5: /* divider 12 */
+               /* data hold time of 4 system clock cycle */
+               bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_DOUTHOLD_4;
+               break;
+       default: /* divider 14 and above */
+               /* data hold time of 7 system clock cycle */
+               bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_DOUTHOLD_7;
+               break;
+       }
+
        /* set transmit buffers and length */
        bs->tx_buf = tfr->tx_buf;
        bs->rx_buf = tfr->rx_buf;

It still means that CPHA=1 may fail to work with devices that
run a software based SPI implementation that has a delay between
clock change and sampling.
SPI slaves that latch the value on clock change should be fine.

Hopefully the policies for the delays were chosen wisely?

But for all practical purposes the DOUTHOLD is 7 systen clock
cycles (undivided or .000000027s) for anything below 
18.3MHz (=256MHz/(2*(1+6)).

If this is an unacceptable limitation, then we can disable CPHA
support by removing SPI_CPHA from BCM2835_AUX_SPI_MODE_BITS.

Maybe by making it a configuration option in the device-tree?

Martin

From marc.zyngier at arm.com  Thu Feb 11 10:39:59 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:59 +0000
Subject: [PATCH v4 18/23] arm64: KVM: VHE: Add alternative panic handling
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-19-git-send-email-marc.zyngier@arm.com>

As the kernel fully runs in HYP when VHE is enabled, we can
directly branch to the kernel's panic() implementation, and
not perform an exception return.

Add the alternative code to deal with this.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/switch.c | 35 +++++++++++++++++++++++++++--------
 1 file changed, 27 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index e609942..731f0a2 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -210,11 +210,34 @@ __alias(__guest_run) int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
 
 static const char __hyp_panic_string[] = "HYP panic:\nPS:%08llx PC:%016llx ESR:%08llx\nFAR:%016llx HPFAR:%016llx PAR:%016llx\nVCPU:%p\n";
 
-void __hyp_text __noreturn __hyp_panic(void)
+static void __hyp_text __hyp_call_panic_nvhe(u64 spsr, u64 elr, u64 par)
 {
 	unsigned long str_va = (unsigned long)__hyp_panic_string;
-	u64 spsr = read_sysreg(spsr_el2);
-	u64 elr = read_sysreg(elr_el2);
+
+	__hyp_do_panic(hyp_kern_va(str_va),
+		       spsr,  elr,
+		       read_sysreg(esr_el2),   read_sysreg_el2(far),
+		       read_sysreg(hpfar_el2), par,
+		       (void *)read_sysreg(tpidr_el2));
+}
+
+static void __hyp_text __hyp_call_panic_vhe(u64 spsr, u64 elr, u64 par)
+{
+	panic(__hyp_panic_string,
+	      spsr,  elr,
+	      read_sysreg_el2(esr),   read_sysreg_el2(far),
+	      read_sysreg(hpfar_el2), par,
+	      (void *)read_sysreg(tpidr_el2));
+}
+
+static hyp_alternate_select(__hyp_call_panic,
+			    __hyp_call_panic_nvhe, __hyp_call_panic_vhe,
+			    ARM64_HAS_VIRT_HOST_EXTN);
+
+void __hyp_text __noreturn __hyp_panic(void)
+{
+	u64 spsr = read_sysreg_el2(spsr);
+	u64 elr = read_sysreg_el2(elr);
 	u64 par = read_sysreg(par_el1);
 
 	if (read_sysreg(vttbr_el2)) {
@@ -229,11 +252,7 @@ void __hyp_text __noreturn __hyp_panic(void)
 	}
 
 	/* Call panic for real */
-	__hyp_do_panic(hyp_kern_va(str_va),
-		       spsr,  elr,
-		       read_sysreg(esr_el2),   read_sysreg(far_el2),
-		       read_sysreg(hpfar_el2), par,
-		       (void *)read_sysreg(tpidr_el2));
+	__hyp_call_panic()(spsr, elr, par);
 
 	unreachable();
 }
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:40:01 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:40:01 +0000
Subject: [PATCH v4 20/23] arm64: perf: Count EL2 events if the kernel is
 running in HYP
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-21-git-send-email-marc.zyngier@arm.com>

When the kernel is running in HYP (with VHE), it is necessary to
include EL2 events if the user requests counting kernel or
hypervisor events.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kernel/perf_event.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index f7ab14c..6013a38 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -20,6 +20,7 @@
  */
 
 #include <asm/irq_regs.h>
+#include <asm/virt.h>
 
 #include <linux/of.h>
 #include <linux/perf/arm_pmu.h>
@@ -693,10 +694,15 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
 		return -EPERM;
 	if (attr->exclude_user)
 		config_base |= ARMV8_EXCLUDE_EL0;
-	if (attr->exclude_kernel)
-		config_base |= ARMV8_EXCLUDE_EL1;
-	if (!attr->exclude_hv)
-		config_base |= ARMV8_INCLUDE_EL2;
+	if (is_kernel_in_hyp_mode()) {
+		if (!attr->exclude_kernel || !attr->exclude_hv)
+			config_base |= ARMV8_INCLUDE_EL2;
+	} else {
+		if (attr->exclude_kernel)
+			config_base |= ARMV8_EXCLUDE_EL1;
+		if (!attr->exclude_hv)
+			config_base |= ARMV8_INCLUDE_EL2;
+	}
 
 	/*
 	 * Install the filter into config_base as this is used to
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:40:03 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:40:03 +0000
Subject: [PATCH v4 22/23] arm64: VHE: Add support for running Linux in EL2 mode
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-23-git-send-email-marc.zyngier@arm.com>

With ARMv8.1 VHE, the architecture is able to (almost) transparently
run the kernel at EL2, despite being written for EL1.

This patch takes care of the "almost" part, mostly preventing the kernel
from dropping from EL2 to EL1, and setting up the HYP configuration.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/Kconfig       | 13 +++++++++++++
 arch/arm64/kernel/head.S | 28 +++++++++++++++++++++++++++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc6228..cf118d9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -750,6 +750,19 @@ config ARM64_LSE_ATOMICS
 	  not support these instructions and requires the kernel to be
 	  built with binutils >= 2.25.
 
+config ARM64_VHE
+	bool "Enable support for Virtualization Host Extensions (VHE)"
+	default y
+	help
+	  Virtualization Host Extensions (VHE) allow the kernel to run
+	  directly at EL2 (instead of EL1) on processors that support
+	  it. This leads to better performance for KVM, as they reduce
+	  the cost of the world switch.
+
+	  Selecting this option allows the VHE feature to be detected
+	  at runtime, and does not affect processors that do not
+	  implement this feature.
+
 endmenu
 
 endmenu
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 917d981..6f2f377 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -30,6 +30,7 @@
 #include <asm/cache.h>
 #include <asm/cputype.h>
 #include <asm/kernel-pgtable.h>
+#include <asm/kvm_arm.h>
 #include <asm/memory.h>
 #include <asm/pgtable-hwdef.h>
 #include <asm/pgtable.h>
@@ -464,9 +465,27 @@ CPU_LE(	bic	x0, x0, #(3 << 24)	)	// Clear the EE and E0E bits for EL1
 	isb
 	ret
 
+2:
+#ifdef CONFIG_ARM64_VHE
+	/*
+	 * Check for VHE being present. For the rest of the EL2 setup,
+	 * x2 being non-zero indicates that we do have VHE, and that the
+	 * kernel is intended to run at EL2.
+	 */
+	mrs	x2, id_aa64mmfr1_el1
+	ubfx	x2, x2, #8, #4
+#else
+	mov	x2, xzr
+#endif
+
 	/* Hyp configuration. */
-2:	mov	x0, #(1 << 31)			// 64-bit EL1
+	mov	x0, #HCR_RW			// 64-bit EL1
+	cbz	x2, set_hcr
+	orr	x0, x0, #HCR_TGE		// Enable Host Extensions
+	orr	x0, x0, #HCR_E2H
+set_hcr:
 	msr	hcr_el2, x0
+	isb
 
 	/* Generic timers. */
 	mrs	x0, cnthctl_el2
@@ -526,6 +545,13 @@ CPU_LE(	movk	x0, #0x30d0, lsl #16	)	// Clear EE and E0E on LE systems
 	/* Stage-2 translation */
 	msr	vttbr_el2, xzr
 
+	cbz	x2, install_el2_stub
+
+	mov	w20, #BOOT_CPU_MODE_EL2		// This CPU booted in EL2
+	isb
+	ret
+
+install_el2_stub:
 	/* Hypervisor stub */
 	adrp	x0, __hyp_stub_vectors
 	add	x0, x0, #:lo12:__hyp_stub_vectors
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:41 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:41 +0000
Subject: [PATCH v4 00/23] arm64: Virtualization Host Extension support
Message-ID: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>

ARMv8.1 comes with the "Virtualization Host Extension" (VHE for
short), which enables simpler support of Type-2 hypervisors.

This extension allows the kernel to directly run at EL2, and
significantly reduces the number of system registers shared between
host and guest, reducing the overhead of virtualization.

In order to have the same kernel binary running on all versions of the
architecture, this series makes heavy use of runtime code patching.

The first 22 patches massage the KVM code to deal with VHE and enable
Linux to run at EL2. The last patch catches an ugly case when VHE
capable CPUs are paired with some of their less capable siblings. This
should never happen, but hey...

I have deliberately left out some of the more "advanced"
optimizations, as they are likely to distract the reviewer from the
core infrastructure, which is what I care about at the moment.

Note: GDB is currently busted on VHE systems, as it checks for version
      6 on the debug architecture, while VHE is version 7. The
      binutils people are on the case.

This has been tested on the FVP_Base_SLV-V8-A model, and based on
v4.5-rc3 + kvmarm/master. I've put a branch out on:

git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/vhe

* From v3:
  - Cleaned debug handling after comments from Catalin
  - Added missing barriers in the panic patch
  - Collected Rb and Acks from Christoffer and Catalin

* From v2:
  - Added support for perf to count kernel events in EL2
  - Added support for EL2 breakpoints
  - Moved the VTCR_EL2 setup from assembly to C
  - Made the fault handling easier to understand (hopefuly)
  - Plenty of smaller fixups

* From v1:
  - Full rewrite now that the World Switch is written in C code.
  - Dropped the "early IRQ handling" for the moment.

Marc Zyngier (23):
  arm/arm64: KVM: Add hook for C-based stage2 init
  arm64: KVM: Switch to C-based stage2 init
  arm/arm64: Add new is_kernel_in_hyp_mode predicate
  arm64: Allow the arch timer to use the HYP timer
  arm64: Add ARM64_HAS_VIRT_HOST_EXTN feature
  arm64: KVM: Skip HYP setup when already running in HYP
  arm64: KVM: VHE: Patch out use of HVC
  arm64: KVM: VHE: Patch out kern_hyp_va
  arm64: KVM: VHE: Introduce unified system register accessors
  arm64: KVM: VHE: Differenciate host/guest sysreg save/restore
  arm64: KVM: VHE: Split save/restore of registers shared between guest
    and host
  arm64: KVM: VHE: Use unified system register accessors
  arm64: KVM: VHE: Enable minimal sysreg save/restore
  arm64: KVM: VHE: Make __fpsimd_enabled VHE aware
  arm64: KVM: VHE: Implement VHE activate/deactivate_traps
  arm64: KVM: VHE: Use unified sysreg accessors for timer
  arm64: KVM: VHE: Add fpsimd enabling on guest access
  arm64: KVM: VHE: Add alternative panic handling
  arm64: KVM: Move most of the fault decoding to C
  arm64: perf: Count EL2 events if the kernel is running in HYP
  arm64: hw_breakpoint: Allow EL2 breakpoints if running in HYP
  arm64: VHE: Add support for running Linux in EL2 mode
  arm64: Panic when VHE and non VHE CPUs coexist

 arch/arm/include/asm/kvm_host.h        |   4 +
 arch/arm/include/asm/virt.h            |   5 +
 arch/arm/kvm/arm.c                     | 174 ++++++++++++++++++----------
 arch/arm/kvm/mmu.c                     |   7 ++
 arch/arm64/Kconfig                     |  13 +++
 arch/arm64/include/asm/cpufeature.h    |   3 +-
 arch/arm64/include/asm/hw_breakpoint.h |  49 +++++---
 arch/arm64/include/asm/kvm_arm.h       |   6 +-
 arch/arm64/include/asm/kvm_asm.h       |   2 +
 arch/arm64/include/asm/kvm_emulate.h   |   3 +
 arch/arm64/include/asm/kvm_host.h      |   6 +
 arch/arm64/include/asm/kvm_mmu.h       |  12 +-
 arch/arm64/include/asm/virt.h          |  27 +++++
 arch/arm64/kernel/asm-offsets.c        |   3 -
 arch/arm64/kernel/cpufeature.c         |  11 ++
 arch/arm64/kernel/head.S               |  50 +++++++-
 arch/arm64/kernel/perf_event.c         |  14 ++-
 arch/arm64/kernel/smp.c                |   3 +
 arch/arm64/kvm/hyp-init.S              |  18 ---
 arch/arm64/kvm/hyp.S                   |   7 ++
 arch/arm64/kvm/hyp/Makefile            |   1 +
 arch/arm64/kvm/hyp/entry.S             |   6 +
 arch/arm64/kvm/hyp/hyp-entry.S         | 109 ++++++------------
 arch/arm64/kvm/hyp/hyp.h               | 108 ++++++++++++++++--
 arch/arm64/kvm/hyp/s2-setup.c          |  44 +++++++
 arch/arm64/kvm/hyp/switch.c            | 202 +++++++++++++++++++++++++++++----
 arch/arm64/kvm/hyp/sysreg-sr.c         | 147 ++++++++++++++++--------
 arch/arm64/kvm/hyp/timer-sr.c          |  10 +-
 drivers/clocksource/arm_arch_timer.c   |  96 ++++++++++------
 29 files changed, 842 insertions(+), 298 deletions(-)
 create mode 100644 arch/arm64/kvm/hyp/s2-setup.c

-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:53 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:53 +0000
Subject: [PATCH v4 12/23] arm64: KVM: VHE: Use unified system register
 accessors
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-13-git-send-email-marc.zyngier@arm.com>

Use the recently introduced unified system register accessors for
those sysregs that behave differently depending on VHE being in
use or not.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/sysreg-sr.c | 84 +++++++++++++++++++++---------------------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c
index 61bad17..7d7d757 100644
--- a/arch/arm64/kvm/hyp/sysreg-sr.c
+++ b/arch/arm64/kvm/hyp/sysreg-sr.c
@@ -37,34 +37,34 @@ static void __hyp_text __sysreg_save_common_state(struct kvm_cpu_context *ctxt)
 	ctxt->sys_regs[TPIDRRO_EL0]	= read_sysreg(tpidrro_el0);
 	ctxt->sys_regs[TPIDR_EL1]	= read_sysreg(tpidr_el1);
 	ctxt->gp_regs.regs.sp		= read_sysreg(sp_el0);
-	ctxt->gp_regs.regs.pc		= read_sysreg(elr_el2);
-	ctxt->gp_regs.regs.pstate	= read_sysreg(spsr_el2);
+	ctxt->gp_regs.regs.pc		= read_sysreg_el2(elr);
+	ctxt->gp_regs.regs.pstate	= read_sysreg_el2(spsr);
 }
 
 static void __hyp_text __sysreg_save_state(struct kvm_cpu_context *ctxt)
 {
 	ctxt->sys_regs[MPIDR_EL1]	= read_sysreg(vmpidr_el2);
 	ctxt->sys_regs[CSSELR_EL1]	= read_sysreg(csselr_el1);
-	ctxt->sys_regs[SCTLR_EL1]	= read_sysreg(sctlr_el1);
-	ctxt->sys_regs[CPACR_EL1]	= read_sysreg(cpacr_el1);
-	ctxt->sys_regs[TTBR0_EL1]	= read_sysreg(ttbr0_el1);
-	ctxt->sys_regs[TTBR1_EL1]	= read_sysreg(ttbr1_el1);
-	ctxt->sys_regs[TCR_EL1]		= read_sysreg(tcr_el1);
-	ctxt->sys_regs[ESR_EL1]		= read_sysreg(esr_el1);
-	ctxt->sys_regs[AFSR0_EL1]	= read_sysreg(afsr0_el1);
-	ctxt->sys_regs[AFSR1_EL1]	= read_sysreg(afsr1_el1);
-	ctxt->sys_regs[FAR_EL1]		= read_sysreg(far_el1);
-	ctxt->sys_regs[MAIR_EL1]	= read_sysreg(mair_el1);
-	ctxt->sys_regs[VBAR_EL1]	= read_sysreg(vbar_el1);
-	ctxt->sys_regs[CONTEXTIDR_EL1]	= read_sysreg(contextidr_el1);
-	ctxt->sys_regs[AMAIR_EL1]	= read_sysreg(amair_el1);
-	ctxt->sys_regs[CNTKCTL_EL1]	= read_sysreg(cntkctl_el1);
+	ctxt->sys_regs[SCTLR_EL1]	= read_sysreg_el1(sctlr);
+	ctxt->sys_regs[CPACR_EL1]	= read_sysreg_el1(cpacr);
+	ctxt->sys_regs[TTBR0_EL1]	= read_sysreg_el1(ttbr0);
+	ctxt->sys_regs[TTBR1_EL1]	= read_sysreg_el1(ttbr1);
+	ctxt->sys_regs[TCR_EL1]		= read_sysreg_el1(tcr);
+	ctxt->sys_regs[ESR_EL1]		= read_sysreg_el1(esr);
+	ctxt->sys_regs[AFSR0_EL1]	= read_sysreg_el1(afsr0);
+	ctxt->sys_regs[AFSR1_EL1]	= read_sysreg_el1(afsr1);
+	ctxt->sys_regs[FAR_EL1]		= read_sysreg_el1(far);
+	ctxt->sys_regs[MAIR_EL1]	= read_sysreg_el1(mair);
+	ctxt->sys_regs[VBAR_EL1]	= read_sysreg_el1(vbar);
+	ctxt->sys_regs[CONTEXTIDR_EL1]	= read_sysreg_el1(contextidr);
+	ctxt->sys_regs[AMAIR_EL1]	= read_sysreg_el1(amair);
+	ctxt->sys_regs[CNTKCTL_EL1]	= read_sysreg_el1(cntkctl);
 	ctxt->sys_regs[PAR_EL1]		= read_sysreg(par_el1);
 	ctxt->sys_regs[MDSCR_EL1]	= read_sysreg(mdscr_el1);
 
 	ctxt->gp_regs.sp_el1		= read_sysreg(sp_el1);
-	ctxt->gp_regs.elr_el1		= read_sysreg(elr_el1);
-	ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg(spsr_el1);
+	ctxt->gp_regs.elr_el1		= read_sysreg_el1(elr);
+	ctxt->gp_regs.spsr[KVM_SPSR_EL1]= read_sysreg_el1(spsr);
 }
 
 void __hyp_text __sysreg_save_host_state(struct kvm_cpu_context *ctxt)
@@ -86,34 +86,34 @@ static void __hyp_text __sysreg_restore_common_state(struct kvm_cpu_context *ctx
 	write_sysreg(ctxt->sys_regs[TPIDRRO_EL0], tpidrro_el0);
 	write_sysreg(ctxt->sys_regs[TPIDR_EL1],	  tpidr_el1);
 	write_sysreg(ctxt->gp_regs.regs.sp,	  sp_el0);
-	write_sysreg(ctxt->gp_regs.regs.pc,	  elr_el2);
-	write_sysreg(ctxt->gp_regs.regs.pstate,	  spsr_el2);
+	write_sysreg_el2(ctxt->gp_regs.regs.pc,	  elr);
+	write_sysreg_el2(ctxt->gp_regs.regs.pstate, spsr);
 }
 
 static void __hyp_text __sysreg_restore_state(struct kvm_cpu_context *ctxt)
 {
-	write_sysreg(ctxt->sys_regs[MPIDR_EL1],	  vmpidr_el2);
-	write_sysreg(ctxt->sys_regs[CSSELR_EL1],  csselr_el1);
-	write_sysreg(ctxt->sys_regs[SCTLR_EL1],	  sctlr_el1);
-	write_sysreg(ctxt->sys_regs[CPACR_EL1],	  cpacr_el1);
-	write_sysreg(ctxt->sys_regs[TTBR0_EL1],	  ttbr0_el1);
-	write_sysreg(ctxt->sys_regs[TTBR1_EL1],	  ttbr1_el1);
-	write_sysreg(ctxt->sys_regs[TCR_EL1],	  tcr_el1);
-	write_sysreg(ctxt->sys_regs[ESR_EL1],	  esr_el1);
-	write_sysreg(ctxt->sys_regs[AFSR0_EL1],	  afsr0_el1);
-	write_sysreg(ctxt->sys_regs[AFSR1_EL1],	  afsr1_el1);
-	write_sysreg(ctxt->sys_regs[FAR_EL1],	  far_el1);
-	write_sysreg(ctxt->sys_regs[MAIR_EL1],	  mair_el1);
-	write_sysreg(ctxt->sys_regs[VBAR_EL1],	  vbar_el1);
-	write_sysreg(ctxt->sys_regs[CONTEXTIDR_EL1], contextidr_el1);
-	write_sysreg(ctxt->sys_regs[AMAIR_EL1],	  amair_el1);
-	write_sysreg(ctxt->sys_regs[CNTKCTL_EL1], cntkctl_el1);
-	write_sysreg(ctxt->sys_regs[PAR_EL1],	  par_el1);
-	write_sysreg(ctxt->sys_regs[MDSCR_EL1],	  mdscr_el1);
-
-	write_sysreg(ctxt->gp_regs.sp_el1,	sp_el1);
-	write_sysreg(ctxt->gp_regs.elr_el1,	elr_el1);
-	write_sysreg(ctxt->gp_regs.spsr[KVM_SPSR_EL1], spsr_el1);
+	write_sysreg(ctxt->sys_regs[MPIDR_EL1],		vmpidr_el2);
+	write_sysreg(ctxt->sys_regs[CSSELR_EL1],	csselr_el1);
+	write_sysreg_el1(ctxt->sys_regs[SCTLR_EL1],	sctlr);
+	write_sysreg_el1(ctxt->sys_regs[CPACR_EL1],	cpacr);
+	write_sysreg_el1(ctxt->sys_regs[TTBR0_EL1],	ttbr0);
+	write_sysreg_el1(ctxt->sys_regs[TTBR1_EL1],	ttbr1);
+	write_sysreg_el1(ctxt->sys_regs[TCR_EL1],	tcr);
+	write_sysreg_el1(ctxt->sys_regs[ESR_EL1],	esr);
+	write_sysreg_el1(ctxt->sys_regs[AFSR0_EL1],	afsr0);
+	write_sysreg_el1(ctxt->sys_regs[AFSR1_EL1],	afsr1);
+	write_sysreg_el1(ctxt->sys_regs[FAR_EL1],	far);
+	write_sysreg_el1(ctxt->sys_regs[MAIR_EL1],	mair);
+	write_sysreg_el1(ctxt->sys_regs[VBAR_EL1],	vbar);
+	write_sysreg_el1(ctxt->sys_regs[CONTEXTIDR_EL1],contextidr);
+	write_sysreg_el1(ctxt->sys_regs[AMAIR_EL1],	amair);
+	write_sysreg_el1(ctxt->sys_regs[CNTKCTL_EL1], 	cntkctl);
+	write_sysreg(ctxt->sys_regs[PAR_EL1],		par_el1);
+	write_sysreg(ctxt->sys_regs[MDSCR_EL1],		mdscr_el1);
+
+	write_sysreg(ctxt->gp_regs.sp_el1,		sp_el1);
+	write_sysreg_el1(ctxt->gp_regs.elr_el1,		elr);
+	write_sysreg_el1(ctxt->gp_regs.spsr[KVM_SPSR_EL1],spsr);
 }
 
 void __hyp_text __sysreg_restore_host_state(struct kvm_cpu_context *ctxt)
-- 
2.1.4



From marc.zyngier at arm.com  Thu Feb 11 10:39:57 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 18:39:57 +0000
Subject: [PATCH v4 16/23] arm64: KVM: VHE: Use unified sysreg accessors for
 timer
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455216004-19499-17-git-send-email-marc.zyngier@arm.com>

Switch the timer code to the unified sysreg accessors.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/timer-sr.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kvm/hyp/timer-sr.c b/arch/arm64/kvm/hyp/timer-sr.c
index 1051e5d..f276d9e 100644
--- a/arch/arm64/kvm/hyp/timer-sr.c
+++ b/arch/arm64/kvm/hyp/timer-sr.c
@@ -31,12 +31,12 @@ void __hyp_text __timer_save_state(struct kvm_vcpu *vcpu)
 	u64 val;
 
 	if (kvm->arch.timer.enabled) {
-		timer->cntv_ctl = read_sysreg(cntv_ctl_el0);
-		timer->cntv_cval = read_sysreg(cntv_cval_el0);
+		timer->cntv_ctl = read_sysreg_el0(cntv_ctl);
+		timer->cntv_cval = read_sysreg_el0(cntv_cval);
 	}
 
 	/* Disable the virtual timer */
-	write_sysreg(0, cntv_ctl_el0);
+	write_sysreg_el0(0, cntv_ctl);
 
 	/* Allow physical timer/counter access for the host */
 	val = read_sysreg(cnthctl_el2);
@@ -64,8 +64,8 @@ void __hyp_text __timer_restore_state(struct kvm_vcpu *vcpu)
 
 	if (kvm->arch.timer.enabled) {
 		write_sysreg(kvm->arch.timer.cntvoff, cntvoff_el2);
-		write_sysreg(timer->cntv_cval, cntv_cval_el0);
+		write_sysreg_el0(timer->cntv_cval, cntv_cval);
 		isb();
-		write_sysreg(timer->cntv_ctl, cntv_ctl_el0);
+		write_sysreg_el0(timer->cntv_ctl, cntv_ctl);
 	}
 }
-- 
2.1.4



From tn at semihalf.com  Thu Feb 11 10:46:22 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Thu, 11 Feb 2016 19:46:22 +0100
Subject: [PATCH V4 22/23] arm64, pci, acpi: Assign legacy IRQs once device
 is enable.
In-Reply-To: <20160211115843.GA24136@red-moon>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
 <1454606941-9523-23-git-send-email-tn@semihalf.com>
 <20160211115843.GA24136@red-moon>
Message-ID: <56BCD6FE.4030107@semihalf.com>

On 11.02.2016 12:58, Lorenzo Pieralisi wrote:
> As for the MSI check, by reading commit history its need I think
> it harks back to bba6f6fc, which was supposed to be a quick hack and it
> has been in the kernel for 9 years:), is it really needed ?

IMO, yes it is needed. We need to chose MSI vs IRQ, and MSI is 
preferable option.

Tomasz


From tony at atomide.com  Thu Feb 11 10:52:01 2016
From: tony at atomide.com (Tony Lindgren)
Date: Thu, 11 Feb 2016 10:52:01 -0800
Subject: [PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred
 probe for pm_runtime_reinit
In-Reply-To: <20160211183640.GB1953@sirena.org.uk>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-4-git-send-email-tony@atomide.com>
 <20160211115128.GF13270@sirena.org.uk>
 <20160211150806.GS19432@atomide.com>
 <20160211155255.GA1953@sirena.org.uk>
 <20160211173620.GU19432@atomide.com>
 <20160211183640.GB1953@sirena.org.uk>
Message-ID: <20160211185201.GX19432@atomide.com>

* Mark Brown <broonie at kernel.org> [160211 10:38]:
> On Thu, Feb 11, 2016 at 09:36:20AM -0800, Tony Lindgren wrote:
> > * Mark Brown <broonie at kernel.org> [160211 07:54]:
> 
> > > This does sound like there's been a change in the interface compared to
> > > what users are actually doing - is this an actual problem or is it just
> > > a divergence from docs?
> 
> > It's an actual problem at least on omaps as the omap_device code
> > is very picky about the hardware state.
> 
> > Depending how the PM runtime is implemented, it may be a problem
> > for some other cases too.
> 
> Or people just aren't testing mainline that well (if this is broken in
> v4.5 that suggests nobody noticed in -next) - do you know when this
> broke?  It really seems like we may need to spin round on how this is
> deployed.

I noticed it only with v4.5-rc1 and bisected it to commit 5de85b9d57ab
("PM / runtime: Re-init runtime PM states at probe error and driver
unbind") as it broke my PM tests for n900. For Linux next probably
was also broken for before that for some time.

Unfortunately based on the regressions I'm chasing every merge window
I'm suspecting that very few people are actually testing PM runtime
with mainline Linux kernel. Or they don't have the PM runtime fully
implemented in the mainline kernel for their devices. This is at
least for the SoC PM use case.

Ulf is working on a generic PM runtime test driver :) I'm hoping we
can then use that for basic regression testing on in an arch
independent way.

Regards,

Tony



From monstr at monstr.eu  Thu Feb 11 10:58:19 2016
From: monstr at monstr.eu (Michal Simek)
Date: Thu, 11 Feb 2016 19:58:19 +0100
Subject: [PATCH 3/3] ARM64: zynqmp: Use 64bit size cell format
In-Reply-To: <CAL_JsqK0=LaXqJyr_rGKCzGgt5kFy79-4ARocTGpKved3JU-Ug@mail.gmail.com>
References: <2f160e012080d5d6de11238ade239bb0bb224f64.1455193571.git.michal.simek@xilinx.com>
 <36fb9c4c9b2019b854e84dc0a9a01252a6de2337.1455193571.git.michal.simek@xilinx.com>
 <CAL_JsqK0=LaXqJyr_rGKCzGgt5kFy79-4ARocTGpKved3JU-Ug@mail.gmail.com>
Message-ID: <56BCD9CB.9030803@monstr.eu>

Hi Rob,

On 11.2.2016 17:13, Rob Herring wrote:
> On Thu, Feb 11, 2016 at 6:26 AM, Michal Simek <michal.simek at xilinx.com> wrote:
>> Use 64bit size cell format instead of 32bit for memory
>> description. Change 64bit sizes also for all others IPs.
> 
> Why? As is, this change is completely pointless because nothing needs
> a >4GB size. Do you have peripherals with >4GB size?

The change I need to do is to support more than 4GB memory. Memory space
is divided to some parts. 2GB connected to hard part below 4GB. There
there is 1GB connected to PL part below. Then 32GB hard part above of
4GB and a lot of space for PL part (~230GB).

PCIe can also address more than 256GB.

That's why I stand before decision. Change size-cell for all IPs which
are currently listed. Or just change it for memory node which is listed
in mainline.
I am not quite sure how PCIe description will look like and if there is
any other IP which will required on current buses use sizes more that
4GB. That's why I have change all sizes to support more than 4GB.

But definitely current need is to support more than 4GB memory size and
I have no problem to use not empty ranges property and keep there
#size-cells = <1>;

Both solution works for me. Definitely thank you for your comments.

Thanks,
Michal


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160211/4e1ce5ef/attachment.sig>

From christoffer.dall at linaro.org  Thu Feb 11 11:07:01 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Thu, 11 Feb 2016 20:07:01 +0100
Subject: [PATCH v4 00/23] arm64: Virtualization Host Extension support
In-Reply-To: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160211190701.GA4842@cbox>

On Thu, Feb 11, 2016 at 06:39:41PM +0000, Marc Zyngier wrote:
> ARMv8.1 comes with the "Virtualization Host Extension" (VHE for
> short), which enables simpler support of Type-2 hypervisors.
> 
> This extension allows the kernel to directly run at EL2, and
> significantly reduces the number of system registers shared between
> host and guest, reducing the overhead of virtualization.
> 
> In order to have the same kernel binary running on all versions of the
> architecture, this series makes heavy use of runtime code patching.
> 
> The first 22 patches massage the KVM code to deal with VHE and enable
> Linux to run at EL2. The last patch catches an ugly case when VHE
> capable CPUs are paired with some of their less capable siblings. This
> should never happen, but hey...
> 
> I have deliberately left out some of the more "advanced"
> optimizations, as they are likely to distract the reviewer from the
> core infrastructure, which is what I care about at the moment.
> 
> Note: GDB is currently busted on VHE systems, as it checks for version
>       6 on the debug architecture, while VHE is version 7. The
>       binutils people are on the case.
> 
> This has been tested on the FVP_Base_SLV-V8-A model, and based on
> v4.5-rc3 + kvmarm/master. I've put a branch out on:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/vhe

I'm happy with this series as it stands, we just need someone to take a
look at that debug patch and be happy with it.

Thanks,
-Christoffer


From kirill at shutemov.name  Thu Feb 11 11:09:42 2016
From: kirill at shutemov.name (Kirill A. Shutemov)
Date: Thu, 11 Feb 2016 21:09:42 +0200
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160211192223.4b517057@thinkpad>
References: <20160211192223.4b517057@thinkpad>
Message-ID: <20160211190942.GA10244@node.shutemov.name>

On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> Hi,
> 
> Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
> review of the THP rework patches, which cannot be bisected, revealed
> commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
> (and also similar commits for other archs).
> 
> This commit removes the THP splitting bit and also the architecture
> implementation of pmdp_splitting_flush(), which took care of the IPI for
> fast_gup serialization. The commit message says
> 
>     pmdp_splitting_flush() is not needed too: on splitting PMD we will do
>     pmdp_clear_flush() + set_pte_at().  pmdp_clear_flush() will do IPI as
>     needed for fast_gup
> 
> The assumption that a TLB flush will also produce an IPI is wrong on s390,
> and maybe also on other architectures, and I thought that this was actually
> the main reason for having an arch-specific pmdp_splitting_flush().
> 
> At least PowerPC and ARM also had an individual implementation of
> pmdp_splitting_flush() that used kick_all_cpus_sync() instead of a TLB
> flush to send the IPI, and those were also removed. Putting the arch
> maintainers and mailing lists on cc to verify.
> 
> On s390 this will break the IPI serialization against fast_gup, which
> would certainly explain the random kernel crashes, please revert or fix
> the pmdp_splitting_flush() removal.

Sorry for that.

I believe, the problem was already addressed for PowerPC:

http://lkml.kernel.org/g/454980831-16631-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com

I think kick_all_cpus_sync() in arch-specific pmdp_invalidate() would do
the trick, right?

If yes, I'll prepare patch tomorrow (some sleep required).

-- 
 Kirill A. Shutemov


From marc.zyngier at arm.com  Thu Feb 11 11:10:50 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 11 Feb 2016 19:10:50 +0000
Subject: [PATCH v4 00/23] arm64: Virtualization Host Extension support
In-Reply-To: <20160211190701.GA4842@cbox>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
 <20160211190701.GA4842@cbox>
Message-ID: <56BCDCBA.5080202@arm.com>

On 11/02/16 19:07, Christoffer Dall wrote:
> On Thu, Feb 11, 2016 at 06:39:41PM +0000, Marc Zyngier wrote:
>> ARMv8.1 comes with the "Virtualization Host Extension" (VHE for
>> short), which enables simpler support of Type-2 hypervisors.
>>
>> This extension allows the kernel to directly run at EL2, and
>> significantly reduces the number of system registers shared between
>> host and guest, reducing the overhead of virtualization.
>>
>> In order to have the same kernel binary running on all versions of the
>> architecture, this series makes heavy use of runtime code patching.
>>
>> The first 22 patches massage the KVM code to deal with VHE and enable
>> Linux to run at EL2. The last patch catches an ugly case when VHE
>> capable CPUs are paired with some of their less capable siblings. This
>> should never happen, but hey...
>>
>> I have deliberately left out some of the more "advanced"
>> optimizations, as they are likely to distract the reviewer from the
>> core infrastructure, which is what I care about at the moment.
>>
>> Note: GDB is currently busted on VHE systems, as it checks for version
>>       6 on the debug architecture, while VHE is version 7. The
>>       binutils people are on the case.
>>
>> This has been tested on the FVP_Base_SLV-V8-A model, and based on
>> v4.5-rc3 + kvmarm/master. I've put a branch out on:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/vhe
> 
> I'm happy with this series as it stands, we just need someone to take a
> look at that debug patch and be happy with it.

I think Will is planning to have a go at it shortly. Once he and Catalin
are happy with the thing, I'll throw it into -next for a good shake.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From kirill.shutemov at linux.intel.com  Thu Feb 11 11:12:53 2016
From: kirill.shutemov at linux.intel.com (Kirill A. Shutemov)
Date: Thu, 11 Feb 2016 22:12:53 +0300
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160211190942.GA10244@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
Message-ID: <20160211191253.GA8589@black.fi.intel.com>

On Thu, Feb 11, 2016 at 09:09:42PM +0200, Kirill A. Shutemov wrote:
> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > Hi,
> > 
> > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> > he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
> > review of the THP rework patches, which cannot be bisected, revealed
> > commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
> > (and also similar commits for other archs).
> > 
> > This commit removes the THP splitting bit and also the architecture
> > implementation of pmdp_splitting_flush(), which took care of the IPI for
> > fast_gup serialization. The commit message says
> > 
> >     pmdp_splitting_flush() is not needed too: on splitting PMD we will do
> >     pmdp_clear_flush() + set_pte_at().  pmdp_clear_flush() will do IPI as
> >     needed for fast_gup
> > 
> > The assumption that a TLB flush will also produce an IPI is wrong on s390,
> > and maybe also on other architectures, and I thought that this was actually
> > the main reason for having an arch-specific pmdp_splitting_flush().
> > 
> > At least PowerPC and ARM also had an individual implementation of
> > pmdp_splitting_flush() that used kick_all_cpus_sync() instead of a TLB
> > flush to send the IPI, and those were also removed. Putting the arch
> > maintainers and mailing lists on cc to verify.
> > 
> > On s390 this will break the IPI serialization against fast_gup, which
> > would certainly explain the random kernel crashes, please revert or fix
> > the pmdp_splitting_flush() removal.
> 
> Sorry for that.
> 
> I believe, the problem was already addressed for PowerPC:
> 
> http://lkml.kernel.org/g/454980831-16631-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com

Correct link is

http://lkml.kernel.org/g/1454980831-16631-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com

-- 
 Kirill A. Shutemov


From paul at pwsan.com  Thu Feb 11 11:27:07 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Thu, 11 Feb 2016 19:27:07 +0000 (UTC)
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <56BACCDB.2070507@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com> <56BACCDB.2070507@ti.com>
Message-ID: <alpine.DEB.2.02.1602111921090.20757@utopia.booyaka.com>

Hi Kishon, Suman,

On Wed, 10 Feb 2016, Kishon Vijay Abraham I wrote:

> On Wednesday 10 February 2016 07:12 AM, Suman Anna wrote:
> > On 02/09/2016 01:36 PM, Paul Walmsley wrote:
> >> On Tue, 9 Feb 2016, Suman Anna wrote:
> >>> On 02/09/2016 02:49 AM, Paul Walmsley wrote:
> >>>> On Mon, 8 Feb 2016, Suman Anna wrote:
> >>>>> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
> >>>>>> On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:
> >>>>>>
> >>>>>>> Paul, what do you think is the best way forward to perform reset?
> >>>>>>
> >>>>>> Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
> >>>>>> Those often need special reset handling to ensure that WFI/HLT-like 
> >>>>>> instructions are executed after reset.  This special handling ensures that 
> >>>>>> the IP blocks' bus initiator interfaces indicate that they are in standby 
> >>>>>> to the PRCM - thus allowing power management for the rest of the chip to 
> >>>>>> work correctly.
> >>>>>>
> >>>>>> But that doesn't seem to be the case with PCIe - and maybe others - 
> >>>>>> possibly some of the MMUs?  
> >>>>>
> >>>>> Yeah, the sequencing between clocks and resets would still be the same
> >>>>> for MMUs, so, adding the custom flags for MMUs is fine.
> >>>>
> >>>> I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs.  
> >>>> We've stated that the main point of the custom hardreset code is to handle 
> >>>> processors that need to be placed into WFI/HLT, but it doesn't seem like 
> >>>> there would be an equivalent for MMUs.  Thoughts?
> >>>
> >>> The current OMAP IOMMU code already leverages the pdata ops for
> >>> performing the resets, so not adding the flags would also require
> >>> additional changes in the driver.
> >>>
> >>> Also, the reset lines controlling the MMUs actually also manage the
> >>> reset for all the other sub-modules other than the processor cores
> >>> within the sub-systems. We have currently different issues (see [1] for
> >>> eg. around the IPU sub-system entering RET in between), so from a PM
> >>> point of view, we do prefer to place the MMUs also in reset when we are
> >>> runtime suspended.
> >>
> >> Should we reassert hardreset in _idle() for IP blocks that don't have 
> >> HWMOD_CUSTOM_HARDRESET set on them?  Would that allow us to use this 
> >> mechanism for the uncore hardreset lines, or are there other quirks?
> >>
> >> Also - would that address the potential issue that you mentioned with the 
> >> PCIe block, or is that a different issue?
> > 
> > Yeah, I think that would address the PCIe block issue in terms of reset
> > state balancing between pm_runtime_get_sync() and pm_runtime_put()
> > calls. Right now, they are unbalanced. The PCIe block is using these
> > only in probe and remove, so it should work for that IP.
> 
> As I mentioned before this would result in undesired behavior during
> suspend/resume cycle in PCIe. (This should be okay for the current mainline
> code but would break once we add suspend/resume support for PCIe).

I'd like to understand where we're currently at here.  It looks like we're 
waiting for testing from Suman, and we're waiting for Kishon to try using 
the bind/unbind driver model hook to see if that wedges PCIe?  Does this 
match your collective understanding of the status here?

Thinking about the question of what to do about hardreset assertion in 
idle, if we need it, we could add a hwmod flag to control that mode.  I 
would consider it a temporary workaround until we have the hwmod code 
moved into a bus driver and the bus driver/hwmod code can hook into the 
LDM .remove operation (and connect it to .shutdown, etc.)  Suman/Kishon: 
is it your understanding that we could remove the existing hardreset 
control in the IOMMU drivers and the PCIe driver if we had these options 
in the hwmod code? 

Dave, any further comments here?


- Paul


From robh+dt at kernel.org  Thu Feb 11 11:49:58 2016
From: robh+dt at kernel.org (Rob Herring)
Date: Thu, 11 Feb 2016 13:49:58 -0600
Subject: [PATCH 3/3] ARM64: zynqmp: Use 64bit size cell format
In-Reply-To: <56BCD9CB.9030803@monstr.eu>
References: <2f160e012080d5d6de11238ade239bb0bb224f64.1455193571.git.michal.simek@xilinx.com>
 <36fb9c4c9b2019b854e84dc0a9a01252a6de2337.1455193571.git.michal.simek@xilinx.com>
 <CAL_JsqK0=LaXqJyr_rGKCzGgt5kFy79-4ARocTGpKved3JU-Ug@mail.gmail.com>
 <56BCD9CB.9030803@monstr.eu>
Message-ID: <CAL_JsqJPXvz_9GFtNyN024+GD=iBHARCb=VdSi_36GjMWe=CnA@mail.gmail.com>

On Thu, Feb 11, 2016 at 12:58 PM, Michal Simek <monstr at monstr.eu> wrote:
> Hi Rob,
>
> On 11.2.2016 17:13, Rob Herring wrote:
>> On Thu, Feb 11, 2016 at 6:26 AM, Michal Simek <michal.simek at xilinx.com> wrote:
>>> Use 64bit size cell format instead of 32bit for memory
>>> description. Change 64bit sizes also for all others IPs.
>>
>> Why? As is, this change is completely pointless because nothing needs
>> a >4GB size. Do you have peripherals with >4GB size?
>
> The change I need to do is to support more than 4GB memory. Memory space
> is divided to some parts. 2GB connected to hard part below 4GB. There
> there is 1GB connected to PL part below. Then 32GB hard part above of
> 4GB and a lot of space for PL part (~230GB).
>
> PCIe can also address more than 256GB.

So I would expect some amount of the bus structure to be reflected in
the DT. For example, hard and PL IP are probably in separate address
ranges. I'd guess PL bus has additional logic to enable/disable it for
reprogramming, so you'd need a different bus node anyway. For PCIe,
it's probably its own bus too.

> That's why I stand before decision. Change size-cell for all IPs which
> are currently listed. Or just change it for memory node which is listed
> in mainline.
> I am not quite sure how PCIe description will look like and if there is
> any other IP which will required on current buses use sizes more that
> 4GB. That's why I have change all sizes to support more than 4GB.
>
> But definitely current need is to support more than 4GB memory size and
> I have no problem to use not empty ranges property and keep there
> #size-cells = <1>;

Then why aren't you adding to the memory? (the bootloader sets the
actual size is a valid answer)

> Both solution works for me. Definitely thank you for your comments.

Either way, I'd change this when you actually need the change, not by itself.

Rob


From gerald.schaefer at de.ibm.com  Thu Feb 11 11:57:02 2016
From: gerald.schaefer at de.ibm.com (Gerald Schaefer)
Date: Thu, 11 Feb 2016 20:57:02 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe
 also on PowerPC and ARM)
In-Reply-To: <20160211190942.GA10244@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
Message-ID: <20160211205702.24f0d17a@thinkpad>

On Thu, 11 Feb 2016 21:09:42 +0200
"Kirill A. Shutemov" <kirill at shutemov.name> wrote:

> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > Hi,
> > 
> > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> > he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
> > review of the THP rework patches, which cannot be bisected, revealed
> > commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
> > (and also similar commits for other archs).
> > 
> > This commit removes the THP splitting bit and also the architecture
> > implementation of pmdp_splitting_flush(), which took care of the IPI for
> > fast_gup serialization. The commit message says
> > 
> >     pmdp_splitting_flush() is not needed too: on splitting PMD we will do
> >     pmdp_clear_flush() + set_pte_at().  pmdp_clear_flush() will do IPI as
> >     needed for fast_gup
> > 
> > The assumption that a TLB flush will also produce an IPI is wrong on s390,
> > and maybe also on other architectures, and I thought that this was actually
> > the main reason for having an arch-specific pmdp_splitting_flush().
> > 
> > At least PowerPC and ARM also had an individual implementation of
> > pmdp_splitting_flush() that used kick_all_cpus_sync() instead of a TLB
> > flush to send the IPI, and those were also removed. Putting the arch
> > maintainers and mailing lists on cc to verify.
> > 
> > On s390 this will break the IPI serialization against fast_gup, which
> > would certainly explain the random kernel crashes, please revert or fix
> > the pmdp_splitting_flush() removal.
> 
> Sorry for that.
> 
> I believe, the problem was already addressed for PowerPC:
> 
> http://lkml.kernel.org/g/454980831-16631-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com
> 
> I think kick_all_cpus_sync() in arch-specific pmdp_invalidate() would do
> the trick, right?

Hmm, not sure about that. After pmdp_invalidate(), a pmd_none() check in
fast_gup will still return false, because the pmd is not empty (at least
on s390). So I don't see spontaneously how it will help fast_gup to break
out to the slow path in case of THP splitting.

> 
> If yes, I'll prepare patch tomorrow (some sleep required).
> 

We'll check if adding kick_all_cpus_sync() to pmdp_invalidate() helps.
It would also be good if Martin has a look at this, he'll return on
Monday.



From f.fainelli at gmail.com  Thu Feb 11 12:01:53 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Thu, 11 Feb 2016 12:01:53 -0800
Subject: [PATCH v2 3/3] ARM: dts: enable GPIO-a for Broadcom NSP
In-Reply-To: <1449249162-16850-1-git-send-email-yrdreddy@broadcom.com>
References: <1449249162-16850-1-git-send-email-yrdreddy@broadcom.com>
Message-ID: <56BCE8B1.2060900@gmail.com>

On 04/12/15 09:12, Yendapally Reddy Dhananjaya Reddy wrote:
> This enables the GPIO-a support for Broadcom NSP SoC
> 
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yrdreddy at broadcom.com>

Finally applied to devicetree/next, since there was a bit of
restructuring with the addition of the ranges, please verify the results
look correct here:

https://github.com/Broadcom/stblinux/commit/018e4feb7584971b3dbda6daa6a8fef310cafbcb

> ---
>  arch/arm/boot/dts/bcm-nsp.dtsi | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
> index 58aca27..148d79e 100644
> --- a/arch/arm/boot/dts/bcm-nsp.dtsi
> +++ b/arch/arm/boot/dts/bcm-nsp.dtsi
> @@ -116,4 +116,16 @@
>  			status = "disabled";
>  		};
>  	};
> +
> +	gpioa: gpio at 18000020 {
> +		compatible = "brcm,nsp-gpio-a";
> +		reg = <0x18000020 0x70>,
> +		      <0x1803f1c4 0x1c>;
> +		#gpio-cells = <2>;
> +		gpio-controller;
> +		ngpios = <32>;
> +		interrupt-controller;
> +		interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
> +		gpio-ranges = <&pinctrl 0 0 32>;
> +	};
>  };
> 


-- 
Florian


From michal.simek at xilinx.com  Thu Feb 11 12:15:55 2016
From: michal.simek at xilinx.com (Michal Simek)
Date: Thu, 11 Feb 2016 21:15:55 +0100
Subject: [PATCH 3/3] ARM64: zynqmp: Use 64bit size cell format
In-Reply-To: <CAL_JsqJPXvz_9GFtNyN024+GD=iBHARCb=VdSi_36GjMWe=CnA@mail.gmail.com>
References: <2f160e012080d5d6de11238ade239bb0bb224f64.1455193571.git.michal.simek@xilinx.com>
 <36fb9c4c9b2019b854e84dc0a9a01252a6de2337.1455193571.git.michal.simek@xilinx.com>
 <CAL_JsqK0=LaXqJyr_rGKCzGgt5kFy79-4ARocTGpKved3JU-Ug@mail.gmail.com>
 <56BCD9CB.9030803@monstr.eu>
 <CAL_JsqJPXvz_9GFtNyN024+GD=iBHARCb=VdSi_36GjMWe=CnA@mail.gmail.com>
Message-ID: <56BCEBFB.3070209@xilinx.com>

Hi Rob,

On 11.2.2016 20:49, Rob Herring wrote:
> On Thu, Feb 11, 2016 at 12:58 PM, Michal Simek <monstr at monstr.eu> wrote:
>> Hi Rob,
>>
>> On 11.2.2016 17:13, Rob Herring wrote:
>>> On Thu, Feb 11, 2016 at 6:26 AM, Michal Simek <michal.simek at xilinx.com> wrote:
>>>> Use 64bit size cell format instead of 32bit for memory
>>>> description. Change 64bit sizes also for all others IPs.
>>>
>>> Why? As is, this change is completely pointless because nothing needs
>>> a >4GB size. Do you have peripherals with >4GB size?
>>
>> The change I need to do is to support more than 4GB memory. Memory space
>> is divided to some parts. 2GB connected to hard part below 4GB. There
>> there is 1GB connected to PL part below. Then 32GB hard part above of
>> 4GB and a lot of space for PL part (~230GB).
>>
>> PCIe can also address more than 256GB.
> 
> So I would expect some amount of the bus structure to be reflected in
> the DT. For example, hard and PL IP are probably in separate address
> ranges. I'd guess PL bus has additional logic to enable/disable it for
> reprogramming, so you'd need a different bus node anyway. For PCIe,
> it's probably its own bus too.

As you see right now there is separation already.

> 
>> That's why I stand before decision. Change size-cell for all IPs which
>> are currently listed. Or just change it for memory node which is listed
>> in mainline.
>> I am not quite sure how PCIe description will look like and if there is
>> any other IP which will required on current buses use sizes more that
>> 4GB. That's why I have change all sizes to support more than 4GB.
>>
>> But definitely current need is to support more than 4GB memory size and
>> I have no problem to use not empty ranges property and keep there
>> #size-cells = <1>;
> 
> Then why aren't you adding to the memory? (the bootloader sets the
> actual size is a valid answer)

I am not fully convinced about it. Bootloader can set it up but there
shouldn't be dependency on bootloader capability that it will do it.
Also you don't need to use fully featured bootloader for doing that.
It means that for board dtses make sense to fill memory node with
correct values. If bootloader is capable to rewrite it/fix it, then it
is fine. If not, you can use let's say default values.

Also the second part of the problem is. You have bootloader which is
aware about that you have 34GB of memory in two banks. 2GB below 4GB
limit and 32GB above. But if bootloader starts to rewrite memory node
where #size-cell = <1> with 32GB size it will probably messes it up.

That's why I see the value to setup size-cells = <2>; earlier rather
than later.
IRC someone mentioning that in past when I was pushing zynqmp DTS that
we should use #size-cells = <2>;

>> Both solution works for me. Definitely thank you for your comments.
> 
> Either way, I'd change this when you actually need the change, not by itself.

ok. Fair enough. I need this for at least memory node because boards are
using the same zynqmp.dtsi files. For all other buses I have no problem
to keep just size-cells = <1>; and setup ranges to make dtc happy.

Thanks,
Michal


From sergei.shtylyov at cogentembedded.com  Thu Feb 11 12:26:38 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 11 Feb 2016 23:26:38 +0300
Subject: [PATCH] ARM: dts: silk: add sound support
In-Reply-To: <1674850.BZpGW9kEud@wasted.cogentembedded.com>
References: <1674850.BZpGW9kEud@wasted.cogentembedded.com>
Message-ID: <4246644.0ZLx3MiCIL@wasted.cogentembedded.com>

Define the SILK board dependent part of the R8A7794 sound  device node.
Add device node for Asahi Kasei AK4643 stereo codec to the I2C1 bus.
Add the "simple-audio-card" device node to interconnect the SoC sound
device  and the codec.

This patch is based on the commit 493b4da7c10c ("ARM: dts: porter: add
sound support").

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
This patch is against the 'renesas-devel-20160209-v4.5-rc3' tag of Simon
Horman's 'renesas.git' repo. It depends on the 5 R8A7794 sound support patches
in posted earlier this week  in order to build and the R8A7794 PFC driver
patches posted yesterday in  order  for  the pins to be properly configured
(but works without the pins  configured  too)...

 arch/arm/boot/dts/r8a7794-silk.dts |   71 +++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7794-silk.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7794-silk.dts
+++ renesas/arch/arm/boot/dts/r8a7794-silk.dts
@@ -10,6 +10,17 @@
  * kind, whether express or implied.
  */
 
+/*
+ * SSI-AK4643
+ *
+ * SW1: 2-1: AK4643
+ *      2-3: ADV7511
+ *
+ * This command is required before playback/capture:
+ *
+ *	amixer set "LINEOUT Mixer DACL" on
+ */
+
 /dts-v1/;
 #include "r8a7794.dtsi"
 #include <dt-bindings/gpio/gpio.h>
@@ -119,6 +130,30 @@
 		#clock-cells = <0>;
 		clock-frequency = <74250000>;
 	};
+
+	x9_clk: x9-clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <12288000>;
+		clock-output-names = "audio_clock";
+	};
+
+	sound {
+		compatible = "simple-audio-card";
+
+		simple-audio-card,format = "left_j";
+		simple-audio-card,bitclock-master = <&soundcodec>;
+		simple-audio-card,frame-master = <&soundcodec>;
+
+		simple-audio-card,cpu {
+			sound-dai = <&rcar_sound>;
+		};
+
+		soundcodec: simple-audio-card,codec {
+			sound-dai = <&ak4643>;
+			clocks = <&x9_clk>;
+		};
+	};
 };
 
 &extal_clk {
@@ -183,6 +218,16 @@
 		renesas,groups = "usb1";
 		renesas,function = "usb1";
 	};
+
+	ssi_pins: sound {
+		renesas,groups = "ssi0129_ctrl", "ssi0_data", "ssi1_data";
+		renesas,function = "ssi";
+	};
+
+	audio_clk_pins: audio_clk {
+		renesas,groups = "audio_clkc";
+		renesas,function = "audio_clk";
+	};
 };
 
 &scif2 {
@@ -220,6 +265,12 @@
 	status = "okay";
 	clock-frequency = <400000>;
 
+	ak4643: codec at 12 {
+		compatible = "asahi-kasei,ak4643";
+		#sound-dai-cells = <0>;
+		reg = <0x12>;
+	};
+
 	composite-in at 20 {
 		compatible = "adi,adv7180";
 		reg = <0x20>;
@@ -380,3 +431,23 @@
 		};
 	};
 };
+
+&rcar_sound {
+	pinctrl-0 = <&ssi_pins &audio_clk_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	/* Single DAI */
+	#sound-dai-cells = <0>;
+
+	rcar_sound,dai {
+		dai0 {
+			playback = <&ssi0>;
+			capture  = <&ssi1>;
+		};
+	};
+};
+
+&ssi1 {
+	shared-pin;
+};



From laurent.pinchart at ideasonboard.com  Thu Feb 11 12:39:03 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 11 Feb 2016 22:39:03 +0200
Subject: [PATCH 4/3] iommu/io-pgtable: Rationalise quirk handling
In-Reply-To: <ea1f3d3feec0dc9c18d43393678370b50b1275f5.1455206840.git.robin.murphy@arm.com>
References: <cover.1453723096.git.robin.murphy@arm.com>
 <20160210154815.GO1052@arm.com>
 <ea1f3d3feec0dc9c18d43393678370b50b1275f5.1455206840.git.robin.murphy@arm.com>
Message-ID: <8742562.HTCU9VW42O@avalon>

Hi Robin,

Thank you for the patch.

On Thursday 11 February 2016 16:13:45 Robin Murphy wrote:
> As the number of io-pgtable implementations grows beyond 1, it's time
> to rationalise the quirks mechanism before things have a chance to
> start getting really ugly and out-of-hand.
> 
> To that end:
> - Indicate exactly which quirks each format can/does support.
> - Fail creating a table if a caller wants unsupported quirks.
> - Properly document where each quirk applies and why.
> 
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> ---
>  drivers/iommu/io-pgtable-arm-v7s.c |  3 +++
>  drivers/iommu/io-pgtable-arm.c     |  2 ++
>  drivers/iommu/io-pgtable.c         |  3 +++
>  drivers/iommu/io-pgtable.h         | 24 ++++++++++++++++++++----
>  4 files changed, 28 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
> b/drivers/iommu/io-pgtable-arm-v7s.c index d39a021..9bc607a 100644
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> @@ -690,6 +690,9 @@ out_free_data:
>  struct io_pgtable_init_fns io_pgtable_arm_v7s_init_fns = {
>  	.alloc	= arm_v7s_alloc_pgtable,
>  	.free	= arm_v7s_free_pgtable,
> +	.supported_quirks = IO_PGTABLE_QUIRK_ARM_NS |
> +			    IO_PGTABLE_QUIRK_NO_PERMS |
> +			    IO_PGTABLE_QUIRK_TLBI_ON_MAP,
>  };
> 
>  #ifdef CONFIG_IOMMU_IO_PGTABLE_ARMV7S_SELFTEST
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 4095af2..32f94f1 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -863,6 +863,7 @@ arm_32_lpae_alloc_pgtable_s2(struct io_pgtable_cfg *cfg,
> void *cookie) struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s1_init_fns
> = { .alloc	= arm_64_lpae_alloc_pgtable_s1,
>  	.free	= arm_lpae_free_pgtable,
> +	.supported_quirks = IO_PGTABLE_QUIRK_ARM_NS,
>  };
> 
>  struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s2_init_fns = {
> @@ -873,6 +874,7 @@ struct io_pgtable_init_fns
> io_pgtable_arm_64_lpae_s2_init_fns = { struct io_pgtable_init_fns
> io_pgtable_arm_32_lpae_s1_init_fns = { .alloc	=
> arm_32_lpae_alloc_pgtable_s1,
>  	.free	= arm_lpae_free_pgtable,
> +	.supported_quirks = IO_PGTABLE_QUIRK_ARM_NS,
>  };
> 
>  struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s2_init_fns = {
> diff --git a/drivers/iommu/io-pgtable.c b/drivers/iommu/io-pgtable.c
> index 876f6a7..0f57a45 100644
> --- a/drivers/iommu/io-pgtable.c
> +++ b/drivers/iommu/io-pgtable.c
> @@ -52,6 +52,9 @@ struct io_pgtable_ops *alloc_io_pgtable_ops(enum
> io_pgtable_fmt fmt, if (!fns)
>  		return NULL;
> 
> +	if (cfg->quirks & ~fns->supported_quirks)
> +		return NULL;
> +
>  	iop = fns->alloc(cfg, cookie);
>  	if (!iop)
>  		return NULL;
> diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
> index 4faee7d..6e7f11e 100644
> --- a/drivers/iommu/io-pgtable.h
> +++ b/drivers/iommu/io-pgtable.h
> @@ -47,10 +47,24 @@ struct iommu_gather_ops {
>   *                 page table walker.
>   */
>  struct io_pgtable_cfg {
> -	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0) /* Set NS bit in PTEs */
> -	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1) /* No AP/XN bits */
> -	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2) /* TLB Inv. on map */
> -	int				quirks;
> +	/*
> +	 * IO_PGTABLE_QUIRK_ARM_NS: (ARM formats) Set NS and NSTABLE bits in
> +	 *	stage 1 PTEs, for hardware which insists on validating them
> +	 *	even in	non-secure state where they should normally be ignored.
> +	 *
> +	 * IO_PGTABLE_QUIRK_NO_PERMS: Ignore the IOMMU_READ, IOMMU_WRITE and
> +	 *	IOMMU_NOEXEC flags and map everything with full access, for
> +	 *	hardware which does not implement the permissions of a given
> +	 *	format, and/or requires some format-specific default value.
> +	 *
> +	 * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching invalid
> +	 *	(unmapped) entries but the hardware might do so anyway, perform
> +	 *	TLB maintenance when mapping as well as when unmapping.
> +	 */
> +	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
> +	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
> +	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2)
> +	unsigned int			quirks;
>  	unsigned long			pgsize_bitmap;
>  	unsigned int			ias;
>  	unsigned int			oas;
> @@ -173,10 +187,12 @@ static inline void io_pgtable_tlb_sync(struct
> io_pgtable *iop) *
>   * @alloc: Allocate a set of page tables described by cfg.
>   * @free:  Free the page tables associated with iop.
> + * @supported_quirks: Bitmap of quirks supported by the format.
>   */
>  struct io_pgtable_init_fns {
>  	struct io_pgtable *(*alloc)(struct io_pgtable_cfg *cfg, void *cookie);
>  	void (*free)(struct io_pgtable *iop);
> +	unsigned int supported_quirks;
>  };
> 
>  extern struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s1_init_fns;

-- 
Regards,

Laurent Pinchart



From s-anna at ti.com  Thu Feb 11 12:43:02 2016
From: s-anna at ti.com (Suman Anna)
Date: Thu, 11 Feb 2016 14:43:02 -0600
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <56BACCDB.2070507@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com> <56BACCDB.2070507@ti.com>
Message-ID: <56BCF256.8010903@ti.com>

On 02/09/2016 11:38 PM, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Wednesday 10 February 2016 07:12 AM, Suman Anna wrote:
>> Hi Paul,
>>
>> On 02/09/2016 01:36 PM, Paul Walmsley wrote:
>>> Hi Suman 
>>>
>>> On Tue, 9 Feb 2016, Suman Anna wrote:
>>>
>>>> On 02/09/2016 02:49 AM, Paul Walmsley wrote:
>>>>> On Mon, 8 Feb 2016, Suman Anna wrote:
>>>>>> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
>>>>>>> On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:
>>>>>>>
>>>>>>>> Paul, what do you think is the best way forward to perform reset?
>>>>>>>
>>>>>>> Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
>>>>>>> Those often need special reset handling to ensure that WFI/HLT-like 
>>>>>>> instructions are executed after reset.  This special handling ensures that 
>>>>>>> the IP blocks' bus initiator interfaces indicate that they are in standby 
>>>>>>> to the PRCM - thus allowing power management for the rest of the chip to 
>>>>>>> work correctly.
>>>>>>>
>>>>>>> But that doesn't seem to be the case with PCIe - and maybe others - 
>>>>>>> possibly some of the MMUs?  
>>>>>>
>>>>>> Yeah, the sequencing between clocks and resets would still be the same
>>>>>> for MMUs, so, adding the custom flags for MMUs is fine.
>>>>>
>>>>> I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs.  
>>>>> We've stated that the main point of the custom hardreset code is to handle 
>>>>> processors that need to be placed into WFI/HLT, but it doesn't seem like 
>>>>> there would be an equivalent for MMUs.  Thoughts?
>>>>
>>>> The current OMAP IOMMU code already leverages the pdata ops for
>>>> performing the resets, so not adding the flags would also require
>>>> additional changes in the driver.
>>>>
>>>> Also, the reset lines controlling the MMUs actually also manage the
>>>> reset for all the other sub-modules other than the processor cores
>>>> within the sub-systems. We have currently different issues (see [1] for
>>>> eg. around the IPU sub-system entering RET in between), so from a PM
>>>> point of view, we do prefer to place the MMUs also in reset when we are
>>>> runtime suspended.
>>>
>>> Should we reassert hardreset in _idle() for IP blocks that don't have 
>>> HWMOD_CUSTOM_HARDRESET set on them?  Would that allow us to use this 
>>> mechanism for the uncore hardreset lines, or are there other quirks?
>>>
>>> Also - would that address the potential issue that you mentioned with the 
>>> PCIe block, or is that a different issue?
>>
>> Yeah, I think that would address the PCIe block issue in terms of reset
>> state balancing between pm_runtime_get_sync() and pm_runtime_put()
>> calls. Right now, they are unbalanced. The PCIe block is using these
>> only in probe and remove, so it should work for that IP.
> 
> As I mentioned before this would result in undesired behavior during
> suspend/resume cycle in PCIe. (This should be okay for the current mainline
> code but would break once we add suspend/resume support for PCIe).

Yeah, I was wondering if some peripheral would want only the clock to be
controlled during _idle() and not reset. Even then for the PCIe case
that you are talking about, going through a pm_runtime_get_sync(),
pm_runtime_put_sync()/pm_runtime_put() deasserts the resets everytime
_enable() is called. Right now, the code block has ignored the return
value from the _hardreset_deassert(), but if you check it and bail out,
then your get_sync() would start failing from the second invocation.

Can you elaborate more on what kind of issues you will see on
suspend/resume cycle with PCIe? Do note that _idle() gets called through
_od_suspend_no_irq() in omap_device.c if your runtime status is not
suspended. I had to manage the runtime status in the IPU/DSP
suspend/resume code to deal with the reset
(omap_device_assert_hardreset) and clock sequences in
_idle()/omap_device_idle()

regards
Suman


From rdunlap at infradead.org  Thu Feb 11 13:08:30 2016
From: rdunlap at infradead.org (Randy Dunlap)
Date: Thu, 11 Feb 2016 13:08:30 -0800
Subject: [PATCH v8 4/4] Documentation: tee subsystem and op-tee driver
In-Reply-To: <1455210877-15748-5-git-send-email-jens.wiklander@linaro.org>
References: <1455210877-15748-1-git-send-email-jens.wiklander@linaro.org>
 <1455210877-15748-5-git-send-email-jens.wiklander@linaro.org>
Message-ID: <56BCF84E.50808@infradead.org>

On 02/11/16 09:14, Jens Wiklander wrote:
> Signed-off-by: Jens Wiklander <jens.wiklander at linaro.org>
> ---
>  Documentation/00-INDEX |   2 +
>  Documentation/tee.txt  | 117 +++++++++++++++++++++++++++++++++++++++++++++++++
>  MAINTAINERS            |   1 +
>  3 files changed, 120 insertions(+)
>  create mode 100644 Documentation/tee.txt

> diff --git a/Documentation/tee.txt b/Documentation/tee.txt
> new file mode 100644
> index 0000000..4ac91d2
> --- /dev/null
> +++ b/Documentation/tee.txt
> @@ -0,0 +1,117 @@
> +TEE subsystem
> +This document describes the TEE subsystem in Linux

                                                Linux.

> +
> +A TEE (Trusted Execution Environment) is a trusted OS running in some
> +secure environment, for example, TrustZone on ARM CPUs, or a separate
> +secure co-processor etc. A TEE driver handles the details needed to
> +communicate with the TEE.
> +
> +This subsystem deals with:
> +
> +- Registration of TEE drivers
> +
> +- Managing shared memory between Linux and the TEE
> +
> +- Providing a generic API to the TEE
> +
> +The TEE interface
> +=================
> +
> +include/uapi/linux/tee.h defines the generic interface to a TEE.
> +
> +User space (the client) connects to the driver by opening /dev/tee[0-9]* or
> +/dev/teepriv[0-9]*.
> +
> +- TEE_IOC_SHM_ALLOC allocates shared memory and returns a file descriptor which
> +  user space can mmap. When user space doesn't need the file descriptor anymore

                                                                           any more,

> +  it should be closed. When shared memory isn't needed any longer it should be
> +  unmapped with munmap() to allow the reuse of memory.
> +
> +- TEE_IOC_VERSION lets user space know which TEE this driver handles and
> +  the its capabilities.
> +
> +- TEE_IOC_OPEN_SESSION opens a new session to a Trusted Application

end with '.'

> +
> +- TEE_IOC_INVOKE invokes a function in a Trusted Application

ditto

> +
> +- TEE_IOC_CANCEL may cancel an ongoing TEE_IOC_OPEN_SESSION or TEE_IOC_INVOKE

ditto

> +
> +- TEE_IOC_CLOSE_SESSION closes a session to a Trusted Application

ditto

> +
> +There are two classes of clients, normal clients and supplicants. The latter is
> +a helper process for the TEE to access resources in Linux, for example file
> +system access. A normal client opens /dev/tee[0-9]* and a supplicant opens
> +/dev/teepriv[0-9].
> +
> +Much of the communication between clients and the TEE is opaque to the
> +driver. The main job for the driver is to receive requests from the
> +clients, forward them to the TEE and send back the results. In the case of
> +supplicants the communication goes in the other direction, the TEE sends
> +requests to the supplicant which then sends back the result.
> +
> +OP-TEE driver
> +=============
> +
> +The OP-TEE driver handles OP-TEE [1] based TEEs. Currently it is only the ARM
> +TrustZone based OP-TEE solution that is supported.
> +
> +Lowest level of communication with OP-TEE builds on ARM SMC Calling
> +Convention (SMCCC) [2], which is the foundation for OP-TEE's SMC interface
> +[3] used internally by the driver. Stacked on top of that is OP-TEE Message
> +Protocol [4].
> +
> +OP-TEE SMC interface provides the basic functions required by SMCCC and some
> +additional functions specific for OP-TEE. The most interesting functions are:
> +
> +- OPTEE_SMC_FUNCID_CALLS_UID (part of SMCCC) returns the version information
> +  which is then returned by TEE_IOC_VERSION
> +
> +- OPTEE_SMC_CALL_GET_OS_UUID returns the particular OP-TEE implementation, used
> +  to tell, for instance, a TrustZone OP-TEE apart from an OP-TEE running on a
> +  separate secure co-processor.
> +
> +- OPTEE_SMC_CALL_WITH_ARG drives the OP-TEE message protocol
> +
> +- OPTEE_SMC_GET_SHM_CONFIG lets the driver and OP-TEE agree on which memory
> +  range to used for shared memory between Linux and OP-TEE.
> +
> +The GlobalPlatform TEE Client API [5] is implemented on top of the generic
> +TEE API.
> +
> +Picture of the relationship between the different components in the
> +OP-TEE architecture.
> +
> +    User space                  Kernel                   Secure world
> +    ~~~~~~~~~~                  ~~~~~~                   ~~~~~~~~~~~~
> + +--------+                                             +-------------+
> + | Client |                                             | Trusted     |
> + +--------+                                             | Application |
> +    /\                                                  +-------------+
> +    || +----------+                                           /\
> +    || |tee-      |                                           ||
> +    || |supplicant|                                           \/
> +    || +----------+                                     +-------------+
> +    \/      /\                                          | TEE Internal|
> + +-------+  ||                                          | API         |
> + + TEE   |  ||            +--------+--------+           +-------------+
> + | Client|  ||            | TEE    | OP-TEE |           | OP-TEE      |
> + | API   |  \/            | subsys | driver |           | Trusted OS  |
> + +-------+----------------+----+-------+----+-----------+-------------+
> + |      Generic TEE API        |       |     OP-TEE MSG               |
> + |      IOCTL (TEE_IOC_*)      |       |     SMCCC (OPTEE_SMC_CALL_*) |
> + +-----------------------------+       +------------------------------+
> +
> +RPC (Remote Procedure Call) are requests from secure world to kernel driver
> +or tee-supplicant. An RPC is identified by a special range of SMCCC return
> +values from OPTEE_SMC_CALL_WITH_ARG. RPC messages which are intended for the
> +kernel are handled by the kernel driver. Other RPC messages will be forwarded to
> +tee-supplicant without further involvement of the driver, except switching
> +shared memory buffer representation.
> +
> +References:
> +[1] https://github.com/OP-TEE/optee_os
> +[2] http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
> +[3] drivers/tee/optee/optee_smc.h
> +[4] drivers/tee/optee/optee_msg.h
> +[5] http://www.globalplatform.org/specificationsdevice.asp look for
> +    "TEE Client API Specification v1.0" and click download.


-- 
~Randy


From olof at lixom.net  Thu Feb 11 13:22:20 2016
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Feb 2016 13:22:20 -0800
Subject: [GIT PULL] Renesas ARM Based SoC DT Updates for v4.6
In-Reply-To: <20160211172218.GD12080@verge.net.au>
References: <cover.1454595846.git.horms+renesas@verge.net.au>
 <20160208215130.GJ25468@localhost>
 <CAMuHMdVWYVEHTvGYEZkEXpEaMzfZ_NfMAb0o8HtVcJM+GDdfmA@mail.gmail.com>
 <20160209183921.GA1089@verge.net.au>
 <CAOesGMjeyah0qpwWR=RJOF61dVGGqkxmGUJrE0qYNuCOwoPFjQ@mail.gmail.com>
 <20160211172218.GD12080@verge.net.au>
Message-ID: <CAOesGMhs=tN705VPB2CDvRKsahpKA6R8xoyjL+TPjSOEJLM0cQ@mail.gmail.com>

Simon,


On Thu, Feb 11, 2016 at 9:22 AM, Simon Horman <horms at verge.net.au> wrote:
> On Wed, Feb 10, 2016 at 07:55:30PM -0800, Olof Johansson wrote:
>> Hi,
>>
>> On Tue, Feb 9, 2016 at 10:39 AM, Simon Horman <horms at verge.net.au> wrote:
>> > On Tue, Feb 09, 2016 at 08:39:31AM +0100, Geert Uytterhoeven wrote:
>> >> Hi Olof,
>> >>
>> >> On Mon, Feb 8, 2016 at 10:51 PM, Olof Johansson <olof at lixom.net> wrote:
>> >> > On Thu, Feb 04, 2016 at 03:30:02PM +0100, Simon Horman wrote:
>> >> >> Please consider these Renesas ARM based SoC DT updates for v4.6.
>> >> >>
>> >> >>
>> >> >> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>> >> >>
>> >> >>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>> >> >>
>> >> >> are available in the git repository at:
>> >> >>
>> >> >>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-for-v4.6
>> >> >>
>> >> >> for you to fetch changes up to d7a11140d0a659e5c1f83627792f95b6713030a2:
>> >> >>
>> >> >>   ARM: dts: silk: Enable SCIF_CLK frequency and pins (2016-02-02 14:02:28 +0100)
>> >> >>
>> >> >> ----------------------------------------------------------------
>> >> >> Renesas ARM Based SoC DT Updates for v4.6
>> >> >>
>> >> >> * Use SCIF and USBHS fallback compatibility strings
>> >> >> * Add Baud Rate Generator (BRG) support for (H)SCIF
>> >> >> * Enable SCIF_CLK frequency and pins
>> >> >> * Use GIC_* defines
>> >> >> * Migrate to generic l2c OF initialization on r8a7740
>> >> >> * Enable audio on r8a7793/gose
>> >> >> * Enable HDMI vidio out on r8a7793
>> >> >> * Enable i2c on r8a7793/gose
>> >> >> * Enable QSPI on alt
>> >> >> * Enable GPIO keys and leds on gise
>> >> >> * Enable audio on porter
>> >> >> * Enable DU on porter
>> >> >>
>> >> >> ----------------------------------------------------------------
>> >> >> Geert Uytterhoeven (22):
>> >> >>       ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization
>> >> >>       ARM: shmobile: r8a7740: Remove mapping of L2 cache controller registers
>> >> >
>> >> > Hmm. Those aren't DT changes. There's also nothing for r8a7740 to convert
>> >> > L2 init to DT earlier in this branch, which makes this look like it's just
>> >> > a generic cleanup that should go in independently in your cleanup branch.
>> >> >
>> >> > Or am I missing some dependency that isn't obvious? If I'm not, then please
>> >> > respin this branch and move those to the place they belong (cleanup).
>> >>
>> >> The dependency is commit 374e70075e58acfe ("ARM: shmobile: r8a7740 dtsi: Add
>> >> L2 cache-controller node"), which has already entered mainline in v4.5-rc1.
>> >>
>> >> So I agree with your comments.
>> >
>> > Sorry for the mix-up.
>> > I'll see about respinning this.
>>
>> I've merged the patches, so respinning won't work. Instead, please
>> follow up with incremental fixes instead.
>
> Hi Olof,
>
> sorry once again for the mix-up.
>
> If you have already pulled this pull request then I am happy.
> However, I don't see it in the arm-soc tree and if you haven't pulled it
> and it isn't too much trouble I would like to re-spin as I have a further
> r8a7740 cleanup in the pipeline.

Sorry for the confusion, my reply went to the wrong thread somehow.



-Olof


From robert.jarzmik at free.fr  Thu Feb 11 13:23:16 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Thu, 11 Feb 2016 22:23:16 +0100
Subject: [PATCH 2/4] dmaengine: mmp-pdma: add number of requestors
In-Reply-To: <1455225798-9510-1-git-send-email-robert.jarzmik@free.fr>
References: <1455225798-9510-1-git-send-email-robert.jarzmik@free.fr>
Message-ID: <1455225798-9510-3-git-send-email-robert.jarzmik@free.fr>

The DMA chip has a fixed number of requestor lines used for flow
control. This number is platform dependent. The pxa_dma dma driver will
use this value to activate or not the flow control.

There won't be any impact on mmp_pdma driver.

Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
 include/linux/platform_data/mmp_dma.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/platform_data/mmp_dma.h b/include/linux/platform_data/mmp_dma.h
index 2a330ec9e2af..d1397c8ed94e 100644
--- a/include/linux/platform_data/mmp_dma.h
+++ b/include/linux/platform_data/mmp_dma.h
@@ -14,6 +14,7 @@
 
 struct mmp_dma_platdata {
 	int dma_channels;
+	int nb_requestors;
 };
 
 #endif /* MMP_DMA_H */
-- 
2.1.4



From robert.jarzmik at free.fr  Thu Feb 11 13:23:14 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Thu, 11 Feb 2016 22:23:14 +0100
Subject: [PATCH 0/4] Fix pxa dma requestor lines
Message-ID: <1455225798-9510-1-git-send-email-robert.jarzmik@free.fr>

This serie aims at fixing a bug which arose in the pxa_dma driver, which needs
to know the number of requestor lines which are connected to the DMA IP.

The current implementation of pxa_dma is limited to 32 lines, which pxa27x has
75 lines and pxa3xx has 100 of them. As a consequence, DMA clients with a
requestor greater that 32 are not working, namely the pxa_camera driver.

The proposed fix by Vinod is to make the driver aware of the number of lines,
which is done by this patchset.

I'd like to have this reviewed and then taken through the PXA tree. For this
I'll need :
 - Rob/Grant/Kumar/Ian ack on patch 1/4
 - Haojian's ack on patch 2/4
 - Vinod's ack on patch 4/4

Thanks in advance.

--
Robert

Robert Jarzmik (4):
  dma: mmp_pdma: Add the #requestors DT property documentation
  dmaengine: mmp-pdma: add number of requestors
  ARM: pxa: add the number of DMA requestor lines
  dmaengine: pxa_dma: fix the maximum requestor line

 Documentation/devicetree/bindings/dma/mmp-dma.txt |  2 ++
 arch/arm/boot/dts/pxa27x.dtsi                     |  1 +
 arch/arm/boot/dts/pxa3xx.dtsi                     |  1 +
 arch/arm/mach-pxa/devices.c                       |  3 ++-
 arch/arm/mach-pxa/pxa25x.c                        |  2 +-
 arch/arm/mach-pxa/pxa27x.c                        |  2 +-
 arch/arm/mach-pxa/pxa3xx.c                        |  2 +-
 arch/arm/plat-pxa/include/plat/dma.h              |  2 +-
 drivers/dma/pxa_dma.c                             | 33 +++++++++++++++--------
 include/linux/platform_data/mmp_dma.h             |  1 +
 10 files changed, 33 insertions(+), 16 deletions(-)

-- 
2.1.4



From robert.jarzmik at free.fr  Thu Feb 11 13:23:15 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Thu, 11 Feb 2016 22:23:15 +0100
Subject: [PATCH 1/4] dma: mmp_pdma: Add the #requestors DT property
 documentation
In-Reply-To: <1455225798-9510-1-git-send-email-robert.jarzmik@free.fr>
References: <1455225798-9510-1-git-send-email-robert.jarzmik@free.fr>
Message-ID: <1455225798-9510-2-git-send-email-robert.jarzmik@free.fr>

For pxa based platforms, the number of requestor lines should be
specified, so that the driver can check if the flow control should be
activated (when a requestor line is asked for) or not.

Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
 Documentation/devicetree/bindings/dma/mmp-dma.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/mmp-dma.txt b/Documentation/devicetree/bindings/dma/mmp-dma.txt
index 7a802f64e5bd..716b70338a15 100644
--- a/Documentation/devicetree/bindings/dma/mmp-dma.txt
+++ b/Documentation/devicetree/bindings/dma/mmp-dma.txt
@@ -12,6 +12,8 @@ Required properties:
 Optional properties:
 - #dma-channels: Number of DMA channels supported by the controller (defaults
   to 32 when not specified)
+- #requestors: Number of DMA requestor lines supported by the controller
+  (defaults to 0 when not specified)
 
 "marvell,pdma-1.0"
 Used platforms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688.
-- 
2.1.4



From robert.jarzmik at free.fr  Thu Feb 11 13:23:17 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Thu, 11 Feb 2016 22:23:17 +0100
Subject: [PATCH 3/4] ARM: pxa: add the number of DMA requestor lines
In-Reply-To: <1455225798-9510-1-git-send-email-robert.jarzmik@free.fr>
References: <1455225798-9510-1-git-send-email-robert.jarzmik@free.fr>
Message-ID: <1455225798-9510-4-git-send-email-robert.jarzmik@free.fr>

Declare the number of DMA requestor lines per platform :
 - for pxa25x: 40 requestor lines
 - for pxa27x: 75 requestor lines
 - for pxa3xx: 100 requestor lines

This information will be used to activate the DMA flow control or not.

Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
 arch/arm/boot/dts/pxa27x.dtsi        | 1 +
 arch/arm/boot/dts/pxa3xx.dtsi        | 1 +
 arch/arm/mach-pxa/devices.c          | 3 ++-
 arch/arm/mach-pxa/pxa25x.c           | 2 +-
 arch/arm/mach-pxa/pxa27x.c           | 2 +-
 arch/arm/mach-pxa/pxa3xx.c           | 2 +-
 arch/arm/plat-pxa/include/plat/dma.h | 2 +-
 7 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index ef366b204c89..1f5bdfd8f9e0 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -13,6 +13,7 @@
 			interrupts = <25>;
 			#dma-channels = <32>;
 			#dma-cells = <2>;
+			#requestors = <75>;
 			status = "okay";
 		};
 
diff --git a/arch/arm/boot/dts/pxa3xx.dtsi b/arch/arm/boot/dts/pxa3xx.dtsi
index cf6998a0804d..d10d932d1d2b 100644
--- a/arch/arm/boot/dts/pxa3xx.dtsi
+++ b/arch/arm/boot/dts/pxa3xx.dtsi
@@ -12,6 +12,7 @@
 			interrupts = <25>;
 			#dma-channels = <32>;
 			#dma-cells = <2>;
+			#requestors = <100>;
 			status = "okay";
 		};
 
diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index 6e12c162506f..d9ff6e4dd854 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -1233,6 +1233,7 @@ void __init pxa2xx_set_spi_info(unsigned id, struct pxa2xx_spi_master *info)
 
 static struct mmp_dma_platdata pxa_dma_pdata = {
 	.dma_channels	= 0,
+	.nb_requestors	= 0,
 };
 
 static struct resource pxa_dma_resource[] = {
@@ -1261,7 +1262,7 @@ static struct platform_device pxa2xx_pxa_dma = {
 	.resource	= pxa_dma_resource,
 };
 
-void __init pxa2xx_set_dmac_info(int nb_channels)
+void __init pxa2xx_set_dmac_info(int nb_channels, int nb_requestors)
 {
 	pxa_dma_pdata.dma_channels = nb_channels;
 	pxa_register_device(&pxa2xx_pxa_dma, &pxa_dma_pdata);
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index a177bf45feef..823504f48f80 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -206,7 +206,7 @@ static int __init pxa25x_init(void)
 		register_syscore_ops(&pxa_irq_syscore_ops);
 		register_syscore_ops(&pxa2xx_mfp_syscore_ops);
 
-		pxa2xx_set_dmac_info(16);
+		pxa2xx_set_dmac_info(16, 40);
 		pxa_register_device(&pxa25x_device_gpio, &pxa25x_gpio_info);
 		ret = platform_add_devices(pxa25x_devices,
 					   ARRAY_SIZE(pxa25x_devices));
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index 73e96270dc53..d84239c89639 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -310,7 +310,7 @@ static int __init pxa27x_init(void)
 		if (!of_have_populated_dt()) {
 			pxa_register_device(&pxa27x_device_gpio,
 					    &pxa27x_gpio_info);
-			pxa2xx_set_dmac_info(32);
+			pxa2xx_set_dmac_info(32, 75);
 			ret = platform_add_devices(devices,
 						   ARRAY_SIZE(devices));
 		}
diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
index a1c4c888f246..fb0adb669124 100644
--- a/arch/arm/mach-pxa/pxa3xx.c
+++ b/arch/arm/mach-pxa/pxa3xx.c
@@ -450,7 +450,7 @@ static int __init pxa3xx_init(void)
 		if (of_have_populated_dt())
 			return 0;
 
-		pxa2xx_set_dmac_info(32);
+		pxa2xx_set_dmac_info(32, 100);
 		ret = platform_add_devices(devices, ARRAY_SIZE(devices));
 		if (ret)
 			return ret;
diff --git a/arch/arm/plat-pxa/include/plat/dma.h b/arch/arm/plat-pxa/include/plat/dma.h
index 28848b344e2d..ceba3e4184fc 100644
--- a/arch/arm/plat-pxa/include/plat/dma.h
+++ b/arch/arm/plat-pxa/include/plat/dma.h
@@ -95,6 +95,6 @@ static inline int pxad_toggle_reserved_channel(int legacy_channel)
 }
 #endif
 
-extern void __init pxa2xx_set_dmac_info(int nb_channels);
+extern void __init pxa2xx_set_dmac_info(int nb_channels, int nb_requestors);
 
 #endif /* __PLAT_DMA_H */
-- 
2.1.4



From olof at lixom.net  Thu Feb 11 13:23:52 2016
From: olof at lixom.net (Olof Johansson)
Date: Thu, 11 Feb 2016 13:23:52 -0800
Subject: [PATCH V2 03/12] dtb: amd: Fix DMA ranges in device tree
In-Reply-To: <56BBA80E.6090205@amd.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
 <1454954357-8395-4-git-send-email-Suravee.Suthikulpanit@amd.com>
 <2845776.WTPtnQzg8d@wuerfel> <56BBA80E.6090205@amd.com>
Message-ID: <CAOesGMgOmmXY2X2bwOd-6m117o6VPpqer6BXrzNePuRPoiz_Nw@mail.gmail.com>

Hi,

On Wed, Feb 10, 2016 at 1:13 PM, Suravee Suthikulpanit
<Suravee.Suthikulpanit at amd.com> wrote:
> Hi Arnd,
>
>
> On 2/9/16 21:57, Arnd Bergmann wrote:
>>
>> On Monday 08 February 2016 11:59:08 Suravee Suthikulpanit wrote:
>>>
>>> From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
>>>
>>> Fix DMA ranges of smb0 and pcie0 nodes in AMD Seattle SOC.
>>>
>>> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
>>>
>>
>> This could use a changelog text to explain why it's broken and how the
>> fix works.
>>
>>         Arnd
>>
>
> So, I have not experience the breakage. However, IIUC, the GICv2m MSI frame
> is also considered DMA-able. So, I think it should be included in the
> dma-range specified here. Please let me know if my assumption is incorrect.
> Otherwise, I will include more description in the commit log in my next rev.

As I replied when I did it -- I've applied the patches, so respinning
won't work. Instead, please follow up with incremental fixes to this
series instead.


Thanks,

-Olof


From robert.jarzmik at free.fr  Thu Feb 11 13:23:18 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Thu, 11 Feb 2016 22:23:18 +0100
Subject: [PATCH 4/4] dmaengine: pxa_dma: fix the maximum requestor line
In-Reply-To: <1455225798-9510-1-git-send-email-robert.jarzmik@free.fr>
References: <1455225798-9510-1-git-send-email-robert.jarzmik@free.fr>
Message-ID: <1455225798-9510-5-git-send-email-robert.jarzmik@free.fr>

The current number of requestor lines is limited to 31. This was an
error of a previous commit, as this number is platform dependent, and is
actually :
 - for pxa25x: 40 requestor lines
 - for pxa27x: 75 requestor lines
 - for pxa3xx: 100 requestor lines

The previous testing did not reveal the faulty constant as on pxa[23]xx
platforms, only camera, MSL and USB are above requestor 32, and in these
only the camera has a driver using dma.

Fixes: e87ffbdf0697 ("dmaengine: pxa_dma: fix the no-requestor case")
Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
 drivers/dma/pxa_dma.c | 33 ++++++++++++++++++++++-----------
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index ca6c088edc8a..bc51d6271373 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -122,6 +122,7 @@ struct pxad_chan {
 struct pxad_device {
 	struct dma_device		slave;
 	int				nr_chans;
+	int				nr_requestors;
 	void __iomem			*base;
 	struct pxad_phy			*phys;
 	spinlock_t			phy_lock;	/* Phy association */
@@ -473,7 +474,7 @@ static void pxad_free_phy(struct pxad_chan *chan)
 		return;
 
 	/* clear the channel mapping in DRCMR */
-	if (chan->drcmr <= DRCMR_CHLNUM) {
+	if (chan->drcmr <= pdev->nr_requestors) {
 		reg = pxad_drcmr(chan->drcmr);
 		writel_relaxed(0, chan->phy->base + reg);
 	}
@@ -509,6 +510,7 @@ static bool is_running_chan_misaligned(struct pxad_chan *chan)
 
 static void phy_enable(struct pxad_phy *phy, bool misaligned)
 {
+	struct pxad_device *pdev;
 	u32 reg, dalgn;
 
 	if (!phy->vchan)
@@ -518,7 +520,8 @@ static void phy_enable(struct pxad_phy *phy, bool misaligned)
 		"%s(); phy=%p(%d) misaligned=%d\n", __func__,
 		phy, phy->idx, misaligned);
 
-	if (phy->vchan->drcmr <= DRCMR_CHLNUM) {
+	pdev = to_pxad_dev(phy->vchan->vc.chan.device);
+	if (phy->vchan->drcmr <= pdev->nr_requestors) {
 		reg = pxad_drcmr(phy->vchan->drcmr);
 		writel_relaxed(DRCMR_MAPVLD | phy->idx, phy->base + reg);
 	}
@@ -914,6 +917,7 @@ static void pxad_get_config(struct pxad_chan *chan,
 {
 	u32 maxburst = 0, dev_addr = 0;
 	enum dma_slave_buswidth width = DMA_SLAVE_BUSWIDTH_UNDEFINED;
+	struct pxad_device *pdev = to_pxad_dev(chan->vc.chan.device);
 
 	*dcmd = 0;
 	if (dir == DMA_DEV_TO_MEM) {
@@ -922,7 +926,7 @@ static void pxad_get_config(struct pxad_chan *chan,
 		dev_addr = chan->cfg.src_addr;
 		*dev_src = dev_addr;
 		*dcmd |= PXA_DCMD_INCTRGADDR;
-		if (chan->drcmr <= DRCMR_CHLNUM)
+		if (chan->drcmr <= pdev->nr_requestors)
 			*dcmd |= PXA_DCMD_FLOWSRC;
 	}
 	if (dir == DMA_MEM_TO_DEV) {
@@ -931,7 +935,7 @@ static void pxad_get_config(struct pxad_chan *chan,
 		dev_addr = chan->cfg.dst_addr;
 		*dev_dst = dev_addr;
 		*dcmd |= PXA_DCMD_INCSRCADDR;
-		if (chan->drcmr <= DRCMR_CHLNUM)
+		if (chan->drcmr <= pdev->nr_requestors)
 			*dcmd |= PXA_DCMD_FLOWTRG;
 	}
 	if (dir == DMA_MEM_TO_MEM)
@@ -1341,13 +1345,15 @@ static struct dma_chan *pxad_dma_xlate(struct of_phandle_args *dma_spec,
 
 static int pxad_init_dmadev(struct platform_device *op,
 			    struct pxad_device *pdev,
-			    unsigned int nr_phy_chans)
+			    unsigned int nr_phy_chans,
+			    unsigned int nr_requestors)
 {
 	int ret;
 	unsigned int i;
 	struct pxad_chan *c;
 
 	pdev->nr_chans = nr_phy_chans;
+	pdev->nr_requestors = nr_requestors;
 	INIT_LIST_HEAD(&pdev->slave.channels);
 	pdev->slave.device_alloc_chan_resources = pxad_alloc_chan_resources;
 	pdev->slave.device_free_chan_resources = pxad_free_chan_resources;
@@ -1382,7 +1388,7 @@ static int pxad_probe(struct platform_device *op)
 	const struct of_device_id *of_id;
 	struct mmp_dma_platdata *pdata = dev_get_platdata(&op->dev);
 	struct resource *iores;
-	int ret, dma_channels = 0;
+	int ret, dma_channels = 0, nb_requestors = 0;
 	const enum dma_slave_buswidth widths =
 		DMA_SLAVE_BUSWIDTH_1_BYTE   | DMA_SLAVE_BUSWIDTH_2_BYTES |
 		DMA_SLAVE_BUSWIDTH_4_BYTES;
@@ -1399,13 +1405,17 @@ static int pxad_probe(struct platform_device *op)
 		return PTR_ERR(pdev->base);
 
 	of_id = of_match_device(pxad_dt_ids, &op->dev);
-	if (of_id)
+	if (of_id) {
 		of_property_read_u32(op->dev.of_node, "#dma-channels",
 				     &dma_channels);
-	else if (pdata && pdata->dma_channels)
+		of_property_read_u32(op->dev.of_node, "#requestors",
+				     &nb_requestors);
+	} else if (pdata && pdata->dma_channels) {
 		dma_channels = pdata->dma_channels;
-	else
+		nb_requestors = pdata->nb_requestors;
+	} else {
 		dma_channels = 32;	/* default 32 channel */
+	}
 
 	dma_cap_set(DMA_SLAVE, pdev->slave.cap_mask);
 	dma_cap_set(DMA_MEMCPY, pdev->slave.cap_mask);
@@ -1423,7 +1433,7 @@ static int pxad_probe(struct platform_device *op)
 	pdev->slave.descriptor_reuse = true;
 
 	pdev->slave.dev = &op->dev;
-	ret = pxad_init_dmadev(op, pdev, dma_channels);
+	ret = pxad_init_dmadev(op, pdev, dma_channels, nb_requestors);
 	if (ret) {
 		dev_err(pdev->slave.dev, "unable to register\n");
 		return ret;
@@ -1442,7 +1452,8 @@ static int pxad_probe(struct platform_device *op)
 
 	platform_set_drvdata(op, pdev);
 	pxad_init_debugfs(pdev);
-	dev_info(pdev->slave.dev, "initialized %d channels\n", dma_channels);
+	dev_info(pdev->slave.dev, "initialized %d channels on %d requestors\n",
+		 dma_channels, nb_requestors);
 	return 0;
 }
 
-- 
2.1.4



From mturquette at baylibre.com  Thu Feb 11 13:35:42 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Thu, 11 Feb 2016 13:35:42 -0800
Subject: [PATCH v6 7/7] clk: mediatek: Enable critical clocks for MT2701
In-Reply-To: <1454665050-37776-8-git-send-email-jamesjj.liao@mediatek.com>
References: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
 <1454665050-37776-8-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <20160211213542.26445.82983@quark.deferred.io>

Hi James,

Quoting James Liao (2016-02-05 01:37:30)
> Some system clocks should be turned on by default on MT2701.
> This patch enable these clocks when related clocks have
> been registered.
> 
> Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
> ---
>  drivers/clk/mediatek/clk-mt2701.c | 23 +++++++++++++++++++++--
>  1 file changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/mediatek/clk-mt2701.c b/drivers/clk/mediatek/clk-mt2701.c
> index 01722e0..f7b4d52 100644
> --- a/drivers/clk/mediatek/clk-mt2701.c
> +++ b/drivers/clk/mediatek/clk-mt2701.c
> @@ -573,6 +573,21 @@ static const struct mtk_gate top_clks[] __initconst = {
>         GATE_TOP_AUD(CLK_TOP_AUD_I2S6_MCLK, "aud_i2s6_mclk", "aud_k6_src_div", 28),
>  };
>  
> +static struct clk_onecell_data *top_clk_data __initdata;
> +static struct clk_onecell_data *pll_clk_data __initdata;
> +
> +static void __init mtk_clk_enable_critical(void)
> +{
> +       if (!top_clk_data || !pll_clk_data)
> +               return;
> +
> +       clk_prepare_enable(pll_clk_data->clks[CLK_APMIXED_ARMPLL]);
> +       clk_prepare_enable(top_clk_data->clks[CLK_TOP_AXI_SEL]);
> +       clk_prepare_enable(top_clk_data->clks[CLK_TOP_MEM_SEL]);
> +       clk_prepare_enable(top_clk_data->clks[CLK_TOP_DDRPHYCFG_SEL]);
> +       clk_prepare_enable(top_clk_data->clks[CLK_TOP_RTC_SEL]);
> +}

I think we're close to having a better solution. Please see this patch
series[0] and let me know if it provides a better way for you to enable
these critical clocks instead of the open-coded solution.

[0] http://lkml.kernel.org/r/<1455225554-13267-1-git-send-email-mturquette at baylibre.com>

Regards,
Mike

> +
>  static void __init mtk_topckgen_init(struct device_node *node)
>  {
>         struct clk_onecell_data *clk_data;
> @@ -585,7 +600,7 @@ static void __init mtk_topckgen_init(struct device_node *node)
>                 return;
>         }
>  
> -       clk_data = mtk_alloc_clk_data(CLK_TOP_NR);
> +       top_clk_data = clk_data = mtk_alloc_clk_data(CLK_TOP_NR);
>  
>         mtk_clk_register_fixed_clks(top_fixed_clks, ARRAY_SIZE(top_fixed_clks),
>                                                                 clk_data);
> @@ -606,6 +621,8 @@ static void __init mtk_topckgen_init(struct device_node *node)
>         if (r)
>                 pr_err("%s(): could not register clock provider: %d\n",
>                         __func__, r);
> +
> +       mtk_clk_enable_critical();

So you call the function here, and ...
>  }
>  CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt2701-topckgen", mtk_topckgen_init);
>  
> @@ -1201,7 +1218,7 @@ static void __init mtk_apmixedsys_init(struct device_node *node)
>         struct clk_onecell_data *clk_data;
>         int r;
>  
> -       clk_data = mtk_alloc_clk_data(ARRAY_SIZE(apmixed_plls));
> +       pll_clk_data = clk_data = mtk_alloc_clk_data(ARRAY_SIZE(apmixed_plls));
>         if (!clk_data)
>                 return;
>  
> @@ -1212,6 +1229,8 @@ static void __init mtk_apmixedsys_init(struct device_node *node)
>         if (r)
>                 pr_err("%s(): could not register clock provider: %d\n",
>                         __func__, r);
> +
> +       mtk_clk_enable_critical();

... here as well. So the prepare_count and enable_count will be 2? I'm
not sure that this makes sense. If you have different clocks that need
to be enabled at different times (due to the split registration scheme
that you employ in this driver) then why not pass an array of those
clocks into mtk_clk_enable_critical?

Anyways, like I mentioned above I think we're close to a solution to
handle this in the framework.

One question: do you ever want these critical clocks to be gated by a
driver, or do you want them always on, forever?

Regards,
Mike

>  }
>  CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt2701-apmixedsys",
>                                                         mtk_apmixedsys_init);
> -- 
> 1.9.1
> 


From robh at kernel.org  Thu Feb 11 13:46:04 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 11 Feb 2016 15:46:04 -0600
Subject: breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi:
 Refactor A31 PLL6 so that it can be reused)
In-Reply-To: <20160211100048.GK31506@lukather>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <56BB2D79.6090402@arm.com>
 <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
 <20160210143755.GE31506@lukather> <20160210163001.GG2632@leverpostej>
 <20160211100048.GK31506@lukather>
Message-ID: <CAL_JsqKAjwQWZ5HpdHbMiWkuEQKFwwUNGUsb=iAZ-t7scb1FUg@mail.gmail.com>

On Thu, Feb 11, 2016 at 4:00 AM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> On Wed, Feb 10, 2016 at 04:30:01PM +0000, Mark Rutland wrote:
>> On Wed, Feb 10, 2016 at 03:37:55PM +0100, Maxime Ripard wrote:
>> > Hi Rob,
>> >
>> > On Wed, Feb 10, 2016 at 07:42:02AM -0600, Rob Herring wrote:
>> > > On Wed, Feb 10, 2016 at 6:30 AM, Andre Przywara <andre.przywara at arm.com> wrote:
>> > > > Hi,
>> > > >
>> > > > just a ping:
>> > > >
>> > > > Are we really OK with breaking existing DTs in 4.6? (per the code in
>> > > > -next: f7d372ba54ea04d528a291b8dbe34716507bb60b, which is this patch).
>> > >
>> > > I only warn and make sure people are aware of the issue. I leave that
>> > > up to platform maintainers to decide. It depends on the maturity of
>> > > the platform and users.
>> >
>> > The impacted SoCs support is really partial. For the most supported
>> > one, big things like display or sound are totally missing, and we
>> > still update them on a regular basis to add support for new
>> > devices. As such, users are very likely to upgrade the DT from one
>> > version to another just because there's new devices available to
>> > them. And the newest SoC impacted just got introduced in 4.5, and only
>> > has the UART and MMC devices available.
>> >
>> > > If people complain about it then it's their mess. For platforms
>> > > supported in distros such as debian or fedora, I would strongly
>> > > recommend against breaking compatibility.
>> >
>> > None of them are officially supported:
>> > https://www.debian.org/releases/stable/armhf/ch02s01.html.en
>> > https://fedoraproject.org/wiki/Architectures/ARM#Fedora_23
>> >
>> > Only the older one are, and they are not affected by this patch.
>> >
>> > > They do ship dtbs, but it's a chicken and egg problem. If dtbs were
>> > > stable and provided by firmware, then they wouldn't have to provide
>> > > them. If dtbs are unstable, then they have no choice.
>> >
>> > And while it might work great on platforms that have all the needed
>> > documentation, or a perfect one, which is our case. Almost each
>> > release, we discover that something is not working as it was
>> > documented, when it was documented in the first place.
>> >
>> > It also seems that even on well documented platforms, supported by the
>> > vendors, the stable ABI dream is not going to happen:
>> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm/Atmel/README#n105
>> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/arm/marvell,berlin.txt#n4
>>
>> To be quite frank, I completely disagree with that stance.
>>
>> It seems like the only reason DT bindings aren't remaining stable is
>> because people are deliberately ignoring the requirement and reasoning
>> for doing so.
>
> And for DT maintainers saying on multiple occasions that it's bad but
> ok to break it and / or that they never actually said that it was a
> stable ABI...

It says so in the documentation, why do we need to repeat it? While I
do defer to platform maintainers judgement, if there is complete
disregard for the ABI then I won't. This single case alone doesn't
bother me so much, but if this is the pattern every kernel cycle I am
bothered.

Also, I'm inclined to go delete the text in the links above.

> I'm guessing it could be a stable ABI if there was bindings
> reviews. Rob actually started to review a significant amount of
> bindings lately, and that's really appreciated, but if you don't
> review all the bindings, then we're going to make mistakes.

Everything should be reviewed. Subsystem/platform maintainers are
responsible for reviewing and getting DT help if needed. There is
documentation about this too. Maybe this system is not working well
and needs to be revisited. I know the reviews are better for some
subsystems than others. I am trying to be more actively reviewing
things, but subsystem maintainers still need to review them. They
should know their bindings better than me.

Even if we review all bindings, there will still be mistakes.

Rob


From pbonzini at redhat.com  Thu Feb 11 13:47:13 2016
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Thu, 11 Feb 2016 22:47:13 +0100
Subject: [PULL] KVM/ARM fixes for 4.5-rc4
In-Reply-To: <1455206386-24997-1-git-send-email-marc.zyngier@arm.com>
References: <1455206386-24997-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <56BD0161.6060003@redhat.com>



On 11/02/2016 16:59, Marc Zyngier wrote:
> Hi Paolo,
> 
> Please find below the KVM/ARM updates for 4.5-rc4. One fix for the
> timer, and another for the HYP MMU setup.
> 
> Please pull!
> 
> Thanks,
> 
> 	M.
> 
> The following changes since commit 6327f35a2010c06a3bc2bfb14202a38764fb9920:
> 
>   arm64: KVM: Fix guest dead loop when register accessor returns false (2016-01-24 21:56:01 +0000)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvm-arm-for-4.5-rc4
> 
> for you to fetch changes up to 3c5b1d92b3b02be07873d611a27950addff544d3:
> 
>   arm64: KVM: Configure TCR_EL2.PS at runtime (2016-02-11 13:16:47 +0000)
> 
> ----------------------------------------------------------------
> KVM/ARM fixes for 4.5-rc4
> 
> - Fix for an unpleasant crash when the VM is created without a timer
> - Allow HYP mode to access the full PA space, and not only 40bit
> 
> ----------------------------------------------------------------
> Andre Przywara (1):
>       KVM: arm/arm64: Fix reference to uninitialised VGIC
> 
> Tirumalesh Chalamarla (1):
>       arm64: KVM: Configure TCR_EL2.PS at runtime
> 
>  arch/arm64/include/asm/kvm_arm.h |  2 --
>  arch/arm64/kvm/hyp-init.S        | 12 +++++++-----
>  virt/kvm/arm/arch_timer.c        |  9 ++++++---
>  3 files changed, 13 insertions(+), 10 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Pulled, thanks (but I'll probably delay it to rc5).

Paolo


From sergei.shtylyov at cogentembedded.com  Thu Feb 11 13:49:52 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 12 Feb 2016 00:49:52 +0300
Subject: [PATCH] ARM: dts: porter: fix JP3 jumper description
In-Reply-To: <1674850.BZpGW9kEud@wasted.cogentembedded.com>
References: <1674850.BZpGW9kEud@wasted.cogentembedded.com>
Message-ID: <1655804.y4T36KvG5v@wasted.cogentembedded.com>

When finishing the Porter sound support patch, I managed to call the JP3
jumper SW3 in the comment.  Fix this  along with (also miscalled) jumper
positions...

Fixes: 493b4da7c10c ("ARM: dts: porter: add sound support")
Reported-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
This patch is against the 'renesas-devel-20160209-v4.5-rc3' tag of Simon
Horman's 'renesas.git' repo.

arch/arm/boot/dts/r8a7791-porter.dts |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -11,8 +11,8 @@
 /*
  * SSI-AK4642
  *
- * SW3: 1: AK4642
- *      3: ADV7511
+ * JP3: 2-1: AK4642
+ *      2-3: ADV7511
  *
  * This command is required before playback/capture:
  *



From arnd at arndb.de  Thu Feb 11 13:59:51 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 22:59:51 +0100
Subject: [PATCH 1/4] dma: mmp_pdma: Add the #requestors DT property
 documentation
In-Reply-To: <1455225798-9510-2-git-send-email-robert.jarzmik@free.fr>
References: <1455225798-9510-1-git-send-email-robert.jarzmik@free.fr>
 <1455225798-9510-2-git-send-email-robert.jarzmik@free.fr>
Message-ID: <2622040.i4begfCjyO@wuerfel>

On Thursday 11 February 2016 22:23:15 Robert Jarzmik wrote:
> @@ -12,6 +12,8 @@ Required properties:
>  Optional properties:
>  - #dma-channels: Number of DMA channels supported by the controller (defaults
>    to 32 when not specified)
> +- #requestors: Number of DMA requestor lines supported by the controller
> +  (defaults to 0 when not specified)
>  
> 

Most other ones use "#dma-requests" as the property name here, I think it makes
sense to stay with that convention.

	Arnd


From s-anna at ti.com  Thu Feb 11 14:04:19 2016
From: s-anna at ti.com (Suman Anna)
Date: Thu, 11 Feb 2016 16:04:19 -0600
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <alpine.DEB.2.02.1602111921090.20757@utopia.booyaka.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com> <56BACCDB.2070507@ti.com>
 <alpine.DEB.2.02.1602111921090.20757@utopia.booyaka.com>
Message-ID: <56BD0563.3060107@ti.com>

On 02/11/2016 01:27 PM, Paul Walmsley wrote:
> Hi Kishon, Suman,
> 
> On Wed, 10 Feb 2016, Kishon Vijay Abraham I wrote:
> 
>> On Wednesday 10 February 2016 07:12 AM, Suman Anna wrote:
>>> On 02/09/2016 01:36 PM, Paul Walmsley wrote:
>>>> On Tue, 9 Feb 2016, Suman Anna wrote:
>>>>> On 02/09/2016 02:49 AM, Paul Walmsley wrote:
>>>>>> On Mon, 8 Feb 2016, Suman Anna wrote:
>>>>>>> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
>>>>>>>> On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:
>>>>>>>>
>>>>>>>>> Paul, what do you think is the best way forward to perform reset?
>>>>>>>>
>>>>>>>> Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
>>>>>>>> Those often need special reset handling to ensure that WFI/HLT-like 
>>>>>>>> instructions are executed after reset.  This special handling ensures that 
>>>>>>>> the IP blocks' bus initiator interfaces indicate that they are in standby 
>>>>>>>> to the PRCM - thus allowing power management for the rest of the chip to 
>>>>>>>> work correctly.
>>>>>>>>
>>>>>>>> But that doesn't seem to be the case with PCIe - and maybe others - 
>>>>>>>> possibly some of the MMUs?  
>>>>>>>
>>>>>>> Yeah, the sequencing between clocks and resets would still be the same
>>>>>>> for MMUs, so, adding the custom flags for MMUs is fine.
>>>>>>
>>>>>> I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs.  
>>>>>> We've stated that the main point of the custom hardreset code is to handle 
>>>>>> processors that need to be placed into WFI/HLT, but it doesn't seem like 
>>>>>> there would be an equivalent for MMUs.  Thoughts?
>>>>>
>>>>> The current OMAP IOMMU code already leverages the pdata ops for
>>>>> performing the resets, so not adding the flags would also require
>>>>> additional changes in the driver.
>>>>>
>>>>> Also, the reset lines controlling the MMUs actually also manage the
>>>>> reset for all the other sub-modules other than the processor cores
>>>>> within the sub-systems. We have currently different issues (see [1] for
>>>>> eg. around the IPU sub-system entering RET in between), so from a PM
>>>>> point of view, we do prefer to place the MMUs also in reset when we are
>>>>> runtime suspended.
>>>>
>>>> Should we reassert hardreset in _idle() for IP blocks that don't have 
>>>> HWMOD_CUSTOM_HARDRESET set on them?  Would that allow us to use this 
>>>> mechanism for the uncore hardreset lines, or are there other quirks?
>>>>
>>>> Also - would that address the potential issue that you mentioned with the 
>>>> PCIe block, or is that a different issue?
>>>
>>> Yeah, I think that would address the PCIe block issue in terms of reset
>>> state balancing between pm_runtime_get_sync() and pm_runtime_put()
>>> calls. Right now, they are unbalanced. The PCIe block is using these
>>> only in probe and remove, so it should work for that IP.
>>
>> As I mentioned before this would result in undesired behavior during
>> suspend/resume cycle in PCIe. (This should be okay for the current mainline
>> code but would break once we add suspend/resume support for PCIe).
> 
> I'd like to understand where we're currently at here.  It looks like we're 
> waiting for testing from Suman, and we're waiting for Kishon to try using 
> the bind/unbind driver model hook to see if that wedges PCIe?  Does this 
> match your collective understanding of the status here?

Matches mine :)

For MMUs and (out of tree) OMAP remoteprocs, my current sequence is
omap_device_deassert_hardreset() followed by pm_runtime_get_sync() or
omap_device_enable() during booting, and pm_runtime_put_sync() or
omap_device_idle() followed by omap_device_assert_hardreset(). Atleast
they are bunched together.

So, the current code does _deassert_hardreset twice when invoking the
pm_runtime_get_sync() in my driver since the check for
_are_all_hardreset_lines_asserted(oh) would fail.

> 
> Thinking about the question of what to do about hardreset assertion in 
> idle, if we need it, we could add a hwmod flag to control that mode.  I 
> would consider it a temporary workaround until we have the hwmod code 
> moved into a bus driver and the bus driver/hwmod code can hook into the 
> LDM .remove operation (and connect it to .shutdown, etc.)  Suman/Kishon: 
> is it your understanding that we could remove the existing hardreset 
> control in the IOMMU drivers and the PCIe driver if we had these options 
> in the hwmod code?

For MMUs/processors, the position where we deassert the reset becomes
important. It has to be after the clocks are enabled (which is why half
of the _deassert_hardreset code looks like the code sequence in _enable()).

regards
Suman


> 
> Dave, any further comments here?



From arnd at arndb.de  Thu Feb 11 14:12:18 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 11 Feb 2016 23:12:18 +0100
Subject: [PATCH v2 1/3] of/fdt: factor out assignment of
 initrd_start/initrd_end
In-Reply-To: <1455209282-9596-2-git-send-email-ard.biesheuvel@linaro.org>
References: <1455209282-9596-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455209282-9596-2-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <3591081.dypcHcG82d@wuerfel>

On Thursday 11 February 2016 17:48:00 Ard Biesheuvel wrote:
> 
>  #ifdef CONFIG_BLK_DEV_INITRD
> +void __weak __early_init_dt_declare_initrd(unsigned long start,
> +                                          unsigned long end)
> +{
> +       initrd_start = (unsigned long)__va(start);
> +       initrd_end = (unsigned long)__va(end);
> +       initrd_below_start_ok = 1;
> +}
> +
> 

I find __weak functions particularly hard to follow, I think a Kconfig
symbols or a function you can override by defining a macro in asm/memory.h
would be nicer.

	Arnd


From yang.shi at linaro.org  Thu Feb 11 13:53:10 2016
From: yang.shi at linaro.org (Yang Shi)
Date: Thu, 11 Feb 2016 13:53:10 -0800
Subject: [PATCH] arm64: make irq_stack_ptr more robust
Message-ID: <1455227590-9837-1-git-send-email-yang.shi@linaro.org>

Switching between stacks is only valid if we are tracing ourselves while on the
irq_stack, so it is only valid when in current and non-preemptible context,
otherwise is is just zeroed off.

Signed-off-by: Yang Shi <yang.shi at linaro.org>
---
 arch/arm64/kernel/stacktrace.c | 13 ++++++-------
 arch/arm64/kernel/traps.c      | 11 ++++++++++-
 2 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 12a18cb..d9751a4 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -44,14 +44,13 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
 	unsigned long irq_stack_ptr;
 
 	/*
-	 * Use raw_smp_processor_id() to avoid false-positives from
-	 * CONFIG_DEBUG_PREEMPT. get_wchan() calls unwind_frame() on sleeping
-	 * task stacks, we can be pre-empted in this case, so
-	 * {raw_,}smp_processor_id() may give us the wrong value. Sleeping
-	 * tasks can't ever be on an interrupt stack, so regardless of cpu,
-	 * the checks will always fail.
+	 * Switching between stacks is valid when tracing current and in
+	 * non-preemptible context.
 	 */
-	irq_stack_ptr = IRQ_STACK_PTR(raw_smp_processor_id());
+	if (tsk == current && !preemptible())
+		irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
+	else
+		irq_stack_ptr = 0;
 
 	low  = frame->sp;
 	/* irq stacks are not THREAD_SIZE aligned */
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index cbedd72..7d8db3a 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -146,9 +146,18 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
 static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
 {
 	struct stackframe frame;
-	unsigned long irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
+	unsigned long irq_stack_ptr;
 	int skip;
 
+	/*
+	 * Switching between  stacks is valid when tracing current and in
+	 * non-preemptible context.
+	 */
+	if (tsk == current && !preemptible())
+		irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
+	else
+		irq_stack_ptr = 0;
+
 	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
 
 	if (!tsk)
-- 
2.0.2



From rjw at rjwysocki.net  Thu Feb 11 14:22:29 2016
From: rjw at rjwysocki.net (Rafael J. Wysocki)
Date: Thu, 11 Feb 2016 23:22:29 +0100
Subject: [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen
In-Reply-To: <alpine.DEB.2.02.1602111557430.27008@kaball.uk.xensource.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
 <44113385.2QnPtvxQx0@vostro.rjw.lan>
 <alpine.DEB.2.02.1602111557430.27008@kaball.uk.xensource.com>
Message-ID: <1667812.hY9vsC2epc@vostro.rjw.lan>

On Thursday, February 11, 2016 04:04:14 PM Stefano Stabellini wrote:
> On Wed, 10 Feb 2016, Rafael J. Wysocki wrote:
> > On Tuesday, February 09, 2016 11:19:02 AM Stefano Stabellini wrote:
> > > On Mon, 8 Feb 2016, Rafael J. Wysocki wrote:
> > > > On Monday, February 08, 2016 10:57:01 AM Stefano Stabellini wrote:
> > > > > On Sat, 6 Feb 2016, Rafael J. Wysocki wrote:
> > > > > > On Fri, Feb 5, 2016 at 4:05 AM, Shannon Zhao <zhaoshenglong at huawei.com> wrote:
> > > > > > > From: Shannon Zhao <shannon.zhao at linaro.org>
> > > > > > >
> > > > > > > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > > > > > > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > > > > > > UART is used by Xen. So here it hides UART from Dom0.
> > > > > > >
> > > > > > > Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> > > > > > > Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> > > > > > 
> > > > > > Well, this doesn't look right to me.
> > > > > > 
> > > > > > We need to find a nicer way to achieve what you want.
> > > > > 
> > > > > I take that you are talking about how to honor the STAO table in Linux.
> > > > > Do you have any concrete suggestions?
> > > > 
> > > > I do.
> > > > 
> > > > The last hunk of the patch is likely what it needs to be, although I'm
> > > > not sure if the place it is added to is the right one.  That's a minor thing,
> > > > though.
> > > > 
> > > > The other part is problematic.  Not that as it doesn't work, but because of
> > > > how it works.  With these changes the device will be visible to the OS (in
> > > > fact to user space even), but will never be "present".  I'm not sure if
> > > > that's what you want?
> > > > 
> > > > It might be better to add a check to acpi_bus_type_and_status() that will
> > > > evaluate the "should ignore?" thing and return -ENODEV if this is true.  This
> > > > way the device won't be visible at all.
> > > 
> > > Something like below?  Actually your suggestion is better, thank you!
> > > 
> > > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > > index 78d5f02..4778c51 100644
> > > --- a/drivers/acpi/scan.c
> > > +++ b/drivers/acpi/scan.c
> > > @@ -1455,6 +1455,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > >  	if (ACPI_FAILURE(status))
> > >  		return -ENODEV;
> > >  
> > > +	if (acpi_check_device_is_ignored(handle))
> > > +		return -ENODEV;
> > > +
> > >  	switch (acpi_type) {
> > >  	case ACPI_TYPE_ANY:		/* for ACPI_ROOT_OBJECT */
> > >  	case ACPI_TYPE_DEVICE:
> > > 
> > 
> > I thought about doing that under ACPI_TYPE_DEVICE, because it shouldn't be
> > applicable to the other types.  But generally, yes.
> 
> I was pondering about it myself. Maybe an ACPI_TYPE_PROCESSOR object
> could theoretically be hidden with the STAO?

But this patch won't check for it anyway, will it?

It seems to be only checking against the UART address or have I missed
anything?

> I added the check before
> the switch because I thought that there would be no harm in being
> caution about it.
> 
> 
> > Plus I'd move the table checks to acpi_scan_init(), so the UART address can
> > be a static variable in scan.c.
> >
> > Also maybe rename acpi_check_device_is_ignored() to something like
> > acpi_device_should_be_hidden().
> 
> Both make sense. Shannon, are you happy to make these changes?

Plus maybe make acpi_device_should_be_hidden() print a (KERN_INFO) message
when it decides to hide something?

Thanks,
Rafael



From tbaicar at codeaurora.org  Thu Feb 11 14:37:55 2016
From: tbaicar at codeaurora.org (Baicar, Tyler)
Date: Thu, 11 Feb 2016 15:37:55 -0700
Subject: [PATCH V1 6/6] acpi: apei: handle SEA notification type for ARMv8
In-Reply-To: <20160210180332.GU1052@arm.com>
References: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
 <1454699608-22760-7-git-send-email-tbaicar@codeaurora.org>
 <20160210180332.GU1052@arm.com>
Message-ID: <56BD0D43.4060901@codeaurora.org>

Hello Will,

On 2/10/2016 11:03 AM, Will Deacon wrote:
> On Fri, Feb 05, 2016 at 12:13:28PM -0700, Tyler Baicar wrote:
>> ARM APEI extension proposal added SEA (Synchrounous External
>> Abort) notification type for ARMv8.
>>
>> Add a new GHES error source handling function for SEA. If an error
>> source's notification type is SEA, then this function can be registered
>> into the SEA exception handler. That way GHES will parse and report
>> SEA exceptions when they occur.
>>
>> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang at codeaurora.org>
>> Signed-off-by: Tyler Baicar <tbaicar at codeaurora.org>
>> Signed-off-by: Naveen Kaje <nkaje at codeaurora.org>
>> ---
>>   arch/arm64/Kconfig        |  1 +
>>   drivers/acpi/apei/Kconfig | 13 ++++++++
>>   drivers/acpi/apei/ghes.c  | 83 +++++++++++++++++++++++++++++++++++++++++++++++
>>   include/acpi/actbl1.h     |  6 +++-
>>   4 files changed, 102 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 6e4a4f4..236f398 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -6,6 +6,7 @@ config ARM64
>>   	select ACPI_REDUCED_HARDWARE_ONLY if ACPI
>>   	select ARCH_HAS_DEVMEM_IS_ALLOWED
>>   	select HAVE_ACPI_APEI if ACPI
>> +	select HAVE_ACPI_APEI_SEA if ACPI
>>   	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
>>   	select ARCH_HAS_ELF_RANDOMIZE
>>   	select ARCH_HAS_GCOV_PROFILE_ALL
>> diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
>> index a60bb00..bfcbb9e 100644
>> --- a/drivers/acpi/apei/Kconfig
>> +++ b/drivers/acpi/apei/Kconfig
>> @@ -7,6 +7,19 @@ config HAVE_ACPI_APEI_NMI
>>   config HAVE_ACPI_APEI_HEST_IA32
>>   	bool
>>   
>> +config HAVE_ACPI_APEI_SEA
>> +	bool "APEI Synchronous External Abort logging/recovering support"
>> +	help
>> +	  This option should be enabled if the system supports
>> +	  firmware first handling of SEA (Synchronous External Abort).
>> +	  SEA happens with certain faults of data abort or instruction
>> +	  abort synchronous exceptions on ARMv8 systems. If a system
>> +	  supports firmware first handling of SEA, the platform analyzes
>> +	  and handles hardware error notifications with SEA, and it may then
>> +	  form a HW error record for the OS to parse and handle. This
>> +	  option allows the OS to look for such HW error record, and
>> +	  take appropriate action.
>> +
>>   config ACPI_APEI
>>   	bool "ACPI Platform Error Interface (APEI)"
>>   	select MISC_FILESYSTEMS
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index 6c68100..ed64b97 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -50,6 +50,10 @@
>>   #include <acpi/apei.h>
>>   #include <asm/tlbflush.h>
>>   
>> +#ifdef CONFIG_HAVE_ACPI_APEI_SEA
>> +#include <asm/system_misc.h>
>> +#endif
>> +
>>   #include "apei-internal.h"
>>   
>>   #define GHES_PFX	"GHES: "
>> @@ -784,6 +788,62 @@ static struct notifier_block ghes_notifier_sci = {
>>   	.notifier_call = ghes_notify_sci,
>>   };
>>   
>> +#ifdef CONFIG_HAVE_ACPI_APEI_SEA
>> +static LIST_HEAD(ghes_sea);
>> +
>> +static int ghes_notify_sea(struct notifier_block *this,
>> +				  unsigned long event, void *data)
>> +{
>> +	struct ghes *ghes;
>> +	int ret = NOTIFY_DONE;
>> +
>> +	rcu_read_lock();
>> +	list_for_each_entry_rcu(ghes, &ghes_sea, list) {
>> +		if (!ghes_proc(ghes))
>> +			ret = NOTIFY_OK;
>> +	}
>> +	rcu_read_unlock();
>> +
>> +	return ret;
>> +}
>> +
>> +static struct notifier_block ghes_notifier_sea = {
>> +	.notifier_call = ghes_notify_sea,
>> +};
>> +
>> +static int ghes_sea_add(struct ghes *ghes)
>> +{
>> +	mutex_lock(&ghes_list_mutex);
> Can you just use spin_lock, to be consistent with our other excception
> hooks?
This mutex is being used throughout ghes.c for editing the lists, so I 
think this is the proper (or at least consistent) implementation. This 
mutex was defined specifically for editing the lists according to the 
comment above the mutex definition:

"All error sources notified with SCI shares one notifier function, so 
they need to be linked and checked one by one. This is applied to NMI 
too. RCU is used for these lists, so ghes_list_mutex is only used for 
list changing, not for traversing."

The use of this mutex is identical to the way that SCI and NMI use it 
when adding or deleting from the lists. Should I add to this comment 
that this applies to SEA as well?
>
>> +	if (list_empty(&ghes_sea))
>> +		sea_register_handler_chain(&ghes_notifier_sea);
>> +	list_add_rcu(&ghes->list, &ghes_sea);
>> +	mutex_unlock(&ghes_list_mutex);
>> +	return 0;
>> +}
>> +
>> +static void ghes_sea_remove(struct ghes *ghes)
>> +{
>> +	mutex_lock(&ghes_list_mutex);
>> +	list_del_rcu(&ghes->list);
>> +	if (list_empty(&ghes_sea))
>> +		sea_unregister_handler_chain(&ghes_notifier_sea);
>> +	mutex_unlock(&ghes_list_mutex);
>> +}
>> +#else /* CONFIG_HAVE_ACPI_APEI_SEA */
>> +static inline int ghes_sea_add(struct ghes *ghes)
>> +{
>> +	pr_err(GHES_PFX "ID: %d, trying to add SEA notification which is not supported\n",
>> +	       ghes->generic->header.source_id);
>> +	return -ENOTSUPP;
>> +}
>> +
>> +static inline void ghes_sea_remove(struct ghes *ghes)
>> +{
>> +	pr_err(GHES_PFX "ID: %d, trying to remove SEA notification which is not supported\n",
>> +	       ghes->generic->header.source_id);
>> +}
> Why are these getting called if !CONFIG_HAVE_ACPI_APEI_SEA?
>
> Will
Thanks,
Tyler

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project



From msalter at redhat.com  Thu Feb 11 14:52:09 2016
From: msalter at redhat.com (Mark Salter)
Date: Thu, 11 Feb 2016 17:52:09 -0500
Subject: [PATCH 05/15] c6x: use of_platform_default_populate() to
 populate default bus
In-Reply-To: <1453868872-26300-6-git-send-email-wangkefeng.wang@huawei.com>
References: <1453868872-26300-1-git-send-email-wangkefeng.wang@huawei.com>
 <1453868872-26300-6-git-send-email-wangkefeng.wang@huawei.com>
Message-ID: <1455231129.3767.61.camel@redhat.com>

On Wed, 2016-01-27 at 12:27 +0800, Kefeng Wang wrote:
> Use helper of_platform_default_populate() in linux/of_platform
> when possible, instead of calling of_platform_populate() with
> the default match table.
> 
> Cc: Mark Salter <msalter at redhat.com>
> Cc: Aurelien Jacquiot <a-jacquiot at ti.com>
> Signed-off-by: Kefeng Wang <wangkefeng.wang at huawei.com>
> ---

Acked-by: Mark Salter <msalter at redhat.com>

> ?arch/c6x/platforms/platform.c | 2 +-
> ?1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/c6x/platforms/platform.c b/arch/c6x/platforms/platform.c
> index 26c1a35..8412334 100644
> --- a/arch/c6x/platforms/platform.c
> +++ b/arch/c6x/platforms/platform.c
> @@ -11,7 +11,7 @@
> ?
> ?static int __init c6x_device_probe(void)
> ?{
> -	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +	of_platform_default_populate(NULL, NULL, NULL);
> ?	return 0;
> ?}
> ?core_initcall(c6x_device_probe);



From dinguyen at opensource.altera.com  Thu Feb 11 14:47:36 2016
From: dinguyen at opensource.altera.com (dinguyen at opensource.altera.com)
Date: Thu, 11 Feb 2016 16:47:36 -0600
Subject: [PATCH] ARM: socfpga_defconfig: enable support for initramfs/initrd
 support
Message-ID: <1455230856-19648-1-git-send-email-dinguyen@opensource.altera.com>

From: Dinh Nguyen <dinguyen at opensource.altera.com>

Enable CONFIG_BLK_DEV_INITRD.

Signed-off-by: Dinh Nguyen <dinguyen at opensource.altera.com>
---
 arch/arm/configs/socfpga_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig
index f7f4e2e..753f1a5 100644
--- a/arch/arm/configs/socfpga_defconfig
+++ b/arch/arm/configs/socfpga_defconfig
@@ -7,6 +7,7 @@ CONFIG_LOG_BUF_SHIFT=14
 CONFIG_CGROUPS=y
 CONFIG_CPUSETS=y
 CONFIG_NAMESPACES=y
+CONFIG_BLK_DEV_INITRD=y
 CONFIG_EMBEDDED=y
 CONFIG_PROFILING=y
 CONFIG_OPROFILE=y
@@ -107,4 +108,3 @@ CONFIG_DETECT_HUNG_TASK=y
 # CONFIG_SCHED_DEBUG is not set
 CONFIG_ENABLE_DEFAULT_TRACERS=y
 CONFIG_DEBUG_USER=y
-CONFIG_XZ_DEC=y
-- 
2.6.2



From Suravee.Suthikulpanit at amd.com  Thu Feb 11 14:59:56 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Fri, 12 Feb 2016 05:59:56 +0700
Subject: [PATCH V2 03/12] dtb: amd: Fix DMA ranges in device tree
In-Reply-To: <CAOesGMgOmmXY2X2bwOd-6m117o6VPpqer6BXrzNePuRPoiz_Nw@mail.gmail.com>
References: <1454954357-8395-1-git-send-email-Suravee.Suthikulpanit@amd.com>
 <1454954357-8395-4-git-send-email-Suravee.Suthikulpanit@amd.com>
 <2845776.WTPtnQzg8d@wuerfel> <56BBA80E.6090205@amd.com>
 <CAOesGMgOmmXY2X2bwOd-6m117o6VPpqer6BXrzNePuRPoiz_Nw@mail.gmail.com>
Message-ID: <56BD126C.1050301@amd.com>

Ok, I'll send the incremental patch out again.

Thanks,
Suravee

On 2/12/16 04:23, Olof Johansson wrote:
> Hi,
>
> On Wed, Feb 10, 2016 at 1:13 PM, Suravee Suthikulpanit
> <Suravee.Suthikulpanit at amd.com> wrote:
>> Hi Arnd,
>>
>>
>> On 2/9/16 21:57, Arnd Bergmann wrote:
>>>
>>> On Monday 08 February 2016 11:59:08 Suravee Suthikulpanit wrote:
>>>>
>>>> From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
>>>>
>>>> Fix DMA ranges of smb0 and pcie0 nodes in AMD Seattle SOC.
>>>>
>>>> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
>>>>
>>>
>>> This could use a changelog text to explain why it's broken and how the
>>> fix works.
>>>
>>>          Arnd
>>>
>>
>> So, I have not experience the breakage. However, IIUC, the GICv2m MSI frame
>> is also considered DMA-able. So, I think it should be included in the
>> dma-range specified here. Please let me know if my assumption is incorrect.
>> Otherwise, I will include more description in the commit log in my next rev.
>
> As I replied when I did it -- I've applied the patches, so respinning
> won't work. Instead, please follow up with incremental fixes to this
> series instead.
>
>
> Thanks,
>
> -Olof
>


From arnd at arndb.de  Thu Feb 11 15:01:18 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 00:01:18 +0100
Subject: [PATCH] ARM: socfpga_defconfig: enable support for
 initramfs/initrd support
In-Reply-To: <1455230856-19648-1-git-send-email-dinguyen@opensource.altera.com>
References: <1455230856-19648-1-git-send-email-dinguyen@opensource.altera.com>
Message-ID: <4776059.MG11XzgNhU@wuerfel>

On Thursday 11 February 2016 16:47:36 dinguyen at opensource.altera.com wrote:
> From: Dinh Nguyen <dinguyen at opensource.altera.com>
> 
> Enable CONFIG_BLK_DEV_INITRD.
> 
> Signed-off-by: Dinh Nguyen <dinguyen at opensource.altera.com>

What for?

	Arnd


From robh at kernel.org  Thu Feb 11 15:06:34 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 11 Feb 2016 17:06:34 -0600
Subject: [PATCH] ARM: boot: Add an implementation of strnlen for libfdt
Message-ID: <1455231994-12048-1-git-send-email-robh@kernel.org>

Recent versions of libfdt add a dependency on strnlen. Copy the
implementation in lib/string.c here, so we can update libfdt.

Signed-off-by: Rob Herring <robh at kernel.org>
---
Russell,

I have a pending libfdt update, so I'd like to take this thru the DT 
tree with your ack.

Rob

 arch/arm/boot/compressed/string.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
index 36e53ef..6894674 100644
--- a/arch/arm/boot/compressed/string.c
+++ b/arch/arm/boot/compressed/string.c
@@ -65,6 +65,15 @@ size_t strlen(const char *s)
 	return sc - s;
 }
 
+size_t strnlen(const char *s, size_t count)
+{
+	const char *sc;
+
+	for (sc = s; count-- && *sc != '\0'; ++sc)
+		/* nothing */;
+	return sc - s;
+}
+
 int memcmp(const void *cs, const void *ct, size_t count)
 {
 	const unsigned char *su1 = cs, *su2 = ct, *end = su1 + count;
-- 
2.5.0



From matthias.bgg at gmail.com  Thu Feb 11 15:14:14 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Fri, 12 Feb 2016 00:14:14 +0100
Subject: [PATCH v2 5/6] serial: 8250/mediatek: fix building with
 SERIAL_8250=m
In-Reply-To: <1455205297-1021302-6-git-send-email-arnd@arndb.de>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
 <1455205297-1021302-6-git-send-email-arnd@arndb.de>
Message-ID: <56BD15C6.6040006@gmail.com>



On 11/02/16 16:41, Arnd Bergmann wrote:
> The Mediatek 8250 driver has a 'bool' Kconfig symbol, but that
> breaks when SERIAL_8250 is a loadable module:
>
> drivers/tty/built-in.o: In function `mtk8250_set_termios':
> :(.text+0x1bee8): undefined reference to `serial8250_do_set_termios'
> :(.text+0x1bf10): undefined reference to `uart_get_baud_rate'
> :(.text+0x1c09c): undefined reference to `uart_get_divisor'
> drivers/tty/built-in.o: In function `mtk8250_do_pm':
> :(.text+0x1c0d0): undefined reference to `serial8250_do_pm'
> drivers/tty/built-in.o: In function `mtk8250_probe':
> :(.text+0x1c2e4): undefined reference to `serial8250_register_8250_port'
> serial/8250/8250_mtk.c:287:242: error: data definition has no type or storage class [-Werror]
> serial/8250/8250_mtk.c:287:122: error: 'mtk8250_platform_driver_init' defined but not used [-Werror=unused-function]
>
> This changes the symbol to a 'tristate', so the dependency on
> SERIAL_8250 also works when that is set to 'm'.
> To actually build the driver, we also need to include <linux/module.h>.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---

Acked-by: Matthias Brugger <matthias.bgg at gmail.com>


From robh+dt at kernel.org  Thu Feb 11 15:15:27 2016
From: robh+dt at kernel.org (Rob Herring)
Date: Thu, 11 Feb 2016 17:15:27 -0600
Subject: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
In-Reply-To: <56BC6ABA.5020605@arm.com>
References: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
 <56BC6ABA.5020605@arm.com>
Message-ID: <CAL_JsqLScMdfUAtMPDGWphc_PZp4K-c0MfjRZh9G7=A9pLZu9Q@mail.gmail.com>

On Thu, Feb 11, 2016 at 5:04 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 09/02/16 11:04, Robin Murphy wrote:
>> The existing msi-map code is fine for shifting the entire RID space
>> upwards, but attempting finer-grained remapping reveals a bug. It turns
>> out that we are mistakenly treating the msi-base part as an offset, not
>> as a new base to remap onto, so things get squiffy when rid-base is
>> nonzero. Fix this, and at the same time add a sanity check against
>> having msi-map-mask clash with a nonzero rid-base, as that's another
>> thing one can easily get wrong.
>>
>> CC: <stable at vger.kernel.org>
>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>
> Rob, Frank,
>
> Are you willing to take this one through the OF tree? Or should we route
> it through the IRQ tree? It'd be good if it make it into 4.5.

Applied for 4.5. ATM, I don't have anything else to send to Linus.
I'll give it a week or so if this is not urgent. Or send me a bunch of
DT binding fixes and you can get it in sooner. ;)

Rob


From linux at arm.linux.org.uk  Thu Feb 11 15:24:34 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 11 Feb 2016 23:24:34 +0000
Subject: [PATCH] ARM: boot: Add an implementation of strnlen for libfdt
In-Reply-To: <1455231994-12048-1-git-send-email-robh@kernel.org>
References: <1455231994-12048-1-git-send-email-robh@kernel.org>
Message-ID: <20160211232434.GZ10826@n2100.arm.linux.org.uk>

On Thu, Feb 11, 2016 at 05:06:34PM -0600, Rob Herring wrote:
> Recent versions of libfdt add a dependency on strnlen. Copy the
> implementation in lib/string.c here, so we can update libfdt.
> 
> Signed-off-by: Rob Herring <robh at kernel.org>

Thanks.

Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>

> ---
> Russell,
> 
> I have a pending libfdt update, so I'd like to take this thru the DT 
> tree with your ack.
> 
> Rob
> 
>  arch/arm/boot/compressed/string.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/boot/compressed/string.c b/arch/arm/boot/compressed/string.c
> index 36e53ef..6894674 100644
> --- a/arch/arm/boot/compressed/string.c
> +++ b/arch/arm/boot/compressed/string.c
> @@ -65,6 +65,15 @@ size_t strlen(const char *s)
>  	return sc - s;
>  }
>  
> +size_t strnlen(const char *s, size_t count)
> +{
> +	const char *sc;
> +
> +	for (sc = s; count-- && *sc != '\0'; ++sc)
> +		/* nothing */;
> +	return sc - s;
> +}
> +
>  int memcmp(const void *cs, const void *ct, size_t count)
>  {
>  	const unsigned char *su1 = cs, *su2 = ct, *end = su1 + count;
> -- 
> 2.5.0
> 

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From matthias.bgg at gmail.com  Thu Feb 11 15:27:40 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Fri, 12 Feb 2016 00:27:40 +0100
Subject: [PATCH v3 5/5] arm: dts: Add pinctrl/GPIO/EINT node for mt2701
In-Reply-To: <CACRpkdbc-tNaeMzzX2riwUFPp0-XjVfvjuM6knWzVVwP89ECdA@mail.gmail.com>
References: <1451286546-5920-1-git-send-email-biao.huang@mediatek.com>
 <1451286546-5920-6-git-send-email-biao.huang@mediatek.com>
 <5685104D.7070008@gmail.com>
 <CACRpkdbc-tNaeMzzX2riwUFPp0-XjVfvjuM6knWzVVwP89ECdA@mail.gmail.com>
Message-ID: <56BD18EC.3090601@gmail.com>



On 07/01/16 11:14, Linus Walleij wrote:
> On Thu, Dec 31, 2015 at 12:23 PM, Matthias Brugger
> <matthias.bgg at gmail.com> wrote:
>> On 28/12/15 08:09, Biao Huang wrote:
>>>
>>> Add pinctrl and GPIO node to mt2701.dtsi
>>>
>>> Signed-off-by: Biao Huang <biao.huang at mediatek.com>
>>> Acked-by: Linus Walleij <linus.walleij at linaro.org>
>>> ---
>>>    arch/arm/boot/dts/mt2701.dtsi |   19 +++++++++++++++++++
>>>    1 file changed, 19 insertions(+)
>>>
>>
>> Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
>>
>> Linus, will you take this patch through your branch?
>
> No I prefer anything in arch/arm/boot/dts/* to go in through
> the ARM SoC tree.
>
> It can usually be merged orthogonally anyways.
>
> I take Documenation/devicetree/bindings/* and patches
> to the driver itself in drivers/pinctrl/*
>
> Yours,
> Linus Walleij
>

Applied, thanks.


From milo.kim at ti.com  Thu Feb 11 16:14:37 2016
From: milo.kim at ti.com (Kim, Milo)
Date: Fri, 12 Feb 2016 09:14:37 +0900
Subject: [PATCH v2 2/4] regulator: lp872x: Add enable GPIO pin support
In-Reply-To: <1454697741-8687-3-git-send-email-contact@paulk.fr>
References: <1454697741-8687-1-git-send-email-contact@paulk.fr>
 <1454697741-8687-3-git-send-email-contact@paulk.fr>
Message-ID: <56BD23ED.8010207@ti.com>

Hi Paul,

Thanks for the patch. Please see my comments below.

On 2/6/2016 3:42 AM, Paul Kocialkowski wrote:
> LP872x regulators are made active via the EN pin, which might be hooked to a
> GPIO. This adds support for driving the GPIO high when the driver is in use.
>
> Signed-off-by: Paul Kocialkowski <contact at paulk.fr>
> ---
>   .../devicetree/bindings/regulator/lp872x.txt       |  1 +
>   drivers/regulator/lp872x.c                         | 34 ++++++++++++++++++++++
>   include/linux/regulator/lp872x.h                   |  5 ++++
>   3 files changed, 40 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/regulator/lp872x.txt b/Documentation/devicetree/bindings/regulator/lp872x.txt
> index 7818318..ca58a68 100644
> --- a/Documentation/devicetree/bindings/regulator/lp872x.txt
> +++ b/Documentation/devicetree/bindings/regulator/lp872x.txt
> @@ -28,6 +28,7 @@ Optional properties:
>     - ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x devices.
>     - ti,dvs-vsel: DVS selector. 0 = SEL_V1, 1 = SEL_V2.
>     - ti,dvs-state: initial DVS pin state. 0 = DVS_LOW, 1 = DVS_HIGH.
> +  - enable-gpios: GPIO specifier for EN pin control of LP872x devices.
>
>     Sub nodes for regulator_init_data
>       LP8720 has maximum 6 nodes. (child name: ldo1 ~ 5 and buck)
> diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
> index 21c49d8..3899211 100644
> --- a/drivers/regulator/lp872x.c
> +++ b/drivers/regulator/lp872x.c
> @@ -15,6 +15,7 @@
>   #include <linux/regmap.h>
>   #include <linux/err.h>
>   #include <linux/gpio.h>
> +#include <linux/delay.h>
>   #include <linux/regulator/lp872x.h>
>   #include <linux/regulator/driver.h>
>   #include <linux/platform_device.h>
> @@ -757,6 +758,33 @@ set_default_dvs_mode:
>   				default_dvs_mode[lp->chipid]);
>   }
>
> +static int lp872x_hw_enable(struct lp872x *lp)
> +{
> +	int ret, gpio;
> +
> +	if (!lp->pdata)
> +		return -EINVAL;
> +
> +	gpio = lp->pdata->enable_gpio;
> +	if (!gpio_is_valid(gpio))
> +		return 0;

It seems gpio is always 0 when it starts from DT. 'enable_gpio' is 
updated in lp872x_config() but lp872x_hw_enable() is called first.

> +
> +	/* Always set enable GPIO high. */
> +	ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, "LP872X EN");
> +	if (ret) {
> +		dev_err(lp->dev, "gpio request err: %d\n", ret);
> +		return ret;
> +	}
> +
> +	/* Each chip has a different enable delay. */
> +	if (lp->chipid == LP8720)
> +		usleep_range(LP8720_ENABLE_DELAY, 1.5 * LP8720_ENABLE_DELAY);
> +	else
> +		usleep_range(LP8725_ENABLE_DELAY, 1.5 * LP8725_ENABLE_DELAY);
> +
> +	return 0;
> +}
> +
>   static int lp872x_config(struct lp872x *lp)
>   {
>   	struct lp872x_platform_data *pdata = lp->pdata;
> @@ -875,6 +903,8 @@ static struct lp872x_platform_data
>   	of_property_read_u8(np, "ti,dvs-state", &dvs_state);
>   	pdata->dvs->init_state = dvs_state ? DVS_HIGH : DVS_LOW;
>
> +	pdata->enable_gpio = of_get_named_gpio(np, "enable-gpios", 0);

Please move this code to lp872x_populate_pdata_from_dt().
lp872x_hw_enable() is called prior to lp872x_config(), so enable_gpio 
should be set on parsing the DT properties.

> +
>   	if (of_get_child_count(np) == 0)
>   		goto out;
>
> @@ -948,6 +978,10 @@ static int lp872x_probe(struct i2c_client *cl, const struct i2c_device_id *id)
>   	lp->chipid = id->driver_data;
>   	i2c_set_clientdata(cl, lp);
>
> +	ret = lp872x_hw_enable(lp);
> +	if (ret)
> +		return ret;
> +
>   	ret = lp872x_config(lp);
>   	if (ret)
>   		return ret;
> diff --git a/include/linux/regulator/lp872x.h b/include/linux/regulator/lp872x.h
> index 132e05c..6029279 100644
> --- a/include/linux/regulator/lp872x.h
> +++ b/include/linux/regulator/lp872x.h
> @@ -18,6 +18,9 @@
>
>   #define LP872X_MAX_REGULATORS		9
>
> +#define LP8720_ENABLE_DELAY		200
> +#define LP8725_ENABLE_DELAY		30000
> +
>   enum lp872x_regulator_id {
>   	LP8720_ID_BASE,
>   	LP8720_ID_LDO1 = LP8720_ID_BASE,
> @@ -79,12 +82,14 @@ struct lp872x_regulator_data {
>    * @update_config     : if LP872X_GENERAL_CFG register is updated, set true
>    * @regulator_data    : platform regulator id and init data
>    * @dvs               : dvs data for buck voltage control
> + * @enable_gpio       : gpio pin number for enable control
>    */
>   struct lp872x_platform_data {
>   	u8 general_config;
>   	bool update_config;
>   	struct lp872x_regulator_data regulator_data[LP872X_MAX_REGULATORS];
>   	struct lp872x_dvs *dvs;
> +	int enable_gpio;
>   };
>
>   #endif
>

Best regards,
Milo


From milo.kim at ti.com  Thu Feb 11 16:14:20 2016
From: milo.kim at ti.com (Kim, Milo)
Date: Fri, 12 Feb 2016 09:14:20 +0900
Subject: [PATCH v2 1/4] regulator: lp872x: Remove warning about invalid
 DVS GPIO
In-Reply-To: <1454697741-8687-2-git-send-email-contact@paulk.fr>
References: <1454697741-8687-1-git-send-email-contact@paulk.fr>
 <1454697741-8687-2-git-send-email-contact@paulk.fr>
Message-ID: <56BD23DC.30901@ti.com>

On 2/6/2016 3:42 AM, Paul Kocialkowski wrote:
> Some devices don't hook the DVS pin to a GPIO but to ground or VCC.
> In those cases, it is not a problem to have no DVS GPIO provided, as the current
> code will already switch to software-only DVS selection:
>
> When the DVS GPIO is invalid, lp872x_init_dvs jumps to the set_default_dvs_mode
> label, which instructs the chip not to use the DVS pin at all and do it all in
> software instead (by clearing the LP8720_EXT_DVS_M bit in the
> LP872X_GENERAL_CFG register).
>
> That is reflected later in the code, when setting the bucks (the DVS pin only
> applies to the bucks) by checking for the LP8720_EXT_DVS_M bit on the
> LP872X_GENERAL_CFG register (in lp872x_select_buck_vout_addr) to decide whether
> to use software or hardware DVS selection.
>
> Thus, there is no need to print a warning when the DVS GPIO is invalid.
>
> Signed-off-by: Paul Kocialkowski <contact at paulk.fr>

Acked-by: Milo Kim <milo.kim at ti.com>

> ---
>   drivers/regulator/lp872x.c | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
> index 19d7584..21c49d8 100644
> --- a/drivers/regulator/lp872x.c
> +++ b/drivers/regulator/lp872x.c
> @@ -738,10 +738,8 @@ static int lp872x_init_dvs(struct lp872x *lp)
>   		goto set_default_dvs_mode;
>
>   	gpio = dvs->gpio;
> -	if (!gpio_is_valid(gpio)) {
> -		dev_warn(lp->dev, "invalid gpio: %d\n", gpio);
> +	if (!gpio_is_valid(gpio))
>   		goto set_default_dvs_mode;
> -	}
>
>   	pinstate = dvs->init_state;
>   	ret = devm_gpio_request_one(lp->dev, gpio, pinstate, "LP872X DVS");
>


From Suravee.Suthikulpanit at amd.com  Thu Feb 11 16:20:43 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Fri, 12 Feb 2016 07:20:43 +0700
Subject: [PATCH] dtb: amd: Fix-up for ccn504 and kcs nodes
Message-ID: <1455236443-23949-1-git-send-email-Suravee.Suthikulpanit@amd.com>

From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

This is a fix-up patch based on the review comment from
Arnd regarding:
    * fix ccn504 address in the node name
    * remove kcs interrupt-name

Signed-off-by: Brijesh Singh <brijesh.singh at amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
Cc: Arnd Bergmann <arnd at arndb.de>
---

Hi Olof,

Here are the changes from the V3 that I sent earlier. Sorry for confusion.
Would you please pull this into the next tree?

Thank you,
Suravee

 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index a7fc059..bd3adea 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -231,7 +231,7 @@
 		};
 
 		/* Perf CCN504 PMU */
-		ccn: ccn at 0xe8000000 {
+		ccn: ccn at e8000000 {
 			compatible = "arm,ccn-504";
 			reg = <0x0 0xe8000000 0 0x1000000>;
 			interrupts = <0 380 4>;
@@ -243,7 +243,6 @@
 			device_type = "ipmi";
 			reg = <0x0 0xe0010000 0 0x8>;
 			interrupts = <0 389 4>;
-			interrupt-names = "ipmi_kcs";
 			reg-size = <1>;
 			reg-spacing = <4>;
 		};
-- 
2.5.0



From khilman at baylibre.com  Thu Feb 11 16:40:14 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Thu, 11 Feb 2016 16:40:14 -0800
Subject: [PATCH] ARM: socfpga_defconfig: enable support for
 initramfs/initrd support
In-Reply-To: <4776059.MG11XzgNhU@wuerfel> (Arnd Bergmann's message of "Fri, 12
 Feb 2016 00:01:18 +0100")
References: <1455230856-19648-1-git-send-email-dinguyen@opensource.altera.com>
 <4776059.MG11XzgNhU@wuerfel>
Message-ID: <7hwpqaoj69.fsf@baylibre.com>

Arnd Bergmann <arnd at arndb.de> writes:

> On Thursday 11 February 2016 16:47:36 dinguyen at opensource.altera.com wrote:
>> From: Dinh Nguyen <dinguyen at opensource.altera.com>
>> 
>> Enable CONFIG_BLK_DEV_INITRD.
>> 
>> Signed-off-by: Dinh Nguyen <dinguyen at opensource.altera.com>
>
> What for?
>

So the board farms doing boot testing can do so with an initramfs.

Acked-by: Kevin Hilman <khilman at baylibre.com>

Kevin


From khilman at baylibre.com  Thu Feb 11 17:13:23 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Thu, 11 Feb 2016 17:13:23 -0800
Subject: [PATCH 6/7] ARM: OMAP2+: Improve omap_device error for driver
 writers
In-Reply-To: <1455145370-20301-7-git-send-email-tony@atomide.com> (Tony
 Lindgren's message of "Wed, 10 Feb 2016 15:02:49 -0800")
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-7-git-send-email-tony@atomide.com>
Message-ID: <7hfuwy6898.fsf@baylibre.com>

Tony Lindgren <tony at atomide.com> writes:

> Drivers using pm_runtime_use_autosuspend() may not get disabled after
> -EPROBE_DEFER. On the following device driver probe, hardware state
> is different from the PM runtime state causing omap_device to produce
> the following error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> Let's add a proper error message so driver writers can easily fix
> their drivers for PM.
>
> In general, the solution is to fix the drivers to follow the PM
> runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Let's not return with 0 from _od_runtime_resume() as that will
> eventually lead into new drivers with broken PM runtime that will
> block deeper idle states on omaps.
>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Kevin Hilman <khilman at baylibre.com>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Rafael J. Wysocki <rafael at kernel.org>
> Cc: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Tero Kristo <t-kristo at ti.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>

Acked-by: Kevin Hilman <khilman at baylibre.com>

> ---
>  arch/arm/mach-omap2/omap_device.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 0437537..ebd8369 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -602,8 +602,10 @@ static int _od_runtime_resume(struct device *dev)
>  	int ret;
>  
>  	ret = omap_device_enable(pdev);
> -	if (ret)
> +	if (ret) {
> +		dev_err(dev, "use pm_runtime_put_sync_suspend() in driver?\n");
>  		return ret;
> +	}
>  
>  	return pm_generic_runtime_resume(dev);
>  }


From khilman at baylibre.com  Thu Feb 11 17:13:37 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Thu, 11 Feb 2016 17:13:37 -0800
Subject: [PATCH 7/7] ARM: OMAP2+: Fix omap_device for module reload on PM
 runtime forbid
In-Reply-To: <1455145370-20301-8-git-send-email-tony@atomide.com> (Tony
 Lindgren's message of "Wed, 10 Feb 2016 15:02:50 -0800")
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-8-git-send-email-tony@atomide.com>
Message-ID: <7hbn7m688u.fsf@baylibre.com>

Tony Lindgren <tony at atomide.com> writes:

> If a driver PM runtime is disabled via sysfs, and the module is
> unloaded, PM runtime can't do anything to disable the device. Let's
> let the interconnect disable the device on BUS_NOTIFY_UNBOUND_DRIVER.
>
> Otherwise omap_device will produce and error on the following module
> reload. This can be easily tested with something like:
>
> # modprobe omap_hsmmc
> # echo on > /sys/devices/platform/68000000.ocp/4809c000.mmc/power/control
> # rmmod omap_hsmmc
> # modprobe omap_hsmmc
>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Kevin Hilman <khilman at baylibre.com>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Rafael J. Wysocki <rafael at kernel.org>
> Cc: Tero Kristo <t-kristo at ti.com>
> Reported-by: Ulf Hansson <ulf.hansson at linaro.org>
> Signed-off-by: Tony Lindgren <tony at atomide.com>

Acked-by: Kevin Hilman <khilman at baylibre.com>

> ---
>  arch/arm/mach-omap2/omap_device.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index ebd8369..f7ff3b9 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -191,12 +191,22 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
>  {
>  	struct platform_device *pdev = to_platform_device(dev);
>  	struct omap_device *od;
> +	int err;
>  
>  	switch (event) {
>  	case BUS_NOTIFY_DEL_DEVICE:
>  		if (pdev->archdata.od)
>  			omap_device_delete(pdev->archdata.od);
>  		break;
> +	case BUS_NOTIFY_UNBOUND_DRIVER:
> +		od = to_omap_device(pdev);
> +		if (od && (od->_state == OMAP_DEVICE_STATE_ENABLED)) {
> +			dev_info(dev, "enabled after unload, idling\n");
> +			err = omap_device_idle(pdev);
> +			if (err)
> +				dev_err(dev, "failed to idle\n");
> +		}
> +		break;
>  	case BUS_NOTIFY_ADD_DEVICE:
>  		if (pdev->dev.of_node)
>  			omap_device_build_from_dt(pdev);


From wens at csie.org  Thu Feb 11 18:02:39 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 12 Feb 2016 10:02:39 +0800
Subject: [PATCH v8 02/10] mfd: axp20x: Remove second struct device * parameter
 for axp20x_match_device()
In-Reply-To: <1455242567-17880-1-git-send-email-wens@csie.org>
References: <1455242567-17880-1-git-send-email-wens@csie.org>
Message-ID: <1455242567-17880-3-git-send-email-wens@csie.org>

The first argument passed to axp20x_match_device(), struct axp20x_dev *,
already contains a pointer to the device. By rearranging some code,
moving the assignment of the pointer before axp20x_match_device() is
called, we can eliminate the second parameter.

Suggested-by: Andy Shevchenko <andy.shevchenko at gmail.com>
Signed-off-by: Chen-Yu Tsai <wens at csie.org>
Acked-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mfd/axp20x.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 9842199e2e6c..685a78614f83 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -606,8 +606,9 @@ static void axp20x_power_off(void)
 		     AXP20X_OFF);
 }
 
-static int axp20x_match_device(struct axp20x_dev *axp20x, struct device *dev)
+static int axp20x_match_device(struct axp20x_dev *axp20x)
 {
+	struct device *dev = axp20x->dev;
 	const struct acpi_device_id *acpi_id;
 	const struct of_device_id *of_id;
 
@@ -673,14 +674,14 @@ static int axp20x_i2c_probe(struct i2c_client *i2c,
 	if (!axp20x)
 		return -ENOMEM;
 
-	ret = axp20x_match_device(axp20x, &i2c->dev);
-	if (ret)
-		return ret;
-
 	axp20x->i2c_client = i2c;
 	axp20x->dev = &i2c->dev;
 	dev_set_drvdata(axp20x->dev, axp20x);
 
+	ret = axp20x_match_device(axp20x);
+	if (ret)
+		return ret;
+
 	axp20x->regmap = devm_regmap_init_i2c(i2c, axp20x->regmap_cfg);
 	if (IS_ERR(axp20x->regmap)) {
 		ret = PTR_ERR(axp20x->regmap);
-- 
2.7.0



From wens at csie.org  Thu Feb 11 18:02:41 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 12 Feb 2016 10:02:41 +0800
Subject: [PATCH v8 04/10] mfd: axp20x: Add missing copyright notice
In-Reply-To: <1455242567-17880-1-git-send-email-wens@csie.org>
References: <1455242567-17880-1-git-send-email-wens@csie.org>
Message-ID: <1455242567-17880-5-git-send-email-wens@csie.org>

Supply a backdated copyright notice.

Cc: Carlo Caione <carlo at caione.org>
Signed-off-by: Chen-Yu Tsai <wens at csie.org>
Acked-by: Carlo Caione <carlo at caione.org>
Acked-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mfd/axp20x.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 3e186f2dcac3..cec51e689d1d 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -5,6 +5,8 @@
  * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
  * as well as configurable GPIOs.
  *
+ * Copyright (C) 2014 Carlo Caione
+ *
  * Author: Carlo Caione <carlo at caione.org>
  *
  * This program is free software; you can redistribute it and/or modify
-- 
2.7.0



From wens at csie.org  Thu Feb 11 18:02:37 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 12 Feb 2016 10:02:37 +0800
Subject: [PATCH v8 00/10] mfd: axp20x: Add support for RSB based AXP223
Message-ID: <1455242567-17880-1-git-send-email-wens@csie.org>

Hi everyone,

This is v8 of the AXP223 PMIC series. All the driver bits are acked.
Lee, please merge the first 8 patches. Once they're in, Maxime can take
the DTS patches.

Changes since v7:

  - Shortened commit message of "mfd: axp20x: Add missing copyright notice"

Changes since v6:

  - Add copyright notice to axp20x-rsb.c

  - Correct order of header files in axp20x-rsb.c

  - Use generic dev_set_drvdata() instead of sunxi_rsb_device_set_drvdata()

  - Drop file name from file headers

  - Add patch adding missing copyright notice for original axp20x author

Changes since v5:

  - Correct AXP223 address to 0x3a3.

Changes since v4:

  - Get rid of second parameter of axp20x_match_device() (new patch 2)

  - Match against dev->driver->of_match_table, so the entirety of
    axp20x_match_device() can be kept in the core. (new patch 3)

  - Move *_device_id tables to bottom of the driver, right above driver
    declaration. (patch 4 & 6)

  - Remove extra whitespaces while moving i2c specific code (patch 4)

  - Remove leftover whitespace and code style issues in axp20x core
    (new patch 5)

  - Remove extra whitespaces in rsb specific code (patch 6)

Changes since v3:

  - Removed settings for axp223 reg_rtc_ldo from board dts files that
    are already in axp22x.dtsi. The name is kept.

  - Dropped simplefb label and defconfig patches, as they are merged.

Changes since v2:

  - s/It's/Its/ for the commit messages of patches 5 and 7

  - Add Rob's Acked-by for patch 1

Changes since v1:

  - Dropped NMI interrupt controller dts patch (Merged)

  - Change MFD_AXP20X to represent the axp20x core, and drop MFD_AXP20X_CORE
  
  - Keep the axp20x core bits named axp20x.c

  - Add patch 7 to add AXP223 to sun8i-q8-common.dtsi

  - Add patch 8 & 9 to update defconfigs

  - Make axp20x drivers tristate and buildable as modules

  - Drop "_sunxi" substring from identifiers in axp20x-rsb driver


This series adds support for the Reduced Serial Bus based AXP223 PMIC.
The AXP223 is functionally identical to the AXP221, which we already
support. Only some default values for the regulators are different.
The defaults fit their recommended application, paired with different
SoCs.

Patch 1 adds AXP223 to the list of supported chips in the DT binding.

Patch 2 gets rid of the extra "struct device *" parameter from
axp20x_match_device().

Patch 3 makes axp20x_match_device() use dev->driver->of_match_table,
so the function can be library-ized without modification.

Patch 4 adds the missing copyright notice for axp20x's original author.

Patch 5 splits the axp20x mfd driver into 2 parts, a core library, and
an I2C driver.

Patch 6 cleans up some leftover whitespace issues in axp20x core.

Patch 7 adds an RSB based driver for the AXP223.

Patch 8 adds support for the AXP223 regulators

Patch 9 enables the AXP223 PMIC and its regulators for the Sinlinx
SinA33.

Patch 10 enables the AXP223 PMIC and its regulators for A23/A33 based
Q8 tablet devices.


Regards
ChenYu


Chen-Yu Tsai (10):
  mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings
  mfd: axp20x: Remove second struct device * parameter for
    axp20x_match_device()
  mfd: axp20x: use dev->driver->of_match_table in axp20x_match_device()
  mfd: axp20x: Add missing copyright notice
  mfd: axp20x: Split the driver into core and i2c bits
  mfd: axp20x: Whitespace, open parenthesis alignment code style fixes
  mfd: axp20x: Add support for RSB based AXP223 PMIC
  regulator: axp20x: Support new AXP223 PMIC
  ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC device and regulator
    nodes
  ARM: dts: sun8i: q8-common: Add AXP223 PMIC device and regulator nodes

 Documentation/devicetree/bindings/mfd/axp20x.txt |   7 +-
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts   |  76 +++++++++++++++-
 arch/arm/boot/dts/sun8i-q8-common.dtsi           |  83 +++++++++++++++++-
 drivers/mfd/Kconfig                              |  25 ++++--
 drivers/mfd/Makefile                             |   2 +
 drivers/mfd/axp20x-i2c.c                         | 104 ++++++++++++++++++++++
 drivers/mfd/axp20x-rsb.c                         |  80 +++++++++++++++++
 drivers/mfd/axp20x.c                             | 105 ++++++-----------------
 drivers/regulator/axp20x-regulator.c             |   3 +
 include/linux/mfd/axp20x.h                       |  34 +++++++-
 10 files changed, 425 insertions(+), 94 deletions(-)
 create mode 100644 drivers/mfd/axp20x-i2c.c
 create mode 100644 drivers/mfd/axp20x-rsb.c

-- 
2.7.0



From wens at csie.org  Thu Feb 11 18:02:40 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 12 Feb 2016 10:02:40 +0800
Subject: [PATCH v8 03/10] mfd: axp20x: use dev->driver->of_match_table in
 axp20x_match_device()
In-Reply-To: <1455242567-17880-1-git-send-email-wens@csie.org>
References: <1455242567-17880-1-git-send-email-wens@csie.org>
Message-ID: <1455242567-17880-4-git-send-email-wens@csie.org>

In axp20x_match_device(), match the of_device_id table bound to the
device driver instead of pointing to axp20x_of_match directly. This
will allow us to keep axp20x_match_device() unmodified when we expand
the axp20x driver into multiple ones covering different interface
types.

of_device_get_match_data() cannot be used here as we need to know if
it failed to get a match, or if the match data value just happened to
be 0, as it is for the AXP152.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
Acked-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mfd/axp20x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 685a78614f83..3e186f2dcac3 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -613,7 +613,7 @@ static int axp20x_match_device(struct axp20x_dev *axp20x)
 	const struct of_device_id *of_id;
 
 	if (dev->of_node) {
-		of_id = of_match_device(axp20x_of_match, dev);
+		of_id = of_match_device(dev->driver->of_match_table, dev);
 		if (!of_id) {
 			dev_err(dev, "Unable to match OF ID\n");
 			return -ENODEV;
-- 
2.7.0



From wens at csie.org  Thu Feb 11 18:02:38 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 12 Feb 2016 10:02:38 +0800
Subject: [PATCH v8 01/10] mfd: axp20x: Add AXP223 to list of supported PMICs
 in DT bindings
In-Reply-To: <1455242567-17880-1-git-send-email-wens@csie.org>
References: <1455242567-17880-1-git-send-email-wens@csie.org>
Message-ID: <1455242567-17880-2-git-send-email-wens@csie.org>

The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Acked-by: Rob Herring <robh at kernel.org>
Acked-by: Lee Jones <lee.jones at linaro.org>
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
index a474359dd206..fd39fa54571b 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -5,11 +5,12 @@ axp152 (X-Powers)
 axp202 (X-Powers)
 axp209 (X-Powers)
 axp221 (X-Powers)
+axp223 (X-Powers)
 
 Required properties:
 - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
-	      "x-powers,axp221"
-- reg: The I2C slave address for the AXP chip
+	      "x-powers,axp221", "x-powers,axp223"
+- reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
 - interrupt-controller: The PMIC has its own internal IRQs
@@ -51,7 +52,7 @@ LDO3		: LDO		: ldo3in-supply
 LDO4		: LDO		: ldo24in-supply	: shared supply
 LDO5		: LDO		: ldo5in-supply
 
-AXP221 regulators, type, and corresponding input supply names:
+AXP221/AXP223 regulators, type, and corresponding input supply names:
 
 Regulator	  Type		  Supply Name		  Notes
 ---------	  ----		  -----------		  -----
-- 
2.7.0



From wens at csie.org  Thu Feb 11 18:02:45 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 12 Feb 2016 10:02:45 +0800
Subject: [PATCH v8 08/10] regulator: axp20x: Support new AXP223 PMIC
In-Reply-To: <1455242567-17880-1-git-send-email-wens@csie.org>
References: <1455242567-17880-1-git-send-email-wens@csie.org>
Message-ID: <1455242567-17880-9-git-send-email-wens@csie.org>

The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
Reviewed-by: Mark Brown <broonie at kernel.org>
---
 drivers/regulator/axp20x-regulator.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index f2e1a39ce0f3..e86d1fc2d80b 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -244,6 +244,7 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
 		step = 75;
 		break;
 	case AXP221_ID:
+	case AXP223_ID:
 		min = 1800;
 		max = 4050;
 		def = 3000;
@@ -322,6 +323,7 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev *rdev, int id, u32 work
 		break;
 
 	case AXP221_ID:
+	case AXP223_ID:
 		if (id < AXP22X_DCDC1 || id > AXP22X_DCDC5)
 			return -EINVAL;
 
@@ -360,6 +362,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		nregulators = AXP20X_REG_ID_MAX;
 		break;
 	case AXP221_ID:
+	case AXP223_ID:
 		regulators = axp22x_regulators;
 		nregulators = AXP22X_REG_ID_MAX;
 		break;
-- 
2.7.0



From wens at csie.org  Thu Feb 11 18:02:46 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 12 Feb 2016 10:02:46 +0800
Subject: [PATCH v8 09/10] ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC
 device and regulator nodes
In-Reply-To: <1455242567-17880-1-git-send-email-wens@csie.org>
References: <1455242567-17880-1-git-send-email-wens@csie.org>
Message-ID: <1455242567-17880-10-git-send-email-wens@csie.org>

This board has a X-Powers AXP223 PMIC connected via RSB. Its regulators
provide power to various parts of the SoC and the board.

Also update the regulator supply phandles.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 76 +++++++++++++++++++++++++-
 1 file changed, 73 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index bd2a3beb4629..fef6abc0a703 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -68,7 +68,7 @@
 };
 
 &lradc {
-	vref-supply = <&reg_vcc3v0>;
+	vref-supply = <&reg_dcdc1>;
 	status = "okay";
 
 	button at 200 {
@@ -96,7 +96,7 @@
 &mmc0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_sina33>;
-	vmmc-supply = <&reg_vcc3v0>;
+	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
 	cd-gpios = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
 	cd-inverted;
@@ -106,7 +106,7 @@
 &mmc2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc2_8bit_pins>;
-	vmmc-supply = <&reg_vcc3v0>;
+	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <8>;
 	non-removable;
 	cap-mmc-hw-reset;
@@ -135,6 +135,76 @@
 
 &r_rsb {
 	status = "okay";
+
+	axp22x: pmic at 3a3 {
+		compatible = "x-powers,axp223";
+		reg = <0x3a3>;
+		interrupt-parent = <&nmi_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+		eldoin-supply = <&reg_dcdc1>;
+	};
+};
+
+#include "axp22x.dtsi"
+
+&reg_aldo1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-io";
+};
+
+&reg_aldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <2350000>;
+	regulator-max-microvolt = <2650000>;
+	regulator-name = "vdd-dll";
+};
+
+&reg_aldo3 {
+	regulator-always-on;
+	regulator-min-microvolt = <2700000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-pll-avcc";
+};
+
+&reg_dc5ldo {
+	regulator-always-on;
+	regulator-min-microvolt = <900000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-cpus";
+};
+
+&reg_dcdc1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-3v0";
+};
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <900000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-sys";
+};
+
+&reg_dcdc3 {
+	regulator-always-on;
+	regulator-min-microvolt = <900000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-cpu";
+};
+
+&reg_dcdc5 {
+	regulator-always-on;
+	regulator-min-microvolt = <1500000>;
+	regulator-max-microvolt = <1500000>;
+	regulator-name = "vcc-dram";
+};
+
+&reg_rtc_ldo {
+	regulator-name = "vcc-rtc";
 };
 
 &uart0 {
-- 
2.7.0



From wens at csie.org  Thu Feb 11 18:02:43 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 12 Feb 2016 10:02:43 +0800
Subject: [PATCH v8 06/10] mfd: axp20x: Whitespace,
 open parenthesis alignment code style fixes
In-Reply-To: <1455242567-17880-1-git-send-email-wens@csie.org>
References: <1455242567-17880-1-git-send-email-wens@csie.org>
Message-ID: <1455242567-17880-7-git-send-email-wens@csie.org>

This fixes some leftover code style issues in the axp20x core.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
Acked-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mfd/axp20x.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 8e569bcfe3bc..3054ea4b95e8 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -593,14 +593,14 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
 			dev_err(dev, "Unable to match OF ID\n");
 			return -ENODEV;
 		}
-		axp20x->variant = (long) of_id->data;
+		axp20x->variant = (long)of_id->data;
 	} else {
 		acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
 		if (!acpi_id || !acpi_id->driver_data) {
 			dev_err(dev, "Unable to match ACPI ID and data\n");
 			return -ENODEV;
 		}
-		axp20x->variant = (long) acpi_id->driver_data;
+		axp20x->variant = (long)acpi_id->driver_data;
 	}
 
 	switch (axp20x->variant) {
@@ -634,7 +634,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
 		return -EINVAL;
 	}
 	dev_info(dev, "AXP20x variant %s found\n",
-		axp20x_model_names[axp20x->variant]);
+		 axp20x_model_names[axp20x->variant]);
 
 	return 0;
 }
@@ -654,7 +654,7 @@ int axp20x_device_probe(struct axp20x_dev *axp20x)
 	}
 
 	ret = mfd_add_devices(axp20x->dev, -1, axp20x->cells,
-			axp20x->nr_cells, NULL, 0, NULL);
+			      axp20x->nr_cells, NULL, 0, NULL);
 
 	if (ret) {
 		dev_err(axp20x->dev, "failed to add MFD devices: %d\n", ret);
-- 
2.7.0



From wens at csie.org  Thu Feb 11 18:02:47 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 12 Feb 2016 10:02:47 +0800
Subject: [PATCH v8 10/10] ARM: dts: sun8i: q8-common: Add AXP223 PMIC device
 and regulator nodes
In-Reply-To: <1455242567-17880-1-git-send-email-wens@csie.org>
References: <1455242567-17880-1-git-send-email-wens@csie.org>
Message-ID: <1455242567-17880-11-git-send-email-wens@csie.org>

A23/A33 Q8 tablets have an X-Powers AXP223 PMIC connected via RSB. Its
regulators provide power to various parts of the SoC and the board.

Also add lcd regulator supply for simplefb and update the existing
vmmc-supply for mmc0.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/boot/dts/sun8i-q8-common.dtsi | 83 +++++++++++++++++++++++++++++++++-
 1 file changed, 81 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi b/arch/arm/boot/dts/sun8i-q8-common.dtsi
index 1a69231d2da5..9d2b7e2f5975 100644
--- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
+++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
@@ -56,7 +56,6 @@
 		brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
 		default-brightness-level = <8>;
 		enable-gpios = <&pio 7 6 GPIO_ACTIVE_HIGH>; /* PH6 */
-		/* backlight is powered by AXP223 DC1SW */
 	};
 
 	chosen {
@@ -67,7 +66,7 @@
 &mmc0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_q8>;
-	vmmc-supply = <&reg_vcc3v0>;
+	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
 	cd-gpios = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
 	cd-inverted;
@@ -92,6 +91,82 @@
 
 &r_rsb {
 	status = "okay";
+
+	axp22x: pmic at 3a3 {
+		compatible = "x-powers,axp223";
+		reg = <0x3a3>;
+		interrupt-parent = <&nmi_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+		eldoin-supply = <&reg_dcdc1>;
+	};
+};
+
+#include "axp22x.dtsi"
+
+&reg_aldo1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-io";
+};
+
+&reg_aldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <2350000>;
+	regulator-max-microvolt = <2650000>;
+	regulator-name = "vdd-dll";
+};
+
+&reg_aldo3 {
+	regulator-always-on;
+	regulator-min-microvolt = <2700000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-pll-avcc";
+};
+
+&reg_dc1sw {
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-lcd";
+};
+
+&reg_dc5ldo {
+	regulator-always-on;
+	regulator-min-microvolt = <900000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-cpus";
+};
+
+&reg_dcdc1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "vcc-3v0";
+};
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <900000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-sys";
+};
+
+&reg_dcdc3 {
+	regulator-always-on;
+	regulator-min-microvolt = <900000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-cpu";
+};
+
+&reg_dcdc5 {
+	regulator-always-on;
+	regulator-min-microvolt = <1500000>;
+	regulator-max-microvolt = <1500000>;
+	regulator-name = "vcc-dram";
+};
+
+&reg_rtc_ldo {
+	regulator-name = "vcc-rtc";
 };
 
 &r_uart {
@@ -99,3 +174,7 @@
 	pinctrl-0 = <&r_uart_pins_a>;
 	status = "okay";
 };
+
+&simplefb_lcd {
+	vcc-lcd-supply = <&reg_dc1sw>;
+};
-- 
2.7.0



From wens at csie.org  Thu Feb 11 18:02:44 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 12 Feb 2016 10:02:44 +0800
Subject: [PATCH v8 07/10] mfd: axp20x: Add support for RSB based AXP223 PMIC
In-Reply-To: <1455242567-17880-1-git-send-email-wens@csie.org>
References: <1455242567-17880-1-git-send-email-wens@csie.org>
Message-ID: <1455242567-17880-8-git-send-email-wens@csie.org>

The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
Acked-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mfd/Kconfig        | 11 +++++++
 drivers/mfd/Makefile       |  1 +
 drivers/mfd/axp20x-rsb.c   | 80 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/mfd/axp20x.c       |  2 ++
 include/linux/mfd/axp20x.h |  1 +
 5 files changed, 95 insertions(+)
 create mode 100644 drivers/mfd/axp20x-rsb.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 0037b9c933d9..ae3990b5a2bf 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -107,6 +107,17 @@ config MFD_AXP20X_I2C
 	  components like regulators or the PEK (Power Enable Key) under the
 	  corresponding menus.
 
+config MFD_AXP20X_RSB
+	tristate "X-Powers AXP series PMICs with RSB"
+	select MFD_AXP20X
+	depends on SUNXI_RSB
+	help
+	  If you say Y here you get support for the X-Powers AXP series power
+	  management ICs (PMICs) controlled with RSB.
+	  This driver include only the core APIs. You have to select individual
+	  components like regulators or the PEK (Power Enable Key) under the
+	  corresponding menus.
+
 config MFD_CROS_EC
 	tristate "ChromeOS Embedded Controller"
 	select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index dba4f99d9044..c69ea744fd1a 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -112,6 +112,7 @@ obj-$(CONFIG_MFD_DA9052_SPI)	+= da9052-spi.o
 obj-$(CONFIG_MFD_DA9052_I2C)	+= da9052-i2c.o
 obj-$(CONFIG_MFD_AXP20X)	+= axp20x.o
 obj-$(CONFIG_MFD_AXP20X_I2C)	+= axp20x-i2c.o
+obj-$(CONFIG_MFD_AXP20X_RSB)	+= axp20x-rsb.o
 
 obj-$(CONFIG_MFD_LP3943)	+= lp3943.o
 obj-$(CONFIG_MFD_LP8788)	+= lp8788.o lp8788-irq.o
diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
new file mode 100644
index 000000000000..28c20247c112
--- /dev/null
+++ b/drivers/mfd/axp20x-rsb.c
@@ -0,0 +1,80 @@
+/*
+ * RSB driver for the X-Powers' Power Management ICs
+ *
+ * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK DC-DC
+ * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
+ * as well as configurable GPIOs.
+ *
+ * This driver supports the RSB variants.
+ *
+ * Copyright (C) 2015 Chen-Yu Tsai
+ *
+ * Author: Chen-Yu Tsai <wens at csie.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/acpi.h>
+#include <linux/err.h>
+#include <linux/mfd/axp20x.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/sunxi-rsb.h>
+
+static int axp20x_rsb_probe(struct sunxi_rsb_device *rdev)
+{
+	struct axp20x_dev *axp20x;
+	int ret;
+
+	axp20x = devm_kzalloc(&rdev->dev, sizeof(*axp20x), GFP_KERNEL);
+	if (!axp20x)
+		return -ENOMEM;
+
+	axp20x->dev = &rdev->dev;
+	axp20x->irq = rdev->irq;
+	dev_set_drvdata(&rdev->dev, axp20x);
+
+	ret = axp20x_match_device(axp20x);
+	if (ret)
+		return ret;
+
+	axp20x->regmap = devm_regmap_init_sunxi_rsb(rdev, axp20x->regmap_cfg);
+	if (IS_ERR(axp20x->regmap)) {
+		ret = PTR_ERR(axp20x->regmap);
+		dev_err(&rdev->dev, "regmap init failed: %d\n", ret);
+		return ret;
+	}
+
+	return axp20x_device_probe(axp20x);
+}
+
+static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
+{
+	struct axp20x_dev *axp20x = sunxi_rsb_device_get_drvdata(rdev);
+
+	return axp20x_device_remove(axp20x);
+}
+
+static const struct of_device_id axp20x_rsb_of_match[] = {
+	{ .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, axp20x_rsb_of_match);
+
+static struct sunxi_rsb_driver axp20x_rsb_driver = {
+	.driver = {
+		.name	= "axp20x-rsb",
+		.of_match_table	= of_match_ptr(axp20x_rsb_of_match),
+	},
+	.probe	= axp20x_rsb_probe,
+	.remove	= axp20x_rsb_remove,
+};
+module_sunxi_rsb_driver(axp20x_rsb_driver);
+
+MODULE_DESCRIPTION("PMIC MFD sunXi RSB driver for AXP20X");
+MODULE_AUTHOR("Chen-Yu Tsai <wens at csie.org>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 3054ea4b95e8..a57d6e940610 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -35,6 +35,7 @@ static const char * const axp20x_model_names[] = {
 	"AXP202",
 	"AXP209",
 	"AXP221",
+	"AXP223",
 	"AXP288",
 };
 
@@ -618,6 +619,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
 		axp20x->regmap_irq_chip = &axp20x_regmap_irq_chip;
 		break;
 	case AXP221_ID:
+	case AXP223_ID:
 		axp20x->nr_cells = ARRAY_SIZE(axp22x_cells);
 		axp20x->cells = axp22x_cells;
 		axp20x->regmap_cfg = &axp22x_regmap_config;
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index 00697c6ad8b0..d82e7d51372b 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -18,6 +18,7 @@ enum {
 	AXP202_ID,
 	AXP209_ID,
 	AXP221_ID,
+	AXP223_ID,
 	AXP288_ID,
 	NR_AXP20X_VARIANTS,
 };
-- 
2.7.0



From wens at csie.org  Thu Feb 11 18:02:42 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 12 Feb 2016 10:02:42 +0800
Subject: [PATCH v8 05/10] mfd: axp20x: Split the driver into core and i2c bits
In-Reply-To: <1455242567-17880-1-git-send-email-wens@csie.org>
References: <1455242567-17880-1-git-send-email-wens@csie.org>
Message-ID: <1455242567-17880-6-git-send-email-wens@csie.org>

The axp20x driver assumes the device is i2c based. This is not the
case with later chips, which use a proprietary 2 wire serial bus
by Allwinner called "Reduced Serial Bus".

This patch follows the example of mfd/wm831x and splits it into
an interface independent core, and an i2c specific glue layer.
MFD_AXP20X and the new MFD_AXP20X_I2C are changed to tristate
symbols, allowing the driver to be built as modules.

Whitespace and other style errors in the moved i2c specific code
have been fixed. Included but unused header files are removed as
well.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
Acked-by: Lee Jones <lee.jones at linaro.org>
---
 drivers/mfd/Kconfig        |  14 +++---
 drivers/mfd/Makefile       |   1 +
 drivers/mfd/axp20x-i2c.c   | 104 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/mfd/axp20x.c       |  90 +++++++--------------------------------
 include/linux/mfd/axp20x.h |  33 +++++++++++++-
 5 files changed, 161 insertions(+), 81 deletions(-)
 create mode 100644 drivers/mfd/axp20x-i2c.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 9ca66de0c1c1..0037b9c933d9 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -91,14 +91,18 @@ config MFD_BCM590XX
 	  Support for the BCM590xx PMUs from Broadcom
 
 config MFD_AXP20X
-	bool "X-Powers AXP20X"
+	tristate
 	select MFD_CORE
-	select REGMAP_I2C
 	select REGMAP_IRQ
-	depends on I2C=y
+
+config MFD_AXP20X_I2C
+	tristate "X-Powers AXP series PMICs with I2C"
+	select MFD_AXP20X
+	select REGMAP_I2C
+	depends on I2C
 	help
-	  If you say Y here you get support for the X-Powers AXP202, AXP209 and
-	  AXP288 power management IC (PMIC).
+	  If you say Y here you get support for the X-Powers AXP series power
+	  management ICs (PMICs) controlled with I2C.
 	  This driver include only the core APIs. You have to select individual
 	  components like regulators or the PEK (Power Enable Key) under the
 	  corresponding menus.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 0f230a6103f8..dba4f99d9044 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -111,6 +111,7 @@ obj-$(CONFIG_PMIC_DA9052)	+= da9052-core.o
 obj-$(CONFIG_MFD_DA9052_SPI)	+= da9052-spi.o
 obj-$(CONFIG_MFD_DA9052_I2C)	+= da9052-i2c.o
 obj-$(CONFIG_MFD_AXP20X)	+= axp20x.o
+obj-$(CONFIG_MFD_AXP20X_I2C)	+= axp20x-i2c.o
 
 obj-$(CONFIG_MFD_LP3943)	+= lp3943.o
 obj-$(CONFIG_MFD_LP8788)	+= lp8788.o lp8788-irq.o
diff --git a/drivers/mfd/axp20x-i2c.c b/drivers/mfd/axp20x-i2c.c
new file mode 100644
index 000000000000..b1b865822c07
--- /dev/null
+++ b/drivers/mfd/axp20x-i2c.c
@@ -0,0 +1,104 @@
+/*
+ * I2C driver for the X-Powers' Power Management ICs
+ *
+ * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK DC-DC
+ * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
+ * as well as configurable GPIOs.
+ *
+ * This driver supports the I2C variants.
+ *
+ * Copyright (C) 2014 Carlo Caione
+ *
+ * Author: Carlo Caione <carlo at caione.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/acpi.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/mfd/axp20x.h>
+#include <linux/of.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+static int axp20x_i2c_probe(struct i2c_client *i2c,
+			    const struct i2c_device_id *id)
+{
+	struct axp20x_dev *axp20x;
+	int ret;
+
+	axp20x = devm_kzalloc(&i2c->dev, sizeof(*axp20x), GFP_KERNEL);
+	if (!axp20x)
+		return -ENOMEM;
+
+	axp20x->dev = &i2c->dev;
+	axp20x->irq = i2c->irq;
+	dev_set_drvdata(axp20x->dev, axp20x);
+
+	ret = axp20x_match_device(axp20x);
+	if (ret)
+		return ret;
+
+	axp20x->regmap = devm_regmap_init_i2c(i2c, axp20x->regmap_cfg);
+	if (IS_ERR(axp20x->regmap)) {
+		ret = PTR_ERR(axp20x->regmap);
+		dev_err(&i2c->dev, "regmap init failed: %d\n", ret);
+		return ret;
+	}
+
+	return axp20x_device_probe(axp20x);
+}
+
+static int axp20x_i2c_remove(struct i2c_client *i2c)
+{
+	struct axp20x_dev *axp20x = i2c_get_clientdata(i2c);
+
+	return axp20x_device_remove(axp20x);
+}
+
+static const struct of_device_id axp20x_i2c_of_match[] = {
+	{ .compatible = "x-powers,axp152", .data = (void *)AXP152_ID },
+	{ .compatible = "x-powers,axp202", .data = (void *)AXP202_ID },
+	{ .compatible = "x-powers,axp209", .data = (void *)AXP209_ID },
+	{ .compatible = "x-powers,axp221", .data = (void *)AXP221_ID },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, axp20x_i2c_of_match);
+
+/*
+ * This is useless for OF-enabled devices, but it is needed by I2C subsystem
+ */
+static const struct i2c_device_id axp20x_i2c_id[] = {
+	{ },
+};
+MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
+
+static const struct acpi_device_id axp20x_i2c_acpi_match[] = {
+	{
+		.id = "INT33F4",
+		.driver_data = AXP288_ID,
+	},
+	{ },
+};
+MODULE_DEVICE_TABLE(acpi, axp20x_i2c_acpi_match);
+
+static struct i2c_driver axp20x_i2c_driver = {
+	.driver = {
+		.name	= "axp20x-i2c",
+		.of_match_table	= of_match_ptr(axp20x_i2c_of_match),
+		.acpi_match_table = ACPI_PTR(axp20x_i2c_acpi_match),
+	},
+	.probe		= axp20x_i2c_probe,
+	.remove		= axp20x_i2c_remove,
+	.id_table	= axp20x_i2c_id,
+};
+
+module_i2c_driver(axp20x_i2c_driver);
+
+MODULE_DESCRIPTION("PMIC MFD I2C driver for AXP20X");
+MODULE_AUTHOR("Carlo Caione <carlo at caione.org>");
+MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index cec51e689d1d..8e569bcfe3bc 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -1,10 +1,12 @@
 /*
- * axp20x.c - MFD core driver for the X-Powers' Power Management ICs
+ * MFD core driver for the X-Powers' Power Management ICs
  *
  * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK DC-DC
  * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
  * as well as configurable GPIOs.
  *
+ * This file contains the interface independent core functions.
+ *
  * Copyright (C) 2014 Carlo Caione
  *
  * Author: Carlo Caione <carlo at caione.org>
@@ -15,18 +17,15 @@
  */
 
 #include <linux/err.h>
-#include <linux/i2c.h>
 #include <linux/interrupt.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/pm_runtime.h>
 #include <linux/regmap.h>
-#include <linux/slab.h>
 #include <linux/regulator/consumer.h>
 #include <linux/mfd/axp20x.h>
 #include <linux/mfd/core.h>
 #include <linux/of_device.h>
-#include <linux/of_irq.h>
 #include <linux/acpi.h>
 
 #define AXP20X_OFF	0x80
@@ -378,32 +377,6 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
 	INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG,            5, 1),
 };
 
-static const struct of_device_id axp20x_of_match[] = {
-	{ .compatible = "x-powers,axp152", .data = (void *) AXP152_ID },
-	{ .compatible = "x-powers,axp202", .data = (void *) AXP202_ID },
-	{ .compatible = "x-powers,axp209", .data = (void *) AXP209_ID },
-	{ .compatible = "x-powers,axp221", .data = (void *) AXP221_ID },
-	{ },
-};
-MODULE_DEVICE_TABLE(of, axp20x_of_match);
-
-/*
- * This is useless for OF-enabled devices, but it is needed by I2C subsystem
- */
-static const struct i2c_device_id axp20x_i2c_id[] = {
-	{ },
-};
-MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
-
-static const struct acpi_device_id axp20x_acpi_match[] = {
-	{
-		.id = "INT33F4",
-		.driver_data = AXP288_ID,
-	},
-	{ },
-};
-MODULE_DEVICE_TABLE(acpi, axp20x_acpi_match);
-
 static const struct regmap_irq_chip axp152_regmap_irq_chip = {
 	.name			= "axp152_irq_chip",
 	.status_base		= AXP152_IRQ1_STATE,
@@ -608,7 +581,7 @@ static void axp20x_power_off(void)
 		     AXP20X_OFF);
 }
 
-static int axp20x_match_device(struct axp20x_dev *axp20x)
+int axp20x_match_device(struct axp20x_dev *axp20x)
 {
 	struct device *dev = axp20x->dev;
 	const struct acpi_device_id *acpi_id;
@@ -665,38 +638,18 @@ static int axp20x_match_device(struct axp20x_dev *axp20x)
 
 	return 0;
 }
+EXPORT_SYMBOL(axp20x_match_device);
 
-static int axp20x_i2c_probe(struct i2c_client *i2c,
-			 const struct i2c_device_id *id)
+int axp20x_device_probe(struct axp20x_dev *axp20x)
 {
-	struct axp20x_dev *axp20x;
 	int ret;
 
-	axp20x = devm_kzalloc(&i2c->dev, sizeof(*axp20x), GFP_KERNEL);
-	if (!axp20x)
-		return -ENOMEM;
-
-	axp20x->i2c_client = i2c;
-	axp20x->dev = &i2c->dev;
-	dev_set_drvdata(axp20x->dev, axp20x);
-
-	ret = axp20x_match_device(axp20x);
-	if (ret)
-		return ret;
-
-	axp20x->regmap = devm_regmap_init_i2c(i2c, axp20x->regmap_cfg);
-	if (IS_ERR(axp20x->regmap)) {
-		ret = PTR_ERR(axp20x->regmap);
-		dev_err(&i2c->dev, "regmap init failed: %d\n", ret);
-		return ret;
-	}
-
-	ret = regmap_add_irq_chip(axp20x->regmap, i2c->irq,
+	ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
 				  IRQF_ONESHOT | IRQF_SHARED, -1,
 				  axp20x->regmap_irq_chip,
 				  &axp20x->regmap_irqc);
 	if (ret) {
-		dev_err(&i2c->dev, "failed to add irq chip: %d\n", ret);
+		dev_err(axp20x->dev, "failed to add irq chip: %d\n", ret);
 		return ret;
 	}
 
@@ -704,8 +657,8 @@ static int axp20x_i2c_probe(struct i2c_client *i2c,
 			axp20x->nr_cells, NULL, 0, NULL);
 
 	if (ret) {
-		dev_err(&i2c->dev, "failed to add MFD devices: %d\n", ret);
-		regmap_del_irq_chip(i2c->irq, axp20x->regmap_irqc);
+		dev_err(axp20x->dev, "failed to add MFD devices: %d\n", ret);
+		regmap_del_irq_chip(axp20x->irq, axp20x->regmap_irqc);
 		return ret;
 	}
 
@@ -714,38 +667,25 @@ static int axp20x_i2c_probe(struct i2c_client *i2c,
 		pm_power_off = axp20x_power_off;
 	}
 
-	dev_info(&i2c->dev, "AXP20X driver loaded\n");
+	dev_info(axp20x->dev, "AXP20X driver loaded\n");
 
 	return 0;
 }
+EXPORT_SYMBOL(axp20x_device_probe);
 
-static int axp20x_i2c_remove(struct i2c_client *i2c)
+int axp20x_device_remove(struct axp20x_dev *axp20x)
 {
-	struct axp20x_dev *axp20x = i2c_get_clientdata(i2c);
-
 	if (axp20x == axp20x_pm_power_off) {
 		axp20x_pm_power_off = NULL;
 		pm_power_off = NULL;
 	}
 
 	mfd_remove_devices(axp20x->dev);
-	regmap_del_irq_chip(axp20x->i2c_client->irq, axp20x->regmap_irqc);
+	regmap_del_irq_chip(axp20x->irq, axp20x->regmap_irqc);
 
 	return 0;
 }
-
-static struct i2c_driver axp20x_i2c_driver = {
-	.driver = {
-		.name	= "axp20x",
-		.of_match_table	= of_match_ptr(axp20x_of_match),
-		.acpi_match_table = ACPI_PTR(axp20x_acpi_match),
-	},
-	.probe		= axp20x_i2c_probe,
-	.remove		= axp20x_i2c_remove,
-	.id_table	= axp20x_i2c_id,
-};
-
-module_i2c_driver(axp20x_i2c_driver);
+EXPORT_SYMBOL(axp20x_device_remove);
 
 MODULE_DESCRIPTION("PMIC MFD core driver for AXP20X");
 MODULE_AUTHOR("Carlo Caione <carlo at caione.org>");
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index b24c771cebd5..00697c6ad8b0 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -396,7 +396,7 @@ enum axp288_irqs {
 
 struct axp20x_dev {
 	struct device			*dev;
-	struct i2c_client		*i2c_client;
+	int				irq;
 	struct regmap			*regmap;
 	struct regmap_irq_chip_data	*regmap_irqc;
 	long				variant;
@@ -462,4 +462,35 @@ static inline int axp20x_read_variable_width(struct regmap *regmap,
 	return result;
 }
 
+/**
+ * axp20x_match_device(): Setup axp20x variant related fields
+ *
+ * @axp20x: axp20x device to setup (.dev field must be set)
+ * @dev: device associated with this axp20x device
+ *
+ * This lets the axp20x core configure the mfd cells and register maps
+ * for later use.
+ */
+int axp20x_match_device(struct axp20x_dev *axp20x);
+
+/**
+ * axp20x_device_probe(): Probe a configured axp20x device
+ *
+ * @axp20x: axp20x device to probe (must be configured)
+ *
+ * This function lets the axp20x core register the axp20x mfd devices
+ * and irqchip. The axp20x device passed in must be fully configured
+ * with axp20x_match_device, its irq set, and regmap created.
+ */
+int axp20x_device_probe(struct axp20x_dev *axp20x);
+
+/**
+ * axp20x_device_probe(): Remove a axp20x device
+ *
+ * @axp20x: axp20x device to remove
+ *
+ * This tells the axp20x core to remove the associated mfd devices
+ */
+int axp20x_device_remove(struct axp20x_dev *axp20x);
+
 #endif /* __LINUX_MFD_AXP20X_H */
-- 
2.7.0



From wens at csie.org  Thu Feb 11 18:04:08 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 12 Feb 2016 10:04:08 +0800
Subject: [linux-sunxi] Re: [PATCH v7 04/10] mfd: axp20x: Add missing
 copyright notice
In-Reply-To: <20160211152418.GA20693@x1>
References: <1452655854-1528-1-git-send-email-wens@csie.org>
 <1452655854-1528-5-git-send-email-wens@csie.org> <20160125143957.GS3368@x1>
 <20160211152418.GA20693@x1>
Message-ID: <CAGb2v65pF8+XA_zS1ajBo8c__rGr207X4aZ426f920N-X9M_Cg@mail.gmail.com>

On Thu, Feb 11, 2016 at 11:24 PM, Lee Jones <lee.jones at linaro.org> wrote:
> On Mon, 25 Jan 2016, Lee Jones wrote:
>
>> On Wed, 13 Jan 2016, Chen-Yu Tsai wrote:
>>
>> > When the driver was merged, the original author did not include a proper
>> > copyright notice. This patch adds the notice, backdated to when the
>> > driver was merged.
>>
>> This is very wordy.
>>
>> "Supply a backdated copyright notice."
>
> Can you re-submit this set with this fixed and the Acks you collected?

Just did. Hopefully you'll see it in your inbox, and not your spam folder.

Thanks
ChenYu


From hongzhou.yang at mediatek.com  Thu Feb 11 18:07:11 2016
From: hongzhou.yang at mediatek.com (Hongzhou Yang)
Date: Thu, 11 Feb 2016 18:07:11 -0800
Subject: [PATCH 1/2] pinctrl: mediatek: fix direction control issue
In-Reply-To: <CACRpkdZb2-TX1eY7eyK5qCqOg66MP1e4+OO287roJdP=RB6-Fg@mail.gmail.com>
References: <1454462686-770-1-git-send-email-biao.huang@mediatek.com>
 <1454462686-770-2-git-send-email-biao.huang@mediatek.com>
 <1454555015.4618.10.camel@mussux00>
 <CACRpkdZb2-TX1eY7eyK5qCqOg66MP1e4+OO287roJdP=RB6-Fg@mail.gmail.com>
Message-ID: <1455242831.35628.15.camel@mussux00>

On Fri, 2016-02-05 at 14:52 +0100, Linus Walleij wrote:
> On Thu, Feb 4, 2016 at 4:03 AM, Hongzhou Yang
> <hongzhou.yang at mediatek.com> wrote:
> > On Wed, 2016-02-03 at 09:24 +0800, Biao Huang wrote:
> >> Since input-enable/disable and input-schmitt-enable/disable are
> >> workable when gpio direction is input, so add direction setting
> >> when do input-enable/disable and input-schmitt-enable/disable
> >> properties.
> >>
> >> Signed-off-by: Biao Huang <biao.huang at mediatek.com>
> >> ---
> >>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c |    2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> >> index 8cac73d..6eb01c9 100644
> >> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> >> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> >> @@ -352,6 +352,7 @@ static int mtk_pconf_parse_conf(struct pinctrl_dev *pctldev,
> >>               ret = mtk_pconf_set_pull_select(pctl, pin, true, false, arg);
> >>               break;
> >>       case PIN_CONFIG_INPUT_ENABLE:
> >> +             mtk_pmx_gpio_set_direction(pctldev, NULL, pin, true);
> >>               ret = mtk_pconf_set_ies_smt(pctl, pin, arg, param);
> >
> > Hi Linus,
> >
> > From pinctrl-bindings.txt, 'input-enable' property defined as following:
> > input-enable        - enable input on pin (no effect on output)
> >
> > Since input enable and input direction are two different settings on our
> > SOC,
> 
> What does this mean? How can input have a "direction"?
> 
> Isn't the direction of an input always inbound, into the SoC?
> 
> Please elaborate.

Sorry for the late reply.
There are two conditions if external device input data into SOC.
1. Change GPIO direction to input.
2. Switch on input.


> > could you tell me the exact meaning of this property? Input enable
> > only? Or set input direction at the same time?
> 
> This was added in commit 8ba3f4d00078e7a49c60c0bd6298f29402c3a0a0
> "pinctrl: Adds slew-rate, input-enable/disable"
> by Sherman Yin so let's ask him first.

Thanks for this info.
>From Sherman's comment, PIN_CONFIG_INPUT_ENABLE seems only to stand for
the condition 2.

* @PIN_CONFIG_INPUT_ENABLE: enable the pin's input.  Note that this does
not affect the pin's ability to drive output.  1 enables input, 0
disables input.

Then I get confuse if we can change direction under this property.

Thanks.
Hongzhou



From gregkh at linuxfoundation.org  Thu Feb 11 19:15:51 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 11 Feb 2016 19:15:51 -0800
Subject: [PATCH v8 2/4] tee: generic TEE subsystem
In-Reply-To: <1455210877-15748-3-git-send-email-jens.wiklander@linaro.org>
References: <1455210877-15748-1-git-send-email-jens.wiklander@linaro.org>
 <1455210877-15748-3-git-send-email-jens.wiklander@linaro.org>
Message-ID: <20160212031551.GA10157@kroah.com>

On Thu, Feb 11, 2016 at 06:14:35PM +0100, Jens Wiklander wrote:
> Initial patch for generic TEE subsystem.
> This subsystem provides:
> * Registration/un-registration of TEE drivers.
> * Shared memory between normal world and secure world.
> * Ioctl interface for interaction with user space.
> * Sysfs implementation_id of TEE driver
> 
> A TEE (Trusted Execution Environment) driver is a driver that interfaces
> with a trusted OS running in some secure environment, for example,
> TrustZone on ARM cpus, or a separate secure co-processor etc.
> 
> The TEE subsystem can serve a TEE driver for a Global Platform compliant
> TEE, but it's not limited to only Global Platform TEEs.
> 
> This patch builds on other similar implementations trying to solve
> the same problem:
> * "optee_linuxdriver" by among others
>   Jean-michel DELORME<jean-michel.delorme at st.com> and
>   Emmanuel MICHEL <emmanuel.michel at st.com>
> * "Generic TrustZone Driver" by Javier Gonz?lez <javier at javigon.com>
> 
> Signed-off-by: Jens Wiklander <jens.wiklander at linaro.org>

I need you to get other people to review this before I can accept this
series.  Please do that, surely someone else cares about this code
becides you?

thanks,

greg k-h


From gregkh at linuxfoundation.org  Thu Feb 11 19:17:13 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 11 Feb 2016 19:17:13 -0800
Subject: [PATCH 4/7] serial: 8250_omap: Fix PM regression with deferred
 probe for pm_runtime_reinit
In-Reply-To: <1455145370-20301-5-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-5-git-send-email-tony@atomide.com>
Message-ID: <20160212031713.GB10157@kroah.com>

On Wed, Feb 10, 2016 at 03:02:47PM -0800, Tony Lindgren wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
> 
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
> 
> omap_device_enable() called from invalid state 1
> 
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
> 
> The solution is to fix the drivers to follow the PM runtime documentation:
> 
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
> 
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
> 
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-serial at vger.kernel.org
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: Kevin Hilman <khilman at baylibre.com>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Peter Hurley <peter at hurleysoftware.com>
> Cc: Rafael J. Wysocki <rafael at kernel.org>
> Cc: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Tero Kristo <t-kristo at ti.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> ---
> 
> Greg & Peter, I'd like to merge this along with other related fixes
> via the ARM SoC tree if no objections, please review and ack if this
> look OK to you.

Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>


From gregkh at linuxfoundation.org  Thu Feb 11 19:19:07 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 11 Feb 2016 19:19:07 -0800
Subject: [PATCH v5 RESEND 3/5] driver core: handle -EPROBE_DEFER from
 bus_type.match()
In-Reply-To: <1455101250-11327-4-git-send-email-m.szyprowski@samsung.com>
References: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
 <1455101250-11327-4-git-send-email-m.szyprowski@samsung.com>
Message-ID: <20160212031907.GD10157@kroah.com>

On Wed, Feb 10, 2016 at 11:47:28AM +0100, Marek Szyprowski wrote:
> From: Tomeu Vizoso <tomeu.vizoso at collabora.com>
> 
> Allow implementations of the match() callback in struct bus_type to
> return errors and if it's -EPROBE_DEFER then queue the device for
> deferred probing.
> 
> This is useful to buses such as AMBA in which devices are registered
> before their matching information can be retrieved from the HW
> (typically because a clock driver hasn't probed yet).
> 
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso at collabora.com>
> [changed if-else code structure, adjusted documentation to match the code,
> extended comments]
> Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
> Reviewed-by: Ulf Hansson <ulf.hansson at linaro.org>
> ---
>  Documentation/driver-model/porting.txt |  6 ++++--
>  drivers/base/dd.c                      | 24 ++++++++++++++++++++++--
>  include/linux/device.h                 |  7 +++++--
>  3 files changed, 31 insertions(+), 6 deletions(-)


Acked-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>



From f.fainelli at gmail.com  Thu Feb 11 19:46:42 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Thu, 11 Feb 2016 19:46:42 -0800
Subject: [GIT PULL] bcm2835 DT changes for 4.6
In-Reply-To: <87d1s42yb8.fsf@eliezer.anholt.net>
References: <1454977978-17491-1-git-send-email-eric@anholt.net>
 <DDFB1D8B-805B-488F-9582-796EBCEF287B@sperl.org>
 <87d1s42yb8.fsf@eliezer.anholt.net>
Message-ID: <56BD55A2.20104@gmail.com>

On 10/02/2016 10:51, Eric Anholt wrote:
> Martin Sperl <martin at sperl.org> writes:
> 
>>> On 09.02.2016, at 01:32, Eric Anholt <eric at anholt.net> wrote:
>>>
>>> Hi Florian.  Here's the first set of patches for bcm2835 for 4.6.
>>> We've got more DT patches that are going to happen for new boards,
>>> too, but they're still getting polished.
>>>
>>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>>
>>>  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>>
>>> are available in the git repository at:
>>>
>>>  git at github.com:anholt/linux.git tags/bcm2835-dt-next-2016-02-04
>>>
>>> for you to fetch changes up to 5ec6f2cd8ec4bcd38ba199ea8711a5ec906d85e7:
>>>
>>>  ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT. (2016-02-02 20:02:45 -0800)
>>>
>>> ----------------------------------------------------------------
>>> This pull request covers mostly DT changes that didn't make it into
>>> 4.5 because required header files went through other trees.
>>>
>>> ----------------------------------------------------------------
>>> Alexander Aring (1):
>>>      ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
>>>
>>> Lubomir Rintel (1):
>>>      ARM: bcm2835: dt: Add Raspberry Pi Model A
>>>
>>> Martin Sperl (2):
>>>      ARM: bcm2835: add the auxiliary spi1 and spi2 to the device tree
>>>      ARM: bcm2835: follow dt uart node-naming convention
>>
>> Do you want me to resend a rebased version of:
>>      ARM: bcm2835: add bcm2835-aux-uart support to default DT
>>
>> The corresponding driver has been added to tty/tty-next.
> 
> It hadn't landed last time I checked.  A rebased version that you've
> tested would be great!

OK, please submit this in the next week or so at most, so we can get
this pull request merged, thanks!

Eric, do you have other changes outside of Device Tree?
--
Florian


From aneesh.kumar at linux.vnet.ibm.com  Thu Feb 11 20:04:33 2016
From: aneesh.kumar at linux.vnet.ibm.com (Aneesh Kumar K.V)
Date: Fri, 12 Feb 2016 09:34:33 +0530
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160211205702.24f0d17a@thinkpad>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
Message-ID: <87a8n6shf2.fsf@linux.vnet.ibm.com>

Gerald Schaefer <gerald.schaefer at de.ibm.com> writes:

> On Thu, 11 Feb 2016 21:09:42 +0200
> "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
>
>> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
>> > Hi,
>> > 
>> > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
>> > he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
>> > review of the THP rework patches, which cannot be bisected, revealed
>> > commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
>> > (and also similar commits for other archs).
>> > 
>> > This commit removes the THP splitting bit and also the architecture
>> > implementation of pmdp_splitting_flush(), which took care of the IPI for
>> > fast_gup serialization. The commit message says
>> > 
>> >     pmdp_splitting_flush() is not needed too: on splitting PMD we will do
>> >     pmdp_clear_flush() + set_pte_at().  pmdp_clear_flush() will do IPI as
>> >     needed for fast_gup
>> > 
>> > The assumption that a TLB flush will also produce an IPI is wrong on s390,
>> > and maybe also on other architectures, and I thought that this was actually
>> > the main reason for having an arch-specific pmdp_splitting_flush().
>> > 
>> > At least PowerPC and ARM also had an individual implementation of
>> > pmdp_splitting_flush() that used kick_all_cpus_sync() instead of a TLB
>> > flush to send the IPI, and those were also removed. Putting the arch
>> > maintainers and mailing lists on cc to verify.
>> > 
>> > On s390 this will break the IPI serialization against fast_gup, which
>> > would certainly explain the random kernel crashes, please revert or fix
>> > the pmdp_splitting_flush() removal.
>> 
>> Sorry for that.
>> 
>> I believe, the problem was already addressed for PowerPC:
>> 
>> http://lkml.kernel.org/g/454980831-16631-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com
>> 
>> I think kick_all_cpus_sync() in arch-specific pmdp_invalidate() would do
>> the trick, right?
>
> Hmm, not sure about that. After pmdp_invalidate(), a pmd_none() check in
> fast_gup will still return false, because the pmd is not empty (at least
> on s390).

Why can't we do this ? I did this for ppc64.

 void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
 		     pmd_t *pmdp)
 {
-	pmd_hugepage_update(vma->vm_mm, address, pmdp, _PAGE_PRESENT, 0);
+	pmd_hugepage_update(vma->vm_mm, address, pmdp, ~0UL, 0);

>So I don't see spontaneously how it will help fast_gup to break
> out to the slow path in case of THP splitting.
>
>> 
>> If yes, I'll prepare patch tomorrow (some sleep required).
>> 
>
> We'll check if adding kick_all_cpus_sync() to pmdp_invalidate() helps.
> It would also be good if Martin has a look at this, he'll return on
> Monday.

-aneesh



From shaun.ren at linux.com  Thu Feb 11 20:07:52 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Thu, 11 Feb 2016 20:07:52 -0800
Subject: [PATCH v4 0/8] Staging: rts5208: Fix coding style
In-Reply-To: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
References: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>

This set of patches fixes the coding style issues in rtsx_transport.c.

Changes since v3
 * Removed the extraneous SCSI comment in the first patch
 * Removed the last patch (Staging: rts5208: Add missing dma_mapping_error)
   as it is already done in change 9a66d05d82db
   (Staging: rts5208: fix check for dma mapping error)

Changes since v2
 * Incorporated Joshua Clayton's suggestions regarding the block comments



Shaun Ren (8):
  Staging: rts5208: rtsx_transport.c: Cleanup comments
  Staging: rts5208: rtsx_transport.c: Align to open parenthesis
  Staging: rts5208: rtsx_transport.c: Remove spaces after casts
  Staging: rts5208: rtsx_transport.c: Add spaces around -
  Staging: rts5208: rtsx_transport.c: Remove extra newlines
  Staging: rts5208: rtsx_transport.c: Fix label naming convention
  Staging: rts5208: rtsx_transport.c: Remove unnecessary parentheses
  Staging: rts5208: rtsx_transport.c: Fix comparisons to NULL

 drivers/staging/rts5208/rtsx_transport.c | 152 ++++++++++++++++---------------
 1 file changed, 81 insertions(+), 71 deletions(-)

-- 
2.7.0



From shaun.ren at linux.com  Thu Feb 11 20:07:53 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Thu, 11 Feb 2016 20:07:53 -0800
Subject: [PATCH v4 1/8] Staging: rts5208: rtsx_transport.c: Cleanup comments
In-Reply-To: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
References: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
 <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455250080-9897-2-git-send-email-shaun.ren@linux.com>

This patch fixes all multiline comments to conform to the coding style,
which states that multiline comments should start with "/*" and end
with "*/" on a separate line.

Also cleans up some comments to make them more clear and/or reflect what
the code is doing.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
Changes since v3
 * Removed the extraneous SCSI comment in the first patch in
   rtsx_stor_access_xfer_buf()

Changes since v2
 * Cleaned up comments as per Joshua Clayton's suggestions

 drivers/staging/rts5208/rtsx_transport.c | 53 ++++++++++++++++----------------
 1 file changed, 27 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index f2eb18e..91fdccf 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -1,4 +1,5 @@
-/* Driver for Realtek PCI-Express card reader
+/*
+ * Driver for Realtek PCI-Express card reader
  *
  * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
@@ -30,13 +31,15 @@
  * Scatter-gather transfer buffer access routines
  ***********************************************************************/
 
-/* Copy a buffer of length buflen to/from the srb's transfer buffer.
+/*
+ * Copy a buffer of length buflen to/from the srb's transfer buffer.
  * (Note: for scatter-gather transfers (srb->use_sg > 0), srb->request_buffer
  * points to a list of s-g entries and we ignore srb->request_bufflen.
  * For non-scatter-gather transfers, srb->request_buffer points to the
  * transfer buffer itself and srb->request_bufflen is the buffer's length.)
  * Update the *index and *offset variables so that the next copy will
- * pick up from where this one left off. */
+ * pick up from where this one left off.
+ */
 
 unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 	unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
@@ -44,8 +47,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 {
 	unsigned int cnt;
 
-	/* If not using scatter-gather, just transfer the data directly.
-	 * Make certain it will fit in the available buffer space. */
+	/* If not using scatter-gather, just transfer the data directly. */
 	if (scsi_sg_count(srb) == 0) {
 		if (*offset >= scsi_bufflen(srb))
 			return 0;
@@ -58,22 +60,22 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 					*offset, cnt);
 		*offset += cnt;
 
-	/* Using scatter-gather.  We have to go through the list one entry
+	/*
+	 * Using scatter-gather.  We have to go through the list one entry
 	 * at a time.  Each s-g entry contains some number of pages, and
-	 * each page has to be kmap()'ed separately.  If the page is already
-	 * in kernel-addressable memory then kmap() will return its address.
-	 * If the page is not directly accessible -- such as a user buffer
-	 * located in high memory -- then kmap() will map it to a temporary
-	 * position in the kernel's virtual address space. */
+	 * each page has to be kmap()'ed separately.
+	 */
 	} else {
 		struct scatterlist *sg =
 				(struct scatterlist *) scsi_sglist(srb)
 				+ *index;
 
-		/* This loop handles a single s-g list entry, which may
+		/*
+		 * This loop handles a single s-g list entry, which may
 		 * include multiple pages.  Find the initial page structure
 		 * and the starting offset within the page, and update
-		 * the *offset and *index values for the next loop. */
+		 * the *offset and *index values for the next loop.
+		 */
 		cnt = 0;
 		while (cnt < buflen && *index < scsi_sg_count(srb)) {
 			struct page *page = sg_page(sg) +
@@ -95,9 +97,6 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 				++sg;
 			}
 
-			/* Transfer the data for all the pages in this
-			 * s-g entry.  For each page: call kmap(), do the
-			 * transfer, and call kunmap() immediately after. */
 			while (sglen > 0) {
 				unsigned int plen = min(sglen, (unsigned int)
 						PAGE_SIZE - poff);
@@ -122,8 +121,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 	return cnt;
 }
 
-/* Store the contents of buffer into srb's transfer buffer and set the
-* SCSI residue. */
+/*
+ * Store the contents of buffer into srb's transfer buffer and set the
+ * SCSI residue.
+ */
 void rtsx_stor_set_xfer_buf(unsigned char *buffer,
 	unsigned int buflen, struct scsi_cmnd *srb)
 {
@@ -151,7 +152,8 @@ void rtsx_stor_get_xfer_buf(unsigned char *buffer,
  * Transport routines
  ***********************************************************************/
 
-/* Invoke the transport and basic error-handling/recovery methods
+/*
+ * Invoke the transport and basic error-handling/recovery methods
  *
  * This is used to send the message to the device and receive the response.
  */
@@ -161,8 +163,9 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 
 	result = rtsx_scsi_handler(srb, chip);
 
-	/* if the command gets aborted by the higher layers, we need to
-	 * short-circuit all other processing
+	/*
+	 * if the command gets aborted by the higher layers, we need to
+	 * short-circuit all other processing.
 	 */
 	if (rtsx_chk_stat(chip, RTSX_STAT_ABORT)) {
 		dev_dbg(rtsx_dev(chip), "-- command was aborted\n");
@@ -194,9 +197,6 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 
 	return;
 
-	/* Error and abort processing: try to resynchronize with the device
-	 * by issuing a port reset.  If that fails, try a class-specific
-	 * device reset. */
 Handle_Errors:
 	return;
 }
@@ -368,10 +368,11 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
 	resid = size;
 	sg_ptr = sg;
 	chip->sgi = 0;
-	/* Usually the next entry will be @sg@ + 1, but if this sg element
+	/*
+	 * Usually the next entry will be @sg@ + 1, but if this sg element
 	 * is part of a chained scatterlist, it could jump to the start of
 	 * a new scatterlist array. So here we use sg_next to move to
-	 * the proper sg
+	 * the proper sg.
 	 */
 	for (i = 0; i < *index; i++)
 		sg_ptr = sg_next(sg_ptr);
-- 
2.7.0



From shaun.ren at linux.com  Thu Feb 11 20:07:54 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Thu, 11 Feb 2016 20:07:54 -0800
Subject: [PATCH v4 2/8] Staging: rts5208: rtsx_transport.c: Align to open
 parenthesis
In-Reply-To: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
References: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
 <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455250080-9897-3-git-send-email-shaun.ren@linux.com>

This patch fixes the alignment issue reported by checkpatch.pl:

CHECK: Alignment should match open parenthesis

Add a unsigned char *sgbuffer in rtsx_stor_access_xfer_buffer to make the
following memcpy logic easier to read.

Add a struct scatterlist *sg in the use_sg branch of
rtsx_transfer_data_partial to make the parameters of the
rtsx_transfer_sglist_adma_partial call fit in 80 character lines after
aligning them to the open parenthesis.

Refactor memcpy logic in rtsx_stor_access_xfer_buf to make it more legible.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
Changes since v3
  * Fixed misalignment of the last parameter of rtsx_stor_access_xfer_buf()
  * Refactored memcpy in rtsx_stor_access_xfer_buf() for legibility

 drivers/staging/rts5208/rtsx_transport.c | 68 +++++++++++++++++++-------------
 1 file changed, 40 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 91fdccf..1a4da89 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -42,8 +42,11 @@
  */
 
 unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
-	unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
-	unsigned int *offset, enum xfer_buf_dir dir)
+				       unsigned int buflen,
+				       struct scsi_cmnd *srb,
+				       unsigned int *index,
+				       unsigned int *offset,
+				       enum xfer_buf_dir dir)
 {
 	unsigned int cnt;
 
@@ -52,12 +55,14 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 		if (*offset >= scsi_bufflen(srb))
 			return 0;
 		cnt = min(buflen, scsi_bufflen(srb) - *offset);
+
+		unsigned char *sgbuffer = (unsigned char *)scsi_sglist(srb) +
+			*offset;
+
 		if (dir == TO_XFER_BUF)
-			memcpy((unsigned char *) scsi_sglist(srb) + *offset,
-					buffer, cnt);
+			memcpy(sgbuffer, buffer, cnt);
 		else
-			memcpy(buffer, (unsigned char *) scsi_sglist(srb) +
-					*offset, cnt);
+			memcpy(buffer, sgbuffer, cnt);
 		*offset += cnt;
 
 	/*
@@ -126,7 +131,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
  * SCSI residue.
  */
 void rtsx_stor_set_xfer_buf(unsigned char *buffer,
-	unsigned int buflen, struct scsi_cmnd *srb)
+			    unsigned int buflen, struct scsi_cmnd *srb)
 {
 	unsigned int index = 0, offset = 0;
 
@@ -137,7 +142,7 @@ void rtsx_stor_set_xfer_buf(unsigned char *buffer,
 }
 
 void rtsx_stor_get_xfer_buf(unsigned char *buffer,
-	unsigned int buflen, struct scsi_cmnd *srb)
+			    unsigned int buflen, struct scsi_cmnd *srb)
 {
 	unsigned int index = 0, offset = 0;
 
@@ -191,8 +196,8 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 		/* set the result so the higher layers expect this data */
 		srb->result = SAM_STAT_CHECK_CONDITION;
 		memcpy(srb->sense_buffer,
-			(unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
-			sizeof(struct sense_data_t));
+		       (unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
+		       sizeof(struct sense_data_t));
 	}
 
 	return;
@@ -202,7 +207,7 @@ Handle_Errors:
 }
 
 void rtsx_add_cmd(struct rtsx_chip *chip,
-		u8 cmd_type, u16 reg_addr, u8 mask, u8 data)
+		  u8 cmd_type, u16 reg_addr, u8 mask, u8 data)
 {
 	u32 *cb = (u32 *)(chip->host_cmds_ptr);
 	u32 val = 0;
@@ -321,9 +326,11 @@ static inline void rtsx_add_sg_tbl(
 }
 
 static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
-		struct scatterlist *sg, int num_sg, unsigned int *index,
-		unsigned int *offset, int size,
-		enum dma_data_direction dma_dir, int timeout)
+					     struct scatterlist *sg, int num_sg,
+					     unsigned int *index,
+					     unsigned int *offset, int size,
+					     enum dma_data_direction dma_dir,
+					     int timeout)
 {
 	struct rtsx_dev *rtsx = chip->rtsx;
 	struct completion trans_done;
@@ -486,8 +493,9 @@ out:
 }
 
 static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
-		struct scatterlist *sg, int num_sg,
-		enum dma_data_direction dma_dir, int timeout)
+				     struct scatterlist *sg, int num_sg,
+				     enum dma_data_direction dma_dir,
+				     int timeout)
 {
 	struct rtsx_dev *rtsx = chip->rtsx;
 	struct completion trans_done;
@@ -633,7 +641,8 @@ out:
 }
 
 static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
-		size_t len, enum dma_data_direction dma_dir, int timeout)
+			     size_t len, enum dma_data_direction dma_dir,
+			     int timeout)
 {
 	struct rtsx_dev *rtsx = chip->rtsx;
 	struct completion trans_done;
@@ -716,9 +725,9 @@ out:
 }
 
 int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
-		void *buf, size_t len, int use_sg, unsigned int *index,
-		unsigned int *offset, enum dma_data_direction dma_dir,
-		int timeout)
+			       void *buf, size_t len, int use_sg,
+			       unsigned int *index, unsigned int *offset,
+			       enum dma_data_direction dma_dir, int timeout)
 {
 	int err = 0;
 
@@ -726,13 +735,16 @@ int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
 	if (rtsx_chk_stat(chip, RTSX_STAT_ABORT))
 		return -EIO;
 
-	if (use_sg)
-		err = rtsx_transfer_sglist_adma_partial(chip, card,
-				(struct scatterlist *)buf, use_sg,
-				index, offset, (int)len, dma_dir, timeout);
-	else
+	if (use_sg) {
+		struct scatterlist *sg = (struct scatterlist *)buf;
+
+		err = rtsx_transfer_sglist_adma_partial(chip, card, sg, use_sg,
+							index, offset, (int)len,
+							dma_dir, timeout);
+	} else {
 		err = rtsx_transfer_buf(chip, card,
 					buf, len, dma_dir, timeout);
+	}
 	if (err < 0) {
 		if (RTSX_TST_DELINK(chip)) {
 			RTSX_CLR_DELINK(chip);
@@ -745,7 +757,7 @@ int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
 }
 
 int rtsx_transfer_data(struct rtsx_chip *chip, u8 card, void *buf, size_t len,
-		int use_sg, enum dma_data_direction dma_dir, int timeout)
+		       int use_sg, enum dma_data_direction dma_dir, int timeout)
 {
 	int err = 0;
 
@@ -757,8 +769,8 @@ int rtsx_transfer_data(struct rtsx_chip *chip, u8 card, void *buf, size_t len,
 
 	if (use_sg) {
 		err = rtsx_transfer_sglist_adma(chip, card,
-				(struct scatterlist *)buf,
-				use_sg, dma_dir, timeout);
+						(struct scatterlist *)buf,
+						use_sg, dma_dir, timeout);
 	} else {
 		err = rtsx_transfer_buf(chip, card, buf, len, dma_dir, timeout);
 	}
-- 
2.7.0



From shaun.ren at linux.com  Thu Feb 11 20:07:55 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Thu, 11 Feb 2016 20:07:55 -0800
Subject: [PATCH v4 3/8] Staging: rts5208: rtsx_transport.c: Remove spaces
 after casts
In-Reply-To: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
References: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
 <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455250080-9897-4-git-send-email-shaun.ren@linux.com>

This patch removes all spaces after casts in rtsx_transport.c, as reported
by checkpatch.pl:

CHECK: No space is necessary after a cast

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 1a4da89..1a6018a 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -72,7 +72,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 	 */
 	} else {
 		struct scatterlist *sg =
-				(struct scatterlist *) scsi_sglist(srb)
+				(struct scatterlist *)scsi_sglist(srb)
 				+ *index;
 
 		/*
-- 
2.7.0



From shaun.ren at linux.com  Thu Feb 11 20:07:56 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Thu, 11 Feb 2016 20:07:56 -0800
Subject: [PATCH v4 4/8] Staging: rts5208: rtsx_transport.c: Add spaces around -
In-Reply-To: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
References: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
 <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455250080-9897-5-git-send-email-shaun.ren@linux.com>

This patch fixes the following styling issue in rtsx_transport.c
as reported by checkpatch.pl:

CHECK: spaces preferred around that '-' (ctx:VxV)

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 1a6018a..d8c8436 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -85,8 +85,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 		while (cnt < buflen && *index < scsi_sg_count(srb)) {
 			struct page *page = sg_page(sg) +
 					((sg->offset + *offset) >> PAGE_SHIFT);
-			unsigned int poff =
-					(sg->offset + *offset) & (PAGE_SIZE-1);
+			unsigned int poff = (sg->offset + *offset) &
+					    (PAGE_SIZE - 1);
 			unsigned int sglen = sg->length - *offset;
 
 			if (sglen > buflen - cnt) {
-- 
2.7.0



From shaun.ren at linux.com  Thu Feb 11 20:07:57 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Thu, 11 Feb 2016 20:07:57 -0800
Subject: [PATCH v4 5/8] Staging: rts5208: rtsx_transport.c: Remove extra
 newlines
In-Reply-To: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
References: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
 <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455250080-9897-6-git-send-email-shaun.ren@linux.com>

This patch fixes the following issues in rtsx_transport.c as reported by
checkpatch.pl:

CHECK: Blank lines aren't necessary after an open brace '{'
CHECK: Please don't use multiple blank lines

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index d8c8436..1ce9b9d 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -90,12 +90,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 			unsigned int sglen = sg->length - *offset;
 
 			if (sglen > buflen - cnt) {
-
 				/* Transfer ends within this s-g entry */
 				sglen = buflen - cnt;
 				*offset += sglen;
 			} else {
-
 				/* Transfer continues to next s-g entry */
 				*offset = 0;
 				++*index;
@@ -152,7 +150,6 @@ void rtsx_stor_get_xfer_buf(unsigned char *buffer,
 		scsi_set_resid(srb, scsi_bufflen(srb) - buflen);
 }
 
-
 /***********************************************************************
  * Transport routines
  ***********************************************************************/
-- 
2.7.0



From shaun.ren at linux.com  Thu Feb 11 20:07:58 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Thu, 11 Feb 2016 20:07:58 -0800
Subject: [PATCH v4 6/8] Staging: rts5208: rtsx_transport.c: Fix label naming
 convention
In-Reply-To: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
References: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
 <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455250080-9897-7-git-send-email-shaun.ren@linux.com>

This patch fixes the following naming convention issue in rtsx_transport.c,
as reported by checkpatch.pl:

CHECK: Avoid CamelCase: <Handle_Errors>

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 1ce9b9d..0d332f5 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -172,14 +172,14 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 	if (rtsx_chk_stat(chip, RTSX_STAT_ABORT)) {
 		dev_dbg(rtsx_dev(chip), "-- command was aborted\n");
 		srb->result = DID_ABORT << 16;
-		goto Handle_Errors;
+		goto handle_errors;
 	}
 
 	/* if there is a transport error, reset and don't auto-sense */
 	if (result == TRANSPORT_ERROR) {
 		dev_dbg(rtsx_dev(chip), "-- transport indicates error, resetting\n");
 		srb->result = DID_ERROR << 16;
-		goto Handle_Errors;
+		goto handle_errors;
 	}
 
 	srb->result = SAM_STAT_GOOD;
@@ -199,7 +199,7 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 
 	return;
 
-Handle_Errors:
+handle_errors:
 	return;
 }
 
-- 
2.7.0



From shaun.ren at linux.com  Thu Feb 11 20:07:59 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Thu, 11 Feb 2016 20:07:59 -0800
Subject: [PATCH v4 7/8] Staging: rts5208: rtsx_transport.c: Remove unnecessary
 parentheses
In-Reply-To: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
References: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
 <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455250080-9897-8-git-send-email-shaun.ren@linux.com>

This patch removes all unnecessary parentheses found by checkpatch.pl.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
Changes since v3
  * Fixed patch conflicts due to commit 9a66d05d82db
    ("Staging: rts5208: fix check for dma mapping error"), and
    commit b3232842dbef ("Staging: rts5208: remove unnecessary parantheses")

 drivers/staging/rts5208/rtsx_transport.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 0d332f5..be3423a 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -193,7 +193,7 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 		/* set the result so the higher layers expect this data */
 		srb->result = SAM_STAT_CHECK_CONDITION;
 		memcpy(srb->sense_buffer,
-		       (unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
+		       (unsigned char *)&chip->sense_buffer[SCSI_LUN(srb)],
 		       sizeof(struct sense_data_t));
 	}
 
@@ -367,7 +367,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
 
 	spin_unlock_irq(&rtsx->reg_lock);
 
-	sg_cnt = dma_map_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	sg_cnt = dma_map_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	resid = size;
 	sg_ptr = sg;
@@ -481,7 +481,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
 out:
 	rtsx->done = NULL;
 	rtsx->trans_state = STATE_TRANS_NONE;
-	dma_unmap_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	dma_unmap_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	if (err < 0)
 		rtsx_stop_cmd(chip, card);
@@ -531,7 +531,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
 
 	spin_unlock_irq(&rtsx->reg_lock);
 
-	buf_cnt = dma_map_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	buf_cnt = dma_map_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	sg_ptr = sg;
 
@@ -629,7 +629,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
 out:
 	rtsx->done = NULL;
 	rtsx->trans_state = STATE_TRANS_NONE;
-	dma_unmap_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	dma_unmap_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	if (err < 0)
 		rtsx_stop_cmd(chip, card);
@@ -713,7 +713,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
 out:
 	rtsx->done = NULL;
 	rtsx->trans_state = STATE_TRANS_NONE;
-	dma_unmap_single(&(rtsx->pci->dev), addr, len, dma_dir);
+	dma_unmap_single(&rtsx->pci->dev, addr, len, dma_dir);
 
 	if (err < 0)
 		rtsx_stop_cmd(chip, card);
-- 
2.7.0



From shaun.ren at linux.com  Thu Feb 11 20:08:00 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Thu, 11 Feb 2016 20:08:00 -0800
Subject: [PATCH v4 8/8] Staging: rts5208: rtsx_transport.c: Fix comparisons to
 NULL
In-Reply-To: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
References: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
 <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455250080-9897-9-git-send-email-shaun.ren@linux.com>

This patch changes all comparsions to NULL with !..., as reported by
checkpatch.pl.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index be3423a..73e50ec 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -338,7 +338,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
 	struct scatterlist *sg_ptr;
 	u32 val = TRIG_DMA;
 
-	if ((sg == NULL) || (num_sg <= 0) || !offset || !index)
+	if (!sg || (num_sg <= 0) || !offset || !index)
 		return -EIO;
 
 	if (dma_dir == DMA_TO_DEVICE)
@@ -502,7 +502,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
 	long timeleft;
 	struct scatterlist *sg_ptr;
 
-	if ((sg == NULL) || (num_sg <= 0))
+	if (!sg || (num_sg <= 0))
 		return -EIO;
 
 	if (dma_dir == DMA_TO_DEVICE)
@@ -649,7 +649,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
 	u32 val = 1 << 31;
 	long timeleft;
 
-	if ((buf == NULL) || (len <= 0))
+	if (!buf || (len <= 0))
 		return -EIO;
 
 	if (dma_dir == DMA_TO_DEVICE)
-- 
2.7.0



From joe at perches.com  Thu Feb 11 20:32:15 2016
From: joe at perches.com (Joe Perches)
Date: Thu, 11 Feb 2016 20:32:15 -0800
Subject: [PATCH v4 2/8] Staging: rts5208: rtsx_transport.c: Align to
 open parenthesis
In-Reply-To: <1455250080-9897-3-git-send-email-shaun.ren@linux.com>
References: <1455072328-7033-1-git-send-email-shaun.ren@linux.com>
 <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
 <1455250080-9897-3-git-send-email-shaun.ren@linux.com>
Message-ID: <1455251535.13149.7.camel@perches.com>

On Thu, 2016-02-11 at 20:07 -0800, Shaun Ren wrote:
> This patch fixes the alignment issue reported by checkpatch.pl:
> 
> CHECK: Alignment should match open parenthesis
[]
> diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
[]
> @@ -52,12 +55,14 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
> ?		if (*offset >= scsi_bufflen(srb))
> ?			return 0;
> ?		cnt = min(buflen, scsi_bufflen(srb) - *offset);
> +
> +		unsigned char *sgbuffer = (unsigned char *)scsi_sglist(srb) +
> +			*offset;

Please don't declare variables in the middle of functions.
Variable declarations are only done at the beginning of functions.

> +
> ?		if (dir == TO_XFER_BUF)
> -			memcpy((unsigned char *) scsi_sglist(srb) + *offset,
> -					buffer, cnt);
> +			memcpy(sgbuffer, buffer, cnt);
> ?		else
> -			memcpy(buffer, (unsigned char *) scsi_sglist(srb) +
> -					*offset, cnt);
> +			memcpy(buffer, sgbuffer, cnt);
> ?		*offset += cnt;



From lkp at intel.com  Thu Feb 11 20:38:18 2016
From: lkp at intel.com (kbuild test robot)
Date: Fri, 12 Feb 2016 12:38:18 +0800
Subject: [PATCH v4 2/8] Staging: rts5208: rtsx_transport.c: Align to open
 parenthesis
In-Reply-To: <1455250080-9897-3-git-send-email-shaun.ren@linux.com>
Message-ID: <201602121205.F88kAao7%fengguang.wu@intel.com>

Hi Shaun,

[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v4.5-rc3 next-20160211]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Shaun-Ren/Staging-rts5208-Fix-coding-style/20160212-122003
config: xtensa-allyesconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

   drivers/staging/rts5208/rtsx_transport.c: In function 'rtsx_stor_access_xfer_buf':
>> drivers/staging/rts5208/rtsx_transport.c:59:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
      unsigned char *sgbuffer = (unsigned char *)scsi_sglist(srb) +
      ^

vim +59 drivers/staging/rts5208/rtsx_transport.c

    43	
    44	unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
    45					       unsigned int buflen,
    46					       struct scsi_cmnd *srb,
    47					       unsigned int *index,
    48					       unsigned int *offset,
    49					       enum xfer_buf_dir dir)
    50	{
    51		unsigned int cnt;
    52	
    53		/* If not using scatter-gather, just transfer the data directly. */
    54		if (scsi_sg_count(srb) == 0) {
    55			if (*offset >= scsi_bufflen(srb))
    56				return 0;
    57			cnt = min(buflen, scsi_bufflen(srb) - *offset);
    58	
  > 59			unsigned char *sgbuffer = (unsigned char *)scsi_sglist(srb) +
    60				*offset;
    61	
    62			if (dir == TO_XFER_BUF)
    63				memcpy(sgbuffer, buffer, cnt);
    64			else
    65				memcpy(buffer, sgbuffer, cnt);
    66			*offset += cnt;
    67	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 44081 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/e0fa3a29/attachment-0001.obj>

From viro at ZenIV.linux.org.uk  Thu Feb 11 20:51:59 2016
From: viro at ZenIV.linux.org.uk (Al Viro)
Date: Fri, 12 Feb 2016 04:51:59 +0000
Subject: [PATCH v8 2/4] tee: generic TEE subsystem
In-Reply-To: <1455210877-15748-3-git-send-email-jens.wiklander@linaro.org>
References: <1455210877-15748-1-git-send-email-jens.wiklander@linaro.org>
 <1455210877-15748-3-git-send-email-jens.wiklander@linaro.org>
Message-ID: <20160212045159.GQ17997@ZenIV.linux.org.uk>

On Thu, Feb 11, 2016 at 06:14:35PM +0100, Jens Wiklander wrote:

> +static int tee_ioctl_shm_alloc(struct tee_context *ctx,
> +		struct tee_ioctl_shm_alloc_data __user *udata)
> +{
> +	long ret;
> +	struct tee_ioctl_shm_alloc_data data;
> +	struct tee_shm *shm;
> +
> +	if (copy_from_user(&data, udata, sizeof(data)))
> +		return -EFAULT;
> +
> +	/* Currently no input flags are supported */
> +	if (data.flags)
> +		return -EINVAL;
> +
> +	data.fd = -1;
> +
> +	shm = tee_shm_alloc(ctx->teedev, data.size,
> +			    TEE_SHM_MAPPED | TEE_SHM_DMA_BUF);
> +	if (IS_ERR(shm))
> +		return PTR_ERR(shm);
> +
> +	data.flags = shm->flags;
> +	data.size = shm->size;
> +	data.fd = tee_shm_get_fd(shm);
> +	if (data.fd < 0) {
> +		ret = data.fd;
> +		goto err;
> +	}
> +
> +	if (copy_to_user(udata, &data, sizeof(data))) {
> +		ret = -EFAULT;
> +		goto err;
> +	}
> +	/*
> +	 * When user space closes the file descriptor the shared memory
> +	 * should be freed
> +	 */
> +	tee_shm_put(shm);
> +	return 0;
> +err:
> +	if (data.fd >= 0)
> +		tee_shm_put_fd(data.fd);

This is completely broken.  Don't ever use that pattern.  Once something
is in descriptor table, that's _it_.  You are already past the point of
no return and there is no way to clean up.

In ABIs like that (and struct containing descriptor *is* a bad ABI design)
solution is
	* allocate a descriptor
	* do everything that might fail, including copy_to_user()/put_user(),
etc.
	* if failed, release unused descriptor and do fput(), if you already
have a struct file reference that needs to be released.
	* FINALLY, when nothing no failures are possible, fd_install() the
sucker in place.

And yes, dma_buf_fd() encourages that kind of braindamage.  It's tolerable
only in one case - when we are about to return descriptor number directly
as return value of syscall and really can't fail anymore.  Not the case
here.


From han.xu at nxp.com  Thu Feb 11 21:13:25 2016
From: han.xu at nxp.com (Han Xu)
Date: Fri, 12 Feb 2016 05:13:25 +0000
Subject: [PATCH] MAINTAINERS: update Han's email
Message-ID: <1455254005-746-1-git-send-email-han.xu@nxp.com>

Update my email address from freescale to nxp.

Signed-off-by: Han Xu <han.xu at nxp.com>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7bd927e..b00cce8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4559,7 +4559,7 @@ F:	include/linux/platform_data/video-imxfb.h
 F:	drivers/video/fbdev/imxfb.c
 
 FREESCALE QUAD SPI DRIVER
-M:	Han Xu <han.xu at freescale.com>
+M:	Han Xu <han.xu at nxp.com>
 L:	linux-mtd at lists.infradead.org
 S:	Maintained
 F:	drivers/mtd/spi-nor/fsl-quadspi.c
-- 
2.7.1



From vishnupatekar0510 at gmail.com  Thu Feb 11 21:24:39 2016
From: vishnupatekar0510 at gmail.com (Vishnu Patekar)
Date: Fri, 12 Feb 2016 13:24:39 +0800
Subject: [PATCH 04/14] clk: sunxi: add ahb1 clock for A83T
In-Reply-To: <20160204080109.GA4270@lukather>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-5-git-send-email-vishnupatekar0510@gmail.com>
 <20160202131725.GQ4652@lukather>
 <CAEzqOZuBz2jexvZvvtkvjbE8UtzUMKL9nT5JJ9JcvMPmzEKTcQ@mail.gmail.com>
 <20160204080109.GA4270@lukather>
Message-ID: <CAEzqOZsCkGDxma77H0Te+9PLau6Ybu19cdG_yNTiEhEbwQQrhw@mail.gmail.com>

Hello Maxime,

On Thu, Feb 4, 2016 at 4:01 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> On Thu, Feb 04, 2016 at 02:06:45PM +0800, Vishnu Patekar wrote:
>> Hello Maxime,
>>
>>
>> On Tue, Feb 2, 2016 at 9:17 PM, Maxime Ripard
>> <maxime.ripard at free-electrons.com> wrote:
>> > Hi,
>> >
>> > On Sun, Jan 31, 2016 at 09:20:56AM +0800, Vishnu Patekar wrote:
>> >> AHB1 on A83T is similar to ahb1 on A31, except parents are different.
>> >> clock index 0b1x is PLL6.
>> >>
>> >> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
>> >
>> > If the clock is the same but the parents are different, then we don't
>> > need to duplicate all the logic. Simply add the number of parents to
>> > mux_data, and you're all set.
>>
>> Problem here is: parent 0b10 for A31 ahb1 is AXI, 0b11 is pll6/pre_div.
>> 0b10 and 0b11 is pll6/pre_div.
>> So, just adding number of parents to mux_data will not solve problem.
>
> Is anyone using 0b11 ? Can't we just ignore it?
Yes, it's used, 0b11 is pll6 parent in case of A31.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com


From maitysanchayan at gmail.com  Thu Feb 11 22:34:03 2016
From: maitysanchayan at gmail.com (maitysanchayan at gmail.com)
Date: Fri, 12 Feb 2016 12:04:03 +0530
Subject: [PATCH v1 2/2] iio: dac: vf610_dac: Add IIO DAC driver for
 Vybrid SoC
In-Reply-To: <alpine.DEB.2.02.1602090729130.22963@pmeerw.net>
References: <cover.1454939346.git.maitysanchayan@gmail.com>
 <5a699d45c89d239f3e49fa83d16a9b467016e219.1454939346.git.maitysanchayan@gmail.com>
 <alpine.DEB.2.02.1602090729130.22963@pmeerw.net>
Message-ID: <20160212063403.GA3056@Sanchayan-Arch.toradex.int>

Hello Peter,

On 16-02-09 07:43:14, Peter Meerwald-Stadler wrote:
> On Tue, 9 Feb 2016, Sanchayan Maity wrote:
> 
> > Add driver support for DAC peripheral on Vybrid SoC.
> 
> comments below
>  
> > Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
> > ---
> >  .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
> >  drivers/iio/dac/Kconfig                            |   8 +
> >  drivers/iio/dac/Makefile                           |   1 +
> >  drivers/iio/dac/vf610_dac.c                        | 302 +++++++++++++++++++++
> >  4 files changed, 331 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
> >  create mode 100644 drivers/iio/dac/vf610_dac.c
> > 
> > diff --git a/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
> > new file mode 100644
> > index 0000000..97d7a40
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
> > @@ -0,0 +1,20 @@
> > +Freescale vf610 Digital to Analog Converter bindings
> > +
> > +The devicetree bindings are for the new DAC driver written for
> > +vf610 SoCs from Freescale.
> > +
> > +Required properties:
> > +- compatible: Should contain "fsl,vf610-dac"
> > +- reg: Offset and length of the register set for the device
> > +- interrupts: Should contain the interrupt for the device
> > +- clocks: The clock is needed by the DAC controller
> > +- clock-names: Must contain "dac", matching entry in the clocks property.
> 
> the last sentence is not quite clear; is the comma needed?
> 
> > +
> > +Example:
> > +dac0: dac at 400cc000 {
> > +	compatible = "fsl,vf610-dac";
> > +	reg = <0x400cc000 0x1000>;
> > +	interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
> > +	clock-names = "dac";
> > +	clocks = <&clks VF610_CLK_DAC0>;
> > +};
> > diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> > index e701e28..8eb0502 100644
> > --- a/drivers/iio/dac/Kconfig
> > +++ b/drivers/iio/dac/Kconfig
> > @@ -196,4 +196,12 @@ config MCP4922
> >  	  To compile this driver as a module, choose M here: the module
> >  	  will be called mcp4922.
> >  
> > +config VF610_DAC
> > +	tristate "Vybrid vf610 DAC driver"
> > +	help
> > +	  Say yes here to support Vybrid board digital-to-analog converter.
> > +
> > +	  This driver can also be built as a module. If so, the module will
> > +	  be called vf610_dac.
> > +
> >  endmenu
> > diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> > index 63ae056..93feb27 100644
> > --- a/drivers/iio/dac/Makefile
> > +++ b/drivers/iio/dac/Makefile
> > @@ -21,3 +21,4 @@ obj-$(CONFIG_MAX517) += max517.o
> >  obj-$(CONFIG_MAX5821) += max5821.o
> >  obj-$(CONFIG_MCP4725) += mcp4725.o
> >  obj-$(CONFIG_MCP4922) += mcp4922.o
> > +obj-$(CONFIG_VF610_DAC) += vf610_dac.o
> > diff --git a/drivers/iio/dac/vf610_dac.c b/drivers/iio/dac/vf610_dac.c
> > new file mode 100644
> > index 0000000..775b349
> > --- /dev/null
> > +++ b/drivers/iio/dac/vf610_dac.c
> > @@ -0,0 +1,302 @@
> > +/*
> > + * Freescale Vybrid vf610 DAC driver
> > + *
> > + * Copyright 2016 Toradex AG
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/err.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/io.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regulator/consumer.h>
> > +#include <linux/slab.h>
> > +
> > +#include <linux/iio/iio.h>
> > +#include <linux/iio/sysfs.h>
> > +
> > +#define DRIVER_NAME "vf610-dac"
> 
> VF610_ prefix
> 
> > +
> > +#define VF610_DACx_STATCTRL		0x20
> > +
> > +#define VF610_DAC_DACEN			BIT(15)
> > +#define VF610_DAC_DACRFS		BIT(14)
> > +#define VF610_DAC_LPEN			BIT(11)
> > +
> > +#define VF610_DAC_DAT0(x)		((x) & 0xFFF)
> > +
> > +enum conversion_mode_sel {
> 
> vf610_ prefix
> 
> > +	VF610_DAC_CONV_HIGH_POWER,
> > +	VF610_DAC_CONV_LOW_POWER,
> > +};
> > +
> > +struct vf610_dac {
> > +	struct clk *clk;
> > +	struct device *dev;
> > +	enum conversion_mode_sel conv_mode;
> > +	void __iomem *regs;
> > +	int irq;
> > +};
> > +
> > +static int vf610_dac_init(struct vf610_dac *info)
> 
> should be void, or check the return value
> 
> > +{
> > +	int val;
> > +
> > +	info->conv_mode = VF610_DAC_CONV_LOW_POWER;
> > +	val = VF610_DAC_DACEN | VF610_DAC_DACRFS |
> > +		VF610_DAC_LPEN;
> > +	writel(val, info->regs + VF610_DACx_STATCTRL);
> > +
> > +	return 0;
> > +}
> > +
> > +static int vf610_set_conversion_mode(struct iio_dev *indio_dev,
> > +				const struct iio_chan_spec *chan,
> > +				unsigned int mode)
> 
> mode should be enum conversion_mode_sel?
> 
> > +{
> > +	struct vf610_dac *info = iio_priv(indio_dev);
> > +	int val;
> > +
> > +	mutex_lock(&indio_dev->mlock);
> > +	info->conv_mode = mode;
> > +	val = readl(info->regs + VF610_DACx_STATCTRL);
> > +	if (mode)
> > +		val |= VF610_DAC_LPEN;
> > +	else
> > +		val &= ~VF610_DAC_LPEN;
> > +	writel(val, info->regs + VF610_DACx_STATCTRL);
> > +	mutex_unlock(&indio_dev->mlock);
> > +
> > +	return 0;
> > +}
> > +
> > +static int vf610_get_conversion_mode(struct iio_dev *indio_dev,
> 
> return of type enum conversion_mode_sel?


Regarding the enum. As per the function prototype in iio.h

struct iio_enum {
        const char * const *items;
        unsigned int num_items;
        int (*set)(struct iio_dev *, const struct iio_chan_spec *, unsigned int);
        int (*get)(struct iio_dev *, const struct iio_chan_spec *);
};

the "mode" argument is unsigned int and return type of getter is int as well.

> 
> > +				const struct iio_chan_spec *chan)
> > +{
> > +	struct vf610_dac *info = iio_priv(indio_dev);
> > +
> > +	return info->conv_mode;
> > +}
> > +
> > +static const char * const vf610_conv_modes[] = { "high-power", "low-power"};
> 
> this should be documented in sysfs-bus-iio-vf610; maybe high-power should 
> be high-speed
> 
> probably this interface should have been exposed as a settable 
> conversion rate

Vybrid DAC block does not provide for setting a conversion rate. There is only one
register for configration and only one LPEN bit concerning power mode. As per the
operating behavior, this controls characteristics of supply current, settling time
and slew rate. 

While I agree this should be documented in ABI sysfs documentation, I am not clear
as to how that should be. Currently that document specifies the modes observed for
the vf610 ADC driver. As per the datasheet, "high-power" and "low-power" would be
the most clear description in case of DAC but "normal", "high-speed" and "low-power"
are applicable for ADC. This just stuck me just now while making the change.

How should I best include this? Peter, Jonathan, Stefan suggestions?

I have changed the code to include all other feedback. Thank you for feedback.

Best Regards,
Sanchayan.

> 
> > +
> > +static const struct iio_enum vf610_conversion_mode = {
> > +	.items = vf610_conv_modes,
> > +	.num_items = ARRAY_SIZE(vf610_conv_modes),
> > +	.get = vf610_get_conversion_mode,
> > +	.set = vf610_set_conversion_mode,
> > +};
> > +
> > +static const struct iio_chan_spec_ext_info vf610_ext_info[] = {
> > +	IIO_ENUM("conversion_mode", IIO_SHARED_BY_DIR,
> > +		&vf610_conversion_mode),
> > +	{},
> > +};
> > +
> > +#define VF610_DAC_CHAN(_chan_type) { \
> > +	.type = (_chan_type), \
> > +	.indexed = -1, \
> 
> indexed should be 0 (or not specified) if no indexing is to be used
> 
> > +	.output = 1, \
> > +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> > +	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> > +	.ext_info = vf610_ext_info, \
> > +}
> > +
> > +static const struct iio_chan_spec vf610_dac_iio_channels[] = {
> > +	VF610_DAC_CHAN(IIO_VOLTAGE),
> > +};
> > +
> > +static int vf610_read_raw(struct iio_dev *indio_dev,
> > +			struct iio_chan_spec const *chan,
> > +			int *val, int *val2,
> > +			long mask)
> > +{
> > +	struct vf610_dac *info = iio_priv(indio_dev);
> > +
> > +	switch (mask) {
> > +	case IIO_CHAN_INFO_RAW:
> > +		*val = VF610_DAC_DAT0(readl(info->regs));
> > +		return IIO_VAL_INT;
> > +	case IIO_CHAN_INFO_SCALE:
> > +		/*
> > +		 * DACRFS is always 1 for valid reference and typical
> > +		 * reference voltage as per Vybrid datasheet is 3.3V
> > +		 * from section 9.1.2.1 of Vybrid datasheet
> > +		 */
> > +		*val = 3300 /* mV */;
> > +		*val2 = 12;
> > +		return IIO_VAL_FRACTIONAL_LOG2;
> > +
> > +	default:
> > +		break;
> 
> just return -EINVAL here?
> and remove it below below
> 
> > +	}
> > +
> > +	return -EINVAL;
> > +}
> > +
> > +static int vf610_write_raw(struct iio_dev *indio_dev,
> > +			struct iio_chan_spec const *chan,
> > +			int val, int val2,
> > +			long mask)
> > +{
> > +	struct vf610_dac *info = iio_priv(indio_dev);
> > +
> > +	switch (mask) {
> > +	case IIO_CHAN_INFO_RAW:
> > +		mutex_lock(&indio_dev->mlock);
> > +		writel(VF610_DAC_DAT0(val), info->regs);
> > +		mutex_unlock(&indio_dev->mlock);
> > +		return 0;
> > +
> > +	default:
> > +		break;
> 
> return -EINVAL here should save two lines
> 
> > +	}
> > +
> > +	return -EINVAL;
> > +}
> > +
> > +static const struct iio_info vf610_dac_iio_info = {
> > +	.driver_module = THIS_MODULE,
> > +	.read_raw = &vf610_read_raw,
> > +	.write_raw = &vf610_write_raw,
> > +};
> > +
> > +static const struct of_device_id vf610_dac_match[] = {
> > +	{ .compatible = "fsl,vf610-dac", },
> > +	{ /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, vf610_dac_match);
> > +
> > +static int vf610_dac_probe(struct platform_device *pdev)
> > +{
> > +	struct iio_dev *indio_dev;
> > +	struct vf610_dac *info;
> > +	struct resource *mem;
> > +	int ret;
> > +
> > +	indio_dev = devm_iio_device_alloc(&pdev->dev,
> > +					sizeof(struct vf610_dac));
> > +	if (!indio_dev) {
> > +		dev_err(&pdev->dev, "Failed allocating iio device\n");
> > +		return -ENOMEM;
> > +	}
> > +
> > +	info = iio_priv(indio_dev);
> > +	info->dev = &pdev->dev;
> > +
> > +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +	info->regs = devm_ioremap_resource(&pdev->dev, mem);
> > +	if (IS_ERR(info->regs))
> > +		return PTR_ERR(info->regs);
> > +
> > +	info->clk = devm_clk_get(&pdev->dev, "dac");
> > +	if (IS_ERR(info->clk)) {
> > +		dev_err(&pdev->dev, "failed getting clock, err = %ld\n",
> 
> "Failed getting ..."
> 
> > +			PTR_ERR(info->clk));
> > +		return PTR_ERR(info->clk);
> > +	}
> > +
> > +	platform_set_drvdata(pdev, indio_dev);
> > +
> > +	indio_dev->name = dev_name(&pdev->dev);
> > +	indio_dev->dev.parent = &pdev->dev;
> > +	indio_dev->dev.of_node = pdev->dev.of_node;
> > +	indio_dev->info = &vf610_dac_iio_info;
> > +	indio_dev->modes = INDIO_DIRECT_MODE;
> > +	indio_dev->channels = vf610_dac_iio_channels;
> > +	indio_dev->num_channels = ARRAY_SIZE(vf610_dac_iio_channels);
> > +
> > +	ret = clk_prepare_enable(info->clk);
> > +	if (ret) {
> > +		dev_err(&pdev->dev,
> > +			"Could not prepare or enable the clock\n");
> > +		return ret;
> > +	}
> > +
> > +	ret = iio_device_register(indio_dev);
> > +	if (ret) {
> > +		dev_err(&pdev->dev, "Couldn't register the device\n");
> > +		goto error_iio_device_register;
> > +	}
> > +
> > +	vf610_dac_init(info);
> 
> there is a race here, move _dac_init() before _register()
> return value is not checked (or use void)
> 
> > +
> > +	return 0;
> > +
> > +error_iio_device_register:
> > +	clk_disable_unprepare(info->clk);
> > +
> > +	return ret;
> > +}
> > +
> > +static int vf610_dac_remove(struct platform_device *pdev)
> > +{
> > +	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> > +	struct vf610_dac *info = iio_priv(indio_dev);
> > +
> > +	iio_device_unregister(indio_dev);
> > +	clk_disable_unprepare(info->clk);
> > +
> > +	return 0;
> > +}
> > +
> > +#ifdef CONFIG_PM_SLEEP
> > +static int vf610_dac_suspend(struct device *dev)
> > +{
> > +	struct iio_dev *indio_dev = dev_get_drvdata(dev);
> > +	struct vf610_dac *info = iio_priv(indio_dev);
> > +	int val;
> > +
> > +	val = readl(info->regs + VF610_DACx_STATCTRL);
> > +	val &= ~VF610_DAC_DACEN;
> > +	writel(val, info->regs + VF610_DACx_STATCTRL);
> > +
> > +	clk_disable_unprepare(info->clk);
> > +
> > +	return 0;
> > +}
> > +
> > +static int vf610_dac_resume(struct device *dev)
> > +{
> > +	struct iio_dev *indio_dev = dev_get_drvdata(dev);
> > +	struct vf610_dac *info = iio_priv(indio_dev);
> > +	int ret;
> > +
> > +	ret = clk_prepare_enable(info->clk);
> > +	if (ret)
> > +		return ret;
> > +
> > +	vf610_dac_init(info);
> > +
> > +	return 0;
> > +}
> > +#endif
> > +
> > +static SIMPLE_DEV_PM_OPS(vf610_dac_pm_ops, vf610_dac_suspend, vf610_dac_resume);
> > +
> > +static struct platform_driver vf610_dac_driver = {
> > +	.probe          = vf610_dac_probe,
> > +	.remove         = vf610_dac_remove,
> > +	.driver         = {
> > +		.name   = DRIVER_NAME,
> > +		.of_match_table = vf610_dac_match,
> > +		.pm     = &vf610_dac_pm_ops,
> > +	},
> > +};
> > +module_platform_driver(vf610_dac_driver);
> > +
> > +MODULE_AUTHOR("Sanchayan Maity <sanchayan.maity at toradex.com");
> > +MODULE_DESCRIPTION("Freescale VF610 DAC driver");
> > +MODULE_LICENSE("GPL v2");
> > 
> 
> -- 
> 
> Peter Meerwald-Stadler
> +43-664-2444418 (mobile)


From a.hajda at samsung.com  Thu Feb 11 22:38:51 2016
From: a.hajda at samsung.com (Andrzej Hajda)
Date: Fri, 12 Feb 2016 07:38:51 +0100
Subject: [PATCH] tty/serial: digicolor: Fix bad usage of IS_ERR_VALUE
In-Reply-To: <20160211153243.GA3076@roeck-us.net>
References: <1455030539-10798-1-git-send-email-linux@roeck-us.net>
 <4571887.rTPndCnv20@wuerfel> <56BAA27A.9050605@roeck-us.net>
 <2606061.l722KO95iI@wuerfel> <56BC022B.7030004@roeck-us.net>
 <56BC2DF7.20803@samsung.com> <20160211153243.GA3076@roeck-us.net>
Message-ID: <56BD7DFB.10608@samsung.com>

On 02/11/2016 04:32 PM, Guenter Roeck wrote:
> On Thu, Feb 11, 2016 at 07:45:11AM +0100, Andrzej Hajda wrote:
>> On 02/11/2016 04:38 AM, Guenter Roeck wrote:
>>> On 02/10/2016 07:21 AM, Arnd Bergmann wrote:
>>>> On Tuesday 09 February 2016 18:37:46 Guenter Roeck wrote:
>>>>> On 02/09/2016 07:26 AM, Arnd Bergmann wrote:
>>>>>> On Tuesday 09 February 2016 07:08:59 Guenter Roeck wrote:
>>>>>>> IS_ERR_VALUE() assumes that its parameter is an unsigned long.
>>>>>>> It can not be used to check if an unsigned int reflects an error.
>>>>>>> Doing so can result in the following build warning.
>>>>>>>
>>>>>>> drivers/tty/serial/digicolor-usart.c: In function ?digicolor_uart_probe?:
>>>>>>> include/linux/err.h:21:38: warning:
>>>>>>>           comparison is always false due to limited range of data type
>>>>>>> drivers/tty/serial/digicolor-usart.c:485:6: note:
>>>>>>>           in expansion of macro ?IS_ERR_VALUE?
>>>>>>>
>>>>>>> If that warning is seen, an error return from platform_get_irq() is missed.
>>>>>>>
>>>>>>>
>>>>>> The patch looks correct to me, but what compiler version and which kernel
>>>>>> tree is it that triggered the warning?
>>>>>>
>>>>>> Andrzej Hajda just modified the definition of IS_ERR_VALUE(), and the
>>>>>> changes are still under discussion, but I don't see that warning with
>>>>>> any of the versions.
>>>>>>
>>>>> I see it with gcc 5.1 and 5.2 (and W=1). I did not see / notice Andrzej's patch.
>>>>>
>>>>> I agree that fixing the problem in IS_ERR_VALUE() is preferrable.
>>>>>
>>>>>
>>>> Ah, W=1 explains it. We are still debating about the proper solution. Al Viro
>>>> pointed out that most users of IS_ERR_VALUE() shouldn't be using it at all,
>>>> so your patch is probably best here after all.
>>>>
>>> Yes, after looking into it some more I agree. Coccinelle should be able to handle
>>> most of the conversions automatically. I actually tried to write a script, just
>>> for the fun of it, but it misses some of the problem cases in patch mode.
>>> Maybe I get it working tonight.
>>>
>>> Guenter
>>>
>> Maybe it can be helpful. The script which classifies all IS_ERR_VALUE
>> usages as
>> correct, signed, incorrect and unknown (cocci was not able to detect type).
>> Adding patch mode should be quite simple.
>>
>> // Options: --all-includes --include
>> include/uapi/linux/netfilter_ipv6/ip6_tables.h --include
>> include/uapi/linux/netfilter_ipv4/ip_tables.h --include
>> include/uapi/linux/netfilter_arp/arp_tables.h --include
>> include/uapi/linux/netfilter/x_tables.h --include include/linux/mm_types.h
>>
>> virtual context
>> virtual report
>>
>> @r@
>> typedef bool, u8, u16, u32, u64, s8, s16, s32, s64, __u64, dma_addr_t,
>> Elf32_Addr, Elf64_Addr;
>> {unsigned long, size_t} ev;
>> {short, int, long, s16, s32, ssize_t} ew;
>> {char, unsigned char, unsigned short, unsigned int, long long, unsigned
>> long long, bool, u8, u16, u32, u64, s64, __u64, dma_addr_t, Elf32_Addr,
>> Elf64_Addr} ei;
>> expression eu;
>> position p;
>> @@
>>
>> IS_ERR_VALUE(\(ev \| ew \| ei \| eu \))@p
>>
>> @script:python depends on report@
>> p << r.p = [];
>> ev << r.ev = "";
>> ew << r.ew = "";
>> ei << r.ei = "";
>> eu << r.eu = "";
> This doesn't work for me; it bails out at the assignments. If I remove
> the assignments, it does not report anything.
>
> Any idea what might be wrong ?

Old version of spatch. Default values are supported since 1.0.3.

Regards
Andrzej



From kishon at ti.com  Thu Feb 11 22:49:53 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 12 Feb 2016 12:19:53 +0530
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <alpine.DEB.2.02.1602111921090.20757@utopia.booyaka.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com> <56BACCDB.2070507@ti.com>
 <alpine.DEB.2.02.1602111921090.20757@utopia.booyaka.com>
Message-ID: <56BD8091.4090007@ti.com>

Hi,

On Friday 12 February 2016 12:57 AM, Paul Walmsley wrote:
> Hi Kishon, Suman,
> 
> On Wed, 10 Feb 2016, Kishon Vijay Abraham I wrote:
> 
>> On Wednesday 10 February 2016 07:12 AM, Suman Anna wrote:
>>> On 02/09/2016 01:36 PM, Paul Walmsley wrote:
>>>> On Tue, 9 Feb 2016, Suman Anna wrote:
>>>>> On 02/09/2016 02:49 AM, Paul Walmsley wrote:
>>>>>> On Mon, 8 Feb 2016, Suman Anna wrote:
>>>>>>> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
>>>>>>>> On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:
>>>>>>>>
>>>>>>>>> Paul, what do you think is the best way forward to perform reset?
>>>>>>>>
>>>>>>>> Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
>>>>>>>> Those often need special reset handling to ensure that WFI/HLT-like 
>>>>>>>> instructions are executed after reset.  This special handling ensures that 
>>>>>>>> the IP blocks' bus initiator interfaces indicate that they are in standby 
>>>>>>>> to the PRCM - thus allowing power management for the rest of the chip to 
>>>>>>>> work correctly.
>>>>>>>>
>>>>>>>> But that doesn't seem to be the case with PCIe - and maybe others - 
>>>>>>>> possibly some of the MMUs?  
>>>>>>>
>>>>>>> Yeah, the sequencing between clocks and resets would still be the same
>>>>>>> for MMUs, so, adding the custom flags for MMUs is fine.
>>>>>>
>>>>>> I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs.  
>>>>>> We've stated that the main point of the custom hardreset code is to handle 
>>>>>> processors that need to be placed into WFI/HLT, but it doesn't seem like 
>>>>>> there would be an equivalent for MMUs.  Thoughts?
>>>>>
>>>>> The current OMAP IOMMU code already leverages the pdata ops for
>>>>> performing the resets, so not adding the flags would also require
>>>>> additional changes in the driver.
>>>>>
>>>>> Also, the reset lines controlling the MMUs actually also manage the
>>>>> reset for all the other sub-modules other than the processor cores
>>>>> within the sub-systems. We have currently different issues (see [1] for
>>>>> eg. around the IPU sub-system entering RET in between), so from a PM
>>>>> point of view, we do prefer to place the MMUs also in reset when we are
>>>>> runtime suspended.
>>>>
>>>> Should we reassert hardreset in _idle() for IP blocks that don't have 
>>>> HWMOD_CUSTOM_HARDRESET set on them?  Would that allow us to use this 
>>>> mechanism for the uncore hardreset lines, or are there other quirks?
>>>>
>>>> Also - would that address the potential issue that you mentioned with the 
>>>> PCIe block, or is that a different issue?
>>>
>>> Yeah, I think that would address the PCIe block issue in terms of reset
>>> state balancing between pm_runtime_get_sync() and pm_runtime_put()
>>> calls. Right now, they are unbalanced. The PCIe block is using these
>>> only in probe and remove, so it should work for that IP.
>>
>> As I mentioned before this would result in undesired behavior during
>> suspend/resume cycle in PCIe. (This should be okay for the current mainline
>> code but would break once we add suspend/resume support for PCIe).
> 
> I'd like to understand where we're currently at here.  It looks like we're 
> waiting for testing from Suman, and we're waiting for Kishon to try using 
> the bind/unbind driver model hook to see if that wedges PCIe?  Does this 
> match your collective understanding of the status here?

I got to try this and looks like even without this series there are other PM
issues possible introduced by Commit 5de85b9d57ab ("PM / runtime: Re-init
runtime PM states at probe error and driver unbind").

Now I get this error if I tried to modprobe after rmmod pci-dra7xx.
[   54.352860] dra7-pcie 51000000.pcie: omap_device: omap_device_enable()
called from invalid state 1
[   54.362318] dra7-pcie 51000000.pcie: pm_runtime_get_sync failed
[   54.368624] dra7-pcie: probe of 51000000.pcie failed with error -22

>From the thread that fixes this issue [1], looks like drivers that use
*_autosuspend() get this issue. However I don't use *_autosuspend() in
pci-dra7xx. Maybe pci core has this? This has to be debugged further. But I
feel this is not related to the problem that we are trying to solve right now
(dra7 hangs if PCI driver is enabled) and given the fact that pci-dra7xx driver
is now modeled as built-in driver, this can be deferred.

[1] -> http://www.spinics.net/lists/arm-kernel/msg481845.html

> 
> Thinking about the question of what to do about hardreset assertion in 
> idle, if we need it, we could add a hwmod flag to control that mode.  I 
> would consider it a temporary workaround until we have the hwmod code 
> moved into a bus driver and the bus driver/hwmod code can hook into the 
> LDM .remove operation (and connect it to .shutdown, etc.)  Suman/Kishon: 
> is it your understanding that we could remove the existing hardreset 
> control in the IOMMU drivers and the PCIe driver if we had these options 
> in the hwmod code? 

Yeah, that's my understanding. And since this series solves the PCIe problem,
it's proven that hardreset control can be moved to hwmod code.

For PCIe, it's even okay to do deassert in _reset, but I'm not sure if it'll
have side effects with other modules.

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e9f65fe..24cafd9 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1966,8 +1966,11 @@ static int _reset(struct omap_hwmod *oh)
 		r = oh->class->reset(oh);
 	} else {
 		if (oh->rst_lines_cnt > 0) {
-			for (i = 0; i < oh->rst_lines_cnt; i++)
+			for (i = 0; i < oh->rst_lines_cnt; i++) {
 				_assert_hardreset(oh, oh->rst_lines[i].name);
+				if (!(oh->flags & HWMOD_CUSTOM_HARDRESET))
+					_deassert_hardreset(oh, oh->rst_lines[i].name);
+			}
 			return 0;
 		} else {
 			r = _ocp_softreset(oh);

Thanks
Kishon

P.S. I'll be on vacation till end of next week with no email access till then.
So email response will be delayed. Sorry about that.
> 
> Dave, any further comments here?
> 
> 
> - Paul
> 


From kishon at ti.com  Thu Feb 11 22:55:49 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Fri, 12 Feb 2016 12:25:49 +0530
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <56BCF256.8010903@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com> <56BACCDB.2070507@ti.com> <56BCF256.8010903@ti.com>
Message-ID: <56BD81F5.8090404@ti.com>

Hi Suman,

On Friday 12 February 2016 02:13 AM, Suman Anna wrote:
> On 02/09/2016 11:38 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 10 February 2016 07:12 AM, Suman Anna wrote:
>>> Hi Paul,
>>>
>>> On 02/09/2016 01:36 PM, Paul Walmsley wrote:
>>>> Hi Suman 
>>>>
>>>> On Tue, 9 Feb 2016, Suman Anna wrote:
>>>>
>>>>> On 02/09/2016 02:49 AM, Paul Walmsley wrote:
>>>>>> On Mon, 8 Feb 2016, Suman Anna wrote:
>>>>>>> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
>>>>>>>> On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:
>>>>>>>>
>>>>>>>>> Paul, what do you think is the best way forward to perform reset?
>>>>>>>>
>>>>>>>> Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
>>>>>>>> Those often need special reset handling to ensure that WFI/HLT-like 
>>>>>>>> instructions are executed after reset.  This special handling ensures that 
>>>>>>>> the IP blocks' bus initiator interfaces indicate that they are in standby 
>>>>>>>> to the PRCM - thus allowing power management for the rest of the chip to 
>>>>>>>> work correctly.
>>>>>>>>
>>>>>>>> But that doesn't seem to be the case with PCIe - and maybe others - 
>>>>>>>> possibly some of the MMUs?  
>>>>>>>
>>>>>>> Yeah, the sequencing between clocks and resets would still be the same
>>>>>>> for MMUs, so, adding the custom flags for MMUs is fine.
>>>>>>
>>>>>> I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs.  
>>>>>> We've stated that the main point of the custom hardreset code is to handle 
>>>>>> processors that need to be placed into WFI/HLT, but it doesn't seem like 
>>>>>> there would be an equivalent for MMUs.  Thoughts?
>>>>>
>>>>> The current OMAP IOMMU code already leverages the pdata ops for
>>>>> performing the resets, so not adding the flags would also require
>>>>> additional changes in the driver.
>>>>>
>>>>> Also, the reset lines controlling the MMUs actually also manage the
>>>>> reset for all the other sub-modules other than the processor cores
>>>>> within the sub-systems. We have currently different issues (see [1] for
>>>>> eg. around the IPU sub-system entering RET in between), so from a PM
>>>>> point of view, we do prefer to place the MMUs also in reset when we are
>>>>> runtime suspended.
>>>>
>>>> Should we reassert hardreset in _idle() for IP blocks that don't have 
>>>> HWMOD_CUSTOM_HARDRESET set on them?  Would that allow us to use this 
>>>> mechanism for the uncore hardreset lines, or are there other quirks?
>>>>
>>>> Also - would that address the potential issue that you mentioned with the 
>>>> PCIe block, or is that a different issue?
>>>
>>> Yeah, I think that would address the PCIe block issue in terms of reset
>>> state balancing between pm_runtime_get_sync() and pm_runtime_put()
>>> calls. Right now, they are unbalanced. The PCIe block is using these
>>> only in probe and remove, so it should work for that IP.
>>
>> As I mentioned before this would result in undesired behavior during
>> suspend/resume cycle in PCIe. (This should be okay for the current mainline
>> code but would break once we add suspend/resume support for PCIe).
> 
> Yeah, I was wondering if some peripheral would want only the clock to be
> controlled during _idle() and not reset. Even then for the PCIe case
> that you are talking about, going through a pm_runtime_get_sync(),
> pm_runtime_put_sync()/pm_runtime_put() deasserts the resets everytime

right. But it'll deassert a line which is already deasserted. So it actually
doesn't do a reset again.
> _enable() is called. Right now, the code block has ignored the return
> value from the _hardreset_deassert(), but if you check it and bail out,
> then your get_sync() would start failing from the second invocation.

hmm.. yeah.
> 
> Can you elaborate more on what kind of issues you will see on
> suspend/resume cycle with PCIe? Do note that _idle() gets called through

At this point there are other issues w.r.t suspend/resume in PCI-dra7xx but as
such reset of the controller is not desired during suspend/resume cycle and
it'll result in the register contents being reset (haven't tested it though).

Thanks
Kishon


From shaun.ren at linux.com  Thu Feb 11 22:56:08 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Thu, 11 Feb 2016 22:56:08 -0800
Subject: [PATCH v5 2/8] Staging: rts5208: rtsx_transport.c: Align to open
 parenthesis
In-Reply-To: <1455251535.13149.7.camel@perches.com>
References: <1455251535.13149.7.camel@perches.com>
Message-ID: <1455260168-16980-1-git-send-email-shaun.ren@linux.com>

This patch fixes the alignment issue reported by checkpatch.pl:

CHECK: Alignment should match open parenthesis

Add a unsigned char *sgbuffer in rtsx_stor_access_xfer_buffer to make the
following memcpy logic easier to read.

Add a struct scatterlist *sg in the use_sg branch of
rtsx_transfer_data_partial to make the parameters of the
rtsx_transfer_sglist_adma_partial call fit in 80 character lines after
aligning them to the open parenthesis.

Refactor memcpy logic in rtsx_stor_access_xfer_buf to make it more legible.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 69 +++++++++++++++++++-------------
Changes since v3
  * Fixed misalignment of the last parameter of rtsx_stor_access_xfer_buf()
  * Refactored memcpy in rtsx_stor_access_xfer_buf() for legibility

 1 file changed, 41 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 91fdccf..b6de93f 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -42,22 +42,28 @@
  */
 
 unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
-	unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
-	unsigned int *offset, enum xfer_buf_dir dir)
+				       unsigned int buflen,
+				       struct scsi_cmnd *srb,
+				       unsigned int *index,
+				       unsigned int *offset,
+				       enum xfer_buf_dir dir)
 {
 	unsigned int cnt;
 
 	/* If not using scatter-gather, just transfer the data directly. */
 	if (scsi_sg_count(srb) == 0) {
+		unsigned char *sgbuffer;
+
 		if (*offset >= scsi_bufflen(srb))
 			return 0;
 		cnt = min(buflen, scsi_bufflen(srb) - *offset);
+
+		sgbuffer = (unsigned char *)scsi_sglist(srb) + *offset;
+
 		if (dir == TO_XFER_BUF)
-			memcpy((unsigned char *) scsi_sglist(srb) + *offset,
-					buffer, cnt);
+			memcpy(sgbuffer, buffer, cnt);
 		else
-			memcpy(buffer, (unsigned char *) scsi_sglist(srb) +
-					*offset, cnt);
+			memcpy(buffer, sgbuffer, cnt);
 		*offset += cnt;
 
 	/*
@@ -126,7 +132,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
  * SCSI residue.
  */
 void rtsx_stor_set_xfer_buf(unsigned char *buffer,
-	unsigned int buflen, struct scsi_cmnd *srb)
+			    unsigned int buflen, struct scsi_cmnd *srb)
 {
 	unsigned int index = 0, offset = 0;
 
@@ -137,7 +143,7 @@ void rtsx_stor_set_xfer_buf(unsigned char *buffer,
 }
 
 void rtsx_stor_get_xfer_buf(unsigned char *buffer,
-	unsigned int buflen, struct scsi_cmnd *srb)
+			    unsigned int buflen, struct scsi_cmnd *srb)
 {
 	unsigned int index = 0, offset = 0;
 
@@ -191,8 +197,8 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 		/* set the result so the higher layers expect this data */
 		srb->result = SAM_STAT_CHECK_CONDITION;
 		memcpy(srb->sense_buffer,
-			(unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
-			sizeof(struct sense_data_t));
+		       (unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
+		       sizeof(struct sense_data_t));
 	}
 
 	return;
@@ -202,7 +208,7 @@ Handle_Errors:
 }
 
 void rtsx_add_cmd(struct rtsx_chip *chip,
-		u8 cmd_type, u16 reg_addr, u8 mask, u8 data)
+		  u8 cmd_type, u16 reg_addr, u8 mask, u8 data)
 {
 	u32 *cb = (u32 *)(chip->host_cmds_ptr);
 	u32 val = 0;
@@ -321,9 +327,11 @@ static inline void rtsx_add_sg_tbl(
 }
 
 static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
-		struct scatterlist *sg, int num_sg, unsigned int *index,
-		unsigned int *offset, int size,
-		enum dma_data_direction dma_dir, int timeout)
+					     struct scatterlist *sg, int num_sg,
+					     unsigned int *index,
+					     unsigned int *offset, int size,
+					     enum dma_data_direction dma_dir,
+					     int timeout)
 {
 	struct rtsx_dev *rtsx = chip->rtsx;
 	struct completion trans_done;
@@ -486,8 +494,9 @@ out:
 }
 
 static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
-		struct scatterlist *sg, int num_sg,
-		enum dma_data_direction dma_dir, int timeout)
+				     struct scatterlist *sg, int num_sg,
+				     enum dma_data_direction dma_dir,
+				     int timeout)
 {
 	struct rtsx_dev *rtsx = chip->rtsx;
 	struct completion trans_done;
@@ -633,7 +642,8 @@ out:
 }
 
 static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
-		size_t len, enum dma_data_direction dma_dir, int timeout)
+			     size_t len, enum dma_data_direction dma_dir,
+			     int timeout)
 {
 	struct rtsx_dev *rtsx = chip->rtsx;
 	struct completion trans_done;
@@ -716,9 +726,9 @@ out:
 }
 
 int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
-		void *buf, size_t len, int use_sg, unsigned int *index,
-		unsigned int *offset, enum dma_data_direction dma_dir,
-		int timeout)
+			       void *buf, size_t len, int use_sg,
+			       unsigned int *index, unsigned int *offset,
+			       enum dma_data_direction dma_dir, int timeout)
 {
 	int err = 0;
 
@@ -726,13 +736,16 @@ int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
 	if (rtsx_chk_stat(chip, RTSX_STAT_ABORT))
 		return -EIO;
 
-	if (use_sg)
-		err = rtsx_transfer_sglist_adma_partial(chip, card,
-				(struct scatterlist *)buf, use_sg,
-				index, offset, (int)len, dma_dir, timeout);
-	else
+	if (use_sg) {
+		struct scatterlist *sg = (struct scatterlist *)buf;
+
+		err = rtsx_transfer_sglist_adma_partial(chip, card, sg, use_sg,
+							index, offset, (int)len,
+							dma_dir, timeout);
+	} else {
 		err = rtsx_transfer_buf(chip, card,
 					buf, len, dma_dir, timeout);
+	}
 	if (err < 0) {
 		if (RTSX_TST_DELINK(chip)) {
 			RTSX_CLR_DELINK(chip);
@@ -745,7 +758,7 @@ int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
 }
 
 int rtsx_transfer_data(struct rtsx_chip *chip, u8 card, void *buf, size_t len,
-		int use_sg, enum dma_data_direction dma_dir, int timeout)
+		       int use_sg, enum dma_data_direction dma_dir, int timeout)
 {
 	int err = 0;
 
@@ -757,8 +770,8 @@ int rtsx_transfer_data(struct rtsx_chip *chip, u8 card, void *buf, size_t len,
 
 	if (use_sg) {
 		err = rtsx_transfer_sglist_adma(chip, card,
-				(struct scatterlist *)buf,
-				use_sg, dma_dir, timeout);
+						(struct scatterlist *)buf,
+						use_sg, dma_dir, timeout);
 	} else {
 		err = rtsx_transfer_buf(chip, card, buf, len, dma_dir, timeout);
 	}
-- 
2.7.0



From dirk.behme at de.bosch.com  Thu Feb 11 23:11:33 2016
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Fri, 12 Feb 2016 08:11:33 +0100
Subject: [PATCH] ARM: imx: Do L2 errata only if the L2 cache isn't enabled
Message-ID: <1455261093-11849-1-git-send-email-dirk.behme@de.bosch.com>

All the generic L2 cache handling code is encapsulated by a
check if the L2 cache is enabled. If it's enabled already, the code
is skipped.

For the i.MX6 specific L2 cache handling we missed this check.
Add it.

Signed-off-by: Marcel Grosshans <MarcelViktor.Grosshans at de.bosch.com>
Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
---
 arch/arm/mach-imx/system.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-imx/system.c b/arch/arm/mach-imx/system.c
index 51c3501..a600bd7 100644
--- a/arch/arm/mach-imx/system.c
+++ b/arch/arm/mach-imx/system.c
@@ -106,6 +106,9 @@ void __init imx_init_l2cache(void)
 		goto out;
 	}
 
+	if (readl_relaxed(l2x0_base + L2X0_CTRL) & L2X0_CTRL_EN)
+		goto skip_if_enabled;
+
 	/* Configure the L2 PREFETCH and POWER registers */
 	val = readl_relaxed(l2x0_base + L310_PREFETCH_CTRL);
 	val |= 0x70800000;
@@ -122,6 +125,7 @@ void __init imx_init_l2cache(void)
 		val &= ~(1 << 30 | 1 << 23);
 	writel_relaxed(val, l2x0_base + L310_PREFETCH_CTRL);
 
+skip_if_enabled:
 	iounmap(l2x0_base);
 	of_node_put(np);
 
-- 
2.5.0



From ard.biesheuvel at linaro.org  Fri Feb 12 00:08:12 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 09:08:12 +0100
Subject: [PATCH v2 1/3] of/fdt: factor out assignment of
 initrd_start/initrd_end
In-Reply-To: <3591081.dypcHcG82d@wuerfel>
References: <1455209282-9596-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455209282-9596-2-git-send-email-ard.biesheuvel@linaro.org>
 <3591081.dypcHcG82d@wuerfel>
Message-ID: <CAKv+Gu9azpBo=Z12vvf044OBvHGNkF17tfkqe6+G=3C-nAdQTg@mail.gmail.com>

On 11 February 2016 at 23:12, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 11 February 2016 17:48:00 Ard Biesheuvel wrote:
>>
>>  #ifdef CONFIG_BLK_DEV_INITRD
>> +void __weak __early_init_dt_declare_initrd(unsigned long start,
>> +                                          unsigned long end)
>> +{
>> +       initrd_start = (unsigned long)__va(start);
>> +       initrd_end = (unsigned long)__va(end);
>> +       initrd_below_start_ok = 1;
>> +}
>> +
>>
>
> I find __weak functions particularly hard to follow, I think a Kconfig
> symbols or a function you can override by defining a macro in asm/memory.h
> would be nicer.
>

OK, that makes sense.

I will give Catalin a chance to comment before respinning, though.


From eric.auger at linaro.org  Fri Feb 12 00:13:02 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:02 +0000
Subject: [RFC v3 00/15] KVM PCIe/MSI passthrough on ARM/ARM64
Message-ID: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>

This series addresses KVM PCIe passthrough with MSI enabled on ARM/ARM64.
It pursues the efforts done on [1], [2], [3]. It also aims at covering the
same need on PowerPC platforms although the same kind of integration
should be carried out.

On x86 all accesses to the 1MB PA region [FEE0_0000h - FEF0_000h] are directed
as interrupt messages: accesses to this special PA window directly target the
APIC configuration space and not DRAM, meaning the downstream IOMMU is bypassed.

This is not the case on above mentionned platforms where MSI messages emitted
by devices are conveyed through the IOMMU. This means an IOVA/host PA mapping
must exist for the MSI to reach the MSI controller. Normal way to create
IOVA bindings consists in using VFIO DMA MAP API. However in this case
the MSI IOVA is not mapped onto guest RAM but on host physical page (the MSI
controller frame).

In a nutshell, this series does:
- introduce an IOMMU API to register a IOVA window usable for reserved mapping
- reuse VFIO DMA MAP ioctl with a new flag to plug onto that new API
- check if the device MSI-parent controllers allow IRQ remapping
  (allow unsafe interrupt modality) for a given group
- introduce a new IOMMU API to allocate reserved IOVAs and bind them onto
  a physical address
- allow the GICv2M and GICv3-ITS PCI irqchip to map/unmap the MSI frame
  on irq_write_msi_msg

Best Regards

Eric

Testing:
- functional on ARM64 AMD Overdrive HW (single GICv2m frame) with an e1000e
  PCIe card.
- tested there is no regresion on
  x non assigned PCIe driver
  x platform device passthrough
- Not tested: ARM with SR-IOV, ARM GICv3 ITS, ...

References:
[1] [RFC 0/2] VFIO: Add virtual MSI doorbell support
    (https://lkml.org/lkml/2015/7/24/135)
[2] [RFC PATCH 0/6] vfio: Add interface to map MSI pages
    (https://lists.cs.columbia.edu/pipermail/kvmarm/2015-September/016607.html)
[3] [PATCH v2 0/3] Introduce MSI hardware mapping for VFIO
    (http://permalink.gmane.org/gmane.comp.emulators.kvm.arm.devel/3858)

Git:
https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.5-rc3-pcie-passthrough-rfcv3

previous version at
v2: https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.5-rc3-pcie-passthrough-rfcv2
v1: https://git.linaro.org/people/eric.auger/linux.git/shortlog/refs/heads/v4.5-rc1-pcie-passthrough-v1

QEMU Integration:
[RFC v2 0/8] KVM PCI/MSI passthrough with mach-virt
(http://lists.gnu.org/archive/html/qemu-arm/2016-01/msg00444.html)
https://git.linaro.org/people/eric.auger/qemu.git/shortlog/refs/heads/v2.5.0-pci-passthrough-rfc-v2

User Hints:
To allow PCI/MSI passthrough with GICv2M, compile VFIO as a module and
load the vfio_iommu_type1 module with allow_unsafe_interrupts param:
sudo modprobe -v vfio-pci
sudo modprobe -r vfio_iommu_type1
sudo modprobe -v vfio_iommu_type1 allow_unsafe_interrupts=1

History:

RFC v2 -> RFC v3:
- should fix wrong handling of some CONFIG combinations:
  CONFIG_IOVA, CONFIG_IOMMU_API, CONFIG_PCI_MSI_IRQ_DOMAIN
- fix MSI_FLAG_IRQ_REMAPPING setting in GICv3 ITS (although not tested)

PATCH v1 -> RFC v2:
- reverted to RFC since it looks more reasonable ;-) the code is split
  between VFIO, IOMMU, MSI controller and I am not sure I did the right
  choices. Also API need to be further discussed.
- iova API usage in arm-smmu.c.
- MSI controller natively programs the MSI addr with either the PA or IOVA.
  This is not done anymore in vfio-pci driver as suggested by Alex.
- check irq remapping capability of the group

RFC v1 [2] -> PATCH v1:
- use the existing dma map/unmap ioctl interface with a flag to register a
  reserved IOVA range. Use the legacy Rb to store this special vfio_dma.
- a single reserved IOVA contiguous region now is allowed
- use of an RB tree indexed by PA to store allocated reserved slots
- use of a vfio_domain iova_domain to manage iova allocation within the
  window provided by the userspace
- vfio alloc_map/unmap_free take a vfio_group handle
- vfio_group handle is cached in vfio_pci_device
- add ref counting to bindings
- user modality enabled at the end of the series


Eric Auger (15):
  iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute
  vfio: expose MSI mapping requirement through VFIO_IOMMU_GET_INFO
  vfio: introduce VFIO_IOVA_RESERVED vfio_dma type
  iommu: add alloc/free_reserved_iova_domain
  iommu/arm-smmu: implement alloc/free_reserved_iova_domain
  iommu/arm-smmu: add a reserved binding RB tree
  iommu: iommu_get/put_single_reserved
  iommu/arm-smmu: implement iommu_get/put_single_reserved
  iommu/arm-smmu: relinquish reserved resources on domain deletion
  vfio: allow the user to register reserved iova range for MSI mapping
  msi: Add a new MSI_FLAG_IRQ_REMAPPING flag
  msi: export msi_get_domain_info
  vfio/type1: also check IRQ remapping capability at msi domain
  iommu/arm-smmu: do not advertise IOMMU_CAP_INTR_REMAP
  irqchip/gicv2m/v3-its-pci-msi: IOMMU map the MSI frame when needed

 drivers/iommu/Kconfig                    |   2 +
 drivers/iommu/arm-smmu.c                 | 292 +++++++++++++++++++++++++++++--
 drivers/iommu/fsl_pamu_domain.c          |   2 +
 drivers/iommu/iommu.c                    |  43 +++++
 drivers/irqchip/irq-gic-common.c         |  69 ++++++++
 drivers/irqchip/irq-gic-common.h         |   5 +
 drivers/irqchip/irq-gic-v2m.c            |   7 +-
 drivers/irqchip/irq-gic-v3-its-pci-msi.c |   8 +-
 drivers/vfio/vfio_iommu_type1.c          | 157 ++++++++++++++++-
 include/linux/iommu.h                    |  31 ++++
 include/linux/msi.h                      |   2 +
 include/uapi/linux/vfio.h                |  10 ++
 kernel/irq/msi.c                         |   1 +
 13 files changed, 607 insertions(+), 22 deletions(-)

-- 
1.9.1



From eric.auger at linaro.org  Fri Feb 12 00:13:03 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:03 +0000
Subject: [RFC v3 01/15] iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute
In-Reply-To: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455264797-2334-2-git-send-email-eric.auger@linaro.org>

Introduce new DOMAIN_ATTR_MSI_MAPPING domain attribute. If supported,
this means the MSI addresses need to be mapped in the IOMMU. ARM SMMUS
and FSL PAMU, at least expose this attribute.

x86 IOMMUs typically don't expose the attribute since on x86, MSI write
transaction addresses always are within the 1MB PA region [FEE0_0000h -
FEF0_000h] window which directly targets the APIC configuration space and
hence bypass the sMMU.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan at freescale.com>
Signed-off-by: Eric Auger <eric.auger at linaro.org>

---

RFC v1 -> v1:
- the data field is not used
- for this attribute domain_get_attr simply returns 0 if the MSI_MAPPING
  capability if needed or <0 if not.
- removed struct iommu_domain_msi_maps
---
 drivers/iommu/arm-smmu.c        | 2 ++
 drivers/iommu/fsl_pamu_domain.c | 2 ++
 include/linux/iommu.h           | 1 +
 3 files changed, 5 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 59ee4b8..c8b7e71 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1409,6 +1409,8 @@ static int arm_smmu_domain_get_attr(struct iommu_domain *domain,
 	case DOMAIN_ATTR_NESTING:
 		*(int *)data = (smmu_domain->stage == ARM_SMMU_DOMAIN_NESTED);
 		return 0;
+	case DOMAIN_ATTR_MSI_MAPPING:
+		return 0;
 	default:
 		return -ENODEV;
 	}
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index da0e1e3..46d5c6a 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -856,6 +856,8 @@ static int fsl_pamu_get_domain_attr(struct iommu_domain *domain,
 	case DOMAIN_ATTR_FSL_PAMUV1:
 		*(int *)data = DOMAIN_ATTR_FSL_PAMUV1;
 		break;
+	case DOMAIN_ATTR_MSI_MAPPING:
+		break;
 	default:
 		pr_debug("Unsupported attribute type\n");
 		ret = -EINVAL;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index a5c539f..a4fe04a 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -112,6 +112,7 @@ enum iommu_attr {
 	DOMAIN_ATTR_FSL_PAMU_ENABLE,
 	DOMAIN_ATTR_FSL_PAMUV1,
 	DOMAIN_ATTR_NESTING,	/* two stages of translation */
+	DOMAIN_ATTR_MSI_MAPPING, /* Require MSIs mapping in iommu */
 	DOMAIN_ATTR_MAX,
 };
 
-- 
1.9.1



From eric.auger at linaro.org  Fri Feb 12 00:13:04 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:04 +0000
Subject: [RFC v3 02/15] vfio: expose MSI mapping requirement through
 VFIO_IOMMU_GET_INFO
In-Reply-To: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455264797-2334-3-git-send-email-eric.auger@linaro.org>

This patch allows the user-space to retrieve whether msi write
transaction addresses must be mapped. This is returned through the
VFIO_IOMMU_GET_INFO API and its new flag: VFIO_IOMMU_INFO_REQUIRE_MSI_MAP.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan at freescale.com>
Signed-off-by: Eric Auger <eric.auger at linaro.org>

---

RFC v1 -> v1:
- derived from
  [RFC PATCH 3/6] vfio: Extend iommu-info to return MSIs automap state
- renamed allow_msi_reconfig into require_msi_mapping
- fixed VFIO_IOMMU_GET_INFO
---
 drivers/vfio/vfio_iommu_type1.c | 26 ++++++++++++++++++++++++++
 include/uapi/linux/vfio.h       |  1 +
 2 files changed, 27 insertions(+)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 6f1ea3d..c5b57e1 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -255,6 +255,29 @@ static int vaddr_get_pfn(unsigned long vaddr, int prot, unsigned long *pfn)
 }
 
 /*
+ * vfio_domains_require_msi_mapping: indicates whether MSI write transaction
+ * addresses must be mapped
+ *
+ * returns true if it does
+ */
+static bool vfio_domains_require_msi_mapping(struct vfio_iommu *iommu)
+{
+	struct vfio_domain *d;
+	bool ret;
+
+	mutex_lock(&iommu->lock);
+	/* All domains have same require_msi_map property, pick first */
+	d = list_first_entry(&iommu->domain_list, struct vfio_domain, next);
+	if (iommu_domain_get_attr(d->domain, DOMAIN_ATTR_MSI_MAPPING, NULL) < 0)
+		ret = false;
+	else
+		ret = true;
+	mutex_unlock(&iommu->lock);
+
+	return ret;
+}
+
+/*
  * Attempt to pin pages.  We really don't want to track all the pfns and
  * the iommu can only map chunks of consecutive pfns anyway, so get the
  * first page and all consecutive pages with the same locking.
@@ -997,6 +1020,9 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
 
 		info.flags = VFIO_IOMMU_INFO_PGSIZES;
 
+		if (vfio_domains_require_msi_mapping(iommu))
+			info.flags |= VFIO_IOMMU_INFO_REQUIRE_MSI_MAP;
+
 		info.iova_pgsizes = vfio_pgsize_bitmap(iommu);
 
 		return copy_to_user((void __user *)arg, &info, minsz);
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 7d7a4c6..43e183b 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -400,6 +400,7 @@ struct vfio_iommu_type1_info {
 	__u32	argsz;
 	__u32	flags;
 #define VFIO_IOMMU_INFO_PGSIZES (1 << 0)	/* supported page sizes info */
+#define VFIO_IOMMU_INFO_REQUIRE_MSI_MAP (1 << 1)/* MSI must be mapped */
 	__u64	iova_pgsizes;		/* Bitmap of supported page sizes */
 };
 
-- 
1.9.1



From eric.auger at linaro.org  Fri Feb 12 00:13:05 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:05 +0000
Subject: [RFC v3 03/15] vfio: introduce VFIO_IOVA_RESERVED vfio_dma type
In-Reply-To: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455264797-2334-4-git-send-email-eric.auger@linaro.org>

We introduce a vfio_dma type since we will need to discriminate
legacy vfio_dma's from new reserved ones. Since those latter are
not mapped at registration, some treatments need to be reworked:
removal, replay. Currently they are unplugged. In subsequent patches
they will be reworked.

Signed-off-by: Eric Auger <eric.auger at linaro.org>
---
 drivers/vfio/vfio_iommu_type1.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index c5b57e1..b9326c9 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -53,6 +53,15 @@ module_param_named(disable_hugepages,
 MODULE_PARM_DESC(disable_hugepages,
 		 "Disable VFIO IOMMU support for IOMMU hugepages.");
 
+enum vfio_iova_type {
+	VFIO_IOVA_USER = 0, /* standard IOVA used to map user vaddr */
+	/*
+	 * IOVA reserved to map special host physical addresses,
+	 * MSI frames for instance
+	 */
+	VFIO_IOVA_RESERVED,
+};
+
 struct vfio_iommu {
 	struct list_head	domain_list;
 	struct mutex		lock;
@@ -75,6 +84,7 @@ struct vfio_dma {
 	unsigned long		vaddr;		/* Process virtual addr */
 	size_t			size;		/* Map size (bytes) */
 	int			prot;		/* IOMMU_READ/WRITE */
+	enum vfio_iova_type	type;		/* type of IOVA */
 };
 
 struct vfio_group {
@@ -418,7 +428,8 @@ static void vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma *dma)
 
 static void vfio_remove_dma(struct vfio_iommu *iommu, struct vfio_dma *dma)
 {
-	vfio_unmap_unpin(iommu, dma);
+	if (likely(dma->type != VFIO_IOVA_RESERVED))
+		vfio_unmap_unpin(iommu, dma);
 	vfio_unlink_dma(iommu, dma);
 	kfree(dma);
 }
@@ -694,6 +705,10 @@ static int vfio_iommu_replay(struct vfio_iommu *iommu,
 		dma_addr_t iova;
 
 		dma = rb_entry(n, struct vfio_dma, node);
+
+		if (unlikely(dma->type == VFIO_IOVA_RESERVED))
+			continue;
+
 		iova = dma->iova;
 
 		while (iova < dma->iova + dma->size) {
-- 
1.9.1



From eric.auger at linaro.org  Fri Feb 12 00:13:06 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:06 +0000
Subject: [RFC v3 04/15] iommu: add alloc/free_reserved_iova_domain
In-Reply-To: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455264797-2334-5-git-send-email-eric.auger@linaro.org>

Introduce alloc/free_reserved_iova_domain in the IOMMU API.
alloc_reserved_iova_domain initializes an iova domain at a given
iova base address and with a given size. This iova domain will
be used to allocate iova within that window. Those IOVAs will be reserved
for special purpose, typically MSI frame binding. Allocation function
within the reserved iova domain will be introduced in subsequent patches.

This is the responsability of the API user to make sure any IOVA
belonging to that domain are allocated with those allocation functions.

Signed-off-by: Eric Auger <eric.auger at linaro.org>

---
v2 -> v3:
- remove iommu_alloc_reserved_iova_domain & iommu_free_reserved_iova_domain
  static implementation in case CONFIG_IOMMU_API is not set

v1 -> v2:
- moved from vfio API to IOMMU API
---
 drivers/iommu/iommu.c | 22 ++++++++++++++++++++++
 include/linux/iommu.h | 10 ++++++++++
 2 files changed, 32 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 0e3b009..a994f34 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1557,6 +1557,28 @@ int iommu_domain_set_attr(struct iommu_domain *domain,
 }
 EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
 
+int iommu_alloc_reserved_iova_domain(struct iommu_domain *domain,
+				     dma_addr_t iova, size_t size,
+				     unsigned long order)
+{
+	int ret;
+
+	if (!domain->ops->alloc_reserved_iova_domain)
+		return -EINVAL;
+	ret = domain->ops->alloc_reserved_iova_domain(domain, iova,
+						      size, order);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(iommu_alloc_reserved_iova_domain);
+
+void iommu_free_reserved_iova_domain(struct iommu_domain *domain)
+{
+	if (!domain->ops->free_reserved_iova_domain)
+		return;
+	domain->ops->free_reserved_iova_domain(domain);
+}
+EXPORT_SYMBOL_GPL(iommu_free_reserved_iova_domain);
+
 void iommu_get_dm_regions(struct device *dev, struct list_head *list)
 {
 	const struct iommu_ops *ops = dev->bus->iommu_ops;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index a4fe04a..2d1f155 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -195,6 +195,12 @@ struct iommu_ops {
 	int (*domain_set_windows)(struct iommu_domain *domain, u32 w_count);
 	/* Get the number of windows per domain */
 	u32 (*domain_get_windows)(struct iommu_domain *domain);
+	/* allocates the reserved iova domain */
+	int (*alloc_reserved_iova_domain)(struct iommu_domain *domain,
+					  dma_addr_t iova, size_t size,
+					  unsigned long order);
+	/* frees the reserved iova domain */
+	void (*free_reserved_iova_domain)(struct iommu_domain *domain);
 
 #ifdef CONFIG_OF_IOMMU
 	int (*of_xlate)(struct device *dev, struct of_phandle_args *args);
@@ -266,6 +272,10 @@ extern int iommu_domain_get_attr(struct iommu_domain *domain, enum iommu_attr,
 				 void *data);
 extern int iommu_domain_set_attr(struct iommu_domain *domain, enum iommu_attr,
 				 void *data);
+extern int iommu_alloc_reserved_iova_domain(struct iommu_domain *domain,
+					    dma_addr_t iova, size_t size,
+					    unsigned long order);
+extern void iommu_free_reserved_iova_domain(struct iommu_domain *domain);
 struct device *iommu_device_create(struct device *parent, void *drvdata,
 				   const struct attribute_group **groups,
 				   const char *fmt, ...) __printf(4, 5);
-- 
1.9.1



From eric.auger at linaro.org  Fri Feb 12 00:13:07 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:07 +0000
Subject: [RFC v3 05/15] iommu/arm-smmu: implement
 alloc/free_reserved_iova_domain
In-Reply-To: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455264797-2334-6-git-send-email-eric.auger@linaro.org>

Implement alloc/free_reserved_iova_domain for arm-smmu. we use
the iova allocator (iova.c). The iova_domain is attached to the
arm_smmu_domain struct. A mutex is introduced to protect it.

Signed-off-by: Eric Auger <eric.auger at linaro.org>

---
v2 -> v3:
- select IOMMU_IOVA when ARM_SMMU or ARM_SMMU_V3 is set

v1 -> v2:
- formerly implemented in vfio_iommu_type1
---
 drivers/iommu/Kconfig    |  2 ++
 drivers/iommu/arm-smmu.c | 87 +++++++++++++++++++++++++++++++++++++++---------
 2 files changed, 74 insertions(+), 15 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index a1e75cb..1106528 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -289,6 +289,7 @@ config ARM_SMMU
 	bool "ARM Ltd. System MMU (SMMU) Support"
 	depends on (ARM64 || ARM) && MMU
 	select IOMMU_API
+	select IOMMU_IOVA
 	select IOMMU_IO_PGTABLE_LPAE
 	select ARM_DMA_USE_IOMMU if ARM
 	help
@@ -302,6 +303,7 @@ config ARM_SMMU_V3
 	bool "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
 	depends on ARM64 && PCI
 	select IOMMU_API
+	select IOMMU_IOVA
 	select IOMMU_IO_PGTABLE_LPAE
 	select GENERIC_MSI_IRQ_DOMAIN
 	help
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index c8b7e71..f42341d 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -42,6 +42,7 @@
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include <linux/iova.h>
 
 #include <linux/amba/bus.h>
 
@@ -347,6 +348,9 @@ struct arm_smmu_domain {
 	enum arm_smmu_domain_stage	stage;
 	struct mutex			init_mutex; /* Protects smmu pointer */
 	struct iommu_domain		domain;
+	struct iova_domain		*reserved_iova_domain;
+	/* protects reserved domain manipulation */
+	struct mutex			reserved_mutex;
 };
 
 static struct iommu_ops arm_smmu_ops;
@@ -975,6 +979,7 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
 		return NULL;
 
 	mutex_init(&smmu_domain->init_mutex);
+	mutex_init(&smmu_domain->reserved_mutex);
 	spin_lock_init(&smmu_domain->pgtbl_lock);
 
 	return &smmu_domain->domain;
@@ -1446,22 +1451,74 @@ out_unlock:
 	return ret;
 }
 
+static int arm_smmu_alloc_reserved_iova_domain(struct iommu_domain *domain,
+					       dma_addr_t iova, size_t size,
+					       unsigned long order)
+{
+	unsigned long granule, mask;
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	int ret = 0;
+
+	granule = 1UL << order;
+	mask = granule - 1;
+	if (iova & mask || (!size) || (size & mask))
+		return -EINVAL;
+
+	if (smmu_domain->reserved_iova_domain)
+		return -EEXIST;
+
+	mutex_lock(&smmu_domain->reserved_mutex);
+
+	smmu_domain->reserved_iova_domain =
+		kzalloc(sizeof(struct iova_domain), GFP_KERNEL);
+	if (!smmu_domain->reserved_iova_domain) {
+		ret = -ENOMEM;
+		goto unlock;
+	}
+
+	init_iova_domain(smmu_domain->reserved_iova_domain,
+			 granule, iova >> order, (iova + size - 1) >> order);
+
+unlock:
+	mutex_unlock(&smmu_domain->reserved_mutex);
+	return ret;
+}
+
+static void arm_smmu_free_reserved_iova_domain(struct iommu_domain *domain)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	struct iova_domain *iovad = smmu_domain->reserved_iova_domain;
+
+	if (!iovad)
+		return;
+
+	mutex_lock(&smmu_domain->reserved_mutex);
+
+	put_iova_domain(iovad);
+	kfree(iovad);
+
+	mutex_unlock(&smmu_domain->reserved_mutex);
+}
+
 static struct iommu_ops arm_smmu_ops = {
-	.capable		= arm_smmu_capable,
-	.domain_alloc		= arm_smmu_domain_alloc,
-	.domain_free		= arm_smmu_domain_free,
-	.attach_dev		= arm_smmu_attach_dev,
-	.detach_dev		= arm_smmu_detach_dev,
-	.map			= arm_smmu_map,
-	.unmap			= arm_smmu_unmap,
-	.map_sg			= default_iommu_map_sg,
-	.iova_to_phys		= arm_smmu_iova_to_phys,
-	.add_device		= arm_smmu_add_device,
-	.remove_device		= arm_smmu_remove_device,
-	.device_group		= arm_smmu_device_group,
-	.domain_get_attr	= arm_smmu_domain_get_attr,
-	.domain_set_attr	= arm_smmu_domain_set_attr,
-	.pgsize_bitmap		= -1UL, /* Restricted during device attach */
+	.capable			= arm_smmu_capable,
+	.domain_alloc			= arm_smmu_domain_alloc,
+	.domain_free			= arm_smmu_domain_free,
+	.attach_dev			= arm_smmu_attach_dev,
+	.detach_dev			= arm_smmu_detach_dev,
+	.map				= arm_smmu_map,
+	.unmap				= arm_smmu_unmap,
+	.map_sg				= default_iommu_map_sg,
+	.iova_to_phys			= arm_smmu_iova_to_phys,
+	.add_device			= arm_smmu_add_device,
+	.remove_device			= arm_smmu_remove_device,
+	.device_group			= arm_smmu_device_group,
+	.domain_get_attr		= arm_smmu_domain_get_attr,
+	.domain_set_attr		= arm_smmu_domain_set_attr,
+	.alloc_reserved_iova_domain	= arm_smmu_alloc_reserved_iova_domain,
+	.free_reserved_iova_domain	= arm_smmu_free_reserved_iova_domain,
+	/* Page size bitmap, restricted during device attach */
+	.pgsize_bitmap			= -1UL,
 };
 
 static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
-- 
1.9.1



From eric.auger at linaro.org  Fri Feb 12 00:13:08 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:08 +0000
Subject: [RFC v3 06/15] iommu/arm-smmu: add a reserved binding RB tree
In-Reply-To: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455264797-2334-7-git-send-email-eric.auger@linaro.org>

we will need to track which host physical addresses are mapped to
reserved IOVA. In that prospect we introduce a new RB tree indexed
by physical address. This RB tree only is used for reserved IOVA
bindings.

It is expected this RB tree will contain very few bindings. Those
generally correspond to single page mapping one MSI frame (GICv2m
frame or ITS GITS_TRANSLATER frame).

Signed-off-by: Eric Auger <eric.auger at linaro.org>

---
---
 drivers/iommu/arm-smmu.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 64 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index f42341d..729a4c6 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -349,10 +349,21 @@ struct arm_smmu_domain {
 	struct mutex			init_mutex; /* Protects smmu pointer */
 	struct iommu_domain		domain;
 	struct iova_domain		*reserved_iova_domain;
-	/* protects reserved domain manipulation */
+	/* rb tree indexed by PA, for reserved bindings only */
+	struct rb_root			reserved_binding_list;
+	/* protects reserved domain and rbtree manipulation */
 	struct mutex			reserved_mutex;
 };
 
+struct arm_smmu_reserved_binding {
+	struct kref		kref;
+	struct rb_node		node;
+	struct arm_smmu_domain	*domain;
+	phys_addr_t		addr;
+	dma_addr_t		iova;
+	size_t			size;
+};
+
 static struct iommu_ops arm_smmu_ops;
 
 static DEFINE_SPINLOCK(arm_smmu_devices_lock);
@@ -400,6 +411,57 @@ static struct device_node *dev_get_dev_node(struct device *dev)
 	return dev->of_node;
 }
 
+/* Reserved binding RB-tree manipulation */
+
+static struct arm_smmu_reserved_binding *find_reserved_binding(
+				    struct arm_smmu_domain *d,
+				    phys_addr_t start, size_t size)
+{
+	struct rb_node *node = d->reserved_binding_list.rb_node;
+
+	while (node) {
+		struct arm_smmu_reserved_binding *binding =
+			rb_entry(node, struct arm_smmu_reserved_binding, node);
+
+		if (start + size <= binding->addr)
+			node = node->rb_left;
+		else if (start >= binding->addr + binding->size)
+			node = node->rb_right;
+		else
+			return binding;
+	}
+
+	return NULL;
+}
+
+static void link_reserved_binding(struct arm_smmu_domain *d,
+				  struct arm_smmu_reserved_binding *new)
+{
+	struct rb_node **link = &d->reserved_binding_list.rb_node;
+	struct rb_node *parent = NULL;
+	struct arm_smmu_reserved_binding *binding;
+
+	while (*link) {
+		parent = *link;
+		binding = rb_entry(parent, struct arm_smmu_reserved_binding,
+				   node);
+
+		if (new->addr + new->size <= binding->addr)
+			link = &(*link)->rb_left;
+		else
+			link = &(*link)->rb_right;
+	}
+
+	rb_link_node(&new->node, parent, link);
+	rb_insert_color(&new->node, &d->reserved_binding_list);
+}
+
+static void unlink_reserved_binding(struct arm_smmu_domain *d,
+				    struct arm_smmu_reserved_binding *old)
+{
+	rb_erase(&old->node, &d->reserved_binding_list);
+}
+
 static struct arm_smmu_master *find_smmu_master(struct arm_smmu_device *smmu,
 						struct device_node *dev_node)
 {
@@ -981,6 +1043,7 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
 	mutex_init(&smmu_domain->init_mutex);
 	mutex_init(&smmu_domain->reserved_mutex);
 	spin_lock_init(&smmu_domain->pgtbl_lock);
+	smmu_domain->reserved_binding_list = RB_ROOT;
 
 	return &smmu_domain->domain;
 }
-- 
1.9.1



From eric.auger at linaro.org  Fri Feb 12 00:13:14 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:14 +0000
Subject: [RFC v3 12/15] msi: export msi_get_domain_info
In-Reply-To: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455264797-2334-13-git-send-email-eric.auger@linaro.org>

We plan to use msi_get_domain_info in VFIO module so let's export it.

Signed-off-by: Eric Auger <eric.auger at linaro.org>

---

v2 -> v3:
- remove static implementation in case CONFIG_PCI_MSI_IRQ_DOMAIN is not set
---
 kernel/irq/msi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index 38e89ce..9b0ba4a 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -400,5 +400,6 @@ struct msi_domain_info *msi_get_domain_info(struct irq_domain *domain)
 {
 	return (struct msi_domain_info *)domain->host_data;
 }
+EXPORT_SYMBOL_GPL(msi_get_domain_info);
 
 #endif /* CONFIG_GENERIC_MSI_IRQ_DOMAIN */
-- 
1.9.1



From eric.auger at linaro.org  Fri Feb 12 00:13:16 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:16 +0000
Subject: [RFC v3 14/15] iommu/arm-smmu: do not advertise IOMMU_CAP_INTR_REMAP
In-Reply-To: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455264797-2334-15-git-send-email-eric.auger@linaro.org>

Do not advertise IOMMU_CAP_INTR_REMAP for arm-smmu. Indeed the
irq_remapping capability is abstracted on irqchip side for ARM as
opposed to Intel IOMMU featuring IRQ remapping HW.

So to check IRQ remmapping capability, the msi domain needs to be
checked instead.

Signed-off-by: Eric Auger <eric.auger at linaro.org>
---
 drivers/iommu/arm-smmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index ae8a97d..9a83285 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1354,7 +1354,7 @@ static bool arm_smmu_capable(enum iommu_cap cap)
 		 */
 		return true;
 	case IOMMU_CAP_INTR_REMAP:
-		return true; /* MSIs are just memory writes */
+		return false; /* MSIs are just memory writes */
 	case IOMMU_CAP_NOEXEC:
 		return true;
 	default:
-- 
1.9.1



From eric.auger at linaro.org  Fri Feb 12 00:13:09 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:09 +0000
Subject: [RFC v3 07/15] iommu: iommu_get/put_single_reserved
In-Reply-To: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455264797-2334-8-git-send-email-eric.auger@linaro.org>

This patch introduces iommu_get/put_single_reserved.

iommu_get_single_reserved allows to allocate a new reserved iova page
and map it onto the physical page that contains a given physical address.
It returns the iova that is mapped onto the provided physical address.
Hence the physical address passed in argument does not need to be aligned.

In case a mapping already exists between both pages, the IOVA mapped
to the PA is directly returned.

Each time an iova is successfully returned a binding ref count is
incremented.

iommu_put_single_reserved decrements the ref count and when this latter
is null, the mapping is destroyed and the iova is released.

Signed-off-by: Eric Auger <eric.auger at linaro.org>
Signed-off-by: Ankit Jindal <ajindal at apm.com>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar at linaro.org>
Signed-off-by: Bharat Bhushan <Bharat.Bhushan at freescale.com>

---

v2 -> v3:
- remove static implementation of iommu_get_single_reserved &
  iommu_put_single_reserved when CONFIG_IOMMU_API is not set

v1 -> v2:
- previously a VFIO API, named vfio_alloc_map/unmap_free_reserved_iova
---
 drivers/iommu/iommu.c | 21 +++++++++++++++++++++
 include/linux/iommu.h | 20 ++++++++++++++++++++
 2 files changed, 41 insertions(+)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index a994f34..14ebde1 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1415,6 +1415,27 @@ size_t iommu_unmap(struct iommu_domain *domain, unsigned long iova, size_t size)
 	return unmapped;
 }
 EXPORT_SYMBOL_GPL(iommu_unmap);
+int iommu_get_single_reserved(struct iommu_domain *domain,
+			      phys_addr_t addr, int prot,
+			      dma_addr_t *iova)
+{
+	if (!domain->ops->get_single_reserved)
+		return  -ENODEV;
+
+	return domain->ops->get_single_reserved(domain, addr, prot, iova);
+
+}
+EXPORT_SYMBOL_GPL(iommu_get_single_reserved);
+
+void iommu_put_single_reserved(struct iommu_domain *domain,
+			       dma_addr_t iova)
+{
+	if (!domain->ops->put_single_reserved)
+		return;
+
+	domain->ops->put_single_reserved(domain, iova);
+}
+EXPORT_SYMBOL_GPL(iommu_put_single_reserved);
 
 size_t default_iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
 			 struct scatterlist *sg, unsigned int nents, int prot)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 2d1f155..1e00c1b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -201,6 +201,21 @@ struct iommu_ops {
 					  unsigned long order);
 	/* frees the reserved iova domain */
 	void (*free_reserved_iova_domain)(struct iommu_domain *domain);
+	/**
+	 * allocate a reserved iova page and bind it onto the page that
+	 * contains a physical address (@addr), returns the @iova bound to
+	 * @addr. In case the 2 pages already are bound simply return @iova
+	 * and increment a ref count.
+	 */
+	int (*get_single_reserved)(struct iommu_domain *domain,
+					 phys_addr_t addr, int prot,
+					 dma_addr_t *iova);
+	/**
+	 * decrement a ref count of the iova page. If null, unmap the iova page
+	 * and release the iova
+	 */
+	void (*put_single_reserved)(struct iommu_domain *domain,
+					   dma_addr_t iova);
 
 #ifdef CONFIG_OF_IOMMU
 	int (*of_xlate)(struct device *dev, struct of_phandle_args *args);
@@ -276,6 +291,11 @@ extern int iommu_alloc_reserved_iova_domain(struct iommu_domain *domain,
 					    dma_addr_t iova, size_t size,
 					    unsigned long order);
 extern void iommu_free_reserved_iova_domain(struct iommu_domain *domain);
+extern int iommu_get_single_reserved(struct iommu_domain *domain,
+				     phys_addr_t paddr, int prot,
+				     dma_addr_t *iova);
+extern void iommu_put_single_reserved(struct iommu_domain *domain,
+				      dma_addr_t iova);
 struct device *iommu_device_create(struct device *parent, void *drvdata,
 				   const struct attribute_group **groups,
 				   const char *fmt, ...) __printf(4, 5);
-- 
1.9.1



From eric.auger at linaro.org  Fri Feb 12 00:13:10 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:10 +0000
Subject: [RFC v3 08/15] iommu/arm-smmu: implement iommu_get/put_single_reserved
In-Reply-To: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455264797-2334-9-git-send-email-eric.auger@linaro.org>

Implement the iommu_get/put_single_reserved API in arm-smmu.

In order to track which physical address is already mapped we
use the RB tree indexed by PA.

Signed-off-by: Eric Auger <eric.auger at linaro.org>

---

v1 -> v2:
- previously in vfio_iommu_type1.c
---
 drivers/iommu/arm-smmu.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 114 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 729a4c6..9961bfd 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1563,6 +1563,118 @@ static void arm_smmu_free_reserved_iova_domain(struct iommu_domain *domain)
 	mutex_unlock(&smmu_domain->reserved_mutex);
 }
 
+static int arm_smmu_get_single_reserved(struct iommu_domain *domain,
+					phys_addr_t addr, int prot,
+					dma_addr_t *iova)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	unsigned long order = __ffs(domain->ops->pgsize_bitmap);
+	size_t page_size = 1 << order;
+	phys_addr_t mask = page_size - 1;
+	phys_addr_t aligned_addr = addr & ~mask;
+	phys_addr_t offset  = addr - aligned_addr;
+	struct arm_smmu_reserved_binding *b;
+	struct iova *p_iova;
+	struct iova_domain *iovad = smmu_domain->reserved_iova_domain;
+	int ret;
+
+	if (!iovad)
+		return -EINVAL;
+
+	mutex_lock(&smmu_domain->reserved_mutex);
+
+	b = find_reserved_binding(smmu_domain, aligned_addr, page_size);
+	if (b) {
+		*iova = b->iova + offset;
+		kref_get(&b->kref);
+		ret = 0;
+		goto unlock;
+	}
+
+	/* there is no existing reserved iova for this pa */
+	p_iova = alloc_iova(iovad, 1, iovad->dma_32bit_pfn, true);
+	if (!p_iova) {
+		ret = -ENOMEM;
+		goto unlock;
+	}
+	*iova = p_iova->pfn_lo << order;
+
+	b = kzalloc(sizeof(*b), GFP_KERNEL);
+	if (!b) {
+		ret = -ENOMEM;
+		goto free_iova_unlock;
+	}
+
+	ret = arm_smmu_map(domain, *iova, aligned_addr, page_size, prot);
+	if (ret)
+		goto free_binding_iova_unlock;
+
+	kref_init(&b->kref);
+	kref_get(&b->kref);
+	b->domain = smmu_domain;
+	b->addr = aligned_addr;
+	b->iova = *iova;
+	b->size = page_size;
+
+	link_reserved_binding(smmu_domain, b);
+
+	*iova += offset;
+	goto unlock;
+
+free_binding_iova_unlock:
+	kfree(b);
+free_iova_unlock:
+	free_iova(smmu_domain->reserved_iova_domain, *iova >> order);
+unlock:
+	mutex_unlock(&smmu_domain->reserved_mutex);
+	return ret;
+}
+
+/* called with reserved_mutex locked */
+static void reserved_binding_release(struct kref *kref)
+{
+	struct arm_smmu_reserved_binding *b =
+		container_of(kref, struct arm_smmu_reserved_binding, kref);
+	struct arm_smmu_domain *smmu_domain = b->domain;
+	struct iommu_domain *d = &smmu_domain->domain;
+	unsigned long order = __ffs(b->size);
+
+
+	arm_smmu_unmap(d, b->iova, b->size);
+	free_iova(smmu_domain->reserved_iova_domain, b->iova >> order);
+	unlink_reserved_binding(smmu_domain, b);
+	kfree(b);
+}
+
+static void arm_smmu_put_single_reserved(struct iommu_domain *domain,
+					 dma_addr_t iova)
+{
+	unsigned long order;
+	phys_addr_t aligned_addr;
+	dma_addr_t aligned_iova, page_size, mask, offset;
+	struct arm_smmu_reserved_binding *b;
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+
+	order = __ffs(domain->ops->pgsize_bitmap);
+	page_size = (uint64_t)1 << order;
+	mask = page_size - 1;
+
+	aligned_iova = iova & ~mask;
+	offset = iova - aligned_iova;
+
+	aligned_addr = iommu_iova_to_phys(domain, aligned_iova);
+
+	mutex_lock(&smmu_domain->reserved_mutex);
+
+	b = find_reserved_binding(smmu_domain, aligned_addr, page_size);
+	if (!b)
+		goto unlock;
+	kref_put(&b->kref, reserved_binding_release);
+
+unlock:
+	mutex_unlock(&smmu_domain->reserved_mutex);
+}
+
 static struct iommu_ops arm_smmu_ops = {
 	.capable			= arm_smmu_capable,
 	.domain_alloc			= arm_smmu_domain_alloc,
@@ -1580,6 +1692,8 @@ static struct iommu_ops arm_smmu_ops = {
 	.domain_set_attr		= arm_smmu_domain_set_attr,
 	.alloc_reserved_iova_domain	= arm_smmu_alloc_reserved_iova_domain,
 	.free_reserved_iova_domain	= arm_smmu_free_reserved_iova_domain,
+	.get_single_reserved		= arm_smmu_get_single_reserved,
+	.put_single_reserved		= arm_smmu_put_single_reserved,
 	/* Page size bitmap, restricted during device attach */
 	.pgsize_bitmap			= -1UL,
 };
-- 
1.9.1



From eric.auger at linaro.org  Fri Feb 12 00:13:11 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:11 +0000
Subject: [RFC v3 09/15] iommu/arm-smmu: relinquish reserved resources on
 domain deletion
In-Reply-To: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455264797-2334-10-git-send-email-eric.auger@linaro.org>

arm_smmu_unmap_reserved releases all reserved binding resources:
destroy all bindings, free iova, free iova_domain. This happens
on domain deletion.

Signed-off-by: Eric Auger <eric.auger at linaro.org>
---
 drivers/iommu/arm-smmu.c | 34 +++++++++++++++++++++++++++++-----
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 9961bfd..ae8a97d 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -363,6 +363,7 @@ struct arm_smmu_reserved_binding {
 	dma_addr_t		iova;
 	size_t			size;
 };
+static void arm_smmu_unmap_reserved(struct iommu_domain *domain);
 
 static struct iommu_ops arm_smmu_ops;
 
@@ -1057,6 +1058,7 @@ static void arm_smmu_domain_free(struct iommu_domain *domain)
 	 * already been detached.
 	 */
 	arm_smmu_destroy_domain_context(domain);
+	arm_smmu_unmap_reserved(domain);
 	kfree(smmu_domain);
 }
 
@@ -1547,19 +1549,23 @@ unlock:
 	return ret;
 }
 
-static void arm_smmu_free_reserved_iova_domain(struct iommu_domain *domain)
+static void __arm_smmu_free_reserved_iova_domain(struct arm_smmu_domain *sd)
 {
-	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
-	struct iova_domain *iovad = smmu_domain->reserved_iova_domain;
+	struct iova_domain *iovad = sd->reserved_iova_domain;
 
 	if (!iovad)
 		return;
 
-	mutex_lock(&smmu_domain->reserved_mutex);
-
 	put_iova_domain(iovad);
 	kfree(iovad);
+}
 
+static void arm_smmu_free_reserved_iova_domain(struct iommu_domain *domain)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+
+	mutex_lock(&smmu_domain->reserved_mutex);
+	__arm_smmu_free_reserved_iova_domain(smmu_domain);
 	mutex_unlock(&smmu_domain->reserved_mutex);
 }
 
@@ -1675,6 +1681,24 @@ unlock:
 	mutex_unlock(&smmu_domain->reserved_mutex);
 }
 
+static void arm_smmu_unmap_reserved(struct iommu_domain *domain)
+{
+	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+	struct rb_node *node;
+
+	mutex_lock(&smmu_domain->reserved_mutex);
+	while ((node = rb_first(&smmu_domain->reserved_binding_list))) {
+		struct arm_smmu_reserved_binding *b =
+			rb_entry(node, struct arm_smmu_reserved_binding, node);
+
+		while (!kref_put(&b->kref, reserved_binding_release))
+			;
+	}
+	smmu_domain->reserved_binding_list = RB_ROOT;
+	__arm_smmu_free_reserved_iova_domain(smmu_domain);
+	mutex_unlock(&smmu_domain->reserved_mutex);
+}
+
 static struct iommu_ops arm_smmu_ops = {
 	.capable			= arm_smmu_capable,
 	.domain_alloc			= arm_smmu_domain_alloc,
-- 
1.9.1



From eric.auger at linaro.org  Fri Feb 12 00:13:13 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:13 +0000
Subject: [RFC v3 11/15] msi: Add a new MSI_FLAG_IRQ_REMAPPING flag
In-Reply-To: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455264797-2334-12-git-send-email-eric.auger@linaro.org>

Let's introduce a new msi_domain_info flag value, MSI_FLAG_IRQ_REMAPPING
meant to tell the domain supports IRQ REMAPPING, also known as Interrupt
Translation Service. On Intel HW this capability is abstracted on IOMMU
side while on ARM it is abstracted on MSI controller side.

GICv3 ITS HW is the first HW advertising that feature.

Signed-off-by: Eric Auger <eric.auger at linaro.org>
---
 drivers/irqchip/irq-gic-v3-its-pci-msi.c | 3 ++-
 include/linux/msi.h                      | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index aee60ed..8223765 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -96,7 +96,8 @@ static struct msi_domain_ops its_pci_msi_ops = {
 
 static struct msi_domain_info its_pci_msi_domain_info = {
 	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
-		   MSI_FLAG_MULTI_PCI_MSI | MSI_FLAG_PCI_MSIX),
+		   MSI_FLAG_MULTI_PCI_MSI | MSI_FLAG_PCI_MSIX |
+		   MSI_FLAG_IRQ_REMAPPING),
 	.ops	= &its_pci_msi_ops,
 	.chip	= &its_msi_irq_chip,
 };
diff --git a/include/linux/msi.h b/include/linux/msi.h
index a2a0068..03eda72 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -261,6 +261,8 @@ enum {
 	MSI_FLAG_MULTI_PCI_MSI		= (1 << 3),
 	/* Support PCI MSIX interrupts */
 	MSI_FLAG_PCI_MSIX		= (1 << 4),
+	/* Support MSI IRQ remapping service */
+	MSI_FLAG_IRQ_REMAPPING		= (1 << 5),
 };
 
 int msi_domain_set_affinity(struct irq_data *data, const struct cpumask *mask,
-- 
1.9.1



From eric.auger at linaro.org  Fri Feb 12 00:13:12 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:12 +0000
Subject: [RFC v3 10/15] vfio: allow the user to register reserved iova range
 for MSI mapping
In-Reply-To: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455264797-2334-11-git-send-email-eric.auger@linaro.org>

The user is allowed to register a reserved IOVA range by using the
DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA.
It provides the base address and the size. This region is stored in the
vfio_dma rb tree. At that point the iova range is not mapped to any target
address yet. The host kernel will use those iova when needed, typically
when the VFIO-PCI device allocates its MSI's.

This patch also handles the destruction of the reserved binding RB-tree and
domain's iova_domains.

Signed-off-by: Eric Auger <eric.auger at linaro.org>
Signed-off-by: Bharat Bhushan <Bharat.Bhushan at freescale.com>

---

v1 -> v2:
- set returned value according to alloc_reserved_iova_domain result
- free the iova domains in case any error occurs

RFC v1 -> v1:
- takes into account Alex comments, based on
  [RFC PATCH 1/6] vfio: Add interface for add/del reserved iova region:
- use the existing dma map/unmap ioctl interface with a flag to register
  a reserved IOVA range. A single reserved iova region is allowed.
---
 drivers/vfio/vfio_iommu_type1.c | 75 ++++++++++++++++++++++++++++++++++++++++-
 include/uapi/linux/vfio.h       |  9 +++++
 2 files changed, 83 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index b9326c9..c5d3b48 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -673,6 +673,75 @@ static int vfio_dma_do_map(struct vfio_iommu *iommu,
 	return ret;
 }
 
+static int vfio_register_reserved_iova_range(struct vfio_iommu *iommu,
+			   struct vfio_iommu_type1_dma_map *map)
+{
+	dma_addr_t iova = map->iova;
+	size_t size = map->size;
+	uint64_t mask;
+	struct vfio_dma *dma;
+	int ret = 0;
+	struct vfio_domain *d;
+	unsigned long order;
+
+	/* Verify that none of our __u64 fields overflow */
+	if (map->size != size || map->iova != iova)
+		return -EINVAL;
+
+	order =  __ffs(vfio_pgsize_bitmap(iommu));
+	mask = ((uint64_t)1 << order) - 1;
+
+	WARN_ON(mask & PAGE_MASK);
+
+	/* we currently only support MSI_RESERVED_IOVA */
+	if (!(map->flags & VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA))
+		return -EINVAL;
+
+	if (!size || (size | iova) & mask)
+		return -EINVAL;
+
+	/* Don't allow IOVA address wrap */
+	if (iova + size - 1 < iova)
+		return -EINVAL;
+
+	mutex_lock(&iommu->lock);
+
+	/* check if the iova domain has not been instantiated already*/
+	d = list_first_entry(&iommu->domain_list,
+				  struct vfio_domain, next);
+
+	if (vfio_find_dma(iommu, iova, size)) {
+		ret =  -EEXIST;
+		goto out;
+	}
+
+	dma = kzalloc(sizeof(*dma), GFP_KERNEL);
+	if (!dma) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	dma->iova = iova;
+	dma->size = size;
+	dma->type = VFIO_IOVA_RESERVED;
+
+	list_for_each_entry(d, &iommu->domain_list, next)
+		ret |= iommu_alloc_reserved_iova_domain(d->domain, iova,
+							size, order);
+
+	if (ret) {
+		list_for_each_entry(d, &iommu->domain_list, next)
+			iommu_free_reserved_iova_domain(d->domain);
+		goto out;
+	}
+
+	vfio_link_dma(iommu, dma);
+
+out:
+	mutex_unlock(&iommu->lock);
+	return ret;
+}
+
 static int vfio_bus_type(struct device *dev, void *data)
 {
 	struct bus_type **bus = data;
@@ -1045,7 +1114,8 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
 	} else if (cmd == VFIO_IOMMU_MAP_DMA) {
 		struct vfio_iommu_type1_dma_map map;
 		uint32_t mask = VFIO_DMA_MAP_FLAG_READ |
-				VFIO_DMA_MAP_FLAG_WRITE;
+				VFIO_DMA_MAP_FLAG_WRITE |
+				VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA;
 
 		minsz = offsetofend(struct vfio_iommu_type1_dma_map, size);
 
@@ -1055,6 +1125,9 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
 		if (map.argsz < minsz || map.flags & ~mask)
 			return -EINVAL;
 
+		if (map.flags & VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA)
+			return vfio_register_reserved_iova_range(iommu, &map);
+
 		return vfio_dma_do_map(iommu, &map);
 
 	} else if (cmd == VFIO_IOMMU_UNMAP_DMA) {
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 43e183b..982e326 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -411,12 +411,21 @@ struct vfio_iommu_type1_info {
  *
  * Map process virtual addresses to IO virtual addresses using the
  * provided struct vfio_dma_map. Caller sets argsz. READ &/ WRITE required.
+ *
+ * In case MSI_RESERVED_IOVA is set, the API only aims at registering an IOVA
+ * region which will be used on some platforms to map the host MSI frame.
+ * in that specific case, vaddr and prot are ignored. The requirement for
+ * provisioning such IOVA range can be checked by calling VFIO_IOMMU_GET_INFO
+ * with the VFIO_IOMMU_INFO_REQUIRE_MSI_MAP attribute. A single
+ * MSI_RESERVED_IOVA region can be registered
  */
 struct vfio_iommu_type1_dma_map {
 	__u32	argsz;
 	__u32	flags;
 #define VFIO_DMA_MAP_FLAG_READ (1 << 0)		/* readable from device */
 #define VFIO_DMA_MAP_FLAG_WRITE (1 << 1)	/* writable from device */
+/* reserved iova for MSI vectors*/
+#define VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA (1 << 2)
 	__u64	vaddr;				/* Process virtual address */
 	__u64	iova;				/* IO virtual address */
 	__u64	size;				/* Size of mapping (bytes) */
-- 
1.9.1



From eric.auger at linaro.org  Fri Feb 12 00:13:15 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:15 +0000
Subject: [RFC v3 13/15] vfio/type1: also check IRQ remapping capability at msi
 domain
In-Reply-To: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455264797-2334-14-git-send-email-eric.auger@linaro.org>

On x86 IRQ remapping is abstracted by the IOMMU. On ARM this is abstracted
by the msi controller. vfio_msi_parent_irq_remapping_capable allows to
check whether interrupts are "safe" for a given device. There are if the device
does not use MSI or if the device uses MSI and the msi-parent controller
supports IRQ remapping.

Then we check at group level if all devices have safe interrupts: if not
only allow the group to be attached if allow_unsafe_interrupts is set.

At this point ARM sMMU still advertises IOMMU_CAP_INTR_REMAP. This is
changed in next patch.

Signed-off-by: Eric Auger <eric.auger at linaro.org>

---

v2 -> v3:
- protect vfio_msi_parent_irq_remapping_capable with
  CONFIG_GENERIC_MSI_IRQ_DOMAIN
---
 drivers/vfio/vfio_iommu_type1.c | 39 +++++++++++++++++++++++++++++++++++++--
 1 file changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index c5d3b48..3afb815 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -36,6 +36,8 @@
 #include <linux/uaccess.h>
 #include <linux/vfio.h>
 #include <linux/workqueue.h>
+#include <linux/irqdomain.h>
+#include <linux/msi.h>
 
 #define DRIVER_VERSION  "0.2"
 #define DRIVER_AUTHOR   "Alex Williamson <alex.williamson at redhat.com>"
@@ -754,6 +756,32 @@ static int vfio_bus_type(struct device *dev, void *data)
 	return 0;
 }
 
+/**
+ * vfio_msi_parent_irq_remapping_capable: returns whether the device msi-parent
+ * controller supports IRQ remapping, aka interrupt translation
+ *
+ * @dev: device handle
+ * @data: unused
+ * returns 0 if irq remapping is supported or -1 if not supported.
+ */
+static int vfio_msi_parent_irq_remapping_capable(struct device *dev, void *data)
+{
+#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
+	struct irq_domain *domain;
+	struct msi_domain_info *info;
+
+	domain = dev_get_msi_domain(dev);
+	if (!domain)
+		return 0;
+
+	info = msi_get_domain_info(domain);
+
+	if (!(info->flags & MSI_FLAG_IRQ_REMAPPING))
+		return -1;
+#endif
+	return 0;
+}
+
 static int vfio_iommu_replay(struct vfio_iommu *iommu,
 			     struct vfio_domain *domain)
 {
@@ -848,7 +876,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
 	struct vfio_group *group, *g;
 	struct vfio_domain *domain, *d;
 	struct bus_type *bus = NULL;
-	int ret;
+	int ret, irq_remapping;
 
 	mutex_lock(&iommu->lock);
 
@@ -871,6 +899,13 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
 
 	group->iommu_group = iommu_group;
 
+	/*
+	 * Determine if all the devices of the group has an MSI-parent that
+	 * supports irq remapping
+	 */
+	irq_remapping = !iommu_group_for_each_dev(iommu_group, &bus,
+				       vfio_msi_parent_irq_remapping_capable);
+
 	/* Determine bus_type in order to allocate a domain */
 	ret = iommu_group_for_each_dev(iommu_group, &bus, vfio_bus_type);
 	if (ret)
@@ -899,7 +934,7 @@ static int vfio_iommu_type1_attach_group(void *iommu_data,
 	list_add(&group->next, &domain->group_list);
 
 	if (!allow_unsafe_interrupts &&
-	    !iommu_capable(bus, IOMMU_CAP_INTR_REMAP)) {
+	    (!iommu_capable(bus, IOMMU_CAP_INTR_REMAP) && !irq_remapping)) {
 		pr_warn("%s: No interrupt remapping support.  Use the module param \"allow_unsafe_interrupts\" to enable VFIO IOMMU support on this platform\n",
 		       __func__);
 		ret = -EPERM;
-- 
1.9.1



From eric.auger at linaro.org  Fri Feb 12 00:13:17 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Fri, 12 Feb 2016 08:13:17 +0000
Subject: [RFC v3 15/15] irqchip/gicv2m/v3-its-pci-msi: IOMMU map the MSI frame
 when needed
In-Reply-To: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
Message-ID: <1455264797-2334-16-git-send-email-eric.auger@linaro.org>

In case the msi_desc references a device attached to an iommu
domain, the msi address needs to be mapped in the IOMMU. Else any
MSI write transaction will cause a fault.

gic_set_msi_addr detects that case and allocates an iova bound
to the physical address page comprising the MSI frame. This iova
then is used as the msi_msg address. Unset operation decrements the
reference on the binding.

The functions are called in the irq_write_msi_msg ops implementation.
At that time we can recognize whether the msi is setup or teared down
looking at the msi_msg content. Indeed msi_domain_deactivate zeroes all
the fields.

Signed-off-by: Eric Auger <eric.auger at linaro.org>

---

v2 -> v3:
- protect iova/addr manipulation with CONFIG_ARCH_DMA_ADDR_T_64BIT and
  CONFIG_PHYS_ADDR_T_64BIT
- only expose gic_pci_msi_domain_write_msg in case CONFIG_IOMMU_API &
  CONFIG_PCI_MSI_IRQ_DOMAIN are set.
- gic_set/unset_msi_addr duly become static
---
 drivers/irqchip/irq-gic-common.c         | 69 ++++++++++++++++++++++++++++++++
 drivers/irqchip/irq-gic-common.h         |  5 +++
 drivers/irqchip/irq-gic-v2m.c            |  7 +++-
 drivers/irqchip/irq-gic-v3-its-pci-msi.c |  5 +++
 4 files changed, 85 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
index f174ce0..46cd06c 100644
--- a/drivers/irqchip/irq-gic-common.c
+++ b/drivers/irqchip/irq-gic-common.c
@@ -18,6 +18,8 @@
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/irqchip/arm-gic.h>
+#include <linux/iommu.h>
+#include <linux/msi.h>
 
 #include "irq-gic-common.h"
 
@@ -121,3 +123,70 @@ void gic_cpu_config(void __iomem *base, void (*sync_access)(void))
 	if (sync_access)
 		sync_access();
 }
+
+#if defined(CONFIG_IOMMU_API) && defined(CONFIG_PCI_MSI_IRQ_DOMAIN)
+static int gic_set_msi_addr(struct irq_data *data, struct msi_msg *msg)
+{
+	struct msi_desc *desc = irq_data_get_msi_desc(data);
+	struct device *dev = msi_desc_to_dev(desc);
+	struct iommu_domain *d;
+	phys_addr_t addr;
+	dma_addr_t iova;
+	int ret;
+
+	d = iommu_get_domain_for_dev(dev);
+	if (!d)
+		return 0;
+#ifdef CONFIG_PHYS_ADDR_T_64BIT
+	addr = ((phys_addr_t)(msg->address_hi) << 32) | msg->address_lo;
+#else
+	addr = msg->address_lo;
+#endif
+
+	ret = iommu_get_single_reserved(d, addr, IOMMU_WRITE, &iova);
+
+	if (!ret) {
+		msg->address_lo = lower_32_bits(iova);
+		msg->address_hi = upper_32_bits(iova);
+	}
+	return ret;
+}
+
+
+static void gic_unset_msi_addr(struct irq_data *data)
+{
+	struct msi_desc *desc = irq_data_get_msi_desc(data);
+	struct device *dev;
+	struct iommu_domain *d;
+	dma_addr_t iova;
+
+#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
+	iova = ((dma_addr_t)(desc->msg.address_hi) << 32) |
+		desc->msg.address_lo;
+#else
+	iova = desc->msg.address_lo;
+#endif
+
+	dev = msi_desc_to_dev(desc);
+	if (!dev)
+		return;
+
+	d = iommu_get_domain_for_dev(dev);
+	if (!d)
+		return;
+
+	iommu_put_single_reserved(d, iova);
+}
+
+void gic_pci_msi_domain_write_msg(struct irq_data *irq_data,
+				  struct msi_msg *msg)
+{
+	if (!msg->address_hi && !msg->address_lo && !msg->data)
+		gic_unset_msi_addr(irq_data); /* deactivate */
+	else
+		gic_set_msi_addr(irq_data, msg); /* activate, set_affinity */
+
+	pci_msi_domain_write_msg(irq_data, msg);
+}
+#endif
+
diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
index fff697d..98681fd 100644
--- a/drivers/irqchip/irq-gic-common.h
+++ b/drivers/irqchip/irq-gic-common.h
@@ -35,4 +35,9 @@ void gic_cpu_config(void __iomem *base, void (*sync_access)(void));
 void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
 		void *data);
 
+#if defined(CONFIG_PCI_MSI_IRQ_DOMAIN) && defined(CONFIG_IOMMU_API)
+void gic_pci_msi_domain_write_msg(struct irq_data *irq_data,
+				  struct msi_msg *msg);
+#endif
+
 #endif /* _IRQ_GIC_COMMON_H */
diff --git a/drivers/irqchip/irq-gic-v2m.c b/drivers/irqchip/irq-gic-v2m.c
index c779f83..692d809 100644
--- a/drivers/irqchip/irq-gic-v2m.c
+++ b/drivers/irqchip/irq-gic-v2m.c
@@ -24,6 +24,7 @@
 #include <linux/of_pci.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include "irq-gic-common.h"
 
 /*
 * MSI_TYPER:
@@ -83,7 +84,11 @@ static struct irq_chip gicv2m_msi_irq_chip = {
 	.irq_mask		= gicv2m_mask_msi_irq,
 	.irq_unmask		= gicv2m_unmask_msi_irq,
 	.irq_eoi		= irq_chip_eoi_parent,
-	.irq_write_msi_msg	= pci_msi_domain_write_msg,
+#ifdef CONFIG_IOMMU_API
+	.irq_write_msi_msg	= gic_pci_msi_domain_write_msg,
+#else
+	.irq_write_msi_msg      = pci_msi_domain_write_msg,
+#endif
 };
 
 static struct msi_domain_info gicv2m_msi_domain_info = {
diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index 8223765..690504e 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -19,6 +19,7 @@
 #include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/of_pci.h>
+#include "irq-gic-common.h"
 
 static void its_mask_msi_irq(struct irq_data *d)
 {
@@ -37,7 +38,11 @@ static struct irq_chip its_msi_irq_chip = {
 	.irq_unmask		= its_unmask_msi_irq,
 	.irq_mask		= its_mask_msi_irq,
 	.irq_eoi		= irq_chip_eoi_parent,
+#ifdef CONFIG_IOMMU_API
+	.irq_write_msi_msg	= gic_pci_msi_domain_write_msg,
+#else
 	.irq_write_msi_msg	= pci_msi_domain_write_msg,
+#endif
 };
 
 struct its_pci_alias {
-- 
1.9.1



From marc.zyngier at arm.com  Fri Feb 12 00:32:12 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Feb 2016 08:32:12 +0000
Subject: [PATCH] of/irq: Fix msi-map calculation for nonzero rid-base
In-Reply-To: <CAL_JsqLScMdfUAtMPDGWphc_PZp4K-c0MfjRZh9G7=A9pLZu9Q@mail.gmail.com>
References: <9f6845195d03b0e0b0d187bb510fbf7bd497e836.1455015344.git.robin.murphy@arm.com>
 <56BC6ABA.5020605@arm.com>
 <CAL_JsqLScMdfUAtMPDGWphc_PZp4K-c0MfjRZh9G7=A9pLZu9Q@mail.gmail.com>
Message-ID: <56BD988C.6090909@arm.com>

On 11/02/16 23:15, Rob Herring wrote:
> On Thu, Feb 11, 2016 at 5:04 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> On 09/02/16 11:04, Robin Murphy wrote:
>>> The existing msi-map code is fine for shifting the entire RID space
>>> upwards, but attempting finer-grained remapping reveals a bug. It turns
>>> out that we are mistakenly treating the msi-base part as an offset, not
>>> as a new base to remap onto, so things get squiffy when rid-base is
>>> nonzero. Fix this, and at the same time add a sanity check against
>>> having msi-map-mask clash with a nonzero rid-base, as that's another
>>> thing one can easily get wrong.
>>>
>>> CC: <stable at vger.kernel.org>
>>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>>
>> Rob, Frank,
>>
>> Are you willing to take this one through the OF tree? Or should we route
>> it through the IRQ tree? It'd be good if it make it into 4.5.
> 
> Applied for 4.5. ATM, I don't have anything else to send to Linus.
> I'll give it a week or so if this is not urgent. Or send me a bunch of
> DT binding fixes and you can get it in sooner. ;)

Doesn't really qualify as "a bunch", but how about this one:

https://patchwork.ozlabs.org/patch/578268/

I had it in mind for 4.6, but the sooner the better!

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From tn at semihalf.com  Fri Feb 12 00:56:54 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Fri, 12 Feb 2016 09:56:54 +0100
Subject: [PATCH V4 15/23] acpi, mcfg: Implement two calls that might be
 used to inject/remove MCFG region.
In-Reply-To: <20160210140602.GB25060@red-moon>
References: <1454606941-9523-1-git-send-email-tn@semihalf.com>
 <1454606941-9523-16-git-send-email-tn@semihalf.com>
 <20160210140602.GB25060@red-moon>
Message-ID: <56BD9E56.5070805@semihalf.com>

On 10.02.2016 15:06, Lorenzo Pieralisi wrote:
> On Thu, Feb 04, 2016 at 06:28:53PM +0100, Tomasz Nowicki wrote:
>> >Lets abstract two calls which allow to inject and remove MCFG regions
>> >which may come from DSDT table. These calls will be used for x86 and ARM64
>> >PCI host bridge driver in the later patches.
>> >
>> >Signed-off-by: Tomasz Nowicki<tn at semihalf.com>
>> >Tested-by: Duc Dang<dhdang at apm.com>
>> >Tested-by: Dongdong Liu<liudongdong3 at huawei.com>
>> >Tested-by: Hanjun Guo<hanjun.guo at linaro.org>
>> >Tested-by: Graeme Gregory<graeme.gregory at linaro.org>
>> >Tested-by: Sinan Kaya<okaya at codeaurora.org>
>> >---
>> >  drivers/acpi/mcfg.c      | 38 ++++++++++++++++++++++++++++++++++++++
>> >  include/linux/pci-acpi.h |  9 +++++++++
>> >  2 files changed, 47 insertions(+)
>> >
>> >diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
>> >index 3e1e7be..dca4c4e 100644
>> >--- a/drivers/acpi/mcfg.c
>> >+++ b/drivers/acpi/mcfg.c
>> >@@ -10,6 +10,7 @@
>> >  #include <linux/acpi.h>
>> >  #include <linux/ecam.h>
>> >  #include <linux/pci.h>
>> >+#include <linux/pci-acpi.h>
>> >
>> >  #define	PREFIX	"MCFG: "
>> >
>> >@@ -77,6 +78,43 @@ int __init acpi_parse_mcfg(struct acpi_table_header *header)
>> >  	return 0;
>> >  }
>> >
>> >+int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci)
>> >+{
>> >+	struct pci_mmcfg_region *cfg;
>> >+	struct acpi_pci_root *root;
>> >+	int seg, start, end, err;
>> >+
>> >+	root = ci->root;
>> >+	seg = root->segment;
>> >+	start = root->secondary.start;
>> >+	end = root->secondary.end;
>> >+
>> >+	cfg = pci_mmconfig_lookup(seg, start);
>> >+	if (cfg)
>> >+		return 0;
>> >+
>> >+	cfg = pci_mmconfig_alloc(seg, start, end, root->mcfg_addr);
>> >+	if (!cfg)
>> >+		return -ENOMEM;
>> >+
>> >+	err = pci_mmconfig_inject(cfg);
>> >+	return err;
> When you integrate Jayachandran's patch this whole function will
> become a pci_mmconfig_insert() and that's where hot_added should
> be set.
>
>> >+}
>> >+
>> >+void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci)
>> >+{
>> >+	struct acpi_pci_root *root = ci->root;
>> >+	struct pci_mmcfg_region *cfg;
>> >+
>> >+	cfg = pci_mmconfig_lookup(root->segment, root->secondary.start);
>> >+	if (!cfg)
>> >+		return;
>> >+
>> >+	if (cfg->hot_added)
> Move the hot_added check in pci_mmconfig_delete() (that does the look
> up again), we do not want to carry out pci_mmconfig_lookup only to
> check that flag here (and we miss rcu locking for the look-up BTW).

Makes sense to me, I will follow your suggestion.

Thanks,
Tomasz


From lee.jones at linaro.org  Fri Feb 12 01:00:33 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 12 Feb 2016 09:00:33 +0000
Subject: [GIT PULL] Immutable branch between MFD and Regulator
In-Reply-To: <1455242567-17880-1-git-send-email-wens@csie.org>
References: <1455242567-17880-1-git-send-email-wens@csie.org>
Message-ID: <20160212090033.GN20693@x1>

Enjoy!

The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3:

  Linux 4.5-rc2 (2016-01-31 18:12:16 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/ib-mfd-regulator-v4.6

for you to fetch changes up to 04e0981c67e6a7ba8aacac731d925f4ff21b67fb:

  regulator: axp20x: Support new AXP223 PMIC (2016-02-12 08:55:34 +0000)

----------------------------------------------------------------
Immutable branch between MFD and Regulator

----------------------------------------------------------------
Chen-Yu Tsai (8):
      mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings
      mfd: axp20x: Remove second struct device * parameter for axp20x_match_device()
      mfd: axp20x: Use dev->driver->of_match_table in axp20x_match_device()
      mfd: axp20x: Add missing copyright notice
      mfd: axp20x: Split the driver into core and i2c bits
      mfd: axp20x: Whitespace, open parenthesis alignment code style fixes
      mfd: axp20x: Add support for RSB based AXP223 PMIC
      regulator: axp20x: Support new AXP223 PMIC

 Documentation/devicetree/bindings/mfd/axp20x.txt |   7 +-
 drivers/mfd/Kconfig                              |  25 ++++--
 drivers/mfd/Makefile                             |   2 +
 drivers/mfd/axp20x-i2c.c                         | 104 ++++++++++++++++++++++
 drivers/mfd/axp20x-rsb.c                         |  80 +++++++++++++++++
 drivers/mfd/axp20x.c                             | 105 ++++++-----------------
 drivers/regulator/axp20x-regulator.c             |   3 +
 include/linux/mfd/axp20x.h                       |  34 +++++++-
 8 files changed, 271 insertions(+), 89 deletions(-)
 create mode 100644 drivers/mfd/axp20x-i2c.c
 create mode 100644 drivers/mfd/axp20x-rsb.c

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lee.jones at linaro.org  Fri Feb 12 01:01:39 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Fri, 12 Feb 2016 09:01:39 +0000
Subject: [PATCH v8 00/10] mfd: axp20x: Add support for RSB based AXP223
In-Reply-To: <1455242567-17880-1-git-send-email-wens@csie.org>
References: <1455242567-17880-1-git-send-email-wens@csie.org>
Message-ID: <20160212090139.GO20693@x1>

On Fri, 12 Feb 2016, Chen-Yu Tsai wrote:

[...]

> Chen-Yu Tsai (10):
>   mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings
>   mfd: axp20x: Remove second struct device * parameter for
>     axp20x_match_device()
>   mfd: axp20x: use dev->driver->of_match_table in axp20x_match_device()
>   mfd: axp20x: Add missing copyright notice
>   mfd: axp20x: Split the driver into core and i2c bits
>   mfd: axp20x: Whitespace, open parenthesis alignment code style fixes
>   mfd: axp20x: Add support for RSB based AXP223 PMIC
>   regulator: axp20x: Support new AXP223 PMIC
>   ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC device and regulator
>     nodes
>   ARM: dts: sun8i: q8-common: Add AXP223 PMIC device and regulator nodes
> 
>  Documentation/devicetree/bindings/mfd/axp20x.txt |   7 +-
>  arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts   |  76 +++++++++++++++-
>  arch/arm/boot/dts/sun8i-q8-common.dtsi           |  83 +++++++++++++++++-
>  drivers/mfd/Kconfig                              |  25 ++++--
>  drivers/mfd/Makefile                             |   2 +
>  drivers/mfd/axp20x-i2c.c                         | 104 ++++++++++++++++++++++
>  drivers/mfd/axp20x-rsb.c                         |  80 +++++++++++++++++
>  drivers/mfd/axp20x.c                             | 105 ++++++-----------------
>  drivers/regulator/axp20x-regulator.c             |   3 +
>  include/linux/mfd/axp20x.h                       |  34 +++++++-
>  10 files changed, 425 insertions(+), 94 deletions(-)
>  create mode 100644 drivers/mfd/axp20x-i2c.c
>  create mode 100644 drivers/mfd/axp20x-rsb.c

Right, I've applied the MFD and Regulator patches and sent out the
required pull-request.  You just need to have the arch/arm/ patches
taken care off and you're all set.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From adrian.hunter at intel.com  Fri Feb 12 01:18:01 2016
From: adrian.hunter at intel.com (Adrian Hunter)
Date: Fri, 12 Feb 2016 11:18:01 +0200
Subject: [PATCH] MAINTAINERS: mmc: Add Adrian Hunter as the maintainer for
 SDHCI
In-Reply-To: <1455200099-5306-1-git-send-email-ulf.hansson@linaro.org>
References: <1455200099-5306-1-git-send-email-ulf.hansson@linaro.org>
Message-ID: <56BDA349.1040009@intel.com>

On 11/02/16 16:14, Ulf Hansson wrote:
>>From discussions on linux-mmc I have been encouraging someone to pick
> up the maintainer role for SDHCI. I am very pleased that Adrian Hunter
> volunteered and accepted the challenge!
> 
> The SDHCI code is currently in quite poor quality, but we have agreed on
> a way forward to try to reach a point where the SDHCI core becomes more of
> a set of library functions. Each SDHCI driver variant can then decide
> which functions to use and allows it to implement variant specific code,
> without needing to also change SDHCI core code.
> 
> In the end we aim to get better optimized and maintainable code.
> 
> Signed-off-by: Ulf Hansson <ulf.hansson at linaro.org>
> ---
>  MAINTAINERS | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 30aca4a..5511069 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9706,10 +9706,11 @@ S:	Maintained
>  F:	drivers/mmc/host/sdricoh_cs.c
>  
>  SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) DRIVER
> +M:	Adrian Hunter <adrian.hunter at intel.com>
>  L:	linux-mmc at vger.kernel.org
> -S:	Orphan
> -F:	drivers/mmc/host/sdhci.*
> -F:	drivers/mmc/host/sdhci-pltfm.[ch]
> +S:	Maintained

+T: git git://git.infradead.org/users/ahunter/linux-sdhci.git

> +F:	drivers/mmc/host/sdhci*
> +F:	include/linux/mmc/sdhci*
>  
>  SECURE COMPUTING
>  M:	Kees Cook <keescook at chromium.org>
> 

Sorry, I hadn't got round to doing this myself.

Acked-by: Adrian Hunter <adrian.hunter at intel.com>



From yamada.masahiro at socionext.com  Fri Feb 12 01:28:16 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 12 Feb 2016 18:28:16 +0900
Subject: [PATCH] earlycon: rework common framework for earlycon declarations
Message-ID: <1455269296-5009-1-git-send-email-yamada.masahiro@socionext.com>

Commit 71f50c6d9a22 ("of: drop symbols declared by _OF_DECLARE() from
modules") fixed the link error introduced by commit b8d20e06eaad
("serial: 8250_uniphier: add earlycon support").

After commit 2eaa790989e0 ("earlycon: Use common framework for
earlycon declarations") was applied, the link error came back
because the commit reworked OF_EARLYCON_DECLARE() to not use
_OF_DECLARE().

This commit reworks OF_EARLYCON_DECLARE() again based on
_OF_DECLARE().  My motivations are:

 - Fix the link error in a generic way (without patching
   drivers/tty/serial/8250/8250_uniphier.c)

 - Delete struct earlycon_id.  This struct is re-inventing the wheel;
   the fields "name", "compatible", "setup" can be implemented in
   struct of_device_id as other framework do.

The difference between OF_EARLYCON_DECLARE() and other users of
_OF_DECLARE is that OF_EARLYCON_DECLARE() needs to fill the "name"
field of struct of_device_id.  To make it easier, a new macro
_OF_DECLARE_WITH_NAME() has been added.  It fills the name field
with the given argument.  On the other hand, _OF_DECLARE() sets the
"name" field to a null string; this is the same behavior as before.

Fixes: 2eaa790989e0 ("earlycon: Use common framework for earlycon declarations")
Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

I confirmed this patch can apply onto "next-20160212" tag of linux-next.

In order to apply it onto the "tty-next" branch of TTY subsytem,
Grag will have to pull v4.5-rc3 in.


 drivers/of/fdt.c                  |  7 ++-----
 drivers/tty/serial/earlycon.c     | 19 +++++++++++++------
 include/asm-generic/vmlinux.lds.h | 12 ++----------
 include/linux/of.h                | 22 +++++++++++++++-------
 include/linux/serial_core.h       | 23 +++++++----------------
 5 files changed, 39 insertions(+), 44 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index e2295b2..ad262e9 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -802,7 +802,7 @@ static int __init early_init_dt_scan_chosen_serial(void)
 	int offset;
 	const char *p, *q, *options = NULL;
 	int l;
-	const struct earlycon_id *match;
+	const struct of_device_id *match;
 	const void *fdt = initial_boot_params;
 
 	offset = fdt_path_offset(fdt, "/chosen");
@@ -829,10 +829,7 @@ static int __init early_init_dt_scan_chosen_serial(void)
 		return 0;
 	}
 
-	for (match = __earlycon_table; match < __earlycon_table_end; match++) {
-		if (!match->compatible[0])
-			continue;
-
+	for (match = __earlycon_of_table; match->compatible[0]; match++) {
 		if (fdt_node_check_compatible(fdt, offset, match->compatible))
 			continue;
 
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 067783f..4888ced 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -38,6 +38,9 @@ static struct earlycon_device early_console_dev = {
 	.con = &early_con,
 };
 
+static const struct of_device_id __earlycon_of_table_sentinel
+	__used __section(__earlycon_of_table_end);
+
 static void __iomem * __init earlycon_map(unsigned long paddr, size_t size)
 {
 	void __iomem *base;
@@ -127,9 +130,10 @@ static int __init parse_options(struct earlycon_device *device, char *options)
 	return 0;
 }
 
-static int __init register_earlycon(char *buf, const struct earlycon_id *match)
+static int __init register_earlycon(char *buf, const struct of_device_id *match)
 {
 	int err;
+	int (*setup)(struct earlycon_device *, const char *options);
 	struct uart_port *port = &early_console_dev.port;
 
 	/* On parsing error, pass the options buf to the setup function */
@@ -142,7 +146,8 @@ static int __init register_earlycon(char *buf, const struct earlycon_id *match)
 		port->membase = earlycon_map(port->mapbase, 64);
 
 	earlycon_init(&early_console_dev, match->name);
-	err = match->setup(&early_console_dev, buf);
+	setup = match->data;
+	err = setup(&early_console_dev, buf);
 	if (err < 0)
 		return err;
 	if (!early_console_dev.con->write)
@@ -172,7 +177,7 @@ static int __init register_earlycon(char *buf, const struct earlycon_id *match)
  */
 int __init setup_earlycon(char *buf)
 {
-	const struct earlycon_id *match;
+	const struct of_device_id *match;
 
 	if (!buf || !buf[0])
 		return -EINVAL;
@@ -180,7 +185,7 @@ int __init setup_earlycon(char *buf)
 	if (early_con.flags & CON_ENABLED)
 		return -EALREADY;
 
-	for (match = __earlycon_table; match < __earlycon_table_end; match++) {
+	for (match = __earlycon_of_table; match->name[0]; match++) {
 		size_t len = strlen(match->name);
 
 		if (strncmp(buf, match->name, len))
@@ -220,12 +225,13 @@ early_param("earlycon", param_setup_earlycon);
 
 #ifdef CONFIG_OF_EARLY_FLATTREE
 
-int __init of_setup_earlycon(const struct earlycon_id *match,
+int __init of_setup_earlycon(const struct of_device_id *match,
 			     unsigned long node,
 			     const char *options)
 {
 	int err;
 	struct uart_port *port = &early_console_dev.port;
+	int (*setup)(struct earlycon_device *, const char *options);
 	const __be32 *val;
 	bool big_endian;
 	u64 addr;
@@ -273,7 +279,8 @@ int __init of_setup_earlycon(const struct earlycon_id *match,
 			sizeof(early_console_dev.options));
 	}
 	earlycon_init(&early_console_dev, match->name);
-	err = match->setup(&early_console_dev, options);
+	setup = match->data;
+	err = setup(&early_console_dev, options);
 	if (err < 0)
 		return err;
 	if (!early_console_dev.con->write)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index e9a81a6..699f4a5 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -153,15 +153,6 @@
 #define TRACE_SYSCALLS()
 #endif
 
-#ifdef CONFIG_SERIAL_EARLYCON
-#define EARLYCON_TABLE() STRUCT_ALIGN();			\
-			 VMLINUX_SYMBOL(__earlycon_table) = .;	\
-			 *(__earlycon_table)			\
-			 VMLINUX_SYMBOL(__earlycon_table_end) = .;
-#else
-#define EARLYCON_TABLE()
-#endif
-
 #define ___OF_TABLE(cfg, name)	_OF_TABLE_##cfg(name)
 #define __OF_TABLE(cfg, name)	___OF_TABLE(cfg, name)
 #define OF_TABLE(cfg, name)	__OF_TABLE(config_enabled(cfg), name)
@@ -179,6 +170,7 @@
 #define RESERVEDMEM_OF_TABLES()	OF_TABLE(CONFIG_OF_RESERVED_MEM, reservedmem)
 #define CPU_METHOD_OF_TABLES()	OF_TABLE(CONFIG_SMP, cpu_method)
 #define CPUIDLE_METHOD_OF_TABLES() OF_TABLE(CONFIG_CPU_IDLE, cpuidle_method)
+#define EARLYCON_OF_TABLES()	OF_TABLE(CONFIG_SERIAL_EARLYCON, earlycon)
 
 #ifdef CONFIG_ACPI
 #define ACPI_PROBE_TABLE(name)						\
@@ -525,7 +517,7 @@
 	IRQCHIP_OF_MATCH_TABLE()					\
 	ACPI_PROBE_TABLE(irqchip)					\
 	ACPI_PROBE_TABLE(clksrc)					\
-	EARLYCON_TABLE()
+	EARLYCON_OF_TABLES()
 
 #define INIT_TEXT							\
 	*(.init.text)							\
diff --git a/include/linux/of.h b/include/linux/of.h
index dc6e396..6e57245 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -930,19 +930,27 @@ static inline int of_get_available_child_count(const struct device_node *np)
 }
 
 #if defined(CONFIG_OF) && !defined(MODULE)
-#define _OF_DECLARE(table, name, compat, fn, fn_type)			\
-	static const struct of_device_id __of_table_##name		\
+#define __OF_DECLARE(table, name1, name2, compat, fn, fn_type)		\
+	static const struct of_device_id __UNIQUE_ID(__of_table_##name1)\
 		__used __section(__##table##_of_table)			\
-		 = { .compatible = compat,				\
+		 = { .name = name2,					\
+		     .compatible = compat,				\
 		     .data = (fn == (fn_type)NULL) ? fn : fn  }
 #else
-#define _OF_DECLARE(table, name, compat, fn, fn_type)			\
-	static const struct of_device_id __of_table_##name		\
+#define __OF_DECLARE(table, name1, name2, compat, fn, fn_type)		\
+	static const struct of_device_id __UNIQUE_ID(__of_table_##name1)\
 		__attribute__((unused))					\
-		 = { .compatible = compat,				\
-		     .data = (fn == (fn_type)NULL) ? fn : fn }
+		 = { .name = name2,					\
+		     .compatible = compat,				\
+		     .data = (fn == (fn_type)NULL) ? fn : fn  }
 #endif
 
+#define _OF_DECLARE(table, name, compat, fn, fn_type)	\
+	__OF_DECLARE(table, name, "", compat, fn, fn_type)
+
+#define _OF_DECLARE_WITH_NAME(table, name, compat, fn, fn_type)	\
+	__OF_DECLARE(table, name, __stringify(name), compat, fn, fn_type)
+
 typedef int (*of_init_fn_2)(struct device_node *, struct device_node *);
 typedef void (*of_init_fn_1)(struct device_node *);
 
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index cbfcf38..0f13160 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -24,6 +24,7 @@
 #include <linux/compiler.h>
 #include <linux/interrupt.h>
 #include <linux/circ_buf.h>
+#include <linux/mod_devicetable.h>
 #include <linux/spinlock.h>
 #include <linux/sched.h>
 #include <linux/tty.h>
@@ -340,26 +341,16 @@ struct earlycon_device {
 	unsigned int baud;
 };
 
-struct earlycon_id {
-	char	name[16];
-	char	compatible[128];
-	int	(*setup)(struct earlycon_device *, const char *options);
-} __aligned(32);
+extern const struct of_device_id __earlycon_of_table[];
 
-extern const struct earlycon_id __earlycon_table[];
-extern const struct earlycon_id __earlycon_table_end[];
+#define OF_EARLYCON_DECLARE(name, compat, fn)				\
+	_OF_DECLARE_WITH_NAME(earlycon, name, compat, fn, void *)
 
-#define OF_EARLYCON_DECLARE(_name, compat, fn)				\
-	static const struct earlycon_id __UNIQUE_ID(__earlycon_##_name)	\
-	     __used __section(__earlycon_table)				\
-		= { .name = __stringify(_name),				\
-		    .compatible = compat,				\
-		    .setup = fn  }
-
-#define EARLYCON_DECLARE(_name, fn)	OF_EARLYCON_DECLARE(_name, "", fn)
+#define EARLYCON_DECLARE(_name, fn)	\
+	OF_EARLYCON_DECLARE(_name, "-earlycon-dummy-compat-string-", fn)
 
 extern int setup_earlycon(char *buf);
-extern int of_setup_earlycon(const struct earlycon_id *match,
+extern int of_setup_earlycon(const struct of_device_id *match,
 			     unsigned long node,
 			     const char *options);
 
-- 
1.9.1



From wens at csie.org  Fri Feb 12 01:31:13 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 12 Feb 2016 17:31:13 +0800
Subject: [PATCH v2 0/2] clk: sunxi: Fix APBS clock for Allwinner A80
Message-ID: <1455269475-8180-1-git-send-email-wens@csie.org>

Hi everyone,

This is v2 of the A80 APBS clock fixes series.

When I did the A80 PRCM support, I failed to notice the A80's APBS clock
was not the same as the A23's APB0 clock. The former is a zero-based
divider, while the latter is a power-of-two divider. But the lowest 2
dividers are the same.

The hardware defaults to the lowest setting, or a /1 divider. Since the
child gates do not propagate clk_set_rate up, and no consumers here do
clk_set_rate, this actually works.

I realized my mistake while reviewing the A83T's PRCM patches. The A83T
shares the same PRCM clocks as the A80.

Maxime, since this was introduced in 4.5-rc1, please apply this series
for 4.5 so we fix it before the release.


Changes since v1:

  - Replace the CLK_OF_DECLARE version of sun8i-a23-apb0-clk with the
    A80 APBS version, instead of writing a new driver.

Regards
ChenYu


Chen-Yu Tsai (2):
  clk: sunxi: Add support for A80 APBS clock
  ARM: dts: sun9i: Fix apbs clock compatible

 Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
 arch/arm/boot/dts/sun9i-a80.dtsi                  |  2 +-
 drivers/clk/sunxi/clk-sun8i-apb0.c                | 23 ++++++++---------------
 3 files changed, 10 insertions(+), 16 deletions(-)

-- 
2.7.0



From wens at csie.org  Fri Feb 12 01:31:15 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 12 Feb 2016 17:31:15 +0800
Subject: [PATCH v2 2/2] ARM: dts: sun9i: Fix apbs clock compatible
In-Reply-To: <1455269475-8180-1-git-send-email-wens@csie.org>
References: <1455269475-8180-1-git-send-email-wens@csie.org>
Message-ID: <1455269475-8180-3-git-send-email-wens@csie.org>

The APBS clock on A80 is not compatible with A23's APB0 clock. The only
reason it works is becase the lowest and default divider is the same.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/boot/dts/sun9i-a80.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index f68b3242b33a..2b4ce813b0ad 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -395,7 +395,7 @@
 		};
 
 		apbs: clk at 0800141c {
-			compatible = "allwinner,sun8i-a23-apb0-clk";
+			compatible = "allwinner,sun9i-a80-apbs-clk";
 			reg = <0x0800141c 0x4>;
 			#clock-cells = <0>;
 			clocks = <&ahbs>;
-- 
2.7.0



From wens at csie.org  Fri Feb 12 01:31:14 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Fri, 12 Feb 2016 17:31:14 +0800
Subject: [PATCH v2 1/2] clk: sunxi: Add support for A80 APBS clock
In-Reply-To: <1455269475-8180-1-git-send-email-wens@csie.org>
References: <1455269475-8180-1-git-send-email-wens@csie.org>
Message-ID: <1455269475-8180-2-git-send-email-wens@csie.org>

A80's APBS clock is not the same as the APB0 clock on A23. The A80's
is a zero-based divider, while the A23's is a power-of-two divider.

Replace the CLK_OF_DECLARE version of sun8i-a23-apb0. This also extends
the common setup function to take div clk flags.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
 drivers/clk/sunxi/clk-sun8i-apb0.c                | 23 ++++++++---------------
 2 files changed, 9 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index 966dcaffcb9c..5206e48694d6 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -60,6 +60,7 @@ Required properties:
 	"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
 	"allwinner,sun8i-a83t-bus-gates-clk" - for the bus gates on A83T
 	"allwinner,sun8i-h3-bus-gates-clk" - for the bus gates on H3
+	"allwinner,sun9i-a80-apbs-clk" - for the APBS clock on A80
 	"allwinner,sun9i-a80-apbs-gates-clk" - for the APBS gates on A80
 	"allwinner,sun4i-a10-dram-gates-clk" - for the DRAM gates on A10
 	"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
diff --git a/drivers/clk/sunxi/clk-sun8i-apb0.c b/drivers/clk/sunxi/clk-sun8i-apb0.c
index 7ba61103a6f5..cfe9c19a831b 100644
--- a/drivers/clk/sunxi/clk-sun8i-apb0.c
+++ b/drivers/clk/sunxi/clk-sun8i-apb0.c
@@ -21,7 +21,7 @@
 #include <linux/platform_device.h>
 
 static struct clk *sun8i_a23_apb0_register(struct device_node *node,
-					   void __iomem *reg)
+					   void __iomem *reg, u8 div_flags)
 {
 	const char *clk_name = node->name;
 	const char *clk_parent;
@@ -36,7 +36,7 @@ static struct clk *sun8i_a23_apb0_register(struct device_node *node,
 
 	/* The A23 APB0 clock is a standard 2 bit wide divider clock */
 	clk = clk_register_divider(NULL, clk_name, clk_parent, 0, reg,
-				   0, 2, CLK_DIVIDER_POWER_OF_TWO, NULL);
+				   0, 2, div_flags, NULL);
 	if (IS_ERR(clk))
 		return clk;
 
@@ -52,7 +52,7 @@ err_unregister:
 	return ERR_PTR(ret);
 }
 
-static void sun8i_a23_apb0_setup(struct device_node *node)
+static void sun9i_a80_apbs_setup(struct device_node *node)
 {
 	void __iomem *reg;
 	struct resource res;
@@ -60,18 +60,11 @@ static void sun8i_a23_apb0_setup(struct device_node *node)
 
 	reg = of_io_request_and_map(node, 0, of_node_full_name(node));
 	if (IS_ERR(reg)) {
-		/*
-		 * This happens with clk nodes instantiated through mfd,
-		 * as those do not have their resources assigned in the
-		 * device tree. Do not print an error in this case.
-		 */
-		if (PTR_ERR(reg) != -EINVAL)
-			pr_err("Could not get registers for a23-apb0-clk\n");
-
+		pr_err("Could not get registers for a80-apbs-clk\n");
 		return;
 	}
 
-	clk = sun8i_a23_apb0_register(node, reg);
+	clk = sun8i_a23_apb0_register(node, reg, 0);
 	if (IS_ERR(clk))
 		goto err_unmap;
 
@@ -82,8 +75,8 @@ err_unmap:
 	of_address_to_resource(node, 0, &res);
 	release_mem_region(res.start, resource_size(&res));
 }
-CLK_OF_DECLARE(sun8i_a23_apb0, "allwinner,sun8i-a23-apb0-clk",
-	       sun8i_a23_apb0_setup);
+CLK_OF_DECLARE(sun9i_a80_apbs, "allwinner,sun9i-a80-apbs-clk",
+	       sun9i_a80_apbs_setup);
 
 static int sun8i_a23_apb0_clk_probe(struct platform_device *pdev)
 {
@@ -97,7 +90,7 @@ static int sun8i_a23_apb0_clk_probe(struct platform_device *pdev)
 	if (IS_ERR(reg))
 		return PTR_ERR(reg);
 
-	clk = sun8i_a23_apb0_register(np, reg);
+	clk = sun8i_a23_apb0_register(np, reg, CLK_DIVIDER_POWER_OF_TWO);
 	if (IS_ERR(clk))
 		return PTR_ERR(clk);
 
-- 
2.7.0



From yamada.masahiro at socionext.com  Fri Feb 12 01:37:08 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 12 Feb 2016 18:37:08 +0900
Subject: [PATCH v2 4/6] serial: 8250/uniphier: fix modular build
In-Reply-To: <1455205297-1021302-5-git-send-email-arnd@arndb.de>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
 <1455205297-1021302-5-git-send-email-arnd@arndb.de>
Message-ID: <CAK7LNAR8fJWPubucjw28gAPpF-4yvVMWZZ0F3j6VN4whGF9Yhw@mail.gmail.com>

Hi Arnd,




2016-02-12 0:41 GMT+09:00 Arnd Bergmann <arnd at arndb.de>:
> The newly added uniphier serial port driver fails to build as
> a loadable module when the base 8250 driver is built-in and
> its console support enabled:
>
> ERROR: "early_serial8250_setup" [drivers/tty/serial/8250/8250_uniphier.ko] undefined!
>
> This changes the driver to only provide the early console support
> if it is built-in itself as well.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/tty/serial/8250/8250_uniphier.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_uniphier.c b/drivers/tty/serial/8250/8250_uniphier.c
> index bab6b3ae2540..1b7bd26555b7 100644
> --- a/drivers/tty/serial/8250/8250_uniphier.c
> +++ b/drivers/tty/serial/8250/8250_uniphier.c
> @@ -35,7 +35,7 @@ struct uniphier8250_priv {
>         spinlock_t atomic_write_lock;
>  };
>
> -#ifdef CONFIG_SERIAL_8250_CONSOLE
> +#if defined(CONFIG_SERIAL_8250_CONSOLE) && !defined(MODULE)
>  static int __init uniphier_early_console_setup(struct earlycon_device *device,
>                                                const char *options)
>  {
> --
> 2.7.0
>

I noticed commit 2eaa790989e03900298ad24f77f1086dbbc1aebd
revived this link error, but I am not happy with seeing
this patch again and again.


Can you check this patch?
https://patchwork.kernel.org/patch/8289231/



-- 
Best Regards
Masahiro Yamada


From l.stach at pengutronix.de  Fri Feb 12 01:40:30 2016
From: l.stach at pengutronix.de (Lucas Stach)
Date: Fri, 12 Feb 2016 10:40:30 +0100
Subject: breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi:
 Refactor A31 PLL6 so that it can be reused)
In-Reply-To: <20160211170820.GP31506@lukather>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <56BB2D79.6090402@arm.com>
 <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
 <20160210143755.GE31506@lukather> <20160210163001.GG2632@leverpostej>
 <20160211100048.GK31506@lukather> <20160211114410.GA32535@leverpostej>
 <20160211170820.GP31506@lukather>
Message-ID: <1455270030.3201.71.camel@pengutronix.de>

Am Donnerstag, den 11.02.2016, 18:08 +0100 schrieb Maxime Ripard:
[...]
> > > > Having code in mainline comes with responsibilities. One of those is to
> > > > keep said code working for existing users. Otherwise, why bother having
> > > > it in mainline at all?
> > > 
> > > None of our existing users ever complained.
> > 
> > I believe that in this case, Andre was complaining about this particular
> > breakage, unless I have misunderstood.
> > 
> > To be clear, I'm arguing for the strategy going forward. If no-one has
> > complained about the stuff broken up to this point, let's not waste time
> > restoring that.
> > 
> > Going forward we need to keep old DTBs supported.
> 
> I find that stand a bit dishonest.
> 
> You, DT maintainers, admit that you're not doing your job properly,
> and that burden relies on the platform maintainers? Or should I take
> it as you volunteering to maintain that code?
> 
> But ok. Let's do that. Make sure that the other platform maintainers
> are aware that this is the rule too though. I surely don't want to be
> alone in that boat.

FWIW: I always thought it's the platform maintainers job to enforce a
reasonable level of DT stability. I don't see how the DT maintainers
could provide the necessary in-depth review with every platform being
different in many subtle ways.

For the i.MX platform we actually enforced a baseline of DT stability by
shooting down patches that break DT stability for the sake of adding new
features, or when trying to put "fixes" into the DT, that could be
solved entirely inside the kernel.

Yes, mistakes happen and and we can not really prevent all breakage,
especially when the bindings were not strictly enough defined and board
DT writers may have interpreted them differently, but it is definitely
possible to keep DTs reasonably stable if the platform maintainers care
about that.

I strongly disagree with platform maintainers denying that duty, by
claiming that DTs won't be completely stable ever, so there is no reason
to even care.

Regards,
Lucas
-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |



From yamada.masahiro at socionext.com  Fri Feb 12 01:43:05 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 12 Feb 2016 18:43:05 +0900
Subject: [PATCH v2 5/6] serial: 8250/mediatek: fix building with
 SERIAL_8250=m
In-Reply-To: <1455205297-1021302-6-git-send-email-arnd@arndb.de>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
 <1455205297-1021302-6-git-send-email-arnd@arndb.de>
Message-ID: <CAK7LNAS5oNd8hdjS6+mYoPhNVTaGzAjc4SvnSmP1f_pDeHTFDg@mail.gmail.com>

Hi Arnd,


2016-02-12 0:41 GMT+09:00 Arnd Bergmann <arnd at arndb.de>:
> The Mediatek 8250 driver has a 'bool' Kconfig symbol, but that
> breaks when SERIAL_8250 is a loadable module:
>
> drivers/tty/built-in.o: In function `mtk8250_set_termios':
> :(.text+0x1bee8): undefined reference to `serial8250_do_set_termios'
> :(.text+0x1bf10): undefined reference to `uart_get_baud_rate'
> :(.text+0x1c09c): undefined reference to `uart_get_divisor'
> drivers/tty/built-in.o: In function `mtk8250_do_pm':
> :(.text+0x1c0d0): undefined reference to `serial8250_do_pm'
> drivers/tty/built-in.o: In function `mtk8250_probe':
> :(.text+0x1c2e4): undefined reference to `serial8250_register_8250_port'
> serial/8250/8250_mtk.c:287:242: error: data definition has no type or storage class [-Werror]
> serial/8250/8250_mtk.c:287:122: error: 'mtk8250_platform_driver_init' defined but not used [-Werror=unused-function]
>
> This changes the symbol to a 'tristate', so the dependency on
> SERIAL_8250 also works when that is set to 'm'.
> To actually build the driver, we also need to include <linux/module.h>.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/tty/serial/8250/8250_mtk.c | 3 ++-
>  drivers/tty/serial/8250/Kconfig    | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
> index 6ecc6e3e82dc..55be90c1d85e 100644
> --- a/drivers/tty/serial/8250/8250_mtk.c
> +++ b/drivers/tty/serial/8250/8250_mtk.c
> @@ -19,6 +19,7 @@
>  #include <linux/module.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_platform.h>
> +#include <linux/module.h>
>  #include <linux/platform_device.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/serial_8250.h>
> @@ -303,7 +304,7 @@ static struct platform_driver mtk8250_platform_driver = {
>  };
>  module_platform_driver(mtk8250_platform_driver);
>
> -#ifdef CONFIG_SERIAL_8250_CONSOLE
> +#if defined(CONFIG_SERIAL_8250_CONSOLE) && !defined(MODULE)
>  static int __init early_mtk8250_setup(struct earlycon_device *device,
>                                         const char *options)
>  {


As mentioned in 4/6, this hunk might become unneeded if
https://patchwork.kernel.org/patch/8289231/
is accepted.



-- 
Best Regards
Masahiro Yamada


From arnd at arndb.de  Fri Feb 12 01:45:55 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 10:45:55 +0100
Subject: [PATCH v2] ARM: mm: mark section-aligned portion of rodata NX
In-Reply-To: <20160211180032.GY10826@n2100.arm.linux.org.uk>
References: <20151207223534.GA13722@www.outflux.net>
 <CAGXu5jLDK8eVO2kUD1cB3TArL8k8pF=igc3O04Fa40QgQ2pwNw@mail.gmail.com>
 <20160211180032.GY10826@n2100.arm.linux.org.uk>
Message-ID: <4300378.sBT9DdB2Gc@wuerfel>

On Thursday 11 February 2016 18:00:32 Russell King - ARM Linux wrote:
> On Fri, Jan 22, 2016 at 01:19:03PM -0800, Kees Cook wrote:
> > On Tue, Dec 8, 2015 at 10:38 AM, Kees Cook <keescook at chromium.org> wrote:
> > > On Mon, Dec 7, 2015 at 11:47 PM, Ard Biesheuvel
> > > <ard.biesheuvel at linaro.org> wrote:
> > >> On 7 December 2015 at 23:35, Kees Cook <keescook at chromium.org> wrote:
> > >>>  /*
> > >>> + * Without CONFIG_DEBUG_ALIGN_RODATA, __start_rodata_section_aligned will
> > >>> + * be the first section-aligned location after __start_rodata. Otherwise,
> > >>> + * it will be equal to __start_rodata.
> > >>> + */
> > >>> +__start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
> ...
> 
> I'm afraid this causes build errors on two configurations:
> 
> ./arch/arm/kernel/vmlinux.lds:701: undefined symbol `SECTION_SHIFT' referenced in expression
> 
> which I think is down to the new __start_rodata_section_aligned line.
> 
> Olof's builder errored out with this for both allnoconfig and
> lpc18xx_defconfig builds.  Both probably due to CONFIG_MMU being
> unset, and hence no definition for SECTION_SHIFT.
> 
> I think you need to make this conditional on CONFIG_MMU.

I've hit another problem with this patch, when using XIP_KERNEL, I now see

arch/arm/mm/built-in.o:(.data+0x4bc): undefined reference to `__start_rodata_section_aligned'

in linux-next, apparently because of the combination with "ARM: 8513/1: xip: Move
XIP linking to a separate file".

	Arnd


From yamada.masahiro at socionext.com  Fri Feb 12 01:45:58 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 12 Feb 2016 18:45:58 +0900
Subject: [PATCH v2 6/6] serial: 8250/ingenic: fix building with
 SERIAL_8250=m
In-Reply-To: <1455205297-1021302-7-git-send-email-arnd@arndb.de>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
 <1455205297-1021302-7-git-send-email-arnd@arndb.de>
Message-ID: <CAK7LNAT3xxJut0Dqu_Cy4CAVc1foBN93+nGhSFo=qOtjRhYjGw@mail.gmail.com>

Hi Arnd,


2016-02-12 0:41 GMT+09:00 Arnd Bergmann <arnd at arndb.de>:
> The Ingenic 8250 driver has a 'bool' Kconfig symbol, but that
> breaks when SERIAL_8250 is a loadable module:
>
> drivers/tty/built-in.o: In function `ingenic_uart_probe':
> 8250_ingenic.c:(.text+0x1c1a0): undefined reference to `serial8250_register_8250_port'
>
> This changes the symbol to a 'tristate', plus a dependency on
> SERIAL_8250, which makes it work again. Unlike the other
> soc-specific backends, this one has no dependency on an
> architecture or a platform. I'm adding a dependency on
> MIPS || COMPILE_TEST as well here, to avoid showing the driver
> on architectures that are not interested in it.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/tty/serial/8250/8250_ingenic.c | 2 +-
>  drivers/tty/serial/8250/Kconfig        | 7 ++++---
>  2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_ingenic.c b/drivers/tty/serial/8250/8250_ingenic.c
> index 97b78558caed..b0677f610863 100644
> --- a/drivers/tty/serial/8250/8250_ingenic.c
> +++ b/drivers/tty/serial/8250/8250_ingenic.c
> @@ -48,7 +48,7 @@ static const struct of_device_id of_match[];
>  #define UART_MCR_MDCE  BIT(7)
>  #define UART_MCR_FCM   BIT(6)
>
> -#ifdef CONFIG_SERIAL_EARLYCON
> +#if defined(CONFIG_SERIAL_EARLYCON) && !defined(MODULE)
>  static struct earlycon_device *early_device;
>
>  static uint8_t __init early_in(struct uart_port *port, int offset)


The same comment applies here as 5/6.





-- 
Best Regards
Masahiro Yamada


From will.deacon at arm.com  Fri Feb 12 01:51:44 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 12 Feb 2016 09:51:44 +0000
Subject: [PATCH V1 6/6] acpi: apei: handle SEA notification type for ARMv8
In-Reply-To: <56BD0D43.4060901@codeaurora.org>
References: <1454699608-22760-1-git-send-email-tbaicar@codeaurora.org>
 <1454699608-22760-7-git-send-email-tbaicar@codeaurora.org>
 <20160210180332.GU1052@arm.com> <56BD0D43.4060901@codeaurora.org>
Message-ID: <20160212095143.GC25087@arm.com>

On Thu, Feb 11, 2016 at 03:37:55PM -0700, Baicar, Tyler wrote:
> On 2/10/2016 11:03 AM, Will Deacon wrote:
> >On Fri, Feb 05, 2016 at 12:13:28PM -0700, Tyler Baicar wrote:
> >>diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> >>index 6c68100..ed64b97 100644
> >>--- a/drivers/acpi/apei/ghes.c
> >>+++ b/drivers/acpi/apei/ghes.c
> >>@@ -50,6 +50,10 @@
> >>  #include <acpi/apei.h>
> >>  #include <asm/tlbflush.h>
> >>+#ifdef CONFIG_HAVE_ACPI_APEI_SEA
> >>+#include <asm/system_misc.h>
> >>+#endif
> >>+
> >>  #include "apei-internal.h"
> >>  #define GHES_PFX	"GHES: "
> >>@@ -784,6 +788,62 @@ static struct notifier_block ghes_notifier_sci = {
> >>  	.notifier_call = ghes_notify_sci,
> >>  };
> >>+#ifdef CONFIG_HAVE_ACPI_APEI_SEA
> >>+static LIST_HEAD(ghes_sea);
> >>+
> >>+static int ghes_notify_sea(struct notifier_block *this,
> >>+				  unsigned long event, void *data)
> >>+{
> >>+	struct ghes *ghes;
> >>+	int ret = NOTIFY_DONE;
> >>+
> >>+	rcu_read_lock();
> >>+	list_for_each_entry_rcu(ghes, &ghes_sea, list) {
> >>+		if (!ghes_proc(ghes))
> >>+			ret = NOTIFY_OK;
> >>+	}
> >>+	rcu_read_unlock();
> >>+
> >>+	return ret;
> >>+}
> >>+
> >>+static struct notifier_block ghes_notifier_sea = {
> >>+	.notifier_call = ghes_notify_sea,
> >>+};
> >>+
> >>+static int ghes_sea_add(struct ghes *ghes)
> >>+{
> >>+	mutex_lock(&ghes_list_mutex);
> >Can you just use spin_lock, to be consistent with our other excception
> >hooks?
> This mutex is being used throughout ghes.c for editing the lists, so I think
> this is the proper (or at least consistent) implementation. This mutex was
> defined specifically for editing the lists according to the comment above
> the mutex definition:
> 
> "All error sources notified with SCI shares one notifier function, so they
> need to be linked and checked one by one. This is applied to NMI too. RCU is
> used for these lists, so ghes_list_mutex is only used for list changing, not
> for traversing."
> 
> The use of this mutex is identical to the way that SCI and NMI use it when
> adding or deleting from the lists. Should I add to this comment that this
> applies to SEA as well?

No, it's fine. I overlooked the fact that this was under drivers/acpi/,
so if you're consistent with other code under there then there's no need
to change anything.

Will


From arnd at arndb.de  Fri Feb 12 02:01:24 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 11:01:24 +0100
Subject: [PATCH] ARM: socfpga_defconfig: enable support for
 initramfs/initrd support
In-Reply-To: <7hwpqaoj69.fsf@baylibre.com>
References: <1455230856-19648-1-git-send-email-dinguyen@opensource.altera.com>
 <4776059.MG11XzgNhU@wuerfel> <7hwpqaoj69.fsf@baylibre.com>
Message-ID: <3329414.HcXjecCDpd@wuerfel>

On Thursday 11 February 2016 16:40:14 Kevin Hilman wrote:
> Arnd Bergmann <arnd at arndb.de> writes:
> 
> > On Thursday 11 February 2016 16:47:36 dinguyen at opensource.altera.com wrote:
> >> From: Dinh Nguyen <dinguyen at opensource.altera.com>
> >> 
> >> Enable CONFIG_BLK_DEV_INITRD.
> >> 
> >> Signed-off-by: Dinh Nguyen <dinguyen at opensource.altera.com>
> >
> > What for?
> >
> 
> So the board farms doing boot testing can do so with an initramfs.
> 
> Acked-by: Kevin Hilman <khilman at baylibre.com>

Ah, got it. I thought this was just the option for the old-style blockdev
based initrd, not the new-style initramfs.

	Arnd


From will.deacon at arm.com  Fri Feb 12 02:01:37 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 12 Feb 2016 10:01:37 +0000
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160211205702.24f0d17a@thinkpad>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
Message-ID: <20160212100137.GE25087@arm.com>

On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> On Thu, 11 Feb 2016 21:09:42 +0200
> "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> > > he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
> > > review of the THP rework patches, which cannot be bisected, revealed
> > > commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
> > > (and also similar commits for other archs).
> > > 
> > > This commit removes the THP splitting bit and also the architecture
> > > implementation of pmdp_splitting_flush(), which took care of the IPI for
> > > fast_gup serialization. The commit message says
> > > 
> > >     pmdp_splitting_flush() is not needed too: on splitting PMD we will do
> > >     pmdp_clear_flush() + set_pte_at().  pmdp_clear_flush() will do IPI as
> > >     needed for fast_gup
> > > 
> > > The assumption that a TLB flush will also produce an IPI is wrong on s390,
> > > and maybe also on other architectures, and I thought that this was actually
> > > the main reason for having an arch-specific pmdp_splitting_flush().
> > > 
> > > At least PowerPC and ARM also had an individual implementation of
> > > pmdp_splitting_flush() that used kick_all_cpus_sync() instead of a TLB
> > > flush to send the IPI, and those were also removed. Putting the arch
> > > maintainers and mailing lists on cc to verify.
> > > 
> > > On s390 this will break the IPI serialization against fast_gup, which
> > > would certainly explain the random kernel crashes, please revert or fix
> > > the pmdp_splitting_flush() removal.
> > 
> > Sorry for that.
> > 
> > I believe, the problem was already addressed for PowerPC:
> > 
> > http://lkml.kernel.org/g/454980831-16631-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com
> > 
> > I think kick_all_cpus_sync() in arch-specific pmdp_invalidate() would do
> > the trick, right?
> 
> Hmm, not sure about that. After pmdp_invalidate(), a pmd_none() check in
> fast_gup will still return false, because the pmd is not empty (at least
> on s390). So I don't see spontaneously how it will help fast_gup to break
> out to the slow path in case of THP splitting.
> 
> > 
> > If yes, I'll prepare patch tomorrow (some sleep required).
> > 
> 
> We'll check if adding kick_all_cpus_sync() to pmdp_invalidate() helps.
> It would also be good if Martin has a look at this, he'll return on
> Monday.

Do you have a reliable way to trigger the "random kernel crashes"? We've not
seen anything reported on arm64, but I don't see why we wouldn't be affected
by the same bug and it would be good to confirm and validate a fix.

Cheers,

Will


From arnd at arndb.de  Fri Feb 12 02:05:55 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 11:05:55 +0100
Subject: [PATCH] earlycon: rework common framework for earlycon
 declarations
In-Reply-To: <1455269296-5009-1-git-send-email-yamada.masahiro@socionext.com>
References: <1455269296-5009-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <4230998.Zt9XrE8YSr@wuerfel>

On Friday 12 February 2016 18:28:16 Masahiro Yamada wrote:
> Commit 71f50c6d9a22 ("of: drop symbols declared by _OF_DECLARE() from
> modules") fixed the link error introduced by commit b8d20e06eaad
> ("serial: 8250_uniphier: add earlycon support").
> 
> After commit 2eaa790989e0 ("earlycon: Use common framework for
> earlycon declarations") was applied, the link error came back
> because the commit reworked OF_EARLYCON_DECLARE() to not use
> _OF_DECLARE().
> 
> This commit reworks OF_EARLYCON_DECLARE() again based on
> _OF_DECLARE().  My motivations are:
> 
>  - Fix the link error in a generic way (without patching
>    drivers/tty/serial/8250/8250_uniphier.c)
> 
>  - Delete struct earlycon_id.  This struct is re-inventing the wheel;
>    the fields "name", "compatible", "setup" can be implemented in
>    struct of_device_id as other framework do.
> 
> The difference between OF_EARLYCON_DECLARE() and other users of
> _OF_DECLARE is that OF_EARLYCON_DECLARE() needs to fill the "name"
> field of struct of_device_id.  To make it easier, a new macro
> _OF_DECLARE_WITH_NAME() has been added.  It fills the name field
> with the given argument.  On the other hand, _OF_DECLARE() sets the
> "name" field to a null string; this is the same behavior as before.
> 
> Fixes: 2eaa790989e0 ("earlycon: Use common framework for earlycon declarations")
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
> ---
> 
> I confirmed this patch can apply onto "next-20160212" tag of linux-next.
> 
> In order to apply it onto the "tty-next" branch of TTY subsytem,
> Grag will have to pull v4.5-rc3 in.

I think this is the right approach, and I can include it in my 8250
series when I resend it, and rebase the other patches on top of it
to simplify them.

Peter, since you did the change "earlycon: Use common framework for
earlycon declarations", are you ok with the new version?

	Arnd


From arnd at arndb.de  Fri Feb 12 02:07:11 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 11:07:11 +0100
Subject: [PATCH v2 4/6] serial: 8250/uniphier: fix modular build
In-Reply-To: <CAK7LNAR8fJWPubucjw28gAPpF-4yvVMWZZ0F3j6VN4whGF9Yhw@mail.gmail.com>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
 <1455205297-1021302-5-git-send-email-arnd@arndb.de>
 <CAK7LNAR8fJWPubucjw28gAPpF-4yvVMWZZ0F3j6VN4whGF9Yhw@mail.gmail.com>
Message-ID: <3557175.oOjJgCHd2P@wuerfel>

On Friday 12 February 2016 18:37:08 Masahiro Yamada wrote:
> >  };
> >
> > -#ifdef CONFIG_SERIAL_8250_CONSOLE
> > +#if defined(CONFIG_SERIAL_8250_CONSOLE) && !defined(MODULE)
> >  static int __init uniphier_early_console_setup(struct earlycon_device *device,
> >                                                const char *options)
> >  {
> > --
> > 2.7.0
> >
> 
> I noticed commit 2eaa790989e03900298ad24f77f1086dbbc1aebd
> revived this link error, but I am not happy with seeing
> this patch again and again.
> 
> 
> Can you check this patch?
> https://patchwork.kernel.org/patch/8289231/
> 
> 
> 

Yes, I think your patch is nicer than mine. Let's see what the others
think, then I can resend my remaining patches on top of yours.

	Arnd


From sebott at linux.vnet.ibm.com  Fri Feb 12 02:12:34 2016
From: sebott at linux.vnet.ibm.com (Sebastian Ott)
Date: Fri, 12 Feb 2016 11:12:34 +0100 (CET)
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160212100137.GE25087@arm.com>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad> <20160212100137.GE25087@arm.com>
Message-ID: <alpine.LFD.2.20.1602121106140.1773@schleppi>

On Fri, 12 Feb 2016, Will Deacon wrote:
> On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> > On Thu, 11 Feb 2016 21:09:42 +0200
> > "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> > > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > > > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> > > > he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
> > > > review of the THP rework patches, which cannot be bisected, revealed
> > > > commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
> > > > (and also similar commits for other archs).
> > > > 
> > > > This commit removes the THP splitting bit and also the architecture
> > > > implementation of pmdp_splitting_flush(), which took care of the IPI for
> > > > fast_gup serialization. The commit message says
> > > > 
> > > >     pmdp_splitting_flush() is not needed too: on splitting PMD we will do
> > > >     pmdp_clear_flush() + set_pte_at().  pmdp_clear_flush() will do IPI as
> > > >     needed for fast_gup
> > > > 
> > > > The assumption that a TLB flush will also produce an IPI is wrong on s390,
> > > > and maybe also on other architectures, and I thought that this was actually
> > > > the main reason for having an arch-specific pmdp_splitting_flush().
> > > > 
> > > > At least PowerPC and ARM also had an individual implementation of
> > > > pmdp_splitting_flush() that used kick_all_cpus_sync() instead of a TLB
> > > > flush to send the IPI, and those were also removed. Putting the arch
> > > > maintainers and mailing lists on cc to verify.
> > > > 
> > > > On s390 this will break the IPI serialization against fast_gup, which
> > > > would certainly explain the random kernel crashes, please revert or fix
> > > > the pmdp_splitting_flush() removal.
> > > 
> > > Sorry for that.
> > > 
> > > I believe, the problem was already addressed for PowerPC:
> > > 
> > > http://lkml.kernel.org/g/454980831-16631-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com
> > > 
> > > I think kick_all_cpus_sync() in arch-specific pmdp_invalidate() would do
> > > the trick, right?
> > 
> > Hmm, not sure about that. After pmdp_invalidate(), a pmd_none() check in
> > fast_gup will still return false, because the pmd is not empty (at least
> > on s390). So I don't see spontaneously how it will help fast_gup to break
> > out to the slow path in case of THP splitting.
> > 
> > > 
> > > If yes, I'll prepare patch tomorrow (some sleep required).
> > > 
> > 
> > We'll check if adding kick_all_cpus_sync() to pmdp_invalidate() helps.
> > It would also be good if Martin has a look at this, he'll return on
> > Monday.
> 
> Do you have a reliable way to trigger the "random kernel crashes"? We've not
> seen anything reported on arm64, but I don't see why we wouldn't be affected
> by the same bug and it would be good to confirm and validate a fix.

My testcase was compiling the kernel. Most of the time my test system
didn't survive a single compile run. During bisect I did at least 20
compile runs to flag a commit as good.

Sebastian



From tn at semihalf.com  Fri Feb 12 02:10:59 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Fri, 12 Feb 2016 11:10:59 +0100
Subject: [PATCH V3 06/10] irqchip, GICv3, ITS: Refator ITS dt init code to
 prepare for ACPI.
In-Reply-To: <56BB1548.5050402@arm.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
 <1453209083-3358-7-git-send-email-tn@semihalf.com> <56BB1548.5050402@arm.com>
Message-ID: <56BDAFB3.6090807@semihalf.com>

On 10.02.2016 11:47, Marc Zyngier wrote:
> On 19/01/16 13:11, Tomasz Nowicki wrote:
>> Similarly to GICv3 core, we need to extract common code before adding
>> ACPI support. No functional changes.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
>> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
>> ---
>>   drivers/irqchip/irq-gic-v3-its.c   | 82 +++++++++++++++++++++++---------------
>>   drivers/irqchip/irq-gic-v3.c       |  6 +--
>>   include/linux/irqchip/arm-gic-v3.h |  2 +-
>>   3 files changed, 52 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c

[..]

>> -static int __init its_probe(struct device_node *node,
>> -			    struct irq_domain *parent)
>> +static int __init its_probe_one(phys_addr_t phys_base, unsigned long size,
>> +				struct irq_domain *parent,
>> +				bool is_msi_controller,
>
> I really question the fact that you are keeping this msi_controller
> thing. Let's face it: if this is not an MSI controller, then the whole
> thing is absolutely pointless.
>
> So I'd rather you simplify the whole in a separate patch, and just don't
> bother initializing the ITS if it cannot be used for MSIs.
>
>> +				struct fwnode_handle *handler)
>>   {
>> -	struct resource res;
>>   	struct its_node *its;
>>   	void __iomem *its_base;
>>   	struct irq_domain *inner_domain;
>> @@ -1435,33 +1436,26 @@ static int __init its_probe(struct device_node *node,
>>   	u64 baser, tmp;
>>   	int err;
>>
>> -	err = of_address_to_resource(node, 0, &res);
>> -	if (err) {
>> -		pr_warn("%s: no regs?\n", node->full_name);
>> -		return -ENXIO;
>> -	}
>> -
>> -	its_base = ioremap(res.start, resource_size(&res));
>> +	its_base = ioremap(phys_base, size);
>>   	if (!its_base) {
>> -		pr_warn("%s: unable to map registers\n", node->full_name);
>> +		pr_warn("Unable to map ITS registers\n");
>
> There is some value in at least displaying the base address - think of
> people writing their DT or ACPI tables. Please do not blindly remove
> debugging information which is often useful on a system with multiple ITS.

Yes, base address is helpful with multi ITS.

>
>>   		return -ENOMEM;
>>   	}
>>
>>   	val = readl_relaxed(its_base + GITS_PIDR2) & GIC_PIDR2_ARCH_MASK;
>>   	if (val != 0x30 && val != 0x40) {
>> -		pr_warn("%s: no ITS detected, giving up\n", node->full_name);
>> +		pr_warn("No ITS detected, giving up\n");
>>   		err = -ENODEV;
>>   		goto out_unmap;
>>   	}
>>
>>   	err = its_force_quiescent(its_base);
>>   	if (err) {
>> -		pr_warn("%s: failed to quiesce, giving up\n",
>> -			node->full_name);
>> +		pr_warn("Failed to quiesce, giving up\n");
>>   		goto out_unmap;
>>   	}
>>
>> -	pr_info("ITS: %s\n", node->full_name);
>> +	pr_info("ITS at 0x%lx\n", (long)phys_base);
>>
>>   	its = kzalloc(sizeof(*its), GFP_KERNEL);
>>   	if (!its) {
>> @@ -1473,7 +1467,7 @@ static int __init its_probe(struct device_node *node,
>>   	INIT_LIST_HEAD(&its->entry);
>>   	INIT_LIST_HEAD(&its->its_device_list);
>>   	its->base = its_base;
>> -	its->phys_base = res.start;
>> +	its->phys_base = phys_base;
>>   	its->ite_size = ((readl_relaxed(its_base + GITS_TYPER) >> 4) & 0xf) + 1;
>>
>>   	its->cmd_base = kzalloc(ITS_CMD_QUEUE_SZ, GFP_KERNEL);
>> @@ -1485,7 +1479,7 @@ static int __init its_probe(struct device_node *node,
>>
>>   	its_enable_quirks(its);
>>
>> -	err = its_alloc_tables(node->full_name, its);
>> +	err = its_alloc_tables(its);
>>   	if (err)
>>   		goto out_free_cmd;
>>
>> @@ -1521,7 +1515,7 @@ static int __init its_probe(struct device_node *node,
>>   	writeq_relaxed(0, its->base + GITS_CWRITER);
>>   	writel_relaxed(GITS_CTLR_ENABLE, its->base + GITS_CTLR);
>>
>> -	if (of_property_read_bool(node, "msi-controller")) {
>> +	if (is_msi_controller) {
>>   		struct msi_domain_info *info;
>>
>>   		info = kzalloc(sizeof(*info), GFP_KERNEL);
>> @@ -1530,7 +1524,8 @@ static int __init its_probe(struct device_node *node,
>>   			goto out_free_tables;
>>   		}
>>
>> -		inner_domain = irq_domain_add_tree(node, &its_domain_ops, its);
>> +		inner_domain = irq_domain_create_tree(handler, &its_domain_ops,
>> +						      its);
>>   		if (!inner_domain) {
>>   			err = -ENOMEM;
>>   			kfree(info);
>> @@ -1558,10 +1553,28 @@ out_free_its:
>>   	kfree(its);
>>   out_unmap:
>>   	iounmap(its_base);
>> -	pr_err("ITS: failed probing %s (%d)\n", node->full_name, err);
>> +	pr_err("ITS at 0x%lx: failed probing (%d)\n", (long)phys_base, err);
>>   	return err;
>>   }
>>
>> +static int __init
>> +its_of_probe(struct device_node *node, struct irq_domain *parent)
>> +{
>> +	struct resource res;
>> +	bool is_msi_controller = false;
>> +
>> +	if (of_address_to_resource(node, 0, &res)) {
>> +		pr_warn("%s: no regs?\n", node->full_name);
>> +		return -ENXIO;
>> +	}
>> +
>> +	if (of_property_read_bool(node, "msi-controller"))
>> +		is_msi_controller = true;
>
> This is where you should return early, with a message saying that this
> ITS is being ignored if it doesn't have the msi-controller property.

Agree, will do.

Thanks,
Tomasz


From tn at semihalf.com  Fri Feb 12 02:14:46 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Fri, 12 Feb 2016 11:14:46 +0100
Subject: [PATCH V3 08/10] irqchip, gicv3, its: Probe ITS in the ACPI way.
In-Reply-To: <56BB22FB.5060609@arm.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
 <1453209083-3358-9-git-send-email-tn@semihalf.com> <56BB22FB.5060609@arm.com>
Message-ID: <56BDB096.6080907@semihalf.com>

On 10.02.2016 12:46, Marc Zyngier wrote:
> On 19/01/16 13:11, Tomasz Nowicki wrote:
>> Since we prepared ITS for being initialized different that via DT,
>> it is now possible to parse MADT and pass mandatory info to
>> firmware-agnostic ITS init call.
>>
>> Note that we are using here IORT lib to keep track of allocated
>> domain handler which will be used to build PCI MSI domain on top
>> in the later patches.
>>
>> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
>> Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
>> ---
>>   drivers/irqchip/irq-gic-v3-its.c | 57 +++++++++++++++++++++++++++++++++++++++-
>>   1 file changed, 56 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index fecb7a6..42f378a 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -15,10 +15,13 @@
>>    * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>    */
>>
>> +#include <linux/acpi.h>
>>   #include <linux/bitmap.h>
>>   #include <linux/cpu.h>
>>   #include <linux/delay.h>
>>   #include <linux/interrupt.h>
>> +#include <linux/irqdomain.h>
>> +#include <linux/iort.h>
>>   #include <linux/log2.h>
>>   #include <linux/mm.h>
>>   #include <linux/msi.h>
>> @@ -1272,6 +1275,11 @@ static int its_irq_gic_domain_alloc(struct irq_domain *domain,
>>   		fwspec.param[0] = GIC_IRQ_TYPE_LPI;
>>   		fwspec.param[1] = hwirq;
>>   		fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
>> +	} else if (is_fwnode_irqchip(domain->parent->fwnode)) {
>> +		fwspec.fwnode = domain->parent->fwnode;
>> +		fwspec.param_count = 2;
>> +		fwspec.param[0] = hwirq;
>> +		fwspec.param[1] = IRQ_TYPE_EDGE_RISING;
>>   	} else {
>>   		return -EINVAL;
>>   	}
>> @@ -1594,6 +1602,52 @@ int its_cpu_init(void)
>>   	return 0;
>>   }
>>
>> +#ifdef CONFIG_ACPI
>> +
>> +#define ACPI_GICV3_ITS_MEM_SIZE (2 * SZ_64K)
>> +
>> +static struct irq_domain *its_parent __initdata;
>> +
>> +static int __init
>> +gic_acpi_parse_madt_its(struct acpi_subtable_header *header,
>> +			const unsigned long end)
>> +{
>> +	struct acpi_madt_generic_translator *its_entry;
>> +	struct fwnode_handle *domain_handle;
>> +	int err;
>> +
>> +	its_entry = (struct acpi_madt_generic_translator *)header;
>> +	domain_handle = irq_domain_alloc_fwnode((void *)its_entry->base_address);
>> +	if (!domain_handle) {
>> +		pr_err("Unable to allocate GICv2m domain token\n");
>
> -ECOPYPASTE.
>
>> +		return -ENOMEM;
>> +	}
>> +
>> +	/* ITS works as msi controller in ACPI case */
>> +	err = its_probe_one(its_entry->base_address, ACPI_GICV3_ITS_MEM_SIZE,
>> +			    its_parent, true, domain_handle);
>> +	if (err) {
>> +		irq_domain_free_fwnode(domain_handle);
>> +		return err;
>> +	}
>> +	iort_register_domain_token(its_entry->translation_id, domain_handle);
>
> And what if this fails?
>
>> +	return 0;
>> +}
>> +
>> +void __init its_acpi_probe(struct irq_domain *parent_domain)
>> +{
>> +	int count;
>> +
>> +	its_parent = parent_domain;
>> +	count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
>> +				      gic_acpi_parse_madt_its, 0);
>> +	if (count <= 0)
>> +		pr_info("No valid GIC ITS entries exist\n");
>> +}
>> +#else
>> +static inline void __init its_acpi_probe(struct irq_domain *parent_domain) { }
>> +#endif
>> +
>>   static struct of_device_id its_device_id[] = {
>>   	{	.compatible	= "arm,gic-v3-its",	},
>>   	{},
>> @@ -1610,7 +1664,8 @@ int __init its_init(struct fwnode_handle *handle, struct rdists *rdists,
>>   		     np = of_find_matching_node(np, its_device_id)) {
>>   			its_of_probe(np, parent_domain);
>>   		}
>> -	}
>> +	} else
>> +		its_acpi_probe(parent_domain);
>
> Missing braces.
>

Right, I will address all your comments in the next ITS-only series.

Tomasz


From yamada.masahiro at socionext.com  Fri Feb 12 02:36:34 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 12 Feb 2016 19:36:34 +0900
Subject: [PATCH v2] serial: earlycon: rework common framework for earlycon
 declarations
Message-ID: <1455273394-27350-1-git-send-email-yamada.masahiro@socionext.com>

Commit 71f50c6d9a22 ("of: drop symbols declared by _OF_DECLARE() from
modules") fixed the link error introduced by commit b8d20e06eaad
("serial: 8250_uniphier: add earlycon support").

After commit 2eaa790989e0 ("earlycon: Use common framework for
earlycon declarations") was applied, the link error came back
because the commit reworked OF_EARLYCON_DECLARE() to not use
_OF_DECLARE().

This commit reworks OF_EARLYCON_DECLARE() again based on
_OF_DECLARE().  My motivations are:

 - Fix the link error in a generic way (without patching
   drivers/tty/serial/8250/8250_uniphier.c)

 - Delete struct earlycon_id.  This struct is re-inventing the wheel;
   the fields "name", "compatible", "setup" can be implemented in
   struct of_device_id as other frameworks do.

The difference between OF_EARLYCON_DECLARE() and other users of
_OF_DECLARE is that OF_EARLYCON_DECLARE() needs to fill the "name"
field of struct of_device_id.  To make it easier, a new macro
_OF_DECLARE_WITH_NAME() has been added.  It fills the "name" field
with the given argument.  On the other hand, _OF_DECLARE() sets it
to a null string; this is the same behavior as before.

Fixes: 2eaa790989e0 ("earlycon: Use common framework for earlycon declarations")
Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

I confirmed this patch can apply onto "next-20160212" tag of linux-next.

In order to apply it onto the "tty-next" branch of TTY subsytem,
Greg will have to pull v4.5-rc3 in.


Changes in v2:
  Minor updates of git-log
   - fix a typo framework/frameworks/).
   - s/Grag/Greg/   (Sorry!)

 drivers/of/fdt.c                  |  7 ++-----
 drivers/tty/serial/earlycon.c     | 19 +++++++++++++------
 include/asm-generic/vmlinux.lds.h | 12 ++----------
 include/linux/of.h                | 22 +++++++++++++++-------
 include/linux/serial_core.h       | 23 +++++++----------------
 5 files changed, 39 insertions(+), 44 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index e2295b2..ad262e9 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -802,7 +802,7 @@ static int __init early_init_dt_scan_chosen_serial(void)
 	int offset;
 	const char *p, *q, *options = NULL;
 	int l;
-	const struct earlycon_id *match;
+	const struct of_device_id *match;
 	const void *fdt = initial_boot_params;
 
 	offset = fdt_path_offset(fdt, "/chosen");
@@ -829,10 +829,7 @@ static int __init early_init_dt_scan_chosen_serial(void)
 		return 0;
 	}
 
-	for (match = __earlycon_table; match < __earlycon_table_end; match++) {
-		if (!match->compatible[0])
-			continue;
-
+	for (match = __earlycon_of_table; match->compatible[0]; match++) {
 		if (fdt_node_check_compatible(fdt, offset, match->compatible))
 			continue;
 
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 067783f..4888ced 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -38,6 +38,9 @@ static struct earlycon_device early_console_dev = {
 	.con = &early_con,
 };
 
+static const struct of_device_id __earlycon_of_table_sentinel
+	__used __section(__earlycon_of_table_end);
+
 static void __iomem * __init earlycon_map(unsigned long paddr, size_t size)
 {
 	void __iomem *base;
@@ -127,9 +130,10 @@ static int __init parse_options(struct earlycon_device *device, char *options)
 	return 0;
 }
 
-static int __init register_earlycon(char *buf, const struct earlycon_id *match)
+static int __init register_earlycon(char *buf, const struct of_device_id *match)
 {
 	int err;
+	int (*setup)(struct earlycon_device *, const char *options);
 	struct uart_port *port = &early_console_dev.port;
 
 	/* On parsing error, pass the options buf to the setup function */
@@ -142,7 +146,8 @@ static int __init register_earlycon(char *buf, const struct earlycon_id *match)
 		port->membase = earlycon_map(port->mapbase, 64);
 
 	earlycon_init(&early_console_dev, match->name);
-	err = match->setup(&early_console_dev, buf);
+	setup = match->data;
+	err = setup(&early_console_dev, buf);
 	if (err < 0)
 		return err;
 	if (!early_console_dev.con->write)
@@ -172,7 +177,7 @@ static int __init register_earlycon(char *buf, const struct earlycon_id *match)
  */
 int __init setup_earlycon(char *buf)
 {
-	const struct earlycon_id *match;
+	const struct of_device_id *match;
 
 	if (!buf || !buf[0])
 		return -EINVAL;
@@ -180,7 +185,7 @@ int __init setup_earlycon(char *buf)
 	if (early_con.flags & CON_ENABLED)
 		return -EALREADY;
 
-	for (match = __earlycon_table; match < __earlycon_table_end; match++) {
+	for (match = __earlycon_of_table; match->name[0]; match++) {
 		size_t len = strlen(match->name);
 
 		if (strncmp(buf, match->name, len))
@@ -220,12 +225,13 @@ early_param("earlycon", param_setup_earlycon);
 
 #ifdef CONFIG_OF_EARLY_FLATTREE
 
-int __init of_setup_earlycon(const struct earlycon_id *match,
+int __init of_setup_earlycon(const struct of_device_id *match,
 			     unsigned long node,
 			     const char *options)
 {
 	int err;
 	struct uart_port *port = &early_console_dev.port;
+	int (*setup)(struct earlycon_device *, const char *options);
 	const __be32 *val;
 	bool big_endian;
 	u64 addr;
@@ -273,7 +279,8 @@ int __init of_setup_earlycon(const struct earlycon_id *match,
 			sizeof(early_console_dev.options));
 	}
 	earlycon_init(&early_console_dev, match->name);
-	err = match->setup(&early_console_dev, options);
+	setup = match->data;
+	err = setup(&early_console_dev, options);
 	if (err < 0)
 		return err;
 	if (!early_console_dev.con->write)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index e9a81a6..699f4a5 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -153,15 +153,6 @@
 #define TRACE_SYSCALLS()
 #endif
 
-#ifdef CONFIG_SERIAL_EARLYCON
-#define EARLYCON_TABLE() STRUCT_ALIGN();			\
-			 VMLINUX_SYMBOL(__earlycon_table) = .;	\
-			 *(__earlycon_table)			\
-			 VMLINUX_SYMBOL(__earlycon_table_end) = .;
-#else
-#define EARLYCON_TABLE()
-#endif
-
 #define ___OF_TABLE(cfg, name)	_OF_TABLE_##cfg(name)
 #define __OF_TABLE(cfg, name)	___OF_TABLE(cfg, name)
 #define OF_TABLE(cfg, name)	__OF_TABLE(config_enabled(cfg), name)
@@ -179,6 +170,7 @@
 #define RESERVEDMEM_OF_TABLES()	OF_TABLE(CONFIG_OF_RESERVED_MEM, reservedmem)
 #define CPU_METHOD_OF_TABLES()	OF_TABLE(CONFIG_SMP, cpu_method)
 #define CPUIDLE_METHOD_OF_TABLES() OF_TABLE(CONFIG_CPU_IDLE, cpuidle_method)
+#define EARLYCON_OF_TABLES()	OF_TABLE(CONFIG_SERIAL_EARLYCON, earlycon)
 
 #ifdef CONFIG_ACPI
 #define ACPI_PROBE_TABLE(name)						\
@@ -525,7 +517,7 @@
 	IRQCHIP_OF_MATCH_TABLE()					\
 	ACPI_PROBE_TABLE(irqchip)					\
 	ACPI_PROBE_TABLE(clksrc)					\
-	EARLYCON_TABLE()
+	EARLYCON_OF_TABLES()
 
 #define INIT_TEXT							\
 	*(.init.text)							\
diff --git a/include/linux/of.h b/include/linux/of.h
index dc6e396..6e57245 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -930,19 +930,27 @@ static inline int of_get_available_child_count(const struct device_node *np)
 }
 
 #if defined(CONFIG_OF) && !defined(MODULE)
-#define _OF_DECLARE(table, name, compat, fn, fn_type)			\
-	static const struct of_device_id __of_table_##name		\
+#define __OF_DECLARE(table, name1, name2, compat, fn, fn_type)		\
+	static const struct of_device_id __UNIQUE_ID(__of_table_##name1)\
 		__used __section(__##table##_of_table)			\
-		 = { .compatible = compat,				\
+		 = { .name = name2,					\
+		     .compatible = compat,				\
 		     .data = (fn == (fn_type)NULL) ? fn : fn  }
 #else
-#define _OF_DECLARE(table, name, compat, fn, fn_type)			\
-	static const struct of_device_id __of_table_##name		\
+#define __OF_DECLARE(table, name1, name2, compat, fn, fn_type)		\
+	static const struct of_device_id __UNIQUE_ID(__of_table_##name1)\
 		__attribute__((unused))					\
-		 = { .compatible = compat,				\
-		     .data = (fn == (fn_type)NULL) ? fn : fn }
+		 = { .name = name2,					\
+		     .compatible = compat,				\
+		     .data = (fn == (fn_type)NULL) ? fn : fn  }
 #endif
 
+#define _OF_DECLARE(table, name, compat, fn, fn_type)	\
+	__OF_DECLARE(table, name, "", compat, fn, fn_type)
+
+#define _OF_DECLARE_WITH_NAME(table, name, compat, fn, fn_type)	\
+	__OF_DECLARE(table, name, __stringify(name), compat, fn, fn_type)
+
 typedef int (*of_init_fn_2)(struct device_node *, struct device_node *);
 typedef void (*of_init_fn_1)(struct device_node *);
 
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index cbfcf38..0f13160 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -24,6 +24,7 @@
 #include <linux/compiler.h>
 #include <linux/interrupt.h>
 #include <linux/circ_buf.h>
+#include <linux/mod_devicetable.h>
 #include <linux/spinlock.h>
 #include <linux/sched.h>
 #include <linux/tty.h>
@@ -340,26 +341,16 @@ struct earlycon_device {
 	unsigned int baud;
 };
 
-struct earlycon_id {
-	char	name[16];
-	char	compatible[128];
-	int	(*setup)(struct earlycon_device *, const char *options);
-} __aligned(32);
+extern const struct of_device_id __earlycon_of_table[];
 
-extern const struct earlycon_id __earlycon_table[];
-extern const struct earlycon_id __earlycon_table_end[];
+#define OF_EARLYCON_DECLARE(name, compat, fn)				\
+	_OF_DECLARE_WITH_NAME(earlycon, name, compat, fn, void *)
 
-#define OF_EARLYCON_DECLARE(_name, compat, fn)				\
-	static const struct earlycon_id __UNIQUE_ID(__earlycon_##_name)	\
-	     __used __section(__earlycon_table)				\
-		= { .name = __stringify(_name),				\
-		    .compatible = compat,				\
-		    .setup = fn  }
-
-#define EARLYCON_DECLARE(_name, fn)	OF_EARLYCON_DECLARE(_name, "", fn)
+#define EARLYCON_DECLARE(_name, fn)	\
+	OF_EARLYCON_DECLARE(_name, "-earlycon-dummy-compat-string-", fn)
 
 extern int setup_earlycon(char *buf);
-extern int of_setup_earlycon(const struct earlycon_id *match,
+extern int of_setup_earlycon(const struct of_device_id *match,
 			     unsigned long node,
 			     const char *options);
 
-- 
1.9.1



From yamada.masahiro at socionext.com  Fri Feb 12 02:38:42 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 12 Feb 2016 19:38:42 +0900
Subject: [PATCH v2 4/6] serial: 8250/uniphier: fix modular build
In-Reply-To: <3557175.oOjJgCHd2P@wuerfel>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
 <1455205297-1021302-5-git-send-email-arnd@arndb.de>
 <CAK7LNAR8fJWPubucjw28gAPpF-4yvVMWZZ0F3j6VN4whGF9Yhw@mail.gmail.com>
 <3557175.oOjJgCHd2P@wuerfel>
Message-ID: <CAK7LNATEhZuqkMaEONu7tDBzWnTqS527c0N0vuOKRJuPeeQSDA@mail.gmail.com>

Hi Arnd,


2016-02-12 19:07 GMT+09:00 Arnd Bergmann <arnd at arndb.de>:
> On Friday 12 February 2016 18:37:08 Masahiro Yamada wrote:
>> >  };
>> >
>> > -#ifdef CONFIG_SERIAL_8250_CONSOLE
>> > +#if defined(CONFIG_SERIAL_8250_CONSOLE) && !defined(MODULE)
>> >  static int __init uniphier_early_console_setup(struct earlycon_device *device,
>> >                                                const char *options)
>> >  {
>> > --
>> > 2.7.0
>> >
>>
>> I noticed commit 2eaa790989e03900298ad24f77f1086dbbc1aebd
>> revived this link error, but I am not happy with seeing
>> this patch again and again.
>>
>>
>> Can you check this patch?
>> https://patchwork.kernel.org/patch/8289231/
>>
>>
>>
>
> Yes, I think your patch is nicer than mine. Let's see what the others
> think, then I can resend my remaining patches on top of yours.

OK, thanks!

I noticed some typos, so I've posted v2.
(no change in code-diff).



-- 
Best Regards
Masahiro Yamada


From arnd at arndb.de  Fri Feb 12 02:42:34 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 11:42:34 +0100
Subject: [PATCH] net: phy: spi_ks8995: include linux/gpio/consumer.h
Message-ID: <1455273762-161477-1-git-send-email-arnd@arndb.de>

The ks8995 phy driver just started using gpiod_* functions, which are
declared in linux/gpio/consumer.h, not linux/gpio.h, resulting in a
build failure in randconfig builds that do not have CONFIG_GPIOLIB
enabled:

drivers/net/phy/spi_ks8995.c: In function 'ks8995_probe':
drivers/net/phy/spi_ks8995.c:477:3: error: implicit declaration of function 'gpiod_set_value' [-Werror=implicit-function-declaration]

This changes the header inclusion so it builds in all configurations.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: cd6f288cbaab ("net: phy: spi_ks8995: add support for resetting switch using GPIO")
---
 drivers/net/phy/spi_ks8995.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/spi_ks8995.c b/drivers/net/phy/spi_ks8995.c
index 5e7340f6b37c..b5d50d458728 100644
--- a/drivers/net/phy/spi_ks8995.c
+++ b/drivers/net/phy/spi_ks8995.c
@@ -18,8 +18,8 @@
 #include <linux/module.h>
 #include <linux/delay.h>
 #include <linux/device.h>
+#include <linux/gpio/consumer.h>
 #include <linux/of.h>
-#include <linux/gpio.h>
 #include <linux/of_gpio.h>
 
 #include <linux/spi/spi.h>
-- 
2.7.0



From kernel at martin.sperl.org  Fri Feb 12 03:14:25 2016
From: kernel at martin.sperl.org (kernel at martin.sperl.org)
Date: Fri, 12 Feb 2016 11:14:25 +0000
Subject: [PATCH] ARM: bcm2835: add bcm2835-aux-uart support to DT
Message-ID: <1455275666-15806-1-git-send-email-kernel@martin.sperl.org>

From: Martin Sperl <kernel at martin.sperl.org>

Add bcm2835-aux-uart support to the device tree.

Signed-off-by: Martin Sperl <kernel at martin.sperl.org>
---
 arch/arm/boot/dts/bcm283x.dtsi |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 05ff5ce..8aaf193 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -160,6 +160,14 @@
 			clocks = <&clocks BCM2835_CLOCK_VPU>;
 		};
 
+		uart1: serial at 7e215040 {
+			compatible = "brcm,bcm2835-aux-uart";
+			reg = <0x7e215040 0x40>;
+			interrupts = <1 29>;
+			clocks = <&aux BCM2835_AUX_CLOCK_UART>;
+			status = "disabled";
+		};
+
 		spi1: spi at 7e215080 {
 			compatible = "brcm,bcm2835-aux-spi";
 			reg = <0x7e215080 0x40>;
-- 
1.7.10.4



From arnd at arndb.de  Fri Feb 12 03:15:29 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 12:15:29 +0100
Subject: [PATCH] iio: adc/imx25-gcq: move incorrect do_div
Message-ID: <1455275748-999115-1-git-send-email-arnd@arndb.de>

The newly added driver uses do_div() to device a 32-bit number, which now
provokes a warning:

drivers/iio/adc/fsl-imx25-gcq.c: In function 'mx25_gcq_setup_cfgs':
include/asm-generic/div64.h:207:28: warning: comparison of distinct pointer types lacks a cast
  (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \

This replaces the do_div() call with a straight division operator.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 6df2e98c3ea5 ("iio: adc: Add imx25-gcq ADC driver")
---
 drivers/iio/adc/fsl-imx25-gcq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/adc/fsl-imx25-gcq.c b/drivers/iio/adc/fsl-imx25-gcq.c
index 2fd192735d5b..72b32c1ab257 100644
--- a/drivers/iio/adc/fsl-imx25-gcq.c
+++ b/drivers/iio/adc/fsl-imx25-gcq.c
@@ -233,7 +233,7 @@ static int mx25_gcq_setup_cfgs(struct platform_device *pdev,
 			priv->channel_vref_mv[reg] =
 				regulator_get_voltage(priv->vref[refp]);
 			/* Conversion from uV to mV */
-			do_div(priv->channel_vref_mv[reg], 1000);
+			priv->channel_vref_mv[reg] /= 1000;
 			break;
 		case MX25_ADC_REFP_INT:
 			priv->channel_vref_mv[reg] = 2500;
-- 
2.7.0



From jens.wiklander at linaro.org  Fri Feb 12 03:30:07 2016
From: jens.wiklander at linaro.org (Jens Wiklander)
Date: Fri, 12 Feb 2016 12:30:07 +0100
Subject: [PATCH v8 2/4] tee: generic TEE subsystem
In-Reply-To: <20160212045159.GQ17997@ZenIV.linux.org.uk>
References: <1455210877-15748-1-git-send-email-jens.wiklander@linaro.org>
 <1455210877-15748-3-git-send-email-jens.wiklander@linaro.org>
 <20160212045159.GQ17997@ZenIV.linux.org.uk>
Message-ID: <20160212113006.GA30447@ermac>

On Fri, Feb 12, 2016 at 04:51:59AM +0000, Al Viro wrote:
> On Thu, Feb 11, 2016 at 06:14:35PM +0100, Jens Wiklander wrote:
> 
> > +static int tee_ioctl_shm_alloc(struct tee_context *ctx,
> > +		struct tee_ioctl_shm_alloc_data __user *udata)
> > +{
> > +	long ret;
> > +	struct tee_ioctl_shm_alloc_data data;
> > +	struct tee_shm *shm;
> > +
> > +	if (copy_from_user(&data, udata, sizeof(data)))
> > +		return -EFAULT;
> > +
> > +	/* Currently no input flags are supported */
> > +	if (data.flags)
> > +		return -EINVAL;
> > +
> > +	data.fd = -1;
> > +
> > +	shm = tee_shm_alloc(ctx->teedev, data.size,
> > +			    TEE_SHM_MAPPED | TEE_SHM_DMA_BUF);
> > +	if (IS_ERR(shm))
> > +		return PTR_ERR(shm);
> > +
> > +	data.flags = shm->flags;
> > +	data.size = shm->size;
> > +	data.fd = tee_shm_get_fd(shm);
> > +	if (data.fd < 0) {
> > +		ret = data.fd;
> > +		goto err;
> > +	}
> > +
> > +	if (copy_to_user(udata, &data, sizeof(data))) {
> > +		ret = -EFAULT;
> > +		goto err;
> > +	}
> > +	/*
> > +	 * When user space closes the file descriptor the shared memory
> > +	 * should be freed
> > +	 */
> > +	tee_shm_put(shm);
> > +	return 0;
> > +err:
> > +	if (data.fd >= 0)
> > +		tee_shm_put_fd(data.fd);
> 
> This is completely broken.  Don't ever use that pattern.  Once something
> is in descriptor table, that's _it_.  You are already past the point of
> no return and there is no way to clean up.
> 
> In ABIs like that (and struct containing descriptor *is* a bad ABI design)
> solution is
> 	* allocate a descriptor
> 	* do everything that might fail, including copy_to_user()/put_user(),
> etc.
> 	* if failed, release unused descriptor and do fput(), if you already
> have a struct file reference that needs to be released.
> 	* FINALLY, when nothing no failures are possible, fd_install() the
> sucker in place.
> 
> And yes, dma_buf_fd() encourages that kind of braindamage.  It's tolerable
> only in one case - when we are about to return descriptor number directly
> as return value of syscall and really can't fail anymore.  Not the case
> here.

Thanks for the feedback, I'll change to return the descriptor in the
return value instead.

--
Jens


From will.deacon at arm.com  Fri Feb 12 03:49:08 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 12 Feb 2016 11:49:08 +0000
Subject: [PATCH v2 3/3] arm64: prevent __va() translations before
 memstart_addr is assigned
In-Reply-To: <1455209282-9596-4-git-send-email-ard.biesheuvel@linaro.org>
References: <1455209282-9596-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455209282-9596-4-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160212114908.GK25087@arm.com>

On Thu, Feb 11, 2016 at 05:48:02PM +0100, Ard Biesheuvel wrote:
> Just a hack to check whether all early __va() calls are gone.
> ---
>  arch/arm64/include/asm/memory.h | 10 +++++++++-
>  arch/arm64/mm/init.c            |  2 +-
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 083361531a61..0d4d1b3b9695 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -90,7 +90,9 @@
>  	__x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :	\
>  			     (__x - kimage_voffset); })
>  
> -#define __phys_to_virt(x)	((unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET))
> +#define __phys_to_virt(x) ({						\
> +	assert_memstart_addr_assigned();				\
> +	(unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET); })
>  #define __phys_to_kimg(x)	((unsigned long)((x) + kimage_voffset))
>  
>  /*
> @@ -133,6 +135,12 @@ extern u64			kimage_vaddr;
>  /* the offset between the kernel virtual and physical mappings */
>  extern u64			kimage_voffset;
>  
> +static inline void assert_memstart_addr_assigned(void)
> +{
> +	if (unlikely(memstart_addr == (phys_addr_t)-1))
> +		asm("brk #%0" :: "I"(0x800));

Ok, I'll bite! Why isn't this just a BUG_ON?

Will


From stefano.stabellini at eu.citrix.com  Fri Feb 12 03:50:24 2016
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Fri, 12 Feb 2016 11:50:24 +0000
Subject: [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen
In-Reply-To: <1667812.hY9vsC2epc@vostro.rjw.lan>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
 <44113385.2QnPtvxQx0@vostro.rjw.lan>
 <alpine.DEB.2.02.1602111557430.27008@kaball.uk.xensource.com>
 <1667812.hY9vsC2epc@vostro.rjw.lan>
Message-ID: <alpine.DEB.2.02.1602121138090.27008@kaball.uk.xensource.com>

On Thu, 11 Feb 2016, Rafael J. Wysocki wrote:
> On Thursday, February 11, 2016 04:04:14 PM Stefano Stabellini wrote:
> > On Wed, 10 Feb 2016, Rafael J. Wysocki wrote:
> > > On Tuesday, February 09, 2016 11:19:02 AM Stefano Stabellini wrote:
> > > > On Mon, 8 Feb 2016, Rafael J. Wysocki wrote:
> > > > > On Monday, February 08, 2016 10:57:01 AM Stefano Stabellini wrote:
> > > > > > On Sat, 6 Feb 2016, Rafael J. Wysocki wrote:
> > > > > > > On Fri, Feb 5, 2016 at 4:05 AM, Shannon Zhao <zhaoshenglong at huawei.com> wrote:
> > > > > > > > From: Shannon Zhao <shannon.zhao at linaro.org>
> > > > > > > >
> > > > > > > > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > > > > > > > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > > > > > > > UART is used by Xen. So here it hides UART from Dom0.
> > > > > > > >
> > > > > > > > Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> > > > > > > > Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> > > > > > > 
> > > > > > > Well, this doesn't look right to me.
> > > > > > > 
> > > > > > > We need to find a nicer way to achieve what you want.
> > > > > > 
> > > > > > I take that you are talking about how to honor the STAO table in Linux.
> > > > > > Do you have any concrete suggestions?
> > > > > 
> > > > > I do.
> > > > > 
> > > > > The last hunk of the patch is likely what it needs to be, although I'm
> > > > > not sure if the place it is added to is the right one.  That's a minor thing,
> > > > > though.
> > > > > 
> > > > > The other part is problematic.  Not that as it doesn't work, but because of
> > > > > how it works.  With these changes the device will be visible to the OS (in
> > > > > fact to user space even), but will never be "present".  I'm not sure if
> > > > > that's what you want?
> > > > > 
> > > > > It might be better to add a check to acpi_bus_type_and_status() that will
> > > > > evaluate the "should ignore?" thing and return -ENODEV if this is true.  This
> > > > > way the device won't be visible at all.
> > > > 
> > > > Something like below?  Actually your suggestion is better, thank you!
> > > > 
> > > > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > > > index 78d5f02..4778c51 100644
> > > > --- a/drivers/acpi/scan.c
> > > > +++ b/drivers/acpi/scan.c
> > > > @@ -1455,6 +1455,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> > > >  	if (ACPI_FAILURE(status))
> > > >  		return -ENODEV;
> > > >  
> > > > +	if (acpi_check_device_is_ignored(handle))
> > > > +		return -ENODEV;
> > > > +
> > > >  	switch (acpi_type) {
> > > >  	case ACPI_TYPE_ANY:		/* for ACPI_ROOT_OBJECT */
> > > >  	case ACPI_TYPE_DEVICE:
> > > > 
> > > 
> > > I thought about doing that under ACPI_TYPE_DEVICE, because it shouldn't be
> > > applicable to the other types.  But generally, yes.
> > 
> > I was pondering about it myself. Maybe an ACPI_TYPE_PROCESSOR object
> > could theoretically be hidden with the STAO?
> 
> But this patch won't check for it anyway, will it?
> 
> It seems to be only checking against the UART address or have I missed
> anything?

You are right, this patch only checks for the UART address, which is
critical.

However the STAO also has a "Name List" field with a list of paths in
ACPI namespace to hide. If not implementing proper "Name List" support,
at least, as part of this patch, it would be nice to check for the
presence of the Name List field in the table, and print a warning such
as "STAO Name List not yet supported" when the field is present.


From ard.biesheuvel at linaro.org  Fri Feb 12 03:51:40 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 12:51:40 +0100
Subject: [PATCH v2 3/3] arm64: prevent __va() translations before
 memstart_addr is assigned
In-Reply-To: <20160212114908.GK25087@arm.com>
References: <1455209282-9596-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455209282-9596-4-git-send-email-ard.biesheuvel@linaro.org>
 <20160212114908.GK25087@arm.com>
Message-ID: <CAKv+Gu_2xLeN+ySAhEBKh+NByjka_12HunprueV+ykE0njrgsw@mail.gmail.com>

On 12 February 2016 at 12:49, Will Deacon <will.deacon at arm.com> wrote:
> On Thu, Feb 11, 2016 at 05:48:02PM +0100, Ard Biesheuvel wrote:
>> Just a hack to check whether all early __va() calls are gone.
>> ---
>>  arch/arm64/include/asm/memory.h | 10 +++++++++-
>>  arch/arm64/mm/init.c            |  2 +-
>>  2 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index 083361531a61..0d4d1b3b9695 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -90,7 +90,9 @@
>>       __x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :        \
>>                            (__x - kimage_voffset); })
>>
>> -#define __phys_to_virt(x)    ((unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET))
>> +#define __phys_to_virt(x) ({                                         \
>> +     assert_memstart_addr_assigned();                                \
>> +     (unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET); })
>>  #define __phys_to_kimg(x)    ((unsigned long)((x) + kimage_voffset))
>>
>>  /*
>> @@ -133,6 +135,12 @@ extern u64                       kimage_vaddr;
>>  /* the offset between the kernel virtual and physical mappings */
>>  extern u64                   kimage_voffset;
>>
>> +static inline void assert_memstart_addr_assigned(void)
>> +{
>> +     if (unlikely(memstart_addr == (phys_addr_t)-1))
>> +             asm("brk #%0" :: "I"(0x800));
>
> Ok, I'll bite! Why isn't this just a BUG_ON?
>

Because circular header dependencies prevent BUG_ON() from being used
here, and I was reluctant to move this function into a .c file.

Note that I am not necessarily suggesting that this patch be merged,
but I included it since it's the code I used to confirm that no other
early instance of __va() remain. I can try and clean it up if we want
to keep it.

-- 
Ard.


From codekipper at gmail.com  Fri Feb 12 03:54:31 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Fri, 12 Feb 2016 12:54:31 +0100
Subject: [linux-sunxi][PATCH] ARM: dts: sun4i: Enable USB DRC on the MK8082
Message-ID: <1455278071-22339-1-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

Enable the otg/drc usb controller on the MK8082.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
 arch/arm/boot/dts/sun4i-a10-mk802.dts | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-mk802.dts b/arch/arm/boot/dts/sun4i-a10-mk802.dts
index ddf0683..ee46ea8 100644
--- a/arch/arm/boot/dts/sun4i-a10-mk802.dts
+++ b/arch/arm/boot/dts/sun4i-a10-mk802.dts
@@ -44,6 +44,7 @@
 #include "sun4i-a10.dtsi"
 #include "sunxi-common-regulators.dtsi"
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
 
 / {
 	model = "MK802";
@@ -84,7 +85,25 @@
 	status = "okay";
 };
 
+&otg_sram {
+	status = "okay";
+};
+
 &pio {
+	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
+		allwinner,pins = "PH4";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+
+	usb0_vbus_detect_pin: usb0_vbus_detect_pin at 0 {
+		allwinner,pins = "PH5";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+
 	usb2_vbus_pin_mk802: usb2_vbus_pin at 0 {
 		allwinner,pins = "PH12";
 		allwinner,function = "gpio_out";
@@ -93,6 +112,10 @@
 	};
 };
 
+&reg_usb0_vbus {
+	status = "okay";
+};
+
 &reg_usb1_vbus {
 	status = "okay";
 };
@@ -109,7 +132,17 @@
 	status = "okay";
 };
 
+&usb_otg {
+	dr_mode = "otg";
+	status = "okay";
+};
+
 &usbphy {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
+	usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+	usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+	usb0_vbus-supply = <&reg_usb0_vbus>;
 	usb1_vbus-supply = <&reg_usb1_vbus>;
 	usb2_vbus-supply = <&reg_usb2_vbus>;
 	status = "okay";
-- 
2.7.1



From martin at sperl.org  Fri Feb 12 03:56:09 2016
From: martin at sperl.org (Martin Sperl)
Date: Fri, 12 Feb 2016 12:56:09 +0100
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in
 console
In-Reply-To: <1617009200.323700.219000a8-c162-4594-aacc-a7e9894518b2.open-xchange@email.1und1.de>
References: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
 <56BC895E.2010108@sperl.org>
 <1617009200.323700.219000a8-c162-4594-aacc-a7e9894518b2.open-xchange@email.1und1.de>
Message-ID: <662D2FB2-B088-4CFC-8416-A4F35BBAD7DD@sperl.org>


> On 11.02.2016, at 18:55, Stefan Wahren <stefan.wahren at i2se.com> wrote:
> I think the reason for this behavior can be found in the uart-pl011 driver which
> plays with the clocks.
> 
I will look into the why and share what I find...

> According to the clock tree "plld" seems to be critical and shouldn't be
> disabled?

Then we may need to avoid this - but as far as I can tell
the amba-pl011 driver only disables the clock in error cases
(or when shutting down).
Maybe we just need to disable the shutdown of the plld?

>> Is this maybe related to the uart0_pclk, uart1_pclk, apb_pclk
>> clocks created and registered in bcm2835_init_clocks?
> 
> Related or not i think we should get the rid off them.

A quick test shows that an empty bcm2835_init_clocks
does not change the basic kernel-boot behavior and everything
seems to work.

So we probably should remove it in:
* arch/arm/mach-bcm/board_bcm2835.c (call)
* drivers/clk/bcm/clk-bcm2835.c (function definition)

Martin



From arnd at arndb.de  Fri Feb 12 03:55:21 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 12:55:21 +0100
Subject: [PATCH] ath9k: reduce stack usage in ar9003_aic_cal_post_process
Message-ID: <1455278130-1831694-1-git-send-email-arnd@arndb.de>

In some configurations, this function uses more than the warning limit
of 1024 bytes:

drivers/net/wireless/ath/ath9k/ar9003_aic.c: In function 'ar9003_aic_cal_post_process':
drivers/net/wireless/ath/ath9k/ar9003_aic.c:434:1: error: the frame size of 1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

It turns out that there are two large arrays on the stack here, but
almost all the data in them is never used outside of the loop in
which it gets written, so we can replace the array with a single
instance.

The .valid flag is used later, so I'm replacing the array of structures
with an array of bools. An obvious follow-up optimization would be
to replace it with a bitmask and set_bit()/find_first_bit()/
find_last_bit()/... operations. However, I have not tested this patch,
so I sticked to the simpler transformation that does the job of
reducing the stack usage to a harmless level.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/net/wireless/ath/ath9k/ar9003_aic.c | 79 +++++++++++++++--------------
 drivers/net/wireless/ath/ath9k/ar9003_aic.h |  1 -
 2 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9003_aic.c b/drivers/net/wireless/ath/ath9k/ar9003_aic.c
index 1db119d77783..547cd46da260 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_aic.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_aic.c
@@ -53,19 +53,19 @@ static bool ar9003_hw_is_aic_enabled(struct ath_hw *ah)
 	return true;
 }
 
-static int16_t ar9003_aic_find_valid(struct ath_aic_sram_info *cal_sram,
+static int16_t ar9003_aic_find_valid(bool *cal_sram_valid,
 				     bool dir, u8 index)
 {
 	int16_t i;
 
 	if (dir) {
 		for (i = index + 1; i < ATH_AIC_MAX_BT_CHANNEL; i++) {
-			if (cal_sram[i].valid)
+			if (cal_sram_valid[i])
 				break;
 		}
 	} else {
 		for (i = index - 1; i >= 0; i--) {
-			if (cal_sram[i].valid)
+			if (cal_sram_valid[i])
 				break;
 		}
 	}
@@ -264,7 +264,7 @@ static u8 ar9003_aic_cal_start(struct ath_hw *ah, u8 min_valid_count)
 static bool ar9003_aic_cal_post_process(struct ath_hw *ah)
 {
 	struct ath9k_hw_aic *aic = &ah->btcoex_hw.aic;
-	struct ath_aic_sram_info cal_sram[ATH_AIC_MAX_BT_CHANNEL];
+	bool cal_sram_valid[ATH_AIC_MAX_BT_CHANNEL];
 	struct ath_aic_out_info aic_sram[ATH_AIC_MAX_BT_CHANNEL];
 	u32 dir_path_gain_idx, quad_path_gain_idx, value;
 	u32 fixed_com_att_db;
@@ -272,33 +272,34 @@ static bool ar9003_aic_cal_post_process(struct ath_hw *ah)
 	int16_t i;
 	bool ret = true;
 
-	memset(&cal_sram, 0, sizeof(cal_sram));
+	memset(&cal_sram_valid, 0, sizeof(cal_sram_valid));
 	memset(&aic_sram, 0, sizeof(aic_sram));
 
 	for (i = 0; i < ATH_AIC_MAX_BT_CHANNEL; i++) {
+		struct ath_aic_sram_info sram;
 		value = aic->aic_sram[i];
 
-		cal_sram[i].valid =
+		cal_sram_valid[i] = sram.valid =
 			MS(value, AR_PHY_AIC_SRAM_VALID);
-		cal_sram[i].rot_quad_att_db =
+		sram.rot_quad_att_db =
 			MS(value, AR_PHY_AIC_SRAM_ROT_QUAD_ATT_DB);
-		cal_sram[i].vga_quad_sign =
+		sram.vga_quad_sign =
 			MS(value, AR_PHY_AIC_SRAM_VGA_QUAD_SIGN);
-		cal_sram[i].rot_dir_att_db =
+		sram.rot_dir_att_db =
 			MS(value, AR_PHY_AIC_SRAM_ROT_DIR_ATT_DB);
-		cal_sram[i].vga_dir_sign =
+		sram.vga_dir_sign =
 			MS(value, AR_PHY_AIC_SRAM_VGA_DIR_SIGN);
-		cal_sram[i].com_att_6db =
+		sram.com_att_6db =
 			MS(value, AR_PHY_AIC_SRAM_COM_ATT_6DB);
 
-		if (cal_sram[i].valid) {
-			dir_path_gain_idx = cal_sram[i].rot_dir_att_db +
-				com_att_db_table[cal_sram[i].com_att_6db];
-			quad_path_gain_idx = cal_sram[i].rot_quad_att_db +
-				com_att_db_table[cal_sram[i].com_att_6db];
+		if (sram.valid) {
+			dir_path_gain_idx = sram.rot_dir_att_db +
+				com_att_db_table[sram.com_att_6db];
+			quad_path_gain_idx = sram.rot_quad_att_db +
+				com_att_db_table[sram.com_att_6db];
 
-			dir_path_sign = (cal_sram[i].vga_dir_sign) ? 1 : -1;
-			quad_path_sign = (cal_sram[i].vga_quad_sign) ? 1 : -1;
+			dir_path_sign = (sram.vga_dir_sign) ? 1 : -1;
+			quad_path_sign = (sram.vga_quad_sign) ? 1 : -1;
 
 			aic_sram[i].dir_path_gain_lin = dir_path_sign *
 				aic_lin_table[dir_path_gain_idx];
@@ -310,16 +311,16 @@ static bool ar9003_aic_cal_post_process(struct ath_hw *ah)
 	for (i = 0; i < ATH_AIC_MAX_BT_CHANNEL; i++) {
 		int16_t start_idx, end_idx;
 
-		if (cal_sram[i].valid)
+		if (cal_sram_valid[i])
 			continue;
 
-		start_idx = ar9003_aic_find_valid(cal_sram, 0, i);
-		end_idx = ar9003_aic_find_valid(cal_sram, 1, i);
+		start_idx = ar9003_aic_find_valid(cal_sram_valid, 0, i);
+		end_idx = ar9003_aic_find_valid(cal_sram_valid, 1, i);
 
 		if (start_idx < 0) {
 			/* extrapolation */
 			start_idx = end_idx;
-			end_idx = ar9003_aic_find_valid(cal_sram, 1, start_idx);
+			end_idx = ar9003_aic_find_valid(cal_sram_valid, 1, start_idx);
 
 			if (end_idx < 0) {
 				ret = false;
@@ -342,7 +343,7 @@ static bool ar9003_aic_cal_post_process(struct ath_hw *ah)
 
 		if (end_idx < 0) {
 			/* extrapolation */
-			end_idx = ar9003_aic_find_valid(cal_sram, 0, start_idx);
+			end_idx = ar9003_aic_find_valid(cal_sram_valid, 0, start_idx);
 
 			if (end_idx < 0) {
 				ret = false;
@@ -378,19 +379,21 @@ static bool ar9003_aic_cal_post_process(struct ath_hw *ah)
 	}
 
 	/* From dir/quad_path_gain_lin to sram. */
-	i = ar9003_aic_find_valid(cal_sram, 1, 0);
+	i = ar9003_aic_find_valid(cal_sram_valid, 1, 0);
 	if (i < 0) {
 		i = 0;
 		ret = false;
 	}
-	fixed_com_att_db = com_att_db_table[cal_sram[i].com_att_6db];
+	fixed_com_att_db = com_att_db_table[MS(aic->aic_sram[i],
+					    AR_PHY_AIC_SRAM_COM_ATT_6DB)];
 
 	for (i = 0; i < ATH_AIC_MAX_BT_CHANNEL; i++) {
 		int16_t rot_dir_path_att_db, rot_quad_path_att_db;
+		struct ath_aic_sram_info sram;
 
-		aic_sram[i].sram.vga_dir_sign =
+		sram.vga_dir_sign =
 			(aic_sram[i].dir_path_gain_lin >= 0) ? 1 : 0;
-		aic_sram[i].sram.vga_quad_sign=
+		sram.vga_quad_sign =
 			(aic_sram[i].quad_path_gain_lin >= 0) ? 1 : 0;
 
 		rot_dir_path_att_db =
@@ -400,33 +403,31 @@ static bool ar9003_aic_cal_post_process(struct ath_hw *ah)
 			ar9003_aic_find_index(0, abs(aic_sram[i].quad_path_gain_lin)) -
 			fixed_com_att_db;
 
-		aic_sram[i].sram.com_att_6db =
+		sram.com_att_6db =
 			ar9003_aic_find_index(1, fixed_com_att_db);
 
-		aic_sram[i].sram.valid = 1;
+		sram.valid = 1;
 
-		aic_sram[i].sram.rot_dir_att_db =
+		sram.rot_dir_att_db =
 			min(max(rot_dir_path_att_db,
 				(int16_t)ATH_AIC_MIN_ROT_DIR_ATT_DB),
 			    ATH_AIC_MAX_ROT_DIR_ATT_DB);
-		aic_sram[i].sram.rot_quad_att_db =
+		sram.rot_quad_att_db =
 			min(max(rot_quad_path_att_db,
 				(int16_t)ATH_AIC_MIN_ROT_QUAD_ATT_DB),
 			    ATH_AIC_MAX_ROT_QUAD_ATT_DB);
-	}
 
-	for (i = 0; i < ATH_AIC_MAX_BT_CHANNEL; i++) {
-		aic->aic_sram[i] = (SM(aic_sram[i].sram.vga_dir_sign,
+		aic->aic_sram[i] = (SM(sram.vga_dir_sign,
 				       AR_PHY_AIC_SRAM_VGA_DIR_SIGN) |
-				    SM(aic_sram[i].sram.vga_quad_sign,
+				    SM(sram.vga_quad_sign,
 				       AR_PHY_AIC_SRAM_VGA_QUAD_SIGN) |
-				    SM(aic_sram[i].sram.com_att_6db,
+				    SM(sram.com_att_6db,
 				       AR_PHY_AIC_SRAM_COM_ATT_6DB) |
-				    SM(aic_sram[i].sram.valid,
+				    SM(sram.valid,
 				       AR_PHY_AIC_SRAM_VALID) |
-				    SM(aic_sram[i].sram.rot_dir_att_db,
+				    SM(sram.rot_dir_att_db,
 				       AR_PHY_AIC_SRAM_ROT_DIR_ATT_DB) |
-				    SM(aic_sram[i].sram.rot_quad_att_db,
+				    SM(sram.rot_quad_att_db,
 				       AR_PHY_AIC_SRAM_ROT_QUAD_ATT_DB));
 	}
 
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_aic.h b/drivers/net/wireless/ath/ath9k/ar9003_aic.h
index 86f40644be43..9512c63799f2 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_aic.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_aic.h
@@ -50,7 +50,6 @@ struct ath_aic_sram_info {
 struct ath_aic_out_info {
 	int16_t dir_path_gain_lin;
 	int16_t quad_path_gain_lin;
-	struct ath_aic_sram_info sram;
 };
 
 u8 ar9003_aic_calibration(struct ath_hw *ah);
-- 
2.7.0



From codekipper at gmail.com  Fri Feb 12 03:59:19 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Fri, 12 Feb 2016 12:59:19 +0100
Subject: [linux-sunxi][PATCH v2] ARM: dts: sun4i: Enable USB DRC on the MK802
Message-ID: <1455278359-22451-1-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

Enable the otg/drc usb controller on the MK802.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
Changes since v1:
- Corrected name of the device in subject & description.
---
 arch/arm/boot/dts/sun4i-a10-mk802.dts | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-mk802.dts b/arch/arm/boot/dts/sun4i-a10-mk802.dts
index ddf0683..ee46ea8 100644
--- a/arch/arm/boot/dts/sun4i-a10-mk802.dts
+++ b/arch/arm/boot/dts/sun4i-a10-mk802.dts
@@ -44,6 +44,7 @@
 #include "sun4i-a10.dtsi"
 #include "sunxi-common-regulators.dtsi"
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
 
 / {
 	model = "MK802";
@@ -84,7 +85,25 @@
 	status = "okay";
 };
 
+&otg_sram {
+	status = "okay";
+};
+
 &pio {
+	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
+		allwinner,pins = "PH4";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+
+	usb0_vbus_detect_pin: usb0_vbus_detect_pin at 0 {
+		allwinner,pins = "PH5";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+
 	usb2_vbus_pin_mk802: usb2_vbus_pin at 0 {
 		allwinner,pins = "PH12";
 		allwinner,function = "gpio_out";
@@ -93,6 +112,10 @@
 	};
 };
 
+&reg_usb0_vbus {
+	status = "okay";
+};
+
 &reg_usb1_vbus {
 	status = "okay";
 };
@@ -109,7 +132,17 @@
 	status = "okay";
 };
 
+&usb_otg {
+	dr_mode = "otg";
+	status = "okay";
+};
+
 &usbphy {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
+	usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+	usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+	usb0_vbus-supply = <&reg_usb0_vbus>;
 	usb1_vbus-supply = <&reg_usb1_vbus>;
 	usb2_vbus-supply = <&reg_usb2_vbus>;
 	status = "okay";
-- 
2.7.1



From gerald.schaefer at de.ibm.com  Fri Feb 12 03:59:43 2016
From: gerald.schaefer at de.ibm.com (Gerald Schaefer)
Date: Fri, 12 Feb 2016 12:59:43 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe
 also on PowerPC and ARM)
In-Reply-To: <87a8n6shf2.fsf@linux.vnet.ibm.com>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <87a8n6shf2.fsf@linux.vnet.ibm.com>
Message-ID: <20160212125943.1eb2ca9d@thinkpad>

On Fri, 12 Feb 2016 09:34:33 +0530
"Aneesh Kumar K.V" <aneesh.kumar at linux.vnet.ibm.com> wrote:

> Gerald Schaefer <gerald.schaefer at de.ibm.com> writes:
> 
> > On Thu, 11 Feb 2016 21:09:42 +0200
> > "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> >
> >> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> >> > Hi,
> >> > 
> >> > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> >> > he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
> >> > review of the THP rework patches, which cannot be bisected, revealed
> >> > commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
> >> > (and also similar commits for other archs).
> >> > 
> >> > This commit removes the THP splitting bit and also the architecture
> >> > implementation of pmdp_splitting_flush(), which took care of the IPI for
> >> > fast_gup serialization. The commit message says
> >> > 
> >> >     pmdp_splitting_flush() is not needed too: on splitting PMD we will do
> >> >     pmdp_clear_flush() + set_pte_at().  pmdp_clear_flush() will do IPI as
> >> >     needed for fast_gup
> >> > 
> >> > The assumption that a TLB flush will also produce an IPI is wrong on s390,
> >> > and maybe also on other architectures, and I thought that this was actually
> >> > the main reason for having an arch-specific pmdp_splitting_flush().
> >> > 
> >> > At least PowerPC and ARM also had an individual implementation of
> >> > pmdp_splitting_flush() that used kick_all_cpus_sync() instead of a TLB
> >> > flush to send the IPI, and those were also removed. Putting the arch
> >> > maintainers and mailing lists on cc to verify.
> >> > 
> >> > On s390 this will break the IPI serialization against fast_gup, which
> >> > would certainly explain the random kernel crashes, please revert or fix
> >> > the pmdp_splitting_flush() removal.
> >> 
> >> Sorry for that.
> >> 
> >> I believe, the problem was already addressed for PowerPC:
> >> 
> >> http://lkml.kernel.org/g/454980831-16631-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com
> >> 
> >> I think kick_all_cpus_sync() in arch-specific pmdp_invalidate() would do
> >> the trick, right?
> >
> > Hmm, not sure about that. After pmdp_invalidate(), a pmd_none() check in
> > fast_gup will still return false, because the pmd is not empty (at least
> > on s390).
> 
> Why can't we do this ? I did this for ppc64.
> 
>  void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
>  		     pmd_t *pmdp)
>  {
> -	pmd_hugepage_update(vma->vm_mm, address, pmdp, _PAGE_PRESENT, 0);
> +	pmd_hugepage_update(vma->vm_mm, address, pmdp, ~0UL, 0);
> 

Wouldn't that semantically change what pmdp_invalidate() was supposed to
do? The comment before the call says "the pmd_trans_huge and
pmd_trans_splitting must remain set at all times on the pmd". So, after
removing pmd_trans_splitting, it seems to be necessary to at least keep
pmd_trans_huge set.

In your case, the pmd would be completely cleared, which may help to find
it in fast_gup with pmd_none(), but I'm not sure if this would open up
other problems, e.g. with concurrent page faults. But I must also admit that
my THP overview got a little rusty.

> >So I don't see spontaneously how it will help fast_gup to break
> > out to the slow path in case of THP splitting.
> >
> >> 
> >> If yes, I'll prepare patch tomorrow (some sleep required).
> >> 
> >
> > We'll check if adding kick_all_cpus_sync() to pmdp_invalidate() helps.
> > It would also be good if Martin has a look at this, he'll return on
> > Monday.
> 
> -aneesh
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-s390" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



From codekipper at gmail.com  Fri Feb 12 04:00:18 2016
From: codekipper at gmail.com (Code Kipper)
Date: Fri, 12 Feb 2016 13:00:18 +0100
Subject: [linux-sunxi][PATCH] ARM: dts: sun4i: Enable USB DRC on the MK8082
In-Reply-To: <1455278071-22339-1-git-send-email-codekipper@gmail.com>
References: <1455278071-22339-1-git-send-email-codekipper@gmail.com>
Message-ID: <CAEKpxBkVmxLdm1VKosSyCtgghoV2ba-jyxxaz-TmccSpziAF9Q@mail.gmail.com>

NAK...doohhh got the name of the device wrong in both subject and
description. V2 sent.

On 12 February 2016 at 12:54,  <codekipper at gmail.com> wrote:
> From: Marcus Cooper <codekipper at gmail.com>
>
> Enable the otg/drc usb controller on the MK8082.
>
> Signed-off-by: Marcus Cooper <codekipper at gmail.com>
> ---
>  arch/arm/boot/dts/sun4i-a10-mk802.dts | 33 +++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10-mk802.dts b/arch/arm/boot/dts/sun4i-a10-mk802.dts
> index ddf0683..ee46ea8 100644
> --- a/arch/arm/boot/dts/sun4i-a10-mk802.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-mk802.dts
> @@ -44,6 +44,7 @@
>  #include "sun4i-a10.dtsi"
>  #include "sunxi-common-regulators.dtsi"
>  #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>
>  / {
>         model = "MK802";
> @@ -84,7 +85,25 @@
>         status = "okay";
>  };
>
> +&otg_sram {
> +       status = "okay";
> +};
> +
>  &pio {
> +       usb0_id_detect_pin: usb0_id_detect_pin at 0 {
> +               allwinner,pins = "PH4";
> +               allwinner,function = "gpio_in";
> +               allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +               allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +       };
> +
> +       usb0_vbus_detect_pin: usb0_vbus_detect_pin at 0 {
> +               allwinner,pins = "PH5";
> +               allwinner,function = "gpio_in";
> +               allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +               allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +       };
> +
>         usb2_vbus_pin_mk802: usb2_vbus_pin at 0 {
>                 allwinner,pins = "PH12";
>                 allwinner,function = "gpio_out";
> @@ -93,6 +112,10 @@
>         };
>  };
>
> +&reg_usb0_vbus {
> +       status = "okay";
> +};
> +
>  &reg_usb1_vbus {
>         status = "okay";
>  };
> @@ -109,7 +132,17 @@
>         status = "okay";
>  };
>
> +&usb_otg {
> +       dr_mode = "otg";
> +       status = "okay";
> +};
> +
>  &usbphy {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
> +       usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
> +       usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
> +       usb0_vbus-supply = <&reg_usb0_vbus>;
>         usb1_vbus-supply = <&reg_usb1_vbus>;
>         usb2_vbus-supply = <&reg_usb2_vbus>;
>         status = "okay";
> --
> 2.7.1
>


From ard.biesheuvel at linaro.org  Fri Feb 12 04:06:43 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 13:06:43 +0100
Subject: [PATCH v2] ARM: vmlinux-xip.lds: assert that ROM and RAM don't overlap
Message-ID: <1455278803-27679-1-git-send-email-ard.biesheuvel@linaro.org>

When building an XIP kernel, the linker produces two disjoint VMA regions,
where the first is mapped onto ROM and the second onto RAM. For this reason,
the linker output pointer '.' is updated halfway through the linker script,
and set to a value that corresponds with the start of the RAM region.

However, in some cases, the ROM region exceeds the expected size, and the
assignment of the output pointer results in a decrement rather than an
increment, causing the virtual addresses of the .data region to clash with
the .text region. Such a kernel cannot boot normally, but it also confuses
the hell out of kallsyms, since .data symbols may appear inside the
[_stext, _etext] or [_sinittext, _einittext] intervals in the first pass,
but not in the second (or vice versa), resulting in inconsistent kallsyms
data.

So let's make sure that the output pointer only advances, and never jumps
back into the ROM region.

Cc: Chris Brandt <Chris.Brandt at renesas.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
v2: rebased onto the split off XIP linker script

 arch/arm/kernel/vmlinux-xip.lds.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
index 40bc4cadb959..07c642cff50e 100644
--- a/arch/arm/kernel/vmlinux-xip.lds.S
+++ b/arch/arm/kernel/vmlinux-xip.lds.S
@@ -213,6 +213,7 @@ SECTIONS
 
 	_exiprom = .;			/* End of XIP ROM area */
 	__data_loc = ALIGN(4);		/* location in binary */
+	ASSERT(. < PAGE_OFFSET + TEXT_OFFSET, "XIP_KERNEL: ROM and RAM overlap")
 	. = PAGE_OFFSET + TEXT_OFFSET;
 
 	.data : AT(__data_loc) {
-- 
2.5.0



From arnd at arndb.de  Fri Feb 12 04:04:40 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 13:04:40 +0100
Subject: [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
Message-ID: <1455278707-2008263-1-git-send-email-arnd@arndb.de>

The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:

drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'

This changes the dependencies of XEN_FBDEV_FRONTEND so it cannot be
built-in if CONFIG_INPUT=m && CONFIG_INPUT_MISC=y, as that would result
in the broken select.

As usual, we would be much better off without the 'select', but removing
it now would likely break existing user configurations that depend on
it, so this adds another hack on top to get it working.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
---
 drivers/video/fbdev/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8ea45a5cd806..fd3d6fd290a9 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2241,6 +2241,7 @@ config FB_VIRTUAL
 config XEN_FBDEV_FRONTEND
 	tristate "Xen virtual frame buffer support"
 	depends on FB && XEN
+	depends on INPUT || !INPUT_MISC
 	select FB_SYS_FILLRECT
 	select FB_SYS_COPYAREA
 	select FB_SYS_IMAGEBLIT
-- 
2.7.0



From will.deacon at arm.com  Fri Feb 12 04:08:58 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 12 Feb 2016 12:08:58 +0000
Subject: [PATCH 4/3] iommu/io-pgtable: Rationalise quirk handling
In-Reply-To: <ea1f3d3feec0dc9c18d43393678370b50b1275f5.1455206840.git.robin.murphy@arm.com>
References: <cover.1453723096.git.robin.murphy@arm.com>
 <066c4af0e29c9cc658bd5e48edc5e2d7ba7140a1.1453723096.git.robin.murphy@arm.com>
 <20160210154815.GO1052@arm.com>
 <ea1f3d3feec0dc9c18d43393678370b50b1275f5.1455206840.git.robin.murphy@arm.com>
Message-ID: <20160212120857.GN25087@arm.com>

On Thu, Feb 11, 2016 at 04:13:45PM +0000, Robin Murphy wrote:
> As the number of io-pgtable implementations grows beyond 1, it's time
> to rationalise the quirks mechanism before things have a chance to
> start getting really ugly and out-of-hand.
> 
> To that end:
> - Indicate exactly which quirks each format can/does support.
> - Fail creating a table if a caller wants unsupported quirks.
> - Properly document where each quirk applies and why.
> 
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
>  drivers/iommu/io-pgtable-arm-v7s.c |  3 +++
>  drivers/iommu/io-pgtable-arm.c     |  2 ++
>  drivers/iommu/io-pgtable.c         |  3 +++
>  drivers/iommu/io-pgtable.h         | 24 ++++++++++++++++++++----
>  4 files changed, 28 insertions(+), 4 deletions(-)

Note that I can't merge this until we've figured out the plan for Yong's
driver.

> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
> index d39a021..9bc607a 100644
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> @@ -690,6 +690,9 @@ out_free_data:
>  struct io_pgtable_init_fns io_pgtable_arm_v7s_init_fns = {
>  	.alloc	= arm_v7s_alloc_pgtable,
>  	.free	= arm_v7s_free_pgtable,
> +	.supported_quirks = IO_PGTABLE_QUIRK_ARM_NS |
> +			    IO_PGTABLE_QUIRK_NO_PERMS |
> +			    IO_PGTABLE_QUIRK_TLBI_ON_MAP,
>  };
>  
>  #ifdef CONFIG_IOMMU_IO_PGTABLE_ARMV7S_SELFTEST
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 4095af2..32f94f1 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -863,6 +863,7 @@ arm_32_lpae_alloc_pgtable_s2(struct io_pgtable_cfg *cfg, void *cookie)
>  struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s1_init_fns = {
>  	.alloc	= arm_64_lpae_alloc_pgtable_s1,
>  	.free	= arm_lpae_free_pgtable,
> +	.supported_quirks = IO_PGTABLE_QUIRK_ARM_NS,
>  };
>  
>  struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s2_init_fns = {
> @@ -873,6 +874,7 @@ struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s2_init_fns = {
>  struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s1_init_fns = {
>  	.alloc	= arm_32_lpae_alloc_pgtable_s1,
>  	.free	= arm_lpae_free_pgtable,
> +	.supported_quirks = IO_PGTABLE_QUIRK_ARM_NS,
>  };
>  
>  struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s2_init_fns = {
> diff --git a/drivers/iommu/io-pgtable.c b/drivers/iommu/io-pgtable.c
> index 876f6a7..0f57a45 100644
> --- a/drivers/iommu/io-pgtable.c
> +++ b/drivers/iommu/io-pgtable.c
> @@ -52,6 +52,9 @@ struct io_pgtable_ops *alloc_io_pgtable_ops(enum io_pgtable_fmt fmt,
>  	if (!fns)
>  		return NULL;
>  
> +	if (cfg->quirks & ~fns->supported_quirks)
> +		return NULL;
> +
>  	iop = fns->alloc(cfg, cookie);
>  	if (!iop)
>  		return NULL;
> diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
> index 4faee7d..6e7f11e 100644
> --- a/drivers/iommu/io-pgtable.h
> +++ b/drivers/iommu/io-pgtable.h
> @@ -47,10 +47,24 @@ struct iommu_gather_ops {
>   *                 page table walker.
>   */
>  struct io_pgtable_cfg {
> -	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0) /* Set NS bit in PTEs */
> -	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1) /* No AP/XN bits */
> -	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2) /* TLB Inv. on map */
> -	int				quirks;
> +	/*
> +	 * IO_PGTABLE_QUIRK_ARM_NS: (ARM formats) Set NS and NSTABLE bits in
> +	 *	stage 1 PTEs, for hardware which insists on validating them
> +	 *	even in	non-secure state where they should normally be ignored.
> +	 *
> +	 * IO_PGTABLE_QUIRK_NO_PERMS: Ignore the IOMMU_READ, IOMMU_WRITE and
> +	 *	IOMMU_NOEXEC flags and map everything with full access, for
> +	 *	hardware which does not implement the permissions of a given
> +	 *	format, and/or requires some format-specific default value.
> +	 *
> +	 * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching invalid
> +	 *	(unmapped) entries but the hardware might do so anyway, perform
> +	 *	TLB maintenance when mapping as well as when unmapping.
> +	 */

Much better, cheers.

> +	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
> +	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
> +	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2)
> +	unsigned int			quirks;

Let's just make this unsigned long.

>  	unsigned long			pgsize_bitmap;
>  	unsigned int			ias;
>  	unsigned int			oas;
> @@ -173,10 +187,12 @@ static inline void io_pgtable_tlb_sync(struct io_pgtable *iop)
>   *
>   * @alloc: Allocate a set of page tables described by cfg.
>   * @free:  Free the page tables associated with iop.
> + * @supported_quirks: Bitmap of quirks supported by the format.
>   */
>  struct io_pgtable_init_fns {
>  	struct io_pgtable *(*alloc)(struct io_pgtable_cfg *cfg, void *cookie);
>  	void (*free)(struct io_pgtable *iop);
> +	unsigned int supported_quirks;
>  };

My only gripe here is that this is supposed to be a struct of function
pointers... get_supported_quirks() ?

Will


From arnd at arndb.de  Fri Feb 12 04:09:50 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 13:09:50 +0100
Subject: [PATCH v2 3/3] arm64: prevent __va() translations before
 memstart_addr is assigned
In-Reply-To: <CAKv+Gu_2xLeN+ySAhEBKh+NByjka_12HunprueV+ykE0njrgsw@mail.gmail.com>
References: <1455209282-9596-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160212114908.GK25087@arm.com>
 <CAKv+Gu_2xLeN+ySAhEBKh+NByjka_12HunprueV+ykE0njrgsw@mail.gmail.com>
Message-ID: <2388983.RePUKvokN0@wuerfel>

On Friday 12 February 2016 12:51:40 Ard Biesheuvel wrote:
> >> @@ -133,6 +135,12 @@ extern u64                       kimage_vaddr;
> >>  /* the offset between the kernel virtual and physical mappings */
> >>  extern u64                   kimage_voffset;
> >>
> >> +static inline void assert_memstart_addr_assigned(void)
> >> +{
> >> +     if (unlikely(memstart_addr == (phys_addr_t)-1))
> >> +             asm("brk #%0" :: "I"(0x800));
> >
> > Ok, I'll bite! Why isn't this just a BUG_ON?
> >
> 
> Because circular header dependencies prevent BUG_ON() from being used
> here, and I was reluctant to move this function into a .c file.

Maybe it works if you make assert_memstart_addr_assigned() a macro as well?

	Arnd


From sebott at linux.vnet.ibm.com  Fri Feb 12 04:21:46 2016
From: sebott at linux.vnet.ibm.com (Sebastian Ott)
Date: Fri, 12 Feb 2016 13:21:46 +0100 (CET)
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160211191253.GA8589@black.fi.intel.com>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211191253.GA8589@black.fi.intel.com>
Message-ID: <alpine.LFD.2.20.1602121318080.1773@schleppi>

On Thu, 11 Feb 2016, Kirill A. Shutemov wrote:
> On Thu, Feb 11, 2016 at 09:09:42PM +0200, Kirill A. Shutemov wrote:
> > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > > Hi,
> > > 
> > > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> > > he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
> > > review of the THP rework patches, which cannot be bisected, revealed
> > > commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
> > > (and also similar commits for other archs).
> > > 
> > > This commit removes the THP splitting bit and also the architecture
> > > implementation of pmdp_splitting_flush(), which took care of the IPI for
> > > fast_gup serialization. The commit message says
> > > 
> > >     pmdp_splitting_flush() is not needed too: on splitting PMD we will do
> > >     pmdp_clear_flush() + set_pte_at().  pmdp_clear_flush() will do IPI as
> > >     needed for fast_gup
> > > 
> > > The assumption that a TLB flush will also produce an IPI is wrong on s390,
> > > and maybe also on other architectures, and I thought that this was actually
> > > the main reason for having an arch-specific pmdp_splitting_flush().
> > > 
> > > At least PowerPC and ARM also had an individual implementation of
> > > pmdp_splitting_flush() that used kick_all_cpus_sync() instead of a TLB
> > > flush to send the IPI, and those were also removed. Putting the arch
> > > maintainers and mailing lists on cc to verify.
> > > 
> > > On s390 this will break the IPI serialization against fast_gup, which
> > > would certainly explain the random kernel crashes, please revert or fix
> > > the pmdp_splitting_flush() removal.
> > 
> > Sorry for that.
> > 
> > I believe, the problem was already addressed for PowerPC:
> > 
> > http://lkml.kernel.org/g/454980831-16631-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com
> 
> Correct link is
> 
> http://lkml.kernel.org/g/1454980831-16631-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com
> 

Based on your suggestion Gerald provided the following patch but sadly it
didn't fix the problem.

Sebastian


---
 arch/s390/include/asm/pgtable.h |    2 ++
 1 file changed, 2 insertions(+)

--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1587,6 +1587,8 @@ static inline void pmdp_invalidate(struc
 				   unsigned long address, pmd_t *pmdp)
 {
 	pmdp_flush_direct(vma->vm_mm, address, pmdp);
+	/* Serialize against fast_gup with IPI */
+	kick_all_cpus_sync();
 }

 #define __HAVE_ARCH_PMDP_SET_WRPROTECT



From maitysanchayan at gmail.com  Fri Feb 12 04:23:00 2016
From: maitysanchayan at gmail.com (Sanchayan Maity)
Date: Fri, 12 Feb 2016 17:53:00 +0530
Subject: [PATCH v2] ARM: dts: vfxxx: Add iio_hwmon node for ADC temperature
 channel
Message-ID: <cd32f1664a04b38b8a025414d039bd015cb9a5ff.1455278754.git.maitysanchayan@gmail.com>

Add iio_hwmon node to expose the temperature channel on Vybrid as
hardware monitor device using the iio_hwmon driver.

Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
---

Hello,

The first version of the patch was send quite a while ago.
https://lkml.org/lkml/2015/9/16/932

Shawn you had requested that hyphen rather than underscore should
be used in node name. I looked into that.

The iio_hwmon driver calls hwmon_device register_with_groups inside
hwmon.c and this
http://lxr.free-electrons.com/source/drivers/hwmon/hwmon.c#L103

does not allow hyphen in hwmon name attribute. I was not aware of
this but while trying to test the change, the device probe failed
with EINVAL. I think we should stick to the existing use of the
bindings or we need to change the hwmon code as well along with the
existing device tree files and binding documentation.

Changes since v1:
1. Expose ADC1 temperature channel as well
2. Move the entry outside of the aips1 bus node

Best Regards,
Sanchayan Maity.
---
 arch/arm/boot/dts/vfxxx.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index a5f07e3..8ed8e47 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -673,5 +673,10 @@
 				status = "disabled";
 			};
 		};
+
+		iio_hwmon {
+			compatible = "iio-hwmon";
+			io-channels = <&adc0 16>, <&adc1 16>;
+		};
 	};
 };
-- 
2.7.1



From tn at semihalf.com  Fri Feb 12 04:26:55 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Fri, 12 Feb 2016 13:26:55 +0100
Subject: [PATCH V3 10/10] acpi, gicv3, its: Use MADT ITS subtable to do
 PCI/MSI domain initialization.
In-Reply-To: <56BB26E5.6060703@arm.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
 <1453209083-3358-11-git-send-email-tn@semihalf.com>
 <56BB26E5.6060703@arm.com>
Message-ID: <56BDCF8F.1080208@semihalf.com>

+ Charles

On 10.02.2016 13:02, Marc Zyngier wrote:
> On 19/01/16 13:11, Tomasz Nowicki wrote:
>> After refactoring DT code, we let ACPI to build ITS PCI MSI domain
>> and do requester ID to device ID translation using IORT table.
>>
>> We have now full PCI MSI domain stack, thus we can enable ITS initialization
>> from GICv3 core driver for ACPI scenario.
>>
>> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
>> ---
>>   drivers/irqchip/irq-gic-v3-its-pci-msi.c | 44 +++++++++++++++++++++++++++++++-
>>   drivers/irqchip/irq-gic-v3.c             |  3 +--
>>   drivers/pci/msi.c                        |  3 +++
>>   3 files changed, 47 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
>> index 06165cb..7f0a958 100644
>> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
>> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
>> @@ -15,6 +15,8 @@
>>    * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>    */
>>
>> +#include <linux/acpi.h>
>> +#include <linux/iort.h>
>>   #include <linux/msi.h>
>>   #include <linux/of.h>
>>   #include <linux/of_irq.h>
>> @@ -143,10 +145,50 @@ static int __init its_pci_of_msi_init(void)
>>   	return 0;
>>   }
>>
>> +#ifdef CONFIG_ACPI
>> +
>> +static int __init
>> +its_pci_msi_parse_madt(struct acpi_subtable_header *header,
>> +		    const unsigned long end)
>> +{
>> +	struct acpi_madt_generic_translator *its_entry;
>> +	struct fwnode_handle *domain_handle;
>> +
>> +	its_entry = (struct acpi_madt_generic_translator *)header;
>> +	domain_handle = iort_find_its_domain_token(its_entry->translation_id);
>> +	if (!domain_handle) {
>> +		pr_err("ITS at 0x%lx: Unable to locate ITS domain handle\n",
>> +		       (long)its_entry->base_address);
>> +		return 0;
>> +	}
>> +
>> +	if (its_pci_msi_init_one(domain_handle))
>> +		return 0;
>> +
>> +	pci_msi_register_fwnode_provider(&iort_find_pci_domain_token);
>
> I'm a bit worried by this. You are registering this for each and every
> ITS that gets probed (useless, but why not). But also, you're using a
> hook that is designed to work at the bus level, without caring for the
> actual PCI devices. That's fine for something like GICv2m, which exposes
> a single domain, but I can't picture how this works when you have
> devices sitting behind a single RC that talk to different ITSs.
>
> My understanding is that IORT was behaving in a similar way the msi-map
> property works, so I'm a bit puzzled here.
>
> Can you please shed some light on that?
>

I see your point now. It is possible to describe such case in IORT, for 
example:

********************************************
RC0 node:
---------------
Mapping 0:
<input ID range> -> <output ID range>
<0:100> -> <0:100>
parent -> ITS0
---------------
Mapping 1:
<input ID range> -> <output ID range>
<101:200> -> <101:200>
parent -> ITS1
---------------
********************************************

So for this scenario I cannot use pci_host_bridge_acpi_msi_domain() to 
find IRQ domain based on bus device (unless there is only one ITS bound 
to e.g. RC), I should rather add ACPI implementation to 
pci_msi_get_device_domain on per-device MSI basis. Do you agree?

BTW. I should have put IORT specification link to changelog:
http://infocenter.arm.com/help/topic/com.arm.doc.den0049a/DEN0049A_IO_Remapping_Table.pdf

Thanks,
Tomasz


From laurent.pinchart at ideasonboard.com  Fri Feb 12 04:32:43 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 12 Feb 2016 14:32:43 +0200
Subject: [PATCH 4/3] iommu/io-pgtable: Rationalise quirk handling
In-Reply-To: <20160212120857.GN25087@arm.com>
References: <cover.1453723096.git.robin.murphy@arm.com>
 <ea1f3d3feec0dc9c18d43393678370b50b1275f5.1455206840.git.robin.murphy@arm.com>
 <20160212120857.GN25087@arm.com>
Message-ID: <4282853.vdxKI5JT5z@avalon>

On Friday 12 February 2016 12:08:58 Will Deacon wrote:
> On Thu, Feb 11, 2016 at 04:13:45PM +0000, Robin Murphy wrote:
> > As the number of io-pgtable implementations grows beyond 1, it's time
> > to rationalise the quirks mechanism before things have a chance to
> > start getting really ugly and out-of-hand.
> > 
> > To that end:
> > - Indicate exactly which quirks each format can/does support.
> > - Fail creating a table if a caller wants unsupported quirks.
> > - Properly document where each quirk applies and why.
> > 
> > Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> > ---
> > 
> >  drivers/iommu/io-pgtable-arm-v7s.c |  3 +++
> >  drivers/iommu/io-pgtable-arm.c     |  2 ++
> >  drivers/iommu/io-pgtable.c         |  3 +++
> >  drivers/iommu/io-pgtable.h         | 24 ++++++++++++++++++++----
> >  4 files changed, 28 insertions(+), 4 deletions(-)
> 
> Note that I can't merge this until we've figured out the plan for Yong's
> driver.
> 
> > diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
> > b/drivers/iommu/io-pgtable-arm-v7s.c index d39a021..9bc607a 100644
> > --- a/drivers/iommu/io-pgtable-arm-v7s.c
> > +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> > 
> > @@ -690,6 +690,9 @@ out_free_data:
> >  struct io_pgtable_init_fns io_pgtable_arm_v7s_init_fns = {
> >  
> >  	.alloc	= arm_v7s_alloc_pgtable,
> >  	.free	= arm_v7s_free_pgtable,
> > 
> > +	.supported_quirks = IO_PGTABLE_QUIRK_ARM_NS |
> > +			    IO_PGTABLE_QUIRK_NO_PERMS |
> > +			    IO_PGTABLE_QUIRK_TLBI_ON_MAP,
> > 
> >  };
> >  
> >  #ifdef CONFIG_IOMMU_IO_PGTABLE_ARMV7S_SELFTEST
> > 
> > diff --git a/drivers/iommu/io-pgtable-arm.c
> > b/drivers/iommu/io-pgtable-arm.c index 4095af2..32f94f1 100644
> > --- a/drivers/iommu/io-pgtable-arm.c
> > +++ b/drivers/iommu/io-pgtable-arm.c
> > @@ -863,6 +863,7 @@ arm_32_lpae_alloc_pgtable_s2(struct io_pgtable_cfg
> > *cfg, void *cookie)> 
> >  struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s1_init_fns = {
> >  
> >  	.alloc	= arm_64_lpae_alloc_pgtable_s1,
> >  	.free	= arm_lpae_free_pgtable,
> > 
> > +	.supported_quirks = IO_PGTABLE_QUIRK_ARM_NS,
> > 
> >  };
> >  
> >  struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s2_init_fns = {
> > 
> > @@ -873,6 +874,7 @@ struct io_pgtable_init_fns
> > io_pgtable_arm_64_lpae_s2_init_fns = {> 
> >  struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s1_init_fns = {
> >  
> >  	.alloc	= arm_32_lpae_alloc_pgtable_s1,
> >  	.free	= arm_lpae_free_pgtable,
> > 
> > +	.supported_quirks = IO_PGTABLE_QUIRK_ARM_NS,
> > 
> >  };
> >  
> >  struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s2_init_fns = {
> > 
> > diff --git a/drivers/iommu/io-pgtable.c b/drivers/iommu/io-pgtable.c
> > index 876f6a7..0f57a45 100644
> > --- a/drivers/iommu/io-pgtable.c
> > +++ b/drivers/iommu/io-pgtable.c
> > @@ -52,6 +52,9 @@ struct io_pgtable_ops *alloc_io_pgtable_ops(enum
> > io_pgtable_fmt fmt,> 
> >  	if (!fns)
> >  	
> >  		return NULL;
> > 
> > +	if (cfg->quirks & ~fns->supported_quirks)
> > +		return NULL;
> > +
> > 
> >  	iop = fns->alloc(cfg, cookie);
> >  	if (!iop)
> >  	
> >  		return NULL;
> > 
> > diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
> > index 4faee7d..6e7f11e 100644
> > --- a/drivers/iommu/io-pgtable.h
> > +++ b/drivers/iommu/io-pgtable.h
> > @@ -47,10 +47,24 @@ struct iommu_gather_ops {
> > 
> >   *                 page table walker.
> >   */
> >  
> >  struct io_pgtable_cfg {
> > 
> > -	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0) /* Set NS bit in PTEs */
> > -	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1) /* No AP/XN bits */
> > -	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2) /* TLB Inv. on map */
> > -	int				quirks;
> > +	/*
> > +	 * IO_PGTABLE_QUIRK_ARM_NS: (ARM formats) Set NS and NSTABLE bits in
> > +	 *	stage 1 PTEs, for hardware which insists on validating them
> > +	 *	even in	non-secure state where they should normally be ignored.
> > +	 *
> > +	 * IO_PGTABLE_QUIRK_NO_PERMS: Ignore the IOMMU_READ, IOMMU_WRITE and
> > +	 *	IOMMU_NOEXEC flags and map everything with full access, for
> > +	 *	hardware which does not implement the permissions of a given
> > +	 *	format, and/or requires some format-specific default value.
> > +	 *
> > +	 * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching 
invalid
> > +	 *	(unmapped) entries but the hardware might do so anyway, perform
> > +	 *	TLB maintenance when mapping as well as when unmapping.
> > +	 */
> 
> Much better, cheers.
> 
> > +	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
> > +	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
> > +	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2)
> > +	unsigned int			quirks;
> 
> Let's just make this unsigned long.
> 
> >  	unsigned long			pgsize_bitmap;
> >  	unsigned int			ias;
> >  	unsigned int			oas;
> > 
> > @@ -173,10 +187,12 @@ static inline void io_pgtable_tlb_sync(struct
> > io_pgtable *iop)
> >   *
> >   * @alloc: Allocate a set of page tables described by cfg.
> >   * @free:  Free the page tables associated with iop.
> > + * @supported_quirks: Bitmap of quirks supported by the format.
> >   */
> >  struct io_pgtable_init_fns {
> >  	struct io_pgtable *(*alloc)(struct io_pgtable_cfg *cfg, void 
*cookie);
> >  	void (*free)(struct io_pgtable *iop);
> > +	unsigned int supported_quirks;
> >  };
> 
> My only gripe here is that this is supposed to be a struct of function
> pointers... get_supported_quirks() ?

Can't we instead say it's a struct of function pointers and static data ? :-) 
A function to retrieve the supported quirks will just contribute to kernel 
bloat without adding any extra benefit.

-- 
Regards,

Laurent Pinchart



From ulf.hansson at linaro.org  Fri Feb 12 04:50:37 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Fri, 12 Feb 2016 13:50:37 +0100
Subject: [PATCH 2/7] i2c: omap: Fix PM regression with deferred probe for
 pm_runtime_reinit
In-Reply-To: <1455145370-20301-3-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-3-git-send-email-tony@atomide.com>
Message-ID: <CAPDyKFqGAhWefDtFMPwYAv2m1J8tPPUNOdznRtAPVpTbwnAN1A@mail.gmail.com>

On 11 February 2016 at 00:02, Tony Lindgren <tony at atomide.com> wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-i2c at vger.kernel.org
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Kevin Hilman <khilman at baylibre.com>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Rafael J. Wysocki <rafael at kernel.org>
> Cc: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Tero Kristo <t-kristo at ti.com>
> Cc: Wolfram Sang <wsa at the-dreams.de>
> Signed-off-by: Tony Lindgren <tony at atomide.com>

Acked-by: Ulf Hansson <ulf.hansson at linaro.org>

Kind regards
Uffe

> ---
>
> Wolfram, I'd like to merge this along with other related fixes via
> the ARM SoC tree if no objections, please review and ack if this
> look OK to you.
>
>
> ---
>
>  drivers/i2c/busses/i2c-omap.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 08d26ba..13c4529 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -1450,7 +1450,8 @@ omap_i2c_probe(struct platform_device *pdev)
>
>  err_unuse_clocks:
>         omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
> -       pm_runtime_put(omap->dev);
> +       pm_runtime_dont_use_autosuspend(omap->dev);
> +       pm_runtime_put_sync(omap->dev);
>         pm_runtime_disable(&pdev->dev);
>  err_free_mem:
>
> @@ -1468,6 +1469,7 @@ static int omap_i2c_remove(struct platform_device *pdev)
>                 return ret;
>
>         omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
> +       pm_runtime_dont_use_autosuspend(&pdev->dev);
>         pm_runtime_put_sync(&pdev->dev);
>         pm_runtime_disable(&pdev->dev);
>         return 0;
> --
> 2.7.0
>


From ulf.hansson at linaro.org  Fri Feb 12 04:51:18 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Fri, 12 Feb 2016 13:51:18 +0100
Subject: [PATCH 3/7] spi: omap2-mcspi: Fix PM regression with deferred
 probe for pm_runtime_reinit
In-Reply-To: <1455145370-20301-4-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-4-git-send-email-tony@atomide.com>
Message-ID: <CAPDyKFpatP1Kq4Dkw=m0eurP=7AJVRH2GjOHx0Cj56gYLOjVDQ@mail.gmail.com>

On 11 February 2016 at 00:02, Tony Lindgren <tony at atomide.com> wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-spi at vger.kernel.org
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Kevin Hilman <khilman at baylibre.com>
> Cc: Mark Brown <broonie at kernel.org>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Rafael J. Wysocki <rafael at kernel.org>
> Cc: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Tero Kristo <t-kristo at ti.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>

Acked-by: Ulf Hansson <ulf.hansson at linaro.org>

Kind regards
Uffe

> ---
>
> Mark, I'd like to merge this along with other related fixes via
> the ARM SoC tree if no objections, please review and ack if this
> look OK to you.
>
>
> ---
>  drivers/spi/spi-omap2-mcspi.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
> index 7273820..0caa3c8 100644
> --- a/drivers/spi/spi-omap2-mcspi.c
> +++ b/drivers/spi/spi-omap2-mcspi.c
> @@ -1490,6 +1490,8 @@ static int omap2_mcspi_probe(struct platform_device *pdev)
>         return status;
>
>  disable_pm:
> +       pm_runtime_dont_use_autosuspend(&pdev->dev);
> +       pm_runtime_put_sync(&pdev->dev);
>         pm_runtime_disable(&pdev->dev);
>  free_master:
>         spi_master_put(master);
> @@ -1501,6 +1503,7 @@ static int omap2_mcspi_remove(struct platform_device *pdev)
>         struct spi_master *master = platform_get_drvdata(pdev);
>         struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
>
> +       pm_runtime_dont_use_autosuspend(mcspi->dev);
>         pm_runtime_put_sync(mcspi->dev);
>         pm_runtime_disable(&pdev->dev);
>
> --
> 2.7.0
>


From ulf.hansson at linaro.org  Fri Feb 12 04:52:09 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Fri, 12 Feb 2016 13:52:09 +0100
Subject: [PATCH 4/7] serial: 8250_omap: Fix PM regression with deferred
 probe for pm_runtime_reinit
In-Reply-To: <1455145370-20301-5-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-5-git-send-email-tony@atomide.com>
Message-ID: <CAPDyKFoO2pHhMBbZJgF8=wiqtxWe0vJyCnMyqfmH84P4cCBa6A@mail.gmail.com>

On 11 February 2016 at 00:02, Tony Lindgren <tony at atomide.com> wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-serial at vger.kernel.org
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: Kevin Hilman <khilman at baylibre.com>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Peter Hurley <peter at hurleysoftware.com>
> Cc: Rafael J. Wysocki <rafael at kernel.org>
> Cc: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Tero Kristo <t-kristo at ti.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>

Acked-by: Ulf Hansson <ulf.hansson at linaro.org>

Kind regards
Uffe

> ---
>
> Greg & Peter, I'd like to merge this along with other related fixes
> via the ARM SoC tree if no objections, please review and ack if this
> look OK to you.
>
> ---
>  drivers/tty/serial/8250/8250_omap.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index a2c0734..81ff337 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -1235,7 +1235,8 @@ static int omap8250_probe(struct platform_device *pdev)
>         pm_runtime_put_autosuspend(&pdev->dev);
>         return 0;
>  err:
> -       pm_runtime_put(&pdev->dev);
> +       pm_runtime_dont_use_autosuspend(&pdev->dev);
> +       pm_runtime_put_sync(&pdev->dev);
>         pm_runtime_disable(&pdev->dev);
>         return ret;
>  }
> @@ -1244,6 +1245,7 @@ static int omap8250_remove(struct platform_device *pdev)
>  {
>         struct omap8250_priv *priv = platform_get_drvdata(pdev);
>
> +       pm_runtime_dont_use_autosuspend(&pdev->dev);
>         pm_runtime_put_sync(&pdev->dev);
>         pm_runtime_disable(&pdev->dev);
>         serial8250_unregister_port(priv->line);
> --
> 2.7.0
>


From ulf.hansson at linaro.org  Fri Feb 12 04:52:44 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Fri, 12 Feb 2016 13:52:44 +0100
Subject: [PATCH 5/7] serial: omap: Fix PM regression with deferred probe
 for pm_runtime_reinit
In-Reply-To: <1455145370-20301-6-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-6-git-send-email-tony@atomide.com>
Message-ID: <CAPDyKFoTWzoCypdEz5etghO+zt51n0wriXCRkGBgP3mM=8JSPA@mail.gmail.com>

On 11 February 2016 at 00:02, Tony Lindgren <tony at atomide.com> wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-serial at vger.kernel.org
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
> Cc: Kevin Hilman <khilman at baylibre.com>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Rafael J. Wysocki <rafael at kernel.org>
> Cc: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Tero Kristo <t-kristo at ti.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>

Acked-by: Ulf Hansson <ulf.hansson at linaro.org>

Kind regards
Uffe


> ---
>
> Greg & Peter, I'd like to merge this along with other related fixes
> via the ARM SoC tree if no objections, please review and ack if
> this look OK to you.
>
> ---
>  drivers/tty/serial/omap-serial.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index b645f92..5c43f75 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -1708,7 +1708,8 @@ static int serial_omap_probe(struct platform_device *pdev)
>         return 0;
>
>  err_add_port:
> -       pm_runtime_put(&pdev->dev);
> +       pm_runtime_dont_use_autosuspend(&pdev->dev);
> +       pm_runtime_put_sync(&pdev->dev);
>         pm_runtime_disable(&pdev->dev);
>         pm_qos_remove_request(&up->pm_qos_request);
>         device_init_wakeup(up->dev, false);
> @@ -1721,6 +1722,7 @@ static int serial_omap_remove(struct platform_device *dev)
>  {
>         struct uart_omap_port *up = platform_get_drvdata(dev);
>
> +       pm_runtime_dont_use_autosuspend(up->dev);
>         pm_runtime_put_sync(up->dev);
>         pm_runtime_disable(up->dev);
>         uart_remove_one_port(&serial_omap_reg, &up->port);
> --
> 2.7.0
>


From ulf.hansson at linaro.org  Fri Feb 12 04:53:34 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Fri, 12 Feb 2016 13:53:34 +0100
Subject: [PATCH 6/7] ARM: OMAP2+: Improve omap_device error for driver
 writers
In-Reply-To: <1455145370-20301-7-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-7-git-send-email-tony@atomide.com>
Message-ID: <CAPDyKFqTMDYdMFj9mABKVA9nCx2n9P0+LExjO6iKJ+9NWAbtcQ@mail.gmail.com>

On 11 February 2016 at 00:02, Tony Lindgren <tony at atomide.com> wrote:
> Drivers using pm_runtime_use_autosuspend() may not get disabled after
> -EPROBE_DEFER. On the following device driver probe, hardware state
> is different from the PM runtime state causing omap_device to produce
> the following error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> Let's add a proper error message so driver writers can easily fix
> their drivers for PM.
>
> In general, the solution is to fix the drivers to follow the PM
> runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Let's not return with 0 from _od_runtime_resume() as that will
> eventually lead into new drivers with broken PM runtime that will
> block deeper idle states on omaps.
>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Kevin Hilman <khilman at baylibre.com>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Rafael J. Wysocki <rafael at kernel.org>
> Cc: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Tero Kristo <t-kristo at ti.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>

Acked-by: Ulf Hansson <ulf.hansson at linaro.org>

Kind regards
Uffe


> ---
>  arch/arm/mach-omap2/omap_device.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 0437537..ebd8369 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -602,8 +602,10 @@ static int _od_runtime_resume(struct device *dev)
>         int ret;
>
>         ret = omap_device_enable(pdev);
> -       if (ret)
> +       if (ret) {
> +               dev_err(dev, "use pm_runtime_put_sync_suspend() in driver?\n");
>                 return ret;
> +       }
>
>         return pm_generic_runtime_resume(dev);
>  }
> --
> 2.7.0
>


From ulf.hansson at linaro.org  Fri Feb 12 04:54:21 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Fri, 12 Feb 2016 13:54:21 +0100
Subject: [PATCH 7/7] ARM: OMAP2+: Fix omap_device for module reload on PM
 runtime forbid
In-Reply-To: <1455145370-20301-8-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-8-git-send-email-tony@atomide.com>
Message-ID: <CAPDyKFoJHw73xi0GE8YqtHcAjArrUkisXLTnF_kypSjAAtG0Eg@mail.gmail.com>

On 11 February 2016 at 00:02, Tony Lindgren <tony at atomide.com> wrote:
> If a driver PM runtime is disabled via sysfs, and the module is
> unloaded, PM runtime can't do anything to disable the device. Let's
> let the interconnect disable the device on BUS_NOTIFY_UNBOUND_DRIVER.
>
> Otherwise omap_device will produce and error on the following module
> reload. This can be easily tested with something like:
>
> # modprobe omap_hsmmc
> # echo on > /sys/devices/platform/68000000.ocp/4809c000.mmc/power/control
> # rmmod omap_hsmmc
> # modprobe omap_hsmmc
>
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Kevin Hilman <khilman at baylibre.com>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Rafael J. Wysocki <rafael at kernel.org>
> Cc: Tero Kristo <t-kristo at ti.com>
> Reported-by: Ulf Hansson <ulf.hansson at linaro.org>
> Signed-off-by: Tony Lindgren <tony at atomide.com>

Acked-by: Ulf Hansson <ulf.hansson at linaro.org>

Kind regards
Uffe


> ---
>  arch/arm/mach-omap2/omap_device.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index ebd8369..f7ff3b9 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -191,12 +191,22 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
>  {
>         struct platform_device *pdev = to_platform_device(dev);
>         struct omap_device *od;
> +       int err;
>
>         switch (event) {
>         case BUS_NOTIFY_DEL_DEVICE:
>                 if (pdev->archdata.od)
>                         omap_device_delete(pdev->archdata.od);
>                 break;
> +       case BUS_NOTIFY_UNBOUND_DRIVER:
> +               od = to_omap_device(pdev);
> +               if (od && (od->_state == OMAP_DEVICE_STATE_ENABLED)) {
> +                       dev_info(dev, "enabled after unload, idling\n");
> +                       err = omap_device_idle(pdev);
> +                       if (err)
> +                               dev_err(dev, "failed to idle\n");
> +               }
> +               break;
>         case BUS_NOTIFY_ADD_DEVICE:
>                 if (pdev->dev.of_node)
>                         omap_device_build_from_dt(pdev);
> --
> 2.7.0
>


From rafael at kernel.org  Fri Feb 12 04:57:44 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Fri, 12 Feb 2016 13:57:44 +0100
Subject: [PATCH v4 01/17] Xen: ACPI: Hide UART used by Xen
In-Reply-To: <alpine.DEB.2.02.1602121138090.27008@kaball.uk.xensource.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
 <44113385.2QnPtvxQx0@vostro.rjw.lan>
 <alpine.DEB.2.02.1602111557430.27008@kaball.uk.xensource.com>
 <1667812.hY9vsC2epc@vostro.rjw.lan>
 <alpine.DEB.2.02.1602121138090.27008@kaball.uk.xensource.com>
Message-ID: <CAJZ5v0j7Vv5B-+CYt=ZAvO+YTj6-0Cm0Bi=1AjG5JbTeNLW3EQ@mail.gmail.com>

On Fri, Feb 12, 2016 at 12:50 PM, Stefano Stabellini
<stefano.stabellini at eu.citrix.com> wrote:
> On Thu, 11 Feb 2016, Rafael J. Wysocki wrote:
>> On Thursday, February 11, 2016 04:04:14 PM Stefano Stabellini wrote:
>> > On Wed, 10 Feb 2016, Rafael J. Wysocki wrote:
>> > > On Tuesday, February 09, 2016 11:19:02 AM Stefano Stabellini wrote:
>> > > > On Mon, 8 Feb 2016, Rafael J. Wysocki wrote:
>> > > > > On Monday, February 08, 2016 10:57:01 AM Stefano Stabellini wrote:
>> > > > > > On Sat, 6 Feb 2016, Rafael J. Wysocki wrote:
>> > > > > > > On Fri, Feb 5, 2016 at 4:05 AM, Shannon Zhao <zhaoshenglong at huawei.com> wrote:
>> > > > > > > > From: Shannon Zhao <shannon.zhao at linaro.org>
>> > > > > > > >
>> > > > > > > > ACPI 6.0 introduces a new table STAO to list the devices which are used
>> > > > > > > > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
>> > > > > > > > UART is used by Xen. So here it hides UART from Dom0.
>> > > > > > > >
>> > > > > > > > Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
>> > > > > > > > Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
>> > > > > > >
>> > > > > > > Well, this doesn't look right to me.
>> > > > > > >
>> > > > > > > We need to find a nicer way to achieve what you want.
>> > > > > >
>> > > > > > I take that you are talking about how to honor the STAO table in Linux.
>> > > > > > Do you have any concrete suggestions?
>> > > > >
>> > > > > I do.
>> > > > >
>> > > > > The last hunk of the patch is likely what it needs to be, although I'm
>> > > > > not sure if the place it is added to is the right one.  That's a minor thing,
>> > > > > though.
>> > > > >
>> > > > > The other part is problematic.  Not that as it doesn't work, but because of
>> > > > > how it works.  With these changes the device will be visible to the OS (in
>> > > > > fact to user space even), but will never be "present".  I'm not sure if
>> > > > > that's what you want?
>> > > > >
>> > > > > It might be better to add a check to acpi_bus_type_and_status() that will
>> > > > > evaluate the "should ignore?" thing and return -ENODEV if this is true.  This
>> > > > > way the device won't be visible at all.
>> > > >
>> > > > Something like below?  Actually your suggestion is better, thank you!
>> > > >
>> > > > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> > > > index 78d5f02..4778c51 100644
>> > > > --- a/drivers/acpi/scan.c
>> > > > +++ b/drivers/acpi/scan.c
>> > > > @@ -1455,6 +1455,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type,
>> > > >         if (ACPI_FAILURE(status))
>> > > >                 return -ENODEV;
>> > > >
>> > > > +       if (acpi_check_device_is_ignored(handle))
>> > > > +               return -ENODEV;
>> > > > +
>> > > >         switch (acpi_type) {
>> > > >         case ACPI_TYPE_ANY:             /* for ACPI_ROOT_OBJECT */
>> > > >         case ACPI_TYPE_DEVICE:
>> > > >
>> > >
>> > > I thought about doing that under ACPI_TYPE_DEVICE, because it shouldn't be
>> > > applicable to the other types.  But generally, yes.
>> >
>> > I was pondering about it myself. Maybe an ACPI_TYPE_PROCESSOR object
>> > could theoretically be hidden with the STAO?
>>
>> But this patch won't check for it anyway, will it?
>>
>> It seems to be only checking against the UART address or have I missed
>> anything?
>
> You are right, this patch only checks for the UART address, which is
> critical.
>
> However the STAO also has a "Name List" field with a list of paths in
> ACPI namespace to hide. If not implementing proper "Name List" support,
> at least, as part of this patch, it would be nice to check for the
> presence of the Name List field in the table, and print a warning such
> as "STAO Name List not yet supported" when the field is present.

That would be fine, but anyway it belongs to the table parsing part IMO.

And the check can be moved when adding proper support for the name list part.

Thanks,
Rafael


From ulf.hansson at linaro.org  Fri Feb 12 04:59:07 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Fri, 12 Feb 2016 13:59:07 +0100
Subject: [PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred
 probe for pm_runtime_reinit
In-Reply-To: <20160211172632.GT19432@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-2-git-send-email-tony@atomide.com>
 <CAPDyKFpAcsfLgtu93P45fTEg11MjdGwREcyeGSS7vt6GWbNu_w@mail.gmail.com>
 <20160211150240.GR19432@atomide.com>
 <CAPDyKFo4Jyjwyvr3P5VHfDhQ87K9mnR01N-NtKz-yx2ycnfOLg@mail.gmail.com>
 <20160211172632.GT19432@atomide.com>
Message-ID: <CAPDyKFpwGcCW_Vwz07cgh8LxGmxu9=GVch0MVJEpNJ19zoLZ7g@mail.gmail.com>

On 11 February 2016 at 18:26, Tony Lindgren <tony at atomide.com> wrote:
> * Ulf Hansson <ulf.hansson at linaro.org> [160211 07:14]:
>> On 11 February 2016 at 16:02, Tony Lindgren <tony at atomide.com> wrote:
>> > * Ulf Hansson <ulf.hansson at linaro.org> [160211 02:19]:
>> >> On 11 February 2016 at 00:02, Tony Lindgren <tony at atomide.com> wrote:
>> >> >
>> >> > Ulf, I'd like to merge this along with other related fixes via the
>> >> > ARM SoC tree if no objections, please review and ack if this look OK
>> >> > to you.
>> >>
>> >> I have some other omap_hsmmc patches queued for 4.6, so I prefer to
>> >> send this via my mmc tree.
>> >>
>> >> I guess that's okay as well!?
>> >
>> > Naturally yes, please go ahead thanks!
>>
>> Okay!
>>
>> BTW, did you notice my other comments to the patch?
>>
>> I can fix them before applying, unless you want to send a v2?
>
> Oh sorry, no I missed the rest of your comments again, I really
> need to recalibrate my reading habits obviously if I keep
> missing comments on regular basis..
>
> You comments make sense to me. Below is the patch with only
> minimal changes. Seems to work just fine and hit off mode for
> suspend too.
>
> Regards,
>
> Tony
>
> 8< -------------------
> From eb3c93421f01fb6198f76127262a92b527dd214c Mon Sep 17 00:00:00 2001
> From: Tony Lindgren <tony at atomide.com>
> Date: Tue, 9 Feb 2016 09:31:10 -0800
> Subject: [PATCH] mmc: omap_hsmmc: Fix PM regression with deferred probe for
>  pm_runtime_reinit
>
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
>
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
>
> omap_device_enable() called from invalid state 1
>
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
>
> The solution is to fix the drivers to follow the PM runtime documentation:
>
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
>
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
>
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-mmc at vger.kernel.org
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Kevin Hilman <khilman at baylibre.com>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Rafael J. Wysocki <rafael at kernel.org>
> Cc: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Tero Kristo <t-kristo at ti.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>
>
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2232,6 +2232,7 @@ err_irq:
>                 dma_release_channel(host->tx_chan);
>         if (host->rx_chan)
>                 dma_release_channel(host->rx_chan);
> +       pm_runtime_dont_use_autosuspend(host->dev);
>         pm_runtime_put_sync(host->dev);
>         pm_runtime_disable(host->dev);
>         if (host->dbclk)
> @@ -2253,6 +2254,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
>         dma_release_channel(host->tx_chan);
>         dma_release_channel(host->rx_chan);
>
> +       pm_runtime_dont_use_autosuspend(host->dev);
>         pm_runtime_put_sync(host->dev);
>         pm_runtime_disable(host->dev);
>         device_init_wakeup(&pdev->dev, false);

Thanks, applied for fixes!

Kind regards
Uffe


From marc.zyngier at arm.com  Fri Feb 12 05:22:41 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 12 Feb 2016 13:22:41 +0000
Subject: [PATCH V3 10/10] acpi, gicv3, its: Use MADT ITS subtable to do
 PCI/MSI domain initialization.
In-Reply-To: <56BDCF8F.1080208@semihalf.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
 <1453209083-3358-11-git-send-email-tn@semihalf.com>
 <56BB26E5.6060703@arm.com> <56BDCF8F.1080208@semihalf.com>
Message-ID: <56BDDCA1.2090909@arm.com>

On 12/02/16 12:26, Tomasz Nowicki wrote:
> + Charles
> 
> On 10.02.2016 13:02, Marc Zyngier wrote:
>> On 19/01/16 13:11, Tomasz Nowicki wrote:
>>> After refactoring DT code, we let ACPI to build ITS PCI MSI domain
>>> and do requester ID to device ID translation using IORT table.
>>>
>>> We have now full PCI MSI domain stack, thus we can enable ITS initialization
>>> from GICv3 core driver for ACPI scenario.
>>>
>>> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
>>> ---
>>>   drivers/irqchip/irq-gic-v3-its-pci-msi.c | 44 +++++++++++++++++++++++++++++++-
>>>   drivers/irqchip/irq-gic-v3.c             |  3 +--
>>>   drivers/pci/msi.c                        |  3 +++
>>>   3 files changed, 47 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
>>> index 06165cb..7f0a958 100644
>>> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
>>> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
>>> @@ -15,6 +15,8 @@
>>>    * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>>    */
>>>
>>> +#include <linux/acpi.h>
>>> +#include <linux/iort.h>
>>>   #include <linux/msi.h>
>>>   #include <linux/of.h>
>>>   #include <linux/of_irq.h>
>>> @@ -143,10 +145,50 @@ static int __init its_pci_of_msi_init(void)
>>>   	return 0;
>>>   }
>>>
>>> +#ifdef CONFIG_ACPI
>>> +
>>> +static int __init
>>> +its_pci_msi_parse_madt(struct acpi_subtable_header *header,
>>> +		    const unsigned long end)
>>> +{
>>> +	struct acpi_madt_generic_translator *its_entry;
>>> +	struct fwnode_handle *domain_handle;
>>> +
>>> +	its_entry = (struct acpi_madt_generic_translator *)header;
>>> +	domain_handle = iort_find_its_domain_token(its_entry->translation_id);
>>> +	if (!domain_handle) {
>>> +		pr_err("ITS at 0x%lx: Unable to locate ITS domain handle\n",
>>> +		       (long)its_entry->base_address);
>>> +		return 0;
>>> +	}
>>> +
>>> +	if (its_pci_msi_init_one(domain_handle))
>>> +		return 0;
>>> +
>>> +	pci_msi_register_fwnode_provider(&iort_find_pci_domain_token);
>>
>> I'm a bit worried by this. You are registering this for each and every
>> ITS that gets probed (useless, but why not). But also, you're using a
>> hook that is designed to work at the bus level, without caring for the
>> actual PCI devices. That's fine for something like GICv2m, which exposes
>> a single domain, but I can't picture how this works when you have
>> devices sitting behind a single RC that talk to different ITSs.
>>
>> My understanding is that IORT was behaving in a similar way the msi-map
>> property works, so I'm a bit puzzled here.
>>
>> Can you please shed some light on that?
>>
> 
> I see your point now. It is possible to describe such case in IORT, for 
> example:
> 
> ********************************************
> RC0 node:
> ---------------
> Mapping 0:
> <input ID range> -> <output ID range>
> <0:100> -> <0:100>
> parent -> ITS0
> ---------------
> Mapping 1:
> <input ID range> -> <output ID range>
> <101:200> -> <101:200>
> parent -> ITS1
> ---------------
> ********************************************
> 
> So for this scenario I cannot use pci_host_bridge_acpi_msi_domain() to 
> find IRQ domain based on bus device (unless there is only one ITS bound 
> to e.g. RC), I should rather add ACPI implementation to 
> pci_msi_get_device_domain on per-device MSI basis. Do you agree?

That's what I was angling for, having had that in mind when writing that
particular piece of code (see 54fa97eeb for the rational).

You should also split the plugging of IORT into the MSI layer from the
ITS driver (last hunk of this patch).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From tim at krieglstein.org  Fri Feb 12 05:35:35 2016
From: tim at krieglstein.org (Tim Sander)
Date: Fri, 12 Feb 2016 14:35:35 +0100
Subject: [PATCH] dts: add specific compatible type for Terasic DE0-NANO-SoC
 Board
Message-ID: <8416439.76b9YNhpgR@dabox>

From: Tim Sander <tim at krieglstein.org>

Add a more specific compatible string:"terasic,de0-nano-soc" for respective board.
Background: when checking for bootspec entries, some board specific fixups
                         are not apropriate for board of the same platform ("altr,socfpga-cyclone5").
                        The same aproach is taken with the EBV-Socrates board.

Signed-off-by: Tim Sander <tim at krieglstein.org>
---
 arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
index 555e9caf21e1..3a427423168e 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
@@ -18,7 +18,7 @@
 
 / {
        model = "Terasic DE-0(Atlas)";
-       compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+       compatible = "terasic,de0-nano-soc"," altr,socfpga-cyclone5", "altr,socfpga";
 
        chosen {
                bootargs = "earlyprintk";
-- 
1.9.1


From james.morse at arm.com  Fri Feb 12 05:47:12 2016
From: james.morse at arm.com (James Morse)
Date: Fri, 12 Feb 2016 13:47:12 +0000
Subject: [PATCH] arm64: make irq_stack_ptr more robust
In-Reply-To: <1455227590-9837-1-git-send-email-yang.shi@linaro.org>
References: <1455227590-9837-1-git-send-email-yang.shi@linaro.org>
Message-ID: <56BDE260.20504@arm.com>

Hi!

On 11/02/16 21:53, Yang Shi wrote:
> Switching between stacks is only valid if we are tracing ourselves while on the
> irq_stack, so it is only valid when in current and non-preemptible context,
> otherwise is is just zeroed off.

Given it was picked up with CONFIG_DEBUG_PREEMPT:

Fixes: 132cd887b5c5 ("arm64: Modify stack trace and dump for use with irq_stack")


> Signed-off-by: Yang Shi <yang.shi at linaro.org>
> ---
>  arch/arm64/kernel/stacktrace.c | 13 ++++++-------
>  arch/arm64/kernel/traps.c      | 11 ++++++++++-
>  2 files changed, 16 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
> index 12a18cb..d9751a4 100644
> --- a/arch/arm64/kernel/stacktrace.c
> +++ b/arch/arm64/kernel/stacktrace.c
> @@ -44,14 +44,13 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
>  	unsigned long irq_stack_ptr;
>  
>  	/*
> -	 * Use raw_smp_processor_id() to avoid false-positives from
> -	 * CONFIG_DEBUG_PREEMPT. get_wchan() calls unwind_frame() on sleeping
> -	 * task stacks, we can be pre-empted in this case, so
> -	 * {raw_,}smp_processor_id() may give us the wrong value. Sleeping
> -	 * tasks can't ever be on an interrupt stack, so regardless of cpu,
> -	 * the checks will always fail.
> +	 * Switching between stacks is valid when tracing current and in
> +	 * non-preemptible context.
>  	 */
> -	irq_stack_ptr = IRQ_STACK_PTR(raw_smp_processor_id());
> +	if (tsk == current && !preemptible())
> +		irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
> +	else
> +		irq_stack_ptr = 0;
>  
>  	low  = frame->sp;
>  	/* irq stacks are not THREAD_SIZE aligned */
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index cbedd72..7d8db3a 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -146,9 +146,18 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
>  static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
>  {
>  	struct stackframe frame;
> -	unsigned long irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
> +	unsigned long irq_stack_ptr;
>  	int skip;
>  
> +	/*
> +	 * Switching between  stacks is valid when tracing current and in

Nit: Two spaces: "between[ ][ ]stacks"


> +	 * non-preemptible context.
> +	 */
> +	if (tsk == current && !preemptible())
> +		irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
> +	else
> +		irq_stack_ptr = 0;
> +
>  	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
>  
>  	if (!tsk)
> 

Neither file includes 'linux/preempt.h' for the definition of preemptible().
(I can't talk: I should have included smp.h for smp_processor_id())


Acked-by: James Morse <james.morse at arm.com>
Tested-by: James Morse <james.morse at arm.com>


Thanks!

James




From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:50:01 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:50:01 +0000
Subject: [PATCH 01/17] drm/virtio: removed optional dummy encoder mode_fixup
 function.
In-Reply-To: <1455285017-2771-1-git-send-email-palminha@synopsys.com>
References: <1455285017-2771-1-git-send-email-palminha@synopsys.com>
Message-ID: <1455285017-2771-2-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/virtio/virtgpu_display.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
index a165f03..429aa31 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -282,13 +282,6 @@ static const struct drm_crtc_helper_funcs virtio_gpu_crtc_helper_funcs = {
 	.atomic_check  = virtio_gpu_crtc_atomic_check,
 };
 
-static bool virtio_gpu_enc_mode_fixup(struct drm_encoder *encoder,
-				      const struct drm_display_mode *mode,
-				      struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void virtio_gpu_enc_mode_set(struct drm_encoder *encoder,
 				    struct drm_display_mode *mode,
 				    struct drm_display_mode *adjusted_mode)
@@ -362,7 +355,6 @@ virtio_gpu_best_encoder(struct drm_connector *connector)
 }
 
 static const struct drm_encoder_helper_funcs virtio_gpu_enc_helper_funcs = {
-	.mode_fixup = virtio_gpu_enc_mode_fixup,
 	.mode_set   = virtio_gpu_enc_mode_set,
 	.enable     = virtio_gpu_enc_enable,
 	.disable    = virtio_gpu_enc_disable,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:50:02 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:50:02 +0000
Subject: [PATCH 02/17] drm/udl: removed optional dummy encoder mode_fixup
 function.
In-Reply-To: <1455285017-2771-1-git-send-email-palminha@synopsys.com>
References: <1455285017-2771-1-git-send-email-palminha@synopsys.com>
Message-ID: <1455285017-2771-3-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/udl/udl_encoder.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_encoder.c b/drivers/gpu/drm/udl/udl_encoder.c
index a181a64..59a4b34 100644
--- a/drivers/gpu/drm/udl/udl_encoder.c
+++ b/drivers/gpu/drm/udl/udl_encoder.c
@@ -26,13 +26,6 @@ static void udl_encoder_disable(struct drm_encoder *encoder)
 {
 }
 
-static bool udl_mode_fixup(struct drm_encoder *encoder,
-			   const struct drm_display_mode *mode,
-			   struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void udl_encoder_prepare(struct drm_encoder *encoder)
 {
 }
@@ -54,7 +47,6 @@ udl_encoder_dpms(struct drm_encoder *encoder, int mode)
 
 static const struct drm_encoder_helper_funcs udl_helper_funcs = {
 	.dpms = udl_encoder_dpms,
-	.mode_fixup = udl_mode_fixup,
 	.prepare = udl_encoder_prepare,
 	.mode_set = udl_encoder_mode_set,
 	.commit = udl_encoder_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:50:00 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:50:00 +0000
Subject: [PATCH 00/17] drm encoders cleanup: nuke optional dummy encoder
 mode_fixup function. 
Message-ID: <1455285017-2771-1-git-send-email-palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Carlos Palminha (17):
  drm/virtio: removed optional dummy encoder mode_fixup function.
  drm/udl: removed optional dummy encoder mode_fixup function.
  drm/exynos: removed optional dummy encoder mode_fixup function.
  drm/amdgpu: removed optional dummy encoder mode_fixup function.
  drm/ast: removed optional dummy encoder mode_fixup function.
  drm/bochs: removed optional dummy encoder mode_fixup function.
  drm/cirrus: removed optional dummy encoder mode_fixup function.
  drm/exynos: removed optional dummy encoder mode_fixup function.
  drm/gma500: removed optional dummy encoder mode_fixup function.
  drm/imx: removed optional dummy encoder mode_fixup function.
  drm/msm/mdp: removed optional dummy encoder mode_fixup function.
  drm/mgag200: removed optional dummy encoder mode_fixup function.
  drm/qxl: removed optional dummy encoder mode_fixup function.
  drm/radeon: removed optional dummy encoder mode_fixup function.
  drm/rockchip: removed optional dummy encoder mode_fixup function.
  drm/sti: removed optional dummy encoder mode_fixup function.
  drm/tilcdc: removed optional dummy encoder mode_fixup function.

 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c           |  8 --------
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c           |  8 --------
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c            |  8 --------
 drivers/gpu/drm/ast/ast_mode.c                   |  8 --------
 drivers/gpu/drm/bochs/bochs_kms.c                |  8 --------
 drivers/gpu/drm/cirrus/cirrus_mode.c             |  9 ---------
 drivers/gpu/drm/exynos/exynos_dp_core.c          |  8 --------
 drivers/gpu/drm/exynos/exynos_drm_dpi.c          |  8 --------
 drivers/gpu/drm/exynos/exynos_drm_dsi.c          |  8 --------
 drivers/gpu/drm/exynos/exynos_drm_vidi.c         |  8 --------
 drivers/gpu/drm/gma500/cdv_intel_crt.c           |  1 -
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c          |  1 -
 drivers/gpu/drm/gma500/gma_display.c             |  7 -------
 drivers/gpu/drm/gma500/gma_display.h             |  3 ---
 drivers/gpu/drm/gma500/oaktrail_hdmi.c           |  1 -
 drivers/gpu/drm/imx/dw_hdmi-imx.c                |  8 --------
 drivers/gpu/drm/imx/imx-ldb.c                    |  8 --------
 drivers/gpu/drm/imx/imx-tve.c                    |  8 --------
 drivers/gpu/drm/imx/parallel-display.c           |  8 --------
 drivers/gpu/drm/mgag200/mgag200_mode.c           |  8 --------
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c  |  8 --------
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c  |  8 --------
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c |  8 --------
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c  |  9 ---------
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c      |  8 --------
 drivers/gpu/drm/qxl/qxl_display.c                |  9 ---------
 drivers/gpu/drm/radeon/atombios_encoders.c       |  8 --------
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c           |  8 --------
 drivers/gpu/drm/sti/sti_tvout.c                  | 10 ----------
 drivers/gpu/drm/tilcdc/tilcdc_panel.c            |  9 ---------
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c           |  9 ---------
 drivers/gpu/drm/udl/udl_encoder.c                |  8 --------
 drivers/gpu/drm/virtio/virtgpu_display.c         |  8 --------
 33 files changed, 244 deletions(-)

-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:50:04 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:50:04 +0000
Subject: [PATCH 04/17] drm/amdgpu: removed optional dummy encoder mode_fixup
 function.
In-Reply-To: <1455285017-2771-1-git-send-email-palminha@synopsys.com>
References: <1455285017-2771-1-git-send-email-palminha@synopsys.com>
Message-ID: <1455285017-2771-5-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 8 --------
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 8 --------
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  | 8 --------
 3 files changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 093599a..3483018 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -3624,16 +3624,8 @@ dce_v10_0_ext_dpms(struct drm_encoder *encoder, int mode)
 
 }
 
-static bool dce_v10_0_ext_mode_fixup(struct drm_encoder *encoder,
-				    const struct drm_display_mode *mode,
-				    struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static const struct drm_encoder_helper_funcs dce_v10_0_ext_helper_funcs = {
 	.dpms = dce_v10_0_ext_dpms,
-	.mode_fixup = dce_v10_0_ext_mode_fixup,
 	.prepare = dce_v10_0_ext_prepare,
 	.mode_set = dce_v10_0_ext_mode_set,
 	.commit = dce_v10_0_ext_commit,
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 8e67249..36deea1 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -3619,16 +3619,8 @@ dce_v11_0_ext_dpms(struct drm_encoder *encoder, int mode)
 
 }
 
-static bool dce_v11_0_ext_mode_fixup(struct drm_encoder *encoder,
-				    const struct drm_display_mode *mode,
-				    struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static const struct drm_encoder_helper_funcs dce_v11_0_ext_helper_funcs = {
 	.dpms = dce_v11_0_ext_dpms,
-	.mode_fixup = dce_v11_0_ext_mode_fixup,
 	.prepare = dce_v11_0_ext_prepare,
 	.mode_set = dce_v11_0_ext_mode_set,
 	.commit = dce_v11_0_ext_commit,
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index d0e128c..25dd8b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -3554,16 +3554,8 @@ dce_v8_0_ext_dpms(struct drm_encoder *encoder, int mode)
 
 }
 
-static bool dce_v8_0_ext_mode_fixup(struct drm_encoder *encoder,
-				    const struct drm_display_mode *mode,
-				    struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static const struct drm_encoder_helper_funcs dce_v8_0_ext_helper_funcs = {
 	.dpms = dce_v8_0_ext_dpms,
-	.mode_fixup = dce_v8_0_ext_mode_fixup,
 	.prepare = dce_v8_0_ext_prepare,
 	.mode_set = dce_v8_0_ext_mode_set,
 	.commit = dce_v8_0_ext_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:50:03 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:50:03 +0000
Subject: [PATCH 03/17] drm/exynos: removed optional dummy encoder mode_fixup
 function.
In-Reply-To: <1455285017-2771-1-git-send-email-palminha@synopsys.com>
References: <1455285017-2771-1-git-send-email-palminha@synopsys.com>
Message-ID: <1455285017-2771-4-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index e977a81..736115c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1597,13 +1597,6 @@ static int exynos_dsi_create_connector(struct drm_encoder *encoder)
 	return 0;
 }
 
-static bool exynos_dsi_mode_fixup(struct drm_encoder *encoder,
-				  const struct drm_display_mode *mode,
-				  struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void exynos_dsi_mode_set(struct drm_encoder *encoder,
 				struct drm_display_mode *mode,
 				struct drm_display_mode *adjusted_mode)
@@ -1623,7 +1616,6 @@ static void exynos_dsi_mode_set(struct drm_encoder *encoder,
 }
 
 static const struct drm_encoder_helper_funcs exynos_dsi_encoder_helper_funcs = {
-	.mode_fixup = exynos_dsi_mode_fixup,
 	.mode_set = exynos_dsi_mode_set,
 	.enable = exynos_dsi_enable,
 	.disable = exynos_dsi_disable,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:50:53 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:50:53 +0000
Subject: [PATCH 01/17] drm/virtio: removed optional dummy encoder mode_fixup
 function.
In-Reply-To: <1455285069-2819-1-git-send-email-palminha@synopsys.com>
References: <daniel.vetter@ffwll.ch,>
 <1455285069-2819-1-git-send-email-palminha@synopsys.com>
Message-ID: <1455285069-2819-2-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/virtio/virtgpu_display.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
index a165f03..429aa31 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -282,13 +282,6 @@ static const struct drm_crtc_helper_funcs virtio_gpu_crtc_helper_funcs = {
 	.atomic_check  = virtio_gpu_crtc_atomic_check,
 };
 
-static bool virtio_gpu_enc_mode_fixup(struct drm_encoder *encoder,
-				      const struct drm_display_mode *mode,
-				      struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void virtio_gpu_enc_mode_set(struct drm_encoder *encoder,
 				    struct drm_display_mode *mode,
 				    struct drm_display_mode *adjusted_mode)
@@ -362,7 +355,6 @@ virtio_gpu_best_encoder(struct drm_connector *connector)
 }
 
 static const struct drm_encoder_helper_funcs virtio_gpu_enc_helper_funcs = {
-	.mode_fixup = virtio_gpu_enc_mode_fixup,
 	.mode_set   = virtio_gpu_enc_mode_set,
 	.enable     = virtio_gpu_enc_enable,
 	.disable    = virtio_gpu_enc_disable,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:50:54 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:50:54 +0000
Subject: [PATCH 02/17] drm/udl: removed optional dummy encoder mode_fixup
 function.
In-Reply-To: <1455285069-2819-1-git-send-email-palminha@synopsys.com>
References: <daniel.vetter@ffwll.ch,>
 <1455285069-2819-1-git-send-email-palminha@synopsys.com>
Message-ID: <1455285069-2819-3-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/udl/udl_encoder.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_encoder.c b/drivers/gpu/drm/udl/udl_encoder.c
index a181a64..59a4b34 100644
--- a/drivers/gpu/drm/udl/udl_encoder.c
+++ b/drivers/gpu/drm/udl/udl_encoder.c
@@ -26,13 +26,6 @@ static void udl_encoder_disable(struct drm_encoder *encoder)
 {
 }
 
-static bool udl_mode_fixup(struct drm_encoder *encoder,
-			   const struct drm_display_mode *mode,
-			   struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void udl_encoder_prepare(struct drm_encoder *encoder)
 {
 }
@@ -54,7 +47,6 @@ udl_encoder_dpms(struct drm_encoder *encoder, int mode)
 
 static const struct drm_encoder_helper_funcs udl_helper_funcs = {
 	.dpms = udl_encoder_dpms,
-	.mode_fixup = udl_mode_fixup,
 	.prepare = udl_encoder_prepare,
 	.mode_set = udl_encoder_mode_set,
 	.commit = udl_encoder_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:50:56 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:50:56 +0000
Subject: [PATCH 04/17] drm/amdgpu: removed optional dummy encoder mode_fixup
 function.
In-Reply-To: <1455285069-2819-1-git-send-email-palminha@synopsys.com>
References: <daniel.vetter@ffwll.ch,>
 <1455285069-2819-1-git-send-email-palminha@synopsys.com>
Message-ID: <1455285069-2819-5-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 8 --------
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 8 --------
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  | 8 --------
 3 files changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 093599a..3483018 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -3624,16 +3624,8 @@ dce_v10_0_ext_dpms(struct drm_encoder *encoder, int mode)
 
 }
 
-static bool dce_v10_0_ext_mode_fixup(struct drm_encoder *encoder,
-				    const struct drm_display_mode *mode,
-				    struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static const struct drm_encoder_helper_funcs dce_v10_0_ext_helper_funcs = {
 	.dpms = dce_v10_0_ext_dpms,
-	.mode_fixup = dce_v10_0_ext_mode_fixup,
 	.prepare = dce_v10_0_ext_prepare,
 	.mode_set = dce_v10_0_ext_mode_set,
 	.commit = dce_v10_0_ext_commit,
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 8e67249..36deea1 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -3619,16 +3619,8 @@ dce_v11_0_ext_dpms(struct drm_encoder *encoder, int mode)
 
 }
 
-static bool dce_v11_0_ext_mode_fixup(struct drm_encoder *encoder,
-				    const struct drm_display_mode *mode,
-				    struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static const struct drm_encoder_helper_funcs dce_v11_0_ext_helper_funcs = {
 	.dpms = dce_v11_0_ext_dpms,
-	.mode_fixup = dce_v11_0_ext_mode_fixup,
 	.prepare = dce_v11_0_ext_prepare,
 	.mode_set = dce_v11_0_ext_mode_set,
 	.commit = dce_v11_0_ext_commit,
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index d0e128c..25dd8b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -3554,16 +3554,8 @@ dce_v8_0_ext_dpms(struct drm_encoder *encoder, int mode)
 
 }
 
-static bool dce_v8_0_ext_mode_fixup(struct drm_encoder *encoder,
-				    const struct drm_display_mode *mode,
-				    struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static const struct drm_encoder_helper_funcs dce_v8_0_ext_helper_funcs = {
 	.dpms = dce_v8_0_ext_dpms,
-	.mode_fixup = dce_v8_0_ext_mode_fixup,
 	.prepare = dce_v8_0_ext_prepare,
 	.mode_set = dce_v8_0_ext_mode_set,
 	.commit = dce_v8_0_ext_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:50:55 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:50:55 +0000
Subject: [PATCH 03/17] drm/exynos: removed optional dummy encoder mode_fixup
 function.
In-Reply-To: <1455285069-2819-1-git-send-email-palminha@synopsys.com>
References: <daniel.vetter@ffwll.ch,>
 <1455285069-2819-1-git-send-email-palminha@synopsys.com>
Message-ID: <1455285069-2819-4-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index e977a81..736115c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1597,13 +1597,6 @@ static int exynos_dsi_create_connector(struct drm_encoder *encoder)
 	return 0;
 }
 
-static bool exynos_dsi_mode_fixup(struct drm_encoder *encoder,
-				  const struct drm_display_mode *mode,
-				  struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void exynos_dsi_mode_set(struct drm_encoder *encoder,
 				struct drm_display_mode *mode,
 				struct drm_display_mode *adjusted_mode)
@@ -1623,7 +1616,6 @@ static void exynos_dsi_mode_set(struct drm_encoder *encoder,
 }
 
 static const struct drm_encoder_helper_funcs exynos_dsi_encoder_helper_funcs = {
-	.mode_fixup = exynos_dsi_mode_fixup,
 	.mode_set = exynos_dsi_mode_set,
 	.enable = exynos_dsi_enable,
 	.disable = exynos_dsi_disable,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:53:28 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:53:28 +0000
Subject: [PATCH 05/17] drm/ast: removed optional dummy encoder mode_fixup
 function.
Message-ID: <1455285208-2889-1-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/ast/ast_mode.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 0123458..f221e2d 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -710,13 +710,6 @@ static void ast_encoder_dpms(struct drm_encoder *encoder, int mode)
 
 }
 
-static bool ast_mode_fixup(struct drm_encoder *encoder,
-			   const struct drm_display_mode *mode,
-			   struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void ast_encoder_mode_set(struct drm_encoder *encoder,
 			       struct drm_display_mode *mode,
 			       struct drm_display_mode *adjusted_mode)
@@ -736,7 +729,6 @@ static void ast_encoder_commit(struct drm_encoder *encoder)
 
 static const struct drm_encoder_helper_funcs ast_enc_helper_funcs = {
 	.dpms = ast_encoder_dpms,
-	.mode_fixup = ast_mode_fixup,
 	.prepare = ast_encoder_prepare,
 	.commit = ast_encoder_commit,
 	.mode_set = ast_encoder_mode_set,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:54:23 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:54:23 +0000
Subject: [PATCH 07/17] drm/cirrus: removed optional dummy encoder mode_fixup
 function.
Message-ID: <1455285263-3070-1-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/cirrus/cirrus_mode.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c b/drivers/gpu/drm/cirrus/cirrus_mode.c
index 4a02854..432ce94 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -430,14 +430,6 @@ void cirrus_crtc_fb_gamma_get(struct drm_crtc *crtc, u16 *red, u16 *green,
 	*blue = cirrus_crtc->lut_b[regno];
 }
 
-
-static bool cirrus_encoder_mode_fixup(struct drm_encoder *encoder,
-				      const struct drm_display_mode *mode,
-				      struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void cirrus_encoder_mode_set(struct drm_encoder *encoder,
 				struct drm_display_mode *mode,
 				struct drm_display_mode *adjusted_mode)
@@ -466,7 +458,6 @@ static void cirrus_encoder_destroy(struct drm_encoder *encoder)
 
 static const struct drm_encoder_helper_funcs cirrus_encoder_helper_funcs = {
 	.dpms = cirrus_encoder_dpms,
-	.mode_fixup = cirrus_encoder_mode_fixup,
 	.mode_set = cirrus_encoder_mode_set,
 	.prepare = cirrus_encoder_prepare,
 	.commit = cirrus_encoder_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:54:36 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:54:36 +0000
Subject: [PATCH 08/17] drm/exynos: removed optional dummy encoder mode_fixup
 function.
Message-ID: <1455285276-3117-1-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/exynos/exynos_dp_core.c  | 8 --------
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  | 8 --------
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 8 --------
 3 files changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 673164b..9fd12c62 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1155,13 +1155,6 @@ static int exynos_dp_create_connector(struct drm_encoder *encoder)
 	return 0;
 }
 
-static bool exynos_dp_mode_fixup(struct drm_encoder *encoder,
-				 const struct drm_display_mode *mode,
-				 struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void exynos_dp_mode_set(struct drm_encoder *encoder,
 			       struct drm_display_mode *mode,
 			       struct drm_display_mode *adjusted_mode)
@@ -1177,7 +1170,6 @@ static void exynos_dp_disable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs exynos_dp_encoder_helper_funcs = {
-	.mode_fixup = exynos_dp_mode_fixup,
 	.mode_set = exynos_dp_mode_set,
 	.enable = exynos_dp_enable,
 	.disable = exynos_dp_disable,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 05350ae..75e570f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -128,13 +128,6 @@ static int exynos_dpi_create_connector(struct drm_encoder *encoder)
 	return 0;
 }
 
-static bool exynos_dpi_mode_fixup(struct drm_encoder *encoder,
-				  const struct drm_display_mode *mode,
-				  struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void exynos_dpi_mode_set(struct drm_encoder *encoder,
 				struct drm_display_mode *mode,
 				struct drm_display_mode *adjusted_mode)
@@ -162,7 +155,6 @@ static void exynos_dpi_disable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs exynos_dpi_encoder_helper_funcs = {
-	.mode_fixup = exynos_dpi_mode_fixup,
 	.mode_set = exynos_dpi_mode_set,
 	.enable = exynos_dpi_enable,
 	.disable = exynos_dpi_disable,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 62ac4e5..65108cb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -410,13 +410,6 @@ static int vidi_create_connector(struct drm_encoder *encoder)
 	return 0;
 }
 
-static bool exynos_vidi_mode_fixup(struct drm_encoder *encoder,
-				 const struct drm_display_mode *mode,
-				 struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void exynos_vidi_mode_set(struct drm_encoder *encoder,
 			       struct drm_display_mode *mode,
 			       struct drm_display_mode *adjusted_mode)
@@ -432,7 +425,6 @@ static void exynos_vidi_disable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs exynos_vidi_encoder_helper_funcs = {
-	.mode_fixup = exynos_vidi_mode_fixup,
 	.mode_set = exynos_vidi_mode_set,
 	.enable = exynos_vidi_enable,
 	.disable = exynos_vidi_disable,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:54:48 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:54:48 +0000
Subject: [PATCH 09/17] drm/gma500: removed optional dummy encoder mode_fixup
 function.
Message-ID: <1455285288-3164-1-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/gma500/cdv_intel_crt.c  | 1 -
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 1 -
 drivers/gpu/drm/gma500/gma_display.c    | 7 -------
 drivers/gpu/drm/gma500/gma_display.h    | 3 ---
 drivers/gpu/drm/gma500/oaktrail_hdmi.c  | 1 -
 5 files changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index d0717a8..b837e7a 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
@@ -217,7 +217,6 @@ static int cdv_intel_crt_set_property(struct drm_connector *connector,
 
 static const struct drm_encoder_helper_funcs cdv_intel_crt_helper_funcs = {
 	.dpms = cdv_intel_crt_dpms,
-	.mode_fixup = gma_encoder_mode_fixup,
 	.prepare = gma_encoder_prepare,
 	.commit = gma_encoder_commit,
 	.mode_set = cdv_intel_crt_mode_set,
diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
index ddf2d77..28f9d90 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
@@ -255,7 +255,6 @@ static void cdv_hdmi_destroy(struct drm_connector *connector)
 
 static const struct drm_encoder_helper_funcs cdv_hdmi_helper_funcs = {
 	.dpms = cdv_hdmi_dpms,
-	.mode_fixup = gma_encoder_mode_fixup,
 	.prepare = gma_encoder_prepare,
 	.mode_set = cdv_hdmi_mode_set,
 	.commit = gma_encoder_commit,
diff --git a/drivers/gpu/drm/gma500/gma_display.c b/drivers/gpu/drm/gma500/gma_display.c
index ff17af4..9270821 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -478,13 +478,6 @@ int gma_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
 	return 0;
 }
 
-bool gma_encoder_mode_fixup(struct drm_encoder *encoder,
-			    const struct drm_display_mode *mode,
-			    struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 bool gma_crtc_mode_fixup(struct drm_crtc *crtc,
 			 const struct drm_display_mode *mode,
 			 struct drm_display_mode *adjusted_mode)
diff --git a/drivers/gpu/drm/gma500/gma_display.h b/drivers/gpu/drm/gma500/gma_display.h
index ed569d8..78b9f98 100644
--- a/drivers/gpu/drm/gma500/gma_display.h
+++ b/drivers/gpu/drm/gma500/gma_display.h
@@ -90,9 +90,6 @@ extern void gma_crtc_restore(struct drm_crtc *crtc);
 extern void gma_encoder_prepare(struct drm_encoder *encoder);
 extern void gma_encoder_commit(struct drm_encoder *encoder);
 extern void gma_encoder_destroy(struct drm_encoder *encoder);
-extern bool gma_encoder_mode_fixup(struct drm_encoder *encoder,
-				   const struct drm_display_mode *mode,
-				   struct drm_display_mode *adjusted_mode);
 
 /* Common clock related functions */
 extern const struct gma_limit_t *gma_limit(struct drm_crtc *crtc, int refclk);
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 2d18499..8b2eb32 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -601,7 +601,6 @@ static void oaktrail_hdmi_destroy(struct drm_connector *connector)
 
 static const struct drm_encoder_helper_funcs oaktrail_hdmi_helper_funcs = {
 	.dpms = oaktrail_hdmi_dpms,
-	.mode_fixup = gma_encoder_mode_fixup,
 	.prepare = gma_encoder_prepare,
 	.mode_set = oaktrail_hdmi_mode_set,
 	.commit = gma_encoder_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:55:01 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:55:01 +0000
Subject: [PATCH 10/17] drm/imx: removed optional dummy encoder mode_fixup
 function.
Message-ID: <1455285301-3214-1-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/imx/dw_hdmi-imx.c      | 8 --------
 drivers/gpu/drm/imx/imx-ldb.c          | 8 --------
 drivers/gpu/drm/imx/imx-tve.c          | 8 --------
 drivers/gpu/drm/imx/parallel-display.c | 8 --------
 4 files changed, 32 deletions(-)

diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 063825f..21d6158 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -109,13 +109,6 @@ static void dw_hdmi_imx_encoder_disable(struct drm_encoder *encoder)
 {
 }
 
-static bool dw_hdmi_imx_encoder_mode_fixup(struct drm_encoder *encoder,
-					   const struct drm_display_mode *mode,
-					   struct drm_display_mode *adj_mode)
-{
-	return true;
-}
-
 static void dw_hdmi_imx_encoder_mode_set(struct drm_encoder *encoder,
 					 struct drm_display_mode *mode,
 					 struct drm_display_mode *adj_mode)
@@ -138,7 +131,6 @@ static void dw_hdmi_imx_encoder_prepare(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs dw_hdmi_imx_encoder_helper_funcs = {
-	.mode_fixup = dw_hdmi_imx_encoder_mode_fixup,
 	.mode_set   = dw_hdmi_imx_encoder_mode_set,
 	.prepare    = dw_hdmi_imx_encoder_prepare,
 	.commit     = dw_hdmi_imx_encoder_commit,
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 22ac482..024d613 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -139,13 +139,6 @@ static void imx_ldb_encoder_dpms(struct drm_encoder *encoder, int mode)
 {
 }
 
-static bool imx_ldb_encoder_mode_fixup(struct drm_encoder *encoder,
-			   const struct drm_display_mode *mode,
-			   struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void imx_ldb_set_clock(struct imx_ldb *ldb, int mux, int chno,
 		unsigned long serial_clk, unsigned long di_clk)
 {
@@ -376,7 +369,6 @@ static const struct drm_encoder_funcs imx_ldb_encoder_funcs = {
 
 static const struct drm_encoder_helper_funcs imx_ldb_encoder_helper_funcs = {
 	.dpms = imx_ldb_encoder_dpms,
-	.mode_fixup = imx_ldb_encoder_mode_fixup,
 	.prepare = imx_ldb_encoder_prepare,
 	.commit = imx_ldb_encoder_commit,
 	.mode_set = imx_ldb_encoder_mode_set,
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 292349f..ae7a9fb 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -286,13 +286,6 @@ static void imx_tve_encoder_dpms(struct drm_encoder *encoder, int mode)
 		dev_err(tve->dev, "failed to disable TVOUT: %d\n", ret);
 }
 
-static bool imx_tve_encoder_mode_fixup(struct drm_encoder *encoder,
-				       const struct drm_display_mode *mode,
-				       struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void imx_tve_encoder_prepare(struct drm_encoder *encoder)
 {
 	struct imx_tve *tve = enc_to_tve(encoder);
@@ -379,7 +372,6 @@ static const struct drm_encoder_funcs imx_tve_encoder_funcs = {
 
 static const struct drm_encoder_helper_funcs imx_tve_encoder_helper_funcs = {
 	.dpms = imx_tve_encoder_dpms,
-	.mode_fixup = imx_tve_encoder_mode_fixup,
 	.prepare = imx_tve_encoder_prepare,
 	.mode_set = imx_tve_encoder_mode_set,
 	.commit = imx_tve_encoder_commit,
diff --git a/drivers/gpu/drm/imx/parallel-display.c b/drivers/gpu/drm/imx/parallel-display.c
index 0ffef17..363e2c7 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -112,13 +112,6 @@ static void imx_pd_encoder_dpms(struct drm_encoder *encoder, int mode)
 		drm_panel_enable(imxpd->panel);
 }
 
-static bool imx_pd_encoder_mode_fixup(struct drm_encoder *encoder,
-			   const struct drm_display_mode *mode,
-			   struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void imx_pd_encoder_prepare(struct drm_encoder *encoder)
 {
 	struct imx_parallel_display *imxpd = enc_to_imxpd(encoder);
@@ -166,7 +159,6 @@ static const struct drm_encoder_funcs imx_pd_encoder_funcs = {
 
 static const struct drm_encoder_helper_funcs imx_pd_encoder_helper_funcs = {
 	.dpms = imx_pd_encoder_dpms,
-	.mode_fixup = imx_pd_encoder_mode_fixup,
 	.prepare = imx_pd_encoder_prepare,
 	.commit = imx_pd_encoder_commit,
 	.mode_set = imx_pd_encoder_mode_set,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:56:02 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:56:02 +0000
Subject: [PATCH 15/17] drm/rockchip: removed optional dummy encoder mode_fixup
 function.
Message-ID: <1455285362-3450-1-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index f8f8f29..7766206 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -875,13 +875,6 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder *encoder)
 	clk_disable_unprepare(dsi->pclk);
 }
 
-static bool dw_mipi_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
-					const struct drm_display_mode *mode,
-					struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void dw_mipi_dsi_encoder_commit(struct drm_encoder *encoder)
 {
 	struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
@@ -931,7 +924,6 @@ static void dw_mipi_dsi_encoder_commit(struct drm_encoder *encoder)
 
 static struct drm_encoder_helper_funcs
 dw_mipi_dsi_encoder_helper_funcs = {
-	.mode_fixup = dw_mipi_dsi_encoder_mode_fixup,
 	.commit = dw_mipi_dsi_encoder_commit,
 	.mode_set = dw_mipi_dsi_encoder_mode_set,
 	.disable = dw_mipi_dsi_encoder_disable,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:50:52 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:50:52 +0000
Subject: [PATCH 00/17] drm encoders cleanup: nuke optional dummy encoder
 mode_fixup function. 
In-Reply-To: <daniel.vetter@ffwll.ch,>
References: <daniel.vetter@ffwll.ch,>
Message-ID: <1455285069-2819-1-git-send-email-palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Carlos Palminha (17):
  drm/virtio: removed optional dummy encoder mode_fixup function.
  drm/udl: removed optional dummy encoder mode_fixup function.
  drm/exynos: removed optional dummy encoder mode_fixup function.
  drm/amdgpu: removed optional dummy encoder mode_fixup function.
  drm/ast: removed optional dummy encoder mode_fixup function.
  drm/bochs: removed optional dummy encoder mode_fixup function.
  drm/cirrus: removed optional dummy encoder mode_fixup function.
  drm/exynos: removed optional dummy encoder mode_fixup function.
  drm/gma500: removed optional dummy encoder mode_fixup function.
  drm/imx: removed optional dummy encoder mode_fixup function.
  drm/msm/mdp: removed optional dummy encoder mode_fixup function.
  drm/mgag200: removed optional dummy encoder mode_fixup function.
  drm/qxl: removed optional dummy encoder mode_fixup function.
  drm/radeon: removed optional dummy encoder mode_fixup function.
  drm/rockchip: removed optional dummy encoder mode_fixup function.
  drm/sti: removed optional dummy encoder mode_fixup function.
  drm/tilcdc: removed optional dummy encoder mode_fixup function.

 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c           |  8 --------
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c           |  8 --------
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c            |  8 --------
 drivers/gpu/drm/ast/ast_mode.c                   |  8 --------
 drivers/gpu/drm/bochs/bochs_kms.c                |  8 --------
 drivers/gpu/drm/cirrus/cirrus_mode.c             |  9 ---------
 drivers/gpu/drm/exynos/exynos_dp_core.c          |  8 --------
 drivers/gpu/drm/exynos/exynos_drm_dpi.c          |  8 --------
 drivers/gpu/drm/exynos/exynos_drm_dsi.c          |  8 --------
 drivers/gpu/drm/exynos/exynos_drm_vidi.c         |  8 --------
 drivers/gpu/drm/gma500/cdv_intel_crt.c           |  1 -
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c          |  1 -
 drivers/gpu/drm/gma500/gma_display.c             |  7 -------
 drivers/gpu/drm/gma500/gma_display.h             |  3 ---
 drivers/gpu/drm/gma500/oaktrail_hdmi.c           |  1 -
 drivers/gpu/drm/imx/dw_hdmi-imx.c                |  8 --------
 drivers/gpu/drm/imx/imx-ldb.c                    |  8 --------
 drivers/gpu/drm/imx/imx-tve.c                    |  8 --------
 drivers/gpu/drm/imx/parallel-display.c           |  8 --------
 drivers/gpu/drm/mgag200/mgag200_mode.c           |  8 --------
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c  |  8 --------
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c  |  8 --------
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c |  8 --------
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c  |  9 ---------
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c      |  8 --------
 drivers/gpu/drm/qxl/qxl_display.c                |  9 ---------
 drivers/gpu/drm/radeon/atombios_encoders.c       |  8 --------
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c           |  8 --------
 drivers/gpu/drm/sti/sti_tvout.c                  | 10 ----------
 drivers/gpu/drm/tilcdc/tilcdc_panel.c            |  9 ---------
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c           |  9 ---------
 drivers/gpu/drm/udl/udl_encoder.c                |  8 --------
 drivers/gpu/drm/virtio/virtgpu_display.c         |  8 --------
 33 files changed, 244 deletions(-)

-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:54:04 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:54:04 +0000
Subject: [PATCH 06/17] drm/bochs: removed optional dummy encoder mode_fixup
 function.
Message-ID: <1455285244-2978-1-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/bochs/bochs_kms.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c
index 2849f1b..317c27f 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -152,13 +152,6 @@ static void bochs_crtc_init(struct drm_device *dev)
 	drm_crtc_helper_add(crtc, &bochs_helper_funcs);
 }
 
-static bool bochs_encoder_mode_fixup(struct drm_encoder *encoder,
-				     const struct drm_display_mode *mode,
-				     struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void bochs_encoder_mode_set(struct drm_encoder *encoder,
 				   struct drm_display_mode *mode,
 				   struct drm_display_mode *adjusted_mode)
@@ -179,7 +172,6 @@ static void bochs_encoder_commit(struct drm_encoder *encoder)
 
 static const struct drm_encoder_helper_funcs bochs_encoder_helper_funcs = {
 	.dpms = bochs_encoder_dpms,
-	.mode_fixup = bochs_encoder_mode_fixup,
 	.mode_set = bochs_encoder_mode_set,
 	.prepare = bochs_encoder_prepare,
 	.commit = bochs_encoder_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:55:13 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:55:13 +0000
Subject: [PATCH 11/17] drm/msm/mdp: removed optional dummy encoder mode_fixup
 function.
Message-ID: <1455285313-3261-1-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c  | 8 --------
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c  | 8 --------
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c | 8 --------
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c  | 9 ---------
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c      | 8 --------
 5 files changed, 41 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c
index 2f57e94..106f0e7 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c
@@ -47,13 +47,6 @@ static const struct drm_encoder_funcs mdp4_dsi_encoder_funcs = {
 	.destroy = mdp4_dsi_encoder_destroy,
 };
 
-static bool mdp4_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
-					const struct drm_display_mode *mode,
-					struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void mdp4_dsi_encoder_mode_set(struct drm_encoder *encoder,
 				      struct drm_display_mode *mode,
 				      struct drm_display_mode *adjusted_mode)
@@ -163,7 +156,6 @@ static void mdp4_dsi_encoder_enable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs mdp4_dsi_encoder_helper_funcs = {
-	.mode_fixup = mdp4_dsi_encoder_mode_fixup,
 	.mode_set = mdp4_dsi_encoder_mode_set,
 	.disable = mdp4_dsi_encoder_disable,
 	.enable = mdp4_dsi_encoder_enable,
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c
index a21df54..35ad78a 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c
@@ -94,13 +94,6 @@ static const struct drm_encoder_funcs mdp4_dtv_encoder_funcs = {
 	.destroy = mdp4_dtv_encoder_destroy,
 };
 
-static bool mdp4_dtv_encoder_mode_fixup(struct drm_encoder *encoder,
-		const struct drm_display_mode *mode,
-		struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void mdp4_dtv_encoder_mode_set(struct drm_encoder *encoder,
 		struct drm_display_mode *mode,
 		struct drm_display_mode *adjusted_mode)
@@ -234,7 +227,6 @@ static void mdp4_dtv_encoder_enable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs mdp4_dtv_encoder_helper_funcs = {
-	.mode_fixup = mdp4_dtv_encoder_mode_fixup,
 	.mode_set = mdp4_dtv_encoder_mode_set,
 	.enable = mdp4_dtv_encoder_enable,
 	.disable = mdp4_dtv_encoder_disable,
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c
index cd63fed..bc3d8e7 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c
@@ -260,13 +260,6 @@ static void setup_phy(struct drm_encoder *encoder)
 	mdp4_write(mdp4_kms, REG_MDP4_LVDS_PHY_CFG0, lvds_phy_cfg0);
 }
 
-static bool mdp4_lcdc_encoder_mode_fixup(struct drm_encoder *encoder,
-		const struct drm_display_mode *mode,
-		struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void mdp4_lcdc_encoder_mode_set(struct drm_encoder *encoder,
 		struct drm_display_mode *mode,
 		struct drm_display_mode *adjusted_mode)
@@ -430,7 +423,6 @@ static void mdp4_lcdc_encoder_enable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs mdp4_lcdc_encoder_helper_funcs = {
-	.mode_fixup = mdp4_lcdc_encoder_mode_fixup,
 	.mode_set = mdp4_lcdc_encoder_mode_set,
 	.disable = mdp4_lcdc_encoder_disable,
 	.enable = mdp4_lcdc_encoder_enable,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
index 1aa21db..69094cb 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
@@ -188,13 +188,6 @@ static const struct drm_encoder_funcs mdp5_cmd_encoder_funcs = {
 	.destroy = mdp5_cmd_encoder_destroy,
 };
 
-static bool mdp5_cmd_encoder_mode_fixup(struct drm_encoder *encoder,
-		const struct drm_display_mode *mode,
-		struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void mdp5_cmd_encoder_mode_set(struct drm_encoder *encoder,
 		struct drm_display_mode *mode,
 		struct drm_display_mode *adjusted_mode)
@@ -256,7 +249,6 @@ static void mdp5_cmd_encoder_enable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs mdp5_cmd_encoder_helper_funcs = {
-	.mode_fixup = mdp5_cmd_encoder_mode_fixup,
 	.mode_set = mdp5_cmd_encoder_mode_set,
 	.disable = mdp5_cmd_encoder_disable,
 	.enable = mdp5_cmd_encoder_enable,
@@ -340,4 +332,3 @@ fail:
 
 	return ERR_PTR(ret);
 }
-
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
index 0d737ca..1d95f9f 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
@@ -112,13 +112,6 @@ static const struct drm_encoder_funcs mdp5_encoder_funcs = {
 	.destroy = mdp5_encoder_destroy,
 };
 
-static bool mdp5_encoder_mode_fixup(struct drm_encoder *encoder,
-		const struct drm_display_mode *mode,
-		struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void mdp5_encoder_mode_set(struct drm_encoder *encoder,
 		struct drm_display_mode *mode,
 		struct drm_display_mode *adjusted_mode)
@@ -287,7 +280,6 @@ static void mdp5_encoder_enable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs mdp5_encoder_helper_funcs = {
-	.mode_fixup = mdp5_encoder_mode_fixup,
 	.mode_set = mdp5_encoder_mode_set,
 	.disable = mdp5_encoder_disable,
 	.enable = mdp5_encoder_enable,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:55:25 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:55:25 +0000
Subject: [PATCH 12/17] drm/mgag200: removed optional dummy encoder mode_fixup
 function.
Message-ID: <1455285325-3308-1-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c b/drivers/gpu/drm/mgag200/mgag200_mode.c
index dc13c48..af8b4c1 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1479,13 +1479,6 @@ void mga_crtc_fb_gamma_get(struct drm_crtc *crtc, u16 *red, u16 *green,
  * These functions are analagous to those in the CRTC code, but are intended
  * to handle any encoder-specific limitations
  */
-static bool mga_encoder_mode_fixup(struct drm_encoder *encoder,
-				   const struct drm_display_mode *mode,
-				   struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void mga_encoder_mode_set(struct drm_encoder *encoder,
 				struct drm_display_mode *mode,
 				struct drm_display_mode *adjusted_mode)
@@ -1515,7 +1508,6 @@ static void mga_encoder_destroy(struct drm_encoder *encoder)
 
 static const struct drm_encoder_helper_funcs mga_encoder_helper_funcs = {
 	.dpms = mga_encoder_dpms,
-	.mode_fixup = mga_encoder_mode_fixup,
 	.mode_set = mga_encoder_mode_set,
 	.prepare = mga_encoder_prepare,
 	.commit = mga_encoder_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:55:37 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:55:37 +0000
Subject: [PATCH 13/17] drm/qxl: removed optional dummy encoder mode_fixup
 function.
Message-ID: <1455285337-3356-1-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/qxl/qxl_display.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c
index 8627651..43e5f50 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -734,14 +734,6 @@ static void qxl_enc_dpms(struct drm_encoder *encoder, int mode)
 	DRM_DEBUG("\n");
 }
 
-static bool qxl_enc_mode_fixup(struct drm_encoder *encoder,
-			       const struct drm_display_mode *mode,
-			       struct drm_display_mode *adjusted_mode)
-{
-	DRM_DEBUG("\n");
-	return true;
-}
-
 static void qxl_enc_prepare(struct drm_encoder *encoder)
 {
 	DRM_DEBUG("\n");
@@ -864,7 +856,6 @@ static struct drm_encoder *qxl_best_encoder(struct drm_connector *connector)
 
 static const struct drm_encoder_helper_funcs qxl_enc_helper_funcs = {
 	.dpms = qxl_enc_dpms,
-	.mode_fixup = qxl_enc_mode_fixup,
 	.prepare = qxl_enc_prepare,
 	.mode_set = qxl_enc_mode_set,
 	.commit = qxl_enc_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:55:50 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:55:50 +0000
Subject: [PATCH 14/17] drm/radeon: removed optional dummy encoder mode_fixup
 function.
Message-ID: <1455285350-3403-1-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/radeon/atombios_encoders.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
index 01b20e1..1603751 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -2623,16 +2623,8 @@ radeon_atom_ext_dpms(struct drm_encoder *encoder, int mode)
 
 }
 
-static bool radeon_atom_ext_mode_fixup(struct drm_encoder *encoder,
-				       const struct drm_display_mode *mode,
-				       struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static const struct drm_encoder_helper_funcs radeon_atom_ext_helper_funcs = {
 	.dpms = radeon_atom_ext_dpms,
-	.mode_fixup = radeon_atom_ext_mode_fixup,
 	.prepare = radeon_atom_ext_prepare,
 	.mode_set = radeon_atom_ext_mode_set,
 	.commit = radeon_atom_ext_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:56:13 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:56:13 +0000
Subject: [PATCH 16/17] drm/sti: removed optional dummy encoder mode_fixup
 function.
Message-ID: <1455285373-3497-1-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/sti/sti_tvout.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c
index f2afcf5..24a3735 100644
--- a/drivers/gpu/drm/sti/sti_tvout.c
+++ b/drivers/gpu/drm/sti/sti_tvout.c
@@ -440,13 +440,6 @@ static void sti_tvout_encoder_dpms(struct drm_encoder *encoder, int mode)
 {
 }
 
-static bool sti_tvout_encoder_mode_fixup(struct drm_encoder *encoder,
-				       const struct drm_display_mode *mode,
-				       struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void sti_tvout_encoder_mode_set(struct drm_encoder *encoder,
 				       struct drm_display_mode *mode,
 				       struct drm_display_mode *adjusted_mode)
@@ -486,7 +479,6 @@ static void sti_dvo_encoder_disable(struct drm_encoder *encoder)
 
 static const struct drm_encoder_helper_funcs sti_dvo_encoder_helper_funcs = {
 	.dpms = sti_tvout_encoder_dpms,
-	.mode_fixup = sti_tvout_encoder_mode_fixup,
 	.mode_set = sti_tvout_encoder_mode_set,
 	.prepare = sti_tvout_encoder_prepare,
 	.commit = sti_dvo_encoder_commit,
@@ -540,7 +532,6 @@ static void sti_hda_encoder_disable(struct drm_encoder *encoder)
 
 static const struct drm_encoder_helper_funcs sti_hda_encoder_helper_funcs = {
 	.dpms = sti_tvout_encoder_dpms,
-	.mode_fixup = sti_tvout_encoder_mode_fixup,
 	.mode_set = sti_tvout_encoder_mode_set,
 	.prepare = sti_tvout_encoder_prepare,
 	.commit = sti_hda_encoder_commit,
@@ -589,7 +580,6 @@ static void sti_hdmi_encoder_disable(struct drm_encoder *encoder)
 
 static const struct drm_encoder_helper_funcs sti_hdmi_encoder_helper_funcs = {
 	.dpms = sti_tvout_encoder_dpms,
-	.mode_fixup = sti_tvout_encoder_mode_fixup,
 	.mode_set = sti_tvout_encoder_mode_set,
 	.prepare = sti_tvout_encoder_prepare,
 	.commit = sti_hdmi_encoder_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Fri Feb 12 05:56:26 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Fri, 12 Feb 2016 13:56:26 +0000
Subject: [PATCH 17/17] drm/tilcdc: removed optional dummy encoder mode_fixup
 function.
Message-ID: <1455285386-3547-1-git-send-email-palminha@synopsys.com>

---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 9 ---------
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 9 ---------
 2 files changed, 18 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 4dda6e2..8dcf02a 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -70,14 +70,6 @@ static void panel_encoder_dpms(struct drm_encoder *encoder, int mode)
 					 mode == DRM_MODE_DPMS_ON ? 1 : 0);
 }
 
-static bool panel_encoder_mode_fixup(struct drm_encoder *encoder,
-		const struct drm_display_mode *mode,
-		struct drm_display_mode *adjusted_mode)
-{
-	/* nothing needed */
-	return true;
-}
-
 static void panel_encoder_prepare(struct drm_encoder *encoder)
 {
 	struct panel_encoder *panel_encoder = to_panel_encoder(encoder);
@@ -103,7 +95,6 @@ static const struct drm_encoder_funcs panel_encoder_funcs = {
 
 static const struct drm_encoder_helper_funcs panel_encoder_helper_funcs = {
 		.dpms           = panel_encoder_dpms,
-		.mode_fixup     = panel_encoder_mode_fixup,
 		.prepare        = panel_encoder_prepare,
 		.commit         = panel_encoder_commit,
 		.mode_set       = panel_encoder_mode_set,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index 5052a8a..1c23017 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -80,14 +80,6 @@ static void tfp410_encoder_dpms(struct drm_encoder *encoder, int mode)
 	tfp410_encoder->dpms = mode;
 }
 
-static bool tfp410_encoder_mode_fixup(struct drm_encoder *encoder,
-		const struct drm_display_mode *mode,
-		struct drm_display_mode *adjusted_mode)
-{
-	/* nothing needed */
-	return true;
-}
-
 static void tfp410_encoder_prepare(struct drm_encoder *encoder)
 {
 	tfp410_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
@@ -112,7 +104,6 @@ static const struct drm_encoder_funcs tfp410_encoder_funcs = {
 
 static const struct drm_encoder_helper_funcs tfp410_encoder_helper_funcs = {
 		.dpms           = tfp410_encoder_dpms,
-		.mode_fixup     = tfp410_encoder_mode_fixup,
 		.prepare        = tfp410_encoder_prepare,
 		.commit         = tfp410_encoder_commit,
 		.mode_set       = tfp410_encoder_mode_set,
-- 
2.5.0



From drjones at redhat.com  Fri Feb 12 05:56:45 2016
From: drjones at redhat.com (Andrew Jones)
Date: Fri, 12 Feb 2016 14:56:45 +0100
Subject: [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
In-Reply-To: <1455278707-2008263-1-git-send-email-arnd@arndb.de>
References: <1455278707-2008263-1-git-send-email-arnd@arndb.de>
Message-ID: <20160212135645.ouppx4ijselfomjy@hawk.localdomain>

On Fri, Feb 12, 2016 at 01:04:40PM +0100, Arnd Bergmann wrote:
> The Xen framebuffer driver selects the xen keyboard driver, so the latter
> will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
> is a loadable module, this configuration cannot work. On mainline kernels,
> the symbol will be enabled but not used, while in combination with
> a patch I have to detect such useless configurations, we get the
> expected link failure:
> 
> drivers/input/built-in.o: In function `xenkbd_remove':
> xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
> xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
> 
> This changes the dependencies of XEN_FBDEV_FRONTEND so it cannot be
> built-in if CONFIG_INPUT=m && CONFIG_INPUT_MISC=y, as that would result
> in the broken select.
> 
> As usual, we would be much better off without the 'select', but removing
> it now would likely break existing user configurations that depend on
> it, so this adds another hack on top to get it working.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
> ---
>  drivers/video/fbdev/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 8ea45a5cd806..fd3d6fd290a9 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2241,6 +2241,7 @@ config FB_VIRTUAL
>  config XEN_FBDEV_FRONTEND
>  	tristate "Xen virtual frame buffer support"
>  	depends on FB && XEN
> +	depends on INPUT || !INPUT_MISC
>  	select FB_SYS_FILLRECT
>  	select FB_SYS_COPYAREA
>  	select FB_SYS_IMAGEBLIT
> -- 
> 2.7.0
>

Reviewed-by: Andrew Jones <drjones at redhat.com>

Thanks,
drew 


From mark.rutland at arm.com  Fri Feb 12 06:04:18 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 12 Feb 2016 14:04:18 +0000
Subject: [PATCHv2] arm64: Rework valid_user_regs
Message-ID: <1455285858-11757-1-git-send-email-mark.rutland@arm.com>

We validate pstate using PSR_MODE32_BIT, which is part of the
user-provided pstate (and cannot be trusted). Also, we conflate
validation of AArch32 and AArch64 pstate values, making the code
difficult to reason about.

Instead, validate the pstate value based on the associated task. The
task may or may not be current (e.g. when using ptrace), so this must be
passed explicitly by callers. To avoid circular header dependencies via
sched.h, is_compat_task is pulled out of asm/ptrace.h.

To make the code possible to reason about, the AArch64 and AArch32
validation is split into separate functions. Software must respect the
RES0 policy for SPSR bits, and thus the kernel mirrors the hardware
policy (RAZ/WI) for bits as-yet unallocated. When these acquire an
architected meaning writes may be permitted (potentially with additional
validation).

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Dave Martin <dave.martin at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Peter Maydell <peter.maydell at linaro.org>
Cc: Will Deacon <will.deacon at arm.com>
---
 arch/arm64/include/asm/ptrace.h | 32 ++----------------
 arch/arm64/kernel/ptrace.c      | 74 +++++++++++++++++++++++++++++++++++++++--
 arch/arm64/kernel/signal.c      |  4 +--
 arch/arm64/kernel/signal32.c    |  2 +-
 4 files changed, 78 insertions(+), 34 deletions(-)

Since v1 [1]
* Clear the full complement of RES0 bits
* Treat IL as RES0
* Treat SS as RES0 when not tracing
* renames: s/aa64/native, s/aa32/compat/

Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/406424.html

diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index e9e5467..0bb538b 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -151,35 +151,9 @@ static inline unsigned long regs_return_value(struct pt_regs *regs)
 	return regs->regs[0];
 }
 
-/*
- * Are the current registers suitable for user mode? (used to maintain
- * security in signal handlers)
- */
-static inline int valid_user_regs(struct user_pt_regs *regs)
-{
-	if (user_mode(regs) && (regs->pstate & PSR_I_BIT) == 0) {
-		regs->pstate &= ~(PSR_F_BIT | PSR_A_BIT);
-
-		/* The T bit is reserved for AArch64 */
-		if (!(regs->pstate & PSR_MODE32_BIT))
-			regs->pstate &= ~COMPAT_PSR_T_BIT;
-
-		return 1;
-	}
-
-	/*
-	 * Force PSR to something logical...
-	 */
-	regs->pstate &= PSR_f | PSR_s | (PSR_x & ~PSR_A_BIT) | \
-			COMPAT_PSR_T_BIT | PSR_MODE32_BIT;
-
-	if (!(regs->pstate & PSR_MODE32_BIT)) {
-		regs->pstate &= ~COMPAT_PSR_T_BIT;
-		regs->pstate |= PSR_MODE_EL0t;
-	}
-
-	return 0;
-}
+/* We must avoid circular header include via sched.h */
+struct task_struct;
+int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task);
 
 #define instruction_pointer(regs)	((unsigned long)(regs)->pc)
 
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index ff7f132..b293647 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -500,7 +500,7 @@ static int gpr_set(struct task_struct *target, const struct user_regset *regset,
 	if (ret)
 		return ret;
 
-	if (!valid_user_regs(&newregs))
+	if (!valid_user_regs(&newregs, target))
 		return -EINVAL;
 
 	task_pt_regs(target)->user_regs = newregs;
@@ -770,7 +770,7 @@ static int compat_gpr_set(struct task_struct *target,
 
 	}
 
-	if (valid_user_regs(&newregs.user_regs))
+	if (valid_user_regs(&newregs.user_regs, target))
 		*task_pt_regs(target) = newregs;
 	else
 		ret = -EINVAL;
@@ -1272,3 +1272,73 @@ asmlinkage void syscall_trace_exit(struct pt_regs *regs)
 	if (test_thread_flag(TIF_SYSCALL_TRACE))
 		tracehook_report_syscall(regs, PTRACE_SYSCALL_EXIT);
 }
+
+/*
+ * Bits which are always architecturally RES0 per ARM DDI 0487A.h
+ * Userspace cannot use these until they have an architectural meaning.
+ * We also reserve IL for the kernel; SS is handled dynamically.
+ */
+#define SPSR_EL1_AARCH64_RES0_BITS \
+	(GENMASK_ULL(63,32) | GENMASK_ULL(27, 22) | GENMASK_ULL(20, 10) | \
+	 GENMASK_ULL(5, 5))
+#define SPSR_EL1_AARCH32_RES0_BITS \
+	(GENMASK_ULL(63,32) | GENMASK_ULL(24, 22) | GENMASK_ULL(20,20))
+
+static int valid_compat_regs(struct user_pt_regs *regs)
+{
+	regs->pstate &= ~SPSR_EL1_AARCH32_RES0_BITS;
+
+	if (!system_supports_mixed_endian_el0()) {
+		if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
+			regs->pstate |= COMPAT_PSR_E_BIT;
+		else
+			regs->pstate &= ~COMPAT_PSR_E_BIT;
+	}
+
+	if (user_mode(regs) && (regs->pstate & PSR_MODE32_BIT) &&
+	    (regs->pstate & COMPAT_PSR_A_BIT) == 0 &&
+	    (regs->pstate & COMPAT_PSR_I_BIT) == 0 &&
+	    (regs->pstate & COMPAT_PSR_F_BIT) == 0) {
+		return 1;
+	}
+
+	/* Force PSR to a valid 32-bit EL0t */
+	regs->pstate |= PSR_MODE32_BIT;
+	regs->pstate &= PSR_f | PSR_s | (PSR_x & ~COMPAT_PSR_A_BIT) | \
+			COMPAT_PSR_T_BIT;
+
+	return 0;
+}
+
+static int valid_native_regs(struct user_pt_regs *regs)
+{
+	regs->pstate &= ~SPSR_EL1_AARCH64_RES0_BITS;
+
+	if (user_mode(regs) && !(regs->pstate & PSR_MODE32_BIT) &&
+	    (regs->pstate & PSR_D_BIT) == 0 &&
+	    (regs->pstate & PSR_A_BIT) == 0 &&
+	    (regs->pstate & PSR_I_BIT) == 0 &&
+	    (regs->pstate & PSR_F_BIT) == 0) {
+		return 1;
+	}
+
+	/* Force PSR to a valid 64-bit EL0t */
+	regs->pstate &= PSR_f | PSR_s;
+
+	return 0;
+}
+
+/*
+ * Are the current registers suitable for user mode? (used to maintain
+ * security in signal handlers)
+ */
+int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
+{
+	if (!test_tsk_thread_flag(task, TIF_SINGLESTEP))
+		regs->pstate &= ~DBG_SPSR_SS;
+
+	if (is_compat_thread(task_thread_info(task)))
+		return valid_compat_regs(regs);
+	else
+		return valid_native_regs(regs);
+}
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index e18c48c..a8eafdb 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -115,7 +115,7 @@ static int restore_sigframe(struct pt_regs *regs,
 	 */
 	regs->syscallno = ~0UL;
 
-	err |= !valid_user_regs(&regs->user_regs);
+	err |= !valid_user_regs(&regs->user_regs, current);
 
 	if (err == 0) {
 		struct fpsimd_context *fpsimd_ctx =
@@ -307,7 +307,7 @@ static void handle_signal(struct ksignal *ksig, struct pt_regs *regs)
 	/*
 	 * Check that the resulting registers are actually sane.
 	 */
-	ret |= !valid_user_regs(&regs->user_regs);
+	ret |= !valid_user_regs(&regs->user_regs, current);
 
 	/*
 	 * Fast forward the stepping logic so we step into the signal
diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index 71ef6dc..1073356 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -356,7 +356,7 @@ static int compat_restore_sigframe(struct pt_regs *regs,
 	 */
 	regs->syscallno = ~0UL;
 
-	err |= !valid_user_regs(&regs->user_regs);
+	err |= !valid_user_regs(&regs->user_regs, current);
 
 	aux = (struct compat_aux_sigframe __user *) sf->uc.uc_regspace;
 	if (err == 0)
-- 
1.9.1



From linux at arm.linux.org.uk  Fri Feb 12 06:16:54 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 12 Feb 2016 14:16:54 +0000
Subject: [PATCH] ARM: imx: Do L2 errata only if the L2 cache isn't enabled
In-Reply-To: <1455261093-11849-1-git-send-email-dirk.behme@de.bosch.com>
References: <1455261093-11849-1-git-send-email-dirk.behme@de.bosch.com>
Message-ID: <20160212141654.GA10826@n2100.arm.linux.org.uk>

On Fri, Feb 12, 2016 at 08:11:33AM +0100, Dirk Behme wrote:
> All the generic L2 cache handling code is encapsulated by a
> check if the L2 cache is enabled. If it's enabled already, the code
> is skipped.
> 
> For the i.MX6 specific L2 cache handling we missed this check.
> Add it.

What's the reasoning behind this?  The prefetch register is writable
while the L2 cache is enabled, unlike the auxiliary control register.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From arnd at arndb.de  Fri Feb 12 06:27:18 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 15:27:18 +0100
Subject: [PATCH] [media] zl10353: use div_u64 instead of do_div
Message-ID: <1455287246-3540549-1-git-send-email-arnd@arndb.de>

I noticed a build error in some randconfig builds in the zl10353 driver:

dvb-frontends/zl10353.c:138: undefined reference to `____ilog2_NaN'
dvb-frontends/zl10353.c:138: undefined reference to `__aeabi_uldivmod'

The problem can be tracked down to the use of -fprofile-arcs (using
CONFIG_GCOV_PROFILE_ALL) in combination with CONFIG_PROFILE_ALL_BRANCHES
on gcc version 4.9 or higher, when it fails to reliably optimize
constant expressions.

Using div_u64() instead of do_div() makes the code slightly more
readable by both humans and by gcc, which gives the compiler enough
of a break to figure it all out.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/media/dvb-frontends/zl10353.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb-frontends/zl10353.c b/drivers/media/dvb-frontends/zl10353.c
index ef9764a02d4c..160c88710553 100644
--- a/drivers/media/dvb-frontends/zl10353.c
+++ b/drivers/media/dvb-frontends/zl10353.c
@@ -135,8 +135,7 @@ static void zl10353_calc_nominal_rate(struct dvb_frontend *fe,
 
 	value = (u64)10 * (1 << 23) / 7 * 125;
 	value = (bw * value) + adc_clock / 2;
-	do_div(value, adc_clock);
-	*nominal_rate = value;
+	*nominal_rate = div_u64(value, adc_clock);
 
 	dprintk("%s: bw %d, adc_clock %d => 0x%x\n",
 		__func__, bw, adc_clock, *nominal_rate);
@@ -163,8 +162,7 @@ static void zl10353_calc_input_freq(struct dvb_frontend *fe,
 		if (ife > adc_clock / 2)
 			ife = adc_clock - ife;
 	}
-	value = (u64)65536 * ife + adc_clock / 2;
-	do_div(value, adc_clock);
+	value = div_u64((u64)65536 * ife + adc_clock / 2, adc_clock);
 	*input_freq = -value;
 
 	dprintk("%s: if2 %d, ife %d, adc_clock %d => %d / 0x%x\n",
-- 
2.7.0



From lkp at intel.com  Fri Feb 12 06:28:19 2016
From: lkp at intel.com (kbuild test robot)
Date: Fri, 12 Feb 2016 22:28:19 +0800
Subject: [PATCH 1/4] net: ethernet: dwmac: add Ethernet glue logic for
 stm32 chip
In-Reply-To: <1454511275-9791-2-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <201602122254.EsWZQE5Z%fengguang.wu@intel.com>

Hi Alexandre,

[auto build test WARNING on net/master]
[also build test WARNING on v4.5-rc3 next-20160212]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Alexandre-TORGUE/Add-Ethernet-support-on-STM32F429/20160203-225940
config: um-allyesconfig (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=um 

All warnings (new ones prefixed by >>):

warning: (ST_IRQCHIP && HIP04_ETH && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && DWMAC_STM32 && TI_CPSW && PINCTRL_ROCKCHIP && PINCTRL_DOVE && POWER_RESET_KEYSTONE && POWER_RESET_SYSCON && POWER_RESET_SYSCON_POWEROFF && S3C2410_WATCHDOG && VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 17523 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/d3544f93/attachment-0001.obj>

From robh at kernel.org  Fri Feb 12 06:36:16 2016
From: robh at kernel.org (Rob Herring)
Date: Fri, 12 Feb 2016 08:36:16 -0600
Subject: [PATCH v5 2/3] Documentation: gpio: Update description for
 X-Gene standby GPIO controller DTS binding
In-Reply-To: <CAFopSPQBjXQZwG-Phfc+xJ5Kn6dXPakT6Hg5qT-ByXG06p8wgg@mail.gmail.com>
References: <1454041735-8434-1-git-send-email-qnguyen@apm.com>
 <1454041735-8434-3-git-send-email-qnguyen@apm.com>
 <20160201153502.GA19725@rob-hp-laptop>
 <CAFopSPQBjXQZwG-Phfc+xJ5Kn6dXPakT6Hg5qT-ByXG06p8wgg@mail.gmail.com>
Message-ID: <20160212143616.GA1603@rob-hp-laptop>

On Tue, Feb 02, 2016 at 08:46:25AM +0700, Quan Nguyen wrote:
> On Mon, Feb 1, 2016 at 10:35 PM, Rob Herring <robh at kernel.org> wrote:
> > On Fri, Jan 29, 2016 at 11:28:54AM +0700, Quan Nguyen wrote:
> >> Update description for X-Gene standby GPIO controller DTS binding to
> >> support GPIO line configuration as input, output or external IRQ pin.
> >>
> >> Signed-off-by: Y Vo <yvo at apm.com>
> >> Signed-off-by: Quan Nguyen <qnguyen at apm.com>
> >> ---
> >>  .../devicetree/bindings/gpio/gpio-xgene-sb.txt     | 47 ++++++++++++++++++----
> >>  1 file changed, 40 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
> >> index dae1300..7b8b4cb 100644
> >> --- a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
> >> +++ b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
> >> @@ -1,10 +1,20 @@
> >>  APM X-Gene Standby GPIO controller bindings
> >>
> >> -This is a gpio controller in the standby domain.
> >> -
> >> -There are 20 GPIO pins from 0..21. There is no GPIO_DS14 or GPIO_DS15,
> >> -only GPIO_DS8..GPIO_DS13 support interrupts. The IRQ mapping
> >> -is currently 1-to-1 on interrupts 0x28 thru 0x2d.
> >> +This is a gpio controller in the standby domain. It also supports interrupt in
> >> +some particular pins which are sourced to its parent interrupt controller
> >> +as diagram below:
> >> +                           +-----------------+
> >> +                           | X-Gene standby  |
> >> +                           | GPIO controller +--------- GPIO_0
> >> ++------------+             |                 | ...
> >> +| Parent IRQ |             |                 +--------- GPIO_8/EXT_INT_0
> >> +| controller |  EXT_INT_0  |                 | ...
> >> +| (GICv2)    +-------------+                 +--------- GPIO_[N+8]/EXT_INT_N
> >> +|            |  ...        |                 |
> >> +|            |  EXT_INT_N  |                 +--------- GPIO_[N+9]
> >> +|            +-------------+                 | ...
> >> +|            |             |                 +--------- GPIO_MAX
> >> ++------------+             +-----------------+
> >>
> >>  Required properties:
> >>  - compatible: "apm,xgene-gpio-sb" for the X-Gene Standby GPIO controller
> >> @@ -15,10 +25,18 @@ Required properties:
> >>               0 = active high
> >>               1 = active low
> >>  - gpio-controller: Marks the device node as a GPIO controller.
> >> -- interrupts: Shall contain exactly 6 interrupts.
> >> +- interrupts: The EXT_INT_0 parent interrupt resource must be listed first.
> >> +- interrupt-parent: Phandle of the parent interrupt controller.
> >> +- interrupt-cells: Should be two.
> >> +       - first cell is 0-N coresponding for EXT_INT_0 to EXT_INT_N.
> >> +       - second cell is used to specify flags.
> >> +- interrupt-controller: Marks the device node as an interrupt controller.
> >> +- apm,nr-gpios: Optional, specify number of gpios pin.
> >> +- apm,nr-irqs: Optional, specify number of interrupt pins.
> >
> > When is this not 6?
> >
> Hi Rob,  by default, this should be 6, but I think this property can
> help in cases:
> + Used only 5(or less) first pin as interrupt.
> + For similar device which has different interrupt pins (8 for example).
> My idea is to make it a bit more generic by using this optional property.

What is similar device? Another SoC? board? Is 6 fixed in the SoC? I 
think you need more specific compatible string with the SoC name in it 
to determine these setting rather than trying to do something generic.

Rob


From bharat.kumar.gogada at xilinx.com  Fri Feb 12 06:45:50 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Fri, 12 Feb 2016 14:45:50 +0000
Subject: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL
 PCIe Host Controller
In-Reply-To: <8520D5D51A55D047800579B0941471982587422C@XAP-PVEXMBX01.xlnx.xilinx.com>
References: <1448798633-12697-1-git-send-email-bharatku@xilinx.com>
 <20151209231921.GI31930@localhost>
 <8520D5D51A55D047800579B09414719825869A85@XAP-PVEXMBX01.xlnx.xilinx.com>
 <20151210201817.GB367@localhost>
 <8520D5D51A55D047800579B09414719825869EDC@XAP-PVEXMBX01.xlnx.xilinx.com>
 <8520D5D51A55D047800579B0941471982586BC8D@XAP-PVEXMBX01.xlnx.xilinx.com>
 <20160110220819.GA25883@localhost>
 <8520D5D51A55D047800579B09414719825870721@XAP-PVEXMBX01.xlnx.xilinx.com>
 <8520D5D51A55D047800579B0941471982587422C@XAP-PVEXMBX01.xlnx.xilinx.com>
Message-ID: <8520D5D51A55D047800579B094147198258821DA@XAP-PVEXMBX01.xlnx.xilinx.com>

> Ping
> 
> > Subject: RE: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for
> > Xilinx NWL PCIe Host Controller
> >
> >  > On Mon, Dec 21, 2015 at 05:23:47AM +0000, Bharat Kumar Gogada wrote:
> > > > Hi Bjorn, can you comment on this. Marc has also replied for query
> > > > on
> > > irq_dispose_mapping().
> > >
> > > I'm not sure exactly what you want me to comment on.
> > I wanted you to check for Marc's reply.
> > >
> > > > > Subject: RE: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for
> > > > > Xilinx NWL PCIe Host Controller
> > > > >
> > > > > > Subject: Re: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support
> > > > > > for Xilinx NWL PCIe Host Controller
> > > > > >
> > > > > > [+cc Marc for irq_dispose_mapping() question]
> > > > > >
> > > > > > On Thu, Dec 10, 2015 at 02:10:34PM +0000, Bharat Kumar Gogada
> > > wrote:
> > > > > > I'm trying to figure out what the difference is between these
> > > > > > two checks and why you have both of them:
> > > > > >
> > > > > > > +	if (bus->number == pcie->root_busno && devfn > 0)
> > > > > > > +	if (bus->primary == pcie->root_busno && devfn > 0)
> > > > > >
> > > > > > If I understand correctly, pcie->root_busno is the bus number
> > > > > > of the Root Port device (likely 00).  I think the "bus->number
> > > > > > ==
> > > > > > pcie->root_busno && devfn > 0" check means that the Root Port,
> > > > > > pcie->e.g.,
> > > > > > 00:00.0, is the only device allowed on bus 00.  Often a Root
> > > > > > Complex contains several Root Ports and other integrated
> > > > > > devices that typically are
> > > > > on bus 00.
> > > > > > But in your case, I think you're saying there is only the
> > > > > > single Root Port and no other devices.
> > > > > >
> > > > > > I think that first check takes care of everything on bus 00,
> > > > > > so I'm trying to figure out what the second check is for.
> > > > > > Assume your Root Port is device
> > > > > > 00:00.0 and it is a bridge to [bus 01-ff].  Then we have two
> > > > > > pci_bus structs with these values:
> > > > > >
> > > > > >   bus->number = 00
> > > > > >   bus->primary = 00
> > > > > >   bus->busn_res = [bus 00-ff]
> > > > > >
> > > > > >   bus->number = 01
> > > > > >   bus->primary = 00
> > > > > >   bus->busn_res = [bus 01-ff]
> > > > > >
> > > > > > Because of the first check, 00:00.0 is the only possible
> > > > > > device on bus 00, and because of the second check, 01:00.0 is
> > > > > > the only possible device on
> > > > > bus 01.
> > > > > > Therefore, you don't support a multifunction device connected
> > > > > > to the Root Port.  Right?
> > > > > >
> > > > > We support multifunction devices also, so this check should not
> > > > > be there, will remove this check in next patch.
> > >
> > > It looks like you're planning to change this.
> > No, our core supports multifunction devices it was my
> > misunderstanding, due to which this condition was present.
> > > > > > > > > +		return false;
> > > > > > > > > +
> > > > > > > > > +	return true;
> > > > > > > > > +}
> > > > > > > > > + * nwl_setup_sspl - Set Slot Power limit
> > > > > > > > > + *
> > > > > > > > > + * @pcie: PCIe port information  */ static int
> > > > > > > > > +nwl_setup_sspl(struct nwl_pcie *pcie)
> > > > > > > >
> > > > > > > The Set_Slot_Power_Limit Message includes a one DW data
> > payload.
> > > > > > > The data payload is copied from the Slot Capabilities
> > > > > > > register of the Downstream Port and is written into the
> > > > > > > Device Capabilities register of the Upstream Port on the
> > > > > > > other side of the Link. Bits 9:8 of the data payload map to
> > > > > > > the Slot Power Limit Scale field and bits 7:0 map to the
> > > > > > > Slot Power Limit Value field. Bits 31:10 of the data payload
> > > > > > > must be set to all 0's by the Transmitter and ignored by the
> > > > > Receiver.
> > > > > >
> > > > > > > This Message is sent automatically by the Downstream Port
> > > > > > > (of a Root Complex or a Switch) when one of the following
> > > > > > > events
> > occurs:
> > > > > > > -> On a Configuration Write to the Slot Capabilities
> > > > > > > -> register (see
> > > > > > > Section 7.8.9) when the Data Link Layer reports DL_Up status.
> > > > > >
> > > > > > I interpret this as meaning "the *hardware* automatically
> > > > > > sends a Set_Slot_Power_Limit Message."  There's no mention of
> > > > > > software doing anything other than the configuration write.
> > > > > >
> > > > > > If your hardware doesn't do that, I think it's a defect.  It's
> > > > > > fine to work around it, but we should have a comment to that
> > > > > > effect so people don't copy the code to new drivers that don't
> > > > > > need
> > it.
> > > > >
> > > > > Our hardware is not capable of doing it, so we are doing it
> > > > > software. Yes I will add some comments.
> > >
> > > And add a comment here.
> > >
> > You meant to add comments for the function clearly mentioning that
> > hardware doesn't support this so doing it software ?
> >
> > > > > > It's a little strange that 7.8.9 talks about writing to this
> > > > > > register when all of its fields are HwInit and supposedly
> > > > > > read-only.  I had assumed devices would use strapping or
> > > > > > implementation-specific registers to set the Slot Power
> > > > > > values, but maybe some devices use direct
> > > > > writes to Slot Capabilities instead.
> > > > > >
> > > > > > BTW, I noticed a related lspci bug: it didn't decode the
> > > > > > Capture Slot Power Limit in Device Capabilities of Endpoints.
> > > > > > I posted a fix for that
> > > > > separately.
> > > > > >
> > > > > > The Slot Power Limit (in Slot Capabilities) indicates how much
> > > > > > power the slot can supply to a downstream device.  That's a
> > > > > > function of the platform design, so it seems like this is
> > > > > > something you want to set via DT or some other mechanism that
> > > > > > knows
> > > about the platform.
> > > > > > Intercepting all config writes and updating it with whatever
> > > > > > the caller supplies doesn't sound wise.  The value might be
> > > > > > coming from setpci or some other source with no knowledge of the
> platform.
> > > > >
> > > > > Agreed, but this is what can be done, it is difficult to
> > > > > determine who does what.
> > >
> > > Your driver is based on DT.  What prevents you from adding a DT
> > > property that shows the slot power capability?
> > >
> > You meant to add a DT property, Example: xlnx,slot_power_cap; as
> > required property, and use this property to call nwl_setup_sspl
> > function. Currently this function is being invoked in config write
> > function if the condition meets a write to slot power capabilities register.
> > > > > > > > > +			status = nwl_bridge_readl(pcie,
> > > > > TX_PCIE_MSG)
> > > > > > > > > +						  &
> MSG_DONE_BIT;
> > > > > > > > > +			if (status) {
> > > > > > > > > +				status =
> nwl_bridge_readl(pcie,
> > > > > > > > TX_PCIE_MSG)
> > > > > > > > > +						  &
> > > > > MSG_DONE_STATUS_BIT;
> > > > > >
> > > > > > > > It's not clear to me whether you need to re-read
> > > > > > > > TX_PCIE_MSG
> > > here.
> > > > > > >
> > > > > > > MSG_DONE_BIT qualifies MSG_DONE_STATUS_BIT; so value of
> > > > > > > MSG_DONE_STATUS_BIT is valid only when MSG_DONE_BIT = 1
> > > > > >
> > > > > > That doesn't answer the question of whether another read is
> > required.
> > > > > > In fact, I would argue that if MSG_DONE_STATUS_BIT is only
> > > > > > valid when MSG_DONE_BIT = 1, you *should* only do one read,
> > > > > > because
> > > you
> > > > > > want to capture both bits simultaneously so you know they're
> > > > > > consistent, e.g.,
> > > > > >
> > > > > >   status = nwl_bridge_readl(pcie, TX_PCIE_MSG);
> > > > > >   if (status & MSG_DONE_BIT) {
> > > > > >     if (status & MSG_DONE_STATUS_BIT)
> > > > > >       ...
> > > > > >   }
> > > > > >
> > > > > > If you read the register twice, you always have to worry about
> > > > > > what changes MSG_DONE_BIT, and how you guarantee that the
> > > second
> > > > > > read happens before MSG_DONE_BIT changes.
> > > > > >
> > > > > Agreed, will do it in this way, once will also confirm with IP
> > > > > owner regarding both bits being updated parallel.
> > >
> > > It sounds like you're working on resolving this.
> > >
> > > Did I miss a question for me?
> >
> > Since IP owner is different, we don't have exact information by that
> > time we commented, now we got Information from owner that both buts
> > simultaneously.
> >
> > Bharat
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in the
> body of a message to majordomo at vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html


From robh at kernel.org  Fri Feb 12 06:49:10 2016
From: robh at kernel.org (Rob Herring)
Date: Fri, 12 Feb 2016 08:49:10 -0600
Subject: [PATCH v3 08/12] devicetree: bindings: add DT binding for the
 Marvell Armada 3700 SoC family
In-Reply-To: <1454951660-13289-9-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
 <1454951660-13289-9-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160212144910.GA11975@rob-hp-laptop>

On Mon, Feb 08, 2016 at 06:14:16PM +0100, Gregory CLEMENT wrote:
> The Marvell Armada 3700 is a family of ARMv8 CA53 SoCs. This commit
> introduces the Device Tree binding that documents the top-level
> compatible strings for Armada 3700 based platforms.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  .../devicetree/bindings/arm/marvell/armada-37xx.txt      | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Fri Feb 12 06:51:00 2016
From: robh at kernel.org (Rob Herring)
Date: Fri, 12 Feb 2016 08:51:00 -0600
Subject: [PATCH v1 2/2] iio: dac: vf610_dac: Add IIO DAC driver for
 Vybrid SoC
In-Reply-To: <5a699d45c89d239f3e49fa83d16a9b467016e219.1454939346.git.maitysanchayan@gmail.com>
References: <cover.1454939346.git.maitysanchayan@gmail.com>
 <5a699d45c89d239f3e49fa83d16a9b467016e219.1454939346.git.maitysanchayan@gmail.com>
Message-ID: <20160212145100.GA12514@rob-hp-laptop>

On Tue, Feb 09, 2016 at 10:56:06AM +0530, Sanchayan Maity wrote:
> Add driver support for DAC peripheral on Vybrid SoC.
> 
> Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
> ---
>  .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++

Acked-by: Rob Herring <robh at kernel.org>

>  drivers/iio/dac/Kconfig                            |   8 +
>  drivers/iio/dac/Makefile                           |   1 +
>  drivers/iio/dac/vf610_dac.c                        | 302 +++++++++++++++++++++
>  4 files changed, 331 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>  create mode 100644 drivers/iio/dac/vf610_dac.c


From peter.maydell at linaro.org  Fri Feb 12 06:53:51 2016
From: peter.maydell at linaro.org (Peter Maydell)
Date: Fri, 12 Feb 2016 14:53:51 +0000
Subject: [PATCHv2] arm64: Rework valid_user_regs
In-Reply-To: <1455285858-11757-1-git-send-email-mark.rutland@arm.com>
References: <1455285858-11757-1-git-send-email-mark.rutland@arm.com>
Message-ID: <CAFEAcA_XGrPB=2GnQwW4Jr8eE9UqbTAgRb86qCkX+rw25u4yNg@mail.gmail.com>

On 12 February 2016 at 14:04, Mark Rutland <mark.rutland at arm.com> wrote:
> We validate pstate using PSR_MODE32_BIT, which is part of the
> user-provided pstate (and cannot be trusted). Also, we conflate
> validation of AArch32 and AArch64 pstate values, making the code
> difficult to reason about.
>
> Instead, validate the pstate value based on the associated task. The
> task may or may not be current (e.g. when using ptrace), so this must be
> passed explicitly by callers. To avoid circular header dependencies via
> sched.h, is_compat_task is pulled out of asm/ptrace.h.
>
> To make the code possible to reason about, the AArch64 and AArch32
> validation is split into separate functions. Software must respect the
> RES0 policy for SPSR bits, and thus the kernel mirrors the hardware
> policy (RAZ/WI) for bits as-yet unallocated. When these acquire an
> architected meaning writes may be permitted (potentially with additional
> validation).

> +       /* Force PSR to a valid 32-bit EL0t */
> +       regs->pstate |= PSR_MODE32_BIT;
> +       regs->pstate &= PSR_f | PSR_s | (PSR_x & ~COMPAT_PSR_A_BIT) | \
> +                       COMPAT_PSR_T_BIT;
> +

I think the consensus from the v1 review was to drop these PSR_[fsx] masks?

thanks
-- PMM


From ard.biesheuvel at linaro.org  Fri Feb 12 06:57:22 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 15:57:22 +0100
Subject: [PATCH v3 0/4] arm64: avoid early __va translations
Message-ID: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>

This is a somewhat cleaner approach for dealing with the issue that the
early FDT performs __va() translations before the linear mapping has been
set up. Being able to defer the assignment of memstart_addr until after we
have discovered all of memory is an important piece of functionality, not
only for KASLR but also for mapping the linear region as efficiently as
possible.

Changes since v2:
- replace __weak function in patches #1 and #2 with a preprocessor macro
- add patch to address the circular header dependency when including
  asm/bug.h in asm/memory.h
- turned the hack that adds the BUG_ON() into a proper patch

Patch #1 refactors the early FDT code so that the actual assignment of
initrd_start and initrd_end (which is where the __va() translations are
performed) can be overridden in architecture specific code.

Patch #2 performs the override, and only records the physical addresses
as they are found in the /chosen node, or on the command line, and defers
the __va() translation until after memstart_addr has been assigned.

Patch #3 reshuffles some #includes and #defines so that asm/bug.h can be
included (and used) in asm/memory.h

Patch #4 implements a BUG_ON() check to ensure that no references to
memstart_addr are made before it has been assigned.

Ard Biesheuvel (4):
  of/fdt: factor out assignment of initrd_start/initrd_end
  arm64: defer __va translation of initrd_start and initrd_end
  arm64: prevent potential circular header dependencies in asm/bug.h
  arm64: prevent __va() translations before memstart_addr is assigned

 arch/arm64/include/asm/bug.h            |  2 +-
 arch/arm64/include/asm/debug-monitors.h |  2 +-
 arch/arm64/include/asm/memory.h         | 12 ++++++++++-
 arch/arm64/kvm/hyp/debug-sr.c           |  1 +
 arch/arm64/mm/init.c                    | 21 +++++++++++++++-----
 drivers/of/fdt.c                        | 14 ++++++++++---
 6 files changed, 41 insertions(+), 11 deletions(-)

-- 
2.5.0



From ard.biesheuvel at linaro.org  Fri Feb 12 06:57:23 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 15:57:23 +0100
Subject: [PATCH v3 1/4] of/fdt: factor out assignment of
 initrd_start/initrd_end
In-Reply-To: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455289046-21321-2-git-send-email-ard.biesheuvel@linaro.org>

Since architectures may not yet have their linear mapping up and running
when the initrd address is discovered from the DT, factor out the
assignment of initrd_start and initrd_end, so that an architecture can
override it and use the translation it needs.

Cc: Rob Herring <robh at kernel.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/of/fdt.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 1f98156f8996..3e90bce70545 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -760,6 +760,16 @@ const void * __init of_flat_dt_match_machine(const void *default_match,
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
+#ifndef __early_init_dt_declare_initrd
+static void __early_init_dt_declare_initrd(unsigned long start,
+					   unsigned long end)
+{
+	initrd_start = (unsigned long)__va(start);
+	initrd_end = (unsigned long)__va(end);
+	initrd_below_start_ok = 1;
+}
+#endif
+
 /**
  * early_init_dt_check_for_initrd - Decode initrd location from flat tree
  * @node: reference to node containing initrd location ('chosen')
@@ -782,9 +792,7 @@ static void __init early_init_dt_check_for_initrd(unsigned long node)
 		return;
 	end = of_read_number(prop, len/4);
 
-	initrd_start = (unsigned long)__va(start);
-	initrd_end = (unsigned long)__va(end);
-	initrd_below_start_ok = 1;
+	__early_init_dt_declare_initrd(start, end);
 
 	pr_debug("initrd_start=0x%llx  initrd_end=0x%llx\n",
 		 (unsigned long long)start, (unsigned long long)end);
-- 
2.5.0



From ard.biesheuvel at linaro.org  Fri Feb 12 06:57:24 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 15:57:24 +0100
Subject: [PATCH v3 2/4] arm64: defer __va translation of initrd_start and
 initrd_end
In-Reply-To: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455289046-21321-3-git-send-email-ard.biesheuvel@linaro.org>

Commit 66f51676a095 ("arm64: allow kernel Image to be loaded anywhere in
physical memory") defers the assignment of memstart_addr to the point where
all memory has been discovered and possibly clipped based on the size of
the linear region and the presence of a mem= command line parameter.

However, this results in __va() translations that have been performed up
to this point to have been carried out with a preliminary, incorrect value
of memstart_addr, and these values need to be fixed up. So wire up the
generic support to declare the initrd addresses, and implement it without
__va() translations, and perform the translation after memstart_addr has
been assigned.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/memory.h |  8 ++++++++
 arch/arm64/mm/init.c            | 13 +++++++++----
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 083361531a61..c900883a3119 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -121,6 +121,14 @@
 #define IOREMAP_MAX_ORDER	(PMD_SHIFT)
 #endif
 
+#ifdef CONFIG_BLK_DEV_INITRD
+#define __early_init_dt_declare_initrd(__start, __end)			\
+	do {								\
+		initrd_start = (__start);				\
+		initrd_end = (__end);					\
+	} while (0)
+#endif
+
 #ifndef __ASSEMBLY__
 
 extern phys_addr_t		memstart_addr;
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 3a9fc46cbf80..ed85778b32e5 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -61,8 +61,8 @@ static int __init early_initrd(char *p)
 	if (*endp == ',') {
 		size = memparse(endp + 1, NULL);
 
-		initrd_start = (unsigned long)__va(start);
-		initrd_end = (unsigned long)__va(start + size);
+		initrd_start = start;
+		initrd_end = start + size;
 	}
 	return 0;
 }
@@ -213,8 +213,13 @@ void __init arm64_memblock_init(void)
 	 */
 	memblock_reserve(__pa(_text), _end - _text);
 #ifdef CONFIG_BLK_DEV_INITRD
-	if (initrd_start)
-		memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
+	if (initrd_start) {
+		memblock_reserve(initrd_start, initrd_end - initrd_start);
+
+		/* the generic initrd code expects virtual addresses */
+		initrd_start = __phys_to_virt(initrd_start);
+		initrd_end = __phys_to_virt(initrd_end);
+	}
 #endif
 
 	early_init_fdt_scan_reserved_mem();
-- 
2.5.0



From ard.biesheuvel at linaro.org  Fri Feb 12 06:57:25 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 15:57:25 +0100
Subject: [PATCH v3 3/4] arm64: prevent potential circular header dependencies
 in asm/bug.h
In-Reply-To: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455289046-21321-4-git-send-email-ard.biesheuvel@linaro.org>

Currently, using BUG_ON() in header files is cumbersome, due to the fact
that asm/bug.h transitively includes a lot of other header files, resulting
in the actual BUG_ON() invocation appearing before its definition in the
preprocessor input. So let's reverse the #include dependency between
asm/bug.h and asm/debug-monitors.h, by moving the definition of BUG_BRK_IMM
from the latter to the former. Also fix up one user of asm/debug-monitors.h
which relied on a transitive include.

Cc: Dave Martin <Dave.Martin at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/bug.h            | 2 +-
 arch/arm64/include/asm/debug-monitors.h | 2 +-
 arch/arm64/kvm/hyp/debug-sr.c           | 1 +
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/bug.h b/arch/arm64/include/asm/bug.h
index 4a748ce9ba1a..679d49221998 100644
--- a/arch/arm64/include/asm/bug.h
+++ b/arch/arm64/include/asm/bug.h
@@ -18,7 +18,7 @@
 #ifndef _ARCH_ARM64_ASM_BUG_H
 #define _ARCH_ARM64_ASM_BUG_H
 
-#include <asm/debug-monitors.h>
+#define BUG_BRK_IMM			0x800
 
 #ifdef CONFIG_GENERIC_BUG
 #define HAVE_ARCH_BUG
diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
index 279c85b5ec09..e893a1fca9c2 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -20,6 +20,7 @@
 
 #include <linux/errno.h>
 #include <linux/types.h>
+#include <asm/bug.h>
 #include <asm/esr.h>
 #include <asm/insn.h>
 #include <asm/ptrace.h>
@@ -57,7 +58,6 @@
 #define FAULT_BRK_IMM			0x100
 #define KGDB_DYN_DBG_BRK_IMM		0x400
 #define KGDB_COMPILED_DBG_BRK_IMM	0x401
-#define BUG_BRK_IMM			0x800
 
 /*
  * BRK instruction encoding
diff --git a/arch/arm64/kvm/hyp/debug-sr.c b/arch/arm64/kvm/hyp/debug-sr.c
index c9c1e97501a9..2f8bca8af295 100644
--- a/arch/arm64/kvm/hyp/debug-sr.c
+++ b/arch/arm64/kvm/hyp/debug-sr.c
@@ -18,6 +18,7 @@
 #include <linux/compiler.h>
 #include <linux/kvm_host.h>
 
+#include <asm/debug-monitors.h>
 #include <asm/kvm_asm.h>
 #include <asm/kvm_mmu.h>
 
-- 
2.5.0



From ard.biesheuvel at linaro.org  Fri Feb 12 06:57:26 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 15:57:26 +0100
Subject: [PATCH v3 4/4] arm64: prevent __va() translations before
 memstart_addr is assigned
In-Reply-To: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455289046-21321-5-git-send-email-ard.biesheuvel@linaro.org>

Since memstart_addr is assigned relatively late in the boot code,
after generic code like DT parsing and memblock manipulation has
already occurred, we need to ensure that no __va() translation occur
until memstart_addr has been set to a meaningful value.

So initialize memstart_addr to a value that cannot represent a valid
physical address, and BUG() if memstart_addr is referenced while it
still holds this value. Note that the > comparison against LLONG_MAX
(not ULLONG_MAX) resolves to a single tbnz instruction that performs
a conditional jump to a brk instruction that is emitted out of line.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/memory.h | 4 +++-
 arch/arm64/mm/init.c            | 8 +++++++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index c900883a3119..ae398919fb5f 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -24,6 +24,7 @@
 #include <linux/compiler.h>
 #include <linux/const.h>
 #include <linux/types.h>
+#include <asm/bug.h>
 #include <asm/sizes.h>
 
 /*
@@ -133,7 +134,8 @@
 
 extern phys_addr_t		memstart_addr;
 /* PHYS_OFFSET - the physical address of the start of memory. */
-#define PHYS_OFFSET		({ memstart_addr; })
+#define PHYS_OFFSET		\
+	({ BUG_ON(memstart_addr > LLONG_MAX); memstart_addr; })
 
 /* the virtual base of the kernel image (minus TEXT_OFFSET) */
 extern u64			kimage_vaddr;
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index ed85778b32e5..023c41f22b5b 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -48,7 +48,13 @@
 
 #include "mm.h"
 
-phys_addr_t memstart_addr __read_mostly = 0;
+/*
+ * We need to be able to catch inadvertent references to memstart_addr
+ * that occur (potentially in generic code) before arm64_memblock_init()
+ * executes, which assigns it its actual value. So use a default value
+ * that cannot be mistaken for a real physical address.
+ */
+phys_addr_t memstart_addr __read_mostly = ULLONG_MAX;
 phys_addr_t arm64_dma_phys_limit __read_mostly;
 
 #ifdef CONFIG_BLK_DEV_INITRD
-- 
2.5.0



From Michael.Williams at arm.com  Fri Feb 12 06:55:02 2016
From: Michael.Williams at arm.com (Michael Williams)
Date: Fri, 12 Feb 2016 14:55:02 +0000
Subject: [PATCH V3 6/6] coresight-stm: adding driver for CoreSight STM
 component
In-Reply-To: <CANLsYkxvLFu1C+_H9c0EoMebLQu1gnwt9bqY6_R3j+ua2w+xMg@mail.gmail.com>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
 <1454756672-12790-7-git-send-email-zhang.chunyan@linaro.org>
 <CANLsYkxvLFu1C+_H9c0EoMebLQu1gnwt9bqY6_R3j+ua2w+xMg@mail.gmail.com>
Message-ID: <VI1PR08MB06708C5EA9DEE2D71C13FFAA8AA90@VI1PR08MB0670.eurprd08.prod.outlook.com>

Mathieu Poirier [mailto:mathieu.poirier at linaro.org] wrote:
> On 6 February 2016 at 04:04, Chunyan Zhang <zhang.chunyan at linaro.org> wrote:
>> From: Pratik Patel <pratikp at codeaurora.org>
>>
>> This driver adds support for the STM CoreSight IP block, allowing any
>> system compoment (HW or SW) to log and aggregate messages via a
>> single entity.
>>
>> The CoreSight STM exposes an application defined number of channels
>> called stimulus port.  Configuration is done using entries in sysfs
>> and channels made available to userspace via configfs.
>>
>> Signed-off-by: Pratik Patel <pratikp at codeaurora.org>
>> Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
>> Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
>> ---
>>  .../ABI/testing/sysfs-bus-coresight-devices-stm    |  53 ++
>>  Documentation/trace/coresight.txt                  |  37 +-
>>  drivers/hwtracing/coresight/Kconfig                |  11 +
>>  drivers/hwtracing/coresight/Makefile               |   1 +
>>  drivers/hwtracing/coresight/coresight-stm.c        | 928 +++++++++++++++++++++
>>  include/linux/coresight-stm.h                      |   6 +
>>  include/uapi/linux/coresight-stm.h                 |  12 +
>>  7 files changed, 1046 insertions(+), 2 deletions(-)
>>  create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>>  create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
>>  create mode 100644 include/linux/coresight-stm.h
>>  create mode 100644 include/uapi/linux/coresight-stm.h
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>> new file mode 100644
>> index 0000000..a1d7022
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>> @@ -0,0 +1,53 @@
>> +What:          /sys/bus/coresight/devices/<memory_map>.stm/enable_source
>> +Date:          February 2016
>> +KernelVersion: 4.5
>> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
>> +Description:   (RW) Enable/disable tracing on this specific trace macrocell.
>> +               Enabling the trace macrocell implies it has been configured
>> +               properly and a sink has been identidifed for it.  The path
>> +               of coresight components linking the source to the sink is
>> +               configured and managed automatically by the coresight framework.
>> +
>> +What:          /sys/bus/coresight/devices/<memory_map>.stm/hwevent_enable
>> +Date:          February 2016
>> +KernelVersion: 4.5
>> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
>> +Description:   (RW) Provides access to the HW event enable register, used in
>> +               conjunction with HW event bank select register.
>> +
>> +What:          /sys/bus/coresight/devices/<memory_map>.stm/hwevent_select
>> +Date:          February 2016
>> +KernelVersion: 4.5
>> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
>> +Description:   (RW) Gives access to the HW event block select register
>> +               (STMHEBSR) in order to configure up to 256 channels.  Used in
>> +               conjunction with "hwevent_enable" register as described above.
>> +
>> +What:          /sys/bus/coresight/devices/<memory_map>.stm/port_enable
>> +Date:          February 2016
>> +KernelVersion: 4.5
>> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
>> +Description:   (RW) Provides access to the stimlus port enable register
>> +               (STMSPER).  Used in conjunction with "port_select" described
>> +               below.
>> +
>> +What:          /sys/bus/coresight/devices/<memory_map>.stm/port_select
>> +Date:          February 2016
>> +KernelVersion: 4.5
>> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
>> +Description:   (RW) Used to determine which bank of stimulus port bit in
>> +               register STMSPER (see above) apply to.
>> +
>> +What:          /sys/bus/coresight/devices/<memory_map>.stm/status
>> +Date:          February 2016
>> +KernelVersion: 4.5
>> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
>> +Description:   (R) List various control and status registers.  The specific
>> +               layout and content is driver specific.
>> +
>> +What:          /sys/bus/coresight/devices/<memory_map>.stm/traceid
>> +Date:          February 2016
>> +KernelVersion: 4.5
>> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
>> +Description:   (RW) Holds the trace ID that will appear in the trace stream
>> +               coming from this trace entity.
>> diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
>> index 0a5c329..a33c88c 100644
>> --- a/Documentation/trace/coresight.txt
>> +++ b/Documentation/trace/coresight.txt
>> @@ -190,8 +190,8 @@ expected to be accessed and controlled using those entries.
>>  Last but not least, "struct module *owner" is expected to be set to reflect
>>  the information carried in "THIS_MODULE".
>>
>> -How to use
>> -----------
>> +How to use the tracer modules
>> +-----------------------------
>>
>>  Before trace collection can start, a coresight sink needs to be identify.
>>  There is no limit on the amount of sinks (nor sources) that can be enabled at
>> @@ -297,3 +297,36 @@ Info                                    Tracing enabled
>>  Instruction     13570831        0x8026B584      E28DD00C        false   ADD
> sp,sp,#0xc
>>  Instruction     0       0x8026B588      E8BD8000        true    LDM      sp!,{pc}
>>  Timestamp                                       Timestamp: 17107041535
>> +
>> +How to use the STM module
>> +-------------------------
>> +
>> +Using the System Trace Macrocell module is the same as the tracers - the only
>> +difference is that clients are driving the trace capture rather
>> +than the program flow through the code.
>> +
>> +As with any other CoreSight component, specifics about the STM tracer can be
>> +found in sysfs with more information on each entry being found in [1]:
>> +
>> +root at genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
>> +enable_source   hwevent_select  port_enable     subsystem       uevent
>> +hwevent_enable  mgmt            port_select     traceid
>> +root at genericarmv8:~#
>> +
>> +Like any other source a sink needs to be identified and the STM enabled before
>> +being used:
>> +
>> +root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
>> +root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
>> +
>> +From there user space applications can request and use channels using the devfs
>> +interface provided for that purpose by the generic STM API:
>> +
>> +root at genericarmv8:~# ls -l /dev/20100000.stm
>> +crw-------    1 root     root       10,  61 Jan  3 18:11 /dev/20100000.stm
>> +root at genericarmv8:~#
>> +
>> +Details on how to use the generic STM API can be found here [2].
>> +
>> +[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>> +[2]. Documentation/trace/stm.txt
>> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
>> index c85935f..f4a8bfa 100644
>> --- a/drivers/hwtracing/coresight/Kconfig
>> +++ b/drivers/hwtracing/coresight/Kconfig
>> @@ -77,4 +77,15 @@ config CORESIGHT_QCOM_REPLICATOR
>>           programmable ATB replicator sends the ATB trace stream from the
>>           ETB/ETF to the TPIUi and ETR.
>>
>> +config CORESIGHT_STM
>> +       bool "CoreSight System Trace Macrocell driver"
>> +       depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) || ARM64
>> +       select CORESIGHT_LINKS_AND_SINKS
>> +       select STM
>> +       help
>> +         This driver provides support for hardware assisted software
>> +         instrumentation based tracing. This is primarily used for
>> +         logging useful software events or data coming from various entities
>> +         in the system, possibly running different OSs
>> +
>>  endif
>> diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
>> index 99f8e5f..1f6eaec 100644
>> --- a/drivers/hwtracing/coresight/Makefile
>> +++ b/drivers/hwtracing/coresight/Makefile
>> @@ -11,3 +11,4 @@ obj-$(CONFIG_CORESIGHT_LINKS_AND_SINKS) += coresight-funnel.o \
>>  obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o coresight-etm-cp14.o
>>  obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
>>  obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
>> +obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
>> diff --git a/drivers/hwtracing/coresight/coresight-stm.c
> b/drivers/hwtracing/coresight/coresight-stm.c
>> new file mode 100644
>> index 0000000..01b3521
>> --- /dev/null
>> +++ b/drivers/hwtracing/coresight/coresight-stm.c
>> @@ -0,0 +1,928 @@
>> +/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * Initial implementation by Pratik Patel
>> + * (C) 2014-2015 Pratik Patel <pratikp at codeaurora.org>
>> + *
>> + * Serious refactoring, code cleanup and upgrading to the Coresight upstream
>> + * framework by Mathieu Poirier
>> + * (C) 2015-2016 Mathieu Poirier <mathieu.poirier at linaro.org>
>> + *
>> + * Guaranteed timing and support for various packet type coming from the
>> + * generic STM API by Chunyan Zhang
>> + * (C) 2015-2016 Chunyan Zhang <zhang.chunyan at linaro.org>
>> + */
>> +#include <linux/amba/bus.h>
>> +#include <linux/bitmap.h>
>> +#include <linux/clk.h>
>> +#include <linux/coresight.h>
>> +#include <linux/coresight-stm.h>
>> +#include <linux/err.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of_address.h>
>> +#include <linux/pm_runtime.h>
>> +#include <linux/stm.h>
>> +
>> +#include "coresight-priv.h"
>> +
>> +#define STMDMASTARTR                   0xc04
>> +#define STMDMASTOPR                    0xc08
>> +#define STMDMASTATR                    0xc0c
>> +#define STMDMACTLR                     0xc10
>> +#define STMDMAIDR                      0xcfc
>> +#define STMHEER                                0xd00
>> +#define STMHETER                       0xd20
>> +#define STMHEBSR                       0xd60
>> +#define STMHEMCR                       0xd64
>> +#define STMHEMASTR                     0xdf4
>> +#define STMHEFEAT1R                    0xdf8
>> +#define STMHEIDR                       0xdfc
>> +#define STMSPER                                0xe00
>> +#define STMSPTER                       0xe20
>> +#define STMPRIVMASKR                   0xe40
>> +#define STMSPSCR                       0xe60
>> +#define STMSPMSCR                      0xe64
>> +#define STMSPOVERRIDER                 0xe68
>> +#define STMSPMOVERRIDER                        0xe6c
>> +#define STMSPTRIGCSR                   0xe70
>> +#define STMTCSR                                0xe80
>> +#define STMTSSTIMR                     0xe84
>> +#define STMTSFREQR                     0xe8c
>> +#define STMSYNCR                       0xe90
>> +#define STMAUXCR                       0xe94
>> +#define STMSPFEAT1R                    0xea0
>> +#define STMSPFEAT2R                    0xea4
>> +#define STMSPFEAT3R                    0xea8
>> +#define STMITTRIGGER                   0xee8
>> +#define STMITATBDATA0                  0xeec
>> +#define STMITATBCTR2                   0xef0
>> +#define STMITATBID                     0xef4
>> +#define STMITATBCTR0                   0xef8
>> +
>> +#define STM_32_CHANNEL                 32
>> +#define BYTES_PER_CHANNEL              256
>> +#define STM_TRACE_BUF_SIZE             4096
>> +#define STM_SW_MASTER_END              127
>> +
>> +/* Register bit definition */
>> +#define STMTCSR_BUSY_BIT               23
>> +/* Reserve the first 10 channels for kernel usage */
>> +#define STM_CHANNEL_OFFSET             0
>> +
>> +enum stm_pkt_type {
>> +       STM_PKT_TYPE_DATA       = 0x98,
>> +       STM_PKT_TYPE_FLAG       = 0xE8,
>> +       STM_PKT_TYPE_TRIG       = 0xF8,
>> +};
>> +
>> +#define stm_channel_addr(drvdata, ch)  (drvdata->chs.base +    \
>> +                                       (ch * BYTES_PER_CHANNEL))
>> +#define stm_channel_off(type, opts)    (type & ~opts)
>> +
>> +static int boot_nr_channel;
>> +
>> +module_param_named(
>> +       boot_nr_channel, boot_nr_channel, int, S_IRUGO
>> +);
>> +
>> +/**
>> + * struct channel_space - central management entity for extended ports
>> + * @base:              memory mapped base address where channels start.
>> + * @guaraneed:         is the channel delivery guaranteed.
>> + */
>> +struct channel_space {
>> +       void __iomem            *base;
>> +       unsigned long           *guaranteed;
>> +};
>> +
>> +/**
>> + * struct stm_drvdata - specifics associated to an STM component
>> + * @base:              memory mapped base address for this component.
>> + * @dev:               the device entity associated to this component.
>> + * @atclk:             optional clock for the core parts of the STM.
>> + * @csdev:             component vitals needed by the framework.
>> + * @spinlock:          only one at a time pls.
>> + * @chs:               the channels accociated to this STM.
>> + * @stm:               structure associated to the generic STM interface.
>> + * @enable:            this STM is being used.
>> + * @traceid:           value of the current ID for this component.
>> + * @write_max:         Maximus bytes this STM can write at a time.
>> + * @write_64bit:       whether this STM supports 64 bit access.
>> + * @stmsper:           settings for register STMSPER.
>> + * @stmspscr:          settings for register STMSPSCR.
>> + * @numsp:             the total number of stimulus port support by this STM.
>> + * @stmheer:           settings for register STMHEER.
>> + * @stmheter:          settings for register STMHETER.
>> + * @stmhebsr:          settings for register STMHEBSR.
>> + */
>> +struct stm_drvdata {
>> +       void __iomem            *base;
>> +       struct device           *dev;
>> +       struct clk              *atclk;
>> +       struct coresight_device *csdev;
>> +       spinlock_t              spinlock;
>> +       struct channel_space    chs;
>> +       struct stm_data         stm;
>> +       bool                    enable;
>> +       u8                      traceid;
>> +       u8                      write_max;
>> +       u32                     write_64bit;
>> +       u32                     stmsper;
>> +       u32                     stmspscr;
>> +       u32                     numsp;
>> +       u32                     stmheer;
>> +       u32                     stmheter;
>> +       u32                     stmhebsr;
>> +};
>> +
>> +static void stm_hwevent_enable_hw(struct stm_drvdata *drvdata)
>> +{
>> +       CS_UNLOCK(drvdata->base);
>> +
>> +       writel_relaxed(drvdata->stmhebsr, drvdata->base + STMHEBSR);
>> +       writel_relaxed(drvdata->stmheter, drvdata->base + STMHETER);
>> +       writel_relaxed(drvdata->stmheer, drvdata->base + STMHEER);
>> +       writel_relaxed(0x01 |   /* Enable HW event tracing */
>> +                      0x04,    /* Error detection on event tracing */
>> +                      drvdata->base + STMHEMCR);
>> +
>> +       CS_LOCK(drvdata->base);
>> +}
>> +
>> +static void stm_port_enable_hw(struct stm_drvdata *drvdata)
>> +{
>> +       CS_UNLOCK(drvdata->base);
>> +       /* ATB trigger enable on direct writes to TRIG locations */
>> +       writel_relaxed(0x10,
>> +                      drvdata->base + STMSPTRIGCSR);
>> +       writel_relaxed(drvdata->stmspscr, drvdata->base + STMSPSCR);
>> +       writel_relaxed(drvdata->stmsper, drvdata->base + STMSPER);
>> +
>> +       CS_LOCK(drvdata->base);
>> +}
>> +
>> +static void stm_enable_hw(struct stm_drvdata *drvdata)
>> +{
>> +       if (drvdata->stmheer)
>> +               stm_hwevent_enable_hw(drvdata);
>> +
>> +       stm_port_enable_hw(drvdata);
>> +
>> +       CS_UNLOCK(drvdata->base);
>> +
>> +       /* 4096 byte between synchronisation packets */
>> +       writel_relaxed(0xFFF, drvdata->base + STMSYNCR);
>> +       writel_relaxed((drvdata->traceid << 16 | /* trace id */
>> +                       0x02 |                   /* timestamp enable */
>> +                       0x01),                   /* global STM enable */
>> +                       drvdata->base + STMTCSR);
>> +
>> +       CS_LOCK(drvdata->base);
>> +}
>> +
>> +static int stm_enable(struct coresight_device *csdev)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>> +
>> +       pm_runtime_get_sync(drvdata->dev);
>> +
>> +       spin_lock(&drvdata->spinlock);
>> +       stm_enable_hw(drvdata);
>> +       drvdata->enable = true;
>> +       spin_unlock(&drvdata->spinlock);
>> +
>> +       dev_info(drvdata->dev, "STM tracing enabled\n");
>> +       return 0;
>> +}
>> +
>> +static void stm_hwevent_disable_hw(struct stm_drvdata *drvdata)
>> +{
>> +       CS_UNLOCK(drvdata->base);
>> +
>> +       writel_relaxed(0x0, drvdata->base + STMHEMCR);
>> +       writel_relaxed(0x0, drvdata->base + STMHEER);
>> +       writel_relaxed(0x0, drvdata->base + STMHETER);
>> +
>> +       CS_LOCK(drvdata->base);
>> +}
>> +
>> +static void stm_port_disable_hw(struct stm_drvdata *drvdata)
>> +{
>> +       CS_UNLOCK(drvdata->base);
>> +
>> +       writel_relaxed(0x0, drvdata->base + STMSPER);
>> +       writel_relaxed(0x0, drvdata->base + STMSPTRIGCSR);
>> +
>> +       CS_LOCK(drvdata->base);
>> +}
>> +
>> +static void stm_disable_hw(struct stm_drvdata *drvdata)
>> +{
>> +       u32 val;
>> +
>> +       CS_UNLOCK(drvdata->base);
>> +
>> +       val = readl_relaxed(drvdata->base + STMTCSR);
>> +       val &= ~0x1; /* clear global STM enable [0] */
>> +       writel_relaxed(val, drvdata->base + STMTCSR);
>> +
>> +       CS_LOCK(drvdata->base);
>> +
>> +       stm_port_disable_hw(drvdata);
>> +       if (drvdata->stmheer)
>> +               stm_hwevent_disable_hw(drvdata);
>> +}
>> +
>> +static void stm_disable(struct coresight_device *csdev)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>> +
>> +       spin_lock(&drvdata->spinlock);
>> +       stm_disable_hw(drvdata);
>> +       drvdata->enable = false;
>> +       spin_unlock(&drvdata->spinlock);
>> +
>> +       /* Wait until the engine has completely stopped */
>> +       coresight_timeout(drvdata, STMTCSR, STMTCSR_BUSY_BIT, 0);
>> +
>> +       pm_runtime_put(drvdata->dev);
>> +
>> +       dev_info(drvdata->dev, "STM tracing disabled\n");
>> +}
>> +
>> +static int stm_trace_id(struct coresight_device *csdev)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>> +
>> +       return drvdata->traceid;
>> +}
>> +
>> +static const struct coresight_ops_source stm_source_ops = {
>> +       .trace_id       = stm_trace_id,
>> +       .enable         = stm_enable,
>> +       .disable        = stm_disable,
>> +};
>> +
>> +static const struct coresight_ops stm_cs_ops = {
>> +       .source_ops     = &stm_source_ops,
>> +};
>> +
>> +static inline bool stm_addr_unaligned(const void *addr, u8 max)
>> +{
>> +       return ((unsigned long)addr & (max - 1));
>> +}
>> +
>> +static int stm_send(void *addr, const void *data, u32 size, u8 max)
>> +{
>> +       u32 len = size;
>> +       u8 paload[8];
>> +
>> +       if (stm_addr_unaligned(data, max)) {
>> +               memcpy(paload, data, size);
>> +               data = paload;
>> +       }
>> +
>> +       /* now we are 64bit/32bit aligned */
>> +#ifdef CONFIG_64BIT
>> +       if (size == 8)
>> +               writeq_relaxed(*(u64 *)data, addr);
>> +#endif
>
> We probably don't need an #ifdef here.  Checking the size of the
> transfer against the fundamental data size will result in the same
> outcome, i.e preventing 64 bit transfers on a 32 bit architecture.  An
> error (understandable by the caller) should probably be returned in
> this case.

In theory this is correct, but if the code is unreachable for non-32-bit architectures, why include it at all?

>> +       if (size >= 4) {
>> +               writel_relaxed(*(u32 *)data, addr);
>> +               data += 4;
>> +               size -= 4;
>> +       }
>> +
>> +       if (size >= 2) {
>> +               writew_relaxed(*(u16 *)data, addr);
>> +               data += 2;
>> +               size -= 2;
>> +       }
>> +
>> +       if (size == 1)
>> +               writeb_relaxed(*(u8 *)data, addr);
>> +
>> +       return len;
>> +}

The API for stm_data::packet (include/linux/stm.h) is not wholly clearly defined, but it does state "sends an STP packet," which I interpret as meaning exactly one packet and no more. This function (which is called from this module's implementation of stm_data::packet) will send multiple STP packets if called with a value that is not exactly 8, 4, 2, or 1.

To send only one packet, either:

* These "if" statements are replaced with "else if" (as appropriate), and the function returns the size of data consumed; or
* The stm_generic_packet() function (below) forces "size" to a power-of-two (<= write_max) before calling stm_send().

>> +static int stm_generic_link(struct stm_data *stm_data,
>> +                           unsigned int master,  unsigned int channel)
>> +{
>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>> +                                                  struct stm_drvdata, stm);
>> +       if (!drvdata || !drvdata->csdev)
>> +               return -EINVAL;
>> +
>> +       return coresight_enable(drvdata->csdev);
>> +}
>> +
>> +static void stm_generic_unlink(struct stm_data *stm_data,
>> +                              unsigned int master,  unsigned int channel)
>> +{
>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>> +                                                  struct stm_drvdata, stm);
>> +       if (!drvdata || !drvdata->csdev)
>> +               return;
>> +
>> +       stm_disable(drvdata->csdev);
>> +}
>> +
>> +static long stm_generic_set_options(struct stm_data *stm_data,
>> +                                   unsigned int master,
>> +                                   unsigned int channel,
>> +                                   unsigned int nr_chans,
>> +                                   unsigned long options)
>> +{
>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>> +                                                  struct stm_drvdata, stm);
>> +       if (!(drvdata && drvdata->enable))
>> +               return -EINVAL;
>> +
>> +       if (channel >= drvdata->numsp)
>> +               return -EINVAL;
>> +
>> +       switch (options) {
>> +       case STM_OPTION_GUARANTEED:
>> +               set_bit(channel, drvdata->chs.guaranteed);
>> +               break;
>> +
>> +       case STM_OPTION_INVARIANT:
>> +               clear_bit(channel, drvdata->chs.guaranteed);
>> +               break;
>> +
>> +       default:
>> +               return -EINVAL;
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static long stm_generic_get_options(struct stm_data *stm_data,
>> +                                   unsigned int master,
>> +                                   unsigned int channel,
>> +                                   unsigned int nr_chans,
>> +                                   u64 *options)
>> +{
>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>> +                                                  struct stm_drvdata, stm);
>> +       if (!(drvdata && drvdata->enable))
>> +               return -EINVAL;
>> +
>> +       if (channel >= drvdata->numsp)
>> +               return -EINVAL;
>> +
>> +       switch (*options) {
>> +       case STM_OPTION_GUARANTEED:
>> +               *options = test_bit(channel, drvdata->chs.guaranteed);
>> +               break;
>> +
>> +       default:
>> +               return -EINVAL;
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static ssize_t stm_generic_packet(struct stm_data *stm_data,
>> +                                 unsigned int master,
>> +                                 unsigned int channel,
>> +                                 unsigned int packet,
>> +                                 unsigned int flags,
>> +                                 unsigned int size,
>> +                                 const unsigned char *payload)
>> +{
>> +       unsigned long ch_addr;
>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>> +                                                  struct stm_drvdata, stm);
>> +
>> +       if (!(drvdata && drvdata->enable))
>> +               return 0;
>> +
>> +       if (channel >= drvdata->numsp)
>> +               return 0;
>> +
>> +       ch_addr = (unsigned long)stm_channel_addr(drvdata, channel);
>> +
>> +       flags = (flags == STP_PACKET_TIMESTAMPED) ? STM_FLAG_TIMESTAMPED : 0;
>> +       flags |= test_bit(channel, drvdata->chs.guaranteed) ?
>> +                          STM_FLAG_GUARANTEED : 0;
>> +
>> +       if (size > drvdata->write_max)
>> +               size = drvdata->write_max;
>> +
>> +       switch (packet) {
>> +       case STP_PACKET_FLAG:
>> +               ch_addr |= stm_channel_off(STM_PKT_TYPE_FLAG, flags);
>> +
>> +               /* the generic STM API set a size of zero on flag packets. */
>> +               size = 1;
>> +               break;
>> +
>> +       case STP_PACKET_DATA:
>> +               ch_addr |= stm_channel_off(STM_PKT_TYPE_DATA, flags);
>> +               break;
>> +
>> +       default:
>> +               return 0;
>> +       }
>> +
>> +       return stm_send((void *)ch_addr, payload, size, drvdata->write_max);
>> +}
>> +
>> +static ssize_t hwevent_enable_show(struct device *dev,
>> +                                  struct device_attribute *attr, char *buf)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val = drvdata->stmheer;
>> +
>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>> +}
>> +
>> +static ssize_t hwevent_enable_store(struct device *dev,
>> +                                   struct device_attribute *attr,
>> +                                   const char *buf, size_t size)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val;
>> +       int ret = 0;
>> +
>> +       ret = kstrtoul(buf, 16, &val);
>> +       if (ret)
>> +               return -EINVAL;
>> +
>> +       drvdata->stmheer = val;
>> +       /* HW event enable and trigger go hand in hand */
>> +       drvdata->stmheter = val;
>> +
>> +       return size;
>> +}
>> +static DEVICE_ATTR_RW(hwevent_enable);
>> +
>> +static ssize_t hwevent_select_show(struct device *dev,
>> +                                  struct device_attribute *attr, char *buf)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val = drvdata->stmhebsr;
>> +
>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>> +}
>> +
>> +static ssize_t hwevent_select_store(struct device *dev,
>> +                                   struct device_attribute *attr,
>> +                                   const char *buf, size_t size)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val;
>> +       int ret = 0;
>> +
>> +       ret = kstrtoul(buf, 16, &val);
>> +       if (ret)
>> +               return -EINVAL;
>> +
>> +       drvdata->stmhebsr = val;
>> +
>> +       return size;
>> +}
>> +static DEVICE_ATTR_RW(hwevent_select);
>> +
>> +static ssize_t port_select_show(struct device *dev,
>> +                               struct device_attribute *attr, char *buf)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val;
>> +
>> +       if (!drvdata->enable) {
>> +               val = drvdata->stmspscr;
>> +       } else {
>> +               spin_lock(&drvdata->spinlock);
>> +               val = readl_relaxed(drvdata->base + STMSPSCR);
>> +               spin_unlock(&drvdata->spinlock);
>> +       }
>> +
>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>> +}
>> +
>> +static ssize_t port_select_store(struct device *dev,
>> +                                struct device_attribute *attr,
>> +                                const char *buf, size_t size)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val, stmsper;
>> +       int ret = 0;
>> +
>> +       ret = kstrtoul(buf, 16, &val);
>> +       if (ret)
>> +               return ret;
>> +
>> +       spin_lock(&drvdata->spinlock);
>> +       drvdata->stmspscr = val;
>> +
>> +       if (drvdata->enable) {
>> +               CS_UNLOCK(drvdata->base);
>> +               /* Process as per ARM's TRM recommendation */
>> +               stmsper = readl_relaxed(drvdata->base + STMSPER);
>> +               writel_relaxed(0x0, drvdata->base + STMSPER);
>> +               writel_relaxed(drvdata->stmspscr, drvdata->base + STMSPSCR);
>> +               writel_relaxed(stmsper, drvdata->base + STMSPER);
>> +               CS_LOCK(drvdata->base);
>> +       }
>> +       spin_unlock(&drvdata->spinlock);
>> +
>> +       return size;
>> +}
>> +static DEVICE_ATTR_RW(port_select);
>> +
>> +static ssize_t port_enable_show(struct device *dev,
>> +                               struct device_attribute *attr, char *buf)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val;
>> +
>> +       if (!drvdata->enable) {
>> +               val = drvdata->stmsper;
>> +       } else {
>> +               spin_lock(&drvdata->spinlock);
>> +               val = readl_relaxed(drvdata->base + STMSPER);
>> +               spin_unlock(&drvdata->spinlock);
>> +       }
>> +
>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>> +}
>> +
>> +static ssize_t port_enable_store(struct device *dev,
>> +                                struct device_attribute *attr,
>> +                                const char *buf, size_t size)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val;
>> +       int ret = 0;
>> +
>> +       ret = kstrtoul(buf, 16, &val);
>> +       if (ret)
>> +               return ret;
>> +
>> +       spin_lock(&drvdata->spinlock);
>> +       drvdata->stmsper = val;
>> +
>> +       if (drvdata->enable) {
>> +               CS_UNLOCK(drvdata->base);
>> +               writel_relaxed(drvdata->stmsper, drvdata->base + STMSPER);
>> +               CS_LOCK(drvdata->base);
>> +       }
>> +       spin_unlock(&drvdata->spinlock);
>> +
>> +       return size;
>> +}
>> +static DEVICE_ATTR_RW(port_enable);
>> +
>> +static ssize_t traceid_show(struct device *dev,
>> +                           struct device_attribute *attr, char *buf)
>> +{
>> +       unsigned long val;
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +
>> +       val = drvdata->traceid;
>> +       return sprintf(buf, "%#lx\n", val);
>> +}
>> +
>> +static ssize_t traceid_store(struct device *dev,
>> +                            struct device_attribute *attr,
>> +                            const char *buf, size_t size)
>> +{
>> +       int ret;
>> +       unsigned long val;
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +
>> +       ret = kstrtoul(buf, 16, &val);
>> +       if (ret)
>> +               return ret;
>> +
>> +       /* traceid field is 7bit wide on STM32 */
>> +       drvdata->traceid = val & 0x7f;
>> +       return size;
>> +}
>> +static DEVICE_ATTR_RW(traceid);
>> +
>> +#define coresight_simple_func(type, name, offset)                      \
>> +static ssize_t name##_show(struct device *_dev,                                \
>> +                          struct device_attribute *attr, char *buf)    \
>> +{                                                                      \
>> +       type *drvdata = dev_get_drvdata(_dev->parent);                  \
>> +       return scnprintf(buf, PAGE_SIZE, "0x%08x\n",                    \
>> +                        readl_relaxed(drvdata->base + offset));        \
>> +}                                                                      \
>> +DEVICE_ATTR_RO(name)
>> +
>> +#define coresight_stm_simple_func(name, offset)        \
>> +       coresight_simple_func(struct stm_drvdata, name, offset)
>> +
>> +coresight_stm_simple_func(tcsr, STMTCSR);
>> +coresight_stm_simple_func(tsfreqr, STMTSFREQR);
>> +coresight_stm_simple_func(syncr, STMSYNCR);
>> +coresight_stm_simple_func(sper, STMSPER);
>> +coresight_stm_simple_func(spter, STMSPTER);
>> +coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
>> +coresight_stm_simple_func(spscr, STMSPSCR);
>> +coresight_stm_simple_func(spmscr, STMSPMSCR);
>> +coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
>> +coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
>> +coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
>> +coresight_stm_simple_func(devid, CORESIGHT_DEVID);
>> +
>> +static struct attribute *coresight_stm_attrs[] = {
>> +       &dev_attr_hwevent_enable.attr,
>> +       &dev_attr_hwevent_select.attr,
>> +       &dev_attr_port_enable.attr,
>> +       &dev_attr_port_select.attr,
>> +       &dev_attr_traceid.attr,
>> +       NULL,
>> +};
>> +
>> +static struct attribute *coresight_stm_mgmt_attrs[] = {
>> +       &dev_attr_tcsr.attr,
>> +       &dev_attr_tsfreqr.attr,
>> +       &dev_attr_syncr.attr,
>> +       &dev_attr_sper.attr,
>> +       &dev_attr_spter.attr,
>> +       &dev_attr_privmaskr.attr,
>> +       &dev_attr_spscr.attr,
>> +       &dev_attr_spmscr.attr,
>> +       &dev_attr_spfeat1r.attr,
>> +       &dev_attr_spfeat2r.attr,
>> +       &dev_attr_spfeat3r.attr,
>> +       &dev_attr_devid.attr,
>> +       NULL,
>> +};
>> +
>> +static const struct attribute_group coresight_stm_group = {
>> +       .attrs = coresight_stm_attrs,
>> +};
>> +
>> +static const struct attribute_group coresight_stm_mgmt_group = {
>> +       .attrs = coresight_stm_mgmt_attrs,
>> +       .name = "mgmt",
>> +};
>> +
>> +static const struct attribute_group *coresight_stm_groups[] = {
>> +       &coresight_stm_group,
>> +       &coresight_stm_mgmt_group,
>> +       NULL,
>> +};
>> +
>> +static int stm_get_resource_byname(struct device_node *np,
>> +                                  char *ch_base, struct resource *res)
>> +{
>> +       const char *name = NULL;
>> +       int index = 0, found = 0;
>> +
>> +       while (!of_property_read_string_index(np, "reg-names", index, &name)) {
>> +               if (strcmp(ch_base, name)) {
>> +                       index++;
>> +                       continue;
>> +               }
>> +
>> +               /* We have a match and @index is where it's at */
>> +               found = 1;
>> +               break;
>> +       }
>> +
>> +       if (!found)
>> +               return -EINVAL;
>> +
>> +       return of_address_to_resource(np, index, res);
>> +}
>> +
>> +static u32 stm_fundamental_data_size(struct stm_drvdata *drvdata)
>> +{
>> +       u32 stmspfeat2r;
>> +
>> +       stmspfeat2r = readl_relaxed(drvdata->base + STMSPFEAT2R);
>> +       return BMVAL(stmspfeat2r, 12, 15);
>> +}
>> +
>> +static u32 stm_num_stimulus_port(struct stm_drvdata *drvdata)
>> +{
>> +       u32 numsp;
>> +
>> +       numsp = readl_relaxed(drvdata->base + CORESIGHT_DEVID);
>> +       /*
>> +        * NUMPS in STMDEVID is 17 bit long and if equal to 0x0,
>> +        * 32 stimulus ports are supported.
>> +        */
>> +       numsp &= 0x1ffff;
>> +       if (!numsp)
>> +               numsp = STM_32_CHANNEL;
>> +       return numsp;
>> +}
>> +
>> +static void stm_init_default_data(struct stm_drvdata *drvdata)
>> +{
>> +       /* Don't use port selection */
>> +       drvdata->stmspscr = 0x0;
>> +       /*
>> +        * Enable all channel regardless of their number.  When port
>> +        * selection isn't used (see above) STMSPER applies to all
>> +        * 32 channel group available, hence setting all 32 bits to 1
>> +        */
>> +       drvdata->stmsper = ~0x0;
>> +
>> +       /*
>> +        * Select arbitrary value to start with.  If there is a conflict
>> +        * with other tracers the framework will deal with it.
>> +        */
>> +       drvdata->traceid = 0x20;
>> +
>> +       /* Set invariant transaction timing on all channels */
>> +       bitmap_clear(drvdata->chs.guaranteed, 0, drvdata->numsp);
>> +}
>> +
>> +static void stm_init_generic_data(struct stm_drvdata *drvdata)
>> +{
>> +       drvdata->stm.name = dev_name(drvdata->dev);
>> +       drvdata->stm.mstatic = true;
>> +       drvdata->stm.sw_nchannels = drvdata->numsp;
>> +       drvdata->stm.packet = stm_generic_packet;
>> +       drvdata->stm.link = stm_generic_link;
>> +       drvdata->stm.unlink = stm_generic_unlink;
>> +       drvdata->stm.set_options = stm_generic_set_options;
>> +       drvdata->stm.get_options = stm_generic_get_options;
>> +}
>> +
>> +static int stm_probe(struct amba_device *adev, const struct amba_id *id)
>> +{
>> +       int ret;
>> +       void __iomem *base;
>> +       unsigned long *guaranteed;
>> +       struct device *dev = &adev->dev;
>> +       struct coresight_platform_data *pdata = NULL;
>> +       struct stm_drvdata *drvdata;
>> +       struct resource *res = &adev->res;
>> +       struct resource ch_res;
>> +       size_t res_size, bitmap_size;
>> +       struct coresight_desc *desc;
>> +       struct device_node *np = adev->dev.of_node;
>> +
>> +       if (np) {
>> +               pdata = of_get_coresight_platform_data(dev, np);
>> +               if (IS_ERR(pdata))
>> +                       return PTR_ERR(pdata);
>> +               adev->dev.platform_data = pdata;
>> +       }
>> +       drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
>> +       if (!drvdata)
>> +               return -ENOMEM;
>> +
>> +       drvdata->dev = &adev->dev;
>> +       drvdata->atclk = devm_clk_get(&adev->dev, "atclk"); /* optional */
>> +       if (!IS_ERR(drvdata->atclk)) {
>> +               ret = clk_prepare_enable(drvdata->atclk);
>> +               if (ret)
>> +                       return ret;
>> +       }
>> +       dev_set_drvdata(dev, drvdata);
>> +
>> +       base = devm_ioremap_resource(dev, res);
>> +       if (IS_ERR(base))
>> +               return PTR_ERR(base);
>> +       drvdata->base = base;
>> +
>> +       ret = stm_get_resource_byname(np, "stm-stimulus-base", &ch_res);
>> +       if (ret)
>> +               return ret;
>> +
>> +       base = devm_ioremap_resource(dev, &ch_res);
>> +       if (IS_ERR(base))
>> +               return PTR_ERR(base);
>> +       drvdata->chs.base = base;
>> +
>> +       drvdata->write_max = sizeof(u32);
>
> Isn't the fundamental data size the maximum an architecture can stand?
>  Why not simply use that rather than adding another variable?
>
>> +       drvdata->write_64bit = stm_fundamental_data_size(drvdata);
>> +
>> +#ifndef CONFIG_64BIT
>> +       if (drvdata->write_64bit)
>> +               drvdata->write_max = sizeof(u64);
>> +#endif

It is a bit odd that this code is using sizeof(u64) / sizeof(u32) here, when it is using 8 / 4 explicitly in the functions above.

>
> In most cases the fundamental data size will follow the architecture
> size, i.e, 32 bit architecture with 32 bit fundamental data size, 64
> bit architecture with 64 bit fundamental data size.  A fundamental
> data size of 32 is also possible on a 64 bit architecture.
>
> What needs to be prevented is a 32 bit architecture with a fundamental
> data size of 64.  In those cases the fundamental data size should be
> adjusted to be 32 bit.  To do that I suggest to modify
> stm_fundamental_data_size() to probe the STM's fundamental data size
> but to adjust it down if on a 32 bit system.  Knowing whether running
> on a 32/64 bit system is easy when using the IS_ENABLED() macro.

Agreed. For ARM, 64-bit writes to the STM are supported only if BOTH the STM supports 64-bit data and the processor is in 64-bit execution state. Otherwise, the largest size is 32 bits. You are likely to see both 64-bit STM from 32-bit execution state, and 32-bit STM on a SoC with a 64-bit ARM processor.

>> +
>> +       if (boot_nr_channel) {
>> +               drvdata->numsp = boot_nr_channel;
>> +               res_size = min((resource_size_t)(boot_nr_channel *
>> +                                 BYTES_PER_CHANNEL), resource_size(res));
>> +       } else {
>> +               drvdata->numsp = stm_num_stimulus_port(drvdata);
>> +               res_size = min((resource_size_t)(drvdata->numsp *
>> +                                BYTES_PER_CHANNEL), resource_size(res));
>> +       }
>> +       bitmap_size = BITS_TO_LONGS(drvdata->numsp) * sizeof(long);
>> +
>> +       guaranteed = devm_kzalloc(dev, bitmap_size, GFP_KERNEL);
>> +       if (!guaranteed)
>> +               return -ENOMEM;
>> +       drvdata->chs.guaranteed = guaranteed;
>> +
>> +       spin_lock_init(&drvdata->spinlock);
>> +
>> +       stm_init_default_data(drvdata);
>> +       stm_init_generic_data(drvdata);
>> +
>> +       if (stm_register_device(dev, &drvdata->stm, THIS_MODULE)) {
>> +               dev_info(dev,
>> +                        "stm_register_device failed, probing deffered\n");
>> +               return -EPROBE_DEFER;
>> +       }
>> +
>> +       desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
>> +       if (!desc) {
>> +               ret = -ENOMEM;
>> +               goto stm_unregister;
>> +       }
>> +
>> +       desc->type = CORESIGHT_DEV_TYPE_SOURCE;
>> +       desc->subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE;
>> +       desc->ops = &stm_cs_ops;
>> +       desc->pdata = pdata;
>> +       desc->dev = dev;
>> +       desc->groups = coresight_stm_groups;
>> +       drvdata->csdev = coresight_register(desc);
>> +       if (IS_ERR(drvdata->csdev)) {
>> +               ret = PTR_ERR(drvdata->csdev);
>> +               goto stm_unregister;
>> +       }
>> +
>> +       pm_runtime_put(&adev->dev);
>> +
>> +       dev_info(dev, "%s initialized\n", (char *)id->data);
>> +       return 0;
>> +
>> +stm_unregister:
>> +       stm_unregister_device(&drvdata->stm);
>> +       return ret;
>> +}
>> +
>> +static int stm_remove(struct amba_device *adev)
>> +{
>> +       struct stm_drvdata *drvdata = amba_get_drvdata(adev);
>> +
>> +       stm_unregister_device(&drvdata->stm);
>> +       coresight_unregister(drvdata->csdev);
>> +       return 0;
>> +}
>
> The xyz_remove() functions is not needed for coresight devices -
> unbinding a device from its driver will no longer be possible in the
> 4.6 cycle.
>
>> +
>> +#ifdef CONFIG_PM
>> +static int stm_runtime_suspend(struct device *dev)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev);
>> +
>> +       if (drvdata && !IS_ERR(drvdata->atclk))
>> +               clk_disable_unprepare(drvdata->atclk);
>> +
>> +       return 0;
>> +}
>> +
>> +static int stm_runtime_resume(struct device *dev)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev);
>> +
>> +       if (drvdata && !IS_ERR(drvdata->atclk))
>> +               clk_prepare_enable(drvdata->atclk);
>> +
>> +       return 0;
>> +}
>> +#endif
>> +
>> +static const struct dev_pm_ops stm_dev_pm_ops = {
>> +       SET_RUNTIME_PM_OPS(stm_runtime_suspend, stm_runtime_resume, NULL)
>> +};
>> +
>> +static struct amba_id stm_ids[] = {
>> +       {
>> +               .id     = 0x0003b962,
>> +               .mask   = 0x0003ffff,
>> +               .data   = "STM32",
>> +       },
>> +       { 0, 0},
>> +};
>> +
>> +static struct amba_driver stm_driver = {
>> +       .drv = {
>> +               .name   = "coresight-stm",
>> +               .owner  = THIS_MODULE,
>> +               .pm     = &stm_dev_pm_ops,
>> +       },
>> +       .probe          = stm_probe,
>> +       .remove         = stm_remove,
>> +       .id_table       = stm_ids,
>> +};
>> +
>> +module_amba_driver(stm_driver);
>> +
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("CoreSight System Trace Macrocell driver");
>> diff --git a/include/linux/coresight-stm.h b/include/linux/coresight-stm.h
>> new file mode 100644
>> index 0000000..a978bb8
>> --- /dev/null
>> +++ b/include/linux/coresight-stm.h
>> @@ -0,0 +1,6 @@
>> +#ifndef __LINUX_CORESIGHT_STM_H_
>> +#define __LINUX_CORESIGHT_STM_H_
>> +
>> +#include <uapi/linux/coresight-stm.h>
>> +
>> +#endif
>> diff --git a/include/uapi/linux/coresight-stm.h b/include/uapi/linux/coresight-stm.h
>> new file mode 100644
>> index 0000000..fa35f0b
>> --- /dev/null
>> +++ b/include/uapi/linux/coresight-stm.h
>> @@ -0,0 +1,12 @@
>> +#ifndef __UAPI_CORESIGHT_STM_H_
>> +#define __UAPI_CORESIGHT_STM_H_
>> +
>> +#define STM_FLAG_TIMESTAMPED   BIT(3)
>> +#define STM_FLAG_GUARANTEED    BIT(7)
>> +
>> +enum {
>> +       STM_OPTION_GUARANTEED = 0,
>> +       STM_OPTION_INVARIANT,
>> +};
>> +
>> +#endif
>> --
>> 1.9.1
>>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

From catalin.marinas at arm.com  Fri Feb 12 06:58:44 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 12 Feb 2016 14:58:44 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160212145844.GI31665@e104818-lin.cambridge.arm.com>

Hi Ard,

On Mon, Feb 01, 2016 at 11:54:52AM +0100, Ard Biesheuvel wrote:
> This moves the module area to right before the vmalloc area, and
> moves the kernel image to the base of the vmalloc area. This is
> an intermediate step towards implementing KASLR, which allows the
> kernel image to be located anywhere in the vmalloc area.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

This patch is causing lots of KASAN warnings on Juno (interestingly, it
doesn't seem to trigger on Seattle, though we only tried for-next/core).
I pushed the branch that I'm currently using here:

git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux for-next/kernmap


A typical error (though its place varies based on the config options,
kernel layout):

BUG: KASAN: stack-out-of-bounds in clockevents_program_event+0x28/0x1b0 at addr ffffffc936257cc8
Read of size 8 by task swapper/2/0
page:ffffffbde6d895c0 count:0 mapcount:0 mapping:          (null) index:0x0
flags: 0x4000000000000000()
page dumped because: kasan: bad access detected
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.5.0-rc1+ #130
Hardware name: Juno (DT)
Call trace:
[<ffffff900408b590>] dump_backtrace+0x0/0x258
[<ffffff900408b7fc>] show_stack+0x14/0x20
[<ffffff900448789c>] dump_stack+0xac/0x100
[<ffffff9004224f3c>] kasan_report_error+0x544/0x570
[<ffffff9004225328>] kasan_report+0x40/0x48
[<ffffff9004223c58>] __asan_load8+0x60/0x78
[<ffffff90041596f0>] clockevents_program_event+0x28/0x1b0
[<ffffff900415c63c>] tick_program_event+0x74/0xb8
[<ffffff9004148944>] __remove_hrtimer+0xcc/0x100
[<ffffff9004148f0c>] hrtimer_start_range_ns+0x3f4/0x538
[<ffffff900415d450>] __tick_nohz_idle_enter+0x558/0x590
[<ffffff900415d74c>] tick_nohz_idle_enter+0x44/0x78
[<ffffff900411fcc8>] cpu_startup_entry+0x48/0x2c0
[<ffffff9004091f58>] secondary_start_kernel+0x208/0x278
[<0000000080082aac>] 0x80082aac
Memory state around the buggy address:
 ffffffc936257b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffffc936257c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
>ffffffc936257c80: f1 f1 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00
                                              ^
 ffffffc936257d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffffc936257d80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1


And some additional info from the kernel boot:

Processing EFI memory map:
  0x000008000000-0x00000bffffff [Memory Mapped I/O  |RUN|  |  |  |  |  |   |  |  |  |UC]
  0x00001c170000-0x00001c170fff [Memory Mapped I/O  |RUN|  |  |  |  |  |   |  |  |  |UC]
  0x000080000000-0x00008000ffff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x000080010000-0x00008007ffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x000080080000-0x00008149ffff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x0000814a0000-0x00009fdfffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x00009fe00000-0x00009fe0ffff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x00009fe10000-0x0000dfffffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x0000e00f0000-0x0000febd5fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x0000febd6000-0x0000febd9fff [ACPI Reclaim Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]*
  0x0000febda000-0x0000febdafff [ACPI Memory NVS    |   |  |  |  |  |  |   |WB|WT|WC|UC]*
  0x0000febdb000-0x0000febdcfff [ACPI Reclaim Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]*
  0x0000febdd000-0x0000feffffff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x000880000000-0x0009f8794fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x0009f8795000-0x0009f8796fff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x0009f8797000-0x0009f9bb4fff [Loader Code        |   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x0009f9bb5000-0x0009faf6efff [Boot Code          |   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x0009faf6f000-0x0009fafa9fff [Runtime Data       |RUN|  |  |  |  |  |   |WB|WT|WC|UC]*
  0x0009fafaa000-0x0009ff2b1fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x0009ff2b2000-0x0009ffb70fff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x0009ffb71000-0x0009ffb89fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x0009ffb8a000-0x0009ffb8dfff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x0009ffb8e000-0x0009ffb8efff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x0009ffb8f000-0x0009ffdddfff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x0009ffdde000-0x0009ffe76fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x0009ffe77000-0x0009fff6dfff [Boot Code          |   |  |  |  |  |  |   |WB|WT|WC|UC]
  0x0009fff6e000-0x0009fffaefff [Runtime Code       |RUN|  |  |  |  |  |   |WB|WT|WC|UC]*
  0x0009fffaf000-0x0009ffffefff [Runtime Data       |RUN|  |  |  |  |  |   |WB|WT|WC|UC]*
  0x0009fffff000-0x0009ffffffff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]


Memory: 7068520K/8371264K available (10424K kernel code, 3464K rwdata, 5284K rodata, 1016K init, 380K bss, 1286360K reserved, 16384K cma-reserved)
Virtual kernel memory layout:
    kasan   : 0xffffff8000000000 - 0xffffff9000000000   (    64 GB)
    modules : 0xffffff9000000000 - 0xffffff9004000000   (    64 MB)
    vmalloc : 0xffffff9004000000 - 0xffffffbdbfff0000   (   182 GB)
      .init : 0xffffff9004fd9000 - 0xffffff90050d7000   (  1016 KB)
      .text : 0xffffff9004080000 - 0xffffff9004fd9000   ( 15716 KB)
      .data : 0xffffff90050d7000 - 0xffffff9005439200   (  3465 KB)
    vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000   (     8 GB maximum)
              0xffffffbdc2000000 - 0xffffffbde8000000   (   608 MB actual)
    fixed   : 0xffffffbffe7fd000 - 0xffffffbffec00000   (  4108 KB)
    PCI I/O : 0xffffffbffee00000 - 0xffffffbfffe00000   (    16 MB)
    memory  : 0xffffffc000000000 - 0xffffffc980000000   ( 38912 MB)

-- 
Catalin


From alexandre.torgue at gmail.com  Fri Feb 12 07:01:10 2016
From: alexandre.torgue at gmail.com (Alexandre Torgue)
Date: Fri, 12 Feb 2016 16:01:10 +0100
Subject: [PATCH 0/4] Add Ethernet support on STM32F429
In-Reply-To: <20160209.045214.805916119264070573.davem@davemloft.net>
References: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
 <20160209.045214.805916119264070573.davem@davemloft.net>
Message-ID: <CAJgp7zxMoHD+zqHgsOvB=+wx=TtqqL0HH_3o=J=712QsvJvZwQ@mail.gmail.com>

Hi David,

I will fix it in next patch version.
I just find a corruption issue in stmmac driver, I will also fix it in
next version.

Best regards

Alex

2016-02-09 10:52 GMT+01:00 David Miller <davem at davemloft.net>:
> From: Alexandre TORGUE <alexandre.torgue at gmail.com>
> Date: Wed,  3 Feb 2016 15:54:31 +0100
>
>> STM32F429 Chip embeds a Synopsys 3.50a MAC IP.
>> This series:
>>       -enhance current stmmac driver to control it (code already available) and
>>        adds basic glue for STM32F429 chip.
>>       -Enable basic Net config in kernel.
>>
>> Note that DT patches are not present because STM32 pinctrl code is not
>> yet avalaible.
>
> Looks like this needs to be respun to deal with the warnings the kbuild
> robot reported.
>
> Thanks.


From ard.biesheuvel at linaro.org  Fri Feb 12 07:02:58 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 16:02:58 +0100
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>

On 12 February 2016 at 15:58, Catalin Marinas <catalin.marinas at arm.com> wrote:
> Hi Ard,
>
> On Mon, Feb 01, 2016 at 11:54:52AM +0100, Ard Biesheuvel wrote:
>> This moves the module area to right before the vmalloc area, and
>> moves the kernel image to the base of the vmalloc area. This is
>> an intermediate step towards implementing KASLR, which allows the
>> kernel image to be located anywhere in the vmalloc area.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>
> This patch is causing lots of KASAN warnings on Juno (interestingly, it
> doesn't seem to trigger on Seattle, though we only tried for-next/core).
> I pushed the branch that I'm currently using here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux for-next/kernmap
>
>
> A typical error (though its place varies based on the config options,
> kernel layout):
>
> BUG: KASAN: stack-out-of-bounds in clockevents_program_event+0x28/0x1b0 at addr ffffffc936257cc8

Can you confirm that these are stack accesses? I was having similar
errors before, and I ended up creating the kasan zero page patch
because it turned out the kasan shadow page in question was aliased
and the stack writes were occurring elsewhere.


> Read of size 8 by task swapper/2/0
> page:ffffffbde6d895c0 count:0 mapcount:0 mapping:          (null) index:0x0
> flags: 0x4000000000000000()
> page dumped because: kasan: bad access detected
> CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.5.0-rc1+ #130
> Hardware name: Juno (DT)
> Call trace:
> [<ffffff900408b590>] dump_backtrace+0x0/0x258
> [<ffffff900408b7fc>] show_stack+0x14/0x20
> [<ffffff900448789c>] dump_stack+0xac/0x100
> [<ffffff9004224f3c>] kasan_report_error+0x544/0x570
> [<ffffff9004225328>] kasan_report+0x40/0x48
> [<ffffff9004223c58>] __asan_load8+0x60/0x78
> [<ffffff90041596f0>] clockevents_program_event+0x28/0x1b0
> [<ffffff900415c63c>] tick_program_event+0x74/0xb8
> [<ffffff9004148944>] __remove_hrtimer+0xcc/0x100
> [<ffffff9004148f0c>] hrtimer_start_range_ns+0x3f4/0x538
> [<ffffff900415d450>] __tick_nohz_idle_enter+0x558/0x590
> [<ffffff900415d74c>] tick_nohz_idle_enter+0x44/0x78
> [<ffffff900411fcc8>] cpu_startup_entry+0x48/0x2c0
> [<ffffff9004091f58>] secondary_start_kernel+0x208/0x278
> [<0000000080082aac>] 0x80082aac
> Memory state around the buggy address:
>  ffffffc936257b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  ffffffc936257c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
>>ffffffc936257c80: f1 f1 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00
>                                               ^
>  ffffffc936257d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  ffffffc936257d80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
>
>
> And some additional info from the kernel boot:
>
> Processing EFI memory map:
>   0x000008000000-0x00000bffffff [Memory Mapped I/O  |RUN|  |  |  |  |  |   |  |  |  |UC]
>   0x00001c170000-0x00001c170fff [Memory Mapped I/O  |RUN|  |  |  |  |  |   |  |  |  |UC]
>   0x000080000000-0x00008000ffff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x000080010000-0x00008007ffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x000080080000-0x00008149ffff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x0000814a0000-0x00009fdfffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x00009fe00000-0x00009fe0ffff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x00009fe10000-0x0000dfffffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x0000e00f0000-0x0000febd5fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x0000febd6000-0x0000febd9fff [ACPI Reclaim Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]*
>   0x0000febda000-0x0000febdafff [ACPI Memory NVS    |   |  |  |  |  |  |   |WB|WT|WC|UC]*
>   0x0000febdb000-0x0000febdcfff [ACPI Reclaim Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]*
>   0x0000febdd000-0x0000feffffff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x000880000000-0x0009f8794fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x0009f8795000-0x0009f8796fff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x0009f8797000-0x0009f9bb4fff [Loader Code        |   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x0009f9bb5000-0x0009faf6efff [Boot Code          |   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x0009faf6f000-0x0009fafa9fff [Runtime Data       |RUN|  |  |  |  |  |   |WB|WT|WC|UC]*
>   0x0009fafaa000-0x0009ff2b1fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x0009ff2b2000-0x0009ffb70fff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x0009ffb71000-0x0009ffb89fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x0009ffb8a000-0x0009ffb8dfff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x0009ffb8e000-0x0009ffb8efff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x0009ffb8f000-0x0009ffdddfff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x0009ffdde000-0x0009ffe76fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x0009ffe77000-0x0009fff6dfff [Boot Code          |   |  |  |  |  |  |   |WB|WT|WC|UC]
>   0x0009fff6e000-0x0009fffaefff [Runtime Code       |RUN|  |  |  |  |  |   |WB|WT|WC|UC]*
>   0x0009fffaf000-0x0009ffffefff [Runtime Data       |RUN|  |  |  |  |  |   |WB|WT|WC|UC]*
>   0x0009fffff000-0x0009ffffffff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
>
>
> Memory: 7068520K/8371264K available (10424K kernel code, 3464K rwdata, 5284K rodata, 1016K init, 380K bss, 1286360K reserved, 16384K cma-reserved)
> Virtual kernel memory layout:
>     kasan   : 0xffffff8000000000 - 0xffffff9000000000   (    64 GB)
>     modules : 0xffffff9000000000 - 0xffffff9004000000   (    64 MB)
>     vmalloc : 0xffffff9004000000 - 0xffffffbdbfff0000   (   182 GB)
>       .init : 0xffffff9004fd9000 - 0xffffff90050d7000   (  1016 KB)
>       .text : 0xffffff9004080000 - 0xffffff9004fd9000   ( 15716 KB)
>       .data : 0xffffff90050d7000 - 0xffffff9005439200   (  3465 KB)
>     vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000   (     8 GB maximum)
>               0xffffffbdc2000000 - 0xffffffbde8000000   (   608 MB actual)
>     fixed   : 0xffffffbffe7fd000 - 0xffffffbffec00000   (  4108 KB)
>     PCI I/O : 0xffffffbffee00000 - 0xffffffbfffe00000   (    16 MB)
>     memory  : 0xffffffc000000000 - 0xffffffc980000000   ( 38912 MB)
>
> --
> Catalin


From robh at kernel.org  Fri Feb 12 07:04:30 2016
From: robh at kernel.org (Rob Herring)
Date: Fri, 12 Feb 2016 09:04:30 -0600
Subject: [PATCH 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <979fb4dc5fba643a6780759d2a13530a@mail.gmail.com>
References: <1455008277-8312-1-git-send-email-raveendra.padasalagi@broadcom.com>
 <1455008277-8312-2-git-send-email-raveendra.padasalagi@broadcom.com>
 <2631849.GeOulu78vx@wuerfel>
 <3b53af6b6c6735d10cb88518c8b8a0ae@mail.gmail.com>
 <20160209174351.GC40460@dtor-ws>
 <979fb4dc5fba643a6780759d2a13530a@mail.gmail.com>
Message-ID: <20160212150430.GA15049@rob-hp-laptop>

Your mailer is not handling wrapping correctly. Generally, Outlook does 
not work for maillists.

On Wed, Feb 10, 2016 at 10:24:43AM +0530, Raveendra Padasalagi wrote:
> > -----Original Message-----
> > From: Dmitry Torokhov [mailto:dmitry.torokhov at gmail.com]
> > Sent: 09 February 2016 23:14
> > To: Raveendra Padasalagi
> > Cc: Arnd Bergmann; Russell King; devicetree at vger.kernel.org; linux-arm-
> > kernel at lists.infradead.org; linux-input at vger.kernel.org; Rob Herring;
> Pawel
> > Moll; Mark Rutland; Ian Campbell; Kumar Gala; Jonathan Richardson; Jon
> > Mason; Florian Fainelli; Ray Jui; Scott Branden;
> linux-kernel at vger.kernel.org;
> > bcm-kernel-feedback-list at broadcom.com
> > Subject: Re: [PATCH 1/3] input: cygnus-update touchscreen dt node
> document

And Outlook's reply header is non-standard.

[...]

> > > In Cygnus SOC, Touch screen controller registers are shared with ADC
> > > and flex timer IP's.
> > > Using readl/writel could lead to race condition. So this patch is
> > > introduced to take care mutually exclusive access of register's in
> > > such a case.
> > >
> > > In the platform's where touchscreen register's are not shared normal
> > > readl/writel could be used.
> >
> > Are there currently platforms where the registers are not shared? If we
> have to
> > use regmap to correctly update registers (and thus we need
> > syscon) then I wonder if we should even attempt to support direct
> register
> > access by the driver.
> 
> Currently there are no platforms without register sharing, but we would
> like to keep
> the driver generic enough to take care of future SOC's if comes with
> dedicated registers
> and same touchscreen IP being re-used.

These future SoCs will have a different compatible string and you should 
use that to determine whether reg or syscon is used.

Rob


From catalin.marinas at arm.com  Fri Feb 12 07:10:06 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 12 Feb 2016 15:10:06 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
Message-ID: <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>

On Fri, Feb 12, 2016 at 04:02:58PM +0100, Ard Biesheuvel wrote:
> On 12 February 2016 at 15:58, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > Hi Ard,
> >
> > On Mon, Feb 01, 2016 at 11:54:52AM +0100, Ard Biesheuvel wrote:
> >> This moves the module area to right before the vmalloc area, and
> >> moves the kernel image to the base of the vmalloc area. This is
> >> an intermediate step towards implementing KASLR, which allows the
> >> kernel image to be located anywhere in the vmalloc area.
> >>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >
> > This patch is causing lots of KASAN warnings on Juno (interestingly, it
> > doesn't seem to trigger on Seattle, though we only tried for-next/core).
> > I pushed the branch that I'm currently using here:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux for-next/kernmap
> >
> >
> > A typical error (though its place varies based on the config options,
> > kernel layout):
> >
> > BUG: KASAN: stack-out-of-bounds in clockevents_program_event+0x28/0x1b0 at addr ffffffc936257cc8
> 
> Can you confirm that these are stack accesses? I was having similar
> errors before, and I ended up creating the kasan zero page patch
> because it turned out the kasan shadow page in question was aliased
> and the stack writes were occurring elsewhere.

It's possible, we are looking into this. Is there any other patch I miss on
the above branch?

BTW, disabling CPU_IDLE, I get other errors:

WARNING: at /work/Linux/linux-2.6-aarch64/mm/vmalloc.c:135
Modules linked in:

CPU: 2 PID: 973 Comm: systemd-modules Tainted: G        W       4.5.0-rc1+ #131
Hardware name: Juno (DT)
task: ffffffc93448e200 ti: ffffffc9346ac000 task.ti: ffffffc9346ac000
PC is at vmap_page_range_noflush+0x240/0x2e8
LR is at vmap_page_range_noflush+0x16c/0x2e8
pc : [<ffffff90041fef78>] lr : [<ffffff90041feea4>] pstate: 20000145
sp : ffffffc9346af9b0
x29: ffffffc9346af9b0 x28: ffffff90050da000
x27: ffffffc001438008 x26: ffffffbde6d16440
x25: 0000004240000000 x24: ffffffc97ff3a000
x23: 0000000000000041 x22: ffffffc078e9e600
x21: ffffff8200002000 x20: ffffff8200001000
x19: 0000000000000000 x18: 00000000f3294c2f
x17: 00000000f7dc90fb x16: 0000000087b402ce
x15: ffffffffffffffff x14: ffffff0000000000
x13: ffffffffffffffff x12: 0000000000000028
x11: 0101010101010101 x10: 00000001801a001a
x9 : 0000000000000000 x8 : ffffff89268b2400
x7 : 0000000000000000 x6 : 000000000000003f
x5 : 0000000000000040 x4 : 0000000000000000
x3 : 0000000000000000 x2 : 1ffffff800287001
x1 : dfffff9000000000 x0 : 00e8000081439713

---[ end trace 8a78d7ad8d08d2a9 ]---
Call trace:
Exception stack(0xffffffc9346af790 to 0xffffffc9346af8b0)
f780:                                   0000000000000000 ffffff8200001000
f7a0: ffffffc9346af9b0 ffffff90041fef78 0000000020000145 000000000000003d
f7c0: 0000004240000000 ffffffc078e9f600 0000000041b58ab3 ffffff9004f0c370
f7e0: ffffff9004082608 ffffffc078e9f620 00000000024080c2 0000000000400000
f800: ffffffc9346afe70 ffffffc9346afe50 ffffffc9346af9b0 ffffffc93448e200
f820: ffffffc9346af830 ffffff900408b1b0 ffffffc9346af900 ffffff900408b228
f840: ffffffc9346ac000 ffffffc9346af9b0 ffffffc9346ac000 ffffffc078e9e600
f860: 0000000041b58ab3 ffffff9004f0c8a8 ffffff900408b080 000000010010000e
f880: ffffffc9346af9b0 0000000000000000 00e8000081439713 dfffff9000000000
f8a0: 1ffffff800287001 0000000000000000
[<ffffff90041fef78>] vmap_page_range_noflush+0x240/0x2e8
[<ffffff90041ff078>] map_vm_area+0x58/0x88
[<ffffff9004200400>] __vmalloc_node_range+0x2b8/0x350
[<ffffff9004224394>] kasan_module_alloc+0x64/0xb8
[<ffffff90040943f4>] module_alloc+0x5c/0xa0
[<ffffff9004169460>] load_module+0x1798/0x3098
[<ffffff900416b020>] SyS_finit_module+0xf8/0x108
[<ffffff9004085d30>] el0_svc_naked+0x24/0x28
vmalloc: allocation failure, allocated 4096 of 4096 bytes

-- 
Catalin


From andre.przywara at arm.com  Fri Feb 12 07:11:52 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Fri, 12 Feb 2016 15:11:52 +0000
Subject: [PATCH 2/3] clk: sunxi: improve divider_clk error handling and
 reporting
In-Reply-To: <1455289913-29514-1-git-send-email-andre.przywara@arm.com>
References: <1455289913-29514-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455289913-29514-3-git-send-email-andre.przywara@arm.com>

We now report a failing ioremap, failing output names parsing,
failures in table registration and in the final step.
Also there was a bug where clk_register_divider_table() would return
an ERR_PTR value instead of NULL, which we were checking for.
We now implement proper rollback in case of an error.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 33 ++++++++++++++++++++++++++++++---
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 361f396..1ac6c9e0 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -819,17 +819,44 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
 	void __iomem *reg;
 
 	reg = of_iomap(node, 0);
+	if (!reg) {
+		pr_err("Could not map registers for mux-clk: %s\n", node->name);
+		return;
+	}
 
 	clk_parent = of_clk_get_parent_name(node, 0);
 
-	of_property_read_string(node, "clock-output-names", &clk_name);
+	if (of_property_read_string(node, "clock-output-names", &clk_name)) {
+		pr_err("%s: could not read clock-output-names for \"%s\"\n",
+		       __func__, clk_name);
+		goto out_unmap;
+	}
 
 	clk = clk_register_divider_table(NULL, clk_name, clk_parent, 0,
 					 reg, data->shift, data->width,
 					 data->pow ? CLK_DIVIDER_POWER_OF_TWO : 0,
 					 data->table, &clk_lock);
-	if (clk)
-		of_clk_add_provider(node, of_clk_src_simple_get, clk);
+	if (IS_ERR(clk)) {
+		pr_err("%s: failed to register divider clock %s: %ld\n",
+		       __func__, clk_name, PTR_ERR(clk));
+		goto out_unmap;
+	}
+
+	if (of_clk_add_provider(node, of_clk_src_simple_get, clk)) {
+		pr_err("%s: failed to add clock provider for %s\n",
+		       __func__, clk_name);
+		goto out_unregister;
+	}
+
+	if (!clk_register_clkdev(clk, clk_name, NULL))
+		return;
+
+	of_clk_del_provider(node);
+out_unregister:
+	clk_unregister_divider(clk);
+
+out_unmap:
+	iounmap(reg);
 }
 
 static void __init sun4i_ahb_clk_setup(struct device_node *node)
-- 
2.6.4



From andre.przywara at arm.com  Fri Feb 12 07:11:51 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Fri, 12 Feb 2016 15:11:51 +0000
Subject: [PATCH 1/3] clk: sunxi: improve mux_clk error handling and reporting
In-Reply-To: <1455289913-29514-1-git-send-email-andre.przywara@arm.com>
References: <1455289913-29514-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455289913-29514-2-git-send-email-andre.przywara@arm.com>

We now catch and report a failing ioremap, also a failure in the final
step of the clock registration is now handled and reported.
Also warnings are turned into errors.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 49ce283..361f396 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -690,11 +690,15 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
 	int i;
 
 	reg = of_iomap(node, 0);
+	if (!reg) {
+		pr_err("Could not map registers for mux-clk: %s\n", node->name);
+		return NULL;
+	}
 
 	i = of_clk_parent_fill(node, parents, SUNXI_MAX_PARENTS);
 	if (of_property_read_string(node, "clock-output-names", &clk_name)) {
-		pr_warn("%s: could not read clock-output-names for \"%s\"\n",
-			__func__, clk_name);
+		pr_err("%s: could not read clock-output-names for \"%s\"\n",
+		       __func__, clk_name);
 		goto out_unmap;
 	}
 
@@ -704,14 +708,17 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
 			       0, &clk_lock);
 
 	if (IS_ERR(clk)) {
-		pr_warn("%s: failed to register mux clock %s: %ld\n", __func__,
-			clk_name, PTR_ERR(clk));
+		pr_err("%s: failed to register mux clock %s: %ld\n", __func__,
+		       clk_name, PTR_ERR(clk));
 		goto out_unmap;
 	}
 
-	of_clk_add_provider(node, of_clk_src_simple_get, clk);
+	if (!of_clk_add_provider(node, of_clk_src_simple_get, clk))
+		return clk;
+
+	pr_err("%s: failed to add clock provider for %s\n", __func__, clk_name);
 
-	return clk;
+	clk_unregister_divider(clk);
 
 out_unmap:
 	iounmap(reg);
-- 
2.6.4



From andre.przywara at arm.com  Fri Feb 12 07:11:50 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Fri, 12 Feb 2016 15:11:50 +0000
Subject: [PATCH 0/3] clk: sunxi: error checking on clock setup
Message-ID: <1455289913-29514-1-git-send-email-andre.przywara@arm.com>

Since I promised to do this some days ago:

Setting up the clocks properly is quite critical to the system's
operation, but currently our error handling is not very verbose.
This series adds error handling and reporting to the sunxi clocks,
so that any errors are correctly detected and reported. Also previous
actions are rolled back in case something went wrong.
This proves to be helpful in debugging clock tree issues,
especially when adding support for new SoCs.
I tested this on a BananaPi by deliberately misspelling
"clock-output-names". The resulting kernel crash in
sun4i_timer_interrupt is totally misleading, but now there is a line
in the dmesg before saying:
=======
sunxi_divider_clk_setup: could not read clock-output-names for "apb0"
=======

This applies on top of Maxime's sunxi/for-next branch.

Please have a look (and apply, if you like it).

Cheers,
Andre.

Andre Przywara (3):
  clk: sunxi: improve mux_clk error handling and reporting
  clk: sunxi: improve divider_clk error handling and reporting
  clk: sunxi: Improve divs_clk error handling and reporting

 drivers/clk/sunxi/clk-sunxi.c | 68 +++++++++++++++++++++++++++++++++++--------
 1 file changed, 56 insertions(+), 12 deletions(-)

-- 
2.6.4



From andre.przywara at arm.com  Fri Feb 12 07:11:53 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Fri, 12 Feb 2016 15:11:53 +0000
Subject: [PATCH 3/3] clk: sunxi: Improve divs_clk error handling and reporting
In-Reply-To: <1455289913-29514-1-git-send-email-andre.przywara@arm.com>
References: <1455289913-29514-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455289913-29514-4-git-send-email-andre.przywara@arm.com>

We catch errors in the base clock registration, failure to ioremap
and failures in the final of_clk_add_provider() call.
Also we unmap the registers when we need to rollback.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 1ac6c9e0..48ed81d 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -987,13 +987,20 @@ static struct clk ** __init sunxi_divs_clk_setup(struct device_node *node,
 
 	/* Set up factor clock that we will be dividing */
 	pclk = sunxi_factors_clk_setup(node, data->factors);
+	if (!pclk)
+		return NULL;
 	parent = __clk_get_name(pclk);
 
 	reg = of_iomap(node, 0);
+	if (!reg) {
+		pr_err("Could not map registers for divs-clk: %s\n",
+		       node->name);
+		return NULL;
+	}
 
 	clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
 	if (!clk_data)
-		return NULL;
+		goto out_unmap;
 
 	clks = kcalloc(ndivs, sizeof(*clks), GFP_KERNEL);
 	if (!clks)
@@ -1076,9 +1083,10 @@ static struct clk ** __init sunxi_divs_clk_setup(struct device_node *node,
 	/* Adjust to the real max */
 	clk_data->clk_num = i;
 
-	of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+	if (!of_clk_add_provider(node, of_clk_src_onecell_get, clk_data))
+		return clks;
 
-	return clks;
+	pr_err("%s: failed to add clock provider for %s\n", __func__, clk_name);
 
 free_gate:
 	kfree(gate);
@@ -1086,6 +1094,8 @@ free_clks:
 	kfree(clks);
 free_clkdata:
 	kfree(clk_data);
+out_unmap:
+	iounmap(reg);
 	return NULL;
 }
 
-- 
2.6.4



From ard.biesheuvel at linaro.org  Fri Feb 12 07:17:09 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 16:17:09 +0100
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>

On 12 February 2016 at 16:10, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Fri, Feb 12, 2016 at 04:02:58PM +0100, Ard Biesheuvel wrote:
>> On 12 February 2016 at 15:58, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > Hi Ard,
>> >
>> > On Mon, Feb 01, 2016 at 11:54:52AM +0100, Ard Biesheuvel wrote:
>> >> This moves the module area to right before the vmalloc area, and
>> >> moves the kernel image to the base of the vmalloc area. This is
>> >> an intermediate step towards implementing KASLR, which allows the
>> >> kernel image to be located anywhere in the vmalloc area.
>> >>
>> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> >
>> > This patch is causing lots of KASAN warnings on Juno (interestingly, it
>> > doesn't seem to trigger on Seattle, though we only tried for-next/core).
>> > I pushed the branch that I'm currently using here:
>> >
>> > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux for-next/kernmap
>> >
>> >
>> > A typical error (though its place varies based on the config options,
>> > kernel layout):
>> >
>> > BUG: KASAN: stack-out-of-bounds in clockevents_program_event+0x28/0x1b0 at addr ffffffc936257cc8
>>
>> Can you confirm that these are stack accesses? I was having similar
>> errors before, and I ended up creating the kasan zero page patch
>> because it turned out the kasan shadow page in question was aliased
>> and the stack writes were occurring elsewhere.
>
> It's possible, we are looking into this. Is there any other patch I miss on
> the above branch?
>

I don't think so but I will check

> BTW, disabling CPU_IDLE, I get other errors:
>
> WARNING: at /work/Linux/linux-2.6-aarch64/mm/vmalloc.c:135
> Modules linked in:
>

Since this occurs in kasan_module_alloc(), I think this may be a
symptom of the same underlying issue, where the kernel VA space and
the projection onto the Kasan shadow area are somehow out of sync.

I will try to reproduce with the branch above.



> CPU: 2 PID: 973 Comm: systemd-modules Tainted: G        W       4.5.0-rc1+ #131
> Hardware name: Juno (DT)
> task: ffffffc93448e200 ti: ffffffc9346ac000 task.ti: ffffffc9346ac000
> PC is at vmap_page_range_noflush+0x240/0x2e8
> LR is at vmap_page_range_noflush+0x16c/0x2e8
> pc : [<ffffff90041fef78>] lr : [<ffffff90041feea4>] pstate: 20000145
> sp : ffffffc9346af9b0
> x29: ffffffc9346af9b0 x28: ffffff90050da000
> x27: ffffffc001438008 x26: ffffffbde6d16440
> x25: 0000004240000000 x24: ffffffc97ff3a000
> x23: 0000000000000041 x22: ffffffc078e9e600
> x21: ffffff8200002000 x20: ffffff8200001000
> x19: 0000000000000000 x18: 00000000f3294c2f
> x17: 00000000f7dc90fb x16: 0000000087b402ce
> x15: ffffffffffffffff x14: ffffff0000000000
> x13: ffffffffffffffff x12: 0000000000000028
> x11: 0101010101010101 x10: 00000001801a001a
> x9 : 0000000000000000 x8 : ffffff89268b2400
> x7 : 0000000000000000 x6 : 000000000000003f
> x5 : 0000000000000040 x4 : 0000000000000000
> x3 : 0000000000000000 x2 : 1ffffff800287001
> x1 : dfffff9000000000 x0 : 00e8000081439713
>
> ---[ end trace 8a78d7ad8d08d2a9 ]---
> Call trace:
> Exception stack(0xffffffc9346af790 to 0xffffffc9346af8b0)
> f780:                                   0000000000000000 ffffff8200001000
> f7a0: ffffffc9346af9b0 ffffff90041fef78 0000000020000145 000000000000003d
> f7c0: 0000004240000000 ffffffc078e9f600 0000000041b58ab3 ffffff9004f0c370
> f7e0: ffffff9004082608 ffffffc078e9f620 00000000024080c2 0000000000400000
> f800: ffffffc9346afe70 ffffffc9346afe50 ffffffc9346af9b0 ffffffc93448e200
> f820: ffffffc9346af830 ffffff900408b1b0 ffffffc9346af900 ffffff900408b228
> f840: ffffffc9346ac000 ffffffc9346af9b0 ffffffc9346ac000 ffffffc078e9e600
> f860: 0000000041b58ab3 ffffff9004f0c8a8 ffffff900408b080 000000010010000e
> f880: ffffffc9346af9b0 0000000000000000 00e8000081439713 dfffff9000000000
> f8a0: 1ffffff800287001 0000000000000000
> [<ffffff90041fef78>] vmap_page_range_noflush+0x240/0x2e8
> [<ffffff90041ff078>] map_vm_area+0x58/0x88
> [<ffffff9004200400>] __vmalloc_node_range+0x2b8/0x350
> [<ffffff9004224394>] kasan_module_alloc+0x64/0xb8
> [<ffffff90040943f4>] module_alloc+0x5c/0xa0
> [<ffffff9004169460>] load_module+0x1798/0x3098
> [<ffffff900416b020>] SyS_finit_module+0xf8/0x108
> [<ffffff9004085d30>] el0_svc_naked+0x24/0x28
> vmalloc: allocation failure, allocated 4096 of 4096 bytes
>
> --
> Catalin


From peter at hurleysoftware.com  Fri Feb 12 07:17:45 2016
From: peter at hurleysoftware.com (Peter Hurley)
Date: Fri, 12 Feb 2016 07:17:45 -0800
Subject: [PATCH v2] serial: earlycon: rework common framework for earlycon
 declarations
In-Reply-To: <1455273394-27350-1-git-send-email-yamada.masahiro@socionext.com>
References: <1455273394-27350-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <56BDF799.1030505@hurleysoftware.com>

On 02/12/2016 02:36 AM, Masahiro Yamada wrote:
> Commit 71f50c6d9a22 ("of: drop symbols declared by _OF_DECLARE() from
> modules") fixed the link error introduced by commit b8d20e06eaad
> ("serial: 8250_uniphier: add earlycon support").
> 
> After commit 2eaa790989e0 ("earlycon: Use common framework for
> earlycon declarations") was applied, the link error came back
> because the commit reworked OF_EARLYCON_DECLARE() to not use
> _OF_DECLARE().

What link error are you getting?


> This commit reworks OF_EARLYCON_DECLARE() again based on
> _OF_DECLARE().  My motivations are:
> 
>  - Fix the link error in a generic way (without patching
>    drivers/tty/serial/8250/8250_uniphier.c)
> 
>  - Delete struct earlycon_id.  This struct is re-inventing the wheel;
>    the fields "name", "compatible", "setup" can be implemented in
>    struct of_device_id as other frameworks do.

This patch basically reverts the common framework.
What happens when not building with OF? Does it still declare the
earlycon table?


> The difference between OF_EARLYCON_DECLARE() and other users of
> _OF_DECLARE is that OF_EARLYCON_DECLARE() needs to fill the "name"
> field of struct of_device_id.  To make it easier, a new macro
> _OF_DECLARE_WITH_NAME() has been added.  It fills the "name" field
> with the given argument.  On the other hand, _OF_DECLARE() sets it
> to a null string; this is the same behavior as before.
> 
> Fixes: 2eaa790989e0 ("earlycon: Use common framework for earlycon declarations")
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
> ---
> 
> I confirmed this patch can apply onto "next-20160212" tag of linux-next.
> 
> In order to apply it onto the "tty-next" branch of TTY subsytem,
> Greg will have to pull v4.5-rc3 in.
> 
> 
> Changes in v2:
>   Minor updates of git-log
>    - fix a typo framework/frameworks/).
>    - s/Grag/Greg/   (Sorry!)
> 
>  drivers/of/fdt.c                  |  7 ++-----
>  drivers/tty/serial/earlycon.c     | 19 +++++++++++++------
>  include/asm-generic/vmlinux.lds.h | 12 ++----------
>  include/linux/of.h                | 22 +++++++++++++++-------
>  include/linux/serial_core.h       | 23 +++++++----------------
>  5 files changed, 39 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index e2295b2..ad262e9 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -802,7 +802,7 @@ static int __init early_init_dt_scan_chosen_serial(void)
>  	int offset;
>  	const char *p, *q, *options = NULL;
>  	int l;
> -	const struct earlycon_id *match;
> +	const struct of_device_id *match;
>  	const void *fdt = initial_boot_params;
>  
>  	offset = fdt_path_offset(fdt, "/chosen");
> @@ -829,10 +829,7 @@ static int __init early_init_dt_scan_chosen_serial(void)
>  		return 0;
>  	}
>  
> -	for (match = __earlycon_table; match < __earlycon_table_end; match++) {
> -		if (!match->compatible[0])
> -			continue;
> -
> +	for (match = __earlycon_of_table; match->compatible[0]; match++) {
>  		if (fdt_node_check_compatible(fdt, offset, match->compatible))
>  			continue;
>  
> diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
> index 067783f..4888ced 100644
> --- a/drivers/tty/serial/earlycon.c
> +++ b/drivers/tty/serial/earlycon.c
> @@ -38,6 +38,9 @@ static struct earlycon_device early_console_dev = {
>  	.con = &early_con,
>  };
>  
> +static const struct of_device_id __earlycon_of_table_sentinel
> +	__used __section(__earlycon_of_table_end);
> +
>  static void __iomem * __init earlycon_map(unsigned long paddr, size_t size)
>  {
>  	void __iomem *base;
> @@ -127,9 +130,10 @@ static int __init parse_options(struct earlycon_device *device, char *options)
>  	return 0;
>  }
>  
> -static int __init register_earlycon(char *buf, const struct earlycon_id *match)
> +static int __init register_earlycon(char *buf, const struct of_device_id *match)
>  {
>  	int err;
> +	int (*setup)(struct earlycon_device *, const char *options);
>  	struct uart_port *port = &early_console_dev.port;
>  
>  	/* On parsing error, pass the options buf to the setup function */
> @@ -142,7 +146,8 @@ static int __init register_earlycon(char *buf, const struct earlycon_id *match)
>  		port->membase = earlycon_map(port->mapbase, 64);
>  
>  	earlycon_init(&early_console_dev, match->name);
> -	err = match->setup(&early_console_dev, buf);
> +	setup = match->data;
> +	err = setup(&early_console_dev, buf);
>  	if (err < 0)
>  		return err;
>  	if (!early_console_dev.con->write)
> @@ -172,7 +177,7 @@ static int __init register_earlycon(char *buf, const struct earlycon_id *match)
>   */
>  int __init setup_earlycon(char *buf)
>  {
> -	const struct earlycon_id *match;
> +	const struct of_device_id *match;
>  
>  	if (!buf || !buf[0])
>  		return -EINVAL;
> @@ -180,7 +185,7 @@ int __init setup_earlycon(char *buf)
>  	if (early_con.flags & CON_ENABLED)
>  		return -EALREADY;
>  
> -	for (match = __earlycon_table; match < __earlycon_table_end; match++) {
> +	for (match = __earlycon_of_table; match->name[0]; match++) {
>  		size_t len = strlen(match->name);
>  
>  		if (strncmp(buf, match->name, len))
> @@ -220,12 +225,13 @@ early_param("earlycon", param_setup_earlycon);
>  
>  #ifdef CONFIG_OF_EARLY_FLATTREE
>  
> -int __init of_setup_earlycon(const struct earlycon_id *match,
> +int __init of_setup_earlycon(const struct of_device_id *match,
>  			     unsigned long node,
>  			     const char *options)
>  {
>  	int err;
>  	struct uart_port *port = &early_console_dev.port;
> +	int (*setup)(struct earlycon_device *, const char *options);
>  	const __be32 *val;
>  	bool big_endian;
>  	u64 addr;
> @@ -273,7 +279,8 @@ int __init of_setup_earlycon(const struct earlycon_id *match,
>  			sizeof(early_console_dev.options));
>  	}
>  	earlycon_init(&early_console_dev, match->name);
> -	err = match->setup(&early_console_dev, options);
> +	setup = match->data;
> +	err = setup(&early_console_dev, options);
>  	if (err < 0)
>  		return err;
>  	if (!early_console_dev.con->write)
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index e9a81a6..699f4a5 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -153,15 +153,6 @@
>  #define TRACE_SYSCALLS()
>  #endif
>  
> -#ifdef CONFIG_SERIAL_EARLYCON
> -#define EARLYCON_TABLE() STRUCT_ALIGN();			\
> -			 VMLINUX_SYMBOL(__earlycon_table) = .;	\
> -			 *(__earlycon_table)			\
> -			 VMLINUX_SYMBOL(__earlycon_table_end) = .;
> -#else
> -#define EARLYCON_TABLE()
> -#endif
> -
>  #define ___OF_TABLE(cfg, name)	_OF_TABLE_##cfg(name)
>  #define __OF_TABLE(cfg, name)	___OF_TABLE(cfg, name)
>  #define OF_TABLE(cfg, name)	__OF_TABLE(config_enabled(cfg), name)
> @@ -179,6 +170,7 @@
>  #define RESERVEDMEM_OF_TABLES()	OF_TABLE(CONFIG_OF_RESERVED_MEM, reservedmem)
>  #define CPU_METHOD_OF_TABLES()	OF_TABLE(CONFIG_SMP, cpu_method)
>  #define CPUIDLE_METHOD_OF_TABLES() OF_TABLE(CONFIG_CPU_IDLE, cpuidle_method)
> +#define EARLYCON_OF_TABLES()	OF_TABLE(CONFIG_SERIAL_EARLYCON, earlycon)
>  
>  #ifdef CONFIG_ACPI
>  #define ACPI_PROBE_TABLE(name)						\
> @@ -525,7 +517,7 @@
>  	IRQCHIP_OF_MATCH_TABLE()					\
>  	ACPI_PROBE_TABLE(irqchip)					\
>  	ACPI_PROBE_TABLE(clksrc)					\
> -	EARLYCON_TABLE()
> +	EARLYCON_OF_TABLES()
>  
>  #define INIT_TEXT							\
>  	*(.init.text)							\
> diff --git a/include/linux/of.h b/include/linux/of.h
> index dc6e396..6e57245 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -930,19 +930,27 @@ static inline int of_get_available_child_count(const struct device_node *np)
>  }
>  
>  #if defined(CONFIG_OF) && !defined(MODULE)
> -#define _OF_DECLARE(table, name, compat, fn, fn_type)			\
> -	static const struct of_device_id __of_table_##name		\
> +#define __OF_DECLARE(table, name1, name2, compat, fn, fn_type)		\
> +	static const struct of_device_id __UNIQUE_ID(__of_table_##name1)\
>  		__used __section(__##table##_of_table)			\
> -		 = { .compatible = compat,				\
> +		 = { .name = name2,					\
> +		     .compatible = compat,				\
>  		     .data = (fn == (fn_type)NULL) ? fn : fn  }
>  #else
> -#define _OF_DECLARE(table, name, compat, fn, fn_type)			\
> -	static const struct of_device_id __of_table_##name		\
> +#define __OF_DECLARE(table, name1, name2, compat, fn, fn_type)		\
> +	static const struct of_device_id __UNIQUE_ID(__of_table_##name1)\
>  		__attribute__((unused))					\
> -		 = { .compatible = compat,				\
> -		     .data = (fn == (fn_type)NULL) ? fn : fn }
> +		 = { .name = name2,					\
> +		     .compatible = compat,				\
> +		     .data = (fn == (fn_type)NULL) ? fn : fn  }
>  #endif
>  
> +#define _OF_DECLARE(table, name, compat, fn, fn_type)	\
> +	__OF_DECLARE(table, name, "", compat, fn, fn_type)
> +
> +#define _OF_DECLARE_WITH_NAME(table, name, compat, fn, fn_type)	\
> +	__OF_DECLARE(table, name, __stringify(name), compat, fn, fn_type)
> +
>  typedef int (*of_init_fn_2)(struct device_node *, struct device_node *);
>  typedef void (*of_init_fn_1)(struct device_node *);
>  
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index cbfcf38..0f13160 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -24,6 +24,7 @@
>  #include <linux/compiler.h>
>  #include <linux/interrupt.h>
>  #include <linux/circ_buf.h>
> +#include <linux/mod_devicetable.h>
>  #include <linux/spinlock.h>
>  #include <linux/sched.h>
>  #include <linux/tty.h>
> @@ -340,26 +341,16 @@ struct earlycon_device {
>  	unsigned int baud;
>  };
>  
> -struct earlycon_id {
> -	char	name[16];
> -	char	compatible[128];
> -	int	(*setup)(struct earlycon_device *, const char *options);
> -} __aligned(32);
> +extern const struct of_device_id __earlycon_of_table[];
>  
> -extern const struct earlycon_id __earlycon_table[];
> -extern const struct earlycon_id __earlycon_table_end[];
> +#define OF_EARLYCON_DECLARE(name, compat, fn)				\
> +	_OF_DECLARE_WITH_NAME(earlycon, name, compat, fn, void *)
>  
> -#define OF_EARLYCON_DECLARE(_name, compat, fn)				\
> -	static const struct earlycon_id __UNIQUE_ID(__earlycon_##_name)	\
> -	     __used __section(__earlycon_table)				\
> -		= { .name = __stringify(_name),				\
> -		    .compatible = compat,				\
> -		    .setup = fn  }
> -
> -#define EARLYCON_DECLARE(_name, fn)	OF_EARLYCON_DECLARE(_name, "", fn)
> +#define EARLYCON_DECLARE(_name, fn)	\
> +	OF_EARLYCON_DECLARE(_name, "-earlycon-dummy-compat-string-", fn)
>  
>  extern int setup_earlycon(char *buf);
> -extern int of_setup_earlycon(const struct earlycon_id *match,
> +extern int of_setup_earlycon(const struct of_device_id *match,
>  			     unsigned long node,
>  			     const char *options);
>  
> 



From alexander.shishkin at linux.intel.com  Fri Feb 12 07:18:48 2016
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Fri, 12 Feb 2016 17:18:48 +0200
Subject: [PATCH V3 1/6] stm class: Add ioctl get_options interface
In-Reply-To: <1454756672-12790-2-git-send-email-zhang.chunyan@linaro.org>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
 <1454756672-12790-2-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <87ziv62bzb.fsf@ashishki-desk.ger.corp.intel.com>

Chunyan Zhang <zhang.chunyan at linaro.org> writes:

> There is already an interface of set_options, but no get_options yet.
> Before setting any options, one would may want to see the current
> status of that option by means of get_options interface. This
> interface has been used in CoreSight STM driver.

I'm not sure I understand the reasoning behind this. If a userspace
program opens a communication channel and wants to configure certain
features on it, why does its choice depend on what has been configured
for this channel previously? It can be anything at all. Most likely,
it's either unconfigured or configured to its default values, but why
does this matter for a new writer?

Regards,
--
Alex


From robin.murphy at arm.com  Fri Feb 12 07:23:04 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Fri, 12 Feb 2016 15:23:04 +0000
Subject: [PATCH 4/3] iommu/io-pgtable: Rationalise quirk handling
In-Reply-To: <4282853.vdxKI5JT5z@avalon>
References: <cover.1453723096.git.robin.murphy@arm.com>
 <ea1f3d3feec0dc9c18d43393678370b50b1275f5.1455206840.git.robin.murphy@arm.com>
 <20160212120857.GN25087@arm.com> <4282853.vdxKI5JT5z@avalon>
Message-ID: <56BDF8D8.4010200@arm.com>

On 12/02/16 12:32, Laurent Pinchart wrote:
> On Friday 12 February 2016 12:08:58 Will Deacon wrote:
>> On Thu, Feb 11, 2016 at 04:13:45PM +0000, Robin Murphy wrote:
>>> As the number of io-pgtable implementations grows beyond 1, it's time
>>> to rationalise the quirks mechanism before things have a chance to
>>> start getting really ugly and out-of-hand.
>>>
>>> To that end:
>>> - Indicate exactly which quirks each format can/does support.
>>> - Fail creating a table if a caller wants unsupported quirks.
>>> - Properly document where each quirk applies and why.
>>>
>>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>>> ---
>>>
>>>   drivers/iommu/io-pgtable-arm-v7s.c |  3 +++
>>>   drivers/iommu/io-pgtable-arm.c     |  2 ++
>>>   drivers/iommu/io-pgtable.c         |  3 +++
>>>   drivers/iommu/io-pgtable.h         | 24 ++++++++++++++++++++----
>>>   4 files changed, 28 insertions(+), 4 deletions(-)
>>
>> Note that I can't merge this until we've figured out the plan for Yong's
>> driver.

Indeed (hence 4/3) - it just ended up seeming like a significant enough 
change to warrant its own patch, but not critical enough to warrant 
splitting it for the sake of applying the parts touching the existing 
code right now.

>>> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
>>> b/drivers/iommu/io-pgtable-arm-v7s.c index d39a021..9bc607a 100644
>>> --- a/drivers/iommu/io-pgtable-arm-v7s.c
>>> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
>>>
>>> @@ -690,6 +690,9 @@ out_free_data:
>>>   struct io_pgtable_init_fns io_pgtable_arm_v7s_init_fns = {
>>>
>>>   	.alloc	= arm_v7s_alloc_pgtable,
>>>   	.free	= arm_v7s_free_pgtable,
>>>
>>> +	.supported_quirks = IO_PGTABLE_QUIRK_ARM_NS |
>>> +			    IO_PGTABLE_QUIRK_NO_PERMS |
>>> +			    IO_PGTABLE_QUIRK_TLBI_ON_MAP,
>>>
>>>   };
>>>
>>>   #ifdef CONFIG_IOMMU_IO_PGTABLE_ARMV7S_SELFTEST
>>>
>>> diff --git a/drivers/iommu/io-pgtable-arm.c
>>> b/drivers/iommu/io-pgtable-arm.c index 4095af2..32f94f1 100644
>>> --- a/drivers/iommu/io-pgtable-arm.c
>>> +++ b/drivers/iommu/io-pgtable-arm.c
>>> @@ -863,6 +863,7 @@ arm_32_lpae_alloc_pgtable_s2(struct io_pgtable_cfg
>>> *cfg, void *cookie)>
>>>   struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s1_init_fns = {
>>>
>>>   	.alloc	= arm_64_lpae_alloc_pgtable_s1,
>>>   	.free	= arm_lpae_free_pgtable,
>>>
>>> +	.supported_quirks = IO_PGTABLE_QUIRK_ARM_NS,
>>>
>>>   };
>>>
>>>   struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s2_init_fns = {
>>>
>>> @@ -873,6 +874,7 @@ struct io_pgtable_init_fns
>>> io_pgtable_arm_64_lpae_s2_init_fns = {>
>>>   struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s1_init_fns = {
>>>
>>>   	.alloc	= arm_32_lpae_alloc_pgtable_s1,
>>>   	.free	= arm_lpae_free_pgtable,
>>>
>>> +	.supported_quirks = IO_PGTABLE_QUIRK_ARM_NS,
>>>
>>>   };
>>>
>>>   struct io_pgtable_init_fns io_pgtable_arm_32_lpae_s2_init_fns = {
>>>
>>> diff --git a/drivers/iommu/io-pgtable.c b/drivers/iommu/io-pgtable.c
>>> index 876f6a7..0f57a45 100644
>>> --- a/drivers/iommu/io-pgtable.c
>>> +++ b/drivers/iommu/io-pgtable.c
>>> @@ -52,6 +52,9 @@ struct io_pgtable_ops *alloc_io_pgtable_ops(enum
>>> io_pgtable_fmt fmt,>
>>>   	if (!fns)
>>>   	
>>>   		return NULL;
>>>
>>> +	if (cfg->quirks & ~fns->supported_quirks)
>>> +		return NULL;
>>> +
>>>
>>>   	iop = fns->alloc(cfg, cookie);
>>>   	if (!iop)
>>>   	
>>>   		return NULL;
>>>
>>> diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
>>> index 4faee7d..6e7f11e 100644
>>> --- a/drivers/iommu/io-pgtable.h
>>> +++ b/drivers/iommu/io-pgtable.h
>>> @@ -47,10 +47,24 @@ struct iommu_gather_ops {
>>>
>>>    *                 page table walker.
>>>    */
>>>
>>>   struct io_pgtable_cfg {
>>>
>>> -	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0) /* Set NS bit in PTEs */
>>> -	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1) /* No AP/XN bits */
>>> -	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2) /* TLB Inv. on map */
>>> -	int				quirks;
>>> +	/*
>>> +	 * IO_PGTABLE_QUIRK_ARM_NS: (ARM formats) Set NS and NSTABLE bits in
>>> +	 *	stage 1 PTEs, for hardware which insists on validating them
>>> +	 *	even in	non-secure state where they should normally be ignored.
>>> +	 *
>>> +	 * IO_PGTABLE_QUIRK_NO_PERMS: Ignore the IOMMU_READ, IOMMU_WRITE and
>>> +	 *	IOMMU_NOEXEC flags and map everything with full access, for
>>> +	 *	hardware which does not implement the permissions of a given
>>> +	 *	format, and/or requires some format-specific default value.
>>> +	 *
>>> +	 * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching
> invalid
>>> +	 *	(unmapped) entries but the hardware might do so anyway, perform
>>> +	 *	TLB maintenance when mapping as well as when unmapping.
>>> +	 */
>>
>> Much better, cheers.
>>
>>> +	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
>>> +	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
>>> +	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2)
>>> +	unsigned int			quirks;
>>
>> Let's just make this unsigned long.
>>
>>>   	unsigned long			pgsize_bitmap;
>>>   	unsigned int			ias;
>>>   	unsigned int			oas;
>>>
>>> @@ -173,10 +187,12 @@ static inline void io_pgtable_tlb_sync(struct
>>> io_pgtable *iop)
>>>    *
>>>    * @alloc: Allocate a set of page tables described by cfg.
>>>    * @free:  Free the page tables associated with iop.
>>> + * @supported_quirks: Bitmap of quirks supported by the format.
>>>    */
>>>   struct io_pgtable_init_fns {
>>>   	struct io_pgtable *(*alloc)(struct io_pgtable_cfg *cfg, void
> *cookie);
>>>   	void (*free)(struct io_pgtable *iop);
>>> +	unsigned int supported_quirks;
>>>   };
>>
>> My only gripe here is that this is supposed to be a struct of function
>> pointers... get_supported_quirks() ?
>
> Can't we instead say it's a struct of function pointers and static data ? :-)
> A function to retrieve the supported quirks will just contribute to kernel
> bloat without adding any extra benefit.

Bleh - personally I think it's marginally more obvious and readable to 
have the information looking like data, but I'd much sooner just have a 
hard-coded "if (cfq->quirks & ..." check in every format's alloc 
function than introduce a whole new callback. Does that sound like a 
reasonable compromise?

Robin.


From robh at kernel.org  Fri Feb 12 07:23:06 2016
From: robh at kernel.org (Rob Herring)
Date: Fri, 12 Feb 2016 09:23:06 -0600
Subject: [PATCH 4/6] dt-bindings: watchdog: Add ARM SP805 DT bindings
In-Reply-To: <1455084651-29325-5-git-send-email-anup.patel@broadcom.com>
References: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
 <1455084651-29325-5-git-send-email-anup.patel@broadcom.com>
Message-ID: <20160212152306.GA29673@rob-hp-laptop>

On Wed, Feb 10, 2016 at 11:40:49AM +0530, Anup Patel wrote:
> The ARM SP805 DT node is already present in various DTS files.
> This patch adds missing DT bindings documentation for ARM SP805.
> 
> Signed-off-by: Anup Patel <anup.patel at broadcom.com>
> Reviewed-by: Ray Jui <rjui at broadcom.com>
> Reviewed-by: Vikram Prakash <vikramp at broadcom.com>
> Reviewed-by: Scott Branden <sbranden at broadcom.com>
> ---
>  .../devicetree/bindings/watchdog/arm,sp805.txt          | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/watchdog/arm,sp805.txt
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/arm,sp805.txt b/Documentation/devicetree/bindings/watchdog/arm,sp805.txt
> new file mode 100644
> index 0000000..6ebb77d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/arm,sp805.txt
> @@ -0,0 +1,17 @@
> +ARM AMBA Primecell SP805 Watchdog
> +
> +Required properties:
> +- compatible: Should be "arm,sp805" & "arm,primecell"
> +- reg: Should contain location and length for watchdog timer register.
> +- interrupts: Should contain the list of watchdog timer interrupts.
> +- clocks: clocks driving the watchdog timer hardware. This list should be 2
> +	clocks. With 2 clocks, the order is wdogclk clock, apb_pclk.
> +
> +Example:
> +	wdt at 66090000 {

This should be watchdog at ...

Otherwise:

Acked-by: Rob Herring <robh at kernel.org>


From catalin.marinas at arm.com  Fri Feb 12 07:26:41 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 12 Feb 2016 15:26:41 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
Message-ID: <20160212152641.GK31665@e104818-lin.cambridge.arm.com>

On Fri, Feb 12, 2016 at 04:17:09PM +0100, Ard Biesheuvel wrote:
> On 12 February 2016 at 16:10, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Fri, Feb 12, 2016 at 04:02:58PM +0100, Ard Biesheuvel wrote:
> >> On 12 February 2016 at 15:58, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> > On Mon, Feb 01, 2016 at 11:54:52AM +0100, Ard Biesheuvel wrote:
> >> >> This moves the module area to right before the vmalloc area, and
> >> >> moves the kernel image to the base of the vmalloc area. This is
> >> >> an intermediate step towards implementing KASLR, which allows the
> >> >> kernel image to be located anywhere in the vmalloc area.
> >> >>
> >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >> >
> >> > This patch is causing lots of KASAN warnings on Juno (interestingly, it
> >> > doesn't seem to trigger on Seattle, though we only tried for-next/core).
> >> > I pushed the branch that I'm currently using here:
> >> >
> >> > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux for-next/kernmap
> >> >
> >> >
> >> > A typical error (though its place varies based on the config options,
> >> > kernel layout):
> >> >
> >> > BUG: KASAN: stack-out-of-bounds in clockevents_program_event+0x28/0x1b0 at addr ffffffc936257cc8
> >>
> >> Can you confirm that these are stack accesses? I was having similar
> >> errors before, and I ended up creating the kasan zero page patch
> >> because it turned out the kasan shadow page in question was aliased
> >> and the stack writes were occurring elsewhere.
> >
> > It's possible, we are looking into this. Is there any other patch I miss on
> > the above branch?
> 
> I don't think so but I will check

Commit 7b1af9795773 ("arm64: kasan: ensure that the KASAN zero page is
mapped read-only") was merged in -rc2 while the branch above is based on
-rc1. Anyway, I merged it into -rc2 and the errors are similar.

-- 
Catalin


From matthias.bgg at gmail.com  Fri Feb 12 07:28:13 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Fri, 12 Feb 2016 16:28:13 +0100
Subject: mt1873-evb: MMC failing with linux-next
In-Reply-To: <56BDF937.60208@gmail.com>
References: <7hegcmadfk.fsf@baylibre.com> <56BDF937.60208@gmail.com>
Message-ID: <56BDFA0D.5080806@gmail.com>

Hi,

I just resend as the attachment was to too big for linux-arm-kernel.

On 12/02/16 16:24, Matthias Brugger wrote:
> Hi Kevin,
>
> On 09/02/16 02:18, Kevin Hilman wrote:
>> Hello,
>>
>> I tried getting MMC working with linux-next (next-20160208) on
>> mt8173-evb by enabling a few options[1] on top of the default defconfig,
>> and this results in a kernel that hangs as soon as it starts userspace.
>>
>> The MMC driver seems to start, though has some regulator issues:
>>
>> [    0.526380] sdhci: Secure Digital Host Controller Interface driver
>> [    0.527176] sdhci: Copyright(c) Pierre Ossman
>> [    0.528835] vio18: unsupportable voltage range: 3300000-1980000uV
>> [    0.529610] mtk-msdc 11230000.mmc: Regulator set error -22:
>> 3300000 - 3300000
>> [    0.563731] mtk-msdc 11240000.mmc: Got CD GPIO
>>
>> The driver appears to be attempting to set 3.3V but using a 1.8V
>> regulator (vio18), which is failing.
>>
>> Then, the kernel hangs after freeing unused memory:
>>
>> [    0.616386] hctosys: unable to open rtc device (rtc0)
>> [    0.624118] usb_vbus: disabling
>> [    0.624547] vusb: disabling
>> [    0.624929] vgp6: disabling
>> [    0.625635] ALSA device list:
>> [    0.626009]   No soundcards found.
>> [    0.626963] Freeing unused kernel memory: 724K (ffffffc000977000 -
>> ffffffc000a2c000)
>>
>> And nothing further here.
>>
>
> I can see the warning from the mmc regulator access, but after that my
> board boots just fine.
> I'm using linux-next as of today (20160212).
> I attached my config, it should be defconfig plus the config options you
> mentioned (and an initramfs).
>

Instead of attaching my config, you can find it here:
http://pastebin.com/5uhXtSHj

> Is this the configuration you have?
>
> Regards,
> Matthias
>
>> It boots fine when disabling the MMC driver (CONFIG_MMC_MTK=n).
>>
>> Any ideas?
>>
>> Kevin
>>
>> [1]
>> CONFIG_MMC_MTK=y
>> CONFIG_MFD_MT6397=y
>> CONFIG_REGULATOR_MT6397=y
>> CONFIG_MTK_PMIC_WRAP=y
>>


From alexander.shishkin at linux.intel.com  Fri Feb 12 07:28:16 2016
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Fri, 12 Feb 2016 17:28:16 +0200
Subject: [PATCH V3 6/6] coresight-stm: adding driver for CoreSight STM
 component
In-Reply-To: <1454756672-12790-7-git-send-email-zhang.chunyan@linaro.org>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
 <1454756672-12790-7-git-send-email-zhang.chunyan@linaro.org>
Message-ID: <87y4aq2bjj.fsf@ashishki-desk.ger.corp.intel.com>

Chunyan Zhang <zhang.chunyan at linaro.org> writes:

> +static long stm_generic_set_options(struct stm_data *stm_data,
> +				    unsigned int master,
> +				    unsigned int channel,
> +				    unsigned int nr_chans,
> +				    unsigned long options)
> +{
> +	struct stm_drvdata *drvdata = container_of(stm_data,
> +						   struct stm_drvdata, stm);
> +	if (!(drvdata && drvdata->enable))
> +		return -EINVAL;
> +
> +	if (channel >= drvdata->numsp)
> +		return -EINVAL;
> +
> +	switch (options) {
> +	case STM_OPTION_GUARANTEED:
> +		set_bit(channel, drvdata->chs.guaranteed);
> +		break;
> +
> +	case STM_OPTION_INVARIANT:
> +		clear_bit(channel, drvdata->chs.guaranteed);
> +		break;

This is a bad interface. Firstly, neither option is described
anywhere. Secondly, I'm pretty sure "invariant" does not mean "not
guaranteed" in english, although this function seems to imply this.

> +
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
> +static long stm_generic_get_options(struct stm_data *stm_data,
> +				    unsigned int master,
> +				    unsigned int channel,
> +				    unsigned int nr_chans,
> +				    u64 *options)
> +{
> +	struct stm_drvdata *drvdata = container_of(stm_data,
> +						   struct stm_drvdata, stm);
> +	if (!(drvdata && drvdata->enable))
> +		return -EINVAL;
> +
> +	if (channel >= drvdata->numsp)
> +		return -EINVAL;
> +
> +	switch (*options) {
> +	case STM_OPTION_GUARANTEED:
> +		*options = test_bit(channel, drvdata->chs.guaranteed);
> +		break;

This just doesn't work. @options here is an on-stack variable in
stm_char_ioctl(), hitherto uninitialized. The get_options ioctl command
as you implemented it doesn't fetch @options from userspace either, it
just passes a pointer to it to this callback, expecting that the
callback will set it so that it can be copy_to_user()ed back to the
user.

Then, when we figure this out, there is again the question of what
should one make of STM_OPTION_{GUARANTEED,INVARIANT} and how do they fit
into *options.

The idea behind set_options ioctl is that the user specifies a bit mask
of options that he/she wants to set.

[snip]

> +#ifndef __UAPI_CORESIGHT_STM_H_
> +#define __UAPI_CORESIGHT_STM_H_
> +
> +#define STM_FLAG_TIMESTAMPED   BIT(3)
> +#define STM_FLAG_GUARANTEED    BIT(7)
> +
> +enum {
> +	STM_OPTION_GUARANTEED = 0,
> +	STM_OPTION_INVARIANT,
> +};

Each of these guys could also use an explanation.

Regards,
--
Alex


From sudeep.holla at arm.com  Fri Feb 12 07:38:46 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Fri, 12 Feb 2016 15:38:46 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
Message-ID: <56BDFC86.5010705@arm.com>


On 12/02/16 15:26, Catalin Marinas wrote:
> On Fri, Feb 12, 2016 at 04:17:09PM +0100, Ard Biesheuvel wrote:
>> On 12 February 2016 at 16:10, Catalin Marinas <catalin.marinas at arm.com> wrote:
>>> On Fri, Feb 12, 2016 at 04:02:58PM +0100, Ard Biesheuvel wrote:
>>>> On 12 February 2016 at 15:58, Catalin Marinas <catalin.marinas at arm.com> wrote:
>>>>> On Mon, Feb 01, 2016 at 11:54:52AM +0100, Ard Biesheuvel wrote:
>>>>>> This moves the module area to right before the vmalloc area, and
>>>>>> moves the kernel image to the base of the vmalloc area. This is
>>>>>> an intermediate step towards implementing KASLR, which allows the
>>>>>> kernel image to be located anywhere in the vmalloc area.
>>>>>>
>>>>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>>>>>
>>>>> This patch is causing lots of KASAN warnings on Juno (interestingly, it
>>>>> doesn't seem to trigger on Seattle, though we only tried for-next/core).
>>>>> I pushed the branch that I'm currently using here:
>>>>>
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux for-next/kernmap
>>>>>
>>>>>
>>>>> A typical error (though its place varies based on the config options,
>>>>> kernel layout):
>>>>>
>>>>> BUG: KASAN: stack-out-of-bounds in clockevents_program_event+0x28/0x1b0 at addr ffffffc936257cc8
>>>>
>>>> Can you confirm that these are stack accesses? I was having similar
>>>> errors before, and I ended up creating the kasan zero page patch
>>>> because it turned out the kasan shadow page in question was aliased
>>>> and the stack writes were occurring elsewhere.
>>>
>>> It's possible, we are looking into this. Is there any other patch I miss on
>>> the above branch?
>>
>> I don't think so but I will check
>
> Commit 7b1af9795773 ("arm64: kasan: ensure that the KASAN zero page is
> mapped read-only") was merged in -rc2 while the branch above is based on
> -rc1. Anyway, I merged it into -rc2 and the errors are similar.
>

Sorry to add more confusion, but I observed similar KASAN warning
with latest mainline(v4.5-rc3+, commit c05235d50f68) with below diff.

Regards,
Sudeep

--->8

diff --git i/arch/arm64/Kconfig w/arch/arm64/Kconfig
index 8cc62289a63e..fdd1d75f5bad 100644
--- i/arch/arm64/Kconfig
+++ w/arch/arm64/Kconfig
@@ -9,6 +9,7 @@ config ARM64
         select ARCH_HAS_GCOV_PROFILE_ALL
         select ARCH_HAS_SG_CHAIN
         select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
+       select ARCH_HAS_UBSAN_SANITIZE_ALL
         select ARCH_USE_CMPXCHG_LOCKREF
         select ARCH_SUPPORTS_ATOMIC_RMW
         select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git i/arch/arm64/configs/defconfig w/arch/arm64/configs/defconfig
index 86581f793e39..0006b0204b97 100644
--- i/arch/arm64/configs/defconfig
+++ w/arch/arm64/configs/defconfig
@@ -240,11 +240,14 @@ CONFIG_DEBUG_INFO=y
  CONFIG_DEBUG_FS=y
  CONFIG_MAGIC_SYSRQ=y
  CONFIG_DEBUG_KERNEL=y
+CONFIG_KASAN=y
+CONFIG_TEST_KASAN=m
  CONFIG_LOCKUP_DETECTOR=y
  # CONFIG_SCHED_DEBUG is not set
  # CONFIG_DEBUG_PREEMPT is not set
  # CONFIG_FTRACE is not set
  CONFIG_MEMTEST=y
+CONFIG_UBSAN=y
  CONFIG_SECURITY=y
  CONFIG_CRYPTO_ECHAINIV=y
  CONFIG_CRYPTO_ANSI_CPRNG=y




From kirill at shutemov.name  Fri Feb 12 07:41:16 2016
From: kirill at shutemov.name (Kirill A. Shutemov)
Date: Fri, 12 Feb 2016 17:41:16 +0200
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160211205702.24f0d17a@thinkpad>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
Message-ID: <20160212154116.GA15142@node.shutemov.name>

On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> On Thu, 11 Feb 2016 21:09:42 +0200
> "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> 
> > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > > Hi,
> > > 
> > > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> > > he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
> > > review of the THP rework patches, which cannot be bisected, revealed
> > > commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
> > > (and also similar commits for other archs).
> > > 
> > > This commit removes the THP splitting bit and also the architecture
> > > implementation of pmdp_splitting_flush(), which took care of the IPI for
> > > fast_gup serialization. The commit message says
> > > 
> > >     pmdp_splitting_flush() is not needed too: on splitting PMD we will do
> > >     pmdp_clear_flush() + set_pte_at().  pmdp_clear_flush() will do IPI as
> > >     needed for fast_gup
> > > 
> > > The assumption that a TLB flush will also produce an IPI is wrong on s390,
> > > and maybe also on other architectures, and I thought that this was actually
> > > the main reason for having an arch-specific pmdp_splitting_flush().
> > > 
> > > At least PowerPC and ARM also had an individual implementation of
> > > pmdp_splitting_flush() that used kick_all_cpus_sync() instead of a TLB
> > > flush to send the IPI, and those were also removed. Putting the arch
> > > maintainers and mailing lists on cc to verify.
> > > 
> > > On s390 this will break the IPI serialization against fast_gup, which
> > > would certainly explain the random kernel crashes, please revert or fix
> > > the pmdp_splitting_flush() removal.
> > 
> > Sorry for that.
> > 
> > I believe, the problem was already addressed for PowerPC:
> > 
> > http://lkml.kernel.org/g/454980831-16631-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com
> > 
> > I think kick_all_cpus_sync() in arch-specific pmdp_invalidate() would do
> > the trick, right?
> 
> Hmm, not sure about that. After pmdp_invalidate(), a pmd_none() check in
> fast_gup will still return false, because the pmd is not empty (at least
> on s390). So I don't see spontaneously how it will help fast_gup to break
> out to the slow path in case of THP splitting.

What pmdp_flush_direct() does in pmdp_invalidate()? It's hard to unwrap for me :-/
Does it make the pmd !pmd_present()?

I'm also confused by pmd_none() is equal to !pmd_present() on s390. Hm?

-- 
 Kirill A. Shutemov


From jeremy.linton at arm.com  Fri Feb 12 07:47:52 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Fri, 12 Feb 2016 09:47:52 -0600
Subject: [PATCH] arm/arm64/crypto: assure that ECB modes don't require an IV
Message-ID: <1455292072-5236-1-git-send-email-jeremy.linton@arm.com>

ECB modes don't use an initialization vector. The kernel
/proc/crypto interface doesn't reflect this properly.

Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
---
 arch/arm/crypto/aes-ce-glue.c | 4 ++--
 arch/arm64/crypto/aes-glue.c  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/crypto/aes-ce-glue.c b/arch/arm/crypto/aes-ce-glue.c
index b445a5d..89a3a3e 100644
--- a/arch/arm/crypto/aes-ce-glue.c
+++ b/arch/arm/crypto/aes-ce-glue.c
@@ -364,7 +364,7 @@ static struct crypto_alg aes_algs[] = { {
 	.cra_blkcipher = {
 		.min_keysize	= AES_MIN_KEY_SIZE,
 		.max_keysize	= AES_MAX_KEY_SIZE,
-		.ivsize		= AES_BLOCK_SIZE,
+		.ivsize		= 0,
 		.setkey		= ce_aes_setkey,
 		.encrypt	= ecb_encrypt,
 		.decrypt	= ecb_decrypt,
@@ -441,7 +441,7 @@ static struct crypto_alg aes_algs[] = { {
 	.cra_ablkcipher = {
 		.min_keysize	= AES_MIN_KEY_SIZE,
 		.max_keysize	= AES_MAX_KEY_SIZE,
-		.ivsize		= AES_BLOCK_SIZE,
+		.ivsize		= 0,
 		.setkey		= ablk_set_key,
 		.encrypt	= ablk_encrypt,
 		.decrypt	= ablk_decrypt,
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index 05d9e16..7a3d22a 100644
--- a/arch/arm64/crypto/aes-glue.c
+++ b/arch/arm64/crypto/aes-glue.c
@@ -294,7 +294,7 @@ static struct crypto_alg aes_algs[] = { {
 	.cra_blkcipher = {
 		.min_keysize	= AES_MIN_KEY_SIZE,
 		.max_keysize	= AES_MAX_KEY_SIZE,
-		.ivsize		= AES_BLOCK_SIZE,
+		.ivsize		= 0,
 		.setkey		= aes_setkey,
 		.encrypt	= ecb_encrypt,
 		.decrypt	= ecb_decrypt,
@@ -371,7 +371,7 @@ static struct crypto_alg aes_algs[] = { {
 	.cra_ablkcipher = {
 		.min_keysize	= AES_MIN_KEY_SIZE,
 		.max_keysize	= AES_MAX_KEY_SIZE,
-		.ivsize		= AES_BLOCK_SIZE,
+		.ivsize		= 0,
 		.setkey		= ablk_set_key,
 		.encrypt	= ablk_encrypt,
 		.decrypt	= ablk_decrypt,
-- 
2.4.3



From dirk.behme at gmail.com  Fri Feb 12 07:51:00 2016
From: dirk.behme at gmail.com (Dirk Behme)
Date: Fri, 12 Feb 2016 16:51:00 +0100
Subject: [PATCH] ARM: imx: Do L2 errata only if the L2 cache isn't enabled
In-Reply-To: <20160212141654.GA10826@n2100.arm.linux.org.uk>
References: <1455261093-11849-1-git-send-email-dirk.behme@de.bosch.com>
 <20160212141654.GA10826@n2100.arm.linux.org.uk>
Message-ID: <56BDFF64.9090701@gmail.com>

On 12.02.2016 15:16, Russell King - ARM Linux wrote:
> On Fri, Feb 12, 2016 at 08:11:33AM +0100, Dirk Behme wrote:
>> All the generic L2 cache handling code is encapsulated by a
>> check if the L2 cache is enabled. If it's enabled already, the code
>> is skipped.
>>
>> For the i.MX6 specific L2 cache handling we missed this check.
>> Add it.
>
> What's the reasoning behind this?  The prefetch register is writable
> while the L2 cache is enabled, unlike the auxiliary control register.

 From an internal log I have the following info:

The write to the L2-Cache controller from non-secure world causes an 
imprecise
external abort. If Linux runs from normal world the cache controller 
is already
enabled and thus no configuration is needed by Linux.

Best regards

Dirk



From will.deacon at arm.com  Fri Feb 12 07:52:22 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 12 Feb 2016 15:52:22 +0000
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <alpine.LFD.2.20.1602121106140.1773@schleppi>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad> <20160212100137.GE25087@arm.com>
 <alpine.LFD.2.20.1602121106140.1773@schleppi>
Message-ID: <20160212155221.GP25087@arm.com>

On Fri, Feb 12, 2016 at 11:12:34AM +0100, Sebastian Ott wrote:
> On Fri, 12 Feb 2016, Will Deacon wrote:
> > On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> > > On Thu, 11 Feb 2016 21:09:42 +0200
> > > "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> > > > On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > > > > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> > > > > he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
> > > > > review of the THP rework patches, which cannot be bisected, revealed
> > > > > commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
> > > > > (and also similar commits for other archs).

[...]

> > Do you have a reliable way to trigger the "random kernel crashes"? We've not
> > seen anything reported on arm64, but I don't see why we wouldn't be affected
> > by the same bug and it would be good to confirm and validate a fix.
> 
> My testcase was compiling the kernel. Most of the time my test system
> didn't survive a single compile run. During bisect I did at least 20
> compile runs to flag a commit as good.

I've been building kernels all day with -rc3 on my arm64 box and haven't
seen any problems yet.. :/.

I'll leave it going over the weekend.

Will


From will.deacon at arm.com  Fri Feb 12 07:55:18 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 12 Feb 2016 15:55:18 +0000
Subject: [PATCH 4/3] iommu/io-pgtable: Rationalise quirk handling
In-Reply-To: <56BDF8D8.4010200@arm.com>
References: <cover.1453723096.git.robin.murphy@arm.com>
 <ea1f3d3feec0dc9c18d43393678370b50b1275f5.1455206840.git.robin.murphy@arm.com>
 <20160212120857.GN25087@arm.com> <4282853.vdxKI5JT5z@avalon>
 <56BDF8D8.4010200@arm.com>
Message-ID: <20160212155517.GQ25087@arm.com>

On Fri, Feb 12, 2016 at 03:23:04PM +0000, Robin Murphy wrote:
> On 12/02/16 12:32, Laurent Pinchart wrote:
> >On Friday 12 February 2016 12:08:58 Will Deacon wrote:
> >>On Thu, Feb 11, 2016 at 04:13:45PM +0000, Robin Murphy wrote:
> >>>@@ -173,10 +187,12 @@ static inline void io_pgtable_tlb_sync(struct
> >>>io_pgtable *iop)
> >>>   *
> >>>   * @alloc: Allocate a set of page tables described by cfg.
> >>>   * @free:  Free the page tables associated with iop.
> >>>+ * @supported_quirks: Bitmap of quirks supported by the format.
> >>>   */
> >>>  struct io_pgtable_init_fns {
> >>>  	struct io_pgtable *(*alloc)(struct io_pgtable_cfg *cfg, void
> >*cookie);
> >>>  	void (*free)(struct io_pgtable *iop);
> >>>+	unsigned int supported_quirks;
> >>>  };
> >>
> >>My only gripe here is that this is supposed to be a struct of function
> >>pointers... get_supported_quirks() ?
> >
> >Can't we instead say it's a struct of function pointers and static data ? :-)
> >A function to retrieve the supported quirks will just contribute to kernel
> >bloat without adding any extra benefit.
> 
> Bleh - personally I think it's marginally more obvious and readable to have
> the information looking like data, but I'd much sooner just have a
> hard-coded "if (cfq->quirks & ..." check in every format's alloc function
> than introduce a whole new callback. Does that sound like a reasonable
> compromise?

Yeah, do that. You never know, there could be quirks that are only supported
based on other things in the cfg, so it's more extensible that way too.

Will


From alexander.shishkin at linux.intel.com  Fri Feb 12 07:54:41 2016
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Fri, 12 Feb 2016 17:54:41 +0200
Subject: [PATCH V2 3/6] stm class: provision for statically assigned
 masterIDs
In-Reply-To: <AM4PR08MB0785EAA2B628765D7EA3FDA086D50@AM4PR08MB0785.eurprd08.prod.outlook.com>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
 <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org>
 <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com>
 <CANLsYky2twQ98u241YyHD=atYRp1N56YVHUQNY2E2Ljsq0cseA@mail.gmail.com>
 <87twlj49k7.fsf@ashishki-desk.ger.corp.intel.com>
 <CANLsYkw=mG+ch8QzxmbwWs9o+mndVNo1MuqXcrPrNJYj_SQcHQ@mail.gmail.com>
 <AM4PR08MB0785EAA2B628765D7EA3FDA086D50@AM4PR08MB0785.eurprd08.prod.outlook.com>
Message-ID: <87twld3ovy.fsf@ashishki-desk.ger.corp.intel.com>

Al Grant <Al.Grant at arm.com> writes:

>> Mike did write "master IDs are hardwired to individual cores and core security
>> states", which make assignment for one platform very static.
>> On the flip side those will change from one system to another.
>
> It depends on your perspective.  From the perspective of a userspace
> process not pinned to a core, the master id will appear to vary
> dynamically and unpredictably as the thread migrates from one
> core to another.  (That's actually useful if the decoder wants to know
> where the thread is running at any given point, as it can find that out
> for free, without the need to track migration events.)
>
> On the other hand if you are pinned (e.g. you're the kernel on a
> particular core, or you're a per-core worker thread in some thread
> pooling system) then you have a fixed master id, and then you can
> have one instance per core all using the same range of channel
> numbers, with the master id indicating the core - this saves on
> channel space compared to having to give each core its own
> range of channel space.

What I understood from Mike's explanation is that basically nothing is
fixed from the software perspective (talking about Coresight STM). One
doesn't know the master id with which one's data will be tagged,
regardless of whether one is cpu-affine or not, because:

 * even per-core master IDs will be highly implementation dependent and
   therefore not knowable by the kernel and subsequently userspace,
 * master IDs may change based on other conditions (besides security
   states), so even if we knew per-core master IDs for sure, it wouldn't
   give us the complete picture.

So even though from the HW perspective master IDs may be "hardwired" to
hardware states, the hardware states themselves are dynamic, so from the
SW perspective these master IDs are not static or hardwired at all.

If the same mmio write done by software would always result in the exact
same master ID tagged to it, that would be more like "static" to me.

Regards,
--
Alex


From borntraeger at de.ibm.com  Fri Feb 12 07:57:27 2016
From: borntraeger at de.ibm.com (Christian Borntraeger)
Date: Fri, 12 Feb 2016 16:57:27 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160212154116.GA15142@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
Message-ID: <56BE00E7.1010303@de.ibm.com>

On 02/12/2016 04:41 PM, Kirill A. Shutemov wrote:
> On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
>> On Thu, 11 Feb 2016 21:09:42 +0200
>> "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
>>
>>> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
>>>> Hi,
>>>>
>>>> Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
>>>> he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
>>>> review of the THP rework patches, which cannot be bisected, revealed
>>>> commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
>>>> (and also similar commits for other archs).
>>>>
>>>> This commit removes the THP splitting bit and also the architecture
>>>> implementation of pmdp_splitting_flush(), which took care of the IPI for
>>>> fast_gup serialization. The commit message says
>>>>
>>>>     pmdp_splitting_flush() is not needed too: on splitting PMD we will do
>>>>     pmdp_clear_flush() + set_pte_at().  pmdp_clear_flush() will do IPI as
>>>>     needed for fast_gup
>>>>
>>>> The assumption that a TLB flush will also produce an IPI is wrong on s390,
>>>> and maybe also on other architectures, and I thought that this was actually
>>>> the main reason for having an arch-specific pmdp_splitting_flush().
>>>>
>>>> At least PowerPC and ARM also had an individual implementation of
>>>> pmdp_splitting_flush() that used kick_all_cpus_sync() instead of a TLB
>>>> flush to send the IPI, and those were also removed. Putting the arch
>>>> maintainers and mailing lists on cc to verify.
>>>>
>>>> On s390 this will break the IPI serialization against fast_gup, which
>>>> would certainly explain the random kernel crashes, please revert or fix
>>>> the pmdp_splitting_flush() removal.
>>>
>>> Sorry for that.
>>>
>>> I believe, the problem was already addressed for PowerPC:
>>>
>>> http://lkml.kernel.org/g/454980831-16631-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com
>>>
>>> I think kick_all_cpus_sync() in arch-specific pmdp_invalidate() would do
>>> the trick, right?
>>
>> Hmm, not sure about that. After pmdp_invalidate(), a pmd_none() check in
>> fast_gup will still return false, because the pmd is not empty (at least
>> on s390). So I don't see spontaneously how it will help fast_gup to break
>> out to the slow path in case of THP splitting.
> 
> What pmdp_flush_direct() does in pmdp_invalidate()? It's hard to unwrap for me :-/
> Does it make the pmd !pmd_present()?

It uses the idte instruction, which in an atomic fashion flushes the associated
TLB entry and changes the value of the pmd entry to invalid. This comes from the
HW requirement to not  change a PTE/PMD that might be still in use, other than 
with special instructions that does the tlb handling and the invalidation together.

(It also does some some other magic to the attach_count, which might hold off
finish_arch_post_lock_switch while some flushing is happening, but this should
be unrelated here)


> I'm also confused by pmd_none() is equal to !pmd_present() on s390. Hm?

Don't know, Gerald or Martin?



From robh at kernel.org  Fri Feb 12 07:59:02 2016
From: robh at kernel.org (Rob Herring)
Date: Fri, 12 Feb 2016 09:59:02 -0600
Subject: [PATCH 1/3] ARM: mvebu: Define binding for the nsa3xx-hwmon driver
In-Reply-To: <1455147224-6742-2-git-send-email-linux@baker-net.org.uk>
References: <1455147224-6742-1-git-send-email-linux@baker-net.org.uk>
 <1455147224-6742-2-git-send-email-linux@baker-net.org.uk>
Message-ID: <20160212155902.GA13402@rob-hp-laptop>

On Wed, Feb 10, 2016 at 11:33:42PM +0000, Adam Baker wrote:
> Define a binding for the hardware monitoring chip present in several
> variants of the Zyxel NSA3xx NAS devices.
> 
> Signed-off-by: Adam Baker <linux at baker-net.org.uk>
> ---
>  .../devicetree/bindings/hwmon/nsa320-mcu.txt        | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt

Acked-by: Rob Herring <robh at kernel.org>


From hdegoede at redhat.com  Fri Feb 12 07:59:45 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Fri, 12 Feb 2016 16:59:45 +0100
Subject: [linux-sunxi][PATCH v2] ARM: dts: sun4i: Enable USB DRC on the
 MK802
In-Reply-To: <1455278359-22451-1-git-send-email-codekipper@gmail.com>
References: <1455278359-22451-1-git-send-email-codekipper@gmail.com>
Message-ID: <56BE0171.9040305@redhat.com>

Hi,

On 12-02-16 12:59, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
>
> Enable the otg/drc usb controller on the MK802.
>
> Signed-off-by: Marcus Cooper <codekipper at gmail.com>
> ---
> Changes since v1:
> - Corrected name of the device in subject & description.

Looks good to me:

Reviewed-by: Hans de Goede <hdegoede at redhat.com>

Regards,

Hans


> ---
>   arch/arm/boot/dts/sun4i-a10-mk802.dts | 33 +++++++++++++++++++++++++++++++++
>   1 file changed, 33 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10-mk802.dts b/arch/arm/boot/dts/sun4i-a10-mk802.dts
> index ddf0683..ee46ea8 100644
> --- a/arch/arm/boot/dts/sun4i-a10-mk802.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-mk802.dts
> @@ -44,6 +44,7 @@
>   #include "sun4i-a10.dtsi"
>   #include "sunxi-common-regulators.dtsi"
>   #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>
>   / {
>   	model = "MK802";
> @@ -84,7 +85,25 @@
>   	status = "okay";
>   };
>
> +&otg_sram {
> +	status = "okay";
> +};
> +
>   &pio {
> +	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
> +		allwinner,pins = "PH4";
> +		allwinner,function = "gpio_in";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +	};
> +
> +	usb0_vbus_detect_pin: usb0_vbus_detect_pin at 0 {
> +		allwinner,pins = "PH5";
> +		allwinner,function = "gpio_in";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +	};
> +
>   	usb2_vbus_pin_mk802: usb2_vbus_pin at 0 {
>   		allwinner,pins = "PH12";
>   		allwinner,function = "gpio_out";
> @@ -93,6 +112,10 @@
>   	};
>   };
>
> +&reg_usb0_vbus {
> +	status = "okay";
> +};
> +
>   &reg_usb1_vbus {
>   	status = "okay";
>   };
> @@ -109,7 +132,17 @@
>   	status = "okay";
>   };
>
> +&usb_otg {
> +	dr_mode = "otg";
> +	status = "okay";
> +};
> +
>   &usbphy {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
> +	usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
> +	usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
> +	usb0_vbus-supply = <&reg_usb0_vbus>;
>   	usb1_vbus-supply = <&reg_usb1_vbus>;
>   	usb2_vbus-supply = <&reg_usb2_vbus>;
>   	status = "okay";
>


From matthias.bgg at gmail.com  Fri Feb 12 08:01:26 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Fri, 12 Feb 2016 17:01:26 +0100
Subject: mt1873-evb: MMC failing with linux-next
In-Reply-To: <56BDF937.60208@gmail.com>
References: <7hegcmadfk.fsf@baylibre.com> <56BDF937.60208@gmail.com>
Message-ID: <56BE01D6.40908@gmail.com>



On 12/02/16 16:24, Matthias Brugger wrote:
> Hi Kevin,
>
> On 09/02/16 02:18, Kevin Hilman wrote:
>> Hello,
>>
>> I tried getting MMC working with linux-next (next-20160208) on
>> mt8173-evb by enabling a few options[1] on top of the default defconfig,
>> and this results in a kernel that hangs as soon as it starts userspace.
>>
>> The MMC driver seems to start, though has some regulator issues:
>>
>> [    0.526380] sdhci: Secure Digital Host Controller Interface driver
>> [    0.527176] sdhci: Copyright(c) Pierre Ossman
>> [    0.528835] vio18: unsupportable voltage range: 3300000-1980000uV
>> [    0.529610] mtk-msdc 11230000.mmc: Regulator set error -22:
>> 3300000 - 3300000
>> [    0.563731] mtk-msdc 11240000.mmc: Got CD GPIO
>>
>> The driver appears to be attempting to set 3.3V but using a 1.8V
>> regulator (vio18), which is failing.
>>
>> Then, the kernel hangs after freeing unused memory:
>>
>> [    0.616386] hctosys: unable to open rtc device (rtc0)
>> [    0.624118] usb_vbus: disabling
>> [    0.624547] vusb: disabling
>> [    0.624929] vgp6: disabling
>> [    0.625635] ALSA device list:
>> [    0.626009]   No soundcards found.
>> [    0.626963] Freeing unused kernel memory: 724K (ffffffc000977000 -
>> ffffffc000a2c000)
>>
>> And nothing further here.
>>
>
> I can see the warning from the mmc regulator access, but after that my
> board boots just fine.
> I'm using linux-next as of today (20160212).
> I attached my config, it should be defconfig plus the config options you
> mentioned (and an initramfs).
>
> Is this the configuration you have?

I spotted an error in my scripts to build the kernel. After fixing this 
I can reproduce your error.

Regards,
Matthias

>
> Regards,
> Matthias
>
>> It boots fine when disabling the MMC driver (CONFIG_MMC_MTK=n).
>>
>> Any ideas?
>>
>> Kevin
>>
>> [1]
>> CONFIG_MMC_MTK=y
>> CONFIG_MFD_MT6397=y
>> CONFIG_REGULATOR_MT6397=y
>> CONFIG_MTK_PMIC_WRAP=y
>>


From vishnupatekar0510 at gmail.com  Fri Feb 12 08:06:00 2016
From: vishnupatekar0510 at gmail.com (Vishnu Patekar)
Date: Sat, 13 Feb 2016 00:06:00 +0800
Subject: [PATCH 10/14] ARM: dts: sun8i-a83t: Add PRCM related clocks and
 resets
In-Reply-To: <CAGb2v67iO-816KaLttWRRPL2f7hpfgJ1--p69tD_oOrewmOjCA@mail.gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-11-git-send-email-vishnupatekar0510@gmail.com>
 <CAGb2v67iO-816KaLttWRRPL2f7hpfgJ1--p69tD_oOrewmOjCA@mail.gmail.com>
Message-ID: <CAEzqOZtsdHC2tCgjC=Bj5q3RFip2Uyni8bFC16u03PRLCra5KA@mail.gmail.com>

Hello Wens,


On Tue, Feb 2, 2016 at 2:44 PM, Chen-Yu Tsai <wens at csie.org> wrote:
> On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
> <vishnupatekar0510 at gmail.com> wrote:
>> This adds A83T PRCM related clocks, clock resets.
>>
>> As a83t apb0 gates clock support is added earlier, this enables it.
>> Apart from apb0 gates, other added clocks are compatible with
>> earlier sun8i socs.
>>
>> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
>> ---
>>  arch/arm/boot/dts/sun8i-a83t.dtsi | 44 +++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 44 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
>> index ac96aa1..5ea20ff 100644
>> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
>> @@ -268,6 +268,44 @@
>>                                              "mmc2_output",
>>                                              "mmc2_sample";
>>                 };
>> +
>> +               cpus_clk: clk at 01f01400 {
>> +                       compatible = "allwinner,sun9i-a80-cpus-clk";
>> +                       reg = <0x01f01400 0x4>;
>> +                       #clock-cells = <0>;
>> +                       clocks = <&osc16Md512>, <&osc24M>, <&pll6>, <&osc16M>;
>> +                       clock-output-names = "cpus";
>> +               };
>> +
>> +               ahb0: ahb0_clk {
>> +                       compatible = "fixed-factor-clock";
>> +                       #clock-cells = <0>;
>> +                       clock-div = <1>;
>> +                       clock-mult = <1>;
>> +                       clocks = <&cpus_clk>;
>> +                       clock-output-names = "ahb0";
>> +               };
>> +
>> +               apb0: clk at 01f0140c {
>> +                       compatible = "allwinner,sun8i-a23-apb0-clk";
>
> This is actually wrong, as it is wrong in sun9i-a80.dtsi.
> I've sent a patch series for it.
A83T apb0 is different from A80, and it's same as A23, so this should
be correct.
Please correct me in case I'm missing something.

> Also the drivers for "allwinner,sun9i-a80-cpus-clk" and
> "allwinner,sun9i-a80-apbs-clk"
> are only compiled for CONFIG_MACH_SUN9I. Please add a patch to address this.
Okie.
>
> Regards
> ChenYu
>
>> +                       reg = <0x01f0140c 0x4>;
>> +                       #clock-cells = <0>;
>> +                       clocks = <&ahb0>;
>> +                       clock-output-names = "apb0";
>> +               };
>> +
>> +               apb0_gates: clk at 01f01428 {
>> +                       compatible = "allwinner,sun8i-a83t-apb0-gates-clk";
>> +                       reg = <0x01f01428 0x4>;
>> +                       #clock-cells = <1>;
>> +                       clocks = <&apb0>;
>> +                       clock-indices = <0>, <1>,
>> +                                       <2>, <3>,
>> +                                       <4>, <6>, <7>;
>> +                       clock-output-names = "apb0_pio", "apb0_ir",
>> +                                       "apb0_timer", "apb0_rsb",
>> +                                       "apb0_uart", "apb0_i2c0", "apb0_twd";
>> +               };
>>         };
>>
>>         soc {
>> @@ -434,5 +472,11 @@
>>                         #interrupt-cells = <3>;
>>                         interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
>>                 };
>> +
>> +               apb0_reset: reset at 01f014b0 {
>> +                       reg = <0x01f014b0 0x4>;
>> +                       compatible = "allwinner,sun6i-a31-clock-reset";
>> +                       #reset-cells = <1>;
>> +               };
>>         };
>>  };
>> --
>> 1.9.1
>>


From arnd at arndb.de  Fri Feb 12 08:06:17 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 17:06:17 +0100
Subject: [PATCH 0/5] gcov fixes and maybe-uninitialized warnings
Message-ID: <1455293187-179811-1-git-send-email-arnd@arndb.de>

This series tries to address two related problems:

* getting better "variable may be used uninitialized" warnings
  in allmodconfig and randconfig builds

* improving GCOV_PROFILE support

Surprisingly, these two are related, so I have a single series that
I hope to get merged through the Kbuild tree.

I have built many thousands of ARM randconfig kernels and created
patches for every single warning and error I found, and submitted
most of them for inclusion. The "may be used uninitialized" warnings
are both the most annoying and the most helpful ones that gcc
gives us, so this tries to make them more useful, including three
steps:

1. Limit the false positives as much as we can: Aside from
   CC_OPTIMIZE_FOR_SIZE, three other options (UBSAN_SANITIZE_ALL,
   PROFILE_ALL_BRANCHES and GCOV_PROFILE_ALL) confuse the
   compiler (in versions 4.9 through 5.3, and to a lesser degree
   on older versions) so we get a lot of extra warnings. We
   already disable the warnings for CC_OPTIMIZE_FOR_SIZE, and
   this series also disables them for the other two, which are
   rarely used in practice but do show up in randconfig builds
   all the time.
2. Ensure we actually see them on 'allmodconfig' builds: Today they
   are disabled, because CC_OPTIMIZE_FOR_SIZE disables them.
   UBSAN_SANITIZE_ALL and PROFILE_ALL_BRANCHES are defined in
   a way that they don't get turned on for allmodconfig, and
   we need to do the samem for GCOV_PROFILE_ALL and
   CC_OPTIMIZE_FOR_SIZE.
3. Fix all known such warnings: The warnings should stick out,
   so we can fix them once they first appear. Today they often
   get ignored because of all the false positives.

For GCOV support, another problem showed up, resulting in an increased
risk for kernel stack overflow, aside from getting a number of
warnings about the stack size. I'm also including a patch to
address that here.

	Arnd

Arnd Bergmann (5):
  Kbuild: change CC_OPTIMIZE_FOR_SIZE definition
  Kbuild: disable 'maybe-uninitialized' warning for
    CONFIG_PROFILE_ALL_BRANCHES
  gcov: disable for COMPILE_TEST
  gcov: disable tree-loop-im to reduce stack usage
  gcov: disable -Wmaybe-uninitialized warning

 Makefile            |  8 ++++++--
 init/Kconfig        | 13 +++++++++++++
 kernel/gcov/Kconfig |  1 +
 3 files changed, 20 insertions(+), 2 deletions(-)

-- 
2.7.0



From catalin.marinas at arm.com  Fri Feb 12 08:06:53 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 12 Feb 2016 16:06:53 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <56BDFC86.5010705@arm.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
Message-ID: <20160212160652.GL31665@e104818-lin.cambridge.arm.com>

On Fri, Feb 12, 2016 at 03:38:46PM +0000, Sudeep Holla wrote:
> 
> On 12/02/16 15:26, Catalin Marinas wrote:
> >On Fri, Feb 12, 2016 at 04:17:09PM +0100, Ard Biesheuvel wrote:
> >>On 12 February 2016 at 16:10, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >>>On Fri, Feb 12, 2016 at 04:02:58PM +0100, Ard Biesheuvel wrote:
> >>>>On 12 February 2016 at 15:58, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >>>>>On Mon, Feb 01, 2016 at 11:54:52AM +0100, Ard Biesheuvel wrote:
> >>>>>>This moves the module area to right before the vmalloc area, and
> >>>>>>moves the kernel image to the base of the vmalloc area. This is
> >>>>>>an intermediate step towards implementing KASLR, which allows the
> >>>>>>kernel image to be located anywhere in the vmalloc area.
> >>>>>>
> >>>>>>Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >>>>>
> >>>>>This patch is causing lots of KASAN warnings on Juno (interestingly, it
> >>>>>doesn't seem to trigger on Seattle, though we only tried for-next/core).
> >>>>>I pushed the branch that I'm currently using here:
> >>>>>
> >>>>>git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux for-next/kernmap
> >>>>>
> >>>>>
> >>>>>A typical error (though its place varies based on the config options,
> >>>>>kernel layout):
> >>>>>
> >>>>>BUG: KASAN: stack-out-of-bounds in clockevents_program_event+0x28/0x1b0 at addr ffffffc936257cc8
> >>>>
> >>>>Can you confirm that these are stack accesses? I was having similar
> >>>>errors before, and I ended up creating the kasan zero page patch
> >>>>because it turned out the kasan shadow page in question was aliased
> >>>>and the stack writes were occurring elsewhere.
> >>>
> >>>It's possible, we are looking into this. Is there any other patch I miss on
> >>>the above branch?
> >>
> >>I don't think so but I will check
> >
> >Commit 7b1af9795773 ("arm64: kasan: ensure that the KASAN zero page is
> >mapped read-only") was merged in -rc2 while the branch above is based on
> >-rc1. Anyway, I merged it into -rc2 and the errors are similar.
> >
> 
> Sorry to add more confusion, but I observed similar KASAN warning
> with latest mainline(v4.5-rc3+, commit c05235d50f68) with below diff.

I can reproduce this with UBSAN enabled (log below for the record).

So far, we have:

KASAN+for-next/kernmap goes wrong
KASAN+UBSAN goes wrong

Enabled individually, KASAN, UBSAN and for-next/kernmap seem fine. I may
have to trim for-next/core down until we figure out where the problem
is.


BUG: KASAN: stack-out-of-bounds in find_busiest_group+0x164/0x16a0 at addr ffffffc93665bc8c
Read of size 4 by task swapper/3/0
page:ffffffbde6d996c0 count:0 mapcount:0 mapping:          (null) index:0x0
flags: 0x4000000000000000()
page dumped because: kasan: bad access detected
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.5.0-rc3+ #134
Hardware name: Juno (DT)
Call trace:
[<ffffffc00008f8f0>] dump_backtrace+0x0/0x358
[<ffffffc00008fc5c>] show_stack+0x14/0x20
[<ffffffc00069d0a8>] dump_stack+0x108/0x150
[<ffffffc0003077f8>] kasan_report_error+0x690/0x970
[<ffffffc0003082c0>] kasan_report+0x60/0xc0
[<ffffffc00030634c>] __asan_load4+0x64/0x80
[<ffffffc00015f714>] find_busiest_group+0x164/0x16a0
[<ffffffc000160ea0>] load_balance+0x250/0x1450
[<ffffffc0001630c0>] pick_next_task_fair+0x5d0/0xb40
[<ffffffc000f08090>] __schedule+0x460/0xbc8
[<ffffffc000f08870>] schedule+0x78/0x208
[<ffffffc000f092d4>] schedule_preempt_disabled+0x3c/0xd8
[<ffffffc000172208>] cpu_startup_entry+0x160/0x4c8
[<ffffffc0000985b8>] secondary_start_kernel+0x280/0x428
[<0000000080082e2c>] 0x80082e2c
Memory state around the buggy address:
 ffffffc93665bb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffffc93665bc00: f1 f1 f1 f1 00 f4 f4 f4 f2 f2 f2 f2 00 00 f1 f1
>ffffffc93665bc80: f1 f1 00 00 00 00 f3 f3 00 f4 f4 f4 f3 f3 f3 f3
                      ^
 ffffffc93665bd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffffc93665bd80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4

-- 
Catalin


From jeremy.linton at arm.com  Fri Feb 12 08:06:46 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Fri, 12 Feb 2016 10:06:46 -0600
Subject: [PATCH 0/2] flag contiguous PTEs in linear mapping
Message-ID: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>

This is a rebase of the previous contiguous ptes in linear map patches
on top of Mark Rutland's fixmap changes. Those changes appear to be sufficient
to allow this patch set to boot on JunoR2, seattle and the xgene/m400. I've
also done basic testing with RODATA turned on. In all cases with ACPI systems.

This patch also adds the ability to align 64k kernels on the 2M CONT boundary
which helps to assure that a number of the sections are completely mapped with
CONT bits. There remain a number of holes due to smaller remapping operations
that don't really affect the page protection states. That can be worked around
in a number of cases if the code gets smart enough to detect that the break
doesn't result in an actual change in permissions. Some of these are visible
in the included example where its not initially obvious why a contigious 2M
region isn't marked as such until digging into it.

With 64k pages, and section alignment enabled the kernel looks like:
---[ Kernel Mapping ]---
0xfffffe0000000000-0xfffffe0000200000           2M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0000200000-0xfffffe0001200000          16M     ro x  SHD AF    CON     UXN MEM/NORMAL
0xfffffe0001200000-0xfffffe0001400000           2M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0001400000-0xfffffe0001600000           2M     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe0001600000-0xfffffe0002600000          16M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0002600000-0xfffffe0002800000           2M     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe0002800000-0xfffffe0020000000         472M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0020000000-0xfffffe0060000000           1G     RW NX SHD AF        BLK UXN MEM/NORMAL
0xfffffe00600f0000-0xfffffe0060200000        1088K     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe0060200000-0xfffffe0076400000         354M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0076400000-0xfffffe0076600000           2M     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe0076600000-0xfffffe0078e00000          40M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe00793b0000-0xfffffe0079400000         320K     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe0079400000-0xfffffe007e200000          78M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe007e200000-0xfffffe007e3d0000        1856K     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe007e420000-0xfffffe007e600000        1920K     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe007e600000-0xfffffe007f000000          10M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0800000000-0xfffffe0980000000           6G     RW NX SHD AF        BLK UXN MEM/NORMAL

With 4k pages
---[ Kernel Mapping ]---
0xffffffc000000000-0xffffffc000200000           2M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc000200000-0xffffffc001200000          16M     ro x  SHD AF        BLK UXN MEM/NORMAL
0xffffffc001200000-0xffffffc001400000           2M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc001400000-0xffffffc0015c0000        1792K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc0015c0000-0xffffffc0015d0000          64K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc0015d0000-0xffffffc001600000         192K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc001600000-0xffffffc002600000          16M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc002600000-0xffffffc002620000         128K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc002620000-0xffffffc002630000          64K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc002630000-0xffffffc002800000        1856K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc002800000-0xffffffc060000000        1496M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc0600f0000-0xffffffc060200000        1088K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc060200000-0xffffffc076400000         354M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc076400000-0xffffffc076590000        1600K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc076590000-0xffffffc076595000          20K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc076596000-0xffffffc0765a0000          40K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc0765a0000-0xffffffc076600000         384K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc076600000-0xffffffc078e00000          40M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc0793b0000-0xffffffc079400000         320K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc079400000-0xffffffc07e200000          78M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc07e200000-0xffffffc07e3d0000        1856K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc07e420000-0xffffffc07e600000        1920K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc07e600000-0xffffffc07f000000          10M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc800000000-0xffffffc980000000           6G     RW NX SHD AF        BLK UXN MEM/NORMAL

Jeremy Linton (2):
  arm64: mm: Enable CONT_SIZE aligned sections for 64k page kernels.
  arm64: Mark kernel page ranges contiguous

 arch/arm64/Kconfig.debug        | 12 ++++----
 arch/arm64/kernel/vmlinux.lds.S | 11 +++----
 arch/arm64/mm/mmu.c             | 64 +++++++++++++++++++++++++++++++++++++----
 3 files changed, 70 insertions(+), 17 deletions(-)

-- 
2.4.3



From arnd at arndb.de  Fri Feb 12 08:06:18 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 17:06:18 +0100
Subject: [PATCH 1/5] Kbuild: change CC_OPTIMIZE_FOR_SIZE definition
In-Reply-To: <1455293187-179811-1-git-send-email-arnd@arndb.de>
References: <1455293187-179811-1-git-send-email-arnd@arndb.de>
Message-ID: <1455293187-179811-2-git-send-email-arnd@arndb.de>

CC_OPTIMIZE_FOR_SIZE disables the often useful -Wmaybe-unused warning,
because that causes a ridiculous amount of false positives when combined
with -Os.

This means a lot of warnings don't show up in testing by the developers
that should see them with an 'allmodconfig' kernel that has
CC_OPTIMIZE_FOR_SIZE enabled, but only later in randconfig builds
that don't.

This changes the Kconfig logic around CC_OPTIMIZE_FOR_SIZE to make
it a 'choice' statement defaulting to CC_OPTIMIZE_FOR_PERFORMANCE
that gets added for this purpose. The allmodconfig and allyesconfig
kernels now default to -O2 with the maybe-unused warning enabled.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 init/Kconfig | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/init/Kconfig b/init/Kconfig
index 651ec15ecddb..159a542ef3fc 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1305,6 +1305,17 @@ source "usr/Kconfig"
 
 endif
 
+choice
+	prompt "Compiler optimization level"
+	default CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE
+
+config CC_OPTIMIZE_FOR_PERFORMANCE
+	bool "Optimize for performance"
+	help
+	  This is the default optimization level for the kernel, building
+	  with the "-O2" compiler flag for best performance and most
+	  helpful compile-time warnings.
+
 config CC_OPTIMIZE_FOR_SIZE
 	bool "Optimize for size"
 	help
@@ -1313,6 +1324,8 @@ config CC_OPTIMIZE_FOR_SIZE
 
 	  If unsure, say N.
 
+endchoice
+
 config SYSCTL
 	bool
 
-- 
2.7.0



From jeremy.linton at arm.com  Fri Feb 12 08:06:47 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Fri, 12 Feb 2016 10:06:47 -0600
Subject: [PATCH 1/2] arm64: mm: Enable CONT_SIZE aligned sections for 64k page
 kernels.
In-Reply-To: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
References: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
Message-ID: <1455293208-6763-2-git-send-email-jeremy.linton@arm.com>

This change allows ALIGN_RODATA for 16k and 64k kernels.
In the case of 64k kernels it actually aligns to the CONT_SIZE
rather than the SECTION_SIZE (which is 512M). This makes it generally
more useful, especially for CONT enabled kernels.

Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
---
 arch/arm64/Kconfig.debug        | 12 ++++++------
 arch/arm64/kernel/vmlinux.lds.S | 11 ++++++-----
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
index e13c4bf..65705ee 100644
--- a/arch/arm64/Kconfig.debug
+++ b/arch/arm64/Kconfig.debug
@@ -59,15 +59,15 @@ config DEBUG_RODATA
           If in doubt, say Y
 
 config DEBUG_ALIGN_RODATA
-	depends on DEBUG_RODATA && ARM64_4K_PAGES
+	depends on DEBUG_RODATA
 	bool "Align linker sections up to SECTION_SIZE"
 	help
 	  If this option is enabled, sections that may potentially be marked as
-	  read only or non-executable will be aligned up to the section size of
-	  the kernel. This prevents sections from being split into pages and
-	  avoids a potential TLB penalty. The downside is an increase in
-	  alignment and potentially wasted space. Turn on this option if
-	  performance is more important than memory pressure.
+	  read only or non-executable will be aligned up to the section size
+	  or contiguous hint size of the kernel. This prevents sections from
+	  being split into pages and avoids a potential TLB penalty. The downside
+	  is an increase in alignment and potentially wasted space. Turn on
+	  this option if performance is more important than memory pressure.
 
 	  If in doubt, say N
 
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index b78a3c7..ab4e436 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -63,13 +63,14 @@ PECOFF_FILE_ALIGNMENT = 0x200;
 #endif
 
 #if defined(CONFIG_DEBUG_ALIGN_RODATA)
-#define ALIGN_DEBUG_RO			. = ALIGN(1<<SECTION_SHIFT);
-#define ALIGN_DEBUG_RO_MIN(min)		ALIGN_DEBUG_RO
+#if defined(CONFIG_ARM64_64K_PAGES)
+#define ALIGN_DEBUG_RO_MIN(min)		. = ALIGN(CONT_SIZE);
+#else
+#define ALIGN_DEBUG_RO_MIN(min)		. = ALIGN(SECTION_SIZE);
+#endif
 #elif defined(CONFIG_DEBUG_RODATA)
-#define ALIGN_DEBUG_RO			. = ALIGN(1<<PAGE_SHIFT);
-#define ALIGN_DEBUG_RO_MIN(min)		ALIGN_DEBUG_RO
+#define ALIGN_DEBUG_RO_MIN(min)		. = ALIGN(PAGE_SIZE);
 #else
-#define ALIGN_DEBUG_RO
 #define ALIGN_DEBUG_RO_MIN(min)		. = ALIGN(min);
 #endif
 
-- 
2.4.3



From jeremy.linton at arm.com  Fri Feb 12 08:06:48 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Fri, 12 Feb 2016 10:06:48 -0600
Subject: [PATCH 2/2] arm64: Mark kernel page ranges contiguous
In-Reply-To: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
References: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
Message-ID: <1455293208-6763-3-git-send-email-jeremy.linton@arm.com>

With 64k pages, the next larger segment size is 512M. The linux
kernel also uses different protection flags to cover its code and data.
Because of this requirement, the vast majority of the kernel code and
data structures end up being mapped with 64k pages instead of the larger
pages common with a 4k page kernel.

Recent ARM processors support a contiguous bit in the
page tables which allows the a TLB to cover a range larger than a
single PTE if that range is mapped into physically contiguous
ram.

So, for the kernel its a good idea to set this flag. Some basic
micro benchmarks show it can significantly reduce the number of
L1 dTLB refills.

Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
---
 arch/arm64/mm/mmu.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 58 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 7711554..ab69a99 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1,3 +1,4 @@
+
 /*
  * Based on arch/arm/mm/mmu.c
  *
@@ -103,17 +104,49 @@ static void split_pmd(pmd_t *pmd, pte_t *pte)
 		 * Need to have the least restrictive permissions available
 		 * permissions will be fixed up later
 		 */
-		set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC));
+		set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC_CONT));
 		pfn++;
 	} while (pte++, i++, i < PTRS_PER_PTE);
 }
 
+static void clear_cont_pte_range(pte_t *pte, unsigned long addr)
+{
+	int i;
+
+	pte -= CONT_RANGE_OFFSET(addr);
+	for (i = 0; i < CONT_PTES; i++) {
+		if (pte_cont(*pte))
+			set_pte(pte, pte_mknoncont(*pte));
+		pte++;
+	}
+	flush_tlb_all();
+}
+
+/*
+ * Given a range of PTEs set the pfn and provided page protection flags
+ */
+static void __populate_init_pte(pte_t *pte, unsigned long addr,
+			       unsigned long end, phys_addr_t phys,
+			       pgprot_t prot)
+{
+	unsigned long pfn = __phys_to_pfn(phys);
+
+	do {
+		/* clear all the bits except the pfn, then apply the prot */
+		set_pte(pte, pfn_pte(pfn, prot));
+		pte++;
+		pfn++;
+		addr += PAGE_SIZE;
+	} while (addr != end);
+}
+
 static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
-				  unsigned long end, unsigned long pfn,
+				  unsigned long end, phys_addr_t phys,
 				  pgprot_t prot,
 				  phys_addr_t (*pgtable_alloc)(void))
 {
 	pte_t *pte;
+	unsigned long next;
 
 	if (pmd_none(*pmd) || pmd_sect(*pmd)) {
 		phys_addr_t pte_phys = pgtable_alloc();
@@ -127,10 +160,29 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
 	BUG_ON(pmd_bad(*pmd));
 
 	pte = pte_set_fixmap_offset(pmd, addr);
+
 	do {
-		set_pte(pte, pfn_pte(pfn, prot));
-		pfn++;
-	} while (pte++, addr += PAGE_SIZE, addr != end);
+		next = min(end, (addr + CONT_SIZE) & CONT_MASK);
+		if (((addr | next | phys) & ~CONT_MASK) == 0) {
+			/* a block of CONT_PTES	 */
+			__populate_init_pte(pte, addr, next, phys,
+					    prot | __pgprot(PTE_CONT));
+		} else {
+			/*
+			 * If the range being split is already inside of a
+			 * contiguous range but this PTE isn't going to be
+			 * contiguous, then we want to unmark the adjacent
+			 * ranges, then update the portion of the range we
+			 * are interrested in.
+			 */
+			clear_cont_pte_range(pte, addr);
+			__populate_init_pte(pte, addr, next, phys, prot);
+		}
+
+		pte += (next - addr) >> PAGE_SHIFT;
+		phys += next - addr;
+		addr = next;
+	} while (addr != end);
 
 	pte_clear_fixmap();
 }
@@ -194,7 +246,7 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
 				}
 			}
 		} else {
-			alloc_init_pte(pmd, addr, next, __phys_to_pfn(phys),
+			alloc_init_pte(pmd, addr, next, phys,
 				       prot, pgtable_alloc);
 		}
 		phys += next - addr;
-- 
2.4.3



From arnd at arndb.de  Fri Feb 12 08:06:19 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 17:06:19 +0100
Subject: [PATCH 2/5] Kbuild: disable 'maybe-uninitialized' warning for
 CONFIG_PROFILE_ALL_BRANCHES
In-Reply-To: <1455293187-179811-1-git-send-email-arnd@arndb.de>
References: <1455293187-179811-1-git-send-email-arnd@arndb.de>
Message-ID: <1455293187-179811-3-git-send-email-arnd@arndb.de>

CONFIG_PROFILE_ALL_BRANCHES confuses gcc-5.x to the degree that it prints
incorrect warnings about a lot of variables that it thinks can be used
uninitialized, e.g.:

i2c/busses/i2c-diolan-u2c.c: In function 'diolan_usb_xfer':
i2c/busses/i2c-diolan-u2c.c:391:16: warning: 'byte' may be used uninitialized in this function
iio/gyro/itg3200_core.c: In function 'itg3200_probe':
iio/gyro/itg3200_core.c:213:6: warning: 'val' may be used uninitialized in this function
leds/leds-lp55xx-common.c: In function 'lp55xx_update_bits':
leds/leds-lp55xx-common.c:350:6: warning: 'tmp' may be used uninitialized in this function
misc/bmp085.c: In function 'show_pressure':
misc/bmp085.c:363:10: warning: 'pressure' may be used uninitialized in this function
power/ds2782_battery.c: In function 'ds2786_get_capacity':
power/ds2782_battery.c:214:17: warning: 'raw' may be used uninitialized in this function

These are all false positives that either rob someone's time when trying
to figure out whether they are real, or they get people to send wrong
patches to shut up the warnings.

Nobody normally wants to run a CONFIG_PROFILE_ALL_BRANCHES kernel in
production, so disabling the whole class of warnings for this configuration
has no serious downsides either.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 Makefile | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 9092c16fa6cf..352f55ccc54e 100644
--- a/Makefile
+++ b/Makefile
@@ -617,7 +617,11 @@ KBUILD_CFLAGS	+= $(call cc-option,-fno-delete-null-pointer-checks,)
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
 KBUILD_CFLAGS	+= -Os $(call cc-disable-warning,maybe-uninitialized,)
 else
-KBUILD_CFLAGS	+= -O2
+ifdef CONFIG_PROFILE_ALL_BRANCHES
+KBUILD_CFLAGS	+= -O2 $(call cc-disable-warning,maybe-uninitialized,)
+else
+KBUILD_CFLAGS   += -O2
+endif
 endif
 
 # Tell gcc to never replace conditional load with a non-conditional one
-- 
2.7.0



From arnd at arndb.de  Fri Feb 12 08:06:20 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 17:06:20 +0100
Subject: [PATCH 3/5] gcov: disable for COMPILE_TEST
In-Reply-To: <1455293187-179811-1-git-send-email-arnd@arndb.de>
References: <1455293187-179811-1-git-send-email-arnd@arndb.de>
Message-ID: <1455293187-179811-4-git-send-email-arnd@arndb.de>

Enabling gcov is counterproductive to compile testing: it significantly
increases the kernel image size, compile time, and it produces lots
of false positive "may be used uninitialized" warnings as the result
of missed optimizations.

This is in line with how UBSAN_SANITIZE_ALL and PROFILE_ALL_BRANCHES
work, both of which have similar problems.

With an ARM allmodconfig kernel, I see the build time drop from
283 minutes CPU time to 225 minutes, and the vmlinux size drops
from 43MB to 26MB.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 kernel/gcov/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/gcov/Kconfig b/kernel/gcov/Kconfig
index c92e44855ddd..1276aabaab55 100644
--- a/kernel/gcov/Kconfig
+++ b/kernel/gcov/Kconfig
@@ -37,6 +37,7 @@ config ARCH_HAS_GCOV_PROFILE_ALL
 
 config GCOV_PROFILE_ALL
 	bool "Profile entire Kernel"
+	depends on !COMPILE_TEST
 	depends on GCOV_KERNEL
 	depends on ARCH_HAS_GCOV_PROFILE_ALL
 	default n
-- 
2.7.0



From arnd at arndb.de  Fri Feb 12 08:06:22 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 17:06:22 +0100
Subject: [PATCH 5/5] gcov: disable -Wmaybe-uninitialized warning
In-Reply-To: <1455293187-179811-1-git-send-email-arnd@arndb.de>
References: <1455293187-179811-1-git-send-email-arnd@arndb.de>
Message-ID: <1455293187-179811-6-git-send-email-arnd@arndb.de>

When gcov profiling is enabled, we see a lot of spurious warnings about
possibly uninitialized variables being used:

arch/arm/mm/dma-mapping.c: In function 'arm_coherent_iommu_map_page':
arch/arm/mm/dma-mapping.c:1085:16: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/clk/st/clk-flexgen.c: In function 'st_of_flexgen_setup':
drivers/clk/st/clk-flexgen.c:323:9: warning: 'num_parents' may be used uninitialized in this function [-Wmaybe-uninitialized]
kernel/cgroup.c: In function 'cgroup_mount':
kernel/cgroup.c:2119:11: warning: 'root' may be used uninitialized in this function [-Wmaybe-uninitialized]

All of these are false positives, so it seems better to just disable
the warnings whenever GCOV is enabled. Most users don't enable GCOV,
and based on a prior patch, it is now also disabled for 'allmodconfig'
builds, so there should be no downsides of doing this.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 6bb89728a9d1..7b6900931a47 100644
--- a/Makefile
+++ b/Makefile
@@ -364,7 +364,7 @@ AFLAGS_MODULE   =
 LDFLAGS_MODULE  =
 CFLAGS_KERNEL	=
 AFLAGS_KERNEL	=
-CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage -fno-tree-loop-im
+CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage -fno-tree-loop-im -Wno-maybe-uninitialized
 CFLAGS_KCOV	= -fsanitize-coverage=trace-pc
 
 
-- 
2.7.0



From arnd at arndb.de  Fri Feb 12 08:06:21 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 17:06:21 +0100
Subject: [PATCH 4/5] gcov: disable tree-loop-im to reduce stack usage
In-Reply-To: <1455293187-179811-1-git-send-email-arnd@arndb.de>
References: <1455293187-179811-1-git-send-email-arnd@arndb.de>
Message-ID: <1455293187-179811-5-git-send-email-arnd@arndb.de>

Enabling CONFIG_GCOV_PROFILE_ALL produces us a lot of warnings like

lib/lz4/lz4hc_compress.c: In function 'lz4_compresshcctx':
lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1504 bytes is larger than 1024 bytes [-Wframe-larger-than=]

After some investigation, I found that this behavior started with gcc-4.9,
and opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702.
A suggested workaround for it is to use the -fno-tree-loop-im
flag that turns off one of the optimization stages in gcc, so the
code runs a little slower but does not use excessive amounts
of stack.

We could make this conditional on the gcc version, but I could not
find an easy way to do this in Kbuild and the benefit would be
fairly small, given that most of the gcc version in production are
affected now.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 352f55ccc54e..6bb89728a9d1 100644
--- a/Makefile
+++ b/Makefile
@@ -364,7 +364,7 @@ AFLAGS_MODULE   =
 LDFLAGS_MODULE  =
 CFLAGS_KERNEL	=
 AFLAGS_KERNEL	=
-CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage
+CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage -fno-tree-loop-im
 CFLAGS_KCOV	= -fsanitize-coverage=trace-pc
 
 
-- 
2.7.0



From ard.biesheuvel at linaro.org  Fri Feb 12 08:11:50 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 17:11:50 +0100
Subject: [PATCH 1/2] arm64: mm: Enable CONT_SIZE aligned sections for 64k
 page kernels.
In-Reply-To: <1455293208-6763-2-git-send-email-jeremy.linton@arm.com>
References: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
 <1455293208-6763-2-git-send-email-jeremy.linton@arm.com>
Message-ID: <CAKv+Gu_ViEAVN1GEDMWpJ5OYjg6BVSLTEtdus6vCCXchQ1BOjw@mail.gmail.com>

Hi Jeremy,

Question below:

On 12 February 2016 at 17:06, Jeremy Linton <jeremy.linton at arm.com> wrote:
> This change allows ALIGN_RODATA for 16k and 64k kernels.
> In the case of 64k kernels it actually aligns to the CONT_SIZE
> rather than the SECTION_SIZE (which is 512M). This makes it generally
> more useful, especially for CONT enabled kernels.
>
> Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
> ---
>  arch/arm64/Kconfig.debug        | 12 ++++++------
>  arch/arm64/kernel/vmlinux.lds.S | 11 ++++++-----
>  2 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> index e13c4bf..65705ee 100644
> --- a/arch/arm64/Kconfig.debug
> +++ b/arch/arm64/Kconfig.debug
> @@ -59,15 +59,15 @@ config DEBUG_RODATA
>            If in doubt, say Y
>
>  config DEBUG_ALIGN_RODATA
> -       depends on DEBUG_RODATA && ARM64_4K_PAGES
> +       depends on DEBUG_RODATA
>         bool "Align linker sections up to SECTION_SIZE"
>         help
>           If this option is enabled, sections that may potentially be marked as
> -         read only or non-executable will be aligned up to the section size of
> -         the kernel. This prevents sections from being split into pages and
> -         avoids a potential TLB penalty. The downside is an increase in
> -         alignment and potentially wasted space. Turn on this option if
> -         performance is more important than memory pressure.
> +         read only or non-executable will be aligned up to the section size
> +         or contiguous hint size of the kernel. This prevents sections from
> +         being split into pages and avoids a potential TLB penalty. The downside
> +         is an increase in alignment and potentially wasted space. Turn on
> +         this option if performance is more important than memory pressure.
>
>           If in doubt, say N
>
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index b78a3c7..ab4e436 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -63,13 +63,14 @@ PECOFF_FILE_ALIGNMENT = 0x200;
>  #endif
>
>  #if defined(CONFIG_DEBUG_ALIGN_RODATA)
> -#define ALIGN_DEBUG_RO                 . = ALIGN(1<<SECTION_SHIFT);
> -#define ALIGN_DEBUG_RO_MIN(min)                ALIGN_DEBUG_RO
> +#if defined(CONFIG_ARM64_64K_PAGES)
> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(CONT_SIZE);
> +#else
> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(SECTION_SIZE);

Doesn't this align to 32 MB on 16k pages kernels?

> +#endif
>  #elif defined(CONFIG_DEBUG_RODATA)
> -#define ALIGN_DEBUG_RO                 . = ALIGN(1<<PAGE_SHIFT);
> -#define ALIGN_DEBUG_RO_MIN(min)                ALIGN_DEBUG_RO
> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(PAGE_SIZE);
>  #else
> -#define ALIGN_DEBUG_RO
>  #define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(min);
>  #endif
>
> --
> 2.4.3
>


From jeremy.linton at arm.com  Fri Feb 12 08:13:19 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Fri, 12 Feb 2016 10:13:19 -0600
Subject: [PATCH] arm64: mm: Mark .rodata as RO
Message-ID: <1455293599-6974-1-git-send-email-jeremy.linton@arm.com>

Currently the .rodata section is actually still executable when DEBUG_RODATA
is enabled. This changes that so the .rodata is actually read only, no execute.

Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
---
 arch/arm64/kernel/vmlinux.lds.S |  5 +++--
 arch/arm64/mm/mmu.c             | 14 +++++++++++---
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index ab4e436..2e2c053 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -114,8 +114,9 @@ SECTIONS
 		*(.got)			/* Global offset table		*/
 	}
 
-	RO_DATA(PAGE_SIZE)
-	EXCEPTION_TABLE(8)
+	ALIGN_DEBUG_RO_MIN(0)
+	RO_DATA(PAGE_SIZE)		/* everything from this point to */
+	EXCEPTION_TABLE(8)		/* _etext will be marked RO NX   */
 	NOTES
 
 	ALIGN_DEBUG_RO_MIN(PAGE_SIZE)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index ab69a99..a3f4112 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -453,10 +453,18 @@ static void __init map_mem(pgd_t *pgd)
 #ifdef CONFIG_DEBUG_RODATA
 void mark_rodata_ro(void)
 {
-	create_mapping_late(__pa(_stext), (unsigned long)_stext,
-				(unsigned long)_etext - (unsigned long)_stext,
-				PAGE_KERNEL_ROX);
+	unsigned long section_size;
 
+	section_size = (unsigned long)__start_rodata - (unsigned long)_stext;
+	create_mapping_late(__pa(_stext), (unsigned long)_stext,
+			    section_size, PAGE_KERNEL_ROX);
+	/*
+	 * mark .rodata as read only. Use _etext rather than __end_rodata to
+	 * cover NOTES and EXCEPTION_TABLE.
+	 */
+	section_size = (unsigned long)_etext - (unsigned long)__start_rodata;
+	create_mapping_late(__pa(__start_rodata), (unsigned long)__start_rodata,
+			    section_size, PAGE_KERNEL_RO);
 }
 #endif
 
-- 
2.4.3



From aneesh.kumar at linux.vnet.ibm.com  Fri Feb 12 08:17:39 2016
From: aneesh.kumar at linux.vnet.ibm.com (Aneesh Kumar K.V)
Date: Fri, 12 Feb 2016 21:47:39 +0530
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160212125943.1eb2ca9d@thinkpad>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad> <87a8n6shf2.fsf@linux.vnet.ibm.com>
 <20160212125943.1eb2ca9d@thinkpad>
Message-ID: <8760xtsy1o.fsf@linux.vnet.ibm.com>

Gerald Schaefer <gerald.schaefer at de.ibm.com> writes:

> On Fri, 12 Feb 2016 09:34:33 +0530
> "Aneesh Kumar K.V" <aneesh.kumar at linux.vnet.ibm.com> wrote:
>
>> Gerald Schaefer <gerald.schaefer at de.ibm.com> writes:
>> 
>> > On Thu, 11 Feb 2016 21:09:42 +0200
>> > "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
>> >
>> >> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
>> >> > Hi,
>> >> > 
>> >> > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
>> >> > he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
>> >> > review of the THP rework patches, which cannot be bisected, revealed
>> >> > commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
>> >> > (and also similar commits for other archs).
>> >> > 
>> >> > This commit removes the THP splitting bit and also the architecture
>> >> > implementation of pmdp_splitting_flush(), which took care of the IPI for
>> >> > fast_gup serialization. The commit message says
>> >> > 
>> >> >     pmdp_splitting_flush() is not needed too: on splitting PMD we will do
>> >> >     pmdp_clear_flush() + set_pte_at().  pmdp_clear_flush() will do IPI as
>> >> >     needed for fast_gup
>> >> > 
>> >> > The assumption that a TLB flush will also produce an IPI is wrong on s390,
>> >> > and maybe also on other architectures, and I thought that this was actually
>> >> > the main reason for having an arch-specific pmdp_splitting_flush().
>> >> > 
>> >> > At least PowerPC and ARM also had an individual implementation of
>> >> > pmdp_splitting_flush() that used kick_all_cpus_sync() instead of a TLB
>> >> > flush to send the IPI, and those were also removed. Putting the arch
>> >> > maintainers and mailing lists on cc to verify.
>> >> > 
>> >> > On s390 this will break the IPI serialization against fast_gup, which
>> >> > would certainly explain the random kernel crashes, please revert or fix
>> >> > the pmdp_splitting_flush() removal.
>> >> 
>> >> Sorry for that.
>> >> 
>> >> I believe, the problem was already addressed for PowerPC:
>> >> 
>> >> http://lkml.kernel.org/g/454980831-16631-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com
>> >> 
>> >> I think kick_all_cpus_sync() in arch-specific pmdp_invalidate() would do
>> >> the trick, right?
>> >
>> > Hmm, not sure about that. After pmdp_invalidate(), a pmd_none() check in
>> > fast_gup will still return false, because the pmd is not empty (at least
>> > on s390).
>> 
>> Why can't we do this ? I did this for ppc64.
>> 
>>  void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
>>  		     pmd_t *pmdp)
>>  {
>> -	pmd_hugepage_update(vma->vm_mm, address, pmdp, _PAGE_PRESENT, 0);
>> +	pmd_hugepage_update(vma->vm_mm, address, pmdp, ~0UL, 0);
>> 
>
> Wouldn't that semantically change what pmdp_invalidate() was supposed to
> do? The comment before the call says "the pmd_trans_huge and
> pmd_trans_splitting must remain set at all times on the pmd". So, after
> removing pmd_trans_splitting, it seems to be necessary to at least keep
> pmd_trans_huge set.
>
> In your case, the pmd would be completely cleared, which may help to find
> it in fast_gup with pmd_none(), but I'm not sure if this would open up
> other problems, e.g. with concurrent page faults. But I must also admit that
> my THP overview got a little rusty.

Thinking about this more, I guess, I should not be doing this. Because
this bring in the exit_mmap race that I outlined in the patch even
though the window now is small. 

I guess we should fix this in the gup path by checking for what ever
trick we are using to mark the pmd splitting. For ppc64 we clear the
_PAGE_USER. We are ok as long as autonuma is enabled because
pmd_protnone() check will check against _PAGE_USER. But that may not be
sufficient. 

-aneesh



From jeremy.linton at arm.com  Fri Feb 12 08:21:44 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Fri, 12 Feb 2016 10:21:44 -0600
Subject: [PATCH 1/2] arm64: mm: Enable CONT_SIZE aligned sections for 64k
 page kernels.
In-Reply-To: <CAKv+Gu_ViEAVN1GEDMWpJ5OYjg6BVSLTEtdus6vCCXchQ1BOjw@mail.gmail.com>
References: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
 <1455293208-6763-2-git-send-email-jeremy.linton@arm.com>
 <CAKv+Gu_ViEAVN1GEDMWpJ5OYjg6BVSLTEtdus6vCCXchQ1BOjw@mail.gmail.com>
Message-ID: <56BE0698.10506@arm.com>

On 02/12/2016 10:11 AM, Ard Biesheuvel wrote:
> On 12 February 2016 at 17:06, Jeremy Linton <jeremy.linton at arm.com> wrote:
(trimming)
>>   #if defined(CONFIG_DEBUG_ALIGN_RODATA)
>> -#define ALIGN_DEBUG_RO                 . = ALIGN(1<<SECTION_SHIFT);
>> -#define ALIGN_DEBUG_RO_MIN(min)                ALIGN_DEBUG_RO
>> +#if defined(CONFIG_ARM64_64K_PAGES)
>> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(CONT_SIZE);
>> +#else
>> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(SECTION_SIZE);
>
> Doesn't this align to 32 MB on 16k pages kernels?

Yes, I considered whether it was more appropriate to use CONT_SIZE for 
16k as well.

Opinions?

>
>> +#endif
>>   #elif defined(CONFIG_DEBUG_RODATA)
>> -#define ALIGN_DEBUG_RO                 . = ALIGN(1<<PAGE_SHIFT);
>> -#define ALIGN_DEBUG_RO_MIN(min)                ALIGN_DEBUG_RO
>> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(PAGE_SIZE);
>>   #else
>> -#define ALIGN_DEBUG_RO
>>   #define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(min);
>>   #endif
>>
>> --
>> 2.4.3
>>
>



From ard.biesheuvel at linaro.org  Fri Feb 12 08:28:36 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 17:28:36 +0100
Subject: [PATCH 1/2] arm64: mm: Enable CONT_SIZE aligned sections for 64k
 page kernels.
In-Reply-To: <56BE0698.10506@arm.com>
References: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
 <1455293208-6763-2-git-send-email-jeremy.linton@arm.com>
 <CAKv+Gu_ViEAVN1GEDMWpJ5OYjg6BVSLTEtdus6vCCXchQ1BOjw@mail.gmail.com>
 <56BE0698.10506@arm.com>
Message-ID: <CAKv+Gu--05Wn6oWEiy=43nzujNgG0=DpOB9b1zs9_jfddYXWwQ@mail.gmail.com>

On 12 February 2016 at 17:21, Jeremy Linton <jeremy.linton at arm.com> wrote:
> On 02/12/2016 10:11 AM, Ard Biesheuvel wrote:
>>
>> On 12 February 2016 at 17:06, Jeremy Linton <jeremy.linton at arm.com> wrote:
>
> (trimming)
>>>
>>>   #if defined(CONFIG_DEBUG_ALIGN_RODATA)
>>> -#define ALIGN_DEBUG_RO                 . = ALIGN(1<<SECTION_SHIFT);
>>> -#define ALIGN_DEBUG_RO_MIN(min)                ALIGN_DEBUG_RO
>>> +#if defined(CONFIG_ARM64_64K_PAGES)
>>> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(CONT_SIZE);
>>> +#else
>>> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(SECTION_SIZE);
>>
>>
>> Doesn't this align to 32 MB on 16k pages kernels?
>
>
> Yes, I considered whether it was more appropriate to use CONT_SIZE for 16k
> as well.
>
> Opinions?
>

Looking at vmlinux.lds.S, I see that that would put _stext and
__init_begin at 32 MB aligned boundaries. making the size of the
kernel at least 64 MB. If I take your .rodata patch into account,
which adds a third instance of ALIGN_DEBUG_RO_MIN, the Image footprint
will rise to ~100 MB. Or am I missing something?



>
>>
>>> +#endif
>>>   #elif defined(CONFIG_DEBUG_RODATA)
>>> -#define ALIGN_DEBUG_RO                 . = ALIGN(1<<PAGE_SHIFT);
>>> -#define ALIGN_DEBUG_RO_MIN(min)                ALIGN_DEBUG_RO
>>> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(PAGE_SIZE);
>>>   #else
>>> -#define ALIGN_DEBUG_RO
>>>   #define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(min);
>>>   #endif
>>>
>>> --
>>> 2.4.3
>>>
>>
>


From alexander.shishkin at linux.intel.com  Fri Feb 12 08:27:32 2016
From: alexander.shishkin at linux.intel.com (Alexander Shishkin)
Date: Fri, 12 Feb 2016 18:27:32 +0200
Subject: [PATCH V2 3/6] stm class: provision for statically assigned
 masterIDs
In-Reply-To: <CANLsYkw=mG+ch8QzxmbwWs9o+mndVNo1MuqXcrPrNJYj_SQcHQ@mail.gmail.com>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
 <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org>
 <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com>
 <CANLsYky2twQ98u241YyHD=atYRp1N56YVHUQNY2E2Ljsq0cseA@mail.gmail.com>
 <87twlj49k7.fsf@ashishki-desk.ger.corp.intel.com>
 <CANLsYkw=mG+ch8QzxmbwWs9o+mndVNo1MuqXcrPrNJYj_SQcHQ@mail.gmail.com>
Message-ID: <87r3gh3nd7.fsf@ashishki-desk.ger.corp.intel.com>

Mathieu Poirier <mathieu.poirier at linaro.org> writes:

> On 8 February 2016 at 06:26, Alexander Shishkin
> <alexander.shishkin at linux.intel.com> wrote:
>> This $end==$start situation itself may be ambiguous and can be
>> interpreted either as having just one *static* master ID fixed for all
>> SW writers (what I assumed from your commit message) or as having a
>> floating master ID, which changes of its own accord and is not
>> controllable by software.
>
> Some clarification here.
>
> On ARM from a SW point of view $end == $start and that doesn't change
> (with regards to masterIDs) .  The ambiguity comes from the fact that
> on other platforms where masterID configuration does change and is
> important, the condition $end == $start could also be valid.

Yes, that's what I was saying. The thing is, on the system-under-tracing
side these two situations are not very different from one
another. Master IDs are really just numbers without any semantics
attached to them in the sense that they are not covered by the mipi spec
or any other standard (to my knowledge).

The difference is in the way we map channels to masters. One way is to
allocate a distinct set of channels for each master (the way Intel Trace
Hub does it); another way is to share the same set of channels between
multiple masters. So we can describe this as "hardware implements the
same set of channels across multiple masters" or something along those
lines.

Actually, in the latter scheme of things you can also have multiple
masters, at least theoretically. Say, you have masters [0..15], each
with distinct set of channels, but depending on hardware state these
masters actually end up as $state*16+$masterID in the STP stream.

So we might also think about differentiating between the hardware
masters (0 though 15 in the above example) and STP masters.

Regards,
--
Alex


From alexdeucher at gmail.com  Fri Feb 12 08:31:04 2016
From: alexdeucher at gmail.com (Alex Deucher)
Date: Fri, 12 Feb 2016 11:31:04 -0500
Subject: [PATCH 04/17] drm/amdgpu: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <1455285069-2819-5-git-send-email-palminha@synopsys.com>
References: <daniel.vetter@ffwll.ch,>
 <1455285069-2819-1-git-send-email-palminha@synopsys.com>
 <1455285069-2819-5-git-send-email-palminha@synopsys.com>
Message-ID: <CADnq5_N1smWVyhC68fwS4DO_E9NJ=ztSZMaSoZ3YKvSCtaM8Zg@mail.gmail.com>

On Fri, Feb 12, 2016 at 8:50 AM, Carlos Palminha
<CARLOS.PALMINHA at synopsys.com> wrote:
> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 8 --------
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 8 --------
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  | 8 --------
>  3 files changed, 24 deletions(-)

Reviewed-by: Alex Deucher <alexander.deucher at amd.com>

>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 093599a..3483018 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -3624,16 +3624,8 @@ dce_v10_0_ext_dpms(struct drm_encoder *encoder, int mode)
>
>  }
>
> -static bool dce_v10_0_ext_mode_fixup(struct drm_encoder *encoder,
> -                                   const struct drm_display_mode *mode,
> -                                   struct drm_display_mode *adjusted_mode)
> -{
> -       return true;
> -}
> -
>  static const struct drm_encoder_helper_funcs dce_v10_0_ext_helper_funcs = {
>         .dpms = dce_v10_0_ext_dpms,
> -       .mode_fixup = dce_v10_0_ext_mode_fixup,
>         .prepare = dce_v10_0_ext_prepare,
>         .mode_set = dce_v10_0_ext_mode_set,
>         .commit = dce_v10_0_ext_commit,
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 8e67249..36deea1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -3619,16 +3619,8 @@ dce_v11_0_ext_dpms(struct drm_encoder *encoder, int mode)
>
>  }
>
> -static bool dce_v11_0_ext_mode_fixup(struct drm_encoder *encoder,
> -                                   const struct drm_display_mode *mode,
> -                                   struct drm_display_mode *adjusted_mode)
> -{
> -       return true;
> -}
> -
>  static const struct drm_encoder_helper_funcs dce_v11_0_ext_helper_funcs = {
>         .dpms = dce_v11_0_ext_dpms,
> -       .mode_fixup = dce_v11_0_ext_mode_fixup,
>         .prepare = dce_v11_0_ext_prepare,
>         .mode_set = dce_v11_0_ext_mode_set,
>         .commit = dce_v11_0_ext_commit,
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index d0e128c..25dd8b6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -3554,16 +3554,8 @@ dce_v8_0_ext_dpms(struct drm_encoder *encoder, int mode)
>
>  }
>
> -static bool dce_v8_0_ext_mode_fixup(struct drm_encoder *encoder,
> -                                   const struct drm_display_mode *mode,
> -                                   struct drm_display_mode *adjusted_mode)
> -{
> -       return true;
> -}
> -
>  static const struct drm_encoder_helper_funcs dce_v8_0_ext_helper_funcs = {
>         .dpms = dce_v8_0_ext_dpms,
> -       .mode_fixup = dce_v8_0_ext_mode_fixup,
>         .prepare = dce_v8_0_ext_prepare,
>         .mode_set = dce_v8_0_ext_mode_set,
>         .commit = dce_v8_0_ext_commit,
> --
> 2.5.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


From yamada.masahiro at socionext.com  Fri Feb 12 08:30:46 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Sat, 13 Feb 2016 01:30:46 +0900
Subject: [PATCH v2] serial: earlycon: rework common framework for earlycon
 declarations
In-Reply-To: <56BDF799.1030505@hurleysoftware.com>
References: <1455273394-27350-1-git-send-email-yamada.masahiro@socionext.com>
 <56BDF799.1030505@hurleysoftware.com>
Message-ID: <CAK7LNAS_vietwRRFnH3YhbWSzjRFP4U6rjftYek1KQ3ips2ZSQ@mail.gmail.com>

Hi Peter,


2016-02-13 0:17 GMT+09:00 Peter Hurley <peter at hurleysoftware.com>:
> On 02/12/2016 02:36 AM, Masahiro Yamada wrote:
>> Commit 71f50c6d9a22 ("of: drop symbols declared by _OF_DECLARE() from
>> modules") fixed the link error introduced by commit b8d20e06eaad
>> ("serial: 8250_uniphier: add earlycon support").
>>
>> After commit 2eaa790989e0 ("earlycon: Use common framework for
>> earlycon declarations") was applied, the link error came back
>> because the commit reworked OF_EARLYCON_DECLARE() to not use
>> _OF_DECLARE().
>
> What link error are you getting?

The combination of CONFIG_SERIAL_8250_CONSOLE=y
and CONFIG_SERIAL_8250_UNIPHIER=m causes a link error.



>
>> This commit reworks OF_EARLYCON_DECLARE() again based on
>> _OF_DECLARE().  My motivations are:
>>
>>  - Fix the link error in a generic way (without patching
>>    drivers/tty/serial/8250/8250_uniphier.c)
>>
>>  - Delete struct earlycon_id.  This struct is re-inventing the wheel;
>>    the fields "name", "compatible", "setup" can be implemented in
>>    struct of_device_id as other frameworks do.
>
> This patch basically reverts the common framework.
> What happens when not building with OF? Does it still declare the
> earlycon table?

Ah, I missed this.  (sigh)

Earlycon must still work without OF.
My way only works with OF.

I really screwed up.  Sorry.

Just disregard this patch.





-- 
Best Regards
Masahiro Yamada


From alexdeucher at gmail.com  Fri Feb 12 08:31:19 2016
From: alexdeucher at gmail.com (Alex Deucher)
Date: Fri, 12 Feb 2016 11:31:19 -0500
Subject: [PATCH 14/17] drm/radeon: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <1455285350-3403-1-git-send-email-palminha@synopsys.com>
References: <1455285350-3403-1-git-send-email-palminha@synopsys.com>
Message-ID: <CADnq5_PchtK9bYHSAYjf6mnJ77+O9VzvbNxsoSLcafqYrhBF3A@mail.gmail.com>

On Fri, Feb 12, 2016 at 8:55 AM, Carlos Palminha
<CARLOS.PALMINHA at synopsys.com> wrote:
> ---
>  drivers/gpu/drm/radeon/atombios_encoders.c | 8 --------
>  1 file changed, 8 deletions(-)

Reviewed-by: Alex Deucher <alexander.deucher at amd.com>

>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
> index 01b20e1..1603751 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -2623,16 +2623,8 @@ radeon_atom_ext_dpms(struct drm_encoder *encoder, int mode)
>
>  }
>
> -static bool radeon_atom_ext_mode_fixup(struct drm_encoder *encoder,
> -                                      const struct drm_display_mode *mode,
> -                                      struct drm_display_mode *adjusted_mode)
> -{
> -       return true;
> -}
> -
>  static const struct drm_encoder_helper_funcs radeon_atom_ext_helper_funcs = {
>         .dpms = radeon_atom_ext_dpms,
> -       .mode_fixup = radeon_atom_ext_mode_fixup,
>         .prepare = radeon_atom_ext_prepare,
>         .mode_set = radeon_atom_ext_mode_set,
>         .commit = radeon_atom_ext_commit,
> --
> 2.5.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


From mchehab at osg.samsung.com  Fri Feb 12 08:32:20 2016
From: mchehab at osg.samsung.com (Mauro Carvalho Chehab)
Date: Fri, 12 Feb 2016 14:32:20 -0200
Subject: [PATCH] [media] zl10353: use div_u64 instead of do_div
In-Reply-To: <1455287246-3540549-1-git-send-email-arnd@arndb.de>
References: <1455287246-3540549-1-git-send-email-arnd@arndb.de>
Message-ID: <20160212143220.5a440e66@recife.lan>

Em Fri, 12 Feb 2016 15:27:18 +0100
Arnd Bergmann <arnd at arndb.de> escreveu:

> I noticed a build error in some randconfig builds in the zl10353 driver:
> 
> dvb-frontends/zl10353.c:138: undefined reference to `____ilog2_NaN'
> dvb-frontends/zl10353.c:138: undefined reference to `__aeabi_uldivmod'
> 
> The problem can be tracked down to the use of -fprofile-arcs (using
> CONFIG_GCOV_PROFILE_ALL) in combination with CONFIG_PROFILE_ALL_BRANCHES
> on gcc version 4.9 or higher, when it fails to reliably optimize
> constant expressions.
> 
> Using div_u64() instead of do_div() makes the code slightly more
> readable by both humans and by gcc, which gives the compiler enough
> of a break to figure it all out.

I'm not against this patch, but we have 94 occurrences of do_div() 
just at the media subsystem. If this is failing here, it would likely
fail with other drivers. So, I guess we should either fix do_div() or
convert all such occurrences to do_div64().

> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/media/dvb-frontends/zl10353.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/dvb-frontends/zl10353.c b/drivers/media/dvb-frontends/zl10353.c
> index ef9764a02d4c..160c88710553 100644
> --- a/drivers/media/dvb-frontends/zl10353.c
> +++ b/drivers/media/dvb-frontends/zl10353.c
> @@ -135,8 +135,7 @@ static void zl10353_calc_nominal_rate(struct dvb_frontend *fe,
>  
>  	value = (u64)10 * (1 << 23) / 7 * 125;
>  	value = (bw * value) + adc_clock / 2;
> -	do_div(value, adc_clock);
> -	*nominal_rate = value;
> +	*nominal_rate = div_u64(value, adc_clock);
>  
>  	dprintk("%s: bw %d, adc_clock %d => 0x%x\n",
>  		__func__, bw, adc_clock, *nominal_rate);
> @@ -163,8 +162,7 @@ static void zl10353_calc_input_freq(struct dvb_frontend *fe,
>  		if (ife > adc_clock / 2)
>  			ife = adc_clock - ife;
>  	}
> -	value = (u64)65536 * ife + adc_clock / 2;
> -	do_div(value, adc_clock);
> +	value = div_u64((u64)65536 * ife + adc_clock / 2, adc_clock);
>  	*input_freq = -value;
>  
>  	dprintk("%s: if2 %d, ife %d, adc_clock %d => %d / 0x%x\n",


From gregory.clement at free-electrons.com  Fri Feb 12 08:35:17 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Feb 2016 17:35:17 +0100
Subject: [PATCH 0/3] ARM: mvebu: Add driver for the Zyxel NSA3XX hwmon MCU
In-Reply-To: <1455147224-6742-1-git-send-email-linux@baker-net.org.uk> (Adam
 Baker's message of "Wed, 10 Feb 2016 23:33:41 +0000")
References: <1455147224-6742-1-git-send-email-linux@baker-net.org.uk>
Message-ID: <87mvr5x4xm.fsf@free-electrons.com>

Hi Adam,
 
 On jeu., f?vr. 11 2016, Adam Baker <linux at baker-net.org.uk> wrote:

> This patch series adds a driver to support the hardware monitoring MCU
> that is present in some models of the Zyxel NSA3xx series of NAS units.
>
> A patch is included to add it to the device tree for the NSA320 model,
> patches to the other device trees will be included if testers come
> forward (I already have a possible tester for NSA325).
>
> There are no dependencies between the patches so I guess the first two
> should go via the hardware monitoring maintainers and the third via
> the ARM mvebu maintainers.

You are right. However the first tow patch are misnamed, they better
should be called:
hwmn: Define binding for the nsa3xx-hwmon driver
hwmn: Create a driver to support the hardware monitoring chip

The last patch seems OK for me, and the binding has been approved. So
when you will get a review from the hwmon maintainer, I will apply the
last patch in the mvebu tree.

Thanks,

Gregory

>
>  [PATCH 1/3] Define a binding for the hardware monitoring chip present
>  [PATCH 2/3] Create a driver to support the hardware monitoring chip
>  [PATCH 3/3] Add an entry for the hardware monitoring MCU
>
>  Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt |  21 ++++++++
>  arch/arm/boot/dts/kirkwood-nsa320.dts                  |  13 ++++-
>  drivers/hwmon/Kconfig                                  |  13 +++++
>  drivers/hwmon/Makefile                                 |   1 +
>  drivers/hwmon/nsa3xx-hwmon.c | 223
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 269 insertions(+), 2 deletions(-)

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From robh at kernel.org  Fri Feb 12 08:37:42 2016
From: robh at kernel.org (Rob Herring)
Date: Fri, 12 Feb 2016 10:37:42 -0600
Subject: [PATCH 1/3] Documentation: devicetree: add Freescale SCC bindings
In-Reply-To: <1455199485-24458-1-git-send-email-s.trumtrar@pengutronix.de>
References: <1455199485-24458-1-git-send-email-s.trumtrar@pengutronix.de>
Message-ID: <20160212163742.GA6769@rob-hp-laptop>

On Thu, Feb 11, 2016 at 03:04:43PM +0100, Steffen Trumtrar wrote:
> Add documentation for the Freescale Security Controller (SCC)
> found on i.MX25 SoCs.
> 
> Signed-off-by: Steffen Trumtrar <s.trumtrar at pengutronix.de>
> ---
>  .../devicetree/bindings/crypto/fsl-imx-scc.txt          | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt

Acked-by: Rob Herring <robh at kernel.org>


From yamada.masahiro at socionext.com  Fri Feb 12 08:37:56 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Sat, 13 Feb 2016 01:37:56 +0900
Subject: [PATCH v2 4/6] serial: 8250/uniphier: fix modular build
In-Reply-To: <3557175.oOjJgCHd2P@wuerfel>
References: <1455205297-1021302-1-git-send-email-arnd@arndb.de>
 <1455205297-1021302-5-git-send-email-arnd@arndb.de>
 <CAK7LNAR8fJWPubucjw28gAPpF-4yvVMWZZ0F3j6VN4whGF9Yhw@mail.gmail.com>
 <3557175.oOjJgCHd2P@wuerfel>
Message-ID: <CAK7LNAT9DN=zCamO8HYVpj5R4KxoFMH-e3HjjYN6XmxYi3NNuw@mail.gmail.com>

Hi Arnd,


2016-02-12 19:07 GMT+09:00 Arnd Bergmann <arnd at arndb.de>:
> On Friday 12 February 2016 18:37:08 Masahiro Yamada wrote:
>> >  };
>> >
>> > -#ifdef CONFIG_SERIAL_8250_CONSOLE
>> > +#if defined(CONFIG_SERIAL_8250_CONSOLE) && !defined(MODULE)
>> >  static int __init uniphier_early_console_setup(struct earlycon_device *device,
>> >                                                const char *options)
>> >  {
>> > --
>> > 2.7.0
>> >
>>
>> I noticed commit 2eaa790989e03900298ad24f77f1086dbbc1aebd
>> revived this link error, but I am not happy with seeing
>> this patch again and again.
>>
>>
>> Can you check this patch?
>> https://patchwork.kernel.org/patch/8289231/
>>
>>
>>
>
> Yes, I think your patch is nicer than mine. Let's see what the others
> think, then I can resend my remaining patches on top of yours.
>

As Peter pointed out, my patch would not work without CONFIG_OF.

I can not suggest any other alternative,
so I am OK with this patch.

Unfortunately, the "tty-linus" branch is getting dirty with
apply, revert, apply again.



-- 
Best Regards
Masahiro Yamada


From robh at kernel.org  Fri Feb 12 08:40:53 2016
From: robh at kernel.org (Rob Herring)
Date: Fri, 12 Feb 2016 10:40:53 -0600
Subject: [PATCH v3 1/6] arm: add device-tree SoC bindings for Axis Artpec-6
In-Reply-To: <0a38251ad8ad1895a1744f43a58f6b161676af09.1455205057.git.larper@axis.com>
References: <cover.1455205057.git.larper@axis.com>
 <0a38251ad8ad1895a1744f43a58f6b161676af09.1455205057.git.larper@axis.com>
Message-ID: <20160212164053.GA8287@rob-hp-laptop>

On Thu, Feb 11, 2016 at 05:06:16PM +0100, Lars Persson wrote:
> This adds device tree bindings for the Artpec-6 SoC.
> 
> Signed-off-by: Lars Persson <larper at axis.com>
> ---
>  Documentation/devicetree/bindings/arm/axis.txt | 29 ++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/axis.txt

Acked-by: Rob Herring <robh at kernel.org>


From will.deacon at arm.com  Fri Feb 12 08:42:18 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 12 Feb 2016 16:42:18 +0000
Subject: [PATCHv2] arm64: Rework valid_user_regs
In-Reply-To: <CAFEAcA_XGrPB=2GnQwW4Jr8eE9UqbTAgRb86qCkX+rw25u4yNg@mail.gmail.com>
References: <1455285858-11757-1-git-send-email-mark.rutland@arm.com>
 <CAFEAcA_XGrPB=2GnQwW4Jr8eE9UqbTAgRb86qCkX+rw25u4yNg@mail.gmail.com>
Message-ID: <20160212164218.GC17901@arm.com>

On Fri, Feb 12, 2016 at 02:53:51PM +0000, Peter Maydell wrote:
> On 12 February 2016 at 14:04, Mark Rutland <mark.rutland at arm.com> wrote:
> > We validate pstate using PSR_MODE32_BIT, which is part of the
> > user-provided pstate (and cannot be trusted). Also, we conflate
> > validation of AArch32 and AArch64 pstate values, making the code
> > difficult to reason about.
> >
> > Instead, validate the pstate value based on the associated task. The
> > task may or may not be current (e.g. when using ptrace), so this must be
> > passed explicitly by callers. To avoid circular header dependencies via
> > sched.h, is_compat_task is pulled out of asm/ptrace.h.
> >
> > To make the code possible to reason about, the AArch64 and AArch32
> > validation is split into separate functions. Software must respect the
> > RES0 policy for SPSR bits, and thus the kernel mirrors the hardware
> > policy (RAZ/WI) for bits as-yet unallocated. When these acquire an
> > architected meaning writes may be permitted (potentially with additional
> > validation).
> 
> > +       /* Force PSR to a valid 32-bit EL0t */
> > +       regs->pstate |= PSR_MODE32_BIT;
> > +       regs->pstate &= PSR_f | PSR_s | (PSR_x & ~COMPAT_PSR_A_BIT) | \
> > +                       COMPAT_PSR_T_BIT;
> > +
> 
> I think the consensus from the v1 review was to drop these PSR_[fsx] masks?

Yup. Mark, if you respin with that change then I can take this as a fix.

Thanks,

Will


From jeremy.linton at arm.com  Fri Feb 12 08:43:23 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Fri, 12 Feb 2016 10:43:23 -0600
Subject: [PATCH 1/2] arm64: mm: Enable CONT_SIZE aligned sections for 64k
 page kernels.
In-Reply-To: <CAKv+Gu--05Wn6oWEiy=43nzujNgG0=DpOB9b1zs9_jfddYXWwQ@mail.gmail.com>
References: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
 <1455293208-6763-2-git-send-email-jeremy.linton@arm.com>
 <CAKv+Gu_ViEAVN1GEDMWpJ5OYjg6BVSLTEtdus6vCCXchQ1BOjw@mail.gmail.com>
 <56BE0698.10506@arm.com>
 <CAKv+Gu--05Wn6oWEiy=43nzujNgG0=DpOB9b1zs9_jfddYXWwQ@mail.gmail.com>
Message-ID: <56BE0BAB.7060502@arm.com>

On 02/12/2016 10:28 AM, Ard Biesheuvel wrote:
> On 12 February 2016 at 17:21, Jeremy Linton <jeremy.linton at arm.com> wrote:
>> On 02/12/2016 10:11 AM, Ard Biesheuvel wrote:
>>>
>>> On 12 February 2016 at 17:06, Jeremy Linton <jeremy.linton at arm.com> wrote:
>>
>> (trimming)
>>>>
>>>>    #if defined(CONFIG_DEBUG_ALIGN_RODATA)
>>>> -#define ALIGN_DEBUG_RO                 . = ALIGN(1<<SECTION_SHIFT);
>>>> -#define ALIGN_DEBUG_RO_MIN(min)                ALIGN_DEBUG_RO
>>>> +#if defined(CONFIG_ARM64_64K_PAGES)
>>>> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(CONT_SIZE);
>>>> +#else
>>>> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(SECTION_SIZE);
>>>
>>>
>>> Doesn't this align to 32 MB on 16k pages kernels?
>>
>>
>> Yes, I considered whether it was more appropriate to use CONT_SIZE for 16k
>> as well.
>>
>> Opinions?
>>
>
> Looking at vmlinux.lds.S, I see that that would put _stext and
> __init_begin at 32 MB aligned boundaries. making the size of the
> kernel at least 64 MB. If I take your .rodata patch into account,
> which adds a third instance of ALIGN_DEBUG_RO_MIN, the Image footprint
> will rise to ~100 MB. Or am I missing something?
>

No, I think your correct. But, its an option, and it sort of depends on 
use case. In a system with 100+GB of RAM it might be useful. Not so much 
on a phone or small embedded system. I don't really see those people 
enabling ALIGN_RODATA anyway. Worse, I expect the loss of RAM 
efficiently going from 4k-16k pages in a RAM constrained system to be a 
pretty big hit too.

I don't have any hard data one way or the other, and I don't have a 
strong opinion. Although, I suspect at the moment the potential users of 
16k pages may tend toward the small side.










From wens at csie.org  Fri Feb 12 08:43:27 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Sat, 13 Feb 2016 00:43:27 +0800
Subject: [PATCH 10/14] ARM: dts: sun8i-a83t: Add PRCM related clocks and
 resets
In-Reply-To: <CAEzqOZtsdHC2tCgjC=Bj5q3RFip2Uyni8bFC16u03PRLCra5KA@mail.gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-11-git-send-email-vishnupatekar0510@gmail.com>
 <CAGb2v67iO-816KaLttWRRPL2f7hpfgJ1--p69tD_oOrewmOjCA@mail.gmail.com>
 <CAEzqOZtsdHC2tCgjC=Bj5q3RFip2Uyni8bFC16u03PRLCra5KA@mail.gmail.com>
Message-ID: <CAGb2v65cfG=cJ91+9G5uS5XcUh0nx6-7ZnMr7RjSGqXPHjyxpQ@mail.gmail.com>

On Sat, Feb 13, 2016 at 12:06 AM, Vishnu Patekar
<vishnupatekar0510 at gmail.com> wrote:
> Hello Wens,
>
>
> On Tue, Feb 2, 2016 at 2:44 PM, Chen-Yu Tsai <wens at csie.org> wrote:
>> On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
>> <vishnupatekar0510 at gmail.com> wrote:
>>> This adds A83T PRCM related clocks, clock resets.
>>>
>>> As a83t apb0 gates clock support is added earlier, this enables it.
>>> Apart from apb0 gates, other added clocks are compatible with
>>> earlier sun8i socs.
>>>
>>> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
>>> ---
>>>  arch/arm/boot/dts/sun8i-a83t.dtsi | 44 +++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 44 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
>>> index ac96aa1..5ea20ff 100644
>>> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
>>> @@ -268,6 +268,44 @@
>>>                                              "mmc2_output",
>>>                                              "mmc2_sample";
>>>                 };
>>> +
>>> +               cpus_clk: clk at 01f01400 {
>>> +                       compatible = "allwinner,sun9i-a80-cpus-clk";
>>> +                       reg = <0x01f01400 0x4>;
>>> +                       #clock-cells = <0>;
>>> +                       clocks = <&osc16Md512>, <&osc24M>, <&pll6>, <&osc16M>;
>>> +                       clock-output-names = "cpus";
>>> +               };
>>> +
>>> +               ahb0: ahb0_clk {
>>> +                       compatible = "fixed-factor-clock";
>>> +                       #clock-cells = <0>;
>>> +                       clock-div = <1>;
>>> +                       clock-mult = <1>;
>>> +                       clocks = <&cpus_clk>;
>>> +                       clock-output-names = "ahb0";
>>> +               };
>>> +
>>> +               apb0: clk at 01f0140c {
>>> +                       compatible = "allwinner,sun8i-a23-apb0-clk";
>>
>> This is actually wrong, as it is wrong in sun9i-a80.dtsi.
>> I've sent a patch series for it.
> A83T apb0 is different from A80, and it's same as A23, so this should
> be correct.
> Please correct me in case I'm missing something.

My user manual (v1.5.1) says A83T apb0 dividers (page. 246) are
/1, /2, /3, /4, while the A23 is /1, /2, /4, /8.

ChenYu

>> Also the drivers for "allwinner,sun9i-a80-cpus-clk" and
>> "allwinner,sun9i-a80-apbs-clk"
>> are only compiled for CONFIG_MACH_SUN9I. Please add a patch to address this.
> Okie.
>>
>> Regards
>> ChenYu
>>
>>> +                       reg = <0x01f0140c 0x4>;
>>> +                       #clock-cells = <0>;
>>> +                       clocks = <&ahb0>;
>>> +                       clock-output-names = "apb0";
>>> +               };
>>> +
>>> +               apb0_gates: clk at 01f01428 {
>>> +                       compatible = "allwinner,sun8i-a83t-apb0-gates-clk";
>>> +                       reg = <0x01f01428 0x4>;
>>> +                       #clock-cells = <1>;
>>> +                       clocks = <&apb0>;
>>> +                       clock-indices = <0>, <1>,
>>> +                                       <2>, <3>,
>>> +                                       <4>, <6>, <7>;
>>> +                       clock-output-names = "apb0_pio", "apb0_ir",
>>> +                                       "apb0_timer", "apb0_rsb",
>>> +                                       "apb0_uart", "apb0_i2c0", "apb0_twd";
>>> +               };
>>>         };
>>>
>>>         soc {
>>> @@ -434,5 +472,11 @@
>>>                         #interrupt-cells = <3>;
>>>                         interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
>>>                 };
>>> +
>>> +               apb0_reset: reset at 01f014b0 {
>>> +                       reg = <0x01f014b0 0x4>;
>>> +                       compatible = "allwinner,sun6i-a31-clock-reset";
>>> +                       #reset-cells = <1>;
>>> +               };
>>>         };
>>>  };
>>> --
>>> 1.9.1
>>>


From ard.biesheuvel at linaro.org  Fri Feb 12 08:44:13 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 17:44:13 +0100
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu_bKeJiS0Ctd8QU2M7_SKfpDrA5hksqZgfPUwYqO_KrjA@mail.gmail.com>

On 12 February 2016 at 17:06, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Fri, Feb 12, 2016 at 03:38:46PM +0000, Sudeep Holla wrote:
>>
>> On 12/02/16 15:26, Catalin Marinas wrote:
>> >On Fri, Feb 12, 2016 at 04:17:09PM +0100, Ard Biesheuvel wrote:
>> >>On 12 February 2016 at 16:10, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> >>>On Fri, Feb 12, 2016 at 04:02:58PM +0100, Ard Biesheuvel wrote:
>> >>>>On 12 February 2016 at 15:58, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> >>>>>On Mon, Feb 01, 2016 at 11:54:52AM +0100, Ard Biesheuvel wrote:
>> >>>>>>This moves the module area to right before the vmalloc area, and
>> >>>>>>moves the kernel image to the base of the vmalloc area. This is
>> >>>>>>an intermediate step towards implementing KASLR, which allows the
>> >>>>>>kernel image to be located anywhere in the vmalloc area.
>> >>>>>>
>> >>>>>>Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> >>>>>
>> >>>>>This patch is causing lots of KASAN warnings on Juno (interestingly, it
>> >>>>>doesn't seem to trigger on Seattle, though we only tried for-next/core).
>> >>>>>I pushed the branch that I'm currently using here:
>> >>>>>
>> >>>>>git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux for-next/kernmap
>> >>>>>
>> >>>>>
>> >>>>>A typical error (though its place varies based on the config options,
>> >>>>>kernel layout):
>> >>>>>
>> >>>>>BUG: KASAN: stack-out-of-bounds in clockevents_program_event+0x28/0x1b0 at addr ffffffc936257cc8
>> >>>>
>> >>>>Can you confirm that these are stack accesses? I was having similar
>> >>>>errors before, and I ended up creating the kasan zero page patch
>> >>>>because it turned out the kasan shadow page in question was aliased
>> >>>>and the stack writes were occurring elsewhere.
>> >>>
>> >>>It's possible, we are looking into this. Is there any other patch I miss on
>> >>>the above branch?
>> >>
>> >>I don't think so but I will check
>> >
>> >Commit 7b1af9795773 ("arm64: kasan: ensure that the KASAN zero page is
>> >mapped read-only") was merged in -rc2 while the branch above is based on
>> >-rc1. Anyway, I merged it into -rc2 and the errors are similar.
>> >
>>
>> Sorry to add more confusion, but I observed similar KASAN warning
>> with latest mainline(v4.5-rc3+, commit c05235d50f68) with below diff.
>
> I can reproduce this with UBSAN enabled (log below for the record).
>
> So far, we have:
>
> KASAN+for-next/kernmap goes wrong
> KASAN+UBSAN goes wrong
>
> Enabled individually, KASAN, UBSAN and for-next/kernmap seem fine. I may
> have to trim for-next/core down until we figure out where the problem
> is.
>

I haven't managed to reproduce this yet on QEMU, Seattle or FVP, but I
did notice something that may or may not be related:
without my changes the memory map show this:

    kasan   : 0xffffff8000000000 - 0xffffff9000000000   (    64 GB)
    vmalloc : 0xffffff9000010000 - 0xffffffbdbfff0000   (   182 GB)

i.e., there is a 64 KB guard region between the shadow region and the
vmalloc region. I am not sure what it is for, but I realize now that I
accidentally removed it in my patch:

    kasan   : 0xffffff8000000000 - 0xffffff9000000000   (    64 GB)
    modules : 0xffffff9000000000 - 0xffffff9004000000   (    64 MB)
    vmalloc : 0xffffff9004000000 - 0xffffffbdbfff0000   (   182 GB)



>
> BUG: KASAN: stack-out-of-bounds in find_busiest_group+0x164/0x16a0 at addr ffffffc93665bc8c
> Read of size 4 by task swapper/3/0
> page:ffffffbde6d996c0 count:0 mapcount:0 mapping:          (null) index:0x0
> flags: 0x4000000000000000()
> page dumped because: kasan: bad access detected
> CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.5.0-rc3+ #134
> Hardware name: Juno (DT)
> Call trace:
> [<ffffffc00008f8f0>] dump_backtrace+0x0/0x358
> [<ffffffc00008fc5c>] show_stack+0x14/0x20
> [<ffffffc00069d0a8>] dump_stack+0x108/0x150
> [<ffffffc0003077f8>] kasan_report_error+0x690/0x970
> [<ffffffc0003082c0>] kasan_report+0x60/0xc0
> [<ffffffc00030634c>] __asan_load4+0x64/0x80
> [<ffffffc00015f714>] find_busiest_group+0x164/0x16a0
> [<ffffffc000160ea0>] load_balance+0x250/0x1450
> [<ffffffc0001630c0>] pick_next_task_fair+0x5d0/0xb40
> [<ffffffc000f08090>] __schedule+0x460/0xbc8
> [<ffffffc000f08870>] schedule+0x78/0x208
> [<ffffffc000f092d4>] schedule_preempt_disabled+0x3c/0xd8
> [<ffffffc000172208>] cpu_startup_entry+0x160/0x4c8
> [<ffffffc0000985b8>] secondary_start_kernel+0x280/0x428
> [<0000000080082e2c>] 0x80082e2c
> Memory state around the buggy address:
>  ffffffc93665bb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  ffffffc93665bc00: f1 f1 f1 f1 00 f4 f4 f4 f2 f2 f2 f2 00 00 f1 f1
>>ffffffc93665bc80: f1 f1 00 00 00 00 f3 f3 00 f4 f4 f4 f3 f3 f3 f3
>                       ^
>  ffffffc93665bd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  ffffffc93665bd80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4
>
> --
> Catalin


From ard.biesheuvel at linaro.org  Fri Feb 12 08:46:50 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 17:46:50 +0100
Subject: [PATCH 1/2] arm64: mm: Enable CONT_SIZE aligned sections for 64k
 page kernels.
In-Reply-To: <56BE0BAB.7060502@arm.com>
References: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
 <1455293208-6763-2-git-send-email-jeremy.linton@arm.com>
 <CAKv+Gu_ViEAVN1GEDMWpJ5OYjg6BVSLTEtdus6vCCXchQ1BOjw@mail.gmail.com>
 <56BE0698.10506@arm.com>
 <CAKv+Gu--05Wn6oWEiy=43nzujNgG0=DpOB9b1zs9_jfddYXWwQ@mail.gmail.com>
 <56BE0BAB.7060502@arm.com>
Message-ID: <CAKv+Gu-CYxr9jk=U-NrfRkyBhi0M2_9G+Mqx8fYeEEkRL8GnVw@mail.gmail.com>

On 12 February 2016 at 17:43, Jeremy Linton <jeremy.linton at arm.com> wrote:
> On 02/12/2016 10:28 AM, Ard Biesheuvel wrote:
>>
>> On 12 February 2016 at 17:21, Jeremy Linton <jeremy.linton at arm.com> wrote:
>>>
>>> On 02/12/2016 10:11 AM, Ard Biesheuvel wrote:
>>>>
>>>>
>>>> On 12 February 2016 at 17:06, Jeremy Linton <jeremy.linton at arm.com>
>>>> wrote:
>>>
>>>
>>> (trimming)
>>>>>
>>>>>
>>>>>    #if defined(CONFIG_DEBUG_ALIGN_RODATA)
>>>>> -#define ALIGN_DEBUG_RO                 . = ALIGN(1<<SECTION_SHIFT);
>>>>> -#define ALIGN_DEBUG_RO_MIN(min)                ALIGN_DEBUG_RO
>>>>> +#if defined(CONFIG_ARM64_64K_PAGES)
>>>>> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(CONT_SIZE);
>>>>> +#else
>>>>> +#define ALIGN_DEBUG_RO_MIN(min)                . =
>>>>> ALIGN(SECTION_SIZE);
>>>>
>>>>
>>>>
>>>> Doesn't this align to 32 MB on 16k pages kernels?
>>>
>>>
>>>
>>> Yes, I considered whether it was more appropriate to use CONT_SIZE for
>>> 16k
>>> as well.
>>>
>>> Opinions?
>>>
>>
>> Looking at vmlinux.lds.S, I see that that would put _stext and
>> __init_begin at 32 MB aligned boundaries. making the size of the
>> kernel at least 64 MB. If I take your .rodata patch into account,
>> which adds a third instance of ALIGN_DEBUG_RO_MIN, the Image footprint
>> will rise to ~100 MB. Or am I missing something?
>>
>
> No, I think your correct. But, its an option, and it sort of depends on use
> case. In a system with 100+GB of RAM it might be useful. Not so much on a
> phone or small embedded system. I don't really see those people enabling
> ALIGN_RODATA anyway. Worse, I expect the loss of RAM efficiently going from
> 4k-16k pages in a RAM constrained system to be a pretty big hit too.
>
> I don't have any hard data one way or the other, and I don't have a strong
> opinion. Although, I suspect at the moment the potential users of 16k pages
> may tend toward the small side.
>

Well, the thing is, if you only use 2 MB of each 32 MB on average, you
gain nothing by going from contiguous pages to proper sections, since
the TLB footprint is the same. So my opinion would be to use CONT_SIZE
for 16k pages as well.


From sergei.shtylyov at cogentembedded.com  Fri Feb 12 08:47:45 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 12 Feb 2016 19:47:45 +0300
Subject: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
In-Reply-To: <20160210171455.GB17671@verge.net.au>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
 <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
 <874mdhtn7d.wl%kuninori.morimoto.gx@renesas.com>
 <20160210171455.GB17671@verge.net.au>
Message-ID: <56BE0CB1.4070408@cogentembedded.com>

On 02/10/2016 08:14 PM, Simon Horman wrote:

>> Sorry for my un-ordered response
>>
>>> Define the generic R8A7794 part of  the sound device node.
>>> This sound device  is a complex one and comprises the Audio Clock Generator
>>> (ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
>>> (SSI[U]), and Audio DMAC-Peripheral-Peripheral.
>>> It is up  to the board file to enable the device.
>>>
>>> This patch is based on the R8A7791 sound work by Kuninori Morimoto.
>>>
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>> (snip)
>>> +		rcar_sound,src {
>>> +			src1: src at 1 {
>>> +				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
>>> +				dmas = <&audma0 0x87>, <&audma0 0x9c>;
>>> +				dma-names = "rx", "tx";
>>> +			};
>>> +			src2: src at 2 {
>>> +				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
>>> +				dmas = <&audma0 0x89>, <&audma0 0x9e>;
>>> +				dma-names = "rx", "tx";
>>> +			};
>>> +			src3: src at 3 {
>>> +				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
>>> +				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
>>> +				dma-names = "rx", "tx";
>>> +			};
>>> +			src4: src at 4 {
>>> +				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
>>> +				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
>>> +				dma-names = "rx", "tx";
>>> +			};
>>> +			src5: src at 5 {
>>> +				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
>>> +				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
>>> +				dma-names = "rx", "tx";
>>> +			};
>>> +			src6: src at 6 {
>>> +				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
>>> +				dmas = <&audma0 0x91>, <&audma0 0xb4>;
>>> +				dma-names = "rx", "tx";
>>> +			};
>>> +		};
>>
>> I think this can't work correctly, because driver is assuming
>> DT has all channles (from 0). (see linux/sound/soc/sh/rcar/src.c :: rsnd_src_probe)
>> Can you adds dummy src0 with some comments ? or fix src.c driver ?
>
> I would prefer the driver to be fixed (I had a similar patchset locally
> and I found it doesn't work).

    You mean you had R8A7794 sound patch set too?

> The reason is that DT should describe
> the hardware rather than the current state of the software.

    Yes, of course. Just tell me do I have to fix the driver *before* this 
patch set is accepted?

MBR, Sergei



From gregory.clement at free-electrons.com  Fri Feb 12 08:49:00 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Feb 2016 17:49:00 +0100
Subject: [PATCH v2 1/2] ARM: mvebu: use armada-370-sata for SATA on Armada
 375
In-Reply-To: <1455121756-20804-1-git-send-email-thomas.petazzoni@free-electrons.com>
 (Thomas Petazzoni's message of "Wed, 10 Feb 2016 17:29:15 +0100")
References: <1455121756-20804-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <87io1tx4ar.fsf@free-electrons.com>

Hi Thomas,
 
 On mer., f?vr. 10 2016, Thomas Petazzoni <thomas.petazzoni at free-electrons.com> wrote:

> From: Lior Amsalem <alior at marvell.com>
>
> The Armada 375 has the same SATA IP as Armada 370 and Armada XP, which
> requires the PHY speed to be set in the LP_PHY_CTL register for SATA
> hotplug to work.
>
> Therefore, this commit updates the compatible string used to describe
> the SATA IP in Armada 375 from marvell,orion-sata to
> marvell,armada-370-sata.
>
> Fixes: 4de59085091f753d08c8429d756b46756ab94665 ("ARM: mvebu: add Device Tree description of the Armada 375 SoC")
> Cc: <stable at vger.kernel.org>
> Signed-off-by: Lior Amsalem <alior at marvell.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Applied on mvebu/dt, I renamed the patch to: " ARM: dts: armada-375: use
armada-370-sata for SATA" to unify the way we labl the dt related patch.
I also adde the reviwed-by tag from Andrew.

Thanks,

Gregory

> ---
> Changes since v1:
>  - Add Fixes: tag, and add stable@ in Cc, as suggested by Andrew Lunn.
> ---
>  arch/arm/boot/dts/armada-375.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
> index 7ccce75..cc952cf 100644
> --- a/arch/arm/boot/dts/armada-375.dtsi
> +++ b/arch/arm/boot/dts/armada-375.dtsi
> @@ -529,7 +529,7 @@
>  			};
>  
>  			sata at a0000 {
> -				compatible = "marvell,orion-sata";
> +				compatible = "marvell,armada-370-sata";
>  				reg = <0xa0000 0x5000>;
>  				interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
>  				clocks = <&gateclk 14>, <&gateclk 20>;
> -- 
> 2.6.4
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From gregory.clement at free-electrons.com  Fri Feb 12 08:50:53 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Feb 2016 17:50:53 +0100
Subject: [PATCH v2 2/2] ARM: mvebu: add NAND description to Armada 370 DB
 and Armada XP DB
In-Reply-To: <1455121756-20804-2-git-send-email-thomas.petazzoni@free-electrons.com>
 (Thomas Petazzoni's message of "Wed, 10 Feb 2016 17:29:16 +0100")
References: <1455121756-20804-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455121756-20804-2-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <87egchx47m.fsf@free-electrons.com>

Hi Thomas,
 
 On mer., f?vr. 10 2016, Thomas Petazzoni <thomas.petazzoni at free-electrons.com> wrote:

> This commit adds the Device Tree description for the 1GB NAND flash
> present in the Armada 370 DB and Armada XP DB evaluation boards from
> Marvell.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Applied on mvebu/dt, I renamed the patch to: "ARM: dts: mvebu: add NAND
description to Armada 370 DB and Armada XP DB" to unify the way we label
the dt related patch. I also added the reviewed-by tag from Andrew.

Thanks,

Gregory
> ---
> Changes since v1:
>  - Use the new MTD partitions DT binding, with all partitions grouped
>    into a 'partitions' subnode. Suggested by Andrew Lunn.
> ---
>  arch/arm/boot/dts/armada-370-db.dts | 27 +++++++++++++++++++++++++++
>  arch/arm/boot/dts/armada-xp-db.dts  | 28 ++++++++++++++++++++++++++++
>  2 files changed, 55 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
> index bb280de..2364fc5 100644
> --- a/arch/arm/boot/dts/armada-370-db.dts
> +++ b/arch/arm/boot/dts/armada-370-db.dts
> @@ -168,6 +168,33 @@
>  					spi-max-frequency = <50000000>;
>  				};
>  			};
> +
> +			nand at d0000 {
> +				status = "okay";
> +				num-cs = <1>;
> +				marvell,nand-keep-config;
> +				marvell,nand-enable-arbiter;
> +				nand-on-flash-bbt;
> +
> +				partitions {
> +					compatible = "fixed-partitions";
> +					#address-cells = <1>;
> +					#size-cells = <1>;
> +
> +					partition at 0 {
> +						label = "U-Boot";
> +						reg = <0 0x800000>;
> +					};
> +					partition at 800000 {
> +						label = "Linux";
> +						reg = <0x800000 0x800000>;
> +					};
> +					partition at 1000000 {
> +						label = "Filesystem";
> +						reg = <0x1000000 0x3f000000>;
> +					};
> +				};
> +			};
>  		};
>  
>  		pcie-controller {
> diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
> index f774101..96aaaed 100644
> --- a/arch/arm/boot/dts/armada-xp-db.dts
> +++ b/arch/arm/boot/dts/armada-xp-db.dts
> @@ -229,6 +229,34 @@
>  					spi-max-frequency = <20000000>;
>  				};
>  			};
> +
> +			nand at d0000 {
> +				status = "okay";
> +				num-cs = <1>;
> +				marvell,nand-keep-config;
> +				marvell,nand-enable-arbiter;
> +				nand-on-flash-bbt;
> +
> +				partitions {
> +					compatible = "fixed-partitions";
> +					#address-cells = <1>;
> +					#size-cells = <1>;
> +
> +					partition at 0 {
> +						label = "U-Boot";
> +						reg = <0 0x800000>;
> +					};
> +					partition at 800000 {
> +						label = "Linux";
> +						reg = <0x800000 0x800000>;
> +					};
> +					partition at 1000000 {
> +						label = "Filesystem";
> +						reg = <0x1000000 0x3f000000>;
> +
> +					};
> +				};
> +			};
>  		};
>  	};
>  };
> -- 
> 2.6.4
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From robh at kernel.org  Fri Feb 12 08:52:21 2016
From: robh at kernel.org (Rob Herring)
Date: Fri, 12 Feb 2016 10:52:21 -0600
Subject: [PATCH v2 1/2] clk: sunxi: Add support for A80 APBS clock
In-Reply-To: <1455269475-8180-2-git-send-email-wens@csie.org>
References: <1455269475-8180-1-git-send-email-wens@csie.org>
 <1455269475-8180-2-git-send-email-wens@csie.org>
Message-ID: <20160212165221.GA14697@rob-hp-laptop>

On Fri, Feb 12, 2016 at 05:31:14PM +0800, Chen-Yu Tsai wrote:
> A80's APBS clock is not the same as the APB0 clock on A23. The A80's
> is a zero-based divider, while the A23's is a power-of-two divider.
> 
> Replace the CLK_OF_DECLARE version of sun8i-a23-apb0. This also extends
> the common setup function to take div clk flags.
> 
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt |  1 +

Acked-by: Rob Herring <robh at kernel.org>

>  drivers/clk/sunxi/clk-sun8i-apb0.c                | 23 ++++++++---------------
>  2 files changed, 9 insertions(+), 15 deletions(-)



From jglauber at cavium.com  Fri Feb 12 08:55:05 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Fri, 12 Feb 2016 17:55:05 +0100
Subject: [RFC PATCH 0/7] Cavium ThunderX uncore PMU support
Message-ID: <cover.1455295032.git.jglauber@cavium.com>

Hi,

this patch series provides access to various counters on the ThunderX SOC.

For details of the implementation see patch #1.

Patches #2-7 add ther various ThunderX specific PMUs.

I did not want to put these file into arch/arm64/kernel so I added a
"uncore" directory. Maybe this should be put somewhere under drivers/
instead.

Feedback welcome!

Jan


Jan Glauber (7):
  arm64/perf: Basic uncore counter support for Cavium ThunderX
  arm64/perf: Cavium ThunderX L2C TAD uncore support
  arm64/perf: Cavium ThunderX L2C CBC uncore support
  arm64/perf: Cavium ThunderX LMC uncore support
  arm64/perf: Cavium ThunderX OCX LNE uncore support
  arm64/perf: Cavium ThunderX OCX FRC uncore support
  arm64/perf: Cavium ThunderX OCX TLK uncore support

 arch/arm64/kernel/Makefile                       |   1 +
 arch/arm64/kernel/uncore/Makefile                |   7 +
 arch/arm64/kernel/uncore/uncore_cavium.c         | 229 +++++++++
 arch/arm64/kernel/uncore/uncore_cavium.h         |  97 ++++
 arch/arm64/kernel/uncore/uncore_cavium_l2c_cbc.c | 239 +++++++++
 arch/arm64/kernel/uncore/uncore_cavium_l2c_tad.c | 600 +++++++++++++++++++++++
 arch/arm64/kernel/uncore/uncore_cavium_lmc.c     | 201 ++++++++
 arch/arm64/kernel/uncore/uncore_cavium_ocx_frc.c | 248 ++++++++++
 arch/arm64/kernel/uncore/uncore_cavium_ocx_lne.c | 270 ++++++++++
 arch/arm64/kernel/uncore/uncore_cavium_ocx_tlk.c | 366 ++++++++++++++
 10 files changed, 2258 insertions(+)
 create mode 100644 arch/arm64/kernel/uncore/Makefile
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium.c
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium.h
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium_l2c_cbc.c
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium_l2c_tad.c
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium_lmc.c
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium_ocx_frc.c
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium_ocx_lne.c
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium_ocx_tlk.c

-- 
1.9.1



From jglauber at cavium.com  Fri Feb 12 08:55:06 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Fri, 12 Feb 2016 17:55:06 +0100
Subject: [RFC PATCH 1/7] arm64/perf: Basic uncore counter support for Cavium
 ThunderX
In-Reply-To: <cover.1455295032.git.jglauber@cavium.com>
References: <cover.1455295032.git.jglauber@cavium.com>
Message-ID: <8bd93a25e069ed6428bc6c21fc53270962ccafcc.1455295032.git.jglauber@cavium.com>

Provide uncore facilities for non-CPU performance counter units.
Based on Intel/AMD uncore pmu support.

The uncore PMUs can be found under /sys/bus/event_source/devices.
All counters are exported via sysfs in the corresponding events
files under the PMU directory so the perf tool can list the event names.

There are 2 points that are special in this implementation:

1) The PMU detection solely relies on PCI device detection. If a
   matching PCI device is found the PMU is created. The code can deal
   with multiple units of the same type, e.g. more than one memory
   controller.

2) Counters are summarized across the different units of the same type,
   e.g. L2C TAD 0..7 is presented as a single counter (adding the
   values from TAD 0 to 7). Although losing the ability to read a
   single value the merged values are easier to use and yield
   enough information.

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 arch/arm64/kernel/Makefile               |   1 +
 arch/arm64/kernel/uncore/Makefile        |   1 +
 arch/arm64/kernel/uncore/uncore_cavium.c | 210 +++++++++++++++++++++++++++++++
 arch/arm64/kernel/uncore/uncore_cavium.h |  73 +++++++++++
 4 files changed, 285 insertions(+)
 create mode 100644 arch/arm64/kernel/uncore/Makefile
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium.c
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium.h

diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 83cd7e6..c2d2810 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -42,6 +42,7 @@ arm64-obj-$(CONFIG_PCI)			+= pci.o
 arm64-obj-$(CONFIG_ARMV8_DEPRECATED)	+= armv8_deprecated.o
 arm64-obj-$(CONFIG_ACPI)		+= acpi.o
 arm64-obj-$(CONFIG_PARAVIRT)		+= paravirt.o
+arm64-obj-$(CONFIG_ARCH_THUNDER)	+= uncore/
 
 obj-y					+= $(arm64-obj-y) vdso/
 obj-m					+= $(arm64-obj-m)
diff --git a/arch/arm64/kernel/uncore/Makefile b/arch/arm64/kernel/uncore/Makefile
new file mode 100644
index 0000000..b9c72c2
--- /dev/null
+++ b/arch/arm64/kernel/uncore/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ARCH_THUNDER) += uncore_cavium.o
diff --git a/arch/arm64/kernel/uncore/uncore_cavium.c b/arch/arm64/kernel/uncore/uncore_cavium.c
new file mode 100644
index 0000000..0cfcc83
--- /dev/null
+++ b/arch/arm64/kernel/uncore/uncore_cavium.c
@@ -0,0 +1,210 @@
+/*
+ * Cavium Thunder uncore PMU support. Derived from Intel and AMD uncore code.
+ *
+ * Copyright (C) 2015,2016 Cavium Inc.
+ * Author: Jan Glauber <jan.glauber at cavium.com>
+ */
+
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/cpu.h>
+#include <linux/io.h>
+#include <linux/perf_event.h>
+#include <linux/pci.h>
+
+#include <asm/cpufeature.h>
+#include <asm/cputype.h>
+
+#include "uncore_cavium.h"
+
+int thunder_uncore_version;
+
+struct thunder_uncore *event_to_thunder_uncore(struct perf_event *event)
+{
+	return NULL;
+}
+
+void thunder_uncore_read(struct perf_event *event)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	u64 prev, new = 0;
+	s64 delta;
+	int i;
+
+	/*
+	 * since we do not enable counter overflow interrupts,
+	 * we do not have to worry about prev_count changing on us
+	 */
+
+	prev = local64_read(&hwc->prev_count);
+
+	/* read counter values from all units */
+	for (i = 0; i < uncore->nr_units; i++)
+		new += readq(map_offset(hwc->event_base, uncore, i));
+
+	local64_set(&hwc->prev_count, new);
+	delta = new - prev;
+	local64_add(delta, &event->count);
+}
+
+void thunder_uncore_del(struct perf_event *event, int flags)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	int i;
+
+	event->pmu->stop(event, PERF_EF_UPDATE);
+
+	for (i = 0; i < uncore->num_counters; i++) {
+		if (cmpxchg(&uncore->events[i], event, NULL) == event)
+			break;
+	}
+	hwc->idx = -1;
+}
+
+int thunder_uncore_event_init(struct perf_event *event)
+{
+	struct hw_perf_event *hwc = &event->hw;
+	struct thunder_uncore *uncore;
+
+	if (event->attr.type != event->pmu->type)
+		return -ENOENT;
+
+	/* we do not support sampling */
+	if (is_sampling_event(event))
+		return -EINVAL;
+
+	/* counters do not have these bits */
+	if (event->attr.exclude_user	||
+	    event->attr.exclude_kernel	||
+	    event->attr.exclude_host	||
+	    event->attr.exclude_guest	||
+	    event->attr.exclude_hv	||
+	    event->attr.exclude_idle)
+		return -EINVAL;
+
+	/* and we do not enable counter overflow interrupts */
+
+	uncore = event_to_thunder_uncore(event);
+	if (!uncore)
+		return -ENODEV;
+	if (!uncore->event_valid(event->attr.config))
+		return -EINVAL;
+
+	hwc->config = event->attr.config;
+	hwc->idx = -1;
+
+	/* and we don't care about CPU */
+
+	return 0;
+}
+
+static cpumask_t thunder_active_mask;
+
+static ssize_t thunder_uncore_attr_show_cpumask(struct device *dev,
+						struct device_attribute *attr,
+						char *buf)
+{
+	cpumask_t *active_mask = &thunder_active_mask;
+
+	/*
+	 * Thunder uncore events are independent from CPUs. Provide a cpumask
+	 * nevertheless to prevent perf from adding the event per-cpu and just
+	 * set the mask to one online CPU.
+	 */
+	cpumask_set_cpu(cpumask_first(cpu_online_mask), active_mask);
+
+	return cpumap_print_to_pagebuf(true, buf, active_mask);
+}
+static DEVICE_ATTR(cpumask, S_IRUGO, thunder_uncore_attr_show_cpumask, NULL);
+
+static struct attribute *thunder_uncore_attrs[] = {
+	&dev_attr_cpumask.attr,
+	NULL,
+};
+
+struct attribute_group thunder_uncore_attr_group = {
+	.attrs = thunder_uncore_attrs,
+};
+
+ssize_t thunder_events_sysfs_show(struct device *dev,
+				  struct device_attribute *attr,
+				  char *page)
+{
+	struct perf_pmu_events_attr *pmu_attr =
+		container_of(attr, struct perf_pmu_events_attr, attr);
+
+	if (pmu_attr->event_str)
+		return sprintf(page, "%s", pmu_attr->event_str);
+
+	return 0;
+}
+
+int __init thunder_uncore_setup(struct thunder_uncore *uncore, int id,
+			 unsigned long offset, unsigned long size,
+			 struct pmu *pmu)
+{
+	struct pci_dev *pdev = NULL;
+	pci_bus_addr_t start;
+	int ret, node = 0;
+
+	/* detect PCI devices */
+	do {
+		pdev = pci_get_device(PCI_VENDOR_ID_CAVIUM, id, pdev);
+		if (!pdev)
+			break;
+		start = pci_resource_start(pdev, 0);
+		uncore->pdevs[node].pdev = pdev;
+		uncore->pdevs[node].base = start;
+		uncore->pdevs[node].map = ioremap(start + offset, size);
+		node++;
+		if (node >= MAX_NR_UNCORE_PDEVS) {
+			pr_err("reached pdev limit\n");
+			break;
+		}
+	} while (1);
+
+	if (!node)
+		return -ENODEV;
+
+	uncore->nr_units = node;
+
+	ret = perf_pmu_register(pmu, pmu->name, -1);
+	if (ret)
+		goto fail;
+
+	uncore->pmu = pmu;
+	return 0;
+
+fail:
+	for (node = 0; node < MAX_NR_UNCORE_PDEVS; node++) {
+		pdev = uncore->pdevs[node].pdev;
+		if (!pdev)
+			break;
+		iounmap(uncore->pdevs[node].map);
+		pci_dev_put(pdev);
+	}
+	return ret;
+}
+
+static int __init thunder_uncore_init(void)
+{
+	unsigned long implementor = read_cpuid_implementor();
+	unsigned long part_number = read_cpuid_part_number();
+	u32 variant;
+
+	if (implementor != ARM_CPU_IMP_CAVIUM ||
+	    part_number != CAVIUM_CPU_PART_THUNDERX)
+		return -ENODEV;
+
+	/* detect pass2 which contains different counters */
+	variant = MIDR_VARIANT(read_cpuid_id());
+	if (variant == 1)
+		thunder_uncore_version = 1;
+	pr_info("PMU version: %d\n", thunder_uncore_version);
+
+	return 0;
+}
+late_initcall(thunder_uncore_init);
diff --git a/arch/arm64/kernel/uncore/uncore_cavium.h b/arch/arm64/kernel/uncore/uncore_cavium.h
new file mode 100644
index 0000000..acd121d
--- /dev/null
+++ b/arch/arm64/kernel/uncore/uncore_cavium.h
@@ -0,0 +1,73 @@
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/cpu.h>
+#include <linux/io.h>
+#include <linux/perf_event.h>
+#include <linux/pci.h>
+
+#include <asm/cpufeature.h>
+#include <asm/cputype.h>
+
+#undef pr_fmt
+#define pr_fmt(fmt)     "thunderx_uncore: " fmt
+
+enum uncore_type {
+	NOP_TYPE,
+};
+
+extern int thunder_uncore_version;
+
+#define MAX_NR_UNCORE_PDEVS		16
+
+/* maximum number of parallel hardware counters for all uncore parts */
+#define MAX_COUNTERS			64
+
+/* generic uncore struct for different pmu types */
+struct thunder_uncore {
+	int num_counters;
+	int nr_units;
+	int type;
+	struct pmu *pmu;
+	int (*event_valid)(u64);
+	struct {
+		unsigned long base;
+		void __iomem *map;
+		struct pci_dev *pdev;
+	} pdevs[MAX_NR_UNCORE_PDEVS];
+	struct perf_event *events[MAX_COUNTERS];
+};
+
+#define EVENT_PTR(_id) (&event_attr_##_id.attr.attr)
+
+#define EVENT_ATTR(_name, _val)						   \
+static struct perf_pmu_events_attr event_attr_##_name = {		   \
+	.attr	   = __ATTR(_name, 0444, thunder_events_sysfs_show, NULL), \
+	.event_str = "event=" __stringify(_val),			   \
+};
+
+#define EVENT_ATTR_STR(_name, _str)					   \
+static struct perf_pmu_events_attr event_attr_##_name = {		   \
+	.attr	   = __ATTR(_name, 0444, thunder_events_sysfs_show, NULL), \
+	.event_str = _str,						   \
+};
+
+static inline void __iomem *map_offset(unsigned long addr,
+				struct thunder_uncore *uncore, int unit)
+{
+	return (void __iomem *) (addr + uncore->pdevs[unit].map);
+}
+
+extern struct attribute_group thunder_uncore_attr_group;
+
+/* Prototypes */
+struct thunder_uncore *event_to_thunder_uncore(struct perf_event *event);
+void thunder_uncore_del(struct perf_event *event, int flags);
+int thunder_uncore_event_init(struct perf_event *event);
+void thunder_uncore_read(struct perf_event *event);
+int thunder_uncore_setup(struct thunder_uncore *uncore, int id,
+			 unsigned long offset, unsigned long size,
+			 struct pmu *pmu);
+ssize_t thunder_events_sysfs_show(struct device *dev,
+				  struct device_attribute *attr,
+				  char *page);
-- 
1.9.1



From jglauber at cavium.com  Fri Feb 12 08:55:08 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Fri, 12 Feb 2016 17:55:08 +0100
Subject: [RFC PATCH 3/7] arm64/perf: Cavium ThunderX L2C CBC uncore support
In-Reply-To: <cover.1455295032.git.jglauber@cavium.com>
References: <cover.1455295032.git.jglauber@cavium.com>
Message-ID: <c3cf1244e1d635fa84ddb830f7dbb29bc6f88eea.1455295032.git.jglauber@cavium.com>

Support counters of the L2 cache crossbar connect.

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 arch/arm64/kernel/uncore/Makefile                |   3 +-
 arch/arm64/kernel/uncore/uncore_cavium.c         |   3 +
 arch/arm64/kernel/uncore/uncore_cavium.h         |   4 +
 arch/arm64/kernel/uncore/uncore_cavium_l2c_cbc.c | 239 +++++++++++++++++++++++
 4 files changed, 248 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium_l2c_cbc.c

diff --git a/arch/arm64/kernel/uncore/Makefile b/arch/arm64/kernel/uncore/Makefile
index 6a16caf..d52ecc9 100644
--- a/arch/arm64/kernel/uncore/Makefile
+++ b/arch/arm64/kernel/uncore/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_ARCH_THUNDER) += uncore_cavium.o		\
-			      uncore_cavium_l2c_tad.o
+			      uncore_cavium_l2c_tad.o	\
+			      uncore_cavium_l2c_cbc.o
diff --git a/arch/arm64/kernel/uncore/uncore_cavium.c b/arch/arm64/kernel/uncore/uncore_cavium.c
index b625caf..0304c60 100644
--- a/arch/arm64/kernel/uncore/uncore_cavium.c
+++ b/arch/arm64/kernel/uncore/uncore_cavium.c
@@ -24,6 +24,8 @@ struct thunder_uncore *event_to_thunder_uncore(struct perf_event *event)
 {
 	if (event->pmu->type == thunder_l2c_tad_pmu.type)
 		return thunder_uncore_l2c_tad;
+	else if (event->pmu->type == thunder_l2c_cbc_pmu.type)
+		return thunder_uncore_l2c_cbc;
 	else
 		return NULL;
 }
@@ -209,6 +211,7 @@ static int __init thunder_uncore_init(void)
 	pr_info("PMU version: %d\n", thunder_uncore_version);
 
 	thunder_uncore_l2c_tad_setup();
+	thunder_uncore_l2c_cbc_setup();
 	return 0;
 }
 late_initcall(thunder_uncore_init);
diff --git a/arch/arm64/kernel/uncore/uncore_cavium.h b/arch/arm64/kernel/uncore/uncore_cavium.h
index 90e6a2d..74f44d7 100644
--- a/arch/arm64/kernel/uncore/uncore_cavium.h
+++ b/arch/arm64/kernel/uncore/uncore_cavium.h
@@ -14,6 +14,7 @@
 
 enum uncore_type {
 	L2C_TAD_TYPE,
+	L2C_CBC_TYPE,
 };
 
 extern int thunder_uncore_version;
@@ -60,7 +61,9 @@ static inline void __iomem *map_offset(unsigned long addr,
 
 extern struct attribute_group thunder_uncore_attr_group;
 extern struct thunder_uncore *thunder_uncore_l2c_tad;
+extern struct thunder_uncore *thunder_uncore_l2c_cbc;
 extern struct pmu thunder_l2c_tad_pmu;
+extern struct pmu thunder_l2c_cbc_pmu;
 
 /* Prototypes */
 struct thunder_uncore *event_to_thunder_uncore(struct perf_event *event);
@@ -75,3 +78,4 @@ ssize_t thunder_events_sysfs_show(struct device *dev,
 				  char *page);
 
 int thunder_uncore_l2c_tad_setup(void);
+int thunder_uncore_l2c_cbc_setup(void);
diff --git a/arch/arm64/kernel/uncore/uncore_cavium_l2c_cbc.c b/arch/arm64/kernel/uncore/uncore_cavium_l2c_cbc.c
new file mode 100644
index 0000000..f1ba9be
--- /dev/null
+++ b/arch/arm64/kernel/uncore/uncore_cavium_l2c_cbc.c
@@ -0,0 +1,239 @@
+/*
+ * Cavium Thunder uncore PMU support, L2C CBC counters.
+ *
+ * Copyright 2016 Cavium Inc.
+ * Author: Jan Glauber <jan.glauber at cavium.com>
+ */
+
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/cpu.h>
+#include <linux/io.h>
+#include <linux/perf_event.h>
+#include <linux/pci.h>
+
+#include <asm/cpufeature.h>
+#include <asm/cputype.h>
+
+#include "uncore_cavium.h"
+
+#ifndef PCI_DEVICE_ID_THUNDER_L2C_CBC
+#define PCI_DEVICE_ID_THUNDER_L2C_CBC	0xa02f
+#endif
+
+#define L2C_CBC_NR_COUNTERS             16
+
+/* L2C CBC event list */
+#define L2C_CBC_EVENT_XMC0		0x00
+#define L2C_CBC_EVENT_XMD0		0x01
+#define L2C_CBC_EVENT_RSC0		0x02
+#define L2C_CBC_EVENT_RSD0		0x03
+#define L2C_CBC_EVENT_INV0		0x04
+#define L2C_CBC_EVENT_IOC0		0x05
+#define L2C_CBC_EVENT_IOR0		0x06
+
+#define L2C_CBC_EVENT_XMC1		0x08	/* 0x40 */
+#define L2C_CBC_EVENT_XMD1		0x09
+#define L2C_CBC_EVENT_RSC1		0x0a
+#define L2C_CBC_EVENT_RSD1		0x0b
+#define L2C_CBC_EVENT_INV1		0x0c
+
+#define L2C_CBC_EVENT_XMC2		0x10	/* 0x80 */
+#define L2C_CBC_EVENT_XMD2		0x11
+#define L2C_CBC_EVENT_RSC2		0x12
+#define L2C_CBC_EVENT_RSD2		0x13
+
+struct thunder_uncore *thunder_uncore_l2c_cbc;
+
+int l2c_cbc_events[L2C_CBC_NR_COUNTERS] = {
+	0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06,
+	0x08, 0x09, 0x0a, 0x0b, 0x0c,
+	0x10, 0x11, 0x12, 0x13
+};
+
+static void thunder_uncore_start(struct perf_event *event, int flags)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	u64 prev;
+	int i;
+
+	/* restore counter value divided by units into all counters */
+	if (flags & PERF_EF_RELOAD) {
+		prev = local64_read(&hwc->prev_count);
+		prev = prev / uncore->nr_units;
+		for (i = 0; i < uncore->nr_units; i++)
+			writeq(prev, map_offset(hwc->event_base, uncore, i));
+	}
+
+	hwc->state = 0;
+	perf_event_update_userpage(event);
+}
+
+static void thunder_uncore_stop(struct perf_event *event, int flags)
+{
+	struct hw_perf_event *hwc = &event->hw;
+
+	if ((flags & PERF_EF_UPDATE) && !(hwc->state & PERF_HES_UPTODATE)) {
+		thunder_uncore_read(event);
+		hwc->state |= PERF_HES_UPTODATE;
+	}
+}
+
+static int thunder_uncore_add(struct perf_event *event, int flags)
+	{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	int i;
+
+	WARN_ON_ONCE(!uncore);
+
+	/* are we already assigned? */
+	if (hwc->idx != -1 && uncore->events[hwc->idx] == event)
+		goto out;
+
+	for (i = 0; i < uncore->num_counters; i++) {
+		if (uncore->events[i] == event) {
+			hwc->idx = i;
+			goto out;
+		}
+	}
+
+	/* these counters are self-sustained so idx must match the counter! */
+	hwc->idx = -1;
+	for (i = 0; i < uncore->num_counters; i++) {
+		if (l2c_cbc_events[i] == hwc->config) {
+			if (cmpxchg(&uncore->events[i], NULL, event) == NULL) {
+				hwc->idx = i;
+				break;
+			}
+		}
+	}
+
+out:
+	if (hwc->idx == -1)
+		return -EBUSY;
+
+	hwc->event_base = hwc->config * sizeof(unsigned long long);
+
+	/* counter is not stoppable so avoiding PERF_HES_STOPPED */
+	hwc->state = PERF_HES_UPTODATE;
+
+	if (flags & PERF_EF_START)
+		thunder_uncore_start(event, 0);
+
+	return 0;
+}
+
+PMU_FORMAT_ATTR(event, "config:0-4");
+
+static struct attribute *thunder_l2c_cbc_format_attr[] = {
+	&format_attr_event.attr,
+	NULL,
+};
+
+static struct attribute_group thunder_l2c_cbc_format_group = {
+	.name = "format",
+	.attrs = thunder_l2c_cbc_format_attr,
+};
+
+EVENT_ATTR(xmc0,	L2C_CBC_EVENT_XMC0);
+EVENT_ATTR(xmd0,	L2C_CBC_EVENT_XMD0);
+EVENT_ATTR(rsc0,	L2C_CBC_EVENT_RSC0);
+EVENT_ATTR(rsd0,	L2C_CBC_EVENT_RSD0);
+EVENT_ATTR(inv0,	L2C_CBC_EVENT_INV0);
+EVENT_ATTR(ioc0,	L2C_CBC_EVENT_IOC0);
+EVENT_ATTR(ior0,	L2C_CBC_EVENT_IOR0);
+EVENT_ATTR(xmc1,	L2C_CBC_EVENT_XMC1);
+EVENT_ATTR(xmd1,	L2C_CBC_EVENT_XMD1);
+EVENT_ATTR(rsc1,	L2C_CBC_EVENT_RSC1);
+EVENT_ATTR(rsd1,	L2C_CBC_EVENT_RSD1);
+EVENT_ATTR(inv1,	L2C_CBC_EVENT_INV1);
+EVENT_ATTR(xmc2,	L2C_CBC_EVENT_XMC2);
+EVENT_ATTR(xmd2,	L2C_CBC_EVENT_XMD2);
+EVENT_ATTR(rsc2,	L2C_CBC_EVENT_RSC2);
+EVENT_ATTR(rsd2,	L2C_CBC_EVENT_RSD2);
+
+static struct attribute *thunder_l2c_cbc_events_attr[] = {
+	EVENT_PTR(xmc0),
+	EVENT_PTR(xmd0),
+	EVENT_PTR(rsc0),
+	EVENT_PTR(rsd0),
+	EVENT_PTR(inv0),
+	EVENT_PTR(ioc0),
+	EVENT_PTR(ior0),
+	EVENT_PTR(xmc1),
+	EVENT_PTR(xmd1),
+	EVENT_PTR(rsc1),
+	EVENT_PTR(rsd1),
+	EVENT_PTR(inv1),
+	EVENT_PTR(xmc2),
+	EVENT_PTR(xmd2),
+	EVENT_PTR(rsc2),
+	EVENT_PTR(rsd2),
+	NULL,
+};
+
+static struct attribute_group thunder_l2c_cbc_events_group = {
+	.name = "events",
+	.attrs = thunder_l2c_cbc_events_attr,
+};
+
+static const struct attribute_group *thunder_l2c_cbc_attr_groups[] = {
+	&thunder_uncore_attr_group,
+	&thunder_l2c_cbc_format_group,
+	&thunder_l2c_cbc_events_group,
+	NULL,
+};
+
+struct pmu thunder_l2c_cbc_pmu = {
+	.attr_groups	= thunder_l2c_cbc_attr_groups,
+	.name		= "thunder_l2c_cbc",
+	.event_init	= thunder_uncore_event_init,
+	.add		= thunder_uncore_add,
+	.del		= thunder_uncore_del,
+	.start		= thunder_uncore_start,
+	.stop		= thunder_uncore_stop,
+	.read		= thunder_uncore_read,
+};
+
+static int event_valid(u64 config)
+{
+	if (config <= L2C_CBC_EVENT_IOR0 ||
+	    (config >= L2C_CBC_EVENT_XMC1 && config <= L2C_CBC_EVENT_INV1) ||
+	    (config >= L2C_CBC_EVENT_XMC2 && config <= L2C_CBC_EVENT_RSD2))
+		return 1;
+	else
+		return 0;
+}
+
+int __init thunder_uncore_l2c_cbc_setup(void)
+{
+	int ret;
+
+	thunder_uncore_l2c_cbc = kzalloc(sizeof(struct thunder_uncore),
+					 GFP_KERNEL);
+	if (!thunder_uncore_l2c_cbc) {
+		ret = -ENOMEM;
+		goto fail_nomem;
+	}
+
+	ret = thunder_uncore_setup(thunder_uncore_l2c_cbc,
+				   PCI_DEVICE_ID_THUNDER_L2C_CBC,
+				   0,
+				   0x100,
+				   &thunder_l2c_cbc_pmu);
+	if (ret)
+		goto fail;
+
+	thunder_uncore_l2c_cbc->type = L2C_CBC_TYPE;
+	thunder_uncore_l2c_cbc->num_counters = L2C_CBC_NR_COUNTERS;
+	thunder_uncore_l2c_cbc->event_valid = event_valid;
+	return 0;
+
+fail:
+	kfree(thunder_uncore_l2c_cbc);
+fail_nomem:
+	return ret;
+}
-- 
1.9.1



From jglauber at cavium.com  Fri Feb 12 08:55:07 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Fri, 12 Feb 2016 17:55:07 +0100
Subject: [RFC PATCH 2/7] arm64/perf: Cavium ThunderX L2C TAD uncore support
In-Reply-To: <cover.1455295032.git.jglauber@cavium.com>
References: <cover.1455295032.git.jglauber@cavium.com>
Message-ID: <b347d2f6b4c0f6cc2daaab02c5a9f2dc505f5fa2.1455295032.git.jglauber@cavium.com>

Support counters of the L2 Cache tag and data units.

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 arch/arm64/kernel/uncore/Makefile                |   3 +-
 arch/arm64/kernel/uncore/uncore_cavium.c         |   6 +-
 arch/arm64/kernel/uncore/uncore_cavium.h         |   6 +-
 arch/arm64/kernel/uncore/uncore_cavium_l2c_tad.c | 600 +++++++++++++++++++++++
 4 files changed, 612 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium_l2c_tad.c

diff --git a/arch/arm64/kernel/uncore/Makefile b/arch/arm64/kernel/uncore/Makefile
index b9c72c2..6a16caf 100644
--- a/arch/arm64/kernel/uncore/Makefile
+++ b/arch/arm64/kernel/uncore/Makefile
@@ -1 +1,2 @@
-obj-$(CONFIG_ARCH_THUNDER) += uncore_cavium.o
+obj-$(CONFIG_ARCH_THUNDER) += uncore_cavium.o		\
+			      uncore_cavium_l2c_tad.o
diff --git a/arch/arm64/kernel/uncore/uncore_cavium.c b/arch/arm64/kernel/uncore/uncore_cavium.c
index 0cfcc83..b625caf 100644
--- a/arch/arm64/kernel/uncore/uncore_cavium.c
+++ b/arch/arm64/kernel/uncore/uncore_cavium.c
@@ -22,7 +22,10 @@ int thunder_uncore_version;
 
 struct thunder_uncore *event_to_thunder_uncore(struct perf_event *event)
 {
-	return NULL;
+	if (event->pmu->type == thunder_l2c_tad_pmu.type)
+		return thunder_uncore_l2c_tad;
+	else
+		return NULL;
 }
 
 void thunder_uncore_read(struct perf_event *event)
@@ -205,6 +208,7 @@ static int __init thunder_uncore_init(void)
 		thunder_uncore_version = 1;
 	pr_info("PMU version: %d\n", thunder_uncore_version);
 
+	thunder_uncore_l2c_tad_setup();
 	return 0;
 }
 late_initcall(thunder_uncore_init);
diff --git a/arch/arm64/kernel/uncore/uncore_cavium.h b/arch/arm64/kernel/uncore/uncore_cavium.h
index acd121d..90e6a2d 100644
--- a/arch/arm64/kernel/uncore/uncore_cavium.h
+++ b/arch/arm64/kernel/uncore/uncore_cavium.h
@@ -13,7 +13,7 @@
 #define pr_fmt(fmt)     "thunderx_uncore: " fmt
 
 enum uncore_type {
-	NOP_TYPE,
+	L2C_TAD_TYPE,
 };
 
 extern int thunder_uncore_version;
@@ -59,6 +59,8 @@ static inline void __iomem *map_offset(unsigned long addr,
 }
 
 extern struct attribute_group thunder_uncore_attr_group;
+extern struct thunder_uncore *thunder_uncore_l2c_tad;
+extern struct pmu thunder_l2c_tad_pmu;
 
 /* Prototypes */
 struct thunder_uncore *event_to_thunder_uncore(struct perf_event *event);
@@ -71,3 +73,5 @@ int thunder_uncore_setup(struct thunder_uncore *uncore, int id,
 ssize_t thunder_events_sysfs_show(struct device *dev,
 				  struct device_attribute *attr,
 				  char *page);
+
+int thunder_uncore_l2c_tad_setup(void);
diff --git a/arch/arm64/kernel/uncore/uncore_cavium_l2c_tad.c b/arch/arm64/kernel/uncore/uncore_cavium_l2c_tad.c
new file mode 100644
index 0000000..bf45b4a
--- /dev/null
+++ b/arch/arm64/kernel/uncore/uncore_cavium_l2c_tad.c
@@ -0,0 +1,600 @@
+/*
+ * Cavium Thunder uncore PMU support, L2C TAD counters.
+ *
+ * Copyright 2016 Cavium Inc.
+ * Author: Jan Glauber <jan.glauber at cavium.com>
+ */
+
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/cpu.h>
+#include <linux/io.h>
+#include <linux/perf_event.h>
+#include <linux/pci.h>
+
+#include <asm/cpufeature.h>
+#include <asm/cputype.h>
+
+#include "uncore_cavium.h"
+
+#ifndef PCI_DEVICE_ID_THUNDER_L2C_TAD
+#define PCI_DEVICE_ID_THUNDER_L2C_TAD	0xa02e
+#endif
+
+#define L2C_TAD_NR_COUNTERS             4
+#define L2C_TAD_CONTROL_OFFSET		0x10000
+#define L2C_TAD_COUNTER_OFFSET		0x100
+
+/* L2C TAD event list */
+#define L2C_TAD_EVENTS_DISABLED		0x00
+
+#define L2C_TAD_EVENT_L2T_HIT		0x01
+#define L2C_TAD_EVENT_L2T_MISS		0x02
+#define L2C_TAD_EVENT_L2T_NOALLOC	0x03
+#define L2C_TAD_EVENT_L2_VIC		0x04
+#define L2C_TAD_EVENT_SC_FAIL		0x05
+#define L2C_TAD_EVENT_SC_PASS		0x06
+#define L2C_TAD_EVENT_LFB_OCC		0x07
+#define L2C_TAD_EVENT_WAIT_LFB		0x08
+#define L2C_TAD_EVENT_WAIT_VAB		0x09
+
+#define L2C_TAD_EVENT_RTG_HIT		0x41
+#define L2C_TAD_EVENT_RTG_MISS		0x42
+#define L2C_TAD_EVENT_L2_RTG_VIC	0x44
+#define L2C_TAD_EVENT_L2_OPEN_OCI	0x48
+
+#define L2C_TAD_EVENT_QD0_IDX		0x80
+#define L2C_TAD_EVENT_QD0_RDAT		0x81
+#define L2C_TAD_EVENT_QD0_BNKS		0x82
+#define L2C_TAD_EVENT_QD0_WDAT		0x83
+
+#define L2C_TAD_EVENT_QD1_IDX		0x90
+#define L2C_TAD_EVENT_QD1_RDAT		0x91
+#define L2C_TAD_EVENT_QD1_BNKS		0x92
+#define L2C_TAD_EVENT_QD1_WDAT		0x93
+
+#define L2C_TAD_EVENT_QD2_IDX		0xa0
+#define L2C_TAD_EVENT_QD2_RDAT		0xa1
+#define L2C_TAD_EVENT_QD2_BNKS		0xa2
+#define L2C_TAD_EVENT_QD2_WDAT		0xa3
+
+#define L2C_TAD_EVENT_QD3_IDX		0xb0
+#define L2C_TAD_EVENT_QD3_RDAT		0xb1
+#define L2C_TAD_EVENT_QD3_BNKS		0xb2
+#define L2C_TAD_EVENT_QD3_WDAT		0xb3
+
+#define L2C_TAD_EVENT_QD4_IDX		0xc0
+#define L2C_TAD_EVENT_QD4_RDAT		0xc1
+#define L2C_TAD_EVENT_QD4_BNKS		0xc2
+#define L2C_TAD_EVENT_QD4_WDAT		0xc3
+
+#define L2C_TAD_EVENT_QD5_IDX		0xd0
+#define L2C_TAD_EVENT_QD5_RDAT		0xd1
+#define L2C_TAD_EVENT_QD5_BNKS		0xd2
+#define L2C_TAD_EVENT_QD5_WDAT		0xd3
+
+#define L2C_TAD_EVENT_QD6_IDX		0xe0
+#define L2C_TAD_EVENT_QD6_RDAT		0xe1
+#define L2C_TAD_EVENT_QD6_BNKS		0xe2
+#define L2C_TAD_EVENT_QD6_WDAT		0xe3
+
+#define L2C_TAD_EVENT_QD7_IDX		0xf0
+#define L2C_TAD_EVENT_QD7_RDAT		0xf1
+#define L2C_TAD_EVENT_QD7_BNKS		0xf2
+#define L2C_TAD_EVENT_QD7_WDAT		0xf3
+
+/* pass2 added/changed event list */
+#define L2C_TAD_EVENT_OPEN_CCPI			0x0a
+#define L2C_TAD_EVENT_LOOKUP			0x40
+#define L2C_TAD_EVENT_LOOKUP_XMC_LCL		0x41
+#define L2C_TAD_EVENT_LOOKUP_XMC_RMT		0x42
+#define L2C_TAD_EVENT_LOOKUP_MIB		0x43
+#define L2C_TAD_EVENT_LOOKUP_ALL		0x44
+#define L2C_TAD_EVENT_TAG_ALC_HIT		0x48
+#define L2C_TAD_EVENT_TAG_ALC_MISS		0x49
+#define L2C_TAD_EVENT_TAG_ALC_NALC		0x4a
+#define L2C_TAD_EVENT_TAG_NALC_HIT		0x4b
+#define L2C_TAD_EVENT_TAG_NALC_MISS		0x4c
+#define L2C_TAD_EVENT_LMC_WR			0x4e
+#define L2C_TAD_EVENT_LMC_SBLKDTY		0x4f
+#define L2C_TAD_EVENT_TAG_ALC_RTG_HIT		0x50
+#define L2C_TAD_EVENT_TAG_ALC_RTG_HITE		0x51
+#define L2C_TAD_EVENT_TAG_ALC_RTG_HITS		0x52
+#define L2C_TAD_EVENT_TAG_ALC_RTG_MISS		0x53
+#define L2C_TAD_EVENT_TAG_NALC_RTG_HIT		0x54
+#define L2C_TAD_EVENT_TAG_NALC_RTG_MISS		0x55
+#define L2C_TAD_EVENT_TAG_NALC_RTG_HITE		0x56
+#define L2C_TAD_EVENT_TAG_NALC_RTG_HITS		0x57
+#define L2C_TAD_EVENT_TAG_ALC_LCL_EVICT		0x58
+#define L2C_TAD_EVENT_TAG_ALC_LCL_CLNVIC	0x59
+#define L2C_TAD_EVENT_TAG_ALC_LCL_DTYVIC	0x5a
+#define L2C_TAD_EVENT_TAG_ALC_RMT_EVICT		0x5b
+#define L2C_TAD_EVENT_TAG_ALC_RMT_VIC		0x5c
+#define L2C_TAD_EVENT_RTG_ALC			0x5d
+#define L2C_TAD_EVENT_RTG_ALC_HIT		0x5e
+#define L2C_TAD_EVENT_RTG_ALC_HITWB		0x5f
+#define L2C_TAD_EVENT_STC_TOTAL			0x60
+#define L2C_TAD_EVENT_STC_TOTAL_FAIL		0x61
+#define L2C_TAD_EVENT_STC_RMT			0x62
+#define L2C_TAD_EVENT_STC_RMT_FAIL		0x63
+#define L2C_TAD_EVENT_STC_LCL			0x64
+#define L2C_TAD_EVENT_STC_LCL_FAIL		0x65
+#define L2C_TAD_EVENT_OCI_RTG_WAIT		0x68
+#define L2C_TAD_EVENT_OCI_FWD_CYC_HIT		0x69
+#define L2C_TAD_EVENT_OCI_FWD_RACE		0x6a
+#define L2C_TAD_EVENT_OCI_HAKS			0x6b
+#define L2C_TAD_EVENT_OCI_FLDX_TAG_E_NODAT	0x6c
+#define L2C_TAD_EVENT_OCI_FLDX_TAG_E_DAT	0x6d
+#define L2C_TAD_EVENT_OCI_RLDD			0x6e
+#define L2C_TAD_EVENT_OCI_RLDD_PEMD		0x6f
+#define L2C_TAD_EVENT_OCI_RRQ_DAT_CNT		0x70
+#define L2C_TAD_EVENT_OCI_RRQ_DAT_DMASK		0x71
+#define L2C_TAD_EVENT_OCI_RSP_DAT_CNT		0x72
+#define L2C_TAD_EVENT_OCI_RSP_DAT_DMASK		0x73
+#define L2C_TAD_EVENT_OCI_RSP_DAT_VICD_CNT	0x74
+#define L2C_TAD_EVENT_OCI_RSP_DAT_VICD_DMASK	0x75
+#define L2C_TAD_EVENT_OCI_RTG_ALC_EVICT		0x76
+#define L2C_TAD_EVENT_OCI_RTG_ALC_VIC		0x77
+
+struct thunder_uncore *thunder_uncore_l2c_tad;
+
+static void thunder_uncore_start(struct perf_event *event, int flags)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	u64 prev;
+	int i;
+
+	/* restore counter value divided by units into all counters */
+	if (flags & PERF_EF_RELOAD) {
+		prev = local64_read(&hwc->prev_count);
+		prev = prev / uncore->nr_units;
+		for (i = 0; i < uncore->nr_units; i++)
+			writeq(prev, map_offset(hwc->event_base, uncore, i));
+	}
+
+	hwc->state = 0;
+
+	/* write byte in control registers for all units */
+	for (i = 0; i < uncore->nr_units; i++)
+		writeb(hwc->config, map_offset(hwc->config_base, uncore, i));
+
+	perf_event_update_userpage(event);
+}
+
+static void thunder_uncore_stop(struct perf_event *event, int flags)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	int i;
+
+	/* reset selection value for all units */
+	for (i = 0; i < uncore->nr_units; i++)
+		writeb(L2C_TAD_EVENTS_DISABLED,
+		       map_offset(hwc->config_base, uncore, i));
+	hwc->state |= PERF_HES_STOPPED;
+
+	if ((flags & PERF_EF_UPDATE) && !(hwc->state & PERF_HES_UPTODATE)) {
+		thunder_uncore_read(event);
+		hwc->state |= PERF_HES_UPTODATE;
+	}
+}
+
+static int thunder_uncore_add(struct perf_event *event, int flags)
+	{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	int i;
+
+	WARN_ON_ONCE(!uncore);
+
+	/* are we already assigned? */
+	if (hwc->idx != -1 && uncore->events[hwc->idx] == event)
+		goto out;
+
+	for (i = 0; i < uncore->num_counters; i++) {
+		if (uncore->events[i] == event) {
+			hwc->idx = i;
+			goto out;
+		}
+	}
+
+	/* if not take the first available counter */
+	hwc->idx = -1;
+	for (i = 0; i < uncore->num_counters; i++) {
+		if (cmpxchg(&uncore->events[i], NULL, event) == NULL) {
+			hwc->idx = i;
+			break;
+		}
+	}
+out:
+	if (hwc->idx == -1)
+		return -EBUSY;
+
+	hwc->config_base = hwc->idx;
+	hwc->event_base = L2C_TAD_COUNTER_OFFSET +
+			  hwc->idx * sizeof(unsigned long long);
+	hwc->state = PERF_HES_UPTODATE | PERF_HES_STOPPED;
+
+	if (flags & PERF_EF_START)
+		thunder_uncore_start(event, PERF_EF_RELOAD);
+
+	return 0;
+}
+
+PMU_FORMAT_ATTR(event, "config:0-7");
+
+static struct attribute *thunder_l2c_tad_format_attr[] = {
+	&format_attr_event.attr,
+	NULL,
+};
+
+static struct attribute_group thunder_l2c_tad_format_group = {
+	.name = "format",
+	.attrs = thunder_l2c_tad_format_attr,
+};
+
+EVENT_ATTR(l2t_hit,	L2C_TAD_EVENT_L2T_HIT);
+EVENT_ATTR(l2t_miss,	L2C_TAD_EVENT_L2T_MISS);
+EVENT_ATTR(l2t_noalloc,	L2C_TAD_EVENT_L2T_NOALLOC);
+EVENT_ATTR(l2_vic,	L2C_TAD_EVENT_L2_VIC);
+EVENT_ATTR(sc_fail,	L2C_TAD_EVENT_SC_FAIL);
+EVENT_ATTR(sc_pass,	L2C_TAD_EVENT_SC_PASS);
+EVENT_ATTR(lfb_occ,	L2C_TAD_EVENT_LFB_OCC);
+EVENT_ATTR(wait_lfb,	L2C_TAD_EVENT_WAIT_LFB);
+EVENT_ATTR(wait_vab,	L2C_TAD_EVENT_WAIT_VAB);
+EVENT_ATTR(rtg_hit,	L2C_TAD_EVENT_RTG_HIT);
+EVENT_ATTR(rtg_miss,	L2C_TAD_EVENT_RTG_MISS);
+EVENT_ATTR(l2_rtg_vic,	L2C_TAD_EVENT_L2_RTG_VIC);
+EVENT_ATTR(l2_open_oci,	L2C_TAD_EVENT_L2_OPEN_OCI);
+
+EVENT_ATTR(qd0_idx,	L2C_TAD_EVENT_QD0_IDX);
+EVENT_ATTR(qd0_rdat,	L2C_TAD_EVENT_QD0_RDAT);
+EVENT_ATTR(qd0_bnks,	L2C_TAD_EVENT_QD0_BNKS);
+EVENT_ATTR(qd0_wdat,	L2C_TAD_EVENT_QD0_WDAT);
+
+EVENT_ATTR(qd1_idx,	L2C_TAD_EVENT_QD1_IDX);
+EVENT_ATTR(qd1_rdat,	L2C_TAD_EVENT_QD1_RDAT);
+EVENT_ATTR(qd1_bnks,	L2C_TAD_EVENT_QD1_BNKS);
+EVENT_ATTR(qd1_wdat,	L2C_TAD_EVENT_QD1_WDAT);
+
+EVENT_ATTR(qd2_idx,	L2C_TAD_EVENT_QD2_IDX);
+EVENT_ATTR(qd2_rdat,	L2C_TAD_EVENT_QD2_RDAT);
+EVENT_ATTR(qd2_bnks,	L2C_TAD_EVENT_QD2_BNKS);
+EVENT_ATTR(qd2_wdat,	L2C_TAD_EVENT_QD2_WDAT);
+
+EVENT_ATTR(qd3_idx,	L2C_TAD_EVENT_QD3_IDX);
+EVENT_ATTR(qd3_rdat,	L2C_TAD_EVENT_QD3_RDAT);
+EVENT_ATTR(qd3_bnks,	L2C_TAD_EVENT_QD3_BNKS);
+EVENT_ATTR(qd3_wdat,	L2C_TAD_EVENT_QD3_WDAT);
+
+EVENT_ATTR(qd4_idx,	L2C_TAD_EVENT_QD4_IDX);
+EVENT_ATTR(qd4_rdat,	L2C_TAD_EVENT_QD4_RDAT);
+EVENT_ATTR(qd4_bnks,	L2C_TAD_EVENT_QD4_BNKS);
+EVENT_ATTR(qd4_wdat,	L2C_TAD_EVENT_QD4_WDAT);
+
+EVENT_ATTR(qd5_idx,	L2C_TAD_EVENT_QD5_IDX);
+EVENT_ATTR(qd5_rdat,	L2C_TAD_EVENT_QD5_RDAT);
+EVENT_ATTR(qd5_bnks,	L2C_TAD_EVENT_QD5_BNKS);
+EVENT_ATTR(qd5_wdat,	L2C_TAD_EVENT_QD5_WDAT);
+
+EVENT_ATTR(qd6_idx,	L2C_TAD_EVENT_QD6_IDX);
+EVENT_ATTR(qd6_rdat,	L2C_TAD_EVENT_QD6_RDAT);
+EVENT_ATTR(qd6_bnks,	L2C_TAD_EVENT_QD6_BNKS);
+EVENT_ATTR(qd6_wdat,	L2C_TAD_EVENT_QD6_WDAT);
+
+EVENT_ATTR(qd7_idx,	L2C_TAD_EVENT_QD7_IDX);
+EVENT_ATTR(qd7_rdat,	L2C_TAD_EVENT_QD7_RDAT);
+EVENT_ATTR(qd7_bnks,	L2C_TAD_EVENT_QD7_BNKS);
+EVENT_ATTR(qd7_wdat,	L2C_TAD_EVENT_QD7_WDAT);
+
+static struct attribute *thunder_l2c_tad_events_attr[] = {
+	EVENT_PTR(l2t_hit),
+	EVENT_PTR(l2t_miss),
+	EVENT_PTR(l2t_noalloc),
+	EVENT_PTR(l2_vic),
+	EVENT_PTR(sc_fail),
+	EVENT_PTR(sc_pass),
+	EVENT_PTR(lfb_occ),
+	EVENT_PTR(wait_lfb),
+	EVENT_PTR(wait_vab),
+	EVENT_PTR(rtg_hit),
+	EVENT_PTR(rtg_miss),
+	EVENT_PTR(l2_rtg_vic),
+	EVENT_PTR(l2_open_oci),
+
+	EVENT_PTR(qd0_idx),
+	EVENT_PTR(qd0_rdat),
+	EVENT_PTR(qd0_bnks),
+	EVENT_PTR(qd0_wdat),
+
+	EVENT_PTR(qd1_idx),
+	EVENT_PTR(qd1_rdat),
+	EVENT_PTR(qd1_bnks),
+	EVENT_PTR(qd1_wdat),
+
+	EVENT_PTR(qd2_idx),
+	EVENT_PTR(qd2_rdat),
+	EVENT_PTR(qd2_bnks),
+	EVENT_PTR(qd2_wdat),
+
+	EVENT_PTR(qd3_idx),
+	EVENT_PTR(qd3_rdat),
+	EVENT_PTR(qd3_bnks),
+	EVENT_PTR(qd3_wdat),
+
+	EVENT_PTR(qd4_idx),
+	EVENT_PTR(qd4_rdat),
+	EVENT_PTR(qd4_bnks),
+	EVENT_PTR(qd4_wdat),
+
+	EVENT_PTR(qd5_idx),
+	EVENT_PTR(qd5_rdat),
+	EVENT_PTR(qd5_bnks),
+	EVENT_PTR(qd5_wdat),
+
+	EVENT_PTR(qd6_idx),
+	EVENT_PTR(qd6_rdat),
+	EVENT_PTR(qd6_bnks),
+	EVENT_PTR(qd6_wdat),
+
+	EVENT_PTR(qd7_idx),
+	EVENT_PTR(qd7_rdat),
+	EVENT_PTR(qd7_bnks),
+	EVENT_PTR(qd7_wdat),
+	NULL,
+};
+
+/* pass2 added/chanegd events */
+EVENT_ATTR(open_ccpi,		L2C_TAD_EVENT_OPEN_CCPI);
+EVENT_ATTR(lookup,		L2C_TAD_EVENT_LOOKUP);
+EVENT_ATTR(lookup_xmc_lcl,	L2C_TAD_EVENT_LOOKUP_XMC_LCL);
+EVENT_ATTR(lookup_xmc_rmt,	L2C_TAD_EVENT_LOOKUP_XMC_RMT);
+EVENT_ATTR(lookup_mib,		L2C_TAD_EVENT_LOOKUP_MIB);
+EVENT_ATTR(lookup_all,		L2C_TAD_EVENT_LOOKUP_ALL);
+
+EVENT_ATTR(tag_alc_hit,		L2C_TAD_EVENT_TAG_ALC_HIT);
+EVENT_ATTR(tag_alc_miss,	L2C_TAD_EVENT_TAG_ALC_MISS);
+EVENT_ATTR(tag_alc_nalc,	L2C_TAD_EVENT_TAG_ALC_NALC);
+EVENT_ATTR(tag_nalc_hit,	L2C_TAD_EVENT_TAG_NALC_HIT);
+EVENT_ATTR(tag_nalc_miss,	L2C_TAD_EVENT_TAG_NALC_MISS);
+
+EVENT_ATTR(lmc_wr,		L2C_TAD_EVENT_LMC_WR);
+EVENT_ATTR(lmc_sblkdty,		L2C_TAD_EVENT_LMC_SBLKDTY);
+
+EVENT_ATTR(tag_alc_rtg_hit,	L2C_TAD_EVENT_TAG_ALC_RTG_HIT);
+EVENT_ATTR(tag_alc_rtg_hite,	L2C_TAD_EVENT_TAG_ALC_RTG_HITE);
+EVENT_ATTR(tag_alc_rtg_hits,	L2C_TAD_EVENT_TAG_ALC_RTG_HITS);
+EVENT_ATTR(tag_alc_rtg_miss,	L2C_TAD_EVENT_TAG_ALC_RTG_MISS);
+EVENT_ATTR(tag_alc_nalc_rtg_hit, L2C_TAD_EVENT_TAG_NALC_RTG_HIT);
+EVENT_ATTR(tag_nalc_rtg_miss,	L2C_TAD_EVENT_TAG_NALC_RTG_MISS);
+EVENT_ATTR(tag_nalc_rtg_hite,	L2C_TAD_EVENT_TAG_NALC_RTG_HITE);
+EVENT_ATTR(tag_nalc_rtg_hits,	L2C_TAD_EVENT_TAG_NALC_RTG_HITS);
+EVENT_ATTR(tag_alc_lcl_evict,	L2C_TAD_EVENT_TAG_ALC_LCL_EVICT);
+EVENT_ATTR(tag_alc_lcl_clnvic,	L2C_TAD_EVENT_TAG_ALC_LCL_CLNVIC);
+EVENT_ATTR(tag_alc_lcl_dtyvic,	L2C_TAD_EVENT_TAG_ALC_LCL_DTYVIC);
+EVENT_ATTR(tag_alc_rmt_evict,	L2C_TAD_EVENT_TAG_ALC_RMT_EVICT);
+EVENT_ATTR(tag_alc_rmt_vic,	L2C_TAD_EVENT_TAG_ALC_RMT_VIC);
+
+EVENT_ATTR(rtg_alc,		L2C_TAD_EVENT_RTG_ALC);
+EVENT_ATTR(rtg_alc_hit,		L2C_TAD_EVENT_RTG_ALC_HIT);
+EVENT_ATTR(rtg_alc_hitwb,	L2C_TAD_EVENT_RTG_ALC_HITWB);
+
+EVENT_ATTR(stc_total,		L2C_TAD_EVENT_STC_TOTAL);
+EVENT_ATTR(stc_total_fail,	L2C_TAD_EVENT_STC_TOTAL_FAIL);
+EVENT_ATTR(stc_rmt,		L2C_TAD_EVENT_STC_RMT);
+EVENT_ATTR(stc_rmt_fail,	L2C_TAD_EVENT_STC_RMT_FAIL);
+EVENT_ATTR(stc_lcl,		L2C_TAD_EVENT_STC_LCL);
+EVENT_ATTR(stc_lcl_fail,	L2C_TAD_EVENT_STC_LCL_FAIL);
+
+EVENT_ATTR(oci_rtg_wait,	L2C_TAD_EVENT_OCI_RTG_WAIT);
+EVENT_ATTR(oci_fwd_cyc_hit,	L2C_TAD_EVENT_OCI_FWD_CYC_HIT);
+EVENT_ATTR(oci_fwd_race,	L2C_TAD_EVENT_OCI_FWD_RACE);
+EVENT_ATTR(oci_haks,		L2C_TAD_EVENT_OCI_HAKS);
+EVENT_ATTR(oci_fldx_tag_e_nodat, L2C_TAD_EVENT_OCI_FLDX_TAG_E_NODAT);
+EVENT_ATTR(oci_fldx_tag_e_dat,	L2C_TAD_EVENT_OCI_FLDX_TAG_E_DAT);
+EVENT_ATTR(oci_rldd,		L2C_TAD_EVENT_OCI_RLDD);
+EVENT_ATTR(oci_rldd_pemd,	L2C_TAD_EVENT_OCI_RLDD_PEMD);
+EVENT_ATTR(oci_rrq_dat_cnt,	L2C_TAD_EVENT_OCI_RRQ_DAT_CNT);
+EVENT_ATTR(oci_rrq_dat_dmask,	L2C_TAD_EVENT_OCI_RRQ_DAT_DMASK);
+EVENT_ATTR(oci_rsp_dat_cnt,	L2C_TAD_EVENT_OCI_RSP_DAT_CNT);
+EVENT_ATTR(oci_rsp_dat_dmaks,	L2C_TAD_EVENT_OCI_RSP_DAT_DMASK);
+EVENT_ATTR(oci_rsp_dat_vicd_cnt, L2C_TAD_EVENT_OCI_RSP_DAT_VICD_CNT);
+EVENT_ATTR(oci_rsp_dat_vicd_dmask, L2C_TAD_EVENT_OCI_RSP_DAT_VICD_DMASK);
+EVENT_ATTR(oci_rtg_alc_evict,	L2C_TAD_EVENT_OCI_RTG_ALC_EVICT);
+EVENT_ATTR(oci_rtg_alc_vic,	L2C_TAD_EVENT_OCI_RTG_ALC_VIC);
+
+static struct attribute *thunder_l2c_tad_pass2_events_attr[] = {
+	EVENT_PTR(l2t_hit),
+	EVENT_PTR(l2t_miss),
+	EVENT_PTR(l2t_noalloc),
+	EVENT_PTR(l2_vic),
+	EVENT_PTR(sc_fail),
+	EVENT_PTR(sc_pass),
+	EVENT_PTR(lfb_occ),
+	EVENT_PTR(wait_lfb),
+	EVENT_PTR(wait_vab),
+	EVENT_PTR(open_ccpi),
+
+	EVENT_PTR(lookup),
+	EVENT_PTR(lookup_xmc_lcl),
+	EVENT_PTR(lookup_xmc_rmt),
+	EVENT_PTR(lookup_mib),
+	EVENT_PTR(lookup_all),
+
+	EVENT_PTR(tag_alc_hit),
+	EVENT_PTR(tag_alc_miss),
+	EVENT_PTR(tag_alc_nalc),
+	EVENT_PTR(tag_nalc_hit),
+	EVENT_PTR(tag_nalc_miss),
+
+	EVENT_PTR(lmc_wr),
+	EVENT_PTR(lmc_sblkdty),
+
+	EVENT_PTR(tag_alc_rtg_hit),
+	EVENT_PTR(tag_alc_rtg_hite),
+	EVENT_PTR(tag_alc_rtg_hits),
+	EVENT_PTR(tag_alc_rtg_miss),
+	EVENT_PTR(tag_alc_nalc_rtg_hit),
+	EVENT_PTR(tag_nalc_rtg_miss),
+	EVENT_PTR(tag_nalc_rtg_hite),
+	EVENT_PTR(tag_nalc_rtg_hits),
+	EVENT_PTR(tag_alc_lcl_evict),
+	EVENT_PTR(tag_alc_lcl_clnvic),
+	EVENT_PTR(tag_alc_lcl_dtyvic),
+	EVENT_PTR(tag_alc_rmt_evict),
+	EVENT_PTR(tag_alc_rmt_vic),
+
+	EVENT_PTR(rtg_alc),
+	EVENT_PTR(rtg_alc_hit),
+	EVENT_PTR(rtg_alc_hitwb),
+
+	EVENT_PTR(stc_total),
+	EVENT_PTR(stc_total_fail),
+	EVENT_PTR(stc_rmt),
+	EVENT_PTR(stc_rmt_fail),
+	EVENT_PTR(stc_lcl),
+	EVENT_PTR(stc_lcl_fail),
+
+	EVENT_PTR(oci_rtg_wait),
+	EVENT_PTR(oci_fwd_cyc_hit),
+	EVENT_PTR(oci_fwd_race),
+	EVENT_PTR(oci_haks),
+	EVENT_PTR(oci_fldx_tag_e_nodat),
+	EVENT_PTR(oci_fldx_tag_e_dat),
+	EVENT_PTR(oci_rldd),
+	EVENT_PTR(oci_rldd_pemd),
+	EVENT_PTR(oci_rrq_dat_cnt),
+	EVENT_PTR(oci_rrq_dat_dmask),
+	EVENT_PTR(oci_rsp_dat_cnt),
+	EVENT_PTR(oci_rsp_dat_dmaks),
+	EVENT_PTR(oci_rsp_dat_vicd_cnt),
+	EVENT_PTR(oci_rsp_dat_vicd_dmask),
+	EVENT_PTR(oci_rtg_alc_evict),
+	EVENT_PTR(oci_rtg_alc_vic),
+
+	EVENT_PTR(qd0_idx),
+	EVENT_PTR(qd0_rdat),
+	EVENT_PTR(qd0_bnks),
+	EVENT_PTR(qd0_wdat),
+
+	EVENT_PTR(qd1_idx),
+	EVENT_PTR(qd1_rdat),
+	EVENT_PTR(qd1_bnks),
+	EVENT_PTR(qd1_wdat),
+
+	EVENT_PTR(qd2_idx),
+	EVENT_PTR(qd2_rdat),
+	EVENT_PTR(qd2_bnks),
+	EVENT_PTR(qd2_wdat),
+
+	EVENT_PTR(qd3_idx),
+	EVENT_PTR(qd3_rdat),
+	EVENT_PTR(qd3_bnks),
+	EVENT_PTR(qd3_wdat),
+
+	EVENT_PTR(qd4_idx),
+	EVENT_PTR(qd4_rdat),
+	EVENT_PTR(qd4_bnks),
+	EVENT_PTR(qd4_wdat),
+
+	EVENT_PTR(qd5_idx),
+	EVENT_PTR(qd5_rdat),
+	EVENT_PTR(qd5_bnks),
+	EVENT_PTR(qd5_wdat),
+
+	EVENT_PTR(qd6_idx),
+	EVENT_PTR(qd6_rdat),
+	EVENT_PTR(qd6_bnks),
+	EVENT_PTR(qd6_wdat),
+
+	EVENT_PTR(qd7_idx),
+	EVENT_PTR(qd7_rdat),
+	EVENT_PTR(qd7_bnks),
+	EVENT_PTR(qd7_wdat),
+	NULL,
+};
+
+static struct attribute_group thunder_l2c_tad_events_group = {
+	.name = "events",
+	.attrs = NULL,
+};
+
+static const struct attribute_group *thunder_l2c_tad_attr_groups[] = {
+	&thunder_uncore_attr_group,
+	&thunder_l2c_tad_format_group,
+	&thunder_l2c_tad_events_group,
+	NULL,
+};
+
+struct pmu thunder_l2c_tad_pmu = {
+	.attr_groups	= thunder_l2c_tad_attr_groups,
+	.name		= "thunder_l2c_tad",
+	.event_init	= thunder_uncore_event_init,
+	.add		= thunder_uncore_add,
+	.del		= thunder_uncore_del,
+	.start		= thunder_uncore_start,
+	.stop		= thunder_uncore_stop,
+	.read		= thunder_uncore_read,
+};
+
+static int event_valid(u64 config)
+{
+	if ((config > 0 && config <= L2C_TAD_EVENT_WAIT_VAB) ||
+	    config == L2C_TAD_EVENT_RTG_HIT ||
+	    config == L2C_TAD_EVENT_RTG_MISS ||
+	    config == L2C_TAD_EVENT_L2_RTG_VIC ||
+	    config == L2C_TAD_EVENT_L2_OPEN_OCI ||
+	    ((config & 0x80) && ((config & 0xf) <= 3)))
+		return 1;
+
+	if (thunder_uncore_version == 1)
+		if (config == L2C_TAD_EVENT_OPEN_CCPI ||
+		    (config >= L2C_TAD_EVENT_LOOKUP &&
+		     config <= L2C_TAD_EVENT_LOOKUP_ALL) ||
+		    (config >= L2C_TAD_EVENT_TAG_ALC_HIT &&
+		     config <= L2C_TAD_EVENT_OCI_RTG_ALC_VIC &&
+		     config != 0x4d &&
+		     config != 0x66 &&
+		     config != 0x67))
+			return 1;
+
+	return 0;
+}
+
+int __init thunder_uncore_l2c_tad_setup(void)
+{
+	int ret;
+
+	thunder_uncore_l2c_tad = kzalloc(sizeof(struct thunder_uncore),
+					 GFP_KERNEL);
+	if (!thunder_uncore_l2c_tad) {
+		ret = -ENOMEM;
+		goto fail_nomem;
+	}
+
+	if (thunder_uncore_version == 0)
+		thunder_l2c_tad_events_group.attrs = thunder_l2c_tad_events_attr;
+	else /* default */
+		thunder_l2c_tad_events_group.attrs = thunder_l2c_tad_pass2_events_attr;
+
+	ret = thunder_uncore_setup(thunder_uncore_l2c_tad,
+			   PCI_DEVICE_ID_THUNDER_L2C_TAD,
+			   L2C_TAD_CONTROL_OFFSET,
+			   L2C_TAD_COUNTER_OFFSET + L2C_TAD_NR_COUNTERS
+				* sizeof(unsigned long long),
+			   &thunder_l2c_tad_pmu);
+	if (ret)
+		goto fail;
+
+	thunder_uncore_l2c_tad->type = L2C_TAD_TYPE;
+	thunder_uncore_l2c_tad->num_counters = L2C_TAD_NR_COUNTERS;
+	thunder_uncore_l2c_tad->event_valid = event_valid;
+	return 0;
+
+fail:
+	kfree(thunder_uncore_l2c_tad);
+fail_nomem:
+	return ret;
+}
-- 
1.9.1



From jglauber at cavium.com  Fri Feb 12 08:55:09 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Fri, 12 Feb 2016 17:55:09 +0100
Subject: [RFC PATCH 4/7] arm64/perf: Cavium ThunderX LMC uncore support
In-Reply-To: <cover.1455295032.git.jglauber@cavium.com>
References: <cover.1455295032.git.jglauber@cavium.com>
Message-ID: <6b9e09796299c25e6e41b1732932e893123e0210.1455295032.git.jglauber@cavium.com>

Support counters on the DRAM controllers.

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 arch/arm64/kernel/uncore/Makefile            |   3 +-
 arch/arm64/kernel/uncore/uncore_cavium.c     |   3 +
 arch/arm64/kernel/uncore/uncore_cavium.h     |   4 +
 arch/arm64/kernel/uncore/uncore_cavium_lmc.c | 201 +++++++++++++++++++++++++++
 4 files changed, 210 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium_lmc.c

diff --git a/arch/arm64/kernel/uncore/Makefile b/arch/arm64/kernel/uncore/Makefile
index d52ecc9..81479e8 100644
--- a/arch/arm64/kernel/uncore/Makefile
+++ b/arch/arm64/kernel/uncore/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_ARCH_THUNDER) += uncore_cavium.o		\
 			      uncore_cavium_l2c_tad.o	\
-			      uncore_cavium_l2c_cbc.o
+			      uncore_cavium_l2c_cbc.o	\
+			      uncore_cavium_lmc.o
diff --git a/arch/arm64/kernel/uncore/uncore_cavium.c b/arch/arm64/kernel/uncore/uncore_cavium.c
index 0304c60..a972418 100644
--- a/arch/arm64/kernel/uncore/uncore_cavium.c
+++ b/arch/arm64/kernel/uncore/uncore_cavium.c
@@ -26,6 +26,8 @@ struct thunder_uncore *event_to_thunder_uncore(struct perf_event *event)
 		return thunder_uncore_l2c_tad;
 	else if (event->pmu->type == thunder_l2c_cbc_pmu.type)
 		return thunder_uncore_l2c_cbc;
+	else if (event->pmu->type == thunder_lmc_pmu.type)
+		return thunder_uncore_lmc;
 	else
 		return NULL;
 }
@@ -212,6 +214,7 @@ static int __init thunder_uncore_init(void)
 
 	thunder_uncore_l2c_tad_setup();
 	thunder_uncore_l2c_cbc_setup();
+	thunder_uncore_lmc_setup();
 	return 0;
 }
 late_initcall(thunder_uncore_init);
diff --git a/arch/arm64/kernel/uncore/uncore_cavium.h b/arch/arm64/kernel/uncore/uncore_cavium.h
index 74f44d7..6e3beba 100644
--- a/arch/arm64/kernel/uncore/uncore_cavium.h
+++ b/arch/arm64/kernel/uncore/uncore_cavium.h
@@ -15,6 +15,7 @@
 enum uncore_type {
 	L2C_TAD_TYPE,
 	L2C_CBC_TYPE,
+	LMC_TYPE,
 };
 
 extern int thunder_uncore_version;
@@ -62,8 +63,10 @@ static inline void __iomem *map_offset(unsigned long addr,
 extern struct attribute_group thunder_uncore_attr_group;
 extern struct thunder_uncore *thunder_uncore_l2c_tad;
 extern struct thunder_uncore *thunder_uncore_l2c_cbc;
+extern struct thunder_uncore *thunder_uncore_lmc;
 extern struct pmu thunder_l2c_tad_pmu;
 extern struct pmu thunder_l2c_cbc_pmu;
+extern struct pmu thunder_lmc_pmu;
 
 /* Prototypes */
 struct thunder_uncore *event_to_thunder_uncore(struct perf_event *event);
@@ -79,3 +82,4 @@ ssize_t thunder_events_sysfs_show(struct device *dev,
 
 int thunder_uncore_l2c_tad_setup(void);
 int thunder_uncore_l2c_cbc_setup(void);
+int thunder_uncore_lmc_setup(void);
diff --git a/arch/arm64/kernel/uncore/uncore_cavium_lmc.c b/arch/arm64/kernel/uncore/uncore_cavium_lmc.c
new file mode 100644
index 0000000..9667819
--- /dev/null
+++ b/arch/arm64/kernel/uncore/uncore_cavium_lmc.c
@@ -0,0 +1,201 @@
+/*
+ * Cavium Thunder uncore PMU support, LMC counters.
+ *
+ * Copyright 2016 Cavium Inc.
+ * Author: Jan Glauber <jan.glauber at cavium.com>
+ */
+
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/cpu.h>
+#include <linux/io.h>
+#include <linux/perf_event.h>
+#include <linux/pci.h>
+
+#include <asm/cpufeature.h>
+#include <asm/cputype.h>
+
+#include "uncore_cavium.h"
+
+#ifndef PCI_DEVICE_ID_THUNDER_LMC
+#define PCI_DEVICE_ID_THUNDER_LMC	0xa022
+#endif
+
+#define LMC_NR_COUNTERS			3
+#define LMC_PASS2_NR_COUNTERS		5
+#define LMC_MAX_NR_COUNTERS		LMC_PASS2_NR_COUNTERS
+
+/* LMC event list */
+#define LMC_EVENT_IFB_CNT		0
+#define LMC_EVENT_OPS_CNT		1
+#define LMC_EVENT_DCLK_CNT		2
+
+/* pass 2 added counters */
+#define LMC_EVENT_BANK_CONFLICT1	3
+#define LMC_EVENT_BANK_CONFLICT2	4
+
+#define LMC_COUNTER_START		LMC_EVENT_IFB_CNT
+#define LMC_COUNTER_END			(LMC_EVENT_BANK_CONFLICT2 + 8)
+
+struct thunder_uncore *thunder_uncore_lmc;
+
+int lmc_events[LMC_MAX_NR_COUNTERS] = { 0x1d0, 0x1d8, 0x1e0, 0x360, 0x368 };
+
+static void thunder_uncore_start(struct perf_event *event, int flags)
+{
+	struct hw_perf_event *hwc = &event->hw;
+
+	hwc->state = 0;
+	perf_event_update_userpage(event);
+}
+
+static void thunder_uncore_stop(struct perf_event *event, int flags)
+{
+	struct hw_perf_event *hwc = &event->hw;
+
+	if ((flags & PERF_EF_UPDATE) && !(hwc->state & PERF_HES_UPTODATE)) {
+		thunder_uncore_read(event);
+		hwc->state |= PERF_HES_UPTODATE;
+	}
+}
+
+static int thunder_uncore_add(struct perf_event *event, int flags)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	int i;
+
+	WARN_ON_ONCE(!uncore);
+
+	/* are we already assigned? */
+	if (hwc->idx != -1 && uncore->events[hwc->idx] == event)
+		goto out;
+
+	for (i = 0; i < uncore->num_counters; i++) {
+		if (uncore->events[i] == event) {
+			hwc->idx = i;
+			goto out;
+		}
+	}
+
+	/* these counters are self-sustained so idx must match the counter! */
+	hwc->idx = -1;
+	if (cmpxchg(&uncore->events[hwc->config], NULL, event) == NULL)
+		hwc->idx = i;
+
+out:
+	if (hwc->idx == -1)
+		return -EBUSY;
+
+	hwc->event_base = lmc_events[hwc->config];
+	hwc->state = PERF_HES_UPTODATE;
+
+	/* counters are read-only, so avoid PERF_EF_RELOAD */
+	if (flags & PERF_EF_START)
+		thunder_uncore_start(event, 0);
+
+	return 0;
+}
+
+PMU_FORMAT_ATTR(event, "config:0-2");
+
+static struct attribute *thunder_lmc_format_attr[] = {
+	&format_attr_event.attr,
+	NULL,
+};
+
+static struct attribute_group thunder_lmc_format_group = {
+	.name = "format",
+	.attrs = thunder_lmc_format_attr,
+};
+
+EVENT_ATTR(ifb_cnt,		LMC_EVENT_IFB_CNT);
+EVENT_ATTR(ops_cnt,		LMC_EVENT_OPS_CNT);
+EVENT_ATTR(dclk_cnt,		LMC_EVENT_DCLK_CNT);
+EVENT_ATTR(bank_conflict1,	LMC_EVENT_BANK_CONFLICT1);
+EVENT_ATTR(bank_conflict2,	LMC_EVENT_BANK_CONFLICT2);
+
+static struct attribute *thunder_lmc_events_attr[] = {
+	EVENT_PTR(ifb_cnt),
+	EVENT_PTR(ops_cnt),
+	EVENT_PTR(dclk_cnt),
+	NULL,
+};
+
+static struct attribute *thunder_lmc_pass2_events_attr[] = {
+	EVENT_PTR(ifb_cnt),
+	EVENT_PTR(ops_cnt),
+	EVENT_PTR(dclk_cnt),
+	EVENT_PTR(bank_conflict1),
+	EVENT_PTR(bank_conflict2),
+	NULL,
+};
+
+static struct attribute_group thunder_lmc_events_group = {
+	.name = "events",
+	.attrs = NULL,
+};
+
+static const struct attribute_group *thunder_lmc_attr_groups[] = {
+	&thunder_uncore_attr_group,
+	&thunder_lmc_format_group,
+	&thunder_lmc_events_group,
+	NULL,
+};
+
+struct pmu thunder_lmc_pmu = {
+	.attr_groups	= thunder_lmc_attr_groups,
+	.name		= "thunder_lmc",
+	.event_init	= thunder_uncore_event_init,
+	.add		= thunder_uncore_add,
+	.del		= thunder_uncore_del,
+	.start		= thunder_uncore_start,
+	.stop		= thunder_uncore_stop,
+	.read		= thunder_uncore_read,
+};
+
+static int event_valid(u64 config)
+{
+	if (config <= LMC_EVENT_DCLK_CNT)
+		return 1;
+
+	if (thunder_uncore_version == 1)
+		if (config == LMC_EVENT_BANK_CONFLICT1 ||
+		    config == LMC_EVENT_BANK_CONFLICT2)
+			return 1;
+	return 0;
+}
+
+int __init thunder_uncore_lmc_setup(void)
+{
+	int ret;
+
+	thunder_uncore_lmc = kzalloc(sizeof(struct thunder_uncore), GFP_KERNEL);
+	if (!thunder_uncore_lmc) {
+		ret = -ENOMEM;
+		goto fail_nomem;
+	}
+
+	thunder_lmc_events_group.attrs = (thunder_uncore_version == 1) ?
+		thunder_lmc_pass2_events_attr : thunder_lmc_events_attr;
+
+	ret = thunder_uncore_setup(thunder_uncore_lmc,
+				   PCI_DEVICE_ID_THUNDER_LMC,
+				   LMC_COUNTER_START,
+				   LMC_COUNTER_END - LMC_COUNTER_START,
+				   &thunder_lmc_pmu);
+	if (ret)
+		goto fail;
+
+	thunder_uncore_lmc->type = LMC_TYPE;
+	thunder_uncore_lmc->num_counters = (thunder_uncore_version == 1) ?
+		LMC_PASS2_NR_COUNTERS : LMC_NR_COUNTERS;
+	thunder_uncore_lmc->event_valid = event_valid;
+	return 0;
+
+fail:
+	kfree(thunder_uncore_lmc);
+fail_nomem:
+	return ret;
+}
-- 
1.9.1



From jglauber at cavium.com  Fri Feb 12 08:55:11 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Fri, 12 Feb 2016 17:55:11 +0100
Subject: [RFC PATCH 6/7] arm64/perf: Cavium ThunderX OCX FRC uncore support
In-Reply-To: <cover.1455295032.git.jglauber@cavium.com>
References: <cover.1455295032.git.jglauber@cavium.com>
Message-ID: <ab260094ba13a120ca5f306375919122ff91f906.1455295032.git.jglauber@cavium.com>

Support for the OCX alignment counters.

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 arch/arm64/kernel/uncore/Makefile                |   3 +-
 arch/arm64/kernel/uncore/uncore_cavium.c         |   3 +
 arch/arm64/kernel/uncore/uncore_cavium.h         |   4 +
 arch/arm64/kernel/uncore/uncore_cavium_ocx_frc.c | 248 +++++++++++++++++++++++
 4 files changed, 257 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium_ocx_frc.c

diff --git a/arch/arm64/kernel/uncore/Makefile b/arch/arm64/kernel/uncore/Makefile
index da39f452..752af39 100644
--- a/arch/arm64/kernel/uncore/Makefile
+++ b/arch/arm64/kernel/uncore/Makefile
@@ -2,4 +2,5 @@ obj-$(CONFIG_ARCH_THUNDER) += uncore_cavium.o		\
 			      uncore_cavium_l2c_tad.o	\
 			      uncore_cavium_l2c_cbc.o	\
 			      uncore_cavium_lmc.o	\
-			      uncore_cavium_ocx_lne.o
+			      uncore_cavium_ocx_lne.o	\
+			      uncore_cavium_ocx_frc.o
diff --git a/arch/arm64/kernel/uncore/uncore_cavium.c b/arch/arm64/kernel/uncore/uncore_cavium.c
index f2fbdea..9fed1d6 100644
--- a/arch/arm64/kernel/uncore/uncore_cavium.c
+++ b/arch/arm64/kernel/uncore/uncore_cavium.c
@@ -30,6 +30,8 @@ struct thunder_uncore *event_to_thunder_uncore(struct perf_event *event)
 		return thunder_uncore_lmc;
 	else if (event->pmu->type == thunder_ocx_lne_pmu.type)
 		return thunder_uncore_ocx_lne;
+	else if (event->pmu->type == thunder_ocx_frc_pmu.type)
+		return thunder_uncore_ocx_frc;
 	else
 		return NULL;
 }
@@ -218,6 +220,7 @@ static int __init thunder_uncore_init(void)
 	thunder_uncore_l2c_cbc_setup();
 	thunder_uncore_lmc_setup();
 	thunder_uncore_ocx_lne_setup();
+	thunder_uncore_ocx_frc_setup();
 	return 0;
 }
 late_initcall(thunder_uncore_init);
diff --git a/arch/arm64/kernel/uncore/uncore_cavium.h b/arch/arm64/kernel/uncore/uncore_cavium.h
index b9bcb42..07bd4f4 100644
--- a/arch/arm64/kernel/uncore/uncore_cavium.h
+++ b/arch/arm64/kernel/uncore/uncore_cavium.h
@@ -17,6 +17,7 @@ enum uncore_type {
 	L2C_CBC_TYPE,
 	LMC_TYPE,
 	OCX_LNE_TYPE,
+	OCX_FRC_TYPE,
 };
 
 extern int thunder_uncore_version;
@@ -66,10 +67,12 @@ extern struct thunder_uncore *thunder_uncore_l2c_tad;
 extern struct thunder_uncore *thunder_uncore_l2c_cbc;
 extern struct thunder_uncore *thunder_uncore_lmc;
 extern struct thunder_uncore *thunder_uncore_ocx_lne;
+extern struct thunder_uncore *thunder_uncore_ocx_frc;
 extern struct pmu thunder_l2c_tad_pmu;
 extern struct pmu thunder_l2c_cbc_pmu;
 extern struct pmu thunder_lmc_pmu;
 extern struct pmu thunder_ocx_lne_pmu;
+extern struct pmu thunder_ocx_frc_pmu;
 
 /* Prototypes */
 struct thunder_uncore *event_to_thunder_uncore(struct perf_event *event);
@@ -87,3 +90,4 @@ int thunder_uncore_l2c_tad_setup(void);
 int thunder_uncore_l2c_cbc_setup(void);
 int thunder_uncore_lmc_setup(void);
 int thunder_uncore_ocx_lne_setup(void);
+int thunder_uncore_ocx_frc_setup(void);
diff --git a/arch/arm64/kernel/uncore/uncore_cavium_ocx_frc.c b/arch/arm64/kernel/uncore/uncore_cavium_ocx_frc.c
new file mode 100644
index 0000000..7f62019
--- /dev/null
+++ b/arch/arm64/kernel/uncore/uncore_cavium_ocx_frc.c
@@ -0,0 +1,248 @@
+/*
+ * Cavium Thunder uncore PMU support, OCX FRC counters.
+ *
+ * Copyright 2016 Cavium Inc.
+ * Author: Jan Glauber <jan.glauber at cavium.com>
+ */
+
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/cpu.h>
+#include <linux/io.h>
+#include <linux/perf_event.h>
+#include <linux/pci.h>
+
+#include <asm/cpufeature.h>
+#include <asm/cputype.h>
+
+#include "uncore_cavium.h"
+
+#ifndef PCI_DEVICE_ID_THUNDER_OCX
+#define PCI_DEVICE_ID_THUNDER_OCX		0xa013
+#endif
+
+#define OCX_FRC_NR_COUNTERS			4
+#define OCX_FRC_NR_UNITS			6
+#define OCX_FRC_UNIT_OFFSET			0x8
+#define OCX_FRC_COUNTER_OFFSET			0xfa00
+#define OCX_FRC_CONTROL_OFFSET			0xff00
+#define OCX_FRC_COUNTER_INC			0x80
+#define OCX_FRC_EVENT_MASK			0x1fffff
+#define OCX_FRC_STAT_CONTROL_BIT		37
+
+/* OCX FRC event list */
+#define OCX_FRC_EVENT_STAT0			0x0
+#define OCX_FRC_EVENT_STAT1			0x1
+#define OCX_FRC_EVENT_STAT2			0x2
+#define OCX_FRC_EVENT_STAT3			0x3
+
+struct thunder_uncore *thunder_uncore_ocx_frc;
+
+static inline void __iomem *map_offset_ocx_frc(unsigned long addr,
+				struct thunder_uncore *uncore, int unit)
+{
+	return (void __iomem *) (addr +
+				 uncore->pdevs[0].map +
+				 unit * OCX_FRC_UNIT_OFFSET);
+}
+
+/*
+ * Summarize counters across all FRC's. Different from the other uncore
+ * PMUs because all FRC's are on one PCI device.
+ */
+static void thunder_uncore_read_ocx_frc(struct perf_event *event)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	u64 prev, new, sum = 0;
+	s64 delta;
+	int i;
+
+	/*
+	 * since we do not enable counter overflow interrupts,
+	 * we do not have to worry about prev_count changing on us
+	 */
+
+	prev = local64_read(&hwc->prev_count);
+
+	/* read counter values from all units */
+	for (i = 0; i < OCX_FRC_NR_UNITS; i++) {
+		new = readq(map_offset_ocx_frc(hwc->event_base, uncore, i));
+		sum += new & OCX_FRC_EVENT_MASK;
+	}
+
+	local64_set(&hwc->prev_count, new);
+	delta = new - prev;
+	local64_add(delta, &event->count);
+}
+
+static void thunder_uncore_start(struct perf_event *event, int flags)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	u64 prev, ctl;
+	int i;
+
+	/* restore counter value divided by units into all counters */
+	if (flags & PERF_EF_RELOAD) {
+		prev = local64_read(&hwc->prev_count);
+		prev = (prev / uncore->nr_units) & OCX_FRC_EVENT_MASK;
+		for (i = 0; i < uncore->nr_units; i++)
+			writeq(prev, map_offset_ocx_frc(hwc->event_base,
+							uncore, i));
+	}
+
+
+	hwc->state = 0;
+
+	/* enable counters */
+	ctl = readq(hwc->config_base + uncore->pdevs[0].map);
+	ctl |= 1ULL << OCX_FRC_STAT_CONTROL_BIT;
+	writeq(ctl, hwc->config_base + uncore->pdevs[0].map);
+
+	perf_event_update_userpage(event);
+}
+
+static void thunder_uncore_stop(struct perf_event *event, int flags)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	u64 ctl;
+
+	/* disable counters */
+	ctl = readq(hwc->config_base + uncore->pdevs[0].map);
+	ctl &= ~(1ULL << OCX_FRC_STAT_CONTROL_BIT);
+	writeq(ctl, hwc->config_base + uncore->pdevs[0].map);
+
+	hwc->state |= PERF_HES_STOPPED;
+
+	if ((flags & PERF_EF_UPDATE) && !(hwc->state & PERF_HES_UPTODATE)) {
+		thunder_uncore_read_ocx_frc(event);
+		hwc->state |= PERF_HES_UPTODATE;
+	}
+}
+
+static int thunder_uncore_add(struct perf_event *event, int flags)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	int i;
+
+	WARN_ON_ONCE(!uncore);
+
+	/* are we already assigned? */
+	if (hwc->idx != -1 && uncore->events[hwc->idx] == event)
+		goto out;
+
+	for (i = 0; i < uncore->num_counters; i++) {
+		if (uncore->events[i] == event) {
+			hwc->idx = i;
+			goto out;
+		}
+	}
+
+	/* counters are 1:1 */
+	hwc->idx = -1;
+	if (cmpxchg(&uncore->events[hwc->config], NULL, event) == NULL)
+		hwc->idx = hwc->config;
+
+out:
+	if (hwc->idx == -1)
+		return -EBUSY;
+
+	hwc->config_base = OCX_FRC_CONTROL_OFFSET - OCX_FRC_COUNTER_OFFSET;
+	hwc->event_base = hwc->idx * OCX_FRC_COUNTER_INC;
+	hwc->state = PERF_HES_UPTODATE | PERF_HES_STOPPED;
+
+	if (flags & PERF_EF_START)
+		thunder_uncore_start(event, PERF_EF_RELOAD);
+
+	return 0;
+}
+
+PMU_FORMAT_ATTR(event, "config:0-1");
+
+static struct attribute *thunder_ocx_frc_format_attr[] = {
+	&format_attr_event.attr,
+	NULL,
+};
+
+static struct attribute_group thunder_ocx_frc_format_group = {
+	.name = "format",
+	.attrs = thunder_ocx_frc_format_attr,
+};
+
+EVENT_ATTR(stat0,	OCX_FRC_EVENT_STAT0);
+EVENT_ATTR(stat1,	OCX_FRC_EVENT_STAT1);
+EVENT_ATTR(stat2,	OCX_FRC_EVENT_STAT2);
+EVENT_ATTR(stat3,	OCX_FRC_EVENT_STAT3);
+
+static struct attribute *thunder_ocx_frc_events_attr[] = {
+	EVENT_PTR(stat0),
+	EVENT_PTR(stat1),
+	EVENT_PTR(stat2),
+	EVENT_PTR(stat3),
+	NULL,
+};
+
+static struct attribute_group thunder_ocx_frc_events_group = {
+	.name = "events",
+	.attrs = thunder_ocx_frc_events_attr,
+};
+
+static const struct attribute_group *thunder_ocx_frc_attr_groups[] = {
+	&thunder_uncore_attr_group,
+	&thunder_ocx_frc_format_group,
+	&thunder_ocx_frc_events_group,
+	NULL,
+};
+
+struct pmu thunder_ocx_frc_pmu = {
+	.attr_groups	= thunder_ocx_frc_attr_groups,
+	.name		= "thunder_ocx_frc",
+	.event_init	= thunder_uncore_event_init,
+	.add		= thunder_uncore_add,
+	.del		= thunder_uncore_del,
+	.start		= thunder_uncore_start,
+	.stop		= thunder_uncore_stop,
+	.read		= thunder_uncore_read_ocx_frc,
+};
+
+static int event_valid(u64 config)
+{
+	if (config <= OCX_FRC_EVENT_STAT3)
+		return 1;
+	else
+		return 0;
+}
+
+int __init thunder_uncore_ocx_frc_setup(void)
+{
+	int ret;
+
+	thunder_uncore_ocx_frc = kzalloc(sizeof(struct thunder_uncore),
+					 GFP_KERNEL);
+	if (!thunder_uncore_ocx_frc) {
+		ret = -ENOMEM;
+		goto fail_nomem;
+	}
+
+	ret = thunder_uncore_setup(thunder_uncore_ocx_frc,
+			PCI_DEVICE_ID_THUNDER_OCX, OCX_FRC_COUNTER_OFFSET,
+			OCX_FRC_CONTROL_OFFSET - OCX_FRC_COUNTER_OFFSET
+				+ sizeof(unsigned long long),
+			&thunder_ocx_frc_pmu);
+	if (ret)
+		goto fail;
+
+	thunder_uncore_ocx_frc->type = OCX_FRC_TYPE;
+	thunder_uncore_ocx_frc->num_counters = OCX_FRC_NR_COUNTERS;
+	thunder_uncore_ocx_frc->event_valid = event_valid;
+	return 0;
+
+fail:
+	kfree(thunder_uncore_ocx_frc);
+fail_nomem:
+	return ret;
+}
-- 
1.9.1



From jglauber at cavium.com  Fri Feb 12 08:55:10 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Fri, 12 Feb 2016 17:55:10 +0100
Subject: [RFC PATCH 5/7] arm64/perf: Cavium ThunderX OCX LNE uncore support
In-Reply-To: <cover.1455295032.git.jglauber@cavium.com>
References: <cover.1455295032.git.jglauber@cavium.com>
Message-ID: <19008f588c058ef63ed42cc5b8b242d3e2565622.1455295032.git.jglauber@cavium.com>

Support counters for the CCPI Interface controller (OCX) lanes.

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 arch/arm64/kernel/uncore/Makefile                |   3 +-
 arch/arm64/kernel/uncore/uncore_cavium.c         |   3 +
 arch/arm64/kernel/uncore/uncore_cavium.h         |   4 +
 arch/arm64/kernel/uncore/uncore_cavium_ocx_lne.c | 270 +++++++++++++++++++++++
 4 files changed, 279 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium_ocx_lne.c

diff --git a/arch/arm64/kernel/uncore/Makefile b/arch/arm64/kernel/uncore/Makefile
index 81479e8..da39f452 100644
--- a/arch/arm64/kernel/uncore/Makefile
+++ b/arch/arm64/kernel/uncore/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_ARCH_THUNDER) += uncore_cavium.o		\
 			      uncore_cavium_l2c_tad.o	\
 			      uncore_cavium_l2c_cbc.o	\
-			      uncore_cavium_lmc.o
+			      uncore_cavium_lmc.o	\
+			      uncore_cavium_ocx_lne.o
diff --git a/arch/arm64/kernel/uncore/uncore_cavium.c b/arch/arm64/kernel/uncore/uncore_cavium.c
index a972418..f2fbdea 100644
--- a/arch/arm64/kernel/uncore/uncore_cavium.c
+++ b/arch/arm64/kernel/uncore/uncore_cavium.c
@@ -28,6 +28,8 @@ struct thunder_uncore *event_to_thunder_uncore(struct perf_event *event)
 		return thunder_uncore_l2c_cbc;
 	else if (event->pmu->type == thunder_lmc_pmu.type)
 		return thunder_uncore_lmc;
+	else if (event->pmu->type == thunder_ocx_lne_pmu.type)
+		return thunder_uncore_ocx_lne;
 	else
 		return NULL;
 }
@@ -215,6 +217,7 @@ static int __init thunder_uncore_init(void)
 	thunder_uncore_l2c_tad_setup();
 	thunder_uncore_l2c_cbc_setup();
 	thunder_uncore_lmc_setup();
+	thunder_uncore_ocx_lne_setup();
 	return 0;
 }
 late_initcall(thunder_uncore_init);
diff --git a/arch/arm64/kernel/uncore/uncore_cavium.h b/arch/arm64/kernel/uncore/uncore_cavium.h
index 6e3beba..b9bcb42 100644
--- a/arch/arm64/kernel/uncore/uncore_cavium.h
+++ b/arch/arm64/kernel/uncore/uncore_cavium.h
@@ -16,6 +16,7 @@ enum uncore_type {
 	L2C_TAD_TYPE,
 	L2C_CBC_TYPE,
 	LMC_TYPE,
+	OCX_LNE_TYPE,
 };
 
 extern int thunder_uncore_version;
@@ -64,9 +65,11 @@ extern struct attribute_group thunder_uncore_attr_group;
 extern struct thunder_uncore *thunder_uncore_l2c_tad;
 extern struct thunder_uncore *thunder_uncore_l2c_cbc;
 extern struct thunder_uncore *thunder_uncore_lmc;
+extern struct thunder_uncore *thunder_uncore_ocx_lne;
 extern struct pmu thunder_l2c_tad_pmu;
 extern struct pmu thunder_l2c_cbc_pmu;
 extern struct pmu thunder_lmc_pmu;
+extern struct pmu thunder_ocx_lne_pmu;
 
 /* Prototypes */
 struct thunder_uncore *event_to_thunder_uncore(struct perf_event *event);
@@ -83,3 +86,4 @@ ssize_t thunder_events_sysfs_show(struct device *dev,
 int thunder_uncore_l2c_tad_setup(void);
 int thunder_uncore_l2c_cbc_setup(void);
 int thunder_uncore_lmc_setup(void);
+int thunder_uncore_ocx_lne_setup(void);
diff --git a/arch/arm64/kernel/uncore/uncore_cavium_ocx_lne.c b/arch/arm64/kernel/uncore/uncore_cavium_ocx_lne.c
new file mode 100644
index 0000000..c2981b9
--- /dev/null
+++ b/arch/arm64/kernel/uncore/uncore_cavium_ocx_lne.c
@@ -0,0 +1,270 @@
+/*
+ * Cavium Thunder uncore PMU support, OCX LNE counters.
+ *
+ * Copyright 2016 Cavium Inc.
+ * Author: Jan Glauber <jan.glauber at cavium.com>
+ */
+
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/cpu.h>
+#include <linux/io.h>
+#include <linux/perf_event.h>
+#include <linux/pci.h>
+
+#include <asm/cpufeature.h>
+#include <asm/cputype.h>
+
+#include "uncore_cavium.h"
+
+#ifndef PCI_DEVICE_ID_THUNDER_OCX
+#define PCI_DEVICE_ID_THUNDER_OCX		0xa013
+#endif
+
+#define OCX_LNE_NR_COUNTERS			15
+#define OCX_LNE_NR_UNITS			24
+#define OCX_LNE_UNIT_OFFSET			0x100
+#define OCX_LNE_CONTROL_OFFSET			0x8000
+#define OCX_LNE_COUNTER_OFFSET			0x40
+
+#define OCX_LNE_STAT_DISABLE			0
+#define OCX_LNE_STAT_ENABLE			1
+
+/* OCX LNE event list */
+#define OCX_LNE_EVENT_STAT00			0x00
+#define OCX_LNE_EVENT_STAT01			0x01
+#define OCX_LNE_EVENT_STAT02			0x02
+#define OCX_LNE_EVENT_STAT03			0x03
+#define OCX_LNE_EVENT_STAT04			0x04
+#define OCX_LNE_EVENT_STAT05			0x05
+#define OCX_LNE_EVENT_STAT06			0x06
+#define OCX_LNE_EVENT_STAT07			0x07
+#define OCX_LNE_EVENT_STAT08			0x08
+#define OCX_LNE_EVENT_STAT09			0x09
+#define OCX_LNE_EVENT_STAT10			0x0a
+#define OCX_LNE_EVENT_STAT11			0x0b
+#define OCX_LNE_EVENT_STAT12			0x0c
+#define OCX_LNE_EVENT_STAT13			0x0d
+#define OCX_LNE_EVENT_STAT14			0x0e
+
+struct thunder_uncore *thunder_uncore_ocx_lne;
+
+static inline void __iomem *map_offset_ocx_lne(unsigned long addr,
+				struct thunder_uncore *uncore, int unit)
+{
+	return (void __iomem *) (addr +
+				 uncore->pdevs[0].map +
+				 unit * OCX_LNE_UNIT_OFFSET);
+}
+
+/*
+ * Summarize counters across all LNE's. Different from the other uncore
+ * PMUs because all LNE's are on one PCI device.
+ */
+static void thunder_uncore_read_ocx_lne(struct perf_event *event)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	u64 prev, new = 0;
+	s64 delta;
+	int i;
+
+	/*
+	 * since we do not enable counter overflow interrupts,
+	 * we do not have to worry about prev_count changing on us
+	 */
+
+	prev = local64_read(&hwc->prev_count);
+
+	/* read counter values from all units */
+	for (i = 0; i < OCX_LNE_NR_UNITS; i++)
+		new += readq(map_offset_ocx_lne(hwc->event_base, uncore, i));
+
+	local64_set(&hwc->prev_count, new);
+	delta = new - prev;
+	local64_add(delta, &event->count);
+}
+
+static void thunder_uncore_start(struct perf_event *event, int flags)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	int i;
+
+	hwc->state = 0;
+
+	/* enable counters on all units */
+	for (i = 0; i < OCX_LNE_NR_UNITS; i++)
+		writeb(OCX_LNE_STAT_ENABLE,
+		       map_offset_ocx_lne(hwc->config_base, uncore, i));
+
+	perf_event_update_userpage(event);
+}
+
+static void thunder_uncore_stop(struct perf_event *event, int flags)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	int i;
+
+	/* disable counters on all units */
+	for (i = 0; i < OCX_LNE_NR_UNITS; i++)
+		writeb(OCX_LNE_STAT_DISABLE,
+		       map_offset_ocx_lne(hwc->config_base, uncore, i));
+	hwc->state |= PERF_HES_STOPPED;
+
+	if ((flags & PERF_EF_UPDATE) && !(hwc->state & PERF_HES_UPTODATE)) {
+		thunder_uncore_read_ocx_lne(event);
+		hwc->state |= PERF_HES_UPTODATE;
+	}
+}
+
+static int thunder_uncore_add(struct perf_event *event, int flags)
+	{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	int i;
+
+	WARN_ON_ONCE(!uncore);
+
+	/* are we already assigned? */
+	if (hwc->idx != -1 && uncore->events[hwc->idx] == event)
+		goto out;
+
+	for (i = 0; i < uncore->num_counters; i++) {
+		if (uncore->events[i] == event) {
+			hwc->idx = i;
+			goto out;
+		}
+	}
+
+	/* counters are 1:1 */
+	hwc->idx = -1;
+	if (cmpxchg(&uncore->events[hwc->config], NULL, event) == NULL)
+		hwc->idx = hwc->config;
+
+out:
+	if (hwc->idx == -1)
+		return -EBUSY;
+
+	hwc->config_base = 0;
+	hwc->event_base = OCX_LNE_COUNTER_OFFSET +
+			hwc->idx * sizeof(unsigned long long);
+	hwc->state = PERF_HES_UPTODATE | PERF_HES_STOPPED;
+
+	if (flags & PERF_EF_START)
+		/* counters are read-only, so avoid PERF_EF_RELOAD */
+		thunder_uncore_start(event, 0);
+
+	return 0;
+}
+
+PMU_FORMAT_ATTR(event, "config:0-3");
+
+static struct attribute *thunder_ocx_lne_format_attr[] = {
+	&format_attr_event.attr,
+	NULL,
+};
+
+static struct attribute_group thunder_ocx_lne_format_group = {
+	.name = "format",
+	.attrs = thunder_ocx_lne_format_attr,
+};
+
+EVENT_ATTR(stat00,	OCX_LNE_EVENT_STAT00);
+EVENT_ATTR(stat01,	OCX_LNE_EVENT_STAT01);
+EVENT_ATTR(stat02,	OCX_LNE_EVENT_STAT02);
+EVENT_ATTR(stat03,	OCX_LNE_EVENT_STAT03);
+EVENT_ATTR(stat04,	OCX_LNE_EVENT_STAT04);
+EVENT_ATTR(stat05,	OCX_LNE_EVENT_STAT05);
+EVENT_ATTR(stat06,	OCX_LNE_EVENT_STAT06);
+EVENT_ATTR(stat07,	OCX_LNE_EVENT_STAT07);
+EVENT_ATTR(stat08,	OCX_LNE_EVENT_STAT08);
+EVENT_ATTR(stat09,	OCX_LNE_EVENT_STAT09);
+EVENT_ATTR(stat10,	OCX_LNE_EVENT_STAT10);
+EVENT_ATTR(stat11,	OCX_LNE_EVENT_STAT11);
+EVENT_ATTR(stat12,	OCX_LNE_EVENT_STAT12);
+EVENT_ATTR(stat13,	OCX_LNE_EVENT_STAT13);
+EVENT_ATTR(stat14,	OCX_LNE_EVENT_STAT14);
+
+static struct attribute *thunder_ocx_lne_events_attr[] = {
+	EVENT_PTR(stat00),
+	EVENT_PTR(stat01),
+	EVENT_PTR(stat02),
+	EVENT_PTR(stat03),
+	EVENT_PTR(stat04),
+	EVENT_PTR(stat05),
+	EVENT_PTR(stat06),
+	EVENT_PTR(stat07),
+	EVENT_PTR(stat08),
+	EVENT_PTR(stat09),
+	EVENT_PTR(stat10),
+	EVENT_PTR(stat11),
+	EVENT_PTR(stat12),
+	EVENT_PTR(stat13),
+	EVENT_PTR(stat14),
+	NULL,
+};
+
+static struct attribute_group thunder_ocx_lne_events_group = {
+	.name = "events",
+	.attrs = thunder_ocx_lne_events_attr,
+};
+
+static const struct attribute_group *thunder_ocx_lne_attr_groups[] = {
+	&thunder_uncore_attr_group,
+	&thunder_ocx_lne_format_group,
+	&thunder_ocx_lne_events_group,
+	NULL,
+};
+
+struct pmu thunder_ocx_lne_pmu = {
+	.attr_groups	= thunder_ocx_lne_attr_groups,
+	.name		= "thunder_ocx_lne",
+	.event_init	= thunder_uncore_event_init,
+	.add		= thunder_uncore_add,
+	.del		= thunder_uncore_del,
+	.start		= thunder_uncore_start,
+	.stop		= thunder_uncore_stop,
+	.read		= thunder_uncore_read_ocx_lne,
+};
+
+static int event_valid(u64 config)
+{
+	if (config <= OCX_LNE_EVENT_STAT14)
+		return 1;
+	else
+		return 0;
+}
+
+int __init thunder_uncore_ocx_lne_setup(void)
+{
+	int ret;
+
+	thunder_uncore_ocx_lne = kzalloc(sizeof(struct thunder_uncore),
+					 GFP_KERNEL);
+	if (!thunder_uncore_ocx_lne) {
+		ret = -ENOMEM;
+		goto fail_nomem;
+	}
+
+	ret = thunder_uncore_setup(thunder_uncore_ocx_lne,
+				   PCI_DEVICE_ID_THUNDER_OCX,
+				   OCX_LNE_CONTROL_OFFSET,
+				   OCX_LNE_COUNTER_OFFSET + OCX_LNE_NR_COUNTERS
+					* sizeof(unsigned long long),
+				   &thunder_ocx_lne_pmu);
+	if (ret)
+		goto fail;
+
+	thunder_uncore_ocx_lne->type = OCX_LNE_TYPE;
+	thunder_uncore_ocx_lne->num_counters = OCX_LNE_NR_COUNTERS;
+	thunder_uncore_ocx_lne->event_valid = event_valid;
+	return 0;
+
+fail:
+	kfree(thunder_uncore_ocx_lne);
+fail_nomem:
+	return ret;
+}
-- 
1.9.1



From jglauber at cavium.com  Fri Feb 12 08:55:12 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Fri, 12 Feb 2016 17:55:12 +0100
Subject: [RFC PATCH 7/7] arm64/perf: Cavium ThunderX OCX TLK uncore support
In-Reply-To: <cover.1455295032.git.jglauber@cavium.com>
References: <cover.1455295032.git.jglauber@cavium.com>
Message-ID: <662156d87b85c7f9bc76c6490297b63edd23ca29.1455295032.git.jglauber@cavium.com>

Support for the OCX transmit link counters.

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 arch/arm64/kernel/uncore/Makefile                |   3 +-
 arch/arm64/kernel/uncore/uncore_cavium.c         |   3 +
 arch/arm64/kernel/uncore/uncore_cavium.h         |   4 +
 arch/arm64/kernel/uncore/uncore_cavium_ocx_tlk.c | 366 +++++++++++++++++++++++
 4 files changed, 375 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/kernel/uncore/uncore_cavium_ocx_tlk.c

diff --git a/arch/arm64/kernel/uncore/Makefile b/arch/arm64/kernel/uncore/Makefile
index 752af39..a267800 100644
--- a/arch/arm64/kernel/uncore/Makefile
+++ b/arch/arm64/kernel/uncore/Makefile
@@ -3,4 +3,5 @@ obj-$(CONFIG_ARCH_THUNDER) += uncore_cavium.o		\
 			      uncore_cavium_l2c_cbc.o	\
 			      uncore_cavium_lmc.o	\
 			      uncore_cavium_ocx_lne.o	\
-			      uncore_cavium_ocx_frc.o
+			      uncore_cavium_ocx_frc.o	\
+			      uncore_cavium_ocx_tlk.o
diff --git a/arch/arm64/kernel/uncore/uncore_cavium.c b/arch/arm64/kernel/uncore/uncore_cavium.c
index 9fed1d6..e2edb7a4 100644
--- a/arch/arm64/kernel/uncore/uncore_cavium.c
+++ b/arch/arm64/kernel/uncore/uncore_cavium.c
@@ -32,6 +32,8 @@ struct thunder_uncore *event_to_thunder_uncore(struct perf_event *event)
 		return thunder_uncore_ocx_lne;
 	else if (event->pmu->type == thunder_ocx_frc_pmu.type)
 		return thunder_uncore_ocx_frc;
+	else if (event->pmu->type == thunder_ocx_tlk_pmu.type)
+		return thunder_uncore_ocx_tlk;
 	else
 		return NULL;
 }
@@ -221,6 +223,7 @@ static int __init thunder_uncore_init(void)
 	thunder_uncore_lmc_setup();
 	thunder_uncore_ocx_lne_setup();
 	thunder_uncore_ocx_frc_setup();
+	thunder_uncore_ocx_tlk_setup();
 	return 0;
 }
 late_initcall(thunder_uncore_init);
diff --git a/arch/arm64/kernel/uncore/uncore_cavium.h b/arch/arm64/kernel/uncore/uncore_cavium.h
index 07bd4f4..f312d41 100644
--- a/arch/arm64/kernel/uncore/uncore_cavium.h
+++ b/arch/arm64/kernel/uncore/uncore_cavium.h
@@ -18,6 +18,7 @@ enum uncore_type {
 	LMC_TYPE,
 	OCX_LNE_TYPE,
 	OCX_FRC_TYPE,
+	OCX_TLK_TYPE,
 };
 
 extern int thunder_uncore_version;
@@ -68,11 +69,13 @@ extern struct thunder_uncore *thunder_uncore_l2c_cbc;
 extern struct thunder_uncore *thunder_uncore_lmc;
 extern struct thunder_uncore *thunder_uncore_ocx_lne;
 extern struct thunder_uncore *thunder_uncore_ocx_frc;
+extern struct thunder_uncore *thunder_uncore_ocx_tlk;
 extern struct pmu thunder_l2c_tad_pmu;
 extern struct pmu thunder_l2c_cbc_pmu;
 extern struct pmu thunder_lmc_pmu;
 extern struct pmu thunder_ocx_lne_pmu;
 extern struct pmu thunder_ocx_frc_pmu;
+extern struct pmu thunder_ocx_tlk_pmu;
 
 /* Prototypes */
 struct thunder_uncore *event_to_thunder_uncore(struct perf_event *event);
@@ -91,3 +94,4 @@ int thunder_uncore_l2c_cbc_setup(void);
 int thunder_uncore_lmc_setup(void);
 int thunder_uncore_ocx_lne_setup(void);
 int thunder_uncore_ocx_frc_setup(void);
+int thunder_uncore_ocx_tlk_setup(void);
diff --git a/arch/arm64/kernel/uncore/uncore_cavium_ocx_tlk.c b/arch/arm64/kernel/uncore/uncore_cavium_ocx_tlk.c
new file mode 100644
index 0000000..71ef3ae
--- /dev/null
+++ b/arch/arm64/kernel/uncore/uncore_cavium_ocx_tlk.c
@@ -0,0 +1,366 @@
+/*
+ * Cavium Thunder uncore PMU support, OCX TLK counters.
+ *
+ * Copyright 2016 Cavium Inc.
+ * Author: Jan Glauber <jan.glauber at cavium.com>
+ */
+
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/cpu.h>
+#include <linux/io.h>
+#include <linux/perf_event.h>
+#include <linux/pci.h>
+
+#include <asm/cpufeature.h>
+#include <asm/cputype.h>
+
+#include "uncore_cavium.h"
+
+#ifndef PCI_DEVICE_ID_THUNDER_OCX
+#define PCI_DEVICE_ID_THUNDER_OCX		0xa013
+#endif
+
+#define OCX_TLK_NR_UNITS			3
+#define OCX_TLK_UNIT_OFFSET			0x2000
+#define OCX_TLK_CONTROL_OFFSET			0x10040
+#define OCX_TLK_COUNTER_OFFSET			0x10400
+
+#define OCX_TLK_STAT_DISABLE			0
+#define OCX_TLK_STAT_ENABLE			1
+
+/* OCX TLK event list */
+#define OCX_TLK_EVENT_STAT_IDLE_CNT		0x00
+#define OCX_TLK_EVENT_STAT_DATA_CNT		0x01
+#define OCX_TLK_EVENT_STAT_SYNC_CNT		0x02
+#define OCX_TLK_EVENT_STAT_RETRY_CNT		0x03
+#define OCX_TLK_EVENT_STAT_ERR_CNT		0x04
+
+#define OCX_TLK_EVENT_STAT_MAT0_CNT		0x08
+#define OCX_TLK_EVENT_STAT_MAT1_CNT		0x09
+#define OCX_TLK_EVENT_STAT_MAT2_CNT		0x0a
+#define OCX_TLK_EVENT_STAT_MAT3_CNT		0x0b
+
+#define OCX_TLK_EVENT_STAT_VC0_CMD		0x10
+#define OCX_TLK_EVENT_STAT_VC1_CMD		0x11
+#define OCX_TLK_EVENT_STAT_VC2_CMD		0x12
+#define OCX_TLK_EVENT_STAT_VC3_CMD		0x13
+#define OCX_TLK_EVENT_STAT_VC4_CMD		0x14
+#define OCX_TLK_EVENT_STAT_VC5_CMD		0x15
+
+#define OCX_TLK_EVENT_STAT_VC0_PKT		0x20
+#define OCX_TLK_EVENT_STAT_VC1_PKT		0x21
+#define OCX_TLK_EVENT_STAT_VC2_PKT		0x22
+#define OCX_TLK_EVENT_STAT_VC3_PKT		0x23
+#define OCX_TLK_EVENT_STAT_VC4_PKT		0x24
+#define OCX_TLK_EVENT_STAT_VC5_PKT		0x25
+#define OCX_TLK_EVENT_STAT_VC6_PKT		0x26
+#define OCX_TLK_EVENT_STAT_VC7_PKT		0x27
+#define OCX_TLK_EVENT_STAT_VC8_PKT		0x28
+#define OCX_TLK_EVENT_STAT_VC9_PKT		0x29
+#define OCX_TLK_EVENT_STAT_VC10_PKT		0x2a
+#define OCX_TLK_EVENT_STAT_VC11_PKT		0x2b
+#define OCX_TLK_EVENT_STAT_VC12_PKT		0x2c
+#define OCX_TLK_EVENT_STAT_VC13_PKT		0x2d
+
+#define OCX_TLK_EVENT_STAT_VC0_CON		0x30
+#define OCX_TLK_EVENT_STAT_VC1_CON		0x31
+#define OCX_TLK_EVENT_STAT_VC2_CON		0x32
+#define OCX_TLK_EVENT_STAT_VC3_CON		0x33
+#define OCX_TLK_EVENT_STAT_VC4_CON		0x34
+#define OCX_TLK_EVENT_STAT_VC5_CON		0x35
+#define OCX_TLK_EVENT_STAT_VC6_CON		0x36
+#define OCX_TLK_EVENT_STAT_VC7_CON		0x37
+#define OCX_TLK_EVENT_STAT_VC8_CON		0x38
+#define OCX_TLK_EVENT_STAT_VC9_CON		0x39
+#define OCX_TLK_EVENT_STAT_VC10_CON		0x3a
+#define OCX_TLK_EVENT_STAT_VC11_CON		0x3b
+#define OCX_TLK_EVENT_STAT_VC12_CON		0x3c
+#define OCX_TLK_EVENT_STAT_VC13_CON		0x3d
+
+#define OCX_TLK_MAX_COUNTER			OCX_TLK_EVENT_STAT_VC13_CON
+#define OCX_TLK_NR_COUNTERS			OCX_TLK_MAX_COUNTER
+
+struct thunder_uncore *thunder_uncore_ocx_tlk;
+
+static inline void __iomem *map_offset_ocx_tlk(unsigned long addr,
+				struct thunder_uncore *uncore, int unit)
+{
+	return (void __iomem *) (addr +
+				 uncore->pdevs[0].map +
+				 unit * OCX_TLK_UNIT_OFFSET);
+}
+
+/*
+ * Summarize counters across all TLK's. Different from the other uncore
+ * PMUs because all TLK's are on one PCI device.
+ */
+static void thunder_uncore_read_ocx_tlk(struct perf_event *event)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	u64 prev, new = 0;
+	s64 delta;
+	int i;
+
+	/*
+	 * since we do not enable counter overflow interrupts,
+	 * we do not have to worry about prev_count changing on us
+	 */
+
+	prev = local64_read(&hwc->prev_count);
+
+	/* read counter values from all units */
+	for (i = 0; i < OCX_TLK_NR_UNITS; i++)
+		new += readq(map_offset_ocx_tlk(hwc->event_base, uncore, i));
+
+	local64_set(&hwc->prev_count, new);
+	delta = new - prev;
+	local64_add(delta, &event->count);
+}
+
+static void thunder_uncore_start(struct perf_event *event, int flags)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	int i;
+
+	hwc->state = 0;
+
+	/* enable counters on all units */
+	for (i = 0; i < OCX_TLK_NR_UNITS; i++)
+		writeb(OCX_TLK_STAT_ENABLE,
+		       map_offset_ocx_tlk(hwc->config_base, uncore, i));
+
+	perf_event_update_userpage(event);
+}
+
+static void thunder_uncore_stop(struct perf_event *event, int flags)
+{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	int i;
+
+	/* disable counters on all units */
+	for (i = 0; i < OCX_TLK_NR_UNITS; i++)
+		writeb(OCX_TLK_STAT_DISABLE,
+		       map_offset_ocx_tlk(hwc->config_base, uncore, i));
+	hwc->state |= PERF_HES_STOPPED;
+
+	if ((flags & PERF_EF_UPDATE) && !(hwc->state & PERF_HES_UPTODATE)) {
+		thunder_uncore_read_ocx_tlk(event);
+		hwc->state |= PERF_HES_UPTODATE;
+	}
+}
+
+static int thunder_uncore_add(struct perf_event *event, int flags)
+	{
+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
+	struct hw_perf_event *hwc = &event->hw;
+	int i;
+
+	WARN_ON_ONCE(!uncore);
+
+	/* are we already assigned? */
+	if (hwc->idx != -1 && uncore->events[hwc->idx] == event)
+		goto out;
+
+	for (i = 0; i < uncore->num_counters; i++) {
+		if (uncore->events[i] == event) {
+			hwc->idx = i;
+			goto out;
+		}
+	}
+
+	/* counters are 1:1 */
+	hwc->idx = -1;
+	if (cmpxchg(&uncore->events[hwc->config], NULL, event) == NULL)
+		hwc->idx = hwc->config;
+
+out:
+	if (hwc->idx == -1)
+		return -EBUSY;
+
+	hwc->config_base = 0;
+	hwc->event_base = OCX_TLK_COUNTER_OFFSET - OCX_TLK_CONTROL_OFFSET +
+			hwc->idx * sizeof(unsigned long long);
+	hwc->state = PERF_HES_UPTODATE | PERF_HES_STOPPED;
+
+	if (flags & PERF_EF_START)
+		thunder_uncore_start(event, PERF_EF_RELOAD);
+
+	return 0;
+}
+
+PMU_FORMAT_ATTR(event, "config:0-5");
+
+static struct attribute *thunder_ocx_tlk_format_attr[] = {
+	&format_attr_event.attr,
+	NULL,
+};
+
+static struct attribute_group thunder_ocx_tlk_format_group = {
+	.name = "format",
+	.attrs = thunder_ocx_tlk_format_attr,
+};
+
+EVENT_ATTR(idle_cnt,	OCX_TLK_EVENT_STAT_IDLE_CNT);
+EVENT_ATTR(data_cnt,	OCX_TLK_EVENT_STAT_DATA_CNT);
+EVENT_ATTR(sync_cnt,	OCX_TLK_EVENT_STAT_SYNC_CNT);
+EVENT_ATTR(retry_cnt,	OCX_TLK_EVENT_STAT_RETRY_CNT);
+EVENT_ATTR(err_cnt,	OCX_TLK_EVENT_STAT_ERR_CNT);
+EVENT_ATTR(mat0_cnt,	OCX_TLK_EVENT_STAT_MAT0_CNT);
+EVENT_ATTR(mat1_cnt,	OCX_TLK_EVENT_STAT_MAT1_CNT);
+EVENT_ATTR(mat2_cnt,	OCX_TLK_EVENT_STAT_MAT2_CNT);
+EVENT_ATTR(mat3_cnt,	OCX_TLK_EVENT_STAT_MAT3_CNT);
+EVENT_ATTR(vc0_cmd,	OCX_TLK_EVENT_STAT_VC0_CMD);
+EVENT_ATTR(vc1_cmd,	OCX_TLK_EVENT_STAT_VC1_CMD);
+EVENT_ATTR(vc2_cmd,	OCX_TLK_EVENT_STAT_VC2_CMD);
+EVENT_ATTR(vc3_cmd,	OCX_TLK_EVENT_STAT_VC3_CMD);
+EVENT_ATTR(vc4_cmd,	OCX_TLK_EVENT_STAT_VC4_CMD);
+EVENT_ATTR(vc5_cmd,	OCX_TLK_EVENT_STAT_VC5_CMD);
+EVENT_ATTR(vc0_pkt,	OCX_TLK_EVENT_STAT_VC0_PKT);
+EVENT_ATTR(vc1_pkt,	OCX_TLK_EVENT_STAT_VC1_PKT);
+EVENT_ATTR(vc2_pkt,	OCX_TLK_EVENT_STAT_VC2_PKT);
+EVENT_ATTR(vc3_pkt,	OCX_TLK_EVENT_STAT_VC3_PKT);
+EVENT_ATTR(vc4_pkt,	OCX_TLK_EVENT_STAT_VC4_PKT);
+EVENT_ATTR(vc5_pkt,	OCX_TLK_EVENT_STAT_VC5_PKT);
+EVENT_ATTR(vc6_pkt,	OCX_TLK_EVENT_STAT_VC6_PKT);
+EVENT_ATTR(vc7_pkt,	OCX_TLK_EVENT_STAT_VC7_PKT);
+EVENT_ATTR(vc8_pkt,	OCX_TLK_EVENT_STAT_VC8_PKT);
+EVENT_ATTR(vc9_pkt,	OCX_TLK_EVENT_STAT_VC9_PKT);
+EVENT_ATTR(vc10_pkt,	OCX_TLK_EVENT_STAT_VC10_PKT);
+EVENT_ATTR(vc11_pkt,	OCX_TLK_EVENT_STAT_VC11_PKT);
+EVENT_ATTR(vc12_pkt,	OCX_TLK_EVENT_STAT_VC12_PKT);
+EVENT_ATTR(vc13_pkt,	OCX_TLK_EVENT_STAT_VC13_PKT);
+EVENT_ATTR(vc0_con,	OCX_TLK_EVENT_STAT_VC0_CON);
+EVENT_ATTR(vc1_con,	OCX_TLK_EVENT_STAT_VC1_CON);
+EVENT_ATTR(vc2_con,	OCX_TLK_EVENT_STAT_VC2_CON);
+EVENT_ATTR(vc3_con,	OCX_TLK_EVENT_STAT_VC3_CON);
+EVENT_ATTR(vc4_con,	OCX_TLK_EVENT_STAT_VC4_CON);
+EVENT_ATTR(vc5_con,	OCX_TLK_EVENT_STAT_VC5_CON);
+EVENT_ATTR(vc6_con,	OCX_TLK_EVENT_STAT_VC6_CON);
+EVENT_ATTR(vc7_con,	OCX_TLK_EVENT_STAT_VC7_CON);
+EVENT_ATTR(vc8_con,	OCX_TLK_EVENT_STAT_VC8_CON);
+EVENT_ATTR(vc9_con,	OCX_TLK_EVENT_STAT_VC9_CON);
+EVENT_ATTR(vc10_con,	OCX_TLK_EVENT_STAT_VC10_CON);
+EVENT_ATTR(vc11_con,	OCX_TLK_EVENT_STAT_VC11_CON);
+EVENT_ATTR(vc12_con,	OCX_TLK_EVENT_STAT_VC12_CON);
+EVENT_ATTR(vc13_con,	OCX_TLK_EVENT_STAT_VC13_CON);
+
+static struct attribute *thunder_ocx_tlk_events_attr[] = {
+	EVENT_PTR(idle_cnt),
+	EVENT_PTR(data_cnt),
+	EVENT_PTR(sync_cnt),
+	EVENT_PTR(retry_cnt),
+	EVENT_PTR(err_cnt),
+	EVENT_PTR(mat0_cnt),
+	EVENT_PTR(mat1_cnt),
+	EVENT_PTR(mat2_cnt),
+	EVENT_PTR(mat3_cnt),
+	EVENT_PTR(vc0_cmd),
+	EVENT_PTR(vc1_cmd),
+	EVENT_PTR(vc2_cmd),
+	EVENT_PTR(vc3_cmd),
+	EVENT_PTR(vc4_cmd),
+	EVENT_PTR(vc5_cmd),
+	EVENT_PTR(vc0_pkt),
+	EVENT_PTR(vc1_pkt),
+	EVENT_PTR(vc2_pkt),
+	EVENT_PTR(vc3_pkt),
+	EVENT_PTR(vc4_pkt),
+	EVENT_PTR(vc5_pkt),
+	EVENT_PTR(vc6_pkt),
+	EVENT_PTR(vc7_pkt),
+	EVENT_PTR(vc8_pkt),
+	EVENT_PTR(vc9_pkt),
+	EVENT_PTR(vc10_pkt),
+	EVENT_PTR(vc11_pkt),
+	EVENT_PTR(vc12_pkt),
+	EVENT_PTR(vc13_pkt),
+	EVENT_PTR(vc0_con),
+	EVENT_PTR(vc1_con),
+	EVENT_PTR(vc2_con),
+	EVENT_PTR(vc3_con),
+	EVENT_PTR(vc4_con),
+	EVENT_PTR(vc5_con),
+	EVENT_PTR(vc6_con),
+	EVENT_PTR(vc7_con),
+	EVENT_PTR(vc8_con),
+	EVENT_PTR(vc9_con),
+	EVENT_PTR(vc10_con),
+	EVENT_PTR(vc11_con),
+	EVENT_PTR(vc12_con),
+	EVENT_PTR(vc13_con),
+	NULL,
+};
+
+static struct attribute_group thunder_ocx_tlk_events_group = {
+	.name = "events",
+	.attrs = thunder_ocx_tlk_events_attr,
+};
+
+static const struct attribute_group *thunder_ocx_tlk_attr_groups[] = {
+	&thunder_uncore_attr_group,
+	&thunder_ocx_tlk_format_group,
+	&thunder_ocx_tlk_events_group,
+	NULL,
+};
+
+struct pmu thunder_ocx_tlk_pmu = {
+	.attr_groups	= thunder_ocx_tlk_attr_groups,
+	.name		= "thunder_ocx_tlk",
+	.event_init	= thunder_uncore_event_init,
+	.add		= thunder_uncore_add,
+	.del		= thunder_uncore_del,
+	.start		= thunder_uncore_start,
+	.stop		= thunder_uncore_stop,
+	.read		= thunder_uncore_read_ocx_tlk,
+};
+
+static int event_valid(u64 config)
+{
+	if (config <= OCX_TLK_EVENT_STAT_ERR_CNT ||
+	    (config >= OCX_TLK_EVENT_STAT_MAT0_CNT &&
+	     config <= OCX_TLK_EVENT_STAT_MAT3_CNT) ||
+	    (config >= OCX_TLK_EVENT_STAT_VC0_CMD &&
+	     config <= OCX_TLK_EVENT_STAT_VC5_CMD) ||
+	    (config >= OCX_TLK_EVENT_STAT_VC0_PKT &&
+	     config <= OCX_TLK_EVENT_STAT_VC13_PKT) ||
+	    (config >= OCX_TLK_EVENT_STAT_VC0_CON &&
+	     config <= OCX_TLK_EVENT_STAT_VC13_CON))
+		return 1;
+	else
+		return 0;
+}
+
+int __init thunder_uncore_ocx_tlk_setup(void)
+{
+	int ret;
+
+	thunder_uncore_ocx_tlk = kzalloc(sizeof(struct thunder_uncore),
+					 GFP_KERNEL);
+	if (!thunder_uncore_ocx_tlk) {
+		ret = -ENOMEM;
+		goto fail_nomem;
+	}
+
+	ret = thunder_uncore_setup(thunder_uncore_ocx_tlk,
+				   PCI_DEVICE_ID_THUNDER_OCX,
+				   OCX_TLK_CONTROL_OFFSET,
+				   OCX_TLK_UNIT_OFFSET * OCX_TLK_NR_UNITS,
+				   &thunder_ocx_tlk_pmu);
+	if (ret)
+		goto fail;
+
+	thunder_uncore_ocx_tlk->type = OCX_TLK_TYPE;
+	thunder_uncore_ocx_tlk->num_counters = OCX_TLK_NR_COUNTERS;
+	thunder_uncore_ocx_tlk->event_valid = event_valid;
+	return 0;
+
+fail:
+	kfree(thunder_uncore_ocx_tlk);
+fail_nomem:
+	return ret;
+}
-- 
1.9.1



From mark.rutland at arm.com  Fri Feb 12 08:57:07 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 12 Feb 2016 16:57:07 +0000
Subject: [PATCH 2/2] arm64: Mark kernel page ranges contiguous
In-Reply-To: <1455293208-6763-3-git-send-email-jeremy.linton@arm.com>
References: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
 <1455293208-6763-3-git-send-email-jeremy.linton@arm.com>
Message-ID: <20160212165707.GB20262@leverpostej>

Hi,

On Fri, Feb 12, 2016 at 10:06:48AM -0600, Jeremy Linton wrote:
> With 64k pages, the next larger segment size is 512M. The linux
> kernel also uses different protection flags to cover its code and data.
> Because of this requirement, the vast majority of the kernel code and
> data structures end up being mapped with 64k pages instead of the larger
> pages common with a 4k page kernel.
> 
> Recent ARM processors support a contiguous bit in the
> page tables which allows the a TLB to cover a range larger than a
> single PTE if that range is mapped into physically contiguous
> ram.
> 
> So, for the kernel its a good idea to set this flag. Some basic
> micro benchmarks show it can significantly reduce the number of
> L1 dTLB refills.
> 
> Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
> ---
>  arch/arm64/mm/mmu.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 58 insertions(+), 6 deletions(-)

This generally looks good.

As a heads-up, I have one concern:

> +static void clear_cont_pte_range(pte_t *pte, unsigned long addr)
> +{
> +	int i;
> +
> +	pte -= CONT_RANGE_OFFSET(addr);
> +	for (i = 0; i < CONT_PTES; i++) {
> +		if (pte_cont(*pte))
> +			set_pte(pte, pte_mknoncont(*pte));
> +		pte++;
> +	}
> +	flush_tlb_all();
> +}

As far as I can tell, "splitting" contiguous entries comes with the same
caveats as splitting sections. In the absence of a BBM sequence we might
end up with conflicting TLB entries.

However, I think we're OK for now.

The way we consistently map/unmap/modify image/linear "chunks" should
prevent us from trying to split those, and if/when we do this for the
EFI runtime page tables thy aren't live.

It would be good to figure out how to get rid of the splitting entirely.

Otherwise, this looks good to me; I'll try to give this a spin next
week.

Thanks,
Mark.


From ard.biesheuvel at linaro.org  Fri Feb 12 09:00:01 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 18:00:01 +0100
Subject: [PATCH] arm/arm64/crypto: assure that ECB modes don't require an
 IV
In-Reply-To: <1455292072-5236-1-git-send-email-jeremy.linton@arm.com>
References: <1455292072-5236-1-git-send-email-jeremy.linton@arm.com>
Message-ID: <CAKv+Gu8_Z5=0dTeBsVgx_BT0c+_O5PNUCyKFjuDf9x470bxHOA@mail.gmail.com>

On 12 February 2016 at 16:47, Jeremy Linton <jeremy.linton at arm.com> wrote:
> ECB modes don't use an initialization vector. The kernel
> /proc/crypto interface doesn't reflect this properly.
>
> Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>

Thanks for spotting that!

Acked-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

> ---
>  arch/arm/crypto/aes-ce-glue.c | 4 ++--
>  arch/arm64/crypto/aes-glue.c  | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/crypto/aes-ce-glue.c b/arch/arm/crypto/aes-ce-glue.c
> index b445a5d..89a3a3e 100644
> --- a/arch/arm/crypto/aes-ce-glue.c
> +++ b/arch/arm/crypto/aes-ce-glue.c
> @@ -364,7 +364,7 @@ static struct crypto_alg aes_algs[] = { {
>         .cra_blkcipher = {
>                 .min_keysize    = AES_MIN_KEY_SIZE,
>                 .max_keysize    = AES_MAX_KEY_SIZE,
> -               .ivsize         = AES_BLOCK_SIZE,
> +               .ivsize         = 0,
>                 .setkey         = ce_aes_setkey,
>                 .encrypt        = ecb_encrypt,
>                 .decrypt        = ecb_decrypt,
> @@ -441,7 +441,7 @@ static struct crypto_alg aes_algs[] = { {
>         .cra_ablkcipher = {
>                 .min_keysize    = AES_MIN_KEY_SIZE,
>                 .max_keysize    = AES_MAX_KEY_SIZE,
> -               .ivsize         = AES_BLOCK_SIZE,
> +               .ivsize         = 0,
>                 .setkey         = ablk_set_key,
>                 .encrypt        = ablk_encrypt,
>                 .decrypt        = ablk_decrypt,
> diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
> index 05d9e16..7a3d22a 100644
> --- a/arch/arm64/crypto/aes-glue.c
> +++ b/arch/arm64/crypto/aes-glue.c
> @@ -294,7 +294,7 @@ static struct crypto_alg aes_algs[] = { {
>         .cra_blkcipher = {
>                 .min_keysize    = AES_MIN_KEY_SIZE,
>                 .max_keysize    = AES_MAX_KEY_SIZE,
> -               .ivsize         = AES_BLOCK_SIZE,
> +               .ivsize         = 0,
>                 .setkey         = aes_setkey,
>                 .encrypt        = ecb_encrypt,
>                 .decrypt        = ecb_decrypt,
> @@ -371,7 +371,7 @@ static struct crypto_alg aes_algs[] = { {
>         .cra_ablkcipher = {
>                 .min_keysize    = AES_MIN_KEY_SIZE,
>                 .max_keysize    = AES_MAX_KEY_SIZE,
> -               .ivsize         = AES_BLOCK_SIZE,
> +               .ivsize         = 0,
>                 .setkey         = ablk_set_key,
>                 .encrypt        = ablk_encrypt,
>                 .decrypt        = ablk_decrypt,
> --
> 2.4.3
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From mark.rutland at arm.com  Fri Feb 12 09:00:57 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 12 Feb 2016 17:00:57 +0000
Subject: [RFC PATCH 0/7] Cavium ThunderX uncore PMU support
In-Reply-To: <cover.1455295032.git.jglauber@cavium.com>
References: <cover.1455295032.git.jglauber@cavium.com>
Message-ID: <20160212170056.GC20262@leverpostej>

On Fri, Feb 12, 2016 at 05:55:05PM +0100, Jan Glauber wrote:
> Hi,
> 
> this patch series provides access to various counters on the ThunderX SOC.
> 
> For details of the implementation see patch #1.
> 
> Patches #2-7 add ther various ThunderX specific PMUs.
> 
> I did not want to put these file into arch/arm64/kernel so I added a
> "uncore" directory. Maybe this should be put somewhere under drivers/
> instead.

This is probably better suited to drivers/perf/, or drivers/bus/ (where
CCN and CCI perf drivers live).

Mark.


From arnd at arndb.de  Fri Feb 12 09:04:31 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 18:04:31 +0100
Subject: [PATCH] [media] zl10353: use div_u64 instead of do_div
In-Reply-To: <20160212143220.5a440e66@recife.lan>
References: <1455287246-3540549-1-git-send-email-arnd@arndb.de>
 <20160212143220.5a440e66@recife.lan>
Message-ID: <2712691.b9gkR7KMX7@wuerfel>

On Friday 12 February 2016 14:32:20 Mauro Carvalho Chehab wrote:
> Em Fri, 12 Feb 2016 15:27:18 +0100
> Arnd Bergmann <arnd at arndb.de> escreveu:
> 
> > I noticed a build error in some randconfig builds in the zl10353 driver:
> > 
> > dvb-frontends/zl10353.c:138: undefined reference to `____ilog2_NaN'
> > dvb-frontends/zl10353.c:138: undefined reference to `__aeabi_uldivmod'
> > 
> > The problem can be tracked down to the use of -fprofile-arcs (using
> > CONFIG_GCOV_PROFILE_ALL) in combination with CONFIG_PROFILE_ALL_BRANCHES
> > on gcc version 4.9 or higher, when it fails to reliably optimize
> > constant expressions.
> > 
> > Using div_u64() instead of do_div() makes the code slightly more
> > readable by both humans and by gcc, which gives the compiler enough
> > of a break to figure it all out.
> 
> I'm not against this patch, but we have 94 occurrences of do_div() 
> just at the media subsystem. If this is failing here, it would likely
> fail with other drivers. So, I guess we should either fix do_div() or
> convert all such occurrences to do_div64().

I agree that it's possible that the same problem exists elsewhere, but this is
the only one that I ever saw (in five ranconfig builds out of 8035 last week).

I also tried changing do_div() to be an inline function with just a small
macro wrapper around it for the odd calling conventions, which also made this
error go away. I would assume that Nico had a good reason for doing do_div()
the way he did. In some other files, I saw the object code grow by a few
instructions, but the examples I looked at were otherwise identical.

I can imagine that there might be cases where the constant-argument optimization
of do_div fails when we go through an inline function in some combination
of Kconfig options and compiler version, though I don't think that was
the case here.

Nico, any other thoughts on this?

	Arnd


From robin.murphy at arm.com  Fri Feb 12 09:09:46 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Fri, 12 Feb 2016 17:09:46 +0000
Subject: [PATCH v2] iommu/io-pgtable: Rationalise quirk handling
In-Reply-To: <cover.1453723096.git.robin.murphy@arm.com>
References: <cover.1453723096.git.robin.murphy@arm.com>
Message-ID: <62860b753f304beef7b4b6f1e13d7094252f2f37.1455294748.git.robin.murphy@arm.com>

As the number of io-pgtable implementations grows beyond 1, it's time
to rationalise the quirks mechanism before things have a chance to
start getting really ugly and out-of-hand.

To that end:
- Indicate exactly which quirks each format can/does support.
- Fail creating a table if a caller wants unsupported quirks.
- Properly document where each quirk applies and why.

Signed-off-by: Robin Murphy <robin.murphy at arm.com>
---

Just to allay any confusion, I intend this as a followup to the
short-descriptor[1] and Mediatek IOMMU[2] patches, rather than a
crucial addition, so it can either get picked up along with those
or wait 'til later.

v2:
- Use unsigned long for the bitmap.
- Do format-specific checks inline.
- Enough of a difference that I don't feel comfortable putting
  Laurent's reviewed-by from v1 on it...

Robin.

[1]:http://thread.gmane.org/gmane.linux.kernel.iommu/12007
[2]:http://thread.gmane.org/gmane.linux.kernel.iommu/11974

 drivers/iommu/io-pgtable-arm-v7s.c |  5 +++++
 drivers/iommu/io-pgtable-arm.c     | 13 +++++++++++--
 drivers/iommu/io-pgtable.h         | 22 ++++++++++++++++++----
 3 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index d39a021..9fcceb1 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -623,6 +623,11 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
 	if (cfg->ias > ARM_V7S_ADDR_BITS || cfg->oas > ARM_V7S_ADDR_BITS)
 		return NULL;
 
+	if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
+			    IO_PGTABLE_QUIRK_NO_PERMS |
+			    IO_PGTABLE_QUIRK_TLBI_ON_MAP))
+		return NULL;
+
 	data = kmalloc(sizeof(*data), GFP_KERNEL);
 	if (!data)
 		return NULL;
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 4095af2..debdf04 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -658,8 +658,12 @@ static struct io_pgtable *
 arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie)
 {
 	u64 reg;
-	struct arm_lpae_io_pgtable *data = arm_lpae_alloc_pgtable(cfg);
+	struct arm_lpae_io_pgtable *data;
 
+	if (cfg->quirks & ~IO_PGTABLE_QUIRK_ARM_NS)
+		return NULL;
+
+	data = arm_lpae_alloc_pgtable(cfg);
 	if (!data)
 		return NULL;
 
@@ -742,8 +746,13 @@ static struct io_pgtable *
 arm_64_lpae_alloc_pgtable_s2(struct io_pgtable_cfg *cfg, void *cookie)
 {
 	u64 reg, sl;
-	struct arm_lpae_io_pgtable *data = arm_lpae_alloc_pgtable(cfg);
+	struct arm_lpae_io_pgtable *data;
 
+	/* The NS quirk doesn't apply at stage 2 */
+	if (cfg->quirks)
+		return NULL;
+
+	data = arm_lpae_alloc_pgtable(cfg);
 	if (!data)
 		return NULL;
 
diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
index 4faee7d..d4f5027 100644
--- a/drivers/iommu/io-pgtable.h
+++ b/drivers/iommu/io-pgtable.h
@@ -47,10 +47,24 @@ struct iommu_gather_ops {
  *                 page table walker.
  */
 struct io_pgtable_cfg {
-	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0) /* Set NS bit in PTEs */
-	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1) /* No AP/XN bits */
-	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2) /* TLB Inv. on map */
-	int				quirks;
+	/*
+	 * IO_PGTABLE_QUIRK_ARM_NS: (ARM formats) Set NS and NSTABLE bits in
+	 *	stage 1 PTEs, for hardware which insists on validating them
+	 *	even in	non-secure state where they should normally be ignored.
+	 *
+	 * IO_PGTABLE_QUIRK_NO_PERMS: Ignore the IOMMU_READ, IOMMU_WRITE and
+	 *	IOMMU_NOEXEC flags and map everything with full access, for
+	 *	hardware which does not implement the permissions of a given
+	 *	format, and/or requires some format-specific default value.
+	 *
+	 * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching invalid
+	 *	(unmapped) entries but the hardware might do so anyway, perform
+	 *	TLB maintenance when mapping as well as when unmapping.
+	 */
+	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
+	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
+	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2)
+	unsigned long			quirks;
 	unsigned long			pgsize_bitmap;
 	unsigned int			ias;
 	unsigned int			oas;
-- 
2.7.0.25.gfc10eb5.dirty



From gerald.schaefer at de.ibm.com  Fri Feb 12 09:16:40 2016
From: gerald.schaefer at de.ibm.com (Gerald Schaefer)
Date: Fri, 12 Feb 2016 18:16:40 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe
 also on PowerPC and ARM)
In-Reply-To: <56BE00E7.1010303@de.ibm.com>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com>
Message-ID: <20160212181640.4eabb85f@thinkpad>

On Fri, 12 Feb 2016 16:57:27 +0100
Christian Borntraeger <borntraeger at de.ibm.com> wrote:

> On 02/12/2016 04:41 PM, Kirill A. Shutemov wrote:
> > On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> >> On Thu, 11 Feb 2016 21:09:42 +0200
> >> "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> >>
> >>> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> >>>> Hi,
> >>>>
> >>>> Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> >>>> he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
> >>>> review of the THP rework patches, which cannot be bisected, revealed
> >>>> commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
> >>>> (and also similar commits for other archs).
> >>>>
> >>>> This commit removes the THP splitting bit and also the architecture
> >>>> implementation of pmdp_splitting_flush(), which took care of the IPI for
> >>>> fast_gup serialization. The commit message says
> >>>>
> >>>>     pmdp_splitting_flush() is not needed too: on splitting PMD we will do
> >>>>     pmdp_clear_flush() + set_pte_at().  pmdp_clear_flush() will do IPI as
> >>>>     needed for fast_gup
> >>>>
> >>>> The assumption that a TLB flush will also produce an IPI is wrong on s390,
> >>>> and maybe also on other architectures, and I thought that this was actually
> >>>> the main reason for having an arch-specific pmdp_splitting_flush().
> >>>>
> >>>> At least PowerPC and ARM also had an individual implementation of
> >>>> pmdp_splitting_flush() that used kick_all_cpus_sync() instead of a TLB
> >>>> flush to send the IPI, and those were also removed. Putting the arch
> >>>> maintainers and mailing lists on cc to verify.
> >>>>
> >>>> On s390 this will break the IPI serialization against fast_gup, which
> >>>> would certainly explain the random kernel crashes, please revert or fix
> >>>> the pmdp_splitting_flush() removal.
> >>>
> >>> Sorry for that.
> >>>
> >>> I believe, the problem was already addressed for PowerPC:
> >>>
> >>> http://lkml.kernel.org/g/454980831-16631-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com
> >>>
> >>> I think kick_all_cpus_sync() in arch-specific pmdp_invalidate() would do
> >>> the trick, right?
> >>
> >> Hmm, not sure about that. After pmdp_invalidate(), a pmd_none() check in
> >> fast_gup will still return false, because the pmd is not empty (at least
> >> on s390). So I don't see spontaneously how it will help fast_gup to break
> >> out to the slow path in case of THP splitting.
> > 
> > What pmdp_flush_direct() does in pmdp_invalidate()? It's hard to unwrap for me :-/
> > Does it make the pmd !pmd_present()?
> 
> It uses the idte instruction, which in an atomic fashion flushes the associated
> TLB entry and changes the value of the pmd entry to invalid. This comes from the
> HW requirement to not  change a PTE/PMD that might be still in use, other than 
> with special instructions that does the tlb handling and the invalidation together.

Correct, and it does _not_ make the pmd !pmd_present(), that would only be the
case after a _clear_flush(). It only marks the pmd as invalid and flushes,
so that it cannot generate a new TLB entry before the following pmd_populate(),
but it keeps its other content. This is to fulfill the requirements outlined in
the comment in mm/huge_memory.c before the call to pmdp_invalidate(). And
independent from that comment, we would need such an _invalidate() or
_clear_flush() on s390 before the pmd_populate() because of the HW details
that Christian described.

Reading the comment again, I do now notice that it also says "mark the current
pmd notpresent", which we cannot do w/o losing the huge and (formerly) splitting
bits, but it also shouldn't be needed to provide the "single TLB guarantee" that
is required from the comment. So, a pmd_present() check on s390 in this state
would still return true. Not sure yet if this is a problem, need more thinking,
this behavior was already present before the THP rework but maybe it was OK
before and is not OK now.

At least for fast_gup this should not be a problem though.

> (It also does some some other magic to the attach_count, which might hold off
> finish_arch_post_lock_switch while some flushing is happening, but this should
> be unrelated here)
> 
> 
> > I'm also confused by pmd_none() is equal to !pmd_present() on s390. Hm?
> 
> Don't know, Gerald or Martin?

The implementation frequently changes depending on how many new bits Martin
needs to squeeze out :-)
We don't have a _PAGE_PRESENT bit for pmds, so pmd_present() just checks if the
entry is not empty. pmd_none() of course does the opposite, it checks if it is
empty.

> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-s390" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



From s-anna at ti.com  Fri Feb 12 09:20:20 2016
From: s-anna at ti.com (Suman Anna)
Date: Fri, 12 Feb 2016 11:20:20 -0600
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <56BD8091.4090007@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com> <56BACCDB.2070507@ti.com>
 <alpine.DEB.2.02.1602111921090.20757@utopia.booyaka.com>
 <56BD8091.4090007@ti.com>
Message-ID: <56BE1454.3030002@ti.com>

Kishon,

On 02/12/2016 12:49 AM, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Friday 12 February 2016 12:57 AM, Paul Walmsley wrote:
>> Hi Kishon, Suman,
>>
>> On Wed, 10 Feb 2016, Kishon Vijay Abraham I wrote:
>>
>>> On Wednesday 10 February 2016 07:12 AM, Suman Anna wrote:
>>>> On 02/09/2016 01:36 PM, Paul Walmsley wrote:
>>>>> On Tue, 9 Feb 2016, Suman Anna wrote:
>>>>>> On 02/09/2016 02:49 AM, Paul Walmsley wrote:
>>>>>>> On Mon, 8 Feb 2016, Suman Anna wrote:
>>>>>>>> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
>>>>>>>>> On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:
>>>>>>>>>
>>>>>>>>>> Paul, what do you think is the best way forward to perform reset?
>>>>>>>>>
>>>>>>>>> Many of the IP blocks with PRM hardreset lines are processor IP blocks. 
>>>>>>>>> Those often need special reset handling to ensure that WFI/HLT-like 
>>>>>>>>> instructions are executed after reset.  This special handling ensures that 
>>>>>>>>> the IP blocks' bus initiator interfaces indicate that they are in standby 
>>>>>>>>> to the PRCM - thus allowing power management for the rest of the chip to 
>>>>>>>>> work correctly.
>>>>>>>>>
>>>>>>>>> But that doesn't seem to be the case with PCIe - and maybe others - 
>>>>>>>>> possibly some of the MMUs?  
>>>>>>>>
>>>>>>>> Yeah, the sequencing between clocks and resets would still be the same
>>>>>>>> for MMUs, so, adding the custom flags for MMUs is fine.
>>>>>>>
>>>>>>> I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs.  
>>>>>>> We've stated that the main point of the custom hardreset code is to handle 
>>>>>>> processors that need to be placed into WFI/HLT, but it doesn't seem like 
>>>>>>> there would be an equivalent for MMUs.  Thoughts?
>>>>>>
>>>>>> The current OMAP IOMMU code already leverages the pdata ops for
>>>>>> performing the resets, so not adding the flags would also require
>>>>>> additional changes in the driver.
>>>>>>
>>>>>> Also, the reset lines controlling the MMUs actually also manage the
>>>>>> reset for all the other sub-modules other than the processor cores
>>>>>> within the sub-systems. We have currently different issues (see [1] for
>>>>>> eg. around the IPU sub-system entering RET in between), so from a PM
>>>>>> point of view, we do prefer to place the MMUs also in reset when we are
>>>>>> runtime suspended.
>>>>>
>>>>> Should we reassert hardreset in _idle() for IP blocks that don't have 
>>>>> HWMOD_CUSTOM_HARDRESET set on them?  Would that allow us to use this 
>>>>> mechanism for the uncore hardreset lines, or are there other quirks?
>>>>>
>>>>> Also - would that address the potential issue that you mentioned with the 
>>>>> PCIe block, or is that a different issue?
>>>>
>>>> Yeah, I think that would address the PCIe block issue in terms of reset
>>>> state balancing between pm_runtime_get_sync() and pm_runtime_put()
>>>> calls. Right now, they are unbalanced. The PCIe block is using these
>>>> only in probe and remove, so it should work for that IP.
>>>
>>> As I mentioned before this would result in undesired behavior during
>>> suspend/resume cycle in PCIe. (This should be okay for the current mainline
>>> code but would break once we add suspend/resume support for PCIe).
>>
>> I'd like to understand where we're currently at here.  It looks like we're 
>> waiting for testing from Suman, and we're waiting for Kishon to try using 
>> the bind/unbind driver model hook to see if that wedges PCIe?  Does this 
>> match your collective understanding of the status here?
> 
> I got to try this and looks like even without this series there are other PM
> issues possible introduced by Commit 5de85b9d57ab ("PM / runtime: Re-init
> runtime PM states at probe error and driver unbind").
> 
> Now I get this error if I tried to modprobe after rmmod pci-dra7xx.
> [   54.352860] dra7-pcie 51000000.pcie: omap_device: omap_device_enable()
> called from invalid state 1
> [   54.362318] dra7-pcie 51000000.pcie: pm_runtime_get_sync failed
> [   54.368624] dra7-pcie: probe of 51000000.pcie failed with error -22
> 
> From the thread that fixes this issue [1], looks like drivers that use
> *_autosuspend() get this issue. However I don't use *_autosuspend() in
> pci-dra7xx. Maybe pci core has this? This has to be debugged further. But I
> feel this is not related to the problem that we are trying to solve right now
> (dra7 hangs if PCI driver is enabled) and given the fact that pci-dra7xx driver
> is now modeled as built-in driver, this can be deferred.
> 
> [1] -> http://www.spinics.net/lists/arm-kernel/msg481845.html
> 
>>
>> Thinking about the question of what to do about hardreset assertion in 
>> idle, if we need it, we could add a hwmod flag to control that mode.  I 
>> would consider it a temporary workaround until we have the hwmod code 
>> moved into a bus driver and the bus driver/hwmod code can hook into the 
>> LDM .remove operation (and connect it to .shutdown, etc.)  Suman/Kishon: 
>> is it your understanding that we could remove the existing hardreset 
>> control in the IOMMU drivers and the PCIe driver if we had these options 
>> in the hwmod code? 
> 
> Yeah, that's my understanding. And since this series solves the PCIe problem,
> it's proven that hardreset control can be moved to hwmod code.
> 
> For PCIe, it's even okay to do deassert in _reset, but I'm not sure if it'll
> have side effects with other modules.
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index e9f65fe..24cafd9 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -1966,8 +1966,11 @@ static int _reset(struct omap_hwmod *oh)
>  		r = oh->class->reset(oh);
>  	} else {
>  		if (oh->rst_lines_cnt > 0) {
> -			for (i = 0; i < oh->rst_lines_cnt; i++)
> +			for (i = 0; i < oh->rst_lines_cnt; i++) {
>  				_assert_hardreset(oh, oh->rst_lines[i].name);
> +				if (!(oh->flags & HWMOD_CUSTOM_HARDRESET))
> +					_deassert_hardreset(oh, oh->rst_lines[i].name);
> +			}

Better yet, just add this specific  _deassert_hardreset logic to a DRA7
PCIe-specific class->reset function. You won't need adding the
HWMOD_CUSTOM_HARDRESET flags either and will satisfy your suspend/resume
dilemma, and it won't affect other paths. If that can work for you, that
would be simplest patch for this -rc cycle.

>  			return 0;
>  		} else {
>  			r = _ocp_softreset(oh);
> 
> Thanks
> Kishon
> 
> P.S. I'll be on vacation till end of next week with no email access till then.
> So email response will be delayed. Sorry about that.

Sekhar,
Will you be following up with above suggestion since Kishon is gonna be out?

regards
Suman

>>
>> Dave, any further comments here?
>>
>>
>> - Paul
>>



From laurent.pinchart at ideasonboard.com  Fri Feb 12 09:24:06 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Fri, 12 Feb 2016 19:24:06 +0200
Subject: [PATCH v2] iommu/io-pgtable: Rationalise quirk handling
In-Reply-To: <62860b753f304beef7b4b6f1e13d7094252f2f37.1455294748.git.robin.murphy@arm.com>
References: <cover.1453723096.git.robin.murphy@arm.com>
 <62860b753f304beef7b4b6f1e13d7094252f2f37.1455294748.git.robin.murphy@arm.com>
Message-ID: <27989114.h36RDrXrhS@avalon>

Hi Robin,

Thank you for the patch.

On Friday 12 February 2016 17:09:46 Robin Murphy wrote:
> As the number of io-pgtable implementations grows beyond 1, it's time
> to rationalise the quirks mechanism before things have a chance to
> start getting really ugly and out-of-hand.
> 
> To that end:
> - Indicate exactly which quirks each format can/does support.
> - Fail creating a table if a caller wants unsupported quirks.
> - Properly document where each quirk applies and why.
> 
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
> 
> Just to allay any confusion, I intend this as a followup to the
> short-descriptor[1] and Mediatek IOMMU[2] patches, rather than a
> crucial addition, so it can either get picked up along with those
> or wait 'til later.
> 
> v2:
> - Use unsigned long for the bitmap.
> - Do format-specific checks inline.
> - Enough of a difference that I don't feel comfortable putting
>   Laurent's reviewed-by from v1 on it...

Here it is again.

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> [1]:http://thread.gmane.org/gmane.linux.kernel.iommu/12007
> [2]:http://thread.gmane.org/gmane.linux.kernel.iommu/11974
> 
>  drivers/iommu/io-pgtable-arm-v7s.c |  5 +++++
>  drivers/iommu/io-pgtable-arm.c     | 13 +++++++++++--
>  drivers/iommu/io-pgtable.h         | 22 ++++++++++++++++++----
>  3 files changed, 34 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
> b/drivers/iommu/io-pgtable-arm-v7s.c index d39a021..9fcceb1 100644
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> @@ -623,6 +623,11 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct
> io_pgtable_cfg *cfg, if (cfg->ias > ARM_V7S_ADDR_BITS || cfg->oas >
> ARM_V7S_ADDR_BITS) return NULL;
> 
> +	if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
> +			    IO_PGTABLE_QUIRK_NO_PERMS |
> +			    IO_PGTABLE_QUIRK_TLBI_ON_MAP))
> +		return NULL;
> +
>  	data = kmalloc(sizeof(*data), GFP_KERNEL);
>  	if (!data)
>  		return NULL;
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 4095af2..debdf04 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -658,8 +658,12 @@ static struct io_pgtable *
>  arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, void *cookie)
>  {
>  	u64 reg;
> -	struct arm_lpae_io_pgtable *data = arm_lpae_alloc_pgtable(cfg);
> +	struct arm_lpae_io_pgtable *data;
> 
> +	if (cfg->quirks & ~IO_PGTABLE_QUIRK_ARM_NS)
> +		return NULL;
> +
> +	data = arm_lpae_alloc_pgtable(cfg);
>  	if (!data)
>  		return NULL;
> 
> @@ -742,8 +746,13 @@ static struct io_pgtable *
>  arm_64_lpae_alloc_pgtable_s2(struct io_pgtable_cfg *cfg, void *cookie)
>  {
>  	u64 reg, sl;
> -	struct arm_lpae_io_pgtable *data = arm_lpae_alloc_pgtable(cfg);
> +	struct arm_lpae_io_pgtable *data;
> 
> +	/* The NS quirk doesn't apply at stage 2 */
> +	if (cfg->quirks)
> +		return NULL;
> +
> +	data = arm_lpae_alloc_pgtable(cfg);
>  	if (!data)
>  		return NULL;
> 
> diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
> index 4faee7d..d4f5027 100644
> --- a/drivers/iommu/io-pgtable.h
> +++ b/drivers/iommu/io-pgtable.h
> @@ -47,10 +47,24 @@ struct iommu_gather_ops {
>   *                 page table walker.
>   */
>  struct io_pgtable_cfg {
> -	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0) /* Set NS bit in PTEs */
> -	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1) /* No AP/XN bits */
> -	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2) /* TLB Inv. on map */
> -	int				quirks;
> +	/*
> +	 * IO_PGTABLE_QUIRK_ARM_NS: (ARM formats) Set NS and NSTABLE bits in
> +	 *	stage 1 PTEs, for hardware which insists on validating them
> +	 *	even in	non-secure state where they should normally be ignored.
> +	 *
> +	 * IO_PGTABLE_QUIRK_NO_PERMS: Ignore the IOMMU_READ, IOMMU_WRITE and
> +	 *	IOMMU_NOEXEC flags and map everything with full access, for
> +	 *	hardware which does not implement the permissions of a given
> +	 *	format, and/or requires some format-specific default value.
> +	 *
> +	 * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching invalid
> +	 *	(unmapped) entries but the hardware might do so anyway, perform
> +	 *	TLB maintenance when mapping as well as when unmapping.
> +	 */
> +	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
> +	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
> +	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2)
> +	unsigned long			quirks;
>  	unsigned long			pgsize_bitmap;
>  	unsigned int			ias;
>  	unsigned int			oas;

-- 
Regards,

Laurent Pinchart



From robin.murphy at arm.com  Fri Feb 12 09:25:02 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Fri, 12 Feb 2016 17:25:02 +0000
Subject: [PATCH v2] iommu/io-pgtable: Rationalise quirk handling
In-Reply-To: <27989114.h36RDrXrhS@avalon>
References: <cover.1453723096.git.robin.murphy@arm.com>
 <62860b753f304beef7b4b6f1e13d7094252f2f37.1455294748.git.robin.murphy@arm.com>
 <27989114.h36RDrXrhS@avalon>
Message-ID: <56BE156E.3090707@arm.com>

On 12/02/16 17:24, Laurent Pinchart wrote:
> Hi Robin,
>
> Thank you for the patch.
>
> On Friday 12 February 2016 17:09:46 Robin Murphy wrote:
>> As the number of io-pgtable implementations grows beyond 1, it's time
>> to rationalise the quirks mechanism before things have a chance to
>> start getting really ugly and out-of-hand.
>>
>> To that end:
>> - Indicate exactly which quirks each format can/does support.
>> - Fail creating a table if a caller wants unsupported quirks.
>> - Properly document where each quirk applies and why.
>>
>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>> ---
>>
>> Just to allay any confusion, I intend this as a followup to the
>> short-descriptor[1] and Mediatek IOMMU[2] patches, rather than a
>> crucial addition, so it can either get picked up along with those
>> or wait 'til later.
>>
>> v2:
>> - Use unsigned long for the bitmap.
>> - Do format-specific checks inline.
>> - Enough of a difference that I don't feel comfortable putting
>>    Laurent's reviewed-by from v1 on it...
>
> Here it is again.
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

Thanks!

Robin.



From will.deacon at arm.com  Fri Feb 12 09:27:17 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 12 Feb 2016 17:27:17 +0000
Subject: [PATCH v2] iommu/io-pgtable: Rationalise quirk handling
In-Reply-To: <62860b753f304beef7b4b6f1e13d7094252f2f37.1455294748.git.robin.murphy@arm.com>
References: <cover.1453723096.git.robin.murphy@arm.com>
 <62860b753f304beef7b4b6f1e13d7094252f2f37.1455294748.git.robin.murphy@arm.com>
Message-ID: <20160212172716.GH17901@arm.com>

On Fri, Feb 12, 2016 at 05:09:46PM +0000, Robin Murphy wrote:
> As the number of io-pgtable implementations grows beyond 1, it's time
> to rationalise the quirks mechanism before things have a chance to
> start getting really ugly and out-of-hand.
> 
> To that end:
> - Indicate exactly which quirks each format can/does support.
> - Fail creating a table if a caller wants unsupported quirks.
> - Properly document where each quirk applies and why.
> 
> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> ---
> 
> Just to allay any confusion, I intend this as a followup to the
> short-descriptor[1] and Mediatek IOMMU[2] patches, rather than a
> crucial addition, so it can either get picked up along with those
> or wait 'til later.

I'd like to see it included in whichever tree takes the short-descriptor
code so, in case that's not my tree:

Acked-by: Will Deacon <will.deacon at arm.com>

Will


From sboyd at codeaurora.org  Fri Feb 12 09:30:17 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 12 Feb 2016 09:30:17 -0800
Subject: [PATCH] Revert "ASoC: qcom: Specify LE device endianness"
Message-ID: <1455298217-15744-1-git-send-email-sboyd@codeaurora.org>

This reverts commit 18560a4e3b07438113b50589e78532d95f907029.

The commit that caused us to specify LE device endianness here,
29bb45f25ff3 (regmap-mmio: Use native endianness for read/write,
2015-10-29), has been reverted in mainline so now when we specify
LE it actively breaks big endian kernels because the byte
swapping in regmap-mmio is incorrect. Let's revert this change
because it will 1) fix the big endian kernels and 2) be redundant
to specify LE because that will become the default soon.

Cc: Kenneth Westfield <kwestfie at codeaurora.org>
Cc: Kevin Hilman <khilman at linaro.org>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 sound/soc/qcom/lpass-cpu.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 00b6c9d039cf..e5101e0d2d37 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -355,7 +355,6 @@ static struct regmap_config lpass_cpu_regmap_config = {
 	.readable_reg = lpass_cpu_regmap_readable,
 	.volatile_reg = lpass_cpu_regmap_volatile,
 	.cache_type = REGCACHE_FLAT,
-	.val_format_endian = REGMAP_ENDIAN_LITTLE,
 };
 
 int asoc_qcom_lpass_cpu_platform_probe(struct platform_device *pdev)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From ard.biesheuvel at linaro.org  Fri Feb 12 09:32:31 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 18:32:31 +0100
Subject: [PATCH 1/2] arm64: mm: Enable CONT_SIZE aligned sections for 64k
 page kernels.
In-Reply-To: <CAKv+Gu-CYxr9jk=U-NrfRkyBhi0M2_9G+Mqx8fYeEEkRL8GnVw@mail.gmail.com>
References: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
 <1455293208-6763-2-git-send-email-jeremy.linton@arm.com>
 <CAKv+Gu_ViEAVN1GEDMWpJ5OYjg6BVSLTEtdus6vCCXchQ1BOjw@mail.gmail.com>
 <56BE0698.10506@arm.com>
 <CAKv+Gu--05Wn6oWEiy=43nzujNgG0=DpOB9b1zs9_jfddYXWwQ@mail.gmail.com>
 <56BE0BAB.7060502@arm.com>
 <CAKv+Gu-CYxr9jk=U-NrfRkyBhi0M2_9G+Mqx8fYeEEkRL8GnVw@mail.gmail.com>
Message-ID: <CAKv+Gu-ukreZPCJ6S-fdNwgjPvJZPWsWKanhri37ZR2bbmoZfg@mail.gmail.com>

On 12 February 2016 at 17:46, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 12 February 2016 at 17:43, Jeremy Linton <jeremy.linton at arm.com> wrote:
>> On 02/12/2016 10:28 AM, Ard Biesheuvel wrote:
>>>
>>> On 12 February 2016 at 17:21, Jeremy Linton <jeremy.linton at arm.com> wrote:
>>>>
>>>> On 02/12/2016 10:11 AM, Ard Biesheuvel wrote:
>>>>>
>>>>>
>>>>> On 12 February 2016 at 17:06, Jeremy Linton <jeremy.linton at arm.com>
>>>>> wrote:
>>>>
>>>>
>>>> (trimming)
>>>>>>
>>>>>>
>>>>>>    #if defined(CONFIG_DEBUG_ALIGN_RODATA)
>>>>>> -#define ALIGN_DEBUG_RO                 . = ALIGN(1<<SECTION_SHIFT);
>>>>>> -#define ALIGN_DEBUG_RO_MIN(min)                ALIGN_DEBUG_RO
>>>>>> +#if defined(CONFIG_ARM64_64K_PAGES)
>>>>>> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(CONT_SIZE);
>>>>>> +#else
>>>>>> +#define ALIGN_DEBUG_RO_MIN(min)                . =
>>>>>> ALIGN(SECTION_SIZE);
>>>>>
>>>>>
>>>>>
>>>>> Doesn't this align to 32 MB on 16k pages kernels?
>>>>
>>>>
>>>>
>>>> Yes, I considered whether it was more appropriate to use CONT_SIZE for
>>>> 16k
>>>> as well.
>>>>
>>>> Opinions?
>>>>
>>>
>>> Looking at vmlinux.lds.S, I see that that would put _stext and
>>> __init_begin at 32 MB aligned boundaries. making the size of the
>>> kernel at least 64 MB. If I take your .rodata patch into account,
>>> which adds a third instance of ALIGN_DEBUG_RO_MIN, the Image footprint
>>> will rise to ~100 MB. Or am I missing something?
>>>
>>
>> No, I think your correct. But, its an option, and it sort of depends on use
>> case. In a system with 100+GB of RAM it might be useful. Not so much on a
>> phone or small embedded system. I don't really see those people enabling
>> ALIGN_RODATA anyway. Worse, I expect the loss of RAM efficiently going from
>> 4k-16k pages in a RAM constrained system to be a pretty big hit too.
>>
>> I don't have any hard data one way or the other, and I don't have a strong
>> opinion. Although, I suspect at the moment the potential users of 16k pages
>> may tend toward the small side.
>>
>
> Well, the thing is, if you only use 2 MB of each 32 MB on average, you
> gain nothing by going from contiguous pages to proper sections, since
> the TLB footprint is the same. So my opinion would be to use CONT_SIZE
> for 16k pages as well.

Actually, none of this matters, since the physical alignment is not
guaranteed to be 32 MB. So anything beyond 2 MB is not really
meaningful imo


From kernel at martin.sperl.org  Fri Feb 12 09:34:27 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Fri, 12 Feb 2016 18:34:27 +0100
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in
 console
In-Reply-To: <662D2FB2-B088-4CFC-8416-A4F35BBAD7DD@sperl.org>
References: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
 <56BC895E.2010108@sperl.org>
 <1617009200.323700.219000a8-c162-4594-aacc-a7e9894518b2.open-xchange@email.1und1.de>
 <662D2FB2-B088-4CFC-8416-A4F35BBAD7DD@sperl.org>
Message-ID: <F7A2533A-D64C-4187-ABD4-416C446D1637@martin.sperl.org>


> On 12.02.2016, at 12:56, Martin Sperl <martin at sperl.org> wrote:
> 
> 
>> On 11.02.2016, at 18:55, Stefan Wahren <stefan.wahren at i2se.com> wrote:
>> I think the reason for this behavior can be found in the uart-pl011 driver which
>> plays with the clocks.
>> 
> I will look into the why and share what I find?

Well - just disabling CONFIG_SERIAL_AMBA_PL011_CONSOLE
in config still results in the early-boot getting
dumped to ttyAMA0 and the same behaviour
when starting getty on that tty: crash?

Similarly when compiled amba-pl011 as a module:
* strangely the boot messages still goes to ttyAMA
  - this may be something that uboot sets up?
  Maybe: earlycon-arm-semihost using SWI?
* loading the module works fine:
  [   65.458754] Serial: AMBA PL011 UART driver
  [   65.547204] 20201000.uart: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
* using ttyAMA0 (via getty) crashes the system.
  [   73.560708] uart-pl011 20201000.uart: no DMA platform data
  [   73.667150] bcm2835-clk 20101000.cprman: plld: couldn't lock PLL
  [   73.673305] ------------[ cut here ]------------
  [   73.678039] WARNING: CPU: 0 PID: 2377 at drivers/clk/clk.c:680 clk_core_disable+0x34/0xf0()
  [   73.687320] ---[ end trace e38a11a59bfd67ea ]---
  [   73.692196] ------------[ cut here ]------------
  [   73.696973] WARNING: CPU: 0 PID: 2377 at drivers/clk/clk.c:575 clk_core_unprepare+0x34/0x110()
  [   73.706709] ---[ end trace e38a11a59bfd67eb ]---


Now having instrumented clock and amba-pl011 with debug prints I get:

Boot sequence (logged to ttyAMA0 without a driver / earlycon0):

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.5.0-rc3+ (root at raspcm.intern.sperl.org) (gcc version 4.7.2 (Debian 4.7.2-5+rpi1) ) #91 Fri Feb 12 13:12:31 UTC 2016
[    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine model: Raspberry Pi Model B+
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: Data cache writeback
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
[    0.000000] Kernel command line: earlyprintk consoleblank=0 console=ttyS0,115200n1 root=/dev/mmcblk0p2 rootwait
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 445500K/458752K available (5768K kernel code, 418K rwdata, 1840K rodata, 420K init, 697K bss, 13252K reserved, 0K cma-reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xdc800000 - 0xff800000   ( 560 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xdc000000   ( 448 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0776394   (7609 kB)
[    0.000000]       .init : 0xc0777000 - 0xc07e0000   ( 420 kB)
[    0.000000]       .data : 0xc07e0000 - 0xc0848960   ( 419 kB)
[    0.000000]        .bss : 0xc0848960 - 0xc08f6f68   ( 698 kB)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000030] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483647500ns
[    0.008591] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
[    0.018176] bcm2835: system timer (irq = 27)
[    0.023023] Console: colour dummy device 80x30
[    0.027636] Calibrating delay loop... 697.95 BogoMIPS (lpj=3489792)
[    0.094228] pid_max: default: 32768 minimum: 301
[    0.099359] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.106197] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.114578] CPU: Testing write buffer coherency: ok
[    0.119730] ftrace: allocating 19776 entries in 58 pages
[    0.247172] Setting up static identity map for 0x8220 - 0x8258
[    0.257687] devtmpfs: initialized
[    0.267447] VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5
[    0.275647] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.286277] pinctrl core: initialized pinctrl subsystem
[    0.293168] NET: Registered protocol family 16
[    0.298438] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.313885] No ATAGs?
[    0.316051] hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.
[    0.323345] hw-breakpoint: maximum watchpoint size is 4 bytes.
?
[    0.366218] clocksource: Switched to clocksource timer
[    0.424382] simple-framebuffer 5e887000.framebuffer: framebuffer at 0x5e887000, 0x36c600 bytes, mapped to 0xdcc00000
[    0.435245] simple-framebuffer 5e887000.framebuffer: format=r5g6b5, mode=1824x984x16, linelength=3648
[    0.482137] Console: switching to colour frame buffer device 228x61
[    0.524351] simple-framebuffer 5e887000.framebuffer: fb0: simplefb registered
!
?
[    0.702577] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.711152] bcm2835-aux-uart 20215040.serial: could not get clk: -517
?
[    1.962031] usbhid: USB HID core driver
[    1.966329] bcm2835-clk 20101000.cprman: bcm2835_pll_get_rate - plla
[    1.972879] bcm2835-clk 20101000.cprman: bcm2835_pll_get_rate - pllb
[    1.979474] bcm2835-clk 20101000.cprman: bcm2835_pll_get_rate - pllc
[    1.986019] bcm2835-clk 20101000.cprman: bcm2835_pll_get_rate - plld
[    1.992608] bcm2835-clk 20101000.cprman: bcm2835_pll_get_rate - pllh
[    1.999375] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - timer
[    2.006434] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - timer
[    2.013468] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - otp
[    2.020318] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - otp
[    2.027000] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - tsens
[    2.033959] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - tsens
[    2.040831] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - vpu
[    2.047679] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - vpu
[    2.054431] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - v3d
[    2.061271] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - v3d
[    2.067966] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - isp
[    2.074749] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - isp
[    2.081445] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - h264
[    2.088358] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - h264
[    2.095120] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - sdram
[    2.102122] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - sdram
[    2.109230] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - uart
[    2.116108] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - uart
[    2.122907] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - vec
[    2.129734] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - vec
[    2.136449] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - hsm
[    2.143234] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - hsm
[    2.149939] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - emmc
[    2.156853] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - emmc
[    2.163615] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - pwm
[    2.170448] bcm2835-clk 20101000.cprman: bcm2835_clock_get_rate - pwm
[    2.177114] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - pwm
[    2.184451] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - pwm
[    2.191391] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - pwm
[    2.198247] bcm2835-clk 20101000.cprman: bcm2835_clock_get_parent - pwm
?
[    2.259033] bcm2835-clk 20101000.cprman: bcm2835_pll_on - pllc
[    2.265485] console [ttyS0] disabled
[    2.269377] 20215040.serial: ttyS0 at MMIO 0x0 (irq = 53, base_baud = 3122499
9) is a 16550
[    2.277931] console [ttyS0] enabled
[    2.285083] bootconsole [earlycon0] disabled

Boot sequence after earlycon0 to ttyS0:
[    2.277931] console [ttyS0] enabled
[    2.285083] bootconsole [earlycon0] disabled
[    2.294646] bcm2835-clk 20101000.cprman: bcm2835_clock_on - emmc
[    2.306321] usb 1-1: new high-speed USB device number 2 using dwc2
[    2.346289] mmc0: SDHCI controller on 20300000.sdhci [20300000.sdhci] using PIO
[    2.361549] Waiting for root device /dev/mmcblk0p2...
[    2.409495] mmc0: MAN_BKOPS_EN bit is not set
[    2.415026] mmc0: new MMC card at address 0001
[    2.420585] mmcblk0: mmc0:0001 4FEACB 3.64 GiB
[    2.425646] mmcblk0boot0: mmc0:0001 4FEACB partition 1 4.00 MiB
[    2.432466] mmcblk0boot1: mmc0:0001 4FEACB partition 2 4.00 MiB
[    2.439214] mmcblk0rpmb: mmc0:0001 4FEACB partition 3 512 KiB
[    2.447959]  mmcblk0: p1 p2
[    2.477939] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature incompatibilities
?
getty - Serial open on ttyS0, network up

Loading module:
root at raspcm:~# modprobe amba-pl011
[   59.238155] Serial: AMBA PL011 UART driver
[   59.245951] 20201000.uart: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud =2
root at raspcm:~#

And when starting getty ttyAMA0:
root at raspcm:~# /sbin/getty -a root -L ttyAMA0 115200 vt100
[   67.998916] pl011_startup - start
[   68.002326] pl011_hwinit - prepare-enable
[   68.006434] bcm2835-clk 20101000.cprman: bcm2835_pll_on - plld
[   68.012524] bcm2835-clk 20101000.cprman: bcm2835_clock_on - uart
[   68.018733] pl011_hwinit - prepare-enable - 0
[   68.024790] uart-pl011 20201000.uart: no DMA platform data
[   68.030693] pl011_startup - exit
[   68.038628] pl011_shutdown - start
[   68.042152] pl011_shutdown - disable_unprepare
[   68.046715] bcm2835-clk 20101000.cprman: bcm2835_clock_off - uart
[   68.053040] bcm2835-clk 20101000.cprman: bcm2835_clock_wait_busy - uart
[   68.059818] bcm2835-clk 20101000.cprman: bcm2835_pll_off - plld
[   68.065856] pl011_shutdown - exit

Note that I have now a hdmi display connected and the display
stops showing the framebuffer but the display goes off.

So it seems as if pl011_shutdown gets called for some reason,
which turns off the uart clock and as a consequence also the
plld gets shut down (probably ref-counting.

I wonder why we have the VPU as a secondary clock in the dt - 
amba-pll11 does not reference it anywhere.

When adding a return to bcm2835_pll_off it looks like this:
root at raspcm:~# /sbin/getty -a root -L ttyAMA0 115200 vt100
[   73.862152] pl011_startup - start
[   73.865558] pl011_hwinit - prepare-enable
[   73.869886] bcm2835-clk 20101000.cprman: bcm2835_pll_on - plld
[   73.875854] bcm2835-clk 20101000.cprman: bcm2835_clock_on - uart
[   73.882044] pl011_hwinit - prepare-enable - ret = 0
[   73.888126] uart-pl011 20201000.uart: no DMA platform data
[   73.893757] pl011_startup - exit
[   73.901495] pl011_shutdown - start
[   73.905034] pl011_shutdown - disable_unprepare
[   73.909742] bcm2835-clk 20101000.cprman: bcm2835_clock_off - uart
[   73.915967] bcm2835-clk 20101000.cprman: bcm2835_clock_wait_busy - uart
[   73.922775] bcm2835-clk 20101000.cprman: bcm2835_pll_off - plld
[   73.928844] pl011_shutdown - exit
[   73.934152] pl011_startup - start
[   73.937617] pl011_hwinit - prepare-enable
[   73.941726] bcm2835-clk 20101000.cprman: bcm2835_pll_on - plld
[   73.947738] bcm2835-clk 20101000.cprman: bcm2835_clock_on - uart
[   73.953865] pl011_hwinit - prepare-enable - ret = 0
[   73.959776] pl011_startup - exit

The ttyAMA0 console does not work, hdmi display blinks,
but the network works...

When removing the pll_on/off from the pll_ops I have a similar effect
but in this case PLL is not touched at all:
root at raspcm:~# /sbin/getty -a root -L ttyAMA0 115200 vt100
[   83.345055] pl011_startup - start
[   83.348580] pl011_hwinit - prepare-enable
[   83.352725] bcm2835-clk 20101000.cprman: bcm2835_clock_on - uart
[   83.358910] pl011_hwinit - prepare-enable - 0
[   83.365083] uart-pl011 20201000.uart: no DMA platform data
[   83.370790] pl011_startup - exit
[   83.378653] pl011_shutdown - start
[   83.382176] pl011_shutdown - disable_unprepare
[   83.386873] bcm2835-clk 20101000.cprman: bcm2835_clock_off - uart
[   83.393097] bcm2835-clk 20101000.cprman: bcm2835_clock_wait_busy - uart
[   83.399888] pl011_shutdown - exit
[   83.405164] pl011_startup - start
[   83.408652] pl011_hwinit - prepare-enable
[   83.412771] bcm2835-clk 20101000.cprman: bcm2835_clock_on - uart
[   83.418952] pl011_hwinit - prepare-enable - 0
[   83.423665] pl011_startup - exit

The system continues, but the UART still is not working and the
HDMI-Display is flashing only (but with a certain pattern on the
display: totally blue, then some wait, then a black horizontal bar
finally a full dark screen flash - that happens in a 3-4 second
cycle.

As if there is something else that requires the UART clock running
- maybe in the firmware?

Even making the uart clock a VPU clock does not help:
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 015e687..4856657 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -758,6 +761,7 @@ static const struct bcm2835_clock_data bcm2835_clock_uart_da
        .div_reg = CM_UARTDIV,
        .int_bits = 10,
        .frac_bits = 12,
+       .is_vpu_clock = true,
 };

 /* HDMI state machine */

This produces the following debug messages:
[   56.409818] pl011_startup - start
[   56.413225] pl011_hwinit - prepare-enable
[   56.417443] pl011_hwinit - prepare-enable - ret = 0
[   56.423297] uart-pl011 20201000.uart: no DMA platform data
[   56.428989] pl011_startup - exit
[   56.435485] pl011_shutdown - start
[   56.440337] pl011_shutdown - disable_unprepare
[   56.444913] pl011_shutdown - exit
[   56.449762] pl011_startup - start
[   56.453165] pl011_hwinit - prepare-enable
[   56.457371] pl011_hwinit - prepare-enable - ret = 0
[   56.462175] pl011_startup - exit

The screen is still blinking and UART does not work.
Maybe the driver is not able to handle the ?remapping?
of registers to a different range and is touching ram
used by the FW?

The only solution that I found is using fixed clocks
in the device-tree (which is not what we intended:
/ {
                clk_uart0: clock at 3 {
                        compatible = "fixed-clock";
                        reg = <3>;
                        #clock-cells = <0>;
                        clock-output-names = "uart0_pclk";
                        clock-frequency = <3000000>;
                };

                clk_apb_p: clock at 4 {
                        compatible = "fixed-clock";
                        reg = <4>;
                        #clock-cells = <0>;
                        clock-output-names = "apb_pclk";
                        clock-frequency = <126000000>;
                };
};
&uart0 {
        clocks = <&clk_uart0 &clk_apb_p>;
};

(so I have ruled out that the amba-pl011 writes to
the wrong addresses).

So as far as I can tell it is only clock related
and when the new clock-framework is used it fails...

Martin



From jeremy.linton at arm.com  Fri Feb 12 09:35:05 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Fri, 12 Feb 2016 11:35:05 -0600
Subject: [PATCH 2/2] arm64: Mark kernel page ranges contiguous
In-Reply-To: <20160212165707.GB20262@leverpostej>
References: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
 <1455293208-6763-3-git-send-email-jeremy.linton@arm.com>
 <20160212165707.GB20262@leverpostej>
Message-ID: <56BE17C9.6090608@arm.com>

On 02/12/2016 10:57 AM, Mark Rutland wrote:
(trimming)
 > On Fri, Feb 12, 2016 at 10:06:48AM -0600, Jeremy Linton wrote:
>> +static void clear_cont_pte_range(pte_t *pte, unsigned long addr)
>> +{
>> +	int i;
>> +
>> +	pte -= CONT_RANGE_OFFSET(addr);
>> +	for (i = 0; i < CONT_PTES; i++) {
>> +		if (pte_cont(*pte))
>> +			set_pte(pte, pte_mknoncont(*pte));
>> +		pte++;
>> +	}
>> +	flush_tlb_all();
>> +}
>
> As far as I can tell, "splitting" contiguous entries comes with the same
> caveats as splitting sections. In the absence of a BBM sequence we might
> end up with conflicting TLB entries.

As I mentioned a couple weeks ago, I'm not sure that inverting a BBM to 
a full "make partial copy of the whole table->break TTBR to copy 
sequence" is so bad if the copy process maintains references to the 
original table entries when they aren't in the modification path. It 
might even work with all the CPU's spun up because the break sequence 
would just be IPI's to the remaining cpu's to replace their TTBR/flush 
with a new value. I think you mentioned the ugly part is arbitrating 
access to the update functionality (and all the implied rules of when it 
could be done). But doing it that way doesn't require stalling the CPU's 
during the "make partial copy" portion.

> However, I think we're OK for now.
>
> The way we consistently map/unmap/modify image/linear "chunks" should
> prevent us from trying to split those, and if/when we do this for the
> EFI runtime page tables thy aren't live.
>
> It would be good to figure out how to get rid of the splitting entirely.

Well we could hoist some of it earlier by taking the 
create_mapping_late() calls and doing them earlier with RWX permissions, 
and then applying the RO,ROX,RW later as necessarily.

Which is ugly, but it might solve particular late splitting cases.


From mark.rutland at arm.com  Fri Feb 12 09:36:59 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 12 Feb 2016 17:36:59 +0000
Subject: [RFC PATCH 1/7] arm64/perf: Basic uncore counter support for
 Cavium ThunderX
In-Reply-To: <8bd93a25e069ed6428bc6c21fc53270962ccafcc.1455295032.git.jglauber@cavium.com>
References: <cover.1455295032.git.jglauber@cavium.com>
 <8bd93a25e069ed6428bc6c21fc53270962ccafcc.1455295032.git.jglauber@cavium.com>
Message-ID: <20160212173658.GD20262@leverpostej>

On Fri, Feb 12, 2016 at 05:55:06PM +0100, Jan Glauber wrote:
> Provide uncore facilities for non-CPU performance counter units.
> Based on Intel/AMD uncore pmu support.
> 
> The uncore PMUs can be found under /sys/bus/event_source/devices.
> All counters are exported via sysfs in the corresponding events
> files under the PMU directory so the perf tool can list the event names.

It turns out that "uncore" covers quite a lot of things.

Where exactly do the see counters live? system, socket, cluster?

Are there potentially multiple instances of a given PMU in the system?
e.g. might each clutster have an instance of an L2 PMU?

If I turn off a set of CPUs, do any "uncore" PMUs lost context or become
inaccessible?

Otherwise, are they associated with some power domain?

> There are 2 points that are special in this implementation:
> 
> 1) The PMU detection solely relies on PCI device detection. If a
>    matching PCI device is found the PMU is created. The code can deal
>    with multiple units of the same type, e.g. more than one memory
>    controller.

I see below that the driver has an initcall that runs regardless of
whether the PCI device exists, and looks at the MIDR. That's clearly not
string PCI device detection.

Why is this not a true PCI driver that only gets probed if the PCI
device exists? 

> 2) Counters are summarized across the different units of the same type,
>    e.g. L2C TAD 0..7 is presented as a single counter (adding the
>    values from TAD 0 to 7). Although losing the ability to read a
>    single value the merged values are easier to use and yield
>    enough information.

I'm not sure I follow this. What is easier? What are you doing, and what
are you comparing that with to say that your approach is easier?

It sounds like it should be possible to handle multiple counters like
this, so I don't follow why you want to amalgamate them in-kernel.

[...]

> +#include <asm/cpufeature.h>
> +#include <asm/cputype.h>

I don't see why you should need these two if this is truly an uncore
device probed solely from PCI.

> +void thunder_uncore_read(struct perf_event *event)
> +{
> +	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
> +	struct hw_perf_event *hwc = &event->hw;
> +	u64 prev, new = 0;
> +	s64 delta;
> +	int i;
> +
> +	/*
> +	 * since we do not enable counter overflow interrupts,
> +	 * we do not have to worry about prev_count changing on us
> +	 */

Without overflow interrupts, how do you ensure that you account for
overflow in a reasonable time window (i.e. before the counter runs past
its initial value)?

> +
> +	prev = local64_read(&hwc->prev_count);
> +
> +	/* read counter values from all units */
> +	for (i = 0; i < uncore->nr_units; i++)
> +		new += readq(map_offset(hwc->event_base, uncore, i));

There's no bit to determine whether an overflow occurred?

> +
> +	local64_set(&hwc->prev_count, new);
> +	delta = new - prev;
> +	local64_add(delta, &event->count);
> +}
> +
> +void thunder_uncore_del(struct perf_event *event, int flags)
> +{
> +	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
> +	struct hw_perf_event *hwc = &event->hw;
> +	int i;
> +
> +	event->pmu->stop(event, PERF_EF_UPDATE);
> +
> +	for (i = 0; i < uncore->num_counters; i++) {
> +		if (cmpxchg(&uncore->events[i], event, NULL) == event)
> +			break;
> +	}
> +	hwc->idx = -1;
> +}

Why not just place the event at uncode->events[hwc->idx] ?

Theat way removing the event is trivial.

> +int thunder_uncore_event_init(struct perf_event *event)
> +{
> +	struct hw_perf_event *hwc = &event->hw;
> +	struct thunder_uncore *uncore;
> +
> +	if (event->attr.type != event->pmu->type)
> +		return -ENOENT;
> +
> +	/* we do not support sampling */
> +	if (is_sampling_event(event))
> +		return -EINVAL;
> +
> +	/* counters do not have these bits */
> +	if (event->attr.exclude_user	||
> +	    event->attr.exclude_kernel	||
> +	    event->attr.exclude_host	||
> +	    event->attr.exclude_guest	||
> +	    event->attr.exclude_hv	||
> +	    event->attr.exclude_idle)
> +		return -EINVAL;

We should _really_ make these features opt-in at the core level. It's
crazy that each and every PMU drivers has to explicitly test and reject
things it doesn't support.

> +
> +	/* and we do not enable counter overflow interrupts */

That statement raises far more questions than it answers.

_why_ do we not user overflow interrupts?

> +
> +	uncore = event_to_thunder_uncore(event);
> +	if (!uncore)
> +		return -ENODEV;
> +	if (!uncore->event_valid(event->attr.config))
> +		return -EINVAL;
> +
> +	hwc->config = event->attr.config;
> +	hwc->idx = -1;
> +
> +	/* and we don't care about CPU */

Actually, you do. You want the perf core to serialize accesses via the
same CPU, so all events _must_ be targetted at the same CPU. Otherwise
there are a tonne of problems you don't even want to think about.

You _must_ ensure this kernel-side, regardless of what the perf tool
happens to do.

See the arm-cci and arm-ccn drivers for an example.

You can also follow the migration approach used there to allow you to
retain counting across a hotplug.

[...]

> +static int __init thunder_uncore_init(void)
> +{
> +	unsigned long implementor = read_cpuid_implementor();
> +	unsigned long part_number = read_cpuid_part_number();
> +	u32 variant;
> +
> +	if (implementor != ARM_CPU_IMP_CAVIUM ||
> +	    part_number != CAVIUM_CPU_PART_THUNDERX)
> +		return -ENODEV;
> +
> +	/* detect pass2 which contains different counters */
> +	variant = MIDR_VARIANT(read_cpuid_id());
> +	if (variant == 1)
> +		thunder_uncore_version = 1;
> +	pr_info("PMU version: %d\n", thunder_uncore_version);
> +
> +	return 0;
> +}

You should call out these differences in the commmit message.

Mark.


From yang.shi at linaro.org  Fri Feb 12 09:38:51 2016
From: yang.shi at linaro.org (Shi, Yang)
Date: Fri, 12 Feb 2016 09:38:51 -0800
Subject: [PATCH] arm64: make irq_stack_ptr more robust
In-Reply-To: <56BDE260.20504@arm.com>
References: <1455227590-9837-1-git-send-email-yang.shi@linaro.org>
 <56BDE260.20504@arm.com>
Message-ID: <56BE18AB.4090902@linaro.org>

On 2/12/2016 5:47 AM, James Morse wrote:
> Hi!
>
> On 11/02/16 21:53, Yang Shi wrote:
>> Switching between stacks is only valid if we are tracing ourselves while on the
>> irq_stack, so it is only valid when in current and non-preemptible context,
>> otherwise is is just zeroed off.
>
> Given it was picked up with CONFIG_DEBUG_PREEMPT:
>
> Fixes: 132cd887b5c5 ("arm64: Modify stack trace and dump for use with irq_stack")

Wii add in v2.

>
>
>> Signed-off-by: Yang Shi <yang.shi at linaro.org>
>> ---
>>   arch/arm64/kernel/stacktrace.c | 13 ++++++-------
>>   arch/arm64/kernel/traps.c      | 11 ++++++++++-
>>   2 files changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
>> index 12a18cb..d9751a4 100644
>> --- a/arch/arm64/kernel/stacktrace.c
>> +++ b/arch/arm64/kernel/stacktrace.c
>> @@ -44,14 +44,13 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
>>   	unsigned long irq_stack_ptr;
>>
>>   	/*
>> -	 * Use raw_smp_processor_id() to avoid false-positives from
>> -	 * CONFIG_DEBUG_PREEMPT. get_wchan() calls unwind_frame() on sleeping
>> -	 * task stacks, we can be pre-empted in this case, so
>> -	 * {raw_,}smp_processor_id() may give us the wrong value. Sleeping
>> -	 * tasks can't ever be on an interrupt stack, so regardless of cpu,
>> -	 * the checks will always fail.
>> +	 * Switching between stacks is valid when tracing current and in
>> +	 * non-preemptible context.
>>   	 */
>> -	irq_stack_ptr = IRQ_STACK_PTR(raw_smp_processor_id());
>> +	if (tsk == current && !preemptible())
>> +		irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
>> +	else
>> +		irq_stack_ptr = 0;
>>
>>   	low  = frame->sp;
>>   	/* irq stacks are not THREAD_SIZE aligned */
>> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
>> index cbedd72..7d8db3a 100644
>> --- a/arch/arm64/kernel/traps.c
>> +++ b/arch/arm64/kernel/traps.c
>> @@ -146,9 +146,18 @@ static void dump_instr(const char *lvl, struct pt_regs *regs)
>>   static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
>>   {
>>   	struct stackframe frame;
>> -	unsigned long irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
>> +	unsigned long irq_stack_ptr;
>>   	int skip;
>>
>> +	/*
>> +	 * Switching between  stacks is valid when tracing current and in
>
> Nit: Two spaces: "between[ ][ ]stacks"

Will fix in v2.

>
>
>> +	 * non-preemptible context.
>> +	 */
>> +	if (tsk == current && !preemptible())
>> +		irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
>> +	else
>> +		irq_stack_ptr = 0;
>> +
>>   	pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
>>
>>   	if (!tsk)
>>
>
> Neither file includes 'linux/preempt.h' for the definition of preemptible().
> (I can't talk: I should have included smp.h for smp_processor_id())

I tried to build the kernel with preempt and without preempt, both 
works. And, I saw arch/arm64/include/asm/Kbuild has:

generic-y += preempt.h

So, it sounds preempt.h has been included by default.

Thanks,
Yang

>
>
> Acked-by: James Morse <james.morse at arm.com>
> Tested-by: James Morse <james.morse at arm.com>
>
>
> Thanks!
>
> James
>
>



From will.deacon at arm.com  Fri Feb 12 09:41:16 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 12 Feb 2016 17:41:16 +0000
Subject: [PATCH] arm64: make irq_stack_ptr more robust
In-Reply-To: <56BE18AB.4090902@linaro.org>
References: <1455227590-9837-1-git-send-email-yang.shi@linaro.org>
 <56BDE260.20504@arm.com> <56BE18AB.4090902@linaro.org>
Message-ID: <20160212174116.GI17901@arm.com>

On Fri, Feb 12, 2016 at 09:38:51AM -0800, Shi, Yang wrote:
> On 2/12/2016 5:47 AM, James Morse wrote:
> >On 11/02/16 21:53, Yang Shi wrote:
> >>Switching between stacks is only valid if we are tracing ourselves while on the
> >>irq_stack, so it is only valid when in current and non-preemptible context,
> >>otherwise is is just zeroed off.
> >
> >Given it was picked up with CONFIG_DEBUG_PREEMPT:
> >
> >Fixes: 132cd887b5c5 ("arm64: Modify stack trace and dump for use with irq_stack")
> 
> Wii add in v2.

I already queued the patch with this and the whitespace fix, so no need
for a v2.

Will


From yang.shi at linaro.org  Fri Feb 12 09:43:11 2016
From: yang.shi at linaro.org (Shi, Yang)
Date: Fri, 12 Feb 2016 09:43:11 -0800
Subject: [PATCH] arm64: make irq_stack_ptr more robust
In-Reply-To: <20160212174116.GI17901@arm.com>
References: <1455227590-9837-1-git-send-email-yang.shi@linaro.org>
 <56BDE260.20504@arm.com> <56BE18AB.4090902@linaro.org>
 <20160212174116.GI17901@arm.com>
Message-ID: <56BE19AF.7000605@linaro.org>

On 2/12/2016 9:41 AM, Will Deacon wrote:
> On Fri, Feb 12, 2016 at 09:38:51AM -0800, Shi, Yang wrote:
>> On 2/12/2016 5:47 AM, James Morse wrote:
>>> On 11/02/16 21:53, Yang Shi wrote:
>>>> Switching between stacks is only valid if we are tracing ourselves while on the
>>>> irq_stack, so it is only valid when in current and non-preemptible context,
>>>> otherwise is is just zeroed off.
>>>
>>> Given it was picked up with CONFIG_DEBUG_PREEMPT:
>>>
>>> Fixes: 132cd887b5c5 ("arm64: Modify stack trace and dump for use with irq_stack")
>>
>> Wii add in v2.
>
> I already queued the patch with this and the whitespace fix, so no need
> for a v2.

Thanks so much.

Yang

>
> Will
>



From aleksey.makarov at linaro.org  Fri Feb 12 09:43:31 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Fri, 12 Feb 2016 20:43:31 +0300
Subject: [PATCH v2 0/9] ACPI: parse the SPCR table
Message-ID: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>

This patchset is based on the patchset by Leif Lindholm [1]

'ARM Server Base Boot Requirements' [2] mentions SPCR (Serial Port
Console Redirection Table) [3] as a mandatory ACPI table that
specifies the configuration of serial console.

SPCR support is included in QEMU's ARM mach-virt since 2.4 release.

Parse the SPCR table and check if any registered console matches the
description.  If it does, enable that console.

Also add an implementation of this member function to the pl011 and 8250
drivers, fix a minor issue in printk.c and use SPCR to tell if SBSA serial
driver should use 32-bit access to registers.
To be able to access SPCR table each time any console is registered
change __init to __ref for early_acpi_os_unmap_memory()
and introduce acpi_table_parse2() in separate patches.

The patchset should be applied to tty-next.

v2:
- don't use SPCR if user specified console in command line
- fix initialization order of newcon->index = 0
- rename some variables at printk.c (Joe Perches, Peter Hurley)
- enable ACPI_SPCR_TABLE in a separate patch (Andy Shevchenko)
- remove the retry loop for console registering (Peter Hurley).
  Instead, obtain SPCR with acpi_get_table().  That works after
  call to acpi_early_init() i. e. in any *_initcall()
- describe design decision behind introducing acpi_match() (Peter Hurley)
- fix compilation for x86 + ACPI (Graeme Gregory)
- introduce DBG2 constants in a separate patch (Andy Shevchenko)
- fix a typo in DBG2 constants (Andy Shevchenko)
- add ACPI_DBG2_ARM_SBSA_32BIT constant (Christopher Covington)
- add support for ACPI_DBG2_ARM_SBSA_* consoles (Christopher Covington)
- add documentation for functions
- add a patch that uses SPCR to find if SBSA serial driver should use 32-bit
  accessor functions (Christopher Covington)
- change __init to __ref for early_acpi_os_unmap_memory() in a separate patch
- introduce acpi_table_parse2() in a separate patch
- fix fetching the SPCR table early (Mark Salter)
- add a patch from Mark Salter that introduces support for matching 8250-based
  consoles

v1:
https://lkml.kernel.org/g/1453722324-22407-1-git-send-email-aleksey.makarov at linaro.org

[1] https://lkml.kernel.org/g/1441716217-23786-1-git-send-email-leif.lindholm at linaro.org
[2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
[3] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx

Aleksey Makarov (8):
  printk: fix name and type of some variables
  ACPI: Change __init to __ref for early_acpi_os_unmap_memory()
  ACPI: introduce acpi_table_parse2()
  ACPI: parse SPCR and enable matching console
  ACPI: enable ACPI_SPCR_TABLE on ARM64
  ACPI: add definition of DBG2 subtypes
  serial: pl011: add acpi_match
  serial: pl011: use SPCR to setup 32-bit access

Mark Salter (1):
  serial: 8250: add acpi_match

 arch/arm64/Kconfig                  |   1 +
 drivers/acpi/Kconfig                |   3 +
 drivers/acpi/Makefile               |   1 +
 drivers/acpi/osl.c                  |   6 +-
 drivers/acpi/spcr.c                 | 106 ++++++++++++++++++++++++++++++++++++
 drivers/acpi/tables.c               |  49 ++++++++++++++---
 drivers/tty/serial/8250/8250_core.c |  23 ++++++++
 drivers/tty/serial/amba-pl011.c     |  24 ++++++++
 include/acpi/actbl2.h               |   5 ++
 include/linux/acpi.h                |   8 +++
 include/linux/console.h             |  17 ++++++
 kernel/printk/printk.c              |  40 ++++++++++----
 12 files changed, 264 insertions(+), 19 deletions(-)
 create mode 100644 drivers/acpi/spcr.c

-- 
2.7.0



From aleksey.makarov at linaro.org  Fri Feb 12 09:43:32 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Fri, 12 Feb 2016 20:43:32 +0300
Subject: [PATCH v2 1/9] printk: fix name and type of some variables
In-Reply-To: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1455299022-11641-2-git-send-email-aleksey.makarov@linaro.org>

The variable preferred_console is used only inside register_console()
and its semantics is boolean.  It is negative when no console has been
made preferred.

The variable selected_console holds an index into the console_cmdline
array, pointing to the console that was made preferred.

Rename the variables:
selected_console -> preferred_console
preferred_console -> has_preferred
and make the new has_preferred local static bool.

This is a preparatory patch.  To introduce selection with
ACPI SPCR table we should decide which value (old) preferred_console
should hold in the case when the console was set by ACPI.

Renaming was suggested by Peter Hurley

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
Tested-by: Christopher Covington <cov at codeaurora.org>
---
 kernel/printk/printk.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index c963ba5..0cc9542 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -143,7 +143,6 @@ static struct console *exclusive_console;
 
 static struct console_cmdline console_cmdline[MAX_CMDLINECONSOLES];
 
-static int selected_console = -1;
 static int preferred_console = -1;
 int console_set_on_cmdline;
 EXPORT_SYMBOL(console_set_on_cmdline);
@@ -1997,14 +1996,14 @@ static int __add_preferred_console(char *name, int idx, char *options,
 	     i++, c++) {
 		if (strcmp(c->name, name) == 0 && c->index == idx) {
 			if (!brl_options)
-				selected_console = i;
+				preferred_console = i;
 			return 0;
 		}
 	}
 	if (i == MAX_CMDLINECONSOLES)
 		return -E2BIG;
 	if (!brl_options)
-		selected_console = i;
+		preferred_console = i;
 	strlcpy(c->name, name, sizeof(c->name));
 	c->options = options;
 	braille_set_options(c, brl_options);
@@ -2490,6 +2489,7 @@ void register_console(struct console *newcon)
 	unsigned long flags;
 	struct console *bcon = NULL;
 	struct console_cmdline *c;
+	static bool has_preferred;
 
 	if (console_drivers)
 		for_each_console(bcon)
@@ -2516,15 +2516,15 @@ void register_console(struct console *newcon)
 	if (console_drivers && console_drivers->flags & CON_BOOT)
 		bcon = console_drivers;
 
-	if (preferred_console < 0 || bcon || !console_drivers)
-		preferred_console = selected_console;
+	if (!has_preferred || bcon || !console_drivers)
+		has_preferred = preferred_console >= 0;
 
 	/*
 	 *	See if we want to use this console driver. If we
 	 *	didn't select a console we take the first one
 	 *	that registers here.
 	 */
-	if (preferred_console < 0) {
+	if (!has_preferred) {
 		if (newcon->index < 0)
 			newcon->index = 0;
 		if (newcon->setup == NULL ||
@@ -2532,7 +2532,7 @@ void register_console(struct console *newcon)
 			newcon->flags |= CON_ENABLED;
 			if (newcon->device) {
 				newcon->flags |= CON_CONSDEV;
-				preferred_console = 0;
+				has_preferred = true;
 			}
 		}
 	}
@@ -2565,9 +2565,9 @@ void register_console(struct console *newcon)
 		}
 
 		newcon->flags |= CON_ENABLED;
-		if (i == selected_console) {
+		if (i == preferred_console) {
 			newcon->flags |= CON_CONSDEV;
-			preferred_console = selected_console;
+			has_preferred = true;
 		}
 		break;
 	}
-- 
2.7.0



From aleksey.makarov at linaro.org  Fri Feb 12 09:43:33 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Fri, 12 Feb 2016 20:43:33 +0300
Subject: [PATCH v2 2/9] ACPI: Change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1455299022-11641-3-git-send-email-aleksey.makarov@linaro.org>

early_acpi_os_unmap_memory() is marked as __init because it calls
__acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is not set.

acpi_gbl_permanent_mmap is set in __init acpi_early_init()
so it is safe to call early_acpi_os_unmap_memory() from anywhere

We need this function to be non-__init because we need access to
some tables at unpredictable time--it may be before or after
acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port Console
Redirection) table is needed each time a new console is registered.
It can be quite early (console_initcall) or when a module is inserted.
When this table accessed before acpi_gbl_permanent_mmap is set,
the pointer should be unmapped.  This is exactly what this function
does.

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 drivers/acpi/osl.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 67da6fb..8a552cd 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void *virt, acpi_size size)
 }
 EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
 
-void __init early_acpi_os_unmap_memory(void __iomem *virt, acpi_size size)
+/*
+ * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
+ * so it is safe to call early_acpi_os_unmap_memory() from anywhere
+ */
+void __ref early_acpi_os_unmap_memory(void __iomem *virt, acpi_size size)
 {
 	if (!acpi_gbl_permanent_mmap)
 		__acpi_unmap_table(virt, size);
-- 
2.7.0



From aleksey.makarov at linaro.org  Fri Feb 12 09:43:34 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Fri, 12 Feb 2016 20:43:34 +0300
Subject: [PATCH v2 3/9] ACPI: introduce acpi_table_parse2()
In-Reply-To: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1455299022-11641-4-git-send-email-aleksey.makarov@linaro.org>

The function acpi_table_parse() has some problems:
1 It can be called only from __init code
2 It does not pass any data to the handler
3 It just throws out the value returned from the handler

These issues are addressed in this patch

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 drivers/acpi/tables.c | 49 ++++++++++++++++++++++++++++++++++++++++++-------
 include/linux/acpi.h  |  8 ++++++++
 2 files changed, 50 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 6c0f079..98ae052 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -40,7 +40,7 @@ static char *mps_inti_flags_trigger[] = { "dfl", "edge", "res", "level" };
 
 static struct acpi_table_desc initial_tables[ACPI_MAX_TABLES] __initdata;
 
-static int acpi_apic_instance __initdata;
+static int acpi_apic_instance;
 
 /*
  * Disable table checksum verification for the early stage due to the size
@@ -374,19 +374,27 @@ acpi_table_parse_madt(enum acpi_madt_type id,
 }
 
 /**
- * acpi_table_parse - find table with @id, run @handler on it
+ * acpi_table_parse2 - find table with @id, run @handler on it
  * @id: table id to find
  * @handler: handler to run
+ * @data: data to pass to handler
  *
  * Scan the ACPI System Descriptor Table (STD) for a table matching @id,
  * run @handler on it.
  *
- * Return 0 if table found, -errno if not.
+ * How it differs from acpi_table_parse()
+ * 1. It respect the return value of the handler function
+ * 2. It has additional data argument to make closures
+ * 3. It can be called from everywhere from the kernel (no __init)
+ *
+ * Return: the value returned by the handler if table found, -errno if not.
  */
-int __init acpi_table_parse(char *id, acpi_tbl_table_handler handler)
+int acpi_table_parse2(char *id,
+	int (*handler)(struct acpi_table_header *table, void *data), void *data)
 {
 	struct acpi_table_header *table = NULL;
 	acpi_size tbl_size;
+	int err;
 
 	if (acpi_disabled)
 		return -ENODEV;
@@ -395,16 +403,43 @@ int __init acpi_table_parse(char *id, acpi_tbl_table_handler handler)
 		return -EINVAL;
 
 	if (strncmp(id, ACPI_SIG_MADT, 4) == 0)
-		acpi_get_table_with_size(id, acpi_apic_instance, &table, &tbl_size);
+		acpi_get_table_with_size(id, acpi_apic_instance, &table,
+					 &tbl_size);
 	else
 		acpi_get_table_with_size(id, 0, &table, &tbl_size);
 
 	if (table) {
-		handler(table);
+		err = handler(table, data);
 		early_acpi_os_unmap_memory(table, tbl_size);
-		return 0;
+		return err;
 	} else
 		return -ENODEV;
+
+}
+
+/*
+ * 1. fix the signature
+ * 2. always return 0, don't respect the value returned from the handler
+ */
+static int legacy_acpi_table_handler(struct acpi_table_header *table, void *d)
+{
+	((acpi_tbl_table_handler)d)(table);
+	return 0;
+}
+
+/**
+ * acpi_table_parse - find table with @id, run @handler on it
+ * @id: table id to find
+ * @handler: handler to run
+ *
+ * Scan the ACPI System Descriptor Table (STD) for a table matching @id,
+ * run @handler on it.
+ *
+ * Return 0 if table found, -errno if not.
+ */
+int __init acpi_table_parse(char *id, acpi_tbl_table_handler handler)
+{
+	return acpi_table_parse2(id, legacy_acpi_table_handler, handler);
 }
 
 /* 
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 06ed7e5..bed9b89 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -218,6 +218,8 @@ int acpi_numa_init (void);
 
 int acpi_table_init (void);
 int acpi_table_parse(char *id, acpi_tbl_table_handler handler);
+int acpi_table_parse2(char *id, int (*handler)(struct acpi_table_header *table,
+					       void *data), void *data);
 int __init acpi_parse_entries(char *id, unsigned long table_size,
 			      acpi_tbl_entry_handler handler,
 			      struct acpi_table_header *table_header,
@@ -636,6 +638,12 @@ static inline int acpi_table_parse(char *id,
 	return -ENODEV;
 }
 
+int acpi_table_parse2(char *id, int (*handler)(struct acpi_table_header *table,
+					       void *data), void *data)
+{
+	return -ENODEV;
+}
+
 static inline int acpi_nvs_register(__u64 start, __u64 size)
 {
 	return 0;
-- 
2.7.0



From aleksey.makarov at linaro.org  Fri Feb 12 09:43:37 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Fri, 12 Feb 2016 20:43:37 +0300
Subject: [PATCH v2 6/9] ACPI: add definition of DBG2 subtypes
In-Reply-To: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1455299022-11641-7-git-send-email-aleksey.makarov@linaro.org>

The recent version of Microsoft Debug Port Table 2 (DBG2) [1]
specifies additional serial debug port subtypes.  These constants
are also referred by Serial Port Console Redirection Table (SPCR) [2]

Add these constants.

[1] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
[2] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
Tested-by: Christopher Covington <cov at codeaurora.org>
---
 include/acpi/actbl2.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index a4ef625..e9930ab 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -371,6 +371,11 @@ struct acpi_dbg2_device {
 
 #define ACPI_DBG2_16550_COMPATIBLE  0x0000
 #define ACPI_DBG2_16550_SUBSET      0x0001
+#define ACPI_DBG2_ARM_PL011         0x0003
+#define ACPI_DBG2_ARM_SBSA_32BIT    0x000d
+#define ACPI_DBG2_ARM_SBSA_GENERIC  0x000e
+#define ACPI_DBG2_ARM_DCC           0x000f
+#define ACPI_DBG2_BCM2835           0x0010
 
 #define ACPI_DBG2_1394_STANDARD     0x0000
 
-- 
2.7.0



From aleksey.makarov at linaro.org  Fri Feb 12 09:43:35 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Fri, 12 Feb 2016 20:43:35 +0300
Subject: [PATCH v2 4/9] ACPI: parse SPCR and enable matching console
In-Reply-To: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1455299022-11641-5-git-send-email-aleksey.makarov@linaro.org>

'ARM Server Base Boot Requiremets' [1] mentions SPCR (Serial Port
Console Redirection Table) [2] as a mandatory ACPI table that
specifies the configuration of serial console.

Parse this table and check if any registered console match the
description.  If it does, enable that console.

In the original submission [3] the ACPI devices are traversed to find
one that has the same address as specified by SPCR. Then while
registering a serial device it is checked if it has an ACPI companion
and it is the same device that was found at traversal. If so,
add_preferred_console() was used to specify the device as preferred.
The console name and index are known at the time of registration of
serial device.

The problem is that SPCR can specify the console not only by the base
address but also with PCI Device ID/PCI Vendor ID or PCI Bus
Number/PCI Device Number.  In general, there is no way to get serial
name and index from the SPCR table.

To implement that, introduce a new member

        int (*acpi_match)(struct console *, struct acpi_table_spcr *)

of struct console.  It allows drivers to check if they provide a
matching console device.

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
[2] http://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
[3] https://lkml.kernel.org/g/1441716217-23786-1-git-send-email-leif.lindholm at linaro.org

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 drivers/acpi/Kconfig    |  3 ++
 drivers/acpi/Makefile   |  1 +
 drivers/acpi/spcr.c     | 77 +++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/console.h | 12 ++++++++
 kernel/printk/printk.c  | 22 ++++++++++++--
 5 files changed, 113 insertions(+), 2 deletions(-)
 create mode 100644 drivers/acpi/spcr.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 65fb483..5611eb6 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -77,6 +77,9 @@ config ACPI_DEBUGGER_USER
 
 endif
 
+config ACPI_SPCR_TABLE
+	bool
+
 config ACPI_SLEEP
 	bool
 	depends on SUSPEND || HIBERNATION
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 346101c..708b143 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_ACPI_EC_DEBUGFS)	+= ec_sys.o
 obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
 obj-$(CONFIG_ACPI_BGRT)		+= bgrt.o
 obj-$(CONFIG_ACPI_CPPC_LIB)	+= cppc_acpi.o
+obj-$(CONFIG_ACPI_SPCR_TABLE)	+= spcr.o
 obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
 
 # processor has its own "processor." module_param namespace
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
new file mode 100644
index 0000000..0475840
--- /dev/null
+++ b/drivers/acpi/spcr.c
@@ -0,0 +1,77 @@
+/*
+ * Copyright (c) 2012, Intel Corporation
+ * Copyright (c) 2015, Red Hat, Inc.
+ * Copyright (c) 2015, 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/acpi.h>
+#include <linux/console.h>
+#include <linux/kernel.h>
+
+struct spcr_table_handler_match_data {
+	struct console *console;
+	char **options;
+};
+
+static int spcr_table_handler_match(struct acpi_table_header *t, void *d)
+{
+	struct acpi_table_spcr *table = (struct acpi_table_spcr *)t;
+	struct spcr_table_handler_match_data *data = d;
+	int err;
+
+	if (table->header.revision < 2)
+		return -EOPNOTSUPP;
+
+	err = data->console->acpi_match(data->console, table);
+	if (err < 0)
+		return err;
+
+	if (data->options) {
+		switch (table->baud_rate) {
+		case 3:
+			*data->options = "9600";
+			break;
+		case 4:
+			*data->options = "19200";
+			break;
+		case 6:
+			*data->options = "57600";
+			break;
+		case 7:
+			*data->options = "115200";
+			break;
+		default:
+			*data->options = "";
+			break;
+		}
+	}
+
+	return err;
+}
+
+/**
+ * acpi_console_match - Check if console matches one specified by SPCR.
+ *
+ * @console:	console to match
+ * @options:	if the console matches, this will return options for the console
+ *		as in kernel command line
+ *
+ * Return: a non-error value if the console matches.
+ */
+int acpi_console_match(struct console *console, char **options)
+{
+	struct spcr_table_handler_match_data d = {
+		.console = console,
+		.options = options,
+	};
+
+	if (acpi_disabled || !console->acpi_match || console_set_on_cmdline)
+		return -ENODEV;
+
+	return acpi_table_parse2(ACPI_SIG_SPCR, spcr_table_handler_match, &d);
+}
diff --git a/include/linux/console.h b/include/linux/console.h
index ea731af..dcc2b59 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -15,6 +15,7 @@
 #define _LINUX_CONSOLE_H_ 1
 
 #include <linux/types.h>
+#include <linux/errno.h>
 
 struct vc_data;
 struct console_font_op;
@@ -117,6 +118,7 @@ static inline int con_debug_leave(void)
 #define CON_BRL		(32) /* Used for a braille device */
 #define CON_EXTENDED	(64) /* Use the extended output format a la /dev/kmsg */
 
+struct acpi_table_spcr;
 struct console {
 	char	name[16];
 	void	(*write)(struct console *, const char *, unsigned);
@@ -125,6 +127,7 @@ struct console {
 	void	(*unblank)(void);
 	int	(*setup)(struct console *, char *);
 	int	(*match)(struct console *, char *name, int idx, char *options);
+	int	(*acpi_match)(struct console *, struct acpi_table_spcr *);
 	short	flags;
 	short	index;
 	int	cflag;
@@ -132,6 +135,15 @@ struct console {
 	struct	 console *next;
 };
 
+#ifdef CONFIG_ACPI_SPCR_TABLE
+int acpi_console_match(struct console *c, char **options);
+#else
+static inline int acpi_console_match(struct console *c, char **options)
+{
+	return -ENODEV;
+}
+#endif
+
 /*
  * for_each_console() allows you to iterate on each console
  */
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 0cc9542..5c270cf 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2572,8 +2572,26 @@ void register_console(struct console *newcon)
 		break;
 	}
 
-	if (!(newcon->flags & CON_ENABLED))
-		return;
+	if (!(newcon->flags & CON_ENABLED)) {
+		char *opts;
+		int err;
+
+		if (newcon->flags & CON_BOOT)
+			return;
+
+		err = acpi_console_match(newcon, &opts);
+		if (err < 0)
+			return;
+
+		if (newcon->index < 0)
+			newcon->index = 0;
+
+		if (newcon->setup && newcon->setup(newcon, opts) != 0)
+			return;
+
+		newcon->flags |= CON_ENABLED | CON_CONSDEV;
+		has_preferred = true;
+	}
 
 	/*
 	 * If we have a bootconsole, and are switching to a real console,
-- 
2.7.0



From aleksey.makarov at linaro.org  Fri Feb 12 09:43:38 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Fri, 12 Feb 2016 20:43:38 +0300
Subject: [PATCH v2 7/9] serial: pl011: add acpi_match
In-Reply-To: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1455299022-11641-8-git-send-email-aleksey.makarov@linaro.org>

Add an implementation of acpi_match() to the pl011 driver.
It allows console to check if it matches the console specified by
ACPI SPCR table.

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
Tested-by: Christopher Covington <cov at codeaurora.org>
---
 drivers/tty/serial/amba-pl011.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 500232a..f613bff 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2285,12 +2285,34 @@ static int __init pl011_console_setup(struct console *co, char *options)
 	return uart_set_options(&uap->port, co, baud, parity, bits, flow);
 }
 
+static int __init pl011_console_acpi_match(struct console *co,
+					   struct acpi_table_spcr *spcr)
+{
+	struct uart_amba_port *uap = amba_ports[co->index < 0 ? 0 : co->index];
+
+	if (uap->vendor->access_32b) {
+		if (spcr->interface_type != ACPI_DBG2_ARM_SBSA_32BIT)
+			return -ENODEV;
+	} else {
+		if (spcr->interface_type != ACPI_DBG2_ARM_PL011 &&
+		    spcr->interface_type != ACPI_DBG2_ARM_SBSA_GENERIC)
+			return -ENODEV;
+	}
+
+	if (spcr->serial_port.space_id != ACPI_ADR_SPACE_SYSTEM_MEMORY ||
+	    spcr->serial_port.address != (u64)uap->port.mapbase)
+		return -ENODEV;
+
+	return 0;
+}
+
 static struct uart_driver amba_reg;
 static struct console amba_console = {
 	.name		= "ttyAMA",
 	.write		= pl011_console_write,
 	.device		= uart_console_device,
 	.setup		= pl011_console_setup,
+	.acpi_match	= pl011_console_acpi_match,
 	.flags		= CON_PRINTBUFFER,
 	.index		= -1,
 	.data		= &amba_reg,
-- 
2.7.0



From aleksey.makarov at linaro.org  Fri Feb 12 09:43:39 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Fri, 12 Feb 2016 20:43:39 +0300
Subject: [PATCH v2 8/9] serial: 8250: add acpi_match
In-Reply-To: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1455299022-11641-9-git-send-email-aleksey.makarov@linaro.org>

From: Mark Salter <msalter at redhat.com>

Add an implementation of acpi_match() to the 8250 driver.
It allows console to check if it matches the console specified by
ACPI SPCR table.

Signed-off-by: Mark Salter <msalter at redhat.com>
Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 drivers/tty/serial/8250/8250_core.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index 7775221..059338a 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -40,6 +40,7 @@
 #ifdef CONFIG_SPARC
 #include <linux/sunserialcore.h>
 #endif
+#include <linux/acpi.h>
 
 #include <asm/irq.h>
 
@@ -669,12 +670,34 @@ static int univ8250_console_match(struct console *co, char *name, int idx,
 	return -ENODEV;
 }
 
+static int __init univ8250_console_acpi_match(struct console *co,
+					      struct acpi_table_spcr *spcr)
+{
+	int index = co->index >= 0 ? co->index : 0;
+	struct uart_port *port = &serial8250_ports[index].port;
+
+	if (spcr->interface_type != ACPI_DBG2_16550_SUBSET &&
+	    spcr->interface_type != ACPI_DBG2_16550_COMPATIBLE)
+		return -ENODEV;
+
+	if (spcr->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY &&
+	    spcr->serial_port.address == (u64)port->mapbase)
+		return 0;
+
+	if (spcr->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_IO &&
+	    spcr->serial_port.address == (u64)port->iobase)
+		return 0;
+
+	return -ENODEV;
+}
+
 static struct console univ8250_console = {
 	.name		= "ttyS",
 	.write		= univ8250_console_write,
 	.device		= uart_console_device,
 	.setup		= univ8250_console_setup,
 	.match		= univ8250_console_match,
+	.acpi_match	= univ8250_console_acpi_match,
 	.flags		= CON_PRINTBUFFER | CON_ANYTIME,
 	.index		= -1,
 	.data		= &serial8250_reg,
-- 
2.7.0



From aleksey.makarov at linaro.org  Fri Feb 12 09:43:36 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Fri, 12 Feb 2016 20:43:36 +0300
Subject: [PATCH v2 5/9] ACPI: enable ACPI_SPCR_TABLE on ARM64
In-Reply-To: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1455299022-11641-6-git-send-email-aleksey.makarov@linaro.org>

SBBR mentions SPCR as a mandatory ACPI table.
So enable it for ARM64

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
Tested-by: Christopher Covington <cov at codeaurora.org>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6bb21d8..75739cd 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -3,6 +3,7 @@ config ARM64
 	select ACPI_CCA_REQUIRED if ACPI
 	select ACPI_GENERIC_GSI if ACPI
 	select ACPI_REDUCED_HARDWARE_ONLY if ACPI
+	select ACPI_SPCR_TABLE if ACPI
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_ELF_RANDOMIZE
-- 
2.7.0



From james.morse at arm.com  Fri Feb 12 09:47:47 2016
From: james.morse at arm.com (James Morse)
Date: Fri, 12 Feb 2016 17:47:47 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <56BE1AC3.409@arm.com>

Hi Ard,

On 01/02/16 10:54, Ard Biesheuvel wrote:
> This moves the module area to right before the vmalloc area, and
> moves the kernel image to the base of the vmalloc area. This is
> an intermediate step towards implementing KASLR, which allows the
> kernel image to be located anywhere in the vmalloc area.

I've rebased hibernate onto for-next/core, and this patch leads to the hibernate
core code falling down a kernel shaped hole in the linear map.

The hibernate code assumes that for zones returned by for_each_populated_zone(),
if pfn_valid() says a page is present, then it is okay to access the page via
page_address(pfn_to_page(pfn)). But for pfns that correspond to the kernel text,
this is still returning an address in the linear map, which isn't mapped...

I'm not sure what the correct fix is here.
Should this sort of walk be valid?


>From include/linux/mm.h:
> static __always_inline void *lowmem_page_address(const struct page *page)
> {
>	return __va(PFN_PHYS(page_to_pfn(page)));
> }


Suggestions welcome!


Thanks,

James


From aleksey.makarov at linaro.org  Fri Feb 12 09:43:40 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Fri, 12 Feb 2016 20:43:40 +0300
Subject: [PATCH v2 9/9] serial: pl011: use SPCR to setup 32-bit access
In-Reply-To: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1455299022-11641-10-git-send-email-aleksey.makarov@linaro.org>

Some implementations of ARM SBSA serial port hardware require that access
to the registers should be 32-bit.  Unfortunately, the only way for
the driver to tell if it's the case is to use the data from ACPI SPCR/DBG2
tables.  In this case the value of the 'Interface Type' field of the SPCR
table is ACPI_DBG2_ARM_SBSA_32BIT.

How this value is described in the DBG2 spec:
"(deprecated) ARM SBSA (2.x only) Generic UART supporting only
32-bit accesses"

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
Tested-by: Christopher Covington <cov at codeaurora.org>
---
 drivers/acpi/spcr.c             | 29 +++++++++++++++++++++++++++++
 drivers/tty/serial/amba-pl011.c |  2 ++
 include/linux/console.h         |  5 +++++
 3 files changed, 36 insertions(+)

diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index 0475840..df1741f 100644
--- a/drivers/acpi/spcr.c
+++ b/drivers/acpi/spcr.c
@@ -75,3 +75,32 @@ int acpi_console_match(struct console *console, char **options)
 
 	return acpi_table_parse2(ACPI_SIG_SPCR, spcr_table_handler_match, &d);
 }
+
+static int spcr_table_handler_32_bit(struct acpi_table_header *t,
+				     void *data)
+{
+	struct acpi_table_spcr *table = (struct acpi_table_spcr *)t;
+
+	return table->interface_type == ACPI_DBG2_ARM_SBSA_32BIT;
+}
+
+/**
+ * acpi_console_sbsa_32bit - Tell if SPCR specifies 32-bit SBSA.
+ *
+ * Some implementations of ARM SBSA serial port hardware require that access
+ * to the registers should be 32-bit.  Unfortunately, the only way for
+ * the driver to tell if it's the case is to use the data from ACPI SPCR/DBG2
+ * tables.  In this case the value of the 'Interface Type' field of the SPCR
+ * table is ACPI_DBG2_ARM_SBSA_32BIT.
+ *
+ * Return: true if access should be 32-bit wide.
+ */
+bool acpi_console_sbsa_32bit(void)
+{
+	if (acpi_disabled)
+		return false;
+
+	return acpi_table_parse2(ACPI_SIG_SPCR,
+				 spcr_table_handler_32_bit, NULL) > 0;
+}
+EXPORT_SYMBOL(acpi_console_sbsa_32bit);
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index f613bff..699a3ce 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2563,6 +2563,8 @@ static int sbsa_uart_probe(struct platform_device *pdev)
 		baudrate = 115200;
 	}
 
+	vendor_sbsa.access_32b = acpi_console_sbsa_32bit();
+
 	portnr = pl011_find_free_port();
 	if (portnr < 0)
 		return portnr;
diff --git a/include/linux/console.h b/include/linux/console.h
index dcc2b59..027ef50 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -137,11 +137,16 @@ struct console {
 
 #ifdef CONFIG_ACPI_SPCR_TABLE
 int acpi_console_match(struct console *c, char **options);
+bool acpi_console_sbsa_32bit(void);
 #else
 static inline int acpi_console_match(struct console *c, char **options)
 {
 	return -ENODEV;
 }
+static inline bool acpi_console_sbsa_32bit(void)
+{
+	return false;
+}
 #endif
 
 /*
-- 
2.7.0



From yang.shi at linaro.org  Fri Feb 12 09:54:27 2016
From: yang.shi at linaro.org (Shi, Yang)
Date: Fri, 12 Feb 2016 09:54:27 -0800
Subject: [PATCH] arm64: make irq_stack_ptr more robust
In-Reply-To: <56BE18AB.4090902@linaro.org>
References: <1455227590-9837-1-git-send-email-yang.shi@linaro.org>
 <56BDE260.20504@arm.com> <56BE18AB.4090902@linaro.org>
Message-ID: <56BE1C53.8070605@linaro.org>

On 2/12/2016 9:38 AM, Shi, Yang wrote:
> On 2/12/2016 5:47 AM, James Morse wrote:
>> Hi!
>>
>> On 11/02/16 21:53, Yang Shi wrote:
>>> Switching between stacks is only valid if we are tracing ourselves
>>> while on the
>>> irq_stack, so it is only valid when in current and non-preemptible
>>> context,
>>> otherwise is is just zeroed off.
>>
>> Given it was picked up with CONFIG_DEBUG_PREEMPT:
>>
>> Fixes: 132cd887b5c5 ("arm64: Modify stack trace and dump for use with
>> irq_stack")
>
> Wii add in v2.
>
>>
>>
>>> Signed-off-by: Yang Shi <yang.shi at linaro.org>
>>> ---
>>>   arch/arm64/kernel/stacktrace.c | 13 ++++++-------
>>>   arch/arm64/kernel/traps.c      | 11 ++++++++++-
>>>   2 files changed, 16 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/arch/arm64/kernel/stacktrace.c
>>> b/arch/arm64/kernel/stacktrace.c
>>> index 12a18cb..d9751a4 100644
>>> --- a/arch/arm64/kernel/stacktrace.c
>>> +++ b/arch/arm64/kernel/stacktrace.c
>>> @@ -44,14 +44,13 @@ int notrace unwind_frame(struct task_struct *tsk,
>>> struct stackframe *frame)
>>>       unsigned long irq_stack_ptr;
>>>
>>>       /*
>>> -     * Use raw_smp_processor_id() to avoid false-positives from
>>> -     * CONFIG_DEBUG_PREEMPT. get_wchan() calls unwind_frame() on
>>> sleeping
>>> -     * task stacks, we can be pre-empted in this case, so
>>> -     * {raw_,}smp_processor_id() may give us the wrong value. Sleeping
>>> -     * tasks can't ever be on an interrupt stack, so regardless of cpu,
>>> -     * the checks will always fail.
>>> +     * Switching between stacks is valid when tracing current and in
>>> +     * non-preemptible context.
>>>        */
>>> -    irq_stack_ptr = IRQ_STACK_PTR(raw_smp_processor_id());
>>> +    if (tsk == current && !preemptible())
>>> +        irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
>>> +    else
>>> +        irq_stack_ptr = 0;
>>>
>>>       low  = frame->sp;
>>>       /* irq stacks are not THREAD_SIZE aligned */
>>> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
>>> index cbedd72..7d8db3a 100644
>>> --- a/arch/arm64/kernel/traps.c
>>> +++ b/arch/arm64/kernel/traps.c
>>> @@ -146,9 +146,18 @@ static void dump_instr(const char *lvl, struct
>>> pt_regs *regs)
>>>   static void dump_backtrace(struct pt_regs *regs, struct task_struct
>>> *tsk)
>>>   {
>>>       struct stackframe frame;
>>> -    unsigned long irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
>>> +    unsigned long irq_stack_ptr;
>>>       int skip;
>>>
>>> +    /*
>>> +     * Switching between  stacks is valid when tracing current and in
>>
>> Nit: Two spaces: "between[ ][ ]stacks"
>
> Will fix in v2.
>
>>
>>
>>> +     * non-preemptible context.
>>> +     */
>>> +    if (tsk == current && !preemptible())
>>> +        irq_stack_ptr = IRQ_STACK_PTR(smp_processor_id());
>>> +    else
>>> +        irq_stack_ptr = 0;
>>> +
>>>       pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
>>>
>>>       if (!tsk)
>>>
>>
>> Neither file includes 'linux/preempt.h' for the definition of
>> preemptible().
>> (I can't talk: I should have included smp.h for smp_processor_id())
>
> I tried to build the kernel with preempt and without preempt, both
> works. And, I saw arch/arm64/include/asm/Kbuild has:
>
> generic-y += preempt.h
>
> So, it sounds preempt.h has been included by default.

In addition, linux/sched.h, which is included by both traps.c and 
stacktrace.c, includes preempt.h already.

Yang

>
> Thanks,
> Yang
>
>>
>>
>> Acked-by: James Morse <james.morse at arm.com>
>> Tested-by: James Morse <james.morse at arm.com>
>>
>>
>> Thanks!
>>
>> James
>>
>>
>



From mark.rutland at arm.com  Fri Feb 12 09:58:58 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 12 Feb 2016 17:58:58 +0000
Subject: [PATCH 2/2] arm64: Mark kernel page ranges contiguous
In-Reply-To: <56BE17C9.6090608@arm.com>
References: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
 <1455293208-6763-3-git-send-email-jeremy.linton@arm.com>
 <20160212165707.GB20262@leverpostej> <56BE17C9.6090608@arm.com>
Message-ID: <20160212175857.GE20262@leverpostej>

On Fri, Feb 12, 2016 at 11:35:05AM -0600, Jeremy Linton wrote:
> On 02/12/2016 10:57 AM, Mark Rutland wrote:
> (trimming)
> > On Fri, Feb 12, 2016 at 10:06:48AM -0600, Jeremy Linton wrote:
> >>+static void clear_cont_pte_range(pte_t *pte, unsigned long addr)
> >>+{
> >>+	int i;
> >>+
> >>+	pte -= CONT_RANGE_OFFSET(addr);
> >>+	for (i = 0; i < CONT_PTES; i++) {
> >>+		if (pte_cont(*pte))
> >>+			set_pte(pte, pte_mknoncont(*pte));
> >>+		pte++;
> >>+	}
> >>+	flush_tlb_all();
> >>+}
> >
> >As far as I can tell, "splitting" contiguous entries comes with the same
> >caveats as splitting sections. In the absence of a BBM sequence we might
> >end up with conflicting TLB entries.
> 
> As I mentioned a couple weeks ago, I'm not sure that inverting a BBM
> to a full "make partial copy of the whole table->break TTBR to copy
> sequence" is so bad if the copy process maintains references to the
> original table entries when they aren't in the modification path. It
> might even work with all the CPU's spun up because the break
> sequence would just be IPI's to the remaining cpu's to replace their
> TTBR/flush with a new value. I think you mentioned the ugly part is
> arbitrating access to the update functionality (and all the implied
> rules of when it could be done). But doing it that way doesn't
> require stalling the CPU's during the "make partial copy" portion.

That may be true, and worthy of investigation.

One problem I envisaged with that is concurrent kernel pagetable
modification (e.g. vmalloc, DEBUG_PAGEALLOC). To handle that correctly
you require global serialization (or your copy may be stale), though as
you point out that doesn't mean stop-the-world entirely.

For the above, I was simply pointing out that in general,
splitting/fusing contiguous ranges comes with the same issues as
splitting/fusing sections, as that may not be immediately obvious.

> >However, I think we're OK for now.
> >
> >The way we consistently map/unmap/modify image/linear "chunks" should
> >prevent us from trying to split those, and if/when we do this for the
> >EFI runtime page tables thy aren't live.
> >
> >It would be good to figure out how to get rid of the splitting entirely.
> 
> Well we could hoist some of it earlier by taking the
> create_mapping_late() calls and doing them earlier with RWX
> permissions, and then applying the RO,ROX,RW later as necessarily.
> 
> Which is ugly, but it might solve particular late splitting cases.

I'm not sure I follow.

The aim was that after my changes we should only split/fuse for EFI page
tables, and only for !4K page kernels. See [1] for why. Avoiding that in
the EFI case is very painful, so for now we kept split_pud and
split_pmd.

All create_mapping_late() calls should be performed with the same
physical/virtual start/end as earlier "chunk" mappings, and thus should
never result in a fuse/split or translation change -- only permission
changes (which we believe do not result in TLB conflicts, or we'd need
to do far more work to fix those up).

If we split/fuse in any case other than EFI runtime table creation, that
is a bug that we need to fix. If you're seeing a case we do that, then
please let me know!

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/398178.html


From andre.przywara at arm.com  Fri Feb 12 09:59:56 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Fri, 12 Feb 2016 17:59:56 +0000
Subject: [RFC PATCH 0/4] clk: sunxi: fix DT compatibility issues
Message-ID: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>

Commit f7d372ba54ea ("clk: sunxi: Refactor A31 PLL6 so that it can be
reused") (in -next) made the A31 PLL6 clock driver more generic, so
that it can drive the PLL8 clock in newer SoCs too.
However the patch broke compatibility with older DTs, which this
series tries to fix.
The approach chosen here is to bring back the old driver under its
old name, while letting the new driver using a different name to be
able to tell them apart.
The old driver should be somewhat deprecated and not used in new DTs
anymore.
The slight disadvantage is that there are now two drivers and two
compatible names for the same hardware (the PLL6 clock), I am not
sure if this is frowned upon or can be tolerated since the new driver
is more generic (drives PLL8 as well) and makes the old one obsolete.
We just need to keep it for compatibility.

The naming for both the functions and compatible names is probably
wrong, I am relying on more sunxi - experienced people here to
suggest better identifiers.

This is only one possible approach to fix this issues, so I am open
to any kind of discussion.

The series is made on top of Maxime's sunxi/for-next branch, so it
somehow reverts the change in question. I am happy to rebase it on
any branch people tell me.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>

Andre Przywara (4):
  clk: sunxi: rename new sun6i_a31_pll6 clock to sun6i_a31_pll clock
  clk: sunxi: re-add old sun6i_a31_pll6 clock
  clk: sunxi: revert .dtsi changes for DTs with a sun6i_a31_pll6 clock
  DT: Allwinner H3: fix PLL8 clock

 Documentation/devicetree/bindings/clock/sunxi.txt |  2 +-
 arch/arm/boot/dts/sun6i-a31.dtsi                  | 36 ++++++++---------
 arch/arm/boot/dts/sun8i-a23-a33.dtsi              | 25 ++++--------
 arch/arm/boot/dts/sun8i-a23.dtsi                  |  2 +-
 arch/arm/boot/dts/sun8i-a33.dtsi                  |  4 +-
 arch/arm/boot/dts/sun8i-h3.dtsi                   | 31 +++++---------
 drivers/clk/sunxi/clk-sunxi.c                     | 49 ++++++++++++++++++++---
 7 files changed, 84 insertions(+), 65 deletions(-)

-- 
2.6.4



From andre.przywara at arm.com  Fri Feb 12 09:59:57 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Fri, 12 Feb 2016 17:59:57 +0000
Subject: [RFC PATCH 1/4] clk: sunxi: rename new sun6i_a31_pll6 clock to
 sun6i_a31_pll clock
In-Reply-To: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
References: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455300000-18723-2-git-send-email-andre.przywara@arm.com>

In preparation for bringing back the old driver for keeping
compatibility, we rename the new A31 PLL6 clock driver. This only
affects the internal naming, the compatible name stays on pll6 for
now.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 48ed81d..b4ab84b 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -233,7 +233,7 @@ static void sun4i_get_pll5_factors(struct factors_request *req)
  * parent_rate is always 24Mhz
  */
 
-static void sun6i_a31_get_pll6_factors(struct factors_request *req)
+static void sun6i_a31_get_pll_factors(struct factors_request *req)
 {
 	u8 div;
 
@@ -542,10 +542,10 @@ static const struct factors_data sun4i_pll6_data __initconst = {
 	.name = "pll6",
 };
 
-static const struct factors_data sun6i_a31_pll6_data __initconst = {
+static const struct factors_data sun6i_a31_pll_data __initconst = {
 	.enable = 31,
 	.table = &sun6i_a31_pll6_config,
-	.getter = sun6i_a31_get_pll6_factors,
+	.getter = sun6i_a31_get_pll_factors,
 	.recalc = sun6i_a31_pll6_recalc,
 };
 
@@ -622,12 +622,12 @@ static void __init sun7i_pll4_clk_setup(struct device_node *node)
 CLK_OF_DECLARE(sun7i_pll4, "allwinner,sun7i-a20-pll4-clk",
 	       sun7i_pll4_clk_setup);
 
-static void __init sun6i_pll6_clk_setup(struct device_node *node)
+static void __init sun6i_pll_clk_setup(struct device_node *node)
 {
-	sunxi_factors_clk_setup(node, &sun6i_a31_pll6_data);
+	sunxi_factors_clk_setup(node, &sun6i_a31_pll_data);
 }
-CLK_OF_DECLARE(sun6i_pll6, "allwinner,sun6i-a31-pll6-clk",
-	       sun6i_pll6_clk_setup);
+CLK_OF_DECLARE(sun6i_pll, "allwinner,sun6i-a31-pll6-clk",
+	       sun6i_pll_clk_setup);
 
 static void __init sun5i_ahb_clk_setup(struct device_node *node)
 {
-- 
2.6.4



From andre.przywara at arm.com  Fri Feb 12 09:59:58 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Fri, 12 Feb 2016 17:59:58 +0000
Subject: [RFC PATCH 2/4] clk: sunxi: re-add old sun6i_a31_pll6 clock
In-Reply-To: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
References: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455300000-18723-3-git-send-email-andre.przywara@arm.com>

The older version of the A31 PLL6 clock driver was used by many DTs
which we want to stay compatible with.
As an intermediate step bring back the code for the old driver, but
don't instantiate it yet.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index b4ab84b..12131ba 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -248,6 +248,21 @@ static void sun6i_a31_get_pll_factors(struct factors_request *req)
 	req->n = DIV_ROUND_UP(div, (req->k + 1)) - 1;
 }
 
+static void sun6i_a31_get_pll6_factors(struct factors_request *req)
+{
+	u8 div;
+
+	/* Normalize value to a parent_rate multiple (24M) */
+	div = req->rate / req->parent_rate;
+	req->rate = req->parent_rate * div;
+
+	req->k = div / 32;
+	if (req->k > 3)
+		req->k = 3;
+
+	req->n = DIV_ROUND_UP(div, (req->k + 1)) - 1;
+}
+
 static void sun6i_a31_pll6_recalc(struct factors_request *req)
 {
 	req->rate = req->parent_rate;
@@ -549,6 +564,13 @@ static const struct factors_data sun6i_a31_pll_data __initconst = {
 	.recalc = sun6i_a31_pll6_recalc,
 };
 
+static const struct factors_data sun6i_a31_pll6_data __initconst = {
+	.enable = 31,
+	.table = &sun6i_a31_pll6_config,
+	.getter = sun6i_a31_get_pll6_factors,
+	.name	= "pll6x2",
+};
+
 static const struct factors_data sun5i_a13_ahb_data __initconst = {
 	.mux = 6,
 	.muxmask = BIT(1) | BIT(0),
@@ -954,6 +976,15 @@ static const struct divs_data pll6_divs_data __initconst = {
 	}
 };
 
+static const struct divs_data sun6i_a31_pll6_divs_data __initconst = {
+	.factors = &sun6i_a31_pll6_data,
+	.ndivs = 2,
+	.div = {
+		{ .fixed = 2 }, /* normal output */
+		{ .self = 1 }, /* base factor clock, 2x */
+	}
+};
+
 /**
  * sunxi_divs_clk_setup() - Setup function for leaf divisors on clocks
  *
-- 
2.6.4



From andre.przywara at arm.com  Fri Feb 12 09:59:59 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Fri, 12 Feb 2016 17:59:59 +0000
Subject: [RFC PATCH 3/4] clk: sunxi: revert .dtsi changes for DTs with a
 sun6i_a31_pll6 clock
In-Reply-To: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
References: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455300000-18723-4-git-send-email-andre.przywara@arm.com>

The changes made to the driver broke compatibilty with older DTs.
For most of the boards the new driver does not bring any advantage,
so for the sake of compatibility bring them back to the previous
version.
This also affects the new H3 .dtsi - at least for this patch, the
next one will fix this.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 Documentation/devicetree/bindings/clock/sunxi.txt |  2 +-
 arch/arm/boot/dts/sun6i-a31.dtsi                  | 36 +++++++++++-----------
 arch/arm/boot/dts/sun8i-a23-a33.dtsi              | 25 +++++----------
 arch/arm/boot/dts/sun8i-a23.dtsi                  |  2 +-
 arch/arm/boot/dts/sun8i-a33.dtsi                  |  4 +--
 arch/arm/boot/dts/sun8i-h3.dtsi                   | 37 +++++++++--------------
 drivers/clk/sunxi/clk-sunxi.c                     |  8 ++++-
 7 files changed, 51 insertions(+), 63 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index 966dcaf..c09f59b 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -88,7 +88,7 @@ Required properties for all clocks:
 - #clock-cells : from common clock binding; shall be set to 0 except for
 	the following compatibles where it shall be set to 1:
 	"allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk",
-	"allwinner,sun4i-pll6-clk",
+	"allwinner,sun4i-pll6-clk", "allwinner,sun6i-a31-pll6-clk",
 	"allwinner,*-usb-clk", "allwinner,*-mmc-clk",
 	"allwinner,*-mmc-config-clk"
 - clock-output-names : shall be the corresponding names of the outputs.
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 7a198dc..1867af2 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -65,7 +65,7 @@
 			compatible = "allwinner,simple-framebuffer",
 				     "simple-framebuffer";
 			allwinner,pipeline = "de_be0-lcd0-hdmi";
-			clocks = <&pll6>;
+			clocks = <&pll6 0>;
 			status = "disabled";
 		};
 
@@ -73,7 +73,7 @@
 			compatible = "allwinner,simple-framebuffer",
 				     "simple-framebuffer";
 			allwinner,pipeline = "de_be0-lcd0";
-			clocks = <&pll6>;
+			clocks = <&pll6 0>;
 			status = "disabled";
 		};
 	};
@@ -201,11 +201,11 @@
 		};
 
 		pll6: clk at 01c20028 {
-			#clock-cells = <0>;
+			#clock-cells = <1>;
 			compatible = "allwinner,sun6i-a31-pll6-clk";
 			reg = <0x01c20028 0x4>;
 			clocks = <&osc24M>;
-			clock-output-names = "pll6";
+			clock-output-names = "pll6", "pll6x2";
 		};
 
 		cpu: cpu at 01c20050 {
@@ -235,7 +235,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun6i-a31-ahb1-clk";
 			reg = <0x01c20054 0x4>;
-			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
+			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
 			clock-output-names = "ahb1";
 
 			/*
@@ -244,7 +244,7 @@
 			 * controller requires AHB1 clocked from PLL6.
 			 */
 			assigned-clocks = <&ahb1>;
-			assigned-clock-parents = <&pll6>;
+			assigned-clock-parents = <&pll6 0>;
 		};
 
 		ahb1_gates: clk at 01c20060 {
@@ -307,7 +307,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-apb1-clk";
 			reg = <0x01c20058 0x4>;
-			clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
+			clocks = <&osc32k>, <&osc24M>, <&pll6 0>, <&pll6 0>;
 			clock-output-names = "apb2";
 		};
 
@@ -331,7 +331,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20088 0x4>;
-			clocks = <&osc24M>, <&pll6>;
+			clocks = <&osc24M>, <&pll6 0>;
 			clock-output-names = "mmc0",
 					     "mmc0_output",
 					     "mmc0_sample";
@@ -341,7 +341,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c2008c 0x4>;
-			clocks = <&osc24M>, <&pll6>;
+			clocks = <&osc24M>, <&pll6 0>;
 			clock-output-names = "mmc1",
 					     "mmc1_output",
 					     "mmc1_sample";
@@ -351,7 +351,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20090 0x4>;
-			clocks = <&osc24M>, <&pll6>;
+			clocks = <&osc24M>, <&pll6 0>;
 			clock-output-names = "mmc2",
 					     "mmc2_output",
 					     "mmc2_sample";
@@ -361,7 +361,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20094 0x4>;
-			clocks = <&osc24M>, <&pll6>;
+			clocks = <&osc24M>, <&pll6 0>;
 			clock-output-names = "mmc3",
 					     "mmc3_output",
 					     "mmc3_sample";
@@ -371,7 +371,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-mod0-clk";
 			reg = <0x01c2009c 0x4>;
-			clocks = <&osc24M>, <&pll6>;
+			clocks = <&osc24M>, <&pll6 0>;
 			clock-output-names = "ss";
 		};
 
@@ -379,7 +379,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-mod0-clk";
 			reg = <0x01c200a0 0x4>;
-			clocks = <&osc24M>, <&pll6>;
+			clocks = <&osc24M>, <&pll6 0>;
 			clock-output-names = "spi0";
 		};
 
@@ -387,7 +387,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-mod0-clk";
 			reg = <0x01c200a4 0x4>;
-			clocks = <&osc24M>, <&pll6>;
+			clocks = <&osc24M>, <&pll6 0>;
 			clock-output-names = "spi1";
 		};
 
@@ -395,7 +395,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-mod0-clk";
 			reg = <0x01c200a8 0x4>;
-			clocks = <&osc24M>, <&pll6>;
+			clocks = <&osc24M>, <&pll6 0>;
 			clock-output-names = "spi2";
 		};
 
@@ -403,7 +403,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-mod0-clk";
 			reg = <0x01c200ac 0x4>;
-			clocks = <&osc24M>, <&pll6>;
+			clocks = <&osc24M>, <&pll6 0>;
 			clock-output-names = "spi3";
 		};
 
@@ -1052,8 +1052,8 @@
 			ar100: ar100_clk {
 				compatible = "allwinner,sun6i-a31-ar100-clk";
 				#clock-cells = <0>;
-				clocks = <&osc32k>, <&osc24M>, <&pll6>,
-					 <&pll6>;
+				clocks = <&osc32k>, <&osc24M>, <&pll6 0>,
+					 <&pll6 0>;
 				clock-output-names = "ar100";
 			};
 
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 783b4b8..7e05e09 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -60,7 +60,7 @@
 			compatible = "allwinner,simple-framebuffer",
 				     "simple-framebuffer";
 			allwinner,pipeline = "de_be0-lcd0";
-			clocks = <&pll6>;
+			clocks = <&pll6 0>;
 			status = "disabled";
 		};
 	};
@@ -129,20 +129,11 @@
 		};
 
 		pll6: clk at 01c20028 {
-			#clock-cells = <0>;
+			#clock-cells = <1>;
 			compatible = "allwinner,sun6i-a31-pll6-clk";
 			reg = <0x01c20028 0x4>;
 			clocks = <&osc24M>;
-			clock-output-names = "pll6";
-		};
-
-                pll6x2: pll6x2_clk {
-			compatible = "fixed-factor-clock";
-			#clock-cells = <0>;
-			clock-div = <1>;
-			clock-mult = <2>;
-			clocks = <&pll6>;
-			clock-output-names = "pll6-2x";
+			clock-output-names = "pll6", "pll6x2";
 		};
 
 		cpu: cpu_clk at 01c20050 {
@@ -172,7 +163,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun6i-a31-ahb1-clk";
 			reg = <0x01c20054 0x4>;
-			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
+			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
 			clock-output-names = "ahb1";
 		};
 
@@ -199,7 +190,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-apb1-clk";
 			reg = <0x01c20058 0x4>;
-			clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
+			clocks = <&osc32k>, <&osc24M>, <&pll6 0>, <&pll6 0>;
 			clock-output-names = "apb2";
 		};
 
@@ -222,7 +213,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20088 0x4>;
-			clocks = <&osc24M>, <&pll6>;
+			clocks = <&osc24M>, <&pll6 0>;
 			clock-output-names = "mmc0",
 					     "mmc0_output",
 					     "mmc0_sample";
@@ -232,7 +223,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c2008c 0x4>;
-			clocks = <&osc24M>, <&pll6>;
+			clocks = <&osc24M>, <&pll6 0>;
 			clock-output-names = "mmc1",
 					     "mmc1_output",
 					     "mmc1_sample";
@@ -242,7 +233,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20090 0x4>;
-			clocks = <&osc24M>, <&pll6>;
+			clocks = <&osc24M>, <&pll6 0>;
 			clock-output-names = "mmc2",
 					     "mmc2_output",
 					     "mmc2_sample";
diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/sun8i-a23.dtsi
index 5e589c1..92e6616 100644
--- a/arch/arm/boot/dts/sun8i-a23.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23.dtsi
@@ -79,7 +79,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun8i-a23-mbus-clk";
 			reg = <0x01c2015c 0x4>;
-			clocks = <&osc24M>, <&pll6x2>, <&pll5>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5>;
 			clock-output-names = "mbus";
 		};
 	};
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index f3eb618..001d840 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -103,7 +103,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-mod0-clk";
 			reg = <0x01c2009c 0x4>;
-			clocks = <&osc24M>, <&pll6>;
+			clocks = <&osc24M>, <&pll6 0>;
 			clock-output-names = "ss";
 		};
 
@@ -111,7 +111,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun8i-a23-mbus-clk";
 			reg = <0x01c2015c 0x4>;
-			clocks = <&osc24M>, <&pll6x2>, <&pll5>, <&pll11>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5>, <&pll11>;
 			clock-output-names = "mbus";
 		};
 	};
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 6f6b4e4..1524130e 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -121,11 +121,11 @@
 		};
 
 		pll6: clk at 01c20028 {
-			#clock-cells = <0>;
+			#clock-cells = <1>;
 			compatible = "allwinner,sun6i-a31-pll6-clk";
 			reg = <0x01c20028 0x4>;
 			clocks = <&osc24M>;
-			clock-output-names = "pll6";
+			clock-output-names = "pll6", "pll6x2";
 		};
 
 		pll6d2: pll6d2_clk {
@@ -133,24 +133,15 @@
 			compatible = "fixed-factor-clock";
 			clock-div = <2>;
 			clock-mult = <1>;
-			clocks = <&pll6>;
-			clock-output-names = "pll6-d2";
+			clocks = <&pll6 0>;
+			clock-output-names = "pll6d2";
 		};
 
-		pll6x2: pll6x2_clk {
+		/* dummy clock until pll6 can be reused */
+		pll8: pll8_clk {
 			#clock-cells = <0>;
-			compatible = "fixed-factor-clock";
-			clock-div = <1>;
-			clock-mult = <2>;
-			clocks = <&pll6>;
-			clock-output-names = "pll6-2x";
-		};
-
-		pll8: clk at 01c20044 {
-			#clock-cells = <0>;
-			compatible = "allwinner,sun6i-a31-pll6-clk";
-			reg = <0x01c20044 0x4>;
-			clocks = <&osc24M>;
+			compatible = "fixed-clock";
+			clock-frequency = <1>;
 			clock-output-names = "pll8";
 		};
 
@@ -174,7 +165,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun6i-a31-ahb1-clk";
 			reg = <0x01c20054 0x4>;
-			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
+			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
 			clock-output-names = "ahb1";
 		};
 
@@ -198,7 +189,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun4i-a10-apb1-clk";
 			reg = <0x01c20058 0x4>;
-			clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
+			clocks = <&osc32k>, <&osc24M>, <&pll6 0>, <&pll6 0>;
 			clock-output-names = "apb2";
 		};
 
@@ -252,7 +243,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20088 0x4>;
-			clocks = <&osc24M>, <&pll6>, <&pll8>;
+			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
 			clock-output-names = "mmc0",
 					     "mmc0_output",
 					     "mmc0_sample";
@@ -262,7 +253,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c2008c 0x4>;
-			clocks = <&osc24M>, <&pll6>, <&pll8>;
+			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
 			clock-output-names = "mmc1",
 					     "mmc1_output",
 					     "mmc1_sample";
@@ -272,7 +263,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20090 0x4>;
-			clocks = <&osc24M>, <&pll6>, <&pll8>;
+			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
 			clock-output-names = "mmc2",
 					     "mmc2_output",
 					     "mmc2_sample";
@@ -282,7 +273,7 @@
 			#clock-cells = <0>;
 			compatible = "allwinner,sun8i-a23-mbus-clk";
 			reg = <0x01c2015c 0x4>;
-			clocks = <&osc24M>, <&pll6x2>, <&pll5>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll5>;
 			clock-output-names = "mbus";
 		};
 	};
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 12131ba..0ed0a8e 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -648,7 +648,7 @@ static void __init sun6i_pll_clk_setup(struct device_node *node)
 {
 	sunxi_factors_clk_setup(node, &sun6i_a31_pll_data);
 }
-CLK_OF_DECLARE(sun6i_pll, "allwinner,sun6i-a31-pll6-clk",
+CLK_OF_DECLARE(sun6i_pll, "allwinner,sun6i-a31-pll-clk",
 	       sun6i_pll_clk_setup);
 
 static void __init sun5i_ahb_clk_setup(struct device_node *node)
@@ -1152,3 +1152,9 @@ static void __init sun4i_pll6_clk_setup(struct device_node *node)
 CLK_OF_DECLARE(sun4i_pll6, "allwinner,sun4i-a10-pll6-clk",
 	       sun4i_pll6_clk_setup);
 
+static void __init sun6i_pll6_clk_setup(struct device_node *node)
+{
+	sunxi_divs_clk_setup(node, &sun6i_a31_pll6_divs_data);
+}
+CLK_OF_DECLARE(sun6i_pll6, "allwinner,sun6i-a31-pll6-clk",
+	       sun6i_pll6_clk_setup);
-- 
2.6.4



From andre.przywara at arm.com  Fri Feb 12 10:00:00 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Fri, 12 Feb 2016 18:00:00 +0000
Subject: [RFC PATCH 4/4] DT: Allwinner H3: fix PLL8 clock
In-Reply-To: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
References: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455300000-18723-5-git-send-email-andre.przywara@arm.com>

With the new generic a31-pll clock driver in place, we can use it to
properly describe the PLL8 clock.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 1524130e..1b2eb20 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -137,11 +137,11 @@
 			clock-output-names = "pll6d2";
 		};
 
-		/* dummy clock until pll6 can be reused */
-		pll8: pll8_clk {
+		pll8: clk at 01c20044 {
 			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <1>;
+			compatible = "allwinner,sun6i-a31-pll-clk";
+			reg = <0x01c20044 0x4>;
+			clocks = <&osc24M>;
 			clock-output-names = "pll8";
 		};
 
-- 
2.6.4



From ard.biesheuvel at linaro.org  Fri Feb 12 10:01:49 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 19:01:49 +0100
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <56BE1AC3.409@arm.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <56BE1AC3.409@arm.com>
Message-ID: <CAKv+Gu9evDuU_4seC2SVhFkzu_u5cUUaP0_cTk9po035mjaCzw@mail.gmail.com>

On 12 February 2016 at 18:47, James Morse <james.morse at arm.com> wrote:
> Hi Ard,
>
> On 01/02/16 10:54, Ard Biesheuvel wrote:
>> This moves the module area to right before the vmalloc area, and
>> moves the kernel image to the base of the vmalloc area. This is
>> an intermediate step towards implementing KASLR, which allows the
>> kernel image to be located anywhere in the vmalloc area.
>
> I've rebased hibernate onto for-next/core, and this patch leads to the hibernate
> core code falling down a kernel shaped hole in the linear map.
>
> The hibernate code assumes that for zones returned by for_each_populated_zone(),
> if pfn_valid() says a page is present, then it is okay to access the page via
> page_address(pfn_to_page(pfn)). But for pfns that correspond to the kernel text,
> this is still returning an address in the linear map, which isn't mapped...
>
> I'm not sure what the correct fix is here.
> Should this sort of walk be valid?
>

I think the correct fix would be to mark the [_stext, _etext] interval
as NOMAP. That will also simplify the mapping routine where I now
check manually whether a memblock intersects that interval. And it
should make this particular piece of code behave.

However, you would still need to preserve the contents of the
interval, since the generic hibernate routines will not do that
anymore after this change.

I will experiment with this on Monday, and report back.

Thanks,
Ard.


>
> From include/linux/mm.h:
>> static __always_inline void *lowmem_page_address(const struct page *page)
>> {
>>       return __va(PFN_PHYS(page_to_pfn(page)));
>> }
>
>
> Suggestions welcome!
>
>
> Thanks,
>
> James


From gregory.clement at free-electrons.com  Fri Feb 12 10:04:26 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 12 Feb 2016 19:04:26 +0100
Subject: [PATCH net-next 03/10] net: mvneta: bm: add support for hardware
 buffer management
In-Reply-To: <CAPv3WKeEXUmH4gqBm7=gkNYwjhR1YybCBZJND_Vidj+Q6U_8=g@mail.gmail.com>
 (Marcin Wojtas's message of "Tue, 12 Jan 2016 21:12:25 +0100")
References: <1452625834-22166-1-git-send-email-gregory.clement@free-electrons.com>
 <1452625834-22166-4-git-send-email-gregory.clement@free-electrons.com>
 <CAPv3WKeEXUmH4gqBm7=gkNYwjhR1YybCBZJND_Vidj+Q6U_8=g@mail.gmail.com>
Message-ID: <87a8n5x0t1.fsf@free-electrons.com>

Hi Marcin,
 
 On mar., janv. 12 2016, Marcin Wojtas <mw at semihalf.com> wrote:

> Hi Gregory,
>
> I have two remarks to my own code. Please let me know before patch v2,
> I will provide you with corrected version (I already did it locally).

I resumled my work on the subject yestaerdy, and I just remebered this
email now.

Could you provide the correct version of your patches?

Thanks!

>
>> @@ -1556,17 +1777,20 @@ static void mvneta_rxq_drop_pkts(struct mvneta_port *pp,
>>         int rx_done, i;
>>
>>         rx_done = mvneta_rxq_busy_desc_num_get(pp, rxq);
>> +       if (rx_done)
>> +               mvneta_rxq_desc_num_update(pp, rxq, rx_done, rx_done);
>> +
>> +       if (pp->bm_priv)
>> +               return;
>> +
>
> This is wrong - buffers that are supposed to be dropped should return
> to bm_pool.
>
>> @@ -1587,23 +1812,35 @@ static int mvneta_rx(struct mvneta_port *pp, int rx_todo,
>>
>>         rx_done = 0;
>>
>> +       bm_in_use = pp->bm_priv ? true : false;
>> +
>>         /* Fairness NAPI loop */
>>         while (rx_done < rx_todo) {
>>                 struct mvneta_rx_desc *rx_desc = mvneta_rxq_next_desc_get(rxq);
>> +               struct mvneta_bm_pool *bm_pool = NULL;
>>                 struct sk_buff *skb;
>>                 unsigned char *data;
>>                 dma_addr_t phys_addr;
>> -               u32 rx_status;
>> +               u32 rx_status, frag_size;
>>                 int rx_bytes, err;
>> +               u8 pool_id;
>>
>>                 rx_done++;
>>                 rx_status = rx_desc->status;
>>                 rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE);
>>                 data = (unsigned char *)rx_desc->buf_cookie;
>>                 phys_addr = rx_desc->buf_phys_addr;
>> +               if (bm_in_use) {
>> +                       pool_id = MVNETA_RX_GET_BM_POOL_ID(rx_desc);
>> +                       bm_pool = &pp->bm_priv->bm_pools[pool_id];
>> +               }
>>
>>                 if (!mvneta_rxq_desc_is_first_last(rx_status) ||
>>                     (rx_status & MVNETA_RXD_ERR_SUMMARY)) {
>> +                       /* Return the buffer to the pool */
>> +                       if (bm_in_use)
>> +                               mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool,
>> +                                                     rx_desc->buf_phys_addr);
>>                 err_drop_frame:
>>                         dev->stats.rx_errors++;
>>                         mvneta_rx_error(pp, rx_desc);
>> @@ -1633,25 +1870,38 @@ static int mvneta_rx(struct mvneta_port *pp, int rx_todo,
>>                         rcvd_pkts++;
>>                         rcvd_bytes += rx_bytes;
>>
>> +                       /* Return the buffer to the pool */
>> +                       if (bm_in_use)
>> +                               mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool,
>> +                                                     rx_desc->buf_phys_addr);
>> +
>>                         /* leave the descriptor and buffer untouched */
>>                         continue;
>>                 }
>>
>>                 /* Refill processing */
>> -               err = mvneta_rx_refill(pp, rx_desc);
>> +               err = bm_in_use ? mvneta_bm_pool_refill(pp->bm_priv, bm_pool) :
>> +                                 mvneta_rx_refill(pp, rx_desc);
>>                 if (err) {
>>                         netdev_err(dev, "Linux processing - Can't refill\n");
>>                         rxq->missed++;
>>                         goto err_drop_frame;
>
> Wrong - on refill fail, original buffer should be returned to bm_pool.
> Same case is, when netdev_alloc_skb_ip_align fail inside copybreak
> (this should also be fixed).
>
> Best regards,
> Marcin

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From computersforpeace at gmail.com  Fri Feb 12 10:09:03 2016
From: computersforpeace at gmail.com (Brian Norris)
Date: Fri, 12 Feb 2016 10:09:03 -0800
Subject: [PATCH] MAINTAINERS: update Han's email
In-Reply-To: <1455254005-746-1-git-send-email-han.xu@nxp.com>
References: <1455254005-746-1-git-send-email-han.xu@nxp.com>
Message-ID: <20160212180903.GN19540@google.com>

On Fri, Feb 12, 2016 at 05:13:25AM +0000, Han Xu wrote:
> Update my email address from freescale to nxp.
> 
> Signed-off-by: Han Xu <han.xu at nxp.com>

Applied to linux-mtd.git


From jeremy.linton at arm.com  Fri Feb 12 10:09:41 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Fri, 12 Feb 2016 12:09:41 -0600
Subject: [PATCH 2/2] arm64: Mark kernel page ranges contiguous
In-Reply-To: <20160212175857.GE20262@leverpostej>
References: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
 <1455293208-6763-3-git-send-email-jeremy.linton@arm.com>
 <20160212165707.GB20262@leverpostej> <56BE17C9.6090608@arm.com>
 <20160212175857.GE20262@leverpostej>
Message-ID: <56BE1FE5.8080002@arm.com>

On 02/12/2016 11:58 AM, Mark Rutland wrote:

(trimming)

> All create_mapping_late() calls should be performed with the same
> physical/virtual start/end as earlier "chunk" mappings, and thus should
> never result in a fuse/split or translation change -- only permission
> changes (which we believe do not result in TLB conflicts, or we'd need
> to do far more work to fix those up).
>
> If we split/fuse in any case other than EFI runtime table creation, that
> is a bug that we need to fix. If you're seeing a case we do that, then
> please let me know!

We are saying the same thing, and right now the biggest violator is 
probably the .rodata patch I just posted!






From mark.rutland at arm.com  Fri Feb 12 10:11:02 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 12 Feb 2016 18:11:02 +0000
Subject: [PATCH 2/2] arm64: Mark kernel page ranges contiguous
In-Reply-To: <56BE1FE5.8080002@arm.com>
References: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
 <1455293208-6763-3-git-send-email-jeremy.linton@arm.com>
 <20160212165707.GB20262@leverpostej> <56BE17C9.6090608@arm.com>
 <20160212175857.GE20262@leverpostej> <56BE1FE5.8080002@arm.com>
Message-ID: <20160212181102.GF20262@leverpostej>

On Fri, Feb 12, 2016 at 12:09:41PM -0600, Jeremy Linton wrote:
> On 02/12/2016 11:58 AM, Mark Rutland wrote:
> 
> (trimming)
> 
> >All create_mapping_late() calls should be performed with the same
> >physical/virtual start/end as earlier "chunk" mappings, and thus should
> >never result in a fuse/split or translation change -- only permission
> >changes (which we believe do not result in TLB conflicts, or we'd need
> >to do far more work to fix those up).
> >
> >If we split/fuse in any case other than EFI runtime table creation, that
> >is a bug that we need to fix. If you're seeing a case we do that, then
> >please let me know!
> 
> We are saying the same thing, and right now the biggest violator is
> probably the .rodata patch I just posted!

Ok, phew!

The simple fix is to make .text and .rodata separate "chunks", then it
all falls out in the wash.

Mark.


From yang.shi at linaro.org  Fri Feb 12 09:56:43 2016
From: yang.shi at linaro.org (Yang Shi)
Date: Fri, 12 Feb 2016 09:56:43 -0800
Subject: [PATCH] arm64: remove redundant preempt.h
Message-ID: <1455299803-317-1-git-send-email-yang.shi@linaro.org>

preempt.h has been included by sched.h, so it is not necessary to include
both, just keep sched.h.

Signed-off-by: Yang Shi <yang.shi at linaro.org>
---
Happened to find this when checking preempt.h include for another patch review.
Build test is passed with and without CONFIG_PREEMPT enabled.

 arch/arm64/kernel/cpuinfo.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 212ae63..e2b37ff 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -25,7 +25,6 @@
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/personality.h>
-#include <linux/preempt.h>
 #include <linux/printk.h>
 #include <linux/seq_file.h>
 #include <linux/sched.h>
-- 
2.0.2



From nicolas.pitre at linaro.org  Fri Feb 12 10:21:33 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 12 Feb 2016 13:21:33 -0500 (EST)
Subject: [PATCH] [media] zl10353: use div_u64 instead of do_div
In-Reply-To: <2712691.b9gkR7KMX7@wuerfel>
References: <1455287246-3540549-1-git-send-email-arnd@arndb.de>
 <20160212143220.5a440e66@recife.lan> <2712691.b9gkR7KMX7@wuerfel>
Message-ID: <alpine.LFD.2.20.1602121305180.13632@knanqh.ubzr>

On Fri, 12 Feb 2016, Arnd Bergmann wrote:

> On Friday 12 February 2016 14:32:20 Mauro Carvalho Chehab wrote:
> > Em Fri, 12 Feb 2016 15:27:18 +0100
> > Arnd Bergmann <arnd at arndb.de> escreveu:
> > 
> > > I noticed a build error in some randconfig builds in the zl10353 driver:
> > > 
> > > dvb-frontends/zl10353.c:138: undefined reference to `____ilog2_NaN'
> > > dvb-frontends/zl10353.c:138: undefined reference to `__aeabi_uldivmod'
> > > 
> > > The problem can be tracked down to the use of -fprofile-arcs (using
> > > CONFIG_GCOV_PROFILE_ALL) in combination with CONFIG_PROFILE_ALL_BRANCHES
> > > on gcc version 4.9 or higher, when it fails to reliably optimize
> > > constant expressions.
> > > 
> > > Using div_u64() instead of do_div() makes the code slightly more
> > > readable by both humans and by gcc, which gives the compiler enough
> > > of a break to figure it all out.
> > 
> > I'm not against this patch, but we have 94 occurrences of do_div() 
> > just at the media subsystem. If this is failing here, it would likely
> > fail with other drivers. So, I guess we should either fix do_div() or
> > convert all such occurrences to do_div64().
> 
> I agree that it's possible that the same problem exists elsewhere, but this is
> the only one that I ever saw (in five ranconfig builds out of 8035 last week).
> 
> I also tried changing do_div() to be an inline function with just a small
> macro wrapper around it for the odd calling conventions, which also made this
> error go away. I would assume that Nico had a good reason for doing do_div()
> the way he did.

The do_div() calling convention predates my work on it.  I assume it was 
originally done this way to better map onto the x86 instruction.

> In some other files, I saw the object code grow by a few
> instructions, but the examples I looked at were otherwise identical.
> 
> I can imagine that there might be cases where the constant-argument optimization
> of do_div fails when we go through an inline function in some combination
> of Kconfig options and compiler version, though I don't think that was
> the case here.

What could be tried is to turn __div64_const32() into a static inline 
and see if that makes a difference with those gcc versions we currently 
accept.

> Nico, any other thoughts on this?

This is all related to the gcc bug for which I produced a test case 
here:

http://article.gmane.org/gmane.linux.kernel.cross-arch/29801

Do you know if this is fixed in recent gcc?


Nicolas


From mathieu.poirier at linaro.org  Fri Feb 12 10:24:35 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Fri, 12 Feb 2016 11:24:35 -0700
Subject: [PATCH V3 6/6] coresight-stm: adding driver for CoreSight STM
 component
In-Reply-To: <VI1PR08MB06708C5EA9DEE2D71C13FFAA8AA90@VI1PR08MB0670.eurprd08.prod.outlook.com>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
 <1454756672-12790-7-git-send-email-zhang.chunyan@linaro.org>
 <CANLsYkxvLFu1C+_H9c0EoMebLQu1gnwt9bqY6_R3j+ua2w+xMg@mail.gmail.com>
 <VI1PR08MB06708C5EA9DEE2D71C13FFAA8AA90@VI1PR08MB0670.eurprd08.prod.outlook.com>
Message-ID: <CANLsYkynL9S0ui05-c2NfUeCMvBdKSFZZGuvqGPCQ4RijiNpAQ@mail.gmail.com>

On 12 February 2016 at 07:55, Michael Williams <Michael.Williams at arm.com> wrote:
> Mathieu Poirier [mailto:mathieu.poirier at linaro.org] wrote:
>> On 6 February 2016 at 04:04, Chunyan Zhang <zhang.chunyan at linaro.org> wrote:
>>> From: Pratik Patel <pratikp at codeaurora.org>
>>>
>>> This driver adds support for the STM CoreSight IP block, allowing any
>>> system compoment (HW or SW) to log and aggregate messages via a
>>> single entity.
>>>
>>> The CoreSight STM exposes an application defined number of channels
>>> called stimulus port.  Configuration is done using entries in sysfs
>>> and channels made available to userspace via configfs.
>>>
>>> Signed-off-by: Pratik Patel <pratikp at codeaurora.org>
>>> Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
>>> Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
>>> ---
>>>  .../ABI/testing/sysfs-bus-coresight-devices-stm    |  53 ++
>>>  Documentation/trace/coresight.txt                  |  37 +-
>>>  drivers/hwtracing/coresight/Kconfig                |  11 +
>>>  drivers/hwtracing/coresight/Makefile               |   1 +
>>>  drivers/hwtracing/coresight/coresight-stm.c        | 928 +++++++++++++++++++++
>>>  include/linux/coresight-stm.h                      |   6 +
>>>  include/uapi/linux/coresight-stm.h                 |  12 +
>>>  7 files changed, 1046 insertions(+), 2 deletions(-)
>>>  create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>>>  create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
>>>  create mode 100644 include/linux/coresight-stm.h
>>>  create mode 100644 include/uapi/linux/coresight-stm.h
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>>> new file mode 100644
>>> index 0000000..a1d7022
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>>> @@ -0,0 +1,53 @@
>>> +What:          /sys/bus/coresight/devices/<memory_map>.stm/enable_source
>>> +Date:          February 2016
>>> +KernelVersion: 4.5
>>> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
>>> +Description:   (RW) Enable/disable tracing on this specific trace macrocell.
>>> +               Enabling the trace macrocell implies it has been configured
>>> +               properly and a sink has been identidifed for it.  The path
>>> +               of coresight components linking the source to the sink is
>>> +               configured and managed automatically by the coresight framework.
>>> +
>>> +What:          /sys/bus/coresight/devices/<memory_map>.stm/hwevent_enable
>>> +Date:          February 2016
>>> +KernelVersion: 4.5
>>> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
>>> +Description:   (RW) Provides access to the HW event enable register, used in
>>> +               conjunction with HW event bank select register.
>>> +
>>> +What:          /sys/bus/coresight/devices/<memory_map>.stm/hwevent_select
>>> +Date:          February 2016
>>> +KernelVersion: 4.5
>>> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
>>> +Description:   (RW) Gives access to the HW event block select register
>>> +               (STMHEBSR) in order to configure up to 256 channels.  Used in
>>> +               conjunction with "hwevent_enable" register as described above.
>>> +
>>> +What:          /sys/bus/coresight/devices/<memory_map>.stm/port_enable
>>> +Date:          February 2016
>>> +KernelVersion: 4.5
>>> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
>>> +Description:   (RW) Provides access to the stimlus port enable register
>>> +               (STMSPER).  Used in conjunction with "port_select" described
>>> +               below.
>>> +
>>> +What:          /sys/bus/coresight/devices/<memory_map>.stm/port_select
>>> +Date:          February 2016
>>> +KernelVersion: 4.5
>>> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
>>> +Description:   (RW) Used to determine which bank of stimulus port bit in
>>> +               register STMSPER (see above) apply to.
>>> +
>>> +What:          /sys/bus/coresight/devices/<memory_map>.stm/status
>>> +Date:          February 2016
>>> +KernelVersion: 4.5
>>> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
>>> +Description:   (R) List various control and status registers.  The specific
>>> +               layout and content is driver specific.
>>> +
>>> +What:          /sys/bus/coresight/devices/<memory_map>.stm/traceid
>>> +Date:          February 2016
>>> +KernelVersion: 4.5
>>> +Contact:       Mathieu Poirier <mathieu.poirier at linaro.org>
>>> +Description:   (RW) Holds the trace ID that will appear in the trace stream
>>> +               coming from this trace entity.
>>> diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
>>> index 0a5c329..a33c88c 100644
>>> --- a/Documentation/trace/coresight.txt
>>> +++ b/Documentation/trace/coresight.txt
>>> @@ -190,8 +190,8 @@ expected to be accessed and controlled using those entries.
>>>  Last but not least, "struct module *owner" is expected to be set to reflect
>>>  the information carried in "THIS_MODULE".
>>>
>>> -How to use
>>> -----------
>>> +How to use the tracer modules
>>> +-----------------------------
>>>
>>>  Before trace collection can start, a coresight sink needs to be identify.
>>>  There is no limit on the amount of sinks (nor sources) that can be enabled at
>>> @@ -297,3 +297,36 @@ Info                                    Tracing enabled
>>>  Instruction     13570831        0x8026B584      E28DD00C        false   ADD
>> sp,sp,#0xc
>>>  Instruction     0       0x8026B588      E8BD8000        true    LDM      sp!,{pc}
>>>  Timestamp                                       Timestamp: 17107041535
>>> +
>>> +How to use the STM module
>>> +-------------------------
>>> +
>>> +Using the System Trace Macrocell module is the same as the tracers - the only
>>> +difference is that clients are driving the trace capture rather
>>> +than the program flow through the code.
>>> +
>>> +As with any other CoreSight component, specifics about the STM tracer can be
>>> +found in sysfs with more information on each entry being found in [1]:
>>> +
>>> +root at genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
>>> +enable_source   hwevent_select  port_enable     subsystem       uevent
>>> +hwevent_enable  mgmt            port_select     traceid
>>> +root at genericarmv8:~#
>>> +
>>> +Like any other source a sink needs to be identified and the STM enabled before
>>> +being used:
>>> +
>>> +root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
>>> +root at genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
>>> +
>>> +From there user space applications can request and use channels using the devfs
>>> +interface provided for that purpose by the generic STM API:
>>> +
>>> +root at genericarmv8:~# ls -l /dev/20100000.stm
>>> +crw-------    1 root     root       10,  61 Jan  3 18:11 /dev/20100000.stm
>>> +root at genericarmv8:~#
>>> +
>>> +Details on how to use the generic STM API can be found here [2].
>>> +
>>> +[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>>> +[2]. Documentation/trace/stm.txt
>>> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
>>> index c85935f..f4a8bfa 100644
>>> --- a/drivers/hwtracing/coresight/Kconfig
>>> +++ b/drivers/hwtracing/coresight/Kconfig
>>> @@ -77,4 +77,15 @@ config CORESIGHT_QCOM_REPLICATOR
>>>           programmable ATB replicator sends the ATB trace stream from the
>>>           ETB/ETF to the TPIUi and ETR.
>>>
>>> +config CORESIGHT_STM
>>> +       bool "CoreSight System Trace Macrocell driver"
>>> +       depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) || ARM64
>>> +       select CORESIGHT_LINKS_AND_SINKS
>>> +       select STM
>>> +       help
>>> +         This driver provides support for hardware assisted software
>>> +         instrumentation based tracing. This is primarily used for
>>> +         logging useful software events or data coming from various entities
>>> +         in the system, possibly running different OSs
>>> +
>>>  endif
>>> diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
>>> index 99f8e5f..1f6eaec 100644
>>> --- a/drivers/hwtracing/coresight/Makefile
>>> +++ b/drivers/hwtracing/coresight/Makefile
>>> @@ -11,3 +11,4 @@ obj-$(CONFIG_CORESIGHT_LINKS_AND_SINKS) += coresight-funnel.o \
>>>  obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o coresight-etm-cp14.o
>>>  obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
>>>  obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
>>> +obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
>>> diff --git a/drivers/hwtracing/coresight/coresight-stm.c
>> b/drivers/hwtracing/coresight/coresight-stm.c
>>> new file mode 100644
>>> index 0000000..01b3521
>>> --- /dev/null
>>> +++ b/drivers/hwtracing/coresight/coresight-stm.c
>>> @@ -0,0 +1,928 @@
>>> +/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 and
>>> + * only version 2 as published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * Initial implementation by Pratik Patel
>>> + * (C) 2014-2015 Pratik Patel <pratikp at codeaurora.org>
>>> + *
>>> + * Serious refactoring, code cleanup and upgrading to the Coresight upstream
>>> + * framework by Mathieu Poirier
>>> + * (C) 2015-2016 Mathieu Poirier <mathieu.poirier at linaro.org>
>>> + *
>>> + * Guaranteed timing and support for various packet type coming from the
>>> + * generic STM API by Chunyan Zhang
>>> + * (C) 2015-2016 Chunyan Zhang <zhang.chunyan at linaro.org>
>>> + */
>>> +#include <linux/amba/bus.h>
>>> +#include <linux/bitmap.h>
>>> +#include <linux/clk.h>
>>> +#include <linux/coresight.h>
>>> +#include <linux/coresight-stm.h>
>>> +#include <linux/err.h>
>>> +#include <linux/kernel.h>
>>> +#include <linux/module.h>
>>> +#include <linux/of_address.h>
>>> +#include <linux/pm_runtime.h>
>>> +#include <linux/stm.h>
>>> +
>>> +#include "coresight-priv.h"
>>> +
>>> +#define STMDMASTARTR                   0xc04
>>> +#define STMDMASTOPR                    0xc08
>>> +#define STMDMASTATR                    0xc0c
>>> +#define STMDMACTLR                     0xc10
>>> +#define STMDMAIDR                      0xcfc
>>> +#define STMHEER                                0xd00
>>> +#define STMHETER                       0xd20
>>> +#define STMHEBSR                       0xd60
>>> +#define STMHEMCR                       0xd64
>>> +#define STMHEMASTR                     0xdf4
>>> +#define STMHEFEAT1R                    0xdf8
>>> +#define STMHEIDR                       0xdfc
>>> +#define STMSPER                                0xe00
>>> +#define STMSPTER                       0xe20
>>> +#define STMPRIVMASKR                   0xe40
>>> +#define STMSPSCR                       0xe60
>>> +#define STMSPMSCR                      0xe64
>>> +#define STMSPOVERRIDER                 0xe68
>>> +#define STMSPMOVERRIDER                        0xe6c
>>> +#define STMSPTRIGCSR                   0xe70
>>> +#define STMTCSR                                0xe80
>>> +#define STMTSSTIMR                     0xe84
>>> +#define STMTSFREQR                     0xe8c
>>> +#define STMSYNCR                       0xe90
>>> +#define STMAUXCR                       0xe94
>>> +#define STMSPFEAT1R                    0xea0
>>> +#define STMSPFEAT2R                    0xea4
>>> +#define STMSPFEAT3R                    0xea8
>>> +#define STMITTRIGGER                   0xee8
>>> +#define STMITATBDATA0                  0xeec
>>> +#define STMITATBCTR2                   0xef0
>>> +#define STMITATBID                     0xef4
>>> +#define STMITATBCTR0                   0xef8
>>> +
>>> +#define STM_32_CHANNEL                 32
>>> +#define BYTES_PER_CHANNEL              256
>>> +#define STM_TRACE_BUF_SIZE             4096
>>> +#define STM_SW_MASTER_END              127
>>> +
>>> +/* Register bit definition */
>>> +#define STMTCSR_BUSY_BIT               23
>>> +/* Reserve the first 10 channels for kernel usage */
>>> +#define STM_CHANNEL_OFFSET             0
>>> +
>>> +enum stm_pkt_type {
>>> +       STM_PKT_TYPE_DATA       = 0x98,
>>> +       STM_PKT_TYPE_FLAG       = 0xE8,
>>> +       STM_PKT_TYPE_TRIG       = 0xF8,
>>> +};
>>> +
>>> +#define stm_channel_addr(drvdata, ch)  (drvdata->chs.base +    \
>>> +                                       (ch * BYTES_PER_CHANNEL))
>>> +#define stm_channel_off(type, opts)    (type & ~opts)
>>> +
>>> +static int boot_nr_channel;
>>> +
>>> +module_param_named(
>>> +       boot_nr_channel, boot_nr_channel, int, S_IRUGO
>>> +);
>>> +
>>> +/**
>>> + * struct channel_space - central management entity for extended ports
>>> + * @base:              memory mapped base address where channels start.
>>> + * @guaraneed:         is the channel delivery guaranteed.
>>> + */
>>> +struct channel_space {
>>> +       void __iomem            *base;
>>> +       unsigned long           *guaranteed;
>>> +};
>>> +
>>> +/**
>>> + * struct stm_drvdata - specifics associated to an STM component
>>> + * @base:              memory mapped base address for this component.
>>> + * @dev:               the device entity associated to this component.
>>> + * @atclk:             optional clock for the core parts of the STM.
>>> + * @csdev:             component vitals needed by the framework.
>>> + * @spinlock:          only one at a time pls.
>>> + * @chs:               the channels accociated to this STM.
>>> + * @stm:               structure associated to the generic STM interface.
>>> + * @enable:            this STM is being used.
>>> + * @traceid:           value of the current ID for this component.
>>> + * @write_max:         Maximus bytes this STM can write at a time.
>>> + * @write_64bit:       whether this STM supports 64 bit access.
>>> + * @stmsper:           settings for register STMSPER.
>>> + * @stmspscr:          settings for register STMSPSCR.
>>> + * @numsp:             the total number of stimulus port support by this STM.
>>> + * @stmheer:           settings for register STMHEER.
>>> + * @stmheter:          settings for register STMHETER.
>>> + * @stmhebsr:          settings for register STMHEBSR.
>>> + */
>>> +struct stm_drvdata {
>>> +       void __iomem            *base;
>>> +       struct device           *dev;
>>> +       struct clk              *atclk;
>>> +       struct coresight_device *csdev;
>>> +       spinlock_t              spinlock;
>>> +       struct channel_space    chs;
>>> +       struct stm_data         stm;
>>> +       bool                    enable;
>>> +       u8                      traceid;
>>> +       u8                      write_max;
>>> +       u32                     write_64bit;
>>> +       u32                     stmsper;
>>> +       u32                     stmspscr;
>>> +       u32                     numsp;
>>> +       u32                     stmheer;
>>> +       u32                     stmheter;
>>> +       u32                     stmhebsr;
>>> +};
>>> +
>>> +static void stm_hwevent_enable_hw(struct stm_drvdata *drvdata)
>>> +{
>>> +       CS_UNLOCK(drvdata->base);
>>> +
>>> +       writel_relaxed(drvdata->stmhebsr, drvdata->base + STMHEBSR);
>>> +       writel_relaxed(drvdata->stmheter, drvdata->base + STMHETER);
>>> +       writel_relaxed(drvdata->stmheer, drvdata->base + STMHEER);
>>> +       writel_relaxed(0x01 |   /* Enable HW event tracing */
>>> +                      0x04,    /* Error detection on event tracing */
>>> +                      drvdata->base + STMHEMCR);
>>> +
>>> +       CS_LOCK(drvdata->base);
>>> +}
>>> +
>>> +static void stm_port_enable_hw(struct stm_drvdata *drvdata)
>>> +{
>>> +       CS_UNLOCK(drvdata->base);
>>> +       /* ATB trigger enable on direct writes to TRIG locations */
>>> +       writel_relaxed(0x10,
>>> +                      drvdata->base + STMSPTRIGCSR);
>>> +       writel_relaxed(drvdata->stmspscr, drvdata->base + STMSPSCR);
>>> +       writel_relaxed(drvdata->stmsper, drvdata->base + STMSPER);
>>> +
>>> +       CS_LOCK(drvdata->base);
>>> +}
>>> +
>>> +static void stm_enable_hw(struct stm_drvdata *drvdata)
>>> +{
>>> +       if (drvdata->stmheer)
>>> +               stm_hwevent_enable_hw(drvdata);
>>> +
>>> +       stm_port_enable_hw(drvdata);
>>> +
>>> +       CS_UNLOCK(drvdata->base);
>>> +
>>> +       /* 4096 byte between synchronisation packets */
>>> +       writel_relaxed(0xFFF, drvdata->base + STMSYNCR);
>>> +       writel_relaxed((drvdata->traceid << 16 | /* trace id */
>>> +                       0x02 |                   /* timestamp enable */
>>> +                       0x01),                   /* global STM enable */
>>> +                       drvdata->base + STMTCSR);
>>> +
>>> +       CS_LOCK(drvdata->base);
>>> +}
>>> +
>>> +static int stm_enable(struct coresight_device *csdev)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>>> +
>>> +       pm_runtime_get_sync(drvdata->dev);
>>> +
>>> +       spin_lock(&drvdata->spinlock);
>>> +       stm_enable_hw(drvdata);
>>> +       drvdata->enable = true;
>>> +       spin_unlock(&drvdata->spinlock);
>>> +
>>> +       dev_info(drvdata->dev, "STM tracing enabled\n");
>>> +       return 0;
>>> +}
>>> +
>>> +static void stm_hwevent_disable_hw(struct stm_drvdata *drvdata)
>>> +{
>>> +       CS_UNLOCK(drvdata->base);
>>> +
>>> +       writel_relaxed(0x0, drvdata->base + STMHEMCR);
>>> +       writel_relaxed(0x0, drvdata->base + STMHEER);
>>> +       writel_relaxed(0x0, drvdata->base + STMHETER);
>>> +
>>> +       CS_LOCK(drvdata->base);
>>> +}
>>> +
>>> +static void stm_port_disable_hw(struct stm_drvdata *drvdata)
>>> +{
>>> +       CS_UNLOCK(drvdata->base);
>>> +
>>> +       writel_relaxed(0x0, drvdata->base + STMSPER);
>>> +       writel_relaxed(0x0, drvdata->base + STMSPTRIGCSR);
>>> +
>>> +       CS_LOCK(drvdata->base);
>>> +}
>>> +
>>> +static void stm_disable_hw(struct stm_drvdata *drvdata)
>>> +{
>>> +       u32 val;
>>> +
>>> +       CS_UNLOCK(drvdata->base);
>>> +
>>> +       val = readl_relaxed(drvdata->base + STMTCSR);
>>> +       val &= ~0x1; /* clear global STM enable [0] */
>>> +       writel_relaxed(val, drvdata->base + STMTCSR);
>>> +
>>> +       CS_LOCK(drvdata->base);
>>> +
>>> +       stm_port_disable_hw(drvdata);
>>> +       if (drvdata->stmheer)
>>> +               stm_hwevent_disable_hw(drvdata);
>>> +}
>>> +
>>> +static void stm_disable(struct coresight_device *csdev)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>>> +
>>> +       spin_lock(&drvdata->spinlock);
>>> +       stm_disable_hw(drvdata);
>>> +       drvdata->enable = false;
>>> +       spin_unlock(&drvdata->spinlock);
>>> +
>>> +       /* Wait until the engine has completely stopped */
>>> +       coresight_timeout(drvdata, STMTCSR, STMTCSR_BUSY_BIT, 0);
>>> +
>>> +       pm_runtime_put(drvdata->dev);
>>> +
>>> +       dev_info(drvdata->dev, "STM tracing disabled\n");
>>> +}
>>> +
>>> +static int stm_trace_id(struct coresight_device *csdev)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>>> +
>>> +       return drvdata->traceid;
>>> +}
>>> +
>>> +static const struct coresight_ops_source stm_source_ops = {
>>> +       .trace_id       = stm_trace_id,
>>> +       .enable         = stm_enable,
>>> +       .disable        = stm_disable,
>>> +};
>>> +
>>> +static const struct coresight_ops stm_cs_ops = {
>>> +       .source_ops     = &stm_source_ops,
>>> +};
>>> +
>>> +static inline bool stm_addr_unaligned(const void *addr, u8 max)
>>> +{
>>> +       return ((unsigned long)addr & (max - 1));
>>> +}
>>> +
>>> +static int stm_send(void *addr, const void *data, u32 size, u8 max)
>>> +{
>>> +       u32 len = size;
>>> +       u8 paload[8];
>>> +
>>> +       if (stm_addr_unaligned(data, max)) {
>>> +               memcpy(paload, data, size);
>>> +               data = paload;
>>> +       }
>>> +
>>> +       /* now we are 64bit/32bit aligned */
>>> +#ifdef CONFIG_64BIT
>>> +       if (size == 8)
>>> +               writeq_relaxed(*(u64 *)data, addr);
>>> +#endif
>>
>> We probably don't need an #ifdef here.  Checking the size of the
>> transfer against the fundamental data size will result in the same
>> outcome, i.e preventing 64 bit transfers on a 32 bit architecture.  An
>> error (understandable by the caller) should probably be returned in
>> this case.
>
> In theory this is correct, but if the code is unreachable for non-32-bit architectures, why include it at all?

Why is this code unreachable on 64-bit systems?  In this latest
revision "stm_send()" is used for both architecture.

>
>>> +       if (size >= 4) {
>>> +               writel_relaxed(*(u32 *)data, addr);
>>> +               data += 4;
>>> +               size -= 4;
>>> +       }
>>> +
>>> +       if (size >= 2) {
>>> +               writew_relaxed(*(u16 *)data, addr);
>>> +               data += 2;
>>> +               size -= 2;
>>> +       }
>>> +
>>> +       if (size == 1)
>>> +               writeb_relaxed(*(u8 *)data, addr);
>>> +
>>> +       return len;
>>> +}
>
> The API for stm_data::packet (include/linux/stm.h) is not wholly clearly defined, but it does state "sends an STP packet," which I interpret as meaning exactly one packet and no more. This function (which is called from this module's implementation of stm_data::packet) will send multiple STP packets if called with a value that is not exactly 8, 4, 2, or 1.

I agree.

>
> To send only one packet, either:
>
> * These "if" statements are replaced with "else if" (as appropriate), and the function returns the size of data consumed; or

Please use a 'case' statement.

> * The stm_generic_packet() function (below) forces "size" to a power-of-two (<= write_max) before calling stm_send().

That will become a nightmare to debug/maintain - function stm_write()
[1] is already doing the count management.

[1]. http://lxr.free-electrons.com/source/drivers/hwtracing/stm/core.c#L383

>
>>> +static int stm_generic_link(struct stm_data *stm_data,
>>> +                           unsigned int master,  unsigned int channel)
>>> +{
>>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>>> +                                                  struct stm_drvdata, stm);
>>> +       if (!drvdata || !drvdata->csdev)
>>> +               return -EINVAL;
>>> +
>>> +       return coresight_enable(drvdata->csdev);
>>> +}
>>> +
>>> +static void stm_generic_unlink(struct stm_data *stm_data,
>>> +                              unsigned int master,  unsigned int channel)
>>> +{
>>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>>> +                                                  struct stm_drvdata, stm);
>>> +       if (!drvdata || !drvdata->csdev)
>>> +               return;
>>> +
>>> +       stm_disable(drvdata->csdev);
>>> +}
>>> +
>>> +static long stm_generic_set_options(struct stm_data *stm_data,
>>> +                                   unsigned int master,
>>> +                                   unsigned int channel,
>>> +                                   unsigned int nr_chans,
>>> +                                   unsigned long options)
>>> +{
>>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>>> +                                                  struct stm_drvdata, stm);
>>> +       if (!(drvdata && drvdata->enable))
>>> +               return -EINVAL;
>>> +
>>> +       if (channel >= drvdata->numsp)
>>> +               return -EINVAL;
>>> +
>>> +       switch (options) {
>>> +       case STM_OPTION_GUARANTEED:
>>> +               set_bit(channel, drvdata->chs.guaranteed);
>>> +               break;
>>> +
>>> +       case STM_OPTION_INVARIANT:
>>> +               clear_bit(channel, drvdata->chs.guaranteed);
>>> +               break;
>>> +
>>> +       default:
>>> +               return -EINVAL;
>>> +       }
>>> +
>>> +       return 0;
>>> +}
>>> +
>>> +static long stm_generic_get_options(struct stm_data *stm_data,
>>> +                                   unsigned int master,
>>> +                                   unsigned int channel,
>>> +                                   unsigned int nr_chans,
>>> +                                   u64 *options)
>>> +{
>>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>>> +                                                  struct stm_drvdata, stm);
>>> +       if (!(drvdata && drvdata->enable))
>>> +               return -EINVAL;
>>> +
>>> +       if (channel >= drvdata->numsp)
>>> +               return -EINVAL;
>>> +
>>> +       switch (*options) {
>>> +       case STM_OPTION_GUARANTEED:
>>> +               *options = test_bit(channel, drvdata->chs.guaranteed);
>>> +               break;
>>> +
>>> +       default:
>>> +               return -EINVAL;
>>> +       }
>>> +
>>> +       return 0;
>>> +}
>>> +
>>> +static ssize_t stm_generic_packet(struct stm_data *stm_data,
>>> +                                 unsigned int master,
>>> +                                 unsigned int channel,
>>> +                                 unsigned int packet,
>>> +                                 unsigned int flags,
>>> +                                 unsigned int size,
>>> +                                 const unsigned char *payload)
>>> +{
>>> +       unsigned long ch_addr;
>>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>>> +                                                  struct stm_drvdata, stm);
>>> +
>>> +       if (!(drvdata && drvdata->enable))
>>> +               return 0;
>>> +
>>> +       if (channel >= drvdata->numsp)
>>> +               return 0;
>>> +
>>> +       ch_addr = (unsigned long)stm_channel_addr(drvdata, channel);
>>> +
>>> +       flags = (flags == STP_PACKET_TIMESTAMPED) ? STM_FLAG_TIMESTAMPED : 0;
>>> +       flags |= test_bit(channel, drvdata->chs.guaranteed) ?
>>> +                          STM_FLAG_GUARANTEED : 0;
>>> +
>>> +       if (size > drvdata->write_max)
>>> +               size = drvdata->write_max;
>>> +
>>> +       switch (packet) {
>>> +       case STP_PACKET_FLAG:
>>> +               ch_addr |= stm_channel_off(STM_PKT_TYPE_FLAG, flags);
>>> +
>>> +               /* the generic STM API set a size of zero on flag packets. */
>>> +               size = 1;
>>> +               break;
>>> +
>>> +       case STP_PACKET_DATA:
>>> +               ch_addr |= stm_channel_off(STM_PKT_TYPE_DATA, flags);
>>> +               break;
>>> +
>>> +       default:
>>> +               return 0;
>>> +       }
>>> +
>>> +       return stm_send((void *)ch_addr, payload, size, drvdata->write_max);
>>> +}
>>> +
>>> +static ssize_t hwevent_enable_show(struct device *dev,
>>> +                                  struct device_attribute *attr, char *buf)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val = drvdata->stmheer;
>>> +
>>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>>> +}
>>> +
>>> +static ssize_t hwevent_enable_store(struct device *dev,
>>> +                                   struct device_attribute *attr,
>>> +                                   const char *buf, size_t size)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val;
>>> +       int ret = 0;
>>> +
>>> +       ret = kstrtoul(buf, 16, &val);
>>> +       if (ret)
>>> +               return -EINVAL;
>>> +
>>> +       drvdata->stmheer = val;
>>> +       /* HW event enable and trigger go hand in hand */
>>> +       drvdata->stmheter = val;
>>> +
>>> +       return size;
>>> +}
>>> +static DEVICE_ATTR_RW(hwevent_enable);
>>> +
>>> +static ssize_t hwevent_select_show(struct device *dev,
>>> +                                  struct device_attribute *attr, char *buf)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val = drvdata->stmhebsr;
>>> +
>>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>>> +}
>>> +
>>> +static ssize_t hwevent_select_store(struct device *dev,
>>> +                                   struct device_attribute *attr,
>>> +                                   const char *buf, size_t size)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val;
>>> +       int ret = 0;
>>> +
>>> +       ret = kstrtoul(buf, 16, &val);
>>> +       if (ret)
>>> +               return -EINVAL;
>>> +
>>> +       drvdata->stmhebsr = val;
>>> +
>>> +       return size;
>>> +}
>>> +static DEVICE_ATTR_RW(hwevent_select);
>>> +
>>> +static ssize_t port_select_show(struct device *dev,
>>> +                               struct device_attribute *attr, char *buf)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val;
>>> +
>>> +       if (!drvdata->enable) {
>>> +               val = drvdata->stmspscr;
>>> +       } else {
>>> +               spin_lock(&drvdata->spinlock);
>>> +               val = readl_relaxed(drvdata->base + STMSPSCR);
>>> +               spin_unlock(&drvdata->spinlock);
>>> +       }
>>> +
>>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>>> +}
>>> +
>>> +static ssize_t port_select_store(struct device *dev,
>>> +                                struct device_attribute *attr,
>>> +                                const char *buf, size_t size)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val, stmsper;
>>> +       int ret = 0;
>>> +
>>> +       ret = kstrtoul(buf, 16, &val);
>>> +       if (ret)
>>> +               return ret;
>>> +
>>> +       spin_lock(&drvdata->spinlock);
>>> +       drvdata->stmspscr = val;
>>> +
>>> +       if (drvdata->enable) {
>>> +               CS_UNLOCK(drvdata->base);
>>> +               /* Process as per ARM's TRM recommendation */
>>> +               stmsper = readl_relaxed(drvdata->base + STMSPER);
>>> +               writel_relaxed(0x0, drvdata->base + STMSPER);
>>> +               writel_relaxed(drvdata->stmspscr, drvdata->base + STMSPSCR);
>>> +               writel_relaxed(stmsper, drvdata->base + STMSPER);
>>> +               CS_LOCK(drvdata->base);
>>> +       }
>>> +       spin_unlock(&drvdata->spinlock);
>>> +
>>> +       return size;
>>> +}
>>> +static DEVICE_ATTR_RW(port_select);
>>> +
>>> +static ssize_t port_enable_show(struct device *dev,
>>> +                               struct device_attribute *attr, char *buf)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val;
>>> +
>>> +       if (!drvdata->enable) {
>>> +               val = drvdata->stmsper;
>>> +       } else {
>>> +               spin_lock(&drvdata->spinlock);
>>> +               val = readl_relaxed(drvdata->base + STMSPER);
>>> +               spin_unlock(&drvdata->spinlock);
>>> +       }
>>> +
>>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>>> +}
>>> +
>>> +static ssize_t port_enable_store(struct device *dev,
>>> +                                struct device_attribute *attr,
>>> +                                const char *buf, size_t size)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val;
>>> +       int ret = 0;
>>> +
>>> +       ret = kstrtoul(buf, 16, &val);
>>> +       if (ret)
>>> +               return ret;
>>> +
>>> +       spin_lock(&drvdata->spinlock);
>>> +       drvdata->stmsper = val;
>>> +
>>> +       if (drvdata->enable) {
>>> +               CS_UNLOCK(drvdata->base);
>>> +               writel_relaxed(drvdata->stmsper, drvdata->base + STMSPER);
>>> +               CS_LOCK(drvdata->base);
>>> +       }
>>> +       spin_unlock(&drvdata->spinlock);
>>> +
>>> +       return size;
>>> +}
>>> +static DEVICE_ATTR_RW(port_enable);
>>> +
>>> +static ssize_t traceid_show(struct device *dev,
>>> +                           struct device_attribute *attr, char *buf)
>>> +{
>>> +       unsigned long val;
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +
>>> +       val = drvdata->traceid;
>>> +       return sprintf(buf, "%#lx\n", val);
>>> +}
>>> +
>>> +static ssize_t traceid_store(struct device *dev,
>>> +                            struct device_attribute *attr,
>>> +                            const char *buf, size_t size)
>>> +{
>>> +       int ret;
>>> +       unsigned long val;
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +
>>> +       ret = kstrtoul(buf, 16, &val);
>>> +       if (ret)
>>> +               return ret;
>>> +
>>> +       /* traceid field is 7bit wide on STM32 */
>>> +       drvdata->traceid = val & 0x7f;
>>> +       return size;
>>> +}
>>> +static DEVICE_ATTR_RW(traceid);
>>> +
>>> +#define coresight_simple_func(type, name, offset)                      \
>>> +static ssize_t name##_show(struct device *_dev,                                \
>>> +                          struct device_attribute *attr, char *buf)    \
>>> +{                                                                      \
>>> +       type *drvdata = dev_get_drvdata(_dev->parent);                  \
>>> +       return scnprintf(buf, PAGE_SIZE, "0x%08x\n",                    \
>>> +                        readl_relaxed(drvdata->base + offset));        \
>>> +}                                                                      \
>>> +DEVICE_ATTR_RO(name)
>>> +
>>> +#define coresight_stm_simple_func(name, offset)        \
>>> +       coresight_simple_func(struct stm_drvdata, name, offset)
>>> +
>>> +coresight_stm_simple_func(tcsr, STMTCSR);
>>> +coresight_stm_simple_func(tsfreqr, STMTSFREQR);
>>> +coresight_stm_simple_func(syncr, STMSYNCR);
>>> +coresight_stm_simple_func(sper, STMSPER);
>>> +coresight_stm_simple_func(spter, STMSPTER);
>>> +coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
>>> +coresight_stm_simple_func(spscr, STMSPSCR);
>>> +coresight_stm_simple_func(spmscr, STMSPMSCR);
>>> +coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
>>> +coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
>>> +coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
>>> +coresight_stm_simple_func(devid, CORESIGHT_DEVID);
>>> +
>>> +static struct attribute *coresight_stm_attrs[] = {
>>> +       &dev_attr_hwevent_enable.attr,
>>> +       &dev_attr_hwevent_select.attr,
>>> +       &dev_attr_port_enable.attr,
>>> +       &dev_attr_port_select.attr,
>>> +       &dev_attr_traceid.attr,
>>> +       NULL,
>>> +};
>>> +
>>> +static struct attribute *coresight_stm_mgmt_attrs[] = {
>>> +       &dev_attr_tcsr.attr,
>>> +       &dev_attr_tsfreqr.attr,
>>> +       &dev_attr_syncr.attr,
>>> +       &dev_attr_sper.attr,
>>> +       &dev_attr_spter.attr,
>>> +       &dev_attr_privmaskr.attr,
>>> +       &dev_attr_spscr.attr,
>>> +       &dev_attr_spmscr.attr,
>>> +       &dev_attr_spfeat1r.attr,
>>> +       &dev_attr_spfeat2r.attr,
>>> +       &dev_attr_spfeat3r.attr,
>>> +       &dev_attr_devid.attr,
>>> +       NULL,
>>> +};
>>> +
>>> +static const struct attribute_group coresight_stm_group = {
>>> +       .attrs = coresight_stm_attrs,
>>> +};
>>> +
>>> +static const struct attribute_group coresight_stm_mgmt_group = {
>>> +       .attrs = coresight_stm_mgmt_attrs,
>>> +       .name = "mgmt",
>>> +};
>>> +
>>> +static const struct attribute_group *coresight_stm_groups[] = {
>>> +       &coresight_stm_group,
>>> +       &coresight_stm_mgmt_group,
>>> +       NULL,
>>> +};
>>> +
>>> +static int stm_get_resource_byname(struct device_node *np,
>>> +                                  char *ch_base, struct resource *res)
>>> +{
>>> +       const char *name = NULL;
>>> +       int index = 0, found = 0;
>>> +
>>> +       while (!of_property_read_string_index(np, "reg-names", index, &name)) {
>>> +               if (strcmp(ch_base, name)) {
>>> +                       index++;
>>> +                       continue;
>>> +               }
>>> +
>>> +               /* We have a match and @index is where it's at */
>>> +               found = 1;
>>> +               break;
>>> +       }
>>> +
>>> +       if (!found)
>>> +               return -EINVAL;
>>> +
>>> +       return of_address_to_resource(np, index, res);
>>> +}
>>> +
>>> +static u32 stm_fundamental_data_size(struct stm_drvdata *drvdata)
>>> +{
>>> +       u32 stmspfeat2r;
>>> +
>>> +       stmspfeat2r = readl_relaxed(drvdata->base + STMSPFEAT2R);
>>> +       return BMVAL(stmspfeat2r, 12, 15);
>>> +}
>>> +
>>> +static u32 stm_num_stimulus_port(struct stm_drvdata *drvdata)
>>> +{
>>> +       u32 numsp;
>>> +
>>> +       numsp = readl_relaxed(drvdata->base + CORESIGHT_DEVID);
>>> +       /*
>>> +        * NUMPS in STMDEVID is 17 bit long and if equal to 0x0,
>>> +        * 32 stimulus ports are supported.
>>> +        */
>>> +       numsp &= 0x1ffff;
>>> +       if (!numsp)
>>> +               numsp = STM_32_CHANNEL;
>>> +       return numsp;
>>> +}
>>> +
>>> +static void stm_init_default_data(struct stm_drvdata *drvdata)
>>> +{
>>> +       /* Don't use port selection */
>>> +       drvdata->stmspscr = 0x0;
>>> +       /*
>>> +        * Enable all channel regardless of their number.  When port
>>> +        * selection isn't used (see above) STMSPER applies to all
>>> +        * 32 channel group available, hence setting all 32 bits to 1
>>> +        */
>>> +       drvdata->stmsper = ~0x0;
>>> +
>>> +       /*
>>> +        * Select arbitrary value to start with.  If there is a conflict
>>> +        * with other tracers the framework will deal with it.
>>> +        */
>>> +       drvdata->traceid = 0x20;
>>> +
>>> +       /* Set invariant transaction timing on all channels */
>>> +       bitmap_clear(drvdata->chs.guaranteed, 0, drvdata->numsp);
>>> +}
>>> +
>>> +static void stm_init_generic_data(struct stm_drvdata *drvdata)
>>> +{
>>> +       drvdata->stm.name = dev_name(drvdata->dev);
>>> +       drvdata->stm.mstatic = true;
>>> +       drvdata->stm.sw_nchannels = drvdata->numsp;
>>> +       drvdata->stm.packet = stm_generic_packet;
>>> +       drvdata->stm.link = stm_generic_link;
>>> +       drvdata->stm.unlink = stm_generic_unlink;
>>> +       drvdata->stm.set_options = stm_generic_set_options;
>>> +       drvdata->stm.get_options = stm_generic_get_options;
>>> +}
>>> +
>>> +static int stm_probe(struct amba_device *adev, const struct amba_id *id)
>>> +{
>>> +       int ret;
>>> +       void __iomem *base;
>>> +       unsigned long *guaranteed;
>>> +       struct device *dev = &adev->dev;
>>> +       struct coresight_platform_data *pdata = NULL;
>>> +       struct stm_drvdata *drvdata;
>>> +       struct resource *res = &adev->res;
>>> +       struct resource ch_res;
>>> +       size_t res_size, bitmap_size;
>>> +       struct coresight_desc *desc;
>>> +       struct device_node *np = adev->dev.of_node;
>>> +
>>> +       if (np) {
>>> +               pdata = of_get_coresight_platform_data(dev, np);
>>> +               if (IS_ERR(pdata))
>>> +                       return PTR_ERR(pdata);
>>> +               adev->dev.platform_data = pdata;
>>> +       }
>>> +       drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
>>> +       if (!drvdata)
>>> +               return -ENOMEM;
>>> +
>>> +       drvdata->dev = &adev->dev;
>>> +       drvdata->atclk = devm_clk_get(&adev->dev, "atclk"); /* optional */
>>> +       if (!IS_ERR(drvdata->atclk)) {
>>> +               ret = clk_prepare_enable(drvdata->atclk);
>>> +               if (ret)
>>> +                       return ret;
>>> +       }
>>> +       dev_set_drvdata(dev, drvdata);
>>> +
>>> +       base = devm_ioremap_resource(dev, res);
>>> +       if (IS_ERR(base))
>>> +               return PTR_ERR(base);
>>> +       drvdata->base = base;
>>> +
>>> +       ret = stm_get_resource_byname(np, "stm-stimulus-base", &ch_res);
>>> +       if (ret)
>>> +               return ret;
>>> +
>>> +       base = devm_ioremap_resource(dev, &ch_res);
>>> +       if (IS_ERR(base))
>>> +               return PTR_ERR(base);
>>> +       drvdata->chs.base = base;
>>> +
>>> +       drvdata->write_max = sizeof(u32);
>>
>> Isn't the fundamental data size the maximum an architecture can stand?
>>  Why not simply use that rather than adding another variable?
>>
>>> +       drvdata->write_64bit = stm_fundamental_data_size(drvdata);
>>> +
>>> +#ifndef CONFIG_64BIT
>>> +       if (drvdata->write_64bit)
>>> +               drvdata->write_max = sizeof(u64);
>>> +#endif
>
> It is a bit odd that this code is using sizeof(u64) / sizeof(u32) here, when it is using 8 / 4 explicitly in the functions above.
>
>>
>> In most cases the fundamental data size will follow the architecture
>> size, i.e, 32 bit architecture with 32 bit fundamental data size, 64
>> bit architecture with 64 bit fundamental data size.  A fundamental
>> data size of 32 is also possible on a 64 bit architecture.
>>
>> What needs to be prevented is a 32 bit architecture with a fundamental
>> data size of 64.  In those cases the fundamental data size should be
>> adjusted to be 32 bit.  To do that I suggest to modify
>> stm_fundamental_data_size() to probe the STM's fundamental data size
>> but to adjust it down if on a 32 bit system.  Knowing whether running
>> on a 32/64 bit system is easy when using the IS_ENABLED() macro.
>
> Agreed. For ARM, 64-bit writes to the STM are supported only if BOTH the STM supports 64-bit data and the processor is in 64-bit execution state. Otherwise, the largest size is 32 bits. You are likely to see both 64-bit STM from 32-bit execution state, and 32-bit STM on a SoC with a 64-bit ARM processor.
>
>>> +
>>> +       if (boot_nr_channel) {
>>> +               drvdata->numsp = boot_nr_channel;
>>> +               res_size = min((resource_size_t)(boot_nr_channel *
>>> +                                 BYTES_PER_CHANNEL), resource_size(res));
>>> +       } else {
>>> +               drvdata->numsp = stm_num_stimulus_port(drvdata);
>>> +               res_size = min((resource_size_t)(drvdata->numsp *
>>> +                                BYTES_PER_CHANNEL), resource_size(res));
>>> +       }
>>> +       bitmap_size = BITS_TO_LONGS(drvdata->numsp) * sizeof(long);
>>> +
>>> +       guaranteed = devm_kzalloc(dev, bitmap_size, GFP_KERNEL);
>>> +       if (!guaranteed)
>>> +               return -ENOMEM;
>>> +       drvdata->chs.guaranteed = guaranteed;
>>> +
>>> +       spin_lock_init(&drvdata->spinlock);
>>> +
>>> +       stm_init_default_data(drvdata);
>>> +       stm_init_generic_data(drvdata);
>>> +
>>> +       if (stm_register_device(dev, &drvdata->stm, THIS_MODULE)) {
>>> +               dev_info(dev,
>>> +                        "stm_register_device failed, probing deffered\n");
>>> +               return -EPROBE_DEFER;
>>> +       }
>>> +
>>> +       desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
>>> +       if (!desc) {
>>> +               ret = -ENOMEM;
>>> +               goto stm_unregister;
>>> +       }
>>> +
>>> +       desc->type = CORESIGHT_DEV_TYPE_SOURCE;
>>> +       desc->subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE;
>>> +       desc->ops = &stm_cs_ops;
>>> +       desc->pdata = pdata;
>>> +       desc->dev = dev;
>>> +       desc->groups = coresight_stm_groups;
>>> +       drvdata->csdev = coresight_register(desc);
>>> +       if (IS_ERR(drvdata->csdev)) {
>>> +               ret = PTR_ERR(drvdata->csdev);
>>> +               goto stm_unregister;
>>> +       }
>>> +
>>> +       pm_runtime_put(&adev->dev);
>>> +
>>> +       dev_info(dev, "%s initialized\n", (char *)id->data);
>>> +       return 0;
>>> +
>>> +stm_unregister:
>>> +       stm_unregister_device(&drvdata->stm);
>>> +       return ret;
>>> +}
>>> +
>>> +static int stm_remove(struct amba_device *adev)
>>> +{
>>> +       struct stm_drvdata *drvdata = amba_get_drvdata(adev);
>>> +
>>> +       stm_unregister_device(&drvdata->stm);
>>> +       coresight_unregister(drvdata->csdev);
>>> +       return 0;
>>> +}
>>
>> The xyz_remove() functions is not needed for coresight devices -
>> unbinding a device from its driver will no longer be possible in the
>> 4.6 cycle.
>>
>>> +
>>> +#ifdef CONFIG_PM
>>> +static int stm_runtime_suspend(struct device *dev)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev);
>>> +
>>> +       if (drvdata && !IS_ERR(drvdata->atclk))
>>> +               clk_disable_unprepare(drvdata->atclk);
>>> +
>>> +       return 0;
>>> +}
>>> +
>>> +static int stm_runtime_resume(struct device *dev)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev);
>>> +
>>> +       if (drvdata && !IS_ERR(drvdata->atclk))
>>> +               clk_prepare_enable(drvdata->atclk);
>>> +
>>> +       return 0;
>>> +}
>>> +#endif
>>> +
>>> +static const struct dev_pm_ops stm_dev_pm_ops = {
>>> +       SET_RUNTIME_PM_OPS(stm_runtime_suspend, stm_runtime_resume, NULL)
>>> +};
>>> +
>>> +static struct amba_id stm_ids[] = {
>>> +       {
>>> +               .id     = 0x0003b962,
>>> +               .mask   = 0x0003ffff,
>>> +               .data   = "STM32",
>>> +       },
>>> +       { 0, 0},
>>> +};
>>> +
>>> +static struct amba_driver stm_driver = {
>>> +       .drv = {
>>> +               .name   = "coresight-stm",
>>> +               .owner  = THIS_MODULE,
>>> +               .pm     = &stm_dev_pm_ops,
>>> +       },
>>> +       .probe          = stm_probe,
>>> +       .remove         = stm_remove,
>>> +       .id_table       = stm_ids,
>>> +};
>>> +
>>> +module_amba_driver(stm_driver);
>>> +
>>> +MODULE_LICENSE("GPL v2");
>>> +MODULE_DESCRIPTION("CoreSight System Trace Macrocell driver");
>>> diff --git a/include/linux/coresight-stm.h b/include/linux/coresight-stm.h
>>> new file mode 100644
>>> index 0000000..a978bb8
>>> --- /dev/null
>>> +++ b/include/linux/coresight-stm.h
>>> @@ -0,0 +1,6 @@
>>> +#ifndef __LINUX_CORESIGHT_STM_H_
>>> +#define __LINUX_CORESIGHT_STM_H_
>>> +
>>> +#include <uapi/linux/coresight-stm.h>
>>> +
>>> +#endif
>>> diff --git a/include/uapi/linux/coresight-stm.h b/include/uapi/linux/coresight-stm.h
>>> new file mode 100644
>>> index 0000000..fa35f0b
>>> --- /dev/null
>>> +++ b/include/uapi/linux/coresight-stm.h
>>> @@ -0,0 +1,12 @@
>>> +#ifndef __UAPI_CORESIGHT_STM_H_
>>> +#define __UAPI_CORESIGHT_STM_H_
>>> +
>>> +#define STM_FLAG_TIMESTAMPED   BIT(3)
>>> +#define STM_FLAG_GUARANTEED    BIT(7)
>>> +
>>> +enum {
>>> +       STM_OPTION_GUARANTEED = 0,
>>> +       STM_OPTION_INVARIANT,
>>> +};
>>> +
>>> +#endif
>>> --
>>> 1.9.1
>>>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


From contact at paulk.fr  Fri Feb 12 10:25:32 2016
From: contact at paulk.fr (Paul Kocialkowski)
Date: Fri, 12 Feb 2016 19:25:32 +0100
Subject: [PATCH v2 2/4] regulator: lp872x: Add enable GPIO pin support
In-Reply-To: <56BD23ED.8010207@ti.com>
References: <1454697741-8687-1-git-send-email-contact@paulk.fr>
 <1454697741-8687-3-git-send-email-contact@paulk.fr>
 <56BD23ED.8010207@ti.com>
Message-ID: <1455301532.2760.1.camel@collins>

Hi,
Le vendredi 12 f?vrier 2016 ? 09:14 +0900, Kim, Milo a ?crit :
> Thanks for the patch. Please see my comments below.

Thanks for the review!

> On 2/6/2016 3:42 AM, Paul Kocialkowski wrote:
> > LP872x regulators are made active via the EN pin, which might be hooked to a
> > GPIO. This adds support for driving the GPIO high when the driver is in use.
> >
> > Signed-off-by: Paul Kocialkowski <contact at paulk.fr>
> > ---
> >   .../devicetree/bindings/regulator/lp872x.txt       |  1 +
> >   drivers/regulator/lp872x.c                         | 34 ++++++++++++++++++++++
> >   include/linux/regulator/lp872x.h                   |  5 ++++
> >   3 files changed, 40 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/regulator/lp872x.txt b/Documentation/devicetree/bindings/regulator/lp872x.txt
> > index 7818318..ca58a68 100644
> > --- a/Documentation/devicetree/bindings/regulator/lp872x.txt
> > +++ b/Documentation/devicetree/bindings/regulator/lp872x.txt
> > @@ -28,6 +28,7 @@ Optional properties:
> >     - ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x devices.
> >     - ti,dvs-vsel: DVS selector. 0 = SEL_V1, 1 = SEL_V2.
> >     - ti,dvs-state: initial DVS pin state. 0 = DVS_LOW, 1 = DVS_HIGH.
> > +  - enable-gpios: GPIO specifier for EN pin control of LP872x devices.
> >
> >     Sub nodes for regulator_init_data
> >       LP8720 has maximum 6 nodes. (child name: ldo1 ~ 5 and buck)
> > diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
> > index 21c49d8..3899211 100644
> > --- a/drivers/regulator/lp872x.c
> > +++ b/drivers/regulator/lp872x.c
> > @@ -15,6 +15,7 @@
> >   #include <linux/regmap.h>
> >   #include <linux/err.h>
> >   #include <linux/gpio.h>
> > +#include <linux/delay.h>
> >   #include <linux/regulator/lp872x.h>
> >   #include <linux/regulator/driver.h>
> >   #include <linux/platform_device.h>
> > @@ -757,6 +758,33 @@ set_default_dvs_mode:
> >   				default_dvs_mode[lp->chipid]);
> >   }
> >
> > +static int lp872x_hw_enable(struct lp872x *lp)
> > +{
> > +	int ret, gpio;
> > +
> > +	if (!lp->pdata)
> > +		return -EINVAL;
> > +
> > +	gpio = lp->pdata->enable_gpio;
> > +	if (!gpio_is_valid(gpio))
> > +		return 0;
> 
> It seems gpio is always 0 when it starts from DT. 'enable_gpio' is 
> updated in lp872x_config() but lp872x_hw_enable() is called first.

Actually, enable_gpio is updated in lp872x_populate_pdata_from_dt.

> > +
> > +	/* Always set enable GPIO high. */
> > +	ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, "LP872X EN");
> > +	if (ret) {
> > +		dev_err(lp->dev, "gpio request err: %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	/* Each chip has a different enable delay. */
> > +	if (lp->chipid == LP8720)
> > +		usleep_range(LP8720_ENABLE_DELAY, 1.5 * LP8720_ENABLE_DELAY);
> > +	else
> > +		usleep_range(LP8725_ENABLE_DELAY, 1.5 * LP8725_ENABLE_DELAY);
> > +
> > +	return 0;
> > +}
> > +
> >   static int lp872x_config(struct lp872x *lp)
> >   {
> >   	struct lp872x_platform_data *pdata = lp->pdata;
> > @@ -875,6 +903,8 @@ static struct lp872x_platform_data
> >   	of_property_read_u8(np, "ti,dvs-state", &dvs_state);
> >   	pdata->dvs->init_state = dvs_state ? DVS_HIGH : DVS_LOW;
> >
> > +	pdata->enable_gpio = of_get_named_gpio(np, "enable-gpios", 0);
> 
> Please move this code to lp872x_populate_pdata_from_dt().

This already adds it in lp872x_populate_pdata_from_dt (see the context
around the insertion).

I don't know why the diff makes it seem like it's added in
lp872x_config. It's really not.

> lp872x_hw_enable() is called prior to lp872x_config(), so enable_gpio 
> should be set on parsing the DT properties.

Of course.

> > +
> >   	if (of_get_child_count(np) == 0)
> >   		goto out;
> >
> > @@ -948,6 +978,10 @@ static int lp872x_probe(struct i2c_client *cl, const struct i2c_device_id *id)
> >   	lp->chipid = id->driver_data;
> >   	i2c_set_clientdata(cl, lp);
> >
> > +	ret = lp872x_hw_enable(lp);
> > +	if (ret)
> > +		return ret;
> > +
> >   	ret = lp872x_config(lp);
> >   	if (ret)
> >   		return ret;
> > diff --git a/include/linux/regulator/lp872x.h b/include/linux/regulator/lp872x.h
> > index 132e05c..6029279 100644
> > --- a/include/linux/regulator/lp872x.h
> > +++ b/include/linux/regulator/lp872x.h
> > @@ -18,6 +18,9 @@
> >
> >   #define LP872X_MAX_REGULATORS		9
> >
> > +#define LP8720_ENABLE_DELAY		200
> > +#define LP8725_ENABLE_DELAY		30000
> > +
> >   enum lp872x_regulator_id {
> >   	LP8720_ID_BASE,
> >   	LP8720_ID_LDO1 = LP8720_ID_BASE,
> > @@ -79,12 +82,14 @@ struct lp872x_regulator_data {
> >    * @update_config     : if LP872X_GENERAL_CFG register is updated, set true
> >    * @regulator_data    : platform regulator id and init data
> >    * @dvs               : dvs data for buck voltage control
> > + * @enable_gpio       : gpio pin number for enable control
> >    */
> >   struct lp872x_platform_data {
> >   	u8 general_config;
> >   	bool update_config;
> >   	struct lp872x_regulator_data regulator_data[LP872X_MAX_REGULATORS];
> >   	struct lp872x_dvs *dvs;
> > +	int enable_gpio;
> >   };
> >
> >   #endif
> >
> 
> Best regards,
> Milo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/25a0e415/attachment.sig>

From mark.rutland at arm.com  Fri Feb 12 10:25:27 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 12 Feb 2016 18:25:27 +0000
Subject: [PATCH] arm64: mm: Mark .rodata as RO
In-Reply-To: <1455293599-6974-1-git-send-email-jeremy.linton@arm.com>
References: <1455293599-6974-1-git-send-email-jeremy.linton@arm.com>
Message-ID: <20160212182527.GG20262@leverpostej>

On Fri, Feb 12, 2016 at 10:13:19AM -0600, Jeremy Linton wrote:
> Currently the .rodata section is actually still executable when DEBUG_RODATA
> is enabled. This changes that so the .rodata is actually read only, no execute.
> 
> Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
> ---
>  arch/arm64/kernel/vmlinux.lds.S |  5 +++--
>  arch/arm64/mm/mmu.c             | 14 +++++++++++---
>  2 files changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index ab4e436..2e2c053 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -114,8 +114,9 @@ SECTIONS
>  		*(.got)			/* Global offset table		*/
>  	}
>  
> -	RO_DATA(PAGE_SIZE)
> -	EXCEPTION_TABLE(8)
> +	ALIGN_DEBUG_RO_MIN(0)
> +	RO_DATA(PAGE_SIZE)		/* everything from this point to */
> +	EXCEPTION_TABLE(8)		/* _etext will be marked RO NX   */
>  	NOTES
>  
>  	ALIGN_DEBUG_RO_MIN(PAGE_SIZE)
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index ab69a99..a3f4112 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -453,10 +453,18 @@ static void __init map_mem(pgd_t *pgd)
>  #ifdef CONFIG_DEBUG_RODATA
>  void mark_rodata_ro(void)
>  {
> -	create_mapping_late(__pa(_stext), (unsigned long)_stext,
> -				(unsigned long)_etext - (unsigned long)_stext,
> -				PAGE_KERNEL_ROX);
> +	unsigned long section_size;
>  
> +	section_size = (unsigned long)__start_rodata - (unsigned long)_stext;
> +	create_mapping_late(__pa(_stext), (unsigned long)_stext,
> +			    section_size, PAGE_KERNEL_ROX);
> +	/*
> +	 * mark .rodata as read only. Use _etext rather than __end_rodata to
> +	 * cover NOTES and EXCEPTION_TABLE.
> +	 */
> +	section_size = (unsigned long)_etext - (unsigned long)__start_rodata;
> +	create_mapping_late(__pa(__start_rodata), (unsigned long)__start_rodata,
> +			    section_size, PAGE_KERNEL_RO);
>  }

As you pointed out in the other thread, we'll also need to update
map_kernel to use equivalent chunks for .text and .rodata.

I think we can probably make .rodata RO from the outset in map_kernel,
too.

Could you please update mem_init to log .text and .rodata separately?

It looks like some core code makes assumptions about _etext, so I guess
that has to cover .rodata regardless.

Otherwise, looks good!

Thanks,
Mark.


From mathieu.poirier at linaro.org  Fri Feb 12 10:33:17 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Fri, 12 Feb 2016 11:33:17 -0700
Subject: [PATCH V3 1/6] stm class: Add ioctl get_options interface
In-Reply-To: <87ziv62bzb.fsf@ashishki-desk.ger.corp.intel.com>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
 <1454756672-12790-2-git-send-email-zhang.chunyan@linaro.org>
 <87ziv62bzb.fsf@ashishki-desk.ger.corp.intel.com>
Message-ID: <CANLsYkzQTjROVX3K3NEE=GNg6QVKXLA9QDLVDe+W9eeDVwbgGQ@mail.gmail.com>

On 12 February 2016 at 08:18, Alexander Shishkin
<alexander.shishkin at linux.intel.com> wrote:
> Chunyan Zhang <zhang.chunyan at linaro.org> writes:
>
>> There is already an interface of set_options, but no get_options yet.
>> Before setting any options, one would may want to see the current
>> status of that option by means of get_options interface. This
>> interface has been used in CoreSight STM driver.
>
> I'm not sure I understand the reasoning behind this. If a userspace
> program opens a communication channel and wants to configure certain
> features on it, why does its choice depend on what has been configured
> for this channel previously? It can be anything at all. Most likely,
> it's either unconfigured or configured to its default values, but why
> does this matter for a new writer?

A client may wish to change the settings (invariant/guaranteed) it has
on a specific channel - it may even want to so do multiple times.  The
idea behind introducing a get_options() was to probe the specific
settings of a channel before going a head with a new configuration.
In hindsight it may not be needed as a client should simply go ahead
and push down the configuration it wants.

>
> Regards,
> --
> Alex


From wsa at the-dreams.de  Fri Feb 12 10:37:47 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Fri, 12 Feb 2016 19:37:47 +0100
Subject: [PATCH V7 1/6] i2c: qup: Change qup_wait_writeready function to
 use for all timeouts
In-Reply-To: <1453197766-18976-2-git-send-email-sricharan@codeaurora.org>
References: <1453197766-18976-1-git-send-email-sricharan@codeaurora.org>
 <1453197766-18976-2-git-send-email-sricharan@codeaurora.org>
Message-ID: <20160212183747.GB1520@katana>

On Tue, Jan 19, 2016 at 03:32:41PM +0530, Sricharan R wrote:
> qup_wait_writeready waits only on a output fifo empty event.
> Change the same function to accept the event and data length
> to wait as parameters. This way the same function can be used for
> timeouts in other places as well.
> 
> Signed-off-by: Sricharan R <sricharan at codeaurora.org>
> Reviewed-by: Andy Gross <andy.gross at linaro.org>
> Tested-by: Archit Taneja <architt at codeaurora.org>
> Tested-by: Telkar Nagender <ntelkar at codeaurora.org>

Applied to for-next, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/e9441006/attachment-0001.sig>

From wsa at the-dreams.de  Fri Feb 12 10:37:38 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Fri, 12 Feb 2016 19:37:38 +0100
Subject: [PATCH V7 4/6] i2c: qup: Add bam dma capabilities
In-Reply-To: <1453197766-18976-5-git-send-email-sricharan@codeaurora.org>
References: <1453197766-18976-1-git-send-email-sricharan@codeaurora.org>
 <1453197766-18976-5-git-send-email-sricharan@codeaurora.org>
Message-ID: <20160212183737.GA1520@katana>

On Tue, Jan 19, 2016 at 03:32:44PM +0530, Sricharan R wrote:
> QUP cores can be attached to a BAM module, which acts as
> a dma engine for the QUP core. When DMA with BAM is enabled,
> the BAM consumer pipe transmitted data is written to the
> output FIFO and the BAM producer pipe received data is read
> from the input FIFO.
> 
> With BAM capabilities, qup-i2c core can transfer more than
> 256 bytes, without a 'stop' which is not possible otherwise.
> 
> Signed-off-by: Sricharan R <sricharan at codeaurora.org>
> Reviewed-by: Andy Gross <andy.gross at linaro.org>
> Tested-by: Archit Taneja <architt at codeaurora.org>
> Tested-by: Telkar Nagender <ntelkar at codeaurora.org>

My code checkers found some issues:

    SPARSE
drivers/i2c/busses/i2c-qup.c:555:6: warning: symbol 'qup_sg_set_buf' was not declared. Should it be static?
drivers/i2c/busses/i2c-qup.c:1243:50: warning: dubious: !x & !y
    SMATCH
drivers/i2c/busses/i2c-qup.c:165 qup_sg_set_buf warn: unused return: s = sg_next()
drivers/i2c/busses/i2c-qup.c:165 qup_sg_set_buf warn: unused return: s = sg_next()
drivers/i2c/busses/i2c-qup.c:1243 qup_i2c_xfer_v2() warn: add some parenthesis here?
    CPPCHECK
drivers/i2c/busses/i2c-qup.c:1243: style: Boolean result is used in bitwise operation. Clarify expression with parentheses.
    SPATCH
drivers/i2c/busses/i2c-qup.c:1380:2-13: WARNING: Assignment of bool to 0/1
drivers/i2c/busses/i2c-qup.c:1481:1-13: WARNING: Assignment of bool to 0/1
  CC      drivers/i2c/busses/i2c-qup.o
drivers/i2c/busses/i2c-qup.c:555:6: warning: no previous prototype for 'qup_sg_set_buf' [-Wmissing-prototypes]
 void qup_sg_set_buf(struct scatterlist *sg, void *buf, struct qup_i2c_tag *tg,

Can you fix them and resend??

Thanks,

   Wolfram
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/6b685d54/attachment-0001.sig>

From wsa at the-dreams.de  Fri Feb 12 10:37:55 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Fri, 12 Feb 2016 19:37:55 +0100
Subject: [PATCH V7 2/6] i2c: qup: Add V2 tags support
In-Reply-To: <1453197766-18976-3-git-send-email-sricharan@codeaurora.org>
References: <1453197766-18976-1-git-send-email-sricharan@codeaurora.org>
 <1453197766-18976-3-git-send-email-sricharan@codeaurora.org>
Message-ID: <20160212183755.GC1520@katana>

On Tue, Jan 19, 2016 at 03:32:42PM +0530, Sricharan R wrote:
> QUP from version 2.1.1 onwards, supports a new format of
> i2c command tags. Tag codes instructs the controller to
> perform a operation like read/write. This new tagging version
> supports bam dma and transfers of more than 256 bytes without 'stop'
> in between. Adding the support for the same.
> 
> For each block a data_write/read tag and data_len tag is added to
> the output fifo. For the final block of data write_stop/read_stop
> tag is used.
> 
> Signed-off-by: Andy Gross <andy.gross at linaro.org>
> Signed-off-by: Sricharan R <sricharan at codeaurora.org>
> Tested-by: Archit Taneja <architt at codeaurora.org>
> Tested-by: Telkar Nagender <ntelkar at codeaurora.org>

Applied to for-next, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/8c9036f4/attachment.sig>

From wsa at the-dreams.de  Fri Feb 12 10:38:15 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Fri, 12 Feb 2016 19:38:15 +0100
Subject: [PATCH V7 3/6] i2c: qup: Transfer each i2c_msg in i2c_msgs
 without a stop bit
In-Reply-To: <1453197766-18976-4-git-send-email-sricharan@codeaurora.org>
References: <1453197766-18976-1-git-send-email-sricharan@codeaurora.org>
 <1453197766-18976-4-git-send-email-sricharan@codeaurora.org>
Message-ID: <20160212183815.GD1520@katana>

On Tue, Jan 19, 2016 at 03:32:43PM +0530, Sricharan R wrote:
> The definition of i2c_msg says that
> 
> "If this is the last message in a group, it is followed by a STOP.
> Otherwise it is followed by the next @i2c_msg transaction segment,
> beginning with a (repeated) START"
> 
> So the expectation is that there is no 'STOP' bit inbetween individual
> i2c_msg segments with repeated 'START'. The QUP i2c hardware has no way
> to inform that there should not be a 'STOP' at the end of transaction.
> The only way to implement this is to coalesce all the i2c_msg in i2c_msgs
> in to one transaction and transfer them. Adding the support for the same.
> 
> This is required for some clients like touchscreen which keeps
> incrementing counts across individual transfers and 'STOP' bit inbetween
> resets the counter, which is not required.
> 
> This patch adds the support in non-dma mode.
> 
> Signed-off-by: Sricharan R <sricharan at codeaurora.org>
> Reviewed-by: Andy Gross <andy.gross at linaro.org>
> Tested-by: Archit Taneja <architt at codeaurora.org>
> Tested-by: Telkar Nagender <ntelkar at codeaurora.org>

Shortened the commit message and applied to for-next, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/decc30e7/attachment.sig>

From wsa at the-dreams.de  Fri Feb 12 10:42:13 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Fri, 12 Feb 2016 19:42:13 +0100
Subject: [PATCH V7 4/6] i2c: qup: Add bam dma capabilities
In-Reply-To: <20160212183737.GA1520@katana>
References: <1453197766-18976-1-git-send-email-sricharan@codeaurora.org>
 <1453197766-18976-5-git-send-email-sricharan@codeaurora.org>
 <20160212183737.GA1520@katana>
Message-ID: <20160212184212.GE1520@katana>

> Can you fix them and resend??

That should have been only one '?', sorry.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/5d6c78d9/attachment.sig>

From wsa at the-dreams.de  Fri Feb 12 10:43:36 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Fri, 12 Feb 2016 19:43:36 +0100
Subject: [PATCH 2/7] i2c: omap: Fix PM regression with deferred probe for
 pm_runtime_reinit
In-Reply-To: <1455145370-20301-3-git-send-email-tony@atomide.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-3-git-send-email-tony@atomide.com>
Message-ID: <20160212184335.GF1520@katana>

On Wed, Feb 10, 2016 at 03:02:45PM -0800, Tony Lindgren wrote:
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind") introduced pm_runtime_reinit() that is used
> to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
> down the device after a failed probe.
> 
> However, for drivers using pm_runtime_use_autosuspend() this can cause
> a state where suspend callback is never called after -EPROBE_DEFER.
> On the following device driver probe, hardware state is different from
> the PM runtime state causing omap_device to produce the following
> error:
> 
> omap_device_enable() called from invalid state 1
> 
> And with omap_device and omap hardware being picky for PM, this will
> block any deeper idle states in hardware.
> 
> The solution is to fix the drivers to follow the PM runtime documentation:
> 
> 1. For sections of code that needs the device disabled, use
>    pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
>    been set.
> 
> 2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
>    pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
>    set.
> 
> Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
> error and driver unbind")
> Cc: linux-i2c at vger.kernel.org
> Cc: Alan Stern <stern at rowland.harvard.edu>
> Cc: Kevin Hilman <khilman at baylibre.com>
> Cc: Nishanth Menon <nm at ti.com>
> Cc: Rafael J. Wysocki <rafael at kernel.org>
> Cc: Ulf Hansson <ulf.hansson at linaro.org>
> Cc: Tero Kristo <t-kristo at ti.com>
> Cc: Wolfram Sang <wsa at the-dreams.de>
> Signed-off-by: Tony Lindgren <tony at atomide.com>

Applied to for-current, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/d994bb7d/attachment.sig>

From horms at verge.net.au  Fri Feb 12 10:43:43 2016
From: horms at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 19:43:43 +0100
Subject: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
In-Reply-To: <56BE0CB1.4070408@cogentembedded.com>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
 <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
 <874mdhtn7d.wl%kuninori.morimoto.gx@renesas.com>
 <20160210171455.GB17671@verge.net.au>
 <56BE0CB1.4070408@cogentembedded.com>
Message-ID: <20160212184343.GA31655@verge.net.au>

On Fri, Feb 12, 2016 at 07:47:45PM +0300, Sergei Shtylyov wrote:
> On 02/10/2016 08:14 PM, Simon Horman wrote:
> 
> >>Sorry for my un-ordered response
> >>
> >>>Define the generic R8A7794 part of  the sound device node.
> >>>This sound device  is a complex one and comprises the Audio Clock Generator
> >>>(ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
> >>>(SSI[U]), and Audio DMAC-Peripheral-Peripheral.
> >>>It is up  to the board file to enable the device.
> >>>
> >>>This patch is based on the R8A7791 sound work by Kuninori Morimoto.
> >>>
> >>>Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> >>(snip)
> >>>+		rcar_sound,src {
> >>>+			src1: src at 1 {
> >>>+				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
> >>>+				dmas = <&audma0 0x87>, <&audma0 0x9c>;
> >>>+				dma-names = "rx", "tx";
> >>>+			};
> >>>+			src2: src at 2 {
> >>>+				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
> >>>+				dmas = <&audma0 0x89>, <&audma0 0x9e>;
> >>>+				dma-names = "rx", "tx";
> >>>+			};
> >>>+			src3: src at 3 {
> >>>+				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
> >>>+				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
> >>>+				dma-names = "rx", "tx";
> >>>+			};
> >>>+			src4: src at 4 {
> >>>+				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
> >>>+				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
> >>>+				dma-names = "rx", "tx";
> >>>+			};
> >>>+			src5: src at 5 {
> >>>+				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
> >>>+				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
> >>>+				dma-names = "rx", "tx";
> >>>+			};
> >>>+			src6: src at 6 {
> >>>+				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> >>>+				dmas = <&audma0 0x91>, <&audma0 0xb4>;
> >>>+				dma-names = "rx", "tx";
> >>>+			};
> >>>+		};
> >>
> >>I think this can't work correctly, because driver is assuming
> >>DT has all channles (from 0). (see linux/sound/soc/sh/rcar/src.c :: rsnd_src_probe)
> >>Can you adds dummy src0 with some comments ? or fix src.c driver ?
> >
> >I would prefer the driver to be fixed (I had a similar patchset locally
> >and I found it doesn't work).
> 
>    You mean you had R8A7794 sound patch set too?

Yes, I was working on it recently.
I suppose we should coordinate these things in future to avoid
duplicated effort.

> >The reason is that DT should describe
> >the hardware rather than the current state of the software.
> 
>    Yes, of course. Just tell me do I have to fix the driver *before* this
> patch set is accepted?

I did not entirely get to the bottom of the problem, but I think that at
the very least something needs to be done about the for_each_rsnd_src()
loop in rsnd_src_probe.

My, obviously not satisfactory, hack around there being no src0 was as follows.

diff --git a/sound/soc/sh/rcar/src.c b/sound/soc/sh/rcar/src.c
index 68b439ed22d7..58a447b0785b 100644
--- a/sound/soc/sh/rcar/src.c
+++ b/sound/soc/sh/rcar/src.c
@@ -1072,7 +1072,7 @@ int rsnd_src_probe(struct platform_device *pdev,
 
 	for_each_rsnd_src(src, priv, i) {
 		snprintf(name, RSND_SRC_NAME_SIZE, "%s.%d",
-			 SRC_NAME, i);
+			 SRC_NAME, i + 1);
 
 		clk = devm_clk_get(dev, name);
 		if (IS_ERR(clk))



From lkp at intel.com  Fri Feb 12 10:44:16 2016
From: lkp at intel.com (kbuild test robot)
Date: Sat, 13 Feb 2016 02:44:16 +0800
Subject: [PATCH v2 3/9] ACPI: introduce acpi_table_parse2()
In-Reply-To: <1455299022-11641-4-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <201602130210.rOqbMzRs%fengguang.wu@intel.com>

Hi Aleksey,

[auto build test ERROR on pm/linux-next]
[also build test ERROR on v4.5-rc3 next-20160212]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Aleksey-Makarov/ACPI-parse-the-SPCR-table/20160213-015350
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
config: i386-tinyconfig (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/kernel/i8259.o: In function `acpi_table_parse2':
>> i8259.c:(.text+0x2c4): multiple definition of `acpi_table_parse2'
   arch/x86/kernel/setup.o:setup.c:(.text+0x3): first defined here
   arch/x86/kernel/irqinit.o: In function `acpi_table_parse2':
   irqinit.c:(.text+0x0): multiple definition of `acpi_table_parse2'
   arch/x86/kernel/setup.o:setup.c:(.text+0x3): first defined here
   arch/x86/kernel/bootflag.o: In function `acpi_table_parse2':
   bootflag.c:(.text+0x0): multiple definition of `acpi_table_parse2'
   arch/x86/kernel/setup.o:setup.c:(.text+0x3): first defined here
   arch/x86/kernel/e820.o: In function `acpi_table_parse2':
   e820.c:(.text+0x0): multiple definition of `acpi_table_parse2'
   arch/x86/kernel/setup.o:setup.c:(.text+0x3): first defined here
   arch/x86/kernel/pci-dma.o: In function `acpi_table_parse2':
   pci-dma.c:(.text+0x0): multiple definition of `acpi_table_parse2'
   arch/x86/kernel/setup.o:setup.c:(.text+0x3): first defined here
   arch/x86/kernel/rtc.o: In function `acpi_table_parse2':
   rtc.c:(.text+0x43): multiple definition of `acpi_table_parse2'
   arch/x86/kernel/setup.o:setup.c:(.text+0x3): first defined here

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 6205 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160213/0cb21c2c/attachment-0001.obj>

From hdegoede at redhat.com  Fri Feb 12 10:51:13 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Fri, 12 Feb 2016 19:51:13 +0100
Subject: [linux-sunxi] [RFC PATCH 0/4] clk: sunxi: fix DT compatibility
 issues
In-Reply-To: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
References: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
Message-ID: <56BE29A1.3060107@redhat.com>

Hi,

So far I've stayed out of this discussion, but now I feel I have to
weigh in:

There is no need for this series, device-tree compatibility for
sunxi devices is a non issue. No devices ship with dtb files as
part of the bootloader / firmware (the vendor kernels do not
use dtb at all).

So we always are using a dtb from the kernel tree, and both Fedora
and Debian (AFAIK), the 2 distros which ship with more or less official
sunxi support package things so that each kernel version uses the dtb
files compiled from the dts shipped with that exact kernel version,
(through the ftddir directive in extlinux.conf, which is per menu
entry / kernel version) even if multiple kernel versions are installed.

So there is no reason, no reason at all to worry too much about dtb
compatibility for sunxi devices.

As for compatibility with u-boot, u-boot ships with its own embedded
dtb copy, which is based on dts files from the kernel (the u-boot copies
get synced regularly), and even if this dtb were to somehow be replaced
by a new "incompatible" dtb from a newer kernel there would still not
be a problem as u-boot does not (currently) use the clk definitions
from the dtb. Note I'm the u-boot sunxi custodian and I'm fine with
the proposed changes.

TL;DR: NACK for this series.

Regards,

Hans



On 12-02-16 18:59, Andre Przywara wrote:
> Commit f7d372ba54ea ("clk: sunxi: Refactor A31 PLL6 so that it can be
> reused") (in -next) made the A31 PLL6 clock driver more generic, so
> that it can drive the PLL8 clock in newer SoCs too.
> However the patch broke compatibility with older DTs, which this
> series tries to fix.
> The approach chosen here is to bring back the old driver under its
> old name, while letting the new driver using a different name to be
> able to tell them apart.
> The old driver should be somewhat deprecated and not used in new DTs
> anymore.
> The slight disadvantage is that there are now two drivers and two
> compatible names for the same hardware (the PLL6 clock), I am not
> sure if this is frowned upon or can be tolerated since the new driver
> is more generic (drives PLL8 as well) and makes the old one obsolete.
> We just need to keep it for compatibility.
>
> The naming for both the functions and compatible names is probably
> wrong, I am relying on more sunxi - experienced people here to
> suggest better identifiers.
>
> This is only one possible approach to fix this issues, so I am open
> to any kind of discussion.
>
> The series is made on top of Maxime's sunxi/for-next branch, so it
> somehow reverts the change in question. I am happy to rebase it on
> any branch people tell me.
>
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>
> Andre Przywara (4):
>    clk: sunxi: rename new sun6i_a31_pll6 clock to sun6i_a31_pll clock
>    clk: sunxi: re-add old sun6i_a31_pll6 clock
>    clk: sunxi: revert .dtsi changes for DTs with a sun6i_a31_pll6 clock
>    DT: Allwinner H3: fix PLL8 clock
>
>   Documentation/devicetree/bindings/clock/sunxi.txt |  2 +-
>   arch/arm/boot/dts/sun6i-a31.dtsi                  | 36 ++++++++---------
>   arch/arm/boot/dts/sun8i-a23-a33.dtsi              | 25 ++++--------
>   arch/arm/boot/dts/sun8i-a23.dtsi                  |  2 +-
>   arch/arm/boot/dts/sun8i-a33.dtsi                  |  4 +-
>   arch/arm/boot/dts/sun8i-h3.dtsi                   | 31 +++++---------
>   drivers/clk/sunxi/clk-sunxi.c                     | 49 ++++++++++++++++++++---
>   7 files changed, 84 insertions(+), 65 deletions(-)
>


From gregkh at linuxfoundation.org  Fri Feb 12 10:51:30 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 12 Feb 2016 10:51:30 -0800
Subject: [PATCH v2 3/9] ACPI: introduce acpi_table_parse2()
In-Reply-To: <1455299022-11641-4-git-send-email-aleksey.makarov@linaro.org>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
 <1455299022-11641-4-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <20160212185130.GA10095@kroah.com>

On Fri, Feb 12, 2016 at 08:43:34PM +0300, Aleksey Makarov wrote:
> The function acpi_table_parse() has some problems:
> 1 It can be called only from __init code
> 2 It does not pass any data to the handler
> 3 It just throws out the value returned from the handler
> 
> These issues are addressed in this patch

Why not just fix acpi_table_parse(), like you have, and not add a new
API call with a "2" at the end of it.  That seems crazy to try to
maintain that level of apis.

But I'm not the acpi maintainer(s), so it's their call...

good luck,

greg k-h


From gregkh at linuxfoundation.org  Fri Feb 12 10:53:30 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 12 Feb 2016 10:53:30 -0800
Subject: [PATCH v2 4/9] ACPI: parse SPCR and enable matching console
In-Reply-To: <1455299022-11641-5-git-send-email-aleksey.makarov@linaro.org>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
 <1455299022-11641-5-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <20160212185330.GB10095@kroah.com>

On Fri, Feb 12, 2016 at 08:43:35PM +0300, Aleksey Makarov wrote:
> 'ARM Server Base Boot Requiremets' [1] mentions SPCR (Serial Port
> Console Redirection Table) [2] as a mandatory ACPI table that
> specifies the configuration of serial console.
> 
> Parse this table and check if any registered console match the
> description.  If it does, enable that console.
> 
> In the original submission [3] the ACPI devices are traversed to find
> one that has the same address as specified by SPCR. Then while
> registering a serial device it is checked if it has an ACPI companion
> and it is the same device that was found at traversal. If so,
> add_preferred_console() was used to specify the device as preferred.
> The console name and index are known at the time of registration of
> serial device.
> 
> The problem is that SPCR can specify the console not only by the base
> address but also with PCI Device ID/PCI Vendor ID or PCI Bus
> Number/PCI Device Number.  In general, there is no way to get serial
> name and index from the SPCR table.
> 
> To implement that, introduce a new member
> 
>         int (*acpi_match)(struct console *, struct acpi_table_spcr *)
> 
> of struct console.  It allows drivers to check if they provide a
> matching console device.
> 
> [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
> [2] http://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
> [3] https://lkml.kernel.org/g/1441716217-23786-1-git-send-email-leif.lindholm at linaro.org
> 
> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> ---
>  drivers/acpi/Kconfig    |  3 ++
>  drivers/acpi/Makefile   |  1 +
>  drivers/acpi/spcr.c     | 77 +++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/console.h | 12 ++++++++
>  kernel/printk/printk.c  | 22 ++++++++++++--
>  5 files changed, 113 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/acpi/spcr.c
> 
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 65fb483..5611eb6 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -77,6 +77,9 @@ config ACPI_DEBUGGER_USER
>  
>  endif
>  
> +config ACPI_SPCR_TABLE
> +	bool
> +
>  config ACPI_SLEEP
>  	bool
>  	depends on SUSPEND || HIBERNATION
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 346101c..708b143 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -81,6 +81,7 @@ obj-$(CONFIG_ACPI_EC_DEBUGFS)	+= ec_sys.o
>  obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
>  obj-$(CONFIG_ACPI_BGRT)		+= bgrt.o
>  obj-$(CONFIG_ACPI_CPPC_LIB)	+= cppc_acpi.o
> +obj-$(CONFIG_ACPI_SPCR_TABLE)	+= spcr.o
>  obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
>  
>  # processor has its own "processor." module_param namespace
> diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
> new file mode 100644
> index 0000000..0475840
> --- /dev/null
> +++ b/drivers/acpi/spcr.c
> @@ -0,0 +1,77 @@
> +/*
> + * Copyright (c) 2012, Intel Corporation
> + * Copyright (c) 2015, Red Hat, Inc.
> + * Copyright (c) 2015, 2016 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include <linux/acpi.h>
> +#include <linux/console.h>
> +#include <linux/kernel.h>
> +
> +struct spcr_table_handler_match_data {
> +	struct console *console;
> +	char **options;
> +};
> +
> +static int spcr_table_handler_match(struct acpi_table_header *t, void *d)
> +{
> +	struct acpi_table_spcr *table = (struct acpi_table_spcr *)t;
> +	struct spcr_table_handler_match_data *data = d;
> +	int err;
> +
> +	if (table->header.revision < 2)
> +		return -EOPNOTSUPP;
> +
> +	err = data->console->acpi_match(data->console, table);
> +	if (err < 0)
> +		return err;
> +
> +	if (data->options) {
> +		switch (table->baud_rate) {
> +		case 3:
> +			*data->options = "9600";
> +			break;
> +		case 4:
> +			*data->options = "19200";
> +			break;
> +		case 6:
> +			*data->options = "57600";
> +			break;
> +		case 7:
> +			*data->options = "115200";
> +			break;
> +		default:
> +			*data->options = "";
> +			break;
> +		}
> +	}
> +
> +	return err;
> +}
> +
> +/**
> + * acpi_console_match - Check if console matches one specified by SPCR.
> + *
> + * @console:	console to match
> + * @options:	if the console matches, this will return options for the console
> + *		as in kernel command line
> + *
> + * Return: a non-error value if the console matches.
> + */
> +int acpi_console_match(struct console *console, char **options)
> +{
> +	struct spcr_table_handler_match_data d = {
> +		.console = console,
> +		.options = options,
> +	};
> +
> +	if (acpi_disabled || !console->acpi_match || console_set_on_cmdline)
> +		return -ENODEV;
> +
> +	return acpi_table_parse2(ACPI_SIG_SPCR, spcr_table_handler_match, &d);
> +}
> diff --git a/include/linux/console.h b/include/linux/console.h
> index ea731af..dcc2b59 100644
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -15,6 +15,7 @@
>  #define _LINUX_CONSOLE_H_ 1
>  
>  #include <linux/types.h>
> +#include <linux/errno.h>
>  
>  struct vc_data;
>  struct console_font_op;
> @@ -117,6 +118,7 @@ static inline int con_debug_leave(void)
>  #define CON_BRL		(32) /* Used for a braille device */
>  #define CON_EXTENDED	(64) /* Use the extended output format a la /dev/kmsg */
>  
> +struct acpi_table_spcr;
>  struct console {
>  	char	name[16];
>  	void	(*write)(struct console *, const char *, unsigned);
> @@ -125,6 +127,7 @@ struct console {
>  	void	(*unblank)(void);
>  	int	(*setup)(struct console *, char *);
>  	int	(*match)(struct console *, char *name, int idx, char *options);
> +	int	(*acpi_match)(struct console *, struct acpi_table_spcr *);

Are we expected to add a new 'match' callback for every single type of
firmware out there?  I really don't want to see that, isn't there some
other way to do this without having to add this?

Why not just hook into the match callback instead somehow?

thanks,

greg k-h


From gregkh at linuxfoundation.org  Fri Feb 12 10:56:33 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Fri, 12 Feb 2016 10:56:33 -0800
Subject: [PATCH v2 8/9] serial: 8250: add acpi_match
In-Reply-To: <1455299022-11641-9-git-send-email-aleksey.makarov@linaro.org>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
 <1455299022-11641-9-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <20160212185633.GC10095@kroah.com>

On Fri, Feb 12, 2016 at 08:43:39PM +0300, Aleksey Makarov wrote:
> From: Mark Salter <msalter at redhat.com>
> 
> Add an implementation of acpi_match() to the 8250 driver.
> It allows console to check if it matches the console specified by
> ACPI SPCR table.
> 
> Signed-off-by: Mark Salter <msalter at redhat.com>
> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> ---
>  drivers/tty/serial/8250/8250_core.c | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
> index 7775221..059338a 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -40,6 +40,7 @@
>  #ifdef CONFIG_SPARC
>  #include <linux/sunserialcore.h>
>  #endif
> +#include <linux/acpi.h>
>  
>  #include <asm/irq.h>
>  
> @@ -669,12 +670,34 @@ static int univ8250_console_match(struct console *co, char *name, int idx,
>  	return -ENODEV;
>  }
>  
> +static int __init univ8250_console_acpi_match(struct console *co,
> +					      struct acpi_table_spcr *spcr)
> +{
> +	int index = co->index >= 0 ? co->index : 0;
> +	struct uart_port *port = &serial8250_ports[index].port;
> +
> +	if (spcr->interface_type != ACPI_DBG2_16550_SUBSET &&
> +	    spcr->interface_type != ACPI_DBG2_16550_COMPATIBLE)
> +		return -ENODEV;
> +
> +	if (spcr->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY &&
> +	    spcr->serial_port.address == (u64)port->mapbase)
> +		return 0;
> +
> +	if (spcr->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_IO &&
> +	    spcr->serial_port.address == (u64)port->iobase)
> +		return 0;
> +
> +	return -ENODEV;
> +}

Ick, I don't like this, you are doing almost the same thing that
univ8250_console_match does, yet you have to know the internals of the
acpi_table_spcr structure, which is insane (again, do you want to do
this for every firmware type?)

Isn't this something that resources are supposed to handle for us?  What
happened to getting this type of information from the firmware in a
non-firmware-specific way to pass to the drivers?  Please work on that
instead, then you don't have to modify each and every single driver you
want to work with your system, they will all "just work" automagically.

Please redo this series, as it is, I don't like it at all.

thanks,

greg k-h


From mathieu.poirier at linaro.org  Fri Feb 12 11:02:27 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Fri, 12 Feb 2016 12:02:27 -0700
Subject: [PATCH V3 6/6] coresight-stm: adding driver for CoreSight STM
 component
In-Reply-To: <87y4aq2bjj.fsf@ashishki-desk.ger.corp.intel.com>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
 <1454756672-12790-7-git-send-email-zhang.chunyan@linaro.org>
 <87y4aq2bjj.fsf@ashishki-desk.ger.corp.intel.com>
Message-ID: <CANLsYkxTiwbE9WM4yR0hThPopv5ESJM0_B0+Qcay=aiTvaeJ0g@mail.gmail.com>

On 12 February 2016 at 08:28, Alexander Shishkin
<alexander.shishkin at linux.intel.com> wrote:
> Chunyan Zhang <zhang.chunyan at linaro.org> writes:
>
>> +static long stm_generic_set_options(struct stm_data *stm_data,
>> +                                 unsigned int master,
>> +                                 unsigned int channel,
>> +                                 unsigned int nr_chans,
>> +                                 unsigned long options)
>> +{
>> +     struct stm_drvdata *drvdata = container_of(stm_data,
>> +                                                struct stm_drvdata, stm);
>> +     if (!(drvdata && drvdata->enable))
>> +             return -EINVAL;
>> +
>> +     if (channel >= drvdata->numsp)
>> +             return -EINVAL;
>> +
>> +     switch (options) {
>> +     case STM_OPTION_GUARANTEED:
>> +             set_bit(channel, drvdata->chs.guaranteed);
>> +             break;
>> +
>> +     case STM_OPTION_INVARIANT:
>> +             clear_bit(channel, drvdata->chs.guaranteed);
>> +             break;
>
> This is a bad interface. Firstly, neither option is described
> anywhere. Secondly, I'm pretty sure "invariant" does not mean "not
> guaranteed" in english, although this function seems to imply this.

Regardless of the semantic associated to the word "invariant" in the
English language, the documentation characterises a channel configured
in best effort delivery mode as "invariant".  This is also the
opposite of the "guaranteed" mode where packets are guaranteed to be
delivered.  Adding a few comments here is probably a good idea.

>
>> +
>> +     default:
>> +             return -EINVAL;
>> +     }
>> +
>> +     return 0;
>> +}
>> +
>> +static long stm_generic_get_options(struct stm_data *stm_data,
>> +                                 unsigned int master,
>> +                                 unsigned int channel,
>> +                                 unsigned int nr_chans,
>> +                                 u64 *options)
>> +{
>> +     struct stm_drvdata *drvdata = container_of(stm_data,
>> +                                                struct stm_drvdata, stm);
>> +     if (!(drvdata && drvdata->enable))
>> +             return -EINVAL;
>> +
>> +     if (channel >= drvdata->numsp)
>> +             return -EINVAL;
>> +
>> +     switch (*options) {
>> +     case STM_OPTION_GUARANTEED:
>> +             *options = test_bit(channel, drvdata->chs.guaranteed);
>> +             break;
>
> This just doesn't work. @options here is an on-stack variable in
> stm_char_ioctl(), hitherto uninitialized. The get_options ioctl command
> as you implemented it doesn't fetch @options from userspace either, it
> just passes a pointer to it to this callback, expecting that the
> callback will set it so that it can be copy_to_user()ed back to the
> user.

Yes, that was the intended behaviour - to allow user space to see in
what mode channels are configured (guaranteed/invariant).

>
> Then, when we figure this out, there is again the question of what
> should one make of STM_OPTION_{GUARANTEED,INVARIANT} and how do they fit
> into *options.

The interface asks if the channel is configured in "guaranteed" mode.
If not and because there isn't another mode available, it is
automatically in "invariant" mode.

But as I pointed out in my earlier email this may no longer needed.
One has to issue a system call anyway, might as well just go ahead
with the configuration request.

Thanks,
Mathieu

>
> The idea behind set_options ioctl is that the user specifies a bit mask
> of options that he/she wants to set.
>
> [snip]
>
>> +#ifndef __UAPI_CORESIGHT_STM_H_
>> +#define __UAPI_CORESIGHT_STM_H_
>> +
>> +#define STM_FLAG_TIMESTAMPED   BIT(3)
>> +#define STM_FLAG_GUARANTEED    BIT(7)
>> +
>> +enum {
>> +     STM_OPTION_GUARANTEED = 0,
>> +     STM_OPTION_INVARIANT,
>> +};
>
> Each of these guys could also use an explanation.
>
> Regards,
> --
> Alex


From horms+renesas at verge.net.au  Fri Feb 12 11:05:46 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:46 +0100
Subject: [GIT PULL v2] Renesas ARM Based SoC DT Updates for v4.6
Message-ID: <cover.1455303422.git.horms+renesas@verge.net.au>

Hi Olof, Hi Kevin, Hi Arnd,

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


Changes since v1 of this pull-request:
* Drop two non-DT patches


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

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

for you to fetch changes up to c3373b09ba0391bcd9e992b0a2ce52d48d33e47b:

  ARM: dts: silk: Enable SCIF_CLK frequency and pins (2016-02-09 19:43:28 +0100)

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

* Use SCIF and USBHS fallback compatibility strings
* Add Baud Rate Generator (BRG) support for (H)SCIF
* Enable SCIF_CLK frequency and pins
* Use GIC_* defines
* Enable audio on r8a7793/gose
* Enable HDMI vidio out on r8a7793
* Enable i2c on r8a7793/gose
* Enable QSPI on alt
* Enable GPIO keys and leds on gise
* Enable audio on porter
* Enable DU on porter

----------------------------------------------------------------
Geert Uytterhoeven (20):
      ARM: dts: r8a7778: Add SCIF fallback compatibility strings
      ARM: dts: r8a7779: Add SCIF fallback compatibility strings
      ARM: dts: r8a7790: Add SCIF fallback compatibility strings
      ARM: dts: r8a7791: Add SCIF fallback compatibility strings
      ARM: dts: r8a7793: Add SCIF fallback compatibility strings
      ARM: dts: r8a7794: Add SCIF fallback compatibility strings
      ARM: dts: r8a7778: Add BRG support for SCIF
      ARM: dts: r8a7779: Add BRG support for SCIF
      ARM: dts: r8a7790: Add BRG support for (H)SCIF
      ARM: dts: r8a7791: Add BRG support for (H)SCIF
      ARM: dts: r8a7793: Add BRG support for SCIF
      ARM: dts: r8a7794: Add BRG support for (H)SCIF
      ARM: dts: alt: Enable SCIF_CLK frequency and pins
      ARM: dts: bockw: Enable SCIF_CLK frequency and pins
      ARM: dts: gose: Enable SCIF_CLK frequency and pins
      ARM: dts: koelsch: Enable SCIF_CLK frequency and pins
      ARM: dts: lager: Enable SCIF_CLK frequency and pins
      ARM: dts: marzen: Enable SCIF_CLK frequency and pins
      ARM: dts: porter: Enable SCIF_CLK frequency and pins
      ARM: dts: silk: Enable SCIF_CLK frequency and pins

Laurent Pinchart (11):
      ARM: dts: r8a7793: Add I2C master nodes to DT
      ARM: dts: sh73a0: Rename the serial port clock to fck
      ARM: dts: r7s72100: Rename the serial port clock to fck
      ARM: dts: r8a73a4: Rename the serial port clock to fck
      ARM: dts: r8a7740: Rename the serial port clock to fck
      ARM: dts: r8a7778: Rename the serial port clock to fck
      ARM: dts: r8a7779: Rename the serial port clock to fck
      ARM: dts: r8a7790: Rename the serial port clock to fck
      ARM: dts: r8a7791: Rename the serial port clock to fck
      ARM: dts: r8a7793: Rename the serial port clock to fck
      ARM: dts: r8a7794: Rename the serial port clock to fck

Magnus Damm (1):
      ARM: dts: r8a7793: gose: Add HDMI video out support

Sergei Shtylyov (3):
      ARM: dts: porter: add DU DT support
      ARM: dts: silk: add DU DT support
      ARM: dts: porter: add sound support

Simon Horman (33):
      ARM: dts: gose: Add GPIO keys to DT
      ARM: dts: gose: Add GPIO leds to DT
      ARM: dts: alt: Add QSPI device to DT
      ARM: dts: r8a7790: use fallback usbhs compatibility string
      ARM: dts: r8a7791: use fallback usbhs compatibility string
      ARM: dts: r8a7794: use fallback usbhs compatibility string
      ARM: dts: r8a7793: move dmac nodes
      ARM: dts: gose: add i2c2 bus to device tree
      ARM: dts: r8a7790: use GIC_* defines
      ARM: dts: r8a7791: use GIC_* defines
      ARM: dts: r8a7793: use GIC_* defines
      ARM: dts: r8a7794: use GIC_* defines
      ARM: dts: r8a7778: use GIC_* defines
      ARM: dts: r8a7779: use GIC_* defines
      ARM: dts: r8a73a4: use GIC_* defines
      ARM: dts: r8a7740: use GIC_* defines
      ARM: dts: r8a7793: add MSTP10 clocks to device tree
      ARM: dts: r8a7793: add audio clock to device tree
      ARM: dts: r8a7793: add m2 clock to device tree
      ARM: dts: r8a7793: add R-Car sound support to device tree
      ARM: dts: r8a7793: add DVC support to device tree
      ARM: dts: r8a7793: add audio DMAC clocks to device tree
      ARM: dts: r8a7793: add audio DMAC to device tree
      ARM: dts: r8a7793: enable Audio DMAC peri peri via sound driver
      ARM: dts: gose: Enable sound PIO support in device tree
      ARM: dts: gose: enable sound DMA support in device tree
      ARM: dts: gose: enable sound DMA support via BUSIF in device tree
      ARM: dts: gose: enable sound DMA support via SRC in device tree
      ARM: dts: gose: enable sound DMA support via DVC in device tree
      ARM: dts: r8a7793: enable audio DMAC in device tree
      ARM: dts: r7s72100: use GIC_* defines
      ARM: dts: sh73a0: use GIC_* defines
      ARM: dts: emev2: use GIC_* defines

 arch/arm/boot/dts/emev2.dtsi              |  39 +-
 arch/arm/boot/dts/r7s72100.dtsi           | 177 +++----
 arch/arm/boot/dts/r8a73a4.dtsi            | 224 ++++-----
 arch/arm/boot/dts/r8a7740.dtsi            | 161 +++----
 arch/arm/boot/dts/r8a7778-bockw.dts       |  13 +
 arch/arm/boot/dts/r8a7778.dtsi            | 144 +++---
 arch/arm/boot/dts/r8a7779-marzen.dts      |  13 +
 arch/arm/boot/dts/r8a7779.dtsi            | 135 +++---
 arch/arm/boot/dts/r8a7790-lager.dts       |  13 +
 arch/arm/boot/dts/r8a7790.dtsi            | 441 +++++++++--------
 arch/arm/boot/dts/r8a7791-koelsch.dts     |  13 +
 arch/arm/boot/dts/r8a7791-porter.dts      | 165 +++++++
 arch/arm/boot/dts/r8a7791.dtsi            | 514 ++++++++++----------
 arch/arm/boot/dts/r8a7793-gose.dts        | 304 ++++++++++++
 arch/arm/boot/dts/r8a7793.dtsi            | 758 ++++++++++++++++++++++++------
 arch/arm/boot/dts/r8a7794-alt.dts         |  59 +++
 arch/arm/boot/dts/r8a7794-silk.dts        | 122 +++++
 arch/arm/boot/dts/r8a7794.dtsi            | 362 +++++++-------
 arch/arm/boot/dts/sh73a0.dtsi             | 186 ++++----
 include/dt-bindings/clock/r8a7793-clock.h |   2 +
 20 files changed, 2569 insertions(+), 1276 deletions(-)


From horms+renesas at verge.net.au  Fri Feb 12 11:04:51 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:04:51 +0100
Subject: [PATCH 01/68] ARM: dts: gose: Add GPIO keys to DT
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <d7d5974b156e2ef7436483de00ccada5987c9d31.1455303422.git.horms+renesas@verge.net.au>

Instantiate the GPIO keys in the gose device tree.

Based on similar work for the koelsch board by Laurent Pinchart.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Tested-by: Magnus Damm <damm+renesas at opensource.se>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 82 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 82 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index baa59fe84298..ccbc1c66cc6c 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -31,6 +31,88 @@
 		device_type = "memory";
 		reg = <0 0x40000000 0 0x40000000>;
 	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		key-1 {
+		        gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_1>;
+		        label = "SW2-1";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-2 {
+		        gpios = <&gpio5 1 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_2>;
+		        label = "SW2-2";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-3 {
+		        gpios = <&gpio5 2 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_3>;
+		        label = "SW2-3";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-4 {
+		        gpios = <&gpio5 3 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_4>;
+		        label = "SW2-4";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-a {
+		        gpios = <&gpio7 0 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_A>;
+		        label = "SW30";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-b {
+		        gpios = <&gpio7 1 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_B>;
+		        label = "SW31";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-c {
+		        gpios = <&gpio7 2 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_C>;
+		        label = "SW32";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-d {
+		        gpios = <&gpio7 3 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_D>;
+		        label = "SW33";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-e {
+		        gpios = <&gpio7 4 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_E>;
+		        label = "SW34";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-f {
+		        gpios = <&gpio7 5 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_F>;
+		        label = "SW35";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+		key-g {
+		        gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+		        linux,code = <KEY_G>;
+		        label = "SW36";
+		        gpio-key,wakeup;
+		        debounce-interval = <20>;
+		};
+	};
 };
 
 &extal_clk {
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:04:53 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:04:53 +0100
Subject: [PATCH 03/68] ARM: dts: porter: add DU DT support
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <c5af8a4248d3cb01078d2a20df28081dd588b0e3.1455303422.git.horms+renesas@verge.net.au>

From: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

Define  the Porter board dependent part of the DU device node.
Add the device node  for Analog Devices ADV7511W  HDMI transmitter to I2C2
bus and the HDMI connector. Add the necessary subnodes to interconnect  DU
and HDMI devices.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791-porter.dts | 81 ++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
index 6713b1ea732b..fe81fa0e478c 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -78,6 +78,29 @@
 		states = <3300000 1
 			  1800000 0>;
 	};
+
+	hdmi-out {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_con: endpoint {
+				remote-endpoint = <&adv7511_out>;
+			};
+		};
+	};
+
+	x3_clk: x3-clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <148500000>;
+	};
+
+	x16_clk: x16-clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <74250000>;
+	};
 };
 
 &extal_clk {
@@ -139,6 +162,11 @@
 		renesas,groups = "can0_data";
 		renesas,function = "can0";
 	};
+
+	du_pins: du {
+		renesas,groups = "du_rgb888", "du_sync", "du_disp", "du_clk_out_0";
+		renesas,function = "du";
+	};
 };
 
 &scif0 {
@@ -241,6 +269,38 @@
 			};
 		};
 	};
+
+	hdmi at 39 {
+		compatible = "adi,adv7511w";
+		reg = <0x39>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+
+		adi,input-depth = <8>;
+		adi,input-colorspace = "rgb";
+		adi,input-clock = "1x";
+		adi,input-style = <1>;
+		adi,input-justification = "evenly";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				adv7511_in: endpoint {
+					remote-endpoint = <&du_out_rgb>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+				adv7511_out: endpoint {
+					remote-endpoint = <&hdmi_con>;
+				};
+			};
+		};
+	};
 };
 
 &sata0 {
@@ -304,3 +364,24 @@
 
 	status = "okay";
 };
+
+&du {
+	pinctrl-0 = <&du_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	clocks = <&mstp7_clks R8A7791_CLK_DU0>,
+		 <&mstp7_clks R8A7791_CLK_DU1>,
+		 <&mstp7_clks R8A7791_CLK_LVDS0>,
+		 <&x3_clk>, <&x16_clk>;
+	clock-names = "du.0", "du.1", "lvds.0",
+		      "dclkin.0", "dclkin.1";
+
+	ports {
+		port at 1 {
+			endpoint {
+				remote-endpoint = <&adv7511_in>;
+			};
+		};
+	};
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:04:52 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:04:52 +0100
Subject: [PATCH 02/68] ARM: dts: gose: Add GPIO leds to DT
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <3b18d8593d4cb6880c6647c26ccfcd3eb5a849d9.1455303422.git.horms+renesas@verge.net.au>

Instantiate the GPIO leds in the gose device tree.

Based on similar work for the koelsch board by Magnus Damm.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Tested-by: Magnus Damm <damm+renesas at opensource.se>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index ccbc1c66cc6c..90b587c3c736 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -113,6 +113,22 @@
 		        debounce-interval = <20>;
 		};
 	};
+
+	leds {
+		compatible = "gpio-leds";
+		led6 {
+			gpios = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+			label = "LED6";
+		};
+		led7 {
+			gpios = <&gpio2 20 GPIO_ACTIVE_HIGH>;
+			label = "LED7";
+		};
+		led8 {
+			gpios = <&gpio2 21 GPIO_ACTIVE_HIGH>;
+			label = "LED8";
+		};
+	};
 };
 
 &extal_clk {
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:04:54 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:04:54 +0100
Subject: [PATCH 04/68] ARM: dts: r8a7793: Add I2C master nodes to DT
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <7aed17f4450ba6863937797d88dab64088f38ccc.1455303422.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

Instantiate all the 9 I2C controllers in the disabled state.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 135 ++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 132 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index aef9e69d6c26..f9d92de4f65b 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -19,6 +19,15 @@
 	#size-cells = <2>;
 
 	aliases {
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+		i2c4 = &i2c4;
+		i2c5 = &i2c5;
+		i2c6 = &i2c6;
+		i2c7 = &i2c7;
+		i2c8 = &i2c8;
 		spi0 = &qspi;
 	};
 
@@ -230,6 +239,120 @@
 		power-domains = <&cpg_clocks>;
 	};
 
+	/* The memory map in the User's Manual maps the cores to bus numbers */
+	i2c0: i2c at e6508000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,i2c-r8a7793";
+		reg = <0 0xe6508000 0 0x40>;
+		interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp9_clks R8A7793_CLK_I2C0>;
+		power-domains = <&cpg_clocks>;
+		i2c-scl-internal-delay-ns = <6>;
+		status = "disabled";
+	};
+
+	i2c1: i2c at e6518000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,i2c-r8a7793";
+		reg = <0 0xe6518000 0 0x40>;
+		interrupts = <0 288 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp9_clks R8A7793_CLK_I2C1>;
+		power-domains = <&cpg_clocks>;
+		i2c-scl-internal-delay-ns = <6>;
+		status = "disabled";
+	};
+
+	i2c2: i2c at e6530000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,i2c-r8a7793";
+		reg = <0 0xe6530000 0 0x40>;
+		interrupts = <0 286 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp9_clks R8A7793_CLK_I2C2>;
+		power-domains = <&cpg_clocks>;
+		i2c-scl-internal-delay-ns = <6>;
+		status = "disabled";
+	};
+
+	i2c3: i2c at e6540000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,i2c-r8a7793";
+		reg = <0 0xe6540000 0 0x40>;
+		interrupts = <0 290 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp9_clks R8A7793_CLK_I2C3>;
+		power-domains = <&cpg_clocks>;
+		i2c-scl-internal-delay-ns = <6>;
+		status = "disabled";
+	};
+
+	i2c4: i2c at e6520000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,i2c-r8a7793";
+		reg = <0 0xe6520000 0 0x40>;
+		interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp9_clks R8A7793_CLK_I2C4>;
+		power-domains = <&cpg_clocks>;
+		i2c-scl-internal-delay-ns = <6>;
+		status = "disabled";
+	};
+
+	i2c5: i2c at e6528000 {
+		/* doesn't need pinmux */
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,i2c-r8a7793";
+		reg = <0 0xe6528000 0 0x40>;
+		interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp9_clks R8A7793_CLK_I2C5>;
+		power-domains = <&cpg_clocks>;
+		i2c-scl-internal-delay-ns = <110>;
+		status = "disabled";
+	};
+
+	i2c6: i2c at e60b0000 {
+		/* doesn't need pinmux */
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
+		reg = <0 0xe60b0000 0 0x425>;
+		interrupts = <0 173 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp9_clks R8A7793_CLK_IICDVFS>;
+		dmas = <&dmac0 0x77>, <&dmac0 0x78>;
+		dma-names = "tx", "rx";
+		power-domains = <&cpg_clocks>;
+		status = "disabled";
+	};
+
+	i2c7: i2c at e6500000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
+		reg = <0 0xe6500000 0 0x425>;
+		interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp3_clks R8A7793_CLK_IIC0>;
+		dmas = <&dmac0 0x61>, <&dmac0 0x62>;
+		dma-names = "tx", "rx";
+		power-domains = <&cpg_clocks>;
+		status = "disabled";
+	};
+
+	i2c8: i2c at e6510000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
+		reg = <0 0xe6510000 0 0x425>;
+		interrupts = <0 175 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp3_clks R8A7793_CLK_IIC1>;
+		dmas = <&dmac0 0x65>, <&dmac0 0x66>;
+		dma-names = "tx", "rx";
+		power-domains = <&cpg_clocks>;
+		status = "disabled";
+	};
+
 	pfc: pfc at e6060000 {
 		compatible = "renesas,pfc-r8a7793";
 		reg = <0 0xe6060000 0 0x250>;
@@ -820,19 +943,25 @@
 			reg = <0 0xe6150994 0 4>, <0 0xe61509a4 0 4>;
 			clocks = <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>,
 				 <&cp_clk>, <&cp_clk>, <&cp_clk>, <&cp_clk>,
-				 <&cpg_clocks R8A7793_CLK_QSPI>;
+				 <&cpg_clocks R8A7793_CLK_QSPI>, <&hp_clk>,
+				 <&cp_clk>, <&hp_clk>, <&hp_clk>, <&hp_clk>,
+				 <&hp_clk>, <&hp_clk>;
 			#clock-cells = <1>;
 			clock-indices = <
 				R8A7793_CLK_GPIO7 R8A7793_CLK_GPIO6
 				R8A7793_CLK_GPIO5 R8A7793_CLK_GPIO4
 				R8A7793_CLK_GPIO3 R8A7793_CLK_GPIO2
 				R8A7793_CLK_GPIO1 R8A7793_CLK_GPIO0
-				R8A7793_CLK_QSPI_MOD
+				R8A7793_CLK_QSPI_MOD R8A7793_CLK_I2C5
+				R8A7793_CLK_IICDVFS R8A7793_CLK_I2C4
+				R8A7793_CLK_I2C3 R8A7793_CLK_I2C2
+				R8A7793_CLK_I2C1 R8A7793_CLK_I2C0
 			>;
 			clock-output-names =
 				"gpio7", "gpio6", "gpio5", "gpio4",
 				"gpio3", "gpio2", "gpio1", "gpio0",
-				"qspi_mod";
+				"qspi_mod", "i2c5", "i2c6", "i2c4",
+				"i2c3", "i2c2", "i2c1", "i2c0";
 		};
 		mstp11_clks: mstp11_clks at e615099c {
 			compatible = "renesas,r8a7793-mstp-clocks", "renesas,cpg-mstp-clocks";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:04:55 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:04:55 +0100
Subject: [PATCH 05/68] ARM: dts: alt: Add QSPI device to DT
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <6b78e6ae688b09aa75376537bcfa990c9d4eff07.1455303422.git.horms+renesas@verge.net.au>

Enable the QSPI controller in the alt device tree.

Based similar work for the silk board by by Vladimir Barinov and
Sergei Shtylyov.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7794-alt.dts | 46 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
index 2394e4883786..773f304d1142 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -138,6 +138,13 @@
 	status = "okay";
 };
 
+&pfc {
+	qspi_pins: spi0 {
+		renesas,groups = "qspi_ctrl", "qspi_data4";
+		renesas,function = "qspi";
+	};
+};
+
 &ether {
 	pinctrl-0 = <&ether_pins &phy1_pins>;
 	pinctrl-names = "default";
@@ -197,3 +204,42 @@
 
 	status = "okay";
 };
+
+&qspi {
+	pinctrl-0 = <&qspi_pins>;
+	pinctrl-names = "default";
+
+	status = "okay";
+
+	flash at 0 {
+		compatible = "spansion,s25fl512s", "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <30000000>;
+		spi-tx-bus-width = <4>;
+		spi-rx-bus-width = <4>;
+		spi-cpol;
+		spi-cpha;
+		m25p,fast-read;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition at 0 {
+				label = "loader";
+				reg = <0x00000000 0x00040000>;
+				read-only;
+			};
+			partition at 40000 {
+				label = "system";
+				reg = <0x00040000 0x00040000>;
+				read-only;
+			};
+			partition at 80000 {
+				label = "user";
+				reg = <0x00080000 0x03f80000>;
+			};
+		};
+	};
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:04:57 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:04:57 +0100
Subject: [PATCH 07/68] ARM: dts: r8a7791: use fallback usbhs compatibility
 string
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <8cf1d454b24961223fc3e8d26808d4f72b484a1b.1455303422.git.horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7791 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7791.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 2a369ddcb6fd..829224d2a3ed 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -822,7 +822,7 @@
 	};
 
 	hsusb: usb at e6590000 {
-		compatible = "renesas,usbhs-r8a7791";
+		compatible = "renesas,usbhs-r8a7791", "renesas,rcar-gen2-usbhs";
 		reg = <0 0xe6590000 0 0x100>;
 		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSUSB>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:04:56 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:04:56 +0100
Subject: [PATCH 06/68] ARM: dts: r8a7790: use fallback usbhs compatibility
 string
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <d87ec94aee6dc62ed5db4cad7dba47006c0dd00e.1455303422.git.horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7790 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7790.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 7dfd393bfc7e..4d9af0f46fab 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -746,7 +746,7 @@
 	};
 
 	hsusb: usb at e6590000 {
-		compatible = "renesas,usbhs-r8a7790";
+		compatible = "renesas,usbhs-r8a7790", "renesas,rcar-gen2-usbhs";
 		reg = <0 0xe6590000 0 0x100>;
 		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:00 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:00 +0100
Subject: [PATCH 10/68] ARM: dts: gose: add i2c2 bus to device tree
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <f6890af3ad2b6440d287c8ee97b3f38e18b0674e.1455303422.git.horms+renesas@verge.net.au>

Activate i2c2 bus in r8a7793/gose device tree.

Based on similar work for the r8a7791/koelsch by Wolfram Sang.

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Acked-by: Wolfram Sang <wsa+renesas at sang-engineering.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 90b587c3c736..987ed03b1e02 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -136,6 +136,11 @@
 };
 
 &pfc {
+	i2c2_pins: i2c2 {
+		renesas,groups = "i2c2";
+		renesas,function = "i2c2";
+	};
+
 	scif0_pins: serial0 {
 		renesas,groups = "scif0_data_d";
 		renesas,function = "scif0";
@@ -234,3 +239,17 @@
 		};
 	};
 };
+
+&i2c2 {
+	pinctrl-0 = <&i2c2_pins>;
+	pinctrl-names = "default";
+
+	status = "okay";
+	clock-frequency = <100000>;
+
+	eeprom at 50 {
+		compatible = "renesas,r1ex24002", "atmel,24c02";
+		reg = <0x50>;
+		pagesize = <16>;
+	};
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:03 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:03 +0100
Subject: [PATCH 13/68] ARM: dts: silk: add DU DT support
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <84e734f497cd48f60c16c400d14b8da08cd281dc.1455303422.git.horms+renesas@verge.net.au>

From: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

Define  the SILK board dependent part of the DU device node.
Add the device nodes for the Analog Devices ADV7511W HDMI transmitter
(connected to DU0) and ADV7123  video DAC (connected to DU1). Add the
necessary subnodes to interconnect DU, HDMI/VDAC devices, and HDMI/VGA
connectors.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794-silk.dts | 109 +++++++++++++++++++++++++++++++++++++
 1 file changed, 109 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
index 5153e3af25d9..98b8bcca84da 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -64,6 +64,61 @@
 		states = <3300000 1
 			  1800000 0>;
 	};
+
+	vga-encoder {
+		compatible = "adi,adv7123";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				adv7123_in: endpoint {
+					remote-endpoint = <&du_out_rgb1>;
+				};
+			};
+			port at 1 {
+				reg = <1>;
+				adv7123_out: endpoint {
+					remote-endpoint = <&vga_in>;
+				};
+			};
+		};
+	};
+
+	hdmi-out {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_con: endpoint {
+				remote-endpoint = <&adv7511_out>;
+			};
+		};
+	};
+
+	vga {
+		compatible = "vga-connector";
+
+		port {
+			vga_in: endpoint {
+				remote-endpoint = <&adv7123_out>;
+			};
+		};
+	};
+
+	x2_clk: x2-clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <148500000>;
+	};
+
+	x3_clk: x3-clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <74250000>;
+	};
 };
 
 &extal_clk {
@@ -164,6 +219,38 @@
 			};
 		};
 	};
+
+	hdmi at 39 {
+		compatible = "adi,adv7511w";
+		reg = <0x39>;
+		interrupt-parent = <&gpio5>;
+		interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
+
+		adi,input-depth = <8>;
+		adi,input-colorspace = "rgb";
+		adi,input-clock = "1x";
+		adi,input-style = <1>;
+		adi,input-justification = "evenly";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				adv7511_in: endpoint {
+					remote-endpoint = <&du_out_rgb0>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+				adv7511_out: endpoint {
+					remote-endpoint = <&hdmi_con>;
+				};
+			};
+		};
+	};
 };
 
 &mmcif0 {
@@ -258,3 +345,25 @@
 &usbphy {
 	status = "okay";
 };
+
+&du {
+	status = "okay";
+
+	clocks = <&mstp7_clks R8A7794_CLK_DU0>,
+		 <&mstp7_clks R8A7794_CLK_DU0>,
+		 <&x2_clk>, <&x3_clk>;
+	clock-names = "du.0", "du.1", "dclkin.0", "dclkin.1";
+
+	ports {
+		port at 0 {
+			endpoint {
+				remote-endpoint = <&adv7511_in>;
+			};
+		};
+		port at 1 {
+			endpoint {
+				remote-endpoint = <&adv7123_in>;
+			};
+		};
+	};
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:04:58 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:04:58 +0100
Subject: [PATCH 08/68] ARM: dts: r8a7794: use fallback usbhs compatibility
 string
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <1472ffa81a9089af6250e299068f9a877369333f.1455303422.git.horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7794 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7794.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 6c78f1fae90f..f8cd3a0beebf 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -724,7 +724,7 @@
 	};
 
 	hsusb: usb at e6590000 {
-		compatible = "renesas,usbhs-r8a7794";
+		compatible = "renesas,usbhs-r8a7794", "renesas,rcar-gen2-usbhs";
 		reg = <0 0xe6590000 0 0x100>;
 		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSUSB>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:04:59 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:04:59 +0100
Subject: [PATCH 09/68] ARM: dts: r8a7793: move dmac nodes
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <cefe5a56d3ffcdad0c63dda37f90845f42518e0a.1455303422.git.horms+renesas@verge.net.au>

Move dmac nodes in the r8a7793 device tree to match their location
in the r8a7791 device tree to aid comparison between the device
trees of these similar SoCs.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 124 ++++++++++++++++++++---------------------
 1 file changed, 62 insertions(+), 62 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index f9d92de4f65b..0ce7cc420c9d 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -239,6 +239,68 @@
 		power-domains = <&cpg_clocks>;
 	};
 
+	dmac0: dma-controller at e6700000 {
+		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
+		reg = <0 0xe6700000 0 0x20000>;
+		interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH
+			      0 200 IRQ_TYPE_LEVEL_HIGH
+			      0 201 IRQ_TYPE_LEVEL_HIGH
+			      0 202 IRQ_TYPE_LEVEL_HIGH
+			      0 203 IRQ_TYPE_LEVEL_HIGH
+			      0 204 IRQ_TYPE_LEVEL_HIGH
+			      0 205 IRQ_TYPE_LEVEL_HIGH
+			      0 206 IRQ_TYPE_LEVEL_HIGH
+			      0 207 IRQ_TYPE_LEVEL_HIGH
+			      0 208 IRQ_TYPE_LEVEL_HIGH
+			      0 209 IRQ_TYPE_LEVEL_HIGH
+			      0 210 IRQ_TYPE_LEVEL_HIGH
+			      0 211 IRQ_TYPE_LEVEL_HIGH
+			      0 212 IRQ_TYPE_LEVEL_HIGH
+			      0 213 IRQ_TYPE_LEVEL_HIGH
+			      0 214 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "error",
+				"ch0", "ch1", "ch2", "ch3",
+				"ch4", "ch5", "ch6", "ch7",
+				"ch8", "ch9", "ch10", "ch11",
+				"ch12", "ch13", "ch14";
+		clocks = <&mstp2_clks R8A7793_CLK_SYS_DMAC0>;
+		clock-names = "fck";
+		power-domains = <&cpg_clocks>;
+		#dma-cells = <1>;
+		dma-channels = <15>;
+	};
+
+	dmac1: dma-controller at e6720000 {
+		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
+		reg = <0 0xe6720000 0 0x20000>;
+		interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
+			      0 216 IRQ_TYPE_LEVEL_HIGH
+			      0 217 IRQ_TYPE_LEVEL_HIGH
+			      0 218 IRQ_TYPE_LEVEL_HIGH
+			      0 219 IRQ_TYPE_LEVEL_HIGH
+			      0 308 IRQ_TYPE_LEVEL_HIGH
+			      0 309 IRQ_TYPE_LEVEL_HIGH
+			      0 310 IRQ_TYPE_LEVEL_HIGH
+			      0 311 IRQ_TYPE_LEVEL_HIGH
+			      0 312 IRQ_TYPE_LEVEL_HIGH
+			      0 313 IRQ_TYPE_LEVEL_HIGH
+			      0 314 IRQ_TYPE_LEVEL_HIGH
+			      0 315 IRQ_TYPE_LEVEL_HIGH
+			      0 316 IRQ_TYPE_LEVEL_HIGH
+			      0 317 IRQ_TYPE_LEVEL_HIGH
+			      0 318 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "error",
+				"ch0", "ch1", "ch2", "ch3",
+				"ch4", "ch5", "ch6", "ch7",
+				"ch8", "ch9", "ch10", "ch11",
+				"ch12", "ch13", "ch14";
+		clocks = <&mstp2_clks R8A7793_CLK_SYS_DMAC1>;
+		clock-names = "fck";
+		power-domains = <&cpg_clocks>;
+		#dma-cells = <1>;
+		dma-channels = <15>;
+	};
+
 	/* The memory map in the User's Manual maps the cores to bus numbers */
 	i2c0: i2c at e6508000 {
 		#address-cells = <1>;
@@ -358,68 +420,6 @@
 		reg = <0 0xe6060000 0 0x250>;
 	};
 
-	dmac0: dma-controller at e6700000 {
-		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
-		reg = <0 0xe6700000 0 0x20000>;
-		interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH
-			      0 200 IRQ_TYPE_LEVEL_HIGH
-			      0 201 IRQ_TYPE_LEVEL_HIGH
-			      0 202 IRQ_TYPE_LEVEL_HIGH
-			      0 203 IRQ_TYPE_LEVEL_HIGH
-			      0 204 IRQ_TYPE_LEVEL_HIGH
-			      0 205 IRQ_TYPE_LEVEL_HIGH
-			      0 206 IRQ_TYPE_LEVEL_HIGH
-			      0 207 IRQ_TYPE_LEVEL_HIGH
-			      0 208 IRQ_TYPE_LEVEL_HIGH
-			      0 209 IRQ_TYPE_LEVEL_HIGH
-			      0 210 IRQ_TYPE_LEVEL_HIGH
-			      0 211 IRQ_TYPE_LEVEL_HIGH
-			      0 212 IRQ_TYPE_LEVEL_HIGH
-			      0 213 IRQ_TYPE_LEVEL_HIGH
-			      0 214 IRQ_TYPE_LEVEL_HIGH>;
-		interrupt-names = "error",
-				"ch0", "ch1", "ch2", "ch3",
-				"ch4", "ch5", "ch6", "ch7",
-				"ch8", "ch9", "ch10", "ch11",
-				"ch12", "ch13", "ch14";
-		clocks = <&mstp2_clks R8A7793_CLK_SYS_DMAC0>;
-		clock-names = "fck";
-		power-domains = <&cpg_clocks>;
-		#dma-cells = <1>;
-		dma-channels = <15>;
-	};
-
-	dmac1: dma-controller at e6720000 {
-		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
-		reg = <0 0xe6720000 0 0x20000>;
-		interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
-			      0 216 IRQ_TYPE_LEVEL_HIGH
-			      0 217 IRQ_TYPE_LEVEL_HIGH
-			      0 218 IRQ_TYPE_LEVEL_HIGH
-			      0 219 IRQ_TYPE_LEVEL_HIGH
-			      0 308 IRQ_TYPE_LEVEL_HIGH
-			      0 309 IRQ_TYPE_LEVEL_HIGH
-			      0 310 IRQ_TYPE_LEVEL_HIGH
-			      0 311 IRQ_TYPE_LEVEL_HIGH
-			      0 312 IRQ_TYPE_LEVEL_HIGH
-			      0 313 IRQ_TYPE_LEVEL_HIGH
-			      0 314 IRQ_TYPE_LEVEL_HIGH
-			      0 315 IRQ_TYPE_LEVEL_HIGH
-			      0 316 IRQ_TYPE_LEVEL_HIGH
-			      0 317 IRQ_TYPE_LEVEL_HIGH
-			      0 318 IRQ_TYPE_LEVEL_HIGH>;
-		interrupt-names = "error",
-				"ch0", "ch1", "ch2", "ch3",
-				"ch4", "ch5", "ch6", "ch7",
-				"ch8", "ch9", "ch10", "ch11",
-				"ch12", "ch13", "ch14";
-		clocks = <&mstp2_clks R8A7793_CLK_SYS_DMAC1>;
-		clock-names = "fck";
-		power-domains = <&cpg_clocks>;
-		#dma-cells = <1>;
-		dma-channels = <15>;
-	};
-
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:02 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:02 +0100
Subject: [PATCH 12/68] ARM: dts: r8a7791: use GIC_* defines
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <386a9291134b55493b2af2bc1317eeeb05f8a49a.1455303422.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7791 device tree.

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791.dtsi | 386 ++++++++++++++++++++---------------------
 1 file changed, 193 insertions(+), 193 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 829224d2a3ed..6b3b02c0c58a 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -78,13 +78,13 @@
 			<0 0xf1002000 0 0x1000>,
 			<0 0xf1004000 0 0x2000>,
 			<0 0xf1006000 0 0x2000>;
-		interrupts = <1 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
 	};
 
 	gpio0: gpio at e6050000 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6050000 0 0x50>;
-		interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 0 32>;
@@ -97,7 +97,7 @@
 	gpio1: gpio at e6051000 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6051000 0 0x50>;
-		interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 32 26>;
@@ -110,7 +110,7 @@
 	gpio2: gpio at e6052000 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6052000 0 0x50>;
-		interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 64 32>;
@@ -123,7 +123,7 @@
 	gpio3: gpio at e6053000 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6053000 0 0x50>;
-		interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 96 32>;
@@ -136,7 +136,7 @@
 	gpio4: gpio at e6054000 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6054000 0 0x50>;
-		interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 128 32>;
@@ -149,7 +149,7 @@
 	gpio5: gpio at e6055000 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6055000 0 0x50>;
-		interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 160 32>;
@@ -162,7 +162,7 @@
 	gpio6: gpio at e6055400 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6055400 0 0x50>;
-		interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 192 32>;
@@ -175,7 +175,7 @@
 	gpio7: gpio at e6055800 {
 		compatible = "renesas,gpio-r8a7791", "renesas,gpio-rcar";
 		reg = <0 0xe6055800 0 0x50>;
-		interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 224 26>;
@@ -188,24 +188,24 @@
 	thermal at e61f0000 {
 		compatible = "renesas,thermal-r8a7791", "renesas,rcar-thermal";
 		reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
-		interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks R8A7791_CLK_THERMAL>;
 		power-domains = <&cpg_clocks>;
 	};
 
 	timer {
 		compatible = "arm,armv7-timer";
-		interrupts = <1 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
 	};
 
 	cmt0: timer at ffca0000 {
 		compatible = "renesas,cmt-48-r8a7791", "renesas,cmt-48-gen2";
 		reg = <0 0xffca0000 0 0x1004>;
-		interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 143 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7791_CLK_CMT0>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -218,14 +218,14 @@
 	cmt1: timer at e6130000 {
 		compatible = "renesas,cmt-48-r8a7791", "renesas,cmt-48-gen2";
 		reg = <0 0xe6130000 0 0x1004>;
-		interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 121 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 122 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 123 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 124 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 125 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 126 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 127 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_CMT1>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -240,16 +240,16 @@
 		#interrupt-cells = <2>;
 		interrupt-controller;
 		reg = <0 0xe61c0000 0 0x200>;
-		interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 1 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 2 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 3 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 12 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 13 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 14 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 15 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 16 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 17 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A7791_CLK_IRQC>;
 		power-domains = <&cpg_clocks>;
 	};
@@ -257,22 +257,22 @@
 	dmac0: dma-controller at e6700000 {
 		compatible = "renesas,dmac-r8a7791", "renesas,rcar-dmac";
 		reg = <0 0xe6700000 0 0x20000>;
-		interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH
-			      0 200 IRQ_TYPE_LEVEL_HIGH
-			      0 201 IRQ_TYPE_LEVEL_HIGH
-			      0 202 IRQ_TYPE_LEVEL_HIGH
-			      0 203 IRQ_TYPE_LEVEL_HIGH
-			      0 204 IRQ_TYPE_LEVEL_HIGH
-			      0 205 IRQ_TYPE_LEVEL_HIGH
-			      0 206 IRQ_TYPE_LEVEL_HIGH
-			      0 207 IRQ_TYPE_LEVEL_HIGH
-			      0 208 IRQ_TYPE_LEVEL_HIGH
-			      0 209 IRQ_TYPE_LEVEL_HIGH
-			      0 210 IRQ_TYPE_LEVEL_HIGH
-			      0 211 IRQ_TYPE_LEVEL_HIGH
-			      0 212 IRQ_TYPE_LEVEL_HIGH
-			      0 213 IRQ_TYPE_LEVEL_HIGH
-			      0 214 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -288,22 +288,22 @@
 	dmac1: dma-controller at e6720000 {
 		compatible = "renesas,dmac-r8a7791", "renesas,rcar-dmac";
 		reg = <0 0xe6720000 0 0x20000>;
-		interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
-			      0 216 IRQ_TYPE_LEVEL_HIGH
-			      0 217 IRQ_TYPE_LEVEL_HIGH
-			      0 218 IRQ_TYPE_LEVEL_HIGH
-			      0 219 IRQ_TYPE_LEVEL_HIGH
-			      0 308 IRQ_TYPE_LEVEL_HIGH
-			      0 309 IRQ_TYPE_LEVEL_HIGH
-			      0 310 IRQ_TYPE_LEVEL_HIGH
-			      0 311 IRQ_TYPE_LEVEL_HIGH
-			      0 312 IRQ_TYPE_LEVEL_HIGH
-			      0 313 IRQ_TYPE_LEVEL_HIGH
-			      0 314 IRQ_TYPE_LEVEL_HIGH
-			      0 315 IRQ_TYPE_LEVEL_HIGH
-			      0 316 IRQ_TYPE_LEVEL_HIGH
-			      0 317 IRQ_TYPE_LEVEL_HIGH
-			      0 318 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -319,20 +319,20 @@
 	audma0: dma-controller at ec700000 {
 		compatible = "renesas,dmac-r8a7791", "renesas,rcar-dmac";
 		reg = <0 0xec700000 0 0x10000>;
-		interrupts =	<0 346 IRQ_TYPE_LEVEL_HIGH
-				 0 320 IRQ_TYPE_LEVEL_HIGH
-				 0 321 IRQ_TYPE_LEVEL_HIGH
-				 0 322 IRQ_TYPE_LEVEL_HIGH
-				 0 323 IRQ_TYPE_LEVEL_HIGH
-				 0 324 IRQ_TYPE_LEVEL_HIGH
-				 0 325 IRQ_TYPE_LEVEL_HIGH
-				 0 326 IRQ_TYPE_LEVEL_HIGH
-				 0 327 IRQ_TYPE_LEVEL_HIGH
-				 0 328 IRQ_TYPE_LEVEL_HIGH
-				 0 329 IRQ_TYPE_LEVEL_HIGH
-				 0 330 IRQ_TYPE_LEVEL_HIGH
-				 0 331 IRQ_TYPE_LEVEL_HIGH
-				 0 332 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts =	<GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -348,20 +348,20 @@
 	audma1: dma-controller at ec720000 {
 		compatible = "renesas,dmac-r8a7791", "renesas,rcar-dmac";
 		reg = <0 0xec720000 0 0x10000>;
-		interrupts =	<0 347 IRQ_TYPE_LEVEL_HIGH
-				 0 333 IRQ_TYPE_LEVEL_HIGH
-				 0 334 IRQ_TYPE_LEVEL_HIGH
-				 0 335 IRQ_TYPE_LEVEL_HIGH
-				 0 336 IRQ_TYPE_LEVEL_HIGH
-				 0 337 IRQ_TYPE_LEVEL_HIGH
-				 0 338 IRQ_TYPE_LEVEL_HIGH
-				 0 339 IRQ_TYPE_LEVEL_HIGH
-				 0 340 IRQ_TYPE_LEVEL_HIGH
-				 0 341 IRQ_TYPE_LEVEL_HIGH
-				 0 342 IRQ_TYPE_LEVEL_HIGH
-				 0 343 IRQ_TYPE_LEVEL_HIGH
-				 0 344 IRQ_TYPE_LEVEL_HIGH
-				 0 345 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts =	<GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -377,8 +377,8 @@
 	usb_dmac0: dma-controller at e65a0000 {
 		compatible = "renesas,r8a7791-usb-dmac", "renesas,usb-dmac";
 		reg = <0 0xe65a0000 0 0x100>;
-		interrupts = <0 109 IRQ_TYPE_LEVEL_HIGH
-			      0 109 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "ch0", "ch1";
 		clocks = <&mstp3_clks R8A7791_CLK_USBDMAC0>;
 		power-domains = <&cpg_clocks>;
@@ -389,8 +389,8 @@
 	usb_dmac1: dma-controller at e65b0000 {
 		compatible = "renesas,r8a7791-usb-dmac", "renesas,usb-dmac";
 		reg = <0 0xe65b0000 0 0x100>;
-		interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH
-			      0 110 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "ch0", "ch1";
 		clocks = <&mstp3_clks R8A7791_CLK_USBDMAC1>;
 		power-domains = <&cpg_clocks>;
@@ -404,7 +404,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7791";
 		reg = <0 0xe6508000 0 0x40>;
-		interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -416,7 +416,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7791";
 		reg = <0 0xe6518000 0 0x40>;
-		interrupts = <0 288 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_I2C1>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -428,7 +428,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7791";
 		reg = <0 0xe6530000 0 0x40>;
-		interrupts = <0 286 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_I2C2>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -440,7 +440,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7791";
 		reg = <0 0xe6540000 0 0x40>;
-		interrupts = <0 290 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_I2C3>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -452,7 +452,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7791";
 		reg = <0 0xe6520000 0 0x40>;
-		interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_I2C4>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -465,7 +465,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7791";
 		reg = <0 0xe6528000 0 0x40>;
-		interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_I2C5>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <110>;
@@ -478,7 +478,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7791", "renesas,rmobile-iic";
 		reg = <0 0xe60b0000 0 0x425>;
-		interrupts = <0 173 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_IICDVFS>;
 		dmas = <&dmac0 0x77>, <&dmac0 0x78>;
 		dma-names = "tx", "rx";
@@ -491,7 +491,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7791", "renesas,rmobile-iic";
 		reg = <0 0xe6500000 0 0x425>;
-		interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_IIC0>;
 		dmas = <&dmac0 0x61>, <&dmac0 0x62>;
 		dma-names = "tx", "rx";
@@ -504,7 +504,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7791", "renesas,rmobile-iic";
 		reg = <0 0xe6510000 0 0x425>;
-		interrupts = <0 175 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_IIC1>;
 		dmas = <&dmac0 0x65>, <&dmac0 0x66>;
 		dma-names = "tx", "rx";
@@ -520,7 +520,7 @@
 	mmcif0: mmc at ee200000 {
 		compatible = "renesas,mmcif-r8a7791", "renesas,sh-mmcif";
 		reg = <0 0xee200000 0 0x80>;
-		interrupts = <0 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_MMCIF0>;
 		dmas = <&dmac0 0xd1>, <&dmac0 0xd2>;
 		dma-names = "tx", "rx";
@@ -533,7 +533,7 @@
 	sdhi0: sd at ee100000 {
 		compatible = "renesas,sdhi-r8a7791";
 		reg = <0 0xee100000 0 0x328>;
-		interrupts = <0 165 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_SDHI0>;
 		dmas = <&dmac1 0xcd>, <&dmac1 0xce>;
 		dma-names = "tx", "rx";
@@ -544,7 +544,7 @@
 	sdhi1: sd at ee140000 {
 		compatible = "renesas,sdhi-r8a7791";
 		reg = <0 0xee140000 0 0x100>;
-		interrupts = <0 167 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_SDHI1>;
 		dmas = <&dmac1 0xc1>, <&dmac1 0xc2>;
 		dma-names = "tx", "rx";
@@ -555,7 +555,7 @@
 	sdhi2: sd at ee160000 {
 		compatible = "renesas,sdhi-r8a7791";
 		reg = <0 0xee160000 0 0x100>;
-		interrupts = <0 168 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_SDHI2>;
 		dmas = <&dmac1 0xd3>, <&dmac1 0xd4>;
 		dma-names = "tx", "rx";
@@ -566,7 +566,7 @@
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
-		interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
@@ -578,7 +578,7 @@
 	scifa1: serial at e6c50000 {
 		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
-		interrupts = <0 145 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
@@ -590,7 +590,7 @@
 	scifa2: serial at e6c60000 {
 		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
-		interrupts = <0 151 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
@@ -602,7 +602,7 @@
 	scifa3: serial at e6c70000 {
 		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
 		reg = <0 0xe6c70000 0 64>;
-		interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA3>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1b>, <&dmac0 0x1c>;
@@ -614,7 +614,7 @@
 	scifa4: serial at e6c78000 {
 		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
 		reg = <0 0xe6c78000 0 64>;
-		interrupts = <0 30 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA4>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1f>, <&dmac0 0x20>;
@@ -626,7 +626,7 @@
 	scifa5: serial at e6c80000 {
 		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
 		reg = <0 0xe6c80000 0 64>;
-		interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA5>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x23>, <&dmac0 0x24>;
@@ -638,7 +638,7 @@
 	scifb0: serial at e6c20000 {
 		compatible = "renesas,scifb-r8a7791", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
-		interrupts = <0 148 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
@@ -650,7 +650,7 @@
 	scifb1: serial at e6c30000 {
 		compatible = "renesas,scifb-r8a7791", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
@@ -662,7 +662,7 @@
 	scifb2: serial at e6ce0000 {
 		compatible = "renesas,scifb-r8a7791", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
-		interrupts = <0 150 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
@@ -674,7 +674,7 @@
 	scif0: serial at e6e60000 {
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
-		interrupts = <0 152 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
@@ -686,7 +686,7 @@
 	scif1: serial at e6e68000 {
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
-		interrupts = <0 153 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
@@ -698,7 +698,7 @@
 	scif2: serial at e6e58000 {
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
-		interrupts = <0 22 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
@@ -710,7 +710,7 @@
 	scif3: serial at e6ea8000 {
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
-		interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF3>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
@@ -722,7 +722,7 @@
 	scif4: serial at e6ee0000 {
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
-		interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF4>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
@@ -734,7 +734,7 @@
 	scif5: serial at e6ee8000 {
 		compatible = "renesas,scif-r8a7791", "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
-		interrupts = <0 25 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF5>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
@@ -746,7 +746,7 @@
 	hscif0: serial at e62c0000 {
 		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
-		interrupts = <0 154 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
@@ -758,7 +758,7 @@
 	hscif1: serial at e62c8000 {
 		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
-		interrupts = <0 155 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
@@ -770,7 +770,7 @@
 	hscif2: serial at e62d0000 {
 		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
-		interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
@@ -782,7 +782,7 @@
 	ether: ethernet at ee700000 {
 		compatible = "renesas,ether-r8a7791";
 		reg = <0 0xee700000 0 0x400>;
-		interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7791_CLK_ETHER>;
 		power-domains = <&cpg_clocks>;
 		phy-mode = "rmii";
@@ -795,7 +795,7 @@
 		compatible = "renesas,etheravb-r8a7791",
 			     "renesas,etheravb-rcar-gen2";
 		reg = <0 0xe6800000 0 0x800>, <0 0xee0e8000 0 0x4000>;
-		interrupts = <0 163 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7791_CLK_ETHERAVB>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -806,7 +806,7 @@
 	sata0: sata at ee300000 {
 		compatible = "renesas,sata-r8a7791";
 		reg = <0 0xee300000 0 0x2000>;
-		interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7791_CLK_SATA0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -815,7 +815,7 @@
 	sata1: sata at ee500000 {
 		compatible = "renesas,sata-r8a7791";
 		reg = <0 0xee500000 0 0x2000>;
-		interrupts = <0 106 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7791_CLK_SATA1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -824,7 +824,7 @@
 	hsusb: usb at e6590000 {
 		compatible = "renesas,usbhs-r8a7791", "renesas,rcar-gen2-usbhs";
 		reg = <0 0xe6590000 0 0x100>;
-		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSUSB>;
 		dmas = <&usb_dmac0 0>, <&usb_dmac0 1>,
 		       <&usb_dmac1 0>, <&usb_dmac1 1>;
@@ -859,7 +859,7 @@
 	vin0: video at e6ef0000 {
 		compatible = "renesas,vin-r8a7791";
 		reg = <0 0xe6ef0000 0 0x1000>;
-		interrupts = <0 188 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7791_CLK_VIN0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -868,7 +868,7 @@
 	vin1: video at e6ef1000 {
 		compatible = "renesas,vin-r8a7791";
 		reg = <0 0xe6ef1000 0 0x1000>;
-		interrupts = <0 189 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7791_CLK_VIN1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -877,7 +877,7 @@
 	vin2: video at e6ef2000 {
 		compatible = "renesas,vin-r8a7791";
 		reg = <0 0xe6ef2000 0 0x1000>;
-		interrupts = <0 190 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7791_CLK_VIN2>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -886,7 +886,7 @@
 	vsp1 at fe928000 {
 		compatible = "renesas,vsp1";
 		reg = <0 0xfe928000 0 0x8000>;
-		interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7791_CLK_VSP1_S>;
 		power-domains = <&cpg_clocks>;
 
@@ -900,7 +900,7 @@
 	vsp1 at fe930000 {
 		compatible = "renesas,vsp1";
 		reg = <0 0xfe930000 0 0x8000>;
-		interrupts = <0 246 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7791_CLK_VSP1_DU0>;
 		power-domains = <&cpg_clocks>;
 
@@ -914,7 +914,7 @@
 	vsp1 at fe938000 {
 		compatible = "renesas,vsp1";
 		reg = <0 0xfe938000 0 0x8000>;
-		interrupts = <0 247 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7791_CLK_VSP1_DU1>;
 		power-domains = <&cpg_clocks>;
 
@@ -930,8 +930,8 @@
 		reg = <0 0xfeb00000 0 0x40000>,
 		      <0 0xfeb90000 0 0x1c>;
 		reg-names = "du", "lvds.0";
-		interrupts = <0 256 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 268 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_DU0>,
 			 <&mstp7_clks R8A7791_CLK_DU1>,
 			 <&mstp7_clks R8A7791_CLK_LVDS0>;
@@ -958,7 +958,7 @@
 	can0: can at e6e80000 {
 		compatible = "renesas,can-r8a7791";
 		reg = <0 0xe6e80000 0 0x1000>;
-		interrupts = <0 186 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_RCAN0>,
 			 <&cpg_clocks R8A7791_CLK_RCAN>, <&can_clk>;
 		clock-names = "clkp1", "clkp2", "can_clk";
@@ -969,7 +969,7 @@
 	can1: can at e6e88000 {
 		compatible = "renesas,can-r8a7791";
 		reg = <0 0xe6e88000 0 0x1000>;
-		interrupts = <0 187 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_RCAN1>,
 			 <&cpg_clocks R8A7791_CLK_RCAN>, <&can_clk>;
 		clock-names = "clkp1", "clkp2", "can_clk";
@@ -980,7 +980,7 @@
 	jpu: jpeg-codec at fe980000 {
 		compatible = "renesas,jpu-r8a7791";
 		reg = <0 0xfe980000 0 0x10300>;
-		interrupts = <0 272 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7791_CLK_JPU>;
 		power-domains = <&cpg_clocks>;
 	};
@@ -1432,7 +1432,7 @@
 	qspi: spi at e6b10000 {
 		compatible = "renesas,qspi-r8a7791", "renesas,qspi";
 		reg = <0 0xe6b10000 0 0x2c>;
-		interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7791_CLK_QSPI_MOD>;
 		dmas = <&dmac0 0x17>, <&dmac0 0x18>;
 		dma-names = "tx", "rx";
@@ -1446,7 +1446,7 @@
 	msiof0: spi at e6e20000 {
 		compatible = "renesas,msiof-r8a7791";
 		reg = <0 0xe6e20000 0 0x0064>;
-		interrupts = <0 156 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7791_CLK_MSIOF0>;
 		dmas = <&dmac0 0x51>, <&dmac0 0x52>;
 		dma-names = "tx", "rx";
@@ -1459,7 +1459,7 @@
 	msiof1: spi at e6e10000 {
 		compatible = "renesas,msiof-r8a7791";
 		reg = <0 0xe6e10000 0 0x0064>;
-		interrupts = <0 157 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_MSIOF1>;
 		dmas = <&dmac0 0x55>, <&dmac0 0x56>;
 		dma-names = "tx", "rx";
@@ -1472,7 +1472,7 @@
 	msiof2: spi at e6e00000 {
 		compatible = "renesas,msiof-r8a7791";
 		reg = <0 0xe6e00000 0 0x0064>;
-		interrupts = <0 158 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_MSIOF2>;
 		dmas = <&dmac0 0x41>, <&dmac0 0x42>;
 		dma-names = "tx", "rx";
@@ -1485,7 +1485,7 @@
 	xhci: usb at ee000000 {
 		compatible = "renesas,xhci-r8a7791";
 		reg = <0 0xee000000 0 0xc00>;
-		interrupts = <0 101 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_SSUSB>;
 		power-domains = <&cpg_clocks>;
 		phys = <&usb2 1>;
@@ -1498,7 +1498,7 @@
 		device_type = "pci";
 		reg = <0 0xee090000 0 0xc00>,
 		      <0 0xee080000 0 0x1100>;
-		interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_EHCI>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -1509,9 +1509,9 @@
 		#interrupt-cells = <1>;
 		ranges = <0x02000000 0 0xee080000 0 0xee080000 0 0x00010000>;
 		interrupt-map-mask = <0xff00 0 0 0x7>;
-		interrupt-map = <0x0000 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
-				 0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
-				 0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH
+				 0x0800 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH
+				 0x1000 0 0 2 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 
 		usb at 0,1 {
 			reg = <0x800 0 0 0 0>;
@@ -1533,7 +1533,7 @@
 		device_type = "pci";
 		reg = <0 0xee0d0000 0 0xc00>,
 		      <0 0xee0c0000 0 0x1100>;
-		interrupts = <0 113 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_EHCI>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -1544,9 +1544,9 @@
 		#interrupt-cells = <1>;
 		ranges = <0x02000000 0 0xee0c0000 0 0xee0c0000 0 0x00010000>;
 		interrupt-map-mask = <0xff00 0 0 0x7>;
-		interrupt-map = <0x0000 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
-				 0x0800 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
-				 0x1000 0 0 2 &gic 0 113 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
+				 0x0800 0 0 1 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
+				 0x1000 0 0 2 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
 
 		usb at 0,1 {
 			reg = <0x800 0 0 0 0>;
@@ -1577,12 +1577,12 @@
 		/* Map all possible DDR as inbound ranges */
 		dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000
 			      0x43000000 2 0x00000000 2 0x00000000 1 0x00000000>;
-		interrupts = <0 116 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 117 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 118 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
 		#interrupt-cells = <1>;
 		interrupt-map-mask = <0 0 0 0>;
-		interrupt-map = <0 0 0 0 &gic 0 116 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0 0 0 0 &gic GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7791_CLK_PCIEC>, <&pcie_bus_clk>;
 		clock-names = "pcie", "pcie_bus";
 		power-domains = <&cpg_clocks>;
@@ -1592,8 +1592,8 @@
 	ipmmu_sy0: mmu at e6280000 {
 		compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6280000 0 0x1000>;
-		interrupts = <0 223 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 224 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1601,7 +1601,7 @@
 	ipmmu_sy1: mmu at e6290000 {
 		compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6290000 0 0x1000>;
-		interrupts = <0 225 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1609,8 +1609,8 @@
 	ipmmu_ds: mmu at e6740000 {
 		compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6740000 0 0x1000>;
-		interrupts = <0 198 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 199 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1618,7 +1618,7 @@
 	ipmmu_mp: mmu at ec680000 {
 		compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";
 		reg = <0 0xec680000 0 0x1000>;
-		interrupts = <0 226 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1626,8 +1626,8 @@
 	ipmmu_mx: mmu at fe951000 {
 		compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";
 		reg = <0 0xfe951000 0 0x1000>;
-		interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 221 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1635,7 +1635,7 @@
 	ipmmu_rt: mmu at ffc80000 {
 		compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";
 		reg = <0 0xffc80000 0 0x1000>;
-		interrupts = <0 307 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1643,8 +1643,8 @@
 	ipmmu_gp: mmu at e62a0000 {
 		compatible = "renesas,ipmmu-r8a7791", "renesas,ipmmu-vmsa";
 		reg = <0 0xe62a0000 0 0x1000>;
-		interrupts = <0 260 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 261 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 261 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1721,52 +1721,52 @@
 
 		rcar_sound,src {
 			src0: src at 0 {
-				interrupts = <0 352 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x85>, <&audma1 0x9a>;
 				dma-names = "rx", "tx";
 			};
 			src1: src at 1 {
-				interrupts = <0 353 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x87>, <&audma1 0x9c>;
 				dma-names = "rx", "tx";
 			};
 			src2: src at 2 {
-				interrupts = <0 354 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x89>, <&audma1 0x9e>;
 				dma-names = "rx", "tx";
 			};
 			src3: src at 3 {
-				interrupts = <0 355 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x8b>, <&audma1 0xa0>;
 				dma-names = "rx", "tx";
 			};
 			src4: src at 4 {
-				interrupts = <0 356 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x8d>, <&audma1 0xb0>;
 				dma-names = "rx", "tx";
 			};
 			src5: src at 5 {
-				interrupts = <0 357 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x8f>, <&audma1 0xb2>;
 				dma-names = "rx", "tx";
 			};
 			src6: src at 6 {
-				interrupts = <0 358 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x91>, <&audma1 0xb4>;
 				dma-names = "rx", "tx";
 			};
 			src7: src at 7 {
-				interrupts = <0 359 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x93>, <&audma1 0xb6>;
 				dma-names = "rx", "tx";
 			};
 			src8: src at 8 {
-				interrupts = <0 360 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x95>, <&audma1 0xb8>;
 				dma-names = "rx", "tx";
 			};
 			src9: src at 9 {
-				interrupts = <0 361 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x97>, <&audma1 0xba>;
 				dma-names = "rx", "tx";
 			};
@@ -1774,52 +1774,52 @@
 
 		rcar_sound,ssi {
 			ssi0: ssi at 0 {
-				interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x01>, <&audma1 0x02>, <&audma0 0x15>, <&audma1 0x16>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi1: ssi at 1 {
-				 interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>;
+				 interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x03>, <&audma1 0x04>, <&audma0 0x49>, <&audma1 0x4a>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi2: ssi at 2 {
-				interrupts = <0 372 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x05>, <&audma1 0x06>, <&audma0 0x63>, <&audma1 0x64>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi3: ssi at 3 {
-				interrupts = <0 373 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x07>, <&audma1 0x08>, <&audma0 0x6f>, <&audma1 0x70>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi4: ssi at 4 {
-				interrupts = <0 374 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x09>, <&audma1 0x0a>, <&audma0 0x71>, <&audma1 0x72>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi5: ssi at 5 {
-				interrupts = <0 375 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x0b>, <&audma1 0x0c>, <&audma0 0x73>, <&audma1 0x74>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi6: ssi at 6 {
-				interrupts = <0 376 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x0d>, <&audma1 0x0e>, <&audma0 0x75>, <&audma1 0x76>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi7: ssi at 7 {
-				interrupts = <0 377 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x0f>, <&audma1 0x10>, <&audma0 0x79>, <&audma1 0x7a>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi8: ssi at 8 {
-				interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x11>, <&audma1 0x12>, <&audma0 0x7b>, <&audma1 0x7c>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi9: ssi at 9 {
-				interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x13>, <&audma1 0x14>, <&audma0 0x7d>, <&audma1 0x7e>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:06 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:06 +0100
Subject: [PATCH 16/68] ARM: dts: r8a7793: gose: Add HDMI video out support
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <8871eb07c0e77196f1f6cd2ccd659516e3e5d9aa.1455303422.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm+renesas at opensource.se>

This patch adds r8a7793 GOSE HDMI video out support.

The r8a7793 GOSE board is similar to r8a7791 Koelsch. For those
boards an on-board HDMI encoder chip provides HDMI video out
and also a LVDS port is available for external LCD panels.

Tested on r8a7793 Gose with HDMI hooked up to a Toshiba TV.

Signed-off-by: Magnus Damm <damm+renesas at opensource.se>
[simon: rebased; reused existing i2c2 node]
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 85 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 85 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 987ed03b1e02..0b4cc8d99390 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -129,6 +129,54 @@
 			label = "LED8";
 		};
 	};
+
+	hdmi-out {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_con: endpoint {
+				remote-endpoint = <&adv7511_out>;
+			};
+		};
+	};
+
+	x2_clk: x2-clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <74250000>;
+	};
+
+	x13_clk: x13-clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <148500000>;
+	};
+};
+
+&du {
+	pinctrl-0 = <&du_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	clocks = <&mstp7_clks R8A7793_CLK_DU0>,
+		 <&mstp7_clks R8A7793_CLK_DU1>,
+		 <&mstp7_clks R8A7793_CLK_LVDS0>,
+		 <&x13_clk>, <&x2_clk>;
+	clock-names = "du.0", "du.1", "lvds.0",
+		      "dclkin.0", "dclkin.1";
+
+	ports {
+		port at 0 {
+			endpoint {
+				remote-endpoint = <&adv7511_in>;
+			};
+		};
+		port at 1 {
+			lvds_connector: endpoint {
+			};
+		};
+	};
 };
 
 &extal_clk {
@@ -141,6 +189,11 @@
 		renesas,function = "i2c2";
 	};
 
+	du_pins: du {
+		renesas,groups = "du_rgb888", "du_sync", "du_disp", "du_clk_out_0";
+		renesas,function = "du";
+	};
+
 	scif0_pins: serial0 {
 		renesas,groups = "scif0_data_d";
 		renesas,function = "scif0";
@@ -247,6 +300,38 @@
 	status = "okay";
 	clock-frequency = <100000>;
 
+	hdmi at 39 {
+		compatible = "adi,adv7511w";
+		reg = <0x39>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+
+		adi,input-depth = <8>;
+		adi,input-colorspace = "rgb";
+		adi,input-clock = "1x";
+		adi,input-style = <1>;
+		adi,input-justification = "evenly";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port at 0 {
+				reg = <0>;
+				adv7511_in: endpoint {
+					remote-endpoint = <&du_out_rgb>;
+				};
+			};
+
+			port at 1 {
+				reg = <1>;
+				adv7511_out: endpoint {
+					remote-endpoint = <&hdmi_con>;
+				};
+			};
+		};
+	};
+
 	eeprom at 50 {
 		compatible = "renesas,r1ex24002", "atmel,24c02";
 		reg = <0x50>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:08 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:08 +0100
Subject: [PATCH 18/68] ARM: dts: r8a7779: use GIC_* defines
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <854b7733fee0ebdb70e34ffa5f57de4cff319a49.1455303422.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7779 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7779.dtsi | 78 +++++++++++++++++++++---------------------
 1 file changed, 39 insertions(+), 39 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 6afa909865b5..93f3fdf95e31 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -74,7 +74,7 @@
 	gpio0: gpio at ffc40000 {
 		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
 		reg = <0xffc40000 0x2c>;
-		interrupts = <0 141 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 0 32>;
@@ -85,7 +85,7 @@
 	gpio1: gpio at ffc41000 {
 		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
 		reg = <0xffc41000 0x2c>;
-		interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 32 32>;
@@ -96,7 +96,7 @@
 	gpio2: gpio at ffc42000 {
 		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
 		reg = <0xffc42000 0x2c>;
-		interrupts = <0 143 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 64 32>;
@@ -107,7 +107,7 @@
 	gpio3: gpio at ffc43000 {
 		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
 		reg = <0xffc43000 0x2c>;
-		interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 96 32>;
@@ -118,7 +118,7 @@
 	gpio4: gpio at ffc44000 {
 		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
 		reg = <0xffc44000 0x2c>;
-		interrupts = <0 145 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 128 32>;
@@ -129,7 +129,7 @@
 	gpio5: gpio at ffc45000 {
 		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
 		reg = <0xffc45000 0x2c>;
-		interrupts = <0 146 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 160 32>;
@@ -140,7 +140,7 @@
 	gpio6: gpio at ffc46000 {
 		compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
 		reg = <0xffc46000 0x2c>;
-		interrupts = <0 147 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 192 9>;
@@ -159,10 +159,10 @@
 			<0xfe780044 4>,
 			<0xfe780064 4>,
 			<0xfe780000 4>;
-		interrupts = <0 27 IRQ_TYPE_LEVEL_HIGH
-			      0 28 IRQ_TYPE_LEVEL_HIGH
-			      0 29 IRQ_TYPE_LEVEL_HIGH
-			      0 30 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		sense-bitfield-width = <2>;
 	};
 
@@ -171,7 +171,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7779";
 		reg = <0xffc70000 0x1000>;
-		interrupts = <0 79 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_I2C0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -182,7 +182,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7779";
 		reg = <0xffc71000 0x1000>;
-		interrupts = <0 82 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_I2C1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -193,7 +193,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7779";
 		reg = <0xffc72000 0x1000>;
-		interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_I2C2>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -204,7 +204,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7779";
 		reg = <0xffc73000 0x1000>;
-		interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_I2C3>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -213,7 +213,7 @@
 	scif0: serial at ffe40000 {
 		compatible = "renesas,scif-r8a7779", "renesas,scif";
 		reg = <0xffe40000 0x100>;
-		interrupts = <0 88 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF0>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -223,7 +223,7 @@
 	scif1: serial at ffe41000 {
 		compatible = "renesas,scif-r8a7779", "renesas,scif";
 		reg = <0xffe41000 0x100>;
-		interrupts = <0 89 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF1>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -233,7 +233,7 @@
 	scif2: serial at ffe42000 {
 		compatible = "renesas,scif-r8a7779", "renesas,scif";
 		reg = <0xffe42000 0x100>;
-		interrupts = <0 90 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF2>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -243,7 +243,7 @@
 	scif3: serial at ffe43000 {
 		compatible = "renesas,scif-r8a7779", "renesas,scif";
 		reg = <0xffe43000 0x100>;
-		interrupts = <0 91 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF3>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -253,7 +253,7 @@
 	scif4: serial at ffe44000 {
 		compatible = "renesas,scif-r8a7779", "renesas,scif";
 		reg = <0xffe44000 0x100>;
-		interrupts = <0 92 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF4>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -263,7 +263,7 @@
 	scif5: serial at ffe45000 {
 		compatible = "renesas,scif-r8a7779", "renesas,scif";
 		reg = <0xffe45000 0x100>;
-		interrupts = <0 93 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF5>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -283,9 +283,9 @@
 	tmu0: timer at ffd80000 {
 		compatible = "renesas,tmu-r8a7779", "renesas,tmu";
 		reg = <0xffd80000 0x30>;
-		interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 33 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 34 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_TMU0>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -298,9 +298,9 @@
 	tmu1: timer at ffd81000 {
 		compatible = "renesas,tmu-r8a7779", "renesas,tmu";
 		reg = <0xffd81000 0x30>;
-		interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 37 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 38 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_TMU1>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -313,9 +313,9 @@
 	tmu2: timer at ffd82000 {
 		compatible = "renesas,tmu-r8a7779", "renesas,tmu";
 		reg = <0xffd82000 0x30>;
-		interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 41 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 42 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_TMU2>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -328,7 +328,7 @@
 	sata: sata at fc600000 {
 		compatible = "renesas,sata-r8a7779", "renesas,rcar-sata";
 		reg = <0xfc600000 0x2000>;
-		interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7779_CLK_SATA>;
 		power-domains = <&cpg_clocks>;
 	};
@@ -336,7 +336,7 @@
 	sdhi0: sd at ffe4c000 {
 		compatible = "renesas,sdhi-r8a7779";
 		reg = <0xffe4c000 0x100>;
-		interrupts = <0 104 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7779_CLK_SDHI0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -345,7 +345,7 @@
 	sdhi1: sd at ffe4d000 {
 		compatible = "renesas,sdhi-r8a7779";
 		reg = <0xffe4d000 0x100>;
-		interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7779_CLK_SDHI1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -354,7 +354,7 @@
 	sdhi2: sd at ffe4e000 {
 		compatible = "renesas,sdhi-r8a7779";
 		reg = <0xffe4e000 0x100>;
-		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7779_CLK_SDHI2>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -363,7 +363,7 @@
 	sdhi3: sd at ffe4f000 {
 		compatible = "renesas,sdhi-r8a7779";
 		reg = <0xffe4f000 0x100>;
-		interrupts = <0 106 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7779_CLK_SDHI3>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -372,7 +372,7 @@
 	hspi0: spi at fffc7000 {
 		compatible = "renesas,hspi-r8a7779", "renesas,hspi";
 		reg = <0xfffc7000 0x18>;
-		interrupts = <0 73 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&mstp0_clks R8A7779_CLK_HSPI>;
@@ -383,7 +383,7 @@
 	hspi1: spi at fffc8000 {
 		compatible = "renesas,hspi-r8a7779", "renesas,hspi";
 		reg = <0xfffc8000 0x18>;
-		interrupts = <0 74 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&mstp0_clks R8A7779_CLK_HSPI>;
@@ -394,7 +394,7 @@
 	hspi2: spi at fffc6000 {
 		compatible = "renesas,hspi-r8a7779", "renesas,hspi";
 		reg = <0xfffc6000 0x18>;
-		interrupts = <0 75 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 		clocks = <&mstp0_clks R8A7779_CLK_HSPI>;
@@ -405,7 +405,7 @@
 	du: display at fff80000 {
 		compatible = "renesas,du-r8a7779";
 		reg = <0 0xfff80000 0 0x40000>;
-		interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7779_CLK_DU>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:12 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:12 +0100
Subject: [PATCH 22/68] ARM: dts: r8a7793: add MSTP10 clocks to device tree
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <072d326542e491874c31adda10bf513b371e560c.1455303422.git.horms+renesas@verge.net.au>

Instantiate MSTP10 clocks in r8a7793 device tree.

Based on similar work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi            | 36 +++++++++++++++++++++++++++++++
 include/dt-bindings/clock/r8a7793-clock.h |  2 ++
 2 files changed, 38 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index ea1196b99d52..c4459f147330 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -963,6 +963,42 @@
 				"qspi_mod", "i2c5", "i2c6", "i2c4",
 				"i2c3", "i2c2", "i2c1", "i2c0";
 		};
+		mstp10_clks: mstp10_clks at e6150998 {
+			compatible = "renesas,r8a7793-mstp-clocks", "renesas,cpg-mstp-clocks";
+			reg = <0 0xe6150998 0 4>, <0 0xe61509a8 0 4>;
+			clocks = <&p_clk>,
+				<&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+				<&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>,
+				<&p_clk>,
+				<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>,
+				<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>,
+				<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>,
+				<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>,
+				<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>,
+				<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>,
+				<&mstp10_clks R8A7793_CLK_SCU_ALL>, <&mstp10_clks R8A7793_CLK_SCU_ALL>;
+
+			#clock-cells = <1>;
+			clock-indices = <
+				R8A7793_CLK_SSI_ALL
+				R8A7793_CLK_SSI9 R8A7793_CLK_SSI8 R8A7793_CLK_SSI7 R8A7793_CLK_SSI6 R8A7793_CLK_SSI5
+				R8A7793_CLK_SSI4 R8A7793_CLK_SSI3 R8A7793_CLK_SSI2 R8A7793_CLK_SSI1 R8A7793_CLK_SSI0
+				R8A7793_CLK_SCU_ALL
+				R8A7793_CLK_SCU_DVC1 R8A7793_CLK_SCU_DVC0
+				R8A7793_CLK_SCU_CTU1_MIX1 R8A7793_CLK_SCU_CTU0_MIX0
+				R8A7793_CLK_SCU_SRC9 R8A7793_CLK_SCU_SRC8 R8A7793_CLK_SCU_SRC7 R8A7793_CLK_SCU_SRC6 R8A7793_CLK_SCU_SRC5
+				R8A7793_CLK_SCU_SRC4 R8A7793_CLK_SCU_SRC3 R8A7793_CLK_SCU_SRC2 R8A7793_CLK_SCU_SRC1 R8A7793_CLK_SCU_SRC0
+			>;
+			clock-output-names =
+				"ssi-all",
+				"ssi9", "ssi8", "ssi7", "ssi6", "ssi5",
+				"ssi4", "ssi3", "ssi2", "ssi1", "ssi0",
+				"scu-all",
+				"scu-dvc1", "scu-dvc0",
+				"scu-ctu1-mix1", "scu-ctu0-mix0",
+				"scu-src9", "scu-src8", "scu-src7", "scu-src6", "scu-src5",
+				"scu-src4", "scu-src3", "scu-src2", "scu-src1", "scu-src0";
+		};
 		mstp11_clks: mstp11_clks at e615099c {
 			compatible = "renesas,r8a7793-mstp-clocks", "renesas,cpg-mstp-clocks";
 			reg = <0 0xe615099c 0 4>, <0 0xe61509ac 0 4>;
diff --git a/include/dt-bindings/clock/r8a7793-clock.h b/include/dt-bindings/clock/r8a7793-clock.h
index 1579e07f96a3..efcbc594fe82 100644
--- a/include/dt-bindings/clock/r8a7793-clock.h
+++ b/include/dt-bindings/clock/r8a7793-clock.h
@@ -145,6 +145,8 @@
 #define R8A7793_CLK_SCU_ALL		17
 #define R8A7793_CLK_SCU_DVC1		18
 #define R8A7793_CLK_SCU_DVC0		19
+#define R8A7793_CLK_SCU_CTU1_MIX1	20
+#define R8A7793_CLK_SCU_CTU0_MIX0	21
 #define R8A7793_CLK_SCU_SRC9		22
 #define R8A7793_CLK_SCU_SRC8		23
 #define R8A7793_CLK_SCU_SRC7		24
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:09 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:09 +0100
Subject: [PATCH 19/68] ARM: dts: porter: add sound support
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <493b4da7c10ca647850627849bcf6031c0a80f13.1455303422.git.horms+renesas@verge.net.au>

From: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

Define the Porter board dependent part of the R8A7791 sound device node.
Add device node for Asahi Kasei AK4642 stereo codec  to the I2C2 bus.
Add the "simple-audio-card" device node to interconnect the SoC sound
device  and the codec.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791-porter.dts | 71 ++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
index fe81fa0e478c..5015eaa0ae50 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -8,6 +8,17 @@
  * kind, whether express or implied.
  */
 
+/*
+ * SSI-AK4642
+ *
+ * SW3: 1: AK4642
+ *      3: ADV7511
+ *
+ * This command is required before playback/capture:
+ *
+ *	amixer set "LINEOUT Mixer DACL" on
+ */
+
 /dts-v1/;
 #include "r8a7791.dtsi"
 #include <dt-bindings/gpio/gpio.h>
@@ -101,6 +112,30 @@
 		#clock-cells = <0>;
 		clock-frequency = <74250000>;
 	};
+
+	x14_clk: x14-clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <11289600>;
+		clock-output-names = "audio_clock";
+	};
+
+	sound {
+		compatible = "simple-audio-card";
+
+		simple-audio-card,format = "left_j";
+		simple-audio-card,bitclock-master = <&soundcodec>;
+		simple-audio-card,frame-master = <&soundcodec>;
+
+		simple-audio-card,cpu {
+			sound-dai = <&rcar_sound>;
+		};
+
+		soundcodec: simple-audio-card,codec {
+			sound-dai = <&ak4642>;
+			clocks = <&x14_clk>;
+		};
+	};
 };
 
 &extal_clk {
@@ -167,6 +202,16 @@
 		renesas,groups = "du_rgb888", "du_sync", "du_disp", "du_clk_out_0";
 		renesas,function = "du";
 	};
+
+	ssi_pins: sound {
+		renesas,groups = "ssi0129_ctrl", "ssi0_data", "ssi1_data";
+		renesas,function = "ssi";
+	};
+
+	audio_clk_pins: audio_clk {
+		renesas,groups = "audio_clk_a";
+		renesas,function = "audio_clk";
+	};
 };
 
 &scif0 {
@@ -257,6 +302,12 @@
 	status = "okay";
 	clock-frequency = <400000>;
 
+	ak4642: codec at 12 {
+		compatible = "asahi-kasei,ak4642";
+		#sound-dai-cells = <0>;
+		reg = <0x12>;
+	};
+
 	composite-in at 20 {
 		compatible = "adi,adv7180";
 		reg = <0x20>;
@@ -385,3 +436,23 @@
 		};
 	};
 };
+
+&rcar_sound {
+	pinctrl-0 = <&ssi_pins &audio_clk_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	/* Single DAI */
+	#sound-dai-cells = <0>;
+
+	rcar_sound,dai {
+		dai0 {
+			playback = <&ssi0>;
+			capture  = <&ssi1>;
+		};
+	};
+};
+
+&ssi1 {
+	shared-pin;
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:25 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:25 +0100
Subject: [PATCH 35/68] ARM: dts: r8a7793: enable audio DMAC in device tree
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <f418cbb69a2f5a481bd5f210bb5c8c5cc9322224.1455303422.git.horms+renesas@verge.net.au>

Enable audio DMAC (= rcar-dmac) in r8a7793 device tree.

Based on similar work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

---
v4
* Use GIC_SPI in interrupts properties
---
 arch/arm/boot/dts/r8a7793.dtsi | 91 ++++++++++++++++++++++++++++++++++++------
 1 file changed, 79 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index ddbda9d2c177..6817f14314e2 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -1201,52 +1201,119 @@
 		status = "disabled";
 
 		rcar_sound,dvc {
-			dvc0: dvc at 0 { };
-			dvc1: dvc at 1 { };
+			dvc0: dvc at 0 {
+				dmas = <&audma0 0xbc>;
+				dma-names = "tx";
+			};
+			dvc1: dvc at 1 {
+				dmas = <&audma0 0xbe>;
+				dma-names = "tx";
+			};
 		};
+
 		rcar_sound,src {
-			src0: src at 0 { };
-			src1: src at 1 { };
-			src2: src at 2 { };
-			src3: src at 3 { };
-			src4: src at 4 { };
-			src5: src at 5 { };
-			src6: src at 6 { };
-			src7: src at 7 { };
-			src8: src at 8 { };
-			src9: src at 9 { };
+			src0: src at 0 {
+				interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x85>, <&audma1 0x9a>;
+				dma-names = "rx", "tx";
+			};
+			src1: src at 1 {
+				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x87>, <&audma1 0x9c>;
+				dma-names = "rx", "tx";
+			};
+			src2: src at 2 {
+				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x89>, <&audma1 0x9e>;
+				dma-names = "rx", "tx";
+			};
+			src3: src at 3 {
+				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x8b>, <&audma1 0xa0>;
+				dma-names = "rx", "tx";
+			};
+			src4: src at 4 {
+				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x8d>, <&audma1 0xb0>;
+				dma-names = "rx", "tx";
+			};
+			src5: src at 5 {
+				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x8f>, <&audma1 0xb2>;
+				dma-names = "rx", "tx";
+			};
+			src6: src at 6 {
+				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x91>, <&audma1 0xb4>;
+				dma-names = "rx", "tx";
+			};
+			src7: src at 7 {
+				interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x93>, <&audma1 0xb6>;
+				dma-names = "rx", "tx";
+			};
+			src8: src at 8 {
+				interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x95>, <&audma1 0xb8>;
+				dma-names = "rx", "tx";
+			};
+			src9: src at 9 {
+				interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x97>, <&audma1 0xba>;
+				dma-names = "rx", "tx";
+			};
 		};
 
 		rcar_sound,ssi {
 			ssi0: ssi at 0 {
 				interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x01>, <&audma1 0x02>, <&audma0 0x15>, <&audma1 0x16>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi1: ssi at 1 {
 				 interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x03>, <&audma1 0x04>, <&audma0 0x49>, <&audma1 0x4a>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi2: ssi at 2 {
 				interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x05>, <&audma1 0x06>, <&audma0 0x63>, <&audma1 0x64>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi3: ssi at 3 {
 				interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x07>, <&audma1 0x08>, <&audma0 0x6f>, <&audma1 0x70>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi4: ssi at 4 {
 				interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x09>, <&audma1 0x0a>, <&audma0 0x71>, <&audma1 0x72>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi5: ssi at 5 {
 				interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x0b>, <&audma1 0x0c>, <&audma0 0x73>, <&audma1 0x74>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi6: ssi at 6 {
 				interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x0d>, <&audma1 0x0e>, <&audma0 0x75>, <&audma1 0x76>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi7: ssi at 7 {
 				interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x0f>, <&audma1 0x10>, <&audma0 0x79>, <&audma1 0x7a>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi8: ssi at 8 {
 				interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x11>, <&audma1 0x12>, <&audma0 0x7b>, <&audma1 0x7c>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi9: ssi at 9 {
 				interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
+				dmas = <&audma0 0x13>, <&audma1 0x14>, <&audma0 0x7d>, <&audma1 0x7e>;
+				dma-names = "rx", "tx", "rxu", "txu";
 			};
 		};
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:24 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:24 +0100
Subject: [PATCH 34/68] ARM: dts: gose: enable sound DMA support via DVC in
 device tree
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <ae79f66db7e75dfe696df7f392f4db4980117306.1455303422.git.horms+renesas@verge.net.au>

Enable DMA transfer using DVC in r8a7793/gose device tree.

     DMA               DMApp
[MEM] -> [SRC] -> [DVC] -> [SSIU] -> [SSI]

     DMA               DMApp
[MEM] <- [DVC] <- [SRC] <- [SSIU] <- [SSI]

Based on similar work for the r8a7791/koelsch by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 17c87fe0944f..2fa052036dbc 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -18,7 +18,24 @@
  * This command is required when Playback/Capture
  *
  *	amixer set "LINEOUT Mixer DACL" on
+ *	amixer set "DVC Out" 100%
+ *	amixer set "DVC In" 100%
+ *
+ * You can use Mute
+ *
+ *	amixer set "DVC Out Mute" on
+ *	amixer set "DVC In Mute" on
+ *
+ * You can use Volume Ramp
+ *
+ *	amixer set "DVC Out Ramp Up Rate"   "0.125 dB/64 steps"
+ *	amixer set "DVC Out Ramp Down Rate" "0.125 dB/512 steps"
+ *	amixer set "DVC Out Ramp" on
+ *	aplay xxx.wav &
+ *	amixer set "DVC Out"  80%  // Volume Down
+ *	amixer set "DVC Out" 100%  // Volume Up
  */
+
 /dts-v1/;
 #include "r8a7793.dtsi"
 #include <dt-bindings/gpio/gpio.h>
@@ -401,8 +418,8 @@
 
 	rcar_sound,dai {
 		dai0 {
-			playback = <&ssi0 &src2>;
-			capture  = <&ssi1 &src3>;
+			playback = <&ssi0 &src2 &dvc0>;
+			capture  = <&ssi1 &src3 &dvc1>;
 		};
 	};
 };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:28 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:28 +0100
Subject: [PATCH 38/68] ARM: dts: emev2: use GIC_* defines
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <b14ce2321b9c63f807719358c64bbe7aa973731c.1455303422.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in emev2 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/emev2.dtsi | 39 ++++++++++++++++++++-------------------
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/arch/arm/boot/dts/emev2.dtsi b/arch/arm/boot/dts/emev2.dtsi
index 57795da616cb..bcce6f50c93d 100644
--- a/arch/arm/boot/dts/emev2.dtsi
+++ b/arch/arm/boot/dts/emev2.dtsi
@@ -9,6 +9,7 @@
  */
 
 #include "skeleton.dtsi"
+#include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/interrupt-controller/irq.h>
 
 / {
@@ -53,8 +54,8 @@
 
 	pmu {
 		compatible = "arm,cortex-a9-pmu";
-		interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 121 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
 	};
 
 	clocks at e0110000 {
@@ -158,7 +159,7 @@
 	timer at e0180000 {
 		compatible = "renesas,em-sti";
 		reg = <0xe0180000 0x54>;
-		interrupts = <0 125 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&sti_sclk>;
 		clock-names = "sclk";
 	};
@@ -166,7 +167,7 @@
 	uart0: serial at e1020000 {
 		compatible = "renesas,em-uart";
 		reg = <0xe1020000 0x38>;
-		interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&usia_u0_sclk>;
 		clock-names = "sclk";
 	};
@@ -174,7 +175,7 @@
 	uart1: serial at e1030000 {
 		compatible = "renesas,em-uart";
 		reg = <0xe1030000 0x38>;
-		interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&usib_u1_sclk>;
 		clock-names = "sclk";
 	};
@@ -182,7 +183,7 @@
 	uart2: serial at e1040000 {
 		compatible = "renesas,em-uart";
 		reg = <0xe1040000 0x38>;
-		interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&usib_u2_sclk>;
 		clock-names = "sclk";
 	};
@@ -190,7 +191,7 @@
 	uart3: serial at e1050000 {
 		compatible = "renesas,em-uart";
 		reg = <0xe1050000 0x38>;
-		interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&usib_u3_sclk>;
 		clock-names = "sclk";
 	};
@@ -203,8 +204,8 @@
 	gpio0: gpio at e0050000 {
 		compatible = "renesas,em-gio";
 		reg = <0xe0050000 0x2c>, <0xe0050040 0x20>;
-		interrupts = <0 67 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 68 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 0 32>;
 		#gpio-cells = <2>;
@@ -215,8 +216,8 @@
 	gpio1: gpio at e0050080 {
 		compatible = "renesas,em-gio";
 		reg = <0xe0050080 0x2c>, <0xe00500c0 0x20>;
-		interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 70 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 32 32>;
 		#gpio-cells = <2>;
@@ -227,8 +228,8 @@
 	gpio2: gpio at e0050100 {
 		compatible = "renesas,em-gio";
 		reg = <0xe0050100 0x2c>, <0xe0050140 0x20>;
-		interrupts = <0 71 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 72 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 64 32>;
 		#gpio-cells = <2>;
@@ -239,8 +240,8 @@
 	gpio3: gpio at e0050180 {
 		compatible = "renesas,em-gio";
 		reg = <0xe0050180 0x2c>, <0xe00501c0 0x20>;
-		interrupts = <0 73 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 74 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 96 32>;
 		#gpio-cells = <2>;
@@ -251,8 +252,8 @@
 	gpio4: gpio at e0050200 {
 		compatible = "renesas,em-gio";
 		reg = <0xe0050200 0x2c>, <0xe0050240 0x20>;
-		interrupts = <0 75 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 76 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 128 31>;
 		#gpio-cells = <2>;
@@ -266,7 +267,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-emev2";
 		reg = <0xe0070000 0x28>;
-		interrupts = <0 32 IRQ_TYPE_EDGE_RISING>;
+		interrupts = <GIC_SPI 32 IRQ_TYPE_EDGE_RISING>;
 		clocks = <&iic0_sclk>;
 		clock-names = "sclk";
 		status = "disabled";
@@ -277,7 +278,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-emev2";
 		reg = <0xe10a0000 0x28>;
-		interrupts = <0 33 IRQ_TYPE_EDGE_RISING>;
+		interrupts = <GIC_SPI 33 IRQ_TYPE_EDGE_RISING>;
 		clocks = <&iic1_sclk>;
 		clock-names = "sclk";
 		status = "disabled";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:26 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:26 +0100
Subject: [PATCH 36/68] ARM: dts: r7s72100: use GIC_* defines
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <16af4e9705b1dee1a5b2e5d82632b584399fdf6d.1455303422.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r7s72100 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r7s72100.dtsi | 161 ++++++++++++++++++++--------------------
 1 file changed, 81 insertions(+), 80 deletions(-)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index 4657d7fb5bce..a5938c72d5bd 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -10,6 +10,7 @@
  */
 
 #include <dt-bindings/clock/r7s72100-clock.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/interrupt-controller/irq.h>
 
 / {
@@ -152,10 +153,10 @@
 	scif0: serial at e8007000 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe8007000 64>;
-		interrupts = <0 190 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 191 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 192 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 189 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF0>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -165,10 +166,10 @@
 	scif1: serial at e8007800 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe8007800 64>;
-		interrupts = <0 194 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 195 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 196 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 193 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF1>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -178,10 +179,10 @@
 	scif2: serial at e8008000 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe8008000 64>;
-		interrupts = <0 198 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 199 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 200 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 197 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF2>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -191,10 +192,10 @@
 	scif3: serial at e8008800 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe8008800 64>;
-		interrupts = <0 202 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 203 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 204 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 201 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF3>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -204,10 +205,10 @@
 	scif4: serial at e8009000 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe8009000 64>;
-		interrupts = <0 206 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 207 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 208 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 205 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF4>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -217,10 +218,10 @@
 	scif5: serial at e8009800 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe8009800 64>;
-		interrupts = <0 210 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 211 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 212 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 209 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF5>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -230,10 +231,10 @@
 	scif6: serial at e800a000 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe800a000 64>;
-		interrupts = <0 214 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 215 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 216 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 213 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF6>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -243,10 +244,10 @@
 	scif7: serial at e800a800 {
 		compatible = "renesas,scif-r7s72100", "renesas,scif";
 		reg = <0xe800a800 64>;
-		interrupts = <0 218 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 219 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 220 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 217 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF7>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -256,9 +257,9 @@
 	spi0: spi at e800c800 {
 		compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
 		reg = <0xe800c800 0x24>;
-		interrupts = <0 238 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 239 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 240 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 238 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 239 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error", "rx", "tx";
 		clocks = <&mstp10_clks R7S72100_CLK_SPI0>;
 		power-domains = <&cpg_clocks>;
@@ -271,9 +272,9 @@
 	spi1: spi at e800d000 {
 		compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
 		reg = <0xe800d000 0x24>;
-		interrupts = <0 241 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 242 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 243 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 241 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 242 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error", "rx", "tx";
 		clocks = <&mstp10_clks R7S72100_CLK_SPI1>;
 		power-domains = <&cpg_clocks>;
@@ -286,9 +287,9 @@
 	spi2: spi at e800d800 {
 		compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
 		reg = <0xe800d800 0x24>;
-		interrupts = <0 244 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 245 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 246 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 245 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error", "rx", "tx";
 		clocks = <&mstp10_clks R7S72100_CLK_SPI2>;
 		power-domains = <&cpg_clocks>;
@@ -301,9 +302,9 @@
 	spi3: spi at e800e000 {
 		compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
 		reg = <0xe800e000 0x24>;
-		interrupts = <0 247 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 248 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 249 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 248 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 249 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error", "rx", "tx";
 		clocks = <&mstp10_clks R7S72100_CLK_SPI3>;
 		power-domains = <&cpg_clocks>;
@@ -316,9 +317,9 @@
 	spi4: spi at e800e800 {
 		compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
 		reg = <0xe800e800 0x24>;
-		interrupts = <0 250 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 251 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 252 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 250 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 251 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 252 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error", "rx", "tx";
 		clocks = <&mstp10_clks R7S72100_CLK_SPI4>;
 		power-domains = <&cpg_clocks>;
@@ -342,14 +343,14 @@
 		#size-cells = <0>;
 		compatible = "renesas,riic-r7s72100", "renesas,riic-rz";
 		reg = <0xfcfee000 0x44>;
-		interrupts = <0 157 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 158 IRQ_TYPE_EDGE_RISING>,
-			     <0 159 IRQ_TYPE_EDGE_RISING>,
-			     <0 160 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 161 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 162 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 163 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 164 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 158 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 159 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R7S72100_CLK_I2C0>;
 		clock-frequency = <100000>;
 		power-domains = <&cpg_clocks>;
@@ -361,14 +362,14 @@
 		#size-cells = <0>;
 		compatible = "renesas,riic-r7s72100", "renesas,riic-rz";
 		reg = <0xfcfee400 0x44>;
-		interrupts = <0 165 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 166 IRQ_TYPE_EDGE_RISING>,
-			     <0 167 IRQ_TYPE_EDGE_RISING>,
-			     <0 168 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 169 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 170 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 171 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 172 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 166 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 167 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R7S72100_CLK_I2C1>;
 		clock-frequency = <100000>;
 		power-domains = <&cpg_clocks>;
@@ -380,14 +381,14 @@
 		#size-cells = <0>;
 		compatible = "renesas,riic-r7s72100", "renesas,riic-rz";
 		reg = <0xfcfee800 0x44>;
-		interrupts = <0 173 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 174 IRQ_TYPE_EDGE_RISING>,
-			     <0 175 IRQ_TYPE_EDGE_RISING>,
-			     <0 176 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 177 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 178 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 179 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 180 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 174 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 175 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R7S72100_CLK_I2C2>;
 		clock-frequency = <100000>;
 		power-domains = <&cpg_clocks>;
@@ -399,14 +400,14 @@
 		#size-cells = <0>;
 		compatible = "renesas,riic-r7s72100", "renesas,riic-rz";
 		reg = <0xfcfeec00 0x44>;
-		interrupts = <0 181 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 182 IRQ_TYPE_EDGE_RISING>,
-			     <0 183 IRQ_TYPE_EDGE_RISING>,
-			     <0 184 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 185 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 186 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 187 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 188 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 182 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 183 IRQ_TYPE_EDGE_RISING>,
+			     <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R7S72100_CLK_I2C3>;
 		clock-frequency = <100000>;
 		power-domains = <&cpg_clocks>;
@@ -416,7 +417,7 @@
 	mtu2: timer at fcff0000 {
 		compatible = "renesas,mtu2-r7s72100", "renesas,mtu2";
 		reg = <0xfcff0000 0x400>;
-		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "tgi0a";
 		clocks = <&mstp3_clks R7S72100_CLK_MTU2>;
 		clock-names = "fck";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:29 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:29 +0100
Subject: [PATCH 39/68] ARM: dts: r8a7778: Add SCIF fallback compatibility
 strings
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <720e9096e3c205dd71f951a9ff295f988a45e207.1455303422.git.horms+renesas@verge.net.au>

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

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7778.dtsi | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index fc5e7243467a..8ea1792c5146 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -297,7 +297,8 @@
 	};
 
 	scif0: serial at ffe40000 {
-		compatible = "renesas,scif-r8a7778", "renesas,scif";
+		compatible = "renesas,scif-r8a7778", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe40000 0x100>;
 		interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF0>;
@@ -307,7 +308,8 @@
 	};
 
 	scif1: serial at ffe41000 {
-		compatible = "renesas,scif-r8a7778", "renesas,scif";
+		compatible = "renesas,scif-r8a7778", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe41000 0x100>;
 		interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF1>;
@@ -317,7 +319,8 @@
 	};
 
 	scif2: serial at ffe42000 {
-		compatible = "renesas,scif-r8a7778", "renesas,scif";
+		compatible = "renesas,scif-r8a7778", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe42000 0x100>;
 		interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF2>;
@@ -327,7 +330,8 @@
 	};
 
 	scif3: serial at ffe43000 {
-		compatible = "renesas,scif-r8a7778", "renesas,scif";
+		compatible = "renesas,scif-r8a7778", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe43000 0x100>;
 		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF3>;
@@ -337,7 +341,8 @@
 	};
 
 	scif4: serial at ffe44000 {
-		compatible = "renesas,scif-r8a7778", "renesas,scif";
+		compatible = "renesas,scif-r8a7778", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe44000 0x100>;
 		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF4>;
@@ -347,7 +352,8 @@
 	};
 
 	scif5: serial at ffe45000 {
-		compatible = "renesas,scif-r8a7778", "renesas,scif";
+		compatible = "renesas,scif-r8a7778", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe45000 0x100>;
 		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF5>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:30 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:30 +0100
Subject: [PATCH 40/68] ARM: dts: r8a7779: Add SCIF fallback compatibility
 strings
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <b2ac44fa39569094131b2a998e60023a10794b17.1455303422.git.horms+renesas@verge.net.au>

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

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779.dtsi | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 93f3fdf95e31..1671839f55a6 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -211,7 +211,8 @@
 	};
 
 	scif0: serial at ffe40000 {
-		compatible = "renesas,scif-r8a7779", "renesas,scif";
+		compatible = "renesas,scif-r8a7779", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe40000 0x100>;
 		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF0>;
@@ -221,7 +222,8 @@
 	};
 
 	scif1: serial at ffe41000 {
-		compatible = "renesas,scif-r8a7779", "renesas,scif";
+		compatible = "renesas,scif-r8a7779", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe41000 0x100>;
 		interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF1>;
@@ -231,7 +233,8 @@
 	};
 
 	scif2: serial at ffe42000 {
-		compatible = "renesas,scif-r8a7779", "renesas,scif";
+		compatible = "renesas,scif-r8a7779", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe42000 0x100>;
 		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF2>;
@@ -241,7 +244,8 @@
 	};
 
 	scif3: serial at ffe43000 {
-		compatible = "renesas,scif-r8a7779", "renesas,scif";
+		compatible = "renesas,scif-r8a7779", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe43000 0x100>;
 		interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF3>;
@@ -251,7 +255,8 @@
 	};
 
 	scif4: serial at ffe44000 {
-		compatible = "renesas,scif-r8a7779", "renesas,scif";
+		compatible = "renesas,scif-r8a7779", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe44000 0x100>;
 		interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF4>;
@@ -261,7 +266,8 @@
 	};
 
 	scif5: serial at ffe45000 {
-		compatible = "renesas,scif-r8a7779", "renesas,scif";
+		compatible = "renesas,scif-r8a7779", "renesas,rcar-gen1-scif",
+			     "renesas,scif";
 		reg = <0xffe45000 0x100>;
 		interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF5>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:31 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:31 +0100
Subject: [PATCH 41/68] ARM: dts: r8a7790: Add SCIF fallback compatibility
 strings
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <a20dc9f2e4e18ecdf1114b43d2320503f6033917.1455303422.git.horms+renesas@verge.net.au>

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

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 30 ++++++++++++++++++++----------
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index cc7eccf0ada7..1d94dfd53141 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -585,7 +585,8 @@
 	};
 
 	scifa0: serial at e6c40000 {
-		compatible = "renesas,scifa-r8a7790", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7790",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA0>;
@@ -597,7 +598,8 @@
 	};
 
 	scifa1: serial at e6c50000 {
-		compatible = "renesas,scifa-r8a7790", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7790",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA1>;
@@ -609,7 +611,8 @@
 	};
 
 	scifa2: serial at e6c60000 {
-		compatible = "renesas,scifa-r8a7790", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7790",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA2>;
@@ -621,7 +624,8 @@
 	};
 
 	scifb0: serial at e6c20000 {
-		compatible = "renesas,scifb-r8a7790", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7790",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB0>;
@@ -633,7 +637,8 @@
 	};
 
 	scifb1: serial at e6c30000 {
-		compatible = "renesas,scifb-r8a7790", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7790",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB1>;
@@ -645,7 +650,8 @@
 	};
 
 	scifb2: serial at e6ce0000 {
-		compatible = "renesas,scifb-r8a7790", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7790",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB2>;
@@ -657,7 +663,8 @@
 	};
 
 	scif0: serial at e6e60000 {
-		compatible = "renesas,scif-r8a7790", "renesas,scif";
+		compatible = "renesas,scif-r8a7790", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_SCIF0>;
@@ -669,7 +676,8 @@
 	};
 
 	scif1: serial at e6e68000 {
-		compatible = "renesas,scif-r8a7790", "renesas,scif";
+		compatible = "renesas,scif-r8a7790", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_SCIF1>;
@@ -681,7 +689,8 @@
 	};
 
 	hscif0: serial at e62c0000 {
-		compatible = "renesas,hscif-r8a7790", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7790",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSCIF0>;
@@ -693,7 +702,8 @@
 	};
 
 	hscif1: serial at e62c8000 {
-		compatible = "renesas,hscif-r8a7790", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7790",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSCIF1>;
-- 
2.7.0.rc3.207.g0ac5344



From computersforpeace at gmail.com  Fri Feb 12 11:12:43 2016
From: computersforpeace at gmail.com (Brian Norris)
Date: Fri, 12 Feb 2016 11:12:43 -0800
Subject: [PATCH] mtd: map: fix .set_vpp() documentation
In-Reply-To: <1454364168-1342-1-git-send-email-linus.walleij@linaro.org>
References: <1454364168-1342-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <20160212191243.GB21465@google.com>

On Mon, Feb 01, 2016 at 11:02:48PM +0100, Linus Walleij wrote:
> As of commit 876fe76d793d03077eb61ba3afab4a383f46c554
> "mtd: maps: physmap: Add reference counter to set_vpp()"
> the comment in the header file is incorrect and misleading.
> Fix it up.
> 
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Paul Parsons <lost.distance at yahoo.com>
> Fixes: 876fe76d793d ("mtd: maps: physmap: Add reference counter to set_vpp()")

^^ Let's watch the non-gregkh stable maintainers pick up this patch just
because of this (undocumented in Documentation/stable_kernel_rules.txt)
tag :)

> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
>  include/linux/mtd/map.h | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
> index 58f3ba709ade..5e0eb7ccabd4 100644
> --- a/include/linux/mtd/map.h
> +++ b/include/linux/mtd/map.h
> @@ -240,8 +240,11 @@ struct map_info {
>  	   If there is no cache to care about this can be set to NULL. */
>  	void (*inval_cache)(struct map_info *, unsigned long, ssize_t);
>  
> -	/* set_vpp() must handle being reentered -- enable, enable, disable
> -	   must leave it enabled. */
> +	/* This will be called with 1 as parameter when the first map user
> +	 * needs VPP, and called with 0 when the last user exits. The map
> +	 * core maintains a reference counter, and assumes that VPP is a
> +	 * global resource applying to all mapped flash chips on the system.
> +	 */
>  	void (*set_vpp)(struct map_info *, int);
>  
>  	unsigned long pfow_base;

Looks good, thanks. Applied to l2-mtd.git


From horms+renesas at verge.net.au  Fri Feb 12 11:05:07 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:07 +0100
Subject: [PATCH 17/68] ARM: dts: r8a7778: use GIC_* defines
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <0c34bd1e00b0c60407ede0ca0d49862ef6116fa5.1455303422.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7778 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7778.dtsi | 87 +++++++++++++++++++++---------------------
 1 file changed, 44 insertions(+), 43 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index 791aafd310a5..fc5e7243467a 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -17,6 +17,7 @@
 /include/ "skeleton.dtsi"
 
 #include <dt-bindings/clock/r8a7778-clock.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/interrupt-controller/irq.h>
 
 / {
@@ -51,7 +52,7 @@
 	ether: ethernet at fde00000 {
 		compatible = "renesas,ether-r8a7778";
 		reg = <0xfde00000 0x400>;
-		interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7778_CLK_ETHER>;
 		power-domains = <&cpg_clocks>;
 		phy-mode = "rmii";
@@ -79,17 +80,17 @@
 			<0xfe780024 4>,
 			<0xfe780044 4>,
 			<0xfe780064 4>;
-		interrupts =   <0 27 IRQ_TYPE_LEVEL_HIGH
-				0 28 IRQ_TYPE_LEVEL_HIGH
-				0 29 IRQ_TYPE_LEVEL_HIGH
-				0 30 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts =   <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH
+				GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH
+				GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH
+				GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		sense-bitfield-width = <2>;
 	};
 
 	gpio0: gpio at ffc40000 {
 		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
 		reg = <0xffc40000 0x2c>;
-		interrupts = <0 103 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 0 32>;
@@ -100,7 +101,7 @@
 	gpio1: gpio at ffc41000 {
 		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
 		reg = <0xffc41000 0x2c>;
-		interrupts = <0 103 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 32 32>;
@@ -111,7 +112,7 @@
 	gpio2: gpio at ffc42000 {
 		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
 		reg = <0xffc42000 0x2c>;
-		interrupts = <0 103 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 64 32>;
@@ -122,7 +123,7 @@
 	gpio3: gpio at ffc43000 {
 		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
 		reg = <0xffc43000 0x2c>;
-		interrupts = <0 103 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 96 32>;
@@ -133,7 +134,7 @@
 	gpio4: gpio at ffc44000 {
 		compatible = "renesas,gpio-r8a7778", "renesas,gpio-rcar";
 		reg = <0xffc44000 0x2c>;
-		interrupts = <0 103 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 128 27>;
@@ -151,7 +152,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7778";
 		reg = <0xffc70000 0x1000>;
-		interrupts = <0 67 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_I2C0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -162,7 +163,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7778";
 		reg = <0xffc71000 0x1000>;
-		interrupts = <0 78 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_I2C1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -173,7 +174,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7778";
 		reg = <0xffc72000 0x1000>;
-		interrupts = <0 76 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_I2C2>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -184,7 +185,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7778";
 		reg = <0xffc73000 0x1000>;
-		interrupts = <0 77 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_I2C3>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -193,9 +194,9 @@
 	tmu0: timer at ffd80000 {
 		compatible = "renesas,tmu-r8a7778", "renesas,tmu";
 		reg = <0xffd80000 0x30>;
-		interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 33 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 34 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_TMU0>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -208,9 +209,9 @@
 	tmu1: timer at ffd81000 {
 		compatible = "renesas,tmu-r8a7778", "renesas,tmu";
 		reg = <0xffd81000 0x30>;
-		interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 37 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 38 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_TMU1>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -223,9 +224,9 @@
 	tmu2: timer at ffd82000 {
 		compatible = "renesas,tmu-r8a7778", "renesas,tmu";
 		reg = <0xffd82000 0x30>;
-		interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 41 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 42 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_TMU2>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -285,20 +286,20 @@
 		};
 
 		rcar_sound,ssi {
-			ssi3: ssi at 3 { interrupts = <0 0x85 IRQ_TYPE_LEVEL_HIGH>; };
-			ssi4: ssi at 4 { interrupts = <0 0x85 IRQ_TYPE_LEVEL_HIGH>; };
-			ssi5: ssi at 5 { interrupts = <0 0x86 IRQ_TYPE_LEVEL_HIGH>; };
-			ssi6: ssi at 6 { interrupts = <0 0x86 IRQ_TYPE_LEVEL_HIGH>; };
-			ssi7: ssi at 7 { interrupts = <0 0x86 IRQ_TYPE_LEVEL_HIGH>; };
-			ssi8: ssi at 8 { interrupts = <0 0x86 IRQ_TYPE_LEVEL_HIGH>; };
-			ssi9: ssi at 9 { interrupts = <0 0x86 IRQ_TYPE_LEVEL_HIGH>; };
+			ssi3: ssi at 3 { interrupts = <GIC_SPI 0x85 IRQ_TYPE_LEVEL_HIGH>; };
+			ssi4: ssi at 4 { interrupts = <GIC_SPI 0x85 IRQ_TYPE_LEVEL_HIGH>; };
+			ssi5: ssi at 5 { interrupts = <GIC_SPI 0x86 IRQ_TYPE_LEVEL_HIGH>; };
+			ssi6: ssi at 6 { interrupts = <GIC_SPI 0x86 IRQ_TYPE_LEVEL_HIGH>; };
+			ssi7: ssi at 7 { interrupts = <GIC_SPI 0x86 IRQ_TYPE_LEVEL_HIGH>; };
+			ssi8: ssi at 8 { interrupts = <GIC_SPI 0x86 IRQ_TYPE_LEVEL_HIGH>; };
+			ssi9: ssi at 9 { interrupts = <GIC_SPI 0x86 IRQ_TYPE_LEVEL_HIGH>; };
 		};
 	};
 
 	scif0: serial at ffe40000 {
 		compatible = "renesas,scif-r8a7778", "renesas,scif";
 		reg = <0xffe40000 0x100>;
-		interrupts = <0 70 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF0>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -308,7 +309,7 @@
 	scif1: serial at ffe41000 {
 		compatible = "renesas,scif-r8a7778", "renesas,scif";
 		reg = <0xffe41000 0x100>;
-		interrupts = <0 71 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF1>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -318,7 +319,7 @@
 	scif2: serial at ffe42000 {
 		compatible = "renesas,scif-r8a7778", "renesas,scif";
 		reg = <0xffe42000 0x100>;
-		interrupts = <0 72 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF2>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -328,7 +329,7 @@
 	scif3: serial at ffe43000 {
 		compatible = "renesas,scif-r8a7778", "renesas,scif";
 		reg = <0xffe43000 0x100>;
-		interrupts = <0 73 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF3>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -338,7 +339,7 @@
 	scif4: serial at ffe44000 {
 		compatible = "renesas,scif-r8a7778", "renesas,scif";
 		reg = <0xffe44000 0x100>;
-		interrupts = <0 74 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF4>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -348,7 +349,7 @@
 	scif5: serial at ffe45000 {
 		compatible = "renesas,scif-r8a7778", "renesas,scif";
 		reg = <0xffe45000 0x100>;
-		interrupts = <0 75 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF5>;
 		clock-names = "sci_ick";
 		power-domains = <&cpg_clocks>;
@@ -358,7 +359,7 @@
 	mmcif: mmc at ffe4e000 {
 		compatible = "renesas,sh-mmcif";
 		reg = <0xffe4e000 0x100>;
-		interrupts = <0 61 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7778_CLK_MMC>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -367,7 +368,7 @@
 	sdhi0: sd at ffe4c000 {
 		compatible = "renesas,sdhi-r8a7778";
 		reg = <0xffe4c000 0x100>;
-		interrupts = <0 87 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7778_CLK_SDHI0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -376,7 +377,7 @@
 	sdhi1: sd at ffe4d000 {
 		compatible = "renesas,sdhi-r8a7778";
 		reg = <0xffe4d000 0x100>;
-		interrupts = <0 88 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7778_CLK_SDHI1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -385,7 +386,7 @@
 	sdhi2: sd at ffe4f000 {
 		compatible = "renesas,sdhi-r8a7778";
 		reg = <0xffe4f000 0x100>;
-		interrupts = <0 86 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7778_CLK_SDHI2>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -394,7 +395,7 @@
 	hspi0: spi at fffc7000 {
 		compatible = "renesas,hspi-r8a7778", "renesas,hspi";
 		reg = <0xfffc7000 0x18>;
-		interrupts = <0 63 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_HSPI>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -405,7 +406,7 @@
 	hspi1: spi at fffc8000 {
 		compatible = "renesas,hspi-r8a7778", "renesas,hspi";
 		reg = <0xfffc8000 0x18>;
-		interrupts = <0 84 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_HSPI>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -416,7 +417,7 @@
 	hspi2: spi at fffc6000 {
 		compatible = "renesas,hspi-r8a7778", "renesas,hspi";
 		reg = <0xfffc6000 0x18>;
-		interrupts = <0 85 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_HSPI>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:19 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:19 +0100
Subject: [PATCH 29/68] ARM: dts: r8a7793: enable Audio DMAC peri peri via
 sound driver
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <3cf7452a5ae2a90448121feb29810bf437d72f02.1455303422.git.horms+renesas@verge.net.au>

Audio DMAC peri peri is no longer DMAEngine. it is supported by
sound driver. this patch enable it.

Base on work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 2c9ab9f18b41..ddbda9d2c177 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -1172,8 +1172,9 @@
 		reg =	<0 0xec500000 0 0x1000>, /* SCU */
 			<0 0xec5a0000 0 0x100>,  /* ADG */
 			<0 0xec540000 0 0x1000>, /* SSIU */
-			<0 0xec541000 0 0x280>;  /* SSI */
-		reg-names = "scu", "adg", "ssiu", "ssi";
+			<0 0xec541000 0 0x280>,  /* SSI */
+			<0 0xec740000 0 0x200>;  /* Audio DMAC peri peri*/
+		reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
 
 		clocks = <&mstp10_clks R8A7793_CLK_SSI_ALL>,
 			<&mstp10_clks R8A7793_CLK_SSI9>, <&mstp10_clks R8A7793_CLK_SSI8>,
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:21 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:21 +0100
Subject: [PATCH 31/68] ARM: dts: gose: enable sound DMA support in device tree
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <96c1b8d8507102759c1e232f371ff333811ccdd9.1455303422.git.horms+renesas@verge.net.au>

Enable DMA transfer to/from SSI in r8a7793/gose device tree.

     DMA
[MEM] -> [SSI]

     DMA
[MEM] <- [SSI]

Based on similar work for the r8a7791/koelsch by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 395ea63746ac..a4b2dcb8e73d 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -408,10 +408,10 @@
 };
 
 &ssi0 {
-	pio-transfer;
+	no-busif;
 };
 
 &ssi1 {
-	pio-transfer;
+	no-busif;
 	shared-pin;
 };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:18 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:18 +0100
Subject: [PATCH 28/68] ARM: dts: r8a7793: add audio DMAC to device tree
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <6708eb73183e226ddd73dae128239e76b3807390.1455303422.git.horms+renesas@verge.net.au>

Instantiate the two Audio DMA controllers in the r8a7791 device tree.

Based on similar work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 58 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index cb6251e71ef9..2c9ab9f18b41 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -301,6 +301,64 @@
 		dma-channels = <15>;
 	};
 
+	audma0: dma-controller at ec700000 {
+		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
+		reg = <0 0xec700000 0 0x10000>;
+		interrupts = <GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "error",
+				"ch0", "ch1", "ch2", "ch3",
+				"ch4", "ch5", "ch6", "ch7",
+				"ch8", "ch9", "ch10", "ch11",
+				"ch12";
+		clocks = <&mstp5_clks R8A7793_CLK_AUDIO_DMAC0>;
+		clock-names = "fck";
+		power-domains = <&cpg_clocks>;
+		#dma-cells = <1>;
+		dma-channels = <13>;
+	};
+
+	audma1: dma-controller at ec720000 {
+		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
+		reg = <0 0xec720000 0 0x10000>;
+		interrupts = <GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "error",
+				"ch0", "ch1", "ch2", "ch3",
+				"ch4", "ch5", "ch6", "ch7",
+				"ch8", "ch9", "ch10", "ch11",
+				"ch12";
+		clocks = <&mstp5_clks R8A7793_CLK_AUDIO_DMAC1>;
+		clock-names = "fck";
+		power-domains = <&cpg_clocks>;
+		#dma-cells = <1>;
+		dma-channels = <13>;
+	};
+
 	/* The memory map in the User's Manual maps the cores to bus numbers */
 	i2c0: i2c at e6508000 {
 		#address-cells = <1>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:20 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:20 +0100
Subject: [PATCH 30/68] ARM: dts: gose: Enable sound PIO support in device tree
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <f8905ce841deb22b43c6cc1f2ef47638e61bbec6.1455303422.git.horms+renesas@verge.net.au>

Enable sound PIO support in the r8a7793/gose device tree.

Based on similar work for the r8a7791/koelsch by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 77 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 0b4cc8d99390..395ea63746ac 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -8,6 +8,17 @@
  * kind, whether express or implied.
  */
 
+/*
+ * SSI-AK4643
+ *
+ * SW1: 1: AK4643
+ *      2: CN22
+ *      3: ADV7511
+ *
+ * This command is required when Playback/Capture
+ *
+ *	amixer set "LINEOUT Mixer DACL" on
+ */
 /dts-v1/;
 #include "r8a7793.dtsi"
 #include <dt-bindings/gpio/gpio.h>
@@ -130,6 +141,30 @@
 		};
 	};
 
+	audio_clock: clock {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <11289600>;
+		clock-output-names = "audio_clock";
+	};
+
+	rsnd_ak4643: sound {
+		compatible = "simple-audio-card";
+
+		simple-audio-card,format = "left_j";
+		simple-audio-card,bitclock-master = <&sndcodec>;
+		simple-audio-card,frame-master = <&sndcodec>;
+
+		sndcpu: simple-audio-card,cpu {
+			sound-dai = <&rcar_sound>;
+		};
+
+		sndcodec: simple-audio-card,codec {
+			sound-dai = <&ak4643>;
+			clocks = <&audio_clock>;
+		};
+	};
+
 	hdmi-out {
 		compatible = "hdmi-connector";
 		type = "a";
@@ -218,6 +253,16 @@
 		renesas,groups = "qspi_ctrl", "qspi_data4";
 		renesas,function = "qspi";
 	};
+
+	sound_pins: sound {
+		renesas,groups = "ssi0129_ctrl", "ssi0_data", "ssi1_data";
+		renesas,function = "ssi";
+	};
+
+	sound_clk_pins: sound_clk {
+		renesas,groups = "audio_clk_a";
+		renesas,function = "audio_clk";
+	};
 };
 
 &ether {
@@ -300,6 +345,12 @@
 	status = "okay";
 	clock-frequency = <100000>;
 
+	ak4643: codec at 12 {
+		compatible = "asahi-kasei,ak4643";
+		#sound-dai-cells = <0>;
+		reg = <0x12>;
+	};
+
 	hdmi at 39 {
 		compatible = "adi,adv7511w";
 		reg = <0x39>;
@@ -338,3 +389,29 @@
 		pagesize = <16>;
 	};
 };
+
+&rcar_sound {
+	pinctrl-0 = <&sound_pins &sound_clk_pins>;
+	pinctrl-names = "default";
+
+	/* Single DAI */
+	#sound-dai-cells = <0>;
+
+	status = "okay";
+
+	rcar_sound,dai {
+		dai0 {
+			playback = <&ssi0>;
+			capture  = <&ssi1>;
+		};
+	};
+};
+
+&ssi0 {
+	pio-transfer;
+};
+
+&ssi1 {
+	pio-transfer;
+	shared-pin;
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:27 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:27 +0100
Subject: [PATCH 37/68] ARM: dts: sh73a0: use GIC_* defines
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <10bbad96d4bc135d0bb0ea64e996a8870d42d989.1455303422.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in sh73a0 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/sh73a0.dtsi | 168 +++++++++++++++++++++---------------------
 1 file changed, 84 insertions(+), 84 deletions(-)

diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index 3a6056f9f0d2..453280c41d27 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -58,7 +58,7 @@
 	L2: cache-controller {
 		compatible = "arm,pl310-cache";
 		reg = <0xf0100000 0x1000>;
-		interrupts = <0 44 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
 		power-domains = <&pd_a3sm>;
 		arm,data-latency = <3 3 3>;
 		arm,tag-latency = <2 2 2>;
@@ -70,8 +70,8 @@
 	sbsc2: memory-controller at fb400000 {
 		compatible = "renesas,sbsc-sh73a0";
 		reg = <0xfb400000 0x400>;
-		interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 38 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "sec", "temp";
 		power-domains = <&pd_a4bc1>;
 	};
@@ -79,22 +79,22 @@
 	sbsc1: memory-controller at fe400000 {
 		compatible = "renesas,sbsc-sh73a0";
 		reg = <0xfe400000 0x400>;
-		interrupts = <0 35 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 36 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "sec", "temp";
 		power-domains = <&pd_a4bc0>;
 	};
 
 	pmu {
 		compatible = "arm,cortex-a9-pmu";
-		interrupts = <0 55 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 56 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
 	};
 
 	cmt1: timer at e6138000 {
 		compatible = "renesas,cmt-48-sh73a0", "renesas,cmt-48";
 		reg = <0xe6138000 0x200>;
-		interrupts = <0 65 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_CMT1>;
 		clock-names = "fck";
 		power-domains = <&pd_c5>;
@@ -113,14 +113,14 @@
 			<0xe6900020 1>,
 			<0xe6900040 1>,
 			<0xe6900060 1>;
-		interrupts = <0 1 IRQ_TYPE_LEVEL_HIGH
-			      0 2 IRQ_TYPE_LEVEL_HIGH
-			      0 3 IRQ_TYPE_LEVEL_HIGH
-			      0 4 IRQ_TYPE_LEVEL_HIGH
-			      0 5 IRQ_TYPE_LEVEL_HIGH
-			      0 6 IRQ_TYPE_LEVEL_HIGH
-			      0 7 IRQ_TYPE_LEVEL_HIGH
-			      0 8 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks SH73A0_CLK_INTCA0>;
 		power-domains = <&pd_a4s>;
 		control-parent;
@@ -135,14 +135,14 @@
 			<0xe6900024 1>,
 			<0xe6900044 1>,
 			<0xe6900064 1>;
-		interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH
-			      0 10 IRQ_TYPE_LEVEL_HIGH
-			      0 11 IRQ_TYPE_LEVEL_HIGH
-			      0 12 IRQ_TYPE_LEVEL_HIGH
-			      0 13 IRQ_TYPE_LEVEL_HIGH
-			      0 14 IRQ_TYPE_LEVEL_HIGH
-			      0 15 IRQ_TYPE_LEVEL_HIGH
-			      0 16 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks SH73A0_CLK_INTCA0>;
 		power-domains = <&pd_a4s>;
 		control-parent;
@@ -157,14 +157,14 @@
 			<0xe6900028 1>,
 			<0xe6900048 1>,
 			<0xe6900068 1>;
-		interrupts = <0 17 IRQ_TYPE_LEVEL_HIGH
-			      0 18 IRQ_TYPE_LEVEL_HIGH
-			      0 19 IRQ_TYPE_LEVEL_HIGH
-			      0 20 IRQ_TYPE_LEVEL_HIGH
-			      0 21 IRQ_TYPE_LEVEL_HIGH
-			      0 22 IRQ_TYPE_LEVEL_HIGH
-			      0 23 IRQ_TYPE_LEVEL_HIGH
-			      0 24 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks SH73A0_CLK_INTCA0>;
 		power-domains = <&pd_a4s>;
 		control-parent;
@@ -179,14 +179,14 @@
 			<0xe690002c 1>,
 			<0xe690004c 1>,
 			<0xe690006c 1>;
-		interrupts = <0 25 IRQ_TYPE_LEVEL_HIGH
-			      0 26 IRQ_TYPE_LEVEL_HIGH
-			      0 27 IRQ_TYPE_LEVEL_HIGH
-			      0 28 IRQ_TYPE_LEVEL_HIGH
-			      0 29 IRQ_TYPE_LEVEL_HIGH
-			      0 30 IRQ_TYPE_LEVEL_HIGH
-			      0 31 IRQ_TYPE_LEVEL_HIGH
-			      0 32 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks SH73A0_CLK_INTCA0>;
 		power-domains = <&pd_a4s>;
 		control-parent;
@@ -197,10 +197,10 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-sh73a0", "renesas,rmobile-iic";
 		reg = <0xe6820000 0x425>;
-		interrupts = <0 167 IRQ_TYPE_LEVEL_HIGH
-			      0 168 IRQ_TYPE_LEVEL_HIGH
-			      0 169 IRQ_TYPE_LEVEL_HIGH
-			      0 170 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks SH73A0_CLK_IIC0>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -211,10 +211,10 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-sh73a0", "renesas,rmobile-iic";
 		reg = <0xe6822000 0x425>;
-		interrupts = <0 51 IRQ_TYPE_LEVEL_HIGH
-			      0 52 IRQ_TYPE_LEVEL_HIGH
-			      0 53 IRQ_TYPE_LEVEL_HIGH
-			      0 54 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_IIC1>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -225,10 +225,10 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-sh73a0", "renesas,rmobile-iic";
 		reg = <0xe6824000 0x425>;
-		interrupts = <0 171 IRQ_TYPE_LEVEL_HIGH
-			      0 172 IRQ_TYPE_LEVEL_HIGH
-			      0 173 IRQ_TYPE_LEVEL_HIGH
-			      0 174 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks SH73A0_CLK_IIC2>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -239,10 +239,10 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-sh73a0", "renesas,rmobile-iic";
 		reg = <0xe6826000 0x425>;
-		interrupts = <0 183 IRQ_TYPE_LEVEL_HIGH
-			      0 184 IRQ_TYPE_LEVEL_HIGH
-			      0 185 IRQ_TYPE_LEVEL_HIGH
-			      0 186 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks SH73A0_CLK_IIC3>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -253,10 +253,10 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-sh73a0", "renesas,rmobile-iic";
 		reg = <0xe6828000 0x425>;
-		interrupts = <0 187 IRQ_TYPE_LEVEL_HIGH
-			      0 188 IRQ_TYPE_LEVEL_HIGH
-			      0 189 IRQ_TYPE_LEVEL_HIGH
-			      0 190 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks SH73A0_CLK_IIC4>;
 		power-domains = <&pd_c5>;
 		status = "disabled";
@@ -265,8 +265,8 @@
 	mmcif: mmc at e6bd0000 {
 		compatible = "renesas,sh-mmcif";
 		reg = <0xe6bd0000 0x100>;
-		interrupts = <0 140 IRQ_TYPE_LEVEL_HIGH
-			      0 141 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_MMCIF0>;
 		power-domains = <&pd_a3sp>;
 		reg-io-width = <4>;
@@ -276,7 +276,7 @@
 	msiof0: spi at e6e20000 {
 		compatible = "renesas,msiof-sh73a0", "renesas,sh-mobile-msiof";
 		reg = <0xe6e20000 0x0064>;
-		interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks SH73A0_CLK_MSIOF0>;
 		power-domains = <&pd_a3sp>;
 		#address-cells = <1>;
@@ -287,7 +287,7 @@
 	msiof1: spi at e6e10000 {
 		compatible = "renesas,msiof-sh73a0", "renesas,sh-mobile-msiof";
 		reg = <0xe6e10000 0x0064>;
-		interrupts = <0 77 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_MSIOF1>;
 		power-domains = <&pd_a3sp>;
 		#address-cells = <1>;
@@ -298,7 +298,7 @@
 	msiof2: spi at e6e00000 {
 		compatible = "renesas,msiof-sh73a0", "renesas,sh-mobile-msiof";
 		reg = <0xe6e00000 0x0064>;
-		interrupts = <0 76 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_MSIOF2>;
 		power-domains = <&pd_a3sp>;
 		#address-cells = <1>;
@@ -309,7 +309,7 @@
 	msiof3: spi at e6c90000 {
 		compatible = "renesas,msiof-sh73a0", "renesas,sh-mobile-msiof";
 		reg = <0xe6c90000 0x0064>;
-		interrupts = <0 59 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_MSIOF3>;
 		power-domains = <&pd_a3sp>;
 		#address-cells = <1>;
@@ -320,9 +320,9 @@
 	sdhi0: sd at ee100000 {
 		compatible = "renesas,sdhi-sh73a0";
 		reg = <0xee100000 0x100>;
-		interrupts = <0 83 IRQ_TYPE_LEVEL_HIGH
-			      0 84 IRQ_TYPE_LEVEL_HIGH
-			      0 85 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_SDHI0>;
 		power-domains = <&pd_a3sp>;
 		cap-sd-highspeed;
@@ -333,8 +333,8 @@
 	sdhi1: sd at ee120000 {
 		compatible = "renesas,sdhi-sh73a0";
 		reg = <0xee120000 0x100>;
-		interrupts = <0 88 IRQ_TYPE_LEVEL_HIGH
-			      0 89 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_SDHI1>;
 		power-domains = <&pd_a3sp>;
 		toshiba,mmc-wrprotect-disable;
@@ -345,8 +345,8 @@
 	sdhi2: sd at ee140000 {
 		compatible = "renesas,sdhi-sh73a0";
 		reg = <0xee140000 0x100>;
-		interrupts = <0 104 IRQ_TYPE_LEVEL_HIGH
-			      0 105 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_SDHI2>;
 		power-domains = <&pd_a3sp>;
 		toshiba,mmc-wrprotect-disable;
@@ -357,7 +357,7 @@
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6c40000 0x100>;
-		interrupts = <0 72 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA0>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -367,7 +367,7 @@
 	scifa1: serial at e6c50000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6c50000 0x100>;
-		interrupts = <0 73 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA1>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -377,7 +377,7 @@
 	scifa2: serial at e6c60000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6c60000 0x100>;
-		interrupts = <0 74 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA2>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -387,7 +387,7 @@
 	scifa3: serial at e6c70000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6c70000 0x100>;
-		interrupts = <0 75 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA3>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -397,7 +397,7 @@
 	scifa4: serial at e6c80000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6c80000 0x100>;
-		interrupts = <0 78 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA4>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -407,7 +407,7 @@
 	scifa5: serial at e6cb0000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6cb0000 0x100>;
-		interrupts = <0 79 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA5>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -417,7 +417,7 @@
 	scifa6: serial at e6cc0000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6cc0000 0x100>;
-		interrupts = <0 156 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_SCIFA6>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -427,7 +427,7 @@
 	scifa7: serial at e6cd0000 {
 		compatible = "renesas,scifa-sh73a0", "renesas,scifa";
 		reg = <0xe6cd0000 0x100>;
-		interrupts = <0 143 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA7>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -437,7 +437,7 @@
 	scifb: serial at e6c30000 {
 		compatible = "renesas,scifb-sh73a0", "renesas,scifb";
 		reg = <0xe6c30000 0x100>;
-		interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFB>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -579,7 +579,7 @@
 		#sound-dai-cells = <1>;
 		compatible = "renesas,fsi2-sh73a0", "renesas,sh_fsi2";
 		reg = <0xec230000 0x400>;
-		interrupts = <0 146 0x4>;
+		interrupts = <GIC_SPI 146 0x4>;
 		power-domains = <&pd_a4mp>;
 		status = "disabled";
 	};
@@ -591,7 +591,7 @@
 		#size-cells = <1>;
 		ranges = <0 0 0x20000000>;
 		reg = <0xfec10000 0x400>;
-		interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&zb_clk>;
 		power-domains = <&pd_a4s>;
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:38 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:38 +0100
Subject: [PATCH 48/68] ARM: dts: r8a7740: Rename the serial port clock to fck
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <0995b9a8d618b7e2a57eeb191bdb7f11dd18ba3e.1455303422.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7740.dtsi | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 36bcb39cca03..995fbda74b7a 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -214,7 +214,7 @@
 		reg = <0xe6c40000 0x100>;
 		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -224,7 +224,7 @@
 		reg = <0xe6c50000 0x100>;
 		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -234,7 +234,7 @@
 		reg = <0xe6c60000 0x100>;
 		interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -244,7 +244,7 @@
 		reg = <0xe6c70000 0x100>;
 		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -254,7 +254,7 @@
 		reg = <0xe6c80000 0x100>;
 		interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -264,7 +264,7 @@
 		reg = <0xe6cb0000 0x100>;
 		interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -274,7 +274,7 @@
 		reg = <0xe6cc0000 0x100>;
 		interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA6>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -284,7 +284,7 @@
 		reg = <0xe6cd0000 0x100>;
 		interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA7>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -294,7 +294,7 @@
 		reg = <0xe6c30000 0x100>;
 		interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFB>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:47 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:47 +0100
Subject: [PATCH 57/68] ARM: dts: r8a7790: Add BRG support for (H)SCIF
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <42af65e88df70a32c3c1afa0e6d35022b379c6ae.1455303422.git.horms+renesas@verge.net.au>

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

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depends on
the actual board.

Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF and HSCIF device nodes.

This increases the range and accuracy of supported baud rates on
(H)SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 29 +++++++++++++++++++++--------
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index c5672745a1e5..c9583fa6cae7 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -667,8 +667,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7790_CLK_SCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7790_CLK_SCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -680,8 +681,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7790_CLK_SCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7790_CLK_SCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -693,8 +695,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7790_CLK_HSCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7790_CLK_HSCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -706,8 +709,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7790_CLK_HSCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7790_CLK_HSCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -996,6 +1000,15 @@
 			clock-output-names = "audio_clk_c";
 		};
 
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+			status = "disabled";
+		};
+
 		/* External USB clock - can be overridden by the board */
 		usb_extal_clk: usb_extal_clk {
 			compatible = "fixed-clock";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:49 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:49 +0100
Subject: [PATCH 59/68] ARM: dts: r8a7793: Add BRG support for SCIF
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <166d8ca693a9a1f4f3285ba03d9aebe7f679753f.1455303422.git.horms+renesas@verge.net.au>

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

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depends on
the actual board.

Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF and HSCIF device nodes.

This increases the range and accuracy of supported baud rates on
(H)SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 07af584915c6..45dba1c79a43 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -600,8 +600,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_SCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_SCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -613,8 +614,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_SCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_SCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -626,8 +628,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_SCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_SCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -639,8 +642,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_SCIF3>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_SCIF3>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -652,8 +656,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_SCIF4>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_SCIF4>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -665,8 +670,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_SCIF5>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_SCIF5>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -678,8 +684,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_HSCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_HSCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -691,8 +698,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_HSCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_HSCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -704,8 +712,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7793_CLK_HSCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7793_CLK_HSCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -805,6 +814,15 @@
 			clock-output-names = "audio_clk_c";
 		};
 
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+			status = "disabled";
+		};
+
 		/* Special CPG clocks */
 		cpg_clocks: cpg_clocks at e6150000 {
 			compatible = "renesas,r8a7793-cpg-clocks",
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:51 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:51 +0100
Subject: [PATCH 61/68] ARM: dts: alt: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <8a758a9493d8cac4afde82918590a11bbb24c85c.1455303422.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794-alt.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
index 773f304d1142..ca9bc4fff287 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -103,6 +103,9 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	du_pins: du {
 		renesas,groups = "du1_rgb666", "du1_sync", "du1_disp", "du1_dotclkout0";
 		renesas,function = "du";
@@ -113,6 +116,11 @@
 		renesas,function = "scif2";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	ether_pins: ether {
 		renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
 		renesas,function = "eth";
@@ -205,6 +213,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &qspi {
 	pinctrl-0 = <&qspi_pins>;
 	pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:50 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:50 +0100
Subject: [PATCH 60/68] ARM: dts: r8a7794: Add BRG support for (H)SCIF
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <a864446f9662be8aba43e2969c9f1264e22aa500.1455303422.git.horms+renesas@verge.net.au>

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

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depends on
the actual board.

Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF and HSCIF device nodes.

This increases the range and accuracy of supported baud rates on
(H)SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794.dtsi | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index b03a77b3d22f..7d4c5597af5b 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -403,8 +403,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_SCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_SCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -416,8 +417,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_SCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_SCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -429,8 +431,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_SCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_SCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -442,8 +445,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_SCIF3>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_SCIF3>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -455,8 +459,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_SCIF4>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_SCIF4>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -468,8 +473,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_SCIF5>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_SCIF5>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -481,8 +487,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_HSCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_HSCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -494,8 +501,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_HSCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_HSCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -507,8 +515,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7794_CLK_HSCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7794_CLK_HSCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -815,6 +824,15 @@
 			clock-output-names = "extal";
 		};
 
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+			status = "disabled";
+		};
+
 		/* Special CPG clocks */
 		cpg_clocks: cpg_clocks at e6150000 {
 			compatible = "renesas,r8a7794-cpg-clocks",
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:52 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:52 +0100
Subject: [PATCH 62/68] ARM: dts: bockw: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <33ef9688ae45d19bf11c75a7c403a4f20804720d.1455303422.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7778-bockw.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7778-bockw.dts b/arch/arm/boot/dts/r8a7778-bockw.dts
index a52b359e2ae2..21e3b9dda2da 100644
--- a/arch/arm/boot/dts/r8a7778-bockw.dts
+++ b/arch/arm/boot/dts/r8a7778-bockw.dts
@@ -126,11 +126,19 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	scif0_pins: serial0 {
 		renesas,groups = "scif0_data_a", "scif0_ctrl";
 		renesas,function = "scif0";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	mmc_pins: mmc {
 		renesas,groups = "mmc_data8", "mmc_ctrl";
 		renesas,function = "mmc";
@@ -217,3 +225,8 @@
 
 	status = "okay";
 };
+
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:53 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:53 +0100
Subject: [PATCH 63/68] ARM: dts: gose: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <81a81ba9412c2c29309abd8752bcf771c22335a1.1455303422.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 2fa052036dbc..cfe142c2ba38 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -236,6 +236,9 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	i2c2_pins: i2c2 {
 		renesas,groups = "i2c2";
 		renesas,function = "i2c2";
@@ -256,6 +259,11 @@
 		renesas,function = "scif1";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	ether_pins: ether {
 		renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
 		renesas,function = "eth";
@@ -316,6 +324,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &qspi {
 	pinctrl-0 = <&qspi_pins>;
 	pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:56 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:56 +0100
Subject: [PATCH 66/68] ARM: dts: marzen: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <e50b5ac88d3e1c4cf6f74797be6f13bc9109b037.1455303422.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779-marzen.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7779-marzen.dts b/arch/arm/boot/dts/r8a7779-marzen.dts
index fe396c8d58db..e111d35d02ae 100644
--- a/arch/arm/boot/dts/r8a7779-marzen.dts
+++ b/arch/arm/boot/dts/r8a7779-marzen.dts
@@ -165,6 +165,9 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	du_pins: du {
 		du0 {
 			renesas,groups = "du0_rgb888", "du0_sync_1", "du0_clk_out_0";
@@ -176,6 +179,11 @@
 		};
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk_b";
+		renesas,function = "scif_clk";
+	};
+
 	ethernet_pins: ethernet {
 		intc {
 			renesas,groups = "intc_irq1_b";
@@ -222,6 +230,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &sdhi0 {
 	pinctrl-0 = <&sdhi0_pins>;
 	pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:54 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:54 +0100
Subject: [PATCH 64/68] ARM: dts: koelsch: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <338f7ebf46e184746e63bcb93b3e5dbee95564a3.1455303422.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates:
  - SCIF:
      - Supports now 50, 75, 110, 1152000, 1500000, 2000000, and
        4000000 bps,
      - Perfect match for standard 50-460800, and 9216000 bps.
      - More accurate 576000 bps.
  - HSCIF:
      - Supports now 50, 75, 110, 134, 150, and 200 bps,
      - Perfect match for standard 50-460800, and 9216000 bps.
      - More accurate 576000, 1152000, 3000000, 3500000, and 4000000
	bps.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 45256f3cc835..0ad71b81d3a2 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -320,6 +320,9 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	i2c2_pins: i2c2 {
 		renesas,groups = "i2c2";
 		renesas,function = "i2c2";
@@ -340,6 +343,11 @@
 		renesas,function = "scif1";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	ether_pins: ether {
 		renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
 		renesas,function = "eth";
@@ -440,6 +448,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &sdhi0 {
 	pinctrl-0 = <&sdhi0_pins>;
 	pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:55 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:55 +0100
Subject: [PATCH 65/68] ARM: dts: lager: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <1781460c9accb106b0887985754b63be1b4c63f8.1455303422.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790-lager.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index 052dcee4790d..cdc0414f5f07 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -291,6 +291,9 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	du_pins: du {
 		renesas,groups = "du_rgb666", "du_sync_1", "du_clk_out_0";
 		renesas,function = "du";
@@ -301,6 +304,11 @@
 		renesas,function = "scif0";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	ether_pins: ether {
 		renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
 		renesas,function = "eth";
@@ -485,6 +493,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &msiof1 {
 	pinctrl-0 = <&msiof1_pins>;
 	pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:57 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:57 +0100
Subject: [PATCH 67/68] ARM: dts: porter: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <19417bd9c5112f58ea63e97ba72edabd5e1cc0fe.1455303422.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791-porter.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
index 5015eaa0ae50..ed1f6f884e2b 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -143,11 +143,19 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	scif0_pins: serial0 {
 		renesas,groups = "scif0_data_d";
 		renesas,function = "scif0";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	ether_pins: ether {
 		renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
 		renesas,function = "eth";
@@ -221,6 +229,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &ether {
 	pinctrl-0 = <&ether_pins &phy1_pins>;
 	pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:58 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:58 +0100
Subject: [PATCH 68/68] ARM: dts: silk: Enable SCIF_CLK frequency and pins
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <c3373b09ba0391bcd9e992b0a2ce52d48d33e47b.1455303422.git.horms+renesas@verge.net.au>

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

Add and enable the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.

This increases the range and accuracy of supported baud rates.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794-silk.dts | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
index 98b8bcca84da..66f077a3ca41 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -126,11 +126,19 @@
 };
 
 &pfc {
+	pinctrl-0 = <&scif_clk_pins>;
+	pinctrl-names = "default";
+
 	scif2_pins: serial2 {
 		renesas,groups = "scif2_data";
 		renesas,function = "scif2";
 	};
 
+	scif_clk_pins: scif_clk {
+		renesas,groups = "scif_clk";
+		renesas,function = "scif_clk";
+	};
+
 	ether_pins: ether {
 		renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
 		renesas,function = "eth";
@@ -184,6 +192,11 @@
 	status = "okay";
 };
 
+&scif_clk {
+	clock-frequency = <14745600>;
+	status = "okay";
+};
+
 &ether {
 	pinctrl-0 = <&ether_pins &phy1_pins>;
 	pinctrl-names = "default";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:06:19 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:06:19 +0100
Subject: [PATCH 1/8] ARM: shmobile: r8a7779: Remove remainings of removed SCU
 boot setup code
In-Reply-To: <cover.1455303757.git.horms+renesas@verge.net.au>
References: <cover.1455303757.git.horms+renesas@verge.net.au>
Message-ID: <48735f69b9b027786e1fac25b76976fb818f8335.1455303757.git.horms+renesas@verge.net.au>

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

Commit 0ca2894b5a900709 ("ARM: shmobile: Use shared SCU SMP boot code on
r8a7779") obsoleted the r8a7779-specific SCU boot code, but forgot to
remove the setup of shmobile_boot_fn and shmobile_boot_arg, which is
overwritten by shmobile_smp_scu_prepare_cpus().

Note that shmobile_scu_base wasn't initialized at that point yet anyway.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/smp-r8a7779.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/smp-r8a7779.c b/arch/arm/mach-shmobile/smp-r8a7779.c
index b854fe2095ad..0b024a9dbd43 100644
--- a/arch/arm/mach-shmobile/smp-r8a7779.c
+++ b/arch/arm/mach-shmobile/smp-r8a7779.c
@@ -92,8 +92,6 @@ static void __init r8a7779_smp_prepare_cpus(unsigned int max_cpus)
 {
 	/* Map the reset vector (in headsmp-scu.S, headsmp.S) */
 	__raw_writel(__pa(shmobile_boot_vector), AVECR);
-	shmobile_boot_fn = virt_to_phys(shmobile_boot_scu);
-	shmobile_boot_arg = (unsigned long)shmobile_scu_base;
 
 	/* setup r8a7779 specific SCU bits */
 	shmobile_scu_base = IOMEM(R8A7779_SCU_BASE);
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:04 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:04 +0100
Subject: [PATCH 14/68] ARM: dts: r8a7793: use GIC_* defines
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <214e8481fe1fef5e88f80f0da6c9bfbd1963099f.1455303422.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7793 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7793.dtsi | 216 ++++++++++++++++++++---------------------
 1 file changed, 108 insertions(+), 108 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 0ce7cc420c9d..ea1196b99d52 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -63,13 +63,13 @@
 			<0 0xf1002000 0 0x1000>,
 			<0 0xf1004000 0 0x2000>,
 			<0 0xf1006000 0 0x2000>;
-		interrupts = <1 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
 	};
 
 	gpio0: gpio at e6050000 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6050000 0 0x50>;
-		interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 0 32>;
@@ -82,7 +82,7 @@
 	gpio1: gpio at e6051000 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6051000 0 0x50>;
-		interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 32 26>;
@@ -95,7 +95,7 @@
 	gpio2: gpio at e6052000 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6052000 0 0x50>;
-		interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 64 32>;
@@ -108,7 +108,7 @@
 	gpio3: gpio at e6053000 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6053000 0 0x50>;
-		interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 96 32>;
@@ -121,7 +121,7 @@
 	gpio4: gpio at e6054000 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6054000 0 0x50>;
-		interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 128 32>;
@@ -134,7 +134,7 @@
 	gpio5: gpio at e6055000 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6055000 0 0x50>;
-		interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 160 32>;
@@ -147,7 +147,7 @@
 	gpio6: gpio at e6055400 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6055400 0 0x50>;
-		interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 192 32>;
@@ -160,7 +160,7 @@
 	gpio7: gpio at e6055800 {
 		compatible = "renesas,gpio-r8a7793", "renesas,gpio-rcar";
 		reg = <0 0xe6055800 0 0x50>;
-		interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 224 26>;
@@ -173,24 +173,24 @@
 	thermal at e61f0000 {
 		compatible = "renesas,thermal-r8a7793", "renesas,rcar-thermal";
 		reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
-		interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks R8A7793_CLK_THERMAL>;
 		power-domains = <&cpg_clocks>;
 	};
 
 	timer {
 		compatible = "arm,armv7-timer";
-		interrupts = <1 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
 	};
 
 	cmt0: timer at ffca0000 {
 		compatible = "renesas,cmt-48-r8a7793", "renesas,cmt-48-gen2";
 		reg = <0 0xffca0000 0 0x1004>;
-		interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 143 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7793_CLK_CMT0>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -203,14 +203,14 @@
 	cmt1: timer at e6130000 {
 		compatible = "renesas,cmt-48-r8a7793", "renesas,cmt-48-gen2";
 		reg = <0 0xe6130000 0 0x1004>;
-		interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 121 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 122 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 123 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 124 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 125 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 126 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 127 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7793_CLK_CMT1>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -225,16 +225,16 @@
 		#interrupt-cells = <2>;
 		interrupt-controller;
 		reg = <0 0xe61c0000 0 0x200>;
-		interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 1 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 2 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 3 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 12 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 13 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 14 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 15 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 16 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 17 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A7793_CLK_IRQC>;
 		power-domains = <&cpg_clocks>;
 	};
@@ -242,22 +242,22 @@
 	dmac0: dma-controller at e6700000 {
 		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
 		reg = <0 0xe6700000 0 0x20000>;
-		interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH
-			      0 200 IRQ_TYPE_LEVEL_HIGH
-			      0 201 IRQ_TYPE_LEVEL_HIGH
-			      0 202 IRQ_TYPE_LEVEL_HIGH
-			      0 203 IRQ_TYPE_LEVEL_HIGH
-			      0 204 IRQ_TYPE_LEVEL_HIGH
-			      0 205 IRQ_TYPE_LEVEL_HIGH
-			      0 206 IRQ_TYPE_LEVEL_HIGH
-			      0 207 IRQ_TYPE_LEVEL_HIGH
-			      0 208 IRQ_TYPE_LEVEL_HIGH
-			      0 209 IRQ_TYPE_LEVEL_HIGH
-			      0 210 IRQ_TYPE_LEVEL_HIGH
-			      0 211 IRQ_TYPE_LEVEL_HIGH
-			      0 212 IRQ_TYPE_LEVEL_HIGH
-			      0 213 IRQ_TYPE_LEVEL_HIGH
-			      0 214 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -273,22 +273,22 @@
 	dmac1: dma-controller at e6720000 {
 		compatible = "renesas,dmac-r8a7793", "renesas,rcar-dmac";
 		reg = <0 0xe6720000 0 0x20000>;
-		interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
-			      0 216 IRQ_TYPE_LEVEL_HIGH
-			      0 217 IRQ_TYPE_LEVEL_HIGH
-			      0 218 IRQ_TYPE_LEVEL_HIGH
-			      0 219 IRQ_TYPE_LEVEL_HIGH
-			      0 308 IRQ_TYPE_LEVEL_HIGH
-			      0 309 IRQ_TYPE_LEVEL_HIGH
-			      0 310 IRQ_TYPE_LEVEL_HIGH
-			      0 311 IRQ_TYPE_LEVEL_HIGH
-			      0 312 IRQ_TYPE_LEVEL_HIGH
-			      0 313 IRQ_TYPE_LEVEL_HIGH
-			      0 314 IRQ_TYPE_LEVEL_HIGH
-			      0 315 IRQ_TYPE_LEVEL_HIGH
-			      0 316 IRQ_TYPE_LEVEL_HIGH
-			      0 317 IRQ_TYPE_LEVEL_HIGH
-			      0 318 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -307,7 +307,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7793";
 		reg = <0 0xe6508000 0 0x40>;
-		interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_I2C0>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -319,7 +319,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7793";
 		reg = <0 0xe6518000 0 0x40>;
-		interrupts = <0 288 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_I2C1>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -331,7 +331,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7793";
 		reg = <0 0xe6530000 0 0x40>;
-		interrupts = <0 286 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_I2C2>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -343,7 +343,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7793";
 		reg = <0 0xe6540000 0 0x40>;
-		interrupts = <0 290 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_I2C3>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -355,7 +355,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7793";
 		reg = <0 0xe6520000 0 0x40>;
-		interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_I2C4>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -368,7 +368,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7793";
 		reg = <0 0xe6528000 0 0x40>;
-		interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_I2C5>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <110>;
@@ -381,7 +381,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
 		reg = <0 0xe60b0000 0 0x425>;
-		interrupts = <0 173 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_IICDVFS>;
 		dmas = <&dmac0 0x77>, <&dmac0 0x78>;
 		dma-names = "tx", "rx";
@@ -394,7 +394,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
 		reg = <0 0xe6500000 0 0x425>;
-		interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7793_CLK_IIC0>;
 		dmas = <&dmac0 0x61>, <&dmac0 0x62>;
 		dma-names = "tx", "rx";
@@ -407,7 +407,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
 		reg = <0 0xe6510000 0 0x425>;
-		interrupts = <0 175 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7793_CLK_IIC1>;
 		dmas = <&dmac0 0x65>, <&dmac0 0x66>;
 		dma-names = "tx", "rx";
@@ -423,7 +423,7 @@
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
-		interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
@@ -435,7 +435,7 @@
 	scifa1: serial at e6c50000 {
 		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
-		interrupts = <0 145 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
@@ -447,7 +447,7 @@
 	scifa2: serial at e6c60000 {
 		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
-		interrupts = <0 151 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
@@ -459,7 +459,7 @@
 	scifa3: serial at e6c70000 {
 		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
 		reg = <0 0xe6c70000 0 64>;
-		interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA3>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1b>, <&dmac0 0x1c>;
@@ -471,7 +471,7 @@
 	scifa4: serial at e6c78000 {
 		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
 		reg = <0 0xe6c78000 0 64>;
-		interrupts = <0 30 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA4>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1f>, <&dmac0 0x20>;
@@ -483,7 +483,7 @@
 	scifa5: serial at e6c80000 {
 		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
 		reg = <0 0xe6c80000 0 64>;
-		interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA5>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x23>, <&dmac0 0x24>;
@@ -495,7 +495,7 @@
 	scifb0: serial at e6c20000 {
 		compatible = "renesas,scifb-r8a7793", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
-		interrupts = <0 148 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
@@ -507,7 +507,7 @@
 	scifb1: serial at e6c30000 {
 		compatible = "renesas,scifb-r8a7793", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
@@ -519,7 +519,7 @@
 	scifb2: serial at e6ce0000 {
 		compatible = "renesas,scifb-r8a7793", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
-		interrupts = <0 150 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
@@ -531,7 +531,7 @@
 	scif0: serial at e6e60000 {
 		compatible = "renesas,scif-r8a7793", "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
-		interrupts = <0 152 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
@@ -543,7 +543,7 @@
 	scif1: serial at e6e68000 {
 		compatible = "renesas,scif-r8a7793", "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
-		interrupts = <0 153 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
@@ -555,7 +555,7 @@
 	scif2: serial at e6e58000 {
 		compatible = "renesas,scif-r8a7793", "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
-		interrupts = <0 22 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
@@ -567,7 +567,7 @@
 	scif3: serial at e6ea8000 {
 		compatible = "renesas,scif-r8a7793", "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
-		interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF3>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
@@ -579,7 +579,7 @@
 	scif4: serial at e6ee0000 {
 		compatible = "renesas,scif-r8a7793", "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
-		interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF4>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
@@ -591,7 +591,7 @@
 	scif5: serial at e6ee8000 {
 		compatible = "renesas,scif-r8a7793", "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
-		interrupts = <0 25 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF5>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
@@ -603,7 +603,7 @@
 	hscif0: serial at e62c0000 {
 		compatible = "renesas,hscif-r8a7793", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
-		interrupts = <0 154 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
@@ -615,7 +615,7 @@
 	hscif1: serial at e62c8000 {
 		compatible = "renesas,hscif-r8a7793", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
-		interrupts = <0 155 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
@@ -627,7 +627,7 @@
 	hscif2: serial at e62d0000 {
 		compatible = "renesas,hscif-r8a7793", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
-		interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
@@ -639,7 +639,7 @@
 	ether: ethernet at ee700000 {
 		compatible = "renesas,ether-r8a7793";
 		reg = <0 0xee700000 0 0x400>;
-		interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7793_CLK_ETHER>;
 		power-domains = <&cpg_clocks>;
 		phy-mode = "rmii";
@@ -651,7 +651,7 @@
 	qspi: spi at e6b10000 {
 		compatible = "renesas,qspi-r8a7793", "renesas,qspi";
 		reg = <0 0xe6b10000 0 0x2c>;
-		interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7793_CLK_QSPI_MOD>;
 		dmas = <&dmac0 0x17>, <&dmac0 0x18>;
 		dma-names = "tx", "rx";
@@ -667,8 +667,8 @@
 		reg = <0 0xfeb00000 0 0x40000>,
 		      <0 0xfeb90000 0 0x1c>;
 		reg-names = "du", "lvds.0";
-		interrupts = <0 256 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 268 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_DU0>,
 			 <&mstp7_clks R8A7793_CLK_DU1>,
 			 <&mstp7_clks R8A7793_CLK_LVDS0>;
@@ -978,8 +978,8 @@
 	ipmmu_sy0: mmu at e6280000 {
 		compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6280000 0 0x1000>;
-		interrupts = <0 223 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 224 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -987,7 +987,7 @@
 	ipmmu_sy1: mmu at e6290000 {
 		compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6290000 0 0x1000>;
-		interrupts = <0 225 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -995,8 +995,8 @@
 	ipmmu_ds: mmu at e6740000 {
 		compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6740000 0 0x1000>;
-		interrupts = <0 198 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 199 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1004,7 +1004,7 @@
 	ipmmu_mp: mmu at ec680000 {
 		compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
 		reg = <0 0xec680000 0 0x1000>;
-		interrupts = <0 226 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1012,8 +1012,8 @@
 	ipmmu_mx: mmu at fe951000 {
 		compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
 		reg = <0 0xfe951000 0 0x1000>;
-		interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 221 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1021,7 +1021,7 @@
 	ipmmu_rt: mmu at ffc80000 {
 		compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
 		reg = <0 0xffc80000 0 0x1000>;
-		interrupts = <0 307 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1029,8 +1029,8 @@
 	ipmmu_gp: mmu at e62a0000 {
 		compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
 		reg = <0 0xe62a0000 0 0x1000>;
-		interrupts = <0 260 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 261 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 261 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:01 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:01 +0100
Subject: [PATCH 11/68] ARM: dts: r8a7790: use GIC_* defines
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <3abb4d5fc3a1fbfdd414d50d9c1d01bfd453c4a9.1455303422.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7791 device tree.

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 368 ++++++++++++++++++++---------------------
 1 file changed, 184 insertions(+), 184 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 4d9af0f46fab..cc7eccf0ada7 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -121,13 +121,13 @@
 			<0 0xf1002000 0 0x1000>,
 			<0 0xf1004000 0 0x2000>,
 			<0 0xf1006000 0 0x2000>;
-		interrupts = <1 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
 	};
 
 	gpio0: gpio at e6050000 {
 		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
 		reg = <0 0xe6050000 0 0x50>;
-		interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 0 32>;
@@ -140,7 +140,7 @@
 	gpio1: gpio at e6051000 {
 		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
 		reg = <0 0xe6051000 0 0x50>;
-		interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 32 30>;
@@ -153,7 +153,7 @@
 	gpio2: gpio at e6052000 {
 		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
 		reg = <0 0xe6052000 0 0x50>;
-		interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 64 30>;
@@ -166,7 +166,7 @@
 	gpio3: gpio at e6053000 {
 		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
 		reg = <0 0xe6053000 0 0x50>;
-		interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 96 32>;
@@ -179,7 +179,7 @@
 	gpio4: gpio at e6054000 {
 		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
 		reg = <0 0xe6054000 0 0x50>;
-		interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 128 32>;
@@ -192,7 +192,7 @@
 	gpio5: gpio at e6055000 {
 		compatible = "renesas,gpio-r8a7790", "renesas,gpio-rcar";
 		reg = <0 0xe6055000 0 0x50>;
-		interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 160 32>;
@@ -205,24 +205,24 @@
 	thermal at e61f0000 {
 		compatible = "renesas,thermal-r8a7790", "renesas,rcar-thermal";
 		reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
-		interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks R8A7790_CLK_THERMAL>;
 		power-domains = <&cpg_clocks>;
 	};
 
 	timer {
 		compatible = "arm,armv7-timer";
-		interrupts = <1 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
 	};
 
 	cmt0: timer at ffca0000 {
 		compatible = "renesas,cmt-48-r8a7790", "renesas,cmt-48-gen2";
 		reg = <0 0xffca0000 0 0x1004>;
-		interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 143 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7790_CLK_CMT0>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -235,14 +235,14 @@
 	cmt1: timer at e6130000 {
 		compatible = "renesas,cmt-48-r8a7790", "renesas,cmt-48-gen2";
 		reg = <0 0xe6130000 0 0x1004>;
-		interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 121 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 122 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 123 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 124 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 125 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 126 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 127 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_CMT1>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -257,10 +257,10 @@
 		#interrupt-cells = <2>;
 		interrupt-controller;
 		reg = <0 0xe61c0000 0 0x200>;
-		interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 1 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 2 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 3 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A7790_CLK_IRQC>;
 		power-domains = <&cpg_clocks>;
 	};
@@ -268,22 +268,22 @@
 	dmac0: dma-controller at e6700000 {
 		compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
 		reg = <0 0xe6700000 0 0x20000>;
-		interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH
-			      0 200 IRQ_TYPE_LEVEL_HIGH
-			      0 201 IRQ_TYPE_LEVEL_HIGH
-			      0 202 IRQ_TYPE_LEVEL_HIGH
-			      0 203 IRQ_TYPE_LEVEL_HIGH
-			      0 204 IRQ_TYPE_LEVEL_HIGH
-			      0 205 IRQ_TYPE_LEVEL_HIGH
-			      0 206 IRQ_TYPE_LEVEL_HIGH
-			      0 207 IRQ_TYPE_LEVEL_HIGH
-			      0 208 IRQ_TYPE_LEVEL_HIGH
-			      0 209 IRQ_TYPE_LEVEL_HIGH
-			      0 210 IRQ_TYPE_LEVEL_HIGH
-			      0 211 IRQ_TYPE_LEVEL_HIGH
-			      0 212 IRQ_TYPE_LEVEL_HIGH
-			      0 213 IRQ_TYPE_LEVEL_HIGH
-			      0 214 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -299,22 +299,22 @@
 	dmac1: dma-controller at e6720000 {
 		compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
 		reg = <0 0xe6720000 0 0x20000>;
-		interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
-			      0 216 IRQ_TYPE_LEVEL_HIGH
-			      0 217 IRQ_TYPE_LEVEL_HIGH
-			      0 218 IRQ_TYPE_LEVEL_HIGH
-			      0 219 IRQ_TYPE_LEVEL_HIGH
-			      0 308 IRQ_TYPE_LEVEL_HIGH
-			      0 309 IRQ_TYPE_LEVEL_HIGH
-			      0 310 IRQ_TYPE_LEVEL_HIGH
-			      0 311 IRQ_TYPE_LEVEL_HIGH
-			      0 312 IRQ_TYPE_LEVEL_HIGH
-			      0 313 IRQ_TYPE_LEVEL_HIGH
-			      0 314 IRQ_TYPE_LEVEL_HIGH
-			      0 315 IRQ_TYPE_LEVEL_HIGH
-			      0 316 IRQ_TYPE_LEVEL_HIGH
-			      0 317 IRQ_TYPE_LEVEL_HIGH
-			      0 318 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -330,20 +330,20 @@
 	audma0: dma-controller at ec700000 {
 		compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
 		reg = <0 0xec700000 0 0x10000>;
-		interrupts =	<0 346 IRQ_TYPE_LEVEL_HIGH
-				 0 320 IRQ_TYPE_LEVEL_HIGH
-				 0 321 IRQ_TYPE_LEVEL_HIGH
-				 0 322 IRQ_TYPE_LEVEL_HIGH
-				 0 323 IRQ_TYPE_LEVEL_HIGH
-				 0 324 IRQ_TYPE_LEVEL_HIGH
-				 0 325 IRQ_TYPE_LEVEL_HIGH
-				 0 326 IRQ_TYPE_LEVEL_HIGH
-				 0 327 IRQ_TYPE_LEVEL_HIGH
-				 0 328 IRQ_TYPE_LEVEL_HIGH
-				 0 329 IRQ_TYPE_LEVEL_HIGH
-				 0 330 IRQ_TYPE_LEVEL_HIGH
-				 0 331 IRQ_TYPE_LEVEL_HIGH
-				 0 332 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts =	<GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -359,20 +359,20 @@
 	audma1: dma-controller at ec720000 {
 		compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
 		reg = <0 0xec720000 0 0x10000>;
-		interrupts =	<0 347 IRQ_TYPE_LEVEL_HIGH
-				 0 333 IRQ_TYPE_LEVEL_HIGH
-				 0 334 IRQ_TYPE_LEVEL_HIGH
-				 0 335 IRQ_TYPE_LEVEL_HIGH
-				 0 336 IRQ_TYPE_LEVEL_HIGH
-				 0 337 IRQ_TYPE_LEVEL_HIGH
-				 0 338 IRQ_TYPE_LEVEL_HIGH
-				 0 339 IRQ_TYPE_LEVEL_HIGH
-				 0 340 IRQ_TYPE_LEVEL_HIGH
-				 0 341 IRQ_TYPE_LEVEL_HIGH
-				 0 342 IRQ_TYPE_LEVEL_HIGH
-				 0 343 IRQ_TYPE_LEVEL_HIGH
-				 0 344 IRQ_TYPE_LEVEL_HIGH
-				 0 345 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts =	<GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH
+				 GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -388,8 +388,8 @@
 	usb_dmac0: dma-controller at e65a0000 {
 		compatible = "renesas,r8a7790-usb-dmac", "renesas,usb-dmac";
 		reg = <0 0xe65a0000 0 0x100>;
-		interrupts = <0 109 IRQ_TYPE_LEVEL_HIGH
-			      0 109 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "ch0", "ch1";
 		clocks = <&mstp3_clks R8A7790_CLK_USBDMAC0>;
 		power-domains = <&cpg_clocks>;
@@ -400,8 +400,8 @@
 	usb_dmac1: dma-controller at e65b0000 {
 		compatible = "renesas,r8a7790-usb-dmac", "renesas,usb-dmac";
 		reg = <0 0xe65b0000 0 0x100>;
-		interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH
-			      0 110 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "ch0", "ch1";
 		clocks = <&mstp3_clks R8A7790_CLK_USBDMAC1>;
 		power-domains = <&cpg_clocks>;
@@ -414,7 +414,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7790";
 		reg = <0 0xe6508000 0 0x40>;
-		interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_I2C0>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <110>;
@@ -426,7 +426,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7790";
 		reg = <0 0xe6518000 0 0x40>;
-		interrupts = <0 288 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_I2C1>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -438,7 +438,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7790";
 		reg = <0 0xe6530000 0 0x40>;
-		interrupts = <0 286 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_I2C2>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <6>;
@@ -450,7 +450,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,i2c-r8a7790";
 		reg = <0 0xe6540000 0 0x40>;
-		interrupts = <0 290 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_I2C3>;
 		power-domains = <&cpg_clocks>;
 		i2c-scl-internal-delay-ns = <110>;
@@ -462,7 +462,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
 		reg = <0 0xe6500000 0 0x425>;
-		interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_IIC0>;
 		dmas = <&dmac0 0x61>, <&dmac0 0x62>;
 		dma-names = "tx", "rx";
@@ -475,7 +475,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
 		reg = <0 0xe6510000 0 0x425>;
-		interrupts = <0 175 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_IIC1>;
 		dmas = <&dmac0 0x65>, <&dmac0 0x66>;
 		dma-names = "tx", "rx";
@@ -488,7 +488,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
 		reg = <0 0xe6520000 0 0x425>;
-		interrupts = <0 176 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_IIC2>;
 		dmas = <&dmac0 0x69>, <&dmac0 0x6a>;
 		dma-names = "tx", "rx";
@@ -501,7 +501,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
 		reg = <0 0xe60b0000 0 0x425>;
-		interrupts = <0 173 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_IICDVFS>;
 		dmas = <&dmac0 0x77>, <&dmac0 0x78>;
 		dma-names = "tx", "rx";
@@ -512,7 +512,7 @@
 	mmcif0: mmc at ee200000 {
 		compatible = "renesas,mmcif-r8a7790", "renesas,sh-mmcif";
 		reg = <0 0xee200000 0 0x80>;
-		interrupts = <0 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_MMCIF0>;
 		dmas = <&dmac0 0xd1>, <&dmac0 0xd2>;
 		dma-names = "tx", "rx";
@@ -525,7 +525,7 @@
 	mmcif1: mmc at ee220000 {
 		compatible = "renesas,mmcif-r8a7790", "renesas,sh-mmcif";
 		reg = <0 0xee220000 0 0x80>;
-		interrupts = <0 170 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_MMCIF1>;
 		dmas = <&dmac0 0xe1>, <&dmac0 0xe2>;
 		dma-names = "tx", "rx";
@@ -543,7 +543,7 @@
 	sdhi0: sd at ee100000 {
 		compatible = "renesas,sdhi-r8a7790";
 		reg = <0 0xee100000 0 0x328>;
-		interrupts = <0 165 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_SDHI0>;
 		dmas = <&dmac1 0xcd>, <&dmac1 0xce>;
 		dma-names = "tx", "rx";
@@ -554,7 +554,7 @@
 	sdhi1: sd at ee120000 {
 		compatible = "renesas,sdhi-r8a7790";
 		reg = <0 0xee120000 0 0x328>;
-		interrupts = <0 166 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_SDHI1>;
 		dmas = <&dmac1 0xc9>, <&dmac1 0xca>;
 		dma-names = "tx", "rx";
@@ -565,7 +565,7 @@
 	sdhi2: sd at ee140000 {
 		compatible = "renesas,sdhi-r8a7790";
 		reg = <0 0xee140000 0 0x100>;
-		interrupts = <0 167 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_SDHI2>;
 		dmas = <&dmac1 0xc1>, <&dmac1 0xc2>;
 		dma-names = "tx", "rx";
@@ -576,7 +576,7 @@
 	sdhi3: sd at ee160000 {
 		compatible = "renesas,sdhi-r8a7790";
 		reg = <0 0xee160000 0 0x100>;
-		interrupts = <0 168 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_SDHI3>;
 		dmas = <&dmac1 0xd3>, <&dmac1 0xd4>;
 		dma-names = "tx", "rx";
@@ -587,7 +587,7 @@
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a7790", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
-		interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
@@ -599,7 +599,7 @@
 	scifa1: serial at e6c50000 {
 		compatible = "renesas,scifa-r8a7790", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
-		interrupts = <0 145 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
@@ -611,7 +611,7 @@
 	scifa2: serial at e6c60000 {
 		compatible = "renesas,scifa-r8a7790", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
-		interrupts = <0 151 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
@@ -623,7 +623,7 @@
 	scifb0: serial at e6c20000 {
 		compatible = "renesas,scifb-r8a7790", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
-		interrupts = <0 148 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
@@ -635,7 +635,7 @@
 	scifb1: serial at e6c30000 {
 		compatible = "renesas,scifb-r8a7790", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
@@ -647,7 +647,7 @@
 	scifb2: serial at e6ce0000 {
 		compatible = "renesas,scifb-r8a7790", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
-		interrupts = <0 150 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
@@ -659,7 +659,7 @@
 	scif0: serial at e6e60000 {
 		compatible = "renesas,scif-r8a7790", "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
-		interrupts = <0 152 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_SCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
@@ -671,7 +671,7 @@
 	scif1: serial at e6e68000 {
 		compatible = "renesas,scif-r8a7790", "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
-		interrupts = <0 153 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_SCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
@@ -683,7 +683,7 @@
 	hscif0: serial at e62c0000 {
 		compatible = "renesas,hscif-r8a7790", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
-		interrupts = <0 154 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
@@ -695,7 +695,7 @@
 	hscif1: serial at e62c8000 {
 		compatible = "renesas,hscif-r8a7790", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
-		interrupts = <0 155 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
@@ -707,7 +707,7 @@
 	ether: ethernet at ee700000 {
 		compatible = "renesas,ether-r8a7790";
 		reg = <0 0xee700000 0 0x400>;
-		interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_ETHER>;
 		power-domains = <&cpg_clocks>;
 		phy-mode = "rmii";
@@ -719,7 +719,7 @@
 	avb: ethernet at e6800000 {
 		compatible = "renesas,etheravb-r8a7790";
 		reg = <0 0xe6800000 0 0x800>, <0 0xee0e8000 0 0x4000>;
-		interrupts = <0 163 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_ETHERAVB>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -730,7 +730,7 @@
 	sata0: sata at ee300000 {
 		compatible = "renesas,sata-r8a7790";
 		reg = <0 0xee300000 0 0x2000>;
-		interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_SATA0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -739,7 +739,7 @@
 	sata1: sata at ee500000 {
 		compatible = "renesas,sata-r8a7790";
 		reg = <0 0xee500000 0 0x2000>;
-		interrupts = <0 106 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_SATA1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -748,7 +748,7 @@
 	hsusb: usb at e6590000 {
 		compatible = "renesas,usbhs-r8a7790", "renesas,rcar-gen2-usbhs";
 		reg = <0 0xe6590000 0 0x100>;
-		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
 		dmas = <&usb_dmac0 0>, <&usb_dmac0 1>,
 		       <&usb_dmac1 0>, <&usb_dmac1 1>;
@@ -783,7 +783,7 @@
 	vin0: video at e6ef0000 {
 		compatible = "renesas,vin-r8a7790";
 		reg = <0 0xe6ef0000 0 0x1000>;
-		interrupts = <0 188 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_VIN0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -792,7 +792,7 @@
 	vin1: video at e6ef1000 {
 		compatible = "renesas,vin-r8a7790";
 		reg = <0 0xe6ef1000 0 0x1000>;
-		interrupts = <0 189 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_VIN1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -801,7 +801,7 @@
 	vin2: video at e6ef2000 {
 		compatible = "renesas,vin-r8a7790";
 		reg = <0 0xe6ef2000 0 0x1000>;
-		interrupts = <0 190 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_VIN2>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -810,7 +810,7 @@
 	vin3: video at e6ef3000 {
 		compatible = "renesas,vin-r8a7790";
 		reg = <0 0xe6ef3000 0 0x1000>;
-		interrupts = <0 191 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_VIN3>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -819,7 +819,7 @@
 	vsp1 at fe920000 {
 		compatible = "renesas,vsp1";
 		reg = <0 0xfe920000 0 0x8000>;
-		interrupts = <0 266 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7790_CLK_VSP1_R>;
 		power-domains = <&cpg_clocks>;
 
@@ -832,7 +832,7 @@
 	vsp1 at fe928000 {
 		compatible = "renesas,vsp1";
 		reg = <0 0xfe928000 0 0x8000>;
-		interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7790_CLK_VSP1_S>;
 		power-domains = <&cpg_clocks>;
 
@@ -846,7 +846,7 @@
 	vsp1 at fe930000 {
 		compatible = "renesas,vsp1";
 		reg = <0 0xfe930000 0 0x8000>;
-		interrupts = <0 246 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 246 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7790_CLK_VSP1_DU0>;
 		power-domains = <&cpg_clocks>;
 
@@ -860,7 +860,7 @@
 	vsp1 at fe938000 {
 		compatible = "renesas,vsp1";
 		reg = <0 0xfe938000 0 0x8000>;
-		interrupts = <0 247 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7790_CLK_VSP1_DU1>;
 		power-domains = <&cpg_clocks>;
 
@@ -877,9 +877,9 @@
 		      <0 0xfeb90000 0 0x1c>,
 		      <0 0xfeb94000 0 0x1c>;
 		reg-names = "du", "lvds.0", "lvds.1";
-		interrupts = <0 256 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 268 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 269 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_DU0>,
 			 <&mstp7_clks R8A7790_CLK_DU1>,
 			 <&mstp7_clks R8A7790_CLK_DU2>,
@@ -913,7 +913,7 @@
 	can0: can at e6e80000 {
 		compatible = "renesas,can-r8a7790";
 		reg = <0 0xe6e80000 0 0x1000>;
-		interrupts = <0 186 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_RCAN0>,
 			 <&cpg_clocks R8A7790_CLK_RCAN>, <&can_clk>;
 		clock-names = "clkp1", "clkp2", "can_clk";
@@ -924,7 +924,7 @@
 	can1: can at e6e88000 {
 		compatible = "renesas,can-r8a7790";
 		reg = <0 0xe6e88000 0 0x1000>;
-		interrupts = <0 187 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_RCAN1>,
 			 <&cpg_clocks R8A7790_CLK_RCAN>, <&can_clk>;
 		clock-names = "clkp1", "clkp2", "can_clk";
@@ -935,7 +935,7 @@
 	jpu: jpeg-codec at fe980000 {
 		compatible = "renesas,jpu-r8a7790";
 		reg = <0 0xfe980000 0 0x10300>;
-		interrupts = <0 272 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7790_CLK_JPU>;
 		power-domains = <&cpg_clocks>;
 	};
@@ -1401,7 +1401,7 @@
 	qspi: spi at e6b10000 {
 		compatible = "renesas,qspi-r8a7790", "renesas,qspi";
 		reg = <0 0xe6b10000 0 0x2c>;
-		interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7790_CLK_QSPI_MOD>;
 		dmas = <&dmac0 0x17>, <&dmac0 0x18>;
 		dma-names = "tx", "rx";
@@ -1415,7 +1415,7 @@
 	msiof0: spi at e6e20000 {
 		compatible = "renesas,msiof-r8a7790";
 		reg = <0 0xe6e20000 0 0x0064>;
-		interrupts = <0 156 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7790_CLK_MSIOF0>;
 		dmas = <&dmac0 0x51>, <&dmac0 0x52>;
 		dma-names = "tx", "rx";
@@ -1428,7 +1428,7 @@
 	msiof1: spi at e6e10000 {
 		compatible = "renesas,msiof-r8a7790";
 		reg = <0 0xe6e10000 0 0x0064>;
-		interrupts = <0 157 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_MSIOF1>;
 		dmas = <&dmac0 0x55>, <&dmac0 0x56>;
 		dma-names = "tx", "rx";
@@ -1441,7 +1441,7 @@
 	msiof2: spi at e6e00000 {
 		compatible = "renesas,msiof-r8a7790";
 		reg = <0 0xe6e00000 0 0x0064>;
-		interrupts = <0 158 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_MSIOF2>;
 		dmas = <&dmac0 0x41>, <&dmac0 0x42>;
 		dma-names = "tx", "rx";
@@ -1454,7 +1454,7 @@
 	msiof3: spi at e6c90000 {
 		compatible = "renesas,msiof-r8a7790";
 		reg = <0 0xe6c90000 0 0x0064>;
-		interrupts = <0 159 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_MSIOF3>;
 		dmas = <&dmac0 0x45>, <&dmac0 0x46>;
 		dma-names = "tx", "rx";
@@ -1467,7 +1467,7 @@
 	xhci: usb at ee000000 {
 		compatible = "renesas,xhci-r8a7790";
 		reg = <0 0xee000000 0 0xc00>;
-		interrupts = <0 101 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_SSUSB>;
 		power-domains = <&cpg_clocks>;
 		phys = <&usb2 1>;
@@ -1480,7 +1480,7 @@
 		device_type = "pci";
 		reg = <0 0xee090000 0 0xc00>,
 		      <0 0xee080000 0 0x1100>;
-		interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_EHCI>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -1491,9 +1491,9 @@
 		#interrupt-cells = <1>;
 		ranges = <0x02000000 0 0xee080000 0 0xee080000 0 0x00010000>;
 		interrupt-map-mask = <0xff00 0 0 0x7>;
-		interrupt-map = <0x0000 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
-				 0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
-				 0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH
+				 0x0800 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH
+				 0x1000 0 0 2 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 
 		usb at 0,1 {
 			reg = <0x800 0 0 0 0>;
@@ -1515,7 +1515,7 @@
 		device_type = "pci";
 		reg = <0 0xee0b0000 0 0xc00>,
 		      <0 0xee0a0000 0 0x1100>;
-		interrupts = <0 112 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_EHCI>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -1526,9 +1526,9 @@
 		#interrupt-cells = <1>;
 		ranges = <0x02000000 0 0xee0a0000 0 0xee0a0000 0 0x00010000>;
 		interrupt-map-mask = <0xff00 0 0 0x7>;
-		interrupt-map = <0x0000 0 0 1 &gic 0 112 IRQ_TYPE_LEVEL_HIGH
-				 0x0800 0 0 1 &gic 0 112 IRQ_TYPE_LEVEL_HIGH
-				 0x1000 0 0 2 &gic 0 112 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH
+				 0x0800 0 0 1 &gic GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH
+				 0x1000 0 0 2 &gic GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
 	};
 
 	pci2: pci at ee0d0000 {
@@ -1538,7 +1538,7 @@
 		power-domains = <&cpg_clocks>;
 		reg = <0 0xee0d0000 0 0xc00>,
 		      <0 0xee0c0000 0 0x1100>;
-		interrupts = <0 113 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
 		status = "disabled";
 
 		bus-range = <2 2>;
@@ -1547,9 +1547,9 @@
 		#interrupt-cells = <1>;
 		ranges = <0x02000000 0 0xee0c0000 0 0xee0c0000 0 0x00010000>;
 		interrupt-map-mask = <0xff00 0 0 0x7>;
-		interrupt-map = <0x0000 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
-				 0x0800 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
-				 0x1000 0 0 2 &gic 0 113 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
+				 0x0800 0 0 1 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
+				 0x1000 0 0 2 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
 
 		usb at 0,1 {
 			reg = <0x800 0 0 0 0>;
@@ -1580,12 +1580,12 @@
 		/* Map all possible DDR as inbound ranges */
 		dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000
 			      0x43000000 1 0x80000000 1 0x80000000 0 0x80000000>;
-		interrupts = <0 116 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 117 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 118 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
 		#interrupt-cells = <1>;
 		interrupt-map-mask = <0 0 0 0>;
-		interrupt-map = <0 0 0 0 &gic 0 116 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0 0 0 0 &gic GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7790_CLK_PCIEC>, <&pcie_bus_clk>;
 		clock-names = "pcie", "pcie_bus";
 		power-domains = <&cpg_clocks>;
@@ -1664,52 +1664,52 @@
 
 		rcar_sound,src {
 			src0: src at 0 {
-				interrupts = <0 352 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x85>, <&audma1 0x9a>;
 				dma-names = "rx", "tx";
 			};
 			src1: src at 1 {
-				interrupts = <0 353 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x87>, <&audma1 0x9c>;
 				dma-names = "rx", "tx";
 			};
 			src2: src at 2 {
-				interrupts = <0 354 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x89>, <&audma1 0x9e>;
 				dma-names = "rx", "tx";
 			};
 			src3: src at 3 {
-				interrupts = <0 355 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x8b>, <&audma1 0xa0>;
 				dma-names = "rx", "tx";
 			};
 			src4: src at 4 {
-				interrupts = <0 356 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x8d>, <&audma1 0xb0>;
 				dma-names = "rx", "tx";
 			};
 			src5: src at 5 {
-				interrupts = <0 357 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x8f>, <&audma1 0xb2>;
 				dma-names = "rx", "tx";
 			};
 			src6: src at 6 {
-				interrupts = <0 358 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x91>, <&audma1 0xb4>;
 				dma-names = "rx", "tx";
 			};
 			src7: src at 7 {
-				interrupts = <0 359 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x93>, <&audma1 0xb6>;
 				dma-names = "rx", "tx";
 			};
 			src8: src at 8 {
-				interrupts = <0 360 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x95>, <&audma1 0xb8>;
 				dma-names = "rx", "tx";
 			};
 			src9: src at 9 {
-				interrupts = <0 361 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x97>, <&audma1 0xba>;
 				dma-names = "rx", "tx";
 			};
@@ -1717,52 +1717,52 @@
 
 		rcar_sound,ssi {
 			ssi0: ssi at 0 {
-				interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x01>, <&audma1 0x02>, <&audma0 0x15>, <&audma1 0x16>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi1: ssi at 1 {
-				 interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>;
+				 interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x03>, <&audma1 0x04>, <&audma0 0x49>, <&audma1 0x4a>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi2: ssi at 2 {
-				interrupts = <0 372 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x05>, <&audma1 0x06>, <&audma0 0x63>, <&audma1 0x64>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi3: ssi at 3 {
-				interrupts = <0 373 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x07>, <&audma1 0x08>, <&audma0 0x6f>, <&audma1 0x70>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi4: ssi at 4 {
-				interrupts = <0 374 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x09>, <&audma1 0x0a>, <&audma0 0x71>, <&audma1 0x72>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi5: ssi at 5 {
-				interrupts = <0 375 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x0b>, <&audma1 0x0c>, <&audma0 0x73>, <&audma1 0x74>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi6: ssi at 6 {
-				interrupts = <0 376 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x0d>, <&audma1 0x0e>, <&audma0 0x75>, <&audma1 0x76>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi7: ssi at 7 {
-				interrupts = <0 377 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x0f>, <&audma1 0x10>, <&audma0 0x79>, <&audma1 0x7a>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi8: ssi at 8 {
-				interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x11>, <&audma1 0x12>, <&audma0 0x7b>, <&audma1 0x7c>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
 			ssi9: ssi at 9 {
-				interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
 				dmas = <&audma0 0x13>, <&audma1 0x14>, <&audma0 0x7d>, <&audma1 0x7e>;
 				dma-names = "rx", "tx", "rxu", "txu";
 			};
@@ -1772,8 +1772,8 @@
 	ipmmu_sy0: mmu at e6280000 {
 		compatible = "renesas,ipmmu-r8a7790", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6280000 0 0x1000>;
-		interrupts = <0 223 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 224 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1781,7 +1781,7 @@
 	ipmmu_sy1: mmu at e6290000 {
 		compatible = "renesas,ipmmu-r8a7790", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6290000 0 0x1000>;
-		interrupts = <0 225 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1789,8 +1789,8 @@
 	ipmmu_ds: mmu at e6740000 {
 		compatible = "renesas,ipmmu-r8a7790", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6740000 0 0x1000>;
-		interrupts = <0 198 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 199 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1798,7 +1798,7 @@
 	ipmmu_mp: mmu at ec680000 {
 		compatible = "renesas,ipmmu-r8a7790", "renesas,ipmmu-vmsa";
 		reg = <0 0xec680000 0 0x1000>;
-		interrupts = <0 226 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1806,8 +1806,8 @@
 	ipmmu_mx: mmu at fe951000 {
 		compatible = "renesas,ipmmu-r8a7790", "renesas,ipmmu-vmsa";
 		reg = <0 0xfe951000 0 0x1000>;
-		interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 221 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1815,7 +1815,7 @@
 	ipmmu_rt: mmu at ffc80000 {
 		compatible = "renesas,ipmmu-r8a7790", "renesas,ipmmu-vmsa";
 		reg = <0 0xffc80000 0 0x1000>;
-		interrupts = <0 307 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:05 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:05 +0100
Subject: [PATCH 15/68] ARM: dts: r8a7794: use GIC_* defines
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <8d47e6af6f824e6f68f0af3f09816cc424e6fbac.1455303422.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7794 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7794.dtsi | 234 ++++++++++++++++++++---------------------
 1 file changed, 117 insertions(+), 117 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index f8cd3a0beebf..21be4bdc4001 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -59,13 +59,13 @@
 			<0 0xf1002000 0 0x1000>,
 			<0 0xf1004000 0 0x2000>,
 			<0 0xf1006000 0 0x2000>;
-		interrupts = <1 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
 	};
 
 	gpio0: gpio at e6050000 {
 		compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
 		reg = <0 0xe6050000 0 0x50>;
-		interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 0 32>;
@@ -78,7 +78,7 @@
 	gpio1: gpio at e6051000 {
 		compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
 		reg = <0 0xe6051000 0 0x50>;
-		interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 32 26>;
@@ -91,7 +91,7 @@
 	gpio2: gpio at e6052000 {
 		compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
 		reg = <0 0xe6052000 0 0x50>;
-		interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 64 32>;
@@ -104,7 +104,7 @@
 	gpio3: gpio at e6053000 {
 		compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
 		reg = <0 0xe6053000 0 0x50>;
-		interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 96 32>;
@@ -117,7 +117,7 @@
 	gpio4: gpio at e6054000 {
 		compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
 		reg = <0 0xe6054000 0 0x50>;
-		interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 128 32>;
@@ -130,7 +130,7 @@
 	gpio5: gpio at e6055000 {
 		compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
 		reg = <0 0xe6055000 0 0x50>;
-		interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 160 28>;
@@ -143,7 +143,7 @@
 	gpio6: gpio at e6055400 {
 		compatible = "renesas,gpio-r8a7794", "renesas,gpio-rcar";
 		reg = <0 0xe6055400 0 0x50>;
-		interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
 		#gpio-cells = <2>;
 		gpio-controller;
 		gpio-ranges = <&pfc 0 192 26>;
@@ -156,8 +156,8 @@
 	cmt0: timer at ffca0000 {
 		compatible = "renesas,cmt-48-gen2";
 		reg = <0 0xffca0000 0 0x1004>;
-		interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 143 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7794_CLK_CMT0>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -170,14 +170,14 @@
 	cmt1: timer at e6130000 {
 		compatible = "renesas,cmt-48-gen2";
 		reg = <0 0xe6130000 0 0x1004>;
-		interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 121 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 122 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 123 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 124 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 125 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 126 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 127 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7794_CLK_CMT1>;
 		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
@@ -189,10 +189,10 @@
 
 	timer {
 		compatible = "arm,armv7-timer";
-		interrupts = <1 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
 	};
 
 	irqc0: interrupt-controller at e61c0000 {
@@ -200,16 +200,16 @@
 		#interrupt-cells = <2>;
 		interrupt-controller;
 		reg = <0 0xe61c0000 0 0x200>;
-		interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 1 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 2 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 3 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 12 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 13 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 14 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 15 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 16 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 17 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A7794_CLK_IRQC>;
 		power-domains = <&cpg_clocks>;
 	};
@@ -222,22 +222,22 @@
 	dmac0: dma-controller at e6700000 {
 		compatible = "renesas,dmac-r8a7794", "renesas,rcar-dmac";
 		reg = <0 0xe6700000 0 0x20000>;
-		interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH
-			      0 200 IRQ_TYPE_LEVEL_HIGH
-			      0 201 IRQ_TYPE_LEVEL_HIGH
-			      0 202 IRQ_TYPE_LEVEL_HIGH
-			      0 203 IRQ_TYPE_LEVEL_HIGH
-			      0 204 IRQ_TYPE_LEVEL_HIGH
-			      0 205 IRQ_TYPE_LEVEL_HIGH
-			      0 206 IRQ_TYPE_LEVEL_HIGH
-			      0 207 IRQ_TYPE_LEVEL_HIGH
-			      0 208 IRQ_TYPE_LEVEL_HIGH
-			      0 209 IRQ_TYPE_LEVEL_HIGH
-			      0 210 IRQ_TYPE_LEVEL_HIGH
-			      0 211 IRQ_TYPE_LEVEL_HIGH
-			      0 212 IRQ_TYPE_LEVEL_HIGH
-			      0 213 IRQ_TYPE_LEVEL_HIGH
-			      0 214 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -253,22 +253,22 @@
 	dmac1: dma-controller at e6720000 {
 		compatible = "renesas,dmac-r8a7794", "renesas,rcar-dmac";
 		reg = <0 0xe6720000 0 0x20000>;
-		interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
-			      0 216 IRQ_TYPE_LEVEL_HIGH
-			      0 217 IRQ_TYPE_LEVEL_HIGH
-			      0 218 IRQ_TYPE_LEVEL_HIGH
-			      0 219 IRQ_TYPE_LEVEL_HIGH
-			      0 308 IRQ_TYPE_LEVEL_HIGH
-			      0 309 IRQ_TYPE_LEVEL_HIGH
-			      0 310 IRQ_TYPE_LEVEL_HIGH
-			      0 311 IRQ_TYPE_LEVEL_HIGH
-			      0 312 IRQ_TYPE_LEVEL_HIGH
-			      0 313 IRQ_TYPE_LEVEL_HIGH
-			      0 314 IRQ_TYPE_LEVEL_HIGH
-			      0 315 IRQ_TYPE_LEVEL_HIGH
-			      0 316 IRQ_TYPE_LEVEL_HIGH
-			      0 317 IRQ_TYPE_LEVEL_HIGH
-			      0 318 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "error",
 				"ch0", "ch1", "ch2", "ch3",
 				"ch4", "ch5", "ch6", "ch7",
@@ -284,7 +284,7 @@
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
-		interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
@@ -296,7 +296,7 @@
 	scifa1: serial at e6c50000 {
 		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
-		interrupts = <0 145 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
@@ -308,7 +308,7 @@
 	scifa2: serial at e6c60000 {
 		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
-		interrupts = <0 151 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
@@ -320,7 +320,7 @@
 	scifa3: serial at e6c70000 {
 		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
 		reg = <0 0xe6c70000 0 64>;
-		interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA3>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1b>, <&dmac0 0x1c>;
@@ -332,7 +332,7 @@
 	scifa4: serial at e6c78000 {
 		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
 		reg = <0 0xe6c78000 0 64>;
-		interrupts = <0 30 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA4>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1f>, <&dmac0 0x20>;
@@ -344,7 +344,7 @@
 	scifa5: serial at e6c80000 {
 		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
 		reg = <0 0xe6c80000 0 64>;
-		interrupts = <0 31 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA5>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x23>, <&dmac0 0x24>;
@@ -356,7 +356,7 @@
 	scifb0: serial at e6c20000 {
 		compatible = "renesas,scifb-r8a7794", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
-		interrupts = <0 148 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
@@ -368,7 +368,7 @@
 	scifb1: serial at e6c30000 {
 		compatible = "renesas,scifb-r8a7794", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
@@ -380,7 +380,7 @@
 	scifb2: serial at e6ce0000 {
 		compatible = "renesas,scifb-r8a7794", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
-		interrupts = <0 150 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
@@ -392,7 +392,7 @@
 	scif0: serial at e6e60000 {
 		compatible = "renesas,scif-r8a7794", "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
-		interrupts = <0 152 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
@@ -404,7 +404,7 @@
 	scif1: serial at e6e68000 {
 		compatible = "renesas,scif-r8a7794", "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
-		interrupts = <0 153 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
@@ -416,7 +416,7 @@
 	scif2: serial at e6e58000 {
 		compatible = "renesas,scif-r8a7794", "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
-		interrupts = <0 22 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
@@ -428,7 +428,7 @@
 	scif3: serial at e6ea8000 {
 		compatible = "renesas,scif-r8a7794", "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
-		interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF3>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
@@ -440,7 +440,7 @@
 	scif4: serial at e6ee0000 {
 		compatible = "renesas,scif-r8a7794", "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
-		interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF4>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
@@ -452,7 +452,7 @@
 	scif5: serial at e6ee8000 {
 		compatible = "renesas,scif-r8a7794", "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
-		interrupts = <0 25 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF5>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
@@ -464,7 +464,7 @@
 	hscif0: serial at e62c0000 {
 		compatible = "renesas,hscif-r8a7794", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
-		interrupts = <0 154 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF0>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
@@ -476,7 +476,7 @@
 	hscif1: serial at e62c8000 {
 		compatible = "renesas,hscif-r8a7794", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
-		interrupts = <0 155 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF1>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
@@ -488,7 +488,7 @@
 	hscif2: serial at e62d0000 {
 		compatible = "renesas,hscif-r8a7794", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
-		interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF2>;
 		clock-names = "sci_ick";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
@@ -500,7 +500,7 @@
 	ether: ethernet at ee700000 {
 		compatible = "renesas,ether-r8a7794";
 		reg = <0 0xee700000 0 0x400>;
-		interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7794_CLK_ETHER>;
 		power-domains = <&cpg_clocks>;
 		phy-mode = "rmii";
@@ -513,7 +513,7 @@
 	i2c0: i2c at e6508000 {
 		compatible = "renesas,i2c-r8a7794";
 		reg = <0 0xe6508000 0 0x40>;
-		interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7794_CLK_I2C0>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -525,7 +525,7 @@
 	i2c1: i2c at e6518000 {
 		compatible = "renesas,i2c-r8a7794";
 		reg = <0 0xe6518000 0 0x40>;
-		interrupts = <0 288 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7794_CLK_I2C1>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -537,7 +537,7 @@
 	i2c2: i2c at e6530000 {
 		compatible = "renesas,i2c-r8a7794";
 		reg = <0 0xe6530000 0 0x40>;
-		interrupts = <0 286 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7794_CLK_I2C2>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -549,7 +549,7 @@
 	i2c3: i2c at e6540000 {
 		compatible = "renesas,i2c-r8a7794";
 		reg = <0 0xe6540000 0 0x40>;
-		interrupts = <0 290 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7794_CLK_I2C3>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -561,7 +561,7 @@
 	i2c4: i2c at e6520000 {
 		compatible = "renesas,i2c-r8a7794";
 		reg = <0 0xe6520000 0 0x40>;
-		interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7794_CLK_I2C4>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -573,7 +573,7 @@
 	i2c5: i2c at e6528000 {
 		compatible = "renesas,i2c-r8a7794";
 		reg = <0 0xe6528000 0 0x40>;
-		interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7794_CLK_I2C5>;
 		power-domains = <&cpg_clocks>;
 		#address-cells = <1>;
@@ -585,7 +585,7 @@
 	mmcif0: mmc at ee200000 {
 		compatible = "renesas,mmcif-r8a7794", "renesas,sh-mmcif";
 		reg = <0 0xee200000 0 0x80>;
-		interrupts = <0 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7794_CLK_MMCIF0>;
 		dmas = <&dmac0 0xd1>, <&dmac0 0xd2>;
 		dma-names = "tx", "rx";
@@ -597,7 +597,7 @@
 	sdhi0: sd at ee100000 {
 		compatible = "renesas,sdhi-r8a7794";
 		reg = <0 0xee100000 0 0x200>;
-		interrupts = <0 165 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7794_CLK_SDHI0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -606,7 +606,7 @@
 	sdhi1: sd at ee140000 {
 		compatible = "renesas,sdhi-r8a7794";
 		reg = <0 0xee140000 0 0x100>;
-		interrupts = <0 167 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7794_CLK_SDHI1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -615,7 +615,7 @@
 	sdhi2: sd at ee160000 {
 		compatible = "renesas,sdhi-r8a7794";
 		reg = <0 0xee160000 0 0x100>;
-		interrupts = <0 168 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7794_CLK_SDHI2>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -624,7 +624,7 @@
 	qspi: spi at e6b10000 {
 		compatible = "renesas,qspi-r8a7794", "renesas,qspi";
 		reg = <0 0xe6b10000 0 0x2c>;
-		interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp9_clks R8A7794_CLK_QSPI_MOD>;
 		dmas = <&dmac0 0x17>, <&dmac0 0x18>;
 		dma-names = "tx", "rx";
@@ -638,7 +638,7 @@
 	vin0: video at e6ef0000 {
 		compatible = "renesas,vin-r8a7794";
 		reg = <0 0xe6ef0000 0 0x1000>;
-		interrupts = <0 188 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7794_CLK_VIN0>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -647,7 +647,7 @@
 	vin1: video at e6ef1000 {
 		compatible = "renesas,vin-r8a7794";
 		reg = <0 0xe6ef1000 0 0x1000>;
-		interrupts = <0 189 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7794_CLK_VIN1>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -658,7 +658,7 @@
 		device_type = "pci";
 		reg = <0 0xee090000 0 0xc00>,
 		      <0 0xee080000 0 0x1100>;
-		interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_EHCI>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -669,9 +669,9 @@
 		#interrupt-cells = <1>;
 		ranges = <0x02000000 0 0xee080000 0 0xee080000 0 0x00010000>;
 		interrupt-map-mask = <0xff00 0 0 0x7>;
-		interrupt-map = <0x0000 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
-				 0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
-				 0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH
+				 0x0800 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH
+				 0x1000 0 0 2 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 
 		usb at 0,1 {
 			reg = <0x800 0 0 0 0>;
@@ -693,7 +693,7 @@
 		device_type = "pci";
 		reg = <0 0xee0d0000 0 0xc00>,
 		      <0 0xee0c0000 0 0x1100>;
-		interrupts = <0 113 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_EHCI>;
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
@@ -704,9 +704,9 @@
 		#interrupt-cells = <1>;
 		ranges = <0x02000000 0 0xee0c0000 0 0xee0c0000 0 0x00010000>;
 		interrupt-map-mask = <0xff00 0 0 0x7>;
-		interrupt-map = <0x0000 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
-				 0x0800 0 0 1 &gic 0 113 IRQ_TYPE_LEVEL_HIGH
-				 0x1000 0 0 2 &gic 0 113 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
+				 0x0800 0 0 1 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
+				 0x1000 0 0 2 &gic GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
 
 		usb at 0,1 {
 			reg = <0x800 0 0 0 0>;
@@ -726,7 +726,7 @@
 	hsusb: usb at e6590000 {
 		compatible = "renesas,usbhs-r8a7794", "renesas,rcar-gen2-usbhs";
 		reg = <0 0xe6590000 0 0x100>;
-		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSUSB>;
 		power-domains = <&cpg_clocks>;
 		renesas,buswait = <4>;
@@ -759,8 +759,8 @@
 		compatible = "renesas,du-r8a7794";
 		reg = <0 0xfeb00000 0 0x40000>;
 		reg-names = "du";
-		interrupts = <0 256 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 268 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_DU0>,
 			 <&mstp7_clks R8A7794_CLK_DU0>;
 		clock-names = "du.0", "du.1";
@@ -1111,8 +1111,8 @@
 	ipmmu_sy0: mmu at e6280000 {
 		compatible = "renesas,ipmmu-r8a7794", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6280000 0 0x1000>;
-		interrupts = <0 223 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 224 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1120,7 +1120,7 @@
 	ipmmu_sy1: mmu at e6290000 {
 		compatible = "renesas,ipmmu-r8a7794", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6290000 0 0x1000>;
-		interrupts = <0 225 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1128,8 +1128,8 @@
 	ipmmu_ds: mmu at e6740000 {
 		compatible = "renesas,ipmmu-r8a7794", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6740000 0 0x1000>;
-		interrupts = <0 198 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 199 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1137,7 +1137,7 @@
 	ipmmu_mp: mmu at ec680000 {
 		compatible = "renesas,ipmmu-r8a7794", "renesas,ipmmu-vmsa";
 		reg = <0 0xec680000 0 0x1000>;
-		interrupts = <0 226 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1145,8 +1145,8 @@
 	ipmmu_mx: mmu at fe951000 {
 		compatible = "renesas,ipmmu-r8a7794", "renesas,ipmmu-vmsa";
 		reg = <0 0xfe951000 0 0x1000>;
-		interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 221 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
@@ -1154,8 +1154,8 @@
 	ipmmu_gp: mmu at e62a0000 {
 		compatible = "renesas,ipmmu-r8a7794", "renesas,ipmmu-vmsa";
 		reg = <0 0xe62a0000 0 0x1000>;
-		interrupts = <0 260 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 261 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 261 IRQ_TYPE_LEVEL_HIGH>;
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:16 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:16 +0100
Subject: [PATCH 26/68] ARM: dts: r8a7793: add DVC support to device tree
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <4dfc6f8bbf821850c7a4e7f1364a42b63375ad4e.1455303422.git.horms+renesas@verge.net.au>

Add DVC support to sound node in r8a7793 device tree.

Based on similar work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 8b1ec47754ac..3531d30fe107 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -1127,17 +1127,23 @@
 			<&mstp10_clks R8A7793_CLK_SCU_SRC5>, <&mstp10_clks R8A7793_CLK_SCU_SRC4>,
 			<&mstp10_clks R8A7793_CLK_SCU_SRC3>, <&mstp10_clks R8A7793_CLK_SCU_SRC2>,
 			<&mstp10_clks R8A7793_CLK_SCU_SRC1>, <&mstp10_clks R8A7793_CLK_SCU_SRC0>,
+			<&mstp10_clks R8A7793_CLK_SCU_DVC0>, <&mstp10_clks R8A7793_CLK_SCU_DVC1>,
 			<&audio_clk_a>, <&audio_clk_b>, <&audio_clk_c>, <&m2_clk>;
 		clock-names = "ssi-all",
 				"ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
 				"ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0",
 				"src.9", "src.8", "src.7", "src.6", "src.5",
 				"src.4", "src.3", "src.2", "src.1", "src.0",
+				"dvc.0", "dvc.1",
 				"clk_a", "clk_b", "clk_c", "clk_i";
 		power-domains = <&cpg_clocks>;
 
 		status = "disabled";
 
+		rcar_sound,dvc {
+			dvc0: dvc at 0 { };
+			dvc1: dvc at 1 { };
+		};
 		rcar_sound,src {
 			src0: src at 0 { };
 			src1: src at 1 { };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:14 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:14 +0100
Subject: [PATCH 24/68] ARM: dts: r8a7793: add m2 clock to device tree
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <892f09f1528d113f8d1e5983ecebd322236ded95.1455303422.git.horms+renesas@verge.net.au>

Declare m2 clock in r8a7793 device tree.

Based on similar work for the r8a7791 by Laurent Pinchart.

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 530fa9488a4a..6aabba6ef92c 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -817,6 +817,14 @@
 			clock-mult = <1>;
 			clock-output-names = "p";
 		};
+		m2_clk: m2_clk {
+			compatible = "fixed-factor-clock";
+			clocks = <&cpg_clocks R8A7793_CLK_PLL1>;
+			#clock-cells = <0>;
+			clock-div = <8>;
+			clock-mult = <1>;
+			clock-output-names = "m2";
+		};
 		rclk_clk: rclk_clk {
 			compatible = "fixed-factor-clock";
 			clocks = <&cpg_clocks R8A7793_CLK_PLL1>;
-- 
2.7.0.rc3.207.g0ac5344



From sergei.shtylyov at cogentembedded.com  Fri Feb 12 11:08:54 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 12 Feb 2016 22:08:54 +0300
Subject: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
In-Reply-To: <20160212184343.GA31655@verge.net.au>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
 <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
 <874mdhtn7d.wl%kuninori.morimoto.gx@renesas.com>
 <20160210171455.GB17671@verge.net.au> <56BE0CB1.4070408@cogentembedded.com>
 <20160212184343.GA31655@verge.net.au>
Message-ID: <56BE2DC6.4080802@cogentembedded.com>

On 02/12/2016 09:43 PM, Simon Horman wrote:

>>>> Sorry for my un-ordered response
>>>>
>>>>> Define the generic R8A7794 part of  the sound device node.
>>>>> This sound device  is a complex one and comprises the Audio Clock Generator
>>>>> (ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
>>>>> (SSI[U]), and Audio DMAC-Peripheral-Peripheral.
>>>>> It is up  to the board file to enable the device.
>>>>>
>>>>> This patch is based on the R8A7791 sound work by Kuninori Morimoto.
>>>>>
>>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>>>> (snip)
>>>>> +		rcar_sound,src {
>>>>> +			src1: src at 1 {
>>>>> +				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
>>>>> +				dmas = <&audma0 0x87>, <&audma0 0x9c>;
>>>>> +				dma-names = "rx", "tx";
>>>>> +			};
>>>>> +			src2: src at 2 {
>>>>> +				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
>>>>> +				dmas = <&audma0 0x89>, <&audma0 0x9e>;
>>>>> +				dma-names = "rx", "tx";
>>>>> +			};
>>>>> +			src3: src at 3 {
>>>>> +				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
>>>>> +				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
>>>>> +				dma-names = "rx", "tx";
>>>>> +			};
>>>>> +			src4: src at 4 {
>>>>> +				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
>>>>> +				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
>>>>> +				dma-names = "rx", "tx";
>>>>> +			};
>>>>> +			src5: src at 5 {
>>>>> +				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
>>>>> +				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
>>>>> +				dma-names = "rx", "tx";
>>>>> +			};
>>>>> +			src6: src at 6 {
>>>>> +				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
>>>>> +				dmas = <&audma0 0x91>, <&audma0 0xb4>;
>>>>> +				dma-names = "rx", "tx";
>>>>> +			};
>>>>> +		};
>>>>
>>>> I think this can't work correctly, because driver is assuming
>>>> DT has all channles (from 0). (see linux/sound/soc/sh/rcar/src.c :: rsnd_src_probe)
>>>> Can you adds dummy src0 with some comments ? or fix src.c driver ?
>>>
>>> I would prefer the driver to be fixed (I had a similar patchset locally
>>> and I found it doesn't work).
>>
>>     You mean you had R8A7794 sound patch set too?
>
> Yes, I was working on it recently.
> I suppose we should coordinate these things in future to avoid
> duplicated effort.

    Yes, seems a good idea now. :-)

>>> The reason is that DT should describe
>>> the hardware rather than the current state of the software.
>>
>>     Yes, of course. Just tell me do I have to fix the driver *before* this
>> patch set is accepted?

> I did not entirely get to the bottom of the problem, but I think that at
> the very least something needs to be done about the for_each_rsnd_src()
> loop in rsnd_src_probe.

    It's not that it replies to my question. :-)
    So you're looking at this issue yourself?

> My, obviously not satisfactory, hack around there being no src0 was as follows.
>
> diff --git a/sound/soc/sh/rcar/src.c b/sound/soc/sh/rcar/src.c
> index 68b439ed22d7..58a447b0785b 100644
> --- a/sound/soc/sh/rcar/src.c
> +++ b/sound/soc/sh/rcar/src.c
> @@ -1072,7 +1072,7 @@ int rsnd_src_probe(struct platform_device *pdev,
>
>   	for_each_rsnd_src(src, priv, i) {

    Which tree is this? The recent devel branch of renesas.git has 
for_each_child_of_node() here...

>   		snprintf(name, RSND_SRC_NAME_SIZE, "%s.%d",
> -			 SRC_NAME, i);
> +			 SRC_NAME, i + 1);
>
>   		clk = devm_clk_get(dev, name);
>   		if (IS_ERR(clk))

MBR, Sergei



From horms+renesas at verge.net.au  Fri Feb 12 11:05:17 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:17 +0100
Subject: [PATCH 27/68] ARM: dts: r8a7793: add audio DMAC clocks to device tree
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <8d2883bddf47e3d59a4f041c6bd338f0d18783fe.1455303422.git.horms+renesas@verge.net.au>

Instantiate Audio DMA clocks in the r8a7791 device tree.

Based on similar work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 3531d30fe107..cb6251e71ef9 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -924,10 +924,11 @@
 		mstp5_clks: mstp5_clks at e6150144 {
 			compatible = "renesas,r8a7793-mstp-clocks", "renesas,cpg-mstp-clocks";
 			reg = <0 0xe6150144 0 4>, <0 0xe615003c 0 4>;
-			clocks = <&extal_clk>;
+			clocks = <&hp_clk>, <&hp_clk>, <&extal_clk>;
 			#clock-cells = <1>;
-			clock-indices = <R8A7793_CLK_THERMAL>;
-			clock-output-names = "thermal";
+			clock-indices = <R8A7793_CLK_AUDIO_DMAC0 R8A7793_CLK_AUDIO_DMAC1
+					 R8A7793_CLK_THERMAL>;
+			clock-output-names = "audmac0", "audmac1", "thermal";
 		};
 		mstp7_clks: mstp7_clks at e615014c {
 			compatible = "renesas,r8a7793-mstp-clocks",
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:13 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:13 +0100
Subject: [PATCH 23/68] ARM: dts: r8a7793: add audio clock to device tree
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <ad6472bf11464d498fefcea9ae30ddf9255e4f49.1455303422.git.horms+renesas@verge.net.au>

Instantiate audio clock in r8a7793 device tree.
audio_clk_a/b/c are required for R-Car sound.

Based on similar work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index c4459f147330..530fa9488a4a 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -706,6 +706,29 @@
 			clock-output-names = "extal";
 		};
 
+		/*
+		 * The external audio clocks are configured as 0 Hz fixed frequency clocks by
+		 * default. Boards that provide audio clocks should override them.
+		 */
+		audio_clk_a: audio_clk_a {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+			clock-output-names = "audio_clk_a";
+		};
+		audio_clk_b: audio_clk_b {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+			clock-output-names = "audio_clk_b";
+		};
+		audio_clk_c: audio_clk_c {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+			clock-output-names = "audio_clk_c";
+		};
+
 		/* Special CPG clocks */
 		cpg_clocks: cpg_clocks at e6150000 {
 			compatible = "renesas,r8a7793-cpg-clocks",
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:15 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:15 +0100
Subject: [PATCH 25/68] ARM: dts: r8a7793: add R-Car sound support to device
 tree
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <951431e08636858bafabb7654c3aae0eac18d950.1455303422.git.horms+renesas@verge.net.au>

Instantiate R-Car sound node in r8a7793 device tree.
This only supports PIO transfers.

Based on similar work for the r8a7791 by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 83 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 83 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 6aabba6ef92c..8b1ec47754ac 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -1101,4 +1101,87 @@
 		#iommu-cells = <1>;
 		status = "disabled";
 	};
+
+	rcar_sound: sound at ec500000 {
+		/*
+		 * #sound-dai-cells is required
+		 *
+		 * Single DAI : #sound-dai-cells = <0>;         <&rcar_sound>;
+		 * Multi  DAI : #sound-dai-cells = <1>;         <&rcar_sound N>;
+		 */
+		compatible =  "renesas,rcar_sound-r8a7793", "renesas,rcar_sound-gen2";
+		reg =	<0 0xec500000 0 0x1000>, /* SCU */
+			<0 0xec5a0000 0 0x100>,  /* ADG */
+			<0 0xec540000 0 0x1000>, /* SSIU */
+			<0 0xec541000 0 0x280>;  /* SSI */
+		reg-names = "scu", "adg", "ssiu", "ssi";
+
+		clocks = <&mstp10_clks R8A7793_CLK_SSI_ALL>,
+			<&mstp10_clks R8A7793_CLK_SSI9>, <&mstp10_clks R8A7793_CLK_SSI8>,
+			<&mstp10_clks R8A7793_CLK_SSI7>, <&mstp10_clks R8A7793_CLK_SSI6>,
+			<&mstp10_clks R8A7793_CLK_SSI5>, <&mstp10_clks R8A7793_CLK_SSI4>,
+			<&mstp10_clks R8A7793_CLK_SSI3>, <&mstp10_clks R8A7793_CLK_SSI2>,
+			<&mstp10_clks R8A7793_CLK_SSI1>, <&mstp10_clks R8A7793_CLK_SSI0>,
+			<&mstp10_clks R8A7793_CLK_SCU_SRC9>, <&mstp10_clks R8A7793_CLK_SCU_SRC8>,
+			<&mstp10_clks R8A7793_CLK_SCU_SRC7>, <&mstp10_clks R8A7793_CLK_SCU_SRC6>,
+			<&mstp10_clks R8A7793_CLK_SCU_SRC5>, <&mstp10_clks R8A7793_CLK_SCU_SRC4>,
+			<&mstp10_clks R8A7793_CLK_SCU_SRC3>, <&mstp10_clks R8A7793_CLK_SCU_SRC2>,
+			<&mstp10_clks R8A7793_CLK_SCU_SRC1>, <&mstp10_clks R8A7793_CLK_SCU_SRC0>,
+			<&audio_clk_a>, <&audio_clk_b>, <&audio_clk_c>, <&m2_clk>;
+		clock-names = "ssi-all",
+				"ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5",
+				"ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0",
+				"src.9", "src.8", "src.7", "src.6", "src.5",
+				"src.4", "src.3", "src.2", "src.1", "src.0",
+				"clk_a", "clk_b", "clk_c", "clk_i";
+		power-domains = <&cpg_clocks>;
+
+		status = "disabled";
+
+		rcar_sound,src {
+			src0: src at 0 { };
+			src1: src at 1 { };
+			src2: src at 2 { };
+			src3: src at 3 { };
+			src4: src at 4 { };
+			src5: src at 5 { };
+			src6: src at 6 { };
+			src7: src at 7 { };
+			src8: src at 8 { };
+			src9: src at 9 { };
+		};
+
+		rcar_sound,ssi {
+			ssi0: ssi at 0 {
+				interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi1: ssi at 1 {
+				 interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi2: ssi at 2 {
+				interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi3: ssi at 3 {
+				interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi4: ssi at 4 {
+				interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi5: ssi at 5 {
+				interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi6: ssi at 6 {
+				interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi7: ssi at 7 {
+				interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi8: ssi at 8 {
+				interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
+			};
+			ssi9: ssi at 9 {
+				interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
+			};
+		};
+	};
 };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:11 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:11 +0100
Subject: [PATCH 21/68] ARM: dts: r8a7740: use GIC_* defines
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <e1e7b6fa83f0d8372392662ebdffdd79c71ba6a3.1455303422.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7740 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7740.dtsi | 143 +++++++++++++++++++++--------------------
 1 file changed, 72 insertions(+), 71 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 6ef954766eef..36bcb39cca03 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -11,6 +11,7 @@
 /include/ "skeleton.dtsi"
 
 #include <dt-bindings/clock/r8a7740-clock.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/interrupt-controller/irq.h>
 
 / {
@@ -41,7 +42,7 @@
 	L2: cache-controller {
 		compatible = "arm,pl310-cache";
 		reg = <0xf0100000 0x1000>;
-		interrupts = <0 84 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
 		power-domains = <&pd_a3sm>;
 		arm,data-latency = <3 3 3>;
 		arm,tag-latency = <2 2 2>;
@@ -58,7 +59,7 @@
 
 	pmu {
 		compatible = "arm,cortex-a9-pmu";
-		interrupts = <0 83 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
 	};
 
 	ptm {
@@ -69,7 +70,7 @@
 	cmt1: timer at e6138000 {
 		compatible = "renesas,cmt-48-r8a7740", "renesas,cmt-48";
 		reg = <0xe6138000 0x170>;
-		interrupts = <0 58 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7740_CLK_CMT1>;
 		clock-names = "fck";
 		power-domains = <&pd_c5>;
@@ -89,14 +90,14 @@
 			<0xe6900020 1>,
 			<0xe6900040 1>,
 			<0xe6900060 1>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_INTCA>;
 		power-domains = <&pd_a4s>;
 	};
@@ -111,14 +112,14 @@
 			<0xe6900024 1>,
 			<0xe6900044 1>,
 			<0xe6900064 1>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_INTCA>;
 		power-domains = <&pd_a4s>;
 	};
@@ -133,14 +134,14 @@
 			<0xe6900028 1>,
 			<0xe6900048 1>,
 			<0xe6900068 1>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_INTCA>;
 		power-domains = <&pd_a4s>;
 	};
@@ -155,14 +156,14 @@
 			<0xe690002c 1>,
 			<0xe690004c 1>,
 			<0xe690006c 1>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH
-			      0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_INTCA>;
 		power-domains = <&pd_a4s>;
 	};
@@ -171,7 +172,7 @@
 		compatible = "renesas,gether-r8a7740";
 		reg = <0xe9a00000 0x800>,
 		      <0xe9a01800 0x800>;
-		interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7740_CLK_GETHER>;
 		power-domains = <&pd_a4s>;
 		phy-mode = "mii";
@@ -185,10 +186,10 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7740", "renesas,rmobile-iic";
 		reg = <0xfff20000 0x425>;
-		interrupts = <0 201 IRQ_TYPE_LEVEL_HIGH
-			      0 202 IRQ_TYPE_LEVEL_HIGH
-			      0 203 IRQ_TYPE_LEVEL_HIGH
-			      0 204 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7740_CLK_IIC0>;
 		power-domains = <&pd_a4r>;
 		status = "disabled";
@@ -199,10 +200,10 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a7740", "renesas,rmobile-iic";
 		reg = <0xe6c20000 0x425>;
-		interrupts = <0 70 IRQ_TYPE_LEVEL_HIGH
-			      0 71 IRQ_TYPE_LEVEL_HIGH
-			      0 72 IRQ_TYPE_LEVEL_HIGH
-			      0 73 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7740_CLK_IIC1>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -211,7 +212,7 @@
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6c40000 0x100>;
-		interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA0>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -221,7 +222,7 @@
 	scifa1: serial at e6c50000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6c50000 0x100>;
-		interrupts = <0 101 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA1>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -231,7 +232,7 @@
 	scifa2: serial at e6c60000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6c60000 0x100>;
-		interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA2>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -241,7 +242,7 @@
 	scifa3: serial at e6c70000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6c70000 0x100>;
-		interrupts = <0 103 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA3>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -251,7 +252,7 @@
 	scifa4: serial at e6c80000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6c80000 0x100>;
-		interrupts = <0 104 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA4>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -261,7 +262,7 @@
 	scifa5: serial at e6cb0000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6cb0000 0x100>;
-		interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA5>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -271,7 +272,7 @@
 	scifa6: serial at e6cc0000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6cc0000 0x100>;
-		interrupts = <0 106 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA6>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -281,7 +282,7 @@
 	scifa7: serial at e6cd0000 {
 		compatible = "renesas,scifa-r8a7740", "renesas,scifa";
 		reg = <0xe6cd0000 0x100>;
-		interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFA7>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -291,7 +292,7 @@
 	scifb: serial at e6c30000 {
 		compatible = "renesas,scifb-r8a7740", "renesas,scifb";
 		reg = <0xe6c30000 0x100>;
-		interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7740_CLK_SCIFB>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -329,8 +330,8 @@
 	mmcif0: mmc at e6bd0000 {
 		compatible = "renesas,mmcif-r8a7740", "renesas,sh-mmcif";
 		reg = <0xe6bd0000 0x100>;
-		interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH
-			      0 57 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7740_CLK_MMC>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -339,9 +340,9 @@
 	sdhi0: sd at e6850000 {
 		compatible = "renesas,sdhi-r8a7740";
 		reg = <0xe6850000 0x100>;
-		interrupts = <0 117 IRQ_TYPE_LEVEL_HIGH
-			      0 118 IRQ_TYPE_LEVEL_HIGH
-			      0 119 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7740_CLK_SDHI0>;
 		power-domains = <&pd_a3sp>;
 		cap-sd-highspeed;
@@ -352,9 +353,9 @@
 	sdhi1: sd at e6860000 {
 		compatible = "renesas,sdhi-r8a7740";
 		reg = <0xe6860000 0x100>;
-		interrupts = <0 121 IRQ_TYPE_LEVEL_HIGH
-			      0 122 IRQ_TYPE_LEVEL_HIGH
-			      0 123 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A7740_CLK_SDHI1>;
 		power-domains = <&pd_a3sp>;
 		cap-sd-highspeed;
@@ -365,9 +366,9 @@
 	sdhi2: sd at e6870000 {
 		compatible = "renesas,sdhi-r8a7740";
 		reg = <0xe6870000 0x100>;
-		interrupts = <0 125 IRQ_TYPE_LEVEL_HIGH
-			      0 126 IRQ_TYPE_LEVEL_HIGH
-			      0 127 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH
+			      GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A7740_CLK_SDHI2>;
 		power-domains = <&pd_a3sp>;
 		cap-sd-highspeed;
@@ -379,7 +380,7 @@
 		#sound-dai-cells = <1>;
 		compatible = "renesas,fsi2-r8a7740", "renesas,sh_fsi2";
 		reg = <0xfe1f0000 0x400>;
-		interrupts = <0 9 0x4>;
+		interrupts = <GIC_SPI 9 0x4>;
 		clocks = <&mstp3_clks R8A7740_CLK_FSI>;
 		power-domains = <&pd_a4mp>;
 		status = "disabled";
@@ -388,9 +389,9 @@
 	tmu0: timer at fff80000 {
 		compatible = "renesas,tmu-r8a7740", "renesas,tmu";
 		reg = <0xfff80000 0x2c>;
-		interrupts = <0 198 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 199 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 200 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 199 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7740_CLK_TMU0>;
 		clock-names = "fck";
 		power-domains = <&pd_a4r>;
@@ -403,9 +404,9 @@
 	tmu1: timer at fff90000 {
 		compatible = "renesas,tmu-r8a7740", "renesas,tmu";
 		reg = <0xfff90000 0x2c>;
-		interrupts = <0 170 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 171 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 172 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7740_CLK_TMU1>;
 		clock-names = "fck";
 		power-domains = <&pd_a4r>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:10 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:10 +0100
Subject: [PATCH 20/68] ARM: dts: r8a73a4: use GIC_* defines
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <4d5746a3ec3a705028aeb81b34fbca70e523668a.1455303422.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a73a4 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a73a4.dtsi | 212 ++++++++++++++++++++---------------------
 1 file changed, 106 insertions(+), 106 deletions(-)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index cb4f7b2798fe..64f3efcd7ba5 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -39,10 +39,10 @@
 
 	timer {
 		compatible = "arm,armv7-timer";
-		interrupts = <1 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-			     <1 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
 	};
 
 	dbsc1: memory-controller at e6790000 {
@@ -69,27 +69,27 @@
 		dma0: dma-controller at e6700020 {
 			compatible = "renesas,shdma-r8a73a4";
 			reg = <0 0xe6700020 0 0x89e0>;
-			interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH
-					0 200 IRQ_TYPE_LEVEL_HIGH
-					0 201 IRQ_TYPE_LEVEL_HIGH
-					0 202 IRQ_TYPE_LEVEL_HIGH
-					0 203 IRQ_TYPE_LEVEL_HIGH
-					0 204 IRQ_TYPE_LEVEL_HIGH
-					0 205 IRQ_TYPE_LEVEL_HIGH
-					0 206 IRQ_TYPE_LEVEL_HIGH
-					0 207 IRQ_TYPE_LEVEL_HIGH
-					0 208 IRQ_TYPE_LEVEL_HIGH
-					0 209 IRQ_TYPE_LEVEL_HIGH
-					0 210 IRQ_TYPE_LEVEL_HIGH
-					0 211 IRQ_TYPE_LEVEL_HIGH
-					0 212 IRQ_TYPE_LEVEL_HIGH
-					0 213 IRQ_TYPE_LEVEL_HIGH
-					0 214 IRQ_TYPE_LEVEL_HIGH
-					0 215 IRQ_TYPE_LEVEL_HIGH
-					0 216 IRQ_TYPE_LEVEL_HIGH
-					0 217 IRQ_TYPE_LEVEL_HIGH
-					0 218 IRQ_TYPE_LEVEL_HIGH
-					0 219 IRQ_TYPE_LEVEL_HIGH>;
+			interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+					GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "error",
 					"ch0", "ch1", "ch2", "ch3",
 					"ch4", "ch5", "ch6", "ch7",
@@ -106,7 +106,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe60b0000 0 0x428>;
-		interrupts = <0 179 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A73A4_CLK_IIC5>;
 		power-domains = <&pd_a3sp>;
 
@@ -116,7 +116,7 @@
 	cmt1: timer at e6130000 {
 		compatible = "renesas,cmt-48-r8a73a4", "renesas,cmt-48-gen2";
 		reg = <0 0xe6130000 0 0x1004>;
-		interrupts = <0 120 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_CMT1>;
 		clock-names = "fck";
 		power-domains = <&pd_c5>;
@@ -131,38 +131,38 @@
 		#interrupt-cells = <2>;
 		interrupt-controller;
 		reg = <0 0xe61c0000 0 0x200>;
-		interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 1 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 2 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 3 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 4 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 5 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 6 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 7 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 8 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 9 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 10 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 11 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 12 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 13 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 14 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 15 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 16 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 17 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 18 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 19 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 20 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 21 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 22 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 23 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 24 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 25 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 26 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 27 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 28 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 29 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 30 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 31 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A73A4_CLK_IRQC>;
 		power-domains = <&pd_c4>;
 	};
@@ -172,32 +172,32 @@
 		#interrupt-cells = <2>;
 		interrupt-controller;
 		reg = <0 0xe61c0200 0 0x200>;
-		interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 33 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 34 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 35 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 36 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 37 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 38 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 39 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 40 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 41 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 42 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 43 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 44 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 45 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 46 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 47 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 48 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 49 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 50 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 51 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 52 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 53 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 54 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 55 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 56 IRQ_TYPE_LEVEL_HIGH>,
-			     <0 57 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A73A4_CLK_IRQC>;
 		power-domains = <&pd_c4>;
 	};
@@ -237,7 +237,7 @@
 		compatible = "renesas,thermal-r8a73a4", "renesas,rcar-thermal";
 		reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>,
 			 <0 0xe61f0200 0 0x38>, <0 0xe61f0300 0 0x38>;
-		interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks R8A73A4_CLK_THERMAL>;
 		power-domains = <&pd_c5>;
 	};
@@ -247,7 +247,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6500000 0 0x428>;
-		interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_IIC0>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -258,7 +258,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6510000 0 0x428>;
-		interrupts = <0 175 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_IIC1>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -269,7 +269,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6520000 0 0x428>;
-		interrupts = <0 176 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_IIC2>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -280,7 +280,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6530000 0 0x428>;
-		interrupts = <0 177 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A73A4_CLK_IIC3>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -291,7 +291,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6540000 0 0x428>;
-		interrupts = <0 178 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R8A73A4_CLK_IIC4>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -302,7 +302,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6550000 0 0x428>;
-		interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_IIC6>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -313,7 +313,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6560000 0 0x428>;
-		interrupts = <0 185 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_IIC7>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -324,7 +324,7 @@
 		#size-cells = <0>;
 		compatible = "renesas,iic-r8a73a4", "renesas,rmobile-iic";
 		reg = <0 0xe6570000 0 0x428>;
-		interrupts = <0 173 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks R8A73A4_CLK_IIC8>;
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
@@ -333,7 +333,7 @@
 	scifb0: serial at e6c20000 {
 		compatible = "renesas,scifb-r8a73a4", "renesas,scifb";
 		reg = <0 0xe6c20000 0 0x100>;
-		interrupts = <0 148 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB0>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -343,7 +343,7 @@
 	scifb1: serial at e6c30000 {
 		compatible = "renesas,scifb-r8a73a4", "renesas,scifb";
 		reg = <0 0xe6c30000 0 0x100>;
-		interrupts = <0 149 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB1>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -353,7 +353,7 @@
 	scifa0: serial at e6c40000 {
 		compatible = "renesas,scifa-r8a73a4", "renesas,scifa";
 		reg = <0 0xe6c40000 0 0x100>;
-		interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFA0>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -363,7 +363,7 @@
 	scifa1: serial at e6c50000 {
 		compatible = "renesas,scifa-r8a73a4", "renesas,scifa";
 		reg = <0 0xe6c50000 0 0x100>;
-		interrupts = <0 145 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFA1>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -373,7 +373,7 @@
 	scifb2: serial at e6ce0000 {
 		compatible = "renesas,scifb-r8a73a4", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 0x100>;
-		interrupts = <0 150 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB2>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_a3sp>;
@@ -383,7 +383,7 @@
 	scifb3: serial at e6cf0000 {
 		compatible = "renesas,scifb-r8a73a4", "renesas,scifb";
 		reg = <0 0xe6cf0000 0 0x100>;
-		interrupts = <0 151 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB3>;
 		clock-names = "sci_ick";
 		power-domains = <&pd_c4>;
@@ -393,7 +393,7 @@
 	sdhi0: sd at ee100000 {
 		compatible = "renesas,sdhi-r8a73a4";
 		reg = <0 0xee100000 0 0x100>;
-		interrupts = <0 165 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_SDHI0>;
 		power-domains = <&pd_a3sp>;
 		cap-sd-highspeed;
@@ -403,7 +403,7 @@
 	sdhi1: sd at ee120000 {
 		compatible = "renesas,sdhi-r8a73a4";
 		reg = <0 0xee120000 0 0x100>;
-		interrupts = <0 166 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_SDHI1>;
 		power-domains = <&pd_a3sp>;
 		cap-sd-highspeed;
@@ -413,7 +413,7 @@
 	sdhi2: sd at ee140000 {
 		compatible = "renesas,sdhi-r8a73a4";
 		reg = <0 0xee140000 0 0x100>;
-		interrupts = <0 167 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_SDHI2>;
 		power-domains = <&pd_a3sp>;
 		cap-sd-highspeed;
@@ -423,7 +423,7 @@
 	mmcif0: mmc at ee200000 {
 		compatible = "renesas,sh-mmcif";
 		reg = <0 0xee200000 0 0x80>;
-		interrupts = <0 169 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_MMCIF0>;
 		power-domains = <&pd_a3sp>;
 		reg-io-width = <4>;
@@ -433,7 +433,7 @@
 	mmcif1: mmc at ee220000 {
 		compatible = "renesas,sh-mmcif";
 		reg = <0 0xee220000 0 0x80>;
-		interrupts = <0 170 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks R8A73A4_CLK_MMCIF1>;
 		power-domains = <&pd_a3sp>;
 		reg-io-width = <4>;
@@ -449,7 +449,7 @@
 			<0 0xf1002000 0 0x1000>,
 			<0 0xf1004000 0 0x2000>,
 			<0 0xf1006000 0 0x2000>;
-		interrupts = <1 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
 	};
 
 	bsc: bus at fec10000 {
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:22 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:22 +0100
Subject: [PATCH 32/68] ARM: dts: gose: enable sound DMA support via BUSIF in
 device tree
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <402586d0cce05317100356cfd73f0c044c60ccd7.1455303422.git.horms+renesas@verge.net.au>

Enable DMA transfer to/from SSIU in gose/r8a7791 device tree.

     DMA
[MEM] -> [SSIU] -> [SSI]

     DMA
[MEM] <- [SSIU] <- [SSI]

Based on similar work for the r8a7791/koelsch by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index a4b2dcb8e73d..81bfe9484bbc 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -407,11 +407,6 @@
 	};
 };
 
-&ssi0 {
-	no-busif;
-};
-
 &ssi1 {
-	no-busif;
 	shared-pin;
 };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:23 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:23 +0100
Subject: [PATCH 33/68] ARM: dts: gose: enable sound DMA support via SRC in
 device tree
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <d2cde3b6103678a4f3d2079af744937dfc9c4104.1455303422.git.horms+renesas@verge.net.au>

Enable DMA transfer to/from SRC in r8a7793/gose device tree.

     DMA      DMApp
[MEM] -> [SRC] -> [SSIU] -> [SSI]

     DMA      DMApp
[MEM] <- [SRC] <- [SSIU] <- [SSI]

Current sound driver is supporting
SSI/SRC random connection.
So, this patch is tring
SSI0 -> SRC2
SSI1 <- SRC3

Based on similar work for the r8a7791/koeslch by Kuninori Morimoto.

Cc: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index 81bfe9484bbc..17c87fe0944f 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -401,8 +401,8 @@
 
 	rcar_sound,dai {
 		dai0 {
-			playback = <&ssi0>;
-			capture  = <&ssi1>;
+			playback = <&ssi0 &src2>;
+			capture  = <&ssi1 &src3>;
 		};
 	};
 };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:33 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:33 +0100
Subject: [PATCH 43/68] ARM: dts: r8a7793: Add SCIF fallback compatibility
 strings
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <3ffc90a3e97771e0bd5402a52962f3d91c2bb27a.1455303422.git.horms+renesas@verge.net.au>

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

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 6817f14314e2..b49f9271ceb3 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -479,7 +479,8 @@
 	};
 
 	scifa0: serial at e6c40000 {
-		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7793",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA0>;
@@ -491,7 +492,8 @@
 	};
 
 	scifa1: serial at e6c50000 {
-		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7793",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA1>;
@@ -503,7 +505,8 @@
 	};
 
 	scifa2: serial at e6c60000 {
-		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7793",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA2>;
@@ -515,7 +518,8 @@
 	};
 
 	scifa3: serial at e6c70000 {
-		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7793",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c70000 0 64>;
 		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA3>;
@@ -527,7 +531,8 @@
 	};
 
 	scifa4: serial at e6c78000 {
-		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7793",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c78000 0 64>;
 		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA4>;
@@ -539,7 +544,8 @@
 	};
 
 	scifa5: serial at e6c80000 {
-		compatible = "renesas,scifa-r8a7793", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7793",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c80000 0 64>;
 		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA5>;
@@ -551,7 +557,8 @@
 	};
 
 	scifb0: serial at e6c20000 {
-		compatible = "renesas,scifb-r8a7793", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7793",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB0>;
@@ -563,7 +570,8 @@
 	};
 
 	scifb1: serial at e6c30000 {
-		compatible = "renesas,scifb-r8a7793", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7793",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB1>;
@@ -575,7 +583,8 @@
 	};
 
 	scifb2: serial at e6ce0000 {
-		compatible = "renesas,scifb-r8a7793", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7793",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB2>;
@@ -587,7 +596,8 @@
 	};
 
 	scif0: serial at e6e60000 {
-		compatible = "renesas,scif-r8a7793", "renesas,scif";
+		compatible = "renesas,scif-r8a7793", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF0>;
@@ -599,7 +609,8 @@
 	};
 
 	scif1: serial at e6e68000 {
-		compatible = "renesas,scif-r8a7793", "renesas,scif";
+		compatible = "renesas,scif-r8a7793", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF1>;
@@ -611,7 +622,8 @@
 	};
 
 	scif2: serial at e6e58000 {
-		compatible = "renesas,scif-r8a7793", "renesas,scif";
+		compatible = "renesas,scif-r8a7793", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF2>;
@@ -623,7 +635,8 @@
 	};
 
 	scif3: serial at e6ea8000 {
-		compatible = "renesas,scif-r8a7793", "renesas,scif";
+		compatible = "renesas,scif-r8a7793", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF3>;
@@ -635,7 +648,8 @@
 	};
 
 	scif4: serial at e6ee0000 {
-		compatible = "renesas,scif-r8a7793", "renesas,scif";
+		compatible = "renesas,scif-r8a7793", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF4>;
@@ -647,7 +661,8 @@
 	};
 
 	scif5: serial at e6ee8000 {
-		compatible = "renesas,scif-r8a7793", "renesas,scif";
+		compatible = "renesas,scif-r8a7793", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF5>;
@@ -659,7 +674,8 @@
 	};
 
 	hscif0: serial at e62c0000 {
-		compatible = "renesas,hscif-r8a7793", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7793",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF0>;
@@ -671,7 +687,8 @@
 	};
 
 	hscif1: serial at e62c8000 {
-		compatible = "renesas,hscif-r8a7793", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7793",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF1>;
@@ -683,7 +700,8 @@
 	};
 
 	hscif2: serial at e62d0000 {
-		compatible = "renesas,hscif-r8a7793", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7793",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF2>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:32 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:32 +0100
Subject: [PATCH 42/68] ARM: dts: r8a7791: Add SCIF fallback compatibility
 strings
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <b5b52dd7d014eea55ba122ae8eaf142f6f902aae.1455303422.git.horms+renesas@verge.net.au>

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

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791.dtsi | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 6b3b02c0c58a..e7537ba68b5e 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -564,7 +564,8 @@
 	};
 
 	scifa0: serial at e6c40000 {
-		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7791",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA0>;
@@ -576,7 +577,8 @@
 	};
 
 	scifa1: serial at e6c50000 {
-		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7791",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA1>;
@@ -588,7 +590,8 @@
 	};
 
 	scifa2: serial at e6c60000 {
-		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7791",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA2>;
@@ -600,7 +603,8 @@
 	};
 
 	scifa3: serial at e6c70000 {
-		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7791",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c70000 0 64>;
 		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA3>;
@@ -612,7 +616,8 @@
 	};
 
 	scifa4: serial at e6c78000 {
-		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7791",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c78000 0 64>;
 		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA4>;
@@ -624,7 +629,8 @@
 	};
 
 	scifa5: serial at e6c80000 {
-		compatible = "renesas,scifa-r8a7791", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7791",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c80000 0 64>;
 		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA5>;
@@ -636,7 +642,8 @@
 	};
 
 	scifb0: serial at e6c20000 {
-		compatible = "renesas,scifb-r8a7791", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7791",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB0>;
@@ -648,7 +655,8 @@
 	};
 
 	scifb1: serial at e6c30000 {
-		compatible = "renesas,scifb-r8a7791", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7791",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB1>;
@@ -660,7 +668,8 @@
 	};
 
 	scifb2: serial at e6ce0000 {
-		compatible = "renesas,scifb-r8a7791", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7791",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB2>;
@@ -672,7 +681,8 @@
 	};
 
 	scif0: serial at e6e60000 {
-		compatible = "renesas,scif-r8a7791", "renesas,scif";
+		compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF0>;
@@ -684,7 +694,8 @@
 	};
 
 	scif1: serial at e6e68000 {
-		compatible = "renesas,scif-r8a7791", "renesas,scif";
+		compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF1>;
@@ -696,7 +707,8 @@
 	};
 
 	scif2: serial at e6e58000 {
-		compatible = "renesas,scif-r8a7791", "renesas,scif";
+		compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF2>;
@@ -708,7 +720,8 @@
 	};
 
 	scif3: serial at e6ea8000 {
-		compatible = "renesas,scif-r8a7791", "renesas,scif";
+		compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF3>;
@@ -720,7 +733,8 @@
 	};
 
 	scif4: serial at e6ee0000 {
-		compatible = "renesas,scif-r8a7791", "renesas,scif";
+		compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF4>;
@@ -732,7 +746,8 @@
 	};
 
 	scif5: serial at e6ee8000 {
-		compatible = "renesas,scif-r8a7791", "renesas,scif";
+		compatible = "renesas,scif-r8a7791", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF5>;
@@ -744,7 +759,8 @@
 	};
 
 	hscif0: serial at e62c0000 {
-		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7791",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF0>;
@@ -756,7 +772,8 @@
 	};
 
 	hscif1: serial at e62c8000 {
-		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7791",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF1>;
@@ -768,7 +785,8 @@
 	};
 
 	hscif2: serial at e62d0000 {
-		compatible = "renesas,hscif-r8a7791", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7791",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF2>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:34 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:34 +0100
Subject: [PATCH 44/68] ARM: dts: r8a7794: Add SCIF fallback compatibility
 strings
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <06930a1f9d875e42e17e408dd26240f7fa4e49b9.1455303422.git.horms+renesas@verge.net.au>

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

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794.dtsi | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 21be4bdc4001..a49bf303a02d 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -282,7 +282,8 @@
 	};
 
 	scifa0: serial at e6c40000 {
-		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7794",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA0>;
@@ -294,7 +295,8 @@
 	};
 
 	scifa1: serial at e6c50000 {
-		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7794",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA1>;
@@ -306,7 +308,8 @@
 	};
 
 	scifa2: serial at e6c60000 {
-		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7794",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA2>;
@@ -318,7 +321,8 @@
 	};
 
 	scifa3: serial at e6c70000 {
-		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7794",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c70000 0 64>;
 		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA3>;
@@ -330,7 +334,8 @@
 	};
 
 	scifa4: serial at e6c78000 {
-		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7794",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c78000 0 64>;
 		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA4>;
@@ -342,7 +347,8 @@
 	};
 
 	scifa5: serial at e6c80000 {
-		compatible = "renesas,scifa-r8a7794", "renesas,scifa";
+		compatible = "renesas,scifa-r8a7794",
+			     "renesas,rcar-gen2-scifa", "renesas,scifa";
 		reg = <0 0xe6c80000 0 64>;
 		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA5>;
@@ -354,7 +360,8 @@
 	};
 
 	scifb0: serial at e6c20000 {
-		compatible = "renesas,scifb-r8a7794", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7794",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB0>;
@@ -366,7 +373,8 @@
 	};
 
 	scifb1: serial at e6c30000 {
-		compatible = "renesas,scifb-r8a7794", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7794",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB1>;
@@ -378,7 +386,8 @@
 	};
 
 	scifb2: serial at e6ce0000 {
-		compatible = "renesas,scifb-r8a7794", "renesas,scifb";
+		compatible = "renesas,scifb-r8a7794",
+			     "renesas,rcar-gen2-scifb", "renesas,scifb";
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB2>;
@@ -390,7 +399,8 @@
 	};
 
 	scif0: serial at e6e60000 {
-		compatible = "renesas,scif-r8a7794", "renesas,scif";
+		compatible = "renesas,scif-r8a7794", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF0>;
@@ -402,7 +412,8 @@
 	};
 
 	scif1: serial at e6e68000 {
-		compatible = "renesas,scif-r8a7794", "renesas,scif";
+		compatible = "renesas,scif-r8a7794", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF1>;
@@ -414,7 +425,8 @@
 	};
 
 	scif2: serial at e6e58000 {
-		compatible = "renesas,scif-r8a7794", "renesas,scif";
+		compatible = "renesas,scif-r8a7794", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF2>;
@@ -426,7 +438,8 @@
 	};
 
 	scif3: serial at e6ea8000 {
-		compatible = "renesas,scif-r8a7794", "renesas,scif";
+		compatible = "renesas,scif-r8a7794", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF3>;
@@ -438,7 +451,8 @@
 	};
 
 	scif4: serial at e6ee0000 {
-		compatible = "renesas,scif-r8a7794", "renesas,scif";
+		compatible = "renesas,scif-r8a7794", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF4>;
@@ -450,7 +464,8 @@
 	};
 
 	scif5: serial at e6ee8000 {
-		compatible = "renesas,scif-r8a7794", "renesas,scif";
+		compatible = "renesas,scif-r8a7794", "renesas,rcar-gen2-scif",
+			     "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF5>;
@@ -462,7 +477,8 @@
 	};
 
 	hscif0: serial at e62c0000 {
-		compatible = "renesas,hscif-r8a7794", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7794",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF0>;
@@ -474,7 +490,8 @@
 	};
 
 	hscif1: serial at e62c8000 {
-		compatible = "renesas,hscif-r8a7794", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7794",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF1>;
@@ -486,7 +503,8 @@
 	};
 
 	hscif2: serial at e62d0000 {
-		compatible = "renesas,hscif-r8a7794", "renesas,hscif";
+		compatible = "renesas,hscif-r8a7794",
+			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF2>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:35 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:35 +0100
Subject: [PATCH 45/68] ARM: dts: sh73a0: Rename the serial port clock to fck
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <46ae0e376b0dfe827ed7b675ff24a98d5f525c8a.1455303422.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/sh73a0.dtsi | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index 453280c41d27..bf825ca4f6f7 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -359,7 +359,7 @@
 		reg = <0xe6c40000 0x100>;
 		interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -369,7 +369,7 @@
 		reg = <0xe6c50000 0x100>;
 		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -379,7 +379,7 @@
 		reg = <0xe6c60000 0x100>;
 		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -389,7 +389,7 @@
 		reg = <0xe6c70000 0x100>;
 		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -399,7 +399,7 @@
 		reg = <0xe6c80000 0x100>;
 		interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -409,7 +409,7 @@
 		reg = <0xe6cb0000 0x100>;
 		interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -419,7 +419,7 @@
 		reg = <0xe6cc0000 0x100>;
 		interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp3_clks SH73A0_CLK_SCIFA6>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -429,7 +429,7 @@
 		reg = <0xe6cd0000 0x100>;
 		interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFA7>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -439,7 +439,7 @@
 		reg = <0xe6c30000 0x100>;
 		interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks SH73A0_CLK_SCIFB>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:36 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:36 +0100
Subject: [PATCH 46/68] ARM: dts: r7s72100: Rename the serial port clock to fck
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <92489120be987cb83a23d3c6ea013501f438c41e.1455303422.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r7s72100.dtsi | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
index a5938c72d5bd..89e46ebef1bc 100644
--- a/arch/arm/boot/dts/r7s72100.dtsi
+++ b/arch/arm/boot/dts/r7s72100.dtsi
@@ -158,7 +158,7 @@
 			     <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -171,7 +171,7 @@
 			     <GIC_SPI 196 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -184,7 +184,7 @@
 			     <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -197,7 +197,7 @@
 			     <GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -210,7 +210,7 @@
 			     <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -223,7 +223,7 @@
 			     <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -236,7 +236,7 @@
 			     <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF6>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -249,7 +249,7 @@
 			     <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH>,
 			     <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp4_clks R7S72100_CLK_SCIF7>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:37 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:37 +0100
Subject: [PATCH 47/68] ARM: dts: r8a73a4: Rename the serial port clock to fck
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <d4be2f1bfdf7f2f6b3551d783edf676e9af00815.1455303422.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a73a4.dtsi | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 64f3efcd7ba5..138414a7d170 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -335,7 +335,7 @@
 		reg = <0 0xe6c20000 0 0x100>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -345,7 +345,7 @@
 		reg = <0 0xe6c30000 0 0x100>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -355,7 +355,7 @@
 		reg = <0 0xe6c40000 0 0x100>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFA0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -365,7 +365,7 @@
 		reg = <0 0xe6c50000 0 0x100>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFA1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -375,7 +375,7 @@
 		reg = <0 0xe6ce0000 0 0x100>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_a3sp>;
 		status = "disabled";
 	};
@@ -385,7 +385,7 @@
 		reg = <0 0xe6cf0000 0 0x100>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A73A4_CLK_SCIFB3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&pd_c4>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:40 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:40 +0100
Subject: [PATCH 50/68] ARM: dts: r8a7779: Rename the serial port clock to fck
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <b406f38d4b4d06f617d4e2a826abadda7327b652.1455303422.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779.dtsi | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 1671839f55a6..8fddfae13865 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -216,7 +216,7 @@
 		reg = <0xffe40000 0x100>;
 		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -227,7 +227,7 @@
 		reg = <0xffe41000 0x100>;
 		interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -238,7 +238,7 @@
 		reg = <0xffe42000 0x100>;
 		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -249,7 +249,7 @@
 		reg = <0xffe43000 0x100>;
 		interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -260,7 +260,7 @@
 		reg = <0xffe44000 0x100>;
 		interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -271,7 +271,7 @@
 		reg = <0xffe45000 0x100>;
 		interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7779_CLK_SCIF5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:39 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:39 +0100
Subject: [PATCH 49/68] ARM: dts: r8a7778: Rename the serial port clock to fck
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <258b3c31897cefca8430b5d1de4ccbab0049efbc.1455303422.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7778.dtsi | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index 8ea1792c5146..50784e2b632d 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -302,7 +302,7 @@
 		reg = <0xffe40000 0x100>;
 		interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -313,7 +313,7 @@
 		reg = <0xffe41000 0x100>;
 		interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -324,7 +324,7 @@
 		reg = <0xffe42000 0x100>;
 		interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -335,7 +335,7 @@
 		reg = <0xffe43000 0x100>;
 		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -346,7 +346,7 @@
 		reg = <0xffe44000 0x100>;
 		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -357,7 +357,7 @@
 		reg = <0xffe45000 0x100>;
 		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp0_clks R8A7778_CLK_SCIF5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:41 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:41 +0100
Subject: [PATCH 51/68] ARM: dts: r8a7790: Rename the serial port clock to fck
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <6c6e12a1f90d9b1cc5ae7428f43aeee33049c2ee.1455303422.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 1d94dfd53141..c5672745a1e5 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -590,7 +590,7 @@
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -603,7 +603,7 @@
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -616,7 +616,7 @@
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFA2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -629,7 +629,7 @@
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -642,7 +642,7 @@
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -655,7 +655,7 @@
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7790_CLK_SCIFB2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -668,7 +668,7 @@
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_SCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -681,7 +681,7 @@
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_SCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -694,7 +694,7 @@
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -707,7 +707,7 @@
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7790_CLK_HSCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:44 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:44 +0100
Subject: [PATCH 54/68] ARM: dts: r8a7794: Rename the serial port clock to fck
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <1b463bd51042927e041775dc1ca5af63e7e5592b.1455303422.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794.dtsi | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index a49bf303a02d..b03a77b3d22f 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -287,7 +287,7 @@
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -300,7 +300,7 @@
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -313,7 +313,7 @@
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFA2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -326,7 +326,7 @@
 		reg = <0 0xe6c70000 0 64>;
 		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1b>, <&dmac0 0x1c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -339,7 +339,7 @@
 		reg = <0 0xe6c78000 0 64>;
 		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1f>, <&dmac0 0x20>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -352,7 +352,7 @@
 		reg = <0 0xe6c80000 0 64>;
 		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7794_CLK_SCIFA5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x23>, <&dmac0 0x24>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -365,7 +365,7 @@
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -378,7 +378,7 @@
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -391,7 +391,7 @@
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7794_CLK_SCIFB2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -404,7 +404,7 @@
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -417,7 +417,7 @@
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -430,7 +430,7 @@
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -443,7 +443,7 @@
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -456,7 +456,7 @@
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -469,7 +469,7 @@
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_SCIF5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -482,7 +482,7 @@
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -495,7 +495,7 @@
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -508,7 +508,7 @@
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7794_CLK_HSCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:42 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:42 +0100
Subject: [PATCH 52/68] ARM: dts: r8a7791: Rename the serial port clock to fck
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <bb7ca1952e120aba212538563c3ecd476a6a22f5.1455303422.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791.dtsi | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index e7537ba68b5e..194e9464b748 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -569,7 +569,7 @@
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -582,7 +582,7 @@
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -595,7 +595,7 @@
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFA2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -608,7 +608,7 @@
 		reg = <0 0xe6c70000 0 64>;
 		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1b>, <&dmac0 0x1c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -621,7 +621,7 @@
 		reg = <0 0xe6c78000 0 64>;
 		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1f>, <&dmac0 0x20>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -634,7 +634,7 @@
 		reg = <0 0xe6c80000 0 64>;
 		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7791_CLK_SCIFA5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x23>, <&dmac0 0x24>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -647,7 +647,7 @@
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -660,7 +660,7 @@
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -673,7 +673,7 @@
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7791_CLK_SCIFB2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -686,7 +686,7 @@
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -699,7 +699,7 @@
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -712,7 +712,7 @@
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -725,7 +725,7 @@
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -738,7 +738,7 @@
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -751,7 +751,7 @@
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_SCIF5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -764,7 +764,7 @@
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -777,7 +777,7 @@
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -790,7 +790,7 @@
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7791_CLK_HSCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:45 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:45 +0100
Subject: [PATCH 55/68] ARM: dts: r8a7778: Add BRG support for SCIF
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <5fb544da5f9a77ef723b685181d4e763f6a1b2eb.1455303422.git.horms+renesas@verge.net.au>

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

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depends on
the actual board.

Add the two optional clock sources (S1 and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF device nodes.

This increases the range and accuracy of supported baud rates on SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7778.dtsi | 39 +++++++++++++++++++++++++++------------
 1 file changed, 27 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index 50784e2b632d..f83a348fc07a 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -301,8 +301,9 @@
 			     "renesas,scif";
 		reg = <0xffe40000 0x100>;
 		interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7778_CLK_SCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7778_CLK_SCIF0>,
+			 <&cpg_clocks R8A7778_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -312,8 +313,9 @@
 			     "renesas,scif";
 		reg = <0xffe41000 0x100>;
 		interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7778_CLK_SCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7778_CLK_SCIF1>,
+			 <&cpg_clocks R8A7778_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -323,8 +325,9 @@
 			     "renesas,scif";
 		reg = <0xffe42000 0x100>;
 		interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7778_CLK_SCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7778_CLK_SCIF2>,
+			 <&cpg_clocks R8A7778_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -334,8 +337,9 @@
 			     "renesas,scif";
 		reg = <0xffe43000 0x100>;
 		interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7778_CLK_SCIF3>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7778_CLK_SCIF3>,
+			 <&cpg_clocks R8A7778_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -345,8 +349,9 @@
 			     "renesas,scif";
 		reg = <0xffe44000 0x100>;
 		interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7778_CLK_SCIF4>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7778_CLK_SCIF4>,
+			 <&cpg_clocks R8A7778_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -356,8 +361,9 @@
 			     "renesas,scif";
 		reg = <0xffe45000 0x100>;
 		interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7778_CLK_SCIF5>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7778_CLK_SCIF5>,
+			 <&cpg_clocks R8A7778_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -444,6 +450,15 @@
 			clock-output-names = "extal";
 		};
 
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+			status = "disabled";
+		};
+
 		/* Special CPG clocks */
 		cpg_clocks: cpg_clocks at ffc80000 {
 			compatible = "renesas,r8a7778-cpg-clocks";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:43 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:43 +0100
Subject: [PATCH 53/68] ARM: dts: r8a7793: Rename the serial port clock to fck
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <48f27c190c475d2b83d0d1c464f0ced6c5b17838.1455303422.git.horms+renesas@verge.net.au>

From: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>

The clock is really the device functional clock, not the interface
clock. Rename it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas at ideasonboard.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index b49f9271ceb3..07af584915c6 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -484,7 +484,7 @@
 		reg = <0 0xe6c40000 0 64>;
 		interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x21>, <&dmac0 0x22>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -497,7 +497,7 @@
 		reg = <0 0xe6c50000 0 64>;
 		interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x25>, <&dmac0 0x26>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -510,7 +510,7 @@
 		reg = <0 0xe6c60000 0 64>;
 		interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFA2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x27>, <&dmac0 0x28>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -523,7 +523,7 @@
 		reg = <0 0xe6c70000 0 64>;
 		interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1b>, <&dmac0 0x1c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -536,7 +536,7 @@
 		reg = <0 0xe6c78000 0 64>;
 		interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1f>, <&dmac0 0x20>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -549,7 +549,7 @@
 		reg = <0 0xe6c80000 0 64>;
 		interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp11_clks R8A7793_CLK_SCIFA5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x23>, <&dmac0 0x24>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -562,7 +562,7 @@
 		reg = <0 0xe6c20000 0 64>;
 		interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x3d>, <&dmac0 0x3e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -575,7 +575,7 @@
 		reg = <0 0xe6c30000 0 64>;
 		interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x19>, <&dmac0 0x1a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -588,7 +588,7 @@
 		reg = <0 0xe6ce0000 0 64>;
 		interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp2_clks R8A7793_CLK_SCIFB2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x1d>, <&dmac0 0x1e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -601,7 +601,7 @@
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -614,7 +614,7 @@
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -627,7 +627,7 @@
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -640,7 +640,7 @@
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF3>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -653,7 +653,7 @@
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF4>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -666,7 +666,7 @@
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_SCIF5>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -679,7 +679,7 @@
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF0>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -692,7 +692,7 @@
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF1>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -705,7 +705,7 @@
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp7_clks R8A7793_CLK_HSCIF2>;
-		clock-names = "sci_ick";
+		clock-names = "fck";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:46 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:46 +0100
Subject: [PATCH 56/68] ARM: dts: r8a7779: Add BRG support for SCIF
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <f2be5f00d5eef701871cb1bc2b573dd5a75f66d3.1455303422.git.horms+renesas@verge.net.au>

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

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depends on
the actual board.

Add the two optional clock sources (S1 and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF device nodes.

This increases the range and accuracy of supported baud rates on SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7779.dtsi | 39 +++++++++++++++++++++++++++------------
 1 file changed, 27 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 8fddfae13865..a0cc08e6295b 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -215,8 +215,9 @@
 			     "renesas,scif";
 		reg = <0xffe40000 0x100>;
 		interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7779_CLK_SCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7779_CLK_SCIF0>,
+			 <&cpg_clocks R8A7779_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -226,8 +227,9 @@
 			     "renesas,scif";
 		reg = <0xffe41000 0x100>;
 		interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7779_CLK_SCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7779_CLK_SCIF1>,
+			 <&cpg_clocks R8A7779_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -237,8 +239,9 @@
 			     "renesas,scif";
 		reg = <0xffe42000 0x100>;
 		interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7779_CLK_SCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7779_CLK_SCIF2>,
+			 <&cpg_clocks R8A7779_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -248,8 +251,9 @@
 			     "renesas,scif";
 		reg = <0xffe43000 0x100>;
 		interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7779_CLK_SCIF3>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7779_CLK_SCIF3>,
+			 <&cpg_clocks R8A7779_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -259,8 +263,9 @@
 			     "renesas,scif";
 		reg = <0xffe44000 0x100>;
 		interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7779_CLK_SCIF4>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7779_CLK_SCIF4>,
+			 <&cpg_clocks R8A7779_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -270,8 +275,9 @@
 			     "renesas,scif";
 		reg = <0xffe45000 0x100>;
 		interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp0_clks R8A7779_CLK_SCIF5>;
-		clock-names = "fck";
+		clocks = <&mstp0_clks R8A7779_CLK_SCIF5>,
+			 <&cpg_clocks R8A7779_CLK_S1>, <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		power-domains = <&cpg_clocks>;
 		status = "disabled";
 	};
@@ -447,6 +453,15 @@
 			clock-output-names = "extal";
 		};
 
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+			status = "disabled";
+		};
+
 		/* Special CPG clocks */
 		cpg_clocks: clocks at ffc80000 {
 			compatible = "renesas,r8a7779-cpg-clocks";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:05:48 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:05:48 +0100
Subject: [PATCH 58/68] ARM: dts: r8a7791: Add BRG support for (H)SCIF
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <394730a1337c578da7a5dc26671187c10ce3a9cd.1455303422.git.horms+renesas@verge.net.au>

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

Add the device node for the external SCIF_CLK.
The presence of the SCIF_CLK crystal and its clock frequency depends on
the actual board.

Add the two optional clock sources (ZS_CLK and SCIF_CLK for the internal
resp. external clock) for the Baud Rate Generator for External Clock
(BRG) to all SCIF and HSCIF device nodes.

This increases the range and accuracy of supported baud rates on
(H)SCIF.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791.dtsi | 54 ++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 194e9464b748..14aa62539ff2 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -685,8 +685,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e60000 0 64>;
 		interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x29>, <&dmac0 0x2a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -698,8 +699,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e68000 0 64>;
 		interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2d>, <&dmac0 0x2e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -711,8 +713,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6e58000 0 64>;
 		interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2b>, <&dmac0 0x2c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -724,8 +727,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ea8000 0 64>;
 		interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF3>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF3>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x2f>, <&dmac0 0x30>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -737,8 +741,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ee0000 0 64>;
 		interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF4>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF4>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0xfb>, <&dmac0 0xfc>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -750,8 +755,9 @@
 			     "renesas,scif";
 		reg = <0 0xe6ee8000 0 64>;
 		interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_SCIF5>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_SCIF5>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0xfd>, <&dmac0 0xfe>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -763,8 +769,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c0000 0 96>;
 		interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_HSCIF0>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_HSCIF0>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x39>, <&dmac0 0x3a>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -776,8 +783,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62c8000 0 96>;
 		interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_HSCIF1>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_HSCIF1>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x4d>, <&dmac0 0x4e>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -789,8 +797,9 @@
 			     "renesas,rcar-gen2-hscif", "renesas,hscif";
 		reg = <0 0xe62d0000 0 96>;
 		interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&mstp7_clks R8A7791_CLK_HSCIF2>;
-		clock-names = "fck";
+		clocks = <&mstp7_clks R8A7791_CLK_HSCIF2>, <&zs_clk>,
+			 <&scif_clk>;
+		clock-names = "fck", "brg_int", "scif_clk";
 		dmas = <&dmac0 0x3b>, <&dmac0 0x3c>;
 		dma-names = "tx", "rx";
 		power-domains = <&cpg_clocks>;
@@ -1049,6 +1058,15 @@
 			status = "disabled";
 		};
 
+		/* External SCIF clock */
+		scif_clk: scif {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			/* This value must be overridden by the board. */
+			clock-frequency = <0>;
+			status = "disabled";
+		};
+
 		/* External USB clock - can be overridden by the board */
 		usb_extal_clk: usb_extal_clk {
 			compatible = "fixed-clock";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:06:22 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:06:22 +0100
Subject: [GIT PULL] Renesas ARM Based SoC Updates for v4.6
Message-ID: <cover.1455303757.git.horms+renesas@verge.net.au>

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM based SoC updates for v4.6.

This pull request is based on "Renesas ARM Based SoC Cleanup for v4.6",
tagged as cleanup-for-v4.6, which you have already pulled.


The following changes since commit e24f317c859f2d904d1eb87cbb503c309e6dead7:

  ARM: shmobile: Typo s/MIPDR/MPIDR/ (2016-02-04 15:09:30 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-for-v4.6

for you to fetch changes up to 9c9c1320111449c770a51488ca74a5902835e227:

  ARM: shmobile: emev2: Move declaration of emev2_smp_ops to emev2.h (2016-02-09 21:16:16 +0100)

----------------------------------------------------------------
Renesas ARM Based SoC Updates for v4.6

* Move emev2_smp_ops to emev2
* Remove legacy map_io callbacks on r8a7740 and emev2 SoCs
* Clean up SCU mapping code
* Migrate to generic l2c OF initialization on r8a7740

----------------------------------------------------------------
Geert Uytterhoeven (8):
      ARM: shmobile: r8a7779: Remove remainings of removed SCU boot setup code
      ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization
      ARM: shmobile: r8a7740: Remove mapping of L2 cache controller registers
      ARM: shmobile: Move shmobile_scu_base from .text to .data
      ARM: shmobile: Consolidate SCU mapping code
      ARM: shmobile: r8a7740: Remove legacy machine_desc.map_io() callback
      ARM: shmobile: emev2: Remove legacy machine_desc.map_io() callback
      ARM: shmobile: emev2: Move declaration of emev2_smp_ops to emev2.h

 arch/arm/mach-shmobile/common.h        |  5 ++---
 arch/arm/mach-shmobile/emev2.h         |  6 ++++++
 arch/arm/mach-shmobile/headsmp-scu.S   |  6 ------
 arch/arm/mach-shmobile/platsmp-scu.c   | 11 ++++++++--
 arch/arm/mach-shmobile/setup-emev2.c   | 22 ++-----------------
 arch/arm/mach-shmobile/setup-r8a7740.c | 39 ++--------------------------------
 arch/arm/mach-shmobile/smp-emev2.c     |  5 +++--
 arch/arm/mach-shmobile/smp-r8a7779.c   |  5 +----
 arch/arm/mach-shmobile/smp-sh73a0.c    |  3 +--
 9 files changed, 26 insertions(+), 76 deletions(-)
 create mode 100644 arch/arm/mach-shmobile/emev2.h


From horms+renesas at verge.net.au  Fri Feb 12 11:06:20 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:06:20 +0100
Subject: [PATCH 2/8] ARM: shmobile: r8a7740: Migrate to generic l2c OF
 initialization
In-Reply-To: <cover.1455303757.git.horms+renesas@verge.net.au>
References: <cover.1455303757.git.horms+renesas@verge.net.au>
Message-ID: <f5b891cc1078d0185837dc2af09ae33044163b56.1455303757.git.horms+renesas@verge.net.au>

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

Migrate the generic r8a7740 platform from calling l2x0_of_init() to the
generic l2c OF initialization.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7740.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 0c8f80c5b04d..bf221e05c8dc 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -23,7 +23,6 @@
 #include <asm/mach/map.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
-#include <asm/hardware/cache-l2x0.h>
 
 #include "common.h"
 
@@ -110,10 +109,6 @@ static void __init r8a7740_generic_init(void)
 {
 	r8a7740_meram_workaround();
 
-#ifdef CONFIG_CACHE_L2X0
-	/* Shared attribute override enable, 32K*8way */
-	l2x0_init(IOMEM(0xf0002000), 0x00400000, 0xc20f0fff);
-#endif
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
@@ -123,6 +118,8 @@ static const char *const r8a7740_boards_compat_dt[] __initconst = {
 };
 
 DT_MACHINE_START(R8A7740_DT, "Generic R8A7740 (Flattened Device Tree)")
+	.l2c_aux_val	= 0,
+	.l2c_aux_mask	= ~0,
 	.map_io		= r8a7740_map_io,
 	.init_early	= shmobile_init_delay,
 	.init_irq	= r8a7740_init_irq_of,
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:06:21 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:06:21 +0100
Subject: [PATCH 3/8] ARM: shmobile: r8a7740: Remove mapping of L2 cache
 controller registers
In-Reply-To: <cover.1455303757.git.horms+renesas@verge.net.au>
References: <cover.1455303757.git.horms+renesas@verge.net.au>
Message-ID: <fb9ac297db2a9d3753f24e7ae295aa2efaa30a27.1455303757.git.horms+renesas@verge.net.au>

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

Now all r8a7740-based platforms have been migrated to the generic l2c OF
initialization, it's no longer needed to map the L2 cache controller
registers from .map_io().

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7740.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index bf221e05c8dc..3e71cd4168dd 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -37,18 +37,6 @@ static struct map_desc r8a7740_io_desc[] __initdata = {
 		.length		= 160 << 20,
 		.type		= MT_DEVICE_NONSHARED
 	},
-#ifdef CONFIG_CACHE_L2X0
-	/*
-	 * for l2x0_init()
-	 * 0xf0100000-0xf0101000 -> 0xf0002000-0xf0003000
-	 */
-	{
-		.virtual	= 0xf0002000,
-		.pfn		= __phys_to_pfn(0xf0100000),
-		.length		= PAGE_SIZE,
-		.type		= MT_DEVICE_NONSHARED
-	},
-#endif
 };
 
 static void __init r8a7740_map_io(void)
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:06:22 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:06:22 +0100
Subject: [PATCH 4/8] ARM: shmobile: Move shmobile_scu_base from .text to .data
In-Reply-To: <cover.1455303757.git.horms+renesas@verge.net.au>
References: <cover.1455303757.git.horms+renesas@verge.net.au>
Message-ID: <797eff54b22b76d9f356074ff3c7ed25d9742e54.1455303757.git.horms+renesas@verge.net.au>

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

shmobile_scu_base is being written to, so it doesn't belong in the .text
section. Fix this by moving it from asm .text to C .data, as it's no
longer used from asm code since commit 4f6da36f7edd5790 ("ARM: shmobile:
Remove old SCU boot code").

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/headsmp-scu.S | 6 ------
 arch/arm/mach-shmobile/platsmp-scu.c | 3 +++
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/headsmp-scu.S b/arch/arm/mach-shmobile/headsmp-scu.S
index c0008a5aa4ca..936d7011c314 100644
--- a/arch/arm/mach-shmobile/headsmp-scu.S
+++ b/arch/arm/mach-shmobile/headsmp-scu.S
@@ -38,9 +38,3 @@ ENTRY(shmobile_boot_scu)
 
 	b	secondary_startup
 ENDPROC(shmobile_boot_scu)
-
-	.text
-	.align	2
-	.globl	shmobile_scu_base
-shmobile_scu_base:
-	.space	4
diff --git a/arch/arm/mach-shmobile/platsmp-scu.c b/arch/arm/mach-shmobile/platsmp-scu.c
index 64663110ab6c..f2198c9c7435 100644
--- a/arch/arm/mach-shmobile/platsmp-scu.c
+++ b/arch/arm/mach-shmobile/platsmp-scu.c
@@ -17,6 +17,9 @@
 #include <asm/smp_scu.h>
 #include "common.h"
 
+
+void __iomem *shmobile_scu_base;
+
 static int shmobile_smp_scu_notifier_call(struct notifier_block *nfb,
 					  unsigned long action, void *hcpu)
 {
-- 
2.7.0.rc3.207.g0ac5344



From wsa at the-dreams.de  Fri Feb 12 11:18:45 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Fri, 12 Feb 2016 20:18:45 +0100
Subject: [PATCH v6] i2c: mt8173: add 4GB mode support in i2c driver.
In-Reply-To: <1454347143-31461-1-git-send-email-liguo.zhang@mediatek.com>
References: <1454347143-31461-1-git-send-email-liguo.zhang@mediatek.com>
Message-ID: <20160212191845.GN1520@katana>

On Tue, Feb 02, 2016 at 01:19:03AM +0800, Liguo Zhang wrote:
> If 4GB mode is enable, we should add 4gb mode support in i2c driver.
> Set 4GB mode register to support 4GB mode.
> 
> Signed-off-by: Liguo Zhang <liguo.zhang at mediatek.com>

The subject should have "mt65xx" since this is the driver name. I also
added DMA to the commit message to make clear what this mode is about.

Applied to for-next, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/3605881a/attachment-0001.sig>

From wsa at the-dreams.de  Fri Feb 12 11:23:34 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Fri, 12 Feb 2016 20:23:34 +0100
Subject: [PATCH] i2c: uniphier: fix typos in error messages
In-Reply-To: <1453799361-21910-1-git-send-email-yamada.masahiro@socionext.com>
References: <1453799361-21910-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <20160212192334.GO1520@katana>

On Tue, Jan 26, 2016 at 06:09:21PM +0900, Masahiro Yamada wrote:
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>

Applied to for-current, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/d4ac609d/attachment-0001.sig>

From computersforpeace at gmail.com  Fri Feb 12 11:24:38 2016
From: computersforpeace at gmail.com (Brian Norris)
Date: Fri, 12 Feb 2016 11:24:38 -0800
Subject: [PATCH linux-next v2 01/14] mtd: spi-nor: remove
 micron_quad_enable()
In-Reply-To: <56B1E1A5.9060902@atmel.com>
References: <A765B125120D1346A63912DDE6D8B6310BF57A75@NTXXIAMBX02.xacn.micron.com>
 <56B1E1A5.9060902@atmel.com>
Message-ID: <20160212192438.GD21465@google.com>

On Wed, Feb 03, 2016 at 12:16:53PM +0100, Cyrille Pitchen wrote:

> So in its current state, micron_quad_enable() prevents us from using Micron
> memories for Quad SPI operations. Some code is missing to make it work.

TL;DR: the original code adding micron_quad_enable() was broken and
should never have been merged (sorry, my bad). Next time, please test
your changes Bean.

> As I said in the patch description, using the SPI 4-4-4 protocol is not
> relevant for MTD usage. It would be worth for XIP operations but this is not the
> purpose of the spi-nor driver.

I'm not completely opposed to using it, if someone can support it well,
test it, and prove it actually provides real benefits. But none of the
above have been satisfied yet.

Regards,
Brian


From horms at verge.net.au  Fri Feb 12 11:33:48 2016
From: horms at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:33:48 +0100
Subject: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
In-Reply-To: <56BE2DC6.4080802@cogentembedded.com>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
 <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
 <874mdhtn7d.wl%kuninori.morimoto.gx@renesas.com>
 <20160210171455.GB17671@verge.net.au>
 <56BE0CB1.4070408@cogentembedded.com>
 <20160212184343.GA31655@verge.net.au>
 <56BE2DC6.4080802@cogentembedded.com>
Message-ID: <20160212193347.GB23472@verge.net.au>

On Fri, Feb 12, 2016 at 10:08:54PM +0300, Sergei Shtylyov wrote:
> On 02/12/2016 09:43 PM, Simon Horman wrote:
> 
> >>>>Sorry for my un-ordered response
> >>>>
> >>>>>Define the generic R8A7794 part of  the sound device node.
> >>>>>This sound device  is a complex one and comprises the Audio Clock Generator
> >>>>>(ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
> >>>>>(SSI[U]), and Audio DMAC-Peripheral-Peripheral.
> >>>>>It is up  to the board file to enable the device.
> >>>>>
> >>>>>This patch is based on the R8A7791 sound work by Kuninori Morimoto.
> >>>>>
> >>>>>Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> >>>>(snip)
> >>>>>+		rcar_sound,src {
> >>>>>+			src1: src at 1 {
> >>>>>+				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>+				dmas = <&audma0 0x87>, <&audma0 0x9c>;
> >>>>>+				dma-names = "rx", "tx";
> >>>>>+			};
> >>>>>+			src2: src at 2 {
> >>>>>+				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>+				dmas = <&audma0 0x89>, <&audma0 0x9e>;
> >>>>>+				dma-names = "rx", "tx";
> >>>>>+			};
> >>>>>+			src3: src at 3 {
> >>>>>+				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>+				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
> >>>>>+				dma-names = "rx", "tx";
> >>>>>+			};
> >>>>>+			src4: src at 4 {
> >>>>>+				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>+				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
> >>>>>+				dma-names = "rx", "tx";
> >>>>>+			};
> >>>>>+			src5: src at 5 {
> >>>>>+				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>+				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
> >>>>>+				dma-names = "rx", "tx";
> >>>>>+			};
> >>>>>+			src6: src at 6 {
> >>>>>+				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>+				dmas = <&audma0 0x91>, <&audma0 0xb4>;
> >>>>>+				dma-names = "rx", "tx";
> >>>>>+			};
> >>>>>+		};
> >>>>
> >>>>I think this can't work correctly, because driver is assuming
> >>>>DT has all channles (from 0). (see linux/sound/soc/sh/rcar/src.c :: rsnd_src_probe)
> >>>>Can you adds dummy src0 with some comments ? or fix src.c driver ?
> >>>
> >>>I would prefer the driver to be fixed (I had a similar patchset locally
> >>>and I found it doesn't work).
> >>
> >>    You mean you had R8A7794 sound patch set too?
> >
> >Yes, I was working on it recently.
> >I suppose we should coordinate these things in future to avoid
> >duplicated effort.
> 
>    Yes, seems a good idea now. :-)
> 
> >>>The reason is that DT should describe
> >>>the hardware rather than the current state of the software.
> >>
> >>    Yes, of course. Just tell me do I have to fix the driver *before* this
> >>patch set is accepted?
> 
> >I did not entirely get to the bottom of the problem, but I think that at
> >the very least something needs to be done about the for_each_rsnd_src()
> >loop in rsnd_src_probe.
> 
>    It's not that it replies to my question. :-)
>    So you're looking at this issue yourself?

I have not got very far, as you can see, but I was planning to look into it.
I don't mind if you want to do so.

> >My, obviously not satisfactory, hack around there being no src0 was as follows.
> >
> >diff --git a/sound/soc/sh/rcar/src.c b/sound/soc/sh/rcar/src.c
> >index 68b439ed22d7..58a447b0785b 100644
> >--- a/sound/soc/sh/rcar/src.c
> >+++ b/sound/soc/sh/rcar/src.c
> >@@ -1072,7 +1072,7 @@ int rsnd_src_probe(struct platform_device *pdev,
> >
> >  	for_each_rsnd_src(src, priv, i) {
> 
>    Which tree is this? The recent devel branch of renesas.git has
> for_each_child_of_node() here...

renesas-devel-20160118-v4.4

I guess the code in question updated in v4.5-rcX.

> >  		snprintf(name, RSND_SRC_NAME_SIZE, "%s.%d",
> >-			 SRC_NAME, i);
> >+			 SRC_NAME, i + 1);
> >
> >  		clk = devm_clk_get(dev, name);
> >  		if (IS_ERR(clk))
> 
> MBR, Sergei


From broonie at kernel.org  Fri Feb 12 11:34:13 2016
From: broonie at kernel.org (Mark Brown)
Date: Fri, 12 Feb 2016 19:34:13 +0000
Subject: [PATCH] Revert "ASoC: qcom: Specify LE device endianness"
In-Reply-To: <1455298217-15744-1-git-send-email-sboyd@codeaurora.org>
References: <1455298217-15744-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <20160212193413.GA11402@sirena.org.uk>

On Fri, Feb 12, 2016 at 09:30:17AM -0800, Stephen Boyd wrote:
> This reverts commit 18560a4e3b07438113b50589e78532d95f907029.

Please use subject lines matching the style for the subsystem and 
please include human readable descriptions of things like commits and
issues being discussed in e-mail in your mails, this makes them much
easier for humans to read especially when they have no internet access.
I do frequently catch up on my mail on flights or while otherwise
travelling so this is even more pressing for me than just being about
making things a bit easier to read.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/270bb5d2/attachment-0001.sig>

From matthias.bgg at gmail.com  Fri Feb 12 11:45:09 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Fri, 12 Feb 2016 20:45:09 +0100
Subject: [PATCH v5sub1 0/8] arm64: split linear and kernel mappings
In-Reply-To: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <56BE3645.3030403@gmail.com>

Hi Ard,

On 01/02/16 11:54, Ard Biesheuvel wrote:
> At the request of Catalin, this series has been split off from my series
> 'arm64: implement support for KASLR v4' [1]. This sub-series deals with
> moving the kernel out of the linear mapping into the vmalloc area. This
> is a prerequisite for independent physical and virtual randomization of
> the kernel image. On top of that, considering that these changes allow
> the linear mapping to start at an arbitrary offset above PAGE_OFFSET, it
> should be an improvement in itself due to the fact that we can now choose
> PAGE_OFFSET such that RAM can be mapped using large block sizes.
>
> For instance, on my Seattle A0 box, the kernel is loaded 16 MB into the
> lowest GB of RAM, which means __pa(PAGE_OFFSET) is not 1 GB aligned, and
> the entire 16 GB of RAM will be mapping using 2 MB blocks. (Similarly,
> for 64 KB granule kernels, the entire 16 GB of RAM will be mapped using
> pages since __pa(PAGE_OFFSET) is not 512 MB aligned). With these changes
>   __pa(PAGE_OFFSET) will always be chosen such that it is aligned to a
> quantity that allows efficient mapping.
>
> Note that of the entire KASLR series, this sub-series is the most likely to
> cause problems, and hence requires the most careful review and testing. This
> is due to the fact that, with these changes, the invariant __va(__pa(x)) == x
> no longer holds, and any code that is based on that assumption needs to be
> updated.
>
> Changes since v4:
> - added Marc's ack to patch #6
> - round the kasan zero shadow region around the kernel image to swapper block
>    size (#7)
> - ensure that we don't clip the kernel image when clipping RAM to the linear
>    region size (#8)
>
> Patch #1 allows the low mark of memblocks discovered from the FDT to be
> overridden by the architecture.
>
> Patch #2 enables the huge-vmap generic feature for arm64. This should be an
> improvement in itself, but the significance for this series is that it allows
> unmap_kernel_range() to be called on the [__init_begin, __init_end) region,
> which may be partially mapped using block mappings.
>
> Patch #3 introduces KIMAGE_VADDR as a separate, preparatory step towards
> decoupling the kernel placement from PAGE_OFFSET
>
> Patch #4 implements some translation table accessors that operate on statically
> allocate translation tables before the linear mapping is up.
>
> Patch #5 decouples the fixmap initialization from the linear mapping, by using
> the accessors implemented by patch #4
>
> Patch #6 removes assumptions made my KVM regarding the placement of the kernel
> image inside the linear mapping.
>
> Patch #7 moves the kernel image from the base of the linear mapping to the base
> of the vmalloc area. The modules area, which sits right below the kernel image,
> is moved along and is put right before the start of the vmalloc area.
>
> Patch #8 decouples PHYS_OFFSET from PAGE_OFFSET, which allows the linear mapping
> to cover all discovered memory, regardless of where the kernel image is located
> in it. This effectively allows the kernel to be loaded at any physical address
> (provided that the correct alignment is used)
>
> [1] http://thread.gmane.org/gmane.linux.kernel/2135931
>
> Ard Biesheuvel (8):
>    of/fdt: make memblock minimum physical address arch configurable
>    arm64: add support for ioremap() block mappings
>    arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
>    arm64: pgtable: implement static [pte|pmd|pud]_offset variants
>    arm64: decouple early fixmap init from linear mapping
>    arm64: kvm: deal with kernel symbols outside of linear mapping
>    arm64: move kernel image to base of vmalloc area
>    arm64: allow kernel Image to be loaded anywhere in physical memory
>

I bisected linux-next (20160212) with the following error on booting 
with an initramfs:
  Failed to execute /init (error -8)
  request_module: runaway loop modprobe binfmt-464c
  Starting init: /sbin/init exists but couldn't execute it (error -8)
  request_module: runaway loop modprobe binfmt-464c
  Starting init: /bin/sh exists but couldn't execute it (error -8)
  Kernel panic - not syncing: No working init found.  Try passing init= 
option to kernel. See Linux Documentation/init..

I tracked down the error to patch 7 of this series. But I realized that 
patch 7 does not compile, but from patch 8 onwards I observe the error.

I use defconfig with an initramfs.cpio created with buildroot.
I tested this on my mt8173 eval board, but I suppose this can be 
reproduced easily on other machines as well.

Regards,
Matthias

>   Documentation/arm64/booting.txt                      |  20 ++-
>   Documentation/features/vm/huge-vmap/arch-support.txt |   2 +-
>   arch/arm/include/asm/kvm_asm.h                       |   2 +
>   arch/arm/kvm/arm.c                                   |   8 +-
>   arch/arm64/Kconfig                                   |   1 +
>   arch/arm64/include/asm/boot.h                        |   6 +
>   arch/arm64/include/asm/kasan.h                       |   2 +-
>   arch/arm64/include/asm/kernel-pgtable.h              |  12 ++
>   arch/arm64/include/asm/kvm_asm.h                     |   2 +
>   arch/arm64/include/asm/kvm_host.h                    |   8 +-
>   arch/arm64/include/asm/memory.h                      |  44 ++++--
>   arch/arm64/include/asm/pgtable.h                     |  23 ++-
>   arch/arm64/kernel/head.S                             |   8 +-
>   arch/arm64/kernel/image.h                            |  13 +-
>   arch/arm64/kernel/vmlinux.lds.S                      |   4 +-
>   arch/arm64/kvm/hyp.S                                 |   6 +-
>   arch/arm64/mm/dump.c                                 |  12 +-
>   arch/arm64/mm/init.c                                 | 123 ++++++++++++++--
>   arch/arm64/mm/kasan_init.c                           |  31 +++-
>   arch/arm64/mm/mmu.c                                  | 155 +++++++++++++++-----
>   drivers/of/fdt.c                                     |   5 +-
>   21 files changed, 378 insertions(+), 109 deletions(-)
>


From ard.biesheuvel at linaro.org  Fri Feb 12 11:47:27 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 20:47:27 +0100
Subject: [PATCH v5sub1 0/8] arm64: split linear and kernel mappings
In-Reply-To: <56BE3645.3030403@gmail.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <56BE3645.3030403@gmail.com>
Message-ID: <CAKv+Gu9Qw=DSe1fZT=Dv=iKaKqzsf5ARK9dzwCWPk_0uRECm1w@mail.gmail.com>

On 12 February 2016 at 20:45, Matthias Brugger <matthias.bgg at gmail.com> wrote:
> Hi Ard,
>
>
> On 01/02/16 11:54, Ard Biesheuvel wrote:
>>
>> At the request of Catalin, this series has been split off from my series
>> 'arm64: implement support for KASLR v4' [1]. This sub-series deals with
>> moving the kernel out of the linear mapping into the vmalloc area. This
>> is a prerequisite for independent physical and virtual randomization of
>> the kernel image. On top of that, considering that these changes allow
>> the linear mapping to start at an arbitrary offset above PAGE_OFFSET, it
>> should be an improvement in itself due to the fact that we can now choose
>> PAGE_OFFSET such that RAM can be mapped using large block sizes.
>>
>> For instance, on my Seattle A0 box, the kernel is loaded 16 MB into the
>> lowest GB of RAM, which means __pa(PAGE_OFFSET) is not 1 GB aligned, and
>> the entire 16 GB of RAM will be mapping using 2 MB blocks. (Similarly,
>> for 64 KB granule kernels, the entire 16 GB of RAM will be mapped using
>> pages since __pa(PAGE_OFFSET) is not 512 MB aligned). With these changes
>>   __pa(PAGE_OFFSET) will always be chosen such that it is aligned to a
>> quantity that allows efficient mapping.
>>
>> Note that of the entire KASLR series, this sub-series is the most likely
>> to
>> cause problems, and hence requires the most careful review and testing.
>> This
>> is due to the fact that, with these changes, the invariant __va(__pa(x))
>> == x
>> no longer holds, and any code that is based on that assumption needs to be
>> updated.
>>
>> Changes since v4:
>> - added Marc's ack to patch #6
>> - round the kasan zero shadow region around the kernel image to swapper
>> block
>>    size (#7)
>> - ensure that we don't clip the kernel image when clipping RAM to the
>> linear
>>    region size (#8)
>>
>> Patch #1 allows the low mark of memblocks discovered from the FDT to be
>> overridden by the architecture.
>>
>> Patch #2 enables the huge-vmap generic feature for arm64. This should be
>> an
>> improvement in itself, but the significance for this series is that it
>> allows
>> unmap_kernel_range() to be called on the [__init_begin, __init_end)
>> region,
>> which may be partially mapped using block mappings.
>>
>> Patch #3 introduces KIMAGE_VADDR as a separate, preparatory step towards
>> decoupling the kernel placement from PAGE_OFFSET
>>
>> Patch #4 implements some translation table accessors that operate on
>> statically
>> allocate translation tables before the linear mapping is up.
>>
>> Patch #5 decouples the fixmap initialization from the linear mapping, by
>> using
>> the accessors implemented by patch #4
>>
>> Patch #6 removes assumptions made my KVM regarding the placement of the
>> kernel
>> image inside the linear mapping.
>>
>> Patch #7 moves the kernel image from the base of the linear mapping to the
>> base
>> of the vmalloc area. The modules area, which sits right below the kernel
>> image,
>> is moved along and is put right before the start of the vmalloc area.
>>
>> Patch #8 decouples PHYS_OFFSET from PAGE_OFFSET, which allows the linear
>> mapping
>> to cover all discovered memory, regardless of where the kernel image is
>> located
>> in it. This effectively allows the kernel to be loaded at any physical
>> address
>> (provided that the correct alignment is used)
>>
>> [1] http://thread.gmane.org/gmane.linux.kernel/2135931
>>
>> Ard Biesheuvel (8):
>>    of/fdt: make memblock minimum physical address arch configurable
>>    arm64: add support for ioremap() block mappings
>>    arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
>>    arm64: pgtable: implement static [pte|pmd|pud]_offset variants
>>    arm64: decouple early fixmap init from linear mapping
>>    arm64: kvm: deal with kernel symbols outside of linear mapping
>>    arm64: move kernel image to base of vmalloc area
>>    arm64: allow kernel Image to be loaded anywhere in physical memory
>>
>
> I bisected linux-next (20160212) with the following error on booting with an
> initramfs:
>  Failed to execute /init (error -8)
>  request_module: runaway loop modprobe binfmt-464c
>  Starting init: /sbin/init exists but couldn't execute it (error -8)
>  request_module: runaway loop modprobe binfmt-464c
>  Starting init: /bin/sh exists but couldn't execute it (error -8)
>  Kernel panic - not syncing: No working init found.  Try passing init=
> option to kernel. See Linux Documentation/init..
>
> I tracked down the error to patch 7 of this series. But I realized that
> patch 7 does not compile, but from patch 8 onwards I observe the error.
>
> I use defconfig with an initramfs.cpio created with buildroot.
> I tested this on my mt8173 eval board, but I suppose this can be reproduced
> easily on other machines as well.
>

Thanks for the report. Does this help at all?

http://thread.gmane.org/gmane.linux.ports.arm.kernel/477645

> Regards,
> Matthias
>
>
>>   Documentation/arm64/booting.txt                      |  20 ++-
>>   Documentation/features/vm/huge-vmap/arch-support.txt |   2 +-
>>   arch/arm/include/asm/kvm_asm.h                       |   2 +
>>   arch/arm/kvm/arm.c                                   |   8 +-
>>   arch/arm64/Kconfig                                   |   1 +
>>   arch/arm64/include/asm/boot.h                        |   6 +
>>   arch/arm64/include/asm/kasan.h                       |   2 +-
>>   arch/arm64/include/asm/kernel-pgtable.h              |  12 ++
>>   arch/arm64/include/asm/kvm_asm.h                     |   2 +
>>   arch/arm64/include/asm/kvm_host.h                    |   8 +-
>>   arch/arm64/include/asm/memory.h                      |  44 ++++--
>>   arch/arm64/include/asm/pgtable.h                     |  23 ++-
>>   arch/arm64/kernel/head.S                             |   8 +-
>>   arch/arm64/kernel/image.h                            |  13 +-
>>   arch/arm64/kernel/vmlinux.lds.S                      |   4 +-
>>   arch/arm64/kvm/hyp.S                                 |   6 +-
>>   arch/arm64/mm/dump.c                                 |  12 +-
>>   arch/arm64/mm/init.c                                 | 123
>> ++++++++++++++--
>>   arch/arm64/mm/kasan_init.c                           |  31 +++-
>>   arch/arm64/mm/mmu.c                                  | 155
>> +++++++++++++++-----
>>   drivers/of/fdt.c                                     |   5 +-
>>   21 files changed, 378 insertions(+), 109 deletions(-)
>>
>


From horms+renesas at verge.net.au  Fri Feb 12 11:06:24 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:06:24 +0100
Subject: [PATCH 6/8] ARM: shmobile: r8a7740: Remove legacy
 machine_desc.map_io() callback
In-Reply-To: <cover.1455303757.git.horms+renesas@verge.net.au>
References: <cover.1455303757.git.horms+renesas@verge.net.au>
Message-ID: <a0827317f5f351c303ed91f0272f10b1394bdab1.1455303757.git.horms+renesas@verge.net.au>

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

Commit 37201ba5c99d0be8 ("ARM: shmobile: r8a7740: Migrate to generic l2c
OF initialization") removed the last user of the legacy "IOMEM()" macro
on r8a7740-based systems. Hence there's no longer a need to set up a
transparent mapping of system I/O registers. Remove the mapping and the
legacy machine_desc.map_io() callback.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7740.c | 20 --------------------
 1 file changed, 20 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 3e71cd4168dd..db6dbfbaf9f1 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -26,25 +26,6 @@
 
 #include "common.h"
 
-static struct map_desc r8a7740_io_desc[] __initdata = {
-	 /*
-	  * for CPGA/INTC/PFC
-	  * 0xe6000000-0xefffffff -> 0xe6000000-0xefffffff
-	  */
-	{
-		.virtual	= 0xe6000000,
-		.pfn		= __phys_to_pfn(0xe6000000),
-		.length		= 160 << 20,
-		.type		= MT_DEVICE_NONSHARED
-	},
-};
-
-static void __init r8a7740_map_io(void)
-{
-	debug_ll_io_init();
-	iotable_init(r8a7740_io_desc, ARRAY_SIZE(r8a7740_io_desc));
-}
-
 /*
  * r8a7740 chip has lasting errata on MERAM buffer.
  * this is work-around for it.
@@ -108,7 +89,6 @@ static const char *const r8a7740_boards_compat_dt[] __initconst = {
 DT_MACHINE_START(R8A7740_DT, "Generic R8A7740 (Flattened Device Tree)")
 	.l2c_aux_val	= 0,
 	.l2c_aux_mask	= ~0,
-	.map_io		= r8a7740_map_io,
 	.init_early	= shmobile_init_delay,
 	.init_irq	= r8a7740_init_irq_of,
 	.init_machine	= r8a7740_generic_init,
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:06:23 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:06:23 +0100
Subject: [PATCH 5/8] ARM: shmobile: Consolidate SCU mapping code
In-Reply-To: <cover.1455303757.git.horms+renesas@verge.net.au>
References: <cover.1455303757.git.horms+renesas@verge.net.au>
Message-ID: <4a7680695f5d9d219cfb16123d71013be92da75f.1455303757.git.horms+renesas@verge.net.au>

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

Currently the SCU registers are mapped in SoC-specific code, using
different methods, all involving the static mapping set up from
machine_desc.map_io():
  - On emev2, a static (non-identity) mapping is used, with ioremap().
    As the static mapping uses the MT_DEVICE type, ioremap() reuses it,
    and the returned virtual address is suitable for passing to
    shmobile_smp_hook(),
  - On sh73a0 and r8a7779, a static identity mapping is used, with the
    legacy IOMEM() macro.
    As the static mapping uses the MT_DEVICE_NONSHARED type, replacing
    IOMEM() by ioremap() would create a new mapping, whose virtual
    address cannot be passed to shmobile_smp_hook().

Move the mapping of the SCU registers from SoC-specific code to common
code, always using ioremap(). To work in the absence of a static
mapping, this requires passing the physical SCU base address to
shmobile_smp_hook().

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/common.h      |  5 ++---
 arch/arm/mach-shmobile/platsmp-scu.c | 10 +++++++---
 arch/arm/mach-shmobile/smp-emev2.c   |  3 +--
 arch/arm/mach-shmobile/smp-r8a7779.c |  3 +--
 arch/arm/mach-shmobile/smp-sh73a0.c  |  3 +--
 5 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-shmobile/common.h b/arch/arm/mach-shmobile/common.h
index 9cb11215ceba..225c12bb3de9 100644
--- a/arch/arm/mach-shmobile/common.h
+++ b/arch/arm/mach-shmobile/common.h
@@ -12,7 +12,8 @@ extern void shmobile_smp_hook(unsigned int cpu, unsigned long fn,
 			      unsigned long arg);
 extern bool shmobile_smp_cpu_can_disable(unsigned int cpu);
 extern void shmobile_boot_scu(void);
-extern void shmobile_smp_scu_prepare_cpus(unsigned int max_cpus);
+extern void shmobile_smp_scu_prepare_cpus(phys_addr_t scu_base_phys,
+					  unsigned int max_cpus);
 extern void shmobile_smp_scu_cpu_die(unsigned int cpu);
 extern int shmobile_smp_scu_cpu_kill(unsigned int cpu);
 extern struct platform_suspend_ops shmobile_suspend_ops;
@@ -31,8 +32,6 @@ int shmobile_cpufreq_init(void);
 static inline int shmobile_cpufreq_init(void) { return 0; }
 #endif
 
-extern void __iomem *shmobile_scu_base;
-
 static inline void __init shmobile_init_late(void)
 {
 	shmobile_suspend_init();
diff --git a/arch/arm/mach-shmobile/platsmp-scu.c b/arch/arm/mach-shmobile/platsmp-scu.c
index f2198c9c7435..4c7d2caf3730 100644
--- a/arch/arm/mach-shmobile/platsmp-scu.c
+++ b/arch/arm/mach-shmobile/platsmp-scu.c
@@ -18,7 +18,8 @@
 #include "common.h"
 
 
-void __iomem *shmobile_scu_base;
+static phys_addr_t shmobile_scu_base_phys;
+static void __iomem *shmobile_scu_base;
 
 static int shmobile_smp_scu_notifier_call(struct notifier_block *nfb,
 					  unsigned long action, void *hcpu)
@@ -29,7 +30,7 @@ static int shmobile_smp_scu_notifier_call(struct notifier_block *nfb,
 	case CPU_UP_PREPARE:
 		/* For this particular CPU register SCU SMP boot vector */
 		shmobile_smp_hook(cpu, virt_to_phys(shmobile_boot_scu),
-				  (unsigned long)shmobile_scu_base);
+				  shmobile_scu_base_phys);
 		break;
 	};
 
@@ -40,13 +41,16 @@ static struct notifier_block shmobile_smp_scu_notifier = {
 	.notifier_call = shmobile_smp_scu_notifier_call,
 };
 
-void __init shmobile_smp_scu_prepare_cpus(unsigned int max_cpus)
+void __init shmobile_smp_scu_prepare_cpus(phys_addr_t scu_base_phys,
+					  unsigned int max_cpus)
 {
 	/* install boot code shared by all CPUs */
 	shmobile_boot_fn = virt_to_phys(shmobile_smp_boot);
 	shmobile_boot_arg = MPIDR_HWID_BITMASK;
 
 	/* enable SCU and cache coherency on booting CPU */
+	shmobile_scu_base_phys = scu_base_phys;
+	shmobile_scu_base = ioremap(scu_base_phys, PAGE_SIZE);
 	scu_enable(shmobile_scu_base);
 	scu_power_mode(shmobile_scu_base, SCU_PM_NORMAL);
 
diff --git a/arch/arm/mach-shmobile/smp-emev2.c b/arch/arm/mach-shmobile/smp-emev2.c
index adbac6963f2b..4dfafd845452 100644
--- a/arch/arm/mach-shmobile/smp-emev2.c
+++ b/arch/arm/mach-shmobile/smp-emev2.c
@@ -45,8 +45,7 @@ static void __init emev2_smp_prepare_cpus(unsigned int max_cpus)
 	}
 
 	/* setup EMEV2 specific SCU bits */
-	shmobile_scu_base = ioremap(EMEV2_SCU_BASE, PAGE_SIZE);
-	shmobile_smp_scu_prepare_cpus(max_cpus);
+	shmobile_smp_scu_prepare_cpus(EMEV2_SCU_BASE, max_cpus);
 }
 
 const struct smp_operations emev2_smp_ops __initconst = {
diff --git a/arch/arm/mach-shmobile/smp-r8a7779.c b/arch/arm/mach-shmobile/smp-r8a7779.c
index 0b024a9dbd43..f5c31fbc10b2 100644
--- a/arch/arm/mach-shmobile/smp-r8a7779.c
+++ b/arch/arm/mach-shmobile/smp-r8a7779.c
@@ -94,8 +94,7 @@ static void __init r8a7779_smp_prepare_cpus(unsigned int max_cpus)
 	__raw_writel(__pa(shmobile_boot_vector), AVECR);
 
 	/* setup r8a7779 specific SCU bits */
-	shmobile_scu_base = IOMEM(R8A7779_SCU_BASE);
-	shmobile_smp_scu_prepare_cpus(max_cpus);
+	shmobile_smp_scu_prepare_cpus(R8A7779_SCU_BASE, max_cpus);
 
 	r8a7779_pm_init();
 
diff --git a/arch/arm/mach-shmobile/smp-sh73a0.c b/arch/arm/mach-shmobile/smp-sh73a0.c
index ee1a4b70604b..41137404382e 100644
--- a/arch/arm/mach-shmobile/smp-sh73a0.c
+++ b/arch/arm/mach-shmobile/smp-sh73a0.c
@@ -52,8 +52,7 @@ static void __init sh73a0_smp_prepare_cpus(unsigned int max_cpus)
 	__raw_writel(__pa(shmobile_boot_vector), SBAR);
 
 	/* setup sh73a0 specific SCU bits */
-	shmobile_scu_base = IOMEM(SH73A0_SCU_BASE);
-	shmobile_smp_scu_prepare_cpus(max_cpus);
+	shmobile_smp_scu_prepare_cpus(SH73A0_SCU_BASE, max_cpus);
 }
 
 const struct smp_operations sh73a0_smp_ops __initconst = {
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:06:26 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:06:26 +0100
Subject: [PATCH 8/8] ARM: shmobile: emev2: Move declaration of emev2_smp_ops
 to emev2.h
In-Reply-To: <cover.1455303757.git.horms+renesas@verge.net.au>
References: <cover.1455303757.git.horms+renesas@verge.net.au>
Message-ID: <9c9c1320111449c770a51488ca74a5902835e227.1455303757.git.horms+renesas@verge.net.au>

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

make C=1:

    arch/arm/mach-shmobile/smp-emev2.c:51:29: warning: symbol 'emev2_smp_ops' was not declared. Should it be static?

To fix this, move the forward declaration of emev2_smp_ops to a header
file, and include it where appropriate.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/emev2.h       | 6 ++++++
 arch/arm/mach-shmobile/setup-emev2.c | 4 ++--
 arch/arm/mach-shmobile/smp-emev2.c   | 2 ++
 3 files changed, 10 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-shmobile/emev2.h

diff --git a/arch/arm/mach-shmobile/emev2.h b/arch/arm/mach-shmobile/emev2.h
new file mode 100644
index 000000000000..916d25f6780e
--- /dev/null
+++ b/arch/arm/mach-shmobile/emev2.h
@@ -0,0 +1,6 @@
+#ifndef __ASM_EMEV2_H__
+#define __ASM_EMEV2_H__
+
+extern const struct smp_operations emev2_smp_ops;
+
+#endif /* __ASM_EMEV2_H__ */
diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
index 0829d0215c38..3c99aaf65325 100644
--- a/arch/arm/mach-shmobile/setup-emev2.c
+++ b/arch/arm/mach-shmobile/setup-emev2.c
@@ -18,15 +18,15 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
+
 #include "common.h"
+#include "emev2.h"
 
 static const char *const emev2_boards_compat_dt[] __initconst = {
 	"renesas,emev2",
 	NULL,
 };
 
-extern const struct smp_operations emev2_smp_ops;
-
 DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 (Flattened Device Tree)")
 	.smp		= smp_ops(emev2_smp_ops),
 	.init_early	= shmobile_init_delay,
diff --git a/arch/arm/mach-shmobile/smp-emev2.c b/arch/arm/mach-shmobile/smp-emev2.c
index 4dfafd845452..3a732199cf5e 100644
--- a/arch/arm/mach-shmobile/smp-emev2.c
+++ b/arch/arm/mach-shmobile/smp-emev2.c
@@ -21,7 +21,9 @@
 #include <linux/delay.h>
 #include <asm/smp_plat.h>
 #include <asm/smp_scu.h>
+
 #include "common.h"
+#include "emev2.h"
 
 #define EMEV2_SCU_BASE 0x1e000000
 #define EMEV2_SMU_BASE 0xe0110000
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Fri Feb 12 11:06:25 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 12 Feb 2016 20:06:25 +0100
Subject: [PATCH 7/8] ARM: shmobile: emev2: Remove legacy machine_desc.map_io()
 callback
In-Reply-To: <cover.1455303757.git.horms+renesas@verge.net.au>
References: <cover.1455303757.git.horms+renesas@verge.net.au>
Message-ID: <77621efa3544e5597892274de4fcff55294fffc8.1455303757.git.horms+renesas@verge.net.au>

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

Commit FIXME ("ARM: shmobile: Consolidate SCU mapping code") removed the
last user of the static mapping on emev2-based systems.  Remove the
mapping and the legacy machine_desc.map_io() callback.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-emev2.c | 18 ------------------
 1 file changed, 18 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
index 10b7cb5dcb3a..0829d0215c38 100644
--- a/arch/arm/mach-shmobile/setup-emev2.c
+++ b/arch/arm/mach-shmobile/setup-emev2.c
@@ -20,23 +20,6 @@
 #include <asm/mach/map.h>
 #include "common.h"
 
-static struct map_desc emev2_io_desc[] __initdata = {
-#ifdef CONFIG_SMP
-	/* 2M mapping for SCU + L2 controller */
-	{
-		.virtual	= 0xf0000000,
-		.pfn		= __phys_to_pfn(0x1e000000),
-		.length		= SZ_2M,
-		.type		= MT_DEVICE
-	},
-#endif
-};
-
-static void __init emev2_map_io(void)
-{
-	iotable_init(emev2_io_desc, ARRAY_SIZE(emev2_io_desc));
-}
-
 static const char *const emev2_boards_compat_dt[] __initconst = {
 	"renesas,emev2",
 	NULL,
@@ -46,7 +29,6 @@ extern const struct smp_operations emev2_smp_ops;
 
 DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 (Flattened Device Tree)")
 	.smp		= smp_ops(emev2_smp_ops),
-	.map_io		= emev2_map_io,
 	.init_early	= shmobile_init_delay,
 	.init_late	= shmobile_init_late,
 	.dt_compat	= emev2_boards_compat_dt,
-- 
2.7.0.rc3.207.g0ac5344



From arnd at arndb.de  Fri Feb 12 11:48:58 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 20:48:58 +0100
Subject: [PATCH] Revert "ASoC: qcom: Specify LE device endianness"
In-Reply-To: <1455298217-15744-1-git-send-email-sboyd@codeaurora.org>
References: <1455298217-15744-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <2686474.cvCA6vY47l@wuerfel>

On Friday 12 February 2016 09:30:17 Stephen Boyd wrote:
> This reverts commit 18560a4e3b07438113b50589e78532d95f907029.
> 
> The commit that caused us to specify LE device endianness here,
> 29bb45f25ff3 (regmap-mmio: Use native endianness for read/write,
> 2015-10-29), has been reverted in mainline so now when we specify
> LE it actively breaks big endian kernels because the byte
> swapping in regmap-mmio is incorrect. Let's revert this change
> because it will 1) fix the big endian kernels and 2) be redundant
> to specify LE because that will become the default soon.
> 
> Cc: Kenneth Westfield <kwestfie at codeaurora.org>
> Cc: Kevin Hilman <khilman at linaro.org>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>

Ah, too bad to have to revert a correct change until the infrastructure
is fixed properly, but I guess it's the easier way out here.

What about the other uses of REGMAP_ENDIAN_LITTLE in the kernel?
In particular I see 

drivers/clk/nxp/clk-lpc32xx.c:  .val_format_endian = REGMAP_ENDIAN_LITTLE,

drivers/clk/qcom/gcc-apq8084.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
drivers/clk/qcom/gcc-ipq806x.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
drivers/clk/qcom/gcc-msm8660.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
drivers/clk/qcom/gcc-msm8916.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
drivers/clk/qcom/gcc-msm8960.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
drivers/clk/qcom/gcc-msm8960.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
drivers/clk/qcom/gcc-msm8974.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
drivers/clk/qcom/lcc-ipq806x.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
drivers/clk/qcom/lcc-msm8960.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
drivers/clk/qcom/mmcc-apq8084.c:        .val_format_endian = REGMAP_ENDIAN_LITTLE,
drivers/clk/qcom/mmcc-msm8960.c:        .val_format_endian = REGMAP_ENDIAN_LITTLE,
drivers/clk/qcom/mmcc-msm8960.c:        .val_format_endian = REGMAP_ENDIAN_LITTLE,
drivers/clk/qcom/mmcc-msm8974.c:        .val_format_endian = REGMAP_ENDIAN_LITTLE,

drivers/nvmem/qfprom.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,

and of course

drivers/mfd/syscon.c:   syscon_config.val_format_endian = REGMAP_ENDIAN_LITTLE;

which all look like they are regmap_mmio users as well. Do they 
suffer from the same problem?

	Arnd


From broonie at kernel.org  Fri Feb 12 12:03:11 2016
From: broonie at kernel.org (Mark Brown)
Date: Fri, 12 Feb 2016 20:03:11 +0000
Subject: [PATCH] Revert "ASoC: qcom: Specify LE device endianness"
In-Reply-To: <2686474.cvCA6vY47l@wuerfel>
References: <1455298217-15744-1-git-send-email-sboyd@codeaurora.org>
 <2686474.cvCA6vY47l@wuerfel>
Message-ID: <20160212200311.GB11402@sirena.org.uk>

On Fri, Feb 12, 2016 at 08:48:58PM +0100, Arnd Bergmann wrote:

> which all look like they are regmap_mmio users as well. Do they 
> suffer from the same problem?

Probably, yes.  It's only a problem if they're in systems that might
otherwise run big endian successfully.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/46c8c533/attachment.sig>

From sergei.shtylyov at cogentembedded.com  Fri Feb 12 11:57:06 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Fri, 12 Feb 2016 22:57:06 +0300
Subject: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
In-Reply-To: <20160212193347.GB23472@verge.net.au>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
 <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
 <874mdhtn7d.wl%kuninori.morimoto.gx@renesas.com>
 <20160210171455.GB17671@verge.net.au> <56BE0CB1.4070408@cogentembedded.com>
 <20160212184343.GA31655@verge.net.au> <56BE2DC6.4080802@cogentembedded.com>
 <20160212193347.GB23472@verge.net.au>
Message-ID: <56BE3912.9000601@cogentembedded.com>

On 02/12/2016 10:33 PM, Simon Horman wrote:

>>>>>> Sorry for my un-ordered response
>>>>>>
>>>>>>> Define the generic R8A7794 part of  the sound device node.
>>>>>>> This sound device  is a complex one and comprises the Audio Clock Generator
>>>>>>> (ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
>>>>>>> (SSI[U]), and Audio DMAC-Peripheral-Peripheral.
>>>>>>> It is up  to the board file to enable the device.
>>>>>>>
>>>>>>> This patch is based on the R8A7791 sound work by Kuninori Morimoto.
>>>>>>>
>>>>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>>>>>> (snip)
>>>>>>> +		rcar_sound,src {
>>>>>>> +			src1: src at 1 {
>>>>>>> +				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>> +				dmas = <&audma0 0x87>, <&audma0 0x9c>;
>>>>>>> +				dma-names = "rx", "tx";
>>>>>>> +			};
>>>>>>> +			src2: src at 2 {
>>>>>>> +				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>> +				dmas = <&audma0 0x89>, <&audma0 0x9e>;
>>>>>>> +				dma-names = "rx", "tx";
>>>>>>> +			};
>>>>>>> +			src3: src at 3 {
>>>>>>> +				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>> +				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
>>>>>>> +				dma-names = "rx", "tx";
>>>>>>> +			};
>>>>>>> +			src4: src at 4 {
>>>>>>> +				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>> +				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
>>>>>>> +				dma-names = "rx", "tx";
>>>>>>> +			};
>>>>>>> +			src5: src at 5 {
>>>>>>> +				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>> +				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
>>>>>>> +				dma-names = "rx", "tx";
>>>>>>> +			};
>>>>>>> +			src6: src at 6 {
>>>>>>> +				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>> +				dmas = <&audma0 0x91>, <&audma0 0xb4>;
>>>>>>> +				dma-names = "rx", "tx";
>>>>>>> +			};
>>>>>>> +		};
>>>>>>
>>>>>> I think this can't work correctly, because driver is assuming
>>>>>> DT has all channles (from 0). (see linux/sound/soc/sh/rcar/src.c :: rsnd_src_probe)
>>>>>> Can you adds dummy src0 with some comments ? or fix src.c driver ?
>>>>>
>>>>> I would prefer the driver to be fixed (I had a similar patchset locally
>>>>> and I found it doesn't work).
>>>>
>>>>     You mean you had R8A7794 sound patch set too?
>>>
>>> Yes, I was working on it recently.
>>> I suppose we should coordinate these things in future to avoid
>>> duplicated effort.
>>
>>     Yes, seems a good idea now. :-)
>>
>>>>> The reason is that DT should describe
>>>>> the hardware rather than the current state of the software.
>>>>
>>>>     Yes, of course. Just tell me do I have to fix the driver *before* this
>>>> patch set is accepted?
>>
>>> I did not entirely get to the bottom of the problem, but I think that at
>>> the very least something needs to be done about the for_each_rsnd_src()
>>> loop in rsnd_src_probe.
>>
>>     It's not that it replies to my question. :-)
>>     So you're looking at this issue yourself?
>
> I have not got very far, as you can see, but I was planning to look into it.
> I don't mind if you want to do so.

    After consultation with the management, I'm going to look into this issue 
myself. :-)

>>> My, obviously not satisfactory, hack around there being no src0 was as follows.
>>>
>>> diff --git a/sound/soc/sh/rcar/src.c b/sound/soc/sh/rcar/src.c
>>> index 68b439ed22d7..58a447b0785b 100644
>>> --- a/sound/soc/sh/rcar/src.c
>>> +++ b/sound/soc/sh/rcar/src.c
>>> @@ -1072,7 +1072,7 @@ int rsnd_src_probe(struct platform_device *pdev,
>>>
>>>   	for_each_rsnd_src(src, priv, i) {
>>
>>     Which tree is this? The recent devel branch of renesas.git has
>> for_each_child_of_node() here...
>
> renesas-devel-20160118-v4.4

    Ah! :-)

> I guess the code in question updated in v4.5-rcX.

    Probably...

[...]

MBR, Sergei



From kernel at martin.sperl.org  Fri Feb 12 11:44:25 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Fri, 12 Feb 2016 20:44:25 +0100
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in
 console
In-Reply-To: <F7A2533A-D64C-4187-ABD4-416C446D1637@martin.sperl.org>
References: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
 <56BC895E.2010108@sperl.org>
 <1617009200.323700.219000a8-c162-4594-aacc-a7e9894518b2.open-xchange@email.1und1.de>
 <662D2FB2-B088-4CFC-8416-A4F35BBAD7DD@sperl.org>
 <F7A2533A-D64C-4187-ABD4-416C446D1637@martin.sperl.org>
Message-ID: <6CD3FC59-BA17-43D9-897C-A2D122D26EF8@martin.sperl.org>


> On 12.02.2016, at 18:34, Martin Sperl <kernel at martin.sperl.org> wrote:
> 
> The screen is still blinking and UART does not work.
> Maybe the driver is not able to handle the ?remapping?
> of registers to a different range and is touching ram
> used by the FW?
> 
> The only solution that I found is using fixed clocks
> in the device-tree (which is not what we intended:
> / {
>                clk_uart0: clock at 3 {
>                        compatible = "fixed-clock";
>                        reg = <3>;
>                        #clock-cells = <0>;
>                        clock-output-names = "uart0_pclk";
>                        clock-frequency = <3000000>;
>                };
> 
>                clk_apb_p: clock at 4 {
>                        compatible = "fixed-clock";
>                        reg = <4>;
>                        #clock-cells = <0>;
>                        clock-output-names = "apb_pclk";
>                        clock-frequency = <126000000>;
>                };
> };
> &uart0 {
>        clocks = <&clk_uart0 &clk_apb_p>;
> };
> 
> (so I have ruled out that the amba-pl011 writes to
> the wrong addresses).
> 
> So as far as I can tell it is only clock related
> and when the new clock-framework is used it fails...

So the issue is triggered as soon as the plld_per
pll divider gets disabled/reenabled.

This happens because the clk_hw.core.prepare_count
drops down to 0 and then unprepare is called.

So we need to increase the ref-count for the pll
and pll_dividers to at least 1 so that these never
get disabled - at least for now until we can come
up with a better contract with the firmware.

Obviously this may impact other drivers as well
where a pll is used for the first time - if nothing
else uses it and the clock gets released, then
the clock would trigger a unprepare of the whole
branch of the clock tree.

The question is: how can we solve it in an acceptable
manner?

Do we need a driver that just holds a reference to
those clocks? Or should we just prepare the clock
after registering it in clk-bcm2835.c?

As for why does this not show up when compiled in?
It seems that in that case the amba_pl011 driver
never gets removed and then probed again.

This is possibly related to the optional use of DMA,
with the amba-pl011 driver that retries the install,
which is not supported on the bcm2835 - at least that
is what the datasheet says. And DMA is (probably) not
enabled during the early boot stages, so it does not
fail once when it tries to register DMA.

Thanks,
	Martin




From matthias.bgg at gmail.com  Fri Feb 12 12:10:29 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Fri, 12 Feb 2016 21:10:29 +0100
Subject: [PATCH v5sub1 0/8] arm64: split linear and kernel mappings
In-Reply-To: <CAKv+Gu9Qw=DSe1fZT=Dv=iKaKqzsf5ARK9dzwCWPk_0uRECm1w@mail.gmail.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <56BE3645.3030403@gmail.com>
 <CAKv+Gu9Qw=DSe1fZT=Dv=iKaKqzsf5ARK9dzwCWPk_0uRECm1w@mail.gmail.com>
Message-ID: <56BE3C35.7070608@gmail.com>



On 12/02/16 20:47, Ard Biesheuvel wrote:
> On 12 February 2016 at 20:45, Matthias Brugger <matthias.bgg at gmail.com> wrote:
>> Hi Ard,
>>
>>
>> On 01/02/16 11:54, Ard Biesheuvel wrote:
>>>
>>> At the request of Catalin, this series has been split off from my series
>>> 'arm64: implement support for KASLR v4' [1]. This sub-series deals with
>>> moving the kernel out of the linear mapping into the vmalloc area. This
>>> is a prerequisite for independent physical and virtual randomization of
>>> the kernel image. On top of that, considering that these changes allow
>>> the linear mapping to start at an arbitrary offset above PAGE_OFFSET, it
>>> should be an improvement in itself due to the fact that we can now choose
>>> PAGE_OFFSET such that RAM can be mapped using large block sizes.
>>>
>>> For instance, on my Seattle A0 box, the kernel is loaded 16 MB into the
>>> lowest GB of RAM, which means __pa(PAGE_OFFSET) is not 1 GB aligned, and
>>> the entire 16 GB of RAM will be mapping using 2 MB blocks. (Similarly,
>>> for 64 KB granule kernels, the entire 16 GB of RAM will be mapped using
>>> pages since __pa(PAGE_OFFSET) is not 512 MB aligned). With these changes
>>>    __pa(PAGE_OFFSET) will always be chosen such that it is aligned to a
>>> quantity that allows efficient mapping.
>>>
>>> Note that of the entire KASLR series, this sub-series is the most likely
>>> to
>>> cause problems, and hence requires the most careful review and testing.
>>> This
>>> is due to the fact that, with these changes, the invariant __va(__pa(x))
>>> == x
>>> no longer holds, and any code that is based on that assumption needs to be
>>> updated.
>>>
>>> Changes since v4:
>>> - added Marc's ack to patch #6
>>> - round the kasan zero shadow region around the kernel image to swapper
>>> block
>>>     size (#7)
>>> - ensure that we don't clip the kernel image when clipping RAM to the
>>> linear
>>>     region size (#8)
>>>
>>> Patch #1 allows the low mark of memblocks discovered from the FDT to be
>>> overridden by the architecture.
>>>
>>> Patch #2 enables the huge-vmap generic feature for arm64. This should be
>>> an
>>> improvement in itself, but the significance for this series is that it
>>> allows
>>> unmap_kernel_range() to be called on the [__init_begin, __init_end)
>>> region,
>>> which may be partially mapped using block mappings.
>>>
>>> Patch #3 introduces KIMAGE_VADDR as a separate, preparatory step towards
>>> decoupling the kernel placement from PAGE_OFFSET
>>>
>>> Patch #4 implements some translation table accessors that operate on
>>> statically
>>> allocate translation tables before the linear mapping is up.
>>>
>>> Patch #5 decouples the fixmap initialization from the linear mapping, by
>>> using
>>> the accessors implemented by patch #4
>>>
>>> Patch #6 removes assumptions made my KVM regarding the placement of the
>>> kernel
>>> image inside the linear mapping.
>>>
>>> Patch #7 moves the kernel image from the base of the linear mapping to the
>>> base
>>> of the vmalloc area. The modules area, which sits right below the kernel
>>> image,
>>> is moved along and is put right before the start of the vmalloc area.
>>>
>>> Patch #8 decouples PHYS_OFFSET from PAGE_OFFSET, which allows the linear
>>> mapping
>>> to cover all discovered memory, regardless of where the kernel image is
>>> located
>>> in it. This effectively allows the kernel to be loaded at any physical
>>> address
>>> (provided that the correct alignment is used)
>>>
>>> [1] http://thread.gmane.org/gmane.linux.kernel/2135931
>>>
>>> Ard Biesheuvel (8):
>>>     of/fdt: make memblock minimum physical address arch configurable
>>>     arm64: add support for ioremap() block mappings
>>>     arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
>>>     arm64: pgtable: implement static [pte|pmd|pud]_offset variants
>>>     arm64: decouple early fixmap init from linear mapping
>>>     arm64: kvm: deal with kernel symbols outside of linear mapping
>>>     arm64: move kernel image to base of vmalloc area
>>>     arm64: allow kernel Image to be loaded anywhere in physical memory
>>>
>>
>> I bisected linux-next (20160212) with the following error on booting with an
>> initramfs:
>>   Failed to execute /init (error -8)
>>   request_module: runaway loop modprobe binfmt-464c
>>   Starting init: /sbin/init exists but couldn't execute it (error -8)
>>   request_module: runaway loop modprobe binfmt-464c
>>   Starting init: /bin/sh exists but couldn't execute it (error -8)
>>   Kernel panic - not syncing: No working init found.  Try passing init=
>> option to kernel. See Linux Documentation/init..
>>
>> I tracked down the error to patch 7 of this series. But I realized that
>> patch 7 does not compile, but from patch 8 onwards I observe the error.
>>
>> I use defconfig with an initramfs.cpio created with buildroot.
>> I tested this on my mt8173 eval board, but I suppose this can be reproduced
>> easily on other machines as well.
>>
>
> Thanks for the report. Does this help at all?
>
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/477645
>

I applied them on top of linux-next and this fixed the problem.

Thanks,
Matthias

>> Regards,
>> Matthias
>>
>>
>>>    Documentation/arm64/booting.txt                      |  20 ++-
>>>    Documentation/features/vm/huge-vmap/arch-support.txt |   2 +-
>>>    arch/arm/include/asm/kvm_asm.h                       |   2 +
>>>    arch/arm/kvm/arm.c                                   |   8 +-
>>>    arch/arm64/Kconfig                                   |   1 +
>>>    arch/arm64/include/asm/boot.h                        |   6 +
>>>    arch/arm64/include/asm/kasan.h                       |   2 +-
>>>    arch/arm64/include/asm/kernel-pgtable.h              |  12 ++
>>>    arch/arm64/include/asm/kvm_asm.h                     |   2 +
>>>    arch/arm64/include/asm/kvm_host.h                    |   8 +-
>>>    arch/arm64/include/asm/memory.h                      |  44 ++++--
>>>    arch/arm64/include/asm/pgtable.h                     |  23 ++-
>>>    arch/arm64/kernel/head.S                             |   8 +-
>>>    arch/arm64/kernel/image.h                            |  13 +-
>>>    arch/arm64/kernel/vmlinux.lds.S                      |   4 +-
>>>    arch/arm64/kvm/hyp.S                                 |   6 +-
>>>    arch/arm64/mm/dump.c                                 |  12 +-
>>>    arch/arm64/mm/init.c                                 | 123
>>> ++++++++++++++--
>>>    arch/arm64/mm/kasan_init.c                           |  31 +++-
>>>    arch/arm64/mm/mmu.c                                  | 155
>>> +++++++++++++++-----
>>>    drivers/of/fdt.c                                     |   5 +-
>>>    21 files changed, 378 insertions(+), 109 deletions(-)
>>>
>>


From mathieu.poirier at linaro.org  Fri Feb 12 12:33:58 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Fri, 12 Feb 2016 13:33:58 -0700
Subject: [PATCH V2 3/6] stm class: provision for statically assigned
 masterIDs
In-Reply-To: <87r3gh3nd7.fsf@ashishki-desk.ger.corp.intel.com>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
 <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org>
 <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com>
 <CANLsYky2twQ98u241YyHD=atYRp1N56YVHUQNY2E2Ljsq0cseA@mail.gmail.com>
 <87twlj49k7.fsf@ashishki-desk.ger.corp.intel.com>
 <CANLsYkw=mG+ch8QzxmbwWs9o+mndVNo1MuqXcrPrNJYj_SQcHQ@mail.gmail.com>
 <87r3gh3nd7.fsf@ashishki-desk.ger.corp.intel.com>
Message-ID: <CANLsYkz1nNYdcTXrkZ+HAMHexNandm93EpM7auvYE4CY43hy6w@mail.gmail.com>

On 12 February 2016 at 09:27, Alexander Shishkin
<alexander.shishkin at linux.intel.com> wrote:
> Mathieu Poirier <mathieu.poirier at linaro.org> writes:
>
>> On 8 February 2016 at 06:26, Alexander Shishkin
>> <alexander.shishkin at linux.intel.com> wrote:
>>> This $end==$start situation itself may be ambiguous and can be
>>> interpreted either as having just one *static* master ID fixed for all
>>> SW writers (what I assumed from your commit message) or as having a
>>> floating master ID, which changes of its own accord and is not
>>> controllable by software.
>>
>> Some clarification here.
>>
>> On ARM from a SW point of view $end == $start and that doesn't change
>> (with regards to masterIDs) .  The ambiguity comes from the fact that
>> on other platforms where masterID configuration does change and is
>> important, the condition $end == $start could also be valid.
>
> Yes, that's what I was saying. The thing is, on the system-under-tracing
> side these two situations are not very different from one
> another. Master IDs are really just numbers without any semantics
> attached to them in the sense that they are not covered by the mipi spec
> or any other standard (to my knowledge).

We are definitely on the same page here, just using slightly different terms.

>
> The difference is in the way we map channels to masters. One way is to
> allocate a distinct set of channels for each master (the way Intel Trace
> Hub does it); another way is to share the same set of channels between
> multiple masters.

We are in total agreement.

> So we can describe this as "hardware implements the
> same set of channels across multiple masters" or something along those
> lines.

I suggest "Shared channels"?  In the end, that's really what it is...

The outstanding issue is still how to represent these to different way
of mapping things in the STM core.  I suggested a flag, called
"mstatic" (but that can be changed), and a representation of '-1' in
for masterIDs sysFS.  Whether we stick with that or not is irrelevant,
I'd be fine with another mechanism.  What I am keen on is that from
sysFS users can quickly tell which heuristic is enacted on that
specific architecture.

>
> Actually, in the latter scheme of things you can also have multiple
> masters, at least theoretically. Say, you have masters [0..15], each
> with distinct set of channels, but depending on hardware state these
> masters actually end up as $state*16+$masterID in the STP stream.
>
> So we might also think about differentiating between the hardware
> masters (0 though 15 in the above example) and STP masters.

I'm not sure I get what you mean here.  On ARM the masterIDs assigned
in HW, which will depend on the state, will show up in the STP stream.
But again, I might be missing your point.

Thanks,
Mathieu

>
> Regards,
> --
> Alex


From arnd at arndb.de  Fri Feb 12 12:35:26 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 21:35:26 +0100
Subject: [PATCH] Revert "ASoC: qcom: Specify LE device endianness"
In-Reply-To: <20160212200311.GB11402@sirena.org.uk>
References: <1455298217-15744-1-git-send-email-sboyd@codeaurora.org>
 <2686474.cvCA6vY47l@wuerfel> <20160212200311.GB11402@sirena.org.uk>
Message-ID: <4609707.AR30v8FONr@wuerfel>

On Friday 12 February 2016 20:03:11 Mark Brown wrote:
> On Fri, Feb 12, 2016 at 08:48:58PM +0100, Arnd Bergmann wrote:
> 
> > which all look like they are regmap_mmio users as well. Do they 
> > suffer from the same problem?
> 
> Probably, yes.  It's only a problem if they're in systems that might
> otherwise run big endian successfully.
> 

The affected clock drivers seem to include all the qcom platforms,
so I assumed that whatever platform uses sound/soc/qcom/lpass-cpu.c
has to use one of those as well. Same thing for drivers/nvmem/qfprom.c.

lpc32xx probably won't support big-endian.

syscon is probably fine because it only sets that flag based on the
"little-endian" DT property and I don't see anything setting that
(except the one platform that did so incorrectly).

	Arnd


From ard.biesheuvel at linaro.org  Fri Feb 12 12:37:02 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 12 Feb 2016 21:37:02 +0100
Subject: [PATCH v5sub1 0/8] arm64: split linear and kernel mappings
In-Reply-To: <56BE3C35.7070608@gmail.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <56BE3645.3030403@gmail.com>
 <CAKv+Gu9Qw=DSe1fZT=Dv=iKaKqzsf5ARK9dzwCWPk_0uRECm1w@mail.gmail.com>
 <56BE3C35.7070608@gmail.com>
Message-ID: <CAKv+Gu_oRxvw_543M21Z_5qcUd8euWnn8T-qzrneQMw_z5SQkQ@mail.gmail.com>

On 12 February 2016 at 21:10, Matthias Brugger <matthias.bgg at gmail.com> wrote:
>
>
> On 12/02/16 20:47, Ard Biesheuvel wrote:
>>
>> On 12 February 2016 at 20:45, Matthias Brugger <matthias.bgg at gmail.com>
>> wrote:
>>>
>>> Hi Ard,
>>>
>>>
>>> On 01/02/16 11:54, Ard Biesheuvel wrote:
>>>>
>>>>
>>>> At the request of Catalin, this series has been split off from my series
>>>> 'arm64: implement support for KASLR v4' [1]. This sub-series deals with
>>>> moving the kernel out of the linear mapping into the vmalloc area. This
>>>> is a prerequisite for independent physical and virtual randomization of
>>>> the kernel image. On top of that, considering that these changes allow
>>>> the linear mapping to start at an arbitrary offset above PAGE_OFFSET, it
>>>> should be an improvement in itself due to the fact that we can now
>>>> choose
>>>> PAGE_OFFSET such that RAM can be mapped using large block sizes.
>>>>
>>>> For instance, on my Seattle A0 box, the kernel is loaded 16 MB into the
>>>> lowest GB of RAM, which means __pa(PAGE_OFFSET) is not 1 GB aligned, and
>>>> the entire 16 GB of RAM will be mapping using 2 MB blocks. (Similarly,
>>>> for 64 KB granule kernels, the entire 16 GB of RAM will be mapped using
>>>> pages since __pa(PAGE_OFFSET) is not 512 MB aligned). With these changes
>>>>    __pa(PAGE_OFFSET) will always be chosen such that it is aligned to a
>>>> quantity that allows efficient mapping.
>>>>
>>>> Note that of the entire KASLR series, this sub-series is the most likely
>>>> to
>>>> cause problems, and hence requires the most careful review and testing.
>>>> This
>>>> is due to the fact that, with these changes, the invariant __va(__pa(x))
>>>> == x
>>>> no longer holds, and any code that is based on that assumption needs to
>>>> be
>>>> updated.
>>>>
>>>> Changes since v4:
>>>> - added Marc's ack to patch #6
>>>> - round the kasan zero shadow region around the kernel image to swapper
>>>> block
>>>>     size (#7)
>>>> - ensure that we don't clip the kernel image when clipping RAM to the
>>>> linear
>>>>     region size (#8)
>>>>
>>>> Patch #1 allows the low mark of memblocks discovered from the FDT to be
>>>> overridden by the architecture.
>>>>
>>>> Patch #2 enables the huge-vmap generic feature for arm64. This should be
>>>> an
>>>> improvement in itself, but the significance for this series is that it
>>>> allows
>>>> unmap_kernel_range() to be called on the [__init_begin, __init_end)
>>>> region,
>>>> which may be partially mapped using block mappings.
>>>>
>>>> Patch #3 introduces KIMAGE_VADDR as a separate, preparatory step towards
>>>> decoupling the kernel placement from PAGE_OFFSET
>>>>
>>>> Patch #4 implements some translation table accessors that operate on
>>>> statically
>>>> allocate translation tables before the linear mapping is up.
>>>>
>>>> Patch #5 decouples the fixmap initialization from the linear mapping, by
>>>> using
>>>> the accessors implemented by patch #4
>>>>
>>>> Patch #6 removes assumptions made my KVM regarding the placement of the
>>>> kernel
>>>> image inside the linear mapping.
>>>>
>>>> Patch #7 moves the kernel image from the base of the linear mapping to
>>>> the
>>>> base
>>>> of the vmalloc area. The modules area, which sits right below the kernel
>>>> image,
>>>> is moved along and is put right before the start of the vmalloc area.
>>>>
>>>> Patch #8 decouples PHYS_OFFSET from PAGE_OFFSET, which allows the linear
>>>> mapping
>>>> to cover all discovered memory, regardless of where the kernel image is
>>>> located
>>>> in it. This effectively allows the kernel to be loaded at any physical
>>>> address
>>>> (provided that the correct alignment is used)
>>>>
>>>> [1] http://thread.gmane.org/gmane.linux.kernel/2135931
>>>>
>>>> Ard Biesheuvel (8):
>>>>     of/fdt: make memblock minimum physical address arch configurable
>>>>     arm64: add support for ioremap() block mappings
>>>>     arm64: introduce KIMAGE_VADDR as the virtual base of the kernel
>>>> region
>>>>     arm64: pgtable: implement static [pte|pmd|pud]_offset variants
>>>>     arm64: decouple early fixmap init from linear mapping
>>>>     arm64: kvm: deal with kernel symbols outside of linear mapping
>>>>     arm64: move kernel image to base of vmalloc area
>>>>     arm64: allow kernel Image to be loaded anywhere in physical memory
>>>>
>>>
>>> I bisected linux-next (20160212) with the following error on booting with
>>> an
>>> initramfs:
>>>   Failed to execute /init (error -8)
>>>   request_module: runaway loop modprobe binfmt-464c
>>>   Starting init: /sbin/init exists but couldn't execute it (error -8)
>>>   request_module: runaway loop modprobe binfmt-464c
>>>   Starting init: /bin/sh exists but couldn't execute it (error -8)
>>>   Kernel panic - not syncing: No working init found.  Try passing init=
>>> option to kernel. See Linux Documentation/init..
>>>
>>> I tracked down the error to patch 7 of this series. But I realized that
>>> patch 7 does not compile, but from patch 8 onwards I observe the error.
>>>
>>> I use defconfig with an initramfs.cpio created with buildroot.
>>> I tested this on my mt8173 eval board, but I suppose this can be
>>> reproduced
>>> easily on other machines as well.
>>>
>>
>> Thanks for the report. Does this help at all?
>>
>> http://thread.gmane.org/gmane.linux.ports.arm.kernel/477645
>>
>
> I applied them on top of linux-next and this fixed the problem.
>

Great! Thanks for testing

>>> Regards,
>>> Matthias
>>>
>>>
>>>>    Documentation/arm64/booting.txt                      |  20 ++-
>>>>    Documentation/features/vm/huge-vmap/arch-support.txt |   2 +-
>>>>    arch/arm/include/asm/kvm_asm.h                       |   2 +
>>>>    arch/arm/kvm/arm.c                                   |   8 +-
>>>>    arch/arm64/Kconfig                                   |   1 +
>>>>    arch/arm64/include/asm/boot.h                        |   6 +
>>>>    arch/arm64/include/asm/kasan.h                       |   2 +-
>>>>    arch/arm64/include/asm/kernel-pgtable.h              |  12 ++
>>>>    arch/arm64/include/asm/kvm_asm.h                     |   2 +
>>>>    arch/arm64/include/asm/kvm_host.h                    |   8 +-
>>>>    arch/arm64/include/asm/memory.h                      |  44 ++++--
>>>>    arch/arm64/include/asm/pgtable.h                     |  23 ++-
>>>>    arch/arm64/kernel/head.S                             |   8 +-
>>>>    arch/arm64/kernel/image.h                            |  13 +-
>>>>    arch/arm64/kernel/vmlinux.lds.S                      |   4 +-
>>>>    arch/arm64/kvm/hyp.S                                 |   6 +-
>>>>    arch/arm64/mm/dump.c                                 |  12 +-
>>>>    arch/arm64/mm/init.c                                 | 123
>>>> ++++++++++++++--
>>>>    arch/arm64/mm/kasan_init.c                           |  31 +++-
>>>>    arch/arm64/mm/mmu.c                                  | 155
>>>> +++++++++++++++-----
>>>>    drivers/of/fdt.c                                     |   5 +-
>>>>    21 files changed, 378 insertions(+), 109 deletions(-)
>>>>
>>>
>


From mathieu.poirier at linaro.org  Fri Feb 12 12:44:31 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Fri, 12 Feb 2016 13:44:31 -0700
Subject: [PATCH] coresight: etb: Remove simple announcement message
In-Reply-To: <1455195004-30214-1-git-send-email-broonie@kernel.org>
References: <1455195004-30214-1-git-send-email-broonie@kernel.org>
Message-ID: <CANLsYkwVn4FgBST-0MeOa38qCkH78-z32_CXewcCF78CnvbxeQ@mail.gmail.com>

On 11 February 2016 at 05:50, Mark Brown <broonie at kernel.org> wrote:
> It's generally preferred that drivers not print initialisation messages on
> startup that don't contain information gained at runtime such as specific
> hardware revision information. This provides a small speedup on systems
> with serial consoles and keeps the boot less noisy.
>
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---
>  drivers/hwtracing/coresight/coresight-etb10.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
> index 92969dae739d..18c55d1c428c 100644
> --- a/drivers/hwtracing/coresight/coresight-etb10.c
> +++ b/drivers/hwtracing/coresight/coresight-etb10.c
> @@ -481,7 +481,6 @@ static int etb_probe(struct amba_device *adev, const struct amba_id *id)
>         if (ret)
>                 goto err_misc_register;
>
> -       dev_info(dev, "ETB initialized\n");
>         return 0;

Didn't we touch base on that topic before?  I'm not against moving
forward with this but it has to be all or nothing - whether we remove
all the CS boot log message or they all stay.  Otherwise people could
mistakenly come to the conclusion that some of the CS components did
not boot properly.

ETB, funnel and TMCs don't output any useful HW related information
but tracers (ETMv3, PTM and ETMv4) actually do.

People concerned about boot time will definitely set their loglevel
accordingly on the kernel cmd line.  Otherwise we are likely talking
about developers interested in knowing what happened when their kernel
booted.

Thanks,
Mathieu

>
>  err_misc_register:
> --
> 2.7.0
>


From lina.iyer at linaro.org  Fri Feb 12 12:50:26 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Fri, 12 Feb 2016 13:50:26 -0700
Subject: [RFC v2 00/12] PM: SoC idle support using PM domains
Message-ID: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>

Hi all,

Changes since RFC v1 [1] -
- genpd lock abstraction using fn ptrs. Sparse is happier.
- Removed restriction that IRQ-safe domains can only have IRQ safe parents [3]
- changes in the way CPU domains are initialized, starting from CPU now
	* cpu-map node dependency removed
	* platform driver initiate CPU PM domain setup
- smaller patchset excluding genpd multiple level changes
	* they were submitted to ML earlier [2]
- cpuidle runtime PM and hotplug changes
- PSCI changes to detect if the f/w supports OSI
- updated documentation
- this new cover description

This series allows CPU common hardware blocks to enter idle state, when the
CPUs are in idle. A lightweight but important power saving in a battery powered
device is power savings when the device is not suspended. While being active,
the CPUs can save power by entering low power states with the help of cpuidle
framework, but the hardware supporting these CPU still remain active. This is
an effort in reducing power on these h/w block around the CPU during cpuidle.

Every CPU decides for itself the deepest low power mode possible and enters
that state to be more power effecient. This is unlike coupled states, where
CPUs have to wait until the last of the CPU is ready to enter the deepest idle.
The last of the CPU that enters idle decides for the domain, the best idle
state the domain may enter. This is also a higher level than what MCPM solves.
In newer SoC's the coherency and other race conditions coming out of warm reset
are handled in the firmware. This patchset helps Linux make the right power
decision for other h/w blocks that are dependent on the CPUs.

The idea is that CPU hierarchy (represented in DT) is modelled as regular
devices attached to their PM domains, which in turn may be attached to its
parent domain. When cpuidle puts the CPU to sleep, runtime PM for the CPU
device is notified, which suspends the CPU device. This triggers a reduction in
genpd domain usage count. When the last device in a domain suspends, the domain
is powered off as part of the same call. Similarly, the domain resumes before
the first CPU device resumes from idle. To achieve this the following changes
are needed -
	- genpd to support multiple idle states (more than just on/off)
	- genpd should support suspend/resume from IRQ safe context
	- CPU devices set up for runtime PM, as IRQ safe devices
	- cpuidle calls runtime PM ops when idling
	- the genpd power downs calling into a gov to determine the deepest idle state 
	- genpd ->power_on()/->power_off() callbacks to be handled by the platform

Patches from Axel [2] allow genpd to define multiple idle states and choose the
best idle state from them.

These patches build up on top of that -

- Patches [1, 2] - Genpd changes
Sets up Generic PM domains to be called from cpuidle. Genpd uses mutexes for
synchronization. This has to be changed to spinlocks for domains that may be
called from IRQ safe contexts.

- Patch [3] - CPU PM domains
Parses DT and sets up PM domains for CPUs and builds up the hierarchy of
domains and devices. These are bunch of helper functions.

- Patch [4] - ARM cpuidle driver
Enable ARM cpuidle driver to call runtime PM. Even though this has been done
for ARM, there is nothing architecture specific about this. Currently, all idle
states other than ARM clock gating calls into runtime PM. This could also be
state specific i.e call into runtime PM only after a certain state. The changes
may be made part of cpuidle framework, but needs discussion.

- Patches [5, 6, 7] - PM domain governor for CPUs
Introduces a new genpd governor that looks into the per-CPU tick device to
identify the next CPU wakeup and determine the available sleep time for the
domain. This along with QoS is used to determine the best idle state for the
domain. A domains' wake up is determined by the first CPU in that domain to
wake up. A coherency level domain's (parent of a domain containing CPU devices)
wake up is determined by the first CPU amongst all the CPUs to wake up.
Identifying the CPUs and their wakeups are the part of these patches.

- Patches [9, 10] - ARM64 PSCI platform driver
ARM64 PSCI v1.0 specific. PSCI OS initiated mode supports powering off CPU
clusters (caches etc, by configuring separate power controllers). These patches
enable Linux to determine if the f/w supports this mode and if so, uses CPU PM
domain helper functions to create PM domains and handles the power_on/power_off
callbacks. The resulting cluster state is passed as an argument to the f/w
along with the CPU state.

- Patches [11, 12] - DTS changes for MSM8916
QCOM 410c Dragonboard/96Board specific. Enables CPUidle and cluster idle for
this SoC. A compatible f/w (in the works) is needed for this support.

Testing and results -

This patchset has been tested on a QCOM 410c Dragonboard with a quad ARM v8 A53
CPU and 512KB L2 cache. Though not accurate, I see a ~20 mA drop in current
measured at the battery outside the SoC when the SoC idle is enabled. This
needs to be redone again to get an accurate measurement. I see about ~5 us
increase before entering idle state to determine the last man down and about
~20 us while coming out of idle (in Linux) when the cache is flushed and
powered down.

This was tested on top of 4.5-rc3. My series along with patches from Axel can
be found at [4]. Note that [5] has not been published on the ML, is needed for
this series.

Thanks,
Lina

[1]. http://comments.gmane.org/gmane.linux.ports.arm.msm/16232
[2]. http://permalink.gmane.org/gmane.linux.power-management.general/71387
[3]. http://permalink.gmane.org/gmane.linux.ports.arm.msm/17279
[4]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-psci-RFC-v2
[5]. https://git.linaro.org/people/lina.iyer/linux-next.git/commit/1dfec82c8c133b0fbcd245d739dade087a1dd1fc

Lina Iyer (12):
  PM / Domains: Abstract genpd locking
  PM / Domains: Support IRQ safe PM domains
  PM / cpu_domains: Setup PM domains for CPUs/clusters
  ARM: cpuidle: Add runtime PM support for CPUs
  timer: Export next wake up of a CPU
  PM / cpu_domains: Record CPUs that are part of the domain
  PM / cpu_domains: Add PM Domain governor for CPUs
  Documentation / cpu_domains: Describe CPU PM domains setup and
    governor
  drivers: firmware: psci: Allow OS Initiated suspend mode
  ARM64: psci: Support cluster idle states for OS-Initiated
  ARM64: dts: Add PSCI cpuidle support for MSM8916
  ARM64: dts: Define CPU power domain for MSM8916

 Documentation/power/cpu_domains.txt   |  79 ++++++++
 Documentation/power/devices.txt       |  12 +-
 arch/arm64/boot/dts/qcom/msm8916.dtsi |  49 +++++
 arch/arm64/kernel/psci.c              |  46 ++++-
 drivers/base/power/Makefile           |   1 +
 drivers/base/power/cpu_domains.c      | 361 ++++++++++++++++++++++++++++++++++
 drivers/base/power/domain.c           | 217 ++++++++++++++++----
 drivers/cpuidle/cpuidle-arm.c         |  48 +++++
 drivers/firmware/psci.c               |  45 ++++-
 include/linux/cpu_domains.h           |  35 ++++
 include/linux/pm_domain.h             |  14 +-
 include/linux/psci.h                  |   2 +
 include/linux/tick.h                  |  10 +
 include/uapi/linux/psci.h             |   5 +
 kernel/time/tick-sched.c              |  13 ++
 15 files changed, 889 insertions(+), 47 deletions(-)
 create mode 100644 Documentation/power/cpu_domains.txt
 create mode 100644 drivers/base/power/cpu_domains.c
 create mode 100644 include/linux/cpu_domains.h

-- 
2.1.4



From lina.iyer at linaro.org  Fri Feb 12 12:50:27 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Fri, 12 Feb 2016 13:50:27 -0700
Subject: [RFC v2 01/12] PM / Domains: Abstract genpd locking
In-Reply-To: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
References: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
Message-ID: <1455310238-8963-2-git-send-email-lina.iyer@linaro.org>

Abstract genpd lock/unlock calls, in preparation for domain specific
locks added in the following patches.

Cc: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Kevin Hilman <khilman at linaro.org>
Cc: Rafael J. Wysocki <rjw at rjwysocki.net>
Cc: Geert Uytterhoeven <geert at linux-m68k.org>
Cc: Krzysztof Koz?owski <k.kozlowski at samsung.com>
Signed-off-by: Lina Iyer <lina.iyer at linaro.org>
---
Changes since RFC v1 -
- split into two patches. This patch abstracts genpd locking
- uses function pointer, instead of runtime function determination

 drivers/base/power/domain.c | 109 ++++++++++++++++++++++++++++++--------------
 include/linux/pm_domain.h   |   5 +-
 2 files changed, 79 insertions(+), 35 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 3ddd05d..8204615 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -40,6 +40,46 @@
 static LIST_HEAD(gpd_list);
 static DEFINE_MUTEX(gpd_list_lock);
 
+struct genpd_lock_fns {
+	void (*lock)(struct generic_pm_domain *genpd);
+	void (*lock_nested)(struct generic_pm_domain *genpd, int depth);
+	int (*lock_interruptible)(struct generic_pm_domain *genpd);
+	void (*unlock)(struct generic_pm_domain *genpd);
+};
+
+static void genpd_lock_irq(struct generic_pm_domain *genpd)
+{
+	mutex_lock(&genpd->mlock);
+}
+
+static void genpd_lock_irq_nested(struct generic_pm_domain *genpd,
+					int depth)
+{
+	mutex_lock_nested(&genpd->mlock, depth);
+}
+
+static int genpd_lock_interruptible_irq(struct generic_pm_domain *genpd)
+{
+	return mutex_lock_interruptible(&genpd->mlock);
+}
+
+static void genpd_unlock_irq(struct generic_pm_domain *genpd)
+{
+	return mutex_unlock(&genpd->mlock);
+}
+
+static struct genpd_lock_fns irq_lock = {
+	.lock = genpd_lock_irq,
+	.lock_nested = genpd_lock_irq_nested,
+	.lock_interruptible = genpd_lock_interruptible_irq,
+	.unlock = genpd_unlock_irq,
+};
+
+#define genpd_lock(p)			p->lock_fns->lock(p)
+#define genpd_lock_nested(p, d)		p->lock_fns->lock_nested(p, d)
+#define genpd_lock_interruptible(p)	p->lock_fns->lock_interruptible(p)
+#define genpd_unlock(p)			p->lock_fns->unlock(p)
+
 /*
  * Get the generic PM domain for a particular struct device.
  * This validates the struct device pointer, the PM domain pointer,
@@ -202,9 +242,9 @@ static int genpd_poweron(struct generic_pm_domain *genpd, unsigned int depth)
 
 		genpd_sd_counter_inc(master);
 
-		mutex_lock_nested(&master->lock, depth + 1);
+		genpd_lock_nested(master, depth + 1);
 		ret = genpd_poweron(master, depth + 1);
-		mutex_unlock(&master->lock);
+		genpd_unlock(master);
 
 		if (ret) {
 			genpd_sd_counter_dec(master);
@@ -268,9 +308,9 @@ static int genpd_dev_pm_qos_notifier(struct notifier_block *nb,
 		spin_unlock_irq(&dev->power.lock);
 
 		if (!IS_ERR(genpd)) {
-			mutex_lock(&genpd->lock);
+			genpd_lock(genpd);
 			genpd->max_off_time_changed = true;
-			mutex_unlock(&genpd->lock);
+			genpd_unlock(genpd);
 		}
 
 		dev = dev->parent;
@@ -367,9 +407,9 @@ static void genpd_power_off_work_fn(struct work_struct *work)
 
 	genpd = container_of(work, struct generic_pm_domain, power_off_work);
 
-	mutex_lock(&genpd->lock);
+	genpd_lock(genpd);
 	genpd_poweroff(genpd, true);
-	mutex_unlock(&genpd->lock);
+	genpd_unlock(genpd);
 }
 
 /**
@@ -439,9 +479,9 @@ static int pm_genpd_runtime_suspend(struct device *dev)
 	if (dev->power.irq_safe)
 		return 0;
 
-	mutex_lock(&genpd->lock);
+	genpd_lock(genpd);
 	genpd_poweroff(genpd, false);
-	mutex_unlock(&genpd->lock);
+	genpd_unlock(genpd);
 
 	return 0;
 }
@@ -476,9 +516,9 @@ static int pm_genpd_runtime_resume(struct device *dev)
 		goto out;
 	}
 
-	mutex_lock(&genpd->lock);
+	genpd_lock(genpd);
 	ret = genpd_poweron(genpd, 0);
-	mutex_unlock(&genpd->lock);
+	genpd_unlock(genpd);
 
 	if (ret)
 		return ret;
@@ -692,14 +732,14 @@ static int pm_genpd_prepare(struct device *dev)
 	if (resume_needed(dev, genpd))
 		pm_runtime_resume(dev);
 
-	mutex_lock(&genpd->lock);
+	genpd_lock(genpd);
 
 	if (genpd->prepared_count++ == 0) {
 		genpd->suspended_count = 0;
 		genpd->suspend_power_off = genpd->status == GPD_STATE_POWER_OFF;
 	}
 
-	mutex_unlock(&genpd->lock);
+	genpd_unlock(genpd);
 
 	if (genpd->suspend_power_off) {
 		pm_runtime_put_noidle(dev);
@@ -717,12 +757,12 @@ static int pm_genpd_prepare(struct device *dev)
 
 	ret = pm_generic_prepare(dev);
 	if (ret) {
-		mutex_lock(&genpd->lock);
+		genpd_lock(genpd);
 
 		if (--genpd->prepared_count == 0)
 			genpd->suspend_power_off = false;
 
-		mutex_unlock(&genpd->lock);
+		genpd_unlock(genpd);
 		pm_runtime_enable(dev);
 	}
 
@@ -1080,13 +1120,13 @@ static void pm_genpd_complete(struct device *dev)
 	if (IS_ERR(genpd))
 		return;
 
-	mutex_lock(&genpd->lock);
+	genpd_lock(genpd);
 
 	run_complete = !genpd->suspend_power_off;
 	if (--genpd->prepared_count == 0)
 		genpd->suspend_power_off = false;
 
-	mutex_unlock(&genpd->lock);
+	genpd_unlock(genpd);
 
 	if (run_complete) {
 		pm_generic_complete(dev);
@@ -1260,7 +1300,7 @@ int __pm_genpd_add_device(struct generic_pm_domain *genpd, struct device *dev,
 	if (IS_ERR(gpd_data))
 		return PTR_ERR(gpd_data);
 
-	mutex_lock(&genpd->lock);
+	genpd_lock(genpd);
 
 	if (genpd->prepared_count > 0) {
 		ret = -EAGAIN;
@@ -1277,7 +1317,7 @@ int __pm_genpd_add_device(struct generic_pm_domain *genpd, struct device *dev,
 	list_add_tail(&gpd_data->base.list_node, &genpd->dev_list);
 
  out:
-	mutex_unlock(&genpd->lock);
+	genpd_unlock(genpd);
 
 	if (ret)
 		genpd_free_dev_data(dev, gpd_data);
@@ -1310,7 +1350,7 @@ int pm_genpd_remove_device(struct generic_pm_domain *genpd,
 	gpd_data = to_gpd_data(pdd);
 	dev_pm_qos_remove_notifier(dev, &gpd_data->nb);
 
-	mutex_lock(&genpd->lock);
+	genpd_lock(genpd);
 
 	if (genpd->prepared_count > 0) {
 		ret = -EAGAIN;
@@ -1325,14 +1365,14 @@ int pm_genpd_remove_device(struct generic_pm_domain *genpd,
 
 	list_del_init(&pdd->list_node);
 
-	mutex_unlock(&genpd->lock);
+	genpd_unlock(genpd);
 
 	genpd_free_dev_data(dev, gpd_data);
 
 	return 0;
 
  out:
-	mutex_unlock(&genpd->lock);
+	genpd_unlock(genpd);
 	dev_pm_qos_add_notifier(dev, &gpd_data->nb);
 
 	return ret;
@@ -1358,8 +1398,8 @@ int pm_genpd_add_subdomain(struct generic_pm_domain *genpd,
 	if (!link)
 		return -ENOMEM;
 
-	mutex_lock(&subdomain->lock);
-	mutex_lock_nested(&genpd->lock, SINGLE_DEPTH_NESTING);
+	genpd_lock(subdomain);
+	genpd_lock_nested(genpd, SINGLE_DEPTH_NESTING);
 
 	if (genpd->status == GPD_STATE_POWER_OFF
 	    &&  subdomain->status != GPD_STATE_POWER_OFF) {
@@ -1382,8 +1422,8 @@ int pm_genpd_add_subdomain(struct generic_pm_domain *genpd,
 		genpd_sd_counter_inc(genpd);
 
  out:
-	mutex_unlock(&genpd->lock);
-	mutex_unlock(&subdomain->lock);
+	genpd_unlock(genpd);
+	genpd_unlock(subdomain);
 	if (ret)
 		kfree(link);
 	return ret;
@@ -1404,8 +1444,8 @@ int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
 	if (IS_ERR_OR_NULL(genpd) || IS_ERR_OR_NULL(subdomain))
 		return -EINVAL;
 
-	mutex_lock(&subdomain->lock);
-	mutex_lock_nested(&genpd->lock, SINGLE_DEPTH_NESTING);
+	genpd_lock(subdomain);
+	genpd_lock_nested(genpd, SINGLE_DEPTH_NESTING);
 
 	if (!list_empty(&subdomain->slave_links) || subdomain->device_count) {
 		pr_warn("%s: unable to remove subdomain %s\n", genpd->name,
@@ -1429,8 +1469,8 @@ int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
 	}
 
 out:
-	mutex_unlock(&genpd->lock);
-	mutex_unlock(&subdomain->lock);
+	genpd_unlock(genpd);
+	genpd_unlock(subdomain);
 
 	return ret;
 }
@@ -1595,7 +1635,8 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
 	INIT_LIST_HEAD(&genpd->master_links);
 	INIT_LIST_HEAD(&genpd->slave_links);
 	INIT_LIST_HEAD(&genpd->dev_list);
-	mutex_init(&genpd->lock);
+	mutex_init(&genpd->mlock);
+	genpd->lock_fns = &irq_lock;
 	genpd->gov = gov;
 	INIT_WORK(&genpd->power_off_work, genpd_power_off_work_fn);
 	atomic_set(&genpd->sd_count, 0);
@@ -1952,9 +1993,9 @@ int genpd_dev_pm_attach(struct device *dev)
 	dev->pm_domain->detach = genpd_dev_pm_detach;
 	dev->pm_domain->sync = genpd_dev_pm_sync;
 
-	mutex_lock(&pd->lock);
+	genpd_lock(pd);
 	ret = genpd_poweron(pd, 0);
-	mutex_unlock(&pd->lock);
+	genpd_unlock(pd);
 out:
 	return ret ? -EPROBE_DEFER : 0;
 }
@@ -2011,7 +2052,7 @@ static int pm_genpd_summary_one(struct seq_file *s,
 	struct gpd_link *link;
 	int ret;
 
-	ret = mutex_lock_interruptible(&genpd->lock);
+	ret = genpd_lock_interruptible(genpd);
 	if (ret)
 		return -ERESTARTSYS;
 
@@ -2047,7 +2088,7 @@ static int pm_genpd_summary_one(struct seq_file *s,
 
 	seq_puts(s, "\n");
 exit:
-	mutex_unlock(&genpd->lock);
+	genpd_unlock(genpd);
 
 	return 0;
 }
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 376d7fa..ec5523c 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -44,13 +44,14 @@ struct genpd_power_state {
 	u32 param;
 };
 
+struct genpd_lock_fns;
+
 struct generic_pm_domain {
 	struct dev_pm_domain domain;	/* PM domain operations */
 	struct list_head gpd_list_node;	/* Node in the global PM domains list */
 	struct list_head master_links;	/* Links with PM domain as a master */
 	struct list_head slave_links;	/* Links with PM domain as a slave */
 	struct list_head dev_list;	/* List of devices */
-	struct mutex lock;
 	struct dev_power_governor *gov;
 	struct work_struct power_off_work;
 	const char *name;
@@ -74,6 +75,8 @@ struct generic_pm_domain {
 	struct genpd_power_state *states;
 	unsigned int state_count; /* number of states */
 	unsigned int state_idx; /* state that genpd will go to when off */
+	struct genpd_lock_fns *lock_fns;
+	struct mutex mlock;
 
 };
 
-- 
2.1.4



From lina.iyer at linaro.org  Fri Feb 12 12:50:29 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Fri, 12 Feb 2016 13:50:29 -0700
Subject: [RFC v2 03/12] PM / cpu_domains: Setup PM domains for CPUs/clusters
In-Reply-To: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
References: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
Message-ID: <1455310238-8963-4-git-send-email-lina.iyer@linaro.org>

Define and add Generic PM domains (genpd) for CPU clusters. Many new
SoCs group CPUs as clusters. Clusters share common resources like power
rails, caches, VFP, Coresight etc. When all CPUs in the cluster are
idle, these shared resources may also be put in their idle state.

CPUs may be associated with their domain providers in DT. The domains in
turn may be associated with their providers. This is clean way to model
the cluster hierarchy like that of ARM's big.little architecture.

For each CPU in the DT, we identify the domain provider; initialize and
register the PM domain if isn't already registered and attach all the
CPU devices to the domain. Usually, when there are multiple clusters of
CPUs, there is a top level coherency domain that is dependent on these
individual domains. All domains thus created are marked IRQ safe
automatically and therefore may be powered down when the CPUs in the
domain are powered down by cpuidle.

Reading DT, initializing Generic PM domains, attaching CPUs to it
domains are common functionalities across ARM SoCs. Provide a common set
of APIs to setup PM domains for CPU clusters and its parents. The
platform drivers may just call of_setup_cpu_pd() to do a single step
setup of CPU domains.

Cc: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Suggested-by: Kevin Hilman <khilman at linaro.org>
Signed-off-by: Lina Iyer <lina.iyer at linaro.org>
---
Changes since RFC v1 -
- Initialize down up, start with CPUs, identify and create domains
- Clean up of the API
- Two simple API for setting up CPU PM domains
- File name change: cpu-pd.[ch] ->cpu_domains.[ch]
- Depends on CONFIG_PM_GENERIC_DOMAINS_OF only
- cpu_pd_ops abstracts generic pm domains
- platform code does not know about genpd object used inside
- simplification and bug fixes

 drivers/base/power/Makefile      |   1 +
 drivers/base/power/cpu_domains.c | 267 +++++++++++++++++++++++++++++++++++++++
 include/linux/cpu_domains.h      |  33 +++++
 3 files changed, 301 insertions(+)
 create mode 100644 drivers/base/power/cpu_domains.c
 create mode 100644 include/linux/cpu_domains.h

diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile
index 5998c53..9883e89 100644
--- a/drivers/base/power/Makefile
+++ b/drivers/base/power/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PM_SLEEP)	+= main.o wakeup.o
 obj-$(CONFIG_PM_TRACE_RTC)	+= trace.o
 obj-$(CONFIG_PM_OPP)	+= opp/
 obj-$(CONFIG_PM_GENERIC_DOMAINS)	+=  domain.o domain_governor.o
+obj-$(CONFIG_PM_GENERIC_DOMAINS_OF)	+= cpu_domains.o
 obj-$(CONFIG_HAVE_CLK)	+= clock_ops.o
 
 ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
diff --git a/drivers/base/power/cpu_domains.c b/drivers/base/power/cpu_domains.c
new file mode 100644
index 0000000..981592f
--- /dev/null
+++ b/drivers/base/power/cpu_domains.c
@@ -0,0 +1,267 @@
+/*
+ * drivers/base/power/cpu_domains.c - Helper functions to create CPU PM domains.
+ *
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/cpu.h>
+#include <linux/cpu_domains.h>
+#include <linux/cpu_pm.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/of.h>
+#include <linux/pm_domain.h>
+#include <linux/rculist.h>
+#include <linux/rcupdate.h>
+#include <linux/slab.h>
+
+#define CPU_PD_NAME_MAX 36
+
+struct cpu_pm_domain {
+	struct list_head link;
+	struct cpu_pd_ops ops;
+	struct generic_pm_domain *genpd;
+	struct cpu_pm_domain *parent;
+};
+
+/* List of CPU PM domains we care about */
+static LIST_HEAD(of_cpu_pd_list);
+static DEFINE_SPINLOCK(cpu_pd_list_lock);
+
+static inline
+struct cpu_pm_domain *to_cpu_pd(struct generic_pm_domain *d)
+{
+	struct cpu_pm_domain *pd;
+	struct cpu_pm_domain *res = NULL;
+
+	rcu_read_lock();
+	list_for_each_entry_rcu(pd, &of_cpu_pd_list, link)
+		if (pd->genpd == d) {
+			res = pd;
+			break;
+		}
+	rcu_read_unlock();
+
+	return res;
+}
+
+static int cpu_pd_attach_cpu(int cpu)
+{
+	int ret;
+	struct device *cpu_dev;
+
+	cpu_dev = get_cpu_device(cpu);
+	if (!cpu_dev) {
+		pr_warn("%s: Unable to get device for CPU%d\n",
+				__func__, cpu);
+		return -ENODEV;
+	}
+
+	ret = genpd_dev_pm_attach(cpu_dev);
+	if (ret)
+		dev_warn(cpu_dev,
+			"%s: Unable to attach to power-domain: %d\n",
+			__func__, ret);
+	else
+		dev_dbg(cpu_dev, "Attached to domain\n");
+
+	return ret;
+}
+
+static int cpu_pd_power_on(struct generic_pm_domain *genpd)
+{
+	struct cpu_pm_domain *pd = to_cpu_pd(genpd);
+
+	return pd->ops.power_on();
+}
+
+static int cpu_pd_power_off(struct generic_pm_domain *genpd)
+{
+	struct cpu_pm_domain *pd = to_cpu_pd(genpd);
+
+	return pd->ops.power_off(genpd->state_idx,
+			genpd->states[genpd->state_idx].param);
+}
+
+/**
+ * of_init_cpu_pm_domain() - Initialize a CPU PM domain from a device node
+ *
+ * @dn: The domain provider's device node
+ * @ops: The power_on/_off callbacks for the domain
+ *
+ * Returns the generic_pm_domain (genpd) pointer to the domain on success
+ */
+static struct generic_pm_domain *of_init_cpu_pm_domain(struct device_node *dn,
+				const struct cpu_pd_ops *ops)
+{
+	struct cpu_pm_domain *pd = NULL;
+	struct generic_pm_domain *genpd = NULL;
+	int ret = -ENOMEM;
+
+	if (!of_device_is_available(dn))
+		return ERR_PTR(-ENODEV);
+
+	genpd = kzalloc(sizeof(*(genpd)), GFP_KERNEL);
+	if (!genpd)
+		goto fail;
+
+	genpd->name = kstrndup(dn->full_name, CPU_PD_NAME_MAX, GFP_KERNEL);
+	if (!genpd->name)
+		goto fail;
+
+	pd = kzalloc(sizeof(*pd), GFP_KERNEL);
+	if (!pd)
+		goto fail;
+
+	pd->genpd = genpd;
+	pd->genpd->power_off = cpu_pd_power_off;
+	pd->genpd->power_on = cpu_pd_power_on;
+	pd->genpd->flags |= GENPD_FLAG_IRQ_SAFE;
+	pd->ops.power_on = ops->power_on;
+	pd->ops.power_off = ops->power_off;
+
+	INIT_LIST_HEAD_RCU(&pd->link);
+	spin_lock(&cpu_pd_list_lock);
+	list_add_rcu(&pd->link, &of_cpu_pd_list);
+	spin_unlock(&cpu_pd_list_lock);
+
+	/* Register the CPU genpd */
+	pr_debug("adding %s as CPU PM domain.\n", pd->genpd->name);
+	ret = of_pm_genpd_init(dn, pd->genpd, &simple_qos_governor, false);
+	if (ret) {
+		pr_err("Unable to initialize domain %s\n", dn->full_name);
+		goto fail;
+	}
+
+	ret = of_genpd_add_provider_simple(dn, pd->genpd);
+	if (ret)
+		pr_warn("Unable to add genpd %s as provider\n",
+				pd->genpd->name);
+
+	return pd->genpd;
+fail:
+
+	kfree(genpd);
+	kfree(genpd->name);
+	kfree(pd);
+	return ERR_PTR(ret);
+}
+
+static struct generic_pm_domain *of_get_cpu_domain(struct device_node *dn,
+		const struct cpu_pd_ops *ops, int cpu)
+{
+	struct of_phandle_args args;
+	struct generic_pm_domain *genpd, *parent;
+	int ret;
+
+	/* Do we have this domain? If not, create the domain */
+	args.np = dn;
+	args.args_count = 0;
+
+	genpd = of_genpd_get_from_provider(&args);
+	if (!IS_ERR(genpd))
+		goto skip_parent;
+
+	genpd = of_init_cpu_pm_domain(dn, ops);
+	if (IS_ERR(genpd))
+		return genpd;
+
+	/* Is there a domain provider for this domain? */
+	ret = of_parse_phandle_with_args(dn, "power-domains",
+			"#power-domain-cells", 0, &args);
+	of_node_put(dn);
+	if (ret < 0)
+		goto skip_parent;
+
+	/* Find its parent and attach this domain to it, recursively */
+	parent = of_get_cpu_domain(args.np, ops, cpu);
+	if (IS_ERR(parent)) {
+		struct cpu_pm_domain *cpu_pd, *parent_cpu_pd;
+
+		ret = pm_genpd_add_subdomain(genpd, parent);
+		if (ret) {
+			pr_err("%s: Unable to add sub-domain (%s) to parent (%s)\n err: %d",
+					__func__, genpd->name, parent->name,
+					ret);
+			return ERR_PTR(ret);
+		}
+
+		/*
+		 * Reference parent domain for easy access.
+		 * Note: We could be attached to a domain that is not a
+		 * CPU PM domain in that case dont reference the parent.
+		 */
+		cpu_pd = to_cpu_pd(genpd);
+		parent_cpu_pd = to_cpu_pd(parent);
+
+		if (cpu_pd && parent_cpu_pd)
+			cpu_pd->parent = parent_cpu_pd;
+	}
+
+skip_parent:
+	return genpd;
+}
+
+/**
+ * of_setup_cpu_pd_single() - Setup the PM domains for a CPU
+ *
+ * @cpu: The CPU for which the PM domain is to be set up.
+ * @ops: The PM domain suspend/resume ops for the CPU's domain
+ *
+ * If the CPU PM domain exists already, then the CPU is attached to
+ * that CPU PD. If it doesn't, the domain is created, the @ops are
+ * set for power_on/power_off callbacks and then the CPU is attached
+ * to that domain. If the domain was created outside this framework,
+ * then we do not attach the CPU to the domain.
+ */
+int of_setup_cpu_pd_single(int cpu, const struct cpu_pd_ops *ops)
+{
+
+	struct device_node *dn;
+	struct generic_pm_domain *genpd;
+
+	dn = of_get_cpu_node(cpu, NULL);
+	if (!dn)
+		return -ENODEV;
+
+	dn = of_parse_phandle(dn, "power-domains", 0);
+	if (!dn)
+		return -ENODEV;
+	of_node_put(dn);
+
+	/* Find the genpd for this CPU, create if not found */
+	genpd = of_get_cpu_domain(dn, ops, cpu);
+	if (IS_ERR(genpd))
+		return PTR_ERR(genpd);
+
+	return cpu_pd_attach_cpu(cpu);
+}
+EXPORT_SYMBOL(of_setup_cpu_pd_single);
+
+/**
+ * of_setup_cpu_pd() - Setup the PM domains for all CPUs
+ *
+ * @ops: The PM domain suspend/resume ops for all the domains
+ *
+ * Setup the CPU PM domain and attach all possible CPUs to their respective
+ * domains. The domains are created if not already and then attached.
+ */
+int of_setup_cpu_pd(const struct cpu_pd_ops *ops)
+{
+	int cpu;
+	int ret;
+
+	for_each_possible_cpu(cpu) {
+		ret = of_setup_cpu_pd_single(cpu, ops);
+		if (ret)
+			break;
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL(of_setup_cpu_pd);
diff --git a/include/linux/cpu_domains.h b/include/linux/cpu_domains.h
new file mode 100644
index 0000000..bab4846
--- /dev/null
+++ b/include/linux/cpu_domains.h
@@ -0,0 +1,33 @@
+/*
+ * include/linux/cpu_domains.h
+ *
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __CPU_DOMAINS_H__
+#define __CPU_DOMAINS_H__
+
+struct cpu_pd_ops {
+	int (*power_off)(u32 state_idx, u32 param);
+	int (*power_on)(void);
+};
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
+int of_setup_cpu_pd_single(int cpu, const struct cpu_pd_ops *ops);
+int of_setup_cpu_pd(const struct cpu_pd_ops *ops);
+#else
+static inline int of_setup_cpu_pd_single(int cpu, const struct cpu_pd_ops *ops)
+{
+	return -ENODEV;
+}
+static inline int of_setup_cpu_pd(const struct cpu_pd_ops *ops)
+{
+	return -ENODEV;
+}
+#endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
+
+#endif /* __CPU_DOMAINS_H__ */
-- 
2.1.4



From lina.iyer at linaro.org  Fri Feb 12 12:50:28 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Fri, 12 Feb 2016 13:50:28 -0700
Subject: [RFC v2 02/12] PM / Domains: Support IRQ safe PM domains
In-Reply-To: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
References: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
Message-ID: <1455310238-8963-3-git-send-email-lina.iyer@linaro.org>

Generic Power Domains currently support turning on/off only in process
context. This prevents the usage of PM domains for domains that could be
powered on/off in a context where IRQs are disabled. Many such domains
exist today and do not get powered off, when the IRQ safe devices in
that domain are powered off, because of this limitation.

However, not all domains can operate in IRQ safe contexts. Genpd
therefore, has to support both cases where the domain may or may not
operate in IRQ safe contexts. Configuring genpd to use an appropriate
lock for that domain, would allow domains that have IRQ safe devices to
runtime suspend and resume, in atomic context.

To achieve domain specific locking, set the domain's ->flag to
GENPD_FLAG_IRQ_SAFE while defining the domain. This indicates that genpd
should use a spinlock instead of a mutex for locking the domain. Locking
is abstracted through genpd_lock() and genpd_unlock() functions that use
the flag to determine the appropriate lock to be used for that domain.

Domains that have lower latency to suspend and resume and can operate
with IRQs disabled may now be able to save power, when the component
devices and sub-domains are idle at runtime.

The restriction this imposes on the domain hierarchy is that non-IRQ
safe domains may not have IRQ-safe subdomains, but IRQ safe domains may
have IRQ safe and non-IRQ safe domains and devices.

Cc: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Kevin Hilman <khilman at linaro.org>
Cc: Rafael J. Wysocki <rjw at rjwysocki.net>
Cc: Geert Uytterhoeven <geert at linux-m68k.org>
Cc: Krzysztof Koz?owski <k.kozlowski at samsung.com>
Signed-off-by: Lina Iyer <lina.iyer at linaro.org>
---
Changes since RFC v1 -
- split off to into its own patch
- Removed restriction that IRQ-safe domains can only have IRQ safe parents

 Documentation/power/devices.txt |  11 +++-
 drivers/base/power/domain.c     | 112 ++++++++++++++++++++++++++++++++++++----
 include/linux/pm_domain.h       |  11 +++-
 3 files changed, 123 insertions(+), 11 deletions(-)

diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 8ba6625..c06f0b6 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -607,7 +607,16 @@ individually.  Instead, a set of devices sharing a power resource can be put
 into a low-power state together at the same time by turning off the shared
 power resource.  Of course, they also need to be put into the full-power state
 together, by turning the shared power resource on.  A set of devices with this
-property is often referred to as a power domain.
+property is often referred to as a power domain. A power domain may also be
+nested inside another power domain.
+
+Devices, by default, operate in process context and if a device can operate in
+IRQ safe context, has to be explicitly set as IRQ safe. Power domains by
+default, operate in process context but could have devices that are IRQ safe.
+Such power domains cannot be powered on/off during runtime PM. On the other
+hand, an IRQ safe PM domains that have IRQ safe devices may be powered off
+when all the devices are in idle. An IRQ safe domain may only be attached as a
+subdomain to another IRQ safe domain.
 
 Support for power domains is provided through the pm_domain field of struct
 device.  This field is a pointer to an object of type struct dev_pm_domain,
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 8204615..3c4f675 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -75,11 +75,59 @@ static struct genpd_lock_fns irq_lock = {
 	.unlock = genpd_unlock_irq,
 };
 
+static void genpd_lock_nosleep(struct generic_pm_domain *genpd)
+	__acquires(&genpd->slock)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&genpd->slock, flags);
+	genpd->lock_flags = flags;
+}
+
+static void genpd_lock_nosleep_nested(struct generic_pm_domain *genpd,
+					int depth)
+	__acquires(&genpd->slock)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave_nested(&genpd->slock, flags, depth);
+	genpd->lock_flags = flags;
+}
+
+static int genpd_lock_nosleep_interruptible(struct generic_pm_domain *genpd)
+	__acquires(&genpd->slock)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&genpd->slock, flags);
+	genpd->lock_flags = flags;
+	return 0;
+}
+
+static void genpd_unlock_nosleep(struct generic_pm_domain *genpd)
+	__releases(&genpd->slock)
+{
+	spin_unlock_irqrestore(&genpd->slock, genpd->lock_flags);
+}
+
+static struct genpd_lock_fns no_sleep_lock = {
+	.lock = genpd_lock_nosleep,
+	.lock_nested = genpd_lock_nosleep_nested,
+	.lock_interruptible = genpd_lock_nosleep_interruptible,
+	.unlock = genpd_unlock_nosleep,
+};
+
 #define genpd_lock(p)			p->lock_fns->lock(p)
 #define genpd_lock_nested(p, d)		p->lock_fns->lock_nested(p, d)
 #define genpd_lock_interruptible(p)	p->lock_fns->lock_interruptible(p)
 #define genpd_unlock(p)			p->lock_fns->unlock(p)
 
+static inline bool irq_safe_dev_in_no_sleep_domain(struct device *dev,
+		struct generic_pm_domain *genpd)
+{
+	return dev->power.irq_safe && !genpd->irq_safe;
+}
+
 /*
  * Get the generic PM domain for a particular struct device.
  * This validates the struct device pointer, the PM domain pointer,
@@ -356,8 +404,17 @@ static int genpd_poweroff(struct generic_pm_domain *genpd, bool is_async)
 		if (stat > PM_QOS_FLAGS_NONE)
 			return -EBUSY;
 
-		if (!pm_runtime_suspended(pdd->dev) || pdd->dev->power.irq_safe)
+		/*
+		 * We do not want to power off the domain if the device is
+		 * not suspended or an IRQ safe device is part of this
+		 * non-IRQ safe domain.
+		 */
+		if (!pm_runtime_suspended(pdd->dev) ||
+			irq_safe_dev_in_no_sleep_domain(pdd->dev, genpd))
 			not_suspended++;
+		WARN_ONCE(irq_safe_dev_in_no_sleep_domain(pdd->dev, genpd),
+				"PM domain %s will not be powered off\n",
+				genpd->name);
 	}
 
 	if (not_suspended > 1 || (not_suspended == 1 && is_async))
@@ -473,10 +530,13 @@ static int pm_genpd_runtime_suspend(struct device *dev)
 	}
 
 	/*
-	 * If power.irq_safe is set, this routine will be run with interrupts
-	 * off, so it can't use mutexes.
+	 * If power.irq_safe is set, this routine may be run with
+	 * IRQ disabled, so suspend only if the power domain is
+	 * irq_safe.
 	 */
-	if (dev->power.irq_safe)
+	WARN_ONCE(irq_safe_dev_in_no_sleep_domain(dev, genpd),
+			"genpd %s will not be powered off\n", genpd->name);
+	if (irq_safe_dev_in_no_sleep_domain(dev, genpd))
 		return 0;
 
 	genpd_lock(genpd);
@@ -510,8 +570,11 @@ static int pm_genpd_runtime_resume(struct device *dev)
 	if (IS_ERR(genpd))
 		return -EINVAL;
 
-	/* If power.irq_safe, the PM domain is never powered off. */
-	if (dev->power.irq_safe) {
+	/*
+	 * As we dont power off a non IRQ safe domain, which holds
+	 * an IRQ safe device, we dont need to restore power to it.
+	 */
+	if (dev->power.irq_safe && !genpd->irq_safe) {
 		timed = false;
 		goto out;
 	}
@@ -1296,6 +1359,13 @@ int __pm_genpd_add_device(struct generic_pm_domain *genpd, struct device *dev,
 	if (IS_ERR_OR_NULL(genpd) || IS_ERR_OR_NULL(dev))
 		return -EINVAL;
 
+	if (genpd->irq_safe && !dev->power.irq_safe) {
+		dev_err(dev,
+			"PM Domain %s is IRQ safe; device has to IRQ safe.\n",
+			genpd->name);
+		return -EINVAL;
+	}
+
 	gpd_data = genpd_alloc_dev_data(dev, genpd, td);
 	if (IS_ERR(gpd_data))
 		return PTR_ERR(gpd_data);
@@ -1394,6 +1464,17 @@ int pm_genpd_add_subdomain(struct generic_pm_domain *genpd,
 	    || genpd == subdomain)
 		return -EINVAL;
 
+	/*
+	 * If the domain can be powered on/off in an IRQ safe
+	 * context, ensure that the subdomain can also be
+	 * powered on/off in that context.
+	 */
+	if (!genpd->irq_safe && subdomain->irq_safe) {
+		WARN("Parent %s of subdomain %s must be IRQ-safe\n",
+				genpd->name, subdomain->name);
+		return -EINVAL;
+	}
+
 	link = kzalloc(sizeof(*link), GFP_KERNEL);
 	if (!link)
 		return -ENOMEM;
@@ -1610,6 +1691,19 @@ static int of_genpd_device_parse_states(struct device_node *np,
 	return 0;
 }
 
+static void genpd_lock_init(struct generic_pm_domain *genpd)
+{
+	if (genpd->flags & GENPD_FLAG_IRQ_SAFE) {
+		spin_lock_init(&genpd->slock);
+		genpd->irq_safe = true;
+		genpd->lock_fns = &no_sleep_lock;
+	} else {
+		mutex_init(&genpd->mlock);
+		genpd->irq_safe = false;
+		genpd->lock_fns = &irq_lock;
+	}
+}
+
 /**
  * pm_genpd_init - Initialize a generic I/O PM domain object.
  * @genpd: PM domain object to initialize.
@@ -1635,8 +1729,7 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
 	INIT_LIST_HEAD(&genpd->master_links);
 	INIT_LIST_HEAD(&genpd->slave_links);
 	INIT_LIST_HEAD(&genpd->dev_list);
-	mutex_init(&genpd->mlock);
-	genpd->lock_fns = &irq_lock;
+	genpd_lock_init(genpd);
 	genpd->gov = gov;
 	INIT_WORK(&genpd->power_off_work, genpd_power_off_work_fn);
 	atomic_set(&genpd->sd_count, 0);
@@ -2077,7 +2170,8 @@ static int pm_genpd_summary_one(struct seq_file *s,
 	}
 
 	list_for_each_entry(pm_data, &genpd->dev_list, list_node) {
-		kobj_path = kobject_get_path(&pm_data->dev->kobj, GFP_KERNEL);
+		kobj_path = kobject_get_path(&pm_data->dev->kobj,
+				genpd->irq_safe ? GFP_ATOMIC : GFP_KERNEL);
 		if (kobj_path == NULL)
 			continue;
 
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index ec5523c..3f245d5 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -15,9 +15,11 @@
 #include <linux/err.h>
 #include <linux/of.h>
 #include <linux/notifier.h>
+#include <linux/spinlock.h>
 
 /* Defines used for the flags field in the struct generic_pm_domain */
 #define GENPD_FLAG_PM_CLK	(1U << 0) /* PM domain uses PM clk */
+#define GENPD_FLAG_IRQ_SAFE	(1U << 1) /* PM domain operates in atomic */
 
 enum gpd_status {
 	GPD_STATE_ACTIVE = 0,	/* PM domain is active */
@@ -76,7 +78,14 @@ struct generic_pm_domain {
 	unsigned int state_count; /* number of states */
 	unsigned int state_idx; /* state that genpd will go to when off */
 	struct genpd_lock_fns *lock_fns;
-	struct mutex mlock;
+	bool irq_safe;
+	union {
+		struct mutex mlock;
+		struct {
+			spinlock_t slock;
+			unsigned long lock_flags;
+		};
+	};
 
 };
 
-- 
2.1.4



From lina.iyer at linaro.org  Fri Feb 12 12:50:31 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Fri, 12 Feb 2016 13:50:31 -0700
Subject: [RFC v2 05/12] timer: Export next wake up of a CPU
In-Reply-To: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
References: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
Message-ID: <1455310238-8963-6-git-send-email-lina.iyer@linaro.org>

Knowing the sleep length of the CPU is useful for the power state
determination on idle. However, when the common sleep time between
multiple CPUs is needed, the sleep length of a CPU is not useful.

By reading the next wake up event of a CPU, governors can determine the
first CPU to wake up (due to timer) amongst a cluster of CPUs and the
sleep time available between the last CPU to idle and the first CPU to
resume. This information is useful to determine if the caches and other
common hardware blocks can also be put in idle during this common period
of inactivity.

Cc: Thomas Gleixner <tglx at linutronix.de>
Signed-off-by: Lina Iyer <lina.iyer at linaro.org>
---
Changes since RFC v1 -
- any CPU can access this variable if that CPU has IRQs disabled

 include/linux/tick.h     | 10 ++++++++++
 kernel/time/tick-sched.c | 13 +++++++++++++
 2 files changed, 23 insertions(+)

diff --git a/include/linux/tick.h b/include/linux/tick.h
index 97fd4e5..b8a2e06 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -104,6 +104,7 @@ extern void tick_nohz_idle_enter(void);
 extern void tick_nohz_idle_exit(void);
 extern void tick_nohz_irq_exit(void);
 extern ktime_t tick_nohz_get_sleep_length(void);
+extern ktime_t tick_nohz_get_next_wakeup(int cpu);
 extern u64 get_cpu_idle_time_us(int cpu, u64 *last_update_time);
 extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time);
 #else /* !CONFIG_NO_HZ_COMMON */
@@ -118,6 +119,15 @@ static inline ktime_t tick_nohz_get_sleep_length(void)
 
 	return len;
 }
+
+static inline ktime_t tick_nohz_get_next_wakeup(int cpu)
+{
+	ktime_t len = { .tv64 = NSEC_PER_SEC/HZ };
+
+	/* Next wake up is the tick period, assume it starts now */
+	return ktime_add(len, ktime_get());
+}
+
 static inline u64 get_cpu_idle_time_us(int cpu, u64 *unused) { return -1; }
 static inline u64 get_cpu_iowait_time_us(int cpu, u64 *unused) { return -1; }
 #endif /* !CONFIG_NO_HZ_COMMON */
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 0b17424..f0ddaec 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -888,6 +888,19 @@ ktime_t tick_nohz_get_sleep_length(void)
 	return ts->sleep_length;
 }
 
+/**
+ * tick_nohz_get_next_wakeup - return the next wake up of the CPU
+ *
+ * Called with interrupts disabled on the cpu
+ */
+ktime_t tick_nohz_get_next_wakeup(int cpu)
+{
+	struct clock_event_device *dev =
+			per_cpu(tick_cpu_device.evtdev, cpu);
+
+	return dev->next_event;
+}
+
 static void tick_nohz_account_idle_ticks(struct tick_sched *ts)
 {
 #ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
-- 
2.1.4



From lina.iyer at linaro.org  Fri Feb 12 12:50:32 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Fri, 12 Feb 2016 13:50:32 -0700
Subject: [RFC v2 06/12] PM / cpu_domains: Record CPUs that are part of the
 domain
In-Reply-To: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
References: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
Message-ID: <1455310238-8963-7-git-send-email-lina.iyer@linaro.org>

In order to power down a CPU domain, the domain needs information about
the CPUs in that domain. The reference counting for the CPU devices in a
domain is done by genpd. In order to understand the idle time for the
domain, it is necessary to know which CPUs are part of the domain, so
the domain governor may understand the sleep durations of the comprising
CPU devices and make a judicious decision on the domain's idle state.
This extends to the parent of such domains, which may have multiple such
CPU domains and therefore would need to know the sleep patterns of all
the CPUs in all the CPU domains.

To aid this functionality, traverse up the parent chain and set the CPU
in the cpumasks while attaching a CPU to its domain. This mask is
provided in the callback to the platform driver to help identify the
CPUs in the domain that is being powered off.

Signed-off-by: Lina Iyer <lina.iyer at linaro.org>
---
 drivers/base/power/cpu_domains.c | 27 ++++++++++++++++++++++++---
 include/linux/cpu_domains.h      |  4 +++-
 2 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/base/power/cpu_domains.c b/drivers/base/power/cpu_domains.c
index 981592f..c99710c 100644
--- a/drivers/base/power/cpu_domains.c
+++ b/drivers/base/power/cpu_domains.c
@@ -9,6 +9,7 @@
  */
 
 #include <linux/cpu.h>
+#include <linux/cpumask.h>
 #include <linux/cpu_domains.h>
 #include <linux/cpu_pm.h>
 #include <linux/device.h>
@@ -27,6 +28,7 @@ struct cpu_pm_domain {
 	struct cpu_pd_ops ops;
 	struct generic_pm_domain *genpd;
 	struct cpu_pm_domain *parent;
+	cpumask_var_t cpus;
 };
 
 /* List of CPU PM domains we care about */
@@ -50,7 +52,7 @@ struct cpu_pm_domain *to_cpu_pd(struct generic_pm_domain *d)
 	return res;
 }
 
-static int cpu_pd_attach_cpu(int cpu)
+static int cpu_pd_attach_cpu(struct cpu_pm_domain *cpu_pd, int cpu)
 {
 	int ret;
 	struct device *cpu_dev;
@@ -70,6 +72,11 @@ static int cpu_pd_attach_cpu(int cpu)
 	else
 		dev_dbg(cpu_dev, "Attached to domain\n");
 
+	while (!ret && cpu_pd) {
+		cpumask_set_cpu(cpu, cpu_pd->cpus);
+		cpu_pd = cpu_pd->parent;
+	};
+
 	return ret;
 }
 
@@ -85,7 +92,8 @@ static int cpu_pd_power_off(struct generic_pm_domain *genpd)
 	struct cpu_pm_domain *pd = to_cpu_pd(genpd);
 
 	return pd->ops.power_off(genpd->state_idx,
-			genpd->states[genpd->state_idx].param);
+			genpd->states[genpd->state_idx].param,
+			pd->cpus);
 }
 
 /**
@@ -118,6 +126,9 @@ static struct generic_pm_domain *of_init_cpu_pm_domain(struct device_node *dn,
 	if (!pd)
 		goto fail;
 
+	if (!zalloc_cpumask_var(&pd->cpus, GFP_KERNEL))
+		goto fail;
+
 	pd->genpd = genpd;
 	pd->genpd->power_off = cpu_pd_power_off;
 	pd->genpd->power_on = cpu_pd_power_on;
@@ -148,6 +159,8 @@ fail:
 
 	kfree(genpd);
 	kfree(genpd->name);
+	if (pd)
+		kfree(pd->cpus);
 	kfree(pd);
 	return ERR_PTR(ret);
 }
@@ -224,6 +237,7 @@ int of_setup_cpu_pd_single(int cpu, const struct cpu_pd_ops *ops)
 
 	struct device_node *dn;
 	struct generic_pm_domain *genpd;
+	struct cpu_pm_domain *cpu_pd;
 
 	dn = of_get_cpu_node(cpu, NULL);
 	if (!dn)
@@ -239,7 +253,14 @@ int of_setup_cpu_pd_single(int cpu, const struct cpu_pd_ops *ops)
 	if (IS_ERR(genpd))
 		return PTR_ERR(genpd);
 
-	return cpu_pd_attach_cpu(cpu);
+	cpu_pd = to_cpu_pd(genpd);
+	if (!cpu_pd) {
+		pr_err("%s: Genpd was created outside CPU PM domains\n",
+				__func__);
+		return -ENOENT;
+	}
+
+	return cpu_pd_attach_cpu(cpu_pd, cpu);
 }
 EXPORT_SYMBOL(of_setup_cpu_pd_single);
 
diff --git a/include/linux/cpu_domains.h b/include/linux/cpu_domains.h
index bab4846..0c539f0 100644
--- a/include/linux/cpu_domains.h
+++ b/include/linux/cpu_domains.h
@@ -11,8 +11,10 @@
 #ifndef __CPU_DOMAINS_H__
 #define __CPU_DOMAINS_H__
 
+#include <linux/cpumask.h>
+
 struct cpu_pd_ops {
-	int (*power_off)(u32 state_idx, u32 param);
+	int (*power_off)(u32 state_idx, u32 param, const struct cpumask *mask);
 	int (*power_on)(void);
 };
 
-- 
2.1.4



From lina.iyer at linaro.org  Fri Feb 12 12:50:30 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Fri, 12 Feb 2016 13:50:30 -0700
Subject: [RFC v2 04/12] ARM: cpuidle: Add runtime PM support for CPUs
In-Reply-To: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
References: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
Message-ID: <1455310238-8963-5-git-send-email-lina.iyer@linaro.org>

Notify runtime PM when the CPU is going to be powered off in the idle
state. This allows for runtime PM suspend/resume of the CPU as well as
its PM domain.

We do not call into runtime PM for ARM WFI to keep the default state
simple and faster.

Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Lina Iyer <lina.iyer at linaro.org>
---
Changes since RFC v1 -
- runtime PM initialization is now done as part of this file
- hotplug and its runtime PM invocation is done here

 drivers/cpuidle/cpuidle-arm.c | 48 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c
index 545069d..bf7a80c 100644
--- a/drivers/cpuidle/cpuidle-arm.c
+++ b/drivers/cpuidle/cpuidle-arm.c
@@ -11,12 +11,14 @@
 
 #define pr_fmt(fmt) "CPUidle arm: " fmt
 
+#include <linux/cpu.h>
 #include <linux/cpuidle.h>
 #include <linux/cpumask.h>
 #include <linux/cpu_pm.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/of.h>
+#include <linux/pm_runtime.h>
 #include <linux/slab.h>
 
 #include <asm/cpuidle.h>
@@ -37,6 +39,7 @@ static int arm_enter_idle_state(struct cpuidle_device *dev,
 				struct cpuidle_driver *drv, int idx)
 {
 	int ret;
+	struct device *cpu_dev = get_cpu_device(dev->cpu);
 
 	if (!idx) {
 		cpu_do_idle();
@@ -45,6 +48,8 @@ static int arm_enter_idle_state(struct cpuidle_device *dev,
 
 	ret = cpu_pm_enter();
 	if (!ret) {
+		RCU_NONIDLE(pm_runtime_put_sync_suspend(cpu_dev));
+
 		/*
 		 * Pass idle state index to cpu_suspend which in turn will
 		 * call the CPU ops suspend protocol with idle index as a
@@ -52,6 +57,7 @@ static int arm_enter_idle_state(struct cpuidle_device *dev,
 		 */
 		arm_cpuidle_suspend(idx);
 
+		RCU_NONIDLE(pm_runtime_get_sync(cpu_dev));
 		cpu_pm_exit();
 	}
 
@@ -84,6 +90,30 @@ static const struct of_device_id arm_idle_state_match[] __initconst = {
 	{ },
 };
 
+#ifdef CONFIG_HOTPLUG_CPU
+static int cpu_hotplug(struct notifier_block *nb,
+			unsigned long action, void *data)
+{
+	struct device *cpu_dev = get_cpu_device(smp_processor_id());
+
+	/* Execute CPU runtime PM on that CPU */
+	switch (action) {
+	case CPU_DYING:
+	case CPU_DYING_FROZEN:
+		RCU_NONIDLE(pm_runtime_put_sync_suspend(cpu_dev));
+		break;
+	case CPU_STARTING:
+	case CPU_STARTING_FROZEN:
+		RCU_NONIDLE(pm_runtime_get_sync(cpu_dev));
+		break;
+	default:
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+#endif
+
 /*
  * arm_idle_init
  *
@@ -96,6 +126,7 @@ static int __init arm_idle_init(void)
 	int cpu, ret;
 	struct cpuidle_driver *drv = &arm_idle_driver;
 	struct cpuidle_device *dev;
+	struct device *cpu_dev;
 
 	/*
 	 * Initialize idle states data, starting at index 1.
@@ -118,6 +149,16 @@ static int __init arm_idle_init(void)
 	 * idle states suspend back-end specific data
 	 */
 	for_each_possible_cpu(cpu) {
+
+		/* Initialize Runtime PM for the CPU */
+		cpu_dev = get_cpu_device(cpu);
+		pm_runtime_irq_safe(cpu_dev);
+		pm_runtime_enable(cpu_dev);
+		if (cpu_online(cpu)) {
+			pm_runtime_get_noresume(cpu_dev);
+			pm_runtime_set_active(cpu_dev);
+		}
+
 		ret = arm_cpuidle_init(cpu);
 
 		/*
@@ -148,10 +189,17 @@ static int __init arm_idle_init(void)
 		}
 	}
 
+#ifdef CONFIG_HOTPLUG_CPU
+	/* Register for hotplug notifications for runtime PM */
+	hotcpu_notifier(cpu_hotplug, 0);
+#endif
+
 	return 0;
 out_fail:
 	while (--cpu >= 0) {
 		dev = per_cpu(cpuidle_devices, cpu);
+		cpu_dev = get_cpu_device(cpu);
+		__pm_runtime_disable(cpu_dev, false);
 		cpuidle_unregister_device(dev);
 		kfree(dev);
 	}
-- 
2.1.4



From lina.iyer at linaro.org  Fri Feb 12 12:50:34 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Fri, 12 Feb 2016 13:50:34 -0700
Subject: [RFC v2 08/12] Documentation / cpu_domains: Describe CPU PM domains
 setup and governor
In-Reply-To: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
References: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
Message-ID: <1455310238-8963-9-git-send-email-lina.iyer@linaro.org>

A generic CPU PM domain functionality is provided by
drivers/base/power/cpu_domains.c. This document describes the generic
usecase of CPU's PM domains, the setup of such domains and a CPU
specific genpd governor.

Signed-off-by: Lina Iyer <lina.iyer at linaro.org>
---
Changes since RFC v1 -
- a patch of its own 
- updated documentation

 Documentation/power/cpu_domains.txt | 79 +++++++++++++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 Documentation/power/cpu_domains.txt

diff --git a/Documentation/power/cpu_domains.txt b/Documentation/power/cpu_domains.txt
new file mode 100644
index 0000000..5fdc66d
--- /dev/null
+++ b/Documentation/power/cpu_domains.txt
@@ -0,0 +1,79 @@
+CPU PM domains
+==============
+
+Newer CPUs are grouped in SoCs as clusters. A cluster in addition to the CPUs
+may have caches, VFP and architecture specific power controller that share the
+resources when any of the CPUs are active. When the CPUs are in idle, some of
+these cluster components may also idle. A cluster may also be nested inside
+another cluster that provides common coherency interfaces to share data
+between the clusters. The organization of such clusters and CPU may be
+descibed in DT, since they are SoC specific.
+
+CPUIdle framework enables the CPUs to determine the sleep time and enter low
+power state to save power during periods of idle. CPUs in a cluster may enter
+and exit idle state independently of each other. During the time when all the
+CPUs are in idle state, the cluster may safely put some of the shared
+resources in their idle state. The time between the last CPU to enter idle and
+the first CPU to wake up is the time available for the cluster to enter its
+idle state.
+
+When SoCs power down the CPU during cpuidle, they generally have supplemental
+hardware that can handshake with the CPU with a signal that indicates that the
+CPU has stopped execution. The hardware is also responsible for warm booting
+the CPU on receiving an interrupt. With cluster architecture, common resources
+that are shared by the cluster may also be powered down by an external
+microcontroller or a processor. The microcontroller may be programmed in
+advance to put the hardware blocks in a low power state, when the last active
+CPU sends the idle signal. When the signal is received, the microcontroller
+may trigger the hardware blocks to enter their low power state. When an
+interrupt to wakeup the processor is received, the microcontroller is
+responsible for bringing up the hardware blocks to its active state, before
+waking up the CPU. The timelines for such operations should be in the
+acceptable range for the for CPU idle to get power benefits.
+
+CPU PM Domain Setup
+-------------------
+
+PM domains  are represented in the DT as domain consumers and providers. A
+device may have a domain provider and a domain provider may support multiple
+domain consumers. Domains like clusters, may also be nested inside one
+another. A domain that has no active consumer, may be powered off and any
+resuming consumer would trigger the domain back to active. Parent domains may
+be powered off when the child domains are powered off. The CPU cluster can be
+fashioned as a PM domain. When the CPU devices are powered off, the PM domain
+may be powered off.
+
+Device idle is reference counted by runtime PM. When there is no active need
+for the device, runtime PM invokes callbacks to suspend the parent domain.
+Generic PM domain (genpd) handles the hierarchy of devices, domains and the
+reference counting of objects leading to last man down and first man up in the
+domain. The CPU domains helper functions defines PM domains for each CPU
+cluster and attaches the CPU devices to the respective PM domains.
+
+Platform drivers may use the following API to register their CPU PM domains.
+
+of_setup_cpu_pd() -
+Provides a single step registration of the CPU PM domain and attach CPUs to
+the genpd. Platform drivers may additionally register callbacks for power_on
+and power_off operations for the PM domain.
+
+of_setup_cpu_pd_single() -
+Define PM domain for a single CPU and attach the CPU to its domain.
+
+
+CPU PM Domain governor
+----------------------
+
+CPUs have an unique ability to determine their next wakeup. CPUs may wake up
+for known timer interrupts and unknown interrupts from idle. Prediction
+algorithms and heuristic based algorithms like the Menu governor for cpuidle
+can determine the next wakeup of the CPU. However, determining the wakeup
+across a group of CPUs is a tough problem to solve.
+
+A simplistic approach would be to resort to known wakeups of the CPUs in
+determining the next wakeup of any CPU in the cluster. The CPU PM domain
+governor does just that. By looking into the tick device of the CPUs, the
+governor can determine the sleep time between the last CPU and the first
+scheduled wakeup of any CPU in that domain. This combined with the PM QoS
+requirement for CPU_DMA_LATENCY can be used to determine the deepest possible
+idle state of the CPU domain.
-- 
2.1.4



From lina.iyer at linaro.org  Fri Feb 12 12:50:33 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Fri, 12 Feb 2016 13:50:33 -0700
Subject: [RFC v2 07/12] PM / cpu_domains: Add PM Domain governor for CPUs
In-Reply-To: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
References: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
Message-ID: <1455310238-8963-8-git-send-email-lina.iyer@linaro.org>

A PM domain comprising of CPUs may be powered off when all the CPUs in
the domain are powered down. Powering down a CPU domain is generally a
expensive operation and therefore the power performance trade offs
should be considered. The time between the last CPU powering down and
the first CPU powering up in a domain, is the time available for the
domain to sleep. Ideally, the sleep time of the domain should fulfill
the residency requirement of the domains' idle state.

To do this effectively, read the time before the wakeup of the cluster's
CPUs and ensure that the domain's idle state sleep time guarantees the
QoS requirements of each of the CPU, the PM QoS CPU_DMA_LATENCY and the
state's residency.

Signed-off-by: Lina Iyer <lina.iyer at linaro.org>
---
Changes since RFC v1 -
- bug fix

 drivers/base/power/cpu_domains.c | 75 +++++++++++++++++++++++++++++++++++++++-
 1 file changed, 74 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/cpu_domains.c b/drivers/base/power/cpu_domains.c
index c99710c..7069411 100644
--- a/drivers/base/power/cpu_domains.c
+++ b/drivers/base/power/cpu_domains.c
@@ -17,9 +17,12 @@
 #include <linux/list.h>
 #include <linux/of.h>
 #include <linux/pm_domain.h>
+#include <linux/pm_qos.h>
+#include <linux/pm_runtime.h>
 #include <linux/rculist.h>
 #include <linux/rcupdate.h>
 #include <linux/slab.h>
+#include <linux/tick.h>
 
 #define CPU_PD_NAME_MAX 36
 
@@ -52,6 +55,76 @@ struct cpu_pm_domain *to_cpu_pd(struct generic_pm_domain *d)
 	return res;
 }
 
+static bool cpu_pd_down_ok(struct dev_pm_domain *pd)
+{
+	struct generic_pm_domain *genpd = pd_to_genpd(pd);
+	struct cpu_pm_domain *cpu_pd = to_cpu_pd(genpd);
+	int qos = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
+	u64 sleep_ns;
+	ktime_t earliest, next_wakeup;
+	int cpu;
+	int i;
+
+	/* Reset the last set genpd state, default to index 0 */
+	genpd->state_idx = 0;
+
+	/* We dont want to power down, if QoS is 0 */
+	if (!qos)
+		return false;
+
+	/*
+	 * Find the sleep time for the cluster.
+	 * The time between now and the first wake up of any CPU that
+	 * are in this domain hierarchy is the time available for the
+	 * domain to be idle.
+	 */
+	earliest = ktime_set(KTIME_SEC_MAX, 0);
+	for_each_cpu_and(cpu, cpu_pd->cpus, cpu_online_mask) {
+		next_wakeup = tick_nohz_get_next_wakeup(cpu);
+		if (earliest.tv64 > next_wakeup.tv64)
+			earliest = next_wakeup;
+	}
+
+	sleep_ns = ktime_to_ns(ktime_sub(earliest, ktime_get()));
+	if (sleep_ns <= 0)
+		return false;
+
+	/*
+	 * Find the deepest sleep state that satisfies the residency
+	 * requirement and the QoS constraint
+	 */
+	for (i = genpd->state_count - 1; i >= 0; i--) {
+		u64 state_sleep_ns;
+
+		state_sleep_ns = genpd->states[i].power_off_latency_ns +
+			genpd->states[i].power_on_latency_ns +
+			genpd->states[i].residency_ns;
+
+		/*
+		 * If we cant sleep to save power in the state, move on
+		 * to the next lower idle state.
+		 */
+		if (state_sleep_ns > sleep_ns)
+			continue;
+
+		/*
+		 * We also dont want to sleep more than we should to
+		 * gaurantee QoS.
+		 */
+		if (state_sleep_ns < (qos * NSEC_PER_USEC))
+			break;
+	}
+
+	if (i >= 0)
+		genpd->state_idx = i;
+
+	return  (i >= 0) ? true : false;
+}
+
+static struct dev_power_governor cpu_pd_gov = {
+	.power_down_ok = cpu_pd_down_ok,
+};
+
 static int cpu_pd_attach_cpu(struct cpu_pm_domain *cpu_pd, int cpu)
 {
 	int ret;
@@ -143,7 +216,7 @@ static struct generic_pm_domain *of_init_cpu_pm_domain(struct device_node *dn,
 
 	/* Register the CPU genpd */
 	pr_debug("adding %s as CPU PM domain.\n", pd->genpd->name);
-	ret = of_pm_genpd_init(dn, pd->genpd, &simple_qos_governor, false);
+	ret = of_pm_genpd_init(dn, pd->genpd, &cpu_pd_gov, false);
 	if (ret) {
 		pr_err("Unable to initialize domain %s\n", dn->full_name);
 		goto fail;
-- 
2.1.4



From lina.iyer at linaro.org  Fri Feb 12 12:50:35 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Fri, 12 Feb 2016 13:50:35 -0700
Subject: [RFC v2 09/12] drivers: firmware: psci: Allow OS Initiated suspend
 mode
In-Reply-To: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
References: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
Message-ID: <1455310238-8963-10-git-send-email-lina.iyer@linaro.org>

PSCI firmware v1.0 onwards may support 2 different modes for
CPU_SUSPEND. Platform coordinated mode is the default and every firmware
should support it. The firmware shall also be the default mode.

With the kernel capable of deciding the state for CPU cluster and
coherency domains, the OS Initiated mode may now be used by the kernel,
provided the firmware supports it. SET_SUSPEND_MODE is a PSCI function
available on v1.0 onwards and can be used to set the mode in the
firmware.

Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Cc: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Lina Iyer <lina.iyer at linaro.org>
---
 drivers/firmware/psci.c   | 45 ++++++++++++++++++++++++++++++++++++++++++++-
 include/linux/psci.h      |  2 ++
 include/uapi/linux/psci.h |  5 +++++
 3 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index f25cd79..03c084e 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -49,12 +49,19 @@
  * require cooperation with a Trusted OS driver.
  */
 static int resident_cpu = -1;
+static bool has_osi_pd;
+static bool psci_suspend_mode_is_osi;
 
 bool psci_tos_resident_on(int cpu)
 {
 	return cpu == resident_cpu;
 }
 
+bool psci_has_osi_pd_support(void)
+{
+	return has_osi_pd;
+}
+
 struct psci_operations psci_ops;
 
 typedef unsigned long (psci_fn)(unsigned long, unsigned long,
@@ -250,6 +257,26 @@ static int psci_system_suspend(unsigned long unused)
 			      virt_to_phys(cpu_resume), 0, 0);
 }
 
+int psci_set_suspend_mode_osi(bool enable)
+{
+	int ret;
+	int mode;
+
+	if (enable && !psci_has_osi_pd_support())
+		return -ENODEV;
+
+	if (enable == psci_suspend_mode_is_osi)
+		return 0;
+
+	mode = enable ? PSCI_1_0_SUSPEND_MODE_OSI : PSCI_1_0_SUSPEND_MODE_PC;
+	ret = invoke_psci_fn(PSCI_FN_NATIVE(1_0, SET_SUSPEND_MODE),
+			     mode, 0, 0);
+	if (!ret)
+		psci_suspend_mode_is_osi = enable;
+
+	return psci_to_linux_errno(ret);
+}
+
 static int psci_system_suspend_enter(suspend_state_t state)
 {
 	return cpu_suspend(0, psci_system_suspend);
@@ -443,10 +470,26 @@ out_put_node:
 	return err;
 }
 
+static int __init psci_1_0_init(struct device_node *np)
+{
+	int ret;
+
+	ret = psci_0_2_init(np);
+	if (ret)
+		return ret;
+
+	/* Check if PSCI OSI mode is available */
+	ret = psci_features(PSCI_FN_NATIVE(0_2, CPU_SUSPEND));
+	if (ret & PSCI_1_0_OS_INITIATED)
+		has_osi_pd = true;
+
+	return 0;
+}
+
 static const struct of_device_id const psci_of_match[] __initconst = {
 	{ .compatible = "arm,psci",	.data = psci_0_1_init},
 	{ .compatible = "arm,psci-0.2",	.data = psci_0_2_init},
-	{ .compatible = "arm,psci-1.0",	.data = psci_0_2_init},
+	{ .compatible = "arm,psci-1.0",	.data = psci_1_0_init},
 	{},
 };
 
diff --git a/include/linux/psci.h b/include/linux/psci.h
index 12c4865..deae633 100644
--- a/include/linux/psci.h
+++ b/include/linux/psci.h
@@ -23,6 +23,8 @@
 bool psci_tos_resident_on(int cpu);
 bool psci_power_state_loses_context(u32 state);
 bool psci_power_state_is_valid(u32 state);
+bool psci_has_osi_pd_support(void);
+int psci_set_suspend_mode_osi(bool enable);
 
 struct psci_operations {
 	int (*cpu_suspend)(u32 state, unsigned long entry_point);
diff --git a/include/uapi/linux/psci.h b/include/uapi/linux/psci.h
index 3d7a0fc..eaab6e3 100644
--- a/include/uapi/linux/psci.h
+++ b/include/uapi/linux/psci.h
@@ -50,6 +50,7 @@
 #define PSCI_1_0_FN_SYSTEM_SUSPEND		PSCI_0_2_FN(14)
 
 #define PSCI_1_0_FN64_SYSTEM_SUSPEND		PSCI_0_2_FN64(14)
+#define PSCI_1_0_FN64_SET_SUSPEND_MODE		PSCI_0_2_FN64(15)
 
 /* PSCI v0.2 power state encoding for CPU_SUSPEND function */
 #define PSCI_0_2_POWER_STATE_ID_MASK		0xffff
@@ -93,6 +94,10 @@
 #define PSCI_1_0_FEATURES_CPU_SUSPEND_PF_MASK	\
 			(0x1 << PSCI_1_0_FEATURES_CPU_SUSPEND_PF_SHIFT)
 
+#define PSCI_1_0_OS_INITIATED			BIT(0)
+#define PSCI_1_0_SUSPEND_MODE_PC		0
+#define PSCI_1_0_SUSPEND_MODE_OSI		1
+
 /* PSCI return values (inclusive of all PSCI versions) */
 #define PSCI_RET_SUCCESS			0
 #define PSCI_RET_NOT_SUPPORTED			-1
-- 
2.1.4



From lina.iyer at linaro.org  Fri Feb 12 12:50:38 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Fri, 12 Feb 2016 13:50:38 -0700
Subject: [RFC v2 12/12] ARM64: dts: Define CPU power domain for MSM8916
In-Reply-To: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
References: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
Message-ID: <1455310238-8963-13-git-send-email-lina.iyer@linaro.org>

Define power domain and the power states for the domain as defined by
the PSCI firmware. The 8916 firmware supports OS initiated method of
powering off the CPU clusters.

Cc: <devicetree at vger.kernel.org>
Signed-off-by: Lina Iyer <lina.iyer at linaro.org>
---
Changes since RFC v1 -
- no cpu-map topology node

 arch/arm64/boot/dts/qcom/msm8916.dtsi | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index b7839a8..62dade8 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -63,6 +63,7 @@
 			reg = <0x0>;
 			enable-method = "psci";
 			cpu-idle-states = <&CPU_SPC>;
+			power-domains = <&CPU_PD>;
 		};
 
 		CPU1: cpu at 1 {
@@ -71,6 +72,7 @@
 			reg = <0x1>;
 			enable-method = "psci";
 			cpu-idle-states = <&CPU_SPC>;
+			power-domains = <&CPU_PD>;
 		};
 
 		CPU2: cpu at 2 {
@@ -79,6 +81,7 @@
 			reg = <0x2>;
 			enable-method = "psci";
 			cpu-idle-states = <&CPU_SPC>;
+			power-domains = <&CPU_PD>;
 		};
 
 		CPU3: cpu at 3 {
@@ -87,6 +90,7 @@
 			reg = <0x3>;
 			enable-method = "psci";
 			cpu-idle-states = <&CPU_SPC>;
+			power-domains = <&CPU_PD>;
 		};
 
 		idle-states {
@@ -101,6 +105,27 @@
 		};
 	};
 
+	CPU_PD: cpu-pd at 0 {
+		#power-domain-cells = <0>;
+		power-states = <&CLUSTER_RET>, <&CLUSTER_PWR_DWN>;
+	};
+
+	pd-power-states {
+		CLUSTER_RET: power-state at 1 {
+			state-param = <0x1000010>;
+			entry-latency-us = <500>;
+			exit-latency-us = <500>;
+			residency-us = <2000>;
+		 };
+
+		CLUSTER_PWR_DWN: power-state at 2 {
+			state-param = <0x1000030>;
+			entry-latency-us = <2000>;
+			exit-latency-us = <2000>;
+			residency-us = <6000>;
+		};
+	};
+
 	psci {
 		compatible = "arm,psci-1.0";
 		method = "smc";
-- 
2.1.4



From lina.iyer at linaro.org  Fri Feb 12 12:50:36 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Fri, 12 Feb 2016 13:50:36 -0700
Subject: [RFC v2 10/12] ARM64: psci: Support cluster idle states for
 OS-Initiated
In-Reply-To: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
References: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
Message-ID: <1455310238-8963-11-git-send-email-lina.iyer@linaro.org>

PSCI OS initiated firmware may allow Linux to determine the state of the
CPU cluster and the cluster at coherency level to enter idle states when
there are no active CPUs. Since Linux has a better idea of the QoS and
the wakeup pattern of the CPUs, the cluster idle states may be better
determined by the OS instead of the firmware.

The last CPU entering idle in a cluster, is responsible for selecting
the state of the cluster. Only one CPU in a cluster may provide the
cluster idle state to the firmware. Similarly, the last CPU in the
system may provide the state of the coherency domain along with the
cluster and the CPU state IDs.

Utilize the CPU PM domain framework's helper functions to build up the
hierarchy of cluster topology using Generic PM domains. We provide
callbacks for domain power_on and power_off. By appending the state IDs
at each domain level in the -power_off() callbacks, we build up a
composite state ID that can be passed onto the firmware to idle the CPU,
the cluster and the coherency interface.

Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Cc: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Lina Iyer <lina.iyer at linaro.org>
---
Changes since RFC v1 -
- initializes CPU PM domains based on OSI support in FW
- simplified initialization and cluster state id determination

 arch/arm64/kernel/psci.c | 46 +++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 43 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index f67f35b..75b1707 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -15,6 +15,7 @@
 
 #define pr_fmt(fmt) "psci: " fmt
 
+#include <linux/cpu_domains.h>
 #include <linux/init.h>
 #include <linux/of.h>
 #include <linux/smp.h>
@@ -31,6 +32,24 @@
 #include <asm/suspend.h>
 
 static DEFINE_PER_CPU_READ_MOSTLY(u32 *, psci_power_state);
+static DEFINE_PER_CPU(u32, cluster_state_id);
+
+static inline u32 psci_get_composite_state_id(u32 cpu_state)
+{
+	return cpu_state | this_cpu_read(cluster_state_id);
+}
+
+static inline void psci_reset_composite_state_id(void)
+{
+	this_cpu_write(cluster_state_id, 0);
+}
+
+static int psci_pd_power_off(u32 state_idx, u32 param,
+		const struct cpumask *mask)
+{
+	__this_cpu_add(cluster_state_id, param);
+	return 0;
+}
 
 static int __maybe_unused cpu_psci_cpu_init_idle(unsigned int cpu)
 {
@@ -89,6 +108,19 @@ static int __maybe_unused cpu_psci_cpu_init_idle(unsigned int cpu)
 	}
 	/* Idle states parsed correctly, initialize per-cpu pointer */
 	per_cpu(psci_power_state, cpu) = psci_states;
+
+	if (psci_has_osi_pd_support()) {
+		const struct cpu_pd_ops psci_pd_ops = {
+			.power_off = psci_pd_power_off,
+		};
+
+		ret = of_setup_cpu_pd_single(cpu, &psci_pd_ops);
+		if (!ret)
+			ret = psci_set_suspend_mode_osi(true);
+		if (ret)
+			pr_warn("CPU%d: Error setting PSCI OSI mode\n", cpu);
+	}
+
 	return 0;
 
 free_mem:
@@ -117,6 +149,8 @@ static int cpu_psci_cpu_boot(unsigned int cpu)
 	if (err)
 		pr_err("failed to boot CPU%d (%d)\n", cpu, err);
 
+	/* Reset CPU cluster states */
+	psci_reset_composite_state_id();
 	return err;
 }
 
@@ -181,15 +215,16 @@ static int cpu_psci_cpu_kill(unsigned int cpu)
 static int psci_suspend_finisher(unsigned long index)
 {
 	u32 *state = __this_cpu_read(psci_power_state);
+	u32 ext_state = psci_get_composite_state_id(state[index - 1]);
 
-	return psci_ops.cpu_suspend(state[index - 1],
-				    virt_to_phys(cpu_resume));
+	return psci_ops.cpu_suspend(ext_state, virt_to_phys(cpu_resume));
 }
 
 static int __maybe_unused cpu_psci_cpu_suspend(unsigned long index)
 {
 	int ret;
 	u32 *state = __this_cpu_read(psci_power_state);
+	u32 ext_state = psci_get_composite_state_id(state[index - 1]);
 	/*
 	 * idle state index 0 corresponds to wfi, should never be called
 	 * from the cpu_suspend operations
@@ -198,10 +233,15 @@ static int __maybe_unused cpu_psci_cpu_suspend(unsigned long index)
 		return -EINVAL;
 
 	if (!psci_power_state_loses_context(state[index - 1]))
-		ret = psci_ops.cpu_suspend(state[index - 1], 0);
+		ret = psci_ops.cpu_suspend(ext_state, 0);
 	else
 		ret = cpu_suspend(index, psci_suspend_finisher);
 
+	/*
+	 * Clear the CPU's cluster states, we start afresh after coming
+	 * out of idle.
+	 */
+	psci_reset_composite_state_id();
 	return ret;
 }
 
-- 
2.1.4



From lina.iyer at linaro.org  Fri Feb 12 12:50:37 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Fri, 12 Feb 2016 13:50:37 -0700
Subject: [RFC v2 11/12] ARM64: dts: Add PSCI cpuidle support for MSM8916
In-Reply-To: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
References: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
Message-ID: <1455310238-8963-12-git-send-email-lina.iyer@linaro.org>

Add device bindings for CPUs to suspend using PSCI as the enable-method.

Cc: <devicetree at vger.kernel.org>
Signed-off-by: Lina Iyer <lina.iyer at linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 9153214..b7839a8 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -61,27 +61,51 @@
 			device_type = "cpu";
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0x0>;
+			enable-method = "psci";
+			cpu-idle-states = <&CPU_SPC>;
 		};
 
 		CPU1: cpu at 1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0x1>;
+			enable-method = "psci";
+			cpu-idle-states = <&CPU_SPC>;
 		};
 
 		CPU2: cpu at 2 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0x2>;
+			enable-method = "psci";
+			cpu-idle-states = <&CPU_SPC>;
 		};
 
 		CPU3: cpu at 3 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a53", "arm,armv8";
 			reg = <0x3>;
+			enable-method = "psci";
+			cpu-idle-states = <&CPU_SPC>;
+		};
+
+		idle-states {
+			CPU_SPC: spc {
+				compatible = "arm,idle-state";
+				arm,psci-suspend-param = <0x40000002>;
+				entry-latency-us = <130>;
+				exit-latency-us = <150>;
+				min-residency-us = <2000>;
+				local-timer-stop;
+			};
 		};
 	};
 
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
 	timer {
 		compatible = "arm,armv8-timer";
 		interrupts = <GIC_PPI 2 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
-- 
2.1.4



From robert.jarzmik at free.fr  Fri Feb 12 12:55:53 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Fri, 12 Feb 2016 21:55:53 +0100
Subject: [PATCH 1/4] dma: mmp_pdma: Add the #requestors DT property
 documentation
In-Reply-To: <2622040.i4begfCjyO@wuerfel> (Arnd Bergmann's message of "Thu, 11
 Feb 2016 22:59:51 +0100")
References: <1455225798-9510-1-git-send-email-robert.jarzmik@free.fr>
 <1455225798-9510-2-git-send-email-robert.jarzmik@free.fr>
 <2622040.i4begfCjyO@wuerfel>
Message-ID: <87vb5t1wdi.fsf@belgarion.home>

Arnd Bergmann <arnd at arndb.de> writes:

> On Thursday 11 February 2016 22:23:15 Robert Jarzmik wrote:
>> @@ -12,6 +12,8 @@ Required properties:
>>  Optional properties:
>>  - #dma-channels: Number of DMA channels supported by the controller (defaults
>>    to 32 when not specified)
>> +- #requestors: Number of DMA requestor lines supported by the controller
>> +  (defaults to 0 when not specified)
>>  
>> 
>
> Most other ones use "#dma-requests" as the property name here, I think it makes
> sense to stay with that convention.

Most certainly, for v2.

I'll await for a couple of days for other reviews, especially Vinod's one and
Haojian's ack for the .h change.

Cheers.

-- 
Robert


From computersforpeace at gmail.com  Fri Feb 12 13:00:55 2016
From: computersforpeace at gmail.com (Brian Norris)
Date: Fri, 12 Feb 2016 13:00:55 -0800
Subject: [PATCH v3 01/14] mtd: spi-nor: remove micron_quad_enable()
In-Reply-To: <2904a1d704670a9ef57b09370782e198fab6b1f4.1454505161.git.cyrille.pitchen@atmel.com>
References: <cover.1454505161.git.cyrille.pitchen@atmel.com>
 <2904a1d704670a9ef57b09370782e198fab6b1f4.1454505161.git.cyrille.pitchen@atmel.com>
Message-ID: <20160212210055.GG21465@google.com>

On Wed, Feb 03, 2016 at 02:26:46PM +0100, Cyrille Pitchen wrote:
> This patch remove the micron_quad_enable() function which force the Quad
> SPI mode. However, once this mode is enabled, the Micron memory expect ALL
> commands to use the SPI 4-4-4 protocol. Hence a failure does occur when
> calling spi_nor_wait_till_ready() right after the update of the Enhanced
> Volatile Configuration Register (EVCR) in the micron_quad_enable() as
> the SPI controller driver is not aware about the protocol change.
> 
> Since there is almost no performance increase using Fast Read 4-4-4
> commands instead of Fast Read 1-1-4 commands, we rather keep on using the
> Extended SPI mode than enabling the Quad SPI mode.
> 
> Let's take the example of the pretty standard use of 8 dummy cycles during
> Fast Read operations on 64KB erase sectors:
> 
> Fast Read 1-1-4 requires 8 cycles for the command, then 24 cycles for the
> 3byte address followed by 8 dummy clock cycles and finally 65536*2 cycles
> for the read data; so 131112 clock cycles.
> 
> On the other hand the Fast Read 4-4-4 would require 2 cycles for the
> command, then 6 cycles for the 3byte address followed by 8 dummy clock
> cycles and finally 65536*2 cycles for the read data. So 131088 clock
> cycles. The theorical bandwidth increase is 0.0%.

The assumption of whole-block reads is not always realistic. There are
some controllers that might not handle that length properly, and there
are also use cases that don't need to read that much at once.

> Now using Fast Read operations on 512byte pages:
> Fast Read 1-1-4 needs 8+24+8+(512*2) = 1064 clock cycles whereas Fast
> Read 4-4-4 would requires 2+6+8+(512*2) = 1040 clock cycles. Hence the
> theorical bandwidth increase is 2.3%.

This computation is probably more of a reasonable comparison.

> Consecutive reads for non sequential pages is not a relevant use case so
> The Quad SPI mode is not worth it.

So, I still agree with the conclusion.

Applied this patch to l2-mtd.git.

Brian

> mtd_speedtest seems to confirm these figures.
> 
> Signed-off-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
> Fixes: 548cd3ab54da ("mtd: spi-nor: Add quad I/O support for Micron SPI NOR")


From arnd at arndb.de  Fri Feb 12 13:01:01 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 22:01:01 +0100
Subject: [PATCH] [media] zl10353: use div_u64 instead of do_div
In-Reply-To: <alpine.LFD.2.20.1602121305180.13632@knanqh.ubzr>
References: <1455287246-3540549-1-git-send-email-arnd@arndb.de>
 <2712691.b9gkR7KMX7@wuerfel>
 <alpine.LFD.2.20.1602121305180.13632@knanqh.ubzr>
Message-ID: <6737272.LXr2g355Yt@wuerfel>

On Friday 12 February 2016 13:21:33 Nicolas Pitre wrote:
> On Fri, 12 Feb 2016, Arnd Bergmann wrote:
> 
> > On Friday 12 February 2016 14:32:20 Mauro Carvalho Chehab wrote:
> > > Em Fri, 12 Feb 2016 15:27:18 +0100
> > > Arnd Bergmann <arnd at arndb.de> escreveu:
> > > 
> > > > I noticed a build error in some randconfig builds in the zl10353 driver:
> > > > 
> > > > dvb-frontends/zl10353.c:138: undefined reference to `____ilog2_NaN'
> > > > dvb-frontends/zl10353.c:138: undefined reference to `__aeabi_uldivmod'
> > > > 
> > > > The problem can be tracked down to the use of -fprofile-arcs (using
> > > > CONFIG_GCOV_PROFILE_ALL) in combination with CONFIG_PROFILE_ALL_BRANCHES
> > > > on gcc version 4.9 or higher, when it fails to reliably optimize
> > > > constant expressions.
> > > > 
> > > > Using div_u64() instead of do_div() makes the code slightly more
> > > > readable by both humans and by gcc, which gives the compiler enough
> > > > of a break to figure it all out.
> > > 
> > > I'm not against this patch, but we have 94 occurrences of do_div() 
> > > just at the media subsystem. If this is failing here, it would likely
> > > fail with other drivers. So, I guess we should either fix do_div() or
> > > convert all such occurrences to do_div64().
> > 
> > I agree that it's possible that the same problem exists elsewhere, but this is
> > the only one that I ever saw (in five ranconfig builds out of 8035 last week).
> > 
> > I also tried changing do_div() to be an inline function with just a small
> > macro wrapper around it for the odd calling conventions, which also made this
> > error go away. I would assume that Nico had a good reason for doing do_div()
> > the way he did.
> 
> The do_div() calling convention predates my work on it.  I assume it was 
> originally done this way to better map onto the x86 instruction.

Right, this goes back to the dawn of time.

> > In some other files, I saw the object code grow by a few
> > instructions, but the examples I looked at were otherwise identical.
> > 
> > I can imagine that there might be cases where the constant-argument optimization
> > of do_div fails when we go through an inline function in some combination
> > of Kconfig options and compiler version, though I don't think that was
> > the case here.
> 
> What could be tried is to turn __div64_const32() into a static inline 
> and see if that makes a difference with those gcc versions we currently 
> accept.
> 
> > Nico, any other thoughts on this?
> 
> This is all related to the gcc bug for which I produced a test case 
> here:
> 
> http://article.gmane.org/gmane.linux.kernel.cross-arch/29801
> 
> Do you know if this is fixed in recent gcc?

I have a fairly recent gcc, but I also never got around to submit
it properly.

However, I did stumble over an older patch I did now, which I could
not remember what it was good for. It does fix the problem, and
it seems to be a better solution.

	Arnd

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index b5acbb404854..b5ff9881bef8 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -148,7 +148,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
  */
 #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
 #define __trace_if(cond) \
-	if (__builtin_constant_p((cond)) ? !!(cond) :			\
+	if (__builtin_constant_p(!!(cond)) ? !!(cond) :			\
 	({								\
 		int ______r;						\
 		static struct ftrace_branch_data			\



From tony at atomide.com  Fri Feb 12 13:20:07 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Feb 2016 13:20:07 -0800
Subject: [PATCHv5 0/2] Clock driver for dm814x and dra62x ADPLL
Message-ID: <1455312009-808-1-git-send-email-tony@atomide.com>

Hi,

Here's a clock driver for the ADPLL on dm814x and dra62x. It's still
in read-only mode for the PLL, but is already usable with the gates
and dividers and allows us to add devices like MMC and USB.

Regards,

Tony

Tony Lindgren (2):
  dt-bindings: clock: adpll: Add binding documentation for TI adpll
  clk: ti: Add support for dm814x ADPLL

 .../devicetree/bindings/clock/ti/adpll.txt         |  43 +
 drivers/clk/Kconfig                                |   1 +
 drivers/clk/ti/Kconfig                             |   6 +
 drivers/clk/ti/Makefile                            |   2 +
 drivers/clk/ti/adpll.c                             | 983 +++++++++++++++++++++
 drivers/clk/ti/clk-814x.c                          |  53 ++
 6 files changed, 1088 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/ti/adpll.txt
 create mode 100644 drivers/clk/ti/Kconfig
 create mode 100644 drivers/clk/ti/adpll.c

-- 
2.7.0



From tony at atomide.com  Fri Feb 12 13:20:08 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Feb 2016 13:20:08 -0800
Subject: [PATCH 1/2] dt-bindings: clock: adpll: Add binding documentation for
 TI adpll
In-Reply-To: <1455312009-808-1-git-send-email-tony@atomide.com>
References: <1455312009-808-1-git-send-email-tony@atomide.com>
Message-ID: <1455312009-808-2-git-send-email-tony@atomide.com>

Let's add binding documentation for the ADPLL found on dm814x
and dra62x. The binding uses the standard clock binding.

Cc: devicetree at vger.kernel.org
Cc: Rob Herring <robh+dt at kernel.org>
Cc: Stephen Boyd <sboyd at codeaurora.org>
Cc: Tero Kristo <t-kristo at ti.com>
Acked-by: Michael Turquette <mturquette at baylibre.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 .../devicetree/bindings/clock/ti/adpll.txt         | 43 ++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/ti/adpll.txt

diff --git a/Documentation/devicetree/bindings/clock/ti/adpll.txt b/Documentation/devicetree/bindings/clock/ti/adpll.txt
new file mode 100644
index 0000000..8516bf0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/adpll.txt
@@ -0,0 +1,43 @@
+Binding for Texas Instruments ADPLL clock.
+
+Binding status: Unstable - ABI compatibility may be broken in the future
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped ADPLL with two to three selectable input clocks
+and three to four children.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of "ti,dm814-adpll-s-clock" or
+  "ti,dm814-adpll-lj-clock" depending on the type of the ADPLL
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks clkinp and clkinpulow, note
+  that the adpll-s-clock also has an optional clkinphif
+- reg : address and length of the register set for controlling the ADPLL.
+
+Examples:
+	adpll_mpu_ck: adpll at 40 {
+		#clock-cells = <1>;
+		compatible = "ti,dm814-adpll-s-clock";
+		reg = <0x40 0x40>;
+		clocks = <&devosc_ck &devosc_ck &devosc_ck>;
+		clock-names = "clkinp", "clkinpulow", "clkinphif";
+		clock-indices = <0>, <1>, <2>, <3>;
+		clock-output-names = "481c5040.adpll.dcoclkldo",
+				     "481c5040.adpll.clkout",
+				     "481c5040.adpll.clkoutx2",
+				     "481c5040.adpll.clkouthif";
+	};
+
+	adpll_dsp_ck: adpll at 80 {
+		#clock-cells = <1>;
+		compatible = "ti,dm814-adpll-lj-clock";
+		reg = <0x80 0x30>;
+		clocks = <&devosc_ck &devosc_ck>;
+		clock-names = "clkinp", "clkinpulow";
+		clock-indices = <0>, <1>, <2>;
+		clock-output-names = "481c5080.adpll.dcoclkldo",
+				     "481c5080.adpll.clkout",
+				     "481c5080.adpll.clkoutldo";
+	};
-- 
2.7.0



From tony at atomide.com  Fri Feb 12 13:20:09 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Feb 2016 13:20:09 -0800
Subject: [PATCH 2/2] clk: ti: Add support for dm814x ADPLL
In-Reply-To: <1455312009-808-1-git-send-email-tony@atomide.com>
References: <1455312009-808-1-git-send-email-tony@atomide.com>
Message-ID: <1455312009-808-3-git-send-email-tony@atomide.com>

On dm814x we have 13 ADPLLs with 3 to 4 outputs on each. The
ADPLLs have several dividers and muxes controlled by a shared
control register for each PLL.

Note that for the clocks to work as device drivers for booting on
dm814x, this patch depends on "ARM: OMAP2+: Change core_initcall
levels to postcore_initcall".

Also note that this patch does not implement clk_set_rate for the
PLL, that will be posted later on when available.

Cc: Michael Turquette <mturquette at baylibre.com>
Cc: Stephen Boyd <sboyd at codeaurora.org>
Acked-by: Tero Kristo <t-kristo at ti.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---

Changes since v4:

- Removed ti_adpll_clkout_set_parent() as requested by Tero for his
  conditional ack

- Split the device tree binding into a separate patch as requested
  by Mike for his conditional ack of the binding

- Updated dts patch comments about dynamically generated names as
  suggested by Tero.

- Fixed a compiler warning for do_div


 drivers/clk/Kconfig       |   1 +
 drivers/clk/ti/Kconfig    |   6 +
 drivers/clk/ti/Makefile   |   2 +
 drivers/clk/ti/adpll.c    | 983 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/clk/ti/clk-814x.c |  53 +++
 5 files changed, 1045 insertions(+)
 create mode 100644 drivers/clk/ti/Kconfig
 create mode 100644 drivers/clk/ti/adpll.c

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index eca8e01..0b7364a 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -202,6 +202,7 @@ config COMMON_CLK_CDCE706
 
 source "drivers/clk/bcm/Kconfig"
 source "drivers/clk/hisilicon/Kconfig"
+source "drivers/clk/ti/Kconfig"
 source "drivers/clk/qcom/Kconfig"
 
 endmenu
diff --git a/drivers/clk/ti/Kconfig b/drivers/clk/ti/Kconfig
new file mode 100644
index 0000000..a9d5474
--- /dev/null
+++ b/drivers/clk/ti/Kconfig
@@ -0,0 +1,6 @@
+config COMMON_CLK_TI_ADPLL
+	tristate "Clock driver for dm814x ADPLL"
+	depends on ARCH_OMAP2PLUS
+	default y if SOC_TI81XX
+	---help---
+	  ADPLL clock driver for the dm814x SoC using common clock framework.
diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile
index d4ac960..dfe91d7 100644
--- a/drivers/clk/ti/Makefile
+++ b/drivers/clk/ti/Makefile
@@ -18,3 +18,5 @@ obj-$(CONFIG_SOC_AM43XX)		+= $(clk-common) dpll3xxx.o clk-43xx.o
 ifdef CONFIG_ATAGS
 obj-$(CONFIG_ARCH_OMAP3)                += clk-3xxx-legacy.o
 endif
+
+obj-$(CONFIG_COMMON_CLK_TI_ADPLL)	+= adpll.o
diff --git a/drivers/clk/ti/adpll.c b/drivers/clk/ti/adpll.c
new file mode 100644
index 0000000..033c45d
--- /dev/null
+++ b/drivers/clk/ti/adpll.c
@@ -0,0 +1,983 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/math64.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/string.h>
+
+#define ADPLL_PLLSS_MMR_LOCK_OFFSET	0x00	/* Managed by MPPULL */
+#define ADPLL_PLLSS_MMR_LOCK_ENABLED	0x1f125B64
+#define ADPLL_PLLSS_MMR_UNLOCK_MAGIC	0x1eda4c3d
+
+#define ADPLL_PWRCTRL_OFFSET		0x00
+#define ADPLL_PWRCTRL_PONIN		5
+#define ADPLL_PWRCTRL_PGOODIN		4
+#define ADPLL_PWRCTRL_RET		3
+#define ADPLL_PWRCTRL_ISORET		2
+#define ADPLL_PWRCTRL_ISOSCAN		1
+#define ADPLL_PWRCTRL_OFFMODE		0
+
+#define ADPLL_CLKCTRL_OFFSET		0x04
+#define ADPLL_CLKCTRL_CLKDCOLDOEN	29
+#define ADPLL_CLKCTRL_IDLE		23
+#define ADPLL_CLKCTRL_CLKOUTEN		20
+#define ADPLL_CLKINPHIFSEL_ADPLL_S	19	/* REVISIT: which bit? */
+#define ADPLL_CLKCTRL_CLKOUTLDOEN_ADPLL_LJ 19
+#define ADPLL_CLKCTRL_ULOWCLKEN		18
+#define ADPLL_CLKCTRL_CLKDCOLDOPWDNZ	17
+#define ADPLL_CLKCTRL_M2PWDNZ		16
+#define ADPLL_CLKCTRL_M3PWDNZ_ADPLL_S	15
+#define ADPLL_CLKCTRL_LOWCURRSTDBY_ADPLL_S 13
+#define ADPLL_CLKCTRL_LPMODE_ADPLL_S	12
+#define ADPLL_CLKCTRL_REGM4XEN_ADPLL_S	10
+#define ADPLL_CLKCTRL_SELFREQDCO_ADPLL_LJ 10
+#define ADPLL_CLKCTRL_TINITZ		0
+
+#define ADPLL_TENABLE_OFFSET		0x08
+#define ADPLL_TENABLEDIV_OFFSET		0x8c
+
+#define ADPLL_M2NDIV_OFFSET		0x10
+#define ADPLL_M2NDIV_M2			16
+#define ADPLL_M2NDIV_M2_ADPLL_S_WIDTH	5
+#define ADPLL_M2NDIV_M2_ADPLL_LJ_WIDTH	7
+
+#define ADPLL_MN2DIV_OFFSET		0x14
+#define ADPLL_MN2DIV_N2			16
+
+#define ADPLL_FRACDIV_OFFSET		0x18
+#define ADPLL_FRACDIV_REGSD		24
+#define ADPLL_FRACDIV_FRACTIONALM	0
+#define ADPLL_FRACDIV_FRACTIONALM_MASK	0x3ffff
+
+#define ADPLL_BWCTRL_OFFSET		0x1c
+#define ADPLL_BWCTRL_BWCONTROL		1
+#define ADPLL_BWCTRL_BW_INCR_DECRZ	0
+
+#define ADPLL_RESERVED_OFFSET		0x20
+
+#define ADPLL_STATUS_OFFSET		0x24
+#define ADPLL_STATUS_PONOUT		31
+#define ADPLL_STATUS_PGOODOUT		30
+#define ADPLL_STATUS_LDOPWDN		29
+#define ADPLL_STATUS_RECAL_BSTATUS3	28
+#define ADPLL_STATUS_RECAL_OPPIN	27
+#define ADPLL_STATUS_PHASELOCK		10
+#define ADPLL_STATUS_FREQLOCK		9
+#define ADPLL_STATUS_BYPASSACK		8
+#define ADPLL_STATUS_LOSSREF		6
+#define ADPLL_STATUS_CLKOUTENACK	5
+#define ADPLL_STATUS_LOCK2		4
+#define ADPLL_STATUS_M2CHANGEACK	3
+#define ADPLL_STATUS_HIGHJITTER		1
+#define ADPLL_STATUS_BYPASS		0
+#define ADPLL_STATUS_PREPARED_MASK	(BIT(ADPLL_STATUS_PHASELOCK) | \
+					 BIT(ADPLL_STATUS_FREQLOCK))
+
+#define ADPLL_M3DIV_OFFSET		0x28	/* Only on MPUPLL */
+#define ADPLL_M3DIV_M3			0
+#define ADPLL_M3DIV_M3_WIDTH		5
+#define ADPLL_M3DIV_M3_MASK		0x1f
+
+#define ADPLL_RAMPCTRL_OFFSET		0x2c	/* Only on MPUPLL */
+#define ADPLL_RAMPCTRL_CLKRAMPLEVEL	19
+#define ADPLL_RAMPCTRL_CLKRAMPRATE	16
+#define ADPLL_RAMPCTRL_RELOCK_RAMP_EN	0
+
+#define MAX_ADPLL_INPUTS		3
+#define MAX_ADPLL_OUTPUTS		4
+#define ADPLL_MAX_RETRIES		5
+
+#define to_dco(_hw)	container_of(_hw, struct ti_adpll_dco_data, hw)
+#define to_adpll(_hw)	container_of(_hw, struct ti_adpll_data, dco)
+#define to_clkout(_hw)	container_of(_hw, struct ti_adpll_clkout_data, hw)
+
+enum ti_adpll_clocks {
+	TI_ADPLL_DCO,
+	TI_ADPLL_DCO_GATE,
+	TI_ADPLL_N2,
+	TI_ADPLL_M2,
+	TI_ADPLL_M2_GATE,
+	TI_ADPLL_BYPASS,
+	TI_ADPLL_HIF,
+	TI_ADPLL_DIV2,
+	TI_ADPLL_CLKOUT,
+	TI_ADPLL_CLKOUT2,
+	TI_ADPLL_M3,
+};
+
+#define TI_ADPLL_NR_CLOCKS	(TI_ADPLL_M3 + 1)
+
+enum ti_adpll_inputs {
+	TI_ADPLL_CLKINP,
+	TI_ADPLL_CLKINPULOW,
+	TI_ADPLL_CLKINPHIF,
+};
+
+enum ti_adpll_s_outputs {
+	TI_ADPLL_S_DCOCLKLDO,
+	TI_ADPLL_S_CLKOUT,
+	TI_ADPLL_S_CLKOUTX2,
+	TI_ADPLL_S_CLKOUTHIF,
+};
+
+enum ti_adpll_lj_outputs {
+	TI_ADPLL_LJ_CLKDCOLDO,
+	TI_ADPLL_LJ_CLKOUT,
+	TI_ADPLL_LJ_CLKOUTLDO,
+};
+
+struct ti_adpll_platform_data {
+	const bool is_type_s;
+	const int nr_max_inputs;
+	const int nr_max_outputs;
+	const int output_index;
+};
+
+struct ti_adpll_clock {
+	struct clk *clk;
+	struct clk_lookup *cl;
+	void (*unregister)(struct clk *clk);
+};
+
+struct ti_adpll_dco_data {
+	struct clk_hw hw;
+};
+
+struct ti_adpll_clkout_data {
+	struct ti_adpll_data *adpll;
+	struct clk_gate gate;
+	struct clk_hw hw;
+};
+
+struct ti_adpll_data {
+	struct device *dev;
+	const struct ti_adpll_platform_data *c;
+	struct device_node *np;
+	unsigned long pa;
+	void __iomem *iobase;
+	void __iomem *regs;
+	spinlock_t lock;	/* For ADPLL shared register access */
+	const char *parent_names[MAX_ADPLL_INPUTS];
+	struct clk *parent_clocks[MAX_ADPLL_INPUTS];
+	struct ti_adpll_clock *clocks;
+	struct clk_onecell_data outputs;
+	struct ti_adpll_dco_data dco;
+};
+
+static const char *ti_adpll_clk_get_name(struct ti_adpll_data *d,
+					 int output_index,
+					 const char *postfix)
+{
+	const char *name;
+	int err;
+
+	if (output_index >= 0) {
+		err = of_property_read_string_index(d->np,
+						    "clock-output-names",
+						    output_index,
+						    &name);
+		if (err)
+			return NULL;
+	} else {
+		const char *base_name = "adpll";
+		char *buf;
+
+		buf = devm_kzalloc(d->dev, 8 + 1 + strlen(base_name) + 1 +
+				    strlen(postfix), GFP_KERNEL);
+		if (!buf)
+			return NULL;
+		sprintf(buf, "%08lx.%s.%s", d->pa, base_name, postfix);
+		name = buf;
+	}
+
+	return name;
+}
+
+#define ADPLL_MAX_CON_ID	16	/* See MAX_CON_ID */
+
+static int ti_adpll_setup_clock(struct ti_adpll_data *d, struct clk *clock,
+				int index, int output_index, const char *name,
+				void (*unregister)(struct clk *clk))
+{
+	struct clk_lookup *cl;
+	const char *postfix = NULL;
+	char con_id[ADPLL_MAX_CON_ID];
+
+	d->clocks[index].clk = clock;
+	d->clocks[index].unregister = unregister;
+
+	/* Separate con_id in format "pll040dcoclkldo" to fit MAX_CON_ID */
+	postfix = strrchr(name, '.');
+	if (strlen(postfix) > 1) {
+		if (strlen(postfix) > ADPLL_MAX_CON_ID)
+			dev_warn(d->dev, "clock %s con_id lookup may fail\n",
+				 name);
+		snprintf(con_id, 16, "pll%03lx%s", d->pa & 0xfff, postfix + 1);
+		cl = clkdev_create(clock, con_id, NULL);
+		if (!cl)
+			return -ENOMEM;
+		d->clocks[index].cl = cl;
+	} else {
+		dev_warn(d->dev, "no con_id for clock %s\n", name);
+	}
+
+	if (output_index < 0)
+		return 0;
+
+	d->outputs.clks[output_index] = clock;
+	d->outputs.clk_num++;
+
+	return 0;
+}
+
+static int ti_adpll_init_divider(struct ti_adpll_data *d,
+				 enum ti_adpll_clocks index,
+				 int output_index, char *name,
+				 struct clk *parent_clock,
+				 void __iomem *reg,
+				 u8 shift, u8 width,
+				 u8 clk_divider_flags)
+{
+	const char *child_name;
+	const char *parent_name;
+	struct clk *clock;
+
+	child_name = ti_adpll_clk_get_name(d, output_index, name);
+	if (!child_name)
+		return -EINVAL;
+
+	parent_name = __clk_get_name(parent_clock);
+	clock = clk_register_divider(d->dev, child_name, parent_name, 0,
+				     reg, shift, width, clk_divider_flags,
+				     &d->lock);
+	if (IS_ERR(clock)) {
+		dev_err(d->dev, "failed to register divider %s: %li\n",
+			name, PTR_ERR(clock));
+		return PTR_ERR(clock);
+	}
+
+	return ti_adpll_setup_clock(d, clock, index, output_index, child_name,
+				    clk_unregister_divider);
+}
+
+static int ti_adpll_init_mux(struct ti_adpll_data *d,
+			     enum ti_adpll_clocks index,
+			     char *name, struct clk *clk0,
+			     struct clk *clk1,
+			     void __iomem *reg,
+			     u8 shift)
+{
+	const char *child_name;
+	const char *parents[2];
+	struct clk *clock;
+
+	child_name = ti_adpll_clk_get_name(d, -ENODEV, name);
+	if (!child_name)
+		return -ENOMEM;
+	parents[0] = __clk_get_name(clk0);
+	parents[1] = __clk_get_name(clk1);
+	clock = clk_register_mux(d->dev, child_name, parents, 2, 0,
+				 reg, shift, 1, 0, &d->lock);
+	if (IS_ERR(clock)) {
+		dev_err(d->dev, "failed to register mux %s: %li\n",
+			name, PTR_ERR(clock));
+		return PTR_ERR(clock);
+	}
+
+	return ti_adpll_setup_clock(d, clock, index, -ENODEV, child_name,
+				    clk_unregister_mux);
+}
+
+static int ti_adpll_init_gate(struct ti_adpll_data *d,
+			      enum ti_adpll_clocks index,
+			      int output_index, char *name,
+			      struct clk *parent_clock,
+			      void __iomem *reg,
+			      u8 bit_idx,
+			      u8 clk_gate_flags)
+{
+	const char *child_name;
+	const char *parent_name;
+	struct clk *clock;
+
+	child_name = ti_adpll_clk_get_name(d, output_index, name);
+	if (!child_name)
+		return -EINVAL;
+
+	parent_name = __clk_get_name(parent_clock);
+	clock = clk_register_gate(d->dev, child_name, parent_name, 0,
+				  reg, bit_idx, clk_gate_flags,
+				  &d->lock);
+	if (IS_ERR(clock)) {
+		dev_err(d->dev, "failed to register gate %s: %li\n",
+			name, PTR_ERR(clock));
+		return PTR_ERR(clock);
+	}
+
+	return ti_adpll_setup_clock(d, clock, index, output_index, child_name,
+				    clk_unregister_gate);
+}
+
+static int ti_adpll_init_fixed_factor(struct ti_adpll_data *d,
+				      enum ti_adpll_clocks index,
+				      char *name,
+				      struct clk *parent_clock,
+				      unsigned int mult,
+				      unsigned int div)
+{
+	const char *child_name;
+	const char *parent_name;
+	struct clk *clock;
+
+	child_name = ti_adpll_clk_get_name(d, -ENODEV, name);
+	if (!child_name)
+		return -ENOMEM;
+
+	parent_name = __clk_get_name(parent_clock);
+	clock = clk_register_fixed_factor(d->dev, child_name, parent_name,
+					  0, mult, div);
+	if (IS_ERR(clock))
+		return PTR_ERR(clock);
+
+	return ti_adpll_setup_clock(d, clock, index, -ENODEV, child_name,
+				    clk_unregister);
+}
+
+static void ti_adpll_set_idle_bypass(struct ti_adpll_data *d)
+{
+	unsigned long flags;
+	u32 v;
+
+	spin_lock_irqsave(&d->lock, flags);
+	v = readl_relaxed(d->regs + ADPLL_CLKCTRL_OFFSET);
+	v |= BIT(ADPLL_CLKCTRL_IDLE);
+	writel_relaxed(v, d->regs + ADPLL_CLKCTRL_OFFSET);
+	spin_unlock_irqrestore(&d->lock, flags);
+}
+
+static void ti_adpll_clear_idle_bypass(struct ti_adpll_data *d)
+{
+	unsigned long flags;
+	u32 v;
+
+	spin_lock_irqsave(&d->lock, flags);
+	v = readl_relaxed(d->regs + ADPLL_CLKCTRL_OFFSET);
+	v &= ~BIT(ADPLL_CLKCTRL_IDLE);
+	writel_relaxed(v, d->regs + ADPLL_CLKCTRL_OFFSET);
+	spin_unlock_irqrestore(&d->lock, flags);
+}
+
+static bool ti_adpll_clock_is_bypass(struct ti_adpll_data *d)
+{
+	u32 v;
+
+	v = readl_relaxed(d->regs + ADPLL_STATUS_OFFSET);
+
+	return v & BIT(ADPLL_STATUS_BYPASS);
+}
+
+/*
+ * Locked and bypass are not actually mutually exclusive:  if you only care
+ * about the DCO clock and not CLKOUT you can clear M2PWDNZ before enabling
+ * the PLL, resulting in status (FREQLOCK | PHASELOCK | BYPASS) after lock.
+ */
+static bool ti_adpll_is_locked(struct ti_adpll_data *d)
+{
+	u32 v = readl_relaxed(d->regs + ADPLL_STATUS_OFFSET);
+
+	return (v & ADPLL_STATUS_PREPARED_MASK) == ADPLL_STATUS_PREPARED_MASK;
+}
+
+static int ti_adpll_wait_lock(struct ti_adpll_data *d)
+{
+	int retries = ADPLL_MAX_RETRIES;
+
+	do {
+		if (ti_adpll_is_locked(d))
+			return 0;
+		usleep_range(200, 300);
+	} while (retries--);
+
+	dev_err(d->dev, "pll failed to lock\n");
+	return -ETIMEDOUT;
+}
+
+static int ti_adpll_prepare(struct clk_hw *hw)
+{
+	struct ti_adpll_dco_data *dco = to_dco(hw);
+	struct ti_adpll_data *d = to_adpll(dco);
+
+	ti_adpll_clear_idle_bypass(d);
+	ti_adpll_wait_lock(d);
+
+	return 0;
+}
+
+static void ti_adpll_unprepare(struct clk_hw *hw)
+{
+	struct ti_adpll_dco_data *dco = to_dco(hw);
+	struct ti_adpll_data *d = to_adpll(dco);
+
+	ti_adpll_set_idle_bypass(d);
+}
+
+static int ti_adpll_is_prepared(struct clk_hw *hw)
+{
+	struct ti_adpll_dco_data *dco = to_dco(hw);
+	struct ti_adpll_data *d = to_adpll(dco);
+
+	return ti_adpll_is_locked(d);
+}
+
+/*
+ * Note that the DCO clock is never subject to bypass: if the PLL is off,
+ * dcoclk is low.
+ */
+static unsigned long ti_adpll_recalc_rate(struct clk_hw *hw,
+					  unsigned long parent_rate)
+{
+	struct ti_adpll_dco_data *dco = to_dco(hw);
+	struct ti_adpll_data *d = to_adpll(dco);
+	u32 frac_m, divider, v;
+	u64 rate;
+	unsigned long flags;
+
+	if (ti_adpll_clock_is_bypass(d))
+		return 0;
+
+	spin_lock_irqsave(&d->lock, flags);
+	frac_m = readl_relaxed(d->regs + ADPLL_FRACDIV_OFFSET);
+	frac_m &= ADPLL_FRACDIV_FRACTIONALM_MASK;
+	rate = readw_relaxed(d->regs + ADPLL_MN2DIV_OFFSET) << 18;
+	rate += frac_m;
+	rate *= parent_rate;
+	divider = (readw_relaxed(d->regs + ADPLL_M2NDIV_OFFSET) + 1) << 18;
+	spin_unlock_irqrestore(&d->lock, flags);
+
+	do_div(rate, divider);
+
+	if (d->c->is_type_s) {
+		v = readl_relaxed(d->regs + ADPLL_CLKCTRL_OFFSET);
+		if (v & BIT(ADPLL_CLKCTRL_REGM4XEN_ADPLL_S))
+			rate *= 4;
+		rate *= 2;
+	}
+
+	return rate;
+}
+
+/* PLL parent is always clkinp, bypass only affects the children */
+static u8 ti_adpll_get_parent(struct clk_hw *hw)
+{
+	return 0;
+}
+
+static struct clk_ops ti_adpll_ops = {
+	.prepare = ti_adpll_prepare,
+	.unprepare = ti_adpll_unprepare,
+	.is_prepared = ti_adpll_is_prepared,
+	.recalc_rate = ti_adpll_recalc_rate,
+	.get_parent = ti_adpll_get_parent,
+};
+
+static int ti_adpll_init_dco(struct ti_adpll_data *d)
+{
+	struct clk_init_data init;
+	struct clk *clock;
+	const char *postfix;
+	int width, err;
+
+	d->outputs.clks = devm_kzalloc(d->dev, sizeof(struct clk *) *
+				       MAX_ADPLL_OUTPUTS,
+				       GFP_KERNEL);
+	if (!d->outputs.clks)
+		return -ENOMEM;
+
+	if (d->c->output_index < 0)
+		postfix = "dco";
+	else
+		postfix = NULL;
+
+	init.name = ti_adpll_clk_get_name(d, d->c->output_index, postfix);
+	if (!init.name)
+		return -EINVAL;
+
+	init.parent_names = d->parent_names;
+	init.num_parents = d->c->nr_max_inputs;
+	init.ops = &ti_adpll_ops;
+	init.flags = CLK_GET_RATE_NOCACHE;
+	d->dco.hw.init = &init;
+
+	if (d->c->is_type_s)
+		width = 5;
+	else
+		width = 4;
+
+	/* Internal input clock divider N2 */
+	err = ti_adpll_init_divider(d, TI_ADPLL_N2, -ENODEV, "n2",
+				    d->parent_clocks[TI_ADPLL_CLKINP],
+				    d->regs + ADPLL_MN2DIV_OFFSET,
+				    ADPLL_MN2DIV_N2, width, 0);
+	if (err)
+		return err;
+
+	clock = devm_clk_register(d->dev, &d->dco.hw);
+	if (IS_ERR(clock))
+		return PTR_ERR(clock);
+
+	return ti_adpll_setup_clock(d, clock, TI_ADPLL_DCO, d->c->output_index,
+				    init.name, NULL);
+}
+
+static int ti_adpll_clkout_enable(struct clk_hw *hw)
+{
+	struct ti_adpll_clkout_data *co = to_clkout(hw);
+	struct clk_hw *gate_hw = &co->gate.hw;
+
+	__clk_hw_set_clk(gate_hw, hw);
+
+	return clk_gate_ops.enable(gate_hw);
+}
+
+static void ti_adpll_clkout_disable(struct clk_hw *hw)
+{
+	struct ti_adpll_clkout_data *co = to_clkout(hw);
+	struct clk_hw *gate_hw = &co->gate.hw;
+
+	__clk_hw_set_clk(gate_hw, hw);
+	clk_gate_ops.disable(gate_hw);
+}
+
+static int ti_adpll_clkout_is_enabled(struct clk_hw *hw)
+{
+	struct ti_adpll_clkout_data *co = to_clkout(hw);
+	struct clk_hw *gate_hw = &co->gate.hw;
+
+	__clk_hw_set_clk(gate_hw, hw);
+
+	return clk_gate_ops.is_enabled(gate_hw);
+}
+
+/* Setting PLL bypass puts clkout and clkoutx2 into bypass */
+static u8 ti_adpll_clkout_get_parent(struct clk_hw *hw)
+{
+	struct ti_adpll_clkout_data *co = to_clkout(hw);
+	struct ti_adpll_data *d = co->adpll;
+
+	return ti_adpll_clock_is_bypass(d);
+}
+
+static int ti_adpll_init_clkout(struct ti_adpll_data *d,
+				enum ti_adpll_clocks index,
+				int output_index, int gate_bit,
+				char *name, struct clk *clk0,
+				struct clk *clk1)
+{
+	struct ti_adpll_clkout_data *co;
+	struct clk_init_data init;
+	struct clk_ops *ops;
+	const char *parent_names[2];
+	const char *child_name;
+	struct clk *clock;
+	int err;
+
+	co = devm_kzalloc(d->dev, sizeof(*co), GFP_KERNEL);
+	if (!co)
+		return -ENOMEM;
+	co->adpll = d;
+
+	err = of_property_read_string_index(d->np,
+					    "clock-output-names",
+					    output_index,
+					    &child_name);
+	if (err)
+		return err;
+
+	ops = devm_kzalloc(d->dev, sizeof(*ops), GFP_KERNEL);
+	if (!ops)
+		return -ENOMEM;
+
+	init.name = child_name;
+	init.ops = ops;
+	init.flags = CLK_IS_BASIC;
+	co->hw.init = &init;
+	parent_names[0] = __clk_get_name(clk0);
+	parent_names[1] = __clk_get_name(clk1);
+	init.parent_names = parent_names;
+	init.num_parents = 2;
+
+	ops->get_parent = ti_adpll_clkout_get_parent;
+	ops->determine_rate = __clk_mux_determine_rate;
+	if (gate_bit) {
+		co->gate.lock = &d->lock;
+		co->gate.reg = d->regs + ADPLL_CLKCTRL_OFFSET;
+		co->gate.bit_idx = gate_bit;
+		ops->enable = ti_adpll_clkout_enable;
+		ops->disable = ti_adpll_clkout_disable;
+		ops->is_enabled = ti_adpll_clkout_is_enabled;
+	}
+
+	clock = devm_clk_register(d->dev, &co->hw);
+	if (IS_ERR(clock)) {
+		dev_err(d->dev, "failed to register output %s: %li\n",
+			name, PTR_ERR(clock));
+		return PTR_ERR(clock);
+	}
+
+	return ti_adpll_setup_clock(d, clock, index, output_index, child_name,
+				    NULL);
+}
+
+static int ti_adpll_init_children_adpll_s(struct ti_adpll_data *d)
+{
+	int err;
+
+	if (!d->c->is_type_s)
+		return 0;
+
+	/* Internal mux, sources from divider N2 or clkinpulow */
+	err = ti_adpll_init_mux(d, TI_ADPLL_BYPASS, "bypass",
+				d->clocks[TI_ADPLL_N2].clk,
+				d->parent_clocks[TI_ADPLL_CLKINPULOW],
+				d->regs + ADPLL_CLKCTRL_OFFSET,
+				ADPLL_CLKCTRL_ULOWCLKEN);
+	if (err)
+		return err;
+
+	/* Internal divider M2, sources DCO */
+	err = ti_adpll_init_divider(d, TI_ADPLL_M2, -ENODEV, "m2",
+				    d->clocks[TI_ADPLL_DCO].clk,
+				    d->regs + ADPLL_M2NDIV_OFFSET,
+				    ADPLL_M2NDIV_M2,
+				    ADPLL_M2NDIV_M2_ADPLL_S_WIDTH,
+				    CLK_DIVIDER_ONE_BASED);
+	if (err)
+		return err;
+
+	/* Internal fixed divider, after M2 before clkout */
+	err = ti_adpll_init_fixed_factor(d, TI_ADPLL_DIV2, "div2",
+					 d->clocks[TI_ADPLL_M2].clk,
+					 1, 2);
+	if (err)
+		return err;
+
+	/* Output clkout with a mux and gate, sources from div2 or bypass */
+	err = ti_adpll_init_clkout(d, TI_ADPLL_CLKOUT, TI_ADPLL_S_CLKOUT,
+				   ADPLL_CLKCTRL_CLKOUTEN, "clkout",
+				   d->clocks[TI_ADPLL_DIV2].clk,
+				   d->clocks[TI_ADPLL_BYPASS].clk);
+	if (err)
+		return err;
+
+	/* Output clkoutx2 with a mux and gate, sources from M2 or bypass */
+	err = ti_adpll_init_clkout(d, TI_ADPLL_CLKOUT2, TI_ADPLL_S_CLKOUTX2, 0,
+				   "clkout2", d->clocks[TI_ADPLL_M2].clk,
+				   d->clocks[TI_ADPLL_BYPASS].clk);
+	if (err)
+		return err;
+
+	/* Internal mux, sources from DCO and clkinphf */
+	if (d->parent_clocks[TI_ADPLL_CLKINPHIF]) {
+		err = ti_adpll_init_mux(d, TI_ADPLL_HIF, "hif",
+					d->clocks[TI_ADPLL_DCO].clk,
+					d->parent_clocks[TI_ADPLL_CLKINPHIF],
+					d->regs + ADPLL_CLKCTRL_OFFSET,
+					ADPLL_CLKINPHIFSEL_ADPLL_S);
+		if (err)
+			return err;
+	}
+
+	/* Output clkouthif with a divider M3, sources from hif */
+	err = ti_adpll_init_divider(d, TI_ADPLL_M3, TI_ADPLL_S_CLKOUTHIF, "m3",
+				    d->clocks[TI_ADPLL_HIF].clk,
+				    d->regs + ADPLL_M3DIV_OFFSET,
+				    ADPLL_M3DIV_M3,
+				    ADPLL_M3DIV_M3_WIDTH,
+				    CLK_DIVIDER_ONE_BASED);
+	if (err)
+		return err;
+
+	/* Output clock dcoclkldo is the DCO */
+
+	return 0;
+}
+
+static int ti_adpll_init_children_adpll_lj(struct ti_adpll_data *d)
+{
+	int err;
+
+	if (d->c->is_type_s)
+		return 0;
+
+	/* Output clkdcoldo, gated output of DCO */
+	err = ti_adpll_init_gate(d, TI_ADPLL_DCO_GATE, TI_ADPLL_LJ_CLKDCOLDO,
+				 "clkdcoldo", d->clocks[TI_ADPLL_DCO].clk,
+				 d->regs + ADPLL_CLKCTRL_OFFSET,
+				 ADPLL_CLKCTRL_CLKDCOLDOEN, 0);
+	if (err)
+		return err;
+
+	/* Internal divider M2, sources from DCO */
+	err = ti_adpll_init_divider(d, TI_ADPLL_M2, -ENODEV,
+				    "m2", d->clocks[TI_ADPLL_DCO].clk,
+				    d->regs + ADPLL_M2NDIV_OFFSET,
+				    ADPLL_M2NDIV_M2,
+				    ADPLL_M2NDIV_M2_ADPLL_LJ_WIDTH,
+				    CLK_DIVIDER_ONE_BASED);
+	if (err)
+		return err;
+
+	/* Output clkoutldo, gated output of M2 */
+	err = ti_adpll_init_gate(d, TI_ADPLL_M2_GATE, TI_ADPLL_LJ_CLKOUTLDO,
+				 "clkoutldo", d->clocks[TI_ADPLL_M2].clk,
+				 d->regs + ADPLL_CLKCTRL_OFFSET,
+				 ADPLL_CLKCTRL_CLKOUTLDOEN_ADPLL_LJ,
+				 0);
+	if (err)
+		return err;
+
+	/* Internal mux, sources from divider N2 or clkinpulow */
+	err = ti_adpll_init_mux(d, TI_ADPLL_BYPASS, "bypass",
+				d->clocks[TI_ADPLL_N2].clk,
+				d->parent_clocks[TI_ADPLL_CLKINPULOW],
+				d->regs + ADPLL_CLKCTRL_OFFSET,
+				ADPLL_CLKCTRL_ULOWCLKEN);
+	if (err)
+		return err;
+
+	/* Output clkout, sources M2 or bypass */
+	err = ti_adpll_init_clkout(d, TI_ADPLL_CLKOUT, TI_ADPLL_S_CLKOUT,
+				   ADPLL_CLKCTRL_CLKOUTEN, "clkout",
+				   d->clocks[TI_ADPLL_M2].clk,
+				   d->clocks[TI_ADPLL_BYPASS].clk);
+	if (err)
+		return err;
+
+	return 0;
+}
+
+static void ti_adpll_free_resources(struct ti_adpll_data *d)
+{
+	int i;
+
+	for (i = TI_ADPLL_M3; i >= 0; i--) {
+		struct ti_adpll_clock *ac = &d->clocks[i];
+
+		if (!ac || IS_ERR_OR_NULL(ac->clk))
+			continue;
+		if (ac->cl)
+			clkdev_drop(ac->cl);
+		if (ac->unregister)
+			ac->unregister(ac->clk);
+	}
+}
+
+/* MPU PLL manages the lock register for all PLLs */
+static void ti_adpll_unlock_all(void __iomem *reg)
+{
+	u32 v;
+
+	v = readl_relaxed(reg);
+	if (v == ADPLL_PLLSS_MMR_LOCK_ENABLED)
+		writel_relaxed(ADPLL_PLLSS_MMR_UNLOCK_MAGIC, reg);
+}
+
+static int ti_adpll_init_registers(struct ti_adpll_data *d)
+{
+	int register_offset = 0;
+
+	if (d->c->is_type_s) {
+		register_offset = 8;
+		ti_adpll_unlock_all(d->iobase + ADPLL_PLLSS_MMR_LOCK_OFFSET);
+	}
+
+	d->regs = d->iobase + register_offset + ADPLL_PWRCTRL_OFFSET;
+
+	return 0;
+}
+
+static int ti_adpll_init_inputs(struct ti_adpll_data *d)
+{
+	const char *error = "need at least %i inputs";
+	struct clk *clock;
+	int nr_inputs;
+
+	nr_inputs = of_clk_get_parent_count(d->np);
+	if (nr_inputs < d->c->nr_max_inputs) {
+		dev_err(d->dev, error, nr_inputs);
+		return -EINVAL;
+	}
+	of_clk_parent_fill(d->np, d->parent_names, nr_inputs);
+
+	clock = devm_clk_get(d->dev, d->parent_names[0]);
+	if (IS_ERR(clock)) {
+		dev_err(d->dev, "could not get clkinp\n");
+		return PTR_ERR(clock);
+	}
+	d->parent_clocks[TI_ADPLL_CLKINP] = clock;
+
+	clock = devm_clk_get(d->dev, d->parent_names[1]);
+	if (IS_ERR(clock)) {
+		dev_err(d->dev, "could not get clkinpulow clock\n");
+		return PTR_ERR(clock);
+	}
+	d->parent_clocks[TI_ADPLL_CLKINPULOW] = clock;
+
+	if (d->c->is_type_s) {
+		clock =  devm_clk_get(d->dev, d->parent_names[2]);
+		if (IS_ERR(clock)) {
+			dev_err(d->dev, "could not get clkinphif clock\n");
+			return PTR_ERR(clock);
+		}
+		d->parent_clocks[TI_ADPLL_CLKINPHIF] = clock;
+	}
+
+	return 0;
+}
+
+static const struct ti_adpll_platform_data ti_adpll_type_s = {
+	.is_type_s = true,
+	.nr_max_inputs = MAX_ADPLL_INPUTS,
+	.nr_max_outputs = MAX_ADPLL_OUTPUTS,
+	.output_index = TI_ADPLL_S_DCOCLKLDO,
+};
+
+static const struct ti_adpll_platform_data ti_adpll_type_lj = {
+	.is_type_s = false,
+	.nr_max_inputs = MAX_ADPLL_INPUTS - 1,
+	.nr_max_outputs = MAX_ADPLL_OUTPUTS - 1,
+	.output_index = -EINVAL,
+};
+
+static const struct of_device_id ti_adpll_match[] = {
+	{ .compatible = "ti,dm814-adpll-s-clock", &ti_adpll_type_s },
+	{ .compatible = "ti,dm814-adpll-lj-clock", &ti_adpll_type_lj },
+	{},
+};
+MODULE_DEVICE_TABLE(of, ti_adpll_match);
+
+static int ti_adpll_probe(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	struct device *dev = &pdev->dev;
+	const struct of_device_id *match;
+	const struct ti_adpll_platform_data *pdata;
+	struct ti_adpll_data *d;
+	struct resource *res;
+	int err;
+
+	match = of_match_device(ti_adpll_match, dev);
+	if (match)
+		pdata = match->data;
+	else
+		return -ENODEV;
+
+	d = devm_kzalloc(dev, sizeof(*d), GFP_KERNEL);
+	if (!d)
+		return -ENOMEM;
+	d->dev = dev;
+	d->np = node;
+	d->c = pdata;
+	dev_set_drvdata(d->dev, d);
+	spin_lock_init(&d->lock);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res)
+		return -ENODEV;
+	d->pa = res->start;
+
+	d->iobase = devm_ioremap_resource(dev, res);
+	if (IS_ERR(d->iobase)) {
+		dev_err(dev, "could not get IO base: %li\n",
+			PTR_ERR(d->iobase));
+		return PTR_ERR(d->iobase);
+	}
+
+	err = ti_adpll_init_registers(d);
+	if (err)
+		return err;
+
+	err = ti_adpll_init_inputs(d);
+	if (err)
+		return err;
+
+	d->clocks = devm_kzalloc(d->dev, sizeof(struct ti_adpll_clock) *
+				 TI_ADPLL_NR_CLOCKS,
+				 GFP_KERNEL);
+	if (!d->clocks)
+		goto free;
+
+	err = ti_adpll_init_dco(d);
+	if (err) {
+		dev_err(dev, "could not register dco: %i\n", err);
+		goto free;
+	}
+
+	err = ti_adpll_init_children_adpll_s(d);
+	if (err)
+		goto free;
+	err = ti_adpll_init_children_adpll_lj(d);
+	if (err)
+		goto free;
+
+	err = of_clk_add_provider(d->np, of_clk_src_onecell_get, &d->outputs);
+	if (err)
+		goto free;
+
+	return 0;
+
+free:
+	WARN_ON(1);
+	ti_adpll_free_resources(d);
+
+	return err;
+}
+
+static int ti_adpll_remove(struct platform_device *pdev)
+{
+	struct ti_adpll_data *d = dev_get_drvdata(&pdev->dev);
+
+	ti_adpll_free_resources(d);
+
+	return 0;
+}
+
+static struct platform_driver ti_adpll_driver = {
+	.driver = {
+		.name = "ti-adpll",
+		.of_match_table = ti_adpll_match,
+	},
+	.probe = ti_adpll_probe,
+	.remove = ti_adpll_remove,
+};
+
+static int __init ti_adpll_init(void)
+{
+	return platform_driver_register(&ti_adpll_driver);
+}
+core_initcall(ti_adpll_init);
+
+static void __exit ti_adpll_exit(void)
+{
+	platform_driver_unregister(&ti_adpll_driver);
+}
+module_exit(ti_adpll_exit);
+
+MODULE_DESCRIPTION("Clock driver for dm814x ADPLL");
+MODULE_ALIAS("platform:dm814-adpll-clock");
+MODULE_AUTHOR("Tony LIndgren <tony at atomide.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/clk/ti/clk-814x.c b/drivers/clk/ti/clk-814x.c
index 9e85fcc..2323643 100644
--- a/drivers/clk/ti/clk-814x.c
+++ b/drivers/clk/ti/clk-814x.c
@@ -5,8 +5,10 @@
  */
 
 #include <linux/kernel.h>
+#include <linux/clk.h>
 #include <linux/clk-provider.h>
 #include <linux/clk/ti.h>
+#include <linux/of_platform.h>
 
 #include "clock.h"
 
@@ -27,11 +29,62 @@ static struct ti_dt_clk dm814_clks[] = {
 	{ .node_name = NULL },
 };
 
+static bool timer_clocks_initialized;
+
+int __init dm814x_adpll_early_init(void)
+{
+	struct device_node *np;
+
+	if (!timer_clocks_initialized)
+		return -ENODEV;
+
+	np = of_find_node_by_name(NULL, "pllss");
+	if (!np) {
+		pr_err("Could not find node for plls\n");
+		return -ENODEV;
+	}
+
+	of_platform_populate(np, NULL, NULL, NULL);
+
+	return 0;
+}
+core_initcall(dm814x_adpll_early_init);
+
+static const char * const init_clocks[] = {
+	"pll040clkout",		/* MPU 481c5040.adpll.clkout */
+	"pll290clkout",		/* DDR 481c5290.adpll.clkout */
+};
+
+int __init dm814x_adpll_enable_init_clocks(void)
+{
+	int i, err;
+
+	if (!timer_clocks_initialized)
+		return -ENODEV;
+
+	for (i = 0; i < ARRAY_SIZE(init_clocks); i++) {
+		struct clk *clock;
+
+		clock = clk_get(NULL, init_clocks[i]);
+		if (WARN(IS_ERR(clock), "could not find init clock %s\n",
+			 init_clocks[i]))
+			continue;
+		err = clk_prepare_enable(clock);
+		if (WARN(err, "could not enable init clock %s\n",
+			 init_clocks[i]))
+			continue;
+	}
+
+	return 0;
+}
+postcore_initcall(dm814x_adpll_enable_init_clocks);
+
 int __init dm814x_dt_clk_init(void)
 {
 	ti_dt_clocks_register(dm814_clks);
 	omap2_clk_disable_autoidle_all();
 	omap2_clk_enable_init_clocks(NULL, 0);
+	timer_clocks_initialized = true;
 
 	return 0;
 }
-- 
2.7.0



From tony at atomide.com  Fri Feb 12 13:21:58 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Feb 2016 13:21:58 -0800
Subject: [PATCH] ARM: dts: Add clocks for dm814x ADPLL
Message-ID: <1455312118-963-1-git-send-email-tony@atomide.com>

These use the standard clock bindings and now we can make some
of the fixed clocks into real clocks.

Note that the clock output names may become optional as we
probably want to eventually use descriptive names, or use
just dynamically generated names as suggested by Tero.

Acked-by: Tero Kristo <t-kristo at ti.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/boot/dts/dm814x-clocks.dtsi | 256 ++++++++++++++++++++++++++++++-----
 arch/arm/boot/dts/dra62x-clocks.dtsi |  26 ++++
 2 files changed, 251 insertions(+), 31 deletions(-)

diff --git a/arch/arm/boot/dts/dm814x-clocks.dtsi b/arch/arm/boot/dts/dm814x-clocks.dtsi
index 2600158..cdceda9 100644
--- a/arch/arm/boot/dts/dm814x-clocks.dtsi
+++ b/arch/arm/boot/dts/dm814x-clocks.dtsi
@@ -4,6 +4,170 @@
  * published by the Free Software Foundation.
  */
 
+&pllss {
+	/*
+	 * See TRM "2.6.10 Connected outputso DPLLS" and
+	 * "2.6.11 Connected Outputs of DPLLJ". Only clkout is
+	 * connected except for hdmi and usb.
+	 */
+	adpll_mpu_ck: adpll at 40 {
+		#clock-cells = <1>;
+		compatible = "ti,dm814-adpll-s-clock";
+		reg = <0x40 0x40>;
+		clocks = <&devosc_ck &devosc_ck &devosc_ck>;
+		clock-names = "clkinp", "clkinpulow", "clkinphif";
+		clock-indices = <0>, <1>, <2>, <3>;
+		clock-output-names = "481c5040.adpll.dcoclkldo",
+				     "481c5040.adpll.clkout",
+				     "481c5040.adpll.clkoutx2",
+				     "481c5040.adpll.clkouthif";
+	};
+
+	adpll_dsp_ck: adpll at 80 {
+		#clock-cells = <1>;
+		compatible = "ti,dm814-adpll-lj-clock";
+		reg = <0x80 0x30>;
+		clocks = <&devosc_ck &devosc_ck>;
+		clock-names = "clkinp", "clkinpulow";
+		clock-indices = <0>, <1>, <2>;
+		clock-output-names = "481c5080.adpll.dcoclkldo",
+				     "481c5080.adpll.clkout",
+				     "481c5080.adpll.clkoutldo";
+	};
+
+	adpll_sgx_ck: adpll at b0 {
+		#clock-cells = <1>;
+		compatible = "ti,dm814-adpll-lj-clock";
+		reg = <0xb0 0x30>;
+		clocks = <&devosc_ck &devosc_ck>;
+		clock-names = "clkinp", "clkinpulow";
+		clock-indices = <0>, <1>, <2>;
+		clock-output-names = "481c50b0.adpll.dcoclkldo",
+				     "481c50b0.adpll.clkout",
+				     "481c50b0.adpll.clkoutldo";
+	};
+
+	adpll_hdvic_ck: adpll at e0 {
+		#clock-cells = <1>;
+		compatible = "ti,dm814-adpll-lj-clock";
+		reg = <0xe0 0x30>;
+		clocks = <&devosc_ck &devosc_ck>;
+		clock-names = "clkinp", "clkinpulow";
+		clock-indices = <0>, <1>, <2>;
+		clock-output-names = "481c50e0.adpll.dcoclkldo",
+				     "481c50e0.adpll.clkout",
+				     "481c50e0.adpll.clkoutldo";
+	};
+
+	adpll_l3_ck: adpll at 110 {
+		#clock-cells = <1>;
+		compatible = "ti,dm814-adpll-lj-clock";
+		reg = <0x110 0x30>;
+		clocks = <&devosc_ck &devosc_ck>;
+		clock-names = "clkinp", "clkinpulow";
+		clock-indices = <0>, <1>, <2>;
+		clock-output-names = "481c5110.adpll.dcoclkldo",
+				     "481c5110.adpll.clkout",
+				     "481c5110.adpll.clkoutldo";
+	};
+
+	adpll_isp_ck: adpll at 140 {
+		#clock-cells = <1>;
+		compatible = "ti,dm814-adpll-lj-clock";
+		reg = <0x140 0x30>;
+		clocks = <&devosc_ck &devosc_ck>;
+		clock-names = "clkinp", "clkinpulow";
+		clock-indices = <0>, <1>, <2>;
+		clock-output-names = "481c5140.adpll.dcoclkldo",
+				     "481c5140.adpll.clkout",
+				     "481c5140.adpll.clkoutldo";
+	};
+
+	adpll_dss_ck: adpll at 170 {
+		#clock-cells = <1>;
+		compatible = "ti,dm814-adpll-lj-clock";
+		reg = <0x170 0x30>;
+		clocks = <&devosc_ck &devosc_ck>;
+		clock-names = "clkinp", "clkinpulow";
+		clock-indices = <0>, <1>, <2>;
+		clock-output-names = "481c5170.adpll.dcoclkldo",
+				     "481c5170.adpll.clkout",
+				     "481c5170.adpll.clkoutldo";
+	};
+
+	adpll_video0_ck: adpll at 1a0 {
+		#clock-cells = <1>;
+		compatible = "ti,dm814-adpll-lj-clock";
+		reg = <0x1a0 0x30>;
+		clocks = <&devosc_ck &devosc_ck>;
+		clock-names = "clkinp", "clkinpulow";
+		clock-indices = <0>, <1>, <2>;
+		clock-output-names = "481c51a0.adpll.dcoclkldo",
+				     "481c51a0.adpll.clkout",
+				     "481c51a0.adpll.clkoutldo";
+	};
+
+	adpll_video1_ck: adpll at 1d0 {
+		#clock-cells = <1>;
+		compatible = "ti,dm814-adpll-lj-clock";
+		reg = <0x1d0 0x30>;
+		clocks = <&devosc_ck &devosc_ck>;
+		clock-names = "clkinp", "clkinpulow";
+		clock-indices = <0>, <1>, <2>;
+		clock-output-names = "481c51d0.adpll.dcoclkldo",
+				     "481c51d0.adpll.clkout",
+				     "481c51d0.adpll.clkoutldo";
+	};
+
+	adpll_hdmi_ck: adpll at 200 {
+		#clock-cells = <1>;
+		compatible = "ti,dm814-adpll-lj-clock";
+		reg = <0x200 0x30>;
+		clocks = <&devosc_ck &devosc_ck>;
+		clock-names = "clkinp", "clkinpulow";
+		clock-indices = <0>, <1>, <2>;
+		clock-output-names = "481c5200.adpll.dcoclkldo",
+				     "481c5200.adpll.clkout",
+				     "481c5200.adpll.clkoutldo";
+	};
+
+	adpll_audio_ck: adpll at 230 {
+		#clock-cells = <1>;
+		compatible = "ti,dm814-adpll-lj-clock";
+		reg = <0x230 0x30>;
+		clocks = <&devosc_ck &devosc_ck>;
+		clock-names = "clkinp", "clkinpulow";
+		clock-indices = <0>, <1>, <2>;
+		clock-output-names = "481c5230.adpll.dcoclkldo",
+				     "481c5230.adpll.clkout",
+				     "481c5230.adpll.clkoutldo";
+	};
+
+	adpll_usb_ck: adpll at 260 {
+		#clock-cells = <1>;
+		compatible = "ti,dm814-adpll-lj-clock";
+		reg = <0x260 0x30>;
+		clocks = <&devosc_ck &devosc_ck>;
+		clock-names = "clkinp", "clkinpulow";
+		clock-indices = <0>, <1>, <2>;
+		clock-output-names = "481c5260.adpll.dcoclkldo",
+				     "481c5260.adpll.clkout",
+				     "481c5260.adpll.clkoutldo";
+	};
+
+	adpll_ddr_ck: adpll at 290 {
+		#clock-cells = <1>;
+		compatible = "ti,dm814-adpll-lj-clock";
+		reg = <0x290 0x30>;
+		clocks = <&devosc_ck &devosc_ck>;
+		clock-names = "clkinp", "clkinpulow";
+		clock-indices = <0>, <1>, <2>;
+		clock-output-names = "481c5290.adpll.dcoclkldo",
+				     "481c5290.adpll.clkout",
+				     "481c5290.adpll.clkoutldo";
+	};
+};
+
 &pllss_clocks {
 	timer1_fck: timer1_fck {
 		#clock-cells = <0>;
@@ -23,6 +187,24 @@
 		reg = <0x2e0>;
 	};
 
+	/* CPTS_RFT_CLK in RMII_REFCLK_SRC, usually sourced from auiod */
+	cpsw_cpts_rft_clk: cpsw_cpts_rft_clk {
+		#clock-cells = <0>;
+		compatible = "ti,mux-clock";
+		clocks = <&adpll_video0_ck 1
+			  &adpll_video1_ck 1
+			  &adpll_audio_ck 1>;
+		ti,bit-shift = <1>;
+		reg = <0x2e8>;
+	};
+
+	/* REVISIT: Set up with a proper mux using RMII_REFCLK_SRC */
+	cpsw_125mhz_gclk: cpsw_125mhz_gclk {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <125000000>;
+	};
+
 	sysclk18_ck: sysclk18_ck {
 		#clock-cells = <0>;
 		compatible = "ti,mux-clock";
@@ -79,37 +261,6 @@
 		compatible = "fixed-clock";
 		clock-frequency = <1000000000>;
 	};
-
-	sysclk4_ck: sysclk4_ck {
-		#clock-cells = <0>;
-		compatible = "fixed-clock";
-		clock-frequency = <222000000>;
-	};
-
-	sysclk6_ck: sysclk6_ck {
-		#clock-cells = <0>;
-		compatible = "fixed-clock";
-		clock-frequency = <100000000>;
-	};
-
-	sysclk10_ck: sysclk10_ck {
-		#clock-cells = <0>;
-		compatible = "fixed-clock";
-		clock-frequency = <48000000>;
-	};
-
-        cpsw_125mhz_gclk: cpsw_125mhz_gclk {
-		#clock-cells = <0>;
-		compatible = "fixed-clock";
-		clock-frequency = <125000000>;
-	};
-
-	cpsw_cpts_rft_clk: cpsw_cpts_rft_clk {
-		#clock-cells = <0>;
-		compatible = "fixed-clock";
-		clock-frequency = <250000000>;
-	};
-
 };
 
 &prcm_clocks {
@@ -138,6 +289,49 @@
 		clock-div = <78125>;
 	};
 
+	/* L4_HS 220 MHz*/
+	sysclk4_ck: sysclk4_ck {
+		#clock-cells = <0>;
+		compatible = "ti,fixed-factor-clock";
+		clocks = <&adpll_l3_ck 1>;
+		ti,clock-mult = <1>;
+		ti,clock-div = <1>;
+	};
+
+	/* L4_FWCFG */
+	sysclk5_ck: sysclk5_ck {
+		#clock-cells = <0>;
+		compatible = "ti,fixed-factor-clock";
+		clocks = <&adpll_l3_ck 1>;
+		ti,clock-mult = <1>;
+		ti,clock-div = <2>;
+	};
+
+	/* L4_LS 110 MHz */
+	sysclk6_ck: sysclk6_ck {
+		#clock-cells = <0>;
+		compatible = "ti,fixed-factor-clock";
+		clocks = <&adpll_l3_ck 1>;
+		ti,clock-mult = <1>;
+		ti,clock-div = <2>;
+	};
+
+	sysclk8_ck: sysclk8_ck {
+		#clock-cells = <0>;
+		compatible = "ti,fixed-factor-clock";
+		clocks = <&adpll_usb_ck 1>;
+		ti,clock-mult = <1>;
+		ti,clock-div = <1>;
+	};
+
+	sysclk10_ck: sysclk10_ck {
+		compatible = "ti,divider-clock";
+		reg = <0x324>;
+		ti,max-div = <7>;
+		#clock-cells = <0>;
+		clocks = <&adpll_usb_ck 1>;
+	};
+
 	aud_clkin0_ck: aud_clkin0_ck {
 		#clock-cells = <0>;
 		compatible = "fixed-clock";
diff --git a/arch/arm/boot/dts/dra62x-clocks.dtsi b/arch/arm/boot/dts/dra62x-clocks.dtsi
index 6f98dc8..0e49741 100644
--- a/arch/arm/boot/dts/dra62x-clocks.dtsi
+++ b/arch/arm/boot/dts/dra62x-clocks.dtsi
@@ -6,6 +6,32 @@
 
 #include "dm814x-clocks.dtsi"
 
+/* Compared to dm814x, dra62x does not have hdic, l3 or dss PLLs */
+&adpll_hdvic_ck {
+	status = "disabled";
+};
+
+&adpll_l3_ck {
+	status = "disabled";
+};
+
+&adpll_dss_ck {
+	status = "disabled";
+};
+
+/* Compared to dm814x, dra62x has interconnect clocks on isp PLL */
+&sysclk4_ck {
+	clocks = <&adpll_isp_ck 1>;
+};
+
+&sysclk5_ck {
+	clocks = <&adpll_isp_ck 1>;
+};
+
+&sysclk6_ck {
+	clocks = <&adpll_isp_ck 1>;
+};
+
 /*
  * Compared to dm814x, dra62x has different shifts and more mux options.
  * Please add the extra options for ysclk_14 and 16 if really needed.
-- 
2.7.0



From broonie at kernel.org  Fri Feb 12 13:26:00 2016
From: broonie at kernel.org (Mark Brown)
Date: Fri, 12 Feb 2016 21:26:00 +0000
Subject: [PATCH] Revert "ASoC: qcom: Specify LE device endianness"
In-Reply-To: <1455298217-15744-1-git-send-email-sboyd@codeaurora.org>
References: <1455298217-15744-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <20160212212600.GA18872@sirena.org.uk>

On Fri, Feb 12, 2016 at 09:30:17AM -0800, Stephen Boyd wrote:
> This reverts commit 18560a4e3b07438113b50589e78532d95f907029.
> 
> The commit that caused us to specify LE device endianness here,
> 29bb45f25ff3 (regmap-mmio: Use native endianness for read/write,
> 2015-10-29), has been reverted in mainline so now when we specify

So, I applied this to -next as that's where it applies but it seems that
you're trying to revert a commit that's in Linus' tree so should go as a
fix to him.  Can you send a fix against Linus' tree too please?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/80d4ba8b/attachment.sig>

From arnd at arndb.de  Fri Feb 12 13:26:42 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 22:26:42 +0100
Subject: [PATCH] branch tracer: fix freak link error
Message-ID: <1455312410-1058841-1-git-send-email-arnd@arndb.de>

In my randconfig tests, I came across a bug that involves several
components:

* gcc-4.9 through at least 5.3
* CONFIG_GCOV_PROFILE_ALL enabling -fprofile-arcs for all files
* CONFIG_PROFILE_ALL_BRANCHES overriding every if()
* The optimized implementation of do_div() that tries to
  replace a library call with an division by multiplication
* code in drivers/media/dvb-frontends/zl10353.c doing

        u32 adc_clock = 450560; /* 45.056 MHz */
        if (state->config.adc_clock)
                adc_clock = state->config.adc_clock;
        do_div(value, adc_clock);

In this case, gcc fails to determine whether the divisor
in do_div() is __builtin_constant_p(). In particular, it
concludes that __builtin_constant_p(adc_clock) is false, while
__builtin_constant_p(!!adc_clock) is true.

That in turn throws off the logic in do_div() that also uses
__builtin_constant_p(), and instead of picking either the
constant- optimized division, and the code in ilog2() that uses
__builtin_constant_p() to figure out whether it knows the answer at
compile time. The result is a link error from failing to find
multiple symbols that should never have been called based on
the __builtin_constant_p():

dvb-frontends/zl10353.c:138: undefined reference to `____ilog2_NaN'
dvb-frontends/zl10353.c:138: undefined reference to `__aeabi_uldivmod'
ERROR: "____ilog2_NaN" [drivers/media/dvb-frontends/zl10353.ko] undefined!
ERROR: "__aeabi_uldivmod" [drivers/media/dvb-frontends/zl10353.ko] undefined!

This patch avoids the problem by changing __trace_if() to check
whether the condition is known at compile-time to be nonzero, rather
than checking whether it is actually a constant.

I see this one link error in roughly one out of 1600 randconfig builds
on ARM, and the patch fixes all known instances.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: ab3c9c686e22 ("branch tracer, intel-iommu: fix build with CONFIG_BRANCH_TRACER=y")
---
 include/linux/compiler.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index b5acbb404854..b5ff9881bef8 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -148,7 +148,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
  */
 #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
 #define __trace_if(cond) \
-	if (__builtin_constant_p((cond)) ? !!(cond) :			\
+	if (__builtin_constant_p(!!(cond)) ? !!(cond) :			\
 	({								\
 		int ______r;						\
 		static struct ftrace_branch_data			\
-- 
2.7.0



From broonie at kernel.org  Fri Feb 12 13:28:56 2016
From: broonie at kernel.org (Mark Brown)
Date: Fri, 12 Feb 2016 21:28:56 +0000
Subject: [PATCH] Revert "ASoC: qcom: Specify LE device endianness"
In-Reply-To: <4609707.AR30v8FONr@wuerfel>
References: <1455298217-15744-1-git-send-email-sboyd@codeaurora.org>
 <2686474.cvCA6vY47l@wuerfel> <20160212200311.GB11402@sirena.org.uk>
 <4609707.AR30v8FONr@wuerfel>
Message-ID: <20160212212856.GA18988@sirena.org.uk>

On Fri, Feb 12, 2016 at 09:35:26PM +0100, Arnd Bergmann wrote:

> syscon is probably fine because it only sets that flag based on the
> "little-endian" DT property and I don't see anything setting that
> (except the one platform that did so incorrectly).

Though it should be able to remove that as the regmap code will also
parse the property.  Probably worth double checking that works as
intended though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/d83d1fdb/attachment.sig>

From nicolas.pitre at linaro.org  Fri Feb 12 13:38:53 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 12 Feb 2016 16:38:53 -0500 (EST)
Subject: [PATCH] [media] zl10353: use div_u64 instead of do_div
In-Reply-To: <6737272.LXr2g355Yt@wuerfel>
References: <1455287246-3540549-1-git-send-email-arnd@arndb.de>
 <2712691.b9gkR7KMX7@wuerfel>
 <alpine.LFD.2.20.1602121305180.13632@knanqh.ubzr>
 <6737272.LXr2g355Yt@wuerfel>
Message-ID: <alpine.LFD.2.20.1602121634040.13632@knanqh.ubzr>

On Fri, 12 Feb 2016, Arnd Bergmann wrote:

> On Friday 12 February 2016 13:21:33 Nicolas Pitre wrote:
> > This is all related to the gcc bug for which I produced a test case 
> > here:
> > 
> > http://article.gmane.org/gmane.linux.kernel.cross-arch/29801
> > 
> > Do you know if this is fixed in recent gcc?
> 
> I have a fairly recent gcc, but I also never got around to submit
> it properly.
> 
> However, I did stumble over an older patch I did now, which I could
> not remember what it was good for. It does fix the problem, and
> it seems to be a better solution.

WTF?

Hmmm... it apparently doesn't fix it if I apply this change to the gcc 
test case.


> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index b5acbb404854..b5ff9881bef8 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -148,7 +148,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
>   */
>  #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
>  #define __trace_if(cond) \
> -	if (__builtin_constant_p((cond)) ? !!(cond) :			\
> +	if (__builtin_constant_p(!!(cond)) ? !!(cond) :			\
>  	({								\
>  		int ______r;						\
>  		static struct ftrace_branch_data			\
> 
> 


From khilman at baylibre.com  Fri Feb 12 13:42:50 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Fri, 12 Feb 2016 13:42:50 -0800
Subject: mt1873-evb: MMC failing with linux-next
In-Reply-To: <56BE01D6.40908@gmail.com> (Matthias Brugger's message of "Fri,
 12 Feb 2016 17:01:26 +0100")
References: <7hegcmadfk.fsf@baylibre.com> <56BDF937.60208@gmail.com>
 <56BE01D6.40908@gmail.com>
Message-ID: <7h37sx1u79.fsf@baylibre.com>

Matthias Brugger <matthias.bgg at gmail.com> writes:

> On 12/02/16 16:24, Matthias Brugger wrote:
>> Hi Kevin,
>>
>> On 09/02/16 02:18, Kevin Hilman wrote:
>>> Hello,
>>>
>>> I tried getting MMC working with linux-next (next-20160208) on
>>> mt8173-evb by enabling a few options[1] on top of the default defconfig,
>>> and this results in a kernel that hangs as soon as it starts userspace.
>>>
>>> The MMC driver seems to start, though has some regulator issues:
>>>
>>> [    0.526380] sdhci: Secure Digital Host Controller Interface driver
>>> [    0.527176] sdhci: Copyright(c) Pierre Ossman
>>> [    0.528835] vio18: unsupportable voltage range: 3300000-1980000uV
>>> [    0.529610] mtk-msdc 11230000.mmc: Regulator set error -22:
>>> 3300000 - 3300000
>>> [    0.563731] mtk-msdc 11240000.mmc: Got CD GPIO
>>>
>>> The driver appears to be attempting to set 3.3V but using a 1.8V
>>> regulator (vio18), which is failing.
>>>
>>> Then, the kernel hangs after freeing unused memory:
>>>
>>> [    0.616386] hctosys: unable to open rtc device (rtc0)
>>> [    0.624118] usb_vbus: disabling
>>> [    0.624547] vusb: disabling
>>> [    0.624929] vgp6: disabling
>>> [    0.625635] ALSA device list:
>>> [    0.626009]   No soundcards found.
>>> [    0.626963] Freeing unused kernel memory: 724K (ffffffc000977000 -
>>> ffffffc000a2c000)
>>>
>>> And nothing further here.
>>>
>>
>> I can see the warning from the mmc regulator access, but after that my
>> board boots just fine.
>> I'm using linux-next as of today (20160212).
>> I attached my config, it should be defconfig plus the config options you
>> mentioned (and an initramfs).
>>
>> Is this the configuration you have?
>
> I spotted an error in my scripts to build the kernel. After fixing
> this I can reproduce your error.

OK, let me know if you need anything else to help debug, or want me to
test anything further.  Otherwise I'll leave it in your capable hands.

Kevin


From tony at atomide.com  Fri Feb 12 13:44:08 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Feb 2016 13:44:08 -0800
Subject: [RESEND PATCH v4 0/4] ARM: dts: use syscon property instead of
 ctrl-module
In-Reply-To: <1450689201-16973-1-git-send-email-kishon@ti.com>
References: <1450689201-16973-1-git-send-email-kishon@ti.com>
Message-ID: <20160212214408.GA19432@atomide.com>

* Kishon Vijay Abraham I <kishon at ti.com> [151221 01:13]:
> This series is basically to deprecate using ctrl-module property and use
> corresponding syscon properties to program the control module registers.

Applying into omap-for-v4.6/dt finally, thanks!

Tony


From nicolas.pitre at linaro.org  Fri Feb 12 13:45:03 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 12 Feb 2016 16:45:03 -0500 (EST)
Subject: [PATCH] branch tracer: fix freak link error
In-Reply-To: <1455312410-1058841-1-git-send-email-arnd@arndb.de>
References: <1455312410-1058841-1-git-send-email-arnd@arndb.de>
Message-ID: <alpine.LFD.2.20.1602121639340.13632@knanqh.ubzr>

On Fri, 12 Feb 2016, Arnd Bergmann wrote:

> In my randconfig tests, I came across a bug that involves several
> components:
> 
> * gcc-4.9 through at least 5.3
> * CONFIG_GCOV_PROFILE_ALL enabling -fprofile-arcs for all files
> * CONFIG_PROFILE_ALL_BRANCHES overriding every if()
> * The optimized implementation of do_div() that tries to
>   replace a library call with an division by multiplication
> * code in drivers/media/dvb-frontends/zl10353.c doing
> 
>         u32 adc_clock = 450560; /* 45.056 MHz */
>         if (state->config.adc_clock)
>                 adc_clock = state->config.adc_clock;
>         do_div(value, adc_clock);
> 
> In this case, gcc fails to determine whether the divisor
> in do_div() is __builtin_constant_p(). In particular, it
> concludes that __builtin_constant_p(adc_clock) is false, while
> __builtin_constant_p(!!adc_clock) is true.
> 
> That in turn throws off the logic in do_div() that also uses
> __builtin_constant_p(), and instead of picking either the
> constant- optimized division, and the code in ilog2() that uses
> __builtin_constant_p() to figure out whether it knows the answer at
> compile time. The result is a link error from failing to find
> multiple symbols that should never have been called based on
> the __builtin_constant_p():
> 
> dvb-frontends/zl10353.c:138: undefined reference to `____ilog2_NaN'
> dvb-frontends/zl10353.c:138: undefined reference to `__aeabi_uldivmod'
> ERROR: "____ilog2_NaN" [drivers/media/dvb-frontends/zl10353.ko] undefined!
> ERROR: "__aeabi_uldivmod" [drivers/media/dvb-frontends/zl10353.ko] undefined!
> 
> This patch avoids the problem by changing __trace_if() to check
> whether the condition is known at compile-time to be nonzero, rather
> than checking whether it is actually a constant.
> 
> I see this one link error in roughly one out of 1600 randconfig builds
> on ARM, and the patch fixes all known instances.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: ab3c9c686e22 ("branch tracer, intel-iommu: fix build with CONFIG_BRANCH_TRACER=y")

It is certainly a worthwhile workaround if it solves all the known 
cases.

Acked-by: Nicolas Pitre <nico at linaro.org>

This trick doesn't work with the test case I produced to demonstrate 
this bug though.  So we might be affected again in the future, or maybe 
not if we're lucky.


> ---
>  include/linux/compiler.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index b5acbb404854..b5ff9881bef8 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -148,7 +148,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
>   */
>  #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
>  #define __trace_if(cond) \
> -	if (__builtin_constant_p((cond)) ? !!(cond) :			\
> +	if (__builtin_constant_p(!!(cond)) ? !!(cond) :			\
>  	({								\
>  		int ______r;						\
>  		static struct ftrace_branch_data			\
> -- 
> 2.7.0
> 
> 


From arnd at arndb.de  Fri Feb 12 13:45:34 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 22:45:34 +0100
Subject: [PATCH] [media] zl10353: use div_u64 instead of do_div
In-Reply-To: <alpine.LFD.2.20.1602121634040.13632@knanqh.ubzr>
References: <1455287246-3540549-1-git-send-email-arnd@arndb.de>
 <6737272.LXr2g355Yt@wuerfel>
 <alpine.LFD.2.20.1602121634040.13632@knanqh.ubzr>
Message-ID: <5158925.0PEQLt1vYj@wuerfel>

On Friday 12 February 2016 16:38:53 Nicolas Pitre wrote:
> On Fri, 12 Feb 2016, Arnd Bergmann wrote:
> 
> > On Friday 12 February 2016 13:21:33 Nicolas Pitre wrote:
> > > This is all related to the gcc bug for which I produced a test case 
> > > here:
> > > 
> > > http://article.gmane.org/gmane.linux.kernel.cross-arch/29801
> > > 
> > > Do you know if this is fixed in recent gcc?
> > 
> > I have a fairly recent gcc, but I also never got around to submit
> > it properly.
> > 
> > However, I did stumble over an older patch I did now, which I could
> > not remember what it was good for. It does fix the problem, and
> > it seems to be a better solution.
> 
> WTF?

Even better, it also fixes this one:

drivers/mtd/chips/cfi_cmdset_0020.c: In function 'cfi_staa_write_buffers':
drivers/mtd/chips/cfi_cmdset_0020.c:651:1: error: the frame size of 1064 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

I have not even looked what that is, I only saw show up the other day.

	Arnd


From arnd at arndb.de  Fri Feb 12 13:49:07 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 22:49:07 +0100
Subject: [PATCH] branch tracer: fix freak link error
In-Reply-To: <alpine.LFD.2.20.1602121639340.13632@knanqh.ubzr>
References: <1455312410-1058841-1-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602121639340.13632@knanqh.ubzr>
Message-ID: <3016048.Uym15Ei2Bs@wuerfel>

On Friday 12 February 2016 16:45:03 Nicolas Pitre wrote:
> 
> It is certainly a worthwhile workaround if it solves all the known 
> cases.
> 
> Acked-by: Nicolas Pitre <nico at linaro.org>
> 
> This trick doesn't work with the test case I produced to demonstrate 
> this bug though.  So we might be affected again in the future, or maybe 
> not if we're lucky.

Yes, I think it's clear that there is still something interesting going
on with the compiler and nested __builtin_compatible_p().

I'm currently creating a couple of gcc bug reports and plan to finally submit
this one as well.

Now I have to check if it does anything to the spurious "maybe-uninitialized"
warnings that I saw creeping in with PROFILE_ALL_BRANCHES. My guess is
that it doesn't fix them (I submitted a patch to turn off those
warnings today when PROFILE_ALL_BRANCHES is set), but I'll try anyway.

	Arnd


From arnd at arndb.de  Fri Feb 12 13:52:10 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 22:52:10 +0100
Subject: [PATCH] branch tracer: fix freak link error
In-Reply-To: <3016048.Uym15Ei2Bs@wuerfel>
References: <1455312410-1058841-1-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602121639340.13632@knanqh.ubzr>
 <3016048.Uym15Ei2Bs@wuerfel>
Message-ID: <6132207.AQ6oOdTfsj@wuerfel>

On Friday 12 February 2016 22:49:07 Arnd Bergmann wrote:
> Now I have to check if it does anything to the spurious "maybe-uninitialized"
> warnings that I saw creeping in with PROFILE_ALL_BRANCHES. My guess is
> that it doesn't fix them (I submitted a patch to turn off those
> warnings today when PROFILE_ALL_BRANCHES is set), but I'll try anyway. 

Ok, that was easy: they are all still there, so we still need to
pass -Wno-maybe-uninitialized when using PROFILE_ALL_BRANCHES to
avoid flooding the log with useless warnings.

	Arnd


From tony at atomide.com  Fri Feb 12 13:53:26 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Feb 2016 13:53:26 -0800
Subject: [PATCH] ARM: dts: omap3-n900: Allow gpio keys to be disabled
In-Reply-To: <1452447990-22775-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
References: <1452447990-22775-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
Message-ID: <20160212215326.GD19432@atomide.com>

* Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com> [160110 09:47]:
> Add linux,can-disable; to all gpios exported from gpio-keys driver, so
> userspace can disable them
...
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -68,6 +68,7 @@
>  			linux,input-type = <EV_SW>;
>  			linux,code = <SW_CAMERA_LENS_COVER>;
>  			gpio-key,wakeup;
> +			linux,can-disable;
>  		};
>  
>  		camera_focus {

Looks like this no longer applies because of linux,can-disable
to wakeup-source changes. Can you please update against v4.5-rc
series and repost?

Thanks,

Tony


From broonie at kernel.org  Fri Feb 12 13:54:28 2016
From: broonie at kernel.org (Mark Brown)
Date: Fri, 12 Feb 2016 21:54:28 +0000
Subject: [PATCH] coresight: etb: Remove simple announcement message
In-Reply-To: <CANLsYkwVn4FgBST-0MeOa38qCkH78-z32_CXewcCF78CnvbxeQ@mail.gmail.com>
References: <1455195004-30214-1-git-send-email-broonie@kernel.org>
 <CANLsYkwVn4FgBST-0MeOa38qCkH78-z32_CXewcCF78CnvbxeQ@mail.gmail.com>
Message-ID: <20160212215428.GB18988@sirena.org.uk>

On Fri, Feb 12, 2016 at 01:44:31PM -0700, Mathieu Poirier wrote:
> On 11 February 2016 at 05:50, Mark Brown <broonie at kernel.org> wrote:

> > -       dev_info(dev, "ETB initialized\n");
> >         return 0;

> Didn't we touch base on that topic before?  I'm not against moving

We did and you said that there was a patch pending which would change it
to print something useful but the patch still applies so I guess that
didn't happen.

> forward with this but it has to be all or nothing - whether we remove
> all the CS boot log message or they all stay.  Otherwise people could
> mistakenly come to the conclusion that some of the CS components did
> not boot properly.

> ETB, funnel and TMCs don't output any useful HW related information
> but tracers (ETMv3, PTM and ETMv4) actually do.

I think people are familiar enough with the general policy on this stuff
to be able to cope with this, it's certainly not something that's ever
come up with ASoC where we do have a similar multi-device structure.

> People concerned about boot time will definitely set their loglevel
> accordingly on the kernel cmd line.  Otherwise we are likely talking
> about developers interested in knowing what happened when their kernel
> booted.

That applies equally to all drivers so from that point of view we should
be doing something in the driver core - there is actually some logging
there that can be enabled, though it's not that widely used.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/4aa128c5/attachment.sig>

From sboyd at codeaurora.org  Fri Feb 12 14:04:54 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 12 Feb 2016 14:04:54 -0800
Subject: [PATCH] Revert "ASoC: qcom: Specify LE device endianness"
In-Reply-To: <20160212212600.GA18872@sirena.org.uk>
References: <1455298217-15744-1-git-send-email-sboyd@codeaurora.org>
 <20160212212600.GA18872@sirena.org.uk>
Message-ID: <20160212220454.GF4847@codeaurora.org>

On 02/12, Mark Brown wrote:
> On Fri, Feb 12, 2016 at 09:30:17AM -0800, Stephen Boyd wrote:
> > This reverts commit 18560a4e3b07438113b50589e78532d95f907029.
> > 
> > The commit that caused us to specify LE device endianness here,
> > 29bb45f25ff3 (regmap-mmio: Use native endianness for read/write,
> > 2015-10-29), has been reverted in mainline so now when we specify
> 
> So, I applied this to -next as that's where it applies but it seems that
> you're trying to revert a commit that's in Linus' tree so should go as a
> fix to him.  Can you send a fix against Linus' tree too please?

Did you want me to send the fix directly to Linus? The patch
applies to both -next and Linus' tree, although you're right I
generated this patch against -next. If I apply it to Linus' tree
and then git format-patch it's exactly the same except for the
commit hash:

$ diff linus next
1c1
< From 4f7c654bfcd159b3068b01e3b522e8af88069cb9 Mon Sep 17 00:00:00 2001
---
> From 798212b523668d5a37a977c660554827aa0d89ed Mon Sep 17 00:00:00 2001

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From tony at atomide.com  Fri Feb 12 14:07:18 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Feb 2016 14:07:18 -0800
Subject: [PATCH 2/2] ARM: dts: am33xx: add support for Ka-Ro electronics
 TX48-7020 module
In-Reply-To: <CAOCHtYhHiQmueqdxcvA48iC64eqq+Ey2gKNuwZjxaMYKeWPB-Q@mail.gmail.com>
References: <1453292992-1788-1-git-send-email-LW@KARO-electronics.de>
 <1453292992-1788-3-git-send-email-LW@KARO-electronics.de>
 <CAOCHtYhHiQmueqdxcvA48iC64eqq+Ey2gKNuwZjxaMYKeWPB-Q@mail.gmail.com>
Message-ID: <20160212220718.GK19432@atomide.com>

* Robert Nelson <robertcnelson at gmail.com> [160120 08:34]:
> > +
> > +&am33xx_pinmux {
> > +       cpsw_default: cpsw_default {
> > +               pinctrl-single,pins = <
> > +                       /* Slave 1 */
> > +                       0x10c (PIN_INPUT_PULLDOWN | MUX_MODE1)  /* mii1_crs.rmii1_crs_dv */
> > +                       0x110 (PIN_INPUT_PULLDOWN | MUX_MODE1)  /* mii1_rxerr.rmii1_rxerr */
> > +                       0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* mii1_txen.rmii1_txen */
> > +                       0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* mii1_txd1.rmii1_txd1 */
> > +                       0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE1) /* mii1_txd0.rmii1_txd0 */
> > +                       0x13c (PIN_INPUT_PULLDOWN | MUX_MODE1)  /* mii1_rxd1.rmii1_rxd1 */
> > +                       0x140 (PIN_INPUT_PULLDOWN | MUX_MODE1)  /* mii1_rxd0.rmii1_rxd0 */
> > +                       0x144 (PIN_INPUT | SLEWCTRL_FAST | MUX_MODE0)   /* rmii1_ref_clk.rmii1_refclk */
> > +                       0x1e4 (PIN_INPUT_PULLUP | MUX_MODE7)    /* emu0.gpio3_7 */
> > +                       0x1e8 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* emu1.gpio3_8 */
> 
> please go thru and convert these all to use the AM33XX_IOPAD macro..
> 
> All the boards have been converted for the 4.5.0-rc0 merge..
> 
> example:
> 
> https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/commit/?h=for-next&id=df10eadfce3510c2814e95d9f3d2d5d2c64eb26b

Yes and please send this separately from the regulator changes
if no dependency.

Regards,

Tony


From sboyd at codeaurora.org  Fri Feb 12 14:08:16 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Fri, 12 Feb 2016 14:08:16 -0800
Subject: [PATCH] Revert "ASoC: qcom: Specify LE device endianness"
In-Reply-To: <2686474.cvCA6vY47l@wuerfel>
References: <1455298217-15744-1-git-send-email-sboyd@codeaurora.org>
 <2686474.cvCA6vY47l@wuerfel>
Message-ID: <20160212220816.GG4847@codeaurora.org>

On 02/12, Arnd Bergmann wrote:
> 
> drivers/clk/qcom/gcc-apq8084.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
> drivers/clk/qcom/gcc-ipq806x.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
> drivers/clk/qcom/gcc-msm8660.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
> drivers/clk/qcom/gcc-msm8916.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
> drivers/clk/qcom/gcc-msm8960.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
> drivers/clk/qcom/gcc-msm8960.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
> drivers/clk/qcom/gcc-msm8974.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
> drivers/clk/qcom/lcc-ipq806x.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
> drivers/clk/qcom/lcc-msm8960.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,
> drivers/clk/qcom/mmcc-apq8084.c:        .val_format_endian = REGMAP_ENDIAN_LITTLE,
> drivers/clk/qcom/mmcc-msm8960.c:        .val_format_endian = REGMAP_ENDIAN_LITTLE,
> drivers/clk/qcom/mmcc-msm8960.c:        .val_format_endian = REGMAP_ENDIAN_LITTLE,
> drivers/clk/qcom/mmcc-msm8974.c:        .val_format_endian = REGMAP_ENDIAN_LITTLE,

These are taken care of.

> 
> drivers/nvmem/qfprom.c: .val_format_endian = REGMAP_ENDIAN_LITTLE,

I don't plan on reverting this one because it's only in -next. It
is redundant, but it's not actively breaking anything when the
driver tree and the regmap tree are merged together.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From rostedt at goodmis.org  Fri Feb 12 14:12:37 2016
From: rostedt at goodmis.org (Steven Rostedt)
Date: Fri, 12 Feb 2016 17:12:37 -0500
Subject: [PATCH] branch tracer: fix freak link error
In-Reply-To: <6132207.AQ6oOdTfsj@wuerfel>
References: <1455312410-1058841-1-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602121639340.13632@knanqh.ubzr>
 <3016048.Uym15Ei2Bs@wuerfel> <6132207.AQ6oOdTfsj@wuerfel>
Message-ID: <20160212171237.22d2d93e@gandalf.local.home>

On Fri, 12 Feb 2016 22:52:10 +0100
Arnd Bergmann <arnd at arndb.de> wrote:

> On Friday 12 February 2016 22:49:07 Arnd Bergmann wrote:
> > Now I have to check if it does anything to the spurious "maybe-uninitialized"
> > warnings that I saw creeping in with PROFILE_ALL_BRANCHES. My guess is
> > that it doesn't fix them (I submitted a patch to turn off those
> > warnings today when PROFILE_ALL_BRANCHES is set), but I'll try anyway.   
> 
> Ok, that was easy: they are all still there, so we still need to
> pass -Wno-maybe-uninitialized when using PROFILE_ALL_BRANCHES to
> avoid flooding the log with useless warnings.

Yeah, those warnings were the reason I turned PROFILE_ALL_BRANCHES into
a tristate and not a boolean, otherwise a make allmodconfig or
allyesconfig would enable it and spam the compile with those warnings.

I simply ignore them, so adding a way to turn them off when that is
enabled is probably a good idea.

-- Steve


From arnd at arndb.de  Fri Feb 12 14:18:56 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 12 Feb 2016 23:18:56 +0100
Subject: [PATCH] branch tracer: fix freak link error
In-Reply-To: <20160212171237.22d2d93e@gandalf.local.home>
References: <1455312410-1058841-1-git-send-email-arnd@arndb.de>
 <6132207.AQ6oOdTfsj@wuerfel> <20160212171237.22d2d93e@gandalf.local.home>
Message-ID: <2986179.BoCBGAiP5D@wuerfel>

On Friday 12 February 2016 17:12:37 Steven Rostedt wrote:
> On Fri, 12 Feb 2016 22:52:10 +0100
> Arnd Bergmann <arnd at arndb.de> wrote:
> 
> > On Friday 12 February 2016 22:49:07 Arnd Bergmann wrote:
> > > Now I have to check if it does anything to the spurious "maybe-uninitialized"
> > > warnings that I saw creeping in with PROFILE_ALL_BRANCHES. My guess is
> > > that it doesn't fix them (I submitted a patch to turn off those
> > > warnings today when PROFILE_ALL_BRANCHES is set), but I'll try anyway.   
> > 
> > Ok, that was easy: they are all still there, so we still need to
> > pass -Wno-maybe-uninitialized when using PROFILE_ALL_BRANCHES to
> > avoid flooding the log with useless warnings.
> 
> Yeah, those warnings were the reason I turned PROFILE_ALL_BRANCHES into
> a tristate and not a boolean, otherwise a make allmodconfig or
> allyesconfig would enable it and spam the compile with those warnings.
> 
> I simply ignore them, so adding a way to turn them off when that is
> enabled is probably a good idea.

Ok. The series I sent today was titled "[PATCH 0/5] gcov fixes and
maybe-uninitialized warnings", and I disable the warnings for
both GCOV_PROFILE_ALL and PROFILE_ALL_BRANCHES there, along with
CC_OPTIMIZE_FOR_SIZE and UBSAN_SANITIZE_ALL that already do that
today.

The patch series also makes sure that all four options are disabled
in allmodconfig (today they are disabled because of CC_OPTIMIZE_FOR_SIZE)
and the remaining warnings I get in both allmodconfig and randconfig
are finally useful.

	Arnd


From tony at atomide.com  Fri Feb 12 14:21:45 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Feb 2016 14:21:45 -0800
Subject: [PATCH 0/3] arm: dts: DRA7: Add IVA and DSPEVE thermal domain data
In-Reply-To: <20160209215210.GB27284@localhost.localdomain>
References: <1454922990-7501-1-git-send-email-j-keerthy@ti.com>
 <20160209215210.GB27284@localhost.localdomain>
Message-ID: <20160212222144.GN19432@atomide.com>

* Eduardo Valentin <edubezval at gmail.com> [160209 13:53]:
> On Mon, Feb 08, 2016 at 02:46:27PM +0530, Keerthy wrote:
> > OMAP5 has 3 thermal zones cpu, core and multimedia.
> > On the other hand DRA7 has 5 thermal zones cpu, gpu, core, dspeve
> > and iva. Currently cpu, core and multimedia are being added via dt
> > and the other 2 are getting added via kernel. Add the missing thermal
> > domains in dt so as give the correct trip numbers, type and temperatures.
> > 
> > Tested on DRA7-EVM.
> 
> For the series:
> 
> Acked-by: Eduardo Valentin <edubezval at gmail.com>

Applying all into omap-for-v4.6/dt thanks.

Tony


From tony at atomide.com  Fri Feb 12 14:23:48 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Feb 2016 14:23:48 -0800
Subject: [PATCH] arm: dts: AM57XX: Correct the thermal thresholds
In-Reply-To: <56BA6530.4030102@ti.com>
References: <1454924705-8382-1-git-send-email-j-keerthy@ti.com>
 <20160209220901.GC28102@localhost.localdomain>
 <56BA6530.4030102@ti.com>
Message-ID: <20160212222347.GO19432@atomide.com>

* Nishanth Menon <nm at ti.com> [160209 14:17]:
> On 02/09/2016 04:09 PM, Eduardo Valentin wrote:
> > On Mon, Feb 08, 2016 at 03:15:05PM +0530, Keerthy wrote:
> >> The thermal threholds for am57xx are different from that of dra7.
> >> Correcting the thresholds for the same.
> >>
> >> Signed-off-by: Keerthy <j-keerthy at ti.com>
> >> ---
> >>
> >> Depends on: https://lkml.org/lkml/2016/2/8/90
> >>
> >>  arch/arm/boot/dts/am57xx-beagle-x15.dts | 24 ++++++++++++++++++++++++
> >>  1 file changed, 24 insertions(+)
> >>
> >> Index: linux/arch/arm/boot/dts/am57xx-beagle-x15.dts
> >> ===================================================================
> >> --- linux.orig/arch/arm/boot/dts/am57xx-beagle-x15.dts	2016-02-08 14:57:05.514959101 +0530
> >> +++ linux/arch/arm/boot/dts/am57xx-beagle-x15.dts	2016-02-08 14:57:05.510959168 +0530
> > 
> > Sorry, did not bother to check, but is this the only user of am57xx?
> 
> we will have AM57xx-IDK as well coming down the line. we already have
> arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> arch/arm/boot/dts/am57xx-sbc-am57x.dts - not really sure what grade of
> silicon are used in cl-SOM and sbc boards.

Hmm can this one wait for v4.6 or is it critical for v4.5-rc
cycle?

Regards,

Tony


From broonie at kernel.org  Fri Feb 12 14:25:56 2016
From: broonie at kernel.org (Mark Brown)
Date: Fri, 12 Feb 2016 22:25:56 +0000
Subject: [PATCH] Revert "ASoC: qcom: Specify LE device endianness"
In-Reply-To: <20160212220454.GF4847@codeaurora.org>
References: <1455298217-15744-1-git-send-email-sboyd@codeaurora.org>
 <20160212212600.GA18872@sirena.org.uk>
 <20160212220454.GF4847@codeaurora.org>
Message-ID: <20160212222556.GC18988@sirena.org.uk>

On Fri, Feb 12, 2016 at 02:04:54PM -0800, Stephen Boyd wrote:
> On 02/12, Mark Brown wrote:

> > So, I applied this to -next as that's where it applies but it seems that
> > you're trying to revert a commit that's in Linus' tree so should go as a
> > fix to him.  Can you send a fix against Linus' tree too please?

> Did you want me to send the fix directly to Linus? The patch
> applies to both -next and Linus' tree, although you're right I
> generated this patch against -next. If I apply it to Linus' tree
> and then git format-patch it's exactly the same except for the
> commit hash:

No, of course not!  Send it to me.  What I'm looking for is something
that I can apply - it doesn't apply to my current Qualcomm fixes branch.  
Looking again I see that the issue is that that branch is based on
v4.4, I pulled it over now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/24f8e8a8/attachment.sig>

From nm at ti.com  Fri Feb 12 14:30:50 2016
From: nm at ti.com (Nishanth Menon)
Date: Fri, 12 Feb 2016 16:30:50 -0600
Subject: [PATCH] arm: dts: AM57XX: Correct the thermal thresholds
In-Reply-To: <20160212222347.GO19432@atomide.com>
References: <1454924705-8382-1-git-send-email-j-keerthy@ti.com>
 <20160209220901.GC28102@localhost.localdomain>
 <56BA6530.4030102@ti.com> <20160212222347.GO19432@atomide.com>
Message-ID: <CAGo_u6r8-LJBWWrew0fV50Q+JnCxDj9PD57+9NoDm5TqCWL=jw@mail.gmail.com>

On Fri, Feb 12, 2016 at 4:23 PM, Tony Lindgren <tony at atomide.com> wrote:
> * Nishanth Menon <nm at ti.com> [160209 14:17]:
>> On 02/09/2016 04:09 PM, Eduardo Valentin wrote:
>> > On Mon, Feb 08, 2016 at 03:15:05PM +0530, Keerthy wrote:
>> >> The thermal threholds for am57xx are different from that of dra7.
>> >> Correcting the thresholds for the same.
>> >>
>> >> Signed-off-by: Keerthy <j-keerthy at ti.com>
>> >> ---
>> >>
>> >> Depends on: https://lkml.org/lkml/2016/2/8/90
>> >>
>> >>  arch/arm/boot/dts/am57xx-beagle-x15.dts | 24 ++++++++++++++++++++++++
>> >>  1 file changed, 24 insertions(+)
>> >>
>> >> Index: linux/arch/arm/boot/dts/am57xx-beagle-x15.dts
>> >> ===================================================================
>> >> --- linux.orig/arch/arm/boot/dts/am57xx-beagle-x15.dts     2016-02-08 14:57:05.514959101 +0530
>> >> +++ linux/arch/arm/boot/dts/am57xx-beagle-x15.dts  2016-02-08 14:57:05.510959168 +0530
>> >
>> > Sorry, did not bother to check, but is this the only user of am57xx?
>>
>> we will have AM57xx-IDK as well coming down the line. we already have
>> arch/arm/boot/dts/am57xx-cl-som-am57x.dts
>> arch/arm/boot/dts/am57xx-sbc-am57x.dts - not really sure what grade of
>> silicon are used in cl-SOM and sbc boards.
>
> Hmm can this one wait for v4.6 or is it critical for v4.5-rc
> cycle?

personally, I'd like to NAK this patch -> lack of reference
documentation, and guidance for various AM57xx boards in a generic
patch should probably be followed IMHO.
---
Regards,
Nishanth Menon


From broonie at kernel.org  Fri Feb 12 14:37:11 2016
From: broonie at kernel.org (Mark Brown)
Date: Fri, 12 Feb 2016 22:37:11 +0000
Subject: [PATCH v5 3/5] mtd: devices: m25p80: add support for mmap read
 request
In-Reply-To: <56BC1D3E.5020203@ti.com>
References: <1449807000-6457-1-git-send-email-vigneshr@ti.com>
 <1449807000-6457-4-git-send-email-vigneshr@ti.com>
 <20160209193616.GN13270@sirena.org.uk> <56BC1D3E.5020203@ti.com>
Message-ID: <20160212223711.GD18988@sirena.org.uk>

On Thu, Feb 11, 2016 at 11:03:50AM +0530, Vignesh R wrote:
> On 02/10/2016 01:06 AM, Mark Brown wrote:
> > On Fri, Dec 11, 2015 at 09:39:58AM +0530, Vignesh R wrote:

> >> +	if (spi_flash_read_supported(spi)) {
> >> +		struct spi_flash_read_message msg;
> >> +		int ret;

> > Looking at this I can't help but think that spi_flash_read() ought to
> > have the stub in rather than the caller.  But given that we're pretty
> > much only ever expecting one user I'm not 100% sure it actually matters.

> Well, my initial patch set passed long list of arguments to
> spi_flash_read(), but Brian suggested to use struct[1] in order to avoid
> unnecessary churn when things need changed in the API.

I don't see what that has to do with my point?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/b7807a46/attachment.sig>

From tony at atomide.com  Fri Feb 12 14:41:29 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Feb 2016 14:41:29 -0800
Subject: [PATCH] arm: dts: AM57XX: Correct the thermal thresholds
In-Reply-To: <CAGo_u6r8-LJBWWrew0fV50Q+JnCxDj9PD57+9NoDm5TqCWL=jw@mail.gmail.com>
References: <1454924705-8382-1-git-send-email-j-keerthy@ti.com>
 <20160209220901.GC28102@localhost.localdomain>
 <56BA6530.4030102@ti.com> <20160212222347.GO19432@atomide.com>
 <CAGo_u6r8-LJBWWrew0fV50Q+JnCxDj9PD57+9NoDm5TqCWL=jw@mail.gmail.com>
Message-ID: <20160212224129.GP19432@atomide.com>

* Nishanth Menon <nm at ti.com> [160212 14:32]:
> On Fri, Feb 12, 2016 at 4:23 PM, Tony Lindgren <tony at atomide.com> wrote:
> > * Nishanth Menon <nm at ti.com> [160209 14:17]:
> >> On 02/09/2016 04:09 PM, Eduardo Valentin wrote:
> >> > On Mon, Feb 08, 2016 at 03:15:05PM +0530, Keerthy wrote:
> >> >> The thermal threholds for am57xx are different from that of dra7.
> >> >> Correcting the thresholds for the same.
> >> >>
> >> >> Signed-off-by: Keerthy <j-keerthy at ti.com>
> >> >> ---
> >> >>
> >> >> Depends on: https://lkml.org/lkml/2016/2/8/90
> >> >>
> >> >>  arch/arm/boot/dts/am57xx-beagle-x15.dts | 24 ++++++++++++++++++++++++
> >> >>  1 file changed, 24 insertions(+)
> >> >>
> >> >> Index: linux/arch/arm/boot/dts/am57xx-beagle-x15.dts
> >> >> ===================================================================
> >> >> --- linux.orig/arch/arm/boot/dts/am57xx-beagle-x15.dts     2016-02-08 14:57:05.514959101 +0530
> >> >> +++ linux/arch/arm/boot/dts/am57xx-beagle-x15.dts  2016-02-08 14:57:05.510959168 +0530
> >> >
> >> > Sorry, did not bother to check, but is this the only user of am57xx?
> >>
> >> we will have AM57xx-IDK as well coming down the line. we already have
> >> arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> >> arch/arm/boot/dts/am57xx-sbc-am57x.dts - not really sure what grade of
> >> silicon are used in cl-SOM and sbc boards.
> >
> > Hmm can this one wait for v4.6 or is it critical for v4.5-rc
> > cycle?
> 
> personally, I'd like to NAK this patch -> lack of reference
> documentation, and guidance for various AM57xx boards in a generic
> patch should probably be followed IMHO.

OK let's wait for that then.

Regards,

Tony


From robert.moore at intel.com  Fri Feb 12 14:47:19 2016
From: robert.moore at intel.com (Moore, Robert)
Date: Fri, 12 Feb 2016 22:47:19 +0000
Subject: [PATCH v2 6/9] ACPI: add definition of DBG2 subtypes
In-Reply-To: <1455299022-11641-7-git-send-email-aleksey.makarov@linaro.org>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
 <1455299022-11641-7-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E37DA9BA10@ORSMSX112.amr.corp.intel.com>

OK, we'll take these for the next release of ACPICA.
Thanks,
Bob


> -----Original Message-----
> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
> Sent: Friday, February 12, 2016 9:44 AM
> To: linux-acpi at vger.kernel.org
> Cc: linux-serial at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; Aleksey Makarov; Russell King; Greg Kroah-
> Hartman; Rafael J . Wysocki; Leif Lindholm; Graeme Gregory; Al Stone;
> Christopher Covington; Moore, Robert; Zheng, Lv; Wysocki, Rafael J; Len
> Brown; devel at acpica.org
> Subject: [PATCH v2 6/9] ACPI: add definition of DBG2 subtypes
> 
> The recent version of Microsoft Debug Port Table 2 (DBG2) [1] specifies
> additional serial debug port subtypes.  These constants are also referred
> by Serial Port Console Redirection Table (SPCR) [2]
> 
> Add these constants.
> 
> [1] https://msdn.microsoft.com/en-
> us/library/windows/hardware/dn639131(v=vs.85).aspx
> [2] https://msdn.microsoft.com/en-
> us/library/windows/hardware/dn639132(v=vs.85).aspx
> 
> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> Tested-by: Christopher Covington <cov at codeaurora.org>
> ---
>  include/acpi/actbl2.h | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h index
> a4ef625..e9930ab 100644
> --- a/include/acpi/actbl2.h
> +++ b/include/acpi/actbl2.h
> @@ -371,6 +371,11 @@ struct acpi_dbg2_device {
> 
>  #define ACPI_DBG2_16550_COMPATIBLE  0x0000
>  #define ACPI_DBG2_16550_SUBSET      0x0001
> +#define ACPI_DBG2_ARM_PL011         0x0003
> +#define ACPI_DBG2_ARM_SBSA_32BIT    0x000d
> +#define ACPI_DBG2_ARM_SBSA_GENERIC  0x000e
> +#define ACPI_DBG2_ARM_DCC           0x000f
> +#define ACPI_DBG2_BCM2835           0x0010
> 
>  #define ACPI_DBG2_1394_STANDARD     0x0000
> 
> --
> 2.7.0



From tony at atomide.com  Fri Feb 12 14:50:18 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Feb 2016 14:50:18 -0800
Subject: [GIT PULL] omap fixes against v4.5-rc3
Message-ID: <20160212225018.GA3500@atomide.com>

The following changes since commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95:

  Linux 4.5-rc3 (2016-02-07 15:38:30 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.5/fixes-rc3-v2

for you to fetch changes up to cf26f1137333251f3515dea31f95775b99df0fd5:

  ARM: OMAP2+: Fix omap_device for module reload on PM runtime forbid (2016-02-12 08:56:52 -0800)

----------------------------------------------------------------
Few fixes for omaps against v4.5-rc3:

- Improve omap_device error message to tell driver writers what is
  wrong after commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM
  states at probe error and driver unbind"). There will be also a
  handful of driver related fixes also queued separately. But adding
  this error message makes it easy to fix any omap_device using
  drivers suffering from this issue so I think it's important to
  have.

- Also related to commit 5de85b9d57ab discussion, let's fix a bug
  where disabling PM runtime via sysfs will also cause the hardware
  state to be different from PM runtime state.

- Fix audio clocks for beagle-x15.

- Use wakeup-source instead of gpio-key,wakeup for the new entries
  that sneaked in during the merge window.

- Fix a legacy booting vs device tree based booting regression for
  n900 where the legacy user space expects to have the device
  revision available in /proc/atags also when booted with device
  tree.

----------------------------------------------------------------
Ivaylo Dimitrov (1):
      ARM: OMAP2+: Set system_rev from ATAGS for n900

Peter Ujfalusi (1):
      ARM: DTS: am57xx-beagle-x15: Select SYS_CLK2 for audio clocks

Sudeep Holla (1):
      ARM: dts: am335x/am57xx: replace gpio-key,wakeup with wakeup-source property

Tony Lindgren (2):
      ARM: OMAP2+: Improve omap_device error for driver writers
      ARM: OMAP2+: Fix omap_device for module reload on PM runtime forbid

 arch/arm/boot/dts/am335x-shc.dts          |  4 ++--
 arch/arm/boot/dts/am57xx-beagle-x15.dts   |  4 ++++
 arch/arm/boot/dts/am57xx-cl-som-am57x.dts |  2 +-
 arch/arm/mach-omap2/board-generic.c       | 22 +++++++++++++++++++++-
 arch/arm/mach-omap2/omap_device.c         | 14 +++++++++++++-
 5 files changed, 41 insertions(+), 5 deletions(-)


From rafael at kernel.org  Fri Feb 12 15:07:00 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Sat, 13 Feb 2016 00:07:00 +0100
Subject: [PATCH v2 3/9] ACPI: introduce acpi_table_parse2()
In-Reply-To: <1455299022-11641-4-git-send-email-aleksey.makarov@linaro.org>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
 <1455299022-11641-4-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <CAJZ5v0i2RCEEZwCN+Ran3Qmasn4yEk1rbfWkZ5QbEkUQWvaJ+g@mail.gmail.com>

On Fri, Feb 12, 2016 at 6:43 PM, Aleksey Makarov
<aleksey.makarov at linaro.org> wrote:
> The function acpi_table_parse() has some problems:
> 1 It can be called only from __init code
> 2 It does not pass any data to the handler
> 3 It just throws out the value returned from the handler

So why are those problems?

> These issues are addressed in this patch

How are they addressed?

Thanks,
Rafael


From rafael at kernel.org  Fri Feb 12 15:08:38 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Sat, 13 Feb 2016 00:08:38 +0100
Subject: [PATCH v2 3/9] ACPI: introduce acpi_table_parse2()
In-Reply-To: <20160212185130.GA10095@kroah.com>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
 <1455299022-11641-4-git-send-email-aleksey.makarov@linaro.org>
 <20160212185130.GA10095@kroah.com>
Message-ID: <CAJZ5v0ji3rR3HkC7BjygkqXxOrEn3qSKA42i1Rj9tBqZ71Dh+w@mail.gmail.com>

On Fri, Feb 12, 2016 at 7:51 PM, Greg Kroah-Hartman
<gregkh at linuxfoundation.org> wrote:
> On Fri, Feb 12, 2016 at 08:43:34PM +0300, Aleksey Makarov wrote:
>> The function acpi_table_parse() has some problems:
>> 1 It can be called only from __init code
>> 2 It does not pass any data to the handler
>> 3 It just throws out the value returned from the handler
>>
>> These issues are addressed in this patch
>
> Why not just fix acpi_table_parse(), like you have, and not add a new
> API call with a "2" at the end of it.  That seems crazy to try to
> maintain that level of apis.
>
> But I'm not the acpi maintainer(s), so it's their call...

The ACPI maintainer agrees.

Thanks,
Rafael


From khilman at baylibre.com  Fri Feb 12 15:14:04 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Fri, 12 Feb 2016 15:14:04 -0800
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
 (Ulf Hansson's message of "Thu, 4 Feb 2016 16:44:59 +0100")
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
Message-ID: <7hh9hdzflv.fsf@baylibre.com>

Ulf Hansson <ulf.hansson at linaro.org> writes:

> On 28 January 2016 at 17:33, Jon Hunter <jonathanh at nvidia.com> wrote:
>> Adds generic PM support to the PMC driver where the PM domains are
>> populated from device-tree and the PM domain consumer devices are
>> bound to their relevant PM domains via device-tree as well.
>>
>> Update the tegra_powergate_sequence_power_up() API so that internally
>> it calls the same tegra_powergate_xxx functions that are used by the
>> tegra generic power domain code for consistency.
>>
>> This is based upon work by Thierry Reding <treding at nvidia.com>
>> and Vince Hsu <vinceh at nvidia.com>.
>>
>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>

[...]

>> +static void tegra_powergate_disable_clocks(struct tegra_powergate *pg)
>> +{
>> +       unsigned int i;
>> +
>> +       for (i = 0; i < pg->num_clks; i++)
>> +               clk_disable_unprepare(pg->clks[i]);
>> +}
>> +
>> +static int tegra_powergate_enable_clocks(struct tegra_powergate *pg)
>> +{
>> +       unsigned int i;
>> +       int err;
>> +
>> +       for (i = 0; i < pg->num_clks; i++) {
>> +               err = clk_prepare_enable(pg->clks[i]);
>> +               if (err)
>> +                       goto out;
>> +       }
>> +
>> +       return 0;
>> +
>> +out:
>> +       while (i--)
>> +               clk_disable_unprepare(pg->clks[i]);
>> +
>> +       return err;
>> +}
>
> I have seen similar code around in other PM domains, dealing with
> enabling/disabling a *list* of clocks.
> Perhaps we should invent a new clock API that helps with this to
> prevents code duplication!?

What about the pm_clk_* API which was built for tracking clocks
associated with devices for runtime PM.

IOW, you could pm_clk_add(pg->pmc->dev, pg->clks[i]) and then your
_enable_clocks() would become pm_clk_suspend() an dyour
_disable_clocks() would become pm_clk_resume().

I might not be following the mapping between PMC and PGs though so not
sure pg->pmc->dev is the right struct device, but you get the idea.

Kevin


From kirill at shutemov.name  Fri Feb 12 15:15:10 2016
From: kirill at shutemov.name (Kirill A. Shutemov)
Date: Sat, 13 Feb 2016 01:15:10 +0200
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160212181640.4eabb85f@thinkpad>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
Message-ID: <20160212231510.GB15142@node.shutemov.name>

On Fri, Feb 12, 2016 at 06:16:40PM +0100, Gerald Schaefer wrote:
> On Fri, 12 Feb 2016 16:57:27 +0100
> Christian Borntraeger <borntraeger at de.ibm.com> wrote:
> 
> > On 02/12/2016 04:41 PM, Kirill A. Shutemov wrote:
> > > On Thu, Feb 11, 2016 at 08:57:02PM +0100, Gerald Schaefer wrote:
> > >> On Thu, 11 Feb 2016 21:09:42 +0200
> > >> "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> > >>
> > >>> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
> > >>>> Hi,
> > >>>>
> > >>>> Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
> > >>>> he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
> > >>>> review of the THP rework patches, which cannot be bisected, revealed
> > >>>> commit fecffad "s390, thp: remove infrastructure for handling splitting PMDs"
> > >>>> (and also similar commits for other archs).
> > >>>>
> > >>>> This commit removes the THP splitting bit and also the architecture
> > >>>> implementation of pmdp_splitting_flush(), which took care of the IPI for
> > >>>> fast_gup serialization. The commit message says
> > >>>>
> > >>>>     pmdp_splitting_flush() is not needed too: on splitting PMD we will do
> > >>>>     pmdp_clear_flush() + set_pte_at().  pmdp_clear_flush() will do IPI as
> > >>>>     needed for fast_gup
> > >>>>
> > >>>> The assumption that a TLB flush will also produce an IPI is wrong on s390,
> > >>>> and maybe also on other architectures, and I thought that this was actually
> > >>>> the main reason for having an arch-specific pmdp_splitting_flush().
> > >>>>
> > >>>> At least PowerPC and ARM also had an individual implementation of
> > >>>> pmdp_splitting_flush() that used kick_all_cpus_sync() instead of a TLB
> > >>>> flush to send the IPI, and those were also removed. Putting the arch
> > >>>> maintainers and mailing lists on cc to verify.
> > >>>>
> > >>>> On s390 this will break the IPI serialization against fast_gup, which
> > >>>> would certainly explain the random kernel crashes, please revert or fix
> > >>>> the pmdp_splitting_flush() removal.
> > >>>
> > >>> Sorry for that.
> > >>>
> > >>> I believe, the problem was already addressed for PowerPC:
> > >>>
> > >>> http://lkml.kernel.org/g/454980831-16631-1-git-send-email-aneesh.kumar at linux.vnet.ibm.com
> > >>>
> > >>> I think kick_all_cpus_sync() in arch-specific pmdp_invalidate() would do
> > >>> the trick, right?
> > >>
> > >> Hmm, not sure about that. After pmdp_invalidate(), a pmd_none() check in
> > >> fast_gup will still return false, because the pmd is not empty (at least
> > >> on s390). So I don't see spontaneously how it will help fast_gup to break
> > >> out to the slow path in case of THP splitting.
> > > 
> > > What pmdp_flush_direct() does in pmdp_invalidate()? It's hard to unwrap for me :-/
> > > Does it make the pmd !pmd_present()?
> > 
> > It uses the idte instruction, which in an atomic fashion flushes the associated
> > TLB entry and changes the value of the pmd entry to invalid. This comes from the
> > HW requirement to not  change a PTE/PMD that might be still in use, other than 
> > with special instructions that does the tlb handling and the invalidation together.
> 
> Correct, and it does _not_ make the pmd !pmd_present(), that would only be the
> case after a _clear_flush(). It only marks the pmd as invalid and flushes,
> so that it cannot generate a new TLB entry before the following pmd_populate(),
> but it keeps its other content. This is to fulfill the requirements outlined in
> the comment in mm/huge_memory.c before the call to pmdp_invalidate(). And
> independent from that comment, we would need such an _invalidate() or
> _clear_flush() on s390 before the pmd_populate() because of the HW details
> that Christian described.
> 
> Reading the comment again, I do now notice that it also says "mark the current
> pmd notpresent", which we cannot do w/o losing the huge and (formerly) splitting
> bits, but it also shouldn't be needed to provide the "single TLB guarantee" that
> is required from the comment. So, a pmd_present() check on s390 in this state
> would still return true. Not sure yet if this is a problem, need more thinking,
> this behavior was already present before the THP rework but maybe it was OK
> before and is not OK now.
> 
> At least for fast_gup this should not be a problem though.

I'm trying to wrap my head around the issue and I don't think missing
serialization with gup_fast is the cause -- we just don't need it
anymore.

Previously, __split_huge_page_splitting() required serialization against
gup_fast to make sure nobody can obtain new reference to the page after
__split_huge_page_splitting() returns. This was a way to stabilize page
references before starting to distribute them from head page to tail
pages.

With new refcounting, we don't care about this. Splitting PMD is now
decoupled from splitting underlying compound page. It's okay to get new
pins after split_huge_pmd(). To stabilize page references during
split_huge_page() we rely on setting up migration entries once all
pmds are split into page table entries.

The theory that serialization against gup_fast is not a root cause of the
crashes is consistent no crashes on arm64. Problem is somewhere else.
 
> > (It also does some some other magic to the attach_count, which might hold off
> > finish_arch_post_lock_switch while some flushing is happening, but this should
> > be unrelated here)
> > 
> > 
> > > I'm also confused by pmd_none() is equal to !pmd_present() on s390. Hm?
> > 
> > Don't know, Gerald or Martin?
> 
> The implementation frequently changes depending on how many new bits Martin
> needs to squeeze out :-)

One bit was freed up by the commit you've pointed to as a cause.
I wounder If it's possible that screw up something while removing it? I
don't see it, but who knows.

Could you check if revert of fecffad25458 helps?

And could you share how crashes looks like? I haven't seen backtraces yet.

> We don't have a _PAGE_PRESENT bit for pmds, so pmd_present() just checks if the
> entry is not empty. pmd_none() of course does the opposite, it checks if it is
> empty.

-- 
 Kirill A. Shutemov


From tchalamarla at caviumnetworks.com  Fri Feb 12 15:20:30 2016
From: tchalamarla at caviumnetworks.com (tchalamarla at caviumnetworks.com)
Date: Fri, 12 Feb 2016 15:20:30 -0800
Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536
Message-ID: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com>

From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>

Due to Errata in ThunderX, HOST_IRQ_STAT should be
cleared before leaving the interrupt handler.
The patch attempts to satisfy the need.

Changes from V1:
	- Rebased on top of libata/for-4.6
        - Moved ThunderX intr handler to new file

Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
---
 drivers/ata/Makefile        |  2 +-
 drivers/ata/ahci.c          |  3 ++
 drivers/ata/ahci.h          |  1 +
 drivers/ata/ahci_thunderx.c | 73 +++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 78 insertions(+), 1 deletion(-)
 create mode 100644 drivers/ata/ahci_thunderx.c

diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 1857952..a36e70d 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -2,7 +2,7 @@
 obj-$(CONFIG_ATA)		+= libata.o
 
 # non-SFF interface
-obj-$(CONFIG_SATA_AHCI)		+= ahci.o libahci.o
+obj-$(CONFIG_SATA_AHCI)		+= ahci.o libahci.o ahci_thunderx.o
 obj-$(CONFIG_SATA_ACARD_AHCI)	+= acard-ahci.o libahci.o
 obj-$(CONFIG_SATA_AHCI_PLATFORM) += ahci_platform.o libahci.o libahci_platform.o
 obj-$(CONFIG_SATA_FSL)		+= sata_fsl.o
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 546a369..76e310e 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1560,6 +1560,9 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 	if (ahci_broken_devslp(pdev))
 		hpriv->flags |= AHCI_HFLAG_NO_DEVSLP;
 
+	if (pdev->vendor == 0x177d && pdev->device == 0xa01c)
+		ahci_thunderx_init(&pdev->dev, hpriv);
+
 	/* save initial config */
 	ahci_pci_save_initial_config(pdev, hpriv);
 
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index 167ba7e..77ae20d 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -425,6 +425,7 @@ void ahci_print_info(struct ata_host *host, const char *scc_s);
 int ahci_host_activate(struct ata_host *host, struct scsi_host_template *sht);
 void ahci_error_handler(struct ata_port *ap);
 u32 ahci_handle_port_intr(struct ata_host *host, u32 irq_masked);
+void ahci_thunderx_init(struct device *dev, struct ahci_host_priv *hpriv);
 
 static inline void __iomem *__ahci_port_base(struct ata_host *host,
 					     unsigned int port_no)
diff --git a/drivers/ata/ahci_thunderx.c b/drivers/ata/ahci_thunderx.c
new file mode 100644
index 0000000..223e170
--- /dev/null
+++ b/drivers/ata/ahci_thunderx.c
@@ -0,0 +1,73 @@
+/*
+ * SATA glue for Cavium Thunder SOCs.
+ *
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2010-2016 Cavium Networks
+ *
+ */
+
+#include <linux/module.h>
+#include "ahci.h"
+#include "libata.h"
+
+static irqreturn_t ahci_thunderx_irq_intr(int irq, void *dev_instance)
+{
+	struct ata_host *host = dev_instance;
+	struct ahci_host_priv *hpriv;
+	unsigned int rc = 0;
+	void __iomem *mmio;
+	u32 irq_stat, irq_masked;
+	unsigned int handled = 1;
+
+	VPRINTK("ENTER\n");
+
+	hpriv = host->private_data;
+	mmio = hpriv->mmio;
+
+	/* sigh.  0xffffffff is a valid return from h/w */
+	irq_stat = readl(mmio + HOST_IRQ_STAT);
+	if (!irq_stat)
+		return IRQ_NONE;
+redo:
+
+	irq_masked = irq_stat & hpriv->port_map;
+
+	spin_lock(&host->lock);
+
+	rc = ahci_handle_port_intr(host, irq_masked);
+
+	if (!rc)
+		handled = 0;
+
+	writel(irq_stat, mmio + HOST_IRQ_STAT);
+
+	/* Due to ERRATA#22536, ThunderX need to handle
+	 * HOST_IRQ_STAT differently.
+	 * Work around is to make sure all pending IRQs
+	 * are served before leaving handler
+	 */
+	irq_stat = readl(mmio + HOST_IRQ_STAT);
+
+	spin_unlock(&host->lock);
+
+	if (irq_stat)
+		goto redo;
+
+	VPRINTK("EXIT\n");
+
+	return IRQ_RETVAL(handled);
+}
+
+void ahci_thunderx_init(struct device *dev, struct ahci_host_priv *hpriv)
+{
+	hpriv->irq_handler = ahci_thunderx_irq_intr;
+}
+EXPORT_SYMBOL_GPL(ahci_thunderx_init);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Cavium, Inc. <support at cavium.com>");
+MODULE_DESCRIPTION("Cavium Inc. ThunderX sata config.");
-- 
2.1.0



From robert.jarzmik at free.fr  Fri Feb 12 15:49:20 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat, 13 Feb 2016 00:49:20 +0100
Subject: [PATCH] ARM: dts: pxa: fix dma engine node to pxa3xx-nand
Message-ID: <1455320960-10121-1-git-send-email-robert.jarzmik@free.fr>

Since the switch from mmp_pdma to pxa_dma driver for pxa architectures,
the pxa_dma requires 2 arguments, namely the requestor line and the
requested priority.

Fix the only left device node which was still passing only one argument,
making the pxa3xx-nand driver misbehave in a device-tree configuration,
ie. failing all data transfers.

Fixes: c943646d1f49 ("ARM: dts: pxa: add dma engine node to pxa3xx-nand")
Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
 arch/arm/boot/dts/pxa3xx.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/pxa3xx.dtsi b/arch/arm/boot/dts/pxa3xx.dtsi
index bea454f50ff9..fec47bcd8292 100644
--- a/arch/arm/boot/dts/pxa3xx.dtsi
+++ b/arch/arm/boot/dts/pxa3xx.dtsi
@@ -31,7 +31,7 @@
 			reg = <0x43100000 90>;
 			interrupts = <45>;
 			clocks = <&clks CLK_NAND>;
-			dmas = <&pdma 97>;
+			dmas = <&pdma 97 3>;
 			dma-names = "data";
 			#address-cells = <1>;
 			#size-cells = <1>;	
-- 
2.1.4



From f.fainelli at gmail.com  Fri Feb 12 15:50:40 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Fri, 12 Feb 2016 15:50:40 -0800
Subject: [PATCH 0/6] More updates for NS2 DT
In-Reply-To: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
References: <1455084651-29325-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <56BE6FD0.3010103@gmail.com>

On 09/02/16 22:10, Anup Patel wrote:
> This patchset primarily adds more DT nodes for NS2 SVK. It also does
> minor update to arch/arm64/Kconfig.platforms and adds missing DT
> bindings document for sp805 driver.
> 
> The patchset is based on v4.5-rc3 tag and is available in ns2_dt2_v1
> branch of https://github.com/Broadcom/arm64-linux.git
> 
> All patches have been tested on Broadcom NS2 SVK.
> 
> Anup Patel (5):
>   arm64: Select COMMON_CLK_IPROC, PINCTRL and GPIOLIB for iProc SoCs
>   arm64: dts: Add SDHCI DT node for NS2
>   arm64: dts: Add ARM SP804 timer DT nodes for NS2
>   dt-bindings: watchdog: Add ARM SP805 DT bindings
>   arm64: dts: Add ARM SP805 watchdog DT node for NS2
> 
> Ray Jui (1):
>   arm64: dts: Add PCIe0 and PCIe4 DT nodes for NS2

Patch 1 applied to soc-arm64/next

Patch 2-6 applied to devicetree-arm64/next, with Rob's Acked-by and the
suggested rename from wdt@ to watchdog@ that he recommended, thanks
everyone!
-- 
Florian


From f.fainelli at gmail.com  Fri Feb 12 15:55:54 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Fri, 12 Feb 2016 15:55:54 -0800
Subject: [PATCH 0/5] ARM: dts: NSP: DT Updates
In-Reply-To: <1454712204-30419-1-git-send-email-jonmason@broadcom.com>
References: <1454712204-30419-1-git-send-email-jonmason@broadcom.com>
Message-ID: <56BE710A.7000403@gmail.com>

On 05/02/16 14:43, Jon Mason wrote:
> Northstar Plus device tree changes.  The first 2 are bug fixes that
> probably should go in ASAP.  The other 3 enable new hardware and can be
> pushed into the next merge window.

Series applied to devicetree/next, with the update to the last patch
based on Sergei's comment, and I took the v2 of patch 4.

Thanks everyone.
-- 
Florian


From tony at atomide.com  Fri Feb 12 16:26:43 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Feb 2016 16:26:43 -0800
Subject: GPIO regression in Linux next caused by syscon change
Message-ID: <20160213002643.GQ19432@atomide.com>

Hi,

Looks like commit effe02710335 ("mfd: syscon: Set regmap max_register
in of_syscon_register") somehow breaks smsc911x GPIO interrupt for
me at least on omap3:

irq 241: nobody cared (try booting with the "irqpoll" option)
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc3-next-20160212 #864
Hardware name: Generic OMAP36xx (Flattened Device Tree)
[<c010fd44>] (unwind_backtrace) from [<c010c094>] (show_stack+0x10/0x14)
[<c010c094>] (show_stack) from [<c045f24c>] (dump_stack+0xb0/0xe4)
[<c045f24c>] (dump_stack) from [<c01998e8>] (__report_bad_irq+0x24/0xc0)
[<c01998e8>] (__report_bad_irq) from [<c0199ce4>] (note_interrupt+0x27c/0x2dc)
[<c0199ce4>] (note_interrupt) from [<c0197220>] (handle_irq_event_percpu+0x184/0x200)
[<c0197220>] (handle_irq_event_percpu) from [<c01972d4>] (handle_irq_event+0x38/0x5c)
[<c01972d4>] (handle_irq_event) from [<c019a3d8>] (handle_level_irq+0xc0/0x154)
[<c019a3d8>] (handle_level_irq) from [<c0196784>] (generic_handle_irq+0x20/0x34)
[<c0196784>] (generic_handle_irq) from [<c049b690>] (omap_gpio_irq_handler+0x120/0x160)
[<c049b690>] (omap_gpio_irq_handler) from [<c01970f0>] (handle_irq_event_percpu+0x54/0x200)
[<c01970f0>] (handle_irq_event_percpu) from [<c01972d4>] (handle_irq_event+0x38/0x5c)
[<c01972d4>] (handle_irq_event) from [<c019a3d8>] (handle_level_irq+0xc0/0x154)
[<c019a3d8>] (handle_level_irq) from [<c0196784>] (generic_handle_irq+0x20/0x34)
[<c0196784>] (generic_handle_irq) from [<c0196a78>] (__handle_domain_irq+0x64/0xe0)
[<c0196a78>] (__handle_domain_irq) from [<c076f038>] (__irq_svc+0x58/0x78)
[<c076f038>] (__irq_svc) from [<c076e93c>] (_raw_spin_unlock_irqrestore+0x34/0x44)
[<c076e93c>] (_raw_spin_unlock_irqrestore) from [<c019900c>] (__setup_irq+0x40c/0x5e0)
[<c019900c>] (__setup_irq) from [<c0199330>] (request_threaded_irq+0xc0/0x158)
[<c0199330>] (request_threaded_irq) from [<c05a4038>] (smsc911x_drv_probe+0x588/0xfec)
[<c05a4038>] (smsc911x_drv_probe) from [<c04fc1b4>] (platform_drv_probe+0x4c/0xb0)
[<c04fc1b4>] (platform_drv_probe) from [<c04fa89c>] (driver_probe_device+0x208/0x2c0)
[<c04fa89c>] (driver_probe_device) from [<c04fa9e8>] (__driver_attach+0x94/0x98)
[<c04fa9e8>] (__driver_attach) from [<c04f8bc4>] (bus_for_each_dev+0x6c/0xa0)
[<c04f8bc4>] (bus_for_each_dev) from [<c04f9d28>] (bus_add_driver+0x18c/0x214)
[<c04f9d28>] (bus_add_driver) from [<c04fb22c>] (driver_register+0x78/0xf8)
[<c04fb22c>] (driver_register) from [<c010180c>] (do_one_initcall+0x80/0x1dc)
[<c010180c>] (do_one_initcall) from [<c0b00ef0>] (kernel_init_freeable+0x218/0x2ec)
[<c0b00ef0>] (kernel_init_freeable) from [<c0768360>] (kernel_init+0x8/0xf4)
[<c0768360>] (kernel_init) from [<c01078d0>] (ret_from_fork+0x14/0x24)
handlers:
[<c05a26d8>] smsc911x_irqhandler
Disabling IRQ #241
libphy: smsc911x-mdio: probed

I'm not seeing the connection between regmap and  GPIO, so no
idea what goes wrong here.

Regards,

Tony


From eric at anholt.net  Fri Feb 12 16:28:54 2016
From: eric at anholt.net (Eric Anholt)
Date: Fri, 12 Feb 2016 16:28:54 -0800
Subject: [PATCH V4 1/7] clk: bcm2835: the minimum clock divider is 2
In-Reply-To: <56B86DDF.7060904@martin.sperl.org>
References: <1452867667-2447-1-git-send-email-kernel@martin.sperl.org>
 <1452867667-2447-2-git-send-email-kernel@martin.sperl.org>
 <87oac03tuz.fsf@eliezer.anholt.net> <56B86DDF.7060904@martin.sperl.org>
Message-ID: <871t8h312x.fsf@eliezer.anholt.net>

Martin Sperl <kernel at martin.sperl.org> writes:

> On 02.02.2016 00:15, Eric Anholt wrote:
>> kernel at martin.sperl.org writes:
>>
>>> From: Martin Sperl <kernel at martin.sperl.org>
>>>
>>> Testing with different clock divider values has shown
>>> that (at least for the PCM clock) the clock divider
>>> has to be at least 2, otherwise the clock will not
>>> output a signal.
>>
>> For a MASH clock (PWM, PCM, SLIMBUS, but not the others), the minimum
>> integer component of the divider is:
>>
>> mash 0: 1
>> mash 1: 2
>> mash 2: 3
>> mash 3: 5
>>
>
> I know that that is what the datasheet says - see also the errata:
> http://elinux.org/BCM2835_datasheet_errata#p105_table.
>
> Experimentation has show that a divider between 1 and 1 + 4095 / 4096
> does not provide any output PCM clock - only 2 and above does work for
> mash = 0, 1, 2 or 3.
>
> Example: Requesting 12288000Hz (=192kHz at 64bit) with the 19.2Mhz
> oscillator results in a divider of: 1 + 2304 / 4096 and this does not
> give a clock output.
>
> See the report by hiassoft here:
> https://github.com/raspberrypi/linux/issues/1231#issuecomment-171003182
> (note that it also applies to mash = 0, but there may be no comment on
> this fact in this thread)
>
> Note that there is patch 7 that implements the above "mash" limits
> for a divider and downgrades to a lower mash level if the divider
> does not qualify.

I do see "2, 2, 3, 5" being used as the minimum dividers used for mash
clocks in the firmware's clock setup.  So, as long as you limit this to
the MASH clocks, I think you're right.

What I'd expect of this series as a respin:

1) Fix setup of existing MASH clocks
- Mark the few existing MASH clocks as being MASH.
- Apply MASH integer divider limits to MASH clocks.
- Set the MASH field on MASH clocks.

2) Add PCM clock

If you want to add some other clocks that are definitely the same kinds
of clock generators and where we have known parents for them, that's
fine with me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/c593ef2b/attachment.sig>

From david.brown at linaro.org  Fri Feb 12 16:31:47 2016
From: david.brown at linaro.org (David Brown)
Date: Fri, 12 Feb 2016 17:31:47 -0700
Subject: [kernel-hardening] [PATCH] arm64: vdso: Mark vDSO code as
 read-only
In-Reply-To: <CAKv+Gu8ArOYqxDGKb=Tv3NsiB2qWWCdD_zMx55m6+hEwLJR4CA@mail.gmail.com>
References: <1455141142-6838-1-git-send-email-david.brown@linaro.org>
 <CAKv+Gu8ArOYqxDGKb=Tv3NsiB2qWWCdD_zMx55m6+hEwLJR4CA@mail.gmail.com>
Message-ID: <20160213003147.GA12074@davidb.org>

On Thu, Feb 11, 2016 at 03:19:20PM +0100, Ard Biesheuvel wrote:

>> diff --git a/arch/arm64/kernel/vdso/vdso.S b/arch/arm64/kernel/vdso/vdso.S
>> index 60c1db5..db7c0f2 100644
>> --- a/arch/arm64/kernel/vdso/vdso.S
>> +++ b/arch/arm64/kernel/vdso/vdso.S
>> @@ -24,6 +24,7 @@
>>         __PAGE_ALIGNED_DATA
>
>^^ You can get rid of this now as well

Can we?  The page is getting mapped to userspace, and if we didn't
page align it, we could leak kernel read-only data to every userspace
process.

David


From drivshin.allworx at gmail.com  Fri Feb 12 16:45:36 2016
From: drivshin.allworx at gmail.com (David Rivshin (Allworx))
Date: Fri, 12 Feb 2016 19:45:36 -0500
Subject: [PATCH] drivers: net: cpsw-phy-sel: add dev_warn() for unsupported
 PHY mode
Message-ID: <1455324336-3884-1-git-send-email-drivshin.allworx@gmail.com>

From: David Rivshin <drivshin at allworx.com>

The cpsw-phy-sel driver supports only MII, RMII, and RGMII PHY modes,
and silently handled any other values as if MII was specified. In a
case where the PHY mode was incorrectly specified, or a bug elsewhere,
there would be no indication of a problem. If MII was the correct mode,
then this will go unnoticed, otherwise the symptom will be a failure
to transmit/receive data over the RMII/RGMII link.

Add a dev_warn() to make this condition obvious and provide a
breadcrumb to follow.

Cc: Mugunthan V N <mugunthanvnm at ti.com>
Signed-off-by: David Rivshin <drivshin at allworx.com>
---

Dave,
 I'm not sure if you'd consider this net or net-next material, but it will
apply cleanly to either. Indeed, if you want it for -stable, it applies back
as far as 3.18.

 drivers/net/ethernet/ti/cpsw-phy-sel.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw-phy-sel.c b/drivers/net/ethernet/ti/cpsw-phy-sel.c
index e9cc61e..c3e85ac 100644
--- a/drivers/net/ethernet/ti/cpsw-phy-sel.c
+++ b/drivers/net/ethernet/ti/cpsw-phy-sel.c
@@ -63,8 +63,12 @@ static void cpsw_gmii_sel_am3352(struct cpsw_phy_sel_priv *priv,
 		mode = AM33XX_GMII_SEL_MODE_RGMII;
 		break;
 
-	case PHY_INTERFACE_MODE_MII:
 	default:
+		dev_warn(priv->dev,
+			 "Unsupported PHY mode: \"%s\". Defaulting to MII.\n",
+			phy_modes(phy_mode));
+		/* fallthrough */
+	case PHY_INTERFACE_MODE_MII:
 		mode = AM33XX_GMII_SEL_MODE_MII;
 		break;
 	};
@@ -106,8 +110,12 @@ static void cpsw_gmii_sel_dra7xx(struct cpsw_phy_sel_priv *priv,
 		mode = AM33XX_GMII_SEL_MODE_RGMII;
 		break;
 
-	case PHY_INTERFACE_MODE_MII:
 	default:
+		dev_warn(priv->dev,
+			 "Unsupported PHY mode: \"%s\". Defaulting to MII.\n",
+			phy_modes(phy_mode));
+		/* fallthrough */
+	case PHY_INTERFACE_MODE_MII:
 		mode = AM33XX_GMII_SEL_MODE_MII;
 		break;
 	};
-- 
2.5.0



From eric at anholt.net  Fri Feb 12 16:47:22 2016
From: eric at anholt.net (Eric Anholt)
Date: Fri, 12 Feb 2016 16:47:22 -0800
Subject: [PATCH V2 1/3] ASoC: bcm2835: move to use the clock framework
In-Reply-To: <56B88520.5060606@martin.sperl.org>
References: <1452602149-5875-1-git-send-email-kernel@martin.sperl.org>
 <1452602149-5875-2-git-send-email-kernel@martin.sperl.org>
 <87vb6dfjbu.fsf@eliezer.anholt.net> <56B88520.5060606@martin.sperl.org>
Message-ID: <87bn7l3085.fsf@eliezer.anholt.net>

Martin Sperl <kernel at martin.sperl.org> writes:

> On 28.01.2016 23:08, Eric Anholt wrote:
>> kernel at martin.sperl.org writes:
>>
>>> From: Martin Sperl <kernel at martin.sperl.org>
>>>
>>> Since the move to the new clock framework with commit 94cb7f76caa0
>>> ("ARM: bcm2835: Switch to using the new clock driver support.")
>>> this driver was no longer functional as it was manipulating the
>>> clock registers locally without going true the framework.
>>>
>>> This patch moves to use the new clock framework and also
>>> moves away from the hardcoded address offsets for DMA getting
>>> the dma-address directly from the device tree.
>>>
>>> Note that the optimal bclk_ratio selection to avoid jitter
>>> due to the use of fractional dividers, which is in the
>>> current version has been removed, because not all devices
>>> support these non power of 2 sized transfers, which resulted
>>> in lots of (downstream) modules that use:
>>>    snd_soc_dai_set_bclk_ratio(cpu_dai, sample_bits * 2);
>>>
>>> Signed-off-by: Martin Sperl <kernel at martin.sperl.org>
>>> ---
>>>   sound/soc/bcm/bcm2835-i2s.c |  284 ++++++++++---------------------------------
>>>   1 file changed, 64 insertions(+), 220 deletions(-)
>>>
>>> diff --git a/sound/soc/bcm/bcm2835-i2s.c b/sound/soc/bcm/bcm2835-i2s.c
>>> index 3303d5f..1c1f221 100644
>>> --- a/sound/soc/bcm/bcm2835-i2s.c
>>> +++ b/sound/soc/bcm/bcm2835-i2s.c
>>
>>> -	dev->i2s_regmap = regmap[0];
>>> -	dev->clk_regmap = regmap[1];
>>> +	/* get the clock */
>>> +	dev->clk_prepared = false;
>>> +	dev->clk = devm_clk_get(&pdev->dev, NULL);
>>> +	if (IS_ERR(dev->clk)) {
>>> +		dev_err(&pdev->dev, "could not get clk: %ld\n",
>>> +			PTR_ERR(dev->clk));
>>> +		return PTR_ERR(dev->clk);
>>> +	}
>>> +
>>> +	/* Request ioarea */
>>> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> +	base = devm_ioremap_resource(&pdev->dev, mem);
>>> +	if (IS_ERR(base))
>>> +		return PTR_ERR(base);
>>> +
>>> +	dev->i2s_regmap = devm_regmap_init_mmio(&pdev->dev, base,
>>> +				&bcm2835_regmap_config);
>>> +	if (IS_ERR(dev->i2s_regmap))
>>> +		return PTR_ERR(dev->i2s_regmap);
>>> +
>>> +	/* Set the DMA address - we have to parse DT ourselves */
>>> +	addr = of_get_address(pdev->dev.of_node, 0, NULL, NULL);
>>> +	if (!addr) {
>>> +		dev_err(&pdev->dev, "could not get DMA-register address\n");
>>> +		return -EINVAL;
>>> +	}
>>> +	dma_base = be32_to_cpup(addr);
>>
>> Why aren't we just using mem->start like before?  That seems like an
>> independent change that should be justified on its own.  I'd be ready to
>> ack the patch if that change is removed.
>>
>
> Problem is that we need the VC4 bus-address (0x7e203000),
> which is the actual <reg> value from the device tree without any
> mapping.
>
> Not the ARM MMU visible address mappings that mem->start provides
> (typically 0x20203000 or 0x3f203000 for bcm2836)
>
> Nor the mapped address (base) available in the kernel (typically
> 0xdc......).

Now that I've noticed the BCM2835_VCMMU_SHIFT removal, this makes sense,
but when you put unrelated changes like this together you end up slowing
down the review process on your patches.  Please separate it out into a
separate commit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/b4877b08/attachment.sig>

From tony at atomide.com  Fri Feb 12 16:49:35 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 12 Feb 2016 16:49:35 -0800
Subject: GPIO regression in Linux next caused by syscon change
In-Reply-To: <20160213002643.GQ19432@atomide.com>
References: <20160213002643.GQ19432@atomide.com>
Message-ID: <20160213004935.GR19432@atomide.com>

* Tony Lindgren <tony at atomide.com> [160212 16:31]:
> Hi,
> 
> Looks like commit effe02710335 ("mfd: syscon: Set regmap max_register
> in of_syscon_register") somehow breaks smsc911x GPIO interrupt for
> me at least on omap3:
> 
> irq 241: nobody cared (try booting with the "irqpoll" option)
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc3-next-20160212 #864
> Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [<c010fd44>] (unwind_backtrace) from [<c010c094>] (show_stack+0x10/0x14)
> [<c010c094>] (show_stack) from [<c045f24c>] (dump_stack+0xb0/0xe4)
> [<c045f24c>] (dump_stack) from [<c01998e8>] (__report_bad_irq+0x24/0xc0)
> [<c01998e8>] (__report_bad_irq) from [<c0199ce4>] (note_interrupt+0x27c/0x2dc)
> [<c0199ce4>] (note_interrupt) from [<c0197220>] (handle_irq_event_percpu+0x184/0x200)
> [<c0197220>] (handle_irq_event_percpu) from [<c01972d4>] (handle_irq_event+0x38/0x5c)
> [<c01972d4>] (handle_irq_event) from [<c019a3d8>] (handle_level_irq+0xc0/0x154)
> [<c019a3d8>] (handle_level_irq) from [<c0196784>] (generic_handle_irq+0x20/0x34)
> [<c0196784>] (generic_handle_irq) from [<c049b690>] (omap_gpio_irq_handler+0x120/0x160)
> [<c049b690>] (omap_gpio_irq_handler) from [<c01970f0>] (handle_irq_event_percpu+0x54/0x200)
> [<c01970f0>] (handle_irq_event_percpu) from [<c01972d4>] (handle_irq_event+0x38/0x5c)
> [<c01972d4>] (handle_irq_event) from [<c019a3d8>] (handle_level_irq+0xc0/0x154)
> [<c019a3d8>] (handle_level_irq) from [<c0196784>] (generic_handle_irq+0x20/0x34)
> [<c0196784>] (generic_handle_irq) from [<c0196a78>] (__handle_domain_irq+0x64/0xe0)
> [<c0196a78>] (__handle_domain_irq) from [<c076f038>] (__irq_svc+0x58/0x78)
> [<c076f038>] (__irq_svc) from [<c076e93c>] (_raw_spin_unlock_irqrestore+0x34/0x44)
> [<c076e93c>] (_raw_spin_unlock_irqrestore) from [<c019900c>] (__setup_irq+0x40c/0x5e0)
> [<c019900c>] (__setup_irq) from [<c0199330>] (request_threaded_irq+0xc0/0x158)
> [<c0199330>] (request_threaded_irq) from [<c05a4038>] (smsc911x_drv_probe+0x588/0xfec)
> [<c05a4038>] (smsc911x_drv_probe) from [<c04fc1b4>] (platform_drv_probe+0x4c/0xb0)
> [<c04fc1b4>] (platform_drv_probe) from [<c04fa89c>] (driver_probe_device+0x208/0x2c0)
> [<c04fa89c>] (driver_probe_device) from [<c04fa9e8>] (__driver_attach+0x94/0x98)
> [<c04fa9e8>] (__driver_attach) from [<c04f8bc4>] (bus_for_each_dev+0x6c/0xa0)
> [<c04f8bc4>] (bus_for_each_dev) from [<c04f9d28>] (bus_add_driver+0x18c/0x214)
> [<c04f9d28>] (bus_add_driver) from [<c04fb22c>] (driver_register+0x78/0xf8)
> [<c04fb22c>] (driver_register) from [<c010180c>] (do_one_initcall+0x80/0x1dc)
> [<c010180c>] (do_one_initcall) from [<c0b00ef0>] (kernel_init_freeable+0x218/0x2ec)
> [<c0b00ef0>] (kernel_init_freeable) from [<c0768360>] (kernel_init+0x8/0xf4)
> [<c0768360>] (kernel_init) from [<c01078d0>] (ret_from_fork+0x14/0x24)
> handlers:
> [<c05a26d8>] smsc911x_irqhandler
> Disabling IRQ #241
> libphy: smsc911x-mdio: probed
> 
> I'm not seeing the connection between regmap and  GPIO, so no
> idea what goes wrong here.

The only regmap here is the scm_conf in omap3.dtsi. Probably some
resource size calculation issue causing an overlap?

Tony



From eric at anholt.net  Fri Feb 12 16:53:52 2016
From: eric at anholt.net (Eric Anholt)
Date: Fri, 12 Feb 2016 16:53:52 -0800
Subject: [GIT PULL] bcm2835 DT changes for 4.6
In-Reply-To: <56BD55A2.20104@gmail.com>
References: <1454977978-17491-1-git-send-email-eric@anholt.net>
 <DDFB1D8B-805B-488F-9582-796EBCEF287B@sperl.org>
 <87d1s42yb8.fsf@eliezer.anholt.net> <56BD55A2.20104@gmail.com>
Message-ID: <877fi92zxb.fsf@eliezer.anholt.net>

Florian Fainelli <f.fainelli at gmail.com> writes:

> On 10/02/2016 10:51, Eric Anholt wrote:
>> Martin Sperl <martin at sperl.org> writes:
>> 
>>>> On 09.02.2016, at 01:32, Eric Anholt <eric at anholt.net> wrote:
>>>>
>>>> Hi Florian.  Here's the first set of patches for bcm2835 for 4.6.
>>>> We've got more DT patches that are going to happen for new boards,
>>>> too, but they're still getting polished.
>>>>
>>>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>>>
>>>>  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>>>
>>>> are available in the git repository at:
>>>>
>>>>  git at github.com:anholt/linux.git tags/bcm2835-dt-next-2016-02-04
>>>>
>>>> for you to fetch changes up to 5ec6f2cd8ec4bcd38ba199ea8711a5ec906d85e7:
>>>>
>>>>  ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT. (2016-02-02 20:02:45 -0800)
>>>>
>>>> ----------------------------------------------------------------
>>>> This pull request covers mostly DT changes that didn't make it into
>>>> 4.5 because required header files went through other trees.
>>>>
>>>> ----------------------------------------------------------------
>>>> Alexander Aring (1):
>>>>      ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
>>>>
>>>> Lubomir Rintel (1):
>>>>      ARM: bcm2835: dt: Add Raspberry Pi Model A
>>>>
>>>> Martin Sperl (2):
>>>>      ARM: bcm2835: add the auxiliary spi1 and spi2 to the device tree
>>>>      ARM: bcm2835: follow dt uart node-naming convention
>>>
>>> Do you want me to resend a rebased version of:
>>>      ARM: bcm2835: add bcm2835-aux-uart support to default DT
>>>
>>> The corresponding driver has been added to tty/tty-next.
>> 
>> It hadn't landed last time I checked.  A rebased version that you've
>> tested would be great!
>
> OK, please submit this in the next week or so at most, so we can get
> this pull request merged, thanks!
>
> Eric, do you have other changes outside of Device Tree?

We've got bcm2835_defconfig changes that I need to test and tag.

There are also the multi_v7_defconfig updates to enable bcm2835.  Would
I be pulling those, or someone above me?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160212/ec6b7db7/attachment-0001.sig>

From drivshin.allworx at gmail.com  Fri Feb 12 17:28:37 2016
From: drivshin.allworx at gmail.com (David Rivshin (Allworx))
Date: Fri, 12 Feb 2016 20:28:37 -0500
Subject: [PATCH 0/3] drivers: net: cpsw: phy-handle fixes
In-Reply-To: <20151223201816.1a4bd0f6.drivshin.allworx@gmail.com>
References: <1450830994-5450-1-git-send-email-drivshin.allworx@gmail.com>
 <CABr+WT=oDpp56jouAD57UM8_38geD1MMizZcDnx14maf2ohpCw@mail.gmail.com>
 <20151223165454.6e4d5950.drivshin.allworx@gmail.com>
 <CABr+WTm=Oo16=qB6dyO6ZhUUz0307ROi=o270Rac2R4W5-usjg@mail.gmail.com>
 <20151223201816.1a4bd0f6.drivshin.allworx@gmail.com>
Message-ID: <20160212202837.0f8b7c79.drivshin.allworx@gmail.com>

On Wed, 23 Dec 2015 20:18:16 -0500
"David Rivshin (Allworx)" <drivshin.allworx at gmail.com> wrote:

> On Thu, 24 Dec 2015 00:34:49 +0100
> Nicolas Chauvet <kwizart at gmail.com> wrote:
> 
> > 2015-12-23 22:54 GMT+01:00 David Rivshin (Allworx) <  
> > drivshin.allworx at gmail.com>:  
> >   
> > > On Wed, 23 Dec 2015 22:20:58 +0100
> > > Nicolas Chauvet <kwizart at gmail.com> wrote:
> > >  
> > > > 2015-12-23 1:36 GMT+01:00 David Rivshin (Allworx) <  
> > > > drivshin.allworx at gmail.com>:  
> > > >  
> > > > > From: David Rivshin <drivshin at allworx.com>
> > > > >
> > > > > This series is based on the tip of the net tree.
> > > > >
> > > > > The first patch fixes a bug that makes dual_emac mode break if
> > > > > either slave uses the phy-handle property in the devicetree.
> > > > >
> > > > > The second patch fixes some cosmetic problems with error
> > > > > messages, and also makes the binding documentation more
> > > > > explicit.
> > > > >
> > > > > The third patch cleans up the fixed-link case to work like
> > > > > the now-fixed phy-handle case.
> > > > >
> > > > > I have tested on the following hardware configurations:
> > > > >  - (EVMSK) dual emac, phy_id property in both slaves
> > > > >  - (BeagleBoneBlack) single emac, phy_id property
> > > > >  - (custom) single emac, fixed-link subnode
> > > > > Note that I don't have a board which would uses a phy-handle
> > > > > property, though I have used hacked devicetrees to exercise
> > > > > the code paths. Testing by anyone who has real hardware using
> > > > > phy-handle or dual_emac with fixed-link would be appreciated.
> > > > >
> > > > > David Rivshin (3):
> > > > >   drivers: net: cpsw: fix parsing of phy-handle DT property in
> > > > > dual_emac config
> > > > >   drivers: net: cpsw: fix error messages when using phy-handle
> > > > > DT property
> > > > >   drivers: net: cpsw: use of_phy_connect() in fixed-link case
> > > > >
> > > > >  Documentation/devicetree/bindings/net/cpsw.txt |  4 +--
> > > > >  drivers/net/ethernet/ti/cpsw.c                 | 40
> > > > > +++++++++++++-------------
> > > > >  drivers/net/ethernet/ti/cpsw.h                 |  1 +
> > > > >  3 files changed, 23 insertions(+), 22 deletions(-)
> > > > >
> > > > >  
> > > > This serie failed with me on dm8418 hp-t410 on top of linux-next
> > > > from today whereas the same patch level and same methods without
> > > > this serie is working fine.
> > > > I wasn't able to ping anything on a minimal rootfs with static
> > > > ip set from cmdline from kernel.
> > > >
> > > > Sorry for  the lack of details, feel free to add me to any other
> > > > revision of the patch if any.
> > > > I will be able to do more testing next month.  
> > >
> > > (Sorry for the duplicate, doing a reply-all this time. Not sure
> > > why it looked like a non-list email the first time)
> > >  
> > My bad, I've replied twice, but only last on-list.
> > 
> >   
> > > Thanks for testing. I found the dm8148-t410.dts devicetree in the
> > > kernel source, and it uses the phy_id for both slaves, just like
> > > the EVMSK board I tested. So I can't think of an obvious reason
> > > for the problem.
> > > Would you be able to send the 'dmesg' log from right after bootup?
> > > I'm hoping there is an error message in there with some clue.
> > >  
> > here is the full dmesg output with this serie applied to linux-next:
> > http://ur1.ca/ocvs6
> > 
> > [    2.281524] davinci_mdio 4a100800.mdio: davinci mdio revision 1.6
> > [    2.287909] davinci_mdio 4a100800.mdio: detected phy mask
> > fffffffe [    2.302663] Atheros 8031 ethernet 4a100800.mdio:00:
> > GPIO lookup for consumer reset
> > [    2.302686] Atheros 8031 ethernet 4a100800.mdio:00: using lookup
> > tables for GPIO lookup
> > [    2.302732] Atheros 8031 ethernet 4a100800.mdio:00: lookup for
> > GPIO reset failed
> > [    2.302860] libphy: 4a100800.mdio: probed
> > [    2.307063] davinci_mdio 4a100800.mdio: phy[0]: device
> > 4a100800.mdio:00, driver Atheros 8031 ethernet
> > [    2.317945] cpsw 4a100000.ethernet: Detected MACID =
> > 00:18:32:60:8e:38
> > 
> > * 19:06 < nchauvet> btw with this dmesg, I've tried to apply this
> > serie: http://marc.info/?l=linux-omap&m=145032865615589&w=2, but it
> > doesn't seem to work for me (I cannot ping my gateway anymore)  
> 
> That particular email was about a v1 patch, which was then replaced
> by a 3-patch series for v2:
> http://marc.info/?l=linux-netdev&m=145032497014944&w=2
> That is already in linux-next, and below you show that you have it.
> 
> > So I've remembered that I've double checked the Ethernet wire, but I
> > agree it can also be another random issue.  
> 
> If it works without this series, but fails with it, that is strong
> evidence that something in this series either is a bug or exposes
> one.
> 
> > > Just to verify, is your linux-next tree up-to-date? This series
> > > needs to be applied is based on another recent series of 3 patches
> > > to cpsw.c. Although I doubt it would apply cleanly at all without
> > > those.  
> > 
> > From my linux-next base, related to cpsw, I have:
> > git log --oneline cpsw*
> > a6b257c Merge remote-tracking branch 'net-next/master'
> > dfc0a6d drivers: net: cpsw: increment reference count on fixed-link
> > PHY node 
> > f1eea5c drivers: net: cpsw: fix RMII/RGMII mode when used
> > with fixed-link PHY
> > 1873c58 ethernet:ti:cpsw: fix phy identification with multiple
> > slaves on fixed-phy
> > f188b95 Merge
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 0db19b8
> > net: cpsw: Fix ethernet regression for dm814
> > 
> > Theses patches don't lead to any issue on the t410 device.  
> 
> Thanks for verifying. 1873c58, f1eea5, and cdfc0a6d are the previous
> patches I referred to.
> 
> > Comparing a dmesg output where the driver work: it doesn't show any
> > difference from the quoted lines:
> > http://paste.fedoraproject.org/304248/45086839/  
> 
> Thanks for the additional info. I also don't see any red flags in the 
> dmesg output. 
> 
> When I looked closer at the dm8148-t410 devicetree, I see that it's 
> actually more like the BeagleBones than an EVMSK. It specifies two 
> slaves, but is not in dual_emac mode. Other than using RGMII mode 
> instead of MII, the emac configuration in the DT looks the same to
> me. Further, your dmesg shows there is only one actual PHY, same as
> a BeagleBone. I assume that's historical, as specifying slaves=<1> 
> used to crash (fixed by 1973db0df7c3b in v4.2).
> 
> Despite the similarities, I have been unable to reproduce a failure 
> on a BeagleBone-Black running linux-next plus this series. Things
> that I've checked in dmesg output look similar to yours, so I'm 
> currently out of ideas I can check myself. If I could ask you for
> some more assistance in debugging:
> 
> Are you using the devicetree from the linux-next source, or is it 
> modified? If it's modified, can you send it?
> 
> Could you check the phy_interface mode used? I know that being wrong
> would generate such symptoms. Quickest way to check that (and related
> bits) is probably:
>    grep -H . /sys/bus/mdio_bus/devices/*/phy*
> Based on the devicetree in the kernel source and your dmesg output, 
> I expect there to be a single PHY with phy_interface=rgmii and
> phy_id=0x4dd074. If any of those aspects don't match what sysfs 
> reports, then that's likely to be the cause.
> 
> Failing that, I would next try to apply the 3 patches in this series
> one at a time (or bisect them) to identify the specific culprit. 
> 
> Thanks.

Nicolas,

Did you have a chance to try this series again? I've retested 
on a BeagleBone-Black against both current net and linux-next, 
and I still can't reproduce see the failure you reported. I'm
hoping that was just the result of some unrelated and since-
resolved problem. 

Note that the 3rd patch has a merge conflict now, but it is 
trivially resolved by taking the (deletion of) lines from this 
series. If you'd like me to send a post-merge version, just 
let me know.

Also, I have just CCed you on a related patch that adds a 
dev_warn() which catches the case I mentioned at the end of my
previous email. I would suggest applying that as well, just to
remove some guesswork.

Thanks.


From isubramanian at apm.com  Fri Feb 12 17:37:01 2016
From: isubramanian at apm.com (Iyappan Subramanian)
Date: Fri, 12 Feb 2016 17:37:01 -0800
Subject: [PATCH net-next v2 0/4] Add support for Classifier and RSS
Message-ID: <1455327425-8294-1-git-send-email-isubramanian@apm.com>

This patch set enables,

(i) Classifier engine that is used for parsing
through the packet and extracting a search string that is then used
to search a database to find associative data.

(ii) Receive Side Scaling (RSS) that does dynamic load
balancing of the CPUs by controlling the number of messages enqueued
per CPU though the help of Toeplitz Hash function of 4-tuple of
source TCP/UDP port, destination TCP/UDP port, source IPV4 address and
destination IPV4 address.

(iii) Multi queue, to make advantage of RSS


v2: Address review comments from v1
    - fix kbuild warning
    - add default coalescing

v1:
    - Initial version

Signed-off-by: Iyappan Subramanian <isubramanian at apm.com>
---

Iyappan Subramanian (4):
  drivers: net: xgene: Add support for Classifier engine
  drivers: net: xgene: Add support for RSS
  drivers: net: xgene: Add support for multiple queues
  dtb: xgene: Add irqs to support multi queue

 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi        |   8 +-
 arch/arm64/boot/dts/apm/apm-storm.dtsi            |   8 +-
 drivers/net/ethernet/apm/xgene/Makefile           |   3 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c   | 734 ++++++++++++++++++++++
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.h   | 295 +++++++++
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c    |  12 +
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h    |   6 +
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c  | 482 ++++++++------
 drivers/net/ethernet/apm/xgene/xgene_enet_main.h  |  35 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c |  12 +
 10 files changed, 1395 insertions(+), 200 deletions(-)
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_cle.h

-- 
1.9.1



From isubramanian at apm.com  Fri Feb 12 17:37:02 2016
From: isubramanian at apm.com (Iyappan Subramanian)
Date: Fri, 12 Feb 2016 17:37:02 -0800
Subject: [PATCH net-next v2 1/4] drivers: net: xgene: Add support for
 Classifier engine
In-Reply-To: <1455327425-8294-1-git-send-email-isubramanian@apm.com>
References: <1455327425-8294-1-git-send-email-isubramanian@apm.com>
Message-ID: <1455327425-8294-2-git-send-email-isubramanian@apm.com>

Signed-off-by: Iyappan Subramanian <isubramanian at apm.com>
Signed-off-by: Khuong Dinh <kdinh at apm.com>
Signed-off-by: Tanmay Inamdar <tinamdar at apm.com>
Tested-by: Toan Le <toanle at apm.com>
---
 drivers/net/ethernet/apm/xgene/Makefile          |   3 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c  | 357 +++++++++++++++++++++++
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.h  | 254 ++++++++++++++++
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h   |   1 +
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c |  29 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_main.h |  14 +
 6 files changed, 649 insertions(+), 9 deletions(-)
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_cle.h

diff --git a/drivers/net/ethernet/apm/xgene/Makefile b/drivers/net/ethernet/apm/xgene/Makefile
index 700b5ab..f46321f 100644
--- a/drivers/net/ethernet/apm/xgene/Makefile
+++ b/drivers/net/ethernet/apm/xgene/Makefile
@@ -3,5 +3,6 @@
 #
 
 xgene-enet-objs := xgene_enet_hw.o xgene_enet_sgmac.o xgene_enet_xgmac.o \
-		   xgene_enet_main.o xgene_enet_ring2.o xgene_enet_ethtool.o
+		   xgene_enet_main.o xgene_enet_ring2.o xgene_enet_ethtool.o \
+		   xgene_enet_cle.o
 obj-$(CONFIG_NET_XGENE) += xgene-enet.o
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
new file mode 100644
index 0000000..7eea982
--- /dev/null
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
@@ -0,0 +1,357 @@
+/* Applied Micro X-Gene SoC Ethernet Classifier structures
+ *
+ * Copyright (c) 2016, Applied Micro Circuits Corporation
+ * Authors: Khuong Dinh <kdinh at apm.com>
+ *          Tanmay Inamdar <tinamdar at apm.com>
+ *          Iyappan Subramanian <isubramanian at apm.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * 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 "xgene_enet_main.h"
+
+static void xgene_cle_dbptr_to_hw(struct xgene_enet_pdata *pdata,
+				  struct xgene_cle_dbptr *dbptr, u32 *buf)
+{
+	buf[4] = SET_VAL(CLE_FPSEL, dbptr->fpsel) |
+		 SET_VAL(CLE_DSTQIDL, dbptr->dstqid);
+
+	buf[5] = SET_VAL(CLE_DSTQIDH, (u32)dbptr->dstqid >> CLE_DSTQIDL_LEN) |
+		 SET_VAL(CLE_PRIORITY, dbptr->cle_priority);
+}
+
+static void xgene_cle_kn_to_hw(struct xgene_cle_ptree_kn *kn, u32 *buf)
+{
+	u32 i, j = 0;
+	u32 data;
+
+	buf[j++] = SET_VAL(CLE_TYPE, kn->node_type);
+	for (i = 0; i < kn->num_keys; i++) {
+		struct xgene_cle_ptree_key *key = &kn->key[i];
+
+		if (!(i % 2)) {
+			buf[j] = SET_VAL(CLE_KN_PRIO, key->priority) |
+				 SET_VAL(CLE_KN_RPTR, key->result_pointer);
+		} else {
+			data = SET_VAL(CLE_KN_PRIO, key->priority) |
+			       SET_VAL(CLE_KN_RPTR, key->result_pointer);
+			buf[j++] |= (data << 16);
+		}
+	}
+}
+
+static void xgene_cle_dn_to_hw(struct xgene_cle_ptree_ewdn *dn,
+			       u32 *buf, u32 jb)
+{
+	u32 i, j = 0;
+	u32 npp;
+	struct xgene_cle_ptree_branch *br;
+
+	buf[j++] = SET_VAL(CLE_DN_TYPE, dn->node_type) |
+		   SET_VAL(CLE_DN_LASTN, dn->last_node) |
+		   SET_VAL(CLE_DN_HLS, dn->hdr_len_store) |
+		   SET_VAL(CLE_DN_EXT, dn->hdr_extn) |
+		   SET_VAL(CLE_DN_BSTOR, dn->byte_store) |
+		   SET_VAL(CLE_DN_SBSTOR, dn->search_byte_store) |
+		   SET_VAL(CLE_DN_RPTR, dn->result_pointer);
+
+	for (i = 0; i < dn->num_branches; i++) {
+		br = &dn->branch[i];
+		npp = br->next_packet_pointer;
+
+		if ((br->jump_rel == JMP_ABS) && (npp < CLE_PKTRAM_SIZE))
+			npp += jb;
+
+		buf[j++] = SET_VAL(CLE_BR_VALID, br->valid) |
+			   SET_VAL(CLE_BR_NPPTR, npp) |
+			   SET_VAL(CLE_BR_JB, br->jump_bw) |
+			   SET_VAL(CLE_BR_JR, br->jump_rel) |
+			   SET_VAL(CLE_BR_OP, br->operation) |
+			   SET_VAL(CLE_BR_NNODE, br->next_node) |
+			   SET_VAL(CLE_BR_NBR, br->next_branch);
+
+		buf[j++] = SET_VAL(CLE_BR_DATA, br->data) |
+			   SET_VAL(CLE_BR_MASK, br->mask);
+	}
+}
+
+static int xgene_cle_poll_cmd_done(void __iomem *base,
+				   enum xgene_cle_cmd_type cmd)
+{
+	u32 status, loop = 10;
+	int ret = -EBUSY;
+
+	while (loop--) {
+		status = ioread32(base + INDCMD_STATUS);
+		if (status & cmd) {
+			ret = 0;
+			break;
+		}
+		usleep_range(1000, 2000);
+	}
+
+	return ret;
+}
+
+static int xgene_cle_dram_wr(struct xgene_enet_cle *cle, u32 *data, u8 nregs,
+			     u32 index, enum xgene_cle_dram_type type,
+			     enum xgene_cle_cmd_type cmd)
+{
+	void __iomem *base = cle->base;
+	enum xgene_cle_parser parser = cle->active_parser;
+	u32 i, j, ind_addr;
+	u8 port, nparsers;
+	int ret = 0;
+
+	/* PTREE_RAM onwards, DRAM regions are common for all parsers */
+	nparsers = (type >= PTREE_RAM) ? 1 : cle->parsers;
+
+	for (i = 0; i < nparsers; i++) {
+		port = i;
+		if ((type < PTREE_RAM) && (parser != PARSER_ALL))
+			port = parser;
+
+		ind_addr = XGENE_CLE_DRAM(type + (port * 4)) | index;
+		iowrite32(ind_addr, base + INDADDR);
+		for (j = 0; j < nregs; j++)
+			iowrite32(data[j], base + DATA_RAM0 + (j * 4));
+		iowrite32(cmd, base + INDCMD);
+
+		ret = xgene_cle_poll_cmd_done(base, cmd);
+		if (ret)
+			break;
+	}
+
+	return ret;
+}
+
+static void xgene_cle_enable_ptree(struct xgene_enet_pdata *pdata,
+				   struct xgene_enet_cle *cle)
+{
+	struct xgene_cle_ptree *ptree = &cle->ptree;
+	void __iomem *addr, *base = cle->base;
+	u32 offset = CLE_PORT_OFFSET;
+	u32 i;
+
+	/* 1G port has to advance 4 bytes and 10G has to advance 8 bytes */
+	ptree->start_pkt += cle->jump_bytes;
+	for (i = 0; i < cle->parsers; i++) {
+		if (cle->active_parser != PARSER_ALL)
+			addr = base + cle->active_parser * offset;
+		else
+			addr = base + (i * offset);
+
+		iowrite32(ptree->start_node & 0x3fff, addr + SNPTR0);
+		iowrite32(ptree->start_pkt & 0x1ff, addr + SPPTR0);
+	}
+}
+
+static int xgene_cle_setup_dbptr(struct xgene_enet_pdata *pdata,
+				 struct xgene_enet_cle *cle)
+{
+	struct xgene_cle_ptree *ptree = &cle->ptree;
+	struct xgene_cle_dbptr *dbptr = ptree->dbptr;
+	u32 buf[CLE_DRAM_REGS];
+	u32 i;
+	int ret;
+
+	memset(buf, 0, sizeof(buf));
+	for (i = 0; i < ptree->num_dbptr; i++) {
+		xgene_cle_dbptr_to_hw(pdata, &dbptr[i], buf);
+		ret = xgene_cle_dram_wr(cle, buf, 6, i + ptree->start_dbptr,
+					DB_RAM,	CLE_CMD_WR);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int xgene_cle_setup_node(struct xgene_enet_pdata *pdata,
+				struct xgene_enet_cle *cle)
+{
+	struct xgene_cle_ptree *ptree = &cle->ptree;
+	struct xgene_cle_ptree_ewdn *dn = ptree->dn;
+	struct xgene_cle_ptree_kn *kn = ptree->kn;
+	u32 buf[CLE_DRAM_REGS];
+	int i, j, ret;
+
+	memset(buf, 0, sizeof(buf));
+	for (i = 0; i < ptree->num_dn; i++) {
+		xgene_cle_dn_to_hw(&dn[i], buf, cle->jump_bytes);
+		ret = xgene_cle_dram_wr(cle, buf, 17, i + ptree->start_node,
+					PTREE_RAM, CLE_CMD_WR);
+		if (ret)
+			return ret;
+	}
+
+	/* continue node index for key node */
+	memset(buf, 0, sizeof(buf));
+	for (j = i; j < (ptree->num_kn + ptree->num_dn); j++) {
+		xgene_cle_kn_to_hw(&kn[j - ptree->num_dn], buf);
+		ret = xgene_cle_dram_wr(cle, buf, 17, j + ptree->start_node,
+					PTREE_RAM, CLE_CMD_WR);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int xgene_cle_setup_ptree(struct xgene_enet_pdata *pdata,
+				 struct xgene_enet_cle *cle)
+{
+	int ret;
+
+	ret = xgene_cle_setup_node(pdata, cle);
+	if (ret)
+		return ret;
+
+	ret = xgene_cle_setup_dbptr(pdata, cle);
+	if (ret)
+		return ret;
+
+	xgene_cle_enable_ptree(pdata, cle);
+
+	return 0;
+}
+
+static void xgene_cle_setup_def_dbptr(struct xgene_enet_pdata *pdata,
+				      struct xgene_enet_cle *enet_cle,
+				      struct xgene_cle_dbptr *dbptr,
+				      u32 index, u8 priority)
+{
+	void __iomem *base = enet_cle->base;
+	void __iomem *base_addr;
+	u32 buf[CLE_DRAM_REGS];
+	u32 def_cls, offset;
+	u32 i, j;
+
+	memset(buf, 0, sizeof(buf));
+	xgene_cle_dbptr_to_hw(pdata, dbptr, buf);
+
+	for (i = 0; i < enet_cle->parsers; i++) {
+		if (enet_cle->active_parser != PARSER_ALL) {
+			offset = enet_cle->active_parser *
+				CLE_PORT_OFFSET;
+		} else {
+			offset = i * CLE_PORT_OFFSET;
+		}
+
+		base_addr = base + DFCLSRESDB00 + offset;
+		for (j = 0; j < 6; j++)
+			iowrite32(buf[j], base_addr + (j * 4));
+
+		def_cls = ((priority & 0x7) << 10) | (index & 0x3ff);
+		iowrite32(def_cls, base + DFCLSRESDBPTR0 + offset);
+	}
+}
+
+static int xgene_enet_cle_init(struct xgene_enet_pdata *pdata)
+{
+	struct xgene_enet_cle *enet_cle = &pdata->cle;
+	struct xgene_cle_ptree *ptree = &enet_cle->ptree;
+	struct xgene_cle_dbptr dbptr[DB_MAX_PTRS];
+	struct xgene_cle_ptree_kn kn;
+	u32 def_qid, def_fpsel, pool_id;
+	struct xgene_cle_ptree_ewdn ptree_dn[] = {
+		{
+			/* PKT_TYPE_NODE */
+			.node_type = EWDN,
+			.last_node = 0,
+			.hdr_len_store = 0,
+			.hdr_extn = NO_BYTE,
+			.byte_store = NO_BYTE,
+			.search_byte_store = NO_BYTE,
+			.result_pointer = DB_RES_DROP,
+			.num_branches = 1,
+			.branch = {
+				{
+					/* Allow all packet type */
+					.valid = 0,
+					.next_packet_pointer = 0,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = LAST_NODE,
+					.next_branch = 0,
+					.data = 0x0,
+					.mask = 0xffff
+				}
+			}
+		},
+		{
+			/* LAST NODE */
+			.node_type = EWDN,
+			.last_node = 1,
+			.hdr_len_store = 0,
+			.hdr_extn = NO_BYTE,
+			.byte_store = NO_BYTE,
+			.search_byte_store = NO_BYTE,
+			.result_pointer = DB_RES_DROP,
+			.num_branches = 1,
+			.branch = {
+				{
+					.valid = 0,
+					.next_packet_pointer = 0,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = MAX_NODES,
+					.next_branch = 0,
+					.data = 0,
+					.mask = 0xffff
+				}
+			}
+		}
+	};
+
+	ptree->start_pkt = 12; /* Ethertype */
+
+	def_qid = xgene_enet_dst_ring_num(pdata->rx_ring);
+	pool_id = pdata->rx_ring->buf_pool->id;
+	def_fpsel = xgene_enet_ring_bufnum(pool_id) - 0x20;
+
+	memset(dbptr, 0, sizeof(struct xgene_cle_dbptr) * DB_MAX_PTRS);
+	dbptr[DB_RES_ACCEPT].fpsel =  def_fpsel;
+	dbptr[DB_RES_ACCEPT].dstqid = def_qid;
+	dbptr[DB_RES_ACCEPT].cle_priority = 1;
+
+	dbptr[DB_RES_DEF].fpsel = def_fpsel;
+	dbptr[DB_RES_DEF].dstqid = def_qid;
+	dbptr[DB_RES_DEF].cle_priority = 7;
+	xgene_cle_setup_def_dbptr(pdata, enet_cle, &dbptr[DB_RES_DEF],
+				  DB_RES_ACCEPT, 7);
+
+	dbptr[DB_RES_DROP].drop = 1;
+
+	memset(&kn, 0, sizeof(kn));
+	kn.node_type = KN;
+	kn.num_keys = 1;
+	kn.key[0].priority = 0;
+	kn.key[0].result_pointer = DB_RES_ACCEPT;
+
+	ptree->dn = ptree_dn;
+	ptree->kn = &kn;
+	ptree->dbptr = dbptr;
+	ptree->num_dn = MAX_NODES;
+	ptree->num_kn = 1;
+	ptree->num_dbptr = DB_MAX_PTRS;
+
+	return xgene_cle_setup_ptree(pdata, enet_cle);
+}
+
+struct xgene_cle_ops xgene_cle3in_ops = {
+	.cle_init = xgene_enet_cle_init,
+};
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h
new file mode 100644
index 0000000..1db2fd7
--- /dev/null
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h
@@ -0,0 +1,254 @@
+/* Applied Micro X-Gene SoC Ethernet Classifier structures
+ *
+ * Copyright (c) 2016, Applied Micro Circuits Corporation
+ * Authors: Khuong Dinh <kdinh at apm.com>
+ *          Tanmay Inamdar <tinamdar at apm.com>
+ *          Iyappan Subramanian <isubramanian at apm.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __XGENE_ENET_CLE_H__
+#define __XGENE_ENET_CLE_H__
+
+#include <linux/io.h>
+#include <linux/random.h>
+
+/* Register offsets */
+#define INDADDR			0x04
+#define INDCMD			0x08
+#define INDCMD_STATUS		0x0c
+#define DATA_RAM0		0x10
+#define SNPTR0			0x0100
+#define SPPTR0			0x0104
+#define DFCLSRESDBPTR0		0x0108
+#define DFCLSRESDB00		0x010c
+
+#define CLE_CMD_TO		10	/* ms */
+#define CLE_PKTRAM_SIZE		256	/* bytes */
+#define CLE_PORT_OFFSET		0x200
+#define CLE_DRAM_REGS		17
+
+#define CLE_DN_TYPE_LEN		2
+#define CLE_DN_TYPE_POS		0
+#define CLE_DN_LASTN_LEN	1
+#define CLE_DN_LASTN_POS	2
+#define CLE_DN_HLS_LEN		1
+#define CLE_DN_HLS_POS		3
+#define CLE_DN_EXT_LEN		2
+#define	CLE_DN_EXT_POS		4
+#define CLE_DN_BSTOR_LEN	2
+#define CLE_DN_BSTOR_POS	6
+#define CLE_DN_SBSTOR_LEN	2
+#define CLE_DN_SBSTOR_POS	8
+#define CLE_DN_RPTR_LEN		12
+#define CLE_DN_RPTR_POS		12
+
+#define CLE_BR_VALID_LEN	1
+#define CLE_BR_VALID_POS	0
+#define CLE_BR_NPPTR_LEN	9
+#define CLE_BR_NPPTR_POS	1
+#define CLE_BR_JB_LEN		1
+#define CLE_BR_JB_POS		10
+#define CLE_BR_JR_LEN		1
+#define CLE_BR_JR_POS		11
+#define CLE_BR_OP_LEN		3
+#define CLE_BR_OP_POS		12
+#define CLE_BR_NNODE_LEN	9
+#define CLE_BR_NNODE_POS	15
+#define CLE_BR_NBR_LEN		5
+#define CLE_BR_NBR_POS		24
+
+#define CLE_BR_DATA_LEN		16
+#define CLE_BR_DATA_POS		0
+#define CLE_BR_MASK_LEN		16
+#define CLE_BR_MASK_POS		16
+
+#define CLE_KN_PRIO_POS		0
+#define CLE_KN_PRIO_LEN		3
+#define CLE_KN_RPTR_POS		3
+#define CLE_KN_RPTR_LEN		10
+#define CLE_TYPE_POS		0
+#define CLE_TYPE_LEN		2
+
+#define CLE_DSTQIDL_POS		25
+#define CLE_DSTQIDL_LEN		7
+#define CLE_DSTQIDH_POS		0
+#define CLE_DSTQIDH_LEN		5
+#define CLE_FPSEL_POS		21
+#define CLE_FPSEL_LEN		4
+#define CLE_PRIORITY_POS	5
+#define CLE_PRIORITY_LEN	3
+
+#define JMP_ABS			0
+#define JMP_REL			1
+#define JMP_FW			0
+#define JMP_BW			1
+
+enum xgene_cle_ptree_nodes {
+	PKT_TYPE_NODE,
+	LAST_NODE,
+	MAX_NODES
+};
+
+enum xgene_cle_byte_store {
+	NO_BYTE,
+	FIRST_BYTE,
+	SECOND_BYTE,
+	BOTH_BYTES
+};
+
+/* Preclassification operation types */
+enum xgene_cle_node_type {
+	INV,
+	KN,
+	EWDN,
+	RES_NODE
+};
+
+/* Preclassification operation types */
+enum xgene_cle_op_type {
+	EQT,
+	NEQT,
+	LTEQT,
+	GTEQT,
+	AND,
+	NAND
+};
+
+enum xgene_cle_parser {
+	PARSER0,
+	PARSER1,
+	PARSER2,
+	PARSER_ALL
+};
+
+#define XGENE_CLE_DRAM(type)	(((type) & 0xf) << 28)
+enum xgene_cle_dram_type {
+	PKT_RAM,
+	PTREE_RAM = 0xc,
+	AVL_RAM,
+	DB_RAM
+};
+
+enum xgene_cle_cmd_type {
+	CLE_CMD_WR = 1,
+	CLE_CMD_RD = 2,
+	CLE_CMD_AVL_ADD = 8,
+	CLE_CMD_AVL_DEL = 16,
+	CLE_CMD_AVL_SRCH = 32
+};
+
+enum xgene_cle_ptree_dbptrs {
+	DB_RES_DROP,
+	DB_RES_DEF,
+	DB_RES_ACCEPT,
+	DB_MAX_PTRS
+};
+
+struct xgene_cle_ptree_branch {
+	bool valid;
+	u16 next_packet_pointer;
+	bool jump_bw;
+	bool jump_rel;
+	u8 operation;
+	u16 next_node;
+	u8 next_branch;
+	u16 data;
+	u16 mask;
+};
+
+struct xgene_cle_ptree_ewdn {
+	u8 node_type;
+	bool last_node;
+	bool hdr_len_store;
+	u8 hdr_extn;
+	u8 byte_store;
+	u8 search_byte_store;
+	u16 result_pointer;
+	u8 num_branches;
+	struct xgene_cle_ptree_branch branch[6];
+};
+
+struct xgene_cle_ptree_key {
+	u8 priority;
+	u16 result_pointer;
+};
+
+struct xgene_cle_ptree_kn {
+	u8 node_type;
+	u8 num_keys;
+	struct xgene_cle_ptree_key key[32];
+};
+
+struct xgene_cle_dbptr {
+	u8 split_boundary;
+	u8 mirror_nxtfpsel;
+	u8 mirror_fpsel;
+	u16 mirror_dstqid;
+	u8 drop;
+	u8 mirror;
+	u8 hdr_data_split;
+	u64 hopinfomsbs;
+	u8 DR;
+	u8 HR;
+	u64 hopinfomlsbs;
+	u16 h0enq_num;
+	u8 h0fpsel;
+	u8 nxtfpsel;
+	u8 fpsel;
+	u16 dstqid;
+	u8 cle_priority;
+	u8 cle_flowgroup;
+	u8 cle_perflow;
+	u8 cle_insert_timestamp;
+	u8 stash;
+	u8 in;
+	u8 perprioen;
+	u8 perflowgroupen;
+	u8 perflowen;
+	u8 selhash;
+	u8 selhdrext;
+	u8 mirror_nxtfpsel_msb;
+	u8 mirror_fpsel_msb;
+	u8 hfpsel_msb;
+	u8 nxtfpsel_msb;
+	u8 fpsel_msb;
+};
+
+struct xgene_cle_ptree {
+	struct xgene_cle_ptree_ewdn *dn;
+	struct xgene_cle_ptree_kn *kn;
+	struct xgene_cle_dbptr *dbptr;
+	u32 num_dn;
+	u32 num_kn;
+	u32 num_dbptr;
+	u32 start_node;
+	u32 start_pkt;
+	u32 start_dbptr;
+};
+
+struct xgene_enet_cle {
+	void __iomem *base;
+	struct xgene_cle_ptree ptree;
+	enum xgene_cle_parser active_parser;
+	u32 parsers;
+	u32 max_nodes;
+	u32 max_dbptrs;
+	u32 jump_bytes;
+};
+
+extern struct xgene_cle_ops xgene_cle3in_ops;
+
+#endif /* __XGENE_ENET_CLE_H__ */
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
index 8a90910..45725ec 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
@@ -101,6 +101,7 @@ enum xgene_enet_rm {
 #define MAC_OFFSET			0x30
 
 #define BLOCK_ETH_CSR_OFFSET		0x2000
+#define BLOCK_ETH_CLE_CSR_OFFSET	0x6000
 #define BLOCK_ETH_RING_IF_OFFSET	0x9000
 #define BLOCK_ETH_CLKRST_CSR_OFFSET	0xc000
 #define BLOCK_ETH_DIAG_CSR_OFFSET	0xD000
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 5eb9b20..2716d45 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -93,13 +93,6 @@ static int xgene_enet_refill_bufpool(struct xgene_enet_desc_ring *buf_pool,
 	return 0;
 }
 
-static u16 xgene_enet_dst_ring_num(struct xgene_enet_desc_ring *ring)
-{
-	struct xgene_enet_pdata *pdata = netdev_priv(ring->ndev);
-
-	return ((u16)pdata->rm << 10) | ring->num;
-}
-
 static u8 xgene_enet_hdr_len(const void *data)
 {
 	const struct ethhdr *eth = data;
@@ -1278,6 +1271,7 @@ static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
 	else
 		base_addr = pdata->base_addr;
 	pdata->eth_csr_addr = base_addr + BLOCK_ETH_CSR_OFFSET;
+	pdata->cle.base = base_addr + BLOCK_ETH_CLE_CSR_OFFSET;
 	pdata->eth_ring_if_addr = base_addr + BLOCK_ETH_RING_IF_OFFSET;
 	pdata->eth_diag_csr_addr = base_addr + BLOCK_ETH_DIAG_CSR_OFFSET;
 	if (pdata->phy_mode == PHY_INTERFACE_MODE_RGMII ||
@@ -1300,6 +1294,7 @@ static int xgene_enet_init_hw(struct xgene_enet_pdata *pdata)
 {
 	struct net_device *ndev = pdata->ndev;
 	struct xgene_enet_desc_ring *buf_pool;
+	struct xgene_enet_cle *enet_cle = &pdata->cle;
 	u16 dst_ring_num;
 	int ret;
 
@@ -1323,7 +1318,24 @@ static int xgene_enet_init_hw(struct xgene_enet_pdata *pdata)
 	}
 
 	dst_ring_num = xgene_enet_dst_ring_num(pdata->rx_ring);
-	pdata->port_ops->cle_bypass(pdata, dst_ring_num, buf_pool->id);
+	if (pdata->phy_mode == PHY_INTERFACE_MODE_XGMII) {
+		/* Initialize and Enable  PreClassifier Tree */
+		enet_cle->max_nodes = 512;
+		enet_cle->max_dbptrs = 1024;
+		enet_cle->parsers = 3;
+		enet_cle->active_parser = PARSER_ALL;
+		enet_cle->ptree.start_node = 0;
+		enet_cle->ptree.start_dbptr = 0;
+		enet_cle->jump_bytes = 8;
+		ret = pdata->cle_ops->cle_init(pdata);
+		if (ret) {
+			netdev_err(ndev, "Preclass Tree init error\n");
+			return ret;
+		}
+	} else {
+		pdata->port_ops->cle_bypass(pdata, dst_ring_num, buf_pool->id);
+	}
+
 	pdata->mac_ops->init(pdata);
 
 	return ret;
@@ -1345,6 +1357,7 @@ static void xgene_enet_setup_ops(struct xgene_enet_pdata *pdata)
 	default:
 		pdata->mac_ops = &xgene_xgmac_ops;
 		pdata->port_ops = &xgene_xgport_ops;
+		pdata->cle_ops = &xgene_cle3in_ops;
 		pdata->rm = RM0;
 		break;
 	}
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
index 248dfc4..05365c1 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
@@ -36,6 +36,7 @@
 #include <linux/if_vlan.h>
 #include <linux/phy.h>
 #include "xgene_enet_hw.h"
+#include "xgene_enet_cle.h"
 #include "xgene_enet_ring2.h"
 
 #define XGENE_DRV_VERSION	"v1.0"
@@ -145,6 +146,10 @@ struct xgene_ring_ops {
 	u32 (*len)(struct xgene_enet_desc_ring *);
 };
 
+struct xgene_cle_ops {
+	int (*cle_init)(struct xgene_enet_pdata *pdata);
+};
+
 /* ethernet private data */
 struct xgene_enet_pdata {
 	struct net_device *ndev;
@@ -174,10 +179,12 @@ struct xgene_enet_pdata {
 	void __iomem *ring_cmd_addr;
 	int phy_mode;
 	enum xgene_enet_rm rm;
+	struct xgene_enet_cle cle;
 	struct rtnl_link_stats64 stats;
 	const struct xgene_mac_ops *mac_ops;
 	const struct xgene_port_ops *port_ops;
 	struct xgene_ring_ops *ring_ops;
+	struct xgene_cle_ops *cle_ops;
 	struct delayed_work link_work;
 	u32 port_id;
 	u8 cpu_bufnum;
@@ -229,6 +236,13 @@ static inline struct device *ndev_to_dev(struct net_device *ndev)
 	return ndev->dev.parent;
 }
 
+static inline u16 xgene_enet_dst_ring_num(struct xgene_enet_desc_ring *ring)
+{
+	struct xgene_enet_pdata *pdata = netdev_priv(ring->ndev);
+
+	return ((u16)pdata->rm << 10) | ring->num;
+}
+
 void xgene_enet_set_ethtool_ops(struct net_device *netdev);
 
 #endif /* __XGENE_ENET_MAIN_H__ */
-- 
1.9.1



From isubramanian at apm.com  Fri Feb 12 17:37:03 2016
From: isubramanian at apm.com (Iyappan Subramanian)
Date: Fri, 12 Feb 2016 17:37:03 -0800
Subject: [PATCH net-next v2 2/4] drivers: net: xgene: Add support for RSS
In-Reply-To: <1455327425-8294-1-git-send-email-isubramanian@apm.com>
References: <1455327425-8294-1-git-send-email-isubramanian@apm.com>
Message-ID: <1455327425-8294-3-git-send-email-isubramanian@apm.com>

Signed-off-by: Iyappan Subramanian <isubramanian at apm.com>
Signed-off-by: Khuong Dinh <kdinh at apm.com>
Signed-off-by: Tanmay Inamdar <tinamdar at apm.com>
Tested-by: Toan Le <toanle at apm.com>
---
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c | 386 +++++++++++++++++++++++-
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.h |  41 +++
 2 files changed, 422 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
index 7eea982..933eac4 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
@@ -21,6 +21,25 @@
 
 #include "xgene_enet_main.h"
 
+/* interfaces to convert structures to HW recognized bit formats */
+static void xgene_cle_sband_to_hw(u8 frag, enum xgene_cle_prot_version ver,
+				  enum xgene_cle_prot_type type, u32 len,
+				  u32 *reg)
+{
+	*reg =  SET_VAL(SB_IPFRAG, frag) |
+		SET_VAL(SB_IPPROT, type) |
+		SET_VAL(SB_IPVER, ver) |
+		SET_VAL(SB_HDRLEN, len);
+}
+
+static void xgene_cle_idt_to_hw(u32 dstqid, u32 fpsel,
+				u32 nfpsel, u32 *idt_reg)
+{
+	*idt_reg =  SET_VAL(IDT_DSTQID, dstqid) |
+		    SET_VAL(IDT_FPSEL, fpsel) |
+		    SET_VAL(IDT_NFPSEL, nfpsel);
+}
+
 static void xgene_cle_dbptr_to_hw(struct xgene_enet_pdata *pdata,
 				  struct xgene_cle_dbptr *dbptr, u32 *buf)
 {
@@ -258,29 +277,372 @@ static void xgene_cle_setup_def_dbptr(struct xgene_enet_pdata *pdata,
 	}
 }
 
+static int xgene_cle_set_rss_sband(struct xgene_enet_cle *cle)
+{
+	u32 sband, reg = 0;
+	u32 idx = CLE_PKTRAM_SIZE / sizeof(u32);
+	u32 mac_hdr_len = 14;
+	u32 ipv4_ihl = 5;
+	u32 hdr_len;
+	int ret;
+
+	/* Sideband: IPV4/TCP packets */
+	hdr_len = (mac_hdr_len << 5) | ipv4_ihl;
+	xgene_cle_sband_to_hw(0, XGENE_CLE_IPV4, XGENE_CLE_TCP, hdr_len, &reg);
+	sband = reg;
+
+	/* Sideband: IPv4/UDP packets */
+	hdr_len = (mac_hdr_len << 5) | ipv4_ihl;
+	xgene_cle_sband_to_hw(1, XGENE_CLE_IPV4, XGENE_CLE_UDP, hdr_len, &reg);
+	sband |= (reg << 16);
+
+	ret = xgene_cle_dram_wr(cle, &sband, 1, idx, PKT_RAM, CLE_CMD_WR);
+	if (ret)
+		return ret;
+
+	/* Sideband: IPv4/RAW packets */
+	hdr_len = (mac_hdr_len << 5) | ipv4_ihl;
+	xgene_cle_sband_to_hw(0, XGENE_CLE_IPV4, XGENE_CLE_OTHER,
+			      hdr_len, &reg);
+	sband = reg;
+
+	/* Sideband: Ethernet II/RAW packets */
+	hdr_len = (mac_hdr_len << 5);
+	xgene_cle_sband_to_hw(0, XGENE_CLE_IPV4, XGENE_CLE_OTHER,
+			      hdr_len, &reg);
+	sband |= (reg << 16);
+
+	ret = xgene_cle_dram_wr(cle, &sband, 1, idx + 1, PKT_RAM, CLE_CMD_WR);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int xgene_cle_set_rss_skeys(struct xgene_enet_cle *cle)
+{
+	int ret = 0;
+	u32 secret_key_ipv4[4];  /* 16 Bytes*/
+
+	get_random_bytes(secret_key_ipv4, 16);
+	ret = xgene_cle_dram_wr(cle, secret_key_ipv4, 4, 0,
+				RSS_IPV4_HASH_SKEY, CLE_CMD_WR);
+	return ret;
+}
+
+static int xgene_cle_set_rss_idt(struct xgene_enet_pdata *pdata)
+{
+	int i, ret = 0;
+	u32 fpsel, dstqid, nfpsel, idt_reg;
+	u16 pool_id;
+
+	for (i = 0; i < XGENE_CLE_IDT_ENTRIES; i++) {
+		pool_id = pdata->rx_ring->buf_pool->id;
+		fpsel = xgene_enet_ring_bufnum(pool_id) - 0x20;
+		dstqid = xgene_enet_dst_ring_num(pdata->rx_ring);
+		nfpsel = 0;
+		idt_reg = 0;
+
+		xgene_cle_idt_to_hw(dstqid, fpsel, nfpsel, &idt_reg);
+		ret = xgene_cle_dram_wr(&pdata->cle, &idt_reg, 1, i,
+					RSS_IDT, CLE_CMD_WR);
+		if (ret)
+			return ret;
+	}
+
+	ret = xgene_cle_set_rss_skeys(&pdata->cle);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int xgene_cle_setup_rss(struct xgene_enet_pdata *pdata)
+{
+	struct xgene_enet_cle *cle = &pdata->cle;
+	void __iomem *base = cle->base;
+	u32 offset, val = 0;
+	int i, ret = 0;
+
+	offset = CLE_PORT_OFFSET;
+	for (i = 0; i < cle->parsers; i++) {
+		if (cle->active_parser != PARSER_ALL)
+			offset = cle->active_parser * CLE_PORT_OFFSET;
+		else
+			offset = i * CLE_PORT_OFFSET;
+
+		/* enable RSS */
+		val = (RSS_IPV4_12B << 1) | 0x1;
+		writel(val, base + RSS_CTRL0 + offset);
+	}
+
+	/* setup sideband data */
+	ret = xgene_cle_set_rss_sband(cle);
+	if (ret)
+		return ret;
+
+	/* setup indirection table */
+	ret = xgene_cle_set_rss_idt(pdata);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
 static int xgene_enet_cle_init(struct xgene_enet_pdata *pdata)
 {
 	struct xgene_enet_cle *enet_cle = &pdata->cle;
 	struct xgene_cle_ptree *ptree = &enet_cle->ptree;
 	struct xgene_cle_dbptr dbptr[DB_MAX_PTRS];
 	struct xgene_cle_ptree_kn kn;
+	struct xgene_cle_ptree_branch *br;
 	u32 def_qid, def_fpsel, pool_id;
+	int ret;
 	struct xgene_cle_ptree_ewdn ptree_dn[] = {
 		{
 			/* PKT_TYPE_NODE */
 			.node_type = EWDN,
 			.last_node = 0,
-			.hdr_len_store = 0,
+			.hdr_len_store = 1,
 			.hdr_extn = NO_BYTE,
 			.byte_store = NO_BYTE,
 			.search_byte_store = NO_BYTE,
 			.result_pointer = DB_RES_DROP,
-			.num_branches = 1,
+			.num_branches = 2,
 			.branch = {
 				{
-					/* Allow all packet type */
+					/* IPV4 */
 					.valid = 0,
-					.next_packet_pointer = 0,
+					.next_packet_pointer = 22,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = PKT_PROT_NODE,
+					.next_branch = 0,
+					.data = 0x8,
+					.mask = 0xffff
+				},
+				{
+					.valid = 0,
+					.next_packet_pointer = 262,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = LAST_NODE,
+					.next_branch = 0,
+					.data = 0x0,
+					.mask = 0xffff
+				}
+			},
+		},
+		{
+			/* PKT_PROT_NODE */
+			.node_type = EWDN,
+			.last_node = 0,
+			.hdr_len_store = 1,
+			.hdr_extn = NO_BYTE,
+			.byte_store = NO_BYTE,
+			.search_byte_store = NO_BYTE,
+			.result_pointer = DB_RES_DROP,
+			.num_branches = 3,
+			.branch = {
+				{
+					/* TCP */
+					.valid = 1,
+					.next_packet_pointer = 26,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 0,
+					.data = 0x0600,
+					.mask = 0xffff
+				},
+				{
+					/* UDP */
+					.valid = 1,
+					.next_packet_pointer = 26,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 0,
+					.data = 0x1100,
+					.mask = 0xffff
+				},
+				{
+					.valid = 0,
+					.next_packet_pointer = 260,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = LAST_NODE,
+					.next_branch = 0,
+					.data = 0x0,
+					.mask = 0xffff
+				}
+			}
+		},
+		{
+			/* RSS_IPV4_TCP_NODE */
+			.node_type = EWDN,
+			.last_node = 0,
+			.hdr_len_store = 1,
+			.hdr_extn = NO_BYTE,
+			.byte_store = NO_BYTE,
+			.search_byte_store = BOTH_BYTES,
+			.result_pointer = DB_RES_DROP,
+			.num_branches = 6,
+			.branch = {
+				{
+					/* SRC IPV4 B01 */
+					.valid = 0,
+					.next_packet_pointer = 28,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 1,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* SRC IPV4 B23 */
+					.valid = 0,
+					.next_packet_pointer = 30,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 2,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* DST IPV4 B01 */
+					.valid = 0,
+					.next_packet_pointer = 32,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 3,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* DST IPV4 B23 */
+					.valid = 0,
+					.next_packet_pointer = 34,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 4,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* TCP SRC Port */
+					.valid = 0,
+					.next_packet_pointer = 36,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 5,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* TCP DST Port */
+					.valid = 0,
+					.next_packet_pointer = 256,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = LAST_NODE,
+					.next_branch = 0,
+					.data = 0x0,
+					.mask = 0xffff
+				}
+			}
+		},
+		{
+			/* RSS_IPV4_UDP_NODE */
+			.node_type = EWDN,
+			.last_node = 0,
+			.hdr_len_store = 1,
+			.hdr_extn = NO_BYTE,
+			.byte_store = NO_BYTE,
+			.search_byte_store = BOTH_BYTES,
+			.result_pointer = DB_RES_DROP,
+			.num_branches = 6,
+			.branch = {
+				{
+					/* SRC IPV4 B01 */
+					.valid = 0,
+					.next_packet_pointer = 28,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 1,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* SRC IPV4 B23 */
+					.valid = 0,
+					.next_packet_pointer = 30,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 2,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* DST IPV4 B01 */
+					.valid = 0,
+					.next_packet_pointer = 32,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 3,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* DST IPV4 B23 */
+					.valid = 0,
+					.next_packet_pointer = 34,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 4,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* TCP SRC Port */
+					.valid = 0,
+					.next_packet_pointer = 36,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 5,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* TCP DST Port */
+					.valid = 0,
+					.next_packet_pointer = 256,
 					.jump_bw = JMP_FW,
 					.jump_rel = JMP_ABS,
 					.operation = EQT,
@@ -295,7 +657,7 @@ static int xgene_enet_cle_init(struct xgene_enet_pdata *pdata)
 			/* LAST NODE */
 			.node_type = EWDN,
 			.last_node = 1,
-			.hdr_len_store = 0,
+			.hdr_len_store = 1,
 			.hdr_extn = NO_BYTE,
 			.byte_store = NO_BYTE,
 			.search_byte_store = NO_BYTE,
@@ -318,6 +680,20 @@ static int xgene_enet_cle_init(struct xgene_enet_pdata *pdata)
 	};
 
 	ptree->start_pkt = 12; /* Ethertype */
+	if (pdata->phy_mode == PHY_INTERFACE_MODE_XGMII) {
+		ret = xgene_cle_setup_rss(pdata);
+		if (ret) {
+			netdev_err(pdata->ndev, "RSS initialization failed\n");
+			return ret;
+		}
+	} else {
+		br = &ptree_dn[PKT_PROT_NODE].branch[0];
+		br->valid = 0;
+		br->next_packet_pointer = 260;
+		br->next_node = LAST_NODE;
+		br->data = 0x0000;
+		br->mask = 0xffff;
+	}
 
 	def_qid = xgene_enet_dst_ring_num(pdata->rx_ring);
 	pool_id = pdata->rx_ring->buf_pool->id;
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h
index 1db2fd7..29a17ab 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h
@@ -34,6 +34,7 @@
 #define SPPTR0			0x0104
 #define DFCLSRESDBPTR0		0x0108
 #define DFCLSRESDB00		0x010c
+#define RSS_CTRL0		0x0000013c
 
 #define CLE_CMD_TO		10	/* ms */
 #define CLE_PKTRAM_SIZE		256	/* bytes */
@@ -98,6 +99,9 @@
 
 enum xgene_cle_ptree_nodes {
 	PKT_TYPE_NODE,
+	PKT_PROT_NODE,
+	RSS_IPV4_TCP_NODE,
+	RSS_IPV4_UDP_NODE,
 	LAST_NODE,
 	MAX_NODES
 };
@@ -137,6 +141,8 @@ enum xgene_cle_parser {
 #define XGENE_CLE_DRAM(type)	(((type) & 0xf) << 28)
 enum xgene_cle_dram_type {
 	PKT_RAM,
+	RSS_IDT,
+	RSS_IPV4_HASH_SKEY,
 	PTREE_RAM = 0xc,
 	AVL_RAM,
 	DB_RAM
@@ -150,6 +156,22 @@ enum xgene_cle_cmd_type {
 	CLE_CMD_AVL_SRCH = 32
 };
 
+enum xgene_cle_ipv4_rss_hashtype {
+	RSS_IPV4_8B,
+	RSS_IPV4_12B,
+};
+
+enum xgene_cle_prot_type {
+	XGENE_CLE_TCP,
+	XGENE_CLE_UDP,
+	XGENE_CLE_ESP,
+	XGENE_CLE_OTHER
+};
+
+enum xgene_cle_prot_version {
+	XGENE_CLE_IPV4,
+};
+
 enum xgene_cle_ptree_dbptrs {
 	DB_RES_DROP,
 	DB_RES_DEF,
@@ -157,6 +179,25 @@ enum xgene_cle_ptree_dbptrs {
 	DB_MAX_PTRS
 };
 
+/* RSS sideband signal info */
+#define SB_IPFRAG_POS	0
+#define SB_IPFRAG_LEN	1
+#define SB_IPPROT_POS	1
+#define SB_IPPROT_LEN	2
+#define SB_IPVER_POS	3
+#define SB_IPVER_LEN	1
+#define SB_HDRLEN_POS	4
+#define SB_HDRLEN_LEN	12
+
+/* RSS indirection table */
+#define XGENE_CLE_IDT_ENTRIES	128
+#define IDT_DSTQID_POS		0
+#define IDT_DSTQID_LEN		12
+#define IDT_FPSEL_POS		12
+#define IDT_FPSEL_LEN		4
+#define IDT_NFPSEL_POS		16
+#define IDT_NFPSEL_LEN		4
+
 struct xgene_cle_ptree_branch {
 	bool valid;
 	u16 next_packet_pointer;
-- 
1.9.1



From isubramanian at apm.com  Fri Feb 12 17:37:05 2016
From: isubramanian at apm.com (Iyappan Subramanian)
Date: Fri, 12 Feb 2016 17:37:05 -0800
Subject: [PATCH net-next v2 4/4] dtb: xgene: Add irqs to support multi queue
In-Reply-To: <1455327425-8294-1-git-send-email-isubramanian@apm.com>
References: <1455327425-8294-1-git-send-email-isubramanian@apm.com>
Message-ID: <1455327425-8294-5-git-send-email-isubramanian@apm.com>

Signed-off-by: Iyappan Subramanian <isubramanian at apm.com>
Signed-off-by: Khuong Dinh <kdinh at apm.com>
Signed-off-by: Tanmay Inamdar <tinamdar at apm.com>
Tested-by: Toan Le <toanle at apm.com>
---
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 8 +++++++-
 arch/arm64/boot/dts/apm/apm-storm.dtsi     | 8 +++++++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index 5d87a3d..278f106 100644
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -621,7 +621,13 @@
 			      <0x0 0x1f600000 0x0 0Xd100>,
 			      <0x0 0x20000000 0x0 0X220000>;
 			interrupts = <0 108 4>,
-				     <0 109 4>;
+				     <0 109 4>,
+				     <0 110 4>,
+				     <0 111 4>,
+				     <0 112 4>,
+				     <0 113 4>,
+				     <0 114 4>,
+				     <0 115 4>;
 			port-id = <1>;
 			dma-coherent;
 			clocks = <&xge1clk 0>;
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index fe30f76..cafb2c2 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -958,7 +958,13 @@
 			      <0x0 0x18000000 0x0 0X200>;
 			reg-names = "enet_csr", "ring_csr", "ring_cmd";
 			interrupts = <0x0 0x60 0x4>,
-				     <0x0 0x61 0x4>;
+				     <0x0 0x61 0x4>,
+				     <0x0 0x62 0x4>,
+				     <0x0 0x63 0x4>,
+				     <0x0 0x64 0x4>,
+				     <0x0 0x65 0x4>,
+				     <0x0 0x66 0x4>,
+				     <0x0 0x67 0x4>;
 			dma-coherent;
 			clocks = <&xge0clk 0>;
 			/* mac address will be overwritten by the bootloader */
-- 
1.9.1



From isubramanian at apm.com  Fri Feb 12 17:37:04 2016
From: isubramanian at apm.com (Iyappan Subramanian)
Date: Fri, 12 Feb 2016 17:37:04 -0800
Subject: [PATCH net-next v2 3/4] drivers: net: xgene: Add support for multiple
 queues
In-Reply-To: <1455327425-8294-1-git-send-email-isubramanian@apm.com>
References: <1455327425-8294-1-git-send-email-isubramanian@apm.com>
Message-ID: <1455327425-8294-4-git-send-email-isubramanian@apm.com>

Signed-off-by: Iyappan Subramanian <isubramanian at apm.com>
Signed-off-by: Khuong Dinh <kdinh at apm.com>
Signed-off-by: Tanmay Inamdar <tinamdar at apm.com>
Tested-by: Toan Le <toanle at apm.com>
---
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c   |  11 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c    |  12 +
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h    |   5 +
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c  | 453 +++++++++++++---------
 drivers/net/ethernet/apm/xgene/xgene_enet_main.h  |  21 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c |  12 +
 6 files changed, 320 insertions(+), 194 deletions(-)

diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
index 933eac4..3ad7c68 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
@@ -333,13 +333,14 @@ static int xgene_cle_set_rss_skeys(struct xgene_enet_cle *cle)
 static int xgene_cle_set_rss_idt(struct xgene_enet_pdata *pdata)
 {
 	int i, ret = 0;
-	u32 fpsel, dstqid, nfpsel, idt_reg;
+	u32 fpsel, dstqid, nfpsel, idt_reg, idx;
 	u16 pool_id;
 
 	for (i = 0; i < XGENE_CLE_IDT_ENTRIES; i++) {
-		pool_id = pdata->rx_ring->buf_pool->id;
+		idx = i % pdata->rxq_cnt;
+		pool_id = pdata->rx_ring[idx]->buf_pool->id;
 		fpsel = xgene_enet_ring_bufnum(pool_id) - 0x20;
-		dstqid = xgene_enet_dst_ring_num(pdata->rx_ring);
+		dstqid = xgene_enet_dst_ring_num(pdata->rx_ring[idx]);
 		nfpsel = 0;
 		idt_reg = 0;
 
@@ -695,8 +696,8 @@ static int xgene_enet_cle_init(struct xgene_enet_pdata *pdata)
 		br->mask = 0xffff;
 	}
 
-	def_qid = xgene_enet_dst_ring_num(pdata->rx_ring);
-	pool_id = pdata->rx_ring->buf_pool->id;
+	def_qid = xgene_enet_dst_ring_num(pdata->rx_ring[0]);
+	pool_id = pdata->rx_ring[0]->buf_pool->id;
 	def_fpsel = xgene_enet_ring_bufnum(pool_id) - 0x20;
 
 	memset(dbptr, 0, sizeof(struct xgene_cle_dbptr) * DB_MAX_PTRS);
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index db55c9f..39e081a 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -204,6 +204,17 @@ static u32 xgene_enet_ring_len(struct xgene_enet_desc_ring *ring)
 	return num_msgs;
 }
 
+static void xgene_enet_setup_coalescing(struct xgene_enet_desc_ring *ring)
+{
+	u32 data = 0x7777;
+
+	xgene_enet_ring_wr32(ring, CSR_PBM_COAL, 0x8e);
+	xgene_enet_ring_wr32(ring, CSR_PBM_CTICK1, data);
+	xgene_enet_ring_wr32(ring, CSR_PBM_CTICK2, data << 16);
+	xgene_enet_ring_wr32(ring, CSR_THRESHOLD0_SET1, 0x40);
+	xgene_enet_ring_wr32(ring, CSR_THRESHOLD1_SET1, 0x80);
+}
+
 void xgene_enet_parse_error(struct xgene_enet_desc_ring *ring,
 			    struct xgene_enet_pdata *pdata,
 			    enum xgene_enet_err_code status)
@@ -892,4 +903,5 @@ struct xgene_ring_ops xgene_ring1_ops = {
 	.clear = xgene_enet_clear_ring,
 	.wr_cmd = xgene_enet_wr_cmd,
 	.len = xgene_enet_ring_len,
+	.coalesce = xgene_enet_setup_coalescing,
 };
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
index 45725ec..ba7da98 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
@@ -54,6 +54,11 @@ enum xgene_enet_rm {
 #define IS_BUFFER_POOL		BIT(20)
 #define PREFETCH_BUF_EN		BIT(21)
 #define CSR_RING_ID_BUF		0x000c
+#define CSR_PBM_COAL		0x0014
+#define CSR_PBM_CTICK1		0x001c
+#define CSR_PBM_CTICK2		0x0020
+#define CSR_THRESHOLD0_SET1	0x0030
+#define CSR_THRESHOLD1_SET1	0x0034
 #define CSR_RING_NE_INT_MODE	0x017c
 #define CSR_RING_CONFIG		0x006c
 #define CSR_RING_WR_BASE	0x0070
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 2716d45..8b7f5ca 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -182,7 +182,6 @@ static int xgene_enet_tx_completion(struct xgene_enet_desc_ring *cp_ring,
 static u64 xgene_enet_work_msg(struct sk_buff *skb)
 {
 	struct net_device *ndev = skb->dev;
-	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 	struct iphdr *iph;
 	u8 l3hlen = 0, l4hlen = 0;
 	u8 ethhdr, proto = 0, csum_enable = 0;
@@ -228,10 +227,6 @@ static u64 xgene_enet_work_msg(struct sk_buff *skb)
 			if (!mss || ((skb->len - hdr_len) <= mss))
 				goto out;
 
-			if (mss != pdata->mss) {
-				pdata->mss = mss;
-				pdata->mac_ops->set_mss(pdata);
-			}
 			hopinfo |= SET_BIT(ET);
 		}
 	} else if (iph->protocol == IPPROTO_UDP) {
@@ -413,7 +408,7 @@ out:
 	raw_desc->m0 = cpu_to_le64(SET_VAL(LL, ll) | SET_VAL(NV, nv) |
 				   SET_VAL(USERINFO, tx_ring->tail));
 	tx_ring->cp_ring->cp_skb[tx_ring->tail] = skb;
-	pdata->tx_level += count;
+	pdata->tx_level[tx_ring->cp_ring->index] += count;
 	tx_ring->tail = tail;
 
 	return count;
@@ -423,15 +418,17 @@ static netdev_tx_t xgene_enet_start_xmit(struct sk_buff *skb,
 					 struct net_device *ndev)
 {
 	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
-	struct xgene_enet_desc_ring *tx_ring = pdata->tx_ring;
-	u32 tx_level = pdata->tx_level;
+	struct xgene_enet_desc_ring *tx_ring;
+	int index = skb->queue_mapping;
+	u32 tx_level = pdata->tx_level[index];
 	int count;
 
-	if (tx_level < pdata->txc_level)
-		tx_level += ((typeof(pdata->tx_level))~0U);
+	tx_ring = pdata->tx_ring[index];
+	if (tx_level < pdata->txc_level[index])
+		tx_level += ((typeof(pdata->tx_level[index]))~0U);
 
-	if ((tx_level - pdata->txc_level) > pdata->tx_qcnt_hi) {
-		netif_stop_queue(ndev);
+	if ((tx_level - pdata->txc_level[index]) > pdata->tx_qcnt_hi) {
+		netif_stop_subqueue(ndev, index);
 		return NETDEV_TX_BUSY;
 	}
 
@@ -529,7 +526,8 @@ static bool is_rx_desc(struct xgene_enet_raw_desc *raw_desc)
 static int xgene_enet_process_ring(struct xgene_enet_desc_ring *ring,
 				   int budget)
 {
-	struct xgene_enet_pdata *pdata = netdev_priv(ring->ndev);
+	struct net_device *ndev = ring->ndev;
+	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 	struct xgene_enet_raw_desc *raw_desc, *exp_desc;
 	u16 head = ring->head;
 	u16 slots = ring->slots - 1;
@@ -573,7 +571,7 @@ static int xgene_enet_process_ring(struct xgene_enet_desc_ring *ring,
 		desc_count++;
 		processed++;
 		if (is_completion)
-			pdata->txc_level += desc_count;
+			pdata->txc_level[ring->index] += desc_count;
 
 		if (ret)
 			break;
@@ -583,8 +581,8 @@ static int xgene_enet_process_ring(struct xgene_enet_desc_ring *ring,
 		pdata->ring_ops->wr_cmd(ring, -count);
 		ring->head = head;
 
-		if (netif_queue_stopped(ring->ndev))
-			netif_start_queue(ring->ndev);
+		if (__netif_subqueue_stopped(ndev, ring->index))
+			netif_start_subqueue(ndev, ring->index);
 	}
 
 	return processed;
@@ -609,8 +607,16 @@ static int xgene_enet_napi(struct napi_struct *napi, const int budget)
 static void xgene_enet_timeout(struct net_device *ndev)
 {
 	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
+	struct netdev_queue *txq;
+	int i;
 
 	pdata->mac_ops->reset(pdata);
+
+	for (i = 0; i < pdata->txq_cnt; i++) {
+		txq = netdev_get_tx_queue(ndev, i);
+		txq->trans_start = jiffies;
+		netif_tx_start_queue(txq);
+	}
 }
 
 static int xgene_enet_register_irq(struct net_device *ndev)
@@ -618,17 +624,21 @@ static int xgene_enet_register_irq(struct net_device *ndev)
 	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 	struct device *dev = ndev_to_dev(ndev);
 	struct xgene_enet_desc_ring *ring;
-	int ret;
+	int ret = 0, i;
 
-	ring = pdata->rx_ring;
-	irq_set_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
-	ret = devm_request_irq(dev, ring->irq, xgene_enet_rx_irq,
-			       IRQF_SHARED, ring->irq_name, ring);
-	if (ret)
-		netdev_err(ndev, "Failed to request irq %s\n", ring->irq_name);
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		ring = pdata->rx_ring[i];
+		irq_set_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
+		ret = devm_request_irq(dev, ring->irq, xgene_enet_rx_irq,
+				       IRQF_SHARED, ring->irq_name, ring);
+		if (ret) {
+			netdev_err(ndev, "Failed to request irq %s\n",
+				   ring->irq_name);
+		}
+	}
 
-	if (pdata->cq_cnt) {
-		ring = pdata->tx_ring->cp_ring;
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		ring = pdata->tx_ring[i]->cp_ring;
 		irq_set_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
 		ret = devm_request_irq(dev, ring->irq, xgene_enet_rx_irq,
 				       IRQF_SHARED, ring->irq_name, ring);
@@ -646,15 +656,19 @@ static void xgene_enet_free_irq(struct net_device *ndev)
 	struct xgene_enet_pdata *pdata;
 	struct xgene_enet_desc_ring *ring;
 	struct device *dev;
+	int i;
 
 	pdata = netdev_priv(ndev);
 	dev = ndev_to_dev(ndev);
-	ring = pdata->rx_ring;
-	irq_clear_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
-	devm_free_irq(dev, ring->irq, ring);
 
-	if (pdata->cq_cnt) {
-		ring = pdata->tx_ring->cp_ring;
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		ring = pdata->rx_ring[i];
+		irq_clear_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
+		devm_free_irq(dev, ring->irq, ring);
+	}
+
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		ring = pdata->tx_ring[i]->cp_ring;
 		irq_clear_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
 		devm_free_irq(dev, ring->irq, ring);
 	}
@@ -663,12 +677,15 @@ static void xgene_enet_free_irq(struct net_device *ndev)
 static void xgene_enet_napi_enable(struct xgene_enet_pdata *pdata)
 {
 	struct napi_struct *napi;
+	int i;
 
-	napi = &pdata->rx_ring->napi;
-	napi_enable(napi);
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		napi = &pdata->rx_ring[i]->napi;
+		napi_enable(napi);
+	}
 
-	if (pdata->cq_cnt) {
-		napi = &pdata->tx_ring->cp_ring->napi;
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		napi = &pdata->tx_ring[i]->cp_ring->napi;
 		napi_enable(napi);
 	}
 }
@@ -676,12 +693,15 @@ static void xgene_enet_napi_enable(struct xgene_enet_pdata *pdata)
 static void xgene_enet_napi_disable(struct xgene_enet_pdata *pdata)
 {
 	struct napi_struct *napi;
+	int i;
 
-	napi = &pdata->rx_ring->napi;
-	napi_disable(napi);
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		napi = &pdata->rx_ring[i]->napi;
+		napi_disable(napi);
+	}
 
-	if (pdata->cq_cnt) {
-		napi = &pdata->tx_ring->cp_ring->napi;
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		napi = &pdata->tx_ring[i]->cp_ring->napi;
 		napi_disable(napi);
 	}
 }
@@ -692,6 +712,14 @@ static int xgene_enet_open(struct net_device *ndev)
 	const struct xgene_mac_ops *mac_ops = pdata->mac_ops;
 	int ret;
 
+	ret = netif_set_real_num_tx_queues(ndev, pdata->txq_cnt);
+	if (ret)
+		return ret;
+
+	ret = netif_set_real_num_rx_queues(ndev, pdata->rxq_cnt);
+	if (ret)
+		return ret;
+
 	mac_ops->tx_enable(pdata);
 	mac_ops->rx_enable(pdata);
 
@@ -714,6 +742,7 @@ static int xgene_enet_close(struct net_device *ndev)
 {
 	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 	const struct xgene_mac_ops *mac_ops = pdata->mac_ops;
+	int i;
 
 	netif_stop_queue(ndev);
 
@@ -727,7 +756,8 @@ static int xgene_enet_close(struct net_device *ndev)
 
 	xgene_enet_free_irq(ndev);
 	xgene_enet_napi_disable(pdata);
-	xgene_enet_process_ring(pdata->rx_ring, -1);
+	for (i = 0; i < pdata->rxq_cnt; i++)
+		xgene_enet_process_ring(pdata->rx_ring[i], -1);
 
 	return 0;
 }
@@ -747,18 +777,26 @@ static void xgene_enet_delete_ring(struct xgene_enet_desc_ring *ring)
 static void xgene_enet_delete_desc_rings(struct xgene_enet_pdata *pdata)
 {
 	struct xgene_enet_desc_ring *buf_pool;
+	struct xgene_enet_desc_ring *ring;
+	int i;
 
-	if (pdata->tx_ring) {
-		xgene_enet_delete_ring(pdata->tx_ring);
-		pdata->tx_ring = NULL;
+	for (i = 0; i < pdata->txq_cnt; i++) {
+		ring = pdata->tx_ring[i];
+		if (ring) {
+			xgene_enet_delete_ring(ring);
+			pdata->tx_ring[i] = NULL;
+		}
 	}
 
-	if (pdata->rx_ring) {
-		buf_pool = pdata->rx_ring->buf_pool;
-		xgene_enet_delete_bufpool(buf_pool);
-		xgene_enet_delete_ring(buf_pool);
-		xgene_enet_delete_ring(pdata->rx_ring);
-		pdata->rx_ring = NULL;
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		ring = pdata->rx_ring[i];
+		if (ring) {
+			buf_pool = ring->buf_pool;
+			xgene_enet_delete_bufpool(buf_pool);
+			xgene_enet_delete_ring(buf_pool);
+			xgene_enet_delete_ring(ring);
+			pdata->rx_ring[i] = NULL;
+		}
 	}
 }
 
@@ -813,24 +851,29 @@ static void xgene_enet_free_desc_rings(struct xgene_enet_pdata *pdata)
 {
 	struct device *dev = &pdata->pdev->dev;
 	struct xgene_enet_desc_ring *ring;
+	int i;
 
-	ring = pdata->tx_ring;
-	if (ring) {
-		if (ring->cp_ring && ring->cp_ring->cp_skb)
-			devm_kfree(dev, ring->cp_ring->cp_skb);
-		if (ring->cp_ring && pdata->cq_cnt)
-			xgene_enet_free_desc_ring(ring->cp_ring);
-		xgene_enet_free_desc_ring(ring);
-	}
-
-	ring = pdata->rx_ring;
-	if (ring) {
-		if (ring->buf_pool) {
-			if (ring->buf_pool->rx_skb)
-				devm_kfree(dev, ring->buf_pool->rx_skb);
-			xgene_enet_free_desc_ring(ring->buf_pool);
+	for (i = 0; i < pdata->txq_cnt; i++) {
+		ring = pdata->tx_ring[i];
+		if (ring) {
+			if (ring->cp_ring && ring->cp_ring->cp_skb)
+				devm_kfree(dev, ring->cp_ring->cp_skb);
+			if (ring->cp_ring && pdata->cq_cnt)
+				xgene_enet_free_desc_ring(ring->cp_ring);
+			xgene_enet_free_desc_ring(ring);
+		}
+	}
+
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		ring = pdata->rx_ring[i];
+		if (ring) {
+			if (ring->buf_pool) {
+				if (ring->buf_pool->rx_skb)
+					devm_kfree(dev, ring->buf_pool->rx_skb);
+				xgene_enet_free_desc_ring(ring->buf_pool);
+			}
+			xgene_enet_free_desc_ring(ring);
 		}
-		xgene_enet_free_desc_ring(ring);
 	}
 }
 
@@ -943,104 +986,120 @@ static int xgene_enet_create_desc_rings(struct net_device *ndev)
 	u8 bp_bufnum = pdata->bp_bufnum;
 	u16 ring_num = pdata->ring_num;
 	u16 ring_id;
-	int ret, size;
-
-	/* allocate rx descriptor ring */
-	owner = xgene_derive_ring_owner(pdata);
-	ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU, cpu_bufnum++);
-	rx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
-					      RING_CFGSIZE_16KB, ring_id);
-	if (!rx_ring) {
-		ret = -ENOMEM;
-		goto err;
-	}
-
-	/* allocate buffer pool for receiving packets */
-	owner = xgene_derive_ring_owner(pdata);
-	ring_id = xgene_enet_get_ring_id(owner, bp_bufnum++);
-	buf_pool = xgene_enet_create_desc_ring(ndev, ring_num++,
-					       RING_CFGSIZE_2KB, ring_id);
-	if (!buf_pool) {
-		ret = -ENOMEM;
-		goto err;
-	}
+	int i, ret, size;
 
-	rx_ring->nbufpool = NUM_BUFPOOL;
-	rx_ring->buf_pool = buf_pool;
-	rx_ring->irq = pdata->rx_irq;
-	if (!pdata->cq_cnt) {
-		snprintf(rx_ring->irq_name, IRQ_ID_SIZE, "%s-rx-txc",
-			 ndev->name);
-	} else {
-		snprintf(rx_ring->irq_name, IRQ_ID_SIZE, "%s-rx", ndev->name);
-	}
-	buf_pool->rx_skb = devm_kcalloc(dev, buf_pool->slots,
-					sizeof(struct sk_buff *), GFP_KERNEL);
-	if (!buf_pool->rx_skb) {
-		ret = -ENOMEM;
-		goto err;
-	}
-
-	buf_pool->dst_ring_num = xgene_enet_dst_ring_num(buf_pool);
-	rx_ring->buf_pool = buf_pool;
-	pdata->rx_ring = rx_ring;
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		/* allocate rx descriptor ring */
+		owner = xgene_derive_ring_owner(pdata);
+		ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU, cpu_bufnum++);
+		rx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
+						      RING_CFGSIZE_16KB,
+						      ring_id);
+		if (!rx_ring) {
+			ret = -ENOMEM;
+			goto err;
+		}
 
-	/* allocate tx descriptor ring */
-	owner = xgene_derive_ring_owner(pdata);
-	ring_id = xgene_enet_get_ring_id(owner, eth_bufnum++);
-	tx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
-					      RING_CFGSIZE_16KB, ring_id);
-	if (!tx_ring) {
-		ret = -ENOMEM;
-		goto err;
-	}
+		/* allocate buffer pool for receiving packets */
+		owner = xgene_derive_ring_owner(pdata);
+		ring_id = xgene_enet_get_ring_id(owner, bp_bufnum++);
+		buf_pool = xgene_enet_create_desc_ring(ndev, ring_num++,
+						       RING_CFGSIZE_2KB,
+						       ring_id);
+		if (!buf_pool) {
+			ret = -ENOMEM;
+			goto err;
+		}
 
-	size = (tx_ring->slots / 2) * sizeof(__le64) * MAX_EXP_BUFFS;
-	tx_ring->exp_bufs = dma_zalloc_coherent(dev, size, &dma_exp_bufs,
+		rx_ring->nbufpool = NUM_BUFPOOL;
+		rx_ring->buf_pool = buf_pool;
+		rx_ring->irq = pdata->irqs[i];
+		if (!pdata->cq_cnt) {
+			snprintf(rx_ring->irq_name, IRQ_ID_SIZE, "%s-rx-txc",
+				 ndev->name);
+		} else {
+			snprintf(rx_ring->irq_name, IRQ_ID_SIZE, "%s-rx%d",
+				 ndev->name, i);
+		}
+		buf_pool->rx_skb = devm_kcalloc(dev, buf_pool->slots,
+						sizeof(struct sk_buff *),
 						GFP_KERNEL);
-	if (!tx_ring->exp_bufs) {
-		ret = -ENOMEM;
-		goto err;
-	}
+		if (!buf_pool->rx_skb) {
+			ret = -ENOMEM;
+			goto err;
+		}
 
-	pdata->tx_ring = tx_ring;
+		buf_pool->dst_ring_num = xgene_enet_dst_ring_num(buf_pool);
+		rx_ring->buf_pool = buf_pool;
+		pdata->rx_ring[i] = rx_ring;
+	}
 
-	if (!pdata->cq_cnt) {
-		cp_ring = pdata->rx_ring;
-	} else {
-		/* allocate tx completion descriptor ring */
-		ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU, cpu_bufnum++);
-		cp_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
+	for (i = 0; i < pdata->txq_cnt; i++) {
+		/* allocate tx descriptor ring */
+		owner = xgene_derive_ring_owner(pdata);
+		ring_id = xgene_enet_get_ring_id(owner, eth_bufnum++);
+		tx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
 						      RING_CFGSIZE_16KB,
 						      ring_id);
-		if (!cp_ring) {
+		if (!tx_ring) {
 			ret = -ENOMEM;
 			goto err;
 		}
-		cp_ring->irq = pdata->txc_irq;
-		snprintf(cp_ring->irq_name, IRQ_ID_SIZE, "%s-txc", ndev->name);
-	}
 
-	cp_ring->cp_skb = devm_kcalloc(dev, tx_ring->slots,
-				       sizeof(struct sk_buff *), GFP_KERNEL);
-	if (!cp_ring->cp_skb) {
-		ret = -ENOMEM;
-		goto err;
-	}
+		size = (tx_ring->slots / 2) * sizeof(__le64) * MAX_EXP_BUFFS;
+		tx_ring->exp_bufs = dma_zalloc_coherent(dev, size,
+							&dma_exp_bufs,
+							GFP_KERNEL);
+		if (!tx_ring->exp_bufs) {
+			ret = -ENOMEM;
+			goto err;
+		}
 
-	size = sizeof(dma_addr_t) * MAX_SKB_FRAGS;
-	cp_ring->frag_dma_addr = devm_kcalloc(dev, tx_ring->slots,
-					      size, GFP_KERNEL);
-	if (!cp_ring->frag_dma_addr) {
-		devm_kfree(dev, cp_ring->cp_skb);
-		ret = -ENOMEM;
-		goto err;
-	}
+		pdata->tx_ring[i] = tx_ring;
 
-	pdata->tx_ring->cp_ring = cp_ring;
-	pdata->tx_ring->dst_ring_num = xgene_enet_dst_ring_num(cp_ring);
+		if (!pdata->cq_cnt) {
+			cp_ring = pdata->rx_ring[i];
+		} else {
+			/* allocate tx completion descriptor ring */
+			ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU,
+							 cpu_bufnum++);
+			cp_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
+							      RING_CFGSIZE_16KB,
+							      ring_id);
+			if (!cp_ring) {
+				ret = -ENOMEM;
+				goto err;
+			}
+
+			cp_ring->irq = pdata->irqs[pdata->rxq_cnt + i];
+			cp_ring->index = i;
+			snprintf(cp_ring->irq_name, IRQ_ID_SIZE, "%s-txc%d",
+				 ndev->name, i);
+		}
+
+		cp_ring->cp_skb = devm_kcalloc(dev, tx_ring->slots,
+					       sizeof(struct sk_buff *),
+					       GFP_KERNEL);
+		if (!cp_ring->cp_skb) {
+			ret = -ENOMEM;
+			goto err;
+		}
 
-	pdata->tx_qcnt_hi = pdata->tx_ring->slots - 128;
+		size = sizeof(dma_addr_t) * MAX_SKB_FRAGS;
+		cp_ring->frag_dma_addr = devm_kcalloc(dev, tx_ring->slots,
+						      size, GFP_KERNEL);
+		if (!cp_ring->frag_dma_addr) {
+			devm_kfree(dev, cp_ring->cp_skb);
+			ret = -ENOMEM;
+			goto err;
+		}
+
+		tx_ring->cp_ring = cp_ring;
+		tx_ring->dst_ring_num = xgene_enet_dst_ring_num(cp_ring);
+	}
+
+	pdata->ring_ops->coalesce(pdata->tx_ring[0]);
+	pdata->tx_qcnt_hi = pdata->tx_ring[0]->slots - 128;
 
 	return 0;
 
@@ -1159,6 +1218,32 @@ static int xgene_get_rx_delay(struct xgene_enet_pdata *pdata)
 	return 0;
 }
 
+static int xgene_enet_get_irqs(struct xgene_enet_pdata *pdata)
+{
+	struct platform_device *pdev = pdata->pdev;
+	struct device *dev = &pdev->dev;
+	int i, ret, max_irqs;
+
+	if (pdata->phy_mode == PHY_INTERFACE_MODE_RGMII)
+		max_irqs = 1;
+	else if (pdata->phy_mode == PHY_INTERFACE_MODE_SGMII)
+		max_irqs = 2;
+	else
+		max_irqs = XGENE_MAX_ENET_IRQ;
+
+	for (i = 0; i < max_irqs; i++) {
+		ret = platform_get_irq(pdev, i);
+		if (ret <= 0) {
+			dev_err(dev, "Unable to get ENET IRQ\n");
+			ret = ret ? : -ENXIO;
+			return ret;
+		}
+		pdata->irqs[i] = ret;
+	}
+
+	return 0;
+}
+
 static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
 {
 	struct platform_device *pdev;
@@ -1240,25 +1325,9 @@ static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
 	if (ret)
 		return ret;
 
-	ret = platform_get_irq(pdev, 0);
-	if (ret <= 0) {
-		dev_err(dev, "Unable to get ENET Rx IRQ\n");
-		ret = ret ? : -ENXIO;
+	ret = xgene_enet_get_irqs(pdata);
+	if (ret)
 		return ret;
-	}
-	pdata->rx_irq = ret;
-
-	if (pdata->phy_mode != PHY_INTERFACE_MODE_RGMII) {
-		ret = platform_get_irq(pdev, 1);
-		if (ret <= 0) {
-			pdata->cq_cnt = 0;
-			dev_info(dev, "Unable to get Tx completion IRQ,"
-				 "using Rx IRQ instead\n");
-		} else {
-			pdata->cq_cnt = XGENE_MAX_TXC_RINGS;
-			pdata->txc_irq = ret;
-		}
-	}
 
 	pdata->clk = devm_clk_get(&pdev->dev, NULL);
 	if (IS_ERR(pdata->clk)) {
@@ -1296,7 +1365,7 @@ static int xgene_enet_init_hw(struct xgene_enet_pdata *pdata)
 	struct xgene_enet_desc_ring *buf_pool;
 	struct xgene_enet_cle *enet_cle = &pdata->cle;
 	u16 dst_ring_num;
-	int ret;
+	int i, ret;
 
 	ret = pdata->port_ops->reset(pdata);
 	if (ret)
@@ -1309,15 +1378,18 @@ static int xgene_enet_init_hw(struct xgene_enet_pdata *pdata)
 	}
 
 	/* setup buffer pool */
-	buf_pool = pdata->rx_ring->buf_pool;
-	xgene_enet_init_bufpool(buf_pool);
-	ret = xgene_enet_refill_bufpool(buf_pool, pdata->rx_buff_cnt);
-	if (ret) {
-		xgene_enet_delete_desc_rings(pdata);
-		return ret;
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		buf_pool = pdata->rx_ring[i]->buf_pool;
+		xgene_enet_init_bufpool(buf_pool);
+		ret = xgene_enet_refill_bufpool(buf_pool, pdata->rx_buff_cnt);
+		if (ret) {
+			xgene_enet_delete_desc_rings(pdata);
+			return ret;
+		}
 	}
 
-	dst_ring_num = xgene_enet_dst_ring_num(pdata->rx_ring);
+	dst_ring_num = xgene_enet_dst_ring_num(pdata->rx_ring[0]);
+	buf_pool = pdata->rx_ring[0]->buf_pool;
 	if (pdata->phy_mode == PHY_INTERFACE_MODE_XGMII) {
 		/* Initialize and Enable  PreClassifier Tree */
 		enet_cle->max_nodes = 512;
@@ -1348,17 +1420,26 @@ static void xgene_enet_setup_ops(struct xgene_enet_pdata *pdata)
 		pdata->mac_ops = &xgene_gmac_ops;
 		pdata->port_ops = &xgene_gport_ops;
 		pdata->rm = RM3;
+		pdata->rxq_cnt = 1;
+		pdata->txq_cnt = 1;
+		pdata->cq_cnt = 0;
 		break;
 	case PHY_INTERFACE_MODE_SGMII:
 		pdata->mac_ops = &xgene_sgmac_ops;
 		pdata->port_ops = &xgene_sgport_ops;
 		pdata->rm = RM1;
+		pdata->rxq_cnt = 1;
+		pdata->txq_cnt = 1;
+		pdata->cq_cnt = 1;
 		break;
 	default:
 		pdata->mac_ops = &xgene_xgmac_ops;
 		pdata->port_ops = &xgene_xgport_ops;
 		pdata->cle_ops = &xgene_cle3in_ops;
 		pdata->rm = RM0;
+		pdata->rxq_cnt = XGENE_NUM_RX_RING;
+		pdata->txq_cnt = XGENE_NUM_TX_RING;
+		pdata->cq_cnt = XGENE_NUM_TXC_RING;
 		break;
 	}
 
@@ -1412,12 +1493,16 @@ static void xgene_enet_setup_ops(struct xgene_enet_pdata *pdata)
 static void xgene_enet_napi_add(struct xgene_enet_pdata *pdata)
 {
 	struct napi_struct *napi;
+	int i;
 
-	napi = &pdata->rx_ring->napi;
-	netif_napi_add(pdata->ndev, napi, xgene_enet_napi, NAPI_POLL_WEIGHT);
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		napi = &pdata->rx_ring[i]->napi;
+		netif_napi_add(pdata->ndev, napi, xgene_enet_napi,
+			       NAPI_POLL_WEIGHT);
+	}
 
-	if (pdata->cq_cnt) {
-		napi = &pdata->tx_ring->cp_ring->napi;
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		napi = &pdata->tx_ring[i]->cp_ring->napi;
 		netif_napi_add(pdata->ndev, napi, xgene_enet_napi,
 			       NAPI_POLL_WEIGHT);
 	}
@@ -1426,12 +1511,15 @@ static void xgene_enet_napi_add(struct xgene_enet_pdata *pdata)
 static void xgene_enet_napi_del(struct xgene_enet_pdata *pdata)
 {
 	struct napi_struct *napi;
+	int i;
 
-	napi = &pdata->rx_ring->napi;
-	netif_napi_del(napi);
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		napi = &pdata->rx_ring[i]->napi;
+		netif_napi_del(napi);
+	}
 
-	if (pdata->cq_cnt) {
-		napi = &pdata->tx_ring->cp_ring->napi;
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		napi = &pdata->tx_ring[i]->cp_ring->napi;
 		netif_napi_del(napi);
 	}
 }
@@ -1445,7 +1533,8 @@ static int xgene_enet_probe(struct platform_device *pdev)
 	const struct of_device_id *of_id;
 	int ret;
 
-	ndev = alloc_etherdev(sizeof(struct xgene_enet_pdata));
+	ndev = alloc_etherdev_mqs(sizeof(struct xgene_enet_pdata),
+				  XGENE_NUM_RX_RING, XGENE_NUM_TX_RING);
 	if (!ndev)
 		return -ENOMEM;
 
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
index 05365c1..175d188 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
@@ -49,6 +49,11 @@
 #define XGENE_ENET_MSS	1448
 #define XGENE_MIN_ENET_FRAME_SIZE	60
 
+#define XGENE_MAX_ENET_IRQ	8
+#define XGENE_NUM_RX_RING	4
+#define XGENE_NUM_TX_RING	4
+#define XGENE_NUM_TXC_RING	4
+
 #define START_CPU_BUFNUM_0	0
 #define START_ETH_BUFNUM_0	2
 #define START_BP_BUFNUM_0	0x22
@@ -73,7 +78,6 @@
 #define X2_START_RING_NUM_1	256
 
 #define IRQ_ID_SIZE		16
-#define XGENE_MAX_TXC_RINGS	1
 
 #define PHY_POLL_LINK_ON	(10 * HZ)
 #define PHY_POLL_LINK_OFF	(PHY_POLL_LINK_ON / 5)
@@ -103,6 +107,7 @@ struct xgene_enet_desc_ring {
 	void *irq_mbox_addr;
 	u16 dst_ring_num;
 	u8 nbufpool;
+	u8 index;
 	struct sk_buff *(*rx_skb);
 	struct sk_buff *(*cp_skb);
 	dma_addr_t *frag_dma_addr;
@@ -144,6 +149,7 @@ struct xgene_ring_ops {
 	void (*clear)(struct xgene_enet_desc_ring *);
 	void (*wr_cmd)(struct xgene_enet_desc_ring *, int);
 	u32 (*len)(struct xgene_enet_desc_ring *);
+	void (*coalesce)(struct xgene_enet_desc_ring *);
 };
 
 struct xgene_cle_ops {
@@ -159,15 +165,16 @@ struct xgene_enet_pdata {
 	struct clk *clk;
 	struct platform_device *pdev;
 	enum xgene_enet_id enet_id;
-	struct xgene_enet_desc_ring *tx_ring;
-	struct xgene_enet_desc_ring *rx_ring;
-	u16 tx_level;
-	u16 txc_level;
+	struct xgene_enet_desc_ring *tx_ring[XGENE_NUM_TX_RING];
+	struct xgene_enet_desc_ring *rx_ring[XGENE_NUM_RX_RING];
+	u16 tx_level[XGENE_NUM_TX_RING];
+	u16 txc_level[XGENE_NUM_TX_RING];
 	char *dev_name;
 	u32 rx_buff_cnt;
 	u32 tx_qcnt_hi;
-	u32 rx_irq;
-	u32 txc_irq;
+	u32 irqs[XGENE_MAX_ENET_IRQ];
+	u8 rxq_cnt;
+	u8 txq_cnt;
 	u8 cq_cnt;
 	void __iomem *eth_csr_addr;
 	void __iomem *eth_ring_if_addr;
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c b/drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c
index 0b6896b..2b76732 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c
@@ -190,6 +190,17 @@ static u32 xgene_enet_ring_len(struct xgene_enet_desc_ring *ring)
 	return num_msgs;
 }
 
+static void xgene_enet_setup_coalescing(struct xgene_enet_desc_ring *ring)
+{
+	u32 data = 0x7777;
+
+	xgene_enet_ring_wr32(ring, CSR_PBM_COAL, 0x8e);
+	xgene_enet_ring_wr32(ring, CSR_PBM_CTICK1, data);
+	xgene_enet_ring_wr32(ring, CSR_PBM_CTICK2, data << 16);
+	xgene_enet_ring_wr32(ring, CSR_THRESHOLD0_SET1, 0x40);
+	xgene_enet_ring_wr32(ring, CSR_THRESHOLD1_SET1, 0x80);
+}
+
 struct xgene_ring_ops xgene_ring2_ops = {
 	.num_ring_config = X2_NUM_RING_CONFIG,
 	.num_ring_id_shift = 13,
@@ -197,4 +208,5 @@ struct xgene_ring_ops xgene_ring2_ops = {
 	.clear = xgene_enet_clear_ring,
 	.wr_cmd = xgene_enet_wr_cmd,
 	.len = xgene_enet_ring_len,
+	.coalesce = xgene_enet_setup_coalescing,
 };
-- 
1.9.1



From ddaney.cavm at gmail.com  Fri Feb 12 17:47:25 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri, 12 Feb 2016 17:47:25 -0800
Subject: [RFC PATCH 1/7] arm64/perf: Basic uncore counter support for
 Cavium ThunderX
In-Reply-To: <20160212173658.GD20262@leverpostej>
References: <cover.1455295032.git.jglauber@cavium.com>
 <8bd93a25e069ed6428bc6c21fc53270962ccafcc.1455295032.git.jglauber@cavium.com>
 <20160212173658.GD20262@leverpostej>
Message-ID: <56BE8B2D.1000001@gmail.com>

On 02/12/2016 09:36 AM, Mark Rutland wrote:
> On Fri, Feb 12, 2016 at 05:55:06PM +0100, Jan Glauber wrote:
[...]
>> 2) Counters are summarized across the different units of the same type,
>>     e.g. L2C TAD 0..7 is presented as a single counter (adding the
>>     values from TAD 0 to 7). Although losing the ability to read a
>>     single value the merged values are easier to use and yield
>>     enough information.
>
> I'm not sure I follow this. What is easier? What are you doing, and what
> are you comparing that with to say that your approach is easier?
>
> It sounds like it should be possible to handle multiple counters like
> this, so I don't follow why you want to amalgamate them in-kernel.
>

The values of the individual counters are close to meaningless.  The 
only thing that is meaningful to someone reading the counters is the 
aggregate sum of all the counts.


> [...]
>
>> +#include <asm/cpufeature.h>
>> +#include <asm/cputype.h>
>
> I don't see why you should need these two if this is truly an uncore
> device probed solely from PCI.
>
>> +void thunder_uncore_read(struct perf_event *event)
>> +{
>> +	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
>> +	struct hw_perf_event *hwc = &event->hw;
>> +	u64 prev, new = 0;
>> +	s64 delta;
>> +	int i;
>> +
>> +	/*
>> +	 * since we do not enable counter overflow interrupts,
>> +	 * we do not have to worry about prev_count changing on us
>> +	 */
>
> Without overflow interrupts, how do you ensure that you account for
> overflow in a reasonable time window (i.e. before the counter runs past
> its initial value)?

Two reasons:

   1) There are no interrupts.

   2) The counters are 64-bit, they never overflow.

>
>> +
>> +	prev = local64_read(&hwc->prev_count);
>> +
>> +	/* read counter values from all units */
>> +	for (i = 0; i < uncore->nr_units; i++)
>> +		new += readq(map_offset(hwc->event_base, uncore, i));
>
> There's no bit to determine whether an overflow occurred?

No.


>
>> +
>> +	local64_set(&hwc->prev_count, new);
>> +	delta = new - prev;
>> +	local64_add(delta, &event->count);
>> +}
>> +
>> +void thunder_uncore_del(struct perf_event *event, int flags)
>> +{
>> +	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
>> +	struct hw_perf_event *hwc = &event->hw;
>> +	int i;
>> +
>> +	event->pmu->stop(event, PERF_EF_UPDATE);
>> +
>> +	for (i = 0; i < uncore->num_counters; i++) {
>> +		if (cmpxchg(&uncore->events[i], event, NULL) == event)
>> +			break;
>> +	}
>> +	hwc->idx = -1;
>> +}
>
> Why not just place the event at uncode->events[hwc->idx] ?
>
> Theat way removing the event is trivial.
>
>> +int thunder_uncore_event_init(struct perf_event *event)
>> +{
>> +	struct hw_perf_event *hwc = &event->hw;
>> +	struct thunder_uncore *uncore;
>> +
>> +	if (event->attr.type != event->pmu->type)
>> +		return -ENOENT;
>> +
>> +	/* we do not support sampling */
>> +	if (is_sampling_event(event))
>> +		return -EINVAL;
>> +
>> +	/* counters do not have these bits */
>> +	if (event->attr.exclude_user	||
>> +	    event->attr.exclude_kernel	||
>> +	    event->attr.exclude_host	||
>> +	    event->attr.exclude_guest	||
>> +	    event->attr.exclude_hv	||
>> +	    event->attr.exclude_idle)
>> +		return -EINVAL;
>
> We should _really_ make these features opt-in at the core level. It's
> crazy that each and every PMU drivers has to explicitly test and reject
> things it doesn't support.
>
>> +
>> +	/* and we do not enable counter overflow interrupts */
>
> That statement raises far more questions than it answers.
>
> _why_ do we not user overflow interrupts?

As stated above, there are *no* overflow interrupts.

The events we are counting cannot be attributed to any one (or even any) 
CPU, they run asynchronous to the CPU, so even if there were interrupts, 
they would be meaningless.


David Daney


From wens at csie.org  Fri Feb 12 18:28:51 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Sat, 13 Feb 2016 10:28:51 +0800
Subject: [PATCH v2 0/2] clk: sunxi: Fix APBS clock for Allwinner A80
In-Reply-To: <1455269475-8180-1-git-send-email-wens@csie.org>
References: <1455269475-8180-1-git-send-email-wens@csie.org>
Message-ID: <CAGb2v65FT-Kn4C3hno_FDcvbTkpow3FAnLLEUPz3y===d5YebQ@mail.gmail.com>

Hi,

On Fri, Feb 12, 2016 at 5:31 PM, Chen-Yu Tsai <wens at csie.org> wrote:
> Hi everyone,
>
> This is v2 of the A80 APBS clock fixes series.
>
> When I did the A80 PRCM support, I failed to notice the A80's APBS clock
> was not the same as the A23's APB0 clock. The former is a zero-based
> divider, while the latter is a power-of-two divider. But the lowest 2
> dividers are the same.

It turns out that clk-sun8i-a23-apb0 was wrong. It's a zero-based divider,
not a power-of-two divider as the driver says. Thanks to Vishnu for pointing
it out. So NACK on this series.

I'll send a patch fixing this, but what should we do for old kernels?
I don't think backporting the CLK_OF_DECLARE changes is acceptable.
Maybe a stable patch based on the fix?

Sorry for the noise.

ChenYu

> The hardware defaults to the lowest setting, or a /1 divider. Since the
> child gates do not propagate clk_set_rate up, and no consumers here do
> clk_set_rate, this actually works.
>
> I realized my mistake while reviewing the A83T's PRCM patches. The A83T
> shares the same PRCM clocks as the A80.
>
> Maxime, since this was introduced in 4.5-rc1, please apply this series
> for 4.5 so we fix it before the release.
>
>
> Changes since v1:
>
>   - Replace the CLK_OF_DECLARE version of sun8i-a23-apb0-clk with the
>     A80 APBS version, instead of writing a new driver.
>
> Regards
> ChenYu
>
>
> Chen-Yu Tsai (2):
>   clk: sunxi: Add support for A80 APBS clock
>   ARM: dts: sun9i: Fix apbs clock compatible
>
>  Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
>  arch/arm/boot/dts/sun9i-a80.dtsi                  |  2 +-
>  drivers/clk/sunxi/clk-sun8i-apb0.c                | 23 ++++++++---------------
>  3 files changed, 10 insertions(+), 16 deletions(-)
>
> --
> 2.7.0
>


From linux at roeck-us.net  Fri Feb 12 18:35:17 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Fri, 12 Feb 2016 18:35:17 -0800
Subject: [PATCH 2/3] ARM: mvebu: Create a NSA3xx hardware monitoring driver
In-Reply-To: <1455147224-6742-3-git-send-email-linux@baker-net.org.uk>
References: <1455147224-6742-1-git-send-email-linux@baker-net.org.uk>
 <1455147224-6742-3-git-send-email-linux@baker-net.org.uk>
Message-ID: <20160213023517.GA22156@roeck-us.net>

Hi,

On Wed, Feb 10, 2016 at 11:33:43PM +0000, Adam Baker wrote:
> Create a driver to support the hardware monitoring chip present in
> several models of Zyxel NSA3xx NAS devices.
> 
> The driver reads fan speed and temperature from a suitably programmed
> MCU on the device.
> 
> Signed-off-by: Adam Baker <linux at baker-net.org.uk>

Please name the driver nsa320. It may ultimately support other devices,
but that doesn't mean it is going to support NSA-35x or other future
similar devices.

Got the headline, please use

hwmon: Add driver for Zyxel NSA-320

> ---
> I've tested this on an NSA-320, I've had someone offer to test it on
> NSA-325 so hopefully I will get a tested by back.
> ---
>  drivers/hwmon/Kconfig        |  13 +++
>  drivers/hwmon/Makefile       |   1 +
>  drivers/hwmon/nsa3xx-hwmon.c | 223 +++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 237 insertions(+)
>  create mode 100644 drivers/hwmon/nsa3xx-hwmon.c
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 80a73bf..8801b78 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1757,6 +1757,19 @@ config SENSORS_ULTRA45
>  	  This driver provides support for the Ultra45 workstation environmental
>  	  sensors.
>  
> +config SENSORS_NSA3XX

Please try to stick with alphabetic order.

> +	tristate "ZyXEL NSA3xx fan speed and temperature sensors"

... NSA-320 and compatible ...

> +	depends on GPIOLIB && OF

Can you add some additional dependencies ?

It is quite unlikely that the driver is needed on an X86.
Please use at least

	depends on ARM || COMPILE_TEST

or a more specific dependency if the SoC is known. MACH_KIRKWOOD, maybe ?

> +	help
> +	  If you say yes here you get support for hardware monitoring
> +	  for the ZyXEL NSA3XX Media Servers.

Please be specific which devices are supported. Feel free to add "and
compatibles", but please no generic and misleading statements such as 3XX.

> +
> +	  The sensor data is taken from a Holtek HT46R065 microcontroller
> +	  connected to GPIO lines.
> +
Is that relevant ?

> +	  This driver can also be built as a module. If so, the module
> +	  will be called nsa3xx-hwmon.
> +
>  if ACPI
>  
>  comment "ACPI drivers"
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 12a3239..e85414a 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -118,6 +118,7 @@ obj-$(CONFIG_SENSORS_MAX6650)	+= max6650.o
>  obj-$(CONFIG_SENSORS_MAX6697)	+= max6697.o
>  obj-$(CONFIG_SENSORS_MAX31790)	+= max31790.o
>  obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
> +obj-$(CONFIG_SENSORS_NSA3XX)	+= nsa3xx-hwmon.o

Please try to stick with alphabetic order.

>  obj-$(CONFIG_SENSORS_MCP3021)	+= mcp3021.o
>  obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o
>  obj-$(CONFIG_SENSORS_NCT6683)	+= nct6683.o
> diff --git a/drivers/hwmon/nsa3xx-hwmon.c b/drivers/hwmon/nsa3xx-hwmon.c
> new file mode 100644
> index 0000000..0fbf118
> --- /dev/null
> +++ b/drivers/hwmon/nsa3xx-hwmon.c

nsa320-hwmon.c

> @@ -0,0 +1,223 @@
> +/*
> + * drivers/hwmon/nsa3xx-hwmon.c
> + *
> + * ZyXEL NSA3xx Media Servers

Please be specific.

> + * hardware monitoring
> + *
> + * Copyright (C) 2016 Adam Baker <linux at baker-net.org.uk>
> + * based on a board file driver
> + * Copyright (C) 2012 Peter Schildmann <linux at schildmann.info>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License v2 as published by the
> + * Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/platform_device.h>
> +#include <linux/err.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/jiffies.h>
> +#include <linux/delay.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_platform.h>
> +
Please order include files alphabetically.

> +#define MAGIC_NUMBER 0x55
> +
> +/*
> + * The Zyxel hwmon MCU is a Holtek HT46R065 that is factory programmed
> + * to perform temperature and fan speed monitoring. It is read by taking
> + * the active pin low. The 32 bit output word is then clocked onto the
> + * data line. The MSB of the data word is a magic nuber to indicate it
> + * has been read correctly, the next byte is the fan speed (in hundreds
> + * of RPM) and the last two bytes are the temperature (in tenths of a
> + * degree)
> + */
> +
> +struct nsa3xx_hwmon {

s/nsa3xx/nsa320/g for the entire file, please.

> +	struct device		*classdev;
> +	struct mutex		update_lock;	/* lock GPIO operations */
> +	unsigned long		last_updated;	/* jiffies */
> +	u32			mcu_data;

I would suggest to use unsigned long here. See below for reasons.

> +	struct gpio_desc	*act;
> +	struct gpio_desc	*clk;
> +	struct gpio_desc	*data;
> +};
> +
> +enum nsa3xx_inputs {
> +	NSA3XX_FAN = 1,
> +	NSA3XX_TEMP = 0,

Any special reason for the unusual order ? If yes, please explain.

> +};
> +
> +static const char * const nsa3xx_input_names[] = {
> +	[NSA3XX_FAN] = "Chassis Fan",
> +	[NSA3XX_TEMP] = "System Temperature",
> +};
> +
> +/* Although this protocol looks similar to SPI the long delay
> + * between the active (aka chip select) signal and the shorter
> + * delay between clock pulses are needed for reliable operation.
> + * The delays provided are taken from the manufacturer kernel,
> + * testing suggest they probably incorporate a reasonable safety
> + * margin. (The single device tested became unreliable if the
> + * delay was reduced to 1/10th of this value.)
> + */
> +static unsigned long nsa3xx_hwmon_update(struct device *dev)
> +{
> +	u32 mcu_data;
> +	u32 mask;
> +	struct nsa3xx_hwmon *hwmon = dev_get_drvdata(dev);
> +
> +	mutex_lock(&hwmon->update_lock);
> +
> +	mcu_data = hwmon->mcu_data;
> +
> +	if (time_after(jiffies, hwmon->last_updated + HZ) ||
> +							mcu_data == 0) {
> +

Please no blank line here. Also, please align continuation lines with '('.
However, unless I am missing something, the continuation line is not needed
in the first place. Please no unnecessary continuation lines.

> +		gpiod_set_value(hwmon->act, 1);
> +		msleep(100);
> +
> +		for (mask = BIT(31); mask; mask >>= 1) {

Since you are using BIT(), please include linux/bitops.h.

> +			gpiod_set_value(hwmon->clk, 0);
> +			usleep_range(100, 200);
> +			gpiod_set_value(hwmon->clk, 1);
> +			usleep_range(100, 200);
> +			if (gpiod_get_value(hwmon->data))
> +				mcu_data |= mask;
> +		}
> +
> +		gpiod_set_value(hwmon->act, 0);
> +		dev_dbg(dev, "Read raw MCU data %08x\n", mcu_data);
> +
> +		if ((mcu_data >> 24) != MAGIC_NUMBER) {
> +			dev_err(dev, "Read invalid MCU data %08x\n", mcu_data);
> +			mcu_data = 0;

Instead of an error message, it would be better to return an error code
(probably -EIO since we don't know better).

The calling code can then return the error to user space.

> +		}
> +
> +		hwmon->mcu_data = mcu_data;
> +		hwmon->last_updated = jiffies;
> +	}
> +
> +	mutex_unlock(&hwmon->update_lock);
> +
> +	return mcu_data;
> +}
> +
> +static ssize_t show_label(struct device *dev,
> +			  struct device_attribute *attr, char *buf)
> +{
> +	int channel = to_sensor_dev_attr(attr)->index;
> +
> +	return sprintf(buf, "%s\n", nsa3xx_input_names[channel]);
> +}
> +
> +static ssize_t show_value(struct device *dev,
> +			  struct device_attribute *attr, char *buf)
> +{
> +	int channel = to_sensor_dev_attr(attr)->index;
> +	unsigned long mcu_data = nsa3xx_hwmon_update(dev);
> +	unsigned long value = 0;
> +

If nsa3xx_hwmon_update() returns an error code, you can use

	if (IS_ERR_VALUE(mcu_data))
		return (long)mcu_data;

or even better have nsa3xx_hwmon_update() return int directly
to indicate an error.

> +	pr_debug("channel value 0x%02x!\n", channel);

Is this really useful ? I would suggest to drop debug messages
unless really needed. If you really think the message is useful,
please use dev_dbg().

> +	switch (channel) {
> +	case NSA3XX_TEMP:
> +		value = (mcu_data & 0xffff) * 100;
> +		break;
> +	case NSA3XX_FAN:
> +		value = ((mcu_data & 0xff0000) >> 16) * 100;
> +		break;
> +	}
> +	return sprintf(buf, "%lu\n", value);
> +}
> +
> +static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, show_label, NULL, NSA3XX_TEMP);
> +static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_value, NULL, NSA3XX_TEMP);
> +static SENSOR_DEVICE_ATTR(fan1_label, S_IRUGO, show_label, NULL, NSA3XX_FAN);
> +static SENSOR_DEVICE_ATTR(fan1_input, S_IRUGO, show_value, NULL, NSA3XX_FAN);
> +
> +static struct attribute *nsa3xx_attrs[] = {
> +	&sensor_dev_attr_temp1_label.dev_attr.attr,
> +	&sensor_dev_attr_temp1_input.dev_attr.attr,
> +	&sensor_dev_attr_fan1_label.dev_attr.attr,
> +	&sensor_dev_attr_fan1_input.dev_attr.attr,
> +	NULL
> +};
> +
> +ATTRIBUTE_GROUPS(nsa3xx);
> +
> +static const struct of_device_id of_nsa3xx_hwmon_match[] = {
> +	{ .compatible = "zyxel,nsa320-mcu", },
> +	{ },
> +};
> +
> +static int nsa3xx_hwmon_probe(struct platform_device *pdev)
> +{
> +	struct nsa3xx_hwmon *hwmon;
> +
> +	hwmon = devm_kzalloc(&pdev->dev, sizeof(*hwmon), GFP_KERNEL);
> +	if (!hwmon)
> +		return -ENOMEM;
> +
> +	platform_set_drvdata(pdev, hwmon);

Unnecessary.

> +
> +	/* Look up the GPIO pins to use */
> +	hwmon->act = devm_gpiod_get(&pdev->dev, "act", GPIOD_OUT_LOW);
> +	hwmon->clk = devm_gpiod_get(&pdev->dev, "clk", GPIOD_OUT_HIGH);
> +	hwmon->data = devm_gpiod_get(&pdev->dev, "data", GPIOD_IN);
> +
> +	if (IS_ERR(hwmon->act))
> +		return PTR_ERR(hwmon->act);
> +	if (IS_ERR(hwmon->clk))
> +		return PTR_ERR(hwmon->clk);
> +	if (IS_ERR(hwmon->data))
> +		return PTR_ERR(hwmon->data);

Please reorder to have the error checks immediately after the calls
to devm_gpiod_get().

> +
> +	mutex_init(&hwmon->update_lock);
> +
> +	hwmon->classdev = devm_hwmon_device_register_with_groups(&pdev->dev,
> +					"nsa3xx", hwmon, nsa3xx_groups);

classdev is only used in this function and thus does not have to be kept
in struct nsa3xx_hwmon.

> +	if (IS_ERR(hwmon->classdev))
> +		return PTR_ERR(hwmon->classdev);
> +
> +	dev_dbg(&pdev->dev, "initialized\n");
> +

This message is really unnecessary. Please just use
	return PTR_ERR_OR_ZERO(classdev);

> +	return 0;
> +}
> +
> +static int nsa3xx_hwmon_remove(struct platform_device *pdev)
> +{
> +	/* All resources are allocated with devm_*() so
> +	 * there is nothing to do here.
> +	 */
> +
> +	return 0;
> +}

If the remove function is not needed, it is not needed and should not
exist in the first place. Please no dummy functions.

> +
> +static struct platform_driver nsa3xx_hwmon_driver = {
> +	.probe = nsa3xx_hwmon_probe,
> +	.remove = nsa3xx_hwmon_remove,
> +	.driver = {
> +		.name = "nsa3xx-hwmon",
> +		.owner = THIS_MODULE,
> +		.of_match_table = of_match_ptr(of_nsa3xx_hwmon_match),
> +	},
> +};
> +
> +module_platform_driver(nsa3xx_hwmon_driver);
> +
> +MODULE_DEVICE_TABLE(of, of_nsa3xx_hwmon_match);
> +MODULE_AUTHOR("Peter Schildmann <linux at schildmann.info>");
> +MODULE_AUTHOR("Adam Baker <linux at baker-net.org.uk>");
> +MODULE_DESCRIPTION("NSA3XX Hardware Monitoring");
> +MODULE_LICENSE("GPL");

GPL v2

> +MODULE_ALIAS("platform:nsa3xx-hwmon");
> -- 
> 2.1.4
> 


From wens at csie.org  Fri Feb 12 18:44:15 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Sat, 13 Feb 2016 10:44:15 +0800
Subject: [PATCH 1/3] clk: sunxi: improve mux_clk error handling and
 reporting
In-Reply-To: <1455289913-29514-2-git-send-email-andre.przywara@arm.com>
References: <1455289913-29514-1-git-send-email-andre.przywara@arm.com>
 <1455289913-29514-2-git-send-email-andre.przywara@arm.com>
Message-ID: <CAGb2v65hxNiY8XAL=yBbV4qazscJd+six432CKWAm+GfM6bd2Q@mail.gmail.com>

Hi,

On Fri, Feb 12, 2016 at 11:11 PM, Andre Przywara <andre.przywara at arm.com> wrote:
> We now catch and report a failing ioremap, also a failure in the final
> step of the clock registration is now handled and reported.
> Also warnings are turned into errors.
>
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  drivers/clk/sunxi/clk-sunxi.c | 19 +++++++++++++------
>  1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 49ce283..361f396 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -690,11 +690,15 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
>         int i;
>
>         reg = of_iomap(node, 0);
> +       if (!reg) {
> +               pr_err("Could not map registers for mux-clk: %s\n", node->name);

of_node_full_name(node->name) is better. node->name is almost always "clk",
which is useless. (Unless someone goes through the dts files to replace all
of them.)

> +               return NULL;
> +       }
>
>         i = of_clk_parent_fill(node, parents, SUNXI_MAX_PARENTS);
>         if (of_property_read_string(node, "clock-output-names", &clk_name)) {
> -               pr_warn("%s: could not read clock-output-names for \"%s\"\n",
> -                       __func__, clk_name);
> +               pr_err("%s: could not read clock-output-names for \"%s\"\n",
> +                      __func__, clk_name);

Same here. clk_name defaults to node->name. If you could, please replace it.

>                 goto out_unmap;
>         }
>
> @@ -704,14 +708,17 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
>                                0, &clk_lock);
>
>         if (IS_ERR(clk)) {
> -               pr_warn("%s: failed to register mux clock %s: %ld\n", __func__,
> -                       clk_name, PTR_ERR(clk));
> +               pr_err("%s: failed to register mux clock %s: %ld\n", __func__,
> +                      clk_name, PTR_ERR(clk));
>                 goto out_unmap;
>         }
>
> -       of_clk_add_provider(node, of_clk_src_simple_get, clk);
> +       if (!of_clk_add_provider(node, of_clk_src_simple_get, clk))
> +               return clk;
> +
> +       pr_err("%s: failed to add clock provider for %s\n", __func__, clk_name);
>
> -       return clk;

I'd have all the error path in ifs, and have the normal return path
here for consistency.
But I guess this works as well.

Thanks!
ChenYu

> +       clk_unregister_divider(clk);
>
>  out_unmap:
>         iounmap(reg);
> --
> 2.6.4
>


From qnguyen at apm.com  Fri Feb 12 19:21:31 2016
From: qnguyen at apm.com (Quan Nguyen)
Date: Sat, 13 Feb 2016 10:21:31 +0700
Subject: [PATCH v5 2/3] Documentation: gpio: Update description for X-Gene
 standby GPIO controller DTS binding
In-Reply-To: <20160212143616.GA1603@rob-hp-laptop>
References: <1454041735-8434-1-git-send-email-qnguyen@apm.com>
 <1454041735-8434-3-git-send-email-qnguyen@apm.com>
 <20160201153502.GA19725@rob-hp-laptop>
 <CAFopSPQBjXQZwG-Phfc+xJ5Kn6dXPakT6Hg5qT-ByXG06p8wgg@mail.gmail.com>
 <20160212143616.GA1603@rob-hp-laptop>
Message-ID: <CAFopSPSruG1x+yefX--uR6zYOHSp2eXRmw4fb_u9wAKDFp4jHw@mail.gmail.com>

On Fri, Feb 12, 2016 at 9:36 PM, Rob Herring <robh at kernel.org> wrote:
> On Tue, Feb 02, 2016 at 08:46:25AM +0700, Quan Nguyen wrote:
>> On Mon, Feb 1, 2016 at 10:35 PM, Rob Herring <robh at kernel.org> wrote:
>> > On Fri, Jan 29, 2016 at 11:28:54AM +0700, Quan Nguyen wrote:
>> >> Update description for X-Gene standby GPIO controller DTS binding to
>> >> support GPIO line configuration as input, output or external IRQ pin.
>> >>
>> >> Signed-off-by: Y Vo <yvo at apm.com>
>> >> Signed-off-by: Quan Nguyen <qnguyen at apm.com>
>> >> ---
>> >>  .../devicetree/bindings/gpio/gpio-xgene-sb.txt     | 47 ++++++++++++++++++----
>> >>  1 file changed, 40 insertions(+), 7 deletions(-)
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
>> >> index dae1300..7b8b4cb 100644
>> >> --- a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
>> >> +++ b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
>> >> @@ -1,10 +1,20 @@
>> >>  APM X-Gene Standby GPIO controller bindings
>> >>
>> >> -This is a gpio controller in the standby domain.
>> >> -
>> >> -There are 20 GPIO pins from 0..21. There is no GPIO_DS14 or GPIO_DS15,
>> >> -only GPIO_DS8..GPIO_DS13 support interrupts. The IRQ mapping
>> >> -is currently 1-to-1 on interrupts 0x28 thru 0x2d.
>> >> +This is a gpio controller in the standby domain. It also supports interrupt in
>> >> +some particular pins which are sourced to its parent interrupt controller
>> >> +as diagram below:
>> >> +                           +-----------------+
>> >> +                           | X-Gene standby  |
>> >> +                           | GPIO controller +--------- GPIO_0
>> >> ++------------+             |                 | ...
>> >> +| Parent IRQ |             |                 +--------- GPIO_8/EXT_INT_0
>> >> +| controller |  EXT_INT_0  |                 | ...
>> >> +| (GICv2)    +-------------+                 +--------- GPIO_[N+8]/EXT_INT_N
>> >> +|            |  ...        |                 |
>> >> +|            |  EXT_INT_N  |                 +--------- GPIO_[N+9]
>> >> +|            +-------------+                 | ...
>> >> +|            |             |                 +--------- GPIO_MAX
>> >> ++------------+             +-----------------+
>> >>
>> >>  Required properties:
>> >>  - compatible: "apm,xgene-gpio-sb" for the X-Gene Standby GPIO controller
>> >> @@ -15,10 +25,18 @@ Required properties:
>> >>               0 = active high
>> >>               1 = active low
>> >>  - gpio-controller: Marks the device node as a GPIO controller.
>> >> -- interrupts: Shall contain exactly 6 interrupts.
>> >> +- interrupts: The EXT_INT_0 parent interrupt resource must be listed first.
>> >> +- interrupt-parent: Phandle of the parent interrupt controller.
>> >> +- interrupt-cells: Should be two.
>> >> +       - first cell is 0-N coresponding for EXT_INT_0 to EXT_INT_N.
>> >> +       - second cell is used to specify flags.
>> >> +- interrupt-controller: Marks the device node as an interrupt controller.
>> >> +- apm,nr-gpios: Optional, specify number of gpios pin.
>> >> +- apm,nr-irqs: Optional, specify number of interrupt pins.
>> >
>> > When is this not 6?
>> >
>> Hi Rob,  by default, this should be 6, but I think this property can
>> help in cases:
>> + Used only 5(or less) first pin as interrupt.
>> + For similar device which has different interrupt pins (8 for example).
>> My idea is to make it a bit more generic by using this optional property.
>
> What is similar device? Another SoC? board? Is 6 fixed in the SoC? I
> think you need more specific compatible string with the SoC name in it
> to determine these setting rather than trying to do something generic.
>

I agree, Rob, compatible string should be suit for other SoC, but I think
we still need this property for case of less than 6 interrupts are needed.

Thanks,
-- Quan Nguyen


From dhdang at apm.com  Fri Feb 12 19:25:20 2016
From: dhdang at apm.com (Duc Dang)
Date: Fri, 12 Feb 2016 19:25:20 -0800
Subject: [PATCH v5 1/3] mailbox: Add support for APM X-Gene platform
 mailbox driver
In-Reply-To: <CANLsYkxPnFCuJLyKsHnXKdbvAwNurtgQgJ-WF+bD26+8EjkfJw@mail.gmail.com>
References: <CABb+yY1cE152ZdfK_aeB8ufG=WfoUVB6BN8kXPphYgMBnpH-GA@mail.gmail.com>
 <cover.1454967957.git.dhdang@apm.com>
 <90cb13a0b4d3817c18c11c183128c08d6458bf8d.1454967957.git.dhdang@apm.com>
 <CANLsYkwp4vJN+LcNm=7Xm=RppFnsPEXSAARS7=g6CZSsk5M5qw@mail.gmail.com>
 <CADaLNDktgAnq5VHGj=B0iO9-GnMAamTEVELYuBTVegeL3QZ4Sw@mail.gmail.com>
 <CANLsYkxPnFCuJLyKsHnXKdbvAwNurtgQgJ-WF+bD26+8EjkfJw@mail.gmail.com>
Message-ID: <CADaLNDmVFG1xLV9fM16+2bL+F0enEDX1Pc9d71Tmw_-n=RSmwA@mail.gmail.com>

On Wed, Feb 10, 2016 at 6:41 AM, Mathieu Poirier
<mathieu.poirier at linaro.org> wrote:
> On 9 February 2016 at 20:46, Duc Dang <dhdang at apm.com> wrote:
>> On Tue, Feb 9, 2016 at 8:40 AM, Mathieu Poirier
>> <mathieu.poirier at linaro.org> wrote:
>>> On 8 February 2016 at 15:04, Duc Dang <dhdang at apm.com> wrote:
>>>> X-Gene mailbox controller provides 8 mailbox channels, with
>>>> each channel has a dedicated interrupt line.
>>>>
>>>> Signed-off-by: Feng Kan <fkan at apm.com>
>>>> Signed-off-by: Duc Dang <dhdang at apm.com>
>>>> ---
>>>> Changes since v4:
>>>>         - Rebase over v4.5-rc1
>>>>         - Fix section mistmatch warning by removing
>>>>         __init in slimpro_mbox_probe declaration
>>>>         - Correctly print channel number when
>>>>         there is no IRQ for that channel
>>>>
>>>> Changes since v3:
>>>>         - Rebase over v4.4
>>>>         - Remove 'id' in slimpro_mbox_chan structure
>>>>         - Remove small functions that are only called once
>>>>         and fold them into the other callers
>>>>         - Remove void* pointer type cast
>>>>         - Relax the number of mailbox IRQs condition
>>>>         - Use subsys_initcall to guarantee mailbox driver
>>>>         will be registered before any other dependent driver
>>>>         is loaded.
>>>>
>>>>  drivers/mailbox/Kconfig                 |   9 ++
>>>>  drivers/mailbox/Makefile                |   2 +
>>>>  drivers/mailbox/mailbox-xgene-slimpro.c | 264 ++++++++++++++++++++++++++++++++
>>>>  3 files changed, 275 insertions(+)
>>>>  create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c
>>>>
>>>> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
>>>> index 546d05f..678e434 100644
>>>> --- a/drivers/mailbox/Kconfig
>>>> +++ b/drivers/mailbox/Kconfig
>>>> @@ -85,4 +85,13 @@ config MAILBOX_TEST
>>>>           Test client to help with testing new Controller driver
>>>>           implementations.
>>>>
>>>> +config XGENE_SLIMPRO_MBOX
>>>> +       tristate "APM SoC X-Gene SLIMpro Mailbox Controller"
>>>> +       depends on ARCH_XGENE
>>>> +       help
>>>> +         An implementation of the APM X-Gene Interprocessor Communication
>>>> +         Mailbox (IPCM) between the ARM 64-bit cores and SLIMpro controller.
>>>> +         It is used to send short messages between ARM64-bit cores and
>>>> +         the SLIMpro Management Engine, primarily for PM. Say Y here if you
>>>> +         want to use the APM X-Gene SLIMpro IPCM support.
>>>>  endif
>>>> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
>>>> index 92435ef..b602ef8 100644
>>>> --- a/drivers/mailbox/Makefile
>>>> +++ b/drivers/mailbox/Makefile
>>>> @@ -17,3 +17,5 @@ obj-$(CONFIG_ALTERA_MBOX)     += mailbox-altera.o
>>>>  obj-$(CONFIG_BCM2835_MBOX)     += bcm2835-mailbox.o
>>>>
>>>>  obj-$(CONFIG_STI_MBOX)         += mailbox-sti.o
>>>> +
>>>> +obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
>>>> diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c b/drivers/mailbox/mailbox-xgene-slimpro.c
>>>> new file mode 100644
>>>> index 0000000..0ea1eb8
>>>> --- /dev/null
>>>> +++ b/drivers/mailbox/mailbox-xgene-slimpro.c
>>>> @@ -0,0 +1,264 @@
>>>> +/*
>>>> + * APM X-Gene SLIMpro MailBox Driver
>>>> + *
>>>> + * Copyright (c) 2015, Applied Micro Circuits Corporation
>>>> + * Author: Feng Kan fkan at apm.com
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or
>>>> + * modify it under the terms of the GNU General Public License as
>>>> + * published by the Free Software Foundation; either version 2 of
>>>> + * the License, or (at your option) any later version.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + * 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/delay.h>
>>>> +#include <linux/interrupt.h>
>>>> +#include <linux/io.h>
>>>> +#include <linux/mailbox_controller.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/platform_device.h>
>>>> +#include <linux/spinlock.h>
>>>> +
>>>> +#define MBOX_CON_NAME                  "slimpro-mbox"
>>>> +#define MBOX_REG_SET_OFFSET            0x1000
>>>> +#define MBOX_CNT                       8
>>>> +#define MBOX_STATUS_AVAIL_MASK         BIT(16)
>>>> +#define MBOX_STATUS_ACK_MASK           BIT(0)
>>>> +
>>>> +/* Configuration and Status Registers */
>>>> +#define REG_DB_IN              0x00
>>>> +#define REG_DB_DIN0            0x04
>>>> +#define REG_DB_DIN1            0x08
>>>> +#define REG_DB_OUT             0x10
>>>> +#define REG_DB_DOUT0           0x14
>>>> +#define REG_DB_DOUT1           0x18
>>>> +#define REG_DB_STAT            0x20
>>>> +#define REG_DB_STATMASK                0x24
>>>> +
>>>> +struct slimpro_mbox_chan {
>>>> +       struct device *dev;
>>>> +       struct mbox_chan *chan;
>>>> +       void __iomem *reg;
>>>> +       int irq;
>>>> +       u32 rx_msg[3];
>>>> +};
>>>> +
>>>> +struct slimpro_mbox {
>>>> +       struct mbox_controller mb_ctrl;
>>>> +       struct slimpro_mbox_chan mc[MBOX_CNT];
>>>> +       struct mbox_chan chans[MBOX_CNT];
>>>> +};
>>>
>>> The above two structure declaration could use kernel style documentation.
>>
>> Can you please clarify or give an example? I looked into several files
>> in drivers/mailbox/ and drivers/irqchip but could not find what I need
>> to tweak.
>
> http://lxr.free-electrons.com/source/drivers/mailbox/mailbox-sti.c#L42

I am modifying the structure defintion to add description and will
post a new version shortly.

Regards,
Duc Dang.
>
>>
>>>
>>>> +
>>>> +static void mb_chan_send_msg(struct slimpro_mbox_chan *mb_chan, u32 *msg)
>>>> +{
>>>> +       writel(msg[1], mb_chan->reg + REG_DB_DOUT0);
>>>> +       writel(msg[2], mb_chan->reg + REG_DB_DOUT1);
>>>> +       writel(msg[0], mb_chan->reg + REG_DB_OUT);
>>>> +}
>>>> +
>>>> +static void mb_chan_recv_msg(struct slimpro_mbox_chan *mb_chan)
>>>> +{
>>>> +       mb_chan->rx_msg[1] = readl(mb_chan->reg + REG_DB_DIN0);
>>>> +       mb_chan->rx_msg[2] = readl(mb_chan->reg + REG_DB_DIN1);
>>>> +       mb_chan->rx_msg[0] = readl(mb_chan->reg + REG_DB_IN);
>>>> +}
>>>
>>> Is there a requirement that operations in the above two functions be
>>> ordered?  If not significant gains could be achieved by using
>>> writel/readl_relaxed().  Same comment for the rest of this driver.
>>
>> The 'writes' need to be in order as writing to REG_DB_OUT will trigger
>> interrupt, so I want the other 2 'writes' complete before it.
>>
>> After the receiver get the message, it will clear door bell available
>> interrupt request, this will also trigger a door bell acknowledge
>> interrupt. So the 'read' to get the message and the 'write' to clear
>> the door bell available interrupt must be in order as well.
>>
>> Regards,
>> Duc Dang.
>>>
>>> Thanks,
>>> Mathieu
>>>
>>>> +
>>>> +static int mb_chan_status_ack(struct slimpro_mbox_chan *mb_chan)
>>>> +{
>>>> +       u32 val = readl(mb_chan->reg + REG_DB_STAT);
>>>> +
>>>> +       if (val & MBOX_STATUS_ACK_MASK) {
>>>> +               writel(MBOX_STATUS_ACK_MASK, mb_chan->reg + REG_DB_STAT);
>>>> +               return 1;
>>>> +       }
>>>> +       return 0;
>>>> +}
>>>> +
>>>> +static int mb_chan_status_avail(struct slimpro_mbox_chan *mb_chan)
>>>> +{
>>>> +       u32 val = readl(mb_chan->reg + REG_DB_STAT);
>>>> +
>>>> +       if (val & MBOX_STATUS_AVAIL_MASK) {
>>>> +               mb_chan_recv_msg(mb_chan);
>>>> +               writel(MBOX_STATUS_AVAIL_MASK, mb_chan->reg + REG_DB_STAT);
>>>> +               return 1;
>>>> +       }
>>>> +       return 0;
>>>> +}
>>>> +
>>>> +static irqreturn_t slimpro_mbox_irq(int irq, void *id)
>>>> +{
>>>> +       struct slimpro_mbox_chan *mb_chan = id;
>>>> +
>>>> +       if (mb_chan_status_ack(mb_chan))
>>>> +               mbox_chan_txdone(mb_chan->chan, 0);
>>>> +
>>>> +       if (mb_chan_status_avail(mb_chan))
>>>> +               mbox_chan_received_data(mb_chan->chan, mb_chan->rx_msg);
>>>> +
>>>> +       return IRQ_HANDLED;
>>>> +}
>>>> +
>>>> +static int slimpro_mbox_send_data(struct mbox_chan *chan, void *msg)
>>>> +{
>>>> +       struct slimpro_mbox_chan *mb_chan = chan->con_priv;
>>>> +
>>>> +       mb_chan_send_msg(mb_chan, msg);
>>>> +       return 0;
>>>> +}
>>>> +
>>>> +static int slimpro_mbox_startup(struct mbox_chan *chan)
>>>> +{
>>>> +       struct slimpro_mbox_chan *mb_chan = chan->con_priv;
>>>> +       int rc;
>>>> +       u32 val;
>>>> +
>>>> +       rc = devm_request_irq(mb_chan->dev, mb_chan->irq, slimpro_mbox_irq, 0,
>>>> +                             MBOX_CON_NAME, mb_chan);
>>>> +       if (unlikely(rc)) {
>>>> +               dev_err(mb_chan->dev, "failed to register mailbox interrupt %d\n",
>>>> +                       mb_chan->irq);
>>>> +               return rc;
>>>> +       }
>>>> +
>>>> +       /* Enable HW interrupt */
>>>> +       writel(MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK,
>>>> +              mb_chan->reg + REG_DB_STAT);
>>>> +       /* Unmask doorbell status interrupt */
>>>> +       val = readl(mb_chan->reg + REG_DB_STATMASK);
>>>> +       val &= ~(MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK);
>>>> +       writel(val, mb_chan->reg + REG_DB_STATMASK);
>>>> +
>>>> +       return 0;
>>>> +}
>>>> +
>>>> +static void slimpro_mbox_shutdown(struct mbox_chan *chan)
>>>> +{
>>>> +       struct slimpro_mbox_chan *mb_chan = chan->con_priv;
>>>> +       u32 val;
>>>> +
>>>> +       /* Mask doorbell status interrupt */
>>>> +       val = readl(mb_chan->reg + REG_DB_STATMASK);
>>>> +       val |= (MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK);
>>>> +       writel(val, mb_chan->reg + REG_DB_STATMASK);
>>>> +
>>>> +       devm_free_irq(mb_chan->dev, mb_chan->irq, mb_chan);
>>>> +}
>>>> +
>>>> +static struct mbox_chan_ops slimpro_mbox_ops = {
>>>> +       .send_data = slimpro_mbox_send_data,
>>>> +       .startup = slimpro_mbox_startup,
>>>> +       .shutdown = slimpro_mbox_shutdown,
>>>> +};
>>>> +
>>>> +static int slimpro_mbox_probe(struct platform_device *pdev)
>>>> +{
>>>> +       struct slimpro_mbox *ctx;
>>>> +       struct resource *regs;
>>>> +       void __iomem *mb_base;
>>>> +       int rc;
>>>> +       int i;
>>>> +
>>>> +       ctx = devm_kzalloc(&pdev->dev, sizeof(struct slimpro_mbox), GFP_KERNEL);
>>>> +       if (IS_ERR(ctx))
>>>> +               return PTR_ERR(ctx);
>>>> +
>>>> +       platform_set_drvdata(pdev, ctx);
>>>> +
>>>> +       regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>> +       mb_base = devm_ioremap(&pdev->dev, regs->start, resource_size(regs));
>>>> +       if (IS_ERR(mb_base))
>>>> +               return PTR_ERR(mb_base);
>>>> +
>>>> +       /* Setup mailbox links */
>>>> +       for (i = 0; i < MBOX_CNT; i++) {
>>>> +               ctx->mc[i].irq = platform_get_irq(pdev, i);
>>>> +               if (ctx->mc[i].irq < 0) {
>>>> +                       if (i == 0) {
>>>> +                               dev_err(&pdev->dev, "no available IRQ\n");
>>>> +                               return -EINVAL;
>>>> +                       }
>>>> +                       dev_info(&pdev->dev, "no IRQ for channel %d\n", i);
>>>> +                       break;
>>>> +               }
>>>> +
>>>> +               ctx->mc[i].dev = &pdev->dev;
>>>> +               ctx->mc[i].reg = mb_base + i * MBOX_REG_SET_OFFSET;
>>>> +               ctx->mc[i].chan = &ctx->chans[i];
>>>> +               ctx->chans[i].con_priv = &ctx->mc[i];
>>>> +       }
>>>> +
>>>> +       /* Setup mailbox controller */
>>>> +       ctx->mb_ctrl.dev = &pdev->dev;
>>>> +       ctx->mb_ctrl.chans = ctx->chans;
>>>> +       ctx->mb_ctrl.txdone_irq = true;
>>>> +       ctx->mb_ctrl.ops = &slimpro_mbox_ops;
>>>> +       ctx->mb_ctrl.num_chans = i;
>>>> +
>>>> +       rc = mbox_controller_register(&ctx->mb_ctrl);
>>>> +       if (rc) {
>>>> +               dev_err(&pdev->dev,
>>>> +                       "APM X-Gene SLIMpro MailBox register failed:%d\n", rc);
>>>> +               return rc;
>>>> +       }
>>>> +
>>>> +       dev_info(&pdev->dev, "APM X-Gene SLIMpro MailBox registered\n");
>>>> +       return 0;
>>>> +}
>>>> +
>>>> +static int slimpro_mbox_remove(struct platform_device *pdev)
>>>> +{
>>>> +       struct slimpro_mbox *smb = platform_get_drvdata(pdev);
>>>> +
>>>> +       mbox_controller_unregister(&smb->mb_ctrl);
>>>> +       return 0;
>>>> +}
>>>> +
>>>> +static const struct of_device_id slimpro_of_match[] = {
>>>> +       {.compatible = "apm,xgene-slimpro-mbox" },
>>>> +       { },
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, slimpro_of_match);
>>>> +
>>>> +#ifdef CONFIG_ACPI
>>>> +static const struct acpi_device_id slimpro_acpi_ids[] = {
>>>> +       {"APMC0D01", 0},
>>>> +       {}
>>>> +};
>>>> +MODULE_DEVICE_TABLE(acpi, slimpro_acpi_ids);
>>>> +#endif
>>>> +
>>>> +static struct platform_driver slimpro_mbox_driver = {
>>>> +       .probe  = slimpro_mbox_probe,
>>>> +       .remove = slimpro_mbox_remove,
>>>> +       .driver = {
>>>> +               .name = "xgene-slimpro-mbox",
>>>> +               .of_match_table = of_match_ptr(slimpro_of_match),
>>>> +               .acpi_match_table = ACPI_PTR(slimpro_acpi_ids)
>>>> +       },
>>>> +};
>>>> +
>>>> +static int __init slimpro_mbox_init(void)
>>>> +{
>>>> +       return platform_driver_register(&slimpro_mbox_driver);
>>>> +}
>>>> +
>>>> +static void __exit slimpro_mbox_exit(void)
>>>> +{
>>>> +       platform_driver_unregister(&slimpro_mbox_driver);
>>>> +}
>>>> +
>>>> +subsys_initcall(slimpro_mbox_init);
>>>> +module_exit(slimpro_mbox_exit);
>>>> +
>>>> +MODULE_DESCRIPTION("APM X-Gene SLIMpro Mailbox Driver");
>>>> +MODULE_LICENSE("GPL");
>>>> --
>>>> 1.9.1
>>>>


From dhdang at apm.com  Fri Feb 12 19:39:25 2016
From: dhdang at apm.com (Duc Dang)
Date: Fri, 12 Feb 2016 19:39:25 -0800
Subject: [PATCH v6 0/3] mailbox: Add APM X-Gene platform mailbox driver
In-Reply-To: <CANLsYkxPnFCuJLyKsHnXKdbvAwNurtgQgJ-WF+bD26+8EjkfJw@mail.gmail.com>
References: <CANLsYkxPnFCuJLyKsHnXKdbvAwNurtgQgJ-WF+bD26+8EjkfJw@mail.gmail.com>
Message-ID: <cover.1455333720.git.dhdang@apm.com>

APM X-Gene SoC has a mailbox controller that provides
communication mechanism for X-Gene Arm64 cores to communicate
with X-Gene SoC's Cortex M3 (SLIMpro) processor.

X-Gene mailbox controller provides 8 mailbox channels, with
each channel has a dedicated interrupt line.

Changes since v5:
	- Add more description into SlimPRO
	mailbox data structure

Changes since v4:
        - Rebase over v4.5-rc1
        - Fix section mismatch warning during compiling
        - Correctly print channel number when there is
        no IRQ for that channel
        - Change node name to mailbox at 10540000
	- Correct the number of IRQs in documentation

Changes since v3:
        - Rebase over v4.4
        - Remove 'id' in slimpro_mbox_chan structure
        - Remove functions that are only called once
        and fold them into the other callers
        - Remove void* pointer type cast
        - Relax the number of mailbox IRQs condition
        - Fix error and address comment in documentation
        (xgene-slimpro-mailbox.txt)

Changes since v2:
        - Rebase Feng's patch set over v4.3-rc5
        - Remove uneccessary 'inline' in function definition
        - Use module_platform_driver instead of subsys_initcall
        - Minor coding stype clean up

Changes since v1:
        - Add ACPI support
        - Use defines for reg offset

Duc Dang (3):
  mailbox: Add support for APM X-Gene platform mailbox driver
  Documentation: mailbox: Add APM X-Gene SLIMpro mailbox dts
    documentation
  arm64: dts: mailbox device tree node for APM X-Gene platform.

 .../bindings/mailbox/xgene-slimpro-mailbox.txt     |  35 +++
 arch/arm64/boot/dts/apm/apm-storm.dtsi             |  14 +
 drivers/mailbox/Kconfig                            |   9 +
 drivers/mailbox/Makefile                           |   2 +
 drivers/mailbox/mailbox-xgene-slimpro.c            | 284 +++++++++++++++++++++
 5 files changed, 344 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
 create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c

-- 
1.9.1



From dhdang at apm.com  Fri Feb 12 19:39:26 2016
From: dhdang at apm.com (Duc Dang)
Date: Fri, 12 Feb 2016 19:39:26 -0800
Subject: [PATCH v6 1/3] mailbox: Add support for APM X-Gene platform mailbox
 driver
In-Reply-To: <cover.1455333720.git.dhdang@apm.com>
References: <cover.1455333720.git.dhdang@apm.com>
Message-ID: <00c76bac779ab927eb799db9e1cf8fc86d955857.1455333720.git.dhdang@apm.com>

X-Gene mailbox controller provides 8 mailbox channels, with
each channel has a dedicated interrupt line.

Signed-off-by: Feng Kan <fkan at apm.com>
Signed-off-by: Duc Dang <dhdang at apm.com>
---
Changes since v5:
	- Add description for struct slimpro_mbox_chan
	and struct slimpro_mbox

Changes since v4:
        - Rebase over v4.5-rc1
        - Fix section mistmatch warning by removing
        __init in slimpro_mbox_probe declaration
        - Correctly print channel number when
        there is no IRQ for that channel

Changes since v3:
        - Rebase over v4.4
        - Remove 'id' in slimpro_mbox_chan structure
        - Remove small functions that are only called once
        and fold them into the other callers
        - Remove void* pointer type cast
        - Relax the number of mailbox IRQs condition
        - Use subsys_initcall to guarantee mailbox driver
        will be registered before any other dependent driver
        is loaded.

 drivers/mailbox/Kconfig                 |   9 +
 drivers/mailbox/Makefile                |   2 +
 drivers/mailbox/mailbox-xgene-slimpro.c | 284 ++++++++++++++++++++++++++++++++
 3 files changed, 295 insertions(+)
 create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 546d05f..678e434 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -85,4 +85,13 @@ config MAILBOX_TEST
 	  Test client to help with testing new Controller driver
 	  implementations.
 
+config XGENE_SLIMPRO_MBOX
+	tristate "APM SoC X-Gene SLIMpro Mailbox Controller"
+	depends on ARCH_XGENE
+	help
+	  An implementation of the APM X-Gene Interprocessor Communication
+	  Mailbox (IPCM) between the ARM 64-bit cores and SLIMpro controller.
+	  It is used to send short messages between ARM64-bit cores and
+	  the SLIMpro Management Engine, primarily for PM. Say Y here if you
+	  want to use the APM X-Gene SLIMpro IPCM support.
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 92435ef..b602ef8 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -17,3 +17,5 @@ obj-$(CONFIG_ALTERA_MBOX)	+= mailbox-altera.o
 obj-$(CONFIG_BCM2835_MBOX)	+= bcm2835-mailbox.o
 
 obj-$(CONFIG_STI_MBOX)		+= mailbox-sti.o
+
+obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c b/drivers/mailbox/mailbox-xgene-slimpro.c
new file mode 100644
index 0000000..b5f5106
--- /dev/null
+++ b/drivers/mailbox/mailbox-xgene-slimpro.c
@@ -0,0 +1,284 @@
+/*
+ * APM X-Gene SLIMpro MailBox Driver
+ *
+ * Copyright (c) 2015, Applied Micro Circuits Corporation
+ * Author: Feng Kan fkan at apm.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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/delay.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+
+#define MBOX_CON_NAME			"slimpro-mbox"
+#define MBOX_REG_SET_OFFSET		0x1000
+#define MBOX_CNT			8
+#define MBOX_STATUS_AVAIL_MASK		BIT(16)
+#define MBOX_STATUS_ACK_MASK		BIT(0)
+
+/* Configuration and Status Registers */
+#define REG_DB_IN		0x00
+#define REG_DB_DIN0		0x04
+#define REG_DB_DIN1		0x08
+#define REG_DB_OUT		0x10
+#define REG_DB_DOUT0		0x14
+#define REG_DB_DOUT1		0x18
+#define REG_DB_STAT		0x20
+#define REG_DB_STATMASK		0x24
+
+/**
+ * X-Gene SlimPRO mailbox channel information
+ *
+ * @dev:	Device to which it is attached
+ * @chan:	Pointer to mailbox communication channel
+ * @reg:	Base address to access channel registers
+ * @irq:	Interrupt number of the channel
+ * @rx_msg:	Received message storage
+ */
+struct slimpro_mbox_chan {
+	struct device		*dev;
+	struct mbox_chan	*chan;
+	void __iomem		*reg;
+	int			irq;
+	u32			rx_msg[3];
+};
+
+/**
+ * X-Gene SlimPRO Mailbox controller data
+ *
+ * X-Gene SlimPRO Mailbox controller has 8 commnunication channels.
+ * Each channel has a separate IRQ number assgined to it.
+ *
+ * @mb_ctrl:	Representation of the commnunication channel controller
+ * @mc:		Array of SlimPRO mailbox channels of the controller
+ * @chans:	Array of mailbox communication channels
+ *
+ */
+struct slimpro_mbox {
+	struct mbox_controller		mb_ctrl;
+	struct slimpro_mbox_chan	mc[MBOX_CNT];
+	struct mbox_chan		chans[MBOX_CNT];
+};
+
+static void mb_chan_send_msg(struct slimpro_mbox_chan *mb_chan, u32 *msg)
+{
+	writel(msg[1], mb_chan->reg + REG_DB_DOUT0);
+	writel(msg[2], mb_chan->reg + REG_DB_DOUT1);
+	writel(msg[0], mb_chan->reg + REG_DB_OUT);
+}
+
+static void mb_chan_recv_msg(struct slimpro_mbox_chan *mb_chan)
+{
+	mb_chan->rx_msg[1] = readl(mb_chan->reg + REG_DB_DIN0);
+	mb_chan->rx_msg[2] = readl(mb_chan->reg + REG_DB_DIN1);
+	mb_chan->rx_msg[0] = readl(mb_chan->reg + REG_DB_IN);
+}
+
+static int mb_chan_status_ack(struct slimpro_mbox_chan *mb_chan)
+{
+	u32 val = readl(mb_chan->reg + REG_DB_STAT);
+
+	if (val & MBOX_STATUS_ACK_MASK) {
+		writel(MBOX_STATUS_ACK_MASK, mb_chan->reg + REG_DB_STAT);
+		return 1;
+	}
+	return 0;
+}
+
+static int mb_chan_status_avail(struct slimpro_mbox_chan *mb_chan)
+{
+	u32 val = readl(mb_chan->reg + REG_DB_STAT);
+
+	if (val & MBOX_STATUS_AVAIL_MASK) {
+		mb_chan_recv_msg(mb_chan);
+		writel(MBOX_STATUS_AVAIL_MASK, mb_chan->reg + REG_DB_STAT);
+		return 1;
+	}
+	return 0;
+}
+
+static irqreturn_t slimpro_mbox_irq(int irq, void *id)
+{
+	struct slimpro_mbox_chan *mb_chan = id;
+
+	if (mb_chan_status_ack(mb_chan))
+		mbox_chan_txdone(mb_chan->chan, 0);
+
+	if (mb_chan_status_avail(mb_chan))
+		mbox_chan_received_data(mb_chan->chan, mb_chan->rx_msg);
+
+	return IRQ_HANDLED;
+}
+
+static int slimpro_mbox_send_data(struct mbox_chan *chan, void *msg)
+{
+	struct slimpro_mbox_chan *mb_chan = chan->con_priv;
+
+	mb_chan_send_msg(mb_chan, msg);
+	return 0;
+}
+
+static int slimpro_mbox_startup(struct mbox_chan *chan)
+{
+	struct slimpro_mbox_chan *mb_chan = chan->con_priv;
+	int rc;
+	u32 val;
+
+	rc = devm_request_irq(mb_chan->dev, mb_chan->irq, slimpro_mbox_irq, 0,
+			      MBOX_CON_NAME, mb_chan);
+	if (unlikely(rc)) {
+		dev_err(mb_chan->dev, "failed to register mailbox interrupt %d\n",
+			mb_chan->irq);
+		return rc;
+	}
+
+	/* Enable HW interrupt */
+	writel(MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK,
+	       mb_chan->reg + REG_DB_STAT);
+	/* Unmask doorbell status interrupt */
+	val = readl(mb_chan->reg + REG_DB_STATMASK);
+	val &= ~(MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK);
+	writel(val, mb_chan->reg + REG_DB_STATMASK);
+
+	return 0;
+}
+
+static void slimpro_mbox_shutdown(struct mbox_chan *chan)
+{
+	struct slimpro_mbox_chan *mb_chan = chan->con_priv;
+	u32 val;
+
+	/* Mask doorbell status interrupt */
+	val = readl(mb_chan->reg + REG_DB_STATMASK);
+	val |= (MBOX_STATUS_ACK_MASK | MBOX_STATUS_AVAIL_MASK);
+	writel(val, mb_chan->reg + REG_DB_STATMASK);
+
+	devm_free_irq(mb_chan->dev, mb_chan->irq, mb_chan);
+}
+
+static struct mbox_chan_ops slimpro_mbox_ops = {
+	.send_data = slimpro_mbox_send_data,
+	.startup = slimpro_mbox_startup,
+	.shutdown = slimpro_mbox_shutdown,
+};
+
+static int slimpro_mbox_probe(struct platform_device *pdev)
+{
+	struct slimpro_mbox *ctx;
+	struct resource *regs;
+	void __iomem *mb_base;
+	int rc;
+	int i;
+
+	ctx = devm_kzalloc(&pdev->dev, sizeof(struct slimpro_mbox), GFP_KERNEL);
+	if (IS_ERR(ctx))
+		return PTR_ERR(ctx);
+
+	platform_set_drvdata(pdev, ctx);
+
+	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mb_base = devm_ioremap(&pdev->dev, regs->start, resource_size(regs));
+	if (IS_ERR(mb_base))
+		return PTR_ERR(mb_base);
+
+	/* Setup mailbox links */
+	for (i = 0; i < MBOX_CNT; i++) {
+		ctx->mc[i].irq = platform_get_irq(pdev, i);
+		if (ctx->mc[i].irq < 0) {
+			if (i == 0) {
+				dev_err(&pdev->dev, "no available IRQ\n");
+				return -EINVAL;
+			}
+			dev_info(&pdev->dev, "no IRQ for channel %d\n", i);
+			break;
+		}
+
+		ctx->mc[i].dev = &pdev->dev;
+		ctx->mc[i].reg = mb_base + i * MBOX_REG_SET_OFFSET;
+		ctx->mc[i].chan = &ctx->chans[i];
+		ctx->chans[i].con_priv = &ctx->mc[i];
+	}
+
+	/* Setup mailbox controller */
+	ctx->mb_ctrl.dev = &pdev->dev;
+	ctx->mb_ctrl.chans = ctx->chans;
+	ctx->mb_ctrl.txdone_irq = true;
+	ctx->mb_ctrl.ops = &slimpro_mbox_ops;
+	ctx->mb_ctrl.num_chans = i;
+
+	rc = mbox_controller_register(&ctx->mb_ctrl);
+	if (rc) {
+		dev_err(&pdev->dev,
+			"APM X-Gene SLIMpro MailBox register failed:%d\n", rc);
+		return rc;
+	}
+
+	dev_info(&pdev->dev, "APM X-Gene SLIMpro MailBox registered\n");
+	return 0;
+}
+
+static int slimpro_mbox_remove(struct platform_device *pdev)
+{
+	struct slimpro_mbox *smb = platform_get_drvdata(pdev);
+
+	mbox_controller_unregister(&smb->mb_ctrl);
+	return 0;
+}
+
+static const struct of_device_id slimpro_of_match[] = {
+	{.compatible = "apm,xgene-slimpro-mbox" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, slimpro_of_match);
+
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id slimpro_acpi_ids[] = {
+	{"APMC0D01", 0},
+	{}
+};
+MODULE_DEVICE_TABLE(acpi, slimpro_acpi_ids);
+#endif
+
+static struct platform_driver slimpro_mbox_driver = {
+	.probe	= slimpro_mbox_probe,
+	.remove = slimpro_mbox_remove,
+	.driver	= {
+		.name = "xgene-slimpro-mbox",
+		.of_match_table = of_match_ptr(slimpro_of_match),
+		.acpi_match_table = ACPI_PTR(slimpro_acpi_ids)
+	},
+};
+
+static int __init slimpro_mbox_init(void)
+{
+	return platform_driver_register(&slimpro_mbox_driver);
+}
+
+static void __exit slimpro_mbox_exit(void)
+{
+	platform_driver_unregister(&slimpro_mbox_driver);
+}
+
+subsys_initcall(slimpro_mbox_init);
+module_exit(slimpro_mbox_exit);
+
+MODULE_DESCRIPTION("APM X-Gene SLIMpro Mailbox Driver");
+MODULE_LICENSE("GPL");
-- 
1.9.1



From dhdang at apm.com  Fri Feb 12 19:39:27 2016
From: dhdang at apm.com (Duc Dang)
Date: Fri, 12 Feb 2016 19:39:27 -0800
Subject: [PATCH v6 2/3] Documentation: mailbox: Add APM X-Gene SLIMpro mailbox
 dts documentation
In-Reply-To: <cover.1455333720.git.dhdang@apm.com>
References: <cover.1455333720.git.dhdang@apm.com>
Message-ID: <4cf26966ebb6f5f41aab4e258984ac0600835748.1455333720.git.dhdang@apm.com>

This adds the APM X-Gene SLIMpro mailbox device tree
node documentation.

Signed-off-by: Feng Kan <fkan at apm.com>
Signed-off-by: Duc Dang <dhdang at apm.com>
Acked-by: Rob Herring <robh at kernel.org>
---
Changes since v5:
	- None

Changes since v4:
        - Rebase over v4.5-rc1
        - Fix number of total interrupts in
        introduction text
        - Change node name to mailbox at 10540000

Changes since v3:
        - Rebase over v4.4
        - Change number of mailbox IRQs to 8
        - Fix white spaces, typos.

 .../bindings/mailbox/xgene-slimpro-mailbox.txt     | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt

diff --git a/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt b/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
new file mode 100644
index 0000000..e46451b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
@@ -0,0 +1,35 @@
+The APM X-Gene SLIMpro mailbox is used to communicate messages between
+the ARM64 processors and the Cortex M3 (dubbed SLIMpro). It uses a simple
+interrupt based door bell mechanism and can exchange simple messages using the
+internal registers.
+
+There are total of 8 interrupts in this mailbox. Each used for an individual
+door bell (or mailbox channel).
+
+Required properties:
+- compatible:	Should be as "apm,xgene-slimpro-mbox".
+
+- reg:		Contains the mailbox register address range.
+
+- interrupts:	8 interrupts must be from 0 to 7, interrupt 0 define the
+		the interrupt for mailbox channel 0 and interrupt 1 for
+		mailbox channel 1 and so likewise for the reminder.
+
+- #mbox-cells:	only one to specify the mailbox channel number.
+
+Example:
+
+Mailbox Node:
+		mailbox: mailbox at 10540000 {
+			compatible = "apm,xgene-slimpro-mbox";
+			reg = <0x0 0x10540000 0x0 0xa000>;
+			#mbox-cells = <1>;
+			interrupts =  	<0x0 0x0 0x4>,
+					<0x0 0x1 0x4>,
+					<0x0 0x2 0x4>,
+					<0x0 0x3 0x4>,
+					<0x0 0x4 0x4>,
+					<0x0 0x5 0x4>,
+					<0x0 0x6 0x4>,
+					<0x0 0x7 0x4>,
+		};
-- 
1.9.1



From dhdang at apm.com  Fri Feb 12 19:39:28 2016
From: dhdang at apm.com (Duc Dang)
Date: Fri, 12 Feb 2016 19:39:28 -0800
Subject: [PATCH v6 3/3] arm64: dts: mailbox device tree node for APM X-Gene
 platform.
In-Reply-To: <cover.1455333720.git.dhdang@apm.com>
References: <cover.1455333720.git.dhdang@apm.com>
Message-ID: <eeac516f6daa15b22a1c448160ed40991833035a.1455333720.git.dhdang@apm.com>

Mailbox device tree node for APM X-Gene platform.

Signed-off-by: Feng Kan <fkan at apm.com>
Signed-off-by: Duc Dang <dhdang at apm.com>
---
Changes since v5:
	- None

Changes since v4:
        - Rebase over v4.5-rc1
        - Change node name to mailbox at 10540000

Changes since v3:
        - Rebase over v4.4

 arch/arm64/boot/dts/apm/apm-storm.dtsi | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index fe30f76..d91338a 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -691,6 +691,20 @@
 			msi-parent = <&msi>;
 		};
 
+		mailbox: mailbox at 10540000 {
+			compatible = "apm,xgene-slimpro-mbox";
+			reg = <0x0 0x10540000 0x0 0xa000>;
+			#mbox-cells = <1>;
+			interrupts =    <0x0 0x0 0x4>,
+					<0x0 0x1 0x4>,
+					<0x0 0x2 0x4>,
+					<0x0 0x3 0x4>,
+					<0x0 0x4 0x4>,
+					<0x0 0x5 0x4>,
+					<0x0 0x6 0x4>,
+					<0x0 0x7 0x4>;
+		};
+
 		serial0: serial at 1c020000 {
 			status = "disabled";
 			device_type = "serial";
-- 
1.9.1



From f.fainelli at gmail.com  Fri Feb 12 20:00:23 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Fri, 12 Feb 2016 20:00:23 -0800
Subject: [GIT PULL] bcm2835 DT changes for 4.6
In-Reply-To: <877fi92zxb.fsf@eliezer.anholt.net>
References: <1454977978-17491-1-git-send-email-eric@anholt.net>
 <DDFB1D8B-805B-488F-9582-796EBCEF287B@sperl.org>
 <87d1s42yb8.fsf@eliezer.anholt.net> <56BD55A2.20104@gmail.com>
 <877fi92zxb.fsf@eliezer.anholt.net>
Message-ID: <56BEAA57.3050600@gmail.com>

On 12/02/2016 16:53, Eric Anholt wrote:
> Florian Fainelli <f.fainelli at gmail.com> writes:
> 
>> On 10/02/2016 10:51, Eric Anholt wrote:
>>> Martin Sperl <martin at sperl.org> writes:
>>>
>>>>> On 09.02.2016, at 01:32, Eric Anholt <eric at anholt.net> wrote:
>>>>>
>>>>> Hi Florian.  Here's the first set of patches for bcm2835 for 4.6.
>>>>> We've got more DT patches that are going to happen for new boards,
>>>>> too, but they're still getting polished.
>>>>>
>>>>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>>>>
>>>>>  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>>>>
>>>>> are available in the git repository at:
>>>>>
>>>>>  git at github.com:anholt/linux.git tags/bcm2835-dt-next-2016-02-04
>>>>>
>>>>> for you to fetch changes up to 5ec6f2cd8ec4bcd38ba199ea8711a5ec906d85e7:
>>>>>
>>>>>  ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT. (2016-02-02 20:02:45 -0800)
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> This pull request covers mostly DT changes that didn't make it into
>>>>> 4.5 because required header files went through other trees.
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> Alexander Aring (1):
>>>>>      ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
>>>>>
>>>>> Lubomir Rintel (1):
>>>>>      ARM: bcm2835: dt: Add Raspberry Pi Model A
>>>>>
>>>>> Martin Sperl (2):
>>>>>      ARM: bcm2835: add the auxiliary spi1 and spi2 to the device tree
>>>>>      ARM: bcm2835: follow dt uart node-naming convention
>>>>
>>>> Do you want me to resend a rebased version of:
>>>>      ARM: bcm2835: add bcm2835-aux-uart support to default DT
>>>>
>>>> The corresponding driver has been added to tty/tty-next.
>>>
>>> It hadn't landed last time I checked.  A rebased version that you've
>>> tested would be great!
>>
>> OK, please submit this in the next week or so at most, so we can get
>> this pull request merged, thanks!
>>
>> Eric, do you have other changes outside of Device Tree?
> 
> We've got bcm2835_defconfig changes that I need to test and tag.

Ok, so that one needs to be a pull request.

> 
> There are also the multi_v7_defconfig updates to enable bcm2835.  Would
> I be pulling those, or someone above me?

This one could too, or it could be an individual patch that the arm-soc
maintainers take directly, either way is fine AFAIR.
--
Florian


From sricharan at codeaurora.org  Fri Feb 12 22:58:50 2016
From: sricharan at codeaurora.org (Sricharan)
Date: Sat, 13 Feb 2016 12:28:50 +0530
Subject: [PATCH V7 4/6] i2c: qup: Add bam dma capabilities
In-Reply-To: <20160212183737.GA1520@katana>
References: <1453197766-18976-1-git-send-email-sricharan@codeaurora.org>
 <1453197766-18976-5-git-send-email-sricharan@codeaurora.org>
 <20160212183737.GA1520@katana>
Message-ID: <002e01d1662c$0579d640$106d82c0$@codeaurora.org>

Hi Wolfram,

> -----Original Message-----
> From: Wolfram Sang [mailto:wsa at the-dreams.de]
> Sent: Saturday, February 13, 2016 12:08 AM
> To: Sricharan R
> Cc: devicetree at vger.kernel.org; linux-arm-msm at vger.kernel.org;
> agross at codeaurora.org; linux-kernel at vger.kernel.org; linux-
> i2c at vger.kernel.org; iivanov at mm-sol.com; galak at codeaurora.org;
> dmaengine at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> andy.gross at linaro.org; ntelkar at codeaurora.org; architt at codeaurora.org
> Subject: Re: [PATCH V7 4/6] i2c: qup: Add bam dma capabilities
> 
> On Tue, Jan 19, 2016 at 03:32:44PM +0530, Sricharan R wrote:
> > QUP cores can be attached to a BAM module, which acts as a dma engine
> > for the QUP core. When DMA with BAM is enabled, the BAM consumer
> pipe
> > transmitted data is written to the output FIFO and the BAM producer
> > pipe received data is read from the input FIFO.
> >
> > With BAM capabilities, qup-i2c core can transfer more than
> > 256 bytes, without a 'stop' which is not possible otherwise.
> >
> > Signed-off-by: Sricharan R <sricharan at codeaurora.org>
> > Reviewed-by: Andy Gross <andy.gross at linaro.org>
> > Tested-by: Archit Taneja <architt at codeaurora.org>
> > Tested-by: Telkar Nagender <ntelkar at codeaurora.org>
> 
> My code checkers found some issues:
> 
>     SPARSE
> drivers/i2c/busses/i2c-qup.c:555:6: warning: symbol 'qup_sg_set_buf' was
> not declared. Should it be static?
> drivers/i2c/busses/i2c-qup.c:1243:50: warning: dubious: !x & !y
>     SMATCH
> drivers/i2c/busses/i2c-qup.c:165 qup_sg_set_buf warn: unused return: s =
> sg_next()
> drivers/i2c/busses/i2c-qup.c:165 qup_sg_set_buf warn: unused return: s =
> sg_next()
> drivers/i2c/busses/i2c-qup.c:1243 qup_i2c_xfer_v2() warn: add some
> parenthesis here?
>     CPPCHECK
> drivers/i2c/busses/i2c-qup.c:1243: style: Boolean result is used in
bitwise
> operation. Clarify expression with parentheses.
>     SPATCH
> drivers/i2c/busses/i2c-qup.c:1380:2-13: WARNING: Assignment of bool to 0/1
> drivers/i2c/busses/i2c-qup.c:1481:1-13: WARNING: Assignment of bool to 0/1
>   CC      drivers/i2c/busses/i2c-qup.o
> drivers/i2c/busses/i2c-qup.c:555:6: warning: no previous prototype for
> 'qup_sg_set_buf' [-Wmissing-prototypes]  void qup_sg_set_buf(struct
> scatterlist *sg, void *buf, struct qup_i2c_tag *tg,
> 
> Can you fix them and resend??

    Sorry on this , will resend this patch.

Regards,
 Sricharan



From ard.biesheuvel at linaro.org  Sat Feb 13 00:39:35 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Sat, 13 Feb 2016 09:39:35 +0100
Subject: [PATCH] [media] zl10353: use div_u64 instead of do_div
In-Reply-To: <6737272.LXr2g355Yt@wuerfel>
References: <1455287246-3540549-1-git-send-email-arnd@arndb.de>
 <2712691.b9gkR7KMX7@wuerfel>
 <alpine.LFD.2.20.1602121305180.13632@knanqh.ubzr>
 <6737272.LXr2g355Yt@wuerfel>
Message-ID: <CAKv+Gu8dFz28tGgQTv+WYAvKpeiFXaj8JANUFtOJwKPRsB8F5A@mail.gmail.com>

On 12 February 2016 at 22:01, Arnd Bergmann <arnd at arndb.de> wrote:
> On Friday 12 February 2016 13:21:33 Nicolas Pitre wrote:
>> On Fri, 12 Feb 2016, Arnd Bergmann wrote:
>>
>> > On Friday 12 February 2016 14:32:20 Mauro Carvalho Chehab wrote:
>> > > Em Fri, 12 Feb 2016 15:27:18 +0100
>> > > Arnd Bergmann <arnd at arndb.de> escreveu:
>> > >
>> > > > I noticed a build error in some randconfig builds in the zl10353 driver:
>> > > >
>> > > > dvb-frontends/zl10353.c:138: undefined reference to `____ilog2_NaN'
>> > > > dvb-frontends/zl10353.c:138: undefined reference to `__aeabi_uldivmod'
>> > > >
>> > > > The problem can be tracked down to the use of -fprofile-arcs (using
>> > > > CONFIG_GCOV_PROFILE_ALL) in combination with CONFIG_PROFILE_ALL_BRANCHES
>> > > > on gcc version 4.9 or higher, when it fails to reliably optimize
>> > > > constant expressions.
>> > > >
>> > > > Using div_u64() instead of do_div() makes the code slightly more
>> > > > readable by both humans and by gcc, which gives the compiler enough
>> > > > of a break to figure it all out.
>> > >
>> > > I'm not against this patch, but we have 94 occurrences of do_div()
>> > > just at the media subsystem. If this is failing here, it would likely
>> > > fail with other drivers. So, I guess we should either fix do_div() or
>> > > convert all such occurrences to do_div64().
>> >
>> > I agree that it's possible that the same problem exists elsewhere, but this is
>> > the only one that I ever saw (in five ranconfig builds out of 8035 last week).
>> >
>> > I also tried changing do_div() to be an inline function with just a small
>> > macro wrapper around it for the odd calling conventions, which also made this
>> > error go away. I would assume that Nico had a good reason for doing do_div()
>> > the way he did.
>>
>> The do_div() calling convention predates my work on it.  I assume it was
>> originally done this way to better map onto the x86 instruction.
>
> Right, this goes back to the dawn of time.
>
>> > In some other files, I saw the object code grow by a few
>> > instructions, but the examples I looked at were otherwise identical.
>> >
>> > I can imagine that there might be cases where the constant-argument optimization
>> > of do_div fails when we go through an inline function in some combination
>> > of Kconfig options and compiler version, though I don't think that was
>> > the case here.
>>
>> What could be tried is to turn __div64_const32() into a static inline
>> and see if that makes a difference with those gcc versions we currently
>> accept.
>>
>> > Nico, any other thoughts on this?
>>
>> This is all related to the gcc bug for which I produced a test case
>> here:
>>
>> http://article.gmane.org/gmane.linux.kernel.cross-arch/29801
>>
>> Do you know if this is fixed in recent gcc?
>
> I have a fairly recent gcc, but I also never got around to submit
> it properly.
>
> However, I did stumble over an older patch I did now, which I could
> not remember what it was good for. It does fix the problem, and
> it seems to be a better solution.
>
>         Arnd
>
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index b5acbb404854..b5ff9881bef8 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -148,7 +148,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
>   */
>  #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
>  #define __trace_if(cond) \
> -       if (__builtin_constant_p((cond)) ? !!(cond) :                   \
> +       if (__builtin_constant_p(!!(cond)) ? !!(cond) :                 \
>         ({                                                              \
>                 int ______r;                                            \
>                 static struct ftrace_branch_data                        \
>

I remember seeing this patch, but I don't remember the exact context.
But when you think about it, !!cond can be a build time constant even
if cond is not, as long as you can prove statically that cond != 0. So
I think this change is obviously correct, and an improvement since it
will remove the profiling overhead of branches that are not true
branches in the first place.


From kernel at martin.sperl.org  Sat Feb 13 00:51:21 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Sat, 13 Feb 2016 09:51:21 +0100
Subject: [PATCH V2 1/3] ASoC: bcm2835: move to use the clock framework
In-Reply-To: <87bn7l3085.fsf@eliezer.anholt.net>
References: <1452602149-5875-1-git-send-email-kernel@martin.sperl.org>
 <1452602149-5875-2-git-send-email-kernel@martin.sperl.org>
 <87vb6dfjbu.fsf@eliezer.anholt.net> <56B88520.5060606@martin.sperl.org>
 <87bn7l3085.fsf@eliezer.anholt.net>
Message-ID: <A3C029B5-816E-4EC3-823D-6755ECD4773B@martin.sperl.org>


> On 13.02.2016, at 01:47, Eric Anholt <eric at anholt.net> wrote:
> 
> Martin Sperl <kernel at martin.sperl.org> writes:
>> 
>> Problem is that we need the VC4 bus-address (0x7e203000),
>> which is the actual <reg> value from the device tree without any
>> mapping.
>> 
>> Not the ARM MMU visible address mappings that mem->start provides
>> (typically 0x20203000 or 0x3f203000 for bcm2836)
>> 
>> Nor the mapped address (base) available in the kernel (typically
>> 0xdc......).
> 
> Now that I've noticed the BCM2835_VCMMU_SHIFT removal, this makes sense,
> but when you put unrelated changes like this together you end up slowing
> down the review process on your patches.  Please separate it out into a
> separate commit.

OK - I agree: I really should have separated those, but as the
driver was broken for both reasons and the MMU_SHIFT was the earliest
fix I forgot about it when I got the final version for submission.

Anyway: Mark has already applied this patch on January 15th into for-next:
https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/commit/sound/soc/bcm/bcm2835-i2s.c?h=for-next&id=517e7a1537ae4663268be5d0c0ec62c563b9fc99
so it should go into the next release...

So unless Mark wants to revert it and have two separate patches
instead, I guess we need to leave it like it is.

Martin



From ard.biesheuvel at linaro.org  Sat Feb 13 01:00:56 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Sat, 13 Feb 2016 10:00:56 +0100
Subject: [kernel-hardening] [PATCH] arm64: vdso: Mark vDSO code as
 read-only
In-Reply-To: <20160213003147.GA12074@davidb.org>
References: <1455141142-6838-1-git-send-email-david.brown@linaro.org>
 <CAKv+Gu8ArOYqxDGKb=Tv3NsiB2qWWCdD_zMx55m6+hEwLJR4CA@mail.gmail.com>
 <20160213003147.GA12074@davidb.org>
Message-ID: <CAKv+Gu-5OdN7C_SvDytsoSn2QFkVZmonv2ffjpiuEXJA8tc0GA@mail.gmail.com>

On 13 February 2016 at 01:31, David Brown <david.brown at linaro.org> wrote:
> On Thu, Feb 11, 2016 at 03:19:20PM +0100, Ard Biesheuvel wrote:
>
>>> diff --git a/arch/arm64/kernel/vdso/vdso.S
>>> b/arch/arm64/kernel/vdso/vdso.S
>>> index 60c1db5..db7c0f2 100644
>>> --- a/arch/arm64/kernel/vdso/vdso.S
>>> +++ b/arch/arm64/kernel/vdso/vdso.S
>>> @@ -24,6 +24,7 @@
>>>         __PAGE_ALIGNED_DATA
>>
>>
>> ^^ You can get rid of this now as well
>
>
> Can we?  The page is getting mapped to userspace, and if we didn't
> page align it, we could leak kernel read-only data to every userspace
> process.
>

That's what the .balign is for. __PAGE_ALIGNED_DATA only sets the
section, and you're overriding that right after.


From davem at davemloft.net  Sat Feb 13 03:03:14 2016
From: davem at davemloft.net (David Miller)
Date: Sat, 13 Feb 2016 06:03:14 -0500 (EST)
Subject: [PATCH v3 net 0/7] mvneta fixes for SMP
In-Reply-To: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
References: <1454620169-8156-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160213.060314.257506721983765240.davem@davemloft.net>

From: Gregory CLEMENT <gregory.clement at free-electrons.com>
Date: Thu,  4 Feb 2016 22:09:22 +0100

> Following this bug report:
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/468173 and the
> suggestions from Russell King, I reviewed all the code involving
> multi-CPU. It ended with this series of patches which should improve
> the stability of the driver.
> 
> During my test I found another bug which is fixed by new patch (the
> second one of this new version of the series)
> 
> The two first patches fix real bugs, the others fix potential issues
> in the driver.

Series applied, thanks.


From kernel at martin.sperl.org  Sat Feb 13 03:24:43 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Sat, 13 Feb 2016 12:24:43 +0100
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in
 console
In-Reply-To: <470852136.382408.76a8faee-9235-4ee0-9fd1-e25a1e9f0bb3.open-xchange@email.1und1.de>
References: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
 <56BC895E.2010108@sperl.org>
 <1617009200.323700.219000a8-c162-4594-aacc-a7e9894518b2.open-xchange@email.1und1.de>
 <662D2FB2-B088-4CFC-8416-A4F35BBAD7DD@sperl.org>
 <F7A2533A-D64C-4187-ABD4-416C446D1637@martin.sperl.org>
 <6CD3FC59-BA17-43D9-897C-A2D122D26EF8@martin.sperl.org>
 <470852136.382408.76a8faee-9235-4ee0-9fd1-e25a1e9f0bb3.open-xchange@email.1und1.de>
Message-ID: <F7B22AC0-58A7-431D-B203-0C7A9802A040@martin.sperl.org>


> On 13.02.2016, at 11:01, Stefan Wahren <stefan.wahren at i2se.com> wrote:
> 
> Hi Martin,
> 
>> Martin Sperl <kernel at martin.sperl.org> hat am 12. Februar 2016 um 20:44
>> geschrieben:
>> 
>> So the issue is triggered as soon as the plld_per
>> pll divider gets disabled/reenabled.
>> 
>> This happens because the clk_hw.core.prepare_count
>> drops down to 0 and then unprepare is called.
>> 
>> So we need to increase the ref-count for the pll
>> and pll_dividers to at least 1 so that these never
>> get disabled - at least for now until we can come
>> up with a better contract with the firmware.
>> 
>> Obviously this may impact other drivers as well
>> where a pll is used for the first time - if nothing
>> else uses it and the clock gets released, then
>> the clock would trigger a unprepare of the whole
>> branch of the clock tree.
>> 
>> The question is: how can we solve it in an acceptable
>> manner?
>> 
>> Do we need a driver that just holds a reference to
>> those clocks? Or should we just prepare the clock
>> after registering it in clk-bcm2835.c?
>> 
>> As for why does this not show up when compiled in?
>> It seems that in that case the amba_pl011 driver
>> never gets removed and then probed again.
>> 
>> This is possibly related to the optional use of DMA,
>> with the amba-pl011 driver that retries the install,
>> which is not supported on the bcm2835 - at least that
>> is what the datasheet says. And DMA is (probably) not
>> enabled during the early boot stages, so it does not
>> fail once when it tries to register DMA.
>> 
>> Thanks,
>> Martin
>> 
> 
> i think i must correct myself. The fixed apb should stay since there is no
> dynamic replacement and a proper disabling of plld shouldn't cause this freeze.
> 
> I have the suspicion the freeze is caused by a clock glitch or lock-up.
> 
> Could you please revert your changes and apply the attached patch? Maybe we can
> see more.

I will give it a try.

But to me it seems as if the disabling of PLLD produces a hickup in the 
firmware (which relies on PLLD-DIV and thus PLL).

This would also explain the 3-4 second bar/blanking pattern seen on HDMI,
which I would guess is related to a reset loop...

I got a simple fix for now, that just prepares a few clocks/pll/pll_divs
during probing, so that they will never get unprepared/fully stopped):

diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 015e687..fe0c401 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -37,6 +37,7 @@
  * generator).
  */

+#include <linux/clk.h>
 #include <linux/clk-provider.h>
 #include <linux/clkdev.h>
 #include <linux/clk/bcm2835.h>
@@ -1504,6 +1505,7 @@ static int bcm2835_clk_probe(struct platform_device *pdev)
        struct clk **clks;
        struct bcm2835_cprman *cprman;
        struct resource *res;
+       int ret;

        cprman = devm_kzalloc(dev, sizeof(*cprman), GFP_KERNEL);
        if (!cprman)
@@ -1597,6 +1599,37 @@ static int bcm2835_clk_probe(struct platform_device *pdev
        clks[BCM2835_CLOCK_PWM] =
                bcm2835_register_clock(cprman, &bcm2835_clock_pwm_data);

+       /*
+        * Several PLLs, PLL-dividers and clocks need to get prepared
+        * so that they are never unprepared and released.
+        * We run this separately as there may be dependencies that would
+        * need to be fullfilled first...
+        * Note: Especially unpreparing PLLD_PER will kill the system
+        *       (even if it is prepared again almost immediately
+        *        the HDMI display will fail)
+        */
+#define CLK_PREPARE_INITIAL(clkid)                                     \
+       if (clks[clkid] && (ret = clk_prepare(clks[clkid])))            \
+               dev_err(dev, "could not prepare clock %pC - %d\n",      \
+                       clks[clkid], ret);
+       CLK_PREPARE_INITIAL(BCM2835_PLLA);
+       CLK_PREPARE_INITIAL(BCM2835_PLLB);
+       CLK_PREPARE_INITIAL(BCM2835_PLLC);
+       CLK_PREPARE_INITIAL(BCM2835_PLLD);
+       CLK_PREPARE_INITIAL(BCM2835_PLLH);
+       CLK_PREPARE_INITIAL(BCM2835_PLLA_CORE);
+       CLK_PREPARE_INITIAL(BCM2835_PLLA_PER);
+       CLK_PREPARE_INITIAL(BCM2835_PLLC_CORE0);
+       CLK_PREPARE_INITIAL(BCM2835_PLLC_CORE1);
+       CLK_PREPARE_INITIAL(BCM2835_PLLC_CORE2);
+       CLK_PREPARE_INITIAL(BCM2835_PLLC_PER);
+       CLK_PREPARE_INITIAL(BCM2835_PLLD_CORE);
+       CLK_PREPARE_INITIAL(BCM2835_PLLD_PER);
+       CLK_PREPARE_INITIAL(BCM2835_PLLH_RCAL);
+       CLK_PREPARE_INITIAL(BCM2835_PLLH_AUX);
+       CLK_PREPARE_INITIAL(BCM2835_PLLH_PIX);
+       CLK_PREPARE_INITIAL(BCM2835_CLOCK_VPU);
+
        return of_clk_add_provider(dev->of_node, of_clk_src_onecell_get,
                                   &cprman->onecell);
 }

And that resolves the issue and also allows loading/unloading of the
amba-pl011 module as well without any hickups.

I guess it would be better if we did make this configurable in the DT.
(See patch 1 of my RFC patchset, which could get extended to handle this
as well - at least a portion thereof).

But in more general terms: we need to come up with some agreement
on ownership of the clocks between linux and the firmware and how
to change them without impacting the other. 

One example is the ?overclocking? that currently happens for
downstream kernels in the firmware, which impacts some of the
plls and PLLdivs as well as the sram control registers.

The reason for this seems to be that for overclocking the SRAM
parameters also need to get changed and that can only get done
reliably when running the code from L1/L2 caches - and that
requirement of not touching SRAM while changing the SRAM parameters
is probably hard to achieve cleanly on ARM alone.

Ciao,
	Martin

P.s: unloading amba_pl011 gives the following error:
root at raspcm:~# rmmod amba_pl011
[  142.318263] Trying to free nonexistent resource <0000000020201000-0000000020201fff>
but that is an issue not related to clock...



From kernel at martin.sperl.org  Sat Feb 13 03:53:26 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Sat, 13 Feb 2016 12:53:26 +0100
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in
 console
In-Reply-To: <470852136.382408.76a8faee-9235-4ee0-9fd1-e25a1e9f0bb3.open-xchange@email.1und1.de>
References: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
 <56BC895E.2010108@sperl.org>
 <1617009200.323700.219000a8-c162-4594-aacc-a7e9894518b2.open-xchange@email.1und1.de>
 <662D2FB2-B088-4CFC-8416-A4F35BBAD7DD@sperl.org>
 <F7A2533A-D64C-4187-ABD4-416C446D1637@martin.sperl.org>
 <6CD3FC59-BA17-43D9-897C-A2D122D26EF8@martin.sperl.org>
 <470852136.382408.76a8faee-9235-4ee0-9fd1-e25a1e9f0bb3.open-xchange@email.1und1.de>
Message-ID: <EE05C090-EB8A-41E8-B9C3-8CCC79F15FE9@martin.sperl.org>


> On 13.02.2016, at 11:01, Stefan Wahren <stefan.wahren at i2se.com> wrote:
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index 637f8ae..03d95c1 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -1638,6 +1675,9 @@ static int bcm2835_clock_set_rate(struct clk_hw *hw,
> 	enum bcm2835_clock_mash_type mash = divmash_get_mash(dm);
> 	u32 ctl;
> 
> +	if (cprman_read(cprman, data->ctl_reg) & CM_BUSY)
> +		pr_warn("%s: clk still busy from %d\n", __func__, cprman->func_code);
> +
> 	spin_lock(&cprman->regs_lock);
> 
> 	/* if div and mash are identical, then there is nothing to do */
> @@ -1663,6 +1703,11 @@ static int bcm2835_clock_set_rate(struct clk_hw *hw,
> unlock_exit:
> 	spin_unlock(&cprman->regs_lock);
> 
> +	cprman->func_code = 10;
> +
> +	if (cprman_read(cprman, data->ctl_reg) & CM_BUSY)
> +		pr_warn("%s: clk now busy from %d\n", __func__, cprman->func_code);
> +
> 	return 0;
> }
> 

Seems as if you apply it on top of (parts of) my patchset - not on top of a 
clean 4.5-rc3.

Anyway - after some fixing I get the following outputs -
the amba-pl011 driver is still patched with debug messages:

After boot with aux-uart as tty:
root at raspcm:~# dmesg  | grep bcm2835
[    0.018172] bcm2835: system timer (irq = 27)
[    0.711388] bcm2835-aux-uart 20215040.serial: could not get clk: -517
[    1.649124] bcm2835-rng 20104000.rng: hwrng registered
[    2.051190] bcm2835_clock_on: clk still busy from 6
[    2.056159] bcm2835_clock_on: clk now busy from 9
[    8.062743] bcm2835-wdt 20100000.watchdog: Broadcom BCM2835 watchdog timer
[   12.042105] bcm2835-i2s 20203000.i2s: can't request region for resource [mem 0x20101098-0x20101099]
[   12.191701] bcm2835-i2s: probe of 20203000.i2s failed with error -16

Loading the module:
root at raspcm:~# modprobe amba-pl011
[  106.685812] Serial: AMBA PL011 UART driver
[  106.693702] uart-pl011 20201000.uart: pl011_setup_port: f0201000 20201000
[  106.702109] 20201000.uart: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
root at raspcm:~#

and starting getty:
root at raspcm:~# /sbin/getty -a root -L ttyAMA0 115200 vt100
[  137.851123] pl011_startup - start
[  137.854538] pl011_hwinit - prepare-enable
[  137.858772] bcm2835_clock_on: clk still busy from 6
[  137.863755] bcm2835_clock_on: clk now busy from 9
[  137.868590] pl011_hwinit - prepare-enable - ret = 0
[  137.875249] uart-pl011 20201000.uart: no DMA platform data
[  137.880940] pl011_startup - exit
[  137.888840] pl011_shutdown - start
[  137.892360] pl011_shutdown - disable_unprepare
[  137.896933] bcm2835_clock_off: clk still busy from 9
[  137.902112] pl011_shutdown - exit
[  137.907233] pl011_startup - start
[  137.910713] pl011_hwinit - prepare-enable
[  137.914808] bcm2835_pll_on: PLL still locked from 1
[  138.019876] bcm2835-clk 20101000.cprman: plld: couldn't lock PLL
[  138.026000] pl011_hwinit - prepare-enable - ret = -110
[  138.031266] pl011_startup - error = -110 - disable_unprepare
[  138.037048] ------------[ cut here ]------------
[  138.041777] WARNING: CPU: 0 PID: 2377 at drivers/clk/clk.c:680 clk_core_disable+0x34/0xf0()
[  138.051063] ---[ end trace dd2f225b2af4c32c ]---
[  138.055859] ------------[ cut here ]------------
[  138.060627] WARNING: CPU: 0 PID: 2377 at drivers/clk/clk.c:575 clk_core_unprepare+0x34/0x110()
[  138.070321] ---[ end trace dd2f225b2af4c32d ]---

No HDMI output - this time no ?flashing? - just no signal.
Machine is crashed - the attached AXIS USB network card (0b95:772b)
just transmits identical packets on the network without stopping?

I have also disabled the DMA-engine in the amba-pl011 driver
(in the driver itself add: #undef CONFIG_DMA_ENGINE) and then I get:
root at raspcm:/build/linux# /sbin/getty -a root -L ttyAMA0 115200 vt100
[   97.010287] pl011_startup - start
[   97.013698] pl011_hwinit - prepare-enable
[   97.017931] bcm2835_clock_on: clk still busy from 6
[   97.022905] bcm2835_clock_on: clk now busy from 9
[   97.027755] pl011_hwinit - prepare-enable - ret = 0
[   97.034378] pl011_startup - exit
[   97.041197] pl011_shutdown - start
[   97.044728] pl011_shutdown - disable_unprepare
[   97.049386] bcm2835_clock_off: clk still busy from 9
[   97.054458] pl011_shutdown - exit
[   97.059633] pl011_startup - start
[   97.063033] pl011_hwinit - prepare-enable
[   97.067533] bcm2835_pll_on: PLL still locked from 1
[   97.172655] bcm2835-clk 20101000.cprman: plld: couldn't lock PLL
[   97.178838] pl011_hwinit - prepare-enable - ret = -110
[   97.184075] pl011_startup - error = -110 - disable_unprepare
[   97.189905] ------------[ cut here ]------------
[   97.194640] WARNING: CPU: 0 PID: 2442 at drivers/clk/clk.c:680 clk_core_disab
le+0x34/0xf0()
[   97.203924] ---[ end trace 3e878f70606eba69 ]---
[   97.208692] ------------[ cut here ]------------
[   97.213429] WARNING: CPU: 0 PID: 2442 at drivers/clk/clk.c:575 clk_core_unpre
pare+0x34/0x110()
[   97.223096] ---[ end trace 3e878f70606eba6a ]?

Not sure why the pl011 driver runs the startup/shutdown/startup
loop.

Martin






From sebott at linux.vnet.ibm.com  Sat Feb 13 03:58:31 2016
From: sebott at linux.vnet.ibm.com (Sebastian Ott)
Date: Sat, 13 Feb 2016 12:58:31 +0100 (CET)
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160212231510.GB15142@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name> <56BE00E7.1010303@de.ibm.com>
 <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
Message-ID: <alpine.LFD.2.20.1602131238260.1910@schleppi>


On Sat, 13 Feb 2016, Kirill A. Shutemov wrote:
> Could you check if revert of fecffad25458 helps?

I reverted fecffad25458 on top of 721675fcf277cf - it oopsed with:

? 1851.721062! Unable to handle kernel pointer dereference in virtual kernel address space
? 1851.721075! failing address: 0000000000000000 TEID: 0000000000000483
? 1851.721078! Fault in home space mode while using kernel ASCE.
? 1851.721085! AS:0000000000d5c007 R3:00000000ffff0007 S:00000000ffffa800 P:000000000000003d
? 1851.721128! Oops: 0004 ilc:3 ?#1! PREEMPT SMP DEBUG_PAGEALLOC
? 1851.721135! Modules linked in: bridge stp llc btrfs mlx4_ib mlx4_en ib_sa ib_mad vxlan xor ip6_udp_tunnel ib_core udp_tunnel ptp pps_core ib_addr ghash_s390raid6_pq prng ecb aes_s390 mlx4_core des_s390 des_generic genwqe_card sha512_s390 sha256_s390 sha1_s390 sha_common crc_itu_t dm_mod scm_block vhost_net tun vhost eadm_sch macvtap macvlan kvm autofs4
? 1851.721183! CPU: 7 PID: 256422 Comm: bash Not tainted 4.5.0-rc3-00058-g07923d7-dirty #178
? 1851.721186! task: 000000007fbfd290 ti: 000000008c604000 task.ti: 000000008c604000
? 1851.721189! Krnl PSW : 0704d00180000000 000000000045d3b8 (__rb_erase_color+0x280/0x308)
? 1851.721200!            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
               Krnl GPRS: 0000000000000001 0000000000000020 0000000000000000 00000000bd07eff1
? 1851.721205!            000000000027ca10 0000000000000000 0000000083e45898 0000000077b61198
? 1851.721207!            000000007ce1a490 00000000bd07eff0 000000007ce1a548 000000000027ca10
? 1851.721210!            00000000bd07c350 00000000bd07eff0 000000008c607aa8 000000008c607a68
? 1851.721221! Krnl Code: 000000000045d3aa: e3c0d0080024       stg     %%r12,8(%%r13)
                          000000000045d3b0: b9040039           lgr     %%r3,%%r9
                         #000000000045d3b4: a53b0001           oill    %%r3,1
                         >000000000045d3b8: e33010000024       stg     %%r3,0(%%r1)
                          000000000045d3be: ec28000e007c       cgij    %%r2,0,8,45d3da
                          000000000045d3c4: e34020000004       lg      %%r4,0(%%r2)
                          000000000045d3ca: b904001c           lgr     %%r1,%%r12
                          000000000045d3ce: ec143f3f0056       rosbg   %%r1,%%r4,63,63,0
? 1851.721269! Call Trace:
? 1851.721273! (?<0000000083e45898>! 0x83e45898)
? 1851.721279!  ?<000000000029342a>! unlink_anon_vmas+0x9a/0x1d8
? 1851.721282!  ?<0000000000283f34>! free_pgtables+0xcc/0x148
? 1851.721285!  ?<000000000028c376>! exit_mmap+0xd6/0x300
? 1851.721289!  ?<0000000000134db8>! mmput+0x90/0x118
? 1851.721294!  ?<00000000002d76bc>! flush_old_exec+0x5d4/0x700
? 1851.721298!  ?<00000000003369f4>! load_elf_binary+0x2f4/0x13e8
? 1851.721301!  ?<00000000002d6e4a>! search_binary_handler+0x9a/0x1f8
? 1851.721304!  ?<00000000002d8970>! do_execveat_common.isra.32+0x668/0x9a0
? 1851.721307!  ?<00000000002d8cec>! do_execve+0x44/0x58
? 1851.721310!  ?<00000000002d8f92>! SyS_execve+0x3a/0x48
? 1851.721315!  ?<00000000006fb096>! system_call+0xd6/0x258
? 1851.721317!  ?<000003ff997436d6>! 0x3ff997436d6
? 1851.721319! INFO: lockdep is turned off.
? 1851.721321! Last Breaking-Event-Address:
? 1851.721323!  ?<000000000045d31a>! __rb_erase_color+0x1e2/0x308
? 1851.721327!
? 1851.721329! ---? end trace 0d80041ac00cfae2 !---


> 
> And could you share how crashes looks like? I haven't seen backtraces yet.
> 

Sure. I didn't because they really looked random to me. Most of the time
in rcu or list debugging but I thought these have just been the messenger
observing a corruption first. Anyhow, here is an older one that might look
interesting:

[   59.851421] list_del corruption. next->prev should be 000000006e1eb000, but was 0000000000000400
[   59.851469] ------------[ cut here ]------------
[   59.851472] WARNING: at lib/list_debug.c:71
[   59.851475] Modules linked in: bridge stp llc btrfs xor mlx4_en vxlan ip6_udp_tunnel udp_tunnel mlx4_ib ptp pps_core ib_sa ib_mad ib_core ib_addr ghash_s390 prng raid6_pq ecb aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 mlx4_core sha_common genwqe_card scm_block crc_itu_t vhost_net tun vhost dm_mod macvtap eadm_sch macvlan kvm autofs4
[   59.851532] CPU: 0 PID: 5400 Comm: git Not tainted 4.4.0-07794-ga4eff16-dirty #77
[   59.851535] task: 00000000d2310000 ti: 00000000d6610000 task.ti: 00000000d6610000
[   59.851539] Krnl PSW : 0704c00180000000 0000000000487434 (__list_del_entry+0xa4/0xe0)
[   59.851548]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
               Krnl GPRS: 0000000001a7a1cf 00000000d2310000 0000000000000054 0000000000000001
[   59.851554]            0000000000487430 0000000000000000 0000000000000000 00000000774e6900
[   59.851557]            000003ff53000000 000000006d4017a0 000003ff52f00000 000003ff52f00000
[   59.851560]            000003d101780000 000000006e1eb000 0000000000487430 00000000d6613b00
[   59.851571] Krnl Code: 0000000000487424: c02000219e3a	larl	%%r2,8bb098
                          000000000048742a: c0e5ffee05db	brasl	%%r14,247fe0
                         #0000000000487430: a7f40001		brc	15,487432
                         >0000000000487434: a7f40017		brc	15,487462
                          0000000000487438: a7390200		lghi	%%r3,512
                          000000000048743c: ec13ffd28064	cgrj	%%r1,%%r3,8,4873e0
                          0000000000487442: e32010000020	cg	%%r2,0(%%r1)
                          0000000000487448: a774ffda		brc	7,4873fc
[   59.851615] Call Trace:
[   59.851618] ([<0000000000487430>] __list_del_entry+0xa0/0xe0)
[   59.851621]  [<0000000000487498>] list_del+0x28/0x40
[   59.851627]  [<00000000001259ec>] pgtable_trans_huge_withdraw+0x74/0x90
[   59.851632]  [<00000000002bf234>] __split_huge_pmd_locked+0x3ec/0xa10
[   59.851635]  [<00000000002c4310>] __split_huge_pmd+0x118/0x218
[   59.851639]  [<00000000002810e8>] unmap_single_vma+0x2d8/0xb40
[   59.851643]  [<0000000000282d66>] zap_page_range+0x116/0x318
[   59.851646]  [<000000000029b834>] SyS_madvise+0x23c/0x5e8
[   59.851652]  [<00000000006f9f56>] system_call+0xd6/0x258
[   59.851656]  [<000003ff9bbfd282>] 0x3ff9bbfd282
[   59.851658] 2 locks held by git/5400:
[   59.851660]  #0:  (&mm->mmap_sem){++++++}, at: [<000000000029bb5a>] SyS_madvise+0x562/0x5e8
[   59.851670]  #1:  (&(ptlock_ptr(page))->rlock){+.+...}, at: [<00000000002c4268>] __split_huge_pmd+0x70/0x218
[   59.851679] Last Breaking-Event-Address:
[   59.851682]  [<0000000000487430>] __list_del_entry+0xa0/0xe0
[   59.851686] ---[ end trace 7bce9a4f571985b6 ]---
[   59.875754] list_del corruption. prev->next should be 000000006e1eb820, but was           (null)
[   59.875768] ------------[ cut here ]------------
[   59.875771] WARNING: at lib/list_debug.c:68
[   59.875774] Modules linked in: bridge stp llc btrfs xor mlx4_en vxlan ip6_udp_tunnel udp_tunnel mlx4_ib ptp pps_core ib_sa ib_mad ib_core ib_addr ghash_s390 prng raid6_pq ecb aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 mlx4_core sha_common genwqe_card scm_block crc_itu_t vhost_net tun vhost dm_mod macvtap eadm_sch macvlan kvm autofs4
[   59.875820] CPU: 2 PID: 5402 Comm: git Tainted: G        W       4.4.0-07794-ga4eff16-dirty #77
[   59.875823] task: 00000000d2312948 ti: 00000000cfecc000 task.ti: 00000000cfecc000
[   59.875826] Krnl PSW : 0704c00180000000 0000000000487416 (__list_del_entry+0x86/0xe0)
[   59.875832]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
               Krnl GPRS: 0000000001a7a1cf 00000000d2312948 0000000000000054 0000000000000001
[   59.875838]            0000000000487412 0000000000000000 0000000000000000 00000000774e6900
[   59.875841]            000003ff52000000 000000006d403b10 000003ff51f00000 000003ff51f00000
[   59.875843]            000003d10177c000 000000006e1eb820 0000000000487412 00000000cfecfb00
[   59.875851] Krnl Code: 0000000000487406: c02000219e2c	larl	%%r2,8bb05e
                          000000000048740c: c0e5ffee05ea	brasl	%%r14,247fe0
                         #0000000000487412: a7f40001		brc	15,487414
                         >0000000000487416: a7f40026		brc	15,487462
                          000000000048741a: b9040032		lgr	%%r3,%%r2
                          000000000048741e: e34040080004	lg	%%r4,8(%%r4)
                          0000000000487424: c02000219e3a	larl	%%r2,8bb098
                          000000000048742a: c0e5ffee05db	brasl	%%r14,247fe0
[   59.875874] Call Trace:
[   59.875876] ([<0000000000487412>] __list_del_entry+0x82/0xe0)
[   59.875879]  [<0000000000487498>] list_del+0x28/0x40
[   59.875882]  [<00000000001259ec>] pgtable_trans_huge_withdraw+0x74/0x90
[   59.875885]  [<00000000002bf234>] __split_huge_pmd_locked+0x3ec/0xa10
[   59.875888]  [<00000000002c4310>] __split_huge_pmd+0x118/0x218
[   59.875891]  [<00000000002810e8>] unmap_single_vma+0x2d8/0xb40
[   59.875894]  [<0000000000282d66>] zap_page_range+0x116/0x318
[   59.875896]  [<000000000029b834>] SyS_madvise+0x23c/0x5e8
[   59.875899]  [<00000000006f9f56>] system_call+0xd6/0x258
[   59.875902]  [<000003ff9bbfd282>] 0x3ff9bbfd282
[   59.875904] 2 locks held by git/5402:
[   59.875906]  #0:  (&mm->mmap_sem){++++++}, at: [<000000000029bb5a>] SyS_madvise+0x562/0x5e8
[   59.875914]  #1:  (&(ptlock_ptr(page))->rlock){+.+...}, at: [<00000000002c4268>] __split_huge_pmd+0x70/0x218
[   59.875922] Last Breaking-Event-Address:
[   59.875925]  [<0000000000487412>] __list_del_entry+0x82/0xe0
[   59.875927] ---[ end trace 7bce9a4f571985b7 ]---
[   59.875935] ------------[ cut here ]------------
[   59.875937] kernel BUG at mm/huge_memory.c:2884!
[   59.875979] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[   59.875986] Modules linked in: bridge stp llc btrfs xor mlx4_en vxlan ip6_udp_tunnel udp_tunnel mlx4_ib ptp pps_core ib_sa ib_mad ib_core ib_addr ghash_s390 prng raid6_pq ecb aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 mlx4_core sha_common genwqe_card scm_block crc_itu_t vhost_net tun vhost dm_mod macvtap eadm_sch macvlan kvm autofs4
[   59.876033] CPU: 2 PID: 5402 Comm: git Tainted: G        W       4.4.0-07794-ga4eff16-dirty #77
[   59.876036] task: 00000000d2312948 ti: 00000000cfecc000 task.ti: 00000000cfecc000
[   59.876039] Krnl PSW : 0704d00180000000 00000000002bf3aa (__split_huge_pmd_locked+0x562/0xa10)
[   59.876045]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
               Krnl GPRS: 0000000001a7a1cf 000003d10177c000 0000000000044068 000000005df00215
[   59.876051]            0000000000000001 0000000000000001 0000000000000000 00000000774e6900
[   59.876054]            000003ff52000000 000000006d403b10 000000006e1eb800 000003ff51f00000
[   59.876058]            000003d10177c000 0000000000715190 00000000002bf234 00000000cfecfb58
[   59.876068] Krnl Code: 00000000002bf39c: d507d010a000	clc	16(8,%%r13),0(%%r10)
                          00000000002bf3a2: a7840004		brc	8,2bf3aa
                         #00000000002bf3a6: a7f40001		brc	15,2bf3a8
                         >00000000002bf3aa: 91407440		tm	1088(%%r7),64
                          00000000002bf3ae: a7840208		brc	8,2bf7be
                          00000000002bf3b2: a7f401e9		brc	15,2bf784
                          00000000002bf3b6: 9104a006		tm	6(%%r10),4
                          00000000002bf3ba: a7740004		brc	7,2bf3c2
[   59.876089] Call Trace:
[   59.876092] ([<00000000002bf234>] __split_huge_pmd_locked+0x3ec/0xa10)
[   59.876095]  [<00000000002c4310>] __split_huge_pmd+0x118/0x218
[   59.876099]  [<00000000002810e8>] unmap_single_vma+0x2d8/0xb40
[   59.876102]  [<0000000000282d66>] zap_page_range+0x116/0x318
[   59.876105]  [<000000000029b834>] SyS_madvise+0x23c/0x5e8
[   59.876108]  [<00000000006f9f56>] system_call+0xd6/0x258
[   59.876111]  [<000003ff9bbfd282>] 0x3ff9bbfd282
[   59.876113] INFO: lockdep is turned off.
[   59.876115] Last Breaking-Event-Address:
[   59.876118]  [<00000000002bf3a6>] __split_huge_pmd_locked+0x55e/0xa10
[   59.876122]  
[   59.876124] ---[ end trace 7bce9a4f571985b8 ]---
[   59.876128] BUG: sleeping function called from invalid context at include/linux/sched.h:2791
[   59.876130] in_atomic(): 1, irqs_disabled(): 0, pid: 5402, name: git
[   59.876132] INFO: lockdep is turned off.
[   59.876134] Preemption disabled at:[<00000000002c4268>] __split_huge_pmd+0x70/0x218
[   59.876138] 
[   59.876141] CPU: 2 PID: 5402 Comm: git Tainted: G      D W       4.4.0-07794-ga4eff16-dirty #77
[   59.876144]        00000000cfecf610 00000000cfecf6a0 0000000000000002 0000000000000000 
                      00000000cfecf740 00000000cfecf6b8 00000000cfecf6b8 0000000000113402 
                      0000000000000000 000000000089ab4e 00000000008b0a84 0704d0010000000b 
                      00000000cfecf700 00000000cfecf6a0 0000000000000000 0000000000000000 
                      0000000000000000 0000000000113402 00000000cfecf6a0 00000000cfecf700 
[   59.876176] Call Trace:
[   59.876182] ([<000000000011330e>] show_trace+0x126/0x148)
[   59.876185]  [<00000000001133b8>] show_stack+0x88/0xe8
[   59.876189]  [<000000000045549a>] dump_stack+0x7a/0xd8
[   59.876193]  [<00000000001666c6>] ___might_sleep+0x236/0x248
[   59.876198]  [<000000000014a314>] exit_signals+0x3c/0x158
[   59.876202]  [<000000000013a4e0>] do_exit+0x140/0xd18
[   59.876206]  [<00000000001137c4>] die+0x164/0x170
[   59.876209]  [<0000000000100ac6>] do_report_trap+0x14e/0x160
[   59.876211]  [<0000000000100c94>] illegal_op+0x134/0x148
[   59.876214]  [<00000000006fa26c>] pgm_check_handler+0x15c/0x1b4
[   59.876217]  [<00000000002bf3aa>] __split_huge_pmd_locked+0x562/0xa10
[   59.876221] ([<00000000002bf234>] __split_huge_pmd_locked+0x3ec/0xa10)
[   59.876223]  [<00000000002c4310>] __split_huge_pmd+0x118/0x218
[   59.876226]  [<00000000002810e8>] unmap_single_vma+0x2d8/0xb40
[   59.876229]  [<0000000000282d66>] zap_page_range+0x116/0x318
[   59.876232]  [<000000000029b834>] SyS_madvise+0x23c/0x5e8
[   59.876235]  [<00000000006f9f56>] system_call+0xd6/0x258
[   59.876238]  [<000003ff9bbfd282>] 0x3ff9bbfd282
[   59.876240] INFO: lockdep is turned off.
[   59.876243] note: git[5402] exited with preempt_count 1

From manabian at gmail.com  Sat Feb 13 05:06:19 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Sat, 13 Feb 2016 14:06:19 +0100
Subject: [PATCH v2 1/3] clocksource/drivers/lpc32xx: Don't use the
 prescaler counter for clockevents
In-Reply-To: <1455069267-4784-2-git-send-email-ezequiel@vanguardiasur.com.ar>
References: <1455069267-4784-1-git-send-email-ezequiel@vanguardiasur.com.ar>
 <1455069267-4784-2-git-send-email-ezequiel@vanguardiasur.com.ar>
Message-ID: <CAGhQ9VwuUK5Fx12L6oi1DCC_zx1BA-6vPTwG0HpfkinEoUpOig@mail.gmail.com>

Hi Ezequiel,

On 10 February 2016 at 02:54, Ezequiel Garcia
<ezequiel at vanguardiasur.com.ar> wrote:
> This commit switches the clockevents one-shot current implementation
> to avoid using the prescaler counter. The clockevents timer currently
> uses MR0=1, PR=ticks; and after this commit is uses MR0=ticks, PR=0.
>
> While using the prescaler with PR=1 works fine in one-shot mode,
> it seems it doesn't work as expected in periodic mode.
>
> By using the only match channel register (MR0) for the timer we make
> the periodic mode introduction easier, and consistent with one-shot mode.
>
> Signed-off-by: Ezequiel Garcia <ezequiel at vanguardiasur.com.ar>
> ---
>  drivers/clocksource/time-lpc32xx.c | 17 ++++++++---------
>  1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/clocksource/time-lpc32xx.c b/drivers/clocksource/time-lpc32xx.c
> index 1316876b487a..50d1a63cbe1e 100644
> --- a/drivers/clocksource/time-lpc32xx.c
> +++ b/drivers/clocksource/time-lpc32xx.c
> @@ -60,14 +60,13 @@ static int lpc32xx_clkevt_next_event(unsigned long delta,
>                 container_of(evtdev, struct lpc32xx_clock_event_ddata, evtdev);
>
>         /*
> -        * Place timer in reset and program the delta in the prescale
> -        * register (PR). When the prescale counter matches the value
> -        * in PR the counter register is incremented and the compare
> -        * match will trigger. After setup the timer is released from
> -        * reset and enabled.
> +        * Place timer in reset and program the delta in the match
> +        * channel 0 (MR0). When the timer counter matches the value
> +        * in MR0 register the match will trigger an interrupt.
> +        * After setup the timer is released from reset and enabled.
>          */
>         writel_relaxed(LPC32XX_TIMER_TCR_CRST, ddata->base + LPC32XX_TIMER_TCR);
> -       writel_relaxed(delta, ddata->base + LPC32XX_TIMER_PR);
> +       writel_relaxed(delta, ddata->base + LPC32XX_TIMER_MR0);
>         writel_relaxed(LPC32XX_TIMER_TCR_CEN, ddata->base + LPC32XX_TIMER_TCR);
>
>         return 0;
> @@ -210,13 +209,13 @@ static int __init lpc32xx_clockevent_init(struct device_node *np)
>
>         /*
>          * Disable timer and clear any pending interrupt (IR) on match
> -        * channel 0 (MR0). Configure a compare match value of 1 on MR0
> -        * and enable interrupt, reset on match and stop on match (MCR).
> +        * channel 0 (MR0). Clear the prescaler as it's not used.
> +        * Enable interrupt, reset on match and stop on match (MCR).
>          */
>         writel_relaxed(0, base + LPC32XX_TIMER_TCR);
> +       writel_relaxed(0, base + LPC32XX_TIMER_PR);
>         writel_relaxed(0, base + LPC32XX_TIMER_CTCR);
>         writel_relaxed(LPC32XX_TIMER_IR_MR0INT, base + LPC32XX_TIMER_IR);
> -       writel_relaxed(1, base + LPC32XX_TIMER_MR0);
>         writel_relaxed(LPC32XX_TIMER_MCR_MR0I | LPC32XX_TIMER_MCR_MR0R |
>                        LPC32XX_TIMER_MCR_MR0S, base + LPC32XX_TIMER_MCR);
>
> --

There were fewer changes need to switch to MR0 than I thought. Good.

Reviewed-by: Joachim Eastwood <manabian at gmail.com>
Tested-by: Joachim Eastwood <manabian at gmail.com>

Boot tested on EA4357.


regards,
Joachim Eastwood


From manabian at gmail.com  Sat Feb 13 05:08:44 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Sat, 13 Feb 2016 14:08:44 +0100
Subject: [PATCH v2 2/3] clocksource/drivers/lpc32xx: Support periodic mode
In-Reply-To: <1455069267-4784-3-git-send-email-ezequiel@vanguardiasur.com.ar>
References: <1455069267-4784-1-git-send-email-ezequiel@vanguardiasur.com.ar>
 <1455069267-4784-3-git-send-email-ezequiel@vanguardiasur.com.ar>
Message-ID: <CAGhQ9VwSazkF_crdpouE3heYOHyV4gFxh_cFM9N3Pg1iQ+-8Dw@mail.gmail.com>

Hi Ezequiel,

On 10 February 2016 at 02:54, Ezequiel Garcia
<ezequiel at vanguardiasur.com.ar> wrote:
> This commit adds the support for periodic mode. This is done by not
> setting the MR0S (Stop on TnMR0) bit on MCR, thus allowing
> interrupts to be periodically generated on MR0 matches.
>
> In order to do this, move the initial configuration that is specific to
> the one-shot mode to set_state_oneshot().
>
> Signed-off-by: Ezequiel Garcia <ezequiel at vanguardiasur.com.ar>
> ---
>  drivers/clocksource/time-lpc32xx.c | 39 +++++++++++++++++++++++++++++++++-----
>  1 file changed, 34 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clocksource/time-lpc32xx.c b/drivers/clocksource/time-lpc32xx.c
> index 50d1a63cbe1e..5694eddade15 100644
> --- a/drivers/clocksource/time-lpc32xx.c
> +++ b/drivers/clocksource/time-lpc32xx.c
> @@ -43,6 +43,7 @@
>  struct lpc32xx_clock_event_ddata {
>         struct clock_event_device evtdev;
>         void __iomem *base;
> +       u32 ticks_per_jiffy;
>  };
>
>  /* Needed for the sched clock */
> @@ -85,11 +86,39 @@ static int lpc32xx_clkevt_shutdown(struct clock_event_device *evtdev)
>
>  static int lpc32xx_clkevt_oneshot(struct clock_event_device *evtdev)
>  {
> +       struct lpc32xx_clock_event_ddata *ddata =
> +               container_of(evtdev, struct lpc32xx_clock_event_ddata, evtdev);
> +
>         /*
>          * When using oneshot, we must also disable the timer
>          * to wait for the first call to set_next_event().
>          */
> -       return lpc32xx_clkevt_shutdown(evtdev);
> +       writel_relaxed(0, ddata->base + LPC32XX_TIMER_TCR);
> +
> +       /* Enable interrupt, reset on match and stop on match (MCR). */
> +       writel_relaxed(LPC32XX_TIMER_MCR_MR0I | LPC32XX_TIMER_MCR_MR0R |
> +                      LPC32XX_TIMER_MCR_MR0S, ddata->base + LPC32XX_TIMER_MCR);
> +       return 0;
> +}
> +
> +static int lpc32xx_clkevt_periodic(struct clock_event_device *evtdev)
> +{
> +       struct lpc32xx_clock_event_ddata *ddata =
> +               container_of(evtdev, struct lpc32xx_clock_event_ddata, evtdev);
> +
> +       /* Enable interrupt and reset on match. */
> +       writel_relaxed(LPC32XX_TIMER_MCR_MR0I | LPC32XX_TIMER_MCR_MR0R,
> +                      ddata->base + LPC32XX_TIMER_MCR);
> +
> +       /*
> +        * Place timer in reset and program the delta in the match
> +        * channel 0 (MR0).
> +        */
> +       writel_relaxed(LPC32XX_TIMER_TCR_CRST, ddata->base + LPC32XX_TIMER_TCR);
> +       writel_relaxed(ddata->ticks_per_jiffy, ddata->base + LPC32XX_TIMER_MR0);
> +       writel_relaxed(LPC32XX_TIMER_TCR_CEN, ddata->base + LPC32XX_TIMER_TCR);
> +
> +       return 0;
>  }
>
>  static irqreturn_t lpc32xx_clock_event_handler(int irq, void *dev_id)
> @@ -107,11 +136,13 @@ static irqreturn_t lpc32xx_clock_event_handler(int irq, void *dev_id)
>  static struct lpc32xx_clock_event_ddata lpc32xx_clk_event_ddata = {
>         .evtdev = {
>                 .name                   = "lpc3220 clockevent",
> -               .features               = CLOCK_EVT_FEAT_ONESHOT,
> +               .features               = CLOCK_EVT_FEAT_ONESHOT |
> +                                         CLOCK_EVT_FEAT_PERIODIC,
>                 .rating                 = 300,
>                 .set_next_event         = lpc32xx_clkevt_next_event,
>                 .set_state_shutdown     = lpc32xx_clkevt_shutdown,
>                 .set_state_oneshot      = lpc32xx_clkevt_oneshot,
> +               .set_state_periodic     = lpc32xx_clkevt_periodic,
>         },
>  };
>
> @@ -210,17 +241,15 @@ static int __init lpc32xx_clockevent_init(struct device_node *np)
>         /*
>          * Disable timer and clear any pending interrupt (IR) on match
>          * channel 0 (MR0). Clear the prescaler as it's not used.
> -        * Enable interrupt, reset on match and stop on match (MCR).
>          */
>         writel_relaxed(0, base + LPC32XX_TIMER_TCR);
>         writel_relaxed(0, base + LPC32XX_TIMER_PR);
>         writel_relaxed(0, base + LPC32XX_TIMER_CTCR);
>         writel_relaxed(LPC32XX_TIMER_IR_MR0INT, base + LPC32XX_TIMER_IR);
> -       writel_relaxed(LPC32XX_TIMER_MCR_MR0I | LPC32XX_TIMER_MCR_MR0R |
> -                      LPC32XX_TIMER_MCR_MR0S, base + LPC32XX_TIMER_MCR);
>
>         rate = clk_get_rate(clk);
>         lpc32xx_clk_event_ddata.base = base;
> +       lpc32xx_clk_event_ddata.ticks_per_jiffy = DIV_ROUND_CLOSEST(rate, HZ);
>         clockevents_config_and_register(&lpc32xx_clk_event_ddata.evtdev,
>                                         rate, 1, -1);


Reviewed-by: Joachim Eastwood <manabian at gmail.com>
Tested-by: Joachim Eastwood <manabian at gmail.com>

Boot tested on EA4357.

regards,
Joachim Eastwood


From manabian at gmail.com  Sat Feb 13 05:10:08 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Sat, 13 Feb 2016 14:10:08 +0100
Subject: [PATCH v2 3/3] clocksource/drivers/lpc32xx: Support timer-based
 ARM delay
In-Reply-To: <1455069267-4784-4-git-send-email-ezequiel@vanguardiasur.com.ar>
References: <1455069267-4784-1-git-send-email-ezequiel@vanguardiasur.com.ar>
 <1455069267-4784-4-git-send-email-ezequiel@vanguardiasur.com.ar>
Message-ID: <CAGhQ9Vx9AMJfdbNL_kuLTivm52bGZeRrvoYE0fKRA52G4Epv0Q@mail.gmail.com>

On 10 February 2016 at 02:54, Ezequiel Garcia
<ezequiel at vanguardiasur.com.ar> wrote:
> This commit implements the ARM timer-based delay timer for the
> LPC32xx, LPC18xx, LPC43xx family of SoCs.
>
> Also, add a dependency to restrict compiling this driver for
> the ARM architecture.
>
> Signed-off-by: Ezequiel Garcia <ezequiel at vanguardiasur.com.ar>
> ---
>  drivers/clocksource/Kconfig        |  1 +
>  drivers/clocksource/time-lpc32xx.c | 12 ++++++++++++
>  2 files changed, 13 insertions(+)
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 33db7406c0e2..c346be650892 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -160,6 +160,7 @@ config CLKSRC_EFM32
>  config CLKSRC_LPC32XX
>         bool "Clocksource for LPC32XX" if COMPILE_TEST
>         depends on GENERIC_CLOCKEVENTS && HAS_IOMEM
> +       depends on ARM
>         select CLKSRC_MMIO
>         select CLKSRC_OF
>         help
> diff --git a/drivers/clocksource/time-lpc32xx.c b/drivers/clocksource/time-lpc32xx.c
> index 5694eddade15..daae61e8c820 100644
> --- a/drivers/clocksource/time-lpc32xx.c
> +++ b/drivers/clocksource/time-lpc32xx.c
> @@ -18,6 +18,7 @@
>  #include <linux/clk.h>
>  #include <linux/clockchips.h>
>  #include <linux/clocksource.h>
> +#include <linux/delay.h>
>  #include <linux/interrupt.h>
>  #include <linux/irq.h>
>  #include <linux/kernel.h>
> @@ -54,6 +55,15 @@ static u64 notrace lpc32xx_read_sched_clock(void)
>         return readl(clocksource_timer_counter);
>  }
>
> +static unsigned long lpc32xx_delay_timer_read(void)
> +{
> +       return readl(clocksource_timer_counter);
> +}
> +
> +static struct delay_timer lpc32xx_delay_timer = {
> +       .read_current_timer = lpc32xx_delay_timer_read,
> +};
> +
>  static int lpc32xx_clkevt_next_event(unsigned long delta,
>                                      struct clock_event_device *evtdev)
>  {
> @@ -192,6 +202,8 @@ static int __init lpc32xx_clocksource_init(struct device_node *np)
>         }
>
>         clocksource_timer_counter = base + LPC32XX_TIMER_TC;
> +       lpc32xx_delay_timer.freq = rate;
> +       register_current_timer_delay(&lpc32xx_delay_timer);
>         sched_clock_register(lpc32xx_read_sched_clock, 32, rate);
>
>         return 0;

Reviewed-by: Joachim Eastwood <manabian at gmail.com>
Tested-by: Joachim Eastwood <manabian at gmail.com>

Boot tested on EA4357.

regards,
Joachim Eastwood


From linus.walleij at linaro.org  Sat Feb 13 05:19:40 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 13 Feb 2016 14:19:40 +0100
Subject: [PATCH 2/6] mtd: physmap_of: add a hook for Versatile write
 protection
In-Reply-To: <1453806725-4880-3-git-send-email-linus.walleij@linaro.org>
References: <1453806725-4880-1-git-send-email-linus.walleij@linaro.org>
 <1453806725-4880-3-git-send-email-linus.walleij@linaro.org>
Message-ID: <CACRpkdY4fNfQWaKAZcak0yzJ2B17hbrqdU=Q4=NiwiWRNv_0yQ@mail.gmail.com>

Hey MTD folks,

On Tue, Jan 26, 2016 at 12:12 PM, Linus Walleij
<linus.walleij at linaro.org> wrote:

> In order to support device tree probing of Versatile NOR flash
> chips, there must be a way to add the VPP (write protection)
> enable/disable callback. The register in question is in the
> system controllers of these machines. Apart from this quirk,
> the ARM flash chips are standard CFI flash chips from various
> vendors.
>
> Additionally, the Integrator/AP require you to set up the external
> bus interface (EBI) to allow writes to the chip select where the
> flash memory is connected.
>
> Solve this by looking for the arm,versatile-flash compatible
> string in the flash device tree node. In the driver,
> add a special hook to check for the various Versatile syscons and
> register a callback for .set_vpp() if this compatible is present.
>
> Provide a special Kconfig entry for the addon hook so it will
> not be compiled in if the Versatile boards are not supported.
> Stubs in the header file make sure the impact will be zero on
> other platforms. (Compilers optimze this out.)
>
> With this patch, a large slew of ARM board file code can be
> removed.
>
> Cc: Grant Likely <grant.likely at linaro.org>
> Cc: Rob Herring <robh at kernel.org>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

Do you think my reply to this about reference counting and
subsequent (accepted) patch to update the documentation
to reflect 876fe76d793d03077
"mtd: maps: physmap: Add reference counter to set_vpp()"
is enough to warrant merging of this?

If you want the code developed in any special direction
just tell me.

Yours,
Linus Walleij


From jic23 at kernel.org  Sat Feb 13 05:29:39 2016
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sat, 13 Feb 2016 13:29:39 +0000
Subject: [PATCH v1 2/2] iio: dac: vf610_dac: Add IIO DAC driver for Vybrid
 SoC
In-Reply-To: <20160212063403.GA3056@Sanchayan-Arch.toradex.int>
References: <cover.1454939346.git.maitysanchayan@gmail.com>
 <5a699d45c89d239f3e49fa83d16a9b467016e219.1454939346.git.maitysanchayan@gmail.com>
 <alpine.DEB.2.02.1602090729130.22963@pmeerw.net>
 <20160212063403.GA3056@Sanchayan-Arch.toradex.int>
Message-ID: <56BF2FC3.3070502@kernel.org>

On 12/02/16 06:34, maitysanchayan at gmail.com wrote:
> Hello Peter,
> 
> On 16-02-09 07:43:14, Peter Meerwald-Stadler wrote:
>> On Tue, 9 Feb 2016, Sanchayan Maity wrote:
>>
>>> Add driver support for DAC peripheral on Vybrid SoC.
>>
>> comments below
>>  
>>> Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
>>> ---
>>>  .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
>>>  drivers/iio/dac/Kconfig                            |   8 +
>>>  drivers/iio/dac/Makefile                           |   1 +
>>>  drivers/iio/dac/vf610_dac.c                        | 302 +++++++++++++++++++++
>>>  4 files changed, 331 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>>>  create mode 100644 drivers/iio/dac/vf610_dac.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>>> new file mode 100644
>>> index 0000000..97d7a40
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>>> @@ -0,0 +1,20 @@
>>> +Freescale vf610 Digital to Analog Converter bindings
>>> +
>>> +The devicetree bindings are for the new DAC driver written for
>>> +vf610 SoCs from Freescale.
>>> +
>>> +Required properties:
>>> +- compatible: Should contain "fsl,vf610-dac"
>>> +- reg: Offset and length of the register set for the device
>>> +- interrupts: Should contain the interrupt for the device
>>> +- clocks: The clock is needed by the DAC controller
>>> +- clock-names: Must contain "dac", matching entry in the clocks property.
>>
>> the last sentence is not quite clear; is the comma needed?
>>
>>> +
>>> +Example:
>>> +dac0: dac at 400cc000 {
>>> +	compatible = "fsl,vf610-dac";
>>> +	reg = <0x400cc000 0x1000>;
>>> +	interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
>>> +	clock-names = "dac";
>>> +	clocks = <&clks VF610_CLK_DAC0>;
>>> +};
>>> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
>>> index e701e28..8eb0502 100644
>>> --- a/drivers/iio/dac/Kconfig
>>> +++ b/drivers/iio/dac/Kconfig
>>> @@ -196,4 +196,12 @@ config MCP4922
>>>  	  To compile this driver as a module, choose M here: the module
>>>  	  will be called mcp4922.
>>>  
>>> +config VF610_DAC
>>> +	tristate "Vybrid vf610 DAC driver"
>>> +	help
>>> +	  Say yes here to support Vybrid board digital-to-analog converter.
>>> +
>>> +	  This driver can also be built as a module. If so, the module will
>>> +	  be called vf610_dac.
>>> +
>>>  endmenu
>>> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
>>> index 63ae056..93feb27 100644
>>> --- a/drivers/iio/dac/Makefile
>>> +++ b/drivers/iio/dac/Makefile
>>> @@ -21,3 +21,4 @@ obj-$(CONFIG_MAX517) += max517.o
>>>  obj-$(CONFIG_MAX5821) += max5821.o
>>>  obj-$(CONFIG_MCP4725) += mcp4725.o
>>>  obj-$(CONFIG_MCP4922) += mcp4922.o
>>> +obj-$(CONFIG_VF610_DAC) += vf610_dac.o
>>> diff --git a/drivers/iio/dac/vf610_dac.c b/drivers/iio/dac/vf610_dac.c
>>> new file mode 100644
>>> index 0000000..775b349
>>> --- /dev/null
>>> +++ b/drivers/iio/dac/vf610_dac.c
>>> @@ -0,0 +1,302 @@
>>> +/*
>>> + * Freescale Vybrid vf610 DAC driver
>>> + *
>>> + * Copyright 2016 Toradex AG
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +
>>> +#include <linux/clk.h>
>>> +#include <linux/err.h>
>>> +#include <linux/interrupt.h>
>>> +#include <linux/io.h>
>>> +#include <linux/kernel.h>
>>> +#include <linux/module.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/regulator/consumer.h>
>>> +#include <linux/slab.h>
>>> +
>>> +#include <linux/iio/iio.h>
>>> +#include <linux/iio/sysfs.h>
>>> +
>>> +#define DRIVER_NAME "vf610-dac"
>>
>> VF610_ prefix
>>
>>> +
>>> +#define VF610_DACx_STATCTRL		0x20
>>> +
>>> +#define VF610_DAC_DACEN			BIT(15)
>>> +#define VF610_DAC_DACRFS		BIT(14)
>>> +#define VF610_DAC_LPEN			BIT(11)
>>> +
>>> +#define VF610_DAC_DAT0(x)		((x) & 0xFFF)
>>> +
>>> +enum conversion_mode_sel {
>>
>> vf610_ prefix
>>
>>> +	VF610_DAC_CONV_HIGH_POWER,
>>> +	VF610_DAC_CONV_LOW_POWER,
>>> +};
>>> +
>>> +struct vf610_dac {
>>> +	struct clk *clk;
>>> +	struct device *dev;
>>> +	enum conversion_mode_sel conv_mode;
>>> +	void __iomem *regs;
>>> +	int irq;
>>> +};
>>> +
>>> +static int vf610_dac_init(struct vf610_dac *info)
>>
>> should be void, or check the return value
>>
>>> +{
>>> +	int val;
>>> +
>>> +	info->conv_mode = VF610_DAC_CONV_LOW_POWER;
>>> +	val = VF610_DAC_DACEN | VF610_DAC_DACRFS |
>>> +		VF610_DAC_LPEN;
>>> +	writel(val, info->regs + VF610_DACx_STATCTRL);
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static int vf610_set_conversion_mode(struct iio_dev *indio_dev,
>>> +				const struct iio_chan_spec *chan,
>>> +				unsigned int mode)
>>
>> mode should be enum conversion_mode_sel?
>>
>>> +{
>>> +	struct vf610_dac *info = iio_priv(indio_dev);
>>> +	int val;
>>> +
>>> +	mutex_lock(&indio_dev->mlock);
>>> +	info->conv_mode = mode;
>>> +	val = readl(info->regs + VF610_DACx_STATCTRL);
>>> +	if (mode)
>>> +		val |= VF610_DAC_LPEN;
>>> +	else
>>> +		val &= ~VF610_DAC_LPEN;
>>> +	writel(val, info->regs + VF610_DACx_STATCTRL);
>>> +	mutex_unlock(&indio_dev->mlock);
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static int vf610_get_conversion_mode(struct iio_dev *indio_dev,
>>
>> return of type enum conversion_mode_sel?
> 
> 
> Regarding the enum. As per the function prototype in iio.h
> 
> struct iio_enum {
>         const char * const *items;
>         unsigned int num_items;
>         int (*set)(struct iio_dev *, const struct iio_chan_spec *, unsigned int);
>         int (*get)(struct iio_dev *, const struct iio_chan_spec *);
> };
> 
> the "mode" argument is unsigned int and return type of getter is int as well.
> 
>>
>>> +				const struct iio_chan_spec *chan)
>>> +{
>>> +	struct vf610_dac *info = iio_priv(indio_dev);
>>> +
>>> +	return info->conv_mode;
>>> +}
>>> +
>>> +static const char * const vf610_conv_modes[] = { "high-power", "low-power"};
>>
>> this should be documented in sysfs-bus-iio-vf610; maybe high-power should 
>> be high-speed
>>
>> probably this interface should have been exposed as a settable 
>> conversion rate
> 
> Vybrid DAC block does not provide for setting a conversion rate. There is only one
> register for configration and only one LPEN bit concerning power mode. As per the
> operating behavior, this controls characteristics of supply current, settling time
> and slew rate.
It strikes me that perhaps for DACs it would not be overkill to actually
expose the settling time and slew rate via sysfs?
I'd be happy enough seeing these as new info_mask elements as they
are fairly common.  Are these the best ways to describe DAC performance
characteristics? Sounds right to me but my electronics background is
limited!

> 
> While I agree this should be documented in ABI sysfs documentation, I am not clear
> as to how that should be. Currently that document specifies the modes observed for
> the vf610 ADC driver. As per the datasheet, "high-power" and "low-power" would be
> the most clear description in case of DAC but "normal", "high-speed" and "low-power"
> are applicable for ADC. This just stuck me just now while making the change.
Certainly not obvious.  Could use the slewrate or settling time as explicit
controls on this (support both perhaps, with the usual IIO interface rule
that you should never assume changing one sysfs attribute won't also change
another!)

This would then correspond to some degree with the analogy of setting
effectively power modes for ADCs via sampling frequency as the dominant
attribute that effects their power usage.

Jonathan
> 
> How should I best include this? Peter, Jonathan, Stefan suggestions?
> 
> I have changed the code to include all other feedback. Thank you for feedback.
> 
> Best Regards,
> Sanchayan.
> 
>>
>>> +
>>> +static const struct iio_enum vf610_conversion_mode = {
>>> +	.items = vf610_conv_modes,
>>> +	.num_items = ARRAY_SIZE(vf610_conv_modes),
>>> +	.get = vf610_get_conversion_mode,
>>> +	.set = vf610_set_conversion_mode,
>>> +};
>>> +
>>> +static const struct iio_chan_spec_ext_info vf610_ext_info[] = {
>>> +	IIO_ENUM("conversion_mode", IIO_SHARED_BY_DIR,
>>> +		&vf610_conversion_mode),
>>> +	{},
>>> +};
>>> +
>>> +#define VF610_DAC_CHAN(_chan_type) { \
>>> +	.type = (_chan_type), \
>>> +	.indexed = -1, \
>>
>> indexed should be 0 (or not specified) if no indexing is to be used
>>
>>> +	.output = 1, \
>>> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
>>> +	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
>>> +	.ext_info = vf610_ext_info, \
>>> +}
>>> +
>>> +static const struct iio_chan_spec vf610_dac_iio_channels[] = {
>>> +	VF610_DAC_CHAN(IIO_VOLTAGE),
>>> +};
>>> +
>>> +static int vf610_read_raw(struct iio_dev *indio_dev,
>>> +			struct iio_chan_spec const *chan,
>>> +			int *val, int *val2,
>>> +			long mask)
>>> +{
>>> +	struct vf610_dac *info = iio_priv(indio_dev);
>>> +
>>> +	switch (mask) {
>>> +	case IIO_CHAN_INFO_RAW:
>>> +		*val = VF610_DAC_DAT0(readl(info->regs));
>>> +		return IIO_VAL_INT;
>>> +	case IIO_CHAN_INFO_SCALE:
>>> +		/*
>>> +		 * DACRFS is always 1 for valid reference and typical
>>> +		 * reference voltage as per Vybrid datasheet is 3.3V
>>> +		 * from section 9.1.2.1 of Vybrid datasheet
>>> +		 */
>>> +		*val = 3300 /* mV */;
>>> +		*val2 = 12;
>>> +		return IIO_VAL_FRACTIONAL_LOG2;
>>> +
>>> +	default:
>>> +		break;
>>
>> just return -EINVAL here?
>> and remove it below below
>>
>>> +	}
>>> +
>>> +	return -EINVAL;
>>> +}
>>> +
>>> +static int vf610_write_raw(struct iio_dev *indio_dev,
>>> +			struct iio_chan_spec const *chan,
>>> +			int val, int val2,
>>> +			long mask)
>>> +{
>>> +	struct vf610_dac *info = iio_priv(indio_dev);
>>> +
>>> +	switch (mask) {
>>> +	case IIO_CHAN_INFO_RAW:
>>> +		mutex_lock(&indio_dev->mlock);
>>> +		writel(VF610_DAC_DAT0(val), info->regs);
>>> +		mutex_unlock(&indio_dev->mlock);
>>> +		return 0;
>>> +
>>> +	default:
>>> +		break;
>>
>> return -EINVAL here should save two lines
>>
>>> +	}
>>> +
>>> +	return -EINVAL;
>>> +}
>>> +
>>> +static const struct iio_info vf610_dac_iio_info = {
>>> +	.driver_module = THIS_MODULE,
>>> +	.read_raw = &vf610_read_raw,
>>> +	.write_raw = &vf610_write_raw,
>>> +};
>>> +
>>> +static const struct of_device_id vf610_dac_match[] = {
>>> +	{ .compatible = "fsl,vf610-dac", },
>>> +	{ /* sentinel */ }
>>> +};
>>> +MODULE_DEVICE_TABLE(of, vf610_dac_match);
>>> +
>>> +static int vf610_dac_probe(struct platform_device *pdev)
>>> +{
>>> +	struct iio_dev *indio_dev;
>>> +	struct vf610_dac *info;
>>> +	struct resource *mem;
>>> +	int ret;
>>> +
>>> +	indio_dev = devm_iio_device_alloc(&pdev->dev,
>>> +					sizeof(struct vf610_dac));
>>> +	if (!indio_dev) {
>>> +		dev_err(&pdev->dev, "Failed allocating iio device\n");
>>> +		return -ENOMEM;
>>> +	}
>>> +
>>> +	info = iio_priv(indio_dev);
>>> +	info->dev = &pdev->dev;
>>> +
>>> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> +	info->regs = devm_ioremap_resource(&pdev->dev, mem);
>>> +	if (IS_ERR(info->regs))
>>> +		return PTR_ERR(info->regs);
>>> +
>>> +	info->clk = devm_clk_get(&pdev->dev, "dac");
>>> +	if (IS_ERR(info->clk)) {
>>> +		dev_err(&pdev->dev, "failed getting clock, err = %ld\n",
>>
>> "Failed getting ..."
>>
>>> +			PTR_ERR(info->clk));
>>> +		return PTR_ERR(info->clk);
>>> +	}
>>> +
>>> +	platform_set_drvdata(pdev, indio_dev);
>>> +
>>> +	indio_dev->name = dev_name(&pdev->dev);
>>> +	indio_dev->dev.parent = &pdev->dev;
>>> +	indio_dev->dev.of_node = pdev->dev.of_node;
>>> +	indio_dev->info = &vf610_dac_iio_info;
>>> +	indio_dev->modes = INDIO_DIRECT_MODE;
>>> +	indio_dev->channels = vf610_dac_iio_channels;
>>> +	indio_dev->num_channels = ARRAY_SIZE(vf610_dac_iio_channels);
>>> +
>>> +	ret = clk_prepare_enable(info->clk);
>>> +	if (ret) {
>>> +		dev_err(&pdev->dev,
>>> +			"Could not prepare or enable the clock\n");
>>> +		return ret;
>>> +	}
>>> +
>>> +	ret = iio_device_register(indio_dev);
>>> +	if (ret) {
>>> +		dev_err(&pdev->dev, "Couldn't register the device\n");
>>> +		goto error_iio_device_register;
>>> +	}
>>> +
>>> +	vf610_dac_init(info);
>>
>> there is a race here, move _dac_init() before _register()
>> return value is not checked (or use void)
>>
>>> +
>>> +	return 0;
>>> +
>>> +error_iio_device_register:
>>> +	clk_disable_unprepare(info->clk);
>>> +
>>> +	return ret;
>>> +}
>>> +
>>> +static int vf610_dac_remove(struct platform_device *pdev)
>>> +{
>>> +	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>>> +	struct vf610_dac *info = iio_priv(indio_dev);
>>> +
>>> +	iio_device_unregister(indio_dev);
>>> +	clk_disable_unprepare(info->clk);
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +#ifdef CONFIG_PM_SLEEP
>>> +static int vf610_dac_suspend(struct device *dev)
>>> +{
>>> +	struct iio_dev *indio_dev = dev_get_drvdata(dev);
>>> +	struct vf610_dac *info = iio_priv(indio_dev);
>>> +	int val;
>>> +
>>> +	val = readl(info->regs + VF610_DACx_STATCTRL);
>>> +	val &= ~VF610_DAC_DACEN;
>>> +	writel(val, info->regs + VF610_DACx_STATCTRL);
>>> +
>>> +	clk_disable_unprepare(info->clk);
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static int vf610_dac_resume(struct device *dev)
>>> +{
>>> +	struct iio_dev *indio_dev = dev_get_drvdata(dev);
>>> +	struct vf610_dac *info = iio_priv(indio_dev);
>>> +	int ret;
>>> +
>>> +	ret = clk_prepare_enable(info->clk);
>>> +	if (ret)
>>> +		return ret;
>>> +
>>> +	vf610_dac_init(info);
>>> +
>>> +	return 0;
>>> +}
>>> +#endif
>>> +
>>> +static SIMPLE_DEV_PM_OPS(vf610_dac_pm_ops, vf610_dac_suspend, vf610_dac_resume);
>>> +
>>> +static struct platform_driver vf610_dac_driver = {
>>> +	.probe          = vf610_dac_probe,
>>> +	.remove         = vf610_dac_remove,
>>> +	.driver         = {
>>> +		.name   = DRIVER_NAME,
>>> +		.of_match_table = vf610_dac_match,
>>> +		.pm     = &vf610_dac_pm_ops,
>>> +	},
>>> +};
>>> +module_platform_driver(vf610_dac_driver);
>>> +
>>> +MODULE_AUTHOR("Sanchayan Maity <sanchayan.maity at toradex.com");
>>> +MODULE_DESCRIPTION("Freescale VF610 DAC driver");
>>> +MODULE_LICENSE("GPL v2");
>>>
>>
>> -- 
>>
>> Peter Meerwald-Stadler
>> +43-664-2444418 (mobile)



From jic23 at kernel.org  Sat Feb 13 05:45:59 2016
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sat, 13 Feb 2016 13:45:59 +0000
Subject: [PATCH] iio: adc/imx25-gcq: move incorrect do_div
In-Reply-To: <1455275748-999115-1-git-send-email-arnd@arndb.de>
References: <1455275748-999115-1-git-send-email-arnd@arndb.de>
Message-ID: <56BF3397.1040006@kernel.org>

On 12/02/16 11:15, Arnd Bergmann wrote:
> The newly added driver uses do_div() to device a 32-bit number, which now
> provokes a warning:
> 
> drivers/iio/adc/fsl-imx25-gcq.c: In function 'mx25_gcq_setup_cfgs':
> include/asm-generic/div64.h:207:28: warning: comparison of distinct pointer types lacks a cast
>   (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> 
> This replaces the do_div() call with a straight division operator.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 6df2e98c3ea5 ("iio: adc: Add imx25-gcq ADC driver")
Acked-by: Jonathan Cameron <jic23 at kernel.org>

oops.
> ---
>  drivers/iio/adc/fsl-imx25-gcq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/fsl-imx25-gcq.c b/drivers/iio/adc/fsl-imx25-gcq.c
> index 2fd192735d5b..72b32c1ab257 100644
> --- a/drivers/iio/adc/fsl-imx25-gcq.c
> +++ b/drivers/iio/adc/fsl-imx25-gcq.c
> @@ -233,7 +233,7 @@ static int mx25_gcq_setup_cfgs(struct platform_device *pdev,
>  			priv->channel_vref_mv[reg] =
>  				regulator_get_voltage(priv->vref[refp]);
>  			/* Conversion from uV to mV */
> -			do_div(priv->channel_vref_mv[reg], 1000);
> +			priv->channel_vref_mv[reg] /= 1000;
>  			break;
>  		case MX25_ADC_REFP_INT:
>  			priv->channel_vref_mv[reg] = 2500;
> 



From manabian at gmail.com  Sat Feb 13 05:48:56 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Sat, 13 Feb 2016 14:48:56 +0100
Subject: [PATCH 1/4] net: ethernet: dwmac: add Ethernet glue logic for
 stm32 chip
In-Reply-To: <1454511275-9791-2-git-send-email-alexandre.torgue@gmail.com>
References: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
 <1454511275-9791-2-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <CAGhQ9VypZ5J0pQmrf1Mk-mNsv=XTXu7fhoLt_r2LHJ_Lsyj0yA@mail.gmail.com>

On 3 February 2016 at 15:54, Alexandre TORGUE
<alexandre.torgue at gmail.com> wrote:
> stm324xx family chips support Synopsys MAC 3.510 IP.
> This patch adds settings for logical glue logic:
> -clocks
> -mode selection MII or RMII.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> index cec147d..a94dd15 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> @@ -114,6 +114,18 @@ config DWMAC_SUNXI
>           This selects Allwinner SoC glue layer support for the
>           stmmac device driver. This driver is used for A20/A31
>           GMAC ethernet controller.
> +
> +config DWMAC_STM32
> +       tristate "STM32 DWMAC support"
> +       default ARCH_STM32
> +       depends on OF
> +       select MFD_SYSCON
> +       ---help---
> +         Support for ethernet controller on STM32 SOCs.
> +
> +         This selects STM32 SoC glue layer support for the stmmac
> +         device driver. This driver is used on for the STM32 series
> +         SOCs GMAC ethernet controller.
>  endif
>
>  config STMMAC_PCI
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
> index b390161..9fb2061 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_DWMAC_SOCFPGA)   += dwmac-socfpga.o
>  obj-$(CONFIG_DWMAC_STI)                += dwmac-sti.o
>  obj-$(CONFIG_DWMAC_SUNXI)      += dwmac-sunxi.o
>  obj-$(CONFIG_DWMAC_GENERIC)    += dwmac-generic.o
> +obj-$(CONFIG_DWMAC_STM32)      += dwmac-stm32.o

Keep these sorted. There also a comment in the Makefile that states
that the generic should always be last.


>  stmmac-platform-objs:= stmmac_platform.o
>
>  obj-$(CONFIG_STMMAC_PCI) += stmmac-pci.o
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
> new file mode 100644
> index 0000000..56ccc20
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
> @@ -0,0 +1,177 @@
> +/*
> + * dwmac-stm32.c - DWMAC Specific Glue layer for STM32 MCU
> + *
> + * Copyright (C) Alexandre Torgue 2015
> + * Author:  Alexandre Torgue <alexandre.torgue at gmail.com>
> + * License terms:  GNU General Public License (GPL), version 2
> + *
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <linux/platform_device.h>
> +#include <linux/stmmac.h>
> +#include <linux/phy.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <linux/clk.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_net.h>

Consider sorting the includes.

> +
> +#include "stmmac_platform.h"
> +
> +#define MII_PHY_SEL_MASK       BIT(23)
> +
> +struct stm32_dwmac {
> +       int interface;          /* MII interface */
> +       struct clk *clk_tx;
> +       struct clk *clk_rx;
> +       u32 mode_reg;           /* MAC glue-logic mode register */
> +       struct device *dev;

dev doesn't seem to be used anywhere.

> +       struct regmap *regmap;
> +       u32 speed;
> +};
> +
> +static int stm32_dwmac_init(struct platform_device *pdev, void *priv)
> +{
> +       struct stm32_dwmac *dwmac = priv;
> +       struct regmap *regmap = dwmac->regmap;
> +       int ret, iface = dwmac->interface;
> +       u32 reg = dwmac->mode_reg;
> +       u32 val;
> +
> +       if (dwmac->clk_tx)
> +               ret = clk_prepare_enable(dwmac->clk_tx);

The clk API handles a NULL clk so you don't really need to check for it.


> +               if (ret)
> +                       goto out;
> +
> +       if (dwmac->clk_rx)
> +               ret = clk_prepare_enable(dwmac->clk_rx);

Same here.


> +               if (ret)
> +                       goto out_disable_clk_tx;
> +
> +       val = (iface == PHY_INTERFACE_MODE_MII) ? 0 : 1;
> +       ret = regmap_update_bits(regmap, reg, MII_PHY_SEL_MASK, val);
> +       if (ret)
> +               goto out_disable_clk_tx_rx;
> +
> +       return 0;
> +
> +out_disable_clk_tx_rx:
> +       clk_disable_unprepare(dwmac->clk_rx);
> +out_disable_clk_tx:
> +       clk_disable_unprepare(dwmac->clk_tx);
> +out:
> +       return ret;
> +}
> +
> +static void stm32_dwmac_exit(struct platform_device *pdev, void *priv)
> +{
> +       struct stm32_dwmac *dwmac = priv;
> +
> +       if (dwmac->clk_tx)
> +               clk_disable_unprepare(dwmac->clk_tx);
> +       if (dwmac->clk_rx)
> +               clk_disable_unprepare(dwmac->clk_rx);

Same here.


> +}
> +
> +static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
> +                                 struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct device_node *np = dev->of_node;
> +       struct regmap *regmap;
> +       int err;
> +
> +       if (!np)
> +               return -EINVAL;

Can this ever happen?
This is a DT only driver, right?

> +
> +       /*  Get TX/RX clocks */
> +       dwmac->clk_tx = devm_clk_get(dev, "tx-clk");
> +       if (IS_ERR(dwmac->clk_tx)) {
> +               dev_warn(dev, "No tx clock provided...\n");
> +               dwmac->clk_tx = NULL;
> +       }
> +       dwmac->clk_rx = devm_clk_get(dev, "rx-clk");
> +       if (IS_ERR(dwmac->clk_rx)) {
> +               dev_warn(dev, "No rx clock provided...\n");
> +               dwmac->clk_rx = NULL;
> +       }
> +
> +       /* Get mode register */
> +       regmap = syscon_regmap_lookup_by_phandle(np, "st,syscon");
> +       if (IS_ERR(regmap))
> +               return PTR_ERR(regmap);
> +
> +       err = of_property_read_u32_index(np, "st,syscon", 1, &dwmac->mode_reg);
> +       if (err) {
> +               dev_err(dev, "Can't get sysconfig mode offset (%d)\n", err);
> +               return err;
> +       }
> +
> +       dwmac->dev = dev;
> +       dwmac->interface = of_get_phy_mode(np);
> +       dwmac->regmap = regmap;
> +
> +       return 0;
> +}
> +
> +static int stm32_dwmac_probe(struct platform_device *pdev)
> +{
> +       struct plat_stmmacenet_data *plat_dat;
> +       struct stmmac_resources stmmac_res;
> +       struct stm32_dwmac *dwmac;
> +       int ret;
> +
> +       ret = stmmac_get_platform_resources(pdev, &stmmac_res);
> +       if (ret)
> +               return ret;
> +
> +       plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
> +       if (IS_ERR(plat_dat))
> +               return PTR_ERR(plat_dat);
> +
> +       dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
> +       if (!dwmac)
> +               return -ENOMEM;
> +
> +       ret = stm32_dwmac_parse_data(dwmac, pdev);
> +       if (ret) {
> +               dev_err(&pdev->dev, "Unable to parse OF data\n");
> +               return ret;
> +       }
> +
> +       plat_dat->bsp_priv = dwmac;
> +       plat_dat->init = stm32_dwmac_init;
> +       plat_dat->exit = stm32_dwmac_exit;

Instead of using these callbacks could you rather implement the PM
callbacks directly in this driver?
I don't think it should add much code and it will make it look more
like standard driver. This will also give you some more control and
flexibility in your code.

> +
> +       ret = stm32_dwmac_init(pdev, plat_dat->bsp_priv);
> +       if (ret)
> +               return ret;
> +
> +       return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
> +}
> +
> +static const struct of_device_id stm32_dwmac_match[] = {
> +       { .compatible = "st,stm32-dwmac"},
> +       { }
> +};
> +MODULE_DEVICE_TABLE(of, stm32_dwmac_match);
> +
> +static struct platform_driver stm32_dwmac_driver = {
> +       .probe  = stm32_dwmac_probe,
> +       .remove = stmmac_pltfr_remove,

Could you implement the .remove callback in your driver instead of
using stmmac_pltfr_remove?
Same reasons as above.


> +       .driver = {
> +               .name           = "stm32-dwmac",
> +               .pm             = &stmmac_pltfr_pm_ops,
> +               .of_match_table = stm32_dwmac_match,
> +       },
> +};
> +module_platform_driver(stm32_dwmac_driver);
> +
> +MODULE_AUTHOR("Alexandre Torgue <alexandre.torgue at gmail.com>");
> +MODULE_DESCRIPTION("STMicroelectronics MCU DWMAC Specific Glue layer");
> +MODULE_LICENSE("GPL");

Since you state:
> + * License terms:  GNU General Public License (GPL), version 2

You might want to switch use: MODULE_LICENSE("GPL v2");


regards,
Joachim Eastwood


From ard.biesheuvel at linaro.org  Sat Feb 13 06:28:25 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Sat, 13 Feb 2016 15:28:25 +0100
Subject: [PATCH v5sub1 0/8] arm64: split linear and kernel mappings
In-Reply-To: <56BE3C35.7070608@gmail.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <56BE3645.3030403@gmail.com>
 <CAKv+Gu9Qw=DSe1fZT=Dv=iKaKqzsf5ARK9dzwCWPk_0uRECm1w@mail.gmail.com>
 <56BE3C35.7070608@gmail.com>
Message-ID: <CAKv+Gu_29SjYgg+P3fyGFcaRVxjapVzMs85Y2frd7_f51mPv-A@mail.gmail.com>

On 12 February 2016 at 21:10, Matthias Brugger <matthias.bgg at gmail.com> wrote:
>
>
> On 12/02/16 20:47, Ard Biesheuvel wrote:
>>
>> On 12 February 2016 at 20:45, Matthias Brugger <matthias.bgg at gmail.com>
>> wrote:
>>>
>>> Hi Ard,
>>>
>>>
>>> On 01/02/16 11:54, Ard Biesheuvel wrote:
>>>>
>>>>
>>>> At the request of Catalin, this series has been split off from my series
>>>> 'arm64: implement support for KASLR v4' [1]. This sub-series deals with
>>>> moving the kernel out of the linear mapping into the vmalloc area. This
>>>> is a prerequisite for independent physical and virtual randomization of
>>>> the kernel image. On top of that, considering that these changes allow
>>>> the linear mapping to start at an arbitrary offset above PAGE_OFFSET, it
>>>> should be an improvement in itself due to the fact that we can now
>>>> choose
>>>> PAGE_OFFSET such that RAM can be mapped using large block sizes.
>>>>
>>>> For instance, on my Seattle A0 box, the kernel is loaded 16 MB into the
>>>> lowest GB of RAM, which means __pa(PAGE_OFFSET) is not 1 GB aligned, and
>>>> the entire 16 GB of RAM will be mapping using 2 MB blocks. (Similarly,
>>>> for 64 KB granule kernels, the entire 16 GB of RAM will be mapped using
>>>> pages since __pa(PAGE_OFFSET) is not 512 MB aligned). With these changes
>>>>    __pa(PAGE_OFFSET) will always be chosen such that it is aligned to a
>>>> quantity that allows efficient mapping.
>>>>
>>>> Note that of the entire KASLR series, this sub-series is the most likely
>>>> to
>>>> cause problems, and hence requires the most careful review and testing.
>>>> This
>>>> is due to the fact that, with these changes, the invariant __va(__pa(x))
>>>> == x
>>>> no longer holds, and any code that is based on that assumption needs to
>>>> be
>>>> updated.
>>>>
>>>> Changes since v4:
>>>> - added Marc's ack to patch #6
>>>> - round the kasan zero shadow region around the kernel image to swapper
>>>> block
>>>>     size (#7)
>>>> - ensure that we don't clip the kernel image when clipping RAM to the
>>>> linear
>>>>     region size (#8)
>>>>
>>>> Patch #1 allows the low mark of memblocks discovered from the FDT to be
>>>> overridden by the architecture.
>>>>
>>>> Patch #2 enables the huge-vmap generic feature for arm64. This should be
>>>> an
>>>> improvement in itself, but the significance for this series is that it
>>>> allows
>>>> unmap_kernel_range() to be called on the [__init_begin, __init_end)
>>>> region,
>>>> which may be partially mapped using block mappings.
>>>>
>>>> Patch #3 introduces KIMAGE_VADDR as a separate, preparatory step towards
>>>> decoupling the kernel placement from PAGE_OFFSET
>>>>
>>>> Patch #4 implements some translation table accessors that operate on
>>>> statically
>>>> allocate translation tables before the linear mapping is up.
>>>>
>>>> Patch #5 decouples the fixmap initialization from the linear mapping, by
>>>> using
>>>> the accessors implemented by patch #4
>>>>
>>>> Patch #6 removes assumptions made my KVM regarding the placement of the
>>>> kernel
>>>> image inside the linear mapping.
>>>>
>>>> Patch #7 moves the kernel image from the base of the linear mapping to
>>>> the
>>>> base
>>>> of the vmalloc area. The modules area, which sits right below the kernel
>>>> image,
>>>> is moved along and is put right before the start of the vmalloc area.
>>>>
>>>> Patch #8 decouples PHYS_OFFSET from PAGE_OFFSET, which allows the linear
>>>> mapping
>>>> to cover all discovered memory, regardless of where the kernel image is
>>>> located
>>>> in it. This effectively allows the kernel to be loaded at any physical
>>>> address
>>>> (provided that the correct alignment is used)
>>>>
>>>> [1] http://thread.gmane.org/gmane.linux.kernel/2135931
>>>>
>>>> Ard Biesheuvel (8):
>>>>     of/fdt: make memblock minimum physical address arch configurable
>>>>     arm64: add support for ioremap() block mappings
>>>>     arm64: introduce KIMAGE_VADDR as the virtual base of the kernel
>>>> region
>>>>     arm64: pgtable: implement static [pte|pmd|pud]_offset variants
>>>>     arm64: decouple early fixmap init from linear mapping
>>>>     arm64: kvm: deal with kernel symbols outside of linear mapping
>>>>     arm64: move kernel image to base of vmalloc area
>>>>     arm64: allow kernel Image to be loaded anywhere in physical memory
>>>>
>>>
>>> I bisected linux-next (20160212) with the following error on booting with
>>> an
>>> initramfs:
>>>   Failed to execute /init (error -8)
>>>   request_module: runaway loop modprobe binfmt-464c
>>>   Starting init: /sbin/init exists but couldn't execute it (error -8)
>>>   request_module: runaway loop modprobe binfmt-464c
>>>   Starting init: /bin/sh exists but couldn't execute it (error -8)
>>>   Kernel panic - not syncing: No working init found.  Try passing init=
>>> option to kernel. See Linux Documentation/init..
>>>
>>> I tracked down the error to patch 7 of this series. But I realized that
>>> patch 7 does not compile, but from patch 8 onwards I observe the error.
>>>

As far as this failure is concerned, I managed to reproduce an error
with patch #7 and not #8 applied, involving out of range kvm symbols
at link time. This is reproducible with GCC 4.8 but not GCC 4.9 or
later. Is this what you were seeing as well? Or is there another
problem?


>>> I use defconfig with an initramfs.cpio created with buildroot.
>>> I tested this on my mt8173 eval board, but I suppose this can be
>>> reproduced
>>> easily on other machines as well.
>>>
>>
>> Thanks for the report. Does this help at all?
>>
>> http://thread.gmane.org/gmane.linux.ports.arm.kernel/477645
>>
>
> I applied them on top of linux-next and this fixed the problem.
>
> Thanks,
> Matthias
>
>
>>> Regards,
>>> Matthias
>>>
>>>
>>>>    Documentation/arm64/booting.txt                      |  20 ++-
>>>>    Documentation/features/vm/huge-vmap/arch-support.txt |   2 +-
>>>>    arch/arm/include/asm/kvm_asm.h                       |   2 +
>>>>    arch/arm/kvm/arm.c                                   |   8 +-
>>>>    arch/arm64/Kconfig                                   |   1 +
>>>>    arch/arm64/include/asm/boot.h                        |   6 +
>>>>    arch/arm64/include/asm/kasan.h                       |   2 +-
>>>>    arch/arm64/include/asm/kernel-pgtable.h              |  12 ++
>>>>    arch/arm64/include/asm/kvm_asm.h                     |   2 +
>>>>    arch/arm64/include/asm/kvm_host.h                    |   8 +-
>>>>    arch/arm64/include/asm/memory.h                      |  44 ++++--
>>>>    arch/arm64/include/asm/pgtable.h                     |  23 ++-
>>>>    arch/arm64/kernel/head.S                             |   8 +-
>>>>    arch/arm64/kernel/image.h                            |  13 +-
>>>>    arch/arm64/kernel/vmlinux.lds.S                      |   4 +-
>>>>    arch/arm64/kvm/hyp.S                                 |   6 +-
>>>>    arch/arm64/mm/dump.c                                 |  12 +-
>>>>    arch/arm64/mm/init.c                                 | 123
>>>> ++++++++++++++--
>>>>    arch/arm64/mm/kasan_init.c                           |  31 +++-
>>>>    arch/arm64/mm/mmu.c                                  | 155
>>>> +++++++++++++++-----
>>>>    drivers/of/fdt.c                                     |   5 +-
>>>>    21 files changed, 378 insertions(+), 109 deletions(-)
>>>>
>>>
>


From manabian at gmail.com  Sat Feb 13 06:38:45 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Sat, 13 Feb 2016 15:38:45 +0100
Subject: [PATCH 1/2] clk: add lpc18xx creg clk driver
In-Reply-To: <20150818002604.31346.18322@quantum>
References: <1436651307-24098-1-git-send-email-manabian@gmail.com>
 <1436651307-24098-2-git-send-email-manabian@gmail.com>
 <20150811204127.31346.16729@quantum>
 <CAGhQ9VwZaM_iWTkQYVTuTiyb6gCG2y6s8WFVySCHt7YHE1qbcA@mail.gmail.com>
 <20150818002604.31346.18322@quantum>
Message-ID: <CAGhQ9VzOYbHsFZQxM8823OiWpGB6vLEwX8LfvjC=DnL1iqK_qQ@mail.gmail.com>

Hi Mike,

Seems your reply got lost in my mailbox and I didn't notice it before
Stephen replied on the cover letter. Sorry about that.

On 18 August 2015 at 02:26, Michael Turquette <mturquette at baylibre.com> wrote:
> Quoting Joachim Eastwood (2015-08-13 13:43:11)
>> On 11 August 2015 at 22:41, Michael Turquette <mturquette at baylibre.com> wrote:
>> > Hi Joachim,
>> >
>> > Quoting Joachim Eastwood (2015-07-11 14:48:26)
>> >> +static void __init lpc18xx_creg_clk_init(struct device_node *np)
>> >> +{
>> >> +       const char *clk_32khz_parent;
>> >> +       struct regmap *syscon;
>> >> +
>> >> +       syscon = syscon_node_to_regmap(np->parent);
>> >> +       if (IS_ERR(syscon)) {
>> >> +               pr_err("%s: syscon lookup failed\n", __func__);
>> >> +               return;
>> >> +       }
>> >> +
>> >> +       clk_32khz_parent = of_clk_get_parent_name(np, 0);
>> >> +
>> >> +       clk_creg[CREG_CLK_32KHZ] =
>> >> +               clk_register_creg_clk(&clk_creg_clocks[CREG_CLK_32KHZ],
>> >> +                                     &clk_32khz_parent, syscon);
>> >> +
>> >> +       clk_creg[CREG_CLK_1KHZ] =
>> >> +               clk_register_creg_clk(&clk_creg_clocks[CREG_CLK_1KHZ],
>> >> +                                     &clk_creg_clocks[CREG_CLK_32KHZ].name,
>> >> +                                     syscon);
>> >> +
>> >> +       of_clk_add_provider(np, of_clk_src_onecell_get, &clk_base_data);
>> >> +}
>> >> +CLK_OF_DECLARE(lpc18xx_creg_clk, "nxp,lpc1850-creg-clk", lpc18xx_creg_clk_init);
>> >
>> > I'll ask the same question that Stephen asked in your CCU/CGU driver
>> > series: is it necessary to use CLK_OF_DECLARE here or can you use the
>> > platform device model?
>>
>> The 32 kHz clock from the CREG block is a clock parent to the CGU
>> block so it's possible that it will required early. This is all
>> depends on how the boot loader initially configures the CGU.
>>
>> Currently in the DTS for lpc18xx cgu it has:
>> clocks = <&xtal>, <&xtal32>, <...>;
>> xtal32 is just a temporary placeholder until the CREG clock is in place.
>
> Well that seems wrong. Is it just a matter of probe order where you try
> to probe the cgu driver before the creg driver?

The ideal probe order for the clk drivers on the lpc18xx platform
would be; creg-clk, cgu and ccu.
If the 32k clk is used by any of timers we need creg-clk to enable the
32k clock and determine the rate.

Note that the cgu and ccu driver is using CLK_OF_DECLARE now.


I have tired to create an overview of the lpc18xx clock system here:
https://github.com/manabian/linux-lpc/wiki/LPC18xx-LPC43xx-clocks


regards,
Joachim Eastwood


From linus.walleij at linaro.org  Sat Feb 13 06:42:20 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 13 Feb 2016 15:42:20 +0100
Subject: [PATCH 0/3] OMAP/pinmux: remove misuse of IRQF_NO_SUSPEND flag
In-Reply-To: <1454351299-27440-1-git-send-email-sudeep.holla@arm.com>
References: <1454351299-27440-1-git-send-email-sudeep.holla@arm.com>
Message-ID: <CACRpkdYzJ9Hy0sH6gK6RzpLE6juS4WfPjbt7nh43vR9YTuGZWA@mail.gmail.com>

On Mon, Feb 1, 2016 at 7:28 PM, Sudeep Holla <sudeep.holla at arm.com> wrote:

>   pinctrl: single: Use a separate lockdep class
>   pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag
>   ARM: OMAP2+: remove misuse of IRQF_NO_SUSPEND flag
>
>  arch/arm/mach-omap2/mux.c        |  4 ++--
>  arch/arm/mach-omap2/pm34xx.c     |  9 ++++-----
>  arch/arm/mach-omap2/prm_common.c |  1 +
>  drivers/pinctrl/pinctrl-single.c | 15 ++++++++++++---

Are these patches orthogonal so I can merge the pinctrl patch independently
of the OMAP patches if Tony ACKs this?

If not: should it be merged by me or through ARM SoC/Tony?

Anyways waiting for maintainer feedback, but the above is good to know.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Sat Feb 13 06:48:11 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 13 Feb 2016 15:48:11 +0100
Subject: [PATCH v4 4/9] pinctrl: Add STM32 MCUs support
In-Reply-To: <56AF4AEB.40109@st.com>
References: <1452773795-24216-1-git-send-email-mcoquelin.stm32@gmail.com>
 <1452773795-24216-5-git-send-email-mcoquelin.stm32@gmail.com>
 <CACRpkdaBcP6fC5Oxn+d1WPdHq1FtwMkf8Ap5VDLQFg-5UwEBAw@mail.gmail.com>
 <2151471.Wut3mQ9SS7@wuerfel>
 <CALszF6DTpcU8jFwA0HL8LpkxfO5ZOdFmpHBUxA7WfYgAj_uFhg@mail.gmail.com>
 <56AF4AEB.40109@st.com>
Message-ID: <CACRpkdY1E9rLwG-aXWSB7d32rhvmng+4QbVX7E0WR6aqP0oFaw@mail.gmail.com>

On Mon, Feb 1, 2016 at 1:09 PM, Maxime Coquelin <maxime.coquelin at st.com> wrote:
> On 02/01/2016 11:39 AM, Maxime Coquelin wrote:
>> 2016-02-01 11:21 GMT+01:00 Arnd Bergmann <arnd at arndb.de>:

>>> drivers/pinctrl/stm32/pinctrl-stm32.c:26:47: fatal error:
>>> dt-bindings/pinctrl/pinctrl-stm32.h: No such file or directory
>>
>> Right, I missed to notify this dependency to Linus, sorry about that.
>> This dependency is no more needed, so I could just move the macros to
>> the driver side.
>>
>> Note that I also noticed a breakage at build time due to field
>> renaming in gpio_chip structure (dev -> parent).
>>
>> I propose to rebase the series and move the defines into the driver.
>> Is it ok for you?
>>
> I have rebased the series, taking care to fix the mentioned problems.
>
> Linus, do you confirm you will revert STM32 pinctrl patches from your tree?

I guess the other fixes removes the need to do this.

Sorry for not staying on top of this issue, I was swamped with mail
and had a hard time prioritizing :(

Yours,
Linus Walleij


From maitysanchayan at gmail.com  Sat Feb 13 07:14:53 2016
From: maitysanchayan at gmail.com (maitysanchayan at gmail.com)
Date: Sat, 13 Feb 2016 20:44:53 +0530
Subject: [PATCH v1 2/2] iio: dac: vf610_dac: Add IIO DAC driver for
 Vybrid SoC
In-Reply-To: <56BF2FC3.3070502@kernel.org>
References: <cover.1454939346.git.maitysanchayan@gmail.com>
 <5a699d45c89d239f3e49fa83d16a9b467016e219.1454939346.git.maitysanchayan@gmail.com>
 <alpine.DEB.2.02.1602090729130.22963@pmeerw.net>
 <20160212063403.GA3056@Sanchayan-Arch.toradex.int>
 <56BF2FC3.3070502@kernel.org>
Message-ID: <20160213151453.GA5527@Sanchayan-Arch>

Hello Jonathan,

On 16-02-13 13:29:39, Jonathan Cameron wrote:
> On 12/02/16 06:34, maitysanchayan at gmail.com wrote:
> > Hello Peter,
> > 
> > On 16-02-09 07:43:14, Peter Meerwald-Stadler wrote:
> >> On Tue, 9 Feb 2016, Sanchayan Maity wrote:
> >>
> >>> Add driver support for DAC peripheral on Vybrid SoC.
> >>
> >> comments below
> >>  
> >>> Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
> >>> ---
> >>>  .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
> >>>  drivers/iio/dac/Kconfig                            |   8 +
> >>>  drivers/iio/dac/Makefile                           |   1 +
> >>>  drivers/iio/dac/vf610_dac.c                        | 302 +++++++++++++++++++++
> >>>  4 files changed, 331 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
> >>>  create mode 100644 drivers/iio/dac/vf610_dac.c
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
> >>> new file mode 100644
> >>> index 0000000..97d7a40
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
> >>> @@ -0,0 +1,20 @@
> >>> +Freescale vf610 Digital to Analog Converter bindings
> >>> +
> >>> +The devicetree bindings are for the new DAC driver written for
> >>> +vf610 SoCs from Freescale.
> >>> +
> >>> +Required properties:
> >>> +- compatible: Should contain "fsl,vf610-dac"
> >>> +- reg: Offset and length of the register set for the device
> >>> +- interrupts: Should contain the interrupt for the device
> >>> +- clocks: The clock is needed by the DAC controller
> >>> +- clock-names: Must contain "dac", matching entry in the clocks property.
> >>
> >> the last sentence is not quite clear; is the comma needed?
> >>
> >>> +
> >>> +Example:
> >>> +dac0: dac at 400cc000 {
> >>> +	compatible = "fsl,vf610-dac";
> >>> +	reg = <0x400cc000 0x1000>;
> >>> +	interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
> >>> +	clock-names = "dac";
> >>> +	clocks = <&clks VF610_CLK_DAC0>;
> >>> +};
> >>> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> >>> index e701e28..8eb0502 100644
> >>> --- a/drivers/iio/dac/Kconfig
> >>> +++ b/drivers/iio/dac/Kconfig
> >>> @@ -196,4 +196,12 @@ config MCP4922
> >>>  	  To compile this driver as a module, choose M here: the module
> >>>  	  will be called mcp4922.
> >>>  
> >>> +config VF610_DAC
> >>> +	tristate "Vybrid vf610 DAC driver"
> >>> +	help
> >>> +	  Say yes here to support Vybrid board digital-to-analog converter.
> >>> +
> >>> +	  This driver can also be built as a module. If so, the module will
> >>> +	  be called vf610_dac.
> >>> +
> >>>  endmenu
> >>> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> >>> index 63ae056..93feb27 100644
> >>> --- a/drivers/iio/dac/Makefile
> >>> +++ b/drivers/iio/dac/Makefile
> >>> @@ -21,3 +21,4 @@ obj-$(CONFIG_MAX517) += max517.o
> >>>  obj-$(CONFIG_MAX5821) += max5821.o
> >>>  obj-$(CONFIG_MCP4725) += mcp4725.o
> >>>  obj-$(CONFIG_MCP4922) += mcp4922.o
> >>> +obj-$(CONFIG_VF610_DAC) += vf610_dac.o
> >>> diff --git a/drivers/iio/dac/vf610_dac.c b/drivers/iio/dac/vf610_dac.c
> >>> new file mode 100644
> >>> index 0000000..775b349
> >>> --- /dev/null
> >>> +++ b/drivers/iio/dac/vf610_dac.c
> >>> @@ -0,0 +1,302 @@
> >>> +/*
> >>> + * Freescale Vybrid vf610 DAC driver
> >>> + *
> >>> + * Copyright 2016 Toradex AG
> >>> + *
> >>> + * This program is free software; you can redistribute it and/or modify
> >>> + * it under the terms of the GNU General Public License as published by
> >>> + * the Free Software Foundation; either version 2 of the License, or
> >>> + * (at your option) any later version.
> >>> + *
> >>> + * This program is distributed in the hope that it will be useful,
> >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >>> + * GNU General Public License for more details.
> >>> + */
> >>> +
> >>> +#include <linux/clk.h>
> >>> +#include <linux/err.h>
> >>> +#include <linux/interrupt.h>
> >>> +#include <linux/io.h>
> >>> +#include <linux/kernel.h>
> >>> +#include <linux/module.h>
> >>> +#include <linux/platform_device.h>
> >>> +#include <linux/regulator/consumer.h>
> >>> +#include <linux/slab.h>
> >>> +
> >>> +#include <linux/iio/iio.h>
> >>> +#include <linux/iio/sysfs.h>
> >>> +
> >>> +#define DRIVER_NAME "vf610-dac"
> >>
> >> VF610_ prefix
> >>
> >>> +
> >>> +#define VF610_DACx_STATCTRL		0x20
> >>> +
> >>> +#define VF610_DAC_DACEN			BIT(15)
> >>> +#define VF610_DAC_DACRFS		BIT(14)
> >>> +#define VF610_DAC_LPEN			BIT(11)
> >>> +
> >>> +#define VF610_DAC_DAT0(x)		((x) & 0xFFF)
> >>> +
> >>> +enum conversion_mode_sel {
> >>
> >> vf610_ prefix
> >>
> >>> +	VF610_DAC_CONV_HIGH_POWER,
> >>> +	VF610_DAC_CONV_LOW_POWER,
> >>> +};
> >>> +
> >>> +struct vf610_dac {
> >>> +	struct clk *clk;
> >>> +	struct device *dev;
> >>> +	enum conversion_mode_sel conv_mode;
> >>> +	void __iomem *regs;
> >>> +	int irq;
> >>> +};
> >>> +
> >>> +static int vf610_dac_init(struct vf610_dac *info)
> >>
> >> should be void, or check the return value
> >>
> >>> +{
> >>> +	int val;
> >>> +
> >>> +	info->conv_mode = VF610_DAC_CONV_LOW_POWER;
> >>> +	val = VF610_DAC_DACEN | VF610_DAC_DACRFS |
> >>> +		VF610_DAC_LPEN;
> >>> +	writel(val, info->regs + VF610_DACx_STATCTRL);
> >>> +
> >>> +	return 0;
> >>> +}
> >>> +
> >>> +static int vf610_set_conversion_mode(struct iio_dev *indio_dev,
> >>> +				const struct iio_chan_spec *chan,
> >>> +				unsigned int mode)
> >>
> >> mode should be enum conversion_mode_sel?
> >>
> >>> +{
> >>> +	struct vf610_dac *info = iio_priv(indio_dev);
> >>> +	int val;
> >>> +
> >>> +	mutex_lock(&indio_dev->mlock);
> >>> +	info->conv_mode = mode;
> >>> +	val = readl(info->regs + VF610_DACx_STATCTRL);
> >>> +	if (mode)
> >>> +		val |= VF610_DAC_LPEN;
> >>> +	else
> >>> +		val &= ~VF610_DAC_LPEN;
> >>> +	writel(val, info->regs + VF610_DACx_STATCTRL);
> >>> +	mutex_unlock(&indio_dev->mlock);
> >>> +
> >>> +	return 0;
> >>> +}
> >>> +
> >>> +static int vf610_get_conversion_mode(struct iio_dev *indio_dev,
> >>
> >> return of type enum conversion_mode_sel?
> > 
> > 
> > Regarding the enum. As per the function prototype in iio.h
> > 
> > struct iio_enum {
> >         const char * const *items;
> >         unsigned int num_items;
> >         int (*set)(struct iio_dev *, const struct iio_chan_spec *, unsigned int);
> >         int (*get)(struct iio_dev *, const struct iio_chan_spec *);
> > };
> > 
> > the "mode" argument is unsigned int and return type of getter is int as well.
> > 
> >>
> >>> +				const struct iio_chan_spec *chan)
> >>> +{
> >>> +	struct vf610_dac *info = iio_priv(indio_dev);
> >>> +
> >>> +	return info->conv_mode;
> >>> +}
> >>> +
> >>> +static const char * const vf610_conv_modes[] = { "high-power", "low-power"};
> >>
> >> this should be documented in sysfs-bus-iio-vf610; maybe high-power should 
> >> be high-speed
> >>
> >> probably this interface should have been exposed as a settable 
> >> conversion rate
> > 
> > Vybrid DAC block does not provide for setting a conversion rate. There is only one
> > register for configration and only one LPEN bit concerning power mode. As per the
> > operating behavior, this controls characteristics of supply current, settling time
> > and slew rate.
> It strikes me that perhaps for DACs it would not be overkill to actually
> expose the settling time and slew rate via sysfs?
> I'd be happy enough seeing these as new info_mask elements as they
> are fairly common.  Are these the best ways to describe DAC performance
> characteristics? Sounds right to me but my electronics background is
> limited!
> 
> > 
> > While I agree this should be documented in ABI sysfs documentation, I am not clear
> > as to how that should be. Currently that document specifies the modes observed for
> > the vf610 ADC driver. As per the datasheet, "high-power" and "low-power" would be
> > the most clear description in case of DAC but "normal", "high-speed" and "low-power"
> > are applicable for ADC. This just stuck me just now while making the change.
> Certainly not obvious.  Could use the slewrate or settling time as explicit
> controls on this (support both perhaps, with the usual IIO interface rule
> that you should never assume changing one sysfs attribute won't also change
> another!)
> 
> This would then correspond to some degree with the analogy of setting
> effectively power modes for ADCs via sampling frequency as the dominant
> attribute that effects their power usage.

There is no explicit setting or register to set for controlling slew rate or
settling time. There is only one LPEN bit which specifies low or high power
mode. This bit would then effect the settling time or slew rate which would
be the typical values in the datasheet.

Regards,
Sanchayan.

> 
> Jonathan
> > 
> > How should I best include this? Peter, Jonathan, Stefan suggestions?
> > 
> > I have changed the code to include all other feedback. Thank you for feedback.
> > 
> > Best Regards,
> > Sanchayan.
> > 
> >>
> >>> +
> >>> +static const struct iio_enum vf610_conversion_mode = {
> >>> +	.items = vf610_conv_modes,
> >>> +	.num_items = ARRAY_SIZE(vf610_conv_modes),
> >>> +	.get = vf610_get_conversion_mode,
> >>> +	.set = vf610_set_conversion_mode,
> >>> +};
> >>> +
> >>> +static const struct iio_chan_spec_ext_info vf610_ext_info[] = {
> >>> +	IIO_ENUM("conversion_mode", IIO_SHARED_BY_DIR,
> >>> +		&vf610_conversion_mode),
> >>> +	{},
> >>> +};
> >>> +
> >>> +#define VF610_DAC_CHAN(_chan_type) { \
> >>> +	.type = (_chan_type), \
> >>> +	.indexed = -1, \
> >>
> >> indexed should be 0 (or not specified) if no indexing is to be used
> >>
> >>> +	.output = 1, \
> >>> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> >>> +	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> >>> +	.ext_info = vf610_ext_info, \
> >>> +}
> >>> +
> >>> +static const struct iio_chan_spec vf610_dac_iio_channels[] = {
> >>> +	VF610_DAC_CHAN(IIO_VOLTAGE),
> >>> +};
> >>> +
> >>> +static int vf610_read_raw(struct iio_dev *indio_dev,
> >>> +			struct iio_chan_spec const *chan,
> >>> +			int *val, int *val2,
> >>> +			long mask)
> >>> +{
> >>> +	struct vf610_dac *info = iio_priv(indio_dev);
> >>> +
> >>> +	switch (mask) {
> >>> +	case IIO_CHAN_INFO_RAW:
> >>> +		*val = VF610_DAC_DAT0(readl(info->regs));
> >>> +		return IIO_VAL_INT;
> >>> +	case IIO_CHAN_INFO_SCALE:
> >>> +		/*
> >>> +		 * DACRFS is always 1 for valid reference and typical
> >>> +		 * reference voltage as per Vybrid datasheet is 3.3V
> >>> +		 * from section 9.1.2.1 of Vybrid datasheet
> >>> +		 */
> >>> +		*val = 3300 /* mV */;
> >>> +		*val2 = 12;
> >>> +		return IIO_VAL_FRACTIONAL_LOG2;
> >>> +
> >>> +	default:
> >>> +		break;
> >>
> >> just return -EINVAL here?
> >> and remove it below below
> >>
> >>> +	}
> >>> +
> >>> +	return -EINVAL;
> >>> +}
> >>> +
> >>> +static int vf610_write_raw(struct iio_dev *indio_dev,
> >>> +			struct iio_chan_spec const *chan,
> >>> +			int val, int val2,
> >>> +			long mask)
> >>> +{
> >>> +	struct vf610_dac *info = iio_priv(indio_dev);
> >>> +
> >>> +	switch (mask) {
> >>> +	case IIO_CHAN_INFO_RAW:
> >>> +		mutex_lock(&indio_dev->mlock);
> >>> +		writel(VF610_DAC_DAT0(val), info->regs);
> >>> +		mutex_unlock(&indio_dev->mlock);
> >>> +		return 0;
> >>> +
> >>> +	default:
> >>> +		break;
> >>
> >> return -EINVAL here should save two lines
> >>
> >>> +	}
> >>> +
> >>> +	return -EINVAL;
> >>> +}
> >>> +
> >>> +static const struct iio_info vf610_dac_iio_info = {
> >>> +	.driver_module = THIS_MODULE,
> >>> +	.read_raw = &vf610_read_raw,
> >>> +	.write_raw = &vf610_write_raw,
> >>> +};
> >>> +
> >>> +static const struct of_device_id vf610_dac_match[] = {
> >>> +	{ .compatible = "fsl,vf610-dac", },
> >>> +	{ /* sentinel */ }
> >>> +};
> >>> +MODULE_DEVICE_TABLE(of, vf610_dac_match);
> >>> +
> >>> +static int vf610_dac_probe(struct platform_device *pdev)
> >>> +{
> >>> +	struct iio_dev *indio_dev;
> >>> +	struct vf610_dac *info;
> >>> +	struct resource *mem;
> >>> +	int ret;
> >>> +
> >>> +	indio_dev = devm_iio_device_alloc(&pdev->dev,
> >>> +					sizeof(struct vf610_dac));
> >>> +	if (!indio_dev) {
> >>> +		dev_err(&pdev->dev, "Failed allocating iio device\n");
> >>> +		return -ENOMEM;
> >>> +	}
> >>> +
> >>> +	info = iio_priv(indio_dev);
> >>> +	info->dev = &pdev->dev;
> >>> +
> >>> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >>> +	info->regs = devm_ioremap_resource(&pdev->dev, mem);
> >>> +	if (IS_ERR(info->regs))
> >>> +		return PTR_ERR(info->regs);
> >>> +
> >>> +	info->clk = devm_clk_get(&pdev->dev, "dac");
> >>> +	if (IS_ERR(info->clk)) {
> >>> +		dev_err(&pdev->dev, "failed getting clock, err = %ld\n",
> >>
> >> "Failed getting ..."
> >>
> >>> +			PTR_ERR(info->clk));
> >>> +		return PTR_ERR(info->clk);
> >>> +	}
> >>> +
> >>> +	platform_set_drvdata(pdev, indio_dev);
> >>> +
> >>> +	indio_dev->name = dev_name(&pdev->dev);
> >>> +	indio_dev->dev.parent = &pdev->dev;
> >>> +	indio_dev->dev.of_node = pdev->dev.of_node;
> >>> +	indio_dev->info = &vf610_dac_iio_info;
> >>> +	indio_dev->modes = INDIO_DIRECT_MODE;
> >>> +	indio_dev->channels = vf610_dac_iio_channels;
> >>> +	indio_dev->num_channels = ARRAY_SIZE(vf610_dac_iio_channels);
> >>> +
> >>> +	ret = clk_prepare_enable(info->clk);
> >>> +	if (ret) {
> >>> +		dev_err(&pdev->dev,
> >>> +			"Could not prepare or enable the clock\n");
> >>> +		return ret;
> >>> +	}
> >>> +
> >>> +	ret = iio_device_register(indio_dev);
> >>> +	if (ret) {
> >>> +		dev_err(&pdev->dev, "Couldn't register the device\n");
> >>> +		goto error_iio_device_register;
> >>> +	}
> >>> +
> >>> +	vf610_dac_init(info);
> >>
> >> there is a race here, move _dac_init() before _register()
> >> return value is not checked (or use void)
> >>
> >>> +
> >>> +	return 0;
> >>> +
> >>> +error_iio_device_register:
> >>> +	clk_disable_unprepare(info->clk);
> >>> +
> >>> +	return ret;
> >>> +}
> >>> +
> >>> +static int vf610_dac_remove(struct platform_device *pdev)
> >>> +{
> >>> +	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> >>> +	struct vf610_dac *info = iio_priv(indio_dev);
> >>> +
> >>> +	iio_device_unregister(indio_dev);
> >>> +	clk_disable_unprepare(info->clk);
> >>> +
> >>> +	return 0;
> >>> +}
> >>> +
> >>> +#ifdef CONFIG_PM_SLEEP
> >>> +static int vf610_dac_suspend(struct device *dev)
> >>> +{
> >>> +	struct iio_dev *indio_dev = dev_get_drvdata(dev);
> >>> +	struct vf610_dac *info = iio_priv(indio_dev);
> >>> +	int val;
> >>> +
> >>> +	val = readl(info->regs + VF610_DACx_STATCTRL);
> >>> +	val &= ~VF610_DAC_DACEN;
> >>> +	writel(val, info->regs + VF610_DACx_STATCTRL);
> >>> +
> >>> +	clk_disable_unprepare(info->clk);
> >>> +
> >>> +	return 0;
> >>> +}
> >>> +
> >>> +static int vf610_dac_resume(struct device *dev)
> >>> +{
> >>> +	struct iio_dev *indio_dev = dev_get_drvdata(dev);
> >>> +	struct vf610_dac *info = iio_priv(indio_dev);
> >>> +	int ret;
> >>> +
> >>> +	ret = clk_prepare_enable(info->clk);
> >>> +	if (ret)
> >>> +		return ret;
> >>> +
> >>> +	vf610_dac_init(info);
> >>> +
> >>> +	return 0;
> >>> +}
> >>> +#endif
> >>> +
> >>> +static SIMPLE_DEV_PM_OPS(vf610_dac_pm_ops, vf610_dac_suspend, vf610_dac_resume);
> >>> +
> >>> +static struct platform_driver vf610_dac_driver = {
> >>> +	.probe          = vf610_dac_probe,
> >>> +	.remove         = vf610_dac_remove,
> >>> +	.driver         = {
> >>> +		.name   = DRIVER_NAME,
> >>> +		.of_match_table = vf610_dac_match,
> >>> +		.pm     = &vf610_dac_pm_ops,
> >>> +	},
> >>> +};
> >>> +module_platform_driver(vf610_dac_driver);
> >>> +
> >>> +MODULE_AUTHOR("Sanchayan Maity <sanchayan.maity at toradex.com");
> >>> +MODULE_DESCRIPTION("Freescale VF610 DAC driver");
> >>> +MODULE_LICENSE("GPL v2");
> >>>
> >>
> >> -- 
> >>
> >> Peter Meerwald-Stadler
> >> +43-664-2444418 (mobile)
> 


From jic23 at kernel.org  Sat Feb 13 07:26:19 2016
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sat, 13 Feb 2016 15:26:19 +0000
Subject: [PATCH v1 2/2] iio: dac: vf610_dac: Add IIO DAC driver for Vybrid
 SoC
In-Reply-To: <20160213151453.GA5527@Sanchayan-Arch>
References: <cover.1454939346.git.maitysanchayan@gmail.com>
 <5a699d45c89d239f3e49fa83d16a9b467016e219.1454939346.git.maitysanchayan@gmail.com>
 <alpine.DEB.2.02.1602090729130.22963@pmeerw.net>
 <20160212063403.GA3056@Sanchayan-Arch.toradex.int>
 <56BF2FC3.3070502@kernel.org> <20160213151453.GA5527@Sanchayan-Arch>
Message-ID: <94E7F788-FDFC-4D79-A0D5-8FA332CFDFC1@kernel.org>



On 13 February 2016 15:14:53 GMT+00:00, maitysanchayan at gmail.com wrote:
>Hello Jonathan,
>
>On 16-02-13 13:29:39, Jonathan Cameron wrote:
>> On 12/02/16 06:34, maitysanchayan at gmail.com wrote:
>> > Hello Peter,
>> > 
>> > On 16-02-09 07:43:14, Peter Meerwald-Stadler wrote:
>> >> On Tue, 9 Feb 2016, Sanchayan Maity wrote:
>> >>
>> >>> Add driver support for DAC peripheral on Vybrid SoC.
>> >>
>> >> comments below
>> >>  
>> >>> Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
>> >>> ---
>> >>>  .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
>> >>>  drivers/iio/dac/Kconfig                            |   8 +
>> >>>  drivers/iio/dac/Makefile                           |   1 +
>> >>>  drivers/iio/dac/vf610_dac.c                        | 302
>+++++++++++++++++++++
>> >>>  4 files changed, 331 insertions(+)
>> >>>  create mode 100644
>Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>> >>>  create mode 100644 drivers/iio/dac/vf610_dac.c
>> >>>
>> >>> diff --git
>a/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>> >>> new file mode 100644
>> >>> index 0000000..97d7a40
>> >>> --- /dev/null
>> >>> +++ b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>> >>> @@ -0,0 +1,20 @@
>> >>> +Freescale vf610 Digital to Analog Converter bindings
>> >>> +
>> >>> +The devicetree bindings are for the new DAC driver written for
>> >>> +vf610 SoCs from Freescale.
>> >>> +
>> >>> +Required properties:
>> >>> +- compatible: Should contain "fsl,vf610-dac"
>> >>> +- reg: Offset and length of the register set for the device
>> >>> +- interrupts: Should contain the interrupt for the device
>> >>> +- clocks: The clock is needed by the DAC controller
>> >>> +- clock-names: Must contain "dac", matching entry in the clocks
>property.
>> >>
>> >> the last sentence is not quite clear; is the comma needed?
>> >>
>> >>> +
>> >>> +Example:
>> >>> +dac0: dac at 400cc000 {
>> >>> +	compatible = "fsl,vf610-dac";
>> >>> +	reg = <0x400cc000 0x1000>;
>> >>> +	interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
>> >>> +	clock-names = "dac";
>> >>> +	clocks = <&clks VF610_CLK_DAC0>;
>> >>> +};
>> >>> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
>> >>> index e701e28..8eb0502 100644
>> >>> --- a/drivers/iio/dac/Kconfig
>> >>> +++ b/drivers/iio/dac/Kconfig
>> >>> @@ -196,4 +196,12 @@ config MCP4922
>> >>>  	  To compile this driver as a module, choose M here: the module
>> >>>  	  will be called mcp4922.
>> >>>  
>> >>> +config VF610_DAC
>> >>> +	tristate "Vybrid vf610 DAC driver"
>> >>> +	help
>> >>> +	  Say yes here to support Vybrid board digital-to-analog
>converter.
>> >>> +
>> >>> +	  This driver can also be built as a module. If so, the module
>will
>> >>> +	  be called vf610_dac.
>> >>> +
>> >>>  endmenu
>> >>> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
>> >>> index 63ae056..93feb27 100644
>> >>> --- a/drivers/iio/dac/Makefile
>> >>> +++ b/drivers/iio/dac/Makefile
>> >>> @@ -21,3 +21,4 @@ obj-$(CONFIG_MAX517) += max517.o
>> >>>  obj-$(CONFIG_MAX5821) += max5821.o
>> >>>  obj-$(CONFIG_MCP4725) += mcp4725.o
>> >>>  obj-$(CONFIG_MCP4922) += mcp4922.o
>> >>> +obj-$(CONFIG_VF610_DAC) += vf610_dac.o
>> >>> diff --git a/drivers/iio/dac/vf610_dac.c
>b/drivers/iio/dac/vf610_dac.c
>> >>> new file mode 100644
>> >>> index 0000000..775b349
>> >>> --- /dev/null
>> >>> +++ b/drivers/iio/dac/vf610_dac.c
>> >>> @@ -0,0 +1,302 @@
>> >>> +/*
>> >>> + * Freescale Vybrid vf610 DAC driver
>> >>> + *
>> >>> + * Copyright 2016 Toradex AG
>> >>> + *
>> >>> + * This program is free software; you can redistribute it and/or
>modify
>> >>> + * it under the terms of the GNU General Public License as
>published by
>> >>> + * the Free Software Foundation; either version 2 of the
>License, or
>> >>> + * (at your option) any later version.
>> >>> + *
>> >>> + * This program is distributed in the hope that it will be
>useful,
>> >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty
>of
>> >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> >>> + * GNU General Public License for more details.
>> >>> + */
>> >>> +
>> >>> +#include <linux/clk.h>
>> >>> +#include <linux/err.h>
>> >>> +#include <linux/interrupt.h>
>> >>> +#include <linux/io.h>
>> >>> +#include <linux/kernel.h>
>> >>> +#include <linux/module.h>
>> >>> +#include <linux/platform_device.h>
>> >>> +#include <linux/regulator/consumer.h>
>> >>> +#include <linux/slab.h>
>> >>> +
>> >>> +#include <linux/iio/iio.h>
>> >>> +#include <linux/iio/sysfs.h>
>> >>> +
>> >>> +#define DRIVER_NAME "vf610-dac"
>> >>
>> >> VF610_ prefix
>> >>
>> >>> +
>> >>> +#define VF610_DACx_STATCTRL		0x20
>> >>> +
>> >>> +#define VF610_DAC_DACEN			BIT(15)
>> >>> +#define VF610_DAC_DACRFS		BIT(14)
>> >>> +#define VF610_DAC_LPEN			BIT(11)
>> >>> +
>> >>> +#define VF610_DAC_DAT0(x)		((x) & 0xFFF)
>> >>> +
>> >>> +enum conversion_mode_sel {
>> >>
>> >> vf610_ prefix
>> >>
>> >>> +	VF610_DAC_CONV_HIGH_POWER,
>> >>> +	VF610_DAC_CONV_LOW_POWER,
>> >>> +};
>> >>> +
>> >>> +struct vf610_dac {
>> >>> +	struct clk *clk;
>> >>> +	struct device *dev;
>> >>> +	enum conversion_mode_sel conv_mode;
>> >>> +	void __iomem *regs;
>> >>> +	int irq;
>> >>> +};
>> >>> +
>> >>> +static int vf610_dac_init(struct vf610_dac *info)
>> >>
>> >> should be void, or check the return value
>> >>
>> >>> +{
>> >>> +	int val;
>> >>> +
>> >>> +	info->conv_mode = VF610_DAC_CONV_LOW_POWER;
>> >>> +	val = VF610_DAC_DACEN | VF610_DAC_DACRFS |
>> >>> +		VF610_DAC_LPEN;
>> >>> +	writel(val, info->regs + VF610_DACx_STATCTRL);
>> >>> +
>> >>> +	return 0;
>> >>> +}
>> >>> +
>> >>> +static int vf610_set_conversion_mode(struct iio_dev *indio_dev,
>> >>> +				const struct iio_chan_spec *chan,
>> >>> +				unsigned int mode)
>> >>
>> >> mode should be enum conversion_mode_sel?
>> >>
>> >>> +{
>> >>> +	struct vf610_dac *info = iio_priv(indio_dev);
>> >>> +	int val;
>> >>> +
>> >>> +	mutex_lock(&indio_dev->mlock);
>> >>> +	info->conv_mode = mode;
>> >>> +	val = readl(info->regs + VF610_DACx_STATCTRL);
>> >>> +	if (mode)
>> >>> +		val |= VF610_DAC_LPEN;
>> >>> +	else
>> >>> +		val &= ~VF610_DAC_LPEN;
>> >>> +	writel(val, info->regs + VF610_DACx_STATCTRL);
>> >>> +	mutex_unlock(&indio_dev->mlock);
>> >>> +
>> >>> +	return 0;
>> >>> +}
>> >>> +
>> >>> +static int vf610_get_conversion_mode(struct iio_dev *indio_dev,
>> >>
>> >> return of type enum conversion_mode_sel?
>> > 
>> > 
>> > Regarding the enum. As per the function prototype in iio.h
>> > 
>> > struct iio_enum {
>> >         const char * const *items;
>> >         unsigned int num_items;
>> >         int (*set)(struct iio_dev *, const struct iio_chan_spec *,
>unsigned int);
>> >         int (*get)(struct iio_dev *, const struct iio_chan_spec *);
>> > };
>> > 
>> > the "mode" argument is unsigned int and return type of getter is
>int as well.
>> > 
>> >>
>> >>> +				const struct iio_chan_spec *chan)
>> >>> +{
>> >>> +	struct vf610_dac *info = iio_priv(indio_dev);
>> >>> +
>> >>> +	return info->conv_mode;
>> >>> +}
>> >>> +
>> >>> +static const char * const vf610_conv_modes[] = { "high-power",
>"low-power"};
>> >>
>> >> this should be documented in sysfs-bus-iio-vf610; maybe high-power
>should 
>> >> be high-speed
>> >>
>> >> probably this interface should have been exposed as a settable 
>> >> conversion rate
>> > 
>> > Vybrid DAC block does not provide for setting a conversion rate.
>There is only one
>> > register for configration and only one LPEN bit concerning power
>mode. As per the
>> > operating behavior, this controls characteristics of supply
>current, settling time
>> > and slew rate.
>> It strikes me that perhaps for DACs it would not be overkill to
>actually
>> expose the settling time and slew rate via sysfs?
>> I'd be happy enough seeing these as new info_mask elements as they
>> are fairly common.  Are these the best ways to describe DAC
>performance
>> characteristics? Sounds right to me but my electronics background is
>> limited!
>> 
>> > 
>> > While I agree this should be documented in ABI sysfs documentation,
>I am not clear
>> > as to how that should be. Currently that document specifies the
>modes observed for
>> > the vf610 ADC driver. As per the datasheet, "high-power" and
>"low-power" would be
>> > the most clear description in case of DAC but "normal",
>"high-speed" and "low-power"
>> > are applicable for ADC. This just stuck me just now while making
>the change.
>> Certainly not obvious.  Could use the slewrate or settling time as
>explicit
>> controls on this (support both perhaps, with the usual IIO interface
>rule
>> that you should never assume changing one sysfs attribute won't also
>change
>> another!)
>> 
>> This would then correspond to some degree with the analogy of setting
>> effectively power modes for ADCs via sampling frequency as the
>dominant
>> attribute that effects their power usage.
>
>There is no explicit setting or register to set for controlling slew
>rate or
>settling time. There is only one LPEN bit which specifies low or high
>power
>mode. This bit would then effect the settling time or slew rate which
>would
>be the typical values in the datasheet.
That's fine. Just have available attributes with the two resulting values.

J
>
>Regards,
>Sanchayan.
>
>> 
>> Jonathan
>> > 
>> > How should I best include this? Peter, Jonathan, Stefan
>suggestions?
>> > 
>> > I have changed the code to include all other feedback. Thank you
>for feedback.
>> > 
>> > Best Regards,
>> > Sanchayan.
>> > 
>> >>
>> >>> +
>> >>> +static const struct iio_enum vf610_conversion_mode = {
>> >>> +	.items = vf610_conv_modes,
>> >>> +	.num_items = ARRAY_SIZE(vf610_conv_modes),
>> >>> +	.get = vf610_get_conversion_mode,
>> >>> +	.set = vf610_set_conversion_mode,
>> >>> +};
>> >>> +
>> >>> +static const struct iio_chan_spec_ext_info vf610_ext_info[] = {
>> >>> +	IIO_ENUM("conversion_mode", IIO_SHARED_BY_DIR,
>> >>> +		&vf610_conversion_mode),
>> >>> +	{},
>> >>> +};
>> >>> +
>> >>> +#define VF610_DAC_CHAN(_chan_type) { \
>> >>> +	.type = (_chan_type), \
>> >>> +	.indexed = -1, \
>> >>
>> >> indexed should be 0 (or not specified) if no indexing is to be
>used
>> >>
>> >>> +	.output = 1, \
>> >>> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
>> >>> +	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
>> >>> +	.ext_info = vf610_ext_info, \
>> >>> +}
>> >>> +
>> >>> +static const struct iio_chan_spec vf610_dac_iio_channels[] = {
>> >>> +	VF610_DAC_CHAN(IIO_VOLTAGE),
>> >>> +};
>> >>> +
>> >>> +static int vf610_read_raw(struct iio_dev *indio_dev,
>> >>> +			struct iio_chan_spec const *chan,
>> >>> +			int *val, int *val2,
>> >>> +			long mask)
>> >>> +{
>> >>> +	struct vf610_dac *info = iio_priv(indio_dev);
>> >>> +
>> >>> +	switch (mask) {
>> >>> +	case IIO_CHAN_INFO_RAW:
>> >>> +		*val = VF610_DAC_DAT0(readl(info->regs));
>> >>> +		return IIO_VAL_INT;
>> >>> +	case IIO_CHAN_INFO_SCALE:
>> >>> +		/*
>> >>> +		 * DACRFS is always 1 for valid reference and typical
>> >>> +		 * reference voltage as per Vybrid datasheet is 3.3V
>> >>> +		 * from section 9.1.2.1 of Vybrid datasheet
>> >>> +		 */
>> >>> +		*val = 3300 /* mV */;
>> >>> +		*val2 = 12;
>> >>> +		return IIO_VAL_FRACTIONAL_LOG2;
>> >>> +
>> >>> +	default:
>> >>> +		break;
>> >>
>> >> just return -EINVAL here?
>> >> and remove it below below
>> >>
>> >>> +	}
>> >>> +
>> >>> +	return -EINVAL;
>> >>> +}
>> >>> +
>> >>> +static int vf610_write_raw(struct iio_dev *indio_dev,
>> >>> +			struct iio_chan_spec const *chan,
>> >>> +			int val, int val2,
>> >>> +			long mask)
>> >>> +{
>> >>> +	struct vf610_dac *info = iio_priv(indio_dev);
>> >>> +
>> >>> +	switch (mask) {
>> >>> +	case IIO_CHAN_INFO_RAW:
>> >>> +		mutex_lock(&indio_dev->mlock);
>> >>> +		writel(VF610_DAC_DAT0(val), info->regs);
>> >>> +		mutex_unlock(&indio_dev->mlock);
>> >>> +		return 0;
>> >>> +
>> >>> +	default:
>> >>> +		break;
>> >>
>> >> return -EINVAL here should save two lines
>> >>
>> >>> +	}
>> >>> +
>> >>> +	return -EINVAL;
>> >>> +}
>> >>> +
>> >>> +static const struct iio_info vf610_dac_iio_info = {
>> >>> +	.driver_module = THIS_MODULE,
>> >>> +	.read_raw = &vf610_read_raw,
>> >>> +	.write_raw = &vf610_write_raw,
>> >>> +};
>> >>> +
>> >>> +static const struct of_device_id vf610_dac_match[] = {
>> >>> +	{ .compatible = "fsl,vf610-dac", },
>> >>> +	{ /* sentinel */ }
>> >>> +};
>> >>> +MODULE_DEVICE_TABLE(of, vf610_dac_match);
>> >>> +
>> >>> +static int vf610_dac_probe(struct platform_device *pdev)
>> >>> +{
>> >>> +	struct iio_dev *indio_dev;
>> >>> +	struct vf610_dac *info;
>> >>> +	struct resource *mem;
>> >>> +	int ret;
>> >>> +
>> >>> +	indio_dev = devm_iio_device_alloc(&pdev->dev,
>> >>> +					sizeof(struct vf610_dac));
>> >>> +	if (!indio_dev) {
>> >>> +		dev_err(&pdev->dev, "Failed allocating iio device\n");
>> >>> +		return -ENOMEM;
>> >>> +	}
>> >>> +
>> >>> +	info = iio_priv(indio_dev);
>> >>> +	info->dev = &pdev->dev;
>> >>> +
>> >>> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> >>> +	info->regs = devm_ioremap_resource(&pdev->dev, mem);
>> >>> +	if (IS_ERR(info->regs))
>> >>> +		return PTR_ERR(info->regs);
>> >>> +
>> >>> +	info->clk = devm_clk_get(&pdev->dev, "dac");
>> >>> +	if (IS_ERR(info->clk)) {
>> >>> +		dev_err(&pdev->dev, "failed getting clock, err = %ld\n",
>> >>
>> >> "Failed getting ..."
>> >>
>> >>> +			PTR_ERR(info->clk));
>> >>> +		return PTR_ERR(info->clk);
>> >>> +	}
>> >>> +
>> >>> +	platform_set_drvdata(pdev, indio_dev);
>> >>> +
>> >>> +	indio_dev->name = dev_name(&pdev->dev);
>> >>> +	indio_dev->dev.parent = &pdev->dev;
>> >>> +	indio_dev->dev.of_node = pdev->dev.of_node;
>> >>> +	indio_dev->info = &vf610_dac_iio_info;
>> >>> +	indio_dev->modes = INDIO_DIRECT_MODE;
>> >>> +	indio_dev->channels = vf610_dac_iio_channels;
>> >>> +	indio_dev->num_channels = ARRAY_SIZE(vf610_dac_iio_channels);
>> >>> +
>> >>> +	ret = clk_prepare_enable(info->clk);
>> >>> +	if (ret) {
>> >>> +		dev_err(&pdev->dev,
>> >>> +			"Could not prepare or enable the clock\n");
>> >>> +		return ret;
>> >>> +	}
>> >>> +
>> >>> +	ret = iio_device_register(indio_dev);
>> >>> +	if (ret) {
>> >>> +		dev_err(&pdev->dev, "Couldn't register the device\n");
>> >>> +		goto error_iio_device_register;
>> >>> +	}
>> >>> +
>> >>> +	vf610_dac_init(info);
>> >>
>> >> there is a race here, move _dac_init() before _register()
>> >> return value is not checked (or use void)
>> >>
>> >>> +
>> >>> +	return 0;
>> >>> +
>> >>> +error_iio_device_register:
>> >>> +	clk_disable_unprepare(info->clk);
>> >>> +
>> >>> +	return ret;
>> >>> +}
>> >>> +
>> >>> +static int vf610_dac_remove(struct platform_device *pdev)
>> >>> +{
>> >>> +	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>> >>> +	struct vf610_dac *info = iio_priv(indio_dev);
>> >>> +
>> >>> +	iio_device_unregister(indio_dev);
>> >>> +	clk_disable_unprepare(info->clk);
>> >>> +
>> >>> +	return 0;
>> >>> +}
>> >>> +
>> >>> +#ifdef CONFIG_PM_SLEEP
>> >>> +static int vf610_dac_suspend(struct device *dev)
>> >>> +{
>> >>> +	struct iio_dev *indio_dev = dev_get_drvdata(dev);
>> >>> +	struct vf610_dac *info = iio_priv(indio_dev);
>> >>> +	int val;
>> >>> +
>> >>> +	val = readl(info->regs + VF610_DACx_STATCTRL);
>> >>> +	val &= ~VF610_DAC_DACEN;
>> >>> +	writel(val, info->regs + VF610_DACx_STATCTRL);
>> >>> +
>> >>> +	clk_disable_unprepare(info->clk);
>> >>> +
>> >>> +	return 0;
>> >>> +}
>> >>> +
>> >>> +static int vf610_dac_resume(struct device *dev)
>> >>> +{
>> >>> +	struct iio_dev *indio_dev = dev_get_drvdata(dev);
>> >>> +	struct vf610_dac *info = iio_priv(indio_dev);
>> >>> +	int ret;
>> >>> +
>> >>> +	ret = clk_prepare_enable(info->clk);
>> >>> +	if (ret)
>> >>> +		return ret;
>> >>> +
>> >>> +	vf610_dac_init(info);
>> >>> +
>> >>> +	return 0;
>> >>> +}
>> >>> +#endif
>> >>> +
>> >>> +static SIMPLE_DEV_PM_OPS(vf610_dac_pm_ops, vf610_dac_suspend,
>vf610_dac_resume);
>> >>> +
>> >>> +static struct platform_driver vf610_dac_driver = {
>> >>> +	.probe          = vf610_dac_probe,
>> >>> +	.remove         = vf610_dac_remove,
>> >>> +	.driver         = {
>> >>> +		.name   = DRIVER_NAME,
>> >>> +		.of_match_table = vf610_dac_match,
>> >>> +		.pm     = &vf610_dac_pm_ops,
>> >>> +	},
>> >>> +};
>> >>> +module_platform_driver(vf610_dac_driver);
>> >>> +
>> >>> +MODULE_AUTHOR("Sanchayan Maity <sanchayan.maity at toradex.com");
>> >>> +MODULE_DESCRIPTION("Freescale VF610 DAC driver");
>> >>> +MODULE_LICENSE("GPL v2");
>> >>>
>> >>
>> >> -- 
>> >>
>> >> Peter Meerwald-Stadler
>> >> +43-664-2444418 (mobile)
>> 
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo at vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


From ard.biesheuvel at linaro.org  Sat Feb 13 08:43:40 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Sat, 13 Feb 2016 17:43:40 +0100
Subject: [PATCH 2/2] arm64: Mark kernel page ranges contiguous
In-Reply-To: <1455293208-6763-3-git-send-email-jeremy.linton@arm.com>
References: <1455293208-6763-1-git-send-email-jeremy.linton@arm.com>
 <1455293208-6763-3-git-send-email-jeremy.linton@arm.com>
Message-ID: <CAKv+Gu_uu-UdH-2HaAB+jJ7Ex0if4s4ZxjuJMx6f-s3NbO6G8A@mail.gmail.com>

Hi Jeremy,

On 12 February 2016 at 17:06, Jeremy Linton <jeremy.linton at arm.com> wrote:
> With 64k pages, the next larger segment size is 512M. The linux
> kernel also uses different protection flags to cover its code and data.
> Because of this requirement, the vast majority of the kernel code and
> data structures end up being mapped with 64k pages instead of the larger
> pages common with a 4k page kernel.
>
> Recent ARM processors support a contiguous bit in the
> page tables which allows the a TLB to cover a range larger than a
> single PTE if that range is mapped into physically contiguous
> ram.
>
> So, for the kernel its a good idea to set this flag. Some basic
> micro benchmarks show it can significantly reduce the number of
> L1 dTLB refills.
>
> Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>

AFAICT, extending this patch to implement contiguous PMDs for 16 KB
granule kernels should be fairly straightforward, right? Level 2
contiguous block size on 16 KB is 1 GB, which would be useful for the
linear mapping.

> ---
>  arch/arm64/mm/mmu.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 58 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 7711554..ab69a99 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1,3 +1,4 @@
> +
>  /*
>   * Based on arch/arm/mm/mmu.c
>   *
> @@ -103,17 +104,49 @@ static void split_pmd(pmd_t *pmd, pte_t *pte)
>                  * Need to have the least restrictive permissions available
>                  * permissions will be fixed up later
>                  */
> -               set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC));
> +               set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC_CONT));
>                 pfn++;
>         } while (pte++, i++, i < PTRS_PER_PTE);
>  }
>
> +static void clear_cont_pte_range(pte_t *pte, unsigned long addr)
> +{
> +       int i;
> +
> +       pte -= CONT_RANGE_OFFSET(addr);
> +       for (i = 0; i < CONT_PTES; i++) {
> +               if (pte_cont(*pte))
> +                       set_pte(pte, pte_mknoncont(*pte));
> +               pte++;
> +       }
> +       flush_tlb_all();
> +}
> +
> +/*
> + * Given a range of PTEs set the pfn and provided page protection flags
> + */
> +static void __populate_init_pte(pte_t *pte, unsigned long addr,
> +                              unsigned long end, phys_addr_t phys,
> +                              pgprot_t prot)
> +{
> +       unsigned long pfn = __phys_to_pfn(phys);
> +
> +       do {
> +               /* clear all the bits except the pfn, then apply the prot */
> +               set_pte(pte, pfn_pte(pfn, prot));
> +               pte++;
> +               pfn++;
> +               addr += PAGE_SIZE;
> +       } while (addr != end);
> +}
> +
>  static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
> -                                 unsigned long end, unsigned long pfn,
> +                                 unsigned long end, phys_addr_t phys,
>                                   pgprot_t prot,
>                                   phys_addr_t (*pgtable_alloc)(void))
>  {
>         pte_t *pte;
> +       unsigned long next;
>
>         if (pmd_none(*pmd) || pmd_sect(*pmd)) {
>                 phys_addr_t pte_phys = pgtable_alloc();
> @@ -127,10 +160,29 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
>         BUG_ON(pmd_bad(*pmd));
>
>         pte = pte_set_fixmap_offset(pmd, addr);
> +
>         do {
> -               set_pte(pte, pfn_pte(pfn, prot));
> -               pfn++;
> -       } while (pte++, addr += PAGE_SIZE, addr != end);
> +               next = min(end, (addr + CONT_SIZE) & CONT_MASK);
> +               if (((addr | next | phys) & ~CONT_MASK) == 0) {
> +                       /* a block of CONT_PTES  */
> +                       __populate_init_pte(pte, addr, next, phys,
> +                                           prot | __pgprot(PTE_CONT));
> +               } else {
> +                       /*
> +                        * If the range being split is already inside of a
> +                        * contiguous range but this PTE isn't going to be
> +                        * contiguous, then we want to unmark the adjacent
> +                        * ranges, then update the portion of the range we
> +                        * are interrested in.
> +                        */
> +                       clear_cont_pte_range(pte, addr);
> +                       __populate_init_pte(pte, addr, next, phys, prot);
> +               }
> +
> +               pte += (next - addr) >> PAGE_SHIFT;
> +               phys += next - addr;
> +               addr = next;
> +       } while (addr != end);
>
>         pte_clear_fixmap();
>  }
> @@ -194,7 +246,7 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
>                                 }
>                         }
>                 } else {
> -                       alloc_init_pte(pmd, addr, next, __phys_to_pfn(phys),
> +                       alloc_init_pte(pmd, addr, next, phys,
>                                        prot, pgtable_alloc);
>                 }
>                 phys += next - addr;
> --
> 2.4.3
>


From sergei.shtylyov at cogentembedded.com  Sat Feb 13 08:54:25 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sat, 13 Feb 2016 19:54:25 +0300
Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <56BF5FC1.40000@cogentembedded.com>

Hello.

On 2/13/2016 2:20 AM, tchalamarla at caviumnetworks.com wrote:

> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>
> Due to Errata in ThunderX, HOST_IRQ_STAT should be
> cleared before leaving the interrupt handler.
> The patch attempts to satisfy the need.
>
> Changes from V1:
> 	- Rebased on top of libata/for-4.6
>          - Moved ThunderX intr handler to new file
>
> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> ---
>   drivers/ata/Makefile        |  2 +-
>   drivers/ata/ahci.c          |  3 ++
>   drivers/ata/ahci.h          |  1 +
>   drivers/ata/ahci_thunderx.c | 73 +++++++++++++++++++++++++++++++++++++++++++++
>   4 files changed, 78 insertions(+), 1 deletion(-)
>   create mode 100644 drivers/ata/ahci_thunderx.c
>
> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
> index 1857952..a36e70d 100644
> --- a/drivers/ata/Makefile
> +++ b/drivers/ata/Makefile
> @@ -2,7 +2,7 @@
>   obj-$(CONFIG_ATA)		+= libata.o
>
>   # non-SFF interface
> -obj-$(CONFIG_SATA_AHCI)		+= ahci.o libahci.o
> +obj-$(CONFIG_SATA_AHCI)		+= ahci.o libahci.o ahci_thunderx.o
>   obj-$(CONFIG_SATA_ACARD_AHCI)	+= acard-ahci.o libahci.o
>   obj-$(CONFIG_SATA_AHCI_PLATFORM) += ahci_platform.o libahci.o libahci_platform.o
>   obj-$(CONFIG_SATA_FSL)		+= sata_fsl.o
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 546a369..76e310e 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1560,6 +1560,9 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>   	if (ahci_broken_devslp(pdev))
>   		hpriv->flags |= AHCI_HFLAG_NO_DEVSLP;
>
> +	if (pdev->vendor == 0x177d && pdev->device == 0xa01c)
> +		ahci_thunderx_init(&pdev->dev, hpriv);
> +
>   	/* save initial config */
>   	ahci_pci_save_initial_config(pdev, hpriv);
>
> diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
> index 167ba7e..77ae20d 100644
> --- a/drivers/ata/ahci.h
> +++ b/drivers/ata/ahci.h
> @@ -425,6 +425,7 @@ void ahci_print_info(struct ata_host *host, const char *scc_s);
>   int ahci_host_activate(struct ata_host *host, struct scsi_host_template *sht);
>   void ahci_error_handler(struct ata_port *ap);
>   u32 ahci_handle_port_intr(struct ata_host *host, u32 irq_masked);
> +void ahci_thunderx_init(struct device *dev, struct ahci_host_priv *hpriv);
>
>   static inline void __iomem *__ahci_port_base(struct ata_host *host,
>   					     unsigned int port_no)
> diff --git a/drivers/ata/ahci_thunderx.c b/drivers/ata/ahci_thunderx.c
> new file mode 100644
> index 0000000..223e170
> --- /dev/null
> +++ b/drivers/ata/ahci_thunderx.c
> @@ -0,0 +1,73 @@
> +/*
> + * SATA glue for Cavium Thunder SOCs.
> + *
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file "COPYING" in the main directory of this archive
> + * for more details.
> + *
> + * Copyright (C) 2010-2016 Cavium Networks
> + *
> + */
> +
> +#include <linux/module.h>
> +#include "ahci.h"
> +#include "libata.h"
> +
> +static irqreturn_t ahci_thunderx_irq_intr(int irq, void *dev_instance)

    *_irq_intr() is a bit tautological.

> +{
> +	struct ata_host *host = dev_instance;
> +	struct ahci_host_priv *hpriv;
> +	unsigned int rc = 0;
> +	void __iomem *mmio;
> +	u32 irq_stat, irq_masked;
> +	unsigned int handled = 1;
> +
> +	VPRINTK("ENTER\n");
> +
> +	hpriv = host->private_data;
> +	mmio = hpriv->mmio;

    Why not do this in the initializers?

> +
> +	/* sigh.  0xffffffff is a valid return from h/w */
> +	irq_stat = readl(mmio + HOST_IRQ_STAT);
> +	if (!irq_stat)
> +		return IRQ_NONE;
> +redo:

    Closer to the next statement, please.

> +
> +	irq_masked = irq_stat & hpriv->port_map;
> +
> +	spin_lock(&host->lock);
> +
> +	rc = ahci_handle_port_intr(host, irq_masked);
> +

    No need for empty line here.

> +	if (!rc)
> +		handled = 0;

    Doesn't this override the valid result in case of looping?

> +
> +	writel(irq_stat, mmio + HOST_IRQ_STAT);
> +
> +	/* Due to ERRATA#22536, ThunderX need to handle
> +	 * HOST_IRQ_STAT differently.
> +	 * Work around is to make sure all pending IRQs
> +	 * are served before leaving handler
> +	 */
> +	irq_stat = readl(mmio + HOST_IRQ_STAT);
> +
> +	spin_unlock(&host->lock);
> +
> +	if (irq_stat)
> +		goto redo;

    You can have a *do*/*while* loop, no need for *goto*.

> +
> +	VPRINTK("EXIT\n");
> +
> +	return IRQ_RETVAL(handled);
> +}
> +
> +void ahci_thunderx_init(struct device *dev, struct ahci_host_priv *hpriv)
> +{
> +	hpriv->irq_handler = ahci_thunderx_irq_intr;
> +}
> +EXPORT_SYMBOL_GPL(ahci_thunderx_init);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Cavium, Inc. <support at cavium.com>");
> +MODULE_DESCRIPTION("Cavium Inc. ThunderX sata config.");

MBR, Sergei



From mcoquelin.stm32 at gmail.com  Sat Feb 13 09:14:14 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Sat, 13 Feb 2016 18:14:14 +0100
Subject: [PATCH v4 4/9] pinctrl: Add STM32 MCUs support
In-Reply-To: <CACRpkdY1E9rLwG-aXWSB7d32rhvmng+4QbVX7E0WR6aqP0oFaw@mail.gmail.com>
References: <1452773795-24216-1-git-send-email-mcoquelin.stm32@gmail.com>
 <1452773795-24216-5-git-send-email-mcoquelin.stm32@gmail.com>
 <CACRpkdaBcP6fC5Oxn+d1WPdHq1FtwMkf8Ap5VDLQFg-5UwEBAw@mail.gmail.com>
 <2151471.Wut3mQ9SS7@wuerfel>
 <CALszF6DTpcU8jFwA0HL8LpkxfO5ZOdFmpHBUxA7WfYgAj_uFhg@mail.gmail.com>
 <56AF4AEB.40109@st.com>
 <CACRpkdY1E9rLwG-aXWSB7d32rhvmng+4QbVX7E0WR6aqP0oFaw@mail.gmail.com>
Message-ID: <56BF6466.90104@gmail.com>



On 02/13/2016 03:48 PM, Linus Walleij wrote:
> On Mon, Feb 1, 2016 at 1:09 PM, Maxime Coquelin <maxime.coquelin at st.com> wrote:
>> On 02/01/2016 11:39 AM, Maxime Coquelin wrote:
>>> 2016-02-01 11:21 GMT+01:00 Arnd Bergmann <arnd at arndb.de>:
>
>>>> drivers/pinctrl/stm32/pinctrl-stm32.c:26:47: fatal error:
>>>> dt-bindings/pinctrl/pinctrl-stm32.h: No such file or directory
>>>
>>> Right, I missed to notify this dependency to Linus, sorry about that.
>>> This dependency is no more needed, so I could just move the macros to
>>> the driver side.
>>>
>>> Note that I also noticed a breakage at build time due to field
>>> renaming in gpio_chip structure (dev -> parent).
>>>
>>> I propose to rebase the series and move the defines into the driver.
>>> Is it ok for you?
>>>
>> I have rebased the series, taking care to fix the mentioned problems.
>>
>> Linus, do you confirm you will revert STM32 pinctrl patches from your tree?
>
> I guess the other fixes removes the need to do this.
Exactly, all should be fine now.

>
> Sorry for not staying on top of this issue, I was swamped with mail
> and had a hard time prioritizing :(

No worries!

Thanks,
Maxime


From jchandra at broadcom.com  Sat Feb 13 10:46:33 2016
From: jchandra at broadcom.com (Jayachandran C)
Date: Sun, 14 Feb 2016 00:16:33 +0530
Subject: [PATCH 2/4] dt-bindings: Add documentation for Broadcom Vulcan
In-Reply-To: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
References: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
Message-ID: <1455389195-31870-3-git-send-email-jchandra@broadcom.com>

Update arm/cpus.txt to add brcm,vulcan CPU. Add documentation
for Broadcom vulcan boards in arm/bcm/brcm,vulcan.txt

Signed-off-by: Jayachandran C <jchandra at broadcom.com>
---
 Documentation/devicetree/bindings/arm/bcm/brcm,vulcan.txt | 9 +++++++++
 Documentation/devicetree/bindings/arm/cpus.txt            | 1 +
 2 files changed, 10 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,vulcan.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,vulcan.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,vulcan.txt
new file mode 100644
index 0000000..dac9eb5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,vulcan.txt
@@ -0,0 +1,9 @@
+Broadcom Vulcan device tree bindings
+------------------------------------
+
+Boards with Broadcom Vulcan shall have the following properties:
+
+Required root node property:
+
+Vulcan Evaluation Board
+compatible = "brcm,vulcan-eval", "brcm,vulcan";
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index ae9be07..bc43ad7 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -167,6 +167,7 @@ nodes to be present and contain the properties described below.
 			    "arm,cortex-r5"
 			    "arm,cortex-r7"
 			    "brcm,brahma-b15"
+			    "brcm,vulcan"
 			    "cavium,thunder"
 			    "faraday,fa526"
 			    "intel,sa110"
-- 
1.9.1



From jchandra at broadcom.com  Sat Feb 13 10:46:31 2016
From: jchandra at broadcom.com (Jayachandran C)
Date: Sun, 14 Feb 2016 00:16:31 +0530
Subject: [PATCH 0/4] Support for Broadcom Vulcan ARM64 processor
Message-ID: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>

This patchset adds support for Broadcom's Vulcan CPU.

The changes are to add the a device tree (dtsi) for the
Vulcan SoC, a device tree(dts) for developer platform
and related documentation.

Review comments and suggestions are very welcome.

Thanks,
JC.

Jayachandran C (3):
  dt-bindings: Add documentation for Broadcom Vulcan
  arm64: defconfig: Add Broadcom Vulcan to defconfig
  arm64: cputype info for Broadcom Vulcan

Zi Shen Lim (1):
  arm64: Broadcom Vulcan support

 .../devicetree/bindings/arm/bcm/brcm,vulcan.txt    |   9 ++
 Documentation/devicetree/bindings/arm/cpus.txt     |   1 +
 arch/arm64/Kconfig.platforms                       |   5 +
 arch/arm64/boot/dts/broadcom/Makefile              |   1 +
 arch/arm64/boot/dts/broadcom/brcm-vulcan-eval.dts  |  33 +++++
 arch/arm64/boot/dts/broadcom/brcm-vulcan.dtsi      | 146 +++++++++++++++++++++
 arch/arm64/configs/defconfig                       |   1 +
 arch/arm64/include/asm/cputype.h                   |   2 +
 8 files changed, 198 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,vulcan.txt
 create mode 100644 arch/arm64/boot/dts/broadcom/brcm-vulcan-eval.dts
 create mode 100644 arch/arm64/boot/dts/broadcom/brcm-vulcan.dtsi

-- 
1.9.1



From jchandra at broadcom.com  Sat Feb 13 10:46:34 2016
From: jchandra at broadcom.com (Jayachandran C)
Date: Sun, 14 Feb 2016 00:16:34 +0530
Subject: [PATCH 3/4] arm64: defconfig: Add Broadcom Vulcan to defconfig
In-Reply-To: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
References: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
Message-ID: <1455389195-31870-4-git-send-email-jchandra@broadcom.com>

Enable Broadcom Vulcan support in arm64 default configuration. This will
build the device tree needed to boot on a Broadcom Vulcan board.

Signed-off-by: Jayachandran C <jchandra at broadcom.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 86581f7..6c1b3a6 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -47,6 +47,7 @@ CONFIG_ARCH_SPRD=y
 CONFIG_ARCH_THUNDER=y
 CONFIG_ARCH_UNIPHIER=y
 CONFIG_ARCH_VEXPRESS=y
+CONFIG_ARCH_VULCAN=y
 CONFIG_ARCH_XGENE=y
 CONFIG_ARCH_ZYNQMP=y
 CONFIG_PCI=y
-- 
1.9.1



From jchandra at broadcom.com  Sat Feb 13 10:46:35 2016
From: jchandra at broadcom.com (Jayachandran C)
Date: Sun, 14 Feb 2016 00:16:35 +0530
Subject: [PATCH 4/4] arm64: cputype info for Broadcom Vulcan
In-Reply-To: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
References: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
Message-ID: <1455389195-31870-5-git-send-email-jchandra@broadcom.com>

Add Broadcom Vulcan implementor ID and part ID in cputype.h. This is
to document the values.

Signed-off-by: Jayachandran C <jchandra at broadcom.com>
---
 arch/arm64/include/asm/cputype.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 1a59493..3725d59 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -65,6 +65,7 @@
 #define ARM_CPU_IMP_ARM			0x41
 #define ARM_CPU_IMP_APM			0x50
 #define ARM_CPU_IMP_CAVIUM		0x43
+#define ARM_CPU_IMP_BRCM		0x42
 
 #define ARM_CPU_PART_AEM_V8		0xD0F
 #define ARM_CPU_PART_FOUNDATION		0xD00
@@ -74,6 +75,7 @@
 #define APM_CPU_PART_POTENZA		0x000
 
 #define CAVIUM_CPU_PART_THUNDERX	0x0A1
+#define BRCM_CPU_PART_VULCAN		0x516
 
 #ifndef __ASSEMBLY__
 
-- 
1.9.1



From jchandra at broadcom.com  Sat Feb 13 10:46:32 2016
From: jchandra at broadcom.com (Jayachandran C)
Date: Sun, 14 Feb 2016 00:16:32 +0530
Subject: [PATCH 1/4] arm64: Broadcom Vulcan support
In-Reply-To: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
References: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
Message-ID: <1455389195-31870-2-git-send-email-jchandra@broadcom.com>

From: Zi Shen Lim <zlim at broadcom.com>

Add a configuration option and a device tree for Broadcom's Vulcan
ARM64 processor. brcm-vulcan.dtsi has the on-chip blocks like the
PCIe controller, GICv3 with ITS, PMU, system timer and pl011 UART.
brcm-vulcan-eval.dts has definitions for a basic evaluation board.
The firmware supports PSCI 0.2 for cpu wakeup.

Signed-off-by: Zi Shen Lim <zlim at broadcom.com>
[ updated and split dts - jchandra at broadcom.com ]
Signed-off-by: Jayachandran C <jchandra at broadcom.com>
---
 arch/arm64/Kconfig.platforms                      |   5 +
 arch/arm64/boot/dts/broadcom/Makefile             |   1 +
 arch/arm64/boot/dts/broadcom/brcm-vulcan-eval.dts |  33 +++++
 arch/arm64/boot/dts/broadcom/brcm-vulcan.dtsi     | 146 ++++++++++++++++++++++
 4 files changed, 185 insertions(+)
 create mode 100644 arch/arm64/boot/dts/broadcom/brcm-vulcan-eval.dts
 create mode 100644 arch/arm64/boot/dts/broadcom/brcm-vulcan.dtsi

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f6..8718f18 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -131,6 +131,11 @@ config ARCH_VEXPRESS
 	  This enables support for the ARMv8 software model (Versatile
 	  Express).
 
+config ARCH_VULCAN
+	bool "Broadcom Vulcan SOC Family"
+	help
+	  This enables support for Broadcom Vulcan SoC Family
+
 config ARCH_XGENE
 	bool "AppliedMicro X-Gene SOC Family"
 	help
diff --git a/arch/arm64/boot/dts/broadcom/Makefile b/arch/arm64/boot/dts/broadcom/Makefile
index e21fe66..31219e5 100644
--- a/arch/arm64/boot/dts/broadcom/Makefile
+++ b/arch/arm64/boot/dts/broadcom/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb
+dtb-$(CONFIG_ARCH_VULCAN) += brcm-vulcan-eval.dtb
 
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
diff --git a/arch/arm64/boot/dts/broadcom/brcm-vulcan-eval.dts b/arch/arm64/boot/dts/broadcom/brcm-vulcan-eval.dts
new file mode 100644
index 0000000..2ca5562
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/brcm-vulcan-eval.dts
@@ -0,0 +1,33 @@
+/*
+ * dts file for Broadcom (BRCM) Vulcan Eval Platform
+ *
+ * Copyright (C) 2013-2016, Broadcom Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+/dts-v1/;
+
+#include "brcm-vulcan.dtsi"
+
+/ {
+	model = "Broadcom Vulcan Eval Platform";
+	compatible = "brcm,vulcan-eval", "brcm,vulcan";
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x80000000 0x0 0x80000000>,  /* 2G @ 2G  */
+		      <0x00000008 0x80000000 0x0 0x80000000>;  /* 2G @ 34G */
+	};
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
diff --git a/arch/arm64/boot/dts/broadcom/brcm-vulcan.dtsi b/arch/arm64/boot/dts/broadcom/brcm-vulcan.dtsi
new file mode 100644
index 0000000..0f9f618
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/brcm-vulcan.dtsi
@@ -0,0 +1,146 @@
+/*
+ * dtsi file for Broadcom (BRCM) Vulcan processor
+ *
+ * Copyright (C) 2013-2016, Broadcom Corporation.
+ * Author: Zi Shen Lim <zlim at broadcom.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/memreserve/ 0x80000000 0x00010000;
+
+/ {
+	model = "Broadcom Vulcan";
+	compatible = "brcm,vulcan";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	/* just 4 cpus now, 128 needed in full config */
+	cpus {
+		#address-cells = <0x2>;
+		#size-cells = <0x0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "brcm,vulcan", "arm,armv8";
+			reg = <0x0 0x0>;
+			enable-method = "psci";
+		};
+
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "brcm,vulcan", "arm,armv8";
+			reg = <0x0 0x1>;
+			enable-method = "psci";
+		};
+
+		cpu at 2 {
+			device_type = "cpu";
+			compatible = "brcm,vulcan", "arm,armv8";
+			reg = <0x0 0x2>;
+			enable-method = "psci";
+		};
+
+		cpu at 3 {
+			device_type = "cpu";
+			compatible = "brcm,vulcan", "arm,armv8";
+			reg = <0x0 0x3>;
+			enable-method = "psci";
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	gic: interrupt-controller at 400080000 {
+		compatible = "arm,gic-v3";
+		#interrupt-cells = <3>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		interrupt-controller;
+		#redistributor-regions = <1>;
+		reg = <0x04 0x00080000 0x0 0x20000>,	/* GICD */
+		      <0x04 0x01000000 0x0 0x1000000>;	/* GICR */
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+
+		gicits: gic-its at 40010000 {
+			compatible = "arm,gic-v3-its";
+			msi-controller;
+			reg = <0x04 0x00100000 0x0 0x20000>;	/* GIC ITS */
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	pmu {
+		compatible = "arm,armv8-pmuv3";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>; /* PMU overflow */
+	};
+
+	clk125mhz: uart_clk125mhz {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <125000000>;
+		clock-output-names = "clk125mhz";
+	};
+
+	pci {
+		compatible = "pci-host-ecam-generic";
+		device_type = "pci";
+		#interrupt-cells = <1>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+
+		/* ECAM at 0x3000_0000 - 0x4000_0000 */
+		reg = <0x0 0x30000000  0x0 0x10000000>;
+		reg-names = "PCI ECAM";
+
+			  /* IO 0x4000_0000 - 0x4001_0000 */
+		ranges = <0x01000000 0 0x40000000 0 0x40000000 0 0x00010000
+			  /* MEM 0x4800_0000 - 0x5000_0000 */
+			  0x02000000 0 0x48000000 0 0x48000000 0 0x08000000
+			  /* MEM64 pref 0x6_0000_0000 - 0x7_0000_0000 */
+			  0x43000000 6 0x00000000 6 0x00000000 1 0x00000000>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map =
+		      /* addr  pin  ic   icaddr  icintr */
+			<0 0 0  1  &gic   0 0    GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH
+			 0 0 0  2  &gic   0 0    GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH
+			 0 0 0  3  &gic   0 0    GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH
+			 0 0 0  4  &gic   0 0    GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+		msi-parent = <&gicits>;
+		dma-coherent;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		uart0: serial at 402020000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x04 0x02020000 0x0 0x1000>;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clk125mhz>;
+			clock-names = "apb_pclk";
+		};
+	};
+
+};
-- 
1.9.1



From linus.walleij at linaro.org  Sat Feb 13 11:07:02 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 13 Feb 2016 20:07:02 +0100
Subject: [PATCH 2/2] dt-bindings: Add TPO TPG110 binding
In-Reply-To: <20160202162833.GB4918@ulmo>
References: <1454316643-3931-1-git-send-email-linus.walleij@linaro.org>
 <20160202162833.GB4918@ulmo>
Message-ID: <CACRpkdY77MsH5ArGo7Wh8qhUNYJhWHLOZRN4j=4YQKYsvVbnmQ@mail.gmail.com>

On Tue, Feb 2, 2016 at 5:28 PM, Thierry Reding <thierry.reding at gmail.com> wrote:
> On Mon, Feb 01, 2016 at 09:50:43AM +0100, Linus Walleij wrote:

>> +This binding builds on the DPI bindings, adding a few properties
>> +as a superset of a DPI. See panel-dpi.txt for the required DPI
>> +bindings.
>
> It is unfortunate that we have these two types of bindings, one used by
> some of the legacy fbdev drivers and the other by DRM/KMS drivers. There
> isn't really much we can do about it, though, as far as I can see.

I wasn't aware that they were any different. Where is the equivalent
binding for DRM/KMS panels?

I guess one must have been merged first and the second one screwed
up by not reusing the first one :(

> This panel is used with an fbdev driver, right?

Yes.

I don't know if I will be able to convert the AMBA CLCD driver from
fbdev to DRM/KMS but I was hoping I would not have to change the
DT to redescribe the same hardware for that, but now it sounds
like that is a consequence...

Yours,
Linus Walleij


From geert at linux-m68k.org  Sat Feb 13 12:23:47 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Sat, 13 Feb 2016 21:23:47 +0100
Subject: [PATCH 01/68] ARM: dts: gose: Add GPIO keys to DT
In-Reply-To: <d7d5974b156e2ef7436483de00ccada5987c9d31.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
 <d7d5974b156e2ef7436483de00ccada5987c9d31.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <CAMuHMdVefum3YbaxhMX_0hHrmTFYU-pWYZTwSUveQDLFArLdYw@mail.gmail.com>

On Fri, Feb 12, 2016 at 8:04 PM, Simon Horman
<horms+renesas at verge.net.au> wrote:
> Instantiate the GPIO keys in the gose device tree.
>
> Based on similar work for the koelsch board by Laurent Pinchart.
>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> Tested-by: Magnus Damm <damm+renesas at opensource.se>
> ---
>  arch/arm/boot/dts/r8a7793-gose.dts | 82 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 82 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
> index baa59fe84298..ccbc1c66cc6c 100644
> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> @@ -31,6 +31,88 @@
>                 device_type = "memory";
>                 reg = <0 0x40000000 0 0x40000000>;
>         };
> +
> +       gpio-keys {
> +               compatible = "gpio-keys";
> +
> +               key-1 {
> +                       gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
> +                       linux,code = <KEY_1>;
> +                       label = "SW2-1";
> +                       gpio-key,wakeup;

In the mean time, "gpio-key,wakeup" has been deprecated in favor of
"wakeup-source".

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From nicolas.pitre at linaro.org  Sat Feb 13 13:57:41 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Sat, 13 Feb 2016 16:57:41 -0500 (EST)
Subject: [PATCH] [media] zl10353: use div_u64 instead of do_div
In-Reply-To: <CAKv+Gu8dFz28tGgQTv+WYAvKpeiFXaj8JANUFtOJwKPRsB8F5A@mail.gmail.com>
References: <1455287246-3540549-1-git-send-email-arnd@arndb.de>
 <2712691.b9gkR7KMX7@wuerfel>
 <alpine.LFD.2.20.1602121305180.13632@knanqh.ubzr>
 <6737272.LXr2g355Yt@wuerfel>
 <CAKv+Gu8dFz28tGgQTv+WYAvKpeiFXaj8JANUFtOJwKPRsB8F5A@mail.gmail.com>
Message-ID: <alpine.LFD.2.20.1602131652560.13632@knanqh.ubzr>

On Sat, 13 Feb 2016, Ard Biesheuvel wrote:

> On 12 February 2016 at 22:01, Arnd Bergmann <arnd at arndb.de> wrote:
> > However, I did stumble over an older patch I did now, which I could
> > not remember what it was good for. It does fix the problem, and
> > it seems to be a better solution.
> >
> >         Arnd
> >
> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > index b5acbb404854..b5ff9881bef8 100644
> > --- a/include/linux/compiler.h
> > +++ b/include/linux/compiler.h
> > @@ -148,7 +148,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
> >   */
> >  #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
> >  #define __trace_if(cond) \
> > -       if (__builtin_constant_p((cond)) ? !!(cond) :                   \
> > +       if (__builtin_constant_p(!!(cond)) ? !!(cond) :                 \
> >         ({                                                              \
> >                 int ______r;                                            \
> >                 static struct ftrace_branch_data                        \
> >
> 
> I remember seeing this patch, but I don't remember the exact context.
> But when you think about it, !!cond can be a build time constant even
> if cond is not, as long as you can prove statically that cond != 0. So

You're right.  I just tested it and to my surprise gcc is smart enough 
to figure that case out.

> I think this change is obviously correct, and an improvement since it
> will remove the profiling overhead of branches that are not true
> branches in the first place.

Indeed.


Nicolas


From sergei.shtylyov at cogentembedded.com  Sat Feb 13 14:26:34 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Sun, 14 Feb 2016 01:26:34 +0300
Subject: [PATCH] ARM: dts: porter: remove enable prop from HS-USB device node
In-Reply-To: <1674850.BZpGW9kEud@wasted.cogentembedded.com>
References: <1674850.BZpGW9kEud@wasted.cogentembedded.com>
Message-ID: <2684686.0L09MeB6pA@wasted.cogentembedded.com>

In  the final versions of the Porter board (called "PORTER_C") Renesas
decided to get rid  of the Maxim Integrated MAX3355 OTG chip and didn't
add any other provision to differ the host/gadget mode, so we'll have to
remove  no longer valid "renesas,enable-gpio" property from the HS-USB
device node.  Hopefully, the earlier revisions of the board were never
seen in the wild...

Fixes: c794f6a09a25 ("ARM: shmobile: porter: add HS-USB DT support")
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
This patch is against the 'master' branch of Simon Horman's 'renesas.git' repo.

 arch/arm/boot/dts/r8a7791-porter.dts |    1 -
 1 file changed, 1 deletion(-)

Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -283,7 +283,6 @@
 	pinctrl-names = "default";
 
 	status = "okay";
-	renesas,enable-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;
 };
 
 &usbphy {



From linus.walleij at linaro.org  Sat Feb 13 14:52:42 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 13 Feb 2016 23:52:42 +0100
Subject: [PATCH v2] pinctrl: mvebu: fix num_settings in mpp group
 assignment
In-Reply-To: <1454366903-7038-1-git-send-email-sebastian.hesselbarth@gmail.com>
References: <1453844952-28292-1-git-send-email-sebastian.hesselbarth@gmail.com>
 <1454366903-7038-1-git-send-email-sebastian.hesselbarth@gmail.com>
Message-ID: <CACRpkdaPwbood17LBS-PGQsDSe24jZnT_u8ySuJWWkSiUQNMmQ@mail.gmail.com>

On Mon, Feb 1, 2016 at 11:48 PM, Sebastian Hesselbarth
<sebastian.hesselbarth at gmail.com> wrote:

> When assigning mpp settings from static mpp modes to mpp groups,
> we do not want any groups that have no supported setting for a
> specific Kirkwood variant. However, when there is at least a
> single supported setting, we need to assign the number of all
> settings in this mode to grp->num_settings as we are reusing
> the static modes table.
>
> Fixes: 0581b16b1840 ("pinctrl: mvebu: complain about missing group after checking variant")
> Reported-by: Aaro Koskinen <aaro.koskinen at iki.fi>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
> --
> Changelog:
> v1->v2:
> - Chose a less intrusive fix by adding supp_settings variable
>   instead of looping over the settings twice.

Patch applied with Aaro's Test tag.

Yours,
Linus Walleij


From fijam at archlinux.us  Sat Feb 13 16:09:57 2016
From: fijam at archlinux.us (JM)
Date: Sun, 14 Feb 2016 01:09:57 +0100
Subject: marvell_cesa fails to register on kirkwood (88F6282)
In-Reply-To: <20160208172302.GQ10826@n2100.arm.linux.org.uk>
References: <20160205090246.GE32272@lunn.ch>
 <20160205112907.796afb05@bbrezillon>
 <CAKzmTe20fT8BcRaDaf2gz92KMAK0kEUkaD-kPq_cPF1WKBdroA@mail.gmail.com>
 <87vb632maf.fsf@free-electrons.com>
 <CAKzmTe1AqNQwjcsAULotd010NXuk1AYjj5p6UoqT_Zu=BCHdcw@mail.gmail.com>
 <87mvrf2l6p.fsf@free-electrons.com> <87io232kat.fsf@free-electrons.com>
 <8760y2vqje.fsf@natisbad.org> <87twlmdg2b.fsf@natisbad.org>
 <CAKzmTe24iz1Ka7Kkke=ZTVbDGZxxDjBH0m2iEVCQOGuuEpi4Gg@mail.gmail.com>
 <20160208172302.GQ10826@n2100.arm.linux.org.uk>
Message-ID: <CAKzmTe01UShsocA7VbZziWWqt2k-5yJwYH0MnddXHT+s3Oni=w@mail.gmail.com>

I have rebuilt the kernel again, trying to get close to Arnaud's Duov2
config, and amazingly, it works!

$ dmesg | grep -i cesa
[    8.158636] marvell-cesa f1030000.crypto: CESA device successfully registered

I have all the goodies in /proc/crypto as well.

So apparently the bug lurks somewhere in the difference between:

http://heap.ovh/files/config-4.4.1.vanilla <- debian's config
http://heap.ovh/files/config-kirkwood-new <- duov2-like config

I could try to narrow it down, but I can only build natively, and I am
quite clueless as to where to start, so it would take some time...

Best regards,
Jan

On Mon, Feb 8, 2016 at 6:23 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Sat, Feb 06, 2016 at 04:14:49PM +0100, JM wrote:
>> On Fri, Feb 5, 2016 at 10:04 PM, Arnaud Ebalard <arno at natisbad.org> wrote:
>> > Hi,
>> >
>> >> I'll try and do the same now w/ CESA support compiled as module to see
>> >> what I get. I'll keep you posted.
>> >
>> > root at mood:~# insmod /tmp/marvell-cesa.ko
>> > [  573.897977] marvell-cesa f1030000.crypto: CESA device successfully registered
>> >
>> > root at mood:~# uname -a
>> > Linux mood 4.4.0.duov2 #2 Fri Feb 5 21:42:49 CET 2016 armv5tel GNU/Linux
>> >
>> > root at mood:~# zcat /proc/config.gz | grep -i CESA
>> > # CONFIG_CRYPTO_DEV_MV_CESA is not set
>> > CONFIG_CRYPTO_DEV_MARVELL_CESA=m
>> >
>> > Cheers,
>> >
>> > a+
>> >
>> > ps: my config is temporarily at http://natisbad.org/config-duov2-cesa
>>
>> I've built a vanilla 4.4.1 kernel image without any debian-specific
>> patches but using the same oldconfig
>> (http://heap.ovh/files/config-4.4.1.vanilla).
>>
>> # uname -a
>> Linux yukikaze 4.4.1.vanilla #1 Sat Feb 6 14:18:19 CET 2016 armv5tel GNU/Linux
>>
>> # modprobe marvell_cesa allhwsupport=1
>>
>> # dmesg | tail -n1
>> [  116.972828] marvell-cesa: probe of f1030000.crypto failed with error -12
>>
>> The dtb hasn't changed:
>> # diff -s kirkwood-ts219-6282.dtb dtb-4.4.1.vanilla
>> Files kirkwood-ts219-6282.dtb and dtb-4.4.1.vanilla are identical
>>
>> I am also attaching lsmod: http://heap.ovh/files/lsmod-vanilla-4.4.1
>> and full dmesg: http://heap.ovh/files/dmesg-vanilla-4.4.1
>>
>> Perhaps I am missing something obvious? I suppose the next step would
>> be to build a minimal kernel based on the config for the duov2?
>
> As you have built your own kernel, may I suggest that you add some
> debug code into mv_cesa_dev_dma_init(), mv_cesa_get_sram(), and
> mv_cesa_probe() to print which of the many locations that returns
> -ENOMEM is triggering the above error.
>
> In passing, I notice that:
>
>         cesa->regs = devm_ioremap_resource(dev, res);
>         if (IS_ERR(cesa->regs))
>                 return -ENOMEM;
>
> is wrong.  devm_ioremap_resource() returns an errno-encoded pointer
> which should be used to report the error number.  This should be:
>
>         cesa->regs = devm_ioremap_resource(dev, res);
>         if (IS_ERR(cesa->regs))
>                 return PTR_ERR(cesa->regs);
>
> --
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.


From bjorn.andersson at linaro.org  Sat Feb 13 17:35:19 2016
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Sat, 13 Feb 2016 17:35:19 -0800
Subject: [PATCH] MAINTAINERS: Add co-maintainer for remoteproc subsystems
Message-ID: <1455413719-22412-1-git-send-email-bjorn.andersson@linaro.org>

Add myself as co-maintainer for the remote processor related subsystems,
as agreed with Ohad.

Signed-off-by: Bjorn Andersson <bjorn.andersson at linaro.org>
---
 MAINTAINERS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4ebe2e886d36..f51056b02fcd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4989,6 +4989,7 @@ F:	include/linux/hw_random.h
 
 HARDWARE SPINLOCK CORE
 M:	Ohad Ben-Cohen <ohad at wizery.com>
+M:	Bjorn Andersson <bjorn.andersson at linaro.org>
 S:	Maintained
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
 F:	Documentation/hwspinlock.txt
@@ -9170,6 +9171,7 @@ F:	include/linux/regmap.h
 
 REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM
 M:	Ohad Ben-Cohen <ohad at wizery.com>
+M:	Bjorn Andersson <bjorn.andersson at linaro.org>
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
 S:	Maintained
 F:	drivers/remoteproc/
@@ -9178,6 +9180,7 @@ F:	include/linux/remoteproc.h
 
 REMOTE PROCESSOR MESSAGING (RPMSG) SUBSYSTEM
 M:	Ohad Ben-Cohen <ohad at wizery.com>
+M:	Bjorn Andersson <bjorn.andersson at linaro.org>
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git
 S:	Maintained
 F:	drivers/rpmsg/
-- 
2.5.0



From shawnguo at kernel.org  Sat Feb 13 17:57:24 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 09:57:24 +0800
Subject: [PATCH v10 7/8] ARM: dts: imx25: Add TSC and ADC support
In-Reply-To: <1450101234-2191-8-git-send-email-mpa@pengutronix.de>
References: <1450101234-2191-1-git-send-email-mpa@pengutronix.de>
 <1450101234-2191-8-git-send-email-mpa@pengutronix.de>
Message-ID: <20160214015724.GA6756@tiger>

On Mon, Dec 14, 2015 at 02:53:53PM +0100, Markus Pargmann wrote:
> From: Denis Carikli <denis at eukrea.com>
> 
> Signed-off-by: Denis Carikli <denis at eukrea.com>
> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>

Applied #7 and #8, thanks.


From shawnguo at kernel.org  Sat Feb 13 18:10:02 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 10:10:02 +0800
Subject: [PATCH] PCI: layerscape: add ls2085a compatible
In-Reply-To: <VI1PR04MB1230AA5CAEEEE0D4AD8E3DF288D20@VI1PR04MB1230.eurprd04.prod.outlook.com>
References: <1453915925-19198-1-git-send-email-yang.shi@linaro.org>
 <56A906F4.3050809@linaro.org> <20160204223711.GE7031@localhost>
 <56B3E386.8010002@linaro.org>
 <VI1PR04MB1230AA5CAEEEE0D4AD8E3DF288D20@VI1PR04MB1230.eurprd04.prod.outlook.com>
Message-ID: <20160214021002.GB6756@tiger>

On Fri, Feb 05, 2016 at 05:36:28AM +0000, Bhupesh Sharma wrote:
> > From: Shi, Yang
> > Sent: Friday, February 05, 2016 5:19 AM
> > 
> > On 2/4/2016 2:37 PM, Bjorn Helgaas wrote:
> > > On Wed, Jan 27, 2016 at 10:05:40AM -0800, Shi, Yang wrote:
> > >> Correct FSL folks email address to nxp.com, sorry for the
> > inconvenience.
> > >
> > > Do we need some MAINTAINERS updates in addition to the ack for this
> > patch?
> > > I see a bunch of @freescale.com addresses in MAINTAINERS.
> > 
> > I guess so if the @freescale.com address is not valid anymore.
> 
> All @freescale.com address have shifted to @nxp.com.
> 
> Leo, Minghuan - can you kindly review this patch.
> 
> Shawn - can you take this through your tree, once Leo and Minghuan have reviewed the code.

This is a patch that should go through PCI subsystem tree.

Shawn

> > >> On 1/27/2016 9:32 AM, Yang Shi wrote:
> > >>> The layerscape PCI host driver needs recognize ls2085a compatible
> > >>> when using firmware with ls2085a compatible property, otherwise the
> > >>> PCI bus won't be detected even though ls2085a compatible is included
> > by the dts.
> > >>>
> > >>> Signed-off-by: Yang Shi <yang.shi at linaro.org>
> > >>> ---
> > >>>   drivers/pci/host/pci-layerscape.c | 1 +
> > >>>   1 file changed, 1 insertion(+)
> > >>>
> > >>> diff --git a/drivers/pci/host/pci-layerscape.c
> > >>> b/drivers/pci/host/pci-layerscape.c
> > >>> index 3923bed..c40d8b2 100644
> > >>> --- a/drivers/pci/host/pci-layerscape.c
> > >>> +++ b/drivers/pci/host/pci-layerscape.c
> > >>> @@ -203,6 +203,7 @@ static const struct of_device_id
> > ls_pcie_of_match[] = {
> > >>>   	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata
> > },
> > >>>   	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata
> > },
> > >>>   	{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata
> > },
> > >>> +	{ .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },
> > >>>   	{ },
> > >>>   };
> > >>>   MODULE_DEVICE_TABLE(of, ls_pcie_of_match);
> > >>>
> > >>
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > the body of a message to majordomo at vger.kernel.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From majun258 at huawei.com  Sat Feb 13 18:16:26 2016
From: majun258 at huawei.com (MaJun)
Date: Sun, 14 Feb 2016 10:16:26 +0800
Subject: [PATCH 0/5] irqchip: Add support for Hisilicon mbigen v1 chip
Message-ID: <1455416191-23616-1-git-send-email-majun258@huawei.com>

From: Ma Jun <majun258 at huawei.com>

This patch set is used to support the mbigen v1 chip.
Compared to mbigen v2 chip, the main difference between them is
register layout(address,format)

As a sequence of this difference, the functions used to get or calculate
register address are also changed for this reason.

I posted this driver as a independent patch set but not change the mbigen-v2
driver to support mbigen-v1 hardware.

Ma Jun (5):
  dt-binding: Change the mbigen bindding file to support the mbigen-v1
  dt-binding:Rename the mbigen binding file name
  irqchip: add platform device driver for mbigen device
  irqchip:create irq domain for each mbigen device
  irqchip:implement the mbigen irq chip operation functions

 .../interrupt-controller/hisilicon,mbigen-v2.txt   |   74 -----
 .../interrupt-controller/hisilicon,mbigen.txt      |   74 +++++
 drivers/irqchip/Makefile                           |    2 +-
 drivers/irqchip/irq-mbigen-v1.c                    |  295 ++++++++++++++++++++
 4 files changed, 370 insertions(+), 75 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen.txt
 create mode 100644 drivers/irqchip/irq-mbigen-v1.c




From majun258 at huawei.com  Sat Feb 13 18:16:31 2016
From: majun258 at huawei.com (MaJun)
Date: Sun, 14 Feb 2016 10:16:31 +0800
Subject: [PATCH 5/5] irqchip:implement the mbigen irq chip operation functions
In-Reply-To: <1455416191-23616-1-git-send-email-majun258@huawei.com>
References: <1455416191-23616-1-git-send-email-majun258@huawei.com>
Message-ID: <1455416191-23616-6-git-send-email-majun258@huawei.com>

From: Ma Jun <majun258 at huawei.com>

Add the interrupt controller chip operation functions of mbigen chip.

Signed-off-by: Ma Jun <majun258 at huawei.com>
---
 drivers/irqchip/irq-mbigen-v1.c |   75 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen-v1.c b/drivers/irqchip/irq-mbigen-v1.c
index 6bbb82a..8291a47 100644
--- a/drivers/irqchip/irq-mbigen-v1.c
+++ b/drivers/irqchip/irq-mbigen-v1.c
@@ -41,6 +41,20 @@
 #define REG_MBIGEN_EXT_VEC_OFFSET		0x320
 
 /**
+ * offset of clear register in mbigen node
+ * This register is used to clear the status
+ * of interrupt
+ */
+#define REG_MBIGEN_CLEAR_OFFSET		0x100
+
+/**
+ * offset of interrupt type register
+ * This register is used to configure interrupt
+ * trigger type
+ */
+#define REG_MBIGEN_TYPE_OFFSET		0x0
+
+/**
  * struct mbigen_device - holds the information of mbigen device.
  *
  * @pdev:		pointer to the platform device structure of mbigen chip.
@@ -77,8 +91,69 @@ static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq)
 		return (nid - 4) * 4 + REG_MBIGEN_EXT_VEC_OFFSET;
 }
 
+static inline void get_mbigen_type_reg(irq_hw_number_t hwirq,
+					u32 *mask, u32 *addr)
+{
+	int ofst;
+
+	ofst = hwirq / 32 * 4;
+	*mask = 1 << (hwirq % 32);
+
+	*addr = ofst + REG_MBIGEN_TYPE_OFFSET;
+}
+
+static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq,
+					u32 *mask, u32 *addr)
+{
+	unsigned int ofst;
+
+	ofst = hwirq / 32 * 4;
+
+	*mask = 1 << (hwirq % 32);
+	*addr = ofst + REG_MBIGEN_CLEAR_OFFSET;
+}
+
+static void mbigen_eoi_irq(struct irq_data *data)
+{
+	void __iomem *base = data->chip_data;
+	u32 mask, addr;
+
+	get_mbigen_clear_reg(data->hwirq, &mask, &addr);
+
+	writel_relaxed(mask, base + addr);
+
+	irq_chip_eoi_parent(data);
+}
+
+static int mbigen_set_type(struct irq_data *data, unsigned int type)
+{
+	void __iomem *base = data->chip_data;
+	u32 mask, addr, val;
+
+	if (type != IRQ_TYPE_LEVEL_HIGH && type != IRQ_TYPE_EDGE_RISING)
+		return -EINVAL;
+
+	get_mbigen_type_reg(data->hwirq, &mask, &addr);
+
+	val = readl_relaxed(base + addr);
+
+	if (type == IRQ_TYPE_LEVEL_HIGH)
+		val |= mask;
+	else
+		val &= ~mask;
+
+	writel_relaxed(val, base + addr);
+
+	return 0;
+}
+
 static struct irq_chip mbigen_irq_chip = {
 	.name =			"mbigen-v1",
+	.irq_mask =		irq_chip_mask_parent,
+	.irq_unmask =		irq_chip_unmask_parent,
+	.irq_eoi =		mbigen_eoi_irq,
+	.irq_set_type =		mbigen_set_type,
+	.irq_set_affinity =	irq_chip_set_affinity_parent,
 };
 
 static void mbigen_write_msg(struct msi_desc *desc, struct msi_msg *msg)
-- 
1.7.1




From majun258 at huawei.com  Sat Feb 13 18:16:29 2016
From: majun258 at huawei.com (MaJun)
Date: Sun, 14 Feb 2016 10:16:29 +0800
Subject: [PATCH 3/5] irqchip: add platform device driver for mbigen device
In-Reply-To: <1455416191-23616-1-git-send-email-majun258@huawei.com>
References: <1455416191-23616-1-git-send-email-majun258@huawei.com>
Message-ID: <1455416191-23616-4-git-send-email-majun258@huawei.com>

From: Ma Jun <majun258 at huawei.com>

Add the platform device driver for mbigen chip v1.
This patch just same as mbigen v2.

Signed-off-by: Ma Jun <majun258 at huawei.com>
---
 drivers/irqchip/Makefile        |    2 +-
 drivers/irqchip/irq-mbigen-v1.c |   76 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 77 insertions(+), 1 deletions(-)
 create mode 100644 drivers/irqchip/irq-mbigen-v1.c

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 83d1fce..3152450 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -25,7 +25,7 @@ obj-$(CONFIG_REALVIEW_DT)		+= irq-gic-realview.o
 obj-$(CONFIG_ARM_GIC_V2M)		+= irq-gic-v2m.o
 obj-$(CONFIG_ARM_GIC_V3)		+= irq-gic-v3.o irq-gic-common.o
 obj-$(CONFIG_ARM_GIC_V3_ITS)		+= irq-gic-v3-its.o irq-gic-v3-its-pci-msi.o irq-gic-v3-its-platform-msi.o
-obj-$(CONFIG_HISILICON_IRQ_MBIGEN)	+= irq-mbigen.o
+obj-$(CONFIG_HISILICON_IRQ_MBIGEN)	+= irq-mbigen.o irq-mbigen-v1.o
 obj-$(CONFIG_ARM_NVIC)			+= irq-nvic.o
 obj-$(CONFIG_ARM_VIC)			+= irq-vic.o
 obj-$(CONFIG_ATMEL_AIC_IRQ)		+= irq-atmel-aic-common.o irq-atmel-aic.o
diff --git a/drivers/irqchip/irq-mbigen-v1.c b/drivers/irqchip/irq-mbigen-v1.c
new file mode 100644
index 0000000..9445658
--- /dev/null
+++ b/drivers/irqchip/irq-mbigen-v1.c
@@ -0,0 +1,76 @@
+/*
+ * Copyright (C) 2015 Hisilicon Limited, All Rights Reserved.
+ * Author: Jun Ma <majun258 at huawei.com>
+ * Author: Yun Wu <wuyun.wu at huawei.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/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+/**
+ * struct mbigen_device - holds the information of mbigen device.
+ *
+ * @pdev:		pointer to the platform device structure of mbigen chip.
+ * @base:		mapped address of this mbigen chip.
+ */
+struct mbigen_device {
+	struct platform_device	*pdev;
+	void __iomem		*base;
+};
+
+static int mbigen_device_probe(struct platform_device *pdev)
+{
+	struct mbigen_device *mgn_chip;
+	struct resource *res;
+
+	mgn_chip = devm_kzalloc(&pdev->dev, sizeof(*mgn_chip), GFP_KERNEL);
+	if (!mgn_chip)
+		return -ENOMEM;
+
+	mgn_chip->pdev = pdev;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mgn_chip->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+	if (IS_ERR(mgn_chip->base))
+		return PTR_ERR(mgn_chip->base);
+
+	platform_set_drvdata(pdev, mgn_chip);
+
+	return 0;
+}
+
+static const struct of_device_id mbigen_of_match[] = {
+	{ .compatible = "hisilicon,mbigen-v1" },
+	{ /* END */ }
+};
+MODULE_DEVICE_TABLE(of, mbigen_of_match);
+
+static struct platform_driver mbigen_platform_driver = {
+	.driver = {
+		.name		= "Hisilicon MBIGEN-V1",
+		.owner		= THIS_MODULE,
+		.of_match_table	= mbigen_of_match,
+	},
+	.probe			= mbigen_device_probe,
+};
+
+module_platform_driver(mbigen_platform_driver);
+
+MODULE_AUTHOR("Jun Ma <majun258 at huawei.com>");
+MODULE_AUTHOR("Yun Wu <wuyun.wu at huawei.com>");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Hisilicon MBI Generator driver");
-- 
1.7.1




From majun258 at huawei.com  Sat Feb 13 18:16:27 2016
From: majun258 at huawei.com (MaJun)
Date: Sun, 14 Feb 2016 10:16:27 +0800
Subject: [PATCH 1/5] dt-binding: Change the mbigen binding file to support the
 mbigen-v1
In-Reply-To: <1455416191-23616-1-git-send-email-majun258@huawei.com>
References: <1455416191-23616-1-git-send-email-majun258@huawei.com>
Message-ID: <1455416191-23616-2-git-send-email-majun258@huawei.com>

From: Ma Jun <majun258 at huawei.com>

Add the "hisilicon,mbigen-v1" string in binding file.
Signed-off-by: Ma Jun <majun258 at huawei.com>
---
 .../interrupt-controller/hisilicon,mbigen-v2.txt   |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
index 720f7c9..bdd1dea 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
@@ -16,7 +16,7 @@ The mbigen chip and devices connect to mbigen have the following properties:
 
 Mbigen main node required properties:
 -------------------------------------------
-- compatible: Should be "hisilicon,mbigen-v2"
+- compatible: Should be "hisilicon,mbigen-v2" or "hisilicon,mbigen-v1"
 
 - reg: Specifies the base physical address and size of the Mbigen
   registers.
-- 
1.7.1




From majun258 at huawei.com  Sat Feb 13 18:16:30 2016
From: majun258 at huawei.com (MaJun)
Date: Sun, 14 Feb 2016 10:16:30 +0800
Subject: [PATCH 4/5] irqchip:create irq domain for each mbigen device
In-Reply-To: <1455416191-23616-1-git-send-email-majun258@huawei.com>
References: <1455416191-23616-1-git-send-email-majun258@huawei.com>
Message-ID: <1455416191-23616-5-git-send-email-majun258@huawei.com>

From: Ma Jun <majun258 at huawei.com>

For peripheral devices which connect to mbigen,mbigen is a interrupt
controller. So, we create irq domain for each mbigen device and add
mbigen irq domain into irq hierarchy structure.

Signed-off-by: Ma Jun <majun258 at huawei.com>
---
 drivers/irqchip/irq-mbigen-v1.c |  144 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 144 insertions(+), 0 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen-v1.c b/drivers/irqchip/irq-mbigen-v1.c
index 9445658..6bbb82a 100644
--- a/drivers/irqchip/irq-mbigen-v1.c
+++ b/drivers/irqchip/irq-mbigen-v1.c
@@ -16,11 +16,30 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/interrupt.h>
+#include <linux/irqchip.h>
 #include <linux/module.h>
+#include <linux/msi.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 
+/* The maximum IRQ pin number of mbigen chip(start from 0) */
+#define MAXIMUM_IRQ_PIN_NUM		640
+
+/**
+ * In mbigen vector register
+ * bit[31:16]:	device id
+ * bit[15:0]:	event id value
+ */
+#define IRQ_EVENT_ID_MASK		0xffff
+
+/* offset of vector register in mbigen node */
+#define REG_MBIGEN_VEC_OFFSET		0x300
+#define REG_MBIGEN_EXT_VEC_OFFSET		0x320
+
 /**
  * struct mbigen_device - holds the information of mbigen device.
  *
@@ -32,10 +51,120 @@ struct mbigen_device {
 	void __iomem		*base;
 };
 
+static int get_mbigen_nid(unsigned int offset)
+{
+	int nid = 0;
+
+	if (offset < 256)
+		nid = offset / 64;
+	else if (offset < 384)
+		nid = 4;
+	else if (offset < 640)
+		nid = 5;
+
+	return nid;
+}
+
+static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq)
+{
+	unsigned int nid;
+
+	nid = get_mbigen_nid(hwirq);
+
+	if (nid < 4)
+		return (nid * 4) + REG_MBIGEN_VEC_OFFSET;
+	else
+		return (nid - 4) * 4 + REG_MBIGEN_EXT_VEC_OFFSET;
+}
+
+static struct irq_chip mbigen_irq_chip = {
+	.name =			"mbigen-v1",
+};
+
+static void mbigen_write_msg(struct msi_desc *desc, struct msi_msg *msg)
+{
+	struct irq_data *d = irq_get_irq_data(desc->irq);
+	void __iomem *base = d->chip_data;
+	u32 val;
+
+	base += get_mbigen_vec_reg(d->hwirq);
+	val = readl_relaxed(base);
+
+	val &= ~IRQ_EVENT_ID_MASK;
+	val |= msg->data;
+
+	/* The address of doorbell is encoded in mbigen register by default
+	 * So,we don't need to program the doorbell address at here
+	 */
+	writel_relaxed(val, base);
+}
+
+static int mbigen_domain_translate(struct irq_domain *d,
+				    struct irq_fwspec *fwspec,
+				    unsigned long *hwirq,
+				    unsigned int *type)
+{
+	if (is_of_node(fwspec->fwnode)) {
+		if (fwspec->param_count != 2)
+			return -EINVAL;
+
+		if (fwspec->param[0] > MAXIMUM_IRQ_PIN_NUM)
+			return -EINVAL;
+
+		*hwirq = fwspec->param[0];
+
+		/* If there is no valid irq type, just use the default type */
+		if ((fwspec->param[1] == IRQ_TYPE_EDGE_RISING) ||
+			(fwspec->param[1] == IRQ_TYPE_LEVEL_HIGH))
+			*type = fwspec->param[1];
+		else
+			return -EINVAL;
+
+		return 0;
+	}
+	return -EINVAL;
+}
+
+static int mbigen_irq_domain_alloc(struct irq_domain *domain,
+					unsigned int virq,
+					unsigned int nr_irqs,
+					void *args)
+{
+	struct irq_fwspec *fwspec = args;
+	irq_hw_number_t hwirq;
+	unsigned int type;
+	struct mbigen_device *mgn_chip;
+	int i, err;
+
+	err = mbigen_domain_translate(domain, fwspec, &hwirq, &type);
+	if (err)
+		return err;
+
+	err = platform_msi_domain_alloc(domain, virq, nr_irqs);
+	if (err)
+		return err;
+
+	mgn_chip = platform_msi_get_host_data(domain);
+
+	for (i = 0; i < nr_irqs; i++)
+		irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
+				      &mbigen_irq_chip, mgn_chip->base);
+
+	return 0;
+}
+
+static struct irq_domain_ops mbigen_domain_ops = {
+	.translate	= mbigen_domain_translate,
+	.alloc		= mbigen_irq_domain_alloc,
+	.free		= irq_domain_free_irqs_common,
+};
+
 static int mbigen_device_probe(struct platform_device *pdev)
 {
 	struct mbigen_device *mgn_chip;
 	struct resource *res;
+	struct irq_domain *domain;
+	u32 num_pins;
 
 	mgn_chip = devm_kzalloc(&pdev->dev, sizeof(*mgn_chip), GFP_KERNEL);
 	if (!mgn_chip)
@@ -48,8 +177,23 @@ static int mbigen_device_probe(struct platform_device *pdev)
 	if (IS_ERR(mgn_chip->base))
 		return PTR_ERR(mgn_chip->base);
 
+	if (of_property_read_u32(pdev->dev.of_node, "num-pins", &num_pins) < 0) {
+		dev_err(&pdev->dev, "No num-pins property\n");
+		return -EINVAL;
+	}
+
+	domain = platform_msi_create_device_domain(&pdev->dev, num_pins,
+							mbigen_write_msg,
+							&mbigen_domain_ops,
+							mgn_chip);
+
+	if (!domain)
+		return -ENOMEM;
+
 	platform_set_drvdata(pdev, mgn_chip);
 
+	dev_info(&pdev->dev, "Allocated %d MSIs\n", num_pins);
+
 	return 0;
 }
 
-- 
1.7.1




From majun258 at huawei.com  Sat Feb 13 18:16:28 2016
From: majun258 at huawei.com (MaJun)
Date: Sun, 14 Feb 2016 10:16:28 +0800
Subject: [PATCH 2/5] dt-binding:Rename the mbigen binding file name
In-Reply-To: <1455416191-23616-1-git-send-email-majun258@huawei.com>
References: <1455416191-23616-1-git-send-email-majun258@huawei.com>
Message-ID: <1455416191-23616-3-git-send-email-majun258@huawei.com>

From: Ma Jun <majun258 at huawei.com>

Because added the mbigen-v1 compatible string, the origin name is
not suitable any more. So,I remove the version number from file name.

Signed-off-by: Ma Jun <majun258 at huawei.com>
---
 .../interrupt-controller/hisilicon,mbigen-v2.txt   |   74 --------------------
 .../interrupt-controller/hisilicon,mbigen.txt      |   74 ++++++++++++++++++++
 2 files changed, 74 insertions(+), 74 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen.txt

diff --git a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
deleted file mode 100644
index bdd1dea..0000000
--- a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-Hisilicon mbigen device tree bindings.
-=======================================
-
-Mbigen means: message based interrupt generator.
-
-MBI is kind of msi interrupt only used on Non-PCI devices.
-
-To reduce the wired interrupt number connected to GIC,
-Hisilicon designed mbigen to collect and generate interrupt.
-
-
-Non-pci devices can connect to mbigen and generate the
-interrupt by writing ITS register.
-
-The mbigen chip and devices connect to mbigen have the following properties:
-
-Mbigen main node required properties:
--------------------------------------------
-- compatible: Should be "hisilicon,mbigen-v2" or "hisilicon,mbigen-v1"
-
-- reg: Specifies the base physical address and size of the Mbigen
-  registers.
-
-- interrupt controller: Identifies the node as an interrupt controller
-
-- msi-parent: Specifies the MSI controller this mbigen use.
-  For more detail information,please refer to the generic msi-parent binding in
-  Documentation/devicetree/bindings/interrupt-controller/msi.txt.
-
-- num-pins: the total number of pins implemented in this Mbigen
-  instance.
-
-- #interrupt-cells : Specifies the number of cells needed to encode an
-  interrupt source. The value must be 2.
-
-  The 1st cell is hardware pin number of the interrupt.This number is local to
-  each mbigen chip and in the range from 0 to the maximum interrupts number
-  of the mbigen.
-
-  The 2nd cell is the interrupt trigger type.
-	The value of this cell should be:
-	1: rising edge triggered
-	or
-	4: high level triggered
-
-Examples:
-
-	mbigen_device_gmac:intc {
-			compatible = "hisilicon,mbigen-v2";
-			reg = <0x0 0xc0080000 0x0 0x10000>;
-			interrupt-controller;
-			msi-parent = <&its_dsa 0x40b1c>;
-			num-pins = <9>;
-			#interrupt-cells = <2>;
-	};
-
-Devices connect to mbigen required properties:
-----------------------------------------------------
--interrupt-parent: Specifies the mbigen device node which device connected.
-
--interrupts:Specifies the interrupt source.
- For the specific information of each cell in this property,please refer to
- the "interrupt-cells" description mentioned above.
-
-Examples:
-	gmac0: ethernet at c2080000 {
-		#address-cells = <1>;
-		#size-cells = <0>;
-		reg = <0 0xc2080000 0 0x20000>,
-		      <0 0xc0000000 0 0x1000>;
-		interrupt-parent  = <&mbigen_device_gmac>;
-		interrupts =	<656 1>,
-				<657 1>;
-	};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen.txt b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen.txt
new file mode 100644
index 0000000..bdd1dea
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen.txt
@@ -0,0 +1,74 @@
+Hisilicon mbigen device tree bindings.
+=======================================
+
+Mbigen means: message based interrupt generator.
+
+MBI is kind of msi interrupt only used on Non-PCI devices.
+
+To reduce the wired interrupt number connected to GIC,
+Hisilicon designed mbigen to collect and generate interrupt.
+
+
+Non-pci devices can connect to mbigen and generate the
+interrupt by writing ITS register.
+
+The mbigen chip and devices connect to mbigen have the following properties:
+
+Mbigen main node required properties:
+-------------------------------------------
+- compatible: Should be "hisilicon,mbigen-v2" or "hisilicon,mbigen-v1"
+
+- reg: Specifies the base physical address and size of the Mbigen
+  registers.
+
+- interrupt controller: Identifies the node as an interrupt controller
+
+- msi-parent: Specifies the MSI controller this mbigen use.
+  For more detail information,please refer to the generic msi-parent binding in
+  Documentation/devicetree/bindings/interrupt-controller/msi.txt.
+
+- num-pins: the total number of pins implemented in this Mbigen
+  instance.
+
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The value must be 2.
+
+  The 1st cell is hardware pin number of the interrupt.This number is local to
+  each mbigen chip and in the range from 0 to the maximum interrupts number
+  of the mbigen.
+
+  The 2nd cell is the interrupt trigger type.
+	The value of this cell should be:
+	1: rising edge triggered
+	or
+	4: high level triggered
+
+Examples:
+
+	mbigen_device_gmac:intc {
+			compatible = "hisilicon,mbigen-v2";
+			reg = <0x0 0xc0080000 0x0 0x10000>;
+			interrupt-controller;
+			msi-parent = <&its_dsa 0x40b1c>;
+			num-pins = <9>;
+			#interrupt-cells = <2>;
+	};
+
+Devices connect to mbigen required properties:
+----------------------------------------------------
+-interrupt-parent: Specifies the mbigen device node which device connected.
+
+-interrupts:Specifies the interrupt source.
+ For the specific information of each cell in this property,please refer to
+ the "interrupt-cells" description mentioned above.
+
+Examples:
+	gmac0: ethernet at c2080000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0 0xc2080000 0 0x20000>,
+		      <0 0xc0000000 0 0x1000>;
+		interrupt-parent  = <&mbigen_device_gmac>;
+		interrupts =	<656 1>,
+				<657 1>;
+	};
-- 
1.7.1




From shawnguo at kernel.org  Sat Feb 13 18:19:29 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 10:19:29 +0800
Subject: [PATCH v7 4/7] ARM: dts: imx: Add support for Advantech/GE Bx50v3
In-Reply-To: <56B3E578.2080209@timesys.com>
References: <1454109558-22800-1-git-send-email-akshay.bhat@timesys.com>
 <1454109558-22800-5-git-send-email-akshay.bhat@timesys.com>
 <20160203145256.GR8307@tiger> <56B3E578.2080209@timesys.com>
Message-ID: <20160214021929.GC6756@tiger>

On Thu, Feb 04, 2016 at 06:57:44PM -0500, Akshay Bhat wrote:
> >>+/ {
> >>+	clocks {
> >>+		#address-cells = <1>;
> >>+		#size-cells = <0>;
> >
> >These are already specified in imx6qdl.dtsi.
> >
> 
> Will fix this. Once it is removed, should I have a new line before
> the child node?
> eg:
> 
> clocks {
> 

No, this new line is not needed.

Shawn

> 	mclk: clock at 0 {
> 		compatible = "fixed-clock";
> >>+
> >>+		mclk: clock at 0 {
> >>+			compatible = "fixed-clock";
> >>+			reg = <0>;
> >>+			#clock-cells = <0>;
> >>+			clock-frequency = <22000000>;
> >>+		};
> >>+	};


From shawnguo at kernel.org  Sat Feb 13 19:21:03 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 11:21:03 +0800
Subject: [PATCH V3 1/5] clk: imx: Add clock support for imx6qp
In-Reply-To: <1454407298-15545-1-git-send-email-ping.bai@nxp.com>
References: <1454407298-15545-1-git-send-email-ping.bai@nxp.com>
Message-ID: <20160214032103.GD6756@tiger>

On Tue, Feb 02, 2016 at 06:01:34PM +0800, Bai Ping wrote:
> most of the clock tree structures on i.MX6 Quad Plus are
> same as on i.MX6Q. there still some differences between
> these two SOCs. compared to the i.XM6Q, the differents of
> clocks on i.MX6QP is mainly on:
> 
> 1. New clock gate added to support the PRE and PRG modules
> 2. 24MHz OSC clock option added to the UART, IPG, ECSPI, and
>    CAN clock roots.
> 3. MMDC channel 1 clock gate is now controllable.
> 4. clock gating added to the LDB_DIx_IPU clocks on i.MX6QP
> 5. EMI clock root divider fix
> 6. other updates fo CSCMRx, CSCDRx and CS2CDR registers.
> 
> detailed infomation, please refer to the i.MX6QP RM.
> 
> Signed-off-by: Bai Ping <ping.bai at nxp.com>

Applied all, thanks.


From shawnguo at kernel.org  Sat Feb 13 19:24:33 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 11:24:33 +0800
Subject: [PATCH v2] ARM: mx25: Add basic suspend/resume support
In-Reply-To: <1454449538-7620-1-git-send-email-festevam@gmail.com>
References: <1454449538-7620-1-git-send-email-festevam@gmail.com>
Message-ID: <20160214032433.GE6756@tiger>

On Tue, Feb 02, 2016 at 07:45:38PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at nxp.com>
> 
> Tested basic suspend/resume on a mx25pdk:
> 
> $ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
> $ echo mem > /sys/power/state
> 
> Then press any key in the serial console and the system wakes up.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at nxp.com>

Applied, thanks.


From shawnguo at kernel.org  Sat Feb 13 19:28:27 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 11:28:27 +0800
Subject: [PATCH v3] ARM: dts: Add dts for Uniwest evi
In-Reply-To: <1454521065-14241-1-git-send-email-stillcompiling@gmail.com>
References: <1454491459.3415.6.camel@pengutronix.de>
 <1454521065-14241-1-git-send-email-stillcompiling@gmail.com>
Message-ID: <20160214032827.GF6756@tiger>

On Wed, Feb 03, 2016 at 09:37:45AM -0800, Joshua Clayton wrote:
> Uniwest evi is a portable electrical eddy current non-destructive
> testing device.
> 
> Signed-off-by: Joshua Clayton <stillcompiling at gmail.com>

Applied, thanks.


From shawnguo at kernel.org  Sat Feb 13 19:44:44 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 11:44:44 +0800
Subject: [PATCH] dts: ls102xa: ifc: Add the partition for NOR flash
In-Reply-To: <1454487404-330-1-git-send-email-b18965@freescale.com>
References: <1454487404-330-1-git-send-email-b18965@freescale.com>
Message-ID: <20160214034444.GG6756@tiger>

On Wed, Feb 03, 2016 at 04:16:44PM +0800, Alison Wang wrote:
> According to the new mapping table, the partition for NOR flash
> is added.

How do you know that everyone using the board wants the NOR flash to be
partitioned this way?  It's really a matter of software configuration
and may vary from system to system.

Shawn

> 
> Signed-off-by: Alison Wang <alison.wang at nxp.com>
> ---
>  arch/arm/boot/dts/ls1021a-qds.dts | 60 +++++++++++++++++++++++++++++++++++++++
>  arch/arm/boot/dts/ls1021a-twr.dts | 60 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 120 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/ls1021a-qds.dts b/arch/arm/boot/dts/ls1021a-qds.dts
> index 9408753..904ee09 100644
> --- a/arch/arm/boot/dts/ls1021a-qds.dts
> +++ b/arch/arm/boot/dts/ls1021a-qds.dts
> @@ -237,6 +237,66 @@
>  		reg = <0x0 0x0 0x8000000>;
>  		bank-width = <2>;
>  		device-width = <1>;
> +
> +		partition at 0 {
> +			/* 128KB for bank0 RCW */
> +			reg = <0x00000000 0x00020000>;
> +			label = "NOR bank0 RCW Image";
> +		};
> +
> +		partition at 100000 {
> +			/* 1MB for bank0 u-boot Image */
> +			reg = <0x00100000 0x00100000>;
> +			label = "NOR bank0 u-boot Image";
> +		};
> +
> +		partition at 200000 {
> +			/* 1MB for bank0 DTB */
> +			reg = <0x00200000 0x00100000>;
> +			label = "NOR bank0 DTB Image";
> +		};
> +
> +		partition at 300000 {
> +			/* 7MB for bank0 Linux Kernel */
> +			reg = <0x00300000 0x00700000>;
> +			label = "NOR bank0 Linux Kernel Image";
> +		};
> +
> +		partition at a00000 {
> +			/* 54MB for bank0 Ramdisk Root File System */
> +			reg = <0x00a00000 0x03600000>;
> +			label = "NOR bank0 Ramdisk Root File System Image";
> +		};
> +
> +		partition at 4000000 {
> +			/* 128KB for bank4 RCW */
> +			reg = <0x04000000 0x00020000>;
> +			label = "NOR bank4 RCW Image";
> +		};
> +
> +		partition at 4100000 {
> +			/* 1MB for bank4 u-boot Image */
> +			reg = <0x04100000 0x00100000>;
> +			label = "NOR bank4 u-boot Image";
> +		};
> +
> +		partition at 4200000 {
> +			/* 1MB for bank4 DTB */
> +			reg = <0x04200000 0x00100000>;
> +			label = "NOR bank4 DTB Image";
> +		};
> +
> +		partition at 4300000 {
> +			/* 7MB for bank4 Linux Kernel */
> +			reg = <0x04300000 0x00700000>;
> +			label = "NOR bank4 Linux Kernel Image";
> +		};
> +
> +		partition at 4a00000 {
> +			/* 54MB for bank4 Ramdisk Root File System */
> +			reg = <0x04a00000 0x03600000>;
> +			label = "NOR bank4 Ramdisk Root File System Image";
> +		};
>  	};
>  
>  	fpga: board-control at 3,0 {
> diff --git a/arch/arm/boot/dts/ls1021a-twr.dts b/arch/arm/boot/dts/ls1021a-twr.dts
> index 75ecaed..f5e9616 100644
> --- a/arch/arm/boot/dts/ls1021a-twr.dts
> +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> @@ -194,6 +194,66 @@
>  		reg = <0x0 0x0 0x8000000>;
>  		bank-width = <2>;
>  		device-width = <1>;
> +
> +		partition at 0 {
> +			/* 128KB for bank0 RCW */
> +			reg = <0x00000000 0x00020000>;
> +			label = "NOR bank0 RCW Image";
> +		};
> +
> +		partition at 100000 {
> +			/* 1MB for bank0 u-boot Image */
> +			reg = <0x00100000 0x00100000>;
> +			label = "NOR bank0 u-boot Image";
> +		};
> +
> +		partition at 200000 {
> +			/* 1MB for bank0 DTB */
> +			reg = <0x00200000 0x00100000>;
> +			label = "NOR bank0 DTB Image";
> +		};
> +
> +		partition at 300000 {
> +			/* 7MB for bank0 Linux Kernel */
> +			reg = <0x00300000 0x00700000>;
> +			label = "NOR bank0 Linux Kernel Image";
> +		};
> +
> +		partition at a00000 {
> +			/* 54MB for bank0 Ramdisk Root File System */
> +			reg = <0x00a00000 0x03600000>;
> +			label = "NOR bank0 Ramdisk Root File System Image";
> +		};
> +
> +		partition at 4000000 {
> +			/* 128KB for bank4 RCW */
> +			reg = <0x04000000 0x00020000>;
> +			label = "NOR bank4 RCW Image";
> +		};
> +
> +		partition at 4100000 {
> +			/* 1MB for bank4 u-boot Image */
> +			reg = <0x04100000 0x00100000>;
> +			label = "NOR bank4 u-boot Image";
> +		};
> +
> +		partition at 4200000 {
> +			/* 1MB for bank4 DTB */
> +			reg = <0x04200000 0x00100000>;
> +			label = "NOR bank4 DTB Image";
> +		};
> +
> +		partition at 4300000 {
> +			/* 7MB for bank4 Linux Kernel */
> +			reg = <0x04300000 0x00700000>;
> +			label = "NOR bank4 Linux Kernel Image";
> +		};
> +
> +		partition at 4a00000 {
> +			/* 54MB for bank4 Ramdisk Root File System */
> +			reg = <0x04a00000 0x03600000>;
> +			label = "NOR bank4 Ramdisk Root File System Image";
> +		};
>  	};
>  };
>  
> -- 
> 2.1.0.27.g96db324
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From k.kozlowski.k at gmail.com  Sat Feb 13 20:56:18 2016
From: k.kozlowski.k at gmail.com (Krzysztof Kozlowski)
Date: Sun, 14 Feb 2016 13:56:18 +0900
Subject: [next] Odroid XU3 boot fail after cpufreq: dt: Use
 dev_pm_opp_set_rate() to switch frequency
Message-ID: <56C008F2.3080807@gmail.com>

Hi all,

Recently Odroid XU3 failed to boot on linux-next
on multi_v7 defconfig. exynos defconfig boots fine.

Probably the "cpufreq: dt: Use dev_pm_opp_set_rate() to
switch frequency" is important here:
commit 78c3ba5df96c875b1668e1cd3ee0a69e62454f32
Author: Viresh Kumar <viresh.kumar at linaro.org>
Date:   Tue Feb 9 10:30:46 2016 +0530

    cpufreq: dt: Use dev_pm_opp_set_rate() to switch frequency
    
    OPP core supports frequency/voltage changes based on the target
    frequency now, use that instead of open coding the same in cpufreq-dt
    driver.
    
    Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
    Reviewed-by: Stephen Boyd <sboyd at codeaurora.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki at intel.com>


Full log:
http://www.krzk.eu/builders/boot-odroid-xu3-multi_v7/builds/276/steps/Boot%20odroid/logs/serial

dmesg:
Feb 14 10:29:58 [    1.620308] vdd_ldo9: ramp_delay not set
Feb 14 10:29:58 [    1.631144] vdd_ldo13: ramp_delay not set
Feb 14 10:29:58 [    1.638523] vdd_ldo15: ramp_delay not set
Feb 14 10:29:58 [    1.649500] vdd_sd: ramp_delay not set
Feb 14 10:29:58 [    1.712318] ------------[ cut here ]------------
Feb 14 10:29:58 [    1.715490] kernel BUG at ../drivers/regulator/core.c:216!
...
Feb 14 10:29:58 [    2.109871] [<c0684af4>] (regulator_check_voltage) from [<c06857ac>] (regulator_set_voltage_unlocked+0x58/0x230)
Feb 14 10:29:58 [    2.120000] [<c06857ac>] (regulator_set_voltage_unlocked) from [<c06859ac>] (regulator_set_voltage+0x28/0x54)
Feb 14 10:29:58 [    2.129880] [<c06859ac>] (regulator_set_voltage) from [<c0775b28>] (_set_opp_voltage+0x30/0x98)
Feb 14 10:29:58 [    2.138543] [<c0775b28>] (_set_opp_voltage) from [<c0776630>] (dev_pm_opp_set_rate+0xf0/0x28c)
Feb 14 10:29:58 [    2.147126] [<c0776630>] (dev_pm_opp_set_rate) from [<c096f784>] (__cpufreq_driver_target+0x184/0x2b4)
Feb 14 10:29:58 [    2.156394] [<c096f784>] (__cpufreq_driver_target) from [<c0973760>] (dbs_check_cpu+0x1b0/0x1f4)
Feb 14 10:29:58 [    2.165143] [<c0973760>] (dbs_check_cpu) from [<c0973f30>] (cpufreq_governor_dbs+0x324/0x5c4)
Feb 14 10:29:58 [    2.173637] [<c0973f30>] (cpufreq_governor_dbs) from [<c0970958>] (__cpufreq_governor+0xe4/0x1ec)
Feb 14 10:29:58 [    2.182477] [<c0970958>] (__cpufreq_governor) from [<c09711e0>] (cpufreq_init_policy+0x64/0x8c)
Feb 14 10:29:58 [    2.191141] [<c09711e0>] (cpufreq_init_policy) from [<c09718cc>] (cpufreq_online+0x2fc/0x708)
Feb 14 10:29:58 [    2.199634] [<c09718cc>] (cpufreq_online) from [<c0765ff0>] (subsys_interface_register+0x94/0xd8)
Feb 14 10:29:58 [    2.208472] [<c0765ff0>] (subsys_interface_register) from [<c0970530>] (cpufreq_register_driver+0x14c/0x19c)
Feb 14 10:29:58 [    2.218263] [<c0970530>] (cpufreq_register_driver) from [<c09746dc>] (dt_cpufreq_probe+0x70/0xec)
Feb 14 10:29:59 [    2.227104] [<c09746dc>] (dt_cpufreq_probe) from [<c076907c>] (platform_drv_probe+0x4c/0xb0)
Feb 14 10:29:59 [    2.235508] [<c076907c>] (platform_drv_probe) from [<c07678e0>] (driver_probe_device+0x214/0x2c0)
Feb 14 10:29:59 [    2.244345] [<c07678e0>] (driver_probe_device) from [<c0767a18>] (__driver_attach+0x8c/0x90)
Feb 14 10:29:59 [    2.252750] [<c0767a18>] (__driver_attach) from [<c0765c2c>] (bus_for_each_dev+0x68/0x9c)
Feb 14 10:29:59 [    2.260895] [<c0765c2c>] (bus_for_each_dev) from [<c0766d78>] (bus_add_driver+0x1a0/0x218)
Feb 14 10:29:59 [    2.269128] [<c0766d78>] (bus_add_driver) from [<c076810c>] (driver_register+0x78/0xf8)
Feb 14 10:29:59 [    2.277103] [<c076810c>] (driver_register) from [<c0301d74>] (do_one_initcall+0x90/0x1d8)
Feb 14 10:29:59 [    2.285254] [<c0301d74>] (do_one_initcall) from [<c1100e14>] (kernel_init_freeable+0x15c/0x1fc)
Feb 14 10:29:59 [    2.293918] [<c1100e14>] (kernel_init_freeable) from [<c0b27a0c>] (kernel_init+0x8/0xf0)
Feb 14 10:29:59 [    2.301975] [<c0b27a0c>] (kernel_init) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
Feb 14 10:29:59 [    2.309508] Code: e1550004 baffffeb e3a00000 e8bd8070 (e7f001f2) 
Feb 14 10:29:59 [    2.315585] ---[ end trace 42d99689dedcb6cb ]---


Device boots fine after reverting last three opp patches:
1. dd02a3d920083b6cb0ee4f0eaf2c599b740bf5fe
2. df2c8ec28e73d47392b8cb24828c15c54819da41
3. 78c3ba5df96c875b1668e1cd3ee0a69e62454f32


More details:
1. multi_v7_defconfig with enabled IPV6,NFS_V4,SENSORS_PWM_FAN,PWM_SAMSUNG
and disabled LEDS_TRIGGER_HEARTBEAT.
2. exynos5422-odroidxu3-lite.dts
3. The OPP used for cpufreq-dt are a combination of:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/exynos5420.dtsi
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/exynos5422-cpus.dtsi
4. Reproduced recently on next-20160212. First encountered on next-20160211.

Any ideas?

Best regards,
Krzysztof


From k.kozlowski at samsung.com  Sat Feb 13 21:08:11 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Sun, 14 Feb 2016 14:08:11 +0900
Subject: [PATCH v3] arm64: defconfig: Enable samsung MFD and related
 configs
In-Reply-To: <1454652269-6100-1-git-send-email-alim.akhtar@samsung.com>
References: <1454652269-6100-1-git-send-email-alim.akhtar@samsung.com>
Message-ID: <56C00BBB.4080807@samsung.com>

W dniu 05.02.2016 o 15:04, Alim Akhtar pisze:
> Exynos7 based espresso board uses S2MPS15, a multifunction device.
> This patch enables S2MPS1X regulator, pmic-clk and rtc drivers utilized by
> the same.
> 
> Signed-off-by: Alim Akhtar <alim.akhtar at samsung.com>
> Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> ---
> Changes since v2:
> * Added Reviewed-by from Krzysztof
> * rebased on next-20160204
> 
> Changes since v1:
> * updated the comment message to describe which platfrom uses it.
> * enable COMMON_CLK_S2MPS11 which is needed to enable pmic-clk block.
> 
>  arch/arm64/configs/defconfig |    3 +++
>  1 file changed, 3 insertions(+)
> 

Applying this to my tree would cause conflicts with commit efdda175c07f:
arm64: defconfig: add spmi and usb related configs
Conflicts are trivial (simple additions) but maybe it is better to avoid
them.

Olof/Arnd/Kevin, can you apply this directly to arm-soc?

Best regards,
Krzysztof

> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 86581f7..2fd2264 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -151,9 +151,11 @@ CONFIG_GPIO_XGENE=y
>  CONFIG_POWER_RESET_XGENE=y
>  CONFIG_POWER_RESET_SYSCON=y
>  # CONFIG_HWMON is not set
> +CONFIG_MFD_SEC_CORE=y
>  CONFIG_REGULATOR=y
>  CONFIG_REGULATOR_FIXED_VOLTAGE=y
>  CONFIG_REGULATOR_QCOM_SMD_RPM=y
> +CONFIG_REGULATOR_S2MPS11=y
>  CONFIG_FB=y
>  CONFIG_FB_ARMCLCD=y
>  CONFIG_FRAMEBUFFER_CONSOLE=y
> @@ -188,6 +190,7 @@ CONFIG_LEDS_TRIGGERS=y
>  CONFIG_LEDS_TRIGGER_HEARTBEAT=y
>  CONFIG_LEDS_TRIGGER_CPU=y
>  CONFIG_RTC_CLASS=y
> +CONFIG_RTC_DRV_S5M=y
>  CONFIG_RTC_DRV_EFI=y
>  CONFIG_RTC_DRV_PL031=y
>  CONFIG_RTC_DRV_XGENE=y
> 



From viresh.kumar at linaro.org  Sat Feb 13 21:22:28 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Sun, 14 Feb 2016 10:52:28 +0530
Subject: [next] Odroid XU3 boot fail after cpufreq: dt: Use
 dev_pm_opp_set_rate() to switch frequency
In-Reply-To: <56C008F2.3080807@gmail.com>
References: <56C008F2.3080807@gmail.com>
Message-ID: <20160214052228.GA18226@vireshk-i7>

On 14-02-16, 13:56, Krzysztof Kozlowski wrote:
> Hi all,
> 
> Recently Odroid XU3 failed to boot on linux-next
> on multi_v7 defconfig. exynos defconfig boots fine.
> 
> Probably the "cpufreq: dt: Use dev_pm_opp_set_rate() to
> switch frequency" is important here:
> commit 78c3ba5df96c875b1668e1cd3ee0a69e62454f32
> Author: Viresh Kumar <viresh.kumar at linaro.org>
> Date:   Tue Feb 9 10:30:46 2016 +0530
> 
>     cpufreq: dt: Use dev_pm_opp_set_rate() to switch frequency
>     
>     OPP core supports frequency/voltage changes based on the target
>     frequency now, use that instead of open coding the same in cpufreq-dt
>     driver.
>     
>     Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
>     Reviewed-by: Stephen Boyd <sboyd at codeaurora.org>
>     Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki at intel.com>

Can you please try the below untested patch please ?

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index d7cd4e265766..a97b333036c9 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -1156,9 +1156,15 @@ static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev,
 		return -EINVAL;
 	}
 
-	opp->u_volt = microvolt[0];
-	opp->u_volt_min = microvolt[1];
-	opp->u_volt_max = microvolt[2];
+	if (count == 1) {
+		opp->u_volt = microvolt[0];
+		opp->u_volt_min = opp->u_volt;
+		opp->u_volt_max = opp->u_volt;
+	} else {
+		opp->u_volt = microvolt[0];
+		opp->u_volt_min = microvolt[1];
+		opp->u_volt_max = microvolt[2];
+	}
 
 	/* Search for "opp-microamp-<name>" */
 	prop = NULL;

-- 
viresh


From k.kozlowski.k at gmail.com  Sat Feb 13 21:47:40 2016
From: k.kozlowski.k at gmail.com (Krzysztof Kozlowski)
Date: Sun, 14 Feb 2016 14:47:40 +0900
Subject: [next] Odroid XU3 boot fail after cpufreq: dt: Use
 dev_pm_opp_set_rate() to switch frequency
In-Reply-To: <20160214052228.GA18226@vireshk-i7>
References: <56C008F2.3080807@gmail.com> <20160214052228.GA18226@vireshk-i7>
Message-ID: <56C014FC.8060009@gmail.com>

W dniu 14.02.2016 o 14:22, Viresh Kumar pisze:
> On 14-02-16, 13:56, Krzysztof Kozlowski wrote:
>> Hi all,
>>
>> Recently Odroid XU3 failed to boot on linux-next
>> on multi_v7 defconfig. exynos defconfig boots fine.
>>
>> Probably the "cpufreq: dt: Use dev_pm_opp_set_rate() to
>> switch frequency" is important here:
>> commit 78c3ba5df96c875b1668e1cd3ee0a69e62454f32
>> Author: Viresh Kumar <viresh.kumar at linaro.org>
>> Date:   Tue Feb 9 10:30:46 2016 +0530
>>
>>     cpufreq: dt: Use dev_pm_opp_set_rate() to switch frequency
>>     
>>     OPP core supports frequency/voltage changes based on the target
>>     frequency now, use that instead of open coding the same in cpufreq-dt
>>     driver.
>>     
>>     Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
>>     Reviewed-by: Stephen Boyd <sboyd at codeaurora.org>
>>     Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki at intel.com>
> 
> Can you please try the below untested patch please ?

Thanks for quick reply. The patch fixed the problem.

Tested-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>

Best regards,
Krzysztof

> diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
> index d7cd4e265766..a97b333036c9 100644
> --- a/drivers/base/power/opp/core.c
> +++ b/drivers/base/power/opp/core.c
> @@ -1156,9 +1156,15 @@ static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev,
>  		return -EINVAL;
>  	}
>  
> -	opp->u_volt = microvolt[0];
> -	opp->u_volt_min = microvolt[1];
> -	opp->u_volt_max = microvolt[2];
> +	if (count == 1) {
> +		opp->u_volt = microvolt[0];
> +		opp->u_volt_min = opp->u_volt;
> +		opp->u_volt_max = opp->u_volt;
> +	} else {
> +		opp->u_volt = microvolt[0];
> +		opp->u_volt_min = microvolt[1];
> +		opp->u_volt_max = microvolt[2];
> +	}
>  
>  	/* Search for "opp-microamp-<name>" */
>  	prop = NULL;
> 



From k.kozlowski.k at gmail.com  Sat Feb 13 22:06:27 2016
From: k.kozlowski.k at gmail.com (Krzysztof Kozlowski)
Date: Sun, 14 Feb 2016 15:06:27 +0900
Subject: [next] Odroid XU3 easily over-heats
Message-ID: <56C01963.3080106@gmail.com>

Hi all,

With recent addition of cpufreq-dt support to Exynos5422
it is very easy to over-heat the Odroid XU3 leading to critical shutdown:
[  132.622032] thermal thermal_zone3: critical temperature reached(121 C),shutting down


Reproduction:
0. next-20160212 (with recent fix for OPP from Viresh)
1. multi_v7 (on exynos defconfig there is no cpufreq for Exynos5422)
2. Run following test script:
https://github.com/krzk/tools/blob/master/tests/odroid-xu3-cpu-mmc-stress.sh

(the script essentially does only "cat /dev/mmcblk0p2 | gzip -c > /dev/null" for each CPU)

Observe, just before shutdown:
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:1300000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:200000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:154000
/sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0 1 2 3
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:200000 300000 400000 500000 600000 700000 800000 900000 1000000 1100000 1200000 1300000 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:ondemand performance 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:1300000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:cpufreq-dt
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:1300000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:200000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported>

/sys/class/thermal/thermal_zone0/temp:90000
/sys/class/thermal/thermal_zone1/temp:98000
/sys/class/thermal/thermal_zone2/temp:113000
/sys/class/thermal/thermal_zone3/temp:119000
/sys/class/thermal/thermal_zone4/temp:81000

/sys/class/thermal/cooling_device0/cur_state:3
/sys/class/thermal/cooling_device0/max_state:3
/sys/class/thermal/cooling_device0/type:pwm-fan

Fan is working but shutdown is immediate.

What about cpufreq as cooling device? Probably that part
is missing now, right?

Best regards,
Krzysztof


From lkp at intel.com  Sat Feb 13 22:09:11 2016
From: lkp at intel.com (kbuild test robot)
Date: Sun, 14 Feb 2016 14:09:11 +0800
Subject: [PATCH 3/5] irqchip: add platform device driver for mbigen device
In-Reply-To: <1455416191-23616-4-git-send-email-majun258@huawei.com>
Message-ID: <201602141423.fn5CCDUC%fengguang.wu@intel.com>

Hi Ma,

[auto build test ERROR on tip/irq/core]
[also build test ERROR on v4.5-rc3 next-20160212]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/MaJun/irqchip-Add-support-for-Hisilicon-mbigen-v1-chip/20160214-101957
config: arm64-defconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=arm64 

Note: the linux-review/MaJun/irqchip-Add-support-for-Hisilicon-mbigen-v1-chip/20160214-101957 HEAD 9acb433456cd9671c97c0eeb1ccca8cc3b986081 builds fine.
      It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   drivers/irqchip/irq-mbigen-v1.c: In function 'mbigen_device_probe':
>> drivers/irqchip/irq-mbigen-v1.c:47:2: error: implicit declaration of function 'devm_ioremap' [-Werror=implicit-function-declaration]
     mgn_chip->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
     ^
>> drivers/irqchip/irq-mbigen-v1.c:47:17: warning: assignment makes pointer from integer without a cast
     mgn_chip->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
                    ^
   cc1: some warnings being treated as errors

vim +/devm_ioremap +47 drivers/irqchip/irq-mbigen-v1.c

    41		if (!mgn_chip)
    42			return -ENOMEM;
    43	
    44		mgn_chip->pdev = pdev;
    45	
    46		res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
  > 47		mgn_chip->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
    48		if (IS_ERR(mgn_chip->base))
    49			return PTR_ERR(mgn_chip->base);
    50	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 21180 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160214/d5d583fd/attachment-0001.obj>

From k.kozlowski at samsung.com  Sat Feb 13 22:44:53 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Sun, 14 Feb 2016 15:44:53 +0900
Subject: [PATCH] ARM: dts: Move syscon reboot/poweroff to common dtsi for
 Exynos
In-Reply-To: <1455042606-10075-1-git-send-email-javier@osg.samsung.com>
References: <1455042606-10075-1-git-send-email-javier@osg.samsung.com>
Message-ID: <56C02265.40103@samsung.com>

W dniu 10.02.2016 o 03:30, Javier Martinez Canillas pisze:
> All Exynos SoCs have the same syscon reboot and poweroff device nodes so
> there is no need to duplicate the same on each SoC dtsi and can be moved
> to a common dtsi that can be included by all the SoCs dtsi files.
> 
> Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
> 
> ---
> Hello,
> 
> The patch was tested on an Exynos5800 Peach Pi Chromebook and an
> Exynos5422 Odroid XU4 board. Reboot and poweroff worked for both.
> 
> But testing on Exynos3 and Exynos4 will be highly appreciated.

Would you be so kind and add my suggested-by (since it comes from
https://wiki.tizen.org/wiki/Exynos_Mainline_Kernel_TODO :) )

I'll test it on Exynos4 at work and then apply... but few comments below:

> 
> Best regards,
> Javier
> 
>  arch/arm/boot/dts/exynos-syscon-restart.dtsi | 23 +++++++++++++++++++++++
>  arch/arm/boot/dts/exynos3250.dtsi            | 15 +--------------
>  arch/arm/boot/dts/exynos4.dtsi               | 15 +--------------
>  arch/arm/boot/dts/exynos5.dtsi               | 15 +--------------
>  arch/arm/boot/dts/exynos5410.dtsi            | 15 +--------------
>  5 files changed, 27 insertions(+), 56 deletions(-)
>  create mode 100644 arch/arm/boot/dts/exynos-syscon-restart.dtsi
> 
> diff --git a/arch/arm/boot/dts/exynos-syscon-restart.dtsi b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
> new file mode 100644
> index 000000000000..2b8acf554881
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
> @@ -0,0 +1,23 @@
> +/*
> + * Samsung's Exynos SoC syscon reboot/poweroff nodes common definition.
> + *
> + * 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.
> + */
> +
> +/ {

In some of the DTSI this was under "soc" node, not at top-level.
Unfortunately we do not have consistency here - some DTSI have "soc",
some not. Anyway I think we should move to "soc" version.

> +	poweroff: syscon-poweroff {
> +		compatible = "syscon-poweroff";
> +		regmap = <&pmu_system_controller>;
> +		offset = <0x330C>; /* PS_HOLD_CONTROL */
> +		mask = <0x5200>; /* reset value */
> +	};
> +
> +	reboot: syscon-reboot {
> +		compatible = "syscon-reboot";
> +		regmap = <&pmu_system_controller>;
> +		offset = <0x0400>; /* SWRESET */
> +		mask = <0x1>;
> +	};
> +};
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
> index 18e3deffbf48..d9c221517935 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -19,6 +19,7 @@
>  
>  #include "skeleton.dtsi"
>  #include "exynos4-cpu-thermal.dtsi"
> +#include "exynos-syscon-restart.dtsi"
>  #include <dt-bindings/clock/exynos3250.h>
>  
>  / {
> @@ -152,20 +153,6 @@
>  			interrupt-parent = <&gic>;
>  		};
>  
> -		poweroff: syscon-poweroff {
> -			compatible = "syscon-poweroff";
> -			regmap = <&pmu_system_controller>;
> -			offset = <0x330C>; /* PS_HOLD_CONTROL */
> -			mask = <0x5200>; /* Reset value */
> -		};
> -
> -		reboot: syscon-reboot {
> -			compatible = "syscon-reboot";
> -			regmap = <&pmu_system_controller>;
> -			offset = <0x0400>; /* SWRESET */
> -			mask = <0x1>;
> -		};
> -
>  		mipi_phy: video-phy at 10020710 {
>  			compatible = "samsung,s5pv210-mipi-video-phy";
>  			#phy-cells = <1>;
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index ca621a92319e..e6f6939ccdfa 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -21,6 +21,7 @@
>  
>  #include <dt-bindings/clock/exynos4.h>
>  #include <dt-bindings/clock/exynos-audss-clk.h>
> +#include "exynos-syscon-restart.dtsi"

Just to keep it consistent and logic - include after skeleton.

Best regards,
Krzysztof


From shawnguo at kernel.org  Sat Feb 13 22:54:18 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 14:54:18 +0800
Subject: [PATCH v5 0/2] ARM: dts: imx6: Add support for Toradex Apalis
 iMX6Q/D SoM/Ixora carrier board
In-Reply-To: <1454688741-4238-1-git-send-email-marcel.ziswiler@toradex.com>
References: <1454688741-4238-1-git-send-email-marcel.ziswiler@toradex.com>
Message-ID: <20160214065418.GH6756@tiger>

On Fri, Feb 05, 2016 at 05:12:19PM +0100, Marcel Ziswiler wrote:
> Petr ?tetiar (2):
>   ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM
>   ARM: dts: imx6: Add support for Toradex Ixora carrier board

Applied both, thanks.


From shawnguo at kernel.org  Sat Feb 13 23:02:39 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 15:02:39 +0800
Subject: [PATCH 1/1 v3] ARM: dts: imx6dlq-wandboard-revb1.dts: use unique
 model id
In-Reply-To: <1454892908-26975-1-git-send-email-xypron.glpk@gmx.de>
References: <56B7E06B.2060701@gmx.de>
 <1454892908-26975-1-git-send-email-xypron.glpk@gmx.de>
Message-ID: <20160214070239.GI6756@tiger>

On Mon, Feb 08, 2016 at 01:55:08AM +0100, Heinrich Schuchardt wrote:
> Downstream packages like Debian flash-kernel use
> /proc/device-tree/model
> to determine which dtb file to install.
> 
> Hence each dts in the Linux kernel should provide a unique model
> identifier.
> 
> Commit 8536239e371f ("ARM: dts: Restructure imx6qdl-wandboard.dtsi for new
> rev C1 board.")' created new files imx6dl-wandboard-revb1.dts and
> imx6q-wandboard-revb1.dts but used the same model identifier as in
> imx6dl-wandboard.dts and imx6q-wandboard.dts.
> 
> This patch provides unique model identifiers for revision B1 of
> the Wandboard Dual and Wandbaord Quad.
> 
> The patch leaves imx6dl-wandboard.dts and imx6q-wandboard.dts unchanged
> because it is not foreseeable if the same dts will valid for future
> board revisions or not. Furthermore we should avoid unnecessary
> changes.
> 
> v3:
> 	update imx6dl-wandboard-revb1.dts
> 
> v2:
> 	correct name of referenced Debian package
> 
> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>

Applied, thanks.


From shawnguo at kernel.org  Sat Feb 13 23:20:40 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 15:20:40 +0800
Subject: [PATCH 1/4] ARM: dts: imx6q-tbs2910: add SATA PHY configuration
In-Reply-To: <1454870073-6506-1-git-send-email-smoch@web.de>
References: <1454870073-6506-1-git-send-email-smoch@web.de>
Message-ID: <20160214072039.GJ6756@tiger>

On Sun, Feb 07, 2016 at 07:34:30PM +0100, Soeren Moch wrote:
> Configure SATA PHY transmit level, boost, attenuation and equalizer
> parameters for long wire connections. TBS2910 contains a standard SATA
> connector, so devices are typically connected with (longer) SATA cables.
> And explicitly configuring these parameters avoids complaints about
> "not specified" values in boot messages.
> 
> Signed-off-by: Soeren Moch <smoch at web.de>

Applied all, thanks.


From shawnguo at kernel.org  Sat Feb 13 23:23:15 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 15:23:15 +0800
Subject: [PATCH] ARM: imx_v6_v7_defconfig: Select CONFIG_CRYPTO_DEV_SAHARA
In-Reply-To: <1454962073-22401-1-git-send-email-festevam@gmail.com>
References: <1454962073-22401-1-git-send-email-festevam@gmail.com>
Message-ID: <20160214072315.GK6756@tiger>

On Mon, Feb 08, 2016 at 06:07:53PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at nxp.com>
> 
> Select the sahara crypto driver that is used on i.MX53.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam at nxp.com>

Applied, thanks.


From shawnguo at kernel.org  Sat Feb 13 23:42:18 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 15:42:18 +0800
Subject: [PATCH] ARM: dts: ls2080a: Add quirk for Erratum A009116
In-Reply-To: <1455059287-2500-1-git-send-email-Lijun.Pan@freescale.com>
References: <1455059287-2500-1-git-send-email-Lijun.Pan@freescale.com>
Message-ID: <20160214074218.GL6756@tiger>

On Tue, Feb 09, 2016 at 05:08:07PM -0600, Lijun Pan wrote:
> Add "snps,quirk-frame-length-adjustment" property to
> USB3 node for erratum A009116. This property provides
> value of GFLADJ_30MHZ for post silicon frame length
> adjustment.
> 
> Signed-off-by: Lijun Pan <Lijun.Pan at freescale.com>

Applied, thanks.


From shawnguo at kernel.org  Sat Feb 13 23:43:45 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 15:43:45 +0800
Subject: [PATCH] ARM: dts: ls1043a: Add quirk for Erratum A009116
In-Reply-To: <1455080987-30786-1-git-send-email-rajesh.bhagat@freescale.com>
References: <1455080987-30786-1-git-send-email-rajesh.bhagat@freescale.com>
Message-ID: <20160214074345.GM6756@tiger>

On Wed, Feb 10, 2016 at 10:39:47AM +0530, Rajesh Bhagat wrote:
> Add "snps,quirk-frame-length-adjustment" property to USB3 node for erratum A009116.
> This property provides value of GFLADJ_30MHZ for post silicon frame length adjustment.

The commit log should be generally wrapped around column 70.  I fixed
it up and applied patch.

Shawn

> 
> Signed-off-by: Rajesh Bhagat <rajesh.bhagat at freescale.com>
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> index 42a6154..be72bf5 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
> @@ -407,6 +407,7 @@
>  			reg = <0x0 0x2f00000 0x0 0x10000>;
>  			interrupts = <0 60 0x4>;
>  			dr_mode = "host";
> +			snps,quirk-frame-length-adjustment = <0x20>;
>  		};
>  
>  		usb1: usb3 at 3000000 {
> @@ -414,6 +415,7 @@
>  			reg = <0x0 0x3000000 0x0 0x10000>;
>  			interrupts = <0 61 0x4>;
>  			dr_mode = "host";
> +			snps,quirk-frame-length-adjustment = <0x20>;
>  		};
>  
>  		usb2: usb3 at 3100000 {
> @@ -421,6 +423,7 @@
>  			reg = <0x0 0x3100000 0x0 0x10000>;
>  			interrupts = <0 63 0x4>;
>  			dr_mode = "host";
> +			snps,quirk-frame-length-adjustment = <0x20>;
>  		};
>  
>  		sata: sata at 3200000 {
> -- 
> 2.6.2.198.g614a2ac
> 
> 


From shawnguo at kernel.org  Sat Feb 13 23:49:16 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 15:49:16 +0800
Subject: [PATCH 1/2] ARM: dts: vf610twr: assign Ethernet clock explicitly
In-Reply-To: <1455148946-26903-1-git-send-email-stefan@agner.ch>
References: <1455148946-26903-1-git-send-email-stefan@agner.ch>
Message-ID: <20160214074916.GN6756@tiger>

On Wed, Feb 10, 2016 at 04:02:25PM -0800, Stefan Agner wrote:
> Assign Ethernet clock parents explicitly. The VF610 Tower Board
> uses the external Ethernet clock input which is connected to
> a 50MHz clock.
> 
> The Vybrid SoC has two ethernet interfaces (fec0 and fec1) which
> use the same clock source (VF610_CLK_ENET). Therefore this parent
> configuration affects multiple consumer devices and need to be
> specified in the clock provider node.
> 
> Signed-off-by: Stefan Agner <stefan at agner.ch>

Applied both, thanks.


From shawnguo at kernel.org  Sat Feb 13 23:53:08 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 15:53:08 +0800
Subject: [PATCH] ARM: imx_v6_v7_defconfig: enable useful configurations
 for Vybrid
In-Reply-To: <1455156498-29949-1-git-send-email-stefan@agner.ch>
References: <1455156498-29949-1-git-send-email-stefan@agner.ch>
Message-ID: <20160214075308.GO6756@tiger>

On Wed, Feb 10, 2016 at 06:08:18PM -0800, Stefan Agner wrote:
> Enable configuration options useful for Vybrid:
> - NFC NAND driver
> - USB dual-role controller support
> - FTM PWM driver
> - DSPI SPI driver
> - Colibri VF50 Touchscreen support.
> 
> Beside that, enable useful configurations such as IIO hwmon support
> (used in i.MX 23/28, patch pending for Vybrid), PWM LED support and
> CPU idle support.
> 
> Regenerated config using savedefconfig (which removes some configs
> which are now enabled by default).
> 
> Signed-off-by: Stefan Agner <stefan at agner.ch>

Applied, thanks.


From shawnguo at kernel.org  Sat Feb 13 23:55:57 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 15:55:57 +0800
Subject: [PATCH 1/3] Documentation: devicetree: add Freescale SCC bindings
In-Reply-To: <1455199485-24458-1-git-send-email-s.trumtrar@pengutronix.de>
References: <1455199485-24458-1-git-send-email-s.trumtrar@pengutronix.de>
Message-ID: <20160214075557.GP6756@tiger>

On Thu, Feb 11, 2016 at 03:04:43PM +0100, Steffen Trumtrar wrote:
> Add documentation for the Freescale Security Controller (SCC)
> found on i.MX25 SoCs.
> 
> Signed-off-by: Steffen Trumtrar <s.trumtrar at pengutronix.de>
> ---
>  .../devicetree/bindings/crypto/fsl-imx-scc.txt          | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
> 
> diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
> new file mode 100644
> index 000000000000..9a15ab8da94f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
> @@ -0,0 +1,17 @@
> +Freescale Security Controller (SCC)
> +
> +Required properties:
> +- compatible : Should be "fsl,imx25-scc".
> +- reg : Should contain register location and length.
> +- interrupts : Should contain interrupt numbers for SCM IRQ and SMN IRQ.
> +
> +Example:
> +
> +	scc: crypto at 53fac000 {
> +		compatible = "fsl,imx25-scc";
> +		reg = <0x53fac000 0x4000>;
> +		clocks = <&clks 111>;
> +		clock-names = "ipg";

Shouldn't these two be mentioned in properties list above too?

Shawn

> +		interrupts = <49>, <50>;
> +		interrupt-names = "scm", "smn";
> +	};
> -- 
> 2.7.0.rc3
> 
> 


From ard.biesheuvel at linaro.org  Sat Feb 13 23:57:36 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Sun, 14 Feb 2016 08:57:36 +0100
Subject: [PATCH] [media] zl10353: use div_u64 instead of do_div
In-Reply-To: <alpine.LFD.2.20.1602131652560.13632@knanqh.ubzr>
References: <1455287246-3540549-1-git-send-email-arnd@arndb.de>
 <2712691.b9gkR7KMX7@wuerfel>
 <alpine.LFD.2.20.1602121305180.13632@knanqh.ubzr>
 <6737272.LXr2g355Yt@wuerfel>
 <CAKv+Gu8dFz28tGgQTv+WYAvKpeiFXaj8JANUFtOJwKPRsB8F5A@mail.gmail.com>
 <alpine.LFD.2.20.1602131652560.13632@knanqh.ubzr>
Message-ID: <CAKv+Gu9YWEkArjssR9Urh0_MOR3duNOo2UNiV=tXoQNgFtDngQ@mail.gmail.com>

On 13 February 2016 at 22:57, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> On Sat, 13 Feb 2016, Ard Biesheuvel wrote:
>
>> On 12 February 2016 at 22:01, Arnd Bergmann <arnd at arndb.de> wrote:
>> > However, I did stumble over an older patch I did now, which I could
>> > not remember what it was good for. It does fix the problem, and
>> > it seems to be a better solution.
>> >
>> >         Arnd
>> >
>> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
>> > index b5acbb404854..b5ff9881bef8 100644
>> > --- a/include/linux/compiler.h
>> > +++ b/include/linux/compiler.h
>> > @@ -148,7 +148,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
>> >   */
>> >  #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
>> >  #define __trace_if(cond) \
>> > -       if (__builtin_constant_p((cond)) ? !!(cond) :                   \
>> > +       if (__builtin_constant_p(!!(cond)) ? !!(cond) :                 \
>> >         ({                                                              \
>> >                 int ______r;                                            \
>> >                 static struct ftrace_branch_data                        \
>> >
>>
>> I remember seeing this patch, but I don't remember the exact context.
>> But when you think about it, !!cond can be a build time constant even
>> if cond is not, as long as you can prove statically that cond != 0. So
>
> You're right.  I just tested it and to my surprise gcc is smart enough
> to figure that case out.
>
>> I think this change is obviously correct, and an improvement since it
>> will remove the profiling overhead of branches that are not true
>> branches in the first place.
>
> Indeed.
>

... and perhaps we should not evaluate cond twice either?


From hanjun.guo at linaro.org  Sun Feb 14 00:06:23 2016
From: hanjun.guo at linaro.org (Hanjun Guo)
Date: Sun, 14 Feb 2016 16:06:23 +0800
Subject: [PATCH V3 06/10] irqchip, GICv3, ITS: Refator ITS dt init code to
 prepare for ACPI.
In-Reply-To: <56BB1548.5050402@arm.com>
References: <1453209083-3358-1-git-send-email-tn@semihalf.com>
 <1453209083-3358-7-git-send-email-tn@semihalf.com> <56BB1548.5050402@arm.com>
Message-ID: <56C0357F.9010904@linaro.org>

On 2016/2/10 18:47, Marc Zyngier wrote:
> On 19/01/16 13:11, Tomasz Nowicki wrote:
>> Similarly to GICv3 core, we need to extract common code before adding
>> ACPI support. No functional changes.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
>> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
>> ---
>>   drivers/irqchip/irq-gic-v3-its.c   | 82 +++++++++++++++++++++++---------------
>>   drivers/irqchip/irq-gic-v3.c       |  6 +--
>>   include/linux/irqchip/arm-gic-v3.h |  2 +-
>>   3 files changed, 52 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index 2bbed18..fecb7a6 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -813,7 +813,7 @@ static void its_free_tables(struct its_node *its)
>>   	}
>>   }
>>
>> -static int its_alloc_tables(const char *node_name, struct its_node *its)
>> +static int its_alloc_tables(struct its_node *its)
>>   {
>>   	int err;
>>   	int i;
>> @@ -868,8 +868,8 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
>>   				    order);
>>   			if (order >= MAX_ORDER) {
>>   				order = MAX_ORDER - 1;
>> -				pr_warn("%s: Device Table too large, reduce its page order to %u\n",
>> -					node_name, order);
>> +				pr_warn("ITS at 0x%lx: Device Table too large, reduce its page order to %u\n",
>> +					its->phys_base, order);
>>   			}
>>   		}
>>
>> @@ -878,8 +878,8 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
>>   		if (alloc_pages > GITS_BASER_PAGES_MAX) {
>>   			alloc_pages = GITS_BASER_PAGES_MAX;
>>   			order = get_order(GITS_BASER_PAGES_MAX * psz);
>> -			pr_warn("%s: Device Table too large, reduce its page order to %u (%u pages)\n",
>> -				node_name, order, alloc_pages);
>> +			pr_warn("ITS at 0x%lx: Device Table too large, reduce its page order to %u (%u pages)\n",
>> +				its->phys_base, order, alloc_pages);
>>   		}
>>
>>   		base = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
>> @@ -948,8 +948,8 @@ retry_baser:
>>   		}
>>
>>   		if (val != tmp) {
>> -			pr_err("ITS: %s: GITS_BASER%d doesn't stick: %lx %lx\n",
>> -			       node_name, i,
>> +			pr_err("ITS at 0x%lx: GITS_BASER%d doesn't stick: %lx %lx\n",
>> +			       its->phys_base, i,
>>   			       (unsigned long) val, (unsigned long) tmp);
>>   			err = -ENXIO;
>>   			goto out_free;
>> @@ -1424,10 +1424,11 @@ static void its_enable_quirks(struct its_node *its)
>>   	gic_enable_quirks(iidr, its_quirks, its);
>>   }
>>
>> -static int __init its_probe(struct device_node *node,
>> -			    struct irq_domain *parent)
>> +static int __init its_probe_one(phys_addr_t phys_base, unsigned long size,
>> +				struct irq_domain *parent,
>> +				bool is_msi_controller,
>
> I really question the fact that you are keeping this msi_controller
> thing. Let's face it: if this is not an MSI controller, then the whole
> thing is absolutely pointless.
>
> So I'd rather you simplify the whole in a separate patch, and just don't
> bother initializing the ITS if it cannot be used for MSIs.

Agree, that will simplify the code a lot.

Thanks
Hanjun


From shawnguo at kernel.org  Sun Feb 14 00:18:57 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 16:18:57 +0800
Subject: [PATCH] ARM: imx: Do L2 errata only if the L2 cache isn't enabled
In-Reply-To: <56BDFF64.9090701@gmail.com>
References: <1455261093-11849-1-git-send-email-dirk.behme@de.bosch.com>
 <20160212141654.GA10826@n2100.arm.linux.org.uk>
 <56BDFF64.9090701@gmail.com>
Message-ID: <20160214081857.GQ6756@tiger>

On Fri, Feb 12, 2016 at 04:51:00PM +0100, Dirk Behme wrote:
> On 12.02.2016 15:16, Russell King - ARM Linux wrote:
> >On Fri, Feb 12, 2016 at 08:11:33AM +0100, Dirk Behme wrote:
> >>All the generic L2 cache handling code is encapsulated by a
> >>check if the L2 cache is enabled. If it's enabled already, the code
> >>is skipped.
> >>
> >>For the i.MX6 specific L2 cache handling we missed this check.
> >>Add it.
> >
> >What's the reasoning behind this?  The prefetch register is writable
> >while the L2 cache is enabled, unlike the auxiliary control register.
> 
> From an internal log I have the following info:
> 
> The write to the L2-Cache controller from non-secure world causes an
> imprecise
> external abort. If Linux runs from normal world the cache controller
> is already
> enabled and thus no configuration is needed by Linux.

Dirk,

Do you have a real use case of this, i.e. running Linux on i.MX6 in
non-secure world?

Shawn


From dirk.behme at gmail.com  Sun Feb 14 00:30:06 2016
From: dirk.behme at gmail.com (Dirk Behme)
Date: Sun, 14 Feb 2016 09:30:06 +0100
Subject: [PATCH] ARM: imx: Do L2 errata only if the L2 cache isn't enabled
In-Reply-To: <20160214081857.GQ6756@tiger>
References: <1455261093-11849-1-git-send-email-dirk.behme@de.bosch.com>
 <20160212141654.GA10826@n2100.arm.linux.org.uk> <56BDFF64.9090701@gmail.com>
 <20160214081857.GQ6756@tiger>
Message-ID: <56C03B0E.9000809@gmail.com>

On 14.02.2016 09:18, Shawn Guo wrote:
> On Fri, Feb 12, 2016 at 04:51:00PM +0100, Dirk Behme wrote:
>> On 12.02.2016 15:16, Russell King - ARM Linux wrote:
>>> On Fri, Feb 12, 2016 at 08:11:33AM +0100, Dirk Behme wrote:
>>>> All the generic L2 cache handling code is encapsulated by a
>>>> check if the L2 cache is enabled. If it's enabled already, the code
>>>> is skipped.
>>>>
>>>> For the i.MX6 specific L2 cache handling we missed this check.
>>>> Add it.
>>>
>>> What's the reasoning behind this?  The prefetch register is writable
>>> while the L2 cache is enabled, unlike the auxiliary control register.
>>
>>  From an internal log I have the following info:
>>
>> The write to the L2-Cache controller from non-secure world causes an
>> imprecise
>> external abort. If Linux runs from normal world the cache controller
>> is already
>> enabled and thus no configuration is needed by Linux.
>
> Dirk,
>
> Do you have a real use case of this, i.e. running Linux on i.MX6 in
> non-secure world?


Yes, in a scenario where one of the cores runs a RTOS.


Best regards

Dirk



From shawnguo at kernel.org  Sun Feb 14 00:33:49 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 16:33:49 +0800
Subject: [PATCH v2] ARM: dts: vfxxx: Add iio_hwmon node for ADC
 temperature channel
In-Reply-To: <cd32f1664a04b38b8a025414d039bd015cb9a5ff.1455278754.git.maitysanchayan@gmail.com>
References: <cd32f1664a04b38b8a025414d039bd015cb9a5ff.1455278754.git.maitysanchayan@gmail.com>
Message-ID: <20160214083349.GR6756@tiger>

On Fri, Feb 12, 2016 at 05:53:00PM +0530, Sanchayan Maity wrote:
> Add iio_hwmon node to expose the temperature channel on Vybrid as
> hardware monitor device using the iio_hwmon driver.
> 
> Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
> ---
> 
> Hello,
> 
> The first version of the patch was send quite a while ago.
> https://lkml.org/lkml/2015/9/16/932
> 
> Shawn you had requested that hyphen rather than underscore should
> be used in node name. I looked into that.
> 
> The iio_hwmon driver calls hwmon_device register_with_groups inside
> hwmon.c and this
> http://lxr.free-electrons.com/source/drivers/hwmon/hwmon.c#L103
> 
> does not allow hyphen in hwmon name attribute. I was not aware of
> this but while trying to test the change, the device probe failed
> with EINVAL. I think we should stick to the existing use of the
> bindings or we need to change the hwmon code as well along with the
> existing device tree files and binding documentation.

I disagree.

If hyphen is invalid to be part of hwmon name attribute, the following
code in iio_hwmon_probe() is plain wrong, because hyphen is very valid
to be part of node names in device tree.

        if (dev->of_node && dev->of_node->name)
                name = dev->of_node->name;

Shawn

> 
> Changes since v1:
> 1. Expose ADC1 temperature channel as well
> 2. Move the entry outside of the aips1 bus node
> 
> Best Regards,
> Sanchayan Maity.
> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index a5f07e3..8ed8e47 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -673,5 +673,10 @@
>  				status = "disabled";
>  			};
>  		};
> +
> +		iio_hwmon {
> +			compatible = "iio-hwmon";
> +			io-channels = <&adc0 16>, <&adc1 16>;
> +		};
>  	};
>  };
> -- 
> 2.7.1
> 
> 


From shawnguo at kernel.org  Sun Feb 14 00:47:14 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 16:47:14 +0800
Subject: [PATCH] ARM: dts: ls2080a: Add quirk for Erratum A009116
In-Reply-To: <1455059287-2500-1-git-send-email-Lijun.Pan@freescale.com>
References: <1455059287-2500-1-git-send-email-Lijun.Pan@freescale.com>
Message-ID: <20160214084714.GS6756@tiger>

On Tue, Feb 09, 2016 at 05:08:07PM -0600, Lijun Pan wrote:
> Add "snps,quirk-frame-length-adjustment" property to
> USB3 node for erratum A009116. This property provides
> value of GFLADJ_30MHZ for post silicon frame length
> adjustment.
> 
> Signed-off-by: Lijun Pan <Lijun.Pan at freescale.com>
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |    2 ++
>  1 file changed, 2 insertions(+)

Forgot to mention that arm64 patches use a different subject prefix from
ARM ones.  I changed the patch subject to "arm64: dts: ..." when
applying.

Shawn

> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> index 6e9e033..fa506f5 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> @@ -501,6 +501,7 @@
>  			reg = <0x0 0x3100000 0x0 0x10000>;
>  			interrupts = <0 80 0x4>; /* Level high type */
>  			dr_mode = "host";
> +			snps,quirk-frame-length-adjustment = <0x20>;
>  		};
>  
>  		usb1: usb3 at 3110000 {
> @@ -509,6 +510,7 @@
>  			reg = <0x0 0x3110000 0x0 0x10000>;
>  			interrupts = <0 81 0x4>; /* Level high type */
>  			dr_mode = "host";
> +			snps,quirk-frame-length-adjustment = <0x20>;
>  		};
>  
>  		ccn at 4000000 {
> -- 
> 1.7.9.5
> 
> 


From k.kozlowski at samsung.com  Sun Feb 14 00:52:30 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Sun, 14 Feb 2016 17:52:30 +0900
Subject: lockdep: INFO: possible irq lock inversion dependency detected on
 Odroid U3
In-Reply-To: <CANAwSgRgFMNWGhTe7xsHqkQQ1JS0XW6pO8LT8c6rZm=3cEBcbg@mail.gmail.com>
References: <CANAwSgRgFMNWGhTe7xsHqkQQ1JS0XW6pO8LT8c6rZm=3cEBcbg@mail.gmail.com>
Message-ID: <56C0404E.7080707@samsung.com>

W dniu 10.02.2016 o 16:27, Anand Moon pisze:
> Hi all,
> 
> I am observing following lockdep info.

Hi,

Thanks for report. When pasting dmesg output, please do not wrap the
lines because it is difficult to read it.

This looks like known issue:
https://wiki.tizen.org/wiki/Exynos_Mainline_Kernel_TODO/Odroid_XU3_lockdep_warn_during_music_playback

Waiting for someone brave enough to fix it...

But actually more important item is following real lockup, failing
multi_v7 boot ~20% of times:
http://www.krzk.eu/builders/boot-odroid-xu3-multi_v7/builds/34
http://www.krzk.eu/builders/boot-odroid-xu3-multi_v7

Best regards,
Krzysztof

> 
> [  139.806823] =========================================================
> [  139.811934] [ INFO: possible irq lock inversion dependency detected ]
> [  139.818362] 4.5.0-rc3-u3s #11 Tainted: G        W
> [  139.823566] ---------------------------------------------------------
> [  139.829990] swapper/0/0 just changed the state of lock:
> [  139.835197]  (&(&substream->self_group.lock)->rlock){..-...}, at:
> [<c04e03cc>] _snd_pcm_stream_lock_irqsave+0x34/0x40
> [  139.845788] but this lock took another, SOFTIRQ-unsafe lock in the past:
> [  139.852468]  (&(&pri_dai->spinlock)->rlock){+.+...}
> 
> and interrupts could create inverse lock ordering between them.
> 
> [  139.863319]
> [  139.863319] other info that might help us debug this:
> [  139.869830]  Possible interrupt unsafe locking scenario:
> [  139.869830]
> [  139.876599]        CPU0                    CPU1
> [  139.881113]        ----                    ----
> [  139.885626]   lock(&(&pri_dai->spinlock)->rlock);
> [  139.890314]                                local_irq_disable();
> [  139.896216]
> lock(&(&substream->self_group.lock)->rlock);
> [  139.904201]
> lock(&(&pri_dai->spinlock)->rlock);
> [  139.911405]   <Interrupt>
> [  139.914009]     lock(&(&substream->self_group.lock)->rlock);
> [  139.919652]
> [  139.919652]  *** DEADLOCK ***
> [  139.919652]
> [  139.925558] 1 lock held by swapper/0/0:
> [  139.929374]  #0:  (snd_pcm_link_rwlock){...-..}, at: [<c04e0330>]
> snd_pcm_stream_lock+0x20/0x50
> [  139.938054]
> [  139.938054] the shortest dependencies between 2nd lock and 1st lock:
> [  139.945893]  -> (&(&pri_dai->spinlock)->rlock){+.+...} ops: 37 {
> [  139.951856]     HARDIRQ-ON-W at:
> [  139.955067]                       [<c066b89c>] _raw_spin_lock+0x3c/0x74
> [  139.961663]                       [<c0500558>] i2s_set_sysclk+0x40/0x464
> [  139.968347]                       [<c0500e0c>]
> samsung_i2s_dai_probe+0x238/0x2b0
> [  139.975725]                       [<c04ed5f8>] soc_probe_dai.part.2+0x30/0x6c
> [  139.982842]                       [<c04ee1b8>]
> snd_soc_register_card+0x854/0xe64
> [  139.990220]                       [<c04f9b0c>]
> devm_snd_soc_register_card+0x38/0x70
> [  139.997859]                       [<c04ff0f8>]
> asoc_simple_card_probe+0x224/0x460
> [  140.005323]                       [<c036da6c>] platform_drv_probe+0x4c/0xb0
> [  140.012267]                       [<c036c2ac>]
> driver_probe_device+0x20c/0x2b8
> [  140.019472]                       [<c036a644>] bus_for_each_drv+0x60/0x94
> [  140.026242]                       [<c036bfc0>] __device_attach+0xb4/0x118
> [  140.033013]                       [<c036b464>] bus_probe_device+0x88/0x90
> [  140.039783]                       [<c036b900>]
> deferred_probe_work_func+0x6c/0x9c
> [  140.047248]                       [<c0043408>] process_one_work+0x1a8/0x514
> [  140.054192]                       [<c00437ac>] worker_thread+0x38/0x574
> [  140.060789]                       [<c0049c0c>] kthread+0xf4/0x10c
> [  140.066865]                       [<c000f890>] ret_from_fork+0x14/0x24
> [  140.073376]     SOFTIRQ-ON-W at:
> [  140.076587]                       [<c066b89c>] _raw_spin_lock+0x3c/0x74
> [  140.083183]                       [<c0500558>] i2s_set_sysclk+0x40/0x464
> [  140.089867]                       [<c0500e0c>]
> samsung_i2s_dai_probe+0x238/0x2b0
> [  140.097245]                       [<c04ed5f8>] soc_probe_dai.part.2+0x30/0x6c
> [  140.104362]                       [<c04ee1b8>]
> snd_soc_register_card+0x854/0xe64
> [  140.111740]                       [<c04f9b0c>]
> devm_snd_soc_register_card+0x38/0x70
> [  140.119379]                       [<c04ff0f8>]
> asoc_simple_card_probe+0x224/0x460
> [  140.126843]                       [<c036da6c>] platform_drv_probe+0x4c/0xb0
> [  140.133787]                       [<c036c2ac>]
> driver_probe_device+0x20c/0x2b8
> [  140.140992]                       [<c036a644>] bus_for_each_drv+0x60/0x94
> [  140.147762]                       [<c036bfc0>] __device_attach+0xb4/0x118
> [  140.154533]                       [<c036b464>] bus_probe_device+0x88/0x90
> [  140.161303]                       [<c036b900>]
> deferred_probe_work_func+0x6c/0x9c
> [  140.168768]                       [<c0043408>] process_one_work+0x1a8/0x514
> [  140.175712]                       [<c00437ac>] worker_thread+0x38/0x574
> [  140.182309]                       [<c0049c0c>] kthread+0xf4/0x10c
> [  140.188385]                       [<c000f890>] ret_from_fork+0x14/0x24
> [  140.194896]     INITIAL USE at:
> [  140.198020]                      [<c066bb14>]
> _raw_spin_lock_irqsave+0x48/0x84
> [  140.205224]                      [<c04c2d44>] clk_divider_set_rate+0x40/0xc0
> [  140.212255]                      [<c04c1320>] clk_change_rate+0x17c/0x210
> [  140.219025]                      [<c04c12b8>] clk_change_rate+0x114/0x210
> [  140.225796]   }
> [  140.227532]   ... key      at: [<c13e2f04>] __key.37532+0x0/0x8
> [  140.233435]   ... acquired at:
> [  140.236472]    [<c04ffb18>] i2s_trigger+0x40/0x62c
> [  140.241246]    [<c04f4d14>] soc_pcm_trigger+0xd0/0x11c
> [  140.246367]    [<c04dfe58>] snd_pcm_action_single+0x38/0x80
> [  140.251922]    [<c04e1dac>] snd_pcm_common_ioctl1+0x3bc/0xe20
> [  140.257651]    [<c04e29b4>] snd_pcm_playback_ioctl1+0x1a4/0x69c
> [  140.263553]    [<c01343f8>] do_vfs_ioctl+0xa0/0x9d4
> [  140.268414]    [<c0134d60>] SyS_ioctl+0x34/0x5c
> [  140.272927]    [<c000f800>] ret_fast_syscall+0x0/0x1c
> [  140.277962]
> [  140.279438] -> (&(&substream->self_group.lock)->rlock){..-...} ops: 153 {
> [  140.286209]    IN-SOFTIRQ-W at:
> [  140.289333]                     [<c066b89c>] _raw_spin_lock+0x3c/0x74
> [  140.295757]                     [<c04e03cc>]
> _snd_pcm_stream_lock_irqsave+0x34/0x40
> [  140.303395]                     [<c04e6f44>] snd_pcm_period_elapsed+0x1c/0xa0
> [  140.310512]                     [<c02de5b0>] pl330_tasklet+0x198/0x518
> [  140.317022]                     [<c002e424>] tasklet_action+0xac/0x164
> [  140.323532]                     [<c002e6ac>] __do_softirq+0x168/0x2c0
> [  140.329955]                     [<c002eba8>] irq_exit+0xec/0x128
> [  140.335945]                     [<c0087314>] __handle_domain_irq+0x80/0xec
> [  140.342802]                     [<c0009514>] gic_handle_irq+0x54/0x94
> [  140.349225]                     [<c00144f8>] __irq_svc+0x58/0x98
> [  140.355214]                     [<c00102f8>] arch_cpu_idle+0x24/0x3c
> [  140.361551]                     [<c00102f8>] arch_cpu_idle+0x24/0x3c
> [  140.367887]                     [<c006d5d4>] cpu_startup_entry+0x1f4/0x280
> [  140.374744]                     [<c08c8ccc>] start_kernel+0x3ec/0x3f8
> [  140.381169]    INITIAL USE at:
> [  140.384205]                    [<c066b89c>] _raw_spin_lock+0x3c/0x74
> [  140.390542]                    [<c04e0850>] snd_pcm_sync_ptr+0xf8/0x1e0
> [  140.397139]                    [<c04e1e68>] snd_pcm_common_ioctl1+0x478/0xe20
> [  140.404256]                    [<c04e3078>]
> snd_pcm_capture_ioctl1+0x1a4/0x688
> [  140.411461]                    [<c01343f8>] do_vfs_ioctl+0xa0/0x9d4
> [  140.417710]                    [<c0134d60>] SyS_ioctl+0x34/0x5c
> [  140.423613]                    [<c000f800>] ret_fast_syscall+0x0/0x1c
> [  140.430036]  }
> [  140.431685]  ... key      at: [<c13e2be8>] __key.29136+0x0/0x8
> [  140.437501]  ... acquired at:
> [  140.440452]    [<c0079630>] __lock_acquire+0x774/0x1ee0
> [  140.445659]    [<c007b390>] lock_acquire+0xa8/0xd0
> [  140.450433]    [<c066b89c>] _raw_spin_lock+0x3c/0x74
> [  140.455381]    [<c04e03cc>] _snd_pcm_stream_lock_irqsave+0x34/0x40
> [  140.461544]    [<c04e6f44>] snd_pcm_period_elapsed+0x1c/0xa0
> [  140.467186]    [<c02de5b0>] pl330_tasklet+0x198/0x518
> [  140.472220]    [<c002e424>] tasklet_action+0xac/0x164
> [  140.477255]    [<c002e6ac>] __do_softirq+0x168/0x2c0
> [  140.482202]    [<c002eba8>] irq_exit+0xec/0x128
> [  140.486716]    [<c0087314>] __handle_domain_irq+0x80/0xec
> [  140.492097]    [<c0009514>] gic_handle_irq+0x54/0x94
> [  140.497044]    [<c00144f8>] __irq_svc+0x58/0x98
> [  140.501559]    [<c00102f8>] arch_cpu_idle+0x24/0x3c
> [  140.506420]    [<c00102f8>] arch_cpu_idle+0x24/0x3c
> [  140.511280]    [<c006d5d4>] cpu_startup_entry+0x1f4/0x280
> [  140.516662]    [<c08c8ccc>] start_kernel+0x3ec/0x3f8
> [  140.521609]
> [  140.523086]
> [  140.523086] stack backtrace:
> [  140.527435] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
> 4.5.0-rc3-u3s #11
> [  140.535240] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [  140.541339] [<c0016d6c>] (unwind_backtrace) from [<c00139f8>]
> (show_stack+0x10/0x14)
> [  140.549063] [<c00139f8>] (show_stack) from [<c0283884>]
> (dump_stack+0x98/0xc4)
> [  140.556263] [<c0283884>] (dump_stack) from [<c0075458>]
> (print_irq_inversion_bug+0x1d4/0x21c)
> [  140.564766] [<c0075458>] (print_irq_inversion_bug) from
> [<c0075550>] (check_usage_forwards+0xb0/0x10c)
> [  140.574051] [<c0075550>] (check_usage_forwards) from [<c00764f8>]
> (mark_lock+0x370/0x81c)
> [  140.582211] [<c00764f8>] (mark_lock) from [<c0079630>]
> (__lock_acquire+0x774/0x1ee0)
> [  140.589936] [<c0079630>] (__lock_acquire) from [<c007b390>]
> (lock_acquire+0xa8/0xd0)
> [  140.597665] [<c007b390>] (lock_acquire) from [<c066b89c>]
> (_raw_spin_lock+0x3c/0x74)
> [  140.605389] [<c066b89c>] (_raw_spin_lock) from [<c04e03cc>]
> (_snd_pcm_stream_lock_irqsave+0x34/0x40)
> [  140.614503] [<c04e03cc>] (_snd_pcm_stream_lock_irqsave) from
> [<c04e6f44>] (snd_pcm_period_elapsed+0x1c/0xa0)
> [  140.624313] [<c04e6f44>] (snd_pcm_period_elapsed) from [<c02de5b0>]
> (pl330_tasklet+0x198/0x518)
> [  140.632993] [<c02de5b0>] (pl330_tasklet) from [<c002e424>]
> (tasklet_action+0xac/0x164)
> [  140.640890] [<c002e424>] (tasklet_action) from [<c002e6ac>]
> (__do_softirq+0x168/0x2c0)
> [  140.648787] [<c002e6ac>] (__do_softirq) from [<c002eba8>]
> (irq_exit+0xec/0x128)
> [  140.656080] [<c002eba8>] (irq_exit) from [<c0087314>]
> (__handle_domain_irq+0x80/0xec)
> [  140.663889] [<c0087314>] (__handle_domain_irq) from [<c0009514>]
> (gic_handle_irq+0x54/0x94)
> [  140.672219] [<c0009514>] (gic_handle_irq) from [<c00144f8>]
> (__irq_svc+0x58/0x98)
> [  140.679677] Exception stack(0xc0aa5f50 to 0xc0aa5f98)
> [  140.684716] 5f40:                                     00000000
> 2e0b1000 00000000 c0aaa540
> [  140.692879] 5f60: c0aa4000 c0aa655c 00000000 00000000 c0aa5fa8
> c093d49c c0aa65bc c0aa65c4
> [  140.701035] 5f80: 00000000 c0aa5fa0 c0076b38 c00102f8 20030053 ffffffff
> [  140.707637] [<c00144f8>] (__irq_svc) from [<c00102f8>]
> (arch_cpu_idle+0x24/0x3c)
> [  140.715014] [<c00102f8>] (arch_cpu_idle) from [<c006d5d4>]
> (cpu_startup_entry+0x1f4/0x280)
> [  140.723265] [<c006d5d4>] (cpu_startup_entry) from [<c08c8ccc>]
> (start_kernel+0x3ec/0x3f8)
> 
> Best Regards
> -Anand Moon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



From wangkefeng.wang at huawei.com  Sun Feb 14 00:54:18 2016
From: wangkefeng.wang at huawei.com (Kefeng Wang)
Date: Sun, 14 Feb 2016 16:54:18 +0800
Subject: [PATCH 0/6] arm64: hip05: update
In-Reply-To: <1454056746-5048-1-git-send-email-wangkefeng.wang@huawei.com>
References: <1454056746-5048-1-git-send-email-wangkefeng.wang@huawei.com>
Message-ID: <56C040BA.4010701@huawei.com>

Ping, any comments, thanks.

On 2016/1/29 16:39, Kefeng Wang wrote:
> Enable more feature in hip05 d02 board.
> 
> Kefeng Wang (6):
>   arm64: dts: hip05: Add L2 cache topology
>   arm64: dts: hip05: Use Cortex specific device node for pmu
>   arm64: dts: hip05: Append all gicv3 ITS entries
>   arm64: dts: hip05: Append gpio nodes
>   arm64: dts: hip05: Append power button node for D02 board
>   arm64: defconfig: Enable DesignWare APB GPIO controller
> 
>  arch/arm64/boot/dts/hisilicon/hip05-d02.dts | 18 ++++++
>  arch/arm64/boot/dts/hisilicon/hip05.dtsi    | 92 ++++++++++++++++++++++++++++-
>  arch/arm64/configs/defconfig                |  1 +
>  3 files changed, 109 insertions(+), 2 deletions(-)
> 



From wangkefeng.wang at huawei.com  Sun Feb 14 00:57:18 2016
From: wangkefeng.wang at huawei.com (Kefeng Wang)
Date: Sun, 14 Feb 2016 16:57:18 +0800
Subject: [PATCH] arm64: mm: dump: Use VA_START directly instead of private
 LOWEST_ADDR
In-Reply-To: <20160201102345.GB674@leverpostej>
References: <1454140521-741-1-git-send-email-wangkefeng.wang@huawei.com>
 <20160201102345.GB674@leverpostej>
Message-ID: <56C0416E.6050908@huawei.com>

Hi Catalin and Will,  ping...

On 2016/2/1 18:23, Mark Rutland wrote:
> On Sat, Jan 30, 2016 at 03:55:21PM +0800, Kefeng Wang wrote:
>> Use VA_START macro in asm/memory.h instead of private LOWEST_ADDR
>> definition in dump.c.
>>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang at huawei.com>
> 
> FWIW:
> 
> Acked-by: Mark Rutland <mark.rutland at arm.com>
> 
> Mark.
> 
>> ---
>>  arch/arm64/mm/dump.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
>> index 0adbebb..b3c62b1 100644
>> --- a/arch/arm64/mm/dump.c
>> +++ b/arch/arm64/mm/dump.c
>> @@ -27,8 +27,6 @@
>>  #include <asm/pgtable.h>
>>  #include <asm/pgtable-hwdef.h>
>>  
>> -#define LOWEST_ADDR	(UL(0xffffffffffffffff) << VA_BITS)
>> -
>>  struct addr_marker {
>>  	unsigned long start_address;
>>  	const char *name;
>> @@ -316,7 +314,7 @@ static int ptdump_show(struct seq_file *m, void *v)
>>  		.marker = address_markers,
>>  	};
>>  
>> -	walk_pgd(&st, &init_mm, LOWEST_ADDR);
>> +	walk_pgd(&st, &init_mm, VA_START);
>>  
>>  	note_page(&st, 0, 0, 0);
>>  	return 0;
>> -- 
>> 2.6.0.GIT
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
> 
> .
> 



From shawnguo at kernel.org  Sun Feb 14 00:58:52 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Sun, 14 Feb 2016 16:58:52 +0800
Subject: [GIT PULL] ARM: imx: fixes for 4.5
Message-ID: <20160214085852.GT6756@tiger>

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-4.5

for you to fetch changes up to f5d0ca224a071d7077bbdae347cb514949d64fd9:

  ARM: dts: imx6: remove bogus interrupt-parent from CAAM node (2016-01-28 16:48:15 +0800)

----------------------------------------------------------------
The i.MX fixes for v4.5:
 - Drop the bogus interrupt-parent from i.MX6 CAAM node, which leads to
   the CAAM IRQs not getting unmasked at the GPC level.

----------------------------------------------------------------
Lucas Stach (1):
      ARM: dts: imx6: remove bogus interrupt-parent from CAAM node

 arch/arm/boot/dts/imx6qdl.dtsi | 1 -
 1 file changed, 1 deletion(-)


From k.kozlowski at samsung.com  Sun Feb 14 01:04:47 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Sun, 14 Feb 2016 18:04:47 +0900
Subject: [PATCH] ARM: exynos: clarify KEYBOARD_SAMSUNG selection
In-Reply-To: <1455204662-1017820-1-git-send-email-arnd@arndb.de>
References: <1455204662-1017820-1-git-send-email-arnd@arndb.de>
Message-ID: <56C0432F.6040409@samsung.com>

W dniu 12.02.2016 o 00:30, Arnd Bergmann pisze:
> The samsung-keypad driver is implicitly selected by ARCH_EXYNOS4 (why?),
> but this fails if CONFIG_INPUT is a loadable module:

How about removing the select entirely and adding it in defconfigs? It
was introduced by 49b999711ee7 ("ARM: EXYNOS: change HAVE_SAMSUNG_KEYPAD
to KEYBOARD_SAMSUNG") which looks like a mistake. The intention was to
indicate a HAVE, not to select a driver.

Moreover the Exynos3250 also has keypad but it is not selected.

Can you send a patch removing select and changing exynos+multi_v7
defconfigs?

Best regards,
Krzysztof

> 
> drivers/input/built-in.o: In function `samsung_keypad_remove':
> drivers/input/keyboard/samsung-keypad.c:461: undefined reference to `input_unregister_device'
> drivers/input/built-in.o: In function `samsung_keypad_irq':
> drivers/input/keyboard/samsung-keypad.c:137: undefined reference to `input_event'
> drivers/input/built-in.o: In function `samsung_keypad_irq':
> include/linux/input.h:389: undefined reference to `input_event'
> drivers/input/built-in.o: In function `samsung_keypad_probe':
> drivers/input/keyboard/samsung-keypad.c:358: undefined reference to `devm_input_allocate_device'
> drivers/input/built-in.o:(.debug_addr+0x34): undefined reference to `input_set_capability'
> 
> This changes the 'select' statement so we don't do it if CONFIG_INPUT=m.
> The problem does not happen on mainline kernels, as we don't normally
> build built-in input drivers when CONFIG_INPUT=m, but I am experimenting
> with a patch to change this, and the samsung keypad driver showed up
> as one example that was silently broken before.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/mach-exynos/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 8434a0f6334c..b63e64581c24 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -59,7 +59,7 @@ config ARCH_EXYNOS4
>  	select CLKSRC_SAMSUNG_PWM if CPU_EXYNOS4210
>  	select CPU_EXYNOS4210
>  	select GIC_NON_BANKED
> -	select KEYBOARD_SAMSUNG if INPUT_KEYBOARD
> +	select KEYBOARD_SAMSUNG if INPUT=y && INPUT_KEYBOARD
>  	select MIGHT_HAVE_CACHE_L2X0
>  	help
>  	  Samsung EXYNOS4 (Cortex-A9) SoC based systems
> 



From fu.wei at linaro.org  Sun Feb 14 01:26:35 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Sun, 14 Feb 2016 17:26:35 +0800
Subject: [PATCH v11 3/4] ARM64: add SBSA Generic Watchdog device node in
 amd-seattle-soc.dtsi
In-Reply-To: <56BBA3F0.4010908@amd.com>
References: <1455037240-16192-1-git-send-email-fu.wei@linaro.org>
 <1455037240-16192-4-git-send-email-fu.wei@linaro.org>
 <56BBA3F0.4010908@amd.com>
Message-ID: <CADyBb7vQbq2JSu9gvDkPYaRr6MkC-_U2F8-Dhqzh-iTbFAf8SQ@mail.gmail.com>

Hi Suravee,

On 11 February 2016 at 04:56, Suravee Suthikulpanit
<Suravee.Suthikulpanit at amd.com> wrote:
> Hi Fu Wei,
>
> On 2/10/16 00:00, fu.wei at linaro.org wrote:
>>
>> From: Fu Wei <fu.wei at linaro.org>
>>
>> This can be a example of adding SBSA Generic Watchdog device node
>> into some dts files for the Soc which contains SBSA Generic Watchdog.
>>
>> Acked-by: Arnd Bergmann <arnd at arndb.de>
>> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
>> Signed-off-by: Fu Wei <fu.wei at linaro.org>
>> ---
>>   arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 9 +++++++++
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
>> b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
>> index 2874d92..67eb636 100644
>> --- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
>> +++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
>> @@ -84,6 +84,15 @@
>>                         clock-names = "uartclk", "apb_pclk";
>>                 };
>>
>> +               watchdog0: watchdog at e0bb0000 {
>> +                       compatible = "arm,sbsa-gwdt";
>> +                       reg = <0x0 0xe0bc0000 0 0x1000>,
>> +                               <0x0 0xe0bb0000 0 0x1000>;
>> +                       interrupts = <0 337 4>;
>> +                       timeout-sec = <15>;
>> +                       status = "disabled";
>
>
> Could you please remove this status line? I do not think it is necessary for
> this one here anymore.

OK, will do
:-)

>
> Thanks,
> Suravee
>
>
>> +               };
>> +
>>                 spi0: ssp at e1020000 {
>>                         status = "disabled";
>>                         compatible = "arm,pl022", "arm,primecell";
>>
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From Suzuki.Poulose at arm.com  Sun Feb 14 03:13:41 2016
From: Suzuki.Poulose at arm.com (Suzuki K. Poulose)
Date: Sun, 14 Feb 2016 11:13:41 +0000
Subject: [PATCH v6 00/12] arm-cci: PMU driver updates
In-Reply-To: <1453720877-24962-1-git-send-email-suzuki.poulose@arm.com>
References: <1453720877-24962-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <56C06165.3040804@arm.com>

On 25/01/16 11:21, Suzuki K. Poulose wrote:
> This series includes:
>
>   - Simplified sysfs attribute handling for CCI PMU (Patch 1)
>   - Work around for writing to CCI-500/550(introduced later) PMU
>     counters (Patches 2-10)
>   - Support for CCI-550 PMU (11-12) with Acked-bys.


Gentle ping

Cheers
Suzuki


From linux.amoon at gmail.com  Sun Feb 14 03:46:22 2016
From: linux.amoon at gmail.com (Anand Moon)
Date: Sun, 14 Feb 2016 17:16:22 +0530
Subject: lockdep: INFO: possible irq lock inversion dependency detected on
 Odroid U3
In-Reply-To: <56C0404E.7080707@samsung.com>
References: <CANAwSgRgFMNWGhTe7xsHqkQQ1JS0XW6pO8LT8c6rZm=3cEBcbg@mail.gmail.com>
 <56C0404E.7080707@samsung.com>
Message-ID: <CANAwSgStC+59Bcmu9WKTvrE2tj3ZJuXPmBv1N_RS+VDfTNX3XA@mail.gmail.com>

Hi Krzysztof,

On 14 February 2016 at 14:22, Krzysztof Kozlowski
<k.kozlowski at samsung.com> wrote:
> W dniu 10.02.2016 o 16:27, Anand Moon pisze:
>> Hi all,
>>
>> I am observing following lockdep info.
>
> Hi,
>
> Thanks for report. When pasting dmesg output, please do not wrap the
> lines because it is difficult to read it.
>
> This looks like known issue:
> https://wiki.tizen.org/wiki/Exynos_Mainline_Kernel_TODO/Odroid_XU3_lockdep_warn_during_music_playback
>
> Waiting for someone brave enough to fix it...
>
> But actually more important item is following real lockup, failing
> multi_v7 boot ~20% of times:
> http://www.krzk.eu/builders/boot-odroid-xu3-multi_v7/builds/34
> http://www.krzk.eu/builders/boot-odroid-xu3-multi_v7
>
> Best regards,
> Krzysztof
>
Next time I will be much cleaner logs.

Thanks for the conformation on this, well I have tried to solve this
issue, but failed.
>From my understanding it's like IRQ locks that are being hold up by
the pl330 dma module.
But this module also have related to serial driver. So I got but stuck up.

Well I will keep on trying, If I have some thing I will share that.

-Anand Moon

>>
>> [  139.806823] =========================================================
>> [  139.811934] [ INFO: possible irq lock inversion dependency detected ]
>> [  139.818362] 4.5.0-rc3-u3s #11 Tainted: G        W
>> [  139.823566] ---------------------------------------------------------
>> [  139.829990] swapper/0/0 just changed the state of lock:
>> [  139.835197]  (&(&substream->self_group.lock)->rlock){..-...}, at:
>> [<c04e03cc>] _snd_pcm_stream_lock_irqsave+0x34/0x40
>> [  139.845788] but this lock took another, SOFTIRQ-unsafe lock in the past:
>> [  139.852468]  (&(&pri_dai->spinlock)->rlock){+.+...}
>>
>> and interrupts could create inverse lock ordering between them.
>>
>> [  139.863319]
>> [  139.863319] other info that might help us debug this:
>> [  139.869830]  Possible interrupt unsafe locking scenario:
>> [  139.869830]
>> [  139.876599]        CPU0                    CPU1
>> [  139.881113]        ----                    ----
>> [  139.885626]   lock(&(&pri_dai->spinlock)->rlock);
>> [  139.890314]                                local_irq_disable();
>> [  139.896216]
>> lock(&(&substream->self_group.lock)->rlock);
>> [  139.904201]
>> lock(&(&pri_dai->spinlock)->rlock);
>> [  139.911405]   <Interrupt>
>> [  139.914009]     lock(&(&substream->self_group.lock)->rlock);
>> [  139.919652]
>> [  139.919652]  *** DEADLOCK ***
>> [  139.919652]
>> [  139.925558] 1 lock held by swapper/0/0:
>> [  139.929374]  #0:  (snd_pcm_link_rwlock){...-..}, at: [<c04e0330>]
>> snd_pcm_stream_lock+0x20/0x50
>> [  139.938054]
>> [  139.938054] the shortest dependencies between 2nd lock and 1st lock:
>> [  139.945893]  -> (&(&pri_dai->spinlock)->rlock){+.+...} ops: 37 {
>> [  139.951856]     HARDIRQ-ON-W at:
>> [  139.955067]                       [<c066b89c>] _raw_spin_lock+0x3c/0x74
>> [  139.961663]                       [<c0500558>] i2s_set_sysclk+0x40/0x464
>> [  139.968347]                       [<c0500e0c>]
>> samsung_i2s_dai_probe+0x238/0x2b0
>> [  139.975725]                       [<c04ed5f8>] soc_probe_dai.part.2+0x30/0x6c
>> [  139.982842]                       [<c04ee1b8>]
>> snd_soc_register_card+0x854/0xe64
>> [  139.990220]                       [<c04f9b0c>]
>> devm_snd_soc_register_card+0x38/0x70
>> [  139.997859]                       [<c04ff0f8>]
>> asoc_simple_card_probe+0x224/0x460
>> [  140.005323]                       [<c036da6c>] platform_drv_probe+0x4c/0xb0
>> [  140.012267]                       [<c036c2ac>]
>> driver_probe_device+0x20c/0x2b8
>> [  140.019472]                       [<c036a644>] bus_for_each_drv+0x60/0x94
>> [  140.026242]                       [<c036bfc0>] __device_attach+0xb4/0x118
>> [  140.033013]                       [<c036b464>] bus_probe_device+0x88/0x90
>> [  140.039783]                       [<c036b900>]
>> deferred_probe_work_func+0x6c/0x9c
>> [  140.047248]                       [<c0043408>] process_one_work+0x1a8/0x514
>> [  140.054192]                       [<c00437ac>] worker_thread+0x38/0x574
>> [  140.060789]                       [<c0049c0c>] kthread+0xf4/0x10c
>> [  140.066865]                       [<c000f890>] ret_from_fork+0x14/0x24
>> [  140.073376]     SOFTIRQ-ON-W at:
>> [  140.076587]                       [<c066b89c>] _raw_spin_lock+0x3c/0x74
>> [  140.083183]                       [<c0500558>] i2s_set_sysclk+0x40/0x464
>> [  140.089867]                       [<c0500e0c>]
>> samsung_i2s_dai_probe+0x238/0x2b0
>> [  140.097245]                       [<c04ed5f8>] soc_probe_dai.part.2+0x30/0x6c
>> [  140.104362]                       [<c04ee1b8>]
>> snd_soc_register_card+0x854/0xe64
>> [  140.111740]                       [<c04f9b0c>]
>> devm_snd_soc_register_card+0x38/0x70
>> [  140.119379]                       [<c04ff0f8>]
>> asoc_simple_card_probe+0x224/0x460
>> [  140.126843]                       [<c036da6c>] platform_drv_probe+0x4c/0xb0
>> [  140.133787]                       [<c036c2ac>]
>> driver_probe_device+0x20c/0x2b8
>> [  140.140992]                       [<c036a644>] bus_for_each_drv+0x60/0x94
>> [  140.147762]                       [<c036bfc0>] __device_attach+0xb4/0x118
>> [  140.154533]                       [<c036b464>] bus_probe_device+0x88/0x90
>> [  140.161303]                       [<c036b900>]
>> deferred_probe_work_func+0x6c/0x9c
>> [  140.168768]                       [<c0043408>] process_one_work+0x1a8/0x514
>> [  140.175712]                       [<c00437ac>] worker_thread+0x38/0x574
>> [  140.182309]                       [<c0049c0c>] kthread+0xf4/0x10c
>> [  140.188385]                       [<c000f890>] ret_from_fork+0x14/0x24
>> [  140.194896]     INITIAL USE at:
>> [  140.198020]                      [<c066bb14>]
>> _raw_spin_lock_irqsave+0x48/0x84
>> [  140.205224]                      [<c04c2d44>] clk_divider_set_rate+0x40/0xc0
>> [  140.212255]                      [<c04c1320>] clk_change_rate+0x17c/0x210
>> [  140.219025]                      [<c04c12b8>] clk_change_rate+0x114/0x210
>> [  140.225796]   }
>> [  140.227532]   ... key      at: [<c13e2f04>] __key.37532+0x0/0x8
>> [  140.233435]   ... acquired at:
>> [  140.236472]    [<c04ffb18>] i2s_trigger+0x40/0x62c
>> [  140.241246]    [<c04f4d14>] soc_pcm_trigger+0xd0/0x11c
>> [  140.246367]    [<c04dfe58>] snd_pcm_action_single+0x38/0x80
>> [  140.251922]    [<c04e1dac>] snd_pcm_common_ioctl1+0x3bc/0xe20
>> [  140.257651]    [<c04e29b4>] snd_pcm_playback_ioctl1+0x1a4/0x69c
>> [  140.263553]    [<c01343f8>] do_vfs_ioctl+0xa0/0x9d4
>> [  140.268414]    [<c0134d60>] SyS_ioctl+0x34/0x5c
>> [  140.272927]    [<c000f800>] ret_fast_syscall+0x0/0x1c
>> [  140.277962]
>> [  140.279438] -> (&(&substream->self_group.lock)->rlock){..-...} ops: 153 {
>> [  140.286209]    IN-SOFTIRQ-W at:
>> [  140.289333]                     [<c066b89c>] _raw_spin_lock+0x3c/0x74
>> [  140.295757]                     [<c04e03cc>]
>> _snd_pcm_stream_lock_irqsave+0x34/0x40
>> [  140.303395]                     [<c04e6f44>] snd_pcm_period_elapsed+0x1c/0xa0
>> [  140.310512]                     [<c02de5b0>] pl330_tasklet+0x198/0x518
>> [  140.317022]                     [<c002e424>] tasklet_action+0xac/0x164
>> [  140.323532]                     [<c002e6ac>] __do_softirq+0x168/0x2c0
>> [  140.329955]                     [<c002eba8>] irq_exit+0xec/0x128
>> [  140.335945]                     [<c0087314>] __handle_domain_irq+0x80/0xec
>> [  140.342802]                     [<c0009514>] gic_handle_irq+0x54/0x94
>> [  140.349225]                     [<c00144f8>] __irq_svc+0x58/0x98
>> [  140.355214]                     [<c00102f8>] arch_cpu_idle+0x24/0x3c
>> [  140.361551]                     [<c00102f8>] arch_cpu_idle+0x24/0x3c
>> [  140.367887]                     [<c006d5d4>] cpu_startup_entry+0x1f4/0x280
>> [  140.374744]                     [<c08c8ccc>] start_kernel+0x3ec/0x3f8
>> [  140.381169]    INITIAL USE at:
>> [  140.384205]                    [<c066b89c>] _raw_spin_lock+0x3c/0x74
>> [  140.390542]                    [<c04e0850>] snd_pcm_sync_ptr+0xf8/0x1e0
>> [  140.397139]                    [<c04e1e68>] snd_pcm_common_ioctl1+0x478/0xe20
>> [  140.404256]                    [<c04e3078>]
>> snd_pcm_capture_ioctl1+0x1a4/0x688
>> [  140.411461]                    [<c01343f8>] do_vfs_ioctl+0xa0/0x9d4
>> [  140.417710]                    [<c0134d60>] SyS_ioctl+0x34/0x5c
>> [  140.423613]                    [<c000f800>] ret_fast_syscall+0x0/0x1c
>> [  140.430036]  }
>> [  140.431685]  ... key      at: [<c13e2be8>] __key.29136+0x0/0x8
>> [  140.437501]  ... acquired at:
>> [  140.440452]    [<c0079630>] __lock_acquire+0x774/0x1ee0
>> [  140.445659]    [<c007b390>] lock_acquire+0xa8/0xd0
>> [  140.450433]    [<c066b89c>] _raw_spin_lock+0x3c/0x74
>> [  140.455381]    [<c04e03cc>] _snd_pcm_stream_lock_irqsave+0x34/0x40
>> [  140.461544]    [<c04e6f44>] snd_pcm_period_elapsed+0x1c/0xa0
>> [  140.467186]    [<c02de5b0>] pl330_tasklet+0x198/0x518
>> [  140.472220]    [<c002e424>] tasklet_action+0xac/0x164
>> [  140.477255]    [<c002e6ac>] __do_softirq+0x168/0x2c0
>> [  140.482202]    [<c002eba8>] irq_exit+0xec/0x128
>> [  140.486716]    [<c0087314>] __handle_domain_irq+0x80/0xec
>> [  140.492097]    [<c0009514>] gic_handle_irq+0x54/0x94
>> [  140.497044]    [<c00144f8>] __irq_svc+0x58/0x98
>> [  140.501559]    [<c00102f8>] arch_cpu_idle+0x24/0x3c
>> [  140.506420]    [<c00102f8>] arch_cpu_idle+0x24/0x3c
>> [  140.511280]    [<c006d5d4>] cpu_startup_entry+0x1f4/0x280
>> [  140.516662]    [<c08c8ccc>] start_kernel+0x3ec/0x3f8
>> [  140.521609]
>> [  140.523086]
>> [  140.523086] stack backtrace:
>> [  140.527435] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
>> 4.5.0-rc3-u3s #11
>> [  140.535240] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [  140.541339] [<c0016d6c>] (unwind_backtrace) from [<c00139f8>]
>> (show_stack+0x10/0x14)
>> [  140.549063] [<c00139f8>] (show_stack) from [<c0283884>]
>> (dump_stack+0x98/0xc4)
>> [  140.556263] [<c0283884>] (dump_stack) from [<c0075458>]
>> (print_irq_inversion_bug+0x1d4/0x21c)
>> [  140.564766] [<c0075458>] (print_irq_inversion_bug) from
>> [<c0075550>] (check_usage_forwards+0xb0/0x10c)
>> [  140.574051] [<c0075550>] (check_usage_forwards) from [<c00764f8>]
>> (mark_lock+0x370/0x81c)
>> [  140.582211] [<c00764f8>] (mark_lock) from [<c0079630>]
>> (__lock_acquire+0x774/0x1ee0)
>> [  140.589936] [<c0079630>] (__lock_acquire) from [<c007b390>]
>> (lock_acquire+0xa8/0xd0)
>> [  140.597665] [<c007b390>] (lock_acquire) from [<c066b89c>]
>> (_raw_spin_lock+0x3c/0x74)
>> [  140.605389] [<c066b89c>] (_raw_spin_lock) from [<c04e03cc>]
>> (_snd_pcm_stream_lock_irqsave+0x34/0x40)
>> [  140.614503] [<c04e03cc>] (_snd_pcm_stream_lock_irqsave) from
>> [<c04e6f44>] (snd_pcm_period_elapsed+0x1c/0xa0)
>> [  140.624313] [<c04e6f44>] (snd_pcm_period_elapsed) from [<c02de5b0>]
>> (pl330_tasklet+0x198/0x518)
>> [  140.632993] [<c02de5b0>] (pl330_tasklet) from [<c002e424>]
>> (tasklet_action+0xac/0x164)
>> [  140.640890] [<c002e424>] (tasklet_action) from [<c002e6ac>]
>> (__do_softirq+0x168/0x2c0)
>> [  140.648787] [<c002e6ac>] (__do_softirq) from [<c002eba8>]
>> (irq_exit+0xec/0x128)
>> [  140.656080] [<c002eba8>] (irq_exit) from [<c0087314>]
>> (__handle_domain_irq+0x80/0xec)
>> [  140.663889] [<c0087314>] (__handle_domain_irq) from [<c0009514>]
>> (gic_handle_irq+0x54/0x94)
>> [  140.672219] [<c0009514>] (gic_handle_irq) from [<c00144f8>]
>> (__irq_svc+0x58/0x98)
>> [  140.679677] Exception stack(0xc0aa5f50 to 0xc0aa5f98)
>> [  140.684716] 5f40:                                     00000000
>> 2e0b1000 00000000 c0aaa540
>> [  140.692879] 5f60: c0aa4000 c0aa655c 00000000 00000000 c0aa5fa8
>> c093d49c c0aa65bc c0aa65c4
>> [  140.701035] 5f80: 00000000 c0aa5fa0 c0076b38 c00102f8 20030053 ffffffff
>> [  140.707637] [<c00144f8>] (__irq_svc) from [<c00102f8>]
>> (arch_cpu_idle+0x24/0x3c)
>> [  140.715014] [<c00102f8>] (arch_cpu_idle) from [<c006d5d4>]
>> (cpu_startup_entry+0x1f4/0x280)
>> [  140.723265] [<c006d5d4>] (cpu_startup_entry) from [<c08c8ccc>]
>> (start_kernel+0x3ec/0x3f8)
>>
>> Best Regards
>> -Anand Moon
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>


From linus.walleij at linaro.org  Sun Feb 14 05:15:11 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 14 Feb 2016 14:15:11 +0100
Subject: [PATCH v4 1/2] ARM: dts: imx6: Add support for Toradex Apalis
 iMX6Q/D SoM
In-Reply-To: <1454540539.11389.14.camel@toradex.com>
References: <1453675703-31594-1-git-send-email-marcel.ziswiler@toradex.com>
 <1453675703-31594-2-git-send-email-marcel.ziswiler@toradex.com>
 <20160201132916.GF10671@tiger>
 <1454540116.11389.11.camel@toradex.com>
 <1454540539.11389.14.camel@toradex.com>
Message-ID: <CACRpkdb7dY3f2CWoo3bTkOA1p9dFerp_F_O0Vsg0Pmk7t1YGxQ@mail.gmail.com>

On Thu, Feb 4, 2016 at 12:02 AM, Marcel Ziswiler
<marcel.ziswiler at toradex.com> wrote:
> On Wed, 2016-02-03 at 23:55 +0100, Marcel Ziswiler wrote:
>> On Mon, 2016-02-01 at 21:29 +0800, Shawn Guo wrote:
>>
>> [snip]
>>
>> > +   /* STMPE811 touch screen controller */
>> > > + stmpe811 at 41 {
>> > > +         compatible = "st,stmpe811";
>> >
>> > The compatible seems to be used by kernel without a binding
>> > document.
>>
>> Indeed and looking at git logs Linus himself introduced it (;-p):
>>
>> commit 5a826feedc331a2d5ced2afd832199a70b3af891
>> Author: Linus Walleij <linus.walleij at linaro.org>
>> Date:   Wed Apr 23 23:35:58 2014 +0200
>> Subject: mfd: stmpe: Probe properly from the Device Tree
>
> Looking more closely there is actually a proper binding document which
> got added by Lee Jones:
>
> commit 84e6de813b2d1bdb127943d3c8edf1c1afaa90da
> Author: Lee Jones <lee.jones at linaro.org>
> Date:   Mon Nov 5 16:10:34 2012 +0100
> Subject: Documentation: Describe bindings for STMPE Multi-Functional
> Device driver
>
> Documentation/devicetree/bindings/mfd/stmpe.txt
>
> Required properties:
>  - compatible                   : "st,stmpe[811|1601|2401|2403]"
>
> Sorry for the noise.

Yeah the STMPE driver was a common work between Rabin and
Luotao Fu who pitched in the 811 with touchscreen support.

Then Lee added the device tree stuff.

I know it's a bit confusing that the DT bindings for the whole shebang
is in bindings/mfd but it is also confusing to split them up, don't know
what is best really :(

Yours,
Linus Walleij


From nicolas.pitre at linaro.org  Sun Feb 14 08:52:10 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Sun, 14 Feb 2016 11:52:10 -0500 (EST)
Subject: [PATCH] [media] zl10353: use div_u64 instead of do_div
In-Reply-To: <CAKv+Gu9YWEkArjssR9Urh0_MOR3duNOo2UNiV=tXoQNgFtDngQ@mail.gmail.com>
References: <1455287246-3540549-1-git-send-email-arnd@arndb.de>
 <2712691.b9gkR7KMX7@wuerfel>
 <alpine.LFD.2.20.1602121305180.13632@knanqh.ubzr>
 <6737272.LXr2g355Yt@wuerfel>
 <CAKv+Gu8dFz28tGgQTv+WYAvKpeiFXaj8JANUFtOJwKPRsB8F5A@mail.gmail.com>
 <alpine.LFD.2.20.1602131652560.13632@knanqh.ubzr>
 <CAKv+Gu9YWEkArjssR9Urh0_MOR3duNOo2UNiV=tXoQNgFtDngQ@mail.gmail.com>
Message-ID: <alpine.LFD.2.20.1602141139110.13632@knanqh.ubzr>

On Sun, 14 Feb 2016, Ard Biesheuvel wrote:

> On 13 February 2016 at 22:57, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> > On Sat, 13 Feb 2016, Ard Biesheuvel wrote:
> >
> >> On 12 February 2016 at 22:01, Arnd Bergmann <arnd at arndb.de> wrote:
> >> > However, I did stumble over an older patch I did now, which I could
> >> > not remember what it was good for. It does fix the problem, and
> >> > it seems to be a better solution.
> >> >
> >> >         Arnd
> >> >
> >> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> >> > index b5acbb404854..b5ff9881bef8 100644
> >> > --- a/include/linux/compiler.h
> >> > +++ b/include/linux/compiler.h
> >> > @@ -148,7 +148,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
> >> >   */
> >> >  #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
> >> >  #define __trace_if(cond) \
> >> > -       if (__builtin_constant_p((cond)) ? !!(cond) :                   \
> >> > +       if (__builtin_constant_p(!!(cond)) ? !!(cond) :                 \
> >> >         ({                                                              \
> >> >                 int ______r;                                            \
> >> >                 static struct ftrace_branch_data                        \
> >> >
> >>
> >> I remember seeing this patch, but I don't remember the exact context.
> >> But when you think about it, !!cond can be a build time constant even
> >> if cond is not, as long as you can prove statically that cond != 0. So
> >
> > You're right.  I just tested it and to my surprise gcc is smart enough
> > to figure that case out.
> >
> >> I think this change is obviously correct, and an improvement since it
> >> will remove the profiling overhead of branches that are not true
> >> branches in the first place.
> >
> > Indeed.
> >
> 
> ... and perhaps we should not evaluate cond twice either?

It is not. The value of the argument to __builtin_constant_p() is not 
itself evaluated and therefore does not produce side effects.


Nicolas


From tj at kernel.org  Sun Feb 14 09:01:52 2016
From: tj at kernel.org (Tejun Heo)
Date: Sun, 14 Feb 2016 12:01:52 -0500
Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <20160214170152.GC3965@htj.duckdns.org>

Hello,

On Fri, Feb 12, 2016 at 03:20:30PM -0800, tchalamarla at caviumnetworks.com wrote:
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 546a369..76e310e 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1560,6 +1560,9 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>  	if (ahci_broken_devslp(pdev))
>  		hpriv->flags |= AHCI_HFLAG_NO_DEVSLP;
>  
> +	if (pdev->vendor == 0x177d && pdev->device == 0xa01c)
> +		ahci_thunderx_init(&pdev->dev, hpriv);

So, this would make ahci fail to build if thunderx is not configured.
Maybe we should add an additional callback to update hpriv.

>  	/* save initial config */
>  	ahci_pci_save_initial_config(pdev, hpriv);
>  
> diff --git a/drivers/ata/ahci_thunderx.c b/drivers/ata/ahci_thunderx.c

This driver isn't upstream yet, right?  Maybe just fold this change
together?

Thanks.

-- 
tejun


From paul.gortmaker at windriver.com  Sun Feb 14 09:19:11 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Sun, 14 Feb 2016 12:19:11 -0500
Subject: [PATCH] drivers/hwtracing: make coresight-* explicitly non-modular
Message-ID: <1455470351-15219-1-git-send-email-paul.gortmaker@windriver.com>

None of the Kconfig currently controlling compilation of any of
the files here are tristate, meaning that none of it currently
is being built as a module by anyone.

We need not be concerned about .remove functions and blocking the
unbind sysfs operations, since that was already done in a recent
commit.

Lets remove any remaining modular references, so that when reading the
drivers there is no doubt they are builtin-only.

All drivers get mostly the same changes, so they are handled in batch.
Changes are (1) convert to builtin_amba_driver, (2) delete module.h
include where unused, and (3) relocate the description into the
comments so we don't need MODULE_DESCRIPTION and associated tags.

The etm3x and etm4x use module_param_named, and have been adjusted
to just include moduleparam.h for that purpose.

In commit f309d4443130bf814e991f836e919dca22df37ae ("platform_device:
better support builtin boilerplate avoidance") we introduced the
builtin_driver macro.

Here we use that support and extend it to amba driver registration,
so where a driver is clearly non-modular and builtin-only, we can
update with the simple mapping of

     module_amba_driver(...)  ---> builtin_amba_driver(...)

Since module_amba_driver() uses the same init level priority as
builtin_amba_driver() the init ordering remains unchanged with
this commit.

Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
---

[This is what I sent back in October[1], but with the .remove and
 .suppress bits stripped out, since that is now in Mathieu's queue.
 And to make this a standalone commit that Mathieu can also add to
 his queue, I've squished the amba/bus.h change[2] into this change.]

[1]  http://www.spinics.net/lists/kernel/msg2096702.html
[2]  http://lkml.iu.edu/hypermail/linux/kernel/1510.1/02464.html

 drivers/hwtracing/coresight/coresight-etb10.c           |  9 +++------
 drivers/hwtracing/coresight/coresight-etm3x.c           | 14 ++++++++------
 drivers/hwtracing/coresight/coresight-etm4x.c           |  4 +---
 drivers/hwtracing/coresight/coresight-funnel.c          |  9 +++------
 drivers/hwtracing/coresight/coresight-replicator-qcom.c |  4 +---
 drivers/hwtracing/coresight/coresight-replicator.c      |  7 ++-----
 drivers/hwtracing/coresight/coresight-tmc.c             |  9 +++------
 drivers/hwtracing/coresight/coresight-tpiu.c            |  9 +++------
 drivers/hwtracing/coresight/coresight.c                 |  3 ---
 drivers/hwtracing/coresight/of_coresight.c              |  1 -
 include/linux/amba/bus.h                                |  9 +++++++++
 11 files changed, 33 insertions(+), 45 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 92969dae739d..21f6afd24a66 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -1,5 +1,7 @@
 /* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
  *
+ * Description: CoreSight Embedded Trace Buffer driver
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
  * only version 2 as published by the Free Software Foundation.
@@ -11,7 +13,6 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/device.h>
@@ -534,8 +535,4 @@ static struct amba_driver etb_driver = {
 	.probe		= etb_probe,
 	.id_table	= etb_ids,
 };
-
-module_amba_driver(etb_driver);
-
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("CoreSight Embedded Trace Buffer driver");
+builtin_amba_driver(etb_driver);
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index aae80e14508d..8750b432ad36 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -1,5 +1,7 @@
 /* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
  *
+ * Description: CoreSight Program Flow Trace driver
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
  * only version 2 as published by the Free Software Foundation.
@@ -11,7 +13,7 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/module.h>
+#include <linux/moduleparam.h>
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/device.h>
@@ -35,6 +37,10 @@
 
 #include "coresight-etm.h"
 
+/*
+ * not really modular but using module_param is the easiest way to
+ * remain consistent with existing use cases for now.
+ */
 static int boot_enable;
 module_param_named(boot_enable, boot_enable, int, S_IRUGO);
 
@@ -1950,8 +1956,4 @@ static struct amba_driver etm_driver = {
 	.probe		= etm_probe,
 	.id_table	= etm_ids,
 };
-
-module_amba_driver(etm_driver);
-
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("CoreSight Program Flow Trace driver");
+builtin_amba_driver(etm_driver);
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index d6a92c6d3a66..040327ac6e1f 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -15,7 +15,6 @@
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/device.h>
-#include <linux/module.h>
 #include <linux/io.h>
 #include <linux/err.h>
 #include <linux/fs.h>
@@ -2714,5 +2713,4 @@ static struct amba_driver etm4x_driver = {
 	.probe		= etm4_probe,
 	.id_table	= etm4_ids,
 };
-
-module_amba_driver(etm4x_driver);
+builtin_amba_driver(etm4x_driver);
diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c
index 25e8ea140a09..2c1850c8dbe7 100644
--- a/drivers/hwtracing/coresight/coresight-funnel.c
+++ b/drivers/hwtracing/coresight/coresight-funnel.c
@@ -1,5 +1,7 @@
 /* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
  *
+ * Description: CoreSight Funnel driver
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
  * only version 2 as published by the Free Software Foundation.
@@ -11,7 +13,6 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/device.h>
@@ -270,8 +271,4 @@ static struct amba_driver funnel_driver = {
 	.probe		= funnel_probe,
 	.id_table	= funnel_ids,
 };
-
-module_amba_driver(funnel_driver);
-
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("CoreSight Funnel driver");
+builtin_amba_driver(funnel_driver);
diff --git a/drivers/hwtracing/coresight/coresight-replicator-qcom.c b/drivers/hwtracing/coresight/coresight-replicator-qcom.c
index 444815179460..6344dcf19639 100644
--- a/drivers/hwtracing/coresight/coresight-replicator-qcom.c
+++ b/drivers/hwtracing/coresight/coresight-replicator-qcom.c
@@ -15,7 +15,6 @@
 #include <linux/clk.h>
 #include <linux/coresight.h>
 #include <linux/device.h>
-#include <linux/module.h>
 #include <linux/err.h>
 #include <linux/init.h>
 #include <linux/io.h>
@@ -202,5 +201,4 @@ static struct amba_driver replicator_driver = {
 	.probe		= replicator_probe,
 	.id_table	= replicator_ids,
 };
-
-module_amba_driver(replicator_driver);
+builtin_amba_driver(replicator_driver);
diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
index b77d700a3f0e..d31da8004d2e 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -1,5 +1,7 @@
 /* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
  *
+ * Description: CoreSight Replicator driver
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
  * only version 2 as published by the Free Software Foundation.
@@ -11,7 +13,6 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/module.h>
 #include <linux/device.h>
 #include <linux/platform_device.h>
 #include <linux/io.h>
@@ -168,8 +169,4 @@ static struct platform_driver replicator_driver = {
 		.suppress_bind_attrs = true,
 	},
 };
-
 builtin_platform_driver(replicator_driver);
-
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("CoreSight Replicator driver");
diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
index c4fa70ed14ce..021cbb5d9eb3 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -1,5 +1,7 @@
 /* Copyright (c) 2012, The Linux Foundation. All rights reserved.
  *
+ * Description: CoreSight Trace Memory Controller driver
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
  * only version 2 as published by the Free Software Foundation.
@@ -11,7 +13,6 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/device.h>
@@ -787,8 +788,4 @@ static struct amba_driver tmc_driver = {
 	.probe		= tmc_probe,
 	.id_table	= tmc_ids,
 };
-
-module_amba_driver(tmc_driver);
-
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("CoreSight Trace Memory Controller driver");
+builtin_amba_driver(tmc_driver);
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
index ca50e73d9df7..e24bfb04f168 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -1,5 +1,7 @@
 /* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
  *
+ * Description: CoreSight Trace Port Interface Unit driver
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
  * only version 2 as published by the Free Software Foundation.
@@ -11,7 +13,6 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/device.h>
 #include <linux/io.h>
@@ -220,8 +221,4 @@ static struct amba_driver tpiu_driver = {
 	.probe		= tpiu_probe,
 	.id_table	= tpiu_ids,
 };
-
-module_amba_driver(tpiu_driver);
-
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("CoreSight Trace Port Interface Unit driver");
+builtin_amba_driver(tpiu_driver);
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 7e6e9ff27dd1..4b33f1938a58 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -11,7 +11,6 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/device.h>
@@ -766,5 +765,3 @@ void coresight_unregister(struct coresight_device *csdev)
 	device_unregister(&csdev->dev);
 }
 EXPORT_SYMBOL_GPL(coresight_unregister);
-
-MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
index 3cc57c1e3b5d..b68da1888fd5 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -10,7 +10,6 @@
  * GNU General Public License for more details.
  */
 
-#include <linux/module.h>
 #include <linux/types.h>
 #include <linux/err.h>
 #include <linux/slab.h>
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 9006c4e75cf7..3d8dcdd1aeae 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -163,4 +163,13 @@ struct amba_device name##_device = {				\
 #define module_amba_driver(__amba_drv) \
 	module_driver(__amba_drv, amba_driver_register, amba_driver_unregister)
 
+/*
+ * builtin_amba_driver() - Helper macro for drivers that don't do anything
+ * special in driver initcall.  This eliminates a lot of boilerplate.  Each
+ * driver may only use this macro once, and calling it replaces the instance
+ * device_initcall().
+ */
+#define builtin_amba_driver(__amba_drv) \
+	builtin_driver(__amba_drv, amba_driver_register)
+
 #endif
-- 
2.6.1



From daniel at ffwll.ch  Sun Feb 14 10:25:08 2016
From: daniel at ffwll.ch (Daniel Vetter)
Date: Sun, 14 Feb 2016 19:25:08 +0100
Subject: [PATCH 01/17] drm/virtio: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <1455285069-2819-2-git-send-email-palminha@synopsys.com>
References: <daniel.vetter@ffwll.ch,>
 <1455285069-2819-1-git-send-email-palminha@synopsys.com>
 <1455285069-2819-2-git-send-email-palminha@synopsys.com>
Message-ID: <20160214182508.GF11240@phenom.ffwll.local>

On Fri, Feb 12, 2016 at 01:50:53PM +0000, Carlos Palminha wrote:

Sob-line from you is missing on all patches, I can't merge them. Also
please copypaste a default blurb to all patches that this is only recently
no longer needed. And dunno what happened to your patch series, the
threading is somehow broken. In case your mail server doesn't accept a big
patch series you can first format .patch files using git format-patch with
threading enabled (should be the default) and then send them out in
chunks.

When resending please also add the r-b tag from Alex for amdgpu/radoen.

Thanks, Daniel

> ---
>  drivers/gpu/drm/virtio/virtgpu_display.c | 8 --------
>  1 file changed, 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
> index a165f03..429aa31 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -282,13 +282,6 @@ static const struct drm_crtc_helper_funcs virtio_gpu_crtc_helper_funcs = {
>  	.atomic_check  = virtio_gpu_crtc_atomic_check,
>  };
>  
> -static bool virtio_gpu_enc_mode_fixup(struct drm_encoder *encoder,
> -				      const struct drm_display_mode *mode,
> -				      struct drm_display_mode *adjusted_mode)
> -{
> -	return true;
> -}
> -
>  static void virtio_gpu_enc_mode_set(struct drm_encoder *encoder,
>  				    struct drm_display_mode *mode,
>  				    struct drm_display_mode *adjusted_mode)
> @@ -362,7 +355,6 @@ virtio_gpu_best_encoder(struct drm_connector *connector)
>  }
>  
>  static const struct drm_encoder_helper_funcs virtio_gpu_enc_helper_funcs = {
> -	.mode_fixup = virtio_gpu_enc_mode_fixup,
>  	.mode_set   = virtio_gpu_enc_mode_set,
>  	.enable     = virtio_gpu_enc_enable,
>  	.disable    = virtio_gpu_enc_disable,
> -- 
> 2.5.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From ard.biesheuvel at linaro.org  Sun Feb 14 11:06:10 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Sun, 14 Feb 2016 20:06:10 +0100
Subject: [PATCH] [media] zl10353: use div_u64 instead of do_div
In-Reply-To: <alpine.LFD.2.20.1602141139110.13632@knanqh.ubzr>
References: <1455287246-3540549-1-git-send-email-arnd@arndb.de>
 <2712691.b9gkR7KMX7@wuerfel>
 <alpine.LFD.2.20.1602121305180.13632@knanqh.ubzr>
 <6737272.LXr2g355Yt@wuerfel>
 <CAKv+Gu8dFz28tGgQTv+WYAvKpeiFXaj8JANUFtOJwKPRsB8F5A@mail.gmail.com>
 <alpine.LFD.2.20.1602131652560.13632@knanqh.ubzr>
 <CAKv+Gu9YWEkArjssR9Urh0_MOR3duNOo2UNiV=tXoQNgFtDngQ@mail.gmail.com>
 <alpine.LFD.2.20.1602141139110.13632@knanqh.ubzr>
Message-ID: <CAKv+Gu_z0xeQx-n7PPaWYUNjV8xWPXwTrGS3RnyByW8xw3Yf+w@mail.gmail.com>

On 14 February 2016 at 17:52, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> On Sun, 14 Feb 2016, Ard Biesheuvel wrote:
>
>> On 13 February 2016 at 22:57, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
>> > On Sat, 13 Feb 2016, Ard Biesheuvel wrote:
>> >
>> >> On 12 February 2016 at 22:01, Arnd Bergmann <arnd at arndb.de> wrote:
>> >> > However, I did stumble over an older patch I did now, which I could
>> >> > not remember what it was good for. It does fix the problem, and
>> >> > it seems to be a better solution.
>> >> >
>> >> >         Arnd
>> >> >
>> >> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
>> >> > index b5acbb404854..b5ff9881bef8 100644
>> >> > --- a/include/linux/compiler.h
>> >> > +++ b/include/linux/compiler.h
>> >> > @@ -148,7 +148,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
>> >> >   */
>> >> >  #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
>> >> >  #define __trace_if(cond) \
>> >> > -       if (__builtin_constant_p((cond)) ? !!(cond) :                   \
>> >> > +       if (__builtin_constant_p(!!(cond)) ? !!(cond) :                 \
>> >> >         ({                                                              \
>> >> >                 int ______r;                                            \
>> >> >                 static struct ftrace_branch_data                        \
>> >> >
>> >>
>> >> I remember seeing this patch, but I don't remember the exact context.
>> >> But when you think about it, !!cond can be a build time constant even
>> >> if cond is not, as long as you can prove statically that cond != 0. So
>> >
>> > You're right.  I just tested it and to my surprise gcc is smart enough
>> > to figure that case out.
>> >
>> >> I think this change is obviously correct, and an improvement since it
>> >> will remove the profiling overhead of branches that are not true
>> >> branches in the first place.
>> >
>> > Indeed.
>> >
>>
>> ... and perhaps we should not evaluate cond twice either?
>
> It is not. The value of the argument to __builtin_constant_p() is not
> itself evaluated and therefore does not produce side effects.
>

Interesting, thanks for clarifying.


From linux.amoon at gmail.com  Sun Feb 14 11:12:12 2016
From: linux.amoon at gmail.com (Anand Moon)
Date: Mon, 15 Feb 2016 00:42:12 +0530
Subject: lockdep: INFO: possible irq lock inversion dependency detected on
 Odroid U3
In-Reply-To: <56C0404E.7080707@samsung.com>
References: <CANAwSgRgFMNWGhTe7xsHqkQQ1JS0XW6pO8LT8c6rZm=3cEBcbg@mail.gmail.com>
 <56C0404E.7080707@samsung.com>
Message-ID: <CANAwSgS1KPwDCn5eQr0VqTWDNW2T2oykmYr+0rdMCza6C+BPSw@mail.gmail.com>

Hi Krzysztof

On 14 February 2016 at 14:22, Krzysztof Kozlowski
<k.kozlowski at samsung.com> wrote:
> W dniu 10.02.2016 o 16:27, Anand Moon pisze:
>> Hi all,
>>
>> I am observing following lockdep info.
>
> Hi,
>
> Thanks for report. When pasting dmesg output, please do not wrap the
> lines because it is difficult to read it.
>
> This looks like known issue:
> https://wiki.tizen.org/wiki/Exynos_Mainline_Kernel_TODO/Odroid_XU3_lockdep_warn_during_music_playback
>
> Waiting for someone brave enough to fix it...
>
> But actually more important item is following real lockup, failing
> multi_v7 boot ~20% of times:
> http://www.krzk.eu/builders/boot-odroid-xu3-multi_v7/builds/34
> http://www.krzk.eu/builders/boot-odroid-xu3-multi_v7
>
> Best regards,
> Krzysztof
>

I have manage to fix the issue using below changes.

root at odroidu3:/usr/src/odroidxu3-4.y-devel# git diff drivers/dma/pl330.c
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 17ee758..b651443 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1973,10 +1973,9 @@ static void pl330_tasklet(unsigned long data)
 {
        struct dma_pl330_chan *pch = (struct dma_pl330_chan *)data;
        struct dma_pl330_desc *desc, *_dt;
-       unsigned long flags;
        bool power_down = false;

-       spin_lock_irqsave(&pch->lock, flags);
+       spin_lock_irq(&pch->lock);

        /* Pick up ripe tomatoes */
        list_for_each_entry_safe(desc, _dt, &pch->work_list, node)
@@ -2028,12 +2027,12 @@ static void pl330_tasklet(unsigned long data)
                dma_descriptor_unmap(&desc->txd);

                if (callback) {
-                       spin_unlock_irqrestore(&pch->lock, flags);
+                       spin_unlock_irq(&pch->lock);
                        callback(callback_param);
-                       spin_lock_irqsave(&pch->lock, flags);
+                       spin_lock_irq(&pch->lock);
                }
        }
-       spin_unlock_irqrestore(&pch->lock, flags);
+       spin_unlock_irq(&pch->lock);

        /* If work list empty, power down */
        if (power_down) {
@@ -2091,10 +2090,10 @@ static int pl330_alloc_chan_resources(struct
dma_chan *chan)
                return -ENOMEM;
        }

-       tasklet_init(&pch->task, pl330_tasklet, (unsigned long) pch);
-
        spin_unlock_irqrestore(&pch->lock, flags);

+       tasklet_init(&pch->task, pl330_tasklet, (unsigned long) pch);
+
        return 1;
 }

------
Test on Odroid U3.

But below changes introduce below WARNING.

[   14.818967] ------------[ cut here ]------------
[   14.819517] WARNING: CPU: 0 PID: 486 at
kernel/locking/lockdep.c:2608 _raw_spin_unlock_irq+0x24/0x5c()
[   14.828791] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
[   14.833995] Modules linked in:
[   14.837209] CPU: 0 PID: 486 Comm: plymouth Tainted: G        W
 4.5.0-rc3-xu3s #55
[   14.845191] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   14.851282] [<c0016eac>] (unwind_backtrace) from [<c0013b30>]
(show_stack+0x10/0x14)
[   14.859001] [<c0013b30>] (show_stack) from [<c02943e4>]
(dump_stack+0x98/0xc4)
[   14.866204] [<c02943e4>] (dump_stack) from [<c0029fcc>]
(warn_slowpath_common+0x80/0xb0)
[   14.874273] [<c0029fcc>] (warn_slowpath_common) from [<c002a02c>]
(warn_slowpath_fmt+0x30/0x40)
[   14.882956] [<c002a02c>] (warn_slowpath_fmt) from [<c068029c>]
(_raw_spin_unlock_irq+0x24/0x5c)
[   14.891637] [<c068029c>] (_raw_spin_unlock_irq) from [<c02ef1c8>]
(pl330_tasklet+0x1a8/0x504)
[   14.900142] [<c02ef1c8>] (pl330_tasklet) from [<c0325028>]
(s3c24xx_serial_start_tx_dma+0x154/0x198)
[   14.909253] [<c0325028>] (s3c24xx_serial_start_tx_dma) from
[<c032526c>] (s3c24xx_serial_tx_chars+0x200/0x204)
[   14.919236] [<c032526c>] (s3c24xx_serial_tx_chars) from
[<c03265a8>] (s3c64xx_serial_handle_irq+0x34/0x60)
[   14.928873] [<c03265a8>] (s3c64xx_serial_handle_irq) from
[<c0087e48>] (handle_irq_event_percpu+0x9c/0x150)
[   14.938593] [<c0087e48>] (handle_irq_event_percpu) from
[<c0087f34>] (handle_irq_event+0x38/0x5c)
[   14.947446] [<c0087f34>] (handle_irq_event) from [<c008b1f4>]
(handle_fasteoi_irq+0xd0/0x1a8)
[   14.955952] [<c008b1f4>] (handle_fasteoi_irq) from [<c0087464>]
(generic_handle_irq+0x24/0x34)
[   14.964545] [<c0087464>] (generic_handle_irq) from [<c0087778>]
(__handle_domain_irq+0x7c/0xec)
[   14.973225] [<c0087778>] (__handle_domain_irq) from [<c0009514>]
(gic_handle_irq+0x54/0x94)
[   14.981557] [<c0009514>] (gic_handle_irq) from [<c0014638>]
(__irq_svc+0x58/0x98)
[   14.989019] Exception stack(0xed385e90 to 0xed385ed8)
[   14.994055] 5e80:                                     00000000
2e07c000 00000000 edb4e480
[   15.002215] 5ea0: 00000053 c136c014 ed048780 ed048800 c136c014
c0adb108 ed048000 00000002
[   15.010373] 5ec0: 00000000 ed385ee0 c0076edc c0680274 20000053 ffffffff
[   15.016973] [<c0014638>] (__irq_svc) from [<c0680274>]
(_raw_spin_unlock_irqrestore+0x70/0x74)
[   15.025569] [<c0680274>] (_raw_spin_unlock_irqrestore) from
[<c02bd7a4>] (__debug_check_no_obj_freed+0x128/0x220)
[   15.035811] [<c02bd7a4>] (__debug_check_no_obj_freed) from
[<c0127940>] (kmem_cache_free+0x150/0x1ec)
[   15.045011] [<c0127940>] (kmem_cache_free) from [<c002bd70>]
(do_exit+0x32c/0xaf4)
[   15.052560] [<c002bd70>] (do_exit) from [<c002dbc0>]
(do_group_exit+0x3c/0xbc)
[   15.059764] [<c002dbc0>] (do_group_exit) from [<c002dc50>]
(__wake_up_parent+0x0/0x18)
[   15.067660] ---[ end trace 27c09e22f2a7458b ]---

Any comments are valuable.

Best Regards.
-Anand Moon


From dhdang at apm.com  Sun Feb 14 11:13:21 2016
From: dhdang at apm.com (Duc Dang)
Date: Sun, 14 Feb 2016 11:13:21 -0800
Subject: [GIT PULL] arm64: X-Gene platforms DTS changes queued for v4.6 - part1
Message-ID: <CADaLNDk3n3WQyRZ3rCwDQBhT4QDAycTaqhSbe4P4MMhxUxCdUA@mail.gmail.com>

[Resend in plain text format]

Hi Arnd, Olof,

This is the first part of DT changes for X-Gene platforms queued for
4.6. This includes only 1 change in compatible string for X-Gene v2
SOC PLL.

Regards,
Duc Dang.
-------

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  https://github.com/AppliedMicro/xgene-next.git tags/xgene-dts-for-v4.6-part1

for you to fetch changes up to a8618b52bca015be7ae342423ba9b6d2e9a8037b:

  arm64: Update Merlin DT PCP PLL clock node for v2 hardware
(2016-02-09 18:25:02 -0800)

----------------------------------------------------------------
First part of X-Gene DT changes queued for v4.6

This includes a change in compatible string of
X-Gene v2 SOC PLL DT node to reflect the v2 hardware.
This change is part of Loc's series
http://www.spinics.net/lists/arm-kernel/msg475481.html

----------------------------------------------------------------
Loc Ho (1):
      arm64: Update Merlin DT PCP PLL clock node for v2 hardware

 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


From philipp.zabel at gmail.com  Sun Feb 14 11:22:58 2016
From: philipp.zabel at gmail.com (Philipp Zabel)
Date: Sun, 14 Feb 2016 20:22:58 +0100
Subject: GPIO regression in Linux next caused by syscon change
In-Reply-To: <20160213004935.GR19432@atomide.com>
References: <20160213002643.GQ19432@atomide.com>
 <20160213004935.GR19432@atomide.com>
Message-ID: <CA+gwMccZeYimupmGsMX8YbNH9eEA6=Xi=rupciubBwzktfjvBA@mail.gmail.com>

I've just replaced the of_iomap() call with an open coded version,
calling of_address_to_resource() and ioremap() directly. That was
needed so I can use the struct resource returned by
of_address_to_resource() to set the syscon_config.max_register. I
don't see where this could cause resource overlap. Does just setting
syscon_config.max_register to zero again make the problem disappear?

regards
Philipp

On Sat, Feb 13, 2016 at 1:49 AM, Tony Lindgren <tony at atomide.com> wrote:
> * Tony Lindgren <tony at atomide.com> [160212 16:31]:
>> Hi,
>>
>> Looks like commit effe02710335 ("mfd: syscon: Set regmap max_register
>> in of_syscon_register") somehow breaks smsc911x GPIO interrupt for
>> me at least on omap3:
>>
>> irq 241: nobody cared (try booting with the "irqpoll" option)
>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc3-next-20160212 #864
>> Hardware name: Generic OMAP36xx (Flattened Device Tree)
>> [<c010fd44>] (unwind_backtrace) from [<c010c094>] (show_stack+0x10/0x14)
>> [<c010c094>] (show_stack) from [<c045f24c>] (dump_stack+0xb0/0xe4)
>> [<c045f24c>] (dump_stack) from [<c01998e8>] (__report_bad_irq+0x24/0xc0)
>> [<c01998e8>] (__report_bad_irq) from [<c0199ce4>] (note_interrupt+0x27c/0x2dc)
>> [<c0199ce4>] (note_interrupt) from [<c0197220>] (handle_irq_event_percpu+0x184/0x200)
>> [<c0197220>] (handle_irq_event_percpu) from [<c01972d4>] (handle_irq_event+0x38/0x5c)
>> [<c01972d4>] (handle_irq_event) from [<c019a3d8>] (handle_level_irq+0xc0/0x154)
>> [<c019a3d8>] (handle_level_irq) from [<c0196784>] (generic_handle_irq+0x20/0x34)
>> [<c0196784>] (generic_handle_irq) from [<c049b690>] (omap_gpio_irq_handler+0x120/0x160)
>> [<c049b690>] (omap_gpio_irq_handler) from [<c01970f0>] (handle_irq_event_percpu+0x54/0x200)
>> [<c01970f0>] (handle_irq_event_percpu) from [<c01972d4>] (handle_irq_event+0x38/0x5c)
>> [<c01972d4>] (handle_irq_event) from [<c019a3d8>] (handle_level_irq+0xc0/0x154)
>> [<c019a3d8>] (handle_level_irq) from [<c0196784>] (generic_handle_irq+0x20/0x34)
>> [<c0196784>] (generic_handle_irq) from [<c0196a78>] (__handle_domain_irq+0x64/0xe0)
>> [<c0196a78>] (__handle_domain_irq) from [<c076f038>] (__irq_svc+0x58/0x78)
>> [<c076f038>] (__irq_svc) from [<c076e93c>] (_raw_spin_unlock_irqrestore+0x34/0x44)
>> [<c076e93c>] (_raw_spin_unlock_irqrestore) from [<c019900c>] (__setup_irq+0x40c/0x5e0)
>> [<c019900c>] (__setup_irq) from [<c0199330>] (request_threaded_irq+0xc0/0x158)
>> [<c0199330>] (request_threaded_irq) from [<c05a4038>] (smsc911x_drv_probe+0x588/0xfec)
>> [<c05a4038>] (smsc911x_drv_probe) from [<c04fc1b4>] (platform_drv_probe+0x4c/0xb0)
>> [<c04fc1b4>] (platform_drv_probe) from [<c04fa89c>] (driver_probe_device+0x208/0x2c0)
>> [<c04fa89c>] (driver_probe_device) from [<c04fa9e8>] (__driver_attach+0x94/0x98)
>> [<c04fa9e8>] (__driver_attach) from [<c04f8bc4>] (bus_for_each_dev+0x6c/0xa0)
>> [<c04f8bc4>] (bus_for_each_dev) from [<c04f9d28>] (bus_add_driver+0x18c/0x214)
>> [<c04f9d28>] (bus_add_driver) from [<c04fb22c>] (driver_register+0x78/0xf8)
>> [<c04fb22c>] (driver_register) from [<c010180c>] (do_one_initcall+0x80/0x1dc)
>> [<c010180c>] (do_one_initcall) from [<c0b00ef0>] (kernel_init_freeable+0x218/0x2ec)
>> [<c0b00ef0>] (kernel_init_freeable) from [<c0768360>] (kernel_init+0x8/0xf4)
>> [<c0768360>] (kernel_init) from [<c01078d0>] (ret_from_fork+0x14/0x24)
>> handlers:
>> [<c05a26d8>] smsc911x_irqhandler
>> Disabling IRQ #241
>> libphy: smsc911x-mdio: probed
>>
>> I'm not seeing the connection between regmap and  GPIO, so no
>> idea what goes wrong here.
>
> The only regmap here is the scm_conf in omap3.dtsi. Probably some
> resource size calculation issue causing an overlap?
>
> Tony
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From u.kleine-koenig at pengutronix.de  Sun Feb 14 11:55:01 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Sun, 14 Feb 2016 20:55:01 +0100
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160214165010.GA3189@roeck-us.net>
References: <20160214165010.GA3189@roeck-us.net>
Message-ID: <20160214195501.GA12289@pengutronix.de>

[adding lakml and rmk to Cc]

Hello Guenter,

On Sun, Feb 14, 2016 at 08:50:10AM -0800, Guenter Roeck wrote:
> Uwe,
> 
> Your patch 'driver-core: platform: probe of-devices only using list of
> compatibles' causes the following qemu tests to crash in -next.
> 
> arm:vexpress-a9:vexpress_defconfig:vexpress-v2p-ca9
> arm:vexpress-a15:vexpress_defconfig:vexpress-v2p-ca15-tc1
> arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
> arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
> 
> Crash log:
> 
> VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6
> Please append a correct "root=" boot option; here are the available partitions:
> 1f00          131072 mtdblock0  (driver?)
> 1f01           32768 mtdblock1  (driver?)
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
> 
> ie the mmc driver no longer instantiates. Reverting the patch fixes the problem.

The driver is drivers/mmc/host/mmci.c, right? and the relevant device
tree snippet is:

	mmci at 05000 {
		compatible = "arm,pl180", "arm,primecell";
		...
	};

? So the unexpected abnormality here is that even though this device is
instantiated by dt, the driver doesn't provide any compatibles.
Either my expectation is wrong, then 67d02a1bbb33455 should be reverted
(or handle this case in a different way), or the mmci driver should
declare compatibles (but then it needs to be a platform driver and not
an amba driver?).

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From linux at arm.linux.org.uk  Sun Feb 14 12:07:55 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Sun, 14 Feb 2016 20:07:55 +0000
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160214195501.GA12289@pengutronix.de>
References: <20160214165010.GA3189@roeck-us.net>
 <20160214195501.GA12289@pengutronix.de>
Message-ID: <20160214200755.GB10826@n2100.arm.linux.org.uk>

On Sun, Feb 14, 2016 at 08:55:01PM +0100, Uwe Kleine-K?nig wrote:
> So the unexpected abnormality here is that even though this device is
> instantiated by dt, the driver doesn't provide any compatibles.
> Either my expectation is wrong, then 67d02a1bbb33455 should be reverted

Your expectation is wrong.  AMBA primecell devices have hardware IDs
and are matched to their drivers by those IDs.  Just like PCI.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From paul.gortmaker at windriver.com  Sun Feb 14 12:32:46 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Sun, 14 Feb 2016 15:32:46 -0500
Subject: [PATCH 1/5] xen: audit usages of module.h ;
 remove unnecessary instances
In-Reply-To: <1455481970-15239-1-git-send-email-paul.gortmaker@windriver.com>
References: <1455481970-15239-1-git-send-email-paul.gortmaker@windriver.com>
Message-ID: <1455481970-15239-2-git-send-email-paul.gortmaker@windriver.com>

Code that uses no modular facilities whatsoever should not be
sourcing module.h at all, since that header drags in a bunch
of other headers with it.

Similarly, code that is not explicitly using modular facilities
like module_init() but only is declaring module_param setup
variables should be using moduleparam.h and not the larger
module.h file for that.

In making this change, we also uncover an implicit use of BUG()
in inline fcns within arch/arm/include/asm/xen/hypercall.h so
we explicitly source <linux/bug.h> for that file now.

Cc: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Cc: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Cc: David Vrabel <david.vrabel at citrix.com>
Cc: xen-devel at lists.xenproject.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
---
 arch/arm/include/asm/xen/hypercall.h  | 2 ++
 drivers/xen/events/events_2l.c        | 1 -
 drivers/xen/events/events_base.c      | 2 +-
 drivers/xen/events/events_fifo.c      | 1 -
 drivers/xen/features.c                | 2 +-
 drivers/xen/grant-table.c             | 1 -
 drivers/xen/xen-pciback/conf_space.c  | 2 +-
 drivers/xen/xen-pciback/pciback_ops.c | 2 +-
 drivers/xen/xen-pciback/xenbus.c      | 2 +-
 drivers/xen/xen-selfballoon.c         | 1 -
 drivers/xen/xenbus/xenbus_xs.c        | 1 -
 drivers/xen/xenfs/xensyms.c           | 1 -
 12 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index d769972db8cb..b6b962d70db9 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -33,6 +33,8 @@
 #ifndef _ASM_ARM_XEN_HYPERCALL_H
 #define _ASM_ARM_XEN_HYPERCALL_H
 
+#include <linux/bug.h>
+
 #include <xen/interface/xen.h>
 #include <xen/interface/sched.h>
 #include <xen/interface/platform.h>
diff --git a/drivers/xen/events/events_2l.c b/drivers/xen/events/events_2l.c
index 7dd46312c180..51b488f5bfe9 100644
--- a/drivers/xen/events/events_2l.c
+++ b/drivers/xen/events/events_2l.c
@@ -9,7 +9,6 @@
 #include <linux/linkage.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
-#include <linux/module.h>
 
 #include <asm/sync_bitops.h>
 #include <asm/xen/hypercall.h>
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 524c22146429..488017a0806a 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -26,7 +26,7 @@
 #include <linux/linkage.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
-#include <linux/module.h>
+#include <linux/moduleparam.h>
 #include <linux/string.h>
 #include <linux/bootmem.h>
 #include <linux/slab.h>
diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
index eff2b88003d9..9289a17712e2 100644
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -36,7 +36,6 @@
 #include <linux/linkage.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
-#include <linux/module.h>
 #include <linux/smp.h>
 #include <linux/percpu.h>
 #include <linux/cpu.h>
diff --git a/drivers/xen/features.c b/drivers/xen/features.c
index 99eda169c779..d7d34fdfc993 100644
--- a/drivers/xen/features.c
+++ b/drivers/xen/features.c
@@ -7,7 +7,7 @@
  */
 #include <linux/types.h>
 #include <linux/cache.h>
-#include <linux/module.h>
+#include <linux/export.h>
 
 #include <asm/xen/hypercall.h>
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index effbaf91791f..bb36b1e1dbcc 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -33,7 +33,6 @@
 
 #define pr_fmt(fmt) "xen:" KBUILD_MODNAME ": " fmt
 
-#include <linux/module.h>
 #include <linux/sched.h>
 #include <linux/mm.h>
 #include <linux/slab.h>
diff --git a/drivers/xen/xen-pciback/conf_space.c b/drivers/xen/xen-pciback/conf_space.c
index 9c234209d8b5..8e67336f8ddd 100644
--- a/drivers/xen/xen-pciback/conf_space.c
+++ b/drivers/xen/xen-pciback/conf_space.c
@@ -10,7 +10,7 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/module.h>
+#include <linux/moduleparam.h>
 #include <linux/pci.h>
 #include "pciback.h"
 #include "conf_space.h"
diff --git a/drivers/xen/xen-pciback/pciback_ops.c b/drivers/xen/xen-pciback/pciback_ops.c
index 73dafdc494aa..5ad01f9c24fc 100644
--- a/drivers/xen/xen-pciback/pciback_ops.c
+++ b/drivers/xen/xen-pciback/pciback_ops.c
@@ -6,7 +6,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
-#include <linux/module.h>
+#include <linux/moduleparam.h>
 #include <linux/wait.h>
 #include <linux/bitops.h>
 #include <xen/events.h>
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 4843741e703a..c252eb3f0176 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -6,7 +6,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
-#include <linux/module.h>
+#include <linux/moduleparam.h>
 #include <linux/init.h>
 #include <linux/list.h>
 #include <linux/vmalloc.h>
diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c
index 3b2bffde534f..53a085fca00c 100644
--- a/drivers/xen/xen-selfballoon.c
+++ b/drivers/xen/xen-selfballoon.c
@@ -71,7 +71,6 @@
 #include <linux/swap.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
-#include <linux/module.h>
 #include <linux/workqueue.h>
 #include <linux/device.h>
 #include <xen/balloon.h>
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index ba804f3d8278..374b12af8812 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -44,7 +44,6 @@
 #include <linux/fcntl.h>
 #include <linux/kthread.h>
 #include <linux/rwsem.h>
-#include <linux/module.h>
 #include <linux/mutex.h>
 #include <asm/xen/hypervisor.h>
 #include <xen/xenbus.h>
diff --git a/drivers/xen/xenfs/xensyms.c b/drivers/xen/xenfs/xensyms.c
index a03f261b12d8..c6e2b4a542ea 100644
--- a/drivers/xen/xenfs/xensyms.c
+++ b/drivers/xen/xenfs/xensyms.c
@@ -1,4 +1,3 @@
-#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/seq_file.h>
 #include <linux/fs.h>
-- 
2.6.1



From paul.gortmaker at windriver.com  Sun Feb 14 12:32:45 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Sun, 14 Feb 2016 15:32:45 -0500
Subject: [PATCH 0/5] xen: avoid module usage in non-modular code
Message-ID: <1455481970-15239-1-git-send-email-paul.gortmaker@windriver.com>

This series of commits is a part of a larger project to ensure
people don't reference modular support functions in non-modular
code.  Overall there was roughly 5k lines of dead code in the
kernel due to this.  So far we've fixed several areas, like tty,
x86, net, ... and we continue to work on other areas.

There are several reasons to not use module support for code that
can never be built as a module, but the big ones are:

 (1) it is easy to accidentally write unused module_exit and remove code
 (2) it can be misleading when reading the source, thinking it can be
      modular when the Makefile and/or Kconfig prohibit it
 (3) it requires the include of the module.h header file which in turn
     includes nearly everything else.
 (4) it gets copied/replicated into other code and spreads like weeds.

For the xen subsystem, there are just five commits:

First, we get rid of "include <linux/module.h>" instances that are
completely unnecessary.

Then #2 and #3 and #5 are basically trivial remapping to the
appropriate non-modular counterparts, meaning that there is no
runtime change here either.

The fourth hypervisor commit is similar, but also has removal of
some dead code associated with the module_exit function that will
never be called.  So the runtime should be the same, but the object
file will be different (reduced in size).

Patches created on linux-next and build tested for x86-64 and ARM64
allmodconfig.

---

Cc: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Cc: David Vrabel <david.vrabel at citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Cc: xen-devel at lists.xenproject.org

Paul Gortmaker (5):
  xen: audit usages of module.h ; remove unnecessary instances
  drivers/xen: make [xen-]ballon explicitly non-modular
  drivers/xen: make xenbus_dev_[front/back]end explicitly non-modular
  drivers/xen: make sys-hypervisor.c explicitly non-modular
  drivers/xen: make platform-pci.c explicitly non-modular

 arch/arm/include/asm/xen/hypercall.h     |  2 ++
 drivers/xen/balloon.c                    |  4 ----
 drivers/xen/events/events_2l.c           |  1 -
 drivers/xen/events/events_base.c         |  2 +-
 drivers/xen/events/events_fifo.c         |  1 -
 drivers/xen/features.c                   |  2 +-
 drivers/xen/grant-table.c                |  1 -
 drivers/xen/platform-pci.c               | 16 ++++++----------
 drivers/xen/sys-hypervisor.c             | 31 ++++---------------------------
 drivers/xen/xen-balloon.c                | 14 +++-----------
 drivers/xen/xen-pciback/conf_space.c     |  2 +-
 drivers/xen/xen-pciback/pciback_ops.c    |  2 +-
 drivers/xen/xen-pciback/xenbus.c         |  2 +-
 drivers/xen/xen-selfballoon.c            |  1 -
 drivers/xen/xenbus/xenbus_dev_backend.c  | 13 ++-----------
 drivers/xen/xenbus/xenbus_dev_frontend.c | 13 ++-----------
 drivers/xen/xenbus/xenbus_xs.c           |  1 -
 drivers/xen/xenfs/xensyms.c              |  1 -
 18 files changed, 24 insertions(+), 85 deletions(-)

-- 
2.6.1


From blogic at openwrt.org  Sun Feb 14 13:01:38 2016
From: blogic at openwrt.org (John Crispin)
Date: Sun, 14 Feb 2016 22:01:38 +0100
Subject: [PATCH V5 04/11] soc: mediatek: PMIC wrap: split SoC specific
 init into callback
In-Reply-To: <56BC7674.9030706@gmail.com>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
 <1454841778-35529-5-git-send-email-blogic@openwrt.org>
 <56BC7674.9030706@gmail.com>
Message-ID: <56C0EB32.4080701@openwrt.org>



On 11/02/2016 12:54, Matthias Brugger wrote:
>> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c
>> b/drivers/soc/mediatek/mtk-pmic-wrap.c
>> index b22b664..e3bbee5 100644
>> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
>> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
>> @@ -372,6 +372,7 @@ struct pmic_wrapper_type {
>>       enum pwrap_type type;
>>       u32 arb_en_all;
>>       int (*init_reg_clock)(struct pmic_wrapper *wrp);
>> +    int (*init_special)(struct pmic_wrapper *wrp);
> 
> Nit:
> I wonder if we can find a better name for the callback, as init_special
> sounds quite generic to me.
> 
> Thanks,
> Matthias

Hi,

At first I considered enable_wrapper as the mt8135/8173 code seems to do
just that. however mt2701 does an init of the ADC. So how about using
init_soc_specific ?

	John


From linux at roeck-us.net  Sun Feb 14 13:08:42 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Sun, 14 Feb 2016 13:08:42 -0800
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160214195501.GA12289@pengutronix.de>
References: <20160214165010.GA3189@roeck-us.net>
 <20160214195501.GA12289@pengutronix.de>
Message-ID: <56C0ECDA.1000203@roeck-us.net>

On 02/14/2016 11:55 AM, Uwe Kleine-K?nig wrote:
> [adding lakml and rmk to Cc]
>
> Hello Guenter,
>
> On Sun, Feb 14, 2016 at 08:50:10AM -0800, Guenter Roeck wrote:
>> Uwe,
>>
>> Your patch 'driver-core: platform: probe of-devices only using list of
>> compatibles' causes the following qemu tests to crash in -next.
>>
>> arm:vexpress-a9:vexpress_defconfig:vexpress-v2p-ca9
>> arm:vexpress-a15:vexpress_defconfig:vexpress-v2p-ca15-tc1
>> arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>> arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>>
>> Crash log:
>>
>> VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6
>> Please append a correct "root=" boot option; here are the available partitions:
>> 1f00          131072 mtdblock0  (driver?)
>> 1f01           32768 mtdblock1  (driver?)
>> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
>>
>> ie the mmc driver no longer instantiates. Reverting the patch fixes the problem.
>
> The driver is drivers/mmc/host/mmci.c, right? and the relevant device
> tree snippet is:
>
> 	mmci at 05000 {
> 		compatible = "arm,pl180", "arm,primecell";
> 		...
> 	};
>

Yes, I think so, or one of the many other similar mmc entries.

> ? So the unexpected abnormality here is that even though this device is
> instantiated by dt, the driver doesn't provide any compatibles.
> Either my expectation is wrong, then 67d02a1bbb33455 should be reverted
> (or handle this case in a different way), or the mmci driver should
> declare compatibles (but then it needs to be a platform driver and not
> an amba driver?).
>

No idea what the correct solution would be. I do see

         if (of_device_is_compatible(bus, "arm,primecell")) {
                 /*
                  * Don't return an error here to keep compatibility with older
                  * device tree files.
                  */
                 of_amba_device_create(bus, bus_id, platform_data, parent);
                 return 0;
         }

in drivers/of/platform.c, which suggests some special handling for amba
devices. No idea if and how that is related, but I do have some concern
that fixing the problem for mmc alone might not fix it for all the other
devices instantiated with "arm,primecell". After all, my boot tests are
really rudimentary (it boots, therefore it works).

Thanks,
Guenter



From linux at roeck-us.net  Sun Feb 14 14:12:42 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Sun, 14 Feb 2016 14:12:42 -0800
Subject: linux-next: arm64 no longer boots with initramfs in qemu tests
Message-ID: <20160214221242.GA23489@roeck-us.net>

Hi,

my qemu tests for arm64 fail to boot in linux-next, starting with next-20160209.
Primary error is

  VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
  Please append a correct "root=" boot option; here are the available partitions:
  Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

but that doesn't mean much since I try to boot an initramfs.

A bisect attempt points to 'arm64: move kernel image to base of vmalloc area',
but that doesn't really help since some of the bisect attempts fail to build
with linker errors. Just for reference, a bisect log is attached.

Comparing console logs between 4.5-rc3 and next-20160212, one key difference is
that the kernel now displays

  Moving initrd from [88000000-889ae7ff] to [5d251000-5dbff7ff]

which was not the case before. Turns out RAM ends at 60000000, so the address
appears to be a bit odd (4.5-rc3 shows initramfs at a lower address).
My qemu test runs with 512MB RAM. If I increase the RAM size to 2G,
the "Moving" message is no longer displayed. However, I still get the same
error.

Qemu command line:

qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt \
	-nographic -smp 1 -m 512 -kernel arch/arm64/boot/Image \
	-initrd rootfs.arm64.cpio -append "console=ttyAMA0"

Configuration is defconfig. Initramfs can be copied from
	https://github.com/groeck/linux-build-test/blob/master/rootfs/arm64/rootfs.arm64.cpio

Please let me know if there is anything I can do to help tracking down
the problem.

Guenter

---
bisect log:

# bad: [64d9a3617b3b8bc0734ba97caeb433b7019c6187] Add linux-next specific files for 20160212
# good: [388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95] Linux 4.5-rc3
git bisect start 'next-20160212' 'v4.5-rc3'
# bad: [597dc9d36e8bc04941b61b26ac7aa3f8a33aba53] Merge remote-tracking branch 'sound-asoc/for-next'
git bisect bad 597dc9d36e8bc04941b61b26ac7aa3f8a33aba53
# bad: [50d4eb6f1f993ca4a3da8c0aa6b807bcf0bd502a] Merge remote-tracking branch 'hid/for-next'
git bisect bad 50d4eb6f1f993ca4a3da8c0aa6b807bcf0bd502a
# good: [b80f982a1a4a6e091235e31906fc0c1cc8c76307] Merge remote-tracking branch 'samsung-krzk/for-next'
git bisect good b80f982a1a4a6e091235e31906fc0c1cc8c76307
# bad: [5278da7e981882dbf23d8dcd5a7ce4d92ff24ba9] Merge remote-tracking branch 'nfsd/nfsd-next'
git bisect bad 5278da7e981882dbf23d8dcd5a7ce4d92ff24ba9
# bad: [d4cf2a954fb2a40acb1c91a55ccaca987fb367ea] Merge remote-tracking branch 'microblaze/next'
git bisect bad d4cf2a954fb2a40acb1c91a55ccaca987fb367ea
# good: [1bdf65407f5d226fbaf1798ffee76e5d12a6ed8e] Merge remote-tracking branch 'tegra/for-next'
git bisect good 1bdf65407f5d226fbaf1798ffee76e5d12a6ed8e
# bad: [f59ba4eb5629fc1a7afe596ab1e84720b893472b] arm64: move back to generic memblock_enforce_memory_limit()
git bisect bad f59ba4eb5629fc1a7afe596ab1e84720b893472b
# good: [a9262c0ff6c56e45e3abb901d7166b4fe2f4d285] arm64: mm: add functions to walk tables in fixmap
git bisect good a9262c0ff6c56e45e3abb901d7166b4fe2f4d285
# good: [80a5c2655c25f4f8e92bf12207d2f90f771585ac] arm64: add support for ioremap() block mappings
git bisect good 80a5c2655c25f4f8e92bf12207d2f90f771585ac
# good: [e7f7cf4021c3b711f5eec19727aa88bf7532db51] arm64: decouple early fixmap init from linear mapping
git bisect good e7f7cf4021c3b711f5eec19727aa88bf7532db51
# bad: [752af28bd7117bd877caafce1600edf69c5bd7e4] arm64: move kernel image to base of vmalloc area
git bisect bad 752af28bd7117bd877caafce1600edf69c5bd7e4
# good: [6a26b548a2c42652229d15b7b8361382f4182dfc] arm64: kvm: deal with kernel symbols outside of linear mapping
git bisect good 6a26b548a2c42652229d15b7b8361382f4182dfc
# first bad commit: [752af28bd7117bd877caafce1600edf69c5bd7e4] arm64: move kernel image to base of vmalloc area


From milo.kim at ti.com  Sun Feb 14 15:31:02 2016
From: milo.kim at ti.com (Kim, Milo)
Date: Mon, 15 Feb 2016 08:31:02 +0900
Subject: [PATCH v2 2/4] regulator: lp872x: Add enable GPIO pin support
In-Reply-To: <1455301532.2760.1.camel@collins>
References: <1454697741-8687-1-git-send-email-contact@paulk.fr>
 <1454697741-8687-3-git-send-email-contact@paulk.fr> <56BD23ED.8010207@ti.com>
 <1455301532.2760.1.camel@collins>
Message-ID: <56C10E36.1030808@ti.com>

On 2/13/2016 3:25 AM, Paul Kocialkowski wrote:
>>> > >+
>>> > >+	/* Always set enable GPIO high. */
>>> > >+	ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, "LP872X EN");
>>> > >+	if (ret) {
>>> > >+		dev_err(lp->dev, "gpio request err: %d\n", ret);
>>> > >+		return ret;
>>> > >+	}
>>> > >+
>>> > >+	/* Each chip has a different enable delay. */
>>> > >+	if (lp->chipid == LP8720)
>>> > >+		usleep_range(LP8720_ENABLE_DELAY, 1.5 * LP8720_ENABLE_DELAY);
>>> > >+	else
>>> > >+		usleep_range(LP8725_ENABLE_DELAY, 1.5 * LP8725_ENABLE_DELAY);
>>> > >+
>>> > >+	return 0;
>>> > >+}
>>> > >+
>>> > >   static int lp872x_config(struct lp872x *lp)
>>> > >   {
>>> > >   	struct lp872x_platform_data *pdata = lp->pdata;
>>> > >@@ -875,6 +903,8 @@ static struct lp872x_platform_data
>>> > >   	of_property_read_u8(np, "ti,dvs-state", &dvs_state);
>>> > >   	pdata->dvs->init_state = dvs_state ? DVS_HIGH : DVS_LOW;
>>> > >
>>> > >+	pdata->enable_gpio = of_get_named_gpio(np, "enable-gpios", 0);
>> >
>> >Please move this code to lp872x_populate_pdata_from_dt().
> This already adds it in lp872x_populate_pdata_from_dt (see the context
> around the insertion).

Ah, sorry. Your patch is correct.

> I don't know why the diff makes it seem like it's added in
> lp872x_config. It's really not.

I think it was from a line break of lp872x_populate_pdata_from_dt().
Let me add my ACK to this patch. Thank you.

Best regards,
Milo


From milo.kim at ti.com  Sun Feb 14 15:37:47 2016
From: milo.kim at ti.com (Kim, Milo)
Date: Mon, 15 Feb 2016 08:37:47 +0900
Subject: [PATCH v2 2/4] regulator: lp872x: Add enable GPIO pin support
In-Reply-To: <1454697741-8687-3-git-send-email-contact@paulk.fr>
References: <1454697741-8687-1-git-send-email-contact@paulk.fr>
 <1454697741-8687-3-git-send-email-contact@paulk.fr>
Message-ID: <56C10FCB.5070803@ti.com>

On 2/6/2016 3:42 AM, Paul Kocialkowski wrote:
> LP872x regulators are made active via the EN pin, which might be hooked to a
> GPIO. This adds support for driving the GPIO high when the driver is in use.
>
> Signed-off-by: Paul Kocialkowski <contact at paulk.fr>
> ---
>   .../devicetree/bindings/regulator/lp872x.txt       |  1 +
>   drivers/regulator/lp872x.c                         | 34 ++++++++++++++++++++++
>   include/linux/regulator/lp872x.h                   |  5 ++++
>   3 files changed, 40 insertions(+)

Acked-by: Milo Kim <milo.kim at ti.com>

Best regards,
Milo


From k.kozlowski at samsung.com  Sun Feb 14 16:33:59 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Mon, 15 Feb 2016 09:33:59 +0900
Subject: [GIT PULL 0/7] ARM: EXYNOS: Pull request for v4.6
Message-ID: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>

Hi Arnd, Kevin and Olof,

This time pull request directly from me (agreed with Kukjin).


Stuff for v4.6 with some dependencies, split into
separate tags. The need for dependency is explained both
in merge-commit and in description of a tag which is using
the dependency.

The order goes like (but of course dependencies
could be pulled all at once at beginning):
1. tags/samsung-fixes-non-critical-4.6
2. tags/samsung-dt-srom-4.6 (DT changs needed by soc)
3. tags/samsung-drivers-soc-srom-pmu-4.6
4. tags/samsung-soc-4.6
5. tags/samsung-drivers-4.6
6. tags/samsung-dt-4.6
7. tags/samsung-defconfig-4.6 (this will also pull tag from RTC tree)

Please share your comments or just pull.


Kind regards,
Krzysztof



From k.kozlowski at samsung.com  Sun Feb 14 16:34:00 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Mon, 15 Feb 2016 09:34:00 +0900
Subject: [GIT PULL 1/7] ARM: EXYNOS: Non-critical fixes for v4.6
In-Reply-To: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455496446-23779-2-git-send-email-k.kozlowski@samsung.com>

Hi Arnd, Kevin and Olof,

Few fixes from Arnd.

BTW, I did not apply one fix from his set because I had few comments
(not resolved yet).

Kind regards,
Krzysztof


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-fixes-non-critical-4.6

for you to fetch changes up to dc7eb9d589e595954792cc192bcbb92932e5c2ff:

  ARM: EXYNOS: select THERMAL_OF (2016-02-01 10:29:20 +0900)

----------------------------------------------------------------
Fixes from Arnd for harmless warnings for Exynos and S3C platforms.

----------------------------------------------------------------
Arnd Bergmann (5):
      ARM: s3c24xx: don't select EEPROM_AT24
      ARM: s3c24xx: allow selecting S3C2440_XTAL_16934400 for s3c2442
      ARM: s3c24xx: fix unused gta02_configure_pmu_for_charger warning
      ARM: s3c64xx: mark regulator init data as unused
      ARM: EXYNOS: select THERMAL_OF

 arch/arm/configs/mini2440_defconfig   |  1 +
 arch/arm/configs/s3c2410_defconfig    |  1 +
 arch/arm/mach-exynos/Kconfig          |  1 +
 arch/arm/mach-s3c24xx/Kconfig         |  6 ++++--
 arch/arm/mach-s3c24xx/mach-gta02.c    |  2 ++
 arch/arm/mach-s3c64xx/mach-smdk6410.c | 38 +++++++++++++++++------------------
 6 files changed, 28 insertions(+), 21 deletions(-)


From k.kozlowski at samsung.com  Sun Feb 14 16:34:03 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Mon, 15 Feb 2016 09:34:03 +0900
Subject: [GIT PULL 4/7] ARM: EXYNOS: mach/soc changes for v4.6
In-Reply-To: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455496446-23779-5-git-send-email-k.kozlowski@samsung.com>

Hi Arnd, Kevin and Olof,

This pulls previous tags (early DT changes, movement of SROM/PMU
to drivers/soc) and contains other interesting stuff. Description
along with a tag.

Kind regards,
Krzysztof


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-4.6

for you to fetch changes up to f6e4621b33f5eab73510c587023910a4566c2611:

  ARM: EXYNOS: Use generic cpufreq driver for Exynos5422/5800 (2016-01-28 19:31:31 +0900)

----------------------------------------------------------------
Samsung Exynos improvements for v4.6:
1. Split out Exynos SROM controller from arm/mach-exynos
   to drivers/soc/samsung. It allows re-using of SROM controller
   driver on ARM64 platform.
   This depends on DT changes.
2. Add banking configuration to Exynos SROM controller.
   This allows usage of SMSC9115 Ethernet chip on SMDK5410 (Exynos5410)
   directly connected to SROM controller.
3. Split out Exynos PMU driver implementation from arm/mach-exynos
   to the drivers/soc/samsung which will allow re-use of it on ARM64.
4. Use generic DT cpufreq driver on Exynos542x/5800.
5. Minor cleanups.

----------------------------------------------------------------
Bartlomiej Zolnierkiewicz (2):
      ARM: EXYNOS: Use generic cpufreq driver for Exynos5420
      ARM: EXYNOS: Use generic cpufreq driver for Exynos5422/5800

Geliang Tang (1):
      ARM: plat-samsung: use to_platform_device()

Krzysztof Kozlowski (2):
      Merge tag 'samsung-dt-srom-4.6' into for-v4.6/drivers-soc-exynos-srom-pmu
      Merge tag 'samsung-drivers-soc-srom-pmu-4.6' into next/soc

Masahiro Yamada (1):
      ARM: s3c64xx: use "depends on" instead of "if" after prompt

Pankaj Dubey (14):
      ARM: dts: Add SROM device node for exynos4
      ARM: dts: Add SROM device node for exynos5
      ARM: EXYNOS: Remove unused static mapping of CMU for exynos5
      ARM: EXYNOS: Code cleanup in map.h
      dt-bindings: EXYNOS: Add exynos-srom device tree binding
      drivers: soc: Add support for exynos SROM driver
      MAINTAINERS: Add maintainers entry for drivers/soc/samsung
      ARM: EXYNOS: Remove SROM related register settings from mach-exynos
      ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung"
      ARM: EXYNOS: Split up exynos3250 SoC specific PMU data
      ARM: EXYNOS: Split up exynos4 SoC specific PMU data
      ARM: EXYNOS: Split up exynos5250 SoC specific PMU data
      ARM: EXYNOS: Split up exynos5420 SoC specific PMU data
      drivers: soc: Add support for Exynos PMU driver

Pavel Fedin (3):
      ARM: dts: Add SROM to exynos5410
      dt-bindings: EXYNOS: Describe SROMc configuration
      drivers: soc: exynos-srom: Add support for bank configuration

 .../bindings/arm/samsung/exynos-srom.txt           |  81 ++
 MAINTAINERS                                        |   1 +
 arch/arm/boot/dts/exynos4.dtsi                     |   5 +
 arch/arm/boot/dts/exynos5.dtsi                     |   5 +
 arch/arm/boot/dts/exynos5410.dtsi                  |   5 +
 arch/arm/mach-exynos/Kconfig                       |   3 +
 arch/arm/mach-exynos/Makefile                      |   2 +-
 arch/arm/mach-exynos/exynos.c                      |  30 +-
 arch/arm/mach-exynos/include/mach/map.h            |   8 -
 arch/arm/mach-exynos/mcpm-exynos.c                 |   2 +-
 arch/arm/mach-exynos/platsmp.c                     |   2 +-
 arch/arm/mach-exynos/pm.c                          |   4 +-
 arch/arm/mach-exynos/pmu.c                         | 967 ---------------------
 arch/arm/mach-exynos/regs-srom.h                   |  53 --
 arch/arm/mach-exynos/suspend.c                     |  24 +-
 arch/arm/mach-s3c64xx/Kconfig                      |   3 +-
 arch/arm/plat-samsung/adc.c                        |   6 +-
 arch/arm/plat-samsung/include/plat/map-s5p.h       |   1 -
 drivers/soc/Kconfig                                |   1 +
 drivers/soc/Makefile                               |   1 +
 drivers/soc/samsung/Kconfig                        |  17 +
 drivers/soc/samsung/Makefile                       |   3 +
 drivers/soc/samsung/exynos-pmu.c                   | 141 +++
 drivers/soc/samsung/exynos-pmu.h                   |  44 +
 drivers/soc/samsung/exynos-srom.c                  | 232 +++++
 drivers/soc/samsung/exynos-srom.h                  |  51 ++
 drivers/soc/samsung/exynos3250-pmu.c               | 175 ++++
 drivers/soc/samsung/exynos4-pmu.c                  | 222 +++++
 drivers/soc/samsung/exynos5250-pmu.c               | 195 +++++
 drivers/soc/samsung/exynos5420-pmu.c               | 280 ++++++
 .../linux/soc/samsung}/exynos-pmu.h                |   6 +-
 .../linux/soc/samsung/exynos-regs-pmu.h            |   6 +-
 32 files changed, 1486 insertions(+), 1090 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
 delete mode 100644 arch/arm/mach-exynos/pmu.c
 delete mode 100644 arch/arm/mach-exynos/regs-srom.h
 create mode 100644 drivers/soc/samsung/Kconfig
 create mode 100644 drivers/soc/samsung/Makefile
 create mode 100644 drivers/soc/samsung/exynos-pmu.c
 create mode 100644 drivers/soc/samsung/exynos-pmu.h
 create mode 100644 drivers/soc/samsung/exynos-srom.c
 create mode 100644 drivers/soc/samsung/exynos-srom.h
 create mode 100644 drivers/soc/samsung/exynos3250-pmu.c
 create mode 100644 drivers/soc/samsung/exynos4-pmu.c
 create mode 100644 drivers/soc/samsung/exynos5250-pmu.c
 create mode 100644 drivers/soc/samsung/exynos5420-pmu.c
 rename {arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h (81%)
 rename arch/arm/mach-exynos/regs-pmu.h => include/linux/soc/samsung/exynos-regs-pmu.h (99%)


From k.kozlowski at samsung.com  Sun Feb 14 16:34:01 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Mon, 15 Feb 2016 09:34:01 +0900
Subject: [GIT PULL 2/7] ARM: dts: Exynos DT dependency for v4.6
In-Reply-To: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455496446-23779-3-git-send-email-k.kozlowski@samsung.com>

Hi Arnd, Kevin and Olof,

Early DT changes for v4.6, needed before removal of SROM support
from mach-exynos.

Kind regards,
Krzysztof


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-srom-4.6

for you to fetch changes up to d2deef6c61e65d1e0cee40c1d74fa99007da8c84:

  ARM: dts: Add SROM to exynos5410 (2016-01-25 10:32:07 +0900)

----------------------------------------------------------------
Device Tree changes for v4.6 adding the nodes for Exynos SROM controller
driver. The driver saves and restores SROM registers during suspend to RAM.
DT changes should go in before removal of SROM support from mach-exynos.

----------------------------------------------------------------
Pankaj Dubey (2):
      ARM: dts: Add SROM device node for exynos4
      ARM: dts: Add SROM device node for exynos5

Pavel Fedin (1):
      ARM: dts: Add SROM to exynos5410

 arch/arm/boot/dts/exynos4.dtsi    | 5 +++++
 arch/arm/boot/dts/exynos5.dtsi    | 5 +++++
 arch/arm/boot/dts/exynos5410.dtsi | 5 +++++
 3 files changed, 15 insertions(+)


From k.kozlowski at samsung.com  Sun Feb 14 16:34:06 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Mon, 15 Feb 2016 09:34:06 +0900
Subject: [GIT PULL 7/7] ARM: EXYNOS: Defconfig changes for v4.6
In-Reply-To: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455496446-23779-8-git-send-email-k.kozlowski@samsung.com>

Hi Arnd, Kevin and Olof,

Defconfig changes, pulling also a tag from RTC tree (merge
of max77802 into max77686 RTC driver).

Kind regards,
Krzysztof


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-4.6

for you to fetch changes up to 5d51f1dde207f2d5d43158da75c6608f7bfcec03:

  ARM: multi_v7_defconfig: Remove MAX77802 RTC Kconfig symbol (2016-02-05 09:11:32 +0900)

----------------------------------------------------------------
Defconfig (exynos and multi_v7) changes for Exynos based boards for v4.6:
1. exynos defconfig:
   a. Enable NEON and accelerated crypto,
   b. Enable s5p-secss driver (Security SubSystem block for accelerating
      some cryptographic operations),
2. exynos and multi_v7: Remove MAX77802 RTC Kconfig because the driver
   was combined into existing rtc-max77686 driver. This depends on changes
   from RTC tree.

----------------------------------------------------------------
Javier Martinez Canillas (10):
      rtc: max77686: Fix max77686_rtc_read_alarm() return value
      rtc: max77686: Use ARRAY_SIZE() instead of current array length
      rtc: max77686: Use usleep_range() instead of msleep()
      rtc: max77686: Use a driver data struct instead hard-coded values
      rtc: max77686: Add an indirection level to access RTC registers
      rtc: max77686: Add max77802 support
      rtc: max77686: Fix unsupported year message
      rtc: Remove Maxim 77802 driver
      ARM: exynos_defconfig: Remove MAX77802 RTC Kconfig symbol
      ARM: multi_v7_defconfig: Remove MAX77802 RTC Kconfig symbol

Krzysztof Kozlowski (5):
      ARM: exynos_defconfig: Enable NEON, accelerated crypto and cpufreq stats
      ARM: exynos_defconfig: Enable s5p-secss driver
      rtc: max77686: Properly handle regmap_irq_get_virq() error code
      rtc: max77686: Cleanup and reduce dmesg output
      Merge tag 'rtc-max77686-4.6' of git://git.kernel.org/.../abelloni/linux into next/defconfig

 arch/arm/configs/exynos_defconfig   |  10 +-
 arch/arm/configs/multi_v7_defconfig |   1 -
 drivers/rtc/Kconfig                 |  10 -
 drivers/rtc/Makefile                |   1 -
 drivers/rtc/rtc-max77686.c          | 362 ++++++++++++++++++++------
 drivers/rtc/rtc-max77802.c          | 502 ------------------------------------
 6 files changed, 285 insertions(+), 601 deletions(-)
 delete mode 100644 drivers/rtc/rtc-max77802.c


From k.kozlowski at samsung.com  Sun Feb 14 16:34:02 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Mon, 15 Feb 2016 09:34:02 +0900
Subject: [GIT PULL 3/7] drivers: soc: EXYNOS drivers for v4.6
In-Reply-To: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455496446-23779-4-git-send-email-k.kozlowski@samsung.com>

Hi Arnd, Kevin and Olof,

This finally moves SROM controller and PMU code to separate
driver under drivers/soc/samsung.

Kind regards,
Krzysztof


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-soc-srom-pmu-4.6

for you to fetch changes up to 74a6659e8bf193066ba6bf365de66baa897aebb1:

  drivers: soc: Add support for Exynos PMU driver (2016-01-25 10:46:59 +0900)

----------------------------------------------------------------
A set of changes adding new drivers under drivers/soc/samsung:

1. Split code for handling SROM registers out of arm/mach-exynos
   in to separate SROM controller driver under drivers/soc/samsung.
   The driver will save and restore SROM registers during Suspend
   to RAM.

2. Add to this SROM controller driver support for bank configuration
   used by child devices. This allows usage of SMSC9115 Ethernet chip
   on SMDK5410 (Exynos5410) directly connected to SROM controller.

3. Move Exynos PMU driver implementation from arm/mach-exynos
   to the drivers/soc/samsung which will allow re-use of it on ARM64.

----------------------------------------------------------------
Krzysztof Kozlowski (1):
      Merge tag 'samsung-dt-srom-4.6' into for-v4.6/drivers-soc-exynos-srom-pmu

Pankaj Dubey (14):
      ARM: dts: Add SROM device node for exynos4
      ARM: dts: Add SROM device node for exynos5
      ARM: EXYNOS: Remove unused static mapping of CMU for exynos5
      ARM: EXYNOS: Code cleanup in map.h
      dt-bindings: EXYNOS: Add exynos-srom device tree binding
      drivers: soc: Add support for exynos SROM driver
      MAINTAINERS: Add maintainers entry for drivers/soc/samsung
      ARM: EXYNOS: Remove SROM related register settings from mach-exynos
      ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung"
      ARM: EXYNOS: Split up exynos3250 SoC specific PMU data
      ARM: EXYNOS: Split up exynos4 SoC specific PMU data
      ARM: EXYNOS: Split up exynos5250 SoC specific PMU data
      ARM: EXYNOS: Split up exynos5420 SoC specific PMU data
      drivers: soc: Add support for Exynos PMU driver

Pavel Fedin (3):
      ARM: dts: Add SROM to exynos5410
      dt-bindings: EXYNOS: Describe SROMc configuration
      drivers: soc: exynos-srom: Add support for bank configuration

 .../bindings/arm/samsung/exynos-srom.txt           |  81 ++
 MAINTAINERS                                        |   1 +
 arch/arm/boot/dts/exynos4.dtsi                     |   5 +
 arch/arm/boot/dts/exynos5.dtsi                     |   5 +
 arch/arm/boot/dts/exynos5410.dtsi                  |   5 +
 arch/arm/mach-exynos/Kconfig                       |   3 +
 arch/arm/mach-exynos/Makefile                      |   2 +-
 arch/arm/mach-exynos/exynos.c                      |  26 +-
 arch/arm/mach-exynos/include/mach/map.h            |   8 -
 arch/arm/mach-exynos/mcpm-exynos.c                 |   2 +-
 arch/arm/mach-exynos/platsmp.c                     |   2 +-
 arch/arm/mach-exynos/pm.c                          |   4 +-
 arch/arm/mach-exynos/pmu.c                         | 967 ---------------------
 arch/arm/mach-exynos/regs-srom.h                   |  53 --
 arch/arm/mach-exynos/suspend.c                     |  24 +-
 arch/arm/plat-samsung/include/plat/map-s5p.h       |   1 -
 drivers/soc/Kconfig                                |   1 +
 drivers/soc/Makefile                               |   1 +
 drivers/soc/samsung/Kconfig                        |  17 +
 drivers/soc/samsung/Makefile                       |   3 +
 drivers/soc/samsung/exynos-pmu.c                   | 141 +++
 drivers/soc/samsung/exynos-pmu.h                   |  44 +
 drivers/soc/samsung/exynos-srom.c                  | 232 +++++
 drivers/soc/samsung/exynos-srom.h                  |  51 ++
 drivers/soc/samsung/exynos3250-pmu.c               | 175 ++++
 drivers/soc/samsung/exynos4-pmu.c                  | 222 +++++
 drivers/soc/samsung/exynos5250-pmu.c               | 195 +++++
 drivers/soc/samsung/exynos5420-pmu.c               | 280 ++++++
 .../linux/soc/samsung}/exynos-pmu.h                |   6 +-
 .../linux/soc/samsung/exynos-regs-pmu.h            |   6 +-
 30 files changed, 1478 insertions(+), 1085 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
 delete mode 100644 arch/arm/mach-exynos/pmu.c
 delete mode 100644 arch/arm/mach-exynos/regs-srom.h
 create mode 100644 drivers/soc/samsung/Kconfig
 create mode 100644 drivers/soc/samsung/Makefile
 create mode 100644 drivers/soc/samsung/exynos-pmu.c
 create mode 100644 drivers/soc/samsung/exynos-pmu.h
 create mode 100644 drivers/soc/samsung/exynos-srom.c
 create mode 100644 drivers/soc/samsung/exynos-srom.h
 create mode 100644 drivers/soc/samsung/exynos3250-pmu.c
 create mode 100644 drivers/soc/samsung/exynos4-pmu.c
 create mode 100644 drivers/soc/samsung/exynos5250-pmu.c
 create mode 100644 drivers/soc/samsung/exynos5420-pmu.c
 rename {arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h (81%)
 rename arch/arm/mach-exynos/regs-pmu.h => include/linux/soc/samsung/exynos-regs-pmu.h (99%)


From k.kozlowski at samsung.com  Sun Feb 14 16:34:04 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Mon, 15 Feb 2016 09:34:04 +0900
Subject: [GIT PULL 5/7] ARM: EXYNOS: Driver changes for v4.6
In-Reply-To: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455496446-23779-6-git-send-email-k.kozlowski@samsung.com>

Hi Arnd, Kevin and Olof,

Just one lonely commit.

Kind regards,
Krzysztof


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-4.6

for you to fetch changes up to 9b3f105ef6c75ef4f7f1bd982195db814830d78b:

  cpufreq: s5pv210: remove superfluous CONFIG_PM ifdefs (2016-01-25 15:13:53 +0900)

----------------------------------------------------------------
Exynos-specific driver changes for v4.6:
1. Minor cleanup in s5pv210-cpufreq driver.

----------------------------------------------------------------
Bartlomiej Zolnierkiewicz (1):
      cpufreq: s5pv210: remove superfluous CONFIG_PM ifdefs

 drivers/cpufreq/s5pv210-cpufreq.c | 2 --
 1 file changed, 2 deletions(-)


From k.kozlowski at samsung.com  Sun Feb 14 16:34:05 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Mon, 15 Feb 2016 09:34:05 +0900
Subject: [GIT PULL 6/7] ARM: dts: Exynos stuff for v4.6
In-Reply-To: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455496446-23779-7-git-send-email-k.kozlowski@samsung.com>

Hi Arnd, Kevin and Olof,

Rest of DTS changes for v4.6. This also pulls early DT changes (related
to SROM controller) because rest of patches depend on it.

Kind regards,
Krzysztof


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.6

for you to fetch changes up to 36a0282a41493400428d7df8c99701fb4ee344c2:

  ARM: dts: Replace legacy *,wakeup property with wakeup-source for exynos boards (2016-01-29 09:09:49 +0900)

----------------------------------------------------------------
Samsung DeviceTree updates and improvements for v4.6:
1. Add SROM controller device nodes.
2. Add Ethernet chip as child of SROM controller on SMDK5410.
3. Allow simultaneous usage exynos-rng and s5p-sss drivers on Exynos5.
4. Cleanup CPU configuration on Exynos542x/5800.
5. Add necessary nodes for cpufreq-dt driver on Exynos542x/5800 (OPPs,
   regulator supplies) which allows frequency and voltage scalling
   of this SoC.
6. Minor cleanups.

----------------------------------------------------------------
Bartlomiej Zolnierkiewicz (2):
      ARM: dts: Add cluster regulator supply properties for exynos542x/5800
      ARM: dts: Extend existing CPU OPP for exynos5800

Hakjoo Kim (1):
      ARM: dts: Add pinctrl support to exynos5410

Krzysztof Kozlowski (3):
      Merge tag 'samsung-dt-srom-4.6' into next/dt
      ARM: dts: Allow simultaneous usage exynos-rng and s5p-sss drivers on exynos5
      ARM: dts: Make CPU configuration more readable on exynos542x/5800

Marek Szyprowski (1):
      ARM: dts: Add GSCL block parent clock management to pm domain on exynos542x

Pankaj Dubey (2):
      ARM: dts: Add SROM device node for exynos4
      ARM: dts: Add SROM device node for exynos5

Pavel Fedin (2):
      ARM: dts: Add SROM to exynos5410
      ARM: dts: Add Ethernet chip to exynos5410-smdk5410

Sudeep Holla (2):
      ARM: dts: Replace legacy *,wakeup property with wakeup-source on s5pv210
      ARM: dts: Replace legacy *,wakeup property with wakeup-source for exynos boards

Thomas Abraham (1):
      ARM: dts: Add CPU OPP properties for exynos542x/5800

 arch/arm/boot/dts/exynos3250-monk.dts              |   6 +-
 arch/arm/boot/dts/exynos3250-rinato.dts            |   6 +-
 arch/arm/boot/dts/exynos4.dtsi                     |   5 +
 arch/arm/boot/dts/exynos4210-origen.dts            |  10 +-
 arch/arm/boot/dts/exynos4210-smdkv310.dts          |   2 +-
 arch/arm/boot/dts/exynos4210-trats.dts             |   2 +-
 arch/arm/boot/dts/exynos4210-universal_c210.dts    |   4 +-
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi    |   2 +-
 arch/arm/boot/dts/exynos4412-odroidx.dts           |   2 +-
 arch/arm/boot/dts/exynos4412-origen.dts            |   2 +-
 arch/arm/boot/dts/exynos4412-smdk4412.dts          |   2 +-
 arch/arm/boot/dts/exynos4412-trats2.dts            |   4 +-
 arch/arm/boot/dts/exynos5.dtsi                     |   5 +
 arch/arm/boot/dts/exynos5250-arndale.dts           |  12 +-
 arch/arm/boot/dts/exynos5250-snow-common.dtsi      |   4 +-
 arch/arm/boot/dts/exynos5250-spring.dts            |   4 +-
 arch/arm/boot/dts/exynos5250.dtsi                  |   2 +-
 arch/arm/boot/dts/exynos5410-pinctrl.dtsi          | 406 +++++++++++++++++++++
 arch/arm/boot/dts/exynos5410-smdk5410.dts          |  41 +++
 arch/arm/boot/dts/exynos5410.dtsi                  |  47 +++
 arch/arm/boot/dts/exynos5420-arndale-octa.dts      |  11 +-
 arch/arm/boot/dts/exynos5420-cpus.dtsi             | 102 ++++++
 arch/arm/boot/dts/exynos5420-peach-pit.dts         |  13 +-
 arch/arm/boot/dts/exynos5420-smdk5420.dts          |   9 +
 arch/arm/boot/dts/exynos5420.dtsi                  | 170 +++++----
 arch/arm/boot/dts/exynos5422-cpus.dtsi             | 140 ++++---
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |   8 +
 arch/arm/boot/dts/exynos5800-peach-pi.dts          |  13 +-
 arch/arm/boot/dts/exynos5800.dtsi                  | 108 ++++++
 arch/arm/boot/dts/s5pv210-aquila.dts               |   4 +-
 arch/arm/boot/dts/s5pv210-goni.dts                 |   4 +-
 arch/arm/boot/dts/s5pv210-smdkv210.dts             |   2 +-
 32 files changed, 989 insertions(+), 163 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos5410-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/exynos5420-cpus.dtsi


From gregkh at linuxfoundation.org  Sun Feb 14 16:41:47 2016
From: gregkh at linuxfoundation.org (Greg KH)
Date: Sun, 14 Feb 2016 16:41:47 -0800
Subject: [PATCH v5 2/8] Staging: rts5208: rtsx_transport.c: Align to open
 parenthesis
In-Reply-To: <1455260168-16980-1-git-send-email-shaun.ren@linux.com>
References: <1455251535.13149.7.camel@perches.com>
 <1455260168-16980-1-git-send-email-shaun.ren@linux.com>
Message-ID: <20160215004147.GA1440@kroah.com>

On Thu, Feb 11, 2016 at 10:56:08PM -0800, Shaun Ren wrote:
> This patch fixes the alignment issue reported by checkpatch.pl:
> 
> CHECK: Alignment should match open parenthesis
> 
> Add a unsigned char *sgbuffer in rtsx_stor_access_xfer_buffer to make the
> following memcpy logic easier to read.
> 
> Add a struct scatterlist *sg in the use_sg branch of
> rtsx_transfer_data_partial to make the parameters of the
> rtsx_transfer_sglist_adma_partial call fit in 80 character lines after
> aligning them to the open parenthesis.
> 
> Refactor memcpy logic in rtsx_stor_access_xfer_buf to make it more legible.
> 
> Signed-off-by: Shaun Ren <shaun.ren at linux.com>
> ---
>  drivers/staging/rts5208/rtsx_transport.c | 69 +++++++++++++++++++-------------
> Changes since v3
>   * Fixed misalignment of the last parameter of rtsx_stor_access_xfer_buf()
>   * Refactored memcpy in rtsx_stor_access_xfer_buf() for legibility

Where are the 7 other patches in this series?

Please resend all of them.

thanks,

greg k-h


From horms at verge.net.au  Sun Feb 14 17:45:27 2016
From: horms at verge.net.au (Simon Horman)
Date: Mon, 15 Feb 2016 10:45:27 +0900
Subject: [PATCH] ARM: dts: porter: add MAX3355 support
In-Reply-To: <56AFAB67.20404@cogentembedded.com>
References: <1674850.BZpGW9kEud@wasted.cogentembedded.com>
 <4506196.xOgpYRO52t@wasted.cogentembedded.com>
 <SG2PR06MB0919D09C1146EAC0681EE109D8DA0@SG2PR06MB0919.apcprd06.prod.outlook.com>
 <56ABCB69.1070800@cogentembedded.com>
 <56ABD066.7020804@cogentembedded.com>
 <SG2PR06MB0919361DC5805AE3F5B74041D8DE0@SG2PR06MB0919.apcprd06.prod.outlook.com>
 <56AF9BE8.4020002@cogentembedded.com>
 <56AFAB67.20404@cogentembedded.com>
Message-ID: <20160215014527.GE12997@verge.net.au>

On Mon, Feb 01, 2016 at 10:00:55PM +0300, Sergei Shtylyov wrote:
> On 02/01/2016 08:54 PM, Sergei Shtylyov wrote:
> 
> >>>>>>From: linux-renesas-soc-owner at vger.kernel.org
> >>>>>>[mailto:linux-renesas-soc-owner at vger.kernel.org] On Behalf Of Sergei
> >>>>>>Shtylyov
> >>>>>>Sent: Wednesday, January 27, 2016 7:14 AM
> >>>>>>
> >>>>>>Now that Maxim Integrated MAX3355 'extcon' driver and device tree bindings
> >>>>>>are upstream along with the 'extcon' hook  in the Renesas USBHS driver, we
> >>>>>>can add  MAX3355 device node to  the Porter device tree and properly refer
> >>>>>>to it from the USBHS node instead of using  "renesas,enable-gpio" property
> >>>>>>which only allowed checking the USB ID pin  at the driver probe time;  now
> >>>>>>this  pin's  state can be monitored dynamically!
> >>>>>>
> >>>>>>Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> >>>>>
> >>>>>I tested this patch on Porter, but interrupt of "usb-otg" didn't happened
> >>>>>even if I connected/disconnected a usb convert cable (usb micro-ab to A).
> >>>>>Remarks: I confirmed that the usb convert cable worked correctly on other
> >>>>>board.
> >>>>
> >>>>     I guess I have the same cable
> >>>
> >>>     No, I have mini-AB connector here and hence my cable is mini-AB to A.
> >>
> >>I checked Porter specification and then I found 2 specifications exist...
> >
> >    I've looked thru my schematics files and found 3: Rev. 1.1 Update Version
> >2, "PORTER_2" Rev. 3.0 Preliminary, and "PORTER_C" Rev. 3.0 Release version!
> >I'm not sure which of the last 2 should be considered final...
> 
>    Now I've found 5 versions of the Porter schematics... :-)
> 
> >>  Porter "B" : mini AB connecter and Max3355 is on the board.
> >>  Porter "C" : micro AB connect and Max3355 is not on the board. (Select
> >>host/peripheral by a jumper.)
> >
> >    Yeah, seeing JP13 in the PORTER_C schematics.
> >
> >>I guess that your current target is "B".
> >
> >    If not earlier. It actually has "Henninger B REV2" printed on it and
> >"Porter PCB 1 R3" on a pasted sticker.
> >
> >>If so, I think this patch is acceptable.
> >
> >    I'm not so sure now...
> 
>    My boss told me PORTER_C is a final version, so this patch isn't needed.
> But then another patch is needed instead: to remove "renesas,enable-gpio"
> prop from the HS-USB device node...

I am marking this patch as "Rejected" in patchwork.
If changes are required in this area please either
resubmit this patch or post a different one.

Thanks.


From horms at verge.net.au  Sun Feb 14 17:54:21 2016
From: horms at verge.net.au (Simon Horman)
Date: Mon, 15 Feb 2016 10:54:21 +0900
Subject: [PATCH 0/2] ARM: shmobile: r8a779x: use fallback pcie
 compatibility string
In-Reply-To: <1450406163-23795-1-git-send-email-horms+renesas@verge.net.au>
References: <1450406163-23795-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20160215015421.GB14034@verge.net.au>

[Cc: linux-renesas-soc at vger.kernel.org]

On Fri, Dec 18, 2015 at 11:36:01AM +0900, Simon Horman wrote:
> Hi,
> 
> this short series makes use of the recently added fallback pcie
> compatibility string in the r8a779[01] device trees.
> 
> Based on renesas-devel-20151218-v4.4-rc5.
> 
> Simon Horman (2):
>   ARM: shmobile: r8a7790: use fallback pcie compatibility string
>   ARM: shmobile: r8a7791: use fallback pcie compatibility string
> 
>  arch/arm/boot/dts/r8a7790.dtsi | 2 +-
>  arch/arm/boot/dts/r8a7791.dtsi | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

I have queued these up for v4.6.


From horms at verge.net.au  Sun Feb 14 17:55:42 2016
From: horms at verge.net.au (Simon Horman)
Date: Mon, 15 Feb 2016 10:55:42 +0900
Subject: [PATCH 0/3] ARM: shmobile: r8a779x: use fallback pcie
 compatibility string
In-Reply-To: <1450406559-9076-1-git-send-email-horms+renesas@verge.net.au>
References: <1450406559-9076-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <20160215015542.GC14034@verge.net.au>

[Cc linux-renesas-soc at vger.kernel.org]

On Fri, Dec 18, 2015 at 11:42:36AM +0900, Simon Horman wrote:
> Hi,
> 
> this short series makes use of the recently added fallback pci
> compatibility string in the r8a779[014] device trees.
> 
> Based on renesas-devel-20151218-v4.4-rc5.
> 
> Simon Horman (3):
>   ARM: shmobile: r8a7790: use fallback pci compatibility string
>   ARM: shmobile: r8a7791: use fallback pci compatibility string
>   ARM: shmobile: r8a7794: use fallback pci compatibility string
> 
>  arch/arm/boot/dts/r8a7790.dtsi | 6 +++---
>  arch/arm/boot/dts/r8a7791.dtsi | 4 ++--
>  arch/arm/boot/dts/r8a7794.dtsi | 4 ++--
>  3 files changed, 7 insertions(+), 7 deletions(-)

I have queued these up for v4.6


From eddie.huang at mediatek.com  Sun Feb 14 17:58:17 2016
From: eddie.huang at mediatek.com (Eddie Huang)
Date: Mon, 15 Feb 2016 09:58:17 +0800
Subject: [PATCH] rtc: mt6397: Add platform device ID table
In-Reply-To: <1455016095-13724-1-git-send-email-javier@osg.samsung.com>
References: <1455016095-13724-1-git-send-email-javier@osg.samsung.com>
Message-ID: <1455501497.7263.4.camel@mtksdaap41>

On Tue, 2016-02-09 at 08:08 -0300, Javier Martinez Canillas wrote:
> The platform bus_type .match callback attempts to match the platform device
> name with an entry on the .id_table if provided and fallbacks to match with
> the driver's name if a table is not provided.
> 
> Using a platform device ID to match is more explicit, allows the driver to
> support more than one device and also the MODULE_DEVICE_TABLE macro can be
> used to export the module aliases information instead of the MODULE_ALIAS.
> 
> Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
> 
> ---
> 
>  drivers/rtc/rtc-mt6397.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
> index 06a5c52b292f..46533f11f7fc 100644
> --- a/drivers/rtc/rtc-mt6397.c
> +++ b/drivers/rtc/rtc-mt6397.c
> @@ -404,6 +404,12 @@ static const struct of_device_id mt6397_rtc_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, mt6397_rtc_of_match);
>  
> +static const struct platform_device_id mt6397_rtc_id[] = {
> +	{"mt6397-rtc", 0},
> +	{ /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(platform, mt6397_rtc_id);
> +
>  static struct platform_driver mtk_rtc_driver = {
>  	.driver = {
>  		.name = "mt6397-rtc",
> @@ -412,6 +418,7 @@ static struct platform_driver mtk_rtc_driver = {
>  	},
>  	.probe	= mtk_rtc_probe,
>  	.remove = mtk_rtc_remove,
> +	.id_table = mt6397_rtc_id,
>  };
>  
>  module_platform_driver(mtk_rtc_driver);
> @@ -419,4 +426,3 @@ module_platform_driver(mtk_rtc_driver);
>  MODULE_LICENSE("GPL v2");
>  MODULE_AUTHOR("Tianping Fang <tianping.fang at mediatek.com>");
>  MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC");
> -MODULE_ALIAS("platform:mt6397-rtc");

This patch looks good to me, but I am wondering, since we tend to use
device tree method to match driver, do we still need support platform
device ID ?

Eddie




From horms at verge.net.au  Sun Feb 14 17:58:49 2016
From: horms at verge.net.au (Simon Horman)
Date: Mon, 15 Feb 2016 10:58:49 +0900
Subject: [PATCH v2 0/6] ARM/arm64 : shmobile/renesas: Add L2
 cache-controller nodes
In-Reply-To: <1449512659-16688-1-git-send-email-geert+renesas@glider.be>
References: <1449512659-16688-1-git-send-email-geert+renesas@glider.be>
Message-ID: <20160215015848.GD14034@verge.net.au>

Hi Geert,

On Mon, Dec 07, 2015 at 07:24:13PM +0100, Geert Uytterhoeven wrote:
> 	Hi Simon, Magnus,
> 
> This patch series adds the missing L2 cache-controller nodes to the
> DTSes for various Renesas ARM-based SoCs, and links the CPU nodes to
> them.
> 
> For R-Mobile APE6 (r8a73a4), the L2 cache-controllers are also linked to
> the respective (already existing) SYSC Power Domains. Fortunately these
> Power Domains were never powered down, as they are parents of the Power
> Domains containing CPU cores. This may change in the future.
> 
> For R-Car Gen2 and Gen3 (r8a779x), this serves as a preparatory step for
> adding SYSC Power Domain support later.
> 
> Question for the ARM/DT people: What are the DT bindings for
> Cortex-A15/A7/A57/A53 L2 cache controllers?
> Everybody just seems to use "cache" for the compatible values...
> 
> Patches 2-5 were extracted from series "[PATCH/RFC 00/15]
> ARM: shmobile: R-Car: Add SYSC PM Domain DT Support",
> (http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348742.html)
> and received some fixes. You can find more detailed changelogs in the
> individual patches).
> 
> This has been tested on r8a73a4/ape6evm, r8a7791/koelsch, and
> r8a7795/salvator-x.

Sorry for loosing track of this until now.

It seems to me that the Gen-2 changes could be applied, is that correct?
It also seems to me that there was inconclusive discussion regarding
the r8a7795 change, is that also correct.

> 
> Thanks!
> 
> Geert Uytterhoeven (6):
>   ARM: shmobile: r8a73a4 dtsi: Add L2 cache-controller nodes
>   ARM: shmobile: r8a7790 dtsi: Add L2 cache-controller nodes
>   ARM: shmobile: r8a7791 dtsi: Add L2 cache-controller node
>   ARM: shmobile: r8a7793 dtsi: Add L2 cache-controller node
>   ARM: shmobile: r8a7794 dtsi: Add L2 cache-controller node
>   arm64: renesas: r8a7795: Add L2 cache-controller nodes
> 
>  arch/arm/boot/dts/r8a73a4.dtsi           | 19 +++++++++++++++++++
>  arch/arm/boot/dts/r8a7790.dtsi           | 22 ++++++++++++++++++++++
>  arch/arm/boot/dts/r8a7791.dtsi           | 10 ++++++++++
>  arch/arm/boot/dts/r8a7793.dtsi           |  9 +++++++++
>  arch/arm/boot/dts/r8a7794.dtsi           |  8 ++++++++
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 15 +++++++++++++++
>  6 files changed, 83 insertions(+)
> 
> -- 
> 1.9.1
> 
> Gr{oetje,eeting}s,
> 
> 						Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> 							    -- Linus Torvalds
> 


From djkurtz at chromium.org  Sun Feb 14 18:11:45 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Mon, 15 Feb 2016 10:11:45 +0800
Subject: [PATCH 2/3] thermal: Add Mediatek thermal controller support
In-Reply-To: <1454295246.22151.6.camel@mtksdaap41>
References: <1448883753-19068-1-git-send-email-s.hauer@pengutronix.de>
 <1448883753-19068-3-git-send-email-s.hauer@pengutronix.de>
 <20151217193332.GB7999@localhost.localdomain>
 <20160104141940.GI13058@pengutronix.de>
 <20160119072917.GA13237@pengutronix.de> <1454295246.22151.6.camel@mtksdaap41>
Message-ID: <CAGS+omD9U8tKmb02d_gMMAGX18MJZhz0RrugpBK2EuqgZrBy6g@mail.gmail.com>

Hi Eduardo, Sascha,

On Mon, Feb 1, 2016 at 10:54 AM, Eddie Huang <eddie.huang at mediatek.com> wrote:
>
> On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
> > Eduardo,
> >
> > On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
> > > Hi Eduardo,
> > >
> > > >
> > > > That should remove the policy of computing the maximum from this driver.
> > > > Please have a look on the work being done [1] to add grouping and
> > > > aggregation of thermal zones. With that in place, you should be a matter
> > > > of configuring the grouping and selecting max as the aggregation function,
> > > > from the thermal core, instead in the driver. Which should give the
> > > > system engineer, more flexibility to compose whatever policy based on
> > > > the exposed sensors.
> > >
> > > I think the aggregation of thermal zones is quite useful when it comes
> > > to putting different chips together to a system. I am not so sure how
> > > useful it is to expose different thermal zones of a single SoC to the
> > > device tree.
> > > Currently the only control knob we have is the CPU frequency. When any
> > > of the sensors on the SoC gets too hot then the only thing we can do is
> > > to decrease the CPU frequency. This does not leave much space for
> > > configuration in the device tree.
> > > What I need to be able is to attach multiple sensors to one thermal
> > > zone. The aggregation patch series only partly solves that and I think
> > > is inconsistent, but I commented on the series directly.
> >
> > Any input on this? I really like to get this driver upstream as it is
> > currently blocking other Mediatek drivers.
> >
>
> Hi Eduardo,
>
> Do you have any comment about Sascha's response ? We really hope get
> your comment since Mediatek thermal driver already reviewed in public
> over half years, and we have other patches [0] [1] depend on thermal
> driver.
>
> [0]:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> [1]:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html

Friendly ping on the Mediatek thermal driver.
The "EFUSE" dependency has now landed in v4.5-rc4.
So, AFAICT, the only thing left that may be blocking landing Mediatek
thermal driver is resolution of this discussion about thermal zones.
Can we kindly resolve this soon so we have a chance to land it in v4.6.

Thanks,
-Dan


From djkurtz at chromium.org  Sun Feb 14 18:14:12 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Mon, 15 Feb 2016 10:14:12 +0800
Subject: [PATCH 2/3] thermal: Add Mediatek thermal controller support
In-Reply-To: <CAGS+omD9U8tKmb02d_gMMAGX18MJZhz0RrugpBK2EuqgZrBy6g@mail.gmail.com>
References: <1448883753-19068-1-git-send-email-s.hauer@pengutronix.de>
 <1448883753-19068-3-git-send-email-s.hauer@pengutronix.de>
 <20151217193332.GB7999@localhost.localdomain>
 <20160104141940.GI13058@pengutronix.de>
 <20160119072917.GA13237@pengutronix.de> <1454295246.22151.6.camel@mtksdaap41>
 <CAGS+omD9U8tKmb02d_gMMAGX18MJZhz0RrugpBK2EuqgZrBy6g@mail.gmail.com>
Message-ID: <CAGS+omArr0_-ziBXWjEcKS0bqnruNzZc2aq2s3zkghUC7_HfGw@mail.gmail.com>

On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz at chromium.org> wrote:
> Hi Eduardo, Sascha,
>
> On Mon, Feb 1, 2016 at 10:54 AM, Eddie Huang <eddie.huang at mediatek.com> wrote:
>>
>> On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
>> > Eduardo,
>> >
>> > On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
>> > > Hi Eduardo,
>> > >
>> > > >
>> > > > That should remove the policy of computing the maximum from this driver.
>> > > > Please have a look on the work being done [1] to add grouping and
>> > > > aggregation of thermal zones. With that in place, you should be a matter
>> > > > of configuring the grouping and selecting max as the aggregation function,
>> > > > from the thermal core, instead in the driver. Which should give the
>> > > > system engineer, more flexibility to compose whatever policy based on
>> > > > the exposed sensors.
>> > >
>> > > I think the aggregation of thermal zones is quite useful when it comes
>> > > to putting different chips together to a system. I am not so sure how
>> > > useful it is to expose different thermal zones of a single SoC to the
>> > > device tree.
>> > > Currently the only control knob we have is the CPU frequency. When any
>> > > of the sensors on the SoC gets too hot then the only thing we can do is
>> > > to decrease the CPU frequency. This does not leave much space for
>> > > configuration in the device tree.
>> > > What I need to be able is to attach multiple sensors to one thermal
>> > > zone. The aggregation patch series only partly solves that and I think
>> > > is inconsistent, but I commented on the series directly.
>> >
>> > Any input on this? I really like to get this driver upstream as it is
>> > currently blocking other Mediatek drivers.
>> >
>>
>> Hi Eduardo,
>>
>> Do you have any comment about Sascha's response ? We really hope get
>> your comment since Mediatek thermal driver already reviewed in public
>> over half years, and we have other patches [0] [1] depend on thermal
>> driver.
>>
>> [0]:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
>> [1]:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
>
> Friendly ping on the Mediatek thermal driver.
> The "EFUSE" dependency has now landed in v4.5-rc4.

Actually, it landed in char-misc-next, not v4.5-rc4.

> So, AFAICT, the only thing left that may be blocking landing Mediatek
> thermal driver is resolution of this discussion about thermal zones.
> Can we kindly resolve this soon so we have a chance to land it in v4.6.
>
> Thanks,
> -Dan


From chaotian.jing at mediatek.com  Sun Feb 14 10:31:00 2016
From: chaotian.jing at mediatek.com (Chaotian Jing)
Date: Mon, 15 Feb 2016 02:31:00 +0800
Subject: [PATCH] mmc: mediatek: add SD write protect support
Message-ID: <1455474660-19864-1-git-send-email-chaotian.jing@mediatek.com>

use mmc core layer's API to support sd write protect

Signed-off-by: Chaotian Jing <chaotian.jing at mediatek.com>
---
 drivers/mmc/host/mtk-sd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 82a97ac..f01972e 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -35,6 +35,7 @@
 #include <linux/mmc/mmc.h>
 #include <linux/mmc/sd.h>
 #include <linux/mmc/sdio.h>
+#include <linux/mmc/slot-gpio.h>
 
 #define MAX_BD_NUM          1024
 
@@ -1452,6 +1453,7 @@ static struct mmc_host_ops mt_msdc_ops = {
 	.pre_req = msdc_pre_req,
 	.request = msdc_ops_request,
 	.set_ios = msdc_ops_set_ios,
+	.get_ro = mmc_gpio_get_ro,
 	.start_signal_voltage_switch = msdc_ops_switch_volt,
 	.card_busy = msdc_card_busy,
 	.execute_tuning = msdc_execute_tuning,
-- 
1.8.1.1.dirty



From ykk at rock-chips.com  Sun Feb 14 19:25:00 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 11:25:00 +0800
Subject: [PATCH v13.1 02/19] drm/exynos: dp: rename implementation specific
 driver part
In-Reply-To: <1453427614-23053-1-git-send-email-ykk@rock-chips.com>
References: <1453427614-23053-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455506700-31818-1-git-send-email-ykk@rock-chips.com>

From: Heiko Stuebner <heiko at sntech.de>

The core functionality now resides in the generic bridge part so the
exynos-specific implementation details can get a more suitable nameing.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
This patch is splited from "[PATCH v13 01/17] drm: bridge: analogix/dp: split
exynos dp driver to bridge directory".

Changes in v13.1: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/exynos/Makefile                          | 2 +-
 drivers/gpu/drm/exynos/{exynos_dp_core.c => exynos_dp.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/gpu/drm/exynos/{exynos_dp_core.c => exynos_dp.c} (100%)

diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 18244c5..533151b 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -13,7 +13,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS5433_DECON)	+= exynos5433_drm_decon.o
 exynosdrm-$(CONFIG_DRM_EXYNOS7_DECON)	+= exynos7_drm_decon.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DPI)	+= exynos_drm_dpi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DSI)	+= exynos_drm_dsi.o
-exynosdrm-$(CONFIG_DRM_EXYNOS_DP)	+= exynos_dp_core.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_DP)	+= exynos_dp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER)	+= exynos_mixer.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)	+= exynos_hdmi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)	+= exynos_drm_vidi.o
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp.c
similarity index 100%
rename from drivers/gpu/drm/exynos/exynos_dp_core.c
rename to drivers/gpu/drm/exynos/exynos_dp.c
-- 
1.9.1




From ykk at rock-chips.com  Sun Feb 14 19:25:17 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 11:25:17 +0800
Subject: [PATCH v13.1 03/19] drm: bridge: analogix/dp: rename register
 constants
In-Reply-To: <1453427614-23053-1-git-send-email-ykk@rock-chips.com>
References: <1453427614-23053-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455506717-31869-1-git-send-email-ykk@rock-chips.com>

From: Heiko Stuebner <heiko at sntech.de>

In the original split we kept the register constants intact to keep the
diff small. Still the constants are Analogix-specific, so rename them now.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
This patch is splited from "[PATCH v13 01/17] drm: bridge: analogix/dp: split
exynos dp driver to bridge directory".

Changes in v13.1: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 456 +++++++++++-----------
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 248 ++++++------
 2 files changed, 352 insertions(+), 352 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 0b926ea..442cc66 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -29,13 +29,13 @@ void analogix_dp_enable_video_mute(struct analogix_dp_device *dp, bool enable)
 	u32 reg;
 
 	if (enable) {
-		reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+		reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 		reg |= HDCP_VIDEO_MUTE;
-		writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+		writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 	} else {
-		reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+		reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 		reg &= ~HDCP_VIDEO_MUTE;
-		writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+		writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 	}
 }
 
@@ -43,9 +43,9 @@ void analogix_dp_stop_video(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 	reg &= ~VIDEO_EN;
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 }
 
 void analogix_dp_lane_swap(struct analogix_dp_device *dp, bool enable)
@@ -59,7 +59,7 @@ void analogix_dp_lane_swap(struct analogix_dp_device *dp, bool enable)
 		reg = LANE3_MAP_LOGIC_LANE_3 | LANE2_MAP_LOGIC_LANE_2 |
 			LANE1_MAP_LOGIC_LANE_1 | LANE0_MAP_LOGIC_LANE_0;
 
-	writel(reg, dp->reg_base + EXYNOS_DP_LANE_MAP);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LANE_MAP);
 }
 
 void analogix_dp_init_analog_param(struct analogix_dp_device *dp)
@@ -67,41 +67,41 @@ void analogix_dp_init_analog_param(struct analogix_dp_device *dp)
 	u32 reg;
 
 	reg = TX_TERMINAL_CTRL_50_OHM;
-	writel(reg, dp->reg_base + EXYNOS_DP_ANALOG_CTL_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_1);
 
 	reg = SEL_24M | TX_DVDD_BIT_1_0625V;
-	writel(reg, dp->reg_base + EXYNOS_DP_ANALOG_CTL_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
 
 	reg = DRIVE_DVDD_BIT_1_0625V | VCO_BIT_600_MICRO;
-	writel(reg, dp->reg_base + EXYNOS_DP_ANALOG_CTL_3);
+	writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_3);
 
 	reg = PD_RING_OSC | AUX_TERMINAL_CTRL_50_OHM |
 		TX_CUR1_2X | TX_CUR_16_MA;
-	writel(reg, dp->reg_base + EXYNOS_DP_PLL_FILTER_CTL_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_PLL_FILTER_CTL_1);
 
 	reg = CH3_AMP_400_MV | CH2_AMP_400_MV |
 		CH1_AMP_400_MV | CH0_AMP_400_MV;
-	writel(reg, dp->reg_base + EXYNOS_DP_TX_AMP_TUNING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_TX_AMP_TUNING_CTL);
 }
 
 void analogix_dp_init_interrupt(struct analogix_dp_device *dp)
 {
 	/* Set interrupt pin assertion polarity as high */
-	writel(INT_POL1 | INT_POL0, dp->reg_base + EXYNOS_DP_INT_CTL);
+	writel(INT_POL1 | INT_POL0, dp->reg_base + ANALOGIX_DP_INT_CTL);
 
 	/* Clear pending regisers */
-	writel(0xff, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_1);
-	writel(0x4f, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_2);
-	writel(0xe0, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_3);
-	writel(0xe7, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_4);
-	writel(0x63, dp->reg_base + EXYNOS_DP_INT_STA);
+	writel(0xff, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_1);
+	writel(0x4f, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_2);
+	writel(0xe0, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_3);
+	writel(0xe7, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_4);
+	writel(0x63, dp->reg_base + ANALOGIX_DP_INT_STA);
 
 	/* 0:mask,1: unmask */
-	writel(0x00, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_1);
-	writel(0x00, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_2);
-	writel(0x00, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_3);
-	writel(0x00, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_4);
-	writel(0x00, dp->reg_base + EXYNOS_DP_INT_STA_MASK);
+	writel(0x00, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_1);
+	writel(0x00, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_2);
+	writel(0x00, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_3);
+	writel(0x00, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_4);
+	writel(0x00, dp->reg_base + ANALOGIX_DP_INT_STA_MASK);
 }
 
 void analogix_dp_reset(struct analogix_dp_device *dp)
@@ -114,44 +114,44 @@ void analogix_dp_reset(struct analogix_dp_device *dp)
 	reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
 		AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
 		HDCP_FUNC_EN_N | SW_FUNC_EN_N;
-	writel(reg, dp->reg_base + EXYNOS_DP_FUNC_EN_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
 
 	reg = SSC_FUNC_EN_N | AUX_FUNC_EN_N |
 		SERDES_FIFO_FUNC_EN_N |
 		LS_CLK_DOMAIN_FUNC_EN_N;
-	writel(reg, dp->reg_base + EXYNOS_DP_FUNC_EN_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_2);
 
 	usleep_range(20, 30);
 
 	analogix_dp_lane_swap(dp, 0);
 
-	writel(0x0, dp->reg_base + EXYNOS_DP_SYS_CTL_1);
-	writel(0x40, dp->reg_base + EXYNOS_DP_SYS_CTL_2);
-	writel(0x0, dp->reg_base + EXYNOS_DP_SYS_CTL_3);
-	writel(0x0, dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_SYS_CTL_1);
+	writel(0x40, dp->reg_base + ANALOGIX_DP_SYS_CTL_2);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 
-	writel(0x0, dp->reg_base + EXYNOS_DP_PKT_SEND_CTL);
-	writel(0x0, dp->reg_base + EXYNOS_DP_HDCP_CTL);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_HDCP_CTL);
 
-	writel(0x5e, dp->reg_base + EXYNOS_DP_HPD_DEGLITCH_L);
-	writel(0x1a, dp->reg_base + EXYNOS_DP_HPD_DEGLITCH_H);
+	writel(0x5e, dp->reg_base + ANALOGIX_DP_HPD_DEGLITCH_L);
+	writel(0x1a, dp->reg_base + ANALOGIX_DP_HPD_DEGLITCH_H);
 
-	writel(0x10, dp->reg_base + EXYNOS_DP_LINK_DEBUG_CTL);
+	writel(0x10, dp->reg_base + ANALOGIX_DP_LINK_DEBUG_CTL);
 
-	writel(0x0, dp->reg_base + EXYNOS_DP_PHY_TEST);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_PHY_TEST);
 
-	writel(0x0, dp->reg_base + EXYNOS_DP_VIDEO_FIFO_THRD);
-	writel(0x20, dp->reg_base + EXYNOS_DP_AUDIO_MARGIN);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_VIDEO_FIFO_THRD);
+	writel(0x20, dp->reg_base + ANALOGIX_DP_AUDIO_MARGIN);
 
-	writel(0x4, dp->reg_base + EXYNOS_DP_M_VID_GEN_FILTER_TH);
-	writel(0x2, dp->reg_base + EXYNOS_DP_M_AUD_GEN_FILTER_TH);
+	writel(0x4, dp->reg_base + ANALOGIX_DP_M_VID_GEN_FILTER_TH);
+	writel(0x2, dp->reg_base + ANALOGIX_DP_M_AUD_GEN_FILTER_TH);
 
-	writel(0x00000101, dp->reg_base + EXYNOS_DP_SOC_GENERAL_CTL);
+	writel(0x00000101, dp->reg_base + ANALOGIX_DP_SOC_GENERAL_CTL);
 }
 
 void analogix_dp_swreset(struct analogix_dp_device *dp)
 {
-	writel(RESET_DP_TX, dp->reg_base + EXYNOS_DP_TX_SW_RESET);
+	writel(RESET_DP_TX, dp->reg_base + ANALOGIX_DP_TX_SW_RESET);
 }
 
 void analogix_dp_config_interrupt(struct analogix_dp_device *dp)
@@ -160,26 +160,26 @@ void analogix_dp_config_interrupt(struct analogix_dp_device *dp)
 
 	/* 0: mask, 1: unmask */
 	reg = COMMON_INT_MASK_1;
-	writel(reg, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_1);
 
 	reg = COMMON_INT_MASK_2;
-	writel(reg, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_2);
 
 	reg = COMMON_INT_MASK_3;
-	writel(reg, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_3);
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_3);
 
 	reg = COMMON_INT_MASK_4;
-	writel(reg, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_4);
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_4);
 
 	reg = INT_STA_MASK;
-	writel(reg, dp->reg_base + EXYNOS_DP_INT_STA_MASK);
+	writel(reg, dp->reg_base + ANALOGIX_DP_INT_STA_MASK);
 }
 
 enum pll_status analogix_dp_get_pll_lock_status(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_DEBUG_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_DEBUG_CTL);
 	if (reg & PLL_LOCK)
 		return PLL_LOCKED;
 	else
@@ -191,13 +191,13 @@ void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool enable)
 	u32 reg;
 
 	if (enable) {
-		reg = readl(dp->reg_base + EXYNOS_DP_PLL_CTL);
+		reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
 		reg |= DP_PLL_PD;
-		writel(reg, dp->reg_base + EXYNOS_DP_PLL_CTL);
+		writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
 	} else {
-		reg = readl(dp->reg_base + EXYNOS_DP_PLL_CTL);
+		reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
 		reg &= ~DP_PLL_PD;
-		writel(reg, dp->reg_base + EXYNOS_DP_PLL_CTL);
+		writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
 	}
 }
 
@@ -210,77 +210,77 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
 	switch (block) {
 	case AUX_BLOCK:
 		if (enable) {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg |= AUX_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		} else {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg &= ~AUX_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		}
 		break;
 	case CH0_BLOCK:
 		if (enable) {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg |= CH0_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		} else {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg &= ~CH0_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		}
 		break;
 	case CH1_BLOCK:
 		if (enable) {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg |= CH1_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		} else {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg &= ~CH1_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		}
 		break;
 	case CH2_BLOCK:
 		if (enable) {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg |= CH2_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		} else {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg &= ~CH2_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		}
 		break;
 	case CH3_BLOCK:
 		if (enable) {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg |= CH3_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		} else {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg &= ~CH3_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		}
 		break;
 	case ANALOG_TOTAL:
 		if (enable) {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg |= DP_PHY_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		} else {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg &= ~DP_PHY_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		}
 		break;
 	case POWER_ALL:
 		if (enable) {
 			reg = DP_PHY_PD | AUX_PD | CH3_PD | CH2_PD |
 				CH1_PD | CH0_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		} else {
-			writel(0x00, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(0x00, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		}
 		break;
 	default:
@@ -296,11 +296,11 @@ void analogix_dp_init_analog_func(struct analogix_dp_device *dp)
 	analogix_dp_set_analog_power_down(dp, POWER_ALL, 0);
 
 	reg = PLL_LOCK_CHG;
-	writel(reg, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_1);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_DEBUG_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_DEBUG_CTL);
 	reg &= ~(F_PLL_LOCK | PLL_LOCK_CTRL);
-	writel(reg, dp->reg_base + EXYNOS_DP_DEBUG_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_DEBUG_CTL);
 
 	/* Power up PLL */
 	if (analogix_dp_get_pll_lock_status(dp) == PLL_UNLOCKED) {
@@ -317,10 +317,10 @@ void analogix_dp_init_analog_func(struct analogix_dp_device *dp)
 	}
 
 	/* Enable Serdes FIFO function and Link symbol clock domain module */
-	reg = readl(dp->reg_base + EXYNOS_DP_FUNC_EN_2);
+	reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_2);
 	reg &= ~(SERDES_FIFO_FUNC_EN_N | LS_CLK_DOMAIN_FUNC_EN_N
 		| AUX_FUNC_EN_N);
-	writel(reg, dp->reg_base + EXYNOS_DP_FUNC_EN_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_2);
 }
 
 void analogix_dp_clear_hotplug_interrupts(struct analogix_dp_device *dp)
@@ -331,10 +331,10 @@ void analogix_dp_clear_hotplug_interrupts(struct analogix_dp_device *dp)
 		return;
 
 	reg = HOTPLUG_CHG | HPD_LOST | PLUG;
-	writel(reg, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_4);
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_4);
 
 	reg = INT_HPD;
-	writel(reg, dp->reg_base + EXYNOS_DP_INT_STA);
+	writel(reg, dp->reg_base + ANALOGIX_DP_INT_STA);
 }
 
 void analogix_dp_init_hpd(struct analogix_dp_device *dp)
@@ -346,9 +346,9 @@ void analogix_dp_init_hpd(struct analogix_dp_device *dp)
 
 	analogix_dp_clear_hotplug_interrupts(dp);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_3);
+	reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
 	reg &= ~(F_HPD | HPD_CTRL);
-	writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_3);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
 }
 
 enum dp_irq_type analogix_dp_get_irq_type(struct analogix_dp_device *dp)
@@ -363,7 +363,7 @@ enum dp_irq_type analogix_dp_get_irq_type(struct analogix_dp_device *dp)
 			return DP_IRQ_TYPE_HP_CABLE_OUT;
 	} else {
 		/* Parse hotplug interrupt status register */
-		reg = readl(dp->reg_base + EXYNOS_DP_COMMON_INT_STA_4);
+		reg = readl(dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_4);
 
 		if (reg & PLUG)
 			return DP_IRQ_TYPE_HP_CABLE_IN;
@@ -383,9 +383,9 @@ void analogix_dp_reset_aux(struct analogix_dp_device *dp)
 	u32 reg;
 
 	/* Disable AUX channel module */
-	reg = readl(dp->reg_base + EXYNOS_DP_FUNC_EN_2);
+	reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_2);
 	reg |= AUX_FUNC_EN_N;
-	writel(reg, dp->reg_base + EXYNOS_DP_FUNC_EN_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_2);
 }
 
 void analogix_dp_init_aux(struct analogix_dp_device *dp)
@@ -394,23 +394,23 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
 
 	/* Clear inerrupts related to AUX channel */
 	reg = RPLY_RECEIV | AUX_ERR;
-	writel(reg, dp->reg_base + EXYNOS_DP_INT_STA);
+	writel(reg, dp->reg_base + ANALOGIX_DP_INT_STA);
 
 	analogix_dp_reset_aux(dp);
 
 	/* Disable AUX transaction H/W retry */
 	reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3) | AUX_HW_RETRY_COUNT_SEL(0)|
 		AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
-	writel(reg, dp->reg_base + EXYNOS_DP_AUX_HW_RETRY_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_AUX_HW_RETRY_CTL);
 
 	/* Receive AUX Channel DEFER commands equal to DEFFER_COUNT*64 */
 	reg = DEFER_CTRL_EN | DEFER_COUNT(1);
-	writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_DEFER_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_DEFER_CTL);
 
 	/* Enable AUX channel module */
-	reg = readl(dp->reg_base + EXYNOS_DP_FUNC_EN_2);
+	reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_2);
 	reg &= ~AUX_FUNC_EN_N;
-	writel(reg, dp->reg_base + EXYNOS_DP_FUNC_EN_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_2);
 }
 
 int analogix_dp_get_plug_in_status(struct analogix_dp_device *dp)
@@ -421,7 +421,7 @@ int analogix_dp_get_plug_in_status(struct analogix_dp_device *dp)
 		if (gpio_get_value(dp->hpd_gpio))
 			return 0;
 	} else {
-		reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_3);
+		reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
 		if (reg & HPD_STATUS)
 			return 0;
 	}
@@ -433,9 +433,9 @@ void analogix_dp_enable_sw_function(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_FUNC_EN_1);
+	reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
 	reg &= ~SW_FUNC_EN_N;
-	writel(reg, dp->reg_base + EXYNOS_DP_FUNC_EN_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
 }
 
 int analogix_dp_start_aux_transaction(struct analogix_dp_device *dp)
@@ -445,34 +445,34 @@ int analogix_dp_start_aux_transaction(struct analogix_dp_device *dp)
 	int timeout_loop = 0;
 
 	/* Enable AUX CH operation */
-	reg = readl(dp->reg_base + EXYNOS_DP_AUX_CH_CTL_2);
+	reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
 	reg |= AUX_EN;
-	writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
 
 	/* Is AUX CH command reply received? */
-	reg = readl(dp->reg_base + EXYNOS_DP_INT_STA);
+	reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
 	while (!(reg & RPLY_RECEIV)) {
 		timeout_loop++;
 		if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
 			dev_err(dp->dev, "AUX CH command reply failed!\n");
 			return -ETIMEDOUT;
 		}
-		reg = readl(dp->reg_base + EXYNOS_DP_INT_STA);
+		reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
 		usleep_range(10, 11);
 	}
 
 	/* Clear interrupt source for AUX CH command reply */
-	writel(RPLY_RECEIV, dp->reg_base + EXYNOS_DP_INT_STA);
+	writel(RPLY_RECEIV, dp->reg_base + ANALOGIX_DP_INT_STA);
 
 	/* Clear interrupt source for AUX CH access error */
-	reg = readl(dp->reg_base + EXYNOS_DP_INT_STA);
+	reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
 	if (reg & AUX_ERR) {
-		writel(AUX_ERR, dp->reg_base + EXYNOS_DP_INT_STA);
+		writel(AUX_ERR, dp->reg_base + ANALOGIX_DP_INT_STA);
 		return -EREMOTEIO;
 	}
 
 	/* Check AUX CH error access status */
-	reg = readl(dp->reg_base + EXYNOS_DP_AUX_CH_STA);
+	reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_STA);
 	if ((reg & AUX_STATUS_MASK) != 0) {
 		dev_err(dp->dev, "AUX CH error happens: %d\n\n",
 			reg & AUX_STATUS_MASK);
@@ -493,19 +493,19 @@ int analogix_dp_write_byte_to_dpcd(struct analogix_dp_device *dp,
 	for (i = 0; i < 3; i++) {
 		/* Clear AUX CH data buffer */
 		reg = BUF_CLR;
-		writel(reg, dp->reg_base + EXYNOS_DP_BUFFER_DATA_CTL);
+		writel(reg, dp->reg_base + ANALOGIX_DP_BUFFER_DATA_CTL);
 
 		/* Select DPCD device address */
 		reg = AUX_ADDR_7_0(reg_addr);
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_7_0);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_7_0);
 		reg = AUX_ADDR_15_8(reg_addr);
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_15_8);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_15_8);
 		reg = AUX_ADDR_19_16(reg_addr);
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_19_16);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_19_16);
 
 		/* Write data buffer */
 		reg = (unsigned int)data;
-		writel(reg, dp->reg_base + EXYNOS_DP_BUF_DATA_0);
+		writel(reg, dp->reg_base + ANALOGIX_DP_BUF_DATA_0);
 
 		/*
 		 * Set DisplayPort transaction and write 1 byte
@@ -513,7 +513,7 @@ int analogix_dp_write_byte_to_dpcd(struct analogix_dp_device *dp,
 		 * If Bit 3 is 0, I2C transaction.
 		 */
 		reg = AUX_TX_COMM_DP_TRANSACTION | AUX_TX_COMM_WRITE;
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_1);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_1);
 
 		/* Start AUX transaction */
 		retval = analogix_dp_start_aux_transaction(dp);
@@ -538,15 +538,15 @@ int analogix_dp_read_byte_from_dpcd(struct analogix_dp_device *dp,
 	for (i = 0; i < 3; i++) {
 		/* Clear AUX CH data buffer */
 		reg = BUF_CLR;
-		writel(reg, dp->reg_base + EXYNOS_DP_BUFFER_DATA_CTL);
+		writel(reg, dp->reg_base + ANALOGIX_DP_BUFFER_DATA_CTL);
 
 		/* Select DPCD device address */
 		reg = AUX_ADDR_7_0(reg_addr);
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_7_0);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_7_0);
 		reg = AUX_ADDR_15_8(reg_addr);
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_15_8);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_15_8);
 		reg = AUX_ADDR_19_16(reg_addr);
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_19_16);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_19_16);
 
 		/*
 		 * Set DisplayPort transaction and read 1 byte
@@ -554,7 +554,7 @@ int analogix_dp_read_byte_from_dpcd(struct analogix_dp_device *dp,
 		 * If Bit 3 is 0, I2C transaction.
 		 */
 		reg = AUX_TX_COMM_DP_TRANSACTION | AUX_TX_COMM_READ;
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_1);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_1);
 
 		/* Start AUX transaction */
 		retval = analogix_dp_start_aux_transaction(dp);
@@ -566,7 +566,7 @@ int analogix_dp_read_byte_from_dpcd(struct analogix_dp_device *dp,
 	}
 
 	/* Read data buffer */
-	reg = readl(dp->reg_base + EXYNOS_DP_BUF_DATA_0);
+	reg = readl(dp->reg_base + ANALOGIX_DP_BUF_DATA_0);
 	*data = (unsigned char)(reg & 0xff);
 
 	return retval;
@@ -586,7 +586,7 @@ int analogix_dp_write_bytes_to_dpcd(struct analogix_dp_device *dp,
 
 	/* Clear AUX CH data buffer */
 	reg = BUF_CLR;
-	writel(reg, dp->reg_base + EXYNOS_DP_BUFFER_DATA_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_BUFFER_DATA_CTL);
 
 	start_offset = 0;
 	while (start_offset < count) {
@@ -599,16 +599,16 @@ int analogix_dp_write_bytes_to_dpcd(struct analogix_dp_device *dp,
 		for (i = 0; i < 3; i++) {
 			/* Select DPCD device address */
 			reg = AUX_ADDR_7_0(reg_addr + start_offset);
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_7_0);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_7_0);
 			reg = AUX_ADDR_15_8(reg_addr + start_offset);
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_15_8);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_15_8);
 			reg = AUX_ADDR_19_16(reg_addr + start_offset);
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_19_16);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_19_16);
 
 			for (cur_data_idx = 0; cur_data_idx < cur_data_count;
 			     cur_data_idx++) {
 				reg = data[start_offset + cur_data_idx];
-				writel(reg, dp->reg_base + EXYNOS_DP_BUF_DATA_0
+				writel(reg, dp->reg_base + ANALOGIX_DP_BUF_DATA_0
 							  + 4 * cur_data_idx);
 			}
 
@@ -619,7 +619,7 @@ int analogix_dp_write_bytes_to_dpcd(struct analogix_dp_device *dp,
 			 */
 			reg = AUX_LENGTH(cur_data_count) |
 				AUX_TX_COMM_DP_TRANSACTION | AUX_TX_COMM_WRITE;
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_1);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_1);
 
 			/* Start AUX transaction */
 			retval = analogix_dp_start_aux_transaction(dp);
@@ -650,7 +650,7 @@ int analogix_dp_read_bytes_from_dpcd(struct analogix_dp_device *dp,
 
 	/* Clear AUX CH data buffer */
 	reg = BUF_CLR;
-	writel(reg, dp->reg_base + EXYNOS_DP_BUFFER_DATA_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_BUFFER_DATA_CTL);
 
 	start_offset = 0;
 	while (start_offset < count) {
@@ -664,11 +664,11 @@ int analogix_dp_read_bytes_from_dpcd(struct analogix_dp_device *dp,
 		for (i = 0; i < 3; i++) {
 			/* Select DPCD device address */
 			reg = AUX_ADDR_7_0(reg_addr + start_offset);
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_7_0);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_7_0);
 			reg = AUX_ADDR_15_8(reg_addr + start_offset);
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_15_8);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_15_8);
 			reg = AUX_ADDR_19_16(reg_addr + start_offset);
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_19_16);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_19_16);
 
 			/*
 			 * Set DisplayPort transaction and read
@@ -677,7 +677,7 @@ int analogix_dp_read_bytes_from_dpcd(struct analogix_dp_device *dp,
 			 */
 			reg = AUX_LENGTH(cur_data_count) |
 				AUX_TX_COMM_DP_TRANSACTION | AUX_TX_COMM_READ;
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_1);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_1);
 
 			/* Start AUX transaction */
 			retval = analogix_dp_start_aux_transaction(dp);
@@ -690,7 +690,7 @@ int analogix_dp_read_bytes_from_dpcd(struct analogix_dp_device *dp,
 
 		for (cur_data_idx = 0; cur_data_idx < cur_data_count;
 		    cur_data_idx++) {
-			reg = readl(dp->reg_base + EXYNOS_DP_BUF_DATA_0
+			reg = readl(dp->reg_base + ANALOGIX_DP_BUF_DATA_0
 						 + 4 * cur_data_idx);
 			data[start_offset + cur_data_idx] =
 				(unsigned char)reg;
@@ -711,12 +711,12 @@ int analogix_dp_select_i2c_device(struct analogix_dp_device *dp,
 
 	/* Set EDID device address */
 	reg = device_addr;
-	writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_7_0);
-	writel(0x0, dp->reg_base + EXYNOS_DP_AUX_ADDR_15_8);
-	writel(0x0, dp->reg_base + EXYNOS_DP_AUX_ADDR_19_16);
+	writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_7_0);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_AUX_ADDR_15_8);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_AUX_ADDR_19_16);
 
 	/* Set offset from base address of EDID device */
-	writel(reg_addr, dp->reg_base + EXYNOS_DP_BUF_DATA_0);
+	writel(reg_addr, dp->reg_base + ANALOGIX_DP_BUF_DATA_0);
 
 	/*
 	 * Set I2C transaction and write address
@@ -725,7 +725,7 @@ int analogix_dp_select_i2c_device(struct analogix_dp_device *dp,
 	 */
 	reg = AUX_TX_COMM_I2C_TRANSACTION | AUX_TX_COMM_MOT |
 		AUX_TX_COMM_WRITE;
-	writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_1);
 
 	/* Start AUX transaction */
 	retval = analogix_dp_start_aux_transaction(dp);
@@ -747,7 +747,7 @@ int analogix_dp_read_byte_from_i2c(struct analogix_dp_device *dp,
 	for (i = 0; i < 3; i++) {
 		/* Clear AUX CH data buffer */
 		reg = BUF_CLR;
-		writel(reg, dp->reg_base + EXYNOS_DP_BUFFER_DATA_CTL);
+		writel(reg, dp->reg_base + ANALOGIX_DP_BUFFER_DATA_CTL);
 
 		/* Select EDID device */
 		retval = analogix_dp_select_i2c_device(dp, device_addr, reg_addr);
@@ -761,7 +761,7 @@ int analogix_dp_read_byte_from_i2c(struct analogix_dp_device *dp,
 		 */
 		reg = AUX_TX_COMM_I2C_TRANSACTION |
 			AUX_TX_COMM_READ;
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_1);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_1);
 
 		/* Start AUX transaction */
 		retval = analogix_dp_start_aux_transaction(dp);
@@ -774,7 +774,7 @@ int analogix_dp_read_byte_from_i2c(struct analogix_dp_device *dp,
 
 	/* Read data */
 	if (retval == 0)
-		*data = readl(dp->reg_base + EXYNOS_DP_BUF_DATA_0);
+		*data = readl(dp->reg_base + ANALOGIX_DP_BUF_DATA_0);
 
 	return retval;
 }
@@ -795,12 +795,12 @@ int analogix_dp_read_bytes_from_i2c(struct analogix_dp_device *dp,
 		for (j = 0; j < 3; j++) {
 			/* Clear AUX CH data buffer */
 			reg = BUF_CLR;
-			writel(reg, dp->reg_base + EXYNOS_DP_BUFFER_DATA_CTL);
+			writel(reg, dp->reg_base + ANALOGIX_DP_BUFFER_DATA_CTL);
 
 			/* Set normal AUX CH command */
-			reg = readl(dp->reg_base + EXYNOS_DP_AUX_CH_CTL_2);
+			reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
 			reg &= ~ADDR_ONLY;
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_2);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
 
 			/*
 			 * If Rx sends defer, Tx sends only reads
@@ -822,7 +822,7 @@ int analogix_dp_read_bytes_from_i2c(struct analogix_dp_device *dp,
 					AUX_TX_COMM_I2C_TRANSACTION |
 					AUX_TX_COMM_READ;
 				writel(reg, dp->reg_base +
-					EXYNOS_DP_AUX_CH_CTL_1);
+					ANALOGIX_DP_AUX_CH_CTL_1);
 
 				/* Start AUX transaction */
 				retval = analogix_dp_start_aux_transaction(dp);
@@ -834,7 +834,7 @@ int analogix_dp_read_bytes_from_i2c(struct analogix_dp_device *dp,
 						__func__);
 			}
 			/* Check if Rx sends defer */
-			reg = readl(dp->reg_base + EXYNOS_DP_AUX_RX_COMM);
+			reg = readl(dp->reg_base + ANALOGIX_DP_AUX_RX_COMM);
 			if (reg == AUX_RX_COMM_AUX_DEFER ||
 				reg == AUX_RX_COMM_I2C_DEFER) {
 				dev_err(dp->dev, "Defer: %d\n\n", reg);
@@ -843,7 +843,7 @@ int analogix_dp_read_bytes_from_i2c(struct analogix_dp_device *dp,
 		}
 
 		for (cur_data_idx = 0; cur_data_idx < 16; cur_data_idx++) {
-			reg = readl(dp->reg_base + EXYNOS_DP_BUF_DATA_0
+			reg = readl(dp->reg_base + ANALOGIX_DP_BUF_DATA_0
 						 + 4 * cur_data_idx);
 			edid[i + cur_data_idx] = (unsigned char)reg;
 		}
@@ -858,14 +858,14 @@ void analogix_dp_set_link_bandwidth(struct analogix_dp_device *dp, u32 bwtype)
 
 	reg = bwtype;
 	if ((bwtype == LINK_RATE_2_70GBPS) || (bwtype == LINK_RATE_1_62GBPS))
-		writel(reg, dp->reg_base + EXYNOS_DP_LINK_BW_SET);
+		writel(reg, dp->reg_base + ANALOGIX_DP_LINK_BW_SET);
 }
 
 void analogix_dp_get_link_bandwidth(struct analogix_dp_device *dp, u32 *bwtype)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LINK_BW_SET);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LINK_BW_SET);
 	*bwtype = reg;
 }
 
@@ -874,14 +874,14 @@ void analogix_dp_set_lane_count(struct analogix_dp_device *dp, u32 count)
 	u32 reg;
 
 	reg = count;
-	writel(reg, dp->reg_base + EXYNOS_DP_LANE_COUNT_SET);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LANE_COUNT_SET);
 }
 
 void analogix_dp_get_lane_count(struct analogix_dp_device *dp, u32 *count)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LANE_COUNT_SET);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LANE_COUNT_SET);
 	*count = reg;
 }
 
@@ -890,13 +890,13 @@ void analogix_dp_enable_enhanced_mode(struct analogix_dp_device *dp, bool enable
 	u32 reg;
 
 	if (enable) {
-		reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 		reg |= ENHANCED;
-		writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 	} else {
-		reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 		reg &= ~ENHANCED;
-		writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 	}
 }
 
@@ -908,25 +908,25 @@ void analogix_dp_set_training_pattern(struct analogix_dp_device *dp,
 	switch (pattern) {
 	case PRBS7:
 		reg = SCRAMBLING_ENABLE | LINK_QUAL_PATTERN_SET_PRBS7;
-		writel(reg, dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+		writel(reg, dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 		break;
 	case D10_2:
 		reg = SCRAMBLING_ENABLE | LINK_QUAL_PATTERN_SET_D10_2;
-		writel(reg, dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+		writel(reg, dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 		break;
 	case TRAINING_PTN1:
 		reg = SCRAMBLING_DISABLE | SW_TRAINING_PATTERN_SET_PTN1;
-		writel(reg, dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+		writel(reg, dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 		break;
 	case TRAINING_PTN2:
 		reg = SCRAMBLING_DISABLE | SW_TRAINING_PATTERN_SET_PTN2;
-		writel(reg, dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+		writel(reg, dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 		break;
 	case DP_NONE:
 		reg = SCRAMBLING_ENABLE |
 			LINK_QUAL_PATTERN_SET_DISABLE |
 			SW_TRAINING_PATTERN_SET_NORMAL;
-		writel(reg, dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+		writel(reg, dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 		break;
 	default:
 		break;
@@ -937,40 +937,40 @@ void analogix_dp_set_lane0_pre_emphasis(struct analogix_dp_device *dp, u32 level
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN0_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN0_LINK_TRAINING_CTL);
 	reg &= ~PRE_EMPHASIS_SET_MASK;
 	reg |= level << PRE_EMPHASIS_SET_SHIFT;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN0_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN0_LINK_TRAINING_CTL);
 }
 
 void analogix_dp_set_lane1_pre_emphasis(struct analogix_dp_device *dp, u32 level)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN1_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN1_LINK_TRAINING_CTL);
 	reg &= ~PRE_EMPHASIS_SET_MASK;
 	reg |= level << PRE_EMPHASIS_SET_SHIFT;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN1_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN1_LINK_TRAINING_CTL);
 }
 
 void analogix_dp_set_lane2_pre_emphasis(struct analogix_dp_device *dp, u32 level)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN2_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN2_LINK_TRAINING_CTL);
 	reg &= ~PRE_EMPHASIS_SET_MASK;
 	reg |= level << PRE_EMPHASIS_SET_SHIFT;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN2_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN2_LINK_TRAINING_CTL);
 }
 
 void analogix_dp_set_lane3_pre_emphasis(struct analogix_dp_device *dp, u32 level)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN3_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN3_LINK_TRAINING_CTL);
 	reg &= ~PRE_EMPHASIS_SET_MASK;
 	reg |= level << PRE_EMPHASIS_SET_SHIFT;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN3_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN3_LINK_TRAINING_CTL);
 }
 
 void analogix_dp_set_lane0_link_training(struct analogix_dp_device *dp,
@@ -979,7 +979,7 @@ void analogix_dp_set_lane0_link_training(struct analogix_dp_device *dp,
 	u32 reg;
 
 	reg = training_lane;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN0_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN0_LINK_TRAINING_CTL);
 }
 
 void analogix_dp_set_lane1_link_training(struct analogix_dp_device *dp,
@@ -988,7 +988,7 @@ void analogix_dp_set_lane1_link_training(struct analogix_dp_device *dp,
 	u32 reg;
 
 	reg = training_lane;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN1_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN1_LINK_TRAINING_CTL);
 }
 
 void analogix_dp_set_lane2_link_training(struct analogix_dp_device *dp,
@@ -997,7 +997,7 @@ void analogix_dp_set_lane2_link_training(struct analogix_dp_device *dp,
 	u32 reg;
 
 	reg = training_lane;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN2_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN2_LINK_TRAINING_CTL);
 }
 
 void analogix_dp_set_lane3_link_training(struct analogix_dp_device *dp,
@@ -1006,14 +1006,14 @@ void analogix_dp_set_lane3_link_training(struct analogix_dp_device *dp,
 	u32 reg;
 
 	reg = training_lane;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN3_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN3_LINK_TRAINING_CTL);
 }
 
 u32 analogix_dp_get_lane0_link_training(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN0_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN0_LINK_TRAINING_CTL);
 	return reg;
 }
 
@@ -1021,7 +1021,7 @@ u32 analogix_dp_get_lane1_link_training(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN1_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN1_LINK_TRAINING_CTL);
 	return reg;
 }
 
@@ -1029,7 +1029,7 @@ u32 analogix_dp_get_lane2_link_training(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN2_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN2_LINK_TRAINING_CTL);
 	return reg;
 }
 
@@ -1037,7 +1037,7 @@ u32 analogix_dp_get_lane3_link_training(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN3_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN3_LINK_TRAINING_CTL);
 	return reg;
 }
 
@@ -1045,15 +1045,15 @@ void analogix_dp_reset_macro(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_PHY_TEST);
+	reg = readl(dp->reg_base + ANALOGIX_DP_PHY_TEST);
 	reg |= MACRO_RST;
-	writel(reg, dp->reg_base + EXYNOS_DP_PHY_TEST);
+	writel(reg, dp->reg_base + ANALOGIX_DP_PHY_TEST);
 
 	/* 10 us is the minimum reset time. */
 	usleep_range(10, 20);
 
 	reg &= ~MACRO_RST;
-	writel(reg, dp->reg_base + EXYNOS_DP_PHY_TEST);
+	writel(reg, dp->reg_base + ANALOGIX_DP_PHY_TEST);
 }
 
 void analogix_dp_init_video(struct analogix_dp_device *dp)
@@ -1061,19 +1061,19 @@ void analogix_dp_init_video(struct analogix_dp_device *dp)
 	u32 reg;
 
 	reg = VSYNC_DET | VID_FORMAT_CHG | VID_CLK_CHG;
-	writel(reg, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_1);
 
 	reg = 0x0;
-	writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_1);
 
 	reg = CHA_CRI(4) | CHA_CTRL;
-	writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_2);
 
 	reg = 0x0;
-	writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_3);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
 
 	reg = VID_HRES_TH(2) | VID_VRES_TH(0);
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_8);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_8);
 }
 
 void analogix_dp_set_video_color_format(struct analogix_dp_device *dp)
@@ -1084,36 +1084,36 @@ void analogix_dp_set_video_color_format(struct analogix_dp_device *dp)
 	reg = (dp->video_info->dynamic_range << IN_D_RANGE_SHIFT) |
 		(dp->video_info->color_depth << IN_BPC_SHIFT) |
 		(dp->video_info->color_space << IN_COLOR_F_SHIFT);
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_2);
 
 	/* Set Input Color YCbCr Coefficients to ITU601 or ITU709 */
-	reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_3);
+	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_3);
 	reg &= ~IN_YC_COEFFI_MASK;
 	if (dp->video_info->ycbcr_coeff)
 		reg |= IN_YC_COEFFI_ITU709;
 	else
 		reg |= IN_YC_COEFFI_ITU601;
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_3);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_3);
 }
 
 int analogix_dp_is_slave_video_stream_clock_on(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_1);
-	writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_1);
+	reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_1);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_1);
+	reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_1);
 
 	if (!(reg & DET_STA)) {
 		dev_dbg(dp->dev, "Input stream clock not detected.\n");
 		return -EINVAL;
 	}
 
-	reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_2);
-	writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_2);
+	reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_2);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_2);
+	reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_2);
 	dev_dbg(dp->dev, "wait SYS_CTL_2.\n");
 
 	if (reg & CHA_STA) {
@@ -1132,30 +1132,30 @@ void analogix_dp_set_video_cr_mn(struct analogix_dp_device *dp,
 	u32 reg;
 
 	if (type == REGISTER_M) {
-		reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 		reg |= FIX_M_VID;
-		writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 		reg = m_value & 0xff;
-		writel(reg, dp->reg_base + EXYNOS_DP_M_VID_0);
+		writel(reg, dp->reg_base + ANALOGIX_DP_M_VID_0);
 		reg = (m_value >> 8) & 0xff;
-		writel(reg, dp->reg_base + EXYNOS_DP_M_VID_1);
+		writel(reg, dp->reg_base + ANALOGIX_DP_M_VID_1);
 		reg = (m_value >> 16) & 0xff;
-		writel(reg, dp->reg_base + EXYNOS_DP_M_VID_2);
+		writel(reg, dp->reg_base + ANALOGIX_DP_M_VID_2);
 
 		reg = n_value & 0xff;
-		writel(reg, dp->reg_base + EXYNOS_DP_N_VID_0);
+		writel(reg, dp->reg_base + ANALOGIX_DP_N_VID_0);
 		reg = (n_value >> 8) & 0xff;
-		writel(reg, dp->reg_base + EXYNOS_DP_N_VID_1);
+		writel(reg, dp->reg_base + ANALOGIX_DP_N_VID_1);
 		reg = (n_value >> 16) & 0xff;
-		writel(reg, dp->reg_base + EXYNOS_DP_N_VID_2);
+		writel(reg, dp->reg_base + ANALOGIX_DP_N_VID_2);
 	} else  {
-		reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 		reg &= ~FIX_M_VID;
-		writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 
-		writel(0x00, dp->reg_base + EXYNOS_DP_N_VID_0);
-		writel(0x80, dp->reg_base + EXYNOS_DP_N_VID_1);
-		writel(0x00, dp->reg_base + EXYNOS_DP_N_VID_2);
+		writel(0x00, dp->reg_base + ANALOGIX_DP_N_VID_0);
+		writel(0x80, dp->reg_base + ANALOGIX_DP_N_VID_1);
+		writel(0x00, dp->reg_base + ANALOGIX_DP_N_VID_2);
 	}
 }
 
@@ -1164,13 +1164,13 @@ void analogix_dp_set_video_timing_mode(struct analogix_dp_device *dp, u32 type)
 	u32 reg;
 
 	if (type == VIDEO_TIMING_FROM_CAPTURE) {
-		reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+		reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 		reg &= ~FORMAT_SEL;
-		writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+		writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 	} else {
-		reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+		reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 		reg |= FORMAT_SEL;
-		writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+		writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 	}
 }
 
@@ -1179,15 +1179,15 @@ void analogix_dp_enable_video_master(struct analogix_dp_device *dp, bool enable)
 	u32 reg;
 
 	if (enable) {
-		reg = readl(dp->reg_base + EXYNOS_DP_SOC_GENERAL_CTL);
+		reg = readl(dp->reg_base + ANALOGIX_DP_SOC_GENERAL_CTL);
 		reg &= ~VIDEO_MODE_MASK;
 		reg |= VIDEO_MASTER_MODE_EN | VIDEO_MODE_MASTER_MODE;
-		writel(reg, dp->reg_base + EXYNOS_DP_SOC_GENERAL_CTL);
+		writel(reg, dp->reg_base + ANALOGIX_DP_SOC_GENERAL_CTL);
 	} else {
-		reg = readl(dp->reg_base + EXYNOS_DP_SOC_GENERAL_CTL);
+		reg = readl(dp->reg_base + ANALOGIX_DP_SOC_GENERAL_CTL);
 		reg &= ~VIDEO_MODE_MASK;
 		reg |= VIDEO_MODE_SLAVE_MODE;
-		writel(reg, dp->reg_base + EXYNOS_DP_SOC_GENERAL_CTL);
+		writel(reg, dp->reg_base + ANALOGIX_DP_SOC_GENERAL_CTL);
 	}
 }
 
@@ -1195,19 +1195,19 @@ void analogix_dp_start_video(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 	reg |= VIDEO_EN;
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 }
 
 int analogix_dp_is_video_stream_on(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_3);
-	writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_3);
+	reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_3);
+	reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
 	if (!(reg & STRM_VALID)) {
 		dev_dbg(dp->dev, "Input video stream is not detected.\n");
 		return -EINVAL;
@@ -1220,44 +1220,44 @@ void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_FUNC_EN_1);
+	reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
 	reg &= ~(MASTER_VID_FUNC_EN_N|SLAVE_VID_FUNC_EN_N);
 	reg |= MASTER_VID_FUNC_EN_N;
-	writel(reg, dp->reg_base + EXYNOS_DP_FUNC_EN_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 	reg &= ~INTERACE_SCAN_CFG;
 	reg |= (dp->video_info->interlaced << 2);
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 	reg &= ~VSYNC_POLARITY_CFG;
 	reg |= (dp->video_info->v_sync_polarity << 1);
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 	reg &= ~HSYNC_POLARITY_CFG;
 	reg |= (dp->video_info->h_sync_polarity << 0);
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 
 	reg = AUDIO_MODE_SPDIF_MODE | VIDEO_MODE_SLAVE_MODE;
-	writel(reg, dp->reg_base + EXYNOS_DP_SOC_GENERAL_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SOC_GENERAL_CTL);
 }
 
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+	reg = readl(dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 	reg &= ~SCRAMBLING_DISABLE;
-	writel(reg, dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+	writel(reg, dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 }
 
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+	reg = readl(dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 	reg |= SCRAMBLING_DISABLE;
-	writel(reg, dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+	writel(reg, dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 }
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index b9661c9..738db4c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -12,93 +12,93 @@
 #ifndef _ANALOGIX_DP_REG_H
 #define _ANALOGIX_DP_REG_H
 
-#define EXYNOS_DP_TX_SW_RESET			0x14
-#define EXYNOS_DP_FUNC_EN_1			0x18
-#define EXYNOS_DP_FUNC_EN_2			0x1C
-#define EXYNOS_DP_VIDEO_CTL_1			0x20
-#define EXYNOS_DP_VIDEO_CTL_2			0x24
-#define EXYNOS_DP_VIDEO_CTL_3			0x28
-
-#define EXYNOS_DP_VIDEO_CTL_8			0x3C
-#define EXYNOS_DP_VIDEO_CTL_10			0x44
-
-#define EXYNOS_DP_LANE_MAP			0x35C
-
-#define EXYNOS_DP_ANALOG_CTL_1			0x370
-#define EXYNOS_DP_ANALOG_CTL_2			0x374
-#define EXYNOS_DP_ANALOG_CTL_3			0x378
-#define EXYNOS_DP_PLL_FILTER_CTL_1		0x37C
-#define EXYNOS_DP_TX_AMP_TUNING_CTL		0x380
-
-#define EXYNOS_DP_AUX_HW_RETRY_CTL		0x390
-
-#define EXYNOS_DP_COMMON_INT_STA_1		0x3C4
-#define EXYNOS_DP_COMMON_INT_STA_2		0x3C8
-#define EXYNOS_DP_COMMON_INT_STA_3		0x3CC
-#define EXYNOS_DP_COMMON_INT_STA_4		0x3D0
-#define EXYNOS_DP_INT_STA			0x3DC
-#define EXYNOS_DP_COMMON_INT_MASK_1		0x3E0
-#define EXYNOS_DP_COMMON_INT_MASK_2		0x3E4
-#define EXYNOS_DP_COMMON_INT_MASK_3		0x3E8
-#define EXYNOS_DP_COMMON_INT_MASK_4		0x3EC
-#define EXYNOS_DP_INT_STA_MASK			0x3F8
-#define EXYNOS_DP_INT_CTL			0x3FC
-
-#define EXYNOS_DP_SYS_CTL_1			0x600
-#define EXYNOS_DP_SYS_CTL_2			0x604
-#define EXYNOS_DP_SYS_CTL_3			0x608
-#define EXYNOS_DP_SYS_CTL_4			0x60C
-
-#define EXYNOS_DP_PKT_SEND_CTL			0x640
-#define EXYNOS_DP_HDCP_CTL			0x648
-
-#define EXYNOS_DP_LINK_BW_SET			0x680
-#define EXYNOS_DP_LANE_COUNT_SET		0x684
-#define EXYNOS_DP_TRAINING_PTN_SET		0x688
-#define EXYNOS_DP_LN0_LINK_TRAINING_CTL		0x68C
-#define EXYNOS_DP_LN1_LINK_TRAINING_CTL		0x690
-#define EXYNOS_DP_LN2_LINK_TRAINING_CTL		0x694
-#define EXYNOS_DP_LN3_LINK_TRAINING_CTL		0x698
-
-#define EXYNOS_DP_DEBUG_CTL			0x6C0
-#define EXYNOS_DP_HPD_DEGLITCH_L		0x6C4
-#define EXYNOS_DP_HPD_DEGLITCH_H		0x6C8
-#define EXYNOS_DP_LINK_DEBUG_CTL		0x6E0
-
-#define EXYNOS_DP_M_VID_0			0x700
-#define EXYNOS_DP_M_VID_1			0x704
-#define EXYNOS_DP_M_VID_2			0x708
-#define EXYNOS_DP_N_VID_0			0x70C
-#define EXYNOS_DP_N_VID_1			0x710
-#define EXYNOS_DP_N_VID_2			0x714
-
-#define EXYNOS_DP_PLL_CTL			0x71C
-#define EXYNOS_DP_PHY_PD			0x720
-#define EXYNOS_DP_PHY_TEST			0x724
-
-#define EXYNOS_DP_VIDEO_FIFO_THRD		0x730
-#define EXYNOS_DP_AUDIO_MARGIN			0x73C
-
-#define EXYNOS_DP_M_VID_GEN_FILTER_TH		0x764
-#define EXYNOS_DP_M_AUD_GEN_FILTER_TH		0x778
-#define EXYNOS_DP_AUX_CH_STA			0x780
-#define EXYNOS_DP_AUX_CH_DEFER_CTL		0x788
-#define EXYNOS_DP_AUX_RX_COMM			0x78C
-#define EXYNOS_DP_BUFFER_DATA_CTL		0x790
-#define EXYNOS_DP_AUX_CH_CTL_1			0x794
-#define EXYNOS_DP_AUX_ADDR_7_0			0x798
-#define EXYNOS_DP_AUX_ADDR_15_8			0x79C
-#define EXYNOS_DP_AUX_ADDR_19_16		0x7A0
-#define EXYNOS_DP_AUX_CH_CTL_2			0x7A4
-
-#define EXYNOS_DP_BUF_DATA_0			0x7C0
-
-#define EXYNOS_DP_SOC_GENERAL_CTL		0x800
-
-/* EXYNOS_DP_TX_SW_RESET */
+#define ANALOGIX_DP_TX_SW_RESET			0x14
+#define ANALOGIX_DP_FUNC_EN_1			0x18
+#define ANALOGIX_DP_FUNC_EN_2			0x1C
+#define ANALOGIX_DP_VIDEO_CTL_1			0x20
+#define ANALOGIX_DP_VIDEO_CTL_2			0x24
+#define ANALOGIX_DP_VIDEO_CTL_3			0x28
+
+#define ANALOGIX_DP_VIDEO_CTL_8			0x3C
+#define ANALOGIX_DP_VIDEO_CTL_10		0x44
+
+#define ANALOGIX_DP_LANE_MAP			0x35C
+
+#define ANALOGIX_DP_ANALOG_CTL_1		0x370
+#define ANALOGIX_DP_ANALOG_CTL_2		0x374
+#define ANALOGIX_DP_ANALOG_CTL_3		0x378
+#define ANALOGIX_DP_PLL_FILTER_CTL_1		0x37C
+#define ANALOGIX_DP_TX_AMP_TUNING_CTL		0x380
+
+#define ANALOGIX_DP_AUX_HW_RETRY_CTL		0x390
+
+#define ANALOGIX_DP_COMMON_INT_STA_1		0x3C4
+#define ANALOGIX_DP_COMMON_INT_STA_2		0x3C8
+#define ANALOGIX_DP_COMMON_INT_STA_3		0x3CC
+#define ANALOGIX_DP_COMMON_INT_STA_4		0x3D0
+#define ANALOGIX_DP_INT_STA			0x3DC
+#define ANALOGIX_DP_COMMON_INT_MASK_1		0x3E0
+#define ANALOGIX_DP_COMMON_INT_MASK_2		0x3E4
+#define ANALOGIX_DP_COMMON_INT_MASK_3		0x3E8
+#define ANALOGIX_DP_COMMON_INT_MASK_4		0x3EC
+#define ANALOGIX_DP_INT_STA_MASK		0x3F8
+#define ANALOGIX_DP_INT_CTL			0x3FC
+
+#define ANALOGIX_DP_SYS_CTL_1			0x600
+#define ANALOGIX_DP_SYS_CTL_2			0x604
+#define ANALOGIX_DP_SYS_CTL_3			0x608
+#define ANALOGIX_DP_SYS_CTL_4			0x60C
+
+#define ANALOGIX_DP_PKT_SEND_CTL		0x640
+#define ANALOGIX_DP_HDCP_CTL			0x648
+
+#define ANALOGIX_DP_LINK_BW_SET			0x680
+#define ANALOGIX_DP_LANE_COUNT_SET		0x684
+#define ANALOGIX_DP_TRAINING_PTN_SET		0x688
+#define ANALOGIX_DP_LN0_LINK_TRAINING_CTL	0x68C
+#define ANALOGIX_DP_LN1_LINK_TRAINING_CTL	0x690
+#define ANALOGIX_DP_LN2_LINK_TRAINING_CTL	0x694
+#define ANALOGIX_DP_LN3_LINK_TRAINING_CTL	0x698
+
+#define ANALOGIX_DP_DEBUG_CTL			0x6C0
+#define ANALOGIX_DP_HPD_DEGLITCH_L		0x6C4
+#define ANALOGIX_DP_HPD_DEGLITCH_H		0x6C8
+#define ANALOGIX_DP_LINK_DEBUG_CTL		0x6E0
+
+#define ANALOGIX_DP_M_VID_0			0x700
+#define ANALOGIX_DP_M_VID_1			0x704
+#define ANALOGIX_DP_M_VID_2			0x708
+#define ANALOGIX_DP_N_VID_0			0x70C
+#define ANALOGIX_DP_N_VID_1			0x710
+#define ANALOGIX_DP_N_VID_2			0x714
+
+#define ANALOGIX_DP_PLL_CTL			0x71C
+#define ANALOGIX_DP_PHY_PD			0x720
+#define ANALOGIX_DP_PHY_TEST			0x724
+
+#define ANALOGIX_DP_VIDEO_FIFO_THRD		0x730
+#define ANALOGIX_DP_AUDIO_MARGIN		0x73C
+
+#define ANALOGIX_DP_M_VID_GEN_FILTER_TH		0x764
+#define ANALOGIX_DP_M_AUD_GEN_FILTER_TH		0x778
+#define ANALOGIX_DP_AUX_CH_STA			0x780
+#define ANALOGIX_DP_AUX_CH_DEFER_CTL		0x788
+#define ANALOGIX_DP_AUX_RX_COMM			0x78C
+#define ANALOGIX_DP_BUFFER_DATA_CTL		0x790
+#define ANALOGIX_DP_AUX_CH_CTL_1		0x794
+#define ANALOGIX_DP_AUX_ADDR_7_0		0x798
+#define ANALOGIX_DP_AUX_ADDR_15_8		0x79C
+#define ANALOGIX_DP_AUX_ADDR_19_16		0x7A0
+#define ANALOGIX_DP_AUX_CH_CTL_2		0x7A4
+
+#define ANALOGIX_DP_BUF_DATA_0			0x7C0
+
+#define ANALOGIX_DP_SOC_GENERAL_CTL		0x800
+
+/* ANALOGIX_DP_TX_SW_RESET */
 #define RESET_DP_TX				(0x1 << 0)
 
-/* EXYNOS_DP_FUNC_EN_1 */
+/* ANALOGIX_DP_FUNC_EN_1 */
 #define MASTER_VID_FUNC_EN_N			(0x1 << 7)
 #define SLAVE_VID_FUNC_EN_N			(0x1 << 5)
 #define AUD_FIFO_FUNC_EN_N			(0x1 << 4)
@@ -107,17 +107,17 @@
 #define CRC_FUNC_EN_N				(0x1 << 1)
 #define SW_FUNC_EN_N				(0x1 << 0)
 
-/* EXYNOS_DP_FUNC_EN_2 */
+/* ANALOGIX_DP_FUNC_EN_2 */
 #define SSC_FUNC_EN_N				(0x1 << 7)
 #define AUX_FUNC_EN_N				(0x1 << 2)
 #define SERDES_FIFO_FUNC_EN_N			(0x1 << 1)
 #define LS_CLK_DOMAIN_FUNC_EN_N			(0x1 << 0)
 
-/* EXYNOS_DP_VIDEO_CTL_1 */
+/* ANALOGIX_DP_VIDEO_CTL_1 */
 #define VIDEO_EN				(0x1 << 7)
 #define HDCP_VIDEO_MUTE				(0x1 << 6)
 
-/* EXYNOS_DP_VIDEO_CTL_1 */
+/* ANALOGIX_DP_VIDEO_CTL_1 */
 #define IN_D_RANGE_MASK				(0x1 << 7)
 #define IN_D_RANGE_SHIFT			(7)
 #define IN_D_RANGE_CEA				(0x1 << 7)
@@ -134,7 +134,7 @@
 #define IN_COLOR_F_YCBCR422			(0x1 << 0)
 #define IN_COLOR_F_RGB				(0x0 << 0)
 
-/* EXYNOS_DP_VIDEO_CTL_3 */
+/* ANALOGIX_DP_VIDEO_CTL_3 */
 #define IN_YC_COEFFI_MASK			(0x1 << 7)
 #define IN_YC_COEFFI_SHIFT			(7)
 #define IN_YC_COEFFI_ITU709			(0x1 << 7)
@@ -144,17 +144,17 @@
 #define VID_CHK_UPDATE_TYPE_1			(0x1 << 4)
 #define VID_CHK_UPDATE_TYPE_0			(0x0 << 4)
 
-/* EXYNOS_DP_VIDEO_CTL_8 */
+/* ANALOGIX_DP_VIDEO_CTL_8 */
 #define VID_HRES_TH(x)				(((x) & 0xf) << 4)
 #define VID_VRES_TH(x)				(((x) & 0xf) << 0)
 
-/* EXYNOS_DP_VIDEO_CTL_10 */
+/* ANALOGIX_DP_VIDEO_CTL_10 */
 #define FORMAT_SEL				(0x1 << 4)
 #define INTERACE_SCAN_CFG			(0x1 << 2)
 #define VSYNC_POLARITY_CFG			(0x1 << 1)
 #define HSYNC_POLARITY_CFG			(0x1 << 0)
 
-/* EXYNOS_DP_LANE_MAP */
+/* ANALOGIX_DP_LANE_MAP */
 #define LANE3_MAP_LOGIC_LANE_0			(0x0 << 6)
 #define LANE3_MAP_LOGIC_LANE_1			(0x1 << 6)
 #define LANE3_MAP_LOGIC_LANE_2			(0x2 << 6)
@@ -172,30 +172,30 @@
 #define LANE0_MAP_LOGIC_LANE_2			(0x2 << 0)
 #define LANE0_MAP_LOGIC_LANE_3			(0x3 << 0)
 
-/* EXYNOS_DP_ANALOG_CTL_1 */
+/* ANALOGIX_DP_ANALOG_CTL_1 */
 #define TX_TERMINAL_CTRL_50_OHM			(0x1 << 4)
 
-/* EXYNOS_DP_ANALOG_CTL_2 */
+/* ANALOGIX_DP_ANALOG_CTL_2 */
 #define SEL_24M					(0x1 << 3)
 #define TX_DVDD_BIT_1_0625V			(0x4 << 0)
 
-/* EXYNOS_DP_ANALOG_CTL_3 */
+/* ANALOGIX_DP_ANALOG_CTL_3 */
 #define DRIVE_DVDD_BIT_1_0625V			(0x4 << 5)
 #define VCO_BIT_600_MICRO			(0x5 << 0)
 
-/* EXYNOS_DP_PLL_FILTER_CTL_1 */
+/* ANALOGIX_DP_PLL_FILTER_CTL_1 */
 #define PD_RING_OSC				(0x1 << 6)
 #define AUX_TERMINAL_CTRL_50_OHM		(0x2 << 4)
 #define TX_CUR1_2X				(0x1 << 2)
 #define TX_CUR_16_MA				(0x3 << 0)
 
-/* EXYNOS_DP_TX_AMP_TUNING_CTL */
+/* ANALOGIX_DP_TX_AMP_TUNING_CTL */
 #define CH3_AMP_400_MV				(0x0 << 24)
 #define CH2_AMP_400_MV				(0x0 << 16)
 #define CH1_AMP_400_MV				(0x0 << 8)
 #define CH0_AMP_400_MV				(0x0 << 0)
 
-/* EXYNOS_DP_AUX_HW_RETRY_CTL */
+/* ANALOGIX_DP_AUX_HW_RETRY_CTL */
 #define AUX_BIT_PERIOD_EXPECTED_DELAY(x)	(((x) & 0x7) << 8)
 #define AUX_HW_RETRY_INTERVAL_MASK		(0x3 << 3)
 #define AUX_HW_RETRY_INTERVAL_600_MICROSECONDS	(0x0 << 3)
@@ -204,7 +204,7 @@
 #define AUX_HW_RETRY_INTERVAL_1800_MICROSECONDS	(0x3 << 3)
 #define AUX_HW_RETRY_COUNT_SEL(x)		(((x) & 0x7) << 0)
 
-/* EXYNOS_DP_COMMON_INT_STA_1 */
+/* ANALOGIX_DP_COMMON_INT_STA_1 */
 #define VSYNC_DET				(0x1 << 7)
 #define PLL_LOCK_CHG				(0x1 << 6)
 #define SPDIF_ERR				(0x1 << 5)
@@ -214,19 +214,19 @@
 #define VID_CLK_CHG				(0x1 << 1)
 #define SW_INT					(0x1 << 0)
 
-/* EXYNOS_DP_COMMON_INT_STA_2 */
+/* ANALOGIX_DP_COMMON_INT_STA_2 */
 #define ENC_EN_CHG				(0x1 << 6)
 #define HW_BKSV_RDY				(0x1 << 3)
 #define HW_SHA_DONE				(0x1 << 2)
 #define HW_AUTH_STATE_CHG			(0x1 << 1)
 #define HW_AUTH_DONE				(0x1 << 0)
 
-/* EXYNOS_DP_COMMON_INT_STA_3 */
+/* ANALOGIX_DP_COMMON_INT_STA_3 */
 #define AFIFO_UNDER				(0x1 << 7)
 #define AFIFO_OVER				(0x1 << 6)
 #define R0_CHK_FLAG				(0x1 << 5)
 
-/* EXYNOS_DP_COMMON_INT_STA_4 */
+/* ANALOGIX_DP_COMMON_INT_STA_4 */
 #define PSR_ACTIVE				(0x1 << 7)
 #define PSR_INACTIVE				(0x1 << 6)
 #define SPDIF_BI_PHASE_ERR			(0x1 << 5)
@@ -234,29 +234,29 @@
 #define HPD_LOST				(0x1 << 1)
 #define PLUG					(0x1 << 0)
 
-/* EXYNOS_DP_INT_STA */
+/* ANALOGIX_DP_INT_STA */
 #define INT_HPD					(0x1 << 6)
 #define HW_TRAINING_FINISH			(0x1 << 5)
 #define RPLY_RECEIV				(0x1 << 1)
 #define AUX_ERR					(0x1 << 0)
 
-/* EXYNOS_DP_INT_CTL */
+/* ANALOGIX_DP_INT_CTL */
 #define SOFT_INT_CTRL				(0x1 << 2)
 #define INT_POL1				(0x1 << 1)
 #define INT_POL0				(0x1 << 0)
 
-/* EXYNOS_DP_SYS_CTL_1 */
+/* ANALOGIX_DP_SYS_CTL_1 */
 #define DET_STA					(0x1 << 2)
 #define FORCE_DET				(0x1 << 1)
 #define DET_CTRL				(0x1 << 0)
 
-/* EXYNOS_DP_SYS_CTL_2 */
+/* ANALOGIX_DP_SYS_CTL_2 */
 #define CHA_CRI(x)				(((x) & 0xf) << 4)
 #define CHA_STA					(0x1 << 2)
 #define FORCE_CHA				(0x1 << 1)
 #define CHA_CTRL				(0x1 << 0)
 
-/* EXYNOS_DP_SYS_CTL_3 */
+/* ANALOGIX_DP_SYS_CTL_3 */
 #define HPD_STATUS				(0x1 << 6)
 #define F_HPD					(0x1 << 5)
 #define HPD_CTRL				(0x1 << 4)
@@ -265,13 +265,13 @@
 #define F_VALID					(0x1 << 1)
 #define VALID_CTRL				(0x1 << 0)
 
-/* EXYNOS_DP_SYS_CTL_4 */
+/* ANALOGIX_DP_SYS_CTL_4 */
 #define FIX_M_AUD				(0x1 << 4)
 #define ENHANCED				(0x1 << 3)
 #define FIX_M_VID				(0x1 << 2)
 #define M_VID_UPDATE_CTRL			(0x3 << 0)
 
-/* EXYNOS_DP_TRAINING_PTN_SET */
+/* ANALOGIX_DP_TRAINING_PTN_SET */
 #define SCRAMBLER_TYPE				(0x1 << 9)
 #define HW_LINK_TRAINING_PATTERN		(0x1 << 8)
 #define SCRAMBLING_DISABLE			(0x1 << 5)
@@ -285,24 +285,24 @@
 #define SW_TRAINING_PATTERN_SET_PTN1		(0x1 << 0)
 #define SW_TRAINING_PATTERN_SET_NORMAL		(0x0 << 0)
 
-/* EXYNOS_DP_LN0_LINK_TRAINING_CTL */
+/* ANALOGIX_DP_LN0_LINK_TRAINING_CTL */
 #define PRE_EMPHASIS_SET_MASK			(0x3 << 3)
 #define PRE_EMPHASIS_SET_SHIFT			(3)
 
-/* EXYNOS_DP_DEBUG_CTL */
+/* ANALOGIX_DP_DEBUG_CTL */
 #define PLL_LOCK				(0x1 << 4)
 #define F_PLL_LOCK				(0x1 << 3)
 #define PLL_LOCK_CTRL				(0x1 << 2)
 #define PN_INV					(0x1 << 0)
 
-/* EXYNOS_DP_PLL_CTL */
+/* ANALOGIX_DP_PLL_CTL */
 #define DP_PLL_PD				(0x1 << 7)
 #define DP_PLL_RESET				(0x1 << 6)
 #define DP_PLL_LOOP_BIT_DEFAULT			(0x1 << 4)
 #define DP_PLL_REF_BIT_1_1250V			(0x5 << 0)
 #define DP_PLL_REF_BIT_1_2500V			(0x7 << 0)
 
-/* EXYNOS_DP_PHY_PD */
+/* ANALOGIX_DP_PHY_PD */
 #define DP_PHY_PD				(0x1 << 5)
 #define AUX_PD					(0x1 << 4)
 #define CH3_PD					(0x1 << 3)
@@ -310,28 +310,28 @@
 #define CH1_PD					(0x1 << 1)
 #define CH0_PD					(0x1 << 0)
 
-/* EXYNOS_DP_PHY_TEST */
+/* ANALOGIX_DP_PHY_TEST */
 #define MACRO_RST				(0x1 << 5)
 #define CH1_TEST				(0x1 << 1)
 #define CH0_TEST				(0x1 << 0)
 
-/* EXYNOS_DP_AUX_CH_STA */
+/* ANALOGIX_DP_AUX_CH_STA */
 #define AUX_BUSY				(0x1 << 4)
 #define AUX_STATUS_MASK				(0xf << 0)
 
-/* EXYNOS_DP_AUX_CH_DEFER_CTL */
+/* ANALOGIX_DP_AUX_CH_DEFER_CTL */
 #define DEFER_CTRL_EN				(0x1 << 7)
 #define DEFER_COUNT(x)				(((x) & 0x7f) << 0)
 
-/* EXYNOS_DP_AUX_RX_COMM */
+/* ANALOGIX_DP_AUX_RX_COMM */
 #define AUX_RX_COMM_I2C_DEFER			(0x2 << 2)
 #define AUX_RX_COMM_AUX_DEFER			(0x2 << 0)
 
-/* EXYNOS_DP_BUFFER_DATA_CTL */
+/* ANALOGIX_DP_BUFFER_DATA_CTL */
 #define BUF_CLR					(0x1 << 7)
 #define BUF_DATA_COUNT(x)			(((x) & 0x1f) << 0)
 
-/* EXYNOS_DP_AUX_CH_CTL_1 */
+/* ANALOGIX_DP_AUX_CH_CTL_1 */
 #define AUX_LENGTH(x)				(((x - 1) & 0xf) << 4)
 #define AUX_TX_COMM_MASK			(0xf << 0)
 #define AUX_TX_COMM_DP_TRANSACTION		(0x1 << 3)
@@ -340,20 +340,20 @@
 #define AUX_TX_COMM_WRITE			(0x0 << 0)
 #define AUX_TX_COMM_READ			(0x1 << 0)
 
-/* EXYNOS_DP_AUX_ADDR_7_0 */
+/* ANALOGIX_DP_AUX_ADDR_7_0 */
 #define AUX_ADDR_7_0(x)				(((x) >> 0) & 0xff)
 
-/* EXYNOS_DP_AUX_ADDR_15_8 */
+/* ANALOGIX_DP_AUX_ADDR_15_8 */
 #define AUX_ADDR_15_8(x)			(((x) >> 8) & 0xff)
 
-/* EXYNOS_DP_AUX_ADDR_19_16 */
+/* ANALOGIX_DP_AUX_ADDR_19_16 */
 #define AUX_ADDR_19_16(x)			(((x) >> 16) & 0x0f)
 
-/* EXYNOS_DP_AUX_CH_CTL_2 */
+/* ANALOGIX_DP_AUX_CH_CTL_2 */
 #define ADDR_ONLY				(0x1 << 1)
 #define AUX_EN					(0x1 << 0)
 
-/* EXYNOS_DP_SOC_GENERAL_CTL */
+/* ANALOGIX_DP_SOC_GENERAL_CTL */
 #define AUDIO_MODE_SPDIF_MODE			(0x1 << 8)
 #define AUDIO_MODE_MASTER_MODE			(0x0 << 8)
 #define MASTER_VIDEO_INTERLACE_EN		(0x1 << 4)
-- 
1.9.1




From djkurtz at chromium.org  Sun Feb 14 19:28:42 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Mon, 15 Feb 2016 11:28:42 +0800
Subject: [PATCH v6] clk: mediatek: Export CPU mux clocks for CPU frequency
 control
In-Reply-To: <20151217090628.GA317@quark.deferred.io>
References: <1442230072-31593-1-git-send-email-pi-cheng.chen@linaro.org>
 <CAGS+omCkYTPyjMk6QaoxGAL4QVU8VcpWyFqWhST+iP2EFRcRYg@mail.gmail.com>
 <CALx668XVnhhLJWs7RBxvaX=SU=S9=wFVT9HMDP2edqiH4Jio4A@mail.gmail.com>
 <20151217090628.GA317@quark.deferred.io>
Message-ID: <CAGS+omCV-90OsBk1c1Xj9_20yC5CmPNtMb+K9R7=mOiTg3sAJw@mail.gmail.com>

Hi Mike, Pi-Cheng,

On Thu, Dec 17, 2015 at 5:06 PM, Michael Turquette
<mturquette at baylibre.com> wrote:
> On 12/01, Pi-Cheng Chen wrote:
>> On Mon, Nov 30, 2015 at 11:48 AM, Daniel Kurtz <djkurtz at chromium.org> wrote:
>> > Hi Pi-Cheng and Michael,
>> >
>> > On Mon, Sep 14, 2015 at 7:27 PM, Pi-Cheng Chen <pi-cheng.chen at linaro.org> wrote:
>> >> From: "pi-cheng.chen" <pi-cheng.chen at linaro.org>
>> >>
>> >> This patch adds CPU mux clocks which are used by Mediatek cpufreq driver
>> >> for intermediate clock source switching.
>> >
>> > It looks like this patch was never picked up.
>> > It is required for MT8173 cpufreq.
>> >
>> > What is the plan to get this one merged?
>>
>> Hi Dan,
>> Mike is working on a new CCF feature called "coordinated clock rate changes"
>> which would help to migrate mt8173-cpufreq driver to generic cpufreq-dt
>> driver, and I am working with him to port MT8173 clock driver on the new
>> feature. So I think that's why this patch was not picked since it will
>> be migrated to new implementation once the new feature's ready.
>>
>> @Mike:
>> Are you plannig to post those patches on the mailing list ?
>> Or is it fine for you to take this first and then I will refine it for
>> the new feature later?
>
> I plan to post those patches next week.

Were these patches ever posted?
I'm not really sure what patch set I am looking for.

Thanks,
-Dan


From wxt at rock-chips.com  Sun Feb 14 19:30:58 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Mon, 15 Feb 2016 11:30:58 +0800
Subject: [PATCH] arm64: dts: rockchip: fix the incorrect otp-out pin on rk3368
Message-ID: <1455507058-10824-1-git-send-email-wxt@rock-chips.com>

This patch fixes the incorrect Over-temperature protection pin.
since the rk3368 io list said the otp pin is gpio0a3.

Anyway, that should be fixed in here.

Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

 arch/arm64/boot/dts/rockchip/rk3368.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index 49d1191..3949163 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -926,11 +926,11 @@
 
 		tsadc {
 			otp_gpio: otp-gpio {
-				rockchip,pins = <0 10 RK_FUNC_GPIO &pcfg_pull_none>;
+				rockchip,pins = <0 3 RK_FUNC_GPIO &pcfg_pull_none>;
 			};
 
 			otp_out: otp-out {
-				rockchip,pins = <0 10 RK_FUNC_1 &pcfg_pull_none>;
+				rockchip,pins = <0 3 RK_FUNC_1 &pcfg_pull_none>;
 			};
 		};
 
-- 
1.9.1



From tchalamarla at caviumnetworks.com  Sun Feb 14 19:36:18 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Sun, 14 Feb 2016 19:36:18 -0800
Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <20160214170152.GC3965@htj.duckdns.org>
References: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160214170152.GC3965@htj.duckdns.org>
Message-ID: <56C147B2.9010303@caviumnetworks.com>



On 02/14/2016 09:01 AM, Tejun Heo wrote:
> Hello,
>
> On Fri, Feb 12, 2016 at 03:20:30PM -0800, tchalamarla at caviumnetworks.com wrote:
>> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
>> index 546a369..76e310e 100644
>> --- a/drivers/ata/ahci.c
>> +++ b/drivers/ata/ahci.c
>> @@ -1560,6 +1560,9 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>>   	if (ahci_broken_devslp(pdev))
>>   		hpriv->flags |= AHCI_HFLAG_NO_DEVSLP;
>>
>> +	if (pdev->vendor == 0x177d && pdev->device == 0xa01c)
>> +		ahci_thunderx_init(&pdev->dev, hpriv);
>
> So, this would make ahci fail to build if thunderx is not configured.
> Maybe we should add an additional callback to update hpriv.
>
>>   	/* save initial config */
>>   	ahci_pci_save_initial_config(pdev, hpriv);
>>
>> diff --git a/drivers/ata/ahci_thunderx.c b/drivers/ata/ahci_thunderx.c
>
> This driver isn't upstream yet, right?  Maybe just fold this change
> together?
>
There is no need for special Driver, AHCI is sufficient for ThunderX, 
the file only contains this interrupt handler,
is it preferable if this interrupt handler in libahci.c with others, 
instead of separate file?

Thanks,
Tirumalesh.

> Thanks.
>


From caesar.upstream at gmail.com  Sun Feb 14 19:36:36 2016
From: caesar.upstream at gmail.com (Caesar Wang)
Date: Mon, 15 Feb 2016 11:36:36 +0800
Subject: [PATCH v4 09/10] arm64: dts: Add main Thermal info to rk3368.dtsi
In-Reply-To: <42802946.20XC68fnyM@phil>
References: <1447044542-30859-1-git-send-email-wxt@rock-chips.com>
 <1447044542-30859-10-git-send-email-wxt@rock-chips.com>
 <42802946.20XC68fnyM@phil>
Message-ID: <56C147C4.20704@gmail.com>



? 2016?02?09? 16:30, Heiko Stuebner ??:
> Hi Caesar,
>
> Am Montag, 9. November 2015, 12:49:01 schrieb Caesar Wang:
>> This patch add the thermal needed info on RK3368.
>> Meanwhile, support the trips to throttle for thermal.
>>
>> Signed-off-by: Caesar Wang <wxt at rock-chips.com>
>> Acked-by: Eduardo Valentin <edubezval at gmail.com>
> [...]
>
>> @@ -829,6 +855,16 @@
>>   			};
>>   		};
>>
>> +		tsadc {
>> +			otp_gpio: otp-gpio {
>> +				rockchip,pins = <0 10 RK_FUNC_GPIO &pcfg_pull_none>;
>> +			};
>> +
>> +			otp_out: otp-out {
>> +				rockchip,pins = <0 10 RK_FUNC_1 &pcfg_pull_none>;
>> +			};
>> +		};
>> +
>>   		uart0 {
>>   			uart0_xfer: uart0-xfer {
>>   				rockchip,pins = <2 24 RK_FUNC_1 &pcfg_pull_up>,
> As it came up just now, these pinctrl settings seem strange. I.e. according
> to the TRM gpio0b2 [= gpio0 10] func_1 is sc_rst, which seems to be the
> smartcard controller?
>
> It came up because it seems the Tronsmart R68 board seems to use this pin
> for controlling the vcc_host regulator instead.

Yep, that's the incorrect over-temperature protection pin. :-(

Fixed in https://patchwork.kernel.org/patch/8308831/

Thanks Heiko.

>
> Heiko
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip


-- 
Thanks,
Caesar



From wenyou.yang at atmel.com  Sun Feb 14 19:40:26 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Mon, 15 Feb 2016 11:40:26 +0800
Subject: [PATCH v3 0/4] ARM: at91: pm: add ULP1 mode support
Message-ID: <1455507630-29592-1-git-send-email-wenyou.yang@atmel.com>

The ULP1 (Ultra Low-power mode 1) is introduced by SAMA5D2.

In order to achieve the lowest power consumption, in the ULP1 mode,
all the clocks are shut off, inclusive the embedded 12MHz RC oscillator.

The fast startup signal is used as a wake up source for ULP1 mode.
As soon as the wake up event is asserted, the embedded 12MHz RC
oscillator restarts automatically, which fast startup signal
to trigger the PMC to wake up the system from the ULP1 mode can be
configured via DT.

It is based on the following patch set:
	http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390954.html

Changes in v3:
 - use 0 and 1, not string, to define the trigger active polarity.
 - update the property description.

Changes in v2:
 - fix label pm_exit to ulp_exit.
 - shorten the pmc-fast-startup property's name.
 - use the value property, instead of bool property for high
   or low triggered.
 - change the property name and property description.

Wenyou Yang (4):
  ARM: at91: pm: create a separate procedure for the ULP0 mode
  ARM: at91: pm: add ULP1 mode support
  ARM: at91: pm: configure PMC fast startup signals
  Documentation: atmel-pmc: add DT bindings for fast startup

 .../devicetree/bindings/arm/atmel-pmc.txt          |   63 ++++++++
 arch/arm/mach-at91/pm.c                            |  130 +++++++++++++++-
 arch/arm/mach-at91/pm.h                            |    7 +
 arch/arm/mach-at91/pm_suspend.S                    |  158 +++++++++++++++++---
 include/linux/clk/at91_pmc.h                       |   36 +++++
 5 files changed, 369 insertions(+), 25 deletions(-)

-- 
1.7.9.5



From wenyou.yang at atmel.com  Sun Feb 14 19:40:27 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Mon, 15 Feb 2016 11:40:27 +0800
Subject: [PATCH v3 1/4] ARM: at91: pm: create a separate procedure for the
 ULP0 mode
In-Reply-To: <1455507630-29592-1-git-send-email-wenyou.yang@atmel.com>
References: <1455507630-29592-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1455507630-29592-2-git-send-email-wenyou.yang@atmel.com>

To make the code more legible and prepare to add the ULP1 mode
support in the future, create a separate procedure for the ULP0 mode.

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---

Changes in v3: None
Changes in v2: None

 arch/arm/mach-at91/pm_suspend.S |   65 ++++++++++++++++++++++++---------------
 1 file changed, 40 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index a25defd..5fcffdc 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -107,7 +107,7 @@ ENTRY(at91_pm_suspend_in_sram)
 
 	ldr	r0, .pm_mode
 	tst	r0, #AT91_PM_SLOW_CLOCK
-	beq	skip_disable_main_clock
+	beq	standby_mode
 
 	ldr	pmc, .pmc_base
 
@@ -131,32 +131,13 @@ ENTRY(at91_pm_suspend_in_sram)
 	orr	tmp1, tmp1, #(1 << 29)		/* bit 29 always set */
 	str	tmp1, [pmc, #AT91_CKGR_PLLAR]
 
-	/* Turn off the main oscillator */
-	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
-	bic	tmp1, tmp1, #AT91_PMC_MOSCEN
-	orr	tmp1, tmp1, #AT91_PMC_KEY
-	str	tmp1, [pmc, #AT91_CKGR_MOR]
-
-skip_disable_main_clock:
-	ldr	pmc, .pmc_base
-
-	/* Wait for interrupt */
-	at91_cpu_idle
-
-	ldr	r0, .pm_mode
-	tst	r0, #AT91_PM_SLOW_CLOCK
-	beq	skip_enable_main_clock
+ulp0_mode:
+	bl	at91_pm_ulp0_mode
+	b	ulp_exit
 
+ulp_exit:
 	ldr	pmc, .pmc_base
 
-	/* Turn on the main oscillator */
-	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
-	orr	tmp1, tmp1, #AT91_PMC_MOSCEN
-	orr	tmp1, tmp1, #AT91_PMC_KEY
-	str	tmp1, [pmc, #AT91_CKGR_MOR]
-
-	wait_moscrdy
-
 	/* Restore PLLA setting */
 	ldr	tmp1, .saved_pllar
 	str	tmp1, [pmc, #AT91_CKGR_PLLAR]
@@ -177,7 +158,15 @@ skip_disable_main_clock:
 
 	wait_mckrdy
 
-skip_enable_main_clock:
+	b	pm_exit
+
+standby_mode:
+	ldr	pmc, .pmc_base
+
+	/* Wait for interrupt */
+	at91_cpu_idle
+
+pm_exit:
 	/* Exit the self-refresh mode */
 	mov	r0, #SRAMC_SELF_FRESH_EXIT
 	bl	at91_sramc_self_refresh
@@ -311,6 +300,32 @@ exit_sramc_sf:
 	mov	pc, lr
 ENDPROC(at91_sramc_self_refresh)
 
+/*
+ * void at91_pm_ulp0_mode(void)
+ */
+ENTRY(at91_pm_ulp0_mode)
+	ldr	pmc, .pmc_base
+
+	/* Turn off the crystal oscillator */
+	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
+	bic	tmp1, tmp1, #AT91_PMC_MOSCEN
+	orr	tmp1, tmp1, #AT91_PMC_KEY
+	str	tmp1, [pmc, #AT91_CKGR_MOR]
+
+	/* Wait for interrupt */
+	at91_cpu_idle
+
+	/* Turn on the crystal oscillator */
+	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
+	orr	tmp1, tmp1, #AT91_PMC_MOSCEN
+	orr	tmp1, tmp1, #AT91_PMC_KEY
+	str	tmp1, [pmc, #AT91_CKGR_MOR]
+
+	wait_moscrdy
+
+	mov	pc, lr
+ENDPROC(at91_pm_ulp0_mode)
+
 .pmc_base:
 	.word 0
 .sramc_base:
-- 
1.7.9.5



From wenyou.yang at atmel.com  Sun Feb 14 19:40:28 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Mon, 15 Feb 2016 11:40:28 +0800
Subject: [PATCH v3 2/4] ARM: at91: pm: add ULP1 mode support
In-Reply-To: <1455507630-29592-1-git-send-email-wenyou.yang@atmel.com>
References: <1455507630-29592-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1455507630-29592-3-git-send-email-wenyou.yang@atmel.com>

The ULP1 (Ultra Low-power mode 1) is introduced by SAMA5D2.

In the ULP1 mode, all the clocks are shut off, inclusive the embedded
12MHz RC oscillator, so as to achieve the lowest power consumption
with the system in retention mode and able to resume on the wake up
events. As soon as the wake up event is asserted, the embedded 12MHz
RC oscillator restarts automatically.

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---

Changes in v3: None
Changes in v2:
 - fix label pm_exit to ulp_exit.

 arch/arm/mach-at91/pm.c         |   16 ++++++-
 arch/arm/mach-at91/pm.h         |    7 +++
 arch/arm/mach-at91/pm_suspend.S |   97 +++++++++++++++++++++++++++++++++++++++
 include/linux/clk/at91_pmc.h    |    4 ++
 4 files changed, 122 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index f82df15..a7aec35 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -36,6 +36,11 @@
 #include "generic.h"
 #include "pm.h"
 
+#define ULP0_MODE	0x00
+#define ULP1_MODE	0x11
+
+#define SAMA5D2_PMC_VERSION	0x20540
+
 void __iomem *pmc;
 
 /*
@@ -52,6 +57,7 @@ extern void at91_pinctrl_gpio_resume(void);
 static struct {
 	unsigned long uhp_udp_mask;
 	int memctrl;
+	u32 ulp_mode;
 } at91_pm_data;
 
 void __iomem *at91_ramc_base[2];
@@ -141,8 +147,11 @@ static void at91_pm_suspend(suspend_state_t state)
 {
 	unsigned int pm_data = at91_pm_data.memctrl;
 
-	pm_data |= (state == PM_SUSPEND_MEM) ?
-				AT91_PM_MODE(AT91_PM_SLOW_CLOCK) : 0;
+	if (state == PM_SUSPEND_MEM) {
+		pm_data |= AT91_PM_MODE(AT91_PM_SLOW_CLOCK);
+		if (at91_pm_data.ulp_mode == ULP1_MODE)
+			pm_data |= AT91_PM_ULP(AT91_PM_ULP1_MODE);
+	}
 
 	flush_cache_all();
 	outer_disable();
@@ -497,4 +506,7 @@ void __init sama5_pm_init(void)
 	at91_pm_data.uhp_udp_mask = AT91SAM926x_PMC_UHP | AT91SAM926x_PMC_UDP;
 	at91_pm_data.memctrl = AT91_MEMCTRL_DDRSDR;
 	at91_pm_init(NULL);
+
+	if (readl(pmc + AT91_PMC_VERSION) >= SAMA5D2_PMC_VERSION)
+		at91_pm_data.ulp_mode = ULP1_MODE;
 }
diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h
index 3fcf881..2e76745 100644
--- a/arch/arm/mach-at91/pm.h
+++ b/arch/arm/mach-at91/pm.h
@@ -39,4 +39,11 @@ extern void __iomem *at91_ramc_base[];
 
 #define	AT91_PM_SLOW_CLOCK	0x01
 
+#define AT91_PM_ULP_OFFSET	5
+#define AT91_PM_ULP_MASK	0x03
+#define AT91_PM_ULP(x)		(((x) & AT91_PM_ULP_MASK) << AT91_PM_ULP_OFFSET)
+
+#define AT91_PM_ULP0_MODE	0x00
+#define AT91_PM_ULP1_MODE	0x01
+
 #endif
diff --git a/arch/arm/mach-at91/pm_suspend.S b/arch/arm/mach-at91/pm_suspend.S
index 5fcffdc..f2a5c4b 100644
--- a/arch/arm/mach-at91/pm_suspend.S
+++ b/arch/arm/mach-at91/pm_suspend.S
@@ -41,6 +41,15 @@ tmp2	.req	r5
 	.endm
 
 /*
+ * Wait for main oscillator selection is done
+ */
+	.macro wait_moscsels
+1:	ldr	tmp1, [pmc, #AT91_PMC_SR]
+	tst	tmp1, #AT91_PMC_MOSCSELS
+	beq	1b
+	.endm
+
+/*
  * Wait until PLLA has locked.
  */
 	.macro wait_pllalock
@@ -101,6 +110,10 @@ ENTRY(at91_pm_suspend_in_sram)
 	and	r0, r0, #AT91_PM_MODE_MASK
 	str	r0, .pm_mode
 
+	lsr	r0, r3, #AT91_PM_ULP_OFFSET
+	and	r0, r0, #AT91_PM_ULP_MASK
+	str	r0, .ulp_mode
+
 	/* Active the self-refresh mode */
 	mov	r0, #SRAMC_SELF_FRESH_ACTIVE
 	bl	at91_sramc_self_refresh
@@ -131,6 +144,13 @@ ENTRY(at91_pm_suspend_in_sram)
 	orr	tmp1, tmp1, #(1 << 29)		/* bit 29 always set */
 	str	tmp1, [pmc, #AT91_CKGR_PLLAR]
 
+	ldr	r0, .ulp_mode
+	tst	r0, #AT91_PM_ULP1_MODE
+	beq	ulp0_mode
+
+	bl	at91_pm_ulp1_mode
+	b	ulp_exit
+
 ulp0_mode:
 	bl	at91_pm_ulp0_mode
 	b	ulp_exit
@@ -326,6 +346,81 @@ ENTRY(at91_pm_ulp0_mode)
 	mov	pc, lr
 ENDPROC(at91_pm_ulp0_mode)
 
+/*
+ * void at91_pm_ulp1_mode(void)
+ */
+ENTRY(at91_pm_ulp1_mode)
+	ldr	pmc, .pmc_base
+
+	/* Switch the main clock source to 12-MHz RC oscillator */
+	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
+	bic	tmp1, tmp1, #AT91_PMC_MOSCSEL
+	bic	tmp1, tmp1, #AT91_PMC_KEY_MASK
+	orr	tmp1, tmp1, #AT91_PMC_KEY
+	str	tmp1, [pmc, #AT91_CKGR_MOR]
+
+	wait_moscsels
+
+	/* Disable the crystal oscillator */
+	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
+	bic	tmp1, tmp1, #AT91_PMC_MOSCEN
+	bic	tmp1, tmp1, #AT91_PMC_KEY_MASK
+	orr	tmp1, tmp1, #AT91_PMC_KEY
+	str	tmp1, [pmc, #AT91_CKGR_MOR]
+
+	/* Switch the master clock source to main clock */
+	ldr	tmp1, [pmc, #AT91_PMC_MCKR]
+	bic	tmp1, tmp1, #AT91_PMC_CSS
+	orr	tmp1, tmp1, #AT91_PMC_CSS_MAIN
+	str	tmp1, [pmc, #AT91_PMC_MCKR]
+
+	wait_mckrdy
+
+	/* Enter the ULP1 mode by set WAITMODE bit in CKGR_MOR */
+	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
+	orr	tmp1, tmp1, #AT91_PMC_WAITMODE
+	bic	tmp1, tmp1, #AT91_PMC_KEY_MASK
+	orr	tmp1, tmp1, #AT91_PMC_KEY
+	str	tmp1, [pmc, #AT91_CKGR_MOR]
+
+	wait_mckrdy
+
+	/* Enable the crystal oscillator */
+	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
+	orr	tmp1, tmp1, #AT91_PMC_MOSCEN
+	bic	tmp1, tmp1, #AT91_PMC_KEY_MASK
+	orr	tmp1, tmp1, #AT91_PMC_KEY
+	str	tmp1, [pmc, #AT91_CKGR_MOR]
+
+	wait_moscrdy
+
+	/* Switch the master clock source to slow clock */
+	ldr	tmp1, [pmc, #AT91_PMC_MCKR]
+	bic	tmp1, tmp1, #AT91_PMC_CSS
+	str	tmp1, [pmc, #AT91_PMC_MCKR]
+
+	wait_mckrdy
+
+	/* Switch main clock source to crystal oscillator */
+	ldr	tmp1, [pmc, #AT91_CKGR_MOR]
+	orr	tmp1, tmp1, #AT91_PMC_MOSCSEL
+	bic	tmp1, tmp1, #AT91_PMC_KEY_MASK
+	orr	tmp1, tmp1, #AT91_PMC_KEY
+	str	tmp1, [pmc, #AT91_CKGR_MOR]
+
+	wait_moscsels
+
+	/* Switch the master clock source to main clock */
+	ldr	tmp1, [pmc, #AT91_PMC_MCKR]
+	bic	tmp1, tmp1, #AT91_PMC_CSS
+	orr	tmp1, tmp1, #AT91_PMC_CSS_MAIN
+	str	tmp1, [pmc, #AT91_PMC_MCKR]
+
+	wait_mckrdy
+
+	mov	pc, lr
+ENDPROC(at91_pm_ulp1_mode)
+
 .pmc_base:
 	.word 0
 .sramc_base:
@@ -336,6 +431,8 @@ ENDPROC(at91_pm_ulp0_mode)
 	.word 0
 .pm_mode:
 	.word 0
+.ulp_mode:
+	.word 0
 .saved_mckr:
 	.word 0
 .saved_pllar:
diff --git a/include/linux/clk/at91_pmc.h b/include/linux/clk/at91_pmc.h
index 17f413b..4afd891 100644
--- a/include/linux/clk/at91_pmc.h
+++ b/include/linux/clk/at91_pmc.h
@@ -47,8 +47,10 @@
 #define	AT91_CKGR_MOR		0x20			/* Main Oscillator Register [not on SAM9RL] */
 #define		AT91_PMC_MOSCEN		(1    <<  0)		/* Main Oscillator Enable */
 #define		AT91_PMC_OSCBYPASS	(1    <<  1)		/* Oscillator Bypass */
+#define		AT91_PMC_WAITMODE	(1    <<  2)		/* Wait Mode Command */
 #define		AT91_PMC_MOSCRCEN	(1    <<  3)		/* Main On-Chip RC Oscillator Enable [some SAM9] */
 #define		AT91_PMC_OSCOUNT	(0xff <<  8)		/* Main Oscillator Start-up Time */
+#define		AT91_PMC_KEY_MASK	(0xff << 16)
 #define		AT91_PMC_KEY		(0x37 << 16)		/* MOR Writing Key */
 #define		AT91_PMC_MOSCSEL	(1    << 24)		/* Main Oscillator Selection [some SAM9] */
 #define		AT91_PMC_CFDEN		(1    << 25)		/* Clock Failure Detector Enable [some SAM9] */
@@ -166,6 +168,8 @@
 #define		AT91_PMC_WPVS		(0x1  <<  0)		/* Write Protect Violation Status */
 #define		AT91_PMC_WPVSRC		(0xffff  <<  8)		/* Write Protect Violation Source */
 
+#define AT91_PMC_VERSION	0xfc
+
 #define AT91_PMC_PCER1		0x100			/* Peripheral Clock Enable Register 1 [SAMA5 only]*/
 #define AT91_PMC_PCDR1		0x104			/* Peripheral Clock Enable Register 1 */
 #define AT91_PMC_PCSR1		0x108			/* Peripheral Clock Enable Register 1 */
-- 
1.7.9.5



From wenyou.yang at atmel.com  Sun Feb 14 19:40:29 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Mon, 15 Feb 2016 11:40:29 +0800
Subject: [PATCH v3 3/4] ARM: at91: pm: configure PMC fast startup signals
In-Reply-To: <1455507630-29592-1-git-send-email-wenyou.yang@atmel.com>
References: <1455507630-29592-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1455507630-29592-4-git-send-email-wenyou.yang@atmel.com>

The fast startup signal is used as wake up sources for ULP1 mode.
As soon as a fast startup signal is asserted, the embedded 12 MHz
RC oscillator restarts automatically.

This patch is to configure the fast startup signals, which signal
is enabled to trigger the PMC to wake up the system from ULP1 mode
should be configured via the DT.

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---

Changes in v3:
 - use 0 and 1, not string, to define the trigger active polarity.

Changes in v2:
 - shorten the pmc-fast-startup property's name.
 - use the value property, instead of bool property for high
   or low triggered.

 arch/arm/mach-at91/pm.c      |  114 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/clk/at91_pmc.h |   32 ++++++++++++
 2 files changed, 146 insertions(+)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index a7aec35..9a7de07 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -24,6 +24,8 @@
 #include <linux/platform_device.h>
 #include <linux/io.h>
 #include <linux/clk/at91_pmc.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
 
 #include <asm/irq.h>
 #include <linux/atomic.h>
@@ -425,6 +427,116 @@ static void __init at91_pm_sram_init(void)
 			&at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
 }
 
+static int __init at91_pmc_fast_startup_init(void)
+{
+	struct device_node *np;
+	struct regmap *regmap;
+	u32 mode = 0, polarity = 0, value = 0;
+
+	np = of_find_compatible_node(NULL, NULL,
+				     "atmel,sama5d2-pmc-fast-startup");
+	if (!np)
+		return -ENODEV;
+
+	regmap = syscon_node_to_regmap(of_get_parent(np));
+	if (IS_ERR(regmap)) {
+		pr_info("AT91: failed to find PMC fast startup\n");
+		return PTR_ERR(regmap);
+	}
+
+	mode |= of_property_read_bool(np, "atmel,wkup-trigger") ?
+		AT91_PMC_FSTT0 : 0;
+	mode |= of_property_read_bool(np, "atmel,secumod-trigger") ?
+		AT91_PMC_FSTT1 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu0-trigger") ?
+		AT91_PMC_FSTT2 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu1-trigger") ?
+		AT91_PMC_FSTT3 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu2-trigger") ?
+		AT91_PMC_FSTT4 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu3-trigger") ?
+		AT91_PMC_FSTT5 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu4-trigger") ?
+		AT91_PMC_FSTT6 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu5-trigger") ?
+		AT91_PMC_FSTT7 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu6-trigger") ?
+		AT91_PMC_FSTT8 : 0;
+	mode |= of_property_read_bool(np, "atmel,piobu7-trigger") ?
+		AT91_PMC_FSTT9 : 0;
+	mode |= of_property_read_bool(np, "atmel,gmac-wol-trigger") ?
+		AT91_PMC_FSTT10 : 0;
+	mode |= of_property_read_bool(np, "atmel,rtc-alarm-trigger") ?
+		AT91_PMC_RTCAL : 0;
+	mode |= of_property_read_bool(np, "atmel,usb-resume-trigger") ?
+		AT91_PMC_USBAL : 0;
+	mode |= of_property_read_bool(np, "atmel,sdmmc-cd-trigger") ?
+		AT91_PMC_SDMMC_CD : 0;
+	mode |= of_property_read_bool(np, "atmel,rxlp-match-trigger") ?
+		AT91_PMC_RXLP_MCE : 0;
+	mode |= of_property_read_bool(np, "atmel,acc-comparison-trigger") ?
+		AT91_PMC_ACC_CE : 0;
+
+	if (!of_property_read_u32(np, "atmel,wkup-trigger-level", &value)) {
+		if (value)
+			polarity |= AT91_PMC_FSTP0;
+	}
+
+	if (mode & AT91_PMC_FSTT1)
+		polarity |= AT91_PMC_FSTP1;
+
+	if (!of_property_read_u32(np, "atmel,piobu0-trigger-level", &value)) {
+		if (value)
+			polarity |= AT91_PMC_FSTP2;
+	}
+
+	if (!of_property_read_u32(np, "atmel,piobu1-trigger-level", &value)) {
+		if (value)
+			polarity |= AT91_PMC_FSTP3;
+	}
+
+	if (!of_property_read_u32(np, "atmel,piobu2-trigger-level", &value)) {
+		if (value)
+			polarity |= AT91_PMC_FSTP4;
+	}
+
+	if (!of_property_read_u32(np, "atmel,piobu3-trigger-level", &value)) {
+		if (value)
+			polarity |= AT91_PMC_FSTP5;
+	}
+
+	if (!of_property_read_u32(np, "atmel,piobu4-trigger-level", &value)) {
+		if (value)
+			polarity |= AT91_PMC_FSTP6;
+	}
+
+	if (!of_property_read_u32(np, "atmel,piobu5-trigger-level", &value)) {
+		if (value)
+			polarity |= AT91_PMC_FSTP7;
+	}
+
+	if (!of_property_read_u32(np, "atmel,piobu6-trigger-level", &value)) {
+		if (value)
+			polarity |= AT91_PMC_FSTP8;
+	}
+
+	if (!of_property_read_u32(np, "atmel,piobu7-trigger-level", &value)) {
+		if (value)
+			polarity |= AT91_PMC_FSTP9;
+	}
+
+	if (mode & AT91_PMC_FSTT10)
+		polarity |= AT91_PMC_FSTP10;
+
+	regmap_write(regmap, AT91_PMC_FSMR, mode);
+
+	regmap_write(regmap, AT91_PMC_FSPR, polarity);
+
+	of_node_put(np);
+
+	return 0;
+}
+
 static const struct of_device_id atmel_pmc_ids[] = {
 	{ .compatible = "atmel,at91rm9200-pmc"  },
 	{ .compatible = "atmel,at91sam9260-pmc" },
@@ -509,4 +621,6 @@ void __init sama5_pm_init(void)
 
 	if (readl(pmc + AT91_PMC_VERSION) >= SAMA5D2_PMC_VERSION)
 		at91_pm_data.ulp_mode = ULP1_MODE;
+
+	at91_pmc_fast_startup_init();
 }
diff --git a/include/linux/clk/at91_pmc.h b/include/linux/clk/at91_pmc.h
index 4afd891..683580e 100644
--- a/include/linux/clk/at91_pmc.h
+++ b/include/linux/clk/at91_pmc.h
@@ -168,6 +168,38 @@
 #define		AT91_PMC_WPVS		(0x1  <<  0)		/* Write Protect Violation Status */
 #define		AT91_PMC_WPVSRC		(0xffff  <<  8)		/* Write Protect Violation Source */
 
+#define AT91_PMC_FSMR		0x70		/* Fast Startup Mode Register */
+#define AT91_PMC_FSTT0		BIT(0)		/* WKUP Pin Enable */
+#define AT91_PMC_FSTT1		BIT(1)		/* Security Module Enable */
+#define AT91_PMC_FSTT2		BIT(2)		/* PIOBU0 Input Enable */
+#define AT91_PMC_FSTT3		BIT(3)		/* PIOBU1 Input Enable */
+#define AT91_PMC_FSTT4		BIT(4)		/* PIOBU2 Input Enable */
+#define AT91_PMC_FSTT5		BIT(5)		/* PIOBU3 Input Enable */
+#define AT91_PMC_FSTT6		BIT(6)		/* PIOBU4 Input Enable */
+#define AT91_PMC_FSTT7		BIT(7)		/* PIOBU5 Input Enable */
+#define AT91_PMC_FSTT8		BIT(8)		/* PIOBU6 Input Enable */
+#define AT91_PMC_FSTT9		BIT(9)		/* PIOBU7 Input Enable */
+#define AT91_PMC_FSTT10		BIT(10)		/* GMAC Wake-up On LAN Enable */
+#define AT91_PMC_RTCAL		BIT(17)		/* RTC Alarm Enable */
+#define AT91_PMC_USBAL		BIT(18)		/* USB Resume Enable */
+#define AT91_PMC_SDMMC_CD	BIT(19)		/* SDMMC Card Detect Enable */
+#define AT91_PMC_LPM		BIT(20)		/* Low-power Mode */
+#define AT91_PMC_RXLP_MCE	BIT(24)		/* Backup UART Receive Enable */
+#define AT91_PMC_ACC_CE		BIT(25)		/* ACC Enable */
+
+#define AT91_PMC_FSPR		0x74		/* Fast Startup Polarity Reg */
+#define AT91_PMC_FSTP0		BIT(0)		/* WKUP Pin Polarity */
+#define AT91_PMC_FSTP1		BIT(1)		/* Security Module Polarity */
+#define AT91_PMC_FSTP2		BIT(2)		/* PIOBU0 Pin Polarity */
+#define AT91_PMC_FSTP3		BIT(3)		/* PIOBU1 Pin Polarity */
+#define AT91_PMC_FSTP4		BIT(4)		/* PIOBU2 Pin Polarity */
+#define AT91_PMC_FSTP5		BIT(5)		/* PIOBU3 Pin Polarity */
+#define AT91_PMC_FSTP6		BIT(6)		/* PIOBU4 Pin Polarity */
+#define AT91_PMC_FSTP7		BIT(7)		/* PIOBU5 Pin Polarity */
+#define AT91_PMC_FSTP8		BIT(8)		/* PIOBU6 Pin Polarity */
+#define AT91_PMC_FSTP9		BIT(9)		/* PIOBU7 Pin Polarity */
+#define AT91_PMC_FSTP10		BIT(10)		/* Wake-up On LAN Polarity */
+
 #define AT91_PMC_VERSION	0xfc
 
 #define AT91_PMC_PCER1		0x100			/* Peripheral Clock Enable Register 1 [SAMA5 only]*/
-- 
1.7.9.5



From wenyou.yang at atmel.com  Sun Feb 14 19:40:30 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Mon, 15 Feb 2016 11:40:30 +0800
Subject: [PATCH v3 4/4] Documentation: atmel-pmc: add DT bindings for fast
 startup
In-Reply-To: <1455507630-29592-1-git-send-email-wenyou.yang@atmel.com>
References: <1455507630-29592-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1455507630-29592-5-git-send-email-wenyou.yang@atmel.com>

Add DT bindings to configurate the PMC_FSMR and PMC_FSPR registers
to trigger a fast restart signal to PMC.

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
Document: binding

---

Changes in v3:
 - update the property description.

Changes in v2:
 - change the property name and property description.

 .../devicetree/bindings/arm/atmel-pmc.txt          |   63 ++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/atmel-pmc.txt b/Documentation/devicetree/bindings/arm/atmel-pmc.txt
index 795cc78..0d2481c 100644
--- a/Documentation/devicetree/bindings/arm/atmel-pmc.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-pmc.txt
@@ -12,3 +12,66 @@ Examples:
 		compatible = "atmel,at91rm9200-pmc";
 		reg = <0xfffffc00 0x100>;
 	};
+
+PMC Fast Startup Signals
+
+The PMC Fast Start Signals are used as the wake up source to trigger the PMC
+to wake up the system from the ULP1 mode.
+
+required properties:
+- compatible: Should be "atmel,sama5d2-pmc-fast-startup".
+
+optional properties:
+- atmel,wkup-trigger: boolean, WKUP input can trigger a fast restart signal.
+- atmel,secumod-trigger: boolean, SECUMOD can trigger a fast restart signal.
+- atmel,piobu0-trigger: boolean, PIOBU0 input can trigger a fast restart signal.
+- atmel,piobu1-trigger: boolean, PIOBU1 input can trigger a fast restart signal.
+- atmel,piobu2-trigger: boolean, PIOBU2 input can trigger a fast restart signal.
+- atmel,piobu3-trigger: boolean, PIOBU3 input can trigger a fast restart signal.
+- atmel,piobu4-trigger: boolean, PIOBU4 input can trigger a fast restart signal.
+- atmel,piobu5-trigger: boolean, PIOBU5 input can trigger a fast restart signal.
+- atmel,piobu6-trigger: boolean, PIOBU6 input can trigger a fast restart signal.
+- atmel,piobu7-trigger: boolean, PIOBU7 input can trigger a fast restart signal.
+- atmel,gmac-wol-trigger: boolean, GMAC_WOL can trigger a fast restart signal.
+- atmel,rtc-alarm-trigger: boolean, RTC alarm can trigger a fast restart signal.
+- atmel,usb-resume-trigger: boolean, USB resume can trigger a fast restart
+  signal.
+- atmel,sdmmc-cd-trigger: boolean, SDMMC card detect can trigger a fast
+  restart signal.
+- atmel,rxlp-match-trigger: boolean, Matching condition on RXLP can trigger
+  a fast restart signal.
+- atmel,acc-comparison-trigger: boolean, ACC comparison can trigger a fast
+  restart signal.
+
+- atmel,wkup-trigger-level: int, defines the active polarity of the wake-up
+  input. Supported values are: 1 or 0.
+- atmel,piobu0-trigger-level: int, defines the active polarity of
+  the corresponding PIOBU0 input. Supported values are: 1 or 0.
+- atmel,piobu1-trigger-level: int, defines the active polarity of
+  the corresponding PIOBU1 input. Supported values are: 1 or 0.
+- atmel,piobu2-trigger-level: int, defines the active polarity of
+  the corresponding PIOBU2 input. Supported values are: 1 or 0".
+- atmel,piobu3-trigger-level: int, defines the active polarity of
+  the corresponding PIOBU3 input. Supported values are: 1 or 0.
+- atmel,piobu4-trigger-level: int, defines the active polarity of
+  the corresponding PIOBU4 input. Supported values are: 1 or 0.
+- atmel,piobu5-trigger-level: int, defines the active polarity of
+  the corresponding PIOBU5 input. Supported values are: 1 or 0.
+- atmel,piobu6-trigger-level: int, defines the active polarity of
+  the corresponding PIOBU6 input. Supported values are: 1 or 0.
+- atmel,piobu7-trigger-level: int, defines the active polarity of
+  the corresponding PIOBU7 input. Supported values are: 1 or 0.
+
+Example:
+
+	pmc: pmc at f0014000 {
+		compatible = "atmel,sama5d2-pmc";
+		reg = <0xf0014000 0x160>;
+
+		pmc_fast_restart {
+			compatible = "atmel,sama5d2-pmc-fast-startup";
+			atmel,wkup-trigger;
+			atmel,rtc-alarm-trigger;
+			atmel,wkup-trigger-level = <0>;
+		};
+	};
-- 
1.7.9.5



From eddie.huang at mediatek.com  Sun Feb 14 19:52:08 2016
From: eddie.huang at mediatek.com (Eddie Huang)
Date: Mon, 15 Feb 2016 11:52:08 +0800
Subject: mt1873-evb: MMC failing with linux-next
In-Reply-To: <7hegcmadfk.fsf@baylibre.com>
References: <7hegcmadfk.fsf@baylibre.com>
Message-ID: <1455508328.29366.14.camel@mtksdaap41>

Hi Kevin,

On Mon, 2016-02-08 at 17:18 -0800, Kevin Hilman wrote:
> Hello,
> 
> I tried getting MMC working with linux-next (next-20160208) on
> mt8173-evb by enabling a few options[1] on top of the default defconfig,
> and this results in a kernel that hangs as soon as it starts userspace.
> 
> The MMC driver seems to start, though has some regulator issues:
> 
> [    0.526380] sdhci: Secure Digital Host Controller Interface driver
> [    0.527176] sdhci: Copyright(c) Pierre Ossman
> [    0.528835] vio18: unsupportable voltage range: 3300000-1980000uV
> [    0.529610] mtk-msdc 11230000.mmc: Regulator set error -22:    3300000 - 3300000
> [    0.563731] mtk-msdc 11240000.mmc: Got CD GPIO
>     
> The driver appears to be attempting to set 3.3V but using a 1.8V
> regulator (vio18), which is failing.

This message shows set 3.3V to vio18 fail. Then MMC core will set 1.8V
to vio18 again, this time should be ok.

> 
> Then, the kernel hangs after freeing unused memory:
> 
> [    0.616386] hctosys: unable to open rtc device (rtc0)
> [    0.624118] usb_vbus: disabling
> [    0.624547] vusb: disabling
> [    0.624929] vgp6: disabling
> [    0.625635] ALSA device list:
> [    0.626009]   No soundcards found.
> [    0.626963] Freeing unused kernel memory: 724K (ffffffc000977000 - ffffffc000a2c000)
> 
> And nothing further here.
> 
> It boots fine when disabling the MMC driver (CONFIG_MMC_MTK=n).
> 
> Any ideas?

MT8173-evb use MT8173 engineer sample, which has one bug that if disable
USB power domain, vcore (include mmc) power will be disabled too. MT8173
mass production chip already fix this bug. Sascha send one patch to fix
this issue [1] before. But I think it is not a good solution because if
mmc runtime suspend, vcore power will be disabled too. Please apply
following code and try again, I will send this fixup to public later.

By the way, you should set MMC_BLOCK_MINORS=32 because partition number
on eMMC is larger than default value 8.

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8173-evb.d
index e427f04..7453a47 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -214,6 +214,9 @@
 };

 &pwrap {
+       /* Only MT8173 E1 needs USB power domain */
+       power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+
        pmic: mt6397 {
                compatible = "mediatek,mt6397";
                interrupt-parent = <&pio>;


[1]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358065.html




From a0393675 at ti.com  Sun Feb 14 20:27:15 2016
From: a0393675 at ti.com (Keerthy)
Date: Mon, 15 Feb 2016 09:57:15 +0530
Subject: [PATCH] arm: dts: AM57XX: Correct the thermal thresholds
In-Reply-To: <20160212224129.GP19432@atomide.com>
References: <1454924705-8382-1-git-send-email-j-keerthy@ti.com>
 <20160209220901.GC28102@localhost.localdomain> <56BA6530.4030102@ti.com>
 <20160212222347.GO19432@atomide.com>
 <CAGo_u6r8-LJBWWrew0fV50Q+JnCxDj9PD57+9NoDm5TqCWL=jw@mail.gmail.com>
 <20160212224129.GP19432@atomide.com>
Message-ID: <56C153A3.3030508@ti.com>



On Saturday 13 February 2016 04:11 AM, Tony Lindgren wrote:
> * Nishanth Menon <nm at ti.com> [160212 14:32]:
>> On Fri, Feb 12, 2016 at 4:23 PM, Tony Lindgren <tony at atomide.com> wrote:
>>> * Nishanth Menon <nm at ti.com> [160209 14:17]:
>>>> On 02/09/2016 04:09 PM, Eduardo Valentin wrote:
>>>>> On Mon, Feb 08, 2016 at 03:15:05PM +0530, Keerthy wrote:
>>>>>> The thermal threholds for am57xx are different from that of dra7.
>>>>>> Correcting the thresholds for the same.
>>>>>>
>>>>>> Signed-off-by: Keerthy <j-keerthy at ti.com>
>>>>>> ---
>>>>>>
>>>>>> Depends on: https://lkml.org/lkml/2016/2/8/90
>>>>>>
>>>>>>   arch/arm/boot/dts/am57xx-beagle-x15.dts | 24 ++++++++++++++++++++++++
>>>>>>   1 file changed, 24 insertions(+)
>>>>>>
>>>>>> Index: linux/arch/arm/boot/dts/am57xx-beagle-x15.dts
>>>>>> ===================================================================
>>>>>> --- linux.orig/arch/arm/boot/dts/am57xx-beagle-x15.dts     2016-02-08 14:57:05.514959101 +0530
>>>>>> +++ linux/arch/arm/boot/dts/am57xx-beagle-x15.dts  2016-02-08 14:57:05.510959168 +0530
>>>>>
>>>>> Sorry, did not bother to check, but is this the only user of am57xx?
>>>>
>>>> we will have AM57xx-IDK as well coming down the line. we already have
>>>> arch/arm/boot/dts/am57xx-cl-som-am57x.dts
>>>> arch/arm/boot/dts/am57xx-sbc-am57x.dts - not really sure what grade of
>>>> silicon are used in cl-SOM and sbc boards.
>>>
>>> Hmm can this one wait for v4.6 or is it critical for v4.5-rc
>>> cycle?
>>
>> personally, I'd like to NAK this patch -> lack of reference
>> documentation, and guidance for various AM57xx boards in a generic
>> patch should probably be followed IMHO.
>
> OK let's wait for that then.

OK. I will send a v2 with better documentation.

>
> Regards,
>
> Tony
>


From maitysanchayan at gmail.com  Sun Feb 14 20:42:15 2016
From: maitysanchayan at gmail.com (maitysanchayan at gmail.com)
Date: Mon, 15 Feb 2016 10:12:15 +0530
Subject: [PATCH v2] ARM: dts: vfxxx: Add iio_hwmon node for ADC
 temperature channel
In-Reply-To: <20160214083349.GR6756@tiger>
References: <cd32f1664a04b38b8a025414d039bd015cb9a5ff.1455278754.git.maitysanchayan@gmail.com>
 <20160214083349.GR6756@tiger>
Message-ID: <20160215044214.GA5545@Sanchayan-Arch.toradex.int>

Hello Shawn,

On 16-02-14 16:33:49, Shawn Guo wrote:
> On Fri, Feb 12, 2016 at 05:53:00PM +0530, Sanchayan Maity wrote:
> > Add iio_hwmon node to expose the temperature channel on Vybrid as
> > hardware monitor device using the iio_hwmon driver.
> > 
> > Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
> > ---
> > 
> > Hello,
> > 
> > The first version of the patch was send quite a while ago.
> > https://lkml.org/lkml/2015/9/16/932
> > 
> > Shawn you had requested that hyphen rather than underscore should
> > be used in node name. I looked into that.
> > 
> > The iio_hwmon driver calls hwmon_device register_with_groups inside
> > hwmon.c and this
> > http://lxr.free-electrons.com/source/drivers/hwmon/hwmon.c#L103
> > 
> > does not allow hyphen in hwmon name attribute. I was not aware of
> > this but while trying to test the change, the device probe failed
> > with EINVAL. I think we should stick to the existing use of the
> > bindings or we need to change the hwmon code as well along with the
> > existing device tree files and binding documentation.
> 
> I disagree.
> 
> If hyphen is invalid to be part of hwmon name attribute, the following
> code in iio_hwmon_probe() is plain wrong, because hyphen is very valid
> to be part of node names in device tree.
> 
>         if (dev->of_node && dev->of_node->name)
>                 name = dev->of_node->name;

@Shawn
I agree with what you state here, however as you can see the hwmon_device_
register_with_groups does check for hypen with strpbrk and returns EINVAL.
Changing to hyphen instead of currently present underscore in iio_hwmon
node name causes probe failure.

If the node name needs to have hyphen, then the check for hyphen as an invalid
character in hwmon name attribute needs to be changed. I am CC'ing the hwmon
subsystem maintainers Jean Delvare ands Guenter Roeck as well as hwmon list to
check.

@Jean & Guenter
Can you please comment if the change to hwmon_device_register_with_groups
to accept hyphen as a valid character in hwmon name attribute will be acceptable?
Sorry if this is sudden andfor bringing you late into the discussion Jean and
Guenter.

Thanks & Regards,
Sanchayan.

> 
> Shawn
> 
> > 
> > Changes since v1:
> > 1. Expose ADC1 temperature channel as well
> > 2. Move the entry outside of the aips1 bus node
> > 
> > Best Regards,
> > Sanchayan Maity.
> > ---
> >  arch/arm/boot/dts/vfxxx.dtsi | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index a5f07e3..8ed8e47 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -673,5 +673,10 @@
> >  				status = "disabled";
> >  			};
> >  		};
> > +
> > +		iio_hwmon {
> > +			compatible = "iio-hwmon";
> > +			io-channels = <&adc0 16>, <&adc1 16>;
> > +		};
> >  	};
> >  };
> > -- 
> > 2.7.1
> > 
> > 


From kuninori.morimoto.gx at renesas.com  Sun Feb 14 20:50:17 2016
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Mon, 15 Feb 2016 04:50:17 +0000
Subject: [PATCH] ARM: dts: porter: fix JP3 jumper description
In-Reply-To: <1655804.y4T36KvG5v@wasted.cogentembedded.com>
References: <1674850.BZpGW9kEud@wasted.cogentembedded.com>
 <1655804.y4T36KvG5v@wasted.cogentembedded.com>
Message-ID: <87fuwuinsh.wl%kuninori.morimoto.gx@renesas.com>


Hi

> When finishing the Porter sound support patch, I managed to call the JP3
> jumper SW3 in the comment.  Fix this  along with (also miscalled) jumper
> positions...
> 
> Fixes: 493b4da7c10c ("ARM: dts: porter: add sound support")
> Reported-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

> 
> ---
> This patch is against the 'renesas-devel-20160209-v4.5-rc3' tag of Simon
> Horman's 'renesas.git' repo.
> 
> arch/arm/boot/dts/r8a7791-porter.dts |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
> ===================================================================
> --- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
> +++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
> @@ -11,8 +11,8 @@
>  /*
>   * SSI-AK4642
>   *
> - * SW3: 1: AK4642
> - *      3: ADV7511
> + * JP3: 2-1: AK4642
> + *      2-3: ADV7511
>   *
>   * This command is required before playback/capture:
>   *
> 


From kuninori.morimoto.gx at renesas.com  Sun Feb 14 20:56:03 2016
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Mon, 15 Feb 2016 04:56:03 +0000
Subject: [PATCH] ARM: dts: silk: add sound support
In-Reply-To: <4246644.0ZLx3MiCIL@wasted.cogentembedded.com>
References: <1674850.BZpGW9kEud@wasted.cogentembedded.com>
 <4246644.0ZLx3MiCIL@wasted.cogentembedded.com>
Message-ID: <87egceiniu.wl%kuninori.morimoto.gx@renesas.com>

Hi

> Define the SILK board dependent part of the R8A7794 sound  device node.
> Add device node for Asahi Kasei AK4643 stereo codec to the I2C1 bus.
> Add the "simple-audio-card" device node to interconnect the SoC sound
> device  and the codec.
> 
> This patch is based on the commit 493b4da7c10c ("ARM: dts: porter: add
> sound support").
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> ---
> This patch is against the 'renesas-devel-20160209-v4.5-rc3' tag of Simon
> Horman's 'renesas.git' repo. It depends on the 5 R8A7794 sound support patches
> in posted earlier this week  in order to build and the R8A7794 PFC driver
> patches posted yesterday in  order  for  the pins to be properly configured
> (but works without the pins  configured  too)...

Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

This patch doesn't use SRC, and it is no problem.
We need fixup src.c driver for r8a7794 because it lacks some SRCs.


>  arch/arm/boot/dts/r8a7794-silk.dts |   71 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 71 insertions(+)
> 
> Index: renesas/arch/arm/boot/dts/r8a7794-silk.dts
> ===================================================================
> --- renesas.orig/arch/arm/boot/dts/r8a7794-silk.dts
> +++ renesas/arch/arm/boot/dts/r8a7794-silk.dts
> @@ -10,6 +10,17 @@
>   * kind, whether express or implied.
>   */
>  
> +/*
> + * SSI-AK4643
> + *
> + * SW1: 2-1: AK4643
> + *      2-3: ADV7511
> + *
> + * This command is required before playback/capture:
> + *
> + *	amixer set "LINEOUT Mixer DACL" on
> + */
> +
>  /dts-v1/;
>  #include "r8a7794.dtsi"
>  #include <dt-bindings/gpio/gpio.h>
> @@ -119,6 +130,30 @@
>  		#clock-cells = <0>;
>  		clock-frequency = <74250000>;
>  	};
> +
> +	x9_clk: x9-clock {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <12288000>;
> +		clock-output-names = "audio_clock";
> +	};
> +
> +	sound {
> +		compatible = "simple-audio-card";
> +
> +		simple-audio-card,format = "left_j";
> +		simple-audio-card,bitclock-master = <&soundcodec>;
> +		simple-audio-card,frame-master = <&soundcodec>;
> +
> +		simple-audio-card,cpu {
> +			sound-dai = <&rcar_sound>;
> +		};
> +
> +		soundcodec: simple-audio-card,codec {
> +			sound-dai = <&ak4643>;
> +			clocks = <&x9_clk>;
> +		};
> +	};
>  };
>  
>  &extal_clk {
> @@ -183,6 +218,16 @@
>  		renesas,groups = "usb1";
>  		renesas,function = "usb1";
>  	};
> +
> +	ssi_pins: sound {
> +		renesas,groups = "ssi0129_ctrl", "ssi0_data", "ssi1_data";
> +		renesas,function = "ssi";
> +	};
> +
> +	audio_clk_pins: audio_clk {
> +		renesas,groups = "audio_clkc";
> +		renesas,function = "audio_clk";
> +	};
>  };
>  
>  &scif2 {
> @@ -220,6 +265,12 @@
>  	status = "okay";
>  	clock-frequency = <400000>;
>  
> +	ak4643: codec at 12 {
> +		compatible = "asahi-kasei,ak4643";
> +		#sound-dai-cells = <0>;
> +		reg = <0x12>;
> +	};
> +
>  	composite-in at 20 {
>  		compatible = "adi,adv7180";
>  		reg = <0x20>;
> @@ -380,3 +431,23 @@
>  		};
>  	};
>  };
> +
> +&rcar_sound {
> +	pinctrl-0 = <&ssi_pins &audio_clk_pins>;
> +	pinctrl-names = "default";
> +	status = "okay";
> +
> +	/* Single DAI */
> +	#sound-dai-cells = <0>;
> +
> +	rcar_sound,dai {
> +		dai0 {
> +			playback = <&ssi0>;
> +			capture  = <&ssi1>;
> +		};
> +	};
> +};
> +
> +&ssi1 {
> +	shared-pin;
> +};
> 


From qnguyen at apm.com  Sun Feb 14 20:57:40 2016
From: qnguyen at apm.com (Quan Nguyen)
Date: Mon, 15 Feb 2016 11:57:40 +0700
Subject: [PATCH v6 0/3] Enable X-Gene standby GPIO as interrupt controller
Message-ID: <1455512263-18183-1-git-send-email-qnguyen@apm.com>

V6 Changes:
        - Remove redundant irq_ack and irq_shutdown entries
V5 Changes:
        - Add optional properties to describe HW specifics
        - Use irq_create_fwspec_mapping() instead of low level functions
        - Move gpiochip_lock_as_irq() to activate method
        - Remove redundant checks
        - Add optional HW properties description to DT binding document
        - Update "interrupts" property description in DT binding document.
V4 Changes:
        - Convert to hierarchical irq domain
V3 Changes:
        - Picking up from version 2 of "Y Vo <yvo at apm.com>"
        - Get HW resource information from DT
        - Avoid keeping parent IRQ controller
V2 Changes:
        - Support X-Gene standby GPIO as an interrupt controller.

Quan Nguyen (3):
  gpio: xgene: Enable X-Gene standby GPIO as interrupt controller
  Documentation: gpio: Update description for X-Gene standby GPIO
    controller DTS binding
  arm64: dts: Update X-Gene standby GPIO controller DTS entries

 .../devicetree/bindings/gpio/gpio-xgene-sb.txt     |  47 +++-
 arch/arm64/boot/dts/apm/apm-storm.dtsi             |   3 +
 drivers/gpio/gpio-xgene-sb.c                       | 265 ++++++++++++++++++---
 3 files changed, 276 insertions(+), 39 deletions(-)

-- 
1.7.12.4



From qnguyen at apm.com  Sun Feb 14 20:57:41 2016
From: qnguyen at apm.com (Quan Nguyen)
Date: Mon, 15 Feb 2016 11:57:41 +0700
Subject: [PATCH v6 1/3] gpio: xgene: Enable X-Gene standby GPIO as interrupt
 controller
In-Reply-To: <1455512263-18183-1-git-send-email-qnguyen@apm.com>
References: <1455512263-18183-1-git-send-email-qnguyen@apm.com>
Message-ID: <1455512263-18183-2-git-send-email-qnguyen@apm.com>

Enable X-Gene standby GPIO controller as interrupt controller to provide
its own resources. This avoids ambiguity where GIC interrupt resource is
use as X-Gene standby GPIO interrupt resource in user driver.

Signed-off-by: Y Vo <yvo at apm.com>
Signed-off-by: Quan Nguyen <qnguyen at apm.com>
---
 drivers/gpio/gpio-xgene-sb.c | 265 +++++++++++++++++++++++++++++++++++++------
 1 file changed, 233 insertions(+), 32 deletions(-)

diff --git a/drivers/gpio/gpio-xgene-sb.c b/drivers/gpio/gpio-xgene-sb.c
index 282004d..b993b86 100644
--- a/drivers/gpio/gpio-xgene-sb.c
+++ b/drivers/gpio/gpio-xgene-sb.c
@@ -2,8 +2,9 @@
  * AppliedMicro X-Gene SoC GPIO-Standby Driver
  *
  * Copyright (c) 2014, Applied Micro Circuits Corporation
- * Author: 	Tin Huynh <tnhuynh at apm.com>.
- * 		Y Vo <yvo at apm.com>.
+ * Author:	Tin Huynh <tnhuynh at apm.com>.
+ *		Y Vo <yvo at apm.com>.
+ *		Quan Nguyen <qnguyen at apm.com>.
  *
  * This program is free software; you can redistribute  it and/or modify it
  * under  the terms of  the GNU General  Public License as published by the
@@ -28,9 +29,14 @@
 
 #include "gpiolib.h"
 
-#define XGENE_MAX_GPIO_DS		22
-#define XGENE_MAX_GPIO_DS_IRQ		6
+/* Common property names */
+#define XGENE_NIRQ_PROPERTY		"apm,nr-irqs"
+#define XGENE_NGPIO_PROPERTY		"apm,nr-gpios"
+#define XGENE_IRQ_START_PROPERTY	"apm,irq-start"
 
+#define XGENE_DFLT_MAX_NGPIO		22
+#define XGENE_DFLT_MAX_NIRQ		6
+#define XGENE_DFLT_IRQ_START_PIN	8
 #define GPIO_MASK(x)			(1U << ((x) % 32))
 
 #define MPA_GPIO_INT_LVL		0x0290
@@ -39,19 +45,32 @@
 #define MPA_GPIO_IN_ADDR 		0x02a4
 #define MPA_GPIO_SEL_LO 		0x0294
 
+#define GPIO_INT_LEVEL_H	0x000001
+#define GPIO_INT_LEVEL_L	0x000000
+
 /**
  * struct xgene_gpio_sb - GPIO-Standby private data structure.
  * @gc:				memory-mapped GPIO controllers.
- * @irq:			Mapping GPIO pins and interrupt number
- * nirq:			Number of GPIO pins that supports interrupt
+ * @regs:			GPIO register base offset
+ * @irq_domain:			GPIO interrupt domain
+ * @irq_start:			GPIO pin that start support interrupt
+ * @nirq:			Number of GPIO pins that supports interrupt
+ * @parent_irq_base:		Start parent HWIRQ
  */
 struct xgene_gpio_sb {
 	struct gpio_chip	gc;
-	u32 *irq;
-	u32 nirq;
+	void __iomem		*regs;
+	struct irq_domain	*irq_domain;
+	u16			irq_start;
+	u16			nirq;
+	u16			parent_irq_base;
 };
 
-static void xgene_gpio_set_bit(struct gpio_chip *gc, void __iomem *reg, u32 gpio, int val)
+#define HWIRQ_TO_GPIO(priv, hwirq) ((hwirq) + (priv)->irq_start)
+#define GPIO_TO_HWIRQ(priv, gpio) ((gpio) - (priv)->irq_start)
+
+static void xgene_gpio_set_bit(struct gpio_chip *gc,
+				void __iomem *reg, u32 gpio, int val)
 {
 	u32 data;
 
@@ -63,23 +82,170 @@ static void xgene_gpio_set_bit(struct gpio_chip *gc, void __iomem *reg, u32 gpio
 	gc->write_reg(reg, data);
 }
 
-static int apm_gpio_sb_to_irq(struct gpio_chip *gc, u32 gpio)
+static int xgene_gpio_sb_irq_set_type(struct irq_data *d, unsigned int type)
+{
+	struct xgene_gpio_sb *priv = irq_data_get_irq_chip_data(d);
+	int gpio = HWIRQ_TO_GPIO(priv, d->hwirq);
+	int lvl_type = GPIO_INT_LEVEL_H;
+
+	switch (type & IRQ_TYPE_SENSE_MASK) {
+	case IRQ_TYPE_EDGE_RISING:
+	case IRQ_TYPE_LEVEL_HIGH:
+		lvl_type = GPIO_INT_LEVEL_H;
+		break;
+	case IRQ_TYPE_EDGE_FALLING:
+	case IRQ_TYPE_LEVEL_LOW:
+		lvl_type = GPIO_INT_LEVEL_L;
+		break;
+	default:
+		break;
+	}
+
+	xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_SEL_LO,
+			gpio * 2, 1);
+	xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_INT_LVL,
+			d->hwirq, lvl_type);
+
+	/* Propagate IRQ type setting to parent */
+	if (type & IRQ_TYPE_EDGE_BOTH)
+		return irq_chip_set_type_parent(d, IRQ_TYPE_EDGE_RISING);
+	else
+		return irq_chip_set_type_parent(d, IRQ_TYPE_LEVEL_HIGH);
+}
+
+static struct irq_chip xgene_gpio_sb_irq_chip = {
+	.name           = "sbgpio",
+	.irq_eoi	= irq_chip_eoi_parent,
+	.irq_mask       = irq_chip_mask_parent,
+	.irq_unmask     = irq_chip_unmask_parent,
+	.irq_set_type   = xgene_gpio_sb_irq_set_type,
+};
+
+static int xgene_gpio_sb_to_irq(struct gpio_chip *gc, u32 gpio)
 {
 	struct xgene_gpio_sb *priv = gpiochip_get_data(gc);
+	struct irq_fwspec fwspec;
+
+	if ((gpio < priv->irq_start) ||
+			(gpio > HWIRQ_TO_GPIO(priv, priv->nirq)))
+		return -ENXIO;
+
+	if (gc->parent->of_node)
+		fwspec.fwnode = of_node_to_fwnode(gc->parent->of_node);
+	else
+		fwspec.fwnode = gc->parent->fwnode;
+	fwspec.param_count = 2;
+	fwspec.param[0] = GPIO_TO_HWIRQ(priv, gpio);
+	fwspec.param[1] = IRQ_TYPE_NONE;
+	return irq_create_fwspec_mapping(&fwspec);
+}
+
+static void xgene_gpio_sb_domain_activate(struct irq_domain *d,
+		struct irq_data *irq_data)
+{
+	struct xgene_gpio_sb *priv = d->host_data;
+	u32 gpio = HWIRQ_TO_GPIO(priv, irq_data->hwirq);
+
+	if (gpiochip_lock_as_irq(&priv->gc, gpio)) {
+		dev_err(priv->gc.parent,
+		"Unable to configure XGene GPIO standby pin %d as IRQ\n",
+				gpio);
+		return;
+	}
+
+	xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_SEL_LO,
+			gpio * 2, 1);
+}
+
+static void xgene_gpio_sb_domain_deactivate(struct irq_domain *d,
+		struct irq_data *irq_data)
+{
+	struct xgene_gpio_sb *priv = d->host_data;
+	u32 gpio = HWIRQ_TO_GPIO(priv, irq_data->hwirq);
+
+	gpiochip_unlock_as_irq(&priv->gc, gpio);
+	xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_SEL_LO,
+			gpio * 2, 0);
+}
+
+static int xgene_gpio_sb_domain_translate(struct irq_domain *d,
+		struct irq_fwspec *fwspec,
+		unsigned long *hwirq,
+		unsigned int *type)
+{
+	struct xgene_gpio_sb *priv = d->host_data;
 
-	if (priv->irq[gpio])
-		return priv->irq[gpio];
+	if ((fwspec->param_count != 2) ||
+		(fwspec->param[0] >= priv->nirq))
+		return -EINVAL;
+	*hwirq = fwspec->param[0];
+	*type = fwspec->param[1];
+	return 0;
+}
+
+static int xgene_gpio_sb_domain_alloc(struct irq_domain *domain,
+					unsigned int virq,
+					unsigned int nr_irqs, void *data)
+{
+	struct irq_fwspec *fwspec = data;
+	struct irq_fwspec parent_fwspec;
+	struct xgene_gpio_sb *priv = domain->host_data;
+	irq_hw_number_t hwirq;
+	unsigned int i;
+
+	hwirq = fwspec->param[0];
+	for (i = 0; i < nr_irqs; i++)
+		irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
+				&xgene_gpio_sb_irq_chip, priv);
+
+	parent_fwspec.fwnode = domain->parent->fwnode;
+	if (is_of_node(parent_fwspec.fwnode)) {
+		parent_fwspec.param_count = 3;
+		parent_fwspec.param[0] = 0;/* SPI */
+		/* Skip SGIs and PPIs*/
+		parent_fwspec.param[1] = hwirq + priv->parent_irq_base - 32;
+		parent_fwspec.param[2] = fwspec->param[1];
+	} else if (is_fwnode_irqchip(parent_fwspec.fwnode)) {
+		parent_fwspec.param_count = 2;
+		parent_fwspec.param[0] = hwirq + priv->parent_irq_base;
+		parent_fwspec.param[1] = fwspec->param[1];
+	} else
+		return -EINVAL;
+
+	return irq_domain_alloc_irqs_parent(domain, virq, nr_irqs,
+			&parent_fwspec);
+}
+
+static void xgene_gpio_sb_domain_free(struct irq_domain *domain,
+		unsigned int virq,
+		unsigned int nr_irqs)
+{
+	struct irq_data *d;
+	unsigned int i;
 
-	return -ENXIO;
+	for (i = 0; i < nr_irqs; i++) {
+		d = irq_domain_get_irq_data(domain, virq + i);
+		irq_domain_reset_irq_data(d);
+	}
 }
 
+static const struct irq_domain_ops xgene_gpio_sb_domain_ops = {
+	.translate      = xgene_gpio_sb_domain_translate,
+	.alloc          = xgene_gpio_sb_domain_alloc,
+	.free           = xgene_gpio_sb_domain_free,
+	.activate	= xgene_gpio_sb_domain_activate,
+	.deactivate	= xgene_gpio_sb_domain_deactivate,
+};
+
 static int xgene_gpio_sb_probe(struct platform_device *pdev)
 {
 	struct xgene_gpio_sb *priv;
-	u32 ret, i;
-	u32 default_lines[] = {0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D};
+	u32 ret;
 	struct resource *res;
 	void __iomem *regs;
+	struct irq_domain *parent_domain = NULL;
+	struct fwnode_handle *fwnode;
+	u32 val32;
 
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv)
@@ -90,6 +256,18 @@ static int xgene_gpio_sb_probe(struct platform_device *pdev)
 	if (IS_ERR(regs))
 		return PTR_ERR(regs);
 
+	priv->regs = regs;
+
+	ret = platform_get_irq(pdev, 0);
+	if (ret > 0) {
+		priv->parent_irq_base = irq_get_irq_data(ret)->hwirq;
+		parent_domain = irq_get_irq_data(ret)->domain;
+	}
+	if (!parent_domain) {
+		dev_err(&pdev->dev, "unable to obtain parent domain\n");
+		return -ENODEV;
+	}
+
 	ret = bgpio_init(&priv->gc, &pdev->dev, 4,
 			regs + MPA_GPIO_IN_ADDR,
 			regs + MPA_GPIO_OUT_ADDR, NULL,
@@ -97,30 +275,51 @@ static int xgene_gpio_sb_probe(struct platform_device *pdev)
         if (ret)
                 return ret;
 
-	priv->gc.to_irq = apm_gpio_sb_to_irq;
-	priv->gc.ngpio = XGENE_MAX_GPIO_DS;
+	priv->gc.to_irq = xgene_gpio_sb_to_irq;
 
-	priv->nirq = XGENE_MAX_GPIO_DS_IRQ;
+	/* Retrieve start irq pin, use default if property not found */
+	priv->irq_start = XGENE_DFLT_IRQ_START_PIN;
+	if (!device_property_read_u32(&pdev->dev,
+					XGENE_IRQ_START_PROPERTY, &val32))
+		priv->irq_start = val32;
 
-	priv->irq = devm_kzalloc(&pdev->dev, sizeof(u32) * XGENE_MAX_GPIO_DS,
-				   GFP_KERNEL);
-	if (!priv->irq)
-		return -ENOMEM;
+	/* Retrieve number irqs, use default if property not found */
+	priv->nirq = XGENE_DFLT_MAX_NIRQ;
+	if (!device_property_read_u32(&pdev->dev, XGENE_NIRQ_PROPERTY, &val32))
+		priv->nirq = val32;
 
-	for (i = 0; i < priv->nirq; i++) {
-		priv->irq[default_lines[i]] = platform_get_irq(pdev, i);
-		xgene_gpio_set_bit(&priv->gc, regs + MPA_GPIO_SEL_LO,
-                                   default_lines[i] * 2, 1);
-		xgene_gpio_set_bit(&priv->gc, regs + MPA_GPIO_INT_LVL, i, 1);
-	}
+	/* Retrieve number gpio, use default if property not found */
+	priv->gc.ngpio = XGENE_DFLT_MAX_NGPIO;
+	if (!device_property_read_u32(&pdev->dev, XGENE_NGPIO_PROPERTY, &val32))
+		priv->gc.ngpio = val32;
+
+	dev_info(&pdev->dev, "Support %d gpios, %d irqs start from pin %d\n",
+			priv->gc.ngpio, priv->nirq, priv->irq_start);
 
 	platform_set_drvdata(pdev, priv);
 
-	ret = gpiochip_add_data(&priv->gc, priv);
-	if (ret)
-		dev_err(&pdev->dev, "failed to register X-Gene GPIO Standby driver\n");
+	if (pdev->dev.of_node)
+		fwnode = of_node_to_fwnode(pdev->dev.of_node);
 	else
-		dev_info(&pdev->dev, "X-Gene GPIO Standby driver registered\n");
+		fwnode = pdev->dev.fwnode;
+
+	priv->irq_domain = irq_domain_create_hierarchy(parent_domain,
+					0, priv->nirq, fwnode,
+					&xgene_gpio_sb_domain_ops, priv);
+	if (!priv->irq_domain)
+		return -ENODEV;
+
+	priv->gc.irqdomain = priv->irq_domain;
+
+	ret = gpiochip_add_data(&priv->gc, priv);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"failed to register X-Gene GPIO Standby driver\n");
+		irq_domain_remove(priv->irq_domain);
+		return ret;
+	}
+
+	dev_info(&pdev->dev, "X-Gene GPIO Standby driver registered\n");
 
 	if (priv->nirq > 0) {
 		/* Register interrupt handlers for gpio signaled acpi events */
@@ -138,6 +337,8 @@ static int xgene_gpio_sb_remove(struct platform_device *pdev)
 		acpi_gpiochip_free_interrupts(&priv->gc);
 	}
 
+	irq_domain_remove(priv->irq_domain);
+
 	gpiochip_remove(&priv->gc);
 	return 0;
 }
-- 
1.7.12.4



From qnguyen at apm.com  Sun Feb 14 20:57:42 2016
From: qnguyen at apm.com (Quan Nguyen)
Date: Mon, 15 Feb 2016 11:57:42 +0700
Subject: [PATCH v6 2/3] Documentation: gpio: Update description for X-Gene
 standby GPIO controller DTS binding
In-Reply-To: <1455512263-18183-1-git-send-email-qnguyen@apm.com>
References: <1455512263-18183-1-git-send-email-qnguyen@apm.com>
Message-ID: <1455512263-18183-3-git-send-email-qnguyen@apm.com>

Update description for X-Gene standby GPIO controller DTS binding to
support GPIO line configuration as input, output or external IRQ pin.

Signed-off-by: Y Vo <yvo at apm.com>
Signed-off-by: Quan Nguyen <qnguyen at apm.com>
---
 .../devicetree/bindings/gpio/gpio-xgene-sb.txt     | 47 ++++++++++++++++++----
 1 file changed, 40 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
index dae1300..7b8b4cb 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
@@ -1,10 +1,20 @@
 APM X-Gene Standby GPIO controller bindings
 
-This is a gpio controller in the standby domain.
-
-There are 20 GPIO pins from 0..21. There is no GPIO_DS14 or GPIO_DS15,
-only GPIO_DS8..GPIO_DS13 support interrupts. The IRQ mapping
-is currently 1-to-1 on interrupts 0x28 thru 0x2d.
+This is a gpio controller in the standby domain. It also supports interrupt in
+some particular pins which are sourced to its parent interrupt controller
+as diagram below:
+                           +-----------------+
+                           | X-Gene standby  |
+                           | GPIO controller +--------- GPIO_0
++------------+             |                 | ...
+| Parent IRQ |             |                 +--------- GPIO_8/EXT_INT_0
+| controller |  EXT_INT_0  |                 | ...
+| (GICv2)    +-------------+                 +--------- GPIO_[N+8]/EXT_INT_N
+|            |  ...        |                 |
+|            |  EXT_INT_N  |                 +--------- GPIO_[N+9]
+|            +-------------+                 | ...
+|            |             |                 +--------- GPIO_MAX
++------------+             +-----------------+
 
 Required properties:
 - compatible: "apm,xgene-gpio-sb" for the X-Gene Standby GPIO controller
@@ -15,10 +25,18 @@ Required properties:
 		0 = active high
 		1 = active low
 - gpio-controller: Marks the device node as a GPIO controller.
-- interrupts: Shall contain exactly 6 interrupts.
+- interrupts: The EXT_INT_0 parent interrupt resource must be listed first.
+- interrupt-parent: Phandle of the parent interrupt controller.
+- interrupt-cells: Should be two.
+       - first cell is 0-N coresponding for EXT_INT_0 to EXT_INT_N.
+       - second cell is used to specify flags.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- apm,nr-gpios: Optional, specify number of gpios pin.
+- apm,nr-irqs: Optional, specify number of interrupt pins.
+- apm,irq-start: Optional, specify lowest gpio pin support interrupt.
 
 Example:
-	sbgpio: sbgpio at 17001000 {
+	sbgpio: gpio at 17001000{
 		compatible = "apm,xgene-gpio-sb";
 		reg = <0x0 0x17001000 0x0 0x400>;
 		#gpio-cells = <2>;
@@ -29,4 +47,19 @@ Example:
 				<0x0 0x2b 0x1>,
 				<0x0 0x2c 0x1>,
 				<0x0 0x2d 0x1>;
+		interrupt-parent = <&gic>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		apm,nr-gpios = <22>;
+		apm,nr-irqs = <6>;
+		apm,irq-start = <8>;
+	};
+
+	testuser {
+		compatible = "example,testuser";
+		/* Use the GPIO_13/EXT_INT_5 line as an active high triggered
+		 * level interrupt
+		 */
+		interrupts = <5 4>;
+		interrupt-parent = <&sbgpio>;
 	};
-- 
1.7.12.4



From qnguyen at apm.com  Sun Feb 14 20:57:43 2016
From: qnguyen at apm.com (Quan Nguyen)
Date: Mon, 15 Feb 2016 11:57:43 +0700
Subject: [PATCH v6 3/3] arm64: dts: Update X-Gene standby GPIO controller DTS
 entries
In-Reply-To: <1455512263-18183-1-git-send-email-qnguyen@apm.com>
References: <1455512263-18183-1-git-send-email-qnguyen@apm.com>
Message-ID: <1455512263-18183-4-git-send-email-qnguyen@apm.com>

Update APM X-Gene standby GPIO controller DTS entries to enable it
as interrupt controller.

Signed-off-by: Y Vo <yvo at apm.com>
Signed-off-by: Quan Nguyen <qnguyen at apm.com>
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index fe30f76..0f733da 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -883,6 +883,9 @@
 					<0x0 0x2b 0x1>,
 					<0x0 0x2c 0x1>,
 					<0x0 0x2d 0x1>;
+			interrupt-parent = <&gic>;
+			#interrupt-cells = <2>;
+			interrupt-controller;
 		};
 
 		rtc: rtc at 10510000 {
-- 
1.7.12.4



From sre at kernel.org  Sun Feb 14 21:01:18 2016
From: sre at kernel.org (Sebastian Reichel)
Date: Mon, 15 Feb 2016 06:01:18 +0100
Subject: [PATCH 2/2] ARM: versatile: move restart to the device tree
In-Reply-To: <1453710656-14280-1-git-send-email-linus.walleij@linaro.org>
References: <1453710656-14280-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <20160215050118.GC28626@earth>

Hi,

On Mon, Jan 25, 2016 at 09:30:56AM +0100, Linus Walleij wrote:
> We have a power/reset driver for the Versatile family
> in drivers/power/reset so let's just activate that driver
> and use it and get rid of some non-DT remnants.
> 
> Cc: Sebastian Reichel <sre at kernel.org>
> Cc: Dmitry Eremin-Solenikov <dbaryshkov at gmail.com>
> Cc: David Woodhouse <dwmw2 at infradead.org>
> Cc: Rob Herring <robh at kernel.org>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

Acked-By: Sebastian Reichel <sre at kernel.org>

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160215/ac760a53/attachment.sig>

From sre at kernel.org  Sun Feb 14 21:03:09 2016
From: sre at kernel.org (Sebastian Reichel)
Date: Mon, 15 Feb 2016 06:03:09 +0100
Subject: [PATCH] power: collie_battery: hide unused variable
In-Reply-To: <1453736756-1959377-2-git-send-email-arnd@arndb.de>
References: <1453736756-1959377-2-git-send-email-arnd@arndb.de>
Message-ID: <20160215050308.GD28626@earth>

Hi,

On Mon, Jan 25, 2016 at 04:45:49PM +0100, Arnd Bergmann wrote:
> The 'wakeup_enabled' variable in this driver is only accessed
> by the optional power management functions and we get a warning
> when they are disabled:
> 
> drivers/power/collie_battery.c:29:12: error: 'wakeup_enabled' defined but not used [-Werror=unused-variable]
> 
> This moves the definition next to the users inside the same #ifdef,
> which avoids the warning.

Thanks, queued.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160215/07779cfd/attachment.sig>

From linux at roeck-us.net  Sun Feb 14 21:14:06 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Sun, 14 Feb 2016 21:14:06 -0800
Subject: [PATCH v2] ARM: dts: vfxxx: Add iio_hwmon node for ADC
 temperature channel
In-Reply-To: <20160215044214.GA5545@Sanchayan-Arch.toradex.int>
References: <cd32f1664a04b38b8a025414d039bd015cb9a5ff.1455278754.git.maitysanchayan@gmail.com>
 <20160214083349.GR6756@tiger>
 <20160215044214.GA5545@Sanchayan-Arch.toradex.int>
Message-ID: <56C15E9E.3070802@roeck-us.net>

On 02/14/2016 08:42 PM, maitysanchayan at gmail.com wrote:
> Hello Shawn,
>
> On 16-02-14 16:33:49, Shawn Guo wrote:
>> On Fri, Feb 12, 2016 at 05:53:00PM +0530, Sanchayan Maity wrote:
>>> Add iio_hwmon node to expose the temperature channel on Vybrid as
>>> hardware monitor device using the iio_hwmon driver.
>>>
>>> Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
>>> ---
>>>
>>> Hello,
>>>
>>> The first version of the patch was send quite a while ago.
>>> https://lkml.org/lkml/2015/9/16/932
>>>
>>> Shawn you had requested that hyphen rather than underscore should
>>> be used in node name. I looked into that.
>>>
>>> The iio_hwmon driver calls hwmon_device register_with_groups inside
>>> hwmon.c and this
>>> http://lxr.free-electrons.com/source/drivers/hwmon/hwmon.c#L103
>>>
>>> does not allow hyphen in hwmon name attribute. I was not aware of
>>> this but while trying to test the change, the device probe failed
>>> with EINVAL. I think we should stick to the existing use of the
>>> bindings or we need to change the hwmon code as well along with the
>>> existing device tree files and binding documentation.
>>
>> I disagree.
>>
>> If hyphen is invalid to be part of hwmon name attribute, the following
>> code in iio_hwmon_probe() is plain wrong, because hyphen is very valid
>> to be part of node names in device tree.
>>
>>          if (dev->of_node && dev->of_node->name)
>>                  name = dev->of_node->name;
>
> @Shawn
> I agree with what you state here, however as you can see the hwmon_device_
> register_with_groups does check for hypen with strpbrk and returns EINVAL.
> Changing to hyphen instead of currently present underscore in iio_hwmon
> node name causes probe failure.
>
> If the node name needs to have hyphen, then the check for hyphen as an invalid
> character in hwmon name attribute needs to be changed. I am CC'ing the hwmon
> subsystem maintainers Jean Delvare ands Guenter Roeck as well as hwmon list to
> check.
>
> @Jean & Guenter
> Can you please comment if the change to hwmon_device_register_with_groups
> to accept hyphen as a valid character in hwmon name attribute will be acceptable?

User space would not like the '-' and get confused.

We'll have to change the above code and replace '-' with '_' in the name if/when
it is seen. Sorry, I didn't realize the problem when I wrote that code.

Guenter

> Sorry if this is sudden andfor bringing you late into the discussion Jean and
> Guenter.
>
> Thanks & Regards,
> Sanchayan.
>
>>
>> Shawn
>>
>>>
>>> Changes since v1:
>>> 1. Expose ADC1 temperature channel as well
>>> 2. Move the entry outside of the aips1 bus node
>>>
>>> Best Regards,
>>> Sanchayan Maity.
>>> ---
>>>   arch/arm/boot/dts/vfxxx.dtsi | 5 +++++
>>>   1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
>>> index a5f07e3..8ed8e47 100644
>>> --- a/arch/arm/boot/dts/vfxxx.dtsi
>>> +++ b/arch/arm/boot/dts/vfxxx.dtsi
>>> @@ -673,5 +673,10 @@
>>>   				status = "disabled";
>>>   			};
>>>   		};
>>> +
>>> +		iio_hwmon {
>>> +			compatible = "iio-hwmon";
>>> +			io-channels = <&adc0 16>, <&adc1 16>;
>>> +		};
>>>   	};
>>>   };
>>> --
>>> 2.7.1
>>>
>>>
>



From viresh.kumar at linaro.org  Sun Feb 14 21:28:43 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Mon, 15 Feb 2016 10:58:43 +0530
Subject: [next] Odroid XU3 easily over-heats
In-Reply-To: <56C01963.3080106@gmail.com>
References: <56C01963.3080106@gmail.com>
Message-ID: <20160215052843.GA6334@vireshk-i7>

On 14-02-16, 15:06, Krzysztof Kozlowski wrote:
> Hi all,
> 
> With recent addition of cpufreq-dt support to Exynos5422
> it is very easy to over-heat the Odroid XU3 leading to critical shutdown:

How were OPPs passed earlier? I failed to see them in kernel somehow.
You must have been using opp-v1 earlier, right?

You used boost-freqs then? You used cpufreq as a cooling device then?

> What about cpufreq as cooling device? Probably that part
> is missing now, right?

Maybe, how was that earlier though ?

-- 
viresh


From kuninori.morimoto.gx at renesas.com  Sun Feb 14 21:46:56 2016
From: kuninori.morimoto.gx at renesas.com (Kuninori Morimoto)
Date: Mon, 15 Feb 2016 05:46:56 +0000
Subject: [PATCH] arm64: dts: r8a7795: Add GIC-400 virtual interfaces
In-Reply-To: <1455005692-9382-1-git-send-email-dirk.behme@de.bosch.com>
References: <1455005692-9382-1-git-send-email-dirk.behme@de.bosch.com>
Message-ID: <87povyh6lq.wl%kuninori.morimoto.gx@renesas.com>


Hi Dirk
Cc Geert

> Besides the distributor and the CPU interface the GIC-400 additionally
> supports the virtual interface control blocks and the virtual CPU interfaces.
> 
> Add the physical base addresses and size for these.
> 
> See
> 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0471b/index.html
> -> 3.2. GIC-400 register map
> 
> and Linux kernel's
> 
> Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
> 
> for more details.
> 
> Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
> ---

Our R-Car chip is out-of-mapping.
Geert had indicated it in
http://thread.gmane.org/gmane.linux.ports.sh.devel/49751/focus=51544
And we have no answer about it I think

>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index 8f1ed23..0163967 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -130,7 +130,9 @@
>  			#address-cells = <0>;
>  			interrupt-controller;
>  			reg = <0x0 0xf1010000 0 0x1000>,
> -			      <0x0 0xf1020000 0 0x2000>;
> +			      <0x0 0xf1020000 0 0x2000>,
> +			      <0x0 0xf1040000 0 0x2000>,
> +			      <0x0 0xf1060000 0 0x2000>;
>  			interrupts = <GIC_PPI 9
>  					(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>  		};
> -- 
> 2.5.1
> 


From shawnguo at kernel.org  Sun Feb 14 22:10:09 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Mon, 15 Feb 2016 14:10:09 +0800
Subject: [RFC 3/4] ARM: imx: add the platform related rpmsg implementation
In-Reply-To: <DBXPR04MB2708826D9E8C16E8EFE492E8CDA0@DBXPR04MB270.eurprd04.prod.outlook.com>
References: <1452067604-10466-1-git-send-email-hongxing.zhu@nxp.com>
 <1452067604-10466-4-git-send-email-hongxing.zhu@nxp.com>
 <20160128013527.GA9070@tiger>
 <DBXPR04MB2708826D9E8C16E8EFE492E8CDA0@DBXPR04MB270.eurprd04.prod.outlook.com>
Message-ID: <20160215061009.GU6756@tiger>

+LAKML

On Thu, Jan 28, 2016 at 02:17:21AM +0000, Richard Zhu wrote:
> Hi Shawn:
> Thanks for your comments.
> Further review would copied to Stefan Agner.

Please do not top-posting.

> On Wed, Jan 06, 2016 at 04:06:43PM +0800, Richard Zhu wrote:
> > From: Richard Zhu <Richard.Zhu at freescale.com>
> > 
> > - add mu driver support, the irq and 4bytes msg of the mu module are 
> > as the interaction channel between A# core and the M4 core on imx amp 
> > platforms.
> > - register one notify in isr of the mu's irq used by rpmsg.
> > - instance the virtual processor, and fill up the virtio_config_ops in 
> > the platform related rpmsg implementation codes.
> > - hard-code the vring storage shared by A# core and M# core on AMP 
> > SOCs.
> > 
> > Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
> > ---
> >  arch/arm/mach-imx/Kconfig     |  12 ++
> >  arch/arm/mach-imx/Makefile    |   2 +
> >  arch/arm/mach-imx/imx_rpmsg.c | 364 ++++++++++++++++++++++++++++++++++++++++++
> >  arch/arm/mach-imx/mu.c        | 217 +++++++++++++++++++++++++
> 
> I'm not rpmsg expert, but it seems to me that the driver should be put into drivers/rpmsg/ rather than mach-imx.
> [Richard] This part rpmsg codes are closed related to the platform. For example, kinds of ops callback functions.
> Thus, these codes are placed into arch/arm/mach-imx/ folder. BTW,  so does to omap rpmsg implementation.
> http://omappedia.org/wiki/RPMsg_Kernel_Sources

I just took a closer look at this.  What the omappedia page above
describes is an OMAP rpmsg implementation in a vendor tree which is
in turn based on a relatively old kernel version, i.e. v3.0.

I guess the implementation is a base of what mainline has today on
remoteproc/rpmsg support, but they are somehow different.  For example,
on mainline kernel today, there is no remoteproc/rpmsg code in
arch/arm/plat-omap.  And, instead of handling rpmsg with a platform
specific driver, remoteproc encapsulates the rpmsg support.  You can
find the details in commit ac8954a41393 (remoteproc: create rpmsg virtio
device).

I suggest you look at the mainline code today instead of any old
implementation for reference.  And in any case, with device tree
support to populate platform device as needed, it's a wrong to put
remoteproc/rpmsg related driver code into arch/arm/mach-imx.

Shawn


From mugunthanvnm at ti.com  Sun Feb 14 22:15:59 2016
From: mugunthanvnm at ti.com (Mugunthan V N)
Date: Mon, 15 Feb 2016 11:45:59 +0530
Subject: [PATCH] drivers: net: cpsw-phy-sel: add dev_warn() for
 unsupported PHY mode
In-Reply-To: <1455324336-3884-1-git-send-email-drivshin.allworx@gmail.com>
References: <1455324336-3884-1-git-send-email-drivshin.allworx@gmail.com>
Message-ID: <56C16D1F.7060601@ti.com>

On Saturday 13 February 2016 06:15 AM, David Rivshin (Allworx) wrote:
> From: David Rivshin <drivshin at allworx.com>
> 
> The cpsw-phy-sel driver supports only MII, RMII, and RGMII PHY modes,
> and silently handled any other values as if MII was specified. In a
> case where the PHY mode was incorrectly specified, or a bug elsewhere,
> there would be no indication of a problem. If MII was the correct mode,
> then this will go unnoticed, otherwise the symptom will be a failure
> to transmit/receive data over the RMII/RGMII link.
> 
> Add a dev_warn() to make this condition obvious and provide a
> breadcrumb to follow.
> 
> Cc: Mugunthan V N <mugunthanvnm at ti.com>
> Signed-off-by: David Rivshin <drivshin at allworx.com>

Acked-by: Mugunthan V N <mugunthanvnm at ti.com>

Regards
Mugunthan V N



From k.kozlowski at samsung.com  Sun Feb 14 22:36:18 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Mon, 15 Feb 2016 15:36:18 +0900
Subject: [next] Odroid XU3 easily over-heats
In-Reply-To: <20160215052843.GA6334@vireshk-i7>
References: <56C01963.3080106@gmail.com> <20160215052843.GA6334@vireshk-i7>
Message-ID: <56C171E2.90306@samsung.com>

On 15.02.2016 14:28, Viresh Kumar wrote:
> On 14-02-16, 15:06, Krzysztof Kozlowski wrote:
>> Hi all,
>>
>> With recent addition of cpufreq-dt support to Exynos5422
>> it is very easy to over-heat the Odroid XU3 leading to critical shutdown:
> 
> How were OPPs passed earlier? I failed to see them in kernel somehow.
> You must have been using opp-v1 earlier, right?

Till now there was no support for cpufreq for Exynos542x. For some time
Bartlomiej was developing these patches - using opp-v1 at beginning. I
don't know whether he encountered this before.

> 
> You used boost-freqs then? You used cpufreq as a cooling device then?
> 
>> What about cpufreq as cooling device? Probably that part
>> is missing now, right?
> 
> Maybe, how was that earlier though ?

Bootloader initialized frequency and regulators to some safe defaults. I
think the voltage set by uboot is 1 V (for big and little) which
corresponds to ~800 MHz of frequency (I don't know the exact frequency
because it is hardcoded as divider value...).

However there was no cooling device except fan. This did not change. So
the only difference seems to be that now at critical shutdown moment it
operates at 1300 MHz / 1.275 V (little) and 1800 MHz / 1.250 V (big).

Best regards,
Krzysztof


From hongxing.zhu at nxp.com  Sun Feb 14 22:44:06 2016
From: hongxing.zhu at nxp.com (Richard Zhu)
Date: Mon, 15 Feb 2016 06:44:06 +0000
Subject: [RFC 3/4] ARM: imx: add the platform related rpmsg implementation
In-Reply-To: <20160215061009.GU6756@tiger>
References: <1452067604-10466-1-git-send-email-hongxing.zhu@nxp.com>
 <1452067604-10466-4-git-send-email-hongxing.zhu@nxp.com>
 <20160128013527.GA9070@tiger>
 <DBXPR04MB2708826D9E8C16E8EFE492E8CDA0@DBXPR04MB270.eurprd04.prod.outlook.com>
 <20160215061009.GU6756@tiger>
Message-ID: <DBXPR04MB27087D6DD453A62CEE368BF8CAC0@DBXPR04MB270.eurprd04.prod.outlook.com>


> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo at kernel.org]
> Sent: Monday, February 15, 2016 2:10 PM
> To: Richard Zhu
> Cc: ohad at wizery.com; Stefan Agner; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [RFC 3/4] ARM: imx: add the platform related rpmsg
> implementation
> 
> +LAKML
> 
> On Thu, Jan 28, 2016 at 02:17:21AM +0000, Richard Zhu wrote:
> > Hi Shawn:
> > Thanks for your comments.
> > Further review would copied to Stefan Agner.
> 
> Please do not top-posting.
> 
> > On Wed, Jan 06, 2016 at 04:06:43PM +0800, Richard Zhu wrote:
> > > From: Richard Zhu <Richard.Zhu at freescale.com>
> > >
> > > - add mu driver support, the irq and 4bytes msg of the mu module are
> > > as the interaction channel between A# core and the M4 core on imx
> > > amp platforms.
> > > - register one notify in isr of the mu's irq used by rpmsg.
> > > - instance the virtual processor, and fill up the virtio_config_ops
> > > in the platform related rpmsg implementation codes.
> > > - hard-code the vring storage shared by A# core and M# core on AMP
> > > SOCs.
> > >
> > > Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
> > > ---
> > >  arch/arm/mach-imx/Kconfig     |  12 ++
> > >  arch/arm/mach-imx/Makefile    |   2 +
> > >  arch/arm/mach-imx/imx_rpmsg.c | 364
> ++++++++++++++++++++++++++++++++++++++++++
> > >  arch/arm/mach-imx/mu.c        | 217 +++++++++++++++++++++++++
> >
> > I'm not rpmsg expert, but it seems to me that the driver should be put into
> drivers/rpmsg/ rather than mach-imx.
> > [Richard] This part rpmsg codes are closed related to the platform. For
> example, kinds of ops callback functions.
> > Thus, these codes are placed into arch/arm/mach-imx/ folder. BTW,  so does
> to omap rpmsg implementation.
> > http://omappedia.org/wiki/RPMsg_Kernel_Sources
> 
> I just took a closer look at this.  What the omappedia page above describes is
> an OMAP rpmsg implementation in a vendor tree which is in turn based on a
> relatively old kernel version, i.e. v3.0.
> 
> I guess the implementation is a base of what mainline has today on
> remoteproc/rpmsg support, but they are somehow different.  For example, on
> mainline kernel today, there is no remoteproc/rpmsg code in arch/arm/plat-
> omap.  And, instead of handling rpmsg with a platform specific driver,
> remoteproc encapsulates the rpmsg support.  You can find the details in
> commit ac8954a41393 (remoteproc: create rpmsg virtio device).
> 
> I suggest you look at the mainline code today instead of any old
> implementation for reference.  And in any case, with device tree support to
> populate platform device as needed, it's a wrong to put remoteproc/rpmsg
> related driver code into arch/arm/mach-imx.
> 
> Shawn
[Zhu hongxing]  Thanks a lot for your advice. I would take look into it, and re-organize my
patch-set.

Best Regards
hongxing zhu



From maitysanchayan at gmail.com  Sun Feb 14 22:42:31 2016
From: maitysanchayan at gmail.com (Sanchayan Maity)
Date: Mon, 15 Feb 2016 12:12:31 +0530
Subject: [PATCH v2 0/2] Add DAC driver support for Vybrid SoC
Message-ID: <cover.1455516083.git.maitysanchayan@gmail.com>

Hello,

This patchset adds support for the DAC peripheral on Vybrid SoC.
Patchset is based on top of shawn's for-next branch and has been
tested on a Toradex Colibri VF50 module.

@Jonathan
I kept the IIO_SHARED_BY_DIR instead of using IIO_SHARED_BY_ALL
since this gives "out_conversion_mode" allowing me to distinguish
this in the ABI documentation, that this is explicitly for the DAC.

Since 4.5-rc4 was released recently and assuming this makes it with
this or next version, I assumed the target kernel version would be
4.6 and used that in ABI documentation.

Feedbacks and comments most welcome.

Changes since v1:
1. Fix return type of vf610_dac_init function
2. Document conversion modes in sysfs-bus-iio-vf610
3. Remove "indexed" specification from iio_chan_spec
4. Use "return" directly from default case in switch
5. Remove DRIVER_NAME
6. Call vf610_dac_init before iio device registration
7. Define and use vf610_dac_exit function in remove and suspend
8. Add sysfs ABI documentation

v1 of the patchset:
http://www.spinics.net/lists/arm-kernel/msg481190.html

Thanks & Regards,
Sanchayan Maity.

Sanchayan Maity (2):
  ARM: dts: vfxxx: Add DAC node for Vybrid SoC
  iio: dac: vf610_dac: Add IIO DAC driver for Vybrid SoC

 Documentation/ABI/testing/sysfs-bus-iio-vf610      |   9 +
 .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
 arch/arm/boot/dts/vfxxx.dtsi                       |  18 ++
 drivers/iio/dac/Kconfig                            |   8 +
 drivers/iio/dac/Makefile                           |   1 +
 drivers/iio/dac/vf610_dac.c                        | 298 +++++++++++++++++++++
 6 files changed, 354 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
 create mode 100644 drivers/iio/dac/vf610_dac.c

-- 
2.7.1



From maitysanchayan at gmail.com  Sun Feb 14 22:42:32 2016
From: maitysanchayan at gmail.com (Sanchayan Maity)
Date: Mon, 15 Feb 2016 12:12:32 +0530
Subject: [PATCH v2 1/2] ARM: dts: vfxxx: Add DAC node for Vybrid SoC
In-Reply-To: <cover.1455516083.git.maitysanchayan@gmail.com>
References: <cover.1455516083.git.maitysanchayan@gmail.com>
Message-ID: <cb23ab53250603e96eb4725c266d01e5376f8a68.1455516083.git.maitysanchayan@gmail.com>

Add a device tree node entry for DAC peripheral on Vybrid SoC.

Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
---
 arch/arm/boot/dts/vfxxx.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index a5f07e3..8238069 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -602,6 +602,24 @@
 				status = "disabled";
 			};
 
+			dac0: dac at 400cc000 {
+				compatible = "fsl,vf610-dac";
+				reg = <0x400cc000 1000>;
+				interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
+				clock-names = "dac";
+				clocks = <&clks VF610_CLK_DAC0>;
+				status = "disabled";
+			};
+
+			dac1: dac at 400cd000 {
+				compatible = "fsl,vf610-dac";
+				reg = <0x400cd000 1000>;
+				interrupts = <56 IRQ_TYPE_LEVEL_HIGH>;
+				clock-names = "dac";
+				clocks = <&clks VF610_CLK_DAC1>;
+				status = "disabled";
+			};
+
 			fec0: ethernet at 400d0000 {
 				compatible = "fsl,mvf600-fec";
 				reg = <0x400d0000 0x1000>;
-- 
2.7.1



From maitysanchayan at gmail.com  Sun Feb 14 22:42:33 2016
From: maitysanchayan at gmail.com (Sanchayan Maity)
Date: Mon, 15 Feb 2016 12:12:33 +0530
Subject: [PATCH v2 2/2] iio: dac: vf610_dac: Add IIO DAC driver for Vybrid SoC
In-Reply-To: <cover.1455516083.git.maitysanchayan@gmail.com>
References: <cover.1455516083.git.maitysanchayan@gmail.com>
Message-ID: <597b39da08c4c1416984cf7e873f56e19975b80e.1455516083.git.maitysanchayan@gmail.com>

Add driver support for DAC peripheral on Vybrid SoC.

Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/ABI/testing/sysfs-bus-iio-vf610      |   9 +
 .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
 drivers/iio/dac/Kconfig                            |   8 +
 drivers/iio/dac/Makefile                           |   1 +
 drivers/iio/dac/vf610_dac.c                        | 298 +++++++++++++++++++++
 5 files changed, 336 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
 create mode 100644 drivers/iio/dac/vf610_dac.c

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-vf610 b/Documentation/ABI/testing/sysfs-bus-iio-vf610
index ecbc1f4..5ea809c 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-vf610
+++ b/Documentation/ABI/testing/sysfs-bus-iio-vf610
@@ -5,3 +5,12 @@ Description:
 		Specifies the hardware conversion mode used. The three
 		available modes are "normal", "high-speed" and "low-power",
 		where the last is the default mode.
+
+
+What:		/sys/bus/iio/devices/iio:deviceX/out_conversion_mode
+KernelVersion:	4.6
+Contact:	linux-iio at vger.kernel.org
+Description:
+		Specifies the hardware conversion mode used within DAC.
+		The two available modes are "high-power" and "low-power",
+		where "low-power" mode is the default mode.
\ No newline at end of file
diff --git a/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
new file mode 100644
index 0000000..20c6c7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
@@ -0,0 +1,20 @@
+Freescale vf610 Digital to Analog Converter bindings
+
+The devicetree bindings are for the new DAC driver written for
+vf610 SoCs from Freescale.
+
+Required properties:
+- compatible: Should contain "fsl,vf610-dac"
+- reg: Offset and length of the register set for the device
+- interrupts: Should contain the interrupt for the device
+- clocks: The clock is needed by the DAC controller
+- clock-names: Must contain "dac" matching entry in the clocks property.
+
+Example:
+dac0: dac at 400cc000 {
+	compatible = "fsl,vf610-dac";
+	reg = <0x400cc000 0x1000>;
+	interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
+	clock-names = "dac";
+	clocks = <&clks VF610_CLK_DAC0>;
+};
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index e701e28..8eb0502 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -196,4 +196,12 @@ config MCP4922
 	  To compile this driver as a module, choose M here: the module
 	  will be called mcp4922.
 
+config VF610_DAC
+	tristate "Vybrid vf610 DAC driver"
+	help
+	  Say yes here to support Vybrid board digital-to-analog converter.
+
+	  This driver can also be built as a module. If so, the module will
+	  be called vf610_dac.
+
 endmenu
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index 63ae056..93feb27 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_MAX517) += max517.o
 obj-$(CONFIG_MAX5821) += max5821.o
 obj-$(CONFIG_MCP4725) += mcp4725.o
 obj-$(CONFIG_MCP4922) += mcp4922.o
+obj-$(CONFIG_VF610_DAC) += vf610_dac.o
diff --git a/drivers/iio/dac/vf610_dac.c b/drivers/iio/dac/vf610_dac.c
new file mode 100644
index 0000000..3f70f96
--- /dev/null
+++ b/drivers/iio/dac/vf610_dac.c
@@ -0,0 +1,298 @@
+/*
+ * Freescale Vybrid vf610 DAC driver
+ *
+ * Copyright 2016 Toradex AG
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define VF610_DACx_STATCTRL		0x20
+
+#define VF610_DAC_DACEN			BIT(15)
+#define VF610_DAC_DACRFS		BIT(14)
+#define VF610_DAC_LPEN			BIT(11)
+
+#define VF610_DAC_DAT0(x)		((x) & 0xFFF)
+
+enum vf610_conversion_mode_sel {
+	VF610_DAC_CONV_HIGH_POWER,
+	VF610_DAC_CONV_LOW_POWER,
+};
+
+struct vf610_dac {
+	struct clk *clk;
+	struct device *dev;
+	enum vf610_conversion_mode_sel conv_mode;
+	void __iomem *regs;
+};
+
+static void vf610_dac_init(struct vf610_dac *info)
+{
+	int val;
+
+	info->conv_mode = VF610_DAC_CONV_LOW_POWER;
+	val = VF610_DAC_DACEN | VF610_DAC_DACRFS |
+		VF610_DAC_LPEN;
+	writel(val, info->regs + VF610_DACx_STATCTRL);
+}
+
+static void vf610_dac_exit(struct vf610_dac *info)
+{
+	int val;
+
+	val = readl(info->regs + VF610_DACx_STATCTRL);
+	val &= ~VF610_DAC_DACEN;
+	writel(val, info->regs + VF610_DACx_STATCTRL);
+}
+
+static int vf610_set_conversion_mode(struct iio_dev *indio_dev,
+				const struct iio_chan_spec *chan,
+				unsigned int mode)
+{
+	struct vf610_dac *info = iio_priv(indio_dev);
+	int val;
+
+	mutex_lock(&indio_dev->mlock);
+	info->conv_mode = mode;
+	val = readl(info->regs + VF610_DACx_STATCTRL);
+	if (mode)
+		val |= VF610_DAC_LPEN;
+	else
+		val &= ~VF610_DAC_LPEN;
+	writel(val, info->regs + VF610_DACx_STATCTRL);
+	mutex_unlock(&indio_dev->mlock);
+
+	return 0;
+}
+
+static int vf610_get_conversion_mode(struct iio_dev *indio_dev,
+				const struct iio_chan_spec *chan)
+{
+	struct vf610_dac *info = iio_priv(indio_dev);
+
+	return info->conv_mode;
+}
+
+static const char * const vf610_conv_modes[] = { "high-power", "low-power" };
+
+static const struct iio_enum vf610_conversion_mode = {
+	.items = vf610_conv_modes,
+	.num_items = ARRAY_SIZE(vf610_conv_modes),
+	.get = vf610_get_conversion_mode,
+	.set = vf610_set_conversion_mode,
+};
+
+static const struct iio_chan_spec_ext_info vf610_ext_info[] = {
+	IIO_ENUM("conversion_mode", IIO_SHARED_BY_DIR,
+		&vf610_conversion_mode),
+	{},
+};
+
+#define VF610_DAC_CHAN(_chan_type) { \
+	.type = (_chan_type), \
+	.output = 1, \
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+	.ext_info = vf610_ext_info, \
+}
+
+static const struct iio_chan_spec vf610_dac_iio_channels[] = {
+	VF610_DAC_CHAN(IIO_VOLTAGE),
+};
+
+static int vf610_read_raw(struct iio_dev *indio_dev,
+			struct iio_chan_spec const *chan,
+			int *val, int *val2,
+			long mask)
+{
+	struct vf610_dac *info = iio_priv(indio_dev);
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		*val = VF610_DAC_DAT0(readl(info->regs));
+		return IIO_VAL_INT;
+	case IIO_CHAN_INFO_SCALE:
+		/*
+		 * DACRFS is always 1 for valid reference and typical
+		 * reference voltage as per Vybrid datasheet is 3.3V
+		 * from section 9.1.2.1 of Vybrid datasheet
+		 */
+		*val = 3300 /* mV */;
+		*val2 = 12;
+		return IIO_VAL_FRACTIONAL_LOG2;
+
+	default:
+		return -EINVAL;
+	}
+}
+
+static int vf610_write_raw(struct iio_dev *indio_dev,
+			struct iio_chan_spec const *chan,
+			int val, int val2,
+			long mask)
+{
+	struct vf610_dac *info = iio_priv(indio_dev);
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		mutex_lock(&indio_dev->mlock);
+		writel(VF610_DAC_DAT0(val), info->regs);
+		mutex_unlock(&indio_dev->mlock);
+		return 0;
+
+	default:
+		return -EINVAL;
+	}
+}
+
+static const struct iio_info vf610_dac_iio_info = {
+	.driver_module = THIS_MODULE,
+	.read_raw = &vf610_read_raw,
+	.write_raw = &vf610_write_raw,
+};
+
+static const struct of_device_id vf610_dac_match[] = {
+	{ .compatible = "fsl,vf610-dac", },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, vf610_dac_match);
+
+static int vf610_dac_probe(struct platform_device *pdev)
+{
+	struct iio_dev *indio_dev;
+	struct vf610_dac *info;
+	struct resource *mem;
+	int ret;
+
+	indio_dev = devm_iio_device_alloc(&pdev->dev,
+					sizeof(struct vf610_dac));
+	if (!indio_dev) {
+		dev_err(&pdev->dev, "Failed allocating iio device\n");
+		return -ENOMEM;
+	}
+
+	info = iio_priv(indio_dev);
+	info->dev = &pdev->dev;
+
+	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	info->regs = devm_ioremap_resource(&pdev->dev, mem);
+	if (IS_ERR(info->regs))
+		return PTR_ERR(info->regs);
+
+	info->clk = devm_clk_get(&pdev->dev, "dac");
+	if (IS_ERR(info->clk)) {
+		dev_err(&pdev->dev, "Failed getting clock, err = %ld\n",
+			PTR_ERR(info->clk));
+		return PTR_ERR(info->clk);
+	}
+
+	platform_set_drvdata(pdev, indio_dev);
+
+	indio_dev->name = dev_name(&pdev->dev);
+	indio_dev->dev.parent = &pdev->dev;
+	indio_dev->dev.of_node = pdev->dev.of_node;
+	indio_dev->info = &vf610_dac_iio_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->channels = vf610_dac_iio_channels;
+	indio_dev->num_channels = ARRAY_SIZE(vf610_dac_iio_channels);
+
+	ret = clk_prepare_enable(info->clk);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"Could not prepare or enable the clock\n");
+		return ret;
+	}
+
+	vf610_dac_init(info);
+
+	ret = iio_device_register(indio_dev);
+	if (ret) {
+		dev_err(&pdev->dev, "Couldn't register the device\n");
+		goto error_iio_device_register;
+	}
+
+	return 0;
+
+error_iio_device_register:
+	clk_disable_unprepare(info->clk);
+
+	return ret;
+}
+
+static int vf610_dac_remove(struct platform_device *pdev)
+{
+	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+	struct vf610_dac *info = iio_priv(indio_dev);
+
+	vf610_dac_exit(info);
+	iio_device_unregister(indio_dev);
+	clk_disable_unprepare(info->clk);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int vf610_dac_suspend(struct device *dev)
+{
+	struct iio_dev *indio_dev = dev_get_drvdata(dev);
+	struct vf610_dac *info = iio_priv(indio_dev);
+
+	vf610_dac_exit(info);
+	clk_disable_unprepare(info->clk);
+
+	return 0;
+}
+
+static int vf610_dac_resume(struct device *dev)
+{
+	struct iio_dev *indio_dev = dev_get_drvdata(dev);
+	struct vf610_dac *info = iio_priv(indio_dev);
+	int ret;
+
+	ret = clk_prepare_enable(info->clk);
+	if (ret)
+		return ret;
+
+	vf610_dac_init(info);
+
+	return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(vf610_dac_pm_ops, vf610_dac_suspend, vf610_dac_resume);
+
+static struct platform_driver vf610_dac_driver = {
+	.probe          = vf610_dac_probe,
+	.remove         = vf610_dac_remove,
+	.driver         = {
+		.name   = "vf610-dac",
+		.of_match_table = vf610_dac_match,
+		.pm     = &vf610_dac_pm_ops,
+	},
+};
+module_platform_driver(vf610_dac_driver);
+
+MODULE_AUTHOR("Sanchayan Maity <sanchayan.maity at toradex.com");
+MODULE_DESCRIPTION("Freescale VF610 DAC driver");
+MODULE_LICENSE("GPL v2");
-- 
2.7.1



From khalasa at piap.pl  Sun Feb 14 23:02:20 2016
From: khalasa at piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=)
Date: Mon, 15 Feb 2016 08:02:20 +0100
Subject: [PATCH] ARM: drop unused Makefile.boot of Multiplatform SoCs
In-Reply-To: <1454693808-13081-1-git-send-email-yamada.masahiro@socionext.com>
 (Masahiro Yamada's message of "Sat, 6 Feb 2016 02:36:48 +0900")
References: <1454693808-13081-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <m3r3gebgn7.fsf@t19.piap.pl>

Masahiro Yamada <yamada.masahiro at socionext.com> writes:

> The variable "MACHINE" is empty if CONFIG_ARCH_MULTIPLATFORM=y,
> so these Makefile.boot files are never included.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
> ---
>
>  arch/arm/mach-cns3xxx/Makefile.boot    | 3 ---

Acked-by: Krzysztof Ha?asa <khalasa at piap.pl>
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland


From khalasa at piap.pl  Sun Feb 14 23:05:54 2016
From: khalasa at piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=)
Date: Mon, 15 Feb 2016 08:05:54 +0100
Subject: [PATCH 1/3] ARM: ixp4xx: use normal prototype for {read, write}s{b,
 w, l}
In-Reply-To: <1454689262-613421-1-git-send-email-arnd@arndb.de> (Arnd
 Bergmann's message of "Fri, 5 Feb 2016 17:20:48 +0100")
References: <1454689262-613421-1-git-send-email-arnd@arndb.de>
Message-ID: <m3mvr2bgh9.fsf@t19.piap.pl>

Arnd Bergmann <arnd at arndb.de> writes:

> ixp4xx defines the arguments to its __indirect_writesb() and other
> functions as pointers to fixed-size data. This is not necessarily
> wrong, and it works most of the time, but it causes warnings in
> at least one driver:
>
> drivers/net/ethernet/smsc/smc91x.c: In function 'smc_rcv':
> drivers/net/ethernet/smsc/smc91x.c:495:21: error: passing argument 2 of '__indirect_readsw' from incompatible pointer type [-Werror=incompatible-pointer-types]
>    SMC_PULL_DATA(lp, data, packet_len - 4);
>
> All other definitions of the same functions pass void pointers,
> so doing the same here avoids the warnings.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/mach-ixp4xx/include/mach/io.h | 23 +++++++++++++++++------
>  1 file changed, 17 insertions(+), 6 deletions(-)

Acked-by: Krzysztof Ha?asa <khalasa at piap.pl>
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland


From khalasa at piap.pl  Sun Feb 14 23:07:35 2016
From: khalasa at piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=)
Date: Mon, 15 Feb 2016 08:07:35 +0100
Subject: [PATCH 2/3] ARM: ixp4xx: avoid warning about ioport_map() macro
 argument processing
In-Reply-To: <1454689262-613421-2-git-send-email-arnd@arndb.de> (Arnd
 Bergmann's message of "Fri, 5 Feb 2016 17:20:49 +0100")
References: <1454689262-613421-1-git-send-email-arnd@arndb.de>
 <1454689262-613421-2-git-send-email-arnd@arndb.de>
Message-ID: <m3io1qbgeg.fsf@t19.piap.pl>

Arnd Bergmann <arnd at arndb.de> writes:

> We get a harmless compiler warning when building the cs89x0 driver
> for ixp4xx:
>
> drivers/net/ethernet/cirrus/cs89x0.c: In function 'cs89x0_ioport_probe':
> drivers/net/ethernet/cirrus/cs89x0.c:1602:28: warning: suggest parentheses around '+' in operand of '&' [-Wparentheses]
>   io_mem = ioport_map(ioport & ~3, NETCARD_IO_EXTENT);
>
> Simply adding parentheses in the macro avoids the warning
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/mach-ixp4xx/include/mach/io.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Krzysztof Ha?asa <khalasa at piap.pl>
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland


From khalasa at piap.pl  Sun Feb 14 23:07:52 2016
From: khalasa at piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=)
Date: Mon, 15 Feb 2016 08:07:52 +0100
Subject: [PATCH 3/3] ARM: ixp4xx: move indirect I/O into common-pci.c
In-Reply-To: <1454689262-613421-3-git-send-email-arnd@arndb.de> (Arnd
 Bergmann's message of "Fri, 5 Feb 2016 17:20:50 +0100")
References: <1454689262-613421-1-git-send-email-arnd@arndb.de>
 <1454689262-613421-3-git-send-email-arnd@arndb.de>
Message-ID: <m3egcebgdz.fsf@t19.piap.pl>

Arnd Bergmann <arnd at arndb.de> writes:

> The pointer comparison in is_pci_memory() confuses gcc, so it
> starts throwing bogus warnings about the use of possibly uninitialized
> variables:
>
> drivers/ata/ahci_qoriq.c: In function 'ahci_qoriq_hardreset':
> arch/arm/include/asm/io.h:101:2: error: 'px_is' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> drivers/crypto/ixp4xx_crypto.c: In function 'aead_perform':
> drivers/crypto/ixp4xx_crypto.c:1072:5: error: 'lastlen' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> The code is that gets warned about is correct, and we should not warn
> about this. Moving the code into a .c file makes the object files
> smaller and avoids the warnings.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/mach-ixp4xx/common-pci.c      | 98 ++++++++++++++++++++++++++++++++++
>  arch/arm/mach-ixp4xx/include/mach/io.h | 95 +++-----------------------------
>  2 files changed, 104 insertions(+), 89 deletions(-)

Acked-by: Krzysztof Ha?asa <khalasa at piap.pl>
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland


From ard.biesheuvel at linaro.org  Sun Feb 14 23:13:29 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 15 Feb 2016 08:13:29 +0100
Subject: linux-next: arm64 no longer boots with initramfs in qemu tests
In-Reply-To: <20160214221242.GA23489@roeck-us.net>
References: <20160214221242.GA23489@roeck-us.net>
Message-ID: <CAKv+Gu-dyLKo2y503Lj7Uc7qwO5-b9LyZNAeV0guse86uuAqxg@mail.gmail.com>

On 14 February 2016 at 23:12, Guenter Roeck <linux at roeck-us.net> wrote:
> Hi,
>
> my qemu tests for arm64 fail to boot in linux-next, starting with next-20160209.
> Primary error is
>
>   VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
>   Please append a correct "root=" boot option; here are the available partitions:
>   Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
>
> but that doesn't mean much since I try to boot an initramfs.
>
> A bisect attempt points to 'arm64: move kernel image to base of vmalloc area',
> but that doesn't really help since some of the bisect attempts fail to build
> with linker errors. Just for reference, a bisect log is attached.
>
> Comparing console logs between 4.5-rc3 and next-20160212, one key difference is
> that the kernel now displays
>
>   Moving initrd from [88000000-889ae7ff] to [5d251000-5dbff7ff]
>
> which was not the case before. Turns out RAM ends at 60000000, so the address
> appears to be a bit odd (4.5-rc3 shows initramfs at a lower address).
> My qemu test runs with 512MB RAM. If I increase the RAM size to 2G,
> the "Moving" message is no longer displayed. However, I still get the same
> error.
>
> Qemu command line:
>
> qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt \
>         -nographic -smp 1 -m 512 -kernel arch/arm64/boot/Image \
>         -initrd rootfs.arm64.cpio -append "console=ttyAMA0"
>
> Configuration is defconfig. Initramfs can be copied from
>         https://github.com/groeck/linux-build-test/blob/master/rootfs/arm64/rootfs.arm64.cpio
>
> Please let me know if there is anything I can do to help tracking down
> the problem.
>

Hi Guenter,

Thanks for the detailed analysis. This looks like the same issue I fixed here:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/477645

Regards,
Ard.


From horms at verge.net.au  Sun Feb 14 23:18:18 2016
From: horms at verge.net.au (Simon Horman)
Date: Mon, 15 Feb 2016 16:18:18 +0900
Subject: [PATCH 01/68] ARM: dts: gose: Add GPIO keys to DT
In-Reply-To: <CAMuHMdVefum3YbaxhMX_0hHrmTFYU-pWYZTwSUveQDLFArLdYw@mail.gmail.com>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
 <d7d5974b156e2ef7436483de00ccada5987c9d31.1455303422.git.horms+renesas@verge.net.au>
 <CAMuHMdVefum3YbaxhMX_0hHrmTFYU-pWYZTwSUveQDLFArLdYw@mail.gmail.com>
Message-ID: <20160215071817.GA4528@verge.net.au>

On Sat, Feb 13, 2016 at 09:23:47PM +0100, Geert Uytterhoeven wrote:
> On Fri, Feb 12, 2016 at 8:04 PM, Simon Horman
> <horms+renesas at verge.net.au> wrote:
> > Instantiate the GPIO keys in the gose device tree.
> >
> > Based on similar work for the koelsch board by Laurent Pinchart.
> >
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> > Tested-by: Magnus Damm <damm+renesas at opensource.se>
> > ---
> >  arch/arm/boot/dts/r8a7793-gose.dts | 82 ++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 82 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
> > index baa59fe84298..ccbc1c66cc6c 100644
> > --- a/arch/arm/boot/dts/r8a7793-gose.dts
> > +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> > @@ -31,6 +31,88 @@
> >                 device_type = "memory";
> >                 reg = <0 0x40000000 0 0x40000000>;
> >         };
> > +
> > +       gpio-keys {
> > +               compatible = "gpio-keys";
> > +
> > +               key-1 {
> > +                       gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
> > +                       linux,code = <KEY_1>;
> > +                       label = "SW2-1";
> > +                       gpio-key,wakeup;
> 
> In the mean time, "gpio-key,wakeup" has been deprecated in favor of
> "wakeup-source".

Is the change just a matter of s/gpio-key,wakeup/wakeup-source/ ?
If so I'll sort things out.


From xinliang.liu at linaro.org  Sun Feb 14 23:30:10 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Mon, 15 Feb 2016 15:30:10 +0800
Subject: [PATCH v4 01/11] drm/hisilicon: Add device tree binding for
 hi6220 display subsystem
In-Reply-To: <20160208201246.GA17459@rob-hp-laptop>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
 <1454729098-79807-2-git-send-email-xinliang.liu@linaro.org>
 <20160208201246.GA17459@rob-hp-laptop>
Message-ID: <CAGd==07aNFtr6yEgULxg+7WLbqq7GAAWng4GV=oohSnM5fP45A@mail.gmail.com>

On 9 February 2016 at 04:12, Rob Herring <robh at kernel.org> wrote:
> On Sat, Feb 06, 2016 at 11:24:48AM +0800, Xinliang Liu wrote:
>> Add ADE display controller binding doc.
>> Add DesignWare DSI Host Controller v1.20a binding doc.
>
> One comment, otherwise:
>
> Acked-by: Rob Herring <robh at kernel.org>
>
>> +Board specific:
>> +     &dsi {
>> +             status = "ok";
>> +
>> +             ports {
>> +                     /* 1 for output port */
>> +                     port at 1 {
>> +                             #address-cells = <1>;
>> +                             #size-cells = <0>;
>> +                             reg = <1>;
>> +
>> +                             /* 0 for bridge, other value for panel */
>
> The endpoint address would not change based on bridge or panel. So you
> can drop the unit address here.

yes, I can drop the unit address, since it only support bridge in the
DSI code currently, right?

One question: How to distinguish panel and bridge endpoint?  I am
thinking to support panel now.

Thanks,
-xinliang

>
>> +                             dsi_out0: endpoint at 0 {
>> +                                     reg = <0>;
>> +                                     remote-endpoint = <&adv7533_in>;
>> +                             };
>> +                     };
>> +             };
>> +     };


From wxt at rock-chips.com  Sun Feb 14 23:33:25 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Mon, 15 Feb 2016 15:33:25 +0800
Subject: [RESEND PATCH 0/8] Support and fixes the rk3228 SoCS for thermal
Message-ID: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>

Hello Eduardo, Heiko, Michael & Stephen:

This series pacthes to support the rk3228 SoCs thermal.

They have the following patches to work on rk3228 SoCs.

1a6f334 clk: rockchip: add id of the tsadc clock found on rk3228 SoCs
8cf2d1b clk: rockchip: add the tsadc clocks found on rk3228 SoCs
bd2720c thermal: rockchip: fix a impossible condition caused by the warning
df9c1bd thermal: rockchip: fix calculation error for code_to_temp
fb11fbd thermal: rockchip: the rename compatibles for rockchip SoCs
b907b75 thermal: rockchip: fix the tsadc sequence output on rk3228/rk3399
bdc79c0 ARM: dts: rockchip: add the thermal main info found on rk3228
22ea3c3 ARM: dts: rockchip: enable the tsadc for rk3228 evb

Verified on https://github.com/Caesar-github/rockchip/tree/rk3228-thermal-tests.
This series patches are based on
Linux version 4.5.0-rc4+ (wxt at ubuntu) (...) (GCC) ) #204 SMP Mon Feb 15 14:12:16 CST 6

Tests:

1) Get the temperature in every 500ms.

while true;do ls >/dev/null; done&
while true; do grep "" /sys/class/thermal/thermal_zone0/temp; sleep
.5; done &

2) critical tests
**
/sys/devices/virtual/thermal/thermal_zone0 # cat temp
33000
/sys/devices/virtual/thermal/thermal_zone0 # echo 30000 > trip_point_2_temp
[  988.114192] thermal thermal_zone0: critical temperature reached(33 C),shutting down
...
shutdown
-
**via modify the dts over-temperature protectiong value to trigger otp pin.

Verified on rk3228/rk3288/rk3368 SoCs.
---

Hi Michael,Stephen
PATCH[1/8-2/8]:
Add the tsadc needed clocks for rk3228 SoCs

Hi Eduardo,
PATCH[3/8]:
To fix a build warning came from Dan Carpenter report smatch check,
Thanks.
As the patch exists in https://patchwork.kernel.org/patch/7757311/

PATCH[4/8]:
fix calculation error for code_to_temp
That's a error since the copy causes.

PATCH[5/8]:
the rename compatibles for rockchip SoCs
As the more and more rockchip SOCs are supported in thermal driver. this pacth
supposed to be compatible for better.

PATCH[6/8]:
fix the tsadc sequence output on rk3228/rk3399
Fixes the tsadc sequence output since the rk3228/rk3399 SoCs design.

Hi Heiko,
PATCH[7/8-8/8]: thermal DTS
1) add the thermal main info found on rk3228
2) enable the tsadc for rk3228 evb

I'd appreciate if someone have free time to review that. :)



Caesar Wang (7):
  clk: rockchip: add id of the tsadc clock found on rk3228 SoCs
  clk: rockchip: add the tsadc clocks found on rk3228 SoCs
  thermal: rockchip: fix a impossible condition caused by the warning
  thermal: rockchip: the rename compatibles for rockchip SoCs
  thermal: rockchip: fix the tsadc sequence output on rk3228/rk3399
  ARM: dts: rockchip: add the thermal main info found on rk3228
  ARM: dts: rockchip: enable the tsadc for rk3228 evb

Elaine Zhang (1):
  thermal: rockchip: fix calculation error for code_to_temp

 arch/arm/boot/dts/rk3228-evb.dts       |   7 +
 arch/arm/boot/dts/rk3228.dtsi          |  69 ++++++++++
 drivers/clk/rockchip/clk-rk3228.c      |   4 +-
 drivers/thermal/rockchip_thermal.c     | 239 +++++++++++++++++++--------------
 include/dt-bindings/clock/rk3228-cru.h |   2 +
 5 files changed, 216 insertions(+), 105 deletions(-)

-- 
1.9.1



From khalasa at piap.pl  Sun Feb 14 23:33:37 2016
From: khalasa at piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=)
Date: Mon, 15 Feb 2016 08:33:37 +0100
Subject: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
In-Reply-To: <2202960.HHsdV23CYi@wuerfel> (Arnd Bergmann's message of "Fri, 29
 Jan 2016 18:06:58 +0100")
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <1453997843-3489728-3-git-send-email-arnd@arndb.de>
 <m3a8nogy0u.fsf@t19.piap.pl> <2202960.HHsdV23CYi@wuerfel>
Message-ID: <m3a8n2bf72.fsf@t19.piap.pl>

Arnd Bergmann <arnd at arndb.de> writes:

>> Anyway, I think readl()/writel() do the right thing: in BE mode they
>> swap PCI accesses and don't swap normal registers, in LE mode nothing is
>> swapped.
>
> This seems to be true when CONFIG_IXP4XX_INDIRECT_PCI is set, but
> not otherwise. For the indirect variant, writel() is a __raw_writel()
> without barrier or byteswap on non-PCI memory, while with that
> option disabled, we use the standard implementation that has both
> a byteswap and a barrier.
>
> According to your description, that would mean the version without
> indirect PCI access is broken and it appears to have been that way
> since before the start of git history in 2.6.12.
>
> It's possible that nobody cared because all drivers for non-PCI
> devices on ixp4xx (the on chip ones) just use __raw_readl or
> direct pointer references.

Well, it is possible. I recall I probably used __raw_* instead of
readl()/writel() in qmgr/npe/Ethernet drivers for this very reason.

I think Direct pointer references are only used for locations in RAM
(DMA buffers), they have their own share of problems because the
peripherals are always big endian.

I think I still have an early IXP425 board with UDC connector so I will
try to dig it up and test this code.

I wonder if we should switch the driver to use __raw_*, too. The problem
is almost nobody uses UDC with this CPU.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland


From wxt at rock-chips.com  Sun Feb 14 23:33:26 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Mon, 15 Feb 2016 15:33:26 +0800
Subject: [RESEND PATCH 1/8] clk: rockchip: add id of the tsadc clock found on
 rk3228 SoCs
In-Reply-To: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
References: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1455521613-27340-2-git-send-email-wxt@rock-chips.com>

This patch adds 'SCLK_TSADC' and 'PCLK_TSADC' id found on rk3228 SoCs.
That will be needed by TSADC controller.

Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

 include/dt-bindings/clock/rk3228-cru.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/dt-bindings/clock/rk3228-cru.h b/include/dt-bindings/clock/rk3228-cru.h
index a78dd89..cd2e06b 100644
--- a/include/dt-bindings/clock/rk3228-cru.h
+++ b/include/dt-bindings/clock/rk3228-cru.h
@@ -29,6 +29,7 @@
 #define SCLK_SDMMC		68
 #define SCLK_SDIO		69
 #define SCLK_EMMC		71
+#define SCLK_TSADC		72
 #define SCLK_UART0		77
 #define SCLK_UART1		78
 #define SCLK_UART2		79
@@ -68,6 +69,7 @@
 #define PCLK_UART0		341
 #define PCLK_UART1		342
 #define PCLK_UART2		343
+#define PCLK_TSADC		344
 #define PCLK_PWM		350
 #define PCLK_TIMER		353
 #define PCLK_PERI		363
-- 
1.9.1



From wxt at rock-chips.com  Sun Feb 14 23:33:27 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Mon, 15 Feb 2016 15:33:27 +0800
Subject: [RESEND PATCH 2/8] clk: rockchip: add the tsadc clocks found on
 rk3228 SoCs
In-Reply-To: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
References: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1455521613-27340-3-git-send-email-wxt@rock-chips.com>

This patch adds the needed clocks for rk3228 tsadc.

Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

 drivers/clk/rockchip/clk-rk3228.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3228.c b/drivers/clk/rockchip/clk-rk3228.c
index c515915..ac014b9 100644
--- a/drivers/clk/rockchip/clk-rk3228.c
+++ b/drivers/clk/rockchip/clk-rk3228.c
@@ -424,7 +424,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[] __initdata = {
 	GATE(0, "sclk_otgphy1", "xin24m", 0,
 			RK2928_CLKGATE_CON(1), 6, GFLAGS),
 
-	COMPOSITE_NOMUX(0, "sclk_tsadc", "xin24m", 0,
+	COMPOSITE_NOMUX(SCLK_TSADC, "sclk_tsadc", "xin24m", 0,
 			RK2928_CLKSEL_CON(24), 6, 10, DFLAGS,
 			RK2928_CLKGATE_CON(2), 8, GFLAGS),
 
@@ -584,7 +584,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[] __initdata = {
 	GATE(PCLK_UART0, "pclk_uart0", "pclk_cpu", 0, RK2928_CLKGATE_CON(9), 12, GFLAGS),
 	GATE(PCLK_UART1, "pclk_uart1", "pclk_cpu", 0, RK2928_CLKGATE_CON(9), 13, GFLAGS),
 	GATE(PCLK_UART2, "pclk_uart2", "pclk_cpu", 0, RK2928_CLKGATE_CON(9), 14, GFLAGS),
-	GATE(0, "pclk_tsadc", "pclk_cpu", 0, RK2928_CLKGATE_CON(9), 15, GFLAGS),
+	GATE(PCLK_TSADC, "pclk_tsadc", "pclk_cpu", 0, RK2928_CLKGATE_CON(9), 15, GFLAGS),
 	GATE(PCLK_GRF, "pclk_grf", "pclk_cpu", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(10), 0, GFLAGS),
 	GATE(0, "pclk_cru", "pclk_cpu", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(10), 1, GFLAGS),
 	GATE(0, "pclk_sgrf", "pclk_cpu", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(10), 2, GFLAGS),
-- 
1.9.1



From wxt at rock-chips.com  Sun Feb 14 23:33:28 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Mon, 15 Feb 2016 15:33:28 +0800
Subject: [RESEND PATCH 3/8] thermal: rockchip: fix a impossible condition
 caused by the warning
In-Reply-To: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
References: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1455521613-27340-4-git-send-email-wxt@rock-chips.com>

As the Dan report the smatch check the thermal driver warning:
drivers/thermal/rockchip_thermal.c:551 rockchip_configure_from_dt()
warn: impossible condition '(thermal->tshut_temp > ((~0 >> 1))) =>
(s32min-s32max > s32max)'

Although The shut_temp read from DT is u32,the temperature is currently
represented as int not long in the thermal driver.
Let's change to make shut_temp instead of the thermal->tshut_temp for
the condition.

Fixes: commit 437df2172e8d
("thermal: rockchip: consistently use int for temperatures")

Reported-by: Dan Carpenter <dan.carpenter at oracle.com>
Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

 drivers/thermal/rockchip_thermal.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c
index b58e3fb..433085a 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -693,15 +693,14 @@ static int rockchip_configure_from_dt(struct device *dev,
 			 thermal->chip->tshut_temp);
 		thermal->tshut_temp = thermal->chip->tshut_temp;
 	} else {
+		if (shut_temp > INT_MAX) {
+			dev_err(dev, "Invalid tshut temperature specified: %d\n",
+				shut_temp);
+			return -ERANGE;
+		}
 		thermal->tshut_temp = shut_temp;
 	}
 
-	if (thermal->tshut_temp > INT_MAX) {
-		dev_err(dev, "Invalid tshut temperature specified: %d\n",
-			thermal->tshut_temp);
-		return -ERANGE;
-	}
-
 	if (of_property_read_u32(np, "rockchip,hw-tshut-mode", &tshut_mode)) {
 		dev_warn(dev,
 			 "Missing tshut mode property, using default (%s)\n",
-- 
1.9.1



From wxt at rock-chips.com  Sun Feb 14 23:33:29 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Mon, 15 Feb 2016 15:33:29 +0800
Subject: [RESEND PATCH 4/8] thermal: rockchip: fix calculation error for
 code_to_temp
In-Reply-To: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
References: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1455521613-27340-5-git-send-email-wxt@rock-chips.com>

From: Elaine Zhang <zhangqing at rock-chips.com>

the calculation use a global table, not their own table.
so adapt the table to the correct one.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

 drivers/thermal/rockchip_thermal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c
index 433085a..5c58d48 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -411,7 +411,7 @@ static int rk_tsadcv2_code_to_temp(struct chip_tsadc_table table, u32 code,
 	 * temperature between 2 table entries is linear and interpolate
 	 * to produce less granular result.
 	 */
-	num = table.id[mid].temp - v2_code_table[mid - 1].temp;
+	num = table.id[mid].temp - table.id[mid - 1].temp;
 	num *= abs(table.id[mid - 1].code - code);
 	denom = abs(table.id[mid - 1].code - table.id[mid].code);
 	*temp = table.id[mid - 1].temp + (num / denom);
-- 
1.9.1



From wxt at rock-chips.com  Sun Feb 14 23:33:30 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Mon, 15 Feb 2016 15:33:30 +0800
Subject: [RESEND PATCH 5/8] thermal: rockchip: the rename compatibles for
 rockchip SoCs
In-Reply-To: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
References: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1455521613-27340-6-git-send-email-wxt@rock-chips.com>

This patch renames to be more adapter compatibles since more and more
SoCs are supported in thermal driver.

Reported-by: Huang,Tao <huangtao at rock-chips.com>
Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

 drivers/thermal/rockchip_thermal.c | 50 +++++++++++++++++++++-----------------
 1 file changed, 28 insertions(+), 22 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c
index 5c58d48..9cdef62 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -58,8 +58,8 @@ enum sensor_id {
 
 /**
  * The conversion table has the adc value and temperature.
- * ADC_DECREMENT: the adc value is of diminishing.(e.g. v2_code_table)
- * ADC_INCREMENT: the adc value is incremental.(e.g. v3_code_table)
+ * ADC_DECREMENT: the adc value is of diminishing.(e.g. rk3288_code_table)
+ * ADC_INCREMENT: the adc value is incremental.(e.g. rk3368_code_table)
  */
 enum adc_sort_mode {
 	ADC_DECREMENT = 0,
@@ -135,7 +135,13 @@ struct rockchip_thermal_data {
 	enum tshut_polarity tshut_polarity;
 };
 
-/* TSADC Sensor info define: */
+/**
+ * TSADC Sensor Register description:
+ *
+ * TSADCV2_* are used for RK3288 SoCs, the other chips can reuse it.
+ * TSADCV3_* are used for newer SoCs than RK3288. (e.g: RK3228, RK3399)
+ *
+ */
 #define TSADCV2_AUTO_CON			0x04
 #define TSADCV2_INT_EN				0x08
 #define TSADCV2_INT_PD				0x0c
@@ -154,8 +160,8 @@ struct rockchip_thermal_data {
 #define TSADCV2_SHUT_2GPIO_SRC_EN(chn)		BIT(4 + (chn))
 #define TSADCV2_SHUT_2CRU_SRC_EN(chn)		BIT(8 + (chn))
 
-#define TSADCV1_INT_PD_CLEAR_MASK		~BIT(16)
 #define TSADCV2_INT_PD_CLEAR_MASK		~BIT(8)
+#define TSADCV3_INT_PD_CLEAR_MASK		~BIT(16)
 
 #define TSADCV2_DATA_MASK			0xfff
 #define TSADCV3_DATA_MASK			0x3ff
@@ -177,7 +183,7 @@ struct tsadc_table {
  * linearly interpolated.
  * Code to Temperature mapping should be updated based on sillcon results.
  */
-static const struct tsadc_table v1_code_table[] = {
+static const struct tsadc_table rk3228_code_table[] = {
 	{TSADCV3_DATA_MASK, -40000},
 	{436, -40000},
 	{431, -35000},
@@ -215,7 +221,7 @@ static const struct tsadc_table v1_code_table[] = {
 	{264, 125000},
 };
 
-static const struct tsadc_table v2_code_table[] = {
+static const struct tsadc_table rk3288_code_table[] = {
 	{TSADCV2_DATA_MASK, -40000},
 	{3800, -40000},
 	{3792, -35000},
@@ -253,7 +259,7 @@ static const struct tsadc_table v2_code_table[] = {
 	{3421, 125000},
 };
 
-static const struct tsadc_table v3_code_table[] = {
+static const struct tsadc_table rk3368_code_table[] = {
 	{0, -40000},
 	{106, -40000},
 	{108, -35000},
@@ -292,7 +298,7 @@ static const struct tsadc_table v3_code_table[] = {
 	{TSADCV3_DATA_MASK, 125000},
 };
 
-static const struct tsadc_table v4_code_table[] = {
+static const struct tsadc_table rk3399_code_table[] = {
 	{TSADCV3_DATA_MASK, -40000},
 	{431, -40000},
 	{426, -35000},
@@ -453,20 +459,20 @@ static void rk_tsadcv2_initialize(void __iomem *regs,
 		       regs + TSADCV2_HIGHT_TSHUT_DEBOUNCE);
 }
 
-static void rk_tsadcv1_irq_ack(void __iomem *regs)
+static void rk_tsadcv2_irq_ack(void __iomem *regs)
 {
 	u32 val;
 
 	val = readl_relaxed(regs + TSADCV2_INT_PD);
-	writel_relaxed(val & TSADCV1_INT_PD_CLEAR_MASK, regs + TSADCV2_INT_PD);
+	writel_relaxed(val & TSADCV2_INT_PD_CLEAR_MASK, regs + TSADCV2_INT_PD);
 }
 
-static void rk_tsadcv2_irq_ack(void __iomem *regs)
+static void rk_tsadcv3_irq_ack(void __iomem *regs)
 {
 	u32 val;
 
 	val = readl_relaxed(regs + TSADCV2_INT_PD);
-	writel_relaxed(val & TSADCV2_INT_PD_CLEAR_MASK, regs + TSADCV2_INT_PD);
+	writel_relaxed(val & TSADCV3_INT_PD_CLEAR_MASK, regs + TSADCV2_INT_PD);
 }
 
 static void rk_tsadcv2_control(void __iomem *regs, bool enable)
@@ -531,15 +537,15 @@ static const struct rockchip_tsadc_chip rk3228_tsadc_data = {
 	.tshut_temp = 95000,
 
 	.initialize = rk_tsadcv2_initialize,
-	.irq_ack = rk_tsadcv1_irq_ack,
+	.irq_ack = rk_tsadcv3_irq_ack,
 	.control = rk_tsadcv2_control,
 	.get_temp = rk_tsadcv2_get_temp,
 	.set_tshut_temp = rk_tsadcv2_tshut_temp,
 	.set_tshut_mode = rk_tsadcv2_tshut_mode,
 
 	.table = {
-		.id = v1_code_table,
-		.length = ARRAY_SIZE(v1_code_table),
+		.id = rk3228_code_table,
+		.length = ARRAY_SIZE(rk3228_code_table),
 		.data_mask = TSADCV3_DATA_MASK,
 		.mode = ADC_DECREMENT,
 	},
@@ -562,8 +568,8 @@ static const struct rockchip_tsadc_chip rk3288_tsadc_data = {
 	.set_tshut_mode = rk_tsadcv2_tshut_mode,
 
 	.table = {
-		.id = v2_code_table,
-		.length = ARRAY_SIZE(v2_code_table),
+		.id = rk3288_code_table,
+		.length = ARRAY_SIZE(rk3288_code_table),
 		.data_mask = TSADCV2_DATA_MASK,
 		.mode = ADC_DECREMENT,
 	},
@@ -586,8 +592,8 @@ static const struct rockchip_tsadc_chip rk3368_tsadc_data = {
 	.set_tshut_mode = rk_tsadcv2_tshut_mode,
 
 	.table = {
-		.id = v3_code_table,
-		.length = ARRAY_SIZE(v3_code_table),
+		.id = rk3368_code_table,
+		.length = ARRAY_SIZE(rk3368_code_table),
 		.data_mask = TSADCV3_DATA_MASK,
 		.mode = ADC_INCREMENT,
 	},
@@ -603,15 +609,15 @@ static const struct rockchip_tsadc_chip rk3399_tsadc_data = {
 	.tshut_temp = 95000,
 
 	.initialize = rk_tsadcv2_initialize,
-	.irq_ack = rk_tsadcv1_irq_ack,
+	.irq_ack = rk_tsadcv3_irq_ack,
 	.control = rk_tsadcv2_control,
 	.get_temp = rk_tsadcv2_get_temp,
 	.set_tshut_temp = rk_tsadcv2_tshut_temp,
 	.set_tshut_mode = rk_tsadcv2_tshut_mode,
 
 	.table = {
-		.id = v4_code_table,
-		.length = ARRAY_SIZE(v4_code_table),
+		.id = rk3399_code_table,
+		.length = ARRAY_SIZE(rk3399_code_table),
 		.data_mask = TSADCV3_DATA_MASK,
 		.mode = ADC_DECREMENT,
 	},
-- 
1.9.1



From wxt at rock-chips.com  Sun Feb 14 23:33:32 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Mon, 15 Feb 2016 15:33:32 +0800
Subject: [RESEND PATCH 7/8] ARM: dts: rockchip: add the thermal main info
 found on rk3228
In-Reply-To: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
References: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1455521613-27340-8-git-send-email-wxt@rock-chips.com>

This patch adds the thermal needed main information for rk3228 SoCS.

Basically has the following content:

1) TSADC controller:
Add the needed attributes for rk3036 TSADC controller.

Especially for the TSHUT, in some cases if we are unable to shut it down
in orderly fashion (says: kernel is stuck holding a lock or similar), then
hardware TSHUT will reset it.
If the temperature is over 95C over a period of time the thermal shutdown
of the tsadc is invoked with can either reset the entire chip via the CRU,
or notify the PMIC via a GPIO. This should be set in the specific board.

2) Thermal zones:
Add the needed device mode for thermal generic framework.
Detail in Documentation/devicetree/bindings/thermal/thermal.txt.

Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

 arch/arm/boot/dts/rk3228.dtsi | 69 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/arch/arm/boot/dts/rk3228.dtsi b/arch/arm/boot/dts/rk3228.dtsi
index 119ff12..4084081 100644
--- a/arch/arm/boot/dts/rk3228.dtsi
+++ b/arch/arm/boot/dts/rk3228.dtsi
@@ -43,6 +43,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/pinctrl/rockchip.h>
 #include <dt-bindings/clock/rk3228-cru.h>
+#include <dt-bindings/thermal/thermal.h>
 #include "skeleton.dtsi"
 
 / {
@@ -69,6 +70,7 @@
 				/* KHz    uV */
 				 816000 1000000
 			>;
+			#cooling-cells = <2>; /* min followed by max */
 			clock-latency = <40000>;
 			clocks = <&cru ARMCLK>;
 		};
@@ -247,6 +249,63 @@
 		assigned-clock-rates = <594000000>;
 	};
 
+	thermal-zones {
+		cpu_thermal: cpu-thermal {
+			polling-delay-passive = <100>; /* milliseconds */
+			polling-delay = <5000>; /* milliseconds */
+
+			thermal-sensors = <&tsadc 0>;
+
+			trips {
+				cpu_alert0: cpu_alert0 {
+					temperature = <70000>; /* millicelsius */
+					hysteresis = <2000>; /* millicelsius */
+					type = "passive";
+				};
+				cpu_alert1: cpu_alert1 {
+					temperature = <75000>; /* millicelsius */
+					hysteresis = <2000>; /* millicelsius */
+					type = "passive";
+				};
+				cpu_crit: cpu_crit {
+					temperature = <90000>; /* millicelsius */
+					hysteresis = <2000>; /* millicelsius */
+					type = "critical";
+				};
+			};
+
+			cooling-maps {
+				map0 {
+					trip = <&cpu_alert0>;
+					cooling-device =
+						<&cpu0 THERMAL_NO_LIMIT 6>;
+				};
+				map1 {
+					trip = <&cpu_alert1>;
+					cooling-device =
+						<&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
+		};
+	};
+
+	tsadc: tsadc at 11150000 {
+		compatible = "rockchip,rk3228-tsadc";
+		reg = <0x11150000 0x100>;
+		interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_TSADC>, <&cru PCLK_TSADC>;
+		clock-names = "tsadc", "apb_pclk";
+		resets = <&cru SRST_TSADC>;
+		reset-names = "tsadc-apb";
+		pinctrl-names = "init", "default", "sleep";
+		pinctrl-0 = <&otp_gpio>;
+		pinctrl-1 = <&otp_out>;
+		pinctrl-2 = <&otp_gpio>;
+		#thermal-sensor-cells = <0>;
+		rockchip,hw-tshut-temp = <95000>;
+		status = "disabled";
+	};
+
 	emmc: dwmmc at 30020000 {
 		compatible = "rockchip,rk3288-dw-mshc";
 		reg = <0x30020000 0x4000>;
@@ -394,6 +453,16 @@
 			};
 		};
 
+		tsadc {
+			otp_gpio: otp-gpio {
+				rockchip,pins = <0 24 RK_FUNC_GPIO &pcfg_pull_none>;
+			};
+
+			otp_out: otp-out {
+				rockchip,pins = <0 24 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
 		uart0 {
 			uart0_xfer: uart0-xfer {
 				rockchip,pins = <2 26 RK_FUNC_1 &pcfg_pull_none>,
-- 
1.9.1



From wxt at rock-chips.com  Sun Feb 14 23:33:31 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Mon, 15 Feb 2016 15:33:31 +0800
Subject: [RESEND PATCH 6/8] thermal: rockchip: fix the tsadc sequence output
 on rk3228/rk3399
In-Reply-To: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
References: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1455521613-27340-7-git-send-email-wxt@rock-chips.com>

As the TRM says, add the tsadc_q_sel to control the temperature-code
sequence since the rk3228/rk3399 need set this bit (1024 - tsadc_q)
as output.

Fixes: commit
b0d7033 "thermal: rockchip: Support the RK3399 SoCs in thermal driver"
7b02a5e "thermal: rockchip: Support the RK3228 SoCs in thermal driver"

Reported-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Caesar Wang <wxt at rock-chips.com>
---

 drivers/thermal/rockchip_thermal.c | 176 +++++++++++++++++++++----------------
 1 file changed, 102 insertions(+), 74 deletions(-)

diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c
index 9cdef62..233a564 100644
--- a/drivers/thermal/rockchip_thermal.c
+++ b/drivers/thermal/rockchip_thermal.c
@@ -155,6 +155,13 @@ struct rockchip_thermal_data {
 #define TSADCV2_AUTO_EN				BIT(0)
 #define TSADCV2_AUTO_SRC_EN(chn)		BIT(4 + (chn))
 #define TSADCV2_AUTO_TSHUT_POLARITY_HIGH	BIT(8)
+/**
+ * TSADCV1_AUTO_Q_SEL_EN:
+ * whether select (1024 - tsadc_q) as output
+ * 1'b0:use tsadc_q as output(temperature-code is rising sequence)
+ * 1'b1:use(1024 - tsadc_q) as output (temperature-code is falling sequence)
+ */
+#define TSADCV3_AUTO_Q_SEL_EN			BIT(1)
 
 #define TSADCV2_INT_SRC_EN(chn)			BIT(chn)
 #define TSADCV2_SHUT_2GPIO_SRC_EN(chn)		BIT(4 + (chn))
@@ -184,41 +191,42 @@ struct tsadc_table {
  * Code to Temperature mapping should be updated based on sillcon results.
  */
 static const struct tsadc_table rk3228_code_table[] = {
-	{TSADCV3_DATA_MASK, -40000},
-	{436, -40000},
-	{431, -35000},
-	{426, -30000},
-	{421, -25000},
-	{416, -20000},
-	{411, -15000},
-	{406, -10000},
-	{401, -5000},
-	{395, 0},
-	{390, 5000},
-	{385, 10000},
-	{380, 15000},
-	{375, 20000},
-	{370, 25000},
-	{364, 30000},
-	{359, 35000},
-	{354, 40000},
-	{349, 45000},
-	{343, 50000},
-	{338, 55000},
-	{333, 60000},
-	{328, 65000},
-	{322, 70000},
-	{317, 75000},
-	{312, 80000},
-	{307, 85000},
-	{301, 90000},
-	{296, 95000},
-	{291, 100000},
-	{286, 105000},
-	{280, 110000},
-	{275, 115000},
-	{270, 120000},
-	{264, 125000},
+	{0, -40000},
+	{588, -40000},
+	{593, -35000},
+	{598, -30000},
+	{603, -25000},
+	{608, -20000},
+	{613, -15000},
+	{618, -10000},
+	{623, -5000},
+	{629, 0},
+	{634, 5000},
+	{639, 10000},
+	{644, 15000},
+	{649, 20000},
+	{654, 25000},
+	{660, 30000},
+	{665, 35000},
+	{670, 40000},
+	{675, 45000},
+	{681, 50000},
+	{686, 55000},
+	{691, 60000},
+	{696, 65000},
+	{702, 70000},
+	{707, 75000},
+	{712, 80000},
+	{717, 85000},
+	{723, 90000},
+	{728, 95000},
+	{733, 100000},
+	{738, 105000},
+	{744, 110000},
+	{749, 115000},
+	{754, 120000},
+	{760, 125000},
+	{TSADCV2_DATA_MASK, 125000},
 };
 
 static const struct tsadc_table rk3288_code_table[] = {
@@ -299,41 +307,42 @@ static const struct tsadc_table rk3368_code_table[] = {
 };
 
 static const struct tsadc_table rk3399_code_table[] = {
-	{TSADCV3_DATA_MASK, -40000},
-	{431, -40000},
-	{426, -35000},
-	{421, -30000},
-	{415, -25000},
-	{410, -20000},
-	{405, -15000},
-	{399, -10000},
-	{394, -5000},
-	{389, 0},
-	{383, 5000},
-	{378, 10000},
-	{373, 15000},
-	{367, 20000},
-	{362, 25000},
-	{357, 30000},
-	{351, 35000},
-	{346, 40000},
-	{340, 45000},
-	{335, 50000},
-	{330, 55000},
-	{324, 60000},
-	{319, 65000},
-	{313, 70000},
-	{308, 75000},
-	{302, 80000},
-	{297, 85000},
-	{291, 90000},
-	{286, 95000},
-	{281, 100000},
-	{275, 105000},
-	{270, 110000},
-	{264, 115000},
-	{259, 120000},
-	{253, 125000},
+	{0, -40000},
+	{593, -40000},
+	{598, -35000},
+	{603, -30000},
+	{609, -25000},
+	{614, -20000},
+	{619, -15000},
+	{625, -10000},
+	{630, -5000},
+	{635, 0},
+	{641, 5000},
+	{646, 10000},
+	{651, 15000},
+	{657, 20000},
+	{662, 25000},
+	{667, 30000},
+	{673, 35000},
+	{678, 40000},
+	{684, 45000},
+	{689, 50000},
+	{694, 55000},
+	{700, 60000},
+	{705, 65000},
+	{711, 70000},
+	{716, 75000},
+	{722, 80000},
+	{727, 85000},
+	{733, 90000},
+	{738, 95000},
+	{743, 100000},
+	{749, 105000},
+	{754, 110000},
+	{760, 115000},
+	{765, 120000},
+	{771, 125000},
+	{TSADCV3_DATA_MASK, 125000},
 };
 
 static u32 rk_tsadcv2_temp_to_code(struct chip_tsadc_table table,
@@ -488,6 +497,25 @@ static void rk_tsadcv2_control(void __iomem *regs, bool enable)
 	writel_relaxed(val, regs + TSADCV2_AUTO_CON);
 }
 
+/**
+ * @rk_tsadcv3_control:
+ * TSADC controller works at auto mode, and some SoCs need set the tsadc_q_sel
+ * bit on TSADCV2_AUTO_CON[1]. The (1024 - tsadc_q) as output adc value if
+ * setting this bit to enable.
+ */
+static void rk_tsadcv3_control(void __iomem *regs, bool enable)
+{
+	u32 val;
+
+	val = readl_relaxed(regs + TSADCV2_AUTO_CON);
+	if (enable)
+		val |= TSADCV2_AUTO_EN | TSADCV3_AUTO_Q_SEL_EN;
+	else
+		val &= ~TSADCV2_AUTO_EN;
+
+	writel_relaxed(val, regs + TSADCV2_AUTO_CON);
+}
+
 static int rk_tsadcv2_get_temp(struct chip_tsadc_table table,
 			       int chn, void __iomem *regs, int *temp)
 {
@@ -538,7 +566,7 @@ static const struct rockchip_tsadc_chip rk3228_tsadc_data = {
 
 	.initialize = rk_tsadcv2_initialize,
 	.irq_ack = rk_tsadcv3_irq_ack,
-	.control = rk_tsadcv2_control,
+	.control = rk_tsadcv3_control,
 	.get_temp = rk_tsadcv2_get_temp,
 	.set_tshut_temp = rk_tsadcv2_tshut_temp,
 	.set_tshut_mode = rk_tsadcv2_tshut_mode,
@@ -547,7 +575,7 @@ static const struct rockchip_tsadc_chip rk3228_tsadc_data = {
 		.id = rk3228_code_table,
 		.length = ARRAY_SIZE(rk3228_code_table),
 		.data_mask = TSADCV3_DATA_MASK,
-		.mode = ADC_DECREMENT,
+		.mode = ADC_INCREMENT,
 	},
 };
 
@@ -610,7 +638,7 @@ static const struct rockchip_tsadc_chip rk3399_tsadc_data = {
 
 	.initialize = rk_tsadcv2_initialize,
 	.irq_ack = rk_tsadcv3_irq_ack,
-	.control = rk_tsadcv2_control,
+	.control = rk_tsadcv3_control,
 	.get_temp = rk_tsadcv2_get_temp,
 	.set_tshut_temp = rk_tsadcv2_tshut_temp,
 	.set_tshut_mode = rk_tsadcv2_tshut_mode,
@@ -619,7 +647,7 @@ static const struct rockchip_tsadc_chip rk3399_tsadc_data = {
 		.id = rk3399_code_table,
 		.length = ARRAY_SIZE(rk3399_code_table),
 		.data_mask = TSADCV3_DATA_MASK,
-		.mode = ADC_DECREMENT,
+		.mode = ADC_INCREMENT,
 	},
 };
 
-- 
1.9.1



From wxt at rock-chips.com  Sun Feb 14 23:33:33 2016
From: wxt at rock-chips.com (Caesar Wang)
Date: Mon, 15 Feb 2016 15:33:33 +0800
Subject: [RESEND PATCH 8/8] ARM: dts: rockchip: enable the tsadc for rk3228 evb
In-Reply-To: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
References: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1455521613-27340-9-git-send-email-wxt@rock-chips.com>

This patch enables the tsadc for rk3228 evb board.

The rk3228 evb board uses the CRU to reset the chip since it hasn't the
PMIC to connect it, and TSHUT is low active on evb board.

Signed-off-by: Caesar Wang <wxt at rock-chips.com>

---

 arch/arm/boot/dts/rk3228-evb.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/rk3228-evb.dts b/arch/arm/boot/dts/rk3228-evb.dts
index e3898b8..c75cc41 100644
--- a/arch/arm/boot/dts/rk3228-evb.dts
+++ b/arch/arm/boot/dts/rk3228-evb.dts
@@ -61,6 +61,13 @@
 	status = "okay";
 };
 
+&tsadc {
+	status = "okay";
+
+	rockchip,hw-tshut-mode = <0>; /* tshut mode 0:CRU 1:GPIO */
+	rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
+};
+
 &uart2 {
 	status = "okay";
 };
-- 
1.9.1



From thomas.petazzoni at free-electrons.com  Sun Feb 14 23:34:56 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Feb 2016 08:34:56 +0100
Subject: [PATCH 1/3] clk: unconditionally recurse into clk/mvebu/
In-Reply-To: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455521698-7905-2-git-send-email-thomas.petazzoni@free-electrons.com>

The drivers/clk/mvebu directory is only being built when
CONFIG_PLAT_ORION=y. As we are going to support additional mvebu
platforms in drivers/clk/mvebu, which don't have CONFIG_PLAT_ORION=y,
we need to recurse into this directory regardless of the value of
CONFIG_PLAT_ORION.

Since all files in drivers/clk/mvebu/ are already conditionally
compiled depending on various Kconfig options, we can recurse
unconditionally into drivers/clk/mvebu without any other change.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/clk/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index b038e36..e08bb0e 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -61,7 +61,7 @@ obj-$(CONFIG_ARCH_MEDIATEK)		+= mediatek/
 ifeq ($(CONFIG_COMMON_CLK), y)
 obj-$(CONFIG_ARCH_MMP)			+= mmp/
 endif
-obj-$(CONFIG_PLAT_ORION)		+= mvebu/
+obj-y					+= mvebu/
 obj-$(CONFIG_ARCH_MESON)		+= meson/
 obj-$(CONFIG_ARCH_MXS)			+= mxs/
 obj-$(CONFIG_MACH_PISTACHIO)		+= pistachio/
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Sun Feb 14 23:34:55 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Feb 2016 08:34:55 +0100
Subject: [PATCH 0/3] clk: mvebu: initial support for AP806 clocks
Message-ID: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hello,

The following set of patches add initial support for the main clocks
found in the AP806 hardware block, which is the central block used in
the newest Marvell 7K and 8K 64-bits processors.

Two new drivers are added, one for the so-called "core" clocks and one
for the "ring" clocks. The latter are child clocks from one of the
core clocks. The "core" clocks are fixed rate clocks, but their rate
is calculated from values in the Sample At Reset register.

The support for the Marvell 7K/8K platform (Device Tree, etc.) will be
submitted as a separate patch series.

Thanks!

Thomas

Thomas Petazzoni (3):
  clk: unconditionally recurse into clk/mvebu/
  clk: mvebu: add AP806 core clock driver
  clk: mvebu: add AP806 ring clock driver

 .../clock/mvebu-armada-ap806-core-clock.txt        |  33 ++++++
 .../clock/mvebu-armada-ap806-ring-clock.txt        |  32 ++++++
 drivers/clk/Makefile                               |   2 +-
 drivers/clk/mvebu/Kconfig                          |   6 ++
 drivers/clk/mvebu/Makefile                         |   3 +-
 drivers/clk/mvebu/ap806-core.c                     | 112 +++++++++++++++++++++
 drivers/clk/mvebu/ap806-ring.c                     |  65 ++++++++++++
 7 files changed, 251 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt
 create mode 100644 drivers/clk/mvebu/ap806-core.c
 create mode 100644 drivers/clk/mvebu/ap806-ring.c

-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Sun Feb 14 23:34:58 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Feb 2016 08:34:58 +0100
Subject: [PATCH 3/3] clk: mvebu: add AP806 ring clock driver
In-Reply-To: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455521698-7905-4-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adds a new driver to handle the ring clocks found in the
AP806 HW block, which is the core block of all Armada 7K and 8K
Marvell 64-bits processors. Those ring clocks are derived from the
core ring clock handled by the AP806 core clock driver. The ring
clocks are used by various peripherals inside the AP806.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../clock/mvebu-armada-ap806-ring-clock.txt        | 32 +++++++++++
 drivers/clk/mvebu/Kconfig                          |  3 +
 drivers/clk/mvebu/Makefile                         |  1 +
 drivers/clk/mvebu/ap806-ring.c                     | 65 ++++++++++++++++++++++
 4 files changed, 101 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt
 create mode 100644 drivers/clk/mvebu/ap806-ring.c

diff --git a/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt
new file mode 100644
index 0000000..5602bdc
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt
@@ -0,0 +1,32 @@
+* Clock bindings for Marvell MVEBU AP806 Ring clocks
+
+The Marvell MVEBU Armada 7K/8K SoCs contain a block called AP806,
+hosting the CPU and other core components of the CPU. This Device Tree
+binding allows to describe the ring clocks of the AP806, which are
+derived from the Ring Core clock, after a dividing factor.
+
+The following is a list of provided IDs and clock names on Armada
+AP806 RING dividers:
+
+ 0 = Ring 0
+ 1 = Ring 2
+ 2 = Ring 3
+ 3 = Ring 4
+ 4 = Ring 5
+
+Required properties:
+- compatible: must be one of the following:
+	"marvell,armada-ap806-ring-clock"
+- reg: must be the register holding the divider values for ring clocks
+- #clock-cells : from common clock binding; shall be set to 1
+- clock-output-names: name of the output clocks
+
+Example:
+
+	ringclk: clk at 0x6F8250 {
+		compatible = "marvell,armada-ap806-ring-clock";
+		reg = <0x6F8250 0x04>;
+		#clock-cells = <1>;
+		clock-output-names = "ring-0", "ring-2", "ring-3", "ring-4", "ring-5";
+		clocks = <&coreclk 1>;
+	};
diff --git a/drivers/clk/mvebu/Kconfig b/drivers/clk/mvebu/Kconfig
index fd84172..5d30aac 100644
--- a/drivers/clk/mvebu/Kconfig
+++ b/drivers/clk/mvebu/Kconfig
@@ -45,3 +45,6 @@ config ORION_CLK
 
 config ARMADA_AP806_CORE_CLK
 	bool
+
+config ARMADA_AP806_RING_CLK
+	bool
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
index db5c28c..48ca2d3 100644
--- a/drivers/clk/mvebu/Makefile
+++ b/drivers/clk/mvebu/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_ARMADA_375_CLK)	+= armada-375.o
 obj-$(CONFIG_ARMADA_38X_CLK)	+= armada-38x.o
 obj-$(CONFIG_ARMADA_39X_CLK)	+= armada-39x.o
 obj-$(CONFIG_ARMADA_AP806_CORE_CLK) += ap806-core.o
+obj-$(CONFIG_ARMADA_AP806_RING_CLK) += ap806-ring.o
 obj-$(CONFIG_ARMADA_XP_CLK)	+= armada-xp.o
 obj-$(CONFIG_DOVE_CLK)		+= dove.o dove-divider.o
 obj-$(CONFIG_KIRKWOOD_CLK)	+= kirkwood.o
diff --git a/drivers/clk/mvebu/ap806-ring.c b/drivers/clk/mvebu/ap806-ring.c
new file mode 100644
index 0000000..154ee55
--- /dev/null
+++ b/drivers/clk/mvebu/ap806-ring.c
@@ -0,0 +1,65 @@
+/*
+ * Marvell Armada AP806 ring clocks
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+#define AP806_RING_DIV_NUM	5
+
+static struct clk *ap806_ring_clks[AP806_RING_DIV_NUM];
+
+static struct clk_onecell_data ap806_ring_clk_data = {
+	.clks = ap806_ring_clks,
+	.clk_num = AP806_RING_DIV_NUM,
+};
+
+static void __init ap806_ring_clk_init(struct device_node *np)
+{
+	void __iomem *base;
+	const char *parent;
+	u32 reg;
+	int i;
+
+	base = of_iomap(np, 0);
+	if (WARN_ON(!base))
+		return;
+
+	reg = readl(base);
+
+	iounmap(base);
+
+	parent = of_clk_get_parent_name(np, 0);
+
+	for (i = 0; i < AP806_RING_DIV_NUM; i++) {
+		unsigned long divider;
+		const char *name;
+
+		/* Each clock is represented by 6 bits */
+		divider = (reg >> (6 * i)) & 0x3f;
+
+		of_property_read_string_index(np, "clock-output-names",
+					      i, &name);
+
+		ap806_ring_clks[i] =
+			clk_register_fixed_factor(NULL, name, parent,
+						  0, 1, divider);
+	}
+
+	of_clk_add_provider(np, of_clk_src_onecell_get, &ap806_ring_clk_data);
+}
+
+CLK_OF_DECLARE(ap806_ring_clk, "marvell,armada-ap806-ring-clock",
+	       ap806_ring_clk_init);
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Sun Feb 14 23:34:57 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Feb 2016 08:34:57 +0100
Subject: [PATCH 2/3] clk: mvebu: add AP806 core clock driver
In-Reply-To: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455521698-7905-3-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adds a new driver to handle the core clocks found in the
AP806 HW block, which is the core block of all Armada 7K and 8K
Marvell 64-bits processors. This core clock driver reads the
Sample-At-Reset register to determine the frequencies of several core
clocks: DDR, Ring and CPU clocks.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../clock/mvebu-armada-ap806-core-clock.txt        |  33 ++++++
 drivers/clk/mvebu/Kconfig                          |   3 +
 drivers/clk/mvebu/Makefile                         |   2 +-
 drivers/clk/mvebu/ap806-core.c                     | 112 +++++++++++++++++++++
 4 files changed, 149 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt
 create mode 100644 drivers/clk/mvebu/ap806-core.c

diff --git a/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt
new file mode 100644
index 0000000..b2131bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt
@@ -0,0 +1,33 @@
+* Clock bindings for Marvell MVEBU AP806 Core clocks
+
+The Marvell MVEBU Armada 7K/8K SoCs contain a block called AP806,
+hosting the CPU and other core components of the CPU. This Device Tree
+binding allows to describe the core clocks of the AP806, whose
+frequencies are determined by reading the Sample-At-Reset (SAR)
+register.
+
+Clock consumers must specify the desired clock by having the clock ID
+in its "clocks" phandle cell.
+
+The following is a list of provided IDs and clock names for the core
+Armada AP806 clocks:
+
+ 0 = DDR
+ 1 = Ring
+ 2 = CPU
+
+Required properties:
+- compatible: must be be one of the following:
+	"marvell,armada-ap806-core-clock"
+- reg: must be the register address of the Sample-At-Reset (SAR) register
+- #clock-cells: from common clock binding; shall be set to 1
+- clock-output-names: name of the output clocks
+
+Example:
+
+	coreclk: clk at 0x6F8204 {
+		compatible = "marvell,armada-ap806-core-clock";
+		reg = <0x6F8204 0x04>;
+		#clock-cells = <1>;
+		clock-output-names = "ddr", "ring", "cpu";
+	};
diff --git a/drivers/clk/mvebu/Kconfig b/drivers/clk/mvebu/Kconfig
index 2769625..fd84172 100644
--- a/drivers/clk/mvebu/Kconfig
+++ b/drivers/clk/mvebu/Kconfig
@@ -42,3 +42,6 @@ config KIRKWOOD_CLK
 config ORION_CLK
 	bool
 	select MVEBU_CLK_COMMON
+
+config ARMADA_AP806_CORE_CLK
+	bool
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
index 8866115..db5c28c 100644
--- a/drivers/clk/mvebu/Makefile
+++ b/drivers/clk/mvebu/Makefile
@@ -1,11 +1,11 @@
 obj-$(CONFIG_MVEBU_CLK_COMMON)	+= common.o
 obj-$(CONFIG_MVEBU_CLK_CPU) 	+= clk-cpu.o
 obj-$(CONFIG_MVEBU_CLK_COREDIV)	+= clk-corediv.o
-
 obj-$(CONFIG_ARMADA_370_CLK)	+= armada-370.o
 obj-$(CONFIG_ARMADA_375_CLK)	+= armada-375.o
 obj-$(CONFIG_ARMADA_38X_CLK)	+= armada-38x.o
 obj-$(CONFIG_ARMADA_39X_CLK)	+= armada-39x.o
+obj-$(CONFIG_ARMADA_AP806_CORE_CLK) += ap806-core.o
 obj-$(CONFIG_ARMADA_XP_CLK)	+= armada-xp.o
 obj-$(CONFIG_DOVE_CLK)		+= dove.o dove-divider.o
 obj-$(CONFIG_KIRKWOOD_CLK)	+= kirkwood.o
diff --git a/drivers/clk/mvebu/ap806-core.c b/drivers/clk/mvebu/ap806-core.c
new file mode 100644
index 0000000..56c81cd
--- /dev/null
+++ b/drivers/clk/mvebu/ap806-core.c
@@ -0,0 +1,112 @@
+/*
+ * Marvell Armada AP806 core clocks
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+/*
+ * AP806 PLLs:
+ *   0 - DDR
+ *   1 - Ring
+ *   2 - CPU
+ */
+
+#define AP806_PLL_NUM	3
+#define AP806_PLL_FREQ  7
+
+/* SAR parameters to get the PLL data */
+struct apclk_sar {
+	int mask;
+	int offset;
+	const char *name;
+};
+
+static const struct apclk_sar
+ap806_core_clk_sar[AP806_PLL_NUM]  __initconst = {
+	{ .mask = 0x7,	.offset = 21 },
+	{ .mask = 0x7,	.offset = 18 },
+	{ .mask = 0x7,	.offset = 15 },
+};
+
+static struct clk *ap806_core_clks[AP806_PLL_NUM];
+
+static struct clk_onecell_data ap806_core_clk_data = {
+	.clks = ap806_core_clks,
+	.clk_num = AP806_PLL_NUM,
+};
+
+/* mapping between SAR value to frequency */
+static const u32
+ap806_core_clk_freq[AP806_PLL_NUM][AP806_PLL_FREQ] __initconst = {
+	{ 2400000000, 2100000000, 1800000000,
+	  1600000000, 1300000000, 1300000000,
+	  1300000000 },
+	{ 2000000000, 1800000000, 1600000000,
+	  1400000000, 1200000000, 1200000000,
+	  1200000000 },
+	{ 2500000000, 2200000000, 2000000000,
+	  1700000000, 1600000000, 1200000000,
+	  1200000000 },
+};
+
+static unsigned long __init ap806_core_clk_get_freq(u32 reg, int clk_idx)
+{
+	int freq_idx;
+	const struct apclk_sar *clk_info;
+
+	clk_info = &ap806_core_clk_sar[clk_idx];
+
+	freq_idx = (reg >> clk_info->offset) & clk_info->mask;
+	if (WARN_ON(freq_idx > AP806_PLL_FREQ))
+		return 0;
+	else
+		return ap806_core_clk_freq[clk_idx][freq_idx];
+}
+
+static void __init ap806_core_clk_init(struct device_node *np)
+{
+	void __iomem *base;
+	u32 reg;
+	int i;
+
+	base = of_iomap(np, 0);
+	if (WARN_ON(!base))
+		return;
+
+	reg = readl(base);
+
+	iounmap(base);
+
+	for (i = 0; i < AP806_PLL_NUM; i++) {
+		unsigned long freq;
+		const char *name;
+
+		freq = ap806_core_clk_get_freq(reg, i);
+
+		of_property_read_string_index(np, "clock-output-names",
+					      i, &name);
+
+		ap806_core_clks[i] =
+			clk_register_fixed_rate(NULL, name, NULL,
+						CLK_IS_ROOT, freq);
+	}
+
+	of_clk_add_provider(np, of_clk_src_onecell_get,
+			    &ap806_core_clk_data);
+}
+
+CLK_OF_DECLARE(ap806_core_clk, "marvell,armada-ap806-core-clock",
+	       ap806_core_clk_init);
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Sun Feb 14 23:42:42 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Feb 2016 08:42:42 +0100
Subject: [PATCH] irqchip: irq-mvebu-odmi: new driver
Message-ID: <1455522162-16425-1-git-send-email-thomas.petazzoni@free-electrons.com>

This commits adds a new irqchip driver that handles the ODMI
controller found on Marvell 7K/8K processors. The ODMI controller
provide MSI interrupt functionality to on-board peripherals, much like
the GIC-v2m.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../marvell,odmi-controller.txt                    |  36 +++
 drivers/irqchip/Kconfig                            |   4 +
 drivers/irqchip/Makefile                           |   1 +
 drivers/irqchip/irq-mvebu-odmi.c                   | 270 +++++++++++++++++++++
 4 files changed, 311 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
 create mode 100644 drivers/irqchip/irq-mvebu-odmi.c

diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
new file mode 100644
index 0000000..a2470af
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
@@ -0,0 +1,36 @@
+
+* Marvell ODMI for MSI support
+
+Some Marvell SoCs have an On-Die Message Interrupt (ODMI) controller
+which can be used by on-board peripheral for MSI interrupts.
+
+Required properties:
+
+- compatible	       : The value here should contain "marvell,odmi-controller".
+
+- interrupt,controller : Identifies the node as an interrupt controller.
+
+- msi-controller       : Identifies the node as an MSI controller.
+
+- marvell,odmi-frames  : Number of ODMI frames available. Each frame
+                         provides a number of events.
+
+- reg		       : List of register definitions, one for each
+                         ODMI frame.
+
+- marvell,spi-base     : List of GIC base SPI interrupts, one for each
+                         ODMI frame.
+
+Example:
+
+	odmi: odmi at 300000 {
+		compatible = "marvell,odmi-controller";
+		interrupt-controller;
+		msi-controller;
+		marvell,odmi-frames = <4>;
+		reg = <0x300000 0x4000>,
+		      <0x304000 0x4000>,
+		      <0x308000 0x4000>,
+		      <0x30C000 0x4000>;
+		marvell,spi-base = <128>, <136>, <144>, <152>;
+	};
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 715923d..18bed3c 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -217,3 +217,7 @@ config IRQ_MXS
 	def_bool y if MACH_ASM9260 || ARCH_MXS
 	select IRQ_DOMAIN
 	select STMP_DEVICE
+
+config MVEBU_ODMI
+	bool
+	select GENERIC_MSI_IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 18caacb..29c388f 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -59,3 +59,4 @@ obj-$(CONFIG_ARCH_SA1100)		+= irq-sa11x0.o
 obj-$(CONFIG_INGENIC_IRQ)		+= irq-ingenic.o
 obj-$(CONFIG_IMX_GPCV2)			+= irq-imx-gpcv2.o
 obj-$(CONFIG_PIC32_EVIC)		+= irq-pic32-evic.o
+obj-$(CONFIG_MVEBU_ODMI)		+= irq-mvebu-odmi.o
diff --git a/drivers/irqchip/irq-mvebu-odmi.c b/drivers/irqchip/irq-mvebu-odmi.c
new file mode 100644
index 0000000..c3e00b9
--- /dev/null
+++ b/drivers/irqchip/irq-mvebu-odmi.c
@@ -0,0 +1,270 @@
+/*
+ * Copyright (C) 2016 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#define pr_fmt(fmt) "GIC-ODMI: " fmt
+
+#include <linux/irq.h>
+#include <linux/irqchip.h>
+#include <linux/irqdomain.h>
+#include <linux/kernel.h>
+#include <linux/msi.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+#define GICP_ODMIN_SET			0x40
+#define   GICP_ODMI_INT_NUM_SHIFT	12
+#define GICP_ODMIN_GM_EP_R0		0x110
+#define GICP_ODMIN_GM_EP_R1		0x114
+#define GICP_ODMIN_GM_EA_R0		0x108
+#define GICP_ODMIN_GM_EA_R1		0x118
+
+/*
+ * We don't support the group events, so we simply have 8 interrupts
+ * per frame.
+ */
+#define NODMIS_PER_FRAME 8
+
+struct odmi_data {
+	struct resource res;
+	void __iomem *base;
+	unsigned int spi_base;
+	unsigned long bm;
+};
+
+static struct odmi_data *odmis;
+static unsigned int odmis_count;
+
+/*
+ * Lock protecting the allocation bitmap embedded in the odmi_data
+ * structure. Only one spinlock is used, since allocation/freeing of
+ * MSI interrupts is infrequent.
+ */
+static DEFINE_SPINLOCK(odmis_lock);
+
+static int odmi_set_affinity(struct irq_data *irq_data,
+			       const struct cpumask *mask, bool force)
+{
+	int ret;
+
+	ret = irq_chip_set_affinity_parent(irq_data, mask, force);
+	if (ret == IRQ_SET_MASK_OK)
+		ret = IRQ_SET_MASK_OK_DONE;
+
+	return ret;
+}
+
+static void odmi_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
+{
+	struct odmi_data *odmi = NULL;
+	phys_addr_t addr;
+	unsigned int odmi_offset, i;
+
+	/* Search the ODMI frame handling this interrupt */
+	for (i = 0; i < odmis_count; i++) {
+		if (data->hwirq >= odmis[i].spi_base &&
+		    data->hwirq < (odmis[i].spi_base + NODMIS_PER_FRAME)) {
+			odmi = &odmis[i];
+			break;
+		}
+	}
+
+	if (WARN_ON(!odmi))
+		return;
+
+	odmi_offset = (data->hwirq - odmi->spi_base);
+
+	addr = odmi->res.start + GICP_ODMIN_SET;
+
+	msg->address_hi = upper_32_bits(addr);
+	msg->address_lo = lower_32_bits(addr);
+	msg->data = odmi_offset << GICP_ODMI_INT_NUM_SHIFT;
+}
+
+static struct irq_chip odmi_irq_chip = {
+	.name			= "ODMI",
+	.irq_mask		= irq_chip_mask_parent,
+	.irq_unmask		= irq_chip_unmask_parent,
+	.irq_eoi		= irq_chip_eoi_parent,
+	.irq_set_affinity	= odmi_set_affinity,
+	.irq_compose_msi_msg	= odmi_compose_msi_msg,
+};
+
+static int odmi_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+				 unsigned int nr_irqs, void *args)
+{
+	struct odmi_data *odmi = NULL;
+	struct irq_fwspec fwspec;
+	struct irq_data *d;
+	unsigned int offset, hwirq;
+	int i, ret;
+
+	spin_lock(&odmis_lock);
+	for (i = 0; i < odmis_count; i++) {
+		offset = find_first_zero_bit(&odmis[i].bm, NODMIS_PER_FRAME);
+		if (offset < NODMIS_PER_FRAME) {
+			__set_bit(offset, &odmis[i].bm);
+			odmi = &odmis[i];
+			break;
+		}
+	}
+	spin_unlock(&odmis_lock);
+
+	if (!odmi)
+		return -ENOSPC;
+
+	hwirq = odmi->spi_base + offset;
+
+	fwspec.fwnode = domain->parent->fwnode;
+	fwspec.param_count = 3;
+	fwspec.param[0] = GIC_SPI;
+	fwspec.param[1] = hwirq - 32;
+	fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
+
+	ret = irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
+	if (ret) {
+		pr_err("Cannot allocate parent IRQ\n");
+		spin_lock(&odmis_lock);
+		__clear_bit(offset, &odmi->bm);
+		spin_unlock(&odmis_lock);
+		return ret;
+	}
+
+	/* Configure the interrupt line to be edge */
+	d = irq_domain_get_irq_data(domain->parent, virq);
+	d->chip->irq_set_type(d, IRQ_TYPE_EDGE_RISING);
+
+	irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
+				      &odmi_irq_chip, NULL);
+
+	return 0;
+}
+
+static void odmi_irq_domain_free(struct irq_domain *domain,
+				 unsigned int virq, unsigned int nr_irqs)
+{
+	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+	struct odmi_data *odmi = NULL;
+	unsigned int offset;
+	int i;
+
+	/*
+	 * Check if the hwirq number is valid, and if so, to which
+	 * ODMI frame it belongs
+	 */
+	spin_lock(&odmis_lock);
+	for (i = 0; i < odmis_count; i++) {
+		if (d->hwirq >= odmis[i].spi_base &&
+		    d->hwirq < (odmis[i].spi_base + NODMIS_PER_FRAME)) {
+			odmi = &odmis[i];
+			offset = d->hwirq - odmis[i].spi_base;
+			break;
+		}
+	}
+	spin_unlock(&odmis_lock);
+
+	if (!odmi) {
+		pr_err("Failed to teardown msi. Invalid hwirq %lu\n", d->hwirq);
+		return;
+	}
+
+	irq_domain_free_irqs_parent(domain, virq, nr_irqs);
+
+	/* Actually free the MSI */
+	spin_lock(&odmis_lock);
+	__clear_bit(offset, &odmi->bm);
+	spin_unlock(&odmis_lock);
+}
+
+static const struct irq_domain_ops odmi_domain_ops = {
+	.alloc	= odmi_irq_domain_alloc,
+	.free	= odmi_irq_domain_free,
+};
+
+static struct irq_chip odmi_msi_irq_chip = {
+	.name	= "ODMI",
+};
+
+static struct msi_domain_ops odmi_msi_ops = {
+};
+
+static struct msi_domain_info odmi_msi_domain_info = {
+	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),
+	.ops	= &odmi_msi_ops,
+	.chip	= &odmi_msi_irq_chip,
+};
+
+static int __init mvebu_odmi_init(struct device_node *node,
+				  struct device_node *parent)
+{
+	struct irq_domain *inner_domain, *plat_domain;
+	int ret, i;
+
+	if (of_property_read_u32(node, "marvell,odmi-frames", &odmis_count))
+		return -EINVAL;
+
+	odmis = kcalloc(odmis_count, sizeof(struct odmi_data), GFP_KERNEL);
+	if (!odmis)
+		return -ENOMEM;
+
+	for (i = 0; i < odmis_count; i++) {
+		struct odmi_data *odmi = &odmis[i];
+
+		ret = of_address_to_resource(node, i, &odmi->res);
+		if (ret)
+			goto err_unmap;
+
+		odmi->base = of_io_request_and_map(node, i, "odmi");
+		if (IS_ERR(odmi->base)) {
+			ret = PTR_ERR(odmi->base);
+			goto err_unmap;
+		}
+
+		if (of_property_read_u32_index(node, "marvell,spi-base",
+					       i, &odmi->spi_base)) {
+			ret = -EINVAL;
+			goto err_unmap;
+		}
+	}
+
+	inner_domain = irq_domain_create_linear(of_node_to_fwnode(node),
+						odmis_count * NODMIS_PER_FRAME,
+						&odmi_domain_ops, NULL);
+	if (!inner_domain) {
+		ret = -ENOMEM;
+		goto err_unmap;
+	}
+
+	inner_domain->parent = irq_find_host(parent);
+
+	plat_domain = platform_msi_create_irq_domain(of_node_to_fwnode(node),
+						     &odmi_msi_domain_info,
+						     inner_domain);
+	if (!plat_domain) {
+		ret = -ENOMEM;
+		goto err_remove_inner;
+	}
+
+	return 0;
+
+err_remove_inner:
+	irq_domain_remove(inner_domain);
+err_unmap:
+	for (i = 0; i < odmis_count; i++) {
+		struct odmi_data *odmi = &odmis[i];
+
+		if (odmi->base && !IS_ERR(odmi->base))
+			iounmap(odmis[i].base);
+	}
+	kfree(odmis);
+	return ret;
+}
+
+IRQCHIP_DECLARE(mvebu_odmi, "marvell,odmi-controller", mvebu_odmi_init);
-- 
2.6.4



From geert at linux-m68k.org  Sun Feb 14 23:45:48 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 08:45:48 +0100
Subject: [PATCH 01/68] ARM: dts: gose: Add GPIO keys to DT
In-Reply-To: <20160215071817.GA4528@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
 <d7d5974b156e2ef7436483de00ccada5987c9d31.1455303422.git.horms+renesas@verge.net.au>
 <CAMuHMdVefum3YbaxhMX_0hHrmTFYU-pWYZTwSUveQDLFArLdYw@mail.gmail.com>
 <20160215071817.GA4528@verge.net.au>
Message-ID: <CAMuHMdVjJmKuTNJndhss5yBJ5AGt3crMZe5gTXbwC32B-Aw1PA@mail.gmail.com>

On Mon, Feb 15, 2016 at 8:18 AM, Simon Horman <horms at verge.net.au> wrote:
> On Sat, Feb 13, 2016 at 09:23:47PM +0100, Geert Uytterhoeven wrote:
>> On Fri, Feb 12, 2016 at 8:04 PM, Simon Horman
>> <horms+renesas at verge.net.au> wrote:
>> > Instantiate the GPIO keys in the gose device tree.
>> >
>> > Based on similar work for the koelsch board by Laurent Pinchart.
>> >
>> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
>> > Tested-by: Magnus Damm <damm+renesas at opensource.se>
>> > ---
>> >  arch/arm/boot/dts/r8a7793-gose.dts | 82 ++++++++++++++++++++++++++++++++++++++
>> >  1 file changed, 82 insertions(+)
>> >
>> > diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
>> > index baa59fe84298..ccbc1c66cc6c 100644
>> > --- a/arch/arm/boot/dts/r8a7793-gose.dts
>> > +++ b/arch/arm/boot/dts/r8a7793-gose.dts
>> > @@ -31,6 +31,88 @@
>> >                 device_type = "memory";
>> >                 reg = <0 0x40000000 0 0x40000000>;
>> >         };
>> > +
>> > +       gpio-keys {
>> > +               compatible = "gpio-keys";
>> > +
>> > +               key-1 {
>> > +                       gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
>> > +                       linux,code = <KEY_1>;
>> > +                       label = "SW2-1";
>> > +                       gpio-key,wakeup;
>>
>> In the mean time, "gpio-key,wakeup" has been deprecated in favor of
>> "wakeup-source".
>
> Is the change just a matter of s/gpio-key,wakeup/wakeup-source/ ?
> If so I'll sort things out.

Yes, cfr. e.g. commit 0cc16889e77a95568806b1e45af104f75547eac9
("ARM: dts: shmobile/r8a7xxx: replace gpio-key, wakeup with
wakeup-source property")

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From k.kozlowski at samsung.com  Sun Feb 14 23:46:08 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Mon, 15 Feb 2016 16:46:08 +0900
Subject: [PATCH v8 1/2] power: act8945a: add charger driver for ACT8945A
In-Reply-To: <1454646368-18193-2-git-send-email-wenyou.yang@atmel.com>
References: <1454646368-18193-1-git-send-email-wenyou.yang@atmel.com>
 <1454646368-18193-2-git-send-email-wenyou.yang@atmel.com>
Message-ID: <56C18240.70204@samsung.com>

On 05.02.2016 13:26, Wenyou Yang wrote:
> This patch adds new driver for Active-semi ACT8945A ActivePath
> charger (part of ACT8945A MFD driver) providing power supply class
> information to userspace.
> 
> The driver can be configured through DT (such as, total timer,
> precondition timer and input over-voltage threshold).
> 
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> ---
> 
> Changes in v8:
>  - remove the OF table.
>  - due to the mfd cell .of_compatible removal, use the platform
>    device's parent of_node to read the property and assign it
>    to the psy_cfg.of_node.
>  - fix the typo.
> 
> Changes in v7:
>  - use the helper dev_get_regmap(pdev->dev.parent, NULL) to get regmap.
>  - remove *act8945a_dev member from struct act8945a_charger.
>  - remove *psy member from struct act8945a_charger.
>  - merge _parse_dt() and _charger_config() functions, remove relevent
>    members from struct act8945a_charger.
>  - remove unused platform_set_drvdata(pdev, charger) statement.
> 
> Changes in v6:
>  - change the type value to unsigned int.
> 
> Changes in v5:
>  - remove spare spaces after #define.
>  - add OF match table.
> 
> Changes in v4:
>  - use spaces after #define, not tabs.
>  - use BIT(n) macros to substitute (0x01 << x).
>  - change dt properties with more legible name.
> 
> Changes in v3:
>  - update the file header with short version license and author line.
>  - remove unused member of struct act8945a_charger, dev.
>  - action due to removing the member of stuct act8945a_dev, dev.
>  - remove the unnecessary print out.
>  - remove the unnecessary act8945a_charger_remove().
>  - fix align of the code-style.
> 
> Changes in v2:
>  1./ Substitute of_property_read_bool() for of_get_property().
>  2./ Substitute devm_power_supply_register() for power_supply_register().
>  3./ Use module_platform_driver(), instead of subsys_initcall().
>  4./ Substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").
> 
>  drivers/power/Kconfig            |    7 +
>  drivers/power/Makefile           |    1 +
>  drivers/power/act8945a_charger.c |  355 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 363 insertions(+)
>  create mode 100644 drivers/power/act8945a_charger.c
> 
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 1ddd13c..ae75211 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -75,6 +75,13 @@ config BATTERY_88PM860X
>  	help
>  	  Say Y here to enable battery monitor for Marvell 88PM860x chip.
>  
> +config BATTERY_ACT8945A
> +	tristate "Active-semi ACT8945A charger driver"
> +	depends on MFD_ACT8945A
> +	help
> +	  Say Y here to enable support for power supply provided by
> +	  Active-semi ActivePath ACT8945A charger.
> +
>  config BATTERY_DS2760
>  	tristate "DS2760 battery driver (HP iPAQ & others)"
>  	depends on W1 && W1_SLAVE_DS2760
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 0e4eab5..e46b75d 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_WM8350_POWER)	+= wm8350_power.o
>  obj-$(CONFIG_TEST_POWER)	+= test_power.o
>  
>  obj-$(CONFIG_BATTERY_88PM860X)	+= 88pm860x_battery.o
> +obj-$(CONFIG_BATTERY_ACT8945A)	+= act8945a_charger.o
>  obj-$(CONFIG_BATTERY_DS2760)	+= ds2760_battery.o
>  obj-$(CONFIG_BATTERY_DS2780)	+= ds2780_battery.o
>  obj-$(CONFIG_BATTERY_DS2781)	+= ds2781_battery.o
> diff --git a/drivers/power/act8945a_charger.c b/drivers/power/act8945a_charger.c
> new file mode 100644
> index 0000000..0da0ea5
> --- /dev/null
> +++ b/drivers/power/act8945a_charger.c
> @@ -0,0 +1,355 @@
> +/*
> + * Power supply driver for the Active-semi ACT8945A PMIC
> + *
> + * Copyright (C) 2015 Atmel Corporation
> + *
> + * Author: Wenyou Yang <wenyou.yang at atmel.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.
> + *
> + */
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_gpio.h>
> +#include <linux/platform_device.h>
> +#include <linux/power_supply.h>
> +#include <linux/regmap.h>
> +
> +static const char *act8945a_charger_model = "ACT8945A";
> +static const char *act8945a_charger_manufacturer = "Active-semi";
> +
> +/**
> + * ACT8945A Charger Register Map
> + */
> +
> +/* 0x70: Reserved */
> +#define ACT8945A_APCH_CFG		0x71
> +#define ACT8945A_APCH_STATUS		0x78
> +#define ACT8945A_APCH_CTRL		0x79
> +#define ACT8945A_APCH_STATE		0x7A
> +
> +/* ACT8945A_APCH_CFG */
> +#define APCH_CFG_OVPSET			(0x3 << 0)
> +#define APCH_CFG_OVPSET_6V6		(0x0 << 0)
> +#define APCH_CFG_OVPSET_7V		(0x1 << 0)
> +#define APCH_CFG_OVPSET_7V5		(0x2 << 0)
> +#define APCH_CFG_OVPSET_8V		(0x3 << 0)
> +#define APCH_CFG_PRETIMO		(0x3 << 2)
> +#define APCH_CFG_PRETIMO_40_MIN		(0x0 << 2)
> +#define APCH_CFG_PRETIMO_60_MIN		(0x1 << 2)
> +#define APCH_CFG_PRETIMO_80_MIN		(0x2 << 2)
> +#define APCH_CFG_PRETIMO_DISABLED	(0x3 << 2)
> +#define APCH_CFG_TOTTIMO		(0x3 << 4)
> +#define APCH_CFG_TOTTIMO_3_HOUR		(0x0 << 4)
> +#define APCH_CFG_TOTTIMO_4_HOUR		(0x1 << 4)
> +#define APCH_CFG_TOTTIMO_5_HOUR		(0x2 << 4)
> +#define APCH_CFG_TOTTIMO_DISABLED	(0x3 << 4)
> +#define APCH_CFG_SUSCHG			(0x1 << 7)
> +
> +#define APCH_STATUS_CHGDAT		BIT(0)
> +#define APCH_STATUS_INDAT		BIT(1)
> +#define APCH_STATUS_TEMPDAT		BIT(2)
> +#define APCH_STATUS_TIMRDAT		BIT(3)
> +#define APCH_STATUS_CHGSTAT		BIT(4)
> +#define APCH_STATUS_INSTAT		BIT(5)
> +#define APCH_STATUS_TEMPSTAT		BIT(6)
> +#define APCH_STATUS_TIMRSTAT		BIT(7)
> +
> +#define APCH_CTRL_CHGEOCOUT		BIT(0)
> +#define APCH_CTRL_INDIS			BIT(1)
> +#define APCH_CTRL_TEMPOUT		BIT(2)
> +#define APCH_CTRL_TIMRPRE		BIT(3)
> +#define APCH_CTRL_CHGEOCIN		BIT(4)
> +#define APCH_CTRL_INCON			BIT(5)
> +#define APCH_CTRL_TEMPIN		BIT(6)
> +#define APCH_CTRL_TIMRTOT		BIT(7)
> +
> +#define APCH_STATE_ACINSTAT		(0x1 << 1)
> +#define APCH_STATE_CSTATE		(0x3 << 4)
> +#define APCH_STATE_CSTATE_SHIFT		4
> +#define APCH_STATE_CSTATE_DISABLED	0x00
> +#define APCH_STATE_CSTATE_EOC		0x01
> +#define APCH_STATE_CSTATE_FAST		0x02
> +#define APCH_STATE_CSTATE_PRE		0x03
> +
> +struct act8945a_charger {
> +	struct regmap *regmap;
> +	bool battery_temperature;
> +};
> +
> +static int act8945a_get_charger_state(struct regmap *regmap, int *val)
> +{
> +	int ret;
> +	unsigned int status, state;
> +
> +	ret = regmap_read(regmap, ACT8945A_APCH_STATUS, &status);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = regmap_read(regmap, ACT8945A_APCH_STATE, &state);
> +	if (ret < 0)
> +		return ret;
> +
> +	state &= APCH_STATE_CSTATE;
> +	state >>= APCH_STATE_CSTATE_SHIFT;
> +
> +	if (state == APCH_STATE_CSTATE_EOC) {
> +		if (status & APCH_STATUS_CHGDAT)
> +			*val = POWER_SUPPLY_STATUS_FULL;
> +		else
> +			*val = POWER_SUPPLY_STATUS_NOT_CHARGING;
> +	} else if ((state == APCH_STATE_CSTATE_FAST) ||
> +		   (state == APCH_STATE_CSTATE_PRE)) {
> +		*val = POWER_SUPPLY_STATUS_CHARGING;
> +	} else {
> +		*val = POWER_SUPPLY_STATUS_NOT_CHARGING;
> +	}
> +
> +	return 0;
> +}
> +
> +static int act8945a_get_charge_type(struct regmap *regmap, int *val)
> +{
> +	int ret;
> +	unsigned int state;
> +
> +	ret = regmap_read(regmap, ACT8945A_APCH_STATE, &state);
> +	if (ret < 0)
> +		return ret;
> +
> +	state &= APCH_STATE_CSTATE;
> +	state >>= APCH_STATE_CSTATE_SHIFT;
> +
> +	switch (state) {
> +	case APCH_STATE_CSTATE_PRE:
> +		*val = POWER_SUPPLY_CHARGE_TYPE_TRICKLE;
> +		break;
> +	case APCH_STATE_CSTATE_FAST:
> +		*val = POWER_SUPPLY_CHARGE_TYPE_FAST;
> +		break;
> +	case APCH_STATE_CSTATE_EOC:
> +	case APCH_STATE_CSTATE_DISABLED:
> +	default:
> +		*val = POWER_SUPPLY_CHARGE_TYPE_NONE;
> +	}
> +
> +	return 0;
> +}
> +
> +static int act8945a_get_battery_health(struct act8945a_charger *charger,
> +				       struct regmap *regmap, int *val)
> +{
> +	int ret;
> +	unsigned int status;
> +
> +	ret = regmap_read(regmap, ACT8945A_APCH_STATUS, &status);
> +	if (ret < 0)
> +		return ret;
> +
> +	if (charger->battery_temperature && !(status & APCH_STATUS_TEMPDAT))
> +		*val = POWER_SUPPLY_HEALTH_OVERHEAT;
> +	else if (!(status & APCH_STATUS_INDAT))
> +		*val = POWER_SUPPLY_HEALTH_OVERVOLTAGE;
> +	else if (status & APCH_STATUS_TIMRDAT)
> +		*val = POWER_SUPPLY_HEALTH_SAFETY_TIMER_EXPIRE;
> +	else
> +		*val = POWER_SUPPLY_HEALTH_GOOD;
> +
> +	return 0;
> +}
> +
> +static enum power_supply_property act8945a_charger_props[] = {
> +	POWER_SUPPLY_PROP_STATUS,
> +	POWER_SUPPLY_PROP_CHARGE_TYPE,
> +	POWER_SUPPLY_PROP_TECHNOLOGY,
> +	POWER_SUPPLY_PROP_HEALTH,
> +	POWER_SUPPLY_PROP_MODEL_NAME,
> +	POWER_SUPPLY_PROP_MANUFACTURER
> +};
> +
> +static int act8945a_charger_get_property(struct power_supply *psy,
> +					 enum power_supply_property prop,
> +					 union power_supply_propval *val)
> +{
> +	struct act8945a_charger *charger = power_supply_get_drvdata(psy);
> +	struct regmap *regmap = charger->regmap;
> +	int ret = 0;
> +
> +	switch (prop) {
> +	case POWER_SUPPLY_PROP_STATUS:
> +		ret = act8945a_get_charger_state(regmap, &val->intval);
> +		break;
> +	case POWER_SUPPLY_PROP_CHARGE_TYPE:
> +		ret = act8945a_get_charge_type(regmap, &val->intval);
> +		break;
> +	case POWER_SUPPLY_PROP_TECHNOLOGY:
> +		val->intval = POWER_SUPPLY_TECHNOLOGY_LION;
> +		break;
> +	case POWER_SUPPLY_PROP_HEALTH:
> +		ret = act8945a_get_battery_health(charger,
> +						  regmap, &val->intval);
> +		break;
> +	case POWER_SUPPLY_PROP_MODEL_NAME:
> +		val->strval = act8945a_charger_model;
> +		break;
> +	case POWER_SUPPLY_PROP_MANUFACTURER:
> +		val->strval = act8945a_charger_manufacturer;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	return ret;
> +}
> +
> +static const struct power_supply_desc act8945a_charger_desc = {
> +	.name		= "act8945a-charger",
> +	.type		= POWER_SUPPLY_TYPE_BATTERY,
> +	.get_property	= act8945a_charger_get_property,
> +	.properties	= act8945a_charger_props,
> +	.num_properties	= ARRAY_SIZE(act8945a_charger_props),
> +};
> +
> +#define DEFAULT_TOTAL_TIME_OUT		3
> +#define DEFAULT_PRE_TIME_OUT		40
> +#define DEFAULT_INPUT_OVP_THRESHOLD	6600
> +
> +static int act8945a_charger_config(struct device *dev,
> +				   struct act8945a_charger *charger)
> +{
> +	struct device_node *np = dev->of_node;
> +	enum of_gpio_flags flags;
> +	struct regmap *regmap = charger->regmap;
> +
> +	u32 total_time_out;
> +	u32 pre_time_out;
> +	u32 input_voltage_threshold;
> +	int chglev_pin;
> +
> +	unsigned int value = 0;
> +
> +	if (!np) {
> +		dev_err(dev, "no charger of node\n");
> +		return -EINVAL;
> +	}
> +
> +	charger->battery_temperature = of_property_read_bool(np,
> +				"active-semi,check-battery-temperature");
> +
> +	chglev_pin = of_get_named_gpio_flags(np,
> +				"active-semi,chglev-gpios", 0, &flags);
> +
> +	if (gpio_is_valid(chglev_pin)) {
> +		gpio_set_value(chglev_pin,
> +			       ((flags == OF_GPIO_ACTIVE_LOW) ? 0 : 1));
> +	}
> +
> +	if (of_property_read_u32(np,
> +				 "active-semi,input-voltage-threshold-microvolt",
> +				 &input_voltage_threshold))
> +		input_voltage_threshold = DEFAULT_INPUT_OVP_THRESHOLD;
> +
> +	if (of_property_read_u32(np,
> +				 "active-semi,precondition-timeout",
> +				 &pre_time_out))
> +		pre_time_out = DEFAULT_PRE_TIME_OUT;
> +
> +	if (of_property_read_u32(np, "active-semi,total-timeout",
> +				 &total_time_out))
> +		total_time_out = DEFAULT_TOTAL_TIME_OUT;
> +
> +	switch (input_voltage_threshold) {
> +	case 8000:
> +		value |= APCH_CFG_OVPSET_8V;
> +		break;
> +	case 7500:
> +		value |= APCH_CFG_OVPSET_7V5;
> +		break;
> +	case 7000:
> +		value |= APCH_CFG_OVPSET_7V;
> +		break;
> +	case 6600:
> +	default:
> +		value |= APCH_CFG_OVPSET_6V6;
> +		break;
> +	}
> +
> +	switch (pre_time_out) {
> +	case 60:
> +		value |= APCH_CFG_PRETIMO_60_MIN;
> +		break;
> +	case 80:
> +		value |= APCH_CFG_PRETIMO_80_MIN;
> +		break;
> +	case 0:
> +		value |= APCH_CFG_PRETIMO_DISABLED;
> +		break;
> +	case 40:
> +	default:
> +		value |= APCH_CFG_PRETIMO_40_MIN;
> +		break;
> +	}
> +
> +	switch (total_time_out) {
> +	case 4:
> +		value |= APCH_CFG_TOTTIMO_4_HOUR;
> +		break;
> +	case 5:
> +		value |= APCH_CFG_TOTTIMO_5_HOUR;
> +		break;
> +	case 0:
> +		value |= APCH_CFG_TOTTIMO_DISABLED;
> +		break;
> +	case 3:
> +	default:
> +		value |= APCH_CFG_TOTTIMO_3_HOUR;
> +		break;
> +	}
> +
> +	return regmap_write(regmap, ACT8945A_APCH_CFG, value);
> +}
> +
> +static int act8945a_charger_probe(struct platform_device *pdev)
> +{
> +	struct act8945a_charger *charger;
> +	struct power_supply *psy;
> +	struct power_supply_config psy_cfg = {};
> +	int ret;
> +
> +	charger = devm_kzalloc(&pdev->dev, sizeof(*charger), GFP_KERNEL);
> +	if (!charger)
> +		return -ENOMEM;
> +
> +	charger->regmap = dev_get_regmap(pdev->dev.parent, NULL);

I think it would be good (as a precaution) to check for non-null here:
if (!charger->regmap) {
	dev_err(... "Parent did not provide regmap\n");
	return -EINVAL;
}

Beside that:

Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>

Best regards,
Krzysztof



From paul at pwsan.com  Sun Feb 14 23:46:37 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 15 Feb 2016 07:46:37 +0000 (UTC)
Subject: OMAP baseline test results for v4.5-rc4
Message-ID: <alpine.DEB.2.02.1602150744500.26085@utopia.booyaka.com>


Here are some basic OMAP test results for Linux v4.5-rc4.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v4.5-rc4/20160214144827/


Test summary
------------

Build: uImage:
    Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only,
		  omap1_defconfig_5912osk_only

Build: uImage+dtb:
    Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone,
		  omap2plus_defconfig/omap4-panda,
		  omap2plus_defconfig/omap4-panda-es,
		  omap2plus_defconfig/omap4-var-stk-om44,
		  omap2plus_defconfig/omap3-evm-37xx,
		  omap2plus_defconfig_n800_only_a/omap2420-n800,
		  omap2plus_defconfig/omap2430-sdp,
		  omap2plus_defconfig/am3517-evm,
		  omap2plus_defconfig/omap3-beagle,
		  omap2plus_defconfig/omap3-beagle-xm,
		  omap2plus_defconfig/omap3-sbc-t3517,
		  omap2plus_defconfig/omap5-uevm,
		  omap2plus_defconfig/omap5-sbc-t54

Build: zImage:
    Pass (18/18): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
		  omap2plus_defconfig_n800_only_a,
		  omap2plus_defconfig_n800_multi_omap2xxx,
		  omap2plus_defconfig_2430sdp_only,
		  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
		  omap2plus_defconfig_omap2_4_only,
		  omap2plus_defconfig_omap3_4_only,
		  omap2plus_defconfig_omap5_only,
		  omap2plus_defconfig_dra7xx_only,
		  omap2plus_defconfig_am43xx_only,
		  omap2plus_defconfig_ti81xx_only,
		  rmk_omap3430_ldp_oldconfig,
		  rmk_omap3430_ldp_allnoconfig,
		  rmk_omap4430_sdp_oldconfig,
		  rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig

Build warnings from toolchain: uImage:
    (none)

Build warnings from toolchain: uImage+dtb:
    (none)

Build warnings from toolchain: zImage:
    FAIL ( 1/18): multi_v7_defconfig

Boot to userspace:
    FAIL ( 1/18): 2430sdp
    skip ( 3/18): 5912osk, 3517evm, 5430es2sbct54
    Pass (14/18): am335xbonelt, am437xsk, am335xbone, 4430es2panda,
		  4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle,
		  3530es31beagle, 3730beaglexm, 3730es12beaglexm,
		  cmt3517, 5430es2uevm, 2420n800

Kernel warnings during boot to userspace:
    FAIL ( 1/18): cmt3517

PM: chip retention via suspend:
    FAIL ( 7/11): am335xbonelt, 4430es2panda, 4460pandaes,
		  4460varsomom, 37xxevm, 2430sdp, 5430es2uevm
    Pass ( 4/11): 3530es3beagle, 3530es31beagle, 3730beaglexm,
		  3730es12beaglexm

PM: chip retention via dynamic idle:
    FAIL ( 9/11): am335xbonelt, 4430es2panda, 4460pandaes,
		  4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle,
		  2430sdp, 5430es2uevm
    Pass ( 2/11): 3730beaglexm, 3730es12beaglexm

PM: chip off (except CORE, due to errata) via suspend:
    Pass ( 1/ 1): 3730beaglexm

PM: chip off (except CORE, due to errata) via dynamic idle:
    Pass ( 1/ 1): 3730beaglexm

PM: chip off via suspend:
    FAIL ( 2/ 4): 37xxevm, 3530es3beagle
    Pass ( 2/ 4): 3530es31beagle, 3730es12beaglexm

PM: chip off via dynamic idle:
    FAIL ( 3/ 4): 37xxevm, 3530es3beagle, 3530es31beagle
    Pass ( 1/ 4): 3730es12beaglexm

Kernel warnings during PM test:
    (none)

Obsolete Kconfig symbols:
    FAIL ( 3/21): omap1_defconfig, omap2plus_defconfig,
		  multi_v7_defconfig


vmlinux object size
(delta in bytes from test_v4.5-rc3 (388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95)):
   text     data      bss    total  kernel
  +1164      +64      +32    +1260  omap1_defconfig
  +1196      +64      +32    +1292  omap1_defconfig_1510innovator_only
  +1132      +32      +32    +1196  omap1_defconfig_5912osk_only
  +5346     +160        0    +5506  multi_v7_defconfig
  +1052      +64  -147392  -146276  omap2plus_defconfig
   +784      +96  -147456  -146576  omap2plus_defconfig_2430sdp_only
  +5136      +64  -147392  -142192  omap2plus_defconfig_am33xx_only
   +988      +64  -147392  -146340  omap2plus_defconfig_am43xx_only
  +1116      +64  -147392  -146212  omap2plus_defconfig_cpupm
   +988      +64  -147392  -146340  omap2plus_defconfig_dra7xx_only
   +780      +64  -147424  -146580  omap2plus_defconfig_n800_multi_omap2xxx
   +608      +32  -147456  -146816  omap2plus_defconfig_n800_only_a
  +1052      +64  -147392  -146276  omap2plus_defconfig_no_pm
  +1052      +96  -147392  -146244  omap2plus_defconfig_omap2_4_only
  +1052      +96  -147392  -146244  omap2plus_defconfig_omap3_4_only
  +1052      +96  -147392  -146244  omap2plus_defconfig_omap5_only
+8841927  +599312  +8312544  +17753783  omap2plus_defconfig_ti81xx_only
   +748      +64     -260     +552  rmk_omap3430_ldp_allnoconfig
  +1009        0  -147456  -146447  rmk_omap3430_ldp_oldconfig
   +704        0     -180     +524  rmk_omap4430_sdp_allnoconfig
  +1169       -8  -147456  -146295  rmk_omap4430_sdp_oldconfig

Boot-time memory difference
(delta in bytes from test_v4.5-rc3 (388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95))
  avail  rsrvd   high  freed  board          kconfig
   144k  -144k      .      .  2420n800       omap2plus_defconfig_n800_only_a
   144k  -144k      .      .  2430sdp        omap2plus_defconfig
   144k  -144k      .      .  3530es31beagle omap2plus_defconfig
   144k  -144k      .      .  3530es3beagle  omap2plus_defconfig
   144k  -144k      .      .  3730beaglexm   omap2plus_defconfig
   144k  -144k      .      .  3730es12beaglexmomap2plus_defconfig
   144k  -144k      .      .  37xxevm        omap2plus_defconfig
   144k  -144k      .      .  4430es2panda   omap2plus_defconfig
   144k  -144k      .      .  4460pandaes    omap2plus_defconfig
   144k  -144k      .      .  4460varsomom   omap2plus_defconfig
   144k  -144k      .      .  5430es2uevm    omap2plus_defconfig
   144k  -144k      .      .  am335xbone     omap2plus_defconfig_am33xx_only
   144k  -144k      .      .  am335xbonelt   omap2plus_defconfig
   144k  -144k      .      .  am437xsk       omap2plus_defconfig

A buil? test for a kernel specialized for the TI81xx family of devices has 
been a??ed, along with DTB builds for the DM8148 and DM8168 EVMs.

From u.kleine-koenig at pengutronix.de  Sun Feb 14 23:48:12 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Mon, 15 Feb 2016 08:48:12 +0100
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <56C0ECDA.1000203@roeck-us.net>
Message-ID: <20160215074812.GC12289@pengutronix.de>

Hello Guenter,

On Sun, Feb 14, 2016 at 01:08:42PM -0800, Guenter Roeck wrote:
> On 02/14/2016 11:55 AM, Uwe Kleine-K?nig wrote:
> >[adding lakml and rmk to Cc]
[adding some more people to Cc]

> >On Sun, Feb 14, 2016 at 08:50:10AM -0800, Guenter Roeck wrote:
> >>Your patch 'driver-core: platform: probe of-devices only using list of
> >>compatibles' causes the following qemu tests to crash in -next.

For the new readers, that is 67d02a1bbb334558e9380409a3cd426b36d4578b.

The original idea of this commit was to not bind a device created from
device tree when its name matches the driver name but none of the
driver's compatibles which might yield some surprises.

> >>arm:vexpress-a9:vexpress_defconfig:vexpress-v2p-ca9
> >>arm:vexpress-a15:vexpress_defconfig:vexpress-v2p-ca15-tc1
> >>arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
> >>arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
> >>
> >>Crash log:
> >>
> >>VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6
> >>Please append a correct "root=" boot option; here are the available partitions:
> >>1f00          131072 mtdblock0  (driver?)
> >>1f01           32768 mtdblock1  (driver?)
> >>Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
> >>
> >>ie the mmc driver no longer instantiates. Reverting the patch fixes the problem.
> >
> >The driver is drivers/mmc/host/mmci.c, right? and the relevant device
> >tree snippet is:
> >
> >	mmci at 05000 {
> >		compatible = "arm,pl180", "arm,primecell";
> >		...
> >	};
> >
> 
> Yes, I think so, or one of the many other similar mmc entries.

So the driver in question is an amba_driver and it fails to bind because

	static int platform_match(struct device *dev, struct device_driver *drv)
	
was changed. This is the platform bus type's match function. Why is this
called for amba devices (that I would expect to use amba_bustype and so
amba_match)?

The driver isn't matched by of_driver_match_device, so the
following code must yield 1 for the mmci device:

        /* Then try ACPI style match */
        if (acpi_driver_match_device(dev, drv))
                return 1;

        /* Then try to match against the id table */
        if (pdrv->id_table)
                return platform_match_id(pdrv->id_table, pdev) != NULL;

        /* fall-back to driver name match */
        return (strcmp(pdev->name, drv->name) == 0);

acpi seems unlikely, and the other two match by the device's name which
feels wrong. And I also wonder, what drv is here, because platform_match
assumes it is a platform_driver, not an amba_driver.

> >? So the unexpected abnormality here is that even though this device is
> >instantiated by dt, the driver doesn't provide any compatibles.
> >Either my expectation is wrong, then 67d02a1bbb33455 should be reverted
> >(or handle this case in a different way), or the mmci driver should
> >declare compatibles (but then it needs to be a platform driver and not
> >an amba driver?).
> 
> No idea what the correct solution would be. I do see
> 
>         if (of_device_is_compatible(bus, "arm,primecell")) {
>                 /*
>                  * Don't return an error here to keep compatibility with older
>                  * device tree files.
>                  */
>                 of_amba_device_create(bus, bus_id, platform_data, parent);
>                 return 0;
>         }

So there is a new (and better?) way to instantiate amba devices?

> in drivers/of/platform.c, which suggests some special handling for amba
> devices. No idea if and how that is related, but I do have some concern
> that fixing the problem for mmc alone might not fix it for all the other
> devices instantiated with "arm,primecell". After all, my boot tests are
> really rudimentary (it boots, therefore it works).

I don't see the right thing to do either. Maybe someone else can shed
some light on this issue?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From thomas.petazzoni at free-electrons.com  Sun Feb 14 23:58:03 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Feb 2016 08:58:03 +0100
Subject: [PATCH] dma: mv_xor_v2: new driver
Message-ID: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>

The new mv_xor_v2 driver supports the XOR engines found in the 64-bits
ARM from Marvell of the Armada 7K and Armada 8K family. This XOR
engine is a completely new hardware block, entirely different from the
one used on previous Marvell Armada platforms, which use the existing
mv_xor driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../devicetree/bindings/dma/mv-xor-v2.txt          |  19 +
 drivers/dma/Kconfig                                |  13 +
 drivers/dma/Makefile                               |   1 +
 drivers/dma/mv_xor_v2.c                            | 880 +++++++++++++++++++++
 4 files changed, 913 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/mv-xor-v2.txt
 create mode 100644 drivers/dma/mv_xor_v2.c

diff --git a/Documentation/devicetree/bindings/dma/mv-xor-v2.txt b/Documentation/devicetree/bindings/dma/mv-xor-v2.txt
new file mode 100644
index 0000000..0a03dcf
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mv-xor-v2.txt
@@ -0,0 +1,19 @@
+* Marvell XOR v2 engines
+
+Required properties:
+- compatible: Should be "marvell,mv-xor-v2"
+- reg: Should contain registers location and length (two sets)
+    the first set is the DMA registers
+    the second set is the global registers
+- msi-parent: Phandle to the MSI-capable interrupt controller used for
+  interrupts.
+
+Example:
+
+	xor0 at 400000 {
+		compatible = "marvell,mv-xor-v2";
+		reg = <0x400000 0x1000>,
+		      <0x410000 0x1000>;
+		msi-parent = <&gic_v2m0>;
+		dma-coherent;
+	};
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 79b1390..aeaac8b 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -339,6 +339,19 @@ config MV_XOR
 	---help---
 	  Enable support for the Marvell XOR engine.
 
+config MV_XOR_V2
+	bool "Marvell XOR engine version 2 support "
+	select DMA_ENGINE
+	select DMA_ENGINE_RAID
+	select ASYNC_TX_ENABLE_CHANNEL_SWITCH
+	select GENERIC_MSI_IRQ_DOMAIN
+	---help---
+	  Enable support for the Marvell version 2 XOR engine.
+
+	  This engine provides acceleration for copy, XOR and RAID6
+	  operations, and is available on Marvell Armada 7K and 8K
+	  platforms.
+
 config MXS_DMA
 	bool "MXS DMA support"
 	depends on SOC_IMX23 || SOC_IMX28 || SOC_IMX6Q
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 2dd0a067..da8ca73 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_MMP_TDMA) += mmp_tdma.o
 obj-$(CONFIG_MOXART_DMA) += moxart-dma.o
 obj-$(CONFIG_MPC512X_DMA) += mpc512x_dma.o
 obj-$(CONFIG_MV_XOR) += mv_xor.o
+obj-$(CONFIG_MV_XOR_V2) += mv_xor_v2.o
 obj-$(CONFIG_MXS_DMA) += mxs-dma.o
 obj-$(CONFIG_MX3_IPU) += ipu/
 obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
diff --git a/drivers/dma/mv_xor_v2.c b/drivers/dma/mv_xor_v2.c
new file mode 100644
index 0000000..ee73d5c
--- /dev/null
+++ b/drivers/dma/mv_xor_v2.c
@@ -0,0 +1,880 @@
+/*
+ * Copyright (C) 2015-2016 Marvell International Ltd.
+
+ * This program is free software: you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, either version 2 of the
+ * License, or any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#include <linux/dma-mapping.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/msi.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+
+#include "dmaengine.h"
+
+/* DMA Engine Registers */
+#define DMA_DESQ_BALR_OFF	0x000
+#define DMA_DESQ_BAHR_OFF	0x004
+#define DMA_DESQ_SIZE_OFF	0x008
+#define DMA_DESQ_DONE_OFF	0x00C
+#define   DMA_DESQ_DONE_PENDING_MASK		0x7FFF
+#define   DMA_DESQ_DONE_PENDING_SHIFT		0
+#define   DMA_DESQ_DONE_READ_PTR_MASK		0x1FFF
+#define   DMA_DESQ_DONE_READ_PTR_SHIFT		16
+#define DMA_DESQ_ARATTR_OFF	0x010
+#define   DMA_DESQ_ATTR_CACHE_MASK		0x3F3F
+#define   DMA_DESQ_ATTR_OUTER_SHAREABLE		0x202
+#define   DMA_DESQ_ATTR_CACHEABLE		0x3C3C
+#define DMA_IMSG_CDAT_OFF	0x014
+#define DMA_IMSG_THRD_OFF	0x018
+#define   DMA_IMSG_THRD_MASK			0x7FFF
+#define   DMA_IMSG_THRD_SHIFT			0x0
+#define DMA_DESQ_AWATTR_OFF	0x01C
+  /* Same flags as DMA_DESQ_ARATTR_OFF */
+#define DMA_DESQ_ALLOC_OFF	0x04C
+#define   DMA_DESQ_ALLOC_WRPTR_MASK		0xFFFF
+#define   DMA_DESQ_ALLOC_WRPTR_SHIFT		16
+#define DMA_IMSG_BALR_OFF	0x050
+#define DMA_IMSG_BAHR_OFF	0x054
+#define DMA_DESQ_CTRL_OFF	0x100
+#define	  DMA_DESQ_CTRL_32B			1
+#define   DMA_DESQ_CTRL_128B			7
+#define DMA_DESQ_STOP_OFF	0x800
+#define DMA_DESQ_DEALLOC_OFF	0x804
+#define DMA_DESQ_ADD_OFF	0x808
+
+/* XOR Global registers */
+#define GLOB_BW_CTRL		0x4
+#define   GLOB_BW_CTRL_NUM_OSTD_RD_SHIFT	0
+#define   GLOB_BW_CTRL_NUM_OSTD_RD_VAL		64
+#define   GLOB_BW_CTRL_NUM_OSTD_WR_SHIFT	8
+#define   GLOB_BW_CTRL_NUM_OSTD_WR_VAL		8
+#define   GLOB_BW_CTRL_RD_BURST_LEN_SHIFT	12
+#define   GLOB_BW_CTRL_RD_BURST_LEN_VAL		4
+#define   GLOB_BW_CTRL_WR_BURST_LEN_SHIFT	16
+#define	  GLOB_BW_CTRL_WR_BURST_LEN_VAL		4
+#define GLOB_PAUSE		0x014
+#define   GLOB_PAUSE_AXI_TIME_DIS_VAL		0x8
+#define GLOB_SYS_INT_CAUSE	0x200
+#define GLOB_SYS_INT_MASK	0x204
+#define GLOB_MEM_INT_CAUSE	0x220
+#define GLOB_MEM_INT_MASK	0x224
+
+#define MV_XOR_V2_MIN_DESC_SIZE		32
+#define MV_XOR_V2_EXT_DESC_SIZE		128
+
+#define MV_XOR_V2_DESC_RESERVED_SIZE	12
+#define MV_XOR_V2_DESC_BUFF_D_ADDR_SIZE	12
+
+#define MV_XOR_V2_CMD_LINE_NUM_MAX_D_BUF 8
+
+/* descriptors queue size */
+#define MV_XOR_V2_MAX_DESC_NUM	1024
+
+/**
+ * struct mv_xor_v2_descriptor - DMA HW descriptor
+ * @desc_id: used by S/W and is not affected by H/W.
+ * @flags: error and status flags
+ * @crc32_result: CRC32 calculation result
+ * @desc_ctrl: operation mode and control flags
+ * @buff_size: amount of bytes to be processed
+ * @fill_pattern_src_addr: Fill-Pattern or Source-Address and
+ * AW-Attributes
+ * @data_buff_addr: Source (and might be RAID6 destination)
+ * addresses of data buffers in RAID5 and RAID6
+ * @reserved: reserved
+ */
+struct mv_xor_v2_descriptor {
+	u16 desc_id;
+	u16 flags;
+	u32 crc32_result;
+	u32 desc_ctrl;
+
+	/* Definitions for desc_ctrl */
+#define DESC_NUM_ACTIVE_D_BUF_SHIFT	22
+#define DESC_OP_MODE_SHIFT		28
+#define DESC_OP_MODE_NOP		0	/* Idle operation */
+#define DESC_OP_MODE_MEMCPY		1	/* Pure-DMA operation */
+#define DESC_OP_MODE_MEMSET		2	/* Mem-Fill operation */
+#define DESC_OP_MODE_MEMINIT		3	/* Mem-Init operation */
+#define DESC_OP_MODE_MEM_COMPARE	4	/* Mem-Compare operation */
+#define DESC_OP_MODE_CRC32		5	/* CRC32 calculation */
+#define DESC_OP_MODE_XOR		6	/* RAID5 (XOR) operation */
+#define DESC_OP_MODE_RAID6		7	/* RAID6 P&Q-generation */
+#define DESC_OP_MODE_RAID6_REC		8	/* RAID6 Recovery */
+#define DESC_Q_BUFFER_ENABLE		BIT(16)
+#define DESC_P_BUFFER_ENABLE		BIT(17)
+#define DESC_IOD			BIT(27)
+
+	u32 buff_size;
+	u32 fill_pattern_src_addr[4];
+	u32 data_buff_addr[MV_XOR_V2_DESC_BUFF_D_ADDR_SIZE];
+	u32 reserved[MV_XOR_V2_DESC_RESERVED_SIZE];
+};
+
+/**
+ * struct mv_xor_v2_device - implements a xor device
+ * @sw_ll_lock: serializes enqueue/dequeue operations to the sw
+ * descriptors pool
+ * @push_lock: serializes enqueue operations to the DESCQ
+ * @cookie_lock: serializes of cookies control
+ * @dma_base: memory mapped DMA register base
+ * @glob_base: memory mapped global register base
+ * @irq_tasklet:
+ * @free_sw_desc: linked list of free SW descriptors
+ * @dmadev: dma device
+ * @dmachan: dma channel
+ * @hw_desq: HW descriptors queue
+ * @hw_desq_virt: virtual address of DESCQ
+ * @sw_desq: SW descriptors queue
+ * @desc_size: HW descriptor size
+*/
+struct mv_xor_v2_device {
+	spinlock_t sw_ll_lock;
+	spinlock_t push_lock;
+	spinlock_t cookie_lock;
+	void __iomem *dma_base;
+	void __iomem *glob_base;
+	struct tasklet_struct irq_tasklet;
+	struct list_head free_sw_desc;
+	struct dma_device dmadev;
+	struct dma_chan	dmachan;
+	dma_addr_t hw_desq;
+	struct mv_xor_v2_descriptor *hw_desq_virt;
+	struct mv_xor_v2_sw_desc *sw_desq;
+	int desc_size;
+};
+
+/**
+ * struct mv_xor_v2_sw_desc - implements a xor SW descriptor
+ * @idx: descriptor index
+ * @async_tx: support for the async_tx api
+ * @hw_desc: assosiated HW descriptor
+ * @free_list: node of the free SW descriprots list
+*/
+struct mv_xor_v2_sw_desc {
+	int idx;
+	struct dma_async_tx_descriptor async_tx;
+	struct mv_xor_v2_descriptor hw_desc;
+	struct list_head free_list;
+};
+
+/*
+ * Fill the data buffers to a HW descriptor
+ */
+static void mv_xor_v2_set_data_buffers(struct mv_xor_v2_device *xor_dev,
+					struct mv_xor_v2_descriptor *desc,
+					dma_addr_t src, int index)
+{
+	int arr_index = ((index >> 1) * 3);
+
+	/*
+	 * fill the buffer's addresses to the descriptor
+	 * The format of the buffers address for 2 sequential buffers X and X+1:
+	 *  First word: Buffer-DX-Address-Low[31:0]
+	 *  Second word:Buffer-DX+1-Address-Low[31:0]
+	 *  Third word: DX+1-Buffer-Address-High[47:32] [31:16]
+	 *		DX-Buffer-Address-High[47:32] [15:0]
+	 */
+	if ((index & 0x1) == 0) {
+		desc->data_buff_addr[arr_index] = lower_32_bits(src);
+
+		/* Clear lower 16-bits */
+		desc->data_buff_addr[arr_index + 2] &= ~0xFFFF;
+
+		/* Set them if we have a 64 bits DMA address */
+		if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT))
+			desc->data_buff_addr[arr_index + 2] |=
+				upper_32_bits(src) & 0xFFFF;
+	} else {
+		desc->data_buff_addr[arr_index + 1] =
+			lower_32_bits(src);
+
+		/* Clear upper 16-bits */
+		desc->data_buff_addr[arr_index + 2] &= ~0xFFFF0000;
+
+		/* Set them if we have a 64 bits DMA address */
+		if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT))
+			desc->data_buff_addr[arr_index + 2] |=
+				(upper_32_bits(src) & 0xFFFF) << 16;
+	}
+}
+
+/*
+ * Return the next available index in the DESQ.
+ */
+static inline int mv_xor_v2_get_desq_write_ptr(struct mv_xor_v2_device *xor_dev)
+{
+	/* read the index for the next available descriptor in the DESQ */
+	u32 reg = readl(xor_dev->dma_base + DMA_DESQ_ALLOC_OFF);
+
+	return ((reg >> DMA_DESQ_ALLOC_WRPTR_SHIFT)
+		& DMA_DESQ_ALLOC_WRPTR_MASK);
+}
+
+/*
+ * notify the engine of new descriptors, and update the available index.
+ */
+static void mv_xor_v2_add_desc_to_desq(struct mv_xor_v2_device *xor_dev,
+				       int num_of_desc)
+{
+	/* write the number of new descriptors in the DESQ. */
+	writel(num_of_desc, xor_dev->dma_base + DMA_DESQ_ADD_OFF);
+}
+
+/*
+ * free HW descriptors
+ */
+static void mv_xor_v2_free_desc_from_desq(struct mv_xor_v2_device *xor_dev,
+					  int num_of_desc)
+{
+	/* write the number of new descriptors in the DESQ. */
+	writel(num_of_desc, xor_dev->dma_base + DMA_DESQ_DEALLOC_OFF);
+}
+
+/*
+ * Set descriptor size
+ * Return the HW descriptor size in bytes
+ */
+static int mv_xor_v2_set_desc_size(struct mv_xor_v2_device *xor_dev)
+{
+	writel(DMA_DESQ_CTRL_128B,
+	       xor_dev->dma_base + DMA_DESQ_CTRL_OFF);
+
+	return MV_XOR_V2_EXT_DESC_SIZE;
+}
+
+/*
+ * Allocate resources for a channel
+ */
+static int mv_xor_v2_alloc_chan_resources(struct dma_chan *chan)
+{
+	/* nothing to be done here */
+	return 0;
+}
+
+/*
+ * Free resources of a channel
+ */
+void mv_xor_v2_free_chan_resources(struct dma_chan *chan)
+{
+	/* nothing to be done here */
+}
+
+/*
+ * Set the IMSG threshold
+ */
+static inline
+void mv_xor_v2_set_imsg_thrd(struct mv_xor_v2_device *xor_dev, int thrd_val)
+{
+	u32 reg;
+
+	reg = readl(xor_dev->dma_base + DMA_IMSG_THRD_OFF);
+
+	reg &= (~DMA_IMSG_THRD_MASK << DMA_IMSG_THRD_SHIFT);
+	reg |= (thrd_val << DMA_IMSG_THRD_SHIFT);
+
+	writel(reg, xor_dev->dma_base + DMA_IMSG_THRD_OFF);
+}
+
+static irqreturn_t mv_xor_v2_interrupt_handler(int irq, void *data)
+{
+	struct mv_xor_v2_device *xor_dev = data;
+
+	/*
+	 * Update IMSG threshold, to disable new IMSG interrupts until
+	 * end of the tasklet
+	 */
+	mv_xor_v2_set_imsg_thrd(xor_dev, MV_XOR_V2_MAX_DESC_NUM);
+
+	/* schedule a tasklet to handle descriptors callbacks */
+	tasklet_schedule(&xor_dev->irq_tasklet);
+
+	return IRQ_HANDLED;
+}
+
+/*
+ * submit a descriptor to the DMA engine
+ */
+static dma_cookie_t
+mv_xor_v2_tx_submit(struct dma_async_tx_descriptor *tx)
+{
+	int desq_ptr;
+	void *dest_hw_desc;
+	dma_cookie_t cookie;
+	struct mv_xor_v2_sw_desc *sw_desc =
+		container_of(tx, struct mv_xor_v2_sw_desc, async_tx);
+	struct mv_xor_v2_device *xor_dev =
+		container_of(tx->chan, struct mv_xor_v2_device, dmachan);
+
+	dev_dbg(xor_dev->dmadev.dev,
+		"%s sw_desc %p: async_tx %p\n",
+		__func__, sw_desc, &sw_desc->async_tx);
+
+	/* assign coookie */
+	spin_lock_bh(&xor_dev->cookie_lock);
+	cookie = dma_cookie_assign(tx);
+	spin_unlock_bh(&xor_dev->cookie_lock);
+
+	/* lock enqueue DESCQ */
+	spin_lock_bh(&xor_dev->push_lock);
+
+	/* get the next available slot in the DESQ */
+	desq_ptr = mv_xor_v2_get_desq_write_ptr(xor_dev);
+
+	/* copy the HW descriptor from the SW descriptor to the DESQ */
+	dest_hw_desc = ((void *)xor_dev->hw_desq_virt +
+			(xor_dev->desc_size * desq_ptr));
+
+	memcpy(dest_hw_desc, &sw_desc->hw_desc, xor_dev->desc_size);
+
+	/* update the DMA Engine with the new descriptor */
+	mv_xor_v2_add_desc_to_desq(xor_dev, 1);
+
+	/* unlock enqueue DESCQ */
+	spin_unlock_bh(&xor_dev->push_lock);
+
+	return cookie;
+}
+
+/*
+ * Prepare a SW descriptor
+ */
+static struct mv_xor_v2_sw_desc	*
+mv_xor_v2_prep_sw_desc(struct mv_xor_v2_device *xor_dev)
+{
+	struct mv_xor_v2_sw_desc *sw_desc;
+
+	/* Lock the channel */
+	spin_lock_bh(&xor_dev->sw_ll_lock);
+
+	/* get a free SW descriptor from the SW DESQ */
+	sw_desc = list_first_entry(&xor_dev->free_sw_desc,
+				   struct mv_xor_v2_sw_desc, free_list);
+	list_del(&sw_desc->free_list);
+
+	/* Release the channel */
+	spin_unlock_bh(&xor_dev->sw_ll_lock);
+
+	/* set the async tx descriptor */
+	dma_async_tx_descriptor_init(&sw_desc->async_tx, &xor_dev->dmachan);
+	sw_desc->async_tx.tx_submit = mv_xor_v2_tx_submit;
+	async_tx_ack(&sw_desc->async_tx);
+
+	return sw_desc;
+}
+
+/*
+ * Prepare a HW descriptor for a memcpy operation
+ */
+static struct dma_async_tx_descriptor *
+mv_xor_v2_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest,
+			  dma_addr_t src, size_t len, unsigned long flags)
+{
+	struct mv_xor_v2_sw_desc	*sw_desc;
+	struct mv_xor_v2_descriptor	*hw_descriptor;
+	struct mv_xor_v2_device		*xor_dev;
+
+	xor_dev = container_of(chan, struct mv_xor_v2_device, dmachan);
+
+	dev_dbg(xor_dev->dmadev.dev,
+		"%s len: %zu src %pad dest %pad flags: %ld\n",
+		__func__, len, &src, &dest, flags);
+
+	sw_desc = mv_xor_v2_prep_sw_desc(xor_dev);
+
+	sw_desc->async_tx.flags = flags;
+
+	/* set the HW descriptor */
+	hw_descriptor = &sw_desc->hw_desc;
+
+	/* save the SW descriptor ID to restore when operation is done */
+	hw_descriptor->desc_id = sw_desc->idx;
+
+	/* Set the MEMCPY control word */
+	hw_descriptor->desc_ctrl =
+		DESC_OP_MODE_MEMCPY << DESC_OP_MODE_SHIFT;
+
+	if (flags & DMA_PREP_INTERRUPT)
+		hw_descriptor->desc_ctrl |= DESC_IOD;
+
+	/* Set source address */
+	hw_descriptor->fill_pattern_src_addr[0] = lower_32_bits(src);
+
+	if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT))
+		hw_descriptor->fill_pattern_src_addr[1] =
+			upper_32_bits(src) & 0xFFFF;
+	else
+		hw_descriptor->fill_pattern_src_addr[1] = 0;
+
+	/* Set Destination address */
+	hw_descriptor->fill_pattern_src_addr[2] = lower_32_bits(dest);
+
+	if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT))
+		hw_descriptor->fill_pattern_src_addr[3] =
+			upper_32_bits(dest) & 0xFFFF;
+	else
+		hw_descriptor->fill_pattern_src_addr[3] = 0;
+
+	/* Set buffers size */
+	hw_descriptor->buff_size = len;
+
+	/* return the async tx descriptor */
+	return &sw_desc->async_tx;
+}
+
+/*
+ * Prepare a HW descriptor for a XOR operation
+ */
+static struct dma_async_tx_descriptor *
+mv_xor_v2_prep_dma_xor(struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
+		       unsigned int src_cnt, size_t len, unsigned long flags)
+{
+	struct mv_xor_v2_sw_desc	*sw_desc;
+	struct mv_xor_v2_descriptor	*hw_descriptor;
+	struct mv_xor_v2_device		*xor_dev;
+	int i;
+
+	BUG_ON(src_cnt > MV_XOR_V2_CMD_LINE_NUM_MAX_D_BUF || src_cnt < 1);
+
+	xor_dev = container_of(chan, struct mv_xor_v2_device, dmachan);
+
+	dev_dbg(xor_dev->dmadev.dev,
+		"%s src_cnt: %d len: %zu dest %pad flags: %ld\n",
+		__func__, src_cnt, len, &dest, flags);
+
+	BUG_ON(xor_dev->desc_size != MV_XOR_V2_EXT_DESC_SIZE);
+
+	sw_desc = mv_xor_v2_prep_sw_desc(xor_dev);
+
+	sw_desc->async_tx.flags = flags;
+
+	/* set the HW descriptor */
+	hw_descriptor = &sw_desc->hw_desc;
+
+	/* save the SW descriptor ID to restore when operation is done */
+	hw_descriptor->desc_id = sw_desc->idx;
+
+	/* Set the XOR control word */
+	hw_descriptor->desc_ctrl =
+		DESC_OP_MODE_XOR << DESC_OP_MODE_SHIFT;
+	hw_descriptor->desc_ctrl |= DESC_P_BUFFER_ENABLE;
+
+	if (flags & DMA_PREP_INTERRUPT)
+		hw_descriptor->desc_ctrl |= DESC_IOD;
+
+	/* Set the data buffers */
+	for (i = 0; i < src_cnt; i++)
+		mv_xor_v2_set_data_buffers(xor_dev, hw_descriptor, src[i], i);
+
+	hw_descriptor->desc_ctrl |=
+		src_cnt << DESC_NUM_ACTIVE_D_BUF_SHIFT;
+
+	/* Set Destination address */
+	hw_descriptor->fill_pattern_src_addr[2] = lower_32_bits(dest);
+	if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT))
+		hw_descriptor->fill_pattern_src_addr[3] =
+			upper_32_bits(dest) & 0xFFFF;
+	else
+		hw_descriptor->fill_pattern_src_addr[3] = 0;
+
+	/* Set buffers size */
+	hw_descriptor->buff_size = len;
+
+	/* return the async tx descriptor */
+	return &sw_desc->async_tx;
+}
+
+/*
+ * Prepare a HW descriptor for interrupt operation.
+ */
+static struct dma_async_tx_descriptor *
+mv_xor_v2_prep_dma_interrupt(struct dma_chan *chan, unsigned long flags)
+{
+	struct mv_xor_v2_sw_desc	*sw_desc;
+	struct mv_xor_v2_descriptor	*hw_descriptor;
+	struct mv_xor_v2_device		*xor_dev;
+
+	xor_dev = container_of(chan, struct mv_xor_v2_device, dmachan);
+
+	sw_desc = mv_xor_v2_prep_sw_desc(xor_dev);
+
+	/* set the HW descriptor */
+	hw_descriptor = &sw_desc->hw_desc;
+
+	/* save the SW descriptor ID to restore when operation is done */
+	hw_descriptor->desc_id = sw_desc->idx;
+
+	/* Set the INTERRUPT control word */
+	hw_descriptor->desc_ctrl =
+		DESC_OP_MODE_NOP << DESC_OP_MODE_SHIFT;
+	hw_descriptor->desc_ctrl |= DESC_IOD;
+
+	/* return the async tx descriptor */
+	return &sw_desc->async_tx;
+}
+
+/*
+ * poll for a transaction completion
+ */
+static enum dma_status mv_xor_v2_tx_status(struct dma_chan *chan,
+		dma_cookie_t cookie, struct dma_tx_state *txstate)
+{
+	/* return the transaction status */
+	return dma_cookie_status(chan, cookie, txstate);
+}
+
+/*
+ * push pending transactions to hardware
+ */
+static void mv_xor_v2_issue_pending(struct dma_chan *chan)
+{
+	struct mv_xor_v2_device *xor_dev =
+		container_of(chan, struct mv_xor_v2_device, dmachan);
+
+	/* Activate the channel */
+	writel(0, xor_dev->dma_base + DMA_DESQ_STOP_OFF);
+}
+
+static inline
+int mv_xor_v2_get_pending_params(struct mv_xor_v2_device *xor_dev,
+				 int *pending_ptr)
+{
+	u32 reg;
+
+	reg = readl(xor_dev->dma_base + DMA_DESQ_DONE_OFF);
+
+	/* get the next pending descriptor index */
+	*pending_ptr = ((reg >> DMA_DESQ_DONE_READ_PTR_SHIFT) &
+			DMA_DESQ_DONE_READ_PTR_MASK);
+
+	/* get the number of descriptors pending handle */
+	return ((reg >> DMA_DESQ_DONE_PENDING_SHIFT) &
+		DMA_DESQ_DONE_PENDING_MASK);
+}
+
+/*
+ * handle the descriptors after HW process
+ */
+static void mv_xor_v2_tasklet(unsigned long data)
+{
+	struct mv_xor_v2_device *xor_dev = (struct mv_xor_v2_device *) data;
+	int pending_ptr, num_of_pending, i;
+	struct mv_xor_v2_descriptor *next_pending_hw_desc = NULL;
+	struct mv_xor_v2_sw_desc *next_pending_sw_desc = NULL;
+
+	dev_dbg(xor_dev->dmadev.dev, "%s %d\n", __func__, __LINE__);
+
+	/* get thepending descriptors parameters */
+	num_of_pending = mv_xor_v2_get_pending_params(xor_dev, &pending_ptr);
+
+	/* next HW descriptor */
+	next_pending_hw_desc = (struct mv_xor_v2_descriptor *)
+		((void *)xor_dev->hw_desq_virt +
+		 (xor_dev->desc_size * (pending_ptr)));
+
+	/* loop over free descriptors */
+	for (i = 0; i < num_of_pending; i++) {
+
+		if (pending_ptr > MV_XOR_V2_MAX_DESC_NUM)
+			pending_ptr = 0;
+
+		if (next_pending_sw_desc != NULL)
+			next_pending_hw_desc++;
+
+		/* get the SW descriptor related to the HW descriptor */
+		next_pending_sw_desc =
+			&xor_dev->sw_desq[next_pending_hw_desc->desc_id];
+
+		/* call the callback */
+		if (next_pending_sw_desc->async_tx.cookie > 0) {
+			/*
+			 * update the channel's completed cookie - no
+			 * lock is required the IMSG threshold provide
+			 * the locking
+			 */
+			dma_cookie_complete(&next_pending_sw_desc->async_tx);
+
+			if (next_pending_sw_desc->async_tx.callback)
+				next_pending_sw_desc->async_tx.callback(
+				next_pending_sw_desc->async_tx.callback_param);
+
+			dma_descriptor_unmap(&next_pending_sw_desc->async_tx);
+		}
+
+		dma_run_dependencies(&next_pending_sw_desc->async_tx);
+
+		/* Lock the channel */
+		spin_lock_bh(&xor_dev->sw_ll_lock);
+
+		/* add the SW descriptor to the free descriptors list */
+		list_add(&next_pending_sw_desc->free_list,
+			 &xor_dev->free_sw_desc);
+
+		/* Release the channel */
+		spin_unlock_bh(&xor_dev->sw_ll_lock);
+
+		/* increment the next descriptor */
+		pending_ptr++;
+	}
+
+	if (num_of_pending != 0) {
+		/* free the descriptores */
+		mv_xor_v2_free_desc_from_desq(xor_dev, num_of_pending);
+	}
+
+	/* Update IMSG threshold, to enable new IMSG interrupts */
+	mv_xor_v2_set_imsg_thrd(xor_dev, 0);
+}
+
+/*
+ *	Set DMA Interrupt-message (IMSG) parameters
+ */
+static void mv_xor_v2_set_msi_msg(struct msi_desc *desc, struct msi_msg *msg)
+{
+	struct mv_xor_v2_device *xor_dev = dev_get_drvdata(desc->dev);
+
+	writel(msg->address_lo, xor_dev->dma_base + DMA_IMSG_BALR_OFF);
+	writel(msg->address_hi & 0xFFFF, xor_dev->dma_base + DMA_IMSG_BAHR_OFF);
+	writel(msg->data, xor_dev->dma_base + DMA_IMSG_CDAT_OFF);
+}
+
+static int mv_xor_v2_descq_init(struct mv_xor_v2_device *xor_dev)
+{
+	u32 reg;
+
+	/* write the DESQ size to the DMA engine */
+	writel(MV_XOR_V2_MAX_DESC_NUM, xor_dev->dma_base + DMA_DESQ_SIZE_OFF);
+
+	/* write the DESQ address to the DMA enngine*/
+	writel(xor_dev->hw_desq & 0xFFFFFFFF,
+	       xor_dev->dma_base + DMA_DESQ_BALR_OFF);
+	writel((xor_dev->hw_desq & 0xFFFF00000000) >> 32,
+	       xor_dev->dma_base + DMA_DESQ_BAHR_OFF);
+
+	/* enable the DMA engine */
+	writel(0, xor_dev->dma_base + DMA_DESQ_STOP_OFF);
+
+	/*
+	 * This is a temporary solution, until we activate the
+	 * SMMU. Set the attributes for reading & writing data buffers
+	 * & descriptors to:
+	 *
+	 *  - OuterShareable - Snoops will be performed on CPU caches
+	 *  - Enable cacheable - Bufferable, Modifiable, Other Allocate
+	 *    and Allocate
+	 */
+	reg = readl(xor_dev->dma_base + DMA_DESQ_ARATTR_OFF);
+	reg &= ~DMA_DESQ_ATTR_CACHE_MASK;
+	reg |= DMA_DESQ_ATTR_OUTER_SHAREABLE | DMA_DESQ_ATTR_CACHEABLE;
+	writel(reg, xor_dev->dma_base + DMA_DESQ_ARATTR_OFF);
+
+	reg = readl(xor_dev->dma_base + DMA_DESQ_AWATTR_OFF);
+	reg &= ~DMA_DESQ_ATTR_CACHE_MASK;
+	reg |= DMA_DESQ_ATTR_OUTER_SHAREABLE | DMA_DESQ_ATTR_CACHEABLE;
+	writel(reg, xor_dev->dma_base + DMA_DESQ_AWATTR_OFF);
+
+	/* BW CTRL - set values to optimize the XOR performance:
+	 *
+	 *  - Set WrBurstLen & RdBurstLen - the unit will issue
+	 *    maximum of 256B write/read transactions.
+	 * -  Limit the number of outstanding write & read data
+	 *    (OBB/IBB) requests to the maximal value.
+	*/
+	reg  = GLOB_BW_CTRL_NUM_OSTD_RD_VAL  << GLOB_BW_CTRL_NUM_OSTD_RD_SHIFT;
+	reg |= GLOB_BW_CTRL_NUM_OSTD_WR_VAL  << GLOB_BW_CTRL_NUM_OSTD_WR_SHIFT;
+	reg |= GLOB_BW_CTRL_RD_BURST_LEN_VAL << GLOB_BW_CTRL_RD_BURST_LEN_SHIFT;
+	reg |= GLOB_BW_CTRL_WR_BURST_LEN_VAL << GLOB_BW_CTRL_WR_BURST_LEN_SHIFT;
+	writel(reg, xor_dev->glob_base + GLOB_BW_CTRL);
+
+	/* Disable the AXI timer feature */
+	reg = readl(xor_dev->glob_base + GLOB_PAUSE);
+	reg |= GLOB_PAUSE_AXI_TIME_DIS_VAL;
+	writel(reg, xor_dev->glob_base + GLOB_PAUSE);
+
+	return 0;
+}
+
+static int mv_xor_v2_probe(struct platform_device *pdev)
+{
+	struct mv_xor_v2_device *xor_dev;
+	struct resource *res;
+	int i, ret = 0;
+	struct dma_device *dma_dev;
+	struct mv_xor_v2_sw_desc *sw_desc;
+	struct msi_desc *msi_desc;
+
+	dev_notice(&pdev->dev, "Marvell Version 2 XOR driver\n");
+
+	xor_dev = devm_kzalloc(&pdev->dev, sizeof(*xor_dev), GFP_KERNEL);
+	if (!xor_dev)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	xor_dev->dma_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(xor_dev->dma_base))
+		return PTR_ERR(xor_dev->dma_base);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	xor_dev->glob_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(xor_dev->glob_base))
+		return PTR_ERR(xor_dev->glob_base);
+
+	platform_set_drvdata(pdev, xor_dev);
+
+	ret = platform_msi_domain_alloc_irqs(&pdev->dev, 1,
+					     mv_xor_v2_set_msi_msg);
+	if (ret)
+		return ret;
+
+	msi_desc = first_msi_entry(&pdev->dev);
+	if (!msi_desc)
+		goto free_msi_irqs;
+
+	ret = devm_request_irq(&pdev->dev, msi_desc->irq,
+			       mv_xor_v2_interrupt_handler, 0,
+			       dev_name(&pdev->dev), xor_dev);
+	if (ret)
+		goto free_msi_irqs;
+
+	tasklet_init(&xor_dev->irq_tasklet, mv_xor_v2_tasklet,
+		     (unsigned long) xor_dev);
+
+	xor_dev->desc_size = mv_xor_v2_set_desc_size(xor_dev);
+
+	dma_cookie_init(&xor_dev->dmachan);
+
+	/*
+	 * allocate coherent memory for hardware descriptors
+	 * note: writecombine gives slightly better performance, but
+	 * requires that we explicitly flush the writes
+	 */
+	xor_dev->hw_desq_virt =
+		dma_alloc_coherent(&pdev->dev,
+				   xor_dev->desc_size * MV_XOR_V2_MAX_DESC_NUM,
+				   &xor_dev->hw_desq, GFP_KERNEL);
+	if (!xor_dev->hw_desq_virt) {
+		ret = -ENOMEM;
+		goto free_msi_irqs;
+	}
+
+	/* alloc memory for the SW descriptors */
+	xor_dev->sw_desq = devm_kzalloc(&pdev->dev, sizeof(*sw_desc) *
+					MV_XOR_V2_MAX_DESC_NUM, GFP_KERNEL);
+	if (!xor_dev->sw_desq) {
+		ret = -ENOMEM;
+		goto free_hw_desq;
+	}
+
+	/* init the channel locks */
+	spin_lock_init(&xor_dev->sw_ll_lock);
+	spin_lock_init(&xor_dev->push_lock);
+	spin_lock_init(&xor_dev->cookie_lock);
+
+	/* init the free SW descriptors list */
+	INIT_LIST_HEAD(&xor_dev->free_sw_desc);
+
+	/* add all SW descriptors to the free list */
+	for (i = 0; i < MV_XOR_V2_MAX_DESC_NUM; i++) {
+		xor_dev->sw_desq[i].idx = i;
+		list_add(&xor_dev->sw_desq[i].free_list,
+			 &xor_dev->free_sw_desc);
+	}
+
+	dma_dev = &xor_dev->dmadev;
+
+	/* set DMA capabilities */
+	dma_cap_zero(dma_dev->cap_mask);
+	dma_cap_set(DMA_MEMCPY, dma_dev->cap_mask);
+	dma_cap_set(DMA_XOR, dma_dev->cap_mask);
+	dma_cap_set(DMA_INTERRUPT, dma_dev->cap_mask);
+
+	/* init dma link list */
+	INIT_LIST_HEAD(&dma_dev->channels);
+
+	/* set base routines */
+	dma_dev->device_alloc_chan_resources =
+		mv_xor_v2_alloc_chan_resources;
+	dma_dev->device_free_chan_resources =
+		mv_xor_v2_free_chan_resources;
+	dma_dev->device_tx_status = mv_xor_v2_tx_status;
+	dma_dev->device_issue_pending = mv_xor_v2_issue_pending;
+	dma_dev->dev = &pdev->dev;
+
+	dma_dev->device_prep_dma_memcpy = mv_xor_v2_prep_dma_memcpy;
+	dma_dev->device_prep_dma_interrupt = mv_xor_v2_prep_dma_interrupt;
+	dma_dev->max_xor = 8;
+	dma_dev->device_prep_dma_xor = mv_xor_v2_prep_dma_xor;
+
+	xor_dev->dmachan.device = dma_dev;
+
+	list_add_tail(&xor_dev->dmachan.device_node,
+		      &dma_dev->channels);
+
+	mv_xor_v2_descq_init(xor_dev);
+
+	ret = dma_async_device_register(dma_dev);
+	if (ret)
+		goto free_hw_desq;
+
+	return 0;
+
+free_hw_desq:
+	dma_free_coherent(&pdev->dev,
+			  xor_dev->desc_size * MV_XOR_V2_MAX_DESC_NUM,
+			  xor_dev->hw_desq_virt, xor_dev->hw_desq);
+free_msi_irqs:
+	platform_msi_domain_free_irqs(&pdev->dev);
+	return ret;
+}
+
+static int mv_xor_v2_remove(struct platform_device *pdev)
+{
+	struct mv_xor_v2_device *xor_dev = platform_get_drvdata(pdev);
+
+	dma_async_device_unregister(&xor_dev->dmadev);
+
+	dma_free_coherent(&pdev->dev,
+			  xor_dev->desc_size * MV_XOR_V2_MAX_DESC_NUM,
+			  xor_dev->hw_desq_virt, xor_dev->hw_desq);
+
+	platform_msi_domain_free_irqs(&pdev->dev);
+
+	return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id mv_xor_v2_dt_ids[] = {
+	{ .compatible = "marvell,mv-xor-v2", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mv_xor_v2_dt_ids);
+#endif
+
+static struct platform_driver mv_xor_v2_driver = {
+	.probe		= mv_xor_v2_probe,
+	.remove		= mv_xor_v2_remove,
+	.driver		= {
+		.owner	= THIS_MODULE,
+		.name	= "mv_xor_v2",
+		.of_match_table = of_match_ptr(mv_xor_v2_dt_ids),
+	},
+};
+
+module_platform_driver(mv_xor_v2_driver);
+
+MODULE_DESCRIPTION("DMA engine driver for Marvell's Version 2 of XOR engine");
+MODULE_LICENSE("GPL");
+
-- 
2.6.4



From k at japko.eu  Mon Feb 15 00:08:17 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Mon, 15 Feb 2016 09:08:17 +0100
Subject: [linux-sunxi] Re: [PATCH v2 3/5] pinctrl: sunxi: Add H3 R_PIO
 controller support
In-Reply-To: <CACRpkdZkSzcb0fmghkvsfRHpsU-SsSGPP6YvstAW7387HS0xJw@mail.gmail.com>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
 <1454448113-18810-4-git-send-email-k@japko.eu>
 <CACRpkdZkSzcb0fmghkvsfRHpsU-SsSGPP6YvstAW7387HS0xJw@mail.gmail.com>
Message-ID: <20160215080816.GA6426@box2.japko.eu>

On Thu, Feb 11, 2016 at 02:21:15PM +0100, Linus Walleij wrote:
>On Tue, Feb 2, 2016 at 10:21 PM, Krzysztof Adamski <k at japko.eu> wrote:
>
>> H3 has additional PIO controller similar to what we can find on A23.
>> It's a 12 pin port, described in H3 Datasheet rev 1.1, pages 345-350.
>>
>> Signed-off-by: Krzysztof Adamski <k at japko.eu>
>
>Patch applied with Maxime's ACK.

Hi Linus,

You took v2 which does not add documentation for 
allwinner,sun8i-h3-r-pinctrl compatible that is added in this patch.  
This was fixed in v3. Should I prepare a patch for you that only adds 
this to the documentation or you can handle this by taking v3/v4 instead 
of this patch?

Best regards,
Krzysztof Adamski


From geert at linux-m68k.org  Mon Feb 15 00:16:14 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 09:16:14 +0100
Subject: ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8] arm64:
 renesas: r8a7795: Add Renesas R8A7795 SoC support)
Message-ID: <CAMuHMdU-q++XEgthKG=XOgnaq7TY899EsgMFHuWu4Skr5woLZg@mail.gmail.com>

Cc Marz Zyngier
Cc Dirk Behme
Cc devicetree
Cc linux-renesas-soc
Drop linux-sh

On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland <mark.rutland at arm.com> wrote:
>> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
>>> On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland <mark.rutland at arm.com> wrote:
>>> >> > +           gic: interrupt-controller at 0xf1010000 {
>>> >> +                     compatible = "arm,gic-400";
>>> >> +                     #interrupt-cells = <3>;
>>> >> +                     #address-cells = <0>;
>>> >> +                     interrupt-controller;
>>> >> +                     reg = <0x0 0xf1010000 0 0x1000>,
>>> >> +                           <0x0 0xf1020000 0 0x2000>;
>>> >> +                     interrupts = <GIC_PPI 9
>>> >> +                                     (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
>>> >> +             };
>>> >
>>> > No GICH and GICV?
>>>
>>> These seem to be defined in the "arm,gic-v3" DT bindings only, while this is
>>> an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>>
>> See the "GIC virtualization extensions (VGIC)" section in
>> Documentation/devicetree/bindings/arm/gic.txt
>
> DDI0471B_gic400_r0p1_trm.pdf says:
>
>     Address range GIC-400 functional block
>     A. 0x0000 - 0x0FFF Reserved
>     B. 0x1000 - 0x1FFF Distributor
>     C. 0x2000 - 0x3FFF CPU interfaces
>     D. 0x4000 - 0x4FFF Virtual interface control block, for the processor that
>                        is performing the access
>     E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
>                        selected by address bits [11:9]
>     F. 0x6000 - 0x7FFF Virtual CPU interfaces
>
> The DT binding document says:
>   1. The  first region is the GIC distributor register base and size.
>   2. The 2nd region is the GIC cpu interface register base and size.
>   3. The first additional region is the GIC virtual interface control register
>      base and size.
>   4. The 2nd additional region is the GIC virtual cpu interface register base
>      and size.
>
> Matching with the example:
>
>         interrupt-controller at 2c001000 {
>                 compatible = "arm,cortex-a15-gic";
>                 #interrupt-cells = <3>;
>                 interrupt-controller;
>                 reg = <0x2c001000 0x1000>,
>                       <0x2c002000 0x1000>,
>                       <0x2c004000 0x2000>,
>                       <0x2c006000 0x2000>;
>                 interrupts = <1 9 0xf04>;
>         };
>
> This means:
>   - reg entry 1. covers address range B,
>   - reg entry 2. covers address range C,
>   - reg entry 3. covers address ranges D _and_ E,
>   - reg entry 4. covers address range F.
>
> On R-Car Gen3, the base addresses are:
>
>     Distributor             : 0xF101_0000
>     CPU interfaces          : 0xF102_0000
>     Virtual interfaces      : 0xF104_0000
>     Virtual interfaces      : 0xF105_0000
>     Virtual CPU interfaces  : 0xF106_0000
>
> Note the additional multiplication factor of 16 in the offsets relative to
> the base address 0xf1000000 (e.g. 0x50000 instead of 0x5000).
>
> As address ranges D and E are merged in a single reg entry, how is the GIC
> driver supposed to know about this multiplication factor?
>
> Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From u.kleine-koenig at pengutronix.de  Mon Feb 15 00:17:50 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Mon, 15 Feb 2016 09:17:50 +0100
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160214200755.GB10826@n2100.arm.linux.org.uk>
References: <20160214165010.GA3189@roeck-us.net>
 <20160214195501.GA12289@pengutronix.de>
 <20160214200755.GB10826@n2100.arm.linux.org.uk>
Message-ID: <20160215081750.GD12289@pengutronix.de>

Hello Russell,

On Sun, Feb 14, 2016 at 08:07:55PM +0000, Russell King - ARM Linux wrote:
> On Sun, Feb 14, 2016 at 08:55:01PM +0100, Uwe Kleine-K?nig wrote:
> > So the unexpected abnormality here is that even though this device is
> > instantiated by dt, the driver doesn't provide any compatibles.
> > Either my expectation is wrong, then 67d02a1bbb33455 should be reverted
> 
> Your expectation is wrong.  AMBA primecell devices have hardware IDs
> and are matched to their drivers by those IDs.  Just like PCI.

pci devices don't appear in dt, do they? I don't see the connection
between amba devices and platform devices, see my other mail in this
thread for some more details.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From geert at linux-m68k.org  Mon Feb 15 00:21:29 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 09:21:29 +0100
Subject: [PATCH v2] arm64: dts: r8a7795: use GIC_* defines
In-Reply-To: <20160202133103.GK15554@verge.net.au>
References: <20160202133103.GK15554@verge.net.au>
Message-ID: <CAMuHMdXPk5Or5F6YDuicMxQioYqpf49m2XFvA25145xUyC0xAA@mail.gmail.com>

On Tue, Feb 2, 2016 at 2:31 PM, Simon Horman <horms+renesas at verge.net.au> wrote:
> Use GIC_* defines for GIC interrupt cells in r8a7795 device tree.
>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From wenyou.yang at atmel.com  Mon Feb 15 00:22:02 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Mon, 15 Feb 2016 16:22:02 +0800
Subject: [PATCH v9 0/2] power: act8945a: add charger driver for the sub-device
 of ACT8945A MFD
Message-ID: <1455524524-9359-1-git-send-email-wenyou.yang@atmel.com>

The ACT8945A is a Multi Function Device with the following subdevices:
 - Regulator
 - Charger

This patch set is to add regulator driver for ACT8945A.
It is based on the patch set:
	http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/405258.html

Changes in v9:
 - add check if charger->regmap is a NULL pointer.
 - collect Reviewed-by tag.

Changes in v8:
 - remove the OF table.
 - due to the mfd cell .of_compatible removal, use the platform
   device's parent of_node to read the property and assign it
   to the psy_cfg.of_node.
 - fix the typo.
 - due the mfd cell .of_compatible removal, update the compatibe
   description and example.

Changes in v7:
 - use the helper dev_get_regmap(pdev->dev.parent, NULL) to get regmap.
 - remove *act8945a_dev member from struct act8945a_charger.
 - remove *psy member from struct act8945a_charger.
 - merge _parse_dt() and _charger_config() functions, remove relevent
   members from struct act8945a_charger.
 - remove unused platform_set_drvdata(pdev, charger) statement.

Changes in v6:
 - change the type value to unsigned int.

Changes in v5:
 - remove spare spaces after #define.
 - add OF match table.
 - collect Reviewed-by from Krzysztof.

Changes in v4:
 - use spaces after #define, not tabs.
 - use BIT(n) macros to substitute (0x01 << x).
 - change dt properties with more legible name.
 - change the properties with more legible name, clearer description.

Changes in v3:
 - update the file header with short version license and author line.
 - remove unused member of struct act8945a_charger, dev.
 - action due to removing the member of stuct act8945a_dev, dev.
 - remove the unnecessary print out.
 - remove the unnecessary act8945a_charger_remove().
 - fix align of the code-style.

Changes in v2:
 1./ Substitute of_property_read_bool() for of_get_property().
 2./ Substitute devm_power_supply_register() for power_supply_register().
 3./ Use module_platform_driver(), instead of subsys_initcall().
 4./ Substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").

Wenyou Yang (2):
  power: act8945a: add charger driver for ACT8945A
  power: add documentation for ACT8945A's charger DT bindings

 .../devicetree/bindings/power/act8945a-charger.txt |   35 ++
 drivers/power/Kconfig                              |    7 +
 drivers/power/Makefile                             |    1 +
 drivers/power/act8945a_charger.c                   |  359 ++++++++++++++++++++
 4 files changed, 402 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/act8945a-charger.txt
 create mode 100644 drivers/power/act8945a_charger.c

-- 
1.7.9.5



From wenyou.yang at atmel.com  Mon Feb 15 00:22:03 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Mon, 15 Feb 2016 16:22:03 +0800
Subject: [PATCH v9 1/2] power: act8945a: add charger driver for ACT8945A
In-Reply-To: <1455524524-9359-1-git-send-email-wenyou.yang@atmel.com>
References: <1455524524-9359-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1455524524-9359-2-git-send-email-wenyou.yang@atmel.com>

This patch adds new driver for Active-semi ACT8945A ActivePath
charger (part of ACT8945A MFD driver) providing power supply class
information to userspace.

The driver can be configured through DT (such as, total timer,
precondition timer and input over-voltage threshold).

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---

Changes in v9:
 - add check if charger->regmap is a NULL pointer.
 - collect Reviewed-by tag.

Changes in v8:
 - remove the OF table.
 - due to the mfd cell .of_compatible removal, use the platform
   device's parent of_node to read the property and assign it
   to the psy_cfg.of_node.
 - fix the typo.

Changes in v7:
 - use the helper dev_get_regmap(pdev->dev.parent, NULL) to get regmap.
 - remove *act8945a_dev member from struct act8945a_charger.
 - remove *psy member from struct act8945a_charger.
 - merge _parse_dt() and _charger_config() functions, remove relevent
   members from struct act8945a_charger.
 - remove unused platform_set_drvdata(pdev, charger) statement.

Changes in v6:
 - change the type value to unsigned int.

Changes in v5:
 - remove spare spaces after #define.
 - add OF match table.

Changes in v4:
 - use spaces after #define, not tabs.
 - use BIT(n) macros to substitute (0x01 << x).
 - change dt properties with more legible name.

Changes in v3:
 - update the file header with short version license and author line.
 - remove unused member of struct act8945a_charger, dev.
 - action due to removing the member of stuct act8945a_dev, dev.
 - remove the unnecessary print out.
 - remove the unnecessary act8945a_charger_remove().
 - fix align of the code-style.

Changes in v2:
 1./ Substitute of_property_read_bool() for of_get_property().
 2./ Substitute devm_power_supply_register() for power_supply_register().
 3./ Use module_platform_driver(), instead of subsys_initcall().
 4./ Substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").

 drivers/power/Kconfig            |    7 +
 drivers/power/Makefile           |    1 +
 drivers/power/act8945a_charger.c |  359 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 367 insertions(+)
 create mode 100644 drivers/power/act8945a_charger.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 1ddd13c..ae75211 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -75,6 +75,13 @@ config BATTERY_88PM860X
 	help
 	  Say Y here to enable battery monitor for Marvell 88PM860x chip.
 
+config BATTERY_ACT8945A
+	tristate "Active-semi ACT8945A charger driver"
+	depends on MFD_ACT8945A
+	help
+	  Say Y here to enable support for power supply provided by
+	  Active-semi ActivePath ACT8945A charger.
+
 config BATTERY_DS2760
 	tristate "DS2760 battery driver (HP iPAQ & others)"
 	depends on W1 && W1_SLAVE_DS2760
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 0e4eab5..e46b75d 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_WM8350_POWER)	+= wm8350_power.o
 obj-$(CONFIG_TEST_POWER)	+= test_power.o
 
 obj-$(CONFIG_BATTERY_88PM860X)	+= 88pm860x_battery.o
+obj-$(CONFIG_BATTERY_ACT8945A)	+= act8945a_charger.o
 obj-$(CONFIG_BATTERY_DS2760)	+= ds2760_battery.o
 obj-$(CONFIG_BATTERY_DS2780)	+= ds2780_battery.o
 obj-$(CONFIG_BATTERY_DS2781)	+= ds2781_battery.o
diff --git a/drivers/power/act8945a_charger.c b/drivers/power/act8945a_charger.c
new file mode 100644
index 0000000..b5c00e4
--- /dev/null
+++ b/drivers/power/act8945a_charger.c
@@ -0,0 +1,359 @@
+/*
+ * Power supply driver for the Active-semi ACT8945A PMIC
+ *
+ * Copyright (C) 2015 Atmel Corporation
+ *
+ * Author: Wenyou Yang <wenyou.yang at atmel.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.
+ *
+ */
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/platform_device.h>
+#include <linux/power_supply.h>
+#include <linux/regmap.h>
+
+static const char *act8945a_charger_model = "ACT8945A";
+static const char *act8945a_charger_manufacturer = "Active-semi";
+
+/**
+ * ACT8945A Charger Register Map
+ */
+
+/* 0x70: Reserved */
+#define ACT8945A_APCH_CFG		0x71
+#define ACT8945A_APCH_STATUS		0x78
+#define ACT8945A_APCH_CTRL		0x79
+#define ACT8945A_APCH_STATE		0x7A
+
+/* ACT8945A_APCH_CFG */
+#define APCH_CFG_OVPSET			(0x3 << 0)
+#define APCH_CFG_OVPSET_6V6		(0x0 << 0)
+#define APCH_CFG_OVPSET_7V		(0x1 << 0)
+#define APCH_CFG_OVPSET_7V5		(0x2 << 0)
+#define APCH_CFG_OVPSET_8V		(0x3 << 0)
+#define APCH_CFG_PRETIMO		(0x3 << 2)
+#define APCH_CFG_PRETIMO_40_MIN		(0x0 << 2)
+#define APCH_CFG_PRETIMO_60_MIN		(0x1 << 2)
+#define APCH_CFG_PRETIMO_80_MIN		(0x2 << 2)
+#define APCH_CFG_PRETIMO_DISABLED	(0x3 << 2)
+#define APCH_CFG_TOTTIMO		(0x3 << 4)
+#define APCH_CFG_TOTTIMO_3_HOUR		(0x0 << 4)
+#define APCH_CFG_TOTTIMO_4_HOUR		(0x1 << 4)
+#define APCH_CFG_TOTTIMO_5_HOUR		(0x2 << 4)
+#define APCH_CFG_TOTTIMO_DISABLED	(0x3 << 4)
+#define APCH_CFG_SUSCHG			(0x1 << 7)
+
+#define APCH_STATUS_CHGDAT		BIT(0)
+#define APCH_STATUS_INDAT		BIT(1)
+#define APCH_STATUS_TEMPDAT		BIT(2)
+#define APCH_STATUS_TIMRDAT		BIT(3)
+#define APCH_STATUS_CHGSTAT		BIT(4)
+#define APCH_STATUS_INSTAT		BIT(5)
+#define APCH_STATUS_TEMPSTAT		BIT(6)
+#define APCH_STATUS_TIMRSTAT		BIT(7)
+
+#define APCH_CTRL_CHGEOCOUT		BIT(0)
+#define APCH_CTRL_INDIS			BIT(1)
+#define APCH_CTRL_TEMPOUT		BIT(2)
+#define APCH_CTRL_TIMRPRE		BIT(3)
+#define APCH_CTRL_CHGEOCIN		BIT(4)
+#define APCH_CTRL_INCON			BIT(5)
+#define APCH_CTRL_TEMPIN		BIT(6)
+#define APCH_CTRL_TIMRTOT		BIT(7)
+
+#define APCH_STATE_ACINSTAT		(0x1 << 1)
+#define APCH_STATE_CSTATE		(0x3 << 4)
+#define APCH_STATE_CSTATE_SHIFT		4
+#define APCH_STATE_CSTATE_DISABLED	0x00
+#define APCH_STATE_CSTATE_EOC		0x01
+#define APCH_STATE_CSTATE_FAST		0x02
+#define APCH_STATE_CSTATE_PRE		0x03
+
+struct act8945a_charger {
+	struct regmap *regmap;
+	bool battery_temperature;
+};
+
+static int act8945a_get_charger_state(struct regmap *regmap, int *val)
+{
+	int ret;
+	unsigned int status, state;
+
+	ret = regmap_read(regmap, ACT8945A_APCH_STATUS, &status);
+	if (ret < 0)
+		return ret;
+
+	ret = regmap_read(regmap, ACT8945A_APCH_STATE, &state);
+	if (ret < 0)
+		return ret;
+
+	state &= APCH_STATE_CSTATE;
+	state >>= APCH_STATE_CSTATE_SHIFT;
+
+	if (state == APCH_STATE_CSTATE_EOC) {
+		if (status & APCH_STATUS_CHGDAT)
+			*val = POWER_SUPPLY_STATUS_FULL;
+		else
+			*val = POWER_SUPPLY_STATUS_NOT_CHARGING;
+	} else if ((state == APCH_STATE_CSTATE_FAST) ||
+		   (state == APCH_STATE_CSTATE_PRE)) {
+		*val = POWER_SUPPLY_STATUS_CHARGING;
+	} else {
+		*val = POWER_SUPPLY_STATUS_NOT_CHARGING;
+	}
+
+	return 0;
+}
+
+static int act8945a_get_charge_type(struct regmap *regmap, int *val)
+{
+	int ret;
+	unsigned int state;
+
+	ret = regmap_read(regmap, ACT8945A_APCH_STATE, &state);
+	if (ret < 0)
+		return ret;
+
+	state &= APCH_STATE_CSTATE;
+	state >>= APCH_STATE_CSTATE_SHIFT;
+
+	switch (state) {
+	case APCH_STATE_CSTATE_PRE:
+		*val = POWER_SUPPLY_CHARGE_TYPE_TRICKLE;
+		break;
+	case APCH_STATE_CSTATE_FAST:
+		*val = POWER_SUPPLY_CHARGE_TYPE_FAST;
+		break;
+	case APCH_STATE_CSTATE_EOC:
+	case APCH_STATE_CSTATE_DISABLED:
+	default:
+		*val = POWER_SUPPLY_CHARGE_TYPE_NONE;
+	}
+
+	return 0;
+}
+
+static int act8945a_get_battery_health(struct act8945a_charger *charger,
+				       struct regmap *regmap, int *val)
+{
+	int ret;
+	unsigned int status;
+
+	ret = regmap_read(regmap, ACT8945A_APCH_STATUS, &status);
+	if (ret < 0)
+		return ret;
+
+	if (charger->battery_temperature && !(status & APCH_STATUS_TEMPDAT))
+		*val = POWER_SUPPLY_HEALTH_OVERHEAT;
+	else if (!(status & APCH_STATUS_INDAT))
+		*val = POWER_SUPPLY_HEALTH_OVERVOLTAGE;
+	else if (status & APCH_STATUS_TIMRDAT)
+		*val = POWER_SUPPLY_HEALTH_SAFETY_TIMER_EXPIRE;
+	else
+		*val = POWER_SUPPLY_HEALTH_GOOD;
+
+	return 0;
+}
+
+static enum power_supply_property act8945a_charger_props[] = {
+	POWER_SUPPLY_PROP_STATUS,
+	POWER_SUPPLY_PROP_CHARGE_TYPE,
+	POWER_SUPPLY_PROP_TECHNOLOGY,
+	POWER_SUPPLY_PROP_HEALTH,
+	POWER_SUPPLY_PROP_MODEL_NAME,
+	POWER_SUPPLY_PROP_MANUFACTURER
+};
+
+static int act8945a_charger_get_property(struct power_supply *psy,
+					 enum power_supply_property prop,
+					 union power_supply_propval *val)
+{
+	struct act8945a_charger *charger = power_supply_get_drvdata(psy);
+	struct regmap *regmap = charger->regmap;
+	int ret = 0;
+
+	switch (prop) {
+	case POWER_SUPPLY_PROP_STATUS:
+		ret = act8945a_get_charger_state(regmap, &val->intval);
+		break;
+	case POWER_SUPPLY_PROP_CHARGE_TYPE:
+		ret = act8945a_get_charge_type(regmap, &val->intval);
+		break;
+	case POWER_SUPPLY_PROP_TECHNOLOGY:
+		val->intval = POWER_SUPPLY_TECHNOLOGY_LION;
+		break;
+	case POWER_SUPPLY_PROP_HEALTH:
+		ret = act8945a_get_battery_health(charger,
+						  regmap, &val->intval);
+		break;
+	case POWER_SUPPLY_PROP_MODEL_NAME:
+		val->strval = act8945a_charger_model;
+		break;
+	case POWER_SUPPLY_PROP_MANUFACTURER:
+		val->strval = act8945a_charger_manufacturer;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	return ret;
+}
+
+static const struct power_supply_desc act8945a_charger_desc = {
+	.name		= "act8945a-charger",
+	.type		= POWER_SUPPLY_TYPE_BATTERY,
+	.get_property	= act8945a_charger_get_property,
+	.properties	= act8945a_charger_props,
+	.num_properties	= ARRAY_SIZE(act8945a_charger_props),
+};
+
+#define DEFAULT_TOTAL_TIME_OUT		3
+#define DEFAULT_PRE_TIME_OUT		40
+#define DEFAULT_INPUT_OVP_THRESHOLD	6600
+
+static int act8945a_charger_config(struct device *dev,
+				   struct act8945a_charger *charger)
+{
+	struct device_node *np = dev->of_node;
+	enum of_gpio_flags flags;
+	struct regmap *regmap = charger->regmap;
+
+	u32 total_time_out;
+	u32 pre_time_out;
+	u32 input_voltage_threshold;
+	int chglev_pin;
+
+	unsigned int value = 0;
+
+	if (!np) {
+		dev_err(dev, "no charger of node\n");
+		return -EINVAL;
+	}
+
+	charger->battery_temperature = of_property_read_bool(np,
+				"active-semi,check-battery-temperature");
+
+	chglev_pin = of_get_named_gpio_flags(np,
+				"active-semi,chglev-gpios", 0, &flags);
+
+	if (gpio_is_valid(chglev_pin)) {
+		gpio_set_value(chglev_pin,
+			       ((flags == OF_GPIO_ACTIVE_LOW) ? 0 : 1));
+	}
+
+	if (of_property_read_u32(np,
+				 "active-semi,input-voltage-threshold-microvolt",
+				 &input_voltage_threshold))
+		input_voltage_threshold = DEFAULT_INPUT_OVP_THRESHOLD;
+
+	if (of_property_read_u32(np,
+				 "active-semi,precondition-timeout",
+				 &pre_time_out))
+		pre_time_out = DEFAULT_PRE_TIME_OUT;
+
+	if (of_property_read_u32(np, "active-semi,total-timeout",
+				 &total_time_out))
+		total_time_out = DEFAULT_TOTAL_TIME_OUT;
+
+	switch (input_voltage_threshold) {
+	case 8000:
+		value |= APCH_CFG_OVPSET_8V;
+		break;
+	case 7500:
+		value |= APCH_CFG_OVPSET_7V5;
+		break;
+	case 7000:
+		value |= APCH_CFG_OVPSET_7V;
+		break;
+	case 6600:
+	default:
+		value |= APCH_CFG_OVPSET_6V6;
+		break;
+	}
+
+	switch (pre_time_out) {
+	case 60:
+		value |= APCH_CFG_PRETIMO_60_MIN;
+		break;
+	case 80:
+		value |= APCH_CFG_PRETIMO_80_MIN;
+		break;
+	case 0:
+		value |= APCH_CFG_PRETIMO_DISABLED;
+		break;
+	case 40:
+	default:
+		value |= APCH_CFG_PRETIMO_40_MIN;
+		break;
+	}
+
+	switch (total_time_out) {
+	case 4:
+		value |= APCH_CFG_TOTTIMO_4_HOUR;
+		break;
+	case 5:
+		value |= APCH_CFG_TOTTIMO_5_HOUR;
+		break;
+	case 0:
+		value |= APCH_CFG_TOTTIMO_DISABLED;
+		break;
+	case 3:
+	default:
+		value |= APCH_CFG_TOTTIMO_3_HOUR;
+		break;
+	}
+
+	return regmap_write(regmap, ACT8945A_APCH_CFG, value);
+}
+
+static int act8945a_charger_probe(struct platform_device *pdev)
+{
+	struct act8945a_charger *charger;
+	struct power_supply *psy;
+	struct power_supply_config psy_cfg = {};
+	int ret;
+
+	charger = devm_kzalloc(&pdev->dev, sizeof(*charger), GFP_KERNEL);
+	if (!charger)
+		return -ENOMEM;
+
+	charger->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+	if (!charger->regmap) {
+		dev_err(&pdev->dev, "Parent did not provide regmap\n");
+		return -EINVAL;
+	}
+
+	ret = act8945a_charger_config(pdev->dev.parent, charger);
+	if (ret)
+		return ret;
+
+	psy_cfg.of_node	= pdev->dev.parent->of_node;
+	psy_cfg.drv_data = charger;
+
+	psy = devm_power_supply_register(&pdev->dev,
+					 &act8945a_charger_desc,
+					 &psy_cfg);
+	if (IS_ERR(psy)) {
+		dev_err(&pdev->dev, "failed to register power supply\n");
+		return PTR_ERR(psy);
+	}
+
+	return 0;
+}
+
+static struct platform_driver act8945a_charger_driver = {
+	.driver	= {
+		.name = "act8945a-charger",
+	},
+	.probe	= act8945a_charger_probe,
+};
+module_platform_driver(act8945a_charger_driver);
+
+MODULE_DESCRIPTION("Active-semi ACT8945A ActivePath charger driver");
+MODULE_AUTHOR("Wenyou Yang <wenyou.yang at atmel.com>");
+MODULE_LICENSE("GPL");
-- 
1.7.9.5



From wenyou.yang at atmel.com  Mon Feb 15 00:22:04 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Mon, 15 Feb 2016 16:22:04 +0800
Subject: [PATCH v9 2/2] power: add documentation for ACT8945A's charger DT
 bindings
In-Reply-To: <1455524524-9359-1-git-send-email-wenyou.yang@atmel.com>
References: <1455524524-9359-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1455524524-9359-3-git-send-email-wenyou.yang@atmel.com>

This patch adds documentation for the DT bindings of the charger
subdevice of ACT8945A MFD.

Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---

Changes in v9: None
Changes in v8:
 - due the mfd cell .of_compatible removal, update the compatibe
   description and example.

Changes in v7: None
Changes in v6: None
Changes in v5:
 - collect Reviewed-by from Krzysztof.

Changes in v4:
 - change the properties with more legible name, clearer description.

Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/power/act8945a-charger.txt |   35 ++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/act8945a-charger.txt

diff --git a/Documentation/devicetree/bindings/power/act8945a-charger.txt b/Documentation/devicetree/bindings/power/act8945a-charger.txt
new file mode 100644
index 0000000..bea254c
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/act8945a-charger.txt
@@ -0,0 +1,35 @@
+Device-Tree bindings for charger of Active-semi ACT8945A Multi-Function Device
+
+Required properties:
+ - compatible: "active-semi,act8945a", please refer to ../mfd/act8945a.txt.
+ - active-semi,chglev-gpios: charge current level phandle with args
+   as described in ../gpio/gpio.txt.
+
+Optional properties:
+ - active-semi,check-battery-temperature: boolean to check the battery
+   temperature or not.
+ - active-semi,input-voltage-threshold-microvolt: unit: mV;
+   Specifies the charger's input over-voltage threshold value;
+   The value can be: 6600, 7000, 7500, 8000; default: 6600
+ - active-semi,precondition-timeout: unit: minutes;
+   Specifies the charger's PRECONDITION safety timer setting value;
+   The value can be: 40, 60, 80, 0; If 0, it means to disable this timer;
+   default: 40.
+ - active-semi,total-timeout: unit: hours;
+   Specifies the charger's total safety timer setting value;
+   The value can be: 3, 4, 5, 0; If 0, it means to disable this timer;
+   default: 3.
+
+Example:
+	pmic at 5b {
+		compatible = "active-semi,act8945a";
+		reg = <0x5b>;
+		status = "okay";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_charger_chglev>;
+		active-semi,chglev-gpios = <&pioA 12 GPIO_ACTIVE_HIGH>;
+		active-semi,input-voltage-threshold-microvolt = <6600>;
+		active-semi,precondition-timeout = <40>;
+		active-semi,total-timeout = <3>;
+	};
-- 
1.7.9.5



From mw at semihalf.com  Mon Feb 15 00:33:26 2016
From: mw at semihalf.com (Marcin Wojtas)
Date: Mon, 15 Feb 2016 09:33:26 +0100
Subject: [PATCH 1/3] clk: unconditionally recurse into clk/mvebu/
In-Reply-To: <1455521698-7905-2-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455521698-7905-2-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <CAPv3WKdnFg6AYNGexyEvMEjKmHadj4+CH5avnd=5d_HEKCTc2A@mail.gmail.com>

Hi Thomas,



2016-02-15 8:34 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni at free-electrons.com>:
> The drivers/clk/mvebu directory is only being built when
> CONFIG_PLAT_ORION=y. As we are going to support additional mvebu
> platforms in drivers/clk/mvebu, which don't have CONFIG_PLAT_ORION=y,
> we need to recurse into this directory regardless of the value of
> CONFIG_PLAT_ORION.
>
> Since all files in drivers/clk/mvebu/ are already conditionally
> compiled depending on various Kconfig options, we can recurse
> unconditionally into drivers/clk/mvebu without any other change.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  drivers/clk/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index b038e36..e08bb0e 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -61,7 +61,7 @@ obj-$(CONFIG_ARCH_MEDIATEK)           += mediatek/
>  ifeq ($(CONFIG_COMMON_CLK), y)
>  obj-$(CONFIG_ARCH_MMP)                 += mmp/
>  endif
> -obj-$(CONFIG_PLAT_ORION)               += mvebu/
> +obj-y                                  += mvebu/

I know it works with obj-y, but how about using
obj-$(CONFIG_ARCH_MVEBU)? A person editing this Kconfig in future
wouldn't have to run git blame in order to ensure with your commit
log, that he doesn't compile anything more than planned.

Best regards,
Marcin


From zhangqing at rock-chips.com  Mon Feb 15 00:38:45 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Mon, 15 Feb 2016 16:38:45 +0800
Subject: [PATCH v1 0/6] rockchip: power-domain: fix pm domain for support
 RK3399 SoC
Message-ID: <1455525531-14083-1-git-send-email-zhangqing@rock-chips.com>

fix some idle handling
support sub-power domain
add rk3399-power.h
modify power domain for RK3399 SoC
modify document for RK3399 Soc

Elaine Zhang (6):
  rockchip: power-domain: make idle handling optional
  rockchip: power-domain: allow domains only handling idle requests
  rockchip: power-domain: add support for sub-power domains
  dt/bindings: power: add RK3399 SoCs header for power-domain
  rockchip: power-domain: Modify power domain driver for rk3399
  dt/bindings: rockchip: modify document of Rockchip power domains

 .../bindings/soc/rockchip/power_domain.txt         |  21 ++++
 drivers/soc/rockchip/pm_domains.c                  | 128 ++++++++++++++++++++-
 include/dt-bindings/power/rk3399-power.h           |  53 +++++++++
 3 files changed, 197 insertions(+), 5 deletions(-)
 create mode 100644 include/dt-bindings/power/rk3399-power.h

-- 
1.9.1




From zhangqing at rock-chips.com  Mon Feb 15 00:38:47 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Mon, 15 Feb 2016 16:38:47 +0800
Subject: [PATCH v1 2/6] rockchip: power-domain: allow domains only handling
 idle requests
In-Reply-To: <1455525531-14083-1-git-send-email-zhangqing@rock-chips.com>
References: <1455525531-14083-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1455525531-14083-3-git-send-email-zhangqing@rock-chips.com>

On some Rockchip SoC there exist child-domains only handling their
idle state with the actual power-state handled by a parent-domain.

So allow such types of domains. For them, we can determine their
state (on/of) by checking the inverse idle-state instead.

There exist one special case if both idle as well power handling
were set as not present, but as the domain-data is defined in the
code itself, we can expect the reasonable developer to define them

So allow such types of domains. For them, we can determine their
state (on/of) by checking the inverse idle-state instead.

There exist one special case if both idle as well power handling
were set as not present, but as the domain-data is defined in the
code itself, we can expect the reasonable developer to define them
in a correct, without adding more checks.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 drivers/soc/rockchip/pm_domains.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 3dcc611..350527b 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -68,8 +68,8 @@ struct rockchip_pmu {
 
 #define DOMAIN(pwr, status, req, idle, ack)	\
 {						\
-	.pwr_mask = BIT(pwr),			\
-	.status_mask = BIT(status),		\
+	.pwr_mask = (pwr >= 0) ? BIT(pwr) : OVERFLOW_MASK,		\
+	.status_mask = (status >= 0) ? BIT(status) : OVERFLOW_MASK,\
 	.req_mask = (req >= 0) ? BIT(req) : OVERFLOW_MASK,		\
 	.idle_mask = (idle >= 0) ? BIT(idle) : OVERFLOW_MASK,	\
 	.ack_mask = (ack >= 0) ? BIT(ack) : OVERFLOW_MASK,		\
@@ -121,6 +121,10 @@ static bool rockchip_pmu_domain_is_on(struct rockchip_pm_domain *pd)
 	struct rockchip_pmu *pmu = pd->pmu;
 	unsigned int val;
 
+	/* check idle status for idle-only domains */
+	if (pd->info->status_mask >= OVERFLOW_MASK)
+		return !rockchip_pmu_domain_is_idle(pd);
+
 	regmap_read(pmu->regmap, pmu->info->status_offset, &val);
 
 	/* 1'b0: power on, 1'b1: power off */
@@ -132,6 +136,9 @@ static void rockchip_do_pmu_set_power_domain(struct rockchip_pm_domain *pd,
 {
 	struct rockchip_pmu *pmu = pd->pmu;
 
+	if (pd->info->pwr_mask >= OVERFLOW_MASK)
+		return;
+
 	regmap_update_bits(pmu->regmap, pmu->info->pwr_offset,
 			   pd->info->pwr_mask, on ? 0 : -1U);
 
-- 
1.9.1




From zhangqing at rock-chips.com  Mon Feb 15 00:38:46 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Mon, 15 Feb 2016 16:38:46 +0800
Subject: [PATCH v1 1/6] rockchip: power-domain: make idle handling optional
In-Reply-To: <1455525531-14083-1-git-send-email-zhangqing@rock-chips.com>
References: <1455525531-14083-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1455525531-14083-2-git-send-email-zhangqing@rock-chips.com>

Not all new socs need to handle idle states on domain state changes,
so add the possibility to make them optional.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 drivers/soc/rockchip/pm_domains.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 6cdffb1..3dcc611 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -63,14 +63,16 @@ struct rockchip_pmu {
 };
 
 #define to_rockchip_pd(gpd) container_of(gpd, struct rockchip_pm_domain, genpd)
+#define NULL_BIT		-32
+#define OVERFLOW_MASK		32
 
 #define DOMAIN(pwr, status, req, idle, ack)	\
 {						\
 	.pwr_mask = BIT(pwr),			\
 	.status_mask = BIT(status),		\
-	.req_mask = BIT(req),			\
-	.idle_mask = BIT(idle),			\
-	.ack_mask = BIT(ack),			\
+	.req_mask = (req >= 0) ? BIT(req) : OVERFLOW_MASK,		\
+	.idle_mask = (idle >= 0) ? BIT(idle) : OVERFLOW_MASK,	\
+	.ack_mask = (ack >= 0) ? BIT(ack) : OVERFLOW_MASK,		\
 }
 
 #define DOMAIN_RK3288(pwr, status, req)		\
@@ -96,6 +98,9 @@ static int rockchip_pmu_set_idle_request(struct rockchip_pm_domain *pd,
 	struct rockchip_pmu *pmu = pd->pmu;
 	unsigned int val;
 
+	if (pd_info->req_mask >= OVERFLOW_MASK)
+		return 0;
+
 	regmap_update_bits(pmu->regmap, pmu->info->req_offset,
 			   pd_info->req_mask, idle ? -1U : 0);
 
-- 
1.9.1




From zhangqing at rock-chips.com  Mon Feb 15 00:38:48 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Mon, 15 Feb 2016 16:38:48 +0800
Subject: [PATCH v1 3/6] rockchip: power-domain: add support for sub-power
 domains
In-Reply-To: <1455525531-14083-1-git-send-email-zhangqing@rock-chips.com>
References: <1455525531-14083-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1455525531-14083-4-git-send-email-zhangqing@rock-chips.com>

This patch adds support for making one power domain a sub-domain of
other domain. This is useful for modeling power dependences,
which needs to have more than one power domain enabled to be operational.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 drivers/soc/rockchip/pm_domains.c | 51 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 350527b..c4c2aea 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -372,6 +372,51 @@ static void rockchip_configure_pd_cnt(struct rockchip_pmu *pmu,
 	regmap_write(pmu->regmap, domain_reg_offset + 4, count);
 }
 
+static int rockchip_pm_add_subdomain(struct rockchip_pmu *pmu,
+				     struct device_node *parent)
+{
+	struct device_node *np;
+	int error;
+
+	for_each_child_of_node(parent, np) {
+		struct generic_pm_domain *child_domain, *parent_domain;
+		u32 idx = ~0;
+
+		if (of_property_read_u32(parent, "reg", &idx)) {
+			dev_err(pmu->dev,
+				"%s: failed to retrieve domain id (reg)\n",
+				parent->name);
+			return -EINVAL;
+		}
+		parent_domain = pmu->genpd_data.domains[idx];
+
+		error = rockchip_pm_add_one_domain(pmu, np);
+		if (error) {
+			dev_err(pmu->dev, "failed to handle node %s: %d\n",
+				np->name, error);
+			return -ENODEV;
+		}
+
+		if (of_property_read_u32(np, "reg", &idx)) {
+			dev_err(pmu->dev,
+				"%s: failed to retrieve domain id (reg)\n",
+				np->name);
+			return -EINVAL;
+		}
+		child_domain = pmu->genpd_data.domains[idx];
+
+		if (pm_genpd_add_subdomain(parent_domain, child_domain))
+			pr_warn("%s failed to add subdomain: %s\n",
+				parent_domain->name, child_domain->name);
+		else
+			pr_warn("%s add subdomain: %s\n",
+				parent_domain->name, child_domain->name);
+
+		rockchip_pm_add_subdomain(pmu, np);
+	}
+	return 0;
+}
+
 static int rockchip_pm_domain_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -437,6 +482,12 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
 				node->name, error);
 			goto err_out;
 		}
+		error = rockchip_pm_add_subdomain(pmu, node);
+		if (error < 0) {
+			dev_err(dev, "failed to handle subdomain node %s: %d\n",
+				node->name, error);
+			goto err_out;
+		}
 	}
 
 	if (error) {
-- 
1.9.1




From zhangqing at rock-chips.com  Mon Feb 15 00:38:49 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Mon, 15 Feb 2016 16:38:49 +0800
Subject: [PATCH v1 4/6] dt/bindings: power: add RK3399 SoCs header for
 power-domain
In-Reply-To: <1455525531-14083-1-git-send-email-zhangqing@rock-chips.com>
References: <1455525531-14083-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1455525531-14083-5-git-send-email-zhangqing@rock-chips.com>

According to a description from TRM, add all the power domains

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 include/dt-bindings/power/rk3399-power.h | 53 ++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3399-power.h

diff --git a/include/dt-bindings/power/rk3399-power.h b/include/dt-bindings/power/rk3399-power.h
new file mode 100644
index 0000000..69fbd67
--- /dev/null
+++ b/include/dt-bindings/power/rk3399-power.h
@@ -0,0 +1,53 @@
+#ifndef __DT_BINDINGS_POWER_RK3399_POWER_H__
+#define __DT_BINDINGS_POWER_RK3399_POWER_H__
+
+/* VD_CORE_L */
+#define RK3399_PD_A53_L0	0
+#define RK3399_PD_A53_L1	1
+#define RK3399_PD_A53_L2	2
+#define RK3399_PD_A53_L3	3
+#define RK3399_PD_SCU_L		4
+
+/* VD_CORE_B */
+#define RK3399_PD_A72_B0	5
+#define RK3399_PD_A72_B1	6
+#define RK3399_PD_SCU_B		7
+
+/* VD_CENTER */
+#define RK3399_PD_CENTER	8
+#define RK3399_PD_VCODEC	9
+#define RK3399_PD_RGA		10
+#define RK3399_PD_IEP		11
+#define RK3399_PD_VDU		12
+
+/* VD_LOGIC */
+#define RK3399_PD_PERILP	13
+#define RK3399_PD_PERIHP	14
+#define RK3399_PD_VIO		15
+#define RK3399_PD_VO		16
+#define RK3399_PD_VOPB		17
+#define RK3399_PD_VOPL		18
+#define RK3399_PD_ISP0		19
+#define RK3399_PD_ISP1		20
+#define RK3399_PD_HDCP		21
+#define RK3399_PD_TCPD0		22
+#define RK3399_PD_TCPD1		23
+#define RK3399_PD_GIC		24
+#define RK3399_PD_ALIVE		25
+#define RK3399_PD_USB3		26
+#define RK3399_PD_SD		27
+#define RK3399_PD_CCI		28
+#define RK3399_PD_CCI0		29
+#define RK3399_PD_CCI1		30
+#define RK3399_PD_GMAC		31
+#define RK3399_PD_EMMC		32
+#define RK3399_PD_EDP		33
+#define RK3399_PD_SDIOAUDIO	34
+
+/* VD_GPU */
+#define RK3399_PD_GPU		35
+
+/* VD_PMU */
+#define RK3399_PD_PMU		36
+
+#endif
-- 
1.9.1




From geert at linux-m68k.org  Mon Feb 15 00:46:05 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 09:46:05 +0100
Subject: [PATCH v2] ARM: mm: mark section-aligned portion of rodata NX
In-Reply-To: <4300378.sBT9DdB2Gc@wuerfel>
References: <20151207223534.GA13722@www.outflux.net>
 <CAGXu5jLDK8eVO2kUD1cB3TArL8k8pF=igc3O04Fa40QgQ2pwNw@mail.gmail.com>
 <20160211180032.GY10826@n2100.arm.linux.org.uk>
 <4300378.sBT9DdB2Gc@wuerfel>
Message-ID: <CAMuHMdVUXH-_PB+DNuCbTTXD6Zmy4iG9i=-ame4PDVAOKv2tvQ@mail.gmail.com>

On Fri, Feb 12, 2016 at 10:45 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 11 February 2016 18:00:32 Russell King - ARM Linux wrote:
>> On Fri, Jan 22, 2016 at 01:19:03PM -0800, Kees Cook wrote:
>> > On Tue, Dec 8, 2015 at 10:38 AM, Kees Cook <keescook at chromium.org> wrote:
>> > > On Mon, Dec 7, 2015 at 11:47 PM, Ard Biesheuvel
>> > > <ard.biesheuvel at linaro.org> wrote:
>> > >> On 7 December 2015 at 23:35, Kees Cook <keescook at chromium.org> wrote:
>> > >>>  /*
>> > >>> + * Without CONFIG_DEBUG_ALIGN_RODATA, __start_rodata_section_aligned will
>> > >>> + * be the first section-aligned location after __start_rodata. Otherwise,
>> > >>> + * it will be equal to __start_rodata.
>> > >>> + */
>> > >>> +__start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
>> ...
>>
>> I'm afraid this causes build errors on two configurations:
>>
>> ./arch/arm/kernel/vmlinux.lds:701: undefined symbol `SECTION_SHIFT' referenced in expression
>>
>> which I think is down to the new __start_rodata_section_aligned line.
>>
>> Olof's builder errored out with this for both allnoconfig and
>> lpc18xx_defconfig builds.  Both probably due to CONFIG_MMU being
>> unset, and hence no definition for SECTION_SHIFT.
>>
>> I think you need to make this conditional on CONFIG_MMU.
>
> I've hit another problem with this patch, when using XIP_KERNEL, I now see
>
> arch/arm/mm/built-in.o:(.data+0x4bc): undefined reference to `__start_rodata_section_aligned'
>
> in linux-next, apparently because of the combination with "ARM: 8513/1: xip: Move
> XIP linking to a separate file".

Is this due to the copy not taking into account the recent changes to
vmlinux.lds.S?

"git show 538bf4694898b19e" with copy-rename detection shows:

copy from arch/arm/kernel/vmlinux.lds.S
copy to arch/arm/kernel/vmlinux-xip.lds.S
index a6e395c53a48e045..6f59ef290289e078 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux-xip.lds.S

[...]

@@ -117,7 +114,7 @@ SECTIONS
                        ARM_CPU_KEEP(PROC_INFO)
        }

-#ifdef CONFIG_DEBUG_ALIGN_RODATA
+#ifdef CONFIG_DEBUG_RODATA
        . = ALIGN(1<<SECTION_SHIFT);
 #endif
        RO_DATA(PAGE_SIZE)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From zhangqing at rock-chips.com  Mon Feb 15 00:42:24 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Mon, 15 Feb 2016 16:42:24 +0800
Subject: [PATCH v1 5/6] rockchip: power-domain: Modify power domain driver for
 rk3399
Message-ID: <1455525744-14140-1-git-send-email-zhangqing@rock-chips.com>

This driver is modified to support RK3399 SoC.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 drivers/soc/rockchip/pm_domains.c | 55 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index c4c2aea..9affcec 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -19,6 +19,7 @@
 #include <linux/mfd/syscon.h>
 #include <dt-bindings/power/rk3288-power.h>
 #include <dt-bindings/power/rk3368-power.h>
+#include <dt-bindings/power/rk3399-power.h>
 
 struct rockchip_domain_info {
 	int pwr_mask;
@@ -81,6 +82,9 @@ struct rockchip_pmu {
 #define DOMAIN_RK3368(pwr, status, req)		\
 	DOMAIN(pwr, status, req, (req) + 16, req)
 
+#define DOMAIN_RK3399(pwr, status, req)                \
+	DOMAIN(pwr, status, req, req, req)
+
 static bool rockchip_pmu_domain_is_idle(struct rockchip_pm_domain *pd)
 {
 	struct rockchip_pmu *pmu = pd->pmu;
@@ -519,6 +523,36 @@ static const struct rockchip_domain_info rk3368_pm_domains[] = {
 	[RK3368_PD_GPU_1]	= DOMAIN_RK3368(17, 16, 2),
 };
 
+static const struct rockchip_domain_info rk3399_pm_domains[] = {
+	[RK3399_PD_TCPD0]       = DOMAIN_RK3399(8, 8, NULL_BIT),
+	[RK3399_PD_TCPD1]       = DOMAIN_RK3399(9, 9, NULL_BIT),
+	[RK3399_PD_CCI]         = DOMAIN_RK3399(10, 10, NULL_BIT),
+	[RK3399_PD_CCI0]        = DOMAIN_RK3399(NULL_BIT, NULL_BIT, 15),
+	[RK3399_PD_CCI1]        = DOMAIN_RK3399(NULL_BIT, NULL_BIT, 16),
+	[RK3399_PD_PERILP]      = DOMAIN_RK3399(11, 11, 1),
+	[RK3399_PD_PERIHP]      = DOMAIN_RK3399(12, 12, 2),
+	[RK3399_PD_CENTER]      = DOMAIN_RK3399(13, 13, 14),
+	[RK3399_PD_VIO]         = DOMAIN_RK3399(14, 14, 17),
+	[RK3399_PD_GPU]         = DOMAIN_RK3399(15, 15, 0),
+	[RK3399_PD_VCODEC]      = DOMAIN_RK3399(16, 16, 3),
+	[RK3399_PD_VDU]         = DOMAIN_RK3399(17, 17, 4),
+	[RK3399_PD_RGA]         = DOMAIN_RK3399(18, 18, 5),
+	[RK3399_PD_IEP]         = DOMAIN_RK3399(19, 19, 6),
+	[RK3399_PD_VO]          = DOMAIN_RK3399(20, 20, NULL_BIT),
+	[RK3399_PD_VOPB]        = DOMAIN_RK3399(NULL_BIT, NULL_BIT, 7),
+	[RK3399_PD_VOPL]        = DOMAIN_RK3399(NULL_BIT, NULL_BIT, 8),
+	[RK3399_PD_ISP0]        = DOMAIN_RK3399(22, 22, 9),
+	[RK3399_PD_ISP1]        = DOMAIN_RK3399(23, 23, 10),
+	[RK3399_PD_HDCP]        = DOMAIN_RK3399(24, 24, 11),
+	[RK3399_PD_GMAC]        = DOMAIN_RK3399(25, 25, 23),
+	[RK3399_PD_EMMC]        = DOMAIN_RK3399(26, 26, 24),
+	[RK3399_PD_USB3]        = DOMAIN_RK3399(27, 27, 12),
+	[RK3399_PD_EDP]         = DOMAIN_RK3399(28, 28, 22),
+	[RK3399_PD_GIC]         = DOMAIN_RK3399(29, 29, 27),
+	[RK3399_PD_SD]          = DOMAIN_RK3399(30, 30, 28),
+	[RK3399_PD_SDIOAUDIO]   = DOMAIN_RK3399(31, 31, 29),
+};
+
 static const struct rockchip_pmu_info rk3288_pmu = {
 	.pwr_offset = 0x08,
 	.status_offset = 0x0c,
@@ -553,6 +587,23 @@ static const struct rockchip_pmu_info rk3368_pmu = {
 	.domain_info = rk3368_pm_domains,
 };
 
+static const struct rockchip_pmu_info rk3399_pmu = {
+	.pwr_offset = 0x14,
+	.status_offset = 0x18,
+	.req_offset = 0x60,
+	.idle_offset = 0x64,
+	.ack_offset = 0x68,
+
+	.core_pwrcnt_offset = 0x9c,
+	.gpu_pwrcnt_offset = 0xa4,
+
+	.core_power_transition_time = 24,
+	.gpu_power_transition_time = 24,
+
+	.num_domains = ARRAY_SIZE(rk3399_pm_domains),
+	.domain_info = rk3399_pm_domains,
+};
+
 static const struct of_device_id rockchip_pm_domain_dt_match[] = {
 	{
 		.compatible = "rockchip,rk3288-power-controller",
@@ -562,6 +613,10 @@ static const struct of_device_id rockchip_pm_domain_dt_match[] = {
 		.compatible = "rockchip,rk3368-power-controller",
 		.data = (void *)&rk3368_pmu,
 	},
+	{
+		.compatible = "rockchip,rk3399-power-controller",
+		.data = (void *)&rk3399_pmu,
+	},
 	{ /* sentinel */ },
 };
 
-- 
1.9.1




From eun.taik.lee at samsung.com  Mon Feb 15 00:46:19 2016
From: eun.taik.lee at samsung.com (EunTaik Lee)
Date: Mon, 15 Feb 2016 08:46:19 +0000 (GMT)
Subject: [PATCH] arm64: add alignment fault hanling
Message-ID: <1891145150.915921455525975284.JavaMail.weblogic@epmlwas09b>

Userspace memory is mapped as below:
F2A7F000--F2A7FFFF Normal Memory
F2A80000--F2A80FFF Device nGnRnE

And that userspace application makes a system call
as below:

-009 |do_strncpy_from_user(inline)
-009 |strncpy_from_user()
-010 |getname_flags()
-011 |user_path_at_empty()
-012 |user_path_at()
-013 |SYSC_faccessat(inline)
-013 |sys_faccessat()
-014 |__sys_trace(asm)
 --> |exception

The string spans from 0xF2A7FFC1 to 0xF2A7FFFB.

When do_strncpy_from_user() reads the last (unsigned long)
value, the alignement fault is triggered. The 8 byte
from 0xF2A7FFC1 spans to the next page that is mapped as
Device nGnRnE, which does not allow an unaligned access,
causes the abort.

The instruction which caused the alignment fault is registered
in the fixup table but the exception handler does not reach there.

This patch registers a alignment fault handler and fixes up the
pc if appropriate.

Signed-off-by: Eun Taik Lee <eun.taik.lee at samsung.com>
---
 arch/arm64/mm/fault.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 19211c4..8257d4f 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -371,6 +371,16 @@ static int __kprobes do_translation_fault(unsigned long addr,
 	return 0;
 }
 
+static int __kprobes do_alignment_fault(unsigned long addr,
+					  unsigned int esr,
+					  struct pt_regs *regs)
+{
+	if (addr >= TASK_SIZE && fixup_exception(regs))
+		return 0;
+
+	return 1;
+}
+
 /*
  * This abort handler always returns "fault".
  */
@@ -418,7 +428,7 @@ static struct fault_info {
 	{ do_bad,		SIGBUS,  0,		"synchronous parity error (translation table walk" },
 	{ do_bad,		SIGBUS,  0,		"synchronous parity error (translation table walk" },
 	{ do_bad,		SIGBUS,  0,		"unknown 32"			},
-	{ do_bad,		SIGBUS,  BUS_ADRALN,	"alignment fault"		},
+	{ do_alignment_fault,	SIGBUS,  BUS_ADRALN,	"alignment fault"		},
 	{ do_bad,		SIGBUS,  0,		"debug event"			},
 	{ do_bad,		SIGBUS,  0,		"unknown 35"			},
 	{ do_bad,		SIGBUS,  0,		"unknown 36"			},
-- 
1.9.1

From zhangqing at rock-chips.com  Mon Feb 15 00:42:58 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Mon, 15 Feb 2016 16:42:58 +0800
Subject: [PATCH v1 6/6] dt/bindings: rockchip: modify document of Rockchip
 power domains
Message-ID: <1455525778-14190-1-git-send-email-zhangqing@rock-chips.com>

Add binding documentation for the power domains
found on Rockchip RK3399 SoCs.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 .../bindings/soc/rockchip/power_domain.txt          | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
index 13dc6a3..c65d401 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -7,6 +7,7 @@ Required properties for power domain controller:
 - compatible: Should be one of the following.
 	"rockchip,rk3288-power-controller" - for RK3288 SoCs.
 	"rockchip,rk3368-power-controller" - for RK3368 SoCs.
+	"rockchip,rk3399-power-controller" - for RK3399 SoCs.
 - #power-domain-cells: Number of cells in a power-domain specifier.
 	Should be 1 for multiple PM domains.
 - #address-cells: Should be 1.
@@ -16,6 +17,7 @@ Required properties for power domain sub nodes:
 - reg: index of the power domain, should use macros in:
 	"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain.
 	"include/dt-bindings/power/rk3368-power.h" - for RK3368 type power domain.
+	"include/dt-bindings/power/rk3399-power.h" - for RK3399 type power domain.
 - clocks (optional): phandles to clocks which need to be enabled while power domain
 	switches state.
 
@@ -45,12 +47,25 @@ Example:
                 };
         };
 
+	power: power-controller {
+		compatible = "rockchip,rk3399-power-controller";
+		#power-domain-cells = <1>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		pd_gpu {
+			reg = <RK3399_PD_GPU>;
+			clocks = <&cru ACLK_GPU>;
+		};
+	};
+
 Node of a device using power domains must have a power-domains property,
 containing a phandle to the power device node and an index specifying which
 power domain to use.
 The index should use macros in:
 	"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain.
 	"include/dt-bindings/power/rk3368-power.h" - for rk3368 type power domain.
+	"include/dt-bindings/power/rk3399-power.h" - for rk3399 type power domain.
 
 Example of the node using power domain:
 
@@ -65,3 +80,9 @@ Example of the node using power domain:
                 power-domains = <&power RK3368_PD_GPU_1>;
                 /* ... */
         };
+
+	node {
+		/* ... */
+		power-domains = <&power RK3399_PD_GPU>;
+		/* ... */
+	};
-- 
1.9.1




From marc.zyngier at arm.com  Mon Feb 15 00:45:56 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Feb 2016 08:45:56 +0000
Subject: ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8]
 arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)
In-Reply-To: <CAMuHMdU-q++XEgthKG=XOgnaq7TY899EsgMFHuWu4Skr5woLZg@mail.gmail.com>
References: <CAMuHMdU-q++XEgthKG=XOgnaq7TY899EsgMFHuWu4Skr5woLZg@mail.gmail.com>
Message-ID: <56C19044.6050604@arm.com>

On 15/02/16 08:16, Geert Uytterhoeven wrote:
> Cc Marz Zyngier
> Cc Dirk Behme
> Cc devicetree
> Cc linux-renesas-soc
> Drop linux-sh
> 
> On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland <mark.rutland at arm.com> wrote:
>>> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
>>>> On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland <mark.rutland at arm.com> wrote:
>>>>>>> +           gic: interrupt-controller at 0xf1010000 {
>>>>>> +                     compatible = "arm,gic-400";
>>>>>> +                     #interrupt-cells = <3>;
>>>>>> +                     #address-cells = <0>;
>>>>>> +                     interrupt-controller;
>>>>>> +                     reg = <0x0 0xf1010000 0 0x1000>,
>>>>>> +                           <0x0 0xf1020000 0 0x2000>;
>>>>>> +                     interrupts = <GIC_PPI 9
>>>>>> +                                     (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
>>>>>> +             };
>>>>>
>>>>> No GICH and GICV?
>>>>
>>>> These seem to be defined in the "arm,gic-v3" DT bindings only, while this is
>>>> an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>>>
>>> See the "GIC virtualization extensions (VGIC)" section in
>>> Documentation/devicetree/bindings/arm/gic.txt
>>
>> DDI0471B_gic400_r0p1_trm.pdf says:
>>
>>     Address range GIC-400 functional block
>>     A. 0x0000 - 0x0FFF Reserved
>>     B. 0x1000 - 0x1FFF Distributor
>>     C. 0x2000 - 0x3FFF CPU interfaces
>>     D. 0x4000 - 0x4FFF Virtual interface control block, for the processor that
>>                        is performing the access
>>     E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
>>                        selected by address bits [11:9]
>>     F. 0x6000 - 0x7FFF Virtual CPU interfaces
>>
>> The DT binding document says:
>>   1. The  first region is the GIC distributor register base and size.
>>   2. The 2nd region is the GIC cpu interface register base and size.
>>   3. The first additional region is the GIC virtual interface control register
>>      base and size.
>>   4. The 2nd additional region is the GIC virtual cpu interface register base
>>      and size.
>>
>> Matching with the example:
>>
>>         interrupt-controller at 2c001000 {
>>                 compatible = "arm,cortex-a15-gic";
>>                 #interrupt-cells = <3>;
>>                 interrupt-controller;
>>                 reg = <0x2c001000 0x1000>,
>>                       <0x2c002000 0x1000>,
>>                       <0x2c004000 0x2000>,
>>                       <0x2c006000 0x2000>;
>>                 interrupts = <1 9 0xf04>;
>>         };
>>
>> This means:
>>   - reg entry 1. covers address range B,
>>   - reg entry 2. covers address range C,
>>   - reg entry 3. covers address ranges D _and_ E,
>>   - reg entry 4. covers address range F.
>>
>> On R-Car Gen3, the base addresses are:
>>
>>     Distributor             : 0xF101_0000
>>     CPU interfaces          : 0xF102_0000
>>     Virtual interfaces      : 0xF104_0000
>>     Virtual interfaces      : 0xF105_0000
>>     Virtual CPU interfaces  : 0xF106_0000
>>
>> Note the additional multiplication factor of 16 in the offsets relative to
>> the base address 0xf1000000 (e.g. 0x50000 instead of 0x5000).
>>
>> As address ranges D and E are merged in a single reg entry, how is the GIC
>> driver supposed to know about this multiplication factor?

The answer is very simple, the GIC driver doesn't give a damn about the
second part of the GICH region, because it is absolutely unusable for
any realistic use-case. Only the banked version of GICH is of any
relevance (the first 512 bytes, in essence).

Aligning the GIC regions on 64kB boundaries is documented in the SBSA
specification, independently of the GIC400 documentation.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From thomas.petazzoni at free-electrons.com  Mon Feb 15 00:47:44 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Feb 2016 09:47:44 +0100
Subject: [PATCH 4/5] arm64: update ARCH_MVEBU for Marvell Armada 7K/8K support
In-Reply-To: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455526065-7307-5-git-send-email-thomas.petazzoni@free-electrons.com>

This commit updates the ARCH_MVEBU Kconfig option introduced for
Armada 3700 to also be used for the Armada 7K and 8K platforms, by:

 - Selecting the appropriate clock and irqchip drivers
 - Updating the help text to mention Armada 7K and 8K

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm64/Kconfig.platforms | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index d6fee5c..cadb7ff 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -2,9 +2,14 @@ menu "Platform selection"
 
 config ARCH_MVEBU
 	bool "Marvell EBU SoC Family"
-	help
-	  This enables support for Marvell EBU familly such as the
-	  Armada 3700 SoC Family.
+	select ARMADA_AP806_CORE_CLK
+	select ARMADA_AP806_RING_CLK
+	select MVEBU_ODMI
+	help
+	  This enables support for Marvell EBU familly, including:
+	   - Armada 3700 SoC Family
+	   - Armada 7K SoC Family
+	   - Armada 8K SoC Family
 
 config ARCH_BCM_IPROC
 	bool "Broadcom iProc SoC Family"
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Mon Feb 15 00:47:43 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Feb 2016 09:47:43 +0100
Subject: [PATCH 3/5] Documentation: arm: improve Marvell EBU Armada
 documentation
In-Reply-To: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455526065-7307-4-git-send-email-thomas.petazzoni@free-electrons.com>

This commit improves the Marvell EBU Armada documentation by:

 - Clarifying which core is used by each SoC. Indeed, the Armada 370
   and XP use a Marvell ARMv7 compatible core, while Armada 375, 38x
   and 39x use the ARM Cortex-A9 core.

 - Adding a link to the web form that allows to get the Armada 38x
   Functional Specifications.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 Documentation/arm/Marvell/README | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index 74f7ce3..57f8293 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -86,20 +86,25 @@ EBU Armada family
     Product Brief:   http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
     Hardware Spec:   http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
     Functional Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
+    Core:            Marvell PJ4B, ARMv7 compatible
 
   Armada 375 Flavors:
 	88F6720
     Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf
+    Core:          ARM Cortex-A9
 
   Armada 380/385 Flavors:
 	88F6810
 	88F6820
 	88F6828
+    Functional spec: https://marvellcorp.wufoo.com/forms/marvell-armada-38x-functional-specifications/
+    Core:          ARM Cortex-A9
 
   Armada 390/398 Flavors:
 	88F6920
 	88F6928
     Product infos: http://www.marvell.com/embedded-processors/armada-39x/
+    Core:          ARM Cortex-A9
 
   Armada XP Flavors:
         MV78230
@@ -112,8 +117,7 @@ EBU Armada family
       http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF
       http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
       http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
-
-  Core: Sheeva ARMv7 compatible
+    Core: Marvell PJ4B-MP, ARMv7 compatible
 
   Linux kernel mach directory: arch/arm/mach-mvebu
   Linux kernel plat directory: none
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Mon Feb 15 00:47:42 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Feb 2016 09:47:42 +0100
Subject: [PATCH 2/5] Documentation: arm: add Marvell Armada 7K and 8K families
In-Reply-To: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455526065-7307-3-git-send-email-thomas.petazzoni@free-electrons.com>

As we are adding support for the Armada 7K and 8K families, this
commit adds them to the Marvell documentation listing all supported
SoCs, together with references to their Product Brief, Homepage and
Device Tree files.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 Documentation/arm/Marvell/README | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index b92ee66..74f7ce3 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -130,6 +130,26 @@ EBU Armada family ARMv8
 	Product Brief: http://www.marvell.com/embedded-processors/assets/PB-88F3700-FNL.pdf
 	Device tree files: arch/arm64/boot/dts/marvell/armada-37*
 
+  Armada 7K Flavors:
+	88F7020 (AP806 Dual + one CP110)
+	88F7040 (AP806 Quad + one CP110)
+	Core: ARM Cortex A72
+
+	Homepage: http://www.marvell.com/embedded-processors/armada-70xx/
+	Product Brief: http://www.marvell.com/embedded-processors/assets/Armada7020PB-Jan2016.pdf
+		       http://www.marvell.com/embedded-processors/assets/Armada7040PB-Jan2016.pdf
+	Device tree files: arch/arm64/boot/dts/marvell/armada-70*
+
+  Armada 8K Flavors:
+	88F8020 (AP806 Dual + two CP110)
+	88F8040 (AP806 Quad + two CP110)
+	Core: ARM Cortex A72
+
+	Homepage: http://www.marvell.com/embedded-processors/armada-80xx/
+	Product Brief: http://www.marvell.com/embedded-processors/assets/Armada8020PB-Jan2016.pdf
+		       http://www.marvell.com/embedded-processors/assets/Armada8040PB-Jan2016.pdf
+	Device tree files: arch/arm64/boot/dts/marvell/armada-80*
+
 Avanta family
 -------------
 
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Mon Feb 15 00:47:40 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Feb 2016 09:47:40 +0100
Subject: [PATCH 0/5] arm64: Initial support for Marvell Armada 7K/8K
Message-ID: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hello,

This series adds initial support for the new Armada 7K and 8K Marvell
64 bits processors. Details about those processors based on the
Cortex-A72 can be found at:

  http://www.marvell.com/embedded-processors/armada-70xx/
  http://www.marvell.com/embedded-processors/armada-80xx/

One characteristic of those processors is that internally they are
built from several components:

 - One "AP", which contains the processor itself and a few core IP
   blocks. The AP in 7K and 8K is called AP806, and is available on
   two variants: dual Cortex-A72 and quad Cortex-A72.

 - Or or two "CP", which contains most of the I/Os (SATA, PCIe,
   etc.). The CP in 7K and 8K is called CP110. One CP110 is available
   in the 7K family, while two CP110 are available in the 8K family,
   doubling the number of I/O interfaces.

The support added in this series only brings minimal support for the
AP side (and not yet all IP blocks, obviously). Support for the CP
part will come in the future.

Since the series touches similar files as the Armada 3700 series from
Gregory Clement, it is based on it.

Best regards,

Thomas

Thomas Petazzoni (5):
  Documentation: arm: improve Armada 37xx description
  Documentation: arm: add Marvell Armada 7K and 8K families
  Documentation: arm: improve Marvell EBU Armada documentation
  arm64: update ARCH_MVEBU for Marvell Armada 7K/8K support
  arm64: marvell: add Device Tree files for Armada 7K/8K

 Documentation/arm/Marvell/README                   |  39 +++-
 .../bindings/arm/marvell/armada-7k-8k.txt          |  24 +++
 arch/arm64/Kconfig.platforms                       |  11 +-
 arch/arm64/boot/dts/marvell/Makefile               |   1 +
 arch/arm64/boot/dts/marvell/armada-7020.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-7040-db.dts     |  92 ++++++++
 arch/arm64/boot/dts/marvell/armada-7040.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-8020.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-8040.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi |  71 +++++++
 arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi |  84 ++++++++
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi      | 235 +++++++++++++++++++++
 12 files changed, 762 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
 create mode 100644 arch/arm64/boot/dts/marvell/armada-7020.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-7040-db.dts
 create mode 100644 arch/arm64/boot/dts/marvell/armada-7040.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-8020.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-8040.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806.dtsi

-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Mon Feb 15 00:47:41 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Feb 2016 09:47:41 +0100
Subject: [PATCH 1/5] Documentation: arm: improve Armada 37xx description
In-Reply-To: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455526065-7307-2-git-send-email-thomas.petazzoni@free-electrons.com>

In preparation to the introduction of other SoCs in the ARMv8 Armada
EBU family, this commit tweaks the existing description of Armada 37xx
by making the core, homepage and other informations be visible "under"
the Armada 37xx item. Indeed, the new SoCs will not share the same
core or homepage.

In addition, a link to the Product Brief is added.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 Documentation/arm/Marvell/README | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index ddbc048..b92ee66 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -124,12 +124,11 @@ EBU Armada family ARMv8
   Armada 3710/3720 Flavors:
 	88F3710
 	88F3720
+	Core: ARM Cortex A53 (ARMv8)
 
-  Core: ARM Cortex A53 (ARMv8)
-
-  Homepage     : http://www.marvell.com/embedded-processors/armada-3700/
-
-  Device tree descritpion located in arch/arm64/boot/dts/marvell/armada-37*
+	Homepage: http://www.marvell.com/embedded-processors/armada-3700/
+	Product Brief: http://www.marvell.com/embedded-processors/assets/PB-88F3700-FNL.pdf
+	Device tree files: arch/arm64/boot/dts/marvell/armada-37*
 
 Avanta family
 -------------
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Mon Feb 15 00:47:45 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Feb 2016 09:47:45 +0100
Subject: [PATCH 5/5] arm64: marvell: add Device Tree files for Armada 7K/8K
In-Reply-To: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455526065-7307-6-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adds the base Device Tree files for the Armada 7K and 8K
SoCs, as well as the Armada 8040 DB board.

The Armada 7020, 7040 (7K family) and 8020, 8040 (8K family) are
composed of:

 - An AP806 block that contains the CPU core and a few basic
   peripherals. The AP806 is available in dual core configurations
   (used in 7020 and 8020) and quad core configurations (used in 8020
   and 8040).

 - One or two CP110 blocks that contain all the high-speed interfaces
   (SATA, PCIe, Ethernet, etc.). The 7K family chips have one CP110,
   and the 8K family chips have two CP110, giving them twice the
   number of HW interfaces.

In order to represent this from a Device Tree point of view, this
commit creates the following hierarchy:

 * armada-ap806.dtsi - definitions common to dual/quad ap806
   * armada-ap806-dual.dtsi - description of the two CPUs
     * armada-7020.dtsi - description of the 7020 SoC
     * armada-8020.dtsi - description of the 8020 SoC
   * armada-ap806-quad.dtsi - description of the four CPUs
     * armada-7040.dtsi - description of the 7040 SoC
       * armada-7040-db.dts - description of the 7040 board
     * armada-8040.dtsi - description of the 8040 SoC

The CP110 blocks are not described yet, and will be part of future
patch series.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../bindings/arm/marvell/armada-7k-8k.txt          |  24 +++
 arch/arm64/boot/dts/marvell/Makefile               |   1 +
 arch/arm64/boot/dts/marvell/armada-7020.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-7040-db.dts     |  92 ++++++++
 arch/arm64/boot/dts/marvell/armada-7040.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-8020.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-8040.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi |  71 +++++++
 arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi |  84 ++++++++
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi      | 235 +++++++++++++++++++++
 10 files changed, 723 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
 create mode 100644 arch/arm64/boot/dts/marvell/armada-7020.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-7040-db.dts
 create mode 100644 arch/arm64/boot/dts/marvell/armada-7040.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-8020.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-8040.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806.dtsi

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
new file mode 100644
index 0000000..df98a9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
@@ -0,0 +1,24 @@
+Marvell Armada 7K/8K Platforms Device Tree Bindings
+---------------------------------------------------
+
+Boards using a SoC of the Marvell Armada 7K or 8K families must carry
+the following root node property:
+
+ - compatible, with one of the following values:
+
+   - "marvell,armada7020", "marvell,armada-ap806-dual", "marvell,armada-ap806"
+      when the SoC being used is the Armada 7020
+
+   - "marvell,armada7040", "marvell,armada-ap806-quad", "marvell,armada-ap806"
+      when the SoC being used is the Armada 7040
+
+   - "marvell,armada8020", "marvell,armada-ap806-dual", "marvell,armada-ap806"
+      when the SoC being used is the Armada 8020
+
+   - "marvell,armada8040", "marvell,armada-ap806-quad", "marvell,armada-ap806"
+      when the SoC being used is the Armada 8040
+
+Example:
+
+compatible = "marvell,armada7040-db", "marvell,armada7040",
+             "marvell,armada-ap806-quad", "marvell,armada-ap806";
diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index 2114af8..308468d 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
 
 # Mvebu SoC Family
 dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-7040-db.dtb
 
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
diff --git a/arch/arm64/boot/dts/marvell/armada-7020.dtsi b/arch/arm64/boot/dts/marvell/armada-7020.dtsi
new file mode 100644
index 0000000..5257575
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-7020.dtsi
@@ -0,0 +1,54 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for the Armada 7020 SoC, made of an AP806 Dual and
+ * one CP110.
+ */
+
+#include "armada-ap806-dual.dtsi"
+
+/ {
+	model = "Marvell Armada 7020";
+	compatible = "marvell,armada7020", "marvell,armada-ap806-dual",
+		     "marvell,armada-ap806";
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
new file mode 100644
index 0000000..064a251
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for Marvell Armada 7040 Development board platform
+ */
+
+#include "armada-7040.dtsi"
+
+/ {
+	model = "Marvell Armada 7040 DB board";
+	compatible = "marvell,armada7040-db", "marvell,armada7040",
+		     "marvell,armada-ap806-quad", "marvell,armada-ap806";
+
+	memory at 00000000 {
+		device_type = "memory";
+		reg = <0x0 0x0 0x0 0x80000000>;
+	};
+
+	ap806 {
+		config-space {
+			spi at 510600 {
+				status = "okay";
+
+				spi-flash at 0 {
+					#address-cells = <1>;
+					#size-cells = <1>;
+					compatible = "n25q128a13";
+					reg = <0>; /* Chip select 0 */
+					spi-max-frequency = <10000000>;
+
+					partition at 0 {
+						label = "U-Boot";
+						reg = <0 0x200000>;
+					};
+					partition at 400000 {
+						label = "Filesystem";
+						reg = <0x200000 0xce0000>;
+					};
+				};
+			};
+
+			i2c at 511000 {
+				status = "okay";
+				clock-frequency = <100000>;
+			};
+
+			serial at 512000 {
+				status = "okay";
+			};
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-7040.dtsi b/arch/arm64/boot/dts/marvell/armada-7040.dtsi
new file mode 100644
index 0000000..7a2de8b
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-7040.dtsi
@@ -0,0 +1,54 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for the Armada 7040 SoC, made of an AP806 Quad and
+ * one CP110.
+ */
+
+#include "armada-ap806-quad.dtsi"
+
+/ {
+	model = "Marvell Armada 7040";
+	compatible = "marvell,armada7040", "marvell,armada-ap806-quad",
+		     "marvell,armada-ap806";
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-8020.dtsi b/arch/arm64/boot/dts/marvell/armada-8020.dtsi
new file mode 100644
index 0000000..73d69d9
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-8020.dtsi
@@ -0,0 +1,54 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for the Armada 8020 SoC, made of an AP806 Dual and
+ * two CP110.
+ */
+
+#include "armada-ap806-dual.dtsi"
+
+/ {
+	model = "Marvell Armada 8020";
+	compatible = "marvell,armada8020", "marvell,armada-ap806-dual",
+		     "marvell,armada-ap806";
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-8040.dtsi b/arch/arm64/boot/dts/marvell/armada-8040.dtsi
new file mode 100644
index 0000000..a1406a4
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-8040.dtsi
@@ -0,0 +1,54 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for the Armada 8040 SoC, made of an AP806 Quad and
+ * two CP110.
+ */
+
+#include "armada-ap806-quad.dtsi"
+
+/ {
+	model = "Marvell Armada 8040";
+	compatible = "marvell,armada8040", "marvell,armada-ap806-quad",
+		     "marvell,armada-ap806";
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi
new file mode 100644
index 0000000..f25c5c1
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi
@@ -0,0 +1,71 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for Marvell Armada AP806.
+ */
+
+#include "armada-ap806.dtsi"
+
+/ {
+	model = "Marvell Armada AP806 Dual";
+	compatible = "marvell,armada-ap806-dual", "marvell,armada-ap806";
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 000 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x000>;
+			enable-method = "psci";
+		};
+		cpu at 001 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x001>;
+			enable-method = "psci";
+		};
+	};
+};
+
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
new file mode 100644
index 0000000..baa7d9a
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
@@ -0,0 +1,84 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for Marvell Armada AP806.
+ */
+
+#include "armada-ap806.dtsi"
+
+/ {
+	model = "Marvell Armada AP806 Quad";
+	compatible = "marvell,armada-ap806-quad", "marvell,armada-ap806";
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 000 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x000>;
+			enable-method = "psci";
+		};
+		cpu at 001 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x001>;
+			enable-method = "psci";
+		};
+		cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x100>;
+			enable-method = "psci";
+		};
+		cpu at 101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x101>;
+			enable-method = "psci";
+		};
+	};
+
+};
+
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
new file mode 100644
index 0000000..3303db2
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
@@ -0,0 +1,235 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for Marvell Armada AP806.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/dts-v1/;
+
+/ {
+	model = "Marvell Armada AP806";
+	compatible = "marvell,armada-ap806";
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+
+	ap806 {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		compatible = "simple-bus";
+		interrupt-parent = <&gic>;
+		ranges;
+
+		config-space {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "simple-bus";
+			ranges = <0x0 0x0 0xf0000000 0x1000000>;
+
+			gic: interrupt-controller at 210000 {
+				compatible = "arm,cortex-a15-gic",
+					     "arm,cortex-a9-gic";
+				#interrupt-cells = <3>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges;
+				interrupt-controller;
+				interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+				reg = <0x210000 0x1000>,
+				      <0x220000 0x1000>,
+				      <0x240000 0x2000>,
+				      <0x260000 0x2000>;
+
+				gic_v2m0: v2m at 280000 {
+					compatible = "arm,gic-v2m-frame";
+					msi-controller;
+					reg = <0x280000 0x1000>;
+					arm,msi-base-spi = <160>;
+					arm,msi-num-spis = <32>;
+				};
+				gic_v2m1: v2m at 290000 {
+					compatible = "arm,gic-v2m-frame";
+					msi-controller;
+					reg = <0x290000 0x1000>;
+					arm,msi-base-spi = <192>;
+					arm,msi-num-spis = <32>;
+				};
+				gic_v2m2: v2m at 2a0000 {
+					compatible = "arm,gic-v2m-frame";
+					msi-controller;
+					reg = <0x2a0000 0x1000>;
+					arm,msi-base-spi = <224>;
+					arm,msi-num-spis = <32>;
+				};
+				gic_v2m3: v2m at 2b0000 {
+					compatible = "arm,gic-v2m-frame";
+					msi-controller;
+					reg = <0x2b0000 0x1000>;
+					arm,msi-base-spi = <256>;
+					arm,msi-num-spis = <32>;
+				};
+			};
+
+			timer {
+				compatible = "arm,armv8-timer";
+				interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_EDGE_RISING)>,
+					     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_EDGE_RISING)>,
+					     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_EDGE_RISING)>,
+					     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_EDGE_RISING)>;
+			};
+
+			odmi: odmi at 300000 {
+				compatible = "marvell,odmi-controller";
+				interrupt-controller;
+				msi-controller;
+				marvell,odmi-frames = <4>;
+				reg = <0x300000 0x4000>,
+				      <0x304000 0x4000>,
+				      <0x308000 0x4000>,
+				      <0x30C000 0x4000>;
+				marvell,spi-base = <128>, <136>, <144>, <152>;
+			};
+
+			spi0: spi at 510600 {
+				compatible = "marvell,armada-380-spi";
+				reg = <0x510600 0x50>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				cell-index = <0>;
+				interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&ringclk 2>;
+				status = "disabled";
+			};
+
+			i2c0: i2c at 511000 {
+				compatible = "marvell,mv64xxx-i2c";
+				reg = <0x511000 0x20>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+				timeout-ms = <1000>;
+				clocks = <&ringclk 2>;
+				status = "disabled";
+			};
+
+			serial at 512000 {
+				compatible = "snps,dw-apb-uart";
+				reg = <0x512000 0x100>;
+				reg-shift = <2>;
+				interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+				reg-io-width = <1>;
+				clocks = <&ringclk 2>;
+				status = "disabled";
+			};
+
+			serial at 512100 {
+				compatible = "snps,dw-apb-uart";
+				reg = <0x512100 0x100>;
+				reg-shift = <2>;
+				interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+				reg-io-width = <1>;
+				clocks = <&ringclk 2>;
+				status = "disabled";
+
+			};
+
+			coreclk: clk at 0x6F8204 {
+				compatible = "marvell,armada-ap806-core-clock";
+				reg = <0x6F8204 0x04>;
+				#clock-cells = <1>;
+				clock-output-names = "ddr", "ring", "cpu";
+			};
+
+			ringclk: clk at 0x6F8250 {
+				compatible = "marvell,armada-ap806-ring-clock";
+				reg = <0x6F8250 0x04>;
+				#clock-cells = <1>;
+				clock-output-names = "ring-0", "ring-2",
+						     "ring-3", "ring-4",
+						     "ring-5";
+				clocks = <&coreclk 1>;
+			};
+
+			xor0 at 400000 {
+				compatible = "marvell,mv-xor-v2";
+				reg = <0x400000 0x1000>,
+				      <0x410000 0x1000>;
+				msi-parent = <&gic_v2m0>;
+				dma-coherent;
+			};
+
+			xor1 at 420000 {
+				compatible = "marvell,mv-xor-v2";
+				reg = <0x420000 0x1000>,
+				      <0x430000 0x1000>;
+				msi-parent = <&gic_v2m0>;
+				dma-coherent;
+			};
+
+			xor2 at 440000 {
+				compatible = "marvell,mv-xor-v2";
+				reg = <0x440000 0x1000>,
+				      <0x450000 0x1000>;
+				msi-parent = <&gic_v2m0>;
+				dma-coherent;
+			};
+
+			xor3 at 460000 {
+				compatible = "marvell,mv-xor-v2";
+				reg = <0x460000 0x1000>,
+				      <0x470000 0x1000>;
+				msi-parent = <&gic_v2m0>;
+				dma-coherent;
+			};
+		};
+	};
+
+};
+
-- 
2.6.4



From ard.biesheuvel at linaro.org  Mon Feb 15 00:51:49 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 15 Feb 2016 09:51:49 +0100
Subject: [PATCH v2] arm64: use local label prefixes for __reg_num symbols
Message-ID: <1455526309-18519-1-git-send-email-ard.biesheuvel@linaro.org>

The __reg_num_xNN symbols that are used to implement the msr_s and
mrs_s macros are recorded in the ELF metadata of each object file.
This does not affect the size of the final binary, but it does clutter
the output of tools like readelf, i.e.,

  $ readelf -a vmlinux |grep -c __reg_num_x
  50976

So let's use symbols with the .L prefix, these are strictly local,
and don't end up in the object files.

  $ readelf -a vmlinux |grep -c __reg_num_x
  0

Acked-by: Will Deacon <will.deacon at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
v2: updated commit log, added ack

 arch/arm64/include/asm/sysreg.h | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 4aeebec3d882..7d771ac01289 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -196,16 +196,16 @@
 #ifdef __ASSEMBLY__
 
 	.irp	num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30
-	.equ	__reg_num_x\num, \num
+	.equ	.L__reg_num_x\num, \num
 	.endr
-	.equ	__reg_num_xzr, 31
+	.equ	.L__reg_num_xzr, 31
 
 	.macro	mrs_s, rt, sreg
-	.inst	0xd5200000|(\sreg)|(__reg_num_\rt)
+	.inst	0xd5200000|(\sreg)|(.L__reg_num_\rt)
 	.endm
 
 	.macro	msr_s, sreg, rt
-	.inst	0xd5000000|(\sreg)|(__reg_num_\rt)
+	.inst	0xd5000000|(\sreg)|(.L__reg_num_\rt)
 	.endm
 
 #else
@@ -214,16 +214,16 @@
 
 asm(
 "	.irp	num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30\n"
-"	.equ	__reg_num_x\\num, \\num\n"
+"	.equ	.L__reg_num_x\\num, \\num\n"
 "	.endr\n"
-"	.equ	__reg_num_xzr, 31\n"
+"	.equ	.L__reg_num_xzr, 31\n"
 "\n"
 "	.macro	mrs_s, rt, sreg\n"
-"	.inst	0xd5200000|(\\sreg)|(__reg_num_\\rt)\n"
+"	.inst	0xd5200000|(\\sreg)|(.L__reg_num_\\rt)\n"
 "	.endm\n"
 "\n"
 "	.macro	msr_s, sreg, rt\n"
-"	.inst	0xd5000000|(\\sreg)|(__reg_num_\\rt)\n"
+"	.inst	0xd5000000|(\\sreg)|(.L__reg_num_\\rt)\n"
 "	.endm\n"
 );
 
-- 
2.5.0



From jassisinghbrar at gmail.com  Mon Feb 15 00:58:23 2016
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Mon, 15 Feb 2016 14:28:23 +0530
Subject: [PATCH v7 0/4] mailbox: hisilicon: add Hi6220 mailbox driver
In-Reply-To: <1454599500-15600-1-git-send-email-leo.yan@linaro.org>
References: <1454599500-15600-1-git-send-email-leo.yan@linaro.org>
Message-ID: <CABb+yY2_4p6wu0qo0p8S3enD-EO=B4LXmC0569Z7tSj0zdjQHQ@mail.gmail.com>

On Thu, Feb 4, 2016 at 8:54 PM, Leo Yan <leo.yan at linaro.org> wrote:
> Hi6220 mailbox supports up to 32 channels. Each channel is unidirectional
> with a maximum message size of 8 words. I/O is performed using register
> access (there is no DMA) and the cell raises an interrupt when messages
> are received.
>
> This patch series is to implement Hi6220 mailbox driver. It registers
> two channels into framework for communication with MCU, one is tx channel
> and another is rx channel. Now mailbox driver is used to send message to
> MCU to control dynamic voltage and frequency scaling for CPU, GPU and DDR.
>
> Changes from v6:
> * Fix to use lowercase for hexadecimal value in DT binding document
>
Looks ok, but please rebase over mailbox-for-next and resend.

Thanks.


From linux at arm.linux.org.uk  Mon Feb 15 00:58:18 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Feb 2016 08:58:18 +0000
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160215081750.GD12289@pengutronix.de>
References: <20160214165010.GA3189@roeck-us.net>
 <20160214195501.GA12289@pengutronix.de>
 <20160214200755.GB10826@n2100.arm.linux.org.uk>
 <20160215081750.GD12289@pengutronix.de>
Message-ID: <20160215085818.GC10826@n2100.arm.linux.org.uk>

On Mon, Feb 15, 2016 at 09:17:50AM +0100, Uwe Kleine-K?nig wrote:
> Hello Russell,
> 
> On Sun, Feb 14, 2016 at 08:07:55PM +0000, Russell King - ARM Linux wrote:
> > On Sun, Feb 14, 2016 at 08:55:01PM +0100, Uwe Kleine-K?nig wrote:
> > > So the unexpected abnormality here is that even though this device is
> > > instantiated by dt, the driver doesn't provide any compatibles.
> > > Either my expectation is wrong, then 67d02a1bbb33455 should be reverted
> > 
> > Your expectation is wrong.  AMBA primecell devices have hardware IDs
> > and are matched to their drivers by those IDs.  Just like PCI.
> 
> pci devices don't appear in dt, do they? I don't see the connection
> between amba devices and platform devices, see my other mail in this
> thread for some more details.

They both have hardware IDs, and they are both matched via those hardware
IDs.

Your change has introduced a regression and is therefore wrong.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From eun.taik.lee at samsung.com  Mon Feb 15 00:58:32 2016
From: eun.taik.lee at samsung.com (EunTaik Lee)
Date: Mon, 15 Feb 2016 08:58:32 +0000 (GMT)
Subject: [PATCH RESEND] arm64: add alignment fault hanling
Message-ID: <2039801453.916991455526707908.JavaMail.weblogic@epmlwas09b>

Userspace memory is mapped as below:
F2A7F000--F2A7FFFF Normal Memory
F2A80000--F2A80FFF Device nGnRnE

And that userspace application makes a system call
as below:

-009 |do_strncpy_from_user(inline)
-009 |strncpy_from_user()
-010 |getname_flags()
-011 |user_path_at_empty()
-012 |user_path_at()
-013 |SYSC_faccessat(inline)
-013 |sys_faccessat()
-014 |__sys_trace(asm)
--> |exception

The string spans from 0xF2A7FFC1 to 0xF2A7FFFB.

When do_strncpy_from_user() reads the last (unsigned long)
value, the alignement fault is triggered. The 8 byte
from 0xF2A7FFC1 spans to the next page that is mapped as
Device nGnRnE, which does not allow an unaligned access,
causes the abort.

The instruction which caused the alignment fault is registered
in the fixup table but the exception handler does not reach there.

This patch registers a alignment fault handler and fixes up the
pc if appropriate.

Signed-off-by: Eun Taik Lee 
---
arch/arm64/mm/fault.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 19211c4..8257d4f 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -371,6 +371,16 @@ static int __kprobes do_translation_fault(unsigned long addr,
return 0;
}

+static int __kprobes do_alignment_fault(unsigned long addr,
+   unsigned int esr,
+   struct pt_regs *regs)
+{
+ if (addr >= TASK_SIZE && fixup_exception(regs))
+ return 0;
+
+ return 1;
+}
+
/*
  * This abort handler always returns "fault".
  */
@@ -418,7 +428,7 @@ static struct fault_info {
{ do_bad, SIGBUS,  0, "synchronous parity error (translation table walk" },
{ do_bad, SIGBUS,  0, "synchronous parity error (translation table walk" },
{ do_bad, SIGBUS,  0, "unknown 32" },
- { do_bad, SIGBUS,  BUS_ADRALN, "alignment fault" },
+ { do_alignment_fault, SIGBUS,  BUS_ADRALN, "alignment fault" },
{ do_bad, SIGBUS,  0, "debug event" },
{ do_bad, SIGBUS,  0, "unknown 35" },
{ do_bad, SIGBUS,  0, "unknown 36" },
-- 
1.9.1

From linus.walleij at linaro.org  Mon Feb 15 01:07:38 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 15 Feb 2016 10:07:38 +0100
Subject: [GIT PULL] Versatile family DT cleanups step 1
Message-ID: <CACRpkdYR-_41Ay7b_X4hJkPY7dUR2qAsfsjn-MzpahVWqEiVPQ@mail.gmail.com>

Hi ARM SoC folks,

this is a first pull request for my cleanups for the Versatile, as the
finished stuff should not be sitting in my tree but in ARM SoC.
This completes the ARM RealView PB1176 and PB11MPCore
device trees, and moves the Versatile to use power/reset.

The idea is to keep working on this cleanup branch and send
additional patches on top of this one as the prerequisites are
merged into the MTD and FBDEV subsystems. So please create
a special versatile cleanup branch (or suggest another approach).

As it happens, board files and device trees need to change at the
same time to make logical sense, especially for Versatile where
auxdata is replaced with DT entries, such as when reset is moved
in the last patch in this set. The MTD and CLCD changes will share
this characteristic.

Please pull it in!

Yours,
Linus Walleij

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git
tags/versatile-dt-cleanup-1

for you to fetch changes up to 1c6e288da6cc3c72579ff0062b5a5684fb9ef90e:

  ARM: versatile: move restart to the device tree (2016-02-15 09:58:08 +0100)

----------------------------------------------------------------
Versatile family cleanups step 1:
- Finalize RealView the PB1176 and PB11MPCore device trees
- Move Versatile to use the power/reset driver instead of a
  custom restart hook

----------------------------------------------------------------
Linus Walleij (8):
      ARM: realview: add flash devices to the PB1176 DTS
      ARM: realview: fix up PB11MP flash compat strings
      ARM: pb1176: add ICST307 clocks to the device tree
      ARM: pb1176: add AACI to the device tree
      ARM: pb1176: add ISP1761 USB OTG host controller
      ARM: pb1176: add ethernet to devicetree
      ARM: realview: add the DS1338 RTC to PB1176 DT
      ARM: versatile: move restart to the device tree

 arch/arm/boot/dts/arm-realview-pb1176.dts | 118 ++++++++++++++++++++++++++++++
 arch/arm/boot/dts/arm-realview-pb11mp.dts |   4 +-
 arch/arm/mach-versatile/Kconfig           |   3 +
 arch/arm/mach-versatile/versatile_dt.c    |  15 ----
 4 files changed, 123 insertions(+), 17 deletions(-)


From jamesjj.liao at mediatek.com  Mon Feb 15 01:09:19 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Mon, 15 Feb 2016 17:09:19 +0800
Subject: [PATCH v4 1/4] soc: mediatek: Refine scpsys to support multiple
 platform
In-Reply-To: <56B1C19F.9070300@gmail.com>
References: <1453270097-53853-1-git-send-email-jamesjj.liao@mediatek.com>
 <1453270097-53853-2-git-send-email-jamesjj.liao@mediatek.com>
 <56ADF556.6070402@gmail.com> <1454396212.2847.15.camel@mtksdaap41>
 <56B0889A.1010305@gmail.com> <1454476968.2847.59.camel@mtksdaap41>
 <56B1C19F.9070300@gmail.com>
Message-ID: <1455527359.29688.1.camel@mtksdaap41>

Hi Matthias,

On Wed, 2016-02-03 at 10:00 +0100, Matthias Brugger wrote:
> On 03/02/16 06:22, James Liao wrote:
> > On Tue, 2016-02-02 at 11:44 +0100, Matthias Brugger wrote:
> >> On 02/02/16 07:56, James Liao wrote:
> >>> On Sun, 2016-01-31 at 12:51 +0100, Matthias Brugger wrote:
> >>>>> On 20/01/16 07:08, James Liao wrote:
> >>>>>>> Refine scpsys driver common code to support multiple SoC / platform.
> >>>>>>>
> >>>>>>> Signed-off-by: James Liao<jamesjj.liao at mediatek.com>
> >>>>>>> ---
> >>>>>>>    drivers/soc/mediatek/mtk-scpsys.c | 418 ++++++++++++++++++++------------------
> >>>>>>>    drivers/soc/mediatek/mtk-scpsys.h |  55 +++++
> >>>>>>>    2 files changed, 270 insertions(+), 203 deletions(-)
> >>>>>>>    create mode 100644 drivers/soc/mediatek/mtk-scpsys.h
> >>>>>
> >>>>> In general this approach looks fine to me, comments below.
> >>>>>
> >>>>>>>
> >>>>>>> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> >>>>>>> index 0221387..339adfc 100644
> >>>>>>> --- a/drivers/soc/mediatek/mtk-scpsys.c
> >>>>>>> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> >>>>>>> @@ -11,29 +11,17 @@
> >>>>>>>     * GNU General Public License for more details.
> >>>>>>>     */
> >>>>>>>    #include <linux/clk.h>
> >>>>>>> -#include <linux/delay.h>
> >>>>>>> +#include <linux/init.h>
> >>>>>>>    #include <linux/io.h>
> >>>>>>> -#include <linux/kernel.h>
> >>>>>>>    #include <linux/mfd/syscon.h>
> >>>>>
> >>>>> When at it, do we need this include?
> >>> syscon_regmap_lookup_by_phandle() is declared in this head file.
> >>>
> >>>>>>> -#include <linux/init.h>
> >>>>>>>    #include <linux/of_device.h>
> >>>>>>>    #include <linux/platform_device.h>
> >>>>>>>    #include <linux/pm_domain.h>
> >>>>>>> -#include <linux/regmap.h>
> >>>>>>> -#include <linux/soc/mediatek/infracfg.h>
> >>>>>>>    #include <linux/regulator/consumer.h>
> >>>>>>> -#include <dt-bindings/power/mt8173-power.h>
> >>>>>>> +#include <linux/soc/mediatek/infracfg.h>
> >>>>>>> +
> >>>>>>> +#include "mtk-scpsys.h"
> >>>>>>>
> >>>>>>> -#define SPM_VDE_PWR_CON			0x0210
> >>>>>>> -#define SPM_MFG_PWR_CON			0x0214
> >>>>>>> -#define SPM_VEN_PWR_CON			0x0230
> >>>>>>> -#define SPM_ISP_PWR_CON			0x0238
> >>>>>>> -#define SPM_DIS_PWR_CON			0x023c
> >>>>>>> -#define SPM_VEN2_PWR_CON		0x0298
> >>>>>>> -#define SPM_AUDIO_PWR_CON		0x029c
> >>>>>>> -#define SPM_MFG_2D_PWR_CON		0x02c0
> >>>>>>> -#define SPM_MFG_ASYNC_PWR_CON		0x02c4
> >>>>>>> -#define SPM_USB_PWR_CON			0x02cc
> >>>>>
> >>>>> I would prefer to keep this defines and declare SoC specific ones where
> >>>>> necessary. It makes the code more readable.
> >>> Some register address may be reused by other modules among SoCs, so it's
> >>> not easy to maintain the defines when we implement multiple SoC drivers
> >>> in the same file. For example, offset 0x0298 is VEN2_PWR_CON on MT8173,
> >>> but it is MJC_PWR_CON on other chips.
> >>>
> >>
> >> So that sounds as if 0x0298 offset is MT8173 specific.
> >> I checked [VDE, MFG, VEN, IFR, ISP, DIS, DPY]_PWR_CON on mt8173, mt8135
> >> and mt6589 and they all have the same offset. So it doesn't seem as if
> >> the offset randomly changes for every SoC.
> >>
> >>> Furthermore, these register offsets are only used in scp_domain_data[],
> >>> and each element has its own power domain name. So I think it's enough
> >>> to know which power domain are using these registers and status bits.
> >>>
> >>
> >> Yes that's true, but it will make it easier for another person to
> >> understand the driver, especially if he want's to implement the driver
> >> for a new SoC.
> >
> > There are two kinds of conflicts may happen:
> >
> > 1. Different modules use the same register address.
> > 2. Different register addresses are used by the same module (on
> > different IC).
> >
> > Type 1. for example:
> >
> > 	#define SPM_BDP_PWR_CON			0x029c /* 2701 */
> > 	#define SPM_AUDIO_PWR_CON		0x029c /* 8173 */
> >
> > We can resolve this conflict easily, such as define these two register
> > name to the same register address.
> >
> > Type 2. for example:
> >
> > 	#define SPM_VDE_PWR_CON			0x0300 /* 6755 */
> > 	#define SPM_VDE_PWR_CON			0x0210 /* 8173 */
> >
> > We can not reuse the register defines in this case. We may need to name
> > the registers with its IC name, such as MT8173_SPM_VDE_PWR_CON and
> > MT6755_VDE_PWR_CON. But it will increase the maintain effort. That's why
> > I prefer to remove register defines if we implement multiple SoC's
> > scpsys in a single file.
> >
> >
> 
> Well type 2 for me is no problem at all. As stated in my last mail, 
> mt6755 would get the SoC name in the define (as a postfix preferably).
> I don't think that this will make a lot of pain regarding maintaining 
> it. Even less if we have the defines in alphabetic order.
> 
> I we see in the future that this converts to a mess, we always can get 
> rid of the defines quite easily.

OK, I'll add register names back in next patch.


Best regards,

James




From lkp at intel.com  Mon Feb 15 01:09:27 2016
From: lkp at intel.com (kbuild test robot)
Date: Mon, 15 Feb 2016 17:09:27 +0800
Subject: [PATCH] dma: mv_xor_v2: new driver
In-Reply-To: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <201602151735.BaFwBMOn%fengguang.wu@intel.com>

Hi Thomas,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.5-rc4 next-20160215]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Thomas-Petazzoni/dma-mv_xor_v2-new-driver/20160215-160120
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: openrisc-allyesconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   In file included from kernel/irq/chip.c:14:0:
>> include/linux/msi.h:174:21: fatal error: asm/msi.h: No such file or directory
   compilation terminated.

vim +174 include/linux/msi.h

c2791b80 Yijing Wang    2014-11-11  168  	void (*teardown_irq)(struct msi_controller *chip, unsigned int irq);
0cbdcfcf Thierry Reding 2013-08-09  169  };
0cbdcfcf Thierry Reding 2013-08-09  170  
f3cf8bb0 Jiang Liu      2014-11-12  171  #ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
d9109698 Jiang Liu      2014-11-15  172  
aeeb5965 Jiang Liu      2014-11-15  173  #include <linux/irqhandler.h>
d9109698 Jiang Liu      2014-11-15 @174  #include <asm/msi.h>
d9109698 Jiang Liu      2014-11-15  175  
f3cf8bb0 Jiang Liu      2014-11-12  176  struct irq_domain;
552c494a Marc Zyngier   2015-11-23  177  struct irq_domain_ops;

:::::: The code at line 174 was first introduced by commit
:::::: d9109698be6e7439e6082aa00d79d4556114739b genirq: Introduce msi_domain_alloc/free_irqs()

:::::: TO: Jiang Liu <jiang.liu at linux.intel.com>
:::::: CC: Thomas Gleixner <tglx at linutronix.de>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 36865 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160215/c5363463/attachment-0001.obj>

From u.kleine-koenig at pengutronix.de  Mon Feb 15 01:14:06 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Mon, 15 Feb 2016 10:14:06 +0100
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160215085818.GC10826@n2100.arm.linux.org.uk>
References: <20160214165010.GA3189@roeck-us.net>
 <20160214195501.GA12289@pengutronix.de>
 <20160214200755.GB10826@n2100.arm.linux.org.uk>
 <20160215081750.GD12289@pengutronix.de>
 <20160215085818.GC10826@n2100.arm.linux.org.uk>
Message-ID: <20160215091406.GE12289@pengutronix.de>

Hello Russell,

On Mon, Feb 15, 2016 at 08:58:18AM +0000, Russell King - ARM Linux wrote:
> On Mon, Feb 15, 2016 at 09:17:50AM +0100, Uwe Kleine-K?nig wrote:
> > On Sun, Feb 14, 2016 at 08:07:55PM +0000, Russell King - ARM Linux wrote:
> > > On Sun, Feb 14, 2016 at 08:55:01PM +0100, Uwe Kleine-K?nig wrote:
> > > > So the unexpected abnormality here is that even though this device is
> > > > instantiated by dt, the driver doesn't provide any compatibles.
> > > > Either my expectation is wrong, then 67d02a1bbb33455 should be reverted
> > > 
> > > Your expectation is wrong.  AMBA primecell devices have hardware IDs
> > > and are matched to their drivers by those IDs.  Just like PCI.
> > 
> > pci devices don't appear in dt, do they? I don't see the connection
> > between amba devices and platform devices, see my other mail in this
> > thread for some more details.
> 
> They both have hardware IDs, and they are both matched via those hardware
> IDs.

I changed platform_match which is about matching by dt compatible, acpi
and/or device name. I don't see how this can affect an amba device given
they match to a driver by a hardware id.

> Your change has introduced a regression and is therefore wrong.

I'd like to understand though why and how my commit is wrong to be able
to fix it instead of getting it reverted.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From marc.zyngier at arm.com  Mon Feb 15 01:14:15 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Feb 2016 09:14:15 +0000
Subject: [PATCH] irqchip: irq-mvebu-odmi: new driver
In-Reply-To: <1455522162-16425-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455522162-16425-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <56C196E7.2060106@arm.com>

Hi Thomas,

On 15/02/16 07:42, Thomas Petazzoni wrote:
> This commits adds a new irqchip driver that handles the ODMI
> controller found on Marvell 7K/8K processors. The ODMI controller
> provide MSI interrupt functionality to on-board peripherals, much like
> the GIC-v2m.

May I suggest a title that says a bit more than just "new driver"?
Something a bit more descriptive like "Platform MSI support"?

> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  .../marvell,odmi-controller.txt                    |  36 +++
>  drivers/irqchip/Kconfig                            |   4 +
>  drivers/irqchip/Makefile                           |   1 +
>  drivers/irqchip/irq-mvebu-odmi.c                   | 270 +++++++++++++++++++++
>  4 files changed, 311 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
>  create mode 100644 drivers/irqchip/irq-mvebu-odmi.c
> 
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
> new file mode 100644
> index 0000000..a2470af
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
> @@ -0,0 +1,36 @@
> +
> +* Marvell ODMI for MSI support
> +
> +Some Marvell SoCs have an On-Die Message Interrupt (ODMI) controller
> +which can be used by on-board peripheral for MSI interrupts.
> +
> +Required properties:
> +
> +- compatible	       : The value here should contain "marvell,odmi-controller".
> +
> +- interrupt,controller : Identifies the node as an interrupt controller.
> +
> +- msi-controller       : Identifies the node as an MSI controller.
> +
> +- marvell,odmi-frames  : Number of ODMI frames available. Each frame
> +                         provides a number of events.
> +
> +- reg		       : List of register definitions, one for each
> +                         ODMI frame.
> +
> +- marvell,spi-base     : List of GIC base SPI interrupts, one for each
> +                         ODMI frame.

Please add a pointer to the GIC documentation, so that it is explicit
what SPIs are. Also, is the SPI number 0 based? or 32 based? Looking at
the code, it looks to be 32-based.

Please document the need for an "interrupt-parent" property, which may
be implicit in a DT, but fundamental to the understanding of the system.

> +
> +Example:
> +
> +	odmi: odmi at 300000 {
> +		compatible = "marvell,odmi-controller";
> +		interrupt-controller;
> +		msi-controller;
> +		marvell,odmi-frames = <4>;
> +		reg = <0x300000 0x4000>,
> +		      <0x304000 0x4000>,
> +		      <0x308000 0x4000>,
> +		      <0x30C000 0x4000>;
> +		marvell,spi-base = <128>, <136>, <144>, <152>;
> +	};
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index 715923d..18bed3c 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -217,3 +217,7 @@ config IRQ_MXS
>  	def_bool y if MACH_ASM9260 || ARCH_MXS
>  	select IRQ_DOMAIN
>  	select STMP_DEVICE
> +
> +config MVEBU_ODMI
> +	bool
> +	select GENERIC_MSI_IRQ_DOMAIN
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 18caacb..29c388f 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -59,3 +59,4 @@ obj-$(CONFIG_ARCH_SA1100)		+= irq-sa11x0.o
>  obj-$(CONFIG_INGENIC_IRQ)		+= irq-ingenic.o
>  obj-$(CONFIG_IMX_GPCV2)			+= irq-imx-gpcv2.o
>  obj-$(CONFIG_PIC32_EVIC)		+= irq-pic32-evic.o
> +obj-$(CONFIG_MVEBU_ODMI)		+= irq-mvebu-odmi.o
> diff --git a/drivers/irqchip/irq-mvebu-odmi.c b/drivers/irqchip/irq-mvebu-odmi.c
> new file mode 100644
> index 0000000..c3e00b9
> --- /dev/null
> +++ b/drivers/irqchip/irq-mvebu-odmi.c
> @@ -0,0 +1,270 @@
> +/*
> + * Copyright (C) 2016 Marvell
> + *
> + * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#define pr_fmt(fmt) "GIC-ODMI: " fmt
> +
> +#include <linux/irq.h>
> +#include <linux/irqchip.h>
> +#include <linux/irqdomain.h>
> +#include <linux/kernel.h>
> +#include <linux/msi.h>
> +#include <linux/of_address.h>
> +#include <linux/slab.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +#define GICP_ODMIN_SET			0x40
> +#define   GICP_ODMI_INT_NUM_SHIFT	12
> +#define GICP_ODMIN_GM_EP_R0		0x110
> +#define GICP_ODMIN_GM_EP_R1		0x114
> +#define GICP_ODMIN_GM_EA_R0		0x108
> +#define GICP_ODMIN_GM_EA_R1		0x118
> +
> +/*
> + * We don't support the group events, so we simply have 8 interrupts
> + * per frame.
> + */
> +#define NODMIS_PER_FRAME 8
> +
> +struct odmi_data {
> +	struct resource res;
> +	void __iomem *base;
> +	unsigned int spi_base;
> +	unsigned long bm;

So you keep a bitmap per frame? That seems a bit odd - see below.

> +};
> +
> +static struct odmi_data *odmis;
> +static unsigned int odmis_count;
> +
> +/*
> + * Lock protecting the allocation bitmap embedded in the odmi_data
> + * structure. Only one spinlock is used, since allocation/freeing of
> + * MSI interrupts is infrequent.
> + */
> +static DEFINE_SPINLOCK(odmis_lock);
> +
> +static int odmi_set_affinity(struct irq_data *irq_data,
> +			       const struct cpumask *mask, bool force)
> +{
> +	int ret;
> +
> +	ret = irq_chip_set_affinity_parent(irq_data, mask, force);
> +	if (ret == IRQ_SET_MASK_OK)
> +		ret = IRQ_SET_MASK_OK_DONE;

I'm planning to fix GICv2 so that we don't need that anymore (much like
Antoine did got GICv3 in his Alpine series).

> +
> +	return ret;
> +}
> +
> +static void odmi_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> +{
> +	struct odmi_data *odmi = NULL;
> +	phys_addr_t addr;
> +	unsigned int odmi_offset, i;
> +
> +	/* Search the ODMI frame handling this interrupt */
> +	for (i = 0; i < odmis_count; i++) {
> +		if (data->hwirq >= odmis[i].spi_base &&
> +		    data->hwirq < (odmis[i].spi_base + NODMIS_PER_FRAME)) {
> +			odmi = &odmis[i];
> +			break;
> +		}
> +	}

So assume that instead of a bitmap per frame, you have a global one, and
hwirq is just the bit number in the bitmap. You have 8 interrupts per
frame, so you can compute things like this:

odmi = &odmi[data->hwirq >> 3];
odmi_offset = odmi->spi_base + (data->hwirq & 3);

Job done.

> +
> +	if (WARN_ON(!odmi))
> +		return;
> +
> +	odmi_offset = (data->hwirq - odmi->spi_base);
> +
> +	addr = odmi->res.start + GICP_ODMIN_SET;
> +
> +	msg->address_hi = upper_32_bits(addr);
> +	msg->address_lo = lower_32_bits(addr);
> +	msg->data = odmi_offset << GICP_ODMI_INT_NUM_SHIFT;
> +}
> +
> +static struct irq_chip odmi_irq_chip = {
> +	.name			= "ODMI",
> +	.irq_mask		= irq_chip_mask_parent,
> +	.irq_unmask		= irq_chip_unmask_parent,
> +	.irq_eoi		= irq_chip_eoi_parent,
> +	.irq_set_affinity	= odmi_set_affinity,
> +	.irq_compose_msi_msg	= odmi_compose_msi_msg,
> +};
> +
> +static int odmi_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> +				 unsigned int nr_irqs, void *args)
> +{
> +	struct odmi_data *odmi = NULL;
> +	struct irq_fwspec fwspec;
> +	struct irq_data *d;
> +	unsigned int offset, hwirq;
> +	int i, ret;
> +
> +	spin_lock(&odmis_lock);
> +	for (i = 0; i < odmis_count; i++) {
> +		offset = find_first_zero_bit(&odmis[i].bm, NODMIS_PER_FRAME);
> +		if (offset < NODMIS_PER_FRAME) {
> +			__set_bit(offset, &odmis[i].bm);
> +			odmi = &odmis[i];
> +			break;
> +		}
> +	}
> +	spin_unlock(&odmis_lock);

And this becomes much simpler.

> +
> +	if (!odmi)
> +		return -ENOSPC;
> +
> +	hwirq = odmi->spi_base + offset;
> +
> +	fwspec.fwnode = domain->parent->fwnode;
> +	fwspec.param_count = 3;
> +	fwspec.param[0] = GIC_SPI;
> +	fwspec.param[1] = hwirq - 32;
> +	fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
> +
> +	ret = irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
> +	if (ret) {
> +		pr_err("Cannot allocate parent IRQ\n");
> +		spin_lock(&odmis_lock);
> +		__clear_bit(offset, &odmi->bm);
> +		spin_unlock(&odmis_lock);
> +		return ret;
> +	}
> +
> +	/* Configure the interrupt line to be edge */
> +	d = irq_domain_get_irq_data(domain->parent, virq);
> +	d->chip->irq_set_type(d, IRQ_TYPE_EDGE_RISING);
> +
> +	irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
> +				      &odmi_irq_chip, NULL);
> +
> +	return 0;
> +}
> +
> +static void odmi_irq_domain_free(struct irq_domain *domain,
> +				 unsigned int virq, unsigned int nr_irqs)
> +{
> +	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> +	struct odmi_data *odmi = NULL;
> +	unsigned int offset;
> +	int i;
> +
> +	/*
> +	 * Check if the hwirq number is valid, and if so, to which
> +	 * ODMI frame it belongs
> +	 */
> +	spin_lock(&odmis_lock);
> +	for (i = 0; i < odmis_count; i++) {
> +		if (d->hwirq >= odmis[i].spi_base &&
> +		    d->hwirq < (odmis[i].spi_base + NODMIS_PER_FRAME)) {
> +			odmi = &odmis[i];
> +			offset = d->hwirq - odmis[i].spi_base;
> +			break;
> +		}
> +	}
> +	spin_unlock(&odmis_lock);

And that too.

> +
> +	if (!odmi) {
> +		pr_err("Failed to teardown msi. Invalid hwirq %lu\n", d->hwirq);
> +		return;
> +	}
> +
> +	irq_domain_free_irqs_parent(domain, virq, nr_irqs);
> +
> +	/* Actually free the MSI */
> +	spin_lock(&odmis_lock);
> +	__clear_bit(offset, &odmi->bm);
> +	spin_unlock(&odmis_lock);
> +}
> +
> +static const struct irq_domain_ops odmi_domain_ops = {
> +	.alloc	= odmi_irq_domain_alloc,
> +	.free	= odmi_irq_domain_free,
> +};
> +
> +static struct irq_chip odmi_msi_irq_chip = {
> +	.name	= "ODMI",
> +};
> +
> +static struct msi_domain_ops odmi_msi_ops = {
> +};
> +
> +static struct msi_domain_info odmi_msi_domain_info = {
> +	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),
> +	.ops	= &odmi_msi_ops,
> +	.chip	= &odmi_msi_irq_chip,
> +};
> +
> +static int __init mvebu_odmi_init(struct device_node *node,
> +				  struct device_node *parent)
> +{
> +	struct irq_domain *inner_domain, *plat_domain;
> +	int ret, i;
> +
> +	if (of_property_read_u32(node, "marvell,odmi-frames", &odmis_count))
> +		return -EINVAL;
> +
> +	odmis = kcalloc(odmis_count, sizeof(struct odmi_data), GFP_KERNEL);
> +	if (!odmis)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < odmis_count; i++) {
> +		struct odmi_data *odmi = &odmis[i];
> +
> +		ret = of_address_to_resource(node, i, &odmi->res);
> +		if (ret)
> +			goto err_unmap;
> +
> +		odmi->base = of_io_request_and_map(node, i, "odmi");
> +		if (IS_ERR(odmi->base)) {
> +			ret = PTR_ERR(odmi->base);
> +			goto err_unmap;
> +		}
> +
> +		if (of_property_read_u32_index(node, "marvell,spi-base",
> +					       i, &odmi->spi_base)) {
> +			ret = -EINVAL;
> +			goto err_unmap;
> +		}
> +	}
> +
> +	inner_domain = irq_domain_create_linear(of_node_to_fwnode(node),
> +						odmis_count * NODMIS_PER_FRAME,
> +						&odmi_domain_ops, NULL);
> +	if (!inner_domain) {
> +		ret = -ENOMEM;
> +		goto err_unmap;
> +	}
> +
> +	inner_domain->parent = irq_find_host(parent);
> +
> +	plat_domain = platform_msi_create_irq_domain(of_node_to_fwnode(node),
> +						     &odmi_msi_domain_info,
> +						     inner_domain);
> +	if (!plat_domain) {
> +		ret = -ENOMEM;
> +		goto err_remove_inner;
> +	}
> +
> +	return 0;
> +
> +err_remove_inner:
> +	irq_domain_remove(inner_domain);
> +err_unmap:
> +	for (i = 0; i < odmis_count; i++) {
> +		struct odmi_data *odmi = &odmis[i];
> +
> +		if (odmi->base && !IS_ERR(odmi->base))
> +			iounmap(odmis[i].base);
> +	}
> +	kfree(odmis);
> +	return ret;
> +}
> +
> +IRQCHIP_DECLARE(mvebu_odmi, "marvell,odmi-controller", mvebu_odmi_init);
> 

It otherwise looks pretty good to me.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From linus.walleij at linaro.org  Mon Feb 15 01:15:33 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 15 Feb 2016 10:15:33 +0100
Subject: [GIT PULL] plat-versatile clock.c and generic clkdev.h
Message-ID: <CACRpkdbJPPR8jADF1p++w60jZre3tpCAECsaqkzAk4-Y4+N-SA@mail.gmail.com>

Hi ARM SoC folks,

these are Stephen Boyds changes to remove a stale clock implementation
and move to the generic clkdev.h that I queued at Arnd's request, it turns
out I will not have any busines changing stuff in arch/arm/plat-versatile
for this merge window (however a few changes around mach-*) so
this can be pulled in separately.

Please pull this in!

Yours,
Linus Walleij


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git
tags/plat-versatile-cleanup

for you to fetch changes up to 34d2f4d3a4d6a6b204ebfd12d1d2c159360d41a4:

  ARM: Use generic clkdev.h header (2016-02-10 09:22:35 +0100)

----------------------------------------------------------------
plat-versatile cleanup:
- Removes the clock.c in plat-versatile that is no longer used
- Move ARM to use the generic clockdev.h header

----------------------------------------------------------------
Stephen Boyd (2):
      ARM: plat-versatile: Remove unused clock.c file
      ARM: Use generic clkdev.h header

 arch/arm/include/asm/Kbuild      |  1 +
 arch/arm/include/asm/clkdev.h    | 31 -----------------
 arch/arm/plat-versatile/Kconfig  |  3 --
 arch/arm/plat-versatile/Makefile |  1 -
 arch/arm/plat-versatile/clock.c  | 74 ----------------------------------------
 5 files changed, 1 insertion(+), 109 deletions(-)
 delete mode 100644 arch/arm/include/asm/clkdev.h
 delete mode 100644 arch/arm/plat-versatile/clock.c


From linus.walleij at linaro.org  Mon Feb 15 01:17:23 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 15 Feb 2016 10:17:23 +0100
Subject: [linux-sunxi] Re: [PATCH v2 3/5] pinctrl: sunxi: Add H3 R_PIO
 controller support
In-Reply-To: <20160215080816.GA6426@box2.japko.eu>
References: <1454448113-18810-1-git-send-email-k@japko.eu>
 <1454448113-18810-4-git-send-email-k@japko.eu>
 <CACRpkdZkSzcb0fmghkvsfRHpsU-SsSGPP6YvstAW7387HS0xJw@mail.gmail.com>
 <20160215080816.GA6426@box2.japko.eu>
Message-ID: <CACRpkdbfNeh7_=3ReQtJc7OxkkQEn+BUhZ0O0SKnFsRD=WZiUQ@mail.gmail.com>

On Mon, Feb 15, 2016 at 9:08 AM, Krzysztof Adamski <k at japko.eu> wrote:
> On Thu, Feb 11, 2016 at 02:21:15PM +0100, Linus Walleij wrote:
>>
>> On Tue, Feb 2, 2016 at 10:21 PM, Krzysztof Adamski <k at japko.eu> wrote:
>>
>>> H3 has additional PIO controller similar to what we can find on A23.
>>> It's a 12 pin port, described in H3 Datasheet rev 1.1, pages 345-350.
>>>
>>> Signed-off-by: Krzysztof Adamski <k at japko.eu>
>>
>>
>> Patch applied with Maxime's ACK.
>
>
> Hi Linus,
>
> You took v2 which does not add documentation for
> allwinner,sun8i-h3-r-pinctrl compatible that is added in this patch.  This
> was fixed in v3. Should I prepare a patch for you that only adds this to the
> documentation or you can handle this by taking v3/v4 instead of this patch?

Ooops please send a fixup patch, I don't like to rebase the
tree if possible. Sorry for the mess and thanks for your help.

Yours,
Linus Walleij


From daniel.baluta at gmail.com  Mon Feb 15 01:18:20 2016
From: daniel.baluta at gmail.com (Daniel Baluta)
Date: Mon, 15 Feb 2016 11:18:20 +0200
Subject: [PATCH] iio: health/afe4403: mark suspend/resume functions
 __maybe_unused
In-Reply-To: <1455526993-2132098-1-git-send-email-arnd@arndb.de>
References: <1455526993-2132098-1-git-send-email-arnd@arndb.de>
Message-ID: <CAEnQRZBSYy2inu0mUtXEdhEKWQj5i-YUFDL61prvC_8P_L0adQ@mail.gmail.com>

On Mon, Feb 15, 2016 at 11:02 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> The newly added afe4403 driver implements suspend/resume using the
> SIMPLE_DEV_PM_OPS() macro, which leaves out references to the actual
> functions when CONFIG_PM is disabled, causing a harmless warning:
>
> health/afe4403.c:509:12: error: 'afe4403_suspend' defined but not used
> health/afe4403.c:530:12: error: 'afe4403_resume' defined but not used
>
> This marks the functions as __maybe_unused so we don't get those
> warnings.
>
Or we could put _suspend and _resume under CONFIG_PM_SLEEP.

We have:

:~/w/iio/drivers/iio$ ack-grep SIMPLE_DEV_PM_OPS | wc -l
31

and only 2 drivers using __maybe_unused.

:~/w/iio/drivers/iio$ ack-grep maybe_unused
gyro/itg3200_core.c
354:static int __maybe_unused itg3200_suspend(struct device *dev)
365:static int __maybe_unused itg3200_resume(struct device *dev)

adc/imx7d_adc.c
553:static int __maybe_unused imx7d_adc_suspend(struct device *dev)
566:static int __maybe_unused imx7d_adc_resume(struct device *dev)

For consistency, we should use CONFIG_PM_SLEEP and get rid of __maybe_unused.

> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: eec96d1e2d31 ("iio: health: Add driver for the TI AFE4403 heart monitor")
> ---
>  drivers/iio/health/afe4403.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/health/afe4403.c b/drivers/iio/health/afe4403.c
> index 91c046e40d2f..88e43f87b926 100644
> --- a/drivers/iio/health/afe4403.c
> +++ b/drivers/iio/health/afe4403.c
> @@ -506,7 +506,7 @@ static const struct of_device_id afe4403_of_match[] = {
>  MODULE_DEVICE_TABLE(of, afe4403_of_match);
>  #endif
>
> -static int afe4403_suspend(struct device *dev)
> +static int __maybe_unused afe4403_suspend(struct device *dev)
>  {
>         struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>         struct afe4403_data *afe = iio_priv(indio_dev);
> @@ -527,7 +527,7 @@ static int afe4403_suspend(struct device *dev)
>         return 0;
>  }
>
> -static int afe4403_resume(struct device *dev)
> +static int __maybe_unused afe4403_resume(struct device *dev)
>  {
>         struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>         struct afe4403_data *afe = iio_priv(indio_dev);


From jamesjj.liao at mediatek.com  Mon Feb 15 01:19:42 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Mon, 15 Feb 2016 17:19:42 +0800
Subject: [PATCH v6 4/7] clk: mediatek: Add MT2701 clock support
In-Reply-To: <20160210200853.26445.15165@quark.deferred.io>
References: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
 <1454665050-37776-5-git-send-email-jamesjj.liao@mediatek.com>
 <20160210200853.26445.15165@quark.deferred.io>
Message-ID: <1455527982.29688.8.camel@mtksdaap41>

Hi Mike,

On Wed, 2016-02-10 at 12:08 -0800, Michael Turquette wrote:
> Quoting James Liao (2016-02-05 01:37:27)
> > +CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt2701-topckgen", mtk_topckgen_init);
> > +CLK_OF_DECLARE(mtk_infrasys, "mediatek,mt2701-infracfg", mtk_infrasys_init);
> > +CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt2701-pericfg", mtk_pericfg_init);
> > +CLK_OF_DECLARE(mtk_mmsys, "mediatek,mt2701-mmsys", mtk_mmsys_init);
> > +CLK_OF_DECLARE(mtk_imgsys, "mediatek,mt2701-imgsys", mtk_imgsys_init);
> > +CLK_OF_DECLARE(mtk_vdecsys, "mediatek,mt2701-vdecsys", mtk_vdecsys_init);
> > +CLK_OF_DECLARE(mtk_hifsys, "mediatek,mt2701-hifsys", mtk_hifsys_init);
> > +CLK_OF_DECLARE(mtk_ethsys, "mediatek,mt2701-ethsys", mtk_ethsys_init);
> > +CLK_OF_DECLARE(mtk_bdpsys, "mediatek,mt2701-bdpsys", mtk_bdpsys_init);
> > +CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt2701-apmixedsys",
> 
> :-/
> 
> This is way too much CLK_OF_DECLARE and not enough Linux Driver Model.
> 
> I understand that some platforms really must initialize some clocks very
> early, but can we please separate those into one table and call
> CLK_OF_DECLARE on only that set, and then register the rest through a
> platform_driver later on?

I know CLK_OF_DECLARE is much earlier than platform_driver, so it can
ensure all drivers lookup their clocks successfully during
platform_driver probe. Is there anything different to init these clock
providers in CLK_OF_DECLARE and platform_driver?


Best regards,

James





From mpa at pengutronix.de  Mon Feb 15 01:25:27 2016
From: mpa at pengutronix.de (Markus Pargmann)
Date: Mon, 15 Feb 2016 10:25:27 +0100
Subject: [PATCH v10 4/8] mfd: fsl imx25 Touchscreen ADC driver
In-Reply-To: <20160209103513.GC24522@x1>
References: <1450101234-2191-1-git-send-email-mpa@pengutronix.de>
 <6151166.y0HMDdqtvF@adelgunde> <20160209103513.GC24522@x1>
Message-ID: <6071608.sYYGeTKS0i@adelgunde>

On Tuesday, February 09, 2016 10:35:13 AM Lee Jones wrote:
> On Tue, 02 Feb 2016, Markus Pargmann wrote:
> 
> > Hi,
> > 
> > On Monday, January 11, 2016 06:54:41 AM Lee Jones wrote:
> > > On Mon, 14 Dec 2015, Markus Pargmann wrote:
> > > 
> > > > This is the core driver for imx25 touchscreen/adc driver. The module
> > > > has one shared ADC and two different conversion queues which use the
> > > > ADC. The two queues are identical. Both can be used for general purpose
> > > > ADC but one is meant to be used for touchscreens.
> > > > 
> > > > This driver is the core which manages the central components and
> > > > registers of the TSC/ADC unit. It manages the IRQs and forwards them to
> > > > the correct components.
> > > > 
> > > > Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> > > > Signed-off-by: Denis Carikli <denis at eukrea.com>
> > > > 
> > > > [ensure correct ADC clock depending on the IPG clock]
> > > > Signed-off-by: Juergen Borleis <jbe at pengutronix.de>
> > > > Acked-by: Jonathan Cameron <jic23 at kernel.org>
> > > > ---
> > > > 
> > > > Notes:
> > > >     Changes in v7:
> > > >      - Cleanup bit defines in header files to be more readable
> > > >      - Fix irq check to return with an error for irq <= 0
> > > >      - Add COMPILE_TEST in Kconfig file
> > > >     
> > > >     Changes in v5:
> > > >      - Remove ifdef CONFIG_OF as this driver is only for DT usage
> > > >      - Remove module owner
> > > >      - Add Kconfig dependencies ARCH_MX25 and OF
> > > > 
> > > >  drivers/mfd/Kconfig             |   9 ++
> > > >  drivers/mfd/Makefile            |   2 +
> > > >  drivers/mfd/fsl-imx25-tsadc.c   | 203 ++++++++++++++++++++++++++++++++++++++++
> > > >  include/linux/mfd/imx25-tsadc.h | 140 +++++++++++++++++++++++++++
> > > >  4 files changed, 354 insertions(+)
> > > >  create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
> > > >  create mode 100644 include/linux/mfd/imx25-tsadc.h
> > > 
> > > For my own reference:
> > >   Acked-by: Lee Jones <lee.jones at linaro.org>
> > > 
> > > I will apply this and sent out pull-requests to the relevant
> > > maintainers once -rc1 is out.
> > 
> > Thanks. Do you mean just this patch or the whole series?
> 
> I will take all of the /driver patches.  The ARM patches need to go in
> through ARM-SoC via the relevant sub-arch maintainer(s).
> 
> > Shall I resend the whole series to fix the commit title of the first
> > patch?
> 
> No, that's fine.  I'll handle that *this time*.

Thank you.

Best Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160215/95cb73e1/attachment.sig>

From ard.biesheuvel at linaro.org  Mon Feb 15 01:28:32 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 15 Feb 2016 10:28:32 +0100
Subject: [PATCH] arm64: mark kernel text segment as MEMBLOCK_NOMAP
Message-ID: <1455528512-32491-1-git-send-email-ard.biesheuvel@linaro.org>

Commit 752af28bd711 ("arm64: move kernel image to base of vmalloc area")
moves the mapping of the kernel text and data segments out of the linear
region, and takes care not to create a writable alias of the read-only
kernel text segment by checking each memblock against overlap when the
memblocks are mapped into the linear mapping.

However, it is more correct, and much simpler, to mark the [_stext, _etext]
interval as MEMBLOCK_NOMAP. This will also prevent the interval from being
omitted from the linear region, but this fact will now also be reflected
in the output of pfn_valid(), and so code that expects any pfn_valid()
page to be mapped and accessible (which is a reasonable assumption) does
not get surprised by the text segment being inaccessible via the linear
mapping.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---

This should hopefully address the issue reported by James, but I suppose
more work is required on the hibernate side to ensure the unmapped text
region is preserved, since it is no longer covered by the linear mapping.

 arch/arm64/mm/init.c |  1 +
 arch/arm64/mm/mmu.c  | 39 ++------------------
 2 files changed, 4 insertions(+), 36 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 023c41f22b5b..e895fb6ff9dd 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -218,6 +218,7 @@ void __init arm64_memblock_init(void)
 	 * pagetables with memblock.
 	 */
 	memblock_reserve(__pa(_text), _end - _text);
+	memblock_mark_nomap(__pa(_stext), _etext - _stext);
 #ifdef CONFIG_BLK_DEV_INITRD
 	if (initrd_start) {
 		memblock_reserve(initrd_start, initrd_end - initrd_start);
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 5d7e0b801ab7..5ca2f315ba9d 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -352,41 +352,6 @@ static void create_mapping_late(phys_addr_t phys, unsigned long virt,
 			     late_pgtable_alloc);
 }
 
-static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end)
-{
-
-	unsigned long kernel_start = __pa(_stext);
-	unsigned long kernel_end = __pa(_etext);
-
-	/*
-	 * Take care not to create a writable alias for the
-	 * read-only text and rodata sections of the kernel image.
-	 */
-
-	/* No overlap with the kernel text */
-	if (end < kernel_start || start >= kernel_end) {
-		__create_pgd_mapping(pgd, start, __phys_to_virt(start),
-				     end - start, PAGE_KERNEL,
-				     early_pgtable_alloc);
-		return;
-	}
-
-	/*
-	 * This block overlaps the kernel text mapping. Map the portion(s) which
-	 * don't overlap.
-	 */
-	if (start < kernel_start)
-		__create_pgd_mapping(pgd, start,
-				     __phys_to_virt(start),
-				     kernel_start - start, PAGE_KERNEL,
-				     early_pgtable_alloc);
-	if (kernel_end < end)
-		__create_pgd_mapping(pgd, kernel_end,
-				     __phys_to_virt(kernel_end),
-				     end - kernel_end, PAGE_KERNEL,
-				     early_pgtable_alloc);
-}
-
 static void __init map_mem(pgd_t *pgd)
 {
 	struct memblock_region *reg;
@@ -401,7 +366,9 @@ static void __init map_mem(pgd_t *pgd)
 		if (memblock_is_nomap(reg))
 			continue;
 
-		__map_memblock(pgd, start, end);
+		__create_pgd_mapping(pgd, start, __phys_to_virt(start),
+				     end - start, PAGE_KERNEL,
+				     early_pgtable_alloc);
 	}
 }
 
-- 
2.5.0



From marc.zyngier at arm.com  Mon Feb 15 01:32:08 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Feb 2016 09:32:08 +0000
Subject: [PATCH 5/5] arm64: marvell: add Device Tree files for Armada 7K/8K
In-Reply-To: <1455526065-7307-6-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455526065-7307-6-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <56C19B18.8090005@arm.com>

Hi Thomas,

On 15/02/16 08:47, Thomas Petazzoni wrote:
> This commit adds the base Device Tree files for the Armada 7K and 8K
> SoCs, as well as the Armada 8040 DB board.
> 
> The Armada 7020, 7040 (7K family) and 8020, 8040 (8K family) are
> composed of:
> 
>  - An AP806 block that contains the CPU core and a few basic
>    peripherals. The AP806 is available in dual core configurations
>    (used in 7020 and 8020) and quad core configurations (used in 8020
>    and 8040).
> 
>  - One or two CP110 blocks that contain all the high-speed interfaces
>    (SATA, PCIe, Ethernet, etc.). The 7K family chips have one CP110,
>    and the 8K family chips have two CP110, giving them twice the
>    number of HW interfaces.
> 
> In order to represent this from a Device Tree point of view, this
> commit creates the following hierarchy:
> 
>  * armada-ap806.dtsi - definitions common to dual/quad ap806
>    * armada-ap806-dual.dtsi - description of the two CPUs
>      * armada-7020.dtsi - description of the 7020 SoC
>      * armada-8020.dtsi - description of the 8020 SoC
>    * armada-ap806-quad.dtsi - description of the four CPUs
>      * armada-7040.dtsi - description of the 7040 SoC
>        * armada-7040-db.dts - description of the 7040 board
>      * armada-8040.dtsi - description of the 8040 SoC
> 
> The CP110 blocks are not described yet, and will be part of future
> patch series.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  .../bindings/arm/marvell/armada-7k-8k.txt          |  24 +++
>  arch/arm64/boot/dts/marvell/Makefile               |   1 +
>  arch/arm64/boot/dts/marvell/armada-7020.dtsi       |  54 +++++
>  arch/arm64/boot/dts/marvell/armada-7040-db.dts     |  92 ++++++++
>  arch/arm64/boot/dts/marvell/armada-7040.dtsi       |  54 +++++
>  arch/arm64/boot/dts/marvell/armada-8020.dtsi       |  54 +++++
>  arch/arm64/boot/dts/marvell/armada-8040.dtsi       |  54 +++++
>  arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi |  71 +++++++
>  arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi |  84 ++++++++
>  arch/arm64/boot/dts/marvell/armada-ap806.dtsi      | 235 +++++++++++++++++++++
>  10 files changed, 723 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-7020.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-7040-db.dts
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-7040.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-8020.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-8040.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> 

[...[

> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> new file mode 100644
> index 0000000..3303db2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> @@ -0,0 +1,235 @@
> +/*
> + * Copyright (C) 2016 Marvell Technology Group Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPLv2 or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This library is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/*
> + * Device Tree file for Marvell Armada AP806.
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/dts-v1/;
> +
> +/ {
> +	model = "Marvell Armada AP806";
> +	compatible = "marvell,armada-ap806";
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	psci {
> +		compatible = "arm,psci-0.2";
> +		method = "smc";
> +	};
> +
> +
> +	ap806 {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		compatible = "simple-bus";
> +		interrupt-parent = <&gic>;
> +		ranges;
> +
> +		config-space {
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			compatible = "simple-bus";
> +			ranges = <0x0 0x0 0xf0000000 0x1000000>;
> +
> +			gic: interrupt-controller at 210000 {
> +				compatible = "arm,cortex-a15-gic",
> +					     "arm,cortex-a9-gic";
> +				#interrupt-cells = <3>;
> +				#address-cells = <1>;
> +				#size-cells = <1>;
> +				ranges;
> +				interrupt-controller;
> +				interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> +				reg = <0x210000 0x1000>,
> +				      <0x220000 0x1000>,

Assuming we do have a GIC400 here (which is extremely likely), the GICC
block should be at least 8kB to reflect the fact that this is a GICv2.

> +				      <0x240000 0x2000>,
> +				      <0x260000 0x2000>;
> +
> +				gic_v2m0: v2m at 280000 {
> +					compatible = "arm,gic-v2m-frame";
> +					msi-controller;
> +					reg = <0x280000 0x1000>;
> +					arm,msi-base-spi = <160>;
> +					arm,msi-num-spis = <32>;
> +				};
> +				gic_v2m1: v2m at 290000 {
> +					compatible = "arm,gic-v2m-frame";
> +					msi-controller;
> +					reg = <0x290000 0x1000>;
> +					arm,msi-base-spi = <192>;
> +					arm,msi-num-spis = <32>;
> +				};
> +				gic_v2m2: v2m at 2a0000 {
> +					compatible = "arm,gic-v2m-frame";
> +					msi-controller;
> +					reg = <0x2a0000 0x1000>;
> +					arm,msi-base-spi = <224>;
> +					arm,msi-num-spis = <32>;
> +				};
> +				gic_v2m3: v2m at 2b0000 {
> +					compatible = "arm,gic-v2m-frame";
> +					msi-controller;
> +					reg = <0x2b0000 0x1000>;
> +					arm,msi-base-spi = <256>;
> +					arm,msi-num-spis = <32>;
> +				};
> +			};

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From wens at csie.org  Mon Feb 15 01:34:18 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 17:34:18 +0800
Subject: [PATCH 10/14] ARM: dts: sun8i-a83t: Add PRCM related clocks and
 resets
In-Reply-To: <CAGb2v65cfG=cJ91+9G5uS5XcUh0nx6-7ZnMr7RjSGqXPHjyxpQ@mail.gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-11-git-send-email-vishnupatekar0510@gmail.com>
 <CAGb2v67iO-816KaLttWRRPL2f7hpfgJ1--p69tD_oOrewmOjCA@mail.gmail.com>
 <CAEzqOZtsdHC2tCgjC=Bj5q3RFip2Uyni8bFC16u03PRLCra5KA@mail.gmail.com>
 <CAGb2v65cfG=cJ91+9G5uS5XcUh0nx6-7ZnMr7RjSGqXPHjyxpQ@mail.gmail.com>
Message-ID: <CAGb2v66L-zKYbA7h56bY3y_Jf8wOzmW_puRc+R8tQmVY6u1DZw@mail.gmail.com>

On Sat, Feb 13, 2016 at 12:43 AM, Chen-Yu Tsai <wens at csie.org> wrote:
> On Sat, Feb 13, 2016 at 12:06 AM, Vishnu Patekar
> <vishnupatekar0510 at gmail.com> wrote:
>> Hello Wens,
>>
>>
>> On Tue, Feb 2, 2016 at 2:44 PM, Chen-Yu Tsai <wens at csie.org> wrote:
>>> On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
>>> <vishnupatekar0510 at gmail.com> wrote:
>>>> This adds A83T PRCM related clocks, clock resets.
>>>>
>>>> As a83t apb0 gates clock support is added earlier, this enables it.
>>>> Apart from apb0 gates, other added clocks are compatible with
>>>> earlier sun8i socs.
>>>>
>>>> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
>>>> ---
>>>>  arch/arm/boot/dts/sun8i-a83t.dtsi | 44 +++++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 44 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
>>>> index ac96aa1..5ea20ff 100644
>>>> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
>>>> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
>>>> @@ -268,6 +268,44 @@
>>>>                                              "mmc2_output",
>>>>                                              "mmc2_sample";
>>>>                 };
>>>> +
>>>> +               cpus_clk: clk at 01f01400 {
>>>> +                       compatible = "allwinner,sun9i-a80-cpus-clk";
>>>> +                       reg = <0x01f01400 0x4>;
>>>> +                       #clock-cells = <0>;
>>>> +                       clocks = <&osc16Md512>, <&osc24M>, <&pll6>, <&osc16M>;
>>>> +                       clock-output-names = "cpus";
>>>> +               };
>>>> +
>>>> +               ahb0: ahb0_clk {
>>>> +                       compatible = "fixed-factor-clock";
>>>> +                       #clock-cells = <0>;
>>>> +                       clock-div = <1>;
>>>> +                       clock-mult = <1>;
>>>> +                       clocks = <&cpus_clk>;
>>>> +                       clock-output-names = "ahb0";
>>>> +               };
>>>> +
>>>> +               apb0: clk at 01f0140c {
>>>> +                       compatible = "allwinner,sun8i-a23-apb0-clk";
>>>
>>> This is actually wrong, as it is wrong in sun9i-a80.dtsi.
>>> I've sent a patch series for it.
>> A83T apb0 is different from A80, and it's same as A23, so this should
>> be correct.
>> Please correct me in case I'm missing something.
>
> My user manual (v1.5.1) says A83T apb0 dividers (page. 246) are
> /1, /2, /3, /4, while the A23 is /1, /2, /4, /8.

As Vishnu pointed out on IRC, the A23 driver is wrong. They are in fact,
both one-based dividers. I'll send a patch to fix this.

ChenYu

> ChenYu
>
>>> Also the drivers for "allwinner,sun9i-a80-cpus-clk" and
>>> "allwinner,sun9i-a80-apbs-clk"
>>> are only compiled for CONFIG_MACH_SUN9I. Please add a patch to address this.
>> Okie.
>>>
>>> Regards
>>> ChenYu
>>>
>>>> +                       reg = <0x01f0140c 0x4>;
>>>> +                       #clock-cells = <0>;
>>>> +                       clocks = <&ahb0>;
>>>> +                       clock-output-names = "apb0";
>>>> +               };
>>>> +
>>>> +               apb0_gates: clk at 01f01428 {
>>>> +                       compatible = "allwinner,sun8i-a83t-apb0-gates-clk";
>>>> +                       reg = <0x01f01428 0x4>;
>>>> +                       #clock-cells = <1>;
>>>> +                       clocks = <&apb0>;
>>>> +                       clock-indices = <0>, <1>,
>>>> +                                       <2>, <3>,
>>>> +                                       <4>, <6>, <7>;
>>>> +                       clock-output-names = "apb0_pio", "apb0_ir",
>>>> +                                       "apb0_timer", "apb0_rsb",
>>>> +                                       "apb0_uart", "apb0_i2c0", "apb0_twd";
>>>> +               };
>>>>         };
>>>>
>>>>         soc {
>>>> @@ -434,5 +472,11 @@
>>>>                         #interrupt-cells = <3>;
>>>>                         interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
>>>>                 };
>>>> +
>>>> +               apb0_reset: reset at 01f014b0 {
>>>> +                       reg = <0x01f014b0 0x4>;
>>>> +                       compatible = "allwinner,sun6i-a31-clock-reset";
>>>> +                       #reset-cells = <1>;
>>>> +               };
>>>>         };
>>>>  };
>>>> --
>>>> 1.9.1
>>>>


From lkp at intel.com  Mon Feb 15 01:34:20 2016
From: lkp at intel.com (kbuild test robot)
Date: Mon, 15 Feb 2016 17:34:20 +0800
Subject: [PATCH] dma: mv_xor_v2: new driver
In-Reply-To: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <201602151750.ChNRB1qR%fengguang.wu@intel.com>

Hi Thomas,

[auto build test WARNING on robh/for-next]
[also build test WARNING on v4.5-rc4 next-20160215]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Thomas-Petazzoni/dma-mv_xor_v2-new-driver/20160215-160120
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next


coccinelle warnings: (new ones prefixed by >>)

>> drivers/dma/mv_xor_v2.c:870:3-8: No need to set .owner here. The core will do it.

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation


From lkp at intel.com  Mon Feb 15 01:34:20 2016
From: lkp at intel.com (kbuild test robot)
Date: Mon, 15 Feb 2016 17:34:20 +0800
Subject: [PATCH] dma: mv_xor_v2: fix platform_no_drv_owner.cocci warnings
In-Reply-To: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <201602151750.ChNRB1qR%fengguang.wu@intel.com>
Message-ID: <20160215093420.GA124287@roam>

drivers/dma/mv_xor_v2.c:870:3-8: No need to set .owner here. The core will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Signed-off-by: Fengguang Wu <fengguang.wu at intel.com>
---

 mv_xor_v2.c |    1 -
 1 file changed, 1 deletion(-)

--- a/drivers/dma/mv_xor_v2.c
+++ b/drivers/dma/mv_xor_v2.c
@@ -867,7 +867,6 @@ static struct platform_driver mv_xor_v2_
 	.probe		= mv_xor_v2_probe,
 	.remove		= mv_xor_v2_remove,
 	.driver		= {
-		.owner	= THIS_MODULE,
 		.name	= "mv_xor_v2",
 		.of_match_table = of_match_ptr(mv_xor_v2_dt_ids),
 	},


From thomas.petazzoni at free-electrons.com  Mon Feb 15 01:37:12 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Feb 2016 10:37:12 +0100
Subject: [PATCH 0/5] arm64: Initial support for Marvell Armada 7K/8K
In-Reply-To: <2808783.Lm9AZL1OAe@wuerfel>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <2808783.Lm9AZL1OAe@wuerfel>
Message-ID: <20160215103712.55c09f47@free-electrons.com>

Arnd,

On Mon, 15 Feb 2016 10:24:29 +0100, Arnd Bergmann wrote:

> The new code looks ok, but I think I need to resubmit my cleanup of the
> Documentation/arm/Marvell/README fiel that I submitted a while ago,
> which now conflicts with the changes you did in patch 3.
> 
> If you don't mind, can you add my patch to your series to resolve
> the conflict? I'll resend in a minute.

Before my series, Gregory's series is already doing some changes to the
Marvell README file, though it is possible that they don't conflict
with your changes. Anyway, we'll take care of merging your file, I'll
sync with Gregory on this.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From wens at csie.org  Mon Feb 15 01:40:19 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 17:40:19 +0800
Subject: [PATCH v3] clk: sunxi: Fix sun8i-a23-apb0-clk divider flags
Message-ID: <1455529219-30204-1-git-send-email-wens@csie.org>

The APB0 clock on A23 is a zero-based divider, not a power-of-two based
divider.

Note that this patch does not apply cleanly to kernels before 4.5-rc1,
which added CLK_OF_DECLARE support to this driver.

Fixes: 57a1fbf28424 ("clk: sunxi: Add A23 APB0 divider clock support")
Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---

Vishnu pointed out that A23 is in fact a zero-based divider. This
version corrects the whole driver, now that we know this clock is
compatible between A23 and A80.

---
 drivers/clk/sunxi/clk-sun8i-apb0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi/clk-sun8i-apb0.c b/drivers/clk/sunxi/clk-sun8i-apb0.c
index 7ba61103a6f5..2ea61debffc1 100644
--- a/drivers/clk/sunxi/clk-sun8i-apb0.c
+++ b/drivers/clk/sunxi/clk-sun8i-apb0.c
@@ -36,7 +36,7 @@ static struct clk *sun8i_a23_apb0_register(struct device_node *node,
 
 	/* The A23 APB0 clock is a standard 2 bit wide divider clock */
 	clk = clk_register_divider(NULL, clk_name, clk_parent, 0, reg,
-				   0, 2, CLK_DIVIDER_POWER_OF_TWO, NULL);
+				   0, 2, 0, NULL);
 	if (IS_ERR(clk))
 		return clk;
 
-- 
2.7.0



From andy.yan at rock-chips.com  Mon Feb 15 01:43:06 2016
From: andy.yan at rock-chips.com (Andy Yan)
Date: Mon, 15 Feb 2016 17:43:06 +0800
Subject: [PATCH v3 1/4] dt-bindings: power: reset: add document for
 reboot-mode driver
In-Reply-To: <CALAqxLUnbFHjTuJXYXSruV3W0JJ09Fxz=KBe69tZDTd_3_+rxw@mail.gmail.com>
References: <1454406981-4692-1-git-send-email-andy.yan@rock-chips.com>
 <1454407151-4751-1-git-send-email-andy.yan@rock-chips.com>
 <20160204230814.GA4847@rob-hp-laptop>
 <CALAqxLVyznpLd2MLgGr28TDECpLZ=RpmhxH-SHqntXfBsctcmQ@mail.gmail.com>
 <20160205043507.GB4847@rob-hp-laptop>
 <CALAqxLUnbFHjTuJXYXSruV3W0JJ09Fxz=KBe69tZDTd_3_+rxw@mail.gmail.com>
Message-ID: <56C19DAA.5030602@rock-chips.com>

Hi Rob & John:

On 2016?02?05? 13:03, John Stultz wrote:
> On Thu, Feb 4, 2016 at 8:35 PM, Rob Herring <robh at kernel.org> wrote:
>> On Thu, Feb 04, 2016 at 03:46:15PM -0800, John Stultz wrote:
>>> On Thu, Feb 4, 2016 at 3:08 PM, Rob Herring <robh at kernel.org> wrote:
>>>> On Tue, Feb 02, 2016 at 05:59:11PM +0800, Andy Yan wrote:
>>>>> +Example:
>>>>> +     reboot-mode {
>>>>> +             mode-normal = <BOOT_NORMAL>;
>>>>> +             mode-recovery = <BOOT_RECOVERY>;
>>>>> +             mode-fastboot = <BOOT_FASTBOOT>;
>>>> I tend to agree with John on calling this mode-bootloader.
>>>>
>>>> OTOH, fastboot is more specific about what the mode is. The name in DT
>>>> and the userspace name don't necessarily have to be the same.
>>> Wait. This is a bit confusing. The utility of adding a property name
>>> and using that name be the reboot command parsed for made sense
>>> (compared to earlier versions which had command strings) as it made
>>> the dts more terse.   But it sounds here like you're suggesting we
>>> should have some logic in the driver that translates "reboot fastboot"
>>> to mode-bootloader or vice versa.
>> I said early on the DT names and kernel-userspace names should not
>> necessarily be linked. They can be, but we shouldn't require that.
> Sigh. Ok. It seemed it was due to earlier comments (maybe from others,
> but I thought it was you), that we moved from specifying a command
> string, to using the label. But if you think the label name and the
> commands shouldn't be linked, it seems like we should re-introduce
> that. No?
>
> Unless your thinking we need some sort of static in-kernel mapping of
> commands to label names? But that just seems painfully indirect for
> little gain ("Its obvious! For that mode, you use this term here, and
> that different term over there!").
>
>> My concern with mode-bootloader is what if you can boot into multiple
>> bootloader modes. Say USB mass storage is one option. "bootloader" is
>> not real specific.
> True. But as I think we agreed below, "bootloader" and "recovery" are
> basically defacto standards, and I think it would be a bad idea to try
> to declare all the existing android tooling and docs wrong just
> because the command is vague, technically.
>
>
>>>>> +             mode-loader = <BOOT_LOADER>;
>>>> This one needs a better name. Maybe it should be 'rockchip,mode-loader'
>>>> as it is vendor specific. Either way, loader is vague. Perhaps
>>>> rockchip,mode-bl-download?
>>> Hrm. So how what reboot command do you expect to trigger that?
>> Whatever your OS has defined to map to that.
>>
>> We could just decide the kernel will strip <vendor> and 'mode-' and
>> match commands against what remains.
> That part sounds sane, although I do think having vendor prefixes are
> reasonable for actual commands as well.
>
>
>>> I think one of the difficult things here is that there's no real
>>> standards for all bios/bootloader modes. So they are somewhat
>>> firmware/bootloader/device specific, and thus we need something that
>>> is flexible enough to allow lots of different modes to be easily
>>> specified.  That said, this does expose a userspace interface (though
>>> one could argue kernel ABI doesn't cross reboots :) so we should try
>>> to have some consistency so the same userspace can work on various
>>> devices.
>> There is: UEFI. Boot mode efivars are standard. But then they are pretty
>> much PC oriented though. It is more which device to boot off of, but
>> there is network boot or boot to bios setup.
> Well, there's a partial standard there.  I'm told for android on x86,
> there is no UEFI standard way to communicate rebooting to fastboot or
> recovery. Every device does its own device specific driver.
>
>
>>> I do think the "bootloader" and "recovery" arguments are somewhat
>>> defacto standards, well established on most android devices.
>> Yes, otherwise I'd be completely against "mode-bootloader" as the
>> property.
> Ok.
>
>>> I think here the concern is rockchip probably has some userspace that
>>> is already using "reboot maskrom" or "reboot loader" for their own
>>> uses. And its a bit of a pain to ask that userspace to be reworked to
>> Perhaps those are only for development and change would not be so
>> painful.
> Andy: Can you comment here? How critical are the specific commands
> you've used here for your userspace?
>
     Have some discussion with my colleague, we decided remove the" 
maskrom" mode in next version.
   Actually, this mode is not so used so often.
     But "reboot loader" is frequently used  in development by all the 
rockchip platform related people, even
some widely used factory tools use this command.So we really hope it can 
compatible with the existing tools
and user experience.
>>> use "reboot rom-download" or "reboot rockchip,rom-download" depending
>>> on how we try to deal with these.  (Granted, non-upstream interfaces
>>> aren't official, so that is their risk somewhat, but we avoid being
>>> smug about that :)
>> Or vendor specific modes require vendor specific translation in the
>> kernel.
> True.
>
>
>> To some extent we need to design what is right and worry about future
>> devices rather than cater to past devices. There's always some
>> compromise. What would you design ignoring the existing conditions.
>> Start there and then figure out how to make it work with current
>> designs.
> Fair enough. I just want to make sure we're not getting too caught up
> with design purity and are willing the meet the world where it is.
>
>>> Another part of the issue is there isn't really a way to probe for
>>> reboot cmd capability here. As much as I'd rather not complicate
>>> things, one couldn't easily extend existing userspace to work with
>>> current kernels as well as future kernels, since the reboot with an
>>> invalid command won't fail. The machine still resets. So you can't try
>>> one and fallback to the other.
>> Well, that's nice. Maybe we should change that? Or we're stuck with
>> that ABI?
> Maybe? I'm not sure what might have trouble with reboot failing if it
> sticks any extra noise in the reboot command.
> I'd probably lean towards sticking with the existing behavior.
>
>>> Maybe there needs to be a sysfs entry with the list of the supported commands?
>> You can just read the DT. Although, the problem then is what happens
>> when we move to the next firmware interface. We see that some with
>> devices having userspace dependencies on ATAGS.
> Heh. I guess. Thought I suspect "Just read the DT to sort out the
> available reboot modes" is probably not what most userspace wants to
> hear. :)
>
> thanks
> -john
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
>
>




From thomas.petazzoni at free-electrons.com  Mon Feb 15 01:50:08 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Feb 2016 10:50:08 +0100
Subject: [PATCH] dma: mv_xor_v2: new driver
In-Reply-To: <201602151735.BaFwBMOn%fengguang.wu@intel.com>
References: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <201602151735.BaFwBMOn%fengguang.wu@intel.com>
Message-ID: <20160215105008.74aa7869@free-electrons.com>

Marc,

This doesn't seem to be an issue introduced by my patch itself, but
rather a problem with the MSI subsystem itself. Is this already a known
issue (possibly already fixed), or should I investigate?

Thanks!

Thomas

On Mon, 15 Feb 2016 17:09:27 +0800, kbuild test robot wrote:
> Hi Thomas,
> 
> [auto build test ERROR on robh/for-next]
> [also build test ERROR on v4.5-rc4 next-20160215]
> [if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
> 
> url:    https://github.com/0day-ci/linux/commits/Thomas-Petazzoni/dma-mv_xor_v2-new-driver/20160215-160120
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
> config: openrisc-allyesconfig (attached as .config)
> reproduce:
>         wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         make.cross ARCH=openrisc 
> 
> All errors (new ones prefixed by >>):
> 
>    In file included from kernel/irq/chip.c:14:0:
> >> include/linux/msi.h:174:21: fatal error: asm/msi.h: No such file or directory
>    compilation terminated.
> 
> vim +174 include/linux/msi.h
> 
> c2791b80 Yijing Wang    2014-11-11  168  	void (*teardown_irq)(struct msi_controller *chip, unsigned int irq);
> 0cbdcfcf Thierry Reding 2013-08-09  169  };
> 0cbdcfcf Thierry Reding 2013-08-09  170  
> f3cf8bb0 Jiang Liu      2014-11-12  171  #ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
> d9109698 Jiang Liu      2014-11-15  172  
> aeeb5965 Jiang Liu      2014-11-15  173  #include <linux/irqhandler.h>
> d9109698 Jiang Liu      2014-11-15 @174  #include <asm/msi.h>
> d9109698 Jiang Liu      2014-11-15  175  
> f3cf8bb0 Jiang Liu      2014-11-12  176  struct irq_domain;
> 552c494a Marc Zyngier   2015-11-23  177  struct irq_domain_ops;
> 
> :::::: The code at line 174 was first introduced by commit
> :::::: d9109698be6e7439e6082aa00d79d4556114739b genirq: Introduce msi_domain_alloc/free_irqs()
> 
> :::::: TO: Jiang Liu <jiang.liu at linux.intel.com>
> :::::: CC: Thomas Gleixner <tglx at linutronix.de>
> 
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation



-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From jamesjj.liao at mediatek.com  Mon Feb 15 01:50:57 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Mon, 15 Feb 2016 17:50:57 +0800
Subject: [PATCH v6 7/7] clk: mediatek: Enable critical clocks for MT2701
In-Reply-To: <20160211213542.26445.82983@quark.deferred.io>
References: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
 <1454665050-37776-8-git-send-email-jamesjj.liao@mediatek.com>
 <20160211213542.26445.82983@quark.deferred.io>
Message-ID: <1455529857.29688.36.camel@mtksdaap41>

Hi Mike,

On Thu, 2016-02-11 at 13:35 -0800, Michael Turquette wrote:
> Hi James,
> 
> Quoting James Liao (2016-02-05 01:37:30)
> > Some system clocks should be turned on by default on MT2701.
> > This patch enable these clocks when related clocks have
> > been registered.
> > 
> > Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
> > ---
> >  drivers/clk/mediatek/clk-mt2701.c | 23 +++++++++++++++++++++--
> >  1 file changed, 21 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/clk/mediatek/clk-mt2701.c b/drivers/clk/mediatek/clk-mt2701.c
> > index 01722e0..f7b4d52 100644
> > --- a/drivers/clk/mediatek/clk-mt2701.c
> > +++ b/drivers/clk/mediatek/clk-mt2701.c
> > @@ -573,6 +573,21 @@ static const struct mtk_gate top_clks[] __initconst = {
> >         GATE_TOP_AUD(CLK_TOP_AUD_I2S6_MCLK, "aud_i2s6_mclk", "aud_k6_src_div", 28),
> >  };
> >  
> > +static struct clk_onecell_data *top_clk_data __initdata;
> > +static struct clk_onecell_data *pll_clk_data __initdata;
> > +
> > +static void __init mtk_clk_enable_critical(void)
> > +{
> > +       if (!top_clk_data || !pll_clk_data)
> > +               return;
> > +
> > +       clk_prepare_enable(pll_clk_data->clks[CLK_APMIXED_ARMPLL]);
> > +       clk_prepare_enable(top_clk_data->clks[CLK_TOP_AXI_SEL]);
> > +       clk_prepare_enable(top_clk_data->clks[CLK_TOP_MEM_SEL]);
> > +       clk_prepare_enable(top_clk_data->clks[CLK_TOP_DDRPHYCFG_SEL]);
> > +       clk_prepare_enable(top_clk_data->clks[CLK_TOP_RTC_SEL]);
> > +}
> 
> I think we're close to having a better solution. Please see this patch
> series[0] and let me know if it provides a better way for you to enable
> these critical clocks instead of the open-coded solution.
> 
> [0] http://lkml.kernel.org/r/<1455225554-13267-1-git-send-email-mturquette at baylibre.com>
> 

I took a quick view of this patchset, CLK_ENABLE_HAND_OFF is not
suitable for these critical clocks. I'm not sure CLK_IS_CRITICAL
suitable or not. A clock with CLK_IS_CRITICAL will be prepare_enable
when it is registered. But if its parent is not registered into CCF, it
will not be enabled even the parent clock register into CCF later.

> > +
> >  static void __init mtk_topckgen_init(struct device_node *node)
> >  {
> >         struct clk_onecell_data *clk_data;
> > @@ -585,7 +600,7 @@ static void __init mtk_topckgen_init(struct device_node *node)
> >                 return;
> >         }
> >  
> > -       clk_data = mtk_alloc_clk_data(CLK_TOP_NR);
> > +       top_clk_data = clk_data = mtk_alloc_clk_data(CLK_TOP_NR);
> >  
> >         mtk_clk_register_fixed_clks(top_fixed_clks, ARRAY_SIZE(top_fixed_clks),
> >                                                                 clk_data);
> > @@ -606,6 +621,8 @@ static void __init mtk_topckgen_init(struct device_node *node)
> >         if (r)
> >                 pr_err("%s(): could not register clock provider: %d\n",
> >                         __func__, r);
> > +
> > +       mtk_clk_enable_critical();
> 
> So you call the function here, and ...
> >  }
> >  CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt2701-topckgen", mtk_topckgen_init);
> >  
> > @@ -1201,7 +1218,7 @@ static void __init mtk_apmixedsys_init(struct device_node *node)
> >         struct clk_onecell_data *clk_data;
> >         int r;
> >  
> > -       clk_data = mtk_alloc_clk_data(ARRAY_SIZE(apmixed_plls));
> > +       pll_clk_data = clk_data = mtk_alloc_clk_data(ARRAY_SIZE(apmixed_plls));
> >         if (!clk_data)
> >                 return;
> >  
> > @@ -1212,6 +1229,8 @@ static void __init mtk_apmixedsys_init(struct device_node *node)
> >         if (r)
> >                 pr_err("%s(): could not register clock provider: %d\n",
> >                         __func__, r);
> > +
> > +       mtk_clk_enable_critical();
> 
> ... here as well. So the prepare_count and enable_count will be 2? I'm
> not sure that this makes sense. If you have different clocks that need
> to be enabled at different times (due to the split registration scheme
> that you employ in this driver) then why not pass an array of those
> clocks into mtk_clk_enable_critical?

No. After topckgen and apmixedsys initialized, critical clocks'
reference count will be 1.

There is a guard at the beginning of mtk_clk_enable_critical():

	if (!top_clk_data || !pll_clk_data)
		return;

So this function will be only executed when topckgen and apmixedsys init
done.

We need to enable critical clocks:

1. As early as possible.
2. After critical clocks and their parents are registered into CCF.

We need to wait all necessary clock providers because parents of
critical clocks must be enabled at the same time. For example,
CLK_TOP_AXI_SEL may have different parent on different platforms. We
also need to keep new parent clock on if CLK_TOP_AXI_SEL change its
parent dynamically.

Because we can't ensure the init ordering of clock providers, we can
only check all necessary providers are registered or not in each init
function.

> Anyways, like I mentioned above I think we're close to a solution to
> handle this in the framework.
> 
> One question: do you ever want these critical clocks to be gated by a
> driver, or do you want them always on, forever?

In this patch, these clocks should be always on (in SW view) even if
there are other drivers controlling them.

If these is a common way to keep critical clocks and their parents on, I
would like to use the common way. But the solution in your patch series
[0] looks not handle parent clocks well. What's your suggestion to
implement critical clocks base on [0]?


Best regards,

James

> >  }
> >  CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt2701-apmixedsys",
> >                                                         mtk_apmixedsys_init);
> > -- 
> > 1.9.1
> > 




From shawn.lin at kernel-upstream.org  Mon Feb 15 01:52:08 2016
From: shawn.lin at kernel-upstream.org (Shawn Lin)
Date: Mon, 15 Feb 2016 17:52:08 +0800
Subject: [PATCH v1 3/6] rockchip: power-domain: add support for sub-power
 domains
In-Reply-To: <1455525531-14083-4-git-send-email-zhangqing@rock-chips.com>
References: <1455525531-14083-1-git-send-email-zhangqing@rock-chips.com>
 <1455525531-14083-4-git-send-email-zhangqing@rock-chips.com>
Message-ID: <56C19FC8.8030204@kernel-upstream.org>

? 2016/2/15 16:38, Elaine Zhang ??:
> This patch adds support for making one power domain a sub-domain of
> other domain. This is useful for modeling power dependences,
> which needs to have more than one power domain enabled to be operational.
>
> Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
> ---
>   drivers/soc/rockchip/pm_domains.c | 51 +++++++++++++++++++++++++++++++++++++++
>   1 file changed, 51 insertions(+)
>
> diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
> index 350527b..c4c2aea 100644
> --- a/drivers/soc/rockchip/pm_domains.c
> +++ b/drivers/soc/rockchip/pm_domains.c
> @@ -372,6 +372,51 @@ static void rockchip_configure_pd_cnt(struct rockchip_pmu *pmu,
>   	regmap_write(pmu->regmap, domain_reg_offset + 4, count);
>   }
>
> +static int rockchip_pm_add_subdomain(struct rockchip_pmu *pmu,
> +				     struct device_node *parent)
> +{
> +	struct device_node *np;
> +	int error;
> +
> +	for_each_child_of_node(parent, np) {
> +		struct generic_pm_domain *child_domain, *parent_domain;
> +		u32 idx = ~0;
> +
> +		if (of_property_read_u32(parent, "reg", &idx)) {
> +			dev_err(pmu->dev,
> +				"%s: failed to retrieve domain id (reg)\n",
> +				parent->name);
> +			return -EINVAL;

miss of_node_put.

> +		}
> +		parent_domain = pmu->genpd_data.domains[idx];
> +
> +		error = rockchip_pm_add_one_domain(pmu, np);
> +		if (error) {
> +			dev_err(pmu->dev, "failed to handle node %s: %d\n",
> +				np->name, error);
> +			return -ENODEV;

Ditto

> +		}
> +
> +		if (of_property_read_u32(np, "reg", &idx)) {
> +			dev_err(pmu->dev,
> +				"%s: failed to retrieve domain id (reg)\n",
> +				np->name);
> +			return -EINVAL;

Ditto

> +		}
> +		child_domain = pmu->genpd_data.domains[idx];
> +
> +		if (pm_genpd_add_subdomain(parent_domain, child_domain))
> +			pr_warn("%s failed to add subdomain: %s\n",
> +				parent_domain->name, child_domain->name);
> +		else
> +			pr_warn("%s add subdomain: %s\n",
> +				parent_domain->name, child_domain->name);
> +
> +		rockchip_pm_add_subdomain(pmu, np);
> +	}
> +	return 0;
> +}
> +
>   static int rockchip_pm_domain_probe(struct platform_device *pdev)
>   {
>   	struct device *dev = &pdev->dev;
> @@ -437,6 +482,12 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
>   				node->name, error);
>   			goto err_out;
>   		}
> +		error = rockchip_pm_add_subdomain(pmu, node);
> +		if (error < 0) {
> +			dev_err(dev, "failed to handle subdomain node %s: %d\n",
> +				node->name, error);
> +			goto err_out;
> +		}
>   	}
>
>   	if (error) {
>



From wens at csie.org  Mon Feb 15 01:55:49 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 17:55:49 +0800
Subject: [PATCH 10/14] ARM: dts: sun8i-a83t: Add PRCM related clocks and
 resets
In-Reply-To: <CAGb2v66L-zKYbA7h56bY3y_Jf8wOzmW_puRc+R8tQmVY6u1DZw@mail.gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-11-git-send-email-vishnupatekar0510@gmail.com>
 <CAGb2v67iO-816KaLttWRRPL2f7hpfgJ1--p69tD_oOrewmOjCA@mail.gmail.com>
 <CAEzqOZtsdHC2tCgjC=Bj5q3RFip2Uyni8bFC16u03PRLCra5KA@mail.gmail.com>
 <CAGb2v65cfG=cJ91+9G5uS5XcUh0nx6-7ZnMr7RjSGqXPHjyxpQ@mail.gmail.com>
 <CAGb2v66L-zKYbA7h56bY3y_Jf8wOzmW_puRc+R8tQmVY6u1DZw@mail.gmail.com>
Message-ID: <CAGb2v67Wz1EC4=ffZgYPXHiYenwbcbTypqaC3TcP96G1APiNog@mail.gmail.com>

On Mon, Feb 15, 2016 at 5:34 PM, Chen-Yu Tsai <wens at csie.org> wrote:
> On Sat, Feb 13, 2016 at 12:43 AM, Chen-Yu Tsai <wens at csie.org> wrote:
>> On Sat, Feb 13, 2016 at 12:06 AM, Vishnu Patekar
>> <vishnupatekar0510 at gmail.com> wrote:
>>> Hello Wens,
>>>
>>>
>>> On Tue, Feb 2, 2016 at 2:44 PM, Chen-Yu Tsai <wens at csie.org> wrote:
>>>> On Sun, Jan 31, 2016 at 9:21 AM, Vishnu Patekar
>>>> <vishnupatekar0510 at gmail.com> wrote:
>>>>> This adds A83T PRCM related clocks, clock resets.
>>>>>
>>>>> As a83t apb0 gates clock support is added earlier, this enables it.
>>>>> Apart from apb0 gates, other added clocks are compatible with
>>>>> earlier sun8i socs.
>>>>>
>>>>> Signed-off-by: Vishnu Patekar <vishnupatekar0510 at gmail.com>
>>>>> ---
>>>>>  arch/arm/boot/dts/sun8i-a83t.dtsi | 44 +++++++++++++++++++++++++++++++++++++++
>>>>>  1 file changed, 44 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
>>>>> index ac96aa1..5ea20ff 100644
>>>>> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
>>>>> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
>>>>> @@ -268,6 +268,44 @@
>>>>>                                              "mmc2_output",
>>>>>                                              "mmc2_sample";
>>>>>                 };
>>>>> +
>>>>> +               cpus_clk: clk at 01f01400 {
>>>>> +                       compatible = "allwinner,sun9i-a80-cpus-clk";
>>>>> +                       reg = <0x01f01400 0x4>;
>>>>> +                       #clock-cells = <0>;
>>>>> +                       clocks = <&osc16Md512>, <&osc24M>, <&pll6>, <&osc16M>;
>>>>> +                       clock-output-names = "cpus";
>>>>> +               };
>>>>> +
>>>>> +               ahb0: ahb0_clk {
>>>>> +                       compatible = "fixed-factor-clock";
>>>>> +                       #clock-cells = <0>;
>>>>> +                       clock-div = <1>;
>>>>> +                       clock-mult = <1>;
>>>>> +                       clocks = <&cpus_clk>;
>>>>> +                       clock-output-names = "ahb0";
>>>>> +               };
>>>>> +
>>>>> +               apb0: clk at 01f0140c {
>>>>> +                       compatible = "allwinner,sun8i-a23-apb0-clk";
>>>>
>>>> This is actually wrong, as it is wrong in sun9i-a80.dtsi.
>>>> I've sent a patch series for it.
>>> A83T apb0 is different from A80, and it's same as A23, so this should
>>> be correct.
>>> Please correct me in case I'm missing something.
>>
>> My user manual (v1.5.1) says A83T apb0 dividers (page. 246) are
>> /1, /2, /3, /4, while the A23 is /1, /2, /4, /8.
>
> As Vishnu pointed out on IRC, the A23 driver is wrong. They are in fact,
> both one-based dividers. I'll send a patch to fix this.
       ^^^
       zero-based

And for this patch,

Acked-by: Chen-Yu Tsai <wens at csie.org>

>
> ChenYu
>
>> ChenYu
>>
>>>> Also the drivers for "allwinner,sun9i-a80-cpus-clk" and
>>>> "allwinner,sun9i-a80-apbs-clk"
>>>> are only compiled for CONFIG_MACH_SUN9I. Please add a patch to address this.
>>> Okie.
>>>>
>>>> Regards
>>>> ChenYu
>>>>
>>>>> +                       reg = <0x01f0140c 0x4>;
>>>>> +                       #clock-cells = <0>;
>>>>> +                       clocks = <&ahb0>;
>>>>> +                       clock-output-names = "apb0";
>>>>> +               };
>>>>> +
>>>>> +               apb0_gates: clk at 01f01428 {
>>>>> +                       compatible = "allwinner,sun8i-a83t-apb0-gates-clk";
>>>>> +                       reg = <0x01f01428 0x4>;
>>>>> +                       #clock-cells = <1>;
>>>>> +                       clocks = <&apb0>;
>>>>> +                       clock-indices = <0>, <1>,
>>>>> +                                       <2>, <3>,
>>>>> +                                       <4>, <6>, <7>;
>>>>> +                       clock-output-names = "apb0_pio", "apb0_ir",
>>>>> +                                       "apb0_timer", "apb0_rsb",
>>>>> +                                       "apb0_uart", "apb0_i2c0", "apb0_twd";
>>>>> +               };
>>>>>         };
>>>>>
>>>>>         soc {
>>>>> @@ -434,5 +472,11 @@
>>>>>                         #interrupt-cells = <3>;
>>>>>                         interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
>>>>>                 };
>>>>> +
>>>>> +               apb0_reset: reset at 01f014b0 {
>>>>> +                       reg = <0x01f014b0 0x4>;
>>>>> +                       compatible = "allwinner,sun6i-a31-clock-reset";
>>>>> +                       #reset-cells = <1>;
>>>>> +               };
>>>>>         };
>>>>>  };
>>>>> --
>>>>> 1.9.1
>>>>>


From lee.jones at linaro.org  Mon Feb 15 01:57:33 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Mon, 15 Feb 2016 09:57:33 +0000
Subject: [GIT PULL] Immutable branch between MFD, Input and IIO
In-Reply-To: <20160211155633.GB20693@x1>
References: <1450101234-2191-1-git-send-email-mpa@pengutronix.de>
 <20160211155633.GB20693@x1>
Message-ID: <20160215095733.GE3455@x1>

Dmitry, Jonathan,

There as been an fix for one of the IIO drivers.  I'd like to fold the
fix into the patch and re-send this pull-request.  Is that okay with
you?

On Thu, 11 Feb 2016, Lee Jones wrote:

> Enjoy!
> 
> The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3:
> 
>   Linux 4.5-rc2 (2016-01-31 18:12:16 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/ib-mfd-input-iio-v4.6
> 
> for you to fetch changes up to 4f7ed234f2a5dcc26fc56a6e8324d34bbc9afe23:
> 
>   Input: touchscreen: Add imx25 TCQ driver (2016-02-11 15:40:42 +0000)
> 
> ----------------------------------------------------------------
> Immutable branch between MFD, Input and IIO due for v4.6
> 
> ----------------------------------------------------------------
> Markus Pargmann (6):
>       mfd: Add DT binding documentation for imx25 ADC/TSC
>       iio: Add binding documentation for imx25 GCQ
>       Input: add binding documentation for imx25 touchscreen controller
>       mfd: fsl-imx25-tsadc: Register touchscreen ADC driver
>       iio: adc: Add imx25-gcq ADC driver
>       Input: touchscreen: Add imx25 TCQ driver
> 
>  .../devicetree/bindings/iio/adc/fsl,imx25-gcq.txt  |  58 ++
>  .../bindings/input/touchscreen/fsl-mx25-tcq.txt    |  35 ++
>  .../devicetree/bindings/mfd/fsl-imx25-tsadc.txt    |  47 ++
>  drivers/iio/adc/Kconfig                            |   7 +
>  drivers/iio/adc/Makefile                           |   1 +
>  drivers/iio/adc/fsl-imx25-gcq.c                    | 417 ++++++++++++++
>  drivers/input/touchscreen/Kconfig                  |   9 +
>  drivers/input/touchscreen/Makefile                 |   1 +
>  drivers/input/touchscreen/fsl-imx25-tcq.c          | 596 +++++++++++++++++++++
>  drivers/mfd/Kconfig                                |   9 +
>  drivers/mfd/Makefile                               |   2 +
>  drivers/mfd/fsl-imx25-tsadc.c                      | 203 +++++++
>  include/dt-bindings/iio/adc/fsl-imx25-gcq.h        |  18 +
>  include/linux/mfd/imx25-tsadc.h                    | 140 +++++
>  14 files changed, 1543 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
>  create mode 100644 Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
>  create mode 100644 Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
>  create mode 100644 drivers/iio/adc/fsl-imx25-gcq.c
>  create mode 100644 drivers/input/touchscreen/fsl-imx25-tcq.c
>  create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
>  create mode 100644 include/dt-bindings/iio/adc/fsl-imx25-gcq.h
>  create mode 100644 include/linux/mfd/imx25-tsadc.h
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


From lkp at intel.com  Mon Feb 15 01:56:31 2016
From: lkp at intel.com (kbuild test robot)
Date: Mon, 15 Feb 2016 17:56:31 +0800
Subject: [PATCH] dma: mv_xor_v2: new driver
In-Reply-To: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <201602151740.CeSibxZc%fengguang.wu@intel.com>

Hi Thomas,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.5-rc4 next-20160215]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Thomas-Petazzoni/dma-mv_xor_v2-new-driver/20160215-160120
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: sparc64-allyesconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   In file included from include/linux/of_pci.h:5:0,
                    from drivers/of/of_pci.c:6:
>> include/linux/msi.h:203:10: error: unknown type name 'msi_alloc_info_t'
             msi_alloc_info_t *arg);
             ^
   include/linux/msi.h:207:9: error: unknown type name 'msi_alloc_info_t'
            msi_alloc_info_t *arg);
            ^
   include/linux/msi.h:216:12: error: unknown type name 'msi_alloc_info_t'
               msi_alloc_info_t *arg);
               ^
   include/linux/msi.h:217:22: error: unknown type name 'msi_alloc_info_t'
     void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
                         ^
   include/linux/msi.h:218:20: error: unknown type name 'msi_alloc_info_t'
     void  (*set_desc)(msi_alloc_info_t *arg,
                       ^
   include/linux/msi.h:286:18: error: unknown type name 'msi_alloc_info_t'
           int nvec, msi_alloc_info_t *args);
                     ^
   include/linux/msi.h:288:29: error: unknown type name 'msi_alloc_info_t'
            int virq, int nvec, msi_alloc_info_t *args);
                                ^

vim +/msi_alloc_info_t +203 include/linux/msi.h

d9109698 Jiang Liu        2014-11-15  197   * @msi_check, @msi_prepare, @msi_finish, @set_desc and @handle_error
1d1e8cdc Thomas Petazzoni 2015-12-21  198   * are callbacks used by msi_domain_alloc_irqs() and related
d9109698 Jiang Liu        2014-11-15  199   * interfaces which are based on msi_desc.
f3cf8bb0 Jiang Liu        2014-11-12  200   */
f3cf8bb0 Jiang Liu        2014-11-12  201  struct msi_domain_ops {
aeeb5965 Jiang Liu        2014-11-15  202  	irq_hw_number_t	(*get_hwirq)(struct msi_domain_info *info,
aeeb5965 Jiang Liu        2014-11-15 @203  				     msi_alloc_info_t *arg);
f3cf8bb0 Jiang Liu        2014-11-12  204  	int		(*msi_init)(struct irq_domain *domain,
f3cf8bb0 Jiang Liu        2014-11-12  205  				    struct msi_domain_info *info,
f3cf8bb0 Jiang Liu        2014-11-12  206  				    unsigned int virq, irq_hw_number_t hwirq,

:::::: The code at line 203 was first introduced by commit
:::::: aeeb59657c35da64068336c20068da237f41ab76 genirq: Provide default callbacks for msi_domain_ops

:::::: TO: Jiang Liu <jiang.liu at linux.intel.com>
:::::: CC: Thomas Gleixner <tglx at linutronix.de>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 45116 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160215/fd5e58b0/attachment-0001.obj>

From linus.walleij at linaro.org  Mon Feb 15 01:58:35 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 15 Feb 2016 10:58:35 +0100
Subject: [PATCH v2] mfd: ab8500: Provide a small example using new MFD
 cell MACROs
In-Reply-To: <20160210153938.GC26950@x1>
References: <1455028027-1527-1-git-send-email-lee.jones@linaro.org>
 <20160210153938.GC26950@x1>
Message-ID: <CACRpkdbLPpTsWa=Wc145cxg4LBOg=R2zKjbWLqHFr_UzVPnwbQ@mail.gmail.com>

On Wed, Feb 10, 2016 at 4:39 PM, Lee Jones <lee.jones at linaro.org> wrote:

> mfd: ab8500: Provide a small example using new MFD cell MACROs
>
> Signed-off-by: Lee Jones <lee.jones at linaro.org>

Oh, that's pretty.
Acked-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From mpa at pengutronix.de  Mon Feb 15 01:59:05 2016
From: mpa at pengutronix.de (Markus Pargmann)
Date: Mon, 15 Feb 2016 10:59:05 +0100
Subject: [PATCH] iio: adc/imx25-gcq: move incorrect do_div
In-Reply-To: <1455275748-999115-1-git-send-email-arnd@arndb.de>
References: <1455275748-999115-1-git-send-email-arnd@arndb.de>
Message-ID: <2144249.hzmN2uUoLT@adelgunde>

Hi,

On Friday, February 12, 2016 12:15:29 PM Arnd Bergmann wrote:
> The newly added driver uses do_div() to device a 32-bit number, which now
> provokes a warning:
> 
> drivers/iio/adc/fsl-imx25-gcq.c: In function 'mx25_gcq_setup_cfgs':
> include/asm-generic/div64.h:207:28: warning: comparison of distinct pointer types lacks a cast
>   (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> 
> This replaces the do_div() call with a straight division operator.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 6df2e98c3ea5 ("iio: adc: Add imx25-gcq ADC driver")

Thanks for fixing this.

Reviewed-by: Markus Pargmann <mpa at pengutronix.de>

Best Regards,

Markus

> ---
>  drivers/iio/adc/fsl-imx25-gcq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/fsl-imx25-gcq.c b/drivers/iio/adc/fsl-imx25-gcq.c
> index 2fd192735d5b..72b32c1ab257 100644
> --- a/drivers/iio/adc/fsl-imx25-gcq.c
> +++ b/drivers/iio/adc/fsl-imx25-gcq.c
> @@ -233,7 +233,7 @@ static int mx25_gcq_setup_cfgs(struct platform_device *pdev,
>  			priv->channel_vref_mv[reg] =
>  				regulator_get_voltage(priv->vref[refp]);
>  			/* Conversion from uV to mV */
> -			do_div(priv->channel_vref_mv[reg], 1000);
> +			priv->channel_vref_mv[reg] /= 1000;
>  			break;
>  		case MX25_ADC_REFP_INT:
>  			priv->channel_vref_mv[reg] = 2500;
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160215/834da2a4/attachment.sig>

From marc.zyngier at arm.com  Mon Feb 15 01:59:27 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Feb 2016 09:59:27 +0000
Subject: [PATCH] dma: mv_xor_v2: new driver
In-Reply-To: <20160215105008.74aa7869@free-electrons.com>
References: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <201602151735.BaFwBMOn%fengguang.wu@intel.com>
 <20160215105008.74aa7869@free-electrons.com>
Message-ID: <56C1A17F.9030206@arm.com>

Hi Thomas,

On 15/02/16 09:50, Thomas Petazzoni wrote:
> Marc,
> 
> This doesn't seem to be an issue introduced by my patch itself, but
> rather a problem with the MSI subsystem itself. Is this already a known
> issue (possibly already fixed), or should I investigate?

Seems like something is selecting GENERIC_MSI_IRQ_DOMAIN on a system
that doesn't implement the required bits.

It may be that we need to implement something like
HAS_GENERIC_MSI_IRQ_DOMAIN, and make GENERIC_MSI_IRQ_DOMAIN conditional
on that. Or just whitelist the architectures that do implement this.

Any chance you could have a closer look?

Thanks,

	M.

> 
> Thanks!
> 
> Thomas
> 
> On Mon, 15 Feb 2016 17:09:27 +0800, kbuild test robot wrote:
>> Hi Thomas,
>>
>> [auto build test ERROR on robh/for-next]
>> [also build test ERROR on v4.5-rc4 next-20160215]
>> [if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
>>
>> url:    https://github.com/0day-ci/linux/commits/Thomas-Petazzoni/dma-mv_xor_v2-new-driver/20160215-160120
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
>> config: openrisc-allyesconfig (attached as .config)
>> reproduce:
>>         wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>>         chmod +x ~/bin/make.cross
>>         # save the attached .config to linux build tree
>>         make.cross ARCH=openrisc 
>>
>> All errors (new ones prefixed by >>):
>>
>>    In file included from kernel/irq/chip.c:14:0:
>>>> include/linux/msi.h:174:21: fatal error: asm/msi.h: No such file or directory
>>    compilation terminated.
>>
>> vim +174 include/linux/msi.h
>>
>> c2791b80 Yijing Wang    2014-11-11  168  	void (*teardown_irq)(struct msi_controller *chip, unsigned int irq);
>> 0cbdcfcf Thierry Reding 2013-08-09  169  };
>> 0cbdcfcf Thierry Reding 2013-08-09  170  
>> f3cf8bb0 Jiang Liu      2014-11-12  171  #ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
>> d9109698 Jiang Liu      2014-11-15  172  
>> aeeb5965 Jiang Liu      2014-11-15  173  #include <linux/irqhandler.h>
>> d9109698 Jiang Liu      2014-11-15 @174  #include <asm/msi.h>
>> d9109698 Jiang Liu      2014-11-15  175  
>> f3cf8bb0 Jiang Liu      2014-11-12  176  struct irq_domain;
>> 552c494a Marc Zyngier   2015-11-23  177  struct irq_domain_ops;
>>
>> :::::: The code at line 174 was first introduced by commit
>> :::::: d9109698be6e7439e6082aa00d79d4556114739b genirq: Introduce msi_domain_alloc/free_irqs()
>>
>> :::::: TO: Jiang Liu <jiang.liu at linux.intel.com>
>> :::::: CC: Thomas Gleixner <tglx at linutronix.de>
>>
>> ---
>> 0-DAY kernel test infrastructure                Open Source Technology Center
>> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
> 
> 
> 


-- 
Jazz is not dead. It just smells funny...


From sudeep.holla at arm.com  Mon Feb 15 02:01:34 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon, 15 Feb 2016 10:01:34 +0000
Subject: [PATCH 0/3] OMAP/pinmux: remove misuse of IRQF_NO_SUSPEND flag
In-Reply-To: <CACRpkdYzJ9Hy0sH6gK6RzpLE6juS4WfPjbt7nh43vR9YTuGZWA@mail.gmail.com>
References: <1454351299-27440-1-git-send-email-sudeep.holla@arm.com>
 <CACRpkdYzJ9Hy0sH6gK6RzpLE6juS4WfPjbt7nh43vR9YTuGZWA@mail.gmail.com>
Message-ID: <56C1A1FE.3080403@arm.com>

Hi Linus,

On 13/02/16 14:42, Linus Walleij wrote:
> On Mon, Feb 1, 2016 at 7:28 PM, Sudeep Holla <sudeep.holla at arm.com> wrote:
>
>>    pinctrl: single: Use a separate lockdep class
>>    pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag
>>    ARM: OMAP2+: remove misuse of IRQF_NO_SUSPEND flag
>>
>>   arch/arm/mach-omap2/mux.c        |  4 ++--
>>   arch/arm/mach-omap2/pm34xx.c     |  9 ++++-----
>>   arch/arm/mach-omap2/prm_common.c |  1 +
>>   drivers/pinctrl/pinctrl-single.c | 15 ++++++++++++---
>
> Are these patches orthogonal so I can merge the pinctrl patch independently
> of the OMAP patches if Tony ACKs this?
>

Thanks for the follow up.
IIUC they are dependent and remember Tony/Grygorii wanted them to be
merged together(at-least for bisectibility)

> If not: should it be merged by me or through ARM SoC/Tony?
>

I think so.

> Anyways waiting for maintainer feedback, but the above is good to know.
>

Grygorii was still not sure if this works and he couldn't give it a
test. He was traveling and may need more time to get back on this.

-- 
Regards,
Sudeep


From linux at arm.linux.org.uk  Mon Feb 15 02:04:15 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Feb 2016 10:04:15 +0000
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160215091406.GE12289@pengutronix.de>
References: <20160214165010.GA3189@roeck-us.net>
 <20160214195501.GA12289@pengutronix.de>
 <20160214200755.GB10826@n2100.arm.linux.org.uk>
 <20160215081750.GD12289@pengutronix.de>
 <20160215085818.GC10826@n2100.arm.linux.org.uk>
 <20160215091406.GE12289@pengutronix.de>
Message-ID: <20160215100415.GD10826@n2100.arm.linux.org.uk>

On Mon, Feb 15, 2016 at 10:14:06AM +0100, Uwe Kleine-K?nig wrote:
> Hello Russell,
> 
> On Mon, Feb 15, 2016 at 08:58:18AM +0000, Russell King - ARM Linux wrote:
> > On Mon, Feb 15, 2016 at 09:17:50AM +0100, Uwe Kleine-K?nig wrote:
> > > On Sun, Feb 14, 2016 at 08:07:55PM +0000, Russell King - ARM Linux wrote:
> > > > On Sun, Feb 14, 2016 at 08:55:01PM +0100, Uwe Kleine-K?nig wrote:
> > > > > So the unexpected abnormality here is that even though this device is
> > > > > instantiated by dt, the driver doesn't provide any compatibles.
> > > > > Either my expectation is wrong, then 67d02a1bbb33455 should be reverted
> > > > 
> > > > Your expectation is wrong.  AMBA primecell devices have hardware IDs
> > > > and are matched to their drivers by those IDs.  Just like PCI.
> > > 
> > > pci devices don't appear in dt, do they? I don't see the connection
> > > between amba devices and platform devices, see my other mail in this
> > > thread for some more details.
> > 
> > They both have hardware IDs, and they are both matched via those hardware
> > IDs.
> 
> I changed platform_match which is about matching by dt compatible, acpi
> and/or device name. I don't see how this can affect an amba device given
> they match to a driver by a hardware id.
> 
> > Your change has introduced a regression and is therefore wrong.
> 
> I'd like to understand though why and how my commit is wrong to be able
> to fix it instead of getting it reverted.

I don't have the commit, and I haven't seen the patch so I can't
comment further, sorry.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From catalin.marinas at arm.com  Mon Feb 15 02:03:19 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 15 Feb 2016 10:03:19 +0000
Subject: [PATCH RESEND] arm64: add alignment fault hanling
In-Reply-To: <2039801453.916991455526707908.JavaMail.weblogic@epmlwas09b>
References: <2039801453.916991455526707908.JavaMail.weblogic@epmlwas09b>
Message-ID: <20160215100319.GA13683@e104818-lin.cambridge.arm.com>

On Mon, Feb 15, 2016 at 08:58:32AM +0000, EunTaik Lee wrote:
> Userspace memory is mapped as below:
> F2A7F000--F2A7FFFF Normal Memory
> F2A80000--F2A80FFF Device nGnRnE

How do you end up with Device nGnRnE in user space? I thought we should
have got some guard page.

> And that userspace application makes a system call
> as below:
> 
> -009 |do_strncpy_from_user(inline)
> -009 |strncpy_from_user()
> -010 |getname_flags()
> -011 |user_path_at_empty()
> -012 |user_path_at()
> -013 |SYSC_faccessat(inline)
> -013 |sys_faccessat()
> -014 |__sys_trace(asm)
> --> |exception
> 
> The string spans from 0xF2A7FFC1 to 0xF2A7FFFB.
> 
> When do_strncpy_from_user() reads the last (unsigned long)
> value, the alignement fault is triggered. The 8 byte
> from 0xF2A7FFC1 spans to the next page that is mapped as
> Device nGnRnE, which does not allow an unaligned access,
> causes the abort.

do_strncpy_from_user() relies on unsafe_get_user() not being able to
read 8 bytes. The problem now is that it doesn't get a page fault but an
alignment one is isn't handled.

> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 19211c4..8257d4f 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -371,6 +371,16 @@ static int __kprobes do_translation_fault(unsigned long addr,
> return 0;
> }
> 
> +static int __kprobes do_alignment_fault(unsigned long addr,
> +   unsigned int esr,
> +   struct pt_regs *regs)
> +{
> + if (addr >= TASK_SIZE && fixup_exception(regs))
> + return 0;
> +
> + return 1;
> +}

Why addr >= TASK_SIZE? addr here should be the fault address, not pc.

> +
> /*
>   * This abort handler always returns "fault".
>   */
> @@ -418,7 +428,7 @@ static struct fault_info {
> { do_bad, SIGBUS,  0, "synchronous parity error (translation table walk" },
> { do_bad, SIGBUS,  0, "synchronous parity error (translation table walk" },
> { do_bad, SIGBUS,  0, "unknown 32" },
> - { do_bad, SIGBUS,  BUS_ADRALN, "alignment fault" },
> + { do_alignment_fault, SIGBUS,  BUS_ADRALN, "alignment fault" },

The simplest would be to use do_bad_area() here without any additional
function.

-- 
Catalin


From hverkuil at xs4all.nl  Mon Feb 15 02:07:41 2016
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Mon, 15 Feb 2016 11:07:41 +0100
Subject: [PATCH v4 2/8] [media] VPU: mediatek: support Mediatek VPU
In-Reply-To: <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <56C1A36D.6010908@xs4all.nl>

Hi Tiffany,

A small review comment below:

On 02/04/2016 12:34 PM, Tiffany Lin wrote:
> The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
> It is able to handle video decoding/encoding of in a range of formats.
> The driver provides with VPU firmware download, memory management and
> the communication interface between CPU and VPU.
> For VPU initialization, it will create virtual memory for CPU access and
> IOMMU address for vcodec hw device access. When a decode/encode instance
> opens a device node, vpu driver will download vpu firmware to the device.
> A decode/encode instant will decode/encode a frame using VPU
> interface to interrupt vpu to handle decoding/encoding jobs.
> 
> Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
> Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
> ---
>  drivers/media/platform/Kconfig           |    9 +
>  drivers/media/platform/Makefile          |    2 +
>  drivers/media/platform/mtk-vpu/Makefile  |    1 +
>  drivers/media/platform/mtk-vpu/mtk_vpu.c |  994 ++++++++++++++++++++++++++++++
>  drivers/media/platform/mtk-vpu/mtk_vpu.h |  167 +++++
>  5 files changed, 1173 insertions(+)
>  create mode 100644 drivers/media/platform/mtk-vpu/Makefile
>  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c
>  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h
> 

<snip>

> diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> new file mode 100644
> index 0000000..f54fd89
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> @@ -0,0 +1,994 @@

<snip>

> +static ssize_t vpu_debug_read(struct file *file, char __user *user_buf,
> +			      size_t count, loff_t *ppos)
> +{
> +	char buf[256];
> +	unsigned int len;
> +	unsigned int running, pc, vpu_to_host, host_to_vpu, wdt;
> +	int ret;
> +	struct device *dev = file->private_data;
> +	struct mtk_vpu *vpu = dev_get_drvdata(dev);
> +
> +	ret = vpu_clock_enable(vpu);
> +	if (ret) {
> +		dev_err(vpu->dev, "[VPU] enable clock failed %d\n", ret);
> +		return 0;
> +	}
> +
> +	/* vpu register status */
> +	running = vpu_running(vpu);
> +	pc = vpu_cfg_readl(vpu, VPU_PC_REG);
> +	wdt = vpu_cfg_readl(vpu, VPU_WDT_REG);
> +	host_to_vpu = vpu_cfg_readl(vpu, HOST_TO_VPU);
> +	vpu_to_host = vpu_cfg_readl(vpu, VPU_TO_HOST);
> +	vpu_clock_disable(vpu);
> +
> +	if (running) {
> +		len = sprintf(buf, "VPU is running\n\n"

Please use snprintf.

> +		"FW Version: %s\n"
> +		"PC: 0x%x\n"
> +		"WDT: 0x%x\n"
> +		"Host to VPU: 0x%x\n"
> +		"VPU to Host: 0x%x\n",
> +		vpu->run.fw_ver, pc, wdt,
> +		host_to_vpu, vpu_to_host);
> +	} else {
> +		len = sprintf(buf, "VPU not running\n");

Ditto.

sprintf always makes me feel uncomfortable :-)

> +	}
> +
> +	return simple_read_from_buffer(user_buf, count, ppos, buf, len);
> +}

Regards,

	Hans



From catalin.marinas at arm.com  Mon Feb 15 02:09:06 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 15 Feb 2016 10:09:06 +0000
Subject: [PATCH] arm64: mm: dump: Use VA_START directly instead of
 private LOWEST_ADDR
In-Reply-To: <56C0416E.6050908@huawei.com>
References: <1454140521-741-1-git-send-email-wangkefeng.wang@huawei.com>
 <20160201102345.GB674@leverpostej> <56C0416E.6050908@huawei.com>
Message-ID: <20160215100906.GB13683@e104818-lin.cambridge.arm.com>

On Sun, Feb 14, 2016 at 04:57:18PM +0800, Kefeng Wang wrote:
> On 2016/2/1 18:23, Mark Rutland wrote:
> > On Sat, Jan 30, 2016 at 03:55:21PM +0800, Kefeng Wang wrote:
> >> Use VA_START macro in asm/memory.h instead of private LOWEST_ADDR
> >> definition in dump.c.
> >>
> >> Signed-off-by: Kefeng Wang <wangkefeng.wang at huawei.com>

I'll merge this patch for 4.6 but we currently have some issues with the
arm64 for-next/core branch, so I'm not pushing any more patches out
until we figure out what's going on (or I may just start with a clean
branch again, removing some big changes in there).

-- 
Catalin


From u.kleine-koenig at pengutronix.de  Mon Feb 15 02:10:14 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Mon, 15 Feb 2016 11:10:14 +0100
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160215100415.GD10826@n2100.arm.linux.org.uk>
References: <20160214165010.GA3189@roeck-us.net>
 <20160214195501.GA12289@pengutronix.de>
 <20160214200755.GB10826@n2100.arm.linux.org.uk>
 <20160215081750.GD12289@pengutronix.de>
 <20160215085818.GC10826@n2100.arm.linux.org.uk>
 <20160215091406.GE12289@pengutronix.de>
 <20160215100415.GD10826@n2100.arm.linux.org.uk>
Message-ID: <20160215101014.GG12289@pengutronix.de>

Hello Russell,

On Mon, Feb 15, 2016 at 10:04:15AM +0000, Russell King - ARM Linux wrote:
> On Mon, Feb 15, 2016 at 10:14:06AM +0100, Uwe Kleine-K?nig wrote:
> > On Mon, Feb 15, 2016 at 08:58:18AM +0000, Russell King - ARM Linux wrote:
> > > On Mon, Feb 15, 2016 at 09:17:50AM +0100, Uwe Kleine-K?nig wrote:
> > > > On Sun, Feb 14, 2016 at 08:07:55PM +0000, Russell King - ARM Linux wrote:
> > > > > On Sun, Feb 14, 2016 at 08:55:01PM +0100, Uwe Kleine-K?nig wrote:
> > > > > > So the unexpected abnormality here is that even though this device is
> > > > > > instantiated by dt, the driver doesn't provide any compatibles.
> > > > > > Either my expectation is wrong, then 67d02a1bbb33455 should be reverted
> > > > > 
> > > > > Your expectation is wrong.  AMBA primecell devices have hardware IDs
> > > > > and are matched to their drivers by those IDs.  Just like PCI.
> > > > 
> > > > pci devices don't appear in dt, do they? I don't see the connection
> > > > between amba devices and platform devices, see my other mail in this
> > > > thread for some more details.
> > > 
> > > They both have hardware IDs, and they are both matched via those hardware
> > > IDs.
> > 
> > I changed platform_match which is about matching by dt compatible, acpi
> > and/or device name. I don't see how this can affect an amba device given
> > they match to a driver by a hardware id.
> > 
> > > Your change has introduced a regression and is therefore wrong.
> > 
> > I'd like to understand though why and how my commit is wrong to be able
> > to fix it instead of getting it reverted.
> 
> I don't have the commit, and I haven't seen the patch so I can't
> comment further, sorry.

It's in -next. For a quick look:

	https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=67d02a1bbb33455

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From hverkuil at xs4all.nl  Mon Feb 15 02:13:26 2016
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Mon, 15 Feb 2016 11:13:26 +0100
Subject: [PATCH v4 2/8] [media] VPU: mediatek: support Mediatek VPU
In-Reply-To: <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <56C1A4C6.7040601@xs4all.nl>

On 02/04/2016 12:34 PM, Tiffany Lin wrote:
> The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
> It is able to handle video decoding/encoding of in a range of formats.
> The driver provides with VPU firmware download, memory management and
> the communication interface between CPU and VPU.
> For VPU initialization, it will create virtual memory for CPU access and
> IOMMU address for vcodec hw device access. When a decode/encode instance
> opens a device node, vpu driver will download vpu firmware to the device.
> A decode/encode instant will decode/encode a frame using VPU
> interface to interrupt vpu to handle decoding/encoding jobs.
> 
> Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
> Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
> ---
>  drivers/media/platform/Kconfig           |    9 +
>  drivers/media/platform/Makefile          |    2 +
>  drivers/media/platform/mtk-vpu/Makefile  |    1 +
>  drivers/media/platform/mtk-vpu/mtk_vpu.c |  994 ++++++++++++++++++++++++++++++
>  drivers/media/platform/mtk-vpu/mtk_vpu.h |  167 +++++
>  5 files changed, 1173 insertions(+)
>  create mode 100644 drivers/media/platform/mtk-vpu/Makefile
>  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c
>  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index ccbc974..ba812d6 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -148,6 +148,15 @@ config VIDEO_CODA
>  	   Coda is a range of video codec IPs that supports
>  	   H.264, MPEG-4, and other video formats.
>  
> +config VIDEO_MEDIATEK_VPU
> +	tristate "Mediatek Video Processor Unit"
> +	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MEDIATEK
> +	---help---
> +	    This driver provides downloading VPU firmware and
> +	    communicating with VPU. This driver for hw video
> +	    codec embedded in new Mediatek's SOCs. It is able
> +	    to handle video decoding/encoding in a range of formats.

Can you be more specific in this text and mention for which Mediatek SoCs
this driver is for? Just like you did in the commit log.

Also add something like this:

          To compile this driver as a module, choose M here: the module
          will be called mtk-vpu.

I always find it useful if the Kconfig text mentions the module name.

Regards,

	Hans

> +
>  config VIDEO_MEM2MEM_DEINTERLACE
>  	tristate "Deinterlace support"
>  	depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE



From will.deacon at arm.com  Mon Feb 15 02:12:35 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Feb 2016 10:12:35 +0000
Subject: [PATCH 4/4] arm64: cputype info for Broadcom Vulcan
In-Reply-To: <1455389195-31870-5-git-send-email-jchandra@broadcom.com>
References: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
 <1455389195-31870-5-git-send-email-jchandra@broadcom.com>
Message-ID: <20160215101235.GA1748@arm.com>

On Sun, Feb 14, 2016 at 12:16:35AM +0530, Jayachandran C wrote:
> Add Broadcom Vulcan implementor ID and part ID in cputype.h. This is
> to document the values.
> 
> Signed-off-by: Jayachandran C <jchandra at broadcom.com>
> ---
>  arch/arm64/include/asm/cputype.h | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Will Deacon <will.deacon at arm.com>

> diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
> index 1a59493..3725d59 100644
> --- a/arch/arm64/include/asm/cputype.h
> +++ b/arch/arm64/include/asm/cputype.h
> @@ -65,6 +65,7 @@
>  #define ARM_CPU_IMP_ARM			0x41
>  #define ARM_CPU_IMP_APM			0x50
>  #define ARM_CPU_IMP_CAVIUM		0x43
> +#define ARM_CPU_IMP_BRCM		0x42
>  
>  #define ARM_CPU_PART_AEM_V8		0xD0F
>  #define ARM_CPU_PART_FOUNDATION		0xD00
> @@ -74,6 +75,7 @@
>  #define APM_CPU_PART_POTENZA		0x000
>  
>  #define CAVIUM_CPU_PART_THUNDERX	0x0A1
> +#define BRCM_CPU_PART_VULCAN		0x516
>  
>  #ifndef __ASSEMBLY__
>  
> -- 
> 1.9.1
> 


From linux at arm.linux.org.uk  Mon Feb 15 02:13:50 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Feb 2016 10:13:50 +0000
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160215101014.GG12289@pengutronix.de>
References: <20160214165010.GA3189@roeck-us.net>
 <20160214195501.GA12289@pengutronix.de>
 <20160214200755.GB10826@n2100.arm.linux.org.uk>
 <20160215081750.GD12289@pengutronix.de>
 <20160215085818.GC10826@n2100.arm.linux.org.uk>
 <20160215091406.GE12289@pengutronix.de>
 <20160215100415.GD10826@n2100.arm.linux.org.uk>
 <20160215101014.GG12289@pengutronix.de>
Message-ID: <20160215101350.GE10826@n2100.arm.linux.org.uk>

On Mon, Feb 15, 2016 at 11:10:14AM +0100, Uwe Kleine-K?nig wrote:
> Hello Russell,
> 
> On Mon, Feb 15, 2016 at 10:04:15AM +0000, Russell King - ARM Linux wrote:
> > On Mon, Feb 15, 2016 at 10:14:06AM +0100, Uwe Kleine-K?nig wrote:
> > > On Mon, Feb 15, 2016 at 08:58:18AM +0000, Russell King - ARM Linux wrote:
> > > > On Mon, Feb 15, 2016 at 09:17:50AM +0100, Uwe Kleine-K?nig wrote:
> > > > > On Sun, Feb 14, 2016 at 08:07:55PM +0000, Russell King - ARM Linux wrote:
> > > > > > On Sun, Feb 14, 2016 at 08:55:01PM +0100, Uwe Kleine-K?nig wrote:
> > > > > > > So the unexpected abnormality here is that even though this device is
> > > > > > > instantiated by dt, the driver doesn't provide any compatibles.
> > > > > > > Either my expectation is wrong, then 67d02a1bbb33455 should be reverted
> > > > > > 
> > > > > > Your expectation is wrong.  AMBA primecell devices have hardware IDs
> > > > > > and are matched to their drivers by those IDs.  Just like PCI.
> > > > > 
> > > > > pci devices don't appear in dt, do they? I don't see the connection
> > > > > between amba devices and platform devices, see my other mail in this
> > > > > thread for some more details.
> > > > 
> > > > They both have hardware IDs, and they are both matched via those hardware
> > > > IDs.
> > > 
> > > I changed platform_match which is about matching by dt compatible, acpi
> > > and/or device name. I don't see how this can affect an amba device given
> > > they match to a driver by a hardware id.
> > > 
> > > > Your change has introduced a regression and is therefore wrong.
> > > 
> > > I'd like to understand though why and how my commit is wrong to be able
> > > to fix it instead of getting it reverted.
> > 
> > I don't have the commit, and I haven't seen the patch so I can't
> > comment further, sorry.
> 
> It's in -next. For a quick look:
> 
> 	https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=67d02a1bbb33455

Well, if that's only touching the platform device matching, it can't have
any effect on AMBA bus matching, which uses completely different code.
The AMBA bus code is entirely separate from platform devices.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From geert at linux-m68k.org  Mon Feb 15 02:15:16 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 11:15:16 +0100
Subject: [PATCH v2 0/6] ARM/arm64 : shmobile/renesas: Add L2
 cache-controller nodes
In-Reply-To: <20160215015848.GD14034@verge.net.au>
References: <1449512659-16688-1-git-send-email-geert+renesas@glider.be>
 <20160215015848.GD14034@verge.net.au>
Message-ID: <CAMuHMdVRTJ9nXFNQSz+WGSuUGWho3x08WMNZwPS=B-Q8sdzd4w@mail.gmail.com>

Hi Simon,

On Mon, Feb 15, 2016 at 2:58 AM, Simon Horman <horms at verge.net.au> wrote:
> On Mon, Dec 07, 2015 at 07:24:13PM +0100, Geert Uytterhoeven wrote:
>> This patch series adds the missing L2 cache-controller nodes to the
>> DTSes for various Renesas ARM-based SoCs, and links the CPU nodes to
>> them.
>>
>> For R-Mobile APE6 (r8a73a4), the L2 cache-controllers are also linked to
>> the respective (already existing) SYSC Power Domains. Fortunately these
>> Power Domains were never powered down, as they are parents of the Power
>> Domains containing CPU cores. This may change in the future.
>>
>> For R-Car Gen2 and Gen3 (r8a779x), this serves as a preparatory step for
>> adding SYSC Power Domain support later.
>>
>> Question for the ARM/DT people: What are the DT bindings for
>> Cortex-A15/A7/A57/A53 L2 cache controllers?
>> Everybody just seems to use "cache" for the compatible values...
>>
>> Patches 2-5 were extracted from series "[PATCH/RFC 00/15]
>> ARM: shmobile: R-Car: Add SYSC PM Domain DT Support",
>> (http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348742.html)
>> and received some fixes. You can find more detailed changelogs in the
>> individual patches).
>>
>> This has been tested on r8a73a4/ape6evm, r8a7791/koelsch, and
>> r8a7795/salvator-x.
>
> Sorry for loosing track of this until now.
>
> It seems to me that the Gen-2 changes could be applied, is that correct?

And APE6 :-)

> It also seems to me that there was inconclusive discussion regarding
> the r8a7795 change, is that also correct.

There was discussion (for all SoCs) about the presence of the arm,data-latency
and arm,tag-latency properties. Given the mess^H^H^H^H presence or
absence of virtualization they may or may not be valid...

I think the way forward (keeping the dependency for SYSC PM Domains in mind) is
to apply the series, after removing the controversial latency properties.

Should I resend, or can/will you handle that?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From andre.przywara at arm.com  Mon Feb 15 02:16:48 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 15 Feb 2016 10:16:48 +0000
Subject: (Still) breaking DT compatibility (was: [RFC PATCH 0/4] clk: sunxi:
 fix DT compatibility issues)
In-Reply-To: <56BE29A1.3060107@redhat.com>
References: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
 <56BE29A1.3060107@redhat.com>
Message-ID: <56C1A590.6030500@arm.com>

On 12/02/16 18:51, Hans de Goede wrote:
> Hi,
> 
> So far I've stayed out of this discussion, but now I feel I have to
> weigh in:
> 
> There is no need for this series, device-tree compatibility for
> sunxi devices is a non issue. No devices ship with dtb files as
> part of the bootloader / firmware (the vendor kernels do not
> use dtb at all).

I think you are barking in the wrong thread here.
I deliberately sent some code to bring this discussion back to a more
technical level.

But anyway...

> So we always are using a dtb from the kernel tree, and both Fedora
> and Debian (AFAIK), the 2 distros which ship with more or less official
> sunxi support package things

Actually I am trying to help that it doesn't need to stay this way. I
don't see a real reason why a distribution should support a particular
platform, they certainly don't for x86, for instance.
I think a stable DT would help to overcome this limited support that we
see here and would allow distributions to not need to care about sunxi
in particular.

There should be one good DT for all kernels - it may be updated
(especially if new features get supported), but should never break.
Also please note that the DT is not only for Linux, BSDs for instance
use it too - for instance FreeBSD on ARM64.

> so that each kernel version uses the dtb
> files compiled from the dts shipped with that exact kernel version,
> (through the ftddir directive in extlinux.conf, which is per menu
> entry / kernel version) even if multiple kernel versions are installed.

That there are technical ways to mitigate the problem doesn't count as
an excuse to break DT.

To make this clear: The original PLL6 clock _binding_ is actually fine:
it describes the clock as per the manual with two clock outputs.
It's just the driver that is ignoring the clock-output-names that causes
the issue.
So we can happily keep the binding, fix the driver and re-use that very
binding for PLL8, as well.
This fix series here was the easiest approach in terms of changed code.
I can make some patches that implement the proper solution - if you
promise to not shoot down 0/x again easily.

I see that good DT bindings are not easy to come up with. Yes, we are
not perfect and especially for sunxi with it's bad original
documentation we won't create perfect DTs from the beginning.
But I think we should at least _try_ to make a DT what's is meant:
describing the hardware, part of the firmware and OS agnostic - which
implies compatibility.

> So there is no reason, no reason at all to worry too much about dtb
> compatibility for sunxi devices.

I think this argument has been discussed quite a bit in the
other thread.
What I am really worried about is that this now creeps into the arm64 world.
Yes, I see your point that it was a no-brainer so far, but that doesn't
mean that it has to stay this way. For the A64 for instance there are
more devices with eMMC in the pipe (Remix Mini PC and the Olimex board),
so we can just put our firmware bits and the boot loader on there and
distributions don't need to ship those.

> As for compatibility with u-boot, u-boot ships with its own embedded
> dtb copy, which is based on dts files from the kernel (the u-boot copies
> get synced regularly), and even if this dtb were to somehow be replaced
> by a new "incompatible" dtb from a newer kernel there would still not
> be a problem as u-boot does not (currently) use the clk definitions
> from the dtb. Note I'm the u-boot sunxi custodian and I'm fine with
> the proposed changes.
> 
> TL;DR: NACK for this series.

Seriously?

I would prefer if you would save your NACKs for patches that break
something instead.

If you are concerned that this fix is too involved, that's mostly due to
the reason that I couldn't revert the original patch easily due to
conflicts in subsequent patches, so I did a bit more for the rollback.
The actual core fix is pretty easy.

So I hope we can come to a conclusion about this one before I prepare
the next set of patches.

Cheers,
Andre.

> 
> On 12-02-16 18:59, Andre Przywara wrote:
>> Commit f7d372ba54ea ("clk: sunxi: Refactor A31 PLL6 so that it can be
>> reused") (in -next) made the A31 PLL6 clock driver more generic, so
>> that it can drive the PLL8 clock in newer SoCs too.
>> However the patch broke compatibility with older DTs, which this
>> series tries to fix.
>> The approach chosen here is to bring back the old driver under its
>> old name, while letting the new driver using a different name to be
>> able to tell them apart.
>> The old driver should be somewhat deprecated and not used in new DTs
>> anymore.
>> The slight disadvantage is that there are now two drivers and two
>> compatible names for the same hardware (the PLL6 clock), I am not
>> sure if this is frowned upon or can be tolerated since the new driver
>> is more generic (drives PLL8 as well) and makes the old one obsolete.
>> We just need to keep it for compatibility.
>>
>> The naming for both the functions and compatible names is probably
>> wrong, I am relying on more sunxi - experienced people here to
>> suggest better identifiers.
>>
>> This is only one possible approach to fix this issues, so I am open
>> to any kind of discussion.
>>
>> The series is made on top of Maxime's sunxi/for-next branch, so it
>> somehow reverts the change in question. I am happy to rebase it on
>> any branch people tell me.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>>
>> Andre Przywara (4):
>>    clk: sunxi: rename new sun6i_a31_pll6 clock to sun6i_a31_pll clock
>>    clk: sunxi: re-add old sun6i_a31_pll6 clock
>>    clk: sunxi: revert .dtsi changes for DTs with a sun6i_a31_pll6 clock
>>    DT: Allwinner H3: fix PLL8 clock
>>
>>   Documentation/devicetree/bindings/clock/sunxi.txt |  2 +-
>>   arch/arm/boot/dts/sun6i-a31.dtsi                  | 36
>> ++++++++---------
>>   arch/arm/boot/dts/sun8i-a23-a33.dtsi              | 25 ++++--------
>>   arch/arm/boot/dts/sun8i-a23.dtsi                  |  2 +-
>>   arch/arm/boot/dts/sun8i-a33.dtsi                  |  4 +-
>>   arch/arm/boot/dts/sun8i-h3.dtsi                   | 31 +++++---------
>>   drivers/clk/sunxi/clk-sunxi.c                     | 49
>> ++++++++++++++++++++---
>>   7 files changed, 84 insertions(+), 65 deletions(-)
>>
> 



From catalin.marinas at arm.com  Mon Feb 15 02:22:30 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 15 Feb 2016 10:22:30 +0000
Subject: [PATCH v4 21/23] arm64: hw_breakpoint: Allow EL2 breakpoints if
 running in HYP
In-Reply-To: <1455216004-19499-22-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
 <1455216004-19499-22-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160215102230.GC13683@e104818-lin.cambridge.arm.com>

On Thu, Feb 11, 2016 at 06:40:02PM +0000, Marc Zyngier wrote:
> With VHE, we place kernel {watch,break}-points at EL2 to get things
> like kgdb and "perf -e mem:..." working.
> 
> This requires a bit of repainting in the low-level encore/decode,
> but is otherwise pretty simple.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

To the best of my knowledge, this patch is fine ;)

Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>


From catalin.marinas at arm.com  Mon Feb 15 02:23:25 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 15 Feb 2016 10:23:25 +0000
Subject: [PATCH v4 00/23] arm64: Virtualization Host Extension support
In-Reply-To: <56BCDCBA.5080202@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
 <20160211190701.GA4842@cbox> <56BCDCBA.5080202@arm.com>
Message-ID: <20160215102324.GD13683@e104818-lin.cambridge.arm.com>

On Thu, Feb 11, 2016 at 07:10:50PM +0000, Marc Zyngier wrote:
> On 11/02/16 19:07, Christoffer Dall wrote:
> > On Thu, Feb 11, 2016 at 06:39:41PM +0000, Marc Zyngier wrote:
> >> ARMv8.1 comes with the "Virtualization Host Extension" (VHE for
> >> short), which enables simpler support of Type-2 hypervisors.
> >>
> >> This extension allows the kernel to directly run at EL2, and
> >> significantly reduces the number of system registers shared between
> >> host and guest, reducing the overhead of virtualization.
> >>
> >> In order to have the same kernel binary running on all versions of the
> >> architecture, this series makes heavy use of runtime code patching.
> >>
> >> The first 22 patches massage the KVM code to deal with VHE and enable
> >> Linux to run at EL2. The last patch catches an ugly case when VHE
> >> capable CPUs are paired with some of their less capable siblings. This
> >> should never happen, but hey...
> >>
> >> I have deliberately left out some of the more "advanced"
> >> optimizations, as they are likely to distract the reviewer from the
> >> core infrastructure, which is what I care about at the moment.
> >>
> >> Note: GDB is currently busted on VHE systems, as it checks for version
> >>       6 on the debug architecture, while VHE is version 7. The
> >>       binutils people are on the case.
> >>
> >> This has been tested on the FVP_Base_SLV-V8-A model, and based on
> >> v4.5-rc3 + kvmarm/master. I've put a branch out on:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/vhe
> > 
> > I'm happy with this series as it stands, we just need someone to take a
> > look at that debug patch and be happy with it.
> 
> I think Will is planning to have a go at it shortly. Once he and Catalin
> are happy with the thing, I'll throw it into -next for a good shake.

Fine by me but it would be good for Will to have a look, especially on
the debug and perf stuff.

-- 
Catalin


From wens at csie.org  Mon Feb 15 02:31:22 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 18:31:22 +0800
Subject: [PATCH v2 04/10] regulator: axp20x: Use of_match name as default
 regulator name
In-Reply-To: <1455532288-30870-1-git-send-email-wens@csie.org>
References: <1455532288-30870-1-git-send-email-wens@csie.org>
Message-ID: <1455532288-30870-5-git-send-email-wens@csie.org>

Originally the helper macros used uppercase regulator names, which
are primarily used to expand to the regulator ID enum, as the default
names. This is aestheticly unpleasent.

Since the of_match bits are the same, just lowercase, use that as the
default names instead.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 drivers/regulator/axp20x-regulator.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 81f25383f2d5..40cd894e4df5 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -39,7 +39,7 @@
 #define AXP_DESC_IO(_family, _id, _match, _supply, _min, _max, _step, _vreg,	\
 		    _vmask, _ereg, _emask, _enable_val, _disable_val)		\
 	[_family##_##_id] = {							\
-		.name		= #_id,						\
+		.name		= (_match),					\
 		.supply_name	= (_supply),					\
 		.of_match	= of_match_ptr(_match),				\
 		.regulators_node = of_match_ptr("regulators"),			\
@@ -61,7 +61,7 @@
 #define AXP_DESC(_family, _id, _match, _supply, _min, _max, _step, _vreg,	\
 		 _vmask, _ereg, _emask) 					\
 	[_family##_##_id] = {							\
-		.name		= #_id,						\
+		.name		= (_match),					\
 		.supply_name	= (_supply),					\
 		.of_match	= of_match_ptr(_match),				\
 		.regulators_node = of_match_ptr("regulators"),			\
@@ -80,7 +80,7 @@
 
 #define AXP_DESC_SW(_family, _id, _match, _supply, _ereg, _emask)		\
 	[_family##_##_id] = {							\
-		.name		= #_id,						\
+		.name		= (_match),					\
 		.supply_name	= (_supply),					\
 		.of_match	= of_match_ptr(_match),				\
 		.regulators_node = of_match_ptr("regulators"),			\
@@ -94,7 +94,7 @@
 
 #define AXP_DESC_FIXED(_family, _id, _match, _supply, _volt)			\
 	[_family##_##_id] = {							\
-		.name		= #_id,						\
+		.name		= (_match),					\
 		.supply_name	= (_supply),					\
 		.of_match	= of_match_ptr(_match),				\
 		.regulators_node = of_match_ptr("regulators"),			\
@@ -109,7 +109,7 @@
 #define AXP_DESC_RANGES(_family, _id, _match, _supply, _ranges, _n_voltages,	\
 			_vreg, _vmask, _ereg, _emask)				\
 	[_family##_##_id] = {							\
-		.name		= #_id,						\
+		.name		= (_match),					\
 		.supply_name	= (_supply),					\
 		.of_match	= of_match_ptr(_match),				\
 		.regulators_node = of_match_ptr("regulators"),			\
-- 
2.7.0



From wens at csie.org  Mon Feb 15 02:31:19 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 18:31:19 +0800
Subject: [PATCH v2 01/10] MAINTAINERS: Add entry for X-Powers AXP family PMIC
 drivers
In-Reply-To: <1455532288-30870-1-git-send-email-wens@csie.org>
References: <1455532288-30870-1-git-send-email-wens@csie.org>
Message-ID: <1455532288-30870-2-git-send-email-wens@csie.org>

Add an entry for X-Powers AXP family PMIC drivers and list myself
as maintainer.

Cc: Carlo Caione <carlo at caione.org>
Cc: Maxime Ripard <maxime.ripard at free-electrons.com>
Cc: Ramakrishna Pallala <ramakrishna.pallala at intel.com>
Cc: Todd Brandt <todd.e.brandt at linux.intel.com>
Cc: Jacob Pan <jacob.jun.pan at linux.intel.com>
Signed-off-by: Chen-Yu Tsai <wens at csie.org>
Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f678c37107f5..7ea4e54f566a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11941,6 +11941,12 @@ F:	include/linux/workqueue.h
 F:	kernel/workqueue.c
 F:	Documentation/workqueue.txt
 
+X-POWERS MULTIFUNCTION PMIC DEVICE DRIVERS
+M:	Chen-Yu Tsai <wens at csie.org>
+L:	linux-kernel at vger.kernel.org
+S:	Maintained
+N:	axp[128]
+
 X.25 NETWORK LAYER
 M:	Andrew Hendry <andrew.hendry at gmail.com>
 L:	linux-x25 at vger.kernel.org
-- 
2.7.0



From wens at csie.org  Mon Feb 15 02:31:18 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 18:31:18 +0800
Subject: [PATCH v2 00/10] mfd: axp20x: Add support for AXP809 PMIC
Message-ID: <1455532288-30870-1-git-send-email-wens@csie.org>

Hi everyone,

This is v2 of the AXP809 PMIC support series. This adds support for
X-Powers' AXP809 PMIC. This is the primary PMIC accompanying Allwinner's
A80 SoC. For now, only the power button (PEK) and regulators are
supported. These are supported using existing axp20x drivers. This is
based on the AXP223 series v8, as well as 2 patches from v1 that are
already in regulator/topic/axp20x.

Changes since v1:

  - Added patch 4, changing default regulator names to lowercase.
  - Dropped regulator nodes from axp809.dtsi.

Patch 1 adds a MAINTAINERS entry for the X-Powers AXP PMICs. I list
myself as the maintainer.

Patch 2 adds AXP809 to the axp20x bindings.

Patch 3 adds AXP809 support to the axp20x mfd driver.

Patch 4 changes the in-kernel default regulator names from uppercase to
lowercase, making it easier on the eye.

Patch 5 adds AXP809 support to the axp20x regulator driver. This patch
depends on patch 3, and patches already in regulator/topic/axp20x.

Patch 6 adds a dtsi file for AXP809.

Patch 7 enables AXP809 support on the A80 Optimus board.

Patch 8 enables AXP809 support on the Cubieboard 4.

Patch 9 disables the dummy regulators from sunxi-common-regulators.dtsi
on the A80 Optimus board. These aren't used in the board DTS anymore.

Patch 10 disables the dummy regulators from sunxi-common-regulators.dtsi,
on the Cubieboard4. These aren't used in the board DTS anymore.


Regards
ChenYu

Chen-Yu Tsai (10):
  MAINTAINERS: Add entry for X-Powers AXP family PMIC drivers
  mfd: axp20x: Add bindings for AXP809 PMIC
  mfd: axp20x: Add support for AXP809 PMIC
  regulator: axp20x: Use of_match name as default regulator name
  regulator: axp20x: support AXP809 variant
  ARM: dts: sunxi: Add dtsi file for AXP809 PMIC
  ARM: dts: sun9i: a80-optimus: Add AXP809 PMIC device node and
    regulators
  ARM: dts: sun9i: cubieboard4: Add AXP809 PMIC device node and
    regulators
  ARM: dts: sun9i: a80-optimus: Disable dummy regulators vcc3v0, vcc3v3,
    vcc5v0
  ARM: dts: sun9i: cubieboard4: Disable dummy regulators vcc3v0, vcc3v3,
    vcc5v0

 Documentation/devicetree/bindings/mfd/axp20x.txt   |  31 ++++-
 MAINTAINERS                                        |   6 +
 .../dts/{sun9i-a80-cubieboard4.dts => axp809.dtsi} |  98 ++------------
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts        | 143 ++++++++++++++++++++-
 arch/arm/boot/dts/sun9i-a80-optimus.dts            | 143 ++++++++++++++++++++-
 drivers/mfd/axp20x-rsb.c                           |   1 +
 drivers/mfd/axp20x.c                               |  79 ++++++++++++
 drivers/regulator/axp20x-regulator.c               | 129 ++++++++++++++-----
 include/linux/mfd/axp20x.h                         |  59 +++++++++
 9 files changed, 559 insertions(+), 130 deletions(-)
 copy arch/arm/boot/dts/{sun9i-a80-cubieboard4.dts => axp809.dtsi} (52%)

-- 
2.7.0



From wens at csie.org  Mon Feb 15 02:31:20 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 18:31:20 +0800
Subject: [PATCH v2 02/10] mfd: axp20x: Add bindings for AXP809 PMIC
In-Reply-To: <1455532288-30870-1-git-send-email-wens@csie.org>
References: <1455532288-30870-1-git-send-email-wens@csie.org>
Message-ID: <1455532288-30870-3-git-send-email-wens@csie.org>

This patch adds the basic and regulator bindings for the X-Powers AXP809
PMIC.

Also update the DC-DC converter operating frequency for AXP22X/AXP80X.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 31 ++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
index fd39fa54571b..d20b1034e967 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -6,10 +6,11 @@ axp202 (X-Powers)
 axp209 (X-Powers)
 axp221 (X-Powers)
 axp223 (X-Powers)
+axp809 (X-Powers)
 
 Required properties:
 - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
-	      "x-powers,axp221", "x-powers,axp223"
+	      "x-powers,axp221", "x-powers,axp223", "x-powers,axp809"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
@@ -18,7 +19,9 @@ Required properties:
 
 Optional properties:
 - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
-		      (range: 750-1875). Default: 1.5MHz
+		      AXP152/20X: range:  750-1875, Default: 1.5 MHz
+		      AXP22X/80X: range: 1800-4050, Default: 3   MHz
+
 - <input>-supply: a phandle to the regulator supply node. May be omitted if
 		  inputs are unregulated, such as using the IPSOUT output
 		  from the PMIC.
@@ -77,6 +80,30 @@ LDO_IO0		: LDO		: ips-supply		: GPIO 0
 LDO_IO1		: LDO		: ips-supply		: GPIO 1
 RTC_LDO		: LDO		: ips-supply		: always on
 
+AXP809 regulators, type, and corresponding input supply names:
+
+Regulator	  Type		  Supply Name		  Notes
+---------	  ----		  -----------		  -----
+DCDC1		: DC-DC buck	: vin1-supply
+DCDC2		: DC-DC buck	: vin2-supply
+DCDC3		: DC-DC	buck	: vin3-supply
+DCDC4		: DC-DC	buck	: vin4-supply
+DCDC5		: DC-DC	buck	: vin5-supply
+DC1SW		: On/Off Switch	:			: DCDC1 secondary output
+DC5LDO		: LDO		:			: input from DCDC5
+ALDO1		: LDO		: aldoin-supply		: shared supply
+ALDO2		: LDO		: aldoin-supply		: shared supply
+ALDO3		: LDO		: aldoin-supply		: shared supply
+DLDO1		: LDO		: dldoin-supply		: shared supply
+DLDO2		: LDO		: dldoin-supply		: shared supply
+ELDO1		: LDO		: eldoin-supply		: shared supply
+ELDO2		: LDO		: eldoin-supply		: shared supply
+ELDO3		: LDO		: eldoin-supply		: shared supply
+LDO_IO0		: LDO		: ips-supply		: GPIO 0
+LDO_IO1		: LDO		: ips-supply		: GPIO 1
+RTC_LDO		: LDO		: ips-supply		: always on
+SW		: On/Off Switch : swin-supply
+
 Example:
 
 axp209: pmic at 34 {
-- 
2.7.0



From wens at csie.org  Mon Feb 15 02:31:21 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 18:31:21 +0800
Subject: [PATCH v2 03/10] mfd: axp20x: Add support for AXP809 PMIC
In-Reply-To: <1455532288-30870-1-git-send-email-wens@csie.org>
References: <1455532288-30870-1-git-send-email-wens@csie.org>
Message-ID: <1455532288-30870-4-git-send-email-wens@csie.org>

The X-Powers AXP809 is a new PMIC that is paired with Allwinner's A80
SoC, along with a slave AXP806 PMIC.

This PMIC is quite similar to the earlier AXP223, though the interrupts
and regulator have changed a bit.

This patch adds support for the interrupts and power button of the PMIC.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 drivers/mfd/axp20x-rsb.c   |  1 +
 drivers/mfd/axp20x.c       | 79 ++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mfd/axp20x.h | 59 ++++++++++++++++++++++++++++++++++
 3 files changed, 139 insertions(+)

diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
index 28c20247c112..a407527bcd09 100644
--- a/drivers/mfd/axp20x-rsb.c
+++ b/drivers/mfd/axp20x-rsb.c
@@ -61,6 +61,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
 
 static const struct of_device_id axp20x_rsb_of_match[] = {
 	{ .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
+	{ .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, axp20x_rsb_of_match);
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index a57d6e940610..1ce923277cc8 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -37,6 +37,7 @@ static const char * const axp20x_model_names[] = {
 	"AXP221",
 	"AXP223",
 	"AXP288",
+	"AXP809",
 };
 
 static const struct regmap_range axp152_writeable_ranges[] = {
@@ -85,6 +86,7 @@ static const struct regmap_access_table axp20x_volatile_table = {
 	.n_yes_ranges	= ARRAY_SIZE(axp20x_volatile_ranges),
 };
 
+/* AXP22x ranges are shared with the AXP809, as they cover the same range */
 static const struct regmap_range axp22x_writeable_ranges[] = {
 	regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
 	regmap_reg_range(AXP20X_DCDC_MODE, AXP22X_BATLOW_THRES1),
@@ -211,6 +213,20 @@ static struct resource axp288_fuel_gauge_resources[] = {
 	},
 };
 
+static struct resource axp809_pek_resources[] = {
+	{
+		.name   = "PEK_DBR",
+		.start  = AXP809_IRQ_PEK_RIS_EDGE,
+		.end    = AXP809_IRQ_PEK_RIS_EDGE,
+		.flags  = IORESOURCE_IRQ,
+	}, {
+		.name   = "PEK_DBF",
+		.start  = AXP809_IRQ_PEK_FAL_EDGE,
+		.end    = AXP809_IRQ_PEK_FAL_EDGE,
+		.flags  = IORESOURCE_IRQ,
+	},
+};
+
 static const struct regmap_config axp152_regmap_config = {
 	.reg_bits	= 8,
 	.val_bits	= 8,
@@ -378,6 +394,41 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
 	INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG,            5, 1),
 };
 
+static const struct regmap_irq axp809_regmap_irqs[] = {
+	INIT_REGMAP_IRQ(AXP809, ACIN_OVER_V,		0, 7),
+	INIT_REGMAP_IRQ(AXP809, ACIN_PLUGIN,		0, 6),
+	INIT_REGMAP_IRQ(AXP809, ACIN_REMOVAL,	        0, 5),
+	INIT_REGMAP_IRQ(AXP809, VBUS_OVER_V,		0, 4),
+	INIT_REGMAP_IRQ(AXP809, VBUS_PLUGIN,		0, 3),
+	INIT_REGMAP_IRQ(AXP809, VBUS_REMOVAL,	        0, 2),
+	INIT_REGMAP_IRQ(AXP809, VBUS_V_LOW,		0, 1),
+	INIT_REGMAP_IRQ(AXP809, BATT_PLUGIN,		1, 7),
+	INIT_REGMAP_IRQ(AXP809, BATT_REMOVAL,	        1, 6),
+	INIT_REGMAP_IRQ(AXP809, BATT_ENT_ACT_MODE,	1, 5),
+	INIT_REGMAP_IRQ(AXP809, BATT_EXIT_ACT_MODE,	1, 4),
+	INIT_REGMAP_IRQ(AXP809, CHARG,		        1, 3),
+	INIT_REGMAP_IRQ(AXP809, CHARG_DONE,		1, 2),
+	INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_HIGH,	2, 7),
+	INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_HIGH_END,	2, 6),
+	INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_LOW,	2, 5),
+	INIT_REGMAP_IRQ(AXP809, BATT_CHG_TEMP_LOW_END,	2, 4),
+	INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_HIGH,	2, 3),
+	INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_HIGH_END,	2, 2),
+	INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_LOW,	2, 1),
+	INIT_REGMAP_IRQ(AXP809, BATT_ACT_TEMP_LOW_END,	2, 0),
+	INIT_REGMAP_IRQ(AXP809, DIE_TEMP_HIGH,	        3, 7),
+	INIT_REGMAP_IRQ(AXP809, LOW_PWR_LVL1,	        3, 1),
+	INIT_REGMAP_IRQ(AXP809, LOW_PWR_LVL2,	        3, 0),
+	INIT_REGMAP_IRQ(AXP809, TIMER,		        4, 7),
+	INIT_REGMAP_IRQ(AXP809, PEK_RIS_EDGE,	        4, 6),
+	INIT_REGMAP_IRQ(AXP809, PEK_FAL_EDGE,	        4, 5),
+	INIT_REGMAP_IRQ(AXP809, PEK_SHORT,		4, 4),
+	INIT_REGMAP_IRQ(AXP809, PEK_LONG,		4, 3),
+	INIT_REGMAP_IRQ(AXP809, PEK_OVER_OFF,		4, 2),
+	INIT_REGMAP_IRQ(AXP809, GPIO1_INPUT,		4, 1),
+	INIT_REGMAP_IRQ(AXP809, GPIO0_INPUT,		4, 0),
+};
+
 static const struct regmap_irq_chip axp152_regmap_irq_chip = {
 	.name			= "axp152_irq_chip",
 	.status_base		= AXP152_IRQ1_STATE,
@@ -428,6 +479,18 @@ static const struct regmap_irq_chip axp288_regmap_irq_chip = {
 
 };
 
+static const struct regmap_irq_chip axp809_regmap_irq_chip = {
+	.name			= "axp809",
+	.status_base		= AXP20X_IRQ1_STATE,
+	.ack_base		= AXP20X_IRQ1_STATE,
+	.mask_base		= AXP20X_IRQ1_EN,
+	.mask_invert		= true,
+	.init_ack_masked	= true,
+	.irqs			= axp809_regmap_irqs,
+	.num_irqs		= ARRAY_SIZE(axp809_regmap_irqs),
+	.num_regs		= 5,
+};
+
 static struct mfd_cell axp20x_cells[] = {
 	{
 		.name		= "axp20x-pek",
@@ -572,6 +635,16 @@ static struct mfd_cell axp288_cells[] = {
 	},
 };
 
+static struct mfd_cell axp809_cells[] = {
+	{
+		.name			= "axp20x-pek",
+		.num_resources		= ARRAY_SIZE(axp809_pek_resources),
+		.resources		= axp809_pek_resources,
+	}, {
+		.name			= "axp20x-regulator",
+	},
+};
+
 static struct axp20x_dev *axp20x_pm_power_off;
 static void axp20x_power_off(void)
 {
@@ -631,6 +704,12 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
 		axp20x->regmap_cfg = &axp288_regmap_config;
 		axp20x->regmap_irq_chip = &axp288_regmap_irq_chip;
 		break;
+	case AXP809_ID:
+		axp20x->nr_cells = ARRAY_SIZE(axp809_cells);
+		axp20x->cells = axp809_cells;
+		axp20x->regmap_cfg = &axp22x_regmap_config;
+		axp20x->regmap_irq_chip = &axp809_regmap_irq_chip;
+		break;
 	default:
 		dev_err(dev, "unsupported AXP20X ID %lu\n", axp20x->variant);
 		return -EINVAL;
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index d82e7d51372b..0be4982f08fe 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -20,6 +20,7 @@ enum {
 	AXP221_ID,
 	AXP223_ID,
 	AXP288_ID,
+	AXP809_ID,
 	NR_AXP20X_VARIANTS,
 };
 
@@ -264,6 +265,29 @@ enum {
 	AXP22X_REG_ID_MAX,
 };
 
+enum {
+	AXP809_DCDC1 = 0,
+	AXP809_DCDC2,
+	AXP809_DCDC3,
+	AXP809_DCDC4,
+	AXP809_DCDC5,
+	AXP809_DC1SW,
+	AXP809_DC5LDO,
+	AXP809_ALDO1,
+	AXP809_ALDO2,
+	AXP809_ALDO3,
+	AXP809_ELDO1,
+	AXP809_ELDO2,
+	AXP809_ELDO3,
+	AXP809_DLDO1,
+	AXP809_DLDO2,
+	AXP809_RTC_LDO,
+	AXP809_LDO_IO0,
+	AXP809_LDO_IO1,
+	AXP809_SW,
+	AXP809_REG_ID_MAX,
+};
+
 /* IRQs */
 enum {
 	AXP152_IRQ_LDO0IN_CONNECT = 1,
@@ -390,6 +414,41 @@ enum axp288_irqs {
 	AXP288_IRQ_BC_USB_CHNG,
 };
 
+enum axp809_irqs {
+	AXP809_IRQ_ACIN_OVER_V = 1,
+	AXP809_IRQ_ACIN_PLUGIN,
+	AXP809_IRQ_ACIN_REMOVAL,
+	AXP809_IRQ_VBUS_OVER_V,
+	AXP809_IRQ_VBUS_PLUGIN,
+	AXP809_IRQ_VBUS_REMOVAL,
+	AXP809_IRQ_VBUS_V_LOW,
+	AXP809_IRQ_BATT_PLUGIN,
+	AXP809_IRQ_BATT_REMOVAL,
+	AXP809_IRQ_BATT_ENT_ACT_MODE,
+	AXP809_IRQ_BATT_EXIT_ACT_MODE,
+	AXP809_IRQ_CHARG,
+	AXP809_IRQ_CHARG_DONE,
+	AXP809_IRQ_BATT_CHG_TEMP_HIGH,
+	AXP809_IRQ_BATT_CHG_TEMP_HIGH_END,
+	AXP809_IRQ_BATT_CHG_TEMP_LOW,
+	AXP809_IRQ_BATT_CHG_TEMP_LOW_END,
+	AXP809_IRQ_BATT_ACT_TEMP_HIGH,
+	AXP809_IRQ_BATT_ACT_TEMP_HIGH_END,
+	AXP809_IRQ_BATT_ACT_TEMP_LOW,
+	AXP809_IRQ_BATT_ACT_TEMP_LOW_END,
+	AXP809_IRQ_DIE_TEMP_HIGH,
+	AXP809_IRQ_LOW_PWR_LVL1,
+	AXP809_IRQ_LOW_PWR_LVL2,
+	AXP809_IRQ_TIMER,
+	AXP809_IRQ_PEK_RIS_EDGE,
+	AXP809_IRQ_PEK_FAL_EDGE,
+	AXP809_IRQ_PEK_SHORT,
+	AXP809_IRQ_PEK_LONG,
+	AXP809_IRQ_PEK_OVER_OFF,
+	AXP809_IRQ_GPIO1_INPUT,
+	AXP809_IRQ_GPIO0_INPUT,
+};
+
 #define AXP288_TS_ADC_H		0x58
 #define AXP288_TS_ADC_L		0x59
 #define AXP288_GP_ADC_H		0x5a
-- 
2.7.0



From wens at csie.org  Mon Feb 15 02:31:28 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 18:31:28 +0800
Subject: [PATCH v2 10/10] ARM: dts: sun9i: cubieboard4: Disable dummy
 regulators vcc3v0, vcc3v3, vcc5v0
In-Reply-To: <1455532288-30870-1-git-send-email-wens@csie.org>
References: <1455532288-30870-1-git-send-email-wens@csie.org>
Message-ID: <1455532288-30870-11-git-send-email-wens@csie.org>

These 3 regulators are provided in sunxi-common-regulators.dtsi.
3.0V/3.3V and 5.0V are commonly used voltages in Allwinner devices.
These dummy regulators provide a stand-in when bindings that require
one, but the real regulator is not supported yet.

Since these are no longer needed, we can disable them.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index 8d8af1189d87..84a12fef5768 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -255,6 +255,18 @@
 
 #include "axp809.dtsi"
 
+&reg_vcc3v0 {
+	status = "disabled";
+};
+
+&reg_vcc3v3 {
+	status = "disabled";
+};
+
+&reg_vcc5v0 {
+	status = "disabled";
+};
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pins_a>;
-- 
2.7.0



From wens at csie.org  Mon Feb 15 02:31:27 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 18:31:27 +0800
Subject: [PATCH v2 09/10] ARM: dts: sun9i: a80-optimus: Disable dummy
 regulators vcc3v0, vcc3v3, vcc5v0
In-Reply-To: <1455532288-30870-1-git-send-email-wens@csie.org>
References: <1455532288-30870-1-git-send-email-wens@csie.org>
Message-ID: <1455532288-30870-10-git-send-email-wens@csie.org>

These 3 regulators are provided in sunxi-common-regulators.dtsi.
3.0V/3.3V and 5.0V are commonly used voltages in Allwinner devices.
These dummy regulators provide a stand-in when bindings that require
one, but the real regulator is not supported yet.

Since these are no longer needed, we can disable them.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/boot/dts/sun9i-a80-optimus.dts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index 6cfc02194035..991337d1d6f1 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -322,6 +322,18 @@
 
 #include "axp809.dtsi"
 
+&reg_vcc3v0 {
+	status = "disabled";
+};
+
+&reg_vcc3v3 {
+	status = "disabled";
+};
+
+&reg_vcc5v0 {
+	status = "disabled";
+};
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pins_a>;
-- 
2.7.0



From wens at csie.org  Mon Feb 15 02:31:24 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 18:31:24 +0800
Subject: [PATCH v2 06/10] ARM: dts: sunxi: Add dtsi file for AXP809 PMIC
In-Reply-To: <1455532288-30870-1-git-send-email-wens@csie.org>
References: <1455532288-30870-1-git-send-email-wens@csie.org>
Message-ID: <1455532288-30870-7-git-send-email-wens@csie.org>

The AXP809 PMIC is used with the Allwinner A80 SoC, along with
an AXP806 PMIC as a slave.

This patch adds a dtsi file for all the common bindings and default
values unrelated to board design. Currently this is just listing all
the regulator nodes. The regulators are initialized based on their
device node names.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/boot/dts/axp809.dtsi | 53 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 arch/arm/boot/dts/axp809.dtsi

diff --git a/arch/arm/boot/dts/axp809.dtsi b/arch/arm/boot/dts/axp809.dtsi
new file mode 100644
index 000000000000..ab8e5f2d9246
--- /dev/null
+++ b/arch/arm/boot/dts/axp809.dtsi
@@ -0,0 +1,53 @@
+/*
+ * Copyright 2015 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai <wens at csie.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * AXP809 Integrated Power Management Chip
+ */
+
+&axp809 {
+	compatible = "x-powers,axp809";
+	interrupt-controller;
+	#interrupt-cells = <1>;
+};
-- 
2.7.0



From wens at csie.org  Mon Feb 15 02:31:26 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 18:31:26 +0800
Subject: [PATCH v2 08/10] ARM: dts: sun9i: cubieboard4: Add AXP809 PMIC device
 node and regulators
In-Reply-To: <1455532288-30870-1-git-send-email-wens@csie.org>
References: <1455532288-30870-1-git-send-email-wens@csie.org>
Message-ID: <1455532288-30870-9-git-send-email-wens@csie.org>

The AXP809 PMIC is the primary PMIC. It provides various supply voltages
for the SoC and other peripherals. The PMIC's interrupt line is connected
to NMI pin of the SoC.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 131 +++++++++++++++++++++++++++-
 1 file changed, 129 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index eb2ccd0a3bd5..8d8af1189d87 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -98,7 +98,7 @@
 &mmc0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins>, <&mmc0_cd_pin_cubieboard4>;
-	vmmc-supply = <&reg_vcc3v0>;
+	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
 	cd-gpios = <&pio 7 18 GPIO_ACTIVE_HIGH>; /* PH18 */
 	cd-inverted;
@@ -108,7 +108,7 @@
 &mmc2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc2_8bit_pins>;
-	vmmc-supply = <&reg_vcc3v0>;
+	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <8>;
 	non-removable;
 	cap-mmc-hw-reset;
@@ -126,8 +126,135 @@
 
 &r_rsb {
 	status = "okay";
+
+	axp809: pmic at 3a3 {
+		reg = <0x3a3>;
+		interrupt-parent = <&nmi_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+
+		regulators {
+			reg_aldo1: aldo1 {
+				/*
+				 * TODO: This should be handled by the
+				 * USB PHY driver.
+				 */
+				regulator-always-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcc33-usbh";
+			};
+
+			reg_aldo2: aldo2 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc-pb-io-cam";
+			};
+
+			aldo3 {
+				/* unused */
+			};
+
+			reg_dc5ldo: dc5ldo {
+				regulator-always-on;
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-name = "vdd-cpus-09-usbh";
+			};
+
+			reg_dcdc1: dcdc1 {
+				regulator-always-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcc-3v";
+			};
+
+			reg_dcdc2: dcdc2 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-name = "vdd-gpu";
+			};
+
+			reg_dcdc3: dcdc3 {
+				regulator-always-on;
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-name = "vdd-cpua";
+			};
+
+			reg_dcdc4: dcdc4 {
+				regulator-always-on;
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-name = "vdd-sys-usb0-hdmi";
+			};
+
+			reg_dcdc5: dcdc5 {
+				regulator-always-on;
+				regulator-min-microvolt = <1425000>;
+				regulator-max-microvolt = <1575000>;
+				regulator-name = "vcc-dram";
+			};
+
+			reg_dldo1: dldo1 {
+				/*
+				 * The WiFi chip supports a wide range
+				 * (3.0 ~ 4.8V) of voltages, and so does
+				 * this regulator (3.0 ~ 4.2V), but
+				 * Allwinner SDK always sets it to 3.3V.
+				 */
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc-wifi";
+			};
+
+			reg_dldo2: dldo2 {
+				regulator-always-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcc-pl";
+			};
+
+			reg_eldo1: eldo1 {
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-name = "vcc-dvdd-cam";
+			};
+
+			reg_eldo2: eldo2 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc-pe";
+			};
+
+			reg_eldo3: eldo3 {
+				regulator-always-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcc-pm-codec-io1";
+			};
+
+			reg_ldo_io0: ldo_io0 {
+				regulator-always-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcc-pg";
+			};
+
+			reg_ldo_io1: ldo_io1 {
+				regulator-min-microvolt = <2500000>;
+				regulator-max-microvolt = <2500000>;
+				regulator-name = "vcc-pa-gmac-2v5";
+			};
+
+			reg_rtc_ldo: rtc_ldo {
+				regulator-name = "vcc-rtc-vdd1v8-io";
+			};
+		};
+	};
 };
 
+#include "axp809.dtsi"
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pins_a>;
-- 
2.7.0



From wens at csie.org  Mon Feb 15 02:31:25 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 18:31:25 +0800
Subject: [PATCH v2 07/10] ARM: dts: sun9i: a80-optimus: Add AXP809 PMIC device
 node and regulators
In-Reply-To: <1455532288-30870-1-git-send-email-wens@csie.org>
References: <1455532288-30870-1-git-send-email-wens@csie.org>
Message-ID: <1455532288-30870-8-git-send-email-wens@csie.org>

The AXP809 PMIC is the primary PMIC. It provides various supply voltages
for the SoC and other peripherals. The PMIC's interrupt line is
connected to NMI pin of the SoC.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 arch/arm/boot/dts/sun9i-a80-optimus.dts | 131 +++++++++++++++++++++++++++++++-
 1 file changed, 129 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun9i-a80-optimus.dts b/arch/arm/boot/dts/sun9i-a80-optimus.dts
index d7a20d92b114..6cfc02194035 100644
--- a/arch/arm/boot/dts/sun9i-a80-optimus.dts
+++ b/arch/arm/boot/dts/sun9i-a80-optimus.dts
@@ -150,7 +150,7 @@
 &mmc0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins>, <&mmc0_cd_pin_optimus>;
-	vmmc-supply = <&reg_vcc3v0>;
+	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <4>;
 	cd-gpios = <&pio 7 18 GPIO_ACTIVE_HIGH>; /* PH8 */
 	cd-inverted;
@@ -160,7 +160,7 @@
 &mmc2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc2_8bit_pins>;
-	vmmc-supply = <&reg_vcc3v0>;
+	vmmc-supply = <&reg_dcdc1>;
 	bus-width = <8>;
 	non-removable;
 	cap-mmc-hw-reset;
@@ -193,8 +193,135 @@
 
 &r_rsb {
 	status = "okay";
+
+	axp809: pmic at 3a3 {
+		reg = <0x3a3>;
+		interrupt-parent = <&nmi_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+
+		regulators {
+			reg_aldo1: aldo1 {
+				/*
+				 * TODO: This should be handled by the
+				 * USB PHY driver.
+				 */
+				regulator-always-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcc33-usbh";
+			};
+
+			reg_aldo2: aldo2 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc-pb-io-cam";
+			};
+
+			aldo3 {
+				/* unused */
+			};
+
+			reg_dc5ldo: dc5ldo {
+				regulator-always-on;
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-name = "vdd-cpus-09-usbh";
+			};
+
+			reg_dcdc1: dcdc1 {
+				regulator-always-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcc-3v";
+			};
+
+			reg_dcdc2: dcdc2 {
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-name = "vdd-gpu";
+			};
+
+			reg_dcdc3: dcdc3 {
+				regulator-always-on;
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-name = "vdd-cpua";
+			};
+
+			reg_dcdc4: dcdc4 {
+				regulator-always-on;
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1100000>;
+				regulator-name = "vdd-sys-usb0-hdmi";
+			};
+
+			reg_dcdc5: dcdc5 {
+				regulator-always-on;
+				regulator-min-microvolt = <1425000>;
+				regulator-max-microvolt = <1575000>;
+				regulator-name = "vcc-dram";
+			};
+
+			reg_dldo1: dldo1 {
+				/*
+				 * The WiFi chip supports a wide range
+				 * (3.0 ~ 4.8V) of voltages, and so does
+				 * this regulator (3.0 ~ 4.2V), but
+				 * Allwinner SDK always sets it to 3.3V.
+				 */
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc-wifi";
+			};
+
+			reg_dldo2: dldo2 {
+				regulator-always-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcc-pl";
+			};
+
+			reg_eldo1: eldo1 {
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1200000>;
+				regulator-name = "vcc-dvdd-cam";
+			};
+
+			reg_eldo2: eldo2 {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc-pe";
+			};
+
+			reg_eldo3: eldo3 {
+				regulator-always-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcc-pm-codec-io1";
+			};
+
+			reg_ldo_io0: ldo_io0 {
+				regulator-always-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcc-pg";
+			};
+
+			reg_ldo_io1: ldo_io1 {
+				regulator-min-microvolt = <2500000>;
+				regulator-max-microvolt = <2500000>;
+				regulator-name = "vcc-pa-gmac-2v5";
+			};
+
+			reg_rtc_ldo: rtc_ldo {
+				regulator-name = "vcc-rtc-vdd1v8-io";
+			};
+		};
+	};
 };
 
+#include "axp809.dtsi"
+
 &uart0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&uart0_pins_a>;
-- 
2.7.0



From wens at csie.org  Mon Feb 15 02:31:23 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 18:31:23 +0800
Subject: [PATCH v2 05/10] regulator: axp20x: support AXP809 variant
In-Reply-To: <1455532288-30870-1-git-send-email-wens@csie.org>
References: <1455532288-30870-1-git-send-email-wens@csie.org>
Message-ID: <1455532288-30870-6-git-send-email-wens@csie.org>

The X-Powers AXP809 PMIC has a similar set of regulators as the AXP221,
though a few LDOs were removed, and a new switch output added. Like the
AXP221, AXP809 also has DC1SW and DC5LDO, which are internally chained
to DCDC1 and DCDC5, respectively.

Add support for this new variant. Also remove the "axp22x_" prefix from
DC1SW/DC5LDO supply handling code, as the AXP809 uses it as well.

Signed-off-by: Chen-Yu Tsai <wens at csie.org>
---
 drivers/regulator/axp20x-regulator.c | 119 ++++++++++++++++++++++++++---------
 1 file changed, 90 insertions(+), 29 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c
index 40cd894e4df5..6a601f377019 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -224,6 +224,61 @@ static const struct regulator_desc axp22x_regulators[] = {
 	AXP_DESC_FIXED(AXP22X, RTC_LDO, "rtc_ldo", "ips", 3000),
 };
 
+static const struct regulator_linear_range axp809_dcdc4_ranges[] = {
+	REGULATOR_LINEAR_RANGE(600000, 0x0, 0x2f, 20000),
+	REGULATOR_LINEAR_RANGE(1800000, 0x30, 0x38, 100000),
+};
+
+static const struct regulator_linear_range axp809_dldo1_ranges[] = {
+	REGULATOR_LINEAR_RANGE(700000, 0x0, 0x1a, 100000),
+	REGULATOR_LINEAR_RANGE(3400000, 0x1b, 0x1f, 200000),
+};
+
+static const struct regulator_desc axp809_regulators[] = {
+	AXP_DESC(AXP809, DCDC1, "dcdc1", "vin1", 1600, 3400, 100,
+		 AXP22X_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(1)),
+	AXP_DESC(AXP809, DCDC2, "dcdc2", "vin2", 600, 1540, 20,
+		 AXP22X_DCDC2_V_OUT, 0x3f, AXP22X_PWR_OUT_CTRL1, BIT(2)),
+	AXP_DESC(AXP809, DCDC3, "dcdc3", "vin3", 600, 1860, 20,
+		 AXP22X_DCDC3_V_OUT, 0x3f, AXP22X_PWR_OUT_CTRL1, BIT(3)),
+	AXP_DESC_RANGES(AXP809, DCDC4, "dcdc4", "vin4", axp809_dcdc4_ranges,
+			57, AXP22X_DCDC4_V_OUT, 0x3f, AXP22X_PWR_OUT_CTRL1,
+			BIT(4)),
+	AXP_DESC(AXP809, DCDC5, "dcdc5", "vin5", 1000, 2550, 50,
+		 AXP22X_DCDC5_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(5)),
+	/* secondary switchable output of DCDC1 */
+	AXP_DESC_SW(AXP809, DC1SW, "dc1sw", NULL, AXP22X_PWR_OUT_CTRL2,
+		    BIT(7)),
+	/* LDO regulator internally chained to DCDC5 */
+	AXP_DESC(AXP809, DC5LDO, "dc5ldo", NULL, 700, 1400, 100,
+		 AXP22X_DC5LDO_V_OUT, 0x7, AXP22X_PWR_OUT_CTRL1, BIT(0)),
+	AXP_DESC(AXP809, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
+		 AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(6)),
+	AXP_DESC(AXP809, ALDO2, "aldo2", "aldoin", 700, 3300, 100,
+		 AXP22X_ALDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(7)),
+	AXP_DESC(AXP809, ALDO3, "aldo3", "aldoin", 700, 3300, 100,
+		 AXP22X_ALDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(5)),
+	AXP_DESC_RANGES(AXP809, DLDO1, "dldo1", "dldoin", axp809_dldo1_ranges,
+			32, AXP22X_DLDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2,
+			BIT(3)),
+	AXP_DESC(AXP809, DLDO2, "dldo2", "dldoin", 700, 3300, 100,
+		 AXP22X_DLDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(4)),
+	AXP_DESC(AXP809, ELDO1, "eldo1", "eldoin", 700, 3300, 100,
+		 AXP22X_ELDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(0)),
+	AXP_DESC(AXP809, ELDO2, "eldo2", "eldoin", 700, 3300, 100,
+		 AXP22X_ELDO2_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(1)),
+	AXP_DESC(AXP809, ELDO3, "eldo3", "eldoin", 700, 3300, 100,
+		 AXP22X_ELDO3_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(2)),
+	AXP_DESC_IO(AXP809, LDO_IO0, "ldo_io0", "ips", 700, 3300, 100,
+		    AXP22X_LDO_IO0_V_OUT, 0x1f, AXP20X_GPIO0_CTRL, 0x07,
+		    AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+	AXP_DESC_IO(AXP809, LDO_IO1, "ldo_io1", "ips", 700, 3300, 100,
+		    AXP22X_LDO_IO1_V_OUT, 0x1f, AXP20X_GPIO1_CTRL, 0x07,
+		    AXP22X_IO_ENABLED, AXP22X_IO_DISABLED),
+	AXP_DESC_FIXED(AXP809, RTC_LDO, "rtc_ldo", "ips", 1800),
+	AXP_DESC_SW(AXP809, SW, "sw", "swin", AXP22X_PWR_OUT_CTRL2, BIT(6)),
+};
+
 static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
 {
 	struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
@@ -239,6 +294,7 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
 		break;
 	case AXP221_ID:
 	case AXP223_ID:
+	case AXP809_ID:
 		min = 1800;
 		max = 4050;
 		def = 3000;
@@ -318,6 +374,7 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev *rdev, int id, u32 work
 
 	case AXP221_ID:
 	case AXP223_ID:
+	case AXP809_ID:
 		if (id < AXP22X_DCDC1 || id > AXP22X_DCDC5)
 			return -EINVAL;
 
@@ -346,8 +403,8 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 	};
 	int ret, i, nregulators;
 	u32 workmode;
-	const char *axp22x_dc1_name = axp22x_regulators[AXP22X_DCDC1].name;
-	const char *axp22x_dc5_name = axp22x_regulators[AXP22X_DCDC5].name;
+	const char *dcdc1_name = axp22x_regulators[AXP22X_DCDC1].name;
+	const char *dcdc5_name = axp22x_regulators[AXP22X_DCDC5].name;
 
 	switch (axp20x->variant) {
 	case AXP202_ID:
@@ -360,6 +417,10 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		regulators = axp22x_regulators;
 		nregulators = AXP22X_REG_ID_MAX;
 		break;
+	case AXP809_ID:
+		regulators = axp809_regulators;
+		nregulators = AXP809_REG_ID_MAX;
+		break;
 	default:
 		dev_err(&pdev->dev, "Unsupported AXP variant: %ld\n",
 			axp20x->variant);
@@ -382,22 +443,22 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		 * part of this loop to see where we save the DT defined
 		 * name.
 		 */
-		if (regulators == axp22x_regulators) {
-			if (i == AXP22X_DC1SW) {
-				new_desc = devm_kzalloc(&pdev->dev,
-							sizeof(*desc),
-							GFP_KERNEL);
-				*new_desc = regulators[i];
-				new_desc->supply_name = axp22x_dc1_name;
-				desc = new_desc;
-			} else if (i == AXP22X_DC5LDO) {
-				new_desc = devm_kzalloc(&pdev->dev,
-							sizeof(*desc),
-							GFP_KERNEL);
-				*new_desc = regulators[i];
-				new_desc->supply_name = axp22x_dc5_name;
-				desc = new_desc;
-			}
+		if ((regulators == axp22x_regulators && i == AXP22X_DC1SW) ||
+		    (regulators == axp809_regulators && i == AXP809_DC1SW)) {
+			new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
+						GFP_KERNEL);
+			*new_desc = regulators[i];
+			new_desc->supply_name = dcdc1_name;
+			desc = new_desc;
+		}
+
+		if ((regulators == axp22x_regulators && i == AXP22X_DC5LDO) ||
+		    (regulators == axp809_regulators && i == AXP809_DC5LDO)) {
+			new_desc = devm_kzalloc(&pdev->dev, sizeof(*desc),
+						GFP_KERNEL);
+			*new_desc = regulators[i];
+			new_desc->supply_name = dcdc5_name;
+			desc = new_desc;
 		}
 
 		rdev = devm_regulator_register(&pdev->dev, desc, &config);
@@ -420,17 +481,17 @@ static int axp20x_regulator_probe(struct platform_device *pdev)
 		/*
 		 * Save AXP22X DCDC1 / DCDC5 regulator names for later.
 		 */
-		if (regulators == axp22x_regulators) {
-			/* Can we use rdev->constraints->name instead? */
-			if (i == AXP22X_DCDC1)
-				of_property_read_string(rdev->dev.of_node,
-							"regulator-name",
-							&axp22x_dc1_name);
-			else if (i == AXP22X_DCDC5)
-				of_property_read_string(rdev->dev.of_node,
-							"regulator-name",
-							&axp22x_dc5_name);
-		}
+		if ((regulators == axp22x_regulators && i == AXP22X_DCDC1) ||
+		    (regulators == axp809_regulators && i == AXP809_DCDC1))
+			of_property_read_string(rdev->dev.of_node,
+						"regulator-name",
+						&dcdc1_name);
+
+		if ((regulators == axp22x_regulators && i == AXP22X_DCDC5) ||
+		    (regulators == axp809_regulators && i == AXP809_DCDC5))
+			of_property_read_string(rdev->dev.of_node,
+						"regulator-name",
+						&dcdc5_name);
 	}
 
 	return 0;
-- 
2.7.0



From marc.zyngier at arm.com  Mon Feb 15 02:34:18 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Feb 2016 10:34:18 +0000
Subject: [PATCH v4 00/23] arm64: Virtualization Host Extension support
In-Reply-To: <20160215102324.GD13683@e104818-lin.cambridge.arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
 <20160211190701.GA4842@cbox> <56BCDCBA.5080202@arm.com>
 <20160215102324.GD13683@e104818-lin.cambridge.arm.com>
Message-ID: <56C1A9AA.9040504@arm.com>

On 15/02/16 10:23, Catalin Marinas wrote:
> On Thu, Feb 11, 2016 at 07:10:50PM +0000, Marc Zyngier wrote:
>> On 11/02/16 19:07, Christoffer Dall wrote:
>>> On Thu, Feb 11, 2016 at 06:39:41PM +0000, Marc Zyngier wrote:
>>>> ARMv8.1 comes with the "Virtualization Host Extension" (VHE for
>>>> short), which enables simpler support of Type-2 hypervisors.
>>>>
>>>> This extension allows the kernel to directly run at EL2, and
>>>> significantly reduces the number of system registers shared between
>>>> host and guest, reducing the overhead of virtualization.
>>>>
>>>> In order to have the same kernel binary running on all versions of the
>>>> architecture, this series makes heavy use of runtime code patching.
>>>>
>>>> The first 22 patches massage the KVM code to deal with VHE and enable
>>>> Linux to run at EL2. The last patch catches an ugly case when VHE
>>>> capable CPUs are paired with some of their less capable siblings. This
>>>> should never happen, but hey...
>>>>
>>>> I have deliberately left out some of the more "advanced"
>>>> optimizations, as they are likely to distract the reviewer from the
>>>> core infrastructure, which is what I care about at the moment.
>>>>
>>>> Note: GDB is currently busted on VHE systems, as it checks for version
>>>>       6 on the debug architecture, while VHE is version 7. The
>>>>       binutils people are on the case.
>>>>
>>>> This has been tested on the FVP_Base_SLV-V8-A model, and based on
>>>> v4.5-rc3 + kvmarm/master. I've put a branch out on:
>>>>
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/vhe
>>>
>>> I'm happy with this series as it stands, we just need someone to take a
>>> look at that debug patch and be happy with it.
>>
>> I think Will is planning to have a go at it shortly. Once he and Catalin
>> are happy with the thing, I'll throw it into -next for a good shake.
> 
> Fine by me but it would be good for Will to have a look, especially on
> the debug and perf stuff.

Definitely. To make it clear, I do not intend to put anything in -next
until all the relevant people has reviewed it, and at least given their Ack.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From geert at linux-m68k.org  Mon Feb 15 02:35:36 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 11:35:36 +0100
Subject: ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8]
 arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)
In-Reply-To: <56C19044.6050604@arm.com>
References: <CAMuHMdU-q++XEgthKG=XOgnaq7TY899EsgMFHuWu4Skr5woLZg@mail.gmail.com>
 <56C19044.6050604@arm.com>
Message-ID: <CAMuHMdVcnbp8YMq9oNurvfe_9iNGOHYUVW=_=DzHY62Y0DLnQg@mail.gmail.com>

Hi Marc,

On Mon, Feb 15, 2016 at 9:45 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 15/02/16 08:16, Geert Uytterhoeven wrote:
>> On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>>> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland <mark.rutland at arm.com> wrote:
>>>> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
>>>>> On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland <mark.rutland at arm.com> wrote:
>>>>>>>> +           gic: interrupt-controller at 0xf1010000 {
>>>>>>> +                     compatible = "arm,gic-400";
>>>>>>> +                     #interrupt-cells = <3>;
>>>>>>> +                     #address-cells = <0>;
>>>>>>> +                     interrupt-controller;
>>>>>>> +                     reg = <0x0 0xf1010000 0 0x1000>,
>>>>>>> +                           <0x0 0xf1020000 0 0x2000>;
>>>>>>> +                     interrupts = <GIC_PPI 9
>>>>>>> +                                     (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
>>>>>>> +             };
>>>>>>
>>>>>> No GICH and GICV?
>>>>>
>>>>> These seem to be defined in the "arm,gic-v3" DT bindings only, while this is
>>>>> an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>>>>
>>>> See the "GIC virtualization extensions (VGIC)" section in
>>>> Documentation/devicetree/bindings/arm/gic.txt
>>>
>>> DDI0471B_gic400_r0p1_trm.pdf says:
>>>
>>>     Address range GIC-400 functional block
>>>     A. 0x0000 - 0x0FFF Reserved
>>>     B. 0x1000 - 0x1FFF Distributor
>>>     C. 0x2000 - 0x3FFF CPU interfaces
>>>     D. 0x4000 - 0x4FFF Virtual interface control block, for the processor that
>>>                        is performing the access
>>>     E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
>>>                        selected by address bits [11:9]
>>>     F. 0x6000 - 0x7FFF Virtual CPU interfaces
>>>
>>> The DT binding document says:
>>>   1. The  first region is the GIC distributor register base and size.
>>>   2. The 2nd region is the GIC cpu interface register base and size.
>>>   3. The first additional region is the GIC virtual interface control register
>>>      base and size.
>>>   4. The 2nd additional region is the GIC virtual cpu interface register base
>>>      and size.
>>>
>>> Matching with the example:
>>>
>>>         interrupt-controller at 2c001000 {
>>>                 compatible = "arm,cortex-a15-gic";
>>>                 #interrupt-cells = <3>;
>>>                 interrupt-controller;
>>>                 reg = <0x2c001000 0x1000>,
>>>                       <0x2c002000 0x1000>,
>>>                       <0x2c004000 0x2000>,
>>>                       <0x2c006000 0x2000>;
>>>                 interrupts = <1 9 0xf04>;
>>>         };
>>>
>>> This means:
>>>   - reg entry 1. covers address range B,
>>>   - reg entry 2. covers address range C,
>>>   - reg entry 3. covers address ranges D _and_ E,
>>>   - reg entry 4. covers address range F.
>>>
>>> On R-Car Gen3, the base addresses are:
>>>
>>>     Distributor             : 0xF101_0000
>>>     CPU interfaces          : 0xF102_0000
>>>     Virtual interfaces      : 0xF104_0000
>>>     Virtual interfaces      : 0xF105_0000
>>>     Virtual CPU interfaces  : 0xF106_0000
>>>
>>> Note the additional multiplication factor of 16 in the offsets relative to
>>> the base address 0xf1000000 (e.g. 0x50000 instead of 0x5000).
>>>
>>> As address ranges D and E are merged in a single reg entry, how is the GIC
>>> driver supposed to know about this multiplication factor?
>
> The answer is very simple, the GIC driver doesn't give a damn about the
> second part of the GICH region, because it is absolutely unusable for
> any realistic use-case. Only the banked version of GICH is of any
> relevance (the first 512 bytes, in essence).
>
> Aligning the GIC regions on 64kB boundaries is documented in the SBSA
> specification, independently of the GIC400 documentation.

If I understand the SBSA spec correctly (BTW, arm,gic.txt doesn't use the
"GICC" terminology, unlike arm,gic-v3.txt), that means reg entry 3 should be
"<0xf104f000 0x2000>", so it covers the aliased last 4 KiB of address range D,
and the first 4 KiB of address range E. I.e.

                        reg = <0x0 0xf1010000 0 0x1000>,
                             <0x0 0xf1020000 0 0x2000>,
                             <0x0 0xf104f000 0 0x2000>,
                             <0x0 0xf1060000 0 0x2000>;

Is that correct?

Thanks again!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From laurentiu.tudor at nxp.com  Mon Feb 15 02:42:28 2016
From: laurentiu.tudor at nxp.com (Laurentiu Tudor)
Date: Mon, 15 Feb 2016 10:42:28 +0000
Subject: [PATCH v3 0/4] arm64: avoid early __va translations
In-Reply-To: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <56C1AB93.3020101@nxp.com>

Hi Ard,

On 02/12/2016 04:57 PM, Ard Biesheuvel wrote:
> This is a somewhat cleaner approach for dealing with the issue that the
> early FDT performs __va() translations before the linear mapping has been
> set up. Being able to defer the assignment of memstart_addr until after we
> have discovered all of memory is an important piece of functionality, not
> only for KASLR but also for mapping the linear region as efficiently as
> possible.
> 
> Changes since v2:
> - replace __weak function in patches #1 and #2 with a preprocessor macro
> - add patch to address the circular header dependency when including
>   asm/bug.h in asm/memory.h
> - turned the hack that adds the BUG_ON() into a proper patch
> 
> Patch #1 refactors the early FDT code so that the actual assignment of
> initrd_start and initrd_end (which is where the __va() translations are
> performed) can be overridden in architecture specific code.
> 
> Patch #2 performs the override, and only records the physical addresses
> as they are found in the /chosen node, or on the command line, and defers
> the __va() translation until after memstart_addr has been assigned.
> 
> Patch #3 reshuffles some #includes and #defines so that asm/bug.h can be
> included (and used) in asm/memory.h
> 
> Patch #4 implements a BUG_ON() check to ensure that no references to
> memstart_addr are made before it has been assigned.
> 
> Ard Biesheuvel (4):
>   of/fdt: factor out assignment of initrd_start/initrd_end
>   arm64: defer __va translation of initrd_start and initrd_end
>   arm64: prevent potential circular header dependencies in asm/bug.h
>   arm64: prevent __va() translations before memstart_addr is assigned
> 
>  arch/arm64/include/asm/bug.h            |  2 +-
>  arch/arm64/include/asm/debug-monitors.h |  2 +-
>  arch/arm64/include/asm/memory.h         | 12 ++++++++++-
>  arch/arm64/kvm/hyp/debug-sr.c           |  1 +
>  arch/arm64/mm/init.c                    | 21 +++++++++++++++-----
>  drivers/of/fdt.c                        | 14 ++++++++++---
>  6 files changed, 41 insertions(+), 11 deletions(-)

Tried these on one of our LS2 boards so here's a:

Tested-by: Laurentiu Tudor <laurentiu.tudor at nxp.com>

---
Best Regards, Laurentiu


From djkurtz at chromium.org  Mon Feb 15 02:42:48 2016
From: djkurtz at chromium.org (Daniel Kurtz)
Date: Mon, 15 Feb 2016 18:42:48 +0800
Subject: [PATCH v4 4/8] dt-bindings: Add a binding for Mediatek Video
 Encoder
In-Reply-To: <CAGS+omDQW+yqhixCWPfQb9eaHeufgiEDscrvXGwBTc05+eDGCQ@mail.gmail.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <CAGS+omDQW+yqhixCWPfQb9eaHeufgiEDscrvXGwBTc05+eDGCQ@mail.gmail.com>
Message-ID: <CAGS+omAkM97TOnJX-ahEMeN8zO1R2RO43LWqeFFRDuj7gM5CzA@mail.gmail.com>

On Tue, Feb 9, 2016 at 7:29 PM, Daniel Kurtz <djkurtz at chromium.org> wrote:
> Hi Tiffany,
>
> On Thu, Feb 4, 2016 at 7:34 PM, Tiffany Lin <tiffany.lin at mediatek.com> wrote:
>> Add a DT binding documentation of Video Encoder for the
>> MT8173 SoC from Mediatek.
>>
>> Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
>> ---
>>  .../devicetree/bindings/media/mediatek-vcodec.txt  |   59 ++++++++++++++++++++
>>  1 file changed, 59 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
>> new file mode 100644
>> index 0000000..572bfdd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
>> @@ -0,0 +1,59 @@
>> +Mediatek Video Codec
>> +
>> +Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
>> +supports high resolution encoding functionalities.
>> +
>> +Required properties:
>> +- compatible : "mediatek,mt8173-vcodec-enc" for encoder
>> +- reg : Physical base address of the video codec registers and length of
>> +  memory mapped region.
>> +- interrupts : interrupt number to the cpu.
>> +- mediatek,larb : must contain the local arbiters in the current Socs.
>> +- clocks : list of clock specifiers, corresponding to entries in
>> +  the clock-names property.
>> +- clock-names: encoder must contain "vencpll_d2", "venc_sel", "univpll1_d2",
>> +  "venc_lt_sel".
>> +- iommus : should point to the respective IOMMU block with master port as
>> +  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>> +  for details.
>> +- mediatek,vpu : the node of video processor unit
>> +
>> +Example:
>> +vcodec_enc: vcodec at 0x18002000 {
>> +    compatible = "mediatek,mt8173-vcodec-enc";
>> +    reg = <0 0x18002000 0 0x1000>,    /*VENC_SYS*/
>> +          <0 0x19002000 0 0x1000>;    /*VENC_LT_SYS*/
>
> This really looks like two encoder devices combined into a single
> device tree node.
> There are two register sets, two irqs, two sets of iommus, and two
> sets of clocks.
>
> If possible, please split this node into two, one for each encoder.

I chatted offline with Mediatek.  They explained that there really is
just one encoder hardware, that happens to support multiple formats.
The encoder cannot encode with both formats at the same time.  The
Mediatek HW designers added a new format to an existing encoder by
adding a second interface (register set, irq, iommus, clocks) without
modifying the original interface.  However in the hardware itself
there is really just one encoder device.

So, although this node looks like it is for two encoder devices (one
for each format), really there is just one device that supports each
format through its large interface.

So, I'm fine with this being a single device node.

>> +    interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>,
>> +           <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>;
>> +    mediatek,larb = <&larb3>,
>> +                   <&larb5>;
>> +    iommus = <&iommu M4U_PORT_VENC_RCPU>,
>> +             <&iommu M4U_PORT_VENC_REC>,
>> +             <&iommu M4U_PORT_VENC_BSDMA>,
>> +             <&iommu M4U_PORT_VENC_SV_COMV>,
>> +             <&iommu M4U_PORT_VENC_RD_COMV>,
>> +             <&iommu M4U_PORT_VENC_CUR_LUMA>,
>> +             <&iommu M4U_PORT_VENC_CUR_CHROMA>,
>> +             <&iommu M4U_PORT_VENC_REF_LUMA>,
>> +             <&iommu M4U_PORT_VENC_REF_CHROMA>,
>> +             <&iommu M4U_PORT_VENC_NBM_RDMA>,
>> +             <&iommu M4U_PORT_VENC_NBM_WDMA>,
>> +             <&iommu M4U_PORT_VENC_RCPU_SET2>,
>> +             <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
>> +             <&iommu M4U_PORT_VENC_BSDMA_SET2>,
>> +             <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
>> +             <&iommu M4U_PORT_VENC_RD_COMA_SET2>,
>> +             <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
>> +             <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
>> +             <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
>> +             <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
>> +    mediatek,vpu = <&vpu>;
>> +    clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
>> +             <&topckgen CLK_TOP_VENC_SEL>,
>> +             <&topckgen CLK_TOP_UNIVPLL1_D2>,
>> +             <&topckgen CLK_TOP_VENC_LT_SEL>;
>> +    clock-names = "vencpll_d2",
>> +                  "venc_sel",
>> +                  "univpll1_d2",
>> +                  "venc_lt_sel";
>
> The names of these clocks should be from the perspective of the
> encoder, not the clock provider.

I still think these clock names should be updated, however.

-Dan


From marc.zyngier at arm.com  Mon Feb 15 02:55:04 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Feb 2016 10:55:04 +0000
Subject: ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8]
 arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)
In-Reply-To: <CAMuHMdVcnbp8YMq9oNurvfe_9iNGOHYUVW=_=DzHY62Y0DLnQg@mail.gmail.com>
References: <CAMuHMdU-q++XEgthKG=XOgnaq7TY899EsgMFHuWu4Skr5woLZg@mail.gmail.com>
 <56C19044.6050604@arm.com>
 <CAMuHMdVcnbp8YMq9oNurvfe_9iNGOHYUVW=_=DzHY62Y0DLnQg@mail.gmail.com>
Message-ID: <56C1AE88.9050708@arm.com>

On 15/02/16 10:35, Geert Uytterhoeven wrote:
> Hi Marc,
> 
> On Mon, Feb 15, 2016 at 9:45 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> On 15/02/16 08:16, Geert Uytterhoeven wrote:
>>> On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>>>> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland <mark.rutland at arm.com> wrote:
>>>>> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
>>>>>> On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland <mark.rutland at arm.com> wrote:
>>>>>>>>> +           gic: interrupt-controller at 0xf1010000 {
>>>>>>>> +                     compatible = "arm,gic-400";
>>>>>>>> +                     #interrupt-cells = <3>;
>>>>>>>> +                     #address-cells = <0>;
>>>>>>>> +                     interrupt-controller;
>>>>>>>> +                     reg = <0x0 0xf1010000 0 0x1000>,
>>>>>>>> +                           <0x0 0xf1020000 0 0x2000>;
>>>>>>>> +                     interrupts = <GIC_PPI 9
>>>>>>>> +                                     (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
>>>>>>>> +             };
>>>>>>>
>>>>>>> No GICH and GICV?
>>>>>>
>>>>>> These seem to be defined in the "arm,gic-v3" DT bindings only, while this is
>>>>>> an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>>>>>
>>>>> See the "GIC virtualization extensions (VGIC)" section in
>>>>> Documentation/devicetree/bindings/arm/gic.txt
>>>>
>>>> DDI0471B_gic400_r0p1_trm.pdf says:
>>>>
>>>>     Address range GIC-400 functional block
>>>>     A. 0x0000 - 0x0FFF Reserved
>>>>     B. 0x1000 - 0x1FFF Distributor
>>>>     C. 0x2000 - 0x3FFF CPU interfaces
>>>>     D. 0x4000 - 0x4FFF Virtual interface control block, for the processor that
>>>>                        is performing the access
>>>>     E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
>>>>                        selected by address bits [11:9]
>>>>     F. 0x6000 - 0x7FFF Virtual CPU interfaces
>>>>
>>>> The DT binding document says:
>>>>   1. The  first region is the GIC distributor register base and size.
>>>>   2. The 2nd region is the GIC cpu interface register base and size.
>>>>   3. The first additional region is the GIC virtual interface control register
>>>>      base and size.
>>>>   4. The 2nd additional region is the GIC virtual cpu interface register base
>>>>      and size.
>>>>
>>>> Matching with the example:
>>>>
>>>>         interrupt-controller at 2c001000 {
>>>>                 compatible = "arm,cortex-a15-gic";
>>>>                 #interrupt-cells = <3>;
>>>>                 interrupt-controller;
>>>>                 reg = <0x2c001000 0x1000>,
>>>>                       <0x2c002000 0x1000>,
>>>>                       <0x2c004000 0x2000>,
>>>>                       <0x2c006000 0x2000>;
>>>>                 interrupts = <1 9 0xf04>;
>>>>         };
>>>>
>>>> This means:
>>>>   - reg entry 1. covers address range B,
>>>>   - reg entry 2. covers address range C,
>>>>   - reg entry 3. covers address ranges D _and_ E,
>>>>   - reg entry 4. covers address range F.
>>>>
>>>> On R-Car Gen3, the base addresses are:
>>>>
>>>>     Distributor             : 0xF101_0000
>>>>     CPU interfaces          : 0xF102_0000
>>>>     Virtual interfaces      : 0xF104_0000
>>>>     Virtual interfaces      : 0xF105_0000
>>>>     Virtual CPU interfaces  : 0xF106_0000
>>>>
>>>> Note the additional multiplication factor of 16 in the offsets relative to
>>>> the base address 0xf1000000 (e.g. 0x50000 instead of 0x5000).
>>>>
>>>> As address ranges D and E are merged in a single reg entry, how is the GIC
>>>> driver supposed to know about this multiplication factor?
>>
>> The answer is very simple, the GIC driver doesn't give a damn about the
>> second part of the GICH region, because it is absolutely unusable for
>> any realistic use-case. Only the banked version of GICH is of any
>> relevance (the first 512 bytes, in essence).
>>
>> Aligning the GIC regions on 64kB boundaries is documented in the SBSA
>> specification, independently of the GIC400 documentation.
> 
> If I understand the SBSA spec correctly (BTW, arm,gic.txt doesn't use the
> "GICC" terminology, unlike arm,gic-v3.txt), that means reg entry 3 should be
> "<0xf104f000 0x2000>", so it covers the aliased last 4 KiB of address range D,
> and the first 4 KiB of address range E. I.e.
> 
>                         reg = <0x0 0xf1010000 0 0x1000>,
>                              <0x0 0xf1020000 0 0x2000>,
>                              <0x0 0xf104f000 0 0x2000>,
>                              <0x0 0xf1060000 0 0x2000>;
> 
> Is that correct?

My preference would be to expose the full 128kB of the region - assuming
your HW actually supports the SBSA aliasing.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From thomas.petazzoni at free-electrons.com  Mon Feb 15 02:58:34 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 15 Feb 2016 11:58:34 +0100
Subject: [PATCH] dma: mv_xor_v2: new driver
In-Reply-To: <56C1A17F.9030206@arm.com>
References: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <201602151735.BaFwBMOn%fengguang.wu@intel.com>
 <20160215105008.74aa7869@free-electrons.com>
 <56C1A17F.9030206@arm.com>
Message-ID: <20160215115834.60f4e559@free-electrons.com>

Hello,

On Mon, 15 Feb 2016 09:59:27 +0000, Marc Zyngier wrote:

> Seems like something is selecting GENERIC_MSI_IRQ_DOMAIN on a system
> that doesn't implement the required bits.
> 
> It may be that we need to implement something like
> HAS_GENERIC_MSI_IRQ_DOMAIN, and make GENERIC_MSI_IRQ_DOMAIN conditional
> on that. Or just whitelist the architectures that do implement this.
> 
> Any chance you could have a closer look?

I'll have a look. However, in the mean time, I will probably make this
new driver depend on ARM64 so that it does not depend on other patches
touching the MSI mechanism.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From u.kleine-koenig at pengutronix.de  Mon Feb 15 02:59:09 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Mon, 15 Feb 2016 11:59:09 +0100
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160214165010.GA3189@roeck-us.net>
References: <20160214165010.GA3189@roeck-us.net>
Message-ID: <20160215105909.GH12289@pengutronix.de>

Hello Guenter,

On Sun, Feb 14, 2016 at 08:50:10AM -0800, Guenter Roeck wrote:
> Uwe,
> 
> Your patch 'driver-core: platform: probe of-devices only using list of
> compatibles' causes the following qemu tests to crash in -next.
> 
> arm:vexpress-a9:vexpress_defconfig:vexpress-v2p-ca9
> arm:vexpress-a15:vexpress_defconfig:vexpress-v2p-ca15-tc1
> arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
> arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
> 
> Crash log:
> 
> VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6
> Please append a correct "root=" boot option; here are the available partitions:
> 1f00          131072 mtdblock0  (driver?)
> 1f01           32768 mtdblock1  (driver?)
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Can you provide a complete boot log? This might already reveal which
device is failing. It might not be the mmci device but something it
depends on (clock, bus parent, irq).

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From sergei.shtylyov at cogentembedded.com  Mon Feb 15 02:59:38 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Mon, 15 Feb 2016 13:59:38 +0300
Subject: [PATCH] ARM: dts: porter: add MAX3355 support
In-Reply-To: <20160215014527.GE12997@verge.net.au>
References: <1674850.BZpGW9kEud@wasted.cogentembedded.com>
 <4506196.xOgpYRO52t@wasted.cogentembedded.com>
 <SG2PR06MB0919D09C1146EAC0681EE109D8DA0@SG2PR06MB0919.apcprd06.prod.outlook.com>
 <56ABCB69.1070800@cogentembedded.com> <56ABD066.7020804@cogentembedded.com>
 <SG2PR06MB0919361DC5805AE3F5B74041D8DE0@SG2PR06MB0919.apcprd06.prod.outlook.com>
 <56AF9BE8.4020002@cogentembedded.com> <56AFAB67.20404@cogentembedded.com>
 <20160215014527.GE12997@verge.net.au>
Message-ID: <56C1AF9A.5070401@cogentembedded.com>

On 2/15/2016 4:45 AM, Simon Horman wrote:

>>>>>>>> Now that Maxim Integrated MAX3355 'extcon' driver and device tree bindings
>>>>>>>> are upstream along with the 'extcon' hook  in the Renesas USBHS driver, we
>>>>>>>> can add  MAX3355 device node to  the Porter device tree and properly refer
>>>>>>>> to it from the USBHS node instead of using  "renesas,enable-gpio" property
>>>>>>>> which only allowed checking the USB ID pin  at the driver probe time;  now
>>>>>>>> this  pin's  state can be monitored dynamically!
>>>>>>>>
>>>>>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>>>>>>>
>>>>>>> I tested this patch on Porter, but interrupt of "usb-otg" didn't happened
>>>>>>> even if I connected/disconnected a usb convert cable (usb micro-ab to A).
>>>>>>> Remarks: I confirmed that the usb convert cable worked correctly on other
>>>>>>> board.
>>>>>>
>>>>>>      I guess I have the same cable
>>>>>
>>>>>      No, I have mini-AB connector here and hence my cable is mini-AB to A.
>>>>
>>>> I checked Porter specification and then I found 2 specifications exist...
>>>
>>>     I've looked thru my schematics files and found 3: Rev. 1.1 Update Version
>>> 2, "PORTER_2" Rev. 3.0 Preliminary, and "PORTER_C" Rev. 3.0 Release version!
>>> I'm not sure which of the last 2 should be considered final...
>>
>>     Now I've found 5 versions of the Porter schematics... :-)
>>
>>>>   Porter "B" : mini AB connecter and Max3355 is on the board.
>>>>   Porter "C" : micro AB connect and Max3355 is not on the board. (Select
>>>> host/peripheral by a jumper.)
>>>
>>>     Yeah, seeing JP13 in the PORTER_C schematics.
>>>
>>>> I guess that your current target is "B".
>>>
>>>     If not earlier. It actually has "Henninger B REV2" printed on it and
>>> "Porter PCB 1 R3" on a pasted sticker.
>>>
>>>> If so, I think this patch is acceptable.
>>>
>>>     I'm not so sure now...
>>
>>     My boss told me PORTER_C is a final version, so this patch isn't needed.
>> But then another patch is needed instead: to remove "renesas,enable-gpio"
>> prop from the HS-USB device node...
>
> I am marking this patch as "Rejected" in patchwork.
> If changes are required in this area please either
> resubmit this patch or post a different one.

    Posted a different one on Saturday.

> Thanks.

MBR, Sergei



From ykk at rock-chips.com  Mon Feb 15 03:01:11 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:01:11 +0800
Subject: [PATCH 0/2] Add Rockchip display port phy driver support
Message-ID: <1455534071-31230-1-git-send-email-ykk@rock-chips.com>


Hi Kison,

This series is splited from Analogix DP DRM thread [0], and Heiko suggest this
should be an independent thread which may be easy for you to apply.

Best regards,
Yakir

[0]: https://patchwork.kernel.org/patch/8086571/


Changes in v12:
- Re-order the include headers file alphabetically in phy-rockchip-dp.c (Jingoo)

Changes in v11:
- Correct the title of this rockchip dp phy document(Rob)
- Add the ack from Rob Herring

Changes in v10:
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
    BIT(4) -> BIT(20)

Changes in v9:
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.

Changes in v8:
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
- Remove the specific address in the example node name. (Heiko)

Changes in v7:
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)
- Simplify the commit message. (Kishon)

Changes in v5:
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
  the exist "grf" syscon already. And rename the example DT node from
  "edp_phy: phy at ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
  struct" to "static const struct". And correct the input paramters of
  devm_phy_create() interfaces. (Heiko)
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
  elemets in document. (Rob & Heiko)

Changes in v4:
- Add commit message, and remove the redundant rockchip_dp_phy_init()
  function, move those code to probe() method. And remove driver .owner
  number. (Kishon)

Changes in v3:
- Suggest, add rockchip dp phy driver, collect the phy clocks and
  power control. (Heiko)

Yakir Yang (2):
  phy: Add driver for rockchip Display Port PHY
  dt-bindings: add document for rockchip dp phy

 .../devicetree/bindings/phy/rockchip-dp-phy.txt    |  22 +++
 drivers/phy/Kconfig                                |   7 +
 drivers/phy/Makefile                               |   1 +
 drivers/phy/phy-rockchip-dp.c                      | 151 +++++++++++++++++++++
 4 files changed, 181 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
 create mode 100644 drivers/phy/phy-rockchip-dp.c

-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:01:34 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:01:34 +0800
Subject: [PATCH 1/2] phy: Add driver for rockchip Display Port PHY
In-Reply-To: <1455534071-31230-1-git-send-email-ykk@rock-chips.com>
References: <1455534071-31230-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534094-31282-1-git-send-email-ykk@rock-chips.com>

Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko at sntech.de>
---
Changes in v12:
- Re-order the include headers file alphabetically in phy-rockchip-dp.c (Jingoo)

Changes in v11: None
Changes in v10:
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
    BIT(4) -> BIT(20)

Changes in v9:
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.

Changes in v8:
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)

Changes in v7:
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)

Changes in v5:
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
  the exist "grf" syscon already. And rename the example DT node from
  "edp_phy: phy at ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
  struct" to "static const struct". And correct the input paramters of
  devm_phy_create() interfaces. (Heiko)

Changes in v4:
- Add commit message, and remove the redundant rockchip_dp_phy_init()
  function, move those code to probe() method. And remove driver .owner
  number. (Kishon)

Changes in v3:
- Suggest, add rockchip dp phy driver, collect the phy clocks and
  power control. (Heiko)

 drivers/phy/Kconfig           |   7 ++
 drivers/phy/Makefile          |   1 +
 drivers/phy/phy-rockchip-dp.c | 151 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 159 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-dp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index e7e117d..925e82c4 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -336,6 +336,13 @@ config PHY_ROCKCHIP_USB
 	help
 	  Enable this to support the Rockchip USB 2.0 PHY.
 
+config PHY_ROCKCHIP_DP
+	tristate "Rockchip Display Port PHY Driver"
+	depends on ARCH_ROCKCHIP && OF
+	select GENERIC_PHY
+	help
+	  Enable this to support the Rockchip Display Port PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
 	tristate "ST SPEAR1310-MIPHY driver"
 	select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index c80f09d..081479a 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -37,6 +37,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)	+= phy-s5pv210-usb2.o
 obj-$(CONFIG_PHY_EXYNOS5_USBDRD)	+= phy-exynos5-usbdrd.o
 obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)	+= phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP)		+= phy-rockchip-dp.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)	+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)	+= phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)	+= phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 0000000..88f09ec
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,151 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang <ykk@@rock-chips.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include <linux/clk.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#define GRF_SOC_CON12                           0x0274
+
+#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK   BIT(20)
+#define GRF_EDP_REF_CLK_SEL_INTER               BIT(4)
+
+#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK           BIT(21)
+#define GRF_EDP_PHY_SIDDQ_ON                    0
+#define GRF_EDP_PHY_SIDDQ_OFF                   BIT(5)
+
+struct rockchip_dp_phy {
+	struct device  *dev;
+	struct regmap  *grf;
+	struct clk     *phy_24m;
+};
+
+static int rockchip_set_phy_state(struct phy *phy, bool enable)
+{
+	struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
+	int ret;
+
+	if (enable) {
+		ret = regmap_write(dp->grf, GRF_SOC_CON12,
+				   GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+				   GRF_EDP_PHY_SIDDQ_ON);
+		if (ret < 0) {
+			dev_err(dp->dev, "Can't enable PHY power %d\n", ret);
+			return ret;
+		}
+
+		ret = clk_prepare_enable(dp->phy_24m);
+	} else {
+		clk_disable_unprepare(dp->phy_24m);
+
+		ret = regmap_write(dp->grf, GRF_SOC_CON12,
+				   GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+				   GRF_EDP_PHY_SIDDQ_OFF);
+	}
+
+	return ret;
+}
+
+static int rockchip_dp_phy_power_on(struct phy *phy)
+{
+	return rockchip_set_phy_state(phy, true);
+}
+
+static int rockchip_dp_phy_power_off(struct phy *phy)
+{
+	return rockchip_set_phy_state(phy, false);
+}
+
+static const struct phy_ops rockchip_dp_phy_ops = {
+	.power_on	= rockchip_dp_phy_power_on,
+	.power_off	= rockchip_dp_phy_power_off,
+	.owner		= THIS_MODULE,
+};
+
+static int rockchip_dp_phy_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct phy_provider *phy_provider;
+	struct rockchip_dp_phy *dp;
+	struct phy *phy;
+	int ret;
+
+	if (!np)
+		return -ENODEV;
+
+	dp = devm_kzalloc(dev, sizeof(*dp), GFP_KERNEL);
+	if (IS_ERR(dp))
+		return -ENOMEM;
+
+	dp->dev = dev;
+
+	dp->phy_24m = devm_clk_get(dev, "24m");
+	if (IS_ERR(dp->phy_24m)) {
+		dev_err(dev, "cannot get clock 24m\n");
+		return PTR_ERR(dp->phy_24m);
+	}
+
+	ret = clk_set_rate(dp->phy_24m, 24000000);
+	if (ret < 0) {
+		dev_err(dp->dev, "cannot set clock phy_24m %d\n", ret);
+		return ret;
+	}
+
+	dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+	if (IS_ERR(dp->grf)) {
+		dev_err(dev, "rk3288-dp needs rockchip,grf property\n");
+		return PTR_ERR(dp->grf);
+	}
+
+	ret = regmap_write(dp->grf, GRF_SOC_CON12, GRF_EDP_REF_CLK_SEL_INTER |
+			   GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK);
+	if (ret != 0) {
+		dev_err(dp->dev, "Could not config GRF edp ref clk: %d\n", ret);
+		return ret;
+	}
+
+	phy = devm_phy_create(dev, np, &rockchip_dp_phy_ops);
+	if (IS_ERR(phy)) {
+		dev_err(dev, "failed to create phy\n");
+		return PTR_ERR(phy);
+	}
+	phy_set_drvdata(phy, dp);
+
+	phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+
+	return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id rockchip_dp_phy_dt_ids[] = {
+	{ .compatible = "rockchip,rk3288-dp-phy" },
+	{}
+};
+
+MODULE_DEVICE_TABLE(of, rockchip_dp_phy_dt_ids);
+
+static struct platform_driver rockchip_dp_phy_driver = {
+	.probe		= rockchip_dp_phy_probe,
+	.driver		= {
+		.name	= "rockchip-dp-phy",
+		.of_match_table = rockchip_dp_phy_dt_ids,
+	},
+};
+
+module_platform_driver(rockchip_dp_phy_driver);
+
+MODULE_AUTHOR("Yakir Yang <ykk at rock-chips.com>");
+MODULE_DESCRIPTION("Rockchip DP PHY driver");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:01:43 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:01:43 +0800
Subject: [PATCH 2/2] dt-bindings: add document for rockchip dp phy
In-Reply-To: <1455534071-31230-1-git-send-email-ykk@rock-chips.com>
References: <1455534071-31230-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534103-31333-1-git-send-email-ykk@rock-chips.com>

Add dt binding documentation for rockchip display port PHY.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
Acked-by: Rob Herring <robh at kernel.org>
Reviewed-by: Heiko Stuebner <heiko at sntech.de>
---
Changes in v12: None
Changes in v11:
- Correct the title of this rockchip dp phy document(Rob)
- Add the ack from Rob Herring

Changes in v10: None
Changes in v9: None
Changes in v8:
- Remove the specific address in the example node name. (Heiko)

Changes in v7:
- Simplify the commit message. (Kishon)

Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
  elemets in document. (Rob & Heiko)

Changes in v4: None
Changes in v3: None

 .../devicetree/bindings/phy/rockchip-dp-phy.txt    | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 0000000..50c4f9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,22 @@
+Rockchip specific extensions to the Analogix Display Port PHY
+------------------------------------
+
+Required properties:
+- compatible : should be one of the following supported values:
+	 - "rockchip.rk3288-dp-phy"
+- clocks: from common clock binding: handle to dp clock.
+	of memory mapped region.
+- clock-names: from common clock binding:
+	Required elements: "24m"
+- rockchip,grf: phandle to the syscon managing the "general register files"
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: edp-phy {
+	compatible = "rockchip,rk3288-dp-phy";
+	rockchip,grf = <&grf>;
+	clocks = <&cru SCLK_EDP_24M>;
+	clock-names = "24m";
+	#phy-cells = <0>;
+};
-- 
1.9.1




From gregory.clement at free-electrons.com  Mon Feb 15 03:06:34 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Mon, 15 Feb 2016 12:06:34 +0100
Subject: [PATCH 1/3] clk: unconditionally recurse into clk/mvebu/
In-Reply-To: <CAPv3WKdnFg6AYNGexyEvMEjKmHadj4+CH5avnd=5d_HEKCTc2A@mail.gmail.com>
 (Marcin Wojtas's message of "Mon, 15 Feb 2016 09:33:26 +0100")
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455521698-7905-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <CAPv3WKdnFg6AYNGexyEvMEjKmHadj4+CH5avnd=5d_HEKCTc2A@mail.gmail.com>
Message-ID: <87si0uutad.fsf@free-electrons.com>

Hi Marcin,
 
 On lun., f?vr. 15 2016, Marcin Wojtas <mw at semihalf.com> wrote:

> Hi Thomas,
>
>
>
> 2016-02-15 8:34 GMT+01:00 Thomas Petazzoni
> <thomas.petazzoni at free-electrons.com>:
>> The drivers/clk/mvebu directory is only being built when
>> CONFIG_PLAT_ORION=y. As we are going to support additional mvebu
>> platforms in drivers/clk/mvebu, which don't have CONFIG_PLAT_ORION=y,
>> we need to recurse into this directory regardless of the value of
>> CONFIG_PLAT_ORION.
>>
>> Since all files in drivers/clk/mvebu/ are already conditionally
>> compiled depending on various Kconfig options, we can recurse
>> unconditionally into drivers/clk/mvebu without any other change.
>>
>> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>> ---
>>  drivers/clk/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
>> index b038e36..e08bb0e 100644
>> --- a/drivers/clk/Makefile
>> +++ b/drivers/clk/Makefile
>> @@ -61,7 +61,7 @@ obj-$(CONFIG_ARCH_MEDIATEK)           += mediatek/
>>  ifeq ($(CONFIG_COMMON_CLK), y)
>>  obj-$(CONFIG_ARCH_MMP)                 += mmp/
>>  endif
>> -obj-$(CONFIG_PLAT_ORION)               += mvebu/
>> +obj-y                                  += mvebu/
>
> I know it works with obj-y, but how about using
> obj-$(CONFIG_ARCH_MVEBU)? A person editing this Kconfig in future
> wouldn't have to run git blame in order to ensure with your commit
> log, that he doesn't compile anything more than planned.

I think it is still possible to have CONFIG_PLAT_ORION selected without
having CONFIG_ARCH_MVEBU. So for your concern, adding a comment would be
enough.

Gregory


>
> Best regards,
> Marcin

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From ykk at rock-chips.com  Mon Feb 15 03:08:05 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:08:05 +0800
Subject: [PATCH v14 0/17] Add Analogix Core Display Port Driver
Message-ID: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>


Hi all,

  The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM

But there are still three light registers setting different between
exynos and rk3288.
1. RK3288 have five special pll registers which not indicate in exynos
   dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
   between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
   register).

Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
okay to use the ATOMIC helpers functions in connector_funcs. No need to splict
the connector init to platform driver anymore, and this is the biggest change
since version 11.

This v14 didn't have lots of new changes which seems not the correct time to
upgrade the version number, but I have changed ordering of patches (adding 2
more, and removing 2 out). Especially to prevent confusing people, so I updated
the whole series.

Thanks,
- Yakir


Changes in v14:
- Rebase the new changes in imx-dp driver
- Split up this patch into 3 parts, make this easy to review (Heiko)
- Remove the Rockchip DP PHY to an separate thread (Heiko)
    https://patchwork.kernel.org/patch/8312701/

Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function. (Heiko)

Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper (Heiko)
- Add the ack from Jingoo
- Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h (Jingoo)

Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
	drm/exynos: do not start enabling DP at bind() phase
  Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
  the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
- Add the ack from Rob Herring
- Remove the surplus "plat_data" check. (Heiko)
-       switch (dp->plat_data && dp->plat_data->dev_type) {
+       switch (dp->plat_data->dev_type) {

Changes in v9:
- Document more details for 'ports' property.

Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)

Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
  compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
  to avoid -EOVERFLOW error (Krzysztof)

Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
-       hpd-gpio = <&gpx2 6 0>;
+       hpd-gpios = <&gpx2 6 0>;

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
  the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
  attch function. Cause once platform failed at attach, core driver should
  still failed, so no need to init connector before platform attached (Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
  patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
    -		analogix_dp_write_byte_to_dpcd(
    - 				dp, DP_TEST_RESPONSE,
    +		analogix_dp_write_byte_to_dpcd(dp,
    +				DP_TEST_RESPONSE,
				DP_TEST_EDID_CHECKSUM_WRITE);
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
  to get the backword timing values. Krzysztof suggest me that driver could use
  the "of_property_read_bool" to get backword timing values, but that interfacs
  would modify the original drm_display_mode timing directly (whether those
  properties exists or not).
- Correct the misspell in commit message. (Krzysztof)
- Remove the empty line at the end of document, and correct the endpoint
  numbers in the example DT node, and remove the regulator iomux setting
  in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
  support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)

Changes in v4:
- Update "analogix,hpd-gpios" to "hpd-gpios" DT propery. (Rob)
- Rename "analogix_dp-exynos.c" file name to "exynos_dp.c" (Jingoo)
- Create a separate folder for analogix code in bridge/ (Archit)
- Update commit message more readable. (Jingoo)
- Adjust the order from 05 to 04
- Provide backword compatibility with samsung. (Krzysztof)
- Split all DTS changes, and provide backward compatibility. Mark old
  properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
    "analogix,color-space" & "analogix,color-depth"   &
    "analogix,link-rate"   & "analogix,lane-count"    &
    "analogix,ycbcr-coeff" & "analogix,dynamic-range" &
    "vsync-active-high"    & "hsync-active-high"      & "interlaces"
- Separate all DTS changes to a separate patch. (Krzysztof)
- Remove some deprecated DT properties in rockchip dp document.
- Seprate the link-rate and lane-count limit out with the device_type
  flag. (Thierry)
- Take Jingoo suggest, add commit messages.
- Call drm_panel_prepare() in .get_modes function, ensure panel should
  power on before driver try to read edid message.

Changes in v3:
- Move exynos's video_timing code to analogix_dp-exynos platform driver,
  add get_modes method to struct analogix_dp_plat_data. (Thierry)
- Rename some "samsung*" dts propery to "analogix*". (Heiko)
- The link_rate and lane_count shouldn't config to the DT property value
  directly, but we can take those as hardware limite. For example, RK3288
  only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
  like "link-rate = 0x0a" "lane-count = 4". (Thierry)
- Dynamic parse video timing info from struct drm_display_mode and
  struct drm_display_info. (Thierry)
- Add devicetree binding documents. (Heiko)
- Remove sync pol & colorimetry properies from the new analogix dp driver
  devicetree binding. (Thierry)
- Update the exist exynos dtsi file with the latest DP DT properies.
- Leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m",
  and leave "sclk_edp" to analogix dp core driver which name to "dp",
  and leave "pclk_edp" to rockchip dp platform driver which name to
  "pclk". (Thierry & Heiko)
- Add devicetree binding document. (Heiko)
- Remove "rockchip,panel" DT property, take use of remote point to get panel
  node. (Heiko)
- Add the new function point dp_platdata->get_modes() init.
- Add "analogix,need-force-hpd" to indicate whether driver need foce
  hpd when hpd detect failed.
- move dp hpd detect to connector detect function.
- Add edid modes parse support

Changes in v2:
- Remove new copyright (Jingoo)
- Fix compiled failed due to analogix_dp_device misspell
- Improved commit message more readable, and avoid using some
  uncommon style like bellow: (Joe Preches)
    -  retval = exynos_dp_read_bytes_from_i2c(...
  				  ...);
    +  retval =
    +  exynos_dp_read_bytes_from_i2c(......);
- Get panel node with remote-endpoint method, and create devicetree binding
  for driver. (Heiko)
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
  leave those clock to rockchip dp phy driver.
- Fix compile failed dut to phy_pd_addr variable misspell error

Heiko Stuebner (2):
  drm/exynos: dp: rename implementation specific driver part
  drm: bridge: analogix/dp: rename register constants

Yakir Yang (15):
  drm: bridge: analogix/dp: split exynos dp driver to bridge directory
  drm: bridge: analogix/dp: fix some obvious code style
  drm: bridge: analogix/dp: remove duplicate configuration of link rate
    and link count
  drm: bridge: analogix/dp: dynamic parse sync_pol & interlace &
    dynamic_range
  dt-bindings: add document for analogix display port driver
  ARM: dts: exynos/dp: remove some properties that deprecated by
    analogix_dp driver
  drm: rockchip: dp: add rockchip platform dp driver
  dt-bindings: add document for rockchip variant of analogix_dp
  drm: bridge: analogix/dp: add some rk3288 special registers setting
  drm: bridge: analogix/dp: add max link rate and lane count limit for
    RK3288
  drm: bridge: analogix/dp: try force hpd after plug in lookup failed
  drm: bridge: analogix/dp: move hpd detect to connector detect function
  drm: bridge: analogix/dp: add edid modes parse in get_modes method
  drm: bridge: analogix/dp: add panel prepare/unprepare in
    suspend/resume time
  drm: bridge: analogix/dp: Fix the possible dead lock in bridge disable
    time

 .../bindings/display/bridge/analogix_dp.txt        |   52 +
 .../bindings/display/exynos/exynos_dp.txt          |   93 +-
 .../display/rockchip/analogix_dp-rockchip.txt      |   92 ++
 arch/arm/boot/dts/exynos5250-arndale.dts           |    2 -
 arch/arm/boot/dts/exynos5250-smdk5250.dts          |    2 -
 arch/arm/boot/dts/exynos5250-snow-common.dtsi      |    4 +-
 arch/arm/boot/dts/exynos5250-spring.dts            |    4 +-
 arch/arm/boot/dts/exynos5420-peach-pit.dts         |    4 +-
 arch/arm/boot/dts/exynos5420-smdk5420.dts          |    2 -
 arch/arm/boot/dts/exynos5800-peach-pi.dts          |    2 -
 drivers/gpu/drm/bridge/Kconfig                     |    2 +
 drivers/gpu/drm/bridge/Makefile                    |    1 +
 drivers/gpu/drm/bridge/analogix/Kconfig            |    3 +
 drivers/gpu/drm/bridge/analogix/Makefile           |    1 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1430 ++++++++++++++++++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  281 ++++
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 1320 +++++++++++++++++
 .../analogix/analogix_dp_reg.h}                    |  270 ++--
 drivers/gpu/drm/exynos/Kconfig                     |    3 +-
 drivers/gpu/drm/exynos/Makefile                    |    2 +-
 drivers/gpu/drm/exynos/exynos_dp.c                 |  324 +++++
 drivers/gpu/drm/exynos/exynos_dp_core.c            | 1510 --------------------
 drivers/gpu/drm/exynos/exynos_dp_core.h            |  282 ----
 drivers/gpu/drm/exynos/exynos_dp_reg.c             | 1263 ----------------
 drivers/gpu/drm/rockchip/Kconfig                   |    9 +
 drivers/gpu/drm/rockchip/Makefile                  |    1 +
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c    |  384 +++++
 include/drm/bridge/analogix_dp.h                   |   41 +
 28 files changed, 4115 insertions(+), 3269 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
 create mode 100644 Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
 create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
 create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
 create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
 create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
 rename drivers/gpu/drm/{exynos/exynos_dp_reg.h => bridge/analogix/analogix_dp_reg.h} (62%)
 create mode 100644 drivers/gpu/drm/exynos/exynos_dp.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
 delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
 create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
 create mode 100644 include/drm/bridge/analogix_dp.h

-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:09:46 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:09:46 +0800
Subject: [PATCH v14 02/17] drm/exynos: dp: rename implementation specific
 driver part
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534586-1534-1-git-send-email-ykk@rock-chips.com>

From: Heiko Stuebner <heiko at sntech.de>

The core functionality now resides in the generic bridge part so the
exynos-specific implementation details can get a more suitable nameing.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: Yakir Yang <ykk at rock-chips.com>
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/exynos/Makefile                          | 2 +-
 drivers/gpu/drm/exynos/{exynos_dp_core.c => exynos_dp.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/gpu/drm/exynos/{exynos_dp_core.c => exynos_dp.c} (100%)

diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 18244c5..533151b 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -13,7 +13,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS5433_DECON)	+= exynos5433_drm_decon.o
 exynosdrm-$(CONFIG_DRM_EXYNOS7_DECON)	+= exynos7_drm_decon.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DPI)	+= exynos_drm_dpi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DSI)	+= exynos_drm_dsi.o
-exynosdrm-$(CONFIG_DRM_EXYNOS_DP)	+= exynos_dp_core.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_DP)	+= exynos_dp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER)	+= exynos_mixer.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)	+= exynos_hdmi.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)	+= exynos_drm_vidi.o
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp.c
similarity index 100%
rename from drivers/gpu/drm/exynos/exynos_dp_core.c
rename to drivers/gpu/drm/exynos/exynos_dp.c
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:09:54 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:09:54 +0800
Subject: [PATCH v14 03/17] drm: bridge: analogix/dp: rename register constants
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534594-1584-1-git-send-email-ykk@rock-chips.com>

From: Heiko Stuebner <heiko at sntech.de>

In the original split we kept the register constants intact to keep the
diff small. Still the constants are Analogix-specific, so rename them now.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
Signed-off-by: Yakir Yang <ykk at rock-chips.com>
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 456 +++++++++++-----------
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 248 ++++++------
 2 files changed, 352 insertions(+), 352 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 0b926ea..442cc66 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -29,13 +29,13 @@ void analogix_dp_enable_video_mute(struct analogix_dp_device *dp, bool enable)
 	u32 reg;
 
 	if (enable) {
-		reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+		reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 		reg |= HDCP_VIDEO_MUTE;
-		writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+		writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 	} else {
-		reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+		reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 		reg &= ~HDCP_VIDEO_MUTE;
-		writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+		writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 	}
 }
 
@@ -43,9 +43,9 @@ void analogix_dp_stop_video(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 	reg &= ~VIDEO_EN;
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 }
 
 void analogix_dp_lane_swap(struct analogix_dp_device *dp, bool enable)
@@ -59,7 +59,7 @@ void analogix_dp_lane_swap(struct analogix_dp_device *dp, bool enable)
 		reg = LANE3_MAP_LOGIC_LANE_3 | LANE2_MAP_LOGIC_LANE_2 |
 			LANE1_MAP_LOGIC_LANE_1 | LANE0_MAP_LOGIC_LANE_0;
 
-	writel(reg, dp->reg_base + EXYNOS_DP_LANE_MAP);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LANE_MAP);
 }
 
 void analogix_dp_init_analog_param(struct analogix_dp_device *dp)
@@ -67,41 +67,41 @@ void analogix_dp_init_analog_param(struct analogix_dp_device *dp)
 	u32 reg;
 
 	reg = TX_TERMINAL_CTRL_50_OHM;
-	writel(reg, dp->reg_base + EXYNOS_DP_ANALOG_CTL_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_1);
 
 	reg = SEL_24M | TX_DVDD_BIT_1_0625V;
-	writel(reg, dp->reg_base + EXYNOS_DP_ANALOG_CTL_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
 
 	reg = DRIVE_DVDD_BIT_1_0625V | VCO_BIT_600_MICRO;
-	writel(reg, dp->reg_base + EXYNOS_DP_ANALOG_CTL_3);
+	writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_3);
 
 	reg = PD_RING_OSC | AUX_TERMINAL_CTRL_50_OHM |
 		TX_CUR1_2X | TX_CUR_16_MA;
-	writel(reg, dp->reg_base + EXYNOS_DP_PLL_FILTER_CTL_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_PLL_FILTER_CTL_1);
 
 	reg = CH3_AMP_400_MV | CH2_AMP_400_MV |
 		CH1_AMP_400_MV | CH0_AMP_400_MV;
-	writel(reg, dp->reg_base + EXYNOS_DP_TX_AMP_TUNING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_TX_AMP_TUNING_CTL);
 }
 
 void analogix_dp_init_interrupt(struct analogix_dp_device *dp)
 {
 	/* Set interrupt pin assertion polarity as high */
-	writel(INT_POL1 | INT_POL0, dp->reg_base + EXYNOS_DP_INT_CTL);
+	writel(INT_POL1 | INT_POL0, dp->reg_base + ANALOGIX_DP_INT_CTL);
 
 	/* Clear pending regisers */
-	writel(0xff, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_1);
-	writel(0x4f, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_2);
-	writel(0xe0, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_3);
-	writel(0xe7, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_4);
-	writel(0x63, dp->reg_base + EXYNOS_DP_INT_STA);
+	writel(0xff, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_1);
+	writel(0x4f, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_2);
+	writel(0xe0, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_3);
+	writel(0xe7, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_4);
+	writel(0x63, dp->reg_base + ANALOGIX_DP_INT_STA);
 
 	/* 0:mask,1: unmask */
-	writel(0x00, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_1);
-	writel(0x00, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_2);
-	writel(0x00, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_3);
-	writel(0x00, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_4);
-	writel(0x00, dp->reg_base + EXYNOS_DP_INT_STA_MASK);
+	writel(0x00, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_1);
+	writel(0x00, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_2);
+	writel(0x00, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_3);
+	writel(0x00, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_4);
+	writel(0x00, dp->reg_base + ANALOGIX_DP_INT_STA_MASK);
 }
 
 void analogix_dp_reset(struct analogix_dp_device *dp)
@@ -114,44 +114,44 @@ void analogix_dp_reset(struct analogix_dp_device *dp)
 	reg = MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N |
 		AUD_FIFO_FUNC_EN_N | AUD_FUNC_EN_N |
 		HDCP_FUNC_EN_N | SW_FUNC_EN_N;
-	writel(reg, dp->reg_base + EXYNOS_DP_FUNC_EN_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
 
 	reg = SSC_FUNC_EN_N | AUX_FUNC_EN_N |
 		SERDES_FIFO_FUNC_EN_N |
 		LS_CLK_DOMAIN_FUNC_EN_N;
-	writel(reg, dp->reg_base + EXYNOS_DP_FUNC_EN_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_2);
 
 	usleep_range(20, 30);
 
 	analogix_dp_lane_swap(dp, 0);
 
-	writel(0x0, dp->reg_base + EXYNOS_DP_SYS_CTL_1);
-	writel(0x40, dp->reg_base + EXYNOS_DP_SYS_CTL_2);
-	writel(0x0, dp->reg_base + EXYNOS_DP_SYS_CTL_3);
-	writel(0x0, dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_SYS_CTL_1);
+	writel(0x40, dp->reg_base + ANALOGIX_DP_SYS_CTL_2);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 
-	writel(0x0, dp->reg_base + EXYNOS_DP_PKT_SEND_CTL);
-	writel(0x0, dp->reg_base + EXYNOS_DP_HDCP_CTL);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_HDCP_CTL);
 
-	writel(0x5e, dp->reg_base + EXYNOS_DP_HPD_DEGLITCH_L);
-	writel(0x1a, dp->reg_base + EXYNOS_DP_HPD_DEGLITCH_H);
+	writel(0x5e, dp->reg_base + ANALOGIX_DP_HPD_DEGLITCH_L);
+	writel(0x1a, dp->reg_base + ANALOGIX_DP_HPD_DEGLITCH_H);
 
-	writel(0x10, dp->reg_base + EXYNOS_DP_LINK_DEBUG_CTL);
+	writel(0x10, dp->reg_base + ANALOGIX_DP_LINK_DEBUG_CTL);
 
-	writel(0x0, dp->reg_base + EXYNOS_DP_PHY_TEST);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_PHY_TEST);
 
-	writel(0x0, dp->reg_base + EXYNOS_DP_VIDEO_FIFO_THRD);
-	writel(0x20, dp->reg_base + EXYNOS_DP_AUDIO_MARGIN);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_VIDEO_FIFO_THRD);
+	writel(0x20, dp->reg_base + ANALOGIX_DP_AUDIO_MARGIN);
 
-	writel(0x4, dp->reg_base + EXYNOS_DP_M_VID_GEN_FILTER_TH);
-	writel(0x2, dp->reg_base + EXYNOS_DP_M_AUD_GEN_FILTER_TH);
+	writel(0x4, dp->reg_base + ANALOGIX_DP_M_VID_GEN_FILTER_TH);
+	writel(0x2, dp->reg_base + ANALOGIX_DP_M_AUD_GEN_FILTER_TH);
 
-	writel(0x00000101, dp->reg_base + EXYNOS_DP_SOC_GENERAL_CTL);
+	writel(0x00000101, dp->reg_base + ANALOGIX_DP_SOC_GENERAL_CTL);
 }
 
 void analogix_dp_swreset(struct analogix_dp_device *dp)
 {
-	writel(RESET_DP_TX, dp->reg_base + EXYNOS_DP_TX_SW_RESET);
+	writel(RESET_DP_TX, dp->reg_base + ANALOGIX_DP_TX_SW_RESET);
 }
 
 void analogix_dp_config_interrupt(struct analogix_dp_device *dp)
@@ -160,26 +160,26 @@ void analogix_dp_config_interrupt(struct analogix_dp_device *dp)
 
 	/* 0: mask, 1: unmask */
 	reg = COMMON_INT_MASK_1;
-	writel(reg, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_1);
 
 	reg = COMMON_INT_MASK_2;
-	writel(reg, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_2);
 
 	reg = COMMON_INT_MASK_3;
-	writel(reg, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_3);
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_3);
 
 	reg = COMMON_INT_MASK_4;
-	writel(reg, dp->reg_base + EXYNOS_DP_COMMON_INT_MASK_4);
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_4);
 
 	reg = INT_STA_MASK;
-	writel(reg, dp->reg_base + EXYNOS_DP_INT_STA_MASK);
+	writel(reg, dp->reg_base + ANALOGIX_DP_INT_STA_MASK);
 }
 
 enum pll_status analogix_dp_get_pll_lock_status(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_DEBUG_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_DEBUG_CTL);
 	if (reg & PLL_LOCK)
 		return PLL_LOCKED;
 	else
@@ -191,13 +191,13 @@ void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool enable)
 	u32 reg;
 
 	if (enable) {
-		reg = readl(dp->reg_base + EXYNOS_DP_PLL_CTL);
+		reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
 		reg |= DP_PLL_PD;
-		writel(reg, dp->reg_base + EXYNOS_DP_PLL_CTL);
+		writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
 	} else {
-		reg = readl(dp->reg_base + EXYNOS_DP_PLL_CTL);
+		reg = readl(dp->reg_base + ANALOGIX_DP_PLL_CTL);
 		reg &= ~DP_PLL_PD;
-		writel(reg, dp->reg_base + EXYNOS_DP_PLL_CTL);
+		writel(reg, dp->reg_base + ANALOGIX_DP_PLL_CTL);
 	}
 }
 
@@ -210,77 +210,77 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
 	switch (block) {
 	case AUX_BLOCK:
 		if (enable) {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg |= AUX_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		} else {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg &= ~AUX_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		}
 		break;
 	case CH0_BLOCK:
 		if (enable) {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg |= CH0_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		} else {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg &= ~CH0_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		}
 		break;
 	case CH1_BLOCK:
 		if (enable) {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg |= CH1_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		} else {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg &= ~CH1_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		}
 		break;
 	case CH2_BLOCK:
 		if (enable) {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg |= CH2_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		} else {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg &= ~CH2_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		}
 		break;
 	case CH3_BLOCK:
 		if (enable) {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg |= CH3_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		} else {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg &= ~CH3_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		}
 		break;
 	case ANALOG_TOTAL:
 		if (enable) {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg |= DP_PHY_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		} else {
-			reg = readl(dp->reg_base + EXYNOS_DP_PHY_PD);
+			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
 			reg &= ~DP_PHY_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		}
 		break;
 	case POWER_ALL:
 		if (enable) {
 			reg = DP_PHY_PD | AUX_PD | CH3_PD | CH2_PD |
 				CH1_PD | CH0_PD;
-			writel(reg, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		} else {
-			writel(0x00, dp->reg_base + EXYNOS_DP_PHY_PD);
+			writel(0x00, dp->reg_base + ANALOGIX_DP_PHY_PD);
 		}
 		break;
 	default:
@@ -296,11 +296,11 @@ void analogix_dp_init_analog_func(struct analogix_dp_device *dp)
 	analogix_dp_set_analog_power_down(dp, POWER_ALL, 0);
 
 	reg = PLL_LOCK_CHG;
-	writel(reg, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_1);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_DEBUG_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_DEBUG_CTL);
 	reg &= ~(F_PLL_LOCK | PLL_LOCK_CTRL);
-	writel(reg, dp->reg_base + EXYNOS_DP_DEBUG_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_DEBUG_CTL);
 
 	/* Power up PLL */
 	if (analogix_dp_get_pll_lock_status(dp) == PLL_UNLOCKED) {
@@ -317,10 +317,10 @@ void analogix_dp_init_analog_func(struct analogix_dp_device *dp)
 	}
 
 	/* Enable Serdes FIFO function and Link symbol clock domain module */
-	reg = readl(dp->reg_base + EXYNOS_DP_FUNC_EN_2);
+	reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_2);
 	reg &= ~(SERDES_FIFO_FUNC_EN_N | LS_CLK_DOMAIN_FUNC_EN_N
 		| AUX_FUNC_EN_N);
-	writel(reg, dp->reg_base + EXYNOS_DP_FUNC_EN_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_2);
 }
 
 void analogix_dp_clear_hotplug_interrupts(struct analogix_dp_device *dp)
@@ -331,10 +331,10 @@ void analogix_dp_clear_hotplug_interrupts(struct analogix_dp_device *dp)
 		return;
 
 	reg = HOTPLUG_CHG | HPD_LOST | PLUG;
-	writel(reg, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_4);
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_4);
 
 	reg = INT_HPD;
-	writel(reg, dp->reg_base + EXYNOS_DP_INT_STA);
+	writel(reg, dp->reg_base + ANALOGIX_DP_INT_STA);
 }
 
 void analogix_dp_init_hpd(struct analogix_dp_device *dp)
@@ -346,9 +346,9 @@ void analogix_dp_init_hpd(struct analogix_dp_device *dp)
 
 	analogix_dp_clear_hotplug_interrupts(dp);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_3);
+	reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
 	reg &= ~(F_HPD | HPD_CTRL);
-	writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_3);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
 }
 
 enum dp_irq_type analogix_dp_get_irq_type(struct analogix_dp_device *dp)
@@ -363,7 +363,7 @@ enum dp_irq_type analogix_dp_get_irq_type(struct analogix_dp_device *dp)
 			return DP_IRQ_TYPE_HP_CABLE_OUT;
 	} else {
 		/* Parse hotplug interrupt status register */
-		reg = readl(dp->reg_base + EXYNOS_DP_COMMON_INT_STA_4);
+		reg = readl(dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_4);
 
 		if (reg & PLUG)
 			return DP_IRQ_TYPE_HP_CABLE_IN;
@@ -383,9 +383,9 @@ void analogix_dp_reset_aux(struct analogix_dp_device *dp)
 	u32 reg;
 
 	/* Disable AUX channel module */
-	reg = readl(dp->reg_base + EXYNOS_DP_FUNC_EN_2);
+	reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_2);
 	reg |= AUX_FUNC_EN_N;
-	writel(reg, dp->reg_base + EXYNOS_DP_FUNC_EN_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_2);
 }
 
 void analogix_dp_init_aux(struct analogix_dp_device *dp)
@@ -394,23 +394,23 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
 
 	/* Clear inerrupts related to AUX channel */
 	reg = RPLY_RECEIV | AUX_ERR;
-	writel(reg, dp->reg_base + EXYNOS_DP_INT_STA);
+	writel(reg, dp->reg_base + ANALOGIX_DP_INT_STA);
 
 	analogix_dp_reset_aux(dp);
 
 	/* Disable AUX transaction H/W retry */
 	reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3) | AUX_HW_RETRY_COUNT_SEL(0)|
 		AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
-	writel(reg, dp->reg_base + EXYNOS_DP_AUX_HW_RETRY_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_AUX_HW_RETRY_CTL);
 
 	/* Receive AUX Channel DEFER commands equal to DEFFER_COUNT*64 */
 	reg = DEFER_CTRL_EN | DEFER_COUNT(1);
-	writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_DEFER_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_DEFER_CTL);
 
 	/* Enable AUX channel module */
-	reg = readl(dp->reg_base + EXYNOS_DP_FUNC_EN_2);
+	reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_2);
 	reg &= ~AUX_FUNC_EN_N;
-	writel(reg, dp->reg_base + EXYNOS_DP_FUNC_EN_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_2);
 }
 
 int analogix_dp_get_plug_in_status(struct analogix_dp_device *dp)
@@ -421,7 +421,7 @@ int analogix_dp_get_plug_in_status(struct analogix_dp_device *dp)
 		if (gpio_get_value(dp->hpd_gpio))
 			return 0;
 	} else {
-		reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_3);
+		reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
 		if (reg & HPD_STATUS)
 			return 0;
 	}
@@ -433,9 +433,9 @@ void analogix_dp_enable_sw_function(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_FUNC_EN_1);
+	reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
 	reg &= ~SW_FUNC_EN_N;
-	writel(reg, dp->reg_base + EXYNOS_DP_FUNC_EN_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
 }
 
 int analogix_dp_start_aux_transaction(struct analogix_dp_device *dp)
@@ -445,34 +445,34 @@ int analogix_dp_start_aux_transaction(struct analogix_dp_device *dp)
 	int timeout_loop = 0;
 
 	/* Enable AUX CH operation */
-	reg = readl(dp->reg_base + EXYNOS_DP_AUX_CH_CTL_2);
+	reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
 	reg |= AUX_EN;
-	writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
 
 	/* Is AUX CH command reply received? */
-	reg = readl(dp->reg_base + EXYNOS_DP_INT_STA);
+	reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
 	while (!(reg & RPLY_RECEIV)) {
 		timeout_loop++;
 		if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
 			dev_err(dp->dev, "AUX CH command reply failed!\n");
 			return -ETIMEDOUT;
 		}
-		reg = readl(dp->reg_base + EXYNOS_DP_INT_STA);
+		reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
 		usleep_range(10, 11);
 	}
 
 	/* Clear interrupt source for AUX CH command reply */
-	writel(RPLY_RECEIV, dp->reg_base + EXYNOS_DP_INT_STA);
+	writel(RPLY_RECEIV, dp->reg_base + ANALOGIX_DP_INT_STA);
 
 	/* Clear interrupt source for AUX CH access error */
-	reg = readl(dp->reg_base + EXYNOS_DP_INT_STA);
+	reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
 	if (reg & AUX_ERR) {
-		writel(AUX_ERR, dp->reg_base + EXYNOS_DP_INT_STA);
+		writel(AUX_ERR, dp->reg_base + ANALOGIX_DP_INT_STA);
 		return -EREMOTEIO;
 	}
 
 	/* Check AUX CH error access status */
-	reg = readl(dp->reg_base + EXYNOS_DP_AUX_CH_STA);
+	reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_STA);
 	if ((reg & AUX_STATUS_MASK) != 0) {
 		dev_err(dp->dev, "AUX CH error happens: %d\n\n",
 			reg & AUX_STATUS_MASK);
@@ -493,19 +493,19 @@ int analogix_dp_write_byte_to_dpcd(struct analogix_dp_device *dp,
 	for (i = 0; i < 3; i++) {
 		/* Clear AUX CH data buffer */
 		reg = BUF_CLR;
-		writel(reg, dp->reg_base + EXYNOS_DP_BUFFER_DATA_CTL);
+		writel(reg, dp->reg_base + ANALOGIX_DP_BUFFER_DATA_CTL);
 
 		/* Select DPCD device address */
 		reg = AUX_ADDR_7_0(reg_addr);
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_7_0);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_7_0);
 		reg = AUX_ADDR_15_8(reg_addr);
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_15_8);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_15_8);
 		reg = AUX_ADDR_19_16(reg_addr);
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_19_16);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_19_16);
 
 		/* Write data buffer */
 		reg = (unsigned int)data;
-		writel(reg, dp->reg_base + EXYNOS_DP_BUF_DATA_0);
+		writel(reg, dp->reg_base + ANALOGIX_DP_BUF_DATA_0);
 
 		/*
 		 * Set DisplayPort transaction and write 1 byte
@@ -513,7 +513,7 @@ int analogix_dp_write_byte_to_dpcd(struct analogix_dp_device *dp,
 		 * If Bit 3 is 0, I2C transaction.
 		 */
 		reg = AUX_TX_COMM_DP_TRANSACTION | AUX_TX_COMM_WRITE;
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_1);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_1);
 
 		/* Start AUX transaction */
 		retval = analogix_dp_start_aux_transaction(dp);
@@ -538,15 +538,15 @@ int analogix_dp_read_byte_from_dpcd(struct analogix_dp_device *dp,
 	for (i = 0; i < 3; i++) {
 		/* Clear AUX CH data buffer */
 		reg = BUF_CLR;
-		writel(reg, dp->reg_base + EXYNOS_DP_BUFFER_DATA_CTL);
+		writel(reg, dp->reg_base + ANALOGIX_DP_BUFFER_DATA_CTL);
 
 		/* Select DPCD device address */
 		reg = AUX_ADDR_7_0(reg_addr);
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_7_0);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_7_0);
 		reg = AUX_ADDR_15_8(reg_addr);
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_15_8);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_15_8);
 		reg = AUX_ADDR_19_16(reg_addr);
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_19_16);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_19_16);
 
 		/*
 		 * Set DisplayPort transaction and read 1 byte
@@ -554,7 +554,7 @@ int analogix_dp_read_byte_from_dpcd(struct analogix_dp_device *dp,
 		 * If Bit 3 is 0, I2C transaction.
 		 */
 		reg = AUX_TX_COMM_DP_TRANSACTION | AUX_TX_COMM_READ;
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_1);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_1);
 
 		/* Start AUX transaction */
 		retval = analogix_dp_start_aux_transaction(dp);
@@ -566,7 +566,7 @@ int analogix_dp_read_byte_from_dpcd(struct analogix_dp_device *dp,
 	}
 
 	/* Read data buffer */
-	reg = readl(dp->reg_base + EXYNOS_DP_BUF_DATA_0);
+	reg = readl(dp->reg_base + ANALOGIX_DP_BUF_DATA_0);
 	*data = (unsigned char)(reg & 0xff);
 
 	return retval;
@@ -586,7 +586,7 @@ int analogix_dp_write_bytes_to_dpcd(struct analogix_dp_device *dp,
 
 	/* Clear AUX CH data buffer */
 	reg = BUF_CLR;
-	writel(reg, dp->reg_base + EXYNOS_DP_BUFFER_DATA_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_BUFFER_DATA_CTL);
 
 	start_offset = 0;
 	while (start_offset < count) {
@@ -599,16 +599,16 @@ int analogix_dp_write_bytes_to_dpcd(struct analogix_dp_device *dp,
 		for (i = 0; i < 3; i++) {
 			/* Select DPCD device address */
 			reg = AUX_ADDR_7_0(reg_addr + start_offset);
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_7_0);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_7_0);
 			reg = AUX_ADDR_15_8(reg_addr + start_offset);
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_15_8);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_15_8);
 			reg = AUX_ADDR_19_16(reg_addr + start_offset);
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_19_16);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_19_16);
 
 			for (cur_data_idx = 0; cur_data_idx < cur_data_count;
 			     cur_data_idx++) {
 				reg = data[start_offset + cur_data_idx];
-				writel(reg, dp->reg_base + EXYNOS_DP_BUF_DATA_0
+				writel(reg, dp->reg_base + ANALOGIX_DP_BUF_DATA_0
 							  + 4 * cur_data_idx);
 			}
 
@@ -619,7 +619,7 @@ int analogix_dp_write_bytes_to_dpcd(struct analogix_dp_device *dp,
 			 */
 			reg = AUX_LENGTH(cur_data_count) |
 				AUX_TX_COMM_DP_TRANSACTION | AUX_TX_COMM_WRITE;
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_1);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_1);
 
 			/* Start AUX transaction */
 			retval = analogix_dp_start_aux_transaction(dp);
@@ -650,7 +650,7 @@ int analogix_dp_read_bytes_from_dpcd(struct analogix_dp_device *dp,
 
 	/* Clear AUX CH data buffer */
 	reg = BUF_CLR;
-	writel(reg, dp->reg_base + EXYNOS_DP_BUFFER_DATA_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_BUFFER_DATA_CTL);
 
 	start_offset = 0;
 	while (start_offset < count) {
@@ -664,11 +664,11 @@ int analogix_dp_read_bytes_from_dpcd(struct analogix_dp_device *dp,
 		for (i = 0; i < 3; i++) {
 			/* Select DPCD device address */
 			reg = AUX_ADDR_7_0(reg_addr + start_offset);
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_7_0);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_7_0);
 			reg = AUX_ADDR_15_8(reg_addr + start_offset);
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_15_8);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_15_8);
 			reg = AUX_ADDR_19_16(reg_addr + start_offset);
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_19_16);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_19_16);
 
 			/*
 			 * Set DisplayPort transaction and read
@@ -677,7 +677,7 @@ int analogix_dp_read_bytes_from_dpcd(struct analogix_dp_device *dp,
 			 */
 			reg = AUX_LENGTH(cur_data_count) |
 				AUX_TX_COMM_DP_TRANSACTION | AUX_TX_COMM_READ;
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_1);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_1);
 
 			/* Start AUX transaction */
 			retval = analogix_dp_start_aux_transaction(dp);
@@ -690,7 +690,7 @@ int analogix_dp_read_bytes_from_dpcd(struct analogix_dp_device *dp,
 
 		for (cur_data_idx = 0; cur_data_idx < cur_data_count;
 		    cur_data_idx++) {
-			reg = readl(dp->reg_base + EXYNOS_DP_BUF_DATA_0
+			reg = readl(dp->reg_base + ANALOGIX_DP_BUF_DATA_0
 						 + 4 * cur_data_idx);
 			data[start_offset + cur_data_idx] =
 				(unsigned char)reg;
@@ -711,12 +711,12 @@ int analogix_dp_select_i2c_device(struct analogix_dp_device *dp,
 
 	/* Set EDID device address */
 	reg = device_addr;
-	writel(reg, dp->reg_base + EXYNOS_DP_AUX_ADDR_7_0);
-	writel(0x0, dp->reg_base + EXYNOS_DP_AUX_ADDR_15_8);
-	writel(0x0, dp->reg_base + EXYNOS_DP_AUX_ADDR_19_16);
+	writel(reg, dp->reg_base + ANALOGIX_DP_AUX_ADDR_7_0);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_AUX_ADDR_15_8);
+	writel(0x0, dp->reg_base + ANALOGIX_DP_AUX_ADDR_19_16);
 
 	/* Set offset from base address of EDID device */
-	writel(reg_addr, dp->reg_base + EXYNOS_DP_BUF_DATA_0);
+	writel(reg_addr, dp->reg_base + ANALOGIX_DP_BUF_DATA_0);
 
 	/*
 	 * Set I2C transaction and write address
@@ -725,7 +725,7 @@ int analogix_dp_select_i2c_device(struct analogix_dp_device *dp,
 	 */
 	reg = AUX_TX_COMM_I2C_TRANSACTION | AUX_TX_COMM_MOT |
 		AUX_TX_COMM_WRITE;
-	writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_1);
 
 	/* Start AUX transaction */
 	retval = analogix_dp_start_aux_transaction(dp);
@@ -747,7 +747,7 @@ int analogix_dp_read_byte_from_i2c(struct analogix_dp_device *dp,
 	for (i = 0; i < 3; i++) {
 		/* Clear AUX CH data buffer */
 		reg = BUF_CLR;
-		writel(reg, dp->reg_base + EXYNOS_DP_BUFFER_DATA_CTL);
+		writel(reg, dp->reg_base + ANALOGIX_DP_BUFFER_DATA_CTL);
 
 		/* Select EDID device */
 		retval = analogix_dp_select_i2c_device(dp, device_addr, reg_addr);
@@ -761,7 +761,7 @@ int analogix_dp_read_byte_from_i2c(struct analogix_dp_device *dp,
 		 */
 		reg = AUX_TX_COMM_I2C_TRANSACTION |
 			AUX_TX_COMM_READ;
-		writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_1);
+		writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_1);
 
 		/* Start AUX transaction */
 		retval = analogix_dp_start_aux_transaction(dp);
@@ -774,7 +774,7 @@ int analogix_dp_read_byte_from_i2c(struct analogix_dp_device *dp,
 
 	/* Read data */
 	if (retval == 0)
-		*data = readl(dp->reg_base + EXYNOS_DP_BUF_DATA_0);
+		*data = readl(dp->reg_base + ANALOGIX_DP_BUF_DATA_0);
 
 	return retval;
 }
@@ -795,12 +795,12 @@ int analogix_dp_read_bytes_from_i2c(struct analogix_dp_device *dp,
 		for (j = 0; j < 3; j++) {
 			/* Clear AUX CH data buffer */
 			reg = BUF_CLR;
-			writel(reg, dp->reg_base + EXYNOS_DP_BUFFER_DATA_CTL);
+			writel(reg, dp->reg_base + ANALOGIX_DP_BUFFER_DATA_CTL);
 
 			/* Set normal AUX CH command */
-			reg = readl(dp->reg_base + EXYNOS_DP_AUX_CH_CTL_2);
+			reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
 			reg &= ~ADDR_ONLY;
-			writel(reg, dp->reg_base + EXYNOS_DP_AUX_CH_CTL_2);
+			writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
 
 			/*
 			 * If Rx sends defer, Tx sends only reads
@@ -822,7 +822,7 @@ int analogix_dp_read_bytes_from_i2c(struct analogix_dp_device *dp,
 					AUX_TX_COMM_I2C_TRANSACTION |
 					AUX_TX_COMM_READ;
 				writel(reg, dp->reg_base +
-					EXYNOS_DP_AUX_CH_CTL_1);
+					ANALOGIX_DP_AUX_CH_CTL_1);
 
 				/* Start AUX transaction */
 				retval = analogix_dp_start_aux_transaction(dp);
@@ -834,7 +834,7 @@ int analogix_dp_read_bytes_from_i2c(struct analogix_dp_device *dp,
 						__func__);
 			}
 			/* Check if Rx sends defer */
-			reg = readl(dp->reg_base + EXYNOS_DP_AUX_RX_COMM);
+			reg = readl(dp->reg_base + ANALOGIX_DP_AUX_RX_COMM);
 			if (reg == AUX_RX_COMM_AUX_DEFER ||
 				reg == AUX_RX_COMM_I2C_DEFER) {
 				dev_err(dp->dev, "Defer: %d\n\n", reg);
@@ -843,7 +843,7 @@ int analogix_dp_read_bytes_from_i2c(struct analogix_dp_device *dp,
 		}
 
 		for (cur_data_idx = 0; cur_data_idx < 16; cur_data_idx++) {
-			reg = readl(dp->reg_base + EXYNOS_DP_BUF_DATA_0
+			reg = readl(dp->reg_base + ANALOGIX_DP_BUF_DATA_0
 						 + 4 * cur_data_idx);
 			edid[i + cur_data_idx] = (unsigned char)reg;
 		}
@@ -858,14 +858,14 @@ void analogix_dp_set_link_bandwidth(struct analogix_dp_device *dp, u32 bwtype)
 
 	reg = bwtype;
 	if ((bwtype == LINK_RATE_2_70GBPS) || (bwtype == LINK_RATE_1_62GBPS))
-		writel(reg, dp->reg_base + EXYNOS_DP_LINK_BW_SET);
+		writel(reg, dp->reg_base + ANALOGIX_DP_LINK_BW_SET);
 }
 
 void analogix_dp_get_link_bandwidth(struct analogix_dp_device *dp, u32 *bwtype)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LINK_BW_SET);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LINK_BW_SET);
 	*bwtype = reg;
 }
 
@@ -874,14 +874,14 @@ void analogix_dp_set_lane_count(struct analogix_dp_device *dp, u32 count)
 	u32 reg;
 
 	reg = count;
-	writel(reg, dp->reg_base + EXYNOS_DP_LANE_COUNT_SET);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LANE_COUNT_SET);
 }
 
 void analogix_dp_get_lane_count(struct analogix_dp_device *dp, u32 *count)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LANE_COUNT_SET);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LANE_COUNT_SET);
 	*count = reg;
 }
 
@@ -890,13 +890,13 @@ void analogix_dp_enable_enhanced_mode(struct analogix_dp_device *dp, bool enable
 	u32 reg;
 
 	if (enable) {
-		reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 		reg |= ENHANCED;
-		writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 	} else {
-		reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 		reg &= ~ENHANCED;
-		writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 	}
 }
 
@@ -908,25 +908,25 @@ void analogix_dp_set_training_pattern(struct analogix_dp_device *dp,
 	switch (pattern) {
 	case PRBS7:
 		reg = SCRAMBLING_ENABLE | LINK_QUAL_PATTERN_SET_PRBS7;
-		writel(reg, dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+		writel(reg, dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 		break;
 	case D10_2:
 		reg = SCRAMBLING_ENABLE | LINK_QUAL_PATTERN_SET_D10_2;
-		writel(reg, dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+		writel(reg, dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 		break;
 	case TRAINING_PTN1:
 		reg = SCRAMBLING_DISABLE | SW_TRAINING_PATTERN_SET_PTN1;
-		writel(reg, dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+		writel(reg, dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 		break;
 	case TRAINING_PTN2:
 		reg = SCRAMBLING_DISABLE | SW_TRAINING_PATTERN_SET_PTN2;
-		writel(reg, dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+		writel(reg, dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 		break;
 	case DP_NONE:
 		reg = SCRAMBLING_ENABLE |
 			LINK_QUAL_PATTERN_SET_DISABLE |
 			SW_TRAINING_PATTERN_SET_NORMAL;
-		writel(reg, dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+		writel(reg, dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 		break;
 	default:
 		break;
@@ -937,40 +937,40 @@ void analogix_dp_set_lane0_pre_emphasis(struct analogix_dp_device *dp, u32 level
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN0_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN0_LINK_TRAINING_CTL);
 	reg &= ~PRE_EMPHASIS_SET_MASK;
 	reg |= level << PRE_EMPHASIS_SET_SHIFT;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN0_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN0_LINK_TRAINING_CTL);
 }
 
 void analogix_dp_set_lane1_pre_emphasis(struct analogix_dp_device *dp, u32 level)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN1_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN1_LINK_TRAINING_CTL);
 	reg &= ~PRE_EMPHASIS_SET_MASK;
 	reg |= level << PRE_EMPHASIS_SET_SHIFT;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN1_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN1_LINK_TRAINING_CTL);
 }
 
 void analogix_dp_set_lane2_pre_emphasis(struct analogix_dp_device *dp, u32 level)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN2_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN2_LINK_TRAINING_CTL);
 	reg &= ~PRE_EMPHASIS_SET_MASK;
 	reg |= level << PRE_EMPHASIS_SET_SHIFT;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN2_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN2_LINK_TRAINING_CTL);
 }
 
 void analogix_dp_set_lane3_pre_emphasis(struct analogix_dp_device *dp, u32 level)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN3_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN3_LINK_TRAINING_CTL);
 	reg &= ~PRE_EMPHASIS_SET_MASK;
 	reg |= level << PRE_EMPHASIS_SET_SHIFT;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN3_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN3_LINK_TRAINING_CTL);
 }
 
 void analogix_dp_set_lane0_link_training(struct analogix_dp_device *dp,
@@ -979,7 +979,7 @@ void analogix_dp_set_lane0_link_training(struct analogix_dp_device *dp,
 	u32 reg;
 
 	reg = training_lane;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN0_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN0_LINK_TRAINING_CTL);
 }
 
 void analogix_dp_set_lane1_link_training(struct analogix_dp_device *dp,
@@ -988,7 +988,7 @@ void analogix_dp_set_lane1_link_training(struct analogix_dp_device *dp,
 	u32 reg;
 
 	reg = training_lane;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN1_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN1_LINK_TRAINING_CTL);
 }
 
 void analogix_dp_set_lane2_link_training(struct analogix_dp_device *dp,
@@ -997,7 +997,7 @@ void analogix_dp_set_lane2_link_training(struct analogix_dp_device *dp,
 	u32 reg;
 
 	reg = training_lane;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN2_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN2_LINK_TRAINING_CTL);
 }
 
 void analogix_dp_set_lane3_link_training(struct analogix_dp_device *dp,
@@ -1006,14 +1006,14 @@ void analogix_dp_set_lane3_link_training(struct analogix_dp_device *dp,
 	u32 reg;
 
 	reg = training_lane;
-	writel(reg, dp->reg_base + EXYNOS_DP_LN3_LINK_TRAINING_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_LN3_LINK_TRAINING_CTL);
 }
 
 u32 analogix_dp_get_lane0_link_training(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN0_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN0_LINK_TRAINING_CTL);
 	return reg;
 }
 
@@ -1021,7 +1021,7 @@ u32 analogix_dp_get_lane1_link_training(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN1_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN1_LINK_TRAINING_CTL);
 	return reg;
 }
 
@@ -1029,7 +1029,7 @@ u32 analogix_dp_get_lane2_link_training(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN2_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN2_LINK_TRAINING_CTL);
 	return reg;
 }
 
@@ -1037,7 +1037,7 @@ u32 analogix_dp_get_lane3_link_training(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_LN3_LINK_TRAINING_CTL);
+	reg = readl(dp->reg_base + ANALOGIX_DP_LN3_LINK_TRAINING_CTL);
 	return reg;
 }
 
@@ -1045,15 +1045,15 @@ void analogix_dp_reset_macro(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_PHY_TEST);
+	reg = readl(dp->reg_base + ANALOGIX_DP_PHY_TEST);
 	reg |= MACRO_RST;
-	writel(reg, dp->reg_base + EXYNOS_DP_PHY_TEST);
+	writel(reg, dp->reg_base + ANALOGIX_DP_PHY_TEST);
 
 	/* 10 us is the minimum reset time. */
 	usleep_range(10, 20);
 
 	reg &= ~MACRO_RST;
-	writel(reg, dp->reg_base + EXYNOS_DP_PHY_TEST);
+	writel(reg, dp->reg_base + ANALOGIX_DP_PHY_TEST);
 }
 
 void analogix_dp_init_video(struct analogix_dp_device *dp)
@@ -1061,19 +1061,19 @@ void analogix_dp_init_video(struct analogix_dp_device *dp)
 	u32 reg;
 
 	reg = VSYNC_DET | VID_FORMAT_CHG | VID_CLK_CHG;
-	writel(reg, dp->reg_base + EXYNOS_DP_COMMON_INT_STA_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_STA_1);
 
 	reg = 0x0;
-	writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_1);
 
 	reg = CHA_CRI(4) | CHA_CTRL;
-	writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_2);
 
 	reg = 0x0;
-	writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_3);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
 
 	reg = VID_HRES_TH(2) | VID_VRES_TH(0);
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_8);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_8);
 }
 
 void analogix_dp_set_video_color_format(struct analogix_dp_device *dp)
@@ -1084,36 +1084,36 @@ void analogix_dp_set_video_color_format(struct analogix_dp_device *dp)
 	reg = (dp->video_info->dynamic_range << IN_D_RANGE_SHIFT) |
 		(dp->video_info->color_depth << IN_BPC_SHIFT) |
 		(dp->video_info->color_space << IN_COLOR_F_SHIFT);
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_2);
 
 	/* Set Input Color YCbCr Coefficients to ITU601 or ITU709 */
-	reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_3);
+	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_3);
 	reg &= ~IN_YC_COEFFI_MASK;
 	if (dp->video_info->ycbcr_coeff)
 		reg |= IN_YC_COEFFI_ITU709;
 	else
 		reg |= IN_YC_COEFFI_ITU601;
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_3);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_3);
 }
 
 int analogix_dp_is_slave_video_stream_clock_on(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_1);
-	writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_1);
+	reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_1);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_1);
+	reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_1);
 
 	if (!(reg & DET_STA)) {
 		dev_dbg(dp->dev, "Input stream clock not detected.\n");
 		return -EINVAL;
 	}
 
-	reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_2);
-	writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_2);
+	reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_2);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_2);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_2);
+	reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_2);
 	dev_dbg(dp->dev, "wait SYS_CTL_2.\n");
 
 	if (reg & CHA_STA) {
@@ -1132,30 +1132,30 @@ void analogix_dp_set_video_cr_mn(struct analogix_dp_device *dp,
 	u32 reg;
 
 	if (type == REGISTER_M) {
-		reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 		reg |= FIX_M_VID;
-		writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 		reg = m_value & 0xff;
-		writel(reg, dp->reg_base + EXYNOS_DP_M_VID_0);
+		writel(reg, dp->reg_base + ANALOGIX_DP_M_VID_0);
 		reg = (m_value >> 8) & 0xff;
-		writel(reg, dp->reg_base + EXYNOS_DP_M_VID_1);
+		writel(reg, dp->reg_base + ANALOGIX_DP_M_VID_1);
 		reg = (m_value >> 16) & 0xff;
-		writel(reg, dp->reg_base + EXYNOS_DP_M_VID_2);
+		writel(reg, dp->reg_base + ANALOGIX_DP_M_VID_2);
 
 		reg = n_value & 0xff;
-		writel(reg, dp->reg_base + EXYNOS_DP_N_VID_0);
+		writel(reg, dp->reg_base + ANALOGIX_DP_N_VID_0);
 		reg = (n_value >> 8) & 0xff;
-		writel(reg, dp->reg_base + EXYNOS_DP_N_VID_1);
+		writel(reg, dp->reg_base + ANALOGIX_DP_N_VID_1);
 		reg = (n_value >> 16) & 0xff;
-		writel(reg, dp->reg_base + EXYNOS_DP_N_VID_2);
+		writel(reg, dp->reg_base + ANALOGIX_DP_N_VID_2);
 	} else  {
-		reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 		reg &= ~FIX_M_VID;
-		writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_4);
+		writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_4);
 
-		writel(0x00, dp->reg_base + EXYNOS_DP_N_VID_0);
-		writel(0x80, dp->reg_base + EXYNOS_DP_N_VID_1);
-		writel(0x00, dp->reg_base + EXYNOS_DP_N_VID_2);
+		writel(0x00, dp->reg_base + ANALOGIX_DP_N_VID_0);
+		writel(0x80, dp->reg_base + ANALOGIX_DP_N_VID_1);
+		writel(0x00, dp->reg_base + ANALOGIX_DP_N_VID_2);
 	}
 }
 
@@ -1164,13 +1164,13 @@ void analogix_dp_set_video_timing_mode(struct analogix_dp_device *dp, u32 type)
 	u32 reg;
 
 	if (type == VIDEO_TIMING_FROM_CAPTURE) {
-		reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+		reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 		reg &= ~FORMAT_SEL;
-		writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+		writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 	} else {
-		reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+		reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 		reg |= FORMAT_SEL;
-		writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+		writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 	}
 }
 
@@ -1179,15 +1179,15 @@ void analogix_dp_enable_video_master(struct analogix_dp_device *dp, bool enable)
 	u32 reg;
 
 	if (enable) {
-		reg = readl(dp->reg_base + EXYNOS_DP_SOC_GENERAL_CTL);
+		reg = readl(dp->reg_base + ANALOGIX_DP_SOC_GENERAL_CTL);
 		reg &= ~VIDEO_MODE_MASK;
 		reg |= VIDEO_MASTER_MODE_EN | VIDEO_MODE_MASTER_MODE;
-		writel(reg, dp->reg_base + EXYNOS_DP_SOC_GENERAL_CTL);
+		writel(reg, dp->reg_base + ANALOGIX_DP_SOC_GENERAL_CTL);
 	} else {
-		reg = readl(dp->reg_base + EXYNOS_DP_SOC_GENERAL_CTL);
+		reg = readl(dp->reg_base + ANALOGIX_DP_SOC_GENERAL_CTL);
 		reg &= ~VIDEO_MODE_MASK;
 		reg |= VIDEO_MODE_SLAVE_MODE;
-		writel(reg, dp->reg_base + EXYNOS_DP_SOC_GENERAL_CTL);
+		writel(reg, dp->reg_base + ANALOGIX_DP_SOC_GENERAL_CTL);
 	}
 }
 
@@ -1195,19 +1195,19 @@ void analogix_dp_start_video(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 	reg |= VIDEO_EN;
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
 }
 
 int analogix_dp_is_video_stream_on(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_3);
-	writel(reg, dp->reg_base + EXYNOS_DP_SYS_CTL_3);
+	reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_SYS_CTL_3);
+	reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
 	if (!(reg & STRM_VALID)) {
 		dev_dbg(dp->dev, "Input video stream is not detected.\n");
 		return -EINVAL;
@@ -1220,44 +1220,44 @@ void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_FUNC_EN_1);
+	reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
 	reg &= ~(MASTER_VID_FUNC_EN_N|SLAVE_VID_FUNC_EN_N);
 	reg |= MASTER_VID_FUNC_EN_N;
-	writel(reg, dp->reg_base + EXYNOS_DP_FUNC_EN_1);
+	writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 	reg &= ~INTERACE_SCAN_CFG;
 	reg |= (dp->video_info->interlaced << 2);
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 	reg &= ~VSYNC_POLARITY_CFG;
 	reg |= (dp->video_info->v_sync_polarity << 1);
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 
-	reg = readl(dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 	reg &= ~HSYNC_POLARITY_CFG;
 	reg |= (dp->video_info->h_sync_polarity << 0);
-	writel(reg, dp->reg_base + EXYNOS_DP_VIDEO_CTL_10);
+	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 
 	reg = AUDIO_MODE_SPDIF_MODE | VIDEO_MODE_SLAVE_MODE;
-	writel(reg, dp->reg_base + EXYNOS_DP_SOC_GENERAL_CTL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SOC_GENERAL_CTL);
 }
 
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+	reg = readl(dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 	reg &= ~SCRAMBLING_DISABLE;
-	writel(reg, dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+	writel(reg, dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 }
 
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp)
 {
 	u32 reg;
 
-	reg = readl(dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+	reg = readl(dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 	reg |= SCRAMBLING_DISABLE;
-	writel(reg, dp->reg_base + EXYNOS_DP_TRAINING_PTN_SET);
+	writel(reg, dp->reg_base + ANALOGIX_DP_TRAINING_PTN_SET);
 }
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index b9661c9..738db4c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -12,93 +12,93 @@
 #ifndef _ANALOGIX_DP_REG_H
 #define _ANALOGIX_DP_REG_H
 
-#define EXYNOS_DP_TX_SW_RESET			0x14
-#define EXYNOS_DP_FUNC_EN_1			0x18
-#define EXYNOS_DP_FUNC_EN_2			0x1C
-#define EXYNOS_DP_VIDEO_CTL_1			0x20
-#define EXYNOS_DP_VIDEO_CTL_2			0x24
-#define EXYNOS_DP_VIDEO_CTL_3			0x28
-
-#define EXYNOS_DP_VIDEO_CTL_8			0x3C
-#define EXYNOS_DP_VIDEO_CTL_10			0x44
-
-#define EXYNOS_DP_LANE_MAP			0x35C
-
-#define EXYNOS_DP_ANALOG_CTL_1			0x370
-#define EXYNOS_DP_ANALOG_CTL_2			0x374
-#define EXYNOS_DP_ANALOG_CTL_3			0x378
-#define EXYNOS_DP_PLL_FILTER_CTL_1		0x37C
-#define EXYNOS_DP_TX_AMP_TUNING_CTL		0x380
-
-#define EXYNOS_DP_AUX_HW_RETRY_CTL		0x390
-
-#define EXYNOS_DP_COMMON_INT_STA_1		0x3C4
-#define EXYNOS_DP_COMMON_INT_STA_2		0x3C8
-#define EXYNOS_DP_COMMON_INT_STA_3		0x3CC
-#define EXYNOS_DP_COMMON_INT_STA_4		0x3D0
-#define EXYNOS_DP_INT_STA			0x3DC
-#define EXYNOS_DP_COMMON_INT_MASK_1		0x3E0
-#define EXYNOS_DP_COMMON_INT_MASK_2		0x3E4
-#define EXYNOS_DP_COMMON_INT_MASK_3		0x3E8
-#define EXYNOS_DP_COMMON_INT_MASK_4		0x3EC
-#define EXYNOS_DP_INT_STA_MASK			0x3F8
-#define EXYNOS_DP_INT_CTL			0x3FC
-
-#define EXYNOS_DP_SYS_CTL_1			0x600
-#define EXYNOS_DP_SYS_CTL_2			0x604
-#define EXYNOS_DP_SYS_CTL_3			0x608
-#define EXYNOS_DP_SYS_CTL_4			0x60C
-
-#define EXYNOS_DP_PKT_SEND_CTL			0x640
-#define EXYNOS_DP_HDCP_CTL			0x648
-
-#define EXYNOS_DP_LINK_BW_SET			0x680
-#define EXYNOS_DP_LANE_COUNT_SET		0x684
-#define EXYNOS_DP_TRAINING_PTN_SET		0x688
-#define EXYNOS_DP_LN0_LINK_TRAINING_CTL		0x68C
-#define EXYNOS_DP_LN1_LINK_TRAINING_CTL		0x690
-#define EXYNOS_DP_LN2_LINK_TRAINING_CTL		0x694
-#define EXYNOS_DP_LN3_LINK_TRAINING_CTL		0x698
-
-#define EXYNOS_DP_DEBUG_CTL			0x6C0
-#define EXYNOS_DP_HPD_DEGLITCH_L		0x6C4
-#define EXYNOS_DP_HPD_DEGLITCH_H		0x6C8
-#define EXYNOS_DP_LINK_DEBUG_CTL		0x6E0
-
-#define EXYNOS_DP_M_VID_0			0x700
-#define EXYNOS_DP_M_VID_1			0x704
-#define EXYNOS_DP_M_VID_2			0x708
-#define EXYNOS_DP_N_VID_0			0x70C
-#define EXYNOS_DP_N_VID_1			0x710
-#define EXYNOS_DP_N_VID_2			0x714
-
-#define EXYNOS_DP_PLL_CTL			0x71C
-#define EXYNOS_DP_PHY_PD			0x720
-#define EXYNOS_DP_PHY_TEST			0x724
-
-#define EXYNOS_DP_VIDEO_FIFO_THRD		0x730
-#define EXYNOS_DP_AUDIO_MARGIN			0x73C
-
-#define EXYNOS_DP_M_VID_GEN_FILTER_TH		0x764
-#define EXYNOS_DP_M_AUD_GEN_FILTER_TH		0x778
-#define EXYNOS_DP_AUX_CH_STA			0x780
-#define EXYNOS_DP_AUX_CH_DEFER_CTL		0x788
-#define EXYNOS_DP_AUX_RX_COMM			0x78C
-#define EXYNOS_DP_BUFFER_DATA_CTL		0x790
-#define EXYNOS_DP_AUX_CH_CTL_1			0x794
-#define EXYNOS_DP_AUX_ADDR_7_0			0x798
-#define EXYNOS_DP_AUX_ADDR_15_8			0x79C
-#define EXYNOS_DP_AUX_ADDR_19_16		0x7A0
-#define EXYNOS_DP_AUX_CH_CTL_2			0x7A4
-
-#define EXYNOS_DP_BUF_DATA_0			0x7C0
-
-#define EXYNOS_DP_SOC_GENERAL_CTL		0x800
-
-/* EXYNOS_DP_TX_SW_RESET */
+#define ANALOGIX_DP_TX_SW_RESET			0x14
+#define ANALOGIX_DP_FUNC_EN_1			0x18
+#define ANALOGIX_DP_FUNC_EN_2			0x1C
+#define ANALOGIX_DP_VIDEO_CTL_1			0x20
+#define ANALOGIX_DP_VIDEO_CTL_2			0x24
+#define ANALOGIX_DP_VIDEO_CTL_3			0x28
+
+#define ANALOGIX_DP_VIDEO_CTL_8			0x3C
+#define ANALOGIX_DP_VIDEO_CTL_10		0x44
+
+#define ANALOGIX_DP_LANE_MAP			0x35C
+
+#define ANALOGIX_DP_ANALOG_CTL_1		0x370
+#define ANALOGIX_DP_ANALOG_CTL_2		0x374
+#define ANALOGIX_DP_ANALOG_CTL_3		0x378
+#define ANALOGIX_DP_PLL_FILTER_CTL_1		0x37C
+#define ANALOGIX_DP_TX_AMP_TUNING_CTL		0x380
+
+#define ANALOGIX_DP_AUX_HW_RETRY_CTL		0x390
+
+#define ANALOGIX_DP_COMMON_INT_STA_1		0x3C4
+#define ANALOGIX_DP_COMMON_INT_STA_2		0x3C8
+#define ANALOGIX_DP_COMMON_INT_STA_3		0x3CC
+#define ANALOGIX_DP_COMMON_INT_STA_4		0x3D0
+#define ANALOGIX_DP_INT_STA			0x3DC
+#define ANALOGIX_DP_COMMON_INT_MASK_1		0x3E0
+#define ANALOGIX_DP_COMMON_INT_MASK_2		0x3E4
+#define ANALOGIX_DP_COMMON_INT_MASK_3		0x3E8
+#define ANALOGIX_DP_COMMON_INT_MASK_4		0x3EC
+#define ANALOGIX_DP_INT_STA_MASK		0x3F8
+#define ANALOGIX_DP_INT_CTL			0x3FC
+
+#define ANALOGIX_DP_SYS_CTL_1			0x600
+#define ANALOGIX_DP_SYS_CTL_2			0x604
+#define ANALOGIX_DP_SYS_CTL_3			0x608
+#define ANALOGIX_DP_SYS_CTL_4			0x60C
+
+#define ANALOGIX_DP_PKT_SEND_CTL		0x640
+#define ANALOGIX_DP_HDCP_CTL			0x648
+
+#define ANALOGIX_DP_LINK_BW_SET			0x680
+#define ANALOGIX_DP_LANE_COUNT_SET		0x684
+#define ANALOGIX_DP_TRAINING_PTN_SET		0x688
+#define ANALOGIX_DP_LN0_LINK_TRAINING_CTL	0x68C
+#define ANALOGIX_DP_LN1_LINK_TRAINING_CTL	0x690
+#define ANALOGIX_DP_LN2_LINK_TRAINING_CTL	0x694
+#define ANALOGIX_DP_LN3_LINK_TRAINING_CTL	0x698
+
+#define ANALOGIX_DP_DEBUG_CTL			0x6C0
+#define ANALOGIX_DP_HPD_DEGLITCH_L		0x6C4
+#define ANALOGIX_DP_HPD_DEGLITCH_H		0x6C8
+#define ANALOGIX_DP_LINK_DEBUG_CTL		0x6E0
+
+#define ANALOGIX_DP_M_VID_0			0x700
+#define ANALOGIX_DP_M_VID_1			0x704
+#define ANALOGIX_DP_M_VID_2			0x708
+#define ANALOGIX_DP_N_VID_0			0x70C
+#define ANALOGIX_DP_N_VID_1			0x710
+#define ANALOGIX_DP_N_VID_2			0x714
+
+#define ANALOGIX_DP_PLL_CTL			0x71C
+#define ANALOGIX_DP_PHY_PD			0x720
+#define ANALOGIX_DP_PHY_TEST			0x724
+
+#define ANALOGIX_DP_VIDEO_FIFO_THRD		0x730
+#define ANALOGIX_DP_AUDIO_MARGIN		0x73C
+
+#define ANALOGIX_DP_M_VID_GEN_FILTER_TH		0x764
+#define ANALOGIX_DP_M_AUD_GEN_FILTER_TH		0x778
+#define ANALOGIX_DP_AUX_CH_STA			0x780
+#define ANALOGIX_DP_AUX_CH_DEFER_CTL		0x788
+#define ANALOGIX_DP_AUX_RX_COMM			0x78C
+#define ANALOGIX_DP_BUFFER_DATA_CTL		0x790
+#define ANALOGIX_DP_AUX_CH_CTL_1		0x794
+#define ANALOGIX_DP_AUX_ADDR_7_0		0x798
+#define ANALOGIX_DP_AUX_ADDR_15_8		0x79C
+#define ANALOGIX_DP_AUX_ADDR_19_16		0x7A0
+#define ANALOGIX_DP_AUX_CH_CTL_2		0x7A4
+
+#define ANALOGIX_DP_BUF_DATA_0			0x7C0
+
+#define ANALOGIX_DP_SOC_GENERAL_CTL		0x800
+
+/* ANALOGIX_DP_TX_SW_RESET */
 #define RESET_DP_TX				(0x1 << 0)
 
-/* EXYNOS_DP_FUNC_EN_1 */
+/* ANALOGIX_DP_FUNC_EN_1 */
 #define MASTER_VID_FUNC_EN_N			(0x1 << 7)
 #define SLAVE_VID_FUNC_EN_N			(0x1 << 5)
 #define AUD_FIFO_FUNC_EN_N			(0x1 << 4)
@@ -107,17 +107,17 @@
 #define CRC_FUNC_EN_N				(0x1 << 1)
 #define SW_FUNC_EN_N				(0x1 << 0)
 
-/* EXYNOS_DP_FUNC_EN_2 */
+/* ANALOGIX_DP_FUNC_EN_2 */
 #define SSC_FUNC_EN_N				(0x1 << 7)
 #define AUX_FUNC_EN_N				(0x1 << 2)
 #define SERDES_FIFO_FUNC_EN_N			(0x1 << 1)
 #define LS_CLK_DOMAIN_FUNC_EN_N			(0x1 << 0)
 
-/* EXYNOS_DP_VIDEO_CTL_1 */
+/* ANALOGIX_DP_VIDEO_CTL_1 */
 #define VIDEO_EN				(0x1 << 7)
 #define HDCP_VIDEO_MUTE				(0x1 << 6)
 
-/* EXYNOS_DP_VIDEO_CTL_1 */
+/* ANALOGIX_DP_VIDEO_CTL_1 */
 #define IN_D_RANGE_MASK				(0x1 << 7)
 #define IN_D_RANGE_SHIFT			(7)
 #define IN_D_RANGE_CEA				(0x1 << 7)
@@ -134,7 +134,7 @@
 #define IN_COLOR_F_YCBCR422			(0x1 << 0)
 #define IN_COLOR_F_RGB				(0x0 << 0)
 
-/* EXYNOS_DP_VIDEO_CTL_3 */
+/* ANALOGIX_DP_VIDEO_CTL_3 */
 #define IN_YC_COEFFI_MASK			(0x1 << 7)
 #define IN_YC_COEFFI_SHIFT			(7)
 #define IN_YC_COEFFI_ITU709			(0x1 << 7)
@@ -144,17 +144,17 @@
 #define VID_CHK_UPDATE_TYPE_1			(0x1 << 4)
 #define VID_CHK_UPDATE_TYPE_0			(0x0 << 4)
 
-/* EXYNOS_DP_VIDEO_CTL_8 */
+/* ANALOGIX_DP_VIDEO_CTL_8 */
 #define VID_HRES_TH(x)				(((x) & 0xf) << 4)
 #define VID_VRES_TH(x)				(((x) & 0xf) << 0)
 
-/* EXYNOS_DP_VIDEO_CTL_10 */
+/* ANALOGIX_DP_VIDEO_CTL_10 */
 #define FORMAT_SEL				(0x1 << 4)
 #define INTERACE_SCAN_CFG			(0x1 << 2)
 #define VSYNC_POLARITY_CFG			(0x1 << 1)
 #define HSYNC_POLARITY_CFG			(0x1 << 0)
 
-/* EXYNOS_DP_LANE_MAP */
+/* ANALOGIX_DP_LANE_MAP */
 #define LANE3_MAP_LOGIC_LANE_0			(0x0 << 6)
 #define LANE3_MAP_LOGIC_LANE_1			(0x1 << 6)
 #define LANE3_MAP_LOGIC_LANE_2			(0x2 << 6)
@@ -172,30 +172,30 @@
 #define LANE0_MAP_LOGIC_LANE_2			(0x2 << 0)
 #define LANE0_MAP_LOGIC_LANE_3			(0x3 << 0)
 
-/* EXYNOS_DP_ANALOG_CTL_1 */
+/* ANALOGIX_DP_ANALOG_CTL_1 */
 #define TX_TERMINAL_CTRL_50_OHM			(0x1 << 4)
 
-/* EXYNOS_DP_ANALOG_CTL_2 */
+/* ANALOGIX_DP_ANALOG_CTL_2 */
 #define SEL_24M					(0x1 << 3)
 #define TX_DVDD_BIT_1_0625V			(0x4 << 0)
 
-/* EXYNOS_DP_ANALOG_CTL_3 */
+/* ANALOGIX_DP_ANALOG_CTL_3 */
 #define DRIVE_DVDD_BIT_1_0625V			(0x4 << 5)
 #define VCO_BIT_600_MICRO			(0x5 << 0)
 
-/* EXYNOS_DP_PLL_FILTER_CTL_1 */
+/* ANALOGIX_DP_PLL_FILTER_CTL_1 */
 #define PD_RING_OSC				(0x1 << 6)
 #define AUX_TERMINAL_CTRL_50_OHM		(0x2 << 4)
 #define TX_CUR1_2X				(0x1 << 2)
 #define TX_CUR_16_MA				(0x3 << 0)
 
-/* EXYNOS_DP_TX_AMP_TUNING_CTL */
+/* ANALOGIX_DP_TX_AMP_TUNING_CTL */
 #define CH3_AMP_400_MV				(0x0 << 24)
 #define CH2_AMP_400_MV				(0x0 << 16)
 #define CH1_AMP_400_MV				(0x0 << 8)
 #define CH0_AMP_400_MV				(0x0 << 0)
 
-/* EXYNOS_DP_AUX_HW_RETRY_CTL */
+/* ANALOGIX_DP_AUX_HW_RETRY_CTL */
 #define AUX_BIT_PERIOD_EXPECTED_DELAY(x)	(((x) & 0x7) << 8)
 #define AUX_HW_RETRY_INTERVAL_MASK		(0x3 << 3)
 #define AUX_HW_RETRY_INTERVAL_600_MICROSECONDS	(0x0 << 3)
@@ -204,7 +204,7 @@
 #define AUX_HW_RETRY_INTERVAL_1800_MICROSECONDS	(0x3 << 3)
 #define AUX_HW_RETRY_COUNT_SEL(x)		(((x) & 0x7) << 0)
 
-/* EXYNOS_DP_COMMON_INT_STA_1 */
+/* ANALOGIX_DP_COMMON_INT_STA_1 */
 #define VSYNC_DET				(0x1 << 7)
 #define PLL_LOCK_CHG				(0x1 << 6)
 #define SPDIF_ERR				(0x1 << 5)
@@ -214,19 +214,19 @@
 #define VID_CLK_CHG				(0x1 << 1)
 #define SW_INT					(0x1 << 0)
 
-/* EXYNOS_DP_COMMON_INT_STA_2 */
+/* ANALOGIX_DP_COMMON_INT_STA_2 */
 #define ENC_EN_CHG				(0x1 << 6)
 #define HW_BKSV_RDY				(0x1 << 3)
 #define HW_SHA_DONE				(0x1 << 2)
 #define HW_AUTH_STATE_CHG			(0x1 << 1)
 #define HW_AUTH_DONE				(0x1 << 0)
 
-/* EXYNOS_DP_COMMON_INT_STA_3 */
+/* ANALOGIX_DP_COMMON_INT_STA_3 */
 #define AFIFO_UNDER				(0x1 << 7)
 #define AFIFO_OVER				(0x1 << 6)
 #define R0_CHK_FLAG				(0x1 << 5)
 
-/* EXYNOS_DP_COMMON_INT_STA_4 */
+/* ANALOGIX_DP_COMMON_INT_STA_4 */
 #define PSR_ACTIVE				(0x1 << 7)
 #define PSR_INACTIVE				(0x1 << 6)
 #define SPDIF_BI_PHASE_ERR			(0x1 << 5)
@@ -234,29 +234,29 @@
 #define HPD_LOST				(0x1 << 1)
 #define PLUG					(0x1 << 0)
 
-/* EXYNOS_DP_INT_STA */
+/* ANALOGIX_DP_INT_STA */
 #define INT_HPD					(0x1 << 6)
 #define HW_TRAINING_FINISH			(0x1 << 5)
 #define RPLY_RECEIV				(0x1 << 1)
 #define AUX_ERR					(0x1 << 0)
 
-/* EXYNOS_DP_INT_CTL */
+/* ANALOGIX_DP_INT_CTL */
 #define SOFT_INT_CTRL				(0x1 << 2)
 #define INT_POL1				(0x1 << 1)
 #define INT_POL0				(0x1 << 0)
 
-/* EXYNOS_DP_SYS_CTL_1 */
+/* ANALOGIX_DP_SYS_CTL_1 */
 #define DET_STA					(0x1 << 2)
 #define FORCE_DET				(0x1 << 1)
 #define DET_CTRL				(0x1 << 0)
 
-/* EXYNOS_DP_SYS_CTL_2 */
+/* ANALOGIX_DP_SYS_CTL_2 */
 #define CHA_CRI(x)				(((x) & 0xf) << 4)
 #define CHA_STA					(0x1 << 2)
 #define FORCE_CHA				(0x1 << 1)
 #define CHA_CTRL				(0x1 << 0)
 
-/* EXYNOS_DP_SYS_CTL_3 */
+/* ANALOGIX_DP_SYS_CTL_3 */
 #define HPD_STATUS				(0x1 << 6)
 #define F_HPD					(0x1 << 5)
 #define HPD_CTRL				(0x1 << 4)
@@ -265,13 +265,13 @@
 #define F_VALID					(0x1 << 1)
 #define VALID_CTRL				(0x1 << 0)
 
-/* EXYNOS_DP_SYS_CTL_4 */
+/* ANALOGIX_DP_SYS_CTL_4 */
 #define FIX_M_AUD				(0x1 << 4)
 #define ENHANCED				(0x1 << 3)
 #define FIX_M_VID				(0x1 << 2)
 #define M_VID_UPDATE_CTRL			(0x3 << 0)
 
-/* EXYNOS_DP_TRAINING_PTN_SET */
+/* ANALOGIX_DP_TRAINING_PTN_SET */
 #define SCRAMBLER_TYPE				(0x1 << 9)
 #define HW_LINK_TRAINING_PATTERN		(0x1 << 8)
 #define SCRAMBLING_DISABLE			(0x1 << 5)
@@ -285,24 +285,24 @@
 #define SW_TRAINING_PATTERN_SET_PTN1		(0x1 << 0)
 #define SW_TRAINING_PATTERN_SET_NORMAL		(0x0 << 0)
 
-/* EXYNOS_DP_LN0_LINK_TRAINING_CTL */
+/* ANALOGIX_DP_LN0_LINK_TRAINING_CTL */
 #define PRE_EMPHASIS_SET_MASK			(0x3 << 3)
 #define PRE_EMPHASIS_SET_SHIFT			(3)
 
-/* EXYNOS_DP_DEBUG_CTL */
+/* ANALOGIX_DP_DEBUG_CTL */
 #define PLL_LOCK				(0x1 << 4)
 #define F_PLL_LOCK				(0x1 << 3)
 #define PLL_LOCK_CTRL				(0x1 << 2)
 #define PN_INV					(0x1 << 0)
 
-/* EXYNOS_DP_PLL_CTL */
+/* ANALOGIX_DP_PLL_CTL */
 #define DP_PLL_PD				(0x1 << 7)
 #define DP_PLL_RESET				(0x1 << 6)
 #define DP_PLL_LOOP_BIT_DEFAULT			(0x1 << 4)
 #define DP_PLL_REF_BIT_1_1250V			(0x5 << 0)
 #define DP_PLL_REF_BIT_1_2500V			(0x7 << 0)
 
-/* EXYNOS_DP_PHY_PD */
+/* ANALOGIX_DP_PHY_PD */
 #define DP_PHY_PD				(0x1 << 5)
 #define AUX_PD					(0x1 << 4)
 #define CH3_PD					(0x1 << 3)
@@ -310,28 +310,28 @@
 #define CH1_PD					(0x1 << 1)
 #define CH0_PD					(0x1 << 0)
 
-/* EXYNOS_DP_PHY_TEST */
+/* ANALOGIX_DP_PHY_TEST */
 #define MACRO_RST				(0x1 << 5)
 #define CH1_TEST				(0x1 << 1)
 #define CH0_TEST				(0x1 << 0)
 
-/* EXYNOS_DP_AUX_CH_STA */
+/* ANALOGIX_DP_AUX_CH_STA */
 #define AUX_BUSY				(0x1 << 4)
 #define AUX_STATUS_MASK				(0xf << 0)
 
-/* EXYNOS_DP_AUX_CH_DEFER_CTL */
+/* ANALOGIX_DP_AUX_CH_DEFER_CTL */
 #define DEFER_CTRL_EN				(0x1 << 7)
 #define DEFER_COUNT(x)				(((x) & 0x7f) << 0)
 
-/* EXYNOS_DP_AUX_RX_COMM */
+/* ANALOGIX_DP_AUX_RX_COMM */
 #define AUX_RX_COMM_I2C_DEFER			(0x2 << 2)
 #define AUX_RX_COMM_AUX_DEFER			(0x2 << 0)
 
-/* EXYNOS_DP_BUFFER_DATA_CTL */
+/* ANALOGIX_DP_BUFFER_DATA_CTL */
 #define BUF_CLR					(0x1 << 7)
 #define BUF_DATA_COUNT(x)			(((x) & 0x1f) << 0)
 
-/* EXYNOS_DP_AUX_CH_CTL_1 */
+/* ANALOGIX_DP_AUX_CH_CTL_1 */
 #define AUX_LENGTH(x)				(((x - 1) & 0xf) << 4)
 #define AUX_TX_COMM_MASK			(0xf << 0)
 #define AUX_TX_COMM_DP_TRANSACTION		(0x1 << 3)
@@ -340,20 +340,20 @@
 #define AUX_TX_COMM_WRITE			(0x0 << 0)
 #define AUX_TX_COMM_READ			(0x1 << 0)
 
-/* EXYNOS_DP_AUX_ADDR_7_0 */
+/* ANALOGIX_DP_AUX_ADDR_7_0 */
 #define AUX_ADDR_7_0(x)				(((x) >> 0) & 0xff)
 
-/* EXYNOS_DP_AUX_ADDR_15_8 */
+/* ANALOGIX_DP_AUX_ADDR_15_8 */
 #define AUX_ADDR_15_8(x)			(((x) >> 8) & 0xff)
 
-/* EXYNOS_DP_AUX_ADDR_19_16 */
+/* ANALOGIX_DP_AUX_ADDR_19_16 */
 #define AUX_ADDR_19_16(x)			(((x) >> 16) & 0x0f)
 
-/* EXYNOS_DP_AUX_CH_CTL_2 */
+/* ANALOGIX_DP_AUX_CH_CTL_2 */
 #define ADDR_ONLY				(0x1 << 1)
 #define AUX_EN					(0x1 << 0)
 
-/* EXYNOS_DP_SOC_GENERAL_CTL */
+/* ANALOGIX_DP_SOC_GENERAL_CTL */
 #define AUDIO_MODE_SPDIF_MODE			(0x1 << 8)
 #define AUDIO_MODE_MASTER_MODE			(0x0 << 8)
 #define MASTER_VIDEO_INTERLACE_EN		(0x1 << 4)
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:10:04 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:10:04 +0800
Subject: [PATCH v14 05/17] drm: bridge: analogix/dp: remove duplicate
 configuration of link rate and link count
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534604-1694-1-git-send-email-ykk@rock-chips.com>

link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.

Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
Tested-by: Javier Martinez Canillas <javier at osg.samsung.com>
---
Changes in v14: None
Changes in v13: None
Changes in v12:
- Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h (Jingoo)

Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Update commit message more readable. (Jingoo)
- Adjust the order from 05 to 04

Changes in v3:
- The link_rate and lane_count shouldn't config to the DT property value
  directly, but we can take those as hardware limite. For example, RK3288
  only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
  like "link-rate = 0x0a" "lane-count = 4". (Thierry)

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 14 +++++++-------
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  7 +------
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  2 +-
 3 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6901a6f..b948636 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -627,6 +627,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct analogix_dp_device *dp,
 	/*
 	 * For DP rev.1.1, Maximum link rate of Main Link lanes
 	 * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
+	 * For DP rev.1.2, Maximum link rate of Main Link lanes
+	 * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
 	 */
 	analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, &data);
 	*bandwidth = data;
@@ -647,7 +649,7 @@ static void analogix_dp_get_max_rx_lane_count(struct analogix_dp_device *dp,
 
 static void analogix_dp_init_training(struct analogix_dp_device *dp,
 				      enum link_lane_count_type max_lane,
-				      enum link_rate_type max_rate)
+				      int max_rate)
 {
 	/*
 	 * MACRO_RST must be applied after the PLL_LOCK to avoid
@@ -659,11 +661,12 @@ static void analogix_dp_init_training(struct analogix_dp_device *dp,
 	analogix_dp_get_max_rx_bandwidth(dp, &dp->link_train.link_rate);
 	analogix_dp_get_max_rx_lane_count(dp, &dp->link_train.lane_count);
 
-	if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
-	    (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
+	if ((dp->link_train.link_rate != DP_LINK_BW_1_62) &&
+	    (dp->link_train.link_rate != DP_LINK_BW_2_7) &&
+	    (dp->link_train.link_rate != DP_LINK_BW_5_4)) {
 		dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
 			dp->link_train.link_rate);
-		dp->link_train.link_rate = LINK_RATE_1_62GBPS;
+		dp->link_train.link_rate = DP_LINK_BW_1_62;
 	}
 
 	if (dp->link_train.lane_count == 0) {
@@ -901,9 +904,6 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)
 	analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
 	analogix_dp_enable_enhanced_mode(dp, 1);
 
-	analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
-	analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
-
 	analogix_dp_init_video(dp);
 	ret = analogix_dp_config_video(dp);
 	if (ret)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index d4c4ae2..afb0a53 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,11 +20,6 @@
 #define MAX_CR_LOOP 5
 #define MAX_EQ_LOOP 5
 
-enum link_rate_type {
-	LINK_RATE_1_62GBPS = 0x06,
-	LINK_RATE_2_70GBPS = 0x0a
-};
-
 enum link_lane_count_type {
 	LANE_COUNT1 = 1,
 	LANE_COUNT2 = 2,
@@ -128,7 +123,7 @@ struct video_info {
 	enum color_coefficient ycbcr_coeff;
 	enum color_depth color_depth;
 
-	enum link_rate_type link_rate;
+	int link_rate;
 	enum link_lane_count_type lane_count;
 };
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index a388c0a..eb0b63c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -855,7 +855,7 @@ void analogix_dp_set_link_bandwidth(struct analogix_dp_device *dp, u32 bwtype)
 	u32 reg;
 
 	reg = bwtype;
-	if ((bwtype == LINK_RATE_2_70GBPS) || (bwtype == LINK_RATE_1_62GBPS))
+	if ((bwtype == DP_LINK_BW_2_7) || (bwtype == DP_LINK_BW_1_62))
 		writel(reg, dp->reg_base + ANALOGIX_DP_LINK_BW_SET);
 }
 
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:09:59 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:09:59 +0800
Subject: [PATCH v14 04/17] drm: bridge: analogix/dp: fix some obvious code
 style
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534599-1636-1-git-send-email-ykk@rock-chips.com>

Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
Acked-by: Jingoo Han <jingoohan1 at gmail.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
Tested-by: Javier Martinez Canillas <javier at osg.samsung.com>
---
Changes in v14: None
Changes in v13: None
Changes in v12:
- Add the ack from Jingoo

Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
    -		analogix_dp_write_byte_to_dpcd(
    - 				dp, DP_TEST_RESPONSE,
    +		analogix_dp_write_byte_to_dpcd(dp,
    +				DP_TEST_RESPONSE,
				DP_TEST_EDID_CHECKSUM_WRITE);

Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
  uncommon style like bellow: (Joe Preches)
    -  retval = exynos_dp_read_bytes_from_i2c(...
  				  ...);
    +  retval =
    +  exynos_dp_read_bytes_from_i2c(......);

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++++++++++-----------
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  72 ++++++------
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 124 ++++++++++----------
 drivers/gpu/drm/exynos/exynos_dp.c                 |   6 +-
 4 files changed, 166 insertions(+), 165 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 392c296..6901a6f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -64,7 +64,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device *dp)
 
 	while (analogix_dp_get_plug_in_status(dp) != 0) {
 		timeout_loop++;
-		if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+		if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
 			dev_err(dp->dev, "failed to get hpd plug status\n");
 			return -ETIMEDOUT;
 		}
@@ -101,8 +101,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device *dp)
 
 	/* Read Extension Flag, Number of 128-byte EDID extension blocks */
 	retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
-				EDID_EXTENSION_FLAG,
-				&extend_block);
+						EDID_EXTENSION_FLAG,
+						&extend_block);
 	if (retval)
 		return retval;
 
@@ -110,7 +110,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device *dp)
 		dev_dbg(dp->dev, "EDID data includes a single extension!\n");
 
 		/* Read EDID data */
-		retval = analogix_dp_read_bytes_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
+		retval = analogix_dp_read_bytes_from_i2c(dp,
+						I2C_EDID_DEVICE_ADDR,
 						EDID_HEADER_PATTERN,
 						EDID_BLOCK_LENGTH,
 						&edid[EDID_HEADER_PATTERN]);
@@ -141,7 +142,7 @@ static int analogix_dp_read_edid(struct analogix_dp_device *dp)
 		}
 
 		analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
-					&test_vector);
+						&test_vector);
 		if (test_vector & DP_TEST_LINK_EDID_READ) {
 			analogix_dp_write_byte_to_dpcd(dp,
 				DP_TEST_EDID_CHECKSUM,
@@ -155,10 +156,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device *dp)
 
 		/* Read EDID data */
 		retval = analogix_dp_read_bytes_from_i2c(dp,
-				I2C_EDID_DEVICE_ADDR,
-				EDID_HEADER_PATTERN,
-				EDID_BLOCK_LENGTH,
-				&edid[EDID_HEADER_PATTERN]);
+				I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
+				EDID_BLOCK_LENGTH, &edid[EDID_HEADER_PATTERN]);
 		if (retval != 0) {
 			dev_err(dp->dev, "EDID Read failed!\n");
 			return -EIO;
@@ -169,16 +168,13 @@ static int analogix_dp_read_edid(struct analogix_dp_device *dp)
 			return -EIO;
 		}
 
-		analogix_dp_read_byte_from_dpcd(dp,
-			DP_TEST_REQUEST,
-			&test_vector);
+		analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
+						&test_vector);
 		if (test_vector & DP_TEST_LINK_EDID_READ) {
 			analogix_dp_write_byte_to_dpcd(dp,
-				DP_TEST_EDID_CHECKSUM,
-				edid[EDID_CHECKSUM]);
+				DP_TEST_EDID_CHECKSUM, edid[EDID_CHECKSUM]);
 			analogix_dp_write_byte_to_dpcd(dp,
-				DP_TEST_RESPONSE,
-				DP_TEST_EDID_CHECKSUM_WRITE);
+				DP_TEST_RESPONSE, DP_TEST_EDID_CHECKSUM_WRITE);
 		}
 	}
 
@@ -193,8 +189,7 @@ static int analogix_dp_handle_edid(struct analogix_dp_device *dp)
 	int retval;
 
 	/* Read DPCD DP_DPCD_REV~RECEIVE_PORT1_CAP_1 */
-	retval = analogix_dp_read_bytes_from_dpcd(dp, DP_DPCD_REV,
-				12, buf);
+	retval = analogix_dp_read_bytes_from_dpcd(dp, DP_DPCD_REV, 12, buf);
 	if (retval)
 		return retval;
 
@@ -208,8 +203,9 @@ static int analogix_dp_handle_edid(struct analogix_dp_device *dp)
 	return retval;
 }
 
-static void analogix_dp_enable_rx_to_enhanced_mode(struct analogix_dp_device *dp,
-						bool enable)
+static void
+analogix_dp_enable_rx_to_enhanced_mode(struct analogix_dp_device *dp,
+				       bool enable)
 {
 	u8 data;
 
@@ -217,11 +213,11 @@ static void analogix_dp_enable_rx_to_enhanced_mode(struct analogix_dp_device *dp
 
 	if (enable)
 		analogix_dp_write_byte_to_dpcd(dp, DP_LANE_COUNT_SET,
-			DP_LANE_COUNT_ENHANCED_FRAME_EN |
-			DPCD_LANE_COUNT_SET(data));
+					       DP_LANE_COUNT_ENHANCED_FRAME_EN |
+					       DPCD_LANE_COUNT_SET(data));
 	else
 		analogix_dp_write_byte_to_dpcd(dp, DP_LANE_COUNT_SET,
-			DPCD_LANE_COUNT_SET(data));
+					       DPCD_LANE_COUNT_SET(data));
 }
 
 static int analogix_dp_is_enhanced_mode_available(struct analogix_dp_device *dp)
@@ -248,13 +244,13 @@ static void analogix_dp_training_pattern_dis(struct analogix_dp_device *dp)
 {
 	analogix_dp_set_training_pattern(dp, DP_NONE);
 
-	analogix_dp_write_byte_to_dpcd(dp,
-		DP_TRAINING_PATTERN_SET,
-		DP_TRAINING_PATTERN_DISABLE);
+	analogix_dp_write_byte_to_dpcd(dp, DP_TRAINING_PATTERN_SET,
+				       DP_TRAINING_PATTERN_DISABLE);
 }
 
-static void analogix_dp_set_lane_lane_pre_emphasis(struct analogix_dp_device *dp,
-					int pre_emphasis, int lane)
+static void
+analogix_dp_set_lane_lane_pre_emphasis(struct analogix_dp_device *dp,
+				       int pre_emphasis, int lane)
 {
 	switch (lane) {
 	case 0:
@@ -294,8 +290,7 @@ static int analogix_dp_link_start(struct analogix_dp_device *dp)
 	/* Setup RX configuration */
 	buf[0] = dp->link_train.link_rate;
 	buf[1] = dp->link_train.lane_count;
-	retval = analogix_dp_write_bytes_to_dpcd(dp, DP_LINK_BW_SET,
-				2, buf);
+	retval = analogix_dp_write_bytes_to_dpcd(dp, DP_LINK_BW_SET, 2, buf);
 	if (retval)
 		return retval;
 
@@ -331,7 +326,7 @@ static int analogix_dp_link_start(struct analogix_dp_device *dp)
 			    DP_TRAIN_VOLTAGE_SWING_LEVEL_0;
 
 	retval = analogix_dp_write_bytes_to_dpcd(dp, DP_TRAINING_LANE0_SET,
-			lane_count, buf);
+						 lane_count, buf);
 
 	return retval;
 }
@@ -339,7 +334,7 @@ static int analogix_dp_link_start(struct analogix_dp_device *dp)
 static unsigned char analogix_dp_get_lane_status(u8 link_status[2], int lane)
 {
 	int shift = (lane & 1) * 4;
-	u8 link_value = link_status[lane>>1];
+	u8 link_value = link_status[lane >> 1];
 
 	return (link_value >> shift) & 0xf;
 }
@@ -358,7 +353,7 @@ static int analogix_dp_clock_recovery_ok(u8 link_status[2], int lane_count)
 }
 
 static int analogix_dp_channel_eq_ok(u8 link_status[2], u8 link_align,
-				int lane_count)
+				     int lane_count)
 {
 	int lane;
 	u8 lane_status;
@@ -376,11 +371,11 @@ static int analogix_dp_channel_eq_ok(u8 link_status[2], u8 link_align,
 	return 0;
 }
 
-static unsigned char analogix_dp_get_adjust_request_voltage(u8 adjust_request[2],
-							int lane)
+static unsigned char
+analogix_dp_get_adjust_request_voltage(u8 adjust_request[2], int lane)
 {
 	int shift = (lane & 1) * 4;
-	u8 link_value = adjust_request[lane>>1];
+	u8 link_value = adjust_request[lane >> 1];
 
 	return (link_value >> shift) & 0x3;
 }
@@ -390,13 +385,13 @@ static unsigned char analogix_dp_get_adjust_request_pre_emphasis(
 					int lane)
 {
 	int shift = (lane & 1) * 4;
-	u8 link_value = adjust_request[lane>>1];
+	u8 link_value = adjust_request[lane >> 1];
 
 	return ((link_value >> shift) & 0xc) >> 2;
 }
 
 static void analogix_dp_set_lane_link_training(struct analogix_dp_device *dp,
-					u8 training_lane_set, int lane)
+					       u8 training_lane_set, int lane)
 {
 	switch (lane) {
 	case 0:
@@ -416,9 +411,9 @@ static void analogix_dp_set_lane_link_training(struct analogix_dp_device *dp,
 	}
 }
 
-static unsigned int analogix_dp_get_lane_link_training(
-				struct analogix_dp_device *dp,
-				int lane)
+static unsigned int
+analogix_dp_get_lane_link_training(struct analogix_dp_device *dp,
+				   int lane)
 {
 	u32 reg;
 
@@ -452,7 +447,7 @@ static void analogix_dp_reduce_link_rate(struct analogix_dp_device *dp)
 }
 
 static void analogix_dp_get_adjust_training_lane(struct analogix_dp_device *dp,
-					u8 adjust_request[2])
+						 u8 adjust_request[2])
 {
 	int lane, lane_count;
 	u8 voltage_swing, pre_emphasis, training_lane;
@@ -625,7 +620,7 @@ static int analogix_dp_process_equalizer_training(struct analogix_dp_device *dp)
 }
 
 static void analogix_dp_get_max_rx_bandwidth(struct analogix_dp_device *dp,
-					u8 *bandwidth)
+					     u8 *bandwidth)
 {
 	u8 data;
 
@@ -638,7 +633,7 @@ static void analogix_dp_get_max_rx_bandwidth(struct analogix_dp_device *dp,
 }
 
 static void analogix_dp_get_max_rx_lane_count(struct analogix_dp_device *dp,
-					u8 *lane_count)
+					      u8 *lane_count)
 {
 	u8 data;
 
@@ -651,8 +646,8 @@ static void analogix_dp_get_max_rx_lane_count(struct analogix_dp_device *dp,
 }
 
 static void analogix_dp_init_training(struct analogix_dp_device *dp,
-			enum link_lane_count_type max_lane,
-			enum link_rate_type max_rate)
+				      enum link_lane_count_type max_lane,
+				      enum link_rate_type max_rate)
 {
 	/*
 	 * MACRO_RST must be applied after the PLL_LOCK to avoid
@@ -665,7 +660,7 @@ static void analogix_dp_init_training(struct analogix_dp_device *dp,
 	analogix_dp_get_max_rx_lane_count(dp, &dp->link_train.lane_count);
 
 	if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
-	   (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
+	    (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
 		dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
 			dp->link_train.link_rate);
 		dp->link_train.link_rate = LINK_RATE_1_62GBPS;
@@ -725,8 +720,7 @@ static int analogix_dp_sw_link_training(struct analogix_dp_device *dp)
 }
 
 static int analogix_dp_set_link_train(struct analogix_dp_device *dp,
-				u32 count,
-				u32 bwtype)
+				      u32 count, u32 bwtype)
 {
 	int i;
 	int retval;
@@ -762,7 +756,7 @@ static int analogix_dp_config_video(struct analogix_dp_device *dp)
 		timeout_loop++;
 		if (analogix_dp_is_slave_video_stream_clock_on(dp) == 0)
 			break;
-		if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+		if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
 			dev_err(dp->dev, "Timeout of video streamclk ok\n");
 			return -ETIMEDOUT;
 		}
@@ -793,7 +787,7 @@ static int analogix_dp_config_video(struct analogix_dp_device *dp)
 		} else if (done_count) {
 			done_count = 0;
 		}
-		if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+		if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
 			dev_err(dp->dev, "Timeout of video streamclk ok\n");
 			return -ETIMEDOUT;
 		}
@@ -807,25 +801,24 @@ static int analogix_dp_config_video(struct analogix_dp_device *dp)
 	return retval;
 }
 
-static void analogix_dp_enable_scramble(struct analogix_dp_device *dp, bool enable)
+static void analogix_dp_enable_scramble(struct analogix_dp_device *dp,
+					bool enable)
 {
 	u8 data;
 
 	if (enable) {
 		analogix_dp_enable_scrambling(dp);
 
-		analogix_dp_read_byte_from_dpcd(dp,
-			DP_TRAINING_PATTERN_SET,
-			&data);
+		analogix_dp_read_byte_from_dpcd(dp, DP_TRAINING_PATTERN_SET,
+						&data);
 		analogix_dp_write_byte_to_dpcd(dp,
 			DP_TRAINING_PATTERN_SET,
 			(u8)(data & ~DP_LINK_SCRAMBLING_DISABLE));
 	} else {
 		analogix_dp_disable_scrambling(dp);
 
-		analogix_dp_read_byte_from_dpcd(dp,
-			DP_TRAINING_PATTERN_SET,
-			&data);
+		analogix_dp_read_byte_from_dpcd(dp, DP_TRAINING_PATTERN_SET,
+						&data);
 		analogix_dp_write_byte_to_dpcd(dp,
 			DP_TRAINING_PATTERN_SET,
 			(u8)(data | DP_LINK_SCRAMBLING_DISABLE));
@@ -898,7 +891,7 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)
 	}
 
 	ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
-					dp->video_info->link_rate);
+					 dp->video_info->link_rate);
 	if (ret) {
 		dev_err(dp->dev, "unable to do link train\n");
 		return;
@@ -1130,8 +1123,8 @@ static struct video_info *analogix_dp_dt_parse_pdata(struct device *dev)
 	struct device_node *dp_node = dev->of_node;
 	struct video_info *dp_video_config;
 
-	dp_video_config = devm_kzalloc(dev,
-				sizeof(*dp_video_config), GFP_KERNEL);
+	dp_video_config = devm_kzalloc(dev, sizeof(*dp_video_config),
+				       GFP_KERNEL);
 	if (!dp_video_config)
 		return ERR_PTR(-ENOMEM);
 
@@ -1145,37 +1138,37 @@ static struct video_info *analogix_dp_dt_parse_pdata(struct device *dev)
 		of_property_read_bool(dp_node, "interlaced");
 
 	if (of_property_read_u32(dp_node, "samsung,color-space",
-				&dp_video_config->color_space)) {
+				 &dp_video_config->color_space)) {
 		dev_err(dev, "failed to get color-space\n");
 		return ERR_PTR(-EINVAL);
 	}
 
 	if (of_property_read_u32(dp_node, "samsung,dynamic-range",
-				&dp_video_config->dynamic_range)) {
+				 &dp_video_config->dynamic_range)) {
 		dev_err(dev, "failed to get dynamic-range\n");
 		return ERR_PTR(-EINVAL);
 	}
 
 	if (of_property_read_u32(dp_node, "samsung,ycbcr-coeff",
-				&dp_video_config->ycbcr_coeff)) {
+				 &dp_video_config->ycbcr_coeff)) {
 		dev_err(dev, "failed to get ycbcr-coeff\n");
 		return ERR_PTR(-EINVAL);
 	}
 
 	if (of_property_read_u32(dp_node, "samsung,color-depth",
-				&dp_video_config->color_depth)) {
+				 &dp_video_config->color_depth)) {
 		dev_err(dev, "failed to get color-depth\n");
 		return ERR_PTR(-EINVAL);
 	}
 
 	if (of_property_read_u32(dp_node, "samsung,link-rate",
-				&dp_video_config->link_rate)) {
+				 &dp_video_config->link_rate)) {
 		dev_err(dev, "failed to get link-rate\n");
 		return ERR_PTR(-EINVAL);
 	}
 
 	if (of_property_read_u32(dp_node, "samsung,lane-count",
-				&dp_video_config->lane_count)) {
+				 &dp_video_config->lane_count)) {
 		dev_err(dev, "failed to get lane-count\n");
 		return ERR_PTR(-EINVAL);
 	}
@@ -1284,7 +1277,7 @@ int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
 	pm_runtime_enable(dev);
 
 	ret = devm_request_irq(&pdev->dev, dp->irq, analogix_dp_irq_handler,
-			irq_flags, "analogix-dp", dp);
+			       irq_flags, "analogix-dp", dp);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to request irq\n");
 		goto err_disable_pm_runtime;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 0fff745..d4c4ae2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -187,50 +187,55 @@ int analogix_dp_get_plug_in_status(struct analogix_dp_device *dp);
 void analogix_dp_enable_sw_function(struct analogix_dp_device *dp);
 int analogix_dp_start_aux_transaction(struct analogix_dp_device *dp);
 int analogix_dp_write_byte_to_dpcd(struct analogix_dp_device *dp,
-				unsigned int reg_addr,
-				unsigned char data);
+				   unsigned int reg_addr,
+				   unsigned char data);
 int analogix_dp_read_byte_from_dpcd(struct analogix_dp_device *dp,
-				unsigned int reg_addr,
-				unsigned char *data);
+				    unsigned int reg_addr,
+				    unsigned char *data);
 int analogix_dp_write_bytes_to_dpcd(struct analogix_dp_device *dp,
-				unsigned int reg_addr,
-				unsigned int count,
-				unsigned char data[]);
+				    unsigned int reg_addr,
+				    unsigned int count,
+				    unsigned char data[]);
 int analogix_dp_read_bytes_from_dpcd(struct analogix_dp_device *dp,
-				unsigned int reg_addr,
-				unsigned int count,
-				unsigned char data[]);
+				     unsigned int reg_addr,
+				     unsigned int count,
+				     unsigned char data[]);
 int analogix_dp_select_i2c_device(struct analogix_dp_device *dp,
-				unsigned int device_addr,
-				unsigned int reg_addr);
+				  unsigned int device_addr,
+				  unsigned int reg_addr);
 int analogix_dp_read_byte_from_i2c(struct analogix_dp_device *dp,
-				unsigned int device_addr,
-				unsigned int reg_addr,
-				unsigned int *data);
+				   unsigned int device_addr,
+				   unsigned int reg_addr,
+				   unsigned int *data);
 int analogix_dp_read_bytes_from_i2c(struct analogix_dp_device *dp,
-				unsigned int device_addr,
-				unsigned int reg_addr,
-				unsigned int count,
-				unsigned char edid[]);
+				    unsigned int device_addr,
+				    unsigned int reg_addr,
+				    unsigned int count,
+				    unsigned char edid[]);
 void analogix_dp_set_link_bandwidth(struct analogix_dp_device *dp, u32 bwtype);
 void analogix_dp_get_link_bandwidth(struct analogix_dp_device *dp, u32 *bwtype);
 void analogix_dp_set_lane_count(struct analogix_dp_device *dp, u32 count);
 void analogix_dp_get_lane_count(struct analogix_dp_device *dp, u32 *count);
-void analogix_dp_enable_enhanced_mode(struct analogix_dp_device *dp, bool enable);
+void analogix_dp_enable_enhanced_mode(struct analogix_dp_device *dp,
+				      bool enable);
 void analogix_dp_set_training_pattern(struct analogix_dp_device *dp,
-				enum pattern_set pattern);
-void analogix_dp_set_lane0_pre_emphasis(struct analogix_dp_device *dp, u32 level);
-void analogix_dp_set_lane1_pre_emphasis(struct analogix_dp_device *dp, u32 level);
-void analogix_dp_set_lane2_pre_emphasis(struct analogix_dp_device *dp, u32 level);
-void analogix_dp_set_lane3_pre_emphasis(struct analogix_dp_device *dp, u32 level);
+				      enum pattern_set pattern);
+void analogix_dp_set_lane0_pre_emphasis(struct analogix_dp_device *dp,
+					u32 level);
+void analogix_dp_set_lane1_pre_emphasis(struct analogix_dp_device *dp,
+					u32 level);
+void analogix_dp_set_lane2_pre_emphasis(struct analogix_dp_device *dp,
+					u32 level);
+void analogix_dp_set_lane3_pre_emphasis(struct analogix_dp_device *dp,
+					u32 level);
 void analogix_dp_set_lane0_link_training(struct analogix_dp_device *dp,
-				u32 training_lane);
+					 u32 training_lane);
 void analogix_dp_set_lane1_link_training(struct analogix_dp_device *dp,
-				u32 training_lane);
+					 u32 training_lane);
 void analogix_dp_set_lane2_link_training(struct analogix_dp_device *dp,
-				u32 training_lane);
+					 u32 training_lane);
 void analogix_dp_set_lane3_link_training(struct analogix_dp_device *dp,
-				u32 training_lane);
+					 u32 training_lane);
 u32 analogix_dp_get_lane0_link_training(struct analogix_dp_device *dp);
 u32 analogix_dp_get_lane1_link_training(struct analogix_dp_device *dp);
 u32 analogix_dp_get_lane2_link_training(struct analogix_dp_device *dp);
@@ -241,11 +246,12 @@ void analogix_dp_init_video(struct analogix_dp_device *dp);
 void analogix_dp_set_video_color_format(struct analogix_dp_device *dp);
 int analogix_dp_is_slave_video_stream_clock_on(struct analogix_dp_device *dp);
 void analogix_dp_set_video_cr_mn(struct analogix_dp_device *dp,
-			enum clock_recovery_m_value_type type,
-			u32 m_value,
-			u32 n_value);
+				 enum clock_recovery_m_value_type type,
+				 u32 m_value,
+				 u32 n_value);
 void analogix_dp_set_video_timing_mode(struct analogix_dp_device *dp, u32 type);
-void analogix_dp_enable_video_master(struct analogix_dp_device *dp, bool enable);
+void analogix_dp_enable_video_master(struct analogix_dp_device *dp,
+				     bool enable);
 void analogix_dp_start_video(struct analogix_dp_device *dp);
 int analogix_dp_is_video_stream_on(struct analogix_dp_device *dp);
 void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 442cc66..a388c0a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -54,10 +54,10 @@ void analogix_dp_lane_swap(struct analogix_dp_device *dp, bool enable)
 
 	if (enable)
 		reg = LANE3_MAP_LOGIC_LANE_0 | LANE2_MAP_LOGIC_LANE_1 |
-			LANE1_MAP_LOGIC_LANE_2 | LANE0_MAP_LOGIC_LANE_3;
+		      LANE1_MAP_LOGIC_LANE_2 | LANE0_MAP_LOGIC_LANE_3;
 	else
 		reg = LANE3_MAP_LOGIC_LANE_3 | LANE2_MAP_LOGIC_LANE_2 |
-			LANE1_MAP_LOGIC_LANE_1 | LANE0_MAP_LOGIC_LANE_0;
+		      LANE1_MAP_LOGIC_LANE_1 | LANE0_MAP_LOGIC_LANE_0;
 
 	writel(reg, dp->reg_base + ANALOGIX_DP_LANE_MAP);
 }
@@ -202,8 +202,8 @@ void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool enable)
 }
 
 void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
-				enum analog_power_block block,
-				bool enable)
+				       enum analog_power_block block,
+				       bool enable)
 {
 	u32 reg;
 
@@ -399,8 +399,8 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
 	analogix_dp_reset_aux(dp);
 
 	/* Disable AUX transaction H/W retry */
-	reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3) | AUX_HW_RETRY_COUNT_SEL(0)|
-		AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
+	reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3) | AUX_HW_RETRY_COUNT_SEL(0) |
+	      AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
 	writel(reg, dp->reg_base + ANALOGIX_DP_AUX_HW_RETRY_CTL);
 
 	/* Receive AUX Channel DEFER commands equal to DEFFER_COUNT*64 */
@@ -483,8 +483,8 @@ int analogix_dp_start_aux_transaction(struct analogix_dp_device *dp)
 }
 
 int analogix_dp_write_byte_to_dpcd(struct analogix_dp_device *dp,
-				unsigned int reg_addr,
-				unsigned char data)
+				   unsigned int reg_addr,
+				   unsigned char data)
 {
 	u32 reg;
 	int i;
@@ -519,17 +519,16 @@ int analogix_dp_write_byte_to_dpcd(struct analogix_dp_device *dp,
 		retval = analogix_dp_start_aux_transaction(dp);
 		if (retval == 0)
 			break;
-		else
-			dev_dbg(dp->dev, "%s: Aux Transaction fail!\n",
-				__func__);
+
+		dev_dbg(dp->dev, "%s: Aux Transaction fail!\n", __func__);
 	}
 
 	return retval;
 }
 
 int analogix_dp_read_byte_from_dpcd(struct analogix_dp_device *dp,
-				unsigned int reg_addr,
-				unsigned char *data)
+				    unsigned int reg_addr,
+				    unsigned char *data)
 {
 	u32 reg;
 	int i;
@@ -560,9 +559,8 @@ int analogix_dp_read_byte_from_dpcd(struct analogix_dp_device *dp,
 		retval = analogix_dp_start_aux_transaction(dp);
 		if (retval == 0)
 			break;
-		else
-			dev_dbg(dp->dev, "%s: Aux Transaction fail!\n",
-				__func__);
+
+		dev_dbg(dp->dev, "%s: Aux Transaction fail!\n", __func__);
 	}
 
 	/* Read data buffer */
@@ -573,9 +571,9 @@ int analogix_dp_read_byte_from_dpcd(struct analogix_dp_device *dp,
 }
 
 int analogix_dp_write_bytes_to_dpcd(struct analogix_dp_device *dp,
-				unsigned int reg_addr,
-				unsigned int count,
-				unsigned char data[])
+				    unsigned int reg_addr,
+				    unsigned int count,
+				    unsigned char data[])
 {
 	u32 reg;
 	unsigned int start_offset;
@@ -608,8 +606,9 @@ int analogix_dp_write_bytes_to_dpcd(struct analogix_dp_device *dp,
 			for (cur_data_idx = 0; cur_data_idx < cur_data_count;
 			     cur_data_idx++) {
 				reg = data[start_offset + cur_data_idx];
-				writel(reg, dp->reg_base + ANALOGIX_DP_BUF_DATA_0
-							  + 4 * cur_data_idx);
+				writel(reg, dp->reg_base +
+				       ANALOGIX_DP_BUF_DATA_0 +
+				       4 * cur_data_idx);
 			}
 
 			/*
@@ -625,9 +624,9 @@ int analogix_dp_write_bytes_to_dpcd(struct analogix_dp_device *dp,
 			retval = analogix_dp_start_aux_transaction(dp);
 			if (retval == 0)
 				break;
-			else
-				dev_dbg(dp->dev, "%s: Aux Transaction fail!\n",
-					__func__);
+
+			dev_dbg(dp->dev, "%s: Aux Transaction fail!\n",
+				__func__);
 		}
 
 		start_offset += cur_data_count;
@@ -637,9 +636,9 @@ int analogix_dp_write_bytes_to_dpcd(struct analogix_dp_device *dp,
 }
 
 int analogix_dp_read_bytes_from_dpcd(struct analogix_dp_device *dp,
-				unsigned int reg_addr,
-				unsigned int count,
-				unsigned char data[])
+				     unsigned int reg_addr,
+				     unsigned int count,
+				     unsigned char data[])
 {
 	u32 reg;
 	unsigned int start_offset;
@@ -683,9 +682,9 @@ int analogix_dp_read_bytes_from_dpcd(struct analogix_dp_device *dp,
 			retval = analogix_dp_start_aux_transaction(dp);
 			if (retval == 0)
 				break;
-			else
-				dev_dbg(dp->dev, "%s: Aux Transaction fail!\n",
-					__func__);
+
+			dev_dbg(dp->dev, "%s: Aux Transaction fail!\n",
+				__func__);
 		}
 
 		for (cur_data_idx = 0; cur_data_idx < cur_data_count;
@@ -703,8 +702,8 @@ int analogix_dp_read_bytes_from_dpcd(struct analogix_dp_device *dp,
 }
 
 int analogix_dp_select_i2c_device(struct analogix_dp_device *dp,
-				unsigned int device_addr,
-				unsigned int reg_addr)
+				  unsigned int device_addr,
+				  unsigned int reg_addr)
 {
 	u32 reg;
 	int retval;
@@ -736,9 +735,9 @@ int analogix_dp_select_i2c_device(struct analogix_dp_device *dp,
 }
 
 int analogix_dp_read_byte_from_i2c(struct analogix_dp_device *dp,
-				unsigned int device_addr,
-				unsigned int reg_addr,
-				unsigned int *data)
+				   unsigned int device_addr,
+				   unsigned int reg_addr,
+				   unsigned int *data)
 {
 	u32 reg;
 	int i;
@@ -750,7 +749,8 @@ int analogix_dp_read_byte_from_i2c(struct analogix_dp_device *dp,
 		writel(reg, dp->reg_base + ANALOGIX_DP_BUFFER_DATA_CTL);
 
 		/* Select EDID device */
-		retval = analogix_dp_select_i2c_device(dp, device_addr, reg_addr);
+		retval = analogix_dp_select_i2c_device(dp, device_addr,
+						       reg_addr);
 		if (retval != 0)
 			continue;
 
@@ -767,9 +767,8 @@ int analogix_dp_read_byte_from_i2c(struct analogix_dp_device *dp,
 		retval = analogix_dp_start_aux_transaction(dp);
 		if (retval == 0)
 			break;
-		else
-			dev_dbg(dp->dev, "%s: Aux Transaction fail!\n",
-				__func__);
+
+		dev_dbg(dp->dev, "%s: Aux Transaction fail!\n", __func__);
 	}
 
 	/* Read data */
@@ -780,10 +779,10 @@ int analogix_dp_read_byte_from_i2c(struct analogix_dp_device *dp,
 }
 
 int analogix_dp_read_bytes_from_i2c(struct analogix_dp_device *dp,
-				unsigned int device_addr,
-				unsigned int reg_addr,
-				unsigned int count,
-				unsigned char edid[])
+				    unsigned int device_addr,
+				    unsigned int reg_addr,
+				    unsigned int count,
+				    unsigned char edid[])
 {
 	u32 reg;
 	unsigned int i, j;
@@ -828,15 +827,14 @@ int analogix_dp_read_bytes_from_i2c(struct analogix_dp_device *dp,
 				retval = analogix_dp_start_aux_transaction(dp);
 				if (retval == 0)
 					break;
-				else
-					dev_dbg(dp->dev,
-						"%s: Aux Transaction fail!\n",
-						__func__);
+
+				dev_dbg(dp->dev, "%s: Aux Transaction fail!\n",
+					__func__);
 			}
 			/* Check if Rx sends defer */
 			reg = readl(dp->reg_base + ANALOGIX_DP_AUX_RX_COMM);
 			if (reg == AUX_RX_COMM_AUX_DEFER ||
-				reg == AUX_RX_COMM_I2C_DEFER) {
+			    reg == AUX_RX_COMM_I2C_DEFER) {
 				dev_err(dp->dev, "Defer: %d\n\n", reg);
 				defer = 1;
 			}
@@ -885,7 +883,8 @@ void analogix_dp_get_lane_count(struct analogix_dp_device *dp, u32 *count)
 	*count = reg;
 }
 
-void analogix_dp_enable_enhanced_mode(struct analogix_dp_device *dp, bool enable)
+void analogix_dp_enable_enhanced_mode(struct analogix_dp_device *dp,
+				      bool enable)
 {
 	u32 reg;
 
@@ -901,7 +900,7 @@ void analogix_dp_enable_enhanced_mode(struct analogix_dp_device *dp, bool enable
 }
 
 void analogix_dp_set_training_pattern(struct analogix_dp_device *dp,
-				enum pattern_set pattern)
+				      enum pattern_set pattern)
 {
 	u32 reg;
 
@@ -933,7 +932,8 @@ void analogix_dp_set_training_pattern(struct analogix_dp_device *dp,
 	}
 }
 
-void analogix_dp_set_lane0_pre_emphasis(struct analogix_dp_device *dp, u32 level)
+void analogix_dp_set_lane0_pre_emphasis(struct analogix_dp_device *dp,
+					u32 level)
 {
 	u32 reg;
 
@@ -943,7 +943,8 @@ void analogix_dp_set_lane0_pre_emphasis(struct analogix_dp_device *dp, u32 level
 	writel(reg, dp->reg_base + ANALOGIX_DP_LN0_LINK_TRAINING_CTL);
 }
 
-void analogix_dp_set_lane1_pre_emphasis(struct analogix_dp_device *dp, u32 level)
+void analogix_dp_set_lane1_pre_emphasis(struct analogix_dp_device *dp,
+					u32 level)
 {
 	u32 reg;
 
@@ -953,7 +954,8 @@ void analogix_dp_set_lane1_pre_emphasis(struct analogix_dp_device *dp, u32 level
 	writel(reg, dp->reg_base + ANALOGIX_DP_LN1_LINK_TRAINING_CTL);
 }
 
-void analogix_dp_set_lane2_pre_emphasis(struct analogix_dp_device *dp, u32 level)
+void analogix_dp_set_lane2_pre_emphasis(struct analogix_dp_device *dp,
+					u32 level)
 {
 	u32 reg;
 
@@ -963,7 +965,8 @@ void analogix_dp_set_lane2_pre_emphasis(struct analogix_dp_device *dp, u32 level
 	writel(reg, dp->reg_base + ANALOGIX_DP_LN2_LINK_TRAINING_CTL);
 }
 
-void analogix_dp_set_lane3_pre_emphasis(struct analogix_dp_device *dp, u32 level)
+void analogix_dp_set_lane3_pre_emphasis(struct analogix_dp_device *dp,
+					u32 level)
 {
 	u32 reg;
 
@@ -974,7 +977,7 @@ void analogix_dp_set_lane3_pre_emphasis(struct analogix_dp_device *dp, u32 level
 }
 
 void analogix_dp_set_lane0_link_training(struct analogix_dp_device *dp,
-					u32 training_lane)
+					 u32 training_lane)
 {
 	u32 reg;
 
@@ -983,7 +986,7 @@ void analogix_dp_set_lane0_link_training(struct analogix_dp_device *dp,
 }
 
 void analogix_dp_set_lane1_link_training(struct analogix_dp_device *dp,
-					u32 training_lane)
+					 u32 training_lane)
 {
 	u32 reg;
 
@@ -1001,7 +1004,7 @@ void analogix_dp_set_lane2_link_training(struct analogix_dp_device *dp,
 }
 
 void analogix_dp_set_lane3_link_training(struct analogix_dp_device *dp,
-					u32 training_lane)
+					 u32 training_lane)
 {
 	u32 reg;
 
@@ -1125,9 +1128,8 @@ int analogix_dp_is_slave_video_stream_clock_on(struct analogix_dp_device *dp)
 }
 
 void analogix_dp_set_video_cr_mn(struct analogix_dp_device *dp,
-		enum clock_recovery_m_value_type type,
-		u32 m_value,
-		u32 n_value)
+				 enum clock_recovery_m_value_type type,
+				 u32 m_value, u32 n_value)
 {
 	u32 reg;
 
@@ -1221,7 +1223,7 @@ void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp)
 	u32 reg;
 
 	reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
-	reg &= ~(MASTER_VID_FUNC_EN_N|SLAVE_VID_FUNC_EN_N);
+	reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
 	reg |= MASTER_VID_FUNC_EN_N;
 	writel(reg, dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
 
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c
index c6519b9..7650b2b 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -157,7 +157,7 @@ static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
 	int ret;
 
 	ret = of_get_videomode(dp->dev->of_node, &dp->priv.vm,
-			OF_USE_NATIVE_MODE);
+			       OF_USE_NATIVE_MODE);
 	if (ret) {
 		DRM_ERROR("failed: of_get_videomode() : %d\n", ret);
 		return ret;
@@ -214,7 +214,7 @@ static int exynos_dp_bind(struct device *dev, struct device *master, void *data)
 }
 
 static void exynos_dp_unbind(struct device *dev, struct device *master,
-				void *data)
+			     void *data)
 {
 	return analogix_dp_unbind(dev, master, data);
 }
@@ -231,7 +231,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
 	struct exynos_dp_device *dp;
 
 	dp = devm_kzalloc(&pdev->dev, sizeof(struct exynos_dp_device),
-				GFP_KERNEL);
+			  GFP_KERNEL);
 	if (!dp)
 		return -ENOMEM;
 
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:10:26 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:10:26 +0800
Subject: [PATCH v14 07/17] dt-bindings: add document for analogix display port
 driver
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534626-1781-1-git-send-email-ykk@rock-chips.com>

Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt

Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
Acked-by: Rob Herring <robh at kernel.org>
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10:
- Add the ack from Rob Herring

Changes in v9: None
Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Split all DTS changes, and provide backward compatibility. Mark old
  properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
    "analogix,color-space" & "analogix,color-depth"   &
    "analogix,link-rate"   & "analogix,lane-count"    &
    "analogix,ycbcr-coeff" & "analogix,dynamic-range" &
    "vsync-active-high"    & "hsync-active-high"      & "interlaces"

Changes in v3:
- Add devicetree binding documents. (Heiko)
- Remove sync pol & colorimetry properies from the new analogix dp driver
  devicetree binding. (Thierry)
- Update the exist exynos dtsi file with the latest DP DT properies.

Changes in v2: None

 .../bindings/display/bridge/analogix_dp.txt        | 50 ++++++++++++
 .../bindings/display/exynos/exynos_dp.txt          | 92 ++++++----------------
 2 files changed, 76 insertions(+), 66 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix_dp.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
new file mode 100644
index 0000000..7659a7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -0,0 +1,50 @@
+Analogix Display Port bridge bindings
+
+Required properties for dp-controller:
+	-compatible:
+		platform specific such as:
+		 * "samsung,exynos5-dp"
+		 * "rockchip,rk3288-dp"
+	-reg:
+		physical base address of the controller and length
+		of memory mapped region.
+	-interrupts:
+		interrupt combiner values.
+	-clocks:
+		from common clock binding: handle to dp clock.
+	-clock-names:
+		from common clock binding: Shall be "dp".
+	-interrupt-parent:
+		phandle to Interrupt combiner node.
+	-phys:
+		from general PHY binding: the phandle for the PHY device.
+	-phy-names:
+		from general PHY binding: Should be "dp".
+
+Optional properties for dp-controller:
+	-hpd-gpios:
+		Hotplug detect GPIO.
+		Indicates which GPIO should be used for hotplug detection
+	-port@[X]: SoC specific port nodes with endpoint definitions as defined
+		in Documentation/devicetree/bindings/media/video-interfaces.txt,
+		please refer to the SoC specific binding document:
+		* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+		* Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+-------------------------------------------------------------------------------
+
+Example:
+
+	dp-controller {
+		compatible = "samsung,exynos5-dp";
+		reg = <0x145b0000 0x10000>;
+		interrupts = <10 3>;
+		interrupt-parent = <&combiner>;
+		clocks = <&clock 342>;
+		clock-names = "dp";
+
+		phys = <&dp_phy>;
+		phy-names = "dp";
+	};
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index fe4a7a2..4fa8aca 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -1,20 +1,3 @@
-Device-Tree bindings for Samsung Exynos Embedded DisplayPort Transmitter(eDP)
-
-DisplayPort is industry standard to accommodate the growing board adoption
-of digital display technology within the PC and CE industries.
-It consolidates the internal and external connection methods to reduce device
-complexity and cost. It also supports necessary features for important cross
-industry applications and provides performance scalability to enable the next
-generation of displays that feature higher color depths, refresh rates, and
-display resolutions.
-
-eDP (embedded display port) device is compliant with Embedded DisplayPort
-standard as follows,
-- DisplayPort standard 1.1a for Exynos5250 and Exynos5260.
-- DisplayPort standard 1.3 for Exynos5422s and Exynos5800.
-
-eDP resides between FIMD and panel or FIMD and bridge such as LVDS.
-
 The Exynos display port interface should be configured based on
 the type of panel connected to it.
 
@@ -48,26 +31,6 @@ Required properties for dp-controller:
 		from general PHY binding: the phandle for the PHY device.
 	-phy-names:
 		from general PHY binding: Should be "dp".
-	-samsung,color-space:
-		input video data format.
-			COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
-	-samsung,dynamic-range:
-		dynamic range for input video data.
-			VESA = 0, CEA = 1
-	-samsung,ycbcr-coeff:
-		YCbCr co-efficients for input video.
-			COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
-	-samsung,color-depth:
-		number of bits per colour component.
-			COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
-	-samsung,link-rate:
-		link rate supported by the panel.
-			LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
-	-samsung,lane-count:
-		number of lanes supported by the panel.
-			LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
-	- display-timings: timings for the connected panel as described by
-		Documentation/devicetree/bindings/display/display-timing.txt
 
 Optional properties for dp-controller:
 	-interlaced:
@@ -83,17 +46,30 @@ Optional properties for dp-controller:
 		Hotplug detect GPIO.
 			Indicates which GPIO should be used for hotplug
 			detection
-Video interfaces:
-  Device node can contain video interface port nodes according to [1].
-  The following are properties specific to those nodes:
-
-  endpoint node connected to bridge or panel node:
-   - remote-endpoint: specifies the endpoint in panel or bridge node.
-		      This node is required in all kinds of exynos dp
-		      to represent the connection between dp and bridge
-		      or dp and panel.
-
-[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+	-video interfaces: Device node can contain video interface port
+			nodes according to [1].
+	- display-timings: timings for the connected panel as described by
+		Documentation/devicetree/bindings/display/panel/display-timing.txt
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+	-phys (required)
+	-phy-names (required)
+	-hpd-gpios (optional)
+
+Deprecated properties for DisplayPort:
+-interlaced:            deprecated prop that can parsed from drm_display_mode.
+-vsync-active-high:     deprecated prop that can parsed from drm_display_mode.
+-hsync-active-high:     deprecated prop that can parsed from drm_display_mode.
+-samsung,ycbcr-coeff:   deprecated prop that can parsed from drm_display_mode.
+-samsung,dynamic-range: deprecated prop that can parsed from drm_display_mode.
+-samsung,color-space:   deprecated prop that can parsed from drm_display_info.
+-samsung,color-depth:   deprecated prop that can parsed from drm_display_info.
+-samsung,link-rate:     deprecated prop that can reading from monitor by dpcd method.
+-samsung,lane-count:    deprecated prop that can reading from monitor by dpcd method.
+-samsung,hpd-gpio:      deprecated name for hpd-gpios.
+
+-------------------------------------------------------------------------------
 
 Example:
 
@@ -112,13 +88,6 @@ SOC specific portion:
 
 Board Specific portion:
 	dp-controller {
-		samsung,color-space = <0>;
-		samsung,dynamic-range = <0>;
-		samsung,ycbcr-coeff = <0>;
-		samsung,color-depth = <1>;
-		samsung,link-rate = <0x0a>;
-		samsung,lane-count = <4>;
-
 		display-timings {
 			native-mode = <&lcd_timing>;
 			lcd_timing: 1366x768 {
@@ -135,18 +104,9 @@ Board Specific portion:
 		};
 
 		ports {
-			port {
+			port at 0 {
 				dp_out: endpoint {
-					remote-endpoint = <&dp_in>;
-				};
-			};
-		};
-
-		panel {
-			...
-			port {
-				dp_in: endpoint {
-					remote-endpoint = <&dp_out>;
+					remote-endpoint = <&bridge_in>;
 				};
 			};
 		};
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:10:31 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:10:31 +0800
Subject: [PATCH v14 08/17] ARM: dts: exynos/dp: remove some properties that
 deprecated by analogix_dp driver
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534631-1833-1-git-send-email-ykk@rock-chips.com>

After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.

Beside the backward compatibility is fully preserved, so there are no
bisectability break that make this change in a separate patch.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
Tested-by: Javier Martinez Canillas <javier at osg.samsung.com>
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- Fix Peach Pit hpd property name error:
-       hpd-gpio = <&gpx2 6 0>;
+       hpd-gpios = <&gpx2 6 0>;

Changes in v5:
- Correct the misspell in commit message. (Krzysztof)

Changes in v4:
- Separate all DTS changes to a separate patch. (Krzysztof)

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-arndale.dts      | 2 --
 arch/arm/boot/dts/exynos5250-smdk5250.dts     | 2 --
 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +---
 arch/arm/boot/dts/exynos5250-spring.dts       | 4 +---
 arch/arm/boot/dts/exynos5420-peach-pit.dts    | 4 +---
 arch/arm/boot/dts/exynos5420-smdk5420.dts     | 2 --
 arch/arm/boot/dts/exynos5800-peach-pi.dts     | 2 --
 7 files changed, 3 insertions(+), 17 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index c000532..b1790cf 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -124,8 +124,6 @@
 &dp {
 	status = "okay";
 	samsung,color-space = <0>;
-	samsung,dynamic-range = <0>;
-	samsung,ycbcr-coeff = <0>;
 	samsung,color-depth = <1>;
 	samsung,link-rate = <0x0a>;
 	samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 0f5dcd4..f30c2db 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -80,8 +80,6 @@
 
 &dp {
 	samsung,color-space = <0>;
-	samsung,dynamic-range = <0>;
-	samsung,ycbcr-coeff = <0>;
 	samsung,color-depth = <1>;
 	samsung,link-rate = <0x0a>;
 	samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 5cb33ba..b96624b 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -236,12 +236,10 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&dp_hpd>;
 	samsung,color-space = <0>;
-	samsung,dynamic-range = <0>;
-	samsung,ycbcr-coeff = <0>;
 	samsung,color-depth = <1>;
 	samsung,link-rate = <0x0a>;
 	samsung,lane-count = <2>;
-	samsung,hpd-gpio = <&gpx0 7 GPIO_ACTIVE_HIGH>;
+	hpd-gpios = <&gpx0 7 GPIO_ACTIVE_HIGH>;
 
 	ports {
 		port at 0 {
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts b/arch/arm/boot/dts/exynos5250-spring.dts
index c1edd6d..91881d7 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -74,12 +74,10 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&dp_hpd_gpio>;
 	samsung,color-space = <0>;
-	samsung,dynamic-range = <0>;
-	samsung,ycbcr-coeff = <0>;
 	samsung,color-depth = <1>;
 	samsung,link-rate = <0x0a>;
 	samsung,lane-count = <1>;
-	samsung,hpd-gpio = <&gpc3 0 GPIO_ACTIVE_HIGH>;
+	hpd-gpios = <&gpc3 0 GPIO_ACTIVE_HIGH>;
 };
 
 &ehci {
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 35cfb07..2f37c87 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -148,12 +148,10 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&dp_hpd_gpio>;
 	samsung,color-space = <0>;
-	samsung,dynamic-range = <0>;
-	samsung,ycbcr-coeff = <0>;
 	samsung,color-depth = <1>;
 	samsung,link-rate = <0x06>;
 	samsung,lane-count = <2>;
-	samsung,hpd-gpio = <&gpx2 6 GPIO_ACTIVE_HIGH>;
+	hpd-gpios = <&gpx2 6 GPIO_ACTIVE_HIGH>;
 
 	ports {
 		port at 0 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index ac35aef..f67344f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -93,8 +93,6 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&dp_hpd>;
 	samsung,color-space = <0>;
-	samsung,dynamic-range = <0>;
-	samsung,ycbcr-coeff = <0>;
 	samsung,color-depth = <1>;
 	samsung,link-rate = <0x0a>;
 	samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 064176f..5d33fb2 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -148,8 +148,6 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&dp_hpd_gpio>;
 	samsung,color-space = <0>;
-	samsung,dynamic-range = <0>;
-	samsung,ycbcr-coeff = <0>;
 	samsung,color-depth = <1>;
 	samsung,link-rate = <0x0a>;
 	samsung,lane-count = <2>;
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:10:40 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:10:40 +0800
Subject: [PATCH v14 09/17] drm: rockchip: dp: add rockchip platform dp driver
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534640-1877-1-git-send-email-ykk@rock-chips.com>

Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
Tested-by: Javier Martinez Canillas <javier at osg.samsung.com>
---
Changes in v14: None
Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function. (Heiko)

Changes in v12: None
Changes in v11: None
Changes in v10:
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)

Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Remove the empty line at the end of document, and correct the endpoint
  numbers in the example DT node, and remove the regulator iomux setting
  in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
  support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)

Changes in v4:
- Remove some deprecated DT properties in rockchip dp document.

Changes in v3:
- Leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m",
  and leave "sclk_edp" to analogix dp core driver which name to "dp",
  and leave "pclk_edp" to rockchip dp platform driver which name to
  "pclk". (Thierry & Heiko)
- Add devicetree binding document. (Heiko)
- Remove "rockchip,panel" DT property, take use of remote point to get panel
  node. (Heiko)
- Add the new function point dp_platdata->get_modes() init.

Changes in v2:
- Get panel node with remote-endpoint method, and create devicetree binding
  for driver. (Heiko)
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
  leave those clock to rockchip dp phy driver.

 drivers/gpu/drm/rockchip/Kconfig                |   9 +
 drivers/gpu/drm/rockchip/Makefile               |   1 +
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 384 ++++++++++++++++++++++++
 include/drm/bridge/analogix_dp.h                |   1 +
 4 files changed, 395 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 8573985..9fe4e32 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -35,3 +35,12 @@ config ROCKCHIP_DW_MIPI_DSI
 	 for the Synopsys DesignWare HDMI driver. If you want to
 	 enable MIPI DSI on RK3288 based SoC, you should selet this
 	 option.
+
+config ROCKCHIP_ANALOGIX_DP
+	tristate "Rockchip specific extensions for Analogix DP driver"
+	depends on DRM_ROCKCHIP
+	select DRM_ANALOGIX_DP
+	help
+	  This selects support for Rockchip SoC specific extensions
+	  for the Analogix Core DP driver. If you want to enable DP
+	  on RK3288 based SoC, you should selet this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile
index f6a809a..921fabf 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -8,5 +8,6 @@ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
 
 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
+obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
new file mode 100644
index 0000000..b7af1b7
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -0,0 +1,384 @@
+/*
+ * Rockchip SoC DP (Display Port) interface driver.
+ *
+ * Copyright (C) Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Andy Yan <andy.yan at rock-chips.com>
+ *         Yakir Yang <ykk at rock-chips.com>
+ *         Jeff Chen <jeff.chen at rock-chips.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/component.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of_graph.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <linux/clk.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_dp_helper.h>
+#include <drm/drm_of.h>
+#include <drm/drm_panel.h>
+
+#include <video/of_videomode.h>
+#include <video/videomode.h>
+
+#include <drm/bridge/analogix_dp.h>
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define to_dp(nm)	container_of(nm, struct rockchip_dp_device, nm)
+
+/* dp grf register offset */
+#define GRF_SOC_CON6                            0x025c
+#define GRF_EDP_LCD_SEL_MASK                    BIT(5)
+#define GRF_EDP_SEL_VOP_LIT                     BIT(5)
+#define GRF_EDP_SEL_VOP_BIG                     0
+
+struct rockchip_dp_device {
+	struct drm_device        *drm_dev;
+	struct device            *dev;
+	struct drm_encoder       encoder;
+	struct drm_display_mode  mode;
+
+	struct clk               *pclk;
+	struct regmap            *grf;
+	struct reset_control     *rst;
+
+	struct analogix_dp_plat_data plat_data;
+};
+
+static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
+{
+	reset_control_assert(dp->rst);
+	usleep_range(10, 20);
+	reset_control_deassert(dp->rst);
+
+	return 0;
+}
+
+static int rockchip_dp_poweron(struct analogix_dp_plat_data *plat_data)
+{
+	struct rockchip_dp_device *dp = to_dp(plat_data);
+	int ret;
+
+	ret = clk_prepare_enable(dp->pclk);
+	if (ret < 0) {
+		dev_err(dp->dev, "failed to enable pclk %d\n", ret);
+		return ret;
+	}
+
+	ret = rockchip_dp_pre_init(dp);
+	if (ret < 0) {
+		dev_err(dp->dev, "failed to dp pre init %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int rockchip_dp_powerdown(struct analogix_dp_plat_data *plat_data)
+{
+	struct rockchip_dp_device *dp = to_dp(plat_data);
+
+	clk_disable_unprepare(dp->pclk);
+
+	return 0;
+}
+
+static bool
+rockchip_dp_drm_encoder_mode_fixup(struct drm_encoder *encoder,
+				   const struct drm_display_mode *mode,
+				   struct drm_display_mode *adjusted_mode)
+{
+	/* do nothing */
+	return true;
+}
+
+static void rockchip_dp_drm_encoder_mode_set(struct drm_encoder *encoder,
+					     struct drm_display_mode *mode,
+					     struct drm_display_mode *adjusted)
+{
+	/* do nothing */
+}
+
+static void rockchip_dp_drm_encoder_enable(struct drm_encoder *encoder)
+{
+	struct rockchip_dp_device *dp = to_dp(encoder);
+	int ret;
+	u32 val;
+
+	/*
+	 * FIXME(Yakir): driver should configure the CRTC output video
+	 * mode with the display information which indicated the monitor
+	 * support colorimetry.
+	 *
+	 * But don't know why the CRTC driver seems could only output the
+	 * RGBaaa rightly. For example, if connect the "innolux,n116bge"
+	 * eDP screen, EDID would indicated that screen only accepted the
+	 * 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
+	 * screen would show a blue picture (RGB888 show a green picture).
+	 * But if I configure CTRC to RGBaaa, and eDP driver still keep
+	 * RGB666 input video mode, then screen would works prefect.
+	 */
+	ret = rockchip_drm_crtc_mode_config(encoder->crtc,
+					    DRM_MODE_CONNECTOR_eDP,
+					    ROCKCHIP_OUT_MODE_AAAA);
+	if (ret < 0) {
+		dev_err(dp->dev, "Could not set crtc mode config (%d)\n", ret);
+		return;
+	}
+
+	ret = rockchip_drm_encoder_get_mux_id(dp->dev->of_node, encoder);
+	if (ret < 0)
+		return;
+
+	if (ret)
+		val = GRF_EDP_SEL_VOP_LIT | (GRF_EDP_LCD_SEL_MASK << 16);
+	else
+		val = GRF_EDP_SEL_VOP_BIG | (GRF_EDP_LCD_SEL_MASK << 16);
+
+	dev_dbg(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
+
+	ret = regmap_write(dp->grf, GRF_SOC_CON6, val);
+	if (ret != 0) {
+		dev_err(dp->dev, "Could not write to GRF: %d\n", ret);
+		return;
+	}
+}
+
+static void rockchip_dp_drm_encoder_nop(struct drm_encoder *encoder)
+{
+	/* do nothing */
+}
+
+static struct drm_encoder_helper_funcs rockchip_dp_encoder_helper_funcs = {
+	.mode_fixup = rockchip_dp_drm_encoder_mode_fixup,
+	.mode_set = rockchip_dp_drm_encoder_mode_set,
+	.enable = rockchip_dp_drm_encoder_enable,
+	.disable = rockchip_dp_drm_encoder_nop,
+};
+
+static void rockchip_dp_drm_encoder_destroy(struct drm_encoder *encoder)
+{
+	drm_encoder_cleanup(encoder);
+}
+
+static struct drm_encoder_funcs rockchip_dp_encoder_funcs = {
+	.destroy = rockchip_dp_drm_encoder_destroy,
+};
+
+static int rockchip_dp_init(struct rockchip_dp_device *dp)
+{
+	struct device *dev = dp->dev;
+	struct device_node *np = dev->of_node;
+	int ret;
+
+	dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+	if (IS_ERR(dp->grf)) {
+		dev_err(dev, "failed to get rockchip,grf property\n");
+		return PTR_ERR(dp->grf);
+	}
+
+	dp->pclk = devm_clk_get(dev, "pclk");
+	if (IS_ERR(dp->pclk)) {
+		dev_err(dev, "failed to get pclk property\n");
+		return PTR_ERR(dp->pclk);
+	}
+
+	dp->rst = devm_reset_control_get(dev, "dp");
+	if (IS_ERR(dp->rst)) {
+		dev_err(dev, "failed to get dp reset control\n");
+		return PTR_ERR(dp->rst);
+	}
+
+	ret = clk_prepare_enable(dp->pclk);
+	if (ret < 0) {
+		dev_err(dp->dev, "failed to enable pclk %d\n", ret);
+		return ret;
+	}
+
+	ret = rockchip_dp_pre_init(dp);
+	if (ret < 0) {
+		dev_err(dp->dev, "failed to pre init %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int rockchip_dp_drm_create_encoder(struct rockchip_dp_device *dp)
+{
+	struct drm_encoder *encoder = &dp->encoder;
+	struct drm_device *drm_dev = dp->drm_dev;
+	struct device *dev = dp->dev;
+	int ret;
+
+	encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
+							     dev->of_node);
+	DRM_DEBUG_KMS("possible_crtcs = 0x%x\n", encoder->possible_crtcs);
+
+	ret = drm_encoder_init(drm_dev, encoder, &rockchip_dp_encoder_funcs,
+			       DRM_MODE_ENCODER_TMDS, NULL);
+	if (ret) {
+		DRM_ERROR("failed to initialize encoder with drm\n");
+		return ret;
+	}
+
+	drm_encoder_helper_add(encoder, &rockchip_dp_encoder_helper_funcs);
+
+	return 0;
+}
+
+static int rockchip_dp_bind(struct device *dev, struct device *master,
+			    void *data)
+{
+	struct rockchip_dp_device *dp = dev_get_drvdata(dev);
+	struct drm_device *drm_dev = data;
+	int ret;
+
+	/*
+	 * Just like the probe function said, we don't need the
+	 * device drvrate anymore, we should leave the charge to
+	 * analogix dp driver, set the device drvdata to NULL.
+	 */
+	dev_set_drvdata(dev, NULL);
+
+	ret = rockchip_dp_init(dp);
+	if (ret < 0)
+		return ret;
+
+	dp->drm_dev = drm_dev;
+
+	ret = rockchip_dp_drm_create_encoder(dp);
+	if (ret) {
+		DRM_ERROR("failed to create drm encoder\n");
+		return ret;
+	}
+
+	dp->plat_data.encoder = &dp->encoder;
+
+	dp->plat_data.dev_type = RK3288_DP;
+	dp->plat_data.power_on = rockchip_dp_poweron;
+	dp->plat_data.power_off = rockchip_dp_powerdown;
+
+	return analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
+}
+
+static void rockchip_dp_unbind(struct device *dev, struct device *master,
+			       void *data)
+{
+	return analogix_dp_unbind(dev, master, data);
+}
+
+static const struct component_ops rockchip_dp_component_ops = {
+	.bind = rockchip_dp_bind,
+	.unbind = rockchip_dp_unbind,
+};
+
+static int rockchip_dp_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *panel_node, *port, *endpoint;
+	struct rockchip_dp_device *dp;
+	struct drm_panel *panel;
+
+	port = of_graph_get_port_by_id(dev->of_node, 1);
+	if (!port) {
+		dev_err(dev, "can't find output port\n");
+		return -EINVAL;
+	}
+
+	endpoint = of_get_child_by_name(port, "endpoint");
+	of_node_put(port);
+	if (!endpoint) {
+		dev_err(dev, "no output endpoint found\n");
+		return -EINVAL;
+	}
+
+	panel_node = of_graph_get_remote_port_parent(endpoint);
+	of_node_put(endpoint);
+	if (!panel_node) {
+		dev_err(dev, "no output node found\n");
+		return -EINVAL;
+	}
+
+	panel = of_drm_find_panel(panel_node);
+	if (!panel) {
+		DRM_ERROR("failed to find panel\n");
+		of_node_put(panel_node);
+		return -EPROBE_DEFER;
+	}
+
+	of_node_put(panel_node);
+
+	dp = devm_kzalloc(dev, sizeof(*dp), GFP_KERNEL);
+	if (!dp)
+		return -ENOMEM;
+
+	dp->dev = dev;
+
+	dp->plat_data.panel = panel;
+
+	/*
+	 * We just use the drvdata until driver run into component
+	 * add function, and then we would set drvdata to null, so
+	 * that analogix dp driver could take charge of the drvdata.
+	 */
+	platform_set_drvdata(pdev, dp);
+
+	return component_add(dev, &rockchip_dp_component_ops);
+}
+
+static int rockchip_dp_remove(struct platform_device *pdev)
+{
+	component_del(&pdev->dev, &rockchip_dp_component_ops);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int rockchip_dp_suspend(struct device *dev)
+{
+	return analogix_dp_suspend(dev);
+}
+
+static int rockchip_dp_resume(struct device *dev)
+{
+	return analogix_dp_resume(dev);
+}
+#endif
+
+static const struct dev_pm_ops rockchip_dp_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(rockchip_dp_suspend, rockchip_dp_resume)
+};
+
+static const struct of_device_id rockchip_dp_dt_ids[] = {
+	{.compatible = "rockchip,rk3288-dp",},
+	{}
+};
+MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
+
+static struct platform_driver rockchip_dp_driver = {
+	.probe = rockchip_dp_probe,
+	.remove = rockchip_dp_remove,
+	.driver = {
+		   .name = "rockchip-dp",
+		   .owner = THIS_MODULE,
+		   .pm = &rockchip_dp_pm_ops,
+		   .of_match_table = of_match_ptr(rockchip_dp_dt_ids),
+	},
+};
+
+module_platform_driver(rockchip_dp_driver);
+
+MODULE_AUTHOR("Yakir Yang <ykk at rock-chips.com>");
+MODULE_AUTHOR("Jeff chen <jeff.chen at rock-chips.com>");
+MODULE_DESCRIPTION("Rockchip Specific Analogix-DP Driver Extension");
+MODULE_LICENSE("GPL v2");
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index d1188db..25afb31 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -15,6 +15,7 @@
 
 enum analogix_dp_devtype {
 	EXYNOS_DP,
+	RK3288_DP,
 };
 
 struct analogix_dp_plat_data {
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:10:54 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:10:54 +0800
Subject: [PATCH v14 11/17] drm: bridge: analogix/dp: add some rk3288 special
 registers setting
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534654-1966-1-git-send-email-ykk@rock-chips.com>

RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Fix compile failed dut to phy_pd_addr variable misspell error

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 76 ++++++++++++++---------
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 12 ++++
 2 files changed, 60 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 3858df5..1e24b37 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -15,6 +15,8 @@
 #include <linux/delay.h>
 #include <linux/gpio.h>
 
+#include <drm/bridge/analogix_dp.h>
+
 #include "analogix_dp_core.h"
 #include "analogix_dp_reg.h"
 
@@ -72,6 +74,14 @@ void analogix_dp_init_analog_param(struct analogix_dp_device *dp)
 	reg = SEL_24M | TX_DVDD_BIT_1_0625V;
 	writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
 
+	if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP)) {
+		writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
+		writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
+		writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
+		writel(0x58, dp->reg_base + ANALOGIX_DP_PLL_REG_4);
+		writel(0x22, dp->reg_base + ANALOGIX_DP_PLL_REG_5);
+	}
+
 	reg = DRIVE_DVDD_BIT_1_0625V | VCO_BIT_600_MICRO;
 	writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_3);
 
@@ -206,81 +216,85 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
 				       bool enable)
 {
 	u32 reg;
+	u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+
+	if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+		phy_pd_addr = ANALOGIX_DP_PD;
 
 	switch (block) {
 	case AUX_BLOCK:
 		if (enable) {
-			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+			reg = readl(dp->reg_base + phy_pd_addr);
 			reg |= AUX_PD;
-			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+			writel(reg, dp->reg_base + phy_pd_addr);
 		} else {
-			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+			reg = readl(dp->reg_base + phy_pd_addr);
 			reg &= ~AUX_PD;
-			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+			writel(reg, dp->reg_base + phy_pd_addr);
 		}
 		break;
 	case CH0_BLOCK:
 		if (enable) {
-			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+			reg = readl(dp->reg_base + phy_pd_addr);
 			reg |= CH0_PD;
-			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+			writel(reg, dp->reg_base + phy_pd_addr);
 		} else {
-			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+			reg = readl(dp->reg_base + phy_pd_addr);
 			reg &= ~CH0_PD;
-			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+			writel(reg, dp->reg_base + phy_pd_addr);
 		}
 		break;
 	case CH1_BLOCK:
 		if (enable) {
-			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+			reg = readl(dp->reg_base + phy_pd_addr);
 			reg |= CH1_PD;
-			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+			writel(reg, dp->reg_base + phy_pd_addr);
 		} else {
-			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+			reg = readl(dp->reg_base + phy_pd_addr);
 			reg &= ~CH1_PD;
-			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+			writel(reg, dp->reg_base + phy_pd_addr);
 		}
 		break;
 	case CH2_BLOCK:
 		if (enable) {
-			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+			reg = readl(dp->reg_base + phy_pd_addr);
 			reg |= CH2_PD;
-			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+			writel(reg, dp->reg_base + phy_pd_addr);
 		} else {
-			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+			reg = readl(dp->reg_base + phy_pd_addr);
 			reg &= ~CH2_PD;
-			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+			writel(reg, dp->reg_base + phy_pd_addr);
 		}
 		break;
 	case CH3_BLOCK:
 		if (enable) {
-			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+			reg = readl(dp->reg_base + phy_pd_addr);
 			reg |= CH3_PD;
-			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+			writel(reg, dp->reg_base + phy_pd_addr);
 		} else {
-			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+			reg = readl(dp->reg_base + phy_pd_addr);
 			reg &= ~CH3_PD;
-			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+			writel(reg, dp->reg_base + phy_pd_addr);
 		}
 		break;
 	case ANALOG_TOTAL:
 		if (enable) {
-			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+			reg = readl(dp->reg_base + phy_pd_addr);
 			reg |= DP_PHY_PD;
-			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+			writel(reg, dp->reg_base + phy_pd_addr);
 		} else {
-			reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+			reg = readl(dp->reg_base + phy_pd_addr);
 			reg &= ~DP_PHY_PD;
-			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+			writel(reg, dp->reg_base + phy_pd_addr);
 		}
 		break;
 	case POWER_ALL:
 		if (enable) {
 			reg = DP_PHY_PD | AUX_PD | CH3_PD | CH2_PD |
 				CH1_PD | CH0_PD;
-			writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+			writel(reg, dp->reg_base + phy_pd_addr);
 		} else {
-			writel(0x00, dp->reg_base + ANALOGIX_DP_PHY_PD);
+			writel(0x00, dp->reg_base + phy_pd_addr);
 		}
 		break;
 	default:
@@ -399,8 +413,14 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
 	analogix_dp_reset_aux(dp);
 
 	/* Disable AUX transaction H/W retry */
-	reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3) | AUX_HW_RETRY_COUNT_SEL(0) |
-	      AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
+	if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+		reg = AUX_BIT_PERIOD_EXPECTED_DELAY(0) |
+		      AUX_HW_RETRY_COUNT_SEL(3) |
+		      AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
+	else
+		reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3) |
+		      AUX_HW_RETRY_COUNT_SEL(0) |
+		      AUX_HW_RETRY_INTERVAL_600_MICROSECONDS;
 	writel(reg, dp->reg_base + ANALOGIX_DP_AUX_HW_RETRY_CTL);
 
 	/* Receive AUX Channel DEFER commands equal to DEFFER_COUNT*64 */
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index 738db4c..337912b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -22,6 +22,14 @@
 #define ANALOGIX_DP_VIDEO_CTL_8			0x3C
 #define ANALOGIX_DP_VIDEO_CTL_10		0x44
 
+#define ANALOGIX_DP_PLL_REG_1			0xfc
+#define ANALOGIX_DP_PLL_REG_2			0x9e4
+#define ANALOGIX_DP_PLL_REG_3			0x9e8
+#define ANALOGIX_DP_PLL_REG_4			0x9ec
+#define ANALOGIX_DP_PLL_REG_5			0xa00
+
+#define ANALOGIX_DP_PD				0x12c
+
 #define ANALOGIX_DP_LANE_MAP			0x35C
 
 #define ANALOGIX_DP_ANALOG_CTL_1		0x370
@@ -154,6 +162,10 @@
 #define VSYNC_POLARITY_CFG			(0x1 << 1)
 #define HSYNC_POLARITY_CFG			(0x1 << 0)
 
+/* ANALOGIX_DP_PLL_REG_1 */
+#define REF_CLK_24M				(0x1 << 1)
+#define REF_CLK_27M				(0x0 << 1)
+
 /* ANALOGIX_DP_LANE_MAP */
 #define LANE3_MAP_LOGIC_LANE_0			(0x0 << 6)
 #define LANE3_MAP_LOGIC_LANE_1			(0x1 << 6)
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:11:05 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:11:05 +0800
Subject: [PATCH v14 12/17] drm: bridge: analogix/dp: add max link rate and
 lane count limit for RK3288
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534665-2012-1-git-send-email-ykk@rock-chips.com>

There are some IP limit on rk3288 that only support 4 physical lanes
of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
Tested-by: Javier Martinez Canillas <javier at osg.samsung.com>
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10:
- Remove the surplus "plat_data" check. (Heiko)
-       switch (dp->plat_data && dp->plat_data->dev_type) {
+       switch (dp->plat_data->dev_type) {

Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Seprate the link-rate and lane-count limit out with the device_type
  flag. (Thierry)

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 33 ++++++++++++++--------
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  4 +--
 2 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 26359f4..a62e8d0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -893,8 +893,8 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)
 		return;
 	}
 
-	ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
-					 dp->video_info.link_rate);
+	ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
+					 dp->video_info.max_link_rate);
 	if (ret) {
 		dev_err(dp->dev, "unable to do link train\n");
 		return;
@@ -1203,16 +1203,25 @@ static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
 	struct device_node *dp_node = dp->dev->of_node;
 	struct video_info *video_info = &dp->video_info;
 
-	if (of_property_read_u32(dp_node, "samsung,link-rate",
-				 &video_info->link_rate)) {
-		dev_err(dp->dev, "failed to get link-rate\n");
-		return -EINVAL;
-	}
-
-	if (of_property_read_u32(dp_node, "samsung,lane-count",
-				 &video_info->lane_count)) {
-		dev_err(dp->dev, "failed to get lane-count\n");
-		return -EINVAL;
+	switch (dp->plat_data->dev_type) {
+	case RK3288_DP:
+		/*
+		 * Like Rk3288 DisplayPort TRM indicate that "Main link
+		 * containing 4 physical lanes of 2.7/1.62 Gbps/lane".
+		 */
+		video_info->max_link_rate = 0x0A;
+		video_info->max_lane_count = 0x04;
+		break;
+	case EXYNOS_DP:
+		/*
+		 * NOTE: those property parseing code is used for
+		 * providing backward compatibility for samsung platform.
+		 */
+		of_property_read_u32(dp_node, "samsung,link-rate",
+				     &video_info->max_link_rate);
+		of_property_read_u32(dp_node, "samsung,lane-count",
+				     &video_info->max_lane_count);
+		break;
 	}
 
 	return 0;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 123030f..02c0ecf 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -123,8 +123,8 @@ struct video_info {
 	enum color_coefficient ycbcr_coeff;
 	enum color_depth color_depth;
 
-	int link_rate;
-	enum link_lane_count_type lane_count;
+	int max_link_rate;
+	enum link_lane_count_type max_lane_count;
 };
 
 struct link_train {
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:11:15 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:11:15 +0800
Subject: [PATCH v14 13/17] drm: bridge: analogix/dp: try force hpd after plug
 in lookup failed
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534675-2066-1-git-send-email-ykk@rock-chips.com>

Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.

This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
Acked-by: Rob Herring <robh at kernel.org>
Tested-by: Javier Martinez Canillas <javier at osg.samsung.com>
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11:
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
  hpd when hpd detect failed.

Changes in v2: None

 .../bindings/display/bridge/analogix_dp.txt        |  4 ++-
 .../bindings/display/exynos/exynos_dp.txt          |  1 +
 .../display/rockchip/analogix_dp-rockchip.txt      |  1 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 ++++++++++++++++++----
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  9 ++++++
 6 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 7659a7a..4f2ba8c 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
 		from general PHY binding: Should be "dp".
 
 Optional properties for dp-controller:
+	-force-hpd:
+		Indicate driver need force hpd when hpd detect failed, this
+		is used for some eDP screen which don't have hpd signal.
 	-hpd-gpios:
 		Hotplug detect GPIO.
 		Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
 		* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
 		* Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
 
-
 [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
 -------------------------------------------------------------------------------
 
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 4fa8aca..ade5d8e 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -56,6 +56,7 @@ For the below properties, please refer to Analogix DP binding document:
 	-phys (required)
 	-phy-names (required)
 	-hpd-gpios (optional)
+	 force-hpd (optional)
 
 Deprecated properties for DisplayPort:
 -interlaced:            deprecated prop that can parsed from drm_display_mode.
diff --git a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index 04d99e3..e832ff9 100644
--- a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP binding document:
 - phys (required)
 - phy-names (required)
 - hpd-gpios (optional)
+- force-hpd (optional)
 -------------------------------------------------------------------------------
 
 Example:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a62e8d0..13986b7 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -62,15 +62,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device *dp)
 {
 	int timeout_loop = 0;
 
-	while (analogix_dp_get_plug_in_status(dp) != 0) {
+	while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+		if (analogix_dp_get_plug_in_status(dp) == 0)
+			return 0;
+
 		timeout_loop++;
-		if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
-			dev_err(dp->dev, "failed to get hpd plug status\n");
-			return -ETIMEDOUT;
-		}
 		usleep_range(10, 11);
 	}
 
+	/*
+	 * Some edp screen do not have hpd signal, so we can't just
+	 * return failed when hpd plug in detect failed, DT property
+	 * "force-hpd" would indicate whether driver need this.
+	 */
+	if (!dp->force_hpd)
+		return -ETIMEDOUT;
+
+	/*
+	 * The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+	 * will not work, so we need to give a force hpd action to
+	 * set HPD_STATUS manually.
+	 */
+	dev_dbg(dp->dev, "failed to get hpd plug status, try to force hpd\n");
+
+	analogix_dp_force_hpd(dp);
+
+	if (analogix_dp_get_plug_in_status(dp) != 0) {
+		dev_err(dp->dev, "failed to get hpd plug in status\n");
+		return -EINVAL;
+	}
+
+	dev_dbg(dp->dev, "success to get plug in status after force hpd\n");
+
 	return 0;
 }
 
@@ -1291,6 +1314,8 @@ int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
 	if (IS_ERR(dp->reg_base))
 		return PTR_ERR(dp->reg_base);
 
+	dp->force_hpd = of_property_read_bool(dev->of_node, "force-hpd");
+
 	dp->hpd_gpio = of_get_named_gpio(dev->of_node, "hpd-gpios", 0);
 	if (!gpio_is_valid(dp->hpd_gpio))
 		dp->hpd_gpio = of_get_named_gpio(dev->of_node,
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 02c0ecf..22aff07 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -154,6 +154,7 @@ struct analogix_dp_device {
 	struct phy		*phy;
 	int			dpms_mode;
 	int			hpd_gpio;
+	bool                    force_hpd;
 
 	struct analogix_dp_plat_data *plat_data;
 };
@@ -174,6 +175,7 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
 				       bool enable);
 void analogix_dp_init_analog_func(struct analogix_dp_device *dp);
 void analogix_dp_init_hpd(struct analogix_dp_device *dp);
+void analogix_dp_force_hpd(struct analogix_dp_device *dp);
 enum dp_irq_type analogix_dp_get_irq_type(struct analogix_dp_device *dp);
 void analogix_dp_clear_hotplug_interrupts(struct analogix_dp_device *dp);
 void analogix_dp_reset_aux(struct analogix_dp_device *dp);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 1e24b37..cba3ffd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -365,6 +365,15 @@ void analogix_dp_init_hpd(struct analogix_dp_device *dp)
 	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
 }
 
+void analogix_dp_force_hpd(struct analogix_dp_device *dp)
+{
+	u32 reg;
+
+	reg = readl(dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
+	reg = (F_HPD | HPD_CTRL);
+	writel(reg, dp->reg_base + ANALOGIX_DP_SYS_CTL_3);
+}
+
 enum dp_irq_type analogix_dp_get_irq_type(struct analogix_dp_device *dp)
 {
 	u32 reg;
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:11:20 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:11:20 +0800
Subject: [PATCH v14 14/17] drm: bridge: analogix/dp: move hpd detect to
 connector detect function
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534680-2112-1-git-send-email-ykk@rock-chips.com>

This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().

Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
	drm/exynos: do not start enabling DP at bind() phase

But for now the connector status don't hardcode to connected,
need to operate dp phy in .detect function, so we need to revert
parts if Gustavo Padovan's changes, add phy poweron
function in bind time.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
Tested-by: Javier Martinez Canillas <javier at osg.samsung.com>
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11:
- Revert parts of Gustavo Padovan's changes in commit:
	drm/exynos: do not start enabling DP at bind() phase
  Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
  the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Take Jingoo suggest, add commit messages.

Changes in v3:
- move dp hpd detect to connector detect function.

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 38 ++++++++++++----------
 1 file changed, 20 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 13986b7..cfdf695 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -904,12 +904,6 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)
 			DRM_ERROR("failed to disable the panel\n");
 	}
 
-	ret = analogix_dp_detect_hpd(dp);
-	if (ret) {
-		/* Cable has been disconnected, we're done */
-		return;
-	}
-
 	ret = analogix_dp_handle_edid(dp);
 	if (ret) {
 		dev_err(dp->dev, "unable to handle edid\n");
@@ -972,6 +966,11 @@ static const struct drm_connector_helper_funcs analogix_dp_connector_helper_func
 enum drm_connector_status
 analogix_dp_detect(struct drm_connector *connector, bool force)
 {
+	struct analogix_dp_device *dp = to_dp(connector);
+
+	if (analogix_dp_detect_hpd(dp))
+		return connector_status_disconnected;
+
 	return connector_status_connected;
 }
 
@@ -1051,13 +1050,6 @@ static void analogix_dp_bridge_enable(struct drm_bridge *bridge)
 
 	pm_runtime_get_sync(dp->dev);
 
-	if (dp->plat_data->panel) {
-		if (drm_panel_prepare(dp->plat_data->panel)) {
-			DRM_ERROR("failed to setup the panel\n");
-			return;
-		}
-	}
-
 	if (dp->plat_data->power_on)
 		dp->plat_data->power_on(dp->plat_data);
 
@@ -1090,11 +1082,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge *bridge)
 	if (dp->plat_data->power_off)
 		dp->plat_data->power_off(dp->plat_data);
 
-	if (dp->plat_data->panel) {
-		if (drm_panel_unprepare(dp->plat_data->panel))
-			DRM_ERROR("failed to turnoff the panel\n");
-	}
-
 	pm_runtime_put_sync(dp->dev);
 
 	dp->dpms_mode = DRM_MODE_DPMS_OFF;
@@ -1352,6 +1339,15 @@ int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
 
 	pm_runtime_enable(dev);
 
+	phy_power_on(dp->phy);
+
+	if (dp->plat_data->panel) {
+		if (drm_panel_prepare(dp->plat_data->panel)) {
+			DRM_ERROR("failed to setup the panel\n");
+			return -EBUSY;
+		}
+	}
+
 	ret = devm_request_irq(&pdev->dev, dp->irq, analogix_dp_irq_handler,
 			       irq_flags, "analogix-dp", dp);
 	if (ret) {
@@ -1385,6 +1381,12 @@ void analogix_dp_unbind(struct device *dev, struct device *master,
 	struct analogix_dp_device *dp = dev_get_drvdata(dev);
 
 	analogix_dp_bridge_disable(dp->bridge);
+
+	if (dp->plat_data->panel) {
+		if (drm_panel_unprepare(dp->plat_data->panel))
+			DRM_ERROR("failed to turnoff the panel\n");
+	}
+
 	pm_runtime_disable(dev);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_unbind);
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:10:11 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:10:11 +0800
Subject: [PATCH v14 06/17] drm: bridge: analogix/dp: dynamic parse sync_pol &
 interlace & dynamic_range
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534611-1738-1-git-send-email-ykk@rock-chips.com>

Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.

But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
Tested-by: Javier Martinez Canillas <javier at osg.samsung.com>
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
  compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
  to avoid -EOVERFLOW error (Krzysztof)

Changes in v6: None
Changes in v5:
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
  to get the backword timing values. Krzysztof suggest me that driver could use
  the "of_property_read_bool" to get backword timing values, but that interfacs
  would modify the original drm_display_mode timing directly (whether those
  properties exists or not).

Changes in v4:
- Provide backword compatibility with samsung. (Krzysztof)

Changes in v3:
- Dynamic parse video timing info from struct drm_display_mode and
  struct drm_display_info. (Thierry)

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 +++++++++++++--------
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   2 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  14 +-
 3 files changed, 103 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index b948636..26359f4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -893,8 +893,8 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)
 		return;
 	}
 
-	ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
-					 dp->video_info->link_rate);
+	ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
+					 dp->video_info.link_rate);
 	if (ret) {
 		dev_err(dp->dev, "unable to do link train\n");
 		return;
@@ -1077,6 +1077,85 @@ static void analogix_dp_bridge_disable(struct drm_bridge *bridge)
 	dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }
 
+static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
+					struct drm_display_mode *orig_mode,
+					struct drm_display_mode *mode)
+{
+	struct analogix_dp_device *dp = bridge->driver_private;
+	struct drm_display_info *display_info = &dp->connector.display_info;
+	struct video_info *video = &dp->video_info;
+	struct device_node *dp_node = dp->dev->of_node;
+	int vic;
+
+	/* Input video interlaces & hsync pol & vsync pol */
+	video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
+	video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
+	video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
+
+	/* Input video dynamic_range & colorimetry */
+	vic = drm_match_cea_mode(mode);
+	if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
+	    (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
+		video->dynamic_range = CEA;
+		video->ycbcr_coeff = COLOR_YCBCR601;
+	} else if (vic) {
+		video->dynamic_range = CEA;
+		video->ycbcr_coeff = COLOR_YCBCR709;
+	} else {
+		video->dynamic_range = VESA;
+		video->ycbcr_coeff = COLOR_YCBCR709;
+	}
+
+	/* Input vide bpc and color_formats */
+	switch (display_info->bpc) {
+	case 12:
+		video->color_depth = COLOR_12;
+		break;
+	case 10:
+		video->color_depth = COLOR_10;
+		break;
+	case 8:
+		video->color_depth = COLOR_8;
+		break;
+	case 6:
+		video->color_depth = COLOR_6;
+		break;
+	default:
+		video->color_depth = COLOR_8;
+		break;
+	}
+	if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+		video->color_space = COLOR_YCBCR444;
+	else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+		video->color_space = COLOR_YCBCR422;
+	else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
+		video->color_space = COLOR_RGB;
+	else
+		video->color_space = COLOR_RGB;
+
+	/*
+	 * NOTE: those property parsing code is used for providing backward
+	 * compatibility for samsung platform.
+	 * Due to we used the "of_property_read_u32" interfaces, when this
+	 * property isn't present, the "video_info" can keep the original
+	 * values and wouldn't be modified.
+	 */
+	of_property_read_u32(dp_node, "samsung,color-space",
+			     &video->color_space);
+	of_property_read_u32(dp_node, "samsung,dynamic-range",
+			     &video->dynamic_range);
+	of_property_read_u32(dp_node, "samsung,ycbcr-coeff",
+			     &video->ycbcr_coeff);
+	of_property_read_u32(dp_node, "samsung,color-depth",
+			     &video->color_depth);
+	if (of_property_read_bool(dp_node, "hsync-active-high"))
+		video->h_sync_polarity = true;
+	if (of_property_read_bool(dp_node, "vsync-active-high"))
+		video->v_sync_polarity = true;
+	if (of_property_read_bool(dp_node, "interlaced"))
+		video->interlaced = true;
+}
+
 static void analogix_dp_bridge_nop(struct drm_bridge *bridge)
 {
 	/* do nothing */
@@ -1087,6 +1166,7 @@ static const struct drm_bridge_funcs analogix_dp_bridge_funcs = {
 	.disable = analogix_dp_bridge_disable,
 	.pre_enable = analogix_dp_bridge_nop,
 	.post_disable = analogix_dp_bridge_nop,
+	.mode_set = analogix_dp_bridge_mode_set,
 	.attach = analogix_dp_bridge_attach,
 };
 
@@ -1118,62 +1198,24 @@ static int analogix_dp_create_bridge(struct drm_device *drm_dev,
 	return 0;
 }
 
-static struct video_info *analogix_dp_dt_parse_pdata(struct device *dev)
+static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
 {
-	struct device_node *dp_node = dev->of_node;
-	struct video_info *dp_video_config;
-
-	dp_video_config = devm_kzalloc(dev, sizeof(*dp_video_config),
-				       GFP_KERNEL);
-	if (!dp_video_config)
-		return ERR_PTR(-ENOMEM);
-
-	dp_video_config->h_sync_polarity =
-		of_property_read_bool(dp_node, "hsync-active-high");
-
-	dp_video_config->v_sync_polarity =
-		of_property_read_bool(dp_node, "vsync-active-high");
-
-	dp_video_config->interlaced =
-		of_property_read_bool(dp_node, "interlaced");
-
-	if (of_property_read_u32(dp_node, "samsung,color-space",
-				 &dp_video_config->color_space)) {
-		dev_err(dev, "failed to get color-space\n");
-		return ERR_PTR(-EINVAL);
-	}
-
-	if (of_property_read_u32(dp_node, "samsung,dynamic-range",
-				 &dp_video_config->dynamic_range)) {
-		dev_err(dev, "failed to get dynamic-range\n");
-		return ERR_PTR(-EINVAL);
-	}
-
-	if (of_property_read_u32(dp_node, "samsung,ycbcr-coeff",
-				 &dp_video_config->ycbcr_coeff)) {
-		dev_err(dev, "failed to get ycbcr-coeff\n");
-		return ERR_PTR(-EINVAL);
-	}
-
-	if (of_property_read_u32(dp_node, "samsung,color-depth",
-				 &dp_video_config->color_depth)) {
-		dev_err(dev, "failed to get color-depth\n");
-		return ERR_PTR(-EINVAL);
-	}
+	struct device_node *dp_node = dp->dev->of_node;
+	struct video_info *video_info = &dp->video_info;
 
 	if (of_property_read_u32(dp_node, "samsung,link-rate",
-				 &dp_video_config->link_rate)) {
-		dev_err(dev, "failed to get link-rate\n");
-		return ERR_PTR(-EINVAL);
+				 &video_info->link_rate)) {
+		dev_err(dp->dev, "failed to get link-rate\n");
+		return -EINVAL;
 	}
 
 	if (of_property_read_u32(dp_node, "samsung,lane-count",
-				 &dp_video_config->lane_count)) {
-		dev_err(dev, "failed to get lane-count\n");
-		return ERR_PTR(-EINVAL);
+				 &video_info->lane_count)) {
+		dev_err(dp->dev, "failed to get lane-count\n");
+		return -EINVAL;
 	}
 
-	return dp_video_config;
+	return 0;
 }
 
 int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
@@ -1206,9 +1248,9 @@ int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
 	 */
 	dp->plat_data = plat_data;
 
-	dp->video_info = analogix_dp_dt_parse_pdata(&pdev->dev);
-	if (IS_ERR(dp->video_info))
-		return PTR_ERR(dp->video_info);
+	ret = analogix_dp_dt_parse_pdata(dp);
+	if (ret)
+		return ret;
 
 	dp->phy = devm_phy_get(dp->dev, "dp");
 	if (IS_ERR(dp->phy)) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index afb0a53..123030f 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -148,7 +148,7 @@ struct analogix_dp_device {
 	unsigned int		irq;
 	void __iomem		*reg_base;
 
-	struct video_info	*video_info;
+	struct video_info	video_info;
 	struct link_train	link_train;
 	struct work_struct	hotplug_work;
 	struct phy		*phy;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index eb0b63c..3858df5 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1084,15 +1084,15 @@ void analogix_dp_set_video_color_format(struct analogix_dp_device *dp)
 	u32 reg;
 
 	/* Configure the input color depth, color space, dynamic range */
-	reg = (dp->video_info->dynamic_range << IN_D_RANGE_SHIFT) |
-		(dp->video_info->color_depth << IN_BPC_SHIFT) |
-		(dp->video_info->color_space << IN_COLOR_F_SHIFT);
+	reg = (dp->video_info.dynamic_range << IN_D_RANGE_SHIFT) |
+		(dp->video_info.color_depth << IN_BPC_SHIFT) |
+		(dp->video_info.color_space << IN_COLOR_F_SHIFT);
 	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_2);
 
 	/* Set Input Color YCbCr Coefficients to ITU601 or ITU709 */
 	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_3);
 	reg &= ~IN_YC_COEFFI_MASK;
-	if (dp->video_info->ycbcr_coeff)
+	if (dp->video_info.ycbcr_coeff)
 		reg |= IN_YC_COEFFI_ITU709;
 	else
 		reg |= IN_YC_COEFFI_ITU601;
@@ -1229,17 +1229,17 @@ void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp)
 
 	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 	reg &= ~INTERACE_SCAN_CFG;
-	reg |= (dp->video_info->interlaced << 2);
+	reg |= (dp->video_info.interlaced << 2);
 	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 
 	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 	reg &= ~VSYNC_POLARITY_CFG;
-	reg |= (dp->video_info->v_sync_polarity << 1);
+	reg |= (dp->video_info.v_sync_polarity << 1);
 	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 
 	reg = readl(dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 	reg &= ~HSYNC_POLARITY_CFG;
-	reg |= (dp->video_info->h_sync_polarity << 0);
+	reg |= (dp->video_info.h_sync_polarity << 0);
 	writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_10);
 
 	reg = AUDIO_MODE_SPDIF_MODE | VIDEO_MODE_SLAVE_MODE;
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:10:48 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:10:48 +0800
Subject: [PATCH v14 10/17] dt-bindings: add document for rockchip variant of
 analogix_dp
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534648-1921-1-git-send-email-ykk@rock-chips.com>

Rockchip DP driver is a helper driver of analogix_dp coder driver,
so most of the DT property should be descriped in analogix_dp document.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
Acked-by: Rob Herring <robh at kernel.org>
Reviewed-by: Heiko Stuebner <heiko at sntech.de>
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10:
- Add the ack from Rob Herring

Changes in v9:
- Document more details for 'ports' property.

Changes in v8:
- Modify the commit subject name. (Heiko)

Changes in v7: None
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)

Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../display/rockchip/analogix_dp-rockchip.txt      | 91 ++++++++++++++++++++++
 1 file changed, 91 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt

diff --git a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
new file mode 100644
index 0000000..04d99e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -0,0 +1,91 @@
+Rockchip RK3288 specific extensions to the Analogix Display Port
+================================
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+	  of memory mapped region.
+
+- clock-names: from common clock binding:
+	       Required elements: "dp" "pclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+	  See ../reset/reset.txt for details.
+
+- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
+- pinctrl-0: pin-control mode. should be <&edp_hpd>
+
+- reset-names: Must include the name "dp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: there are 2 port nodes with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+    Port 0: contained 2 endpoints, connecting to the output of vop.
+    Port 1: contained 1 endpoint, connecting to the input of panel.
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+- phys (required)
+- phy-names (required)
+- hpd-gpios (optional)
+-------------------------------------------------------------------------------
+
+Example:
+	dp-controller: dp at ff970000 {
+		compatible = "rockchip,rk3288-dp";
+		reg = <0xff970000 0x4000>;
+		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
+		clock-names = "dp", "pclk";
+		phys = <&dp_phy>;
+		phy-names = "dp";
+
+		rockchip,grf = <&grf>;
+		resets = <&cru 111>;
+		reset-names = "dp";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&edp_hpd>;
+
+		status = "disabled";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			edp_in: port at 0 {
+				reg = <0>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				edp_in_vopb: endpoint at 0 {
+					reg = <0>;
+					remote-endpoint = <&vopb_out_edp>;
+				};
+				edp_in_vopl: endpoint at 1 {
+					reg = <1>;
+					remote-endpoint = <&vopl_out_edp>;
+				};
+			};
+
+			edp_out: port at 1 {
+				reg = <1>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				edp_out_panel: endpoint {
+					reg = <0>;
+					remote-endpoint = <&panel_in_edp>
+				};
+			};
+		};
+	};
+
+	pinctrl {
+		edp {
+			edp_hpd: edp-hpd {
+				rockchip,pins = <7 11 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+	};
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:11:29 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:11:29 +0800
Subject: [PATCH v14 15/17] drm: bridge: analogix/dp: add edid modes parse in
 get_modes method
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534689-2165-1-git-send-email-ykk@rock-chips.com>

Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.

Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
	drm/exynos: do not start enabling DP at bind() phase

But for now driver need to read edid message in .get_modes()
function, so controller must be inited in bind time, so we
need to add controller init back.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
Tested-by: Javier Martinez Canillas <javier at osg.samsung.com>
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Call drm_panel_prepare() in .get_modes function, ensure panel should
  power on before driver try to read edid message.

Changes in v3:
- Add edid modes parse support

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 17 ++++----
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 46 +++++++++++-----------
 2 files changed, 33 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index cfdf695..bc59e8d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -110,7 +110,7 @@ static unsigned char analogix_dp_calc_edid_check_sum(unsigned char *edid_data)
 
 static int analogix_dp_read_edid(struct analogix_dp_device *dp)
 {
-	unsigned char edid[EDID_BLOCK_LENGTH * 2];
+	unsigned char *edid = dp->edid;
 	unsigned int extend_block = 0;
 	unsigned char sum;
 	unsigned char test_vector;
@@ -904,12 +904,6 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)
 			DRM_ERROR("failed to disable the panel\n");
 	}
 
-	ret = analogix_dp_handle_edid(dp);
-	if (ret) {
-		dev_err(dp->dev, "unable to handle edid\n");
-		return;
-	}
-
 	ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
 					 dp->video_info.max_link_rate);
 	if (ret) {
@@ -939,8 +933,14 @@ static void analogix_dp_commit(struct analogix_dp_device *dp)
 int analogix_dp_get_modes(struct drm_connector *connector)
 {
 	struct analogix_dp_device *dp = to_dp(connector);
+	struct edid *edid = (struct edid *)dp->edid;
 	int num_modes = 0;
 
+	if (analogix_dp_handle_edid(dp) == 0) {
+		drm_mode_connector_update_edid_property(&dp->connector, edid);
+		num_modes += drm_add_edid_modes(&dp->connector, edid);
+	}
+
 	if (dp->plat_data->panel)
 		num_modes += drm_panel_get_modes(dp->plat_data->panel);
 
@@ -978,6 +978,7 @@ static void analogix_dp_connector_destroy(struct drm_connector *connector)
 {
 	drm_connector_unregister(connector);
 	drm_connector_cleanup(connector);
+
 }
 
 static const struct drm_connector_funcs analogix_dp_connector_funcs = {
@@ -1348,6 +1349,8 @@ int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
 		}
 	}
 
+	analogix_dp_init_dp(dp);
+
 	ret = devm_request_irq(&pdev->dev, dp->irq, analogix_dp_irq_handler,
 			       irq_flags, "analogix-dp", dp);
 	if (ret) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 22aff07..48b4a87 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,28 @@
 #define MAX_CR_LOOP 5
 #define MAX_EQ_LOOP 5
 
+/* I2C EDID Chip ID, Slave Address */
+#define I2C_EDID_DEVICE_ADDR			0x50
+#define I2C_E_EDID_DEVICE_ADDR			0x30
+
+#define EDID_BLOCK_LENGTH			0x80
+#define EDID_HEADER_PATTERN			0x00
+#define EDID_EXTENSION_FLAG			0x7e
+#define EDID_CHECKSUM				0x7f
+
+/* DP_MAX_LANE_COUNT */
+#define DPCD_ENHANCED_FRAME_CAP(x)		(((x) >> 7) & 0x1)
+#define DPCD_MAX_LANE_COUNT(x)			((x) & 0x1f)
+
+/* DP_LANE_COUNT_SET */
+#define DPCD_LANE_COUNT_SET(x)			((x) & 0x1f)
+
+/* DP_TRAINING_LANE0_SET */
+#define DPCD_PRE_EMPHASIS_SET(x)		(((x) & 0x3) << 3)
+#define DPCD_PRE_EMPHASIS_GET(x)		(((x) >> 3) & 0x3)
+#define DPCD_VOLTAGE_SWING_SET(x)		(((x) & 0x3) << 0)
+#define DPCD_VOLTAGE_SWING_GET(x)		(((x) >> 0) & 0x3)
+
 enum link_lane_count_type {
 	LANE_COUNT1 = 1,
 	LANE_COUNT2 = 2,
@@ -155,6 +177,7 @@ struct analogix_dp_device {
 	int			dpms_mode;
 	int			hpd_gpio;
 	bool                    force_hpd;
+	unsigned char           edid[EDID_BLOCK_LENGTH * 2];
 
 	struct analogix_dp_plat_data *plat_data;
 };
@@ -254,27 +277,4 @@ int analogix_dp_is_video_stream_on(struct analogix_dp_device *dp);
 void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp);
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
-
-/* I2C EDID Chip ID, Slave Address */
-#define I2C_EDID_DEVICE_ADDR			0x50
-#define I2C_E_EDID_DEVICE_ADDR			0x30
-
-#define EDID_BLOCK_LENGTH			0x80
-#define EDID_HEADER_PATTERN			0x00
-#define EDID_EXTENSION_FLAG			0x7e
-#define EDID_CHECKSUM				0x7f
-
-/* DP_MAX_LANE_COUNT */
-#define DPCD_ENHANCED_FRAME_CAP(x)		(((x) >> 7) & 0x1)
-#define DPCD_MAX_LANE_COUNT(x)			((x) & 0x1f)
-
-/* DP_LANE_COUNT_SET */
-#define DPCD_LANE_COUNT_SET(x)			((x) & 0x1f)
-
-/* DP_TRAINING_LANE0_SET */
-#define DPCD_PRE_EMPHASIS_SET(x)		(((x) & 0x3) << 3)
-#define DPCD_PRE_EMPHASIS_GET(x)		(((x) >> 3) & 0x3)
-#define DPCD_VOLTAGE_SWING_SET(x)		(((x) & 0x3) << 0)
-#define DPCD_VOLTAGE_SWING_GET(x)		(((x) >> 0) & 0x3)
-
 #endif /* _ANALOGIX_DP_CORE_H */
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:11:37 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:11:37 +0800
Subject: [PATCH v14 16/17] drm: bridge: analogix/dp: add panel
 prepare/unprepare in suspend/resume time
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534697-2209-1-git-send-email-ykk@rock-chips.com>

Turn off the panel power in suspend time would help to reduce
power waste.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index bc59e8d..5292b28 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1400,6 +1400,12 @@ int analogix_dp_suspend(struct device *dev)
 	struct analogix_dp_device *dp = dev_get_drvdata(dev);
 
 	clk_disable_unprepare(dp->clock);
+
+	if (dp->plat_data->panel) {
+		if (drm_panel_unprepare(dp->plat_data->panel))
+			DRM_ERROR("failed to turnoff the panel\n");
+	}
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(analogix_dp_suspend);
@@ -1415,6 +1421,13 @@ int analogix_dp_resume(struct device *dev)
 		return ret;
 	}
 
+	if (dp->plat_data->panel) {
+		if (drm_panel_prepare(dp->plat_data->panel)) {
+			DRM_ERROR("failed to setup the panel\n");
+			return -EBUSY;
+		}
+	}
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(analogix_dp_resume);
-- 
1.9.1




From ykk at rock-chips.com  Mon Feb 15 03:11:50 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Mon, 15 Feb 2016 19:11:50 +0800
Subject: [PATCH v14 17/17] drm: bridge: analogix/dp: Fix the possible dead
 lock in bridge disable time
In-Reply-To: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
References: <1455534485-1154-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1455534710-2262-1-git-send-email-ykk@rock-chips.com>

It may caused a dead lock if we flush the hpd work in bridge disable time.

The normal flow would like:
  IN --> DRM IOCTL
        1. Acquire crtc_ww_class_mutex (DRM IOCTL)
  IN --> analogix_dp_bridge
        2. Acquire hpd work lock (Flush hpd work)
        3. HPD work already in idle, no need to run the work function.
  OUT <-- analogix_dp_bridge
  OUT <-- DRM IOCTL

The dead lock flow would like:
  IN --> DRM IOCTL
        1. Acquire crtc_ww_class_mutex (DRM IOCTL)
  IN --> analogix_dp_bridge
        2. Acquire hpd work lock (Flush hpd work)
  IN --> analogix_dp_hotplug
  IN --> drm_helper_hpd_irq_event
        3. Acquire mode_config lock (This lock already have been acquired in previous step 1)
** Dead Lock Now **

It's wrong to flush the hpd work in bridge->disable time, I guess the
original code just want to ensure the delay work must be finish before
encoder disabled.

The flush work in bridge disable time is try to ensure the HPD event
won't be missed before display card disabled, actually we can take a
fast respond way(interrupt thread) to update DRM HPD event to fix the
delay update and possible dead lock.

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
---
Changes in v14: None
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 62 ++++++++++------------
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  3 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 26 +++++++++
 3 files changed, 55 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5292b28..7699597 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -851,47 +851,40 @@ static void analogix_dp_enable_scramble(struct analogix_dp_device *dp,
 	}
 }
 
-static irqreturn_t analogix_dp_irq_handler(int irq, void *arg)
+static irqreturn_t analogix_dp_hardirq(int irq, void *arg)
 {
 	struct analogix_dp_device *dp = arg;
-
+	irqreturn_t ret = IRQ_NONE;
 	enum dp_irq_type irq_type;
 
 	irq_type = analogix_dp_get_irq_type(dp);
-	switch (irq_type) {
-	case DP_IRQ_TYPE_HP_CABLE_IN:
-		dev_dbg(dp->dev, "Received irq - cable in\n");
-		schedule_work(&dp->hotplug_work);
-		analogix_dp_clear_hotplug_interrupts(dp);
-		break;
-	case DP_IRQ_TYPE_HP_CABLE_OUT:
-		dev_dbg(dp->dev, "Received irq - cable out\n");
-		analogix_dp_clear_hotplug_interrupts(dp);
-		break;
-	case DP_IRQ_TYPE_HP_CHANGE:
-		/*
-		 * We get these change notifications once in a while, but there
-		 * is nothing we can do with them. Just ignore it for now and
-		 * only handle cable changes.
-		 */
-		dev_dbg(dp->dev, "Received irq - hotplug change; ignoring.\n");
-		analogix_dp_clear_hotplug_interrupts(dp);
-		break;
-	default:
-		dev_err(dp->dev, "Received irq - unknown type!\n");
-		break;
+	if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+		analogix_dp_mute_hpd_interrupt(dp);
+		ret = IRQ_WAKE_THREAD;
 	}
-	return IRQ_HANDLED;
+
+	return ret;
 }
 
-static void analogix_dp_hotplug(struct work_struct *work)
+static irqreturn_t analogix_dp_irq_thread(int irq, void *arg)
 {
-	struct analogix_dp_device *dp;
+	struct analogix_dp_device *dp = arg;
+	enum dp_irq_type irq_type;
+
+	irq_type = analogix_dp_get_irq_type(dp);
+	if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN ||
+	    irq_type & DP_IRQ_TYPE_HP_CABLE_OUT) {
+		dev_dbg(dp->dev, "Detected cable status changed!\n");
+		if (dp->drm_dev)
+			drm_helper_hpd_irq_event(dp->drm_dev);
+	}
 
-	dp = container_of(work, struct analogix_dp_device, hotplug_work);
+	if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+		analogix_dp_clear_hotplug_interrupts(dp);
+		analogix_dp_unmute_hpd_interrupt(dp);
+	}
 
-	if (dp->drm_dev)
-		drm_helper_hpd_irq_event(dp->drm_dev);
+	return IRQ_HANDLED;
 }
 
 static void analogix_dp_commit(struct analogix_dp_device *dp)
@@ -1077,7 +1070,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge *bridge)
 	}
 
 	disable_irq(dp->irq);
-	flush_work(&dp->hotplug_work);
 	phy_power_off(dp->phy);
 
 	if (dp->plat_data->power_off)
@@ -1336,8 +1328,6 @@ int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
 		return -ENODEV;
 	}
 
-	INIT_WORK(&dp->hotplug_work, analogix_dp_hotplug);
-
 	pm_runtime_enable(dev);
 
 	phy_power_on(dp->phy);
@@ -1351,8 +1341,10 @@ int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
 
 	analogix_dp_init_dp(dp);
 
-	ret = devm_request_irq(&pdev->dev, dp->irq, analogix_dp_irq_handler,
-			       irq_flags, "analogix-dp", dp);
+	ret = devm_request_threaded_irq(&pdev->dev, dp->irq,
+					analogix_dp_hardirq,
+					analogix_dp_irq_thread,
+					irq_flags, "analogix-dp", dp);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to request irq\n");
 		goto err_disable_pm_runtime;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 48b4a87..f09275d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -172,7 +172,6 @@ struct analogix_dp_device {
 
 	struct video_info	video_info;
 	struct link_train	link_train;
-	struct work_struct	hotplug_work;
 	struct phy		*phy;
 	int			dpms_mode;
 	int			hpd_gpio;
@@ -191,6 +190,8 @@ void analogix_dp_init_interrupt(struct analogix_dp_device *dp);
 void analogix_dp_reset(struct analogix_dp_device *dp);
 void analogix_dp_swreset(struct analogix_dp_device *dp);
 void analogix_dp_config_interrupt(struct analogix_dp_device *dp);
+void analogix_dp_mute_hpd_interrupt(struct analogix_dp_device *dp);
+void analogix_dp_unmute_hpd_interrupt(struct analogix_dp_device *dp);
 enum pll_status analogix_dp_get_pll_lock_status(struct analogix_dp_device *dp);
 void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool enable);
 void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index cba3ffd..49205ef 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -185,6 +185,32 @@ void analogix_dp_config_interrupt(struct analogix_dp_device *dp)
 	writel(reg, dp->reg_base + ANALOGIX_DP_INT_STA_MASK);
 }
 
+void analogix_dp_mute_hpd_interrupt(struct analogix_dp_device *dp)
+{
+	u32 reg;
+
+	/* 0: mask, 1: unmask */
+	reg = readl(dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_4);
+	reg &= ~COMMON_INT_MASK_4;
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_4);
+
+	reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA_MASK);
+	reg &= ~INT_STA_MASK;
+	writel(reg, dp->reg_base + ANALOGIX_DP_INT_STA_MASK);
+}
+
+void analogix_dp_unmute_hpd_interrupt(struct analogix_dp_device *dp)
+{
+	u32 reg;
+
+	/* 0: mask, 1: unmask */
+	reg = COMMON_INT_MASK_4;
+	writel(reg, dp->reg_base + ANALOGIX_DP_COMMON_INT_MASK_4);
+
+	reg = INT_STA_MASK;
+	writel(reg, dp->reg_base + ANALOGIX_DP_INT_STA_MASK);
+}
+
 enum pll_status analogix_dp_get_pll_lock_status(struct analogix_dp_device *dp)
 {
 	u32 reg;
-- 
1.9.1




From tiffany.lin at mediatek.com  Mon Feb 15 03:20:14 2016
From: tiffany.lin at mediatek.com (tiffany lin)
Date: Mon, 15 Feb 2016 19:20:14 +0800
Subject: [PATCH v4 2/8] [media] VPU: mediatek: support Mediatek VPU
In-Reply-To: <56C1A36D.6010908@xs4all.nl>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <56C1A36D.6010908@xs4all.nl>
Message-ID: <1455535214.27088.2.camel@mtksdaap41>

Hi Hans,

On Mon, 2016-02-15 at 11:07 +0100, Hans Verkuil wrote:
> Hi Tiffany,
> 
> A small review comment below:
> 
> On 02/04/2016 12:34 PM, Tiffany Lin wrote:
> > The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
> > It is able to handle video decoding/encoding of in a range of formats.
> > The driver provides with VPU firmware download, memory management and
> > the communication interface between CPU and VPU.
> > For VPU initialization, it will create virtual memory for CPU access and
> > IOMMU address for vcodec hw device access. When a decode/encode instance
> > opens a device node, vpu driver will download vpu firmware to the device.
> > A decode/encode instant will decode/encode a frame using VPU
> > interface to interrupt vpu to handle decoding/encoding jobs.
> > 
> > Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
> > Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
> > ---
> >  drivers/media/platform/Kconfig           |    9 +
> >  drivers/media/platform/Makefile          |    2 +
> >  drivers/media/platform/mtk-vpu/Makefile  |    1 +
> >  drivers/media/platform/mtk-vpu/mtk_vpu.c |  994 ++++++++++++++++++++++++++++++
> >  drivers/media/platform/mtk-vpu/mtk_vpu.h |  167 +++++
> >  5 files changed, 1173 insertions(+)
> >  create mode 100644 drivers/media/platform/mtk-vpu/Makefile
> >  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c
> >  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h
> > 
> 
> <snip>
> 
> > diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> > new file mode 100644
> > index 0000000..f54fd89
> > --- /dev/null
> > +++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> > @@ -0,0 +1,994 @@
> 
> <snip>
> 
> > +static ssize_t vpu_debug_read(struct file *file, char __user *user_buf,
> > +			      size_t count, loff_t *ppos)
> > +{
> > +	char buf[256];
> > +	unsigned int len;
> > +	unsigned int running, pc, vpu_to_host, host_to_vpu, wdt;
> > +	int ret;
> > +	struct device *dev = file->private_data;
> > +	struct mtk_vpu *vpu = dev_get_drvdata(dev);
> > +
> > +	ret = vpu_clock_enable(vpu);
> > +	if (ret) {
> > +		dev_err(vpu->dev, "[VPU] enable clock failed %d\n", ret);
> > +		return 0;
> > +	}
> > +
> > +	/* vpu register status */
> > +	running = vpu_running(vpu);
> > +	pc = vpu_cfg_readl(vpu, VPU_PC_REG);
> > +	wdt = vpu_cfg_readl(vpu, VPU_WDT_REG);
> > +	host_to_vpu = vpu_cfg_readl(vpu, HOST_TO_VPU);
> > +	vpu_to_host = vpu_cfg_readl(vpu, VPU_TO_HOST);
> > +	vpu_clock_disable(vpu);
> > +
> > +	if (running) {
> > +		len = sprintf(buf, "VPU is running\n\n"
> 
> Please use snprintf.
> 
Got it, we will fix this in next version.

> > +		"FW Version: %s\n"
> > +		"PC: 0x%x\n"
> > +		"WDT: 0x%x\n"
> > +		"Host to VPU: 0x%x\n"
> > +		"VPU to Host: 0x%x\n",
> > +		vpu->run.fw_ver, pc, wdt,
> > +		host_to_vpu, vpu_to_host);
> > +	} else {
> > +		len = sprintf(buf, "VPU not running\n");
> 
> Ditto.
> 
> sprintf always makes me feel uncomfortable :-)
> 
Sorry about that, we will check patch series and remove all sprintf in
next version.

> > +	}
> > +
> > +	return simple_read_from_buffer(user_buf, count, ppos, buf, len);
> > +}
> 
> Regards,
> 
> 	Hans
> 




From yamada.masahiro at socionext.com  Mon Feb 15 03:25:34 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon, 15 Feb 2016 20:25:34 +0900
Subject: [PATCH] ARM: drop redundant "PHONY += FORCE"
In-Reply-To: <1454839174-5464-1-git-send-email-yamada.masahiro@socionext.com>
References: <1454839174-5464-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <CAK7LNASARrPWgsvBjMjEyGAC-CzOAMkL8=GSsuj_i3Eq+xCyEQ@mail.gmail.com>

2016-02-07 18:59 GMT+09:00 Masahiro Yamada <yamada.masahiro at socionext.com>:
> "PHONY += FORCE" is already cared by scripts/Makefile.build,
> which this file is included from.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
> ---
>
>  arch/arm/boot/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
> index 9eca7ae..ba73a20 100644
> --- a/arch/arm/boot/Makefile
> +++ b/arch/arm/boot/Makefile
> @@ -88,7 +88,7 @@ $(obj)/bootpImage: $(obj)/bootp/bootp FORCE
>         $(call if_changed,objcopy)
>         @$(kecho) '  Kernel: $@ is ready'
>
> -PHONY += initrd FORCE
> +PHONY += initrd
>  initrd:
>         @test "$(INITRD_PHYS)" != "" || \
>         (echo This machine does not support INITRD; exit -1)
> --

If there is no objection to this patch,
I will put it into Russell's patch tracker.



-- 
Best Regards
Masahiro Yamada


From yamada.masahiro at socionext.com  Mon Feb 15 03:26:02 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon, 15 Feb 2016 20:26:02 +0900
Subject: [PATCH] ARM: remove 'i' and 'zi' targets
In-Reply-To: <1454839003-4342-1-git-send-email-yamada.masahiro@socionext.com>
References: <1454839003-4342-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <CAK7LNASDxBT8J3A70STLCedQTXiwfK+vxo7OVJAgUUORT=pqJQ@mail.gmail.com>

2016-02-07 18:56 GMT+09:00 Masahiro Yamada <yamada.masahiro at socionext.com>:
> These two were introduced by commit 13d5fadf45d1 ("[ARM] Make 'i' and
> 'zi' targets work") to short-circuit the dependencies for 'install'
> and 'zinstall'.
>
> After that, commit 19514fc665ff ('arm, kbuild: make "make install"
> not depend on vmlinux') eventually made "make (z)install" equivalent
> to "make (z)i".
>
> It is true that 'i' and 'zi' might be still useful as shorthands
> but the original intention had been already lost.
>
> They do not even show up in "make ARCH=arm help", so I hope this
> deletion does not have much impact.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
> ---
>
>  arch/arm/Makefile      | 1 -
>  arch/arm/boot/Makefile | 8 --------
>  2 files changed, 9 deletions(-)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index cd21135..1e83a45 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -353,7 +353,6 @@ archclean:
>
>  # My testing targets (bypasses dependencies)
>  bp:;   $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/bootpImage
> -i zi:; $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@
>
>
>  define archhelp
> diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
> index ba73a20..48fab15 100644
> --- a/arch/arm/boot/Makefile
> +++ b/arch/arm/boot/Makefile
> @@ -107,12 +107,4 @@ uinstall:
>         $(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
>         $(obj)/uImage System.map "$(INSTALL_PATH)"
>
> -zi:
> -       $(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
> -       $(obj)/zImage System.map "$(INSTALL_PATH)"
> -
> -i:
> -       $(CONFIG_SHELL) $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" \
> -       $(obj)/Image System.map "$(INSTALL_PATH)"
> -
>  subdir-            := bootp compressed dts
> --


If there is no objection to this patch,
I will put it into Russell's patch tracker.





-- 
Best Regards
Masahiro Yamada


From tiffany.lin at mediatek.com  Mon Feb 15 03:27:36 2016
From: tiffany.lin at mediatek.com (tiffany lin)
Date: Mon, 15 Feb 2016 19:27:36 +0800
Subject: [PATCH v4 2/8] [media] VPU: mediatek: support Mediatek VPU
In-Reply-To: <56C1A4C6.7040601@xs4all.nl>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <56C1A4C6.7040601@xs4all.nl>
Message-ID: <1455535656.27088.6.camel@mtksdaap41>

On Mon, 2016-02-15 at 11:13 +0100, Hans Verkuil wrote:
> On 02/04/2016 12:34 PM, Tiffany Lin wrote:
> > The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
> > It is able to handle video decoding/encoding of in a range of formats.
> > The driver provides with VPU firmware download, memory management and
> > the communication interface between CPU and VPU.
> > For VPU initialization, it will create virtual memory for CPU access and
> > IOMMU address for vcodec hw device access. When a decode/encode instance
> > opens a device node, vpu driver will download vpu firmware to the device.
> > A decode/encode instant will decode/encode a frame using VPU
> > interface to interrupt vpu to handle decoding/encoding jobs.
> > 
> > Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
> > Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
> > ---
> >  drivers/media/platform/Kconfig           |    9 +
> >  drivers/media/platform/Makefile          |    2 +
> >  drivers/media/platform/mtk-vpu/Makefile  |    1 +
> >  drivers/media/platform/mtk-vpu/mtk_vpu.c |  994 ++++++++++++++++++++++++++++++
> >  drivers/media/platform/mtk-vpu/mtk_vpu.h |  167 +++++
> >  5 files changed, 1173 insertions(+)
> >  create mode 100644 drivers/media/platform/mtk-vpu/Makefile
> >  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c
> >  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h
> > 
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index ccbc974..ba812d6 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -148,6 +148,15 @@ config VIDEO_CODA
> >  	   Coda is a range of video codec IPs that supports
> >  	   H.264, MPEG-4, and other video formats.
> >  
> > +config VIDEO_MEDIATEK_VPU
> > +	tristate "Mediatek Video Processor Unit"
> > +	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MEDIATEK
> > +	---help---
> > +	    This driver provides downloading VPU firmware and
> > +	    communicating with VPU. This driver for hw video
> > +	    codec embedded in new Mediatek's SOCs. It is able
> > +	    to handle video decoding/encoding in a range of formats.
> 
> Can you be more specific in this text and mention for which Mediatek SoCs
> this driver is for? Just like you did in the commit log.
> 
Got it. We will add more specific description in Kconfig in next
version.

> Also add something like this:
> 
>           To compile this driver as a module, choose M here: the module
>           will be called mtk-vpu.
> 
> I always find it useful if the Kconfig text mentions the module name.
> 
Got it. We will fix this. Thanks for sharing experience.


best regards,
Tiffany

> Regards,
> 
> 	Hans
> 
> > +
> >  config VIDEO_MEM2MEM_DEINTERLACE
> >  	tristate "Deinterlace support"
> >  	depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
> 




From jonathanh at nvidia.com  Mon Feb 15 03:27:39 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Mon, 15 Feb 2016 11:27:39 +0000
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <7hh9hdzflv.fsf@baylibre.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
 <7hh9hdzflv.fsf@baylibre.com>
Message-ID: <56C1B62B.5060708@nvidia.com>


On 12/02/16 23:14, Kevin Hilman wrote:
> Ulf Hansson <ulf.hansson at linaro.org> writes:
> 
>> On 28 January 2016 at 17:33, Jon Hunter <jonathanh at nvidia.com> wrote:
>>> Adds generic PM support to the PMC driver where the PM domains are
>>> populated from device-tree and the PM domain consumer devices are
>>> bound to their relevant PM domains via device-tree as well.
>>>
>>> Update the tegra_powergate_sequence_power_up() API so that internally
>>> it calls the same tegra_powergate_xxx functions that are used by the
>>> tegra generic power domain code for consistency.
>>>
>>> This is based upon work by Thierry Reding <treding at nvidia.com>
>>> and Vince Hsu <vinceh at nvidia.com>.
>>>
>>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
> 
> [...]
> 
>>> +static void tegra_powergate_disable_clocks(struct tegra_powergate *pg)
>>> +{
>>> +       unsigned int i;
>>> +
>>> +       for (i = 0; i < pg->num_clks; i++)
>>> +               clk_disable_unprepare(pg->clks[i]);
>>> +}
>>> +
>>> +static int tegra_powergate_enable_clocks(struct tegra_powergate *pg)
>>> +{
>>> +       unsigned int i;
>>> +       int err;
>>> +
>>> +       for (i = 0; i < pg->num_clks; i++) {
>>> +               err = clk_prepare_enable(pg->clks[i]);
>>> +               if (err)
>>> +                       goto out;
>>> +       }
>>> +
>>> +       return 0;
>>> +
>>> +out:
>>> +       while (i--)
>>> +               clk_disable_unprepare(pg->clks[i]);
>>> +
>>> +       return err;
>>> +}
>>
>> I have seen similar code around in other PM domains, dealing with
>> enabling/disabling a *list* of clocks.
>> Perhaps we should invent a new clock API that helps with this to
>> prevents code duplication!?
> 
> What about the pm_clk_* API which was built for tracking clocks
> associated with devices for runtime PM.
> 
> IOW, you could pm_clk_add(pg->pmc->dev, pg->clks[i]) and then your
> _enable_clocks() would become pm_clk_suspend() an dyour
> _disable_clocks() would become pm_clk_resume().

Very interesting, I was not aware of this.

> I might not be following the mapping between PMC and PGs though so not
> sure pg->pmc->dev is the right struct device, but you get the idea.

Yes, so this will not work here as-is, because the pmc->dev is common to
all pm-domains (it is the device that creates all the pm-domains). So to
make this work, I would need to create a device for each pm-domain and
add the clocks to that.

I see that this works very well for normal drivers, but it does not feel
so natural for pm-domains where we don't have a device struct today. By
the way, the rockchip pm-domains implementation is very much in the same
boat as tegra, where there are multiple clocks per pm-domain and it is
handled by a simple list. So I am not sure if you think that we should
be turning all pm-domains registered by pm_genpd_init() into a device
and then we can make use of these pm_clk_XXXX() APIs?

I have implemented the generic clk APIs that Ulf and I discussed for
handling multiple clocks, but if we think that this is a better way,
then I will hold off for now.

Cheers
Jon


From kirill at shutemov.name  Mon Feb 15 03:31:59 2016
From: kirill at shutemov.name (Kirill A. Shutemov)
Date: Mon, 15 Feb 2016 13:31:59 +0200
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <alpine.LFD.2.20.1602131238260.1910@schleppi>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
 <alpine.LFD.2.20.1602131238260.1910@schleppi>
Message-ID: <20160215113159.GA28832@node.shutemov.name>

On Sat, Feb 13, 2016 at 12:58:31PM +0100, Sebastian Ott wrote:
> 
> On Sat, 13 Feb 2016, Kirill A. Shutemov wrote:
> > Could you check if revert of fecffad25458 helps?
> 
> I reverted fecffad25458 on top of 721675fcf277cf - it oopsed with:
> 
> ? 1851.721062! Unable to handle kernel pointer dereference in virtual kernel address space
> ? 1851.721075! failing address: 0000000000000000 TEID: 0000000000000483
> ? 1851.721078! Fault in home space mode while using kernel ASCE.
> ? 1851.721085! AS:0000000000d5c007 R3:00000000ffff0007 S:00000000ffffa800 P:000000000000003d
> ? 1851.721128! Oops: 0004 ilc:3 ?#1! PREEMPT SMP DEBUG_PAGEALLOC
> ? 1851.721135! Modules linked in: bridge stp llc btrfs mlx4_ib mlx4_en ib_sa ib_mad vxlan xor ip6_udp_tunnel ib_core udp_tunnel ptp pps_core ib_addr ghash_s390raid6_pq prng ecb aes_s390 mlx4_core des_s390 des_generic genwqe_card sha512_s390 sha256_s390 sha1_s390 sha_common crc_itu_t dm_mod scm_block vhost_net tun vhost eadm_sch macvtap macvlan kvm autofs4
> ? 1851.721183! CPU: 7 PID: 256422 Comm: bash Not tainted 4.5.0-rc3-00058-g07923d7-dirty #178
> ? 1851.721186! task: 000000007fbfd290 ti: 000000008c604000 task.ti: 000000008c604000
> ? 1851.721189! Krnl PSW : 0704d00180000000 000000000045d3b8 (__rb_erase_color+0x280/0x308)
> ? 1851.721200!            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
>                Krnl GPRS: 0000000000000001 0000000000000020 0000000000000000 00000000bd07eff1
> ? 1851.721205!            000000000027ca10 0000000000000000 0000000083e45898 0000000077b61198
> ? 1851.721207!            000000007ce1a490 00000000bd07eff0 000000007ce1a548 000000000027ca10
> ? 1851.721210!            00000000bd07c350 00000000bd07eff0 000000008c607aa8 000000008c607a68
> ? 1851.721221! Krnl Code: 000000000045d3aa: e3c0d0080024       stg     %%r12,8(%%r13)
>                           000000000045d3b0: b9040039           lgr     %%r3,%%r9
>                          #000000000045d3b4: a53b0001           oill    %%r3,1
>                          >000000000045d3b8: e33010000024       stg     %%r3,0(%%r1)
>                           000000000045d3be: ec28000e007c       cgij    %%r2,0,8,45d3da
>                           000000000045d3c4: e34020000004       lg      %%r4,0(%%r2)
>                           000000000045d3ca: b904001c           lgr     %%r1,%%r12
>                           000000000045d3ce: ec143f3f0056       rosbg   %%r1,%%r4,63,63,0
> ? 1851.721269! Call Trace:
> ? 1851.721273! (?<0000000083e45898>! 0x83e45898)
> ? 1851.721279!  ?<000000000029342a>! unlink_anon_vmas+0x9a/0x1d8
> ? 1851.721282!  ?<0000000000283f34>! free_pgtables+0xcc/0x148
> ? 1851.721285!  ?<000000000028c376>! exit_mmap+0xd6/0x300
> ? 1851.721289!  ?<0000000000134db8>! mmput+0x90/0x118
> ? 1851.721294!  ?<00000000002d76bc>! flush_old_exec+0x5d4/0x700
> ? 1851.721298!  ?<00000000003369f4>! load_elf_binary+0x2f4/0x13e8
> ? 1851.721301!  ?<00000000002d6e4a>! search_binary_handler+0x9a/0x1f8
> ? 1851.721304!  ?<00000000002d8970>! do_execveat_common.isra.32+0x668/0x9a0
> ? 1851.721307!  ?<00000000002d8cec>! do_execve+0x44/0x58
> ? 1851.721310!  ?<00000000002d8f92>! SyS_execve+0x3a/0x48
> ? 1851.721315!  ?<00000000006fb096>! system_call+0xd6/0x258
> ? 1851.721317!  ?<000003ff997436d6>! 0x3ff997436d6
> ? 1851.721319! INFO: lockdep is turned off.
> ? 1851.721321! Last Breaking-Event-Address:
> ? 1851.721323!  ?<000000000045d31a>! __rb_erase_color+0x1e2/0x308
> ? 1851.721327!
> ? 1851.721329! ---? end trace 0d80041ac00cfae2 !---
> 
> 
> > 
> > And could you share how crashes looks like? I haven't seen backtraces yet.
> > 
> 
> Sure. I didn't because they really looked random to me. Most of the time
> in rcu or list debugging but I thought these have just been the messenger
> observing a corruption first. Anyhow, here is an older one that might look
> interesting:
> 
> [   59.851421] list_del corruption. next->prev should be 000000006e1eb000, but was 0000000000000400

This kinda interesting: 0x400 is TAIL_MAPPING.. Hm..

Could you check if you see the problem on commit 1c290f642101 and its
immediate parent?

-- 
 Kirill A. Shutemov


From ard.biesheuvel at linaro.org  Mon Feb 15 03:32:31 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 15 Feb 2016 12:32:31 +0100
Subject: [PATCH v2 0/2] efi: ARM/arm64: wire up ESRT table
Message-ID: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>

As reported by Tyler, the ESRT support was not wired up yet for ARM or
arm64, hence this series.

Patch #1 replaces ioremap with memremap in the generic ESRT support, since
what we are mapping is not I/O, and this does make a difference on ARM/arm64

Patch #2 adds the missing efi_esrt_init() call, and tweaks some memmap fields
that efi_mem_desc_lookup() expects.

Ard Biesheuvel (2):
  efi: esrt: use memremap not ioremap to access ESRT table in memory
  arm64/efi: esrt: add missing call to efi_esrt_init()

 drivers/firmware/efi/arm-init.c |  3 +++
 drivers/firmware/efi/esrt.c     | 16 ++++++++--------
 2 files changed, 11 insertions(+), 8 deletions(-)

-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 15 03:32:32 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 15 Feb 2016 12:32:32 +0100
Subject: [PATCH v2 1/2] efi: esrt: use memremap not ioremap to access ESRT
 table in memory
In-Reply-To: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>

On ARM and arm64, ioremap() and memremap() are not interchangeable like
on x86, and the use of ioremap() on ordinary RAM is typically flagged
as an error if the memory region being mapped is also covered by the
linear mapping, since that would lead to aliases with conflicting
cacheability attributes.

Since what we are dealing with is not an I/O region with side effects,
using ioremap() here is arguably incorrect anyway, so let's replace
it with memremap instead. Also add a missing unmap on the success path,
and drop a memblock_remove() call which does not belong here, this far
into the boot sequence.

Cc: Peter Jones <pjones at redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/firmware/efi/esrt.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/firmware/efi/esrt.c b/drivers/firmware/efi/esrt.c
index 22c5285f7705..f096a0a26dbd 100644
--- a/drivers/firmware/efi/esrt.c
+++ b/drivers/firmware/efi/esrt.c
@@ -16,6 +16,7 @@
 #include <linux/device.h>
 #include <linux/efi.h>
 #include <linux/init.h>
+#include <linux/io.h>
 #include <linux/kernel.h>
 #include <linux/kobject.h>
 #include <linux/list.h>
@@ -385,15 +386,15 @@ static void cleanup_entry_list(void)
 static int __init esrt_sysfs_init(void)
 {
 	int error;
-	struct efi_system_resource_table __iomem *ioesrt;
+	struct efi_system_resource_table *memesrt;
 
 	pr_debug("esrt-sysfs: loading.\n");
 	if (!esrt_data || !esrt_data_size)
 		return -ENOSYS;
 
-	ioesrt = ioremap(esrt_data, esrt_data_size);
-	if (!ioesrt) {
-		pr_err("ioremap(%pa, %zu) failed.\n", &esrt_data,
+	memesrt = memremap(esrt_data, esrt_data_size, MEMREMAP_WB);
+	if (!memesrt) {
+		pr_err("memremap(%pa, %zu, MEMREMAP_WB) failed.\n", &esrt_data,
 		       esrt_data_size);
 		return -ENOMEM;
 	}
@@ -401,11 +402,12 @@ static int __init esrt_sysfs_init(void)
 	esrt = kmalloc(esrt_data_size, GFP_KERNEL);
 	if (!esrt) {
 		pr_err("kmalloc failed. (wanted %zu bytes)\n", esrt_data_size);
-		iounmap(ioesrt);
+		memunmap(memesrt);
 		return -ENOMEM;
 	}
 
-	memcpy_fromio(esrt, ioesrt, esrt_data_size);
+	memcpy(esrt, memesrt, esrt_data_size);
+	memunmap(memesrt);
 
 	esrt_kobj = kobject_create_and_add("esrt", efi_kobj);
 	if (!esrt_kobj) {
@@ -432,8 +434,6 @@ static int __init esrt_sysfs_init(void)
 	if (error)
 		goto err_cleanup_list;
 
-	memblock_remove(esrt_data, esrt_data_size);
-
 	pr_debug("esrt-sysfs: loaded.\n");
 
 	return 0;
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 15 03:32:33 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 15 Feb 2016 12:32:33 +0100
Subject: [PATCH v2 2/2] arm64/efi: esrt: add missing call to efi_esrt_init()
In-Reply-To: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455535953-5056-3-git-send-email-ard.biesheuvel@linaro.org>

ESRT support is built by default for all architectures that define
CONFIG_EFI. However, this support was not wired up yet for ARM/arm64,
since efi_esrt_init() was never called. So add the missing call.

Since efi_esrt_init() uses efi_mem_desc_lookup(), which in turn relies
on efi.memmap having been assigned and populated completetely, add the
missing assignments of efi.memmap and efi.memmap->nr_map.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/firmware/efi/arm-init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9e15d571b53c..5c5e799bdb50 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -197,10 +197,13 @@ void __init efi_init(void)
 	memmap.map_end = memmap.map + params.mmap_size;
 	memmap.desc_size = params.desc_size;
 	memmap.desc_version = params.desc_ver;
+	memmap.nr_map = params.mmap_size / params.desc_size;
+	efi.memmap = &memmap;
 
 	if (uefi_init() < 0)
 		return;
 
+	efi_esrt_init();
 	reserve_regions();
 	early_memunmap(memmap.map, params.mmap_size);
 	memblock_mark_nomap(params.mmap & PAGE_MASK,
-- 
2.5.0



From hverkuil at xs4all.nl  Mon Feb 15 03:33:35 2016
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Mon, 15 Feb 2016 12:33:35 +0100
Subject: [PATCH v4 7/8] [media] vcodec: mediatek: Add Mediatek H264 Video
 Encoder Driver
In-Reply-To: <1454585703-42428-8-git-send-email-tiffany.lin@mediatek.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-7-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-8-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <56C1B78F.5050207@xs4all.nl>

On 02/04/2016 12:35 PM, Tiffany Lin wrote:
> Add h264 encoder driver for MT8173
> 
> Signed-off-by: Daniel Hsiao <daniel.hsiao at mediatek.com>
> Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
> ---
>  drivers/media/platform/mtk-vcodec/Makefile         |    3 +-
>  .../media/platform/mtk-vcodec/h264_enc/Makefile    |    6 +
>  .../platform/mtk-vcodec/h264_enc/venc_h264_if.c    |  540 ++++++++++++++++++++
>  .../platform/mtk-vcodec/h264_enc/venc_h264_if.h    |  165 ++++++
>  .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.c   |  309 +++++++++++
>  .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.h   |   30 ++
>  drivers/media/platform/mtk-vcodec/venc_drv_if.c    |    3 +
>  7 files changed, 1055 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/Makefile
>  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
> 
> diff --git a/drivers/media/platform/mtk-vcodec/Makefile b/drivers/media/platform/mtk-vcodec/Makefile
> index f4ef502..f47dfc7 100644
> --- a/drivers/media/platform/mtk-vcodec/Makefile
> +++ b/drivers/media/platform/mtk-vcodec/Makefile
> @@ -5,6 +5,7 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk_vcodec_intr.o \
>  				       mtk_vcodec_enc_pm.o \
>  				       venc_drv_if.o
>  
> -obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += vp8_enc/
> +
> +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += vp8_enc/ h264_enc/
>  
>  ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
> diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/Makefile b/drivers/media/platform/mtk-vcodec/h264_enc/Makefile
> new file mode 100644
> index 0000000..765b45f
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vcodec/h264_enc/Makefile
> @@ -0,0 +1,6 @@
> +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += venc_h264_if.o venc_h264_vpu.o
> +
> +ccflags-y += \
> +    -I$(srctree)/drivers/media/platform/mtk-vcodec/ \
> +    -I$(srctree)/drivers/media/platform/mtk-vcodec/h264_enc \
> +    -I$(srctree)/drivers/media/platform/mtk-vpu
> diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
> new file mode 100644
> index 0000000..c35fb26
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
> @@ -0,0 +1,540 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
> + *         Daniel Hsiao <daniel.hsiao at mediatek.com>
> + *         PoChun Lin <pochun.lin at mediatek.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.
> + */
> +
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +
> +#include "mtk_vcodec_drv.h"
> +#include "mtk_vcodec_util.h"
> +#include "mtk_vcodec_intr.h"
> +#include "mtk_vcodec_enc.h"
> +#include "mtk_vcodec_pm.h"
> +#include "mtk_vpu.h"
> +
> +#include "venc_h264_if.h"
> +#include "venc_h264_vpu.h"
> +
> +#define VENC_PIC_BITSTREAM_BYTE_CNT 0x0098
> +
> +enum venc_h264_irq_status {
> +	H264_IRQ_STATUS_ENC_SPS_INT = (1 << 0),
> +	H264_IRQ_STATUS_ENC_PPS_INT = (1 << 1),
> +	H264_IRQ_STATUS_ENC_FRM_INT = (1 << 2),
> +};
> +
> +static inline void h264_write_reg(struct venc_h264_inst *inst, u32 addr,
> +				  u32 val)
> +{
> +	writel(val, inst->hw_base + addr);
> +}
> +
> +static inline u32 h264_read_reg(struct venc_h264_inst *inst, u32 addr)
> +{
> +	return readl(inst->hw_base + addr);
> +}
> +
> +static void h264_enc_free_work_buf(struct venc_h264_inst *inst)
> +{
> +	int i;
> +
> +	mtk_vcodec_debug_enter(inst);
> +
> +	/* Except the SKIP_FRAME buffers,
> +	 * other buffers need to be freed by AP.
> +	 */
> +	for (i = 0; i < VENC_H264_VPU_WORK_BUF_MAX; i++) {
> +		if (i != VENC_H264_VPU_WORK_BUF_SKIP_FRAME)
> +			if (inst->work_bufs[i].va != NULL)
> +				mtk_vcodec_mem_free(inst->ctx,
> +						    &inst->work_bufs[i]);
> +	}
> +
> +	if (inst->pps_buf.va != NULL)
> +		mtk_vcodec_mem_free(inst->ctx, &inst->pps_buf);
> +
> +	mtk_vcodec_debug_leave(inst);
> +}
> +
> +static int h264_enc_alloc_work_buf(struct venc_h264_inst *inst, void *param)
> +{
> +	int i;
> +	int ret = 0;
> +	struct venc_h264_vpu_buf *wb = inst->vpu_inst.drv->work_bufs;
> +	struct venc_enc_prm *enc_param = param;
> +
> +	mtk_vcodec_debug_enter(inst);
> +
> +	for (i = 0; i < VENC_H264_VPU_WORK_BUF_MAX; i++) {
> +		/*
> +		 * This 'wb' structure is set by VPU side and shared to AP for
> +		 * buffer allocation and IO virtual addr mapping. For most of
> +		 * the buffers, AP will allocate the buffer according to 'size'
> +		 * field and store the IO virtual addr in 'iova' field. There
> +		 * are two exceptions:
> +		 * (1) RC_CODE buffer, it's pre-allocated in the VPU side, and
> +		 * save the VPU addr in the 'vpua' field. The AP will translate
> +		 * the VPU addr to the corresponding IO virtual addr and store
> +		 * in 'iova' field for reg setting in VPU side.
> +		 * (2) SKIP_FRAME buffer, it's pre-allocated in the VPU side,
> +		 * and save the VPU addr in the 'vpua' field. The AP will
> +		 * translate the VPU addr to the corresponding AP side virtual
> +		 * address and do some memcpy access to move to bitstream buffer
> +		 * assigned by v4l2 layer.
> +		 */
> +		if (i == VENC_H264_VPU_WORK_BUF_RC_CODE) {
> +			void *tmp_va;
> +
> +			tmp_va = vpu_mapping_dm_addr(inst->dev, wb[i].vpua);
> +			inst->work_bufs[i].size = wb[i].size;
> +			if (mtk_vcodec_mem_alloc(inst->ctx,
> +						 &inst->work_bufs[i])) {
> +				mtk_vcodec_err(inst,
> +					       "cannot allocate buf %d", i);
> +				ret = -ENOMEM;
> +				goto err_alloc;
> +			}
> +			memcpy(inst->work_bufs[i].va, tmp_va, wb[i].size);
> +			wb[i].iova = inst->work_bufs[i].dma_addr;
> +		} else if (i == VENC_H264_VPU_WORK_BUF_SKIP_FRAME) {
> +			inst->work_bufs[i].size = wb[i].size;
> +			inst->work_bufs[i].va = vpu_mapping_dm_addr(
> +				inst->dev, wb[i].vpua);
> +			inst->work_bufs[i].dma_addr = 0;
> +			wb[i].iova = inst->work_bufs[i].dma_addr;
> +		} else if (i == VENC_H264_VPU_WORK_BUF_SRC_LUMA ||
> +			   i == VENC_H264_VPU_WORK_BUF_SRC_CHROMA ||
> +			   i == VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CB ||
> +			   i == VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CR) {
> +			inst->work_bufs[i].size = wb[i].size;
> +			inst->work_bufs[i].dma_addr = 0;
> +			inst->work_bufs[i].va = NULL;
> +			wb[i].iova = inst->work_bufs[i].dma_addr;
> +		} else {
> +			inst->work_bufs[i].size = wb[i].size;
> +			if (mtk_vcodec_mem_alloc(inst->ctx,
> +						 &inst->work_bufs[i])) {
> +				mtk_vcodec_err(inst,
> +					       "cannot allocate buf %d", i);
> +				ret = -ENOMEM;
> +				goto err_alloc;
> +			}
> +			wb[i].iova = inst->work_bufs[i].dma_addr;
> +		}
> +		mtk_vcodec_debug(inst, "buf[%d] va=0x%p iova=0x%p size=0x%lx",
> +				 i, inst->work_bufs[i].va,
> +				 (void *)inst->work_bufs[i].dma_addr,
> +				 inst->work_bufs[i].size);
> +	}
> +
> +	if (enc_param->input_fourcc == VENC_YUV_FORMAT_NV12 ||
> +	    enc_param->input_fourcc == VENC_YUV_FORMAT_NV21) {
> +		enc_param->sizeimage[0] =
> +			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_LUMA].size;
> +		enc_param->sizeimage[1] =
> +			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_CHROMA].size;
> +		enc_param->sizeimage[2] = 0;
> +	} else {
> +		enc_param->sizeimage[0] =
> +			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_LUMA].size;
> +		enc_param->sizeimage[1] =
> +			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CB].size;
> +		enc_param->sizeimage[2] =
> +			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CR].size;
> +	}
> +
> +	/* the pps_buf is used by AP side only */
> +	inst->pps_buf.size = 128;
> +	if (mtk_vcodec_mem_alloc(inst->ctx,
> +				 &inst->pps_buf)) {
> +		mtk_vcodec_err(inst, "cannot allocate pps_buf");
> +		ret = -ENOMEM;
> +		goto err_alloc;
> +	}
> +	mtk_vcodec_debug_leave(inst);
> +
> +	return ret;
> +
> +err_alloc:
> +	h264_enc_free_work_buf(inst);
> +
> +	return ret;
> +}
> +
> +static unsigned int h264_enc_wait_venc_done(struct venc_h264_inst *inst)
> +{
> +	unsigned int irq_status = 0;
> +	struct mtk_vcodec_ctx *ctx = (struct mtk_vcodec_ctx *)inst->ctx;
> +
> +	mtk_vcodec_wait_for_done_ctx(ctx, MTK_INST_IRQ_RECEIVED,
> +				     WAIT_INTR_TIMEOUT, true);
> +	irq_status = ctx->irq_status;
> +	mtk_vcodec_debug(inst, "irq_status %x <-", irq_status);
> +
> +	return irq_status;
> +}
> +
> +static int h264_encode_sps(struct venc_h264_inst *inst,
> +			   struct mtk_vcodec_mem *bs_buf,
> +			   unsigned int *bs_size)
> +{
> +	int ret = 0;
> +	unsigned int irq_status;
> +
> +	mtk_vcodec_debug_enter(inst);
> +
> +	ret = h264_enc_vpu_encode(inst, H264_BS_MODE_SPS, NULL,
> +				  bs_buf, bs_size);
> +	if (ret)
> +		return ret;
> +
> +	irq_status = h264_enc_wait_venc_done(inst);
> +	if (irq_status != H264_IRQ_STATUS_ENC_SPS_INT) {
> +		mtk_vcodec_err(inst, "expect irq status %d",
> +			       H264_IRQ_STATUS_ENC_SPS_INT);
> +		return -EINVAL;
> +	}
> +
> +	*bs_size = h264_read_reg(inst, VENC_PIC_BITSTREAM_BYTE_CNT);
> +	mtk_vcodec_debug(inst, "bs size %d <-", *bs_size);
> +
> +	return ret;
> +}
> +
> +static int h264_encode_pps(struct venc_h264_inst *inst,
> +			   struct mtk_vcodec_mem *bs_buf,
> +			   unsigned int *bs_size)
> +{
> +	int ret = 0;
> +	unsigned int irq_status;
> +
> +	mtk_vcodec_debug_enter(inst);
> +
> +	ret = h264_enc_vpu_encode(inst, H264_BS_MODE_PPS, NULL,
> +				  bs_buf, bs_size);
> +	if (ret)
> +		return ret;
> +
> +	irq_status = h264_enc_wait_venc_done(inst);
> +	if (irq_status != H264_IRQ_STATUS_ENC_PPS_INT) {
> +		mtk_vcodec_err(inst, "expect irq status %d",
> +			       H264_IRQ_STATUS_ENC_PPS_INT);
> +		return -EINVAL;
> +	}
> +
> +	*bs_size = h264_read_reg(inst, VENC_PIC_BITSTREAM_BYTE_CNT);
> +	mtk_vcodec_debug(inst, "bs size %d <-", *bs_size);
> +
> +	return ret;
> +}
> +
> +static int h264_encode_frame(struct venc_h264_inst *inst,
> +			     struct venc_frm_buf *frm_buf,
> +			     struct mtk_vcodec_mem *bs_buf,
> +			     unsigned int *bs_size)
> +{
> +	int ret = 0;
> +	unsigned int irq_status;
> +
> +	mtk_vcodec_debug_enter(inst);
> +
> +	ret = h264_enc_vpu_encode(inst, H264_BS_MODE_FRAME, frm_buf,
> +				  bs_buf, bs_size);
> +	if (ret)
> +		return ret;
> +
> +	/*
> +	 * skip frame case: The skip frame buffer is composed by vpu side only,
> +	 * it does not trigger the hw, so skip the wait interrupt operation.
> +	 */
> +	if (!inst->vpu_inst.wait_int) {
> +		++inst->frm_cnt;
> +		return ret;
> +	}
> +
> +	irq_status = h264_enc_wait_venc_done(inst);
> +	if (irq_status != H264_IRQ_STATUS_ENC_FRM_INT) {
> +		mtk_vcodec_err(inst, "irq_status=%d failed", irq_status);
> +		return -EINVAL;
> +	}
> +
> +	*bs_size = h264_read_reg(inst,
> +				 VENC_PIC_BITSTREAM_BYTE_CNT);
> +	++inst->frm_cnt;
> +	mtk_vcodec_debug(inst, "frm %d bs size %d key_frm %d <-",
> +			 inst->frm_cnt,
> +			 *bs_size, inst->is_key_frm);
> +
> +	return ret;
> +}
> +
> +static void h264_encode_filler(struct venc_h264_inst *inst, void *buf,
> +			       int size)
> +{
> +	unsigned char *p = buf;
> +
> +	*p++ = 0x0;
> +	*p++ = 0x0;
> +	*p++ = 0x0;
> +	*p++ = 0x1;
> +	*p++ = 0xc;
> +	size -= 5;
> +	while (size) {
> +		*p++ = 0xff;
> +		size -= 1;
> +	}
> +}
> +
> +static int h264_enc_init(struct mtk_vcodec_ctx *ctx, unsigned long *handle)
> +{
> +	int ret = 0;
> +	struct venc_h264_inst *inst;
> +
> +	inst = kzalloc(sizeof(*inst), GFP_KERNEL);
> +	if (!inst)
> +		return -ENOMEM;
> +
> +	inst->ctx = ctx;
> +	inst->dev = mtk_vcodec_get_plat_dev(ctx);
> +	inst->hw_base = mtk_vcodec_get_reg_addr(inst->ctx, VENC_SYS);
> +
> +	mtk_vcodec_debug_enter(inst);
> +	ret = h264_enc_vpu_init(inst);
> +	if (ret)
> +		kfree(inst);
> +	else
> +		(*handle) = (unsigned long)inst;
> +
> +	mtk_vcodec_debug_leave(inst);
> +
> +	return ret;
> +}
> +
> +static int h264_enc_encode(unsigned long handle,
> +			   enum venc_start_opt opt,
> +			   struct venc_frm_buf *frm_buf,
> +			   struct mtk_vcodec_mem *bs_buf,
> +			   struct venc_done_result *result)
> +{
> +	int ret = 0;
> +	struct venc_h264_inst *inst = (struct venc_h264_inst *)handle;
> +	struct mtk_vcodec_ctx *ctx = inst->ctx;
> +
> +	mtk_vcodec_debug(inst, "opt %d ->", opt);
> +
> +	enable_irq(ctx->dev->enc_irq);
> +
> +	switch (opt) {
> +	case VENC_START_OPT_ENCODE_SEQUENCE_HEADER: {
> +		unsigned int bs_size_sps;
> +		unsigned int bs_size_pps;
> +
> +		memset(bs_buf->va, 0x38, 20);
> +		ret = h264_encode_sps(inst, bs_buf, &bs_size_sps);
> +		if (ret)
> +			goto encode_err;
> +
> +		memset(inst->pps_buf.va, 0x49, 20);
> +		ret = h264_encode_pps(inst, &inst->pps_buf, &bs_size_pps);
> +		if (ret)
> +			goto encode_err;
> +
> +		memcpy(bs_buf->va + bs_size_sps,
> +		       inst->pps_buf.va,
> +		       bs_size_pps);
> +		result->bs_size = bs_size_sps + bs_size_pps;
> +		result->is_key_frm = false;
> +	}
> +	break;

Wrong indentation for break, put it before the '}'.

> +
> +	case VENC_START_OPT_ENCODE_FRAME:
> +		if (inst->prepend_hdr) {

Invert the condition to make it more readable:

		if (!inst->prepend_hdr) {
			ret = h264_encode_frame(inst, frm_buf, bs_buf,
						&result->bs_size);
			if (ret)
				goto encode_err;
			result->is_key_frm = inst->is_key_frm;
			break;
		}

Now you can shift the remainder one tab to the left and join lines that
are now broken up (probably because they exceed 80 chars).

> +			int hdr_sz;
> +			int hdr_sz_ext;
> +			int bs_alignment = 128;
> +			int filler_sz = 0;
> +			struct mtk_vcodec_mem tmp_bs_buf;
> +			unsigned int bs_size_sps;
> +			unsigned int bs_size_pps;
> +			unsigned int bs_size_frm;
> +
> +			mtk_vcodec_debug(inst,
> +					 "h264_encode_frame prepend SPS/PPS");
> +			ret = h264_encode_sps(inst, bs_buf, &bs_size_sps);
> +			if (ret)
> +				goto encode_err;
> +
> +			ret = h264_encode_pps(inst, &inst->pps_buf,
> +					      &bs_size_pps);
> +			if (ret)
> +				goto encode_err;
> +
> +			memcpy(bs_buf->va + bs_size_sps,
> +			       inst->pps_buf.va,
> +			       bs_size_pps);
> +
> +			hdr_sz = bs_size_sps + bs_size_pps;
> +			hdr_sz_ext = (hdr_sz & (bs_alignment - 1));
> +			if (hdr_sz_ext) {
> +				filler_sz = bs_alignment - hdr_sz_ext;
> +				if (hdr_sz_ext + 5 > bs_alignment)
> +					filler_sz += bs_alignment;
> +				h264_encode_filler(
> +					inst, bs_buf->va + hdr_sz,
> +					filler_sz);
> +			}
> +
> +			tmp_bs_buf.va = bs_buf->va + hdr_sz +
> +				filler_sz;
> +			tmp_bs_buf.dma_addr = bs_buf->dma_addr + hdr_sz +
> +				filler_sz;
> +			tmp_bs_buf.size = bs_buf->size -
> +				(hdr_sz + filler_sz);
> +
> +			ret = h264_encode_frame(inst, frm_buf, &tmp_bs_buf,
> +						&bs_size_frm);
> +			if (ret)
> +				goto encode_err;
> +
> +			result->bs_size = hdr_sz + filler_sz + bs_size_frm;
> +			mtk_vcodec_debug(inst,
> +					 "hdr %d filler %d frame %d bs %d",
> +					 hdr_sz, filler_sz, bs_size_frm,
> +					 result->bs_size);
> +
> +			inst->prepend_hdr = 0;
> +		} else {
> +			ret = h264_encode_frame(inst, frm_buf, bs_buf,
> +						&result->bs_size);
> +			if (ret)
> +				goto encode_err;
> +		}
> +		result->is_key_frm = inst->is_key_frm;
> +		break;
> +
> +	default:
> +		mtk_vcodec_err(inst, "venc_start_opt %d not supported", opt);
> +		ret = -EINVAL;
> +		break;
> +	}
> +
> +encode_err:
> +	if (ret)
> +		result->msg = VENC_MESSAGE_ERR;
> +	else
> +		result->msg = VENC_MESSAGE_OK;
> +
> +	disable_irq(ctx->dev->enc_irq);
> +	mtk_vcodec_debug(inst, "opt %d <-", opt);
> +
> +	return ret;
> +}
> +
> +static int h264_enc_set_param(unsigned long handle,
> +			      enum venc_set_param_type type, void *in)
> +{
> +	int ret = 0;
> +	struct venc_h264_inst *inst = (struct venc_h264_inst *)handle;
> +	struct venc_enc_prm *enc_prm;
> +
> +	mtk_vcodec_debug(inst, "->type=%d", type);
> +
> +	switch (type) {
> +	case VENC_SET_PARAM_ENC:
> +		enc_prm = in;
> +		ret = h264_enc_vpu_set_param(inst, type, enc_prm);
> +		if (ret)
> +			break;
> +		if (inst->work_buf_allocated == 1) {
> +			h264_enc_free_work_buf(inst);
> +			inst->work_buf_allocated = 0;
> +		}
> +		if (inst->work_buf_allocated == 0) {
> +			ret = h264_enc_alloc_work_buf(inst, enc_prm);
> +			if (ret)
> +				break;
> +			inst->work_buf_allocated = 1;
> +		}
> +		break;
> +
> +	case VENC_SET_PARAM_FORCE_INTRA:
> +		ret = h264_enc_vpu_set_param(inst, type, 0);
> +		break;
> +
> +	case VENC_SET_PARAM_ADJUST_BITRATE:
> +		enc_prm = in;
> +		ret = h264_enc_vpu_set_param(inst, type, &enc_prm->bitrate);
> +		break;
> +
> +	case VENC_SET_PARAM_ADJUST_FRAMERATE:
> +		enc_prm = in;
> +		ret = h264_enc_vpu_set_param(inst, type, &enc_prm->frm_rate);
> +		break;
> +
> +	case VENC_SET_PARAM_I_FRAME_INTERVAL:
> +		ret = h264_enc_vpu_set_param(inst, type, in);
> +		break;
> +
> +	case VENC_SET_PARAM_SKIP_FRAME:
> +		ret = h264_enc_vpu_set_param(inst, type, 0);
> +		break;
> +
> +	case VENC_SET_PARAM_PREPEND_HEADER:
> +		inst->prepend_hdr = 1;
> +		mtk_vcodec_debug(inst, "set prepend header mode");
> +		break;
> +
> +	default:
> +		mtk_vcodec_err(inst, "type %d not supported", type);
> +		ret = -EINVAL;
> +		break;
> +	}
> +
> +	mtk_vcodec_debug_leave(inst);
> +
> +	return ret;
> +}
> +
> +static int h264_enc_deinit(unsigned long handle)
> +{
> +	int ret = 0;
> +	struct venc_h264_inst *inst = (struct venc_h264_inst *)handle;
> +
> +	mtk_vcodec_debug_enter(inst);
> +
> +	ret = h264_enc_vpu_deinit(inst);
> +
> +	if (inst->work_buf_allocated)
> +		h264_enc_free_work_buf(inst);
> +
> +	mtk_vcodec_debug_leave(inst);
> +	kfree(inst);
> +
> +	return ret;
> +}
> +
> +static struct venc_common_if venc_h264_if = {
> +	h264_enc_init,
> +	h264_enc_encode,
> +	h264_enc_set_param,
> +	h264_enc_deinit,
> +};
> +
> +struct venc_common_if *get_h264_enc_comm_if(void)
> +{
> +	return &venc_h264_if;
> +}
> diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
> new file mode 100644
> index 0000000..9ac317a
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
> @@ -0,0 +1,165 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
> + *         Daniel Hsiao <daniel.hsiao at mediatek.com>
> + *         PoChun Lin <pochun.lin at mediatek.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.
> + */
> +
> +#ifndef _VENC_H264_IF_H_
> +#define _VENC_H264_IF_H_
> +
> +#include "venc_drv_base.h"
> +
> +/**
> + * enum venc_h264_vpu_work_buf - h264 encoder buffer index
> + */
> +enum venc_h264_vpu_work_buf {
> +	VENC_H264_VPU_WORK_BUF_RC_INFO,
> +	VENC_H264_VPU_WORK_BUF_RC_CODE,
> +	VENC_H264_VPU_WORK_BUF_REC_LUMA,
> +	VENC_H264_VPU_WORK_BUF_REC_CHROMA,
> +	VENC_H264_VPU_WORK_BUF_REF_LUMA,
> +	VENC_H264_VPU_WORK_BUF_REF_CHROMA,
> +	VENC_H264_VPU_WORK_BUF_MV_INFO_1,
> +	VENC_H264_VPU_WORK_BUF_MV_INFO_2,
> +	VENC_H264_VPU_WORK_BUF_SKIP_FRAME,
> +	VENC_H264_VPU_WORK_BUF_SRC_LUMA,
> +	VENC_H264_VPU_WORK_BUF_SRC_CHROMA,
> +	VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CB,
> +	VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CR,
> +	VENC_H264_VPU_WORK_BUF_MAX,
> +};
> +
> +/**
> + * enum venc_h264_bs_mode - for bs_mode argument in h264_enc_vpu_encode
> + */
> +enum venc_h264_bs_mode {
> +	H264_BS_MODE_SPS,
> +	H264_BS_MODE_PPS,
> +	H264_BS_MODE_FRAME,
> +};
> +
> +/*
> + * struct venc_h264_vpu_config - Structure for h264 encoder configuration
> + * @input_fourcc: input fourcc
> + * @bitrate: target bitrate (in bps)
> + * @pic_w: picture width
> + * @pic_h: picture height
> + * @buf_w: buffer width
> + * @buf_h: buffer height
> + * @intra_period: intra frame period
> + * @framerate: frame rate
> + * @profile: as specified in standard
> + * @level: as specified in standard
> + * @wfd: WFD mode 1:on, 0:off
> + */
> +struct venc_h264_vpu_config {
> +	u32 input_fourcc;
> +	u32 bitrate;
> +	u32 pic_w;
> +	u32 pic_h;
> +	u32 buf_w;
> +	u32 buf_h;
> +	u32 intra_period;
> +	u32 framerate;
> +	u32 profile;
> +	u32 level;
> +	u32 wfd;
> +};
> +
> +/*
> + * struct venc_h264_vpu_buf - Structure for buffer information
> + * @align: buffer alignment (in bytes)
> + * @iova: IO virtual address
> + * @vpua: VPU side memory addr which is used by RC_CODE
> + * @size: buffer size (in bytes)
> + */
> +struct venc_h264_vpu_buf {
> +	u32 align;
> +	u32 iova;
> +	u32 vpua;
> +	u32 size;
> +};
> +
> +/*
> + * struct venc_h264_vpu_drv - Structure for VPU driver control and info share
> + * This structure is allocated in VPU side and shared to AP side.
> + * @config: h264 encoder configuration
> + * @work_bufs: working buffer information in VPU side
> + * The work_bufs here is for storing the 'size' info shared to AP side.
> + * The similar item in struct venc_h264_inst is for memory allocation
> + * in AP side. The AP driver will copy the 'size' from here to the one in
> + * struct mtk_vcodec_mem, then invoke mtk_vcodec_mem_alloc to allocate
> + * the buffer. After that, bypass the 'dma_addr' to the 'iova' field here for
> + * register setting in VPU side.
> + */
> +struct venc_h264_vpu_drv {
> +	struct venc_h264_vpu_config config;
> +	struct venc_h264_vpu_buf work_bufs[VENC_H264_VPU_WORK_BUF_MAX];
> +};
> +
> +/*
> + * struct venc_h264_vpu_inst - h264 encoder VPU driver instance
> + * @wq_hd: wait queue used for vpu cmd trigger then wait vpu interrupt done
> + * @signaled: flag used for checking vpu interrupt done
> + * @failure: flag to show vpu cmd succeeds or not
> + * @state: enum venc_ipi_msg_enc_state
> + * @bs_size: bitstream size for skip frame case usage
> + * @wait_int: flag to wait interrupt done (0: for skip frame case, 1: normal
> + *	      case)
> + * @id: VPU instance id
> + * @drv: driver structure allocated by VPU side and shared to AP side for
> + *	 control and info share
> + */
> +struct venc_h264_vpu_inst {
> +	wait_queue_head_t wq_hd;
> +	int signaled;
> +	int failure;
> +	int state;
> +	int bs_size;
> +	int wait_int;
> +	unsigned int id;
> +	struct venc_h264_vpu_drv *drv;
> +};
> +
> +/*
> + * struct venc_h264_inst - h264 encoder AP driver instance
> + * @hw_base: h264 encoder hardware register base
> + * @work_bufs: working buffer
> + * @pps_buf: buffer to store the pps bitstream
> + * @work_buf_allocated: working buffer allocated flag
> + * @frm_cnt: encoded frame count
> + * @prepend_hdr: when the v4l2 layer send VENC_SET_PARAM_PREPEND_HEADER cmd
> + *  through h264_enc_set_param interface, it will set this flag and prepend the
> + *  sps/pps in h264_enc_encode function.
> + * @is_key_frm: key frame flag
> + * @vpu_inst: VPU instance to exchange information between AP and VPU
> + * @ctx: context for v4l2 layer integration
> + * @dev: device for v4l2 layer integration
> + */
> +struct venc_h264_inst {
> +	void __iomem *hw_base;
> +	struct mtk_vcodec_mem work_bufs[VENC_H264_VPU_WORK_BUF_MAX];
> +	struct mtk_vcodec_mem pps_buf;
> +	bool work_buf_allocated;
> +	unsigned int frm_cnt;
> +	unsigned int prepend_hdr;
> +	unsigned int is_key_frm;
> +	struct venc_h264_vpu_inst vpu_inst;
> +	void *ctx;
> +	struct platform_device *dev;
> +};
> +
> +struct venc_common_if *get_h264_enc_comm_if(void);
> +
> +#endif
> diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
> new file mode 100644
> index 0000000..450be45
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
> @@ -0,0 +1,309 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
> + *         Daniel Hsiao <daniel.hsiao at mediatek.com>
> + *         PoChun Lin <pochun.lin at mediatek.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.
> + */
> +
> +#include "mtk_vpu.h"
> +
> +#include "venc_h264_if.h"
> +#include "venc_h264_vpu.h"
> +#include "venc_ipi_msg.h"
> +
> +static unsigned int h264_get_profile(unsigned int profile)
> +{
> +	/* (Baseline=66, Main=77, High=100) */
> +	switch (profile) {
> +	case V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE:
> +		return 66;
> +	case V4L2_MPEG_VIDEO_H264_PROFILE_MAIN:
> +		return 77;
> +	case V4L2_MPEG_VIDEO_H264_PROFILE_HIGH:
> +		return 100;
> +	default:
> +		return 100;
> +	}
> +}
> +
> +static unsigned int h264_get_level(unsigned int level)
> +{
> +	/* (UpTo4.1(HighProfile)) */
> +	switch (level) {
> +	case V4L2_MPEG_VIDEO_H264_LEVEL_1_0:
> +		return 10;
> +	case V4L2_MPEG_VIDEO_H264_LEVEL_1_1:
> +		return 11;
> +	case V4L2_MPEG_VIDEO_H264_LEVEL_1_2:
> +		return 12;
> +	case V4L2_MPEG_VIDEO_H264_LEVEL_1_3:
> +		return 13;
> +	case V4L2_MPEG_VIDEO_H264_LEVEL_2_0:
> +		return 20;
> +	case V4L2_MPEG_VIDEO_H264_LEVEL_2_1:
> +		return 21;
> +	case V4L2_MPEG_VIDEO_H264_LEVEL_2_2:
> +		return 22;
> +	case V4L2_MPEG_VIDEO_H264_LEVEL_3_0:
> +		return 30;
> +	case V4L2_MPEG_VIDEO_H264_LEVEL_3_1:
> +		return 31;
> +	case V4L2_MPEG_VIDEO_H264_LEVEL_3_2:
> +		return 32;
> +	case V4L2_MPEG_VIDEO_H264_LEVEL_4_0:
> +		return 40;
> +	case V4L2_MPEG_VIDEO_H264_LEVEL_4_1:
> +		return 41;
> +	default:
> +		return 31;
> +	}
> +}
> +
> +static void handle_h264_enc_init_msg(struct venc_h264_inst *inst, void *data)
> +{
> +	struct venc_vpu_ipi_msg_init *msg = data;
> +
> +	inst->vpu_inst.id = msg->inst_id;
> +	inst->vpu_inst.drv = (struct venc_h264_vpu_drv *)vpu_mapping_dm_addr(
> +		inst->dev, msg->inst_id);
> +}
> +
> +static void handle_h264_enc_encode_msg(struct venc_h264_inst *inst, void *data)
> +{
> +	struct venc_vpu_ipi_msg_enc *msg = data;
> +
> +	inst->vpu_inst.state = msg->state;
> +	inst->vpu_inst.bs_size = msg->bs_size;
> +	inst->is_key_frm = msg->key_frame;
> +}
> +
> +static void h264_enc_vpu_ipi_handler(void *data, unsigned int len, void *priv)
> +{
> +	struct venc_vpu_ipi_msg_common *msg = data;
> +	struct venc_h264_inst *inst = (struct venc_h264_inst *)msg->venc_inst;
> +
> +	mtk_vcodec_debug(inst, "msg_id %x inst %p status %d",
> +			 msg->msg_id, inst, msg->status);
> +
> +	switch (msg->msg_id) {
> +	case VPU_IPIMSG_H264_ENC_INIT_DONE:
> +		handle_h264_enc_init_msg(inst, data);
> +		break;
> +	case VPU_IPIMSG_H264_ENC_SET_PARAM_DONE:
> +		break;
> +	case VPU_IPIMSG_H264_ENC_ENCODE_DONE:
> +		handle_h264_enc_encode_msg(inst, data);
> +		break;
> +	case VPU_IPIMSG_H264_ENC_DEINIT_DONE:
> +		break;
> +	default:
> +		mtk_vcodec_err(inst, "unknown msg id %x", msg->msg_id);
> +		break;
> +	}
> +
> +	inst->vpu_inst.signaled = 1;
> +	inst->vpu_inst.failure = (msg->status != VENC_IPI_MSG_STATUS_OK);
> +
> +	mtk_vcodec_debug_leave(inst);
> +}
> +
> +static int h264_enc_vpu_send_msg(struct venc_h264_inst *inst, void *msg,
> +				 int len)
> +{
> +	int status;
> +
> +	mtk_vcodec_debug_enter(inst);
> +	status = vpu_ipi_send(inst->dev, IPI_VENC_H264, msg, len);
> +	if (status) {
> +		mtk_vcodec_err(inst, "vpu_ipi_send msg %x len %d fail %d",
> +			       *(unsigned int *)msg, len, status);
> +		return -EINVAL;
> +	}
> +	mtk_vcodec_debug_leave(inst);
> +
> +	return 0;
> +}
> +
> +int h264_enc_vpu_init(struct venc_h264_inst *inst)
> +{
> +	int status;
> +	struct venc_ap_ipi_msg_init out;
> +
> +	mtk_vcodec_debug_enter(inst);
> +
> +	init_waitqueue_head(&inst->vpu_inst.wq_hd);
> +	inst->vpu_inst.signaled = 0;
> +	inst->vpu_inst.failure = 0;
> +
> +	status = vpu_ipi_register(inst->dev, IPI_VENC_H264,
> +				  h264_enc_vpu_ipi_handler,
> +				  "h264_enc", NULL);
> +	if (status) {
> +		mtk_vcodec_err(inst, "vpu_ipi_register fail %d", status);
> +		return -EINVAL;
> +	}
> +
> +	out.msg_id = AP_IPIMSG_H264_ENC_INIT;
> +	out.venc_inst = (unsigned long)inst;
> +	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
> +	    inst->vpu_inst.failure) {
> +		mtk_vcodec_err(inst, "AP_IPIMSG_H264_ENC_INIT failed");
> +		return -EINVAL;
> +	}
> +
> +	mtk_vcodec_debug_leave(inst);
> +
> +	return 0;
> +}
> +
> +int h264_enc_vpu_set_param(struct venc_h264_inst *inst, unsigned int id,
> +			   void *param)
> +{
> +	struct venc_ap_ipi_msg_set_param out;
> +
> +	mtk_vcodec_debug(inst, "id %d ->", id);
> +
> +	out.msg_id = AP_IPIMSG_H264_ENC_SET_PARAM;
> +	out.inst_id = inst->vpu_inst.id;
> +	out.param_id = id;
> +	switch (id) {
> +	case VENC_SET_PARAM_ENC: {
> +		struct venc_enc_prm *enc_param = (struct venc_enc_prm *)param;
> +
> +		inst->vpu_inst.drv->config.input_fourcc =
> +			enc_param->input_fourcc;
> +		inst->vpu_inst.drv->config.bitrate = enc_param->bitrate;
> +		inst->vpu_inst.drv->config.pic_w = enc_param->width;
> +		inst->vpu_inst.drv->config.pic_h = enc_param->height;
> +		inst->vpu_inst.drv->config.buf_w = enc_param->buf_width;
> +		inst->vpu_inst.drv->config.buf_h = enc_param->buf_height;
> +		inst->vpu_inst.drv->config.intra_period =
> +			enc_param->intra_period;
> +		inst->vpu_inst.drv->config.framerate = enc_param->frm_rate;
> +		inst->vpu_inst.drv->config.profile =
> +			h264_get_profile(enc_param->h264_profile);
> +		inst->vpu_inst.drv->config.level =
> +			h264_get_level(enc_param->h264_level);
> +		inst->vpu_inst.drv->config.wfd = 0;
> +		out.data_item = 0;
> +		break;
> +	}
> +	case VENC_SET_PARAM_FORCE_INTRA:
> +		out.data_item = 0;
> +		break;
> +	case VENC_SET_PARAM_ADJUST_BITRATE:
> +		out.data_item = 1;
> +		out.data[0] = *(unsigned int *)param;
> +		break;
> +	case VENC_SET_PARAM_ADJUST_FRAMERATE:
> +		out.data_item = 1;
> +		out.data[0] = *(unsigned int *)param;
> +		break;
> +	case VENC_SET_PARAM_I_FRAME_INTERVAL:
> +		out.data_item = 1;
> +		out.data[0] = *(unsigned int *)param;
> +		break;
> +	case VENC_SET_PARAM_SKIP_FRAME:
> +		out.data_item = 0;
> +		break;
> +	}
> +	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
> +	    inst->vpu_inst.failure) {
> +		mtk_vcodec_err(inst,
> +			       "AP_IPIMSG_H264_ENC_SET_PARAM %d fail", id);
> +		return -EINVAL;
> +	}
> +
> +	mtk_vcodec_debug(inst, "id %d <-", id);
> +
> +	return 0;
> +}
> +
> +int h264_enc_vpu_encode(struct venc_h264_inst *inst, unsigned int bs_mode,
> +			struct venc_frm_buf *frm_buf,
> +			struct mtk_vcodec_mem *bs_buf,
> +			unsigned int *bs_size)
> +{
> +	struct venc_ap_ipi_msg_enc out;
> +
> +	mtk_vcodec_debug(inst, "bs_mode %d ->", bs_mode);
> +
> +	out.msg_id = AP_IPIMSG_H264_ENC_ENCODE;
> +	out.inst_id = inst->vpu_inst.id;
> +	out.bs_mode = bs_mode;
> +	if (frm_buf) {
> +		if ((frm_buf->fb_addr.dma_addr % 16 == 0) &&
> +		    (frm_buf->fb_addr1.dma_addr % 16 == 0) &&
> +		    (frm_buf->fb_addr2.dma_addr % 16 == 0)) {
> +			out.input_addr[0] = frm_buf->fb_addr.dma_addr;
> +			out.input_addr[1] = frm_buf->fb_addr1.dma_addr;
> +			out.input_addr[2] = frm_buf->fb_addr2.dma_addr;
> +		} else {
> +			mtk_vcodec_err(inst, "dma_addr not align to 16");
> +			return -EINVAL;
> +		}
> +	} else {
> +		out.input_addr[0] = 0;
> +		out.input_addr[1] = 0;
> +		out.input_addr[2] = 0;
> +	}
> +	if (bs_buf) {
> +		out.bs_addr = bs_buf->dma_addr;
> +		out.bs_size = bs_buf->size;
> +	} else {
> +		out.bs_addr = 0;
> +		out.bs_size = 0;
> +	}
> +	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
> +	    inst->vpu_inst.failure) {
> +		mtk_vcodec_err(inst, "AP_IPIMSG_H264_ENC_ENCODE %d fail",
> +			       bs_mode);
> +		return -EINVAL;
> +	}
> +
> +	mtk_vcodec_debug(inst, "state %d size %d key_frm %d",
> +			 inst->vpu_inst.state, inst->vpu_inst.bs_size,
> +			 inst->is_key_frm);
> +
> +	inst->vpu_inst.wait_int = 1;
> +	if (inst->vpu_inst.state == VEN_IPI_MSG_ENC_STATE_SKIP) {
> +		*bs_size = inst->vpu_inst.bs_size;
> +		memcpy(bs_buf->va,
> +		       inst->work_bufs[VENC_H264_VPU_WORK_BUF_SKIP_FRAME].va,
> +		       *bs_size);
> +		inst->vpu_inst.wait_int = 0;
> +	}
> +
> +	mtk_vcodec_debug(inst, "bs_mode %d <-", bs_mode);
> +
> +	return 0;
> +}
> +
> +int h264_enc_vpu_deinit(struct venc_h264_inst *inst)
> +{
> +	struct venc_ap_ipi_msg_deinit out;
> +
> +	mtk_vcodec_debug_enter(inst);
> +
> +	out.msg_id = AP_IPIMSG_H264_ENC_DEINIT;
> +	out.inst_id = inst->vpu_inst.id;
> +	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
> +	    inst->vpu_inst.failure) {
> +		mtk_vcodec_err(inst, "AP_IPIMSG_H264_ENC_DEINIT fail");
> +		return -EINVAL;
> +	}
> +
> +	mtk_vcodec_debug_leave(inst);
> +
> +	return 0;
> +}
> diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
> new file mode 100644
> index 0000000..deccc6f
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
> @@ -0,0 +1,30 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
> + *         Daniel Hsiao <daniel.hsiao at mediatek.com>
> + *         PoChun Lin <pochun.lin at mediatek.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.
> + */
> +
> +#ifndef _VENC_H264_VPU_H_
> +#define _VENC_H264_VPU_H_
> +
> +int h264_enc_vpu_init(struct venc_h264_inst *inst);
> +int h264_enc_vpu_set_param(struct venc_h264_inst *inst, unsigned int id,
> +			   void *param);
> +int h264_enc_vpu_encode(struct venc_h264_inst *inst, unsigned int bs_mode,
> +			struct venc_frm_buf *frm_buf,
> +			struct mtk_vcodec_mem *bs_buf,
> +			unsigned int *bs_size);
> +int h264_enc_vpu_deinit(struct venc_h264_inst *inst);
> +
> +#endif
> diff --git a/drivers/media/platform/mtk-vcodec/venc_drv_if.c b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
> index d293f2c..28ef4a7 100644
> --- a/drivers/media/platform/mtk-vcodec/venc_drv_if.c
> +++ b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
> @@ -25,6 +25,7 @@
>  
>  #include "venc_drv_base.h"
>  #include "vp8_enc/venc_vp8_if.h"
> +#include "h264_enc/venc_h264_if.h"
>  
>  int venc_if_create(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
>  {
> @@ -38,6 +39,8 @@ int venc_if_create(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
>                  ctx->enc_if = get_vp8_enc_comm_if();
>                  break;
>  	case V4L2_PIX_FMT_H264:
> +	        ctx->enc_if = get_h264_enc_comm_if();
> +	        break;
>  	default:
>  		return -EINVAL;
>  	}
> 

Regards,

	Hans


From mark.rutland at arm.com  Mon Feb 15 03:33:50 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 15 Feb 2016 11:33:50 +0000
Subject: [RFC PATCH 1/7] arm64/perf: Basic uncore counter support for
 Cavium ThunderX
In-Reply-To: <56BE8B2D.1000001@gmail.com>
References: <cover.1455295032.git.jglauber@cavium.com>
 <8bd93a25e069ed6428bc6c21fc53270962ccafcc.1455295032.git.jglauber@cavium.com>
 <20160212173658.GD20262@leverpostej> <56BE8B2D.1000001@gmail.com>
Message-ID: <20160215113350.GB9732@leverpostej>

On Fri, Feb 12, 2016 at 05:47:25PM -0800, David Daney wrote:
> On 02/12/2016 09:36 AM, Mark Rutland wrote:
> >On Fri, Feb 12, 2016 at 05:55:06PM +0100, Jan Glauber wrote:
> [...]
> >>2) Counters are summarized across the different units of the same type,
> >>    e.g. L2C TAD 0..7 is presented as a single counter (adding the
> >>    values from TAD 0 to 7). Although losing the ability to read a
> >>    single value the merged values are easier to use and yield
> >>    enough information.
> >
> >I'm not sure I follow this. What is easier? What are you doing, and what
> >are you comparing that with to say that your approach is easier?
> >
> >It sounds like it should be possible to handle multiple counters like
> >this, so I don't follow why you want to amalgamate them in-kernel.
> >
> 
> The values of the individual counters are close to meaningless.  The
> only thing that is meaningful to someone reading the counters is the
> aggregate sum of all the counts.

I obviously know nowhere near enough about your system to say with
certainty, but it may turn out that being able to track counters
individually is useful for some profiling/debugging scenario. How
meaningful the individual counts are really depends on what you're
trying to figure out.

If you believe that aggregate values are sufficient, then I'm happy to
leave that as-is.

> >>+void thunder_uncore_read(struct perf_event *event)
> >>+{
> >>+	struct thunder_uncore *uncore = event_to_thunder_uncore(event);
> >>+	struct hw_perf_event *hwc = &event->hw;
> >>+	u64 prev, new = 0;
> >>+	s64 delta;
> >>+	int i;
> >>+
> >>+	/*
> >>+	 * since we do not enable counter overflow interrupts,
> >>+	 * we do not have to worry about prev_count changing on us
> >>+	 */
> >
> >Without overflow interrupts, how do you ensure that you account for
> >overflow in a reasonable time window (i.e. before the counter runs past
> >its initial value)?
> 
> Two reasons:
> 
>   1) There are no interrupts.
> 
>   2) The counters are 64-bit, they never overflow.

Ok. Please point this out in the comment so that reviewers aren't
misled. Stating that we don't enable an interrupt implies that said
interrupt exists.

> >>+	/* and we do not enable counter overflow interrupts */
> >
> >That statement raises far more questions than it answers.
> >
> >_why_ do we not user overflow interrupts?
> 
> As stated above, there are *no* overflow interrupts.

Ok. As stated above, please fix this comment to not mislead.

> The events we are counting cannot be attributed to any one (or even
> any) CPU, they run asynchronous to the CPU, so even if there were
> interrupts, they would be meaningless.

Yes, they are meaningless w.r.t. the state of an arbitrary CPU.

Were they to exist you could use them to drive other snapshotting of the
state of the uncore PMU, to get an idea of the frequency/stability of
events over time, etc. Userspace might then decide to snapshot other
whole system state based on events fed to it.

That's moot if they don't exist.

Mark.


From catalin.marinas at arm.com  Mon Feb 15 03:45:05 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 15 Feb 2016 11:45:05 +0000
Subject: [PATCH] arm64: mark kernel text segment as MEMBLOCK_NOMAP
In-Reply-To: <1455528512-32491-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455528512-32491-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160215114505.GE13683@e104818-lin.cambridge.arm.com>

On Mon, Feb 15, 2016 at 10:28:32AM +0100, Ard Biesheuvel wrote:
> Commit 752af28bd711 ("arm64: move kernel image to base of vmalloc area")
> moves the mapping of the kernel text and data segments out of the linear
> region, and takes care not to create a writable alias of the read-only
> kernel text segment by checking each memblock against overlap when the
> memblocks are mapped into the linear mapping.
> 
> However, it is more correct, and much simpler, to mark the [_stext, _etext]
> interval as MEMBLOCK_NOMAP. This will also prevent the interval from being
> omitted from the linear region, but this fact will now also be reflected
> in the output of pfn_valid(), and so code that expects any pfn_valid()
> page to be mapped and accessible (which is a reasonable assumption) does
> not get surprised by the text segment being inaccessible via the linear
> mapping.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
> 
> This should hopefully address the issue reported by James, but I suppose
> more work is required on the hibernate side to ensure the unmapped text
> region is preserved, since it is no longer covered by the linear mapping.

Ard, I'm about to drop the kernel memory map patches from -next. There
are several issues like KASAN (which may as well be a KASAN bug but I
haven't got to the bottom of it yet), initrd (you have patches but
require additional acks).

I'll keep your stuff on the for-next/kernmap branch and do further
debugging. If it stabilises in the next 1-2 weeks, I'll merge it into
for-next/core for 4.6, otherwise, it will have to wait. I would really
like these patches merged but it looks like they need wider testing.

I have another branch with your kaslr patches but I didn't dare to merge
them into for-next/core until we sort out the first sub-series.

-- 
Catalin


From stefano.stabellini at eu.citrix.com  Mon Feb 15 03:44:34 2016
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 15 Feb 2016 11:44:34 +0000
Subject: [PATCH 1/5] xen: audit usages of module.h ; remove unnecessary
 instances
In-Reply-To: <1455481970-15239-2-git-send-email-paul.gortmaker@windriver.com>
References: <1455481970-15239-1-git-send-email-paul.gortmaker@windriver.com>
 <1455481970-15239-2-git-send-email-paul.gortmaker@windriver.com>
Message-ID: <alpine.DEB.2.02.1602151104300.27008@kaball.uk.xensource.com>

On Sun, 14 Feb 2016, Paul Gortmaker wrote:
> Code that uses no modular facilities whatsoever should not be
> sourcing module.h at all, since that header drags in a bunch
> of other headers with it.
> 
> Similarly, code that is not explicitly using modular facilities
> like module_init() but only is declaring module_param setup
> variables should be using moduleparam.h and not the larger
> module.h file for that.
> 
> In making this change, we also uncover an implicit use of BUG()
> in inline fcns within arch/arm/include/asm/xen/hypercall.h so
> we explicitly source <linux/bug.h> for that file now.
> 
> Cc: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
> Cc: Boris Ostrovsky <boris.ostrovsky at oracle.com>
> Cc: David Vrabel <david.vrabel at citrix.com>
> Cc: xen-devel at lists.xenproject.org
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>

Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>


>  arch/arm/include/asm/xen/hypercall.h  | 2 ++
>  drivers/xen/events/events_2l.c        | 1 -
>  drivers/xen/events/events_base.c      | 2 +-
>  drivers/xen/events/events_fifo.c      | 1 -
>  drivers/xen/features.c                | 2 +-
>  drivers/xen/grant-table.c             | 1 -
>  drivers/xen/xen-pciback/conf_space.c  | 2 +-
>  drivers/xen/xen-pciback/pciback_ops.c | 2 +-
>  drivers/xen/xen-pciback/xenbus.c      | 2 +-
>  drivers/xen/xen-selfballoon.c         | 1 -
>  drivers/xen/xenbus/xenbus_xs.c        | 1 -
>  drivers/xen/xenfs/xensyms.c           | 1 -
>  12 files changed, 7 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
> index d769972db8cb..b6b962d70db9 100644
> --- a/arch/arm/include/asm/xen/hypercall.h
> +++ b/arch/arm/include/asm/xen/hypercall.h
> @@ -33,6 +33,8 @@
>  #ifndef _ASM_ARM_XEN_HYPERCALL_H
>  #define _ASM_ARM_XEN_HYPERCALL_H
>  
> +#include <linux/bug.h>
> +
>  #include <xen/interface/xen.h>
>  #include <xen/interface/sched.h>
>  #include <xen/interface/platform.h>
> diff --git a/drivers/xen/events/events_2l.c b/drivers/xen/events/events_2l.c
> index 7dd46312c180..51b488f5bfe9 100644
> --- a/drivers/xen/events/events_2l.c
> +++ b/drivers/xen/events/events_2l.c
> @@ -9,7 +9,6 @@
>  #include <linux/linkage.h>
>  #include <linux/interrupt.h>
>  #include <linux/irq.h>
> -#include <linux/module.h>
>  
>  #include <asm/sync_bitops.h>
>  #include <asm/xen/hypercall.h>
> diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
> index 524c22146429..488017a0806a 100644
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -26,7 +26,7 @@
>  #include <linux/linkage.h>
>  #include <linux/interrupt.h>
>  #include <linux/irq.h>
> -#include <linux/module.h>
> +#include <linux/moduleparam.h>
>  #include <linux/string.h>
>  #include <linux/bootmem.h>
>  #include <linux/slab.h>
> diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
> index eff2b88003d9..9289a17712e2 100644
> --- a/drivers/xen/events/events_fifo.c
> +++ b/drivers/xen/events/events_fifo.c
> @@ -36,7 +36,6 @@
>  #include <linux/linkage.h>
>  #include <linux/interrupt.h>
>  #include <linux/irq.h>
> -#include <linux/module.h>
>  #include <linux/smp.h>
>  #include <linux/percpu.h>
>  #include <linux/cpu.h>
> diff --git a/drivers/xen/features.c b/drivers/xen/features.c
> index 99eda169c779..d7d34fdfc993 100644
> --- a/drivers/xen/features.c
> +++ b/drivers/xen/features.c
> @@ -7,7 +7,7 @@
>   */
>  #include <linux/types.h>
>  #include <linux/cache.h>
> -#include <linux/module.h>
> +#include <linux/export.h>
>  
>  #include <asm/xen/hypercall.h>
>  
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index effbaf91791f..bb36b1e1dbcc 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -33,7 +33,6 @@
>  
>  #define pr_fmt(fmt) "xen:" KBUILD_MODNAME ": " fmt
>  
> -#include <linux/module.h>
>  #include <linux/sched.h>
>  #include <linux/mm.h>
>  #include <linux/slab.h>
> diff --git a/drivers/xen/xen-pciback/conf_space.c b/drivers/xen/xen-pciback/conf_space.c
> index 9c234209d8b5..8e67336f8ddd 100644
> --- a/drivers/xen/xen-pciback/conf_space.c
> +++ b/drivers/xen/xen-pciback/conf_space.c
> @@ -10,7 +10,7 @@
>   */
>  
>  #include <linux/kernel.h>
> -#include <linux/module.h>
> +#include <linux/moduleparam.h>
>  #include <linux/pci.h>
>  #include "pciback.h"
>  #include "conf_space.h"
> diff --git a/drivers/xen/xen-pciback/pciback_ops.c b/drivers/xen/xen-pciback/pciback_ops.c
> index 73dafdc494aa..5ad01f9c24fc 100644
> --- a/drivers/xen/xen-pciback/pciback_ops.c
> +++ b/drivers/xen/xen-pciback/pciback_ops.c
> @@ -6,7 +6,7 @@
>  
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>  
> -#include <linux/module.h>
> +#include <linux/moduleparam.h>
>  #include <linux/wait.h>
>  #include <linux/bitops.h>
>  #include <xen/events.h>
> diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> index 4843741e703a..c252eb3f0176 100644
> --- a/drivers/xen/xen-pciback/xenbus.c
> +++ b/drivers/xen/xen-pciback/xenbus.c
> @@ -6,7 +6,7 @@
>  
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>  
> -#include <linux/module.h>
> +#include <linux/moduleparam.h>
>  #include <linux/init.h>
>  #include <linux/list.h>
>  #include <linux/vmalloc.h>
> diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c
> index 3b2bffde534f..53a085fca00c 100644
> --- a/drivers/xen/xen-selfballoon.c
> +++ b/drivers/xen/xen-selfballoon.c
> @@ -71,7 +71,6 @@
>  #include <linux/swap.h>
>  #include <linux/mm.h>
>  #include <linux/mman.h>
> -#include <linux/module.h>
>  #include <linux/workqueue.h>
>  #include <linux/device.h>
>  #include <xen/balloon.h>
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index ba804f3d8278..374b12af8812 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -44,7 +44,6 @@
>  #include <linux/fcntl.h>
>  #include <linux/kthread.h>
>  #include <linux/rwsem.h>
> -#include <linux/module.h>
>  #include <linux/mutex.h>
>  #include <asm/xen/hypervisor.h>
>  #include <xen/xenbus.h>
> diff --git a/drivers/xen/xenfs/xensyms.c b/drivers/xen/xenfs/xensyms.c
> index a03f261b12d8..c6e2b4a542ea 100644
> --- a/drivers/xen/xenfs/xensyms.c
> +++ b/drivers/xen/xenfs/xensyms.c
> @@ -1,4 +1,3 @@
> -#include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/seq_file.h>
>  #include <linux/fs.h>
> -- 
> 2.6.1
> 


From ard.biesheuvel at linaro.org  Mon Feb 15 03:53:59 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 15 Feb 2016 12:53:59 +0100
Subject: [PATCH] arm64: mark kernel text segment as MEMBLOCK_NOMAP
In-Reply-To: <20160215114505.GE13683@e104818-lin.cambridge.arm.com>
References: <1455528512-32491-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160215114505.GE13683@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu-Y-k_LAbFZJjiPuHq6ssaFCb3WMG_fVGx3ODrvb+hEUQ@mail.gmail.com>

On 15 February 2016 at 12:45, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 15, 2016 at 10:28:32AM +0100, Ard Biesheuvel wrote:
>> Commit 752af28bd711 ("arm64: move kernel image to base of vmalloc area")
>> moves the mapping of the kernel text and data segments out of the linear
>> region, and takes care not to create a writable alias of the read-only
>> kernel text segment by checking each memblock against overlap when the
>> memblocks are mapped into the linear mapping.
>>
>> However, it is more correct, and much simpler, to mark the [_stext, _etext]
>> interval as MEMBLOCK_NOMAP. This will also prevent the interval from being
>> omitted from the linear region, but this fact will now also be reflected
>> in the output of pfn_valid(), and so code that expects any pfn_valid()
>> page to be mapped and accessible (which is a reasonable assumption) does
>> not get surprised by the text segment being inaccessible via the linear
>> mapping.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> ---
>>
>> This should hopefully address the issue reported by James, but I suppose
>> more work is required on the hibernate side to ensure the unmapped text
>> region is preserved, since it is no longer covered by the linear mapping.
>
> Ard, I'm about to drop the kernel memory map patches from -next. There
> are several issues like KASAN (which may as well be a KASAN bug but I
> haven't got to the bottom of it yet), initrd (you have patches but
> require additional acks).
>
> I'll keep your stuff on the for-next/kernmap branch and do further
> debugging. If it stabilises in the next 1-2 weeks, I'll merge it into
> for-next/core for 4.6, otherwise, it will have to wait. I would really
> like these patches merged but it looks like they need wider testing.
>

Agreed.

> I have another branch with your kaslr patches but I didn't dare to merge
> them into for-next/core until we sort out the first sub-series.
>

Yes, I noticed. As I pointed out in its cover letter, I expected the
first subseries to be the most problematic in terms of fallout in
other areas, and I turned out to be right, unfortunately. The coverage
so far has been quite useful tbh, especially since I apparently never
tested initrd.

If you are going to drop it for now anyway, I can do a v6sub1 with
this issue and the initrd issue addressed, but also an issue with the
KVM ksym ref patch with GCC 4.8. Since these issues affect
bisectability, I'd prefer to rebase entirely, and fold all the fixes
rather than apply them on top.


From ard.biesheuvel at linaro.org  Mon Feb 15 03:56:42 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 15 Feb 2016 12:56:42 +0100
Subject: [PATCH] arm64: mark kernel text segment as MEMBLOCK_NOMAP
In-Reply-To: <CAKv+Gu-Y-k_LAbFZJjiPuHq6ssaFCb3WMG_fVGx3ODrvb+hEUQ@mail.gmail.com>
References: <1455528512-32491-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160215114505.GE13683@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-Y-k_LAbFZJjiPuHq6ssaFCb3WMG_fVGx3ODrvb+hEUQ@mail.gmail.com>
Message-ID: <CAKv+Gu9OYMO=Sh-OO21YjCBPCfu0hJHZbfA78__RDpdXMhw1xw@mail.gmail.com>

On 15 February 2016 at 12:53, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 15 February 2016 at 12:45, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> On Mon, Feb 15, 2016 at 10:28:32AM +0100, Ard Biesheuvel wrote:
>>> Commit 752af28bd711 ("arm64: move kernel image to base of vmalloc area")
>>> moves the mapping of the kernel text and data segments out of the linear
>>> region, and takes care not to create a writable alias of the read-only
>>> kernel text segment by checking each memblock against overlap when the
>>> memblocks are mapped into the linear mapping.
>>>
>>> However, it is more correct, and much simpler, to mark the [_stext, _etext]
>>> interval as MEMBLOCK_NOMAP. This will also prevent the interval from being
>>> omitted from the linear region, but this fact will now also be reflected
>>> in the output of pfn_valid(), and so code that expects any pfn_valid()
>>> page to be mapped and accessible (which is a reasonable assumption) does
>>> not get surprised by the text segment being inaccessible via the linear
>>> mapping.
>>>
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>>> ---
>>>
>>> This should hopefully address the issue reported by James, but I suppose
>>> more work is required on the hibernate side to ensure the unmapped text
>>> region is preserved, since it is no longer covered by the linear mapping.
>>
>> Ard, I'm about to drop the kernel memory map patches from -next. There
>> are several issues like KASAN (which may as well be a KASAN bug but I
>> haven't got to the bottom of it yet), initrd (you have patches but
>> require additional acks).
>>
>> I'll keep your stuff on the for-next/kernmap branch and do further
>> debugging. If it stabilises in the next 1-2 weeks, I'll merge it into
>> for-next/core for 4.6, otherwise, it will have to wait. I would really
>> like these patches merged but it looks like they need wider testing.
>>
>
> Agreed.
>
>> I have another branch with your kaslr patches but I didn't dare to merge
>> them into for-next/core until we sort out the first sub-series.
>>
>
> Yes, I noticed. As I pointed out in its cover letter, I expected the
> first subseries to be the most problematic in terms of fallout in
> other areas, and I turned out to be right, unfortunately. The coverage
> so far has been quite useful tbh, especially since I apparently never
> tested initrd.
>
> If you are going to drop it for now anyway, I can do a v6sub1 with
> this issue and the initrd issue addressed, but also an issue with the
> KVM ksym ref patch with GCC 4.8.

Note that this is a transient issue that is gone after applying the
subsequent patch, but it would still be nice to get rid of it if we're
going to do another take anyway.

> Since these issues affect
> bisectability, I'd prefer to rebase entirely, and fold all the fixes
> rather than apply them on top.


From hverkuil at xs4all.nl  Mon Feb 15 04:04:51 2016
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Mon, 15 Feb 2016 13:04:51 +0100
Subject: [PATCH v4 0/8] Add MT8173 Video Encoder Driver and VPU Driver
In-Reply-To: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <56C1BEE3.4000904@xs4all.nl>

Hi Tiffany,

Once again, thanks for your patch series!

I have some more comments below.

On 02/04/2016 12:34 PM, Tiffany Lin wrote:
> 
> ==============
>  Introduction
> ==============
> 
> The purpose of this series is to add the driver for video codec hw embedded in the Mediatek's MT8173 SoCs.
> Mediatek Video Codec is able to handle video encoding of in a range of formats.
> 
> This patch series also include VPU driver. Mediatek Video Codec driver rely on VPU driver to load, communicate with VPU.
> 
> Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI.
> MTK IOMMU[1] and MTK SMI[2] have not yet been merged, but we wanted to start discussion about the driver earlier so it could be merged sooner.
> 
> [1]https://patchwork.kernel.org/patch/8120921/
> [2]https://patchwork.kernel.org/patch/8120941/
> 
> 
> ==================
>  Device interface
> ==================
> 
> In principle the driver bases on v4l2 memory-to-memory framework:
> it provides a single video node and each opened file handle gets its own private context with separate buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source buffers, i.e. raw video frames) and CAPTURE (for destination buffers, i.e. encoded video frames).
> 
> ==============================
>  VPU (Video Processor Unit)
> ==============================
> The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
> It is able to handle video decoding/encoding in a range of formats.
> The driver provides with VPU firmware download, memory management and the communication interface between CPU and VPU.
> For VPU initialization, it will create virtual memory for CPU access and physical address for VPU hw device access. When a decode/encode instance opens a device node, vpu driver will download vpu firmware to the device.
> A decode/encode instant will decode/encode a frame using VPU interface to interrupt vpu to handle decoding/encoding jobs.
> 
> Please have a look at the code and comments will be very much appreciated.
> 
> 
> Change in v4:
> Vcodec Part
> 1. Remove MTK_ENCODE_PARAM_SKIP_FRAME support
> 2. Remove MTK_ENCODE_PARAM_FRAME_TYPE and change to use V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME[3]
> 3. Refine Encoder HW clock source
> 4. Refine debug log
> 5. Add watchdog support
> 6. With patch "media: v4l2-compat-ioctl32: fix missing length copy in put_v4l2_buffer32"[4], v4l2-compliance test passed[5] in v4.4-rc5 
> 
> VPU Part
> 1. These two patches were Acked-by: Rob Herring <robh at kernel.org> in v3
>    [PATCH v3 1/8] dt-bindings: Add a binding for Mediatek Video Processor
>    [PATCH v3 3/8] arm64: dts: mediatek: Add node for Mediatek Video Processor Unit
>    Because we were wrong about how the hardware works, there is no connection between VPU and IOMMU HW
>    We remove VPU attaching to IOMMU
> 2. Support VPU running on 4GB DRAM system
> 3. Support VPU watchdog reset
> 4. Refine for coding style 
> 
> [3]https://patchwork.linuxtv.org/patch/32670/
> [4] https://patchwork.linuxtv.org/patch/32631/
> [5]localhost ~ # /usr/bin/v4l2-compliance -d /dev/video1
> Driver Info:
>         Driver name   : mtk-vcodec-en
>         Card type     : platform:mt817
>         Bus info      : platform:mt817

Perhaps this should be mt817x?

>         Driver version: 4.4.0
>         Capabilities  : 0x84204000
>                 Video Memory-to-Memory Multiplanar
>                 Streaming
>                 Extended Pix Format
>                 Device Capabilities
>         Device Caps   : 0x04204000
>                 Video Memory-to-Memory Multiplanar
>                 Streaming
>                 Extended Pix Format
> 
> Compliance test for device /dev/video1 (not using libv4l2):
> 
> Required ioctls:
>         test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
>         test second video open: OK
>         test VIDIOC_QUERYCAP: OK
>         test VIDIOC_G/S_PRIORITY: OK
> 
> Debug ioctls:
>         test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>         test VIDIOC_LOG_STATUS: OK (Not Supported)
> 
> Input ioctls:
>         test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>         test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>         test VIDIOC_ENUMAUDIO: OK (Not Supported)
>         test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
>         test VIDIOC_G/S_AUDIO: OK (Not Supported)
>         Inputs: 0 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
>         test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>         test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>         test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>         test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>         Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
>         test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>         test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>         test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>         test VIDIOC_G/S_EDID: OK (Not Supported)
> 
>         Control ioctls:
>                 test VIDIOC_QUERYCTRL/MENU: OK
>                 test VIDIOC_G/S_CTRL: OK
>                 test VIDIOC_G/S/TRY_EXT_CTRLS: OK
>                 test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
>                 test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>                 Standard Controls: 12 Private Controls: 0
> 
>         Format ioctls:
>                 test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>                 test VIDIOC_G/S_PARM: OK (Not Supported)
>                 test VIDIOC_G_FBUF: OK (Not Supported)
>                 test VIDIOC_G_FMT: OK
>                 test VIDIOC_TRY_FMT: OK
>                 test VIDIOC_S_FMT: OK
>                 test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> 
>         Codec ioctls:
>                 test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
>                 test VIDIOC_G_ENC_INDEX: OK (Not Supported)
>                 test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> 
>         Buffer ioctls:
>                 warn: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(475): VIDIOC_CREATE_BUFS not supported
>                 warn: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(475): VIDIOC_CREATE_BUFS not supported
>                 test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
>                 test VIDIOC_EXPBUF: OK
> 
> Total: 38, Succeeded: 38, Failed: 0, Warnings: 2

Looks great!

Having reviewed the v4 patch series I'd say it is close to being ready (at least
w.r.t. the V4L2 parts). Most of my comments are minor, but fixing the open()
limitation is probably a bigger change on your side.

It should be well worth the effort, though. In my experience limiting the number
of time you can call open() is always a sign of a design flaw and the code improves
if this is handled in the right place (usually start_streaming, which is when you
actually start to use the hardware).

And besides, limiting the number of open()s is out-of-spec.

Regards,

	Hans

> 
> 
> Change in v3:
> 1.Refine code to pass v4l2-compliance test, now it still has 2 issues 2.Refine code according to latest MTK IOMMU patches[1] 3.Remove MFC51 specific CIDs and add MTK specific CIDs for for keyframe and
>   skip I-frame
> 4.Refine code according to review comments
> 
> Below is the v1.6 version v4l2-compliance report for the mt8173 encoder driver.
> Now there are still 2 test fail in v1.6.
> For VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF, we directly use v4l2_m2m_ioctl_* functions, but it still fail. It pass in kernel 3.18 but fail in kernel 4.4.
> We will try v1.8 in next version.
> VIDIOC_EXPBUF is becuase we support all three memory types VB2_DMABUF, VB2_MMAP and VB2_USERPTR. VIDIOC_EXPBUF only allowed when only VB2_MMAP supported.
> localhost ~ # /usr/bin/v4l2-compliance -d /dev/video1 Driver Info:
>         Driver name   : mtk-vcodec-en
>         Card type     : platform:mt817
>         Bus info      : platform:mt817
>         Driver version: 4.4.0
>         Capabilities  : 0x84204000
>                 Video Memory-to-Memory Multiplanar
>                 Streaming
>                 Extended Pix Format
>                 Device Capabilities
>         Device Caps   : 0x04204000
>                 Video Memory-to-Memory Multiplanar
>                 Streaming
>                 Extended Pix Format
> 
> Compliance test for device /dev/video1 (not using libv4l2):
> 
> Required ioctls:
>         test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
>         test second video open: OK
>         test VIDIOC_QUERYCAP: OK
>         test VIDIOC_G/S_PRIORITY: OK
> 
> Debug ioctls:
>         test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>         test VIDIOC_LOG_STATUS: OK (Not Supported)
> 
> Input ioctls:
>         test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>         test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>         test VIDIOC_ENUMAUDIO: OK (Not Supported)
>         test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
>         test VIDIOC_G/S_AUDIO: OK (Not Supported)
>         Inputs: 0 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
>         test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>         test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>         test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>         test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>         Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
>         test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>         test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>         test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>         test VIDIOC_G/S_EDID: OK (Not Supported)
> 
>         Control ioctls:
>                 test VIDIOC_QUERYCTRL/MENU: OK
>                 test VIDIOC_G/S_CTRL: OK
>                 test VIDIOC_G/S/TRY_EXT_CTRLS: OK
>                 test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
>                 test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>                 Standard Controls: 11 Private Controls: 2
> 
>         Format ioctls:
>                 test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>                 test VIDIOC_G/S_PARM: OK (Not Supported)
>                 test VIDIOC_G_FBUF: OK (Not Supported)
>                 test VIDIOC_G_FMT: OK
>                 test VIDIOC_TRY_FMT: OK
>                 test VIDIOC_S_FMT: OK
>                 test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> 
>         Codec ioctls:
>                 test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
>                 test VIDIOC_G_ENC_INDEX: OK (Not Supported)
>                 test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> 
>         Buffer ioctls:
>                 fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(266): vp->length == 0
>                 fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(335): buf.check(Unqueued, i)
>                 fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(420): testQueryBuf(node, i, q.g_buffers())
>                 test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
>                 fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(500): q.has_expbuf(node)
>                 test VIDIOC_EXPBUF: FAIL
> Total: 38, Succeeded: 36, Failed: 2, Warnings: 0
> 
> 
> Change in v2:
> Vcodec Part
> 1.Remove common and include directory in mtk-vcodec 2.Refine vb2ops_venc_start_streaming and vb2ops_venc_stop_streaming and state machine 3.Remove venc_if_init and venc_if_deinit 4.Refine debug message 5.Refine lab and vpu decription in mediatek-vcodec.txt
> 
> VPU Part
> 1. Modify VPU Kconfig
> 2. Move encoder header files to other patch sets 3. Remove marcos for extended virtual/iova address 4. Change register and variable names 5. Add a reference counter for VPU watchdog 6. Remove one busy waiting in function vpu_ipi_send 7. Operate VPU clock in VPU driver (not called by encoder drivers) 8. Refine memory mapping, firmware download and extended memory allocation/free functions 9. Release more allocated resources in driver remove function
> 
> 
> 
> Andrew-CT Chen (2):
>   dt-bindings: Add a binding for Mediatek Video Processor
>   [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver
> 
> Tiffany Lin (6):
>   [media] VPU: mediatek: support Mediatek VPU
>   arm64: dts: mediatek: Add node for Mediatek Video Processor Unit
>   dt-bindings: Add a binding for Mediatek Video Encoder
>   [media] vcodec: mediatek: Add Mediatek VP8 Video Encoder Driver
>   [media] vcodec: mediatek: Add Mediatek H264 Video Encoder Driver
>   arm64: dts: mediatek: Add Video Encoder for MT8173
> 
>  .../devicetree/bindings/media/mediatek-vcodec.txt  |   59 +
>  .../devicetree/bindings/media/mediatek-vpu.txt     |   31 +
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi           |   62 +
>  drivers/media/platform/Kconfig                     |   20 +
>  drivers/media/platform/Makefile                    |    4 +
>  drivers/media/platform/mtk-vcodec/Makefile         |   11 +
>  .../media/platform/mtk-vcodec/h264_enc/Makefile    |    6 +
>  .../platform/mtk-vcodec/h264_enc/venc_h264_if.c    |  540 ++++++++
>  .../platform/mtk-vcodec/h264_enc/venc_h264_if.h    |  165 +++
>  .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.c   |  309 +++++
>  .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.h   |   30 +
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |  388 ++++++
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1380 ++++++++++++++++++++
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h |   46 +
>  .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c |  476 +++++++
>  .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c  |  132 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_intr.c    |  102 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_intr.h    |   29 +
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h  |   26 +
>  .../media/platform/mtk-vcodec/mtk_vcodec_util.c    |  106 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_util.h    |   85 ++
>  drivers/media/platform/mtk-vcodec/venc_drv_base.h  |   62 +
>  drivers/media/platform/mtk-vcodec/venc_drv_if.c    |  106 ++
>  drivers/media/platform/mtk-vcodec/venc_drv_if.h    |  175 +++
>  drivers/media/platform/mtk-vcodec/venc_ipi_msg.h   |  212 +++
>  drivers/media/platform/mtk-vcodec/vp8_enc/Makefile |    6 +
>  .../platform/mtk-vcodec/vp8_enc/venc_vp8_if.c      |  422 ++++++
>  .../platform/mtk-vcodec/vp8_enc/venc_vp8_if.h      |  149 +++
>  .../platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c     |  240 ++++
>  .../platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h     |   28 +
>  drivers/media/platform/mtk-vpu/Makefile            |    1 +
>  drivers/media/platform/mtk-vpu/mtk_vpu.c           |  994 ++++++++++++++
>  drivers/media/platform/mtk-vpu/mtk_vpu.h           |  167 +++
>  include/uapi/linux/v4l2-controls.h                 |    4 +
>  34 files changed, 6573 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt
>  create mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt
>  create mode 100644 drivers/media/platform/mtk-vcodec/Makefile
>  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/Makefile
>  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/Makefile
>  create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.h
>  create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c
>  create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h
>  create mode 100644 drivers/media/platform/mtk-vpu/Makefile
>  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c
>  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h
>  mode change 100644 => 100755 include/uapi/linux/v4l2-controls.h
> 



From catalin.marinas at arm.com  Mon Feb 15 04:08:10 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 15 Feb 2016 12:08:10 +0000
Subject: [PATCH] arm64: mark kernel text segment as MEMBLOCK_NOMAP
In-Reply-To: <CAKv+Gu-Y-k_LAbFZJjiPuHq6ssaFCb3WMG_fVGx3ODrvb+hEUQ@mail.gmail.com>
References: <1455528512-32491-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160215114505.GE13683@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-Y-k_LAbFZJjiPuHq6ssaFCb3WMG_fVGx3ODrvb+hEUQ@mail.gmail.com>
Message-ID: <20160215120809.GF13683@e104818-lin.cambridge.arm.com>

On Mon, Feb 15, 2016 at 12:53:59PM +0100, Ard Biesheuvel wrote:
> On 15 February 2016 at 12:45, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > Ard, I'm about to drop the kernel memory map patches from -next. There
> > are several issues like KASAN (which may as well be a KASAN bug but I
> > haven't got to the bottom of it yet), initrd (you have patches but
> > require additional acks).
> >
> > I'll keep your stuff on the for-next/kernmap branch and do further
> > debugging. If it stabilises in the next 1-2 weeks, I'll merge it into
> > for-next/core for 4.6, otherwise, it will have to wait. I would really
> > like these patches merged but it looks like they need wider testing.
[...]
> If you are going to drop it for now anyway, I can do a v6sub1 with
> this issue and the initrd issue addressed, but also an issue with the
> KVM ksym ref patch with GCC 4.8. Since these issues affect
> bisectability, I'd prefer to rebase entirely, and fold all the fixes
> rather than apply them on top.

That's fine. I'll push one more patch to the for-next/pgtable branch,
converting __set_fixmap_offset() back to a macro as it broke other
architectures. Otherwise it is not rebased and I'll merge it into
for-next core.

-- 
Catalin


From jun.nie at linaro.org  Mon Feb 15 04:13:12 2016
From: jun.nie at linaro.org (Jun Nie)
Date: Mon, 15 Feb 2016 20:13:12 +0800
Subject: [PATCH 1/3] serial: amba-pl011: make platform driver generic
Message-ID: <1455538393-7038-1-git-send-email-jun.nie@linaro.org>

make sbsa uart platform driver more generic so that platform
driver code can be reused by ZTE uart platform driver.

Signed-off-by: Jun Nie <jun.nie at linaro.org>
---
 drivers/tty/serial/amba-pl011.c | 57 +++++++++++++++++++++++++++--------------
 1 file changed, 38 insertions(+), 19 deletions(-)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 500232a..f52a243 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -73,6 +73,9 @@
 #define UART_DR_ERROR		(UART011_DR_OE|UART011_DR_BE|UART011_DR_PE|UART011_DR_FE)
 #define UART_DUMMY_DR_RX	(1 << 16)
 
+static const struct uart_ops amba_pl011_pops;
+static const struct uart_ops sbsa_uart_pops;
+
 static u16 pl011_std_offsets[REG_ARRAY_SIZE] = {
 	[REG_DR] = UART01x_DR,
 	[REG_FR] = UART01x_FR,
@@ -92,6 +95,7 @@ static u16 pl011_std_offsets[REG_ARRAY_SIZE] = {
 /* There is by now at least one vendor with differing details, so handle it */
 struct vendor_data {
 	const u16		*reg_offset;
+	const struct uart_ops	*uart_pops;
 	unsigned int		ifls;
 	bool			access_32b;
 	bool			oversampling;
@@ -119,13 +123,20 @@ static struct vendor_data vendor_arm = {
 	.get_fifosize		= get_fifosize_arm,
 };
 
+static unsigned int get_fifosize_sbsa(struct amba_device *dev)
+{
+	return 32;
+}
+
 static struct vendor_data vendor_sbsa = {
 	.reg_offset		= pl011_std_offsets,
+	.uart_pops		= &sbsa_uart_pops,
 	.oversampling		= false,
 	.dma_threshold		= false,
 	.cts_event_workaround	= false,
 	.always_enabled		= true,
 	.fixed_options		= true,
+	.get_fifosize		= get_fifosize_sbsa,
 };
 
 static u16 pl011_st_offsets[REG_ARRAY_SIZE] = {
@@ -189,6 +200,7 @@ static const u16 pl011_zte_offsets[REG_ARRAY_SIZE] = {
 
 static struct vendor_data vendor_zte __maybe_unused = {
 	.reg_offset		= pl011_zte_offsets,
+	.uart_pops		= &amba_pl011_pops,
 	.access_32b		= true,
 	.ifls			= UART011_IFLS_RX4_8|UART011_IFLS_TX4_8,
 	.get_fifosize		= get_fifosize_arm,
@@ -2084,7 +2096,7 @@ static int pl011_verify_port(struct uart_port *port, struct serial_struct *ser)
 	return ret;
 }
 
-static struct uart_ops amba_pl011_pops = {
+static const struct uart_ops amba_pl011_pops = {
 	.tx_empty	= pl011_tx_empty,
 	.set_mctrl	= pl011_set_mctrl,
 	.get_mctrl	= pl011_get_mctrl,
@@ -2519,10 +2531,12 @@ static int pl011_resume(struct device *dev)
 #endif
 
 static SIMPLE_DEV_PM_OPS(pl011_dev_pm_ops, pl011_suspend, pl011_resume);
+static const struct of_device_id pl011_uart_plat_of_match[];
 
-static int sbsa_uart_probe(struct platform_device *pdev)
+static int pl011_uart_plat_probe(struct platform_device *pdev)
 {
 	struct uart_amba_port *uap;
+	struct vendor_data *vendor;
 	struct resource *r;
 	int portnr, ret;
 	int baudrate;
@@ -2533,11 +2547,15 @@ static int sbsa_uart_probe(struct platform_device *pdev)
 	 */
 	if (pdev->dev.of_node) {
 		struct device_node *np = pdev->dev.of_node;
+		const struct of_device_id *of_id =
+			of_match_device(pl011_uart_plat_of_match, &pdev->dev);
 
 		ret = of_property_read_u32(np, "current-speed", &baudrate);
 		if (ret)
 			return ret;
+		vendor = (struct vendor_data *)of_id->data;
 	} else {
+		vendor = &vendor_sbsa;
 		baudrate = 115200;
 	}
 
@@ -2550,15 +2568,15 @@ static int sbsa_uart_probe(struct platform_device *pdev)
 	if (!uap)
 		return -ENOMEM;
 
-	uap->reg_offset	= vendor_sbsa.reg_offset;
-	uap->vendor	= &vendor_sbsa;
-	uap->fifosize	= 32;
-	uap->port.iotype = vendor_sbsa.access_32b ? UPIO_MEM32 : UPIO_MEM;
+	uap->vendor	= vendor;
+	uap->reg_offset	= vendor->reg_offset;
+	uap->fifosize	= vendor->get_fifosize(NULL);
+	uap->port.iotype = vendor->access_32b ? UPIO_MEM32 : UPIO_MEM;
 	uap->port.irq	= platform_get_irq(pdev, 0);
-	uap->port.ops	= &sbsa_uart_pops;
+	uap->port.ops	= vendor->uart_pops;
 	uap->fixed_baud = baudrate;
 
-	snprintf(uap->type, sizeof(uap->type), "SBSA");
+	snprintf(uap->type, sizeof(uap->type), "PL011 plat");
 
 	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 
@@ -2571,7 +2589,7 @@ static int sbsa_uart_probe(struct platform_device *pdev)
 	return pl011_register_port(uap);
 }
 
-static int sbsa_uart_remove(struct platform_device *pdev)
+static int pl011_uart_plat_remove(struct platform_device *pdev)
 {
 	struct uart_amba_port *uap = platform_get_drvdata(pdev);
 
@@ -2580,11 +2598,12 @@ static int sbsa_uart_remove(struct platform_device *pdev)
 	return 0;
 }
 
-static const struct of_device_id sbsa_uart_of_match[] = {
-	{ .compatible = "arm,sbsa-uart", },
+static const struct of_device_id pl011_uart_plat_of_match[] = {
+	{ .compatible = "arm,sbsa-uart", .data = &vendor_sbsa },
+	{ .compatible = "zte,zx296702-uart", .data = &vendor_zte },
 	{},
 };
-MODULE_DEVICE_TABLE(of, sbsa_uart_of_match);
+MODULE_DEVICE_TABLE(of, pl011_uart_plat_of_match);
 
 static const struct acpi_device_id sbsa_uart_acpi_match[] = {
 	{ "ARMH0011", 0 },
@@ -2592,12 +2611,12 @@ static const struct acpi_device_id sbsa_uart_acpi_match[] = {
 };
 MODULE_DEVICE_TABLE(acpi, sbsa_uart_acpi_match);
 
-static struct platform_driver arm_sbsa_uart_platform_driver = {
-	.probe		= sbsa_uart_probe,
-	.remove		= sbsa_uart_remove,
+static struct platform_driver pl011_uart_platform_driver = {
+	.probe		= pl011_uart_plat_probe,
+	.remove		= pl011_uart_plat_remove,
 	.driver	= {
-		.name	= "sbsa-uart",
-		.of_match_table = of_match_ptr(sbsa_uart_of_match),
+		.name	= "uart-pl011-plat",
+		.of_match_table = of_match_ptr(pl011_uart_plat_of_match),
 		.acpi_match_table = ACPI_PTR(sbsa_uart_acpi_match),
 	},
 };
@@ -2632,14 +2651,14 @@ static int __init pl011_init(void)
 {
 	printk(KERN_INFO "Serial: AMBA PL011 UART driver\n");
 
-	if (platform_driver_register(&arm_sbsa_uart_platform_driver))
+	if (platform_driver_register(&pl011_uart_platform_driver))
 		pr_warn("could not register SBSA UART platform driver\n");
 	return amba_driver_register(&pl011_driver);
 }
 
 static void __exit pl011_exit(void)
 {
-	platform_driver_unregister(&arm_sbsa_uart_platform_driver);
+	platform_driver_unregister(&pl011_uart_platform_driver);
 	amba_driver_unregister(&pl011_driver);
 }
 
-- 
1.9.1



From jun.nie at linaro.org  Mon Feb 15 04:13:13 2016
From: jun.nie at linaro.org (Jun Nie)
Date: Mon, 15 Feb 2016 20:13:13 +0800
Subject: [PATCH 2/3]  serial: amba-pl011: complete support to ZTE uart
In-Reply-To: <1455538393-7038-1-git-send-email-jun.nie@linaro.org>
References: <1455538393-7038-1-git-send-email-jun.nie@linaro.org>
Message-ID: <1455538393-7038-2-git-send-email-jun.nie@linaro.org>

Complete support to ZTE uart with adding specific registers
mask.

Signed-off-by: Jun Nie <jun.nie at linaro.org>
---
 drivers/tty/serial/amba-pl011.c | 70 ++++++++++++++++++++++++++++++++++-------
 include/linux/amba/serial.h     |  4 +++
 2 files changed, 62 insertions(+), 12 deletions(-)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index f52a243..72ae785 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -97,6 +97,10 @@ struct vendor_data {
 	const u16		*reg_offset;
 	const struct uart_ops	*uart_pops;
 	unsigned int		ifls;
+	unsigned int		fr_busy;
+	unsigned int		fr_dsr;
+	unsigned int		fr_cts;
+	unsigned int		fr_ri;
 	bool			access_32b;
 	bool			oversampling;
 	bool			dma_threshold;
@@ -115,6 +119,10 @@ static unsigned int get_fifosize_arm(struct amba_device *dev)
 static struct vendor_data vendor_arm = {
 	.reg_offset		= pl011_std_offsets,
 	.ifls			= UART011_IFLS_RX4_8|UART011_IFLS_TX4_8,
+	.fr_busy		= UART01x_FR_BUSY,
+	.fr_dsr			= UART01x_FR_DSR,
+	.fr_cts			= UART01x_FR_CTS,
+	.fr_ri			= UART011_FR_RI,
 	.oversampling		= false,
 	.dma_threshold		= false,
 	.cts_event_workaround	= false,
@@ -130,6 +138,10 @@ static unsigned int get_fifosize_sbsa(struct amba_device *dev)
 
 static struct vendor_data vendor_sbsa = {
 	.reg_offset		= pl011_std_offsets,
+	.fr_busy		= UART01x_FR_BUSY,
+	.fr_dsr			= UART01x_FR_DSR,
+	.fr_cts			= UART01x_FR_CTS,
+	.fr_ri			= UART011_FR_RI,
 	.uart_pops		= &sbsa_uart_pops,
 	.oversampling		= false,
 	.dma_threshold		= false,
@@ -174,6 +186,10 @@ static unsigned int get_fifosize_st(struct amba_device *dev)
 static struct vendor_data vendor_st = {
 	.reg_offset		= pl011_st_offsets,
 	.ifls			= UART011_IFLS_RX_HALF|UART011_IFLS_TX_HALF,
+	.fr_busy		= UART01x_FR_BUSY,
+	.fr_dsr			= UART01x_FR_DSR,
+	.fr_cts			= UART01x_FR_CTS,
+	.fr_ri			= UART011_FR_RI,
 	.oversampling		= true,
 	.dma_threshold		= true,
 	.cts_event_workaround	= true,
@@ -198,12 +214,26 @@ static const u16 pl011_zte_offsets[REG_ARRAY_SIZE] = {
 	[REG_DMACR] = ZX_UART011_DMACR,
 };
 
+static unsigned int get_fifosize_zte(struct amba_device *dev)
+{
+	return 16;
+}
+
 static struct vendor_data vendor_zte __maybe_unused = {
 	.reg_offset		= pl011_zte_offsets,
 	.uart_pops		= &amba_pl011_pops,
 	.access_32b		= true,
 	.ifls			= UART011_IFLS_RX4_8|UART011_IFLS_TX4_8,
-	.get_fifosize		= get_fifosize_arm,
+	.fr_busy		= ZX_UART01x_FR_BUSY,
+	.fr_dsr			= ZX_UART01x_FR_DSR,
+	.fr_cts			= ZX_UART01x_FR_CTS,
+	.fr_ri			= ZX_UART011_FR_RI,
+	.oversampling		= false,
+	.dma_threshold		= false,
+	.cts_event_workaround	= false,
+	.always_enabled		= false,
+	.fixed_options		= false,
+	.get_fifosize		= get_fifosize_zte,
 };
 
 /* Deals with DMA transactions */
@@ -248,6 +278,10 @@ struct uart_amba_port {
 	unsigned int		im;		/* interrupt mask */
 	unsigned int		old_status;
 	unsigned int		fifosize;	/* vendor-specific */
+	unsigned int		fr_busy;        /* vendor-specific */
+	unsigned int		fr_dsr;		/* vendor-specific */
+	unsigned int		fr_cts;         /* vendor-specific */
+	unsigned int		fr_ri;		/* vendor-specific */
 	unsigned int		old_cr;		/* state during shutdown */
 	bool			autorts;
 	unsigned int		fixed_baud;	/* vendor-set fixed baud rate */
@@ -1178,7 +1212,7 @@ static void pl011_dma_shutdown(struct uart_amba_port *uap)
 		return;
 
 	/* Disable RX and TX DMA */
-	while (pl011_read(uap, REG_FR) & UART01x_FR_BUSY)
+	while (pl011_read(uap, REG_FR) & uap->fr_busy)
 		cpu_relax();
 
 	spin_lock_irq(&uap->port.lock);
@@ -1427,11 +1461,11 @@ static void pl011_modem_status(struct uart_amba_port *uap)
 	if (delta & UART01x_FR_DCD)
 		uart_handle_dcd_change(&uap->port, status & UART01x_FR_DCD);
 
-	if (delta & UART01x_FR_DSR)
+	if (delta & uap->fr_dsr)
 		uap->port.icount.dsr++;
 
-	if (delta & UART01x_FR_CTS)
-		uart_handle_cts_change(&uap->port, status & UART01x_FR_CTS);
+	if (delta & uap->fr_cts)
+		uart_handle_cts_change(&uap->port, status & uap->fr_cts);
 
 	wake_up_interruptible(&uap->port.state->port.delta_msr_wait);
 }
@@ -1504,7 +1538,7 @@ static unsigned int pl011_tx_empty(struct uart_port *port)
 	struct uart_amba_port *uap =
 	    container_of(port, struct uart_amba_port, port);
 	unsigned int status = pl011_read(uap, REG_FR);
-	return status & (UART01x_FR_BUSY|UART01x_FR_TXFF) ? 0 : TIOCSER_TEMT;
+	return status & (uap->fr_busy | UART01x_FR_TXFF) ? 0 : TIOCSER_TEMT;
 }
 
 static unsigned int pl011_get_mctrl(struct uart_port *port)
@@ -1519,9 +1553,9 @@ static unsigned int pl011_get_mctrl(struct uart_port *port)
 		result |= tiocmbit
 
 	TIOCMBIT(UART01x_FR_DCD, TIOCM_CAR);
-	TIOCMBIT(UART01x_FR_DSR, TIOCM_DSR);
-	TIOCMBIT(UART01x_FR_CTS, TIOCM_CTS);
-	TIOCMBIT(UART011_FR_RI, TIOCM_RNG);
+	TIOCMBIT(uap->fr_dsr, TIOCM_DSR);
+	TIOCMBIT(uap->fr_cts, TIOCM_CTS);
+	TIOCMBIT(uap->fr_ri, TIOCM_RNG);
 #undef TIOCMBIT
 	return result;
 }
@@ -2200,7 +2234,7 @@ pl011_console_write(struct console *co, const char *s, unsigned int count)
 	 *	Finally, wait for transmitter to become empty
 	 *	and restore the TCR
 	 */
-	while (pl011_read(uap, REG_FR) & UART01x_FR_BUSY)
+	while (pl011_read(uap, REG_FR) & uap->fr_busy)
 		cpu_relax();
 	if (!uap->vendor->always_enabled)
 		pl011_write(old_cr, uap, REG_CR);
@@ -2482,8 +2516,12 @@ static int pl011_probe(struct amba_device *dev, const struct amba_id *id)
 		return PTR_ERR(uap->clk);
 
 	uap->reg_offset = vendor->reg_offset;
-	uap->vendor = vendor;
-	uap->fifosize = vendor->get_fifosize(dev);
+	uap->vendor	= vendor;
+	uap->fifosize	= vendor->get_fifosize(dev);
+	uap->fr_busy	= vendor->fr_busy;
+	uap->fr_dsr	= vendor->fr_dsr;
+	uap->fr_cts	= vendor->fr_cts;
+	uap->fr_ri	= vendor->fr_ri;
 	uap->port.iotype = vendor->access_32b ? UPIO_MEM32 : UPIO_MEM;
 	uap->port.irq = dev->irq[0];
 	uap->port.ops = &amba_pl011_pops;
@@ -2568,9 +2606,17 @@ static int pl011_uart_plat_probe(struct platform_device *pdev)
 	if (!uap)
 		return -ENOMEM;
 
+	uap->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(uap->clk))
+		return PTR_ERR(uap->clk);
+
 	uap->vendor	= vendor;
 	uap->reg_offset	= vendor->reg_offset;
 	uap->fifosize	= vendor->get_fifosize(NULL);
+	uap->fr_busy	= vendor_sbsa.fr_busy;
+	uap->fr_dsr	= vendor_sbsa.fr_dsr;
+	uap->fr_cts	= vendor_sbsa.fr_cts;
+	uap->fr_ri	= vendor_sbsa.fr_ri;
 	uap->port.iotype = vendor->access_32b ? UPIO_MEM32 : UPIO_MEM;
 	uap->port.irq	= platform_get_irq(pdev, 0);
 	uap->port.ops	= vendor->uart_pops;
diff --git a/include/linux/amba/serial.h b/include/linux/amba/serial.h
index d76a19b..750f2ef 100644
--- a/include/linux/amba/serial.h
+++ b/include/linux/amba/serial.h
@@ -103,6 +103,10 @@
 #define UART01x_FR_DSR 		0x002
 #define UART01x_FR_CTS 		0x001
 #define UART01x_FR_TMSK		(UART01x_FR_TXFF + UART01x_FR_BUSY)
+#define ZX_UART01x_FR_BUSY	0x300
+#define ZX_UART01x_FR_DSR	0x008
+#define ZX_UART01x_FR_CTS	0x002
+#define ZX_UART011_FR_RI	0x001
 
 #define UART011_CR_CTSEN	0x8000	/* CTS hardware flow control */
 #define UART011_CR_RTSEN	0x4000	/* RTS hardware flow control */
-- 
1.9.1



From jun.nie at linaro.org  Mon Feb 15 04:18:32 2016
From: jun.nie at linaro.org (Jun Nie)
Date: Mon, 15 Feb 2016 20:18:32 +0800
Subject: [PATCH 1/3] serial: amba-pl011: make platform driver generic
In-Reply-To: <1455538393-7038-1-git-send-email-jun.nie@linaro.org>
References: <1455538393-7038-1-git-send-email-jun.nie@linaro.org>
Message-ID: <56C1C218.3050106@linaro.org>

There are only two patches for this PL011 UART changes actually. The 
third is for platform config and shall not be posted here. Sorry for 
misleading you by email title.

Jun
> make sbsa uart platform driver more generic so that platform
> driver code can be reused by ZTE uart platform driver.
>
> Signed-off-by: Jun Nie <jun.nie at linaro.org>
> ---
>   drivers/tty/serial/amba-pl011.c | 57 +++++++++++++++++++++++++++--------------
>   1 file changed, 38 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 500232a..f52a243 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -73,6 +73,9 @@
>   #define UART_DR_ERROR		(UART011_DR_OE|UART011_DR_BE|UART011_DR_PE|UART011_DR_FE)
>   #define UART_DUMMY_DR_RX	(1 << 16)
>
> +static const struct uart_ops amba_pl011_pops;
> +static const struct uart_ops sbsa_uart_pops;
> +
>   static u16 pl011_std_offsets[REG_ARRAY_SIZE] = {
>   	[REG_DR] = UART01x_DR,
>   	[REG_FR] = UART01x_FR,
> @@ -92,6 +95,7 @@ static u16 pl011_std_offsets[REG_ARRAY_SIZE] = {
>   /* There is by now at least one vendor with differing details, so handle it */
>   struct vendor_data {
>   	const u16		*reg_offset;
> +	const struct uart_ops	*uart_pops;
>   	unsigned int		ifls;
>   	bool			access_32b;
>   	bool			oversampling;
> @@ -119,13 +123,20 @@ static struct vendor_data vendor_arm = {
>   	.get_fifosize		= get_fifosize_arm,
>   };
>
> +static unsigned int get_fifosize_sbsa(struct amba_device *dev)
> +{
> +	return 32;
> +}
> +
>   static struct vendor_data vendor_sbsa = {
>   	.reg_offset		= pl011_std_offsets,
> +	.uart_pops		= &sbsa_uart_pops,
>   	.oversampling		= false,
>   	.dma_threshold		= false,
>   	.cts_event_workaround	= false,
>   	.always_enabled		= true,
>   	.fixed_options		= true,
> +	.get_fifosize		= get_fifosize_sbsa,
>   };
>
>   static u16 pl011_st_offsets[REG_ARRAY_SIZE] = {
> @@ -189,6 +200,7 @@ static const u16 pl011_zte_offsets[REG_ARRAY_SIZE] = {
>
>   static struct vendor_data vendor_zte __maybe_unused = {
>   	.reg_offset		= pl011_zte_offsets,
> +	.uart_pops		= &amba_pl011_pops,
>   	.access_32b		= true,
>   	.ifls			= UART011_IFLS_RX4_8|UART011_IFLS_TX4_8,
>   	.get_fifosize		= get_fifosize_arm,
> @@ -2084,7 +2096,7 @@ static int pl011_verify_port(struct uart_port *port, struct serial_struct *ser)
>   	return ret;
>   }
>
> -static struct uart_ops amba_pl011_pops = {
> +static const struct uart_ops amba_pl011_pops = {
>   	.tx_empty	= pl011_tx_empty,
>   	.set_mctrl	= pl011_set_mctrl,
>   	.get_mctrl	= pl011_get_mctrl,
> @@ -2519,10 +2531,12 @@ static int pl011_resume(struct device *dev)
>   #endif
>
>   static SIMPLE_DEV_PM_OPS(pl011_dev_pm_ops, pl011_suspend, pl011_resume);
> +static const struct of_device_id pl011_uart_plat_of_match[];
>
> -static int sbsa_uart_probe(struct platform_device *pdev)
> +static int pl011_uart_plat_probe(struct platform_device *pdev)
>   {
>   	struct uart_amba_port *uap;
> +	struct vendor_data *vendor;
>   	struct resource *r;
>   	int portnr, ret;
>   	int baudrate;
> @@ -2533,11 +2547,15 @@ static int sbsa_uart_probe(struct platform_device *pdev)
>   	 */
>   	if (pdev->dev.of_node) {
>   		struct device_node *np = pdev->dev.of_node;
> +		const struct of_device_id *of_id =
> +			of_match_device(pl011_uart_plat_of_match, &pdev->dev);
>
>   		ret = of_property_read_u32(np, "current-speed", &baudrate);
>   		if (ret)
>   			return ret;
> +		vendor = (struct vendor_data *)of_id->data;
>   	} else {
> +		vendor = &vendor_sbsa;
>   		baudrate = 115200;
>   	}
>
> @@ -2550,15 +2568,15 @@ static int sbsa_uart_probe(struct platform_device *pdev)
>   	if (!uap)
>   		return -ENOMEM;
>
> -	uap->reg_offset	= vendor_sbsa.reg_offset;
> -	uap->vendor	= &vendor_sbsa;
> -	uap->fifosize	= 32;
> -	uap->port.iotype = vendor_sbsa.access_32b ? UPIO_MEM32 : UPIO_MEM;
> +	uap->vendor	= vendor;
> +	uap->reg_offset	= vendor->reg_offset;
> +	uap->fifosize	= vendor->get_fifosize(NULL);
> +	uap->port.iotype = vendor->access_32b ? UPIO_MEM32 : UPIO_MEM;
>   	uap->port.irq	= platform_get_irq(pdev, 0);
> -	uap->port.ops	= &sbsa_uart_pops;
> +	uap->port.ops	= vendor->uart_pops;
>   	uap->fixed_baud = baudrate;
>
> -	snprintf(uap->type, sizeof(uap->type), "SBSA");
> +	snprintf(uap->type, sizeof(uap->type), "PL011 plat");
>
>   	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>
> @@ -2571,7 +2589,7 @@ static int sbsa_uart_probe(struct platform_device *pdev)
>   	return pl011_register_port(uap);
>   }
>
> -static int sbsa_uart_remove(struct platform_device *pdev)
> +static int pl011_uart_plat_remove(struct platform_device *pdev)
>   {
>   	struct uart_amba_port *uap = platform_get_drvdata(pdev);
>
> @@ -2580,11 +2598,12 @@ static int sbsa_uart_remove(struct platform_device *pdev)
>   	return 0;
>   }
>
> -static const struct of_device_id sbsa_uart_of_match[] = {
> -	{ .compatible = "arm,sbsa-uart", },
> +static const struct of_device_id pl011_uart_plat_of_match[] = {
> +	{ .compatible = "arm,sbsa-uart", .data = &vendor_sbsa },
> +	{ .compatible = "zte,zx296702-uart", .data = &vendor_zte },
>   	{},
>   };
> -MODULE_DEVICE_TABLE(of, sbsa_uart_of_match);
> +MODULE_DEVICE_TABLE(of, pl011_uart_plat_of_match);
>
>   static const struct acpi_device_id sbsa_uart_acpi_match[] = {
>   	{ "ARMH0011", 0 },
> @@ -2592,12 +2611,12 @@ static const struct acpi_device_id sbsa_uart_acpi_match[] = {
>   };
>   MODULE_DEVICE_TABLE(acpi, sbsa_uart_acpi_match);
>
> -static struct platform_driver arm_sbsa_uart_platform_driver = {
> -	.probe		= sbsa_uart_probe,
> -	.remove		= sbsa_uart_remove,
> +static struct platform_driver pl011_uart_platform_driver = {
> +	.probe		= pl011_uart_plat_probe,
> +	.remove		= pl011_uart_plat_remove,
>   	.driver	= {
> -		.name	= "sbsa-uart",
> -		.of_match_table = of_match_ptr(sbsa_uart_of_match),
> +		.name	= "uart-pl011-plat",
> +		.of_match_table = of_match_ptr(pl011_uart_plat_of_match),
>   		.acpi_match_table = ACPI_PTR(sbsa_uart_acpi_match),
>   	},
>   };
> @@ -2632,14 +2651,14 @@ static int __init pl011_init(void)
>   {
>   	printk(KERN_INFO "Serial: AMBA PL011 UART driver\n");
>
> -	if (platform_driver_register(&arm_sbsa_uart_platform_driver))
> +	if (platform_driver_register(&pl011_uart_platform_driver))
>   		pr_warn("could not register SBSA UART platform driver\n");
>   	return amba_driver_register(&pl011_driver);
>   }
>
>   static void __exit pl011_exit(void)
>   {
> -	platform_driver_unregister(&arm_sbsa_uart_platform_driver);
> +	platform_driver_unregister(&pl011_uart_platform_driver);
>   	amba_driver_unregister(&pl011_driver);
>   }
>
>



From geert+renesas at glider.be  Mon Feb 15 04:20:08 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 13:20:08 +0100
Subject: [PATCH v3 2/2] ARM: shmobile: Remove shmobile_boot_arg
In-Reply-To: <1455538808-6816-1-git-send-email-geert+renesas@glider.be>
References: <1455538808-6816-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455538808-6816-3-git-send-email-geert+renesas@glider.be>

CPU boot configuration writes to shmobile_boot_arg, which is located in
the .text section, and thus should not be written to.

As of commit 1d33a354bbb618ba ("ARM: shmobile: Per-CPU SMP boot / sleep
code for SCU SoCs"), and ignoring accidental remainings,
shmobile_boot_arg is always set to MPIDR_HWID_BITMASK by C code.
Hence we can just hardcode this in the assembler code, and remove the
variable, and thus also remove the need to write to this variable.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Acked-by: Nicolas Pitre <nico at linaro.org>
---
v3:
  - Add Acked-by,

v2:
  - New.
---
 arch/arm/mach-shmobile/common.h       | 1 -
 arch/arm/mach-shmobile/headsmp.S      | 8 ++------
 arch/arm/mach-shmobile/platsmp-apmu.c | 1 -
 arch/arm/mach-shmobile/platsmp-scu.c  | 1 -
 4 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/common.h b/arch/arm/mach-shmobile/common.h
index 225c12bb3de91e76..5464b7a75e3028a7 100644
--- a/arch/arm/mach-shmobile/common.h
+++ b/arch/arm/mach-shmobile/common.h
@@ -4,7 +4,6 @@
 extern void shmobile_init_delay(void);
 extern void shmobile_boot_vector(void);
 extern unsigned long shmobile_boot_fn;
-extern unsigned long shmobile_boot_arg;
 extern unsigned long shmobile_boot_size;
 extern void shmobile_smp_boot(void);
 extern void shmobile_smp_sleep(void);
diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index 94d86ed164144cdf..32e0bf6e3ccb9bd3 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -24,7 +24,6 @@
 	.arm
 	.align  12
 ENTRY(shmobile_boot_vector)
-	ldr     r0, 2f
 	ldr     r1, 1f
 	bx	r1
 
@@ -34,9 +33,6 @@ ENDPROC(shmobile_boot_vector)
 	.globl	shmobile_boot_fn
 shmobile_boot_fn:
 1:	.space	4
-	.globl	shmobile_boot_arg
-shmobile_boot_arg:
-2:	.space	4
 	.globl	shmobile_boot_size
 shmobile_boot_size:
 	.long	. - shmobile_boot_vector
@@ -46,9 +42,9 @@ shmobile_boot_size:
  */
 
 ENTRY(shmobile_smp_boot)
-						@ r0 = MPIDR_HWID_BITMASK
 	mrc	p15, 0, r1, c0, c0, 5		@ r1 = MPIDR
-	and	r0, r1, r0			@ r0 = cpu_logical_map() value
+	and	r0, r1, #0xffffff		@ MPIDR_HWID_BITMASK
+						@ r0 = cpu_logical_map() value
 	mov	r1, #0				@ r1 = CPU index
 	adr	r2, 1f
 	ldmia	r2, {r5, r6, r7}
diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c b/arch/arm/mach-shmobile/platsmp-apmu.c
index 911884f7e28b174c..aba75c89f9c1c5eb 100644
--- a/arch/arm/mach-shmobile/platsmp-apmu.c
+++ b/arch/arm/mach-shmobile/platsmp-apmu.c
@@ -123,7 +123,6 @@ void __init shmobile_smp_apmu_prepare_cpus(unsigned int max_cpus,
 {
 	/* install boot code shared by all CPUs */
 	shmobile_boot_fn = virt_to_phys(shmobile_smp_boot);
-	shmobile_boot_arg = MPIDR_HWID_BITMASK;
 
 	/* perform per-cpu setup */
 	apmu_parse_cfg(apmu_init_cpu, apmu_config, num);
diff --git a/arch/arm/mach-shmobile/platsmp-scu.c b/arch/arm/mach-shmobile/platsmp-scu.c
index 4c7d2caf3730f644..8d478f1da265d55e 100644
--- a/arch/arm/mach-shmobile/platsmp-scu.c
+++ b/arch/arm/mach-shmobile/platsmp-scu.c
@@ -46,7 +46,6 @@ void __init shmobile_smp_scu_prepare_cpus(phys_addr_t scu_base_phys,
 {
 	/* install boot code shared by all CPUs */
 	shmobile_boot_fn = virt_to_phys(shmobile_smp_boot);
-	shmobile_boot_arg = MPIDR_HWID_BITMASK;
 
 	/* enable SCU and cache coherency on booting CPU */
 	shmobile_scu_base_phys = scu_base_phys;
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 04:20:06 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 13:20:06 +0100
Subject: [PATCH v3 0/2] ARM: shmobile: Avoid writing to .text
Message-ID: <1455538808-6816-1-git-send-email-geert+renesas@glider.be>

        Hi Simon, Magnus,

When CONFIG_DEBUG_RODATA=y, the kernel crashes during system suspend:

    Freezing user space processes ... (elapsed 0.004 seconds) done.
    Freezing remaining freezable tasks ... (elapsed 0.002 seconds)
    done.
    PM: suspend of devices complete after 111.948 msecs
    PM: late suspend of devices complete after 1.086 msecs
    PM: noirq suspend of devices complete after 11.576 msecs
    Disabling non-boot CPUs ...
    Kernel panic - not syncing: Attempted to kill the idle task!
    1014ec ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
    CPU0: stopping

This happens because the shmobile assembler sources have several
variables that are written to in the .text section, while .text is
mapped read-only after kernel bootup if CONFIG_DEBUG_RODATA=y.

This series fixes this by moving variables from .text to .bss, or just
removing them.
Note that there's still an issue with shmobile_boot_fn in
arch/arm/mach-shmobile/headsmp.S.  So far I didn't manage to fix this
(the code and data are copied to SRAM on some SoCs).  However, currently
this is mostly harmless, as this is written to during early kernel boot
up only, before .text is marked read-only. It does matter for XIP
(anyone using that with SMP?), so we do want to fix that in the long
run, too.

These issues were uncovered by "[PATCH v2] ARM: mm: flip priority of
CONFIG_DEBUG_RODATA". As that patch is already queued in arm/for-next, I
think all these fixes should be queued for v4.5, to avoid a dependency
with the arm tree.

Changes compared to v2:
  - Use .bss instead of .data, as requested by Nicolas Pitre
    <nicolas.pitre at linaro.org>,
  - Added Acked-by and Reviewed-by.

Changes compared to v1:
  - Dropped "ARM: shmobile: Move shmobile_scu_base from .text to .data",
    which Simon has applied, and queued in soc-for-v4.6 (should be
    soc-for-v4.5?),
  - Added Reviewed-by,
  - Store offsets instead of pointers, as suggested by Nicolas Pitre
    <nicolas.pitre at linaro.org>,
  - Added "ARM: shmobile: Remove shmobile_boot_arg".

Tested hard on sh73a0/kzm9g, r8a7791/koelsch.
Tested lighter on emev2/kzm9d[*], r8a73a4/ape6evm, r8a7740/armadillo, and
r8a7779/marzen[*] ([*] = no remote resume).

Thanks!


Geert Uytterhoeven (2):
  ARM: shmobile: Move shmobile_smp_{mpidr,fn,arg}[] from .text to .bss
  ARM: shmobile: Remove shmobile_boot_arg

 arch/arm/mach-shmobile/common.h       |  1 -
 arch/arm/mach-shmobile/headsmp.S      | 28 ++++++++++++++++------------
 arch/arm/mach-shmobile/platsmp-apmu.c |  1 -
 arch/arm/mach-shmobile/platsmp-scu.c  |  1 -
 4 files changed, 16 insertions(+), 15 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From geert+renesas at glider.be  Mon Feb 15 04:20:07 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 13:20:07 +0100
Subject: [PATCH v3 1/2] ARM: shmobile: Move shmobile_smp_{mpidr, fn,
 arg}[] from .text to .bss
In-Reply-To: <1455538808-6816-1-git-send-email-geert+renesas@glider.be>
References: <1455538808-6816-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455538808-6816-2-git-send-email-geert+renesas@glider.be>

If CONFIG_DEBUG_RODATA=y, the kernel crashes during system suspend:

    Freezing user space processes ... (elapsed 0.004 seconds) done.
    Freezing remaining freezable tasks ... (elapsed 0.002 seconds)
    done.
    PM: suspend of devices complete after 111.948 msecs
    PM: late suspend of devices complete after 1.086 msecs
    PM: noirq suspend of devices complete after 11.576 msecs
    Disabling non-boot CPUs ...
    Kernel panic - not syncing: Attempted to kill the idle task!
    1014ec ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
    CPU0: stopping

This happens because the .text section is marked read-only, while the
arrays shmobile_smp_mpidr[], shmobile_smp_fn[], and shmobile_smp_arg[]
are being written to.

Fix this by moving these arrays from the .text to the .bss section.
This requires accessing them through PC-relative offsets.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Reviewed-by: Kees Cook <keescook at chromium.org>
Reviewed-by: Nicolas Pitre <nico at linaro.org>
---
v3:
  - Use .bss instead of .data, as requested by Nicolas Pitre
    <nicolas.pitre at linaro.org>,
  - Add Reviewed-by,

v2:
  - Add Reviewed-by,
  - Store offsets instead of pointers, as suggested by Nicolas Pitre
    <nicolas.pitre at linaro.org>.
---
 arch/arm/mach-shmobile/headsmp.S | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index 330c1fc63197df89..94d86ed164144cdf 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -50,9 +50,11 @@ ENTRY(shmobile_smp_boot)
 	mrc	p15, 0, r1, c0, c0, 5		@ r1 = MPIDR
 	and	r0, r1, r0			@ r0 = cpu_logical_map() value
 	mov	r1, #0				@ r1 = CPU index
-	adr	r5, 1f				@ array of per-cpu mpidr values
-	adr	r6, 2f				@ array of per-cpu functions
-	adr	r7, 3f				@ array of per-cpu arguments
+	adr	r2, 1f
+	ldmia	r2, {r5, r6, r7}
+	add	r5, r5, r2			@ array of per-cpu mpidr values
+	add	r6, r6, r2			@ array of per-cpu functions
+	add	r7, r7, r2			@ array of per-cpu arguments
 
 shmobile_smp_boot_find_mpidr:
 	ldr	r8, [r5, r1, lsl #2]
@@ -80,12 +82,18 @@ ENTRY(shmobile_smp_sleep)
 	b	shmobile_smp_boot
 ENDPROC(shmobile_smp_sleep)
 
+	.align	2
+1:	.long	shmobile_smp_mpidr - .
+	.long	shmobile_smp_fn - 1b
+	.long	shmobile_smp_arg - 1b
+
+	.bss
 	.globl	shmobile_smp_mpidr
 shmobile_smp_mpidr:
-1:	.space	NR_CPUS * 4
+	.space	NR_CPUS * 4
 	.globl	shmobile_smp_fn
 shmobile_smp_fn:
-2:	.space	NR_CPUS * 4
+	.space	NR_CPUS * 4
 	.globl	shmobile_smp_arg
 shmobile_smp_arg:
-3:	.space	NR_CPUS * 4
+	.space	NR_CPUS * 4
-- 
1.9.1



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 04:29:00 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 12:29:00 +0000
Subject: [PATCH 01/17] drm/virtio: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <20160214182508.GF11240@phenom.ffwll.local>
References: <daniel.vetter@ffwll.ch,>
 <1455285069-2819-1-git-send-email-palminha@synopsys.com>
 <1455285069-2819-2-git-send-email-palminha@synopsys.com>
 <20160214182508.GF11240@phenom.ffwll.local>
Message-ID: <56C1C48C.1050006@synopsys.com>

Daniel, thanks for the feedback.
v2 patch will follow-up. :)

On 14-02-2016 18:25, Daniel Vetter wrote:
> On Fri, Feb 12, 2016 at 01:50:53PM +0000, Carlos Palminha wrote:
>
> Sob-line from you is missing on all patches, I can't merge them. Also
> please copypaste a default blurb to all patches that this is only recently
> no longer needed. And dunno what happened to your patch series, the
> threading is somehow broken. In case your mail server doesn't accept a big
> patch series you can first format .patch files using git format-patch with
> threading enabled (should be the default) and then send them out in
> chunks.
>
> When resending please also add the r-b tag from Alex for amdgpu/radoen.
>
> Thanks, Daniel
>
>> ---
>>   drivers/gpu/drm/virtio/virtgpu_display.c | 8 --------
>>   1 file changed, 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
>> index a165f03..429aa31 100644
>> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
>> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
>> @@ -282,13 +282,6 @@ static const struct drm_crtc_helper_funcs virtio_gpu_crtc_helper_funcs = {
>>   	.atomic_check  = virtio_gpu_crtc_atomic_check,
>>   };
>>
>> -static bool virtio_gpu_enc_mode_fixup(struct drm_encoder *encoder,
>> -				      const struct drm_display_mode *mode,
>> -				      struct drm_display_mode *adjusted_mode)
>> -{
>> -	return true;
>> -}
>> -
>>   static void virtio_gpu_enc_mode_set(struct drm_encoder *encoder,
>>   				    struct drm_display_mode *mode,
>>   				    struct drm_display_mode *adjusted_mode)
>> @@ -362,7 +355,6 @@ virtio_gpu_best_encoder(struct drm_connector *connector)
>>   }
>>
>>   static const struct drm_encoder_helper_funcs virtio_gpu_enc_helper_funcs = {
>> -	.mode_fixup = virtio_gpu_enc_mode_fixup,
>>   	.mode_set   = virtio_gpu_enc_mode_set,
>>   	.enable     = virtio_gpu_enc_enable,
>>   	.disable    = virtio_gpu_enc_disable,
>> --
>> 2.5.0
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>


From dirk.behme at de.bosch.com  Mon Feb 15 04:40:18 2016
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Mon, 15 Feb 2016 13:40:18 +0100
Subject: [PATCH] arm64: dts: r8a7795: Add GIC-400 virtual interfaces
In-Reply-To: <87povyh6lq.wl%kuninori.morimoto.gx@renesas.com>
References: <1455005692-9382-1-git-send-email-dirk.behme@de.bosch.com>
 <87povyh6lq.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <56C1C732.4050505@de.bosch.com>

On 15.02.2016 06:46, Kuninori Morimoto wrote:
>
> Hi Dirk
> Cc Geert
>
>> Besides the distributor and the CPU interface the GIC-400 additionally
>> supports the virtual interface control blocks and the virtual CPU interfaces.
>>
>> Add the physical base addresses and size for these.
>>
>> See
>>
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0471b/index.html
>> -> 3.2. GIC-400 register map
>>
>> and Linux kernel's
>>
>> Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
>>
>> for more details.
>>
>> Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
>> ---
>
> Our R-Car chip is out-of-mapping.
> Geert had indicated it in
> http://thread.gmane.org/gmane.linux.ports.sh.devel/49751/focus=51544
> And we have no answer about it I think


Could you point us to the code where you think our out-of-mapping 
doesn't work?

Best regards

Dirk



From hdegoede at redhat.com  Mon Feb 15 04:42:35 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Mon, 15 Feb 2016 13:42:35 +0100
Subject: [linux-sunxi] (Still) breaking DT compatibility
In-Reply-To: <56C1A590.6030500@arm.com>
References: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
 <56BE29A1.3060107@redhat.com> <56C1A590.6030500@arm.com>
Message-ID: <56C1C7BB.1040602@redhat.com>

Hi,

On 15-02-16 11:16, Andre Przywara wrote:
> On 12/02/16 18:51, Hans de Goede wrote:
>> Hi,
>>
>> So far I've stayed out of this discussion, but now I feel I have to
>> weigh in:
>>
>> There is no need for this series, device-tree compatibility for
>> sunxi devices is a non issue. No devices ship with dtb files as
>> part of the bootloader / firmware (the vendor kernels do not
>> use dtb at all).
>
> I think you are barking in the wrong thread here.
> I deliberately sent some code to bring this discussion back to a more
> technical level.
>
> But anyway...
>
>> So we always are using a dtb from the kernel tree, and both Fedora
>> and Debian (AFAIK), the 2 distros which ship with more or less official
>> sunxi support package things
>
> Actually I am trying to help that it doesn't need to stay this way. I
> don't see a real reason why a distribution should support a particular
> platform, they certainly don't for x86, for instance.
> I think a stable DT would help to overcome this limited support that we
> see here and would allow distributions to not need to care about sunxi
> in particular.

Only if board vendors would start to actually ship things that way.

> There should be one good DT for all kernels - it may be updated
> (especially if new features get supported), but should never break.
> Also please note that the DT is not only for Linux, BSDs for instance
> use it too - for instance FreeBSD on ARM64.
>
>> so that each kernel version uses the dtb
>> files compiled from the dts shipped with that exact kernel version,
>> (through the ftddir directive in extlinux.conf, which is per menu
>> entry / kernel version) even if multiple kernel versions are installed.
>
> That there are technical ways to mitigate the problem doesn't count as
> an excuse to break DT.
>
> To make this clear: The original PLL6 clock _binding_ is actually fine:
> it describes the clock as per the manual with two clock outputs.
> It's just the driver that is ignoring the clock-output-names that causes
> the issue.
> So we can happily keep the binding, fix the driver and re-use that very
> binding for PLL8, as well.
> This fix series here was the easiest approach in terms of changed code.
> I can make some patches that implement the proper solution - if you
> promise to not shoot down 0/x again easily.
>
> I see that good DT bindings are not easy to come up with. Yes, we are
> not perfect and especially for sunxi with it's bad original
> documentation we won't create perfect DTs from the beginning.
> But I think we should at least _try_ to make a DT what's is meant:
> describing the hardware, part of the firmware and OS agnostic - which
> implies compatibility.
>
>> So there is no reason, no reason at all to worry too much about dtb
>> compatibility for sunxi devices.
>
> I think this argument has been discussed quite a bit in the
> other thread.
> What I am really worried about is that this now creeps into the arm64 world.
> Yes, I see your point that it was a no-brainer so far, but that doesn't
> mean that it has to stay this way. For the A64 for instance there are
> more devices with eMMC in the pipe (Remix Mini PC and the Olimex board),
> so we can just put our firmware bits and the boot loader on there and
> distributions don't need to ship those.

Note that putting a proper version of uboot / the bootloader on the device
is somewhat orthogonal to the whole DT compatibility discussion, the only
thing the bootloader has to do with the dtb when using extlinux booting
is that it has coded which specific dtb file to load for the board,
currently it loads the actual dtb from ftddir/<name-coded-in-u-boot>.dtb
where ftddir gets set by the extlinux.conf entry. I realize that this
will not work when trying to boot a new board with a kernel which does
not have a dtb for this board, and in this case having some sort of
fallback ftddir with a dtb would be interesting, and yes this would
require stable bindings.

I'm not arguing that stable bindings may not be useful but currently
no-one is doing the above. So currently there is no reason to worry
too much about stability. If someone had shipped such a board I would
certainly be in favor of this series. But currently the stability
problem is a hypothetical problem and I do not think that carrying
extra code to fix a hypothetical problem is a good idea.

>> As for compatibility with u-boot, u-boot ships with its own embedded
>> dtb copy, which is based on dts files from the kernel (the u-boot copies
>> get synced regularly), and even if this dtb were to somehow be replaced
>> by a new "incompatible" dtb from a newer kernel there would still not
>> be a problem as u-boot does not (currently) use the clk definitions
>> from the dtb. Note I'm the u-boot sunxi custodian and I'm fine with
>> the proposed changes.
>>
>> TL;DR: NACK for this series.
>
> Seriously?

Yes seriously, because you're fixing a hypothetical problem. I'm all
for not randomly breaking devicetree compatibility and so far on
sunxi this has only be done 2 or 3 times over the years, but in the
end it is a balancing act between wishing to keep compatibility and
wishing to keep clean code.

As soon as we actually see boards shipping with dtb-s encoded in their
bootloader, then this balancing act stops and dt compatibility will
become a hard requirement, but IMHO for now sometimes it is better to
break compat when this helps to keep things clean.

> I would prefer if you would save your NACKs for patches that break
> something instead.
>
> If you are concerned that this fix is too involved, that's mostly due to
> the reason that I couldn't revert the original patch easily due to
> conflicts in subsequent patches, so I did a bit more for the rollback.
> The actual core fix is pretty easy.
>
> So I hope we can come to a conclusion about this one before I prepare
> the next set of patches.

I think that the conclusion is that most people are ok with the break,
as is, since it is known to not cause any real world problems.

But in the end this is Maxime's call.

Regards,

Hans

p.s.

I love the work you've been doing on the A64, I've not had a chance
to try it out yet though. Have you made any progress with getting
the mmc slot to work ?  If not maybe I can make some time I've
prior experience in bringing up the mmc slot on other Allwinner SoCs



From geert+renesas at glider.be  Mon Feb 15 04:44:42 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 13:44:42 +0100
Subject: [PATCH -trivial] devicetree: bindings: ARM: Use "uV" for micro-volt
Message-ID: <1455540282-23619-1-git-send-email-geert+renesas@glider.be>

The binding documentation uses both "uVolt" and "uV" for micro-volt.
Improve consistency by settling on "uV".

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 Documentation/devicetree/bindings/arm/cpus.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index ae9be074d09f66d5..afcf50f050ad3f56 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -250,7 +250,7 @@ nodes to be present and contain the properties described below.
 		Usage: optional
 		Value type: <prop-encoded-array>
 		Definition: A u32 value that represents the running time dynamic
-			    power coefficient in units of mW/MHz/uVolt^2. The
+			    power coefficient in units of mW/MHz/uV^2. The
 			    coefficient can either be calculated from power
 			    measurements or derived by analysis.
 
-- 
1.9.1



From marc.zyngier at arm.com  Mon Feb 15 04:54:06 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Feb 2016 12:54:06 +0000
Subject: [PATCH v6 2/3] Documentation: gpio: Update description for X-Gene
 standby GPIO controller DTS binding
In-Reply-To: <1455512263-18183-3-git-send-email-qnguyen@apm.com>
References: <1455512263-18183-1-git-send-email-qnguyen@apm.com>
 <1455512263-18183-3-git-send-email-qnguyen@apm.com>
Message-ID: <56C1CA6E.1060606@arm.com>

On 15/02/16 04:57, Quan Nguyen wrote:
> Update description for X-Gene standby GPIO controller DTS binding to
> support GPIO line configuration as input, output or external IRQ pin.
> 
> Signed-off-by: Y Vo <yvo at apm.com>
> Signed-off-by: Quan Nguyen <qnguyen at apm.com>
> ---
>  .../devicetree/bindings/gpio/gpio-xgene-sb.txt     | 47 ++++++++++++++++++----
>  1 file changed, 40 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
> index dae1300..7b8b4cb 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
> @@ -1,10 +1,20 @@
>  APM X-Gene Standby GPIO controller bindings
>  
> -This is a gpio controller in the standby domain.
> -
> -There are 20 GPIO pins from 0..21. There is no GPIO_DS14 or GPIO_DS15,
> -only GPIO_DS8..GPIO_DS13 support interrupts. The IRQ mapping
> -is currently 1-to-1 on interrupts 0x28 thru 0x2d.
> +This is a gpio controller in the standby domain. It also supports interrupt in
> +some particular pins which are sourced to its parent interrupt controller
> +as diagram below:
> +                           +-----------------+
> +                           | X-Gene standby  |
> +                           | GPIO controller +--------- GPIO_0
> ++------------+             |                 | ...
> +| Parent IRQ |             |                 +--------- GPIO_8/EXT_INT_0
> +| controller |  EXT_INT_0  |                 | ...
> +| (GICv2)    +-------------+                 +--------- GPIO_[N+8]/EXT_INT_N
> +|            |  ...        |                 |
> +|            |  EXT_INT_N  |                 +--------- GPIO_[N+9]
> +|            +-------------+                 | ...
> +|            |             |                 +--------- GPIO_MAX
> ++------------+             +-----------------+
>  
>  Required properties:
>  - compatible: "apm,xgene-gpio-sb" for the X-Gene Standby GPIO controller
> @@ -15,10 +25,18 @@ Required properties:
>  		0 = active high
>  		1 = active low
>  - gpio-controller: Marks the device node as a GPIO controller.
> -- interrupts: Shall contain exactly 6 interrupts.
> +- interrupts: The EXT_INT_0 parent interrupt resource must be listed first.
> +- interrupt-parent: Phandle of the parent interrupt controller.
> +- interrupt-cells: Should be two.
> +       - first cell is 0-N coresponding for EXT_INT_0 to EXT_INT_N.
> +       - second cell is used to specify flags.
> +- interrupt-controller: Marks the device node as an interrupt controller.
> +- apm,nr-gpios: Optional, specify number of gpios pin.
> +- apm,nr-irqs: Optional, specify number of interrupt pins.
> +- apm,irq-start: Optional, specify lowest gpio pin support interrupt.

This is quite ambiguous. Is that relative to the GIC? Assuming this is
the case, you should then document it, specify the type of interrupt
(SPI?), and whether this is 0- or 32-based (the code seems to indicate
that is is 0-based).

>  
>  Example:
> -	sbgpio: sbgpio at 17001000 {
> +	sbgpio: gpio at 17001000{
>  		compatible = "apm,xgene-gpio-sb";
>  		reg = <0x0 0x17001000 0x0 0x400>;
>  		#gpio-cells = <2>;
> @@ -29,4 +47,19 @@ Example:
>  				<0x0 0x2b 0x1>,
>  				<0x0 0x2c 0x1>,
>  				<0x0 0x2d 0x1>;
> +		interrupt-parent = <&gic>;
> +		#interrupt-cells = <2>;
> +		interrupt-controller;
> +		apm,nr-gpios = <22>;
> +		apm,nr-irqs = <6>;
> +		apm,irq-start = <8>;
> +	};
> +
> +	testuser {
> +		compatible = "example,testuser";
> +		/* Use the GPIO_13/EXT_INT_5 line as an active high triggered
> +		 * level interrupt
> +		 */
> +		interrupts = <5 4>;
> +		interrupt-parent = <&sbgpio>;
>  	};
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From marc.zyngier at arm.com  Mon Feb 15 04:55:30 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Feb 2016 12:55:30 +0000
Subject: [PATCH v6 1/3] gpio: xgene: Enable X-Gene standby GPIO as
 interrupt controller
In-Reply-To: <1455512263-18183-2-git-send-email-qnguyen@apm.com>
References: <1455512263-18183-1-git-send-email-qnguyen@apm.com>
 <1455512263-18183-2-git-send-email-qnguyen@apm.com>
Message-ID: <56C1CAC2.8050709@arm.com>

On 15/02/16 04:57, Quan Nguyen wrote:
> Enable X-Gene standby GPIO controller as interrupt controller to provide
> its own resources. This avoids ambiguity where GIC interrupt resource is
> use as X-Gene standby GPIO interrupt resource in user driver.
> 
> Signed-off-by: Y Vo <yvo at apm.com>
> Signed-off-by: Quan Nguyen <qnguyen at apm.com>

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

	M.
-- 
Jazz is not dead. It just smells funny...


From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 04:57:04 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 12:57:04 +0000
Subject: [PATCH v2 00/17] drm encoders cleanup: nuke optional dummy encoder
 mode_fixup function.
Message-ID: <cover.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Changes v1->v2: incorporated Daniel comments
* added signed-off-by line to all patches
* threading enabled due to e-mail server constraints
* common blurb lines to all patches
* add reviewed by Alex, to patches 4 and 14

Carlos Palminha (17):
  drm/virtio: removed optional dummy encoder mode_fixup function.
  drm/udl: removed optional dummy encoder mode_fixup function.
  drm/exynos: removed optional dummy encoder mode_fixup function.
  drm/amdgpu: removed optional dummy encoder mode_fixup function.
  drm/ast: removed optional dummy encoder mode_fixup function.
  drm/bochs: removed optional dummy encoder mode_fixup function.
  drm/cirrus: removed optional dummy encoder mode_fixup function.
  drm/exynos: removed optional dummy encoder mode_fixup function.
  drm/gma500: removed optional dummy encoder mode_fixup function.
  drm/imx: removed optional dummy encoder mode_fixup function.
  drm/msm/mdp: removed optional dummy encoder mode_fixup function.
  drm/mgag200: removed optional dummy encoder mode_fixup function.
  drm/qxl: removed optional dummy encoder mode_fixup function.
  drm/radeon: removed optional dummy encoder mode_fixup function.
  drm/rockchip: removed optional dummy encoder mode_fixup function.
  drm/sti: removed optional dummy encoder mode_fixup function.
  drm/tilcdc: removed optional dummy encoder mode_fixup function.

 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c           |  8 --------
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c           |  8 --------
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c            |  8 --------
 drivers/gpu/drm/ast/ast_mode.c                   |  8 --------
 drivers/gpu/drm/bochs/bochs_kms.c                |  8 --------
 drivers/gpu/drm/cirrus/cirrus_mode.c             |  9 ---------
 drivers/gpu/drm/exynos/exynos_dp_core.c          |  8 --------
 drivers/gpu/drm/exynos/exynos_drm_dpi.c          |  8 --------
 drivers/gpu/drm/exynos/exynos_drm_dsi.c          |  8 --------
 drivers/gpu/drm/exynos/exynos_drm_vidi.c         |  8 --------
 drivers/gpu/drm/gma500/cdv_intel_crt.c           |  1 -
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c          |  1 -
 drivers/gpu/drm/gma500/gma_display.c             |  7 -------
 drivers/gpu/drm/gma500/gma_display.h             |  3 ---
 drivers/gpu/drm/gma500/oaktrail_hdmi.c           |  1 -
 drivers/gpu/drm/imx/dw_hdmi-imx.c                |  8 --------
 drivers/gpu/drm/imx/imx-ldb.c                    |  8 --------
 drivers/gpu/drm/imx/imx-tve.c                    |  8 --------
 drivers/gpu/drm/imx/parallel-display.c           |  8 --------
 drivers/gpu/drm/mgag200/mgag200_mode.c           |  8 --------
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c  |  8 --------
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c  |  8 --------
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c |  8 --------
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c  |  9 ---------
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c      |  8 --------
 drivers/gpu/drm/qxl/qxl_display.c                |  9 ---------
 drivers/gpu/drm/radeon/atombios_encoders.c       |  8 --------
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c           |  8 --------
 drivers/gpu/drm/sti/sti_tvout.c                  | 10 ----------
 drivers/gpu/drm/tilcdc/tilcdc_panel.c            |  9 ---------
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c           |  9 ---------
 drivers/gpu/drm/udl/udl_encoder.c                |  8 --------
 drivers/gpu/drm/virtio/virtgpu_display.c         |  8 --------
 33 files changed, 244 deletions(-)

-- 
2.5.0



From aleksey.makarov at linaro.org  Mon Feb 15 04:51:52 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 15 Feb 2016 15:51:52 +0300
Subject: [PATCH v2 3/9] ACPI: introduce acpi_table_parse2()
In-Reply-To: <CAJZ5v0i2RCEEZwCN+Ran3Qmasn4yEk1rbfWkZ5QbEkUQWvaJ+g@mail.gmail.com>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
 <1455299022-11641-4-git-send-email-aleksey.makarov@linaro.org>
 <CAJZ5v0i2RCEEZwCN+Ran3Qmasn4yEk1rbfWkZ5QbEkUQWvaJ+g@mail.gmail.com>
Message-ID: <56C1C9E8.2050300@linaro.org>



On 02/13/2016 02:07 AM, Rafael J. Wysocki wrote:
> On Fri, Feb 12, 2016 at 6:43 PM, Aleksey Makarov
> <aleksey.makarov at linaro.org> wrote:
>> The function acpi_table_parse() has some problems:
>> 1 It can be called only from __init code
>> 2 It does not pass any data to the handler
>> 3 It just throws out the value returned from the handler
> 
> So why are those problems?

1.  We need this function to be non-__init because we need access to
some tables at unpredictable time--it may be before or after
the init functions are removed.  For example, SPCR (Serial Port Console
Redirection) table is needed each time a new console is registered.
It can be quite early (console_initcall) or when a module is inserted.

2. Having an additional pointer to void is very useful because it allows
drivers to pass (local) data to the handler.  Without this, we would need 
to have global data and a mutex as it was done in drivers/acpi/scan.c
(vars ape, acpi_probe_count, acpi_probe_lock).

3. Passing the value returned from the callback is less important as it 
could be modelled by having a (return) field in the data passed to 
the handler.  It is very convenient though.

I use these three properties in my next patch of this series.

>> These issues are addressed in this patch
> 
> How are they addressed?

A new function acpi_table_parse2() has been created that is just 
the old acpi_table_parse() without __init, taking the handler with 
additional data pointer and respecting the value returned from 
the handler.  The old acpi_table_parse() was implemented witht this 
new function.  Dropping __init was made possible by the previous 
patch where the attribute of the function early_acpi_os_unmap_memory()
was changed from __init to __ref and by dropping __init from 
acpi_apic_instance.

I understand why this approach is not good and I am going to fix it.

Thank you
Aleksey Makarov


From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 04:57:38 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 12:57:38 +0000
Subject: [PATCH v2 01/17] drm/virtio: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <85230bc1356eb52257aaa1e1965adae2f00db5cd.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
---
 drivers/gpu/drm/virtio/virtgpu_display.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
index a165f03..429aa31 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -282,13 +282,6 @@ static const struct drm_crtc_helper_funcs virtio_gpu_crtc_helper_funcs = {
 	.atomic_check  = virtio_gpu_crtc_atomic_check,
 };
 
-static bool virtio_gpu_enc_mode_fixup(struct drm_encoder *encoder,
-				      const struct drm_display_mode *mode,
-				      struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void virtio_gpu_enc_mode_set(struct drm_encoder *encoder,
 				    struct drm_display_mode *mode,
 				    struct drm_display_mode *adjusted_mode)
@@ -362,7 +355,6 @@ virtio_gpu_best_encoder(struct drm_connector *connector)
 }
 
 static const struct drm_encoder_helper_funcs virtio_gpu_enc_helper_funcs = {
-	.mode_fixup = virtio_gpu_enc_mode_fixup,
 	.mode_set   = virtio_gpu_enc_mode_set,
 	.enable     = virtio_gpu_enc_enable,
 	.disable    = virtio_gpu_enc_disable,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 04:57:58 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 12:57:58 +0000
Subject: [PATCH v2 02/17] drm/udl: removed optional dummy encoder mode_fixup
 function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <a7ebfb6c6c333056d0a77d2684c539107ee63589.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
---
 drivers/gpu/drm/udl/udl_encoder.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_encoder.c b/drivers/gpu/drm/udl/udl_encoder.c
index a181a64..59a4b34 100644
--- a/drivers/gpu/drm/udl/udl_encoder.c
+++ b/drivers/gpu/drm/udl/udl_encoder.c
@@ -26,13 +26,6 @@ static void udl_encoder_disable(struct drm_encoder *encoder)
 {
 }
 
-static bool udl_mode_fixup(struct drm_encoder *encoder,
-			   const struct drm_display_mode *mode,
-			   struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void udl_encoder_prepare(struct drm_encoder *encoder)
 {
 }
@@ -54,7 +47,6 @@ udl_encoder_dpms(struct drm_encoder *encoder, int mode)
 
 static const struct drm_encoder_helper_funcs udl_helper_funcs = {
 	.dpms = udl_encoder_dpms,
-	.mode_fixup = udl_mode_fixup,
 	.prepare = udl_encoder_prepare,
 	.mode_set = udl_encoder_mode_set,
 	.commit = udl_encoder_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 04:58:20 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 12:58:20 +0000
Subject: [PATCH v2 03/17] drm/exynos: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <3768b670931572de51fca1102efa18d20dd770ee.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index e977a81..736115c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1597,13 +1597,6 @@ static int exynos_dsi_create_connector(struct drm_encoder *encoder)
 	return 0;
 }
 
-static bool exynos_dsi_mode_fixup(struct drm_encoder *encoder,
-				  const struct drm_display_mode *mode,
-				  struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void exynos_dsi_mode_set(struct drm_encoder *encoder,
 				struct drm_display_mode *mode,
 				struct drm_display_mode *adjusted_mode)
@@ -1623,7 +1616,6 @@ static void exynos_dsi_mode_set(struct drm_encoder *encoder,
 }
 
 static const struct drm_encoder_helper_funcs exynos_dsi_encoder_helper_funcs = {
-	.mode_fixup = exynos_dsi_mode_fixup,
 	.mode_set = exynos_dsi_mode_set,
 	.enable = exynos_dsi_enable,
 	.disable = exynos_dsi_disable,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 04:59:00 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 12:59:00 +0000
Subject: [PATCH v2 05/17] drm/ast: removed optional dummy encoder mode_fixup
 function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <12e1e900724c890166b88b0f4d67baba387482af.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
---
 drivers/gpu/drm/ast/ast_mode.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 0123458..f221e2d 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -710,13 +710,6 @@ static void ast_encoder_dpms(struct drm_encoder *encoder, int mode)
 
 }
 
-static bool ast_mode_fixup(struct drm_encoder *encoder,
-			   const struct drm_display_mode *mode,
-			   struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void ast_encoder_mode_set(struct drm_encoder *encoder,
 			       struct drm_display_mode *mode,
 			       struct drm_display_mode *adjusted_mode)
@@ -736,7 +729,6 @@ static void ast_encoder_commit(struct drm_encoder *encoder)
 
 static const struct drm_encoder_helper_funcs ast_enc_helper_funcs = {
 	.dpms = ast_encoder_dpms,
-	.mode_fixup = ast_mode_fixup,
 	.prepare = ast_encoder_prepare,
 	.commit = ast_encoder_commit,
 	.mode_set = ast_encoder_mode_set,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 04:59:23 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 12:59:23 +0000
Subject: [PATCH v2 07/17] drm/cirrus: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <a53767402bd4a69c3d2a546b7f4d4d122134b545.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
---
 drivers/gpu/drm/cirrus/cirrus_mode.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c b/drivers/gpu/drm/cirrus/cirrus_mode.c
index 4a02854..432ce94 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -430,14 +430,6 @@ void cirrus_crtc_fb_gamma_get(struct drm_crtc *crtc, u16 *red, u16 *green,
 	*blue = cirrus_crtc->lut_b[regno];
 }
 
-
-static bool cirrus_encoder_mode_fixup(struct drm_encoder *encoder,
-				      const struct drm_display_mode *mode,
-				      struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void cirrus_encoder_mode_set(struct drm_encoder *encoder,
 				struct drm_display_mode *mode,
 				struct drm_display_mode *adjusted_mode)
@@ -466,7 +458,6 @@ static void cirrus_encoder_destroy(struct drm_encoder *encoder)
 
 static const struct drm_encoder_helper_funcs cirrus_encoder_helper_funcs = {
 	.dpms = cirrus_encoder_dpms,
-	.mode_fixup = cirrus_encoder_mode_fixup,
 	.mode_set = cirrus_encoder_mode_set,
 	.prepare = cirrus_encoder_prepare,
 	.commit = cirrus_encoder_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 04:59:49 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 12:59:49 +0000
Subject: [PATCH v2 08/17] drm/exynos: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <4906a9925eebbe55489b1005c449b426a61c09bd.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
---
 drivers/gpu/drm/exynos/exynos_dp_core.c  | 8 --------
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  | 8 --------
 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 8 --------
 3 files changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 673164b..9fd12c62 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1155,13 +1155,6 @@ static int exynos_dp_create_connector(struct drm_encoder *encoder)
 	return 0;
 }
 
-static bool exynos_dp_mode_fixup(struct drm_encoder *encoder,
-				 const struct drm_display_mode *mode,
-				 struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void exynos_dp_mode_set(struct drm_encoder *encoder,
 			       struct drm_display_mode *mode,
 			       struct drm_display_mode *adjusted_mode)
@@ -1177,7 +1170,6 @@ static void exynos_dp_disable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs exynos_dp_encoder_helper_funcs = {
-	.mode_fixup = exynos_dp_mode_fixup,
 	.mode_set = exynos_dp_mode_set,
 	.enable = exynos_dp_enable,
 	.disable = exynos_dp_disable,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 05350ae..75e570f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -128,13 +128,6 @@ static int exynos_dpi_create_connector(struct drm_encoder *encoder)
 	return 0;
 }
 
-static bool exynos_dpi_mode_fixup(struct drm_encoder *encoder,
-				  const struct drm_display_mode *mode,
-				  struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void exynos_dpi_mode_set(struct drm_encoder *encoder,
 				struct drm_display_mode *mode,
 				struct drm_display_mode *adjusted_mode)
@@ -162,7 +155,6 @@ static void exynos_dpi_disable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs exynos_dpi_encoder_helper_funcs = {
-	.mode_fixup = exynos_dpi_mode_fixup,
 	.mode_set = exynos_dpi_mode_set,
 	.enable = exynos_dpi_enable,
 	.disable = exynos_dpi_disable,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 62ac4e5..65108cb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -410,13 +410,6 @@ static int vidi_create_connector(struct drm_encoder *encoder)
 	return 0;
 }
 
-static bool exynos_vidi_mode_fixup(struct drm_encoder *encoder,
-				 const struct drm_display_mode *mode,
-				 struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void exynos_vidi_mode_set(struct drm_encoder *encoder,
 			       struct drm_display_mode *mode,
 			       struct drm_display_mode *adjusted_mode)
@@ -432,7 +425,6 @@ static void exynos_vidi_disable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs exynos_vidi_encoder_helper_funcs = {
-	.mode_fixup = exynos_vidi_mode_fixup,
 	.mode_set = exynos_vidi_mode_set,
 	.enable = exynos_vidi_enable,
 	.disable = exynos_vidi_disable,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 05:00:00 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 13:00:00 +0000
Subject: [PATCH v2 09/17] drm/gma500: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <b704458dc68a73cfb5507933c1df0c2a79e186eb.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
---
 drivers/gpu/drm/gma500/cdv_intel_crt.c  | 1 -
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 1 -
 drivers/gpu/drm/gma500/gma_display.c    | 7 -------
 drivers/gpu/drm/gma500/gma_display.h    | 3 ---
 drivers/gpu/drm/gma500/oaktrail_hdmi.c  | 1 -
 5 files changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index d0717a8..b837e7a 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
@@ -217,7 +217,6 @@ static int cdv_intel_crt_set_property(struct drm_connector *connector,
 
 static const struct drm_encoder_helper_funcs cdv_intel_crt_helper_funcs = {
 	.dpms = cdv_intel_crt_dpms,
-	.mode_fixup = gma_encoder_mode_fixup,
 	.prepare = gma_encoder_prepare,
 	.commit = gma_encoder_commit,
 	.mode_set = cdv_intel_crt_mode_set,
diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
index ddf2d77..28f9d90 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
@@ -255,7 +255,6 @@ static void cdv_hdmi_destroy(struct drm_connector *connector)
 
 static const struct drm_encoder_helper_funcs cdv_hdmi_helper_funcs = {
 	.dpms = cdv_hdmi_dpms,
-	.mode_fixup = gma_encoder_mode_fixup,
 	.prepare = gma_encoder_prepare,
 	.mode_set = cdv_hdmi_mode_set,
 	.commit = gma_encoder_commit,
diff --git a/drivers/gpu/drm/gma500/gma_display.c b/drivers/gpu/drm/gma500/gma_display.c
index ff17af4..9270821 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -478,13 +478,6 @@ int gma_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
 	return 0;
 }
 
-bool gma_encoder_mode_fixup(struct drm_encoder *encoder,
-			    const struct drm_display_mode *mode,
-			    struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 bool gma_crtc_mode_fixup(struct drm_crtc *crtc,
 			 const struct drm_display_mode *mode,
 			 struct drm_display_mode *adjusted_mode)
diff --git a/drivers/gpu/drm/gma500/gma_display.h b/drivers/gpu/drm/gma500/gma_display.h
index ed569d8..78b9f98 100644
--- a/drivers/gpu/drm/gma500/gma_display.h
+++ b/drivers/gpu/drm/gma500/gma_display.h
@@ -90,9 +90,6 @@ extern void gma_crtc_restore(struct drm_crtc *crtc);
 extern void gma_encoder_prepare(struct drm_encoder *encoder);
 extern void gma_encoder_commit(struct drm_encoder *encoder);
 extern void gma_encoder_destroy(struct drm_encoder *encoder);
-extern bool gma_encoder_mode_fixup(struct drm_encoder *encoder,
-				   const struct drm_display_mode *mode,
-				   struct drm_display_mode *adjusted_mode);
 
 /* Common clock related functions */
 extern const struct gma_limit_t *gma_limit(struct drm_crtc *crtc, int refclk);
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 2d18499..8b2eb32 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -601,7 +601,6 @@ static void oaktrail_hdmi_destroy(struct drm_connector *connector)
 
 static const struct drm_encoder_helper_funcs oaktrail_hdmi_helper_funcs = {
 	.dpms = oaktrail_hdmi_dpms,
-	.mode_fixup = gma_encoder_mode_fixup,
 	.prepare = gma_encoder_prepare,
 	.mode_set = oaktrail_hdmi_mode_set,
 	.commit = gma_encoder_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 05:00:24 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 13:00:24 +0000
Subject: [PATCH v2 11/17] drm/msm/mdp: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <77692d9d34c2ed6a035f36d377d3544dbe100114.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c  | 8 --------
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c  | 8 --------
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c | 8 --------
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c  | 9 ---------
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c      | 8 --------
 5 files changed, 41 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c
index 2f57e94..106f0e7 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c
@@ -47,13 +47,6 @@ static const struct drm_encoder_funcs mdp4_dsi_encoder_funcs = {
 	.destroy = mdp4_dsi_encoder_destroy,
 };
 
-static bool mdp4_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
-					const struct drm_display_mode *mode,
-					struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void mdp4_dsi_encoder_mode_set(struct drm_encoder *encoder,
 				      struct drm_display_mode *mode,
 				      struct drm_display_mode *adjusted_mode)
@@ -163,7 +156,6 @@ static void mdp4_dsi_encoder_enable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs mdp4_dsi_encoder_helper_funcs = {
-	.mode_fixup = mdp4_dsi_encoder_mode_fixup,
 	.mode_set = mdp4_dsi_encoder_mode_set,
 	.disable = mdp4_dsi_encoder_disable,
 	.enable = mdp4_dsi_encoder_enable,
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c
index a21df54..35ad78a 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c
@@ -94,13 +94,6 @@ static const struct drm_encoder_funcs mdp4_dtv_encoder_funcs = {
 	.destroy = mdp4_dtv_encoder_destroy,
 };
 
-static bool mdp4_dtv_encoder_mode_fixup(struct drm_encoder *encoder,
-		const struct drm_display_mode *mode,
-		struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void mdp4_dtv_encoder_mode_set(struct drm_encoder *encoder,
 		struct drm_display_mode *mode,
 		struct drm_display_mode *adjusted_mode)
@@ -234,7 +227,6 @@ static void mdp4_dtv_encoder_enable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs mdp4_dtv_encoder_helper_funcs = {
-	.mode_fixup = mdp4_dtv_encoder_mode_fixup,
 	.mode_set = mdp4_dtv_encoder_mode_set,
 	.enable = mdp4_dtv_encoder_enable,
 	.disable = mdp4_dtv_encoder_disable,
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c
index cd63fed..bc3d8e7 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c
@@ -260,13 +260,6 @@ static void setup_phy(struct drm_encoder *encoder)
 	mdp4_write(mdp4_kms, REG_MDP4_LVDS_PHY_CFG0, lvds_phy_cfg0);
 }
 
-static bool mdp4_lcdc_encoder_mode_fixup(struct drm_encoder *encoder,
-		const struct drm_display_mode *mode,
-		struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void mdp4_lcdc_encoder_mode_set(struct drm_encoder *encoder,
 		struct drm_display_mode *mode,
 		struct drm_display_mode *adjusted_mode)
@@ -430,7 +423,6 @@ static void mdp4_lcdc_encoder_enable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs mdp4_lcdc_encoder_helper_funcs = {
-	.mode_fixup = mdp4_lcdc_encoder_mode_fixup,
 	.mode_set = mdp4_lcdc_encoder_mode_set,
 	.disable = mdp4_lcdc_encoder_disable,
 	.enable = mdp4_lcdc_encoder_enable,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
index 1aa21db..69094cb 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
@@ -188,13 +188,6 @@ static const struct drm_encoder_funcs mdp5_cmd_encoder_funcs = {
 	.destroy = mdp5_cmd_encoder_destroy,
 };
 
-static bool mdp5_cmd_encoder_mode_fixup(struct drm_encoder *encoder,
-		const struct drm_display_mode *mode,
-		struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void mdp5_cmd_encoder_mode_set(struct drm_encoder *encoder,
 		struct drm_display_mode *mode,
 		struct drm_display_mode *adjusted_mode)
@@ -256,7 +249,6 @@ static void mdp5_cmd_encoder_enable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs mdp5_cmd_encoder_helper_funcs = {
-	.mode_fixup = mdp5_cmd_encoder_mode_fixup,
 	.mode_set = mdp5_cmd_encoder_mode_set,
 	.disable = mdp5_cmd_encoder_disable,
 	.enable = mdp5_cmd_encoder_enable,
@@ -340,4 +332,3 @@ fail:
 
 	return ERR_PTR(ret);
 }
-
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
index 0d737ca..1d95f9f 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
@@ -112,13 +112,6 @@ static const struct drm_encoder_funcs mdp5_encoder_funcs = {
 	.destroy = mdp5_encoder_destroy,
 };
 
-static bool mdp5_encoder_mode_fixup(struct drm_encoder *encoder,
-		const struct drm_display_mode *mode,
-		struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void mdp5_encoder_mode_set(struct drm_encoder *encoder,
 		struct drm_display_mode *mode,
 		struct drm_display_mode *adjusted_mode)
@@ -287,7 +280,6 @@ static void mdp5_encoder_enable(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs mdp5_encoder_helper_funcs = {
-	.mode_fixup = mdp5_encoder_mode_fixup,
 	.mode_set = mdp5_encoder_mode_set,
 	.disable = mdp5_encoder_disable,
 	.enable = mdp5_encoder_enable,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 05:00:35 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 13:00:35 +0000
Subject: [PATCH v2 12/17] drm/mgag200: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <c5852d59a8890c3570ce97d16c0714a71eb61651.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c b/drivers/gpu/drm/mgag200/mgag200_mode.c
index dc13c48..af8b4c1 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1479,13 +1479,6 @@ void mga_crtc_fb_gamma_get(struct drm_crtc *crtc, u16 *red, u16 *green,
  * These functions are analagous to those in the CRTC code, but are intended
  * to handle any encoder-specific limitations
  */
-static bool mga_encoder_mode_fixup(struct drm_encoder *encoder,
-				   const struct drm_display_mode *mode,
-				   struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void mga_encoder_mode_set(struct drm_encoder *encoder,
 				struct drm_display_mode *mode,
 				struct drm_display_mode *adjusted_mode)
@@ -1515,7 +1508,6 @@ static void mga_encoder_destroy(struct drm_encoder *encoder)
 
 static const struct drm_encoder_helper_funcs mga_encoder_helper_funcs = {
 	.dpms = mga_encoder_dpms,
-	.mode_fixup = mga_encoder_mode_fixup,
 	.mode_set = mga_encoder_mode_set,
 	.prepare = mga_encoder_prepare,
 	.commit = mga_encoder_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 04:58:31 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 12:58:31 +0000
Subject: [PATCH v2 04/17] drm/amdgpu: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <8c4710ee930d2ab3a505b8d3cd724f4f4c79b3df.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
---
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 8 --------
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 8 --------
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  | 8 --------
 3 files changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 093599a..3483018 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -3624,16 +3624,8 @@ dce_v10_0_ext_dpms(struct drm_encoder *encoder, int mode)
 
 }
 
-static bool dce_v10_0_ext_mode_fixup(struct drm_encoder *encoder,
-				    const struct drm_display_mode *mode,
-				    struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static const struct drm_encoder_helper_funcs dce_v10_0_ext_helper_funcs = {
 	.dpms = dce_v10_0_ext_dpms,
-	.mode_fixup = dce_v10_0_ext_mode_fixup,
 	.prepare = dce_v10_0_ext_prepare,
 	.mode_set = dce_v10_0_ext_mode_set,
 	.commit = dce_v10_0_ext_commit,
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 8e67249..36deea1 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -3619,16 +3619,8 @@ dce_v11_0_ext_dpms(struct drm_encoder *encoder, int mode)
 
 }
 
-static bool dce_v11_0_ext_mode_fixup(struct drm_encoder *encoder,
-				    const struct drm_display_mode *mode,
-				    struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static const struct drm_encoder_helper_funcs dce_v11_0_ext_helper_funcs = {
 	.dpms = dce_v11_0_ext_dpms,
-	.mode_fixup = dce_v11_0_ext_mode_fixup,
 	.prepare = dce_v11_0_ext_prepare,
 	.mode_set = dce_v11_0_ext_mode_set,
 	.commit = dce_v11_0_ext_commit,
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index d0e128c..25dd8b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -3554,16 +3554,8 @@ dce_v8_0_ext_dpms(struct drm_encoder *encoder, int mode)
 
 }
 
-static bool dce_v8_0_ext_mode_fixup(struct drm_encoder *encoder,
-				    const struct drm_display_mode *mode,
-				    struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static const struct drm_encoder_helper_funcs dce_v8_0_ext_helper_funcs = {
 	.dpms = dce_v8_0_ext_dpms,
-	.mode_fixup = dce_v8_0_ext_mode_fixup,
 	.prepare = dce_v8_0_ext_prepare,
 	.mode_set = dce_v8_0_ext_mode_set,
 	.commit = dce_v8_0_ext_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 04:59:12 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 12:59:12 +0000
Subject: [PATCH v2 06/17] drm/bochs: removed optional dummy encoder mode_fixup
 function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <d8b87edea28c8211e1711348143e4c355764a8c4.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
---
 drivers/gpu/drm/bochs/bochs_kms.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c
index 2849f1b..317c27f 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -152,13 +152,6 @@ static void bochs_crtc_init(struct drm_device *dev)
 	drm_crtc_helper_add(crtc, &bochs_helper_funcs);
 }
 
-static bool bochs_encoder_mode_fixup(struct drm_encoder *encoder,
-				     const struct drm_display_mode *mode,
-				     struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void bochs_encoder_mode_set(struct drm_encoder *encoder,
 				   struct drm_display_mode *mode,
 				   struct drm_display_mode *adjusted_mode)
@@ -179,7 +172,6 @@ static void bochs_encoder_commit(struct drm_encoder *encoder)
 
 static const struct drm_encoder_helper_funcs bochs_encoder_helper_funcs = {
 	.dpms = bochs_encoder_dpms,
-	.mode_fixup = bochs_encoder_mode_fixup,
 	.mode_set = bochs_encoder_mode_set,
 	.prepare = bochs_encoder_prepare,
 	.commit = bochs_encoder_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 05:00:13 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 13:00:13 +0000
Subject: [PATCH v2 10/17] drm/imx: removed optional dummy encoder mode_fixup
 function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <8bf274e8f6908142a9f940d3f2913e4a735e0caa.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
---
 drivers/gpu/drm/imx/dw_hdmi-imx.c      | 8 --------
 drivers/gpu/drm/imx/imx-ldb.c          | 8 --------
 drivers/gpu/drm/imx/imx-tve.c          | 8 --------
 drivers/gpu/drm/imx/parallel-display.c | 8 --------
 4 files changed, 32 deletions(-)

diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 063825f..21d6158 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -109,13 +109,6 @@ static void dw_hdmi_imx_encoder_disable(struct drm_encoder *encoder)
 {
 }
 
-static bool dw_hdmi_imx_encoder_mode_fixup(struct drm_encoder *encoder,
-					   const struct drm_display_mode *mode,
-					   struct drm_display_mode *adj_mode)
-{
-	return true;
-}
-
 static void dw_hdmi_imx_encoder_mode_set(struct drm_encoder *encoder,
 					 struct drm_display_mode *mode,
 					 struct drm_display_mode *adj_mode)
@@ -138,7 +131,6 @@ static void dw_hdmi_imx_encoder_prepare(struct drm_encoder *encoder)
 }
 
 static const struct drm_encoder_helper_funcs dw_hdmi_imx_encoder_helper_funcs = {
-	.mode_fixup = dw_hdmi_imx_encoder_mode_fixup,
 	.mode_set   = dw_hdmi_imx_encoder_mode_set,
 	.prepare    = dw_hdmi_imx_encoder_prepare,
 	.commit     = dw_hdmi_imx_encoder_commit,
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 22ac482..024d613 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -139,13 +139,6 @@ static void imx_ldb_encoder_dpms(struct drm_encoder *encoder, int mode)
 {
 }
 
-static bool imx_ldb_encoder_mode_fixup(struct drm_encoder *encoder,
-			   const struct drm_display_mode *mode,
-			   struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void imx_ldb_set_clock(struct imx_ldb *ldb, int mux, int chno,
 		unsigned long serial_clk, unsigned long di_clk)
 {
@@ -376,7 +369,6 @@ static const struct drm_encoder_funcs imx_ldb_encoder_funcs = {
 
 static const struct drm_encoder_helper_funcs imx_ldb_encoder_helper_funcs = {
 	.dpms = imx_ldb_encoder_dpms,
-	.mode_fixup = imx_ldb_encoder_mode_fixup,
 	.prepare = imx_ldb_encoder_prepare,
 	.commit = imx_ldb_encoder_commit,
 	.mode_set = imx_ldb_encoder_mode_set,
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 292349f..ae7a9fb 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -286,13 +286,6 @@ static void imx_tve_encoder_dpms(struct drm_encoder *encoder, int mode)
 		dev_err(tve->dev, "failed to disable TVOUT: %d\n", ret);
 }
 
-static bool imx_tve_encoder_mode_fixup(struct drm_encoder *encoder,
-				       const struct drm_display_mode *mode,
-				       struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void imx_tve_encoder_prepare(struct drm_encoder *encoder)
 {
 	struct imx_tve *tve = enc_to_tve(encoder);
@@ -379,7 +372,6 @@ static const struct drm_encoder_funcs imx_tve_encoder_funcs = {
 
 static const struct drm_encoder_helper_funcs imx_tve_encoder_helper_funcs = {
 	.dpms = imx_tve_encoder_dpms,
-	.mode_fixup = imx_tve_encoder_mode_fixup,
 	.prepare = imx_tve_encoder_prepare,
 	.mode_set = imx_tve_encoder_mode_set,
 	.commit = imx_tve_encoder_commit,
diff --git a/drivers/gpu/drm/imx/parallel-display.c b/drivers/gpu/drm/imx/parallel-display.c
index 0ffef17..363e2c7 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -112,13 +112,6 @@ static void imx_pd_encoder_dpms(struct drm_encoder *encoder, int mode)
 		drm_panel_enable(imxpd->panel);
 }
 
-static bool imx_pd_encoder_mode_fixup(struct drm_encoder *encoder,
-			   const struct drm_display_mode *mode,
-			   struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void imx_pd_encoder_prepare(struct drm_encoder *encoder)
 {
 	struct imx_parallel_display *imxpd = enc_to_imxpd(encoder);
@@ -166,7 +159,6 @@ static const struct drm_encoder_funcs imx_pd_encoder_funcs = {
 
 static const struct drm_encoder_helper_funcs imx_pd_encoder_helper_funcs = {
 	.dpms = imx_pd_encoder_dpms,
-	.mode_fixup = imx_pd_encoder_mode_fixup,
 	.prepare = imx_pd_encoder_prepare,
 	.commit = imx_pd_encoder_commit,
 	.mode_set = imx_pd_encoder_mode_set,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 05:00:54 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 13:00:54 +0000
Subject: [PATCH v2 13/17] drm/qxl: removed optional dummy encoder mode_fixup
 function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <f35bc322f7af69ba0fea734d58b4daf5e0cd9786.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
---
 drivers/gpu/drm/qxl/qxl_display.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c
index 8627651..43e5f50 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -734,14 +734,6 @@ static void qxl_enc_dpms(struct drm_encoder *encoder, int mode)
 	DRM_DEBUG("\n");
 }
 
-static bool qxl_enc_mode_fixup(struct drm_encoder *encoder,
-			       const struct drm_display_mode *mode,
-			       struct drm_display_mode *adjusted_mode)
-{
-	DRM_DEBUG("\n");
-	return true;
-}
-
 static void qxl_enc_prepare(struct drm_encoder *encoder)
 {
 	DRM_DEBUG("\n");
@@ -864,7 +856,6 @@ static struct drm_encoder *qxl_best_encoder(struct drm_connector *connector)
 
 static const struct drm_encoder_helper_funcs qxl_enc_helper_funcs = {
 	.dpms = qxl_enc_dpms,
-	.mode_fixup = qxl_enc_mode_fixup,
 	.prepare = qxl_enc_prepare,
 	.mode_set = qxl_enc_mode_set,
 	.commit = qxl_enc_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 05:01:15 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 13:01:15 +0000
Subject: [PATCH v2 15/17] drm/rockchip: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <cae559aa2c04a906c21ed5ebe4861f92440e6910.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
---
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index f8f8f29..7766206 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -875,13 +875,6 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder *encoder)
 	clk_disable_unprepare(dsi->pclk);
 }
 
-static bool dw_mipi_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
-					const struct drm_display_mode *mode,
-					struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void dw_mipi_dsi_encoder_commit(struct drm_encoder *encoder)
 {
 	struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
@@ -931,7 +924,6 @@ static void dw_mipi_dsi_encoder_commit(struct drm_encoder *encoder)
 
 static struct drm_encoder_helper_funcs
 dw_mipi_dsi_encoder_helper_funcs = {
-	.mode_fixup = dw_mipi_dsi_encoder_mode_fixup,
 	.commit = dw_mipi_dsi_encoder_commit,
 	.mode_set = dw_mipi_dsi_encoder_mode_set,
 	.disable = dw_mipi_dsi_encoder_disable,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 05:01:05 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 13:01:05 +0000
Subject: [PATCH v2 14/17] drm/radeon: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <1b99680b8cf81977597dec5daedff9b684d3ed19.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
---
 drivers/gpu/drm/radeon/atombios_encoders.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
index 01b20e1..1603751 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -2623,16 +2623,8 @@ radeon_atom_ext_dpms(struct drm_encoder *encoder, int mode)
 
 }
 
-static bool radeon_atom_ext_mode_fixup(struct drm_encoder *encoder,
-				       const struct drm_display_mode *mode,
-				       struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static const struct drm_encoder_helper_funcs radeon_atom_ext_helper_funcs = {
 	.dpms = radeon_atom_ext_dpms,
-	.mode_fixup = radeon_atom_ext_mode_fixup,
 	.prepare = radeon_atom_ext_prepare,
 	.mode_set = radeon_atom_ext_mode_set,
 	.commit = radeon_atom_ext_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 05:01:25 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 13:01:25 +0000
Subject: [PATCH v2 16/17] drm/sti: removed optional dummy encoder mode_fixup
 function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <7f47c6a7b00e4f16af672ebf3a277e31ad117e21.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
---
 drivers/gpu/drm/sti/sti_tvout.c | 10 ----------
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c
index f2afcf5..24a3735 100644
--- a/drivers/gpu/drm/sti/sti_tvout.c
+++ b/drivers/gpu/drm/sti/sti_tvout.c
@@ -440,13 +440,6 @@ static void sti_tvout_encoder_dpms(struct drm_encoder *encoder, int mode)
 {
 }
 
-static bool sti_tvout_encoder_mode_fixup(struct drm_encoder *encoder,
-				       const struct drm_display_mode *mode,
-				       struct drm_display_mode *adjusted_mode)
-{
-	return true;
-}
-
 static void sti_tvout_encoder_mode_set(struct drm_encoder *encoder,
 				       struct drm_display_mode *mode,
 				       struct drm_display_mode *adjusted_mode)
@@ -486,7 +479,6 @@ static void sti_dvo_encoder_disable(struct drm_encoder *encoder)
 
 static const struct drm_encoder_helper_funcs sti_dvo_encoder_helper_funcs = {
 	.dpms = sti_tvout_encoder_dpms,
-	.mode_fixup = sti_tvout_encoder_mode_fixup,
 	.mode_set = sti_tvout_encoder_mode_set,
 	.prepare = sti_tvout_encoder_prepare,
 	.commit = sti_dvo_encoder_commit,
@@ -540,7 +532,6 @@ static void sti_hda_encoder_disable(struct drm_encoder *encoder)
 
 static const struct drm_encoder_helper_funcs sti_hda_encoder_helper_funcs = {
 	.dpms = sti_tvout_encoder_dpms,
-	.mode_fixup = sti_tvout_encoder_mode_fixup,
 	.mode_set = sti_tvout_encoder_mode_set,
 	.prepare = sti_tvout_encoder_prepare,
 	.commit = sti_hda_encoder_commit,
@@ -589,7 +580,6 @@ static void sti_hdmi_encoder_disable(struct drm_encoder *encoder)
 
 static const struct drm_encoder_helper_funcs sti_hdmi_encoder_helper_funcs = {
 	.dpms = sti_tvout_encoder_dpms,
-	.mode_fixup = sti_tvout_encoder_mode_fixup,
 	.mode_set = sti_tvout_encoder_mode_set,
 	.prepare = sti_tvout_encoder_prepare,
 	.commit = sti_hdmi_encoder_commit,
-- 
2.5.0



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 05:01:35 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 13:01:35 +0000
Subject: [PATCH v2 17/17] drm/tilcdc: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <4d838f580cf81068a4df2500a096d66f06f3ad37.1455540137.git.palminha@synopsys.com>

mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com

This patch set nukes all the dummy mode_fixup implementations.

(made on top of Daniel topic/drm-misc branch)

Signed-off-by: Carlos Palminha <palminha at synopsys.com>
---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 9 ---------
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 9 ---------
 2 files changed, 18 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 4dda6e2..8dcf02a 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -70,14 +70,6 @@ static void panel_encoder_dpms(struct drm_encoder *encoder, int mode)
 					 mode == DRM_MODE_DPMS_ON ? 1 : 0);
 }
 
-static bool panel_encoder_mode_fixup(struct drm_encoder *encoder,
-		const struct drm_display_mode *mode,
-		struct drm_display_mode *adjusted_mode)
-{
-	/* nothing needed */
-	return true;
-}
-
 static void panel_encoder_prepare(struct drm_encoder *encoder)
 {
 	struct panel_encoder *panel_encoder = to_panel_encoder(encoder);
@@ -103,7 +95,6 @@ static const struct drm_encoder_funcs panel_encoder_funcs = {
 
 static const struct drm_encoder_helper_funcs panel_encoder_helper_funcs = {
 		.dpms           = panel_encoder_dpms,
-		.mode_fixup     = panel_encoder_mode_fixup,
 		.prepare        = panel_encoder_prepare,
 		.commit         = panel_encoder_commit,
 		.mode_set       = panel_encoder_mode_set,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index 5052a8a..1c23017 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -80,14 +80,6 @@ static void tfp410_encoder_dpms(struct drm_encoder *encoder, int mode)
 	tfp410_encoder->dpms = mode;
 }
 
-static bool tfp410_encoder_mode_fixup(struct drm_encoder *encoder,
-		const struct drm_display_mode *mode,
-		struct drm_display_mode *adjusted_mode)
-{
-	/* nothing needed */
-	return true;
-}
-
 static void tfp410_encoder_prepare(struct drm_encoder *encoder)
 {
 	tfp410_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
@@ -112,7 +104,6 @@ static const struct drm_encoder_funcs tfp410_encoder_funcs = {
 
 static const struct drm_encoder_helper_funcs tfp410_encoder_helper_funcs = {
 		.dpms           = tfp410_encoder_dpms,
-		.mode_fixup     = tfp410_encoder_mode_fixup,
 		.prepare        = tfp410_encoder_prepare,
 		.commit         = tfp410_encoder_commit,
 		.mode_set       = tfp410_encoder_mode_set,
-- 
2.5.0



From aleksey.makarov at linaro.org  Mon Feb 15 04:57:33 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 15 Feb 2016 15:57:33 +0300
Subject: [PATCH v2 3/9] ACPI: introduce acpi_table_parse2()
In-Reply-To: <CAJZ5v0ji3rR3HkC7BjygkqXxOrEn3qSKA42i1Rj9tBqZ71Dh+w@mail.gmail.com>
References: <1455299022-11641-1-git-send-email-aleksey.makarov@linaro.org>
 <1455299022-11641-4-git-send-email-aleksey.makarov@linaro.org>
 <20160212185130.GA10095@kroah.com>
 <CAJZ5v0ji3rR3HkC7BjygkqXxOrEn3qSKA42i1Rj9tBqZ71Dh+w@mail.gmail.com>
Message-ID: <56C1CB3D.6070906@linaro.org>

Hi Rafael, 

Thank you for review.

On 02/13/2016 02:08 AM, Rafael J. Wysocki wrote:
> On Fri, Feb 12, 2016 at 7:51 PM, Greg Kroah-Hartman
> <gregkh at linuxfoundation.org> wrote:
>> On Fri, Feb 12, 2016 at 08:43:34PM +0300, Aleksey Makarov wrote:
>>> The function acpi_table_parse() has some problems:
>>> 1 It can be called only from __init code
>>> 2 It does not pass any data to the handler
>>> 3 It just throws out the value returned from the handler
>>>
>>> These issues are addressed in this patch
>>
>> Why not just fix acpi_table_parse(), like you have, and not add a new
>> API call with a "2" at the end of it.  That seems crazy to try to
>> maintain that level of apis.
>>
>> But I'm not the acpi maintainer(s), so it's their call...
> 
> The ACPI maintainer agrees.

I see. 

How would you prefer it to be fixed:

1. Change the signature/implementation of acpi_table_parse(). 
CON: It would require extensive changes through all the kernel,
which I am not sure I will be able to test (but these changes are
just adding an unused arg to the handler + checking that the 
return value is consistent)

OR

2. Have a local implementation of the function like acpi_table_parse2()
CON: A bit of code duplication.

Thank you
Aleksey Makarov


From robin.murphy at arm.com  Mon Feb 15 05:11:49 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Mon, 15 Feb 2016 13:11:49 +0000
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160215105909.GH12289@pengutronix.de>
References: <20160214165010.GA3189@roeck-us.net>
 <20160215105909.GH12289@pengutronix.de>
Message-ID: <56C1CE95.6020206@arm.com>

On 15/02/16 10:59, Uwe Kleine-K?nig wrote:
> Hello Guenter,
>
> On Sun, Feb 14, 2016 at 08:50:10AM -0800, Guenter Roeck wrote:
>> Uwe,
>>
>> Your patch 'driver-core: platform: probe of-devices only using list of
>> compatibles' causes the following qemu tests to crash in -next.
>>
>> arm:vexpress-a9:vexpress_defconfig:vexpress-v2p-ca9
>> arm:vexpress-a15:vexpress_defconfig:vexpress-v2p-ca15-tc1
>> arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>> arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>>
>> Crash log:
>>
>> VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6
>> Please append a correct "root=" boot option; here are the available partitions:
>> 1f00          131072 mtdblock0  (driver?)
>> 1f01           32768 mtdblock1  (driver?)
>> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
>
> Can you provide a complete boot log? This might already reveal which
> device is failing. It might not be the mmci device but something it
> depends on (clock, bus parent, irq).

FWIW the PL180 on my Juno still works fine with this patch picked on top 
of -rc3, so the issue would seem to be something else - From a quick 
comparison between the DTs I see a slight difference in compatible 
strings for the clocks, but the more likely-looking suspect is that the 
VExpress DT references some GPIOs where the Juno DT doesn't.

Robin.

>
> Best regards
> Uwe
>



From matthias.bgg at gmail.com  Mon Feb 15 05:29:51 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 15 Feb 2016 14:29:51 +0100
Subject: [PATCH v5sub1 0/8] arm64: split linear and kernel mappings
In-Reply-To: <CAKv+Gu_29SjYgg+P3fyGFcaRVxjapVzMs85Y2frd7_f51mPv-A@mail.gmail.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <56BE3645.3030403@gmail.com>
 <CAKv+Gu9Qw=DSe1fZT=Dv=iKaKqzsf5ARK9dzwCWPk_0uRECm1w@mail.gmail.com>
 <56BE3C35.7070608@gmail.com>
 <CAKv+Gu_29SjYgg+P3fyGFcaRVxjapVzMs85Y2frd7_f51mPv-A@mail.gmail.com>
Message-ID: <56C1D2CF.1010108@gmail.com>



On 13/02/16 15:28, Ard Biesheuvel wrote:
> On 12 February 2016 at 21:10, Matthias Brugger <matthias.bgg at gmail.com> wrote:
>>
>>
>> On 12/02/16 20:47, Ard Biesheuvel wrote:
>>>
>>> On 12 February 2016 at 20:45, Matthias Brugger <matthias.bgg at gmail.com>
>>> wrote:
>>>>
>>>> Hi Ard,
>>>>
>>>>
>>>> On 01/02/16 11:54, Ard Biesheuvel wrote:
>>>>>
>>>>>
>>>>> At the request of Catalin, this series has been split off from my series
>>>>> 'arm64: implement support for KASLR v4' [1]. This sub-series deals with
>>>>> moving the kernel out of the linear mapping into the vmalloc area. This
>>>>> is a prerequisite for independent physical and virtual randomization of
>>>>> the kernel image. On top of that, considering that these changes allow
>>>>> the linear mapping to start at an arbitrary offset above PAGE_OFFSET, it
>>>>> should be an improvement in itself due to the fact that we can now
>>>>> choose
>>>>> PAGE_OFFSET such that RAM can be mapped using large block sizes.
>>>>>
>>>>> For instance, on my Seattle A0 box, the kernel is loaded 16 MB into the
>>>>> lowest GB of RAM, which means __pa(PAGE_OFFSET) is not 1 GB aligned, and
>>>>> the entire 16 GB of RAM will be mapping using 2 MB blocks. (Similarly,
>>>>> for 64 KB granule kernels, the entire 16 GB of RAM will be mapped using
>>>>> pages since __pa(PAGE_OFFSET) is not 512 MB aligned). With these changes
>>>>>     __pa(PAGE_OFFSET) will always be chosen such that it is aligned to a
>>>>> quantity that allows efficient mapping.
>>>>>
>>>>> Note that of the entire KASLR series, this sub-series is the most likely
>>>>> to
>>>>> cause problems, and hence requires the most careful review and testing.
>>>>> This
>>>>> is due to the fact that, with these changes, the invariant __va(__pa(x))
>>>>> == x
>>>>> no longer holds, and any code that is based on that assumption needs to
>>>>> be
>>>>> updated.
>>>>>
>>>>> Changes since v4:
>>>>> - added Marc's ack to patch #6
>>>>> - round the kasan zero shadow region around the kernel image to swapper
>>>>> block
>>>>>      size (#7)
>>>>> - ensure that we don't clip the kernel image when clipping RAM to the
>>>>> linear
>>>>>      region size (#8)
>>>>>
>>>>> Patch #1 allows the low mark of memblocks discovered from the FDT to be
>>>>> overridden by the architecture.
>>>>>
>>>>> Patch #2 enables the huge-vmap generic feature for arm64. This should be
>>>>> an
>>>>> improvement in itself, but the significance for this series is that it
>>>>> allows
>>>>> unmap_kernel_range() to be called on the [__init_begin, __init_end)
>>>>> region,
>>>>> which may be partially mapped using block mappings.
>>>>>
>>>>> Patch #3 introduces KIMAGE_VADDR as a separate, preparatory step towards
>>>>> decoupling the kernel placement from PAGE_OFFSET
>>>>>
>>>>> Patch #4 implements some translation table accessors that operate on
>>>>> statically
>>>>> allocate translation tables before the linear mapping is up.
>>>>>
>>>>> Patch #5 decouples the fixmap initialization from the linear mapping, by
>>>>> using
>>>>> the accessors implemented by patch #4
>>>>>
>>>>> Patch #6 removes assumptions made my KVM regarding the placement of the
>>>>> kernel
>>>>> image inside the linear mapping.
>>>>>
>>>>> Patch #7 moves the kernel image from the base of the linear mapping to
>>>>> the
>>>>> base
>>>>> of the vmalloc area. The modules area, which sits right below the kernel
>>>>> image,
>>>>> is moved along and is put right before the start of the vmalloc area.
>>>>>
>>>>> Patch #8 decouples PHYS_OFFSET from PAGE_OFFSET, which allows the linear
>>>>> mapping
>>>>> to cover all discovered memory, regardless of where the kernel image is
>>>>> located
>>>>> in it. This effectively allows the kernel to be loaded at any physical
>>>>> address
>>>>> (provided that the correct alignment is used)
>>>>>
>>>>> [1] http://thread.gmane.org/gmane.linux.kernel/2135931
>>>>>
>>>>> Ard Biesheuvel (8):
>>>>>      of/fdt: make memblock minimum physical address arch configurable
>>>>>      arm64: add support for ioremap() block mappings
>>>>>      arm64: introduce KIMAGE_VADDR as the virtual base of the kernel
>>>>> region
>>>>>      arm64: pgtable: implement static [pte|pmd|pud]_offset variants
>>>>>      arm64: decouple early fixmap init from linear mapping
>>>>>      arm64: kvm: deal with kernel symbols outside of linear mapping
>>>>>      arm64: move kernel image to base of vmalloc area
>>>>>      arm64: allow kernel Image to be loaded anywhere in physical memory
>>>>>
>>>>
>>>> I bisected linux-next (20160212) with the following error on booting with
>>>> an
>>>> initramfs:
>>>>    Failed to execute /init (error -8)
>>>>    request_module: runaway loop modprobe binfmt-464c
>>>>    Starting init: /sbin/init exists but couldn't execute it (error -8)
>>>>    request_module: runaway loop modprobe binfmt-464c
>>>>    Starting init: /bin/sh exists but couldn't execute it (error -8)
>>>>    Kernel panic - not syncing: No working init found.  Try passing init=
>>>> option to kernel. See Linux Documentation/init..
>>>>
>>>> I tracked down the error to patch 7 of this series. But I realized that
>>>> patch 7 does not compile, but from patch 8 onwards I observe the error.
>>>>
>
> As far as this failure is concerned, I managed to reproduce an error
> with patch #7 and not #8 applied, involving out of range kvm symbols
> at link time. This is reproducible with GCC 4.8 but not GCC 4.9 or
> later. Is this what you were seeing as well? Or is there another
> problem?
>

I realized that I used " aarch64-linux-gnu-gcc (Linaro GCC 2014.11) 
4.9.3 20141031 (prerelease)"  which gave me errors like:

arch/arm64/kvm/built-in.o: In function `__cpu_init_hyp_mode':
/home/mbrugger/src/linux-next/./arch/arm64/include/asm/kvm_host.h:331:(.text+0x73b4): 
relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against symbol 
`__kvm_hyp_vector' defined in .hyp.text section in arch/arm64/kvm/built-in.o

So it was time to update my toolchain to "aarch64-linux-gnu-gcc (Linaro 
GCC 5.1-2015.08) 5.1.1 20150608" which fixed the problem for me.

Thanks,
Matthias

>
>>>> I use defconfig with an initramfs.cpio created with buildroot.
>>>> I tested this on my mt8173 eval board, but I suppose this can be
>>>> reproduced
>>>> easily on other machines as well.
>>>>
>>>
>>> Thanks for the report. Does this help at all?
>>>
>>> http://thread.gmane.org/gmane.linux.ports.arm.kernel/477645
>>>
>>
>> I applied them on top of linux-next and this fixed the problem.
>>
>> Thanks,
>> Matthias
>>
>>
>>>> Regards,
>>>> Matthias
>>>>
>>>>
>>>>>     Documentation/arm64/booting.txt                      |  20 ++-
>>>>>     Documentation/features/vm/huge-vmap/arch-support.txt |   2 +-
>>>>>     arch/arm/include/asm/kvm_asm.h                       |   2 +
>>>>>     arch/arm/kvm/arm.c                                   |   8 +-
>>>>>     arch/arm64/Kconfig                                   |   1 +
>>>>>     arch/arm64/include/asm/boot.h                        |   6 +
>>>>>     arch/arm64/include/asm/kasan.h                       |   2 +-
>>>>>     arch/arm64/include/asm/kernel-pgtable.h              |  12 ++
>>>>>     arch/arm64/include/asm/kvm_asm.h                     |   2 +
>>>>>     arch/arm64/include/asm/kvm_host.h                    |   8 +-
>>>>>     arch/arm64/include/asm/memory.h                      |  44 ++++--
>>>>>     arch/arm64/include/asm/pgtable.h                     |  23 ++-
>>>>>     arch/arm64/kernel/head.S                             |   8 +-
>>>>>     arch/arm64/kernel/image.h                            |  13 +-
>>>>>     arch/arm64/kernel/vmlinux.lds.S                      |   4 +-
>>>>>     arch/arm64/kvm/hyp.S                                 |   6 +-
>>>>>     arch/arm64/mm/dump.c                                 |  12 +-
>>>>>     arch/arm64/mm/init.c                                 | 123
>>>>> ++++++++++++++--
>>>>>     arch/arm64/mm/kasan_init.c                           |  31 +++-
>>>>>     arch/arm64/mm/mmu.c                                  | 155
>>>>> +++++++++++++++-----
>>>>>     drivers/of/fdt.c                                     |   5 +-
>>>>>     21 files changed, 378 insertions(+), 109 deletions(-)
>>>>>
>>>>
>>


From javier at osg.samsung.com  Mon Feb 15 05:38:25 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Mon, 15 Feb 2016 10:38:25 -0300
Subject: [PATCH] ARM: dts: Move syscon reboot/poweroff to common dtsi for
 Exynos
In-Reply-To: <56C02265.40103@samsung.com>
References: <1455042606-10075-1-git-send-email-javier@osg.samsung.com>
 <56C02265.40103@samsung.com>
Message-ID: <56C1D4D1.2050108@osg.samsung.com>

Hello Krzysztof,

On 02/14/2016 03:44 AM, Krzysztof Kozlowski wrote:
> W dniu 10.02.2016 o 03:30, Javier Martinez Canillas pisze:
>> All Exynos SoCs have the same syscon reboot and poweroff device nodes so
>> there is no need to duplicate the same on each SoC dtsi and can be moved
>> to a common dtsi that can be included by all the SoCs dtsi files.
>>
>> Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
>>
>> ---
>> Hello,
>>
>> The patch was tested on an Exynos5800 Peach Pi Chromebook and an
>> Exynos5422 Odroid XU4 board. Reboot and poweroff worked for both.
>>
>> But testing on Exynos3 and Exynos4 will be highly appreciated.
>
> Would you be so kind and add my suggested-by (since it comes from
> https://wiki.tizen.org/wiki/Exynos_Mainline_Kernel_TODO :) )
>

Right, sorry for missing that.
  
> I'll test it on Exynos4 at work and then apply... but few comments below:
>
>>
>> Best regards,
>> Javier
>>
>>   arch/arm/boot/dts/exynos-syscon-restart.dtsi | 23 +++++++++++++++++++++++
>>   arch/arm/boot/dts/exynos3250.dtsi            | 15 +--------------
>>   arch/arm/boot/dts/exynos4.dtsi               | 15 +--------------
>>   arch/arm/boot/dts/exynos5.dtsi               | 15 +--------------
>>   arch/arm/boot/dts/exynos5410.dtsi            | 15 +--------------
>>   5 files changed, 27 insertions(+), 56 deletions(-)
>>   create mode 100644 arch/arm/boot/dts/exynos-syscon-restart.dtsi
>>
>> diff --git a/arch/arm/boot/dts/exynos-syscon-restart.dtsi b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
>> new file mode 100644
>> index 000000000000..2b8acf554881
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
>> @@ -0,0 +1,23 @@
>> +/*
>> + * Samsung's Exynos SoC syscon reboot/poweroff nodes common definition.
>> + *
>> + * 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.
>> + */
>> +
>> +/ {
>
> In some of the DTSI this was under "soc" node, not at top-level.
> Unfortunately we do not have consistency here - some DTSI have "soc",

Yes, I noticed this but as you said not all DTSI have a soc node
and that's why I made it top level in the DTSI.

> some not. Anyway I think we should move to "soc" version.
>

Not sure I'm following, did you mean to do it as a follow up or
to add a soc node for the missing DTSI as a part of this series?

>> +	poweroff: syscon-poweroff {
>> +		compatible = "syscon-poweroff";
>> +		regmap = <&pmu_system_controller>;
>> +		offset = <0x330C>; /* PS_HOLD_CONTROL */
>> +		mask = <0x5200>; /* reset value */
>> +	};
>> +
>> +	reboot: syscon-reboot {
>> +		compatible = "syscon-reboot";
>> +		regmap = <&pmu_system_controller>;
>> +		offset = <0x0400>; /* SWRESET */
>> +		mask = <0x1>;
>> +	};
>> +};
>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
>> index 18e3deffbf48..d9c221517935 100644
>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>> @@ -19,6 +19,7 @@
>>
>>   #include "skeleton.dtsi"
>>   #include "exynos4-cpu-thermal.dtsi"
>> +#include "exynos-syscon-restart.dtsi"
>>   #include <dt-bindings/clock/exynos3250.h>
>>
>>   / {
>> @@ -152,20 +153,6 @@
>>   			interrupt-parent = <&gic>;
>>   		};
>>
>> -		poweroff: syscon-poweroff {
>> -			compatible = "syscon-poweroff";
>> -			regmap = <&pmu_system_controller>;
>> -			offset = <0x330C>; /* PS_HOLD_CONTROL */
>> -			mask = <0x5200>; /* Reset value */
>> -		};
>> -
>> -		reboot: syscon-reboot {
>> -			compatible = "syscon-reboot";
>> -			regmap = <&pmu_system_controller>;
>> -			offset = <0x0400>; /* SWRESET */
>> -			mask = <0x1>;
>> -		};
>> -
>>   		mipi_phy: video-phy at 10020710 {
>>   			compatible = "samsung,s5pv210-mipi-video-phy";
>>   			#phy-cells = <1>;
>> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
>> index ca621a92319e..e6f6939ccdfa 100644
>> --- a/arch/arm/boot/dts/exynos4.dtsi
>> +++ b/arch/arm/boot/dts/exynos4.dtsi
>> @@ -21,6 +21,7 @@
>>
>>   #include <dt-bindings/clock/exynos4.h>
>>   #include <dt-bindings/clock/exynos-audss-clk.h>
>> +#include "exynos-syscon-restart.dtsi"
>
> Just to keep it consistent and logic - include after skeleton.
>

Ok, for include I usually try to keep alphabetically sorted but
I'll move it after skeleton if you prefer to keep it consistent.
  
> Best regards,
> Krzysztof
>

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America


From will.deacon at arm.com  Mon Feb 15 05:40:09 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Feb 2016 13:40:09 +0000
Subject: [PATCH v5sub1 0/8] arm64: split linear and kernel mappings
In-Reply-To: <56C1D2CF.1010108@gmail.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <56BE3645.3030403@gmail.com>
 <CAKv+Gu9Qw=DSe1fZT=Dv=iKaKqzsf5ARK9dzwCWPk_0uRECm1w@mail.gmail.com>
 <56BE3C35.7070608@gmail.com>
 <CAKv+Gu_29SjYgg+P3fyGFcaRVxjapVzMs85Y2frd7_f51mPv-A@mail.gmail.com>
 <56C1D2CF.1010108@gmail.com>
Message-ID: <20160215134009.GB6298@arm.com>

On Mon, Feb 15, 2016 at 02:29:51PM +0100, Matthias Brugger wrote:
> >On 12 February 2016 at 21:10, Matthias Brugger <matthias.bgg at gmail.com> wrote:
> >>On 12/02/16 20:47, Ard Biesheuvel wrote:
> >>>On 12 February 2016 at 20:45, Matthias Brugger <matthias.bgg at gmail.com>
> >>>>I bisected linux-next (20160212) with the following error on booting with
> >>>>an
> >>>>initramfs:
> >>>>   Failed to execute /init (error -8)
> >>>>   request_module: runaway loop modprobe binfmt-464c
> >>>>   Starting init: /sbin/init exists but couldn't execute it (error -8)
> >>>>   request_module: runaway loop modprobe binfmt-464c
> >>>>   Starting init: /bin/sh exists but couldn't execute it (error -8)
> >>>>   Kernel panic - not syncing: No working init found.  Try passing init=
> >>>>option to kernel. See Linux Documentation/init..
> >>>>
> >>>>I tracked down the error to patch 7 of this series. But I realized that
> >>>>patch 7 does not compile, but from patch 8 onwards I observe the error.
> >>>>
> >
> >As far as this failure is concerned, I managed to reproduce an error
> >with patch #7 and not #8 applied, involving out of range kvm symbols
> >at link time. This is reproducible with GCC 4.8 but not GCC 4.9 or
> >later. Is this what you were seeing as well? Or is there another
> >problem?
> >
> 
> I realized that I used " aarch64-linux-gnu-gcc (Linaro GCC 2014.11) 4.9.3
> 20141031 (prerelease)"  which gave me errors like:
> 
> arch/arm64/kvm/built-in.o: In function `__cpu_init_hyp_mode':
> /home/mbrugger/src/linux-next/./arch/arm64/include/asm/kvm_host.h:331:(.text+0x73b4):
> relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against symbol
> `__kvm_hyp_vector' defined in .hyp.text section in arch/arm64/kvm/built-in.o
> 
> So it was time to update my toolchain to "aarch64-linux-gnu-gcc (Linaro GCC
> 5.1-2015.08) 5.1.1 20150608" which fixed the problem for me.

FWIW, I've also been seeing a bunch of reloc errors with allmodconfig,
for-next/core and GCC 4.9. loops_per_jiffy was one of the problematic
symbols, iirc, but upgrading to GCC 6 (devel) fixed the issue.

Will


From patrik.r.jakobsson at gmail.com  Mon Feb 15 05:49:09 2016
From: patrik.r.jakobsson at gmail.com (Patrik Jakobsson)
Date: Mon, 15 Feb 2016 14:49:09 +0100
Subject: [PATCH v2 03/17] drm/exynos: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <3768b670931572de51fca1102efa18d20dd770ee.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
 <3768b670931572de51fca1102efa18d20dd770ee.1455540137.git.palminha@synopsys.com>
Message-ID: <CAMeQTsZLdMOnk7-isneoUyFBbQdiRUsGH6+EhD8W1LNB=80LVQ@mail.gmail.com>

Hi Carlos

Any particular reason why this patch isn't squashed with patch 8/17?

Thanks
Patrik


On Mon, Feb 15, 2016 at 1:58 PM, Carlos Palminha
<CARLOS.PALMINHA at synopsys.com> wrote:
> mode_fixup function for encoder drivers became optional with patch
> http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com
>
> This patch set nukes all the dummy mode_fixup implementations.
>
> (made on top of Daniel topic/drm-misc branch)
>
> Signed-off-by: Carlos Palminha <palminha at synopsys.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 --------
>  1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index e977a81..736115c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1597,13 +1597,6 @@ static int exynos_dsi_create_connector(struct drm_encoder *encoder)
>         return 0;
>  }
>
> -static bool exynos_dsi_mode_fixup(struct drm_encoder *encoder,
> -                                 const struct drm_display_mode *mode,
> -                                 struct drm_display_mode *adjusted_mode)
> -{
> -       return true;
> -}
> -
>  static void exynos_dsi_mode_set(struct drm_encoder *encoder,
>                                 struct drm_display_mode *mode,
>                                 struct drm_display_mode *adjusted_mode)
> @@ -1623,7 +1616,6 @@ static void exynos_dsi_mode_set(struct drm_encoder *encoder,
>  }
>
>  static const struct drm_encoder_helper_funcs exynos_dsi_encoder_helper_funcs = {
> -       .mode_fixup = exynos_dsi_mode_fixup,
>         .mode_set = exynos_dsi_mode_set,
>         .enable = exynos_dsi_enable,
>         .disable = exynos_dsi_disable,
> --
> 2.5.0
>


From leo.yan at linaro.org  Mon Feb 15 05:50:22 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 15 Feb 2016 21:50:22 +0800
Subject: [PATCH v7 RESEND 0/4] mailbox: hisilicon: add Hi6220 mailbox driver
Message-ID: <1455544226-10094-1-git-send-email-leo.yan@linaro.org>

Hi6220 mailbox supports up to 32 channels. Each channel is unidirectional
with a maximum message size of 8 words. I/O is performed using register
access (there is no DMA) and the cell raises an interrupt when messages
are received.

This patch series is to implement Hi6220 mailbox driver. It registers
two channels into framework for communication with MCU, one is tx channel
and another is rx channel. Now mailbox driver is used to send message to
MCU to control dynamic voltage and frequency scaling for CPU, GPU and DDR.

Changes from v6:
* Fix to use lowercase for hexadecimal value in DT binding document

Changes from v5:
* Refine to use mailbox three specifiers for client driver, so add xlate
  callback function in mailbox driver to support these specifiers
* Refine document for property "hi6220,mbox-tx-noirq"

Changes from v4:
* According to Jassi's suggestion, using DT binding to register channels
* Change to use operating-points-v2 to register operating points

Changes from v3:
* The patch series for enabling idle state for Hi6220 has reserved memory
  regions, so this series will not include it anymore
* Refined mailbox driver according to Jassi's suggestion;
  Removed kfifo from mailbox driver;
  Removed spinlock for ipc registers accessing, due every channel has its
  own dedicated bit in ipc register and readl/writel will introduce memory
  barrier, so don't need spinlock to protect ipc registers accessing
* After mailbox driver is ready, can use patch 4 to enable CPU's OPPs and
  stub clock driver; finally can enable CPUFreq driver for CPU frequency
  scaling

Changes from v2:
* Get rid of unused memory regions from memory node in DT, and don't use
  reserved-memory node according to Mark and Leif's suggestion; Haojian also
  has updated UEFI for efi memory info

Changes from v1:
* Correct lock usage for SMP scenario

Changes from RFC:
* According to Jassi's review, totally remove the abstract common driver
  layer and only commit driver dedicated for Hi6220
* According to Paul Bolle's review, fix typo issue for Kconfig and remove
  unnecessary dependency with OF and fix minor for mailbox driver
* Refine a little for dts nodes


Leo Yan (4):
  dt-bindings: mailbox: Document Hi6220 mailbox driver
  mailbox: Hi6220: add mailbox driver
  arm64: dts: add mailbox node for Hi6220
  arm64: dts: add Hi6220's stub clock node

 .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  |  74 ++++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi          |  64 ++++
 drivers/mailbox/Kconfig                            |   8 +
 drivers/mailbox/Makefile                           |   2 +
 drivers/mailbox/hi6220-mailbox.c                   | 395 +++++++++++++++++++++
 5 files changed, 543 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
 create mode 100644 drivers/mailbox/hi6220-mailbox.c

-- 
1.9.1



From leo.yan at linaro.org  Mon Feb 15 05:50:23 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 15 Feb 2016 21:50:23 +0800
Subject: [PATCH v7 RESEND 1/4] dt-bindings: mailbox: Document Hi6220 mailbox
 driver
In-Reply-To: <1455544226-10094-1-git-send-email-leo.yan@linaro.org>
References: <1455544226-10094-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1455544226-10094-2-git-send-email-leo.yan@linaro.org>

Document DT binding for Hisilicon Hi6220 mailbox driver.

Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  | 74 ++++++++++++++++++++++
 1 file changed, 74 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt

diff --git a/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
new file mode 100644
index 0000000..044b17f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
@@ -0,0 +1,74 @@
+Hisilicon Hi6220 Mailbox Driver
+===============================
+
+Hisilicon Hi6220 mailbox supports up to 32 channels. Each channel
+is unidirectional with a maximum message size of 8 words. I/O is
+performed using register access (there is no DMA) and the cell
+raises an interrupt when messages are received.
+
+Mailbox Device Node:
+====================
+
+Required properties:
+--------------------
+- compatible:		Shall be "hisilicon,hi6220-mbox"
+- reg:			Contains the mailbox register address range (base
+			address and length); the first item is for IPC
+			registers, the second item is shared buffer for
+			slots.
+- #mbox-cells:		Common mailbox binding property to identify the number
+			of cells required for the mailbox specifier. Must be 3.
+			<&phandle slot_id dst_irq ack_irq>
+			  phandle: Label name of mailbox controller
+			  slot_id: Slot id used either for TX or RX
+			  dst_irq: IRQ identifier index number which used by MCU
+			  ack_irq: IRQ identifier index number with generating a
+			           TX/RX interrupt to application processor,
+				   mailbox driver uses it to acknowledge interrupt
+- interrupts:		Contains the interrupt information for the mailbox
+			device. The format is dependent on which interrupt
+			controller the SoCs use.
+
+Optional Properties:
+--------------------
+- hi6220,mbox-tx-noirq: Property of MCU firmware's feature, so mailbox driver
+			use this flag to ask MCU to enable "automatic idle
+			flag" mode or IRQ generated mode to acknowledge a TX
+			completion.
+
+Example:
+--------
+
+	mailbox: mailbox at f7510000 {
+		compatible = "hisilicon,hi6220-mbox";
+		reg = <0x0 0xf7510000 0x0 0x1000>, /* IPC_S */
+		      <0x0 0x06dff800 0x0 0x0800>; /* Mailbox */
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+		#mbox-cells = <3>;
+	};
+
+
+Mailbox client
+===============
+
+Required properties:
+--------------------
+- compatible:		Many (See the client docs).
+- mboxes:		Standard property to specify a Mailbox (See ./mailbox.txt)
+			Cells must match 'mbox-cells' (See Mailbox Device Node above).
+
+Optional Properties:
+--------------------
+- mbox-names:		Name given to channels seen in the 'mboxes' property.
+
+Example:
+--------
+
+	stub_clock: stub_clock {
+		compatible = "hisilicon,hi6220-stub-clk";
+		hisilicon,hi6220-clk-sram = <&sram>;
+		#clock-cells = <1>;
+		mbox-names = "mbox-tx", "mbox-rx";
+		mboxes = <&mailbox 1 0 11>, <&mailbox 0 1 10>;
+	};
-- 
1.9.1



From leo.yan at linaro.org  Mon Feb 15 05:50:24 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 15 Feb 2016 21:50:24 +0800
Subject: [PATCH v7 RESEND 2/4] mailbox: Hi6220: add mailbox driver
In-Reply-To: <1455544226-10094-1-git-send-email-leo.yan@linaro.org>
References: <1455544226-10094-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1455544226-10094-3-git-send-email-leo.yan@linaro.org>

Add driver for Hi6220 mailbox, the mailbox communicates with MCU; for
sending data, it can support two methods for low level implementation:
one is to use interrupt as acknowledge, another is automatic mode which
without any acknowledge. These two methods have been supported in the
driver. For receiving data, it will depend on the interrupt to notify
the channel has incoming message.

Now mailbox driver is used to send message to MCU to control dynamic
voltage and frequency scaling for CPU, GPU and DDR.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 drivers/mailbox/Kconfig          |   8 +
 drivers/mailbox/Makefile         |   2 +
 drivers/mailbox/hi6220-mailbox.c | 395 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 405 insertions(+)
 create mode 100644 drivers/mailbox/hi6220-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 1107666..642da1c 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -78,6 +78,14 @@ config STI_MBOX
 	  Mailbox implementation for STMicroelectonics family chips with
 	  hardware for interprocessor communication.
 
+config HI6220_MBOX
+	tristate "Hi6220 Mailbox"
+	depends on ARCH_HISI
+	help
+	  An implementation of the hi6220 mailbox. It is used to send message
+	  between application processors and MCU. Say Y here if you want to
+	  build Hi6220 mailbox controller driver.
+
 config MAILBOX_TEST
 	tristate "Mailbox Test Client"
 	depends on OF
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index b602ef8..2310e99 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -19,3 +19,5 @@ obj-$(CONFIG_BCM2835_MBOX)	+= bcm2835-mailbox.o
 obj-$(CONFIG_STI_MBOX)		+= mailbox-sti.o
 
 obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
+
+obj-$(CONFIG_HI6220_MBOX)	+= hi6220-mailbox.o
diff --git a/drivers/mailbox/hi6220-mailbox.c b/drivers/mailbox/hi6220-mailbox.c
new file mode 100644
index 0000000..613722d
--- /dev/null
+++ b/drivers/mailbox/hi6220-mailbox.c
@@ -0,0 +1,395 @@
+/*
+ * Hisilicon's Hi6220 mailbox driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ * Copyright (c) 2015 Linaro Limited.
+ *
+ * Author: Leo Yan <leo.yan at linaro.org>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kfifo.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#define MBOX_CHAN_MAX			32
+
+#define MBOX_TX				0x1
+
+/* Mailbox message length: 8 words */
+#define MBOX_MSG_LEN			8
+
+/* Mailbox Registers */
+#define MBOX_OFF(m)			(0x40 * (m))
+#define MBOX_MODE_REG(m)		(MBOX_OFF(m) + 0x0)
+#define MBOX_DATA_REG(m)		(MBOX_OFF(m) + 0x4)
+
+#define MBOX_STATE_MASK			(0xF << 4)
+#define MBOX_STATE_IDLE			(0x1 << 4)
+#define MBOX_STATE_TX			(0x2 << 4)
+#define MBOX_STATE_RX			(0x4 << 4)
+#define MBOX_STATE_ACK			(0x8 << 4)
+#define MBOX_ACK_CONFIG_MASK		(0x1 << 0)
+#define MBOX_ACK_AUTOMATIC		(0x1 << 0)
+#define MBOX_ACK_IRQ			(0x0 << 0)
+
+/* IPC registers */
+#define ACK_INT_RAW_REG(i)		((i) + 0x400)
+#define ACK_INT_MSK_REG(i)		((i) + 0x404)
+#define ACK_INT_STAT_REG(i)		((i) + 0x408)
+#define ACK_INT_CLR_REG(i)		((i) + 0x40c)
+#define ACK_INT_ENA_REG(i)		((i) + 0x500)
+#define ACK_INT_DIS_REG(i)		((i) + 0x504)
+#define DST_INT_RAW_REG(i)		((i) + 0x420)
+
+
+struct hi6220_mbox_chan {
+
+	/*
+	 * Description for channel's hardware info:
+	 *  - direction: tx or rx
+	 *  - dst irq: peer core's irq number
+	 *  - ack irq: local irq number
+	 *  - slot number
+	 */
+	unsigned int dir, dst_irq, ack_irq;
+	unsigned int slot;
+
+	struct hi6220_mbox *parent;
+};
+
+struct hi6220_mbox {
+	struct device *dev;
+
+	int irq;
+
+	/* flag of enabling tx's irq mode */
+	bool tx_irq_mode;
+
+	/* region for ipc event */
+	void __iomem *ipc;
+
+	/* region for mailbox */
+	void __iomem *base;
+
+	unsigned int chan_num;
+	struct hi6220_mbox_chan *mchan;
+
+	void *irq_map_chan[MBOX_CHAN_MAX];
+	struct mbox_chan *chan;
+	struct mbox_controller controller;
+};
+
+static void mbox_set_state(struct hi6220_mbox *mbox,
+			   unsigned int slot, u32 val)
+{
+	u32 status;
+
+	status = readl(mbox->base + MBOX_MODE_REG(slot));
+	status = (status & ~MBOX_STATE_MASK) | val;
+	writel(status, mbox->base + MBOX_MODE_REG(slot));
+}
+
+static void mbox_set_mode(struct hi6220_mbox *mbox,
+			  unsigned int slot, u32 val)
+{
+	u32 mode;
+
+	mode = readl(mbox->base + MBOX_MODE_REG(slot));
+	mode = (mode & ~MBOX_ACK_CONFIG_MASK) | val;
+	writel(mode, mbox->base + MBOX_MODE_REG(slot));
+}
+
+static bool hi6220_mbox_last_tx_done(struct mbox_chan *chan)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+	u32 state;
+
+	/* Only set idle state for polling mode */
+	BUG_ON(mbox->tx_irq_mode);
+
+	state = readl(mbox->base + MBOX_MODE_REG(mchan->slot));
+	return ((state & MBOX_STATE_MASK) == MBOX_STATE_IDLE);
+}
+
+static int hi6220_mbox_send_data(struct mbox_chan *chan, void *msg)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+	unsigned int slot = mchan->slot;
+	u32 *buf = msg;
+	int i;
+
+	/* indicate as a TX channel */
+	mchan->dir = MBOX_TX;
+
+	mbox_set_state(mbox, slot, MBOX_STATE_TX);
+
+	if (mbox->tx_irq_mode)
+		mbox_set_mode(mbox, slot, MBOX_ACK_IRQ);
+	else
+		mbox_set_mode(mbox, slot, MBOX_ACK_AUTOMATIC);
+
+	for (i = 0; i < MBOX_MSG_LEN; i++)
+		writel(buf[i], mbox->base + MBOX_DATA_REG(slot) + i * 4);
+
+	/* trigger remote request */
+	writel(BIT(mchan->dst_irq), DST_INT_RAW_REG(mbox->ipc));
+	return 0;
+}
+
+static irqreturn_t hi6220_mbox_interrupt(int irq, void *p)
+{
+	struct hi6220_mbox *mbox = p;
+	struct hi6220_mbox_chan *mchan;
+	struct mbox_chan *chan;
+	unsigned int state, intr_bit, i;
+	u32 msg[MBOX_MSG_LEN];
+
+	state = readl(ACK_INT_STAT_REG(mbox->ipc));
+	if (!state) {
+		dev_warn(mbox->dev, "%s: spurious interrupt\n",
+			 __func__);
+		return IRQ_HANDLED;
+	}
+
+	while (state) {
+		intr_bit = __ffs(state);
+		state &= (state - 1);
+
+		chan = mbox->irq_map_chan[intr_bit];
+		if (!chan) {
+			dev_warn(mbox->dev, "%s: unexpected irq vector %d\n",
+				 __func__, intr_bit);
+			continue;
+		}
+
+		mchan = chan->con_priv;
+		if (mchan->dir == MBOX_TX)
+			mbox_chan_txdone(chan, 0);
+		else {
+			for (i = 0; i < MBOX_MSG_LEN; i++)
+				msg[i] = readl(mbox->base +
+					MBOX_DATA_REG(mchan->slot) + i * 4);
+
+			mbox_chan_received_data(chan, (void *)msg);
+		}
+
+		/* clear IRQ source */
+		writel(BIT(mchan->ack_irq), ACK_INT_CLR_REG(mbox->ipc));
+		mbox_set_state(mbox, mchan->slot, MBOX_STATE_IDLE);
+	}
+
+	return IRQ_HANDLED;
+}
+
+static int hi6220_mbox_startup(struct mbox_chan *chan)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+
+	mchan->dir = 0;
+
+	/* enable interrupt */
+	writel(BIT(mchan->ack_irq), ACK_INT_ENA_REG(mbox->ipc));
+	return 0;
+}
+
+static void hi6220_mbox_shutdown(struct mbox_chan *chan)
+{
+	struct hi6220_mbox_chan *mchan = chan->con_priv;
+	struct hi6220_mbox *mbox = mchan->parent;
+
+	/* disable interrupt */
+	writel(BIT(mchan->ack_irq), ACK_INT_DIS_REG(mbox->ipc));
+	mbox->irq_map_chan[mchan->ack_irq] = NULL;
+}
+
+static struct mbox_chan_ops hi6220_mbox_ops = {
+	.send_data    = hi6220_mbox_send_data,
+	.startup      = hi6220_mbox_startup,
+	.shutdown     = hi6220_mbox_shutdown,
+	.last_tx_done = hi6220_mbox_last_tx_done,
+};
+
+static struct mbox_chan *hi6220_mbox_xlate(struct mbox_controller *controller,
+					   const struct of_phandle_args *spec)
+{
+	struct hi6220_mbox *mbox = dev_get_drvdata(controller->dev);
+	struct hi6220_mbox_chan *mchan;
+	struct mbox_chan *chan;
+	unsigned int i = spec->args[0];
+	unsigned int dst_irq = spec->args[1];
+	unsigned int ack_irq = spec->args[2];
+
+	/* Bounds checking */
+	if (i >= mbox->chan_num || dst_irq >= mbox->chan_num ||
+	    ack_irq >= mbox->chan_num) {
+		dev_err(mbox->dev,
+			"Invalid channel idx %d dst_irq %d ack_irq %d\n",
+			i, dst_irq, ack_irq);
+		return ERR_PTR(-EINVAL);
+	}
+
+	/* Is requested channel free? */
+	chan = &mbox->chan[i];
+	if (mbox->irq_map_chan[ack_irq] == (void *)chan) {
+		dev_err(mbox->dev, "Channel in use\n");
+		return ERR_PTR(-EBUSY);
+	}
+
+	mchan = chan->con_priv;
+	mchan->dst_irq = dst_irq;
+	mchan->ack_irq = ack_irq;
+
+	mbox->irq_map_chan[ack_irq] = (void *)chan;
+	return chan;
+}
+
+static const struct of_device_id hi6220_mbox_of_match[] = {
+	{ .compatible = "hisilicon,hi6220-mbox", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, hi6220_mbox_of_match);
+
+static int hi6220_mbox_probe(struct platform_device *pdev)
+{
+	struct device_node *node = pdev->dev.of_node;
+	struct device *dev = &pdev->dev;
+	struct hi6220_mbox *mbox;
+	struct resource *res;
+	int i, err;
+
+	mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+	if (!mbox)
+		return -ENOMEM;
+
+	mbox->dev = dev;
+	mbox->chan_num = MBOX_CHAN_MAX;
+	mbox->mchan = devm_kzalloc(dev,
+		mbox->chan_num * sizeof(*mbox->mchan), GFP_KERNEL);
+	if (!mbox->mchan)
+		return -ENOMEM;
+
+	mbox->chan = devm_kzalloc(dev,
+		mbox->chan_num * sizeof(*mbox->chan), GFP_KERNEL);
+	if (!mbox->chan)
+		return -ENOMEM;
+
+	mbox->irq = platform_get_irq(pdev, 0);
+	if (mbox->irq < 0)
+		return mbox->irq;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mbox->ipc = devm_ioremap_resource(dev, res);
+	if (IS_ERR(mbox->ipc)) {
+		dev_err(dev, "ioremap ipc failed\n");
+		return PTR_ERR(mbox->ipc);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	mbox->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(mbox->base)) {
+		dev_err(dev, "ioremap buffer failed\n");
+		return PTR_ERR(mbox->base);
+	}
+
+	err = devm_request_irq(dev, mbox->irq, hi6220_mbox_interrupt, 0,
+			dev_name(dev), mbox);
+	if (err) {
+		dev_err(dev, "Failed to register a mailbox IRQ handler: %d\n",
+			err);
+		return -ENODEV;
+	}
+
+	mbox->controller.dev = dev;
+	mbox->controller.chans = &mbox->chan[0];
+	mbox->controller.num_chans = mbox->chan_num;
+	mbox->controller.ops = &hi6220_mbox_ops;
+	mbox->controller.of_xlate = hi6220_mbox_xlate;
+
+	for (i = 0; i < mbox->chan_num; i++) {
+		mbox->chan[i].con_priv = &mbox->mchan[i];
+		mbox->irq_map_chan[i] = NULL;
+
+		mbox->mchan[i].parent = mbox;
+		mbox->mchan[i].slot   = i;
+	}
+
+	/* mask and clear all interrupt vectors */
+	writel(0x0,  ACK_INT_MSK_REG(mbox->ipc));
+	writel(~0x0, ACK_INT_CLR_REG(mbox->ipc));
+
+	/* use interrupt for tx's ack */
+	if (of_find_property(node, "hi6220,mbox-tx-noirq", NULL))
+		mbox->tx_irq_mode = false;
+	else
+		mbox->tx_irq_mode = true;
+
+	if (mbox->tx_irq_mode)
+		mbox->controller.txdone_irq = true;
+	else {
+		mbox->controller.txdone_poll = true;
+		mbox->controller.txpoll_period = 5;
+	}
+
+	err = mbox_controller_register(&mbox->controller);
+	if (err) {
+		dev_err(dev, "Failed to register mailbox %d\n", err);
+		return err;
+	}
+
+	platform_set_drvdata(pdev, mbox);
+	dev_info(dev, "Mailbox enabled\n");
+	return 0;
+}
+
+static int hi6220_mbox_remove(struct platform_device *pdev)
+{
+	struct hi6220_mbox *mbox = platform_get_drvdata(pdev);
+
+	mbox_controller_unregister(&mbox->controller);
+	return 0;
+}
+
+static struct platform_driver hi6220_mbox_driver = {
+	.driver = {
+		.name = "hi6220-mbox",
+		.owner = THIS_MODULE,
+		.of_match_table = hi6220_mbox_of_match,
+	},
+	.probe	= hi6220_mbox_probe,
+	.remove	= hi6220_mbox_remove,
+};
+
+static int __init hi6220_mbox_init(void)
+{
+	return platform_driver_register(&hi6220_mbox_driver);
+}
+core_initcall(hi6220_mbox_init);
+
+static void __exit hi6220_mbox_exit(void)
+{
+	platform_driver_unregister(&hi6220_mbox_driver);
+}
+module_exit(hi6220_mbox_exit);
+
+MODULE_AUTHOR("Leo Yan <leo.yan at linaro.org>");
+MODULE_DESCRIPTION("Hi6220 mailbox driver");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1



From leo.yan at linaro.org  Mon Feb 15 05:50:25 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 15 Feb 2016 21:50:25 +0800
Subject: [PATCH v7 RESEND 3/4] arm64: dts: add mailbox node for Hi6220
In-Reply-To: <1455544226-10094-1-git-send-email-leo.yan@linaro.org>
References: <1455544226-10094-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1455544226-10094-4-git-send-email-leo.yan@linaro.org>

This patch add device mailbox node for Hi6220 in DT.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 2585236..23c79e1 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -249,5 +249,13 @@
 			clocks = <&ao_ctrl 27>;
 			clock-names = "apb_pclk";
 		};
+
+		mailbox: mailbox at f7510000 {
+			compatible = "hisilicon,hi6220-mbox";
+			reg = <0x0 0xf7510000 0x0 0x1000>, /* IPC_S */
+			      <0x0 0x06dff800 0x0 0x0800>; /* Mailbox buffer */
+			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+			#mbox-cells = <3>;
+		};
 	};
 };
-- 
1.9.1



From leo.yan at linaro.org  Mon Feb 15 05:50:26 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 15 Feb 2016 21:50:26 +0800
Subject: [PATCH v7 RESEND 4/4] arm64: dts: add Hi6220's stub clock node
In-Reply-To: <1455544226-10094-1-git-send-email-leo.yan@linaro.org>
References: <1455544226-10094-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1455544226-10094-5-git-send-email-leo.yan@linaro.org>

Enable SRAM node and stub clock node for Hi6220, which uses mailbox
channel 1 for CPU's frequency change.

Furthermore, add the CPU clock phandle in CPU's node and using
operating-points-v2 to register operating points. So can be used by
cpufreq-dt driver.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 56 +++++++++++++++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 23c79e1..f588be9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -81,6 +81,11 @@
 			device_type = "cpu";
 			reg = <0x0 0x0>;
 			enable-method = "psci";
+			clocks = <&stub_clock 0>;
+			operating-points-v2 = <&cpu_opp_table>;
+			cooling-min-level = <4>;
+			cooling-max-level = <0>;
+			#cooling-cells = <2>; /* min followed by max */
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -89,6 +94,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x1>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -97,6 +103,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x2>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -105,6 +112,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x3>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -113,6 +121,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x100>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -121,6 +130,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x101>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -129,6 +139,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x102>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 
@@ -137,10 +148,42 @@
 			device_type = "cpu";
 			reg = <0x0 0x103>;
 			enable-method = "psci";
+			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
 	};
 
+	cpu_opp_table: cpu_opp_table {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp00 {
+			opp-hz = /bits/ 64 <208000000>;
+			opp-microvolt = <1040000>;
+			clock-latency-ns = <500000>;
+		};
+		opp01 {
+			opp-hz = /bits/ 64 <432000000>;
+			opp-microvolt = <1040000>;
+			clock-latency-ns = <500000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <729000000>;
+			opp-microvolt = <1090000>;
+			clock-latency-ns = <500000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <960000000>;
+			opp-microvolt = <1180000>;
+			clock-latency-ns = <500000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt = <1330000>;
+			clock-latency-ns = <500000>;
+		};
+	};
+
 	gic: interrupt-controller at f6801000 {
 		compatible = "arm,gic-400";
 		reg = <0x0 0xf6801000 0 0x1000>, /* GICD */
@@ -168,6 +211,11 @@
 		#size-cells = <2>;
 		ranges;
 
+		sram: sram at fff80000 {
+			compatible = "hisilicon,hi6220-sramctrl", "syscon";
+			reg = <0x0 0xfff80000 0x0 0x12000>;
+		};
+
 		ao_ctrl: ao_ctrl at f7800000 {
 			compatible = "hisilicon,hi6220-aoctrl", "syscon";
 			reg = <0x0 0xf7800000 0x0 0x2000>;
@@ -193,6 +241,14 @@
 			#clock-cells = <1>;
 		};
 
+		stub_clock: stub_clock {
+			compatible = "hisilicon,hi6220-stub-clk";
+			hisilicon,hi6220-clk-sram = <&sram>;
+			#clock-cells = <1>;
+			mbox-names = "mbox-tx";
+			mboxes = <&mailbox 1 0 11>;
+		};
+
 		uart0: uart at f8015000 {	/* console */
 			compatible = "arm,pl011", "arm,primecell";
 			reg = <0x0 0xf8015000 0x0 0x1000>;
-- 
1.9.1



From khalasa at piap.pl  Mon Feb 15 05:51:13 2016
From: khalasa at piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=)
Date: Mon, 15 Feb 2016 14:51:13 +0100
Subject: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
In-Reply-To: <2926427.2IOxhm2GZo@wuerfel> (Arnd Bergmann's message of "Mon, 15
 Feb 2016 10:33:08 +0100")
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <2202960.HHsdV23CYi@wuerfel> <m3a8n2bf72.fsf@t19.piap.pl>
 <2926427.2IOxhm2GZo@wuerfel>
Message-ID: <m3y4amqdym.fsf@t19.piap.pl>

Arnd Bergmann <arnd at arndb.de> writes:

> I consider the use of __raw_* accessors a bug, I don't think we should
> ever do that because it hides how the hardware actually works, it doesn't
> work with spinlocks, and it can lead to the compiler splitting up accesses
> into byte sized ones (not on ARM with the current definition, but
> possible in general).

Well, then maybe we should fix them, or add another set.
Why don't they work with spinlocks?

To be honest, I remember this was already discussed a bit years ago.
I think I proposed back then a set of read_le32 (which would be
equivalent of current readl(), and could be named pci_readl() as well),
read_be32, read_host (without swapping).
The names could be better, though.

> Almost all hardware is fixed-endian, so you have to use swapping accessors
> when the CPU is the other way, except for device RAM and FIFO registers
> that are always used to transfer a byte stream (see the definition of
> readsl() and memcpy_fromio()). When you have hardware that adds byteswaps
> on the bus interface, you typically end up with MMIO registers requiring
> no swap (or double swap) and readsl()/memcpy_fromio()) suddenly requiring
> a swap that is counterintuitive.

Sure, but the __raw_* are used just to be sure there is absolutely no
swapping.
E.g. for IXP4xx, the registers never require swapping, thus readl() etc.
are not suitable for this. What is needed here is simple "atomic" 32-bit
straight to/from register (MM)IO (assuming 4-byte address alignment).

If not __raw_* then what?
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland


From leo.yan at linaro.org  Mon Feb 15 05:54:26 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Mon, 15 Feb 2016 21:54:26 +0800
Subject: [PATCH v7 RESEND 0/4] mailbox: hisilicon: add Hi6220 mailbox
 driver
In-Reply-To: <1455544226-10094-1-git-send-email-leo.yan@linaro.org>
References: <1455544226-10094-1-git-send-email-leo.yan@linaro.org>
Message-ID: <20160215135426.GA10532@leoy-linaro>

On Mon, Feb 15, 2016 at 09:50:22PM +0800, Leo Yan wrote:
> Hi6220 mailbox supports up to 32 channels. Each channel is unidirectional
> with a maximum message size of 8 words. I/O is performed using register
> access (there is no DMA) and the cell raises an interrupt when messages
> are received.
> 
> This patch series is to implement Hi6220 mailbox driver. It registers
> two channels into framework for communication with MCU, one is tx channel
> and another is rx channel. Now mailbox driver is used to send message to
> MCU to control dynamic voltage and frequency scaling for CPU, GPU and DDR.
> 
> Changes from v6:
> * Fix to use lowercase for hexadecimal value in DT binding document

Hi Jassi,

Per your request, I have rebased patches over mailbox-for-next.

Hi Wei,

Could you help merge patch 3/4 for Hi6220's DTS?

Thanks,
Leo Yan

> 
> Changes from v5:
> * Refine to use mailbox three specifiers for client driver, so add xlate
>   callback function in mailbox driver to support these specifiers
> * Refine document for property "hi6220,mbox-tx-noirq"
> 
> Changes from v4:
> * According to Jassi's suggestion, using DT binding to register channels
> * Change to use operating-points-v2 to register operating points
> 
> Changes from v3:
> * The patch series for enabling idle state for Hi6220 has reserved memory
>   regions, so this series will not include it anymore
> * Refined mailbox driver according to Jassi's suggestion;
>   Removed kfifo from mailbox driver;
>   Removed spinlock for ipc registers accessing, due every channel has its
>   own dedicated bit in ipc register and readl/writel will introduce memory
>   barrier, so don't need spinlock to protect ipc registers accessing
> * After mailbox driver is ready, can use patch 4 to enable CPU's OPPs and
>   stub clock driver; finally can enable CPUFreq driver for CPU frequency
>   scaling
> 
> Changes from v2:
> * Get rid of unused memory regions from memory node in DT, and don't use
>   reserved-memory node according to Mark and Leif's suggestion; Haojian also
>   has updated UEFI for efi memory info
> 
> Changes from v1:
> * Correct lock usage for SMP scenario
> 
> Changes from RFC:
> * According to Jassi's review, totally remove the abstract common driver
>   layer and only commit driver dedicated for Hi6220
> * According to Paul Bolle's review, fix typo issue for Kconfig and remove
>   unnecessary dependency with OF and fix minor for mailbox driver
> * Refine a little for dts nodes
> 
> 
> Leo Yan (4):
>   dt-bindings: mailbox: Document Hi6220 mailbox driver
>   mailbox: Hi6220: add mailbox driver
>   arm64: dts: add mailbox node for Hi6220
>   arm64: dts: add Hi6220's stub clock node
> 
>  .../bindings/mailbox/hisilicon,hi6220-mailbox.txt  |  74 ++++
>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi          |  64 ++++
>  drivers/mailbox/Kconfig                            |   8 +
>  drivers/mailbox/Makefile                           |   2 +
>  drivers/mailbox/hi6220-mailbox.c                   | 395 +++++++++++++++++++++
>  5 files changed, 543 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mailbox/hisilicon,hi6220-mailbox.txt
>  create mode 100644 drivers/mailbox/hi6220-mailbox.c
> 
> -- 
> 1.9.1
> 


From wuchengli at chromium.org  Mon Feb 15 05:59:04 2016
From: wuchengli at chromium.org (=?UTF-8?B?V3UtQ2hlbmcgTGkgKOadjuWLmeiqoCk=?=)
Date: Mon, 15 Feb 2016 21:59:04 +0800
Subject: [PATCH v4 2/8] [media] VPU: mediatek: support Mediatek VPU
In-Reply-To: <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <CAOMLVLg_zxkFtAdiTdR=8VD=OnSF0KdD4=U0x_KHrTN9x7WHJw@mail.gmail.com>

On Thu, Feb 4, 2016 at 7:34 PM, Tiffany Lin <tiffany.lin at mediatek.com> wrote:
> The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
> It is able to handle video decoding/encoding of in a range of formats.
> The driver provides with VPU firmware download, memory management and
> the communication interface between CPU and VPU.
> For VPU initialization, it will create virtual memory for CPU access and
> IOMMU address for vcodec hw device access. When a decode/encode instance
> opens a device node, vpu driver will download vpu firmware to the device.
> A decode/encode instant will decode/encode a frame using VPU
> interface to interrupt vpu to handle decoding/encoding jobs.
>
> Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
> Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
> ---
>  drivers/media/platform/Kconfig           |    9 +
>  drivers/media/platform/Makefile          |    2 +
>  drivers/media/platform/mtk-vpu/Makefile  |    1 +
>  drivers/media/platform/mtk-vpu/mtk_vpu.c |  994 ++++++++++++++++++++++++++++++
>  drivers/media/platform/mtk-vpu/mtk_vpu.h |  167 +++++
>  5 files changed, 1173 insertions(+)
>  create mode 100644 drivers/media/platform/mtk-vpu/Makefile
>  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c
>  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index ccbc974..ba812d6 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -148,6 +148,15 @@ config VIDEO_CODA
>            Coda is a range of video codec IPs that supports
>            H.264, MPEG-4, and other video formats.
>
> +config VIDEO_MEDIATEK_VPU
> +       tristate "Mediatek Video Processor Unit"
> +       depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MEDIATEK
> +       ---help---
> +           This driver provides downloading VPU firmware and
> +           communicating with VPU. This driver for hw video
> +           codec embedded in new Mediatek's SOCs. It is able
> +           to handle video decoding/encoding in a range of formats.
> +
>  config VIDEO_MEM2MEM_DEINTERLACE
>         tristate "Deinterlace support"
>         depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index efa0295..e5b19c6 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -55,3 +55,5 @@ obj-$(CONFIG_VIDEO_AM437X_VPFE)               += am437x/
>  obj-$(CONFIG_VIDEO_XILINX)             += xilinx/
>
>  ccflags-y += -I$(srctree)/drivers/media/i2c
> +
> +obj-$(CONFIG_VIDEO_MEDIATEK_VPU)       += mtk-vpu/
> diff --git a/drivers/media/platform/mtk-vpu/Makefile b/drivers/media/platform/mtk-vpu/Makefile
> new file mode 100644
> index 0000000..d890a66
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vpu/Makefile
> @@ -0,0 +1 @@
> +obj-y += mtk_vpu.o
> diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> new file mode 100644
> index 0000000..f54fd89
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> @@ -0,0 +1,994 @@
> +/*
> +* Copyright (c) 2015 MediaTek Inc.
> +* Author: Andrew-CT Chen <andrew-ct.chen at mediatek.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.
> +*/
> +#include <linux/bootmem.h>
> +#include <linux/clk.h>
> +#include <linux/debugfs.h>
> +#include <linux/firmware.h>
> +#include <linux/interrupt.h>
> +#include <linux/iommu.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/sched.h>
> +#include <linux/sizes.h>
> +
> +#include "mtk_vpu.h"
> +
> +/**
> + * VPU (video processor unit) is a tiny processor controlling video hardware
> + * related to video codec, scaling and color format converting.
> + * VPU interfaces with other blocks by share memory and interrupt.
> + **/
> +
> +#define INIT_TIMEOUT_MS                2000U
> +#define IPI_TIMEOUT_MS         2000U
> +#define VPU_FW_VER_LEN         16
> +
> +/* maximum program/data TCM (Tightly-Coupled Memory) size */
> +#define VPU_PTCM_SIZE          (96 * SZ_1K)
> +#define VPU_DTCM_SIZE          (32 * SZ_1K)
> +/* the offset to get data tcm address */
> +#define VPU_DTCM_OFFSET                0x18000UL
> +/* daynamic allocated maximum extended memory size */
> +#define VPU_EXT_P_SIZE         SZ_1M
> +#define VPU_EXT_D_SIZE         SZ_4M
> +/* maximum binary firmware size */
> +#define VPU_P_FW_SIZE          (VPU_PTCM_SIZE + VPU_EXT_P_SIZE)
> +#define VPU_D_FW_SIZE          (VPU_DTCM_SIZE + VPU_EXT_D_SIZE)
> +/* the size of share buffer between Host and  VPU */
> +#define SHARE_BUF_SIZE         48
> +
> +/* binary firmware name */
> +#define VPU_P_FW               "vpu_p.bin"
> +#define VPU_D_FW               "vpu_d.bin"
> +
> +#define VPU_RESET              0x0
> +#define VPU_TCM_CFG            0x0008
> +#define VPU_PMEM_EXT0_ADDR     0x000C
> +#define VPU_PMEM_EXT1_ADDR     0x0010
> +#define VPU_TO_HOST            0x001C
> +#define VPU_DMEM_EXT0_ADDR     0x0014
> +#define VPU_DMEM_EXT1_ADDR     0x0018
> +#define HOST_TO_VPU            0x0024
> +#define VPU_PC_REG             0x0060
> +#define VPU_WDT_REG            0x0084
> +
> +/* vpu inter-processor communication interrupt */
> +#define VPU_IPC_INT            BIT(8)
> +
> +/**
> + * enum vpu_fw_type - VPU firmware type
> + *
> + * @P_FW: program firmware
> + * @D_FW: data firmware
> + *
> + */
> +enum vpu_fw_type {
> +       P_FW,
> +       D_FW,
> +};
> +
> +/**
> + * struct vpu_mem - VPU extended program/data memory information
> + *
> + * @va:                the kernel virtual memory address of VPU extended memory
> + * @pa:                the physical memory address of VPU extended memory
This should be device memory address? If yes, s/physical/device/ and
s/pa/dma_addr/.
> + *
> + */
> +struct vpu_mem {
> +       void *va;
> +       dma_addr_t pa;
> +};
> +
> +/**
> + * struct vpu_regs - VPU TCM and configuration registers
> + *
> + * @tcm:       the register for VPU Tightly-Coupled Memory
> + * @cfg:       the register for VPU configuration
> + * @irq:       the irq number for VPU interrupt
> + */
> +struct vpu_regs {
> +       void __iomem *tcm;
> +       void __iomem *cfg;
> +       int irq;
> +};
> +
> +/**
> + * struct vpu_wdt_handler - VPU watchdog reset handler
> + *
> + * @reset_func:        reset handler
> + * @priv:      private data
> + */
> +struct vpu_wdt_handler {
> +       void (*reset_func)(void *);
> +       void *priv;
> +};
> +
> +/**
> + * struct vpu_wdt - VPU watchdog workqueue
> + *
> + * @handler:   VPU watchdog reset handler
> + * @ws:                workstruct for VPU watchdog
> + * @wq:                workqueue for VPU watchdog
> + */
> +struct vpu_wdt {
> +       struct vpu_wdt_handler handler[VPU_RST_MAX];
> +       struct work_struct ws;
> +       struct workqueue_struct *wq;
> +};
> +
> +/**
> + * struct vpu_run - VPU initialization status
> + *
> + * @signaled:          the signal of vpu initialization completed
> + * @fw_ver:            VPU firmware version
> + * @enc_capability:    encoder capability
We should document the meaning of the bit used. Since no bit is used
by the codec driver, document this is not used for now and the value
is reserved for future use.
> + * @wq:                        wait queue for VPU initialization status
> + */
> +struct vpu_run {
> +       u32 signaled;
> +       char fw_ver[VPU_FW_VER_LEN];
> +       unsigned int    enc_capability;
> +       wait_queue_head_t wq;
> +};
> +
> +/**
> + * struct vpu_ipi_desc - VPU IPI descriptor
> + *
> + * @handler:   IPI handler
> + * @name:      the name of IPI handler
> + * @priv:      the private data of IPI handler
> + */
> +struct vpu_ipi_desc {
> +       ipi_handler_t handler;
> +       const char *name;
> +       void *priv;
> +};
> +
> +/**
> + * struct share_obj - DTCM (Data Tightly-Coupled Memory) buffer shared with
> + *                   AP and VPU
> + *
> + * @id:                IPI id
> + * @len:       share buffer length
> + * @share_buf: share buffer data
> + */
> +struct share_obj {
> +       s32 id;
> +       u32 len;
> +       unsigned char share_buf[SHARE_BUF_SIZE];
> +};
> +
> +/**
> + * struct mtk_vpu - vpu driver data
> + * @extmem:            VPU extended memory information
> + * @reg:               VPU TCM and configuration registers
> + * @run:               VPU initialization status
> + * @ipi_desc:          VPU IPI descriptor
> + * @recv_buf:          VPU DTCM share buffer for receiving. The
> + *                     receive buffer is only accessed in interrupt context.
> + * @send_buf:          VPU DTCM share buffer for sending
> + * @dev:               VPU struct device
> + * @clk:               VPU clock on/off
> + * @enable_4GB:                VPU 4GB mode on/off
> + * @vpu_mutex:         protect mtk_vpu (except recv_buf) and ensure only
> + *                     one client to use VPU service at a time. For example,
> + *                     suppose a client is using VPU to decode VP8.
> + *                     If the other client wants to encode VP8,
> + *                     it has to wait until VP8 decode completes.
> + * @wdt_refcnt         WDT reference count to make sure the watchdog can be
> + *                     disabled if no other client is using VPU service
> + * @ipi_ack_signaled:  The ACKs for registered IPI function sending
> + *                     interrupt to VPU
s/ipi_ack_signaled/ipi_id_ack/. Move to after |ack_wq| to be
consistent with the order of variable declaration.
> + * @ack_wq:            The wait queue for each codec and mdp. When sleeping
> + *                     processes wake up, they will check the condition
> + *                     "ipi_ack_signaled" to run the corresponding action or
> + *                     go back to sleep.
> + *
> + */
> +struct mtk_vpu {
> +       struct vpu_mem extmem[2];
> +       struct vpu_regs reg;
> +       struct vpu_run run;
> +       struct vpu_wdt wdt;
> +       struct vpu_ipi_desc ipi_desc[IPI_MAX];
> +       struct share_obj *recv_buf;
> +       struct share_obj *send_buf;
> +       struct device *dev;
> +       struct clk *clk;
> +       bool enable_4GB;
> +       struct mutex vpu_mutex; /* for protecting vpu data data structure */
Remove the comment here. It should be documented in function comment above.
> +       atomic_t wdt_refcnt;
> +       wait_queue_head_t ack_wq;
> +       bool ipi_id_ack[IPI_MAX];
> +};
> +
> +static inline void vpu_cfg_writel(struct mtk_vpu *vpu, u32 val, u32 offset)
> +{
> +       writel(val, vpu->reg.cfg + offset);
> +}
> +
> +static inline u32 vpu_cfg_readl(struct mtk_vpu *vpu, u32 offset)
> +{
> +       return readl(vpu->reg.cfg + offset);
> +}
> +
> +static inline bool vpu_running(struct mtk_vpu *vpu)
> +{
> +       return vpu_cfg_readl(vpu, VPU_RESET) & BIT(0);
> +}
> +
> +void vpu_clock_disable(struct mtk_vpu *vpu)
> +{
> +       /* Disable VPU watchdog */
> +       if (atomic_dec_and_test(&vpu->wdt_refcnt))
Checking wdt_refcnt and doing vpu_cfg_writel should be done
atomically. For example, if vpu_clock_enable is called after
atomic_dec_and_test(&vpu->wdt_refcnt) and before vpu_cfg_writel(...),
the state of watchdog could be wrong. Adding a spinlock to protect
wdt_refcnt and vpu_cfg_writel together. Then wdt_refcnt doesn't need
to be atomic_t.
> +               vpu_cfg_writel(vpu,
> +                              vpu_cfg_readl(vpu, VPU_WDT_REG) & ~(1L << 31),
> +                              VPU_WDT_REG);
> +
> +       clk_disable(vpu->clk);
> +}
> +
> +int vpu_clock_enable(struct mtk_vpu *vpu)
> +{
> +       int ret;
> +
> +       ret = clk_enable(vpu->clk);
> +       if (ret)
> +               return ret;
> +       /* Enable VPU watchdog */
> +       if (!atomic_read(&vpu->wdt_refcnt))
Do we need to enable the watchdog other than vpu_ipi_send? The only
place that AP waits for VPU is in vpu_ipi_send. Right? If yes, can we
just enable and disable the watchdog in vpu_ipi_send?
> +               vpu_cfg_writel(vpu,
> +                              vpu_cfg_readl(vpu, VPU_WDT_REG) | (1L << 31),
> +                              VPU_WDT_REG);
> +
> +       atomic_inc(&vpu->wdt_refcnt);
Same above. atomic_read, vpu_cfg_writel, and atomic_inc should be done
atomically.
> +
> +       return ret;
> +}
> +
> +int vpu_ipi_register(struct platform_device *pdev,
> +                    enum ipi_id id, ipi_handler_t handler,
> +                    const char *name, void *priv)
> +{
> +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> +       struct vpu_ipi_desc *ipi_desc;
> +
> +       if (!vpu) {
> +               dev_err(&pdev->dev, "vpu device in not ready\n");
> +               return -EPROBE_DEFER;
> +       }
> +
> +       if (id < IPI_MAX && handler) {
Check if id >= 0 because type of enum is implementation dependent.
> +               ipi_desc = vpu->ipi_desc;
> +               ipi_desc[id].name = name;
> +               ipi_desc[id].handler = handler;
> +               ipi_desc[id].priv = priv;
> +               return 0;
> +       }
> +
> +       dev_err(&pdev->dev, "register vpu ipi with invalid arguments\n");
print id
> +       return -EINVAL;
> +}
> +
> +int vpu_ipi_send(struct platform_device *pdev,
> +                enum ipi_id id, void *buf,
> +                unsigned int len)
> +{
> +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> +       struct share_obj *send_obj = vpu->send_buf;
> +       unsigned long timeout;
> +       int ret = 0;
> +
> +       if (id <= IPI_VPU_INIT || id >= IPI_MAX ||
> +           len > sizeof(send_obj->share_buf) || !buf) {
> +               dev_err(vpu->dev, "failed to send ipi message\n");
> +               return -EINVAL;
> +       }
> +
> +       ret = vpu_clock_enable(vpu);
> +       if (ret) {
> +               dev_err(vpu->dev, "failed to enable vpu clock\n");
> +               return ret;
> +       }
> +       if (!vpu_running(vpu)) {
> +               dev_err(vpu->dev, "vpu_ipi_send: VPU is not running\n");
> +               ret = -EINVAL;
> +               goto clock_disable;
> +       }
> +
> +       mutex_lock(&vpu->vpu_mutex);
> +
> +        /* Wait until VPU receives the last command */
> +       timeout = jiffies + msecs_to_jiffies(IPI_TIMEOUT_MS);
> +       do {
> +               if (time_after(jiffies, timeout)) {
> +                       dev_err(vpu->dev, "vpu_ipi_send: IPI timeout!\n");
> +                       ret = -EIO;
> +                       goto mut_unlock;
> +               }
> +       } while (vpu_cfg_readl(vpu, HOST_TO_VPU));
> +
> +       memcpy((void *)send_obj->share_buf, buf, len);
> +       send_obj->len = len;
> +       send_obj->id = id;
> +
> +       vpu->ipi_id_ack[id] = false;
> +       /* send the command to VPU */
> +       vpu_cfg_writel(vpu, 0x1, HOST_TO_VPU);
> +
> +       mutex_unlock(&vpu->vpu_mutex);
> +
> +       /* wait for VPU's ACK */
> +       timeout = msecs_to_jiffies(IPI_TIMEOUT_MS);
> +       ret = wait_event_interruptible_timeout(vpu->ack_wq,
> +                                              vpu->ipi_id_ack[id], timeout);
> +       vpu->ipi_id_ack[id] = false;
> +       if (ret == 0) {
> +               dev_err(vpu->dev, "vpu ipi %d ack time out !", id);
> +               ret = -EIO;
> +               goto clock_disable;
> +       } else if (-ERESTARTSYS == ret) {
> +               dev_err(vpu->dev, "vpu ipi %d ack wait interrupted by a signal",
> +                       id);
> +               ret = -ERESTARTSYS;
> +               goto clock_disable;
> +       }
> +       vpu_clock_disable(vpu);
> +
> +       return 0;
> +
> +mut_unlock:
> +       vpu->ipi_id_ack[id] = false;
I don't see why we need to set it to false here. Remove if not needed.
> +       mutex_unlock(&vpu->vpu_mutex);
> +clock_disable:
> +       vpu_clock_disable(vpu);
> +
> +       return ret;
> +}
> +
> +static void vpu_wdt_reset_func(struct work_struct *ws)
> +{
> +       struct vpu_wdt *wdt = container_of(ws, struct vpu_wdt, ws);
> +       struct mtk_vpu *vpu = container_of(wdt, struct mtk_vpu, wdt);
> +       struct vpu_wdt_handler *handler = wdt->handler;
> +       int index, ret;
> +
> +       dev_info(vpu->dev, "vpu reset\n");
> +       mutex_lock(&vpu->vpu_mutex);
> +       ret = vpu_clock_enable(vpu);
> +       if (ret) {
This is missing mutex_unlock. Move mutex_lock right before
vpu_cfg_writel(vpu, 0x0, VPU_RESET);. So we don't need to unlock when
vpu_clock_enable fails.
> +               dev_err(vpu->dev, "[VPU] wdt enables clock failed %d\n", ret);
> +               return;
> +       }
> +       vpu_cfg_writel(vpu, 0x0, VPU_RESET);
> +       vpu_clock_disable(vpu);
> +       mutex_unlock(&vpu->vpu_mutex);
> +
> +       for (index = 0; index < VPU_RST_MAX; index++) {
> +               if (handler[index].reset_func) {
> +                       handler[index].reset_func(handler[index].priv);
> +                       dev_dbg(vpu->dev, "wdt handler func %d\n", index);
> +               }
> +       }
> +}
> +
> +int vpu_wdt_reg_handler(struct platform_device *pdev,
> +                       void wdt_reset(void *),
> +                       void *priv, enum rst_id id)
> +{
> +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> +       struct vpu_wdt_handler *handler = vpu->wdt.handler;
> +
> +       if (!vpu) {
> +               dev_err(vpu->dev, "vpu device in not ready\n");
> +               return -EPROBE_DEFER;
> +       }
> +
> +       if (id < VPU_RST_MAX && wdt_reset != NULL) {
Check id >= 0
> +               dev_dbg(vpu->dev, "wdt register id %d\n", id);
> +               mutex_lock(&vpu->vpu_mutex);
> +               handler[id].reset_func = wdt_reset;
> +               handler[id].priv = priv;
> +               mutex_unlock(&vpu->vpu_mutex);
> +               return 0;
> +       }
> +
> +       dev_err(vpu->dev, "register vpu wdt handler failed\n");
> +       return -EINVAL;
> +}
> +
> +unsigned int vpu_get_venc_hw_capa(struct platform_device *pdev)
> +{
> +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> +
> +       return vpu->run.enc_capability;
> +}
> +
> +void *vpu_mapping_dm_addr(struct platform_device *pdev,
> +                         u32 dtcm_dmem_addr)
> +{
> +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> +
> +       if (!dtcm_dmem_addr ||
> +           (dtcm_dmem_addr > (VPU_DTCM_SIZE + VPU_EXT_D_SIZE))) {
> +               dev_err(vpu->dev, "invalid virtual data memory address\n");
> +               return ERR_PTR(-EINVAL);
> +       }
> +
> +       if (dtcm_dmem_addr < VPU_DTCM_SIZE)
> +               return dtcm_dmem_addr + vpu->reg.tcm + VPU_DTCM_OFFSET;
> +
> +       return vpu->extmem[D_FW].va + (dtcm_dmem_addr - VPU_DTCM_SIZE);
> +}
> +
> +struct platform_device *vpu_get_plat_device(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct device_node *vpu_node;
> +       struct platform_device *vpu_pdev;
> +
> +       vpu_node = of_parse_phandle(dev->of_node, "mediatek,vpu", 0);
> +       if (!vpu_node) {
> +               dev_err(dev, "can't get vpu node\n");
> +               return NULL;
> +       }
> +
> +       vpu_pdev = of_find_device_by_node(vpu_node);
> +       if (WARN_ON(!vpu_pdev)) {
> +               dev_err(dev, "vpu pdev failed\n");
> +               of_node_put(vpu_node);
> +               return NULL;
> +       }
> +
> +       return vpu_pdev;
> +}
> +
> +/* load vpu program/data memory */
> +static int load_requested_vpu(struct mtk_vpu *vpu,
> +                             const struct firmware *vpu_fw,
> +                             u8 fw_type)
> +{
> +       size_t tcm_size = fw_type ? VPU_DTCM_SIZE : VPU_PTCM_SIZE;
> +       size_t fw_size = fw_type ? VPU_D_FW_SIZE : VPU_P_FW_SIZE;
> +       char *fw_name = fw_type ? VPU_D_FW : VPU_P_FW;
> +       size_t dl_size = 0;
> +       size_t extra_fw_size = 0;
> +       void *dest;
> +       int ret;
> +
> +       ret = request_firmware(&vpu_fw, fw_name, vpu->dev);
> +       if (ret < 0) {
> +               dev_err(vpu->dev, "Failed to load %s, %d\n", fw_name, ret);
> +               return ret;
> +       }
> +       dl_size = vpu_fw->size;
> +       if (dl_size > fw_size) {
> +               dev_err(vpu->dev, "fw %s size %zu is abnormal\n", fw_name,
> +                       dl_size);
> +               release_firmware(vpu_fw);
> +               return  -EFBIG;
> +       }
> +       dev_dbg(vpu->dev, "Downloaded fw %s size: %zu.\n",
> +               fw_name,
> +               dl_size);
> +       /* reset VPU */
> +       vpu_cfg_writel(vpu, 0x0, VPU_RESET);
> +
> +       /* handle extended firmware size */
> +       if (dl_size > tcm_size) {
> +               dev_dbg(vpu->dev, "fw size %lx > limited fw size %lx\n",
> +                       dl_size, tcm_size);
> +               extra_fw_size = dl_size - tcm_size;
> +               dev_dbg(vpu->dev, "extra_fw_size %lx\n", extra_fw_size);
> +               dl_size = tcm_size;
> +       }
> +       dest = vpu->reg.tcm;
> +       if (fw_type == D_FW)
> +               dest += VPU_DTCM_OFFSET;
> +       memcpy(dest, vpu_fw->data, dl_size);
> +       /* download to extended memory if need */
> +       if (extra_fw_size > 0) {
> +               dest = vpu->extmem[fw_type].va;
> +               dev_dbg(vpu->dev, "download extended memory type %x\n",
> +                       fw_type);
> +               memcpy(dest, vpu_fw->data + tcm_size, extra_fw_size);
> +       }
> +
> +       release_firmware(vpu_fw);
> +
> +       return 0;
> +}
> +
> +int vpu_load_firmware(struct platform_device *pdev)
> +{
> +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> +       struct device *dev = &pdev->dev;
> +       struct vpu_run *run = &vpu->run;
> +       const struct firmware *vpu_fw;
> +       int ret;
> +
> +       if (!pdev) {
> +               dev_err(dev, "VPU platform device is invalid\n");
> +               return -EINVAL;
> +       }
> +
> +       mutex_lock(&vpu->vpu_mutex);
> +
> +       ret = vpu_clock_enable(vpu);
> +       if (ret) {
> +               dev_err(dev, "enable clock failed %d\n", ret);
> +               goto OUT_LOAD_FW;
> +       }
> +
> +       if (vpu_running(vpu)) {
> +               vpu_clock_disable(vpu);
> +               mutex_unlock(&vpu->vpu_mutex);
> +               dev_warn(dev, "vpu is running already\n");
> +               return 0;
> +       }
> +
> +       run->signaled = false;
> +       dev_dbg(vpu->dev, "firmware request\n");
> +       /* Downloading program firmware to device*/
> +       ret = load_requested_vpu(vpu, vpu_fw, P_FW);
> +       if (ret < 0) {
> +               dev_err(dev, "Failed to request %s, %d\n", VPU_P_FW, ret);
> +               goto OUT_LOAD_FW;
> +       }
> +
> +       /* Downloading data firmware to device */
> +       ret = load_requested_vpu(vpu, vpu_fw, D_FW);
> +       if (ret < 0) {
> +               dev_err(dev, "Failed to request %s, %d\n", VPU_D_FW, ret);
> +               goto OUT_LOAD_FW;
> +       }
> +
> +       /* boot up vpu */
> +       vpu_cfg_writel(vpu, 0x1, VPU_RESET);
> +
> +       ret = wait_event_interruptible_timeout(run->wq,
> +                                              run->signaled,
> +                                              msecs_to_jiffies(INIT_TIMEOUT_MS)
> +                                              );
> +       if (ret == 0) {
> +               ret = -ETIME;
> +               dev_err(dev, "wait vpu initialization timout!\n");
> +               goto OUT_LOAD_FW;
> +       } else if (-ERESTARTSYS == ret) {
> +               dev_err(dev, "wait vpu interrupted by a signal!\n");
> +               goto OUT_LOAD_FW;
> +       }
> +
> +       ret = 0;
> +       dev_info(dev, "vpu is ready. Fw version %s\n", run->fw_ver);
> +
> +OUT_LOAD_FW:
> +       vpu_clock_disable(vpu);
> +       mutex_unlock(&vpu->vpu_mutex);
> +
> +       return ret;
> +}
> +
> +int vpu_compare_version(struct platform_device *pdev,
> +                       const char *expected_version)
> +{
> +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> +       int cur_major, cur_minor, cur_build, cur_rel, cur_ver_num;
> +       int major, minor, build, rel, ver_num;
> +       char *cur_version = vpu->run.fw_ver;
> +
> +       cur_ver_num = sscanf(cur_version, "%d.%d.%d-rc%d",
> +                            &cur_major, &cur_minor, &cur_build, &cur_rel);
> +       if (cur_ver_num < 3)
> +               return -1;
> +       ver_num = sscanf(expected_version, "%d.%d.%d-rc%d",
> +                        &major, &minor, &build, &rel);
> +       if (ver_num < 3)
> +               return -1;
> +
> +       if (cur_major < major)
> +               return -1;
> +       if (cur_major > major)
> +               return 1;
> +
> +       if (cur_minor < minor)
> +               return -1;
> +       if (cur_minor > minor)
> +               return 1;
> +
> +       if (cur_build < build)
> +               return -1;
> +       if (cur_build > build)
> +               return 1;
> +
> +       if (cur_ver_num < ver_num)
> +               return -1;
> +       if (cur_ver_num > ver_num)
> +               return 1;
> +
> +       if (ver_num > 3) {
> +               if (cur_rel < rel)
> +                       return -1;
> +               if (cur_rel > rel)
> +                       return 1;
> +       }
> +
> +       return 0;
> +}
> +
> +static void vpu_init_ipi_handler(void *data, unsigned int len, void *priv)
> +{
> +       struct mtk_vpu *vpu = (struct mtk_vpu *)priv;
> +       struct vpu_run *run = (struct vpu_run *)data;
> +
> +       vpu->run.signaled = run->signaled;
> +       strncpy(vpu->run.fw_ver, run->fw_ver, VPU_FW_VER_LEN);
> +       vpu->run.enc_capability = run->enc_capability;
> +       wake_up_interruptible(&vpu->run.wq);
> +}
> +
> +#ifdef CONFIG_DEBUG_FS
> +static int vpu_debug_open(struct inode *inode, struct file *file)
> +{
> +       file->private_data = inode->i_private;
> +       return 0;
> +}
> +
> +static ssize_t vpu_debug_read(struct file *file, char __user *user_buf,
> +                             size_t count, loff_t *ppos)
> +{
> +       char buf[256];
> +       unsigned int len;
> +       unsigned int running, pc, vpu_to_host, host_to_vpu, wdt;
> +       int ret;
> +       struct device *dev = file->private_data;
> +       struct mtk_vpu *vpu = dev_get_drvdata(dev);
> +
> +       ret = vpu_clock_enable(vpu);
> +       if (ret) {
> +               dev_err(vpu->dev, "[VPU] enable clock failed %d\n", ret);
> +               return 0;
> +       }
> +
> +       /* vpu register status */
> +       running = vpu_running(vpu);
> +       pc = vpu_cfg_readl(vpu, VPU_PC_REG);
> +       wdt = vpu_cfg_readl(vpu, VPU_WDT_REG);
> +       host_to_vpu = vpu_cfg_readl(vpu, HOST_TO_VPU);
> +       vpu_to_host = vpu_cfg_readl(vpu, VPU_TO_HOST);
> +       vpu_clock_disable(vpu);
> +
> +       if (running) {
> +               len = sprintf(buf, "VPU is running\n\n"
> +               "FW Version: %s\n"
> +               "PC: 0x%x\n"
> +               "WDT: 0x%x\n"
> +               "Host to VPU: 0x%x\n"
> +               "VPU to Host: 0x%x\n",
> +               vpu->run.fw_ver, pc, wdt,
> +               host_to_vpu, vpu_to_host);
> +       } else {
> +               len = sprintf(buf, "VPU not running\n");
> +       }
> +
> +       return simple_read_from_buffer(user_buf, count, ppos, buf, len);
> +}
> +
> +static const struct file_operations vpu_debug_fops = {
> +       .open = vpu_debug_open,
> +       .read = vpu_debug_read,
> +};
> +#endif /* CONFIG_DEBUG_FS */
> +
> +static void vpu_free_ext_mem(struct mtk_vpu *vpu, u8 fw_type)
> +{
> +       struct device *dev = vpu->dev;
> +       size_t fw_ext_size = fw_type ? VPU_EXT_D_SIZE : VPU_EXT_P_SIZE;
> +
> +       dma_free_coherent(dev, fw_ext_size, vpu->extmem[fw_type].va,
> +                         vpu->extmem[fw_type].pa);
> +}
> +
> +static int vpu_alloc_ext_mem(struct mtk_vpu *vpu, u32 fw_type)
> +{
> +       struct device *dev = vpu->dev;
> +       size_t fw_ext_size = fw_type ? VPU_EXT_D_SIZE : VPU_EXT_P_SIZE;
> +       u32 vpu_ext_mem0 = fw_type ? VPU_DMEM_EXT0_ADDR : VPU_PMEM_EXT0_ADDR;
> +       u32 vpu_ext_mem1 = fw_type ? VPU_DMEM_EXT1_ADDR : VPU_PMEM_EXT1_ADDR;
> +       u32 offset_4gb = vpu->enable_4GB ? 0x40000000 : 0;
> +
> +       vpu->extmem[fw_type].va = dma_alloc_coherent(dev,
> +                                              fw_ext_size,
> +                                              &vpu->extmem[fw_type].pa,
> +                                              GFP_KERNEL);
> +       if (!vpu->extmem[fw_type].va) {
> +               dev_err(dev, "Failed to allocate the extended program memory\n");
> +               return PTR_ERR(vpu->extmem[fw_type].va);
> +       }
> +
> +       /* Disable extend0. Enable extend1 */
> +       vpu_cfg_writel(vpu, 0x1, vpu_ext_mem0);
> +       vpu_cfg_writel(vpu, (vpu->extmem[fw_type].pa & 0xFFFFF000) + offset_4gb,
> +                      vpu_ext_mem1);
> +
> +       dev_info(dev, "%s extend memory phy=0x%llx virt=0x%p\n",
> +                fw_type ? "Data" : "Program",
> +                (unsigned long long)vpu->extmem[fw_type].pa,
> +                vpu->extmem[fw_type].va);
> +
> +       return 0;
> +}
> +
> +static void vpu_ipi_handler(struct mtk_vpu *vpu)
> +{
> +       struct share_obj *rcv_obj = vpu->recv_buf;
> +       struct vpu_ipi_desc *ipi_desc = vpu->ipi_desc;
> +
> +       if (rcv_obj->id < IPI_MAX && ipi_desc[rcv_obj->id].handler) {
check rcv_obj->id >= 0
> +               ipi_desc[rcv_obj->id].handler(rcv_obj->share_buf,
> +                                             rcv_obj->len,
> +                                             ipi_desc[rcv_obj->id].priv);
> +               if (rcv_obj->id > IPI_VPU_INIT) {
> +                       vpu->ipi_id_ack[rcv_obj->id] = true;
> +                       wake_up_interruptible(&vpu->ack_wq);
> +               }
> +       } else {
> +               dev_err(vpu->dev, "No such ipi id = %d\n", rcv_obj->id);
> +       }
> +}
> +
> +static int vpu_ipi_init(struct mtk_vpu *vpu)
> +{
> +       /* Disable VPU to host interrupt */
> +       vpu_cfg_writel(vpu, 0x0, VPU_TO_HOST);
> +
> +       /* shared buffer initialization */
> +       vpu->recv_buf = (struct share_obj *)(vpu->reg.tcm + VPU_DTCM_OFFSET);
> +       vpu->send_buf = vpu->recv_buf + 1;
> +       memset(vpu->recv_buf, 0, sizeof(struct share_obj));
> +       memset(vpu->send_buf, 0, sizeof(struct share_obj));
> +       mutex_init(&vpu->vpu_mutex);
> +
> +       return 0;
> +}
> +
> +static irqreturn_t vpu_irq_handler(int irq, void *priv)
> +{
> +       struct mtk_vpu *vpu = priv;
> +       u32 vpu_to_host;
> +       int ret;
> +
> +       /*
> +        * Clock should have been enabled already.
> +        * Enable again in case vpu_ipi_send times out
> +        * and has disabled the clock.
> +        */
> +       ret = clk_enable(vpu->clk);
> +       if (ret) {
> +               dev_err(vpu->dev, "[VPU] enable clock failed %d\n", ret);
> +               return IRQ_NONE;
> +       }
> +       vpu_to_host = vpu_cfg_readl(vpu, VPU_TO_HOST);
> +       if (vpu_to_host & VPU_IPC_INT) {
> +               vpu_ipi_handler(vpu);
> +       } else {
> +               dev_err(vpu->dev, "vpu watchdog timeout! 0x%x", vpu_to_host);
> +               if (vpu->wdt.wq)
Remove. mtk_vpu_probe makes sure wdt.wq is not NULL.
> +                       queue_work(vpu->wdt.wq, &vpu->wdt.ws);
> +       }
> +
> +       /* VPU won't send another interrupt until we set VPU_TO_HOST to 0. */
> +       vpu_cfg_writel(vpu, 0x0, VPU_TO_HOST);
> +       clk_disable(vpu->clk);
> +
> +       return IRQ_HANDLED;
> +}
> +
> +#ifdef CONFIG_DEBUG_FS
> +static struct dentry *vpu_debugfs;
> +#endif
> +static int mtk_vpu_probe(struct platform_device *pdev)
> +{
> +       struct mtk_vpu *vpu;
> +       struct device *dev;
> +       struct resource *res;
> +       int ret = 0;
> +
> +       dev_dbg(&pdev->dev, "initialization\n");
> +
> +       dev = &pdev->dev;
> +       vpu = devm_kzalloc(dev, sizeof(*vpu), GFP_KERNEL);
> +       if (!vpu)
> +               return -ENOMEM;
> +
> +       vpu->dev = &pdev->dev;
> +       res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "tcm");
> +       vpu->reg.tcm = devm_ioremap_resource(dev, res);
> +       if (IS_ERR(vpu->reg.tcm)) {
> +               dev_err(dev, "devm_ioremap_resource vpu tcm failed.\n");
> +               return PTR_ERR(vpu->reg.tcm);
> +       }
> +
> +       res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg_reg");
> +       vpu->reg.cfg = devm_ioremap_resource(dev, res);
> +       if (IS_ERR(vpu->reg.cfg)) {
> +               dev_err(dev, "devm_ioremap_resource vpu cfg failed.\n");
> +               return PTR_ERR(vpu->reg.cfg);
> +       }
> +
> +       /* Get VPU clock */
> +       vpu->clk = devm_clk_get(dev, "main");
> +       if (!vpu->clk) {
> +               dev_err(dev, "get vpu clock failed\n");
> +               return -EINVAL;
> +       }
> +
> +       platform_set_drvdata(pdev, vpu);
> +
> +       ret = clk_prepare(vpu->clk);
> +       if (ret) {
> +               dev_err(dev, "prepare vpu clock failed\n");
> +               return ret;
> +       }
> +
> +       /* VPU watchdog */
> +       vpu->wdt.wq = create_singlethread_workqueue("vpu_wdt");
> +       if (!vpu->wdt.wq) {
> +               dev_err(dev, "initialize wdt workqueue failed\n");
> +               return -ENOMEM;
> +       }
> +       INIT_WORK(&vpu->wdt.ws, vpu_wdt_reset_func);
> +
> +       ret = vpu_clock_enable(vpu);
> +       if (ret) {
> +               dev_err(dev, "enable vpu clock failed\n");
> +               goto workqueue_destroy;
> +       }
> +
> +       dev_dbg(dev, "vpu ipi init\n");
> +       ret = vpu_ipi_init(vpu);
> +       if (ret) {
> +               dev_err(dev, "Failed to init ipi\n");
> +               goto disable_vpu_clk;
> +       }
> +
> +       /* register vpu initialization IPI */
> +       ret = vpu_ipi_register(pdev, IPI_VPU_INIT, vpu_init_ipi_handler,
> +                              "vpu_init", vpu);
> +       if (ret) {
> +               dev_err(dev, "Failed to register IPI_VPU_INIT\n");
> +               goto vpu_mutex_destroy;
> +       }
> +
> +#ifdef CONFIG_DEBUG_FS
> +       vpu_debugfs = debugfs_create_file("mtk_vpu", S_IRUGO, NULL, (void *)dev,
> +                                         &vpu_debug_fops);
> +       if (!vpu_debugfs) {
> +               ret = -ENOMEM;
> +               goto cleanup_ipi;
> +       }
> +#endif
> +
> +       /* Set PTCM to 96K and DTCM to 32K */
> +       vpu_cfg_writel(vpu, 0x2, VPU_TCM_CFG);
> +
> +       vpu->enable_4GB = !!(max_pfn > (0xffffffffUL >> PAGE_SHIFT));
> +       dev_dbg(dev, "4GB mode %u\n", vpu->enable_4GB);
> +
> +       if (vpu->enable_4GB) {
> +               ret = of_reserved_mem_device_init(dev);
> +               if (ret)
> +                       dev_info(dev, "init reserved memory failed\n");
> +                       /* continue to use dynamic allocation if failed */
> +       }
> +
> +       ret = vpu_alloc_ext_mem(vpu, D_FW);
> +       if (ret) {
> +               dev_err(dev, "Allocate DM failed\n");
> +               goto remove_debugfs;
> +       }
> +
> +       ret = vpu_alloc_ext_mem(vpu, P_FW);
> +       if (ret) {
> +               dev_err(dev, "Allocate PM failed\n");
> +               goto free_d_mem;
> +       }
> +
> +       init_waitqueue_head(&vpu->run.wq);
> +       init_waitqueue_head(&vpu->ack_wq);
> +
> +       res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> +       if (!res) {
> +               dev_err(dev, "get IRQ resource failed.\n");
> +               ret = -ENXIO;
> +               goto free_p_mem;
> +       }
> +       vpu->reg.irq = platform_get_irq(pdev, 0);
> +       ret = devm_request_irq(dev, vpu->reg.irq, vpu_irq_handler, 0,
> +                              pdev->name, vpu);
> +       if (ret) {
> +               dev_err(dev, "failed to request irq\n");
> +               goto free_p_mem;
> +       }
> +
> +       vpu_clock_disable(vpu);
> +       dev_dbg(dev, "initialization completed\n");
> +
> +       return 0;
> +
> +free_p_mem:
> +       vpu_free_ext_mem(vpu, P_FW);
> +free_d_mem:
> +       vpu_free_ext_mem(vpu, D_FW);
> +remove_debugfs:
> +       of_reserved_mem_device_release(dev);
> +#ifdef CONFIG_DEBUG_FS
> +       debugfs_remove(vpu_debugfs);
> +cleanup_ipi:
> +#endif
> +       memset(vpu->ipi_desc, 0, sizeof(struct vpu_ipi_desc) * IPI_MAX);
> +vpu_mutex_destroy:
> +       mutex_destroy(&vpu->vpu_mutex);
> +disable_vpu_clk:
> +       vpu_clock_disable(vpu);
> +workqueue_destroy:
> +       destroy_workqueue(vpu->wdt.wq);
> +
> +       return ret;
> +}
> +
> +static const struct of_device_id mtk_vpu_match[] = {
> +       {
> +               .compatible = "mediatek,mt8173-vpu",
> +       },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(of, mtk_vpu_match);
> +
> +static int mtk_vpu_remove(struct platform_device *pdev)
> +{
> +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> +
> +#ifdef CONFIG_DEBUG_FS
> +       debugfs_remove(vpu_debugfs);
> +#endif
> +       if (vpu->wdt.wq) {
> +               flush_workqueue(vpu->wdt.wq);
> +               destroy_workqueue(vpu->wdt.wq);
> +       }
> +       vpu_free_ext_mem(vpu, P_FW);
> +       vpu_free_ext_mem(vpu, D_FW);
> +       mutex_destroy(&vpu->vpu_mutex);
> +       clk_unprepare(vpu->clk);
> +
> +       return 0;
> +}
> +
> +static struct platform_driver mtk_vpu_driver = {
> +       .probe  = mtk_vpu_probe,
> +       .remove = mtk_vpu_remove,
> +       .driver = {
> +               .name   = "mtk_vpu",
> +               .owner  = THIS_MODULE,
> +               .of_match_table = mtk_vpu_match,
> +       },
> +};
> +
> +module_platform_driver(mtk_vpu_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("Mediatek Video Prosessor Unit driver");
> diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.h b/drivers/media/platform/mtk-vpu/mtk_vpu.h
> new file mode 100644
> index 0000000..d9c3cde
> --- /dev/null
> +++ b/drivers/media/platform/mtk-vpu/mtk_vpu.h
> @@ -0,0 +1,167 @@
> +/*
> +* Copyright (c) 2015 MediaTek Inc.
> +* Author: Andrew-CT Chen <andrew-ct.chen at mediatek.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.
> +*/
> +
> +#ifndef _MTK_VPU_H
> +#define _MTK_VPU_H
> +
> +#include <linux/platform_device.h>
> +
> +/**
> + * VPU (video processor unit) is a tiny processor controlling video hardware
> + * related to video codec, scaling and color format converting.
> + * VPU interfaces with other blocks by share memory and interrupt.
> + **/
> +
> +typedef void (*ipi_handler_t) (void *data,
> +                              unsigned int len,
> +                              void *priv);
> +
> +/**
> + * enum ipi_id - the id of inter-processor interrupt
> + *
> + * @IPI_VPU_INIT:       The interrupt from vpu is to notfiy kernel
> +                        VPU initialization completed.
> +                        IPI_VPU_INIT is sent from VPU when firmware is
> +                        loaded. AP doesn't need to send IPI_VPU_INIT
> +                        command to VPU.
> +                        For other IPI below, AP should send the request
> +                        to VPU to trigger the interrupt.
> + * @IPI_VENC_H264:      The interrupt from vpu is to notify kernel to
> +                        handle H264 video encoder job, and vice versa.
> + * @IPI_VENC_VP8:       The interrupt fro vpu is to notify kernel to
> +                        handle VP8 video encoder job,, and vice versa.
> + * @IPI_MAX:            The maximum IPI number
> + */
> +
> +enum ipi_id {
> +       IPI_VPU_INIT = 0,
> +       IPI_VENC_H264,
> +       IPI_VENC_VP8,
> +       IPI_MAX,
> +};
> +
> +/**
> + * enum rst_id - reset id to register reset function for VPU watchdog timeout
> + *
> + * @VPU_RST_DEC: decoder reset id
> + * @VPU_RST_ENC: encoder reset id
> + * @VPU_RST_MDP: MDP (Media Data Path) reset id
> + * @VPU_RST_MAX: maximum reset id
> + */
> +enum rst_id {
> +       VPU_RST_ENC,
> +       VPU_RST_DEC,
> +       VPU_RST_MDP,
> +       VPU_RST_MAX,
> +};
> +
> +/**
> + * vpu_ipi_register - register an ipi function
> + *
> + * @pdev:      VPU platform device
> + * @id:                IPI ID
> + * @handler:   IPI handler
> + * @name:      IPI name
> + * @priv:      private data for IPI handler
> + *
> + * Register an ipi function to receive ipi interrupt from VPU.
> + *
> + * Return: Return 0 if ipi registers successfully, otherwise it is failed.
> + */
> +int vpu_ipi_register(struct platform_device *pdev, enum ipi_id id,
> +                    ipi_handler_t handler, const char *name, void *priv);
> +
> +/**
> + * vpu_ipi_send - send data from AP to vpu.
> + *
> + * @pdev:      VPU platform device
> + * @id:                IPI ID
> + * @buf:       the data buffer
> + * @len:       the data buffer length
> + *
> + * This function is thread-safe. When this function returns,
> + * VPU has received the data and starts the processing.
> + * When the processing completes, IPI handler registered
> + * by vpu_ipi_register will be called in interrupt context.
> + *
> + * Return: Return 0 if sending data successfully, otherwise it is failed.
> + **/
> +int vpu_ipi_send(struct platform_device *pdev,
> +                enum ipi_id id, void *buf,
> +                unsigned int len);
> +
> +/**
> + * vpu_get_plat_device - get VPU's platform device
> + *
> + * @pdev:      the platform device of the module requesting VPU platform
> + *             device for using VPU API.
> + *
> + * Return: Return NULL if it is failed.
> + * otherwise it is VPU's platform device
> + **/
> +struct platform_device *vpu_get_plat_device(struct platform_device *pdev);
> +
> +/**
> + * vpu_wdt_reg_handler - register a VPU watchdog handler
> + *
> + * @pdev:               VPU platform device
> + * @vpu_wdt_reset_func:        the callback reset function
> + * @private_data:       the private data for reset function
> + * @rst_id:            reset id
> + *
> + * Register a handler performing own tasks when vpu reset by watchdog
> + *
> + * Return: Return 0 if the handler is added successfully,
> + * otherwise it is failed.
> + *
> + **/
> +int vpu_wdt_reg_handler(struct platform_device *pdev,
> +                       void vpu_wdt_reset_func(void *),
> +                       void *priv, enum rst_id id);
> +
> +/**
> + * vpu_get_venc_hw_capa - get video encoder hardware capability
> + *
> + * @pdev:      VPU platform device
> + *
> + * Return: video encoder hardware capability
> + **/
> +unsigned int vpu_get_venc_hw_capa(struct platform_device *pdev);
> +
> +/**
> + * vpu_load_firmware - download VPU firmware and boot it
> + *
> + * @pdev:      VPU platform device
> + *
> + * Return: Return 0 if downloading firmware successfully,
> + * otherwise it is failed
> + **/
> +int vpu_load_firmware(struct platform_device *pdev);
> +
> +/**
> + * vpu_mapping_dm_addr - Mapping DTCM/DMEM to kernel virtual address
> + *
> + * @pdev:      VPU platform device
> + * @dmem_addr: VPU's data memory address
> + *
> + * Mapping the VPU's DTCM (Data Tightly-Coupled Memory) /
> + * DMEM (Data Extended Memory) memory address to
> + * kernel virtual address.
> + *
> + * Return: Return ERR_PTR(-EINVAL) if mapping failed,
> + * otherwise the mapped kernel virtual address
> + **/
> +void *vpu_mapping_dm_addr(struct platform_device *pdev,
> +                         u32 dtcm_dmem_addr);
> +#endif /* _MTK_VPU_H */
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From jan.glauber at caviumnetworks.com  Mon Feb 15 06:07:20 2016
From: jan.glauber at caviumnetworks.com (Jan Glauber)
Date: Mon, 15 Feb 2016 15:07:20 +0100
Subject: [RFC PATCH 1/7] arm64/perf: Basic uncore counter support for
 Cavium ThunderX
In-Reply-To: <20160212173658.GD20262@leverpostej>
References: <cover.1455295032.git.jglauber@cavium.com>
 <8bd93a25e069ed6428bc6c21fc53270962ccafcc.1455295032.git.jglauber@cavium.com>
 <20160212173658.GD20262@leverpostej>
Message-ID: <20160215140720.GA4053@hardcore>

Hi Mark,

thanks for reviewing! I'll need several mails to address all questions.

On Fri, Feb 12, 2016 at 05:36:59PM +0000, Mark Rutland wrote:
> On Fri, Feb 12, 2016 at 05:55:06PM +0100, Jan Glauber wrote:
> > Provide uncore facilities for non-CPU performance counter units.
> > Based on Intel/AMD uncore pmu support.
> > 
> > The uncore PMUs can be found under /sys/bus/event_source/devices.
> > All counters are exported via sysfs in the corresponding events
> > files under the PMU directory so the perf tool can list the event names.
> 
> It turns out that "uncore" covers quite a lot of things.
> 
> Where exactly do the see counters live? system, socket, cluster?

Neither cluster nor socket, so I would say system. Where a system may
consist of 2 nodes that mostly appear as one system.

> Are there potentially multiple instances of a given PMU in the system?
> e.g. might each clutster have an instance of an L2 PMU?

Yes.

> If I turn off a set of CPUs, do any "uncore" PMUs lost context or become
> inaccessible?

No, they are not related to CPUs.

[...]

> > 
> > 1) The PMU detection solely relies on PCI device detection. If a
> >    matching PCI device is found the PMU is created. The code can deal
> >    with multiple units of the same type, e.g. more than one memory
> >    controller.
> 
> I see below that the driver has an initcall that runs regardless of
> whether the PCI device exists, and looks at the MIDR. That's clearly not
> string PCI device detection.
> 
> Why is this not a true PCI driver that only gets probed if the PCI
> device exists? 

It is not a PCI driver because there are already drivers like edac that
will access these PCI devices. The uncore driver only accesses the
performance counters, which are not used by the other drivers.

[...]

> > +#include <asm/cpufeature.h>
> > +#include <asm/cputype.h>
> 
> I don't see why you should need these two if this is truly an uncore
> device probed solely from PCI.

There are several passes of the hardware that have the same PCI device
ID. Therefore I need the CPU variant to distinguish them. This could
be done _after_ the PCI device is found but I found it easier to
implement the check once in the common setup function.

[...]

> > +int thunder_uncore_event_init(struct perf_event *event)
> > +{
> > +	struct hw_perf_event *hwc = &event->hw;
> > +	struct thunder_uncore *uncore;
> > +
> > +	if (event->attr.type != event->pmu->type)
> > +		return -ENOENT;
> > +
> > +	/* we do not support sampling */
> > +	if (is_sampling_event(event))
> > +		return -EINVAL;
> > +
> > +	/* counters do not have these bits */
> > +	if (event->attr.exclude_user	||
> > +	    event->attr.exclude_kernel	||
> > +	    event->attr.exclude_host	||
> > +	    event->attr.exclude_guest	||
> > +	    event->attr.exclude_hv	||
> > +	    event->attr.exclude_idle)
> > +		return -EINVAL;
> 
> We should _really_ make these features opt-in at the core level. It's
> crazy that each and every PMU drivers has to explicitly test and reject
> things it doesn't support.

Completely agreed. Also, every sample code I looked at did
check for other bits...

[...]

> > +
> > +	uncore = event_to_thunder_uncore(event);
> > +	if (!uncore)
> > +		return -ENODEV;
> > +	if (!uncore->event_valid(event->attr.config))
> > +		return -EINVAL;
> > +
> > +	hwc->config = event->attr.config;
> > +	hwc->idx = -1;
> > +
> > +	/* and we don't care about CPU */
> 
> Actually, you do. You want the perf core to serialize accesses via the
> same CPU, so all events _must_ be targetted at the same CPU. Otherwise
> there are a tonne of problems you don't even want to think about.

I found that perf added the events on every CPU in the system. Because
the uncore events are not CPU related I wanted to avoid this. Setting
cpumask to -1 did not work. Therefore I added a single CPU in the
cpumask, see thunder_uncore_attr_show_cpumask().

> You _must_ ensure this kernel-side, regardless of what the perf tool
> happens to do.
> 
> See the arm-cci and arm-ccn drivers for an example.
> 
> You can also follow the migration approach used there to allow you to
> retain counting across a hotplug.
> 
> [...]
> 
> > +static int __init thunder_uncore_init(void)
> > +{
> > +	unsigned long implementor = read_cpuid_implementor();
> > +	unsigned long part_number = read_cpuid_part_number();
> > +	u32 variant;
> > +
> > +	if (implementor != ARM_CPU_IMP_CAVIUM ||
> > +	    part_number != CAVIUM_CPU_PART_THUNDERX)
> > +		return -ENODEV;
> > +
> > +	/* detect pass2 which contains different counters */
> > +	variant = MIDR_VARIANT(read_cpuid_id());
> > +	if (variant == 1)
> > +		thunder_uncore_version = 1;
> > +	pr_info("PMU version: %d\n", thunder_uncore_version);
> > +
> > +	return 0;
> > +}
> 
> You should call out these differences in the commmit message.

OK

> Mark.

Thanks, Jan


From deathsimple at vodafone.de  Mon Feb 15 06:19:07 2016
From: deathsimple at vodafone.de (=?UTF-8?Q?Christian_K=c3=b6nig?=)
Date: Mon, 15 Feb 2016 15:19:07 +0100
Subject: [PATCH v2 00/17] drm encoders cleanup: nuke optional dummy
 encoder mode_fixup function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <56C1DE5B.4010909@vodafone.de>

Am 15.02.2016 um 13:57 schrieb Carlos Palminha:
> mode_fixup function for encoder drivers became optional with patch
> http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com
>
> This patch set nukes all the dummy mode_fixup implementations.
>
> (made on top of Daniel topic/drm-misc branch)
>
> Changes v1->v2: incorporated Daniel comments
> * added signed-off-by line to all patches
> * threading enabled due to e-mail server constraints
> * common blurb lines to all patches
> * add reviewed by Alex, to patches 4 and 14

You can add a Reviewed-by: Christian K?nig <christian.koenig at amd.com> to 
patch 4 and 14 as well.

Nice cleanup. Thanks,
Christian.

>
> Carlos Palminha (17):
>    drm/virtio: removed optional dummy encoder mode_fixup function.
>    drm/udl: removed optional dummy encoder mode_fixup function.
>    drm/exynos: removed optional dummy encoder mode_fixup function.
>    drm/amdgpu: removed optional dummy encoder mode_fixup function.
>    drm/ast: removed optional dummy encoder mode_fixup function.
>    drm/bochs: removed optional dummy encoder mode_fixup function.
>    drm/cirrus: removed optional dummy encoder mode_fixup function.
>    drm/exynos: removed optional dummy encoder mode_fixup function.
>    drm/gma500: removed optional dummy encoder mode_fixup function.
>    drm/imx: removed optional dummy encoder mode_fixup function.
>    drm/msm/mdp: removed optional dummy encoder mode_fixup function.
>    drm/mgag200: removed optional dummy encoder mode_fixup function.
>    drm/qxl: removed optional dummy encoder mode_fixup function.
>    drm/radeon: removed optional dummy encoder mode_fixup function.
>    drm/rockchip: removed optional dummy encoder mode_fixup function.
>    drm/sti: removed optional dummy encoder mode_fixup function.
>    drm/tilcdc: removed optional dummy encoder mode_fixup function.
>
>   drivers/gpu/drm/amd/amdgpu/dce_v10_0.c           |  8 --------
>   drivers/gpu/drm/amd/amdgpu/dce_v11_0.c           |  8 --------
>   drivers/gpu/drm/amd/amdgpu/dce_v8_0.c            |  8 --------
>   drivers/gpu/drm/ast/ast_mode.c                   |  8 --------
>   drivers/gpu/drm/bochs/bochs_kms.c                |  8 --------
>   drivers/gpu/drm/cirrus/cirrus_mode.c             |  9 ---------
>   drivers/gpu/drm/exynos/exynos_dp_core.c          |  8 --------
>   drivers/gpu/drm/exynos/exynos_drm_dpi.c          |  8 --------
>   drivers/gpu/drm/exynos/exynos_drm_dsi.c          |  8 --------
>   drivers/gpu/drm/exynos/exynos_drm_vidi.c         |  8 --------
>   drivers/gpu/drm/gma500/cdv_intel_crt.c           |  1 -
>   drivers/gpu/drm/gma500/cdv_intel_hdmi.c          |  1 -
>   drivers/gpu/drm/gma500/gma_display.c             |  7 -------
>   drivers/gpu/drm/gma500/gma_display.h             |  3 ---
>   drivers/gpu/drm/gma500/oaktrail_hdmi.c           |  1 -
>   drivers/gpu/drm/imx/dw_hdmi-imx.c                |  8 --------
>   drivers/gpu/drm/imx/imx-ldb.c                    |  8 --------
>   drivers/gpu/drm/imx/imx-tve.c                    |  8 --------
>   drivers/gpu/drm/imx/parallel-display.c           |  8 --------
>   drivers/gpu/drm/mgag200/mgag200_mode.c           |  8 --------
>   drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c  |  8 --------
>   drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c  |  8 --------
>   drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c |  8 --------
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c  |  9 ---------
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c      |  8 --------
>   drivers/gpu/drm/qxl/qxl_display.c                |  9 ---------
>   drivers/gpu/drm/radeon/atombios_encoders.c       |  8 --------
>   drivers/gpu/drm/rockchip/dw-mipi-dsi.c           |  8 --------
>   drivers/gpu/drm/sti/sti_tvout.c                  | 10 ----------
>   drivers/gpu/drm/tilcdc/tilcdc_panel.c            |  9 ---------
>   drivers/gpu/drm/tilcdc/tilcdc_tfp410.c           |  9 ---------
>   drivers/gpu/drm/udl/udl_encoder.c                |  8 --------
>   drivers/gpu/drm/virtio/virtgpu_display.c         |  8 --------
>   33 files changed, 244 deletions(-)
>



From oberpar at linux.vnet.ibm.com  Mon Feb 15 06:23:19 2016
From: oberpar at linux.vnet.ibm.com (Peter Oberparleiter)
Date: Mon, 15 Feb 2016 15:23:19 +0100
Subject: [PATCH 3/5] gcov: disable for COMPILE_TEST
In-Reply-To: <1455293187-179811-4-git-send-email-arnd@arndb.de>
References: <1455293187-179811-1-git-send-email-arnd@arndb.de>
 <1455293187-179811-4-git-send-email-arnd@arndb.de>
Message-ID: <56C1DF57.50601@linux.vnet.ibm.com>

On 12.02.2016 17:06, Arnd Bergmann wrote:
> Enabling gcov is counterproductive to compile testing: it significantly
> increases the kernel image size, compile time, and it produces lots
> of false positive "may be used uninitialized" warnings as the result
> of missed optimizations.
> 
> This is in line with how UBSAN_SANITIZE_ALL and PROFILE_ALL_BRANCHES
> work, both of which have similar problems.
> 
> With an ARM allmodconfig kernel, I see the build time drop from
> 283 minutes CPU time to 225 minutes, and the vmlinux size drops
> from 43MB to 26MB.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Agreed that COMPILE_TEST + GCOV_PROFILE_ALL is a very exotic combination
with little added use.

Acked-by: Peter Oberparleiter <oberpar at linux.vnet.ibm.com>

> ---
>  kernel/gcov/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/gcov/Kconfig b/kernel/gcov/Kconfig
> index c92e44855ddd..1276aabaab55 100644
> --- a/kernel/gcov/Kconfig
> +++ b/kernel/gcov/Kconfig
> @@ -37,6 +37,7 @@ config ARCH_HAS_GCOV_PROFILE_ALL
> 
>  config GCOV_PROFILE_ALL
>  	bool "Profile entire Kernel"
> +	depends on !COMPILE_TEST
>  	depends on GCOV_KERNEL
>  	depends on ARCH_HAS_GCOV_PROFILE_ALL
>  	default n
> 


-- 
Peter Oberparleiter
Linux on z Systems Development - IBM Germany



From patrik.r.jakobsson at gmail.com  Mon Feb 15 06:24:01 2016
From: patrik.r.jakobsson at gmail.com (Patrik Jakobsson)
Date: Mon, 15 Feb 2016 15:24:01 +0100
Subject: [PATCH v2 09/17] drm/gma500: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <b704458dc68a73cfb5507933c1df0c2a79e186eb.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
 <b704458dc68a73cfb5507933c1df0c2a79e186eb.1455540137.git.palminha@synopsys.com>
Message-ID: <CAMeQTsZ=JP36ry8u_WAWgjz4sa4SPSpQmq3n+dACq0JhHonVSw@mail.gmail.com>

On Mon, Feb 15, 2016 at 2:00 PM, Carlos Palminha
<CARLOS.PALMINHA at synopsys.com> wrote:
> mode_fixup function for encoder drivers became optional with patch
> http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com
>
> This patch set nukes all the dummy mode_fixup implementations.
>
> (made on top of Daniel topic/drm-misc branch)
>
> Signed-off-by: Carlos Palminha <palminha at synopsys.com>

Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson at gmail.com>

> ---
>  drivers/gpu/drm/gma500/cdv_intel_crt.c  | 1 -
>  drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 1 -
>  drivers/gpu/drm/gma500/gma_display.c    | 7 -------
>  drivers/gpu/drm/gma500/gma_display.h    | 3 ---
>  drivers/gpu/drm/gma500/oaktrail_hdmi.c  | 1 -
>  5 files changed, 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c b/drivers/gpu/drm/gma500/cdv_intel_crt.c
> index d0717a8..b837e7a 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
> @@ -217,7 +217,6 @@ static int cdv_intel_crt_set_property(struct drm_connector *connector,
>
>  static const struct drm_encoder_helper_funcs cdv_intel_crt_helper_funcs = {
>         .dpms = cdv_intel_crt_dpms,
> -       .mode_fixup = gma_encoder_mode_fixup,
>         .prepare = gma_encoder_prepare,
>         .commit = gma_encoder_commit,
>         .mode_set = cdv_intel_crt_mode_set,
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
> index ddf2d77..28f9d90 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
> @@ -255,7 +255,6 @@ static void cdv_hdmi_destroy(struct drm_connector *connector)
>
>  static const struct drm_encoder_helper_funcs cdv_hdmi_helper_funcs = {
>         .dpms = cdv_hdmi_dpms,
> -       .mode_fixup = gma_encoder_mode_fixup,
>         .prepare = gma_encoder_prepare,
>         .mode_set = cdv_hdmi_mode_set,
>         .commit = gma_encoder_commit,
> diff --git a/drivers/gpu/drm/gma500/gma_display.c b/drivers/gpu/drm/gma500/gma_display.c
> index ff17af4..9270821 100644
> --- a/drivers/gpu/drm/gma500/gma_display.c
> +++ b/drivers/gpu/drm/gma500/gma_display.c
> @@ -478,13 +478,6 @@ int gma_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
>         return 0;
>  }
>
> -bool gma_encoder_mode_fixup(struct drm_encoder *encoder,
> -                           const struct drm_display_mode *mode,
> -                           struct drm_display_mode *adjusted_mode)
> -{
> -       return true;
> -}
> -
>  bool gma_crtc_mode_fixup(struct drm_crtc *crtc,
>                          const struct drm_display_mode *mode,
>                          struct drm_display_mode *adjusted_mode)
> diff --git a/drivers/gpu/drm/gma500/gma_display.h b/drivers/gpu/drm/gma500/gma_display.h
> index ed569d8..78b9f98 100644
> --- a/drivers/gpu/drm/gma500/gma_display.h
> +++ b/drivers/gpu/drm/gma500/gma_display.h
> @@ -90,9 +90,6 @@ extern void gma_crtc_restore(struct drm_crtc *crtc);
>  extern void gma_encoder_prepare(struct drm_encoder *encoder);
>  extern void gma_encoder_commit(struct drm_encoder *encoder);
>  extern void gma_encoder_destroy(struct drm_encoder *encoder);
> -extern bool gma_encoder_mode_fixup(struct drm_encoder *encoder,
> -                                  const struct drm_display_mode *mode,
> -                                  struct drm_display_mode *adjusted_mode);
>
>  /* Common clock related functions */
>  extern const struct gma_limit_t *gma_limit(struct drm_crtc *crtc, int refclk);
> diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
> index 2d18499..8b2eb32 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
> @@ -601,7 +601,6 @@ static void oaktrail_hdmi_destroy(struct drm_connector *connector)
>
>  static const struct drm_encoder_helper_funcs oaktrail_hdmi_helper_funcs = {
>         .dpms = oaktrail_hdmi_dpms,
> -       .mode_fixup = gma_encoder_mode_fixup,
>         .prepare = gma_encoder_prepare,
>         .mode_set = oaktrail_hdmi_mode_set,
>         .commit = gma_encoder_commit,
> --
> 2.5.0
>


From wens at csie.org  Mon Feb 15 06:23:48 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 22:23:48 +0800
Subject: [linux-sunxi] Allwinner A64 MMC support
In-Reply-To: <56C1D9C0.6020601@arm.com>
References: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
 <56BE29A1.3060107@redhat.com> <56C1A590.6030500@arm.com>
 <56C1C7BB.1040602@redhat.com> <56C1D9C0.6020601@arm.com>
Message-ID: <CAGb2v65E54mnLEcPzLyycEBSHbvn6tp9JpS+S8gdbDg_e7qFyQ@mail.gmail.com>

On Mon, Feb 15, 2016 at 9:59 PM, Andre Przywara <andre.przywara at arm.com> wrote:
> Hi Hans,
>
> ....
>
>>
>> p.s.
>>
>> I love the work you've been doing on the A64, I've not had a chance
>> to try it out yet though. Have you made any progress with getting
>> the mmc slot to work ?  If not maybe I can make some time I've
>> prior experience in bringing up the mmc slot on other Allwinner SoCs
>
> Thanks for that!
>
> So we made some progress on the weekend (with the help of #linux-sunxi):
> 1) The regulator node was stupidly put by me into a separate child node
> without putting address and size cells into. So I just moved it into
> /soc directly now and that seems to fixed the missing regulator.
> 2) The reset node is a allwinner,sun6i-a31-ahb1-reset, which does not
> get registered automatically, but by an explicit call from mach-sunxi/.
> I wonder why we do this (yes, I saw that comment, but still...) and if
> it would work with a normal MODULE_DEVICE_TABLE() declaration.
> There is and will be no equivalent to the mach- directory on arm64.

On sun6i, we supported the high resolution timer, which had a reset control.
Timers (or clocksources) are registered before device model kicks in, so the
reset had to be explicitly registered before the timer, or the system would
hang. I think we phased that out though. Maxime should know.

ChenYu

> 3) As Jens pointed out, the MMC IP block isn't really compatible.
> Changing the clocks is easy (done already), but we need to come up with
> code to cover the new phase setting registers in the A64 MMC register block.
>
> Interestingly somehow hacking this (pretending it is compatible) seems
> to work, though I got reports from people about mysterious kernel
> crashes, so I'm inclined to leave MMC out of the first patch series.
>
> So if you could take a look at the new registers (starting at offset
> 0x140) and work out what we actually need to do here, that would be
> great. I have no real clue about what they actually do and how they
> relate to the current output and sample clock phase.
> To me it looks like we might get away with just triggering the automatic
> calibration and the hardware does the rest for us - keep your fingers
> crossed ;-)
>
> Cheers,
> Andre.
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


From aryabinin at virtuozzo.com  Mon Feb 15 06:28:02 2016
From: aryabinin at virtuozzo.com (Andrey Ryabinin)
Date: Mon, 15 Feb 2016 17:28:02 +0300
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
Message-ID: <56C1E072.2090909@virtuozzo.com>



On 02/12/2016 07:06 PM, Catalin Marinas wrote:
> On Fri, Feb 12, 2016 at 03:38:46PM +0000, Sudeep Holla wrote:
>>
>> On 12/02/16 15:26, Catalin Marinas wrote:
>>> On Fri, Feb 12, 2016 at 04:17:09PM +0100, Ard Biesheuvel wrote:
>>>> On 12 February 2016 at 16:10, Catalin Marinas <catalin.marinas at arm.com> wrote:
>>>>> On Fri, Feb 12, 2016 at 04:02:58PM +0100, Ard Biesheuvel wrote:
>>>>>> On 12 February 2016 at 15:58, Catalin Marinas <catalin.marinas at arm.com> wrote:
>>>>>>> On Mon, Feb 01, 2016 at 11:54:52AM +0100, Ard Biesheuvel wrote:
>>>>>>>> This moves the module area to right before the vmalloc area, and
>>>>>>>> moves the kernel image to the base of the vmalloc area. This is
>>>>>>>> an intermediate step towards implementing KASLR, which allows the
>>>>>>>> kernel image to be located anywhere in the vmalloc area.
>>>>>>>>
>>>>>>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>>>>>>>
>>>>>>> This patch is causing lots of KASAN warnings on Juno (interestingly, it
>>>>>>> doesn't seem to trigger on Seattle, though we only tried for-next/core).
>>>>>>> I pushed the branch that I'm currently using here:
>>>>>>>
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux for-next/kernmap
>>>>>>>
>>>>>>>
>>>>>>> A typical error (though its place varies based on the config options,
>>>>>>> kernel layout):
>>>>>>>
>>>>>>> BUG: KASAN: stack-out-of-bounds in clockevents_program_event+0x28/0x1b0 at addr ffffffc936257cc8
>>>>>>
>>>>>> Can you confirm that these are stack accesses? I was having similar
>>>>>> errors before, and I ended up creating the kasan zero page patch
>>>>>> because it turned out the kasan shadow page in question was aliased
>>>>>> and the stack writes were occurring elsewhere.
>>>>>
>>>>> It's possible, we are looking into this. Is there any other patch I miss on
>>>>> the above branch?
>>>>
>>>> I don't think so but I will check
>>>
>>> Commit 7b1af9795773 ("arm64: kasan: ensure that the KASAN zero page is
>>> mapped read-only") was merged in -rc2 while the branch above is based on
>>> -rc1. Anyway, I merged it into -rc2 and the errors are similar.
>>>
>>
>> Sorry to add more confusion, but I observed similar KASAN warning
>> with latest mainline(v4.5-rc3+, commit c05235d50f68) with below diff.
> 
> I can reproduce this with UBSAN enabled (log below for the record).
> 
> So far, we have:
> 
> KASAN+for-next/kernmap goes wrong
> KASAN+UBSAN goes wrong
> 
> Enabled individually, KASAN, UBSAN and for-next/kernmap seem fine. I may
> have to trim for-next/core down until we figure out where the problem
> is.
> 
> 
> BUG: KASAN: stack-out-of-bounds in find_busiest_group+0x164/0x16a0 at addr ffffffc93665bc8c


Can it be related to TLB conflicts, which supposed to be fixed in "arm64: kasan: avoid TLB conflicts" patch
from "arm64: mm: rework page table creation" series ?




From mark.rutland at arm.com  Mon Feb 15 06:27:27 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 15 Feb 2016 14:27:27 +0000
Subject: [RFC PATCH 1/7] arm64/perf: Basic uncore counter support for
 Cavium ThunderX
In-Reply-To: <20160215140720.GA4053@hardcore>
References: <cover.1455295032.git.jglauber@cavium.com>
 <8bd93a25e069ed6428bc6c21fc53270962ccafcc.1455295032.git.jglauber@cavium.com>
 <20160212173658.GD20262@leverpostej>
 <20160215140720.GA4053@hardcore>
Message-ID: <20160215142726.GD9732@leverpostej>

On Mon, Feb 15, 2016 at 03:07:20PM +0100, Jan Glauber wrote:
> Hi Mark,
> 
> thanks for reviewing! I'll need several mails to address all questions.
> 
> On Fri, Feb 12, 2016 at 05:36:59PM +0000, Mark Rutland wrote:
> > On Fri, Feb 12, 2016 at 05:55:06PM +0100, Jan Glauber wrote:
> > > Provide uncore facilities for non-CPU performance counter units.
> > > Based on Intel/AMD uncore pmu support.
> > > 
> > > The uncore PMUs can be found under /sys/bus/event_source/devices.
> > > All counters are exported via sysfs in the corresponding events
> > > files under the PMU directory so the perf tool can list the event names.
> > 
> > It turns out that "uncore" covers quite a lot of things.
> > 
> > Where exactly do the see counters live? system, socket, cluster?
> 
> Neither cluster nor socket, so I would say system. Where a system may
> consist of 2 nodes that mostly appear as one system.
> 
> > Are there potentially multiple instances of a given PMU in the system?
> > e.g. might each clutster have an instance of an L2 PMU?
> 
> Yes.
> 
> > If I turn off a set of CPUs, do any "uncore" PMUs lost context or become
> > inaccessible?
> 
> No, they are not related to CPUs.

Ok. So I should be able to concurrently hotplug random CPUs on/off while
this driver is running, without issues? No registers might be
clock-gated or similar?

I appreciate that they are not "related" to particular CPUs as such.

> > > 1) The PMU detection solely relies on PCI device detection. If a
> > >    matching PCI device is found the PMU is created. The code can deal
> > >    with multiple units of the same type, e.g. more than one memory
> > >    controller.
> > 
> > I see below that the driver has an initcall that runs regardless of
> > whether the PCI device exists, and looks at the MIDR. That's clearly not
> > string PCI device detection.
> > 
> > Why is this not a true PCI driver that only gets probed if the PCI
> > device exists? 
> 
> It is not a PCI driver because there are already drivers like edac that
> will access these PCI devices. The uncore driver only accesses the
> performance counters, which are not used by the other drivers.

Several drivers are accessing the same device?

That sounds somewhat scary.

> > > +#include <asm/cpufeature.h>
> > > +#include <asm/cputype.h>
> > 
> > I don't see why you should need these two if this is truly an uncore
> > device probed solely from PCI.
> 
> There are several passes of the hardware that have the same PCI device
> ID. Therefore I need the CPU variant to distinguish them. This could
> be done _after_ the PCI device is found but I found it easier to
> implement the check once in the common setup function.

Ok. Please call that out in the commit message.

> > > +int thunder_uncore_event_init(struct perf_event *event)
> > > +{
> > > +	struct hw_perf_event *hwc = &event->hw;
> > > +	struct thunder_uncore *uncore;
> > > +
> > > +	if (event->attr.type != event->pmu->type)
> > > +		return -ENOENT;
> > > +
> > > +	/* we do not support sampling */
> > > +	if (is_sampling_event(event))
> > > +		return -EINVAL;
> > > +
> > > +	/* counters do not have these bits */
> > > +	if (event->attr.exclude_user	||
> > > +	    event->attr.exclude_kernel	||
> > > +	    event->attr.exclude_host	||
> > > +	    event->attr.exclude_guest	||
> > > +	    event->attr.exclude_hv	||
> > > +	    event->attr.exclude_idle)
> > > +		return -EINVAL;
> > 
> > We should _really_ make these features opt-in at the core level. It's
> > crazy that each and every PMU drivers has to explicitly test and reject
> > things it doesn't support.
> 
> Completely agreed. Also, every sample code I looked at did
> check for other bits...
> 
> [...]
> 
> > > +
> > > +	uncore = event_to_thunder_uncore(event);
> > > +	if (!uncore)
> > > +		return -ENODEV;
> > > +	if (!uncore->event_valid(event->attr.config))
> > > +		return -EINVAL;
> > > +
> > > +	hwc->config = event->attr.config;
> > > +	hwc->idx = -1;
> > > +
> > > +	/* and we don't care about CPU */
> > 
> > Actually, you do. You want the perf core to serialize accesses via the
> > same CPU, so all events _must_ be targetted at the same CPU. Otherwise
> > there are a tonne of problems you don't even want to think about.
> 
> I found that perf added the events on every CPU in the system. Because
> the uncore events are not CPU related I wanted to avoid this. Setting
> cpumask to -1 did not work. Therefore I added a single CPU in the
> cpumask, see thunder_uncore_attr_show_cpumask().

I understand that, which is why I wrote:

> > You _must_ ensure this kernel-side, regardless of what the perf tool
> > happens to do.
> > 
> > See the arm-cci and arm-ccn drivers for an example.

Take a look at drivers/bus/arm-cci.c; specifically, what we do in
cci_pmu_event_init and cci_pmu_cpu_notifier.

This is the same thing that's done for x86 system PMUs. Take a look at
uncore_pmu_event_init in arch/x86/kernel/cpu/perf_event_intel_uncore.c.

Otherwise there are a number of situations where userspace might open
events on different CPUs, and you get some freaky results because the
perf core expects accesses to a PMU and its related data structures to
be strictly serialised through _some_ CPU (even if that CPU is
arbitrarily chosen).

For example, if CPU 0 was offline when one event was opened, then cpu0
was hotplugged, then a second event was opened, there would be an event
in the CPU1 context and another in the CPU0 context. Modification to the
PMU state is done per CPU-context in the core, and these would race
against each other given the lack of serialisation. Even with sufficient
locking to prevent outright corruption, things like event rotation would
race leading to very non-deterministic results.

Thanks,
Mark.


From oberpar at linux.vnet.ibm.com  Mon Feb 15 06:34:21 2016
From: oberpar at linux.vnet.ibm.com (Peter Oberparleiter)
Date: Mon, 15 Feb 2016 15:34:21 +0100
Subject: [PATCH 4/5] gcov: disable tree-loop-im to reduce stack usage
In-Reply-To: <1455293187-179811-5-git-send-email-arnd@arndb.de>
References: <1455293187-179811-1-git-send-email-arnd@arndb.de>
 <1455293187-179811-5-git-send-email-arnd@arndb.de>
Message-ID: <56C1E1ED.1020205@linux.vnet.ibm.com>

On 12.02.2016 17:06, Arnd Bergmann wrote:
> Enabling CONFIG_GCOV_PROFILE_ALL produces us a lot of warnings like
> 
> lib/lz4/lz4hc_compress.c: In function 'lz4_compresshcctx':
> lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1504 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> 
> After some investigation, I found that this behavior started with gcc-4.9,
> and opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702.
> A suggested workaround for it is to use the -fno-tree-loop-im
> flag that turns off one of the optimization stages in gcc, so the
> code runs a little slower but does not use excessive amounts
> of stack.
> 
> We could make this conditional on the gcc version, but I could not
> find an easy way to do this in Kbuild and the benefit would be
> fairly small, given that most of the gcc version in production are
> affected now.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

-fno-tree-loop-im seems to have been available for long enough in GCC
(starting with GCC4) to make this part of the default gcov compile flags.

Acked-by: Peter Oberparleiter <oberpar at linux.vnet.ibm.com>

> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index 352f55ccc54e..6bb89728a9d1 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -364,7 +364,7 @@ AFLAGS_MODULE   =
>  LDFLAGS_MODULE  =
>  CFLAGS_KERNEL	=
>  AFLAGS_KERNEL	=
> -CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage
> +CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage -fno-tree-loop-im
>  CFLAGS_KCOV	= -fsanitize-coverage=trace-pc
> 
> 


-- 
Peter Oberparleiter
Linux on z Systems Development - IBM Germany



From oberpar at linux.vnet.ibm.com  Mon Feb 15 06:35:21 2016
From: oberpar at linux.vnet.ibm.com (Peter Oberparleiter)
Date: Mon, 15 Feb 2016 15:35:21 +0100
Subject: [PATCH 5/5] gcov: disable -Wmaybe-uninitialized warning
In-Reply-To: <1455293187-179811-6-git-send-email-arnd@arndb.de>
References: <1455293187-179811-1-git-send-email-arnd@arndb.de>
 <1455293187-179811-6-git-send-email-arnd@arndb.de>
Message-ID: <56C1E229.4050308@linux.vnet.ibm.com>

On 12.02.2016 17:06, Arnd Bergmann wrote:
> When gcov profiling is enabled, we see a lot of spurious warnings about
> possibly uninitialized variables being used:
> 
> arch/arm/mm/dma-mapping.c: In function 'arm_coherent_iommu_map_page':
> arch/arm/mm/dma-mapping.c:1085:16: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/clk/st/clk-flexgen.c: In function 'st_of_flexgen_setup':
> drivers/clk/st/clk-flexgen.c:323:9: warning: 'num_parents' may be used uninitialized in this function [-Wmaybe-uninitialized]
> kernel/cgroup.c: In function 'cgroup_mount':
> kernel/cgroup.c:2119:11: warning: 'root' may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> All of these are false positives, so it seems better to just disable
> the warnings whenever GCOV is enabled. Most users don't enable GCOV,
> and based on a prior patch, it is now also disabled for 'allmodconfig'
> builds, so there should be no downsides of doing this.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Sounds sane.

Acked-by: Peter Oberparleiter <oberpar at linux.vnet.ibm.com>

> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index 6bb89728a9d1..7b6900931a47 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -364,7 +364,7 @@ AFLAGS_MODULE   =
>  LDFLAGS_MODULE  =
>  CFLAGS_KERNEL	=
>  AFLAGS_KERNEL	=
> -CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage -fno-tree-loop-im
> +CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage -fno-tree-loop-im -Wno-maybe-uninitialized
>  CFLAGS_KCOV	= -fsanitize-coverage=trace-pc
> 
> 


-- 
Peter Oberparleiter
Linux on z Systems Development - IBM Germany



From mark.rutland at arm.com  Mon Feb 15 06:35:09 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 15 Feb 2016 14:35:09 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <56C1E072.2090909@virtuozzo.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
Message-ID: <20160215143509.GE9732@leverpostej>

On Mon, Feb 15, 2016 at 05:28:02PM +0300, Andrey Ryabinin wrote:
> 
> 
> On 02/12/2016 07:06 PM, Catalin Marinas wrote:
> > So far, we have:
> > 
> > KASAN+for-next/kernmap goes wrong
> > KASAN+UBSAN goes wrong
> > 
> > Enabled individually, KASAN, UBSAN and for-next/kernmap seem fine. I may
> > have to trim for-next/core down until we figure out where the problem
> > is.
> > 
> > BUG: KASAN: stack-out-of-bounds in find_busiest_group+0x164/0x16a0 at addr ffffffc93665bc8c
> 
> Can it be related to TLB conflicts, which supposed to be fixed in "arm64: kasan: avoid TLB conflicts" patch
> from "arm64: mm: rework page table creation" series ?

Currently I don't believe this is a TLB issue. We've been seeing issues
even with those patches in for-next/core with that patch included. It's
also incredibly reliable to trigger.

It seems that issues are more likely the larger the kernel image, so my
suspicion is that at some boundary condition we create the page tables
for the shadow region incorrectly. I'm only able to trigger this on a
particular machine, so the physical memory layout may also matter.

I'm currently looking into that.

Mark.


From andre.przywara at arm.com  Mon Feb 15 06:36:00 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 15 Feb 2016 14:36:00 +0000
Subject: [linux-sunxi] Allwinner A64 MMC support
In-Reply-To: <CAGb2v65E54mnLEcPzLyycEBSHbvn6tp9JpS+S8gdbDg_e7qFyQ@mail.gmail.com>
References: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
 <56BE29A1.3060107@redhat.com> <56C1A590.6030500@arm.com>
 <56C1C7BB.1040602@redhat.com> <56C1D9C0.6020601@arm.com>
 <CAGb2v65E54mnLEcPzLyycEBSHbvn6tp9JpS+S8gdbDg_e7qFyQ@mail.gmail.com>
Message-ID: <56C1E250.9070301@arm.com>

Hi Chen-Yu,

On 15/02/16 14:23, Chen-Yu Tsai wrote:
> On Mon, Feb 15, 2016 at 9:59 PM, Andre Przywara <andre.przywara at arm.com> wrote:
>> Hi Hans,
>>
>> ....
>>
>>>
>>> p.s.
>>>
>>> I love the work you've been doing on the A64, I've not had a chance
>>> to try it out yet though. Have you made any progress with getting
>>> the mmc slot to work ?  If not maybe I can make some time I've
>>> prior experience in bringing up the mmc slot on other Allwinner SoCs
>>
>> Thanks for that!
>>
>> So we made some progress on the weekend (with the help of #linux-sunxi):
>> 1) The regulator node was stupidly put by me into a separate child node
>> without putting address and size cells into. So I just moved it into
>> /soc directly now and that seems to fixed the missing regulator.
>> 2) The reset node is a allwinner,sun6i-a31-ahb1-reset, which does not
>> get registered automatically, but by an explicit call from mach-sunxi/.
>> I wonder why we do this (yes, I saw that comment, but still...) and if
>> it would work with a normal MODULE_DEVICE_TABLE() declaration.
>> There is and will be no equivalent to the mach- directory on arm64.
> 
> On sun6i, we supported the high resolution timer, which had a reset control.
> Timers (or clocksources) are registered before device model kicks in, so the
> reset had to be explicitly registered before the timer, or the system would
> hang. I think we phased that out though. Maxime should know.

Ah, thanks for that insight!
So that sounds like we would get away with a normal registration for the
A64 - and actually many other SoCs as well?
Shall we guard the explicit sun6i_reset_init with MACH_SUN6I or
something and do the normal registration otherwise?
Or do I miss something here?

Cheers,
Andre

>> 3) As Jens pointed out, the MMC IP block isn't really compatible.
>> Changing the clocks is easy (done already), but we need to come up with
>> code to cover the new phase setting registers in the A64 MMC register block.
>>
>> Interestingly somehow hacking this (pretending it is compatible) seems
>> to work, though I got reports from people about mysterious kernel
>> crashes, so I'm inclined to leave MMC out of the first patch series.
>>
>> So if you could take a look at the new registers (starting at offset
>> 0x140) and work out what we actually need to do here, that would be
>> great. I have no real clue about what they actually do and how they
>> relate to the current output and sample clock phase.
>> To me it looks like we might get away with just triggering the automatic
>> calibration and the hardware does the rest for us - keep your fingers
>> crossed ;-)
>>
>> Cheers,
>> Andre.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 


From a.hajda at samsung.com  Mon Feb 15 06:35:18 2016
From: a.hajda at samsung.com (Andrzej Hajda)
Date: Mon, 15 Feb 2016 15:35:18 +0100
Subject: [PATCH 0/7] fix IS_ERR_VALUE usage
Message-ID: <1455546925-22119-1-git-send-email-a.hajda@samsung.com>

Hi,

This small set of independent patches tries to fix incorrect
IS_ERR_VALUE macro usage. It fixes most usages leading to errors
as described in [1]. It also follows conclusion from the discussion
[1][2] - IS_ERR_VALUE should be used only with unsigned long type,
signed types should use comparison 'ret < 0'.

The patchset does not fix errors present in net/ethernet/freescale
and soc/fsq/qe drivers - these drivers mixes different types:
dma_addr_t, u32, unsigned long, fixing it properly seems to me more
challenging, maybe maintainers or brave volunteers can look it.

The list of missing fixes:
drivers/net/ethernet/freescale/fs_enet/mac-scc.c:149:36-37: WARNING: incorrect argument type in IS_ERR_VALUE(fep -> ring_mem_addr)
drivers/net/ethernet/freescale/ucc_geth.c:2237:48-49: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> tx_bd_ring_offset [ j ])
drivers/net/ethernet/freescale/ucc_geth.c:2314:48-49: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> rx_bd_ring_offset [ j ])
drivers/net/ethernet/freescale/ucc_geth.c:2524:44-45: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> tx_glbl_pram_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2544:45-46: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> thread_dat_tx_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2571:46-47: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> send_q_mem_reg_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2612:42-43: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> scheduler_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2659:54-55: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> tx_fw_statistics_pram_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2696:44-45: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> rx_glbl_pram_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2715:45-46: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> thread_dat_rx_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2736:54-55: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> rx_fw_statistics_pram_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2756:53-54: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> rx_irq_coalescing_tbl_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2822:44-45: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> rx_bd_qs_tbl_offset)
drivers/net/ethernet/freescale/ucc_geth.c:2908:47-48: WARNING: incorrect argument type in IS_ERR_VALUE(ugeth -> exf_glbl_param_offset)
drivers/net/ethernet/freescale/ucc_geth.c:292:36-37: WARNING: incorrect argument type in IS_ERR_VALUE(init_enet_offset)
drivers/net/ethernet/freescale/ucc_geth.c:3042:39-40: WARNING: incorrect argument type in IS_ERR_VALUE(init_enet_pram_offset)
drivers/soc/fsl/qe/ucc_fast.c:271:60-61: WARNING: incorrect argument type in IS_ERR_VALUE(uccf -> ucc_fast_tx_virtual_fifo_base_offset)
drivers/soc/fsl/qe/ucc_fast.c:284:60-61: WARNING: incorrect argument type in IS_ERR_VALUE(uccf -> ucc_fast_rx_virtual_fifo_base_offset)
drivers/soc/fsl/qe/ucc_slow.c:186:38-39: WARNING: incorrect argument type in IS_ERR_VALUE(uccs -> us_pram_offset)
drivers/soc/fsl/qe/ucc_slow.c:213:38-39: WARNING: incorrect argument type in IS_ERR_VALUE(uccs -> rx_base_offset)
drivers/soc/fsl/qe/ucc_slow.c:224:38-39: WARNING: incorrect argument type in IS_ERR_VALUE(uccs -> tx_base_offset)
drivers/net/ethernet/freescale/fs_enet/mac-fcc.c:110:35-36: WARNING: unknown argument type in IS_ERR_VALUE(fpi -> dpram_offset)

[1]: http://permalink.gmane.org/gmane.linux.kernel/2120927
[2]: http://permalink.gmane.org/gmane.linux.kernel/2150581

Regards
Andrzej


Andrzej Hajda (7):
  netfilter: fix IS_ERR_VALUE usage
  MIPS: module: fix incorrect IS_ERR_VALUE macro usages
  drivers: char: mem: fix IS_ERROR_VALUE usage
  atmel-isi: fix IS_ERR_VALUE usage
  serial: clps711x: fix IS_ERR_VALUE usage
  fbdev: exynos: fix IS_ERR_VALUE usage
  usb: gadget: fsl_qe_udc: fix IS_ERR_VALUE usage

 arch/mips/kernel/module-rela.c                |  2 +-
 arch/mips/kernel/module.c                     |  2 +-
 drivers/char/mem.c                            |  2 +-
 drivers/media/platform/soc_camera/atmel-isi.c |  4 ++--
 drivers/tty/serial/clps711x.c                 | 14 ++++++++------
 drivers/usb/gadget/udc/fsl_qe_udc.c           |  2 +-
 drivers/video/fbdev/exynos/exynos_mipi_dsi.c  |  6 +++---
 include/linux/netfilter/x_tables.h            |  6 +++---
 net/ipv4/netfilter/arp_tables.c               | 11 +++++++----
 net/ipv4/netfilter/ip_tables.c                | 12 ++++++++----
 net/ipv6/netfilter/ip6_tables.c               | 13 +++++++++----
 11 files changed, 44 insertions(+), 30 deletions(-)

-- 
1.9.1



From a.hajda at samsung.com  Mon Feb 15 06:35:23 2016
From: a.hajda at samsung.com (Andrzej Hajda)
Date: Mon, 15 Feb 2016 15:35:23 +0100
Subject: [PATCH 5/7] serial: clps711x: fix IS_ERR_VALUE usage
In-Reply-To: <1455546925-22119-1-git-send-email-a.hajda@samsung.com>
References: <1455546925-22119-1-git-send-email-a.hajda@samsung.com>
Message-ID: <1455546925-22119-6-git-send-email-a.hajda@samsung.com>

IS_ERR_VALUE macro should be used only with unsigned long type.
For signed types comparison 'ret < 0' should be used.

The patch follows conclusion from discussion on LKML [1][2].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2120927
[2]: http://permalink.gmane.org/gmane.linux.kernel/2150581

Signed-off-by: Andrzej Hajda <a.hajda at samsung.com>
---
 drivers/tty/serial/clps711x.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/clps711x.c b/drivers/tty/serial/clps711x.c
index b3a4e0c..0096ebe 100644
--- a/drivers/tty/serial/clps711x.c
+++ b/drivers/tty/serial/clps711x.c
@@ -467,13 +467,15 @@ static int uart_clps711x_probe(struct platform_device *pdev)
 	if (IS_ERR(s->port.membase))
 		return PTR_ERR(s->port.membase);
 
-	s->port.irq = platform_get_irq(pdev, 0);
-	if (IS_ERR_VALUE(s->port.irq))
-		return s->port.irq;
+	ret = platform_get_irq(pdev, 0);
+	if (ret < 0)
+		return ret;
+	s->port.irq = ret;
 
-	s->rx_irq = platform_get_irq(pdev, 1);
-	if (IS_ERR_VALUE(s->rx_irq))
-		return s->rx_irq;
+	ret = platform_get_irq(pdev, 1);
+	if (ret < 0)
+		return ret;
+	s->rx_irq = ret;
 
 	if (!np) {
 		char syscon_name[9];
-- 
1.9.1



From linux at arm.linux.org.uk  Mon Feb 15 06:43:44 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Feb 2016 14:43:44 +0000
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <56C1CE95.6020206@arm.com>
References: <20160214165010.GA3189@roeck-us.net>
 <20160215105909.GH12289@pengutronix.de> <56C1CE95.6020206@arm.com>
Message-ID: <20160215144344.GF10826@n2100.arm.linux.org.uk>

On Mon, Feb 15, 2016 at 01:11:49PM +0000, Robin Murphy wrote:
> FWIW the PL180 on my Juno still works fine with this patch picked on top of
> -rc3, so the issue would seem to be something else - From a quick comparison
> between the DTs I see a slight difference in compatible strings for the
> clocks, but the more likely-looking suspect is that the VExpress DT
> references some GPIOs where the Juno DT doesn't.

Maybe it would be a good idea that Uwe creates a patch which initially
warns when a DT platform device falls back to matching via the platform
strings?

It's likely that the "basic subsystem" platform drivers are silent when
they probe, so having notification of a fallback would at least put
something into the kernel log when that happens - and then later change
that to be a hard failure (as Uwe is trying to do with his patch.)

However, I have to bring up another point: is what Uwe is trying to do
actually the right thing?  The DT platform device code has the ability
to create standard platform devices from DT, with an of_node, but with
standard names, and platform data.  It's there for compatibility with
older systems, and is there to allow systems to be transitioned over.

This patch breaks all that: despite the DT code changing the platform
device bus_id from the address.nodename format to the standard format
(thus allowing unconverted platform drivers to match), this patch
means that because the platform device has a of_node attached, this
will now fail.

Therefore, I think Uwe's patch is just wrong - or, if it's something we
want, the auxdata table support code needs to _also_ be ripped out of
the drivers/of/platform.c code, but that then means anyone who wants to
go through the conversion has a big flag-day change to go through.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From mark.rutland at arm.com  Mon Feb 15 06:46:52 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 15 Feb 2016 14:46:52 +0000
Subject: [RFC PATCH 1/7] arm64/perf: Basic uncore counter support for
 Cavium ThunderX
In-Reply-To: <20160215142726.GD9732@leverpostej>
References: <cover.1455295032.git.jglauber@cavium.com>
 <8bd93a25e069ed6428bc6c21fc53270962ccafcc.1455295032.git.jglauber@cavium.com>
 <20160212173658.GD20262@leverpostej>
 <20160215140720.GA4053@hardcore>
 <20160215142726.GD9732@leverpostej>
Message-ID: <20160215144652.GF9732@leverpostej>

On Mon, Feb 15, 2016 at 02:27:27PM +0000, Mark Rutland wrote:
> > > > +	uncore = event_to_thunder_uncore(event);
> > > > +	if (!uncore)
> > > > +		return -ENODEV;
> > > > +	if (!uncore->event_valid(event->attr.config))
> > > > +		return -EINVAL;
> > > > +
> > > > +	hwc->config = event->attr.config;
> > > > +	hwc->idx = -1;
> > > > +
> > > > +	/* and we don't care about CPU */
> > > 
> > > Actually, you do. You want the perf core to serialize accesses via the
> > > same CPU, so all events _must_ be targetted at the same CPU. Otherwise
> > > there are a tonne of problems you don't even want to think about.
> > 
> > I found that perf added the events on every CPU in the system. Because
> > the uncore events are not CPU related I wanted to avoid this. Setting
> > cpumask to -1 did not work. Therefore I added a single CPU in the
> > cpumask, see thunder_uncore_attr_show_cpumask().
> 
> I understand that, which is why I wrote:
> 
> > > You _must_ ensure this kernel-side, regardless of what the perf tool
> > > happens to do.
> > > 
> > > See the arm-cci and arm-ccn drivers for an example.
> 
> Take a look at drivers/bus/arm-cci.c; specifically, what we do in
> cci_pmu_event_init and cci_pmu_cpu_notifier.
> 
> This is the same thing that's done for x86 system PMUs. Take a look at
> uncore_pmu_event_init in arch/x86/kernel/cpu/perf_event_intel_uncore.c.

I note that we still have an open TODO rather than a call to
perf_pmu_migrate_context.

The better example is arm_ccn_pmu_cpu_notifier in drivers/bus/arm-ccn.c.

Mark.


From javier at osg.samsung.com  Mon Feb 15 06:50:48 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Mon, 15 Feb 2016 11:50:48 -0300
Subject: [PATCH] rtc: mt6397: Add platform device ID table
In-Reply-To: <1455501497.7263.4.camel@mtksdaap41>
References: <1455016095-13724-1-git-send-email-javier@osg.samsung.com>
 <1455501497.7263.4.camel@mtksdaap41>
Message-ID: <56C1E5C8.6040007@osg.samsung.com>

Hello Eddie,

On 02/14/2016 10:58 PM, Eddie Huang wrote:

[snip]

>> @@ -412,6 +418,7 @@ static struct platform_driver mtk_rtc_driver = {
>>   	},
>>   	.probe	= mtk_rtc_probe,
>>   	.remove = mtk_rtc_remove,
>> +	.id_table = mt6397_rtc_id,
>>   };
>>
>>   module_platform_driver(mtk_rtc_driver);
>> @@ -419,4 +426,3 @@ module_platform_driver(mtk_rtc_driver);
>>   MODULE_LICENSE("GPL v2");
>>   MODULE_AUTHOR("Tianping Fang <tianping.fang at mediatek.com>");
>>   MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC");
>> -MODULE_ALIAS("platform:mt6397-rtc");
>
> This patch looks good to me, but I am wondering, since we tend to use
> device tree method to match driver, do we still need support platform
> device ID ?
>

I'm not familiar with neither this IP block nor the SoC so it is up to
you. I just noticed this issue when reviewing a regulator driver for a
similar PMIC posted by someone from mediatek.

I thought platform device was needed since the driver has a MODULE_ALIAS()
but please let me know what you prefer and I can re-spin the patch and
just remove the MODULE_ALIAS() if that makes more sense for this platform.
  
> Eddie
>
>

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America


From ard.biesheuvel at linaro.org  Mon Feb 15 06:58:05 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 15 Feb 2016 15:58:05 +0100
Subject: [PATCH v5sub1 0/8] arm64: split linear and kernel mappings
In-Reply-To: <56C1D2CF.1010108@gmail.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <56BE3645.3030403@gmail.com>
 <CAKv+Gu9Qw=DSe1fZT=Dv=iKaKqzsf5ARK9dzwCWPk_0uRECm1w@mail.gmail.com>
 <56BE3C35.7070608@gmail.com>
 <CAKv+Gu_29SjYgg+P3fyGFcaRVxjapVzMs85Y2frd7_f51mPv-A@mail.gmail.com>
 <56C1D2CF.1010108@gmail.com>
Message-ID: <CAKv+Gu-y8wvxUoM++dABxR6v-3U0sKmrZex4yAy5xpJLjD0eAQ@mail.gmail.com>

On 15 February 2016 at 14:29, Matthias Brugger <matthias.bgg at gmail.com> wrote:
>
>
> On 13/02/16 15:28, Ard Biesheuvel wrote:
>>
>> On 12 February 2016 at 21:10, Matthias Brugger <matthias.bgg at gmail.com>
>> wrote:
>>>
>>>
>>>
>>> On 12/02/16 20:47, Ard Biesheuvel wrote:
>>>>
>>>>
>>>> On 12 February 2016 at 20:45, Matthias Brugger <matthias.bgg at gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi Ard,
>>>>>
>>>>>
>>>>> On 01/02/16 11:54, Ard Biesheuvel wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> At the request of Catalin, this series has been split off from my
>>>>>> series
>>>>>> 'arm64: implement support for KASLR v4' [1]. This sub-series deals
>>>>>> with
>>>>>> moving the kernel out of the linear mapping into the vmalloc area.
>>>>>> This
>>>>>> is a prerequisite for independent physical and virtual randomization
>>>>>> of
>>>>>> the kernel image. On top of that, considering that these changes allow
>>>>>> the linear mapping to start at an arbitrary offset above PAGE_OFFSET,
>>>>>> it
>>>>>> should be an improvement in itself due to the fact that we can now
>>>>>> choose
>>>>>> PAGE_OFFSET such that RAM can be mapped using large block sizes.
>>>>>>
>>>>>> For instance, on my Seattle A0 box, the kernel is loaded 16 MB into
>>>>>> the
>>>>>> lowest GB of RAM, which means __pa(PAGE_OFFSET) is not 1 GB aligned,
>>>>>> and
>>>>>> the entire 16 GB of RAM will be mapping using 2 MB blocks. (Similarly,
>>>>>> for 64 KB granule kernels, the entire 16 GB of RAM will be mapped
>>>>>> using
>>>>>> pages since __pa(PAGE_OFFSET) is not 512 MB aligned). With these
>>>>>> changes
>>>>>>     __pa(PAGE_OFFSET) will always be chosen such that it is aligned to
>>>>>> a
>>>>>> quantity that allows efficient mapping.
>>>>>>
>>>>>> Note that of the entire KASLR series, this sub-series is the most
>>>>>> likely
>>>>>> to
>>>>>> cause problems, and hence requires the most careful review and
>>>>>> testing.
>>>>>> This
>>>>>> is due to the fact that, with these changes, the invariant
>>>>>> __va(__pa(x))
>>>>>> == x
>>>>>> no longer holds, and any code that is based on that assumption needs
>>>>>> to
>>>>>> be
>>>>>> updated.
>>>>>>
>>>>>> Changes since v4:
>>>>>> - added Marc's ack to patch #6
>>>>>> - round the kasan zero shadow region around the kernel image to
>>>>>> swapper
>>>>>> block
>>>>>>      size (#7)
>>>>>> - ensure that we don't clip the kernel image when clipping RAM to the
>>>>>> linear
>>>>>>      region size (#8)
>>>>>>
>>>>>> Patch #1 allows the low mark of memblocks discovered from the FDT to
>>>>>> be
>>>>>> overridden by the architecture.
>>>>>>
>>>>>> Patch #2 enables the huge-vmap generic feature for arm64. This should
>>>>>> be
>>>>>> an
>>>>>> improvement in itself, but the significance for this series is that it
>>>>>> allows
>>>>>> unmap_kernel_range() to be called on the [__init_begin, __init_end)
>>>>>> region,
>>>>>> which may be partially mapped using block mappings.
>>>>>>
>>>>>> Patch #3 introduces KIMAGE_VADDR as a separate, preparatory step
>>>>>> towards
>>>>>> decoupling the kernel placement from PAGE_OFFSET
>>>>>>
>>>>>> Patch #4 implements some translation table accessors that operate on
>>>>>> statically
>>>>>> allocate translation tables before the linear mapping is up.
>>>>>>
>>>>>> Patch #5 decouples the fixmap initialization from the linear mapping,
>>>>>> by
>>>>>> using
>>>>>> the accessors implemented by patch #4
>>>>>>
>>>>>> Patch #6 removes assumptions made my KVM regarding the placement of
>>>>>> the
>>>>>> kernel
>>>>>> image inside the linear mapping.
>>>>>>
>>>>>> Patch #7 moves the kernel image from the base of the linear mapping to
>>>>>> the
>>>>>> base
>>>>>> of the vmalloc area. The modules area, which sits right below the
>>>>>> kernel
>>>>>> image,
>>>>>> is moved along and is put right before the start of the vmalloc area.
>>>>>>
>>>>>> Patch #8 decouples PHYS_OFFSET from PAGE_OFFSET, which allows the
>>>>>> linear
>>>>>> mapping
>>>>>> to cover all discovered memory, regardless of where the kernel image
>>>>>> is
>>>>>> located
>>>>>> in it. This effectively allows the kernel to be loaded at any physical
>>>>>> address
>>>>>> (provided that the correct alignment is used)
>>>>>>
>>>>>> [1] http://thread.gmane.org/gmane.linux.kernel/2135931
>>>>>>
>>>>>> Ard Biesheuvel (8):
>>>>>>      of/fdt: make memblock minimum physical address arch configurable
>>>>>>      arm64: add support for ioremap() block mappings
>>>>>>      arm64: introduce KIMAGE_VADDR as the virtual base of the kernel
>>>>>> region
>>>>>>      arm64: pgtable: implement static [pte|pmd|pud]_offset variants
>>>>>>      arm64: decouple early fixmap init from linear mapping
>>>>>>      arm64: kvm: deal with kernel symbols outside of linear mapping
>>>>>>      arm64: move kernel image to base of vmalloc area
>>>>>>      arm64: allow kernel Image to be loaded anywhere in physical
>>>>>> memory
>>>>>>
>>>>>
>>>>> I bisected linux-next (20160212) with the following error on booting
>>>>> with
>>>>> an
>>>>> initramfs:
>>>>>    Failed to execute /init (error -8)
>>>>>    request_module: runaway loop modprobe binfmt-464c
>>>>>    Starting init: /sbin/init exists but couldn't execute it (error -8)
>>>>>    request_module: runaway loop modprobe binfmt-464c
>>>>>    Starting init: /bin/sh exists but couldn't execute it (error -8)
>>>>>    Kernel panic - not syncing: No working init found.  Try passing
>>>>> init=
>>>>> option to kernel. See Linux Documentation/init..
>>>>>
>>>>> I tracked down the error to patch 7 of this series. But I realized that
>>>>> patch 7 does not compile, but from patch 8 onwards I observe the error.
>>>>>
>>
>> As far as this failure is concerned, I managed to reproduce an error
>> with patch #7 and not #8 applied, involving out of range kvm symbols
>> at link time. This is reproducible with GCC 4.8 but not GCC 4.9 or
>> later. Is this what you were seeing as well? Or is there another
>> problem?
>>
>
> I realized that I used " aarch64-linux-gnu-gcc (Linaro GCC 2014.11) 4.9.3
> 20141031 (prerelease)"  which gave me errors like:
>
> arch/arm64/kvm/built-in.o: In function `__cpu_init_hyp_mode':
> /home/mbrugger/src/linux-next/./arch/arm64/include/asm/kvm_host.h:331:(.text+0x73b4):
> relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against symbol
> `__kvm_hyp_vector' defined in .hyp.text section in arch/arm64/kvm/built-in.o
>
> So it was time to update my toolchain to "aarch64-linux-gnu-gcc (Linaro GCC
> 5.1-2015.08) 5.1.1 20150608" which fixed the problem for me.
>

OK, so it's the same issue, but I thought before that 4.9 worked ok,
which is indeed not the case (I checked)
This is a transient issue, since the subsequent patch replaces the
offending expressions, but to maintain bisectability, I will add a
workaround nonetheless.

Thanks,
Ard.


From wens at csie.org  Mon Feb 15 06:58:08 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 15 Feb 2016 22:58:08 +0800
Subject: [linux-sunxi] Allwinner A64 MMC support
In-Reply-To: <56C1E250.9070301@arm.com>
References: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
 <56BE29A1.3060107@redhat.com> <56C1A590.6030500@arm.com>
 <56C1C7BB.1040602@redhat.com> <56C1D9C0.6020601@arm.com>
 <CAGb2v65E54mnLEcPzLyycEBSHbvn6tp9JpS+S8gdbDg_e7qFyQ@mail.gmail.com>
 <56C1E250.9070301@arm.com>
Message-ID: <CAGb2v67apAN0H_Nz2kQ4oYjtRwRfaM0L3KTv6uXLfp7m7DpnbA@mail.gmail.com>

On Mon, Feb 15, 2016 at 10:36 PM, Andre Przywara <andre.przywara at arm.com> wrote:
> Hi Chen-Yu,
>
> On 15/02/16 14:23, Chen-Yu Tsai wrote:
>> On Mon, Feb 15, 2016 at 9:59 PM, Andre Przywara <andre.przywara at arm.com> wrote:
>>> Hi Hans,
>>>
>>> ....
>>>
>>>>
>>>> p.s.
>>>>
>>>> I love the work you've been doing on the A64, I've not had a chance
>>>> to try it out yet though. Have you made any progress with getting
>>>> the mmc slot to work ?  If not maybe I can make some time I've
>>>> prior experience in bringing up the mmc slot on other Allwinner SoCs
>>>
>>> Thanks for that!
>>>
>>> So we made some progress on the weekend (with the help of #linux-sunxi):
>>> 1) The regulator node was stupidly put by me into a separate child node
>>> without putting address and size cells into. So I just moved it into
>>> /soc directly now and that seems to fixed the missing regulator.
>>> 2) The reset node is a allwinner,sun6i-a31-ahb1-reset, which does not
>>> get registered automatically, but by an explicit call from mach-sunxi/.
>>> I wonder why we do this (yes, I saw that comment, but still...) and if
>>> it would work with a normal MODULE_DEVICE_TABLE() declaration.
>>> There is and will be no equivalent to the mach- directory on arm64.
>>
>> On sun6i, we supported the high resolution timer, which had a reset control.
>> Timers (or clocksources) are registered before device model kicks in, so the
>> reset had to be explicitly registered before the timer, or the system would
>> hang. I think we phased that out though. Maxime should know.
>
> Ah, thanks for that insight!
> So that sounds like we would get away with a normal registration for the
> A64 - and actually many other SoCs as well?
> Shall we guard the explicit sun6i_reset_init with MACH_SUN6I or
> something and do the normal registration otherwise?
> Or do I miss something here?

You'll notice 2 reset control compatibles, one is
"allwinner,sun6i-a31-ahb1-reset",
while the other is "allwinner,sun6i-a31-clock-reset". The latter is a
proper device
model driver. We also don't have the hstimer device node for later
SoCs. For A23, it
was because the hardware had only 1 timer, while the driver needed 2,
and I didn't
want to deal with it at the time.

As long as you use "allwinner,sun6i-a31-clock-reset", no special code is needed.

ChenYu

> Cheers,
> Andre
>
>>> 3) As Jens pointed out, the MMC IP block isn't really compatible.
>>> Changing the clocks is easy (done already), but we need to come up with
>>> code to cover the new phase setting registers in the A64 MMC register block.
>>>
>>> Interestingly somehow hacking this (pretending it is compatible) seems
>>> to work, though I got reports from people about mysterious kernel
>>> crashes, so I'm inclined to leave MMC out of the first patch series.
>>>
>>> So if you could take a look at the new registers (starting at offset
>>> 0x140) and work out what we actually need to do here, that would be
>>> great. I have no real clue about what they actually do and how they
>>> relate to the current output and sample clock phase.
>>> To me it looks like we might get away with just triggering the automatic
>>> calibration and the hardware does the rest for us - keep your fingers
>>> crossed ;-)
>>>
>>> Cheers,
>>> Andre.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


From andriy.shevchenko at linux.intel.com  Mon Feb 15 07:14:06 2016
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 15 Feb 2016 17:14:06 +0200
Subject: [PATCH 01/14] mfd: intel_quark_i2c_gpio: Use clkdev_create()
In-Reply-To: <1454982341-22715-2-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
 <1454982341-22715-2-git-send-email-sboyd@codeaurora.org>
Message-ID: <1455549246.31169.125.camel@linux.intel.com>

On Mon, 2016-02-08 at 17:45 -0800, Stephen Boyd wrote:
> Convert this driver to use clkdev_create() instead of
> clk_register_clkdevs(). The latter API is only used by this driver,
> although this driver only allocates one clk to add anyway.
> Furthermore, this driver allocates the clk_lookup structure with
> devm, but clkdev_drop() will free that structure when passed,
> leading to a double free when this driver is removed. Clean it
> all up and pave the way for the removal of clk_register_clkdevs().

Good one.

I have still in my local tree the fix regarding to this code since I
found an error in the error path (we don't free clk resources). So, I
will re-base it, although it will require to go with two patches
instead of one if we go to stable.

For this one:
Acked-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>

> 
> Cc: Lee Jones <lee.jones at linaro.org>
> Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
> ?drivers/mfd/intel_quark_i2c_gpio.c | 26 +++++++++-----------------
> ?1 file changed, 9 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
> b/drivers/mfd/intel_quark_i2c_gpio.c
> index 042137465300..bdc5e27222c0 100644
> --- a/drivers/mfd/intel_quark_i2c_gpio.c
> +++ b/drivers/mfd/intel_quark_i2c_gpio.c
> @@ -52,8 +52,6 @@
> ?/* The Quark I2C controller source clock */
> ?#define INTEL_QUARK_I2C_CLK_HZ	33000000
> ?
> -#define INTEL_QUARK_I2C_NCLK	1
> -
> ?struct intel_quark_mfd {
> ?	struct pci_dev		*pdev;
> ?	struct clk		*i2c_clk;
> @@ -128,30 +126,24 @@ MODULE_DEVICE_TABLE(pci, intel_quark_mfd_ids);
> ?static int intel_quark_register_i2c_clk(struct intel_quark_mfd
> *quark_mfd)
> ?{
> ?	struct pci_dev *pdev = quark_mfd->pdev;
> -	struct clk_lookup *i2c_clk_lookup;
> ?	struct clk *i2c_clk;
> -	int ret;
> -
> -	i2c_clk_lookup = devm_kcalloc(&pdev->dev,
> INTEL_QUARK_I2C_NCLK,
> -				??????sizeof(*i2c_clk_lookup),
> GFP_KERNEL);
> -	if (!i2c_clk_lookup)
> -		return -ENOMEM;
> -
> -	i2c_clk_lookup[0].dev_id = INTEL_QUARK_I2C_CONTROLLER_CLK;
> ?
> ?	i2c_clk = clk_register_fixed_rate(&pdev->dev,
> ?					??INTEL_QUARK_I2C_CONTROLLER
> _CLK, NULL,
> ?					??CLK_IS_ROOT,
> INTEL_QUARK_I2C_CLK_HZ);
> +	if (IS_ERR(i2c_clk))
> +		return PTR_ERR(i2c_clk);
> ?
> -	quark_mfd->i2c_clk_lookup = i2c_clk_lookup;
> ?	quark_mfd->i2c_clk = i2c_clk;
> +	quark_mfd->i2c_clk_lookup = clkdev_create(i2c_clk, NULL,
> +						INTEL_QUARK_I2C_CONT
> ROLLER_CLK);
> ?
> -	ret = clk_register_clkdevs(i2c_clk, i2c_clk_lookup,
> -				???INTEL_QUARK_I2C_NCLK);
> -	if (ret)
> -		dev_err(&pdev->dev, "Fixed clk register failed:
> %d\n", ret);
> +	if (!quark_mfd->i2c_clk_lookup) {
> +		dev_err(&pdev->dev, "Fixed clk register failed\n");
> +		return -ENOMEM;
> +	}
> ?
> -	return ret;
> +	return 0;
> ?}
> ?
> ?static void intel_quark_unregister_i2c_clk(struct pci_dev *pdev)

-- 
Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Intel Finland Oy



From andriy.shevchenko at linux.intel.com  Mon Feb 15 07:16:16 2016
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 15 Feb 2016 17:16:16 +0200
Subject: [PATCH 02/14] clkdev: Remove clk_register_clkdevs()
In-Reply-To: <1454982341-22715-3-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
 <1454982341-22715-3-git-send-email-sboyd@codeaurora.org>
Message-ID: <1455549376.31169.127.camel@linux.intel.com>

On Mon, 2016-02-08 at 17:45 -0800, Stephen Boyd wrote:
> Now that we've converted the only caller over to another clkdev
> API, remove this one.
> 

This API didn't feel suitable, good we get rid of it eventually.

Reviewed-by: Andy Shevchenko <andriy.shevchenko at linux.intel.com>>?

> Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
> ---
> ?drivers/clk/clkdev.c???| 27 ---------------------------
> ?include/linux/clkdev.h |??1 -
> ?2 files changed, 28 deletions(-)
> 
> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
> index 779b6ff0c7ad..ae61f2e57048 100644
> --- a/drivers/clk/clkdev.c
> +++ b/drivers/clk/clkdev.c
> @@ -383,30 +383,3 @@ int clk_register_clkdev(struct clk *clk, const
> char *con_id,
> ?	return cl ? 0 : -ENOMEM;
> ?}
> ?EXPORT_SYMBOL(clk_register_clkdev);
> -
> -/**
> - * clk_register_clkdevs - register a set of clk_lookup for a struct
> clk
> - * @clk: struct clk to associate with all clk_lookups
> - * @cl: array of clk_lookup structures with con_id and dev_id pre-
> initialized
> - * @num: number of clk_lookup structures to register
> - *
> - * To make things easier for mass registration, we detect error clks
> - * from a previous clk_register() call, and return the error code
> for
> - * those.??This is to permit this function to be called immediately
> - * after clk_register().
> - */
> -int clk_register_clkdevs(struct clk *clk, struct clk_lookup *cl,
> size_t num)
> -{
> -	unsigned i;
> -
> -	if (IS_ERR(clk))
> -		return PTR_ERR(clk);
> -
> -	for (i = 0; i < num; i++, cl++) {
> -		cl->clk_hw = __clk_get_hw(clk);
> -		__clkdev_add(cl);
> -	}
> -
> -	return 0;
> -}
> -EXPORT_SYMBOL(clk_register_clkdevs);
> diff --git a/include/linux/clkdev.h b/include/linux/clkdev.h
> index 08bffcc466de..43a8c2e8ac29 100644
> --- a/include/linux/clkdev.h
> +++ b/include/linux/clkdev.h
> @@ -46,7 +46,6 @@ int clk_add_alias(const char *, const char *, const
> char *, struct device *);
> ?
> ?int clk_register_clkdev(struct clk *, const char *, const char *,
> ...)
> ?	__printf(3, 4);
> -int clk_register_clkdevs(struct clk *, struct clk_lookup *, size_t);
> ?
> ?#ifdef CONFIG_COMMON_CLK
> ?int __clk_get(struct clk *clk);

-- 
Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Intel Finland Oy



From CARLOS.PALMINHA at synopsys.com  Mon Feb 15 07:18:34 2016
From: CARLOS.PALMINHA at synopsys.com (Carlos Palminha)
Date: Mon, 15 Feb 2016 15:18:34 +0000
Subject: [PATCH v2 03/17] drm/exynos: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <CAMeQTsZLdMOnk7-isneoUyFBbQdiRUsGH6+EhD8W1LNB=80LVQ@mail.gmail.com>
References: <cover.1455540137.git.palminha@synopsys.com>
 <3768b670931572de51fca1102efa18d20dd770ee.1455540137.git.palminha@synopsys.com>
 <CAMeQTsZLdMOnk7-isneoUyFBbQdiRUsGH6+EhD8W1LNB=80LVQ@mail.gmail.com>
Message-ID: <56C1EC4A.1000803@synopsys.com>

Hi Patrik,

No particular reason... i was grepping along the development and probably didn't noticed that exynos was not completely nuked... :)

Regards,
C.Palminha

On 15-02-2016 13:49, Patrik Jakobsson wrote:
> Hi Carlos
> 
> Any particular reason why this patch isn't squashed with patch 8/17?
> 
> Thanks
> Patrik
> 
> 
> On Mon, Feb 15, 2016 at 1:58 PM, Carlos Palminha
> <CARLOS.PALMINHA at synopsys.com> wrote:
>> mode_fixup function for encoder drivers became optional with patch
>> http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com
>>
>> This patch set nukes all the dummy mode_fixup implementations.
>>
>> (made on top of Daniel topic/drm-misc branch)
>>
>> Signed-off-by: Carlos Palminha <palminha at synopsys.com>
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 --------
>>  1 file changed, 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> index e977a81..736115c 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
>> @@ -1597,13 +1597,6 @@ static int exynos_dsi_create_connector(struct drm_encoder *encoder)
>>         return 0;
>>  }
>>
>> -static bool exynos_dsi_mode_fixup(struct drm_encoder *encoder,
>> -                                 const struct drm_display_mode *mode,
>> -                                 struct drm_display_mode *adjusted_mode)
>> -{
>> -       return true;
>> -}
>> -
>>  static void exynos_dsi_mode_set(struct drm_encoder *encoder,
>>                                 struct drm_display_mode *mode,
>>                                 struct drm_display_mode *adjusted_mode)
>> @@ -1623,7 +1616,6 @@ static void exynos_dsi_mode_set(struct drm_encoder *encoder,
>>  }
>>
>>  static const struct drm_encoder_helper_funcs exynos_dsi_encoder_helper_funcs = {
>> -       .mode_fixup = exynos_dsi_mode_fixup,
>>         .mode_set = exynos_dsi_mode_set,
>>         .enable = exynos_dsi_enable,
>>         .disable = exynos_dsi_disable,
>> --
>> 2.5.0
>>


From andre.przywara at arm.com  Mon Feb 15 07:22:43 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 15 Feb 2016 15:22:43 +0000
Subject: [linux-sunxi] Allwinner A64 MMC support
In-Reply-To: <CAGb2v67apAN0H_Nz2kQ4oYjtRwRfaM0L3KTv6uXLfp7m7DpnbA@mail.gmail.com>
References: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
 <56BE29A1.3060107@redhat.com> <56C1A590.6030500@arm.com>
 <56C1C7BB.1040602@redhat.com> <56C1D9C0.6020601@arm.com>
 <CAGb2v65E54mnLEcPzLyycEBSHbvn6tp9JpS+S8gdbDg_e7qFyQ@mail.gmail.com>
 <56C1E250.9070301@arm.com>
 <CAGb2v67apAN0H_Nz2kQ4oYjtRwRfaM0L3KTv6uXLfp7m7DpnbA@mail.gmail.com>
Message-ID: <56C1ED43.6010504@arm.com>

Hi,

On 15/02/16 14:58, Chen-Yu Tsai wrote:
> On Mon, Feb 15, 2016 at 10:36 PM, Andre Przywara <andre.przywara at arm.com> wrote:
>> Hi Chen-Yu,
>>
>> On 15/02/16 14:23, Chen-Yu Tsai wrote:
>>> On Mon, Feb 15, 2016 at 9:59 PM, Andre Przywara <andre.przywara at arm.com> wrote:
>>>> Hi Hans,
>>>>
>>>> ....
>>>>
>>>>>
>>>>> p.s.
>>>>>
>>>>> I love the work you've been doing on the A64, I've not had a chance
>>>>> to try it out yet though. Have you made any progress with getting
>>>>> the mmc slot to work ?  If not maybe I can make some time I've
>>>>> prior experience in bringing up the mmc slot on other Allwinner SoCs
>>>>
>>>> Thanks for that!
>>>>
>>>> So we made some progress on the weekend (with the help of #linux-sunxi):
>>>> 1) The regulator node was stupidly put by me into a separate child node
>>>> without putting address and size cells into. So I just moved it into
>>>> /soc directly now and that seems to fixed the missing regulator.
>>>> 2) The reset node is a allwinner,sun6i-a31-ahb1-reset, which does not
>>>> get registered automatically, but by an explicit call from mach-sunxi/.
>>>> I wonder why we do this (yes, I saw that comment, but still...) and if
>>>> it would work with a normal MODULE_DEVICE_TABLE() declaration.
>>>> There is and will be no equivalent to the mach- directory on arm64.
>>>
>>> On sun6i, we supported the high resolution timer, which had a reset control.
>>> Timers (or clocksources) are registered before device model kicks in, so the
>>> reset had to be explicitly registered before the timer, or the system would
>>> hang. I think we phased that out though. Maxime should know.
>>
>> Ah, thanks for that insight!
>> So that sounds like we would get away with a normal registration for the
>> A64 - and actually many other SoCs as well?
>> Shall we guard the explicit sun6i_reset_init with MACH_SUN6I or
>> something and do the normal registration otherwise?
>> Or do I miss something here?
> 
> You'll notice 2 reset control compatibles, one is
> "allwinner,sun6i-a31-ahb1-reset",
> while the other is "allwinner,sun6i-a31-clock-reset". The latter is a
> proper device
> model driver. We also don't have the hstimer device node for later
> SoCs. For A23, it
> was because the hardware had only 1 timer, while the driver needed 2,
> and I didn't
> want to deal with it at the time.

Oooh, now I see that those are actually the same driver, just the
initialization part is separate. Thanks for the hint!

> As long as you use "allwinner,sun6i-a31-clock-reset", no special code is needed.

Yeah, great, I will just replace the string in the DT.

Cheers,
Andre.

>> Cheers,
>> Andre
>>
>>>> 3) As Jens pointed out, the MMC IP block isn't really compatible.
>>>> Changing the clocks is easy (done already), but we need to come up with
>>>> code to cover the new phase setting registers in the A64 MMC register block.
>>>>
>>>> Interestingly somehow hacking this (pretending it is compatible) seems
>>>> to work, though I got reports from people about mysterious kernel
>>>> crashes, so I'm inclined to leave MMC out of the first patch series.
>>>>
>>>> So if you could take a look at the new registers (starting at offset
>>>> 0x140) and work out what we actually need to do here, that would be
>>>> great. I have no real clue about what they actually do and how they
>>>> relate to the current output and sample clock phase.
>>>> To me it looks like we might get away with just triggering the automatic
>>>> calibration and the hardware does the rest for us - keep your fingers
>>>> crossed ;-)
>>>>
>>>> Cheers,
>>>> Andre.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 


From tony at atomide.com  Mon Feb 15 07:27:52 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 15 Feb 2016 07:27:52 -0800
Subject: [PATCH 0/3] OMAP/pinmux: remove misuse of IRQF_NO_SUSPEND flag
In-Reply-To: <56C1A1FE.3080403@arm.com>
References: <1454351299-27440-1-git-send-email-sudeep.holla@arm.com>
 <CACRpkdYzJ9Hy0sH6gK6RzpLE6juS4WfPjbt7nh43vR9YTuGZWA@mail.gmail.com>
 <56C1A1FE.3080403@arm.com>
Message-ID: <20160215152751.GT19432@atomide.com>

* Sudeep Holla <sudeep.holla at arm.com> [160215 02:03]:
> Hi Linus,
> 
> On 13/02/16 14:42, Linus Walleij wrote:
> >On Mon, Feb 1, 2016 at 7:28 PM, Sudeep Holla <sudeep.holla at arm.com> wrote:
> >
> >>   pinctrl: single: Use a separate lockdep class
> >>   pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag
> >>   ARM: OMAP2+: remove misuse of IRQF_NO_SUSPEND flag
> >>
> >>  arch/arm/mach-omap2/mux.c        |  4 ++--
> >>  arch/arm/mach-omap2/pm34xx.c     |  9 ++++-----
> >>  arch/arm/mach-omap2/prm_common.c |  1 +
> >>  drivers/pinctrl/pinctrl-single.c | 15 ++++++++++++---
> >
> >Are these patches orthogonal so I can merge the pinctrl patch independently
> >of the OMAP patches if Tony ACKs this?
> >
> 
> Thanks for the follow up.
> IIUC they are dependent and remember Tony/Grygorii wanted them to be
> merged together(at-least for bisectibility)

AFAIK this series needs to be kept together to keep things
working.

> >If not: should it be merged by me or through ARM SoC/Tony?
> >
> 
> I think so.
> 
> >Anyways waiting for maintainer feedback, but the above is good to know.
> >
> 
> Grygorii was still not sure if this works and he couldn't give it a
> test. He was traveling and may need more time to get back on this.

He said it does not work so clearly more work is needed.

Regards,

Tony


From qnguyen at apm.com  Mon Feb 15 07:31:59 2016
From: qnguyen at apm.com (Quan Nguyen)
Date: Mon, 15 Feb 2016 22:31:59 +0700
Subject: [PATCH v6 2/3] Documentation: gpio: Update description for X-Gene
 standby GPIO controller DTS binding
In-Reply-To: <56C1CA6E.1060606@arm.com>
References: <1455512263-18183-1-git-send-email-qnguyen@apm.com>
 <1455512263-18183-3-git-send-email-qnguyen@apm.com>
 <56C1CA6E.1060606@arm.com>
Message-ID: <CAFopSPRwd8cHnH8efegYVv52hPVTyk=VW9OrZZtSCj6Szj-K4Q@mail.gmail.com>

On Mon, Feb 15, 2016 at 7:54 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 15/02/16 04:57, Quan Nguyen wrote:
>> Update description for X-Gene standby GPIO controller DTS binding to
>> support GPIO line configuration as input, output or external IRQ pin.
>>
>> Signed-off-by: Y Vo <yvo at apm.com>
>> Signed-off-by: Quan Nguyen <qnguyen at apm.com>
>> ---
>>  .../devicetree/bindings/gpio/gpio-xgene-sb.txt     | 47 ++++++++++++++++++----
>>  1 file changed, 40 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
>> index dae1300..7b8b4cb 100644
>> --- a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
>> @@ -1,10 +1,20 @@
>>  APM X-Gene Standby GPIO controller bindings
>>
>> -This is a gpio controller in the standby domain.
>> -
>> -There are 20 GPIO pins from 0..21. There is no GPIO_DS14 or GPIO_DS15,
>> -only GPIO_DS8..GPIO_DS13 support interrupts. The IRQ mapping
>> -is currently 1-to-1 on interrupts 0x28 thru 0x2d.
>> +This is a gpio controller in the standby domain. It also supports interrupt in
>> +some particular pins which are sourced to its parent interrupt controller
>> +as diagram below:
>> +                           +-----------------+
>> +                           | X-Gene standby  |
>> +                           | GPIO controller +--------- GPIO_0
>> ++------------+             |                 | ...
>> +| Parent IRQ |             |                 +--------- GPIO_8/EXT_INT_0
>> +| controller |  EXT_INT_0  |                 | ...
>> +| (GICv2)    +-------------+                 +--------- GPIO_[N+8]/EXT_INT_N
>> +|            |  ...        |                 |
>> +|            |  EXT_INT_N  |                 +--------- GPIO_[N+9]
>> +|            +-------------+                 | ...
>> +|            |             |                 +--------- GPIO_MAX
>> ++------------+             +-----------------+
>>
>>  Required properties:
>>  - compatible: "apm,xgene-gpio-sb" for the X-Gene Standby GPIO controller
>> @@ -15,10 +25,18 @@ Required properties:
>>               0 = active high
>>               1 = active low
>>  - gpio-controller: Marks the device node as a GPIO controller.
>> -- interrupts: Shall contain exactly 6 interrupts.
>> +- interrupts: The EXT_INT_0 parent interrupt resource must be listed first.
>> +- interrupt-parent: Phandle of the parent interrupt controller.
>> +- interrupt-cells: Should be two.
>> +       - first cell is 0-N coresponding for EXT_INT_0 to EXT_INT_N.
>> +       - second cell is used to specify flags.
>> +- interrupt-controller: Marks the device node as an interrupt controller.
>> +- apm,nr-gpios: Optional, specify number of gpios pin.
>> +- apm,nr-irqs: Optional, specify number of interrupt pins.
>> +- apm,irq-start: Optional, specify lowest gpio pin support interrupt.
>
> This is quite ambiguous. Is that relative to the GIC? Assuming this is
> the case, you should then document it, specify the type of interrupt
> (SPI?), and whether this is 0- or 32-based (the code seems to indicate
> that is is 0-based).
>

Hi Marc, Let me explain by diagram below.
As you can also see in diagram above, the lowest gpio pin that
supports interrupt is GPIO_8 (EXT_INT_0),
and hence, apm,irq-start=<8> as default.

                                           +-----------------+
                                           | X-Gene standby  |
                                           | GPIO controller +--------- GPIO_0
+------------+                             |                 | ...
| Parent IRQ |                             |
+--------- GPIO_[apm,irq-start]/EXT_INT_0
| controller |  EXT_INT_0                  |                 | ...
| (GICv2)    +-----------------------------+
+--------- GPIO_[apm,nr-irqs + apm,irq-start - 1]/EXT_INT_[apm,nr-irqs
- 1]
|            |  ...                        |                 |
|            |  EXT_INT_[apm,nr-irqs - 1]  |
+--------- GPIO_[apm,nr-irqs + apm,irq-start]
|            +-----------------------------+                 | ...
|            |                             |                 +--------- GPIO_MAX
+------------+                             +-----------------+

To fix this ambiguity, I'm thinking to change it to:
"apm,irq-start: Optional, specify index of first gpio pin
corresponding to EXT_INT_0, default is 8."

Thanks,
-- Quan Nguyen


From jan.glauber at caviumnetworks.com  Mon Feb 15 07:34:39 2016
From: jan.glauber at caviumnetworks.com (Jan Glauber)
Date: Mon, 15 Feb 2016 16:34:39 +0100
Subject: [RFC PATCH 1/7] arm64/perf: Basic uncore counter support for
 Cavium ThunderX
In-Reply-To: <20160215142726.GD9732@leverpostej>
References: <cover.1455295032.git.jglauber@cavium.com>
 <8bd93a25e069ed6428bc6c21fc53270962ccafcc.1455295032.git.jglauber@cavium.com>
 <20160212173658.GD20262@leverpostej>
 <20160215140720.GA4053@hardcore>
 <20160215142726.GD9732@leverpostej>
Message-ID: <20160215153439.GA2586@hardcore>

On Mon, Feb 15, 2016 at 02:27:27PM +0000, Mark Rutland wrote:
> > > > 1) The PMU detection solely relies on PCI device detection. If a
> > > >    matching PCI device is found the PMU is created. The code can deal
> > > >    with multiple units of the same type, e.g. more than one memory
> > > >    controller.
> > > 
> > > I see below that the driver has an initcall that runs regardless of
> > > whether the PCI device exists, and looks at the MIDR. That's clearly not
> > > string PCI device detection.
> > > 
> > > Why is this not a true PCI driver that only gets probed if the PCI
> > > device exists? 
> > 
> > It is not a PCI driver because there are already drivers like edac that
> > will access these PCI devices. The uncore driver only accesses the
> > performance counters, which are not used by the other drivers.
> 
> Several drivers are accessing the same device?
> 
> That sounds somewhat scary.

I've double checked that the edac drivers do not access the performance
counters at all. It felt cleaner to me to keep the performance counter code
seperated from edac.

Jan


From andriy.shevchenko at linux.intel.com  Mon Feb 15 07:35:52 2016
From: andriy.shevchenko at linux.intel.com (Andy Shevchenko)
Date: Mon, 15 Feb 2016 17:35:52 +0200
Subject: Common/typical fractional divider HW API
In-Reply-To: <56B76B26.4050306@free.fr>
References: <56B4B67D.2080707@free.fr>
 <1454684758.31169.77.camel@linux.intel.com> <56B4C775.50808@free.fr>
 <1454688729.31169.87.camel@linux.intel.com> <56B4CDEF.3080606@free.fr>
 <1454690599.31169.103.camel@linux.intel.com> <56B76B26.4050306@free.fr>
Message-ID: <1455550552.31169.135.camel@linux.intel.com>

On Sun, 2016-02-07 at 17:04 +0100, Mason wrote:
> On 05/02/2016 17:43, Andy Shevchenko wrote:
> 
> > There are plenty of implementations of the divider.
> 
> I'd be happy to read an overview on the subject, if you have
> some links to share.

drivers/tty/serial/*

> 
> > You might consider to use one than inventing new one
> 
> I find it hard to believe that the interface I'm discussing
> has not been used (several times) in the past. (It's merely
> a trivial floating point scheme.)
> 
> As a matter of fact, the integer divider driver supports
> "I" and "2^I", so extending 2^I to "2^I * (1 + F/256)"
> is an obvious step.

Just to be simple:
Why do you have to modify existing clk-fractional-divider.c module?

May I suggest to reconsider your design to be fit in the existing CLK
divider implementations? Also, some of the hardware IPs have inside
divider registers, like mentioned above UARTs. I already suggested to
look at them to see how hardware is done.

Again, (actually I bored to repeat) I didn't see (yet!) any HW divider
which has integer part as 2^I. I don't get why you stuck with that
formula and why 1/256? Who prevents to have 1/32768 in HW (like we have
in LPSS of Intel SoCs)?

Here I'm giving up this discussion. Perhaps more experienced people
could correct me.

-- 
Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Intel Finland Oy



From linux at roeck-us.net  Mon Feb 15 07:41:19 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 15 Feb 2016 07:41:19 -0800
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160215105909.GH12289@pengutronix.de>
References: <20160214165010.GA3189@roeck-us.net>
 <20160215105909.GH12289@pengutronix.de>
Message-ID: <56C1F19F.8090100@roeck-us.net>

On 02/15/2016 02:59 AM, Uwe Kleine-K?nig wrote:
> Hello Guenter,
>
> On Sun, Feb 14, 2016 at 08:50:10AM -0800, Guenter Roeck wrote:
>> Uwe,
>>
>> Your patch 'driver-core: platform: probe of-devices only using list of
>> compatibles' causes the following qemu tests to crash in -next.
>>
>> arm:vexpress-a9:vexpress_defconfig:vexpress-v2p-ca9
>> arm:vexpress-a15:vexpress_defconfig:vexpress-v2p-ca15-tc1
>> arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>> arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>>
>> Crash log:
>>
>> VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6
>> Please append a correct "root=" boot option; here are the available partitions:
>> 1f00          131072 mtdblock0  (driver?)
>> 1f01           32768 mtdblock1  (driver?)
>> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
>
> Can you provide a complete boot log? This might already reveal which
> device is failing. It might not be the mmci device but something it
> depends on (clock, bus parent, irq).
>

Sure, something else may be failing, but why does reverting your patch
fix the problem ?

Anyway, complete logs are at http://kerneltests.org/builders.

http://kerneltests.org/builders/qemu-arm-next/builds/376/steps/qemubuildcommand/logs/stdio

is the most recent log (next-20120215). Look for the vexpress crashes; the overo
crash bisected to to 'PM / OPP: Disable OPPs that aren't supported by the regulator',
in next-20160212, which I have not fully analyzed yet, and the beagle crashes
as well as the 'new' overo crash are brand new.

Guenter



From pjones at redhat.com  Mon Feb 15 07:45:52 2016
From: pjones at redhat.com (Peter Jones)
Date: Mon, 15 Feb 2016 10:45:52 -0500
Subject: [PATCH v2 1/2] efi: esrt: use memremap not ioremap to access
 ESRT table in memory
In-Reply-To: <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160215154551.GA785@redhat.com>

On Mon, Feb 15, 2016 at 12:32:32PM +0100, Ard Biesheuvel wrote:
> On ARM and arm64, ioremap() and memremap() are not interchangeable like
> on x86, and the use of ioremap() on ordinary RAM is typically flagged
> as an error if the memory region being mapped is also covered by the
> linear mapping, since that would lead to aliases with conflicting
> cacheability attributes.
> 
> Since what we are dealing with is not an I/O region with side effects,
> using ioremap() here is arguably incorrect anyway, so let's replace
> it with memremap instead. Also add a missing unmap on the success path,
> and drop a memblock_remove() call which does not belong here, this far
> into the boot sequence.
> 
> Cc: Peter Jones <pjones at redhat.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

Works on my test box and appears to be correct:

Tested-by: Peter Jones <pjones at redhat.com>
Acked-by: Peter Jones <pjones at redhat.com>

> ---
>  drivers/firmware/efi/esrt.c | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/firmware/efi/esrt.c b/drivers/firmware/efi/esrt.c
> index 22c5285f7705..f096a0a26dbd 100644
> --- a/drivers/firmware/efi/esrt.c
> +++ b/drivers/firmware/efi/esrt.c
> @@ -16,6 +16,7 @@
>  #include <linux/device.h>
>  #include <linux/efi.h>
>  #include <linux/init.h>
> +#include <linux/io.h>
>  #include <linux/kernel.h>
>  #include <linux/kobject.h>
>  #include <linux/list.h>
> @@ -385,15 +386,15 @@ static void cleanup_entry_list(void)
>  static int __init esrt_sysfs_init(void)
>  {
>  	int error;
> -	struct efi_system_resource_table __iomem *ioesrt;
> +	struct efi_system_resource_table *memesrt;
>  
>  	pr_debug("esrt-sysfs: loading.\n");
>  	if (!esrt_data || !esrt_data_size)
>  		return -ENOSYS;
>  
> -	ioesrt = ioremap(esrt_data, esrt_data_size);
> -	if (!ioesrt) {
> -		pr_err("ioremap(%pa, %zu) failed.\n", &esrt_data,
> +	memesrt = memremap(esrt_data, esrt_data_size, MEMREMAP_WB);
> +	if (!memesrt) {
> +		pr_err("memremap(%pa, %zu, MEMREMAP_WB) failed.\n", &esrt_data,
>  		       esrt_data_size);
>  		return -ENOMEM;
>  	}
> @@ -401,11 +402,12 @@ static int __init esrt_sysfs_init(void)
>  	esrt = kmalloc(esrt_data_size, GFP_KERNEL);
>  	if (!esrt) {
>  		pr_err("kmalloc failed. (wanted %zu bytes)\n", esrt_data_size);
> -		iounmap(ioesrt);
> +		memunmap(memesrt);
>  		return -ENOMEM;
>  	}
>  
> -	memcpy_fromio(esrt, ioesrt, esrt_data_size);
> +	memcpy(esrt, memesrt, esrt_data_size);
> +	memunmap(memesrt);
>  
>  	esrt_kobj = kobject_create_and_add("esrt", efi_kobj);
>  	if (!esrt_kobj) {
> @@ -432,8 +434,6 @@ static int __init esrt_sysfs_init(void)
>  	if (error)
>  		goto err_cleanup_list;
>  
> -	memblock_remove(esrt_data, esrt_data_size);
> -
>  	pr_debug("esrt-sysfs: loaded.\n");
>  
>  	return 0;
> -- 
> 2.5.0
> 


From pjones at redhat.com  Mon Feb 15 07:46:30 2016
From: pjones at redhat.com (Peter Jones)
Date: Mon, 15 Feb 2016 10:46:30 -0500
Subject: [PATCH v2 2/2] arm64/efi: esrt: add missing call to
 efi_esrt_init()
In-Reply-To: <1455535953-5056-3-git-send-email-ard.biesheuvel@linaro.org>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-3-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160215154629.GB785@redhat.com>

On Mon, Feb 15, 2016 at 12:32:33PM +0100, Ard Biesheuvel wrote:
> ESRT support is built by default for all architectures that define
> CONFIG_EFI. However, this support was not wired up yet for ARM/arm64,
> since efi_esrt_init() was never called. So add the missing call.
> 
> Since efi_esrt_init() uses efi_mem_desc_lookup(), which in turn relies
> on efi.memmap having been assigned and populated completetely, add the
> missing assignments of efi.memmap and efi.memmap->nr_map.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

Looks correct to me, but I can't test this one:
Acked-by: Peter Jones <pjones at redhat.com>

> ---
>  drivers/firmware/efi/arm-init.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
> index 9e15d571b53c..5c5e799bdb50 100644
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@ -197,10 +197,13 @@ void __init efi_init(void)
>  	memmap.map_end = memmap.map + params.mmap_size;
>  	memmap.desc_size = params.desc_size;
>  	memmap.desc_version = params.desc_ver;
> +	memmap.nr_map = params.mmap_size / params.desc_size;
> +	efi.memmap = &memmap;
>  
>  	if (uefi_init() < 0)
>  		return;
>  
> +	efi_esrt_init();
>  	reserve_regions();
>  	early_memunmap(memmap.map, params.mmap_size);
>  	memblock_mark_nomap(params.mmap & PAGE_MASK,
> -- 
> 2.5.0
> 


From will.deacon at arm.com  Mon Feb 15 07:51:09 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Feb 2016 15:51:09 +0000
Subject: [PATCH] arm/arm64/crypto: assure that ECB modes don't require an
 IV
In-Reply-To: <CAKv+Gu8_Z5=0dTeBsVgx_BT0c+_O5PNUCyKFjuDf9x470bxHOA@mail.gmail.com>
References: <1455292072-5236-1-git-send-email-jeremy.linton@arm.com>
 <CAKv+Gu8_Z5=0dTeBsVgx_BT0c+_O5PNUCyKFjuDf9x470bxHOA@mail.gmail.com>
Message-ID: <20160215155108.GG6298@arm.com>

On Fri, Feb 12, 2016 at 06:00:01PM +0100, Ard Biesheuvel wrote:
> On 12 February 2016 at 16:47, Jeremy Linton <jeremy.linton at arm.com> wrote:
> > ECB modes don't use an initialization vector. The kernel
> > /proc/crypto interface doesn't reflect this properly.
> >
> > Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
> 
> Thanks for spotting that!
> 
> Acked-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

Thanks, I'll queue this for -rc5.

Will


From nm at ti.com  Mon Feb 15 07:49:53 2016
From: nm at ti.com (Nishanth Menon)
Date: Mon, 15 Feb 2016 09:49:53 -0600
Subject: [PATCH] arm: dts: AM57XX: Correct the thermal thresholds
In-Reply-To: <56C153A3.3030508@ti.com>
References: <1454924705-8382-1-git-send-email-j-keerthy@ti.com>
 <20160209220901.GC28102@localhost.localdomain> <56BA6530.4030102@ti.com>
 <20160212222347.GO19432@atomide.com>
 <CAGo_u6r8-LJBWWrew0fV50Q+JnCxDj9PD57+9NoDm5TqCWL=jw@mail.gmail.com>
 <20160212224129.GP19432@atomide.com> <56C153A3.3030508@ti.com>
Message-ID: <56C1F3A1.4080709@ti.com>

On 02/14/2016 10:27 PM, Keerthy wrote:
> 
> 
> On Saturday 13 February 2016 04:11 AM, Tony Lindgren wrote:
>> * Nishanth Menon <nm at ti.com> [160212 14:32]:
>>> On Fri, Feb 12, 2016 at 4:23 PM, Tony Lindgren <tony at atomide.com> wrote:
>>>> * Nishanth Menon <nm at ti.com> [160209 14:17]:
>>>>> On 02/09/2016 04:09 PM, Eduardo Valentin wrote:
>>>>>> On Mon, Feb 08, 2016 at 03:15:05PM +0530, Keerthy wrote:
>>>>>>> The thermal threholds for am57xx are different from that of dra7.
>>>>>>> Correcting the thresholds for the same.
>>>>>>>
>>>>>>> Signed-off-by: Keerthy <j-keerthy at ti.com>
>>>>>>> ---
>>>>>>>
>>>>>>> Depends on: https://lkml.org/lkml/2016/2/8/90
>>>>>>>
>>>>>>>   arch/arm/boot/dts/am57xx-beagle-x15.dts | 24 ++++++++++++++++++++++++
>>>>>>>   1 file changed, 24 insertions(+)
>>>>>>>
>>>>>>> Index: linux/arch/arm/boot/dts/am57xx-beagle-x15.dts
>>>>>>> ===================================================================
>>>>>>> --- linux.orig/arch/arm/boot/dts/am57xx-beagle-x15.dts     2016-02-08 14:57:05.514959101 +0530
>>>>>>> +++ linux/arch/arm/boot/dts/am57xx-beagle-x15.dts  2016-02-08 14:57:05.510959168 +0530
>>>>>>
>>>>>> Sorry, did not bother to check, but is this the only user of am57xx?
>>>>>
>>>>> we will have AM57xx-IDK as well coming down the line. we already have
>>>>> arch/arm/boot/dts/am57xx-cl-som-am57x.dts
>>>>> arch/arm/boot/dts/am57xx-sbc-am57x.dts - not really sure what grade of
>>>>> silicon are used in cl-SOM and sbc boards.
>>>>
>>>> Hmm can this one wait for v4.6 or is it critical for v4.5-rc
>>>> cycle?
>>>
>>> personally, I'd like to NAK this patch -> lack of reference
>>> documentation, and guidance for various AM57xx boards in a generic
>>> patch should probably be followed IMHO.
>>
>> OK let's wait for that then.
> 
> OK. I will send a v2 with better documentation.



This data is in the AM572x datasheet:
http://www.ti.com/lit/ds/symlink/am5728.pdf

Table 5-3 in the current version contains the maximum junction
temperatures.

this indicates that there are "Commercial" and "extended" -> we may
need to introduce just 2 dtsis -> am57xx-commercial and
am57xx-extended and reuse those based on the part on the board. just a
suggestion..


-- 
Regards,
Nishanth Menon


From hdegoede at redhat.com  Mon Feb 15 07:52:38 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Mon, 15 Feb 2016 16:52:38 +0100
Subject: [linux-sunxi] Allwinner A64 MMC support
In-Reply-To: <56C1D9C0.6020601@arm.com>
References: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
 <56BE29A1.3060107@redhat.com> <56C1A590.6030500@arm.com>
 <56C1C7BB.1040602@redhat.com> <56C1D9C0.6020601@arm.com>
Message-ID: <56C1F446.9020801@redhat.com>

Hi,

On 15-02-16 14:59, Andre Przywara wrote:
> Hi Hans,
>
> ....
>
>>
>> p.s.
>>
>> I love the work you've been doing on the A64, I've not had a chance
>> to try it out yet though. Have you made any progress with getting
>> the mmc slot to work ?  If not maybe I can make some time I've
>> prior experience in bringing up the mmc slot on other Allwinner SoCs
>
> Thanks for that!
>
> So we made some progress on the weekend (with the help of #linux-sunxi):
> 1) The regulator node was stupidly put by me into a separate child node
> without putting address and size cells into. So I just moved it into
> /soc directly now and that seems to fixed the missing regulator.
> 2) The reset node is a allwinner,sun6i-a31-ahb1-reset, which does not
> get registered automatically, but by an explicit call from mach-sunxi/.
> I wonder why we do this (yes, I saw that comment, but still...) and if
> it would work with a normal MODULE_DEVICE_TABLE() declaration.
> There is and will be no equivalent to the mach- directory on arm64.
> 3) As Jens pointed out, the MMC IP block isn't really compatible.
> Changing the clocks is easy (done already), but we need to come up with
> code to cover the new phase setting registers in the A64 MMC register block.
>
> Interestingly somehow hacking this (pretending it is compatible) seems
> to work, though I got reports from people about mysterious kernel
> crashes, so I'm inclined to leave MMC out of the first patch series.
>
> So if you could take a look at the new registers (starting at offset
> 0x140) and work out what we actually need to do here, that would be
> great. I have no real clue about what they actually do and how they
> relate to the current output and sample clock phase.
> To me it looks like we might get away with just triggering the automatic
> calibration and the hardware does the rest for us - keep your fingers
> crossed ;-)

Just triggering the automatic calibration sounds good, this likely will
result in better values then the magic values we are currently using for
older SoCs.

As for the meaning of those registers, what we've been doing with the phase
registers so far pretty much boils down to look at what Allwinner BSP kernel
sources do, and then do the same in u-boot / the mainline driver since
the mmc controller documentation is very limited.

Do you have a git tree with your wip mmc support somewhere ? Then I or
maybe Chen-Yu can take a look when we've time.

Regards,

Hans


From tony at atomide.com  Mon Feb 15 08:01:15 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 15 Feb 2016 08:01:15 -0800
Subject: GPIO regression in Linux next caused by syscon change
In-Reply-To: <CA+gwMccZeYimupmGsMX8YbNH9eEA6=Xi=rupciubBwzktfjvBA@mail.gmail.com>
References: <20160213002643.GQ19432@atomide.com>
 <20160213004935.GR19432@atomide.com>
 <CA+gwMccZeYimupmGsMX8YbNH9eEA6=Xi=rupciubBwzktfjvBA@mail.gmail.com>
Message-ID: <20160215160115.GU19432@atomide.com>

* Philipp Zabel <philipp.zabel at gmail.com> [160214 11:24]:
> I've just replaced the of_iomap() call with an open coded version,
> calling of_address_to_resource() and ioremap() directly. That was
> needed so I can use the struct resource returned by
> of_address_to_resource() to set the syscon_config.max_register. I
> don't see where this could cause resource overlap. Does just setting
> syscon_config.max_register to zero again make the problem disappear?

Yes commenting out the syscon_config.max_register line in your patch
makes things work again.

So what does that tell us about the problem?

Regards,

Tony


From linux at arm.linux.org.uk  Mon Feb 15 08:03:06 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Feb 2016 16:03:06 +0000
Subject: [PATCH 4/4] ARM: remove asm/gpio.h
In-Reply-To: <1455551208-2825510-5-git-send-email-arnd@arndb.de>
References: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <1455551208-2825510-1-git-send-email-arnd@arndb.de>
 <1455551208-2825510-5-git-send-email-arnd@arndb.de>
Message-ID: <20160215160305.GG10826@n2100.arm.linux.org.uk>

On Mon, Feb 15, 2016 at 04:46:31PM +0100, Arnd Bergmann wrote:
> -#if CONFIG_ARCH_NR_GPIO > 0
> -#define ARCH_NR_GPIOS CONFIG_ARCH_NR_GPIO
> -#endif
...
> diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
> index 40ec1433f05d..2d04b321db13 100644
> --- a/include/asm-generic/gpio.h
> +++ b/include/asm-generic/gpio.h
> @@ -26,8 +26,12 @@
>   */
>  
>  #ifndef ARCH_NR_GPIOS
> +#ifdef CONFIG_ARCH_NR_GPIO
> +#define ARCH_NR_GPIOS CONFIG_ARCH_NR_GPIO
> +#else
>  #define ARCH_NR_GPIOS		512
>  #endif
> +#endif

This really isn't the same thing, especially when you look at:

config ARCH_NR_GPIO
        int
        default 1024 if ARCH_BRCMSTB || ARCH_SHMOBILE || ARCH_TEGRA || \
                ARCH_ZYNQ
        default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || \
                SOC_DRA7XX || ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210
        default 416 if ARCH_SUNXI
        default 392 if ARCH_U8500
        default 352 if ARCH_VT8500
        default 288 if ARCH_ROCKCHIP
        default 264 if MACH_H4700
        default 0

This has the effect of causing anything not mentioned above to end up
with ARCH_NR_GPIOS set to zero.

You really should _not_ be making these kinds of functional changes
when moving code around.  Separate the two changes: either first move
the code, and have a separate patch to make the functional changes, or
make the functional changes first, and then move the code around.

I'd have thought you would've known this by now...

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From michal.simek at xilinx.com  Mon Feb 15 08:05:17 2016
From: michal.simek at xilinx.com (Michal Simek)
Date: Mon, 15 Feb 2016 17:05:17 +0100
Subject: [PATCH 1/3] ARM: zynq: Move early printk virtual address to vmalloc
 area
Message-ID: <67c9013fc61f53515934b54847a05df8b8e1504a.1455552315.git.michal.simek@xilinx.com>

The patch
"ARM: 8432/1: move VMALLOC_END from 0xff000000 to 0xff800000"
(sha1: 6ff0966052c46efb53980b8a1add2e7b49c9f560)
has moved also start of VMALLOC area because size didn't change.
That's why origin location of vmalloc was
   vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
and now is
   vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)

That's why uart virtual addresses need to be changed to reflect this new
memory setup. Starting address should be vmalloc start address.

Signed-off-by: Michal Simek <michal.simek at xilinx.com>
---

 arch/arm/include/debug/zynq.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/debug/zynq.S b/arch/arm/include/debug/zynq.S
index de86b9247564..060cb5b49bfd 100644
--- a/arch/arm/include/debug/zynq.S
+++ b/arch/arm/include/debug/zynq.S
@@ -20,9 +20,9 @@
 #define UART_SR_TXEMPTY		0x00000008	/* TX FIFO empty */
 
 #define UART0_PHYS		0xE0000000
-#define UART0_VIRT		0xF0000000
+#define UART0_VIRT		0xF0800000
 #define UART1_PHYS		0xE0001000
-#define UART1_VIRT		0xF0001000
+#define UART1_VIRT		0xF0801000
 
 #if IS_ENABLED(CONFIG_DEBUG_ZYNQ_UART1)
 # define LL_UART_PADDR		UART1_PHYS
-- 
1.9.1



From michal.simek at xilinx.com  Mon Feb 15 08:05:18 2016
From: michal.simek at xilinx.com (Michal Simek)
Date: Mon, 15 Feb 2016 17:05:18 +0100
Subject: [PATCH 2/3] serial: xuartps: Enable OF earlycon support
In-Reply-To: <67c9013fc61f53515934b54847a05df8b8e1504a.1455552315.git.michal.simek@xilinx.com>
References: <67c9013fc61f53515934b54847a05df8b8e1504a.1455552315.git.michal.simek@xilinx.com>
Message-ID: <23ab10a19b21df2ef17a5bb6ce2a70d2d3fd3551.1455552315.git.michal.simek@xilinx.com>

Support early console setup via DT for all listed compatible strings.

Signed-off-by: Michal Simek <michal.simek at xilinx.com>
---

 drivers/tty/serial/xilinx_uartps.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index 009e0dbc12d2..6f5657766815 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1094,6 +1094,9 @@ static int __init cdns_early_console_setup(struct earlycon_device *device,
 	return 0;
 }
 EARLYCON_DECLARE(cdns, cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns_a, "xlnx,xuartps", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns_b, "cdns,uart-r1p8", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns_c, "cdns,uart-r1p12", cdns_early_console_setup);
 
 /**
  * cdns_uart_console_write - perform write operation
-- 
1.9.1



From michal.simek at xilinx.com  Mon Feb 15 08:05:19 2016
From: michal.simek at xilinx.com (Michal Simek)
Date: Mon, 15 Feb 2016 17:05:19 +0100
Subject: [PATCH 3/3] ARM: zynq: Use earlycon instead of earlyprintk
In-Reply-To: <67c9013fc61f53515934b54847a05df8b8e1504a.1455552315.git.michal.simek@xilinx.com>
References: <67c9013fc61f53515934b54847a05df8b8e1504a.1455552315.git.michal.simek@xilinx.com>
Message-ID: <8cd6d86437baf0a7a443f4d288a9c6a9df66ffc3.1455552315.git.michal.simek@xilinx.com>

Use early console instead of earlyprintk which is supposed to use for
very early debugging (DEBUG_LL).

Signed-off-by: Michal Simek <michal.simek at xilinx.com>
---

 arch/arm/boot/dts/zynq-parallella.dts | 2 +-
 arch/arm/boot/dts/zynq-zc702.dts      | 2 +-
 arch/arm/boot/dts/zynq-zc706.dts      | 2 +-
 arch/arm/boot/dts/zynq-zed.dts        | 2 +-
 arch/arm/boot/dts/zynq-zybo.dts       | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/zynq-parallella.dts b/arch/arm/boot/dts/zynq-parallella.dts
index 9efd16cb2859..307ed201d658 100644
--- a/arch/arm/boot/dts/zynq-parallella.dts
+++ b/arch/arm/boot/dts/zynq-parallella.dts
@@ -34,7 +34,7 @@
 	};
 
 	chosen {
-		bootargs = "earlyprintk root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait";
+		bootargs = "earlycon root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait";
 		stdout-path = "serial0:115200n8";
 	};
 };
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index cb64209bca08..e96959b2e67a 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -30,7 +30,7 @@
 	};
 
 	chosen {
-		bootargs = "earlyprintk";
+		bootargs = "earlycon";
 		stdout-path = "serial0:115200n8";
 	};
 
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index abf5d238ae04..be6a986bbbd8 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -30,7 +30,7 @@
 	};
 
 	chosen {
-		bootargs = "earlyprintk";
+		bootargs = "earlycon";
 		stdout-path = "serial0:115200n8";
 	};
 
diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts
index b9f2522012e8..7250c1eac7f9 100644
--- a/arch/arm/boot/dts/zynq-zed.dts
+++ b/arch/arm/boot/dts/zynq-zed.dts
@@ -29,7 +29,7 @@
 	};
 
 	chosen {
-		bootargs = "earlyprintk";
+		bootargs = "earlycon";
 		stdout-path = "serial0:115200n8";
 	};
 
diff --git a/arch/arm/boot/dts/zynq-zybo.dts b/arch/arm/boot/dts/zynq-zybo.dts
index 16c9cacd668d..bd992e036aa9 100644
--- a/arch/arm/boot/dts/zynq-zybo.dts
+++ b/arch/arm/boot/dts/zynq-zybo.dts
@@ -29,7 +29,7 @@
 	};
 
 	chosen {
-		bootargs = "earlyprintk";
+		bootargs = "earlycon";
 		stdout-path = "serial0:115200n8";
 	};
 
-- 
1.9.1



From marc.zyngier at arm.com  Mon Feb 15 08:08:12 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Feb 2016 16:08:12 +0000
Subject: [PATCH v6 2/3] Documentation: gpio: Update description for X-Gene
 standby GPIO controller DTS binding
In-Reply-To: <CAFopSPRwd8cHnH8efegYVv52hPVTyk=VW9OrZZtSCj6Szj-K4Q@mail.gmail.com>
References: <1455512263-18183-1-git-send-email-qnguyen@apm.com>
 <1455512263-18183-3-git-send-email-qnguyen@apm.com>
 <56C1CA6E.1060606@arm.com>
 <CAFopSPRwd8cHnH8efegYVv52hPVTyk=VW9OrZZtSCj6Szj-K4Q@mail.gmail.com>
Message-ID: <56C1F7EC.3020701@arm.com>

On 15/02/16 15:31, Quan Nguyen wrote:
> On Mon, Feb 15, 2016 at 7:54 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> On 15/02/16 04:57, Quan Nguyen wrote:
>>> Update description for X-Gene standby GPIO controller DTS binding to
>>> support GPIO line configuration as input, output or external IRQ pin.
>>>
>>> Signed-off-by: Y Vo <yvo at apm.com>
>>> Signed-off-by: Quan Nguyen <qnguyen at apm.com>
>>> ---
>>>  .../devicetree/bindings/gpio/gpio-xgene-sb.txt     | 47 ++++++++++++++++++----
>>>  1 file changed, 40 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
>>> index dae1300..7b8b4cb 100644
>>> --- a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
>>> +++ b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
>>> @@ -1,10 +1,20 @@
>>>  APM X-Gene Standby GPIO controller bindings
>>>
>>> -This is a gpio controller in the standby domain.
>>> -
>>> -There are 20 GPIO pins from 0..21. There is no GPIO_DS14 or GPIO_DS15,
>>> -only GPIO_DS8..GPIO_DS13 support interrupts. The IRQ mapping
>>> -is currently 1-to-1 on interrupts 0x28 thru 0x2d.
>>> +This is a gpio controller in the standby domain. It also supports interrupt in
>>> +some particular pins which are sourced to its parent interrupt controller
>>> +as diagram below:
>>> +                           +-----------------+
>>> +                           | X-Gene standby  |
>>> +                           | GPIO controller +--------- GPIO_0
>>> ++------------+             |                 | ...
>>> +| Parent IRQ |             |                 +--------- GPIO_8/EXT_INT_0
>>> +| controller |  EXT_INT_0  |                 | ...
>>> +| (GICv2)    +-------------+                 +--------- GPIO_[N+8]/EXT_INT_N
>>> +|            |  ...        |                 |
>>> +|            |  EXT_INT_N  |                 +--------- GPIO_[N+9]
>>> +|            +-------------+                 | ...
>>> +|            |             |                 +--------- GPIO_MAX
>>> ++------------+             +-----------------+
>>>
>>>  Required properties:
>>>  - compatible: "apm,xgene-gpio-sb" for the X-Gene Standby GPIO controller
>>> @@ -15,10 +25,18 @@ Required properties:
>>>               0 = active high
>>>               1 = active low
>>>  - gpio-controller: Marks the device node as a GPIO controller.
>>> -- interrupts: Shall contain exactly 6 interrupts.
>>> +- interrupts: The EXT_INT_0 parent interrupt resource must be listed first.
>>> +- interrupt-parent: Phandle of the parent interrupt controller.
>>> +- interrupt-cells: Should be two.
>>> +       - first cell is 0-N coresponding for EXT_INT_0 to EXT_INT_N.
>>> +       - second cell is used to specify flags.
>>> +- interrupt-controller: Marks the device node as an interrupt controller.
>>> +- apm,nr-gpios: Optional, specify number of gpios pin.
>>> +- apm,nr-irqs: Optional, specify number of interrupt pins.
>>> +- apm,irq-start: Optional, specify lowest gpio pin support interrupt.
>>
>> This is quite ambiguous. Is that relative to the GIC? Assuming this is
>> the case, you should then document it, specify the type of interrupt
>> (SPI?), and whether this is 0- or 32-based (the code seems to indicate
>> that is is 0-based).
>>
> 
> Hi Marc, Let me explain by diagram below.
> As you can also see in diagram above, the lowest gpio pin that
> supports interrupt is GPIO_8 (EXT_INT_0),
> and hence, apm,irq-start=<8> as default.
> 
>                                            +-----------------+
>                                            | X-Gene standby  |
>                                            | GPIO controller +--------- GPIO_0
> +------------+                             |                 | ...
> | Parent IRQ |                             |
> +--------- GPIO_[apm,irq-start]/EXT_INT_0
> | controller |  EXT_INT_0                  |                 | ...
> | (GICv2)    +-----------------------------+
> +--------- GPIO_[apm,nr-irqs + apm,irq-start - 1]/EXT_INT_[apm,nr-irqs
> - 1]
> |            |  ...                        |                 |
> |            |  EXT_INT_[apm,nr-irqs - 1]  |
> +--------- GPIO_[apm,nr-irqs + apm,irq-start]
> |            +-----------------------------+                 | ...
> |            |                             |                 +--------- GPIO_MAX
> +------------+                             +-----------------+
> 
> To fix this ambiguity, I'm thinking to change it to:
> "apm,irq-start: Optional, specify index of first gpio pin
> corresponding to EXT_INT_0, default is 8."

I think you are missing the point I'm trying to make. There are two ways
to refer to an SPI: either by its absolute number (INT32 for example) or
by its relative number (SPI0). SPI0 and INT32 are the same interrupt.
Just with a different base.

My question is: which base are you using? By looking at the code, I
think you're using the absolute version (INTx). And as your controller
seems to be very GIC specific, you should add a pointer to the GIC
documentation.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From lars at metafoo.de  Mon Feb 15 08:01:09 2016
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Mon, 15 Feb 2016 17:01:09 +0100
Subject: [PATCH 1/4] gpio: remove broken irq_to_gpio() interface
In-Reply-To: <1455551208-2825510-2-git-send-email-arnd@arndb.de>
References: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <1455551208-2825510-1-git-send-email-arnd@arndb.de>
 <1455551208-2825510-2-git-send-email-arnd@arndb.de>
Message-ID: <56C1F645.1070405@metafoo.de>

On 02/15/2016 04:46 PM, Arnd Bergmann wrote:
> +static inline __deprecated int irq_to_gpio(unsigned int irq)
> +{
> +	/* this has clearly not worked for a long time */
> +	return -EINVAL;
> +}
> +
>  #define IRQ_TO_BIT(irq) BIT(irq_to_gpio(irq) & 0x1f)

The issue seems to be a fallout from commit 832f5dacfa0b ("MIPS: Remove all
the uses of custom gpio.h").

The irq_to_gpio() should be replaced with "(irq - JZ4740_IRQ_GPIO(0))".

- Lars


From will.deacon at arm.com  Mon Feb 15 08:10:46 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Feb 2016 16:10:46 +0000
Subject: [PATCH v4 05/23] arm64: Add ARM64_HAS_VIRT_HOST_EXTN feature
In-Reply-To: <1455216004-19499-6-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
 <1455216004-19499-6-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160215161045.GH6298@arm.com>

On Thu, Feb 11, 2016 at 06:39:46PM +0000, Marc Zyngier wrote:
> Add a new ARM64_HAS_VIRT_HOST_EXTN features to indicate that the
> CPU has the ARMv8.1 VHE capability.
> 
> This will be used to trigger kernel patching in KVM.
> 
> Acked-by: Christoffer Dall <christoffer.dall at linaro.org>
> Acked-by: Catalin Marinas <catalin.marinas at arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/cpufeature.h |  3 ++-
>  arch/arm64/kernel/cpufeature.c      | 11 +++++++++++
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index 8f271b8..c705d6a 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -30,8 +30,9 @@
>  #define ARM64_HAS_LSE_ATOMICS			5
>  #define ARM64_WORKAROUND_CAVIUM_23154		6
>  #define ARM64_WORKAROUND_834220			7
> +#define ARM64_HAS_VIRT_HOST_EXTN		8
>  
> -#define ARM64_NCAPS				8
> +#define ARM64_NCAPS				9

Just a heads up, but this conflicts with the for-next/core branch, where
I used cap 8 to identify the absence of a h/w prefetcher.

Will


From linux at arm.linux.org.uk  Mon Feb 15 08:12:28 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Feb 2016 16:12:28 +0000
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <56C1F19F.8090100@roeck-us.net>
References: <20160214165010.GA3189@roeck-us.net>
 <20160215105909.GH12289@pengutronix.de>
 <56C1F19F.8090100@roeck-us.net>
Message-ID: <20160215161228.GH10826@n2100.arm.linux.org.uk>

On Mon, Feb 15, 2016 at 07:41:19AM -0800, Guenter Roeck wrote:
> On 02/15/2016 02:59 AM, Uwe Kleine-K?nig wrote:
> >Hello Guenter,
> >
> >On Sun, Feb 14, 2016 at 08:50:10AM -0800, Guenter Roeck wrote:
> >>Uwe,
> >>
> >>Your patch 'driver-core: platform: probe of-devices only using list of
> >>compatibles' causes the following qemu tests to crash in -next.
> >>
> >>arm:vexpress-a9:vexpress_defconfig:vexpress-v2p-ca9
> >>arm:vexpress-a15:vexpress_defconfig:vexpress-v2p-ca15-tc1
> >>arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
> >>arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
> >>
> >>Crash log:
> >>
> >>VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6
> >>Please append a correct "root=" boot option; here are the available partitions:
> >>1f00          131072 mtdblock0  (driver?)
> >>1f01           32768 mtdblock1  (driver?)
> >>Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
> >
> >Can you provide a complete boot log? This might already reveal which
> >device is failing. It might not be the mmci device but something it
> >depends on (clock, bus parent, irq).
> >
> 
> Sure, something else may be failing, but why does reverting your patch
> fix the problem ?
> 
> Anyway, complete logs are at http://kerneltests.org/builders.
> 
> http://kerneltests.org/builders/qemu-arm-next/builds/376/steps/qemubuildcommand/logs/stdio
> 
> is the most recent log (next-20120215). Look for the vexpress crashes; the overo
> crash bisected to to 'PM / OPP: Disable OPPs that aren't supported by the regulator',
> in next-20160212, which I have not fully analyzed yet, and the beagle crashes
> as well as the 'new' overo crash are brand new.

Looking at the vexpress-ca9 one, nothing stands out to me apart from the
lack of messages about a MMC driver.  I don't see anything there which
indicates why that would be.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From a0393675 at ti.com  Mon Feb 15 08:13:30 2016
From: a0393675 at ti.com (Keerthy)
Date: Mon, 15 Feb 2016 21:43:30 +0530
Subject: [PATCH] arm: dts: AM57XX: Correct the thermal thresholds
In-Reply-To: <56C1F3A1.4080709@ti.com>
References: <1454924705-8382-1-git-send-email-j-keerthy@ti.com>
 <20160209220901.GC28102@localhost.localdomain> <56BA6530.4030102@ti.com>
 <20160212222347.GO19432@atomide.com>
 <CAGo_u6r8-LJBWWrew0fV50Q+JnCxDj9PD57+9NoDm5TqCWL=jw@mail.gmail.com>
 <20160212224129.GP19432@atomide.com> <56C153A3.3030508@ti.com>
 <56C1F3A1.4080709@ti.com>
Message-ID: <56C1F92A.1020803@ti.com>



On Monday 15 February 2016 09:19 PM, Nishanth Menon wrote:
> On 02/14/2016 10:27 PM, Keerthy wrote:
>>
>>
>> On Saturday 13 February 2016 04:11 AM, Tony Lindgren wrote:
>>> * Nishanth Menon <nm at ti.com> [160212 14:32]:
>>>> On Fri, Feb 12, 2016 at 4:23 PM, Tony Lindgren <tony at atomide.com> wrote:
>>>>> * Nishanth Menon <nm at ti.com> [160209 14:17]:
>>>>>> On 02/09/2016 04:09 PM, Eduardo Valentin wrote:
>>>>>>> On Mon, Feb 08, 2016 at 03:15:05PM +0530, Keerthy wrote:
>>>>>>>> The thermal threholds for am57xx are different from that of dra7.
>>>>>>>> Correcting the thresholds for the same.
>>>>>>>>
>>>>>>>> Signed-off-by: Keerthy <j-keerthy at ti.com>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> Depends on: https://lkml.org/lkml/2016/2/8/90
>>>>>>>>
>>>>>>>>    arch/arm/boot/dts/am57xx-beagle-x15.dts | 24 ++++++++++++++++++++++++
>>>>>>>>    1 file changed, 24 insertions(+)
>>>>>>>>
>>>>>>>> Index: linux/arch/arm/boot/dts/am57xx-beagle-x15.dts
>>>>>>>> ===================================================================
>>>>>>>> --- linux.orig/arch/arm/boot/dts/am57xx-beagle-x15.dts     2016-02-08 14:57:05.514959101 +0530
>>>>>>>> +++ linux/arch/arm/boot/dts/am57xx-beagle-x15.dts  2016-02-08 14:57:05.510959168 +0530
>>>>>>>
>>>>>>> Sorry, did not bother to check, but is this the only user of am57xx?
>>>>>>
>>>>>> we will have AM57xx-IDK as well coming down the line. we already have
>>>>>> arch/arm/boot/dts/am57xx-cl-som-am57x.dts
>>>>>> arch/arm/boot/dts/am57xx-sbc-am57x.dts - not really sure what grade of
>>>>>> silicon are used in cl-SOM and sbc boards.
>>>>>
>>>>> Hmm can this one wait for v4.6 or is it critical for v4.5-rc
>>>>> cycle?
>>>>
>>>> personally, I'd like to NAK this patch -> lack of reference
>>>> documentation, and guidance for various AM57xx boards in a generic
>>>> patch should probably be followed IMHO.
>>>
>>> OK let's wait for that then.
>>
>> OK. I will send a v2 with better documentation.
>
>
>
> This data is in the AM572x datasheet:
> http://www.ti.com/lit/ds/symlink/am5728.pdf
>
> Table 5-3 in the current version contains the maximum junction
> temperatures.
>
> this indicates that there are "Commercial" and "extended" -> we may
> need to introduce just 2 dtsis -> am57xx-commercial and
> am57xx-extended and reuse those based on the part on the board. just a
> suggestion..

Or use the minimum of the 2 to be on the safer side if we have to deal 
with one dtsi?

Regards,
Keerthy
>
>


From p.zabel at pengutronix.de  Mon Feb 15 08:16:01 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon, 15 Feb 2016 17:16:01 +0100
Subject: GPIO regression in Linux next caused by syscon change
In-Reply-To: <20160215160115.GU19432@atomide.com>
References: <20160213002643.GQ19432@atomide.com>
 <20160213004935.GR19432@atomide.com>
 <CA+gwMccZeYimupmGsMX8YbNH9eEA6=Xi=rupciubBwzktfjvBA@mail.gmail.com>
 <20160215160115.GU19432@atomide.com>
Message-ID: <1455552961.4899.37.camel@pengutronix.de>

Am Montag, den 15.02.2016, 08:01 -0800 schrieb Tony Lindgren:
> * Philipp Zabel <philipp.zabel at gmail.com> [160214 11:24]:
> > I've just replaced the of_iomap() call with an open coded version,
> > calling of_address_to_resource() and ioremap() directly. That was
> > needed so I can use the struct resource returned by
> > of_address_to_resource() to set the syscon_config.max_register. I
> > don't see where this could cause resource overlap. Does just setting
> > syscon_config.max_register to zero again make the problem disappear?
> 
> Yes commenting out the syscon_config.max_register line in your patch
> makes things work again.
> 
> So what does that tell us about the problem?

Maybe some out of bounds writes that previously worked are now catched
by the max_register check in regmap_writable and regmap_write returns
-EIO instead of the write being executed.
Is there any omap_ctrl_write?() call with an offset > 0x32c into
scm_conf?

regards
Philipp



From p.zabel at pengutronix.de  Mon Feb 15 08:16:55 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon, 15 Feb 2016 17:16:55 +0100
Subject: [PATCH v2 10/17] drm/imx: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <8bf274e8f6908142a9f940d3f2913e4a735e0caa.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
 <8bf274e8f6908142a9f940d3f2913e4a735e0caa.1455540137.git.palminha@synopsys.com>
Message-ID: <1455553015.4899.38.camel@pengutronix.de>

Am Montag, den 15.02.2016, 13:00 +0000 schrieb Carlos Palminha:
> mode_fixup function for encoder drivers became optional with patch
> http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com
> 
> This patch set nukes all the dummy mode_fixup implementations.
> 
> (made on top of Daniel topic/drm-misc branch)
> 
> Signed-off-by: Carlos Palminha <palminha at synopsys.com>

Acked-by: Philipp Zabel <p.zabel at pengutronix.de>

regards
Philipp



From u.kleine-koenig at pengutronix.de  Mon Feb 15 08:27:53 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Mon, 15 Feb 2016 17:27:53 +0100
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160215144344.GF10826@n2100.arm.linux.org.uk>
References: <20160214165010.GA3189@roeck-us.net>
 <20160215105909.GH12289@pengutronix.de> <56C1CE95.6020206@arm.com>
 <20160215144344.GF10826@n2100.arm.linux.org.uk>
Message-ID: <20160215162753.GI12289@pengutronix.de>

Hello Russell,

On Mon, Feb 15, 2016 at 02:43:44PM +0000, Russell King - ARM Linux wrote:
> On Mon, Feb 15, 2016 at 01:11:49PM +0000, Robin Murphy wrote:
> > FWIW the PL180 on my Juno still works fine with this patch picked on top of
> > -rc3, so the issue would seem to be something else - From a quick comparison
> > between the DTs I see a slight difference in compatible strings for the
> > clocks, but the more likely-looking suspect is that the VExpress DT
> > references some GPIOs where the Juno DT doesn't.
> 
> Maybe it would be a good idea that Uwe creates a patch which initially
> warns when a DT platform device falls back to matching via the platform
> strings?
> 
> It's likely that the "basic subsystem" platform drivers are silent when
> they probe, so having notification of a fallback would at least put
> something into the kernel log when that happens - and then later change
> that to be a hard failure (as Uwe is trying to do with his patch.)
> 
> However, I have to bring up another point: is what Uwe is trying to do
> actually the right thing?  The DT platform device code has the ability
> to create standard platform devices from DT, with an of_node, but with
> standard names, and platform data.  It's there for compatibility with
> older systems, and is there to allow systems to be transitioned over.
> 
> This patch breaks all that: despite the DT code changing the platform
> device bus_id from the address.nodename format to the standard format
> (thus allowing unconverted platform drivers to match), this patch
> means that because the platform device has a of_node attached, this
> will now fail.
> 
> Therefore, I think Uwe's patch is just wrong - or, if it's something we
> want, the auxdata table support code needs to _also_ be ripped out of
> the drivers/of/platform.c code, but that then means anyone who wants to
> go through the conversion has a big flag-day change to go through.

That's a valid concern I wasn't aware of when I created the patch.

So maybe just emitting a warning as you suggested is a good idea. And
additionally only emit it when the driver is dt aware, too.

Greg, can you drop this patch, or do you need a proper changelog for a
revert? On top of that I'd then create a new patch which is more
conservative.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From vinod.koul at intel.com  Mon Feb 15 08:35:24 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 15 Feb 2016 22:05:24 +0530
Subject: [PATCH 4/4] dmaengine: pxa_dma: fix the maximum requestor line
In-Reply-To: <1455225798-9510-5-git-send-email-robert.jarzmik@free.fr>
References: <1455225798-9510-1-git-send-email-robert.jarzmik@free.fr>
 <1455225798-9510-5-git-send-email-robert.jarzmik@free.fr>
Message-ID: <20160215163524.GI19598@localhost>

On Thu, Feb 11, 2016 at 10:23:18PM +0100, Robert Jarzmik wrote:
> @@ -1399,13 +1405,17 @@ static int pxad_probe(struct platform_device *op)
>  		return PTR_ERR(pdev->base);
>  
>  	of_id = of_match_device(pxad_dt_ids, &op->dev);
> -	if (of_id)
> +	if (of_id) {
>  		of_property_read_u32(op->dev.of_node, "#dma-channels",
>  				     &dma_channels);
> -	else if (pdata && pdata->dma_channels)
> +		of_property_read_u32(op->dev.of_node, "#requestors",
> +				     &nb_requestors);

I think we should check the return value here. This might be err in case
when we have older DT on platform, but still should work with default in
that case

> +	} else if (pdata && pdata->dma_channels) {
>  		dma_channels = pdata->dma_channels;
> -	else
> +		nb_requestors = pdata->nb_requestors;
> +	} else {
>  		dma_channels = 32;	/* default 32 channel */
> +	}

-- 
~Vinod


From sebott at linux.vnet.ibm.com  Mon Feb 15 08:38:43 2016
From: sebott at linux.vnet.ibm.com (Sebastian Ott)
Date: Mon, 15 Feb 2016 17:38:43 +0100 (CET)
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160215113159.GA28832@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name> <56BE00E7.1010303@de.ibm.com>
 <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
 <alpine.LFD.2.20.1602131238260.1910@schleppi>
 <20160215113159.GA28832@node.shutemov.name>
Message-ID: <alpine.LFD.2.20.1602151736120.1820@schleppi>

On Mon, 15 Feb 2016, Kirill A. Shutemov wrote:
> > [   59.851421] list_del corruption. next->prev should be 000000006e1eb000, but was 0000000000000400
> 
> This kinda interesting: 0x400 is TAIL_MAPPING.. Hm..
> 
> Could you check if you see the problem on commit 1c290f642101 and its
> immediate parent?

Both 1c290f642101 and 1c290f642101^ survived 20 compile runs each.

Sebastian



From gerald.schaefer at de.ibm.com  Mon Feb 15 08:41:19 2016
From: gerald.schaefer at de.ibm.com (Gerald Schaefer)
Date: Mon, 15 Feb 2016 17:41:19 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe
 also on PowerPC and ARM)
In-Reply-To: <20160212231510.GB15142@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
Message-ID: <20160215174119.53b56b86@thinkpad>

On Sat, 13 Feb 2016 01:15:10 +0200
"Kirill A. Shutemov" <kirill at shutemov.name> wrote:

> 
> I'm trying to wrap my head around the issue and I don't think missing
> serialization with gup_fast is the cause -- we just don't need it
> anymore.
> 
> Previously, __split_huge_page_splitting() required serialization against
> gup_fast to make sure nobody can obtain new reference to the page after
> __split_huge_page_splitting() returns. This was a way to stabilize page
> references before starting to distribute them from head page to tail
> pages.
> 
> With new refcounting, we don't care about this. Splitting PMD is now
> decoupled from splitting underlying compound page. It's okay to get new
> pins after split_huge_pmd(). To stabilize page references during
> split_huge_page() we rely on setting up migration entries once all
> pmds are split into page table entries.
> 
> The theory that serialization against gup_fast is not a root cause of the
> crashes is consistent no crashes on arm64. Problem is somewhere else.

Hmm, ok, I just relied on the commit message of commit fecffad25458, which
talks about "pmdp_clear_flush() will do IPI as needed for fast_gup", as well
as the comments in mm/gup.c, which also still talk about IPIs and THP
splitting.

If IPI serialization with fast_gup is not needed anymore for THP splitting,
please fix at least the comments in mm/gup.c.

> 
> > > (It also does some some other magic to the attach_count, which might hold off
> > > finish_arch_post_lock_switch while some flushing is happening, but this should
> > > be unrelated here)
> > > 
> > > 
> > > > I'm also confused by pmd_none() is equal to !pmd_present() on s390. Hm?
> > > 
> > > Don't know, Gerald or Martin?
> > 
> > The implementation frequently changes depending on how many new bits Martin
> > needs to squeeze out :-)
> 
> One bit was freed up by the commit you've pointed to as a cause.
> I wounder If it's possible that screw up something while removing it? I
> don't see it, but who knows.
> 
> Could you check if revert of fecffad25458 helps?

I tried reverting fecffad25458, plus re-adding a call to pmdp_splitting_flush()
in __split_huge_pmd_locked(), and I could still reproduce the crashes, so I
guess it really isn't related to fast_gup vs. THP splitting.

> 
> And could you share how crashes looks like? I haven't seen backtraces yet.
> 
> > We don't have a _PAGE_PRESENT bit for pmds, so pmd_present() just checks if the
> > entry is not empty. pmd_none() of course does the opposite, it checks if it is
> > empty.
> 



From vincent.abriou at st.com  Mon Feb 15 08:44:13 2016
From: vincent.abriou at st.com (Vincent ABRIOU)
Date: Mon, 15 Feb 2016 17:44:13 +0100
Subject: [PATCH v2 16/17] drm/sti: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <7f47c6a7b00e4f16af672ebf3a277e31ad117e21.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
 <7f47c6a7b00e4f16af672ebf3a277e31ad117e21.1455540137.git.palminha@synopsys.com>
Message-ID: <56C2005D.3020302@st.com>



On 02/15/2016 02:01 PM, Carlos Palminha wrote:
> mode_fixup function for encoder drivers became optional with patch
> http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com
>
> This patch set nukes all the dummy mode_fixup implementations.
>
> (made on top of Daniel topic/drm-misc branch)
>
> Signed-off-by: Carlos Palminha <palminha at synopsys.com>
> ---
>   drivers/gpu/drm/sti/sti_tvout.c | 10 ----------
>   1 file changed, 10 deletions(-)
>

Acked-by: Vincent Abriou <vincent.abriou at st.com>

BR
Vincent

From tony at atomide.com  Mon Feb 15 08:47:57 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 15 Feb 2016 08:47:57 -0800
Subject: GPIO regression in Linux next caused by syscon change
In-Reply-To: <1455552961.4899.37.camel@pengutronix.de>
References: <20160213002643.GQ19432@atomide.com>
 <20160213004935.GR19432@atomide.com>
 <CA+gwMccZeYimupmGsMX8YbNH9eEA6=Xi=rupciubBwzktfjvBA@mail.gmail.com>
 <20160215160115.GU19432@atomide.com>
 <1455552961.4899.37.camel@pengutronix.de>
Message-ID: <20160215164757.GV19432@atomide.com>

* Philipp Zabel <p.zabel at pengutronix.de> [160215 08:17]:
> Am Montag, den 15.02.2016, 08:01 -0800 schrieb Tony Lindgren:
> > * Philipp Zabel <philipp.zabel at gmail.com> [160214 11:24]:
> > > I've just replaced the of_iomap() call with an open coded version,
> > > calling of_address_to_resource() and ioremap() directly. That was
> > > needed so I can use the struct resource returned by
> > > of_address_to_resource() to set the syscon_config.max_register. I
> > > don't see where this could cause resource overlap. Does just setting
> > > syscon_config.max_register to zero again make the problem disappear?
> > 
> > Yes commenting out the syscon_config.max_register line in your patch
> > makes things work again.
> > 
> > So what does that tell us about the problem?
> 
> Maybe some out of bounds writes that previously worked are now catched
> by the max_register check in regmap_writable and regmap_write returns
> -EIO instead of the write being executed.

Hmm weird that something like that would not produce errors?

> Is there any omap_ctrl_write?() call with an offset > 0x32c into
> scm_conf?

Indeed, that's where things go wrong. Adding Tero to Cc, something
is wrong there.

Regards,

Tony


From gregkh at linuxfoundation.org  Mon Feb 15 08:49:37 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 Feb 2016 08:49:37 -0800
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160215162753.GI12289@pengutronix.de>
References: <20160214165010.GA3189@roeck-us.net>
 <20160215105909.GH12289@pengutronix.de> <56C1CE95.6020206@arm.com>
 <20160215144344.GF10826@n2100.arm.linux.org.uk>
 <20160215162753.GI12289@pengutronix.de>
Message-ID: <20160215164937.GC25556@kroah.com>

On Mon, Feb 15, 2016 at 05:27:53PM +0100, Uwe Kleine-K?nig wrote:
> Hello Russell,
> 
> On Mon, Feb 15, 2016 at 02:43:44PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Feb 15, 2016 at 01:11:49PM +0000, Robin Murphy wrote:
> > > FWIW the PL180 on my Juno still works fine with this patch picked on top of
> > > -rc3, so the issue would seem to be something else - From a quick comparison
> > > between the DTs I see a slight difference in compatible strings for the
> > > clocks, but the more likely-looking suspect is that the VExpress DT
> > > references some GPIOs where the Juno DT doesn't.
> > 
> > Maybe it would be a good idea that Uwe creates a patch which initially
> > warns when a DT platform device falls back to matching via the platform
> > strings?
> > 
> > It's likely that the "basic subsystem" platform drivers are silent when
> > they probe, so having notification of a fallback would at least put
> > something into the kernel log when that happens - and then later change
> > that to be a hard failure (as Uwe is trying to do with his patch.)
> > 
> > However, I have to bring up another point: is what Uwe is trying to do
> > actually the right thing?  The DT platform device code has the ability
> > to create standard platform devices from DT, with an of_node, but with
> > standard names, and platform data.  It's there for compatibility with
> > older systems, and is there to allow systems to be transitioned over.
> > 
> > This patch breaks all that: despite the DT code changing the platform
> > device bus_id from the address.nodename format to the standard format
> > (thus allowing unconverted platform drivers to match), this patch
> > means that because the platform device has a of_node attached, this
> > will now fail.
> > 
> > Therefore, I think Uwe's patch is just wrong - or, if it's something we
> > want, the auxdata table support code needs to _also_ be ripped out of
> > the drivers/of/platform.c code, but that then means anyone who wants to
> > go through the conversion has a big flag-day change to go through.
> 
> That's a valid concern I wasn't aware of when I created the patch.
> 
> So maybe just emitting a warning as you suggested is a good idea. And
> additionally only emit it when the driver is dt aware, too.
> 
> Greg, can you drop this patch, or do you need a proper changelog for a
> revert? On top of that I'd then create a new patch which is more
> conservative.

A hint as to what the git commit id was would be helpful, I can just
revert it based on that.

thanks,

greg k-h


From stefano.stabellini at eu.citrix.com  Mon Feb 15 08:51:08 2016
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 15 Feb 2016 16:51:08 +0000
Subject: [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
In-Reply-To: <1455278707-2008263-1-git-send-email-arnd@arndb.de>
References: <1455278707-2008263-1-git-send-email-arnd@arndb.de>
Message-ID: <alpine.DEB.2.02.1602151643150.27008@kaball.uk.xensource.com>

CC'ing a few others.

On Fri, 12 Feb 2016, Arnd Bergmann wrote:
> The Xen framebuffer driver selects the xen keyboard driver, so the latter
> will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
> is a loadable module, this configuration cannot work. On mainline kernels,
> the symbol will be enabled but not used, while in combination with
> a patch I have to detect such useless configurations, we get the
> expected link failure:
> 
> drivers/input/built-in.o: In function `xenkbd_remove':
> xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
> xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
> 
> This changes the dependencies of XEN_FBDEV_FRONTEND so it cannot be
> built-in if CONFIG_INPUT=m && CONFIG_INPUT_MISC=y, as that would result
> in the broken select.
> 
> As usual, we would be much better off without the 'select', but removing
> it now would likely break existing user configurations that depend on
> it, so this adds another hack on top to get it working.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
> ---
>  drivers/video/fbdev/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 8ea45a5cd806..fd3d6fd290a9 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2241,6 +2241,7 @@ config FB_VIRTUAL
>  config XEN_FBDEV_FRONTEND
>  	tristate "Xen virtual frame buffer support"
>  	depends on FB && XEN
> +	depends on INPUT || !INPUT_MISC
>  	select FB_SYS_FILLRECT
>  	select FB_SYS_COPYAREA
>  	select FB_SYS_IMAGEBLIT

This looks very hackish. Couldn't we just do the following?

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8ea45a5..3c15f6d 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2246,7 +2246,7 @@ config XEN_FBDEV_FRONTEND
 	select FB_SYS_IMAGEBLIT
 	select FB_SYS_FOPS
 	select FB_DEFERRED_IO
-	select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
+	select INPUT_XEN_KBDDEV_FRONTEND if (INPUT && INPUT_MISC)
 	select XEN_XENBUS_FRONTEND
 	default y
 	help


From u.kleine-koenig at pengutronix.de  Mon Feb 15 09:00:25 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Mon, 15 Feb 2016 18:00:25 +0100
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <56C1F19F.8090100@roeck-us.net>
References: <20160214165010.GA3189@roeck-us.net>
 <20160215105909.GH12289@pengutronix.de>
 <56C1F19F.8090100@roeck-us.net>
Message-ID: <20160215170025.GJ12289@pengutronix.de>

On Mon, Feb 15, 2016 at 07:41:19AM -0800, Guenter Roeck wrote:
> On 02/15/2016 02:59 AM, Uwe Kleine-K?nig wrote:
> >Hello Guenter,
> >
> >On Sun, Feb 14, 2016 at 08:50:10AM -0800, Guenter Roeck wrote:
> >>Uwe,
> >>
> >>Your patch 'driver-core: platform: probe of-devices only using list of
> >>compatibles' causes the following qemu tests to crash in -next.
> >>
> >>arm:vexpress-a9:vexpress_defconfig:vexpress-v2p-ca9
> >>arm:vexpress-a15:vexpress_defconfig:vexpress-v2p-ca15-tc1
> >>arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
> >>arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
> >>
> >>Crash log:
> >>
> >>VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6
> >>Please append a correct "root=" boot option; here are the available partitions:
> >>1f00          131072 mtdblock0  (driver?)
> >>1f01           32768 mtdblock1  (driver?)
> >>Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
> >
> >Can you provide a complete boot log? This might already reveal which
> >device is failing. It might not be the mmci device but something it
> >depends on (clock, bus parent, irq).
> >
> 
> Sure, something else may be failing, but why does reverting your patch
> fix the problem ?

Well, my patch made matching of platform devices to platform drivers
more strict. Your machine relies on the respective binding though. So of
course reverting my patch "repairs" your machine, but that doesn't
necessarily mean that my patch is wrong. Even though I'm convinced in
the meantime by Russell that there are false positives it doesn't
necessarily imply that your case is such a false positive, too.

One example of a combination of driver + device I intended to break with
my patch was drivers/mtd/nand/mxc_nand.c and devices that got bound to
that by name. The driver does:

	const struct of_device_id *of_id =
		of_match_device(mxcnd_dt_ids, host->dev);

and doesn't handle of_id being NULL after that. Some people argued (also
for other drivers in similar situations) that this cannot happen because
all compatibles had a non-NULL device_id. That is an error that is easy
to make and so the idea was to just not bind in such a case and safe the
user from the surprise.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From david.vrabel at citrix.com  Mon Feb 15 09:05:22 2016
From: david.vrabel at citrix.com (David Vrabel)
Date: Mon, 15 Feb 2016 17:05:22 +0000
Subject: [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
In-Reply-To: <alpine.DEB.2.02.1602151643150.27008@kaball.uk.xensource.com>
References: <1455278707-2008263-1-git-send-email-arnd@arndb.de>
 <alpine.DEB.2.02.1602151643150.27008@kaball.uk.xensource.com>
Message-ID: <56C20552.8030305@citrix.com>

On 15/02/16 16:51, Stefano Stabellini wrote:
> CC'ing a few others.
> 
> On Fri, 12 Feb 2016, Arnd Bergmann wrote:
>> The Xen framebuffer driver selects the xen keyboard driver, so the latter
>> will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
>> is a loadable module, this configuration cannot work. On mainline kernels,
>> the symbol will be enabled but not used, while in combination with
>> a patch I have to detect such useless configurations, we get the
>> expected link failure:
>>
>> drivers/input/built-in.o: In function `xenkbd_remove':
>> xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
>> xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
>>
>> This changes the dependencies of XEN_FBDEV_FRONTEND so it cannot be
>> built-in if CONFIG_INPUT=m && CONFIG_INPUT_MISC=y, as that would result
>> in the broken select.
>>
>> As usual, we would be much better off without the 'select', but removing
>> it now would likely break existing user configurations that depend on
>> it, so this adds another hack on top to get it working.

I would remove the select.

Existing configurations with both XEN_FBDEV_FRONTEND and
XEN_KBDDEV_FRONTEND will continue to work (since XEN_KBDEV_FRONTEND is
already enabled removing the select won't turn it off).

David

>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>> Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
>> ---
>>  drivers/video/fbdev/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>> index 8ea45a5cd806..fd3d6fd290a9 100644
>> --- a/drivers/video/fbdev/Kconfig
>> +++ b/drivers/video/fbdev/Kconfig
>> @@ -2241,6 +2241,7 @@ config FB_VIRTUAL
>>  config XEN_FBDEV_FRONTEND
>>  	tristate "Xen virtual frame buffer support"
>>  	depends on FB && XEN
>> +	depends on INPUT || !INPUT_MISC
>>  	select FB_SYS_FILLRECT
>>  	select FB_SYS_COPYAREA
>>  	select FB_SYS_IMAGEBLIT
> 
> This looks very hackish. Couldn't we just do the following?
> 
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 8ea45a5..3c15f6d 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2246,7 +2246,7 @@ config XEN_FBDEV_FRONTEND
>  	select FB_SYS_IMAGEBLIT
>  	select FB_SYS_FOPS
>  	select FB_DEFERRED_IO
> -	select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
> +	select INPUT_XEN_KBDDEV_FRONTEND if (INPUT && INPUT_MISC)
>  	select XEN_XENBUS_FRONTEND
>  	default y
>  	help
> 



From linux at roeck-us.net  Mon Feb 15 09:05:27 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 15 Feb 2016 09:05:27 -0800
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
Message-ID: <20160215170527.GA24453@roeck-us.net>

Rafael,

I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
timers with utilization update callbacks' with next-20160215. An example
crash log and bisect results are attached below.

Please let me know if there is anything I can do to help tracking down
the problem.

Thanks,
Guenter

---

Building arm:beagle:multi_v7_defconfig:omap3-beagle ... running ..... failed (crashed)
------------
qemu log:

(process:26225): GLib-WARNING **: /build/glib2.0-ajuDY6/glib2.0-2.46.1/./glib/gmem.c:482: custom memory allocation vtable not supported
SMC cmd 0x1 val 0x3
SMC cmd 0x3 val 0x2
SMC cmd 0x3 val 0x32
SMC cmd 0x2 val 0x8000000

U-Boot SPL 2011.12 (Mar 01 2012 - 19:25:06)
Texas Instruments Revision detection unimplemented
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.bin
reading u-boot.bin
SMC cmd 0x1 val 0x3
SMC cmd 0x3 val 0x2
SMC cmd 0x3 val 0x32
SMC cmd 0x2 val 0x8000000


U-Boot 2011.12 (Mar 01 2012 - 19:25:06)

OMAP35XX-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - bad CRC, using default environment

ERROR : Unsupport USB mode
Check that mini-B USB cable is attached to the device
In:    serial
Out:   serial
Err:   serial
Beagle Rev C4
No EEPROM on expansion board
Die ID #51454d5551454d555400000051454d55
Net:   No ethernet found.
checking for preEnv.txt
reading preEnv.txt

** Unable to read "preEnv.txt" from mmc 0:1 **
Hit any key to stop autoboot:  2  1  0 
The user button is currently NOT pressed.
SD/MMC found on device 0
reading uEnv.txt

** Unable to read "uEnv.txt" from mmc 0:1 **
reading boot.scr

393 bytes read
Loaded script from boot.scr
Running bootscript from mmc0 ...
## Executing script at 80200000
reading uImage

6804376 bytes read
reading devicetree.dtb

63421 bytes read
Booting from boot.scr
## Booting kernel from Legacy Image at 80000000 ...
   Image Name:   Linux-4.5.0-rc4-next-20160215
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    6804312 Bytes = 6.5 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 84000000
   Booting using the fdt blob at 0x84000000
   Loading Kernel Image ... OK
OK
   Using Device Tree in place at 84000000, end 840127bc

Starting kernel ...

omap2_inth_read: Bad register 0x000020
omap2_inth_write: protection mode enable attempt
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.5.0-rc4-next-20160215 (groeck at mars) (gcc version 4.7.2 (GCC) ) #1 SMP Mon Feb 15 00:51:07 PST 2016
[    0.000000] CPU: ARMv7 Processor [410fc083] revision 3 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine model: TI OMAP3 BeagleBoard
[    0.000000] cma: Reserved 64 MiB at 0x8b800000
[    0.000000] Memory policy: Data cache writeback
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] OMAP3430/3530 ES3.1 (iva sgx neon isp )
[    0.000000] PERCPU: Embedded 13 pages/cpu @cfb87000 s23296 r8192 d21760 u53248
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64512
[    0.000000] Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootwait earlyprintk fixrtc nocompcache vram=12M omapfb.mode=640x480MR-16 at 60 mpurate=auto doreboot
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 173888K/260096K available (9516K kernel code, 1115K rwdata, 4056K rodata, 2048K init, 341K bss, 20672K reserved, 65536K cma-reserved, 0K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff800000   ( 752 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0208000 - 0xc1041070   (14565 kB)
[    0.000000]       .init : 0xc1100000 - 0xc1300000   (2048 kB)
[    0.000000]       .data : 0xc1300000 - 0xc1416f40   (1116 kB)
[    0.000000]        .bss : 0xc1419000 - 0xc146e6e0   ( 342 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	Build-time adjustment of leaf fanout to 32.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=1.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=1
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts
[    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
[    0.000000] OMAP clockevent source: timer12 at 32768 Hz
[    0.000000] sched_clock: 32 bits at 200 Hz, resolution 5000000ns, wraps every 10737418237500000ns
[    0.000000] Console: colour dummy device 80x30
[    0.105000] Calibrating delay loop... 869.99 BogoMIPS (lpj=2174976)
[    0.105000] pid_max: default: 32768 minimum: 301
[    0.105000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.105000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.110000] CPU: Testing write buffer coherency: ok
[    0.115000] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.115000] Setting up static identity map for 0x80300000 - 0x80300098
[    0.130000] Brought up 1 CPUs
[    0.130000] SMP: Total of 1 processors activated (869.99 BogoMIPS).
[    0.130000] CPU: All CPU(s) started in SVC mode.
[    0.160000] devtmpfs: initialized
[    0.200000] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 2
[    0.210000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9556302231375000 ns
[    0.215000] pinctrl core: initialized pinctrl subsystem
[    0.225000] NET: Registered protocol family 16
[    0.235000] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.255000] omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp
[    0.255000] omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp
[    0.325000] omap_hdq1w_reset: hdq1w: softreset failed (waited 10000 usec)
[    0.340000] omap_hwmod: ssi: _wait_target_ready failed: -16
[    0.340000] omap_hwmod: ssi: cannot be enabled for reset (3)
[    0.340000] omap_hwmod: sham: _wait_target_ready failed: -16
[    0.340000] omap_hwmod: sham: cannot be enabled for reset (3)
[    0.345000] omap_hwmod: aes: _wait_target_ready failed: -16
[    0.345000] omap_hwmod: aes: cannot be enabled for reset (3)
[    0.450000] didn't get FRAMEDONE1/2/3 or TV interrupt
[    0.455000] cpuidle: using governor menu
[    0.455000] Reprogramming SDRC clock to 332000000 Hz
[    0.470000] omap_gpio 48310000.gpio: could not find pctldev for node /ocp/l4 at 48000000/scm at 2000/pinmux at a00/pinmux_gpio1_pins, deferring probe
[    0.470000] OMAP GPIO hardware version 2.5
[    0.480000] irq: no irq domain found for /ocp/l4 at 48000000/scm at 2000/pinmux at 30 !
[    0.495000] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
[    0.495000] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
[    0.505000] of_amba_device_create(): amba_device_add() failed (-19) for /etb at 540000000
[    0.505000] of_amba_device_create(): amba_device_add() failed (-19) for /etm at 54010000
[    0.505000] No ATAGs?
[    0.505000] hw-breakpoint: debug architecture 0x0 unsupported.
[    0.510000] omap4_sram_init:Unable to allocate sram needed to handle errata I688
[    0.510000] omap4_sram_init:Unable to get sram pool needed to handle errata I688
[    0.510000] OMAP DMA hardware revision 4.0
[    0.520000] Serial: AMBA PL011 UART driver
[    0.555000] omap-dma-engine 48056000.dma-controller: OMAP DMA engine driver
[    0.565000] vgaarb: loaded
[    0.570000] SCSI subsystem initialized
[    0.570000] usbcore: registered new interface driver usbfs
[    0.570000] usbcore: registered new interface driver hub
[    0.570000] usbcore: registered new device driver usb
[    0.575000] omap_i2c 48070000.i2c: bus 0 rev3.3 at 2600 kHz
[    0.580000] omap_i2c 48072000.i2c: bus 1 rev3.3 at 100 kHz
[    0.580000] omap_i2c 48060000.i2c: bus 2 rev3.3 at 100 kHz
[    0.580000] pps_core: LinuxPPS API ver. 1 registered
[    0.580000] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti at linux.it>
[    0.580000] PTP clock support registered
[    0.580000] EDAC MC: Ver: 3.0.0
[    0.610000] NET: Registered protocol family 2
[    0.615000] TCP established hash table entries: 2048 (order: 1, 8192 bytes)
[    0.615000] TCP bind hash table entries: 2048 (order: 2, 16384 bytes)
[    0.615000] TCP: Hash tables configured (established 2048 bind 2048)
[    0.615000] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    0.615000] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    0.615000] NET: Registered protocol family 1
[    0.620000] RPC: Registered named UNIX socket transport module.
[    0.620000] RPC: Registered udp transport module.
[    0.620000] RPC: Registered tcp transport module.
[    0.620000] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.625000] hw perfevents: enabled with armv7_cortex_a8 PMU driver, 1 counters available
[    0.630000] futex hash table entries: 256 (order: 2, 16384 bytes)
[    0.635000] workingset: timestamp_bits=28 max_order=16 bucket_order=0
[    0.650000] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.655000] NFS: Registering the id_resolver key type
[    0.655000] Key type id_resolver registered
[    0.655000] Key type id_legacy registered
[    0.655000] ntfs: driver 2.1.32 [Flags: R/O].
[    0.660000] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[    0.660000] io scheduler noop registered
[    0.660000] io scheduler deadline registered
[    0.660000] io scheduler cfq registered (default)
[    0.675000] pinctrl-single 48002030.pinmux: 284 pins at pa fa002030 size 568
[    0.675000] pinctrl-single 48002a00.pinmux: 46 pins at pa fa002a00 size 92
[    0.675000] pinctrl-single 480025d8.pinmux: 18 pins at pa fa0025d8 size 36
[    0.810000] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.815000] SuperH (H)SCI(F) driver initialized
[    0.815000] msm_serial: driver initialized
[    0.815000] omap_uart 4806a000.serial: no wakeirq for uart0
[    0.820000] 4806a000.serial: ttyO0 at MMIO 0x4806a000 (irq = 88, base_baud = 3000000) is a OMAP UART0
[    0.820000] omap_uart 4806c000.serial: no wakeirq for uart1
[    0.820000] 4806c000.serial: ttyO1 at MMIO 0x4806c000 (irq = 89, base_baud = 3000000) is a OMAP UART1
[    0.820000] 49020000.serial: ttyO2 at MMIO 0x49020000 (irq = 90, base_baud = 3000000) is a OMAP UART2
[    0.845000] console [ttyO2] enabled
[    0.845000] STMicroelectronics ASC driver initialized
[    0.850000] [drm] Initialized drm 1.1.0 20060810
[    0.885000] brd: module loaded
[    0.895000] loop: module loaded
[    0.905000] twl 0-0048: PIH (irq 23) chaining IRQs 307..315
[    0.905000] twl 0-0048: power (irq 312) chaining IRQs 315..322
[    0.960000] twl4030_gpio twl4030-gpio: gpio (irq 307) chaining IRQs 323..340
[    0.985000] libphy: Fixed MDIO Bus: probed
[    0.990000] CAN device driver interface
[    0.995000] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.3.0-k
[    0.995000] igb: Copyright (c) 2007-2014 Intel Corporation.
[    1.000000] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB Ethernet driver
[    1.000000] usbcore: registered new interface driver pegasus
[    1.000000] usbcore: registered new interface driver asix
[    1.000000] usbcore: registered new interface driver ax88179_178a
[    1.005000] usbcore: registered new interface driver cdc_ether
[    1.005000] usbcore: registered new interface driver smsc75xx
[    1.005000] usbcore: registered new interface driver smsc95xx
[    1.005000] usbcore: registered new interface driver net1080
[    1.005000] usbcore: registered new interface driver cdc_subset
[    1.005000] usbcore: registered new interface driver zaurus
[    1.005000] usbcore: registered new interface driver cdc_ncm
[    1.010000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.010000] ehci-pci: EHCI PCI platform driver
[    1.010000] ehci-platform: EHCI generic platform driver
[    1.010000] ehci-omap: OMAP-EHCI Host Controller driver
[    1.010000] ehci-omap 48064800.ehci: Can't get PHY device for port 1: -517
[    1.010000] ehci-orion: EHCI orion driver
[    1.010000] SPEAr-ehci: EHCI SPEAr driver
[    1.015000] ehci-st: EHCI STMicroelectronics driver
[    1.015000] ehci-exynos: EHCI EXYNOS driver
[    1.015000] ehci-atmel: EHCI Atmel driver
[    1.015000] tegra-ehci: Tegra EHCI driver
[    1.015000] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.015000] ohci-pci: OHCI PCI platform driver
[    1.015000] ohci-platform: OHCI generic platform driver
[    1.015000] ohci-omap3: OHCI OMAP3 driver
[    1.015000] ohci-omap3 48064400.ohci: OHCI Host Controller
[    1.015000] ohci-omap3 48064400.ohci: new USB bus registered, assigned bus number 1
[    1.020000] ohci-omap3 48064400.ohci: irq 92, io mem 0x48064400
[    1.080000] hub 1-0:1.0: USB hub found
[    1.080000] hub 1-0:1.0: 3 ports detected
[    1.085000] SPEAr-ohci: OHCI SPEAr driver
[    1.085000] ohci-st: OHCI STMicroelectronics driver
[    1.085000] ohci-atmel: OHCI Atmel driver
[    1.090000] usbcore: registered new interface driver usb-storage
[    1.095000] mousedev: PS/2 mouse device common for all mice
[    1.110000] twl_rtc 48070000.i2c:twl at 48:rtc: Power up reset detected.
[    1.115000] twl_rtc 48070000.i2c:twl at 48:rtc: Enabling TWL-RTC
[    1.120000] twl_rtc 48070000.i2c:twl at 48:rtc: rtc core: registered 48070000.i2c:twl at 48 as rtc0
[    1.120000] i2c /dev entries driver
[    1.160000] sdhci: Secure Digital Host Controller Interface driver
[    1.160000] sdhci: Copyright(c) Pierre Ossman
[    1.215000] Synopsys Designware Multimedia Card Interface Driver
[    1.225000] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.260000] mmc0: host does not support reading read-only switch, assuming write-enable
[    1.260000] mmc0: new SD card at address 4567
[    1.270000] ledtrig-cpu: registered to indicate activity on CPUs
[    1.275000] usbcore: registered new interface driver usbhid
[    1.275000] usbhid: USB HID core driver
[    1.295000] NET: Registered protocol family 10
[    1.305000] mmcblk0: mmc0:4567 QEMU! 256 MiB 
[    1.315000]  mmcblk0: p1 p2
[    1.320000] sit: IPv6 over IPv4 tunneling driver
[    1.320000] NET: Registered protocol family 17
[    1.325000] can: controller area network core (rev 20120528 abi 9)
[    1.325000] NET: Registered protocol family 29
[    1.325000] can: raw protocol (rev 20120528)
[    1.325000] can: broadcast manager protocol (rev 20120528 t)
[    1.325000] can: netlink gateway (rev 20130117) max_hops=1
[    1.325000] Key type dns_resolver registered
[    1.330000] omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu_iva
[    1.330000] omap2_set_init_voltage: unable to set vdd_mpu_iva
[    1.330000] omap2_set_init_voltage: unable to find boot up OPP for vdd_core
[    1.330000] omap2_set_init_voltage: unable to set vdd_core
[    1.340000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[    1.340000] pgd = c0204000
[    1.340000] [00000000] *pgd=00000000
[    1.340000] Internal error: Oops: 80000005 [#1] SMP ARM
[    1.340000] Modules linked in:
[    1.340000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4-next-20160215 #1
[    1.340000] Hardware name: Generic OMAP3-GP (Flattened Device Tree)
[    1.340000] task: cb060000 ti: cb05a000 task.ti: cb05a000
[    1.340000] PC is at 0x0
[    1.340000] LR is at arch_send_call_function_single_ipi+0x34/0x38
[    1.340000] pc : [<00000000>]    lr : [<c030de78>]    psr: 20000193
[    1.340000] sp : cb05b7c0  ip : 00000000  fp : cb05b83c
[    1.340000] r10: cfb8c0c0  r9 : 00000000  r8 : cb18a4c0
[    1.340000] r7 : 00000005  r6 : 00000005  r5 : cb5c0334  r4 : 00000000
[    1.340000] r3 : 00000000  r2 : c0c06a7c  r1 : 00000003  r0 : c0c06a7c
[    1.340000] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
[    1.340000] Control: 10c5387d  Table: 80204059  DAC: 00000051
[    1.340000] Process swapper/0 (pid: 1, stack limit = 0xcb05a220)
[    1.340000] Stack: (0xcb05b7c0 to 0xcb05c000)
[    1.340000] b7c0: 00000000 c03b3350 4fdec700 00000000 00000005 c0959a84 ffffffff 00000000
[    1.340000] b7e0: ffffffff cb18a4c0 cfb8c0c0 c03732d8 4c4b4000 cb18a4c0 cfb8c0c0 cfb8c0c0
[    1.340000] b800: 0e979000 cb18a4c0 cfb8c0c0 00000005 0e979000 c12130c0 00000000 cfb8c0c0
[    1.340000] b820: cb05b83c c0360d28 00000000 cb18a4c0 cfb8c0c0 60000193 cb05b84c c0360fc0
[    1.340000] b840: cb18a4c0 cb18a8b4 cb05b87c c0361b74 cfb8c100 00000141 cb05b934 cb1c1cc0
[    1.340000] b860: 00000002 00000000 00000000 00000048 c1416d0c cb0096c0 00000001 c0381de0
[    1.340000] b880: c1416080 cfb8c100 00000400 cb0096c0 cb009720 00000000 00000038 cb003000
[    1.340000] b8a0: 00000000 cb05b9c4 00000a28 c0381ea4 cb0096c0 cb0096d0 00000000 c0385150
[    1.340000] b8c0: c03850ac c1211518 00000000 c038168c 00000155 c0381788 c0932830 20000013
[    1.340000] b8e0: ffffffff cb05b924 00000000 c030bad4 00000001 00000009 00000002 fa070024
[    1.340000] b900: cb127c10 00009401 cb05b9b8 c1302100 00000000 00000000 cb05b9c4 00000a28
[    1.340000] b920: 00000000 cb05b940 00009601 c0932830 20000013 ffffffff 00000051 c093261c
[    1.340000] b940: 00000014 cb127c58 00000002 00000001 000f4240 cb127c10 1443fd00 00000001
[    1.340000] b960: c1302100 cb127c58 cb05b9b8 00000002 c145d438 ffff16ac 00000001 c0928358
[    1.340000] b980: cb127c74 cb127c58 00000002 cb05b9b8 cb05ba97 00000001 cb05ba97 00000001
[    1.340000] b9a0: 00000001 c0928538 00000000 cb518000 cb513740 c07726c4 0000004b cfb80001
[    1.340000] b9c0: cb513740 0001004b 017d0001 cb05ba97 00000000 c076dc30 00000001 00000000
[    1.340000] b9e0: 00000004 000000b9 000000ba cb518000 000000ba 000000b9 00000001 c076dd70
[    1.340000] ba00: 00000000 00000000 cfb8c100 cb518000 000000ba 00000001 00000001 cb05ba97
[    1.340000] ba20: 00000001 000000b9 00000000 c076dfcc c099a208 cb59d048 00000001 c1336dd0
[    1.340000] ba40: a0000113 00000000 00000001 cb05ba97 0000005e 00000004 00000001 00000000
[    1.340000] ba60: 00000000 000ee098 000ee098 c077fd34 0000000d c09e51f0 c09e51d0 cb51f400
[    1.340000] ba80: ffffffff 000ee098 000ee098 c068cb48 00000000 c09c157c cb019180 c067887c
[    1.340000] baa0: cb51f400 c067a700 000ee098 c09c160c cb015780 00000000 3b9aca00 cb5bdcc0
[    1.340000] bac0: cb51f400 00000000 00000000 00000000 000ee098 c067ab5c 000ee098 000ee098
[    1.340000] bae0: cb5bdcc0 000ee098 000ee098 000ee098 cfb87050 00000000 000ee098 c067c614
[    1.340000] bb00: cb5bdcc0 000ee098 000ee098 c0765ad4 1dcd6500 cb5bdc80 00000000 07735940
[    1.340000] bb20: cb5bdc80 cfb87050 cb5bdcc0 00000000 000ee098 c076660c 000ee098 cb5c11d0
[    1.340000] bb40: cb05bb90 00124f80 00124f80 00124f80 07735940 1dcd6500 ffffffff cb5c1100
[    1.340000] bb60: 00000000 00000000 c145dc8c cb5c0280 00000000 00000001 cb05bb90 c0958e78
[    1.340000] bb80: cb05bb8c c13cb404 00000000 00000000 00000010 0007a120 0001e848 00000021
[    1.340000] bba0: ffffffff ee222d90 00000000 00000000 00000000 00000010 cfb8b598 c13cb310
[    1.340000] bbc0: c1302578 c095ca58 c1302578 00000000 cb5c1100 00000000 000927c0 cb5bdfc0
[    1.340000] bbe0: c120e300 00000000 ee32cf60 00000000 c13cb310 cb5c1100 00000000 cb5c0304
[    1.340000] bc00: 00000010 c145dc8c c1302578 cb5c11b4 cb5c1108 c095cd04 c145dc8c 00000001
[    1.340000] bc20: cb5c1100 cb5c1100 00000000 c145dc8c c1302578 00000003 cb5c1100 00000000
[    1.340000] bc40: 00000010 c145dc8c c1302578 cb5c11b4 cb5c1108 c0959c5c cb5c1100 00000000
[    1.340000] bc60: 00000000 c095a2dc c0c0df58 00000001 0000ffff 00000001 00000000 00000000
[    1.340000] bc80: cb5bdc00 000927c0 0001e848 000493e0 0001e848 000927c0 0007a120 00000000
[    1.340000] bca0: 00000000 00000000 00000000 c13cb310 00000000 00000000 00000000 00000000
[    1.340000] bcc0: 00000000 00000000 ffffffe0 cb5c1160 cb5c1160 c095abf4 0001e848 000927c0
[    1.340000] bce0: cb5c0280 c13cb0a8 c13cb0a8 cb5bdf00 cb5c1184 cb5c1184 cb11e600 00000000
[    1.340000] bd00: c13cb128 cb5bf460 00000001 00000003 00000000 00000000 cb5c11ac cb5c11ac
[    1.340000] bd20: ffff0001 cb5c11b8 cb5c11b8 00000000 00000000 cb060000 00000000 00000000
[    1.340000] bd40: 00000000 cb5c11d8 cb5c11d8 00000000 cb5bdf80 cb5bdec0 cb5c1100 c095a5f0
[    1.340000] bd60: 00000000 cb11e600 00000000 c1212594 60000013 00000001 00000000 c13cb110
[    1.340000] bd80: c13acc68 c13cb0a8 c13cb440 c13cb440 00000000 00000000 00000000 c075674c
[    1.340000] bda0: c13cb440 cb00cc5c cb169db4 00000000 c1334248 c13cb488 c145dc8c c0959764
[    1.340000] bdc0: ffffffed cfb87050 cb5e2600 c095d670 ffffffed cb5e2610 fffffdfb c0758e48
[    1.340000] bde0: c0758df8 cb5e2610 c1459090 c1459098 00000000 c07577b0 00000000 00000000
[    1.340000] be00: cb05be30 c0757a68 00000001 c145906c 00000000 c0755d3c cb00cb70 cb5938b8
[    1.340000] be20: cb5e2610 cb5e2644 c13aca58 c0757534 cb5e2610 00000001 00000000 cb5e2610
[    1.340000] be40: cb5e2610 c13aca58 c13acaa8 c0756bc0 cb5e2610 00000000 cb5e2618 c07550c0
[    1.340000] be60: 00000000 c0587884 cb05beb8 cb5e2600 00000000 cb5e2600 cb5e2610 c1419000
[    1.340000] be80: c110362c c11a183c 00000000 c0758fdc 00000000 cb05beb8 cb5e2600 cb5bdb00
[    1.340000] bea0: c1419000 c07597a8 c0ead2ac c1306788 c1306788 c1112510 00000000 00000000
[    1.340000] bec0: c0ead2ac 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    1.340000] bee0: 00000000 00000000 00000000 c110f828 c110fabc c110fac4 c110fabc c1103648
[    1.340000] bf00: c1306788 c0301d28 0000006f cb05bf28 c035a8bc c035a8cc 60000013 ffffffff
[    1.340000] bf20: 00000051 c058b428 c0ff5b24 c0c1da88 0000011a c035ab48 c11a183c c0ea7034
[    1.340000] bf40: c0ff451c 00000000 00000007 00000007 c1335704 cfb96300 c120de7c 00000007
[    1.340000] bf60: c11a1834 c1419000 0000011a c11a183c c1100598 c1100dc4 00000007 00000007
[    1.340000] bf80: 00000000 c1100598 00000000 c0b0bcfc 00000000 00000000 00000000 00000000
[    1.340000] bfa0: 00000000 c0b0bd04 00000000 c0307e78 00000000 00000000 00000000 00000000
[    1.340000] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    1.340000] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[    1.340000] [<c030de78>] (arch_send_call_function_single_ipi) from [<c03b3350>] (irq_work_queue_on+0x90/0x100)
[    1.340000] [<c03b3350>] (irq_work_queue_on) from [<c0959a84>] (cpufreq_update_util+0x40/0x4c)
[    1.340000] [<c0959a84>] (cpufreq_update_util) from [<c03732d8>] (enqueue_task_rt+0x28/0x26c)
[    1.340000] [<c03732d8>] (enqueue_task_rt) from [<c0360d28>] (activate_task+0x60/0x64)
[    1.340000] [<c0360d28>] (activate_task) from [<c0360fc0>] (ttwu_do_activate.constprop.13+0x34/0x68)
[    1.340000] [<c0360fc0>] (ttwu_do_activate.constprop.13) from [<c0361b74>] (try_to_wake_up+0x1a0/0x318)
[    1.340000] [<c0361b74>] (try_to_wake_up) from [<c0381de0>] (handle_irq_event_percpu+0xdc/0x15c)
[    1.340000] [<c0381de0>] (handle_irq_event_percpu) from [<c0381ea4>] (handle_irq_event+0x44/0x68)
[    1.340000] [<c0381ea4>] (handle_irq_event) from [<c0385150>] (handle_level_irq+0xa4/0x13c)
[    1.340000] [<c0385150>] (handle_level_irq) from [<c038168c>] (generic_handle_irq+0x18/0x28)
[    1.340000] [<c038168c>] (generic_handle_irq) from [<c0381788>] (__handle_domain_irq+0x54/0xb0)
[    1.340000] [<c0381788>] (__handle_domain_irq) from [<c030bad4>] (__irq_svc+0x54/0x70)
[    1.340000] [<c030bad4>] (__irq_svc) from [<c0932830>] (omap_i2c_xfer+0x320/0x5a0)
[    1.340000] [<c0932830>] (omap_i2c_xfer) from [<c0928358>] (__i2c_transfer+0x140/0x29c)
[    1.340000] [<c0928358>] (__i2c_transfer) from [<c0928538>] (i2c_transfer+0x84/0xd4)
[    1.340000] [<c0928538>] (i2c_transfer) from [<c07726c4>] (regmap_i2c_read+0x48/0x64)
[    1.340000] [<c07726c4>] (regmap_i2c_read) from [<c076dc30>] (_regmap_raw_read+0xa4/0x110)
[    1.340000] [<c076dc30>] (_regmap_raw_read) from [<c076dd70>] (regmap_raw_read+0xd4/0x170)
[    1.340000] [<c076dd70>] (regmap_raw_read) from [<c076dfcc>] (regmap_bulk_read+0x1c0/0x2b0)
[    1.340000] [<c076dfcc>] (regmap_bulk_read) from [<c077fd34>] (twl_i2c_read+0x48/0x8c)
[    1.340000] [<c077fd34>] (twl_i2c_read) from [<c068cb48>] (twl4030smps_get_voltage+0x44/0x60)
[    1.340000] [<c068cb48>] (twl4030smps_get_voltage) from [<c067887c>] (_regulator_get_voltage+0x68/0xb8)
[    1.340000] [<c067887c>] (_regulator_get_voltage) from [<c067a700>] (_regulator_do_set_voltage+0x48/0x320)
[    1.340000] [<c067a700>] (_regulator_do_set_voltage) from [<c067ab5c>] (regulator_set_voltage_unlocked+0xcc/0x220)
[    1.340000] [<c067ab5c>] (regulator_set_voltage_unlocked) from [<c067c614>] (regulator_set_voltage+0x28/0x54)
[    1.340000] [<c067c614>] (regulator_set_voltage) from [<c0765ad4>] (_set_opp_voltage+0x34/0x90)
[    1.340000] [<c0765ad4>] (_set_opp_voltage) from [<c076660c>] (dev_pm_opp_set_rate+0x19c/0x288)
[    1.340000] [<c076660c>] (dev_pm_opp_set_rate) from [<c0958e78>] (__cpufreq_driver_target+0x180/0x2a0)
[    1.340000] [<c0958e78>] (__cpufreq_driver_target) from [<c095ca58>] (dbs_check_cpu+0x1ac/0x1e8)
[    1.340000] [<c095ca58>] (dbs_check_cpu) from [<c095cd04>] (cpufreq_governor_dbs+0x1fc/0x608)
[    1.340000] [<c095cd04>] (cpufreq_governor_dbs) from [<c0959c5c>] (__cpufreq_governor+0x1a8/0x204)
[    1.340000] [<c0959c5c>] (__cpufreq_governor) from [<c095a2dc>] (cpufreq_init_policy+0x60/0x8c)
[    1.340000] [<c095a2dc>] (cpufreq_init_policy) from [<c095a5f0>] (cpufreq_online+0x2e8/0x708)
[    1.340000] [<c095a5f0>] (cpufreq_online) from [<c075674c>] (subsys_interface_register+0x80/0xc4)
[    1.340000] [<c075674c>] (subsys_interface_register) from [<c0959764>] (cpufreq_register_driver+0x144/0x1a0)
[    1.340000] [<c0959764>] (cpufreq_register_driver) from [<c095d670>] (dt_cpufreq_probe+0x64/0xe8)
[    1.340000] [<c095d670>] (dt_cpufreq_probe) from [<c0758e48>] (platform_drv_probe+0x50/0xb0)
[    1.340000] [<c0758e48>] (platform_drv_probe) from [<c07577b0>] (driver_probe_device+0x1f4/0x2b0)
[    1.340000] [<c07577b0>] (driver_probe_device) from [<c0755d3c>] (bus_for_each_drv+0x44/0x8c)
[    1.340000] [<c0755d3c>] (bus_for_each_drv) from [<c0757534>] (__device_attach+0x9c/0x100)
[    1.340000] [<c0757534>] (__device_attach) from [<c0756bc0>] (bus_probe_device+0x84/0x8c)
[    1.340000] [<c0756bc0>] (bus_probe_device) from [<c07550c0>] (device_add+0x33c/0x528)
[    1.340000] [<c07550c0>] (device_add) from [<c0758fdc>] (platform_device_add+0xa8/0x20c)
[    1.340000] [<c0758fdc>] (platform_device_add) from [<c07597a8>] (platform_device_register_full+0xe0/0x108)
[    1.340000] [<c07597a8>] (platform_device_register_full) from [<c1112510>] (omap2_common_pm_late_init+0xc8/0x10c)
[    1.340000] [<c1112510>] (omap2_common_pm_late_init) from [<c110f828>] (omap_common_late_init+0xc/0x14)
[    1.340000] [<c110f828>] (omap_common_late_init) from [<c110fac4>] (omap3_init_late+0x8/0x14)
[    1.340000] [<c110fac4>] (omap3_init_late) from [<c1103648>] (init_machine_late+0x1c/0x90)
[    1.340000] [<c1103648>] (init_machine_late) from [<c0301d28>] (do_one_initcall+0x84/0x1d4)
[    1.340000] [<c0301d28>] (do_one_initcall) from [<c1100dc4>] (kernel_init_freeable+0x120/0x1ec)
[    1.340000] [<c1100dc4>] (kernel_init_freeable) from [<c0b0bd04>] (kernel_init+0x8/0xec)
[    1.340000] [<c0b0bd04>] (kernel_init) from [<c0307e78>] (ret_from_fork+0x14/0x3c)
[    1.340000] Code: bad PC value
[    1.340000] ---[ end trace 384223760a5ee799 ]---
[    1.340000] Kernel panic - not syncing: Fatal exception in interrupt
[    1.340000] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

---
bisect results:

# bad: [2625f908fc0cbd7e40483217772888529ecbdfd1] Add linux-next specific files for 20160215
# good: [18558cae0272f8fd9647e69d3fec1565a7949865] Linux 4.5-rc4
git bisect start 'HEAD' 'v4.5-rc4'
# bad: [1e384dbfcb9c2b5b3c12cf3d5acc35359014decb] Merge remote-tracking branch 'device-mapper/for-next'
git bisect bad 1e384dbfcb9c2b5b3c12cf3d5acc35359014decb
# good: [0e6f5b65ea4d3669333fd6bc8149563051128b77] Merge branch 'dmi/master'
git bisect good 0e6f5b65ea4d3669333fd6bc8149563051128b77
# bad: [1e07223f47ba25129fb76cabd65b7e0a96115fa4] Merge remote-tracking branch 'mtd/master'
git bisect bad 1e07223f47ba25129fb76cabd65b7e0a96115fa4
# good: [667f00630ebefc4d73aa105c6ab254e4aec867f8] Merge branch 'local-checksum-offload'
git bisect good 667f00630ebefc4d73aa105c6ab254e4aec867f8
# good: [13adf6dd7a6d92ddecae17435f9639b94221dbbb] Merge remote-tracking branch 'libata/for-next'
git bisect good 13adf6dd7a6d92ddecae17435f9639b94221dbbb
# good: [11e70824e75f2cfbad9ae066ca5b29e1c361f19e] mwifiex: firmware dump support for w8997 chipset
git bisect good 11e70824e75f2cfbad9ae066ca5b29e1c361f19e
# bad: [dbf2f2bc4eea54e5cd2b59b9785eca07903cad20] Merge remote-tracking branch 'pm/linux-next'
git bisect bad dbf2f2bc4eea54e5cd2b59b9785eca07903cad20
# good: [02063010fc4dbf3ce0c5e114ddb68386a5f2345d] Merge branch 'pm-sleep' into linux-next
git bisect good 02063010fc4dbf3ce0c5e114ddb68386a5f2345d
# bad: [bd3f1697ffaa48b124e7384a7a68923d8f9724d0] cpufreq: governor: Rename skip_work to work_count
git bisect bad bd3f1697ffaa48b124e7384a7a68923d8f9724d0
# bad: [d51563226a1dc641cfaf3bfeb330a00a37101bd0] cpufreq: governor: Rename some data types and variables
git bisect bad d51563226a1dc641cfaf3bfeb330a00a37101bd0
# bad: [302352f51398cfd732c99daa899e43100e0e0341] cpufreq: governor: Replace timers with utilization update callbacks
git bisect bad 302352f51398cfd732c99daa899e43100e0e0341
# good: [e3f08fbcc76864cebe04219c8b5a77acf5fa3fa8] cpufreq: intel_pstate: Replace timers with utilization update callbacks
git bisect good e3f08fbcc76864cebe04219c8b5a77acf5fa3fa8
# first bad commit: [302352f51398cfd732c99daa899e43100e0e0341] cpufreq: governor: Replace timers with utilization update callbacks


From stefano.stabellini at eu.citrix.com  Mon Feb 15 09:08:30 2016
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Mon, 15 Feb 2016 17:08:30 +0000
Subject: [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
In-Reply-To: <56C20552.8030305@citrix.com>
References: <1455278707-2008263-1-git-send-email-arnd@arndb.de>
 <alpine.DEB.2.02.1602151643150.27008@kaball.uk.xensource.com>
 <56C20552.8030305@citrix.com>
Message-ID: <alpine.DEB.2.02.1602151708110.27008@kaball.uk.xensource.com>

On Mon, 15 Feb 2016, David Vrabel wrote:
> On 15/02/16 16:51, Stefano Stabellini wrote:
> > CC'ing a few others.
> > 
> > On Fri, 12 Feb 2016, Arnd Bergmann wrote:
> >> The Xen framebuffer driver selects the xen keyboard driver, so the latter
> >> will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
> >> is a loadable module, this configuration cannot work. On mainline kernels,
> >> the symbol will be enabled but not used, while in combination with
> >> a patch I have to detect such useless configurations, we get the
> >> expected link failure:
> >>
> >> drivers/input/built-in.o: In function `xenkbd_remove':
> >> xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
> >> xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
> >>
> >> This changes the dependencies of XEN_FBDEV_FRONTEND so it cannot be
> >> built-in if CONFIG_INPUT=m && CONFIG_INPUT_MISC=y, as that would result
> >> in the broken select.
> >>
> >> As usual, we would be much better off without the 'select', but removing
> >> it now would likely break existing user configurations that depend on
> >> it, so this adds another hack on top to get it working.
> 
> I would remove the select.
> 
> Existing configurations with both XEN_FBDEV_FRONTEND and
> XEN_KBDDEV_FRONTEND will continue to work (since XEN_KBDEV_FRONTEND is
> already enabled removing the select won't turn it off).

I am happy with that too.

 
> >> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> >> Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
> >> ---
> >>  drivers/video/fbdev/Kconfig | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> >> index 8ea45a5cd806..fd3d6fd290a9 100644
> >> --- a/drivers/video/fbdev/Kconfig
> >> +++ b/drivers/video/fbdev/Kconfig
> >> @@ -2241,6 +2241,7 @@ config FB_VIRTUAL
> >>  config XEN_FBDEV_FRONTEND
> >>  	tristate "Xen virtual frame buffer support"
> >>  	depends on FB && XEN
> >> +	depends on INPUT || !INPUT_MISC
> >>  	select FB_SYS_FILLRECT
> >>  	select FB_SYS_COPYAREA
> >>  	select FB_SYS_IMAGEBLIT
> > 
> > This looks very hackish. Couldn't we just do the following?
> > 
> > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> > index 8ea45a5..3c15f6d 100644
> > --- a/drivers/video/fbdev/Kconfig
> > +++ b/drivers/video/fbdev/Kconfig
> > @@ -2246,7 +2246,7 @@ config XEN_FBDEV_FRONTEND
> >  	select FB_SYS_IMAGEBLIT
> >  	select FB_SYS_FOPS
> >  	select FB_DEFERRED_IO
> > -	select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
> > +	select INPUT_XEN_KBDDEV_FRONTEND if (INPUT && INPUT_MISC)
> >  	select XEN_XENBUS_FRONTEND
> >  	default y
> >  	help
> > 
> 


From u.kleine-koenig at pengutronix.de  Mon Feb 15 09:12:01 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Mon, 15 Feb 2016 18:12:01 +0100
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160215164937.GC25556@kroah.com>
References: <20160214165010.GA3189@roeck-us.net>
 <20160215105909.GH12289@pengutronix.de> <56C1CE95.6020206@arm.com>
 <20160215144344.GF10826@n2100.arm.linux.org.uk>
 <20160215162753.GI12289@pengutronix.de>
 <20160215164937.GC25556@kroah.com>
Message-ID: <20160215171201.GK12289@pengutronix.de>

Hello Greg,

On Mon, Feb 15, 2016 at 08:49:37AM -0800, Greg Kroah-Hartman wrote:
> On Mon, Feb 15, 2016 at 05:27:53PM +0100, Uwe Kleine-K?nig wrote:
> > Greg, can you drop this patch, or do you need a proper changelog for a
> > revert? On top of that I'd then create a new patch which is more
> > conservative.
> 
> A hint as to what the git commit id was would be helpful, I can just
> revert it based on that.

This is 67d02a1bbb33 ("driver-core: platform: probe of-devices only
using list of compatibles")

If you need a log, something like:

	Reallow binding of of-devices by name

	It turned out that there are valid reasons (e.g. step by step
	conversion to device tree probing using auxdata) to bind
	of-instantiated devices to drivers by name. So revert to the
	original logic.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From rmk+kernel at arm.linux.org.uk  Mon Feb 15 09:12:06 2016
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Mon, 15 Feb 2016 17:12:06 +0000
Subject: [PATCH] ARM: dts: imx6qdl-microsom.dtsi: avoid boot-time UHS warning
Message-ID: <E1aVMgw-0001wE-5w@rmk-PC.arm.linux.org.uk>

Avoid the following warning:

sdhci-esdhc-imx 2190000.usdhc: could not get ultra high speed state, work on normal mode

which occurs at boot each time the SDHCI interface for the Broadcom
WiFi is probed.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/boot/dts/imx6qdl-microsom.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/imx6qdl-microsom.dtsi b/arch/arm/boot/dts/imx6qdl-microsom.dtsi
index 6d4069cc9419..86460e46d055 100644
--- a/arch/arm/boot/dts/imx6qdl-microsom.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-microsom.dtsi
@@ -154,6 +154,7 @@
 	bus-width = <4>;
 	mmc-pwrseq = <&usdhc1_pwrseq>;
 	keep-power-in-suspend;
+	no-1-8-v;
 	non-removable;
 	vmmc-supply = <&reg_brcm>;
 	status = "okay";
-- 
2.1.0



From rmk+kernel at arm.linux.org.uk  Mon Feb 15 09:13:02 2016
From: rmk+kernel at arm.linux.org.uk (Russell King)
Date: Mon, 15 Feb 2016 17:13:02 +0000
Subject: [PATCH] ARM: dts: imx6*-hummingboard: use proper gpio flags
 definitions
Message-ID: <E1aVMhq-0001x5-ST@rmk-PC.arm.linux.org.uk>

Use proper gpio flag definitions for GPIOs rather than using opaque
uninformative numbers.

Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 arch/arm/boot/dts/imx6qdl-hummingboard.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
index 81be050c8d3c..3a06516fe7a9 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
@@ -48,7 +48,7 @@
 
 	ir_recv: ir-receiver {
 		compatible = "gpio-ir-receiver";
-		gpios = <&gpio3 5 1>;
+		gpios = <&gpio3 5 GPIO_ACTIVE_LOW>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_hummingboard_gpio3_5>;
 	};
@@ -67,7 +67,7 @@
 		reg_usbh1_vbus: usb-h1-vbus {
 			compatible = "regulator-fixed";
 			enable-active-high;
-			gpio = <&gpio1 0 0>;
+			gpio = <&gpio1 0 GPIO_ACTIVE_HIGH>;
 			pinctrl-names = "default";
 			pinctrl-0 = <&pinctrl_hummingboard_usbh1_vbus>;
 			regulator-name = "usb_h1_vbus";
@@ -78,7 +78,7 @@
 		reg_usbotg_vbus: usb-otg-vbus {
 			compatible = "regulator-fixed";
 			enable-active-high;
-			gpio = <&gpio3 22 0>;
+			gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
 			pinctrl-names = "default";
 			pinctrl-0 = <&pinctrl_hummingboard_usbotg_vbus>;
 			regulator-name = "usb_otg_vbus";
-- 
2.1.0



From ard.biesheuvel at linaro.org  Mon Feb 15 09:17:46 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 15 Feb 2016 18:17:46 +0100
Subject: [PATCH] arm64: mark kernel text segment as MEMBLOCK_NOMAP
In-Reply-To: <20160215120809.GF13683@e104818-lin.cambridge.arm.com>
References: <1455528512-32491-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160215114505.GE13683@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-Y-k_LAbFZJjiPuHq6ssaFCb3WMG_fVGx3ODrvb+hEUQ@mail.gmail.com>
 <20160215120809.GF13683@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu8XJ4br8U0x2=AzzDUxo3he2gK6MtBkMKEsZ=Juds3_=A@mail.gmail.com>

On 15 February 2016 at 13:08, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 15, 2016 at 12:53:59PM +0100, Ard Biesheuvel wrote:
>> On 15 February 2016 at 12:45, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > Ard, I'm about to drop the kernel memory map patches from -next. There
>> > are several issues like KASAN (which may as well be a KASAN bug but I
>> > haven't got to the bottom of it yet), initrd (you have patches but
>> > require additional acks).
>> >
>> > I'll keep your stuff on the for-next/kernmap branch and do further
>> > debugging. If it stabilises in the next 1-2 weeks, I'll merge it into
>> > for-next/core for 4.6, otherwise, it will have to wait. I would really
>> > like these patches merged but it looks like they need wider testing.
> [...]
>> If you are going to drop it for now anyway, I can do a v6sub1 with
>> this issue and the initrd issue addressed, but also an issue with the
>> KVM ksym ref patch with GCC 4.8. Since these issues affect
>> bisectability, I'd prefer to rebase entirely, and fold all the fixes
>> rather than apply them on top.
>
> That's fine. I'll push one more patch to the for-next/pgtable branch,
> converting __set_fixmap_offset() back to a macro as it broke other
> architectures. Otherwise it is not rebased and I'll merge it into
> for-next core.
>

I have identified (and fixed) a Kasan issue in my patches: instead of
leaving a hole for the 64 MB module window in the Kasan shadow region,
I populated it with zero mappings, which caused many strange errors,
and since the vmap() routines don't expect block mappings (which are
created for the kernel image shadow by vmemmap_populate()), I guess
false positive kasan warnings (like the ones you were seeing) are also
a possible symptom of this issue.

-- 
Ard.


From will.deacon at arm.com  Mon Feb 15 09:22:47 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Feb 2016 17:22:47 +0000
Subject: [PATCH v4 20/23] arm64: perf: Count EL2 events if the kernel is
 running in HYP
In-Reply-To: <1455216004-19499-21-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
 <1455216004-19499-21-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160215172247.GL6298@arm.com>

On Thu, Feb 11, 2016 at 06:40:01PM +0000, Marc Zyngier wrote:
> When the kernel is running in HYP (with VHE), it is necessary to
> include EL2 events if the user requests counting kernel or
> hypervisor events.
> 
> Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
> Acked-by: Catalin Marinas <catalin.marinas at arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kernel/perf_event.c | 14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index f7ab14c..6013a38 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -20,6 +20,7 @@
>   */
>  
>  #include <asm/irq_regs.h>
> +#include <asm/virt.h>
>  
>  #include <linux/of.h>
>  #include <linux/perf/arm_pmu.h>
> @@ -693,10 +694,15 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
>  		return -EPERM;
>  	if (attr->exclude_user)
>  		config_base |= ARMV8_EXCLUDE_EL0;
> -	if (attr->exclude_kernel)
> -		config_base |= ARMV8_EXCLUDE_EL1;
> -	if (!attr->exclude_hv)
> -		config_base |= ARMV8_INCLUDE_EL2;
> +	if (is_kernel_in_hyp_mode()) {
> +		if (!attr->exclude_kernel || !attr->exclude_hv)
> +			config_base |= ARMV8_INCLUDE_EL2;

Hmm, so if userspace sets exclude_kernel but not exclude_user and
exclude_hv, what should we do? I'm slightly tempted to reject the
filter with -EINVAL...

Will


From robert.jarzmik at free.fr  Mon Feb 15 09:24:57 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Mon, 15 Feb 2016 18:24:57 +0100
Subject: [PATCH 4/4] dmaengine: pxa_dma: fix the maximum requestor line
In-Reply-To: <20160215163524.GI19598@localhost> (Vinod Koul's message of "Mon, 
 15 Feb 2016 22:05:24 +0530")
References: <1455225798-9510-1-git-send-email-robert.jarzmik@free.fr>
 <1455225798-9510-5-git-send-email-robert.jarzmik@free.fr>
 <20160215163524.GI19598@localhost>
Message-ID: <87fuwt28eu.fsf@belgarion.home>

Vinod Koul <vinod.koul at intel.com> writes:

> On Thu, Feb 11, 2016 at 10:23:18PM +0100, Robert Jarzmik wrote:
>> @@ -1399,13 +1405,17 @@ static int pxad_probe(struct platform_device *op)
>>  		return PTR_ERR(pdev->base);
>>  
>>  	of_id = of_match_device(pxad_dt_ids, &op->dev);
>> -	if (of_id)
>> +	if (of_id) {
>>  		of_property_read_u32(op->dev.of_node, "#dma-channels",
>>  				     &dma_channels);
>> -	else if (pdata && pdata->dma_channels)
>> +		of_property_read_u32(op->dev.of_node, "#requestors",
>> +				     &nb_requestors);
>
> I think we should check the return value here. This might be err in case
> when we have older DT on platform, but still should work with default in
> that case

Okay, but how should the code react to the err case, more specifically to
-EINVAL or -ENODATA ? As this property is optional as per the device-tree
description, the current code leaves nb_requestors = 0, as is specified in the
description, and fits the mmp_pdma case.

What do you think should be done ? A warning message ? Something else ?

Cheers.

--
Robert


From will.deacon at arm.com  Mon Feb 15 09:26:53 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Feb 2016 17:26:53 +0000
Subject: [PATCH v4 23/23] arm64: Panic when VHE and non VHE CPUs coexist
In-Reply-To: <1455216004-19499-24-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
 <1455216004-19499-24-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160215172653.GM6298@arm.com>

On Thu, Feb 11, 2016 at 06:40:04PM +0000, Marc Zyngier wrote:
> Having both VHE and non-VHE capable CPUs in the same system
> is likely to be a recipe for disaster.
> 
> If the boot CPU has VHE, but a secondary is not, we won't be
> able to downgrade and run the kernel at EL1. Add CPU hotplug
> to the mix, and this produces a terrifying mess.
> 
> Let's solve the problem once and for all. If you mix VHE and
> non-VHE CPUs in the same system, you deserve to loose, and this
> patch makes sure you don't get a chance.
> 
> This is implemented by storing the kernel execution level in
> a global variable. Secondaries will park themselves in a
> WFI loop if they observe a mismatch. Also, the primary CPU
> will detect that the secondary CPU has died on a mismatched
> execution level. Panic will follow.

This should really be based on Suzuki's series for handling generic
mismatches:

http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401727.html

To avoid growing a dependency on something that's unlikely to make it
for 4.6, I'd be inclined to drop your homegrown checks altogether amd
help Suzuki with his series as a separate activity (i.e. it needn't be
a blocker imo).

Will


From nm at ti.com  Mon Feb 15 09:25:38 2016
From: nm at ti.com (Nishanth Menon)
Date: Mon, 15 Feb 2016 11:25:38 -0600
Subject: [PATCH] arm: dts: AM57XX: Correct the thermal thresholds
In-Reply-To: <56C1F92A.1020803@ti.com>
References: <1454924705-8382-1-git-send-email-j-keerthy@ti.com>
 <20160209220901.GC28102@localhost.localdomain> <56BA6530.4030102@ti.com>
 <20160212222347.GO19432@atomide.com>
 <CAGo_u6r8-LJBWWrew0fV50Q+JnCxDj9PD57+9NoDm5TqCWL=jw@mail.gmail.com>
 <20160212224129.GP19432@atomide.com> <56C153A3.3030508@ti.com>
 <56C1F3A1.4080709@ti.com> <56C1F92A.1020803@ti.com>
Message-ID: <56C20A12.8080305@ti.com>

On 02/15/2016 10:13 AM, Keerthy wrote:
[...]
>>
>> This data is in the AM572x datasheet:
>> http://www.ti.com/lit/ds/symlink/am5728.pdf
>>
>> Table 5-3 in the current version contains the maximum junction
>> temperatures.
>>
>> this indicates that there are "Commercial" and "extended" -> we may
>> need to introduce just 2 dtsis -> am57xx-commercial and
>> am57xx-extended and reuse those based on the part on the board. just a
>> suggestion..
> 
> Or use the minimum of the 2 to be on the safer side if we have to deal 
> with one dtsi?

Why would we want to throttle earlier on customer platforms or other
boards using extended? at the very least -> if all upstream boards
have only commercial grade, then just introduce
am57xx-commercial-thermal.dtsi ..


-- 
Regards,
Nishanth Menon


From vinod.koul at intel.com  Mon Feb 15 09:30:53 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 15 Feb 2016 23:00:53 +0530
Subject: [PATCH] dmaengine: use phys_addr_t for slave configuration
In-Reply-To: <20160209225724.GA1522@katana>
References: <1366967214-20776-1-git-send-email-linus.walleij@linaro.org>
 <CAMuHMdUTzTBT8DyRb5WN048U5DbVsFnhJB0c5tjHBnA4rfetJg@mail.gmail.com>
 <20150710081411.GF836@localhost>
 <CAMuHMdV8a1W1MyJPanUNBzaiNsL96JYzetBVSiZoC3=eKXzo1Q@mail.gmail.com>
 <20151215172649.GK1854@localhost>
 <CAMuHMdXe8i2JbhOP2sWkVkqHEeBnW4AfVBbRaoZW=Kg0s_9m3g@mail.gmail.com>
 <20160209225724.GA1522@katana>
Message-ID: <20160215173053.GM19598@localhost>

On Tue, Feb 09, 2016 at 11:57:24PM +0100, Wolfram Sang wrote:
> 
> > This is a dependency for adding iommu support to the rcar-dmac driver, cfr.
> > "[PATCH v2 0/5] dmaengine: rcar-dmac: add iommu support for slave transfers".
> > http://www.spinics.net/lists/linux-renesas-soc/msg00066.html
> > https://www.mail-archive.com/linux-renesas-soc at vger.kernel.org/msg00108.html
> > 
> > Thank you for applying!
> 
> Yup, we really need it. Anything we can do to help?

I have done this change and discussing wider changes
I will send CFT hopefully before EOW, pls test :)

-- 
~Vinod
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160215/f4513e05/attachment.sig>

From vinod.koul at intel.com  Mon Feb 15 09:33:00 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 15 Feb 2016 23:03:00 +0530
Subject: [PATCH 4/4] dmaengine: pxa_dma: fix the maximum requestor line
In-Reply-To: <87fuwt28eu.fsf@belgarion.home>
References: <1455225798-9510-1-git-send-email-robert.jarzmik@free.fr>
 <1455225798-9510-5-git-send-email-robert.jarzmik@free.fr>
 <20160215163524.GI19598@localhost> <87fuwt28eu.fsf@belgarion.home>
Message-ID: <20160215173300.GN19598@localhost>

On Mon, Feb 15, 2016 at 06:24:57PM +0100, Robert Jarzmik wrote:
> Vinod Koul <vinod.koul at intel.com> writes:
> 
> > On Thu, Feb 11, 2016 at 10:23:18PM +0100, Robert Jarzmik wrote:
> >> @@ -1399,13 +1405,17 @@ static int pxad_probe(struct platform_device *op)
> >>  		return PTR_ERR(pdev->base);
> >>  
> >>  	of_id = of_match_device(pxad_dt_ids, &op->dev);
> >> -	if (of_id)
> >> +	if (of_id) {
> >>  		of_property_read_u32(op->dev.of_node, "#dma-channels",
> >>  				     &dma_channels);
> >> -	else if (pdata && pdata->dma_channels)
> >> +		of_property_read_u32(op->dev.of_node, "#requestors",
> >> +				     &nb_requestors);
> >
> > I think we should check the return value here. This might be err in case
> > when we have older DT on platform, but still should work with default in
> > that case
> 
> Okay, but how should the code react to the err case, more specifically to
> -EINVAL or -ENODATA ? As this property is optional as per the device-tree
> description, the current code leaves nb_requestors = 0, as is specified in the
> description, and fits the mmp_pdma case.
> 
> What do you think should be done ? A warning message ? Something else ?

Message is fine, but in order for not to regress we should set this to 32
(IIRC default before this, right) and not zero.

-- 
~Vinod


From catalin.marinas at arm.com  Mon Feb 15 09:35:35 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 15 Feb 2016 17:35:35 +0000
Subject: [PATCH] arm64: mark kernel text segment as MEMBLOCK_NOMAP
In-Reply-To: <CAKv+Gu8XJ4br8U0x2=AzzDUxo3he2gK6MtBkMKEsZ=Juds3_=A@mail.gmail.com>
References: <1455528512-32491-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160215114505.GE13683@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-Y-k_LAbFZJjiPuHq6ssaFCb3WMG_fVGx3ODrvb+hEUQ@mail.gmail.com>
 <20160215120809.GF13683@e104818-lin.cambridge.arm.com>
 <CAKv+Gu8XJ4br8U0x2=AzzDUxo3he2gK6MtBkMKEsZ=Juds3_=A@mail.gmail.com>
Message-ID: <20160215173534.GA19413@e104818-lin.cambridge.arm.com>

On Mon, Feb 15, 2016 at 06:17:46PM +0100, Ard Biesheuvel wrote:
> On 15 February 2016 at 13:08, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Mon, Feb 15, 2016 at 12:53:59PM +0100, Ard Biesheuvel wrote:
> >> On 15 February 2016 at 12:45, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> > Ard, I'm about to drop the kernel memory map patches from -next. There
> >> > are several issues like KASAN (which may as well be a KASAN bug but I
> >> > haven't got to the bottom of it yet), initrd (you have patches but
> >> > require additional acks).
> >> >
> >> > I'll keep your stuff on the for-next/kernmap branch and do further
> >> > debugging. If it stabilises in the next 1-2 weeks, I'll merge it into
> >> > for-next/core for 4.6, otherwise, it will have to wait. I would really
> >> > like these patches merged but it looks like they need wider testing.
> > [...]
> >> If you are going to drop it for now anyway, I can do a v6sub1 with
> >> this issue and the initrd issue addressed, but also an issue with the
> >> KVM ksym ref patch with GCC 4.8. Since these issues affect
> >> bisectability, I'd prefer to rebase entirely, and fold all the fixes
> >> rather than apply them on top.
> >
> > That's fine. I'll push one more patch to the for-next/pgtable branch,
> > converting __set_fixmap_offset() back to a macro as it broke other
> > architectures. Otherwise it is not rebased and I'll merge it into
> > for-next core.
> 
> I have identified (and fixed) a Kasan issue in my patches: instead of
> leaving a hole for the 64 MB module window in the Kasan shadow region,
> I populated it with zero mappings, which caused many strange errors,
> and since the vmap() routines don't expect block mappings (which are
> created for the kernel image shadow by vmemmap_populate()),

This would probably fix the vmalloc warning caused from kasan when
loading modules.

> I guess false positive kasan warnings (like the ones you were seeing)
> are also a possible symptom of this issue.

I now get kasan warnings even on vanilla 4.5-rc1 (though not on 4.4).
I'm trying to figure out whether they are genuine or just false
positives:

BUG: KASAN: stack-out-of-bounds in clockevents_program_event+0x2c8/0x310 at addr ffffffc0016ffc08
Read of size 8 by task swapper/0/0
page:ffffffbdc205bfc0 count:1 mapcount:0 mapping:          (null) index:0x0
flags: 0x400(reserved)
page dumped because: kasan: bad access detected
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G    B           4.5.0-rc1+ #158
Hardware name: Juno (DT)
Call trace:
[<ffffffc00008f130>] dump_backtrace+0x0/0x358
[<ffffffc00008f49c>] show_stack+0x14/0x20
[<ffffffc000785d40>] dump_stack+0xf8/0x188
[<ffffffc000343bb4>] kasan_report_error+0x524/0x550
[<ffffffc000343cf8>] __asan_report_load8_noabort+0x40/0x48
[<ffffffc0001f2b38>] clockevents_program_event+0x2c8/0x310
[<ffffffc0001f737c>] tick_program_event+0xac/0x108
[<ffffffc0001d85c8>] hrtimer_start_range_ns+0x8a0/0xb20
[<ffffffc0001f8b50>] __tick_nohz_idle_enter+0x970/0xca8
[<ffffffc0001f9310>] tick_nohz_idle_enter+0x60/0x98
[<ffffffc0001933ec>] cpu_startup_entry+0x14c/0x448
[<ffffffc00119104c>] rest_init+0xc4/0xd0
[<ffffffc00161beec>] start_kernel+0x54c/0x578
[<ffffffc0000811e0>] 0xffffffc0000811e0
Memory state around the buggy address:
 ffffffc0016ffb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffffc0016ffb80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
>ffffffc0016ffc00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
                      ^
 ffffffc0016ffc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffffc0016ffd00: 00 00 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4 f3 f3

-- 
Catalin


From wsa at the-dreams.de  Mon Feb 15 09:34:58 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Mon, 15 Feb 2016 18:34:58 +0100
Subject: [PATCH] dmaengine: use phys_addr_t for slave configuration
In-Reply-To: <20160215173053.GM19598@localhost>
References: <1366967214-20776-1-git-send-email-linus.walleij@linaro.org>
 <CAMuHMdUTzTBT8DyRb5WN048U5DbVsFnhJB0c5tjHBnA4rfetJg@mail.gmail.com>
 <20150710081411.GF836@localhost>
 <CAMuHMdV8a1W1MyJPanUNBzaiNsL96JYzetBVSiZoC3=eKXzo1Q@mail.gmail.com>
 <20151215172649.GK1854@localhost>
 <CAMuHMdXe8i2JbhOP2sWkVkqHEeBnW4AfVBbRaoZW=Kg0s_9m3g@mail.gmail.com>
 <20160209225724.GA1522@katana> <20160215173053.GM19598@localhost>
Message-ID: <20160215173458.GC1515@katana>


> > > This is a dependency for adding iommu support to the rcar-dmac driver, cfr.
> > > "[PATCH v2 0/5] dmaengine: rcar-dmac: add iommu support for slave transfers".
> > > http://www.spinics.net/lists/linux-renesas-soc/msg00066.html
> > > https://www.mail-archive.com/linux-renesas-soc at vger.kernel.org/msg00108.html
> > > 
> > > Thank you for applying!
> > 
> > Yup, we really need it. Anything we can do to help?
> 
> I have done this change and discussing wider changes
> I will send CFT hopefully before EOW, pls test :)

\o/ Thank you, Vinod!

If you cc linux-renesas-soc at vger.kernel.org, you'll surely have some
testers :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160215/8db026bf/attachment.sig>

From qnguyen at apm.com  Mon Feb 15 09:38:08 2016
From: qnguyen at apm.com (Quan Nguyen)
Date: Tue, 16 Feb 2016 00:38:08 +0700
Subject: [PATCH v6 2/3] Documentation: gpio: Update description for X-Gene
 standby GPIO controller DTS binding
In-Reply-To: <56C1F7EC.3020701@arm.com>
References: <1455512263-18183-1-git-send-email-qnguyen@apm.com>
 <1455512263-18183-3-git-send-email-qnguyen@apm.com>
 <56C1CA6E.1060606@arm.com>
 <CAFopSPRwd8cHnH8efegYVv52hPVTyk=VW9OrZZtSCj6Szj-K4Q@mail.gmail.com>
 <56C1F7EC.3020701@arm.com>
Message-ID: <CAFopSPSh6AApYgZ7vmQgGYWekpAB8ktywC9T4xdfCiJbbSCQ8Q@mail.gmail.com>

On Mon, Feb 15, 2016 at 11:08 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 15/02/16 15:31, Quan Nguyen wrote:
>> On Mon, Feb 15, 2016 at 7:54 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>> On 15/02/16 04:57, Quan Nguyen wrote:
>>>> Update description for X-Gene standby GPIO controller DTS binding to
>>>> support GPIO line configuration as input, output or external IRQ pin.
>>>>
>>>> Signed-off-by: Y Vo <yvo at apm.com>
>>>> Signed-off-by: Quan Nguyen <qnguyen at apm.com>
>>>> ---
>>>>  .../devicetree/bindings/gpio/gpio-xgene-sb.txt     | 47 ++++++++++++++++++----
>>>>  1 file changed, 40 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
>>>> index dae1300..7b8b4cb 100644
>>>> --- a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
>>>> +++ b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
>>>> @@ -1,10 +1,20 @@
>>>>  APM X-Gene Standby GPIO controller bindings
>>>>
>>>> -This is a gpio controller in the standby domain.
>>>> -
>>>> -There are 20 GPIO pins from 0..21. There is no GPIO_DS14 or GPIO_DS15,
>>>> -only GPIO_DS8..GPIO_DS13 support interrupts. The IRQ mapping
>>>> -is currently 1-to-1 on interrupts 0x28 thru 0x2d.
>>>> +This is a gpio controller in the standby domain. It also supports interrupt in
>>>> +some particular pins which are sourced to its parent interrupt controller
>>>> +as diagram below:
>>>> +                           +-----------------+
>>>> +                           | X-Gene standby  |
>>>> +                           | GPIO controller +--------- GPIO_0
>>>> ++------------+             |                 | ...
>>>> +| Parent IRQ |             |                 +--------- GPIO_8/EXT_INT_0
>>>> +| controller |  EXT_INT_0  |                 | ...
>>>> +| (GICv2)    +-------------+                 +--------- GPIO_[N+8]/EXT_INT_N
>>>> +|            |  ...        |                 |
>>>> +|            |  EXT_INT_N  |                 +--------- GPIO_[N+9]
>>>> +|            +-------------+                 | ...
>>>> +|            |             |                 +--------- GPIO_MAX
>>>> ++------------+             +-----------------+
>>>>
>>>>  Required properties:
>>>>  - compatible: "apm,xgene-gpio-sb" for the X-Gene Standby GPIO controller
>>>> @@ -15,10 +25,18 @@ Required properties:
>>>>               0 = active high
>>>>               1 = active low
>>>>  - gpio-controller: Marks the device node as a GPIO controller.
>>>> -- interrupts: Shall contain exactly 6 interrupts.
>>>> +- interrupts: The EXT_INT_0 parent interrupt resource must be listed first.
>>>> +- interrupt-parent: Phandle of the parent interrupt controller.
>>>> +- interrupt-cells: Should be two.
>>>> +       - first cell is 0-N coresponding for EXT_INT_0 to EXT_INT_N.
>>>> +       - second cell is used to specify flags.
>>>> +- interrupt-controller: Marks the device node as an interrupt controller.
>>>> +- apm,nr-gpios: Optional, specify number of gpios pin.
>>>> +- apm,nr-irqs: Optional, specify number of interrupt pins.
>>>> +- apm,irq-start: Optional, specify lowest gpio pin support interrupt.
>>>
>>> This is quite ambiguous. Is that relative to the GIC? Assuming this is
>>> the case, you should then document it, specify the type of interrupt
>>> (SPI?), and whether this is 0- or 32-based (the code seems to indicate
>>> that is is 0-based).
>>>
>>
>> Hi Marc, Let me explain by diagram below.
>> As you can also see in diagram above, the lowest gpio pin that
>> supports interrupt is GPIO_8 (EXT_INT_0),
>> and hence, apm,irq-start=<8> as default.
>>
>>                                            +-----------------+
>>                                            | X-Gene standby  |
>>                                            | GPIO controller +--------- GPIO_0
>> +------------+                             |                 | ...
>> | Parent IRQ |                             |
>> +--------- GPIO_[apm,irq-start]/EXT_INT_0
>> | controller |  EXT_INT_0                  |                 | ...
>> | (GICv2)    +-----------------------------+
>> +--------- GPIO_[apm,nr-irqs + apm,irq-start - 1]/EXT_INT_[apm,nr-irqs
>> - 1]
>> |            |  ...                        |                 |
>> |            |  EXT_INT_[apm,nr-irqs - 1]  |
>> +--------- GPIO_[apm,nr-irqs + apm,irq-start]
>> |            +-----------------------------+                 | ...
>> |            |                             |                 +--------- GPIO_MAX
>> +------------+                             +-----------------+
>>
>> To fix this ambiguity, I'm thinking to change it to:
>> "apm,irq-start: Optional, specify index of first gpio pin
>> corresponding to EXT_INT_0, default is 8."
>
> I think you are missing the point I'm trying to make. There are two ways
> to refer to an SPI: either by its absolute number (INT32 for example) or
> by its relative number (SPI0). SPI0 and INT32 are the same interrupt.
> Just with a different base.
>
> My question is: which base are you using? By looking at the code, I
> think you're using the absolute version (INTx). And as your controller
> seems to be very GIC specific, you should add a pointer to the GIC
> documentation.
>

Sorry, Marc, I was misunderstood.

It is relative number, EXT_INT_0 corresponding with SPI40 and so on.
So, how about adding more specific description into the diagram as below ?

--- a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
@@ -3,18 +3,18 @@ APM X-Gene Standby GPIO controller bindings
 This is a gpio controller in the standby domain. It also supports interrupt in
 some particular pins which are sourced to its parent interrupt controller
 as diagram below:
-                           +-----------------+
-                           | X-Gene standby  |
-                           | GPIO controller +--------- GPIO_0
-+------------+             |                 | ...
-| Parent IRQ |             |                 +--------- GPIO_8/EXT_INT_0
-| controller |  EXT_INT_0  |                 | ...
-| (GICv2)    +-------------+                 +--------- GPIO_[N+8]/EXT_INT_N
-|            |  ...        |                 |
-|            |  EXT_INT_N  |                 +--------- GPIO_[N+9]
-|            +-------------+                 | ...
-|            |             |                 +--------- GPIO_MAX
-+------------+             +-----------------+
+                            +-----------------+
+                            | X-Gene standby  |
+                            | GPIO controller +------ GPIO_0
++------------+              |                 | ...
+| Parent IRQ | EXT_INT_0    |                 +------ GPIO_8/EXT_INT_0
+| controller | (SPI40)      |                 | ...
+| (GICv2)    +--------------+                 +------ GPIO_[N+8]/EXT_INT_N
+|            |   ...        |                 |
+|            | EXT_INT_N    |                 +------ GPIO_[N+9]
+|            | (SPI[40 + N])|                 | ...
+|            +--------------+                 +------ GPIO_MAX
++------------+              +-----------------+

 Required properties:
 - compatible: "apm,xgene-gpio-sb" for the X-Gene Standby GPIO controller


Thanks,
-- Quan Nguyen


From sudeep.holla at arm.com  Mon Feb 15 09:41:42 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon, 15 Feb 2016 17:41:42 +0000
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <56C1F19F.8090100@roeck-us.net>
References: <20160214165010.GA3189@roeck-us.net>
 <20160215105909.GH12289@pengutronix.de> <56C1F19F.8090100@roeck-us.net>
Message-ID: <56C20DD6.8050604@arm.com>



On 15/02/16 15:41, Guenter Roeck wrote:
> On 02/15/2016 02:59 AM, Uwe Kleine-K?nig wrote:
>> Hello Guenter,
>>
>> On Sun, Feb 14, 2016 at 08:50:10AM -0800, Guenter Roeck wrote:
>>> Uwe,
>>>
>>> Your patch 'driver-core: platform: probe of-devices only using list of
>>> compatibles' causes the following qemu tests to crash in -next.
>>>
>>> arm:vexpress-a9:vexpress_defconfig:vexpress-v2p-ca9
>>> arm:vexpress-a15:vexpress_defconfig:vexpress-v2p-ca15-tc1
>>> arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>>> arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>>>
>>> Crash log:
>>>
>>> VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6
>>> Please append a correct "root=" boot option; here are the available
>>> partitions:
>>> 1f00          131072 mtdblock0  (driver?)
>>> 1f01           32768 mtdblock1  (driver?)
>>> Kernel panic - not syncing: VFS: Unable to mount root fs on
>>> unknown-block(0,0)
>>
>> Can you provide a complete boot log? This might already reveal which
>> device is failing. It might not be the mmci device but something it
>> depends on (clock, bus parent, irq).
>>
>
> Sure, something else may be failing, but why does reverting your patch
> fix the problem ?
>
> Anyway, complete logs are at http://kerneltests.org/builders.
>
> http://kerneltests.org/builders/qemu-arm-next/builds/376/steps/qemubuildcommand/logs/stdio
>
>

Sorry for missing this earlier, I could reproduce this on my TC2.
The issue is with card-detect gpio probing. It's not related to AMBA
probing as discussed on the mail thread.

mfd_add_device adds devices with of_node when cell->of_compatible is
matched, but the device created is expected to be matched based on name
which the patch under discussion clearly breaks.

One other option I see is to set driver_override for mfd devices
(something like below) but I am not sure that can be generic.

-- 
Regards,
Sudeep


From will.deacon at arm.com  Mon Feb 15 09:46:56 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Feb 2016 17:46:56 +0000
Subject: [PATCH v4 21/23] arm64: hw_breakpoint: Allow EL2 breakpoints if
 running in HYP
In-Reply-To: <1455216004-19499-22-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
 <1455216004-19499-22-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160215174656.GN6298@arm.com>

On Thu, Feb 11, 2016 at 06:40:02PM +0000, Marc Zyngier wrote:
> With VHE, we place kernel {watch,break}-points at EL2 to get things
> like kgdb and "perf -e mem:..." working.
> 
> This requires a bit of repainting in the low-level encore/decode,
> but is otherwise pretty simple.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/hw_breakpoint.h | 49 +++++++++++++++++++++-------------
>  1 file changed, 31 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
> index 9732908..4d8d5a8 100644
> --- a/arch/arm64/include/asm/hw_breakpoint.h
> +++ b/arch/arm64/include/asm/hw_breakpoint.h
> @@ -18,6 +18,7 @@
>  
>  #include <asm/cputype.h>
>  #include <asm/cpufeature.h>
> +#include <asm/virt.h>
>  
>  #ifdef __KERNEL__
>  
> @@ -35,24 +36,6 @@ struct arch_hw_breakpoint {
>  	struct arch_hw_breakpoint_ctrl ctrl;
>  };
>  
> -static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
> -{
> -	return (ctrl.len << 5) | (ctrl.type << 3) | (ctrl.privilege << 1) |
> -		ctrl.enabled;
> -}
> -
> -static inline void decode_ctrl_reg(u32 reg,
> -				   struct arch_hw_breakpoint_ctrl *ctrl)
> -{
> -	ctrl->enabled	= reg & 0x1;
> -	reg >>= 1;
> -	ctrl->privilege	= reg & 0x3;
> -	reg >>= 2;
> -	ctrl->type	= reg & 0x3;
> -	reg >>= 2;
> -	ctrl->len	= reg & 0xff;
> -}
> -
>  /* Breakpoint */
>  #define ARM_BREAKPOINT_EXECUTE	0
>  
> @@ -62,6 +45,7 @@ static inline void decode_ctrl_reg(u32 reg,
>  #define AARCH64_ESR_ACCESS_MASK	(1 << 6)
>  
>  /* Privilege Levels */
> +#define AARCH64_BREAKPOINT_EL2	0
>  #define AARCH64_BREAKPOINT_EL1	1
>  #define AARCH64_BREAKPOINT_EL0	2
>  
> @@ -76,6 +60,35 @@ static inline void decode_ctrl_reg(u32 reg,
>  #define ARM_KERNEL_STEP_ACTIVE	1
>  #define ARM_KERNEL_STEP_SUSPEND	2
>  
> +#define DBG_HMC_HYP		(1 << 13)
> +#define DBG_SSC_HYP		(3 << 14)

Why do we need to touch the SSC field at all?

> +
> +static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
> +{
> +	u32 val = (ctrl.len << 5) | (ctrl.type << 3) | ctrl.enabled;
> +
> +	if (is_kernel_in_hyp_mode() && ctrl.privilege == AARCH64_BREAKPOINT_EL1)
> +		val |= DBG_HMC_HYP | DBG_SSC_HYP | (AARCH64_BREAKPOINT_EL2 << 1);

I don't think this is correct. We want to allow, for example, a userspace
watchpoint to fire thanks to something like put_user, so the encoding
really needs to build up the PMC field (like we do already), then orr in
the HMC field.

The "gotcha", which is similar to the PMU stuff, is that you can't have
HMC==1 (EL2) and PMC==2 (i.e. EL2 and EL0, but not EL1).

I *think* the conclusion is that you need AARCH64_BREAKPOINT_EL2 to look
like DBG_HMC_HYP | AARCH64_BREAKPOINT_EL1.

Will


From rostedt at goodmis.org  Mon Feb 15 09:47:46 2016
From: rostedt at goodmis.org (Steven Rostedt)
Date: Mon, 15 Feb 2016 12:47:46 -0500
Subject: [PATCH] branch tracer: fix freak link error
In-Reply-To: <1455312410-1058841-1-git-send-email-arnd@arndb.de>
References: <1455312410-1058841-1-git-send-email-arnd@arndb.de>
Message-ID: <20160215124746.44e8c2d0@gandalf.local.home>

On Fri, 12 Feb 2016 22:26:42 +0100
Arnd Bergmann <arnd at arndb.de> wrote:

> In my randconfig tests, I came across a bug that involves several
> components:
> 
>

[..]

> 
> This patch avoids the problem by changing __trace_if() to check
> whether the condition is known at compile-time to be nonzero, rather
> than checking whether it is actually a constant.
> 
> I see this one link error in roughly one out of 1600 randconfig builds
> on ARM, and the patch fixes all known instances.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: ab3c9c686e22 ("branch tracer, intel-iommu: fix build with CONFIG_BRANCH_TRACER=y")

Want me to pull this into my queue? I have another patch I need to send
to Linus and I can add this in that pull request.

-- Steve



From linux at arm.linux.org.uk  Mon Feb 15 09:52:50 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Feb 2016 17:52:50 +0000
Subject: [PATCH v5 RESEND 4/5] ARM: amba: Move reading of periphid to
 amba_match()
In-Reply-To: <1455101250-11327-5-git-send-email-m.szyprowski@samsung.com>
References: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
 <1455101250-11327-5-git-send-email-m.szyprowski@samsung.com>
Message-ID: <20160215175250.GJ10826@n2100.arm.linux.org.uk>

On Wed, Feb 10, 2016 at 11:47:29AM +0100, Marek Szyprowski wrote:
> From: Tomeu Vizoso <tomeu.vizoso at collabora.com>
> 
> Reading the periphid when the Primecell device is registered means that
> the apb pclk must be available by then or the device won't be registered
> at all.
> 
> By reading the periphid in amba_match() we can return -EPROBE_DEFER if
> the apb pclk isn't there yet and the device will be retried later.

I've just realised, we can't do this.  We need to read the peripheral
ID at registration time, because that's published to userspace via
(a) a sysfs attribute, and (b) as part of the uevent, which will be
used by udev to locate the driver module.

So, this will have the side effect of breaking systems which have
AMBA primecell devices configured as modules.

Sorry, I can't apply this.  We can't regress existing platforms for
the sake of introducing new platforms to this code.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From rostedt at goodmis.org  Mon Feb 15 09:46:06 2016
From: rostedt at goodmis.org (Steven Rostedt)
Date: Mon, 15 Feb 2016 12:46:06 -0500
Subject: [PATCH 2/5] Kbuild: disable 'maybe-uninitialized' warning for
 CONFIG_PROFILE_ALL_BRANCHES
In-Reply-To: <1455293187-179811-3-git-send-email-arnd@arndb.de>
References: <1455293187-179811-1-git-send-email-arnd@arndb.de>
 <1455293187-179811-3-git-send-email-arnd@arndb.de>
Message-ID: <20160215174606.GA11406@home.goodmis.org>

On Fri, Feb 12, 2016 at 05:06:19PM +0100, Arnd Bergmann wrote:
> CONFIG_PROFILE_ALL_BRANCHES confuses gcc-5.x to the degree that it prints
> incorrect warnings about a lot of variables that it thinks can be used
> uninitialized, e.g.:
> 
> i2c/busses/i2c-diolan-u2c.c: In function 'diolan_usb_xfer':
> i2c/busses/i2c-diolan-u2c.c:391:16: warning: 'byte' may be used uninitialized in this function
> iio/gyro/itg3200_core.c: In function 'itg3200_probe':
> iio/gyro/itg3200_core.c:213:6: warning: 'val' may be used uninitialized in this function
> leds/leds-lp55xx-common.c: In function 'lp55xx_update_bits':
> leds/leds-lp55xx-common.c:350:6: warning: 'tmp' may be used uninitialized in this function
> misc/bmp085.c: In function 'show_pressure':
> misc/bmp085.c:363:10: warning: 'pressure' may be used uninitialized in this function
> power/ds2782_battery.c: In function 'ds2786_get_capacity':
> power/ds2782_battery.c:214:17: warning: 'raw' may be used uninitialized in this function
> 
> These are all false positives that either rob someone's time when trying
> to figure out whether they are real, or they get people to send wrong
> patches to shut up the warnings.
> 
> Nobody normally wants to run a CONFIG_PROFILE_ALL_BRANCHES kernel in
> production, so disabling the whole class of warnings for this configuration
> has no serious downsides either.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Acked-by: Steven Rostedt <rostedt at goodmis.org>

-- Steve

> ---
>  Makefile | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index 9092c16fa6cf..352f55ccc54e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -617,7 +617,11 @@ KBUILD_CFLAGS	+= $(call cc-option,-fno-delete-null-pointer-checks,)
>  ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
>  KBUILD_CFLAGS	+= -Os $(call cc-disable-warning,maybe-uninitialized,)
>  else
> -KBUILD_CFLAGS	+= -O2
> +ifdef CONFIG_PROFILE_ALL_BRANCHES
> +KBUILD_CFLAGS	+= -O2 $(call cc-disable-warning,maybe-uninitialized,)
> +else
> +KBUILD_CFLAGS   += -O2
> +endif
>  endif
>  
>  # Tell gcc to never replace conditional load with a non-conditional one
> -- 
> 2.7.0


From paulmck at linux.vnet.ibm.com  Mon Feb 15 09:58:25 2016
From: paulmck at linux.vnet.ibm.com (Paul E. McKenney)
Date: Mon, 15 Feb 2016 09:58:25 -0800
Subject: Writes, smp_wmb(), and transitivity?
Message-ID: <20160215175825.GA15878@linux.vnet.ibm.com>

Hello!

Some architectures provide local transitivity for a chain of threads doing
writes separated by smp_wmb(), as exemplified by the litmus tests below.
The pattern is that each thread writes to a its own variable, does an
smp_wmb(), then writes a different value to the next thread's variable.

I don't know of a use of this, but if everyone supports it, it might
be good to mandate it.  Status quo is that smp_wmb() is non-transitive,
so it currently isn't supported.

Anyone know of any architectures that do -not- support this?

Assuming all architectures -do- support this, any arguments -against-
officially supporting it in Linux?

							Thanx, Paul

------------------------------------------------------------------------

Two threads:

	int a, b;

	void thread0(void)
	{
		WRITE_ONCE(a, 1);
		smp_wmb();
		WRITE_ONCE(b, 2);
	}

	void thread1(void)
	{
		WRITE_ONCE(b, 1);
		smp_wmb();
		WRITE_ONCE(a, 2);
	}

	/* After all threads have completed and the dust has settled... */

	BUG_ON(a == 1 && b == 1);

Three threads:

	int a, b, c;

	void thread0(void)
	{
		WRITE_ONCE(a, 1);
		smp_wmb();
		WRITE_ONCE(b, 2);
	}

	void thread1(void)
	{
		WRITE_ONCE(b, 1);
		smp_wmb();
		WRITE_ONCE(c, 2);
	}

	void thread2(void)
	{
		WRITE_ONCE(c, 1);
		smp_wmb();
		WRITE_ONCE(a, 2);
	}

	/* After all threads have completed and the dust has settled... */

	BUG_ON(a == 1 && b == 1 && c == 1);

Four threads:

	int a, b, c, d;

	void thread0(void)
	{
		WRITE_ONCE(a, 1);
		smp_wmb();
		WRITE_ONCE(b, 2);
	}

	void thread1(void)
	{
		WRITE_ONCE(b, 1);
		smp_wmb();
		WRITE_ONCE(c, 2);
	}

	void thread2(void)
	{
		WRITE_ONCE(c, 1);
		smp_wmb();
		WRITE_ONCE(d, 2);
	}

	void thread3(void)
	{
		WRITE_ONCE(d, 1);
		smp_wmb();
		WRITE_ONCE(a, 2);
	}

	/* After all threads have completed and the dust has settled... */

	BUG_ON(a == 1 && b == 1 && c == 1 && d == 1);

And so on...



From linux at arm.linux.org.uk  Mon Feb 15 10:03:33 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Feb 2016 18:03:33 +0000
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <56C20DD6.8050604@arm.com>
References: <20160214165010.GA3189@roeck-us.net>
 <20160215105909.GH12289@pengutronix.de>
 <56C1F19F.8090100@roeck-us.net> <56C20DD6.8050604@arm.com>
Message-ID: <20160215180333.GK10826@n2100.arm.linux.org.uk>

On Mon, Feb 15, 2016 at 05:41:42PM +0000, Sudeep Holla wrote:
> Sorry for missing this earlier, I could reproduce this on my TC2.
> The issue is with card-detect gpio probing. It's not related to AMBA
> probing as discussed on the mail thread.
> 
> mfd_add_device adds devices with of_node when cell->of_compatible is
> matched, but the device created is expected to be matched based on name
> which the patch under discussion clearly breaks.

If I'm understanding you correctly, you're saying that MFD re-adds
platform devices with the of_node of a new platform device pointing
to an existing of_node, but expects this new platform device to
match a _different_ driver?

Sounds like MFD needs fixing.  I've said this before: of_node's must
_never_ be copied between different device structures, especially
when they are on the _same_ bus - quite simply because the driver
core _can_ match using the DT compatible.

For example... let's say you have a platform device called "1234.foo"
created by DT with compatible of "example,foo".  You have two platform
drivers.  One of them matches compatible "example,foo" and the other
matches against platform devices with a name of "bar".

The "example,foo" device driver is matched against "1234.foo".  It
creates a platform device with a name of "bar" and bus ID "bar.0",
setting the of_node to the same as "1234.foo".

When scanning for a matching driver, if the "example,foo" driver is
found first, "bar.0" will be matched to this driver, and its probe
method called.  If it accepts this device, it will repeat its action,
creating "bar.1".  Repeat until you run out of memory.

If it instead finds the "bar" driver first, this driver will be used
and everything appears to work correctly.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From tony at atomide.com  Mon Feb 15 10:06:36 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 15 Feb 2016 10:06:36 -0800
Subject: GPIO regression in Linux next caused by syscon change
In-Reply-To: <20160215164757.GV19432@atomide.com>
References: <20160213002643.GQ19432@atomide.com>
 <20160213004935.GR19432@atomide.com>
 <CA+gwMccZeYimupmGsMX8YbNH9eEA6=Xi=rupciubBwzktfjvBA@mail.gmail.com>
 <20160215160115.GU19432@atomide.com>
 <1455552961.4899.37.camel@pengutronix.de>
 <20160215164757.GV19432@atomide.com>
Message-ID: <20160215180635.GW19432@atomide.com>

* Tony Lindgren <tony at atomide.com> [160215 08:49]:
> * Philipp Zabel <p.zabel at pengutronix.de> [160215 08:17]:
> > Am Montag, den 15.02.2016, 08:01 -0800 schrieb Tony Lindgren:
> > > * Philipp Zabel <philipp.zabel at gmail.com> [160214 11:24]:
> > > > I've just replaced the of_iomap() call with an open coded version,
> > > > calling of_address_to_resource() and ioremap() directly. That was
> > > > needed so I can use the struct resource returned by
> > > > of_address_to_resource() to set the syscon_config.max_register. I
> > > > don't see where this could cause resource overlap. Does just setting
> > > > syscon_config.max_register to zero again make the problem disappear?
> > > 
> > > Yes commenting out the syscon_config.max_register line in your patch
> > > makes things work again.
> > > 
> > > So what does that tell us about the problem?
> > 
> > Maybe some out of bounds writes that previously worked are now catched
> > by the max_register check in regmap_writable and regmap_write returns
> > -EIO instead of the write being executed.
> 
> Hmm weird that something like that would not produce errors?
> 
> > Is there any omap_ctrl_write?() call with an offset > 0x32c into
> > scm_conf?
> 
> Indeed, that's where things go wrong. Adding Tero to Cc, something
> is wrong there.

Something like this might fix it? Needs to be tested to see if it
happens on other omaps.

Tero, got any better ideas?

Regards,

Tony

8< -------------------
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -167,15 +167,23 @@ u16 omap_ctrl_readw(u16 offset)
 u32 omap_ctrl_readl(u16 offset)
 {
 	u32 val;
+	int err;
 
 	offset &= 0xfffc;
-	if (!omap2_ctrl_syscon)
-		val = readl_relaxed(omap2_ctrl_base + offset);
-	else
-		regmap_read(omap2_ctrl_syscon, omap2_ctrl_offset + offset,
-			    &val);
+	if (omap2_ctrl_syscon) {
+		err = regmap_read(omap2_ctrl_syscon,
+				  omap2_ctrl_offset + offset, &val);
+		if (!err)
+			return val;
+	}
+
+	if (WARN(!omap2_ctrl_base,
+		 "syscon out of range for offset 0x%x, no omap2_ctrl_base?\n",
+		    offset)) {
+		return 0;
+	}
 
-	return val;
+	return readl_relaxed(omap2_ctrl_base + offset);
 }
 
 void omap_ctrl_writeb(u8 val, u16 offset)
@@ -206,12 +214,23 @@ void omap_ctrl_writew(u16 val, u16 offset)
 
 void omap_ctrl_writel(u32 val, u16 offset)
 {
+	int err;
+
 	offset &= 0xfffc;
-	if (!omap2_ctrl_syscon)
-		writel_relaxed(val, omap2_ctrl_base + offset);
-	else
-		regmap_write(omap2_ctrl_syscon, omap2_ctrl_offset + offset,
-			     val);
+	if (omap2_ctrl_syscon) {
+		err = regmap_write(omap2_ctrl_syscon,
+				   omap2_ctrl_offset + offset, val);
+		if (!err)
+			return;
+	}
+
+	if (WARN(!omap2_ctrl_base,
+		 "syscon out of range for offset 0x%x, no omap2_ctrl_base?\n",
+		    offset)) {
+		return;
+	}
+
+	writel_relaxed(val, omap2_ctrl_base + offset);
 }
 
 #ifdef CONFIG_ARCH_OMAP3
@@ -724,9 +743,6 @@ int __init omap_control_init(void)
 				if (ret)
 					return ret;
 			}
-
-			iounmap(omap2_ctrl_base);
-			omap2_ctrl_base = NULL;
 		} else {
 			/* No scm_conf found, direct access */
 			ret = omap2_clk_provider_init(np, data->index, NULL,


From geert at linux-m68k.org  Mon Feb 15 10:08:32 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 19:08:32 +0100
Subject: Build regressions/improvements in v4.5-rc4
In-Reply-To: <1455559593-26369-1-git-send-email-geert@linux-m68k.org>
References: <1455559593-26369-1-git-send-email-geert@linux-m68k.org>
Message-ID: <CAMuHMdVDyep0cPPB-Mh5CfRSt4Do_F_j6WMkwzjRfz_jDZLLeQ@mail.gmail.com>

On Mon, Feb 15, 2016 at 7:06 PM, Geert Uytterhoeven
<geert at linux-m68k.org> wrote:
> JFYI, when comparing v4.5-rc4[1] to v4.5-rc3[3], the summaries are:
>   - build errors: +17/-11

  + /home/kisskb/slave/src/arch/arm/include/asm/div64.h: error: 'asm'
operand has impossible constraints:  => 93:3, 111:3
  + /home/kisskb/slave/src/arch/arm/include/asm/div64.h: error: can't
find a register in class 'GENERAL_REGS' while reloading 'asm':  =>
111:3

arm-randconfig

  + error: initramfs.c: undefined reference to `__stack_chk_guard':
=> .init.text+0x373c)

i386-randconfig

> [1] http://kisskb.ellerman.id.au/kisskb/head/9916/ (all 262 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/9888/ (all 262 configs)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From aleksey.makarov at linaro.org  Mon Feb 15 10:05:24 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 15 Feb 2016 21:05:24 +0300
Subject: [PATCH v3 0/5] ACPI: parse the SPCR table
Message-ID: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>

This patchset is based on the patchset by Leif Lindholm [1]

'ARM Server Base Boot Requirements' [2] mentions SPCR (Serial Port
Console Redirection Table) [3] as a mandatory ACPI table that
specifies the configuration of serial console.

SPCR support is included in QEMU's ARM mach-virt since 2.4 release.

Introduce a new function acpi_console_check().  At the uart port
registration, this function checks if the ACPI SPCR table specifies
its argument of type struct uart_port to be a console
and if so calls add_preferred_console().

Use SPCR to tell if SBSA serial driver should use 32-bit access to registers.

To be able to access SPCR table each time any console is registered
change __init to __ref for early_acpi_os_unmap_memory().

The patchset should be applied to tty-next.

v3:
Greg Kroah-Hartman did not like v2 so I have rewritten this patchset:

- drop acpi_match() member of struct console
- drop implementations of this member for pl011 and 8250
- drop the patch that renames some vars in printk.c as it is not needed anymore
- drpo patch that introduces system wide acpi_table_parse2().
  Instead introduce a custom acpi_table_parse_spcr() in spcr.c

Instead of introducing a new match_acpi() member of struct console,
this patchset introduces a new function acpi_console_check().
This function is called when a new uart is registered at serial_core.c
the same way OF code checks for console.  If the registered uart is the
console specified by SPCR table, this function calls add_preferred_console()

The restrictions of this approach are:

- only serial consoles can be set up
- only consoles specified by the memory/io address can be set up
  (SPCR can specify devices by PCI id/PCI address)

v2:
https://lkml.kernel.org/g/1455299022-11641-1-git-send-email-aleksey.makarov at linaro.org
- don't use SPCR if user specified console in command line
- fix initialization order of newcon->index = 0
- rename some variables at printk.c (Joe Perches, Peter Hurley)
- enable ACPI_SPCR_TABLE in a separate patch (Andy Shevchenko)
- remove the retry loop for console registering (Peter Hurley).
  Instead, obtain SPCR with acpi_get_table().  That works after
  call to acpi_early_init() i. e. in any *_initcall()
- describe design decision behind introducing acpi_match() (Peter Hurley)
- fix compilation for x86 + ACPI (Graeme Gregory)
- introduce DBG2 constants in a separate patch (Andy Shevchenko)
- fix a typo in DBG2 constants (Andy Shevchenko)
- add ACPI_DBG2_ARM_SBSA_32BIT constant (Christopher Covington)
- add support for ACPI_DBG2_ARM_SBSA_* consoles (Christopher Covington)
- add documentation for functions
- add a patch that uses SPCR to find if SBSA serial driver should use 32-bit
  accessor functions (Christopher Covington)
- change __init to __ref for early_acpi_os_unmap_memory() in a separate patch
- introduce acpi_table_parse2() in a separate patch
- fix fetching the SPCR table early (Mark Salter)
- add a patch from Mark Salter that introduces support for matching 8250-based
  consoles

v1:
https://lkml.kernel.org/g/1453722324-22407-1-git-send-email-aleksey.makarov at linaro.org

[1] https://lkml.kernel.org/g/1441716217-23786-1-git-send-email-leif.lindholm at linaro.org
[2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
[3] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx

Aleksey Makarov (5):
  ACPI: change __init to __ref for early_acpi_os_unmap_memory()
  ACPI: parse SPCR and enable matching console
  ACPI: enable ACPI_SPCR_TABLE on ARM64
  ACPI: add definition of DBG2 subtypes
  serial: pl011: use SPCR to setup 32-bit access

 arch/arm64/Kconfig               |   1 +
 drivers/acpi/Kconfig             |   3 +
 drivers/acpi/Makefile            |   1 +
 drivers/acpi/osl.c               |   6 +-
 drivers/acpi/spcr.c              | 122 +++++++++++++++++++++++++++++++++++++++
 drivers/tty/serial/amba-pl011.c  |   2 +
 drivers/tty/serial/serial_core.c |  14 ++++-
 include/acpi/actbl2.h            |   5 ++
 include/linux/acpi.h             |  15 +++++
 9 files changed, 166 insertions(+), 3 deletions(-)
 create mode 100644 drivers/acpi/spcr.c

-- 
2.7.1



From aleksey.makarov at linaro.org  Mon Feb 15 10:05:25 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 15 Feb 2016 21:05:25 +0300
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>

early_acpi_os_unmap_memory() is marked as __init because it calls
__acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is not set.

acpi_gbl_permanent_mmap is set in __init acpi_early_init()
so it is safe to call early_acpi_os_unmap_memory() from anywhere

We need this function to be non-__init because we need access to
some tables at unpredictable time--it may be before or after
acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port Console
Redirection) table is needed each time a new console is registered.
It can be quite early (console_initcall) or when a module is inserted.
When this table accessed before acpi_gbl_permanent_mmap is set,
the pointer should be unmapped.  This is exactly what this function
does.

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 drivers/acpi/osl.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 67da6fb..8a552cd 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void *virt, acpi_size size)
 }
 EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
 
-void __init early_acpi_os_unmap_memory(void __iomem *virt, acpi_size size)
+/*
+ * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
+ * so it is safe to call early_acpi_os_unmap_memory() from anywhere
+ */
+void __ref early_acpi_os_unmap_memory(void __iomem *virt, acpi_size size)
 {
 	if (!acpi_gbl_permanent_mmap)
 		__acpi_unmap_table(virt, size);
-- 
2.7.1



From aleksey.makarov at linaro.org  Mon Feb 15 10:05:26 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 15 Feb 2016 21:05:26 +0300
Subject: [PATCH v3 2/5] ACPI: parse SPCR and enable matching console
In-Reply-To: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1455559532-8305-3-git-send-email-aleksey.makarov@linaro.org>

'ARM Server Base Boot Requiremets' [1] mentions SPCR (Serial Port
Console Redirection Table) [2] as a mandatory ACPI table that
specifies the configuration of serial console.

Parse this table and check if any registered console match the
description.  If it does, enable that console.

Introduce a new function acpi_console_check().  At the uart port
registration, this function checks if the ACPI SPCR table specifies
its argument of type struct uart_port to be a console
and if so calls add_preferred_console().

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
[2] http://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 drivers/acpi/Kconfig             |  3 ++
 drivers/acpi/Makefile            |  1 +
 drivers/acpi/spcr.c              | 97 ++++++++++++++++++++++++++++++++++++++++
 drivers/tty/serial/serial_core.c | 14 +++++-
 include/linux/acpi.h             | 10 +++++
 5 files changed, 123 insertions(+), 2 deletions(-)
 create mode 100644 drivers/acpi/spcr.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 65fb483..5611eb6 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -77,6 +77,9 @@ config ACPI_DEBUGGER_USER
 
 endif
 
+config ACPI_SPCR_TABLE
+	bool
+
 config ACPI_SLEEP
 	bool
 	depends on SUSPEND || HIBERNATION
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 346101c..708b143 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_ACPI_EC_DEBUGFS)	+= ec_sys.o
 obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
 obj-$(CONFIG_ACPI_BGRT)		+= bgrt.o
 obj-$(CONFIG_ACPI_CPPC_LIB)	+= cppc_acpi.o
+obj-$(CONFIG_ACPI_SPCR_TABLE)	+= spcr.o
 obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
 
 # processor has its own "processor." module_param namespace
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
new file mode 100644
index 0000000..a1eca91
--- /dev/null
+++ b/drivers/acpi/spcr.c
@@ -0,0 +1,97 @@
+/*
+ * Copyright (c) 2012, Intel Corporation
+ * Copyright (c) 2015, Red Hat, Inc.
+ * Copyright (c) 2015, 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#define pr_fmt(fmt) "ACPI: SPCR: " fmt
+
+#include <linux/acpi.h>
+#include <linux/console.h>
+#include <linux/kernel.h>
+#include <linux/serial_core.h>
+
+static int acpi_table_parse_spcr(int (*handler)(struct acpi_table_spcr *table,
+						void *data), void *data)
+{
+	struct acpi_table_spcr *table = NULL;
+	acpi_size table_size;
+	acpi_status status;
+	int err;
+
+	status = acpi_get_table_with_size(ACPI_SIG_SPCR, 0,
+					  (struct acpi_table_header **)&table,
+					  &table_size);
+
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	err = handler(table, data);
+
+	early_acpi_os_unmap_memory(table, table_size);
+
+	return err;
+}
+
+static int spcr_table_handler_check(struct acpi_table_spcr *table, void *data)
+{
+	struct uart_port *uport = data;
+	char *options;
+
+	if (table->header.revision < 2)
+		return -EOPNOTSUPP;
+
+	switch (table->baud_rate) {
+	case 3:
+		options = "9600";
+		break;
+	case 4:
+		options = "19200";
+		break;
+	case 6:
+		options = "57600";
+		break;
+	case 7:
+		options = "115200";
+		break;
+	default:
+		options = "";
+		break;
+	}
+
+	if ((table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY &&
+	     table->serial_port.address == (u64)uport->mapbase) ||
+	    (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_IO &&
+	     table->serial_port.address == (u64)uport->iobase)) {
+		pr_info("adding preferred console [%s%d]\n", uport->cons->name,
+			uport->line);
+		add_preferred_console(uport->cons->name, uport->line, options);
+		return 1;
+
+	}
+
+	return 0;
+}
+
+/**
+ * acpi_console_check - Check if uart matches the console specified by SPCR.
+ *
+ * @uport:	uart port to check
+ *
+ * This function checks if the ACPI SPCR table specifies @uport to be a console
+ * and if so calls add_preferred_console()
+ *
+ * Return: a non-error value if the console matches.
+ */
+bool acpi_console_check(struct uart_port *uport)
+{
+	if (acpi_disabled || console_set_on_cmdline)
+		return false;
+
+	return acpi_table_parse_spcr(spcr_table_handler_check, uport) > 0;
+}
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index a126a60..459ab54 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -34,6 +34,7 @@
 #include <linux/serial_core.h>
 #include <linux/delay.h>
 #include <linux/mutex.h>
+#include <linux/acpi.h>
 
 #include <asm/irq.h>
 #include <asm/uaccess.h>
@@ -2654,8 +2655,17 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
 		spin_lock_init(&uport->lock);
 		lockdep_set_class(&uport->lock, &port_lock_key);
 	}
-	if (uport->cons && uport->dev)
-		of_console_check(uport->dev->of_node, uport->cons->name, uport->line);
+
+	/*
+	 * Support both open FW and ACPI access to console definitions.
+	 * Both of_console_check() and acpi_console_check() will call
+	 * add_preferred_console() if a console definition is found.
+	 */
+	if (uport->cons && uport->dev) {
+		if (!acpi_console_check(uport))
+			of_console_check(uport->dev->of_node, uport->cons->name,
+					 uport->line);
+	}
 
 	uart_configure_port(drv, state, uport);
 
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 06ed7e5..ea0c297 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1004,4 +1004,14 @@ static inline struct fwnode_handle *acpi_get_next_subnode(struct device *dev,
 #define acpi_probe_device_table(t)	({ int __r = 0; __r;})
 #endif
 
+struct uart_port;
+#ifdef CONFIG_ACPI_SPCR_TABLE
+bool acpi_console_check(struct uart_port *uport);
+#else
+static inline bool acpi_console_check(struct uart_port *uport)
+{
+	return FALSE;
+}
+#endif
+
 #endif	/*_LINUX_ACPI_H*/
-- 
2.7.1



From aleksey.makarov at linaro.org  Mon Feb 15 10:05:27 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 15 Feb 2016 21:05:27 +0300
Subject: [PATCH v3 3/5] ACPI: enable ACPI_SPCR_TABLE on ARM64
In-Reply-To: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1455559532-8305-4-git-send-email-aleksey.makarov@linaro.org>

SBBR mentions SPCR as a mandatory ACPI table.
So enable it for ARM64

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6bb21d8..75739cd 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -3,6 +3,7 @@ config ARM64
 	select ACPI_CCA_REQUIRED if ACPI
 	select ACPI_GENERIC_GSI if ACPI
 	select ACPI_REDUCED_HARDWARE_ONLY if ACPI
+	select ACPI_SPCR_TABLE if ACPI
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_ELF_RANDOMIZE
-- 
2.7.1



From aleksey.makarov at linaro.org  Mon Feb 15 10:05:28 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 15 Feb 2016 21:05:28 +0300
Subject: [PATCH v3 4/5] ACPI: add definition of DBG2 subtypes
In-Reply-To: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1455559532-8305-5-git-send-email-aleksey.makarov@linaro.org>

The recent version of Microsoft Debug Port Table 2 (DBG2) [1]
specifies additional serial debug port subtypes.  These constants
are also referred by Serial Port Console Redirection Table (SPCR) [2]

Add these constants.

[1] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
[2] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 include/acpi/actbl2.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index a4ef625..e9930ab 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -371,6 +371,11 @@ struct acpi_dbg2_device {
 
 #define ACPI_DBG2_16550_COMPATIBLE  0x0000
 #define ACPI_DBG2_16550_SUBSET      0x0001
+#define ACPI_DBG2_ARM_PL011         0x0003
+#define ACPI_DBG2_ARM_SBSA_32BIT    0x000d
+#define ACPI_DBG2_ARM_SBSA_GENERIC  0x000e
+#define ACPI_DBG2_ARM_DCC           0x000f
+#define ACPI_DBG2_BCM2835           0x0010
 
 #define ACPI_DBG2_1394_STANDARD     0x0000
 
-- 
2.7.1



From aleksey.makarov at linaro.org  Mon Feb 15 10:05:29 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 15 Feb 2016 21:05:29 +0300
Subject: [PATCH v3 5/5] serial: pl011: use SPCR to setup 32-bit access
In-Reply-To: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1455559532-8305-6-git-send-email-aleksey.makarov@linaro.org>

Some implementations of ARM SBSA serial port hardware require that access
to the registers should be 32-bit.  Unfortunately, the only way for
the driver to tell if it's the case is to use the data from ACPI SPCR/DBG2
tables.  In this case the value of the 'Interface Type' field of the SPCR
table is ACPI_DBG2_ARM_SBSA_32BIT.

How this value is described in the DBG2 spec:
"(deprecated) ARM SBSA (2.x only) Generic UART supporting only
32-bit accesses"

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 drivers/acpi/spcr.c             | 25 +++++++++++++++++++++++++
 drivers/tty/serial/amba-pl011.c |  2 ++
 include/linux/acpi.h            |  5 +++++
 3 files changed, 32 insertions(+)

diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index a1eca91..a5e241d 100644
--- a/drivers/acpi/spcr.c
+++ b/drivers/acpi/spcr.c
@@ -95,3 +95,28 @@ bool acpi_console_check(struct uart_port *uport)
 
 	return acpi_table_parse_spcr(spcr_table_handler_check, uport) > 0;
 }
+
+static int spcr_table_handler_32_bit(struct acpi_table_spcr *table, void *data)
+{
+	return table->interface_type == ACPI_DBG2_ARM_SBSA_32BIT;
+}
+
+/**
+ * acpi_console_sbsa_32bit - Tell if SPCR specifies 32-bit SBSA.
+ *
+ * Some implementations of ARM SBSA serial port hardware require that access
+ * to the registers should be 32-bit.  Unfortunately, the only way for
+ * the driver to tell if it's the case is to use the data from ACPI SPCR/DBG2
+ * tables.  In this case the value of the 'Interface Type' field of the SPCR
+ * table is ACPI_DBG2_ARM_SBSA_32BIT.
+ *
+ * Return: true if access should be 32-bit wide.
+ */
+bool acpi_console_sbsa_32bit(void)
+{
+	if (acpi_disabled)
+		return false;
+
+	return acpi_table_parse_spcr(spcr_table_handler_32_bit, NULL) > 0;
+}
+EXPORT_SYMBOL(acpi_console_sbsa_32bit);
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 500232a..d9ca3a4 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2541,6 +2541,8 @@ static int sbsa_uart_probe(struct platform_device *pdev)
 		baudrate = 115200;
 	}
 
+	vendor_sbsa.access_32b = acpi_console_sbsa_32bit();
+
 	portnr = pl011_find_free_port();
 	if (portnr < 0)
 		return portnr;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index ea0c297..da1eb23 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1007,11 +1007,16 @@ static inline struct fwnode_handle *acpi_get_next_subnode(struct device *dev,
 struct uart_port;
 #ifdef CONFIG_ACPI_SPCR_TABLE
 bool acpi_console_check(struct uart_port *uport);
+bool acpi_console_sbsa_32bit(void);
 #else
 static inline bool acpi_console_check(struct uart_port *uport)
 {
 	return FALSE;
 }
+static inline bool acpi_console_sbsa_32bit(void)
+{
+	return false;
+}
 #endif
 
 #endif	/*_LINUX_ACPI_H*/
-- 
2.7.1



From linux at roeck-us.net  Mon Feb 15 10:12:40 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 15 Feb 2016 10:12:40 -0800
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160215170025.GJ12289@pengutronix.de>
References: <20160214165010.GA3189@roeck-us.net>
 <20160215105909.GH12289@pengutronix.de> <56C1F19F.8090100@roeck-us.net>
 <20160215170025.GJ12289@pengutronix.de>
Message-ID: <56C21518.5030606@roeck-us.net>

On 02/15/2016 09:00 AM, Uwe Kleine-K?nig wrote:
> On Mon, Feb 15, 2016 at 07:41:19AM -0800, Guenter Roeck wrote:
>> On 02/15/2016 02:59 AM, Uwe Kleine-K?nig wrote:
>>> Hello Guenter,
>>>
>>> On Sun, Feb 14, 2016 at 08:50:10AM -0800, Guenter Roeck wrote:
>>>> Uwe,
>>>>
>>>> Your patch 'driver-core: platform: probe of-devices only using list of
>>>> compatibles' causes the following qemu tests to crash in -next.
>>>>
>>>> arm:vexpress-a9:vexpress_defconfig:vexpress-v2p-ca9
>>>> arm:vexpress-a15:vexpress_defconfig:vexpress-v2p-ca15-tc1
>>>> arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>>>> arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>>>>
>>>> Crash log:
>>>>
>>>> VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6
>>>> Please append a correct "root=" boot option; here are the available partitions:
>>>> 1f00          131072 mtdblock0  (driver?)
>>>> 1f01           32768 mtdblock1  (driver?)
>>>> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
>>>
>>> Can you provide a complete boot log? This might already reveal which
>>> device is failing. It might not be the mmci device but something it
>>> depends on (clock, bus parent, irq).
>>>
>>
>> Sure, something else may be failing, but why does reverting your patch
>> fix the problem ?
>
> Well, my patch made matching of platform devices to platform drivers
> more strict. Your machine relies on the respective binding though. So of
> course reverting my patch "repairs" your machine, but that doesn't
> necessarily mean that my patch is wrong. Even though I'm convinced in
> the meantime by Russell that there are false positives it doesn't
> necessarily imply that your case is such a false positive, too.
>
> One example of a combination of driver + device I intended to break with
> my patch was drivers/mtd/nand/mxc_nand.c and devices that got bound to
> that by name. The driver does:
>
> 	const struct of_device_id *of_id =
> 		of_match_device(mxcnd_dt_ids, host->dev);
>
> and doesn't handle of_id being NULL after that. Some people argued (also
> for other drivers in similar situations) that this cannot happen because
> all compatibles had a non-NULL device_id. That is an error that is easy
> to make and so the idea was to just not bind in such a case and safe the
> user from the surprise.
>

I added some debugging on top of your patch, and get:

platform basic-mmio-gpio.1.auto: Device node exists [/smb/motherboard/iofpga at 7,00000000/sysreg at 00000/sys_led at 08], of_driver_match_device() failed
platform basic-mmio-gpio.1.auto: platform_match_id() succeeded
platform basic-mmio-gpio.2.auto: Device node exists [/smb/motherboard/iofpga at 7,00000000/sysreg at 00000/sys_mci at 48], of_driver_match_device() failed
platform basic-mmio-gpio.2.auto: platform_match_id() succeeded
platform basic-mmio-gpio.3.auto: Device node exists [/smb/motherboard/iofpga at 7,00000000/sysreg at 00000/sys_flash at 4c], of_driver_match_device() failed
platform basic-mmio-gpio.3.auto: platform_match_id() succeeded

So it isn't the mmc driver failing to instantiate directly,
but (I think) vexpress-sysreg.

Guenter



From marc.zyngier at arm.com  Mon Feb 15 10:14:25 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Feb 2016 18:14:25 +0000
Subject: [PATCH v4 23/23] arm64: Panic when VHE and non VHE CPUs coexist
In-Reply-To: <20160215172653.GM6298@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
 <1455216004-19499-24-git-send-email-marc.zyngier@arm.com>
 <20160215172653.GM6298@arm.com>
Message-ID: <56C21581.5030003@arm.com>

On 15/02/16 17:26, Will Deacon wrote:
> On Thu, Feb 11, 2016 at 06:40:04PM +0000, Marc Zyngier wrote:
>> Having both VHE and non-VHE capable CPUs in the same system
>> is likely to be a recipe for disaster.
>>
>> If the boot CPU has VHE, but a secondary is not, we won't be
>> able to downgrade and run the kernel at EL1. Add CPU hotplug
>> to the mix, and this produces a terrifying mess.
>>
>> Let's solve the problem once and for all. If you mix VHE and
>> non-VHE CPUs in the same system, you deserve to loose, and this
>> patch makes sure you don't get a chance.
>>
>> This is implemented by storing the kernel execution level in
>> a global variable. Secondaries will park themselves in a
>> WFI loop if they observe a mismatch. Also, the primary CPU
>> will detect that the secondary CPU has died on a mismatched
>> execution level. Panic will follow.
> 
> This should really be based on Suzuki's series for handling generic
> mismatches:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401727.html
> 
> To avoid growing a dependency on something that's unlikely to make it
> for 4.6, I'd be inclined to drop your homegrown checks altogether amd
> help Suzuki with his series as a separate activity (i.e. it needn't be
> a blocker imo).

That's fine, I'll drop that one - we can revisit it and fold it into
Suzuki's series.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From sudeep.holla at arm.com  Mon Feb 15 10:15:43 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon, 15 Feb 2016 18:15:43 +0000
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160215180333.GK10826@n2100.arm.linux.org.uk>
References: <20160214165010.GA3189@roeck-us.net>
 <20160215105909.GH12289@pengutronix.de> <56C1F19F.8090100@roeck-us.net>
 <56C20DD6.8050604@arm.com> <20160215180333.GK10826@n2100.arm.linux.org.uk>
Message-ID: <56C215CF.1030509@arm.com>



On 15/02/16 18:03, Russell King - ARM Linux wrote:
> On Mon, Feb 15, 2016 at 05:41:42PM +0000, Sudeep Holla wrote:
>> Sorry for missing this earlier, I could reproduce this on my TC2.
>> The issue is with card-detect gpio probing. It's not related to AMBA
>> probing as discussed on the mail thread.
>>
>> mfd_add_device adds devices with of_node when cell->of_compatible is
>> matched, but the device created is expected to be matched based on name
>> which the patch under discussion clearly breaks.
>
> If I'm understanding you correctly, you're saying that MFD re-adds
> platform devices with the of_node of a new platform device pointing
> to an existing of_node, but expects this new platform device to
> match a _different_ driver?
>

Sorry if I was not clear.

I don't think it re-adds. IIUC mfd cells are specified inside the
mfd device DT node. MFD adds devices for it's child nodes with the
associated device node but with the name specified by MFD cells
matching the compatible.

> Sounds like MFD needs fixing.  I've said this before: of_node's must
> _never_ be copied between different device structures, especially
> when they are on the _same_ bus - quite simply because the driver
> core _can_ match using the DT compatible.
>

I don't think that's happening in this case at-least. For example:

Device node compatible: arm,vexpress-sysreg
Child node compatible: arm,vexpress-sysreg,sys_mci

MFD device is created for above child node with name
"basic-mmio-gpio.<id>.auto" as it matched the MFD cell of_compatible

Since there's no driver to match "arm,vexpress-sysreg,sys_mci", it fails
with $subject patch applied which otherwise would do normal name matching

-- 
Regards,
Sudeep


From pablo at netfilter.org  Mon Feb 15 10:14:36 2016
From: pablo at netfilter.org (Pablo Neira Ayuso)
Date: Mon, 15 Feb 2016 19:14:36 +0100
Subject: [PATCH] netfilter: tee: select NF_DUP_IPV6 unconditionally
In-Reply-To: <1454664040-1344109-1-git-send-email-arnd@arndb.de>
References: <1454664040-1344109-1-git-send-email-arnd@arndb.de>
Message-ID: <20160215181436.GA3462@salvia>

On Fri, Feb 05, 2016 at 10:20:21AM +0100, Arnd Bergmann wrote:
> The NETFILTER_XT_TARGET_TEE option selects NF_DUP_IPV6 whenever
> IP6_NF_IPTABLES is enabled, and it ensures that it cannot be
> builtin itself if NF_CONNTRACK is a loadable module, as that
> is a dependency for NF_DUP_IPV6.
> 
> However, NF_DUP_IPV6 can be enabled even if IP6_NF_IPTABLES is
> turned off, and it only really depends on IPV6. With the current
> check in tee_tg6, we call nf_dup_ipv6() whenever NF_DUP_IPV6
> is enabled. This can however be a loadable module which is
> unreachable from a built-in xt_TEE:
> 
> net/built-in.o: In function `tee_tg6':
> :(.text+0x67728): undefined reference to `nf_dup_ipv6'
> 
> The bug was originally introduced in the split of the xt_TEE module
> into separate modules for ipv4 and ipv6, and two patches tried
> to fix it unsuccessfully afterwards.
> 
> This is a revert of the the first incorrect attempt to fix it,
> going back to depending on IPV6 as the dependency, and we
> adapt the 'select' condition accordingly.

Applied, thanks Arnd.


From robert.jarzmik at free.fr  Mon Feb 15 10:22:36 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Mon, 15 Feb 2016 19:22:36 +0100
Subject: [PATCH 4/4] dmaengine: pxa_dma: fix the maximum requestor line
In-Reply-To: <20160215173300.GN19598@localhost> (Vinod Koul's message of "Mon, 
 15 Feb 2016 23:03:00 +0530")
References: <1455225798-9510-1-git-send-email-robert.jarzmik@free.fr>
 <1455225798-9510-5-git-send-email-robert.jarzmik@free.fr>
 <20160215163524.GI19598@localhost> <87fuwt28eu.fsf@belgarion.home>
 <20160215173300.GN19598@localhost>
Message-ID: <87bn7h25qr.fsf@belgarion.home>

Vinod Koul <vinod.koul at intel.com> writes:

> On Mon, Feb 15, 2016 at 06:24:57PM +0100, Robert Jarzmik wrote:
>> Vinod Koul <vinod.koul at intel.com> writes:
>> 
>> > On Thu, Feb 11, 2016 at 10:23:18PM +0100, Robert Jarzmik wrote:
>> >> @@ -1399,13 +1405,17 @@ static int pxad_probe(struct platform_device *op)
>> >>  		return PTR_ERR(pdev->base);
>> >>  
>> >>  	of_id = of_match_device(pxad_dt_ids, &op->dev);
>> >> -	if (of_id)
>> >> +	if (of_id) {
>> >>  		of_property_read_u32(op->dev.of_node, "#dma-channels",
>> >>  				     &dma_channels);
>> >> -	else if (pdata && pdata->dma_channels)
>> >> +		of_property_read_u32(op->dev.of_node, "#requestors",
>> >> +				     &nb_requestors);
>> >
>> > I think we should check the return value here. This might be err in case
>> > when we have older DT on platform, but still should work with default in
>> > that case
>> 
>> Okay, but how should the code react to the err case, more specifically to
>> -EINVAL or -ENODATA ? As this property is optional as per the device-tree
>> description, the current code leaves nb_requestors = 0, as is specified in the
>> description, and fits the mmp_pdma case.
>> 
>> What do you think should be done ? A warning message ? Something else ?
>
> Message is fine, but in order for not to regress we should set this to 32
> (IIRC default before this, right) and not zero.
Okay, got you.

For v2 I'll implement exactly this, ie. a warning message and a default to 32.
I'll amend the device-tree description also to match the 32 (and not the 0 I
wrote earlier).

Cheers.

-- 
Robert


From marc.zyngier at arm.com  Mon Feb 15 10:23:35 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Feb 2016 18:23:35 +0000
Subject: [PATCH v4 20/23] arm64: perf: Count EL2 events if the kernel is
 running in HYP
In-Reply-To: <20160215172247.GL6298@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
 <1455216004-19499-21-git-send-email-marc.zyngier@arm.com>
 <20160215172247.GL6298@arm.com>
Message-ID: <56C217A7.5020105@arm.com>

On 15/02/16 17:22, Will Deacon wrote:
> On Thu, Feb 11, 2016 at 06:40:01PM +0000, Marc Zyngier wrote:
>> When the kernel is running in HYP (with VHE), it is necessary to
>> include EL2 events if the user requests counting kernel or
>> hypervisor events.
>>
>> Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
>> Acked-by: Catalin Marinas <catalin.marinas at arm.com>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/kernel/perf_event.c | 14 ++++++++++----
>>  1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
>> index f7ab14c..6013a38 100644
>> --- a/arch/arm64/kernel/perf_event.c
>> +++ b/arch/arm64/kernel/perf_event.c
>> @@ -20,6 +20,7 @@
>>   */
>>  
>>  #include <asm/irq_regs.h>
>> +#include <asm/virt.h>
>>  
>>  #include <linux/of.h>
>>  #include <linux/perf/arm_pmu.h>
>> @@ -693,10 +694,15 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
>>  		return -EPERM;
>>  	if (attr->exclude_user)
>>  		config_base |= ARMV8_EXCLUDE_EL0;
>> -	if (attr->exclude_kernel)
>> -		config_base |= ARMV8_EXCLUDE_EL1;
>> -	if (!attr->exclude_hv)
>> -		config_base |= ARMV8_INCLUDE_EL2;
>> +	if (is_kernel_in_hyp_mode()) {
>> +		if (!attr->exclude_kernel || !attr->exclude_hv)
>> +			config_base |= ARMV8_INCLUDE_EL2;
> 
> Hmm, so if userspace sets exclude_kernel but not exclude_user and
> exclude_hv, what should we do? I'm slightly tempted to reject the
> filter with -EINVAL...

I was angling for the minimum level of surprise for the user, but
I guess that the results are going to be troubling anyway.

How about something like this on top:

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 6013a38..8c00ed4 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -695,7 +695,10 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
 	if (attr->exclude_user)
 		config_base |= ARMV8_EXCLUDE_EL0;
 	if (is_kernel_in_hyp_mode()) {
-		if (!attr->exclude_kernel || !attr->exclude_hv)
+		/* Demand that kernel and hv are consistent */
+		if (attr->exclude_kernel != attr->exclude_hv)
+			return -EINVAL;
+		if (!attr->exclude_hv)
 			config_base |= ARMV8_INCLUDE_EL2;
 	} else {
 		if (attr->exclude_kernel)

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From will.deacon at arm.com  Mon Feb 15 10:27:51 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Feb 2016 18:27:51 +0000
Subject: [PATCH v4 20/23] arm64: perf: Count EL2 events if the kernel is
 running in HYP
In-Reply-To: <56C217A7.5020105@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
 <1455216004-19499-21-git-send-email-marc.zyngier@arm.com>
 <20160215172247.GL6298@arm.com> <56C217A7.5020105@arm.com>
Message-ID: <20160215182751.GP6298@arm.com>

On Mon, Feb 15, 2016 at 06:23:35PM +0000, Marc Zyngier wrote:
> On 15/02/16 17:22, Will Deacon wrote:
> > On Thu, Feb 11, 2016 at 06:40:01PM +0000, Marc Zyngier wrote:
> >> When the kernel is running in HYP (with VHE), it is necessary to
> >> include EL2 events if the user requests counting kernel or
> >> hypervisor events.
> >>
> >> Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
> >> Acked-by: Catalin Marinas <catalin.marinas at arm.com>
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >> ---
> >>  arch/arm64/kernel/perf_event.c | 14 ++++++++++----
> >>  1 file changed, 10 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> >> index f7ab14c..6013a38 100644
> >> --- a/arch/arm64/kernel/perf_event.c
> >> +++ b/arch/arm64/kernel/perf_event.c
> >> @@ -20,6 +20,7 @@
> >>   */
> >>  
> >>  #include <asm/irq_regs.h>
> >> +#include <asm/virt.h>
> >>  
> >>  #include <linux/of.h>
> >>  #include <linux/perf/arm_pmu.h>
> >> @@ -693,10 +694,15 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
> >>  		return -EPERM;
> >>  	if (attr->exclude_user)
> >>  		config_base |= ARMV8_EXCLUDE_EL0;
> >> -	if (attr->exclude_kernel)
> >> -		config_base |= ARMV8_EXCLUDE_EL1;
> >> -	if (!attr->exclude_hv)
> >> -		config_base |= ARMV8_INCLUDE_EL2;
> >> +	if (is_kernel_in_hyp_mode()) {
> >> +		if (!attr->exclude_kernel || !attr->exclude_hv)
> >> +			config_base |= ARMV8_INCLUDE_EL2;
> > 
> > Hmm, so if userspace sets exclude_kernel but not exclude_user and
> > exclude_hv, what should we do? I'm slightly tempted to reject the
> > filter with -EINVAL...
> 
> I was angling for the minimum level of surprise for the user, but
> I guess that the results are going to be troubling anyway.
> 
> How about something like this on top:
> 
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 6013a38..8c00ed4 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -695,7 +695,10 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
>  	if (attr->exclude_user)
>  		config_base |= ARMV8_EXCLUDE_EL0;
>  	if (is_kernel_in_hyp_mode()) {
> -		if (!attr->exclude_kernel || !attr->exclude_hv)
> +		/* Demand that kernel and hv are consistent */
> +		if (attr->exclude_kernel != attr->exclude_hv)
> +			return -EINVAL;
> +		if (!attr->exclude_hv)
>  			config_base |= ARMV8_INCLUDE_EL2;
>  	} else {
>  		if (attr->exclude_kernel)

Looks like the right idea, and you can probably refactor things slightly
to avoid having two codepaths dealing with ARMV8_INCLUDE_EL2.

Note that I've got a couple of outstanding questions with the architects
that I should have answers to later in the week.

Will


From tj at kernel.org  Mon Feb 15 10:30:41 2016
From: tj at kernel.org (Tejun Heo)
Date: Mon, 15 Feb 2016 13:30:41 -0500
Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <56C147B2.9010303@caviumnetworks.com>
References: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160214170152.GC3965@htj.duckdns.org>
 <56C147B2.9010303@caviumnetworks.com>
Message-ID: <20160215183041.GH3965@htj.duckdns.org>

Hello, Tirumalesh.

On Sun, Feb 14, 2016 at 07:36:18PM -0800, Tirumalesh Chalamarla wrote:
> There is no need for special Driver, AHCI is sufficient for ThunderX, the
> file only contains this interrupt handler,
> is it preferable if this interrupt handler in libahci.c with others, instead
> of separate file?

Yeap, just fold it in ahci.c with surrounding #ifdef guard.

Thanks.

-- 
tejun


From gerald.schaefer at de.ibm.com  Mon Feb 15 10:37:02 2016
From: gerald.schaefer at de.ibm.com (Gerald Schaefer)
Date: Mon, 15 Feb 2016 19:37:02 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe
 also on PowerPC and ARM)
In-Reply-To: <20160215113159.GA28832@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
 <alpine.LFD.2.20.1602131238260.1910@schleppi>
 <20160215113159.GA28832@node.shutemov.name>
Message-ID: <20160215193702.4a15ed5e@thinkpad>

On Mon, 15 Feb 2016 13:31:59 +0200
"Kirill A. Shutemov" <kirill at shutemov.name> wrote:

> On Sat, Feb 13, 2016 at 12:58:31PM +0100, Sebastian Ott wrote:
> > 
> > On Sat, 13 Feb 2016, Kirill A. Shutemov wrote:
> > > Could you check if revert of fecffad25458 helps?
> > 
> > I reverted fecffad25458 on top of 721675fcf277cf - it oopsed with:
> > 
> > ? 1851.721062! Unable to handle kernel pointer dereference in virtual kernel address space
> > ? 1851.721075! failing address: 0000000000000000 TEID: 0000000000000483
> > ? 1851.721078! Fault in home space mode while using kernel ASCE.
> > ? 1851.721085! AS:0000000000d5c007 R3:00000000ffff0007 S:00000000ffffa800 P:000000000000003d
> > ? 1851.721128! Oops: 0004 ilc:3 ?#1! PREEMPT SMP DEBUG_PAGEALLOC
> > ? 1851.721135! Modules linked in: bridge stp llc btrfs mlx4_ib mlx4_en ib_sa ib_mad vxlan xor ip6_udp_tunnel ib_core udp_tunnel ptp pps_core ib_addr ghash_s390raid6_pq prng ecb aes_s390 mlx4_core des_s390 des_generic genwqe_card sha512_s390 sha256_s390 sha1_s390 sha_common crc_itu_t dm_mod scm_block vhost_net tun vhost eadm_sch macvtap macvlan kvm autofs4
> > ? 1851.721183! CPU: 7 PID: 256422 Comm: bash Not tainted 4.5.0-rc3-00058-g07923d7-dirty #178
> > ? 1851.721186! task: 000000007fbfd290 ti: 000000008c604000 task.ti: 000000008c604000
> > ? 1851.721189! Krnl PSW : 0704d00180000000 000000000045d3b8 (__rb_erase_color+0x280/0x308)
> > ? 1851.721200!            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
> >                Krnl GPRS: 0000000000000001 0000000000000020 0000000000000000 00000000bd07eff1
> > ? 1851.721205!            000000000027ca10 0000000000000000 0000000083e45898 0000000077b61198
> > ? 1851.721207!            000000007ce1a490 00000000bd07eff0 000000007ce1a548 000000000027ca10
> > ? 1851.721210!            00000000bd07c350 00000000bd07eff0 000000008c607aa8 000000008c607a68
> > ? 1851.721221! Krnl Code: 000000000045d3aa: e3c0d0080024       stg     %%r12,8(%%r13)
> >                           000000000045d3b0: b9040039           lgr     %%r3,%%r9
> >                          #000000000045d3b4: a53b0001           oill    %%r3,1
> >                          >000000000045d3b8: e33010000024       stg     %%r3,0(%%r1)
> >                           000000000045d3be: ec28000e007c       cgij    %%r2,0,8,45d3da
> >                           000000000045d3c4: e34020000004       lg      %%r4,0(%%r2)
> >                           000000000045d3ca: b904001c           lgr     %%r1,%%r12
> >                           000000000045d3ce: ec143f3f0056       rosbg   %%r1,%%r4,63,63,0
> > ? 1851.721269! Call Trace:
> > ? 1851.721273! (?<0000000083e45898>! 0x83e45898)
> > ? 1851.721279!  ?<000000000029342a>! unlink_anon_vmas+0x9a/0x1d8
> > ? 1851.721282!  ?<0000000000283f34>! free_pgtables+0xcc/0x148
> > ? 1851.721285!  ?<000000000028c376>! exit_mmap+0xd6/0x300
> > ? 1851.721289!  ?<0000000000134db8>! mmput+0x90/0x118
> > ? 1851.721294!  ?<00000000002d76bc>! flush_old_exec+0x5d4/0x700
> > ? 1851.721298!  ?<00000000003369f4>! load_elf_binary+0x2f4/0x13e8
> > ? 1851.721301!  ?<00000000002d6e4a>! search_binary_handler+0x9a/0x1f8
> > ? 1851.721304!  ?<00000000002d8970>! do_execveat_common.isra.32+0x668/0x9a0
> > ? 1851.721307!  ?<00000000002d8cec>! do_execve+0x44/0x58
> > ? 1851.721310!  ?<00000000002d8f92>! SyS_execve+0x3a/0x48
> > ? 1851.721315!  ?<00000000006fb096>! system_call+0xd6/0x258
> > ? 1851.721317!  ?<000003ff997436d6>! 0x3ff997436d6
> > ? 1851.721319! INFO: lockdep is turned off.
> > ? 1851.721321! Last Breaking-Event-Address:
> > ? 1851.721323!  ?<000000000045d31a>! __rb_erase_color+0x1e2/0x308
> > ? 1851.721327!
> > ? 1851.721329! ---? end trace 0d80041ac00cfae2 !---
> > 
> > 
> > > 
> > > And could you share how crashes looks like? I haven't seen backtraces yet.
> > > 
> > 
> > Sure. I didn't because they really looked random to me. Most of the time
> > in rcu or list debugging but I thought these have just been the messenger
> > observing a corruption first. Anyhow, here is an older one that might look
> > interesting:
> > 
> > [   59.851421] list_del corruption. next->prev should be 000000006e1eb000, but was 0000000000000400
> 
> This kinda interesting: 0x400 is TAIL_MAPPING.. Hm..
> 
> Could you check if you see the problem on commit 1c290f642101 and its
> immediate parent?
> 

How should the page->mapping poison end up as next->prev in the list of
pre-allocated THP splitting page tables? Also, commit 1c290f642101
is before the THP rework, at least the non-bisectable part, so we should
expect not to see the problem there.

0x400 is also the value of an empty pte on s390, and the thp_deposit/withdraw
listheads are placed inside the pre-allocated pagetables instead of page->lru,
because we have 2K pagetables on s390 and cannot use struct page == pgtable_t.

So, for example, two concurrent withdraws could produce such a list
corruption, because the first withdraw will overwrite the listhead at the
beginning of the pagetable with 2 empty ptes.

Has anything changed regarding the general THP deposit/withdraw logic?



From punit.agrawal at arm.com  Mon Feb 15 10:36:04 2016
From: punit.agrawal at arm.com (Punit Agrawal)
Date: Mon, 15 Feb 2016 18:36:04 +0000
Subject: [PATCH 1/2] firmware: arm_scpi: add support for 64-bit sensor
 values
In-Reply-To: <1455028377-12728-1-git-send-email-sudeep.holla@arm.com> (Sudeep
 Holla's message of "Tue, 9 Feb 2016 14:32:56 +0000")
References: <1455028377-12728-1-git-send-email-sudeep.holla@arm.com>
Message-ID: <87a8n1akiz.fsf@e105922-lin.cambridge.arm.com>

Sudeep Holla <sudeep.holla at arm.com> writes:

> SCPI specification version 1.1 extended the sensor from 32-bit to 64-bit
> values in order to accommodate new sensor class with 64-bit requirements
>
> Since the SCPI driver sets the higher 32-bit for older protocol version
> to zeros, there's no need to explicitly check the SCPI protocol version
> and the backward compatibility is maintainted.
>
> Cc: Punit Agrawal <punit.agrawal at arm.com>

Thanks for the update to the driver.

       Reviewed-by: Punit Agrawal <punit.agrawal at arm.com>

> Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
> ---
>  drivers/firmware/arm_scpi.c   | 8 +++++---
>  drivers/hwmon/scpi-hwmon.c    | 6 +++---
>  include/linux/scpi_protocol.h | 2 +-
>  3 files changed, 9 insertions(+), 7 deletions(-)
>
> Hi Guenter,
>
> Since I have couple of other fixes for SCPI driver, if you can provide
> your ACKs to this couple of patches after your review, I can take all of
> them together via ARM-SoC if that's fine with you.
>
> Regards,
> Sudeep
>

[...]



From punit.agrawal at arm.com  Mon Feb 15 10:38:18 2016
From: punit.agrawal at arm.com (Punit Agrawal)
Date: Mon, 15 Feb 2016 18:38:18 +0000
Subject: [PATCH 2/2] hwmon: (scpi) add energy meter support
In-Reply-To: <1455028377-12728-2-git-send-email-sudeep.holla@arm.com> (Sudeep
 Holla's message of "Tue, 9 Feb 2016 14:32:57 +0000")
References: <1455028377-12728-1-git-send-email-sudeep.holla@arm.com>
 <1455028377-12728-2-git-send-email-sudeep.holla@arm.com>
Message-ID: <8760xpakf9.fsf@e105922-lin.cambridge.arm.com>

Sudeep Holla <sudeep.holla at arm.com> writes:

> SCPI specification v1.1 adds support for energy sensors. This patch
> adds support for the same.
>
> Cc: Punit Agrawal <punit.agrawal at arm.com>

  Reviewed-by: Punit Agrawal <punit.agrawal at arm.com>

> Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
> ---
>  drivers/hwmon/scpi-hwmon.c    | 8 ++++++++
>  include/linux/scpi_protocol.h | 1 +
>  2 files changed, 9 insertions(+)
>

[...]



From sudeep.holla at arm.com  Mon Feb 15 10:39:53 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Mon, 15 Feb 2016 18:39:53 +0000
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <56C21518.5030606@roeck-us.net>
References: <20160214165010.GA3189@roeck-us.net>
 <20160215105909.GH12289@pengutronix.de> <56C1F19F.8090100@roeck-us.net>
 <20160215170025.GJ12289@pengutronix.de> <56C21518.5030606@roeck-us.net>
Message-ID: <56C21B79.8000408@arm.com>



On 15/02/16 18:12, Guenter Roeck wrote:

[...]

>
> I added some debugging on top of your patch, and get:
>
> platform basic-mmio-gpio.1.auto: Device node exists
> [/smb/motherboard/iofpga at 7,00000000/sysreg at 00000/sys_led at 08],
> of_driver_match_device() failed
> platform basic-mmio-gpio.1.auto: platform_match_id() succeeded
> platform basic-mmio-gpio.2.auto: Device node exists
> [/smb/motherboard/iofpga at 7,00000000/sysreg at 00000/sys_mci at 48],
> of_driver_match_device() failed
> platform basic-mmio-gpio.2.auto: platform_match_id() succeeded
> platform basic-mmio-gpio.3.auto: Device node exists
> [/smb/motherboard/iofpga at 7,00000000/sysreg at 00000/sys_flash at 4c],
> of_driver_match_device() failed
> platform basic-mmio-gpio.3.auto: platform_match_id() succeeded
>
> So it isn't the mmc driver failing to instantiate directly,
> but (I think) vexpress-sysreg.
>

That's correct, I could reproduce this issue and reported with similar
analysis earlier [1]

--
Regards,
Sudeep

[1] http://www.spinics.net/lists/arm-kernel/msg483107.html


From rafael at kernel.org  Mon Feb 15 10:41:21 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 15 Feb 2016 19:41:21 +0100
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <20160215170527.GA24453@roeck-us.net>
References: <20160215170527.GA24453@roeck-us.net>
Message-ID: <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>

On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck <linux at roeck-us.net> wrote:
> Rafael,

Hi,

Thanks for the report!

> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
> timers with utilization update callbacks' with next-20160215. An example
> crash log and bisect results are attached below.
>
> Please let me know if there is anything I can do to help tracking down
> the problem.

It looks like we've uncovered some nastiness in the arch ARM code (see below).

[cut]

> [    1.340000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [    1.340000] pgd = c0204000
> [    1.340000] [00000000] *pgd=00000000
> [    1.340000] Internal error: Oops: 80000005 [#1] SMP ARM
> [    1.340000] Modules linked in:
> [    1.340000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4-next-20160215 #1
> [    1.340000] Hardware name: Generic OMAP3-GP (Flattened Device Tree)
> [    1.340000] task: cb060000 ti: cb05a000 task.ti: cb05a000
> [    1.340000] PC is at 0x0
> [    1.340000] LR is at arch_send_call_function_single_ipi+0x34/0x38

Since this is ARM, arch_send_call_function_single_ipi() looks like this:

void arch_send_call_function_single_ipi(int cpu)
{
         smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
}

so I'm not sure how the NULL pointer deref is possible even.

The only thing coming to mind would be that cpumask_of(cpu) triggers
this, but I'm not sure how exactly that can happen.

I need help from somebody who knows how this low-level stuff works on ARM.

> [    1.340000] pc : [<00000000>]    lr : [<c030de78>]    psr: 20000193
> [    1.340000] sp : cb05b7c0  ip : 00000000  fp : cb05b83c
> [    1.340000] r10: cfb8c0c0  r9 : 00000000  r8 : cb18a4c0
> [    1.340000] r7 : 00000005  r6 : 00000005  r5 : cb5c0334  r4 : 00000000
> [    1.340000] r3 : 00000000  r2 : c0c06a7c  r1 : 00000003  r0 : c0c06a7c
> [    1.340000] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
> [    1.340000] Control: 10c5387d  Table: 80204059  DAC: 00000051
> [    1.340000] Process swapper/0 (pid: 1, stack limit = 0xcb05a220)
> [    1.340000] Stack: (0xcb05b7c0 to 0xcb05c000)
> [    1.340000] b7c0: 00000000 c03b3350 4fdec700 00000000 00000005 c0959a84 ffffffff 00000000
> [    1.340000] b7e0: ffffffff cb18a4c0 cfb8c0c0 c03732d8 4c4b4000 cb18a4c0 cfb8c0c0 cfb8c0c0
> [    1.340000] b800: 0e979000 cb18a4c0 cfb8c0c0 00000005 0e979000 c12130c0 00000000 cfb8c0c0
> [    1.340000] b820: cb05b83c c0360d28 00000000 cb18a4c0 cfb8c0c0 60000193 cb05b84c c0360fc0
> [    1.340000] b840: cb18a4c0 cb18a8b4 cb05b87c c0361b74 cfb8c100 00000141 cb05b934 cb1c1cc0
> [    1.340000] b860: 00000002 00000000 00000000 00000048 c1416d0c cb0096c0 00000001 c0381de0
> [    1.340000] b880: c1416080 cfb8c100 00000400 cb0096c0 cb009720 00000000 00000038 cb003000
> [    1.340000] b8a0: 00000000 cb05b9c4 00000a28 c0381ea4 cb0096c0 cb0096d0 00000000 c0385150
> [    1.340000] b8c0: c03850ac c1211518 00000000 c038168c 00000155 c0381788 c0932830 20000013
> [    1.340000] b8e0: ffffffff cb05b924 00000000 c030bad4 00000001 00000009 00000002 fa070024
> [    1.340000] b900: cb127c10 00009401 cb05b9b8 c1302100 00000000 00000000 cb05b9c4 00000a28
> [    1.340000] b920: 00000000 cb05b940 00009601 c0932830 20000013 ffffffff 00000051 c093261c
> [    1.340000] b940: 00000014 cb127c58 00000002 00000001 000f4240 cb127c10 1443fd00 00000001
> [    1.340000] b960: c1302100 cb127c58 cb05b9b8 00000002 c145d438 ffff16ac 00000001 c0928358
> [    1.340000] b980: cb127c74 cb127c58 00000002 cb05b9b8 cb05ba97 00000001 cb05ba97 00000001
> [    1.340000] b9a0: 00000001 c0928538 00000000 cb518000 cb513740 c07726c4 0000004b cfb80001
> [    1.340000] b9c0: cb513740 0001004b 017d0001 cb05ba97 00000000 c076dc30 00000001 00000000
> [    1.340000] b9e0: 00000004 000000b9 000000ba cb518000 000000ba 000000b9 00000001 c076dd70
> [    1.340000] ba00: 00000000 00000000 cfb8c100 cb518000 000000ba 00000001 00000001 cb05ba97
> [    1.340000] ba20: 00000001 000000b9 00000000 c076dfcc c099a208 cb59d048 00000001 c1336dd0
> [    1.340000] ba40: a0000113 00000000 00000001 cb05ba97 0000005e 00000004 00000001 00000000
> [    1.340000] ba60: 00000000 000ee098 000ee098 c077fd34 0000000d c09e51f0 c09e51d0 cb51f400
> [    1.340000] ba80: ffffffff 000ee098 000ee098 c068cb48 00000000 c09c157c cb019180 c067887c
> [    1.340000] baa0: cb51f400 c067a700 000ee098 c09c160c cb015780 00000000 3b9aca00 cb5bdcc0
> [    1.340000] bac0: cb51f400 00000000 00000000 00000000 000ee098 c067ab5c 000ee098 000ee098
> [    1.340000] bae0: cb5bdcc0 000ee098 000ee098 000ee098 cfb87050 00000000 000ee098 c067c614
> [    1.340000] bb00: cb5bdcc0 000ee098 000ee098 c0765ad4 1dcd6500 cb5bdc80 00000000 07735940
> [    1.340000] bb20: cb5bdc80 cfb87050 cb5bdcc0 00000000 000ee098 c076660c 000ee098 cb5c11d0
> [    1.340000] bb40: cb05bb90 00124f80 00124f80 00124f80 07735940 1dcd6500 ffffffff cb5c1100
> [    1.340000] bb60: 00000000 00000000 c145dc8c cb5c0280 00000000 00000001 cb05bb90 c0958e78
> [    1.340000] bb80: cb05bb8c c13cb404 00000000 00000000 00000010 0007a120 0001e848 00000021
> [    1.340000] bba0: ffffffff ee222d90 00000000 00000000 00000000 00000010 cfb8b598 c13cb310
> [    1.340000] bbc0: c1302578 c095ca58 c1302578 00000000 cb5c1100 00000000 000927c0 cb5bdfc0
> [    1.340000] bbe0: c120e300 00000000 ee32cf60 00000000 c13cb310 cb5c1100 00000000 cb5c0304
> [    1.340000] bc00: 00000010 c145dc8c c1302578 cb5c11b4 cb5c1108 c095cd04 c145dc8c 00000001
> [    1.340000] bc20: cb5c1100 cb5c1100 00000000 c145dc8c c1302578 00000003 cb5c1100 00000000
> [    1.340000] bc40: 00000010 c145dc8c c1302578 cb5c11b4 cb5c1108 c0959c5c cb5c1100 00000000
> [    1.340000] bc60: 00000000 c095a2dc c0c0df58 00000001 0000ffff 00000001 00000000 00000000
> [    1.340000] bc80: cb5bdc00 000927c0 0001e848 000493e0 0001e848 000927c0 0007a120 00000000
> [    1.340000] bca0: 00000000 00000000 00000000 c13cb310 00000000 00000000 00000000 00000000
> [    1.340000] bcc0: 00000000 00000000 ffffffe0 cb5c1160 cb5c1160 c095abf4 0001e848 000927c0
> [    1.340000] bce0: cb5c0280 c13cb0a8 c13cb0a8 cb5bdf00 cb5c1184 cb5c1184 cb11e600 00000000
> [    1.340000] bd00: c13cb128 cb5bf460 00000001 00000003 00000000 00000000 cb5c11ac cb5c11ac
> [    1.340000] bd20: ffff0001 cb5c11b8 cb5c11b8 00000000 00000000 cb060000 00000000 00000000
> [    1.340000] bd40: 00000000 cb5c11d8 cb5c11d8 00000000 cb5bdf80 cb5bdec0 cb5c1100 c095a5f0
> [    1.340000] bd60: 00000000 cb11e600 00000000 c1212594 60000013 00000001 00000000 c13cb110
> [    1.340000] bd80: c13acc68 c13cb0a8 c13cb440 c13cb440 00000000 00000000 00000000 c075674c
> [    1.340000] bda0: c13cb440 cb00cc5c cb169db4 00000000 c1334248 c13cb488 c145dc8c c0959764
> [    1.340000] bdc0: ffffffed cfb87050 cb5e2600 c095d670 ffffffed cb5e2610 fffffdfb c0758e48
> [    1.340000] bde0: c0758df8 cb5e2610 c1459090 c1459098 00000000 c07577b0 00000000 00000000
> [    1.340000] be00: cb05be30 c0757a68 00000001 c145906c 00000000 c0755d3c cb00cb70 cb5938b8
> [    1.340000] be20: cb5e2610 cb5e2644 c13aca58 c0757534 cb5e2610 00000001 00000000 cb5e2610
> [    1.340000] be40: cb5e2610 c13aca58 c13acaa8 c0756bc0 cb5e2610 00000000 cb5e2618 c07550c0
> [    1.340000] be60: 00000000 c0587884 cb05beb8 cb5e2600 00000000 cb5e2600 cb5e2610 c1419000
> [    1.340000] be80: c110362c c11a183c 00000000 c0758fdc 00000000 cb05beb8 cb5e2600 cb5bdb00
> [    1.340000] bea0: c1419000 c07597a8 c0ead2ac c1306788 c1306788 c1112510 00000000 00000000
> [    1.340000] bec0: c0ead2ac 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [    1.340000] bee0: 00000000 00000000 00000000 c110f828 c110fabc c110fac4 c110fabc c1103648
> [    1.340000] bf00: c1306788 c0301d28 0000006f cb05bf28 c035a8bc c035a8cc 60000013 ffffffff
> [    1.340000] bf20: 00000051 c058b428 c0ff5b24 c0c1da88 0000011a c035ab48 c11a183c c0ea7034
> [    1.340000] bf40: c0ff451c 00000000 00000007 00000007 c1335704 cfb96300 c120de7c 00000007
> [    1.340000] bf60: c11a1834 c1419000 0000011a c11a183c c1100598 c1100dc4 00000007 00000007
> [    1.340000] bf80: 00000000 c1100598 00000000 c0b0bcfc 00000000 00000000 00000000 00000000
> [    1.340000] bfa0: 00000000 c0b0bd04 00000000 c0307e78 00000000 00000000 00000000 00000000
> [    1.340000] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [    1.340000] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [    1.340000] [<c030de78>] (arch_send_call_function_single_ipi) from [<c03b3350>] (irq_work_queue_on+0x90/0x100)
> [    1.340000] [<c03b3350>] (irq_work_queue_on) from [<c0959a84>] (cpufreq_update_util+0x40/0x4c)
> [    1.340000] [<c0959a84>] (cpufreq_update_util) from [<c03732d8>] (enqueue_task_rt+0x28/0x26c)
> [    1.340000] [<c03732d8>] (enqueue_task_rt) from [<c0360d28>] (activate_task+0x60/0x64)
> [    1.340000] [<c0360d28>] (activate_task) from [<c0360fc0>] (ttwu_do_activate.constprop.13+0x34/0x68)
> [    1.340000] [<c0360fc0>] (ttwu_do_activate.constprop.13) from [<c0361b74>] (try_to_wake_up+0x1a0/0x318)
> [    1.340000] [<c0361b74>] (try_to_wake_up) from [<c0381de0>] (handle_irq_event_percpu+0xdc/0x15c)
> [    1.340000] [<c0381de0>] (handle_irq_event_percpu) from [<c0381ea4>] (handle_irq_event+0x44/0x68)
> [    1.340000] [<c0381ea4>] (handle_irq_event) from [<c0385150>] (handle_level_irq+0xa4/0x13c)
> [    1.340000] [<c0385150>] (handle_level_irq) from [<c038168c>] (generic_handle_irq+0x18/0x28)
> [    1.340000] [<c038168c>] (generic_handle_irq) from [<c0381788>] (__handle_domain_irq+0x54/0xb0)
> [    1.340000] [<c0381788>] (__handle_domain_irq) from [<c030bad4>] (__irq_svc+0x54/0x70)
> [    1.340000] [<c030bad4>] (__irq_svc) from [<c0932830>] (omap_i2c_xfer+0x320/0x5a0)

It looks like we got an interrupt in the middle of an i2c transaction
changing the CPU OPP.  The handler of that tried to enqueue an RT task
and that led to a cpufreq update that in turn triggered the crash.

That's during cpufreq_online(), so it looks like something might not
be set up entirely somewhere.

> [    1.340000] [<c0932830>] (omap_i2c_xfer) from [<c0928358>] (__i2c_transfer+0x140/0x29c)
> [    1.340000] [<c0928358>] (__i2c_transfer) from [<c0928538>] (i2c_transfer+0x84/0xd4)
> [    1.340000] [<c0928538>] (i2c_transfer) from [<c07726c4>] (regmap_i2c_read+0x48/0x64)
> [    1.340000] [<c07726c4>] (regmap_i2c_read) from [<c076dc30>] (_regmap_raw_read+0xa4/0x110)
> [    1.340000] [<c076dc30>] (_regmap_raw_read) from [<c076dd70>] (regmap_raw_read+0xd4/0x170)
> [    1.340000] [<c076dd70>] (regmap_raw_read) from [<c076dfcc>] (regmap_bulk_read+0x1c0/0x2b0)
> [    1.340000] [<c076dfcc>] (regmap_bulk_read) from [<c077fd34>] (twl_i2c_read+0x48/0x8c)
> [    1.340000] [<c077fd34>] (twl_i2c_read) from [<c068cb48>] (twl4030smps_get_voltage+0x44/0x60)
> [    1.340000] [<c068cb48>] (twl4030smps_get_voltage) from [<c067887c>] (_regulator_get_voltage+0x68/0xb8)
> [    1.340000] [<c067887c>] (_regulator_get_voltage) from [<c067a700>] (_regulator_do_set_voltage+0x48/0x320)
> [    1.340000] [<c067a700>] (_regulator_do_set_voltage) from [<c067ab5c>] (regulator_set_voltage_unlocked+0xcc/0x220)
> [    1.340000] [<c067ab5c>] (regulator_set_voltage_unlocked) from [<c067c614>] (regulator_set_voltage+0x28/0x54)
> [    1.340000] [<c067c614>] (regulator_set_voltage) from [<c0765ad4>] (_set_opp_voltage+0x34/0x90)
> [    1.340000] [<c0765ad4>] (_set_opp_voltage) from [<c076660c>] (dev_pm_opp_set_rate+0x19c/0x288)
> [    1.340000] [<c076660c>] (dev_pm_opp_set_rate) from [<c0958e78>] (__cpufreq_driver_target+0x180/0x2a0)
> [    1.340000] [<c0958e78>] (__cpufreq_driver_target) from [<c095ca58>] (dbs_check_cpu+0x1ac/0x1e8)
> [    1.340000] [<c095ca58>] (dbs_check_cpu) from [<c095cd04>] (cpufreq_governor_dbs+0x1fc/0x608)
> [    1.340000] [<c095cd04>] (cpufreq_governor_dbs) from [<c0959c5c>] (__cpufreq_governor+0x1a8/0x204)
> [    1.340000] [<c0959c5c>] (__cpufreq_governor) from [<c095a2dc>] (cpufreq_init_policy+0x60/0x8c)
> [    1.340000] [<c095a2dc>] (cpufreq_init_policy) from [<c095a5f0>] (cpufreq_online+0x2e8/0x708)
> [    1.340000] [<c095a5f0>] (cpufreq_online) from [<c075674c>] (subsys_interface_register+0x80/0xc4)
> [    1.340000] [<c075674c>] (subsys_interface_register) from [<c0959764>] (cpufreq_register_driver+0x144/0x1a0)

This is the registration of the cpufreq driver (cpufreq-dt in this case).

It does cpufreq_online()->cpufreq_init_policy()->__cpufreq_governor()->cpufreq_governor_dbs()->dbs_check_cpu().

The only way that can happen is when cpufreq_set_policy() finds that
the "old" and the "new" policies use the same governor, so it goes and
calls __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS), but I'm not sure
how this is possible during the initialization ATM.

Viresh, any ideas?

> [    1.340000] [<c0959764>] (cpufreq_register_driver) from [<c095d670>] (dt_cpufreq_probe+0x64/0xe8)
> [    1.340000] [<c095d670>] (dt_cpufreq_probe) from [<c0758e48>] (platform_drv_probe+0x50/0xb0)
> [    1.340000] [<c0758e48>] (platform_drv_probe) from [<c07577b0>] (driver_probe_device+0x1f4/0x2b0)
> [    1.340000] [<c07577b0>] (driver_probe_device) from [<c0755d3c>] (bus_for_each_drv+0x44/0x8c)
> [    1.340000] [<c0755d3c>] (bus_for_each_drv) from [<c0757534>] (__device_attach+0x9c/0x100)
> [    1.340000] [<c0757534>] (__device_attach) from [<c0756bc0>] (bus_probe_device+0x84/0x8c)
> [    1.340000] [<c0756bc0>] (bus_probe_device) from [<c07550c0>] (device_add+0x33c/0x528)
> [    1.340000] [<c07550c0>] (device_add) from [<c0758fdc>] (platform_device_add+0xa8/0x20c)
> [    1.340000] [<c0758fdc>] (platform_device_add) from [<c07597a8>] (platform_device_register_full+0xe0/0x108)
> [    1.340000] [<c07597a8>] (platform_device_register_full) from [<c1112510>] (omap2_common_pm_late_init+0xc8/0x10c)
> [    1.340000] [<c1112510>] (omap2_common_pm_late_init) from [<c110f828>] (omap_common_late_init+0xc/0x14)
> [    1.340000] [<c110f828>] (omap_common_late_init) from [<c110fac4>] (omap3_init_late+0x8/0x14)
> [    1.340000] [<c110fac4>] (omap3_init_late) from [<c1103648>] (init_machine_late+0x1c/0x90)
> [    1.340000] [<c1103648>] (init_machine_late) from [<c0301d28>] (do_one_initcall+0x84/0x1d4)
> [    1.340000] [<c0301d28>] (do_one_initcall) from [<c1100dc4>] (kernel_init_freeable+0x120/0x1ec)
> [    1.340000] [<c1100dc4>] (kernel_init_freeable) from [<c0b0bd04>] (kernel_init+0x8/0xec)
> [    1.340000] [<c0b0bd04>] (kernel_init) from [<c0307e78>] (ret_from_fork+0x14/0x3c)
> [    1.340000] Code: bad PC value
> [    1.340000] ---[ end trace 384223760a5ee799 ]---
> [    1.340000] Kernel panic - not syncing: Fatal exception in interrupt
> [    1.340000] ---[ end Kernel panic - not syncing: Fatal exception in interrupt


From rafael at kernel.org  Mon Feb 15 10:49:00 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 15 Feb 2016 19:49:00 +0100
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
Message-ID: <CAJZ5v0hcNEThqdWAO8FGfvGnAMydHxOQs+s84aCLcqn=BwXbjA@mail.gmail.com>

On Mon, Feb 15, 2016 at 7:41 PM, Rafael J. Wysocki <rafael at kernel.org> wrote:
> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck <linux at roeck-us.net> wrote:
>> Rafael,
>
> Hi,
>
> Thanks for the report!
>
>> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
>> timers with utilization update callbacks' with next-20160215. An example
>> crash log and bisect results are attached below.
>>
>> Please let me know if there is anything I can do to help tracking down
>> the problem.
>
> It looks like we've uncovered some nastiness in the arch ARM code (see below).
>
> [cut]
>
>> [    1.340000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> [    1.340000] pgd = c0204000
>> [    1.340000] [00000000] *pgd=00000000
>> [    1.340000] Internal error: Oops: 80000005 [#1] SMP ARM
>> [    1.340000] Modules linked in:
>> [    1.340000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4-next-20160215 #1
>> [    1.340000] Hardware name: Generic OMAP3-GP (Flattened Device Tree)
>> [    1.340000] task: cb060000 ti: cb05a000 task.ti: cb05a000
>> [    1.340000] PC is at 0x0
>> [    1.340000] LR is at arch_send_call_function_single_ipi+0x34/0x38
>
> Since this is ARM, arch_send_call_function_single_ipi() looks like this:
>
> void arch_send_call_function_single_ipi(int cpu)
> {
>          smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
> }
>
> so I'm not sure how the NULL pointer deref is possible even.
>
> The only thing coming to mind would be that cpumask_of(cpu) triggers
> this, but I'm not sure how exactly that can happen.
>
> I need help from somebody who knows how this low-level stuff works on ARM.

Well, could there be a problem with sending an IPI to the same CPU
that's sending it?


From marc.zyngier at arm.com  Mon Feb 15 10:49:52 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Feb 2016 18:49:52 +0000
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
Message-ID: <56C21DD0.40508@arm.com>

On 15/02/16 18:41, Rafael J. Wysocki wrote:
> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck <linux at roeck-us.net> wrote:
>> Rafael,
> 
> Hi,
> 
> Thanks for the report!
> 
>> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
>> timers with utilization update callbacks' with next-20160215. An example
>> crash log and bisect results are attached below.
>>
>> Please let me know if there is anything I can do to help tracking down
>> the problem.
> 
> It looks like we've uncovered some nastiness in the arch ARM code (see below).
> 
> [cut]
> 
>> [    1.340000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> [    1.340000] pgd = c0204000
>> [    1.340000] [00000000] *pgd=00000000
>> [    1.340000] Internal error: Oops: 80000005 [#1] SMP ARM
>> [    1.340000] Modules linked in:
>> [    1.340000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4-next-20160215 #1
>> [    1.340000] Hardware name: Generic OMAP3-GP (Flattened Device Tree)
>> [    1.340000] task: cb060000 ti: cb05a000 task.ti: cb05a000
>> [    1.340000] PC is at 0x0
>> [    1.340000] LR is at arch_send_call_function_single_ipi+0x34/0x38
> 
> Since this is ARM, arch_send_call_function_single_ipi() looks like this:
> 
> void arch_send_call_function_single_ipi(int cpu)
> {
>          smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
> }
> 
> so I'm not sure how the NULL pointer deref is possible even.
> 
> The only thing coming to mind would be that cpumask_of(cpu) triggers
> this, but I'm not sure how exactly that can happen.
> 
> I need help from somebody who knows how this low-level stuff works on ARM.

Given that OMAP3 is a UP system, there is zero chance that it has
registered the magic hook that delivers IPIs (its interrupt controller
is not even capable of doing so).

I don't really know the context, but IPIs on a UP system seem at best odd.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From dirk.behme at gmail.com  Mon Feb 15 10:53:36 2016
From: dirk.behme at gmail.com (Dirk Behme)
Date: Mon, 15 Feb 2016 19:53:36 +0100
Subject: ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8]
 arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)
In-Reply-To: <56C1AE88.9050708@arm.com>
References: <CAMuHMdU-q++XEgthKG=XOgnaq7TY899EsgMFHuWu4Skr5woLZg@mail.gmail.com>
 <56C19044.6050604@arm.com>
 <CAMuHMdVcnbp8YMq9oNurvfe_9iNGOHYUVW=_=DzHY62Y0DLnQg@mail.gmail.com>
 <56C1AE88.9050708@arm.com>
Message-ID: <56C21EB0.3010103@gmail.com>

On 15.02.2016 11:55, Marc Zyngier wrote:
> On 15/02/16 10:35, Geert Uytterhoeven wrote:
>> Hi Marc,
>>
>> On Mon, Feb 15, 2016 at 9:45 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>> On 15/02/16 08:16, Geert Uytterhoeven wrote:
>>>> On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>>>>> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland <mark.rutland at arm.com> wrote:
>>>>>> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
>>>>>>> On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland <mark.rutland at arm.com> wrote:
>>>>>>>>>> +           gic: interrupt-controller at 0xf1010000 {
>>>>>>>>> +                     compatible = "arm,gic-400";
>>>>>>>>> +                     #interrupt-cells = <3>;
>>>>>>>>> +                     #address-cells = <0>;
>>>>>>>>> +                     interrupt-controller;
>>>>>>>>> +                     reg = <0x0 0xf1010000 0 0x1000>,
>>>>>>>>> +                           <0x0 0xf1020000 0 0x2000>;
>>>>>>>>> +                     interrupts = <GIC_PPI 9
>>>>>>>>> +                                     (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
>>>>>>>>> +             };
>>>>>>>>
>>>>>>>> No GICH and GICV?
>>>>>>>
>>>>>>> These seem to be defined in the "arm,gic-v3" DT bindings only, while this is
>>>>>>> an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>>>>>>
>>>>>> See the "GIC virtualization extensions (VGIC)" section in
>>>>>> Documentation/devicetree/bindings/arm/gic.txt
>>>>>
>>>>> DDI0471B_gic400_r0p1_trm.pdf says:
>>>>>
>>>>>      Address range GIC-400 functional block
>>>>>      A. 0x0000 - 0x0FFF Reserved
>>>>>      B. 0x1000 - 0x1FFF Distributor
>>>>>      C. 0x2000 - 0x3FFF CPU interfaces
>>>>>      D. 0x4000 - 0x4FFF Virtual interface control block, for the processor that
>>>>>                         is performing the access
>>>>>      E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
>>>>>                         selected by address bits [11:9]
>>>>>      F. 0x6000 - 0x7FFF Virtual CPU interfaces
>>>>>
>>>>> The DT binding document says:
>>>>>    1. The  first region is the GIC distributor register base and size.
>>>>>    2. The 2nd region is the GIC cpu interface register base and size.
>>>>>    3. The first additional region is the GIC virtual interface control register
>>>>>       base and size.
>>>>>    4. The 2nd additional region is the GIC virtual cpu interface register base
>>>>>       and size.
>>>>>
>>>>> Matching with the example:
>>>>>
>>>>>          interrupt-controller at 2c001000 {
>>>>>                  compatible = "arm,cortex-a15-gic";
>>>>>                  #interrupt-cells = <3>;
>>>>>                  interrupt-controller;
>>>>>                  reg = <0x2c001000 0x1000>,
>>>>>                        <0x2c002000 0x1000>,
>>>>>                        <0x2c004000 0x2000>,
>>>>>                        <0x2c006000 0x2000>;
>>>>>                  interrupts = <1 9 0xf04>;
>>>>>          };
>>>>>
>>>>> This means:
>>>>>    - reg entry 1. covers address range B,
>>>>>    - reg entry 2. covers address range C,
>>>>>    - reg entry 3. covers address ranges D _and_ E,
>>>>>    - reg entry 4. covers address range F.
>>>>>
>>>>> On R-Car Gen3, the base addresses are:
>>>>>
>>>>>      Distributor             : 0xF101_0000
>>>>>      CPU interfaces          : 0xF102_0000
>>>>>      Virtual interfaces      : 0xF104_0000
>>>>>      Virtual interfaces      : 0xF105_0000
>>>>>      Virtual CPU interfaces  : 0xF106_0000
>>>>>
>>>>> Note the additional multiplication factor of 16 in the offsets relative to
>>>>> the base address 0xf1000000 (e.g. 0x50000 instead of 0x5000).
>>>>>
>>>>> As address ranges D and E are merged in a single reg entry, how is the GIC
>>>>> driver supposed to know about this multiplication factor?
>>>
>>> The answer is very simple, the GIC driver doesn't give a damn about the
>>> second part of the GICH region, because it is absolutely unusable for
>>> any realistic use-case. Only the banked version of GICH is of any
>>> relevance (the first 512 bytes, in essence).
>>>
>>> Aligning the GIC regions on 64kB boundaries is documented in the SBSA
>>> specification, independently of the GIC400 documentation.
>>
>> If I understand the SBSA spec correctly (BTW, arm,gic.txt doesn't use the
>> "GICC" terminology, unlike arm,gic-v3.txt), that means reg entry 3 should be
>> "<0xf104f000 0x2000>", so it covers the aliased last 4 KiB of address range D,
>> and the first 4 KiB of address range E. I.e.
>>
>>                          reg = <0x0 0xf1010000 0 0x1000>,
>>                               <0x0 0xf1020000 0 0x2000>,
>>                               <0x0 0xf104f000 0 0x2000>,
>>                               <0x0 0xf1060000 0 0x2000>;
>>
>> Is that correct?
>
> My preference would be to expose the full 128kB of the region


That would be

<0x0 0xf1040000 0 0x20000>

then? Ok?

Best regards

Dirk



From rafael at kernel.org  Mon Feb 15 10:54:26 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 15 Feb 2016 19:54:26 +0100
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <56C21DD0.40508@arm.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
 <56C21DD0.40508@arm.com>
Message-ID: <CAJZ5v0gfOVyoWeee5jg7NxLFm-xwdA6-sPQV+cJ=NWJOV-wYzg@mail.gmail.com>

On Mon, Feb 15, 2016 at 7:49 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 15/02/16 18:41, Rafael J. Wysocki wrote:
>> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck <linux at roeck-us.net> wrote:
>>> Rafael,
>>
>> Hi,
>>
>> Thanks for the report!
>>
>>> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
>>> timers with utilization update callbacks' with next-20160215. An example
>>> crash log and bisect results are attached below.
>>>
>>> Please let me know if there is anything I can do to help tracking down
>>> the problem.
>>
>> It looks like we've uncovered some nastiness in the arch ARM code (see below).
>>
>> [cut]
>>
>>> [    1.340000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
>>> [    1.340000] pgd = c0204000
>>> [    1.340000] [00000000] *pgd=00000000
>>> [    1.340000] Internal error: Oops: 80000005 [#1] SMP ARM
>>> [    1.340000] Modules linked in:
>>> [    1.340000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4-next-20160215 #1
>>> [    1.340000] Hardware name: Generic OMAP3-GP (Flattened Device Tree)
>>> [    1.340000] task: cb060000 ti: cb05a000 task.ti: cb05a000
>>> [    1.340000] PC is at 0x0
>>> [    1.340000] LR is at arch_send_call_function_single_ipi+0x34/0x38
>>
>> Since this is ARM, arch_send_call_function_single_ipi() looks like this:
>>
>> void arch_send_call_function_single_ipi(int cpu)
>> {
>>          smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
>> }
>>
>> so I'm not sure how the NULL pointer deref is possible even.
>>
>> The only thing coming to mind would be that cpumask_of(cpu) triggers
>> this, but I'm not sure how exactly that can happen.
>>
>> I need help from somebody who knows how this low-level stuff works on ARM.
>
> Given that OMAP3 is a UP system, there is zero chance that it has
> registered the magic hook that delivers IPIs (its interrupt controller
> is not even capable of doing so).
>
> I don't really know the context, but IPIs on a UP system seem at best odd.

That would explain it, thanks.

So it looks like we should always use irq_work_queue() on UP even if
CONFIG_SMP is set, shouldn't we?

Thanks,
Rafael


From marc.zyngier at arm.com  Mon Feb 15 10:57:06 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Feb 2016 18:57:06 +0000
Subject: ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8]
 arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)
In-Reply-To: <56C21EB0.3010103@gmail.com>
References: <CAMuHMdU-q++XEgthKG=XOgnaq7TY899EsgMFHuWu4Skr5woLZg@mail.gmail.com>
 <56C19044.6050604@arm.com>
 <CAMuHMdVcnbp8YMq9oNurvfe_9iNGOHYUVW=_=DzHY62Y0DLnQg@mail.gmail.com>
 <56C1AE88.9050708@arm.com> <56C21EB0.3010103@gmail.com>
Message-ID: <56C21F82.6070305@arm.com>

On 15/02/16 18:53, Dirk Behme wrote:
> On 15.02.2016 11:55, Marc Zyngier wrote:
>> On 15/02/16 10:35, Geert Uytterhoeven wrote:
>>> Hi Marc,
>>>
>>> On Mon, Feb 15, 2016 at 9:45 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>> On 15/02/16 08:16, Geert Uytterhoeven wrote:
>>>>> On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven <geert at linux-m68k.org> wrote:
>>>>>> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland <mark.rutland at arm.com> wrote:
>>>>>>> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
>>>>>>>> On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland <mark.rutland at arm.com> wrote:
>>>>>>>>>>> +           gic: interrupt-controller at 0xf1010000 {
>>>>>>>>>> +                     compatible = "arm,gic-400";
>>>>>>>>>> +                     #interrupt-cells = <3>;
>>>>>>>>>> +                     #address-cells = <0>;
>>>>>>>>>> +                     interrupt-controller;
>>>>>>>>>> +                     reg = <0x0 0xf1010000 0 0x1000>,
>>>>>>>>>> +                           <0x0 0xf1020000 0 0x2000>;
>>>>>>>>>> +                     interrupts = <GIC_PPI 9
>>>>>>>>>> +                                     (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
>>>>>>>>>> +             };
>>>>>>>>>
>>>>>>>>> No GICH and GICV?
>>>>>>>>
>>>>>>>> These seem to be defined in the "arm,gic-v3" DT bindings only, while this is
>>>>>>>> an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>>>>>>>
>>>>>>> See the "GIC virtualization extensions (VGIC)" section in
>>>>>>> Documentation/devicetree/bindings/arm/gic.txt
>>>>>>
>>>>>> DDI0471B_gic400_r0p1_trm.pdf says:
>>>>>>
>>>>>>      Address range GIC-400 functional block
>>>>>>      A. 0x0000 - 0x0FFF Reserved
>>>>>>      B. 0x1000 - 0x1FFF Distributor
>>>>>>      C. 0x2000 - 0x3FFF CPU interfaces
>>>>>>      D. 0x4000 - 0x4FFF Virtual interface control block, for the processor that
>>>>>>                         is performing the access
>>>>>>      E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
>>>>>>                         selected by address bits [11:9]
>>>>>>      F. 0x6000 - 0x7FFF Virtual CPU interfaces
>>>>>>
>>>>>> The DT binding document says:
>>>>>>    1. The  first region is the GIC distributor register base and size.
>>>>>>    2. The 2nd region is the GIC cpu interface register base and size.
>>>>>>    3. The first additional region is the GIC virtual interface control register
>>>>>>       base and size.
>>>>>>    4. The 2nd additional region is the GIC virtual cpu interface register base
>>>>>>       and size.
>>>>>>
>>>>>> Matching with the example:
>>>>>>
>>>>>>          interrupt-controller at 2c001000 {
>>>>>>                  compatible = "arm,cortex-a15-gic";
>>>>>>                  #interrupt-cells = <3>;
>>>>>>                  interrupt-controller;
>>>>>>                  reg = <0x2c001000 0x1000>,
>>>>>>                        <0x2c002000 0x1000>,
>>>>>>                        <0x2c004000 0x2000>,
>>>>>>                        <0x2c006000 0x2000>;
>>>>>>                  interrupts = <1 9 0xf04>;
>>>>>>          };
>>>>>>
>>>>>> This means:
>>>>>>    - reg entry 1. covers address range B,
>>>>>>    - reg entry 2. covers address range C,
>>>>>>    - reg entry 3. covers address ranges D _and_ E,
>>>>>>    - reg entry 4. covers address range F.
>>>>>>
>>>>>> On R-Car Gen3, the base addresses are:
>>>>>>
>>>>>>      Distributor             : 0xF101_0000
>>>>>>      CPU interfaces          : 0xF102_0000
>>>>>>      Virtual interfaces      : 0xF104_0000
>>>>>>      Virtual interfaces      : 0xF105_0000
>>>>>>      Virtual CPU interfaces  : 0xF106_0000
>>>>>>
>>>>>> Note the additional multiplication factor of 16 in the offsets relative to
>>>>>> the base address 0xf1000000 (e.g. 0x50000 instead of 0x5000).
>>>>>>
>>>>>> As address ranges D and E are merged in a single reg entry, how is the GIC
>>>>>> driver supposed to know about this multiplication factor?
>>>>
>>>> The answer is very simple, the GIC driver doesn't give a damn about the
>>>> second part of the GICH region, because it is absolutely unusable for
>>>> any realistic use-case. Only the banked version of GICH is of any
>>>> relevance (the first 512 bytes, in essence).
>>>>
>>>> Aligning the GIC regions on 64kB boundaries is documented in the SBSA
>>>> specification, independently of the GIC400 documentation.
>>>
>>> If I understand the SBSA spec correctly (BTW, arm,gic.txt doesn't use the
>>> "GICC" terminology, unlike arm,gic-v3.txt), that means reg entry 3 should be
>>> "<0xf104f000 0x2000>", so it covers the aliased last 4 KiB of address range D,
>>> and the first 4 KiB of address range E. I.e.
>>>
>>>                          reg = <0x0 0xf1010000 0 0x1000>,
>>>                               <0x0 0xf1020000 0 0x2000>,
>>>                               <0x0 0xf104f000 0 0x2000>,
>>>                               <0x0 0xf1060000 0 0x2000>;
>>>
>>> Is that correct?
>>
>> My preference would be to expose the full 128kB of the region
> 
> 
> That would be
> 
> <0x0 0xf1040000 0 0x20000>
> 
> then? Ok?

Exactly.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From will.deacon at arm.com  Mon Feb 15 10:58:32 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Feb 2016 18:58:32 +0000
Subject: Writes, smp_wmb(), and transitivity?
In-Reply-To: <20160215175825.GA15878@linux.vnet.ibm.com>
References: <20160215175825.GA15878@linux.vnet.ibm.com>
Message-ID: <20160215185832.GQ6298@arm.com>

On Mon, Feb 15, 2016 at 09:58:25AM -0800, Paul E. McKenney wrote:
> Hello!

Hi Paul,

> Some architectures provide local transitivity for a chain of threads doing
> writes separated by smp_wmb(), as exemplified by the litmus tests below.
> The pattern is that each thread writes to a its own variable, does an
> smp_wmb(), then writes a different value to the next thread's variable.
> 
> I don't know of a use of this, but if everyone supports it, it might
> be good to mandate it.  Status quo is that smp_wmb() is non-transitive,
> so it currently isn't supported.
> 
> Anyone know of any architectures that do -not- support this?
> 
> Assuming all architectures -do- support this, any arguments -against-
> officially supporting it in Linux?
> 
> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> Two threads:
> 
> 	int a, b;
> 
> 	void thread0(void)
> 	{
> 		WRITE_ONCE(a, 1);
> 		smp_wmb();
> 		WRITE_ONCE(b, 2);
> 	}
> 
> 	void thread1(void)
> 	{
> 		WRITE_ONCE(b, 1);
> 		smp_wmb();
> 		WRITE_ONCE(a, 2);
> 	}
> 
> 	/* After all threads have completed and the dust has settled... */
> 
> 	BUG_ON(a == 1 && b == 1);

My understanding is that this test, and the generalisation to n threads,
is forbidden on ARM. However, the transitivity of DMB ST (used to
construct smp_wmb()) has been the subject of long debates, because we
allow the following test:


P0:
Wx = 1

P1:
Rx == 1
DMB ST
Wy = 1

P2:
Ry == 1
<addr dep>
Rx == 0


so I'd be uneasy about saying "it's all transitive".

Will


From shaun.ren at linux.com  Mon Feb 15 10:58:46 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon, 15 Feb 2016 10:58:46 -0800
Subject: [PATCH v5 RESEND 0/8] Staging: rts5208: Fix coding style
In-Reply-To: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
References: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455562734-10863-1-git-send-email-shaun.ren@linux.com>

This set of patches fixes the coding style issues in rtsx_transport.c.

Changes since v4
 * Moved a declaration to the beginning of an if branch

Changes since v3
 * Removed the extraneous SCSI comment in the first patch
 * Removed the last patch (Staging: rts5208: Add missing dma_mapping_error)
   as it is already done in change 9a66d05d82db
   (Staging: rts5208: fix check for dma mapping error)

Changes since v2
 * Incorporated Joshua Clayton's suggestions regarding the block comments


Shaun Ren (8):
  Staging: rts5208: rtsx_transport.c: Cleanup comments
  Staging: rts5208: rtsx_transport.c: Align to open parenthesis
  Staging: rts5208: rtsx_transport.c: Remove spaces after casts
  Staging: rts5208: rtsx_transport.c: Add spaces around -
  Staging: rts5208: rtsx_transport.c: Remove extra newlines
  Staging: rts5208: rtsx_transport.c: Fix label naming convention
  Staging: rts5208: rtsx_transport.c: Remove unnecessary parentheses
  Staging: rts5208: rtsx_transport.c: Fix comparisons to NULL

 drivers/staging/rts5208/rtsx_transport.c | 153 +++++++++++++++++--------------
 1 file changed, 82 insertions(+), 71 deletions(-)

-- 
2.7.1



From shaun.ren at linux.com  Mon Feb 15 10:58:47 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon, 15 Feb 2016 10:58:47 -0800
Subject: [PATCH v5 RESEND 1/8] Staging: rts5208: rtsx_transport.c: Cleanup
 comments
In-Reply-To: <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
References: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
 <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455562734-10863-2-git-send-email-shaun.ren@linux.com>

This patch fixes all multiline comments to conform to the coding style,
which states that multiline comments should start with "/*" and end
with "*/" on a separate line.

Also cleans up some comments to make them more clear and/or reflect what
the code is doing.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
Changes since v3
 * Removed the extraneous SCSI comment in the first patch in
   rtsx_stor_access_xfer_buf()

Changes since v2
 * Cleaned up comments as per Joshua Clayton's suggestions

 drivers/staging/rts5208/rtsx_transport.c | 53 ++++++++++++++++----------------
 1 file changed, 27 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index f2eb18e..91fdccf 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -1,4 +1,5 @@
-/* Driver for Realtek PCI-Express card reader
+/*
+ * Driver for Realtek PCI-Express card reader
  *
  * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
@@ -30,13 +31,15 @@
  * Scatter-gather transfer buffer access routines
  ***********************************************************************/
 
-/* Copy a buffer of length buflen to/from the srb's transfer buffer.
+/*
+ * Copy a buffer of length buflen to/from the srb's transfer buffer.
  * (Note: for scatter-gather transfers (srb->use_sg > 0), srb->request_buffer
  * points to a list of s-g entries and we ignore srb->request_bufflen.
  * For non-scatter-gather transfers, srb->request_buffer points to the
  * transfer buffer itself and srb->request_bufflen is the buffer's length.)
  * Update the *index and *offset variables so that the next copy will
- * pick up from where this one left off. */
+ * pick up from where this one left off.
+ */
 
 unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 	unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
@@ -44,8 +47,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 {
 	unsigned int cnt;
 
-	/* If not using scatter-gather, just transfer the data directly.
-	 * Make certain it will fit in the available buffer space. */
+	/* If not using scatter-gather, just transfer the data directly. */
 	if (scsi_sg_count(srb) == 0) {
 		if (*offset >= scsi_bufflen(srb))
 			return 0;
@@ -58,22 +60,22 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 					*offset, cnt);
 		*offset += cnt;
 
-	/* Using scatter-gather.  We have to go through the list one entry
+	/*
+	 * Using scatter-gather.  We have to go through the list one entry
 	 * at a time.  Each s-g entry contains some number of pages, and
-	 * each page has to be kmap()'ed separately.  If the page is already
-	 * in kernel-addressable memory then kmap() will return its address.
-	 * If the page is not directly accessible -- such as a user buffer
-	 * located in high memory -- then kmap() will map it to a temporary
-	 * position in the kernel's virtual address space. */
+	 * each page has to be kmap()'ed separately.
+	 */
 	} else {
 		struct scatterlist *sg =
 				(struct scatterlist *) scsi_sglist(srb)
 				+ *index;
 
-		/* This loop handles a single s-g list entry, which may
+		/*
+		 * This loop handles a single s-g list entry, which may
 		 * include multiple pages.  Find the initial page structure
 		 * and the starting offset within the page, and update
-		 * the *offset and *index values for the next loop. */
+		 * the *offset and *index values for the next loop.
+		 */
 		cnt = 0;
 		while (cnt < buflen && *index < scsi_sg_count(srb)) {
 			struct page *page = sg_page(sg) +
@@ -95,9 +97,6 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 				++sg;
 			}
 
-			/* Transfer the data for all the pages in this
-			 * s-g entry.  For each page: call kmap(), do the
-			 * transfer, and call kunmap() immediately after. */
 			while (sglen > 0) {
 				unsigned int plen = min(sglen, (unsigned int)
 						PAGE_SIZE - poff);
@@ -122,8 +121,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 	return cnt;
 }
 
-/* Store the contents of buffer into srb's transfer buffer and set the
-* SCSI residue. */
+/*
+ * Store the contents of buffer into srb's transfer buffer and set the
+ * SCSI residue.
+ */
 void rtsx_stor_set_xfer_buf(unsigned char *buffer,
 	unsigned int buflen, struct scsi_cmnd *srb)
 {
@@ -151,7 +152,8 @@ void rtsx_stor_get_xfer_buf(unsigned char *buffer,
  * Transport routines
  ***********************************************************************/
 
-/* Invoke the transport and basic error-handling/recovery methods
+/*
+ * Invoke the transport and basic error-handling/recovery methods
  *
  * This is used to send the message to the device and receive the response.
  */
@@ -161,8 +163,9 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 
 	result = rtsx_scsi_handler(srb, chip);
 
-	/* if the command gets aborted by the higher layers, we need to
-	 * short-circuit all other processing
+	/*
+	 * if the command gets aborted by the higher layers, we need to
+	 * short-circuit all other processing.
 	 */
 	if (rtsx_chk_stat(chip, RTSX_STAT_ABORT)) {
 		dev_dbg(rtsx_dev(chip), "-- command was aborted\n");
@@ -194,9 +197,6 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 
 	return;
 
-	/* Error and abort processing: try to resynchronize with the device
-	 * by issuing a port reset.  If that fails, try a class-specific
-	 * device reset. */
 Handle_Errors:
 	return;
 }
@@ -368,10 +368,11 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
 	resid = size;
 	sg_ptr = sg;
 	chip->sgi = 0;
-	/* Usually the next entry will be @sg@ + 1, but if this sg element
+	/*
+	 * Usually the next entry will be @sg@ + 1, but if this sg element
 	 * is part of a chained scatterlist, it could jump to the start of
 	 * a new scatterlist array. So here we use sg_next to move to
-	 * the proper sg
+	 * the proper sg.
 	 */
 	for (i = 0; i < *index; i++)
 		sg_ptr = sg_next(sg_ptr);
-- 
2.7.1



From shaun.ren at linux.com  Mon Feb 15 10:58:50 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon, 15 Feb 2016 10:58:50 -0800
Subject: [PATCH v5 RESEND 4/8] Staging: rts5208: rtsx_transport.c: Add spaces
 around -
In-Reply-To: <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
References: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
 <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455562734-10863-5-git-send-email-shaun.ren@linux.com>

This patch fixes the following styling issue in rtsx_transport.c
as reported by checkpatch.pl:

CHECK: spaces preferred around that '-' (ctx:VxV)

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 54e2027..6d2420f 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -86,8 +86,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 		while (cnt < buflen && *index < scsi_sg_count(srb)) {
 			struct page *page = sg_page(sg) +
 					((sg->offset + *offset) >> PAGE_SHIFT);
-			unsigned int poff =
-					(sg->offset + *offset) & (PAGE_SIZE-1);
+			unsigned int poff = (sg->offset + *offset) &
+					    (PAGE_SIZE - 1);
 			unsigned int sglen = sg->length - *offset;
 
 			if (sglen > buflen - cnt) {
-- 
2.7.1



From shaun.ren at linux.com  Mon Feb 15 10:58:48 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon, 15 Feb 2016 10:58:48 -0800
Subject: [PATCH v5 RESEND 2/8] Staging: rts5208: rtsx_transport.c: Align to
 open parenthesis
In-Reply-To: <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
References: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
 <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455562734-10863-3-git-send-email-shaun.ren@linux.com>

This patch fixes the alignment issue reported by checkpatch.pl:

CHECK: Alignment should match open parenthesis

Add a unsigned char *sgbuffer in rtsx_stor_access_xfer_buffer to make the
following memcpy logic easier to read.

Add a struct scatterlist *sg in the use_sg branch of
rtsx_transfer_data_partial to make the parameters of the
rtsx_transfer_sglist_adma_partial call fit in 80 character lines after
aligning them to the open parenthesis.

Refactor memcpy logic in rtsx_stor_access_xfer_buf to make it more legible.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
Changes since v4
  * Moved unsigned char *sgbuffer decleration to the beginning of the if
    branch in rtsx_stor_access_xfer_buf()

Changes since v3
  * Fixed misalignment of the last parameter of rtsx_stor_access_xfer_buf()
  * Refactored memcpy in rtsx_stor_access_xfer_buf() for legibility

 drivers/staging/rts5208/rtsx_transport.c | 69 +++++++++++++++++++-------------
 1 file changed, 41 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 91fdccf..b6de93f 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -42,22 +42,28 @@
  */
 
 unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
-	unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
-	unsigned int *offset, enum xfer_buf_dir dir)
+				       unsigned int buflen,
+				       struct scsi_cmnd *srb,
+				       unsigned int *index,
+				       unsigned int *offset,
+				       enum xfer_buf_dir dir)
 {
 	unsigned int cnt;
 
 	/* If not using scatter-gather, just transfer the data directly. */
 	if (scsi_sg_count(srb) == 0) {
+		unsigned char *sgbuffer;
+
 		if (*offset >= scsi_bufflen(srb))
 			return 0;
 		cnt = min(buflen, scsi_bufflen(srb) - *offset);
+
+		sgbuffer = (unsigned char *)scsi_sglist(srb) + *offset;
+
 		if (dir == TO_XFER_BUF)
-			memcpy((unsigned char *) scsi_sglist(srb) + *offset,
-					buffer, cnt);
+			memcpy(sgbuffer, buffer, cnt);
 		else
-			memcpy(buffer, (unsigned char *) scsi_sglist(srb) +
-					*offset, cnt);
+			memcpy(buffer, sgbuffer, cnt);
 		*offset += cnt;
 
 	/*
@@ -126,7 +132,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
  * SCSI residue.
  */
 void rtsx_stor_set_xfer_buf(unsigned char *buffer,
-	unsigned int buflen, struct scsi_cmnd *srb)
+			    unsigned int buflen, struct scsi_cmnd *srb)
 {
 	unsigned int index = 0, offset = 0;
 
@@ -137,7 +143,7 @@ void rtsx_stor_set_xfer_buf(unsigned char *buffer,
 }
 
 void rtsx_stor_get_xfer_buf(unsigned char *buffer,
-	unsigned int buflen, struct scsi_cmnd *srb)
+			    unsigned int buflen, struct scsi_cmnd *srb)
 {
 	unsigned int index = 0, offset = 0;
 
@@ -191,8 +197,8 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 		/* set the result so the higher layers expect this data */
 		srb->result = SAM_STAT_CHECK_CONDITION;
 		memcpy(srb->sense_buffer,
-			(unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
-			sizeof(struct sense_data_t));
+		       (unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
+		       sizeof(struct sense_data_t));
 	}
 
 	return;
@@ -202,7 +208,7 @@ Handle_Errors:
 }
 
 void rtsx_add_cmd(struct rtsx_chip *chip,
-		u8 cmd_type, u16 reg_addr, u8 mask, u8 data)
+		  u8 cmd_type, u16 reg_addr, u8 mask, u8 data)
 {
 	u32 *cb = (u32 *)(chip->host_cmds_ptr);
 	u32 val = 0;
@@ -321,9 +327,11 @@ static inline void rtsx_add_sg_tbl(
 }
 
 static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
-		struct scatterlist *sg, int num_sg, unsigned int *index,
-		unsigned int *offset, int size,
-		enum dma_data_direction dma_dir, int timeout)
+					     struct scatterlist *sg, int num_sg,
+					     unsigned int *index,
+					     unsigned int *offset, int size,
+					     enum dma_data_direction dma_dir,
+					     int timeout)
 {
 	struct rtsx_dev *rtsx = chip->rtsx;
 	struct completion trans_done;
@@ -486,8 +494,9 @@ out:
 }
 
 static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
-		struct scatterlist *sg, int num_sg,
-		enum dma_data_direction dma_dir, int timeout)
+				     struct scatterlist *sg, int num_sg,
+				     enum dma_data_direction dma_dir,
+				     int timeout)
 {
 	struct rtsx_dev *rtsx = chip->rtsx;
 	struct completion trans_done;
@@ -633,7 +642,8 @@ out:
 }
 
 static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
-		size_t len, enum dma_data_direction dma_dir, int timeout)
+			     size_t len, enum dma_data_direction dma_dir,
+			     int timeout)
 {
 	struct rtsx_dev *rtsx = chip->rtsx;
 	struct completion trans_done;
@@ -716,9 +726,9 @@ out:
 }
 
 int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
-		void *buf, size_t len, int use_sg, unsigned int *index,
-		unsigned int *offset, enum dma_data_direction dma_dir,
-		int timeout)
+			       void *buf, size_t len, int use_sg,
+			       unsigned int *index, unsigned int *offset,
+			       enum dma_data_direction dma_dir, int timeout)
 {
 	int err = 0;
 
@@ -726,13 +736,16 @@ int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
 	if (rtsx_chk_stat(chip, RTSX_STAT_ABORT))
 		return -EIO;
 
-	if (use_sg)
-		err = rtsx_transfer_sglist_adma_partial(chip, card,
-				(struct scatterlist *)buf, use_sg,
-				index, offset, (int)len, dma_dir, timeout);
-	else
+	if (use_sg) {
+		struct scatterlist *sg = (struct scatterlist *)buf;
+
+		err = rtsx_transfer_sglist_adma_partial(chip, card, sg, use_sg,
+							index, offset, (int)len,
+							dma_dir, timeout);
+	} else {
 		err = rtsx_transfer_buf(chip, card,
 					buf, len, dma_dir, timeout);
+	}
 	if (err < 0) {
 		if (RTSX_TST_DELINK(chip)) {
 			RTSX_CLR_DELINK(chip);
@@ -745,7 +758,7 @@ int rtsx_transfer_data_partial(struct rtsx_chip *chip, u8 card,
 }
 
 int rtsx_transfer_data(struct rtsx_chip *chip, u8 card, void *buf, size_t len,
-		int use_sg, enum dma_data_direction dma_dir, int timeout)
+		       int use_sg, enum dma_data_direction dma_dir, int timeout)
 {
 	int err = 0;
 
@@ -757,8 +770,8 @@ int rtsx_transfer_data(struct rtsx_chip *chip, u8 card, void *buf, size_t len,
 
 	if (use_sg) {
 		err = rtsx_transfer_sglist_adma(chip, card,
-				(struct scatterlist *)buf,
-				use_sg, dma_dir, timeout);
+						(struct scatterlist *)buf,
+						use_sg, dma_dir, timeout);
 	} else {
 		err = rtsx_transfer_buf(chip, card, buf, len, dma_dir, timeout);
 	}
-- 
2.7.1



From shaun.ren at linux.com  Mon Feb 15 10:58:49 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon, 15 Feb 2016 10:58:49 -0800
Subject: [PATCH v5 RESEND 3/8] Staging: rts5208: rtsx_transport.c: Remove
 spaces after casts
In-Reply-To: <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
References: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
 <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455562734-10863-4-git-send-email-shaun.ren@linux.com>

This patch removes all spaces after casts in rtsx_transport.c, as reported
by checkpatch.pl:

CHECK: No space is necessary after a cast

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index b6de93f..54e2027 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -73,7 +73,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 	 */
 	} else {
 		struct scatterlist *sg =
-				(struct scatterlist *) scsi_sglist(srb)
+				(struct scatterlist *)scsi_sglist(srb)
 				+ *index;
 
 		/*
-- 
2.7.1



From shaun.ren at linux.com  Mon Feb 15 10:58:51 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon, 15 Feb 2016 10:58:51 -0800
Subject: [PATCH v5 RESEND 5/8] Staging: rts5208: rtsx_transport.c: Remove
 extra newlines
In-Reply-To: <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
References: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
 <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455562734-10863-6-git-send-email-shaun.ren@linux.com>

This patch fixes the following issues in rtsx_transport.c as reported by
checkpatch.pl:

CHECK: Blank lines aren't necessary after an open brace '{'
CHECK: Please don't use multiple blank lines

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 6d2420f..00401e2 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -91,12 +91,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 			unsigned int sglen = sg->length - *offset;
 
 			if (sglen > buflen - cnt) {
-
 				/* Transfer ends within this s-g entry */
 				sglen = buflen - cnt;
 				*offset += sglen;
 			} else {
-
 				/* Transfer continues to next s-g entry */
 				*offset = 0;
 				++*index;
@@ -153,7 +151,6 @@ void rtsx_stor_get_xfer_buf(unsigned char *buffer,
 		scsi_set_resid(srb, scsi_bufflen(srb) - buflen);
 }
 
-
 /***********************************************************************
  * Transport routines
  ***********************************************************************/
-- 
2.7.1



From shaun.ren at linux.com  Mon Feb 15 10:58:52 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon, 15 Feb 2016 10:58:52 -0800
Subject: [PATCH v5 RESEND 6/8] Staging: rts5208: rtsx_transport.c: Fix label
 naming convention
In-Reply-To: <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
References: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
 <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455562734-10863-7-git-send-email-shaun.ren@linux.com>

This patch fixes the following naming convention issue in rtsx_transport.c,
as reported by checkpatch.pl:

CHECK: Avoid CamelCase: <Handle_Errors>

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index 00401e2..aadef51 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -173,14 +173,14 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 	if (rtsx_chk_stat(chip, RTSX_STAT_ABORT)) {
 		dev_dbg(rtsx_dev(chip), "-- command was aborted\n");
 		srb->result = DID_ABORT << 16;
-		goto Handle_Errors;
+		goto handle_errors;
 	}
 
 	/* if there is a transport error, reset and don't auto-sense */
 	if (result == TRANSPORT_ERROR) {
 		dev_dbg(rtsx_dev(chip), "-- transport indicates error, resetting\n");
 		srb->result = DID_ERROR << 16;
-		goto Handle_Errors;
+		goto handle_errors;
 	}
 
 	srb->result = SAM_STAT_GOOD;
@@ -200,7 +200,7 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 
 	return;
 
-Handle_Errors:
+handle_errors:
 	return;
 }
 
-- 
2.7.1



From shaun.ren at linux.com  Mon Feb 15 10:58:54 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon, 15 Feb 2016 10:58:54 -0800
Subject: [PATCH v5 RESEND 8/8] Staging: rts5208: rtsx_transport.c: Fix
 comparisons to NULL
In-Reply-To: <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
References: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
 <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455562734-10863-9-git-send-email-shaun.ren@linux.com>

This patch changes all comparsions to NULL with !..., as reported by
checkpatch.pl.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
 drivers/staging/rts5208/rtsx_transport.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index c604576..f564a74 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -339,7 +339,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
 	struct scatterlist *sg_ptr;
 	u32 val = TRIG_DMA;
 
-	if ((sg == NULL) || (num_sg <= 0) || !offset || !index)
+	if (!sg || (num_sg <= 0) || !offset || !index)
 		return -EIO;
 
 	if (dma_dir == DMA_TO_DEVICE)
@@ -503,7 +503,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
 	long timeleft;
 	struct scatterlist *sg_ptr;
 
-	if ((sg == NULL) || (num_sg <= 0))
+	if (!sg || (num_sg <= 0))
 		return -EIO;
 
 	if (dma_dir == DMA_TO_DEVICE)
@@ -650,7 +650,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
 	u32 val = 1 << 31;
 	long timeleft;
 
-	if ((buf == NULL) || (len <= 0))
+	if (!buf || (len <= 0))
 		return -EIO;
 
 	if (dma_dir == DMA_TO_DEVICE)
-- 
2.7.1



From shaun.ren at linux.com  Mon Feb 15 10:58:53 2016
From: shaun.ren at linux.com (Shaun Ren)
Date: Mon, 15 Feb 2016 10:58:53 -0800
Subject: [PATCH v5 RESEND 7/8] Staging: rts5208: rtsx_transport.c: Remove
 unnecessary parentheses
In-Reply-To: <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
References: <1455250080-9897-1-git-send-email-shaun.ren@linux.com>
 <1455562734-10863-1-git-send-email-shaun.ren@linux.com>
Message-ID: <1455562734-10863-8-git-send-email-shaun.ren@linux.com>

This patch removes all unnecessary parentheses found by checkpatch.pl.

Signed-off-by: Shaun Ren <shaun.ren at linux.com>
---
Changes since v3
  * Fixed patch conflicts due to commit 9a66d05d82db
    ("Staging: rts5208: fix check for dma mapping error"), and
    commit b3232842dbef ("Staging: rts5208: remove unnecessary parantheses")

 drivers/staging/rts5208/rtsx_transport.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c b/drivers/staging/rts5208/rtsx_transport.c
index aadef51..c604576 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -194,7 +194,7 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct rtsx_chip *chip)
 		/* set the result so the higher layers expect this data */
 		srb->result = SAM_STAT_CHECK_CONDITION;
 		memcpy(srb->sense_buffer,
-		       (unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
+		       (unsigned char *)&chip->sense_buffer[SCSI_LUN(srb)],
 		       sizeof(struct sense_data_t));
 	}
 
@@ -368,7 +368,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
 
 	spin_unlock_irq(&rtsx->reg_lock);
 
-	sg_cnt = dma_map_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	sg_cnt = dma_map_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	resid = size;
 	sg_ptr = sg;
@@ -482,7 +482,7 @@ static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
 out:
 	rtsx->done = NULL;
 	rtsx->trans_state = STATE_TRANS_NONE;
-	dma_unmap_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	dma_unmap_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	if (err < 0)
 		rtsx_stop_cmd(chip, card);
@@ -532,7 +532,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
 
 	spin_unlock_irq(&rtsx->reg_lock);
 
-	buf_cnt = dma_map_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	buf_cnt = dma_map_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	sg_ptr = sg;
 
@@ -630,7 +630,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
 out:
 	rtsx->done = NULL;
 	rtsx->trans_state = STATE_TRANS_NONE;
-	dma_unmap_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+	dma_unmap_sg(&rtsx->pci->dev, sg, num_sg, dma_dir);
 
 	if (err < 0)
 		rtsx_stop_cmd(chip, card);
@@ -714,7 +714,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 card, void *buf,
 out:
 	rtsx->done = NULL;
 	rtsx->trans_state = STATE_TRANS_NONE;
-	dma_unmap_single(&(rtsx->pci->dev), addr, len, dma_dir);
+	dma_unmap_single(&rtsx->pci->dev, addr, len, dma_dir);
 
 	if (err < 0)
 		rtsx_stop_cmd(chip, card);
-- 
2.7.1



From catalin.marinas at arm.com  Mon Feb 15 10:59:57 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 15 Feb 2016 18:59:57 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <56C1E072.2090909@virtuozzo.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
Message-ID: <20160215185957.GB19413@e104818-lin.cambridge.arm.com>

On Mon, Feb 15, 2016 at 05:28:02PM +0300, Andrey Ryabinin wrote:
> On 02/12/2016 07:06 PM, Catalin Marinas wrote:
> > So far, we have:
> > 
> > KASAN+for-next/kernmap goes wrong
> > KASAN+UBSAN goes wrong
> > 
> > Enabled individually, KASAN, UBSAN and for-next/kernmap seem fine. I may
> > have to trim for-next/core down until we figure out where the problem
> > is.
> > 
> > BUG: KASAN: stack-out-of-bounds in find_busiest_group+0x164/0x16a0 at addr ffffffc93665bc8c
> 
> Can it be related to TLB conflicts, which supposed to be fixed in
> "arm64: kasan: avoid TLB conflicts" patch from "arm64: mm: rework page
> table creation" series ?

I can very easily reproduce this with a vanilla 4.5-rc1 series by
enabling inline instrumentation (maybe Mark's theory is true w.r.t.
image size).

Some information, maybe you can shed some light on this. It seems to
happen only for secondary CPUs on the swapper stack (I think allocated
via fork_idle()). The code generated looks sane to me, so KASAN should
not complain but maybe there is some uninitialised shadow, hence the
error.

The report:

-------------->8---------------
BUG: KASAN: stack-out-of-bounds in clockevents_program_event+0x354/0x368 at addr ffffffc93651bca8
Read of size 8 by task swapper/1/0
page:ffffffbde6d946c0 count:0 mapcount:0 mapping:          (null) index:0x0
flags: 0x4000000000000000()
page dumped because: kasan: bad access detected
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G    B           4.5.0-rc1+ #163
Hardware name: Juno (DT)
Call trace:
[<ffffffc00008f130>] dump_backtrace+0x0/0x358
[<ffffffc00008f49c>] show_stack+0x14/0x20
[<ffffffc000785dc0>] dump_stack+0xf8/0x188
[<ffffffc000343c0c>] kasan_report_error+0x524/0x550
[<ffffffc000343d50>] __asan_report_load8_noabort+0x40/0x48
[<ffffffc0001f2bc4>] clockevents_program_event+0x354/0x368
[<ffffffc0001f73d4>] tick_program_event+0xac/0x108
[<ffffffc0001d85c8>] hrtimer_start_range_ns+0x8a0/0xb20
[<ffffffc0001f8ba8>] __tick_nohz_idle_enter+0x970/0xca8
[<ffffffc0001f9368>] tick_nohz_idle_enter+0x60/0x98
[<ffffffc0001933ec>] cpu_startup_entry+0x14c/0x448
[<ffffffc000098654>] secondary_start_kernel+0x264/0x2e0
[<0000000080082ecc>] 0x80082ecc
Memory state around the buggy address:
 ffffffc93651bb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffffc93651bc00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
>ffffffc93651bc80: 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00
                                  ^
 ffffffc93651bd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffffc93651bd80: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4
-------------->8---------------

I put some printks in clockevents_program_event() and the SP is
0xffffffc93651bc70, so it matches the above.

Disassembling the code:

-------------->8---------------
ffffffc0001f2870 <clockevents_program_event>:
ffffffc0001f2870:       a9bc7bfd        stp     x29, x30, [sp,#-64]!
ffffffc0001f2874:       d2dff204        mov     x4, #0xff9000000000             // #280993940373504
ffffffc0001f2878:       910003fd        mov     x29, sp
ffffffc0001f287c:       910103a3        add     x3, x29, #0x40
ffffffc0001f2880:       f2fbffe4        movk    x4, #0xdfff, lsl #48
ffffffc0001f2884:       a90153f3        stp     x19, x20, [sp,#16]
ffffffc0001f2888:       a9025bf5        stp     x21, x22, [sp,#32]
ffffffc0001f288c:       f81f8c61        str     x1, [x3,#-8]!
ffffffc0001f2890:       aa0003f3        mov     x19, x0
ffffffc0001f2894:       53001c55        uxtb    w21, w2
ffffffc0001f2898:       d343fc60        lsr     x0, x3, #3
ffffffc0001f289c:       38e46800        ldrsb   w0, [x0,x4]
ffffffc0001f28a0:       350018e0        cbnz    w0, ffffffc0001f2bbc <clockevents_program_event+0x34c>

[...]

ffffffc0001f2bbc:       aa0303e0        mov     x0, x3
ffffffc0001f2bc0:       94054454        bl      ffffffc000343d10 <__asan_report_load8_noabort>
-------------->8---------------

To me, line ffffffc0001f288c looks like a normal store to a stack
variable and the stack boundaries look fine. The ffffffc0001f289c line
checks shadow and reads non-zero, hence the report. But I don't get
what's wrong with this function, other than corrupt KASAN shadow.

-- 
Catalin


From tony at atomide.com  Mon Feb 15 11:01:17 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 15 Feb 2016 11:01:17 -0800
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor:
 Replace timers with utilization ...'
In-Reply-To: <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
Message-ID: <20160215190116.GX19432@atomide.com>

* Rafael J. Wysocki <rafael at kernel.org> [160215 10:44]:
> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck <linux at roeck-us.net> wrote:
> > Rafael,
> 
> Hi,
> 
> Thanks for the report!
> 
> > I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
> > timers with utilization update callbacks' with next-20160215. An example
> > crash log and bisect results are attached below.
> >
> > Please let me know if there is anything I can do to help tracking down
> > the problem.
> 
> It looks like we've uncovered some nastiness in the arch ARM code (see below).
> 
> [cut]
> 
> > [    1.340000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> > [    1.340000] pgd = c0204000
> > [    1.340000] [00000000] *pgd=00000000
> > [    1.340000] Internal error: Oops: 80000005 [#1] SMP ARM
> > [    1.340000] Modules linked in:
> > [    1.340000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4-next-20160215 #1
> > [    1.340000] Hardware name: Generic OMAP3-GP (Flattened Device Tree)
> > [    1.340000] task: cb060000 ti: cb05a000 task.ti: cb05a000
> > [    1.340000] PC is at 0x0
> > [    1.340000] LR is at arch_send_call_function_single_ipi+0x34/0x38
> 
> Since this is ARM, arch_send_call_function_single_ipi() looks like this:
> 
> void arch_send_call_function_single_ipi(int cpu)
> {
>          smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
> }
> 
> so I'm not sure how the NULL pointer deref is possible even.
> 
> The only thing coming to mind would be that cpumask_of(cpu) triggers
> this, but I'm not sure how exactly that can happen.
> 
> I need help from somebody who knows how this low-level stuff works on ARM.

That's not even an SMP machine? I suspect a bunch of out of the
65 boot failures here are related to this:

https://kernelci.org/boot/all/job/next/kernel/next-20160215/

The SMP ones seem to fail with some regulator issues?

Regards,

Tony


From linux at arm.linux.org.uk  Mon Feb 15 11:02:09 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Feb 2016 19:02:09 +0000
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor:
 Replace timers with utilization ...'
In-Reply-To: <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
Message-ID: <20160215190208.GM10826@n2100.arm.linux.org.uk>

On Mon, Feb 15, 2016 at 07:41:21PM +0100, Rafael J. Wysocki wrote:
> Since this is ARM, arch_send_call_function_single_ipi() looks like this:
> 
> void arch_send_call_function_single_ipi(int cpu)
> {
>          smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
> }
> 
> so I'm not sure how the NULL pointer deref is possible even.

smp_cross_call() is a function pointer, and the hint is:

> I need help from somebody who knows how this low-level stuff works on ARM.
> 
> > [    1.340000] pc : [<00000000>]    lr : [<c030de78>]    psr: 20000193

here that the PC is zero.  It's initialised via set_smp_cross_call(),
which should be happening in drivers/irqchip/irq-gic.c for SMP
capable systems.

However, looking at this, this is an OMAP34xx based Beagle board, which
is a single CPU SoC.  There are no other CPUs to send IPIs to.

> > [    1.340000] sp : cb05b7c0  ip : 00000000  fp : cb05b83c
> > [    1.340000] r10: cfb8c0c0  r9 : 00000000  r8 : cb18a4c0
> > [    1.340000] r7 : 00000005  r6 : 00000005  r5 : cb5c0334  r4 : 00000000
> > [    1.340000] r3 : 00000000  r2 : c0c06a7c  r1 : 00000003  r0 : c0c06a7c
> > [    1.340000] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
> > [    1.340000] Control: 10c5387d  Table: 80204059  DAC: 00000051
> > [    1.340000] Process swapper/0 (pid: 1, stack limit = 0xcb05a220)
> > [    1.340000] Stack: (0xcb05b7c0 to 0xcb05c000)
> > [    1.340000] b7c0: 00000000 c03b3350 4fdec700 00000000 00000005 c0959a84 ffffffff 00000000
> > [    1.340000] b7e0: ffffffff cb18a4c0 cfb8c0c0 c03732d8 4c4b4000 cb18a4c0 cfb8c0c0 cfb8c0c0
> > [    1.340000] b800: 0e979000 cb18a4c0 cfb8c0c0 00000005 0e979000 c12130c0 00000000 cfb8c0c0
> > [    1.340000] b820: cb05b83c c0360d28 00000000 cb18a4c0 cfb8c0c0 60000193 cb05b84c c0360fc0
> > [    1.340000] b840: cb18a4c0 cb18a8b4 cb05b87c c0361b74 cfb8c100 00000141 cb05b934 cb1c1cc0
> > [    1.340000] b860: 00000002 00000000 00000000 00000048 c1416d0c cb0096c0 00000001 c0381de0
> > [    1.340000] b880: c1416080 cfb8c100 00000400 cb0096c0 cb009720 00000000 00000038 cb003000
> > [    1.340000] b8a0: 00000000 cb05b9c4 00000a28 c0381ea4 cb0096c0 cb0096d0 00000000 c0385150
> > [    1.340000] b8c0: c03850ac c1211518 00000000 c038168c 00000155 c0381788 c0932830 20000013
> > [    1.340000] b8e0: ffffffff cb05b924 00000000 c030bad4 00000001 00000009 00000002 fa070024
> > [    1.340000] b900: cb127c10 00009401 cb05b9b8 c1302100 00000000 00000000 cb05b9c4 00000a28
> > [    1.340000] b920: 00000000 cb05b940 00009601 c0932830 20000013 ffffffff 00000051 c093261c
> > [    1.340000] b940: 00000014 cb127c58 00000002 00000001 000f4240 cb127c10 1443fd00 00000001
> > [    1.340000] b960: c1302100 cb127c58 cb05b9b8 00000002 c145d438 ffff16ac 00000001 c0928358
> > [    1.340000] b980: cb127c74 cb127c58 00000002 cb05b9b8 cb05ba97 00000001 cb05ba97 00000001
> > [    1.340000] b9a0: 00000001 c0928538 00000000 cb518000 cb513740 c07726c4 0000004b cfb80001
> > [    1.340000] b9c0: cb513740 0001004b 017d0001 cb05ba97 00000000 c076dc30 00000001 00000000
> > [    1.340000] b9e0: 00000004 000000b9 000000ba cb518000 000000ba 000000b9 00000001 c076dd70
> > [    1.340000] ba00: 00000000 00000000 cfb8c100 cb518000 000000ba 00000001 00000001 cb05ba97
> > [    1.340000] ba20: 00000001 000000b9 00000000 c076dfcc c099a208 cb59d048 00000001 c1336dd0
> > [    1.340000] ba40: a0000113 00000000 00000001 cb05ba97 0000005e 00000004 00000001 00000000
> > [    1.340000] ba60: 00000000 000ee098 000ee098 c077fd34 0000000d c09e51f0 c09e51d0 cb51f400
> > [    1.340000] ba80: ffffffff 000ee098 000ee098 c068cb48 00000000 c09c157c cb019180 c067887c
> > [    1.340000] baa0: cb51f400 c067a700 000ee098 c09c160c cb015780 00000000 3b9aca00 cb5bdcc0
> > [    1.340000] bac0: cb51f400 00000000 00000000 00000000 000ee098 c067ab5c 000ee098 000ee098
> > [    1.340000] bae0: cb5bdcc0 000ee098 000ee098 000ee098 cfb87050 00000000 000ee098 c067c614
> > [    1.340000] bb00: cb5bdcc0 000ee098 000ee098 c0765ad4 1dcd6500 cb5bdc80 00000000 07735940
> > [    1.340000] bb20: cb5bdc80 cfb87050 cb5bdcc0 00000000 000ee098 c076660c 000ee098 cb5c11d0
> > [    1.340000] bb40: cb05bb90 00124f80 00124f80 00124f80 07735940 1dcd6500 ffffffff cb5c1100
> > [    1.340000] bb60: 00000000 00000000 c145dc8c cb5c0280 00000000 00000001 cb05bb90 c0958e78
> > [    1.340000] bb80: cb05bb8c c13cb404 00000000 00000000 00000010 0007a120 0001e848 00000021
> > [    1.340000] bba0: ffffffff ee222d90 00000000 00000000 00000000 00000010 cfb8b598 c13cb310
> > [    1.340000] bbc0: c1302578 c095ca58 c1302578 00000000 cb5c1100 00000000 000927c0 cb5bdfc0
> > [    1.340000] bbe0: c120e300 00000000 ee32cf60 00000000 c13cb310 cb5c1100 00000000 cb5c0304
> > [    1.340000] bc00: 00000010 c145dc8c c1302578 cb5c11b4 cb5c1108 c095cd04 c145dc8c 00000001
> > [    1.340000] bc20: cb5c1100 cb5c1100 00000000 c145dc8c c1302578 00000003 cb5c1100 00000000
> > [    1.340000] bc40: 00000010 c145dc8c c1302578 cb5c11b4 cb5c1108 c0959c5c cb5c1100 00000000
> > [    1.340000] bc60: 00000000 c095a2dc c0c0df58 00000001 0000ffff 00000001 00000000 00000000
> > [    1.340000] bc80: cb5bdc00 000927c0 0001e848 000493e0 0001e848 000927c0 0007a120 00000000
> > [    1.340000] bca0: 00000000 00000000 00000000 c13cb310 00000000 00000000 00000000 00000000
> > [    1.340000] bcc0: 00000000 00000000 ffffffe0 cb5c1160 cb5c1160 c095abf4 0001e848 000927c0
> > [    1.340000] bce0: cb5c0280 c13cb0a8 c13cb0a8 cb5bdf00 cb5c1184 cb5c1184 cb11e600 00000000
> > [    1.340000] bd00: c13cb128 cb5bf460 00000001 00000003 00000000 00000000 cb5c11ac cb5c11ac
> > [    1.340000] bd20: ffff0001 cb5c11b8 cb5c11b8 00000000 00000000 cb060000 00000000 00000000
> > [    1.340000] bd40: 00000000 cb5c11d8 cb5c11d8 00000000 cb5bdf80 cb5bdec0 cb5c1100 c095a5f0
> > [    1.340000] bd60: 00000000 cb11e600 00000000 c1212594 60000013 00000001 00000000 c13cb110
> > [    1.340000] bd80: c13acc68 c13cb0a8 c13cb440 c13cb440 00000000 00000000 00000000 c075674c
> > [    1.340000] bda0: c13cb440 cb00cc5c cb169db4 00000000 c1334248 c13cb488 c145dc8c c0959764
> > [    1.340000] bdc0: ffffffed cfb87050 cb5e2600 c095d670 ffffffed cb5e2610 fffffdfb c0758e48
> > [    1.340000] bde0: c0758df8 cb5e2610 c1459090 c1459098 00000000 c07577b0 00000000 00000000
> > [    1.340000] be00: cb05be30 c0757a68 00000001 c145906c 00000000 c0755d3c cb00cb70 cb5938b8
> > [    1.340000] be20: cb5e2610 cb5e2644 c13aca58 c0757534 cb5e2610 00000001 00000000 cb5e2610
> > [    1.340000] be40: cb5e2610 c13aca58 c13acaa8 c0756bc0 cb5e2610 00000000 cb5e2618 c07550c0
> > [    1.340000] be60: 00000000 c0587884 cb05beb8 cb5e2600 00000000 cb5e2600 cb5e2610 c1419000
> > [    1.340000] be80: c110362c c11a183c 00000000 c0758fdc 00000000 cb05beb8 cb5e2600 cb5bdb00
> > [    1.340000] bea0: c1419000 c07597a8 c0ead2ac c1306788 c1306788 c1112510 00000000 00000000
> > [    1.340000] bec0: c0ead2ac 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > [    1.340000] bee0: 00000000 00000000 00000000 c110f828 c110fabc c110fac4 c110fabc c1103648
> > [    1.340000] bf00: c1306788 c0301d28 0000006f cb05bf28 c035a8bc c035a8cc 60000013 ffffffff
> > [    1.340000] bf20: 00000051 c058b428 c0ff5b24 c0c1da88 0000011a c035ab48 c11a183c c0ea7034
> > [    1.340000] bf40: c0ff451c 00000000 00000007 00000007 c1335704 cfb96300 c120de7c 00000007
> > [    1.340000] bf60: c11a1834 c1419000 0000011a c11a183c c1100598 c1100dc4 00000007 00000007
> > [    1.340000] bf80: 00000000 c1100598 00000000 c0b0bcfc 00000000 00000000 00000000 00000000
> > [    1.340000] bfa0: 00000000 c0b0bd04 00000000 c0307e78 00000000 00000000 00000000 00000000
> > [    1.340000] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > [    1.340000] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> > [    1.340000] [<c030de78>] (arch_send_call_function_single_ipi) from [<c03b3350>] (irq_work_queue_on+0x90/0x100)
> > [    1.340000] [<c03b3350>] (irq_work_queue_on) from [<c0959a84>] (cpufreq_update_util+0x40/0x4c)
> > [    1.340000] [<c0959a84>] (cpufreq_update_util) from [<c03732d8>] (enqueue_task_rt+0x28/0x26c)
> > [    1.340000] [<c03732d8>] (enqueue_task_rt) from [<c0360d28>] (activate_task+0x60/0x64)
> > [    1.340000] [<c0360d28>] (activate_task) from [<c0360fc0>] (ttwu_do_activate.constprop.13+0x34/0x68)
> > [    1.340000] [<c0360fc0>] (ttwu_do_activate.constprop.13) from [<c0361b74>] (try_to_wake_up+0x1a0/0x318)
> > [    1.340000] [<c0361b74>] (try_to_wake_up) from [<c0381de0>] (handle_irq_event_percpu+0xdc/0x15c)
> > [    1.340000] [<c0381de0>] (handle_irq_event_percpu) from [<c0381ea4>] (handle_irq_event+0x44/0x68)
> > [    1.340000] [<c0381ea4>] (handle_irq_event) from [<c0385150>] (handle_level_irq+0xa4/0x13c)
> > [    1.340000] [<c0385150>] (handle_level_irq) from [<c038168c>] (generic_handle_irq+0x18/0x28)
> > [    1.340000] [<c038168c>] (generic_handle_irq) from [<c0381788>] (__handle_domain_irq+0x54/0xb0)
> > [    1.340000] [<c0381788>] (__handle_domain_irq) from [<c030bad4>] (__irq_svc+0x54/0x70)
> > [    1.340000] [<c030bad4>] (__irq_svc) from [<c0932830>] (omap_i2c_xfer+0x320/0x5a0)
> 
> It looks like we got an interrupt in the middle of an i2c transaction
> changing the CPU OPP.  The handler of that tried to enqueue an RT task
> and that led to a cpufreq update that in turn triggered the crash.

I think the question here is around cpufreq_update_util() calling
irq_work_queue_on() for the same CPU... from an IRQ handler.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From marc.zyngier at arm.com  Mon Feb 15 11:03:33 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 15 Feb 2016 19:03:33 +0000
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <CAJZ5v0gfOVyoWeee5jg7NxLFm-xwdA6-sPQV+cJ=NWJOV-wYzg@mail.gmail.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
 <56C21DD0.40508@arm.com>
 <CAJZ5v0gfOVyoWeee5jg7NxLFm-xwdA6-sPQV+cJ=NWJOV-wYzg@mail.gmail.com>
Message-ID: <56C22105.6050900@arm.com>

On 15/02/16 18:54, Rafael J. Wysocki wrote:
> On Mon, Feb 15, 2016 at 7:49 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>> On 15/02/16 18:41, Rafael J. Wysocki wrote:
>>> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck <linux at roeck-us.net> wrote:
>>>> Rafael,
>>>
>>> Hi,
>>>
>>> Thanks for the report!
>>>
>>>> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
>>>> timers with utilization update callbacks' with next-20160215. An example
>>>> crash log and bisect results are attached below.
>>>>
>>>> Please let me know if there is anything I can do to help tracking down
>>>> the problem.
>>>
>>> It looks like we've uncovered some nastiness in the arch ARM code (see below).
>>>
>>> [cut]
>>>
>>>> [    1.340000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
>>>> [    1.340000] pgd = c0204000
>>>> [    1.340000] [00000000] *pgd=00000000
>>>> [    1.340000] Internal error: Oops: 80000005 [#1] SMP ARM
>>>> [    1.340000] Modules linked in:
>>>> [    1.340000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4-next-20160215 #1
>>>> [    1.340000] Hardware name: Generic OMAP3-GP (Flattened Device Tree)
>>>> [    1.340000] task: cb060000 ti: cb05a000 task.ti: cb05a000
>>>> [    1.340000] PC is at 0x0
>>>> [    1.340000] LR is at arch_send_call_function_single_ipi+0x34/0x38
>>>
>>> Since this is ARM, arch_send_call_function_single_ipi() looks like this:
>>>
>>> void arch_send_call_function_single_ipi(int cpu)
>>> {
>>>          smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
>>> }
>>>
>>> so I'm not sure how the NULL pointer deref is possible even.
>>>
>>> The only thing coming to mind would be that cpumask_of(cpu) triggers
>>> this, but I'm not sure how exactly that can happen.
>>>
>>> I need help from somebody who knows how this low-level stuff works on ARM.
>>
>> Given that OMAP3 is a UP system, there is zero chance that it has
>> registered the magic hook that delivers IPIs (its interrupt controller
>> is not even capable of doing so).
>>
>> I don't really know the context, but IPIs on a UP system seem at best odd.
> 
> That would explain it, thanks.
> 
> So it looks like we should always use irq_work_queue() on UP even if
> CONFIG_SMP is set, shouldn't we?

Something like that, yes. CONFIG_SMP is not an indication of an SMP
system anymore (we've even dropped the config option on arm64).

Hopefully num_possible_cpus() is reliable enough to let you do the right
thing...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From linux at arm.linux.org.uk  Mon Feb 15 11:07:00 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Feb 2016 19:07:00 +0000
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor:
 Replace timers with utilization ...'
In-Reply-To: <CAJZ5v0gfOVyoWeee5jg7NxLFm-xwdA6-sPQV+cJ=NWJOV-wYzg@mail.gmail.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
 <56C21DD0.40508@arm.com>
 <CAJZ5v0gfOVyoWeee5jg7NxLFm-xwdA6-sPQV+cJ=NWJOV-wYzg@mail.gmail.com>
Message-ID: <20160215190700.GN10826@n2100.arm.linux.org.uk>

On Mon, Feb 15, 2016 at 07:54:26PM +0100, Rafael J. Wysocki wrote:
> On Mon, Feb 15, 2016 at 7:49 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> > Given that OMAP3 is a UP system, there is zero chance that it has
> > registered the magic hook that delivers IPIs (its interrupt controller
> > is not even capable of doing so).
> >
> > I don't really know the context, but IPIs on a UP system seem at best odd.
> 
> That would explain it, thanks.
> 
> So it looks like we should always use irq_work_queue() on UP even if
> CONFIG_SMP is set, shouldn't we?

irq_work_queue_on() doesn't check whether 'cpu' is the CPU that we're
running on.  This is a problem where we want to be able to run a kernel
built for SMP on a UP system.

I guess the question is whether irq_work_queue_on() is buggy, or whether
our implementation of arch_send_call_function_single_ipi() is buggy.
Should arch_send_call_function_single_ipi() do something on UP systems,
if so what?

We don't have IPIs on UP systems, so we can't raise any interrupts.
So, should we call generic_smp_call_function_interrupt() directly
from it?

Some clues would be good...

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From will.deacon at arm.com  Mon Feb 15 11:07:48 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Feb 2016 19:07:48 +0000
Subject: [PATCH v4 21/23] arm64: hw_breakpoint: Allow EL2 breakpoints if
 running in HYP
In-Reply-To: <20160215174656.GN6298@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
 <1455216004-19499-22-git-send-email-marc.zyngier@arm.com>
 <20160215174656.GN6298@arm.com>
Message-ID: <20160215190747.GR6298@arm.com>

On Mon, Feb 15, 2016 at 05:46:56PM +0000, Will Deacon wrote:
> On Thu, Feb 11, 2016 at 06:40:02PM +0000, Marc Zyngier wrote:
> > With VHE, we place kernel {watch,break}-points at EL2 to get things
> > like kgdb and "perf -e mem:..." working.
> > 
> > This requires a bit of repainting in the low-level encore/decode,
> > but is otherwise pretty simple.
> > 
> > Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> > ---
> >  arch/arm64/include/asm/hw_breakpoint.h | 49 +++++++++++++++++++++-------------
> >  1 file changed, 31 insertions(+), 18 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
> > index 9732908..4d8d5a8 100644
> > --- a/arch/arm64/include/asm/hw_breakpoint.h
> > +++ b/arch/arm64/include/asm/hw_breakpoint.h
> > @@ -18,6 +18,7 @@
> >  
> >  #include <asm/cputype.h>
> >  #include <asm/cpufeature.h>
> > +#include <asm/virt.h>
> >  
> >  #ifdef __KERNEL__
> >  
> > @@ -35,24 +36,6 @@ struct arch_hw_breakpoint {
> >  	struct arch_hw_breakpoint_ctrl ctrl;
> >  };
> >  
> > -static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
> > -{
> > -	return (ctrl.len << 5) | (ctrl.type << 3) | (ctrl.privilege << 1) |
> > -		ctrl.enabled;
> > -}
> > -
> > -static inline void decode_ctrl_reg(u32 reg,
> > -				   struct arch_hw_breakpoint_ctrl *ctrl)
> > -{
> > -	ctrl->enabled	= reg & 0x1;
> > -	reg >>= 1;
> > -	ctrl->privilege	= reg & 0x3;
> > -	reg >>= 2;
> > -	ctrl->type	= reg & 0x3;
> > -	reg >>= 2;
> > -	ctrl->len	= reg & 0xff;
> > -}
> > -
> >  /* Breakpoint */
> >  #define ARM_BREAKPOINT_EXECUTE	0
> >  
> > @@ -62,6 +45,7 @@ static inline void decode_ctrl_reg(u32 reg,
> >  #define AARCH64_ESR_ACCESS_MASK	(1 << 6)
> >  
> >  /* Privilege Levels */
> > +#define AARCH64_BREAKPOINT_EL2	0
> >  #define AARCH64_BREAKPOINT_EL1	1
> >  #define AARCH64_BREAKPOINT_EL0	2
> >  
> > @@ -76,6 +60,35 @@ static inline void decode_ctrl_reg(u32 reg,
> >  #define ARM_KERNEL_STEP_ACTIVE	1
> >  #define ARM_KERNEL_STEP_SUSPEND	2
> >  
> > +#define DBG_HMC_HYP		(1 << 13)
> > +#define DBG_SSC_HYP		(3 << 14)
> 
> Why do we need to touch the SSC field at all?
> 
> > +
> > +static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
> > +{
> > +	u32 val = (ctrl.len << 5) | (ctrl.type << 3) | ctrl.enabled;
> > +
> > +	if (is_kernel_in_hyp_mode() && ctrl.privilege == AARCH64_BREAKPOINT_EL1)
> > +		val |= DBG_HMC_HYP | DBG_SSC_HYP | (AARCH64_BREAKPOINT_EL2 << 1);
> 
> I don't think this is correct. We want to allow, for example, a userspace
> watchpoint to fire thanks to something like put_user, so the encoding
> really needs to build up the PMC field (like we do already), then orr in
> the HMC field.

Hmm, I got my arm and my arm64 mixed up here. For the latter, we don't
actually support EL0+EL1 watchpoints, but I still think that the
{HMC,SSC,PMC} encoding of {1,00,xx} is cleaner.

Will


From rafael at kernel.org  Mon Feb 15 11:12:33 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 15 Feb 2016 20:12:33 +0100
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <56C22105.6050900@arm.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
 <56C21DD0.40508@arm.com>
 <CAJZ5v0gfOVyoWeee5jg7NxLFm-xwdA6-sPQV+cJ=NWJOV-wYzg@mail.gmail.com>
 <56C22105.6050900@arm.com>
Message-ID: <CAJZ5v0gXGzzJ7CcbgNNO-ULrtd9Z2hbqHeuXRYJLFLrh+BWVWA@mail.gmail.com>

On Mon, Feb 15, 2016 at 8:03 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 15/02/16 18:54, Rafael J. Wysocki wrote:
>> On Mon, Feb 15, 2016 at 7:49 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>> On 15/02/16 18:41, Rafael J. Wysocki wrote:
>>>> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck <linux at roeck-us.net> wrote:
>>>>> Rafael,
>>>>
>>>> Hi,
>>>>
>>>> Thanks for the report!
>>>>
>>>>> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
>>>>> timers with utilization update callbacks' with next-20160215. An example
>>>>> crash log and bisect results are attached below.
>>>>>
>>>>> Please let me know if there is anything I can do to help tracking down
>>>>> the problem.
>>>>
>>>> It looks like we've uncovered some nastiness in the arch ARM code (see below).
>>>>
>>>> [cut]
>>>>
>>>>> [    1.340000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
>>>>> [    1.340000] pgd = c0204000
>>>>> [    1.340000] [00000000] *pgd=00000000
>>>>> [    1.340000] Internal error: Oops: 80000005 [#1] SMP ARM
>>>>> [    1.340000] Modules linked in:
>>>>> [    1.340000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4-next-20160215 #1
>>>>> [    1.340000] Hardware name: Generic OMAP3-GP (Flattened Device Tree)
>>>>> [    1.340000] task: cb060000 ti: cb05a000 task.ti: cb05a000
>>>>> [    1.340000] PC is at 0x0
>>>>> [    1.340000] LR is at arch_send_call_function_single_ipi+0x34/0x38
>>>>
>>>> Since this is ARM, arch_send_call_function_single_ipi() looks like this:
>>>>
>>>> void arch_send_call_function_single_ipi(int cpu)
>>>> {
>>>>          smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
>>>> }
>>>>
>>>> so I'm not sure how the NULL pointer deref is possible even.
>>>>
>>>> The only thing coming to mind would be that cpumask_of(cpu) triggers
>>>> this, but I'm not sure how exactly that can happen.
>>>>
>>>> I need help from somebody who knows how this low-level stuff works on ARM.
>>>
>>> Given that OMAP3 is a UP system, there is zero chance that it has
>>> registered the magic hook that delivers IPIs (its interrupt controller
>>> is not even capable of doing so).
>>>
>>> I don't really know the context, but IPIs on a UP system seem at best odd.
>>
>> That would explain it, thanks.
>>
>> So it looks like we should always use irq_work_queue() on UP even if
>> CONFIG_SMP is set, shouldn't we?
>
> Something like that, yes. CONFIG_SMP is not an indication of an SMP
> system anymore (we've even dropped the config option on arm64).
>
> Hopefully num_possible_cpus() is reliable enough to let you do the right
> thing...

Well, in fact I can always use irq_work_queue() in there at least for
the time being.

Let me prepare a patch.

Thanks,
Rafael


From thierry.reding at gmail.com  Mon Feb 15 11:17:36 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 15 Feb 2016 20:17:36 +0100
Subject: [PATCH] arm64/efi: Make strnlen() available to the EFI namespace
Message-ID: <1455563856-1553-1-git-send-email-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

Changes introduced in the upstream version of libfdt pulled in by commit
91feabc2e224 ("scripts/dtc: Update to upstream commit b06e55c88b9b") use
the strnlen() function, which isn't currently available to the EFI name-
space. Add it to the EFI namespace to avoid a linker error.

Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Rob Herring <robh at kernel.org>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 arch/arm64/kernel/image.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
index c9c62cab25a4..8a1978f4a555 100644
--- a/arch/arm64/kernel/image.h
+++ b/arch/arm64/kernel/image.h
@@ -96,6 +96,8 @@ __efistub_strcmp		= KALLSYMS_HIDE(__pi_strcmp);
 __efistub_strncmp		= KALLSYMS_HIDE(__pi_strncmp);
 __efistub___flush_dcache_area	= KALLSYMS_HIDE(__pi___flush_dcache_area);
 
+__efistub_strnlen		= KALLSYMS_HIDE(strnlen);
+
 #ifdef CONFIG_KASAN
 __efistub___memcpy		= KALLSYMS_HIDE(__pi_memcpy);
 __efistub___memmove		= KALLSYMS_HIDE(__pi_memmove);
-- 
2.7.1



From ard.biesheuvel at linaro.org  Mon Feb 15 11:23:22 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 15 Feb 2016 20:23:22 +0100
Subject: [PATCH] arm64/efi: Make strnlen() available to the EFI namespace
In-Reply-To: <1455563856-1553-1-git-send-email-thierry.reding@gmail.com>
References: <1455563856-1553-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <CAKv+Gu86oyHJcBhkjouLQk8FMR=0obrPpwnYvXMFSJkOa3c2pA@mail.gmail.com>

Hi Thierry,

On 15 February 2016 at 20:17, Thierry Reding <thierry.reding at gmail.com> wrote:
> From: Thierry Reding <treding at nvidia.com>
>
> Changes introduced in the upstream version of libfdt pulled in by commit
> 91feabc2e224 ("scripts/dtc: Update to upstream commit b06e55c88b9b") use
> the strnlen() function, which isn't currently available to the EFI name-
> space. Add it to the EFI namespace to avoid a linker error.
>
> Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Rob Herring <robh at kernel.org>
> Signed-off-by: Thierry Reding <treding at nvidia.com>
> ---
>  arch/arm64/kernel/image.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
> index c9c62cab25a4..8a1978f4a555 100644
> --- a/arch/arm64/kernel/image.h
> +++ b/arch/arm64/kernel/image.h
> @@ -96,6 +96,8 @@ __efistub_strcmp              = KALLSYMS_HIDE(__pi_strcmp);
>  __efistub_strncmp              = KALLSYMS_HIDE(__pi_strncmp);
>  __efistub___flush_dcache_area  = KALLSYMS_HIDE(__pi___flush_dcache_area);
>
> +__efistub_strnlen              = KALLSYMS_HIDE(strnlen);
> +

To align with the existing code, we should use __pi_strnlen here, and
declare the asm version of strnlen with ENDPIPROC()

Thanks,
Ard.


>  #ifdef CONFIG_KASAN
>  __efistub___memcpy             = KALLSYMS_HIDE(__pi_memcpy);
>  __efistub___memmove            = KALLSYMS_HIDE(__pi_memmove);
> --
> 2.7.1
>


From linux at arm.linux.org.uk  Mon Feb 15 11:23:17 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 15 Feb 2016 19:23:17 +0000
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor:
 Replace timers with utilization ...'
In-Reply-To: <56C22105.6050900@arm.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
 <56C21DD0.40508@arm.com>
 <CAJZ5v0gfOVyoWeee5jg7NxLFm-xwdA6-sPQV+cJ=NWJOV-wYzg@mail.gmail.com>
 <56C22105.6050900@arm.com>
Message-ID: <20160215192316.GO10826@n2100.arm.linux.org.uk>

On Mon, Feb 15, 2016 at 07:03:33PM +0000, Marc Zyngier wrote:
> On 15/02/16 18:54, Rafael J. Wysocki wrote:
> > That would explain it, thanks.
> > 
> > So it looks like we should always use irq_work_queue() on UP even if
> > CONFIG_SMP is set, shouldn't we?
> 
> Something like that, yes. CONFIG_SMP is not an indication of an SMP
> system anymore (we've even dropped the config option on arm64).
> 
> Hopefully num_possible_cpus() is reliable enough to let you do the right
> thing...

CONFIG_SMP just says whether to include support for SMP.  It doesn't
mandate running on a SMP system. :)

I've been looking around the usages of irq_work_queue_on in kernel/
in -rc4, and some places seem to check for "this CPU":

        /*
         * It is possible that a restart caused this CPU to be
         * chosen again. Don't bother with an IPI, just see if we
         * have more to push.
         */
        if (unlikely(cpu == rq->cpu))
                goto again;

        /* Try the next RT overloaded CPU */
        irq_work_queue_on(&rt_rq->push_work, cpu);

I'm not sure about tell_cpu_to_push().

It's also called via tick_nohz_full_kick_cpu(), and the core scheduler
avoids calling this for the current CPU:

        if (tick_nohz_full_cpu(cpu)) {
                if (cpu != smp_processor_id() ||
                    tick_nohz_tick_stopped())
                        tick_nohz_full_kick_cpu(cpu);

I'm not sure about add_nr_running() in kernel/sched/sched.h - I think
that _could_ be a problem even without Rafael's cpufreq change.

So... the question is what do we do with irq_work_queue_on() in general
when called on non-SMP systems.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From eric at anholt.net  Mon Feb 15 11:25:18 2016
From: eric at anholt.net (Eric Anholt)
Date: Mon, 15 Feb 2016 11:25:18 -0800
Subject: [PATCH v2 0/2] spi: bcm2835aux: auxiliary spi improvements
In-Reply-To: <1455444269-4797-1-git-send-email-stephanolbrich@gmx.de>
References: <1455444269-4797-1-git-send-email-stephanolbrich@gmx.de>
Message-ID: <87povx6ajl.fsf@eliezer.anholt.net>

Stephan Olbrich <stephanolbrich at gmx.de> writes:

> From: Stephan Olbrich <stephanolbrich at gmx.de>
>
> This patch series has some improvements and fixes for the auxiliary spi.
>
> since v1:
> - the first two patches "fix bitmask defines" and "disable tx fifo empty irq"
>   were picked up by Mark Brown and applied to his spi tree so I don't post
>   them again.
> - speed bits are now reset before setting the new speed in case the speed
>   changes between transfers
> - remove CPHA from master->mode_bits
> - rename CPHA bit mask to RISING to make it more clear why things are done
>   that way
>
> 1. set up spi-mode before asserting cs-gpio
>  As Martin Sperl suggested this is done in the same way as in spi-bcm2835.c
>  acace73df2c1913a526c1b41e4741a4a6704c863
>
> 2. fix CPOL/CPHA setting
>  From what I've seen in the documentation [1] and seen on the scope this chip
>  doesn't support modes with CPHA=1. With this patch spi mode 0 and 2 should
>  work correctly whereas mode 1 and 3 are not supported. 

These are both:

Reviewed-by: Eric Anholt <eric at anholt.net>

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160215/4831e8e9/attachment.sig>

From will.deacon at arm.com  Mon Feb 15 11:27:46 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Feb 2016 19:27:46 +0000
Subject: [PATCH] arm64/efi: Make strnlen() available to the EFI namespace
In-Reply-To: <1455563856-1553-1-git-send-email-thierry.reding@gmail.com>
References: <1455563856-1553-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <20160215192746.GT6298@arm.com>

On Mon, Feb 15, 2016 at 08:17:36PM +0100, Thierry Reding wrote:
> From: Thierry Reding <treding at nvidia.com>
> 
> Changes introduced in the upstream version of libfdt pulled in by commit
> 91feabc2e224 ("scripts/dtc: Update to upstream commit b06e55c88b9b") use
> the strnlen() function, which isn't currently available to the EFI name-
> space. Add it to the EFI namespace to avoid a linker error.
> 
> Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Rob Herring <robh at kernel.org>
> Signed-off-by: Thierry Reding <treding at nvidia.com>
> ---
>  arch/arm64/kernel/image.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
> index c9c62cab25a4..8a1978f4a555 100644
> --- a/arch/arm64/kernel/image.h
> +++ b/arch/arm64/kernel/image.h
> @@ -96,6 +96,8 @@ __efistub_strcmp		= KALLSYMS_HIDE(__pi_strcmp);
>  __efistub_strncmp		= KALLSYMS_HIDE(__pi_strncmp);
>  __efistub___flush_dcache_area	= KALLSYMS_HIDE(__pi___flush_dcache_area);
>  
> +__efistub_strnlen		= KALLSYMS_HIDE(strnlen);

Shouldn't this refer to __pi_strnlen once we've established that our
strnlen implementation is position independent? It looks like it is, so
you just need to s/ENDPROC/ENDPIPROC/ over there to get the symbol
defined.

Will


From rjw at rjwysocki.net  Mon Feb 15 11:28:57 2016
From: rjw at rjwysocki.net (Rafael J. Wysocki)
Date: Mon, 15 Feb 2016 20:28:57 +0100
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <CAJZ5v0gXGzzJ7CcbgNNO-ULrtd9Z2hbqHeuXRYJLFLrh+BWVWA@mail.gmail.com>
References: <20160215170527.GA24453@roeck-us.net> <56C22105.6050900@arm.com>
 <CAJZ5v0gXGzzJ7CcbgNNO-ULrtd9Z2hbqHeuXRYJLFLrh+BWVWA@mail.gmail.com>
Message-ID: <1508162.Id3YElPxB2@vostro.rjw.lan>

On Monday, February 15, 2016 08:12:33 PM Rafael J. Wysocki wrote:
> On Mon, Feb 15, 2016 at 8:03 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> > On 15/02/16 18:54, Rafael J. Wysocki wrote:
> >> On Mon, Feb 15, 2016 at 7:49 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> >>> On 15/02/16 18:41, Rafael J. Wysocki wrote:
> >>>> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck <linux at roeck-us.net> wrote:
> >>>>> Rafael,
> >>>>
> >>>> Hi,
> >>>>
> >>>> Thanks for the report!
> >>>>
> >>>>> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
> >>>>> timers with utilization update callbacks' with next-20160215. An example
> >>>>> crash log and bisect results are attached below.
> >>>>>
> >>>>> Please let me know if there is anything I can do to help tracking down
> >>>>> the problem.
> >>>>
> >>>> It looks like we've uncovered some nastiness in the arch ARM code (see below).
> >>>>
> >>>> [cut]
> >>>>
> >>>>> [    1.340000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> >>>>> [    1.340000] pgd = c0204000
> >>>>> [    1.340000] [00000000] *pgd=00000000
> >>>>> [    1.340000] Internal error: Oops: 80000005 [#1] SMP ARM
> >>>>> [    1.340000] Modules linked in:
> >>>>> [    1.340000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4-next-20160215 #1
> >>>>> [    1.340000] Hardware name: Generic OMAP3-GP (Flattened Device Tree)
> >>>>> [    1.340000] task: cb060000 ti: cb05a000 task.ti: cb05a000
> >>>>> [    1.340000] PC is at 0x0
> >>>>> [    1.340000] LR is at arch_send_call_function_single_ipi+0x34/0x38
> >>>>
> >>>> Since this is ARM, arch_send_call_function_single_ipi() looks like this:
> >>>>
> >>>> void arch_send_call_function_single_ipi(int cpu)
> >>>> {
> >>>>          smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
> >>>> }
> >>>>
> >>>> so I'm not sure how the NULL pointer deref is possible even.
> >>>>
> >>>> The only thing coming to mind would be that cpumask_of(cpu) triggers
> >>>> this, but I'm not sure how exactly that can happen.
> >>>>
> >>>> I need help from somebody who knows how this low-level stuff works on ARM.
> >>>
> >>> Given that OMAP3 is a UP system, there is zero chance that it has
> >>> registered the magic hook that delivers IPIs (its interrupt controller
> >>> is not even capable of doing so).
> >>>
> >>> I don't really know the context, but IPIs on a UP system seem at best odd.
> >>
> >> That would explain it, thanks.
> >>
> >> So it looks like we should always use irq_work_queue() on UP even if
> >> CONFIG_SMP is set, shouldn't we?
> >
> > Something like that, yes. CONFIG_SMP is not an indication of an SMP
> > system anymore (we've even dropped the config option on arm64).
> >
> > Hopefully num_possible_cpus() is reliable enough to let you do the right
> > thing...
> 
> Well, in fact I can always use irq_work_queue() in there at least for
> the time being.
> 
> Let me prepare a patch.

Guenter, Tony,

Below is a patch to try, on top of linux-next.

Please let me know if the problem is still around with that patch applied.

Thanks,
Rafael


---
 drivers/cpufreq/cpufreq_governor.c |   11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -350,15 +350,6 @@ static void dbs_irq_work(struct irq_work
 	schedule_work(&policy_dbs->work);
 }
 
-static inline void gov_queue_irq_work(struct policy_dbs_info *policy_dbs)
-{
-#ifdef CONFIG_SMP
-	irq_work_queue_on(&policy_dbs->irq_work, smp_processor_id());
-#else
-	irq_work_queue(&policy_dbs->irq_work);
-#endif
-}
-
 static void dbs_update_util_handler(struct update_util_data *data, u64 time,
 				    unsigned long util, unsigned long max)
 {
@@ -378,7 +369,7 @@ static void dbs_update_util_handler(stru
 		delta_ns = time - policy_dbs->last_sample_time;
 		if ((s64)delta_ns >= policy_dbs->sample_delay_ns) {
 			policy_dbs->last_sample_time = time;
-			gov_queue_irq_work(policy_dbs);
+			irq_work_queue(&policy_dbs->irq_work);
 			return;
 		}
 	}



From will.deacon at arm.com  Mon Feb 15 11:40:38 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Feb 2016 19:40:38 +0000
Subject: [PATCH v3 1/5] arm64/perf: Rename Cortex A57 events
In-Reply-To: <e0ecaaaffb64cc0b2ecfd8852f718a3f1d642b5c.1454516082.git.jglauber@cavium.com>
References: <cover.1454516082.git.jglauber@cavium.com>
 <e0ecaaaffb64cc0b2ecfd8852f718a3f1d642b5c.1454516082.git.jglauber@cavium.com>
Message-ID: <20160215194037.GU6298@arm.com>

On Wed, Feb 03, 2016 at 06:11:56PM +0100, Jan Glauber wrote:
> The implemented Cortex A57 events are not A57 specific.
> They are recommended by ARM and can be found on other
> ARMv8 SOCs like Cavium ThunderX too. Therefore move
> these events to the common PMUv3 table.

I can't find anything in the architecture that suggests these event
numbers are necessarily portable between implementations. Am I missing
something?

Will


From linus.walleij at linaro.org  Mon Feb 15 11:41:22 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 15 Feb 2016 20:41:22 +0100
Subject: [PATCH] pinctrl: coh901: fix initconst annotation
In-Reply-To: <1454941800-2776480-1-git-send-email-arnd@arndb.de>
References: <1454941800-2776480-1-git-send-email-arnd@arndb.de>
Message-ID: <CACRpkdYOq7C-wBktOMSuhkjfWwmH-8ukOPSnuX7ACcLuCUiH-g@mail.gmail.com>

On Mon, Feb 8, 2016 at 3:29 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> Clang correctly points out that the section attribute for u300_gpio_confdata
> is in the wrong place:
>
> drivers/pinctrl/pinctrl-coh901.c:130:37: error: '__section__' attribute only applies to functions and global variables
>
> This moves it from the type name to the variable, so it actually gets
> discarded.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Patch applied.

Yours,
Linus Walleij


From linux at roeck-us.net  Mon Feb 15 11:40:21 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 15 Feb 2016 11:40:21 -0800
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <20160215190116.GX19432@atomide.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
 <20160215190116.GX19432@atomide.com>
Message-ID: <56C229A5.8020901@roeck-us.net>

On 02/15/2016 11:01 AM, Tony Lindgren wrote:
> * Rafael J. Wysocki <rafael at kernel.org> [160215 10:44]:
>> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck <linux at roeck-us.net> wrote:
>>> Rafael,
>>
>> Hi,
>>
>> Thanks for the report!
>>
>>> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
>>> timers with utilization update callbacks' with next-20160215. An example
>>> crash log and bisect results are attached below.
>>>
>>> Please let me know if there is anything I can do to help tracking down
>>> the problem.
>>
>> It looks like we've uncovered some nastiness in the arch ARM code (see below).
>>
>> [cut]
>>
>>> [    1.340000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
>>> [    1.340000] pgd = c0204000
>>> [    1.340000] [00000000] *pgd=00000000
>>> [    1.340000] Internal error: Oops: 80000005 [#1] SMP ARM
>>> [    1.340000] Modules linked in:
>>> [    1.340000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4-next-20160215 #1
>>> [    1.340000] Hardware name: Generic OMAP3-GP (Flattened Device Tree)
>>> [    1.340000] task: cb060000 ti: cb05a000 task.ti: cb05a000
>>> [    1.340000] PC is at 0x0
>>> [    1.340000] LR is at arch_send_call_function_single_ipi+0x34/0x38
>>
>> Since this is ARM, arch_send_call_function_single_ipi() looks like this:
>>
>> void arch_send_call_function_single_ipi(int cpu)
>> {
>>           smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
>> }
>>
>> so I'm not sure how the NULL pointer deref is possible even.
>>
>> The only thing coming to mind would be that cpumask_of(cpu) triggers
>> this, but I'm not sure how exactly that can happen.
>>
>> I need help from somebody who knows how this low-level stuff works on ARM.
>
> That's not even an SMP machine? I suspect a bunch of out of the
> 65 boot failures here are related to this:
>
> https://kernelci.org/boot/all/job/next/kernel/next-20160215/
>
> The SMP ones seem to fail with some regulator issues?
>

There is another problem, introduced with 6a0712f6f199e ("PM / OPP: Add
dev_pm_opp_set_rate()"). The kernelci boot log for next-20160212:omap3-overo-tobi
and others experience that problem.

Essentially, the code now assumes that a CPU clock always has a voltage
regulator attached to it, which is not correct. I sent out a patch to fix
that problem a minute ago.

Guenter



From tony at atomide.com  Mon Feb 15 11:42:27 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 15 Feb 2016 11:42:27 -0800
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor:
 Replace timers with utilization ...'
In-Reply-To: <1508162.Id3YElPxB2@vostro.rjw.lan>
References: <20160215170527.GA24453@roeck-us.net> <56C22105.6050900@arm.com>
 <CAJZ5v0gXGzzJ7CcbgNNO-ULrtd9Z2hbqHeuXRYJLFLrh+BWVWA@mail.gmail.com>
 <1508162.Id3YElPxB2@vostro.rjw.lan>
Message-ID: <20160215194227.GY19432@atomide.com>

* Rafael J. Wysocki <rjw at rjwysocki.net> [160215 11:28]:
> 
> Guenter, Tony,
> 
> Below is a patch to try, on top of linux-next.

Fixes the issue on UP for me:

Tested-by: Tony Lindgren <tony at atomide.com>

> Please let me know if the problem is still around with that patch applied.

It seems we still have another issue with SMP systems, see below.

Regards,

Tony

8< ------------------
Unable to handle kernel NULL pointer dereference at virtual address 00000030
pgd = c0204000
[00000030] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4-next-20160215-00002-g08cd608 #895
Hardware name: Generic OMAP4 (Flattened Device Tree)
task: ee870000 ti: ee85e000 task.ti: ee85e000
PC is at regulator_set_voltage+0x10/0x54
LR is at _set_opp_voltage+0x30/0x98
pc : [<c0684270>]    lr : [<c0774900>]    psr: 00000113
sp : ee85fb20  ip : 00000001  fp : 000fa3e8
r10: 000fa3e8  r9 : 000fa3e8  r8 : 00000000
r7 : ef7ab050  r6 : 000fa3e8  r5 : 000fa3e8  r4 : 00000000
r3 : 000fa3e8  r2 : 000fa3e8  r1 : 000fa3e8  r0 : 00000000
Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 8020404a  DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xee85e220)
Stack: (0xee85fb20 to 0xee860000)
fb20: 00000000 000fa3e8 000fa3e8 c0774900 eedc8500 11e1a300 00000000 11e1a300
fb40: ef7ab050 eedc8500 00000000 ef7ab050 eedc8540 c0775488 000fa3e8 00000000
fb60: 00000000 00124f80 00124f80 00124f80 11e1a300 23c34600 00000000 00000000
fb80: eea82e00 c144e250 eedc86c0 00000000 00000000 00000000 00000000 c096d8ec
fba0: ee85fbac ee85fbf8 00000001 00000000 00000010 000927c0 000493e0 00000021
fbc0: 00000010 00000000 c13bc9c4 c1302574 ef7bc598 0000001e eea82e00 c0971684
fbe0: 000927c0 eedc87c0 c1211598 00000000 c120d300 c1302670 001ef19f 00000000
fc00: c1302574 00000000 eea82e00 00000003 eedcbe04 c144e250 00000010 eea82eb4
fc20: c1302574 c0971ab0 c144e250 eea82e00 eea82e00 00000001 00000000 c144e250
fc40: 00000010 eea82e00 00000000 00000003 c13bc750 c144e250 00000010 eea82eb4
fc60: c1302574 c096eb20 eea82e00 00000000 eea82e08 c096f344 eedcca00 00000003
fc80: 0000ffff 00000003 00000000 00000000 eedc8440 000f6180 000493e0 000493e0
fca0: 000493e0 000f6180 000927c0 00000000 00000000 00000000 00000000 c13bc9c4
fcc0: 00000000 00000000 00000000 00000000 00000000 00000000 ffffffe0 eea82e60
fce0: eea82e60 c096f188 000493e0 000f6180 eedc86c0 c13bc750 c13bc750 eedc8700
fd00: eea82e84 eea82e84 ee9357c0 00000000 c13bc7d0 eedcc4b0 00000001 00000003
fd20: 00000000 00000000 eea82eac eea82eac ffff0001 eea82eb8 eea82eb8 00000000
fd40: 00000000 ee870000 00000000 00000000 00000000 eea82ed8 eea82ed8 00000000
fd60: eedc8780 eedc8680 eea82e00 c096fa00 00000001 60000113 eea82e04 00000000
fd80: ee85fdac c13bc7a4 c139e468 c13bc750 fffffdfb 00000000 00000000 00000000
fda0: 00000000 c0764dd0 c144e904 ee82fc5c ee99e4b4 00000000 c1334208 c13bcb30
fdc0: c144e250 c096e690 eedc8440 ef7ab050 eee32200 c0972368 eee32210 eee32210
fde0: c13bcae8 c0767e5c eee32210 c1449eac c1449eb4 c13bcae8 00000000 c07666c0
fe00: 00000000 ee85fe38 c07667fc 00000001 c1449e88 00000000 00000000 c0764ab4
fe20: ee82fb70 eedf3338 eee32210 eee32244 c139e3e8 c07663cc eee32210 00000001
fe40: eee32218 eee32218 eee32210 c139e3e8 00000000 c07658ac eee32218 eee32210
fe60: c139e260 c0763bfc c120ce1c c058e688 ee85fec0 eee32200 00000000 eee32200
fe80: eee32210 c1103670 00000000 c120ce1c 0000011a c0767bbc ee85fec0 eee32200
fea0: eedc8340 c1103670 00000000 c07685a8 c144e908 c1306810 eedc8340 c11122e0
fec0: 00000000 00000000 c0ec230c 00000000 00000000 00000000 00000000 00000000
fee0: 00000000 00000000 00000000 00000000 c1306810 c110f738 c1306810 c110fc30
ff00: c1306810 c1103690 c1306810 c0301d5c 00000000 c0463578 00000000 ee842b80
ff20: 00000000 c13356dc efffc0bf 0000011a c0c1d73c c035aac0 00000000 c0ebc080
ff40: c10095f8 00000000 00000007 00000007 c13356c4 00000007 c140a000 c140a000
ff60: 00000007 c140a000 c140a000 c11a1838 c11a183c c1100e14 00000007 00000007
ff80: 00000000 c1100594 00000000 c0b26878 00000000 00000000 00000000 00000000
ffa0: 00000000 c0b26880 00000000 c0307d78 00000000 00000000 00000000 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 a1718b7d a59ff7d9
[<c0684270>] (regulator_set_voltage) from [<c0774900>] (_set_opp_voltage+0x30/0x98)
[<c0774900>] (_set_opp_voltage) from [<c0775488>] (dev_pm_opp_set_rate+0x170/0x28c)
[<c0775488>] (dev_pm_opp_set_rate) from [<c096d8ec>] (__cpufreq_driver_target+0x180/0x2b4)
[<c096d8ec>] (__cpufreq_driver_target) from [<c0971684>] (dbs_check_cpu+0x19c/0x1d0)
[<c0971684>] (dbs_check_cpu) from [<c0971ab0>] (cpufreq_governor_dbs+0x274/0x620)
[<c0971ab0>] (cpufreq_governor_dbs) from [<c096eb20>] (__cpufreq_governor+0xf0/0x1a4)
[<c096eb20>] (__cpufreq_governor) from [<c096f344>] (cpufreq_init_policy+0x64/0x8c)
[<c096f344>] (cpufreq_init_policy) from [<c096fa00>] (cpufreq_online+0x2f8/0x714)
[<c096fa00>] (cpufreq_online) from [<c0764dd0>] (subsys_interface_register+0x94/0xd8)
[<c0764dd0>] (subsys_interface_register) from [<c096e690>] (cpufreq_register_driver+0x14c/0x19c)
[<c096e690>] (cpufreq_register_driver) from [<c0972368>] (dt_cpufreq_probe+0x70/0xec)
[<c0972368>] (dt_cpufreq_probe) from [<c0767e5c>] (platform_drv_probe+0x4c/0xb0)
[<c0767e5c>] (platform_drv_probe) from [<c07666c0>] (driver_probe_device+0x214/0x2c0)
[<c07666c0>] (driver_probe_device) from [<c0764ab4>] (bus_for_each_drv+0x60/0x94)
[<c0764ab4>] (bus_for_each_drv) from [<c07663cc>] (__device_attach+0xb0/0x114)
[<c07663cc>] (__device_attach) from [<c07658ac>] (bus_probe_device+0x84/0x8c)
[<c07658ac>] (bus_probe_device) from [<c0763bfc>] (device_add+0x370/0x56c)
[<c0763bfc>] (device_add) from [<c0767bbc>] (platform_device_add+0xfc/0x224)
[<c0767bbc>] (platform_device_add) from [<c07685a8>] (platform_device_register_full+0xf8/0x120)
[<c07685a8>] (platform_device_register_full) from [<c11122e0>] (omap2_common_pm_late_init+0x108/0x114)
[<c11122e0>] (omap2_common_pm_late_init) from [<c110f738>] (omap_common_late_init+0xc/0x14)
[<c110f738>] (omap_common_late_init) from [<c110fc30>] (dra7xx_init_late+0x8/0x14)
[<c110fc30>] (dra7xx_init_late) from [<c1103690>] (init_machine_late+0x20/0x98)
[<c1103690>] (init_machine_late) from [<c0301d5c>] (do_one_initcall+0x90/0x1d8)
[<c0301d5c>] (do_one_initcall) from [<c1100e14>] (kernel_init_freeable+0x15c/0x1fc)
[<c1100e14>] (kernel_init_freeable) from [<c0b26880>] (kernel_init+0x8/0xf0)
[<c0b26880>] (kernel_init) from [<c0307d78>] (ret_from_fork+0x14/0x3c)
Code: e92d4070 e1a04000 e1a05001 e1a06002 (e5900030) 
---[ end trace d0b8b8949b1b4202 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D         4.5.0-rc4-next-20160215-00002-g08cd608 #895
Hardware name: Generic OMAP4 (Flattened Device Tree)
[<c0310290>] (unwind_backtrace) from [<c030b98c>] (show_stack+0x10/0x14)
[<c030b98c>] (show_stack) from [<c058c174>] (dump_stack+0x90/0xa4)
[<c058c174>] (dump_stack) from [<c030ea58>] (handle_IPI+0x174/0x194)
[<c030ea58>] (handle_IPI) from [<c030175c>] (gic_handle_irq+0x90/0x94)
[<c030175c>] (gic_handle_irq) from [<c030c4d4>] (__irq_svc+0x54/0x70)
Exception stack(0xee895eb0 to 0xee895ef8)
5ea0:                                     00200040 c140cb80 00000001 00000000
5ec0: 00000082 00000000 ee894000 00000001 c1302080 fa241100 ee895fe0 c1302504
5ee0: 00000001 ee895f00 c0344a8c c0344668 60000113 ffffffff
[<c030c4d4>] (__irq_svc) from [<c0344668>] (__do_softirq+0x90/0x214)
[<c0344668>] (__do_softirq) from [<c0344a8c>] (irq_exit+0xb0/0x118)
[<c0344a8c>] (irq_exit) from [<c0382f88>] (__handle_domain_irq+0x60/0xb4)
[<c0382f88>] (__handle_domain_irq) from [<c0301720>] (gic_handle_irq+0x54/0x94)
[<c0301720>] (gic_handle_irq) from [<c030c4d4>] (__irq_svc+0x54/0x70)
Exception stack(0xee895f88 to 0xee895fd0)
5f80:                   00000001 00000000 00000000 c031af20 ee894000 c13024a4
5fa0: 00000000 00000000 c120d3a8 c12115d8 ee895fe0 c1302504 00000000 ee895fd8
5fc0: c030878c c0308790 60000113 ffffffff
[<c030c4d4>] (__irq_svc) from [<c0308790>] (arch_cpu_idle+0x38/0x3c)
[<c0308790>] (arch_cpu_idle) from [<c0377808>] (cpu_startup_entry+0x1e4/0x240)
[<c0377808>] (cpu_startup_entry) from [<80301b6c>] (0x80301b6c)
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b



From linux at roeck-us.net  Mon Feb 15 11:46:27 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 15 Feb 2016 11:46:27 -0800
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor:
 Replace timers with utilization ...'
In-Reply-To: <20160215194227.GY19432@atomide.com>
References: <20160215170527.GA24453@roeck-us.net> <56C22105.6050900@arm.com>
 <CAJZ5v0gXGzzJ7CcbgNNO-ULrtd9Z2hbqHeuXRYJLFLrh+BWVWA@mail.gmail.com>
 <1508162.Id3YElPxB2@vostro.rjw.lan>
 <20160215194227.GY19432@atomide.com>
Message-ID: <20160215194627.GA25882@roeck-us.net>

On Mon, Feb 15, 2016 at 11:42:27AM -0800, Tony Lindgren wrote:
> * Rafael J. Wysocki <rjw at rjwysocki.net> [160215 11:28]:
> > 
> > Guenter, Tony,
> > 
> > Below is a patch to try, on top of linux-next.
> 
> Fixes the issue on UP for me:
> 
> Tested-by: Tony Lindgren <tony at atomide.com>
> 
> > Please let me know if the problem is still around with that patch applied.
> 
> It seems we still have another issue with SMP systems, see below.
> 
Try https://patchwork.kernel.org/patch/8318221

Guenter


From alexandre.belloni at free-electrons.com  Mon Feb 15 11:47:40 2016
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Mon, 15 Feb 2016 20:47:40 +0100
Subject: [PATCH] drivers: power: reset: at91-reset: Provide reset reason
 via sysfs (amended with Signed-off-by tag)
In-Reply-To: <20160127071418.GA7124@earth>
References: <1453394936-16616-1-git-send-email-davidm@egauge.net>
 <20160125085539.GB16261@piout.net> <20160127071418.GA7124@earth>
Message-ID: <20160215194740.GD15219@piout.net>

On 27/01/2016 at 08:14:21 +0100, Sebastian Reichel wrote :
> I can see, that there are currently six different values possible
> for at91-reset, but it's unclear to me what some of them mean, so
> that should be covered in the ABI documentation. Also it may make
> sense to drop the reset suffix for some of them (e.g. "unknown").
> 
>     reason = "general reset";
> 
>     This is power-on by power-button/applying voltage?
> 

Yes

>     reason = "wakeup";
> 
>     This is power-on by RTC?
> 

This can actually be any wakeup, but most likely RTC but it could also
be triggered by an external PMIC. Atmel's definition is general: both
VDDcore and VDDbu are rising, wakeup: only VDDcore is rising

>     reason = "watchdog reset";
> 
>     I gues this is reboot triggered by watchdog timeout?
> 

Yes

>     reason = "software reset";
> 
>     This will be returned if system was started by rebooting via
>     "reboot / shutdown -r"?
> 

This will be the case yes

>     reason = "user reset";
> 
>     This is returned if the board's reset button was pressed?
> 

Reset button or any signal on the reset pin of the SoC


>     reason = "unknown reset";
> 
>     => just use "unknown"
> 

It should not happen anyway :)

> I suggest to create include/linux/power/power_on_reason.h, with
> standardized values, that are used by the driver:
> 
> #define POWER_ON_REASON_RTC "RTC wakeup"
> #define POWER_ON_REASON_WATCHDOG "watchdog timeout"
> ...
> 


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From will.deacon at arm.com  Mon Feb 15 11:55:29 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Feb 2016 19:55:29 +0000
Subject: [PATCH v3 4/5] arm64/perf: Enable PMCR long cycle counter bit
In-Reply-To: <de7340e1843f7823384551db64b12eadde7eded7.1454516082.git.jglauber@cavium.com>
References: <cover.1454516082.git.jglauber@cavium.com>
 <de7340e1843f7823384551db64b12eadde7eded7.1454516082.git.jglauber@cavium.com>
Message-ID: <20160215195529.GW6298@arm.com>

On Wed, Feb 03, 2016 at 06:11:59PM +0100, Jan Glauber wrote:
> With the long cycle counter bit (LC) disabled the cycle counter is not
> working on ThunderX SOC (ThunderX only implements Aarch64).
> Also, according to documentation LC == 0 is deprecated.
> 
> To keep the code simple the patch does not introduce 64 bit wide counter
> functions. Instead writing the cycle counter always sets the upper
> 32 bits so overflow interrupts are generated as before.

I guess we could look into chained events if we wanted to go the whole
hog and support 64-bit counters, but this looks fine for now.

> Original patch from Andrew Pinksi <Andrew.Pinksi at caviumnetworks.com>
> 
> Signed-off-by: Jan Glauber <jglauber at cavium.com>
> ---
>  arch/arm64/kernel/perf_event.c | 21 ++++++++++++++++-----
>  1 file changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index c038e4e..5e4275e 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -405,6 +405,7 @@ static const struct attribute_group *armv8_pmuv3_attr_groups[] = {
>  #define ARMV8_PMCR_D		(1 << 3) /* CCNT counts every 64th cpu cycle */
>  #define ARMV8_PMCR_X		(1 << 4) /* Export to ETM */
>  #define ARMV8_PMCR_DP		(1 << 5) /* Disable CCNT if non-invasive debug*/
> +#define ARMV8_PMCR_LC		(1 << 6) /* Overflow on 64 bit cycle counter */
>  #define	ARMV8_PMCR_N_SHIFT	11	 /* Number of counters supported */
>  #define	ARMV8_PMCR_N_MASK	0x1f
>  #define	ARMV8_PMCR_MASK		0x3f	 /* Mask for writable bits */
> @@ -494,9 +495,16 @@ static inline void armv8pmu_write_counter(struct perf_event *event, u32 value)
>  	if (!armv8pmu_counter_valid(cpu_pmu, idx))
>  		pr_err("CPU%u writing wrong counter %d\n",
>  			smp_processor_id(), idx);
> -	else if (idx == ARMV8_IDX_CYCLE_COUNTER)
> -		asm volatile("msr pmccntr_el0, %0" :: "r" (value));
> -	else if (armv8pmu_select_counter(idx) == idx)
> +	else if (idx == ARMV8_IDX_CYCLE_COUNTER) {
> +		/*
> +		 * Set the upper 32bits as this is a 64bit counter but we only
> +		 * count using the lower 32bits and we want an interrupt when
> +		 * it overflows.
> +		 */
> +		u64 value64 = 0xffffffff00000000ULL | value;
> +
> +		asm volatile("msr pmccntr_el0, %0" :: "r" (value64));
> +	} else if (armv8pmu_select_counter(idx) == idx)
>  		asm volatile("msr pmxevcntr_el0, %0" :: "r" (value));
>  }
>  
> @@ -768,8 +776,11 @@ static void armv8pmu_reset(void *info)
>  		armv8pmu_disable_intens(idx);
>  	}
>  
> -	/* Initialize & Reset PMNC: C and P bits. */
> -	armv8pmu_pmcr_write(ARMV8_PMCR_P | ARMV8_PMCR_C);
> +	/*
> +	 * Initialize & Reset PMNC. Request overflow on 64 bit but
> +	 * cheat in armv8pmu_write_counter().

Can you expand the comment to mention that the 64-bit overflow is only
for the cycle counter, please?

Will


From tony at atomide.com  Mon Feb 15 11:57:53 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 15 Feb 2016 11:57:53 -0800
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor:
 Replace timers with utilization ...'
In-Reply-To: <20160215194627.GA25882@roeck-us.net>
References: <20160215170527.GA24453@roeck-us.net> <56C22105.6050900@arm.com>
 <CAJZ5v0gXGzzJ7CcbgNNO-ULrtd9Z2hbqHeuXRYJLFLrh+BWVWA@mail.gmail.com>
 <1508162.Id3YElPxB2@vostro.rjw.lan>
 <20160215194227.GY19432@atomide.com>
 <20160215194627.GA25882@roeck-us.net>
Message-ID: <20160215195752.GZ19432@atomide.com>

* Guenter Roeck <linux at roeck-us.net> [160215 11:47]:
> On Mon, Feb 15, 2016 at 11:42:27AM -0800, Tony Lindgren wrote:
> > * Rafael J. Wysocki <rjw at rjwysocki.net> [160215 11:28]:
> > > 
> > > Guenter, Tony,
> > > 
> > > Below is a patch to try, on top of linux-next.
> > 
> > Fixes the issue on UP for me:
> > 
> > Tested-by: Tony Lindgren <tony at atomide.com>
> > 
> > > Please let me know if the problem is still around with that patch applied.
> > 
> > It seems we still have another issue with SMP systems, see below.
> > 
> Try https://patchwork.kernel.org/patch/8318221

Great, that one fixes the SMP issue for me. So for patchwork
patch 8318221, here's a cross thread tested-by as looks like
I was not on Cc for it:

Tested-by: Tony Lindgren <tony at atomide.com>


From tony at atomide.com  Mon Feb 15 11:58:40 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 15 Feb 2016 11:58:40 -0800
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor:
 Replace timers with utilization ...'
In-Reply-To: <56C229A5.8020901@roeck-us.net>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
 <20160215190116.GX19432@atomide.com>
 <56C229A5.8020901@roeck-us.net>
Message-ID: <20160215195839.GA19432@atomide.com>

* Guenter Roeck <linux at roeck-us.net> [160215 11:41]:
> On 02/15/2016 11:01 AM, Tony Lindgren wrote:
> >
> >https://kernelci.org/boot/all/job/next/kernel/next-20160215/
> >
> >The SMP ones seem to fail with some regulator issues?
> >
> 
> There is another problem, introduced with 6a0712f6f199e ("PM / OPP: Add
> dev_pm_opp_set_rate()"). The kernelci boot log for next-20160212:omap3-overo-tobi
> and others experience that problem.
> 
> Essentially, the code now assumes that a CPU clock always has a voltage
> regulator attached to it, which is not correct. I sent out a patch to fix
> that problem a minute ago.

Yes that fixed it thanks.

Tony


From will.deacon at arm.com  Mon Feb 15 12:04:04 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Feb 2016 20:04:04 +0000
Subject: [PATCH v3 5/5] arm64/perf: Extend event mask for ARMv8.1
In-Reply-To: <fa91eaedf581e6a7053899f25b1b08458dbd4b8e.1454516082.git.jglauber@cavium.com>
References: <cover.1454516082.git.jglauber@cavium.com>
 <fa91eaedf581e6a7053899f25b1b08458dbd4b8e.1454516082.git.jglauber@cavium.com>
Message-ID: <20160215200404.GX6298@arm.com>

On Wed, Feb 03, 2016 at 06:12:00PM +0100, Jan Glauber wrote:
> ARMv8.1 increases the PMU event number space. Detect the
> presence of this PMUv3 type and extend the event mask.
> 
> The event mask is moved to struct arm_pmu so different event masks
> can exist, depending on the PMU type.
> 
> Signed-off-by: Jan Glauber <jglauber at cavium.com>
> ---
>  arch/arm/kernel/perf_event_v6.c     |  6 ++++--
>  arch/arm/kernel/perf_event_v7.c     | 29 +++++++++++++++++++----------
>  arch/arm/kernel/perf_event_xscale.c |  4 +++-
>  arch/arm64/kernel/perf_event.c      | 33 +++++++++++++++++++--------------
>  drivers/perf/arm_pmu.c              |  5 +++--
>  include/linux/perf/arm_pmu.h        |  4 ++--
>  6 files changed, 50 insertions(+), 31 deletions(-)

[...]

>  static void armv8_pmu_init(struct arm_pmu *cpu_pmu)
>  {
> +	u64 id;
> +
>  	cpu_pmu->handle_irq		= armv8pmu_handle_irq,
>  	cpu_pmu->enable			= armv8pmu_enable_event,
>  	cpu_pmu->disable		= armv8pmu_disable_event,
> @@ -842,6 +840,13 @@ static void armv8_pmu_init(struct arm_pmu *cpu_pmu)
>  	cpu_pmu->reset			= armv8pmu_reset,
>  	cpu_pmu->max_period		= (1LLU << 32) - 1,
>  	cpu_pmu->set_event_filter	= armv8pmu_set_event_filter;
> +
> +	/* detect ARMv8.1 PMUv3 with extended event mask */
> +	id = read_cpuid(ID_AA64DFR0_EL1);
> +	if (((id >> 8) & 0xf) == 4)

We have helpers for this stuff (cpuid_feature_extract_field)...

> +		cpu_pmu->event_mask = 0xffff;	/* ARMv8.1 extended events */
> +	else
> +		cpu_pmu->event_mask = ARMV8_EVTYPE_EVENT;

... although can't we just update ARMV8_EVTYPE_EVENT to be 0xffff now?
AFAICT, that just eats into bits that used to be RES0, so we shouldn't
see any problems. That should make your patch *much* simpler!

Will


From will.deacon at arm.com  Mon Feb 15 12:06:13 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 15 Feb 2016 20:06:13 +0000
Subject: [PATCH v3 1/5] arm64/perf: Rename Cortex A57 events
In-Reply-To: <20160215194037.GU6298@arm.com>
References: <cover.1454516082.git.jglauber@cavium.com>
 <e0ecaaaffb64cc0b2ecfd8852f718a3f1d642b5c.1454516082.git.jglauber@cavium.com>
 <20160215194037.GU6298@arm.com>
Message-ID: <20160215200613.GY6298@arm.com>

On Mon, Feb 15, 2016 at 07:40:37PM +0000, Will Deacon wrote:
> On Wed, Feb 03, 2016 at 06:11:56PM +0100, Jan Glauber wrote:
> > The implemented Cortex A57 events are not A57 specific.
> > They are recommended by ARM and can be found on other
> > ARMv8 SOCs like Cavium ThunderX too. Therefore move
> > these events to the common PMUv3 table.
> 
> I can't find anything in the architecture that suggests these event
> numbers are necessarily portable between implementations. Am I missing
> something?

Aha, I just noticed appendix K3.1 (silly me for missing it...).

Lemme check whether or not that mandates that those encodings can't be
used for wildly different things.

Will


From linux at roeck-us.net  Mon Feb 15 12:09:44 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 15 Feb 2016 12:09:44 -0800
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <20160215195839.GA19432@atomide.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
 <20160215190116.GX19432@atomide.com> <56C229A5.8020901@roeck-us.net>
 <20160215195839.GA19432@atomide.com>
Message-ID: <56C23088.8050400@roeck-us.net>

On 02/15/2016 11:58 AM, Tony Lindgren wrote:
> * Guenter Roeck <linux at roeck-us.net> [160215 11:41]:
>> On 02/15/2016 11:01 AM, Tony Lindgren wrote:
>>>
>>> https://kernelci.org/boot/all/job/next/kernel/next-20160215/
>>>
>>> The SMP ones seem to fail with some regulator issues?
>>>
>>
>> There is another problem, introduced with 6a0712f6f199e ("PM / OPP: Add
>> dev_pm_opp_set_rate()"). The kernelci boot log for next-20160212:omap3-overo-tobi
>> and others experience that problem.
>>
>> Essentially, the code now assumes that a CPU clock always has a voltage
>> regulator attached to it, which is not correct. I sent out a patch to fix
>> that problem a minute ago.
>
> Yes that fixed it thanks.
>

Confirmed. With this patch plus mine, all arm qemu tests are again passing for me.

Thanks,
Guenter



From aford173 at gmail.com  Mon Feb 15 12:24:17 2016
From: aford173 at gmail.com (Adam Ford)
Date: Mon, 15 Feb 2016 14:24:17 -0600
Subject: [PATCH 1/4] pwm: omap-dmtimer: fix inaccurate period/duty_cycle
 calculation
In-Reply-To: <56B1D52F.70907@baylibre.com>
References: <1454128014-22866-1-git-send-email-drivshin.allworx@gmail.com>
 <1454128014-22866-2-git-send-email-drivshin.allworx@gmail.com>
 <56B1D52F.70907@baylibre.com>
Message-ID: <CAHCN7xKfn_o_EmQb3zG5-d3P9vxyLp=MX_R7ATT6pzMrS1cJDQ@mail.gmail.com>

I tested this on a DM3730, Timer 10

Tested-by: Adam Ford <aford173 at gmail.com>

On Wed, Feb 3, 2016 at 4:23 AM, Neil Armstrong <narmstrong at baylibre.com> wrote:
> On 01/30/2016 05:26 AM, David Rivshin (Allworx) wrote:
>> From: David Rivshin <drivshin at allworx.com>
>>
>> Fix the calculation of load_value and match_value. Currently they
>> are slightly too low, which produces a noticeably wrong PWM rate with
>> sufficiently short periods (i.e. when 1/period approaches clk_rate/2).
>>
>> Example:
>>  clk_rate=32768Hz, period=122070ns, duty_cycle=61035ns (8192Hz/50% PWM)
>>  Correct values: load = 0xfffffffc, match = 0xfffffffd
>>  Current values: load = 0xfffffffa, match = 0xfffffffc
>>  effective PWM: period=183105ns, duty_cycle=91553ns (5461Hz/50% PWM)
>>
>> Fixes: 6604c6556db9 ("pwm: Add PWM driver for OMAP using dual-mode timers")
>> Signed-off-by: David Rivshin <drivshin at allworx.com>
>
> OK for me.
>
> Acked-by: Neil Armstrong <narmstrong at baylibre.com>
>
> Thanks !
>
>> ---
>>  drivers/pwm/pwm-omap-dmtimer.c | 27 ++++++++++++++++++++-------
>>  1 file changed, 20 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
>> index 826634e..0083e75 100644
>> --- a/drivers/pwm/pwm-omap-dmtimer.c
>> +++ b/drivers/pwm/pwm-omap-dmtimer.c
>> @@ -31,6 +31,7 @@
>>  #include <linux/time.h>
>>
>>  #define DM_TIMER_LOAD_MIN 0xfffffffe
>> +#define DM_TIMER_MAX      0xffffffff
>>
>>  struct pwm_omap_dmtimer_chip {
>>       struct pwm_chip chip;
>> @@ -46,13 +47,13 @@ to_pwm_omap_dmtimer_chip(struct pwm_chip *chip)
>>       return container_of(chip, struct pwm_omap_dmtimer_chip, chip);
>>  }
>>
>> -static int pwm_omap_dmtimer_calc_value(unsigned long clk_rate, int ns)
>> +static u32 pwm_omap_dmtimer_get_clock_cycles(unsigned long clk_rate, int ns)
>>  {
>>       u64 c = (u64)clk_rate * ns;
>>
>>       do_div(c, NSEC_PER_SEC);
>>
>> -     return DM_TIMER_LOAD_MIN - c;
>> +     return c;
>>  }
>>
>>  static void pwm_omap_dmtimer_start(struct pwm_omap_dmtimer_chip *omap)
>> @@ -99,7 +100,8 @@ static int pwm_omap_dmtimer_config(struct pwm_chip *chip,
>>                                  int duty_ns, int period_ns)
>>  {
>>       struct pwm_omap_dmtimer_chip *omap = to_pwm_omap_dmtimer_chip(chip);
>> -     int load_value, match_value;
>> +     u32 period_cycles, duty_cycles;
>> +     u32 load_value, match_value;
>>       struct clk *fclk;
>>       unsigned long clk_rate;
>>       bool timer_active;
>> @@ -133,11 +135,22 @@ static int pwm_omap_dmtimer_config(struct pwm_chip *chip,
>>       /*
>>        * Calculate the appropriate load and match values based on the
>>        * specified period and duty cycle. The load value determines the
>> -      * cycle time and the match value determines the duty cycle.
>> +      * period time and the match value determines the duty time.
>> +      *
>> +      * The period lasts for (DM_TIMER_MAX-load_value+1) clock cycles.
>> +      * Similarly, the active time lasts (match_value-load_value+1) cycles.
>> +      * The non-active time is the remainder: (DM_TIMER_MAX-match_value)
>> +      * clock cycles.
>> +      *
>> +      * References:
>> +      *   OMAP4430/60/70 TRM sections 22.2.4.10 and 22.2.4.11
>> +      *   AM335x Sitara TRM sections 20.1.3.5 and 20.1.3.6
>>        */
>> -     load_value = pwm_omap_dmtimer_calc_value(clk_rate, period_ns);
>> -     match_value = pwm_omap_dmtimer_calc_value(clk_rate,
>> -                                               period_ns - duty_ns);
>> +     period_cycles = pwm_omap_dmtimer_get_clock_cycles(clk_rate, period_ns);
>> +     duty_cycles = pwm_omap_dmtimer_get_clock_cycles(clk_rate, duty_ns);
>> +
>> +     load_value = (DM_TIMER_MAX - period_cycles) + 1;
>> +     match_value = load_value + duty_cycles - 1;
>>
>>       /*
>>        * We MUST stop the associated dual-mode timer before attempting to
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From rostedt at goodmis.org  Mon Feb 15 12:26:39 2016
From: rostedt at goodmis.org (Steven Rostedt)
Date: Mon, 15 Feb 2016 15:26:39 -0500
Subject: [PATCH] branch tracer: fix freak link error
In-Reply-To: <2535125.MjntUgx4sh@wuerfel>
References: <1455312410-1058841-1-git-send-email-arnd@arndb.de>
 <20160215124746.44e8c2d0@gandalf.local.home>
 <2535125.MjntUgx4sh@wuerfel>
Message-ID: <20160215152639.7795795c@gandalf.local.home>

On Mon, 15 Feb 2016 21:15:39 +0100
Arnd Bergmann <arnd at arndb.de> wrote:

> Do you also want to add a 'Cc: stable at vger.kernel.org' tag?
> 

I currently have this in the Tags:

    Acked-by: Nicolas Pitre <nico at linaro.org>
    Fixes: ab3c9c686e22 ("branch tracer, intel-iommu: fix build with CONFIG_BRANCH_TRACER=y")
    Cc: stable at vger.kernel.org # v2.6.30+
    Signed-off-by: Arnd Bergmann <arnd at arndb.de>
    Signed-off-by: Steven Rostedt <rostedt at goodmis.org>

-- Steve



From robert.jarzmik at free.fr  Mon Feb 15 12:27:44 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Mon, 15 Feb 2016 21:27:44 +0100
Subject: [PATCH v2 1/4] dma: mmp_pdma: Add the #dma-requests DT property
 documentation
Message-ID: <1455568067-20203-1-git-send-email-robert.jarzmik@free.fr>

For pxa based platforms, the number of requestor lines should be
specified, so that the driver can check if the flow control should be
activated (when a requestor line is asked for) or not.

Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
Since v1: rename of property to #dma-requests
      	  modify default value to 32 as suggested by Vinod
---
 Documentation/devicetree/bindings/dma/mmp-dma.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/mmp-dma.txt b/Documentation/devicetree/bindings/dma/mmp-dma.txt
index 7a802f64e5bd..8f7364a7b349 100644
--- a/Documentation/devicetree/bindings/dma/mmp-dma.txt
+++ b/Documentation/devicetree/bindings/dma/mmp-dma.txt
@@ -12,6 +12,8 @@ Required properties:
 Optional properties:
 - #dma-channels: Number of DMA channels supported by the controller (defaults
   to 32 when not specified)
+- #dma-requests: Number of DMA requestor lines supported by the controller
+  (defaults to 32 when not specified)
 
 "marvell,pdma-1.0"
 Used platforms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688.
-- 
2.1.4



From paulmck at linux.vnet.ibm.com  Mon Feb 15 12:35:12 2016
From: paulmck at linux.vnet.ibm.com (Paul E. McKenney)
Date: Mon, 15 Feb 2016 12:35:12 -0800
Subject: Writes, smp_wmb(), and transitivity?
In-Reply-To: <20160215185832.GQ6298@arm.com>
References: <20160215175825.GA15878@linux.vnet.ibm.com>
 <20160215185832.GQ6298@arm.com>
Message-ID: <20160215203512.GL6719@linux.vnet.ibm.com>

On Mon, Feb 15, 2016 at 06:58:32PM +0000, Will Deacon wrote:
> On Mon, Feb 15, 2016 at 09:58:25AM -0800, Paul E. McKenney wrote:
> > Hello!
> 
> Hi Paul,
> 
> > Some architectures provide local transitivity for a chain of threads doing
> > writes separated by smp_wmb(), as exemplified by the litmus tests below.
> > The pattern is that each thread writes to a its own variable, does an
> > smp_wmb(), then writes a different value to the next thread's variable.
> > 
> > I don't know of a use of this, but if everyone supports it, it might
> > be good to mandate it.  Status quo is that smp_wmb() is non-transitive,
> > so it currently isn't supported.
> > 
> > Anyone know of any architectures that do -not- support this?
> > 
> > Assuming all architectures -do- support this, any arguments -against-
> > officially supporting it in Linux?
> > 
> > 							Thanx, Paul
> > 
> > ------------------------------------------------------------------------
> > 
> > Two threads:
> > 
> > 	int a, b;
> > 
> > 	void thread0(void)
> > 	{
> > 		WRITE_ONCE(a, 1);
> > 		smp_wmb();
> > 		WRITE_ONCE(b, 2);
> > 	}
> > 
> > 	void thread1(void)
> > 	{
> > 		WRITE_ONCE(b, 1);
> > 		smp_wmb();
> > 		WRITE_ONCE(a, 2);
> > 	}
> > 
> > 	/* After all threads have completed and the dust has settled... */
> > 
> > 	BUG_ON(a == 1 && b == 1);
> 
> My understanding is that this test, and the generalisation to n threads,
> is forbidden on ARM. However, the transitivity of DMB ST (used to
> construct smp_wmb()) has been the subject of long debates, because we
> allow the following test:
> 
> 
> P0:
> Wx = 1
> 
> P1:
> Rx == 1
> DMB ST
> Wy = 1
> 
> P2:
> Ry == 1
> <addr dep>
> Rx == 0
> 
> 
> so I'd be uneasy about saying "it's all transitive".

Agreed!  For one thing, doesn't DMB ST need writes on both sides?

But that is one reason that I am only semi-enthusiastic about this.
The potentially locally transitive case is -very- restrictive, applying
only to situations where -all- accesses are writes.

							Thanx, Paul



From rafael at kernel.org  Mon Feb 15 12:37:39 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 15 Feb 2016 21:37:39 +0100
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <20160215195839.GA19432@atomide.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
 <20160215190116.GX19432@atomide.com>
 <56C229A5.8020901@roeck-us.net>
 <20160215195839.GA19432@atomide.com>
Message-ID: <CAJZ5v0hzVB0+H4nuCun3mmrES3UQ3+Rs1uz5YGu5sv4G3XU+nQ@mail.gmail.com>

On Mon, Feb 15, 2016 at 8:58 PM, Tony Lindgren <tony at atomide.com> wrote:
> * Guenter Roeck <linux at roeck-us.net> [160215 11:41]:
>> On 02/15/2016 11:01 AM, Tony Lindgren wrote:
>> >
>> >https://kernelci.org/boot/all/job/next/kernel/next-20160215/
>> >
>> >The SMP ones seem to fail with some regulator issues?
>> >
>>
>> There is another problem, introduced with 6a0712f6f199e ("PM / OPP: Add
>> dev_pm_opp_set_rate()"). The kernelci boot log for next-20160212:omap3-overo-tobi
>> and others experience that problem.
>>
>> Essentially, the code now assumes that a CPU clock always has a voltage
>> regulator attached to it, which is not correct. I sent out a patch to fix
>> that problem a minute ago.
>
> Yes that fixed it thanks.

Can you please also check if this alternative fix from Viresh works:

https://patchwork.kernel.org/patch/8316611/

?

Thanks,
Rafael


From rafael at kernel.org  Mon Feb 15 12:38:25 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 15 Feb 2016 21:38:25 +0100
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <56C23088.8050400@roeck-us.net>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
 <20160215190116.GX19432@atomide.com>
 <56C229A5.8020901@roeck-us.net>
 <20160215195839.GA19432@atomide.com>
 <56C23088.8050400@roeck-us.net>
Message-ID: <CAJZ5v0hqVCXE0kDfr_4zLz_-c-4KJo8bJg8xVVc1Qd66eA+iHQ@mail.gmail.com>

On Mon, Feb 15, 2016 at 9:09 PM, Guenter Roeck <linux at roeck-us.net> wrote:
> On 02/15/2016 11:58 AM, Tony Lindgren wrote:
>>
>> * Guenter Roeck <linux at roeck-us.net> [160215 11:41]:
>>>
>>> On 02/15/2016 11:01 AM, Tony Lindgren wrote:
>>>>
>>>>
>>>> https://kernelci.org/boot/all/job/next/kernel/next-20160215/
>>>>
>>>> The SMP ones seem to fail with some regulator issues?
>>>>
>>>
>>> There is another problem, introduced with 6a0712f6f199e ("PM / OPP: Add
>>> dev_pm_opp_set_rate()"). The kernelci boot log for
>>> next-20160212:omap3-overo-tobi
>>> and others experience that problem.
>>>
>>> Essentially, the code now assumes that a CPU clock always has a voltage
>>> regulator attached to it, which is not correct. I sent out a patch to fix
>>> that problem a minute ago.
>>
>>
>> Yes that fixed it thanks.
>>
>
> Confirmed. With this patch plus mine, all arm qemu tests are again passing
> for me.

OK, I'll add it to the governor changes branch.

Thanks,
Rafael


From geert+renesas at glider.be  Mon Feb 15 12:38:32 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 21:38:32 +0100
Subject: [PATCH v3 4/7] ARM: dts: r8a7793: Add L2 cache-controller node
In-Reply-To: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
References: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455568715-20880-5-git-send-email-geert+renesas@glider.be>

Add a device node for the L2 cache, and link the CPU node to it.

The L2 cache for the Cortex-A15 CPU cores is 1 MiB large (organized as
64 KiB x 16 ways).

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v3:
  - Drop "arm,data-latency" and "arm,tag-latency" properties, as they
    may not be valid when using virtualization,
  - Change one-line summary prefix to match current arm-soc practices,

v2:
  - Drop (incorrect) optional cache-{size,sets,{block,line}-size}
    properties, as this information is auto-detected,
  - Integrate linking CPU to L2 cache into this patch,
  - Extracted from series "[PATCH/RFC 00/15] ARM: shmobile: R-Car: Add
    SYSC PM Domain DT Support".
---
 arch/arm/boot/dts/r8a7793.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 45dba1c79a43c287..9a30f650aa515b80 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -51,9 +51,16 @@
 					   < 937500 1000000>,
 					   < 750000 1000000>,
 					   < 375000 1000000>;
+			next-level-cache = <&L2_CA15>;
 		};
 	};
 
+	L2_CA15: cache-controller at 0 {
+		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
+	};
+
 	gic: interrupt-controller at f1001000 {
 		compatible = "arm,gic-400";
 		#interrupt-cells = <3>;
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 12:38:30 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 21:38:30 +0100
Subject: [PATCH v3 2/7] ARM: dts: r8a7790: Add L2 cache-controller nodes
In-Reply-To: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
References: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455568715-20880-3-git-send-email-geert+renesas@glider.be>

Add device nodes for the L2 caches, and link the CPU nodes to them.

The L2 cache for the Cortex-A15 CPU cores is 2 MiB large (organized as
128 KiB x 16 ways).

The L2 cache for the Cortex-A7 CPU cores is 512 KiB large (organized as
64 KiB x 8 ways).

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v3:
  - Drop "arm,data-latency" and "arm,tag-latency" properties, as they
    may not be valid when using virtualization,
  - Change one-line summary prefix to match current arm-soc practices,

v2:
  - Drop (incorrect) optional cache-{size,sets,{block,line}-size}
    properties, as this information is auto-detected,
  - Integrate linking CPUs to L2 caches into this patch,
  - Extracted from series "[PATCH/RFC 00/15] ARM: shmobile: R-Car: Add
    SYSC PM Domain DT Support".
---
 arch/arm/boot/dts/r8a7790.dtsi | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 76ddf5c6cca79c3c..e40aa6585831c520 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -52,6 +52,7 @@
 			voltage-tolerance = <1>; /* 1% */
 			clocks = <&cpg_clocks R8A7790_CLK_Z>;
 			clock-latency = <300000>; /* 300 us */
+			next-level-cache = <&L2_CA15>;
 
 			/* kHz - uV - OPPs unknown yet */
 			operating-points = <1400000 1000000>,
@@ -67,6 +68,7 @@
 			compatible = "arm,cortex-a15";
 			reg = <1>;
 			clock-frequency = <1300000000>;
+			next-level-cache = <&L2_CA15>;
 		};
 
 		cpu2: cpu at 2 {
@@ -74,6 +76,7 @@
 			compatible = "arm,cortex-a15";
 			reg = <2>;
 			clock-frequency = <1300000000>;
+			next-level-cache = <&L2_CA15>;
 		};
 
 		cpu3: cpu at 3 {
@@ -81,6 +84,7 @@
 			compatible = "arm,cortex-a15";
 			reg = <3>;
 			clock-frequency = <1300000000>;
+			next-level-cache = <&L2_CA15>;
 		};
 
 		cpu4: cpu at 4 {
@@ -88,6 +92,7 @@
 			compatible = "arm,cortex-a7";
 			reg = <0x100>;
 			clock-frequency = <780000000>;
+			next-level-cache = <&L2_CA7>;
 		};
 
 		cpu5: cpu at 5 {
@@ -95,6 +100,7 @@
 			compatible = "arm,cortex-a7";
 			reg = <0x101>;
 			clock-frequency = <780000000>;
+			next-level-cache = <&L2_CA7>;
 		};
 
 		cpu6: cpu at 6 {
@@ -102,6 +108,7 @@
 			compatible = "arm,cortex-a7";
 			reg = <0x102>;
 			clock-frequency = <780000000>;
+			next-level-cache = <&L2_CA7>;
 		};
 
 		cpu7: cpu at 7 {
@@ -109,9 +116,22 @@
 			compatible = "arm,cortex-a7";
 			reg = <0x103>;
 			clock-frequency = <780000000>;
+			next-level-cache = <&L2_CA7>;
 		};
 	};
 
+	L2_CA15: cache-controller at 0 {
+		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
+	};
+
+	L2_CA7: cache-controller at 1 {
+		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
+	};
+
 	gic: interrupt-controller at f1001000 {
 		compatible = "arm,gic-400";
 		#interrupt-cells = <3>;
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 12:38:34 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 21:38:34 +0100
Subject: [PATCH v3 6/7] arm64: dts: r8a7795: Add missing properties to CA57 L2
 cache node
In-Reply-To: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
References: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455568715-20880-7-git-send-email-geert+renesas@glider.be>

Add the missing "cache-unified" and "cache-level" properties to the
Cortex-A57 cache-controller node.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v3:
  - Remaining part of "[PATCH v2 6/6] arm64: renesas: r8a7795: Add L2
    cache-controller nodes", after dropping the "arm,data-latency" and
    "arm,tag-latency" properties.
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index b5e46e4ff72ad003..c07f4e83b988ba42 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -68,6 +68,8 @@
 
 	L2_CA57: cache-controller at 0 {
 		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
 	};
 
 	extal_clk: extal {
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 12:38:31 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 21:38:31 +0100
Subject: [PATCH v3 3/7] ARM: dts: r8a7791: Add L2 cache-controller node
In-Reply-To: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
References: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455568715-20880-4-git-send-email-geert+renesas@glider.be>

Add a device node for the L2 cache, and link the CPU nodes to it.

The L2 cache for the Cortex-A15 CPU cores is 1 MiB large (organized as
64 KiB x 16 ways).

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v3:
  - Drop "arm,data-latency" and "arm,tag-latency" properties, as they
    may not be valid when using virtualization,
  - Change one-line summary prefix to match current arm-soc practices,

v2:
  - Drop (incorrect) optional cache-{size,sets,{block,line}-size}
    properties, as this information is auto-detected,
  - Integrate linking CPUs to L2 cache into this patch,
  - Extracted from series "[PATCH/RFC 00/15] ARM: shmobile: R-Car: Add
    SYSC PM Domain DT Support".
---
 arch/arm/boot/dts/r8a7791.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 8910236e64bf93ed..a65910ed5884edfd 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -51,6 +51,7 @@
 			voltage-tolerance = <1>; /* 1% */
 			clocks = <&cpg_clocks R8A7791_CLK_Z>;
 			clock-latency = <300000>; /* 300 us */
+			next-level-cache = <&L2_CA15>;
 
 			/* kHz - uV - OPPs unknown yet */
 			operating-points = <1500000 1000000>,
@@ -66,9 +67,16 @@
 			compatible = "arm,cortex-a15";
 			reg = <1>;
 			clock-frequency = <1500000000>;
+			next-level-cache = <&L2_CA15>;
 		};
 	};
 
+	L2_CA15: cache-controller at 0 {
+		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
+	};
+
 	gic: interrupt-controller at f1001000 {
 		compatible = "arm,gic-400";
 		#interrupt-cells = <3>;
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 12:38:29 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 21:38:29 +0100
Subject: [PATCH v3 1/7] ARM: dts: r8a73a4: Add L2 cache-controller nodes
In-Reply-To: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
References: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455568715-20880-2-git-send-email-geert+renesas@glider.be>

Add device nodes for the L2 caches, and link the CPU node to its L2
cache node.

The L2 cache for the Cortex-A15 CPU cores is 1 MiB large (organized as
64 KiB x 16 ways), and located in PM domain A3SM.

The L2 cache for the Cortex-A7 CPU cores is 512 KiB large (organized as
64 KiB x 8 ways), and located in PM domain A3KM.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v3:
  - Drop "arm,data-latency" and "arm,tag-latency" properties, as they
    may not be valid when using virtualization,
  - Change one-line summary prefix to match current arm-soc practices,

v2:
  - New.
---
 arch/arm/boot/dts/r8a73a4.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 138414a7d1703781..6583a1dfca1f64c6 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -29,6 +29,7 @@
 			reg = <0>;
 			clock-frequency = <1500000000>;
 			power-domains = <&pd_a2sl>;
+			next-level-cache = <&L2_CA15>;
 		};
 	};
 
@@ -45,6 +46,22 @@
 			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
 	};
 
+	L2_CA15: cache-controller at 0 {
+		compatible = "cache";
+		clocks = <&cpg_clocks R8A73A4_CLK_Z>;
+		power-domains = <&pd_a3sm>;
+		cache-unified;
+		cache-level = <2>;
+	};
+
+	L2_CA7: cache-controller at 1 {
+		compatible = "cache";
+		clocks = <&cpg_clocks R8A73A4_CLK_Z2>;
+		power-domains = <&pd_a3km>;
+		cache-unified;
+		cache-level = <2>;
+	};
+
 	dbsc1: memory-controller at e6790000 {
 		compatible = "renesas,dbsc-r8a73a4";
 		reg = <0 0xe6790000 0 0x10000>;
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 12:38:35 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 21:38:35 +0100
Subject: [PATCH v3 7/7] arm64: dts: r8a7795: Add CA53 L2 cache-controller node
In-Reply-To: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
References: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455568715-20880-8-git-send-email-geert+renesas@glider.be>

Add a device node for the Cortex-A53 L2 cache-controller.

The L2 cache for the Cortex-A53 CPU cores is 512 KiB large (organized as
32 KiB x 16 ways).

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v3:
  - Remaining part of "[PATCH v2 6/6] arm64: renesas: r8a7795: Add L2
    cache-controller nodes".
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index c07f4e83b988ba42..c572527afec3403a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -72,6 +72,12 @@
 		cache-level = <2>;
 	};
 
+	L2_CA53: cache-controller at 1 {
+		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
+	};
+
 	extal_clk: extal {
 		compatible = "fixed-clock";
 		#clock-cells = <0>;
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 12:38:28 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 21:38:28 +0100
Subject: [PATCH v3 0/7] ARM/arm64: dts: renesas: Add/complete L2
 cache-controller nodes
Message-ID: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>

	Hi Simon, Magnus,

This patch series adds the missing L2 cache-controller nodes to the
DTSes for various Renesas ARM-based SoCs, or completes the existing
nodes, and links the CPU nodes to them.

For R-Mobile APE6 (r8a73a4), the L2 cache-controllers are also linked to
the respective (already existing) SYSC Power Domains. Fortunately these
Power Domains were never powered down, as they are parents of the Power
Domains containing CPU cores. This may change in the future.

For R-Car Gen2 and Gen3 (r8a779x), this serves as a preparatory step for
adding SYSC Power Domain support later.

Changes compared to v2:
  - Dropped "arm,data-latency" and "arm,tag-latency" properties, as they
    may not be valid when using virtualization,
  - Dropped already applied parts of "[PATCH v2 6/6] arm64: renesas:
    r8a7795: Add L2 cache-controller nodes",
  - Changed one-line summary prefix to match current arm-soc practices.

This series is against renesas-devel-20160215-v4.5-rc4.
It has been tested on r8a73a4/ape6evm, r8a7791/koelsch, r8a7794/alt, and
r8a7795/salvator-x.

For your convenience, I've also pushed this series to
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git#topic/l2-cache-v3

Thanks for applying!

Geert Uytterhoeven (7):
  ARM: dts: r8a73a4: Add L2 cache-controller nodes
  ARM: dts: r8a7790: Add L2 cache-controller nodes
  ARM: dts: r8a7791: Add L2 cache-controller node
  ARM: dts: r8a7793: Add L2 cache-controller node
  ARM: dts: r8a7794: Add L2 cache-controller node
  arm64: dts: r8a7795: Add missing properties to CA57 L2 cache node
  arm64: dts: r8a7795: Add CA53 L2 cache-controller node

 arch/arm/boot/dts/r8a73a4.dtsi           | 17 +++++++++++++++++
 arch/arm/boot/dts/r8a7790.dtsi           | 20 ++++++++++++++++++++
 arch/arm/boot/dts/r8a7791.dtsi           |  8 ++++++++
 arch/arm/boot/dts/r8a7793.dtsi           |  7 +++++++
 arch/arm/boot/dts/r8a7794.dtsi           |  8 ++++++++
 arch/arm64/boot/dts/renesas/r8a7795.dtsi |  8 ++++++++
 6 files changed, 68 insertions(+)

-- 
1.9.1

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From geert+renesas at glider.be  Mon Feb 15 12:38:33 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 21:38:33 +0100
Subject: [PATCH v3 5/7] ARM: dts: r8a7794: Add L2 cache-controller node
In-Reply-To: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
References: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455568715-20880-6-git-send-email-geert+renesas@glider.be>

Add a device node for the L2 cache, and link the CPU nodes to it.

The L2 cache for the Cortex-A7 CPU cores is 512 KiB large (organized as
64 KiB x 8 ways).

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v3:
  - Change one-line summary prefix to match current arm-soc practices,

v2:
  - Drop (incorrect) optional cache-{size,sets,{block,line}-size}
    properties, as this information is auto-detected,
  - Integrate linking CPUs to L2 cache into this patch,
  - Extracted from series "[PATCH/RFC 00/15] ARM: shmobile: R-Car: Add
    SYSC PM Domain DT Support".
---
 arch/arm/boot/dts/r8a7794.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index df0861e84a4b81eb..21a02df3609b24aa 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -40,6 +40,7 @@
 			compatible = "arm,cortex-a7";
 			reg = <0>;
 			clock-frequency = <1000000000>;
+			next-level-cache = <&L2_CA7>;
 		};
 
 		cpu1: cpu at 1 {
@@ -47,9 +48,16 @@
 			compatible = "arm,cortex-a7";
 			reg = <1>;
 			clock-frequency = <1000000000>;
+			next-level-cache = <&L2_CA7>;
 		};
 	};
 
+	L2_CA7: cache-controller at 1 {
+		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
+	};
+
 	gic: interrupt-controller at f1001000 {
 		compatible = "arm,gic-400";
 		#interrupt-cells = <3>;
-- 
1.9.1



From rafael at kernel.org  Mon Feb 15 12:41:09 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Mon, 15 Feb 2016 21:41:09 +0100
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <20160215192316.GO10826@n2100.arm.linux.org.uk>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
 <56C21DD0.40508@arm.com>
 <CAJZ5v0gfOVyoWeee5jg7NxLFm-xwdA6-sPQV+cJ=NWJOV-wYzg@mail.gmail.com>
 <56C22105.6050900@arm.com>
 <20160215192316.GO10826@n2100.arm.linux.org.uk>
Message-ID: <CAJZ5v0iC6H9Br21u4=3ykSHJzSJUb7ZMBY_iZNyu74WKO6gnYw@mail.gmail.com>

On Mon, Feb 15, 2016 at 8:23 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Mon, Feb 15, 2016 at 07:03:33PM +0000, Marc Zyngier wrote:
>> On 15/02/16 18:54, Rafael J. Wysocki wrote:
>> > That would explain it, thanks.
>> >
>> > So it looks like we should always use irq_work_queue() on UP even if
>> > CONFIG_SMP is set, shouldn't we?
>>
>> Something like that, yes. CONFIG_SMP is not an indication of an SMP
>> system anymore (we've even dropped the config option on arm64).
>>
>> Hopefully num_possible_cpus() is reliable enough to let you do the right
>> thing...
>
> CONFIG_SMP just says whether to include support for SMP.  It doesn't
> mandate running on a SMP system. :)
>
> I've been looking around the usages of irq_work_queue_on in kernel/
> in -rc4, and some places seem to check for "this CPU":
>
>         /*
>          * It is possible that a restart caused this CPU to be
>          * chosen again. Don't bother with an IPI, just see if we
>          * have more to push.
>          */
>         if (unlikely(cpu == rq->cpu))
>                 goto again;
>
>         /* Try the next RT overloaded CPU */
>         irq_work_queue_on(&rt_rq->push_work, cpu);
>
> I'm not sure about tell_cpu_to_push().
>
> It's also called via tick_nohz_full_kick_cpu(), and the core scheduler
> avoids calling this for the current CPU:
>
>         if (tick_nohz_full_cpu(cpu)) {
>                 if (cpu != smp_processor_id() ||
>                     tick_nohz_tick_stopped())
>                         tick_nohz_full_kick_cpu(cpu);
>
> I'm not sure about add_nr_running() in kernel/sched/sched.h - I think
> that _could_ be a problem even without Rafael's cpufreq change.
>
> So... the question is what do we do with irq_work_queue_on() in general
> when called on non-SMP systems.

I guess it might fall back to arch_irq_work_raise() when asked to
queue on the same CPU, so long as that will always do the right thing
(ie. actually queue on the same one).

Thanks,
Rafael


From broonie at kernel.org  Mon Feb 15 12:04:39 2016
From: broonie at kernel.org (Mark Brown)
Date: Mon, 15 Feb 2016 20:04:39 +0000
Subject: [PATCH v2 05/10] regulator: axp20x: support AXP809 variant
In-Reply-To: <1455532288-30870-6-git-send-email-wens@csie.org>
References: <1455532288-30870-1-git-send-email-wens@csie.org>
 <1455532288-30870-6-git-send-email-wens@csie.org>
Message-ID: <20160215200439.GC18327@sirena.org.uk>

On Mon, Feb 15, 2016 at 06:31:23PM +0800, Chen-Yu Tsai wrote:
> The X-Powers AXP809 PMIC has a similar set of regulators as the AXP221,
> though a few LDOs were removed, and a new switch output added. Like the
> AXP221, AXP809 also has DC1SW and DC5LDO, which are internally chained
> to DCDC1 and DCDC5, respectively.

This doesn't apply against current code, please check and resend.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160215/05c76f90/attachment.sig>

From robert.jarzmik at free.fr  Mon Feb 15 12:57:46 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Mon, 15 Feb 2016 21:57:46 +0100
Subject: [PATCH v2 2/4] dmaengine: mmp-pdma: add number of requestors
In-Reply-To: <1455569868-25017-1-git-send-email-robert.jarzmik@free.fr>
References: <1455569868-25017-1-git-send-email-robert.jarzmik@free.fr>
Message-ID: <1455569868-25017-2-git-send-email-robert.jarzmik@free.fr>

The DMA chip has a fixed number of requestor lines used for flow
control. This number is platform dependent. The pxa_dma dma driver will
use this value to activate or not the flow control.

There won't be any impact on mmp_pdma driver.

Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
 include/linux/platform_data/mmp_dma.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/platform_data/mmp_dma.h b/include/linux/platform_data/mmp_dma.h
index 2a330ec9e2af..d1397c8ed94e 100644
--- a/include/linux/platform_data/mmp_dma.h
+++ b/include/linux/platform_data/mmp_dma.h
@@ -14,6 +14,7 @@
 
 struct mmp_dma_platdata {
 	int dma_channels;
+	int nb_requestors;
 };
 
 #endif /* MMP_DMA_H */
-- 
2.1.4



From robert.jarzmik at free.fr  Mon Feb 15 12:57:45 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Mon, 15 Feb 2016 21:57:45 +0100
Subject: [PATCH v2 1/4] dma: mmp_pdma: Add the #dma-requests DT property
 documentation
Message-ID: <1455569868-25017-1-git-send-email-robert.jarzmik@free.fr>

For pxa based platforms, the number of requestor lines should be
specified, so that the driver can check if the flow control should be
activated (when a requestor line is asked for) or not.

Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
Since v1: rename of property to #dma-requests
      	  modify default value to 32 as suggested by Vinod
---
 Documentation/devicetree/bindings/dma/mmp-dma.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/mmp-dma.txt b/Documentation/devicetree/bindings/dma/mmp-dma.txt
index 7a802f64e5bd..8f7364a7b349 100644
--- a/Documentation/devicetree/bindings/dma/mmp-dma.txt
+++ b/Documentation/devicetree/bindings/dma/mmp-dma.txt
@@ -12,6 +12,8 @@ Required properties:
 Optional properties:
 - #dma-channels: Number of DMA channels supported by the controller (defaults
   to 32 when not specified)
+- #dma-requests: Number of DMA requestor lines supported by the controller
+  (defaults to 32 when not specified)
 
 "marvell,pdma-1.0"
 Used platforms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688.
-- 
2.1.4



From robert.jarzmik at free.fr  Mon Feb 15 12:57:47 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Mon, 15 Feb 2016 21:57:47 +0100
Subject: [PATCH v2 3/4] ARM: pxa: add the number of DMA requestor lines
In-Reply-To: <1455569868-25017-1-git-send-email-robert.jarzmik@free.fr>
References: <1455569868-25017-1-git-send-email-robert.jarzmik@free.fr>
Message-ID: <1455569868-25017-3-git-send-email-robert.jarzmik@free.fr>

Declare the number of DMA requestor lines per platform :
 - for pxa25x: 40 requestor lines
 - for pxa27x: 75 requestor lines
 - for pxa3xx: 100 requestor lines

This information will be used to activate the DMA flow control or not.

Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
Since v1: rename of property to #dma-requests
---
 arch/arm/boot/dts/pxa27x.dtsi        | 1 +
 arch/arm/boot/dts/pxa3xx.dtsi        | 1 +
 arch/arm/mach-pxa/devices.c          | 3 ++-
 arch/arm/mach-pxa/pxa25x.c           | 2 +-
 arch/arm/mach-pxa/pxa27x.c           | 2 +-
 arch/arm/mach-pxa/pxa3xx.c           | 2 +-
 arch/arm/plat-pxa/include/plat/dma.h | 2 +-
 7 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index ef366b204c89..aab08a48dbca 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -13,6 +13,7 @@
 			interrupts = <25>;
 			#dma-channels = <32>;
 			#dma-cells = <2>;
+			#dma-requests = <75>;
 			status = "okay";
 		};
 
diff --git a/arch/arm/boot/dts/pxa3xx.dtsi b/arch/arm/boot/dts/pxa3xx.dtsi
index cf6998a0804d..bea454f50ff9 100644
--- a/arch/arm/boot/dts/pxa3xx.dtsi
+++ b/arch/arm/boot/dts/pxa3xx.dtsi
@@ -12,6 +12,7 @@
 			interrupts = <25>;
 			#dma-channels = <32>;
 			#dma-cells = <2>;
+			#dma-requests = <100>;
 			status = "okay";
 		};
 
diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index 6e12c162506f..d9ff6e4dd854 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -1233,6 +1233,7 @@ void __init pxa2xx_set_spi_info(unsigned id, struct pxa2xx_spi_master *info)
 
 static struct mmp_dma_platdata pxa_dma_pdata = {
 	.dma_channels	= 0,
+	.nb_requestors	= 0,
 };
 
 static struct resource pxa_dma_resource[] = {
@@ -1261,7 +1262,7 @@ static struct platform_device pxa2xx_pxa_dma = {
 	.resource	= pxa_dma_resource,
 };
 
-void __init pxa2xx_set_dmac_info(int nb_channels)
+void __init pxa2xx_set_dmac_info(int nb_channels, int nb_requestors)
 {
 	pxa_dma_pdata.dma_channels = nb_channels;
 	pxa_register_device(&pxa2xx_pxa_dma, &pxa_dma_pdata);
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index a177bf45feef..823504f48f80 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -206,7 +206,7 @@ static int __init pxa25x_init(void)
 		register_syscore_ops(&pxa_irq_syscore_ops);
 		register_syscore_ops(&pxa2xx_mfp_syscore_ops);
 
-		pxa2xx_set_dmac_info(16);
+		pxa2xx_set_dmac_info(16, 40);
 		pxa_register_device(&pxa25x_device_gpio, &pxa25x_gpio_info);
 		ret = platform_add_devices(pxa25x_devices,
 					   ARRAY_SIZE(pxa25x_devices));
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index 73e96270dc53..d84239c89639 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -310,7 +310,7 @@ static int __init pxa27x_init(void)
 		if (!of_have_populated_dt()) {
 			pxa_register_device(&pxa27x_device_gpio,
 					    &pxa27x_gpio_info);
-			pxa2xx_set_dmac_info(32);
+			pxa2xx_set_dmac_info(32, 75);
 			ret = platform_add_devices(devices,
 						   ARRAY_SIZE(devices));
 		}
diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
index a1c4c888f246..fb0adb669124 100644
--- a/arch/arm/mach-pxa/pxa3xx.c
+++ b/arch/arm/mach-pxa/pxa3xx.c
@@ -450,7 +450,7 @@ static int __init pxa3xx_init(void)
 		if (of_have_populated_dt())
 			return 0;
 
-		pxa2xx_set_dmac_info(32);
+		pxa2xx_set_dmac_info(32, 100);
 		ret = platform_add_devices(devices, ARRAY_SIZE(devices));
 		if (ret)
 			return ret;
diff --git a/arch/arm/plat-pxa/include/plat/dma.h b/arch/arm/plat-pxa/include/plat/dma.h
index 28848b344e2d..ceba3e4184fc 100644
--- a/arch/arm/plat-pxa/include/plat/dma.h
+++ b/arch/arm/plat-pxa/include/plat/dma.h
@@ -95,6 +95,6 @@ static inline int pxad_toggle_reserved_channel(int legacy_channel)
 }
 #endif
 
-extern void __init pxa2xx_set_dmac_info(int nb_channels);
+extern void __init pxa2xx_set_dmac_info(int nb_channels, int nb_requestors);
 
 #endif /* __PLAT_DMA_H */
-- 
2.1.4



From robert.jarzmik at free.fr  Mon Feb 15 12:57:48 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Mon, 15 Feb 2016 21:57:48 +0100
Subject: [PATCH v2 4/4] dmaengine: pxa_dma: fix the maximum requestor line
In-Reply-To: <1455569868-25017-1-git-send-email-robert.jarzmik@free.fr>
References: <1455569868-25017-1-git-send-email-robert.jarzmik@free.fr>
Message-ID: <1455569868-25017-4-git-send-email-robert.jarzmik@free.fr>

The current number of requestor lines is limited to 31. This was an
error of a previous commit, as this number is platform dependent, and is
actually :
 - for pxa25x: 40 requestor lines
 - for pxa27x: 75 requestor lines
 - for pxa3xx: 100 requestor lines

The previous testing did not reveal the faulty constant as on pxa[23]xx
platforms, only camera, MSL and USB are above requestor 32, and in these
only the camera has a driver using dma.

Fixes: e87ffbdf0697 ("dmaengine: pxa_dma: fix the no-requestor case")
Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
Since v1: change to #dma-requests the of property name
      	  default to 32 requestors and warn as suggested by Vinod
---
 drivers/dma/pxa_dma.c | 39 ++++++++++++++++++++++++++++-----------
 1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index ca6c088edc8a..8b333601687f 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -122,6 +122,7 @@ struct pxad_chan {
 struct pxad_device {
 	struct dma_device		slave;
 	int				nr_chans;
+	int				nr_requestors;
 	void __iomem			*base;
 	struct pxad_phy			*phys;
 	spinlock_t			phy_lock;	/* Phy association */
@@ -473,7 +474,7 @@ static void pxad_free_phy(struct pxad_chan *chan)
 		return;
 
 	/* clear the channel mapping in DRCMR */
-	if (chan->drcmr <= DRCMR_CHLNUM) {
+	if (chan->drcmr <= pdev->nr_requestors) {
 		reg = pxad_drcmr(chan->drcmr);
 		writel_relaxed(0, chan->phy->base + reg);
 	}
@@ -509,6 +510,7 @@ static bool is_running_chan_misaligned(struct pxad_chan *chan)
 
 static void phy_enable(struct pxad_phy *phy, bool misaligned)
 {
+	struct pxad_device *pdev;
 	u32 reg, dalgn;
 
 	if (!phy->vchan)
@@ -518,7 +520,8 @@ static void phy_enable(struct pxad_phy *phy, bool misaligned)
 		"%s(); phy=%p(%d) misaligned=%d\n", __func__,
 		phy, phy->idx, misaligned);
 
-	if (phy->vchan->drcmr <= DRCMR_CHLNUM) {
+	pdev = to_pxad_dev(phy->vchan->vc.chan.device);
+	if (phy->vchan->drcmr <= pdev->nr_requestors) {
 		reg = pxad_drcmr(phy->vchan->drcmr);
 		writel_relaxed(DRCMR_MAPVLD | phy->idx, phy->base + reg);
 	}
@@ -914,6 +917,7 @@ static void pxad_get_config(struct pxad_chan *chan,
 {
 	u32 maxburst = 0, dev_addr = 0;
 	enum dma_slave_buswidth width = DMA_SLAVE_BUSWIDTH_UNDEFINED;
+	struct pxad_device *pdev = to_pxad_dev(chan->vc.chan.device);
 
 	*dcmd = 0;
 	if (dir == DMA_DEV_TO_MEM) {
@@ -922,7 +926,7 @@ static void pxad_get_config(struct pxad_chan *chan,
 		dev_addr = chan->cfg.src_addr;
 		*dev_src = dev_addr;
 		*dcmd |= PXA_DCMD_INCTRGADDR;
-		if (chan->drcmr <= DRCMR_CHLNUM)
+		if (chan->drcmr <= pdev->nr_requestors)
 			*dcmd |= PXA_DCMD_FLOWSRC;
 	}
 	if (dir == DMA_MEM_TO_DEV) {
@@ -931,7 +935,7 @@ static void pxad_get_config(struct pxad_chan *chan,
 		dev_addr = chan->cfg.dst_addr;
 		*dev_dst = dev_addr;
 		*dcmd |= PXA_DCMD_INCSRCADDR;
-		if (chan->drcmr <= DRCMR_CHLNUM)
+		if (chan->drcmr <= pdev->nr_requestors)
 			*dcmd |= PXA_DCMD_FLOWTRG;
 	}
 	if (dir == DMA_MEM_TO_MEM)
@@ -1341,13 +1345,15 @@ static struct dma_chan *pxad_dma_xlate(struct of_phandle_args *dma_spec,
 
 static int pxad_init_dmadev(struct platform_device *op,
 			    struct pxad_device *pdev,
-			    unsigned int nr_phy_chans)
+			    unsigned int nr_phy_chans,
+			    unsigned int nr_requestors)
 {
 	int ret;
 	unsigned int i;
 	struct pxad_chan *c;
 
 	pdev->nr_chans = nr_phy_chans;
+	pdev->nr_requestors = nr_requestors;
 	INIT_LIST_HEAD(&pdev->slave.channels);
 	pdev->slave.device_alloc_chan_resources = pxad_alloc_chan_resources;
 	pdev->slave.device_free_chan_resources = pxad_free_chan_resources;
@@ -1382,7 +1388,7 @@ static int pxad_probe(struct platform_device *op)
 	const struct of_device_id *of_id;
 	struct mmp_dma_platdata *pdata = dev_get_platdata(&op->dev);
 	struct resource *iores;
-	int ret, dma_channels = 0;
+	int ret, dma_channels = 0, nb_requestors = 0;
 	const enum dma_slave_buswidth widths =
 		DMA_SLAVE_BUSWIDTH_1_BYTE   | DMA_SLAVE_BUSWIDTH_2_BYTES |
 		DMA_SLAVE_BUSWIDTH_4_BYTES;
@@ -1399,13 +1405,23 @@ static int pxad_probe(struct platform_device *op)
 		return PTR_ERR(pdev->base);
 
 	of_id = of_match_device(pxad_dt_ids, &op->dev);
-	if (of_id)
+	if (of_id) {
 		of_property_read_u32(op->dev.of_node, "#dma-channels",
 				     &dma_channels);
-	else if (pdata && pdata->dma_channels)
+		ret = of_property_read_u32(op->dev.of_node, "#dma-requests",
+					   &nb_requestors);
+		if (ret) {
+			dev_warn(pdev->slave.dev,
+				 "#dma-requests set to default 32 as missing in OF: %d",
+				 ret);
+			nb_requestors = 32;
+		};
+	} else if (pdata && pdata->dma_channels) {
 		dma_channels = pdata->dma_channels;
-	else
+		nb_requestors = pdata->nb_requestors;
+	} else {
 		dma_channels = 32;	/* default 32 channel */
+	}
 
 	dma_cap_set(DMA_SLAVE, pdev->slave.cap_mask);
 	dma_cap_set(DMA_MEMCPY, pdev->slave.cap_mask);
@@ -1423,7 +1439,7 @@ static int pxad_probe(struct platform_device *op)
 	pdev->slave.descriptor_reuse = true;
 
 	pdev->slave.dev = &op->dev;
-	ret = pxad_init_dmadev(op, pdev, dma_channels);
+	ret = pxad_init_dmadev(op, pdev, dma_channels, nb_requestors);
 	if (ret) {
 		dev_err(pdev->slave.dev, "unable to register\n");
 		return ret;
@@ -1442,7 +1458,8 @@ static int pxad_probe(struct platform_device *op)
 
 	platform_set_drvdata(op, pdev);
 	pxad_init_debugfs(pdev);
-	dev_info(pdev->slave.dev, "initialized %d channels\n", dma_channels);
+	dev_info(pdev->slave.dev, "initialized %d channels on %d requestors\n",
+		 dma_channels, nb_requestors);
 	return 0;
 }
 
-- 
2.1.4



From gregkh at linuxfoundation.org  Mon Feb 15 13:03:08 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 15 Feb 2016 13:03:08 -0800
Subject: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'
In-Reply-To: <20160215171201.GK12289@pengutronix.de>
References: <20160214165010.GA3189@roeck-us.net>
 <20160215105909.GH12289@pengutronix.de> <56C1CE95.6020206@arm.com>
 <20160215144344.GF10826@n2100.arm.linux.org.uk>
 <20160215162753.GI12289@pengutronix.de>
 <20160215164937.GC25556@kroah.com>
 <20160215171201.GK12289@pengutronix.de>
Message-ID: <20160215210308.GA12095@kroah.com>

On Mon, Feb 15, 2016 at 06:12:01PM +0100, Uwe Kleine-K?nig wrote:
> Hello Greg,
> 
> On Mon, Feb 15, 2016 at 08:49:37AM -0800, Greg Kroah-Hartman wrote:
> > On Mon, Feb 15, 2016 at 05:27:53PM +0100, Uwe Kleine-K?nig wrote:
> > > Greg, can you drop this patch, or do you need a proper changelog for a
> > > revert? On top of that I'd then create a new patch which is more
> > > conservative.
> > 
> > A hint as to what the git commit id was would be helpful, I can just
> > revert it based on that.
> 
> This is 67d02a1bbb33 ("driver-core: platform: probe of-devices only
> using list of compatibles")
> 
> If you need a log, something like:
> 
> 	Reallow binding of of-devices by name
> 
> 	It turned out that there are valid reasons (e.g. step by step
> 	conversion to device tree probing using auxdata) to bind
> 	of-instantiated devices to drivers by name. So revert to the
> 	original logic.

Now reverted, thanks for the text.

greg k-h


From heiko at sntech.de  Mon Feb 15 13:12:50 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 15 Feb 2016 22:12:50 +0100
Subject: [PATCH] arm64: dts: rockchip: fix the incorrect otp-out pin on
 rk3368
In-Reply-To: <1455507058-10824-1-git-send-email-wxt@rock-chips.com>
References: <1455507058-10824-1-git-send-email-wxt@rock-chips.com>
Message-ID: <1884614.IJaL3hhOqa@phil>

Hi Caesar,

Am Montag, 15. Februar 2016, 11:30:58 schrieb Caesar Wang:
> This patch fixes the incorrect Over-temperature protection pin.
> since the rk3368 io list said the otp pin is gpio0a3.
> 
> Anyway, that should be fixed in here.
> 
> Signed-off-by: Caesar Wang <wxt at rock-chips.com>

applied to my dts branch for 4.6

Thanks
Heiko


From geert+renesas at glider.be  Mon Feb 15 13:17:00 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 22:17:00 +0100
Subject: [PATCH/RFC v2 11/11] arm64: dts: r8a7795: Add SYSC PM domains
In-Reply-To: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455571020-18968-12-git-send-email-geert+renesas@glider.be>

Add a device node for the System Controller, with subnodes that
represent the hardware power area hierarchy.
Hook up the Cortex-A57 CPU cores and the Cortex-A57 and Cortex A53 L2
caches/SCUs to their respective PM domains.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
The SH core was dropped in datasheet rev. 0.5E?

v2:
  - New.
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 142 +++++++++++++++++++++++++++++++
 1 file changed, 142 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index c572527afec3403a..69f400e0d478b285 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -39,6 +39,7 @@
 			compatible = "arm,cortex-a57", "arm,armv8";
 			reg = <0x0>;
 			device_type = "cpu";
+			power-domains = <&pd_ca57_cpu0>;
 			next-level-cache = <&L2_CA57>;
 			enable-method = "psci";
 		};
@@ -47,6 +48,7 @@
 			compatible = "arm,cortex-a57","arm,armv8";
 			reg = <0x1>;
 			device_type = "cpu";
+			power-domains = <&pd_ca57_cpu1>;
 			next-level-cache = <&L2_CA57>;
 			enable-method = "psci";
 		};
@@ -54,6 +56,7 @@
 			compatible = "arm,cortex-a57","arm,armv8";
 			reg = <0x2>;
 			device_type = "cpu";
+			power-domains = <&pd_ca57_cpu2>;
 			next-level-cache = <&L2_CA57>;
 			enable-method = "psci";
 		};
@@ -61,6 +64,7 @@
 			compatible = "arm,cortex-a57","arm,armv8";
 			reg = <0x3>;
 			device_type = "cpu";
+			power-domains = <&pd_ca57_cpu3>;
 			next-level-cache = <&L2_CA57>;
 			enable-method = "psci";
 		};
@@ -68,12 +72,14 @@
 
 	L2_CA57: cache-controller at 0 {
 		compatible = "cache";
+		power-domains = <&pd_ca57_scu>;
 		cache-unified;
 		cache-level = <2>;
 	};
 
 	L2_CA53: cache-controller at 1 {
 		compatible = "cache";
+		power-domains = <&pd_ca53_scu>;
 		cache-unified;
 		cache-level = <2>;
 	};
@@ -968,5 +974,141 @@
 			#dma-cells = <1>;
 			dma-channels = <2>;
 		};
+
+		sysc: system-controller at e6180000 {
+			compatible = "renesas,r8a7795-sysc",
+				     "renesas,rcar-gen3-sysc";
+			reg = <0 0xe6180000 0 0x0400>;
+
+			pm-domains {
+				#address-cells = <2>;
+				#size-cells = <0>;
+
+				pd_ca57_scu: ca57_scu at 12 {
+					reg = <12 0x1c0>;
+					#address-cells = <2>;
+					#size-cells = <0>;
+					#power-domain-cells = <0>;
+
+					pd_ca57_cpu0: ca57_cpu at 0 {
+						reg = <0 0x80>;
+						#power-domain-cells = <0>;
+					};
+
+					pd_ca57_cpu1: ca57_cpu at 1 {
+						reg = <1 0x81>;
+						#power-domain-cells = <0>;
+					};
+
+					pd_ca57_cpu2: ca57_cpu at 2 {
+						reg = <2 0x82>;
+						#power-domain-cells = <0>;
+					};
+
+					pd_ca57_cpu3: ca57_cpu at 3 {
+						reg = <3 0x83>;
+						#power-domain-cells = <0>;
+					};
+				};
+
+				pd_ca53_scu: ca53_scu at 21 {
+					reg = <21 0x140>;
+					#address-cells = <2>;
+					#size-cells = <0>;
+					#power-domain-cells = <0>;
+
+					pd_ca53_cpu0: ca53_cpu at 5 {
+						reg = <5 0x200>;
+						#power-domain-cells = <0>;
+					};
+
+					pd_ca53_cpu1: ca53_cpu at 6 {
+						reg = <6 0x201>;
+						#power-domain-cells = <0>;
+					};
+
+					pd_ca53_cpu2: ca53_cpu at 7 {
+						reg = <7 0x202>;
+						#power-domain-cells = <0>;
+					};
+
+					pd_ca53_cpu3: ca53_cpu at 8 {
+						reg = <8 0x203>;
+						#power-domain-cells = <0>;
+					};
+				};
+
+				pd_a3vp: a3vp at 9 {
+					reg = <9 0x340>;
+					#power-domain-cells = <0>;
+				};
+
+
+				pd_cr7: cr7 at 13 {
+					reg = <13 0x240>;
+					#power-domain-cells = <0>;
+				};
+
+				pd_a3vc: a3vc at 14 {
+					reg = <14 0x380>;
+					#address-cells = <2>;
+					#size-cells = <0>;
+					#power-domain-cells = <0>;
+
+					pd_a2vc0: a2vc at 25 {
+						reg = <25 0x3c0>;
+						#power-domain-cells = <0>;
+					};
+
+					pd_a2vc1: a2vc at 26 {
+						reg = <26 0x3c1>;
+						#power-domain-cells = <0>;
+					};
+				};
+
+				pd_a3sh: a3sh at 16 {
+					reg = <16 0xc0>;
+					#power-domain-cells = <0>;
+				};
+
+				pd_3dg_a: 3dg at 17 {
+					reg = <17 0x100>;
+					#address-cells = <2>;
+					#size-cells = <0>;
+					#power-domain-cells = <0>;
+
+					pd_3dg_b: 3dg at 18 {
+						reg = <18 0x101>;
+						#address-cells = <2>;
+						#size-cells = <0>;
+						#power-domain-cells = <0>;
+
+						pd_3dg_c: 3dg at 19 {
+							reg = <19 0x102>;
+							#address-cells = <2>;
+							#size-cells = <0>;
+							#power-domain-cells = <0>;
+
+							pd_3dg_d: 3dg at 20 {
+								reg = <20 0x103>;
+								#address-cells = <2>;
+								#size-cells = <0>;
+								#power-domain-cells = <0>;
+
+								pd_3dg_e: 3dg at 22 {
+									reg = <22 0x104>;
+									#power-domain-cells = <0>;
+								};
+							};
+						};
+					};
+				};
+
+				pd_a3ir: a3ir at 24 {
+					reg = <24 0x180>;
+					#power-domain-cells = <0>;
+				};
+			};
+		};
 	};
 };
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 13:16:57 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 22:16:57 +0100
Subject: [PATCH/RFC v2 08/11] ARM: dts: r8a7791: Add SYSC PM domains
In-Reply-To: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455571020-18968-9-git-send-email-geert+renesas@glider.be>

Add a device node for the System Controller, with subnodes that
represent the hardware power area hierarchy.
Hook up the Cortex-A15 CPU cores and the Cortex-A15 L2 cache/SCU to
their respective PM domains.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v2:
  - Change one-line summary prefix to match current arm-soc practices,
  - Update compatible values.
---
 arch/arm/boot/dts/r8a7791.dtsi | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index a65910ed5884edfd..a194273eb2b7951e 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -51,6 +51,7 @@
 			voltage-tolerance = <1>; /* 1% */
 			clocks = <&cpg_clocks R8A7791_CLK_Z>;
 			clock-latency = <300000>; /* 300 us */
+			power-domains = <&pd_ca15_cpu0>;
 			next-level-cache = <&L2_CA15>;
 
 			/* kHz - uV - OPPs unknown yet */
@@ -67,12 +68,14 @@
 			compatible = "arm,cortex-a15";
 			reg = <1>;
 			clock-frequency = <1500000000>;
+			power-domains = <&pd_ca15_cpu1>;
 			next-level-cache = <&L2_CA15>;
 		};
 	};
 
 	L2_CA15: cache-controller at 0 {
 		compatible = "cache";
+		power-domains = <&pd_ca15_scu>;
 		cache-unified;
 		cache-level = <2>;
 	};
@@ -1473,6 +1476,43 @@
 		};
 	};
 
+	sysc: system-controller at e6180000 {
+		compatible = "renesas,r8a7791-sysc", "renesas,rcar-gen2-sysc";
+		reg = <0 0xe6180000 0 0x0200>;
+
+		pm-domains {
+			#address-cells = <2>;
+			#size-cells = <0>;
+
+			pd_ca15_scu: scu at 12 {
+				reg = <12 0x180>;
+				#address-cells = <2>;
+				#size-cells = <0>;
+				#power-domain-cells = <0>;
+
+				pd_ca15_cpu0: cpu at 0 {
+					reg = <0 0x40>;
+					#power-domain-cells = <0>;
+				};
+
+				pd_ca15_cpu1: cpu at 1 {
+					reg = <1 0x41>;
+					#power-domain-cells = <0>;
+				};
+			};
+
+			pd_sh: sh at 16 {
+				reg = <16 0x80>;
+				#power-domain-cells = <0>;
+			};
+
+			pd_sgx: sgx at 20 {
+				reg = <20 0xc0>;
+				#power-domain-cells = <0>;
+			};
+		};
+	};
+
 	qspi: spi at e6b10000 {
 		compatible = "renesas,qspi-r8a7791", "renesas,qspi";
 		reg = <0 0xe6b10000 0 0x2c>;
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 13:16:49 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 22:16:49 +0100
Subject: [PATCH/RFC v2 00/11] ARM/arm64: renesas: Add SYSC PM Domain DT Support
Message-ID: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>

	Hi all,

The Renesas R-Car System Controller, as found in various Renesas R-Car
SoCs, provides power management for the CPU cores and various
coprocessors.

This RFC patch series adds DT support for the R-Car SYSC, using the
generic PM Domain. It supports R-Car H1, R-Car Gen2, and R-Car H3.

Patches:
  - Patch 1 adds the DT binding documentation (alternatives I considered
    below the "---"-line),
  - Patch 2 moves the existing pm-rcar driver to drivers/soc/renesas, so
    it can be shared by arm32 and arm64,
  - Patches 3-5 contain the driver implementation,
  - Patches 6-11 add the SYSC PM domains themselves to the various dtsi
    files.

Known issues:
  - This needs better integration with the PM code in pm-rcar-gen2, the
    SMP code in smp-r8a7790, and Magnus' DT APMU series,
  - CPG/MSSR clock domain handling should share more code with the
    renesas-cpg-mssr driver.

Changes compared to v2 (more details in the individual patches):
  - Moved pm-rcar from arch/arm/mach-shmobile/ to drivers/soc/renesas/,
  - Added R-Car H3 (r8a7795) support, incl. support for devices part of
    a SYSC PM domain and the CPG/MSSR clock domain,
  - Use "renesas,<type>-sysc" instead of "renesas,sysc-<type>",
  - Added fallback compatibility strings for R-Car Gen2 and Gen3.
  - Changed one-line summary prefix to match current arm-soc practices,
  - The L2 cache-controller patches have been extracted into a separate
    series ("[PATCH v3 0/7] ARM/arm64: dts: renesas: Add/complete L2
    cache-controller nodes"),
  - Minor fixes.

This series is against renesas-devel-20160215-v4.5-rc4, with series
"[PATCH v3 0/7] ARM/arm64: dts: renesas: Add/complete L2
cache-controller nodes" applied. It is not yet meant to be applied!
It's published as-is to ease development of drivers for devices residing
in a SYSC PM domain on R-Car H3 (e.g. VSP, FCP_V).

This was tested on r8a7779/marzen, r8a7791/koelsch, r8a7794/alt, and
r8a7795/salvator-x.

For your convenience, I've also pushed this series to
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git#topic/rcar-sysc-pd-rfc-v2

Thanks for your comments!

Geert Uytterhoeven (11):
  PM / Domains: Add DT bindings for the R-Car System Controller
  soc: renesas: Move pm-rcar to drivers/soc/renesas/
  soc: renesas: Improve rcar_sysc_power() debug info
  soc: renesas: rcar: Add DT support for SYSC PM domains
  soc: renesas: rcar: Handle clock domain devices in SYSC PM domains
  ARM: dts: r8a7779: Add SYSC PM domains
  ARM: dts: r8a7790: Add SYSC PM domains
  ARM: dts: r8a7791: Add SYSC PM domains
  ARM: dts: r8a7793: Add SYSC PM domains
  ARM: dts: r8a7794: Add SYSC PM domains
  arm64: dts: r8a7795: Add SYSC PM domains

 .../bindings/power/renesas,sysc-rcar.txt           |  87 ++++
 arch/arm/boot/dts/r8a7779.dtsi                     |  48 ++
 arch/arm/boot/dts/r8a7790.dtsi                     |  89 ++++
 arch/arm/boot/dts/r8a7791.dtsi                     |  40 ++
 arch/arm/boot/dts/r8a7793.dtsi                     |  39 ++
 arch/arm/boot/dts/r8a7794.dtsi                     |  40 ++
 arch/arm/mach-shmobile/Kconfig                     |   8 +-
 arch/arm/mach-shmobile/Makefile                    |   1 -
 arch/arm/mach-shmobile/pm-r8a7779.c                |   3 +-
 arch/arm/mach-shmobile/pm-rcar-gen2.c              |   2 +-
 arch/arm/mach-shmobile/pm-rcar.c                   | 164 ------
 arch/arm/mach-shmobile/smp-r8a7779.c               |   2 +-
 arch/arm/mach-shmobile/smp-r8a7790.c               |   2 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi           | 142 ++++++
 drivers/soc/Kconfig                                |   1 +
 drivers/soc/Makefile                               |   3 +-
 drivers/soc/renesas/Kconfig                        |   8 +
 drivers/soc/renesas/Makefile                       |   1 +
 drivers/soc/renesas/pm-rcar.c                      | 559 +++++++++++++++++++++
 .../linux/soc/renesas}/pm-rcar.h                   |   2 +
 20 files changed, 1065 insertions(+), 176 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt
 delete mode 100644 arch/arm/mach-shmobile/pm-rcar.c
 create mode 100644 drivers/soc/renesas/Kconfig
 create mode 100644 drivers/soc/renesas/Makefile
 create mode 100644 drivers/soc/renesas/pm-rcar.c
 rename {arch/arm/mach-shmobile => include/linux/soc/renesas}/pm-rcar.h (93%)

-- 
1.9.1

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From geert+renesas at glider.be  Mon Feb 15 13:16:59 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 22:16:59 +0100
Subject: [PATCH/RFC v2 10/11] ARM: dts: r8a7794: Add SYSC PM domains
In-Reply-To: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455571020-18968-11-git-send-email-geert+renesas@glider.be>

Add a device node for the System Controller, with subnodes that
represent the hardware power area hierarchy.
Hook up the Cortex-A7 CPU cores and the Cortex-A7 L2 cache/SCU to their
respective PM domains.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v2:
  - Change one-line summary prefix to match current arm-soc practices,
  - Update compatible values.
---
 arch/arm/boot/dts/r8a7794.dtsi | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 21a02df3609b24aa..d0fc735571242fd1 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -40,6 +40,7 @@
 			compatible = "arm,cortex-a7";
 			reg = <0>;
 			clock-frequency = <1000000000>;
+			power-domains = <&pd_ca7_cpu0>;
 			next-level-cache = <&L2_CA7>;
 		};
 
@@ -48,12 +49,14 @@
 			compatible = "arm,cortex-a7";
 			reg = <1>;
 			clock-frequency = <1000000000>;
+			power-domains = <&pd_ca7_cpu1>;
 			next-level-cache = <&L2_CA7>;
 		};
 	};
 
 	L2_CA7: cache-controller at 1 {
 		compatible = "cache";
+		power-domains = <&pd_ca7_scu>;
 		cache-unified;
 		cache-level = <2>;
 	};
@@ -1152,6 +1155,43 @@
 		};
 	};
 
+	sysc: system-controller at e6180000 {
+		compatible = "renesas,r8a7794-sysc", "renesas,rcar-gen2-sysc";
+		reg = <0 0xe6180000 0 0x0200>;
+
+		pm-domains {
+			#address-cells = <2>;
+			#size-cells = <0>;
+
+			pd_ca7_scu: scu at 21 {
+				reg = <21 0x100>;
+				#address-cells = <2>;
+				#size-cells = <0>;
+				#power-domain-cells = <0>;
+
+				pd_ca7_cpu0: cpu at 5 {
+					reg = <5 0x1c0>;
+					#power-domain-cells = <0>;
+				};
+
+				pd_ca7_cpu1: cpu at 6 {
+					reg = <6 0x1c0>;
+					#power-domain-cells = <0>;
+				};
+			};
+
+			pd_sh: sh at 16 {
+				reg = <16 0x80>;
+				#power-domain-cells = <0>;
+			};
+
+			pd_sgx: sgx at 20 {
+				reg = <20 0xc0>;
+				#power-domain-cells = <0>;
+			};
+		};
+	};
+
 	ipmmu_sy0: mmu at e6280000 {
 		compatible = "renesas,ipmmu-r8a7794", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6280000 0 0x1000>;
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 13:16:52 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 22:16:52 +0100
Subject: [PATCH/RFC v2 03/11] soc: renesas: Improve rcar_sysc_power() debug
 info
In-Reply-To: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455571020-18968-4-git-send-email-geert+renesas@glider.be>

Print requested power domain state.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v2:
  - New.
---
 drivers/soc/renesas/pm-rcar.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/renesas/pm-rcar.c b/drivers/soc/renesas/pm-rcar.c
index bc605d9fbc6ce79c..cc684e9cc8db5d1c 100644
--- a/drivers/soc/renesas/pm-rcar.c
+++ b/drivers/soc/renesas/pm-rcar.c
@@ -128,7 +128,7 @@ static int rcar_sysc_power(const struct rcar_sysc_ch *sysc_ch, bool on)
  out:
 	spin_unlock_irqrestore(&rcar_sysc_lock, flags);
 
-	pr_debug("sysc power domain %d: %08x -> %d\n",
+	pr_debug("sysc power %s domain %d: %08x -> %d\n", on ? "on" : "off",
 		 sysc_ch->isr_bit, ioread32(rcar_sysc_base + SYSCISR), ret);
 	return ret;
 }
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 13:16:56 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 22:16:56 +0100
Subject: [PATCH/RFC v2 07/11] ARM: dts: r8a7790: Add SYSC PM domains
In-Reply-To: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455571020-18968-8-git-send-email-geert+renesas@glider.be>

Add a device node for the System Controller, with subnodes that
represent the hardware power area hierarchy.
Hook up the Cortex-A15 and Cortex-A7 CPU cores and L2 caches/SCUs to
their respective PM domains.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v2:
  - Change one-line summary prefix to match current arm-soc practices,
  - Update compatible values.
---
 arch/arm/boot/dts/r8a7790.dtsi | 89 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 89 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index e40aa6585831c520..3e5a97c70480cbbc 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -52,6 +52,7 @@
 			voltage-tolerance = <1>; /* 1% */
 			clocks = <&cpg_clocks R8A7790_CLK_Z>;
 			clock-latency = <300000>; /* 300 us */
+			power-domains = <&pd_ca15_cpu0>;
 			next-level-cache = <&L2_CA15>;
 
 			/* kHz - uV - OPPs unknown yet */
@@ -68,6 +69,7 @@
 			compatible = "arm,cortex-a15";
 			reg = <1>;
 			clock-frequency = <1300000000>;
+			power-domains = <&pd_ca15_cpu1>;
 			next-level-cache = <&L2_CA15>;
 		};
 
@@ -76,6 +78,7 @@
 			compatible = "arm,cortex-a15";
 			reg = <2>;
 			clock-frequency = <1300000000>;
+			power-domains = <&pd_ca15_cpu2>;
 			next-level-cache = <&L2_CA15>;
 		};
 
@@ -84,6 +87,7 @@
 			compatible = "arm,cortex-a15";
 			reg = <3>;
 			clock-frequency = <1300000000>;
+			power-domains = <&pd_ca15_cpu3>;
 			next-level-cache = <&L2_CA15>;
 		};
 
@@ -92,6 +96,7 @@
 			compatible = "arm,cortex-a7";
 			reg = <0x100>;
 			clock-frequency = <780000000>;
+			power-domains = <&pd_ca7_cpu0>;
 			next-level-cache = <&L2_CA7>;
 		};
 
@@ -100,6 +105,7 @@
 			compatible = "arm,cortex-a7";
 			reg = <0x101>;
 			clock-frequency = <780000000>;
+			power-domains = <&pd_ca7_cpu1>;
 			next-level-cache = <&L2_CA7>;
 		};
 
@@ -108,6 +114,7 @@
 			compatible = "arm,cortex-a7";
 			reg = <0x102>;
 			clock-frequency = <780000000>;
+			power-domains = <&pd_ca7_cpu2>;
 			next-level-cache = <&L2_CA7>;
 		};
 
@@ -116,18 +123,21 @@
 			compatible = "arm,cortex-a7";
 			reg = <0x103>;
 			clock-frequency = <780000000>;
+			power-domains = <&pd_ca7_cpu3>;
 			next-level-cache = <&L2_CA7>;
 		};
 	};
 
 	L2_CA15: cache-controller at 0 {
 		compatible = "cache";
+		power-domains = <&pd_ca15_scu>;
 		cache-unified;
 		cache-level = <2>;
 	};
 
 	L2_CA7: cache-controller at 1 {
 		compatible = "cache";
+		power-domains = <&pd_ca7_scu>;
 		cache-unified;
 		cache-level = <2>;
 	};
@@ -1441,6 +1451,85 @@
 		};
 	};
 
+	sysc: system-controller at e6180000 {
+		compatible = "renesas,r8a7790-sysc", "renesas,rcar-gen2-sysc";
+		reg = <0 0xe6180000 0 0x0200>;
+
+		pm-domains {
+			#address-cells = <2>;
+			#size-cells = <0>;
+
+			pd_ca15_scu: scu at 12 {
+				reg = <12 0x180>;
+				#address-cells = <2>;
+				#size-cells = <0>;
+				#power-domain-cells = <0>;
+
+				pd_ca15_cpu0: cpu at 0 {
+					reg = <0 0x40>;
+					#power-domain-cells = <0>;
+				};
+
+				pd_ca15_cpu1: cpu at 1 {
+					reg = <1 0x41>;
+					#power-domain-cells = <0>;
+				};
+
+				pd_ca15_cpu2: cpu at 2 {
+					reg = <2 0x42>;
+					#power-domain-cells = <0>;
+				};
+
+				pd_ca15_cpu3: cpu at 3 {
+					reg = <3 0x43>;
+					#power-domain-cells = <0>;
+				};
+			};
+
+			pd_ca7_scu: scu at 21 {
+				reg = <21 0x100>;
+				#address-cells = <2>;
+				#size-cells = <0>;
+				#power-domain-cells = <0>;
+
+				pd_ca7_cpu0: cpu at 5 {
+					reg = <5 0x1c0>;
+					#power-domain-cells = <0>;
+				};
+
+				pd_ca7_cpu1: cpu at 6 {
+					reg = <6 0x1c1>;
+					#power-domain-cells = <0>;
+				};
+
+				pd_ca7_cpu2: cpu at 7 {
+					reg = <7 0x1c2>;
+					#power-domain-cells = <0>;
+				};
+
+				pd_ca7_cpu3: cpu at 8 {
+					reg = <8 0x1c3>;
+					#power-domain-cells = <0>;
+				};
+			};
+
+			pd_sh: sh at 16 {
+				reg = <16 0x80>;
+				#power-domain-cells = <0>;
+			};
+
+			pd_rgx: rgx at 20 {
+				reg = <20 0xc0>;
+				#power-domain-cells = <0>;
+			};
+
+			pd_imp: imp at 24 {
+				reg = <24 0x140>;
+				#power-domain-cells = <0>;
+			};
+		};
+	};
+
 	qspi: spi at e6b10000 {
 		compatible = "renesas,qspi-r8a7790", "renesas,qspi";
 		reg = <0 0xe6b10000 0 0x2c>;
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 13:16:53 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 22:16:53 +0100
Subject: [PATCH/RFC v2 04/11] soc: renesas: rcar: Add DT support for SYSC PM
 domains
In-Reply-To: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455571020-18968-5-git-send-email-geert+renesas@glider.be>

Populate the SYSC PM domains from DT.

Special cases, like PM domains containing CPU cores or SCUs, are
handled by scanning the DT topology.

The SYSCIER register value is derived from the PM domains found in DT,
which will allow to get rid of the hardcoded values in pm-rcar-gen2.c.
However, this means we have to scan for PM domains even if CONFIG_PM=n.

FIXME:
  - This needs better integration with the PM code in pm-rcar-gen2, the
    SMP code in smp-r8a7790, and Magnus' DT APMU series.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v2:
  - Add missing definitions for SYSC_PWR_CA15_CPU and SYSC_PWR_CA7_CPU,
  - Add R-Car H3 (r8a7795) support,
  - Drop tests for CONFIG_ARCH_SHMOBILE_LEGACY,
  - Add missing break statements in rcar_sysc_pwr_on_off(),
  - Add missing calls to of_node_put() in error paths,
  - Fix build if CONFIG_PM=n,
  - Update compatible values,
  - Update copyright.
---
 drivers/soc/renesas/pm-rcar.c | 327 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 327 insertions(+)

diff --git a/drivers/soc/renesas/pm-rcar.c b/drivers/soc/renesas/pm-rcar.c
index cc684e9cc8db5d1c..c0540934126e58eb 100644
--- a/drivers/soc/renesas/pm-rcar.c
+++ b/drivers/soc/renesas/pm-rcar.c
@@ -2,6 +2,7 @@
  * R-Car SYSC Power management support
  *
  * Copyright (C) 2014  Magnus Damm
+ * Copyright (C) 2015-2016 Glider bvba
  *
  * This file is subject to the terms and conditions of the GNU General Public
  * License.  See the file "COPYING" in the main directory of this archive
@@ -11,6 +12,9 @@
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/mm.h>
+#include <linux/of_address.h>
+#include <linux/pm_domain.h>
+#include <linux/slab.h>
 #include <linux/spinlock.h>
 #include <linux/io.h>
 #include <linux/soc/renesas/pm-rcar.h>
@@ -38,6 +42,18 @@
 #define PWRONSR_OFFS		0x10	/* Power Resume Status Register */
 #define PWRER_OFFS		0x14	/* Power Shutoff/Resume Error */
 
+/*
+ * SYSC Power Control Register Base Addresses (R-Car Gen2)
+ */
+#define SYSC_PWR_CA15_CPU	0x40	/* CA15 cores (incl. L1C) (H2/M2/V2H) */
+#define SYSC_PWR_CA7_CPU	0x1c0	/* CA7 cores (incl. L1C) (H2/E2) */
+
+/*
+ * SYSC Power Control Register Base Addresses (R-Car Gen3)
+ */
+#define SYSC_PWR_CA57_CPU	0x80	/* CA57 cores (incl. L1C) (H3) */
+#define SYSC_PWR_CA53_CPU	0x200	/* CA53 cores (incl. L1C) (H3) */
+
 
 #define SYSCSR_RETRIES		100
 #define SYSCSR_DELAY_US		1
@@ -51,11 +67,40 @@
 static void __iomem *rcar_sysc_base;
 static DEFINE_SPINLOCK(rcar_sysc_lock); /* SMP CPUs + I/O devices */
 
+static unsigned int rcar_gen;
+
 static int rcar_sysc_pwr_on_off(const struct rcar_sysc_ch *sysc_ch, bool on)
 {
 	unsigned int sr_bit, reg_offs;
 	int k;
 
+	/*
+	 * Only R-Car H1 can control power to CPUs
+	 * Use WFI to power off, CPG/APMU to resume ARM cores on later R-Car
+	 * Generations
+	 */
+	switch (rcar_gen) {
+	case 2:
+		/* FIXME Check rcar_pm_domain.cpu instead? */
+		switch (sysc_ch->chan_offs) {
+		case SYSC_PWR_CA15_CPU:
+		case SYSC_PWR_CA7_CPU:
+			pr_err("%s: Cannot control power to CPU\n", __func__);
+			return -EINVAL;
+		}
+		break;
+
+	case 3:
+		/* FIXME Check rcar_pm_domain.cpu instead? */
+		switch (sysc_ch->chan_offs) {
+		case SYSC_PWR_CA57_CPU:
+		case SYSC_PWR_CA53_CPU:
+			pr_err("%s: Cannot control power to CPU\n", __func__);
+			return -EINVAL;
+		}
+		break;
+	}
+
 	if (on) {
 		sr_bit = SYSCSR_PONENB;
 		reg_offs = PWRONCR_OFFS;
@@ -162,3 +207,285 @@ void __iomem *rcar_sysc_init(phys_addr_t base)
 
 	return rcar_sysc_base;
 }
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS
+struct rcar_pm_domain {
+	struct generic_pm_domain genpd;
+	struct dev_power_governor *gov;
+	struct rcar_sysc_ch ch;
+	unsigned busy:1;		/* Set if always -EBUSY */
+	unsigned cpu:1;			/* Set if domain contains CPU */
+	char name[0];
+};
+
+static inline struct rcar_pm_domain *to_rcar_pd(struct generic_pm_domain *d)
+{
+	return container_of(d, struct rcar_pm_domain, genpd);
+}
+
+static bool rcar_pd_active_wakeup(struct device *dev)
+{
+	return true;
+}
+
+static int rcar_pd_power_down(struct generic_pm_domain *genpd)
+{
+	struct rcar_pm_domain *rcar_pd = to_rcar_pd(genpd);
+
+	pr_debug("%s: %s\n", __func__, genpd->name);
+
+	if (rcar_pd->busy) {
+		pr_debug("%s: %s busy\n", __func__, genpd->name);
+		return -EBUSY;
+	}
+
+	return rcar_sysc_power_down(&rcar_pd->ch);
+}
+
+static int rcar_pd_power_up(struct generic_pm_domain *genpd)
+{
+	pr_debug("%s: %s\n", __func__, genpd->name);
+	return rcar_sysc_power_up(&to_rcar_pd(genpd)->ch);
+}
+
+static void rcar_init_pm_domain(struct rcar_pm_domain *rcar_pd)
+{
+	struct generic_pm_domain *genpd = &rcar_pd->genpd;
+	struct dev_power_governor *gov = rcar_pd->gov;
+
+	pm_genpd_init(genpd, gov ? : &simple_qos_governor, false);
+	genpd->dev_ops.active_wakeup	= rcar_pd_active_wakeup;
+	genpd->power_off		= rcar_pd_power_down;
+	genpd->power_on			= rcar_pd_power_up;
+
+	if (rcar_sysc_power_is_off(&rcar_pd->ch))
+		rcar_sysc_power_up(&rcar_pd->ch);
+}
+
+enum pd_types {
+	PD_NORMAL,
+	PD_CPU,
+	PD_SCU,
+};
+
+#define MAX_NUM_SPECIAL_PDS	16
+
+static struct special_pd {
+	struct device_node *pd;
+	enum pd_types type;
+} special_pds[MAX_NUM_SPECIAL_PDS] __initdata;
+
+static unsigned int num_special_pds __initdata;
+
+static void __init add_special_pd(struct device_node *np, enum pd_types type)
+{
+	unsigned int i;
+	struct device_node *pd;
+
+	pd = of_parse_phandle(np, "power-domains", 0);
+	if (!pd)
+		return;
+
+	for (i = 0; i < num_special_pds; i++)
+		if (pd == special_pds[i].pd && type == special_pds[i].type) {
+			of_node_put(pd);
+			return;
+		}
+
+	if (num_special_pds == ARRAY_SIZE(special_pds)) {
+		pr_warn("Too many special PM domains\n");
+		of_node_put(pd);
+		return;
+	}
+
+	pr_debug("Special PM domain %s type %d for %s\n", pd->name, type,
+		 np->full_name);
+
+	special_pds[num_special_pds].pd = pd;
+	special_pds[num_special_pds].type = type;
+	num_special_pds++;
+}
+
+static void __init get_special_pds(void)
+{
+	struct device_node *cpu, *scu;
+
+	/* PM domains containing CPUs */
+	for_each_node_by_type(cpu, "cpu") {
+		add_special_pd(cpu, PD_CPU);
+
+		/* SCU, represented by an L2 node */
+		scu = of_parse_phandle(cpu, "next-level-cache", 0);
+		if (scu) {
+			add_special_pd(scu, PD_SCU);
+			of_node_put(scu);
+		}
+	}
+}
+
+static void __init put_special_pds(void)
+{
+	unsigned int i;
+
+	for (i = 0; i < num_special_pds; i++)
+		of_node_put(special_pds[i].pd);
+}
+
+static enum pd_types __init pd_type(const struct device_node *pd)
+{
+	unsigned int i;
+
+	for (i = 0; i < num_special_pds; i++)
+		if (pd == special_pds[i].pd)
+			return special_pds[i].type;
+
+	return PD_NORMAL;
+}
+
+static void __init rcar_setup_pm_domain(struct device_node *np,
+					struct rcar_pm_domain *pd)
+{
+	const char *name = pd->genpd.name;
+
+	switch (pd_type(np)) {
+	case PD_CPU:
+		/*
+		 * This domain contains a CPU core and therefore it should
+		 * only be turned off if the CPU is not in use.
+		 */
+		pr_debug("PM domain %s contains CPU\n", name);
+		pd->gov = &pm_domain_always_on_gov;
+		pd->busy = true;
+		pd->cpu = true;
+		break;
+
+	case PD_SCU:
+		/*
+		 * This domain contains an SCU and cache-controller, and
+		 * therefore it should only be turned off if the CPU cores are
+		 * not in use.
+		 */
+		pr_debug("PM domain %s contains SCU\n", name);
+		pd->gov = &pm_domain_always_on_gov;
+		pd->busy = true;
+		break;
+
+	case PD_NORMAL:
+		break;
+	}
+
+	rcar_init_pm_domain(pd);
+}
+
+static int __init rcar_add_pm_domains(struct device_node *parent,
+				      struct generic_pm_domain *genpd_parent,
+				      u32 *syscier)
+{
+	struct device_node *np;
+
+	for_each_child_of_node(parent, np) {
+		struct rcar_pm_domain *pd;
+		u32 reg[2];
+		int n;
+
+		if (of_property_read_u32_array(np, "reg", reg,
+					       ARRAY_SIZE(reg))) {
+			of_node_put(np);
+			return -EINVAL;
+		}
+
+		*syscier |= BIT(reg[0]);
+
+		if (!IS_ENABLED(CONFIG_PM)) {
+			/* Just continue parsing "reg" to update *syscier */
+			rcar_add_pm_domains(np, NULL, syscier);
+			continue;
+		}
+
+		n = snprintf(NULL, 0, "%s@%u", np->name, reg[0]) + 1;
+
+		pd = kzalloc(sizeof(*pd) + n, GFP_KERNEL);
+		if (!pd) {
+			of_node_put(np);
+			return -ENOMEM;
+		}
+
+		snprintf(pd->name, n, "%s@%u", np->name, reg[0]);
+		pd->genpd.name = pd->name;
+		pd->ch.chan_offs = reg[1] & ~31;
+		pd->ch.chan_bit = reg[1] & 31;
+		pd->ch.isr_bit = reg[0];
+
+		rcar_setup_pm_domain(np, pd);
+		if (genpd_parent)
+			pm_genpd_add_subdomain(genpd_parent, &pd->genpd);
+		of_genpd_add_provider_simple(np, &pd->genpd);
+
+		rcar_add_pm_domains(np, &pd->genpd, syscier);
+	}
+	return 0;
+}
+
+static const struct of_device_id rcar_sysc_matches[] = {
+	{ .compatible = "renesas,r8a7779-sysc", .data = (void *)1 },
+	{ .compatible = "renesas,rcar-gen2-sysc", .data = (void *)2 },
+	{ .compatible = "renesas,rcar-gen3-sysc", .data = (void *)3 },
+	{ /* sentinel */ }
+};
+
+static int __init rcar_init_pm_domains(void)
+{
+	const struct of_device_id *match;
+	struct device_node *np, *pmd;
+	bool scanned = false;
+	void __iomem *base;
+	int ret = 0;
+
+	for_each_matching_node_and_match(np, rcar_sysc_matches, &match) {
+		u32 syscier = 0;
+
+		rcar_gen = (uintptr_t)match->data;
+
+		base = of_iomap(np, 0);
+		if (!base) {
+			pr_warn("%s cannot map reg 0\n", np->full_name);
+			continue;
+		}
+
+		rcar_sysc_base = base;	// FIXME conflicts with rcar_sysc_init()
+
+		pmd = of_get_child_by_name(np, "pm-domains");
+		if (!pmd) {
+			pr_warn("%s lacks pm-domains node\n", np->full_name);
+			continue;
+		}
+
+		if (!scanned) {
+			/* Find PM domains containing special blocks */
+			get_special_pds();
+			scanned = true;
+		}
+
+		ret = rcar_add_pm_domains(pmd, NULL, &syscier);
+		of_node_put(pmd);
+		if (ret) {
+			of_node_put(np);
+			break;
+		}
+
+		/*
+		 * Enable all interrupt sources, but do not use interrupt
+		 * handler
+		 */
+		pr_debug("%s: syscier = 0x%08x\n", np->full_name, syscier);
+		iowrite32(syscier, rcar_sysc_base + SYSCIER);
+		iowrite32(0, rcar_sysc_base + SYSCIMR);
+	}
+
+	put_special_pds();
+
+	return ret;
+}
+
+core_initcall(rcar_init_pm_domains);
+#endif /* PM_GENERIC_DOMAINS */
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 13:16:55 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 22:16:55 +0100
Subject: [PATCH/RFC v2 06/11] ARM: dts: r8a7779: Add SYSC PM domains
In-Reply-To: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455571020-18968-7-git-send-email-geert+renesas@glider.be>

Add a device node for the System Controller, with subnodes that
represent the hardware power area hierarchy.
Hook up ARM CPU cores 1-3 to their respective PM domains.
Note that ARM CPU core 0 cannot be shut off.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v2:
  - Correct sysc "reg" property (#address/size-cells = 1, not 2),
  - Change one-line summary prefix to match current arm-soc practices,
  - Update compatible values.
---
 arch/arm/boot/dts/r8a7779.dtsi | 48 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index a0cc08e6295b0396..14b28c225bb3587c 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -34,18 +34,21 @@
 			compatible = "arm,cortex-a9";
 			reg = <1>;
 			clock-frequency = <1000000000>;
+			power-domains = <&pd_arm1>;
 		};
 		cpu at 2 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a9";
 			reg = <2>;
 			clock-frequency = <1000000000>;
+			power-domains = <&pd_arm2>;
 		};
 		cpu at 3 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a9";
 			reg = <3>;
 			clock-frequency = <1000000000>;
+			power-domains = <&pd_arm3>;
 		};
 	};
 
@@ -591,4 +594,49 @@
 				"mmc1", "mmc0";
 		};
 	};
+
+	sysc: system-controller at ffd85000 {
+		compatible = "renesas,r8a7779-sysc";
+		reg = <0xffd85000 0x0200>;
+
+		pm-domains {
+			#address-cells = <2>;
+			#size-cells = <0>;
+
+			pd_arm1: cpu at 1 {
+				reg = <1 0x41>;
+				#power-domain-cells = <0>;
+			};
+
+			pd_arm2: cpu at 2 {
+				reg = <2 0x42>;
+				#power-domain-cells = <0>;
+			};
+
+			pd_arm3: cpu at 3 {
+				reg = <3 0x43>;
+				#power-domain-cells = <0>;
+			};
+
+			pd_sh: sh at 16 {
+				reg = <16 0x80>;
+				#power-domain-cells = <0>;
+			};
+
+			pd_sgx: sgx at 20 {
+				reg = <20 0xc0>;
+				#power-domain-cells = <0>;
+			};
+
+			pd_vdp: vdp at 21 {
+				reg = <21 0x100>;
+				#power-domain-cells = <0>;
+			};
+
+			pd_imp: imp at 24 {
+				reg = <24 0x140>;
+				#power-domain-cells = <0>;
+			};
+		};
+	};
 };
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 13:16:50 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 22:16:50 +0100
Subject: [PATCH/RFC v2 01/11] PM / Domains: Add DT bindings for the R-Car
 System Controller
In-Reply-To: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455571020-18968-2-git-send-email-geert+renesas@glider.be>

The Renesas R-Car System Controller provides power management for the
CPU cores and various coprocessors, following the generic PM domain
bindings in Documentation/devicetree/bindings/power/power_domain.txt.

This supports R-Car Gen1, Gen2, and Gen3.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
Alternatives I considered:

  - Using a single node per power register block, even if it contains
    multiple domains, e.g.:

	    pd_ca15_scu: ca15_scu at 180 {
		    reg = <0x180 0x20>;
		    #address-cells = <1>;
		    #size-cells = <0>;
		    #power-domain-cells = <0>;
		    renesas,interrupt-bits = <12>;

		    pd_ca15_cpu: ca15_cpu at 40 {
			    reg = <0x40 0x20>;
			    #power-domain-cells = <1>;
			    renesas,pm-domain-indices = <0 1>;
			    renesas,pm-domain-names =
				    "ca15_cpu0", "ca15_cpu1";
			    renesas,interrupt-bits = <0 1>;
		    };
	    };

    Notes:
      - You cannot just have a property with the number of domains, as
	index 0 is not used on R-Car H1. Hence the need for
	"renesas,pm-domain-indices" and "renesas,interrupt-bits",
      - "#power-domain-cells = <1>" for nodes with multiple domains,
	which allows typos in "power-domains = <&pd_ca15_cpu n>", using
	an invalid value of "n".

  - Using a linear description in DT:
      - Needs parent links for subdomains,
      - More complicated to parse (lesson learned from R-Mobile PM
	Domain support).

  - Keeping the power register block offset and the bit number as separate
    "reg" cells, increasing "#address-cells" from 2 to 3,

  - Merging the interrupt bit (which needs only 5 bits) in the other "reg"
    cell, decreasing "#address-cells" from 2 to 1.

v2:
  - Add R-Car H3 (r8a7795) support,
  - Use "renesas,<type>-sysc" instead of "renesas,sysc-<type>",
  - Add fallback compatibility strings for R-Car Gen2 and Gen3.
---
 .../bindings/power/renesas,sysc-rcar.txt           | 87 ++++++++++++++++++++++
 1 file changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt

diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt b/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt
new file mode 100644
index 0000000000000000..92ddc0da7b755215
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt
@@ -0,0 +1,87 @@
+DT bindings for the Renesas R-Car System Controller
+
+== System Controller Node ==
+
+The R-Car System Controller provides power management for the CPU cores and
+various coprocessors.
+
+Required properties:
+  - compatible: Must contain one or more of the following:
+      - "renesas,r8a7779-sysc" (R-Car H1)
+      - "renesas,r8a7790-sysc" (R-Car H2)
+      - "renesas,r8a7791-sysc" (R-Car M2-W)
+      - "renesas,r8a7792-sysc" (R-Car V2H)
+      - "renesas,r8a7793-sysc" (R-Car M2-N)
+      - "renesas,r8a7794-sysc" (R-Car E2)
+      - "renesas,r8a7795-sysc" (R-Car H3)
+      - "renesas,rcar-gen2-sysc" (Generic R-Car Gen2)
+      - "renesas,rcar-gen3-sysc" (Generic R-Car Gen3)
+    When compatible with the generic version, nodes must list the SoC-specific
+    version corresponding to the platform first, followed by the generic
+    version.
+  - reg: Address start and address range for the device.
+  - pm-domains: This node contains a hierarchy of PM Domain Nodes.
+    Dependencies (e.g. parent SCUs should not be powered off while child CPUs
+    are on) should be reflected using subnodes.
+
+
+== PM Domain Nodes ==
+
+Each of the PM domain nodes represents a PM domain, as documented by the
+generic PM domain bindings in
+Documentation/devicetree/bindings/power/power_domain.txt.
+
+Required properties:
+  - #power-domain-cells: Must be 0.
+  - reg: This property must contain 2 values:
+	   - The first value is the number of the interrupt bit representing
+	     the power area in the various Interrupt Registers (e.g. SYSCISR,
+	     Interrupt Status Register),
+	   - The second value encodes the power register block offset (which is
+	     a multiple of 64), and the number of the bit representing the
+	     power area in the various Power Control Registers (e.g. PWROFFSR,
+	     Power Shutoff Status Register). This value is created by ORing
+	     these two numbers.
+	 The parent's node must contain the following two properties:
+	   - #address-cells: Must be 2,
+	   - #size-cells: Must be 0.
+
+
+Example:
+
+	sysc: system-controller at e6180000 {
+		compatible = "renesas,r8a7791-sysc", "renesas,rcar-gen2-sysc";
+		reg = <0 0xe6180000 0 0x0200>;
+
+		pm-domains {
+			#address-cells = <2>;
+			#size-cells = <0>;
+
+			pd_ca15_scu: scu at 12 {
+				reg = <12 0x180>;
+				#address-cells = <2>;
+				#size-cells = <0>;
+				#power-domain-cells = <0>;
+
+				pd_ca15_cpu0: cpu at 0 {
+					reg = <0 0x40>;
+					#power-domain-cells = <0>;
+				};
+
+				pd_ca15_cpu1: cpu at 1 {
+					reg = <1 0x41>;
+					#power-domain-cells = <0>;
+				};
+			};
+
+			pd_sh: sh at 16 {
+				reg = <16 0x80>;
+				#power-domain-cells = <0>;
+			};
+
+			pd_sgx: sgx at 20 {
+				reg = <20 0xc0>;
+				#power-domain-cells = <0>;
+			};
+		};
+	};
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 13:16:54 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 22:16:54 +0100
Subject: [PATCH/RFC v2 05/11] soc: renesas: rcar: Handle clock domain devices
 in SYSC PM domains
In-Reply-To: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455571020-18968-6-git-send-email-geert+renesas@glider.be>

R-Car H3 contains some hardware modules (e.g. VSP and FCP_V) that are
not only located in a power area controlled by the SYSC system
controller, but that are also part of the generic CPG/MSSR clock domain.
Make sure both are handled by enabling module clock PM when the device
for such a hardware module is attached to the SYSC PM Domain.

FIXME Share code with the renesas-cpg-mssr driver.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v2:
  - New.
---
 drivers/soc/renesas/pm-rcar.c | 68 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/drivers/soc/renesas/pm-rcar.c b/drivers/soc/renesas/pm-rcar.c
index c0540934126e58eb..d1bf8c231540b11d 100644
--- a/drivers/soc/renesas/pm-rcar.c
+++ b/drivers/soc/renesas/pm-rcar.c
@@ -9,16 +9,20 @@
  * for more details.
  */
 
+#include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/mm.h>
 #include <linux/of_address.h>
+#include <linux/pm_clock.h>
 #include <linux/pm_domain.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 #include <linux/io.h>
 #include <linux/soc/renesas/pm-rcar.h>
 
+#include <dt-bindings/clock/renesas-cpg-mssr.h>
+
 /* SYSC Common */
 #define SYSCSR			0x00	/* SYSC Status Register */
 #define SYSCISR			0x04	/* Interrupt Status Register */
@@ -248,11 +252,75 @@ static int rcar_pd_power_up(struct generic_pm_domain *genpd)
 	return rcar_sysc_power_up(&to_rcar_pd(genpd)->ch);
 }
 
+#ifdef CONFIG_ARCH_R8A7795
+static int rcar_clk_pd_attach_dev(struct generic_pm_domain *genpd,
+				  struct device *dev)
+{
+	struct device_node *np = dev->of_node;
+	struct of_phandle_args clkspec;
+	struct clk *clk;
+	int i = 0;
+	int error;
+
+	while (!of_parse_phandle_with_args(np, "clocks", "#clock-cells", i,
+					   &clkspec)) {
+		if (clkspec.args_count == 2 && clkspec.args[0] == CPG_MOD &&
+		    of_device_is_compatible(clkspec.np,
+					    "renesas,r8a7795-cpg-mssr"))
+			goto found;
+
+		of_node_put(clkspec.np);
+		i++;
+	}
+
+	return 0;
+
+found:
+	clk = of_clk_get_from_provider(&clkspec);
+	of_node_put(clkspec.np);
+
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+
+	error = pm_clk_create(dev);
+	if (error) {
+		dev_err(dev, "pm_clk_create failed %d\n", error);
+		goto fail_put;
+	}
+
+	error = pm_clk_add_clk(dev, clk);
+	if (error) {
+		dev_err(dev, "pm_clk_add_clk %pC failed %d\n", clk, error);
+		goto fail_destroy;
+	}
+
+	return 0;
+
+fail_destroy:
+	pm_clk_destroy(dev);
+fail_put:
+	clk_put(clk);
+	return error;
+}
+
+static void rcar_clk_pd_detach_dev(struct generic_pm_domain *genpd,
+				   struct device *dev)
+{
+	if (!list_empty(&dev->power.subsys_data->clock_list))
+		pm_clk_destroy(dev);
+}
+#endif /* CONFIG_ARCH_R8A7795 */
+
 static void rcar_init_pm_domain(struct rcar_pm_domain *rcar_pd)
 {
 	struct generic_pm_domain *genpd = &rcar_pd->genpd;
 	struct dev_power_governor *gov = rcar_pd->gov;
 
+#ifdef CONFIG_ARCH_R8A7795
+	genpd->flags = GENPD_FLAG_PM_CLK;
+	genpd->attach_dev = rcar_clk_pd_attach_dev;
+	genpd->detach_dev = rcar_clk_pd_detach_dev;
+#endif
 	pm_genpd_init(genpd, gov ? : &simple_qos_governor, false);
 	genpd->dev_ops.active_wakeup	= rcar_pd_active_wakeup;
 	genpd->power_off		= rcar_pd_power_down;
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 13:16:58 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 22:16:58 +0100
Subject: [PATCH/RFC v2 09/11] ARM: dts: r8a7793: Add SYSC PM domains
In-Reply-To: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455571020-18968-10-git-send-email-geert+renesas@glider.be>

Add a device node for the System Controller, with subnodes that
represent the hardware power area hierarchy.
Hook up the first Cortex-A15 CPU core and the Cortex-A15 L2 cache/SCU to
their respective PM domains.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v2:
  - Change one-line summary prefix to match current arm-soc practices,
  - Update compatible values.
---
 arch/arm/boot/dts/r8a7793.dtsi | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 9a30f650aa515b80..843fd3306f35ebb0 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -43,6 +43,7 @@
 			voltage-tolerance = <1>; /* 1% */
 			clocks = <&cpg_clocks R8A7793_CLK_Z>;
 			clock-latency = <300000>; /* 300 us */
+			power-domains = <&pd_ca15_cpu0>;
 
 			/* kHz - uV - OPPs unknown yet */
 			operating-points = <1500000 1000000>,
@@ -57,6 +58,7 @@
 
 	L2_CA15: cache-controller at 0 {
 		compatible = "cache";
+		power-domains = <&pd_ca15_scu>;
 		cache-unified;
 		cache-level = <2>;
 	};
@@ -1144,6 +1146,43 @@
 		};
 	};
 
+	sysc: system-controller at e6180000 {
+		compatible = "renesas,r8a7793-sysc", "renesas,rcar-gen2-sysc";
+		reg = <0 0xe6180000 0 0x0200>;
+
+		pm-domains {
+			#address-cells = <2>;
+			#size-cells = <0>;
+
+			pd_ca15_scu: scu at 12 {
+				reg = <12 0x180>;
+				#address-cells = <2>;
+				#size-cells = <0>;
+				#power-domain-cells = <0>;
+
+				pd_ca15_cpu0: cpu at 0 {
+					reg = <0 0x40>;
+					#power-domain-cells = <0>;
+				};
+
+				pd_ca15_cpu1: cpu at 1 {
+					reg = <1 0x41>;
+					#power-domain-cells = <0>;
+				};
+			};
+
+			pd_sh: sh at 16 {
+				reg = <16 0x80>;
+				#power-domain-cells = <0>;
+			};
+
+			pd_sgx: sgx at 20 {
+				reg = <20 0xc0>;
+				#power-domain-cells = <0>;
+			};
+		};
+	};
+
 	ipmmu_sy0: mmu at e6280000 {
 		compatible = "renesas,ipmmu-r8a7793", "renesas,ipmmu-vmsa";
 		reg = <0 0xe6280000 0 0x1000>;
-- 
1.9.1



From geert+renesas at glider.be  Mon Feb 15 13:16:51 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Mon, 15 Feb 2016 22:16:51 +0100
Subject: [PATCH/RFC v2 02/11] soc: renesas: Move pm-rcar to
 drivers/soc/renesas/
In-Reply-To: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455571020-18968-3-git-send-email-geert+renesas@glider.be>

Move the pm-rcar driver to drivers/soc/renesas/, so it can be shared
between arm32 (R-Car H1 and Gen2) and arm64 (R-Car Gen3).

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
v2:
  - New.
---
 arch/arm/mach-shmobile/Kconfig                                  | 8 ++------
 arch/arm/mach-shmobile/Makefile                                 | 1 -
 arch/arm/mach-shmobile/pm-r8a7779.c                             | 3 ++-
 arch/arm/mach-shmobile/pm-rcar-gen2.c                           | 2 +-
 arch/arm/mach-shmobile/smp-r8a7779.c                            | 2 +-
 arch/arm/mach-shmobile/smp-r8a7790.c                            | 2 +-
 drivers/soc/Kconfig                                             | 1 +
 drivers/soc/Makefile                                            | 3 ++-
 drivers/soc/renesas/Kconfig                                     | 8 ++++++++
 drivers/soc/renesas/Makefile                                    | 1 +
 {arch/arm/mach-shmobile => drivers/soc/renesas}/pm-rcar.c       | 2 +-
 {arch/arm/mach-shmobile => include/linux/soc/renesas}/pm-rcar.h | 2 ++
 12 files changed, 22 insertions(+), 13 deletions(-)
 create mode 100644 drivers/soc/renesas/Kconfig
 create mode 100644 drivers/soc/renesas/Makefile
 rename {arch/arm/mach-shmobile => drivers/soc/renesas}/pm-rcar.c (99%)
 rename {arch/arm/mach-shmobile => include/linux/soc/renesas}/pm-rcar.h (93%)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index cd5f171f83ce6420..e45479d5104ea91a 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -4,23 +4,19 @@ config ARCH_SHMOBILE
 config ARCH_SHMOBILE_MULTI
 	bool
 
-config PM_RCAR
-	bool
-	select PM_GENERIC_DOMAINS if PM
-
 config PM_RMOBILE
 	bool
 	select PM_GENERIC_DOMAINS
 
 config ARCH_RCAR_GEN1
 	bool
-	select PM_RCAR if PM || SMP
+	select RENESAS_RCAR_PM if PM || SMP
 	select RENESAS_INTC_IRQPIN
 	select SYS_SUPPORTS_SH_TMU
 
 config ARCH_RCAR_GEN2
 	bool
-	select PM_RCAR if PM || SMP
+	select RENESAS_RCAR_PM if PM || SMP
 	select RENESAS_IRQC
 	select SYS_SUPPORTS_SH_CMT
 	select PCI_DOMAINS if PCI
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index a65c80ac9009d51f..ebb909c55b856a58 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -39,7 +39,6 @@ smp-$(CONFIG_ARCH_EMEV2)	+= smp-emev2.o headsmp-scu.o platsmp-scu.o
 # PM objects
 obj-$(CONFIG_SUSPEND)		+= suspend.o
 obj-$(CONFIG_CPU_FREQ)		+= cpufreq.o
-obj-$(CONFIG_PM_RCAR)		+= pm-rcar.o
 obj-$(CONFIG_PM_RMOBILE)	+= pm-rmobile.o
 obj-$(CONFIG_ARCH_RCAR_GEN2)	+= pm-rcar-gen2.o
 
diff --git a/arch/arm/mach-shmobile/pm-r8a7779.c b/arch/arm/mach-shmobile/pm-r8a7779.c
index 14c42a1bdf1ef20d..314cc47738252ae6 100644
--- a/arch/arm/mach-shmobile/pm-r8a7779.c
+++ b/arch/arm/mach-shmobile/pm-r8a7779.c
@@ -9,9 +9,10 @@
  * for more details.
  */
 
+#include <linux/soc/renesas/pm-rcar.h>
+
 #include <asm/io.h>
 
-#include "pm-rcar.h"
 #include "r8a7779.h"
 
 /* SYSC */
diff --git a/arch/arm/mach-shmobile/pm-rcar-gen2.c b/arch/arm/mach-shmobile/pm-rcar-gen2.c
index 6815781ad1165ef3..13ef9a8f5bf74090 100644
--- a/arch/arm/mach-shmobile/pm-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/pm-rcar-gen2.c
@@ -13,9 +13,9 @@
 #include <linux/kernel.h>
 #include <linux/of.h>
 #include <linux/smp.h>
+#include <linux/soc/renesas/pm-rcar.h>
 #include <asm/io.h>
 #include "common.h"
-#include "pm-rcar.h"
 #include "rcar-gen2.h"
 
 /* RST */
diff --git a/arch/arm/mach-shmobile/smp-r8a7779.c b/arch/arm/mach-shmobile/smp-r8a7779.c
index f5c31fbc10b2efbf..12e4804a1985012e 100644
--- a/arch/arm/mach-shmobile/smp-r8a7779.c
+++ b/arch/arm/mach-shmobile/smp-r8a7779.c
@@ -19,13 +19,13 @@
 #include <linux/spinlock.h>
 #include <linux/io.h>
 #include <linux/delay.h>
+#include <linux/soc/renesas/pm-rcar.h>
 
 #include <asm/cacheflush.h>
 #include <asm/smp_plat.h>
 #include <asm/smp_scu.h>
 
 #include "common.h"
-#include "pm-rcar.h"
 #include "r8a7779.h"
 
 #define AVECR IOMEM(0xfe700040)
diff --git a/arch/arm/mach-shmobile/smp-r8a7790.c b/arch/arm/mach-shmobile/smp-r8a7790.c
index f6426c6fdefcb489..79a0f7b86ce9149a 100644
--- a/arch/arm/mach-shmobile/smp-r8a7790.c
+++ b/arch/arm/mach-shmobile/smp-r8a7790.c
@@ -17,12 +17,12 @@
 #include <linux/init.h>
 #include <linux/smp.h>
 #include <linux/io.h>
+#include <linux/soc/renesas/pm-rcar.h>
 
 #include <asm/smp_plat.h>
 
 #include "common.h"
 #include "platsmp-apmu.h"
-#include "pm-rcar.h"
 #include "rcar-gen2.h"
 #include "r8a7790.h"
 
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 88260205a2614c84..5d76c14ef98cdc26 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -5,6 +5,7 @@ source "drivers/soc/brcmstb/Kconfig"
 source "drivers/soc/fsl/qe/Kconfig"
 source "drivers/soc/mediatek/Kconfig"
 source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/renesas/Kconfig"
 source "drivers/soc/rockchip/Kconfig"
 source "drivers/soc/sunxi/Kconfig"
 source "drivers/soc/tegra/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 2afdc74f7491adf0..298ee4157bb6d9a0 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -9,7 +9,8 @@ obj-$(CONFIG_MACH_DOVE)		+= dove/
 obj-y				+= fsl/
 obj-$(CONFIG_ARCH_MEDIATEK)	+= mediatek/
 obj-$(CONFIG_ARCH_QCOM)		+= qcom/
-obj-$(CONFIG_ARCH_ROCKCHIP)		+= rockchip/
+obj-$(CONFIG_ARCH_RENESAS)	+= renesas/
+obj-$(CONFIG_ARCH_ROCKCHIP)	+= rockchip/
 obj-$(CONFIG_ARCH_SUNXI)	+= sunxi/
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
 obj-$(CONFIG_SOC_TI)		+= ti/
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
new file mode 100644
index 0000000000000000..b2e4d31555c285f0
--- /dev/null
+++ b/drivers/soc/renesas/Kconfig
@@ -0,0 +1,8 @@
+#
+# Renesas SoC drivers
+#
+
+config RENESAS_RCAR_PM
+	bool
+	select PM_GENERIC_DOMAINS if PM
+	default y if ARCH_RENESAS && ARM64
diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
new file mode 100644
index 0000000000000000..36b8aedf2ef4195f
--- /dev/null
+++ b/drivers/soc/renesas/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_RENESAS_RCAR_PM)	+= pm-rcar.o
diff --git a/arch/arm/mach-shmobile/pm-rcar.c b/drivers/soc/renesas/pm-rcar.c
similarity index 99%
rename from arch/arm/mach-shmobile/pm-rcar.c
rename to drivers/soc/renesas/pm-rcar.c
index 0af05d288b09c3ab..bc605d9fbc6ce79c 100644
--- a/arch/arm/mach-shmobile/pm-rcar.c
+++ b/drivers/soc/renesas/pm-rcar.c
@@ -13,7 +13,7 @@
 #include <linux/mm.h>
 #include <linux/spinlock.h>
 #include <linux/io.h>
-#include "pm-rcar.h"
+#include <linux/soc/renesas/pm-rcar.h>
 
 /* SYSC Common */
 #define SYSCSR			0x00	/* SYSC Status Register */
diff --git a/arch/arm/mach-shmobile/pm-rcar.h b/include/linux/soc/renesas/pm-rcar.h
similarity index 93%
rename from arch/arm/mach-shmobile/pm-rcar.h
rename to include/linux/soc/renesas/pm-rcar.h
index 1b901db4a24c4633..bfeb647ffd9d2e12 100644
--- a/arch/arm/mach-shmobile/pm-rcar.h
+++ b/include/linux/soc/renesas/pm-rcar.h
@@ -1,6 +1,8 @@
 #ifndef PM_RCAR_H
 #define PM_RCAR_H
 
+#include <linux/types.h>
+
 struct rcar_sysc_ch {
 	u16 chan_offs;
 	u8 chan_bit;
-- 
1.9.1



From tony at atomide.com  Mon Feb 15 13:31:54 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 15 Feb 2016 13:31:54 -0800
Subject: [PATCH] clk: ti: omap3+: dpll: use non-locking version of
 clk_get_rate
In-Reply-To: <20160128191949.GK19432@atomide.com>
References: <1453981067-8618-1-git-send-email-t-kristo@ti.com>
 <56A9FED1.3090903@ti.com> <20160128172215.GD19432@atomide.com>
 <56AA6261.7030503@ti.com> <20160128190026.GI19432@atomide.com>
 <56AA6775.5090302@ti.com> <20160128191949.GK19432@atomide.com>
Message-ID: <20160215213153.GC19432@atomide.com>

* Tony Lindgren <tony at atomide.com> [160128 11:20]:
> * Tero Kristo <t-kristo at ti.com> [160128 11:10]:
> > On 01/28/2016 09:00 PM, Tony Lindgren wrote:
> > >* Tero Kristo <t-kristo at ti.com> [160128 10:48]:
> > >>On 01/28/2016 07:22 PM, Tony Lindgren wrote:
> > >>>* Tero Kristo <t-kristo at ti.com> [160128 03:44]:
> > >>>>On 01/28/2016 01:37 PM, Tero Kristo wrote:
> > >>>>>As the code in this file is being executed within irq context in some
> > >>>>>cases, we must avoid the clk_get_rate which uses mutex internally.
> > >>>>>Switch the code to use clk_hw_get_rate instead which is non-locking.
> > >>>>>
> > >>>>>Signed-off-by: Tero Kristo <t-kristo at ti.com>
> > >>>>
> > >>>>Ooops, sorry. Sent wrong version (read: old) of this patch, please ignore
> > >>>>this one. Will re-send the correct version in a bit.
> > >>>
> > >>>I think this is still needed as a fix for -rc cycle with cc: stable
> > >>>as otherwise we have omap4 and 5 hang if PM runtime is enabled before
> > >>>a suspend/resume cycle?
> > >>
> > >>Look at the other patch I sent, it should accomplish the same thing, and
> > >>more.
> > >>
> > >>https://www.spinics.net/lists/linux-clk/msg06094.html
> > >
> > >Right.. But is that suitable for the -rc cycle with cc stable?
> > 
> > Hmm yea, thats a good question, we may need to resurrect this patch after
> > all.
> 
> Yes a minimal fix first with cc stable, then the rest of the changes
> can be done for v4.6?
> 
> > >You should also describe the bug it causes in the change log.
> > >Something like:
> > >
> > >This fixes an issue where PM runtime will hang the system if
> > >enabled with a serial console before a suspend-resume cycle.
> > 
> > Yea I can add this to the desc if we want to keep this version of the patch.
> 
> Yes please. It seems the fix should be cc stable for several merge
> windows.

Tero, what's the status on this one? We have systems hang shortly
after entering init if PM is enabled without this one.

Regards,

Tony


From kirill at shutemov.name  Mon Feb 15 13:35:26 2016
From: kirill at shutemov.name (Kirill A. Shutemov)
Date: Mon, 15 Feb 2016 23:35:26 +0200
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160215193702.4a15ed5e@thinkpad>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
 <alpine.LFD.2.20.1602131238260.1910@schleppi>
 <20160215113159.GA28832@node.shutemov.name>
 <20160215193702.4a15ed5e@thinkpad>
Message-ID: <20160215213526.GA9766@node.shutemov.name>

On Mon, Feb 15, 2016 at 07:37:02PM +0100, Gerald Schaefer wrote:
> On Mon, 15 Feb 2016 13:31:59 +0200
> "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> 
> > On Sat, Feb 13, 2016 at 12:58:31PM +0100, Sebastian Ott wrote:
> > > 
> > > On Sat, 13 Feb 2016, Kirill A. Shutemov wrote:
> > > > Could you check if revert of fecffad25458 helps?
> > > 
> > > I reverted fecffad25458 on top of 721675fcf277cf - it oopsed with:
> > > 
> > > ? 1851.721062! Unable to handle kernel pointer dereference in virtual kernel address space
> > > ? 1851.721075! failing address: 0000000000000000 TEID: 0000000000000483
> > > ? 1851.721078! Fault in home space mode while using kernel ASCE.
> > > ? 1851.721085! AS:0000000000d5c007 R3:00000000ffff0007 S:00000000ffffa800 P:000000000000003d
> > > ? 1851.721128! Oops: 0004 ilc:3 ?#1! PREEMPT SMP DEBUG_PAGEALLOC
> > > ? 1851.721135! Modules linked in: bridge stp llc btrfs mlx4_ib mlx4_en ib_sa ib_mad vxlan xor ip6_udp_tunnel ib_core udp_tunnel ptp pps_core ib_addr ghash_s390raid6_pq prng ecb aes_s390 mlx4_core des_s390 des_generic genwqe_card sha512_s390 sha256_s390 sha1_s390 sha_common crc_itu_t dm_mod scm_block vhost_net tun vhost eadm_sch macvtap macvlan kvm autofs4
> > > ? 1851.721183! CPU: 7 PID: 256422 Comm: bash Not tainted 4.5.0-rc3-00058-g07923d7-dirty #178
> > > ? 1851.721186! task: 000000007fbfd290 ti: 000000008c604000 task.ti: 000000008c604000
> > > ? 1851.721189! Krnl PSW : 0704d00180000000 000000000045d3b8 (__rb_erase_color+0x280/0x308)
> > > ? 1851.721200!            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
> > >                Krnl GPRS: 0000000000000001 0000000000000020 0000000000000000 00000000bd07eff1
> > > ? 1851.721205!            000000000027ca10 0000000000000000 0000000083e45898 0000000077b61198
> > > ? 1851.721207!            000000007ce1a490 00000000bd07eff0 000000007ce1a548 000000000027ca10
> > > ? 1851.721210!            00000000bd07c350 00000000bd07eff0 000000008c607aa8 000000008c607a68
> > > ? 1851.721221! Krnl Code: 000000000045d3aa: e3c0d0080024       stg     %%r12,8(%%r13)
> > >                           000000000045d3b0: b9040039           lgr     %%r3,%%r9
> > >                          #000000000045d3b4: a53b0001           oill    %%r3,1
> > >                          >000000000045d3b8: e33010000024       stg     %%r3,0(%%r1)
> > >                           000000000045d3be: ec28000e007c       cgij    %%r2,0,8,45d3da
> > >                           000000000045d3c4: e34020000004       lg      %%r4,0(%%r2)
> > >                           000000000045d3ca: b904001c           lgr     %%r1,%%r12
> > >                           000000000045d3ce: ec143f3f0056       rosbg   %%r1,%%r4,63,63,0
> > > ? 1851.721269! Call Trace:
> > > ? 1851.721273! (?<0000000083e45898>! 0x83e45898)
> > > ? 1851.721279!  ?<000000000029342a>! unlink_anon_vmas+0x9a/0x1d8
> > > ? 1851.721282!  ?<0000000000283f34>! free_pgtables+0xcc/0x148
> > > ? 1851.721285!  ?<000000000028c376>! exit_mmap+0xd6/0x300
> > > ? 1851.721289!  ?<0000000000134db8>! mmput+0x90/0x118
> > > ? 1851.721294!  ?<00000000002d76bc>! flush_old_exec+0x5d4/0x700
> > > ? 1851.721298!  ?<00000000003369f4>! load_elf_binary+0x2f4/0x13e8
> > > ? 1851.721301!  ?<00000000002d6e4a>! search_binary_handler+0x9a/0x1f8
> > > ? 1851.721304!  ?<00000000002d8970>! do_execveat_common.isra.32+0x668/0x9a0
> > > ? 1851.721307!  ?<00000000002d8cec>! do_execve+0x44/0x58
> > > ? 1851.721310!  ?<00000000002d8f92>! SyS_execve+0x3a/0x48
> > > ? 1851.721315!  ?<00000000006fb096>! system_call+0xd6/0x258
> > > ? 1851.721317!  ?<000003ff997436d6>! 0x3ff997436d6
> > > ? 1851.721319! INFO: lockdep is turned off.
> > > ? 1851.721321! Last Breaking-Event-Address:
> > > ? 1851.721323!  ?<000000000045d31a>! __rb_erase_color+0x1e2/0x308
> > > ? 1851.721327!
> > > ? 1851.721329! ---? end trace 0d80041ac00cfae2 !---
> > > 
> > > 
> > > > 
> > > > And could you share how crashes looks like? I haven't seen backtraces yet.
> > > > 
> > > 
> > > Sure. I didn't because they really looked random to me. Most of the time
> > > in rcu or list debugging but I thought these have just been the messenger
> > > observing a corruption first. Anyhow, here is an older one that might look
> > > interesting:
> > > 
> > > [   59.851421] list_del corruption. next->prev should be 000000006e1eb000, but was 0000000000000400
> > 
> > This kinda interesting: 0x400 is TAIL_MAPPING.. Hm..
> > 
> > Could you check if you see the problem on commit 1c290f642101 and its
> > immediate parent?
> > 
> 
> How should the page->mapping poison end up as next->prev in the list of
> pre-allocated THP splitting page tables?

May be pgtable was casted to struct page or something. I don't know.

> Also, commit 1c290f642101 is before the THP rework, at least the
> non-bisectable part, so we should expect not to see the problem there.

Just to make sure: commit 122afea9626a is fine, commit 61f5d698cc97
crashes. Correct?

> 0x400 is also the value of an empty pte on s390, and the thp_deposit/withdraw
> listheads are placed inside the pre-allocated pagetables instead of page->lru,
> because we have 2K pagetables on s390 and cannot use struct page == pgtable_t.

0x400 from empty pte makes more sense than TAIL_MAPPING. But I guess it
worth changing TAIL_MAPPING to some other value to make sure.

> So, for example, two concurrent withdraws could produce such a list
> corruption, because the first withdraw will overwrite the listhead at the
> beginning of the pagetable with 2 empty ptes.
> 
> Has anything changed regarding the general THP deposit/withdraw logic?

I don't see any changes in this area.

To eliminate one more variable, I would propose to disable split pmd lock
for testing and check if it makes difference.

Is there any chance that I'll be able to trigger the bug using QEMU?
Does anybody have an QEMU image I can use?

-- 
 Kirill A. Shutemov


From tony at atomide.com  Mon Feb 15 13:36:07 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 15 Feb 2016 13:36:07 -0800
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor:
 Replace timers with utilization ...'
In-Reply-To: <CAJZ5v0hzVB0+H4nuCun3mmrES3UQ3+Rs1uz5YGu5sv4G3XU+nQ@mail.gmail.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
 <20160215190116.GX19432@atomide.com>
 <56C229A5.8020901@roeck-us.net>
 <20160215195839.GA19432@atomide.com>
 <CAJZ5v0hzVB0+H4nuCun3mmrES3UQ3+Rs1uz5YGu5sv4G3XU+nQ@mail.gmail.com>
Message-ID: <20160215213606.GD19432@atomide.com>

* Rafael J. Wysocki <rafael at kernel.org> [160215 12:39]:
> On Mon, Feb 15, 2016 at 8:58 PM, Tony Lindgren <tony at atomide.com> wrote:
> > * Guenter Roeck <linux at roeck-us.net> [160215 11:41]:
> >> On 02/15/2016 11:01 AM, Tony Lindgren wrote:
> >> >
> >> >https://kernelci.org/boot/all/job/next/kernel/next-20160215/
> >> >
> >> >The SMP ones seem to fail with some regulator issues?
> >> >
> >>
> >> There is another problem, introduced with 6a0712f6f199e ("PM / OPP: Add
> >> dev_pm_opp_set_rate()"). The kernelci boot log for next-20160212:omap3-overo-tobi
> >> and others experience that problem.
> >>
> >> Essentially, the code now assumes that a CPU clock always has a voltage
> >> regulator attached to it, which is not correct. I sent out a patch to fix
> >> that problem a minute ago.
> >
> > Yes that fixed it thanks.
> 
> Can you please also check if this alternative fix from Viresh works:
> 
> https://patchwork.kernel.org/patch/8316611/

Yes that one too seems to fix the issue on SMP systems for
me:

Tested-by: Tony Lindgren <tony at atomide.com>

Regards,

Tony


From horms+renesas at verge.net.au  Mon Feb 15 13:48:45 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 16 Feb 2016 06:48:45 +0900
Subject: [PATCH] ARM: dts: r8a7794: replace gpio-key,
 wakeup with wakeup-source property
Message-ID: <1455572925-27697-1-git-send-email-horms+renesas@verge.net.au>

Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
check for/support the legacy "gpio-key,wakeup" boolean property to
enable gpio buttons as wakeup source, "wakeup-source" is the new
standard binding.

This patch replaces the legacy "gpio-key,wakeup" with the unified
"wakeup-source" property in order to avoid any futher copy-paste
duplication.

Changelog text from a similar patch by Sudeep Holla.

Cc: Sudeep Holla <sudeep.holla at arm.com>
Reported-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index cfe142c2ba38..87e89ec9dd47 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -67,77 +67,77 @@
 		        gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_1>;
 		        label = "SW2-1";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-2 {
 		        gpios = <&gpio5 1 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_2>;
 		        label = "SW2-2";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-3 {
 		        gpios = <&gpio5 2 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_3>;
 		        label = "SW2-3";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-4 {
 		        gpios = <&gpio5 3 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_4>;
 		        label = "SW2-4";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-a {
 		        gpios = <&gpio7 0 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_A>;
 		        label = "SW30";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-b {
 		        gpios = <&gpio7 1 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_B>;
 		        label = "SW31";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-c {
 		        gpios = <&gpio7 2 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_C>;
 		        label = "SW32";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-d {
 		        gpios = <&gpio7 3 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_D>;
 		        label = "SW33";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-e {
 		        gpios = <&gpio7 4 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_E>;
 		        label = "SW34";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-f {
 		        gpios = <&gpio7 5 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_F>;
 		        label = "SW35";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-g {
 		        gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_G>;
 		        label = "SW36";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms at verge.net.au  Mon Feb 15 13:55:12 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 16 Feb 2016 06:55:12 +0900
Subject: [PATCH] ARM: dts: porter: fix JP3 jumper description
In-Reply-To: <87fuwuinsh.wl%kuninori.morimoto.gx@renesas.com>
References: <1674850.BZpGW9kEud@wasted.cogentembedded.com>
 <1655804.y4T36KvG5v@wasted.cogentembedded.com>
 <87fuwuinsh.wl%kuninori.morimoto.gx@renesas.com>
Message-ID: <20160215215512.GB15913@verge.net.au>

On Mon, Feb 15, 2016 at 04:50:17AM +0000, Kuninori Morimoto wrote:
> 
> Hi
> 
> > When finishing the Porter sound support patch, I managed to call the JP3
> > jumper SW3 in the comment.  Fix this  along with (also miscalled) jumper
> > positions...
> > 
> > Fixes: 493b4da7c10c ("ARM: dts: porter: add sound support")
> > Reported-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> 
> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

Thanks, I have queued this up.


From horms at verge.net.au  Mon Feb 15 13:57:02 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 16 Feb 2016 06:57:02 +0900
Subject: [PATCH v2] arm64: dts: r8a7795: use GIC_* defines
In-Reply-To: <CAMuHMdXPk5Or5F6YDuicMxQioYqpf49m2XFvA25145xUyC0xAA@mail.gmail.com>
References: <20160202133103.GK15554@verge.net.au>
 <CAMuHMdXPk5Or5F6YDuicMxQioYqpf49m2XFvA25145xUyC0xAA@mail.gmail.com>
Message-ID: <20160215215701.GC15913@verge.net.au>

On Mon, Feb 15, 2016 at 09:21:29AM +0100, Geert Uytterhoeven wrote:
> On Tue, Feb 2, 2016 at 2:31 PM, Simon Horman <horms+renesas at verge.net.au> wrote:
> > Use GIC_* defines for GIC interrupt cells in r8a7795 device tree.
> >
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>

Thanks, I have queued this up.


From horms at verge.net.au  Mon Feb 15 13:59:04 2016
From: horms at verge.net.au (Simon Horman)
Date: Tue, 16 Feb 2016 06:59:04 +0900
Subject: [PATCH v3 0/2] ARM: shmobile: Avoid writing to .text
In-Reply-To: <1455538808-6816-1-git-send-email-geert+renesas@glider.be>
References: <1455538808-6816-1-git-send-email-geert+renesas@glider.be>
Message-ID: <20160215215904.GD15913@verge.net.au>

On Mon, Feb 15, 2016 at 01:20:06PM +0100, Geert Uytterhoeven wrote:
>         Hi Simon, Magnus,
> 
> When CONFIG_DEBUG_RODATA=y, the kernel crashes during system suspend:
> 
>     Freezing user space processes ... (elapsed 0.004 seconds) done.
>     Freezing remaining freezable tasks ... (elapsed 0.002 seconds)
>     done.
>     PM: suspend of devices complete after 111.948 msecs
>     PM: late suspend of devices complete after 1.086 msecs
>     PM: noirq suspend of devices complete after 11.576 msecs
>     Disabling non-boot CPUs ...
>     Kernel panic - not syncing: Attempted to kill the idle task!
>     1014ec ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
>     CPU0: stopping
> 
> This happens because the shmobile assembler sources have several
> variables that are written to in the .text section, while .text is
> mapped read-only after kernel bootup if CONFIG_DEBUG_RODATA=y.
> 
> This series fixes this by moving variables from .text to .bss, or just
> removing them.
> Note that there's still an issue with shmobile_boot_fn in
> arch/arm/mach-shmobile/headsmp.S.  So far I didn't manage to fix this
> (the code and data are copied to SRAM on some SoCs).  However, currently
> this is mostly harmless, as this is written to during early kernel boot
> up only, before .text is marked read-only. It does matter for XIP
> (anyone using that with SMP?), so we do want to fix that in the long
> run, too.
> 
> These issues were uncovered by "[PATCH v2] ARM: mm: flip priority of
> CONFIG_DEBUG_RODATA". As that patch is already queued in arm/for-next, I
> think all these fixes should be queued for v4.5, to avoid a dependency
> with the arm tree.

Thanks Geert,

I have queued these up.


From linus.walleij at linaro.org  Mon Feb 15 14:01:44 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 15 Feb 2016 23:01:44 +0100
Subject: linux-4.5-rc3/arch/arm/mach-ux500/cpu-db8500.c:89: statement
 after return ?
In-Reply-To: <DUB128-W6810AD43780578EF2A48789CD50@phx.gbl>
References: <DUB128-W6810AD43780578EF2A48789CD50@phx.gbl>
Message-ID: <CACRpkdbTB9VROfKyiyY4gzWQD-UHio1UnoYu-GuHkzgL5ZgoRw@mail.gmail.com>

On Mon, Feb 8, 2016 at 4:50 PM, David Binderman <dcb314 at hotmail.com> wrote:

> Hello there,
>
> [linux-4.5-rc3/arch/arm/mach-ux500/cpu-db8500.c:89]: (style) Statements following return, break, continue, goto or throw will never be executed.
>
> Source code is
>
>     return kasprintf(GFP_KERNEL, "%08x%08x%08x%08x%08x",
>              readl((u32 *)uid+0),
>              readl((u32 *)uid+1), readl((u32 *)uid+2),
>              readl((u32 *)uid+3), readl((u32 *)uid+4));
>     iounmap(uid);
> }
>
> This looks like a cut-n-paste error to me. Suggest rework.

I sent a patch for this, nice catch.

Yours,
Linus Walleij


From carlo at caione.org  Mon Feb 15 14:03:34 2016
From: carlo at caione.org (Carlo Caione)
Date: Mon, 15 Feb 2016 23:03:34 +0100
Subject: [PATCH] MAINTAINERS: Extend info, add wiki and ml for meson arch
Message-ID: <1455573814-13378-1-git-send-email-carlo@caione.org>

From: Carlo Caione <carlo at endlessm.com>

Update the maintainers info with wiki and mailing list for the meson
platform. Fix a wrong file attribution and add maintainership for
meson8b.

Signed-off-by: Carlo Caione <carlo at endlessm.com>
---
 MAINTAINERS | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 28eb61b..6e08d2a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -923,9 +923,11 @@ F:	drivers/clk/sunxi/
 ARM/Amlogic MesonX SoC support
 M:	Carlo Caione <carlo at caione.org>
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+L:	linux-meson at googlegroups.com
+W:	http://linux-meson.com/
 S:	Maintained
-F:	drivers/media/rc/meson-ir.c
-N:	meson[x68]
+F:	arch/arm/mach-meson/
+N:	meson[x68b]
 
 ARM/Annapurna Labs ALPINE ARCHITECTURE
 M:	Tsahee Zidenberg <tsahee at annapurnalabs.com>
-- 
1.9.1



From linus.walleij at linaro.org  Mon Feb 15 14:04:26 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 15 Feb 2016 23:04:26 +0100
Subject: [PATCH] pinctrl: sunxi: set pin function as input on export
In-Reply-To: <1454942242-25690-1-git-send-email-krzysztof.adamski@tieto.com>
References: <1454942242-25690-1-git-send-email-krzysztof.adamski@tieto.com>
Message-ID: <CACRpkdbd4f3yj2MnR6PU5SuhV5Tj4HzWLc0UX8jQkcJp7MoTig@mail.gmail.com>

On Mon, Feb 8, 2016 at 3:37 PM, Krzysztof Adamski
<krzysztof.adamski at tieto.com> wrote:

> Default function of a pin in sunxi SoCs is "disabled". By default gpios
> exported by sysfs are set as input and indeed, when reading "direction"
> file you will get "in". The "value" pin won't return proper value,
> though, confusing user of this interface.
>
> This patch sets direction of a GPIO as input when exporting it.
>
> Signed-off-by: Krzysztof Adamski <krzysztof.adamski at tieto.com>

As maxime says it's not a sunxi problem.

So maybe it is wrong to set pins to either input or output when
exporting them, I suspect they should be exported as is.

Also: the sysfs ABI is deprecated. I suggest you invest your time
in working on the new chardev ABI.

Yours,
Linus Walleij


From laurent.pinchart at ideasonboard.com  Mon Feb 15 14:08:16 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 16 Feb 2016 00:08:16 +0200
Subject: [PATCH/RFC v2 05/11] soc: renesas: rcar: Handle clock domain
 devices in SYSC PM domains
In-Reply-To: <1455571020-18968-6-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
 <1455571020-18968-6-git-send-email-geert+renesas@glider.be>
Message-ID: <2087210.c20JsV3rp3@avalon>

Hi Geert,

Thank you for the patch.

On Monday 15 February 2016 22:16:54 Geert Uytterhoeven wrote:
> R-Car H3 contains some hardware modules (e.g. VSP and FCP_V) that are
> not only located in a power area controlled by the SYSC system
> controller, but that are also part of the generic CPG/MSSR clock domain.
> Make sure both are handled by enabling module clock PM when the device
> for such a hardware module is attached to the SYSC PM Domain.

Can't we specify both power domains in the DT power-domains attribute instead 
?

> FIXME Share code with the renesas-cpg-mssr driver.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> ---
> v2:
>   - New.
> ---
> drivers/soc/renesas/pm-rcar.c | 68 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
> 
> diff --git a/drivers/soc/renesas/pm-rcar.c b/drivers/soc/renesas/pm-rcar.c
> index c0540934126e58eb..d1bf8c231540b11d 100644
> --- a/drivers/soc/renesas/pm-rcar.c
> +++ b/drivers/soc/renesas/pm-rcar.c
> @@ -9,16 +9,20 @@
>   * for more details.
>   */
> 
> +#include <linux/clk.h>
>  #include <linux/delay.h>
>  #include <linux/err.h>
>  #include <linux/mm.h>
>  #include <linux/of_address.h>
> +#include <linux/pm_clock.h>
>  #include <linux/pm_domain.h>
>  #include <linux/slab.h>
>  #include <linux/spinlock.h>
>  #include <linux/io.h>
>  #include <linux/soc/renesas/pm-rcar.h>
> 
> +#include <dt-bindings/clock/renesas-cpg-mssr.h>
> +
>  /* SYSC Common */
>  #define SYSCSR			0x00	/* SYSC Status Register */
>  #define SYSCISR			0x04	/* Interrupt Status Register */
> @@ -248,11 +252,75 @@ static int rcar_pd_power_up(struct generic_pm_domain
> *genpd) return rcar_sysc_power_up(&to_rcar_pd(genpd)->ch);
>  }
> 
> +#ifdef CONFIG_ARCH_R8A7795
> +static int rcar_clk_pd_attach_dev(struct generic_pm_domain *genpd,
> +				  struct device *dev)
> +{
> +	struct device_node *np = dev->of_node;
> +	struct of_phandle_args clkspec;
> +	struct clk *clk;
> +	int i = 0;
> +	int error;
> +
> +	while (!of_parse_phandle_with_args(np, "clocks", "#clock-cells", i,
> +					   &clkspec)) {
> +		if (clkspec.args_count == 2 && clkspec.args[0] == CPG_MOD &&
> +		    of_device_is_compatible(clkspec.np,
> +					    "renesas,r8a7795-cpg-mssr"))
> +			goto found;
> +
> +		of_node_put(clkspec.np);
> +		i++;
> +	}
> +
> +	return 0;
> +
> +found:
> +	clk = of_clk_get_from_provider(&clkspec);
> +	of_node_put(clkspec.np);
> +
> +	if (IS_ERR(clk))
> +		return PTR_ERR(clk);
> +
> +	error = pm_clk_create(dev);
> +	if (error) {
> +		dev_err(dev, "pm_clk_create failed %d\n", error);
> +		goto fail_put;
> +	}
> +
> +	error = pm_clk_add_clk(dev, clk);
> +	if (error) {
> +		dev_err(dev, "pm_clk_add_clk %pC failed %d\n", clk, error);
> +		goto fail_destroy;
> +	}
> +
> +	return 0;
> +
> +fail_destroy:
> +	pm_clk_destroy(dev);
> +fail_put:
> +	clk_put(clk);
> +	return error;
> +}
> +
> +static void rcar_clk_pd_detach_dev(struct generic_pm_domain *genpd,
> +				   struct device *dev)
> +{
> +	if (!list_empty(&dev->power.subsys_data->clock_list))
> +		pm_clk_destroy(dev);
> +}
> +#endif /* CONFIG_ARCH_R8A7795 */
> +
>  static void rcar_init_pm_domain(struct rcar_pm_domain *rcar_pd)
>  {
>  	struct generic_pm_domain *genpd = &rcar_pd->genpd;
>  	struct dev_power_governor *gov = rcar_pd->gov;
> 
> +#ifdef CONFIG_ARCH_R8A7795
> +	genpd->flags = GENPD_FLAG_PM_CLK;
> +	genpd->attach_dev = rcar_clk_pd_attach_dev;
> +	genpd->detach_dev = rcar_clk_pd_detach_dev;
> +#endif
>  	pm_genpd_init(genpd, gov ? : &simple_qos_governor, false);
>  	genpd->dev_ops.active_wakeup	= rcar_pd_active_wakeup;
>  	genpd->power_off		= rcar_pd_power_down;

-- 
Regards,

Laurent Pinchart



From laurent.pinchart at ideasonboard.com  Mon Feb 15 14:11:24 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 16 Feb 2016 00:11:24 +0200
Subject: [PATCH/RFC v2 03/11] soc: renesas: Improve rcar_sysc_power()
 debug info
In-Reply-To: <1455571020-18968-4-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
 <1455571020-18968-4-git-send-email-geert+renesas@glider.be>
Message-ID: <1640540.sfVMLcT3LH@avalon>

Hi Geert,

Thank you for the patch.

On Monday 15 February 2016 22:16:52 Geert Uytterhoeven wrote:
> Print requested power domain state.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> ---
> v2:
>   - New.
> ---
>  drivers/soc/renesas/pm-rcar.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/renesas/pm-rcar.c b/drivers/soc/renesas/pm-rcar.c
> index bc605d9fbc6ce79c..cc684e9cc8db5d1c 100644
> --- a/drivers/soc/renesas/pm-rcar.c
> +++ b/drivers/soc/renesas/pm-rcar.c
> @@ -128,7 +128,7 @@ static int rcar_sysc_power(const struct rcar_sysc_ch
> *sysc_ch, bool on) out:
>  	spin_unlock_irqrestore(&rcar_sysc_lock, flags);
> 
> -	pr_debug("sysc power domain %d: %08x -> %d\n",
> +	pr_debug("sysc power %s domain %d: %08x -> %d\n", on ? "on" : "off",
>  		 sysc_ch->isr_bit, ioread32(rcar_sysc_base + SYSCISR), ret);
>  	return ret;
>  }

-- 
Regards,

Laurent Pinchart



From carlo at caione.org  Mon Feb 15 14:12:08 2016
From: carlo at caione.org (Carlo Caione)
Date: Mon, 15 Feb 2016 23:12:08 +0100
Subject: [PATCH] MAINTAINERS: Extend info, add wiki and ml for meson arch
In-Reply-To: <1455573814-13378-1-git-send-email-carlo@caione.org>
References: <1455573814-13378-1-git-send-email-carlo@caione.org>
Message-ID: <CAOQ7t2bbv2mgKd8OzNmeOTf0PWL3Br1RP5uX-bq+TQjDwE=Wkg@mail.gmail.com>

On Mon, Feb 15, 2016 at 11:03 PM, Carlo Caione <carlo at caione.org> wrote:
> From: Carlo Caione <carlo at endlessm.com>
>
> Update the maintainers info with wiki and mailing list for the meson
> platform. Fix a wrong file attribution and add maintainership for
> meson8b.
>
> Signed-off-by: Carlo Caione <carlo at endlessm.com>
> ---
>  MAINTAINERS | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 28eb61b..6e08d2a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -923,9 +923,11 @@ F: drivers/clk/sunxi/
>  ARM/Amlogic MesonX SoC support
>  M:     Carlo Caione <carlo at caione.org>
>  L:     linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +L:     linux-meson at googlegroups.com
> +W:     http://linux-meson.com/
>  S:     Maintained
> -F:     drivers/media/rc/meson-ir.c
> -N:     meson[x68]
> +F:     arch/arm/mach-meson/
> +N:     meson[x68b]

Submitting soon a V2 since this doesn't match meson8b.

-- 
Carlo Caione


From laurent.pinchart at ideasonboard.com  Mon Feb 15 14:12:52 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 16 Feb 2016 00:12:52 +0200
Subject: [PATCH/RFC v2 02/11] soc: renesas: Move pm-rcar to
 drivers/soc/renesas/
In-Reply-To: <1455571020-18968-3-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
 <1455571020-18968-3-git-send-email-geert+renesas@glider.be>
Message-ID: <2551067.YVPTHA6AER@avalon>

Hi Geert,

Thank you for the patch.

On Monday 15 February 2016 22:16:51 Geert Uytterhoeven wrote:
> Move the pm-rcar driver to drivers/soc/renesas/, so it can be shared
> between arm32 (R-Car H1 and Gen2) and arm64 (R-Car Gen3).
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>

Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>

> ---
> v2:
>   - New.
> ---
> arch/arm/mach-shmobile/Kconfig                                  | 8 ++-----
> arch/arm/mach-shmobile/Makefile                                 | 1 -
> arch/arm/mach-shmobile/pm-r8a7779.c                             | 3 ++-
> arch/arm/mach-shmobile/pm-rcar-gen2.c                           | 2 +-
> arch/arm/mach-shmobile/smp-r8a7779.c                            | 2 +-
> arch/arm/mach-shmobile/smp-r8a7790.c                            | 2 +-
> drivers/soc/Kconfig                                             | 1 +
> drivers/soc/Makefile                                            | 3 ++-
> drivers/soc/renesas/Kconfig                                     | 8 ++++++++
> drivers/soc/renesas/Makefile                                    | 1 +
> {arch/arm/mach-shmobile => drivers/soc/renesas}/pm-rcar.c       | 2 +-
> {arch/arm/mach-shmobile => include/linux/soc/renesas}/pm-rcar.h | 2 ++
> 12 files changed, 22 insertions(+), 13 deletions(-)
>  create mode 100644 drivers/soc/renesas/Kconfig
>  create mode 100644 drivers/soc/renesas/Makefile
>  rename {arch/arm/mach-shmobile => drivers/soc/renesas}/pm-rcar.c (99%)
>  rename {arch/arm/mach-shmobile => include/linux/soc/renesas}/pm-rcar.h
> (93%)
> 
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index cd5f171f83ce6420..e45479d5104ea91a 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -4,23 +4,19 @@ config ARCH_SHMOBILE
>  config ARCH_SHMOBILE_MULTI
>  	bool
> 
> -config PM_RCAR
> -	bool
> -	select PM_GENERIC_DOMAINS if PM
> -
>  config PM_RMOBILE
>  	bool
>  	select PM_GENERIC_DOMAINS
> 
>  config ARCH_RCAR_GEN1
>  	bool
> -	select PM_RCAR if PM || SMP
> +	select RENESAS_RCAR_PM if PM || SMP
>  	select RENESAS_INTC_IRQPIN
>  	select SYS_SUPPORTS_SH_TMU
> 
>  config ARCH_RCAR_GEN2
>  	bool
> -	select PM_RCAR if PM || SMP
> +	select RENESAS_RCAR_PM if PM || SMP
>  	select RENESAS_IRQC
>  	select SYS_SUPPORTS_SH_CMT
>  	select PCI_DOMAINS if PCI
> diff --git a/arch/arm/mach-shmobile/Makefile
> b/arch/arm/mach-shmobile/Makefile index a65c80ac9009d51f..ebb909c55b856a58
> 100644
> --- a/arch/arm/mach-shmobile/Makefile
> +++ b/arch/arm/mach-shmobile/Makefile
> @@ -39,7 +39,6 @@ smp-$(CONFIG_ARCH_EMEV2)	+= smp-emev2.o headsmp-scu.o
> platsmp-scu.o # PM objects
>  obj-$(CONFIG_SUSPEND)		+= suspend.o
>  obj-$(CONFIG_CPU_FREQ)		+= cpufreq.o
> -obj-$(CONFIG_PM_RCAR)		+= pm-rcar.o
>  obj-$(CONFIG_PM_RMOBILE)	+= pm-rmobile.o
>  obj-$(CONFIG_ARCH_RCAR_GEN2)	+= pm-rcar-gen2.o
> 
> diff --git a/arch/arm/mach-shmobile/pm-r8a7779.c
> b/arch/arm/mach-shmobile/pm-r8a7779.c index
> 14c42a1bdf1ef20d..314cc47738252ae6 100644
> --- a/arch/arm/mach-shmobile/pm-r8a7779.c
> +++ b/arch/arm/mach-shmobile/pm-r8a7779.c
> @@ -9,9 +9,10 @@
>   * for more details.
>   */
> 
> +#include <linux/soc/renesas/pm-rcar.h>
> +
>  #include <asm/io.h>
> 
> -#include "pm-rcar.h"
>  #include "r8a7779.h"
> 
>  /* SYSC */
> diff --git a/arch/arm/mach-shmobile/pm-rcar-gen2.c
> b/arch/arm/mach-shmobile/pm-rcar-gen2.c index
> 6815781ad1165ef3..13ef9a8f5bf74090 100644
> --- a/arch/arm/mach-shmobile/pm-rcar-gen2.c
> +++ b/arch/arm/mach-shmobile/pm-rcar-gen2.c
> @@ -13,9 +13,9 @@
>  #include <linux/kernel.h>
>  #include <linux/of.h>
>  #include <linux/smp.h>
> +#include <linux/soc/renesas/pm-rcar.h>
>  #include <asm/io.h>
>  #include "common.h"
> -#include "pm-rcar.h"
>  #include "rcar-gen2.h"
> 
>  /* RST */
> diff --git a/arch/arm/mach-shmobile/smp-r8a7779.c
> b/arch/arm/mach-shmobile/smp-r8a7779.c index
> f5c31fbc10b2efbf..12e4804a1985012e 100644
> --- a/arch/arm/mach-shmobile/smp-r8a7779.c
> +++ b/arch/arm/mach-shmobile/smp-r8a7779.c
> @@ -19,13 +19,13 @@
>  #include <linux/spinlock.h>
>  #include <linux/io.h>
>  #include <linux/delay.h>
> +#include <linux/soc/renesas/pm-rcar.h>
> 
>  #include <asm/cacheflush.h>
>  #include <asm/smp_plat.h>
>  #include <asm/smp_scu.h>
> 
>  #include "common.h"
> -#include "pm-rcar.h"
>  #include "r8a7779.h"
> 
>  #define AVECR IOMEM(0xfe700040)
> diff --git a/arch/arm/mach-shmobile/smp-r8a7790.c
> b/arch/arm/mach-shmobile/smp-r8a7790.c index
> f6426c6fdefcb489..79a0f7b86ce9149a 100644
> --- a/arch/arm/mach-shmobile/smp-r8a7790.c
> +++ b/arch/arm/mach-shmobile/smp-r8a7790.c
> @@ -17,12 +17,12 @@
>  #include <linux/init.h>
>  #include <linux/smp.h>
>  #include <linux/io.h>
> +#include <linux/soc/renesas/pm-rcar.h>
> 
>  #include <asm/smp_plat.h>
> 
>  #include "common.h"
>  #include "platsmp-apmu.h"
> -#include "pm-rcar.h"
>  #include "rcar-gen2.h"
>  #include "r8a7790.h"
> 
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index 88260205a2614c84..5d76c14ef98cdc26 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -5,6 +5,7 @@ source "drivers/soc/brcmstb/Kconfig"
>  source "drivers/soc/fsl/qe/Kconfig"
>  source "drivers/soc/mediatek/Kconfig"
>  source "drivers/soc/qcom/Kconfig"
> +source "drivers/soc/renesas/Kconfig"
>  source "drivers/soc/rockchip/Kconfig"
>  source "drivers/soc/sunxi/Kconfig"
>  source "drivers/soc/tegra/Kconfig"
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 2afdc74f7491adf0..298ee4157bb6d9a0 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -9,7 +9,8 @@ obj-$(CONFIG_MACH_DOVE)		+= dove/
>  obj-y				+= fsl/
>  obj-$(CONFIG_ARCH_MEDIATEK)	+= mediatek/
>  obj-$(CONFIG_ARCH_QCOM)		+= qcom/
> -obj-$(CONFIG_ARCH_ROCKCHIP)		+= rockchip/
> +obj-$(CONFIG_ARCH_RENESAS)	+= renesas/
> +obj-$(CONFIG_ARCH_ROCKCHIP)	+= rockchip/
>  obj-$(CONFIG_ARCH_SUNXI)	+= sunxi/
>  obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
>  obj-$(CONFIG_SOC_TI)		+= ti/
> diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
> new file mode 100644
> index 0000000000000000..b2e4d31555c285f0
> --- /dev/null
> +++ b/drivers/soc/renesas/Kconfig
> @@ -0,0 +1,8 @@
> +#
> +# Renesas SoC drivers
> +#
> +
> +config RENESAS_RCAR_PM
> +	bool
> +	select PM_GENERIC_DOMAINS if PM
> +	default y if ARCH_RENESAS && ARM64
> diff --git a/drivers/soc/renesas/Makefile b/drivers/soc/renesas/Makefile
> new file mode 100644
> index 0000000000000000..36b8aedf2ef4195f
> --- /dev/null
> +++ b/drivers/soc/renesas/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_RENESAS_RCAR_PM)	+= pm-rcar.o
> diff --git a/arch/arm/mach-shmobile/pm-rcar.c
> b/drivers/soc/renesas/pm-rcar.c similarity index 99%
> rename from arch/arm/mach-shmobile/pm-rcar.c
> rename to drivers/soc/renesas/pm-rcar.c
> index 0af05d288b09c3ab..bc605d9fbc6ce79c 100644
> --- a/arch/arm/mach-shmobile/pm-rcar.c
> +++ b/drivers/soc/renesas/pm-rcar.c
> @@ -13,7 +13,7 @@
>  #include <linux/mm.h>
>  #include <linux/spinlock.h>
>  #include <linux/io.h>
> -#include "pm-rcar.h"
> +#include <linux/soc/renesas/pm-rcar.h>
> 
>  /* SYSC Common */
>  #define SYSCSR			0x00	/* SYSC Status Register */
> diff --git a/arch/arm/mach-shmobile/pm-rcar.h
> b/include/linux/soc/renesas/pm-rcar.h similarity index 93%
> rename from arch/arm/mach-shmobile/pm-rcar.h
> rename to include/linux/soc/renesas/pm-rcar.h
> index 1b901db4a24c4633..bfeb647ffd9d2e12 100644
> --- a/arch/arm/mach-shmobile/pm-rcar.h
> +++ b/include/linux/soc/renesas/pm-rcar.h
> @@ -1,6 +1,8 @@
>  #ifndef PM_RCAR_H
>  #define PM_RCAR_H
> 
> +#include <linux/types.h>
> +
>  struct rcar_sysc_ch {
>  	u16 chan_offs;
>  	u8 chan_bit;

-- 
Regards,

Laurent Pinchart



From mturquette at baylibre.com  Mon Feb 15 14:12:50 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Mon, 15 Feb 2016 14:12:50 -0800
Subject: [PATCH 02/14] clkdev: Remove clk_register_clkdevs()
In-Reply-To: <1454982341-22715-3-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
 <1454982341-22715-3-git-send-email-sboyd@codeaurora.org>
Message-ID: <20160215221250.2278.79010@quark.deferred.io>

Quoting Stephen Boyd (2016-02-08 17:45:29)
> Now that we've converted the only caller over to another clkdev
> API, remove this one.
> 
> Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>

Looks good to me.

Regards,
Mike

> ---
>  drivers/clk/clkdev.c   | 27 ---------------------------
>  include/linux/clkdev.h |  1 -
>  2 files changed, 28 deletions(-)
> 
> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
> index 779b6ff0c7ad..ae61f2e57048 100644
> --- a/drivers/clk/clkdev.c
> +++ b/drivers/clk/clkdev.c
> @@ -383,30 +383,3 @@ int clk_register_clkdev(struct clk *clk, const char *con_id,
>         return cl ? 0 : -ENOMEM;
>  }
>  EXPORT_SYMBOL(clk_register_clkdev);
> -
> -/**
> - * clk_register_clkdevs - register a set of clk_lookup for a struct clk
> - * @clk: struct clk to associate with all clk_lookups
> - * @cl: array of clk_lookup structures with con_id and dev_id pre-initialized
> - * @num: number of clk_lookup structures to register
> - *
> - * To make things easier for mass registration, we detect error clks
> - * from a previous clk_register() call, and return the error code for
> - * those.  This is to permit this function to be called immediately
> - * after clk_register().
> - */
> -int clk_register_clkdevs(struct clk *clk, struct clk_lookup *cl, size_t num)
> -{
> -       unsigned i;
> -
> -       if (IS_ERR(clk))
> -               return PTR_ERR(clk);
> -
> -       for (i = 0; i < num; i++, cl++) {
> -               cl->clk_hw = __clk_get_hw(clk);
> -               __clkdev_add(cl);
> -       }
> -
> -       return 0;
> -}
> -EXPORT_SYMBOL(clk_register_clkdevs);
> diff --git a/include/linux/clkdev.h b/include/linux/clkdev.h
> index 08bffcc466de..43a8c2e8ac29 100644
> --- a/include/linux/clkdev.h
> +++ b/include/linux/clkdev.h
> @@ -46,7 +46,6 @@ int clk_add_alias(const char *, const char *, const char *, struct device *);
>  
>  int clk_register_clkdev(struct clk *, const char *, const char *, ...)
>         __printf(3, 4);
> -int clk_register_clkdevs(struct clk *, struct clk_lookup *, size_t);
>  
>  #ifdef CONFIG_COMMON_CLK
>  int __clk_get(struct clk *clk);
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 


From mturquette at baylibre.com  Mon Feb 15 14:13:13 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Mon, 15 Feb 2016 14:13:13 -0800
Subject: [PATCH 01/14] mfd: intel_quark_i2c_gpio: Use clkdev_create()
In-Reply-To: <1454982341-22715-2-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
 <1454982341-22715-2-git-send-email-sboyd@codeaurora.org>
Message-ID: <20160215221313.2278.40061@quark.deferred.io>

Quoting Stephen Boyd (2016-02-08 17:45:28)
> Convert this driver to use clkdev_create() instead of
> clk_register_clkdevs(). The latter API is only used by this driver,
> although this driver only allocates one clk to add anyway.
> Furthermore, this driver allocates the clk_lookup structure with
> devm, but clkdev_drop() will free that structure when passed,
> leading to a double free when this driver is removed. Clean it
> all up and pave the way for the removal of clk_register_clkdevs().
> 
> Cc: Lee Jones <lee.jones at linaro.org>
> Cc: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> Cc: Russell King <linux at arm.linux.org.uk>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>

Looks good to me.

Regards,
Mike

> ---
>  drivers/mfd/intel_quark_i2c_gpio.c | 26 +++++++++-----------------
>  1 file changed, 9 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/mfd/intel_quark_i2c_gpio.c b/drivers/mfd/intel_quark_i2c_gpio.c
> index 042137465300..bdc5e27222c0 100644
> --- a/drivers/mfd/intel_quark_i2c_gpio.c
> +++ b/drivers/mfd/intel_quark_i2c_gpio.c
> @@ -52,8 +52,6 @@
>  /* The Quark I2C controller source clock */
>  #define INTEL_QUARK_I2C_CLK_HZ 33000000
>  
> -#define INTEL_QUARK_I2C_NCLK   1
> -
>  struct intel_quark_mfd {
>         struct pci_dev          *pdev;
>         struct clk              *i2c_clk;
> @@ -128,30 +126,24 @@ MODULE_DEVICE_TABLE(pci, intel_quark_mfd_ids);
>  static int intel_quark_register_i2c_clk(struct intel_quark_mfd *quark_mfd)
>  {
>         struct pci_dev *pdev = quark_mfd->pdev;
> -       struct clk_lookup *i2c_clk_lookup;
>         struct clk *i2c_clk;
> -       int ret;
> -
> -       i2c_clk_lookup = devm_kcalloc(&pdev->dev, INTEL_QUARK_I2C_NCLK,
> -                                     sizeof(*i2c_clk_lookup), GFP_KERNEL);
> -       if (!i2c_clk_lookup)
> -               return -ENOMEM;
> -
> -       i2c_clk_lookup[0].dev_id = INTEL_QUARK_I2C_CONTROLLER_CLK;
>  
>         i2c_clk = clk_register_fixed_rate(&pdev->dev,
>                                           INTEL_QUARK_I2C_CONTROLLER_CLK, NULL,
>                                           CLK_IS_ROOT, INTEL_QUARK_I2C_CLK_HZ);
> +       if (IS_ERR(i2c_clk))
> +               return PTR_ERR(i2c_clk);
>  
> -       quark_mfd->i2c_clk_lookup = i2c_clk_lookup;
>         quark_mfd->i2c_clk = i2c_clk;
> +       quark_mfd->i2c_clk_lookup = clkdev_create(i2c_clk, NULL,
> +                                               INTEL_QUARK_I2C_CONTROLLER_CLK);
>  
> -       ret = clk_register_clkdevs(i2c_clk, i2c_clk_lookup,
> -                                  INTEL_QUARK_I2C_NCLK);
> -       if (ret)
> -               dev_err(&pdev->dev, "Fixed clk register failed: %d\n", ret);
> +       if (!quark_mfd->i2c_clk_lookup) {
> +               dev_err(&pdev->dev, "Fixed clk register failed\n");
> +               return -ENOMEM;
> +       }
>  
> -       return ret;
> +       return 0;
>  }
>  
>  static void intel_quark_unregister_i2c_clk(struct pci_dev *pdev)
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 


From mturquette at baylibre.com  Mon Feb 15 14:13:32 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Mon, 15 Feb 2016 14:13:32 -0800
Subject: [PATCH 03/14] clk: Add {devm_}clk_hw_{register, unregister}() APIs
In-Reply-To: <1454982341-22715-4-git-send-email-sboyd@codeaurora.org>
References: <1454982341-22715-1-git-send-email-sboyd@codeaurora.org>
 <1454982341-22715-4-git-send-email-sboyd@codeaurora.org>
Message-ID: <20160215221332.2278.64497@quark.deferred.io>

Quoting Stephen Boyd (2016-02-08 17:45:30)
> We've largely split the clk consumer and provider APIs along
> struct clk and struct clk_hw, but clk_register() still returns a
> struct clk pointer for each struct clk_hw that's registered.
> Eventually we'd like to only allocate struct clks when there's a
> user, because struct clk is per-user now, so clk_register() needs
> to change.
> 
> Let's add new APIs to register struct clk_hws, but this time
> we'll hide the struct clk from the caller by returning an int
> error code. Also add an unregistration API that takes the clk_hw
> structure that was passed to the registration API. This way
> provider drivers never have to deal with a struct clk pointer
> unless they're using the clk consumer APIs.
> 
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>

Looks good to me.

Regards,
Mike

> ---
>  Documentation/driver-model/devres.txt |  1 +
>  drivers/clk/clk.c                     | 86 +++++++++++++++++++++++++++++++++++
>  include/linux/clk-provider.h          |  6 +++
>  3 files changed, 93 insertions(+)
> 
> diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
> index 831a5363f6be..600e30bf52c5 100644
> --- a/Documentation/driver-model/devres.txt
> +++ b/Documentation/driver-model/devres.txt
> @@ -236,6 +236,7 @@ certainly invest a bit more effort into libata core layer).
>  CLOCK
>    devm_clk_get()
>    devm_clk_put()
> +  devm_clk_hw_register()
>  
>  DMA
>    dmam_alloc_coherent()
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index b4db67a446c8..adaaead3639f 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2613,6 +2613,22 @@ fail_out:
>  }
>  EXPORT_SYMBOL_GPL(clk_register);
>  
> +/**
> + * clk_hw_register - register a clk_hw and return an error code
> + * @dev: device that is registering this clock
> + * @hw: link to hardware-specific clock data
> + *
> + * clk_hw_register is the primary interface for populating the clock tree with
> + * new clock nodes. It returns an integer equal to zero indicating success or
> + * less than zero indicating failure. Drivers must test for an error code after
> + * calling clk_hw_register().
> + */
> +int clk_hw_register(struct device *dev, struct clk_hw *hw)
> +{
> +       return PTR_ERR_OR_ZERO(clk_register(dev, hw));
> +}
> +EXPORT_SYMBOL_GPL(clk_hw_register);
> +
>  /* Free memory allocated for a clock. */
>  static void __clk_release(struct kref *ref)
>  {
> @@ -2714,11 +2730,26 @@ void clk_unregister(struct clk *clk)
>  }
>  EXPORT_SYMBOL_GPL(clk_unregister);
>  
> +/**
> + * clk_hw_unregister - unregister a currently registered clk_hw
> + * @hw: hardware-specific clock data to unregister
> + */
> +void clk_hw_unregister(struct clk_hw *hw)
> +{
> +       clk_unregister(hw->clk);
> +}
> +EXPORT_SYMBOL_GPL(clk_hw_unregister);
> +
>  static void devm_clk_release(struct device *dev, void *res)
>  {
>         clk_unregister(*(struct clk **)res);
>  }
>  
> +static void devm_clk_hw_release(struct device *dev, void *res)
> +{
> +       clk_hw_unregister(*(struct clk_hw **)res);
> +}
> +
>  /**
>   * devm_clk_register - resource managed clk_register()
>   * @dev: device that is registering this clock
> @@ -2749,6 +2780,36 @@ struct clk *devm_clk_register(struct device *dev, struct clk_hw *hw)
>  }
>  EXPORT_SYMBOL_GPL(devm_clk_register);
>  
> +/**
> + * devm_clk_hw_register - resource managed clk_hw_register()
> + * @dev: device that is registering this clock
> + * @hw: link to hardware-specific clock data
> + *
> + * Managed clk_hw_register(). Clocks returned from this function are
> + * automatically clk_hw_unregister()ed on driver detach. See clk_hw_register()
> + * for more information.
> + */
> +int devm_clk_hw_register(struct device *dev, struct clk_hw *hw)
> +{
> +       struct clk_hw **hwp;
> +       int ret;
> +
> +       hwp = devres_alloc(devm_clk_hw_release, sizeof(*hwp), GFP_KERNEL);
> +       if (!hwp)
> +               return -ENOMEM;
> +
> +       ret = clk_hw_register(dev, hw);
> +       if (!ret) {
> +               *hwp = hw;
> +               devres_add(dev, hwp);
> +       } else {
> +               devres_free(hwp);
> +       }
> +
> +       return ret;
> +}
> +EXPORT_SYMBOL_GPL(devm_clk_hw_register);
> +
>  static int devm_clk_match(struct device *dev, void *res, void *data)
>  {
>         struct clk *c = res;
> @@ -2757,6 +2818,15 @@ static int devm_clk_match(struct device *dev, void *res, void *data)
>         return c == data;
>  }
>  
> +static int devm_clk_hw_match(struct device *dev, void *res, void *data)
> +{
> +       struct clk_hw *hw = res;
> +
> +       if (WARN_ON(!hw))
> +               return 0;
> +       return hw == data;
> +}
> +
>  /**
>   * devm_clk_unregister - resource managed clk_unregister()
>   * @clk: clock to unregister
> @@ -2771,6 +2841,22 @@ void devm_clk_unregister(struct device *dev, struct clk *clk)
>  }
>  EXPORT_SYMBOL_GPL(devm_clk_unregister);
>  
> +/**
> + * devm_clk_hw_unregister - resource managed clk_hw_unregister()
> + * @dev: device that is unregistering the hardware-specific clock data
> + * @hw: link to hardware-specific clock data
> + *
> + * Unregister a clk_hw registered with devm_clk_hw_register(). Normally
> + * this function will not need to be called and the resource management
> + * code will ensure that the resource is freed.
> + */
> +void devm_clk_hw_unregister(struct device *dev, struct clk_hw *hw)
> +{
> +       WARN_ON(devres_release(dev, devm_clk_hw_release, devm_clk_hw_match,
> +                               hw));
> +}
> +EXPORT_SYMBOL_GPL(devm_clk_hw_unregister);
> +
>  /*
>   * clkdev helpers
>   */
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index 1143e38555a4..abc16d77fb62 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -639,9 +639,15 @@ void of_gpio_mux_clk_setup(struct device_node *node);
>  struct clk *clk_register(struct device *dev, struct clk_hw *hw);
>  struct clk *devm_clk_register(struct device *dev, struct clk_hw *hw);
>  
> +int __must_check clk_hw_register(struct device *dev, struct clk_hw *hw);
> +int __must_check devm_clk_hw_register(struct device *dev, struct clk_hw *hw);
> +
>  void clk_unregister(struct clk *clk);
>  void devm_clk_unregister(struct device *dev, struct clk *clk);
>  
> +void clk_hw_unregister(struct clk_hw *hw);
> +void devm_clk_hw_unregister(struct device *dev, struct clk_hw *hw);
> +
>  /* helper functions */
>  const char *__clk_get_name(const struct clk *clk);
>  const char *clk_hw_get_name(const struct clk_hw *hw);
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 


From peter.maydell at linaro.org  Mon Feb 15 14:29:20 2016
From: peter.maydell at linaro.org (Peter Maydell)
Date: Mon, 15 Feb 2016 22:29:20 +0000
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <20160215170527.GA24453@roeck-us.net>
References: <20160215170527.GA24453@roeck-us.net>
Message-ID: <CAFEAcA9Xy2L+edFAdUCpZFiO5NLGyrQPTQ6DgmuScbwEty-nzg@mail.gmail.com>

On 15 February 2016 at 17:05, Guenter Roeck <linux at roeck-us.net> wrote:
> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
> timers with utilization update callbacks' with next-20160215. An example
> crash log and bisect results are attached below.
>
> Please let me know if there is anything I can do to help tracking down
> the problem.
>
> Thanks,
> Guenter
>
> ---
>
> Building arm:beagle:multi_v7_defconfig:omap3-beagle ... running ..... failed (crashed)
> ------------
> qemu log:

You're using the QEMU beagle board emulation? Can I ask which
QEMU you're using (qemu-linaro?). If the OMAP3 emulation is still
actively useful to people I might have another stab at getting
it into upstream QEMU some day...

thanks
-- PMM


From carlo at caione.org  Mon Feb 15 14:34:11 2016
From: carlo at caione.org (Carlo Caione)
Date: Mon, 15 Feb 2016 23:34:11 +0100
Subject: [PATCH v2] MAINTAINERS: Extend info, add wiki and ml for meson arch
Message-ID: <1455575651-16157-1-git-send-email-carlo@caione.org>

From: Carlo Caione <carlo at endlessm.com>

Update the maintainers info with wiki and mailing list for the meson
platform. Fix a wrong file attribution and add maintainership for the
generic meson platforms.

Signed-off-by: Carlo Caione <carlo at endlessm.com>
---
 MAINTAINERS | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 28eb61b..7f51744 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -920,12 +920,15 @@ M:	Emilio L?pez <emilio at elopez.com.ar>
 S:	Maintained
 F:	drivers/clk/sunxi/
 
-ARM/Amlogic MesonX SoC support
+ARM/Amlogic Meson SoC support
 M:	Carlo Caione <carlo at caione.org>
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+L:	linux-meson at googlegroups.com
+W:	http://linux-meson.com/
 S:	Maintained
-F:	drivers/media/rc/meson-ir.c
-N:	meson[x68]
+F:	arch/arm/mach-meson/
+F:	arch/arm/boot/dts/meson*
+N:	meson
 
 ARM/Annapurna Labs ALPINE ARCHITECTURE
 M:	Tsahee Zidenberg <tsahee at annapurnalabs.com>
-- 
1.9.1



From laurent.pinchart at ideasonboard.com  Mon Feb 15 14:51:45 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 16 Feb 2016 00:51:45 +0200
Subject: [PATCH/RFC v2 04/11] soc: renesas: rcar: Add DT support for SYSC
 PM domains
In-Reply-To: <1455571020-18968-5-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
 <1455571020-18968-5-git-send-email-geert+renesas@glider.be>
Message-ID: <3535519.g4KL1PCIZy@avalon>

Hi Geert,

Thank you for the patch.

On Monday 15 February 2016 22:16:53 Geert Uytterhoeven wrote:
> Populate the SYSC PM domains from DT.
> 
> Special cases, like PM domains containing CPU cores or SCUs, are
> handled by scanning the DT topology.
> 
> The SYSCIER register value is derived from the PM domains found in DT,
> which will allow to get rid of the hardcoded values in pm-rcar-gen2.c.
> However, this means we have to scan for PM domains even if CONFIG_PM=n.
> 
> FIXME:
>   - This needs better integration with the PM code in pm-rcar-gen2, the
>     SMP code in smp-r8a7790, and Magnus' DT APMU series.

Have you given this some thoughts already ? Unfortunately smp_prepare_cpus() 
is called before any initcall :-/ How do the other platforms handle this ?

> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> ---
> v2:
>   - Add missing definitions for SYSC_PWR_CA15_CPU and SYSC_PWR_CA7_CPU,
>   - Add R-Car H3 (r8a7795) support,
>   - Drop tests for CONFIG_ARCH_SHMOBILE_LEGACY,
>   - Add missing break statements in rcar_sysc_pwr_on_off(),
>   - Add missing calls to of_node_put() in error paths,
>   - Fix build if CONFIG_PM=n,
>   - Update compatible values,
>   - Update copyright.
> ---
>  drivers/soc/renesas/pm-rcar.c | 327 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 327 insertions(+)
> 
> diff --git a/drivers/soc/renesas/pm-rcar.c b/drivers/soc/renesas/pm-rcar.c
> index cc684e9cc8db5d1c..c0540934126e58eb 100644
> --- a/drivers/soc/renesas/pm-rcar.c
> +++ b/drivers/soc/renesas/pm-rcar.c
> @@ -2,6 +2,7 @@
>   * R-Car SYSC Power management support
>   *
>   * Copyright (C) 2014  Magnus Damm
> + * Copyright (C) 2015-2016 Glider bvba
>   *
>   * This file is subject to the terms and conditions of the GNU General
> Public * License.  See the file "COPYING" in the main directory of this
> archive @@ -11,6 +12,9 @@
>  #include <linux/delay.h>
>  #include <linux/err.h>
>  #include <linux/mm.h>
> +#include <linux/of_address.h>
> +#include <linux/pm_domain.h>
> +#include <linux/slab.h>
>  #include <linux/spinlock.h>
>  #include <linux/io.h>
>  #include <linux/soc/renesas/pm-rcar.h>
> @@ -38,6 +42,18 @@
>  #define PWRONSR_OFFS		0x10	/* Power Resume Status Register */
>  #define PWRER_OFFS		0x14	/* Power Shutoff/Resume Error */
> 
> +/*
> + * SYSC Power Control Register Base Addresses (R-Car Gen2)
> + */
> +#define SYSC_PWR_CA15_CPU	0x40	/* CA15 cores (incl. L1C) (H2/M2/V2H) */
> +#define SYSC_PWR_CA7_CPU	0x1c0	/* CA7 cores (incl. L1C) (H2/E2) */
> +
> +/*
> + * SYSC Power Control Register Base Addresses (R-Car Gen3)
> + */
> +#define SYSC_PWR_CA57_CPU	0x80	/* CA57 cores (incl. L1C) (H3) */
> +#define SYSC_PWR_CA53_CPU	0x200	/* CA53 cores (incl. L1C) (H3) */
> +
> 
>  #define SYSCSR_RETRIES		100
>  #define SYSCSR_DELAY_US		1
> @@ -51,11 +67,40 @@
>  static void __iomem *rcar_sysc_base;
>  static DEFINE_SPINLOCK(rcar_sysc_lock); /* SMP CPUs + I/O devices */
> 
> +static unsigned int rcar_gen;
> +
>  static int rcar_sysc_pwr_on_off(const struct rcar_sysc_ch *sysc_ch, bool
> on)
> {
>  	unsigned int sr_bit, reg_offs;
>  	int k;
> 
> +	/*
> +	 * Only R-Car H1 can control power to CPUs
> +	 * Use WFI to power off, CPG/APMU to resume ARM cores on later R-Car
> +	 * Generations
> +	 */
> +	switch (rcar_gen) {
> +	case 2:
> +		/* FIXME Check rcar_pm_domain.cpu instead? */
> +		switch (sysc_ch->chan_offs) {
> +		case SYSC_PWR_CA15_CPU:
> +		case SYSC_PWR_CA7_CPU:
> +			pr_err("%s: Cannot control power to CPU\n", __func__);
> +			return -EINVAL;
> +		}
> +		break;
> +
> +	case 3:
> +		/* FIXME Check rcar_pm_domain.cpu instead? */
> +		switch (sysc_ch->chan_offs) {
> +		case SYSC_PWR_CA57_CPU:
> +		case SYSC_PWR_CA53_CPU:
> +			pr_err("%s: Cannot control power to CPU\n", __func__);
> +			return -EINVAL;
> +		}
> +		break;
> +	}
> +
>  	if (on) {
>  		sr_bit = SYSCSR_PONENB;
>  		reg_offs = PWRONCR_OFFS;
> @@ -162,3 +207,285 @@ void __iomem *rcar_sysc_init(phys_addr_t base)
> 
>  	return rcar_sysc_base;
>  }
> +
> +#ifdef CONFIG_PM_GENERIC_DOMAINS
> +struct rcar_pm_domain {
> +	struct generic_pm_domain genpd;
> +	struct dev_power_governor *gov;
> +	struct rcar_sysc_ch ch;
> +	unsigned busy:1;		/* Set if always -EBUSY */
> +	unsigned cpu:1;			/* Set if domain contains CPU */
> +	char name[0];
> +};
> +
> +static inline struct rcar_pm_domain *to_rcar_pd(struct generic_pm_domain
> *d)
> +{
> +	return container_of(d, struct rcar_pm_domain, genpd);
> +}
> +
> +static bool rcar_pd_active_wakeup(struct device *dev)
> +{
> +	return true;
> +}
> +
> +static int rcar_pd_power_down(struct generic_pm_domain *genpd)
> +{
> +	struct rcar_pm_domain *rcar_pd = to_rcar_pd(genpd);
> +
> +	pr_debug("%s: %s\n", __func__, genpd->name);
> +
> +	if (rcar_pd->busy) {
> +		pr_debug("%s: %s busy\n", __func__, genpd->name);
> +		return -EBUSY;
> +	}
> +
> +	return rcar_sysc_power_down(&rcar_pd->ch);
> +}
> +
> +static int rcar_pd_power_up(struct generic_pm_domain *genpd)
> +{
> +	pr_debug("%s: %s\n", __func__, genpd->name);
> +	return rcar_sysc_power_up(&to_rcar_pd(genpd)->ch);
> +}
> +
> +static void rcar_init_pm_domain(struct rcar_pm_domain *rcar_pd)
> +{
> +	struct generic_pm_domain *genpd = &rcar_pd->genpd;
> +	struct dev_power_governor *gov = rcar_pd->gov;
> +
> +	pm_genpd_init(genpd, gov ? : &simple_qos_governor, false);
> +	genpd->dev_ops.active_wakeup	= rcar_pd_active_wakeup;
> +	genpd->power_off		= rcar_pd_power_down;
> +	genpd->power_on			= rcar_pd_power_up;
> +
> +	if (rcar_sysc_power_is_off(&rcar_pd->ch))
> +		rcar_sysc_power_up(&rcar_pd->ch);
> +}
> +
> +enum pd_types {
> +	PD_NORMAL,
> +	PD_CPU,
> +	PD_SCU,
> +};
> +
> +#define MAX_NUM_SPECIAL_PDS	16
> +
> +static struct special_pd {
> +	struct device_node *pd;
> +	enum pd_types type;
> +} special_pds[MAX_NUM_SPECIAL_PDS] __initdata;
> +
> +static unsigned int num_special_pds __initdata;
> +
> +static void __init add_special_pd(struct device_node *np, enum pd_types
> type)
> +{
> +	unsigned int i;
> +	struct device_node *pd;
> +
> +	pd = of_parse_phandle(np, "power-domains", 0);
> +	if (!pd)
> +		return;
> +
> +	for (i = 0; i < num_special_pds; i++)
> +		if (pd == special_pds[i].pd && type == special_pds[i].type) {
> +			of_node_put(pd);
> +			return;
> +		}
> +
> +	if (num_special_pds == ARRAY_SIZE(special_pds)) {
> +		pr_warn("Too many special PM domains\n");
> +		of_node_put(pd);
> +		return;
> +	}
> +
> +	pr_debug("Special PM domain %s type %d for %s\n", pd->name, type,
> +		 np->full_name);
> +
> +	special_pds[num_special_pds].pd = pd;
> +	special_pds[num_special_pds].type = type;
> +	num_special_pds++;
> +}
> +
> +static void __init get_special_pds(void)
> +{
> +	struct device_node *cpu, *scu;
> +
> +	/* PM domains containing CPUs */
> +	for_each_node_by_type(cpu, "cpu") {
> +		add_special_pd(cpu, PD_CPU);
> +
> +		/* SCU, represented by an L2 node */
> +		scu = of_parse_phandle(cpu, "next-level-cache", 0);
> +		if (scu) {
> +			add_special_pd(scu, PD_SCU);
> +			of_node_put(scu);
> +		}
> +	}
> +}
> +
> +static void __init put_special_pds(void)
> +{
> +	unsigned int i;
> +
> +	for (i = 0; i < num_special_pds; i++)
> +		of_node_put(special_pds[i].pd);
> +}
> +
> +static enum pd_types __init pd_type(const struct device_node *pd)
> +{
> +	unsigned int i;
> +
> +	for (i = 0; i < num_special_pds; i++)
> +		if (pd == special_pds[i].pd)
> +			return special_pds[i].type;
> +
> +	return PD_NORMAL;
> +}
> +
> +static void __init rcar_setup_pm_domain(struct device_node *np,
> +					struct rcar_pm_domain *pd)
> +{
> +	const char *name = pd->genpd.name;
> +
> +	switch (pd_type(np)) {
> +	case PD_CPU:
> +		/*
> +		 * This domain contains a CPU core and therefore it should
> +		 * only be turned off if the CPU is not in use.
> +		 */
> +		pr_debug("PM domain %s contains CPU\n", name);
> +		pd->gov = &pm_domain_always_on_gov;
> +		pd->busy = true;
> +		pd->cpu = true;
> +		break;
> +
> +	case PD_SCU:
> +		/*
> +		 * This domain contains an SCU and cache-controller, and
> +		 * therefore it should only be turned off if the CPU cores are
> +		 * not in use.
> +		 */
> +		pr_debug("PM domain %s contains SCU\n", name);
> +		pd->gov = &pm_domain_always_on_gov;
> +		pd->busy = true;
> +		break;
> +
> +	case PD_NORMAL:
> +		break;
> +	}
> +
> +	rcar_init_pm_domain(pd);
> +}
> +
> +static int __init rcar_add_pm_domains(struct device_node *parent,
> +				      struct generic_pm_domain *genpd_parent,
> +				      u32 *syscier)
> +{
> +	struct device_node *np;
> +
> +	for_each_child_of_node(parent, np) {
> +		struct rcar_pm_domain *pd;
> +		u32 reg[2];
> +		int n;
> +
> +		if (of_property_read_u32_array(np, "reg", reg,
> +					       ARRAY_SIZE(reg))) {
> +			of_node_put(np);
> +			return -EINVAL;
> +		}
> +
> +		*syscier |= BIT(reg[0]);
> +
> +		if (!IS_ENABLED(CONFIG_PM)) {
> +			/* Just continue parsing "reg" to update *syscier */
> +			rcar_add_pm_domains(np, NULL, syscier);
> +			continue;
> +		}
> +
> +		n = snprintf(NULL, 0, "%s@%u", np->name, reg[0]) + 1;
> +
> +		pd = kzalloc(sizeof(*pd) + n, GFP_KERNEL);
> +		if (!pd) {
> +			of_node_put(np);
> +			return -ENOMEM;
> +		}
> +
> +		snprintf(pd->name, n, "%s@%u", np->name, reg[0]);
> +		pd->genpd.name = pd->name;
> +		pd->ch.chan_offs = reg[1] & ~31;
> +		pd->ch.chan_bit = reg[1] & 31;
> +		pd->ch.isr_bit = reg[0];
> +
> +		rcar_setup_pm_domain(np, pd);
> +		if (genpd_parent)
> +			pm_genpd_add_subdomain(genpd_parent, &pd->genpd);
> +		of_genpd_add_provider_simple(np, &pd->genpd);
> +
> +		rcar_add_pm_domains(np, &pd->genpd, syscier);
> +	}
> +	return 0;
> +}
> +
> +static const struct of_device_id rcar_sysc_matches[] = {
> +	{ .compatible = "renesas,r8a7779-sysc", .data = (void *)1 },
> +	{ .compatible = "renesas,rcar-gen2-sysc", .data = (void *)2 },
> +	{ .compatible = "renesas,rcar-gen3-sysc", .data = (void *)3 },

How about RCAR_GEN1, RCAR_GEN2 and RCAR_GEN3 macros ?

> +	{ /* sentinel */ }
> +};
> +
> +static int __init rcar_init_pm_domains(void)
> +{
> +	const struct of_device_id *match;
> +	struct device_node *np, *pmd;
> +	bool scanned = false;
> +	void __iomem *base;
> +	int ret = 0;
> +
> +	for_each_matching_node_and_match(np, rcar_sysc_matches, &match) {
> +		u32 syscier = 0;
> +
> +		rcar_gen = (uintptr_t)match->data;
> +
> +		base = of_iomap(np, 0);
> +		if (!base) {
> +			pr_warn("%s cannot map reg 0\n", np->full_name);
> +			continue;
> +		}
> +
> +		rcar_sysc_base = base;	// FIXME conflicts with rcar_sysc_init()
> +
> +		pmd = of_get_child_by_name(np, "pm-domains");
> +		if (!pmd) {
> +			pr_warn("%s lacks pm-domains node\n", np->full_name);

Shouldn't you call iounmap() here ?

> +			continue;
> +		}
> +
> +		if (!scanned) {
> +			/* Find PM domains containing special blocks */
> +			get_special_pds();
> +			scanned = true;
> +		}
> +
> +		ret = rcar_add_pm_domains(pmd, NULL, &syscier);
> +		of_node_put(pmd);
> +		if (ret) {
> +			of_node_put(np);
> +			break;
> +		}
> +
> +		/*
> +		 * Enable all interrupt sources, but do not use interrupt
> +		 * handler
> +		 */
> +		pr_debug("%s: syscier = 0x%08x\n", np->full_name, syscier);
> +		iowrite32(syscier, rcar_sysc_base + SYSCIER);
> +		iowrite32(0, rcar_sysc_base + SYSCIMR);

Shouldn't the SYSCIMR bits be set to 1 to mask interrupts ?

> +	}
> +
> +	put_special_pds();
> +
> +	return ret;
> +}
> +
> +core_initcall(rcar_init_pm_domains);
> +#endif /* PM_GENERIC_DOMAINS */

-- 
Regards,

Laurent Pinchart



From k.kozlowski at samsung.com  Mon Feb 15 15:04:34 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 16 Feb 2016 08:04:34 +0900
Subject: [PATCH] ARM: dts: Move syscon reboot/poweroff to common dtsi for
 Exynos
In-Reply-To: <56C1D4D1.2050108@osg.samsung.com>
References: <1455042606-10075-1-git-send-email-javier@osg.samsung.com>
 <56C02265.40103@samsung.com> <56C1D4D1.2050108@osg.samsung.com>
Message-ID: <56C25982.4020301@samsung.com>

On 15.02.2016 22:38, Javier Martinez Canillas wrote:
>>
>> In some of the DTSI this was under "soc" node, not at top-level.
>> Unfortunately we do not have consistency here - some DTSI have "soc",
> 
> Yes, I noticed this but as you said not all DTSI have a soc node
> and that's why I made it top level in the DTSI.
> 
>> some not. Anyway I think we should move to "soc" version.
>>
> 
> Not sure I'm following, did you mean to do it as a follow up or
> to add a soc node for the missing DTSI as a part of this series?

I meant to send a v2 with this under "soc" node even though on some DTS
we do not have the "soc". Optional follow up would be to make DTS
consistent and move nodes under "soc"... but that would be also a lot of
churn.

Best regards,
Krzysztof


From laurent.pinchart at ideasonboard.com  Mon Feb 15 15:08:18 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 16 Feb 2016 01:08:18 +0200
Subject: [PATCH/RFC v2 01/11] PM / Domains: Add DT bindings for the R-Car
 System Controller
In-Reply-To: <1455571020-18968-2-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
 <1455571020-18968-2-git-send-email-geert+renesas@glider.be>
Message-ID: <1720075.YOPnCQ3mE1@avalon>

Hi Geert,

Thank you for the patch.

On Monday 15 February 2016 22:16:50 Geert Uytterhoeven wrote:
> The Renesas R-Car System Controller provides power management for the
> CPU cores and various coprocessors, following the generic PM domain
> bindings in Documentation/devicetree/bindings/power/power_domain.txt.
> 
> This supports R-Car Gen1, Gen2, and Gen3.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> ---
> Alternatives I considered:
> 
>   - Using a single node per power register block, even if it contains
>     multiple domains, e.g.:
> 
> 	    pd_ca15_scu: ca15_scu at 180 {
> 		    reg = <0x180 0x20>;
> 		    #address-cells = <1>;
> 		    #size-cells = <0>;
> 		    #power-domain-cells = <0>;
> 		    renesas,interrupt-bits = <12>;
> 
> 		    pd_ca15_cpu: ca15_cpu at 40 {
> 			    reg = <0x40 0x20>;
> 			    #power-domain-cells = <1>;
> 			    renesas,pm-domain-indices = <0 1>;
> 			    renesas,pm-domain-names =
> 				    "ca15_cpu0", "ca15_cpu1";
> 			    renesas,interrupt-bits = <0 1>;
> 		    };
> 	    };
> 
>     Notes:
>       - You cannot just have a property with the number of domains, as
> 	index 0 is not used on R-Car H1. Hence the need for
> 	"renesas,pm-domain-indices" and "renesas,interrupt-bits",
>       - "#power-domain-cells = <1>" for nodes with multiple domains,
> 	which allows typos in "power-domains = <&pd_ca15_cpu n>", using
> 	an invalid value of "n".
> 
>   - Using a linear description in DT:
>       - Needs parent links for subdomains,
>       - More complicated to parse (lesson learned from R-Mobile PM
> 	Domain support).
> 
>   - Keeping the power register block offset and the bit number as separate
>     "reg" cells, increasing "#address-cells" from 2 to 3,
>
>   - Merging the interrupt bit (which needs only 5 bits) in the other "reg"
>     cell, decreasing "#address-cells" from 2 to 1.
> 
> v2:
>   - Add R-Car H3 (r8a7795) support,
>   - Use "renesas,<type>-sysc" instead of "renesas,sysc-<type>",
>   - Add fallback compatibility strings for R-Car Gen2 and Gen3.
> ---
>  .../bindings/power/renesas,sysc-rcar.txt           | 87 +++++++++++++++++++
>  1 file changed, 87 insertions(+) create mode 100644
> Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt
> 
> diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt
> b/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt new file
> mode 100644
> index 0000000000000000..92ddc0da7b755215
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt
> @@ -0,0 +1,87 @@
> +DT bindings for the Renesas R-Car System Controller
> +
> +== System Controller Node ==
> +
> +The R-Car System Controller provides power management for the CPU cores and
> +various coprocessors.
> +
> +Required properties:
> +  - compatible: Must contain one or more of the following:
> +      - "renesas,r8a7779-sysc" (R-Car H1)
> +      - "renesas,r8a7790-sysc" (R-Car H2)
> +      - "renesas,r8a7791-sysc" (R-Car M2-W)
> +      - "renesas,r8a7792-sysc" (R-Car V2H)
> +      - "renesas,r8a7793-sysc" (R-Car M2-N)
> +      - "renesas,r8a7794-sysc" (R-Car E2)
> +      - "renesas,r8a7795-sysc" (R-Car H3)
> +      - "renesas,rcar-gen2-sysc" (Generic R-Car Gen2)
> +      - "renesas,rcar-gen3-sysc" (Generic R-Car Gen3)
> +    When compatible with the generic version, nodes must list the
> SoC-specific
> +    version corresponding to the platform first, followed by the generic
> +    version.
> +  - reg: Address start and address range for the device.

This isn't correct. I'll refrain from saying we abuse the reg property, as 
using the first cell as a power domain number should be fine (the second cell 
feels a bit more of an abuse to me though, but I won't complain too much), but 
the bindings document should describe what the reg cells contain.

> +  - pm-domains: This node contains a hierarchy of PM Domain Nodes.

Can't it be an issue that the node happens to have the same name as the 
standard pm-domains property ?

> +    Dependencies (e.g. parent SCUs should not be powered off while child
> CPUs
> +    are on) should be reflected using subnodes.
> +
> +
> +== PM Domain Nodes ==
> +
> +Each of the PM domain nodes represents a PM domain, as documented by the
> +generic PM domain bindings in
> +Documentation/devicetree/bindings/power/power_domain.txt.
> +
> +Required properties:
> +  - #power-domain-cells: Must be 0.
> +  - reg: This property must contain 2 values:
> +	   - The first value is the number of the interrupt bit representing
> +	     the power area in the various Interrupt Registers (e.g. SYSCISR,
> +	     Interrupt Status Register),
> +	   - The second value encodes the power register block offset (which is
> +	     a multiple of 64), and the number of the bit representing the
> +	     power area in the various Power Control Registers (e.g. PWROFFSR,
> +	     Power Shutoff Status Register). This value is created by ORing
> +	     these two numbers.
> +	 The parent's node must contain the following two properties:
> +	   - #address-cells: Must be 2,
> +	   - #size-cells: Must be 0.
> +
> +
> +Example:
> +
> +	sysc: system-controller at e6180000 {
> +		compatible = "renesas,r8a7791-sysc", "renesas,rcar-gen2-sysc";
> +		reg = <0 0xe6180000 0 0x0200>;
> +
> +		pm-domains {
> +			#address-cells = <2>;
> +			#size-cells = <0>;
> +
> +			pd_ca15_scu: scu at 12 {
> +				reg = <12 0x180>;
> +				#address-cells = <2>;
> +				#size-cells = <0>;
> +				#power-domain-cells = <0>;
> +
> +				pd_ca15_cpu0: cpu at 0 {
> +					reg = <0 0x40>;
> +					#power-domain-cells = <0>;
> +				};
> +
> +				pd_ca15_cpu1: cpu at 1 {
> +					reg = <1 0x41>;
> +					#power-domain-cells = <0>;
> +				};
> +			};
> +
> +			pd_sh: sh at 16 {
> +				reg = <16 0x80>;
> +				#power-domain-cells = <0>;
> +			};
> +
> +			pd_sgx: sgx at 20 {
> +				reg = <20 0xc0>;
> +				#power-domain-cells = <0>;
> +			};
> +		};
> +	};

-- 
Regards,

Laurent Pinchart



From linux at baker-net.org.uk  Mon Feb 15 15:08:40 2016
From: linux at baker-net.org.uk (Adam Baker)
Date: Mon, 15 Feb 2016 23:08:40 +0000
Subject: [PATCH 2/3] ARM: mvebu: Create a NSA3xx hardware monitoring driver
In-Reply-To: <20160213023517.GA22156@roeck-us.net>
References: <1455147224-6742-1-git-send-email-linux@baker-net.org.uk>
 <1455147224-6742-3-git-send-email-linux@baker-net.org.uk>
 <20160213023517.GA22156@roeck-us.net>
Message-ID: <56C25A78.6020700@baker-net.org.uk>

On 13/02/16 02:35, Guenter Roeck wrote:
> Hi,
>
> On Wed, Feb 10, 2016 at 11:33:43PM +0000, Adam Baker wrote:
>> Create a driver to support the hardware monitoring chip present in
>> several models of Zyxel NSA3xx NAS devices.
>>
>> The driver reads fan speed and temperature from a suitably programmed
>> MCU on the device.
>>
>> Signed-off-by: Adam Baker <linux at baker-net.org.uk>
>
> Please name the driver nsa320. It may ultimately support other devices,
> but that doesn't mean it is going to support NSA-35x or other future
> similar devices.
>
> Got the headline, please use
>
> hwmon: Add driver for Zyxel NSA-320
>
OK

>> ---
>> I've tested this on an NSA-320, I've had someone offer to test it on
>> NSA-325 so hopefully I will get a tested by back.
>> ---
>>   drivers/hwmon/Kconfig        |  13 +++
>>   drivers/hwmon/Makefile       |   1 +
>>   drivers/hwmon/nsa3xx-hwmon.c | 223 +++++++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 237 insertions(+)
>>   create mode 100644 drivers/hwmon/nsa3xx-hwmon.c
>>
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>> index 80a73bf..8801b78 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -1757,6 +1757,19 @@ config SENSORS_ULTRA45
>>   	  This driver provides support for the Ultra45 workstation environmental
>>   	  sensors.
>>
>> +config SENSORS_NSA3XX
>
> Please try to stick with alphabetic order.
done
>
>> +	tristate "ZyXEL NSA3xx fan speed and temperature sensors"
>
> ... NSA-320 and compatible ...
done
>
>> +	depends on GPIOLIB && OF
>
> Can you add some additional dependencies ?
>
> It is quite unlikely that the driver is needed on an X86.
> Please use at least
>
> 	depends on ARM || COMPILE_TEST
>
> or a more specific dependency if the SoC is known. MACH_KIRKWOOD, maybe ?
done - depends on MACH_KIRKWOOD || COMPILE_TEST
>
>> +	help
>> +	  If you say yes here you get support for hardware monitoring
>> +	  for the ZyXEL NSA3XX Media Servers.
>
> Please be specific which devices are supported. Feel free to add "and
> compatibles", but please no generic and misleading statements such as 3XX.
>
Changed to NSA320 and compatible and noted NSA325 and some NSA310 
variants are probably compatible
>> +
>> +	  The sensor data is taken from a Holtek HT46R065 microcontroller
>> +	  connected to GPIO lines.
>> +
> Is that relevant ?
>
I'm guessing that it is if someone is trying to work out if the unit 
they've got is likely to be compatible.

>> +	  This driver can also be built as a module. If so, the module
>> +	  will be called nsa3xx-hwmon.
>> +
>>   if ACPI
>>
>>   comment "ACPI drivers"
>> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
>> index 12a3239..e85414a 100644
>> --- a/drivers/hwmon/Makefile
>> +++ b/drivers/hwmon/Makefile
>> @@ -118,6 +118,7 @@ obj-$(CONFIG_SENSORS_MAX6650)	+= max6650.o
>>   obj-$(CONFIG_SENSORS_MAX6697)	+= max6697.o
>>   obj-$(CONFIG_SENSORS_MAX31790)	+= max31790.o
>>   obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
>> +obj-$(CONFIG_SENSORS_NSA3XX)	+= nsa3xx-hwmon.o
>
> Please try to stick with alphabetic order.
done
>
>>   obj-$(CONFIG_SENSORS_MCP3021)	+= mcp3021.o
>>   obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o
>>   obj-$(CONFIG_SENSORS_NCT6683)	+= nct6683.o
>> diff --git a/drivers/hwmon/nsa3xx-hwmon.c b/drivers/hwmon/nsa3xx-hwmon.c
>> new file mode 100644
>> index 0000000..0fbf118
>> --- /dev/null
>> +++ b/drivers/hwmon/nsa3xx-hwmon.c
>
> nsa320-hwmon.c
done
>
>> @@ -0,0 +1,223 @@
>> +/*
>> + * drivers/hwmon/nsa3xx-hwmon.c
>> + *
>> + * ZyXEL NSA3xx Media Servers
>
> Please be specific.
done
>
>> + * hardware monitoring
>> + *
>> + * Copyright (C) 2016 Adam Baker <linux at baker-net.org.uk>
>> + * based on a board file driver
>> + * Copyright (C) 2012 Peter Schildmann <linux at schildmann.info>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License v2 as published by the
>> + * Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/err.h>
>> +#include <linux/gpio/consumer.h>
>> +#include <linux/hwmon.h>
>> +#include <linux/hwmon-sysfs.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/delay.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_platform.h>
>> +
> Please order include files alphabetically.
done
>
>> +#define MAGIC_NUMBER 0x55
>> +
>> +/*
>> + * The Zyxel hwmon MCU is a Holtek HT46R065 that is factory programmed
>> + * to perform temperature and fan speed monitoring. It is read by taking
>> + * the active pin low. The 32 bit output word is then clocked onto the
>> + * data line. The MSB of the data word is a magic nuber to indicate it
>> + * has been read correctly, the next byte is the fan speed (in hundreds
>> + * of RPM) and the last two bytes are the temperature (in tenths of a
>> + * degree)
>> + */
>> +
>> +struct nsa3xx_hwmon {
>
> s/nsa3xx/nsa320/g for the entire file, please.
done
>
>> +	struct device		*classdev;
>> +	struct mutex		update_lock;	/* lock GPIO operations */
>> +	unsigned long		last_updated;	/* jiffies */
>> +	u32			mcu_data;
>
> I would suggest to use unsigned long here. See below for reasons.
>
I've changed the return value to int
>> +	struct gpio_desc	*act;
>> +	struct gpio_desc	*clk;
>> +	struct gpio_desc	*data;
>> +};
>> +
>> +enum nsa3xx_inputs {
>> +	NSA3XX_FAN = 1,
>> +	NSA3XX_TEMP = 0,
>
> Any special reason for the unusual order ? If yes, please explain.
No, changed
>
>> +};
>> +
>> +static const char * const nsa3xx_input_names[] = {
>> +	[NSA3XX_FAN] = "Chassis Fan",
>> +	[NSA3XX_TEMP] = "System Temperature",
>> +};
>> +
>> +/* Although this protocol looks similar to SPI the long delay
>> + * between the active (aka chip select) signal and the shorter
>> + * delay between clock pulses are needed for reliable operation.
>> + * The delays provided are taken from the manufacturer kernel,
>> + * testing suggest they probably incorporate a reasonable safety
>> + * margin. (The single device tested became unreliable if the
>> + * delay was reduced to 1/10th of this value.)
>> + */
>> +static unsigned long nsa3xx_hwmon_update(struct device *dev)
>> +{
>> +	u32 mcu_data;
>> +	u32 mask;
>> +	struct nsa3xx_hwmon *hwmon = dev_get_drvdata(dev);
>> +
>> +	mutex_lock(&hwmon->update_lock);
>> +
>> +	mcu_data = hwmon->mcu_data;
>> +
>> +	if (time_after(jiffies, hwmon->last_updated + HZ) ||
>> +							mcu_data == 0) {
>> +
>
> Please no blank line here. Also, please align continuation lines with '('.
> However, unless I am missing something, the continuation line is not needed
> in the first place. Please no unnecessary continuation lines.
done
>
>> +		gpiod_set_value(hwmon->act, 1);
>> +		msleep(100);
>> +
>> +		for (mask = BIT(31); mask; mask >>= 1) {
>
> Since you are using BIT(), please include linux/bitops.h.
>
done
>> +			gpiod_set_value(hwmon->clk, 0);
>> +			usleep_range(100, 200);
>> +			gpiod_set_value(hwmon->clk, 1);
>> +			usleep_range(100, 200);
>> +			if (gpiod_get_value(hwmon->data))
>> +				mcu_data |= mask;
>> +		}
>> +
>> +		gpiod_set_value(hwmon->act, 0);
>> +		dev_dbg(dev, "Read raw MCU data %08x\n", mcu_data);
>> +
>> +		if ((mcu_data >> 24) != MAGIC_NUMBER) {
>> +			dev_err(dev, "Read invalid MCU data %08x\n", mcu_data);
>> +			mcu_data = 0;
>
> Instead of an error message, it would be better to return an error code
> (probably -EIO since we don't know better).
>
> The calling code can then return the error to user space.
nsa320_hwmon_update() now returns an int, either 0 or -EIO and the 
caller can read the data from the nsa320_hwmon structure if it returns 
0. dev_err changed to dev_dbg as the raw data is helpful for debugging.
>
>> +		}
>> +
>> +		hwmon->mcu_data = mcu_data;
>> +		hwmon->last_updated = jiffies;
>> +	}
>> +
>> +	mutex_unlock(&hwmon->update_lock);
>> +
>> +	return mcu_data;
>> +}
>> +
>> +static ssize_t show_label(struct device *dev,
>> +			  struct device_attribute *attr, char *buf)
>> +{
>> +	int channel = to_sensor_dev_attr(attr)->index;
>> +
>> +	return sprintf(buf, "%s\n", nsa3xx_input_names[channel]);
>> +}
>> +
>> +static ssize_t show_value(struct device *dev,
>> +			  struct device_attribute *attr, char *buf)
>> +{
>> +	int channel = to_sensor_dev_attr(attr)->index;
>> +	unsigned long mcu_data = nsa3xx_hwmon_update(dev);
>> +	unsigned long value = 0;
>> +
>
> If nsa3xx_hwmon_update() returns an error code, you can use
>
> 	if (IS_ERR_VALUE(mcu_data))
> 		return (long)mcu_data;
>
> or even better have nsa3xx_hwmon_update() return int directly
> to indicate an error.
nsa320_hwmon_update() now returns an int error code or zero and the 
caller gets the data fro the struct if it succeeds
>
>> +	pr_debug("channel value 0x%02x!\n", channel);
>
> Is this really useful ? I would suggest to drop debug messages
> unless really needed. If you really think the message is useful,
> please use dev_dbg().
deleted
>
>> +	switch (channel) {
>> +	case NSA3XX_TEMP:
>> +		value = (mcu_data & 0xffff) * 100;
>> +		break;
>> +	case NSA3XX_FAN:
>> +		value = ((mcu_data & 0xff0000) >> 16) * 100;
>> +		break;
>> +	}
>> +	return sprintf(buf, "%lu\n", value);
>> +}
>> +
>> +static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, show_label, NULL, NSA3XX_TEMP);
>> +static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_value, NULL, NSA3XX_TEMP);
>> +static SENSOR_DEVICE_ATTR(fan1_label, S_IRUGO, show_label, NULL, NSA3XX_FAN);
>> +static SENSOR_DEVICE_ATTR(fan1_input, S_IRUGO, show_value, NULL, NSA3XX_FAN);
>> +
>> +static struct attribute *nsa3xx_attrs[] = {
>> +	&sensor_dev_attr_temp1_label.dev_attr.attr,
>> +	&sensor_dev_attr_temp1_input.dev_attr.attr,
>> +	&sensor_dev_attr_fan1_label.dev_attr.attr,
>> +	&sensor_dev_attr_fan1_input.dev_attr.attr,
>> +	NULL
>> +};
>> +
>> +ATTRIBUTE_GROUPS(nsa3xx);
>> +
>> +static const struct of_device_id of_nsa3xx_hwmon_match[] = {
>> +	{ .compatible = "zyxel,nsa320-mcu", },
>> +	{ },
>> +};
>> +
>> +static int nsa3xx_hwmon_probe(struct platform_device *pdev)
>> +{
>> +	struct nsa3xx_hwmon *hwmon;
>> +
>> +	hwmon = devm_kzalloc(&pdev->dev, sizeof(*hwmon), GFP_KERNEL);
>> +	if (!hwmon)
>> +		return -ENOMEM;
>> +
>> +	platform_set_drvdata(pdev, hwmon);
>
> Unnecessary.
removed
>
>> +
>> +	/* Look up the GPIO pins to use */
>> +	hwmon->act = devm_gpiod_get(&pdev->dev, "act", GPIOD_OUT_LOW);
>> +	hwmon->clk = devm_gpiod_get(&pdev->dev, "clk", GPIOD_OUT_HIGH);
>> +	hwmon->data = devm_gpiod_get(&pdev->dev, "data", GPIOD_IN);
>> +
>> +	if (IS_ERR(hwmon->act))
>> +		return PTR_ERR(hwmon->act);
>> +	if (IS_ERR(hwmon->clk))
>> +		return PTR_ERR(hwmon->clk);
>> +	if (IS_ERR(hwmon->data))
>> +		return PTR_ERR(hwmon->data);
>
> Please reorder to have the error checks immediately after the calls
> to devm_gpiod_get().
done
>
>> +
>> +	mutex_init(&hwmon->update_lock);
>> +
>> +	hwmon->classdev = devm_hwmon_device_register_with_groups(&pdev->dev,
>> +					"nsa3xx", hwmon, nsa3xx_groups);
>
> classdev is only used in this function and thus does not have to be kept
> in struct nsa3xx_hwmon.
removed
>
>> +	if (IS_ERR(hwmon->classdev))
>> +		return PTR_ERR(hwmon->classdev);
>> +
>> +	dev_dbg(&pdev->dev, "initialized\n");
>> +
>
> This message is really unnecessary. Please just use
> 	return PTR_ERR_OR_ZERO(classdev);
done
>
>> +	return 0;
>> +}
>> +
>> +static int nsa3xx_hwmon_remove(struct platform_device *pdev)
>> +{
>> +	/* All resources are allocated with devm_*() so
>> +	 * there is nothing to do here.
>> +	 */
>> +
>> +	return 0;
>> +}
>
> If the remove function is not needed, it is not needed and should not
> exist in the first place. Please no dummy functions.
>
done, I've left a comment to explain why there is no remove to prompt 
anyone who changes the code to use devres or add a remove method
>> +
>> +static struct platform_driver nsa3xx_hwmon_driver = {
>> +	.probe = nsa3xx_hwmon_probe,
>> +	.remove = nsa3xx_hwmon_remove,
>> +	.driver = {
>> +		.name = "nsa3xx-hwmon",
>> +		.owner = THIS_MODULE,
>> +		.of_match_table = of_match_ptr(of_nsa3xx_hwmon_match),
>> +	},
>> +};
>> +
>> +module_platform_driver(nsa3xx_hwmon_driver);
>> +
>> +MODULE_DEVICE_TABLE(of, of_nsa3xx_hwmon_match);
>> +MODULE_AUTHOR("Peter Schildmann <linux at schildmann.info>");
>> +MODULE_AUTHOR("Adam Baker <linux at baker-net.org.uk>");
>> +MODULE_DESCRIPTION("NSA3XX Hardware Monitoring");
>> +MODULE_LICENSE("GPL");
>
> GPL v2
done
>
>> +MODULE_ALIAS("platform:nsa3xx-hwmon");
>> --
>> 2.1.4
>>



From linux at roeck-us.net  Mon Feb 15 15:19:57 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 15 Feb 2016 15:19:57 -0800
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <CAFEAcA9Xy2L+edFAdUCpZFiO5NLGyrQPTQ6DgmuScbwEty-nzg@mail.gmail.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAFEAcA9Xy2L+edFAdUCpZFiO5NLGyrQPTQ6DgmuScbwEty-nzg@mail.gmail.com>
Message-ID: <56C25D1D.5080409@roeck-us.net>

On 02/15/2016 02:29 PM, Peter Maydell wrote:
> On 15 February 2016 at 17:05, Guenter Roeck <linux at roeck-us.net> wrote:
>> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
>> timers with utilization update callbacks' with next-20160215. An example
>> crash log and bisect results are attached below.
>>
>> Please let me know if there is anything I can do to help tracking down
>> the problem.
>>
>> Thanks,
>> Guenter
>>
>> ---
>>
>> Building arm:beagle:multi_v7_defconfig:omap3-beagle ... running ..... failed (crashed)
>> ------------
>> qemu log:
>
> You're using the QEMU beagle board emulation? Can I ask which
> QEMU you're using (qemu-linaro?). If the OMAP3 emulation is still
> actively useful to people I might have another stab at getting
> it into upstream QEMU some day...
>

Yes, I use qemu-linaro for those tests.

Is it useful ? Obviously for me, yes. It lets me test images in qemu,
and I don't need real hardware to run those tests. That means that
I don't depend on the hardware really working, and I am not hosed
if the hardware breaks down and I don't have a replacement. Plus,
of course, I don't need a lab with 90+ pieces of hardware.

Guenter



From linus.walleij at linaro.org  Mon Feb 15 15:23:37 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 16 Feb 2016 00:23:37 +0100
Subject: [PATCH 01/14] pinctrl: sunxi: Add A83T R_PIO controller support
In-Reply-To: <20160211151246.GO31506@lukather>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-2-git-send-email-vishnupatekar0510@gmail.com>
 <CACRpkdbCgOBQw28d=qc1fAURY3x8UdoWqiMtXMZ=uWLaQj-nbg@mail.gmail.com>
 <20160211123648.GN31506@lukather>
 <CACRpkdaGZ4-S1A9zUUaBXXEazyJf_uZ4ESiBhw-CpozXMxfDHg@mail.gmail.com>
 <20160211151246.GO31506@lukather>
Message-ID: <CACRpkdb7=x2bJP1nXpF2bP3U0t+NUHiuw_aeTAhbR8OXOrHn6A@mail.gmail.com>

On Thu, Feb 11, 2016 at 4:12 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> On Thu, Feb 11, 2016 at 02:47:57PM +0100, Linus Walleij wrote:

>> Can you guys supply a MAINTAINERS entry for the sunxi
>> stuff?
>
> We have one, and Chen-Yu is listed as co-maintainer:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n911

Modified request:
can you put in F: wildcards there to match the files pertaining to
the sunxi platform, so that scripts/find-maintainer.pl finds them.

Yours,
Linus Walleij


From heiko at sntech.de  Mon Feb 15 15:25:39 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 16 Feb 2016 00:25:39 +0100
Subject: [RESEND PATCH 0/8] Support and fixes the rk3228 SoCS for thermal
In-Reply-To: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
References: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
Message-ID: <3650760.H1YezDtoUE@phil>

Am Montag, 15. Februar 2016, 15:33:25 schrieb Caesar Wang:
> Hello Eduardo, Heiko, Michael & Stephen:
> 
> This series pacthes to support the rk3228 SoCs thermal.
> 
> They have the following patches to work on rk3228 SoCs.
> 

> 1a6f334 clk: rockchip: add id of the tsadc clock found on rk3228 SoCs
> 8cf2d1b clk: rockchip: add the tsadc clocks found on rk3228 SoCs
> bdc79c0 ARM: dts: rockchip: add the thermal main info found on rk3228
> 22ea3c3 ARM: dts: rockchip: enable the tsadc for rk3228 evb

clk and devicetree patches look good and I'll pick those up once Eduardo is 
ok with (and has taken) the thermal-specific changes:

> bd2720c thermal: rockchip: fix a impossible condition caused by the
> warning df9c1bd thermal: rockchip: fix calculation error for code_to_temp
> fb11fbd thermal: rockchip: the rename compatibles for rockchip SoCs
> b907b75 thermal: rockchip: fix the tsadc sequence output on rk3228/rk3399


Heiko



From linux at baker-net.org.uk  Mon Feb 15 15:25:04 2016
From: linux at baker-net.org.uk (Adam Baker)
Date: Mon, 15 Feb 2016 23:25:04 +0000
Subject: [PATCH v2 3/3] ARM: mvebu: Add the hardware monitor to the NSA320
 device tree
In-Reply-To: <1455578705-10531-1-git-send-email-linux@baker-net.org.uk>
References: <1455578705-10531-1-git-send-email-linux@baker-net.org.uk>
Message-ID: <1455578705-10531-4-git-send-email-linux@baker-net.org.uk>

Add an entry for the hardware monitoring MCU

Signed-off-by: Adam Baker <linux at baker-net.org.uk>
---
 arch/arm/boot/dts/kirkwood-nsa320.dts | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/kirkwood-nsa320.dts b/arch/arm/boot/dts/kirkwood-nsa320.dts
index 24f686d..2a935e9 100644
--- a/arch/arm/boot/dts/kirkwood-nsa320.dts
+++ b/arch/arm/boot/dts/kirkwood-nsa320.dts
@@ -193,10 +193,19 @@
 		};
 	};
 
+	hwmon {
+		compatible = "zyxel,nsa320-mcu";
+		pinctrl-0 = <&pmx_mcu_data &pmx_mcu_clk &pmx_mcu_act>;
+		pinctrl-names = "default";
+
+		data-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+		clk-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
+		act-gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
+	};
+
 	/* The following pins are currently not assigned to a driver,
 	   some of them should be configured as inputs.
-	pinctrl-0 = <&pmx_mcu_data &pmx_mcu_clk &pmx_mcu_act
-		     &pmx_htp &pmx_vid_b1
+	pinctrl-0 = <&pmx_htp &pmx_vid_b1
 		     &pmx_power_resume_data &pmx_power_resume_clk>; */
 };
 
-- 
2.1.4



From linux at baker-net.org.uk  Mon Feb 15 15:25:03 2016
From: linux at baker-net.org.uk (Adam Baker)
Date: Mon, 15 Feb 2016 23:25:03 +0000
Subject: [PATCH v2 2/3] hwmon: Create an NSA320 hardware monitoring driver
In-Reply-To: <1455578705-10531-1-git-send-email-linux@baker-net.org.uk>
References: <1455578705-10531-1-git-send-email-linux@baker-net.org.uk>
Message-ID: <1455578705-10531-3-git-send-email-linux@baker-net.org.uk>

Create a driver to support the hardware monitoring chip present in
the Zyxel NSA320 and some of the other Zyxel NAS devices.

The driver reads fan speed and temperature from a suitably
pre-programmed MCU on the device.

Signed-off-by: Adam Baker <linux at baker-net.org.uk>
---
 drivers/hwmon/Kconfig        |  15 +++
 drivers/hwmon/Makefile       |   1 +
 drivers/hwmon/nsa320-hwmon.c | 215 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 231 insertions(+)
 create mode 100644 drivers/hwmon/nsa320-hwmon.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 80a73bf..08fd7f5 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1186,6 +1186,21 @@ config SENSORS_NCT7904
 	  This driver can also be built as a module.  If so, the module
 	  will be called nct7904.
 
+config SENSORS_NSA320
+	tristate "ZyXEL NSA320 and compatible fan speed and temperature sensors"
+	depends on GPIOLIB && OF
+	depends on MACH_KIRKWOOD || COMPILE_TEST
+	help
+	  If you say yes here you get support for hardware monitoring
+	  for the ZyXEL NSA320 Media Server and other compatible devices
+	  (probably the NSA325 and some NSA310 variants).
+
+	  The sensor data is taken from a Holtek HT46R065 microcontroller
+	  connected to GPIO lines.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called nsa320-hwmon.
+
 config SENSORS_PCF8591
 	tristate "Philips PCF8591 ADC/DAC"
 	depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 12a3239..e555d6d 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -125,6 +125,7 @@ obj-$(CONFIG_SENSORS_NCT6775)	+= nct6775.o
 obj-$(CONFIG_SENSORS_NCT7802)	+= nct7802.o
 obj-$(CONFIG_SENSORS_NCT7904)	+= nct7904.o
 obj-$(CONFIG_SENSORS_NTC_THERMISTOR)	+= ntc_thermistor.o
+obj-$(CONFIG_SENSORS_NSA320)	+= nsa320-hwmon.o
 obj-$(CONFIG_SENSORS_PC87360)	+= pc87360.o
 obj-$(CONFIG_SENSORS_PC87427)	+= pc87427.o
 obj-$(CONFIG_SENSORS_PCF8591)	+= pcf8591.o
diff --git a/drivers/hwmon/nsa320-hwmon.c b/drivers/hwmon/nsa320-hwmon.c
new file mode 100644
index 0000000..f4bfa65
--- /dev/null
+++ b/drivers/hwmon/nsa320-hwmon.c
@@ -0,0 +1,215 @@
+/*
+ * drivers/hwmon/nsa320-hwmon.c
+ *
+ * ZyXEL NSA320 Media Servers
+ * hardware monitoring
+ *
+ * Copyright (C) 2016 Adam Baker <linux at baker-net.org.uk>
+ * based on a board file driver
+ * Copyright (C) 2012 Peter Schildmann <linux at schildmann.info>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License v2 as published by the
+ * Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/bitops.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/jiffies.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+
+#define MAGIC_NUMBER 0x55
+
+/*
+ * The Zyxel hwmon MCU is a Holtek HT46R065 that is factory programmed
+ * to perform temperature and fan speed monitoring. It is read by taking
+ * the active pin low. The 32 bit output word is then clocked onto the
+ * data line. The MSB of the data word is a magic nuber to indicate it
+ * has been read correctly, the next byte is the fan speed (in hundreds
+ * of RPM) and the last two bytes are the temperature (in tenths of a
+ * degree)
+ */
+
+struct nsa320_hwmon {
+	struct mutex		update_lock;	/* lock GPIO operations */
+	unsigned long		last_updated;	/* jiffies */
+	u32			mcu_data;
+	struct gpio_desc	*act;
+	struct gpio_desc	*clk;
+	struct gpio_desc	*data;
+};
+
+enum nsa320_inputs {
+	NSA3XX_TEMP = 0,
+	NSA3XX_FAN = 1,
+};
+
+static const char * const nsa320_input_names[] = {
+	[NSA3XX_FAN] = "Chassis Fan",
+	[NSA3XX_TEMP] = "System Temperature",
+};
+
+/* Although this protocol looks similar to SPI the long delay
+ * between the active (aka chip select) signal and the shorter
+ * delay between clock pulses are needed for reliable operation.
+ * The delays provided are taken from the manufacturer kernel,
+ * testing suggest they probably incorporate a reasonable safety
+ * margin. (The single device tested became unreliable if the
+ * delay was reduced to 1/10th of this value.)
+ */
+static int nsa320_hwmon_update(struct device *dev)
+{
+	u32 mcu_data;
+	u32 mask;
+	struct nsa320_hwmon *hwmon = dev_get_drvdata(dev);
+
+	mutex_lock(&hwmon->update_lock);
+
+	mcu_data = hwmon->mcu_data;
+
+	if (time_after(jiffies, hwmon->last_updated + HZ) || mcu_data == 0) {
+		gpiod_set_value(hwmon->act, 1);
+		msleep(100);
+
+		for (mask = BIT(31); mask; mask >>= 1) {
+			gpiod_set_value(hwmon->clk, 0);
+			usleep_range(100, 200);
+			gpiod_set_value(hwmon->clk, 1);
+			usleep_range(100, 200);
+			if (gpiod_get_value(hwmon->data))
+				mcu_data |= mask;
+		}
+
+		gpiod_set_value(hwmon->act, 0);
+		dev_dbg(dev, "Read raw MCU data %08x\n", mcu_data);
+
+		if ((mcu_data >> 24) != MAGIC_NUMBER) {
+			dev_dbg(dev, "Read invalid MCU data %08x\n", mcu_data);
+			return -EIO;
+		}
+
+		hwmon->mcu_data = mcu_data;
+		hwmon->last_updated = jiffies;
+	}
+
+	mutex_unlock(&hwmon->update_lock);
+
+	return 0;
+}
+
+static ssize_t show_label(struct device *dev,
+			  struct device_attribute *attr, char *buf)
+{
+	int channel = to_sensor_dev_attr(attr)->index;
+
+	return sprintf(buf, "%s\n", nsa320_input_names[channel]);
+}
+
+static ssize_t show_value(struct device *dev,
+			  struct device_attribute *attr, char *buf)
+{
+	int channel = to_sensor_dev_attr(attr)->index;
+	struct nsa320_hwmon *hwmon = dev_get_drvdata(dev);
+	unsigned long value = 0;
+	int ret = nsa320_hwmon_update(dev);
+
+	if (ret)
+		return ret;
+
+	switch (channel) {
+	case NSA3XX_TEMP:
+		value = (hwmon->mcu_data & 0xffff) * 100;
+		break;
+	case NSA3XX_FAN:
+		value = ((hwmon->mcu_data & 0xff0000) >> 16) * 100;
+		break;
+	default:
+		return -EINVAL;
+	}
+	return sprintf(buf, "%lu\n", value);
+}
+
+static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, show_label, NULL, NSA3XX_TEMP);
+static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_value, NULL, NSA3XX_TEMP);
+static SENSOR_DEVICE_ATTR(fan1_label, S_IRUGO, show_label, NULL, NSA3XX_FAN);
+static SENSOR_DEVICE_ATTR(fan1_input, S_IRUGO, show_value, NULL, NSA3XX_FAN);
+
+static struct attribute *nsa320_attrs[] = {
+	&sensor_dev_attr_temp1_label.dev_attr.attr,
+	&sensor_dev_attr_temp1_input.dev_attr.attr,
+	&sensor_dev_attr_fan1_label.dev_attr.attr,
+	&sensor_dev_attr_fan1_input.dev_attr.attr,
+	NULL
+};
+
+ATTRIBUTE_GROUPS(nsa320);
+
+static const struct of_device_id of_nsa320_hwmon_match[] = {
+	{ .compatible = "zyxel,nsa320-mcu", },
+	{ },
+};
+
+static int nsa320_hwmon_probe(struct platform_device *pdev)
+{
+	struct nsa320_hwmon	*hwmon;
+	struct device		*classdev;
+
+	hwmon = devm_kzalloc(&pdev->dev, sizeof(*hwmon), GFP_KERNEL);
+	if (!hwmon)
+		return -ENOMEM;
+
+	/* Look up the GPIO pins to use */
+	hwmon->act = devm_gpiod_get(&pdev->dev, "act", GPIOD_OUT_LOW);
+	if (IS_ERR(hwmon->act))
+		return PTR_ERR(hwmon->act);
+
+	hwmon->clk = devm_gpiod_get(&pdev->dev, "clk", GPIOD_OUT_HIGH);
+	if (IS_ERR(hwmon->clk))
+		return PTR_ERR(hwmon->clk);
+
+	hwmon->data = devm_gpiod_get(&pdev->dev, "data", GPIOD_IN);
+	if (IS_ERR(hwmon->data))
+		return PTR_ERR(hwmon->data);
+
+	mutex_init(&hwmon->update_lock);
+
+	classdev = devm_hwmon_device_register_with_groups(&pdev->dev,
+					"nsa320", hwmon, nsa320_groups);
+
+	return PTR_ERR_OR_ZERO(classdev);
+
+}
+
+/* All allocations use devres so remove() is not needed. */
+
+static struct platform_driver nsa320_hwmon_driver = {
+	.probe = nsa320_hwmon_probe,
+	.driver = {
+		.name = "nsa320-hwmon",
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(of_nsa320_hwmon_match),
+	},
+};
+
+module_platform_driver(nsa320_hwmon_driver);
+
+MODULE_DEVICE_TABLE(of, of_nsa320_hwmon_match);
+MODULE_AUTHOR("Peter Schildmann <linux at schildmann.info>");
+MODULE_AUTHOR("Adam Baker <linux at baker-net.org.uk>");
+MODULE_DESCRIPTION("NSA3XX Hardware Monitoring");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:nsa320-hwmon");
-- 
2.1.4



From linux at baker-net.org.uk  Mon Feb 15 15:25:02 2016
From: linux at baker-net.org.uk (Adam Baker)
Date: Mon, 15 Feb 2016 23:25:02 +0000
Subject: [PATCH v2 1/3] hwmon: Define binding for the nsa320-hwmon driver
In-Reply-To: <1455578705-10531-1-git-send-email-linux@baker-net.org.uk>
References: <1455578705-10531-1-git-send-email-linux@baker-net.org.uk>
Message-ID: <1455578705-10531-2-git-send-email-linux@baker-net.org.uk>

Define a binding for the hardware monitoring chip present in the Zyxel
NSA-320 and some of the other Zyxel NAS devices.

Signed-off-by: Adam Baker <linux at baker-net.org.uk>
---
 .../devicetree/bindings/hwmon/nsa320-mcu.txt        | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt

diff --git a/Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt b/Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt
new file mode 100644
index 0000000..7b346d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt
@@ -0,0 +1,21 @@
+Bindings for the fan / temperature monitor microcontroller used on
+the Zyxel NSA 320 and several subsequent models.
+
+Required properties:
+- compatible	: "zyxel,nsa320-mcu"
+- data-gpios	: The GPIO pin connected to the data line on the MCU
+- clk-gpios	: The GPIO pin connected to the clock line on the MCU
+- act-gpios	: The GPIO pin connected to the active line on the MCU
+
+Example:
+
+	hwmon {
+		compatible = "zyxel,nsa320-mcu";
+		pinctrl-0 = <&pmx_mcu_data &pmx_mcu_clk &pmx_mcu_act>;
+		pinctrl-names = "default";
+
+		data-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
+		clk-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
+		act-gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
+	};
+
-- 
2.1.4



From linux at baker-net.org.uk  Mon Feb 15 15:25:01 2016
From: linux at baker-net.org.uk (Adam Baker)
Date: Mon, 15 Feb 2016 23:25:01 +0000
Subject: [PATCH v2] A driver for the hardware monitoring chip in the Zyxel
 NSA320
Message-ID: <1455578705-10531-1-git-send-email-linux@baker-net.org.uk>

This patch series adds a driver to support the hardware monitoring MCU
that is present in the Zyxel NSA320. It is believed that this is
identical to the one used in the NSA325 and some variants of the NSA310.

 Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt |  21 ++++++++
 arch/arm/boot/dts/kirkwood-nsa320.dts                  |  13 ++++-
 drivers/hwmon/Kconfig                                  |  15 ++++++
 drivers/hwmon/Makefile                                 |   1 +
 drivers/hwmon/nsa320-hwmon.c                           | 215 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 263 insertions(+), 2 deletions(-)


Changes since v1
Update to reflect review comments from Guenter Roeck,
mainly changing it to be nsa320, not nsa3xx but also making it
return an errno on failure and various other tidy ups.

I'm not sure what protocol is with regard to adding tags to a patch
when updating it, in v1

patch 1 received
Acked-by: Rob Herring <robh at kernel.org>

patch 2 was reviewed by Guenter Roeck but does the reviewed by tag
only get added if he agrees with the changes?

Sebastian Hesselbarth reviewed an early draft before it was posted
publicly.



From linus.walleij at linaro.org  Mon Feb 15 15:26:37 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 16 Feb 2016 00:26:37 +0100
Subject: [PATCH v5 1/3] gpio: xgene: Enable X-Gene standby GPIO as
 interrupt controller
In-Reply-To: <56BB52B8.4040501@arm.com>
References: <1454041735-8434-1-git-send-email-qnguyen@apm.com>
 <1454041735-8434-2-git-send-email-qnguyen@apm.com>
 <56BB52B8.4040501@arm.com>
Message-ID: <CACRpkdYg+Z1Y_MSFxaGbJiMiAPjX5EF4_dnWO6q5LCd0m0Fv_A@mail.gmail.com>

On Wed, Feb 10, 2016 at 4:09 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 29/01/16 04:28, Quan Nguyen wrote:

>> +static void xgene_gpio_sb_domain_deactivate(struct irq_domain *d,
>> +             struct irq_data *irq_data)
>> +{
>> +     struct xgene_gpio_sb *priv = d->host_data;
>> +     u32 gpio = HWIRQ_TO_GPIO(priv, irq_data->hwirq);
>> +
>> +     gpiochip_unlock_as_irq(&priv->gc, gpio);
>
> Is it right to do the unlock both in irq_shutdown and domain_deactivate?
> This seems a bit odd to me to have such an inbalance. My hunch is that
> you should either implement irq_startup, do the locking there and drop
> the unlock drop deactivate, or kill irq_shutdown.
>
> Linus, what do you think?

Those functions should be called in .irq_alloc/release_resources(), that is
why Gleixner added those callbacks in the first place.

Yours,
Linus Walleij


From laurent.pinchart at ideasonboard.com  Mon Feb 15 15:33:30 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 16 Feb 2016 01:33:30 +0200
Subject: [PATCH/RFC v2 01/11] PM / Domains: Add DT bindings for the R-Car
 System Controller
In-Reply-To: <1720075.YOPnCQ3mE1@avalon>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
 <1455571020-18968-2-git-send-email-geert+renesas@glider.be>
 <1720075.YOPnCQ3mE1@avalon>
Message-ID: <5091338.oFBh65VqCT@avalon>

On Tuesday 16 February 2016 01:08:18 Laurent Pinchart wrote:
> On Monday 15 February 2016 22:16:50 Geert Uytterhoeven wrote:
> > The Renesas R-Car System Controller provides power management for the
> > CPU cores and various coprocessors, following the generic PM domain
> > bindings in Documentation/devicetree/bindings/power/power_domain.txt.
> > 
> > This supports R-Car Gen1, Gen2, and Gen3.
> > 
> > Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> > ---

[snip]
> > 
> >  .../bindings/power/renesas,sysc-rcar.txt           | 87 +++++++++++++++++
> >  1 file changed, 87 insertions(+) create mode 100644
> > 
> > Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt
> > b/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt new file
> > mode 100644
> > index 0000000000000000..92ddc0da7b755215
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt
> > @@ -0,0 +1,87 @@

[snip]

> > +  - pm-domains: This node contains a hierarchy of PM Domain Nodes.
> 
> Can't it be an issue that the node happens to have the same name as the
> standard pm-domains property ?

Scratch this, it's power-domains, not pm-domains, mybad.

> > +    Dependencies (e.g. parent SCUs should not be powered off while child
> > CPUs
> > +    are on) should be reflected using subnodes.

-- 
Regards,

Laurent Pinchart



From mturquette at baylibre.com  Mon Feb 15 15:31:02 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Mon, 15 Feb 2016 15:31:02 -0800
Subject: [PATCH 0/3] clk: mvebu: initial support for AP806 clocks
In-Reply-To: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20160215233102.2278.88855@quark.deferred.io>

Hi Thomas,

Quoting Thomas Petazzoni (2016-02-14 23:34:55)
> Hello,
> 
> The following set of patches add initial support for the main clocks
> found in the AP806 hardware block, which is the central block used in
> the newest Marvell 7K and 8K 64-bits processors.
> 
> Two new drivers are added, one for the so-called "core" clocks and one
> for the "ring" clocks. The latter are child clocks from one of the
> core clocks. The "core" clocks are fixed rate clocks, but their rate
> is calculated from values in the Sample At Reset register.
> 
> The support for the Marvell 7K/8K platform (Device Tree, etc.) will be
> submitted as a separate patch series.

Yay, new SoC! Just FYI, we worked out an agreement in December[0] that
the clk git tree can take DT bindings and headers, and we'll always host
them in an immutable branch by default in case arm-soc (or anyone else)
needs them. Stephen and I are doing this now.

It's nice for us to review those bindings at the same time that we
review the driver.

[0] http://lkml.kernel.org/r/<20151231001859.19557.99512 at quark.deferred.io>

Best regards,
Mike

> 
> Thanks!
> 
> Thomas
> 
> Thomas Petazzoni (3):
>   clk: unconditionally recurse into clk/mvebu/
>   clk: mvebu: add AP806 core clock driver
>   clk: mvebu: add AP806 ring clock driver
> 
>  .../clock/mvebu-armada-ap806-core-clock.txt        |  33 ++++++
>  .../clock/mvebu-armada-ap806-ring-clock.txt        |  32 ++++++
>  drivers/clk/Makefile                               |   2 +-
>  drivers/clk/mvebu/Kconfig                          |   6 ++
>  drivers/clk/mvebu/Makefile                         |   3 +-
>  drivers/clk/mvebu/ap806-core.c                     | 112 +++++++++++++++++++++
>  drivers/clk/mvebu/ap806-ring.c                     |  65 ++++++++++++
>  7 files changed, 251 insertions(+), 2 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt
>  create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt
>  create mode 100644 drivers/clk/mvebu/ap806-core.c
>  create mode 100644 drivers/clk/mvebu/ap806-ring.c
> 
> -- 
> 2.6.4
> 


From linus.walleij at linaro.org  Mon Feb 15 15:34:51 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 16 Feb 2016 00:34:51 +0100
Subject: [PATCH 00/11] CLCD Nomadik+Versatile support
In-Reply-To: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <CACRpkda=mgcF8RRymbe0AAKpfCWGZSw_YZP5_6JW2g-mKEt16g@mail.gmail.com>

On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij at linaro.org> wrote:

> Eventually I would like to have patches 1 thru 8 (those with
> patches to CLCD or the DT bindings) applied through the FBDEV
> subsystem,

If there are no comments, would the fbdev people consider
patches 1 thru 8?

Yours,
Linus Walleij


From mturquette at baylibre.com  Mon Feb 15 15:36:49 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Mon, 15 Feb 2016 15:36:49 -0800
Subject: [PATCH 0/3] clk: mvebu: initial support for AP806 clocks
In-Reply-To: <20160215233102.2278.88855@quark.deferred.io>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160215233102.2278.88855@quark.deferred.io>
Message-ID: <CAEG3pNCRa_CQx70aPHfQpG+7jEZ_=_-FxBWDkXVYbgH=j=1rmA@mail.gmail.com>

Thomas,

On Mon, Feb 15, 2016 at 3:31 PM, Michael Turquette
<mturquette at baylibre.com> wrote:
> Hi Thomas,
>
> Quoting Thomas Petazzoni (2016-02-14 23:34:55)
>> Hello,
>>
>> The following set of patches add initial support for the main clocks
>> found in the AP806 hardware block, which is the central block used in
>> the newest Marvell 7K and 8K 64-bits processors.
>>
>> Two new drivers are added, one for the so-called "core" clocks and one
>> for the "ring" clocks. The latter are child clocks from one of the
>> core clocks. The "core" clocks are fixed rate clocks, but their rate
>> is calculated from values in the Sample At Reset register.
>>
>> The support for the Marvell 7K/8K platform (Device Tree, etc.) will be
>> submitted as a separate patch series.
>
> Yay, new SoC! Just FYI, we worked out an agreement in December[0] that
> the clk git tree can take DT bindings and headers, and we'll always host
> them in an immutable branch by default in case arm-soc (or anyone else)
> needs them. Stephen and I are doing this now.

Oops, I misunderstood your point (and I should have looked at the
patches before replying). The patches in this series do indeed have
the clk DT binding descriptions.

Pardon the noise, nothing to see here, move along ;-)

Regards,
Mike

>
> It's nice for us to review those bindings at the same time that we
> review the driver.
>
> [0] http://lkml.kernel.org/r/<20151231001859.19557.99512 at quark.deferred.io>
>
> Best regards,
> Mike
>
>>
>> Thanks!
>>
>> Thomas
>>
>> Thomas Petazzoni (3):
>>   clk: unconditionally recurse into clk/mvebu/
>>   clk: mvebu: add AP806 core clock driver
>>   clk: mvebu: add AP806 ring clock driver
>>
>>  .../clock/mvebu-armada-ap806-core-clock.txt        |  33 ++++++
>>  .../clock/mvebu-armada-ap806-ring-clock.txt        |  32 ++++++
>>  drivers/clk/Makefile                               |   2 +-
>>  drivers/clk/mvebu/Kconfig                          |   6 ++
>>  drivers/clk/mvebu/Makefile                         |   3 +-
>>  drivers/clk/mvebu/ap806-core.c                     | 112 +++++++++++++++++++++
>>  drivers/clk/mvebu/ap806-ring.c                     |  65 ++++++++++++
>>  7 files changed, 251 insertions(+), 2 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt
>>  create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt
>>  create mode 100644 drivers/clk/mvebu/ap806-core.c
>>  create mode 100644 drivers/clk/mvebu/ap806-ring.c
>>
>> --
>> 2.6.4
>>



-- 
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/


From mark.yao at rock-chips.com  Mon Feb 15 16:39:09 2016
From: mark.yao at rock-chips.com (Mark yao)
Date: Tue, 16 Feb 2016 08:39:09 +0800
Subject: [PATCH v2 15/17] drm/rockchip: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <cae559aa2c04a906c21ed5ebe4861f92440e6910.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
 <cae559aa2c04a906c21ed5ebe4861f92440e6910.1455540137.git.palminha@synopsys.com>
Message-ID: <56C26FAD.5040102@rock-chips.com>

On 2016?02?15? 21:01, Carlos Palminha wrote:
> mode_fixup function for encoder drivers became optional with patch
> http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com
>
> This patch set nukes all the dummy mode_fixup implementations.
>
> (made on top of Daniel topic/drm-misc branch)
>
> Signed-off-by: Carlos Palminha <palminha at synopsys.com>
> ---
>   drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 8 --------
>   1 file changed, 8 deletions(-)
>
>
Acked-by: Mark Yao <mark.yao at rock-chips.com>

Thanks
Mark




From mark.yao at rock-chips.com  Mon Feb 15 16:44:41 2016
From: mark.yao at rock-chips.com (Mark yao)
Date: Tue, 16 Feb 2016 08:44:41 +0800
Subject: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver
In-Reply-To: <1454049768-30872-1-git-send-email-ykk@rock-chips.com>
References: <1454049768-30872-1-git-send-email-ykk@rock-chips.com>
Message-ID: <56C270F9.9030707@rock-chips.com>

Hi

Ping, it seems inno hdmi driver is ready, So I'd like to merge it into 
drm/rockchip if there is no doubt these days.

Thanks.
Mark
On 2016?01?29? 14:42, Yakir Yang wrote:
> Here are a brief introduction to Innosilicon HDMI IP:
>    - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter
>    - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec
>    - Digital video interface supports a pixel size of 24, 30, 36, 48bits color depth in RGB
>    - S/PDIF output supports PCM, Dolby Digital, DTS digital audio transmission
>      (32-192kHz Fs) using IEC60958 and IEC 61937
>    - The EDID and CEC function are also supported by Innosilicon HDMI Transmitter Controlle
>
> Changes in v8:
> - Don't check whether encoder output format is RGB colorspace, cause driver
>    default configure the output colorspace to RGB. (ZhengYang)
> - Correct the check condition in inno_hdmi_config_video_csc() (ZhengYang)
>      - if (data->enc_out_format == data->enc_out_format) {
>      + if (data->enc_in_format == data->enc_out_format) {
>
> Changes in v7:
> - Correct the module licnese statement (Paul)
>       - MODULE_LICENSE("GPL");
>       + MODULE_LICENSE("GPLv2");
> - Start indentation with tabs and fix the misspell in Kconfig (Paul)
> - Carry the lost device-binding document (Heiko)
>
> Changes in v6:
> - Rebase the Makefile/Kconfig files which add by Chris's rockchip-mipi driver (Caeser)
>
> Changes in v5:
> - Use hdmi_infoframe helper functions to packed the infoframe (Russell)
> - Remove the unused double wait_for_completion_timeout for ddc transfer (Russell)
> - Remove the unused local variable in "inno_hdmi_i2c_write()" function (Russell)
>
> Changes in v4:
> - Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
> - Correct the "DKMS" to "DPMS" (Mark)
> - Fix over 80 characters problems (Mark)
> - Remove encoder .prepare/.commit helper functions, and move the vop mode
> configure function into encoder .enable helper functions. (Mark)
>
> Changes in v3:
> - Use encoder enable/disable function, and remove the encoder DPMS function
> - Keep HDMI PLL power on in standby mode
>
> Changes in v2:
> - Using DRM atomic helper functions for connector init (Mark)
> - Remove "hdmi->connector.encoder = encoder;" (Mark)
> - Add the Acked-by tags from Rob
> - Correct the misspell "rk3036-dw-hdmi" (Heiko)
>
> Yakir Yang (2):
>    drm/rockchip: hdmi: add Innosilicon HDMI support
>    dt-bindings: add document for Innosilicon HDMI on Rockchip platform
>
>   .../display/rockchip/inno_hdmi-rockchip.txt        |  50 ++
>   drivers/gpu/drm/rockchip/Kconfig                   |   8 +
>   drivers/gpu/drm/rockchip/Makefile                  |   1 +
>   drivers/gpu/drm/rockchip/inno_hdmi.c               | 939 +++++++++++++++++++++
>   drivers/gpu/drm/rockchip/inno_hdmi.h               | 362 ++++++++
>   5 files changed, 1360 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
>   create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
>   create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h
>



From viresh.kumar at linaro.org  Mon Feb 15 17:13:35 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Tue, 16 Feb 2016 06:43:35 +0530
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor:
 Replace timers with utilization ...'
In-Reply-To: <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
Message-ID: <20160216011335.GI6334@vireshk-i7>

On 15-02-16, 19:41, Rafael J. Wysocki wrote:
> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck <linux at roeck-us.net> wrote:
> > [    1.340000] [<c0958e78>] (__cpufreq_driver_target) from [<c095ca58>] (dbs_check_cpu+0x1ac/0x1e8)
> > [    1.340000] [<c095ca58>] (dbs_check_cpu) from [<c095cd04>] (cpufreq_governor_dbs+0x1fc/0x608)
> > [    1.340000] [<c095cd04>] (cpufreq_governor_dbs) from [<c0959c5c>] (__cpufreq_governor+0x1a8/0x204)
> > [    1.340000] [<c0959c5c>] (__cpufreq_governor) from [<c095a2dc>] (cpufreq_init_policy+0x60/0x8c)
> > [    1.340000] [<c095a2dc>] (cpufreq_init_policy) from [<c095a5f0>] (cpufreq_online+0x2e8/0x708)
> > [    1.340000] [<c095a5f0>] (cpufreq_online) from [<c075674c>] (subsys_interface_register+0x80/0xc4)
> > [    1.340000] [<c075674c>] (subsys_interface_register) from [<c0959764>] (cpufreq_register_driver+0x144/0x1a0)
> 
> This is the registration of the cpufreq driver (cpufreq-dt in this case).
> 
> It does cpufreq_online()->cpufreq_init_policy()->__cpufreq_governor()->cpufreq_governor_dbs()->dbs_check_cpu().
> 
> The only way that can happen is when cpufreq_set_policy() finds that
> the "old" and the "new" policies use the same governor, so it goes and
> calls __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS), but I'm not sure
> how this is possible during the initialization ATM.
> 
> Viresh, any ideas?

You misread probably.

During init, policy->gov is NULL and new_policy->gov is set to the
default one, probably ondemand/conservative. And in that case, we do:
- INIT
- START
- LIMITS

So above sequence is guaranteed to happen rather.

-- 
viresh


From rjw at rjwysocki.net  Mon Feb 15 17:20:36 2016
From: rjw at rjwysocki.net (Rafael J. Wysocki)
Date: Tue, 16 Feb 2016 02:20:36 +0100
Subject: [PATCH v6 1/2] ACPI: introduce a function to find the first
 physical device
In-Reply-To: <1453300171-25473-2-git-send-email-aleksey.makarov@linaro.org>
References: <1453300171-25473-1-git-send-email-aleksey.makarov@linaro.org>
 <1453300171-25473-2-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <2019009.4Y5n3ZF6bK@vostro.rjw.lan>

On Wednesday, January 20, 2016 08:29:26 PM Aleksey Makarov wrote:
> Factor out the code that finds the first physical device
> of a given ACPI device.  It is used in several places.
> 
> Reviewed-by: Andy Shevchenko <andy.shevchenko at gmail.com>

I guess the above doesn't apply any more, does it?

> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> ---
>  drivers/acpi/acpi_platform.c | 19 ++-----------------
>  drivers/acpi/bus.c           | 33 ++++++++++++++++++++++-----------
>  drivers/acpi/internal.h      |  1 +
>  3 files changed, 25 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> index 296b7a1..c3af108 100644
> --- a/drivers/acpi/acpi_platform.c
> +++ b/drivers/acpi/acpi_platform.c
> @@ -43,7 +43,6 @@ static const struct acpi_device_id forbidden_id_list[] = {
>  struct platform_device *acpi_create_platform_device(struct acpi_device *adev)
>  {
>  	struct platform_device *pdev = NULL;
> -	struct acpi_device *acpi_parent;
>  	struct platform_device_info pdevinfo;
>  	struct resource_entry *rentry;
>  	struct list_head resource_list;
> @@ -82,22 +81,8 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev)
>  	 * attached to it, that physical device should be the parent of the
>  	 * platform device we are about to create.
>  	 */
> -	pdevinfo.parent = NULL;
> -	acpi_parent = adev->parent;
> -	if (acpi_parent) {
> -		struct acpi_device_physical_node *entry;
> -		struct list_head *list;
> -
> -		mutex_lock(&acpi_parent->physical_node_lock);
> -		list = &acpi_parent->physical_node_list;
> -		if (!list_empty(list)) {
> -			entry = list_first_entry(list,
> -					struct acpi_device_physical_node,
> -					node);
> -			pdevinfo.parent = entry->dev;
> -		}
> -		mutex_unlock(&acpi_parent->physical_node_lock);
> -	}
> +	pdevinfo.parent = adev->parent ?
> +		acpi_get_first_physical_node(adev->parent) : NULL;
>  	pdevinfo.name = dev_name(&adev->dev);
>  	pdevinfo.id = -1;
>  	pdevinfo.res = resources;
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index a212cef..832b26d 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -478,24 +478,35 @@ static void acpi_device_remove_notify_handler(struct acpi_device *device)
>                               Device Matching
>     -------------------------------------------------------------------------- */
>  
> -static struct acpi_device *acpi_primary_dev_companion(struct acpi_device *adev,
> -						      const struct device *dev)
> +/**
> + * acpi_device_fix_parent - Get first physical node of an ACPI device

Please fix the function name here.

> + * @adev: ACPI device in question
> + */
> +struct device *acpi_get_first_physical_node(struct acpi_device *adev)
>  {
>  	struct mutex *physical_node_lock = &adev->physical_node_lock;
> +	struct device *node = NULL;
>  
>  	mutex_lock(physical_node_lock);
> -	if (list_empty(&adev->physical_node_list)) {
> -		adev = NULL;
> -	} else {
> -		const struct acpi_device_physical_node *node;
>  
> +	if (!list_empty(&adev->physical_node_list))
>  		node = list_first_entry(&adev->physical_node_list,
> -					struct acpi_device_physical_node, node);
> -		if (node->dev != dev)
> -			adev = NULL;
> -	}
> +				struct acpi_device_physical_node, node)->dev;
> +

No, you don't have to change all that code.

Exercise: rework this function with as few lines of code changed as you possibly can.

>  	mutex_unlock(physical_node_lock);
> -	return adev;
> +
> +	return node;
> +}
> +
> +static struct acpi_device *acpi_primary_dev_companion(struct acpi_device *adev,
> +						      const struct device *dev)
> +{
> +	const struct device *node = acpi_get_first_physical_node(adev);

s/node/phys_dev/ ?

> +
> +	if (node && node == dev)
> +		return adev;
> +
> +	return NULL;

return phys_dev && phys_dev == dev ? adev : NULL;

One line of code instead of 4.

>  }
>  
>  /**
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 11d87bf..ee9312ba 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -98,6 +98,7 @@ bool acpi_device_is_present(struct acpi_device *adev);
>  bool acpi_device_is_battery(struct acpi_device *adev);
>  bool acpi_device_is_first_physical_node(struct acpi_device *adev,
>  					const struct device *dev);
> +struct device *acpi_get_first_physical_node(struct acpi_device *adev);
>  
>  /* --------------------------------------------------------------------------
>                       Device Matching and Notification
> 

Thanks,
Rafael



From rjw at rjwysocki.net  Mon Feb 15 17:21:59 2016
From: rjw at rjwysocki.net (Rafael J. Wysocki)
Date: Tue, 16 Feb 2016 02:21:59 +0100
Subject: [PATCH v6 1/2] ACPI: introduce a function to find the first
 physical device
In-Reply-To: <CAHp75VcdtU6izThE+Z2ODnYoXk-uhweXzUtFwSze_jJHw3+38g@mail.gmail.com>
References: <1453300171-25473-1-git-send-email-aleksey.makarov@linaro.org>
 <1453300171-25473-2-git-send-email-aleksey.makarov@linaro.org>
 <CAHp75VcdtU6izThE+Z2ODnYoXk-uhweXzUtFwSze_jJHw3+38g@mail.gmail.com>
Message-ID: <2019010.CjT5f3j553@vostro.rjw.lan>

On Wednesday, January 20, 2016 05:12:18 PM Andy Shevchenko wrote:
> On Wed, Jan 20, 2016 at 4:29 PM, Aleksey Makarov
> <aleksey.makarov at linaro.org> wrote:
> > Factor out the code that finds the first physical device
> > of a given ACPI device.  It is used in several places.
> >
> > Reviewed-by: Andy Shevchenko <andy.shevchenko at gmail.com>
> > Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> 
> Hmm? Sorry, didn't notice one style issue and there is one is matter
> of taste below.
> 
> > --- a/drivers/acpi/acpi_platform.c
> > +++ b/drivers/acpi/acpi_platform.c
> > @@ -43,7 +43,6 @@ static const struct acpi_device_id forbidden_id_list[] = {
> 
> > +       pdevinfo.parent = adev->parent ?
> > +               acpi_get_first_physical_node(adev->parent) : NULL;
> 
> Matter of taste, but I believe if-else looks better here even when
> consumes +2 LOC.

I disagree.

Thanks,
Rafael



From rjw at rjwysocki.net  Mon Feb 15 17:23:46 2016
From: rjw at rjwysocki.net (Rafael J. Wysocki)
Date: Tue, 16 Feb 2016 02:23:46 +0100
Subject: [PATCH v6 2/2] ACPI: amba bus probing support
In-Reply-To: <1453300171-25473-3-git-send-email-aleksey.makarov@linaro.org>
References: <1453300171-25473-1-git-send-email-aleksey.makarov@linaro.org>
 <1453300171-25473-3-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1558867.xs6LSUHIo3@vostro.rjw.lan>

On Wednesday, January 20, 2016 08:29:27 PM Aleksey Makarov wrote:
> From: Graeme Gregory <graeme.gregory at linaro.org>
> 
> On ARM64 some devices use the AMBA device and not the platform bus for
> probing so add support for this. Uses a dummy clock for apb_pclk as ACPI
> does not have a suitable clock representation and to keep the core
> AMBA bus code unchanged between probing methods.
> 
> Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>
> Signed-off-by: Graeme Gregory <graeme.gregory at linaro.org>
> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>

This one looks OK to me, so please just post an update of the [1/2].

Thanks,
Rafael



From rjw at rjwysocki.net  Mon Feb 15 17:27:15 2016
From: rjw at rjwysocki.net (Rafael J. Wysocki)
Date: Tue, 16 Feb 2016 02:27:15 +0100
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <20160216011335.GI6334@vireshk-i7>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
 <20160216011335.GI6334@vireshk-i7>
Message-ID: <6826860.yxabWEoz5T@vostro.rjw.lan>

On Tuesday, February 16, 2016 06:43:35 AM Viresh Kumar wrote:
> On 15-02-16, 19:41, Rafael J. Wysocki wrote:
> > On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck <linux at roeck-us.net> wrote:
> > > [    1.340000] [<c0958e78>] (__cpufreq_driver_target) from [<c095ca58>] (dbs_check_cpu+0x1ac/0x1e8)
> > > [    1.340000] [<c095ca58>] (dbs_check_cpu) from [<c095cd04>] (cpufreq_governor_dbs+0x1fc/0x608)
> > > [    1.340000] [<c095cd04>] (cpufreq_governor_dbs) from [<c0959c5c>] (__cpufreq_governor+0x1a8/0x204)
> > > [    1.340000] [<c0959c5c>] (__cpufreq_governor) from [<c095a2dc>] (cpufreq_init_policy+0x60/0x8c)
> > > [    1.340000] [<c095a2dc>] (cpufreq_init_policy) from [<c095a5f0>] (cpufreq_online+0x2e8/0x708)
> > > [    1.340000] [<c095a5f0>] (cpufreq_online) from [<c075674c>] (subsys_interface_register+0x80/0xc4)
> > > [    1.340000] [<c075674c>] (subsys_interface_register) from [<c0959764>] (cpufreq_register_driver+0x144/0x1a0)
> > 
> > This is the registration of the cpufreq driver (cpufreq-dt in this case).
> > 
> > It does cpufreq_online()->cpufreq_init_policy()->__cpufreq_governor()->cpufreq_governor_dbs()->dbs_check_cpu().
> > 
> > The only way that can happen is when cpufreq_set_policy() finds that
> > the "old" and the "new" policies use the same governor, so it goes and
> > calls __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS), but I'm not sure
> > how this is possible during the initialization ATM.
> > 
> > Viresh, any ideas?
> 
> You misread probably.
> 
> During init, policy->gov is NULL and new_policy->gov is set to the
> default one, probably ondemand/conservative. And in that case, we do:
> - INIT
> - START
> - LIMITS

Yes, that's what we should be doing, but it seemed to me that we didn't.

Or maybe the trace just contained the last one, because that's when the
crash happened.

Thanks,
Rafael



From mathieu.poirier at linaro.org  Mon Feb 15 17:25:56 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Mon, 15 Feb 2016 18:25:56 -0700
Subject: [PATCH] drivers/hwtracing: make coresight-* explicitly non-modular
In-Reply-To: <1455470351-15219-1-git-send-email-paul.gortmaker@windriver.com>
References: <1455470351-15219-1-git-send-email-paul.gortmaker@windriver.com>
Message-ID: <CANLsYkyY84Tp2oxP9JdAq6WGp9rBXQc=7nXS2hfi9hkcrFEKCw@mail.gmail.com>

On 14 February 2016 at 10:19, Paul Gortmaker
<paul.gortmaker at windriver.com> wrote:
> None of the Kconfig currently controlling compilation of any of
> the files here are tristate, meaning that none of it currently
> is being built as a module by anyone.
>
> We need not be concerned about .remove functions and blocking the
> unbind sysfs operations, since that was already done in a recent
> commit.
>
> Lets remove any remaining modular references, so that when reading the
> drivers there is no doubt they are builtin-only.
>
> All drivers get mostly the same changes, so they are handled in batch.
> Changes are (1) convert to builtin_amba_driver, (2) delete module.h
> include where unused, and (3) relocate the description into the
> comments so we don't need MODULE_DESCRIPTION and associated tags.
>
> The etm3x and etm4x use module_param_named, and have been adjusted
> to just include moduleparam.h for that purpose.
>
> In commit f309d4443130bf814e991f836e919dca22df37ae ("platform_device:
> better support builtin boilerplate avoidance") we introduced the
> builtin_driver macro.
>
> Here we use that support and extend it to amba driver registration,
> so where a driver is clearly non-modular and builtin-only, we can
> update with the simple mapping of
>
>      module_amba_driver(...)  ---> builtin_amba_driver(...)
>
> Since module_amba_driver() uses the same init level priority as
> builtin_amba_driver() the init ordering remains unchanged with
> this commit.
>
> Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> ---
>
> [This is what I sent back in October[1], but with the .remove and
>  .suppress bits stripped out, since that is now in Mathieu's queue.
>  And to make this a standalone commit that Mathieu can also add to
>  his queue, I've squished the amba/bus.h change[2] into this change.]
>
> [1]  http://www.spinics.net/lists/kernel/msg2096702.html
> [2]  http://lkml.iu.edu/hypermail/linux/kernel/1510.1/02464.html
>
>  drivers/hwtracing/coresight/coresight-etb10.c           |  9 +++------
>  drivers/hwtracing/coresight/coresight-etm3x.c           | 14 ++++++++------
>  drivers/hwtracing/coresight/coresight-etm4x.c           |  4 +---
>  drivers/hwtracing/coresight/coresight-funnel.c          |  9 +++------
>  drivers/hwtracing/coresight/coresight-replicator-qcom.c |  4 +---
>  drivers/hwtracing/coresight/coresight-replicator.c      |  7 ++-----
>  drivers/hwtracing/coresight/coresight-tmc.c             |  9 +++------
>  drivers/hwtracing/coresight/coresight-tpiu.c            |  9 +++------
>  drivers/hwtracing/coresight/coresight.c                 |  3 ---
>  drivers/hwtracing/coresight/of_coresight.c              |  1 -
>  include/linux/amba/bus.h                                |  9 +++++++++
>  11 files changed, 33 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
> index 92969dae739d..21f6afd24a66 100644
> --- a/drivers/hwtracing/coresight/coresight-etb10.c
> +++ b/drivers/hwtracing/coresight/coresight-etb10.c
> @@ -1,5 +1,7 @@
>  /* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
>   *
> + * Description: CoreSight Embedded Trace Buffer driver
> + *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License version 2 and
>   * only version 2 as published by the Free Software Foundation.
> @@ -11,7 +13,6 @@
>   */
>
>  #include <linux/kernel.h>
> -#include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/types.h>
>  #include <linux/device.h>
> @@ -534,8 +535,4 @@ static struct amba_driver etb_driver = {
>         .probe          = etb_probe,
>         .id_table       = etb_ids,
>  };
> -
> -module_amba_driver(etb_driver);
> -
> -MODULE_LICENSE("GPL v2");
> -MODULE_DESCRIPTION("CoreSight Embedded Trace Buffer driver");
> +builtin_amba_driver(etb_driver);
> diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
> index aae80e14508d..8750b432ad36 100644
> --- a/drivers/hwtracing/coresight/coresight-etm3x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm3x.c
> @@ -1,5 +1,7 @@
>  /* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
>   *
> + * Description: CoreSight Program Flow Trace driver
> + *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License version 2 and
>   * only version 2 as published by the Free Software Foundation.
> @@ -11,7 +13,7 @@
>   */
>
>  #include <linux/kernel.h>
> -#include <linux/module.h>
> +#include <linux/moduleparam.h>
>  #include <linux/init.h>
>  #include <linux/types.h>
>  #include <linux/device.h>
> @@ -35,6 +37,10 @@
>
>  #include "coresight-etm.h"
>
> +/*
> + * not really modular but using module_param is the easiest way to
> + * remain consistent with existing use cases for now.
> + */
>  static int boot_enable;
>  module_param_named(boot_enable, boot_enable, int, S_IRUGO);
>
> @@ -1950,8 +1956,4 @@ static struct amba_driver etm_driver = {
>         .probe          = etm_probe,
>         .id_table       = etm_ids,
>  };
> -
> -module_amba_driver(etm_driver);
> -
> -MODULE_LICENSE("GPL v2");
> -MODULE_DESCRIPTION("CoreSight Program Flow Trace driver");
> +builtin_amba_driver(etm_driver);
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> index d6a92c6d3a66..040327ac6e1f 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> @@ -15,7 +15,6 @@
>  #include <linux/init.h>
>  #include <linux/types.h>
>  #include <linux/device.h>
> -#include <linux/module.h>
>  #include <linux/io.h>
>  #include <linux/err.h>
>  #include <linux/fs.h>
> @@ -2714,5 +2713,4 @@ static struct amba_driver etm4x_driver = {
>         .probe          = etm4_probe,
>         .id_table       = etm4_ids,
>  };
> -
> -module_amba_driver(etm4x_driver);
> +builtin_amba_driver(etm4x_driver);
> diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c
> index 25e8ea140a09..2c1850c8dbe7 100644
> --- a/drivers/hwtracing/coresight/coresight-funnel.c
> +++ b/drivers/hwtracing/coresight/coresight-funnel.c
> @@ -1,5 +1,7 @@
>  /* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
>   *
> + * Description: CoreSight Funnel driver
> + *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License version 2 and
>   * only version 2 as published by the Free Software Foundation.
> @@ -11,7 +13,6 @@
>   */
>
>  #include <linux/kernel.h>
> -#include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/types.h>
>  #include <linux/device.h>
> @@ -270,8 +271,4 @@ static struct amba_driver funnel_driver = {
>         .probe          = funnel_probe,
>         .id_table       = funnel_ids,
>  };
> -
> -module_amba_driver(funnel_driver);
> -
> -MODULE_LICENSE("GPL v2");
> -MODULE_DESCRIPTION("CoreSight Funnel driver");
> +builtin_amba_driver(funnel_driver);
> diff --git a/drivers/hwtracing/coresight/coresight-replicator-qcom.c b/drivers/hwtracing/coresight/coresight-replicator-qcom.c
> index 444815179460..6344dcf19639 100644
> --- a/drivers/hwtracing/coresight/coresight-replicator-qcom.c
> +++ b/drivers/hwtracing/coresight/coresight-replicator-qcom.c
> @@ -15,7 +15,6 @@
>  #include <linux/clk.h>
>  #include <linux/coresight.h>
>  #include <linux/device.h>
> -#include <linux/module.h>
>  #include <linux/err.h>
>  #include <linux/init.h>
>  #include <linux/io.h>
> @@ -202,5 +201,4 @@ static struct amba_driver replicator_driver = {
>         .probe          = replicator_probe,
>         .id_table       = replicator_ids,
>  };
> -
> -module_amba_driver(replicator_driver);
> +builtin_amba_driver(replicator_driver);
> diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
> index b77d700a3f0e..d31da8004d2e 100644
> --- a/drivers/hwtracing/coresight/coresight-replicator.c
> +++ b/drivers/hwtracing/coresight/coresight-replicator.c
> @@ -1,5 +1,7 @@
>  /* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
>   *
> + * Description: CoreSight Replicator driver
> + *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License version 2 and
>   * only version 2 as published by the Free Software Foundation.
> @@ -11,7 +13,6 @@
>   */
>
>  #include <linux/kernel.h>
> -#include <linux/module.h>
>  #include <linux/device.h>
>  #include <linux/platform_device.h>
>  #include <linux/io.h>
> @@ -168,8 +169,4 @@ static struct platform_driver replicator_driver = {
>                 .suppress_bind_attrs = true,
>         },
>  };
> -
>  builtin_platform_driver(replicator_driver);
> -
> -MODULE_LICENSE("GPL v2");
> -MODULE_DESCRIPTION("CoreSight Replicator driver");
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
> index c4fa70ed14ce..021cbb5d9eb3 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc.c
> @@ -1,5 +1,7 @@
>  /* Copyright (c) 2012, The Linux Foundation. All rights reserved.
>   *
> + * Description: CoreSight Trace Memory Controller driver
> + *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License version 2 and
>   * only version 2 as published by the Free Software Foundation.
> @@ -11,7 +13,6 @@
>   */
>
>  #include <linux/kernel.h>
> -#include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/types.h>
>  #include <linux/device.h>
> @@ -787,8 +788,4 @@ static struct amba_driver tmc_driver = {
>         .probe          = tmc_probe,
>         .id_table       = tmc_ids,
>  };
> -
> -module_amba_driver(tmc_driver);
> -
> -MODULE_LICENSE("GPL v2");
> -MODULE_DESCRIPTION("CoreSight Trace Memory Controller driver");
> +builtin_amba_driver(tmc_driver);
> diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
> index ca50e73d9df7..e24bfb04f168 100644
> --- a/drivers/hwtracing/coresight/coresight-tpiu.c
> +++ b/drivers/hwtracing/coresight/coresight-tpiu.c
> @@ -1,5 +1,7 @@
>  /* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
>   *
> + * Description: CoreSight Trace Port Interface Unit driver
> + *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License version 2 and
>   * only version 2 as published by the Free Software Foundation.
> @@ -11,7 +13,6 @@
>   */
>
>  #include <linux/kernel.h>
> -#include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/device.h>
>  #include <linux/io.h>
> @@ -220,8 +221,4 @@ static struct amba_driver tpiu_driver = {
>         .probe          = tpiu_probe,
>         .id_table       = tpiu_ids,
>  };
> -
> -module_amba_driver(tpiu_driver);
> -
> -MODULE_LICENSE("GPL v2");
> -MODULE_DESCRIPTION("CoreSight Trace Port Interface Unit driver");
> +builtin_amba_driver(tpiu_driver);
> diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
> index 7e6e9ff27dd1..4b33f1938a58 100644
> --- a/drivers/hwtracing/coresight/coresight.c
> +++ b/drivers/hwtracing/coresight/coresight.c
> @@ -11,7 +11,6 @@
>   */
>
>  #include <linux/kernel.h>
> -#include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/types.h>
>  #include <linux/device.h>
> @@ -766,5 +765,3 @@ void coresight_unregister(struct coresight_device *csdev)
>         device_unregister(&csdev->dev);
>  }
>  EXPORT_SYMBOL_GPL(coresight_unregister);
> -
> -MODULE_LICENSE("GPL v2");
> diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
> index 3cc57c1e3b5d..b68da1888fd5 100644
> --- a/drivers/hwtracing/coresight/of_coresight.c
> +++ b/drivers/hwtracing/coresight/of_coresight.c
> @@ -10,7 +10,6 @@
>   * GNU General Public License for more details.
>   */
>
> -#include <linux/module.h>
>  #include <linux/types.h>
>  #include <linux/err.h>
>  #include <linux/slab.h>
> diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
> index 9006c4e75cf7..3d8dcdd1aeae 100644
> --- a/include/linux/amba/bus.h
> +++ b/include/linux/amba/bus.h
> @@ -163,4 +163,13 @@ struct amba_device name##_device = {                               \
>  #define module_amba_driver(__amba_drv) \
>         module_driver(__amba_drv, amba_driver_register, amba_driver_unregister)
>
> +/*
> + * builtin_amba_driver() - Helper macro for drivers that don't do anything
> + * special in driver initcall.  This eliminates a lot of boilerplate.  Each
> + * driver may only use this macro once, and calling it replaces the instance
> + * device_initcall().
> + */
> +#define builtin_amba_driver(__amba_drv) \
> +       builtin_driver(__amba_drv, amba_driver_register)
> +
>  #endif
> --
> 2.6.1
>

I'm good with this patch on the CS side but Russell maintains the amba
subsystem and as such needs to agree with the new macro.  Russell, I
offer to take this through my tree if you're fine with the changes.

Thanks,
Mathieu


From mathieu.poirier at linaro.org  Mon Feb 15 17:32:00 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Mon, 15 Feb 2016 18:32:00 -0700
Subject: [PATCH] coresight: etb: Remove simple announcement message
In-Reply-To: <20160212215428.GB18988@sirena.org.uk>
References: <1455195004-30214-1-git-send-email-broonie@kernel.org>
 <CANLsYkwVn4FgBST-0MeOa38qCkH78-z32_CXewcCF78CnvbxeQ@mail.gmail.com>
 <20160212215428.GB18988@sirena.org.uk>
Message-ID: <CANLsYkxergpAc2Qu8Uq9JF0s9_xtSWhBfCZ0-fH69nVFjEY9Cg@mail.gmail.com>

On 12 February 2016 at 14:54, Mark Brown <broonie at kernel.org> wrote:
> On Fri, Feb 12, 2016 at 01:44:31PM -0700, Mathieu Poirier wrote:
>> On 11 February 2016 at 05:50, Mark Brown <broonie at kernel.org> wrote:
>
>> > -       dev_info(dev, "ETB initialized\n");
>> >         return 0;
>
>> Didn't we touch base on that topic before?  I'm not against moving
>
> We did and you said that there was a patch pending which would change it
> to print something useful but the patch still applies so I guess that
> didn't happen.
>
>> forward with this but it has to be all or nothing - whether we remove
>> all the CS boot log message or they all stay.  Otherwise people could
>> mistakenly come to the conclusion that some of the CS components did
>> not boot properly.
>
>> ETB, funnel and TMCs don't output any useful HW related information
>> but tracers (ETMv3, PTM and ETMv4) actually do.
>
> I think people are familiar enough with the general policy on this stuff
> to be able to cope with this, it's certainly not something that's ever
> come up with ASoC where we do have a similar multi-device structure.

Ok - please send me another patch that removes the boot log messages
for  the TMC, funnel and TPIU drivers.  That way only the tracers
(ETMv3/4) get to keep their boot logs.

Thanks,
Mathieu

>
>> People concerned about boot time will definitely set their loglevel
>> accordingly on the kernel cmd line.  Otherwise we are likely talking
>> about developers interested in knowing what happened when their kernel
>> booted.
>
> That applies equally to all drivers so from that point of view we should
> be doing something in the driver core - there is actually some logging
> there that can be enabled, though it's not that widely used.


From viresh.kumar at linaro.org  Mon Feb 15 17:36:28 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Tue, 16 Feb 2016 07:06:28 +0530
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor:
 Replace timers with utilization ...'
In-Reply-To: <6826860.yxabWEoz5T@vostro.rjw.lan>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
 <20160216011335.GI6334@vireshk-i7>
 <6826860.yxabWEoz5T@vostro.rjw.lan>
Message-ID: <20160216013628.GK6334@vireshk-i7>

On 16-02-16, 02:27, Rafael J. Wysocki wrote:
> Yes, that's what we should be doing, but it seemed to me that we didn't.
> 
> Or maybe the trace just contained the last one, because that's when the
> crash happened.

Ofcourse, it wouldn't mention the function calls that have already
finished :)

-- 
viresh


From linux at roeck-us.net  Mon Feb 15 17:38:06 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 15 Feb 2016 17:38:06 -0800
Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace
 timers with utilization ...'
In-Reply-To: <20160215213606.GD19432@atomide.com>
References: <20160215170527.GA24453@roeck-us.net>
 <CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com>
 <20160215190116.GX19432@atomide.com> <56C229A5.8020901@roeck-us.net>
 <20160215195839.GA19432@atomide.com>
 <CAJZ5v0hzVB0+H4nuCun3mmrES3UQ3+Rs1uz5YGu5sv4G3XU+nQ@mail.gmail.com>
 <20160215213606.GD19432@atomide.com>
Message-ID: <56C27D7E.4060603@roeck-us.net>

On 02/15/2016 01:36 PM, Tony Lindgren wrote:
> * Rafael J. Wysocki <rafael at kernel.org> [160215 12:39]:
>> On Mon, Feb 15, 2016 at 8:58 PM, Tony Lindgren <tony at atomide.com> wrote:
>>> * Guenter Roeck <linux at roeck-us.net> [160215 11:41]:
>>>> On 02/15/2016 11:01 AM, Tony Lindgren wrote:
>>>>>
>>>>> https://kernelci.org/boot/all/job/next/kernel/next-20160215/
>>>>>
>>>>> The SMP ones seem to fail with some regulator issues?
>>>>>
>>>>
>>>> There is another problem, introduced with 6a0712f6f199e ("PM / OPP: Add
>>>> dev_pm_opp_set_rate()"). The kernelci boot log for next-20160212:omap3-overo-tobi
>>>> and others experience that problem.
>>>>
>>>> Essentially, the code now assumes that a CPU clock always has a voltage
>>>> regulator attached to it, which is not correct. I sent out a patch to fix
>>>> that problem a minute ago.
>>>
>>> Yes that fixed it thanks.
>>
>> Can you please also check if this alternative fix from Viresh works:
>>
>> https://patchwork.kernel.org/patch/8316611/
>
> Yes that one too seems to fix the issue on SMP systems for
> me:
>
> Tested-by: Tony Lindgren <tony at atomide.com>
>

Same here.

Tested-by: Guenter Roeck <linux at roeck-us.net>

Guenter



From linux at roeck-us.net  Mon Feb 15 17:40:27 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 15 Feb 2016 17:40:27 -0800
Subject: [PATCH 1/2] firmware: arm_scpi: add support for 64-bit sensor
 values
In-Reply-To: <1455028377-12728-1-git-send-email-sudeep.holla@arm.com>
References: <1455028377-12728-1-git-send-email-sudeep.holla@arm.com>
Message-ID: <56C27E0B.5070600@roeck-us.net>

On 02/09/2016 06:32 AM, Sudeep Holla wrote:
> SCPI specification version 1.1 extended the sensor from 32-bit to 64-bit
> values in order to accommodate new sensor class with 64-bit requirements
>
> Since the SCPI driver sets the higher 32-bit for older protocol version
> to zeros, there's no need to explicitly check the SCPI protocol version
> and the backward compatibility is maintainted.
>
> Cc: Punit Agrawal <punit.agrawal at arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>

Acked-by: Guenter Roeck <linux at roeck-us.net>

> ---
>   drivers/firmware/arm_scpi.c   | 8 +++++---
>   drivers/hwmon/scpi-hwmon.c    | 6 +++---
>   include/linux/scpi_protocol.h | 2 +-
>   3 files changed, 9 insertions(+), 7 deletions(-)
>
> Hi Guenter,
>
> Since I have couple of other fixes for SCPI driver, if you can provide
> your ACKs to this couple of patches after your review, I can take all of
> them together via ARM-SoC if that's fine with you.
>
> Regards,
> Sudeep
>
> diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
> index c32ac6e61ba2..7e3e595c9f30 100644
> --- a/drivers/firmware/arm_scpi.c
> +++ b/drivers/firmware/arm_scpi.c
> @@ -231,7 +231,8 @@ struct _scpi_sensor_info {
>   };
>
>   struct sensor_value {
> -	__le32 val;
> +	__le32 lo_val;
> +	__le32 hi_val;
>   } __packed;
>
>   static struct scpi_drvinfo *scpi_info;
> @@ -525,7 +526,7 @@ static int scpi_sensor_get_info(u16 sensor_id, struct scpi_sensor_info *info)
>   	return ret;
>   }
>
> -int scpi_sensor_get_value(u16 sensor, u32 *val)
> +int scpi_sensor_get_value(u16 sensor, u64 *val)
>   {
>   	__le16 id = cpu_to_le16(sensor);
>   	struct sensor_value buf;
> @@ -534,7 +535,8 @@ int scpi_sensor_get_value(u16 sensor, u32 *val)
>   	ret = scpi_send_message(SCPI_CMD_SENSOR_VALUE, &id, sizeof(id),
>   				&buf, sizeof(buf));
>   	if (!ret)
> -		*val = le32_to_cpu(buf.val);
> +		*val = (u64)le32_to_cpu(buf.hi_val) << 32 |
> +			le32_to_cpu(buf.lo_val);
>
>   	return ret;
>   }
> diff --git a/drivers/hwmon/scpi-hwmon.c b/drivers/hwmon/scpi-hwmon.c
> index 7e20567bc369..7101b14b5137 100644
> --- a/drivers/hwmon/scpi-hwmon.c
> +++ b/drivers/hwmon/scpi-hwmon.c
> @@ -52,7 +52,7 @@ static int scpi_read_temp(void *dev, int *temp)
>   	struct scpi_sensors *scpi_sensors = zone->scpi_sensors;
>   	struct scpi_ops *scpi_ops = scpi_sensors->scpi_ops;
>   	struct sensor_data *sensor = &scpi_sensors->data[zone->sensor_id];
> -	u32 value;
> +	u64 value;
>   	int ret;
>
>   	ret = scpi_ops->sensor_get_value(sensor->info.sensor_id, &value);
> @@ -70,7 +70,7 @@ scpi_show_sensor(struct device *dev, struct device_attribute *attr, char *buf)
>   	struct scpi_sensors *scpi_sensors = dev_get_drvdata(dev);
>   	struct scpi_ops *scpi_ops = scpi_sensors->scpi_ops;
>   	struct sensor_data *sensor;
> -	u32 value;
> +	u64 value;
>   	int ret;
>
>   	sensor = container_of(attr, struct sensor_data, dev_attr_input);
> @@ -79,7 +79,7 @@ scpi_show_sensor(struct device *dev, struct device_attribute *attr, char *buf)
>   	if (ret)
>   		return ret;
>
> -	return sprintf(buf, "%u\n", value);
> +	return sprintf(buf, "%llu\n", value);
>   }
>
>   static ssize_t
> diff --git a/include/linux/scpi_protocol.h b/include/linux/scpi_protocol.h
> index 72ce932c69b2..ecd248d46281 100644
> --- a/include/linux/scpi_protocol.h
> +++ b/include/linux/scpi_protocol.h
> @@ -68,7 +68,7 @@ struct scpi_ops {
>   	struct scpi_dvfs_info *(*dvfs_get_info)(u8);
>   	int (*sensor_get_capability)(u16 *sensors);
>   	int (*sensor_get_info)(u16 sensor_id, struct scpi_sensor_info *);
> -	int (*sensor_get_value)(u16, u32 *);
> +	int (*sensor_get_value)(u16, u64 *);
>   };
>
>   #if IS_REACHABLE(CONFIG_ARM_SCPI_PROTOCOL)
>



From linux at roeck-us.net  Mon Feb 15 17:41:00 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 15 Feb 2016 17:41:00 -0800
Subject: [PATCH 2/2] hwmon: (scpi) add energy meter support
In-Reply-To: <1455028377-12728-2-git-send-email-sudeep.holla@arm.com>
References: <1455028377-12728-1-git-send-email-sudeep.holla@arm.com>
 <1455028377-12728-2-git-send-email-sudeep.holla@arm.com>
Message-ID: <56C27E2C.5030506@roeck-us.net>

On 02/09/2016 06:32 AM, Sudeep Holla wrote:
> SCPI specification v1.1 adds support for energy sensors. This patch
> adds support for the same.
>
> Cc: Punit Agrawal <punit.agrawal at arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>

Acked-by: Guenter Roeck <linux at roeck-us.net>

> ---
>   drivers/hwmon/scpi-hwmon.c    | 8 ++++++++
>   include/linux/scpi_protocol.h | 1 +
>   2 files changed, 9 insertions(+)
>
> diff --git a/drivers/hwmon/scpi-hwmon.c b/drivers/hwmon/scpi-hwmon.c
> index 7101b14b5137..912b449c8303 100644
> --- a/drivers/hwmon/scpi-hwmon.c
> +++ b/drivers/hwmon/scpi-hwmon.c
> @@ -114,6 +114,7 @@ static int scpi_hwmon_probe(struct platform_device *pdev)
>   {
>   	u16 nr_sensors, i;
>   	int num_temp = 0, num_volt = 0, num_current = 0, num_power = 0;
> +	int num_energy = 0;
>   	struct scpi_ops *scpi_ops;
>   	struct device *hwdev, *dev = &pdev->dev;
>   	struct scpi_sensors *scpi_sensors;
> @@ -182,6 +183,13 @@ static int scpi_hwmon_probe(struct platform_device *pdev)
>   				 "power%d_label", num_power + 1);
>   			num_power++;
>   			break;
> +		case ENERGY:
> +			snprintf(sensor->input, sizeof(sensor->input),
> +				 "energy%d_input", num_energy + 1);
> +			snprintf(sensor->label, sizeof(sensor->input),
> +				 "energy%d_label", num_energy + 1);
> +			num_energy++;
> +			break;
>   		default:
>   			continue;
>   		}
> diff --git a/include/linux/scpi_protocol.h b/include/linux/scpi_protocol.h
> index ecd248d46281..35de50a65665 100644
> --- a/include/linux/scpi_protocol.h
> +++ b/include/linux/scpi_protocol.h
> @@ -33,6 +33,7 @@ enum scpi_sensor_class {
>   	VOLTAGE,
>   	CURRENT,
>   	POWER,
> +	ENERGY,
>   };
>
>   struct scpi_sensor_info {
>



From linux at roeck-us.net  Mon Feb 15 17:48:26 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 15 Feb 2016 17:48:26 -0800
Subject: [PATCH v2 1/3] hwmon: Define binding for the nsa320-hwmon driver
In-Reply-To: <1455578705-10531-2-git-send-email-linux@baker-net.org.uk>
References: <1455578705-10531-1-git-send-email-linux@baker-net.org.uk>
 <1455578705-10531-2-git-send-email-linux@baker-net.org.uk>
Message-ID: <56C27FEA.1090806@roeck-us.net>

On 02/15/2016 03:25 PM, Adam Baker wrote:
> Define a binding for the hardware monitoring chip present in the Zyxel
> NSA-320 and some of the other Zyxel NAS devices.
>
> Signed-off-by: Adam Baker <linux at baker-net.org.uk>

Rob sent you an Ack for this patch. Since you did not change the patch
since v1, I would expect to see it here (instead of having to look it up).

Thanks,
Guenter

> ---
>   .../devicetree/bindings/hwmon/nsa320-mcu.txt        | 21 +++++++++++++++++++++
>   1 file changed, 21 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt b/Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt
> new file mode 100644
> index 0000000..7b346d4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt
> @@ -0,0 +1,21 @@
> +Bindings for the fan / temperature monitor microcontroller used on
> +the Zyxel NSA 320 and several subsequent models.
> +
> +Required properties:
> +- compatible	: "zyxel,nsa320-mcu"
> +- data-gpios	: The GPIO pin connected to the data line on the MCU
> +- clk-gpios	: The GPIO pin connected to the clock line on the MCU
> +- act-gpios	: The GPIO pin connected to the active line on the MCU
> +
> +Example:
> +
> +	hwmon {
> +		compatible = "zyxel,nsa320-mcu";
> +		pinctrl-0 = <&pmx_mcu_data &pmx_mcu_clk &pmx_mcu_act>;
> +		pinctrl-names = "default";
> +
> +		data-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
> +		clk-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
> +		act-gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
> +	};
> +
>



From arnd at arndb.de  Mon Feb 15 12:16:30 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Feb 2016 21:16:30 +0100
Subject: [PATCH 1/4] gpio: remove broken irq_to_gpio() interface
In-Reply-To: <56C1F645.1070405@metafoo.de>
References: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <1455551208-2825510-2-git-send-email-arnd@arndb.de>
 <56C1F645.1070405@metafoo.de>
Message-ID: <4277616.myYDBWrFcU@wuerfel>

On Monday 15 February 2016 17:01:09 Lars-Peter Clausen wrote:
> On 02/15/2016 04:46 PM, Arnd Bergmann wrote:
> > +static inline __deprecated int irq_to_gpio(unsigned int irq)
> > +{
> > +     /* this has clearly not worked for a long time */
> > +     return -EINVAL;
> > +}
> > +
> >  #define IRQ_TO_BIT(irq) BIT(irq_to_gpio(irq) & 0x1f)
> 
> The issue seems to be a fallout from commit 832f5dacfa0b ("MIPS: Remove all
> the uses of custom gpio.h").
> 
> The irq_to_gpio() should be replaced with "(irq - JZ4740_IRQ_GPIO(0))".
> 
> 

Ah, that explain it, so it has not been broken for that long.

	Arnd


From tiffany.lin at mediatek.com  Mon Feb 15 18:09:28 2016
From: tiffany.lin at mediatek.com (tiffany lin)
Date: Tue, 16 Feb 2016 10:09:28 +0800
Subject: [PATCH v4 4/8] dt-bindings: Add a binding for Mediatek Video
 Encoder
In-Reply-To: <CAGS+omAkM97TOnJX-ahEMeN8zO1R2RO43LWqeFFRDuj7gM5CzA@mail.gmail.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <CAGS+omDQW+yqhixCWPfQb9eaHeufgiEDscrvXGwBTc05+eDGCQ@mail.gmail.com>
 <CAGS+omAkM97TOnJX-ahEMeN8zO1R2RO43LWqeFFRDuj7gM5CzA@mail.gmail.com>
Message-ID: <1455588568.19396.51.camel@mtksdaap41>

Hi Daniel,

On Mon, 2016-02-15 at 18:42 +0800, Daniel Kurtz wrote:
> On Tue, Feb 9, 2016 at 7:29 PM, Daniel Kurtz <djkurtz at chromium.org> wrote:
> > Hi Tiffany,
> >
> > On Thu, Feb 4, 2016 at 7:34 PM, Tiffany Lin <tiffany.lin at mediatek.com> wrote:
> >> Add a DT binding documentation of Video Encoder for the
> >> MT8173 SoC from Mediatek.
> >>
> >> Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
> >> ---
> >>  .../devicetree/bindings/media/mediatek-vcodec.txt  |   59 ++++++++++++++++++++
> >>  1 file changed, 59 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> >> new file mode 100644
> >> index 0000000..572bfdd
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> >> @@ -0,0 +1,59 @@
> >> +Mediatek Video Codec
> >> +
> >> +Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
> >> +supports high resolution encoding functionalities.
> >> +
> >> +Required properties:
> >> +- compatible : "mediatek,mt8173-vcodec-enc" for encoder
> >> +- reg : Physical base address of the video codec registers and length of
> >> +  memory mapped region.
> >> +- interrupts : interrupt number to the cpu.
> >> +- mediatek,larb : must contain the local arbiters in the current Socs.
> >> +- clocks : list of clock specifiers, corresponding to entries in
> >> +  the clock-names property.
> >> +- clock-names: encoder must contain "vencpll_d2", "venc_sel", "univpll1_d2",
> >> +  "venc_lt_sel".
> >> +- iommus : should point to the respective IOMMU block with master port as
> >> +  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> >> +  for details.
> >> +- mediatek,vpu : the node of video processor unit
> >> +
> >> +Example:
> >> +vcodec_enc: vcodec at 0x18002000 {
> >> +    compatible = "mediatek,mt8173-vcodec-enc";
> >> +    reg = <0 0x18002000 0 0x1000>,    /*VENC_SYS*/
> >> +          <0 0x19002000 0 0x1000>;    /*VENC_LT_SYS*/
> >
> > This really looks like two encoder devices combined into a single
> > device tree node.
> > There are two register sets, two irqs, two sets of iommus, and two
> > sets of clocks.
> >
> > If possible, please split this node into two, one for each encoder.
> 
> I chatted offline with Mediatek.  They explained that there really is
> just one encoder hardware, that happens to support multiple formats.
> The encoder cannot encode with both formats at the same time.  The
> Mediatek HW designers added a new format to an existing encoder by
> adding a second interface (register set, irq, iommus, clocks) without
> modifying the original interface.  However in the hardware itself
> there is really just one encoder device.
> 
> So, although this node looks like it is for two encoder devices (one
> for each format), really there is just one device that supports each
> format through its large interface.
> 
> So, I'm fine with this being a single device node.
> 
> >> +    interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>,
> >> +           <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>;
> >> +    mediatek,larb = <&larb3>,
> >> +                   <&larb5>;
> >> +    iommus = <&iommu M4U_PORT_VENC_RCPU>,
> >> +             <&iommu M4U_PORT_VENC_REC>,
> >> +             <&iommu M4U_PORT_VENC_BSDMA>,
> >> +             <&iommu M4U_PORT_VENC_SV_COMV>,
> >> +             <&iommu M4U_PORT_VENC_RD_COMV>,
> >> +             <&iommu M4U_PORT_VENC_CUR_LUMA>,
> >> +             <&iommu M4U_PORT_VENC_CUR_CHROMA>,
> >> +             <&iommu M4U_PORT_VENC_REF_LUMA>,
> >> +             <&iommu M4U_PORT_VENC_REF_CHROMA>,
> >> +             <&iommu M4U_PORT_VENC_NBM_RDMA>,
> >> +             <&iommu M4U_PORT_VENC_NBM_WDMA>,
> >> +             <&iommu M4U_PORT_VENC_RCPU_SET2>,
> >> +             <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
> >> +             <&iommu M4U_PORT_VENC_BSDMA_SET2>,
> >> +             <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
> >> +             <&iommu M4U_PORT_VENC_RD_COMA_SET2>,
> >> +             <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
> >> +             <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
> >> +             <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
> >> +             <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
> >> +    mediatek,vpu = <&vpu>;
> >> +    clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
> >> +             <&topckgen CLK_TOP_VENC_SEL>,
> >> +             <&topckgen CLK_TOP_UNIVPLL1_D2>,
> >> +             <&topckgen CLK_TOP_VENC_LT_SEL>;
> >> +    clock-names = "vencpll_d2",
> >> +                  "venc_sel",
> >> +                  "univpll1_d2",
> >> +                  "venc_lt_sel";
> >
> > The names of these clocks should be from the perspective of the
> > encoder, not the clock provider.
> 
> I still think these clock names should be updated, however.
> 
Got it. We will fix this in next version.

> -Dan




From linux at roeck-us.net  Mon Feb 15 18:13:03 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Mon, 15 Feb 2016 18:13:03 -0800
Subject: [PATCH v2 2/3] hwmon: Create an NSA320 hardware monitoring driver
In-Reply-To: <1455578705-10531-3-git-send-email-linux@baker-net.org.uk>
References: <1455578705-10531-1-git-send-email-linux@baker-net.org.uk>
 <1455578705-10531-3-git-send-email-linux@baker-net.org.uk>
Message-ID: <56C285AF.9020207@roeck-us.net>

On 02/15/2016 03:25 PM, Adam Baker wrote:
> Create a driver to support the hardware monitoring chip present in
> the Zyxel NSA320 and some of the other Zyxel NAS devices.
>
> The driver reads fan speed and temperature from a suitably
> pre-programmed MCU on the device.
>
> Signed-off-by: Adam Baker <linux at baker-net.org.uk>

Couple of additional comments below.

> ---

Please provide a change log here for the next version (or a comment indicating that
there is no change from the previous version). "Added Ack by ..." is a useful
change log.

>   drivers/hwmon/Kconfig        |  15 +++
>   drivers/hwmon/Makefile       |   1 +
>   drivers/hwmon/nsa320-hwmon.c | 215 +++++++++++++++++++++++++++++++++++++++++++

Please also provide Documentation/hwmon/nsa320-hwmon.

>   3 files changed, 231 insertions(+)
>   create mode 100644 drivers/hwmon/nsa320-hwmon.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 80a73bf..08fd7f5 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1186,6 +1186,21 @@ config SENSORS_NCT7904
>   	  This driver can also be built as a module.  If so, the module
>   	  will be called nct7904.
>
> +config SENSORS_NSA320
> +	tristate "ZyXEL NSA320 and compatible fan speed and temperature sensors"
> +	depends on GPIOLIB && OF
> +	depends on MACH_KIRKWOOD || COMPILE_TEST
> +	help
> +	  If you say yes here you get support for hardware monitoring
> +	  for the ZyXEL NSA320 Media Server and other compatible devices
> +	  (probably the NSA325 and some NSA310 variants).
> +
> +	  The sensor data is taken from a Holtek HT46R065 microcontroller
> +	  connected to GPIO lines.
> +
> +	  This driver can also be built as a module. If so, the module
> +	  will be called nsa320-hwmon.
> +
>   config SENSORS_PCF8591
>   	tristate "Philips PCF8591 ADC/DAC"
>   	depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 12a3239..e555d6d 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -125,6 +125,7 @@ obj-$(CONFIG_SENSORS_NCT6775)	+= nct6775.o
>   obj-$(CONFIG_SENSORS_NCT7802)	+= nct7802.o
>   obj-$(CONFIG_SENSORS_NCT7904)	+= nct7904.o
>   obj-$(CONFIG_SENSORS_NTC_THERMISTOR)	+= ntc_thermistor.o
> +obj-$(CONFIG_SENSORS_NSA320)	+= nsa320-hwmon.o

NSA ... NTC

>   obj-$(CONFIG_SENSORS_PC87360)	+= pc87360.o
>   obj-$(CONFIG_SENSORS_PC87427)	+= pc87427.o
>   obj-$(CONFIG_SENSORS_PCF8591)	+= pcf8591.o
> diff --git a/drivers/hwmon/nsa320-hwmon.c b/drivers/hwmon/nsa320-hwmon.c
> new file mode 100644
> index 0000000..f4bfa65
> --- /dev/null
> +++ b/drivers/hwmon/nsa320-hwmon.c
> @@ -0,0 +1,215 @@
> +/*
> + * drivers/hwmon/nsa320-hwmon.c
> + *
> + * ZyXEL NSA320 Media Servers
> + * hardware monitoring
> + *
> + * Copyright (C) 2016 Adam Baker <linux at baker-net.org.uk>
> + * based on a board file driver
> + * Copyright (C) 2012 Peter Schildmann <linux at schildmann.info>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License v2 as published by the
> + * Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/jiffies.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +
> +#define MAGIC_NUMBER 0x55
> +
> +/*
> + * The Zyxel hwmon MCU is a Holtek HT46R065 that is factory programmed
> + * to perform temperature and fan speed monitoring. It is read by taking
> + * the active pin low. The 32 bit output word is then clocked onto the
> + * data line. The MSB of the data word is a magic nuber to indicate it
> + * has been read correctly, the next byte is the fan speed (in hundreds
> + * of RPM) and the last two bytes are the temperature (in tenths of a
> + * degree)
> + */
> +
> +struct nsa320_hwmon {
> +	struct mutex		update_lock;	/* lock GPIO operations */
> +	unsigned long		last_updated;	/* jiffies */
> +	u32			mcu_data;
> +	struct gpio_desc	*act;
> +	struct gpio_desc	*clk;
> +	struct gpio_desc	*data;
> +};
> +
> +enum nsa320_inputs {
> +	NSA3XX_TEMP = 0,
> +	NSA3XX_FAN = 1,
> +};
> +
> +static const char * const nsa320_input_names[] = {
> +	[NSA3XX_FAN] = "Chassis Fan",
> +	[NSA3XX_TEMP] = "System Temperature",

Swap lines, please.

> +};
> +
> +/* Although this protocol looks similar to SPI the long delay

Please use standard multi-line comments.

> + * between the active (aka chip select) signal and the shorter
> + * delay between clock pulses are needed for reliable operation.
> + * The delays provided are taken from the manufacturer kernel,
> + * testing suggest they probably incorporate a reasonable safety
> + * margin. (The single device tested became unreliable if the
> + * delay was reduced to 1/10th of this value.)
> + */
> +static int nsa320_hwmon_update(struct device *dev)
> +{
> +	u32 mcu_data;
> +	u32 mask;
> +	struct nsa320_hwmon *hwmon = dev_get_drvdata(dev);
> +
> +	mutex_lock(&hwmon->update_lock);
> +
> +	mcu_data = hwmon->mcu_data;
> +
> +	if (time_after(jiffies, hwmon->last_updated + HZ) || mcu_data == 0) {
> +		gpiod_set_value(hwmon->act, 1);
> +		msleep(100);
> +
> +		for (mask = BIT(31); mask; mask >>= 1) {
> +			gpiod_set_value(hwmon->clk, 0);
> +			usleep_range(100, 200);
> +			gpiod_set_value(hwmon->clk, 1);
> +			usleep_range(100, 200);
> +			if (gpiod_get_value(hwmon->data))
> +				mcu_data |= mask;

This is problematic. The code only sets additional bits in mcu_data
and never removes any (since mcu_data starts off with hwmon->mcu_data).

> +		}
> +
> +		gpiod_set_value(hwmon->act, 0);
> +		dev_dbg(dev, "Read raw MCU data %08x\n", mcu_data);
> +
> +		if ((mcu_data >> 24) != MAGIC_NUMBER) {
> +			dev_dbg(dev, "Read invalid MCU data %08x\n", mcu_data);
> +			return -EIO;
> +		}
> +
> +		hwmon->mcu_data = mcu_data;
> +		hwmon->last_updated = jiffies;
> +	}
> +
> +	mutex_unlock(&hwmon->update_lock);
> +
> +	return 0;
> +}
> +
> +static ssize_t show_label(struct device *dev,
> +			  struct device_attribute *attr, char *buf)
> +{
> +	int channel = to_sensor_dev_attr(attr)->index;
> +
> +	return sprintf(buf, "%s\n", nsa320_input_names[channel]);
> +}
> +
> +static ssize_t show_value(struct device *dev,
> +			  struct device_attribute *attr, char *buf)
> +{
> +	int channel = to_sensor_dev_attr(attr)->index;
> +	struct nsa320_hwmon *hwmon = dev_get_drvdata(dev);
> +	unsigned long value = 0;

int should be sufficient, and it does not need to be initialized.

> +	int ret = nsa320_hwmon_update(dev);
> +
> +	if (ret)
> +		return ret;
> +
> +	switch (channel) {
> +	case NSA3XX_TEMP:
> +		value = (hwmon->mcu_data & 0xffff) * 100;
> +		break;
> +	case NSA3XX_FAN:
> +		value = ((hwmon->mcu_data & 0xff0000) >> 16) * 100;
> +		break;
> +	default:
> +		return -EINVAL;

Hmmm ... this would be an implementation error, and leaves the user
guessing where the error comes from. Better make the value 0 here,
and display a warning with a traceback.

This shows, though, why using a single function in cases like this
is not necessarily the best idea. Ultimately you end up having code
which has to deal with impossible cases. I'll leave it up to you,
but I think a better implementation would be to have two separate
show functions.

static ssize_t show_temp(struct device *dev,
			 struct device_attribute *attr, char *buf)
{
	struct nsa320_hwmon *hwmon = dev_get_drvdata(dev);
	int ret = nsa320_hwmon_update(dev);

	if (ret)
		return ret;

	return sprintf(buf, "%u\n", (hwmon->mcu_data & 0xffff) * 100);
}

static ssize_t show_fan(struct device *dev,
			struct device_attribute *attr, char *buf)
{
	struct nsa320_hwmon *hwmon = dev_get_drvdata(dev);
	int ret = nsa320_hwmon_update(dev);

	if (ret)
		return ret;

	return sprintf(buf, "%u\n", ((hwmon->mcu_data & 0xff0000) >> 16) * 100);
}

[ and you could use DEVICE_ATTR() for the show functions ]

You could simplify the functions further, by having nsa320_hwmon_update(dev)
either return an error or the value directly (a valid value will never be < 0).

static ssize_t show_temp(struct device *dev,
			 struct device_attribute *attr, char *buf)
{
	int mcu_data = nsa320_hwmon_update(dev);

	if (mcu_data < 0)
		return mcu_data;

	return sprintf(buf, "%d\n", (mcu_data & 0xffff) * 100);
}

> +	}
> +	return sprintf(buf, "%lu\n", value);
> +}
> +
> +static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, show_label, NULL, NSA3XX_TEMP);
> +static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_value, NULL, NSA3XX_TEMP);
> +static SENSOR_DEVICE_ATTR(fan1_label, S_IRUGO, show_label, NULL, NSA3XX_FAN);
> +static SENSOR_DEVICE_ATTR(fan1_input, S_IRUGO, show_value, NULL, NSA3XX_FAN);
> +
> +static struct attribute *nsa320_attrs[] = {
> +	&sensor_dev_attr_temp1_label.dev_attr.attr,
> +	&sensor_dev_attr_temp1_input.dev_attr.attr,
> +	&sensor_dev_attr_fan1_label.dev_attr.attr,
> +	&sensor_dev_attr_fan1_input.dev_attr.attr,
> +	NULL
> +};
> +
> +ATTRIBUTE_GROUPS(nsa320);
> +
> +static const struct of_device_id of_nsa320_hwmon_match[] = {
> +	{ .compatible = "zyxel,nsa320-mcu", },
> +	{ },
> +};
> +
> +static int nsa320_hwmon_probe(struct platform_device *pdev)
> +{
> +	struct nsa320_hwmon	*hwmon;
> +	struct device		*classdev;
> +
> +	hwmon = devm_kzalloc(&pdev->dev, sizeof(*hwmon), GFP_KERNEL);
> +	if (!hwmon)
> +		return -ENOMEM;
> +
> +	/* Look up the GPIO pins to use */
> +	hwmon->act = devm_gpiod_get(&pdev->dev, "act", GPIOD_OUT_LOW);
> +	if (IS_ERR(hwmon->act))
> +		return PTR_ERR(hwmon->act);
> +
> +	hwmon->clk = devm_gpiod_get(&pdev->dev, "clk", GPIOD_OUT_HIGH);
> +	if (IS_ERR(hwmon->clk))
> +		return PTR_ERR(hwmon->clk);
> +
> +	hwmon->data = devm_gpiod_get(&pdev->dev, "data", GPIOD_IN);
> +	if (IS_ERR(hwmon->data))
> +		return PTR_ERR(hwmon->data);
> +
> +	mutex_init(&hwmon->update_lock);
> +
> +	classdev = devm_hwmon_device_register_with_groups(&pdev->dev,
> +					"nsa320", hwmon, nsa320_groups);
> +
> +	return PTR_ERR_OR_ZERO(classdev);
> +
> +}
> +
> +/* All allocations use devres so remove() is not needed. */
> +
> +static struct platform_driver nsa320_hwmon_driver = {
> +	.probe = nsa320_hwmon_probe,
> +	.driver = {
> +		.name = "nsa320-hwmon",
> +		.owner = THIS_MODULE,
> +		.of_match_table = of_match_ptr(of_nsa320_hwmon_match),
> +	},
> +};
> +
> +module_platform_driver(nsa320_hwmon_driver);
> +
> +MODULE_DEVICE_TABLE(of, of_nsa320_hwmon_match);
> +MODULE_AUTHOR("Peter Schildmann <linux at schildmann.info>");
> +MODULE_AUTHOR("Adam Baker <linux at baker-net.org.uk>");
> +MODULE_DESCRIPTION("NSA3XX Hardware Monitoring");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:nsa320-hwmon");
>



From stefan at agner.ch  Mon Feb 15 18:14:13 2016
From: stefan at agner.ch (Stefan Agner)
Date: Mon, 15 Feb 2016 18:14:13 -0800
Subject: [PATCH 1/2] ARM: dts: vf-colibri: remove container node of regulators
Message-ID: <1455588854-6996-1-git-send-email-stefan@agner.ch>

Drop the fake simple-bus container 'regulators' and put the
regulators directly under the root node. This also makes the
artificial 'reg' properties superfluous.

Signed-off-by: Stefan Agner <stefan at agner.ch>
---
 arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 44 +++++++++++++------------------
 1 file changed, 18 insertions(+), 26 deletions(-)

diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
index b494673..09bf1f5 100644
--- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -50,32 +50,24 @@
 		clock-frequency = <16000000>;
 	};
 
-	regulators {
-		compatible = "simple-bus";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		sys_5v0_reg: regulator at 0 {
-			compatible = "regulator-fixed";
-			reg = <0>;
-			regulator-name = "5v0";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			regulator-always-on;
-		};
+	reg_sys_5v0: regulator-sys-5v0 {
+		compatible = "regulator-fixed";
+		regulator-name = "5v0";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
 
-		/* USBH_PEN */
-		usbh_vbus_reg: regulator at 1 {
-			compatible = "regulator-fixed";
-			pinctrl-names = "default";
-			pinctrl-0 = <&pinctrl_usbh1_reg>;
-			reg = <1>;
-			regulator-name = "usbh_vbus";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			gpio = <&gpio2 19 GPIO_ACTIVE_LOW>;
-			vin-supply = <&sys_5v0_reg>;
-		};
+	/* USBH_PEN */
+	reg_usbh_vbus: regulator-usbh-vbus {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbh1_reg>;
+		regulator-name = "usbh_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpio = <&gpio2 19 GPIO_ACTIVE_LOW>;
+		vin-supply = <&reg_sys_5v0>;
 	};
 };
 
@@ -145,7 +137,7 @@
 };
 
 &usbh1 {
-	vbus-supply = <&usbh_vbus_reg>;
+	vbus-supply = <&reg_usbh_vbus>;
 };
 
 &iomuxc {
-- 
2.7.1



From stefan at agner.ch  Mon Feb 15 18:14:14 2016
From: stefan at agner.ch (Stefan Agner)
Date: Mon, 15 Feb 2016 18:14:14 -0800
Subject: [PATCH 2/2] ARM: dts: vf-colibri: add supply regulators
In-Reply-To: <1455588854-6996-1-git-send-email-stefan@agner.ch>
References: <1455588854-6996-1-git-send-email-stefan@agner.ch>
Message-ID: <1455588854-6996-2-git-send-email-stefan@agner.ch>

Colibri modules need to be powered using the power pins 3V3 and
AVDD. Add fixed regulators which represent this power rails.
Potentially, those power rails could be switched on a carrier
board. A carrier board device tree could add a own regulator with
a GPIO, and reference that regulator in a vin-supply property of
those new module level system regulators.

Signed-off-by: Stefan Agner <stefan at agner.ch>
---
 arch/arm/boot/dts/vf-colibri.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi b/arch/arm/boot/dts/vf-colibri.dtsi
index ff6f58e..191506a 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -48,14 +48,31 @@
 		enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
 		status = "disabled";
 	};
+
+	reg_sys_3v3: regulator-sys-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
+	reg_sys_3v3_avdd: regulator-sys-3v3-avdd {
+		compatible = "regulator-fixed";
+		regulator-name = "AVDD";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
 };
 
 &adc0 {
 	status = "okay";
+	vref-supply = <&reg_sys_3v3_avdd>;
 };
 
 &adc1 {
 	status = "okay";
+	vref-supply = <&reg_sys_3v3_avdd>;
 };
 
 &can0 {
@@ -96,6 +113,7 @@
 
 &fec1 {
 	phy-mode = "rmii";
+	phy-supply = <&reg_sys_3v3>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_fec1>;
 };
-- 
2.7.1



From yamada.masahiro at socionext.com  Mon Feb 15 18:15:11 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Tue, 16 Feb 2016 11:15:11 +0900
Subject: [PATCH 9/9] ARM: dts: uniphier: add @{address} to EEPROM node
In-Reply-To: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
References: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1455588911-9827-10-git-send-email-yamada.masahiro@socionext.com>

Just for consistent coding style.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/uniphier-ref-daughter.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/uniphier-ref-daughter.dtsi b/arch/arm/boot/dts/uniphier-ref-daughter.dtsi
index 3d29d28..f7df088 100644
--- a/arch/arm/boot/dts/uniphier-ref-daughter.dtsi
+++ b/arch/arm/boot/dts/uniphier-ref-daughter.dtsi
@@ -43,7 +43,7 @@
  */
 
 &i2c0 {
-	eeprom {
+	eeprom at 50 {
 		compatible = "microchip,24lc128";
 		reg = <0x50>;
 	};
-- 
1.9.1



From yamada.masahiro at socionext.com  Mon Feb 15 18:15:05 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Tue, 16 Feb 2016 11:15:05 +0900
Subject: [PATCH 3/9] ARM: uniphier: add missing of_node_put()
In-Reply-To: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
References: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1455588911-9827-4-git-send-email-yamada.masahiro@socionext.com>

This node pointer is allocated by of_find_compatible_node() in this
function.  It should be put before exitting this function.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/mach-uniphier/platsmp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-uniphier/platsmp.c b/arch/arm/mach-uniphier/platsmp.c
index b53a8d9..fad568d 100644
--- a/arch/arm/mach-uniphier/platsmp.c
+++ b/arch/arm/mach-uniphier/platsmp.c
@@ -100,6 +100,7 @@ static int __init uniphier_smp_prepare_trampoline(unsigned int max_cpus)
 
 	np = of_find_compatible_node(NULL, NULL, "socionext,uniphier-smpctrl");
 	ret = of_address_to_resource(np, 0, &res);
+	of_node_put(np);
 	if (ret) {
 		pr_err("failed to get resource of uniphier-smpctrl\n");
 		return ret;
-- 
1.9.1



From yamada.masahiro at socionext.com  Mon Feb 15 18:15:07 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Tue, 16 Feb 2016 11:15:07 +0900
Subject: [PATCH 5/9] ARM: dts: uniphier: add EEPROM node for ProXstream2
 Gentil board
In-Reply-To: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
References: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1455588911-9827-6-git-send-email-yamada.masahiro@socionext.com>

This board has an EEPROM (STMicroelectronics M24C64-WMN6TP) connected
to the I2C channel 0 of the SoC.  Its slave address is 0x54.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
index 9d7ec5c..0da3018 100644
--- a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
+++ b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
@@ -75,4 +75,9 @@
 
 &i2c0 {
 	status = "okay";
+
+	eeprom at 54 {
+		compatible = "st,24c64";
+		reg = <0x54>;
+	};
 };
-- 
1.9.1



From yamada.masahiro at socionext.com  Mon Feb 15 18:15:08 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Tue, 16 Feb 2016 11:15:08 +0900
Subject: [PATCH 6/9] ARM: dts: uniphier: enable I2C channel 2 of ProXstream2
 Gentil board
In-Reply-To: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
References: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1455588911-9827-7-git-send-email-yamada.masahiro@socionext.com>

This is used for on-board inter-connection.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
index 0da3018..bf2619e 100644
--- a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
+++ b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
@@ -63,6 +63,7 @@
 		serial1 = &serial1;
 		serial2 = &serial2;
 		i2c0 = &i2c0;
+		i2c2 = &i2c2;
 		i2c4 = &i2c4;
 		i2c5 = &i2c5;
 		i2c6 = &i2c6;
@@ -81,3 +82,7 @@
 		reg = <0x54>;
 	};
 };
+
+&i2c2 {
+	status = "okay";
+};
-- 
1.9.1



From yamada.masahiro at socionext.com  Mon Feb 15 18:15:03 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Tue, 16 Feb 2016 11:15:03 +0900
Subject: [PATCH 1/9] ARM: dts: uniphier: factor out ranges property of support
 card
In-Reply-To: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
References: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1455588911-9827-2-git-send-email-yamada.masahiro@socionext.com>

This property is used in common by several boards.  Move it to the
common place (uniphier-support-card.dtsi).  If necessary, each board
can still override the property.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts              | 8 --------
 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts             | 8 --------
 arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts             | 8 --------
 arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts             | 8 --------
 arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts             | 8 --------
 arch/arm/boot/dts/uniphier-support-card.dtsi            | 3 +++
 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts | 8 --------
 7 files changed, 3 insertions(+), 48 deletions(-)

diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
index f1e9d40..ec94b7a 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
@@ -72,14 +72,6 @@
 	};
 };
 
-&extbus {
-	ranges = <1 0x00000000 0x42000000 0x02000000>;
-};
-
-&support_card {
-	ranges = <0x00000000 1 0x01f00000 0x00100000>;
-};
-
 &ethsc {
 	interrupts = <0 49 4>;
 };
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
index 5baa9fc..b8134c6 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
@@ -74,14 +74,6 @@
 	};
 };
 
-&extbus {
-	ranges = <1 0x00000000 0x42000000 0x02000000>;
-};
-
-&support_card {
-	ranges = <0x00000000 1 0x01f00000 0x00100000>;
-};
-
 &ethsc {
 	interrupts = <0 52 4>;
 };
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
index 2462668..95f631a 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
@@ -74,14 +74,6 @@
 	};
 };
 
-&extbus {
-	ranges = <1 0x00000000 0x42000000 0x02000000>;
-};
-
-&support_card {
-	ranges = <0x00000000 1 0x01f00000 0x00100000>;
-};
-
 &ethsc {
 	interrupts = <0 50 4>;
 };
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
index b7a03215..acb4204 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
@@ -73,14 +73,6 @@
 	};
 };
 
-&extbus {
-	ranges = <1 0x00000000 0x42000000 0x02000000>;
-};
-
-&support_card {
-	ranges = <0x00000000 1 0x01f00000 0x00100000>;
-};
-
 &ethsc {
 	interrupts = <0 49 4>;
 };
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
index fc7250c..d594f40 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
@@ -72,14 +72,6 @@
 	};
 };
 
-&extbus {
-	ranges = <1 0x00000000 0x42000000 0x02000000>;
-};
-
-&support_card {
-	ranges = <0x00000000 1 0x01f00000 0x00100000>;
-};
-
 &ethsc {
 	interrupts = <0 48 4>;
 };
diff --git a/arch/arm/boot/dts/uniphier-support-card.dtsi b/arch/arm/boot/dts/uniphier-support-card.dtsi
index da271e3..fa807e8 100644
--- a/arch/arm/boot/dts/uniphier-support-card.dtsi
+++ b/arch/arm/boot/dts/uniphier-support-card.dtsi
@@ -43,10 +43,13 @@
  */
 
 &extbus {
+	ranges = <1 0x00000000 0x42000000 0x02000000>;
+
 	support_card: support_card {
 		compatible = "simple-bus";
 		#address-cells = <1>;
 		#size-cells = <1>;
+		ranges = <0x00000000 1 0x01f00000 0x00100000>;
 
 		ethsc: ethernet at 00000000 {
 			compatible = "smsc,lan9118", "smsc,lan9115";
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
index 3e53317..e5c8a20 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
@@ -74,14 +74,6 @@
 	};
 };
 
-&extbus {
-	ranges = <1 0x00000000 0x42000000 0x02000000>;
-};
-
-&support_card {
-	ranges = <0x00000000 1 0x01f00000 0x00100000>;
-};
-
 &ethsc {
 	interrupts = <0 48 4>;
 };
-- 
1.9.1



From yamada.masahiro at socionext.com  Mon Feb 15 18:15:09 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Tue, 16 Feb 2016 11:15:09 +0900
Subject: [PATCH 7/9] ARM: dts: uniphier: add PH1-Pro4 Ace board support
In-Reply-To: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
References: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1455588911-9827-8-git-send-email-yamada.masahiro@socionext.com>

Initial commit for PH1-Pro4 Ace board support.

Note:
There are two variants for the amount of DDR memory; 1GB or 2GB.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/Makefile                  |   1 +
 arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts | 113 ++++++++++++++++++++++++++++
 2 files changed, 114 insertions(+)
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..d9d899f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -736,6 +736,7 @@ dtb-$(CONFIG_ARCH_U8500) += \
 dtb-$(CONFIG_ARCH_UNIPHIER) += \
 	uniphier-ph1-ld4-ref.dtb \
 	uniphier-ph1-ld6b-ref.dtb \
+	uniphier-ph1-pro4-ace.dtb \
 	uniphier-ph1-pro4-ref.dtb \
 	uniphier-ph1-sld3-ref.dtb \
 	uniphier-ph1-sld8-ref.dtb \
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts b/arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts
new file mode 100644
index 0000000..d343586
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts
@@ -0,0 +1,113 @@
+/*
+ * Device Tree Source for UniPhier PH1-Pro4 Ace Board
+ *
+ * Copyright (C) 2016 Masahiro Yamada <yamada.masahiro at socionext.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ "uniphier-ph1-pro4.dtsi"
+
+/ {
+	model = "UniPhier PH1-Pro4 Ace Board";
+	compatible = "socionext,ph1-pro4-ace", "socionext,ph1-pro4";
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x40000000>;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	aliases {
+		serial0 = &serial0;
+		serial1 = &serial1;
+		serial2 = &serial2;
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+		i2c5 = &i2c5;
+		i2c6 = &i2c6;
+	};
+};
+
+&serial0 {
+	status = "okay";
+};
+
+&serial1 {
+	status = "okay";
+};
+
+&serial2 {
+	status = "okay";
+};
+
+&i2c0 {
+	status = "okay";
+
+	eeprom at 54 {
+		compatible = "st,24c64";
+		reg = <0x54>;
+	};
+};
+
+&i2c1 {
+	status = "okay";
+};
+
+&i2c2 {
+	status = "okay";
+};
+
+&i2c3 {
+	status = "okay";
+};
+
+&usb2 {
+	status = "okay";
+};
+
+&usb3 {
+	status = "okay";
+};
-- 
1.9.1



From yamada.masahiro at socionext.com  Mon Feb 15 18:15:06 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Tue, 16 Feb 2016 11:15:06 +0900
Subject: [PATCH 4/9] ARM: dts: uniphier: add reference clock nodes
In-Reply-To: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
References: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1455588911-9827-5-git-send-email-yamada.masahiro@socionext.com>

Add master clock nodes generated by crystal oscillators.

  PH1-sLD3, PH1-LD4: 24.576 MHz
  PH1-Pro4, ProXstream2: 25.000 MHz
  PH1-Pro5: 20.000 MHz

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/uniphier-common32.dtsi    | 7 +++++++
 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi     | 4 ++++
 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi    | 4 ++++
 arch/arm/boot/dts/uniphier-ph1-pro5.dtsi    | 4 ++++
 arch/arm/boot/dts/uniphier-ph1-sld3.dtsi    | 6 ++++++
 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi    | 4 ++++
 arch/arm/boot/dts/uniphier-proxstream2.dtsi | 4 ++++
 7 files changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-common32.dtsi b/arch/arm/boot/dts/uniphier-common32.dtsi
index ae48d28..77a6694 100644
--- a/arch/arm/boot/dts/uniphier-common32.dtsi
+++ b/arch/arm/boot/dts/uniphier-common32.dtsi
@@ -45,6 +45,13 @@
 /include/ "skeleton.dtsi"
 
 / {
+	clocks {
+		refclk: ref {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+		};
+	};
+
 	soc: soc {
 		compatible = "simple-bus";
 		#address-cells = <1>;
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index 34f0d8d..dadd860 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -173,6 +173,10 @@
 
 };
 
+&refclk {
+	clock-frequency = <24576000>;
+};
+
 &serial3 {
 	interrupts = <0 29 4>;
 };
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index d78142f..20f3f2a 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -195,6 +195,10 @@
 	};
 };
 
+&refclk {
+	clock-frequency = <25000000>;
+};
+
 &pinctrl {
 	compatible = "socionext,ph1-pro4-pinctrl", "syscon";
 };
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
index 2f389ea..24f6f66 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
@@ -189,6 +189,10 @@
 	};
 };
 
+&refclk {
+	clock-frequency = <20000000>;
+};
+
 &pinctrl {
 	compatible = "socionext,ph1-pro5-pinctrl", "syscon";
 };
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
index ef94d2e..0c61e74 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
@@ -68,6 +68,12 @@
 	};
 
 	clocks {
+		refclk: ref {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <24576000>;
+		};
+
 		arm_timer_clk: arm_timer_clk {
 			#clock-cells = <0>;
 			compatible = "fixed-clock";
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
index 7d06a1c..6bfd29a 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
@@ -172,6 +172,10 @@
 	};
 };
 
+&refclk {
+	clock-frequency = <25000000>;
+};
+
 &serial3 {
 	interrupts = <0 29 4>;
 };
diff --git a/arch/arm/boot/dts/uniphier-proxstream2.dtsi b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
index 6bd353f..4ac484c 100644
--- a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
+++ b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
@@ -200,6 +200,10 @@
 	};
 };
 
+&refclk {
+	clock-frequency = <25000000>;
+};
+
 &pinctrl {
 	compatible = "socionext,proxstream2-pinctrl", "syscon";
 };
-- 
1.9.1



From yamada.masahiro at socionext.com  Mon Feb 15 18:15:02 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Tue, 16 Feb 2016 11:15:02 +0900
Subject: [PATCH 0/9] ARM: uniphier: UniPhier updates for Linux 4.6-rc1
Message-ID: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>


Hi Arnd and Olof,

Here is a series I want you to apply to ASOC.

I know this series includes DT updates for ARM 32bit and ARM 64bit,
but this is intentional.

Please apply the whole series to one branch.
Otherwise, it would cause a build error and big conflicts.
(some DT files are shared between arch/arm and arch/arm64,
so it is impossible to split the series into two.)



Masahiro Yamada (9):
  ARM: dts: uniphier: factor out ranges property of support card
  ARM: dts: uniphier: rework UniPhier System Bus nodes
  ARM: uniphier: add missing of_node_put()
  ARM: dts: uniphier: add reference clock nodes
  ARM: dts: uniphier: add EEPROM node for ProXstream2 Gentil board
  ARM: dts: uniphier: enable I2C channel 2 of ProXstream2 Gentil board
  ARM: dts: uniphier: add PH1-Pro4 Ace board support
  ARM: dts: uniphier: add PH1-Pro4 Sanji board support
  ARM: dts: uniphier: add @{address} to EEPROM node

 arch/arm/boot/dts/Makefile                         |   2 +
 arch/arm/boot/dts/uniphier-common32.dtsi           |  26 +++--
 arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts         |   8 --
 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi            |   4 +
 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts        |   8 --
 arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts        | 113 +++++++++++++++++++++
 arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts        |   8 --
 arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts      | 108 ++++++++++++++++++++
 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi           |   4 +
 arch/arm/boot/dts/uniphier-ph1-pro5.dtsi           |   4 +
 arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts        |   8 --
 arch/arm/boot/dts/uniphier-ph1-sld3.dtsi           |  25 +++--
 arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts        |   8 --
 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi           |   4 +
 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts  |  10 ++
 arch/arm/boot/dts/uniphier-proxstream2.dtsi        |   4 +
 arch/arm/boot/dts/uniphier-ref-daughter.dtsi       |   2 +-
 arch/arm/boot/dts/uniphier-support-card.dtsi       |   5 +-
 arch/arm/mach-uniphier/platsmp.c                   |  12 +--
 .../boot/dts/socionext/uniphier-ph1-ld10-ref.dts   |   8 --
 .../boot/dts/socionext/uniphier-ph1-ld10.dtsi      |  18 ++--
 21 files changed, 309 insertions(+), 80 deletions(-)
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts

-- 
1.9.1



From yamada.masahiro at socionext.com  Mon Feb 15 18:15:10 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Tue, 16 Feb 2016 11:15:10 +0900
Subject: [PATCH 8/9] ARM: dts: uniphier: add PH1-Pro4 Sanji board support
In-Reply-To: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
References: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1455588911-9827-9-git-send-email-yamada.masahiro@socionext.com>

Initial commit for PH1-Pro4 Sanji board support.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/Makefile                    |   1 +
 arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts | 108 ++++++++++++++++++++++++++
 2 files changed, 109 insertions(+)
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d9d899f..f2663ac 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -738,6 +738,7 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
 	uniphier-ph1-ld6b-ref.dtb \
 	uniphier-ph1-pro4-ace.dtb \
 	uniphier-ph1-pro4-ref.dtb \
+	uniphier-ph1-pro4-sanji.dtb \
 	uniphier-ph1-sld3-ref.dtb \
 	uniphier-ph1-sld8-ref.dtb \
 	uniphier-proxstream2-gentil.dtb \
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts b/arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts
new file mode 100644
index 0000000..7c3a1fc
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts
@@ -0,0 +1,108 @@
+/*
+ * Device Tree Source for UniPhier PH1-Pro4 Sanji Board
+ *
+ * Copyright (C) 2016 Masahiro Yamada <yamada.masahiro at socionext.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ "uniphier-ph1-pro4.dtsi"
+
+/ {
+	model = "UniPhier PH1-Pro4 Sanji Board";
+	compatible = "socionext,ph1-pro4-sanji", "socionext,ph1-pro4";
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x80000000>;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	aliases {
+		serial0 = &serial0;
+		serial1 = &serial1;
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+		i2c5 = &i2c5;
+		i2c6 = &i2c6;
+	};
+};
+
+&serial0 {
+	status = "okay";
+};
+
+&serial1 {
+	status = "okay";
+};
+
+&i2c0 {
+	status = "okay";
+
+	eeprom at 54 {
+		compatible = "st,24c64";
+		reg = <0x54>;
+	};
+};
+
+&i2c1 {
+	status = "okay";
+};
+
+&i2c2 {
+	status = "okay";
+};
+
+&i2c3 {
+	status = "okay";
+};
+
+&usb2 {
+	status = "okay";
+};
+
+&usb3 {
+	status = "okay";
+};
-- 
1.9.1



From yamada.masahiro at socionext.com  Mon Feb 15 18:15:04 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Tue, 16 Feb 2016 11:15:04 +0900
Subject: [PATCH 2/9] ARM: dts: uniphier: rework UniPhier System Bus nodes
In-Reply-To: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
References: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1455588911-9827-3-git-send-email-yamada.masahiro@socionext.com>

Tidy up the System Bus nodes in order to make the driver
(drivers/bus/uniphier-system-bus.c) really available.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/uniphier-common32.dtsi             | 19 ++++++++++---------
 arch/arm/boot/dts/uniphier-ph1-sld3.dtsi             | 19 ++++++++++---------
 arch/arm/boot/dts/uniphier-support-card.dtsi         |  2 +-
 arch/arm/mach-uniphier/platsmp.c                     | 11 +++++------
 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi | 18 ++++++++++++------
 5 files changed, 38 insertions(+), 31 deletions(-)

diff --git a/arch/arm/boot/dts/uniphier-common32.dtsi b/arch/arm/boot/dts/uniphier-common32.dtsi
index ea9301a..ae48d28 100644
--- a/arch/arm/boot/dts/uniphier-common32.dtsi
+++ b/arch/arm/boot/dts/uniphier-common32.dtsi
@@ -52,12 +52,6 @@
 		ranges;
 		interrupt-parent = <&intc>;
 
-		extbus: extbus {
-			compatible = "simple-bus";
-			#address-cells = <2>;
-			#size-cells = <1>;
-		};
-
 		serial0: serial at 54006800 {
 			compatible = "socionext,uniphier-uart";
 			status = "disabled";
@@ -98,9 +92,16 @@
 			clocks = <&uart_clk>;
 		};
 
-		system-bus-controller at 58c00000 {
-			compatible = "socionext,uniphier-system-bus-controller";
-			reg = <0x58c00000 0x400>, <0x59800000 0x2000>;
+		system_bus: system-bus at 58c00000 {
+			compatible = "socionext,uniphier-system-bus";
+			reg = <0x58c00000 0x400>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+		};
+
+		smpctrl at 59800000 {
+			compatible = "socionext,uniphier-smpctrl";
+			reg = <0x59801000 0x400>;
 		};
 
 		timer at 60000200 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
index 691a17d..ef94d2e 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
@@ -94,12 +94,6 @@
 		ranges;
 		interrupt-parent = <&intc>;
 
-		extbus: extbus {
-			compatible = "simple-bus";
-			#address-cells = <2>;
-			#size-cells = <1>;
-		};
-
 		timer at 20000200 {
 			compatible = "arm,cortex-a9-global-timer";
 			reg = <0x20000200 0x20>;
@@ -216,9 +210,16 @@
 			clock-frequency = <400000>;
 		};
 
-		system-bus-controller at 58c00000 {
-			compatible = "socionext,uniphier-system-bus-controller";
-			reg = <0x58c00000 0x400>, <0x59800000 0x2000>;
+		system_bus: system-bus at 58c00000 {
+			compatible = "socionext,uniphier-system-bus";
+			reg = <0x58c00000 0x400>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+		};
+
+		smpctrl at 59800000 {
+			compatible = "socionext,uniphier-smpctrl";
+			reg = <0x59801000 0x400>;
 		};
 
 		usb0: usb at 5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-support-card.dtsi b/arch/arm/boot/dts/uniphier-support-card.dtsi
index fa807e8..0d2826a 100644
--- a/arch/arm/boot/dts/uniphier-support-card.dtsi
+++ b/arch/arm/boot/dts/uniphier-support-card.dtsi
@@ -42,7 +42,7 @@
  *     OTHER DEALINGS IN THE SOFTWARE.
  */
 
-&extbus {
+&system_bus {
 	ranges = <1 0x00000000 0x42000000 0x02000000>;
 
 	support_card: support_card {
diff --git a/arch/arm/mach-uniphier/platsmp.c b/arch/arm/mach-uniphier/platsmp.c
index e1cfc1d..b53a8d9 100644
--- a/arch/arm/mach-uniphier/platsmp.c
+++ b/arch/arm/mach-uniphier/platsmp.c
@@ -30,7 +30,7 @@
  * The secondary CPUs check this register from the boot ROM for the jump
  * destination.  After that, it can be reused as a scratch register.
  */
-#define UNIPHIER_SBC_ROM_BOOT_RSV2	0x1208
+#define UNIPHIER_SMPCTRL_ROM_BOOT_RSV2	0x208
 
 static void __iomem *uniphier_smp_rom_boot_rsv2;
 static unsigned int uniphier_smp_max_cpus;
@@ -98,15 +98,14 @@ static int __init uniphier_smp_prepare_trampoline(unsigned int max_cpus)
 	phys_addr_t rom_rsv2_phys;
 	int ret;
 
-	np = of_find_compatible_node(NULL, NULL,
-				"socionext,uniphier-system-bus-controller");
-	ret = of_address_to_resource(np, 1, &res);
+	np = of_find_compatible_node(NULL, NULL, "socionext,uniphier-smpctrl");
+	ret = of_address_to_resource(np, 0, &res);
 	if (ret) {
-		pr_err("failed to get resource of system-bus-controller\n");
+		pr_err("failed to get resource of uniphier-smpctrl\n");
 		return ret;
 	}
 
-	rom_rsv2_phys = res.start + UNIPHIER_SBC_ROM_BOOT_RSV2;
+	rom_rsv2_phys = res.start + UNIPHIER_SMPCTRL_ROM_BOOT_RSV2;
 
 	ret = uniphier_smp_copy_trampoline(rom_rsv2_phys);
 	if (ret)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
index 0296af9..84637eb 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
@@ -133,12 +133,6 @@
 		#size-cells = <1>;
 		ranges = <0 0 0 0xffffffff>;
 
-		extbus: extbus {
-			compatible = "simple-bus";
-			#address-cells = <2>;
-			#size-cells = <1>;
-		};
-
 		serial0: serial at 54006800 {
 			compatible = "socionext,uniphier-uart";
 			status = "disabled";
@@ -261,6 +255,18 @@
 			clock-frequency = <400000>;
 		};
 
+		system_bus: system-bus at 58c00000 {
+			compatible = "socionext,uniphier-system-bus";
+			reg = <0x58c00000 0x400>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+		};
+
+		smpctrl at 59800000 {
+			compatible = "socionext,uniphier-smpctrl";
+			reg = <0x59801000 0x400>;
+		};
+
 		pinctrl: pinctrl at 5f801000 {
 			compatible = "socionext,ph1-ld10-pinctrl", "syscon";
 			reg = <0x5f801000 0xe00>;
-- 
1.9.1



From arnd at arndb.de  Mon Feb 15 07:46:27 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Feb 2016 16:46:27 +0100
Subject: [PATCH 0/4] clean up irq_to_gpio and asm/gpio.h
In-Reply-To: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <1455551208-2825510-1-git-send-email-arnd@arndb.de>

I noticed that arch/arm/include/asm/gpio.h can almost be removed,
after we have already removed the file for most other architectures
now.

When I removed it, I ran into problems with irq_to_gpio(), which
we had already killed off in ARM, but it survived (barely) in the
global headers. this kills it off some more as well.

I'd suggest merging all four patches through the GPIO tree.

	Arnd



From arnd at arndb.de  Mon Feb 15 07:46:28 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Feb 2016 16:46:28 +0100
Subject: [PATCH 1/4] gpio: remove broken irq_to_gpio() interface
In-Reply-To: <1455551208-2825510-1-git-send-email-arnd@arndb.de>
References: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <1455551208-2825510-1-git-send-email-arnd@arndb.de>
Message-ID: <1455551208-2825510-2-git-send-email-arnd@arndb.de>

gpiolib has removed the irq_to_gpio() API several years ago,
but the global header still provided a non-working stub.

Apparently one new user has shown up in arch/mips, so this patch
moves the broken definition to where it is used, ensuring that
we get new users but not changing the current behavior on jz4740.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/mips/jz4740/gpio.c |  7 +++++++
 include/linux/gpio.h    | 12 ------------
 2 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/arch/mips/jz4740/gpio.c b/arch/mips/jz4740/gpio.c
index 8c6d76c9b2d6..e9bb43714892 100644
--- a/arch/mips/jz4740/gpio.c
+++ b/arch/mips/jz4740/gpio.c
@@ -16,6 +16,7 @@
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/init.h>
+#include <linux/compiler.h>
 
 #include <linux/io.h>
 #include <linux/gpio.h>
@@ -270,6 +271,12 @@ uint32_t jz_gpio_port_get_value(int port, uint32_t mask)
 }
 EXPORT_SYMBOL(jz_gpio_port_get_value);
 
+static inline __deprecated int irq_to_gpio(unsigned int irq)
+{
+	/* this has clearly not worked for a long time */
+	return -EINVAL;
+}
+
 #define IRQ_TO_BIT(irq) BIT(irq_to_gpio(irq) & 0x1f)
 
 static void jz_gpio_check_trigger_both(struct jz_gpio_chip *chip, unsigned int irq)
diff --git a/include/linux/gpio.h b/include/linux/gpio.h
index d12b5d566e4b..6fc1c9e74854 100644
--- a/include/linux/gpio.h
+++ b/include/linux/gpio.h
@@ -70,11 +70,6 @@ static inline int gpio_to_irq(unsigned int gpio)
 	return __gpio_to_irq(gpio);
 }
 
-static inline int irq_to_gpio(unsigned int irq)
-{
-	return -EINVAL;
-}
-
 #endif /* ! CONFIG_ARCH_HAVE_CUSTOM_GPIO_H */
 
 /* CONFIG_GPIOLIB: bindings for managed devices that want to request gpios */
@@ -222,13 +217,6 @@ static inline void gpiochip_unlock_as_irq(struct gpio_chip *chip,
 	WARN_ON(1);
 }
 
-static inline int irq_to_gpio(unsigned irq)
-{
-	/* irq can never have been returned from gpio_to_irq() */
-	WARN_ON(1);
-	return -EINVAL;
-}
-
 static inline int
 gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
 		       unsigned int gpio_offset, unsigned int pin_offset,
-- 
2.7.0



From arnd at arndb.de  Mon Feb 15 07:46:30 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Feb 2016 16:46:30 +0100
Subject: [PATCH 3/4] gpio: ep93xx: remove private irq_to_gpio function
In-Reply-To: <1455551208-2825510-1-git-send-email-arnd@arndb.de>
References: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <1455551208-2825510-1-git-send-email-arnd@arndb.de>
Message-ID: <1455551208-2825510-4-git-send-email-arnd@arndb.de>

The ep93xx goes through its own back-and-forth dance every time
it wants to know the gpio number for an irq line, when it really
just hardcodes a fixed offset in ep93xx_gpio_to_irq().

This removes the pointless macro and replaces the conversion inside
of the driver with simple add/subtract operations, using an
explicit macro.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/gpio/gpio-ep93xx.c | 37 +++++++++++++++++--------------------
 1 file changed, 17 insertions(+), 20 deletions(-)

diff --git a/drivers/gpio/gpio-ep93xx.c b/drivers/gpio/gpio-ep93xx.c
index 20e5846bda28..cd83d30e8ff7 100644
--- a/drivers/gpio/gpio-ep93xx.c
+++ b/drivers/gpio/gpio-ep93xx.c
@@ -18,12 +18,8 @@
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/slab.h>
-#include <linux/gpio/driver.h>
-/* FIXME: this is here for gpio_to_irq() - get rid of this! */
 #include <linux/gpio.h>
 
-#define irq_to_gpio(irq)	((irq) - gpio_to_irq(0))
-
 void __iomem *ep93xx_gpio_base; /* FIXME: put this into irq_data */
 
 #define EP93XX_GPIO_REG(x)		(ep93xx_gpio_base + (x))
@@ -35,6 +31,7 @@ void __iomem *ep93xx_gpio_base; /* FIXME: put this into irq_data */
 #define EP93XX_GPIO_LINE_MAX		63
 
 /* maximum value for irq capable line identifiers */
+#define EP93XX_GPIO_IRQ_BASE		64
 #define EP93XX_GPIO_LINE_MAX_IRQ	23
 
 
@@ -77,7 +74,7 @@ static void ep93xx_gpio_update_int_params(unsigned port)
 
 static void ep93xx_gpio_int_debounce(unsigned int irq, bool enable)
 {
-	int line = irq_to_gpio(irq);
+	int line = irq - EP93XX_GPIO_IRQ_BASE;
 	int port = line >> 3;
 	int port_mask = 1 << (line & 7);
 
@@ -98,7 +95,7 @@ static void ep93xx_gpio_ab_irq_handler(struct irq_desc *desc)
 	status = readb(EP93XX_GPIO_A_INT_STATUS);
 	for (i = 0; i < 8; i++) {
 		if (status & (1 << i)) {
-			int gpio_irq = gpio_to_irq(0) + i;
+			int gpio_irq = EP93XX_GPIO_IRQ_BASE + i;
 			generic_handle_irq(gpio_irq);
 		}
 	}
@@ -106,7 +103,7 @@ static void ep93xx_gpio_ab_irq_handler(struct irq_desc *desc)
 	status = readb(EP93XX_GPIO_B_INT_STATUS);
 	for (i = 0; i < 8; i++) {
 		if (status & (1 << i)) {
-			int gpio_irq = gpio_to_irq(8) + i;
+			int gpio_irq = EP93XX_GPIO_IRQ_BASE + 8 + i;
 			generic_handle_irq(gpio_irq);
 		}
 	}
@@ -121,14 +118,14 @@ static void ep93xx_gpio_f_irq_handler(struct irq_desc *desc)
 	 */
 	unsigned int irq = irq_desc_get_irq(desc);
 	int port_f_idx = ((irq + 1) & 7) ^ 4; /* {19..22,47..50} -> {0..7} */
-	int gpio_irq = gpio_to_irq(16) + port_f_idx;
+	int gpio_irq = EP93XX_GPIO_IRQ_BASE + 16 + port_f_idx;
 
 	generic_handle_irq(gpio_irq);
 }
 
 static void ep93xx_gpio_irq_ack(struct irq_data *d)
 {
-	int line = irq_to_gpio(d->irq);
+	int line = d->irq - EP93XX_GPIO_IRQ_BASE;
 	int port = line >> 3;
 	int port_mask = 1 << (line & 7);
 
@@ -142,7 +139,7 @@ static void ep93xx_gpio_irq_ack(struct irq_data *d)
 
 static void ep93xx_gpio_irq_mask_ack(struct irq_data *d)
 {
-	int line = irq_to_gpio(d->irq);
+	int line = d->irq - EP93XX_GPIO_IRQ_BASE;
 	int port = line >> 3;
 	int port_mask = 1 << (line & 7);
 
@@ -157,7 +154,7 @@ static void ep93xx_gpio_irq_mask_ack(struct irq_data *d)
 
 static void ep93xx_gpio_irq_mask(struct irq_data *d)
 {
-	int line = irq_to_gpio(d->irq);
+	int line = d->irq - EP93XX_GPIO_IRQ_BASE;
 	int port = line >> 3;
 
 	gpio_int_unmasked[port] &= ~(1 << (line & 7));
@@ -166,7 +163,7 @@ static void ep93xx_gpio_irq_mask(struct irq_data *d)
 
 static void ep93xx_gpio_irq_unmask(struct irq_data *d)
 {
-	int line = irq_to_gpio(d->irq);
+	int line = d->irq - EP93XX_GPIO_IRQ_BASE;
 	int port = line >> 3;
 
 	gpio_int_unmasked[port] |= 1 << (line & 7);
@@ -180,7 +177,7 @@ static void ep93xx_gpio_irq_unmask(struct irq_data *d)
  */
 static int ep93xx_gpio_irq_type(struct irq_data *d, unsigned int type)
 {
-	const int gpio = irq_to_gpio(d->irq);
+	const int gpio = d->irq - EP93XX_GPIO_IRQ_BASE;
 	const int port = gpio >> 3;
 	const int port_mask = 1 << (gpio & 7);
 	irq_flow_handler_t handler;
@@ -241,14 +238,14 @@ static struct irq_chip ep93xx_gpio_irq_chip = {
 
 static void ep93xx_gpio_init_irq(struct platform_device *pdev)
 {
-	int gpio_irq;
+	int gpio;
 	int i;
 
-	for (gpio_irq = gpio_to_irq(0);
-	     gpio_irq <= gpio_to_irq(EP93XX_GPIO_LINE_MAX_IRQ); ++gpio_irq) {
-		irq_set_chip_and_handler(gpio_irq, &ep93xx_gpio_irq_chip,
+	for (gpio = 0; gpio <= EP93XX_GPIO_LINE_MAX_IRQ; ++gpio) {
+		irq_set_chip_and_handler(EP93XX_GPIO_IRQ_BASE + gpio,
+					 &ep93xx_gpio_irq_chip,
 					 handle_level_irq);
-		irq_clear_status_flags(gpio_irq, IRQ_NOREQUEST);
+		irq_clear_status_flags(EP93XX_GPIO_IRQ_BASE + gpio, IRQ_NOREQUEST);
 	}
 
 	irq_set_chained_handler(platform_get_irq(pdev, 0),
@@ -294,7 +291,7 @@ static int ep93xx_gpio_set_debounce(struct gpio_chip *chip,
 				    unsigned offset, unsigned debounce)
 {
 	int gpio = chip->base + offset;
-	int irq = gpio_to_irq(gpio);
+	int irq = EP93XX_GPIO_IRQ_BASE + gpio;
 
 	if (irq < 0)
 		return -EINVAL;
@@ -316,7 +313,7 @@ static int ep93xx_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
 	if (gpio > EP93XX_GPIO_LINE_MAX_IRQ)
 		return -EINVAL;
 
-	return 64 + gpio;
+	return EP93XX_GPIO_IRQ_BASE + gpio;
 }
 
 static int ep93xx_gpio_add_bank(struct gpio_chip *gc, struct device *dev,
-- 
2.7.0



From arnd at arndb.de  Mon Feb 15 07:46:29 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Feb 2016 16:46:29 +0100
Subject: [PATCH 2/4] gpio: ks8695: remove irq_to_gpio function
In-Reply-To: <1455551208-2825510-1-git-send-email-arnd@arndb.de>
References: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <1455551208-2825510-1-git-send-email-arnd@arndb.de>
Message-ID: <1455551208-2825510-3-git-send-email-arnd@arndb.de>

The ks8695 gpio driver has its own copy of the irq_to_gpio()
function. This is completely unused in the mainline kernel
after we converted all remaining users several years ago,
so we can remove the definition as well.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/gpio/gpio-ks8695.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpio/gpio-ks8695.c b/drivers/gpio/gpio-ks8695.c
index 9f86ed9c753b..179723d02f55 100644
--- a/drivers/gpio/gpio-ks8695.c
+++ b/drivers/gpio/gpio-ks8695.c
@@ -205,18 +205,6 @@ static int ks8695_gpio_to_irq(struct gpio_chip *gc, unsigned int pin)
 	return gpio_irq[pin];
 }
 
-/*
- * Map IRQ number to GPIO line.
- */
-int irq_to_gpio(unsigned int irq)
-{
-	if ((irq < KS8695_IRQ_EXTERN0) || (irq > KS8695_IRQ_EXTERN3))
-		return -EINVAL;
-
-	return (irq - KS8695_IRQ_EXTERN0);
-}
-EXPORT_SYMBOL(irq_to_gpio);
-
 /* GPIOLIB interface */
 
 static struct gpio_chip ks8695_gpio_chip = {
-- 
2.7.0



From arnd at arndb.de  Mon Feb 15 07:46:31 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Feb 2016 16:46:31 +0100
Subject: [PATCH 4/4] ARM: remove asm/gpio.h
In-Reply-To: <1455551208-2825510-1-git-send-email-arnd@arndb.de>
References: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <1455551208-2825510-1-git-send-email-arnd@arndb.de>
Message-ID: <1455551208-2825510-5-git-send-email-arnd@arndb.de>

The ARM version of asm/gpio.h basically just contains the same definitions
as the gpiolib version, with the exception of ARCH_NR_GPIOS.

This adds the option for overriding the constant through Kconfig to
the architecture-independent header, and removes the ARM version at
the same time.

This patch depends on a series done by Bjorn Helgaas, and the patch
removing irq_to_gpio().

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/Kconfig            |  1 -
 arch/arm/include/asm/gpio.h | 25 -------------------------
 include/asm-generic/gpio.h  |  4 ++++
 3 files changed, 4 insertions(+), 26 deletions(-)
 delete mode 100644 arch/arm/include/asm/gpio.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0366ad63e2ed..27aefbe43eea 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -5,7 +5,6 @@ config ARM
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ELF_RANDOMIZE
 	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
-	select ARCH_HAVE_CUSTOM_GPIO_H
 	select ARCH_HAS_GCOV_PROFILE_ALL
 	select ARCH_MIGHT_HAVE_PC_PARPORT
 	select ARCH_SUPPORTS_ATOMIC_RMW
diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
deleted file mode 100644
index 504dcddebfcc..000000000000
--- a/arch/arm/include/asm/gpio.h
+++ /dev/null
@@ -1,25 +0,0 @@
-#ifndef _ARCH_ARM_GPIO_H
-#define _ARCH_ARM_GPIO_H
-
-#if CONFIG_ARCH_NR_GPIO > 0
-#define ARCH_NR_GPIOS CONFIG_ARCH_NR_GPIO
-#endif
-
-/* Note: this may rely upon the value of ARCH_NR_GPIOS set in mach/gpio.h */
-#include <asm-generic/gpio.h>
-
-/* The trivial gpiolib dispatchers */
-#define gpio_get_value  __gpio_get_value
-#define gpio_set_value  __gpio_set_value
-#define gpio_cansleep   __gpio_cansleep
-
-/*
- * Provide a default gpio_to_irq() which should satisfy every case.
- * However, some platforms want to do this differently, so allow them
- * to override it.
- */
-#ifndef gpio_to_irq
-#define gpio_to_irq	__gpio_to_irq
-#endif
-
-#endif /* _ARCH_ARM_GPIO_H */
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 40ec1433f05d..2d04b321db13 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -26,8 +26,12 @@
  */
 
 #ifndef ARCH_NR_GPIOS
+#ifdef CONFIG_ARCH_NR_GPIO
+#define ARCH_NR_GPIOS CONFIG_ARCH_NR_GPIO
+#else
 #define ARCH_NR_GPIOS		512
 #endif
+#endif
 
 /*
  * "valid" GPIO numbers are nonnegative and may be passed to
-- 
2.7.0



From jszhang at marvell.com  Mon Feb 15 18:38:02 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 10:38:02 +0800
Subject: [PATCH v4 00/13] mmc: use sdhci_pltfm_init for private
 allocation and clean up
In-Reply-To: <56B8A1A1.2080408@intel.com>
References: <1453803353-6266-1-git-send-email-jszhang@marvell.com>
 <CAPDyKFpFSTYsAUCG9nFnnzmVsA3zm4hAPO8+6REArt9BJtn+0Q@mail.gmail.com>
 <56B8A1A1.2080408@intel.com>
Message-ID: <20160216103802.266f356c@xhacker>

Dear Adrian, Ulf,

On Mon, 8 Feb 2016 16:09:37 +0200 Adrian Hunter wrote:

> On 04/02/16 12:38, Ulf Hansson wrote:
> > + Adrian
> > 
> > On 26 January 2016 at 11:15, Jisheng Zhang <jszhang at marvell.com> wrote:  
> >> These patches are to complete the TODOs in Commit 0e748234293f ("mmc:
> >> sdhci: Add size for caller in init+register"), I.E:
> >>
> >> - todo: migrate clients to using allocation this way
> >> - todo: remove priv variable once migration is complete
> >>
> >> Since v3:
> >>  - based on v4.5-rc1
> >>  - add Ludovic's ack for sdhci-of-at91 changes
> >>  - fix use-after-free in some drivers: some host drivers still needs to
> >>    access sdhci_pltfm_host->private after sdhci_pltfm_unregister(), but
> >>    the private should be already freed by sdhci_pltfm_unregister.
> >>  - add patch5 to fix one clk bug in sdhci_arasan_remove(). IMHO, It's
> >>    better to add this patch to fixes rather than waiting for next merge
> >>    window
> >>
> >> Since v2:
> >>  - based on mmc next tree and remove all priv usage introduced in newly
> >>    commits in this tree
> >>  - don't break two lines if sdhci_pltfm_init() call could be put into
> >>    one line. Thank Ludovic Desroches.
> >>
> >> Since v1:
> >>  - add new patch03 to factorise sdhci_msm_pdata outisde of sdhci_msm_host.
> >>    This is to fix drivers/mmc/host/sdhci-msm.c:440:32: warning: 'msm_host'
> >>    is used uninitialized in this function [-Wuninitialized]
> >>  - Add Arnd's Ack for all patches except patch3 which is new in v2
> >>
> >>
> >> Jisheng Zhang (13):
> >>   mmc: sdhci-bcm2835: use sdhci_pltfm_init for private allocation
> >>   mmc: sdhci-esdhc-imx: use sdhci_pltfm_init for private allocation
> >>   mmc: sdhci-msm: factorise sdhci_msm_pdata outisde of sdhci_msm_host
> >>   mmc: sdhci-msm: use sdhci_pltfm_init for private allocation
> >>   mmc: sdhci-of-arasan: fix clk issue in sdhci_arasan_remove()
> >>   mmc: sdhci-of-arasan: use sdhci_pltfm_init for private allocation
> >>   mmc: sdhci-of-at91: use sdhci_pltfm_init for private allocation
> >>   mmc: sdhci-of-esdhc: use sdhci_pltfm_init for private allocation
> >>   mmc: sdhci-pxav3: use sdhci_pltfm_init for private allocation
> >>   mmc: sdhci-st: use sdhci_pltfm_init for private allocation
> >>   mmc: sdhci-tegra: use sdhci_pltfm_init for private allocation
> >>   mmc: sdhci-pxav2: remove unnecessary assignment of pltfm_host->priv
> >>   mmc: sdhci-pltfm: remove priv variable from sdhci_pltfm_host
> >>
> >>  drivers/mmc/host/sdhci-bcm2835.c   | 14 +++----------
> >>  drivers/mmc/host/sdhci-esdhc-imx.c | 38 ++++++++++++++++--------------------
> >>  drivers/mmc/host/sdhci-msm.c       | 25 +++++++++++-------------
> >>  drivers/mmc/host/sdhci-of-arasan.c | 33 +++++++++++++++----------------
> >>  drivers/mmc/host/sdhci-of-at91.c   | 33 ++++++++++++++-----------------
> >>  drivers/mmc/host/sdhci-of-esdhc.c  | 19 +++++++++---------
> >>  drivers/mmc/host/sdhci-pltfm.h     |  1 -
> >>  drivers/mmc/host/sdhci-pxav2.c     |  1 -
> >>  drivers/mmc/host/sdhci-pxav3.c     | 20 ++++++++-----------
> >>  drivers/mmc/host/sdhci-st.c        | 40 +++++++++++++++++++-------------------
> >>  drivers/mmc/host/sdhci-tegra.c     | 21 +++++++-------------
> >>  11 files changed, 106 insertions(+), 139 deletions(-)
> >>
> >> --
> >> 2.7.0
> >>  
> > 
> > To avoid confusions. I don't intend to pick up any further sdhci
> > patches, unless they are acked by Adrian Hunter.  
> 
> The patches look OK, although patch 6 doesn't apply cleanly anymore.
> Nevertheless:

Sorry for being late. I'm just back from vacation.
Thank you very much for reviewing! I'll send a new series based on Ulf's next
branch.

> 
> Acked-by: Adrian Hunter <adrian.hunter at intel.com>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From wuninsu at gmail.com  Mon Feb 15 18:46:37 2016
From: wuninsu at gmail.com (Insu Yun)
Date: Mon, 15 Feb 2016 21:46:37 -0500
Subject: [PATCH] s5p_mfc: handling failed allocation for workqueue
Message-ID: <1455590797-8522-1-git-send-email-wuninsu@gmail.com>

create_singlethread_workqueue() can be failed in memory pressure.

Signed-off-by: Insu Yun <wuninsu at gmail.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 927ab49..631aea814 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1239,6 +1239,10 @@ static int s5p_mfc_probe(struct platform_device *pdev)
 
 	dev->hw_lock = 0;
 	dev->watchdog_workqueue = create_singlethread_workqueue(S5P_MFC_NAME);
+	if (!dev->watchdog_workqueue) {
+		ret = -ENOMEM;
+		goto err_enc_reg;
+	}
 	INIT_WORK(&dev->watchdog_work, s5p_mfc_watchdog_worker);
 	atomic_set(&dev->watchdog_cnt, 0);
 	init_timer(&dev->watchdog_timer);
-- 
1.9.1



From songjun.wu at atmel.com  Mon Feb 15 18:54:21 2016
From: songjun.wu at atmel.com (Wu, Songjun)
Date: Tue, 16 Feb 2016 10:54:21 +0800
Subject: [PATCH] ASoC: atmel_ssc_dai: distinguish the different SSC
In-Reply-To: <56966852.8050205@atmel.com>
References: <1452666910-23586-1-git-send-email-songjun.wu@atmel.com>
 <56966852.8050205@atmel.com>
Message-ID: <56C28F5D.5010000@atmel.com>


Any comments on this patch?

On 1/13/2016 23:08, Nicolas Ferre wrote:
> Le 13/01/2016 07:35, Songjun Wu a ?crit :
>> Cpu_dai id always equals 0, can't distinguish the
>> different SSC. Use platform_device id to record
>> and distinguish the different SSC.
>>
>> Signed-off-by: Songjun Wu <songjun.wu at atmel.com>
>
> It seems okay:
> Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
>
>> ---
>>
>>   drivers/misc/atmel-ssc.c        |    1 +
>>   sound/soc/atmel/atmel_ssc_dai.c |   27 ++++++++++++++++++---------
>>   2 files changed, 19 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
>> index e11a0bd..0516ecd 100644
>> --- a/drivers/misc/atmel-ssc.c
>> +++ b/drivers/misc/atmel-ssc.c
>> @@ -34,6 +34,7 @@ struct ssc_device *ssc_request(unsigned int ssc_num)
>>   		if (ssc->pdev->dev.of_node) {
>>   			if (of_alias_get_id(ssc->pdev->dev.of_node, "ssc")
>>   				== ssc_num) {
>> +				ssc->pdev->id = ssc_num;
>>   				ssc_valid = 1;
>>   				break;
>>   			}
>> diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
>> index ba8def5..2768970 100644
>> --- a/sound/soc/atmel/atmel_ssc_dai.c
>> +++ b/sound/soc/atmel/atmel_ssc_dai.c
>> @@ -285,7 +285,8 @@ static int atmel_ssc_hw_rule_rate(struct snd_pcm_hw_params *params,
>>   static int atmel_ssc_startup(struct snd_pcm_substream *substream,
>>   			     struct snd_soc_dai *dai)
>>   {
>> -	struct atmel_ssc_info *ssc_p = &ssc_info[dai->id];
>> +	struct platform_device *pdev = to_platform_device(dai->dev);
>> +	struct atmel_ssc_info *ssc_p = &ssc_info[pdev->id];
>>   	struct atmel_pcm_dma_params *dma_params;
>>   	int dir, dir_mask;
>>   	int ret;
>> @@ -346,7 +347,8 @@ static int atmel_ssc_startup(struct snd_pcm_substream *substream,
>>   static void atmel_ssc_shutdown(struct snd_pcm_substream *substream,
>>   			       struct snd_soc_dai *dai)
>>   {
>> -	struct atmel_ssc_info *ssc_p = &ssc_info[dai->id];
>> +	struct platform_device *pdev = to_platform_device(dai->dev);
>> +	struct atmel_ssc_info *ssc_p = &ssc_info[pdev->id];
>>   	struct atmel_pcm_dma_params *dma_params;
>>   	int dir, dir_mask;
>>
>> @@ -392,7 +394,8 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream *substream,
>>   static int atmel_ssc_set_dai_fmt(struct snd_soc_dai *cpu_dai,
>>   		unsigned int fmt)
>>   {
>> -	struct atmel_ssc_info *ssc_p = &ssc_info[cpu_dai->id];
>> +	struct platform_device *pdev = to_platform_device(cpu_dai->dev);
>> +	struct atmel_ssc_info *ssc_p = &ssc_info[pdev->id];
>>
>>   	ssc_p->daifmt = fmt;
>>   	return 0;
>> @@ -404,7 +407,8 @@ static int atmel_ssc_set_dai_fmt(struct snd_soc_dai *cpu_dai,
>>   static int atmel_ssc_set_dai_clkdiv(struct snd_soc_dai *cpu_dai,
>>   	int div_id, int div)
>>   {
>> -	struct atmel_ssc_info *ssc_p = &ssc_info[cpu_dai->id];
>> +	struct platform_device *pdev = to_platform_device(cpu_dai->dev);
>> +	struct atmel_ssc_info *ssc_p = &ssc_info[pdev->id];
>>
>>   	switch (div_id) {
>>   	case ATMEL_SSC_CMR_DIV:
>> @@ -445,7 +449,8 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
>>   	struct snd_pcm_hw_params *params,
>>   	struct snd_soc_dai *dai)
>>   {
>> -	int id = dai->id;
>> +	struct platform_device *pdev = to_platform_device(dai->dev);
>> +	int id = pdev->id;
>>   	struct atmel_ssc_info *ssc_p = &ssc_info[id];
>>   	struct ssc_device *ssc = ssc_p->ssc;
>>   	struct atmel_pcm_dma_params *dma_params;
>> @@ -772,7 +777,8 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
>>   static int atmel_ssc_prepare(struct snd_pcm_substream *substream,
>>   			     struct snd_soc_dai *dai)
>>   {
>> -	struct atmel_ssc_info *ssc_p = &ssc_info[dai->id];
>> +	struct platform_device *pdev = to_platform_device(dai->dev);
>> +	struct atmel_ssc_info *ssc_p = &ssc_info[pdev->id];
>>   	struct atmel_pcm_dma_params *dma_params;
>>   	int dir;
>>
>> @@ -795,7 +801,8 @@ static int atmel_ssc_prepare(struct snd_pcm_substream *substream,
>>   static int atmel_ssc_trigger(struct snd_pcm_substream *substream,
>>   			     int cmd, struct snd_soc_dai *dai)
>>   {
>> -	struct atmel_ssc_info *ssc_p = &ssc_info[dai->id];
>> +	struct platform_device *pdev = to_platform_device(dai->dev);
>> +	struct atmel_ssc_info *ssc_p = &ssc_info[pdev->id];
>>   	struct atmel_pcm_dma_params *dma_params;
>>   	int dir;
>>
>> @@ -824,11 +831,12 @@ static int atmel_ssc_trigger(struct snd_pcm_substream *substream,
>>   static int atmel_ssc_suspend(struct snd_soc_dai *cpu_dai)
>>   {
>>   	struct atmel_ssc_info *ssc_p;
>> +	struct platform_device *pdev = to_platform_device(cpu_dai->dev);
>>
>>   	if (!cpu_dai->active)
>>   		return 0;
>>
>> -	ssc_p = &ssc_info[cpu_dai->id];
>> +	ssc_p = &ssc_info[pdev->id];
>>
>>   	/* Save the status register before disabling transmit and receive */
>>   	ssc_p->ssc_state.ssc_sr = ssc_readl(ssc_p->ssc->regs, SR);
>> @@ -852,12 +860,13 @@ static int atmel_ssc_suspend(struct snd_soc_dai *cpu_dai)
>>   static int atmel_ssc_resume(struct snd_soc_dai *cpu_dai)
>>   {
>>   	struct atmel_ssc_info *ssc_p;
>> +	struct platform_device *pdev = to_platform_device(cpu_dai->dev);
>>   	u32 cr;
>>
>>   	if (!cpu_dai->active)
>>   		return 0;
>>
>> -	ssc_p = &ssc_info[cpu_dai->id];
>> +	ssc_p = &ssc_info[pdev->id];
>>
>>   	/* restore SSC register settings */
>>   	ssc_writel(ssc_p->ssc->regs, TFMR, ssc_p->ssc_state.ssc_tfmr);
>>
>
>


From eric at anholt.net  Mon Feb 15 19:03:58 2016
From: eric at anholt.net (Eric Anholt)
Date: Mon, 15 Feb 2016 19:03:58 -0800
Subject: [PATCH 2/2] clk: bcm2835: Reuse CLK_DIVIDER_MAX_AT_ZERO for
 recalc_rate()
In-Reply-To: <1455591838-22725-1-git-send-email-eric@anholt.net>
References: <1455591838-22725-1-git-send-email-eric@anholt.net>
Message-ID: <1455591838-22725-2-git-send-email-eric@anholt.net>

We were rolling this ourselves, but clk-divider can do it now.

Signed-off-by: Eric Anholt <eric at anholt.net>
---
 drivers/clk/bcm/clk-bcm2835.c | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 9f4df8f..353e438 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -1060,16 +1060,7 @@ static long bcm2835_pll_divider_round_rate(struct clk_hw *hw,
 static unsigned long bcm2835_pll_divider_get_rate(struct clk_hw *hw,
 						  unsigned long parent_rate)
 {
-	struct bcm2835_pll_divider *divider = bcm2835_pll_divider_from_hw(hw);
-	struct bcm2835_cprman *cprman = divider->cprman;
-	const struct bcm2835_pll_divider_data *data = divider->data;
-	u32 div = cprman_read(cprman, data->a2w_reg);
-
-	div &= (1 << A2W_PLL_DIV_BITS) - 1;
-	if (div == 0)
-		div = 256;
-
-	return parent_rate / div;
+	return clk_divider_ops.recalc_rate(hw, parent_rate);
 }
 
 static void bcm2835_pll_divider_off(struct clk_hw *hw)
@@ -1430,7 +1421,7 @@ bcm2835_register_pll_divider(struct bcm2835_cprman *cprman,
 	divider->div.reg = cprman->regs + data->a2w_reg;
 	divider->div.shift = A2W_PLL_DIV_SHIFT;
 	divider->div.width = A2W_PLL_DIV_BITS;
-	divider->div.flags = 0;
+	divider->div.flags = CLK_DIVIDER_MAX_AT_ZERO;
 	divider->div.lock = &cprman->regs_lock;
 	divider->div.hw.init = &init;
 	divider->div.table = NULL;
-- 
2.7.0



From eric at anholt.net  Mon Feb 15 19:03:57 2016
From: eric at anholt.net (Eric Anholt)
Date: Mon, 15 Feb 2016 19:03:57 -0800
Subject: [PATCH 1/2] clk: bcm2835: Fix setting of PLL divider clock rates
Message-ID: <1455591838-22725-1-git-send-email-eric@anholt.net>

Our dividers weren't being set successfully because CM_PASSWORD wasn't
included in the register write.  It looks easier to just compute the
divider to write ourselves than to update clk-divider for the ability
to OR in some arbitrary bits on write.

Fixes about half of the video modes on my HDMI monitor (everything
except 720x400).

Cc: stable at vger.kernel.org
Signed-off-by: Eric Anholt <eric at anholt.net>
---
 drivers/clk/bcm/clk-bcm2835.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 015e687..9f4df8f 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -1107,13 +1107,15 @@ static int bcm2835_pll_divider_set_rate(struct clk_hw *hw,
 	struct bcm2835_pll_divider *divider = bcm2835_pll_divider_from_hw(hw);
 	struct bcm2835_cprman *cprman = divider->cprman;
 	const struct bcm2835_pll_divider_data *data = divider->data;
-	u32 cm;
-	int ret;
+	u32 cm, div, max_div = 1 << A2W_PLL_DIV_BITS;
 
-	ret = clk_divider_ops.set_rate(hw, rate, parent_rate);
-	if (ret)
-		return ret;
+	div = DIV_ROUND_UP_ULL(parent_rate, rate);
+
+	div = min(div, max_div);
+	if (div == max_div)
+		div = 0;
 
+	cprman_write(cprman, data->a2w_reg, div);
 	cm = cprman_read(cprman, data->cm_reg);
 	cprman_write(cprman, data->cm_reg, cm | data->load_mask);
 	cprman_write(cprman, data->cm_reg, cm & ~data->load_mask);
-- 
2.7.0



From arnd at arndb.de  Mon Feb 15 08:12:54 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Feb 2016 17:12:54 +0100
Subject: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
In-Reply-To: <m3y4amqdym.fsf@t19.piap.pl>
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <2926427.2IOxhm2GZo@wuerfel> <m3y4amqdym.fsf@t19.piap.pl>
Message-ID: <4239208.KBB6rfivoa@wuerfel>

On Monday 15 February 2016 14:51:13 Krzysztof Ha?asa wrote:
> Arnd Bergmann <arnd at arndb.de> writes:
> 
> > I consider the use of __raw_* accessors a bug, I don't think we should
> > ever do that because it hides how the hardware actually works, it doesn't
> > work with spinlocks, and it can lead to the compiler splitting up accesses
> > into byte sized ones (not on ARM with the current definition, but
> > possible in general).
> 
> Well, then maybe we should fix them, or add another set.
> Why don't they work with spinlocks?

The barriers on a spinlock synchronize between CPUs but not an external
bus, so (on some architectures) a spinlock protecting an MMIO register
does not guarantee that two CPUs doing

	spin_lock();
	__raw_writel(address);
	__raw_writel(data);
	spin_unlock();

would cause pairs of address/data to be seen on the bus.

Of course this is meaningless on ixp4xx, as there is only one CPU.

> To be honest, I remember this was already discussed a bit years ago.
> I think I proposed back then a set of read_le32 (which would be
> equivalent of current readl(), and could be named pci_readl() as well),
> read_be32, read_host (without swapping).
> The names could be better, though.

It keeps coming back, but so far the status quo has been stronger,
any it generally works for portable code either hardcoding whichever
endianess the device has, or using runtime detection when the same
device can be used in various ways (e.g. USB ehci).

On powerpc, we have in_le32/in_be32 for SoC-internal register access,
while only PCI devices are allowed to be accessed using readl().

> > Almost all hardware is fixed-endian, so you have to use swapping accessors
> > when the CPU is the other way, except for device RAM and FIFO registers
> > that are always used to transfer a byte stream (see the definition of
> > readsl() and memcpy_fromio()). When you have hardware that adds byteswaps
> > on the bus interface, you typically end up with MMIO registers requiring
> > no swap (or double swap) and readsl()/memcpy_fromio()) suddenly requiring
> > a swap that is counterintuitive.
> 
> Sure, but the __raw_* are used just to be sure there is absolutely no
> swapping.
> E.g. for IXP4xx, the registers never require swapping, thus readl() etc.
> are not suitable for this. What is needed here is simple "atomic" 32-bit
> straight to/from register (MM)IO (assuming 4-byte address alignment).
> 
> If not __raw_* then what?

I would suggest using an ixp4xx specific set of accessors that comes down
to either readl() or ioread32_be(), depending on whether CONFIG_CPU_BIG_ENDIAN
is set. That makes it clear that there is a magic bus involved and that it
works on this platform but not in portable code.

	Arnd


From arnd at arndb.de  Mon Feb 15 12:15:39 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Feb 2016 21:15:39 +0100
Subject: [PATCH] branch tracer: fix freak link error
In-Reply-To: <20160215124746.44e8c2d0@gandalf.local.home>
References: <1455312410-1058841-1-git-send-email-arnd@arndb.de>
 <20160215124746.44e8c2d0@gandalf.local.home>
Message-ID: <2535125.MjntUgx4sh@wuerfel>

On Monday 15 February 2016 12:47:46 Steven Rostedt wrote:
> On Fri, 12 Feb 2016 22:26:42 +0100
> Arnd Bergmann <arnd at arndb.de> wrote:
> 
> > In my randconfig tests, I came across a bug that involves several
> > components:
> > 
> >
> 
> [..]
> 
> > 
> > This patch avoids the problem by changing __trace_if() to check
> > whether the condition is known at compile-time to be nonzero, rather
> > than checking whether it is actually a constant.
> > 
> > I see this one link error in roughly one out of 1600 randconfig builds
> > on ARM, and the patch fixes all known instances.
> > 
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > Fixes: ab3c9c686e22 ("branch tracer, intel-iommu: fix build with CONFIG_BRANCH_TRACER=y")
> 
> Want me to pull this into my queue? I have another patch I need to send
> to Linus and I can add this in that pull request.

That would be nice, yes.

Do you also want to add a 'Cc: stable at vger.kernel.org' tag?

	Arnd


From stefan at agner.ch  Mon Feb 15 19:19:20 2016
From: stefan at agner.ch (Stefan Agner)
Date: Mon, 15 Feb 2016 19:19:20 -0800
Subject: [PATCH] ARM: don't print missing L2 cache as error
In-Reply-To: <1453944439-1070-1-git-send-email-stefan@agner.ch>
References: <1453944439-1070-1-git-send-email-stefan@agner.ch>
Message-ID: <d67716f9edf83700b18532eb66980316@agner.ch>

Hi Russel,

Any comment to this? Currently the kernel prints an error message as
follows on the platform at hand:
[    0.000000] L2C: failed to init: -19

--
Stefan


On 2016-01-27 17:27, Stefan Agner wrote:
> Not having a L2 cache controller is a shame, but not an error. Avoid
> printing an error message if L2 controller initialization returns
> with ENODEV.
> 
> Signed-off-by: Stefan Agner <stefan at agner.ch>
> ---
> Hi Russel,
> 
> We use a multiplatform kernel for two similar SoC's, one with L2
> cache the other without. Maybe silently ignore -ENODEV would be
> an option too, not sure what is preferred here.
> 
> --
> Stefan
> 
>  arch/arm/kernel/irq.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
> index 1d45320e..f80c480 100644
> --- a/arch/arm/kernel/irq.c
> +++ b/arch/arm/kernel/irq.c
> @@ -95,7 +95,9 @@ void __init init_IRQ(void)
>  			outer_cache.write_sec = machine_desc->l2c_write_sec;
>  		ret = l2x0_of_init(machine_desc->l2c_aux_val,
>  				   machine_desc->l2c_aux_mask);
> -		if (ret)
> +		if (ret == -ENODEV)
> +			pr_info("L2C: no device found\n");
> +		else if (ret)
>  			pr_err("L2C: failed to init: %d\n", ret);
>  	}


From shankerd at codeaurora.org  Mon Feb 15 19:41:52 2016
From: shankerd at codeaurora.org (Shanker Donthineni)
Date: Mon, 15 Feb 2016 21:41:52 -0600
Subject: [PATCH] irqchip/gicv3-its: Avoid cache flush beyond ITS_BASERn memory
 size
Message-ID: <1455594112-27783-1-git-send-email-shankerd@codeaurora.org>

Function its_alloc_tables() maintains two local variables, "order" and
and "alloc_size", to hold memory size that has been allocated to
ITS_BASEn. We don't always refresh the variable alloc_size whenever
value of the variable order changes, causing the following two problems.

  - Cache flush operation with size more than required.
  - Information reported by pr_info is not correct.

Use a helper macro that converts page order to size in bytes instead of
variable "alloc_size" to fix both the problems.

Signed-off-by: Shanker Donthineni <shankerd at codeaurora.org>
---
 drivers/irqchip/irq-gic-v3-its.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 0a73632..6f717f7 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -78,6 +78,9 @@ struct its_node {
 
 #define ITS_ITT_ALIGN		SZ_256
 
+/* Convert page order to size in bytes */
+#define PAGE_ORDER_TO_BYTES(o)	(PAGE_SIZE << (o))
+
 struct event_lpi_map {
 	unsigned long		*lpi_map;
 	u16			*col_map;
@@ -846,7 +849,6 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
 		u64 type = GITS_BASER_TYPE(val);
 		u64 entry_size = GITS_BASER_ENTRY_SIZE(val);
 		int order = get_order(psz);
-		int alloc_size;
 		int alloc_pages;
 		u64 tmp;
 		void *base;
@@ -878,9 +880,8 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
 			}
 		}
 
-		alloc_size = (1 << order) * PAGE_SIZE;
 retry_alloc_baser:
-		alloc_pages = (alloc_size / psz);
+		alloc_pages = (PAGE_ORDER_TO_BYTES(order) / psz);
 		if (alloc_pages > GITS_BASER_PAGES_MAX) {
 			alloc_pages = GITS_BASER_PAGES_MAX;
 			order = get_order(GITS_BASER_PAGES_MAX * psz);
@@ -933,7 +934,8 @@ retry_baser:
 			shr = tmp & GITS_BASER_SHAREABILITY_MASK;
 			if (!shr) {
 				cache = GITS_BASER_nC;
-				__flush_dcache_area(base, alloc_size);
+				__flush_dcache_area(base,
+						    PAGE_ORDER_TO_BYTES(order));
 			}
 			goto retry_baser;
 		}
@@ -966,7 +968,7 @@ retry_baser:
 		}
 
 		pr_info("ITS: allocated %d %s @%lx (psz %dK, shr %d)\n",
-			(int)(alloc_size / entry_size),
+			(int)(PAGE_ORDER_TO_BYTES(order) / entry_size),
 			its_base_type_string[type],
 			(unsigned long)virt_to_phys(base),
 			psz / SZ_1K, (int)shr >> GITS_BASER_SHAREABILITY_SHIFT);
-- 
Qualcomm Technologies, Inc. on behalf
of the Qualcomm Innovation Center, Inc.  The Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.



From arnd at arndb.de  Mon Feb 15 01:26:03 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Feb 2016 10:26:03 +0100
Subject: [PATCH] ARM: documentation: update Marvell product listing
In-Reply-To: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <4563969.ihgJV6lDnN@wuerfel>

I'm still getting confused regarding which core specifically
is used in which SoC, so I've added some more detail to the
Marvell README file. I got most of this from random sources
on the internet, so it's possible that some of the information
is wrong, but most of it should be pretty obvious.

There are a few remaining points I could not find out:

* The CPU core in Orion 88F6183
* The difference (if any) between PJ4B-MP and PJ4C
* The naming of Feroceon/Jolteon/Flareon/Sheeva/Mohawk/PJ1/PJ4
  is still confusing, as they tend to overlap.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---


diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index ae89b67d8e23..1f7523df0302 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -22,7 +22,7 @@ Orion family
         88F5281
                Datasheet               : http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf
         88F6183
-  Core: Feroceon ARMv5 compatible
+  Core: Feroceon 88fr331 (88f51xx) or 88fr531-vd (88f52xx) ARMv5 compatible
   Linux kernel mach directory: arch/arm/mach-orion5x
   Linux kernel plat directory: arch/arm/plat-orion
 
@@ -52,7 +52,7 @@ Kirkwood family
                 Hardware Spec  : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
                 Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
   Homepage: http://www.marvell.com/embedded-processors/kirkwood/
-  Core: Feroceon ARMv5 compatible
+  Core: Feroceon 88fr131 ARMv5 compatible
   Linux kernel mach directory: arch/arm/mach-mvebu
   Linux kernel plat directory: none
 
@@ -71,7 +71,7 @@ Discovery family
         MV76100
                 Not supported by the Linux kernel.
 
-  Core: Feroceon ARMv5 compatible
+  Core: Feroceon 88fr571-vd ARMv5 compatible
 
   Linux kernel mach directory: arch/arm/mach-mv78xx0
   Linux kernel plat directory: arch/arm/plat-orion
@@ -86,20 +86,30 @@ EBU Armada family
     Product Brief:   http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
     Hardware Spec:   http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
     Functional Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
+    Core: Sheeva ARMv7 compatible PJ4B
 
   Armada 375 Flavors:
 	88F6720
     Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf
-
-  Armada 380/385 Flavors:
-	88F6810
-	88F6820
-	88F6828
-
-  Armada 390/398 Flavors:
-	88F6920
-	88F6928
+    Core: ARM Cortex-A9
+
+  Armada 38x Flavors:
+	88F6810	Armada 380
+	88F6820 Armada 385
+	88F6828 Armada 388
+    Produce infos: http://www.marvell.com/embedded-processors/armada-38x/
+    Core: ARM Cortex-A9
+
+  Armada 39x Flavors:
+	88F6920 Armada 390
+	88F6928 Armada 398
     Product infos: http://www.marvell.com/embedded-processors/armada-39x/
+    Core: ARM Cortex-A9
+
+  Armada SP:
+	88RC1580
+    Product infos: http://www.marvell.com/embedded-processors/armada-sp/
+    Core: Sheeva ARMv7 comatible Quad-core PJ4C
 
   Armada XP Flavors:
         MV78230
@@ -113,7 +123,7 @@ EBU Armada family
       http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
       http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
 
-  Core: Sheeva ARMv7 compatible
+  Core: Sheeva ARMv7 compatible Dual-core or Quad-core PJ4B-MP
 
   Linux kernel mach directory: arch/arm/mach-mvebu
   Linux kernel plat directory: none
@@ -155,7 +165,7 @@ PXA 2xx/3xx/93x/95x family
   Flavors:
         PXA21x, PXA25x, PXA26x
              Application processor only
-             Core: ARMv5 XScale core
+             Core: ARMv5 XScale1 core
         PXA270, PXA271, PXA272
              Product Brief         : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_pb.pdf
              Design guide          : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_design_guide.pdf
@@ -163,7 +173,7 @@ PXA 2xx/3xx/93x/95x family
              Specification         : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_emts.pdf
              Specification update  : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_spec_update.pdf
              Application processor only
-             Core: ARMv5 XScale core
+             Core: ARMv5 XScale2 core
         PXA300, PXA310, PXA320
              PXA 300 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA300_PB_R4.pdf
              PXA 310 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA310_PB_R4.pdf
@@ -174,10 +184,10 @@ PXA 2xx/3xx/93x/95x family
              Specification Update  : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Spec_Update.zip
              Reference Manual      : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_TavorP_BootROM_Ref_Manual.pdf
              Application processor only
-             Core: ARMv5 XScale core
+             Core: ARMv5 XScale3 core
         PXA930, PXA935
              Application processor with Communication processor
-             Core: ARMv5 XScale core
+             Core: ARMv5 XScale3 core
         PXA955
              Application processor with Communication processor
              Core: ARMv7 compatible Sheeva PJ4 core
@@ -196,7 +206,7 @@ PXA 2xx/3xx/93x/95x family
    Linux kernel mach directory: arch/arm/mach-pxa
    Linux kernel plat directory: arch/arm/plat-pxa
 
-MMP/MMP2 family (communication processor)
+MMP/MMP2/MMP3 family (communication processor)
 -----------------------------------------
 
    Flavors:
@@ -209,16 +219,32 @@ MMP/MMP2 family (communication processor)
              Boot ROM manual      : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_ref_manual.pdf
              App node package     : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_app_note_package.pdf
              Application processor only
-             Core: ARMv5 compatible Marvell PJ1 (Mohawk)
-        PXA910
+             Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
+        PXA910/PXA920
              Homepage             : http://www.marvell.com/communication-processors/pxa910/
              Product Brief        : http://www.marvell.com/communication-processors/pxa910/assets/Marvell_PXA910_Platform-001_PB_final.pdf
              Application processor with Communication processor
-             Core: ARMv5 compatible Marvell PJ1 (Mohawk)
-        MMP2, a.k.a Armada 610
+             Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
+        PXA688, a.k.a. MMP2, a.k.a Armada 610
              Product Brief        : http://www.marvell.com/application-processors/armada-600/assets/armada610_pb.pdf
              Application processor only
-             Core: ARMv7 compatible Sheeva PJ4 core
+             Core: ARMv7 compatible Sheeva PJ4 88sv581x core
+	PXA2128, a.k.a. MMP3 (OLPC XO4, Linux support not upstream)
+	     Product Brief	  : http://www.marvell.com/application-processors/armada/pxa2128/assets/Marvell-ARMADA-PXA2128-SoC-PB.pdf
+	     Application processor only
+	     Core: Dual-core ARMv7 compatible Sheeva PJ4C core
+	PXA960/PXA968/PXA978 (Linux support not upstream)
+	     Application processor with Communication Processor
+	     Core: ARMv7 compatible Sheeva PJ4 core
+	PXA986/PXA988 (Linux support not upstream)
+	     Application processor with Communication Processor
+	     Core: Dual-core ARMv7 compatible Sheeva PJ4B-MP core
+	PXA1088/PXA1920 (Linux support not upstream)
+	     Application processor with Communication Processor
+	     Core: quad-core ARMv7 Cortex-A7
+	PXA1908/PXA1928/PXA1936
+	     Application processor with Communication Processor
+	     Core: multi-core ARMv8 Cortex-A53
 
    Comments:
 
@@ -237,6 +263,10 @@ Berlin family (Multimedia Solutions)
 -------------------------------------
 
   Flavors:
+	88DE3010, Armada 1000 (no Linux support)
+		Core:		Marvell PJ1 (ARMv5TE), Dual-core
+		Product Brief:	http://www.marvell.com.cn/digital-entertainment/assets/armada_1000_pb.pdf
+	88DE3005, Armada 1500-mini
 	88DE3005, Armada 1500 Mini
 		Design name:	BG2CD
 		Core:		ARM Cortex-A9, PL310 L2CC
@@ -247,14 +277,16 @@ Berlin family (Multimedia Solutions)
                 Homepage:       http://www.marvell.com/multimedia-solutions/armada-1500-mini-plus/
 	88DE3100, Armada 1500
 		Design name:	BG2
-		Core:		Marvell PJ4B (ARMv7), Tauros3 L2CC
-		Product Brief:	http://www.marvell.com/multimedia-solutions/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
+		Core:		Marvell PJ4B-MP (ARMv7), Tauros3 L2CC
+		Product Brief:	http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
 	88DE3114, Armada 1500 Pro
 		Design name:	BG2Q
 		Core:		Quad Core ARM Cortex-A9, PL310 L2CC
-	88DE????
+	88DE3214, Armada 1500 Pro 4K
 		Design name:	BG3
 		Core:		ARM Cortex-A15, CA15 integrated L2CC
+	88DE3218, ARMADA 1500 Ultra
+		Core:		ARM Cortex-A53
 
   Homepage: http://www.marvell.com/multimedia-solutions/
   Directory: arch/arm/mach-berlin
@@ -263,6 +295,49 @@ Berlin family (Multimedia Solutions)
    * This line of SoCs is based on Marvell Sheeva or ARM Cortex CPUs
      with Synopsys DesignWare (IRQ, GPIO, Timers, ...) and PXA IP (SDHCI, USB, ETH, ...).
 
+CPU Cores
+---------
+
+The XScale cores were designed by Intel, and shipped by Marvell in the older
+PXA processors. Feroceon is a Marvell designed core that developed in-house,
+and that evolved into Sheeva. The XScale and Feroceon cores were phased out
+over time and replaced with Sheeva cores in later products, which subsequently
+got replaced with licensed ARM Cortex-A cores.
+
+  XScale 1
+	CPUID 0x69052xxx
+	ARMv5, iWMMXt
+  XScale 2
+	CPUID 0x69054xxx
+	ARMv5, iWMMXt
+  XScale 3
+	CPUID 0x69056xxx or 0x69056xxx
+	ARMv5, iWMMXt
+  Feroceon-1850 88fr331 "Mohawk"
+	CPUID 0x5615331x or 0x41xx926x
+	ARMv5TE, single issue
+  Feroceon-2850 88fr531-vd "Jolteon"
+	CPUID 0x5605531x or 0x41xx926x
+	ARMv5TE, VFP, dual-issue
+  Feroceon 88fr571-vd "Jolteon"
+	CPUID 0x5615571x
+	ARMv5TE, VFP, dual-issue
+  Feroceon 88fr131 "Mohawk-D"
+	CPUID 0x5625131x
+	ARMv5TE, single-issue in-order
+  Sheeva PJ1 88sv331 "Mohawk"
+	CPUID 0x561584xx
+	ARMv5, single-issue iWMMXt v2
+  Sheeva PJ4 88sv581x "Flareon"
+	CPUID 0x560f581x
+	ARMv7, idivt, optional iWMMXt v2
+  Sheeva PJ4B 88sv581x
+	CPUID 0x561f581x
+	ARMv7, idivt, optional iWMMXt v2
+  Sheeva PJ4B-MP / PJ4C
+	CPUID 0x562f584x
+	ARMv7, idivt/idiva, LPAE, optional iWMMXt v2 and/or NEON
+
 Long-term plans
 ---------------
 



From wens at csie.org  Mon Feb 15 19:47:19 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue, 16 Feb 2016 11:47:19 +0800
Subject: [PATCH v2 05/10] regulator: axp20x: support AXP809 variant
In-Reply-To: <20160215200439.GC18327@sirena.org.uk>
References: <1455532288-30870-1-git-send-email-wens@csie.org>
 <1455532288-30870-6-git-send-email-wens@csie.org>
 <20160215200439.GC18327@sirena.org.uk>
Message-ID: <CAGb2v671L47bCKowPF7BcjZWGbewLKzg-r+FtFYt3J11YE4KjA@mail.gmail.com>

On Tue, Feb 16, 2016 at 4:04 AM, Mark Brown <broonie at kernel.org> wrote:
> On Mon, Feb 15, 2016 at 06:31:23PM +0800, Chen-Yu Tsai wrote:
>> The X-Powers AXP809 PMIC has a similar set of regulators as the AXP221,
>> though a few LDOs were removed, and a new switch output added. Like the
>> AXP221, AXP809 also has DC1SW and DC5LDO, which are internally chained
>> to DCDC1 and DCDC5, respectively.
>
> This doesn't apply against current code, please check and resend.

This requires mfd/ib-mfd-regulator-4.6 from Lee's tree to apply cleanly,
and "mfd: axp20x: Add support for AXP809 PMIC", which isn't merged yet,
to compile.

ChenYu


From stephanolbrich at gmx.de  Sun Feb 14 02:04:27 2016
From: stephanolbrich at gmx.de (Stephan Olbrich)
Date: Sun, 14 Feb 2016 11:04:27 +0100
Subject: [PATCH v2 0/2] spi: bcm2835aux: auxiliary spi improvements
Message-ID: <1455444269-4797-1-git-send-email-stephanolbrich@gmx.de>

From: Stephan Olbrich <stephanolbrich at gmx.de>

This patch series has some improvements and fixes for the auxiliary spi.

since v1:
- the first two patches "fix bitmask defines" and "disable tx fifo empty irq"
  were picked up by Mark Brown and applied to his spi tree so I don't post
  them again.
- speed bits are now reset before setting the new speed in case the speed
  changes between transfers
- remove CPHA from master->mode_bits
- rename CPHA bit mask to RISING to make it more clear why things are done
  that way

1. set up spi-mode before asserting cs-gpio
 As Martin Sperl suggested this is done in the same way as in spi-bcm2835.c
 acace73df2c1913a526c1b41e4741a4a6704c863

2. fix CPOL/CPHA setting
 From what I've seen in the documentation [1] and seen on the scope this chip
 doesn't support modes with CPHA=1. With this patch spi mode 0 and 2 should
 work correctly whereas mode 1 and 3 are not supported. 
                                                                                                                                                                                                            
Stephan Olbrich (2):
  spi: bcm2835aux: set up spi-mode before asserting cs-gpio
  spi: bcm2835aux: fix CPOL/CPHA setting

 drivers/spi/spi-bcm2835aux.c | 66 +++++++++++++++++++++++++++++---------------
 1 file changed, 44 insertions(+), 22 deletions(-)

-- 
2.5.0



From stephanolbrich at gmx.de  Sun Feb 14 02:04:28 2016
From: stephanolbrich at gmx.de (Stephan Olbrich)
Date: Sun, 14 Feb 2016 11:04:28 +0100
Subject: [PATCH v2 1/2] spi: bcm2835aux: set up spi-mode before asserting
 cs-gpio
In-Reply-To: <1455444269-4797-1-git-send-email-stephanolbrich@gmx.de>
References: <1455444269-4797-1-git-send-email-stephanolbrich@gmx.de>
Message-ID: <1455444269-4797-2-git-send-email-stephanolbrich@gmx.de>

When using reverse polarity for clock (spi-cpol) on a device
the clock line gets altered after chip-select has been asserted
resulting in an additional clock beat, which confuses hardware.

This happens due to the fact, the the hardware was initialized
and reset at the begin and end of each transfer which results
in default state for all lines except chip-select which is
handled by the spi-subsystem as gpio-cs is used.

To avoid this situation this patch moves the setup of polarity
(spi-cpol and spi-cpha) outside of the chip-select into
prepare_message, which is run prior to asserting chip-select.

Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
Reviewed-by: Martin Sperl <kernel at martin.sperl.org>
Tested-by: Martin Sperl <kernel at martin.sperl.org>
---
 drivers/spi/spi-bcm2835aux.c | 57 +++++++++++++++++++++++++++++++-------------
 1 file changed, 41 insertions(+), 16 deletions(-)

diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
index d2f0067..103335e 100644
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -218,9 +218,9 @@ static irqreturn_t bcm2835aux_spi_interrupt(int irq, void *dev_id)
 			BCM2835_AUX_SPI_CNTL1_IDLE);
 	}
 
-	/* and if rx_len is 0 then wake up completion and disable spi */
+	/* and if rx_len is 0 then disable interrupts and wake up completion */
 	if (!bs->rx_len) {
-		bcm2835aux_spi_reset_hw(bs);
+		bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1]);
 		complete(&master->xfer_completion);
 	}
 
@@ -313,9 +313,6 @@ static int bcm2835aux_spi_transfer_one_poll(struct spi_master *master,
 		}
 	}
 
-	/* Transfer complete - reset SPI HW */
-	bcm2835aux_spi_reset_hw(bs);
-
 	/* and return without waiting for completion */
 	return 0;
 }
@@ -336,10 +333,6 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master,
 	 * resulting (potentially) in more interrupts when transferring
 	 * more than 12 bytes
 	 */
-	bs->cntl[0] = BCM2835_AUX_SPI_CNTL0_ENABLE |
-		      BCM2835_AUX_SPI_CNTL0_VAR_WIDTH |
-		      BCM2835_AUX_SPI_CNTL0_MSBF_OUT;
-	bs->cntl[1] = BCM2835_AUX_SPI_CNTL1_MSBF_IN;
 
 	/* set clock */
 	spi_hz = tfr->speed_hz;
@@ -354,17 +347,13 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master,
 	} else { /* the slowest we can go */
 		speed = BCM2835_AUX_SPI_CNTL0_SPEED_MAX;
 	}
+	/* mask out old speed from previous spi_transfer */
+	bs->cntl[0] &= ~(BCM2835_AUX_SPI_CNTL0_SPEED);
+	/* set the new speed */
 	bs->cntl[0] |= speed << BCM2835_AUX_SPI_CNTL0_SPEED_SHIFT;
 
 	spi_used_hz = clk_hz / (2 * (speed + 1));
 
-	/* handle all the modes */
-	if (spi->mode & SPI_CPOL)
-		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPOL;
-	if (spi->mode & SPI_CPHA)
-		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT |
-			       BCM2835_AUX_SPI_CNTL0_CPHA_IN;
-
 	/* set transmit buffers and length */
 	bs->tx_buf = tfr->tx_buf;
 	bs->rx_buf = tfr->rx_buf;
@@ -388,6 +377,40 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master,
 	return bcm2835aux_spi_transfer_one_irq(master, spi, tfr);
 }
 
+static int bcm2835aux_spi_prepare_message(struct spi_master *master,
+					  struct spi_message *msg)
+{
+	struct spi_device *spi = msg->spi;
+	struct bcm2835aux_spi *bs = spi_master_get_devdata(master);
+
+	bs->cntl[0] = BCM2835_AUX_SPI_CNTL0_ENABLE |
+		      BCM2835_AUX_SPI_CNTL0_VAR_WIDTH |
+		      BCM2835_AUX_SPI_CNTL0_MSBF_OUT;
+	bs->cntl[1] = BCM2835_AUX_SPI_CNTL1_MSBF_IN;
+
+	/* handle all the modes */
+	if (spi->mode & SPI_CPOL)
+		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPOL;
+	if (spi->mode & SPI_CPHA)
+		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT |
+			       BCM2835_AUX_SPI_CNTL0_CPHA_IN;
+
+	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1]);
+	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL0, bs->cntl[0]);
+
+	return 0;
+}
+
+static int bcm2835aux_spi_unprepare_message(struct spi_master *master,
+					    struct spi_message *msg)
+{
+	struct bcm2835aux_spi *bs = spi_master_get_devdata(master);
+
+	bcm2835aux_spi_reset_hw(bs);
+
+	return 0;
+}
+
 static void bcm2835aux_spi_handle_err(struct spi_master *master,
 				      struct spi_message *msg)
 {
@@ -416,6 +439,8 @@ static int bcm2835aux_spi_probe(struct platform_device *pdev)
 	master->num_chipselect = -1;
 	master->transfer_one = bcm2835aux_spi_transfer_one;
 	master->handle_err = bcm2835aux_spi_handle_err;
+	master->prepare_message = bcm2835aux_spi_prepare_message;
+	master->unprepare_message = bcm2835aux_spi_unprepare_message;
 	master->dev.of_node = pdev->dev.of_node;
 
 	bs = spi_master_get_devdata(master);
-- 
2.5.0



From stephanolbrich at gmx.de  Sun Feb 14 02:04:29 2016
From: stephanolbrich at gmx.de (Stephan Olbrich)
Date: Sun, 14 Feb 2016 11:04:29 +0100
Subject: [PATCH v2 2/2] spi: bcm2835aux: fix CPOL/CPHA setting
In-Reply-To: <1455444269-4797-1-git-send-email-stephanolbrich@gmx.de>
References: <1455444269-4797-1-git-send-email-stephanolbrich@gmx.de>
Message-ID: <1455444269-4797-3-git-send-email-stephanolbrich@gmx.de>

The auxiliary spi supports only CPHA=0 modes as the first bit is
always output to the pin before the first clock cycle. In CPHA=1
modes the first clock edge outputs the second bit hence the slave
can never read the first bit.

Also the CPHA registers switch between clocking data in/out on
rising/falling edge hence depend on the CPOL setting.

Signed-off-by: Stephan Olbrich <stephanolbrich at gmx.de>
---
 drivers/spi/spi-bcm2835aux.c | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c
index 103335e..7428091 100644
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -64,9 +64,9 @@
 #define BCM2835_AUX_SPI_CNTL0_VAR_WIDTH	0x00004000
 #define BCM2835_AUX_SPI_CNTL0_DOUTHOLD	0x00003000
 #define BCM2835_AUX_SPI_CNTL0_ENABLE	0x00000800
-#define BCM2835_AUX_SPI_CNTL0_CPHA_IN	0x00000400
+#define BCM2835_AUX_SPI_CNTL0_IN_RISING	0x00000400
 #define BCM2835_AUX_SPI_CNTL0_CLEARFIFO	0x00000200
-#define BCM2835_AUX_SPI_CNTL0_CPHA_OUT	0x00000100
+#define BCM2835_AUX_SPI_CNTL0_OUT_RISING	0x00000100
 #define BCM2835_AUX_SPI_CNTL0_CPOL	0x00000080
 #define BCM2835_AUX_SPI_CNTL0_MSBF_OUT	0x00000040
 #define BCM2835_AUX_SPI_CNTL0_SHIFTLEN	0x0000003F
@@ -92,9 +92,6 @@
 #define BCM2835_AUX_SPI_POLLING_LIMIT_US	30
 #define BCM2835_AUX_SPI_POLLING_JIFFIES		2
 
-#define BCM2835_AUX_SPI_MODE_BITS (SPI_CPOL | SPI_CPHA | SPI_CS_HIGH \
-				  | SPI_NO_CS)
-
 struct bcm2835aux_spi {
 	void __iomem *regs;
 	struct clk *clk;
@@ -389,12 +386,12 @@ static int bcm2835aux_spi_prepare_message(struct spi_master *master,
 	bs->cntl[1] = BCM2835_AUX_SPI_CNTL1_MSBF_IN;
 
 	/* handle all the modes */
-	if (spi->mode & SPI_CPOL)
+	if (spi->mode & SPI_CPOL) {
 		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPOL;
-	if (spi->mode & SPI_CPHA)
-		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_CPHA_OUT |
-			       BCM2835_AUX_SPI_CNTL0_CPHA_IN;
-
+		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_OUT_RISING;
+	} else {
+		bs->cntl[0] |= BCM2835_AUX_SPI_CNTL0_IN_RISING;
+	}
 	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL1, bs->cntl[1]);
 	bcm2835aux_wr(bs, BCM2835_AUX_SPI_CNTL0, bs->cntl[0]);
 
@@ -434,7 +431,7 @@ static int bcm2835aux_spi_probe(struct platform_device *pdev)
 	}
 
 	platform_set_drvdata(pdev, master);
-	master->mode_bits = BCM2835_AUX_SPI_MODE_BITS;
+	master->mode_bits = (SPI_CPOL | SPI_CS_HIGH | SPI_NO_CS);
 	master->bits_per_word_mask = SPI_BPW_MASK(8);
 	master->num_chipselect = -1;
 	master->transfer_one = bcm2835aux_spi_transfer_one;
-- 
2.5.0



From arnd at arndb.de  Mon Feb 15 01:20:49 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Feb 2016 10:20:49 +0100
Subject: [PATCH] iio: health/afe4403: mark suspend/resume functions
 __maybe_unused
In-Reply-To: <CAEnQRZBSYy2inu0mUtXEdhEKWQj5i-YUFDL61prvC_8P_L0adQ@mail.gmail.com>
References: <1455526993-2132098-1-git-send-email-arnd@arndb.de>
 <CAEnQRZBSYy2inu0mUtXEdhEKWQj5i-YUFDL61prvC_8P_L0adQ@mail.gmail.com>
Message-ID: <3204595.MT2N1UgYF8@wuerfel>

On Monday 15 February 2016 11:18:20 Daniel Baluta wrote:
> On Mon, Feb 15, 2016 at 11:02 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> > The newly added afe4403 driver implements suspend/resume using the
> > SIMPLE_DEV_PM_OPS() macro, which leaves out references to the actual
> > functions when CONFIG_PM is disabled, causing a harmless warning:
> >
> > health/afe4403.c:509:12: error: 'afe4403_suspend' defined but not used
> > health/afe4403.c:530:12: error: 'afe4403_resume' defined but not used
> >
> > This marks the functions as __maybe_unused so we don't get those
> > warnings.
> >
> Or we could put _suspend and _resume under CONFIG_PM_SLEEP.

That never works reliably. I still have a backlog of ~50 patches
of drivers that got this wrong in the past.

> We have:
> 
> :~/w/iio/drivers/iio$ ack-grep SIMPLE_DEV_PM_OPS | wc -l
> 31
> 
> and only 2 drivers using __maybe_unused.
> 
> :~/w/iio/drivers/iio$ ack-grep maybe_unused
> gyro/itg3200_core.c
> 354:static int __maybe_unused itg3200_suspend(struct device *dev)
> 365:static int __maybe_unused itg3200_resume(struct device *dev)
> 
> adc/imx7d_adc.c
> 553:static int __maybe_unused imx7d_adc_suspend(struct device *dev)
> 566:static int __maybe_unused imx7d_adc_resume(struct device *dev)
> 
> For consistency, we should use CONFIG_PM_SLEEP and get rid of __maybe_unused.

I hope to eventually kill off all the CONFIG_PM_SLEEP checks and then
make it work automatically by redefining SIMPLE_DEV_PM_OPS so it
leaves an unused reference to the functions.

	Arnd


From arnd at arndb.de  Mon Feb 15 01:02:51 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Feb 2016 10:02:51 +0100
Subject: [PATCH] iio: health/afe4403: mark suspend/resume functions
 __maybe_unused
Message-ID: <1455526993-2132098-1-git-send-email-arnd@arndb.de>

The newly added afe4403 driver implements suspend/resume using the
SIMPLE_DEV_PM_OPS() macro, which leaves out references to the actual
functions when CONFIG_PM is disabled, causing a harmless warning:

health/afe4403.c:509:12: error: 'afe4403_suspend' defined but not used
health/afe4403.c:530:12: error: 'afe4403_resume' defined but not used

This marks the functions as __maybe_unused so we don't get those
warnings.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: eec96d1e2d31 ("iio: health: Add driver for the TI AFE4403 heart monitor")
---
 drivers/iio/health/afe4403.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/health/afe4403.c b/drivers/iio/health/afe4403.c
index 91c046e40d2f..88e43f87b926 100644
--- a/drivers/iio/health/afe4403.c
+++ b/drivers/iio/health/afe4403.c
@@ -506,7 +506,7 @@ static const struct of_device_id afe4403_of_match[] = {
 MODULE_DEVICE_TABLE(of, afe4403_of_match);
 #endif
 
-static int afe4403_suspend(struct device *dev)
+static int __maybe_unused afe4403_suspend(struct device *dev)
 {
 	struct iio_dev *indio_dev = dev_to_iio_dev(dev);
 	struct afe4403_data *afe = iio_priv(indio_dev);
@@ -527,7 +527,7 @@ static int afe4403_suspend(struct device *dev)
 	return 0;
 }
 
-static int afe4403_resume(struct device *dev)
+static int __maybe_unused afe4403_resume(struct device *dev)
 {
 	struct iio_dev *indio_dev = dev_to_iio_dev(dev);
 	struct afe4403_data *afe = iio_priv(indio_dev);
-- 
2.7.0



From stefan.wahren at i2se.com  Sat Feb 13 12:45:12 2016
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 13 Feb 2016 21:45:12 +0100 (CET)
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in
 console
In-Reply-To: <EE05C090-EB8A-41E8-B9C3-8CCC79F15FE9@martin.sperl.org>
References: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
 <56BC895E.2010108@sperl.org>
 <1617009200.323700.219000a8-c162-4594-aacc-a7e9894518b2.open-xchange@email.1und1.de>
 <662D2FB2-B088-4CFC-8416-A4F35BBAD7DD@sperl.org>
 <F7A2533A-D64C-4187-ABD4-416C446D1637@martin.sperl.org>
 <6CD3FC59-BA17-43D9-897C-A2D122D26EF8@martin.sperl.org>
 <470852136.382408.76a8faee-9235-4ee0-9fd1-e25a1e9f0bb3.open-xchange@email.1und1.de>
 <EE05C090-EB8A-41E8-B9C3-8CCC79F15FE9@martin.sperl.org>
Message-ID: <359843746.379810.6eb6c2f5-8282-417a-83d1-1fa79425ff73.open-xchange@email.1und1.de>

Hi Martin,

> Martin Sperl <kernel at martin.sperl.org> hat am 13. Februar 2016 um 12:53
> geschrieben:
>
>
> Seems as if you apply it on top of (parts of) my patchset - not on top of a
> clean 4.5-rc3.

sorry about that. I took the wrong directory.

>
> Anyway - after some fixing I get the following outputs -
> the amba-pl011 driver is still patched with debug messages:
>
> After boot with aux-uart as tty:
> root at raspcm:~# dmesg | grep bcm2835
> [ 0.018172] bcm2835: system timer (irq = 27)
> [ 0.711388] bcm2835-aux-uart 20215040.serial: could not get clk: -517
> [ 1.649124] bcm2835-rng 20104000.rng: hwrng registered
> [ 2.051190] bcm2835_clock_on: clk still busy from 6
> [ 2.056159] bcm2835_clock_on: clk now busy from 9

I get the same output here. It belongs to mmc clock.

> [ 8.062743] bcm2835-wdt 20100000.watchdog: Broadcom BCM2835 watchdog timer
> [ 12.042105] bcm2835-i2s 20203000.i2s: can't request region for resource [mem
> 0x20101098-0x20101099]
> [ 12.191701] bcm2835-i2s: probe of 20203000.i2s failed with error -16
>
> Loading the module:
> root at raspcm:~# modprobe amba-pl011
> [ 106.685812] Serial: AMBA PL011 UART driver
> [ 106.693702] uart-pl011 20201000.uart: pl011_setup_port: f0201000 20201000
> [ 106.702109] 20201000.uart: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud =
> 0) is a PL011 rev2
> root at raspcm:~#
>
> and starting getty:
> root at raspcm:~# /sbin/getty -a root -L ttyAMA0 115200 vt100
> [ 137.851123] pl011_startup - start
> [ 137.854538] pl011_hwinit - prepare-enable
> [ 137.858772] bcm2835_clock_on: clk still busy from 6
> [ 137.863755] bcm2835_clock_on: clk now busy from 9
> [ 137.868590] pl011_hwinit - prepare-enable - ret = 0
> [ 137.875249] uart-pl011 20201000.uart: no DMA platform data
> [ 137.880940] pl011_startup - exit
> [ 137.888840] pl011_shutdown - start
> [ 137.892360] pl011_shutdown - disable_unprepare
> [ 137.896933] bcm2835_clock_off: clk still busy from 9
> [ 137.902112] pl011_shutdown - exit
> [ 137.907233] pl011_startup - start
> [ 137.910713] pl011_hwinit - prepare-enable
> [ 137.914808] bcm2835_pll_on: PLL still locked from 1
> [ 138.019876] bcm2835-clk 20101000.cprman: plld: couldn't lock PLL
> [ 138.026000] pl011_hwinit - prepare-enable - ret = -110
> [ 138.031266] pl011_startup - error = -110 - disable_unprepare
> [ 138.037048] ------------[ cut here ]------------
> [ 138.041777] WARNING: CPU: 0 PID: 2377 at drivers/clk/clk.c:680
> clk_core_disable+0x34/0xf0()
> [ 138.051063] ---[ end trace dd2f225b2af4c32c ]---
> [ 138.055859] ------------[ cut here ]------------
> [ 138.060627] WARNING: CPU: 0 PID: 2377 at drivers/clk/clk.c:575
> clk_core_unprepare+0x34/0x110()
> [ 138.070321] ---[ end trace dd2f225b2af4c32d ]---
>
> No HDMI output - this time no ?flashing? - just no signal.
> Machine is crashed - the attached AXIS USB network card (0b95:772b)
> just transmits identical packets on the network without stopping?
>

According to the datasheet busy bit shouldn't be set while changing the clock.
So this isn't good. I hope this could be fixed, too.

Regards

>


From arnd at arndb.de  Mon Feb 15 01:24:29 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Feb 2016 10:24:29 +0100
Subject: [PATCH 0/5] arm64: Initial support for Marvell Armada 7K/8K
In-Reply-To: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <2808783.Lm9AZL1OAe@wuerfel>

On Monday 15 February 2016 09:47:40 Thomas Petazzoni wrote:
> Hello,
> 
> This series adds initial support for the new Armada 7K and 8K Marvell
> 64 bits processors. Details about those processors based on the
> Cortex-A72 can be found at:
> 
>   http://www.marvell.com/embedded-processors/armada-70xx/
>   http://www.marvell.com/embedded-processors/armada-80xx/
> 
> One characteristic of those processors is that internally they are
> built from several components:
> 
>  - One "AP", which contains the processor itself and a few core IP
>    blocks. The AP in 7K and 8K is called AP806, and is available on
>    two variants: dual Cortex-A72 and quad Cortex-A72.
> 
>  - Or or two "CP", which contains most of the I/Os (SATA, PCIe,
>    etc.). The CP in 7K and 8K is called CP110. One CP110 is available
>    in the 7K family, while two CP110 are available in the 8K family,
>    doubling the number of I/O interfaces.
> 
> The support added in this series only brings minimal support for the
> AP side (and not yet all IP blocks, obviously). Support for the CP
> part will come in the future.
> 
> Since the series touches similar files as the Armada 3700 series from
> Gregory Clement, it is based on it.

The new code looks ok, but I think I need to resubmit my cleanup of the
Documentation/arm/Marvell/README fiel that I submitted a while ago,
which now conflicts with the changes you did in patch 3.

If you don't mind, can you add my patch to your series to resolve
the conflict? I'll resend in a minute.

	Arnd


From arnd at arndb.de  Mon Feb 15 01:19:04 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Feb 2016 10:19:04 +0100
Subject: [PATCH] iio: health/afe4404: mark suspend/resume functions
 __maybe_unused
Message-ID: <1455527958-2647084-1-git-send-email-arnd@arndb.de>

The newly added afe4404 driver implements suspend/resume using the
SIMPLE_DEV_PM_OPS() macro, which leaves out references to the actual
functions when CONFIG_PM is disabled, causing a harmless warning:

health/afe4404.c:509:12: error: 'afe4404_suspend' defined but not used
health/afe4404.c:530:12: error: 'afe4404_resume' defined but not used

This marks the functions as __maybe_unused so we don't get those
warnings.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 87aec56e27ef ("iio: health: Add driver for the TI AFE4404 heart monitor")
---
 drivers/iio/health/afe4404.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/health/afe4404.c b/drivers/iio/health/afe4404.c
index 0759268f37e0..5096a4643784 100644
--- a/drivers/iio/health/afe4404.c
+++ b/drivers/iio/health/afe4404.c
@@ -477,7 +477,7 @@ static const struct of_device_id afe4404_of_match[] = {
 MODULE_DEVICE_TABLE(of, afe4404_of_match);
 #endif
 
-static int afe4404_suspend(struct device *dev)
+static int __maybe_unused afe4404_suspend(struct device *dev)
 {
 	struct iio_dev *indio_dev = dev_to_iio_dev(dev);
 	struct afe4404_data *afe = iio_priv(indio_dev);
@@ -498,7 +498,7 @@ static int afe4404_suspend(struct device *dev)
 	return 0;
 }
 
-static int afe4404_resume(struct device *dev)
+static int __maybe_unused afe4404_resume(struct device *dev)
 {
 	struct iio_dev *indio_dev = dev_to_iio_dev(dev);
 	struct afe4404_data *afe = iio_priv(indio_dev);
-- 
2.7.0



From arnd at arndb.de  Mon Feb 15 01:33:08 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Feb 2016 10:33:08 +0100
Subject: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
In-Reply-To: <m3a8n2bf72.fsf@t19.piap.pl>
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <2202960.HHsdV23CYi@wuerfel> <m3a8n2bf72.fsf@t19.piap.pl>
Message-ID: <2926427.2IOxhm2GZo@wuerfel>

On Monday 15 February 2016 08:33:37 Krzysztof Ha?asa wrote:
> Arnd Bergmann <arnd at arndb.de> writes:
> 
> >> Anyway, I think readl()/writel() do the right thing: in BE mode they
> >> swap PCI accesses and don't swap normal registers, in LE mode nothing is
> >> swapped.
> >
> > This seems to be true when CONFIG_IXP4XX_INDIRECT_PCI is set, but
> > not otherwise. For the indirect variant, writel() is a __raw_writel()
> > without barrier or byteswap on non-PCI memory, while with that
> > option disabled, we use the standard implementation that has both
> > a byteswap and a barrier.
> >
> > According to your description, that would mean the version without
> > indirect PCI access is broken and it appears to have been that way
> > since before the start of git history in 2.6.12.
> >
> > It's possible that nobody cared because all drivers for non-PCI
> > devices on ixp4xx (the on chip ones) just use __raw_readl or
> > direct pointer references.
> 
> Well, it is possible. I recall I probably used __raw_* instead of
> readl()/writel() in qmgr/npe/Ethernet drivers for this very reason.
> 
> I think Direct pointer references are only used for locations in RAM
> (DMA buffers), they have their own share of problems because the
> peripherals are always big endian.
> 
> I think I still have an early IXP425 board with UDC connector so I will
> try to dig it up and test this code.
> 
> I wonder if we should switch the driver to use __raw_*, too. The problem
> is almost nobody uses UDC with this CPU.
> 

I consider the use of __raw_* accessors a bug, I don't think we should
ever do that because it hides how the hardware actually works, it doesn't
work with spinlocks, and it can lead to the compiler splitting up accesses
into byte sized ones (not on ARM with the current definition, but
possible in general).

Almost all hardware is fixed-endian, so you have to use swapping accessors
when the CPU is the other way, except for device RAM and FIFO registers
that are always used to transfer a byte stream (see the definition of
readsl() and memcpy_fromio()). When you have hardware that adds byteswaps
on the bus interface, you typically end up with MMIO registers requiring
no swap (or double swap) and readsl()/memcpy_fromio()) suddenly requiring
a swap that is counterintuitive.

	Arnd


From raveendra.padasalagi at broadcom.com  Mon Feb 15 20:24:56 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Tue, 16 Feb 2016 09:54:56 +0530
Subject: [PATCH 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <20160212150430.GA15049@rob-hp-laptop>
References: <1455008277-8312-1-git-send-email-raveendra.padasalagi@broadcom.com>
 <1455008277-8312-2-git-send-email-raveendra.padasalagi@broadcom.com>
 <2631849.GeOulu78vx@wuerfel> <3b53af6b6c6735d10cb88518c8b8a0ae@mail.gmail.com>
 <20160209174351.GC40460@dtor-ws>
 <979fb4dc5fba643a6780759d2a13530a@mail.gmail.com>
 <20160212150430.GA15049@rob-hp-laptop>
Message-ID: <766ebcaceac5e04307b48527eaeefb90@mail.gmail.com>

> -----Original Message-----
> From: Rob Herring [mailto:robh at kernel.org]
> Sent: 12 February 2016 20:35
> To: Raveendra Padasalagi
> Cc: Dmitry Torokhov; Arnd Bergmann; Russell King;
devicetree at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org; linux-input at vger.kernel.org; Pawel
Moll;
> Mark Rutland; Ian Campbell; Kumar Gala; Jonathan Richardson; Jon Mason;
> Florian Fainelli; Ray Jui; Scott Branden; linux-kernel at vger.kernel.org;
bcm-
> kernel-feedback-list at broadcom.com
> Subject: Re: [PATCH 1/3] input: cygnus-update touchscreen dt node
document
>
> Your mailer is not handling wrapping correctly. Generally, Outlook does
not
> work for maillists.
>
> On Wed, Feb 10, 2016 at 10:24:43AM +0530, Raveendra Padasalagi wrote:
> > > -----Original Message-----
> > > From: Dmitry Torokhov [mailto:dmitry.torokhov at gmail.com]
> > > Sent: 09 February 2016 23:14
> > > To: Raveendra Padasalagi
> > > Cc: Arnd Bergmann; Russell King; devicetree at vger.kernel.org;
> > > linux-arm- kernel at lists.infradead.org; linux-input at vger.kernel.org;
> > > Rob Herring;
> > Pawel
> > > Moll; Mark Rutland; Ian Campbell; Kumar Gala; Jonathan Richardson;
> > > Jon Mason; Florian Fainelli; Ray Jui; Scott Branden;
> > linux-kernel at vger.kernel.org;
> > > bcm-kernel-feedback-list at broadcom.com
> > > Subject: Re: [PATCH 1/3] input: cygnus-update touchscreen dt node
> > document
>
> And Outlook's reply header is non-standard.
>
> [...]
>
> > > > In Cygnus SOC, Touch screen controller registers are shared with
> > > > ADC and flex timer IP's.
> > > > Using readl/writel could lead to race condition. So this patch is
> > > > introduced to take care mutually exclusive access of register's in
> > > > such a case.
> > > >
> > > > In the platform's where touchscreen register's are not shared
> > > > normal readl/writel could be used.
> > >
> > > Are there currently platforms where the registers are not shared? If
> > > we
> > have to
> > > use regmap to correctly update registers (and thus we need
> > > syscon) then I wonder if we should even attempt to support direct
> > register
> > > access by the driver.
> >
> > Currently there are no platforms without register sharing, but we
> > would like to keep the driver generic enough to take care of future
> > SOC's if comes with dedicated registers and same touchscreen IP being
> > re-used.
>
> These future SoCs will have a different compatible string and you should
use that
> to determine whether reg or syscon is used.

Thanks Rob. I will address this in the next patch.

> Rob


From arnd at arndb.de  Mon Feb 15 01:42:38 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 15 Feb 2016 10:42:38 +0100
Subject: [PATCH 0/5] arm64: Initial support for Marvell Armada 7K/8K
In-Reply-To: <20160215103712.55c09f47@free-electrons.com>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <2808783.Lm9AZL1OAe@wuerfel> <20160215103712.55c09f47@free-electrons.com>
Message-ID: <3657138.C90eaYQVKB@wuerfel>

On Monday 15 February 2016 10:37:12 Thomas Petazzoni wrote:
> Arnd,
> 
> On Mon, 15 Feb 2016 10:24:29 +0100, Arnd Bergmann wrote:
> 
> > The new code looks ok, but I think I need to resubmit my cleanup of the
> > Documentation/arm/Marvell/README fiel that I submitted a while ago,
> > which now conflicts with the changes you did in patch 3.
> > 
> > If you don't mind, can you add my patch to your series to resolve
> > the conflict? I'll resend in a minute.
> 
> Before my series, Gregory's series is already doing some changes to the
> Marvell README file, though it is possible that they don't conflict
> with your changes. Anyway, we'll take care of merging your file, I'll
> sync with Gregory on this.
> 

Ok, thanks!

	Arnd


From eun.taik.lee at samsung.com  Mon Feb 15 20:44:38 2016
From: eun.taik.lee at samsung.com (EunTaik Lee)
Date: Tue, 16 Feb 2016 04:44:38 +0000 (GMT)
Subject: [PATCH v2] arm64: add alignment fault hanling
Message-ID: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>

Userspace memory is mapped as below:
F2A7F000--F2A7FFFF Normal Memory
F2A80000--F2A80FFF Device nGnRnE

And that userspace application makes a system call
as below:

-009 |do_strncpy_from_user(inline)
-009 |strncpy_from_user()
-010 |getname_flags()
-011 |user_path_at_empty()
-012 |user_path_at()
-013 |SYSC_faccessat(inline)
-013 |sys_faccessat()
-014 |__sys_trace(asm)
 --> |exception

The string spans from 0xF2A7FFC1 to 0xF2A7FFFB.

When do_strncpy_from_user() reads the last (unsigned long)
value, the alignement fault is triggered. The 8 byte
from 0xF2A7FFC1 spans to the next page that is mapped as
Device nGnRnE, which does not allow an unaligned access,
causes the abort.

The instruction which caused the alignment fault is registered
in the fixup table but the exception handler does not reach there.

This patch registers a alignment fault handler and fixes up the
pc if appropriate.

Signed-off-by: Eun Taik Lee <eun.taik.lee at samsung.com>
---

changes in v2 : call do_bad_area() instead of calling
 fix_up_exception directly.

 arch/arm64/mm/fault.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 19211c4..a5ebb99 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -371,6 +371,14 @@ static int __kprobes do_translation_fault(unsigned long addr,
 	return 0;
 }
 
+static int __kprobes do_alignment_fault(unsigned long addr,
+					  unsigned int esr,
+					  struct pt_regs *regs)
+{
+	do_bad_area(addr, esr, regs);
+	return 0;
+}
+
 /*
  * This abort handler always returns "fault".
  */
@@ -418,7 +426,7 @@ static struct fault_info {
 	{ do_bad,		SIGBUS,  0,		"synchronous parity error (translation table walk" },
 	{ do_bad,		SIGBUS,  0,		"synchronous parity error (translation table walk" },
 	{ do_bad,		SIGBUS,  0,		"unknown 32"			},
-	{ do_bad,		SIGBUS,  BUS_ADRALN,	"alignment fault"		},
+	{ do_alignment_fault,	SIGBUS,  BUS_ADRALN,	"alignment fault"		},
 	{ do_bad,		SIGBUS,  0,		"debug event"			},
 	{ do_bad,		SIGBUS,  0,		"unknown 35"			},
 	{ do_bad,		SIGBUS,  0,		"unknown 36"			},
-- 
1.9.1

From k.kozlowski at samsung.com  Mon Feb 15 20:59:14 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 16 Feb 2016 13:59:14 +0900
Subject: [PATCH v2] clk: Move vendor's Kconfig into CCF menu section
In-Reply-To: <1453971537-5510-1-git-send-email-jamesjj.liao@mediatek.com>
References: <1453971537-5510-1-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <CAJKOXPdA1VeGUmgAtObueXbY5S_X0acrF5m_QnEygzaMOeWPUw@mail.gmail.com>

2016-01-28 17:58 GMT+09:00 James Liao <jamesjj.liao at mediatek.com>:
> Move all vendor's Kconfig into CCF menu section to prevent
> new drivers putting their Kconfig files in a wrong place.
>
> Some Kconigs need to modify at the same time to avoid build
> warnings.
>
> Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
> ---
> This patch is based on v4.5-rc1.
>
> changes since v1:
> - Modify s3c24xx and samsung's Kconfig to avoid build warngings.
>
>  arch/arm/mach-s3c24xx/Kconfig | 1 +
>  drivers/clk/Kconfig           | 8 +++-----
>  drivers/clk/samsung/Kconfig   | 1 -
>  3 files changed, 4 insertions(+), 6 deletions(-)
>

I wish you had used scripts/get_maintainer.pl to get list of people to CC...
Kukjin Kim <kgene at kernel.org> (maintainer:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES)
Krzysztof Kozlowski <k.kozlowski at samsung.com> (maintainer:ARM/SAMSUNG
EXYNOS ARM ARCHITECTURES)
linux-samsung-soc at vger.kernel.org (moderated list:ARM/SAMSUNG EXYNOS
ARM ARCHITECTURES)

Beside the fact that it is just nice and welcomed... it would help me
to avoid some of duplicated work...

Best regards,
Krzysztof


From maitysanchayan at gmail.com  Mon Feb 15 21:00:52 2016
From: maitysanchayan at gmail.com (Sanchayan Maity)
Date: Tue, 16 Feb 2016 10:30:52 +0530
Subject: [PATCH v3 0/3] Allow iio_hwmon to accept hypen in node names
Message-ID: <cover.1455597464.git.maitysanchayan@gmail.com>

Hello,

Initial versions of the patchset intended to introduce the use of
iio_hwmon for Vybrid SoC's. Currently the iio_hwmon driver has two
users and as per the binding documentation, the node names use the
underscore. Use of hypen in device tree node names is acceptable,
however currently the hwmon core code rejects it due to perhaps user
space not liking the hypen and getting confused.

As per Guenter Roeck's suggestion, the first patch looks for a hypen
and replaces it with a underscore in the probe call of iio_hwmon driver
before calling hwmon_device_register_with_groups for registration. Any
users of iio_hwmon driver can now use hypen in the node name.

As per Shawn's suggestion, the existing users have been changed to use
the hypen instead of the underscore and the iio-bindings document
updated. Third patch introduces the usage for Vybrid itself.

Patchset is based on top of shawn's for-next branch.

Feedbacks and comments most welcome. Thank you for feedbacks.

@Guenter
I hope I understood and implemented correctly what you had in mind.

Sample Output from Toradex Colibri VF50 module
root at colibri-vf:/sys/class/hwmon/hwmon0# ls
device       name         of_node      power        subsystem    temp1_input  temp2_input  uevent
root at colibri-vf:/sys/class/hwmon/hwmon0# cat name
iio_hwmon
root at colibri-vf:/sys/class/hwmon/hwmon0# uname -a
Linux colibri-vf 4.5.0-rc1-12868-g88b677c #48 SMP Tue Feb 16 10:05:28 IST 2016 armv7l GNU/Linux

v1:
https://lkml.org/lkml/2015/9/16/932

v2:
https://lkml.org/lkml/2016/2/12/168

Thanks & Regards,
Sanchayan Maity.

Sanchayan Maity (3):
  hwmon: iio_hwmon: Allow the driver to accept hypen in device tree node names
  ARM: dts: Change iio_hwmon nodes to use hypen in node names
  ARM: dts: vfxxx: Add iio_hwmon node for ADC temperature channel

 Documentation/devicetree/bindings/iio/iio-bindings.txt |  2 +-
 arch/arm/boot/dts/imx23.dtsi                           |  2 +-
 arch/arm/boot/dts/imx28.dtsi                           |  2 +-
 arch/arm/boot/dts/vfxxx.dtsi                           |  5 +++++
 drivers/hwmon/iio_hwmon.c                              | 11 ++++++++++-
 5 files changed, 18 insertions(+), 4 deletions(-)

-- 
2.7.1



From maitysanchayan at gmail.com  Mon Feb 15 21:00:53 2016
From: maitysanchayan at gmail.com (Sanchayan Maity)
Date: Tue, 16 Feb 2016 10:30:53 +0530
Subject: [PATCH v3 1/3] hwmon: iio_hwmon: Allow the driver to accept hypen in
 device tree node names
In-Reply-To: <cover.1455597464.git.maitysanchayan@gmail.com>
References: <cover.1455597464.git.maitysanchayan@gmail.com>
Message-ID: <cca90e7d9b8fae5da5b186ae80b7081a8b6d3645.1455597464.git.maitysanchayan@gmail.com>

Currently the driver calls hwmon_device_register_with_groups which
does not accept hypen in node name and returns EINVAL. Use of hypen
in device tree node name results in probe failure., however use of
hypen in device tree node name is perfectly acceptable.

Change this by allocating a duplicate managed string, replacing
hypen with underscore and then calling hwmon_device_register_with_groups.
This allows the use of hypen in device tree node name while maintaining
backwards compatibility and preventing any possible regressions with
user space.

Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
---
 drivers/hwmon/iio_hwmon.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/iio_hwmon.c b/drivers/hwmon/iio_hwmon.c
index 17ae2eb..b550ba5 100644
--- a/drivers/hwmon/iio_hwmon.c
+++ b/drivers/hwmon/iio_hwmon.c
@@ -67,6 +67,7 @@ static int iio_hwmon_probe(struct platform_device *pdev)
 	enum iio_chan_type type;
 	struct iio_channel *channels;
 	const char *name = "iio_hwmon";
+	char *sname;
 
 	if (dev->of_node && dev->of_node->name)
 		name = dev->of_node->name;
@@ -144,7 +145,15 @@ static int iio_hwmon_probe(struct platform_device *pdev)
 
 	st->attr_group.attrs = st->attrs;
 	st->groups[0] = &st->attr_group;
-	st->hwmon_dev = hwmon_device_register_with_groups(dev, name, st,
+
+	sname = devm_kstrdup(dev, name, GFP_KERNEL);
+	if (!sname) {
+		ret = -ENOMEM;
+		goto error_release_channels;
+	}
+
+	strreplace(sname, '-', '_');
+	st->hwmon_dev = hwmon_device_register_with_groups(dev, sname, st,
 							  st->groups);
 	if (IS_ERR(st->hwmon_dev)) {
 		ret = PTR_ERR(st->hwmon_dev);
-- 
2.7.1



From maitysanchayan at gmail.com  Mon Feb 15 21:00:54 2016
From: maitysanchayan at gmail.com (Sanchayan Maity)
Date: Tue, 16 Feb 2016 10:30:54 +0530
Subject: [PATCH v3 2/3] ARM: dts: Change iio_hwmon nodes to use hypen in node
 names
In-Reply-To: <cover.1455597464.git.maitysanchayan@gmail.com>
References: <cover.1455597464.git.maitysanchayan@gmail.com>
Message-ID: <c47b13603fe72737ef67ed8b90fc61516cfa2a20.1455597464.git.maitysanchayan@gmail.com>

Change iio_hwmon nodes to use hypen in node names instead of
underscore.

Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
---
 Documentation/devicetree/bindings/iio/iio-bindings.txt | 2 +-
 arch/arm/boot/dts/imx23.dtsi                           | 2 +-
 arch/arm/boot/dts/imx28.dtsi                           | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt b/Documentation/devicetree/bindings/iio/iio-bindings.txt
index 0b447d9..68d6f8c 100644
--- a/Documentation/devicetree/bindings/iio/iio-bindings.txt
+++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
@@ -82,7 +82,7 @@ vdd channel is connected to output 0 of the &ref device.
 
 	...
 
-	iio_hwmon {
+	iio-hwmon {
 		compatible = "iio-hwmon";
 		io-channels = <&adc 0>, <&adc 1>, <&adc 2>,
 			<&adc 3>, <&adc 4>, <&adc 5>,
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 1c6c075..302d116 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -569,7 +569,7 @@
 		};
 	};
 
-	iio_hwmon {
+	iio-hwmon {
 		compatible = "iio-hwmon";
 		io-channels = <&lradc 8>;
 	};
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index fae7b90..f637ec9 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -1256,7 +1256,7 @@
 		};
 	};
 
-	iio_hwmon {
+	iio-hwmon {
 		compatible = "iio-hwmon";
 		io-channels = <&lradc 8>;
 	};
-- 
2.7.1



From maitysanchayan at gmail.com  Mon Feb 15 21:00:55 2016
From: maitysanchayan at gmail.com (Sanchayan Maity)
Date: Tue, 16 Feb 2016 10:30:55 +0530
Subject: [PATCH v3 3/3] ARM: dts: vfxxx: Add iio_hwmon node for ADC
 temperature channel
In-Reply-To: <cover.1455597464.git.maitysanchayan@gmail.com>
References: <cover.1455597464.git.maitysanchayan@gmail.com>
Message-ID: <88b677c3ab62d965b70846618fe566523f95c9bb.1455597464.git.maitysanchayan@gmail.com>

Add iio-hwmon node to expose the temperature channel on Vybrid as
hardware monitor device using the iio_hwmon driver.

Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
---
 arch/arm/boot/dts/vfxxx.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index a5f07e3..24ac5b1 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -673,5 +673,10 @@
 				status = "disabled";
 			};
 		};
+
+		iio-hwmon {
+			compatible = "iio-hwmon";
+			io-channels = <&adc0 16>, <&adc1 16>;
+		};
 	};
 };
-- 
2.7.1



From stefan.wahren at i2se.com  Sat Feb 13 02:01:20 2016
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sat, 13 Feb 2016 11:01:20 +0100 (CET)
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in
 console
In-Reply-To: <6CD3FC59-BA17-43D9-897C-A2D122D26EF8@martin.sperl.org>
References: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
 <56BC895E.2010108@sperl.org>
 <1617009200.323700.219000a8-c162-4594-aacc-a7e9894518b2.open-xchange@email.1und1.de>
 <662D2FB2-B088-4CFC-8416-A4F35BBAD7DD@sperl.org>
 <F7A2533A-D64C-4187-ABD4-416C446D1637@martin.sperl.org>
 <6CD3FC59-BA17-43D9-897C-A2D122D26EF8@martin.sperl.org>
Message-ID: <470852136.382408.76a8faee-9235-4ee0-9fd1-e25a1e9f0bb3.open-xchange@email.1und1.de>

Hi Martin,

> Martin Sperl <kernel at martin.sperl.org> hat am 12. Februar 2016 um 20:44
> geschrieben:
>
> So the issue is triggered as soon as the plld_per
> pll divider gets disabled/reenabled.
>
> This happens because the clk_hw.core.prepare_count
> drops down to 0 and then unprepare is called.
>
> So we need to increase the ref-count for the pll
> and pll_dividers to at least 1 so that these never
> get disabled - at least for now until we can come
> up with a better contract with the firmware.
>
> Obviously this may impact other drivers as well
> where a pll is used for the first time - if nothing
> else uses it and the clock gets released, then
> the clock would trigger a unprepare of the whole
> branch of the clock tree.
>
> The question is: how can we solve it in an acceptable
> manner?
>
> Do we need a driver that just holds a reference to
> those clocks? Or should we just prepare the clock
> after registering it in clk-bcm2835.c?
>
> As for why does this not show up when compiled in?
> It seems that in that case the amba_pl011 driver
> never gets removed and then probed again.
>
> This is possibly related to the optional use of DMA,
> with the amba-pl011 driver that retries the install,
> which is not supported on the bcm2835 - at least that
> is what the datasheet says. And DMA is (probably) not
> enabled during the early boot stages, so it does not
> fail once when it tries to register DMA.
>
> Thanks,
> Martin
>

i think i must correct myself. The fixed apb should stay since there is no
dynamic replacement and a proper disabling of plld shouldn't cause this freeze.

I have the suspicion the freeze is caused by a clock glitch or lock-up.

Could you please revert your changes and apply the attached patch? Maybe we can
see more.

------------------------------8<-----------------------------------------
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 637f8ae..03d95c1 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -364,6 +364,7 @@ struct bcm2835_cprman {
 	void __iomem *regs;
 	spinlock_t regs_lock;
 	const char *osc_name;
+	int func_code;
 
 	struct clk_onecell_data onecell;
 	struct clk *clks[];
@@ -1222,8 +1223,13 @@ static void bcm2835_pll_off(struct clk_hw *hw)
 	struct bcm2835_cprman *cprman = pll->cprman;
 	const struct bcm2835_pll_data *data = pll->data;
 
+	if (!(cprman_read(cprman, CM_LOCK) & data->lock_mask))
+		pr_warn("%s: PLL still locked from %d\n", __func__, cprman->func_code);
+
 	cprman_write(cprman, data->cm_ctrl_reg, CM_PLL_ANARST);
 	cprman_write(cprman, data->a2w_ctrl_reg, A2W_PLL_CTRL_PWRDN);
+
+	cprman->func_code = 1;
 }
 
 static int bcm2835_pll_on(struct clk_hw *hw)
@@ -1233,10 +1239,15 @@ static int bcm2835_pll_on(struct clk_hw *hw)
 	const struct bcm2835_pll_data *data = pll->data;
 	ktime_t timeout;
 
+	if (!(cprman_read(cprman, CM_LOCK) & data->lock_mask))
+		pr_warn("%s: PLL still locked from %d\n", __func__, cprman->func_code);
+
 	/* Take the PLL out of reset. */
 	cprman_write(cprman, data->cm_ctrl_reg,
 		     cprman_read(cprman, data->cm_ctrl_reg) & ~CM_PLL_ANARST);
 
+	cprman->func_code = 2;
+
 	/* Wait for the PLL to lock. */
 	timeout = ktime_add_ns(ktime_get(), LOCK_TIMEOUT_NS);
 	while (!(cprman_read(cprman, CM_LOCK) & data->lock_mask)) {
@@ -1267,6 +1278,8 @@ bcm2835_pll_write_ana(struct bcm2835_cprman *cprman, u32
ana_reg_base, u32 *ana)
 	 */
 	for (i = 3; i >= 0; i--)
 		cprman_write(cprman, ana_reg_base + i * 4, ana[i]);
+
+	cprman->func_code = 3;
 }
 
 static int bcm2835_pll_set_rate(struct clk_hw *hw,
@@ -1339,6 +1352,8 @@ static int bcm2835_pll_set_rate(struct clk_hw *hw,
 	if (!do_ana_setup_first)
 		bcm2835_pll_write_ana(cprman, data->ana_reg_base, ana);
 
+	cprman->func_code = 4;
+
 	return 0;
 }
 
@@ -1404,6 +1419,8 @@ static void bcm2835_pll_divider_off(struct clk_hw *hw)
 		     (cprman_read(cprman, data->cm_reg) &
 		      ~data->load_mask) | data->hold_mask);
 	cprman_write(cprman, data->a2w_reg, A2W_PLL_CHANNEL_DISABLE);
+
+	cprman->func_code = 5;
 }
 
 static int bcm2835_pll_divider_on(struct clk_hw *hw)
@@ -1419,6 +1436,8 @@ static int bcm2835_pll_divider_on(struct clk_hw *hw)
 	cprman_write(cprman, data->cm_reg,
 		     cprman_read(cprman, data->cm_reg) & ~data->hold_mask);
 
+	cprman->func_code = 6;
+
 	return 0;
 }
 
@@ -1440,6 +1459,8 @@ static int bcm2835_pll_divider_set_rate(struct clk_hw *hw,
 	cprman_write(cprman, data->cm_reg, cm | data->load_mask);
 	cprman_write(cprman, data->cm_reg, cm & ~data->load_mask);
 
+	cprman->func_code = 7;
+
 	return 0;
 }
 
@@ -1588,7 +1609,7 @@ static void bcm2835_clock_wait_busy(struct bcm2835_clock
*clock)
 
 	while (cprman_read(cprman, data->ctl_reg) & CM_BUSY) {
 		if (ktime_after(ktime_get(), timeout)) {
-			dev_err(cprman->dev, "%s: couldn't lock PLL\n",
+			dev_err(cprman->dev, "%s: clk busy timeout\n",
 				clk_hw_get_name(&clock->hw));
 			return;
 		}
@@ -1602,6 +1623,9 @@ static void bcm2835_clock_off(struct clk_hw *hw)
 	struct bcm2835_cprman *cprman = clock->cprman;
 	const struct bcm2835_clock_data *data = clock->data;
 
+	if (cprman_read(cprman, data->ctl_reg) & CM_BUSY)
+		pr_warn("%s: clk still busy from %d\n", __func__, cprman->func_code);
+
 	spin_lock(&cprman->regs_lock);
 	cprman_write(cprman, data->ctl_reg,
 		     cprman_read(cprman, data->ctl_reg) & ~CM_ENABLE);
@@ -1609,6 +1633,11 @@ static void bcm2835_clock_off(struct clk_hw *hw)
 
 	/* BUSY will remain high until the divider completes its cycle. */
 	bcm2835_clock_wait_busy(clock);
+
+	cprman->func_code = 8;
+
+	if (cprman_read(cprman, data->ctl_reg) & CM_BUSY)
+		pr_warn("%s: clk now busy from %d\n", __func__, cprman->func_code);
 }
 
 static int bcm2835_clock_on(struct clk_hw *hw)
@@ -1617,6 +1646,9 @@ static int bcm2835_clock_on(struct clk_hw *hw)
 	struct bcm2835_cprman *cprman = clock->cprman;
 	const struct bcm2835_clock_data *data = clock->data;
 
+	if (cprman_read(cprman, data->ctl_reg) & CM_BUSY)
+		pr_warn("%s: clk still busy from %d\n", __func__, cprman->func_code);
+
 	spin_lock(&cprman->regs_lock);
 	cprman_write(cprman, data->ctl_reg,
 		     cprman_read(cprman, data->ctl_reg) |
@@ -1624,6 +1656,11 @@ static int bcm2835_clock_on(struct clk_hw *hw)
 		     CM_GATE);
 	spin_unlock(&cprman->regs_lock);
 
+	cprman->func_code = 9;
+
+	if (cprman_read(cprman, data->ctl_reg) & CM_BUSY)
+		pr_warn("%s: clk now busy from %d\n", __func__, cprman->func_code);
+
 	return 0;
 }
 
@@ -1638,6 +1675,9 @@ static int bcm2835_clock_set_rate(struct clk_hw *hw,
 	enum bcm2835_clock_mash_type mash = divmash_get_mash(dm);
 	u32 ctl;
 
+	if (cprman_read(cprman, data->ctl_reg) & CM_BUSY)
+		pr_warn("%s: clk still busy from %d\n", __func__, cprman->func_code);
+
 	spin_lock(&cprman->regs_lock);
 
 	/* if div and mash are identical, then there is nothing to do */
@@ -1663,6 +1703,11 @@ static int bcm2835_clock_set_rate(struct clk_hw *hw,
 unlock_exit:
 	spin_unlock(&cprman->regs_lock);
 
+	cprman->func_code = 10;
+
+	if (cprman_read(cprman, data->ctl_reg) & CM_BUSY)
+		pr_warn("%s: clk now busy from %d\n", __func__, cprman->func_code);
+
 	return 0;
 }
 
@@ -1713,7 +1758,16 @@ static int bcm2835_clock_set_parent(struct clk_hw *hw, u8
index)
 	const struct bcm2835_clock_data *data = clock->data;
 	u8 src = (index << CM_SRC_SHIFT) & CM_SRC_MASK;
 
+	if (cprman_read(cprman, data->ctl_reg) & CM_BUSY)
+		pr_warn("%s: clk still busy from %d\n", __func__, cprman->func_code);
+
 	cprman_write(cprman, data->ctl_reg, src);
+
+	cprman->func_code = 11;
+
+	if (cprman_read(cprman, data->ctl_reg) & CM_BUSY)
+		pr_warn("%s: clk now busy from %d\n", __func__, cprman->func_code);
+
 	return 0;
 }
 


From jszhang at marvell.com  Mon Feb 15 21:42:19 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 13:42:19 +0800
Subject: [PATCH 5/5] arm64: marvell: add Device Tree files for Armada 7K/8K
In-Reply-To: <1455526065-7307-6-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455526065-7307-6-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20160216134219.00045b5b@xhacker>

Dear Thomas,

On Mon, 15 Feb 2016 09:47:45 +0100 Thomas Petazzoni wrote:

> This commit adds the base Device Tree files for the Armada 7K and 8K
> SoCs, as well as the Armada 8040 DB board.
> 
> The Armada 7020, 7040 (7K family) and 8020, 8040 (8K family) are
> composed of:
> 
>  - An AP806 block that contains the CPU core and a few basic
>    peripherals. The AP806 is available in dual core configurations
>    (used in 7020 and 8020) and quad core configurations (used in 8020
>    and 8040).
> 
>  - One or two CP110 blocks that contain all the high-speed interfaces
>    (SATA, PCIe, Ethernet, etc.). The 7K family chips have one CP110,
>    and the 8K family chips have two CP110, giving them twice the
>    number of HW interfaces.
> 

[...]

> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
> new file mode 100644
> index 0000000..baa7d9a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
> @@ -0,0 +1,84 @@
> +/*
> + * Copyright (C) 2016 Marvell Technology Group Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPLv2 or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This library is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/*
> + * Device Tree file for Marvell Armada AP806.
> + */
> +
> +#include "armada-ap806.dtsi"
> +
> +/ {
> +	model = "Marvell Armada AP806 Quad";
> +	compatible = "marvell,armada-ap806-quad", "marvell,armada-ap806";
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu at 000 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a72", "arm,armv8";
> +			reg = <0x000>;
> +			enable-method = "psci";
> +		};
> +		cpu at 001 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a72", "arm,armv8";
> +			reg = <0x001>;
> +			enable-method = "psci";
> +		};
> +		cpu at 100 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a72", "arm,armv8";
> +			reg = <0x100>;
> +			enable-method = "psci";
> +		};
> +		cpu at 101 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a72", "arm,armv8";
> +			reg = <0x101>;
> +			enable-method = "psci";
> +		};
> +	};
> +
> +};
> +
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> new file mode 100644
> index 0000000..3303db2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
> @@ -0,0 +1,235 @@
> +/*
> + * Copyright (C) 2016 Marvell Technology Group Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPLv2 or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This library is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/*
> + * Device Tree file for Marvell Armada AP806.
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/dts-v1/;
> +
> +/ {
> +	model = "Marvell Armada AP806";
> +	compatible = "marvell,armada-ap806";
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	psci {
> +		compatible = "arm,psci-0.2";

I guess the firmware is also psci-1.0 compatible.

> +		method = "smc";
> +	};
> +
> +
> +	ap806 {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		compatible = "simple-bus";
> +		interrupt-parent = <&gic>;
> +		ranges;
> +
> +		config-space {
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			compatible = "simple-bus";
> +			ranges = <0x0 0x0 0xf0000000 0x1000000>;
> +
> +			gic: interrupt-controller at 210000 {
> +				compatible = "arm,cortex-a15-gic",
> +					     "arm,cortex-a9-gic";

I guess the GIC is neither the one in cortex-a15 or cortex-a9. 

Thanks


From jamesjj.liao at mediatek.com  Mon Feb 15 21:45:56 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Tue, 16 Feb 2016 13:45:56 +0800
Subject: [PATCH v2] clk: Move vendor's Kconfig into CCF menu section
In-Reply-To: <CAJKOXPdA1VeGUmgAtObueXbY5S_X0acrF5m_QnEygzaMOeWPUw@mail.gmail.com>
References: <1453971537-5510-1-git-send-email-jamesjj.liao@mediatek.com>
 <CAJKOXPdA1VeGUmgAtObueXbY5S_X0acrF5m_QnEygzaMOeWPUw@mail.gmail.com>
Message-ID: <1455601556.29688.41.camel@mtksdaap41>

Hi Krzysztof,

On Tue, 2016-02-16 at 13:59 +0900, Krzysztof Kozlowski wrote:
> 2016-01-28 17:58 GMT+09:00 James Liao <jamesjj.liao at mediatek.com>:
> > Move all vendor's Kconfig into CCF menu section to prevent
> > new drivers putting their Kconfig files in a wrong place.
> >
> > Some Kconigs need to modify at the same time to avoid build
> > warnings.
> >
> > Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
> > ---
> > This patch is based on v4.5-rc1.
> >
> > changes since v1:
> > - Modify s3c24xx and samsung's Kconfig to avoid build warngings.
> >
> >  arch/arm/mach-s3c24xx/Kconfig | 1 +
> >  drivers/clk/Kconfig           | 8 +++-----
> >  drivers/clk/samsung/Kconfig   | 1 -
> >  3 files changed, 4 insertions(+), 6 deletions(-)
> >
> 
> I wish you had used scripts/get_maintainer.pl to get list of people to CC...
> Kukjin Kim <kgene at kernel.org> (maintainer:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES)
> Krzysztof Kozlowski <k.kozlowski at samsung.com> (maintainer:ARM/SAMSUNG
> EXYNOS ARM ARCHITECTURES)
> linux-samsung-soc at vger.kernel.org (moderated list:ARM/SAMSUNG EXYNOS
> ARM ARCHITECTURES)
> 
> Beside the fact that it is just nice and welcomed... it would help me
> to avoid some of duplicated work...

I'm sorry about that. I modified mach-s3c24xx/Kconfig and
samsung/Kconfig in patch v2 but I reused the TO and CC list from patch
v1, so this patch missed Samsung's maintainers.


Best regards,

James



From jszhang at marvell.com  Mon Feb 15 22:12:12 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 14:12:12 +0800
Subject: [PATCH v3 05/12] arm64: add mvebu architecture entry
In-Reply-To: <1454951660-13289-6-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
 <1454951660-13289-6-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160216141212.00f037e5@xhacker>

Dear Gregory,

On Mon, 8 Feb 2016 18:14:13 +0100 Gregory CLEMENT wrote:

> The Armada 3700 is an mvebu ARM64 SoC using one or two Cortex-A53 cores
> depending of the variant.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  arch/arm64/Kconfig.platforms | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 21074f674bde..c621e69ed170 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -1,5 +1,11 @@
>  menu "Platform selection"
>  
> +config ARCH_MVEBU

it's better to keep ARCH_YYZZ sorted in alphabetic order

Thanks,
Jisheng

> +	bool "Marvell EBU SoC Family"
> +	help
> +	  This enables support for Marvell EBU family such as the
> +	  Armada 3700 SoC family.
> +
>  config ARCH_BCM_IPROC
>  	bool "Broadcom iProc SoC Family"
>  	help



From jszhang at marvell.com  Mon Feb 15 22:16:27 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 14:16:27 +0800
Subject: [PATCH v3 09/12] arm64: dts: add the Marvell Armada 3700 family
 and a development board
In-Reply-To: <1454951660-13289-10-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
 <1454951660-13289-10-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160216141627.78ec94bd@xhacker>

Dear Gregory,
On Mon, 8 Feb 2016 18:14:17 +0100 Gregory CLEMENT wrote:

> Add initial dtsi files to support Marvell Armada 3700 SoC with Cortex-A53
> CPUs. There are two members in this family: the Armada 3710 (Single CPU)
> and the Armada 3720 (Dual CPUs).
> 
> It also adds a dts file for the Marvell Armada 3720 DB board.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  arch/arm64/boot/dts/marvell/Makefile           |   4 +
>  arch/arm64/boot/dts/marvell/armada-371x.dtsi   |  53 ++++++++++
>  arch/arm64/boot/dts/marvell/armada-3720-db.dts |  86 ++++++++++++++++
>  arch/arm64/boot/dts/marvell/armada-372x.dtsi   |  63 ++++++++++++
>  arch/arm64/boot/dts/marvell/armada-37xx.dtsi   | 131 +++++++++++++++++++++++++
>  5 files changed, 337 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-371x.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-db.dts
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-372x.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> 
> diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
> index 348f4db4f313..2114af8d312d 100644
> --- a/arch/arm64/boot/dts/marvell/Makefile
> +++ b/arch/arm64/boot/dts/marvell/Makefile
> @@ -1,6 +1,10 @@
> +# Berlin SoC Family
>  dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-dmp.dtb
>  dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
>  
> +# Mvebu SoC Family
> +dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
> +
>  always		:= $(dtb-y)
>  subdir-y	:= $(dts-dirs)
>  clean-files	:= *.dtb
> diff --git a/arch/arm64/boot/dts/marvell/armada-371x.dtsi b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
> new file mode 100644
> index 000000000000..c9e5325b8ac3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
> @@ -0,0 +1,53 @@
> +/*
> + * Device Tree Include file for Marvell Armada 371x family of SoCs
> + * (also named 88F3710)
> + *
> + * Copyright (C) 2016 Marvell

Is it better to Add full Marvell company name, eg. Marvell Technology Group Ltd.

> + *
> + * Gregory CLEMENT <gregory.clement at free-electrons.com>

What does this mean? in copyright holder list or just author? Is it better
to add "Author:" prefix or something else?


[...]

> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> new file mode 100644
> index 000000000000..ba9df7ff2a72
> --- /dev/null
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -0,0 +1,131 @@
> +/*
> + * Device Tree Include file for Marvell Armada 37xx family of SoCs.
> + *
> + * Copyright (C) 2016 Marvell
> + *
> + * Gregory CLEMENT <gregory.clement at free-electrons.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This file is distributed in the hope that it will be useful
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> +	model = "Marvell Armada 37xx SoC";
> +	compatible = "marvell,armada3700";
> +	interrupt-parent = <&gic>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	aliases {
> +		serial0 = &uart0;
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			reg = <0>;
> +			enable-method = "psci";
> +		};
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-0.2";
> +		method = "smc";
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts = <GIC_PPI 13
> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 14
> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 11
> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 10
> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
> +	};
> +
> +	soc {
> +		compatible = "simple-bus";
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		internal-regs {
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			compatible = "simple-bus";
> +			/* 32M internal register @ 0xd000_0000 */
> +			ranges = <0x0 0x0 0xd0000000 0x2000000>;
> +
> +			uart0: serial at 12000 {
> +				compatible = "marvell,armada-3700-uart";
> +				reg = <0x12000 0x400>;
> +				interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
> +				status = "disabled";
> +			};
> +
> +			usb3 at 58000 {
> +				compatible = "generic-xhci";
> +				reg = <0x58000 0x4000>;
> +				interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
> +				status = "disabled";
> +			};
> +
> +			sata at e0000 {
> +				compatible = "marvell,armada-3700-ahci";
> +				reg = <0xe0000 0x2000>;
> +				interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
> +				status = "disabled";
> +			};
> +
> +			gic: interrupt-controller at 1d00000 {
> +				compatible = "arm,gic-v3";
> +				#interrupt-cells = <3>;
> +				interrupt-controller;
> +				reg = <0x1d00000 0x10000>, /* GICD */
> +				      <0x1d40000 0x40000>; /* GICR */

There's no GICC, GICV, GICH?

> +			};
> +		};
> +	};
> +};



From k.kozlowski at samsung.com  Mon Feb 15 22:20:29 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 16 Feb 2016 15:20:29 +0900
Subject: [PATCH v5 0/3] arm64/clk: EXYNOS: Consolidate Exynos7 symbol
Message-ID: <1455603632-11158-1-git-send-email-k.kozlowski@samsung.com>

Hi,

Patchset attempts to remove the ARCH_EXYNOS7 symbol.

I rebased this on top of James':
 - clk: Move vendor's Kconfig into CCF menu section
   http://www.spinics.net/lists/devicetree/msg111953.html

The third patch depends on previous ones so one way of merging this
would be to prepare a tag from clk tree with first two patches
and the dependency. The last third patch would go through arm-soc.

Changes since v4:
=================
1. Rebased on "clk: Move vendor's Kconfig into CCF menu section"
   existing in clock tree.
2. Re-work patch 2/3 (see specific changelog).

Changes since v3:
=================
1. Rebase on next-20160127 (s3c64xx became multiplatform).

Changes since v2:
=================
1. Follow Arnd's advice about not enabling silently the newly added
   EXYNOS_ARM64_COMMON_CLK, when COMPILE_TEST is enabled. This was
   also a trigger for some changes in placement of Samsung clocks
   Kconfig entries...
2. ... which lead to introducing patch 1.


Rationale:
==========
We don't need ARCH_EXYNOS7 symbol because all ARMv8 platforms should
fall under generic ARCH_EXYNOS. In the same time there is no sense
in building clocks for these ARMv8 SoCs on ARMv7 builds.


Best regards,
Krzysztof

Krzysztof Kozlowski (3):
  clk: samsung: Enable COMPILE_TEST for Samsung clocks
  clk: samsung: Don't build ARMv8 clock drivers on ARMv7
  arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS

 arch/arm64/Kconfig.platforms        | 11 ++---------
 arch/arm64/boot/dts/exynos/Makefile |  2 +-
 arch/arm64/configs/defconfig        |  2 +-
 drivers/clk/samsung/Kconfig         | 18 +++++++++++++-----
 drivers/clk/samsung/Makefile        |  4 ++--
 5 files changed, 19 insertions(+), 18 deletions(-)

-- 
2.5.0



From k.kozlowski at samsung.com  Mon Feb 15 22:20:30 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 16 Feb 2016 15:20:30 +0900
Subject: [PATCH v5 1/3] clk: samsung: Enable COMPILE_TEST for Samsung clocks
In-Reply-To: <1455603632-11158-1-git-send-email-k.kozlowski@samsung.com>
References: <1455603632-11158-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455603632-11158-2-git-send-email-k.kozlowski@samsung.com>

Enable the COMPILE_TEST to get build coverage of some of Samsung clock
controller drivers. Still some of them will be built only if
appropriate SoC is chosen (like SOC_EXYNOS4415 or ARCH_S3C64XX).

Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
Reviewed-by: Javier Martinez Canillas <javier at osg.samsung.com>
Tested-by: Javier Martinez Canillas <javier at osg.samsung.com>
Reviewed-by: Andi Shyti <andi.shyti at samsung.com>

---

Changes since v4:
1. Rebase on current clk tree which already contains patch moving
   Samsung clock drivers into the COMMON_CLK section.
   (b9e65ebc654, "clk: Move vendor's Kconfig into CCF menu section")

Changes since v3:
1. Rebase on next-20160127 (s3c64xx became multiplatform)

Changes since v2:
1. New patch.
---
 drivers/clk/samsung/Kconfig | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
index b3fe5cb01afe..dd6093a33f84 100644
--- a/drivers/clk/samsung/Kconfig
+++ b/drivers/clk/samsung/Kconfig
@@ -1,8 +1,8 @@
 config COMMON_CLK_SAMSUNG
-	bool
+	bool "Samsung Exynos clock controller support" if COMPILE_TEST
 
 config S3C2410_COMMON_CLK
-	bool
+	bool "Samsung S3C2410 clock controller support" if COMPILE_TEST
 	select COMMON_CLK_SAMSUNG
 	help
 	  Build the s3c2410 clock driver based on the common clock framework.
@@ -16,10 +16,10 @@ config S3C2410_COMMON_DCLK
 	  framework.
 
 config S3C2412_COMMON_CLK
-	bool
+	bool "Samsung S3C2412 clock controller support" if COMPILE_TEST
 	select COMMON_CLK_SAMSUNG
 
 config S3C2443_COMMON_CLK
-	bool
+	bool "Samsung S3C2443 clock controller support" if COMPILE_TEST
 	select COMMON_CLK_SAMSUNG
 
-- 
2.5.0



From k.kozlowski at samsung.com  Mon Feb 15 22:20:31 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 16 Feb 2016 15:20:31 +0900
Subject: [PATCH v5 2/3] clk: samsung: Don't build ARMv8 clock drivers on ARMv7
In-Reply-To: <1455603632-11158-1-git-send-email-k.kozlowski@samsung.com>
References: <1455603632-11158-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455603632-11158-3-git-send-email-k.kozlowski@samsung.com>

Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS
so it is built also on ARMv7. This does not bring any kind of benefit.
There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like
multi_v7 for ARMv7).

Instead build clock drivers only for respective SoC's architecture.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>

---

Changes since v4:
1. Move ARM64 clock entry just before COMMON_CLK_SAMSUNG to make it more
   consistent with selecting behavior. Newer platforms just select
   COMMON_CLK_SAMSUNG. Only S3C24XX select specific clock symbols.
2. Re-work behaviour on COMPILE_TEST=y to fix ignored compilation
   when COMPILE_TEST=y but COMMON_CLK_SAMSUNG=n.
   The COMMON_CLK_SAMSUNG=y is necessary always to compile ARM64 clocks.
3. I received reviews and tests (Chanwoo, Javier, Andi, Stephen - thank
   you guys!)... but the patch is now different so I decided to drop
   them. I am kindly asking for review/testing (again...).

Changes since v3:
1. Rebase on next-20160127.

Changes since v2:
1. Follow Arnd's advice making EXYNOS_ARM64_COMMON_CLK user-visible when
   COMPILE_TEST is enabled.
2. Dropped accumulated tags because the logic is now different.

Changes since v1:
1. Use one Kconfig symbol for clocks of all ARM64 SoCs (after
   discussion): EXYNOS_ARM64_COMMON_CLK.
2. Minor cleanups after Tomasz's comments.
3. Added tags: Chanwoo's, Sylwester's, Alim's and Tomasz's (the tags
   were given for v1 but assuming that change from 1. is not major
   enough to require re-tagging).
---
 drivers/clk/samsung/Kconfig  | 10 +++++++++-
 drivers/clk/samsung/Makefile |  4 ++--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
index dd6093a33f84..20c5fe92ab4a 100644
--- a/drivers/clk/samsung/Kconfig
+++ b/drivers/clk/samsung/Kconfig
@@ -1,6 +1,15 @@
+# Recent Exynos platforms should just select COMMON_CLK_SAMSUNG:
 config COMMON_CLK_SAMSUNG
 	bool "Samsung Exynos clock controller support" if COMPILE_TEST
+	# Clocks on ARM64 SoCs (e.g. Exynos5433, Exynos7) are chosen by
+	# EXYNOS_ARM64_COMMON_CLK to avoid building them on ARMv7:
+	select EXYNOS_ARM64_COMMON_CLK if ARM64 && ARCH_EXYNOS
 
+config EXYNOS_ARM64_COMMON_CLK
+	bool "Samsung Exynos ARMv8-family clock controller support" if COMPILE_TEST
+	depends on COMMON_CLK_SAMSUNG
+
+# For S3C24XX platforms, select following symbols:
 config S3C2410_COMMON_CLK
 	bool "Samsung S3C2410 clock controller support" if COMPILE_TEST
 	select COMMON_CLK_SAMSUNG
@@ -22,4 +31,3 @@ config S3C2412_COMMON_CLK
 config S3C2443_COMMON_CLK
 	bool "Samsung S3C2443 clock controller support" if COMPILE_TEST
 	select COMMON_CLK_SAMSUNG
-
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 5f6833ea355d..fc367d4b2902 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -10,11 +10,11 @@ obj-$(CONFIG_SOC_EXYNOS5250)	+= clk-exynos5250.o
 obj-$(CONFIG_SOC_EXYNOS5260)	+= clk-exynos5260.o
 obj-$(CONFIG_SOC_EXYNOS5410)	+= clk-exynos5410.o
 obj-$(CONFIG_SOC_EXYNOS5420)	+= clk-exynos5420.o
-obj-$(CONFIG_ARCH_EXYNOS)	+= clk-exynos5433.o
+obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynos5433.o
 obj-$(CONFIG_SOC_EXYNOS5440)	+= clk-exynos5440.o
 obj-$(CONFIG_ARCH_EXYNOS)	+= clk-exynos-audss.o
 obj-$(CONFIG_ARCH_EXYNOS)	+= clk-exynos-clkout.o
-obj-$(CONFIG_ARCH_EXYNOS7)	+= clk-exynos7.o
+obj-$(CONFIG_EXYNOS_ARM64_COMMON_CLK)	+= clk-exynos7.o
 obj-$(CONFIG_S3C2410_COMMON_CLK)+= clk-s3c2410.o
 obj-$(CONFIG_S3C2410_COMMON_DCLK)+= clk-s3c2410-dclk.o
 obj-$(CONFIG_S3C2412_COMMON_CLK)+= clk-s3c2412.o
-- 
2.5.0



From k.kozlowski at samsung.com  Mon Feb 15 22:20:32 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 16 Feb 2016 15:20:32 +0900
Subject: [PATCH v5 3/3] arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into
 ARCH_EXYNOS
In-Reply-To: <1455603632-11158-1-git-send-email-k.kozlowski@samsung.com>
References: <1455603632-11158-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455603632-11158-4-git-send-email-k.kozlowski@samsung.com>

The ARMv8 Exynos family SoCs in Linux kernel are currently:
 - Exynos5433 (controlled by ARCH_EXYNOS),
 - Exynos7 (controlled by ARCH_EXYNOS7).

It duplicates Kconfig symbols unnecessarily, so consolidate them into
one ARCH_EXYNOS. Future SoCs could fall also under the ARCH_EXYNOS
symbol.

The commit should not bring any visible functional change.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi at samsung.com>
Reviewed-by: Pankaj Dubey <pankaj.dubey at samsung.com>
Tested-by: Alim Akhtar <alim.akhtar at samsung.com>
Reviewed-by: Tomasz Figa <tomasz.figa at gmail.com>
Reviewed-by: Javier Martinez Canillas <javier at osg.samsung.com>
Reviewed-by: Andi Shyti <andi.shyti at samsung.com>

---

Changes since v4:
1. Added tags from: Javier, Andi.

Changes since v3:
1. Rebase on next-20160127.

Changes since v2:
1. None

Changes since v1:
1. Minor cleanups after Tomasz's comments.
2. Added tags: Chanwoo's, Pankaj's, Alim's and Tomasz's.
---
 arch/arm64/Kconfig.platforms        | 11 ++---------
 arch/arm64/boot/dts/exynos/Makefile |  2 +-
 arch/arm64/configs/defconfig        |  2 +-
 3 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f674bde..653662bbafeb 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -14,21 +14,14 @@ config ARCH_BERLIN
 	  This enables support for Marvell Berlin SoC Family
 
 config ARCH_EXYNOS
-	bool
-	help
-	  This enables support for Samsung Exynos SoC family
-
-config ARCH_EXYNOS7
-	bool "ARMv8 based Samsung Exynos7"
-	select ARCH_EXYNOS
+	bool "ARMv8 based Samsung Exynos SoC family"
 	select COMMON_CLK_SAMSUNG
 	select HAVE_S3C2410_WATCHDOG if WATCHDOG
 	select HAVE_S3C_RTC if RTC_CLASS
 	select PINCTRL
 	select PINCTRL_EXYNOS
-
 	help
-	  This enables support for Samsung Exynos7 SoC family
+	  This enables support for ARMv8 based Samsung Exynos SoC family.
 
 config ARCH_LAYERSCAPE
 	bool "ARMv8 based Freescale Layerscape SoC family"
diff --git a/arch/arm64/boot/dts/exynos/Makefile b/arch/arm64/boot/dts/exynos/Makefile
index 20310e5b6d6f..50c9b9383cfa 100644
--- a/arch/arm64/boot/dts/exynos/Makefile
+++ b/arch/arm64/boot/dts/exynos/Makefile
@@ -1,4 +1,4 @@
-dtb-$(CONFIG_ARCH_EXYNOS7) += exynos7-espresso.dtb
+dtb-$(CONFIG_ARCH_EXYNOS) += exynos7-espresso.dtb
 
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 18ca9fb9e65f..331a843cf122 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -33,7 +33,7 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_IOSCHED_DEADLINE is not set
 CONFIG_ARCH_BCM_IPROC=y
 CONFIG_ARCH_BERLIN=y
-CONFIG_ARCH_EXYNOS7=y
+CONFIG_ARCH_EXYNOS=y
 CONFIG_ARCH_LAYERSCAPE=y
 CONFIG_ARCH_HISI=y
 CONFIG_ARCH_MEDIATEK=y
-- 
2.5.0



From anup.patel at broadcom.com  Mon Feb 15 22:33:35 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Tue, 16 Feb 2016 12:03:35 +0530
Subject: [PATCH 0/5] Add SATA3 support for Broadcom NS2 SVK
Message-ID: <1455604420-11300-1-git-send-email-anup.patel@broadcom.com>

The Broadcom NS2 SoC has a AHCI compliant SATA3 controller with
two ports.

This patchset adds common Broadcom SATA3 PHY driver and related
DT bindings document. It also adds appropriate DT nodes for NS2 DT.

The patchset is based on v4.5-rc3 tag and is available in branch
ns2_sata3_v1 of https://github.com/Broadcom/arm64-linux.git

All patches have been tested on Broadcom NS2 SVK.

Anup Patel (5):
  phy: Rename phy-brcmstb-sata driver to phy-brcm-sata driver
  phy: Add support for NS2 SATA3 PHY in Broadcom SATA3 PHY driver
  dt-bindings: phy: bindings document for common Broadcom SATA3 PHY
    driver
  dt-bindings: ata: add compatible string for iProc AHCI controller
  arm64: dts: Add SATA3 AHCI and SATA3 PHY DT nodes for NS2

 .../devicetree/bindings/ata/ahci-platform.txt      |   1 +
 ...brcm,brcmstb-sata-phy.txt => brcm-sata-phy.txt} |  15 +-
 arch/arm64/boot/dts/broadcom/ns2-svk.dts           |  12 +
 arch/arm64/boot/dts/broadcom/ns2.dtsi              |  43 +++
 drivers/phy/Kconfig                                |  18 +-
 drivers/phy/Makefile                               |   2 +-
 drivers/phy/phy-brcm-sata.c                        | 412 +++++++++++++++++++++
 drivers/phy/phy-brcmstb-sata.c                     | 250 -------------
 8 files changed, 487 insertions(+), 266 deletions(-)
 rename Documentation/devicetree/bindings/phy/{brcm,brcmstb-sata-phy.txt => brcm-sata-phy.txt} (69%)
 create mode 100644 drivers/phy/phy-brcm-sata.c
 delete mode 100644 drivers/phy/phy-brcmstb-sata.c

-- 
1.9.1



From anup.patel at broadcom.com  Mon Feb 15 22:33:36 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Tue, 16 Feb 2016 12:03:36 +0530
Subject: [PATCH 1/5] phy: Rename phy-brcmstb-sata driver to phy-brcm-sata
 driver
In-Reply-To: <1455604420-11300-1-git-send-email-anup.patel@broadcom.com>
References: <1455604420-11300-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <1455604420-11300-2-git-send-email-anup.patel@broadcom.com>

Currently, we have a common SATA3 PHY driver for all Broadcom
STB SoCs. This driver can be extended and re-used for Broadcom
iProc SoCs having same SATA3 PHY.

This patch renames existing Broadcom STB SATA3 PHY driver to
common Broadcom SATA3 PHY driver to share this PHY driver across
Broadcom SoCs.

Signed-off-by: Anup Patel <anup.patel at broadcom.com>
---
 drivers/phy/Kconfig                                 | 18 +++++++++---------
 drivers/phy/Makefile                                |  2 +-
 drivers/phy/{phy-brcmstb-sata.c => phy-brcm-sata.c} |  8 ++++----
 3 files changed, 14 insertions(+), 14 deletions(-)
 rename drivers/phy/{phy-brcmstb-sata.c => phy-brcm-sata.c} (97%)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index e7e117d..4d926b8 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -388,15 +388,6 @@ config PHY_TUSB1210
 	help
 	  Support for TI TUSB1210 USB ULPI PHY.
 
-config PHY_BRCMSTB_SATA
-	tristate "Broadcom STB SATA PHY driver"
-	depends on ARCH_BRCMSTB || BMIPS_GENERIC
-	depends on OF
-	select GENERIC_PHY
-	help
-	  Enable this to support the SATA3 PHY on 28nm or 40nm Broadcom STB SoCs.
-	  Likely useful only with CONFIG_SATA_BRCMSTB enabled.
-
 config PHY_CYGNUS_PCIE
 	tristate "Broadcom Cygnus PCIe PHY driver"
 	depends on OF && (ARCH_BCM_CYGNUS || COMPILE_TEST)
@@ -406,4 +397,13 @@ config PHY_CYGNUS_PCIE
 	  Enable this to support the Broadcom Cygnus PCIe PHY.
 	  If unsure, say N.
 
+config PHY_BRCM_SATA
+	tristate "Broadcom SATA PHY driver"
+	depends on ARCH_BRCMSTB || ARCH_BCM_IPROC || BMIPS_GENERIC || COMPILE_TEST
+	depends on OF
+	select GENERIC_PHY
+	default ARCH_BCM_IPROC
+	help
+	  Enable this to support the Broadcom SATA PHY.
+	  If unsure, say N.
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index c80f09d..d67d609 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -47,6 +47,6 @@ obj-$(CONFIG_PHY_QCOM_UFS) 	+= phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) 	+= phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) 	+= phy-qcom-ufs-qmp-14nm.o
 obj-$(CONFIG_PHY_TUSB1210)		+= phy-tusb1210.o
-obj-$(CONFIG_PHY_BRCMSTB_SATA)		+= phy-brcmstb-sata.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)		+= phy-pistachio-usb.o
 obj-$(CONFIG_PHY_CYGNUS_PCIE)		+= phy-bcm-cygnus-pcie.o
+obj-$(CONFIG_PHY_BRCM_SATA)		+= phy-brcm-sata.o
diff --git a/drivers/phy/phy-brcmstb-sata.c b/drivers/phy/phy-brcm-sata.c
similarity index 97%
rename from drivers/phy/phy-brcmstb-sata.c
rename to drivers/phy/phy-brcm-sata.c
index a23172f..c97b9d6 100644
--- a/drivers/phy/phy-brcmstb-sata.c
+++ b/drivers/phy/phy-brcm-sata.c
@@ -1,7 +1,7 @@
 /*
  * Broadcom SATA3 AHCI Controller PHY Driver
  *
- * Copyright ? 2009-2015 Broadcom Corporation
+ * Copyright (C) 2016 Broadcom
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -238,13 +238,13 @@ static struct platform_driver brcm_sata_phy_driver = {
 	.probe	= brcm_sata_phy_probe,
 	.driver	= {
 		.of_match_table	= brcm_sata_phy_of_match,
-		.name		= "brcmstb-sata-phy",
+		.name		= "brcm-sata-phy",
 	}
 };
 module_platform_driver(brcm_sata_phy_driver);
 
-MODULE_DESCRIPTION("Broadcom STB SATA PHY driver");
+MODULE_DESCRIPTION("Broadcom SATA PHY driver");
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Marc Carino");
 MODULE_AUTHOR("Brian Norris");
-MODULE_ALIAS("platform:phy-brcmstb-sata");
+MODULE_ALIAS("platform:phy-brcm-sata");
-- 
1.9.1



From anup.patel at broadcom.com  Mon Feb 15 22:33:37 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Tue, 16 Feb 2016 12:03:37 +0530
Subject: [PATCH 2/5] phy: Add support for NS2 SATA3 PHY in Broadcom SATA3 PHY
 driver
In-Reply-To: <1455604420-11300-1-git-send-email-anup.patel@broadcom.com>
References: <1455604420-11300-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <1455604420-11300-3-git-send-email-anup.patel@broadcom.com>

This patch adds support for Broadcom NS2 SATA3 PHY in existing
Broadcom SATA3 PHY driver.

Signed-off-by: Anup Patel <anup.patel at broadcom.com>
---
 drivers/phy/phy-brcm-sata.c | 238 +++++++++++++++++++++++++++++++++++++-------
 1 file changed, 200 insertions(+), 38 deletions(-)

diff --git a/drivers/phy/phy-brcm-sata.c b/drivers/phy/phy-brcm-sata.c
index c97b9d6..6c4c5cb 100644
--- a/drivers/phy/phy-brcm-sata.c
+++ b/drivers/phy/phy-brcm-sata.c
@@ -14,6 +14,7 @@
  * GNU General Public License for more details.
  */
 
+#include <linux/delay.h>
 #include <linux/device.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
@@ -24,22 +25,26 @@
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
 
-#define SATA_MDIO_BANK_OFFSET				0x23c
-#define SATA_MDIO_REG_OFFSET(ofs)			((ofs) * 4)
+#define SATA_PCB_BANK_OFFSET				0x23c
+#define SATA_PCB_REG_OFFSET(ofs)			((ofs) * 4)
 
 #define MAX_PORTS					2
 
 /* Register offset between PHYs in PCB space */
-#define SATA_MDIO_REG_28NM_SPACE_SIZE			0x1000
+#define SATA_PCB_REG_28NM_SPACE_SIZE			0x1000
 
 /* The older SATA PHY registers duplicated per port registers within the map,
  * rather than having a separate map per port.
  */
-#define SATA_MDIO_REG_40NM_SPACE_SIZE			0x10
+#define SATA_PCB_REG_40NM_SPACE_SIZE			0x10
+
+/* Register offset between PHYs in PHY control space */
+#define SATA_PHY_CTRL_REG_28NM_SPACE_SIZE		0x8
 
 enum brcm_sata_phy_version {
-	BRCM_SATA_PHY_28NM,
-	BRCM_SATA_PHY_40NM,
+	BRCM_SATA_PHY_STB_28NM,
+	BRCM_SATA_PHY_STB_40NM,
+	BRCM_SATA_PHY_IPROC_NS2,
 };
 
 struct brcm_sata_port {
@@ -52,15 +57,48 @@ struct brcm_sata_port {
 struct brcm_sata_phy {
 	struct device *dev;
 	void __iomem *phy_base;
+	void __iomem *ctrl_base;
 	enum brcm_sata_phy_version version;
 
 	struct brcm_sata_port phys[MAX_PORTS];
 };
 
-enum sata_mdio_phy_regs {
-	PLL_REG_BANK_0				= 0x50,
+enum sata_phy_regs {
+	BLOCK0_REG_BANK				= 0x000,
+	BLOCK0_XGXSSTATUS			= 0x81,
+	BLOCK0_XGXSSTATUS_PLL_LOCK		= BIT(12),
+	BLOCK0_SPARE				= 0x8d,
+	BLOCK0_SPARE_OOB_CLK_SEL_MASK		= 0x3,
+	BLOCK0_SPARE_OOB_CLK_SEL_REFBY2		= 0x1,
+
+	PLL_REG_BANK_0				= 0x050,
 	PLL_REG_BANK_0_PLLCONTROL_0		= 0x81,
 
+	PLL1_REG_BANK				= 0x060,
+	PLL1_ACTRL2				= 0x82,
+	PLL1_ACTRL3				= 0x83,
+	PLL1_ACTRL4				= 0x84,
+
+	OOB_REG_BANK				= 0x150,
+	OOB_CTRL1				= 0x80,
+	OOB_CTRL1_BURST_MAX_MASK		= 0xf,
+	OOB_CTRL1_BURST_MAX_SHIFT		= 12,
+	OOB_CTRL1_BURST_MIN_MASK		= 0xf,
+	OOB_CTRL1_BURST_MIN_SHIFT		= 8,
+	OOB_CTRL1_WAKE_IDLE_MAX_MASK		= 0xf,
+	OOB_CTRL1_WAKE_IDLE_MAX_SHIFT		= 4,
+	OOB_CTRL1_WAKE_IDLE_MIN_MASK		= 0xf,
+	OOB_CTRL1_WAKE_IDLE_MIN_SHIFT		= 0,
+	OOB_CTRL2				= 0x81,
+	OOB_CTRL2_SEL_ENA_SHIFT			= 15,
+	OOB_CTRL2_SEL_ENA_RC_SHIFT		= 14,
+	OOB_CTRL2_RESET_IDLE_MAX_MASK		= 0x3f,
+	OOB_CTRL2_RESET_IDLE_MAX_SHIFT		= 8,
+	OOB_CTRL2_BURST_CNT_MASK		= 0x3,
+	OOB_CTRL2_BURST_CNT_SHIFT		= 6,
+	OOB_CTRL2_RESET_IDLE_MIN_MASK		= 0x3f,
+	OOB_CTRL2_RESET_IDLE_MIN_SHIFT		= 0,
+
 	TXPMD_REG_BANK				= 0x1a0,
 	TXPMD_CONTROL1				= 0x81,
 	TXPMD_CONTROL1_TX_SSC_EN_FRC		= BIT(0),
@@ -72,69 +110,183 @@ enum sata_mdio_phy_regs {
 	TXPMD_TX_FREQ_CTRL_CONTROL3_FMAX_MASK	= 0x3ff,
 };
 
-static inline void __iomem *brcm_sata_phy_base(struct brcm_sata_port *port)
+enum sata_phy_ctrl_regs {
+	PHY_CTRL_1				= 0x0,
+	PHY_CTRL_1_RESET			= BIT(0),
+};
+
+static inline void __iomem *brcm_sata_pcb_base(struct brcm_sata_port *port)
 {
 	struct brcm_sata_phy *priv = port->phy_priv;
-	u32 offset = 0;
+	u32 size = 0;
+
+	switch (priv->version) {
+	case BRCM_SATA_PHY_STB_28NM:
+	case BRCM_SATA_PHY_IPROC_NS2:
+		size = SATA_PCB_REG_28NM_SPACE_SIZE;
+		break;
+	case BRCM_SATA_PHY_STB_40NM:
+		size = SATA_PCB_REG_40NM_SPACE_SIZE;
+		break;
+	default:
+		dev_err(priv->dev, "invalid phy version\n");
+		break;
+	};
 
-	if (priv->version == BRCM_SATA_PHY_28NM)
-		offset = SATA_MDIO_REG_28NM_SPACE_SIZE;
-	else if (priv->version == BRCM_SATA_PHY_40NM)
-		offset = SATA_MDIO_REG_40NM_SPACE_SIZE;
-	else
+	return priv->phy_base + (port->portnum * size);
+}
+
+static inline void __iomem *brcm_sata_ctrl_base(struct brcm_sata_port *port)
+{
+	struct brcm_sata_phy *priv = port->phy_priv;
+	u32 size = 0;
+
+	switch (priv->version) {
+	case BRCM_SATA_PHY_IPROC_NS2:
+		size = SATA_PHY_CTRL_REG_28NM_SPACE_SIZE;
+		break;
+	default:
 		dev_err(priv->dev, "invalid phy version\n");
+		break;
+	};
 
-	return priv->phy_base + (port->portnum * offset);
+	return priv->ctrl_base + (port->portnum * size);
 }
 
-static void brcm_sata_mdio_wr(void __iomem *addr, u32 bank, u32 ofs,
-			      u32 msk, u32 value)
+static void brcm_sata_phy_wr(void __iomem *pcb_base, u32 bank,
+			     u32 ofs, u32 msk, u32 value)
 {
 	u32 tmp;
 
-	writel(bank, addr + SATA_MDIO_BANK_OFFSET);
-	tmp = readl(addr + SATA_MDIO_REG_OFFSET(ofs));
+	writel(bank, pcb_base + SATA_PCB_BANK_OFFSET);
+	tmp = readl(pcb_base + SATA_PCB_REG_OFFSET(ofs));
 	tmp = (tmp & msk) | value;
-	writel(tmp, addr + SATA_MDIO_REG_OFFSET(ofs));
+	writel(tmp, pcb_base + SATA_PCB_REG_OFFSET(ofs));
+}
+
+static u32 brcm_sata_phy_rd(void __iomem *pcb_base, u32 bank, u32 ofs)
+{
+	writel(bank, pcb_base + SATA_PCB_BANK_OFFSET);
+	return readl(pcb_base + SATA_PCB_REG_OFFSET(ofs));
 }
 
 /* These defaults were characterized by H/W group */
-#define FMIN_VAL_DEFAULT	0x3df
-#define FMAX_VAL_DEFAULT	0x3df
-#define FMAX_VAL_SSC		0x83
+#define STB_FMIN_VAL_DEFAULT	0x3df
+#define STB_FMAX_VAL_DEFAULT	0x3df
+#define STB_FMAX_VAL_SSC	0x83
 
-static void brcm_sata_cfg_ssc(struct brcm_sata_port *port)
+static int brcm_stb_sata_init(struct brcm_sata_port *port)
 {
-	void __iomem *base = brcm_sata_phy_base(port);
+	void __iomem *base = brcm_sata_pcb_base(port);
 	struct brcm_sata_phy *priv = port->phy_priv;
 	u32 tmp;
 
 	/* override the TX spread spectrum setting */
 	tmp = TXPMD_CONTROL1_TX_SSC_EN_FRC_VAL | TXPMD_CONTROL1_TX_SSC_EN_FRC;
-	brcm_sata_mdio_wr(base, TXPMD_REG_BANK, TXPMD_CONTROL1, ~tmp, tmp);
+	brcm_sata_phy_wr(base, TXPMD_REG_BANK, TXPMD_CONTROL1, ~tmp, tmp);
 
 	/* set fixed min freq */
-	brcm_sata_mdio_wr(base, TXPMD_REG_BANK, TXPMD_TX_FREQ_CTRL_CONTROL2,
-			  ~TXPMD_TX_FREQ_CTRL_CONTROL2_FMIN_MASK,
-			  FMIN_VAL_DEFAULT);
+	brcm_sata_phy_wr(base, TXPMD_REG_BANK, TXPMD_TX_FREQ_CTRL_CONTROL2,
+			 ~TXPMD_TX_FREQ_CTRL_CONTROL2_FMIN_MASK,
+			 STB_FMIN_VAL_DEFAULT);
 
 	/* set fixed max freq depending on SSC config */
 	if (port->ssc_en) {
-		dev_info(priv->dev, "enabling SSC on port %d\n", port->portnum);
-		tmp = FMAX_VAL_SSC;
+		dev_info(priv->dev, "enabling SSC on port%d\n", port->portnum);
+		tmp = STB_FMAX_VAL_SSC;
 	} else {
-		tmp = FMAX_VAL_DEFAULT;
+		tmp = STB_FMAX_VAL_DEFAULT;
 	}
 
-	brcm_sata_mdio_wr(base, TXPMD_REG_BANK, TXPMD_TX_FREQ_CTRL_CONTROL3,
+	brcm_sata_phy_wr(base, TXPMD_REG_BANK, TXPMD_TX_FREQ_CTRL_CONTROL3,
 			  ~TXPMD_TX_FREQ_CTRL_CONTROL3_FMAX_MASK, tmp);
+
+	return 0;
+}
+
+/* NS2 SATA PLL1 defaults were characterized by H/W group */
+#define NS2_PLL1_ACTRL2_MAGIC	0x1df8
+#define NS2_PLL1_ACTRL3_MAGIC	0x2b00
+#define NS2_PLL1_ACTRL4_MAGIC	0x8824
+
+static int brcm_ns2_sata_init(struct brcm_sata_port *port)
+{
+	int try;
+	unsigned int val;
+	void __iomem *base = brcm_sata_pcb_base(port);
+	void __iomem *ctrl_base = brcm_sata_ctrl_base(port);
+	struct device *dev = port->phy_priv->dev;
+
+	/* Configure OOB control */
+	val = 0x0;
+	val |= (0xc << OOB_CTRL1_BURST_MAX_SHIFT);
+	val |= (0x4 << OOB_CTRL1_BURST_MIN_SHIFT);
+	val |= (0x9 << OOB_CTRL1_WAKE_IDLE_MAX_SHIFT);
+	val |= (0x3 << OOB_CTRL1_WAKE_IDLE_MIN_SHIFT);
+	brcm_sata_phy_wr(base, OOB_REG_BANK, OOB_CTRL1, 0x0, val);
+	val = 0x0;
+	val |= (0x1b << OOB_CTRL2_RESET_IDLE_MAX_SHIFT);
+	val |= (0x2 << OOB_CTRL2_BURST_CNT_SHIFT);
+	val |= (0x9 << OOB_CTRL2_RESET_IDLE_MIN_SHIFT);
+	brcm_sata_phy_wr(base, OOB_REG_BANK, OOB_CTRL2, 0x0, val);
+
+	/* Configure PHY PLL register bank 1 */
+	val = NS2_PLL1_ACTRL2_MAGIC;
+	brcm_sata_phy_wr(base, PLL1_REG_BANK, PLL1_ACTRL2, 0x0, val);
+	val = NS2_PLL1_ACTRL3_MAGIC;
+	brcm_sata_phy_wr(base, PLL1_REG_BANK, PLL1_ACTRL3, 0x0, val);
+	val = NS2_PLL1_ACTRL4_MAGIC;
+	brcm_sata_phy_wr(base, PLL1_REG_BANK, PLL1_ACTRL4, 0x0, val);
+
+	/* Configure PHY BLOCK0 register bank */
+	/* Set oob_clk_sel to refclk/2 */
+	brcm_sata_phy_wr(base, BLOCK0_REG_BANK, BLOCK0_SPARE,
+			 ~BLOCK0_SPARE_OOB_CLK_SEL_MASK,
+			 BLOCK0_SPARE_OOB_CLK_SEL_REFBY2);
+
+	/* Strobe PHY reset using PHY control register */
+	writel(PHY_CTRL_1_RESET, ctrl_base + PHY_CTRL_1);
+	mdelay(1);
+	writel(0x0, ctrl_base + PHY_CTRL_1);
+	mdelay(1);
+
+	/* Wait for PHY PLL lock by polling pll_lock bit */
+	try = 50;
+	while (try) {
+		val = brcm_sata_phy_rd(base, BLOCK0_REG_BANK,
+					BLOCK0_XGXSSTATUS);
+		if (val & BLOCK0_XGXSSTATUS_PLL_LOCK)
+			break;
+		msleep(20);
+		try--;
+	}
+	if (!try) {
+		/* PLL did not lock; give up */
+		dev_err(dev, "port%d PLL did not lock\n", port->portnum);
+		return -ETIMEDOUT;
+	}
+
+	dev_dbg(dev, "port%d initialized\n", port->portnum);
+
+	return 0;
 }
 
 static int brcm_sata_phy_init(struct phy *phy)
 {
+	int rc;
 	struct brcm_sata_port *port = phy_get_drvdata(phy);
 
-	brcm_sata_cfg_ssc(port);
+	switch (port->phy_priv->version) {
+	case BRCM_SATA_PHY_STB_28NM:
+	case BRCM_SATA_PHY_STB_40NM:
+		rc = brcm_stb_sata_init(port);
+		break;
+	case BRCM_SATA_PHY_IPROC_NS2:
+		rc = brcm_ns2_sata_init(port);
+		break;
+	default:
+		rc = -ENODEV;
+	};
 
 	return 0;
 }
@@ -146,9 +298,11 @@ static const struct phy_ops phy_ops = {
 
 static const struct of_device_id brcm_sata_phy_of_match[] = {
 	{ .compatible	= "brcm,bcm7445-sata-phy",
-	  .data = (void *)BRCM_SATA_PHY_28NM },
+	  .data = (void *)BRCM_SATA_PHY_STB_28NM },
 	{ .compatible	= "brcm,bcm7425-sata-phy",
-	  .data = (void *)BRCM_SATA_PHY_40NM },
+	  .data = (void *)BRCM_SATA_PHY_STB_40NM },
+	{ .compatible	= "brcm,iproc-ns2-sata-phy",
+	  .data = (void *)BRCM_SATA_PHY_IPROC_NS2 },
 	{},
 };
 MODULE_DEVICE_TABLE(of, brcm_sata_phy_of_match);
@@ -181,7 +335,15 @@ static int brcm_sata_phy_probe(struct platform_device *pdev)
 	if (of_id)
 		priv->version = (enum brcm_sata_phy_version)of_id->data;
 	else
-		priv->version = BRCM_SATA_PHY_28NM;
+		priv->version = BRCM_SATA_PHY_STB_28NM;
+
+	if (priv->version == BRCM_SATA_PHY_IPROC_NS2) {
+		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+						   "phy-ctrl");
+		priv->ctrl_base = devm_ioremap_resource(dev, res);
+		if (IS_ERR(priv->ctrl_base))
+			return PTR_ERR(priv->ctrl_base);
+	}
 
 	for_each_available_child_of_node(dn, child) {
 		unsigned int id;
-- 
1.9.1



From anup.patel at broadcom.com  Mon Feb 15 22:33:38 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Tue, 16 Feb 2016 12:03:38 +0530
Subject: [PATCH 3/5] dt-bindings: phy: bindings document for common Broadcom
 SATA3 PHY driver
In-Reply-To: <1455604420-11300-1-git-send-email-anup.patel@broadcom.com>
References: <1455604420-11300-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <1455604420-11300-4-git-send-email-anup.patel@broadcom.com>

This patch:
1. Renames DT bindings document of Broadcom STB SATA3 PHY driver to
common Broadcom SATA3 PHY driver bindings document
2. Adds bindings info for NS2 SATA3 PHY

Signed-off-by: Anup Patel <anup.patel at broadcom.com>
---
 .../phy/{brcm,brcmstb-sata-phy.txt => brcm-sata-phy.txt}  | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)
 rename Documentation/devicetree/bindings/phy/{brcm,brcmstb-sata-phy.txt => brcm-sata-phy.txt} (69%)

diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-sata-phy.txt b/Documentation/devicetree/bindings/phy/brcm-sata-phy.txt
similarity index 69%
rename from Documentation/devicetree/bindings/phy/brcm,brcmstb-sata-phy.txt
rename to Documentation/devicetree/bindings/phy/brcm-sata-phy.txt
index d87ab7c..d023120 100644
--- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-sata-phy.txt
+++ b/Documentation/devicetree/bindings/phy/brcm-sata-phy.txt
@@ -1,14 +1,17 @@
-* Broadcom SATA3 PHY for STB
+* Broadcom SATA3 PHY
 
 Required properties:
 - compatible: should be one or more of
      "brcm,bcm7425-sata-phy"
      "brcm,bcm7445-sata-phy"
+     "brcm,iproc-ns2-sata-phy"
      "brcm,phy-sata3"
 - address-cells: should be 1
 - size-cells: should be 0
-- reg: register range for the PHY PCB interface
-- reg-names: should be "phy"
+- reg: register ranges for the PHY PCB interface
+- reg-names: should be "phy" and "phy-ctrl"
+     The "phy-ctrl" registers are only required for
+     "brcm,iproc-ns2-sata-phy".
 
 Sub-nodes:
   Each port's PHY should be represented as a sub-node.
@@ -16,12 +19,12 @@ Sub-nodes:
 Sub-nodes required properties:
 - reg: the PHY number
 - phy-cells: generic PHY binding; must be 0
-Optional:
-- brcm,enable-ssc: use spread spectrum clocking (SSC) on this port
 
+Sub-nodes optional properties:
+- brcm,enable-ssc: use spread spectrum clocking (SSC) on this port
+     This property is not applicable for "brcm,iproc-ns2-sata-phy".
 
 Example:
-
 	sata-phy at f0458100 {
 		compatible = "brcm,bcm7445-sata-phy", "brcm,phy-sata3";
 		reg = <0xf0458100 0x1e00>, <0xf045804c 0x10>;
-- 
1.9.1



From anup.patel at broadcom.com  Mon Feb 15 22:33:39 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Tue, 16 Feb 2016 12:03:39 +0530
Subject: [PATCH 4/5] dt-bindings: ata: add compatible string for iProc AHCI
 controller
In-Reply-To: <1455604420-11300-1-git-send-email-anup.patel@broadcom.com>
References: <1455604420-11300-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <1455604420-11300-5-git-send-email-anup.patel@broadcom.com>

The Broadcom iProc SoCs have AHCI compliant SATA controller. This
patch adds common compatible string for AHCI SATA controller on
iProc SoCs.

Signed-off-by: Anup Patel <anup.patel at broadcom.com>
---
 Documentation/devicetree/bindings/ata/ahci-platform.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index c2340ee..caee721 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -10,6 +10,7 @@ PHYs.
 Required properties:
 - compatible        : compatible string, one of:
   - "allwinner,sun4i-a10-ahci"
+  - "brcm,iproc-ahci"
   - "hisilicon,hisi-ahci"
   - "ibm,476gtr-ahci"
   - "marvell,armada-380-ahci"
-- 
1.9.1



From anup.patel at broadcom.com  Mon Feb 15 22:33:40 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Tue, 16 Feb 2016 12:03:40 +0530
Subject: [PATCH 5/5] arm64: dts: Add SATA3 AHCI and SATA3 PHY DT nodes for NS2
In-Reply-To: <1455604420-11300-1-git-send-email-anup.patel@broadcom.com>
References: <1455604420-11300-1-git-send-email-anup.patel@broadcom.com>
Message-ID: <1455604420-11300-6-git-send-email-anup.patel@broadcom.com>

We have one dual-port SATA3 AHCI controller present in
NS2 SoC.

This patch enables SATA3 AHCI controller and SATA3 PHY
for NS2 SoC in NS2 DT.

Signed-off-by: Anup Patel <anup.patel at broadcom.com>
Reviewed-by: Ray Jui <rjui at broadcom.com>
Reviewed-by: Scott Branden <sbranden at broadcom.com>
---
 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12 +++++++++
 arch/arm64/boot/dts/broadcom/ns2.dtsi    | 43 ++++++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index ce0ab84..06cf9c5 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -72,6 +72,18 @@
 	status = "ok";
 };
 
+&sata_phy0 {
+	status = "ok";
+};
+
+&sata_phy1 {
+	status = "ok";
+};
+
+&sata {
+	status = "ok";
+};
+
 &sdio0 {
 	status = "ok";
 };
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 6f81c9d..c8dccf8 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -413,6 +413,49 @@
 			reg = <0x66220000 0x28>;
 		};
 
+		sata_phy: sata_phy at 663f0100 {
+			compatible = "brcm,iproc-ns2-sata-phy";
+			reg = <0x663f0100 0x1f00>,
+			      <0x663f004c 0x10>;
+			reg-names = "phy", "phy-ctrl";
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			sata_phy0: sata-phy at 0 {
+				reg = <0>;
+				#phy-cells = <0>;
+				status = "disabled";
+			};
+
+			sata_phy1: sata-phy at 1 {
+				reg = <1>;
+				#phy-cells = <0>;
+				status = "disabled";
+			};
+		};
+
+		sata: ahci at 663f2000 {
+			compatible = "brcm,iproc-ahci", "generic-ahci";
+			reg = <0x663f2000 0x1000>;
+			reg-names = "ahci";
+			interrupts = <GIC_SPI 438 IRQ_TYPE_LEVEL_HIGH>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disabled";
+
+			sata0: sata-port at 0 {
+				reg = <0>;
+				phys = <&sata_phy0>;
+				phy-names = "sata-phy";
+			};
+
+			sata1: sata-port at 1 {
+				reg = <1>;
+				phys = <&sata_phy1>;
+				phy-names = "sata-phy";
+			};
+		};
+
 		sdio0: sdhci at 66420000 {
 			compatible = "brcm,sdhci-iproc-cygnus";
 			reg = <0x66420000 0x100>;
-- 
1.9.1



From geert at linux-m68k.org  Mon Feb 15 22:37:00 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 16 Feb 2016 07:37:00 +0100
Subject: [PATCH] ARM: dts: r8a7794: replace gpio-key,wakeup with
 wakeup-source property
In-Reply-To: <1455572925-27697-1-git-send-email-horms+renesas@verge.net.au>
References: <1455572925-27697-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <CAMuHMdWo-tRQCRfDRrceAPaHMBMtPe15tPnMH1yjkhjpDwTSaA@mail.gmail.com>

On Mon, Feb 15, 2016 at 10:48 PM, Simon Horman
<horms+renesas at verge.net.au> wrote:
> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
> check for/support the legacy "gpio-key,wakeup" boolean property to
> enable gpio buttons as wakeup source, "wakeup-source" is the new
> standard binding.
>
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property in order to avoid any futher copy-paste
> duplication.
>
> Changelog text from a similar patch by Sudeep Holla.
>
> Cc: Sudeep Holla <sudeep.holla at arm.com>
> Reported-by: Geert Uytterhoeven <geert+renesas at glider.be>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From majun258 at huawei.com  Mon Feb 15 22:37:24 2016
From: majun258 at huawei.com (MaJun)
Date: Tue, 16 Feb 2016 14:37:24 +0800
Subject: [PATCH v2 1/5] dt-binding: Change the mbigen binding file to support
 the mbigen-v1
In-Reply-To: <1455604648-20668-1-git-send-email-majun258@huawei.com>
References: <1455604648-20668-1-git-send-email-majun258@huawei.com>
Message-ID: <1455604648-20668-2-git-send-email-majun258@huawei.com>

From: Ma Jun <majun258 at huawei.com>

Add the "hisilicon,mbigen-v1" string in binding file.
Signed-off-by: Ma Jun <majun258 at huawei.com>
---
 .../interrupt-controller/hisilicon,mbigen-v2.txt   |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
index 720f7c9..bdd1dea 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
@@ -16,7 +16,7 @@ The mbigen chip and devices connect to mbigen have the following properties:
 
 Mbigen main node required properties:
 -------------------------------------------
-- compatible: Should be "hisilicon,mbigen-v2"
+- compatible: Should be "hisilicon,mbigen-v2" or "hisilicon,mbigen-v1"
 
 - reg: Specifies the base physical address and size of the Mbigen
   registers.
-- 
1.7.1




From majun258 at huawei.com  Mon Feb 15 22:37:25 2016
From: majun258 at huawei.com (MaJun)
Date: Tue, 16 Feb 2016 14:37:25 +0800
Subject: [PATCH v2 2/5] dt-binding:Rename the mbigen binding file name
In-Reply-To: <1455604648-20668-1-git-send-email-majun258@huawei.com>
References: <1455604648-20668-1-git-send-email-majun258@huawei.com>
Message-ID: <1455604648-20668-3-git-send-email-majun258@huawei.com>

From: Ma Jun <majun258 at huawei.com>

Because added the mbigen-v1 compatible string, the origin name is
not suitable any more. So,I remove the version number from file name.

Signed-off-by: Ma Jun <majun258 at huawei.com>
---
 .../interrupt-controller/hisilicon,mbigen-v2.txt   |   74 --------------------
 .../interrupt-controller/hisilicon,mbigen.txt      |   74 ++++++++++++++++++++
 2 files changed, 74 insertions(+), 74 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen.txt

diff --git a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
deleted file mode 100644
index bdd1dea..0000000
--- a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-Hisilicon mbigen device tree bindings.
-=======================================
-
-Mbigen means: message based interrupt generator.
-
-MBI is kind of msi interrupt only used on Non-PCI devices.
-
-To reduce the wired interrupt number connected to GIC,
-Hisilicon designed mbigen to collect and generate interrupt.
-
-
-Non-pci devices can connect to mbigen and generate the
-interrupt by writing ITS register.
-
-The mbigen chip and devices connect to mbigen have the following properties:
-
-Mbigen main node required properties:
--------------------------------------------
-- compatible: Should be "hisilicon,mbigen-v2" or "hisilicon,mbigen-v1"
-
-- reg: Specifies the base physical address and size of the Mbigen
-  registers.
-
-- interrupt controller: Identifies the node as an interrupt controller
-
-- msi-parent: Specifies the MSI controller this mbigen use.
-  For more detail information,please refer to the generic msi-parent binding in
-  Documentation/devicetree/bindings/interrupt-controller/msi.txt.
-
-- num-pins: the total number of pins implemented in this Mbigen
-  instance.
-
-- #interrupt-cells : Specifies the number of cells needed to encode an
-  interrupt source. The value must be 2.
-
-  The 1st cell is hardware pin number of the interrupt.This number is local to
-  each mbigen chip and in the range from 0 to the maximum interrupts number
-  of the mbigen.
-
-  The 2nd cell is the interrupt trigger type.
-	The value of this cell should be:
-	1: rising edge triggered
-	or
-	4: high level triggered
-
-Examples:
-
-	mbigen_device_gmac:intc {
-			compatible = "hisilicon,mbigen-v2";
-			reg = <0x0 0xc0080000 0x0 0x10000>;
-			interrupt-controller;
-			msi-parent = <&its_dsa 0x40b1c>;
-			num-pins = <9>;
-			#interrupt-cells = <2>;
-	};
-
-Devices connect to mbigen required properties:
-----------------------------------------------------
--interrupt-parent: Specifies the mbigen device node which device connected.
-
--interrupts:Specifies the interrupt source.
- For the specific information of each cell in this property,please refer to
- the "interrupt-cells" description mentioned above.
-
-Examples:
-	gmac0: ethernet at c2080000 {
-		#address-cells = <1>;
-		#size-cells = <0>;
-		reg = <0 0xc2080000 0 0x20000>,
-		      <0 0xc0000000 0 0x1000>;
-		interrupt-parent  = <&mbigen_device_gmac>;
-		interrupts =	<656 1>,
-				<657 1>;
-	};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen.txt b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen.txt
new file mode 100644
index 0000000..bdd1dea
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen.txt
@@ -0,0 +1,74 @@
+Hisilicon mbigen device tree bindings.
+=======================================
+
+Mbigen means: message based interrupt generator.
+
+MBI is kind of msi interrupt only used on Non-PCI devices.
+
+To reduce the wired interrupt number connected to GIC,
+Hisilicon designed mbigen to collect and generate interrupt.
+
+
+Non-pci devices can connect to mbigen and generate the
+interrupt by writing ITS register.
+
+The mbigen chip and devices connect to mbigen have the following properties:
+
+Mbigen main node required properties:
+-------------------------------------------
+- compatible: Should be "hisilicon,mbigen-v2" or "hisilicon,mbigen-v1"
+
+- reg: Specifies the base physical address and size of the Mbigen
+  registers.
+
+- interrupt controller: Identifies the node as an interrupt controller
+
+- msi-parent: Specifies the MSI controller this mbigen use.
+  For more detail information,please refer to the generic msi-parent binding in
+  Documentation/devicetree/bindings/interrupt-controller/msi.txt.
+
+- num-pins: the total number of pins implemented in this Mbigen
+  instance.
+
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The value must be 2.
+
+  The 1st cell is hardware pin number of the interrupt.This number is local to
+  each mbigen chip and in the range from 0 to the maximum interrupts number
+  of the mbigen.
+
+  The 2nd cell is the interrupt trigger type.
+	The value of this cell should be:
+	1: rising edge triggered
+	or
+	4: high level triggered
+
+Examples:
+
+	mbigen_device_gmac:intc {
+			compatible = "hisilicon,mbigen-v2";
+			reg = <0x0 0xc0080000 0x0 0x10000>;
+			interrupt-controller;
+			msi-parent = <&its_dsa 0x40b1c>;
+			num-pins = <9>;
+			#interrupt-cells = <2>;
+	};
+
+Devices connect to mbigen required properties:
+----------------------------------------------------
+-interrupt-parent: Specifies the mbigen device node which device connected.
+
+-interrupts:Specifies the interrupt source.
+ For the specific information of each cell in this property,please refer to
+ the "interrupt-cells" description mentioned above.
+
+Examples:
+	gmac0: ethernet at c2080000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0 0xc2080000 0 0x20000>,
+		      <0 0xc0000000 0 0x1000>;
+		interrupt-parent  = <&mbigen_device_gmac>;
+		interrupts =	<656 1>,
+				<657 1>;
+	};
-- 
1.7.1




From majun258 at huawei.com  Mon Feb 15 22:37:23 2016
From: majun258 at huawei.com (MaJun)
Date: Tue, 16 Feb 2016 14:37:23 +0800
Subject: [PATCH v2 0/5] irqchip: Add support for Hisilicon mbigen v1 chip
Message-ID: <1455604648-20668-1-git-send-email-majun258@huawei.com>

From: Ma Jun <majun258 at huawei.com>

This patch set is used to support the mbigen v1 chip.
Compared to mbigen v2 chip, the main difference between them is
register layout(address,format)

As a sequence of this difference, the functions used to get or calculate
register address are also changed for this reason.

Changes in v2:
--- Fixed the build test error when applied patch v1 3/5

Ma Jun (5):
  dt-binding: Change the mbigen binding file to support the mbigen-v1
  dt-binding:Rename the mbigen binding file name
  irqchip: add platform device driver for mbigen device
  irqchip:create irq domain for each mbigen device
  irqchip:implement the mbigen irq chip operation functions

 .../interrupt-controller/hisilicon,mbigen-v2.txt   |   74 -----
 .../interrupt-controller/hisilicon,mbigen.txt      |   74 +++++
 drivers/irqchip/Makefile                           |    2 +-
 drivers/irqchip/irq-mbigen-v1.c                    |  287 ++++++++++++++++++++
 4 files changed, 362 insertions(+), 75 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen-v2.txt
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/hisilicon,mbigen.txt
 create mode 100644 drivers/irqchip/irq-mbigen-v1.c




From majun258 at huawei.com  Mon Feb 15 22:37:28 2016
From: majun258 at huawei.com (MaJun)
Date: Tue, 16 Feb 2016 14:37:28 +0800
Subject: [PATCH v2 5/5] irqchip:implement the mbigen irq chip operation
 functions
In-Reply-To: <1455604648-20668-1-git-send-email-majun258@huawei.com>
References: <1455604648-20668-1-git-send-email-majun258@huawei.com>
Message-ID: <1455604648-20668-6-git-send-email-majun258@huawei.com>

From: Ma Jun <majun258 at huawei.com>

Add the interrupt controller chip operation functions of mbigen chip.

Signed-off-by: Ma Jun <majun258 at huawei.com>
---
 drivers/irqchip/irq-mbigen-v1.c |   75 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen-v1.c b/drivers/irqchip/irq-mbigen-v1.c
index 61e7ad0..0636165 100644
--- a/drivers/irqchip/irq-mbigen-v1.c
+++ b/drivers/irqchip/irq-mbigen-v1.c
@@ -41,6 +41,20 @@
 #define REG_MBIGEN_EXT_VEC_OFFSET		0x320
 
 /**
+ * offset of clear register in mbigen node
+ * This register is used to clear the status
+ * of interrupt
+ */
+#define REG_MBIGEN_CLEAR_OFFSET		0x100
+
+/**
+ * offset of interrupt type register
+ * This register is used to configure interrupt
+ * trigger type
+ */
+#define REG_MBIGEN_TYPE_OFFSET		0x0
+
+/**
  * struct mbigen_device - holds the information of mbigen device.
  *
  * @pdev:		pointer to the platform device structure of mbigen chip.
@@ -77,8 +91,69 @@ static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq)
 		return (nid - 4) * 4 + REG_MBIGEN_EXT_VEC_OFFSET;
 }
 
+static inline void get_mbigen_type_reg(irq_hw_number_t hwirq,
+					u32 *mask, u32 *addr)
+{
+	int ofst;
+
+	ofst = hwirq / 32 * 4;
+	*mask = 1 << (hwirq % 32);
+
+	*addr = ofst + REG_MBIGEN_TYPE_OFFSET;
+}
+
+static inline void get_mbigen_clear_reg(irq_hw_number_t hwirq,
+					u32 *mask, u32 *addr)
+{
+	unsigned int ofst;
+
+	ofst = hwirq / 32 * 4;
+
+	*mask = 1 << (hwirq % 32);
+	*addr = ofst + REG_MBIGEN_CLEAR_OFFSET;
+}
+
+static void mbigen_eoi_irq(struct irq_data *data)
+{
+	void __iomem *base = data->chip_data;
+	u32 mask, addr;
+
+	get_mbigen_clear_reg(data->hwirq, &mask, &addr);
+
+	writel_relaxed(mask, base + addr);
+
+	irq_chip_eoi_parent(data);
+}
+
+static int mbigen_set_type(struct irq_data *data, unsigned int type)
+{
+	void __iomem *base = data->chip_data;
+	u32 mask, addr, val;
+
+	if (type != IRQ_TYPE_LEVEL_HIGH && type != IRQ_TYPE_EDGE_RISING)
+		return -EINVAL;
+
+	get_mbigen_type_reg(data->hwirq, &mask, &addr);
+
+	val = readl_relaxed(base + addr);
+
+	if (type == IRQ_TYPE_LEVEL_HIGH)
+		val |= mask;
+	else
+		val &= ~mask;
+
+	writel_relaxed(val, base + addr);
+
+	return 0;
+}
+
 static struct irq_chip mbigen_irq_chip = {
 	.name =			"mbigen-v1",
+	.irq_mask =		irq_chip_mask_parent,
+	.irq_unmask =		irq_chip_unmask_parent,
+	.irq_eoi =		mbigen_eoi_irq,
+	.irq_set_type =		mbigen_set_type,
+	.irq_set_affinity =	irq_chip_set_affinity_parent,
 };
 
 static void mbigen_write_msg(struct msi_desc *desc, struct msi_msg *msg)
-- 
1.7.1




From majun258 at huawei.com  Mon Feb 15 22:37:27 2016
From: majun258 at huawei.com (MaJun)
Date: Tue, 16 Feb 2016 14:37:27 +0800
Subject: [PATCH v2 4/5] irqchip:create irq domain for each mbigen device
In-Reply-To: <1455604648-20668-1-git-send-email-majun258@huawei.com>
References: <1455604648-20668-1-git-send-email-majun258@huawei.com>
Message-ID: <1455604648-20668-5-git-send-email-majun258@huawei.com>

From: Ma Jun <majun258 at huawei.com>

For peripheral devices which connect to mbigen,mbigen is a interrupt
controller. So, we create irq domain for each mbigen device and add
mbigen irq domain into irq hierarchy structure.

Signed-off-by: Ma Jun <majun258 at huawei.com>
---
 drivers/irqchip/irq-mbigen-v1.c |  136 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 136 insertions(+), 0 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen-v1.c b/drivers/irqchip/irq-mbigen-v1.c
index 9445658..61e7ad0 100644
--- a/drivers/irqchip/irq-mbigen-v1.c
+++ b/drivers/irqchip/irq-mbigen-v1.c
@@ -16,11 +16,30 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/interrupt.h>
+#include <linux/irqchip.h>
 #include <linux/module.h>
+#include <linux/msi.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 
+/* The maximum IRQ pin number of mbigen chip(start from 0) */
+#define MAXIMUM_IRQ_PIN_NUM		640
+
+/**
+ * In mbigen vector register
+ * bit[31:16]:	device id
+ * bit[15:0]:	event id value
+ */
+#define IRQ_EVENT_ID_MASK		0xffff
+
+/* offset of vector register in mbigen node */
+#define REG_MBIGEN_VEC_OFFSET		0x300
+#define REG_MBIGEN_EXT_VEC_OFFSET		0x320
+
 /**
  * struct mbigen_device - holds the information of mbigen device.
  *
@@ -32,10 +51,112 @@ struct mbigen_device {
 	void __iomem		*base;
 };
 
+static int get_mbigen_nid(unsigned int offset)
+{
+	int nid = 0;
+
+	if (offset < 256)
+		nid = offset / 64;
+	else if (offset < 384)
+		nid = 4;
+	else if (offset < 640)
+		nid = 5;
+
+	return nid;
+}
+
+static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq)
+{
+	unsigned int nid;
+
+	nid = get_mbigen_nid(hwirq);
+
+	if (nid < 4)
+		return (nid * 4) + REG_MBIGEN_VEC_OFFSET;
+	else
+		return (nid - 4) * 4 + REG_MBIGEN_EXT_VEC_OFFSET;
+}
+
+static struct irq_chip mbigen_irq_chip = {
+	.name =			"mbigen-v1",
+};
+
+static void mbigen_write_msg(struct msi_desc *desc, struct msi_msg *msg)
+{
+	/* The address of doorbell is encoded in mbigen register by default
+	 * So,we don't need to program the doorbell address at here
+	 * Besides, the event ID is decided by the hardware pin number,
+	 * we can't change it in software.So, we don't need to encode the
+	 * event ID in mbigen register.
+	 */
+}
+
+static int mbigen_domain_translate(struct irq_domain *d,
+				    struct irq_fwspec *fwspec,
+				    unsigned long *hwirq,
+				    unsigned int *type)
+{
+	if (is_of_node(fwspec->fwnode)) {
+		if (fwspec->param_count != 2)
+			return -EINVAL;
+
+		if (fwspec->param[0] > MAXIMUM_IRQ_PIN_NUM)
+			return -EINVAL;
+
+		*hwirq = fwspec->param[0];
+
+		/* If there is no valid irq type, just use the default type */
+		if ((fwspec->param[1] == IRQ_TYPE_EDGE_RISING) ||
+			(fwspec->param[1] == IRQ_TYPE_LEVEL_HIGH))
+			*type = fwspec->param[1];
+		else
+			return -EINVAL;
+
+		return 0;
+	}
+	return -EINVAL;
+}
+
+static int mbigen_irq_domain_alloc(struct irq_domain *domain,
+					unsigned int virq,
+					unsigned int nr_irqs,
+					void *args)
+{
+	struct irq_fwspec *fwspec = args;
+	irq_hw_number_t hwirq;
+	unsigned int type;
+	struct mbigen_device *mgn_chip;
+	int i, err;
+
+	err = mbigen_domain_translate(domain, fwspec, &hwirq, &type);
+	if (err)
+		return err;
+
+	err = platform_msi_domain_alloc(domain, virq, nr_irqs);
+	if (err)
+		return err;
+
+	mgn_chip = platform_msi_get_host_data(domain);
+
+	for (i = 0; i < nr_irqs; i++)
+		irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
+				      &mbigen_irq_chip, mgn_chip->base);
+
+	return 0;
+}
+
+static struct irq_domain_ops mbigen_domain_ops = {
+	.translate	= mbigen_domain_translate,
+	.alloc		= mbigen_irq_domain_alloc,
+	.free		= irq_domain_free_irqs_common,
+};
+
 static int mbigen_device_probe(struct platform_device *pdev)
 {
 	struct mbigen_device *mgn_chip;
 	struct resource *res;
+	struct irq_domain *domain;
+	u32 num_pins;
 
 	mgn_chip = devm_kzalloc(&pdev->dev, sizeof(*mgn_chip), GFP_KERNEL);
 	if (!mgn_chip)
@@ -48,8 +169,23 @@ static int mbigen_device_probe(struct platform_device *pdev)
 	if (IS_ERR(mgn_chip->base))
 		return PTR_ERR(mgn_chip->base);
 
+	if (of_property_read_u32(pdev->dev.of_node, "num-pins", &num_pins) < 0) {
+		dev_err(&pdev->dev, "No num-pins property\n");
+		return -EINVAL;
+	}
+
+	domain = platform_msi_create_device_domain(&pdev->dev, num_pins,
+							mbigen_write_msg,
+							&mbigen_domain_ops,
+							mgn_chip);
+
+	if (!domain)
+		return -ENOMEM;
+
 	platform_set_drvdata(pdev, mgn_chip);
 
+	dev_info(&pdev->dev, "Allocated %d MSIs\n", num_pins);
+
 	return 0;
 }
 
-- 
1.7.1




From majun258 at huawei.com  Mon Feb 15 22:37:26 2016
From: majun258 at huawei.com (MaJun)
Date: Tue, 16 Feb 2016 14:37:26 +0800
Subject: [PATCH v2 3/5] irqchip: add platform device driver for mbigen device
In-Reply-To: <1455604648-20668-1-git-send-email-majun258@huawei.com>
References: <1455604648-20668-1-git-send-email-majun258@huawei.com>
Message-ID: <1455604648-20668-4-git-send-email-majun258@huawei.com>

From: Ma Jun <majun258 at huawei.com>

Add the platform device driver for mbigen chip v1.
This patch just same as mbigen v2.

Signed-off-by: Ma Jun <majun258 at huawei.com>
---
 drivers/irqchip/Makefile        |    2 +-
 drivers/irqchip/irq-mbigen-v1.c |   76 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 77 insertions(+), 1 deletions(-)
 create mode 100644 drivers/irqchip/irq-mbigen-v1.c

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index d91d99d..d4b9c7f 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -25,7 +25,7 @@ obj-$(CONFIG_REALVIEW_DT)		+= irq-gic-realview.o
 obj-$(CONFIG_ARM_GIC_V2M)		+= irq-gic-v2m.o
 obj-$(CONFIG_ARM_GIC_V3)		+= irq-gic-v3.o irq-gic-common.o
 obj-$(CONFIG_ARM_GIC_V3_ITS)		+= irq-gic-v3-its.o irq-gic-v3-its-pci-msi.o irq-gic-v3-its-platform-msi.o
-obj-$(CONFIG_HISILICON_IRQ_MBIGEN)	+= irq-mbigen.o
+obj-$(CONFIG_HISILICON_IRQ_MBIGEN)	+= irq-mbigen.o irq-mbigen-v1.o
 obj-$(CONFIG_ARM_NVIC)			+= irq-nvic.o
 obj-$(CONFIG_ARM_VIC)			+= irq-vic.o
 obj-$(CONFIG_ATMEL_AIC_IRQ)		+= irq-atmel-aic-common.o irq-atmel-aic.o
diff --git a/drivers/irqchip/irq-mbigen-v1.c b/drivers/irqchip/irq-mbigen-v1.c
new file mode 100644
index 0000000..9445658
--- /dev/null
+++ b/drivers/irqchip/irq-mbigen-v1.c
@@ -0,0 +1,76 @@
+/*
+ * Copyright (C) 2015 Hisilicon Limited, All Rights Reserved.
+ * Author: Jun Ma <majun258 at huawei.com>
+ * Author: Yun Wu <wuyun.wu at huawei.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/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+/**
+ * struct mbigen_device - holds the information of mbigen device.
+ *
+ * @pdev:		pointer to the platform device structure of mbigen chip.
+ * @base:		mapped address of this mbigen chip.
+ */
+struct mbigen_device {
+	struct platform_device	*pdev;
+	void __iomem		*base;
+};
+
+static int mbigen_device_probe(struct platform_device *pdev)
+{
+	struct mbigen_device *mgn_chip;
+	struct resource *res;
+
+	mgn_chip = devm_kzalloc(&pdev->dev, sizeof(*mgn_chip), GFP_KERNEL);
+	if (!mgn_chip)
+		return -ENOMEM;
+
+	mgn_chip->pdev = pdev;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mgn_chip->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(mgn_chip->base))
+		return PTR_ERR(mgn_chip->base);
+
+	platform_set_drvdata(pdev, mgn_chip);
+
+	return 0;
+}
+
+static const struct of_device_id mbigen_of_match[] = {
+	{ .compatible = "hisilicon,mbigen-v1" },
+	{ /* END */ }
+};
+MODULE_DEVICE_TABLE(of, mbigen_of_match);
+
+static struct platform_driver mbigen_platform_driver = {
+	.driver = {
+		.name		= "Hisilicon MBIGEN-V1",
+		.owner		= THIS_MODULE,
+		.of_match_table	= mbigen_of_match,
+	},
+	.probe			= mbigen_device_probe,
+};
+
+module_platform_driver(mbigen_platform_driver);
+
+MODULE_AUTHOR("Jun Ma <majun258 at huawei.com>");
+MODULE_AUTHOR("Yun Wu <wuyun.wu at huawei.com>");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Hisilicon MBI Generator driver");
-- 
1.7.1




From dirk.behme at de.bosch.com  Mon Feb 15 22:40:49 2016
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Tue, 16 Feb 2016 07:40:49 +0100
Subject: [PATCH v3 6/7] arm64: dts: r8a7795: Add missing properties to
 CA57 L2 cache node
In-Reply-To: <1455568715-20880-7-git-send-email-geert+renesas@glider.be>
References: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
 <1455568715-20880-7-git-send-email-geert+renesas@glider.be>
Message-ID: <56C2C471.80000@de.bosch.com>

On 15.02.2016 21:38, Geert Uytterhoeven wrote:
> Add the missing "cache-unified" and "cache-level" properties to the
> Cortex-A57 cache-controller node.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> ---
> v3:
>    - Remaining part of "[PATCH v2 6/6] arm64: renesas: r8a7795: Add L2
>      cache-controller nodes", after dropping the "arm,data-latency" and
>      "arm,tag-latency" properties.
> ---
>   arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index b5e46e4ff72ad003..c07f4e83b988ba42 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -68,6 +68,8 @@
>
>   	L2_CA57: cache-controller at 0 {
>   		compatible = "cache";
> +		cache-unified;
> +		cache-level = <2>;


As this is completely unused on ARMv8 I don't think that we want to have 
these unused entries in the DT.

Sudeep: What do you think?

Best regards

Dirk




From dirk.behme at de.bosch.com  Mon Feb 15 22:44:04 2016
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Tue, 16 Feb 2016 07:44:04 +0100
Subject: [PATCH v3 7/7] arm64: dts: r8a7795: Add CA53 L2 cache-controller
 node
In-Reply-To: <1455568715-20880-8-git-send-email-geert+renesas@glider.be>
References: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
 <1455568715-20880-8-git-send-email-geert+renesas@glider.be>
Message-ID: <56C2C534.30704@de.bosch.com>

On 15.02.2016 21:38, Geert Uytterhoeven wrote:
> Add a device node for the Cortex-A53 L2 cache-controller.
>
> The L2 cache for the Cortex-A53 CPU cores is 512 KiB large (organized as
> 32 KiB x 16 ways).
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> ---
> v3:
>    - Remaining part of "[PATCH v2 6/6] arm64: renesas: r8a7795: Add L2
>      cache-controller nodes".
> ---
>   arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 ++++++
>   1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index c07f4e83b988ba42..c572527afec3403a 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -72,6 +72,12 @@
>   		cache-level = <2>;
>   	};
>
> +	L2_CA53: cache-controller at 1 {
> +		compatible = "cache";
> +		cache-unified;
> +		cache-level = <2>;
> +	};
> +


As we don't have any CA53 in the device tree yet, and it was rejected to 
add it, I'd think that we don't want these unused entries at the moment.

I'd propose to add the CA53 entries, first. And then add their L2 cache 
entries.

Based on the outcome of the discussion for the CA57 we have to see if we 
want to add the unused cache-unified and cache-level, then, too.

Best regards

Dirk




From tiffany.lin at mediatek.com  Mon Feb 15 22:46:38 2016
From: tiffany.lin at mediatek.com (tiffany lin)
Date: Tue, 16 Feb 2016 14:46:38 +0800
Subject: [PATCH v4 0/8] Add MT8173 Video Encoder Driver and VPU Driver
In-Reply-To: <56C1BEE3.4000904@xs4all.nl>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <56C1BEE3.4000904@xs4all.nl>
Message-ID: <1455605198.19396.74.camel@mtksdaap41>

Hi Hans,

On Mon, 2016-02-15 at 13:04 +0100, Hans Verkuil wrote:
> Hi Tiffany,
> 
> Once again, thanks for your patch series!
> 
> I have some more comments below.
> 
> On 02/04/2016 12:34 PM, Tiffany Lin wrote:
> > 
> > ==============
> >  Introduction
> > ==============
> > 
> > The purpose of this series is to add the driver for video codec hw embedded in the Mediatek's MT8173 SoCs.
> > Mediatek Video Codec is able to handle video encoding of in a range of formats.
> > 
> > This patch series also include VPU driver. Mediatek Video Codec driver rely on VPU driver to load, communicate with VPU.
> > 
> > Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI.
> > MTK IOMMU[1] and MTK SMI[2] have not yet been merged, but we wanted to start discussion about the driver earlier so it could be merged sooner.
> > 
> > [1]https://patchwork.kernel.org/patch/8120921/
> > [2]https://patchwork.kernel.org/patch/8120941/
> > 
> > 
> > ==================
> >  Device interface
> > ==================
> > 
> > In principle the driver bases on v4l2 memory-to-memory framework:
> > it provides a single video node and each opened file handle gets its own private context with separate buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source buffers, i.e. raw video frames) and CAPTURE (for destination buffers, i.e. encoded video frames).
> > 
> > ==============================
> >  VPU (Video Processor Unit)
> > ==============================
> > The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
> > It is able to handle video decoding/encoding in a range of formats.
> > The driver provides with VPU firmware download, memory management and the communication interface between CPU and VPU.
> > For VPU initialization, it will create virtual memory for CPU access and physical address for VPU hw device access. When a decode/encode instance opens a device node, vpu driver will download vpu firmware to the device.
> > A decode/encode instant will decode/encode a frame using VPU interface to interrupt vpu to handle decoding/encoding jobs.
> > 
> > Please have a look at the code and comments will be very much appreciated.
> > 
> > 
> > Change in v4:
> > Vcodec Part
> > 1. Remove MTK_ENCODE_PARAM_SKIP_FRAME support
> > 2. Remove MTK_ENCODE_PARAM_FRAME_TYPE and change to use V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME[3]
> > 3. Refine Encoder HW clock source
> > 4. Refine debug log
> > 5. Add watchdog support
> > 6. With patch "media: v4l2-compat-ioctl32: fix missing length copy in put_v4l2_buffer32"[4], v4l2-compliance test passed[5] in v4.4-rc5 
> > 
> > VPU Part
> > 1. These two patches were Acked-by: Rob Herring <robh at kernel.org> in v3
> >    [PATCH v3 1/8] dt-bindings: Add a binding for Mediatek Video Processor
> >    [PATCH v3 3/8] arm64: dts: mediatek: Add node for Mediatek Video Processor Unit
> >    Because we were wrong about how the hardware works, there is no connection between VPU and IOMMU HW
> >    We remove VPU attaching to IOMMU
> > 2. Support VPU running on 4GB DRAM system
> > 3. Support VPU watchdog reset
> > 4. Refine for coding style 
> > 
> > [3]https://patchwork.linuxtv.org/patch/32670/
> > [4] https://patchwork.linuxtv.org/patch/32631/
> > [5]localhost ~ # /usr/bin/v4l2-compliance -d /dev/video1
> > Driver Info:
> >         Driver name   : mtk-vcodec-en
> >         Card type     : platform:mt817
> >         Bus info      : platform:mt817
> 
> Perhaps this should be mt817x?
> 
> >         Driver version: 4.4.0
> >         Capabilities  : 0x84204000
> >                 Video Memory-to-Memory Multiplanar
> >                 Streaming
> >                 Extended Pix Format
> >                 Device Capabilities
> >         Device Caps   : 0x04204000
> >                 Video Memory-to-Memory Multiplanar
> >                 Streaming
> >                 Extended Pix Format
> > 
> > Compliance test for device /dev/video1 (not using libv4l2):
> > 
> > Required ioctls:
> >         test VIDIOC_QUERYCAP: OK
> > 
> > Allow for multiple opens:
> >         test second video open: OK
> >         test VIDIOC_QUERYCAP: OK
> >         test VIDIOC_G/S_PRIORITY: OK
> > 
> > Debug ioctls:
> >         test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> >         test VIDIOC_LOG_STATUS: OK (Not Supported)
> > 
> > Input ioctls:
> >         test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> >         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> >         test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> >         test VIDIOC_ENUMAUDIO: OK (Not Supported)
> >         test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
> >         test VIDIOC_G/S_AUDIO: OK (Not Supported)
> >         Inputs: 0 Audio Inputs: 0 Tuners: 0
> > 
> > Output ioctls:
> >         test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> >         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> >         test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> >         test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> >         test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> >         Outputs: 0 Audio Outputs: 0 Modulators: 0
> > 
> > Input/Output configuration ioctls:
> >         test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> >         test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> >         test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> >         test VIDIOC_G/S_EDID: OK (Not Supported)
> > 
> >         Control ioctls:
> >                 test VIDIOC_QUERYCTRL/MENU: OK
> >                 test VIDIOC_G/S_CTRL: OK
> >                 test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> >                 test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> >                 test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> >                 Standard Controls: 12 Private Controls: 0
> > 
> >         Format ioctls:
> >                 test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> >                 test VIDIOC_G/S_PARM: OK (Not Supported)
> >                 test VIDIOC_G_FBUF: OK (Not Supported)
> >                 test VIDIOC_G_FMT: OK
> >                 test VIDIOC_TRY_FMT: OK
> >                 test VIDIOC_S_FMT: OK
> >                 test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> > 
> >         Codec ioctls:
> >                 test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> >                 test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> >                 test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> > 
> >         Buffer ioctls:
> >                 warn: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(475): VIDIOC_CREATE_BUFS not supported
> >                 warn: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(475): VIDIOC_CREATE_BUFS not supported
> >                 test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> >                 test VIDIOC_EXPBUF: OK
> > 
> > Total: 38, Succeeded: 38, Failed: 0, Warnings: 2
> 
> Looks great!
> 
> Having reviewed the v4 patch series I'd say it is close to being ready (at least
> w.r.t. the V4L2 parts). Most of my comments are minor, but fixing the open()
> limitation is probably a bigger change on your side.
> 
> It should be well worth the effort, though. In my experience limiting the number
> of time you can call open() is always a sign of a design flaw and the code improves
> if this is handled in the right place (usually start_streaming, which is when you
> actually start to use the hardware).
> 
> And besides, limiting the number of open()s is out-of-spec.
> 
You are right. We did not think about this before.
We will remove open() limitation and put limitation control in right
place.
Appreciated your time and suggestions.



> Regards,
> 
> 	Hans
> 
> > 
> > 
> > Change in v3:
> > 1.Refine code to pass v4l2-compliance test, now it still has 2 issues 2.Refine code according to latest MTK IOMMU patches[1] 3.Remove MFC51 specific CIDs and add MTK specific CIDs for for keyframe and
> >   skip I-frame
> > 4.Refine code according to review comments
> > 
> > Below is the v1.6 version v4l2-compliance report for the mt8173 encoder driver.
> > Now there are still 2 test fail in v1.6.
> > For VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF, we directly use v4l2_m2m_ioctl_* functions, but it still fail. It pass in kernel 3.18 but fail in kernel 4.4.
> > We will try v1.8 in next version.
> > VIDIOC_EXPBUF is becuase we support all three memory types VB2_DMABUF, VB2_MMAP and VB2_USERPTR. VIDIOC_EXPBUF only allowed when only VB2_MMAP supported.
> > localhost ~ # /usr/bin/v4l2-compliance -d /dev/video1 Driver Info:
> >         Driver name   : mtk-vcodec-en
> >         Card type     : platform:mt817
> >         Bus info      : platform:mt817
> >         Driver version: 4.4.0
> >         Capabilities  : 0x84204000
> >                 Video Memory-to-Memory Multiplanar
> >                 Streaming
> >                 Extended Pix Format
> >                 Device Capabilities
> >         Device Caps   : 0x04204000
> >                 Video Memory-to-Memory Multiplanar
> >                 Streaming
> >                 Extended Pix Format
> > 
> > Compliance test for device /dev/video1 (not using libv4l2):
> > 
> > Required ioctls:
> >         test VIDIOC_QUERYCAP: OK
> > 
> > Allow for multiple opens:
> >         test second video open: OK
> >         test VIDIOC_QUERYCAP: OK
> >         test VIDIOC_G/S_PRIORITY: OK
> > 
> > Debug ioctls:
> >         test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> >         test VIDIOC_LOG_STATUS: OK (Not Supported)
> > 
> > Input ioctls:
> >         test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> >         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> >         test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> >         test VIDIOC_ENUMAUDIO: OK (Not Supported)
> >         test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
> >         test VIDIOC_G/S_AUDIO: OK (Not Supported)
> >         Inputs: 0 Audio Inputs: 0 Tuners: 0
> > 
> > Output ioctls:
> >         test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> >         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> >         test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> >         test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> >         test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> >         Outputs: 0 Audio Outputs: 0 Modulators: 0
> > 
> > Input/Output configuration ioctls:
> >         test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> >         test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> >         test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> >         test VIDIOC_G/S_EDID: OK (Not Supported)
> > 
> >         Control ioctls:
> >                 test VIDIOC_QUERYCTRL/MENU: OK
> >                 test VIDIOC_G/S_CTRL: OK
> >                 test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> >                 test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> >                 test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> >                 Standard Controls: 11 Private Controls: 2
> > 
> >         Format ioctls:
> >                 test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> >                 test VIDIOC_G/S_PARM: OK (Not Supported)
> >                 test VIDIOC_G_FBUF: OK (Not Supported)
> >                 test VIDIOC_G_FMT: OK
> >                 test VIDIOC_TRY_FMT: OK
> >                 test VIDIOC_S_FMT: OK
> >                 test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> > 
> >         Codec ioctls:
> >                 test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> >                 test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> >                 test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> > 
> >         Buffer ioctls:
> >                 fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(266): vp->length == 0
> >                 fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(335): buf.check(Unqueued, i)
> >                 fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(420): testQueryBuf(node, i, q.g_buffers())
> >                 test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
> >                 fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(500): q.has_expbuf(node)
> >                 test VIDIOC_EXPBUF: FAIL
> > Total: 38, Succeeded: 36, Failed: 2, Warnings: 0
> > 
> > 
> > Change in v2:
> > Vcodec Part
> > 1.Remove common and include directory in mtk-vcodec 2.Refine vb2ops_venc_start_streaming and vb2ops_venc_stop_streaming and state machine 3.Remove venc_if_init and venc_if_deinit 4.Refine debug message 5.Refine lab and vpu decription in mediatek-vcodec.txt
> > 
> > VPU Part
> > 1. Modify VPU Kconfig
> > 2. Move encoder header files to other patch sets 3. Remove marcos for extended virtual/iova address 4. Change register and variable names 5. Add a reference counter for VPU watchdog 6. Remove one busy waiting in function vpu_ipi_send 7. Operate VPU clock in VPU driver (not called by encoder drivers) 8. Refine memory mapping, firmware download and extended memory allocation/free functions 9. Release more allocated resources in driver remove function
> > 
> > 
> > 
> > Andrew-CT Chen (2):
> >   dt-bindings: Add a binding for Mediatek Video Processor
> >   [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver
> > 
> > Tiffany Lin (6):
> >   [media] VPU: mediatek: support Mediatek VPU
> >   arm64: dts: mediatek: Add node for Mediatek Video Processor Unit
> >   dt-bindings: Add a binding for Mediatek Video Encoder
> >   [media] vcodec: mediatek: Add Mediatek VP8 Video Encoder Driver
> >   [media] vcodec: mediatek: Add Mediatek H264 Video Encoder Driver
> >   arm64: dts: mediatek: Add Video Encoder for MT8173
> > 
> >  .../devicetree/bindings/media/mediatek-vcodec.txt  |   59 +
> >  .../devicetree/bindings/media/mediatek-vpu.txt     |   31 +
> >  arch/arm64/boot/dts/mediatek/mt8173.dtsi           |   62 +
> >  drivers/media/platform/Kconfig                     |   20 +
> >  drivers/media/platform/Makefile                    |    4 +
> >  drivers/media/platform/mtk-vcodec/Makefile         |   11 +
> >  .../media/platform/mtk-vcodec/h264_enc/Makefile    |    6 +
> >  .../platform/mtk-vcodec/h264_enc/venc_h264_if.c    |  540 ++++++++
> >  .../platform/mtk-vcodec/h264_enc/venc_h264_if.h    |  165 +++
> >  .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.c   |  309 +++++
> >  .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.h   |   30 +
> >  drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |  388 ++++++
> >  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1380 ++++++++++++++++++++
> >  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h |   46 +
> >  .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c |  476 +++++++
> >  .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c  |  132 ++
> >  .../media/platform/mtk-vcodec/mtk_vcodec_intr.c    |  102 ++
> >  .../media/platform/mtk-vcodec/mtk_vcodec_intr.h    |   29 +
> >  drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h  |   26 +
> >  .../media/platform/mtk-vcodec/mtk_vcodec_util.c    |  106 ++
> >  .../media/platform/mtk-vcodec/mtk_vcodec_util.h    |   85 ++
> >  drivers/media/platform/mtk-vcodec/venc_drv_base.h  |   62 +
> >  drivers/media/platform/mtk-vcodec/venc_drv_if.c    |  106 ++
> >  drivers/media/platform/mtk-vcodec/venc_drv_if.h    |  175 +++
> >  drivers/media/platform/mtk-vcodec/venc_ipi_msg.h   |  212 +++
> >  drivers/media/platform/mtk-vcodec/vp8_enc/Makefile |    6 +
> >  .../platform/mtk-vcodec/vp8_enc/venc_vp8_if.c      |  422 ++++++
> >  .../platform/mtk-vcodec/vp8_enc/venc_vp8_if.h      |  149 +++
> >  .../platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c     |  240 ++++
> >  .../platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h     |   28 +
> >  drivers/media/platform/mtk-vpu/Makefile            |    1 +
> >  drivers/media/platform/mtk-vpu/mtk_vpu.c           |  994 ++++++++++++++
> >  drivers/media/platform/mtk-vpu/mtk_vpu.h           |  167 +++
> >  include/uapi/linux/v4l2-controls.h                 |    4 +
> >  34 files changed, 6573 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> >  create mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt
> >  create mode 100644 drivers/media/platform/mtk-vcodec/Makefile
> >  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/Makefile
> >  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
> >  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
> >  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
> >  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
> >  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> >  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> >  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h
> >  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
> >  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
> >  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
> >  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h
> >  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h
> >  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
> >  create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> >  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h
> >  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c
> >  create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h
> >  create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h
> >  create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/Makefile
> >  create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c
> >  create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.h
> >  create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c
> >  create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h
> >  create mode 100644 drivers/media/platform/mtk-vpu/Makefile
> >  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c
> >  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h
> >  mode change 100644 => 100755 include/uapi/linux/v4l2-controls.h
> > 
> 




From geert at linux-m68k.org  Mon Feb 15 23:12:22 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 16 Feb 2016 08:12:22 +0100
Subject: [PATCH v3 7/7] arm64: dts: r8a7795: Add CA53 L2 cache-controller
 node
In-Reply-To: <56C2C534.30704@de.bosch.com>
References: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
 <1455568715-20880-8-git-send-email-geert+renesas@glider.be>
 <56C2C534.30704@de.bosch.com>
Message-ID: <CAMuHMdX=Kgb-i+QpP=yNO2e6nw7sXuCutXPoK0U9NwK-OyANFA@mail.gmail.com>

Hi Dirk,

On Tue, Feb 16, 2016 at 7:44 AM, Dirk Behme <dirk.behme at de.bosch.com> wrote:
> On 15.02.2016 21:38, Geert Uytterhoeven wrote:
>> Add a device node for the Cortex-A53 L2 cache-controller.
>>
>> The L2 cache for the Cortex-A53 CPU cores is 512 KiB large (organized as
>> 32 KiB x 16 ways).
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
>> ---
>> v3:
>>    - Remaining part of "[PATCH v2 6/6] arm64: renesas: r8a7795: Add L2
>>      cache-controller nodes".
>> ---
>>   arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> index c07f4e83b988ba42..c572527afec3403a 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> @@ -72,6 +72,12 @@
>>                 cache-level = <2>;
>>         };
>>
>> +       L2_CA53: cache-controller at 1 {
>> +               compatible = "cache";
>> +               cache-unified;
>> +               cache-level = <2>;
>> +       };
>> +
>
> As we don't have any CA53 in the device tree yet, and it was rejected to add
> it, I'd think that we don't want these unused entries at the moment.

This is a preparatory step for adding the SYSC PM Domains.

> I'd propose to add the CA53 entries, first. And then add their L2 cache
> entries.
>
> Based on the outcome of the discussion for the CA57 we have to see if we
> want to add the unused cache-unified and cache-level, then, too.

These are specified by ePAPR, as I said before.
Remember, DT describes the hardware, not what Linux (or any other OS) is
using.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From geert at linux-m68k.org  Mon Feb 15 23:15:40 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 16 Feb 2016 08:15:40 +0100
Subject: [PATCH/RFC v2 01/11] PM / Domains: Add DT bindings for the R-Car
 System Controller
In-Reply-To: <1720075.YOPnCQ3mE1@avalon>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
 <1455571020-18968-2-git-send-email-geert+renesas@glider.be>
 <1720075.YOPnCQ3mE1@avalon>
Message-ID: <CAMuHMdXJYjde1cqWyqzDL9Cgb-3cWSvJmrG61H6Jf6EOu0-=Fw@mail.gmail.com>

Hi Laurent,

On Tue, Feb 16, 2016 at 12:08 AM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/renesas,sysc-rcar.txt
>> @@ -0,0 +1,87 @@
>> +DT bindings for the Renesas R-Car System Controller
>> +
>> +== System Controller Node ==
>> +
>> +The R-Car System Controller provides power management for the CPU cores and
>> +various coprocessors.
>> +
>> +Required properties:
>> +  - compatible: Must contain one or more of the following:
>> +      - "renesas,r8a7779-sysc" (R-Car H1)
>> +      - "renesas,r8a7790-sysc" (R-Car H2)
>> +      - "renesas,r8a7791-sysc" (R-Car M2-W)
>> +      - "renesas,r8a7792-sysc" (R-Car V2H)
>> +      - "renesas,r8a7793-sysc" (R-Car M2-N)
>> +      - "renesas,r8a7794-sysc" (R-Car E2)
>> +      - "renesas,r8a7795-sysc" (R-Car H3)
>> +      - "renesas,rcar-gen2-sysc" (Generic R-Car Gen2)
>> +      - "renesas,rcar-gen3-sysc" (Generic R-Car Gen3)
>> +    When compatible with the generic version, nodes must list the
>> SoC-specific
>> +    version corresponding to the platform first, followed by the generic
>> +    version.
>> +  - reg: Address start and address range for the device.

You're quoting the description of the "reg" property for the SYSC device node...

> This isn't correct. I'll refrain from saying we abuse the reg property, as
> using the first cell as a power domain number should be fine (the second cell
> feels a bit more of an abuse to me though, but I won't complain too much), but
> the bindings document should describe what the reg cells contain.

... while the two cell format is for the PM domain nodes, not for the
SYSC device
node. Please check the other "reg" description.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From geert at linux-m68k.org  Mon Feb 15 23:30:03 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 16 Feb 2016 08:30:03 +0100
Subject: [PATCH/RFC v2 05/11] soc: renesas: rcar: Handle clock domain
 devices in SYSC PM domains
In-Reply-To: <2087210.c20JsV3rp3@avalon>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
 <1455571020-18968-6-git-send-email-geert+renesas@glider.be>
 <2087210.c20JsV3rp3@avalon>
Message-ID: <CAMuHMdUs1cJMZaO8-UkOcBYTy1nd9oR3kLo4q3Z4wxU_t4SDbw@mail.gmail.com>

Hi Laurent,

On Mon, Feb 15, 2016 at 11:08 PM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> On Monday 15 February 2016 22:16:54 Geert Uytterhoeven wrote:
>> R-Car H3 contains some hardware modules (e.g. VSP and FCP_V) that are
>> not only located in a power area controlled by the SYSC system
>> controller, but that are also part of the generic CPG/MSSR clock domain.
>> Make sure both are handled by enabling module clock PM when the device
>> for such a hardware module is attached to the SYSC PM Domain.
>
> Can't we specify both power domains in the DT power-domains attribute instead
> ?

While the DT property is called "power-domains" (plural), only the first entry
is parsed by genpd_dev_pm_attach(). Which makes sense for power areas
(if there are multiple, they are nested), but indeed can cause problems when
mixed with clock domains.

For R-Mobile, I fixed it in a similar way.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From u.kleine-koenig at pengutronix.de  Mon Feb 15 23:33:27 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Tue, 16 Feb 2016 08:33:27 +0100
Subject: [PATCH v3 0/3] Input: rotary_encoder - Fixups for Dmitry's
 rework and support for >2 gpios
In-Reply-To: <1454674101-1194-1-git-send-email-u.kleine-koenig@pengutronix.de>
References: <1454674101-1194-1-git-send-email-u.kleine-koenig@pengutronix.de>
Message-ID: <20160216073327.GL12289@pengutronix.de>

Hello Dmitry,

On Fri, Feb 05, 2016 at 01:08:18PM +0100, Uwe Kleine-K?nig wrote:
> Hello,
> 
> This bases on top of
> 
> 	git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input rotary-encoder
> 
> (currently at 557a30f2f046).
> 
> Dmitry, I assume you will squash the two fixups accordingly, otherwise
> just tell me, then I create proper patches.
> 
> Also let me note that with threaded irqs I'm able to rotate my device
> quicker than irq handling happens. So a quick counterclockwise rotation
> might be detected as single step clockwise rotation.

gentle ping!

Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From dirk.behme at de.bosch.com  Mon Feb 15 23:33:41 2016
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Tue, 16 Feb 2016 08:33:41 +0100
Subject: [PATCH v3 7/7] arm64: dts: r8a7795: Add CA53 L2 cache-controller
 node
In-Reply-To: <CAMuHMdX=Kgb-i+QpP=yNO2e6nw7sXuCutXPoK0U9NwK-OyANFA@mail.gmail.com>
References: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
 <1455568715-20880-8-git-send-email-geert+renesas@glider.be>
 <56C2C534.30704@de.bosch.com>
 <CAMuHMdX=Kgb-i+QpP=yNO2e6nw7sXuCutXPoK0U9NwK-OyANFA@mail.gmail.com>
Message-ID: <56C2D0D5.7090705@de.bosch.com>

Hi Geert,

On 16.02.2016 08:12, Geert Uytterhoeven wrote:
> Hi Dirk,
>
> On Tue, Feb 16, 2016 at 7:44 AM, Dirk Behme <dirk.behme at de.bosch.com> wrote:
>> On 15.02.2016 21:38, Geert Uytterhoeven wrote:
>>> Add a device node for the Cortex-A53 L2 cache-controller.
>>>
>>> The L2 cache for the Cortex-A53 CPU cores is 512 KiB large (organized as
>>> 32 KiB x 16 ways).
>>>
>>> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
>>> ---
>>> v3:
>>>     - Remaining part of "[PATCH v2 6/6] arm64: renesas: r8a7795: Add L2
>>>       cache-controller nodes".
>>> ---
>>>    arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 ++++++
>>>    1 file changed, 6 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>> index c07f4e83b988ba42..c572527afec3403a 100644
>>> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>> @@ -72,6 +72,12 @@
>>>                  cache-level = <2>;
>>>          };
>>>
>>> +       L2_CA53: cache-controller at 1 {
>>> +               compatible = "cache";
>>> +               cache-unified;
>>> +               cache-level = <2>;
>>> +       };
>>> +
>>
>> As we don't have any CA53 in the device tree yet, and it was rejected to add
>> it, I'd think that we don't want these unused entries at the moment.
>
> This is a preparatory step for adding the SYSC PM Domains.


Yes. But what do you want to control if it's not enabled at all?

To my understanding, as long as we don't enable the CA53 cores, we don't 
enable their L2 caches, too. And then we don't have to PM control them?


>> I'd propose to add the CA53 entries, first. And then add their L2 cache
>> entries.
>>
>> Based on the outcome of the discussion for the CA57 we have to see if we
>> want to add the unused cache-unified and cache-level, then, too.
>
> These are specified by ePAPR, as I said before.
> Remember, DT describes the hardware, not what Linux (or any other OS) is
> using.


Yes, this is understood :)

Your argument is the Spec/ePAPR, my point of view is the practical 
implementation. I'd think both are valid. Therefore let's see what 
Sudeep thinks ;)


Best regards

Dirk



From hverkuil at xs4all.nl  Mon Feb 15 23:44:49 2016
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Tue, 16 Feb 2016 08:44:49 +0100
Subject: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video
 Encoder Driver
In-Reply-To: <1455604653.19396.68.camel@mtksdaap41>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
 <56C1B4AF.1030207@xs4all.nl> <1455604653.19396.68.camel@mtksdaap41>
Message-ID: <56C2D371.9090805@xs4all.nl>

On 02/16/2016 07:37 AM, tiffany lin wrote:

<snip>

>>> +static int vidioc_venc_s_parm(struct file *file, void *priv,
>>> +			      struct v4l2_streamparm *a)
>>> +{
>>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> +
>>> +	if (a->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
>>> +		ctx->enc_params.framerate_num =
>>> +			a->parm.output.timeperframe.denominator;
>>> +		ctx->enc_params.framerate_denom =
>>> +			a->parm.output.timeperframe.numerator;
>>> +		ctx->param_change |= MTK_ENCODE_PARAM_FRAMERATE;
>>> +	} else {
>>> +		return -EINVAL;
>>> +	}
>>
>> I'd invert the test:
>>
>> 	if (a->type != V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
>> 		return -EINVAL;
>>
>> and now you can just set ctx->enc_params.
>>
> We will fix this in next version.
> 
> 
>>> +	return 0;
>>> +}
>>
>> And if there is an s_parm, then there should be a g_parm as well!
>>
> Now our driver does not support g_parm, our use cases do not use g_parm
> too. 
> Do we need to add g_parm at this moment? Or we could add it when we need
> g_parm?

No, you need it. You can see why if you look at the v4l2-compliance output:

                 test VIDIOC_G/S_PARM: OK (Not Supported)

Why does it think it is unsupported? Because (just like most applications) it
tries to call G_PARM first, and if that succeeds it tries to call S_PARM with
the value it got from G_PARM. Thus ensuring the application doesn't change the
driver state. So you can have a 'get' ioctl without the 'set' ioctl, but if
there is a 'set' ioctl there must always be a 'get' ioctl.

<snip>

>>> +static int vidioc_venc_g_s_selection(struct file *file, void *priv,
>>> +                                struct v4l2_selection *s)
>>
>> Why support s_selection if you can only return the current width and height?
>> And why support g_selection if you can't change the selection?
>>
>> In other words, why implement this at all?
>>
>> Unless I am missing something here, I would just drop this.
>>
> Now our driver do not support these capabilities, but userspace app will
> check whether g/s_crop are implemented when using encoder.
> Because g/s_crop are deprecated as you mentioned in previous v2 review
> comments. We change to use g_s_selection.
> We will check if we could add this capability.

It's true that you should use g/s_selection instead of g/s_crop, but only if
there is actually something to select. As long as you don't offer this capability,
just drop this for now.

When you add the capability later you can just add the g/s_selection functions.

Getting selection right can be tricky. I wouldn't mind if this is done later in a
separate patch.

> 
>>> +{
>>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> +	struct mtk_q_data *q_data;
>>> +
>>> +	if (V4L2_TYPE_IS_OUTPUT(s->type)) {
>>> +		if (s->target !=  V4L2_SEL_TGT_COMPOSE)
>>> +			return -EINVAL;
>>> +	} else {
>>> +		if (s->target != V4L2_SEL_TGT_CROP)
>>> +			return -EINVAL;
>>> +	}
>>> +
>>> +	if (s->r.left || s->r.top)
>>> +		return -EINVAL;
>>> +
>>> +	q_data = mtk_venc_get_q_data(ctx, s->type);
>>> +	if (!q_data)
>>> +		return -EINVAL;
>>> +
>>> +	s->r.width = q_data->width;
>>> +	s->r.height = q_data->height;
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +
>>> +static int vidioc_venc_qbuf(struct file *file, void *priv,
>>> +			    struct v4l2_buffer *buf)
>>> +{
>>> +
>>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> +
>>> +	if (ctx->state == MTK_STATE_ABORT) {
>>> +		mtk_v4l2_err("[%d] Call on QBUF after unrecoverable error\n", ctx->idx);
>>> +		return -EIO;
>>> +	}
>>> +
>>> +	return v4l2_m2m_qbuf(file, ctx->m2m_ctx, buf);
>>> +}
>>> +
>>> +static int vidioc_venc_dqbuf(struct file *file, void *priv,
>>> +			     struct v4l2_buffer *buf)
>>> +{
>>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
>>> +	if (ctx->state == MTK_STATE_ABORT) {
>>> +		mtk_v4l2_err("[%d] Call on QBUF after unrecoverable error\n", ctx->idx);
>>> +		return -EIO;
>>> +	}
>>> +
>>> +	return v4l2_m2m_dqbuf(file, ctx->m2m_ctx, buf);
>>> +}
>>> +
>>> +
>>> +const struct v4l2_ioctl_ops mtk_venc_ioctl_ops = {
>>> +	.vidioc_streamon		= v4l2_m2m_ioctl_streamon,
>>> +	.vidioc_streamoff		= v4l2_m2m_ioctl_streamoff,
>>> +
>>> +	.vidioc_reqbufs			= v4l2_m2m_ioctl_reqbufs,
>>> +	.vidioc_querybuf		= v4l2_m2m_ioctl_querybuf,
>>> +	.vidioc_qbuf			= vidioc_venc_qbuf,
>>> +	.vidioc_dqbuf			= vidioc_venc_dqbuf,
>>> +
>>> +	.vidioc_querycap		= vidioc_venc_querycap,
>>> +	.vidioc_enum_fmt_vid_cap_mplane = vidioc_enum_fmt_vid_cap_mplane,
>>> +	.vidioc_enum_fmt_vid_out_mplane = vidioc_enum_fmt_vid_out_mplane,
>>> +	.vidioc_enum_framesizes		= vidioc_enum_framesizes,
>>> +
>>> +	.vidioc_try_fmt_vid_cap_mplane	= vidioc_try_fmt_vid_cap_mplane,
>>> +	.vidioc_try_fmt_vid_out_mplane	= vidioc_try_fmt_vid_out_mplane,
>>> +	.vidioc_expbuf			= v4l2_m2m_ioctl_expbuf,
>>
>> Please add vidioc_create_bufs and vidioc_prepare_buf as well.
>>
> 
> Currently we do not support these use cases, do we need to add
> vidioc_create_bufs and vidioc_prepare_buf now?

I would suggest you do. The vb2 framework gives it (almost) for free.
prepare_buf is completely free (just add the helper) and create_bufs
needs a few small changes in the queue_setup function, that's all.

> 
> 
>>> +	.vidioc_subscribe_event		= v4l2_ctrl_subscribe_event,
>>> +	.vidioc_unsubscribe_event	= v4l2_event_unsubscribe,
>>> +
>>> +	.vidioc_s_parm			= vidioc_venc_s_parm,
>>> +
>>> +	.vidioc_s_fmt_vid_cap_mplane	= vidioc_venc_s_fmt,
>>> +	.vidioc_s_fmt_vid_out_mplane	= vidioc_venc_s_fmt,
>>> +
>>> +	.vidioc_g_fmt_vid_cap_mplane	= vidioc_venc_g_fmt,
>>> +	.vidioc_g_fmt_vid_out_mplane	= vidioc_venc_g_fmt,
>>> +
>>> +	.vidioc_g_selection		= vidioc_venc_g_s_selection,
>>> +	.vidioc_s_selection		= vidioc_venc_g_s_selection,
>>> +};

<snip>

>>> +int mtk_vcodec_enc_queue_init(void *priv, struct vb2_queue *src_vq,
>>> +			   struct vb2_queue *dst_vq)
>>> +{
>>> +	struct mtk_vcodec_ctx *ctx = priv;
>>> +	int ret;
>>> +
>>> +	src_vq->type		= V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
>>> +	src_vq->io_modes	= VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
>>
>> I recomment dropping VB2_USERPTR. That only makes sense for scatter-gather dma,
>> and you use physically contiguous DMA.
>>
> Now our userspace app use VB2_USERPTR. I need to check if we could drop
> VB2_USERPTR.
> We use src_vq->mem_ops = &vb2_dma_contig_memops;
> And there are
> 	.get_userptr	= vb2_dc_get_userptr,
> 	.put_userptr	= vb2_dc_put_userptr,
> I was confused why it only make sense for scatter-gather.
> Could you kindly explain more?

VB2_USERPTR indicates that the application can use malloc to allocate buffers
and pass those to the driver. Since malloc uses virtual memory the physical
memory is scattered all over. And the first page typically does not start at
the beginning of the page but at a random offset.

To support that the DMA generally has to be able to do scatter-gather.

Now, where things get ugly is that a hack was added to the USERPTR support where
apps could pass a pointer to physically contiguous memory as a user pointer. This
was a hack for embedded systems that preallocated a pool of buffers and needed to
pass those pointers around somehow. So the dma-contig USERPTR support is for that
'feature'. If you try to pass a malloc()ed buffer to a dma-contig driver it will
reject it. One big problem is that this specific hack isn't signaled anywhere, so
applications have no way of knowing if the USERPTR support is the proper version
or the hack where physically contiguous memory is expected.

This hack has been replaced with DMABUF which is the proper way of passing buffers
around.

New dma-contig drivers should not use that old hack anymore. Use dmabuf to pass
external buffers around.

How do you use it in your app? With malloc()ed buffers? Or with 'special' pointers
to physically contiguous buffers?

> 
>>> +	src_vq->drv_priv	= ctx;
>>> +	src_vq->buf_struct_size = sizeof(struct mtk_video_enc_buf);
>>> +	src_vq->ops		= &mtk_venc_vb2_ops;
>>> +	src_vq->mem_ops		= &vb2_dma_contig_memops;
>>> +	src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
>>> +	src_vq->lock = &ctx->dev->dev_mutex;
>>> +
>>> +	ret = vb2_queue_init(src_vq);
>>> +	if (ret)
>>> +		return ret;
>>> +
>>> +	dst_vq->type		= V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
>>> +	dst_vq->io_modes	= VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
>>> +	dst_vq->drv_priv	= ctx;
>>> +	dst_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
>>> +	dst_vq->ops		= &mtk_venc_vb2_ops;
>>> +	dst_vq->mem_ops		= &vb2_dma_contig_memops;
>>> +	dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
>>> +	dst_vq->lock = &ctx->dev->dev_mutex;
>>> +
>>> +	return vb2_queue_init(dst_vq);
>>> +}

Regards,

	Hans



From ilya at compulab.co.il  Mon Feb 15 23:56:47 2016
From: ilya at compulab.co.il (Ilya Ledvich)
Date: Tue, 16 Feb 2016 09:56:47 +0200
Subject: iMX7d cpu1 issue
Message-ID: <56C2D63F.1030408@compulab.co.il>

Hi Shawn,
I'm working on Compulab CL-SOM-IMX7 device 
(http://www.compulab.co.il/products/computer-on-modules/cl-som-imx7-freescale-i-mx-7-system-on-module) 
based on Freescale iMX7d CPU.
I use the Freescale latest BSP imx_3.14.52_1.1.0_ga  and the Linux 
mainline v4.4-rc6 as a reference.
I observe an issue with bringing up the second CPU core. Briefly, the 
kernel can successfully boot only when CPU1 fails to come online.
In this case the boot log shows the following messages:
...
CPU1: failed to come online
Brought up 1 CPUs
SMP: Total of 1 processors activated (6.00 BogoMIPS).
...

Otherwise, the device tries to start kernel several times until the boot 
process eventually crashes. Please see attached logs for more details.
This never happens on mainline Linus kernel, because it never tries to 
bring up CPU1.
Unfortunately, we cannot verify this behavior on reference board cause 
we have no one.
Have you ever seen such behavior? Could you please advice something?
Kind regards,
Ilya.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: cl-som-imx7-boot-ok.log
Type: text/x-log
Size: 14933 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/fb57af9a/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cl-som-imx7-boot-failed.log
Type: text/x-log
Size: 21571 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/fb57af9a/attachment-0003.bin>

From majun258 at huawei.com  Mon Feb 15 23:54:49 2016
From: majun258 at huawei.com (majun (F))
Date: Tue, 16 Feb 2016 15:54:49 +0800
Subject: [RFC PATCH] irq/mbigen:Fix the problem of IO remap for duplicated
 physical address in mbigen driver
In-Reply-To: <20160203111602.GA1234@leverpostej>
References: <1454327094-7848-1-git-send-email-majun258@huawei.com>
 <20160201115717.GD674@leverpostej> <56AF585E.6050005@huawei.com>
 <20160201132557.GG674@leverpostej> <56B08431.3000200@huawei.com>
 <20160202114340.GA28839@leverpostej> <56B16698.6050509@huawei.com>
 <20160203111602.GA1234@leverpostej>
Message-ID: <56C2D5C9.7090009@huawei.com>

Hi Mark:
	sorry for late response because of chinese new year.

? 2016/2/3 19:16, Mark Rutland ??:
> On Wed, Feb 03, 2016 at 10:31:52AM +0800, majun (F) wrote:
>>
>>
>> ? 2016/2/2 19:43, Mark Rutland ??:
>>> On Tue, Feb 02, 2016 at 06:25:53PM +0800, majun (F) wrote:
>>>> To simplify the mbigen drvier,
>>>> I didn't use the whole mbigen module as a mbgien device, but use
>>>> the register collections(vector, trigger type,status etc.) corresponding
>>>> to a peripheral device as a mbigen device.
>>>> So, mbigen device is a logical conception or logical device.
>>>
>>> >From the above, it sounds like the DT representation is not an accurate
>>> representation of the hardware. We should describe the _whole_ mbigen,
>>> not portions thereof. Trying to describe it piecemeal leads to problems
>>> like this one.
>>>
>>> I don't understand the rationale for describing the mbigen as separate
>>> nodes. Above you mention that we "need to define a device node for each
>>> device", but I don't see why that's necessary. Why do you believe we
>>> need an mbigen node per client device?
>>>
>>> As far as I can tell, we should be able to map an arbitrary
>>> interrupt-specifier to a particular MSI (complete with device id) within
>>> the mbigen driver. We just need to define the full set of MSIs the
>>> mbigen owns.
>>>
>>
>> mbigen device is a interrupt controller, it is also a ITS device for ITS module.
>> So, we need to register the each mbigen device to ITS with a unique ID.
>> Based on the current MSI/ITS driver, I can't register whole mbigen module which
>> contains several mbigen devices at one time. Because they have different device ID.
> 
> I don't follow.
> 
> You can describe this by having a top-level mbigen node featuring a reg,
> with a sub-node for each mbigen module with an appropriate msi-parent,
> e.g.
> 
> mbigen {
> 	reg = < ... ... >;
> 
> 	#interrupt-cells = <2>;
> 
> 	#address-cells = <1>; /* module index */
> 
> 	module at 0 {
> 		reg = <0>;
> 		msi-parent = <&its 0>;
> 	};
> 
> 	module at 1 {
> 		reg = <1>;
> 		reg = <&its 1>;
> 	};
> };
> 
> 
> That clearly does not require the reg to be duplicated, and encodes the
> information you want. The infrastructure for handling that might not
> exist yet, but that is a Linux issue that we can fix.
> 
> Marc, thoughts?
> 
> I take it all interrupts within a module share the same device id?
> 
>> I don't know whether this explanation is clear or not.
>> I think Marc can explain this well.
>>
>> Marc, would you please help me explain this?  or, do you have any opinion about this ?
>>
>>>> Now, a mbigen hardware module contains several logical mbigen device.
>>>>
>>>> -------------------------------
>>>> |mgn_dev1  mgn_dev2  mgn_dev3 |
>>>> |-----------------------------|
>>>>    |          |        |
>>>> dev1	    dev2      dev3
>>>>
>>>> So,mgn_dev1, mgn_dev2 and mgn_dev3 exist in same mbigen hardware module,
>>>> and,they use the same reg address region,that is adress of mbigen hardware module.
>>>>
>>>> For this case, I think the question is can we map an reg address
>>>> region more than one time?
>>>
>>> As above, I think we've mis-described the hardware. Rather than making
>>> things simpler, this has resulted in problems like this one.
>>>
>>> We should not map a reg region more than once. Even if it's technically
>>> possible to do so, I do not believe that would be the right solution
>>> here. Implicitly sharing resources (e.g. portions of the mbigen control
>>> registers) is inevitably going to lead to more problems later on.
>>
>> Because we only need to write 1 into corresponding bit of status
>> register to clear interrupt status during runtime,I think we don't
>> need to worry about this.
> 
> That might be currently true, but I doubt that will remain true in
> future. Presumably there are other control registers in the mbigen which
> are shared between modules.
> 

I'm sure there is nothing to control except the status register even in future.

Thanks
MaJun

> I think we do need to worry about this.
> 
> Mark.
> 
> .
> 



From jan.glauber at caviumnetworks.com  Tue Feb 16 00:00:15 2016
From: jan.glauber at caviumnetworks.com (Jan Glauber)
Date: Tue, 16 Feb 2016 09:00:15 +0100
Subject: [PATCH v3 5/5] arm64/perf: Extend event mask for ARMv8.1
In-Reply-To: <20160215200404.GX6298@arm.com>
References: <cover.1454516082.git.jglauber@cavium.com>
 <fa91eaedf581e6a7053899f25b1b08458dbd4b8e.1454516082.git.jglauber@cavium.com>
 <20160215200404.GX6298@arm.com>
Message-ID: <20160216080015.GA3490@hardcore>

On Mon, Feb 15, 2016 at 08:04:04PM +0000, Will Deacon wrote:

[...]

> On Wed, Feb 03, 2016 at 06:12:00PM +0100, Jan Glauber wrote:
> > +		cpu_pmu->event_mask = 0xffff;	/* ARMv8.1 extended events */
> > +	else
> > +		cpu_pmu->event_mask = ARMV8_EVTYPE_EVENT;
> 
> ... although can't we just update ARMV8_EVTYPE_EVENT to be 0xffff now?
> AFAICT, that just eats into bits that used to be RES0, so we shouldn't
> see any problems. That should make your patch *much* simpler!

That would of course be easier, but I just can't assess the implications.

Probably I'm missing something but to me it looks like the event mask is the
only verification we do for the user-space selectable events. Is it safe for
implementations that only support 0x3ff events to allow access to the
whole 0xffff range? What memory would be accessed for non-existing
events?

Jan

> Will


From krzysztof.adamski at tieto.com  Tue Feb 16 00:00:05 2016
From: krzysztof.adamski at tieto.com (Krzysztof Adamski)
Date: Tue, 16 Feb 2016 09:00:05 +0100
Subject: [PATCH] pinctrl: sunxi: set pin function as input on export
In-Reply-To: <CACRpkdbd4f3yj2MnR6PU5SuhV5Tj4HzWLc0UX8jQkcJp7MoTig@mail.gmail.com>
References: <1454942242-25690-1-git-send-email-krzysztof.adamski@tieto.com>
 <CACRpkdbd4f3yj2MnR6PU5SuhV5Tj4HzWLc0UX8jQkcJp7MoTig@mail.gmail.com>
Message-ID: <20160216080004.GA24625@box2.japko.eu>

On Mon, Feb 15, 2016 at 11:04:26PM +0100, Linus Walleij wrote:
>On Mon, Feb 8, 2016 at 3:37 PM, Krzysztof Adamski
><krzysztof.adamski at tieto.com> wrote:
>
>> Default function of a pin in sunxi SoCs is "disabled". By default gpios
>> exported by sysfs are set as input and indeed, when reading "direction"
>> file you will get "in". The "value" pin won't return proper value,
>> though, confusing user of this interface.
>>
>> This patch sets direction of a GPIO as input when exporting it.
>>
>> Signed-off-by: Krzysztof Adamski <krzysztof.adamski at tieto.com>
>
>As maxime says it's not a sunxi problem.
>
>So maybe it is wrong to set pins to either input or output when
>exporting them, I suspect they should be exported as is.
>
>Also: the sysfs ABI is deprecated. I suggest you invest your time
>in working on the new chardev ABI.

While sysfs API may be very limited it does have it's strengths too. One 
of them is that it's trivially scriptable even from bash or other 
scripting languages and the other one is that it's there for so long 
that it's very popular and it will take much time before all the 
tutorials and existing applications are updated. So, well, I still find 
it useful to have good support for it.

I find current behaviour of sysfs interface broken (it says that GPIO is 
in input mode when in reality it isn't) and still think it's a good idea 
to fix it. But putting sysfs issue aside, wouldn't it be safer to set 
some well known state of the pin when requesting it instead of leaving 
it at whatever was set before? The same question goes for freeing, 
actually, shouldn't the pin be disabled when we call gpio_free instead 
of leaving it at its last state?

There are existing drivers that set gpio direction to input when 
requesting the pin (for example pinctrl-plgpio.c, pinctrl-sirf.c) so 
sunxi wouldn't be the only driver to do this. This does also show that 
indeed the problem is not sunxi specific, though.

Best regards,
Krzysztof Adamski


From vigneshr at ti.com  Tue Feb 16 00:00:49 2016
From: vigneshr at ti.com (Vignesh R)
Date: Tue, 16 Feb 2016 13:30:49 +0530
Subject: [PATCH v5 3/5] mtd: devices: m25p80: add support for mmap read
 request
In-Reply-To: <20160212223711.GD18988@sirena.org.uk>
References: <1449807000-6457-1-git-send-email-vigneshr@ti.com>
 <1449807000-6457-4-git-send-email-vigneshr@ti.com>
 <20160209193616.GN13270@sirena.org.uk> <56BC1D3E.5020203@ti.com>
 <20160212223711.GD18988@sirena.org.uk>
Message-ID: <56C2D731.6050306@ti.com>



On 02/13/2016 04:07 AM, Mark Brown wrote:
> On Thu, Feb 11, 2016 at 11:03:50AM +0530, Vignesh R wrote:
>> On 02/10/2016 01:06 AM, Mark Brown wrote:
>>> On Fri, Dec 11, 2015 at 09:39:58AM +0530, Vignesh R wrote:
> 
>>>> +	if (spi_flash_read_supported(spi)) {
>>>> +		struct spi_flash_read_message msg;
>>>> +		int ret;
> 
>>> Looking at this I can't help but think that spi_flash_read() ought to
>>> have the stub in rather than the caller.  But given that we're pretty
>>> much only ever expecting one user I'm not 100% sure it actually matters.
> 
>> Well, my initial patch set passed long list of arguments to
>> spi_flash_read(), but Brian suggested to use struct[1] in order to avoid
>> unnecessary churn when things need changed in the API.
> 
> I don't see what that has to do with my point?
> 

AFAIU, your previous comment was to move initialization of
spi_flash_read_message struct to spi_flash_read(). This would mean
sending long list of arguments to spi_flash_read() which needs to be
updated whenever an argument needs to be added/deleted (in future).
Instead passing around a struct would be much easier in case of
adding/removing parameters.
Please correct me if I misunderstood your comment?

-- 
Regards
Vignesh


From laurent.pinchart at ideasonboard.com  Tue Feb 16 00:02:36 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Tue, 16 Feb 2016 10:02:36 +0200
Subject: [PATCH/RFC v2 05/11] soc: renesas: rcar: Handle clock domain
 devices in SYSC PM domains
In-Reply-To: <CAMuHMdUs1cJMZaO8-UkOcBYTy1nd9oR3kLo4q3Z4wxU_t4SDbw@mail.gmail.com>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
 <2087210.c20JsV3rp3@avalon>
 <CAMuHMdUs1cJMZaO8-UkOcBYTy1nd9oR3kLo4q3Z4wxU_t4SDbw@mail.gmail.com>
Message-ID: <2269681.nQFpo1ggiB@avalon>

Hi Geert,

On Tuesday 16 February 2016 08:30:03 Geert Uytterhoeven wrote:
> On Mon, Feb 15, 2016 at 11:08 PM, Laurent Pinchart wrote:
> > On Monday 15 February 2016 22:16:54 Geert Uytterhoeven wrote:
> >> R-Car H3 contains some hardware modules (e.g. VSP and FCP_V) that are
> >> not only located in a power area controlled by the SYSC system
> >> controller, but that are also part of the generic CPG/MSSR clock domain.
> >> Make sure both are handled by enabling module clock PM when the device
> >> for such a hardware module is attached to the SYSC PM Domain.
> > 
> > Can't we specify both power domains in the DT power-domains attribute
> > instead ?
> 
> While the DT property is called "power-domains" (plural), only the first
> entry is parsed by genpd_dev_pm_attach(). Which makes sense for power areas
> (if there are multiple, they are nested), but indeed can cause problems
> when mixed with clock domains.
> 
> For R-Mobile, I fixed it in a similar way.

Still, shouldn't it be fixed in genpd ?

-- 
Regards,

Laurent Pinchart



From jan.glauber at caviumnetworks.com  Tue Feb 16 00:04:24 2016
From: jan.glauber at caviumnetworks.com (Jan Glauber)
Date: Tue, 16 Feb 2016 09:04:24 +0100
Subject: [PATCH v3 4/5] arm64/perf: Enable PMCR long cycle counter bit
In-Reply-To: <20160215195529.GW6298@arm.com>
References: <cover.1454516082.git.jglauber@cavium.com>
 <de7340e1843f7823384551db64b12eadde7eded7.1454516082.git.jglauber@cavium.com>
 <20160215195529.GW6298@arm.com>
Message-ID: <20160216080424.GB3490@hardcore>

On Mon, Feb 15, 2016 at 07:55:29PM +0000, Will Deacon wrote:
> On Wed, Feb 03, 2016 at 06:11:59PM +0100, Jan Glauber wrote:
> > @@ -768,8 +776,11 @@ static void armv8pmu_reset(void *info)
> >  		armv8pmu_disable_intens(idx);
> >  	}
> >  
> > -	/* Initialize & Reset PMNC: C and P bits. */
> > -	armv8pmu_pmcr_write(ARMV8_PMCR_P | ARMV8_PMCR_C);
> > +	/*
> > +	 * Initialize & Reset PMNC. Request overflow on 64 bit but
> > +	 * cheat in armv8pmu_write_counter().
> 
> Can you expand the comment to mention that the 64-bit overflow is only
> for the cycle counter, please?

OK, how about:

/*
 * Initialize & Reset PMNC. Request overflow interrupt for
 * 64 bit cycle counter but cheat in armv8pmu_write_counter().
 */

Jan

> Will


From maxime.ripard at free-electrons.com  Tue Feb 16 00:07:32 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 16 Feb 2016 09:07:32 +0100
Subject: [PATCH v8 00/10] mfd: axp20x: Add support for RSB based AXP223
In-Reply-To: <1455242567-17880-1-git-send-email-wens@csie.org>
References: <1455242567-17880-1-git-send-email-wens@csie.org>
Message-ID: <20160216080732.GA4344@lukather>

On Fri, Feb 12, 2016 at 10:02:37AM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
> 
> This is v8 of the AXP223 PMIC series. All the driver bits are acked.
> Lee, please merge the first 8 patches. Once they're in, Maxime can take
> the DTS patches.

Applied 9 and 10. Thanks for your effort on this!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/852cf182/attachment.sig>

From maxime.ripard at free-electrons.com  Tue Feb 16 00:13:31 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 16 Feb 2016 09:13:31 +0100
Subject: [PATCH v6 1/2] dt-bindings: sunxi :add sun4i SPDIF transceiver
In-Reply-To: <1454951361-10625-2-git-send-email-codekipper@gmail.com>
References: <1454951361-10625-1-git-send-email-codekipper@gmail.com>
 <1454951361-10625-2-git-send-email-codekipper@gmail.com>
Message-ID: <20160216081331.GC4344@lukather>

On Mon, Feb 08, 2016 at 06:09:20PM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
> 
> Add devicetree bindings for the SPDIF transceiver found on
> found on Allwinners A10 and A20 SoCs.
> 
> Signed-off-by: Marcus Cooper <codekipper at gmail.com>

Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/a2711e53/attachment.sig>

From maxime.ripard at free-electrons.com  Tue Feb 16 00:18:05 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 16 Feb 2016 09:18:05 +0100
Subject: [PATCH v6 2/2] ASoC: sunxi: Add support for the SPDIF block
In-Reply-To: <1454951361-10625-3-git-send-email-codekipper@gmail.com>
References: <1454951361-10625-1-git-send-email-codekipper@gmail.com>
 <1454951361-10625-3-git-send-email-codekipper@gmail.com>
Message-ID: <20160216081805.GD4344@lukather>

Hi,

Sorry for the late reply,

On Mon, Feb 08, 2016 at 06:09:21PM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
> 
> The sun4i, sun5i and sun7i SoC families have an SPDIF
> block which is capable of playback and capture.
> 
> This patch enables the playback of this block for
> the sun4i families.
> 
> Signed-off-by: Marcus Cooper <codekipper at gmail.com>

Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/b96562f3/attachment.sig>

From marc.zyngier at arm.com  Tue Feb 16 00:35:49 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 16 Feb 2016 08:35:49 +0000
Subject: [PATCH] irqchip/gicv3-its: Avoid cache flush beyond ITS_BASERn
 memory size
In-Reply-To: <1455594112-27783-1-git-send-email-shankerd@codeaurora.org>
References: <1455594112-27783-1-git-send-email-shankerd@codeaurora.org>
Message-ID: <20160216083549.5c889627@arm.com>

On Mon, 15 Feb 2016 21:41:52 -0600
Shanker Donthineni <shankerd at codeaurora.org> wrote:

> Function its_alloc_tables() maintains two local variables, "order" and
> and "alloc_size", to hold memory size that has been allocated to
> ITS_BASEn. We don't always refresh the variable alloc_size whenever
> value of the variable order changes, causing the following two problems.
> 
>   - Cache flush operation with size more than required.
>   - Information reported by pr_info is not correct.
> 
> Use a helper macro that converts page order to size in bytes instead of
> variable "alloc_size" to fix both the problems.
> 
> Signed-off-by: Shanker Donthineni <shankerd at codeaurora.org>
> ---
>  drivers/irqchip/irq-gic-v3-its.c | 12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 0a73632..6f717f7 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -78,6 +78,9 @@ struct its_node {
>  
>  #define ITS_ITT_ALIGN		SZ_256
>  
> +/* Convert page order to size in bytes */
> +#define PAGE_ORDER_TO_BYTES(o)	(PAGE_SIZE << (o))
> +

nit: PAGE_ORDER_TO_size() seems more appropriate.

>  struct event_lpi_map {
>  	unsigned long		*lpi_map;
>  	u16			*col_map;
> @@ -846,7 +849,6 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
>  		u64 type = GITS_BASER_TYPE(val);
>  		u64 entry_size = GITS_BASER_ENTRY_SIZE(val);
>  		int order = get_order(psz);
> -		int alloc_size;
>  		int alloc_pages;
>  		u64 tmp;
>  		void *base;
> @@ -878,9 +880,8 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
>  			}
>  		}
>  
> -		alloc_size = (1 << order) * PAGE_SIZE;
>  retry_alloc_baser:
> -		alloc_pages = (alloc_size / psz);
> +		alloc_pages = (PAGE_ORDER_TO_BYTES(order) / psz);
>  		if (alloc_pages > GITS_BASER_PAGES_MAX) {
>  			alloc_pages = GITS_BASER_PAGES_MAX;
>  			order = get_order(GITS_BASER_PAGES_MAX * psz);
> @@ -933,7 +934,8 @@ retry_baser:
>  			shr = tmp & GITS_BASER_SHAREABILITY_MASK;
>  			if (!shr) {
>  				cache = GITS_BASER_nC;
> -				__flush_dcache_area(base, alloc_size);
> +				__flush_dcache_area(base,
> +						    PAGE_ORDER_TO_BYTES(order));

Please keep it on the same line. It helps my random grepping...

>  			}
>  			goto retry_baser;
>  		}
> @@ -966,7 +968,7 @@ retry_baser:
>  		}
>  
>  		pr_info("ITS: allocated %d %s @%lx (psz %dK, shr %d)\n",
> -			(int)(alloc_size / entry_size),
> +			(int)(PAGE_ORDER_TO_BYTES(order) / entry_size),
>  			its_base_type_string[type],
>  			(unsigned long)virt_to_phys(base),
>  			psz / SZ_1K, (int)shr >> GITS_BASER_SHAREABILITY_SHIFT);


Otherwise looks good.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.


From fu.wei at linaro.org  Tue Feb 16 00:36:21 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Tue, 16 Feb 2016 16:36:21 +0800
Subject: [PATCH v12 0/4] Watchdog: introduce ARM SBSA watchdog driver
Message-ID: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This patchset:
    (1)Introduce Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
    for FDT info of SBSA Generic Watchdog, and give two examples of
    adding SBSA Generic Watchdog device node into the dts files:
    foundation-v8.dts and amd-seattle-soc.dtsi.

    (2)Introduce ARM SBSA watchdog driver:
        a.Use linux kernel watchdog framework;
        b.Work with FDT on ARM64;
        c.Support getting timeout from parameter and FDT at the driver
          init stage.
        d.The driver works in two modes:
          (1) single stage timeout (ignore WS0 interrupt)
          (2) two stages timeout (register WS0 interrupt, do panic in routine)
        e.User can config working mode by module parameter "action".

This patchset has been tested with watchdog daemon
(ACPI/FDT, module/build-in) on the following platforms:
    (1)ARM Foundation v8 model
    (2)AMD Seattle platform

This patchset has been tested with kdump successfully.

Changelog:
v12:Fix a dev_warn message typo
    Remove unnecessary "status" in dts
    Add more *ed-by in commit message.

v11:https://lkml.org/lkml/2016/2/9/577
    Merge patch 4 and 5.
    Improve some comments.
    The driver works in two modes, it's configured by "action"(instead of
    panic_enabled).
    Improve the initialization of the timeout limits.
    Feeding dog by writing "0" to WRR.

v10:https://lkml.org/lkml/2016/2/3/817
    Delete pretimeout support.
    Separate the driver to two parts:
        (1) single stage timeout driver(ignore WS0 interrupt);
        (2) register WS0 interrupt for the half timeout panic.
    timeout == (enable --> WS1).

v9: https://lkml.org/lkml/2015/11/9/57
    Rebase to latest kernel version(4.3).
    Update the Documentation of sbsa-gwdt device node info of FDT:
        (1) move some introduction to pretimeout patch
        (2) delete WS1 value from "interrupts" of binding documentation,
            since WS1 won't be handled by Linux.

v8: https://lkml.org/lkml/2015/10/27/466
    Rebase to latest kernel version(4.3-rc7).
    Separate the patches of GTDT support and arm_arch_timer. This
    clocksource relevant patch will upstreamed in a individual patchset.
    Update all the default timeout and pretimeout to 30s and 60s.
    Improve documentation and inline comments.
    Fix a bug in pretimeout support which makes timeout and pretimeout
    parameters initialization fail.

v7: https://lkml.org/lkml/2015/8/24/611
    Rebase to latest kernel version(4.2-rc7).
    Improve FDT support: geting resource by order, instead of name.
    According to the FDT support, Update the example dts file, gtdt.c
    and sbsa_gwdt.c.
    Pass the sparse test, and fix the warning.
    Fix the max_pretimeout and max_timeout value overflow bug.
    Delete the WCV output value.
    

v6: https://lkml.org/lkml/2015/6/23/359
    Improve the dtb example files: reduce the register frame size to 4K.
    Improve pretimeout support:
        (1) improve watchdog_init_timeouts function
	(2) rename watchdog_check_min_max_timeouts back to the original name
        (1) improve watchdog_timeout_invalid/watchdog_pretimeout_invalid
    Add the new features in the sbsa_gwdt driver:
	(1) In the second stage, user can feed the dog without cleaning WS0.
	(2) In the second stage, user can trigger WS1 by setting pretimeout = 0.
	(3) expand the max value of pretimeout, in case 10 second is not enough
	    for a kdump kernel reboot in panic.

v5: https://lkml.org/lkml/2015/6/10/357
    Improve pretimeout support:
        (1)fix typo in documentation and comments.
	(2)fix the timeout limits validation bug.
    Simplify sbsa_gwdt driver:
	(1)integrate all the registers access functions into caller.

v4: https://lkml.org/lkml/2015/6/2/4
    Refactor GTDT support code: remove it from arch/arm64/kernel/acpi.c,
    put it into drivers/acpi/gtdt.c file.
    Integrate the GTDT code of drivers/clocksource/arm_arch_timer.c into
    drivers/acpi/gtdt.c.
    Improve pretimeout support, fix "pretimeout == 0" problem.
    Simplify sbsa_gwdt driver:
        (1)timeout/pretimeout limits setup;
        (2)keepalive function;
        (3)delete "clk == 0" check;
        (4)delete WS0 status bit check in interrupt routine;
        (5)sbsa_gwdt_set_wcv function.

v3: https://lkml.org/lkml/2015/5/25/111
    Delete "export arch_timer_get_rate" patch.
    Driver back to use arch_timer_get_cntfrq.
    Improve watchdog_init_timeouts function and update relevant documentation.
    Improve watchdog_timeout_invalid and watchdog_pretimeout_invalid.
    Improve foundation-v8.dts: delete the unnecessary tag of device node.
    Remove "ARM64 || COMPILE_TEST" from Kconfig.
    Add comments in arch/arm64/kernel/acpi.c
    Fix typoes and incorrect comments.

v2: https://lkml.org/lkml/2015/5/21/172
    Improve watchdog-kernel-api.txt documentation for pretimeout support.
    Export "arch_timer_get_rate" in arm_arch_timer.c.
    Add watchdog_init_timeouts API for pretimeout support in framework.
    Improve suspend and resume foundation in driver
    Improve timeout/pretimeout values init code in driver.
    Delete unnecessary items of the sbsa_gwdt struct and #define.
    Delete all unnecessary debug info in driver.
    Fix 64bit division bug.
    Use the arch_timer interface to get watchdog clock rate.
    Add MODULE_DEVICE_TABLE for platform device id.
    Fix typoes.

v1: https://lkml.org/lkml/2015/5/15/279
    The first version upstream patchset to linux mailing list.

Fu Wei (4):
  Documentation: add sbsa-gwdt driver documentation
  ARM64: add SBSA Generic Watchdog device node in foundation-v8.dts
  ARM64: add SBSA Generic Watchdog device node in amd-seattle-soc.dtsi
  Watchdog: introduce ARM SBSA watchdog driver

 .../devicetree/bindings/watchdog/sbsa-gwdt.txt     |  31 ++
 Documentation/watchdog/watchdog-parameters.txt     |   7 +
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi       |   8 +
 arch/arm64/boot/dts/arm/foundation-v8.dts          |   7 +
 drivers/watchdog/Kconfig                           |  20 +
 drivers/watchdog/Makefile                          |   1 +
 drivers/watchdog/sbsa_gwdt.c                       | 403 +++++++++++++++++++++
 7 files changed, 477 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
 create mode 100644 drivers/watchdog/sbsa_gwdt.c

-- 
2.5.0



From fu.wei at linaro.org  Tue Feb 16 00:36:22 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Tue, 16 Feb 2016 16:36:22 +0800
Subject: [PATCH v12 1/4] Documentation: add sbsa-gwdt driver documentation
In-Reply-To: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>
References: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1455611785-2407-2-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

The sbsa-gwdt.txt documentation in devicetree/bindings/watchdog is for
introducing SBSA(Server Base System Architecture) Generic Watchdog
device node info into FDT.

Also add sbsa-gwdt introduction in watchdog-parameters.txt

Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Fu Wei <fu.wei at linaro.org>
---
 .../devicetree/bindings/watchdog/sbsa-gwdt.txt     | 31 ++++++++++++++++++++++
 Documentation/watchdog/watchdog-parameters.txt     |  7 +++++
 2 files changed, 38 insertions(+)

diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
new file mode 100644
index 0000000..6f2d5f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
@@ -0,0 +1,31 @@
+* SBSA (Server Base System Architecture) Generic Watchdog
+
+The SBSA Generic Watchdog Timer is used to force a reset of the system
+after two stages of timeout have elapsed.  A detailed definition of the
+watchdog timer can be found in the ARM document: ARM-DEN-0029 - Server
+Base System Architecture (SBSA)
+
+Required properties:
+- compatible: Should at least contain "arm,sbsa-gwdt".
+
+- reg: Each entry specifies the base physical address of a register frame
+  and the length of that frame; currently, two frames must be defined,
+  in this order:
+  1: Watchdog control frame;
+  2: Refresh frame.
+
+- interrupts: Should contain the Watchdog Signal 0 (WS0) SPI (Shared
+  Peripheral Interrupt) number of SBSA Generic Watchdog.
+
+Optional properties
+- timeout-sec: Watchdog timeout values (in seconds).
+
+Example for FVP Foundation Model v8:
+
+watchdog at 2a440000 {
+	compatible = "arm,sbsa-gwdt";
+	reg = <0x0 0x2a440000 0 0x1000>,
+	      <0x0 0x2a450000 0 0x1000>;
+	interrupts = <0 27 4>;
+	timeout-sec = <30>;
+};
diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
index 9f9ec9f..ce7ae4e 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -284,6 +284,13 @@ sbc_fitpc2_wdt:
 margin: Watchdog margin in seconds (default 60s)
 nowayout: Watchdog cannot be stopped once started
 -------------------------------------------------
+sbsa_gwdt:
+timeout: Watchdog timeout in seconds. (default 10s)
+action: Watchdog action at the first stage timeout,
+	set to 0 to ignore, 1 to panic. (default=0)
+nowayout: Watchdog cannot be stopped once started
+	(default=kernel config parameter)
+-------------------------------------------------
 sc1200wdt:
 isapnp: When set to 0 driver ISA PnP support will be disabled (default=1)
 io: io port
-- 
2.5.0



From fu.wei at linaro.org  Tue Feb 16 00:36:23 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Tue, 16 Feb 2016 16:36:23 +0800
Subject: [PATCH v12 2/4] ARM64: add SBSA Generic Watchdog device node in
 foundation-v8.dts
In-Reply-To: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>
References: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1455611785-2407-3-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Fu Wei <fu.wei at linaro.org>
---
 arch/arm64/boot/dts/arm/foundation-v8.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dts b/arch/arm64/boot/dts/arm/foundation-v8.dts
index 4eac8dc..66cb9aa 100644
--- a/arch/arm64/boot/dts/arm/foundation-v8.dts
+++ b/arch/arm64/boot/dts/arm/foundation-v8.dts
@@ -237,4 +237,11 @@
 			};
 		};
 	};
+	watchdog at 2a440000 {
+		compatible = "arm,sbsa-gwdt";
+		reg = <0x0 0x2a440000 0 0x1000>,
+			<0x0 0x2a450000 0 0x1000>;
+		interrupts = <0 27 4>;
+		timeout-sec = <30>;
+	};
 };
-- 
2.5.0



From fu.wei at linaro.org  Tue Feb 16 00:36:24 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Tue, 16 Feb 2016 16:36:24 +0800
Subject: [PATCH v12 3/4] ARM64: add SBSA Generic Watchdog device node in
 amd-seattle-soc.dtsi
In-Reply-To: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>
References: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1455611785-2407-4-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Signed-off-by: Fu Wei <fu.wei at linaro.org>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 2874d92..0a8ca1d 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -84,6 +84,14 @@
 			clock-names = "uartclk", "apb_pclk";
 		};
 
+		watchdog0: watchdog at e0bb0000 {
+			compatible = "arm,sbsa-gwdt";
+			reg = <0x0 0xe0bc0000 0 0x1000>,
+				<0x0 0xe0bb0000 0 0x1000>;
+			interrupts = <0 337 4>;
+			timeout-sec = <15>;
+		};
+
 		spi0: ssp at e1020000 {
 			status = "disabled";
 			compatible = "arm,pl022", "arm,primecell";
-- 
2.5.0



From fu.wei at linaro.org  Tue Feb 16 00:36:25 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Tue, 16 Feb 2016 16:36:25 +0800
Subject: [PATCH v12 4/4] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>
References: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1455611785-2407-5-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

According to Server Base System Architecture (SBSA) specification,
the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0)
is for alerting the system by interrupt, the second one (WS1) is a real
hardware reset.
More details about the hardware specification of this device:
ARM DEN0029B - Server Base System Architecture (SBSA)

This driver can operate ARM SBSA Generic Watchdog as a single stage watchdog
or a two stages watchdog, it's set up by the module parameter "action".
In the single stage mode, when the timeout is reached, your system
will be reset by WS1. The first signal (WS0) is ignored.
In the two stages mode, when the timeout is reached, the first signal (WS0)
will trigger panic. If the system is getting into trouble and cannot be reset
by panic or restart properly by the kdump kernel(if supported), then the
second stage (as long as the first stage) will be reached, system will be
reset by WS1. This function can help administrator to backup the system
context info by panic console output or kdump.

This driver bases on linux kernel watchdog framework, so it can get
timeout from module parameter and FDT at the driver init stage.

Signed-off-by: Fu Wei <fu.wei at linaro.org>
Reviewed-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Pratyush Anand <panand at redhat.com>
Acked-by: Timur Tabi <timur at codeaurora.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/watchdog/Kconfig     |  20 +++
 drivers/watchdog/Makefile    |   1 +
 drivers/watchdog/sbsa_gwdt.c | 403 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 424 insertions(+)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 0f6d851..ed9a5cb 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -202,6 +202,26 @@ config ARM_SP805_WATCHDOG
 	  ARM Primecell SP805 Watchdog timer. This will reboot your system when
 	  the timeout is reached.
 
+config ARM_SBSA_WATCHDOG
+	tristate "ARM SBSA Generic Watchdog"
+	depends on ARM64
+	depends on ARM_ARCH_TIMER
+	select WATCHDOG_CORE
+	help
+	  ARM SBSA Generic Watchdog has two stage timeouts:
+	  the first signal (WS0) is for alerting the system by interrupt,
+	  the second one (WS1) is a real hardware reset.
+	  More details: ARM DEN0029B - Server Base System Architecture (SBSA)
+
+	  This driver can operate ARM SBSA Generic Watchdog as a single stage
+	  or a two stages watchdog, it depends on the module parameter "action".
+
+	  Note: the maximum timeout in the two stages mode is half of that in
+	  the single stage mode.
+
+	  To compile this driver as module, choose M here: The module
+	  will be called sbsa_gwdt.
+
 config ASM9260_WATCHDOG
 	tristate "Alphascale ASM9260 watchdog"
 	depends on MACH_ASM9260
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index f566753..f9826d4 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
 
 # ARM Architecture
 obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
+obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
 obj-$(CONFIG_ASM9260_WATCHDOG) += asm9260_wdt.o
 obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
 obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
new file mode 100644
index 0000000..789444e
--- /dev/null
+++ b/drivers/watchdog/sbsa_gwdt.c
@@ -0,0 +1,403 @@
+/*
+ * SBSA(Server Base System Architecture) Generic Watchdog driver
+ *
+ * Copyright (c) 2015, Linaro Ltd.
+ * Author: Fu Wei <fu.wei at linaro.org>
+ *         Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
+ *         Al Stone <al.stone at linaro.org>
+ *         Timur Tabi <timur at codeaurora.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License 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.
+ *
+ * ARM SBSA Generic Watchdog has two stage timeouts:
+ * the first signal (WS0) is for alerting the system by interrupt,
+ * the second one (WS1) is a real hardware reset.
+ * More details about the hardware specification of this device:
+ * ARM DEN0029B - Server Base System Architecture (SBSA)
+ *
+ * This driver can operate ARM SBSA Generic Watchdog as a single stage watchdog
+ * or a two stages watchdog, it's set up by the module parameter "action".
+ * In the single stage mode, when the timeout is reached, your system
+ * will be reset by WS1. The first signal (WS0) is ignored.
+ * In the two stages mode, when the timeout is reached, the first signal (WS0)
+ * will trigger panic. If the system is getting into trouble and cannot be reset
+ * by panic or restart properly by the kdump kernel(if supported), then the
+ * second stage (as long as the first stage) will be reached, system will be
+ * reset by WS1. This function can help administrator to backup the system
+ * context info by panic console output or kdump.
+ *
+ * SBSA GWDT:
+ * if action is 1 (the two stages mode):
+ * |--------WOR-------WS0--------WOR-------WS1
+ * |----timeout-----(panic)----timeout-----reset
+ *
+ * if action is 0 (the single stage mode):
+ * |------WOR-----WS0(ignored)-----WOR------WS1
+ * |--------------timeout-------------------reset
+ *
+ * Note: Since this watchdog timer has two stages, and each stage is determined
+ * by WOR, in the single stage mode, the timeout is (WOR * 2); in the two
+ * stages mode, the timeout is WOR. The maximum timeout in the two stages mode
+ * is half of that in the single stage mode.
+ *
+ */
+
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/uaccess.h>
+#include <linux/watchdog.h>
+#include <asm/arch_timer.h>
+
+/* SBSA Generic Watchdog register definitions */
+/* refresh frame */
+#define SBSA_GWDT_WRR				0x000
+
+/* control frame */
+#define SBSA_GWDT_WCS				0x000
+#define SBSA_GWDT_WOR				0x008
+#define SBSA_GWDT_WCV				0x010
+
+/* refresh/control frame */
+#define SBSA_GWDT_W_IIDR			0xfcc
+#define SBSA_GWDT_IDR				0xfd0
+
+/* Watchdog Control and Status Register */
+#define SBSA_GWDT_WCS_EN			BIT(0)
+#define SBSA_GWDT_WCS_WS0			BIT(1)
+#define SBSA_GWDT_WCS_WS1			BIT(2)
+
+/**
+ * struct sbsa_gwdt - Internal representation of the SBSA GWDT
+ * @wdd:		kernel watchdog_device structure
+ * @clk:		store the System Counter clock frequency, in Hz.
+ * @refresh_base:	Virtual address of the watchdog refresh frame
+ * @control_base:	Virtual address of the watchdog control frame
+ */
+struct sbsa_gwdt {
+	struct watchdog_device	wdd;
+	u32			clk;
+	void __iomem		*refresh_base;
+	void __iomem		*control_base;
+};
+
+#define to_sbsa_gwdt(e) container_of(e, struct sbsa_gwdt, wdd)
+
+#define DEFAULT_TIMEOUT		10 /* seconds, the 1st + 2nd watch periods*/
+
+static unsigned int timeout;
+module_param(timeout, uint, 0);
+MODULE_PARM_DESC(timeout,
+		 "Watchdog timeout in seconds. (>=0, default="
+		 __MODULE_STRING(DEFAULT_TIMEOUT) ")");
+
+/*
+ * action refers to action taken when watchdog gets WS0
+ * 0 = skip
+ * 1 = panic
+ * defaults to skip (0)
+ */
+static int action;
+module_param(action, int, 0);
+MODULE_PARM_DESC(action, "after watchdog gets WS0 interrupt, do: "
+		 "0 = skip(*)  1 = panic");
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, S_IRUGO);
+MODULE_PARM_DESC(nowayout,
+		 "Watchdog cannot be stopped once started (default="
+		 __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+/*
+ * watchdog operation functions
+ */
+static int sbsa_gwdt_set_timeout(struct watchdog_device *wdd,
+				 unsigned int timeout)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	wdd->timeout = timeout;
+
+	if (action)
+		writel(gwdt->clk * timeout,
+		       gwdt->control_base + SBSA_GWDT_WOR);
+	else
+		/*
+		 * In the single stage mode, The first signal (WS0) is ignored,
+		 * the timeout is (WOR * 2), so the WOR should be configured
+		 * to half value of timeout.
+		 */
+		writel(gwdt->clk / 2 * timeout,
+		       gwdt->control_base + SBSA_GWDT_WOR);
+
+	return 0;
+}
+
+static unsigned int sbsa_gwdt_get_timeleft(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+	u64 timeleft = 0;
+
+	/*
+	 * In the single stage mode, if WS0 is deasserted
+	 * (watchdog is in the first stage),
+	 * timeleft = WOR + (WCV - system counter)
+	 */
+	if (!action &&
+	    !(readl(gwdt->control_base + SBSA_GWDT_WCS) & SBSA_GWDT_WCS_WS0))
+		timeleft += readl(gwdt->control_base + SBSA_GWDT_WOR);
+
+	timeleft += readq(gwdt->control_base + SBSA_GWDT_WCV) -
+		    arch_counter_get_cntvct();
+
+	do_div(timeleft, gwdt->clk);
+
+	return timeleft;
+}
+
+static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	/*
+	* Writing WRR for an explicit watchdog refresh.
+	* You can write anyting (like 0).
+	*/
+	writel(0, gwdt->refresh_base + SBSA_GWDT_WRR);
+
+	return 0;
+}
+
+static unsigned int sbsa_gwdt_status(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+	u32 status = readl(gwdt->control_base + SBSA_GWDT_WCS);
+
+	/* is the watchdog timer running? */
+	return (status & SBSA_GWDT_WCS_EN) << WDOG_ACTIVE;
+}
+
+static int sbsa_gwdt_start(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	/* writing WCS will cause an explicit watchdog refresh */
+	writel(SBSA_GWDT_WCS_EN, gwdt->control_base + SBSA_GWDT_WCS);
+
+	return sbsa_gwdt_keepalive(wdd);
+}
+
+static int sbsa_gwdt_stop(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	/* Simply write 0 to WCS to clean WCS_EN bit */
+	writel(0, gwdt->control_base + SBSA_GWDT_WCS);
+
+	return 0;
+}
+
+static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
+{
+	panic("SBSA Watchdog timeout");
+
+	return IRQ_HANDLED;
+}
+
+static struct watchdog_info sbsa_gwdt_info = {
+	.identity	= "SBSA Generic Watchdog",
+	.options	= WDIOF_SETTIMEOUT |
+			  WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE |
+			  WDIOF_CARDRESET,
+};
+
+static struct watchdog_ops sbsa_gwdt_ops = {
+	.owner		= THIS_MODULE,
+	.start		= sbsa_gwdt_start,
+	.stop		= sbsa_gwdt_stop,
+	.status		= sbsa_gwdt_status,
+	.ping		= sbsa_gwdt_keepalive,
+	.set_timeout	= sbsa_gwdt_set_timeout,
+	.get_timeleft	= sbsa_gwdt_get_timeleft,
+};
+
+static int sbsa_gwdt_probe(struct platform_device *pdev)
+{
+	void __iomem *rf_base, *cf_base;
+	struct device *dev = &pdev->dev;
+	struct watchdog_device *wdd;
+	struct sbsa_gwdt *gwdt;
+	struct resource *res;
+	int ret, irq;
+	u32 status;
+
+	gwdt = devm_kzalloc(dev, sizeof(*gwdt), GFP_KERNEL);
+	if (!gwdt)
+		return -ENOMEM;
+	platform_set_drvdata(pdev, gwdt);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	cf_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(cf_base))
+		return PTR_ERR(cf_base);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	rf_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(rf_base))
+		return PTR_ERR(rf_base);
+
+	if (action) {
+		irq = platform_get_irq(pdev, 0);
+		if (irq < 0) {
+			action = 0;
+			dev_warn(dev, "unable to get ws0 interrupt.\n");
+		} else {
+			if (devm_request_irq(dev, irq, sbsa_gwdt_interrupt, 0,
+					     pdev->name, gwdt)) {
+				action = 0;
+				dev_warn(dev, "unable to request IRQ %d.\n",
+					 irq);
+			}
+		}
+		if (!action)
+			dev_warn(dev, "falling back to signle stage mode.\n");
+	}
+
+	/*
+	 * Get the frequency of system counter from the cp15 interface of ARM
+	 * Generic timer. We don't need to check it, because if it returns "0",
+	 * system would panic in very early stage.
+	 */
+	gwdt->clk = arch_timer_get_cntfrq();
+	gwdt->refresh_base = rf_base;
+	gwdt->control_base = cf_base;
+
+	wdd = &gwdt->wdd;
+	wdd->parent = dev;
+	wdd->info = &sbsa_gwdt_info;
+	wdd->ops = &sbsa_gwdt_ops;
+	watchdog_set_drvdata(wdd, gwdt);
+	watchdog_set_nowayout(wdd, nowayout);
+
+	wdd->min_timeout = 1;
+	wdd->max_timeout = U32_MAX / gwdt->clk;
+	/*
+	 * In the single stage mode, The first signal (WS0) is ignored,
+	 * the timeout is (WOR * 2), so the maximum timeout should be double.
+	 */
+	if (!action)
+		wdd->max_timeout *= 2;
+
+	wdd->timeout = DEFAULT_TIMEOUT;
+	watchdog_init_timeout(wdd, timeout, dev);
+
+	status = readl(gwdt->control_base + SBSA_GWDT_WCS);
+	if (status & SBSA_GWDT_WCS_WS1) {
+		dev_warn(dev, "System reset by WDT.\n");
+		wdd->bootstatus |= WDIOF_CARDRESET;
+	}
+
+	ret = watchdog_register_device(wdd);
+	if (ret)
+		return ret;
+
+	/*
+	 * Update timeout to WOR.
+	 * Because of the explicit watchdog refresh mechanism,
+	 * it's also a ping, if watchdog is enabled.
+	 */
+	sbsa_gwdt_set_timeout(wdd, wdd->timeout);
+
+	dev_info(dev, "Initialized with %ds timeout @ %u Hz, action=%d.%s\n",
+		 wdd->timeout, gwdt->clk, action,
+		 status & SBSA_GWDT_WCS_EN ? " [enabled]" : "");
+
+	return 0;
+}
+
+static void sbsa_gwdt_shutdown(struct platform_device *pdev)
+{
+	struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
+
+	sbsa_gwdt_stop(&gwdt->wdd);
+}
+
+static int sbsa_gwdt_remove(struct platform_device *pdev)
+{
+	struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
+
+	watchdog_unregister_device(&gwdt->wdd);
+
+	return 0;
+}
+
+/* Disable watchdog if it is active during suspend */
+static int __maybe_unused sbsa_gwdt_suspend(struct device *dev)
+{
+	struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
+
+	if (watchdog_active(&gwdt->wdd))
+		sbsa_gwdt_stop(&gwdt->wdd);
+
+	return 0;
+}
+
+/* Enable watchdog and configure it if necessary */
+static int __maybe_unused sbsa_gwdt_resume(struct device *dev)
+{
+	struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
+
+	if (watchdog_active(&gwdt->wdd))
+		sbsa_gwdt_start(&gwdt->wdd);
+
+	return 0;
+}
+
+static const struct dev_pm_ops sbsa_gwdt_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(sbsa_gwdt_suspend, sbsa_gwdt_resume)
+};
+
+static const struct of_device_id sbsa_gwdt_of_match[] = {
+	{ .compatible = "arm,sbsa-gwdt", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sbsa_gwdt_of_match);
+
+static const struct platform_device_id sbsa_gwdt_pdev_match[] = {
+	{ .name = "sbsa-gwdt", },
+	{},
+};
+MODULE_DEVICE_TABLE(platform, sbsa_gwdt_pdev_match);
+
+static struct platform_driver sbsa_gwdt_driver = {
+	.driver = {
+		.name = "sbsa-gwdt",
+		.pm = &sbsa_gwdt_pm_ops,
+		.of_match_table = sbsa_gwdt_of_match,
+	},
+	.probe = sbsa_gwdt_probe,
+	.remove = sbsa_gwdt_remove,
+	.shutdown = sbsa_gwdt_shutdown,
+	.id_table = sbsa_gwdt_pdev_match,
+};
+
+module_platform_driver(sbsa_gwdt_driver);
+
+MODULE_DESCRIPTION("SBSA Generic Watchdog Driver");
+MODULE_AUTHOR("Fu Wei <fu.wei at linaro.org>");
+MODULE_AUTHOR("Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>");
+MODULE_AUTHOR("Al Stone <al.stone at linaro.org>");
+MODULE_AUTHOR("Timur Tabi <timur at codeaurora.org>");
+MODULE_LICENSE("GPL v2");
-- 
2.5.0



From s.trumtrar at pengutronix.de  Tue Feb 16 00:41:17 2016
From: s.trumtrar at pengutronix.de (Steffen Trumtrar)
Date: Tue, 16 Feb 2016 09:41:17 +0100
Subject: [PATCH 1/3] Documentation: devicetree: add Freescale SCC bindings
In-Reply-To: <20160214075557.GP6756@tiger>
References: <1455199485-24458-1-git-send-email-s.trumtrar@pengutronix.de>
 <20160214075557.GP6756@tiger>
Message-ID: <73fuwtdp3m.fsf@unicorn.hi.pengutronix.de>


Hi!

Shawn Guo writes:

> On Thu, Feb 11, 2016 at 03:04:43PM +0100, Steffen Trumtrar wrote:
>> Add documentation for the Freescale Security Controller (SCC)
>> found on i.MX25 SoCs.
>> 
>> Signed-off-by: Steffen Trumtrar <s.trumtrar at pengutronix.de>
>> ---
>>  .../devicetree/bindings/crypto/fsl-imx-scc.txt          | 17 +++++++++++++++++
>>  1 file changed, 17 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
>> new file mode 100644
>> index 000000000000..9a15ab8da94f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
>> @@ -0,0 +1,17 @@
>> +Freescale Security Controller (SCC)
>> +
>> +Required properties:
>> +- compatible : Should be "fsl,imx25-scc".
>> +- reg : Should contain register location and length.
>> +- interrupts : Should contain interrupt numbers for SCM IRQ and SMN IRQ.
>> +
>> +Example:
>> +
>> +	scc: crypto at 53fac000 {
>> +		compatible = "fsl,imx25-scc";
>> +		reg = <0x53fac000 0x4000>;
>> +		clocks = <&clks 111>;
>> +		clock-names = "ipg";
>
> Shouldn't these two be mentioned in properties list above too?
>

What is the current policy on clocks in bindings? There are some with
and some without.

Of course I can add them to the required properties if necessary.

Thanks,
Steffen

-- 
Pengutronix e.K.                           | Steffen Trumtrar            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From jan.glauber at caviumnetworks.com  Tue Feb 16 00:41:19 2016
From: jan.glauber at caviumnetworks.com (Jan Glauber)
Date: Tue, 16 Feb 2016 09:41:19 +0100
Subject: [RFC PATCH 1/7] arm64/perf: Basic uncore counter support for
 Cavium ThunderX
In-Reply-To: <20160212173658.GD20262@leverpostej>
References: <cover.1455295032.git.jglauber@cavium.com>
 <8bd93a25e069ed6428bc6c21fc53270962ccafcc.1455295032.git.jglauber@cavium.com>
 <20160212173658.GD20262@leverpostej>
Message-ID: <20160216084119.GC3490@hardcore>

On Fri, Feb 12, 2016 at 05:36:59PM +0000, Mark Rutland wrote:
> On Fri, Feb 12, 2016 at 05:55:06PM +0100, Jan Glauber wrote:
> > Provide uncore facilities for non-CPU performance counter units.
> > Based on Intel/AMD uncore pmu support.
> > 
> > The uncore PMUs can be found under /sys/bus/event_source/devices.
> > All counters are exported via sysfs in the corresponding events
> > files under the PMU directory so the perf tool can list the event names.
> 
> It turns out that "uncore" covers quite a lot of things.
> 
> Where exactly do the see counters live? system, socket, cluster?
> 
> Are there potentially multiple instances of a given PMU in the system?
> e.g. might each clutster have an instance of an L2 PMU?

Thinking twice about the multi-node systems I would like to change
the implementation to not merge counters across nodes. There might
be value in having the counters per node and also performance wise
it would be better to merge counters only on the local node.

I'll introduce a node sysfs attribute that can be combined with
the event and fill the node with the numa id.

[...]

> 
> Otherwise, are they associated with some power domain?

No, power domains are not used for the "uncore" related devices.
These devices are currently always on.

Jan


From maxime.ripard at free-electrons.com  Tue Feb 16 00:44:48 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 16 Feb 2016 09:44:48 +0100
Subject: breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi:
 Refactor A31 PLL6 so that it can be reused)
In-Reply-To: <1455270030.3201.71.camel@pengutronix.de>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56B4E2FB.3050703@arm.com> <56BB2D79.6090402@arm.com>
 <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
 <20160210143755.GE31506@lukather>
 <20160210163001.GG2632@leverpostej>
 <20160211100048.GK31506@lukather>
 <20160211114410.GA32535@leverpostej>
 <20160211170820.GP31506@lukather>
 <1455270030.3201.71.camel@pengutronix.de>
Message-ID: <20160216084448.GE4344@lukather>

On Fri, Feb 12, 2016 at 10:40:30AM +0100, Lucas Stach wrote:
> Am Donnerstag, den 11.02.2016, 18:08 +0100 schrieb Maxime Ripard:
> [...]
> > > > > Having code in mainline comes with responsibilities. One of those is to
> > > > > keep said code working for existing users. Otherwise, why bother having
> > > > > it in mainline at all?
> > > > 
> > > > None of our existing users ever complained.
> > > 
> > > I believe that in this case, Andre was complaining about this particular
> > > breakage, unless I have misunderstood.
> > > 
> > > To be clear, I'm arguing for the strategy going forward. If no-one has
> > > complained about the stuff broken up to this point, let's not waste time
> > > restoring that.
> > > 
> > > Going forward we need to keep old DTBs supported.
> > 
> > I find that stand a bit dishonest.
> > 
> > You, DT maintainers, admit that you're not doing your job properly,
> > and that burden relies on the platform maintainers? Or should I take
> > it as you volunteering to maintain that code?
> > 
> > But ok. Let's do that. Make sure that the other platform maintainers
> > are aware that this is the rule too though. I surely don't want to be
> > alone in that boat.
> 
> FWIW: I always thought it's the platform maintainers job to enforce a
> reasonable level of DT stability. I don't see how the DT maintainers
> could provide the necessary in-depth review with every platform being
> different in many subtle ways.
> 
> For the i.MX platform we actually enforced a baseline of DT stability by
> shooting down patches that break DT stability for the sake of adding new
> features, or when trying to put "fixes" into the DT, that could be
> solved entirely inside the kernel.
> 
> Yes, mistakes happen and and we can not really prevent all breakage,
> especially when the bindings were not strictly enough defined and board
> DT writers may have interpreted them differently, but it is definitely
> possible to keep DTs reasonably stable if the platform maintainers care
> about that.
> 
> I strongly disagree with platform maintainers denying that duty, by
> claiming that DTs won't be completely stable ever, so there is no reason
> to even care.

A DT is either stable or not. If it is "reasonably" stable, then it's
not.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/566df8f3/attachment.sig>

From maxime.ripard at free-electrons.com  Tue Feb 16 00:45:34 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 16 Feb 2016 09:45:34 +0100
Subject: [linux-sunxi][PATCH v2] ARM: dts: sun4i: Enable USB DRC on the
 MK802
In-Reply-To: <1455278359-22451-1-git-send-email-codekipper@gmail.com>
References: <1455278359-22451-1-git-send-email-codekipper@gmail.com>
Message-ID: <20160216084534.GF4344@lukather>

On Fri, Feb 12, 2016 at 12:59:19PM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
> 
> Enable the otg/drc usb controller on the MK802.
> 
> Signed-off-by: Marcus Cooper <codekipper at gmail.com>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/e4417281/attachment.sig>

From peter.chen at nxp.com  Tue Feb 16 00:42:52 2016
From: peter.chen at nxp.com (Peter Chen)
Date: Tue, 16 Feb 2016 16:42:52 +0800
Subject: [PATCH v5 1/1] USB: core: let USB device know device node
Message-ID: <1455612172-2081-1-git-send-email-peter.chen@nxp.com>

From: Peter Chen <peter.chen at freescale.com>

Although most of USB devices are hot-plug's, there are still some devices
are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
If these kinds of USB devices are multiple functions, and they can supply
other interfaces like i2c, gpios for other devices, we may need to
describe these at device tree.

In this commit, it uses "reg" in dts as physical port number to match
the phyiscal port number decided by USB core, if they are the same,
then the device node is for the device we are creating for USB core.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
Changes for v5:
- Refine the code how to get the device node at usb_alloc_dev according
  to Alan's comment.
- Point out "usbVID,PID" is the recommented compatible, and others
  compatibles at binding doc could also be used.

Changes for v4:
- The range of "reg" should be 1-31, changing device node address
  style as in lower case hexadecimal with leading zeroes suppressed
  [binding doc, usb-device.txt]
- Improve the example at binding doc, it describes node from the top
  (the controller)
- Delete the struct of_node * within struct usb_device
- Using usb_hcd_find_raw_port_number to get raw port number under root
  hub port

Changes for v3:
- typo: s/descirbe/describe/

Changes for v2:
- Fix build error reported by kbuild robot, lack of "static" for
  inline usb_of_get_child_node
- Fix typo, "devcie_node" -> "device_node"
- Add kernel-doc for of_node at struct usb_device

Changes from RFC:
- Fix the error address for binding doc, and add compatible for binding doc
- Change get child node API from "usb_of_find_node" to
  "usb_of_get_child_node"
- Delete unecessary header files
- One typo

 .../devicetree/bindings/usb/usb-device.txt         | 26 ++++++++++++
 drivers/usb/core/Makefile                          |  2 +-
 drivers/usb/core/of.c                              | 47 ++++++++++++++++++++++
 drivers/usb/core/usb.c                             | 10 +++++
 include/linux/usb/of.h                             |  7 ++++
 5 files changed, 91 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/usb/usb-device.txt
 create mode 100644 drivers/usb/core/of.c

diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt b/Documentation/devicetree/bindings/usb/usb-device.txt
new file mode 100644
index 0000000..a997a23
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -0,0 +1,26 @@
+Generic USB Device Properties
+
+Usually, we only use device tree for hard wired USB device.
+The reference binding doc is from:
+http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
+
+Required properties:
+- compatible: usbVID,PID. The other compatible strings from the above
+  standard binding could also be used, but a device adhering to this
+  binding may leave out all except for usbVID,PID.
+- reg: the port number which this device is connecting to, the range
+  is 1-31.
+
+Example:
+
+&usb1 {
+	status = "okay";
+
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	hub: genesys at 1 {
+		compatible = "usb05e3,0608";
+		reg = <1>;
+	};
+}
diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 2f6f932..9780877 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -5,7 +5,7 @@
 usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o
 usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o
 usbcore-y += devio.o notify.o generic.o quirks.o devices.o
-usbcore-y += port.o
+usbcore-y += port.o of.o
 
 usbcore-$(CONFIG_PCI)		+= hcd-pci.o
 usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
new file mode 100644
index 0000000..2289700
--- /dev/null
+++ b/drivers/usb/core/of.c
@@ -0,0 +1,47 @@
+/*
+ * of.c		The helpers for hcd device tree support
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen <peter.chen at freescale.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  of
+ * the License 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/of.h>
+
+/**
+ * usb_of_get_child_node - Find the device node match port number
+ * @parent: the parent device node
+ * @portnum: the port number which device is connecting
+ *
+ * Find the node from device tree according to its port number.
+ *
+ * Return: On success, a pointer to the device node, %NULL on failure.
+ */
+struct device_node *usb_of_get_child_node(struct device_node *parent,
+					int portnum)
+{
+	struct device_node *node;
+	u32 port;
+
+	for_each_child_of_node(parent, node) {
+		if (!of_property_read_u32(node, "reg", &port)) {
+			if (port == portnum)
+				return node;
+		}
+	}
+
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(usb_of_get_child_node);
+
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 16ade41..d9b2564 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -36,6 +36,7 @@
 #include <linux/mutex.h>
 #include <linux/workqueue.h>
 #include <linux/debugfs.h>
+#include <linux/usb/of.h>
 
 #include <asm/io.h>
 #include <linux/scatterlist.h>
@@ -470,6 +471,7 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
 		dev->route = 0;
 
 		dev->dev.parent = bus->controller;
+		dev->dev.of_node = bus->controller->of_node;
 		dev_set_name(&dev->dev, "usb%d", bus->busnum);
 		root_hub = 1;
 	} else {
@@ -494,6 +496,14 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
 		dev->dev.parent = &parent->dev;
 		dev_set_name(&dev->dev, "%d-%s", bus->busnum, dev->devpath);
 
+		if (!parent->parent) {
+			/* device under root hub's port */
+			port1 = usb_hcd_find_raw_port_number(usb_hcd,
+				port1);
+		}
+		dev->dev.of_node = usb_of_get_child_node(parent->dev.of_node,
+				port1);
+
 		/* hub driver sets up TT records */
 	}
 
diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
index 974bce9..de3237f 100644
--- a/include/linux/usb/of.h
+++ b/include/linux/usb/of.h
@@ -16,6 +16,8 @@ enum usb_dr_mode of_usb_get_dr_mode_by_phy(struct device_node *phy_np);
 bool of_usb_host_tpl_support(struct device_node *np);
 int of_usb_update_otg_caps(struct device_node *np,
 			struct usb_otg_caps *otg_caps);
+struct device_node *usb_of_get_child_node(struct device_node *parent,
+			int portnum);
 #else
 static inline enum usb_dr_mode
 of_usb_get_dr_mode_by_phy(struct device_node *phy_np)
@@ -31,6 +33,11 @@ static inline int of_usb_update_otg_caps(struct device_node *np,
 {
 	return 0;
 }
+static inline struct device_node *usb_of_get_child_node
+		(struct device_node *parent, int portnum)
+{
+	return NULL;
+}
 #endif
 
 #if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_SUPPORT)
-- 
1.9.1



From maxime.ripard at free-electrons.com  Tue Feb 16 00:47:52 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 16 Feb 2016 09:47:52 +0100
Subject: [PATCH v3] clk: sunxi: Fix sun8i-a23-apb0-clk divider flags
In-Reply-To: <1455529219-30204-1-git-send-email-wens@csie.org>
References: <1455529219-30204-1-git-send-email-wens@csie.org>
Message-ID: <20160216084752.GG4344@lukather>

On Mon, Feb 15, 2016 at 05:40:19PM +0800, Chen-Yu Tsai wrote:
> The APB0 clock on A23 is a zero-based divider, not a power-of-two based
> divider.
> 
> Note that this patch does not apply cleanly to kernels before 4.5-rc1,
> which added CLK_OF_DECLARE support to this driver.
> 
> Fixes: 57a1fbf28424 ("clk: sunxi: Add A23 APB0 divider clock support")
> Signed-off-by: Chen-Yu Tsai <wens at csie.org>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/a299ab88/attachment.sig>

From ard.biesheuvel at linaro.org  Tue Feb 16 00:49:48 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 09:49:48 +0100
Subject: [PATCH] arm64: mark kernel text segment as MEMBLOCK_NOMAP
In-Reply-To: <20160215120809.GF13683@e104818-lin.cambridge.arm.com>
References: <1455528512-32491-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160215114505.GE13683@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-Y-k_LAbFZJjiPuHq6ssaFCb3WMG_fVGx3ODrvb+hEUQ@mail.gmail.com>
 <20160215120809.GF13683@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu9uwcjc0dgO+KOrmhJ=Kyc1ojD1FF32gu7v7VFNFqKpnw@mail.gmail.com>

On 15 February 2016 at 13:08, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 15, 2016 at 12:53:59PM +0100, Ard Biesheuvel wrote:
>> On 15 February 2016 at 12:45, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > Ard, I'm about to drop the kernel memory map patches from -next. There
>> > are several issues like KASAN (which may as well be a KASAN bug but I
>> > haven't got to the bottom of it yet), initrd (you have patches but
>> > require additional acks).
>> >
>> > I'll keep your stuff on the for-next/kernmap branch and do further
>> > debugging. If it stabilises in the next 1-2 weeks, I'll merge it into
>> > for-next/core for 4.6, otherwise, it will have to wait. I would really
>> > like these patches merged but it looks like they need wider testing.
> [...]
>> If you are going to drop it for now anyway, I can do a v6sub1 with
>> this issue and the initrd issue addressed, but also an issue with the
>> KVM ksym ref patch with GCC 4.8. Since these issues affect
>> bisectability, I'd prefer to rebase entirely, and fold all the fixes
>> rather than apply them on top.
>
> That's fine. I'll push one more patch to the for-next/pgtable branch,
> converting __set_fixmap_offset() back to a macro as it broke other
> architectures. Otherwise it is not rebased and I'll merge it into
> for-next core.
>

If you are doing for-next/core from scratch, perhaps it is better to
squash the fixmap patches as well?


From marc.zyngier at arm.com  Tue Feb 16 00:50:24 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 16 Feb 2016 08:50:24 +0000
Subject: [PATCH v2 4/5] irqchip:create irq domain for each mbigen device
In-Reply-To: <1455604648-20668-5-git-send-email-majun258@huawei.com>
References: <1455604648-20668-1-git-send-email-majun258@huawei.com>
 <1455604648-20668-5-git-send-email-majun258@huawei.com>
Message-ID: <20160216085024.3f573f40@arm.com>

On Tue, 16 Feb 2016 14:37:27 +0800
MaJun <majun258 at huawei.com> wrote:

> From: Ma Jun <majun258 at huawei.com>
> 
> For peripheral devices which connect to mbigen,mbigen is a interrupt
> controller. So, we create irq domain for each mbigen device and add
> mbigen irq domain into irq hierarchy structure.
> 
> Signed-off-by: Ma Jun <majun258 at huawei.com>
> ---
>  drivers/irqchip/irq-mbigen-v1.c |  136 +++++++++++++++++++++++++++++++++++++++
>  1 files changed, 136 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-mbigen-v1.c b/drivers/irqchip/irq-mbigen-v1.c
> index 9445658..61e7ad0 100644
> --- a/drivers/irqchip/irq-mbigen-v1.c
> +++ b/drivers/irqchip/irq-mbigen-v1.c
> @@ -16,11 +16,30 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <linux/interrupt.h>
> +#include <linux/irqchip.h>
>  #include <linux/module.h>
> +#include <linux/msi.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
>  #include <linux/of_platform.h>
>  #include <linux/platform_device.h>
>  #include <linux/slab.h>
>  
> +/* The maximum IRQ pin number of mbigen chip(start from 0) */
> +#define MAXIMUM_IRQ_PIN_NUM		640
> +
> +/**
> + * In mbigen vector register
> + * bit[31:16]:	device id
> + * bit[15:0]:	event id value
> + */
> +#define IRQ_EVENT_ID_MASK		0xffff
> +
> +/* offset of vector register in mbigen node */
> +#define REG_MBIGEN_VEC_OFFSET		0x300
> +#define REG_MBIGEN_EXT_VEC_OFFSET		0x320
> +
>  /**
>   * struct mbigen_device - holds the information of mbigen device.
>   *
> @@ -32,10 +51,112 @@ struct mbigen_device {
>  	void __iomem		*base;
>  };
>  
> +static int get_mbigen_nid(unsigned int offset)
> +{
> +	int nid = 0;
> +
> +	if (offset < 256)
> +		nid = offset / 64;
> +	else if (offset < 384)
> +		nid = 4;
> +	else if (offset < 640)
> +		nid = 5;
> +
> +	return nid;
> +}
> +
> +static inline unsigned int get_mbigen_vec_reg(irq_hw_number_t hwirq)
> +{
> +	unsigned int nid;
> +
> +	nid = get_mbigen_nid(hwirq);
> +
> +	if (nid < 4)
> +		return (nid * 4) + REG_MBIGEN_VEC_OFFSET;
> +	else
> +		return (nid - 4) * 4 + REG_MBIGEN_EXT_VEC_OFFSET;
> +}
> +
> +static struct irq_chip mbigen_irq_chip = {
> +	.name =			"mbigen-v1",
> +};
> +
> +static void mbigen_write_msg(struct msi_desc *desc, struct msi_msg *msg)
> +{
> +	/* The address of doorbell is encoded in mbigen register by default
> +	 * So,we don't need to program the doorbell address at here
> +	 * Besides, the event ID is decided by the hardware pin number,
> +	 * we can't change it in software.So, we don't need to encode the
> +	 * event ID in mbigen register.
> +	 */

Really? What if tomorrow I decide to change the EventID allocation
policy in the ITS driver? Have your HW engineers really baked the
behaviour of the Linux driver into the device?

I'm puzzled.

	M.
-- 
Jazz is not dead. It just smells funny.


From yingjoe.chen at mediatek.com  Tue Feb 16 00:54:29 2016
From: yingjoe.chen at mediatek.com (Yingjoe Chen)
Date: Tue, 16 Feb 2016 16:54:29 +0800
Subject: [PATCH 1/2] pinctrl: mediatek: fix direction control issue
In-Reply-To: <1455242831.35628.15.camel@mussux00>
References: <1454462686-770-1-git-send-email-biao.huang@mediatek.com>
 <1454462686-770-2-git-send-email-biao.huang@mediatek.com>
 <1454555015.4618.10.camel@mussux00>
 <CACRpkdZb2-TX1eY7eyK5qCqOg66MP1e4+OO287roJdP=RB6-Fg@mail.gmail.com>
 <1455242831.35628.15.camel@mussux00>
Message-ID: <1455612869.11448.22.camel@mtksdaap41>

On Thu, 2016-02-11 at 18:07 -0800, Hongzhou Yang wrote:
> On Fri, 2016-02-05 at 14:52 +0100, Linus Walleij wrote:
> > On Thu, Feb 4, 2016 at 4:03 AM, Hongzhou Yang
> > <hongzhou.yang at mediatek.com> wrote:
> > > On Wed, 2016-02-03 at 09:24 +0800, Biao Huang wrote:
> > >> Since input-enable/disable and input-schmitt-enable/disable are
> > >> workable when gpio direction is input, so add direction setting
> > >> when do input-enable/disable and input-schmitt-enable/disable
> > >> properties.
> > >>
> > >> Signed-off-by: Biao Huang <biao.huang at mediatek.com>
> > >> ---
> > >>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c |    2 ++
> > >>  1 file changed, 2 insertions(+)
> > >>
> > >> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> > >> index 8cac73d..6eb01c9 100644
> > >> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> > >> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> > >> @@ -352,6 +352,7 @@ static int mtk_pconf_parse_conf(struct pinctrl_dev *pctldev,
> > >>               ret = mtk_pconf_set_pull_select(pctl, pin, true, false, arg);
> > >>               break;
> > >>       case PIN_CONFIG_INPUT_ENABLE:
> > >> +             mtk_pmx_gpio_set_direction(pctldev, NULL, pin, true);
> > >>               ret = mtk_pconf_set_ies_smt(pctl, pin, arg, param);
> > >
> > > Hi Linus,
> > >
> > > From pinctrl-bindings.txt, 'input-enable' property defined as following:
> > > input-enable        - enable input on pin (no effect on output)
> > >
> > > Since input enable and input direction are two different settings on our
> > > SOC,
> > 
> > What does this mean? How can input have a "direction"?
> > 
> > Isn't the direction of an input always inbound, into the SoC?
> > 
> > Please elaborate.
> 
> Sorry for the late reply.
> There are two conditions if external device input data into SOC.
> 1. Change GPIO direction to input.
> 2. Switch on input.
> 
> 
> > > could you tell me the exact meaning of this property? Input enable
> > > only? Or set input direction at the same time?
> > 
> > This was added in commit 8ba3f4d00078e7a49c60c0bd6298f29402c3a0a0
> > "pinctrl: Adds slew-rate, input-enable/disable"
> > by Sherman Yin so let's ask him first.
> 
> Thanks for this info.
> From Sherman's comment, PIN_CONFIG_INPUT_ENABLE seems only to stand for
> the condition 2.
> 
> * @PIN_CONFIG_INPUT_ENABLE: enable the pin's input.  Note that this does
> not affect the pin's ability to drive output.  1 enables input, 0
> disables input.
> 
> Then I get confuse if we can change direction under this property.

Hi,

To make it more clear, for a GPIO pin to get input on MTK chip, we must:

- Enable input for the pad (input-enable)
- Set mux to GPIO mode
- Set GPIO direction to input

Currently user need to add a dts node to set pinmux to GPIO mode with
input-enable property, the driver need to call gpio_direction_input to
set direction.

Since input-enable and GPIO direction are 2 different things, we now
think this patch is inappropriate. Instead, user should not required to
add pinmux node in dts if all he want is use it as plain GPIO input.
Patch [2/2] remove the need to set it to GPIO mode, Biao will send a new
patch to remove the need for input-enable.

Joe.C




From wefu at redhat.com  Tue Feb 16 00:55:46 2016
From: wefu at redhat.com (Fu Wei)
Date: Tue, 16 Feb 2016 16:55:46 +0800
Subject: [PATCH v5sub1 8/8] arm64: allow kernel Image to be loaded
 anywhere in physical memory
In-Reply-To: <56AF8797.5000908@redhat.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-9-git-send-email-ard.biesheuvel@linaro.org>
 <20160201145014.GK674@leverpostej> <56AF8797.5000908@redhat.com>
Message-ID: <56C2E412.3000402@redhat.com>



On 02/02/2016 12:28 AM, Fu Wei wrote:
> Hi Mark
>
> On 02/01/2016 10:50 PM, Mark Rutland wrote:
>> On Mon, Feb 01, 2016 at 11:54:53AM +0100, Ard Biesheuvel wrote:
>>> This relaxes the kernel Image placement requirements, so that it
>>> may be placed at any 2 MB aligned offset in physical memory.
>>>
>>> This is accomplished by ignoring PHYS_OFFSET when installing
>>> memblocks, and accounting for the apparent virtual offset of
>>> the kernel Image. As a result, virtual address references
>>> below PAGE_OFFSET are correctly mapped onto physical references
>>> into the kernel Image regardless of where it sits in memory.
>>>
>>> Note that limiting memory using mem= is not unambiguous anymore after
>>> this change, considering that the kernel may be at the top of physical
>>> memory, and clipping from the bottom rather than the top will discard
>>> any 32-bit DMA addressable memory first. To deal with this, the handling
>>> of mem= is reimplemented to clip top down, but take special care not to
>>> clip memory that covers the kernel image.
>>>
>>> Since mem= should not be considered a production feature, a panic
>>> notifier
>>> handler is installed that dumps the memory limit at panic time if one
>>> was
>>> set.
>>
>> Good idea!
>>
>> It would be great if we could follow up with a sizes.h update for SZ_4G,
>> though that's only a nice-to-have, and in no way should block this.
>>
>> Other than that, this looks good. Thanks for putting this together!
>>
>> Reviewed-by: Mark Rutland <mark.rutland at arm.com>
>>
>> For the Documentation/arm64 parts we'll need to ask Fu Wei to update the
>> zh_CN/ translation to match.
>
> Great thanks for your info
> Yes, I will working on it

The zh_CN patch has been prepared, once the English version is merged 
into mainline, I will upstream that immediately.
Because there is another zh_CN patch for booting.txt in upstream 
procedure: https://lkml.org/lkml/2016/2/16/164

sorry for delay. :-)

>
>>
>> Mark.
>>
>>>
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>>> ---
>>>   Documentation/arm64/booting.txt         |  20 ++--
>>>   arch/arm64/include/asm/boot.h           |   6 ++
>>>   arch/arm64/include/asm/kernel-pgtable.h |  12 +++
>>>   arch/arm64/include/asm/kvm_asm.h        |   2 +-
>>>   arch/arm64/include/asm/memory.h         |  15 +--
>>>   arch/arm64/kernel/head.S                |   6 +-
>>>   arch/arm64/kernel/image.h               |  13 ++-
>>>   arch/arm64/mm/init.c                    | 100 +++++++++++++++++++-
>>>   arch/arm64/mm/mmu.c                     |   3 +
>>>   9 files changed, 155 insertions(+), 22 deletions(-)
>>>
>>> diff --git a/Documentation/arm64/booting.txt
>>> b/Documentation/arm64/booting.txt
>>> index 701d39d3171a..56d6d8b796db 100644
>>> --- a/Documentation/arm64/booting.txt
>>> +++ b/Documentation/arm64/booting.txt
>>> @@ -109,7 +109,13 @@ Header notes:
>>>               1 - 4K
>>>               2 - 16K
>>>               3 - 64K
>>> -  Bits 3-63:    Reserved.
>>> +  Bit 3:    Kernel physical placement
>>> +            0 - 2MB aligned base should be as close as possible
>>> +                to the base of DRAM, since memory below it is not
>>> +                accessible via the linear mapping
>>> +            1 - 2MB aligned base may be anywhere in physical
>>> +                memory
>>> +  Bits 4-63:    Reserved.
>>>
>>>   - When image_size is zero, a bootloader should attempt to keep as much
>>>     memory as possible free for use by the kernel immediately after the
>>> @@ -117,14 +123,14 @@ Header notes:
>>>     depending on selected features, and is effectively unbound.
>>>
>>>   The Image must be placed text_offset bytes from a 2MB aligned base
>>> -address near the start of usable system RAM and called there. Memory
>>> -below that base address is currently unusable by Linux, and
>>> therefore it
>>> -is strongly recommended that this location is the start of system RAM.
>>> -The region between the 2 MB aligned base address and the start of the
>>> -image has no special significance to the kernel, and may be used for
>>> -other purposes.
>>> +address anywhere in usable system RAM and called there. The region
>>> +between the 2 MB aligned base address and the start of the image has no
>>> +special significance to the kernel, and may be used for other purposes.
>>>   At least image_size bytes from the start of the image must be free for
>>>   use by the kernel.
>>> +NOTE: versions prior to v4.6 cannot make use of memory below the
>>> +physical offset of the Image so it is recommended that the Image be
>>> +placed as close as possible to the start of system RAM.
>>>
>>>   Any memory described to the kernel (even that below the start of the
>>>   image) which is not marked as reserved from the kernel (e.g., with a
>>> diff --git a/arch/arm64/include/asm/boot.h
>>> b/arch/arm64/include/asm/boot.h
>>> index 81151b67b26b..ebf2481889c3 100644
>>> --- a/arch/arm64/include/asm/boot.h
>>> +++ b/arch/arm64/include/asm/boot.h
>>> @@ -11,4 +11,10 @@
>>>   #define MIN_FDT_ALIGN        8
>>>   #define MAX_FDT_SIZE        SZ_2M
>>>
>>> +/*
>>> + * arm64 requires the kernel image to placed
>>> + * TEXT_OFFSET bytes beyond a 2 MB aligned base
>>> + */
>>> +#define MIN_KIMG_ALIGN        SZ_2M
>>> +
>>>   #endif
>>> diff --git a/arch/arm64/include/asm/kernel-pgtable.h
>>> b/arch/arm64/include/asm/kernel-pgtable.h
>>> index a459714ee29e..5c6375d8528b 100644
>>> --- a/arch/arm64/include/asm/kernel-pgtable.h
>>> +++ b/arch/arm64/include/asm/kernel-pgtable.h
>>> @@ -79,5 +79,17 @@
>>>   #define SWAPPER_MM_MMUFLAGS    (PTE_ATTRINDX(MT_NORMAL) |
>>> SWAPPER_PTE_FLAGS)
>>>   #endif
>>>
>>> +/*
>>> + * To make optimal use of block mappings when laying out the linear
>>> + * mapping, round down the base of physical memory to a size that can
>>> + * be mapped efficiently, i.e., either PUD_SIZE (4k granule) or
>>> PMD_SIZE
>>> + * (64k granule), or a multiple that can be mapped using contiguous
>>> bits
>>> + * in the page tables: 32 * PMD_SIZE (16k granule)
>>> + */
>>> +#ifdef CONFIG_ARM64_64K_PAGES
>>> +#define ARM64_MEMSTART_ALIGN    SZ_512M
>>> +#else
>>> +#define ARM64_MEMSTART_ALIGN    SZ_1G
>>> +#endif
>>>
>>>   #endif    /* __ASM_KERNEL_PGTABLE_H */
>>> diff --git a/arch/arm64/include/asm/kvm_asm.h
>>> b/arch/arm64/include/asm/kvm_asm.h
>>> index f5aee6e764e6..054ac25e7c2e 100644
>>> --- a/arch/arm64/include/asm/kvm_asm.h
>>> +++ b/arch/arm64/include/asm/kvm_asm.h
>>> @@ -26,7 +26,7 @@
>>>   #define KVM_ARM64_DEBUG_DIRTY_SHIFT    0
>>>   #define KVM_ARM64_DEBUG_DIRTY        (1 <<
>>> KVM_ARM64_DEBUG_DIRTY_SHIFT)
>>>
>>> -#define kvm_ksym_ref(sym)        ((void *)&sym - KIMAGE_VADDR +
>>> PAGE_OFFSET)
>>> +#define kvm_ksym_ref(sym)        phys_to_virt((u64)&sym -
>>> kimage_voffset)
>>>
>>>   #ifndef __ASSEMBLY__
>>>   struct kvm;
>>> diff --git a/arch/arm64/include/asm/memory.h
>>> b/arch/arm64/include/asm/memory.h
>>> index 4388651d1f0d..61005e7dd6cb 100644
>>> --- a/arch/arm64/include/asm/memory.h
>>> +++ b/arch/arm64/include/asm/memory.h
>>> @@ -88,10 +88,10 @@
>>>   #define __virt_to_phys(x) ({                        \
>>>       phys_addr_t __x = (phys_addr_t)(x);                \
>>>       __x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :    \
>>> -                 (__x - KIMAGE_VADDR + PHYS_OFFSET); })
>>> +                 (__x - kimage_voffset); })
>>>
>>>   #define __phys_to_virt(x)    ((unsigned long)((x) - PHYS_OFFSET +
>>> PAGE_OFFSET))
>>> -#define __phys_to_kimg(x)    ((unsigned long)((x) - PHYS_OFFSET +
>>> KIMAGE_VADDR))
>>> +#define __phys_to_kimg(x)    ((unsigned long)((x) + kimage_voffset))
>>>
>>>   /*
>>>    * Convert a page to/from a physical address
>>> @@ -127,13 +127,14 @@ extern phys_addr_t        memstart_addr;
>>>   /* PHYS_OFFSET - the physical address of the start of memory. */
>>>   #define PHYS_OFFSET        ({ memstart_addr; })
>>>
>>> +/* the offset between the kernel virtual and physical mappings */
>>> +extern u64            kimage_voffset;
>>> +
>>>   /*
>>> - * The maximum physical address that the linear direct mapping
>>> - * of system RAM can cover. (PAGE_OFFSET can be interpreted as
>>> - * a 2's complement signed quantity and negated to derive the
>>> - * maximum size of the linear mapping.)
>>> + * Allow all memory at the discovery stage. We will clip it later.
>>>    */
>>> -#define MAX_MEMBLOCK_ADDR    ({ memstart_addr - PAGE_OFFSET - 1; })
>>> +#define MIN_MEMBLOCK_ADDR    0
>>> +#define MAX_MEMBLOCK_ADDR    U64_MAX
>>>
>>>   /*
>>>    * PFNs are used to describe any physical page; this means
>>> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
>>> index 04d38a058b19..05b98289093e 100644
>>> --- a/arch/arm64/kernel/head.S
>>> +++ b/arch/arm64/kernel/head.S
>>> @@ -428,7 +428,11 @@ __mmap_switched:
>>>       and    x4, x4, #~(THREAD_SIZE - 1)
>>>       msr    sp_el0, x4            // Save thread_info
>>>       str_l    x21, __fdt_pointer, x5        // Save FDT pointer
>>> -    str_l    x24, memstart_addr, x6        // Save PHYS_OFFSET
>>> +
>>> +    ldr    x4, =KIMAGE_VADDR        // Save the offset between
>>> +    sub    x4, x4, x24            // the kernel virtual and
>>> +    str_l    x4, kimage_voffset, x5        // physical mappings
>>> +
>>>       mov    x29, #0
>>>   #ifdef CONFIG_KASAN
>>>       bl    kasan_early_init
>>> diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
>>> index 999633bd7294..c9c62cab25a4 100644
>>> --- a/arch/arm64/kernel/image.h
>>> +++ b/arch/arm64/kernel/image.h
>>> @@ -42,15 +42,18 @@
>>>   #endif
>>>
>>>   #ifdef CONFIG_CPU_BIG_ENDIAN
>>> -#define __HEAD_FLAG_BE    1
>>> +#define __HEAD_FLAG_BE        1
>>>   #else
>>> -#define __HEAD_FLAG_BE    0
>>> +#define __HEAD_FLAG_BE        0
>>>   #endif
>>>
>>> -#define __HEAD_FLAG_PAGE_SIZE ((PAGE_SHIFT - 10) / 2)
>>> +#define __HEAD_FLAG_PAGE_SIZE    ((PAGE_SHIFT - 10) / 2)
>>>
>>> -#define __HEAD_FLAGS    ((__HEAD_FLAG_BE << 0) |    \
>>> -             (__HEAD_FLAG_PAGE_SIZE << 1))
>>> +#define __HEAD_FLAG_PHYS_BASE    1
>>> +
>>> +#define __HEAD_FLAGS        ((__HEAD_FLAG_BE << 0) |    \
>>> +                 (__HEAD_FLAG_PAGE_SIZE << 1) |    \
>>> +                 (__HEAD_FLAG_PHYS_BASE << 3))
>>>
>>>   /*
>>>    * These will output as part of the Image header, which should be
>>> little-endian
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index 1d627cd8121c..e8e853a1024c 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -35,8 +35,10 @@
>>>   #include <linux/efi.h>
>>>   #include <linux/swiotlb.h>
>>>
>>> +#include <asm/boot.h>
>>>   #include <asm/fixmap.h>
>>>   #include <asm/kasan.h>
>>> +#include <asm/kernel-pgtable.h>
>>>   #include <asm/memory.h>
>>>   #include <asm/sections.h>
>>>   #include <asm/setup.h>
>>> @@ -158,9 +160,80 @@ static int __init early_mem(char *p)
>>>   }
>>>   early_param("mem", early_mem);
>>>
>>> +/*
>>> + * clip_mem_range() - remove memblock memory between @min and @max
>>> until
>>> + *                    we meet the limit in 'memory_limit'.
>>> + */
>>> +static void __init clip_mem_range(u64 min, u64 max)
>>> +{
>>> +    u64 mem_size, to_remove;
>>> +    int i;
>>> +
>>> +again:
>>> +    mem_size = memblock_phys_mem_size();
>>> +    if (mem_size <= memory_limit || max <= min)
>>> +        return;
>>> +
>>> +    to_remove = mem_size - memory_limit;
>>> +
>>> +    for (i = memblock.memory.cnt - 1; i >= 0; i--) {
>>> +        struct memblock_region *r = memblock.memory.regions + i;
>>> +        u64 start = max(min, r->base);
>>> +        u64 end = min(max, r->base + r->size);
>>> +
>>> +        if (start >= max || end <= min)
>>> +            continue;
>>> +
>>> +        if (end > min) {
>>> +            u64 size = min(to_remove, end - max(start, min));
>>> +
>>> +            memblock_remove(end - size, size);
>>> +        } else {
>>> +            memblock_remove(start, min(max - start, to_remove));
>>> +        }
>>> +        goto again;
>>> +    }
>>> +}
>>> +
>>>   void __init arm64_memblock_init(void)
>>>   {
>>> -    memblock_enforce_memory_limit(memory_limit);
>>> +    const s64 linear_region_size = -(s64)PAGE_OFFSET;
>>> +
>>> +    /*
>>> +     * Select a suitable value for the base of physical memory.
>>> +     */
>>> +    memstart_addr = round_down(memblock_start_of_DRAM(),
>>> +                   ARM64_MEMSTART_ALIGN);
>>> +
>>> +    /*
>>> +     * Remove the memory that we will not be able to cover with the
>>> +     * linear mapping. Take care not to clip the kernel which may be
>>> +     * high in memory.
>>> +     */
>>> +    memblock_remove(max(memstart_addr + linear_region_size,
>>> __pa(_end)),
>>> +            ULLONG_MAX);
>>> +    if (memblock_end_of_DRAM() > linear_region_size)
>>> +        memblock_remove(0, memblock_end_of_DRAM() -
>>> linear_region_size);
>>> +
>>> +    if (memory_limit != (phys_addr_t)ULLONG_MAX) {
>>> +        u64 kbase = round_down(__pa(_text), MIN_KIMG_ALIGN);
>>> +        u64 kend = PAGE_ALIGN(__pa(_end));
>>> +        u64 const sz_4g = 0x100000000UL;
>>> +
>>> +        /*
>>> +         * Clip memory in order of preference:
>>> +         * - above the kernel and above 4 GB
>>> +         * - between 4 GB and the start of the kernel (if the kernel
>>> +         *   is loaded high in memory)
>>> +         * - between the kernel and 4 GB (if the kernel is loaded
>>> +         *   low in memory)
>>> +         * - below 4 GB
>>> +         */
>>> +        clip_mem_range(max(sz_4g, kend), ULLONG_MAX);
>>> +        clip_mem_range(sz_4g, kbase);
>>> +        clip_mem_range(kend, sz_4g);
>>> +        clip_mem_range(0, min(kbase, sz_4g));
>>> +    }
>>>
>>>       /*
>>>        * Register the kernel text, kernel data, initrd, and initial
>>> @@ -381,3 +454,28 @@ static int __init keepinitrd_setup(char *__unused)
>>>
>>>   __setup("keepinitrd", keepinitrd_setup);
>>>   #endif
>>> +
>>> +/*
>>> + * Dump out memory limit information on panic.
>>> + */
>>> +static int dump_mem_limit(struct notifier_block *self, unsigned long
>>> v, void *p)
>>> +{
>>> +    if (memory_limit != (phys_addr_t)ULLONG_MAX) {
>>> +        pr_emerg("Memory Limit: %llu MB\n", memory_limit >> 20);
>>> +    } else {
>>> +        pr_emerg("Memory Limit: none\n");
>>> +    }
>>> +    return 0;
>>> +}
>>> +
>>> +static struct notifier_block mem_limit_notifier = {
>>> +    .notifier_call = dump_mem_limit,
>>> +};
>>> +
>>> +static int __init register_mem_limit_dumper(void)
>>> +{
>>> +    atomic_notifier_chain_register(&panic_notifier_list,
>>> +                       &mem_limit_notifier);
>>> +    return 0;
>>> +}
>>> +__initcall(register_mem_limit_dumper);
>>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>>> index 4c4b15932963..8dda38378959 100644
>>> --- a/arch/arm64/mm/mmu.c
>>> +++ b/arch/arm64/mm/mmu.c
>>> @@ -46,6 +46,9 @@
>>>
>>>   u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
>>>
>>> +u64 kimage_voffset __read_mostly;
>>> +EXPORT_SYMBOL(kimage_voffset);
>>> +
>>>   /*
>>>    * Empty_zero_page is a special page that is used for
>>> zero-initialized data
>>>    * and COW.
>>> --
>>> 2.5.0
>>>


From arnd at arndb.de  Tue Feb 16 01:17:52 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 10:17:52 +0100
Subject: [PATCH] branch tracer: fix freak link error
In-Reply-To: <20160215152639.7795795c@gandalf.local.home>
References: <1455312410-1058841-1-git-send-email-arnd@arndb.de>
 <2535125.MjntUgx4sh@wuerfel> <20160215152639.7795795c@gandalf.local.home>
Message-ID: <3821446.rAiXri9yEZ@wuerfel>

On Monday 15 February 2016 15:26:39 Steven Rostedt wrote:
> On Mon, 15 Feb 2016 21:15:39 +0100
> Arnd Bergmann <arnd at arndb.de> wrote:
> 
> > Do you also want to add a 'Cc: stable at vger.kernel.org' tag?
> > 
> 
> I currently have this in the Tags:
> 
>     Acked-by: Nicolas Pitre <nico at linaro.org>
>     Fixes: ab3c9c686e22 ("branch tracer, intel-iommu: fix build with CONFIG_BRANCH_TRACER=y")
>     Cc: stable at vger.kernel.org # v2.6.30+
>     Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>     Signed-off-by: Steven Rostedt <rostedt at goodmis.org>
> 

Looks good, thanks!

	Arnd


From jay.xu at rock-chips.com  Tue Feb 16 01:22:18 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Tue, 16 Feb 2016 17:22:18 +0800
Subject: [PATCH] spi/rockchip: Add dt-binding for Rockchip rk3399 spi
Message-ID: <1455614538-4415-1-git-send-email-jay.xu@rock-chips.com>

From: Xu Jianqun <jay.xu at rock-chips.com>

Add compatible support for Rockchip rk3399 spi.

Signed-off-by: Xu Jianqun <jay.xu at rock-chips.com>
---
 Documentation/devicetree/bindings/spi/spi-rockchip.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
index 0c491bd..1b14d69 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
@@ -9,6 +9,7 @@ Required Properties:
     "rockchip,rk3066-spi" for rk3066.
     "rockchip,rk3188-spi", "rockchip,rk3066-spi" for rk3188.
     "rockchip,rk3288-spi", "rockchip,rk3066-spi" for rk3288.
+    "rockchip,rk3399-spi", "rockchip,rk3066-spi" for rk3399.
 - reg: physical base address of the controller and length of memory mapped
        region.
 - interrupts: The interrupt number to the cpu. The interrupt specifier format
-- 
1.9.1




From Suravee.Suthikulpanit at amd.com  Tue Feb 16 01:25:11 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Tue, 16 Feb 2016 16:25:11 +0700
Subject: [PATCH v11 4/4] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <1455037240-16192-5-git-send-email-fu.wei@linaro.org>
References: <1455037240-16192-1-git-send-email-fu.wei@linaro.org>
 <1455037240-16192-5-git-send-email-fu.wei@linaro.org>
Message-ID: <56C2EAF7.1000608@amd.com>

Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Thanks,
Suravee

On 02/10/2016 12:00 AM, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei at linaro.org>
>
> According to Server Base System Architecture (SBSA) specification,
> the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0)
> is for alerting the system by interrupt, the second one (WS1) is a real
> hardware reset.
> More details about the hardware specification of this device:
> ARM DEN0029B - Server Base System Architecture (SBSA)
>
> This driver can operate ARM SBSA Generic Watchdog as a single stage watchdog
> or a two stages watchdog, it's set up by the module parameter "action".
> In the single stage mode, when the timeout is reached, your system
> will be reset by WS1. The first signal (WS0) is ignored.
> In the two stages mode, when the timeout is reached, the first signal (WS0)
> will trigger panic. If the system is getting into trouble and cannot be reset
> by panic or restart properly by the kdump kernel(if supported), then the
> second stage (as long as the first stage) will be reached, system will be
> reset by WS1. This function can help administrator to backup the system
> context info by panic console output or kdump.
>
> This driver bases on linux kernel watchdog framework, so it can get
> timeout from module parameter and FDT at the driver init stage.
>
> Signed-off-by: Fu Wei <fu.wei at linaro.org>
> Reviewed-by: Graeme Gregory <graeme.gregory at linaro.org>
> Tested-by: Pratyush Anand <panand at redhat.com>
> ---
>   drivers/watchdog/Kconfig     |  20 +++
>   drivers/watchdog/Makefile    |   1 +
>   drivers/watchdog/sbsa_gwdt.c | 403 +++++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 424 insertions(+)
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 0f6d851..ed9a5cb 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -202,6 +202,26 @@ config ARM_SP805_WATCHDOG
>   	  ARM Primecell SP805 Watchdog timer. This will reboot your system when
>   	  the timeout is reached.
>
> +config ARM_SBSA_WATCHDOG
> +	tristate "ARM SBSA Generic Watchdog"
> +	depends on ARM64
> +	depends on ARM_ARCH_TIMER
> +	select WATCHDOG_CORE
> +	help
> +	  ARM SBSA Generic Watchdog has two stage timeouts:
> +	  the first signal (WS0) is for alerting the system by interrupt,
> +	  the second one (WS1) is a real hardware reset.
> +	  More details: ARM DEN0029B - Server Base System Architecture (SBSA)
> +
> +	  This driver can operate ARM SBSA Generic Watchdog as a single stage
> +	  or a two stages watchdog, it depends on the module parameter "action".
> +
> +	  Note: the maximum timeout in the two stages mode is half of that in
> +	  the single stage mode.
> +
> +	  To compile this driver as module, choose M here: The module
> +	  will be called sbsa_gwdt.
> +
>   config ASM9260_WATCHDOG
>   	tristate "Alphascale ASM9260 watchdog"
>   	depends on MACH_ASM9260
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index f566753..f9826d4 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
>
>   # ARM Architecture
>   obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
> +obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
>   obj-$(CONFIG_ASM9260_WATCHDOG) += asm9260_wdt.o
>   obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
>   obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
> new file mode 100644
> index 0000000..f506762
> --- /dev/null
> +++ b/drivers/watchdog/sbsa_gwdt.c
> @@ -0,0 +1,403 @@
> +/*
> + * SBSA(Server Base System Architecture) Generic Watchdog driver
> + *
> + * Copyright (c) 2015, Linaro Ltd.
> + * Author: Fu Wei <fu.wei at linaro.org>
> + *         Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
> + *         Al Stone <al.stone at linaro.org>
> + *         Timur Tabi <timur at codeaurora.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License 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.
> + *
> + * ARM SBSA Generic Watchdog has two stage timeouts:
> + * the first signal (WS0) is for alerting the system by interrupt,
> + * the second one (WS1) is a real hardware reset.
> + * More details about the hardware specification of this device:
> + * ARM DEN0029B - Server Base System Architecture (SBSA)
> + *
> + * This driver can operate ARM SBSA Generic Watchdog as a single stage watchdog
> + * or a two stages watchdog, it's set up by the module parameter "action".
> + * In the single stage mode, when the timeout is reached, your system
> + * will be reset by WS1. The first signal (WS0) is ignored.
> + * In the two stages mode, when the timeout is reached, the first signal (WS0)
> + * will trigger panic. If the system is getting into trouble and cannot be reset
> + * by panic or restart properly by the kdump kernel(if supported), then the
> + * second stage (as long as the first stage) will be reached, system will be
> + * reset by WS1. This function can help administrator to backup the system
> + * context info by panic console output or kdump.
> + *
> + * SBSA GWDT:
> + * if action is 1 (the two stages mode):
> + * |--------WOR-------WS0--------WOR-------WS1
> + * |----timeout-----(panic)----timeout-----reset
> + *
> + * if action is 0 (the single stage mode):
> + * |------WOR-----WS0(ignored)-----WOR------WS1
> + * |--------------timeout-------------------reset
> + *
> + * Note: Since this watchdog timer has two stages, and each stage is determined
> + * by WOR, in the single stage mode, the timeout is (WOR * 2); in the two
> + * stages mode, the timeout is WOR. The maximum timeout in the two stages mode
> + * is half of that in the single stage mode.
> + *
> + */
> +
> +#include <linux/io.h>
> +#include <linux/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/moduleparam.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/uaccess.h>
> +#include <linux/watchdog.h>
> +#include <asm/arch_timer.h>
> +
> +/* SBSA Generic Watchdog register definitions */
> +/* refresh frame */
> +#define SBSA_GWDT_WRR				0x000
> +
> +/* control frame */
> +#define SBSA_GWDT_WCS				0x000
> +#define SBSA_GWDT_WOR				0x008
> +#define SBSA_GWDT_WCV				0x010
> +
> +/* refresh/control frame */
> +#define SBSA_GWDT_W_IIDR			0xfcc
> +#define SBSA_GWDT_IDR				0xfd0
> +
> +/* Watchdog Control and Status Register */
> +#define SBSA_GWDT_WCS_EN			BIT(0)
> +#define SBSA_GWDT_WCS_WS0			BIT(1)
> +#define SBSA_GWDT_WCS_WS1			BIT(2)
> +
> +/**
> + * struct sbsa_gwdt - Internal representation of the SBSA GWDT
> + * @wdd:		kernel watchdog_device structure
> + * @clk:		store the System Counter clock frequency, in Hz.
> + * @refresh_base:	Virtual address of the watchdog refresh frame
> + * @control_base:	Virtual address of the watchdog control frame
> + */
> +struct sbsa_gwdt {
> +	struct watchdog_device	wdd;
> +	u32			clk;
> +	void __iomem		*refresh_base;
> +	void __iomem		*control_base;
> +};
> +
> +#define to_sbsa_gwdt(e) container_of(e, struct sbsa_gwdt, wdd)
> +
> +#define DEFAULT_TIMEOUT		10 /* seconds, the 1st + 2nd watch periods*/
> +
> +static unsigned int timeout;
> +module_param(timeout, uint, 0);
> +MODULE_PARM_DESC(timeout,
> +		 "Watchdog timeout in seconds. (>=0, default="
> +		 __MODULE_STRING(DEFAULT_TIMEOUT) ")");
> +
> +/*
> + * action refers to action taken when watchdog gets WS0
> + * 0 = skip
> + * 1 = panic
> + * defaults to skip (0)
> + */
> +static int action;
> +module_param(action, int, 0);
> +MODULE_PARM_DESC(action, "after watchdog gets WS0 interrupt, do: "
> +		 "0 = skip(*)  1 = panic");
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +module_param(nowayout, bool, S_IRUGO);
> +MODULE_PARM_DESC(nowayout,
> +		 "Watchdog cannot be stopped once started (default="
> +		 __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> +
> +/*
> + * watchdog operation functions
> + */
> +static int sbsa_gwdt_set_timeout(struct watchdog_device *wdd,
> +				 unsigned int timeout)
> +{
> +	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +
> +	wdd->timeout = timeout;
> +
> +	if (action)
> +		writel(gwdt->clk * timeout,
> +		       gwdt->control_base + SBSA_GWDT_WOR);
> +	else
> +		/*
> +		 * In the single stage mode, The first signal (WS0) is ignored,
> +		 * the timeout is (WOR * 2), so the WOR should be configured
> +		 * to half value of timeout.
> +		 */
> +		writel(gwdt->clk / 2 * timeout,
> +		       gwdt->control_base + SBSA_GWDT_WOR);
> +
> +	return 0;
> +}
> +
> +static unsigned int sbsa_gwdt_get_timeleft(struct watchdog_device *wdd)
> +{
> +	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +	u64 timeleft = 0;
> +
> +	/*
> +	 * In the single stage mode, if WS0 is deasserted
> +	 * (watchdog is in the first stage),
> +	 * timeleft = WOR + (WCV - system counter)
> +	 */
> +	if (!action &&
> +	    !(readl(gwdt->control_base + SBSA_GWDT_WCS) & SBSA_GWDT_WCS_WS0))
> +		timeleft += readl(gwdt->control_base + SBSA_GWDT_WOR);
> +
> +	timeleft += readq(gwdt->control_base + SBSA_GWDT_WCV) -
> +		    arch_counter_get_cntvct();
> +
> +	do_div(timeleft, gwdt->clk);
> +
> +	return timeleft;
> +}
> +
> +static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
> +{
> +	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +
> +	/*
> +	* Writing WRR for an explicit watchdog refresh.
> +	* You can write anyting (like 0).
> +	*/
> +	writel(0, gwdt->refresh_base + SBSA_GWDT_WRR);
> +
> +	return 0;
> +}
> +
> +static unsigned int sbsa_gwdt_status(struct watchdog_device *wdd)
> +{
> +	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +	u32 status = readl(gwdt->control_base + SBSA_GWDT_WCS);
> +
> +	/* is the watchdog timer running? */
> +	return (status & SBSA_GWDT_WCS_EN) << WDOG_ACTIVE;
> +}
> +
> +static int sbsa_gwdt_start(struct watchdog_device *wdd)
> +{
> +	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +
> +	/* writing WCS will cause an explicit watchdog refresh */
> +	writel(SBSA_GWDT_WCS_EN, gwdt->control_base + SBSA_GWDT_WCS);
> +
> +	return sbsa_gwdt_keepalive(wdd);
> +}
> +
> +static int sbsa_gwdt_stop(struct watchdog_device *wdd)
> +{
> +	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
> +
> +	/* Simply write 0 to WCS to clean WCS_EN bit */
> +	writel(0, gwdt->control_base + SBSA_GWDT_WCS);
> +
> +	return 0;
> +}
> +
> +static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
> +{
> +	panic("SBSA Watchdog timeout");
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static struct watchdog_info sbsa_gwdt_info = {
> +	.identity	= "SBSA Generic Watchdog",
> +	.options	= WDIOF_SETTIMEOUT |
> +			  WDIOF_KEEPALIVEPING |
> +			  WDIOF_MAGICCLOSE |
> +			  WDIOF_CARDRESET,
> +};
> +
> +static struct watchdog_ops sbsa_gwdt_ops = {
> +	.owner		= THIS_MODULE,
> +	.start		= sbsa_gwdt_start,
> +	.stop		= sbsa_gwdt_stop,
> +	.status		= sbsa_gwdt_status,
> +	.ping		= sbsa_gwdt_keepalive,
> +	.set_timeout	= sbsa_gwdt_set_timeout,
> +	.get_timeleft	= sbsa_gwdt_get_timeleft,
> +};
> +
> +static int sbsa_gwdt_probe(struct platform_device *pdev)
> +{
> +	void __iomem *rf_base, *cf_base;
> +	struct device *dev = &pdev->dev;
> +	struct watchdog_device *wdd;
> +	struct sbsa_gwdt *gwdt;
> +	struct resource *res;
> +	int ret, irq;
> +	u32 status;
> +
> +	gwdt = devm_kzalloc(dev, sizeof(*gwdt), GFP_KERNEL);
> +	if (!gwdt)
> +		return -ENOMEM;
> +	platform_set_drvdata(pdev, gwdt);
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	cf_base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(cf_base))
> +		return PTR_ERR(cf_base);
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +	rf_base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(rf_base))
> +		return PTR_ERR(rf_base);
> +
> +	if (action) {
> +		irq = platform_get_irq(pdev, 0);
> +		if (irq < 0) {
> +			action = 0;
> +			dev_warn(dev, "unable to get ws0 interrupt.\n");
> +		} else {
> +			if (devm_request_irq(dev, irq, sbsa_gwdt_interrupt, 0,
> +					     pdev->name, gwdt)) {
> +				action = 0;
> +				dev_warn(dev, "unable to request IRQ %d.\n",
> +					 irq);
> +			}
> +		}
> +		if (!action)
> +			dev_warn(dev, "fall back to signle stage mode.\n");
> +	}
> +
> +	/*
> +	 * Get the frequency of system counter from the cp15 interface of ARM
> +	 * Generic timer. We don't need to check it, because if it returns "0",
> +	 * system would panic in very early stage.
> +	 */
> +	gwdt->clk = arch_timer_get_cntfrq();
> +	gwdt->refresh_base = rf_base;
> +	gwdt->control_base = cf_base;
> +
> +	wdd = &gwdt->wdd;
> +	wdd->parent = dev;
> +	wdd->info = &sbsa_gwdt_info;
> +	wdd->ops = &sbsa_gwdt_ops;
> +	watchdog_set_drvdata(wdd, gwdt);
> +	watchdog_set_nowayout(wdd, nowayout);
> +
> +	wdd->min_timeout = 1;
> +	wdd->max_timeout = U32_MAX / gwdt->clk;
> +	/*
> +	 * In the single stage mode, The first signal (WS0) is ignored,
> +	 * the timeout is (WOR * 2), so the maximum timeout should be double.
> +	 */
> +	if (!action)
> +		wdd->max_timeout *= 2;
> +
> +	wdd->timeout = DEFAULT_TIMEOUT;
> +	watchdog_init_timeout(wdd, timeout, dev);
> +
> +	status = readl(gwdt->control_base + SBSA_GWDT_WCS);
> +	if (status & SBSA_GWDT_WCS_WS1) {
> +		dev_warn(dev, "System reset by WDT.\n");
> +		wdd->bootstatus |= WDIOF_CARDRESET;
> +	}
> +
> +	ret = watchdog_register_device(wdd);
> +	if (ret)
> +		return ret;
> +
> +	/*
> +	 * Update timeout to WOR.
> +	 * Because of the explicit watchdog refresh mechanism,
> +	 * it's also a ping, if watchdog is enabled.
> +	 */
> +	sbsa_gwdt_set_timeout(wdd, wdd->timeout);
> +
> +	dev_info(dev, "Initialized with %ds timeout @ %u Hz, action=%d.%s\n",
> +		 wdd->timeout, gwdt->clk, action,
> +		 status & SBSA_GWDT_WCS_EN ? " [enabled]" : "");
> +
> +	return 0;
> +}
> +
> +static void sbsa_gwdt_shutdown(struct platform_device *pdev)
> +{
> +	struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
> +
> +	sbsa_gwdt_stop(&gwdt->wdd);
> +}
> +
> +static int sbsa_gwdt_remove(struct platform_device *pdev)
> +{
> +	struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
> +
> +	watchdog_unregister_device(&gwdt->wdd);
> +
> +	return 0;
> +}
> +
> +/* Disable watchdog if it is active during suspend */
> +static int __maybe_unused sbsa_gwdt_suspend(struct device *dev)
> +{
> +	struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
> +
> +	if (watchdog_active(&gwdt->wdd))
> +		sbsa_gwdt_stop(&gwdt->wdd);
> +
> +	return 0;
> +}
> +
> +/* Enable watchdog and configure it if necessary */
> +static int __maybe_unused sbsa_gwdt_resume(struct device *dev)
> +{
> +	struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
> +
> +	if (watchdog_active(&gwdt->wdd))
> +		sbsa_gwdt_start(&gwdt->wdd);
> +
> +	return 0;
> +}
> +
> +static const struct dev_pm_ops sbsa_gwdt_pm_ops = {
> +	SET_SYSTEM_SLEEP_PM_OPS(sbsa_gwdt_suspend, sbsa_gwdt_resume)
> +};
> +
> +static const struct of_device_id sbsa_gwdt_of_match[] = {
> +	{ .compatible = "arm,sbsa-gwdt", },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, sbsa_gwdt_of_match);
> +
> +static const struct platform_device_id sbsa_gwdt_pdev_match[] = {
> +	{ .name = "sbsa-gwdt", },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(platform, sbsa_gwdt_pdev_match);
> +
> +static struct platform_driver sbsa_gwdt_driver = {
> +	.driver = {
> +		.name = "sbsa-gwdt",
> +		.pm = &sbsa_gwdt_pm_ops,
> +		.of_match_table = sbsa_gwdt_of_match,
> +	},
> +	.probe = sbsa_gwdt_probe,
> +	.remove = sbsa_gwdt_remove,
> +	.shutdown = sbsa_gwdt_shutdown,
> +	.id_table = sbsa_gwdt_pdev_match,
> +};
> +
> +module_platform_driver(sbsa_gwdt_driver);
> +
> +MODULE_DESCRIPTION("SBSA Generic Watchdog Driver");
> +MODULE_AUTHOR("Fu Wei <fu.wei at linaro.org>");
> +MODULE_AUTHOR("Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>");
> +MODULE_AUTHOR("Al Stone <al.stone at linaro.org>");
> +MODULE_AUTHOR("Timur Tabi <timur at codeaurora.org>");
> +MODULE_LICENSE("GPL v2");
>


From khalasa at piap.pl  Tue Feb 16 01:26:14 2016
From: khalasa at piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=)
Date: Tue, 16 Feb 2016 10:26:14 +0100
Subject: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
In-Reply-To: <4239208.KBB6rfivoa@wuerfel> (Arnd Bergmann's message of "Mon, 15
 Feb 2016 17:12:54 +0100")
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <2926427.2IOxhm2GZo@wuerfel> <m3y4amqdym.fsf@t19.piap.pl>
 <4239208.KBB6rfivoa@wuerfel>
Message-ID: <m3d1rxqa4p.fsf@t19.piap.pl>

Arnd Bergmann <arnd at arndb.de> writes:

> The barriers on a spinlock synchronize between CPUs but not an external
> bus, so (on some architectures) a spinlock protecting an MMIO register
> does not guarantee that two CPUs doing
>
> 	spin_lock();
> 	__raw_writel(address);
> 	__raw_writel(data);
> 	spin_unlock();
>
> would cause pairs of address/data to be seen on the bus.
>
> Of course this is meaningless on ixp4xx, as there is only one CPU.

I still don't get it. If the spinlocks synchronize between CPUs, there
can only be one CPU (or core) doing the pair of raw_writel(), so how
would it be possible to not get the address/data pair written out?
IOW, how is it different from a system with a single CPU?

> On powerpc, we have in_le32/in_be32 for SoC-internal register access,
> while only PCI devices are allowed to be accessed using readl().

Yeah, this seems like a sane solution.

> I would suggest using an ixp4xx specific set of accessors that comes down
> to either readl() or ioread32_be(), depending on whether CONFIG_CPU_BIG_ENDIAN
> is set. That makes it clear that there is a magic bus involved and that it
> works on this platform but not in portable code.

Hmm. This is actually the opposite - while there may be some magic
(swapping) in readl() and friends, there is absolutely no magic in the
__raw_readl() etc. They are essentially equivalent to
*(volatile u32 *)ptr. This is constant and doesn't depend on endianess,
PCI, anything.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland


From appana.durga.rao at xilinx.com  Tue Feb 16 01:29:06 2016
From: appana.durga.rao at xilinx.com (Kedareswara rao Appana)
Date: Tue, 16 Feb 2016 14:59:06 +0530
Subject: [PATCH] dmaengine: xilinx_vdma: Fix issues with non-parking mode
Message-ID: <1455614946-26197-1-git-send-email-appanad@xilinx.com>

This patch fixes issues with the Non-parking mode(Cirular mode).
With the  existing driver in cirular mode if we submit frames less than h/w
configured we simply end-up having misconfigured vdma h/w.
This patch fixes this issue by
----> By queing multiple descripotrs.
----> By configuring the frame count register.

Signed-off-by: Kedareswara rao Appana <appanad at xilinx.com>
---
 drivers/dma/xilinx/xilinx_vdma.c | 193 ++++++++++++++++++---------------------
 1 file changed, 91 insertions(+), 102 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 6f4b501..a73c8e1 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -190,8 +190,7 @@ struct xilinx_vdma_tx_descriptor {
  * @desc_offset: TX descriptor registers offset
  * @lock: Descriptor operation lock
  * @pending_list: Descriptors waiting
- * @active_desc: Active descriptor
- * @allocated_desc: Allocated descriptor
+ * @active_list: Descriptors ready to submit
  * @done_list: Complete descriptors
  * @common: DMA common channel
  * @desc_pool: Descriptors pool
@@ -203,9 +202,11 @@ struct xilinx_vdma_tx_descriptor {
  * @has_sg: Support scatter transfers
  * @genlock: Support genlock mode
  * @err: Channel has errors
+ * @idle: Check for channel idle
  * @tasklet: Cleanup work after irq
  * @config: Device configuration info
  * @flush_on_fsync: Flush on Frame sync
+ * @desc_pendingcount: Descriptor pending count
  */
 struct xilinx_vdma_chan {
 	struct xilinx_vdma_device *xdev;
@@ -213,8 +214,7 @@ struct xilinx_vdma_chan {
 	u32 desc_offset;
 	spinlock_t lock;
 	struct list_head pending_list;
-	struct xilinx_vdma_tx_descriptor *active_desc;
-	struct xilinx_vdma_tx_descriptor *allocated_desc;
+	struct list_head active_list;
 	struct list_head done_list;
 	struct dma_chan common;
 	struct dma_pool *desc_pool;
@@ -226,9 +226,11 @@ struct xilinx_vdma_chan {
 	bool has_sg;
 	bool genlock;
 	bool err;
+	bool idle;
 	struct tasklet_struct tasklet;
 	struct xilinx_vdma_config config;
 	bool flush_on_fsync;
+	u32 desc_pendingcount;
 };
 
 /**
@@ -342,19 +344,11 @@ static struct xilinx_vdma_tx_descriptor *
 xilinx_vdma_alloc_tx_descriptor(struct xilinx_vdma_chan *chan)
 {
 	struct xilinx_vdma_tx_descriptor *desc;
-	unsigned long flags;
-
-	if (chan->allocated_desc)
-		return chan->allocated_desc;
 
 	desc = kzalloc(sizeof(*desc), GFP_KERNEL);
 	if (!desc)
 		return NULL;
 
-	spin_lock_irqsave(&chan->lock, flags);
-	chan->allocated_desc = desc;
-	spin_unlock_irqrestore(&chan->lock, flags);
-
 	INIT_LIST_HEAD(&desc->segments);
 
 	return desc;
@@ -412,9 +406,7 @@ static void xilinx_vdma_free_descriptors(struct xilinx_vdma_chan *chan)
 
 	xilinx_vdma_free_desc_list(chan, &chan->pending_list);
 	xilinx_vdma_free_desc_list(chan, &chan->done_list);
-
-	xilinx_vdma_free_tx_descriptor(chan, chan->active_desc);
-	chan->active_desc = NULL;
+	xilinx_vdma_free_desc_list(chan, &chan->active_list);
 
 	spin_unlock_irqrestore(&chan->lock, flags);
 }
@@ -529,32 +521,6 @@ static enum dma_status xilinx_vdma_tx_status(struct dma_chan *dchan,
 }
 
 /**
- * xilinx_vdma_is_running - Check if VDMA channel is running
- * @chan: Driver specific VDMA channel
- *
- * Return: '1' if running, '0' if not.
- */
-static bool xilinx_vdma_is_running(struct xilinx_vdma_chan *chan)
-{
-	return !(vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
-		 XILINX_VDMA_DMASR_HALTED) &&
-		(vdma_ctrl_read(chan, XILINX_VDMA_REG_DMACR) &
-		 XILINX_VDMA_DMACR_RUNSTOP);
-}
-
-/**
- * xilinx_vdma_is_idle - Check if VDMA channel is idle
- * @chan: Driver specific VDMA channel
- *
- * Return: '1' if idle, '0' if not.
- */
-static bool xilinx_vdma_is_idle(struct xilinx_vdma_chan *chan)
-{
-	return vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
-		XILINX_VDMA_DMASR_IDLE;
-}
-
-/**
  * xilinx_vdma_halt - Halt VDMA channel
  * @chan: Driver specific VDMA channel
  */
@@ -614,45 +580,34 @@ static void xilinx_vdma_start(struct xilinx_vdma_chan *chan)
 static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 {
 	struct xilinx_vdma_config *config = &chan->config;
-	struct xilinx_vdma_tx_descriptor *desc;
-	unsigned long flags;
+	struct xilinx_vdma_tx_descriptor *desc, *tail_desc;
 	u32 reg;
-	struct xilinx_vdma_tx_segment *head, *tail = NULL;
+	struct xilinx_vdma_tx_segment *tail_segment;
 
 	if (chan->err)
 		return;
 
-	spin_lock_irqsave(&chan->lock, flags);
-
-	/* There's already an active descriptor, bail out. */
-	if (chan->active_desc)
-		goto out_unlock;
-
 	if (list_empty(&chan->pending_list))
-		goto out_unlock;
+		return;
+
+	if (!chan->idle)
+		return;
 
 	desc = list_first_entry(&chan->pending_list,
 				struct xilinx_vdma_tx_descriptor, node);
+	tail_desc = list_last_entry(&chan->pending_list,
+				    struct xilinx_vdma_tx_descriptor, node);
 
-	/* If it is SG mode and hardware is busy, cannot submit */
-	if (chan->has_sg && xilinx_vdma_is_running(chan) &&
-	    !xilinx_vdma_is_idle(chan)) {
-		dev_dbg(chan->dev, "DMA controller still busy\n");
-		goto out_unlock;
-	}
+	tail_segment = list_last_entry(&tail_desc->segments,
+				       struct xilinx_vdma_tx_segment, node);
 
 	/*
 	 * If hardware is idle, then all descriptors on the running lists are
 	 * done, start new transfers
 	 */
-	if (chan->has_sg) {
-		head = list_first_entry(&desc->segments,
-					struct xilinx_vdma_tx_segment, node);
-		tail = list_entry(desc->segments.prev,
-				  struct xilinx_vdma_tx_segment, node);
-
-		vdma_ctrl_write(chan, XILINX_VDMA_REG_CURDESC, head->phys);
-	}
+	if (chan->has_sg)
+		vdma_ctrl_write(chan, XILINX_VDMA_REG_CURDESC,
+				desc->async_tx.phys);
 
 	/* Configure the hardware using info in the config structure */
 	reg = vdma_ctrl_read(chan, XILINX_VDMA_REG_DMACR);
@@ -662,6 +617,9 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 	else
 		reg &= ~XILINX_VDMA_DMACR_FRAMECNT_EN;
 
+	vdma_ctrl_write(chan, XILINX_VDMA_REG_FRMSTORE,
+			chan->desc_pendingcount);
+
 	/*
 	 * With SG, start with circular mode, so that BDs can be fetched.
 	 * In direct register mode, if not parking, enable circular mode
@@ -690,16 +648,19 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 	xilinx_vdma_start(chan);
 
 	if (chan->err)
-		goto out_unlock;
+		return;
 
 	/* Start the transfer */
 	if (chan->has_sg) {
-		vdma_ctrl_write(chan, XILINX_VDMA_REG_TAILDESC, tail->phys);
+		vdma_ctrl_write(chan, XILINX_VDMA_REG_TAILDESC,
+				tail_segment->phys);
 	} else {
 		struct xilinx_vdma_tx_segment *segment, *last = NULL;
 		int i = 0;
 
-		list_for_each_entry(segment, &desc->segments, node) {
+		list_for_each_entry(desc, &chan->pending_list, node) {
+			segment = list_first_entry(&desc->segments,
+					   struct xilinx_vdma_tx_segment, node);
 			vdma_desc_write(chan,
 					XILINX_VDMA_REG_START_ADDRESS(i++),
 					segment->hw.buf_addr);
@@ -707,7 +668,7 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 		}
 
 		if (!last)
-			goto out_unlock;
+			return;
 
 		/* HW expects these parameters to be same for one transaction */
 		vdma_desc_write(chan, XILINX_VDMA_REG_HSIZE, last->hw.hsize);
@@ -716,11 +677,9 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 		vdma_desc_write(chan, XILINX_VDMA_REG_VSIZE, last->hw.vsize);
 	}
 
-	list_del(&desc->node);
-	chan->active_desc = desc;
-
-out_unlock:
-	spin_unlock_irqrestore(&chan->lock, flags);
+	list_splice_tail_init(&chan->pending_list, &chan->active_list);
+	chan->desc_pendingcount = 0;
+	chan->idle = false;
 }
 
 /**
@@ -730,8 +689,11 @@ out_unlock:
 static void xilinx_vdma_issue_pending(struct dma_chan *dchan)
 {
 	struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
+	unsigned long flags;
 
+	spin_lock_irqsave(&chan->lock, flags);
 	xilinx_vdma_start_transfer(chan);
+	spin_unlock_irqrestore(&chan->lock, flags);
 }
 
 /**
@@ -742,24 +704,16 @@ static void xilinx_vdma_issue_pending(struct dma_chan *dchan)
  */
 static void xilinx_vdma_complete_descriptor(struct xilinx_vdma_chan *chan)
 {
-	struct xilinx_vdma_tx_descriptor *desc;
-	unsigned long flags;
+	struct xilinx_vdma_tx_descriptor *desc, *next;
 
-	spin_lock_irqsave(&chan->lock, flags);
+	if (list_empty(&chan->active_list))
+		return;
 
-	desc = chan->active_desc;
-	if (!desc) {
-		dev_dbg(chan->dev, "no running descriptors\n");
-		goto out_unlock;
+	list_for_each_entry_safe(desc, next, &chan->active_list, node) {
+		list_del(&desc->node);
+		dma_cookie_complete(&desc->async_tx);
+		list_add_tail(&desc->node, &chan->done_list);
 	}
-
-	dma_cookie_complete(&desc->async_tx);
-	list_add_tail(&desc->node, &chan->done_list);
-
-	chan->active_desc = NULL;
-
-out_unlock:
-	spin_unlock_irqrestore(&chan->lock, flags);
 }
 
 /**
@@ -870,8 +824,11 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq, void *data)
 	}
 
 	if (status & XILINX_VDMA_DMASR_FRM_CNT_IRQ) {
+		spin_lock(&chan->lock);
 		xilinx_vdma_complete_descriptor(chan);
+		chan->idle = true;
 		xilinx_vdma_start_transfer(chan);
+		spin_unlock(&chan->lock);
 	}
 
 	tasklet_schedule(&chan->tasklet);
@@ -879,6 +836,45 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq, void *data)
 }
 
 /**
+ * append_desc_queue - Queuing descriptor
+ * @chan: Driver specific dma channel
+ * @desc: dma transaction descriptor
+ */
+static void append_desc_queue(struct xilinx_vdma_chan *chan,
+			      struct xilinx_vdma_tx_descriptor *desc)
+{
+	struct xilinx_vdma_tx_segment *tail_segment;
+	struct xilinx_vdma_tx_descriptor *tail_desc;
+
+	if (list_empty(&chan->pending_list))
+		goto append;
+
+	/*
+	 * Add the hardware descriptor to the chain of hardware descriptors
+	 * that already exists in memory.
+	 */
+	tail_desc = list_last_entry(&chan->pending_list,
+				    struct xilinx_vdma_tx_descriptor, node);
+	tail_segment = list_last_entry(&tail_desc->segments,
+				       struct xilinx_vdma_tx_segment, node);
+	tail_segment->hw.next_desc = (u32)desc->async_tx.phys;
+
+	/*
+	 * Add the software descriptor and all children to the list
+	 * of pending transactions
+	 */
+append:
+	list_add_tail(&desc->node, &chan->pending_list);
+	chan->desc_pendingcount++;
+
+	if (unlikely(chan->desc_pendingcount > chan->num_frms)) {
+		dev_dbg(chan->dev, "desc pendingcount is too high\n");
+		chan->desc_pendingcount = chan->num_frms;
+		BUG();
+	}
+}
+
+/**
  * xilinx_vdma_tx_submit - Submit DMA transaction
  * @tx: Async transaction descriptor
  *
@@ -906,11 +902,8 @@ static dma_cookie_t xilinx_vdma_tx_submit(struct dma_async_tx_descriptor *tx)
 
 	cookie = dma_cookie_assign(tx);
 
-	/* Append the transaction to the pending transactions queue. */
-	list_add_tail(&desc->node, &chan->pending_list);
-
-	/* Free the allocated desc */
-	chan->allocated_desc = NULL;
+	/* Put this transaction onto the tail of the pending queue */
+	append_desc_queue(chan, desc);
 
 	spin_unlock_irqrestore(&chan->lock, flags);
 
@@ -973,13 +966,6 @@ xilinx_vdma_dma_prep_interleaved(struct dma_chan *dchan,
 	else
 		hw->buf_addr = xt->src_start;
 
-	/* Link the previous next descriptor to current */
-	if (!list_empty(&desc->segments)) {
-		prev = list_last_entry(&desc->segments,
-				       struct xilinx_vdma_tx_segment, node);
-		prev->hw.next_desc = segment->phys;
-	}
-
 	/* Insert the segment into the descriptor segments list. */
 	list_add_tail(&segment->node, &desc->segments);
 
@@ -988,7 +974,7 @@ xilinx_vdma_dma_prep_interleaved(struct dma_chan *dchan,
 	/* Link the last hardware descriptor with the first. */
 	segment = list_first_entry(&desc->segments,
 				   struct xilinx_vdma_tx_segment, node);
-	prev->hw.next_desc = segment->phys;
+	desc->async_tx.phys = segment->phys;
 
 	return &desc->async_tx;
 
@@ -1127,10 +1113,12 @@ static int xilinx_vdma_chan_probe(struct xilinx_vdma_device *xdev,
 	chan->dev = xdev->dev;
 	chan->xdev = xdev;
 	chan->has_sg = xdev->has_sg;
+	chan->desc_pendingcount = 0x0;
 
 	spin_lock_init(&chan->lock);
 	INIT_LIST_HEAD(&chan->pending_list);
 	INIT_LIST_HEAD(&chan->done_list);
+	INIT_LIST_HEAD(&chan->active_list);
 
 	/* Retrieve the channel properties from the device tree */
 	has_dre = of_property_read_bool(node, "xlnx,include-dre");
@@ -1198,6 +1186,7 @@ static int xilinx_vdma_chan_probe(struct xilinx_vdma_device *xdev,
 
 	list_add_tail(&chan->common.device_node, &xdev->common.channels);
 	xdev->chan[chan->id] = chan;
+	chan->idle = true;
 
 	/* Reset the channel */
 	err = xilinx_vdma_chan_reset(chan);
-- 
2.1.2



From khalasa at piap.pl  Tue Feb 16 01:32:17 2016
From: khalasa at piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=)
Date: Tue, 16 Feb 2016 10:32:17 +0100
Subject: [PATCH v2 01/15] arm: use of_platform_default_populate() to
 populate default bus
In-Reply-To: <1453881180-12296-1-git-send-email-wangkefeng.wang@huawei.com>
 (Kefeng Wang's message of "Wed, 27 Jan 2016 15:53:00 +0800")
References: <1453868872-26300-2-git-send-email-wangkefeng.wang@huawei.com>
 <1453881180-12296-1-git-send-email-wangkefeng.wang@huawei.com>
Message-ID: <m38u2lq9um.fsf@t19.piap.pl>

Kefeng Wang <wangkefeng.wang at huawei.com> writes:

> Use helper of_platform_default_populate() in linux/of_platform
> when possible, instead of calling of_platform_populate() with
> the default match table.
> --- a/arch/arm/mach-cns3xxx/core.c
> +++ b/arch/arm/mach-cns3xxx/core.c
> @@ -395,8 +395,7 @@ static void __init cns3xxx_init(void)
>  
>  	pm_power_off = cns3xxx_power_off;
>  
> -	of_platform_populate(NULL, of_default_bus_match_table,
> -                        cns3xxx_auxdata, NULL);
> +	of_platform_default_populate(NULL, cns3xxx_auxdata, NULL);
>  }
>  

Doesn't look wrong :-)

Acked-by: Krzysztof Halasa <khalasa at piap.pl>

-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland


From maxime.ripard at free-electrons.com  Tue Feb 16 01:33:45 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 16 Feb 2016 10:33:45 +0100
Subject: Allwinner A64 MMC support
In-Reply-To: <56C1D9C0.6020601@arm.com>
References: <1455300000-18723-1-git-send-email-andre.przywara@arm.com>
 <56BE29A1.3060107@redhat.com> <56C1A590.6030500@arm.com>
 <56C1C7BB.1040602@redhat.com> <56C1D9C0.6020601@arm.com>
Message-ID: <20160216093345.GJ4344@lukather>

Hi Andre,

On Mon, Feb 15, 2016 at 01:59:28PM +0000, Andre Przywara wrote:
> 2) The reset node is a allwinner,sun6i-a31-ahb1-reset, which does not
> get registered automatically, but by an explicit call from mach-sunxi/.
> I wonder why we do this (yes, I saw that comment, but still...) and if
> it would work with a normal MODULE_DEVICE_TABLE() declaration.

Because we need to access the reset controller at the time the timer
is probed, which is way before the device model is initilized, and the
"real" reset controller driver is probed.

I'm not really fond of the solution either, but there's no other
solution, if we set aside "rework the driver / device model so that it
initializes properly".

> There is and will be no equivalent to the mach- directory on arm64.

Then you cannot use the HS timer.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/ed962901/attachment-0001.sig>

From andrew-ct.chen at mediatek.com  Tue Feb 16 01:36:14 2016
From: andrew-ct.chen at mediatek.com (andrew-ct chen)
Date: Tue, 16 Feb 2016 17:36:14 +0800
Subject: [PATCH v4 2/8] [media] VPU: mediatek: support Mediatek VPU
In-Reply-To: <CAOMLVLg_zxkFtAdiTdR=8VD=OnSF0KdD4=U0x_KHrTN9x7WHJw@mail.gmail.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <CAOMLVLg_zxkFtAdiTdR=8VD=OnSF0KdD4=U0x_KHrTN9x7WHJw@mail.gmail.com>
Message-ID: <1455615374.26429.30.camel@mtksdaap41>

On Mon, 2016-02-15 at 21:59 +0800, Wu-Cheng Li (???) wrote:
> On Thu, Feb 4, 2016 at 7:34 PM, Tiffany Lin <tiffany.lin at mediatek.com> wrote:
> > The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
> > It is able to handle video decoding/encoding of in a range of formats.
> > The driver provides with VPU firmware download, memory management and
> > the communication interface between CPU and VPU.
> > For VPU initialization, it will create virtual memory for CPU access and
> > IOMMU address for vcodec hw device access. When a decode/encode instance
> > opens a device node, vpu driver will download vpu firmware to the device.
> > A decode/encode instant will decode/encode a frame using VPU
> > interface to interrupt vpu to handle decoding/encoding jobs.
> >
> > Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
> > Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
> > ---
> >  drivers/media/platform/Kconfig           |    9 +
> >  drivers/media/platform/Makefile          |    2 +
> >  drivers/media/platform/mtk-vpu/Makefile  |    1 +
> >  drivers/media/platform/mtk-vpu/mtk_vpu.c |  994 ++++++++++++++++++++++++++++++
> >  drivers/media/platform/mtk-vpu/mtk_vpu.h |  167 +++++
> >  5 files changed, 1173 insertions(+)
> >  create mode 100644 drivers/media/platform/mtk-vpu/Makefile
> >  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c
> >  create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h
> >
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index ccbc974..ba812d6 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -148,6 +148,15 @@ config VIDEO_CODA
> >            Coda is a range of video codec IPs that supports
> >            H.264, MPEG-4, and other video formats.
> >
> > +config VIDEO_MEDIATEK_VPU
> > +       tristate "Mediatek Video Processor Unit"
> > +       depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MEDIATEK
> > +       ---help---
> > +           This driver provides downloading VPU firmware and
> > +           communicating with VPU. This driver for hw video
> > +           codec embedded in new Mediatek's SOCs. It is able
> > +           to handle video decoding/encoding in a range of formats.
> > +
> >  config VIDEO_MEM2MEM_DEINTERLACE
> >         tristate "Deinterlace support"
> >         depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
> > diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> > index efa0295..e5b19c6 100644
> > --- a/drivers/media/platform/Makefile
> > +++ b/drivers/media/platform/Makefile
> > @@ -55,3 +55,5 @@ obj-$(CONFIG_VIDEO_AM437X_VPFE)               += am437x/
> >  obj-$(CONFIG_VIDEO_XILINX)             += xilinx/
> >
> >  ccflags-y += -I$(srctree)/drivers/media/i2c
> > +
> > +obj-$(CONFIG_VIDEO_MEDIATEK_VPU)       += mtk-vpu/
> > diff --git a/drivers/media/platform/mtk-vpu/Makefile b/drivers/media/platform/mtk-vpu/Makefile
> > new file mode 100644
> > index 0000000..d890a66
> > --- /dev/null
> > +++ b/drivers/media/platform/mtk-vpu/Makefile
> > @@ -0,0 +1 @@
> > +obj-y += mtk_vpu.o
> > diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> > new file mode 100644
> > index 0000000..f54fd89
> > --- /dev/null
> > +++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> > @@ -0,0 +1,994 @@
> > +/*
> > +* Copyright (c) 2015 MediaTek Inc.
> > +* Author: Andrew-CT Chen <andrew-ct.chen at mediatek.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.
> > +*/
> > +#include <linux/bootmem.h>
> > +#include <linux/clk.h>
> > +#include <linux/debugfs.h>
> > +#include <linux/firmware.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/iommu.h>
> > +#include <linux/module.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/of_reserved_mem.h>
> > +#include <linux/sched.h>
> > +#include <linux/sizes.h>
> > +
> > +#include "mtk_vpu.h"
> > +
> > +/**
> > + * VPU (video processor unit) is a tiny processor controlling video hardware
> > + * related to video codec, scaling and color format converting.
> > + * VPU interfaces with other blocks by share memory and interrupt.
> > + **/
> > +
> > +#define INIT_TIMEOUT_MS                2000U
> > +#define IPI_TIMEOUT_MS         2000U
> > +#define VPU_FW_VER_LEN         16
> > +
> > +/* maximum program/data TCM (Tightly-Coupled Memory) size */
> > +#define VPU_PTCM_SIZE          (96 * SZ_1K)
> > +#define VPU_DTCM_SIZE          (32 * SZ_1K)
> > +/* the offset to get data tcm address */
> > +#define VPU_DTCM_OFFSET                0x18000UL
> > +/* daynamic allocated maximum extended memory size */
> > +#define VPU_EXT_P_SIZE         SZ_1M
> > +#define VPU_EXT_D_SIZE         SZ_4M
> > +/* maximum binary firmware size */
> > +#define VPU_P_FW_SIZE          (VPU_PTCM_SIZE + VPU_EXT_P_SIZE)
> > +#define VPU_D_FW_SIZE          (VPU_DTCM_SIZE + VPU_EXT_D_SIZE)
> > +/* the size of share buffer between Host and  VPU */
> > +#define SHARE_BUF_SIZE         48
> > +
> > +/* binary firmware name */
> > +#define VPU_P_FW               "vpu_p.bin"
> > +#define VPU_D_FW               "vpu_d.bin"
> > +
> > +#define VPU_RESET              0x0
> > +#define VPU_TCM_CFG            0x0008
> > +#define VPU_PMEM_EXT0_ADDR     0x000C
> > +#define VPU_PMEM_EXT1_ADDR     0x0010
> > +#define VPU_TO_HOST            0x001C
> > +#define VPU_DMEM_EXT0_ADDR     0x0014
> > +#define VPU_DMEM_EXT1_ADDR     0x0018
> > +#define HOST_TO_VPU            0x0024
> > +#define VPU_PC_REG             0x0060
> > +#define VPU_WDT_REG            0x0084
> > +
> > +/* vpu inter-processor communication interrupt */
> > +#define VPU_IPC_INT            BIT(8)
> > +
> > +/**
> > + * enum vpu_fw_type - VPU firmware type
> > + *
> > + * @P_FW: program firmware
> > + * @D_FW: data firmware
> > + *
> > + */
> > +enum vpu_fw_type {
> > +       P_FW,
> > +       D_FW,
> > +};
> > +
> > +/**
> > + * struct vpu_mem - VPU extended program/data memory information
> > + *
> > + * @va:                the kernel virtual memory address of VPU extended memory
> > + * @pa:                the physical memory address of VPU extended memory
> This should be device memory address? If yes, s/physical/device/ and
> s/pa/dma_addr/.

It's really a physical memory since vpu is not attached to IOMMU.It
should be s/dma_addr_t/phys_addr_t for the data type.Thanks.

> > + *
> > + */
> > +struct vpu_mem {
> > +       void *va;
> > +       dma_addr_t pa;
> > +};
> > +
> > +/**
> > + * struct vpu_regs - VPU TCM and configuration registers
> > + *
> > + * @tcm:       the register for VPU Tightly-Coupled Memory
> > + * @cfg:       the register for VPU configuration
> > + * @irq:       the irq number for VPU interrupt
> > + */
> > +struct vpu_regs {
> > +       void __iomem *tcm;
> > +       void __iomem *cfg;
> > +       int irq;
> > +};
> > +
> > +/**
> > + * struct vpu_wdt_handler - VPU watchdog reset handler
> > + *
> > + * @reset_func:        reset handler
> > + * @priv:      private data
> > + */
> > +struct vpu_wdt_handler {
> > +       void (*reset_func)(void *);
> > +       void *priv;
> > +};
> > +
> > +/**
> > + * struct vpu_wdt - VPU watchdog workqueue
> > + *
> > + * @handler:   VPU watchdog reset handler
> > + * @ws:                workstruct for VPU watchdog
> > + * @wq:                workqueue for VPU watchdog
> > + */
> > +struct vpu_wdt {
> > +       struct vpu_wdt_handler handler[VPU_RST_MAX];
> > +       struct work_struct ws;
> > +       struct workqueue_struct *wq;
> > +};
> > +
> > +/**
> > + * struct vpu_run - VPU initialization status
> > + *
> > + * @signaled:          the signal of vpu initialization completed
> > + * @fw_ver:            VPU firmware version
> > + * @enc_capability:    encoder capability
> We should document the meaning of the bit used. Since no bit is used
> by the codec driver, document this is not used for now and the value
> is reserved for future use.

This is not used for now. I will document this in next version. Thanks.

> > + * @wq:                        wait queue for VPU initialization status
> > + */
> > +struct vpu_run {
> > +       u32 signaled;
> > +       char fw_ver[VPU_FW_VER_LEN];
> > +       unsigned int    enc_capability;
> > +       wait_queue_head_t wq;
> > +};
> > +
> > +/**
> > + * struct vpu_ipi_desc - VPU IPI descriptor
> > + *
> > + * @handler:   IPI handler
> > + * @name:      the name of IPI handler
> > + * @priv:      the private data of IPI handler
> > + */
> > +struct vpu_ipi_desc {
> > +       ipi_handler_t handler;
> > +       const char *name;
> > +       void *priv;
> > +};
> > +
> > +/**
> > + * struct share_obj - DTCM (Data Tightly-Coupled Memory) buffer shared with
> > + *                   AP and VPU
> > + *
> > + * @id:                IPI id
> > + * @len:       share buffer length
> > + * @share_buf: share buffer data
> > + */
> > +struct share_obj {
> > +       s32 id;
> > +       u32 len;
> > +       unsigned char share_buf[SHARE_BUF_SIZE];
> > +};
> > +
> > +/**
> > + * struct mtk_vpu - vpu driver data
> > + * @extmem:            VPU extended memory information
> > + * @reg:               VPU TCM and configuration registers
> > + * @run:               VPU initialization status
> > + * @ipi_desc:          VPU IPI descriptor
> > + * @recv_buf:          VPU DTCM share buffer for receiving. The
> > + *                     receive buffer is only accessed in interrupt context.
> > + * @send_buf:          VPU DTCM share buffer for sending
> > + * @dev:               VPU struct device
> > + * @clk:               VPU clock on/off
> > + * @enable_4GB:                VPU 4GB mode on/off
> > + * @vpu_mutex:         protect mtk_vpu (except recv_buf) and ensure only
> > + *                     one client to use VPU service at a time. For example,
> > + *                     suppose a client is using VPU to decode VP8.
> > + *                     If the other client wants to encode VP8,
> > + *                     it has to wait until VP8 decode completes.
> > + * @wdt_refcnt         WDT reference count to make sure the watchdog can be
> > + *                     disabled if no other client is using VPU service
> > + * @ipi_ack_signaled:  The ACKs for registered IPI function sending
> > + *                     interrupt to VPU
> s/ipi_ack_signaled/ipi_id_ack/. Move to after |ack_wq| to be
> consistent with the order of variable declaration.

I will change this in next version. Thanks.

> > + * @ack_wq:            The wait queue for each codec and mdp. When sleeping
> > + *                     processes wake up, they will check the condition
> > + *                     "ipi_ack_signaled" to run the corresponding action or
> > + *                     go back to sleep.
> > + *
> > + */
> > +struct mtk_vpu {
> > +       struct vpu_mem extmem[2];
> > +       struct vpu_regs reg;
> > +       struct vpu_run run;
> > +       struct vpu_wdt wdt;
> > +       struct vpu_ipi_desc ipi_desc[IPI_MAX];
> > +       struct share_obj *recv_buf;
> > +       struct share_obj *send_buf;
> > +       struct device *dev;
> > +       struct clk *clk;
> > +       bool enable_4GB;
> > +       struct mutex vpu_mutex; /* for protecting vpu data data structure */
> Remove the comment here. It should be documented in function comment above

It will get message "CHECK" from checkpatch script if removing this
comment.

> .
> > +       atomic_t wdt_refcnt;
> > +       wait_queue_head_t ack_wq;
> > +       bool ipi_id_ack[IPI_MAX];
> > +};
> > +
> > +static inline void vpu_cfg_writel(struct mtk_vpu *vpu, u32 val, u32 offset)
> > +{
> > +       writel(val, vpu->reg.cfg + offset);
> > +}
> > +
> > +static inline u32 vpu_cfg_readl(struct mtk_vpu *vpu, u32 offset)
> > +{
> > +       return readl(vpu->reg.cfg + offset);
> > +}
> > +
> > +static inline bool vpu_running(struct mtk_vpu *vpu)
> > +{
> > +       return vpu_cfg_readl(vpu, VPU_RESET) & BIT(0);
> > +}
> > +
> > +void vpu_clock_disable(struct mtk_vpu *vpu)
> > +{
> > +       /* Disable VPU watchdog */
> > +       if (atomic_dec_and_test(&vpu->wdt_refcnt))
> Checking wdt_refcnt and doing vpu_cfg_writel should be done
> atomically. For example, if vpu_clock_enable is called after
> atomic_dec_and_test(&vpu->wdt_refcnt) and before vpu_cfg_writel(...),
> the state of watchdog could be wrong. Adding a spinlock to protect
> wdt_refcnt and vpu_cfg_writel together. Then wdt_refcnt doesn't need
> to be atomic_t.

I would use mutex to protect this since this only be called in process
context. I will change this in next version. Thanks.

> > +               vpu_cfg_writel(vpu,
> > +                              vpu_cfg_readl(vpu, VPU_WDT_REG) & ~(1L << 31),
> > +                              VPU_WDT_REG);
> > +
> > +       clk_disable(vpu->clk);
> > +}
> > +
> > +int vpu_clock_enable(struct mtk_vpu *vpu)
> > +{
> > +       int ret;
> > +
> > +       ret = clk_enable(vpu->clk);
> > +       if (ret)
> > +               return ret;
> > +       /* Enable VPU watchdog */
> > +       if (!atomic_read(&vpu->wdt_refcnt))
> Do we need to enable the watchdog other than vpu_ipi_send? The only
> place that AP waits for VPU is in vpu_ipi_send. Right? If yes, can we
> just enable and disable the watchdog in vpu_ipi_send?

Watchdog also should be enabled during driver initialization and
firmware download.

> > +               vpu_cfg_writel(vpu,
> > +                              vpu_cfg_readl(vpu, VPU_WDT_REG) | (1L << 31),
> > +                              VPU_WDT_REG);
> > +
> > +       atomic_inc(&vpu->wdt_refcnt);
> Same above. atomic_read, vpu_cfg_writel, and atomic_inc should be done
> atomically.

I will change this in next version. Thanks.

> > +
> > +       return ret;
> > +}
> > +
> > +int vpu_ipi_register(struct platform_device *pdev,
> > +                    enum ipi_id id, ipi_handler_t handler,
> > +                    const char *name, void *priv)
> > +{
> > +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> > +       struct vpu_ipi_desc *ipi_desc;
> > +
> > +       if (!vpu) {
> > +               dev_err(&pdev->dev, "vpu device in not ready\n");
> > +               return -EPROBE_DEFER;
> > +       }
> > +
> > +       if (id < IPI_MAX && handler) {
> Check if id >= 0 because type of enum is implementation dependent.

I will change this in next version. Thanks.

> > +               ipi_desc = vpu->ipi_desc;
> > +               ipi_desc[id].name = name;
> > +               ipi_desc[id].handler = handler;
> > +               ipi_desc[id].priv = priv;
> > +               return 0;
> > +       }
> > +
> > +       dev_err(&pdev->dev, "register vpu ipi with invalid arguments\n");
> print id

I will change this in next version. Thanks.

> > +       return -EINVAL;
> > +}
> > +
> > +int vpu_ipi_send(struct platform_device *pdev,
> > +                enum ipi_id id, void *buf,
> > +                unsigned int len)
> > +{
> > +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> > +       struct share_obj *send_obj = vpu->send_buf;
> > +       unsigned long timeout;
> > +       int ret = 0;
> > +
> > +       if (id <= IPI_VPU_INIT || id >= IPI_MAX ||
> > +           len > sizeof(send_obj->share_buf) || !buf) {
> > +               dev_err(vpu->dev, "failed to send ipi message\n");
> > +               return -EINVAL;
> > +       }
> > +
> > +       ret = vpu_clock_enable(vpu);
> > +       if (ret) {
> > +               dev_err(vpu->dev, "failed to enable vpu clock\n");
> > +               return ret;
> > +       }
> > +       if (!vpu_running(vpu)) {
> > +               dev_err(vpu->dev, "vpu_ipi_send: VPU is not running\n");
> > +               ret = -EINVAL;
> > +               goto clock_disable;
> > +       }
> > +
> > +       mutex_lock(&vpu->vpu_mutex);
> > +
> > +        /* Wait until VPU receives the last command */
> > +       timeout = jiffies + msecs_to_jiffies(IPI_TIMEOUT_MS);
> > +       do {
> > +               if (time_after(jiffies, timeout)) {
> > +                       dev_err(vpu->dev, "vpu_ipi_send: IPI timeout!\n");
> > +                       ret = -EIO;
> > +                       goto mut_unlock;
> > +               }
> > +       } while (vpu_cfg_readl(vpu, HOST_TO_VPU));
> > +
> > +       memcpy((void *)send_obj->share_buf, buf, len);
> > +       send_obj->len = len;
> > +       send_obj->id = id;
> > +
> > +       vpu->ipi_id_ack[id] = false;
> > +       /* send the command to VPU */
> > +       vpu_cfg_writel(vpu, 0x1, HOST_TO_VPU);
> > +
> > +       mutex_unlock(&vpu->vpu_mutex);
> > +
> > +       /* wait for VPU's ACK */
> > +       timeout = msecs_to_jiffies(IPI_TIMEOUT_MS);
> > +       ret = wait_event_interruptible_timeout(vpu->ack_wq,
> > +                                              vpu->ipi_id_ack[id], timeout);
> > +       vpu->ipi_id_ack[id] = false;
> > +       if (ret == 0) {
> > +               dev_err(vpu->dev, "vpu ipi %d ack time out !", id);
> > +               ret = -EIO;
> > +               goto clock_disable;
> > +       } else if (-ERESTARTSYS == ret) {
> > +               dev_err(vpu->dev, "vpu ipi %d ack wait interrupted by a signal",
> > +                       id);
> > +               ret = -ERESTARTSYS;
> > +               goto clock_disable;
> > +       }
> > +       vpu_clock_disable(vpu);
> > +
> > +       return 0;
> > +
> > +mut_unlock:
> > +       vpu->ipi_id_ack[id] = false;
> I don't see why we need to set it to false here. Remove if not needed.
I will remove this in next version. Thanks.
> > +       mutex_unlock(&vpu->vpu_mutex);
> > +clock_disable:
> > +       vpu_clock_disable(vpu);
> > +
> > +       return ret;
> > +}
> > +
> > +static void vpu_wdt_reset_func(struct work_struct *ws)
> > +{
> > +       struct vpu_wdt *wdt = container_of(ws, struct vpu_wdt, ws);
> > +       struct mtk_vpu *vpu = container_of(wdt, struct mtk_vpu, wdt);
> > +       struct vpu_wdt_handler *handler = wdt->handler;
> > +       int index, ret;
> > +
> > +       dev_info(vpu->dev, "vpu reset\n");
> > +       mutex_lock(&vpu->vpu_mutex);
> > +       ret = vpu_clock_enable(vpu);
> > +       if (ret) {
> This is missing mutex_unlock. Move mutex_lock right before
> vpu_cfg_writel(vpu, 0x0, VPU_RESET);. So we don't need to unlock when
> vpu_clock_enable fails.

I will change this in next version. Thanks.

> > +               dev_err(vpu->dev, "[VPU] wdt enables clock failed %d\n", ret);
> > +               return;
> > +       }
> > +       vpu_cfg_writel(vpu, 0x0, VPU_RESET);
> > +       vpu_clock_disable(vpu);
> > +       mutex_unlock(&vpu->vpu_mutex);
> > +
> > +       for (index = 0; index < VPU_RST_MAX; index++) {
> > +               if (handler[index].reset_func) {
> > +                       handler[index].reset_func(handler[index].priv);
> > +                       dev_dbg(vpu->dev, "wdt handler func %d\n", index);
> > +               }
> > +       }
> > +}
> > +
> > +int vpu_wdt_reg_handler(struct platform_device *pdev,
> > +                       void wdt_reset(void *),
> > +                       void *priv, enum rst_id id)
> > +{
> > +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> > +       struct vpu_wdt_handler *handler = vpu->wdt.handler;
> > +
> > +       if (!vpu) {
> > +               dev_err(vpu->dev, "vpu device in not ready\n");
> > +               return -EPROBE_DEFER;
> > +       }
> > +
> > +       if (id < VPU_RST_MAX && wdt_reset != NULL) {
> Check id >= 0

I will change this in next version. Thanks.

> > +               dev_dbg(vpu->dev, "wdt register id %d\n", id);
> > +               mutex_lock(&vpu->vpu_mutex);
> > +               handler[id].reset_func = wdt_reset;
> > +               handler[id].priv = priv;
> > +               mutex_unlock(&vpu->vpu_mutex);
> > +               return 0;
> > +       }
> > +
> > +       dev_err(vpu->dev, "register vpu wdt handler failed\n");
> > +       return -EINVAL;
> > +}
> > +
> > +unsigned int vpu_get_venc_hw_capa(struct platform_device *pdev)
> > +{
> > +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> > +
> > +       return vpu->run.enc_capability;
> > +}
> > +
> > +void *vpu_mapping_dm_addr(struct platform_device *pdev,
> > +                         u32 dtcm_dmem_addr)
> > +{
> > +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> > +
> > +       if (!dtcm_dmem_addr ||
> > +           (dtcm_dmem_addr > (VPU_DTCM_SIZE + VPU_EXT_D_SIZE))) {
> > +               dev_err(vpu->dev, "invalid virtual data memory address\n");
> > +               return ERR_PTR(-EINVAL);
> > +       }
> > +
> > +       if (dtcm_dmem_addr < VPU_DTCM_SIZE)
> > +               return dtcm_dmem_addr + vpu->reg.tcm + VPU_DTCM_OFFSET;
> > +
> > +       return vpu->extmem[D_FW].va + (dtcm_dmem_addr - VPU_DTCM_SIZE);
> > +}
> > +
> > +struct platform_device *vpu_get_plat_device(struct platform_device *pdev)
> > +{
> > +       struct device *dev = &pdev->dev;
> > +       struct device_node *vpu_node;
> > +       struct platform_device *vpu_pdev;
> > +
> > +       vpu_node = of_parse_phandle(dev->of_node, "mediatek,vpu", 0);
> > +       if (!vpu_node) {
> > +               dev_err(dev, "can't get vpu node\n");
> > +               return NULL;
> > +       }
> > +
> > +       vpu_pdev = of_find_device_by_node(vpu_node);
> > +       if (WARN_ON(!vpu_pdev)) {
> > +               dev_err(dev, "vpu pdev failed\n");
> > +               of_node_put(vpu_node);
> > +               return NULL;
> > +       }
> > +
> > +       return vpu_pdev;
> > +}
> > +
> > +/* load vpu program/data memory */
> > +static int load_requested_vpu(struct mtk_vpu *vpu,
> > +                             const struct firmware *vpu_fw,
> > +                             u8 fw_type)
> > +{
> > +       size_t tcm_size = fw_type ? VPU_DTCM_SIZE : VPU_PTCM_SIZE;
> > +       size_t fw_size = fw_type ? VPU_D_FW_SIZE : VPU_P_FW_SIZE;
> > +       char *fw_name = fw_type ? VPU_D_FW : VPU_P_FW;
> > +       size_t dl_size = 0;
> > +       size_t extra_fw_size = 0;
> > +       void *dest;
> > +       int ret;
> > +
> > +       ret = request_firmware(&vpu_fw, fw_name, vpu->dev);
> > +       if (ret < 0) {
> > +               dev_err(vpu->dev, "Failed to load %s, %d\n", fw_name, ret);
> > +               return ret;
> > +       }
> > +       dl_size = vpu_fw->size;
> > +       if (dl_size > fw_size) {
> > +               dev_err(vpu->dev, "fw %s size %zu is abnormal\n", fw_name,
> > +                       dl_size);
> > +               release_firmware(vpu_fw);
> > +               return  -EFBIG;
> > +       }
> > +       dev_dbg(vpu->dev, "Downloaded fw %s size: %zu.\n",
> > +               fw_name,
> > +               dl_size);
> > +       /* reset VPU */
> > +       vpu_cfg_writel(vpu, 0x0, VPU_RESET);
> > +
> > +       /* handle extended firmware size */
> > +       if (dl_size > tcm_size) {
> > +               dev_dbg(vpu->dev, "fw size %lx > limited fw size %lx\n",
> > +                       dl_size, tcm_size);
> > +               extra_fw_size = dl_size - tcm_size;
> > +               dev_dbg(vpu->dev, "extra_fw_size %lx\n", extra_fw_size);
> > +               dl_size = tcm_size;
> > +       }
> > +       dest = vpu->reg.tcm;
> > +       if (fw_type == D_FW)
> > +               dest += VPU_DTCM_OFFSET;
> > +       memcpy(dest, vpu_fw->data, dl_size);
> > +       /* download to extended memory if need */
> > +       if (extra_fw_size > 0) {
> > +               dest = vpu->extmem[fw_type].va;
> > +               dev_dbg(vpu->dev, "download extended memory type %x\n",
> > +                       fw_type);
> > +               memcpy(dest, vpu_fw->data + tcm_size, extra_fw_size);
> > +       }
> > +
> > +       release_firmware(vpu_fw);
> > +
> > +       return 0;
> > +}
> > +
> > +int vpu_load_firmware(struct platform_device *pdev)
> > +{
> > +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> > +       struct device *dev = &pdev->dev;
> > +       struct vpu_run *run = &vpu->run;
> > +       const struct firmware *vpu_fw;
> > +       int ret;
> > +
> > +       if (!pdev) {
> > +               dev_err(dev, "VPU platform device is invalid\n");
> > +               return -EINVAL;
> > +       }
> > +
> > +       mutex_lock(&vpu->vpu_mutex);
> > +
> > +       ret = vpu_clock_enable(vpu);
> > +       if (ret) {
> > +               dev_err(dev, "enable clock failed %d\n", ret);
> > +               goto OUT_LOAD_FW;
> > +       }
> > +
> > +       if (vpu_running(vpu)) {
> > +               vpu_clock_disable(vpu);
> > +               mutex_unlock(&vpu->vpu_mutex);
> > +               dev_warn(dev, "vpu is running already\n");
> > +               return 0;
> > +       }
> > +
> > +       run->signaled = false;
> > +       dev_dbg(vpu->dev, "firmware request\n");
> > +       /* Downloading program firmware to device*/
> > +       ret = load_requested_vpu(vpu, vpu_fw, P_FW);
> > +       if (ret < 0) {
> > +               dev_err(dev, "Failed to request %s, %d\n", VPU_P_FW, ret);
> > +               goto OUT_LOAD_FW;
> > +       }
> > +
> > +       /* Downloading data firmware to device */
> > +       ret = load_requested_vpu(vpu, vpu_fw, D_FW);
> > +       if (ret < 0) {
> > +               dev_err(dev, "Failed to request %s, %d\n", VPU_D_FW, ret);
> > +               goto OUT_LOAD_FW;
> > +       }
> > +
> > +       /* boot up vpu */
> > +       vpu_cfg_writel(vpu, 0x1, VPU_RESET);
> > +
> > +       ret = wait_event_interruptible_timeout(run->wq,
> > +                                              run->signaled,
> > +                                              msecs_to_jiffies(INIT_TIMEOUT_MS)
> > +                                              );
> > +       if (ret == 0) {
> > +               ret = -ETIME;
> > +               dev_err(dev, "wait vpu initialization timout!\n");
> > +               goto OUT_LOAD_FW;
> > +       } else if (-ERESTARTSYS == ret) {
> > +               dev_err(dev, "wait vpu interrupted by a signal!\n");
> > +               goto OUT_LOAD_FW;
> > +       }
> > +
> > +       ret = 0;
> > +       dev_info(dev, "vpu is ready. Fw version %s\n", run->fw_ver);
> > +
> > +OUT_LOAD_FW:
> > +       vpu_clock_disable(vpu);
> > +       mutex_unlock(&vpu->vpu_mutex);
> > +
> > +       return ret;
> > +}
> > +
> > +int vpu_compare_version(struct platform_device *pdev,
> > +                       const char *expected_version)
> > +{
> > +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> > +       int cur_major, cur_minor, cur_build, cur_rel, cur_ver_num;
> > +       int major, minor, build, rel, ver_num;
> > +       char *cur_version = vpu->run.fw_ver;
> > +
> > +       cur_ver_num = sscanf(cur_version, "%d.%d.%d-rc%d",
> > +                            &cur_major, &cur_minor, &cur_build, &cur_rel);
> > +       if (cur_ver_num < 3)
> > +               return -1;
> > +       ver_num = sscanf(expected_version, "%d.%d.%d-rc%d",
> > +                        &major, &minor, &build, &rel);
> > +       if (ver_num < 3)
> > +               return -1;
> > +
> > +       if (cur_major < major)
> > +               return -1;
> > +       if (cur_major > major)
> > +               return 1;
> > +
> > +       if (cur_minor < minor)
> > +               return -1;
> > +       if (cur_minor > minor)
> > +               return 1;
> > +
> > +       if (cur_build < build)
> > +               return -1;
> > +       if (cur_build > build)
> > +               return 1;
> > +
> > +       if (cur_ver_num < ver_num)
> > +               return -1;
> > +       if (cur_ver_num > ver_num)
> > +               return 1;
> > +
> > +       if (ver_num > 3) {
> > +               if (cur_rel < rel)
> > +                       return -1;
> > +               if (cur_rel > rel)
> > +                       return 1;
> > +       }
> > +
> > +       return 0;
> > +}
> > +
> > +static void vpu_init_ipi_handler(void *data, unsigned int len, void *priv)
> > +{
> > +       struct mtk_vpu *vpu = (struct mtk_vpu *)priv;
> > +       struct vpu_run *run = (struct vpu_run *)data;
> > +
> > +       vpu->run.signaled = run->signaled;
> > +       strncpy(vpu->run.fw_ver, run->fw_ver, VPU_FW_VER_LEN);
> > +       vpu->run.enc_capability = run->enc_capability;
> > +       wake_up_interruptible(&vpu->run.wq);
> > +}
> > +
> > +#ifdef CONFIG_DEBUG_FS
> > +static int vpu_debug_open(struct inode *inode, struct file *file)
> > +{
> > +       file->private_data = inode->i_private;
> > +       return 0;
> > +}
> > +
> > +static ssize_t vpu_debug_read(struct file *file, char __user *user_buf,
> > +                             size_t count, loff_t *ppos)
> > +{
> > +       char buf[256];
> > +       unsigned int len;
> > +       unsigned int running, pc, vpu_to_host, host_to_vpu, wdt;
> > +       int ret;
> > +       struct device *dev = file->private_data;
> > +       struct mtk_vpu *vpu = dev_get_drvdata(dev);
> > +
> > +       ret = vpu_clock_enable(vpu);
> > +       if (ret) {
> > +               dev_err(vpu->dev, "[VPU] enable clock failed %d\n", ret);
> > +               return 0;
> > +       }
> > +
> > +       /* vpu register status */
> > +       running = vpu_running(vpu);
> > +       pc = vpu_cfg_readl(vpu, VPU_PC_REG);
> > +       wdt = vpu_cfg_readl(vpu, VPU_WDT_REG);
> > +       host_to_vpu = vpu_cfg_readl(vpu, HOST_TO_VPU);
> > +       vpu_to_host = vpu_cfg_readl(vpu, VPU_TO_HOST);
> > +       vpu_clock_disable(vpu);
> > +
> > +       if (running) {
> > +               len = sprintf(buf, "VPU is running\n\n"
> > +               "FW Version: %s\n"
> > +               "PC: 0x%x\n"
> > +               "WDT: 0x%x\n"
> > +               "Host to VPU: 0x%x\n"
> > +               "VPU to Host: 0x%x\n",
> > +               vpu->run.fw_ver, pc, wdt,
> > +               host_to_vpu, vpu_to_host);
> > +       } else {
> > +               len = sprintf(buf, "VPU not running\n");
> > +       }
> > +
> > +       return simple_read_from_buffer(user_buf, count, ppos, buf, len);
> > +}
> > +
> > +static const struct file_operations vpu_debug_fops = {
> > +       .open = vpu_debug_open,
> > +       .read = vpu_debug_read,
> > +};
> > +#endif /* CONFIG_DEBUG_FS */
> > +
> > +static void vpu_free_ext_mem(struct mtk_vpu *vpu, u8 fw_type)
> > +{
> > +       struct device *dev = vpu->dev;
> > +       size_t fw_ext_size = fw_type ? VPU_EXT_D_SIZE : VPU_EXT_P_SIZE;
> > +
> > +       dma_free_coherent(dev, fw_ext_size, vpu->extmem[fw_type].va,
> > +                         vpu->extmem[fw_type].pa);
> > +}
> > +
> > +static int vpu_alloc_ext_mem(struct mtk_vpu *vpu, u32 fw_type)
> > +{
> > +       struct device *dev = vpu->dev;
> > +       size_t fw_ext_size = fw_type ? VPU_EXT_D_SIZE : VPU_EXT_P_SIZE;
> > +       u32 vpu_ext_mem0 = fw_type ? VPU_DMEM_EXT0_ADDR : VPU_PMEM_EXT0_ADDR;
> > +       u32 vpu_ext_mem1 = fw_type ? VPU_DMEM_EXT1_ADDR : VPU_PMEM_EXT1_ADDR;
> > +       u32 offset_4gb = vpu->enable_4GB ? 0x40000000 : 0;
> > +
> > +       vpu->extmem[fw_type].va = dma_alloc_coherent(dev,
> > +                                              fw_ext_size,
> > +                                              &vpu->extmem[fw_type].pa,
> > +                                              GFP_KERNEL);
> > +       if (!vpu->extmem[fw_type].va) {
> > +               dev_err(dev, "Failed to allocate the extended program memory\n");
> > +               return PTR_ERR(vpu->extmem[fw_type].va);
> > +       }
> > +
> > +       /* Disable extend0. Enable extend1 */
> > +       vpu_cfg_writel(vpu, 0x1, vpu_ext_mem0);
> > +       vpu_cfg_writel(vpu, (vpu->extmem[fw_type].pa & 0xFFFFF000) + offset_4gb,
> > +                      vpu_ext_mem1);
> > +
> > +       dev_info(dev, "%s extend memory phy=0x%llx virt=0x%p\n",
> > +                fw_type ? "Data" : "Program",
> > +                (unsigned long long)vpu->extmem[fw_type].pa,
> > +                vpu->extmem[fw_type].va);
> > +
> > +       return 0;
> > +}
> > +
> > +static void vpu_ipi_handler(struct mtk_vpu *vpu)
> > +{
> > +       struct share_obj *rcv_obj = vpu->recv_buf;
> > +       struct vpu_ipi_desc *ipi_desc = vpu->ipi_desc;
> > +
> > +       if (rcv_obj->id < IPI_MAX && ipi_desc[rcv_obj->id].handler) {
> check rcv_obj->id >= 0

The variable type of "rcv_obj->id" is u32. I think we don't need to
check this range.Thanks.

> > +               ipi_desc[rcv_obj->id].handler(rcv_obj->share_buf,
> > +                                             rcv_obj->len,
> > +                                             ipi_desc[rcv_obj->id].priv);
> > +               if (rcv_obj->id > IPI_VPU_INIT) {
> > +                       vpu->ipi_id_ack[rcv_obj->id] = true;
> > +                       wake_up_interruptible(&vpu->ack_wq);
> > +               }
> > +       } else {
> > +               dev_err(vpu->dev, "No such ipi id = %d\n", rcv_obj->id);
> > +       }
> > +}
> > +
> > +static int vpu_ipi_init(struct mtk_vpu *vpu)
> > +{
> > +       /* Disable VPU to host interrupt */
> > +       vpu_cfg_writel(vpu, 0x0, VPU_TO_HOST);
> > +
> > +       /* shared buffer initialization */
> > +       vpu->recv_buf = (struct share_obj *)(vpu->reg.tcm + VPU_DTCM_OFFSET);
> > +       vpu->send_buf = vpu->recv_buf + 1;
> > +       memset(vpu->recv_buf, 0, sizeof(struct share_obj));
> > +       memset(vpu->send_buf, 0, sizeof(struct share_obj));
> > +       mutex_init(&vpu->vpu_mutex);
> > +
> > +       return 0;
> > +}
> > +
> > +static irqreturn_t vpu_irq_handler(int irq, void *priv)
> > +{
> > +       struct mtk_vpu *vpu = priv;
> > +       u32 vpu_to_host;
> > +       int ret;
> > +
> > +       /*
> > +        * Clock should have been enabled already.
> > +        * Enable again in case vpu_ipi_send times out
> > +        * and has disabled the clock.
> > +        */
> > +       ret = clk_enable(vpu->clk);
> > +       if (ret) {
> > +               dev_err(vpu->dev, "[VPU] enable clock failed %d\n", ret);
> > +               return IRQ_NONE;
> > +       }
> > +       vpu_to_host = vpu_cfg_readl(vpu, VPU_TO_HOST);
> > +       if (vpu_to_host & VPU_IPC_INT) {
> > +               vpu_ipi_handler(vpu);
> > +       } else {
> > +               dev_err(vpu->dev, "vpu watchdog timeout! 0x%x", vpu_to_host);
> > +               if (vpu->wdt.wq)
> Remove. mtk_vpu_probe makes sure wdt.wq is not NULL.
I will change this in next version. Thanks.

> > +                       queue_work(vpu->wdt.wq, &vpu->wdt.ws);
> > +       }
> > +
> > +       /* VPU won't send another interrupt until we set VPU_TO_HOST to 0. */
> > +       vpu_cfg_writel(vpu, 0x0, VPU_TO_HOST);
> > +       clk_disable(vpu->clk);
> > +
> > +       return IRQ_HANDLED;
> > +}
> > +
> > +#ifdef CONFIG_DEBUG_FS
> > +static struct dentry *vpu_debugfs;
> > +#endif
> > +static int mtk_vpu_probe(struct platform_device *pdev)
> > +{
> > +       struct mtk_vpu *vpu;
> > +       struct device *dev;
> > +       struct resource *res;
> > +       int ret = 0;
> > +
> > +       dev_dbg(&pdev->dev, "initialization\n");
> > +
> > +       dev = &pdev->dev;
> > +       vpu = devm_kzalloc(dev, sizeof(*vpu), GFP_KERNEL);
> > +       if (!vpu)
> > +               return -ENOMEM;
> > +
> > +       vpu->dev = &pdev->dev;
> > +       res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "tcm");
> > +       vpu->reg.tcm = devm_ioremap_resource(dev, res);
> > +       if (IS_ERR(vpu->reg.tcm)) {
> > +               dev_err(dev, "devm_ioremap_resource vpu tcm failed.\n");
> > +               return PTR_ERR(vpu->reg.tcm);
> > +       }
> > +
> > +       res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg_reg");
> > +       vpu->reg.cfg = devm_ioremap_resource(dev, res);
> > +       if (IS_ERR(vpu->reg.cfg)) {
> > +               dev_err(dev, "devm_ioremap_resource vpu cfg failed.\n");
> > +               return PTR_ERR(vpu->reg.cfg);
> > +       }
> > +
> > +       /* Get VPU clock */
> > +       vpu->clk = devm_clk_get(dev, "main");
> > +       if (!vpu->clk) {
> > +               dev_err(dev, "get vpu clock failed\n");
> > +               return -EINVAL;
> > +       }
> > +
> > +       platform_set_drvdata(pdev, vpu);
> > +
> > +       ret = clk_prepare(vpu->clk);
> > +       if (ret) {
> > +               dev_err(dev, "prepare vpu clock failed\n");
> > +               return ret;
> > +       }
> > +
> > +       /* VPU watchdog */
> > +       vpu->wdt.wq = create_singlethread_workqueue("vpu_wdt");
> > +       if (!vpu->wdt.wq) {
> > +               dev_err(dev, "initialize wdt workqueue failed\n");
> > +               return -ENOMEM;
> > +       }
> > +       INIT_WORK(&vpu->wdt.ws, vpu_wdt_reset_func);
> > +
> > +       ret = vpu_clock_enable(vpu);
> > +       if (ret) {
> > +               dev_err(dev, "enable vpu clock failed\n");
> > +               goto workqueue_destroy;
> > +       }
> > +
> > +       dev_dbg(dev, "vpu ipi init\n");
> > +       ret = vpu_ipi_init(vpu);
> > +       if (ret) {
> > +               dev_err(dev, "Failed to init ipi\n");
> > +               goto disable_vpu_clk;
> > +       }
> > +
> > +       /* register vpu initialization IPI */
> > +       ret = vpu_ipi_register(pdev, IPI_VPU_INIT, vpu_init_ipi_handler,
> > +                              "vpu_init", vpu);
> > +       if (ret) {
> > +               dev_err(dev, "Failed to register IPI_VPU_INIT\n");
> > +               goto vpu_mutex_destroy;
> > +       }
> > +
> > +#ifdef CONFIG_DEBUG_FS
> > +       vpu_debugfs = debugfs_create_file("mtk_vpu", S_IRUGO, NULL, (void *)dev,
> > +                                         &vpu_debug_fops);
> > +       if (!vpu_debugfs) {
> > +               ret = -ENOMEM;
> > +               goto cleanup_ipi;
> > +       }
> > +#endif
> > +
> > +       /* Set PTCM to 96K and DTCM to 32K */
> > +       vpu_cfg_writel(vpu, 0x2, VPU_TCM_CFG);
> > +
> > +       vpu->enable_4GB = !!(max_pfn > (0xffffffffUL >> PAGE_SHIFT));
> > +       dev_dbg(dev, "4GB mode %u\n", vpu->enable_4GB);
> > +
> > +       if (vpu->enable_4GB) {
> > +               ret = of_reserved_mem_device_init(dev);
> > +               if (ret)
> > +                       dev_info(dev, "init reserved memory failed\n");
> > +                       /* continue to use dynamic allocation if failed */
> > +       }
> > +
> > +       ret = vpu_alloc_ext_mem(vpu, D_FW);
> > +       if (ret) {
> > +               dev_err(dev, "Allocate DM failed\n");
> > +               goto remove_debugfs;
> > +       }
> > +
> > +       ret = vpu_alloc_ext_mem(vpu, P_FW);
> > +       if (ret) {
> > +               dev_err(dev, "Allocate PM failed\n");
> > +               goto free_d_mem;
> > +       }
> > +
> > +       init_waitqueue_head(&vpu->run.wq);
> > +       init_waitqueue_head(&vpu->ack_wq);
> > +
> > +       res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> > +       if (!res) {
> > +               dev_err(dev, "get IRQ resource failed.\n");
> > +               ret = -ENXIO;
> > +               goto free_p_mem;
> > +       }
> > +       vpu->reg.irq = platform_get_irq(pdev, 0);
> > +       ret = devm_request_irq(dev, vpu->reg.irq, vpu_irq_handler, 0,
> > +                              pdev->name, vpu);
> > +       if (ret) {
> > +               dev_err(dev, "failed to request irq\n");
> > +               goto free_p_mem;
> > +       }
> > +
> > +       vpu_clock_disable(vpu);
> > +       dev_dbg(dev, "initialization completed\n");
> > +
> > +       return 0;
> > +
> > +free_p_mem:
> > +       vpu_free_ext_mem(vpu, P_FW);
> > +free_d_mem:
> > +       vpu_free_ext_mem(vpu, D_FW);
> > +remove_debugfs:
> > +       of_reserved_mem_device_release(dev);
> > +#ifdef CONFIG_DEBUG_FS
> > +       debugfs_remove(vpu_debugfs);
> > +cleanup_ipi:
> > +#endif
> > +       memset(vpu->ipi_desc, 0, sizeof(struct vpu_ipi_desc) * IPI_MAX);
> > +vpu_mutex_destroy:
> > +       mutex_destroy(&vpu->vpu_mutex);
> > +disable_vpu_clk:
> > +       vpu_clock_disable(vpu);
> > +workqueue_destroy:
> > +       destroy_workqueue(vpu->wdt.wq);
> > +
> > +       return ret;
> > +}
> > +
> > +static const struct of_device_id mtk_vpu_match[] = {
> > +       {
> > +               .compatible = "mediatek,mt8173-vpu",
> > +       },
> > +       {},
> > +};
> > +MODULE_DEVICE_TABLE(of, mtk_vpu_match);
> > +
> > +static int mtk_vpu_remove(struct platform_device *pdev)
> > +{
> > +       struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> > +
> > +#ifdef CONFIG_DEBUG_FS
> > +       debugfs_remove(vpu_debugfs);
> > +#endif
> > +       if (vpu->wdt.wq) {
> > +               flush_workqueue(vpu->wdt.wq);
> > +               destroy_workqueue(vpu->wdt.wq);
> > +       }
> > +       vpu_free_ext_mem(vpu, P_FW);
> > +       vpu_free_ext_mem(vpu, D_FW);
> > +       mutex_destroy(&vpu->vpu_mutex);
> > +       clk_unprepare(vpu->clk);
> > +
> > +       return 0;
> > +}
> > +
> > +static struct platform_driver mtk_vpu_driver = {
> > +       .probe  = mtk_vpu_probe,
> > +       .remove = mtk_vpu_remove,
> > +       .driver = {
> > +               .name   = "mtk_vpu",
> > +               .owner  = THIS_MODULE,
> > +               .of_match_table = mtk_vpu_match,
> > +       },
> > +};
> > +
> > +module_platform_driver(mtk_vpu_driver);
> > +
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_DESCRIPTION("Mediatek Video Prosessor Unit driver");
> > diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.h b/drivers/media/platform/mtk-vpu/mtk_vpu.h
> > new file mode 100644
> > index 0000000..d9c3cde
> > --- /dev/null
> > +++ b/drivers/media/platform/mtk-vpu/mtk_vpu.h
> > @@ -0,0 +1,167 @@
> > +/*
> > +* Copyright (c) 2015 MediaTek Inc.
> > +* Author: Andrew-CT Chen <andrew-ct.chen at mediatek.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.
> > +*/
> > +
> > +#ifndef _MTK_VPU_H
> > +#define _MTK_VPU_H
> > +
> > +#include <linux/platform_device.h>
> > +
> > +/**
> > + * VPU (video processor unit) is a tiny processor controlling video hardware
> > + * related to video codec, scaling and color format converting.
> > + * VPU interfaces with other blocks by share memory and interrupt.
> > + **/
> > +
> > +typedef void (*ipi_handler_t) (void *data,
> > +                              unsigned int len,
> > +                              void *priv);
> > +
> > +/**
> > + * enum ipi_id - the id of inter-processor interrupt
> > + *
> > + * @IPI_VPU_INIT:       The interrupt from vpu is to notfiy kernel
> > +                        VPU initialization completed.
> > +                        IPI_VPU_INIT is sent from VPU when firmware is
> > +                        loaded. AP doesn't need to send IPI_VPU_INIT
> > +                        command to VPU.
> > +                        For other IPI below, AP should send the request
> > +                        to VPU to trigger the interrupt.
> > + * @IPI_VENC_H264:      The interrupt from vpu is to notify kernel to
> > +                        handle H264 video encoder job, and vice versa.
> > + * @IPI_VENC_VP8:       The interrupt fro vpu is to notify kernel to
> > +                        handle VP8 video encoder job,, and vice versa.
> > + * @IPI_MAX:            The maximum IPI number
> > + */
> > +
> > +enum ipi_id {
> > +       IPI_VPU_INIT = 0,
> > +       IPI_VENC_H264,
> > +       IPI_VENC_VP8,
> > +       IPI_MAX,
> > +};
> > +
> > +/**
> > + * enum rst_id - reset id to register reset function for VPU watchdog timeout
> > + *
> > + * @VPU_RST_DEC: decoder reset id
> > + * @VPU_RST_ENC: encoder reset id
> > + * @VPU_RST_MDP: MDP (Media Data Path) reset id
> > + * @VPU_RST_MAX: maximum reset id
> > + */
> > +enum rst_id {
> > +       VPU_RST_ENC,
> > +       VPU_RST_DEC,
> > +       VPU_RST_MDP,
> > +       VPU_RST_MAX,
> > +};
> > +
> > +/**
> > + * vpu_ipi_register - register an ipi function
> > + *
> > + * @pdev:      VPU platform device
> > + * @id:                IPI ID
> > + * @handler:   IPI handler
> > + * @name:      IPI name
> > + * @priv:      private data for IPI handler
> > + *
> > + * Register an ipi function to receive ipi interrupt from VPU.
> > + *
> > + * Return: Return 0 if ipi registers successfully, otherwise it is failed.
> > + */
> > +int vpu_ipi_register(struct platform_device *pdev, enum ipi_id id,
> > +                    ipi_handler_t handler, const char *name, void *priv);
> > +
> > +/**
> > + * vpu_ipi_send - send data from AP to vpu.
> > + *
> > + * @pdev:      VPU platform device
> > + * @id:                IPI ID
> > + * @buf:       the data buffer
> > + * @len:       the data buffer length
> > + *
> > + * This function is thread-safe. When this function returns,
> > + * VPU has received the data and starts the processing.
> > + * When the processing completes, IPI handler registered
> > + * by vpu_ipi_register will be called in interrupt context.
> > + *
> > + * Return: Return 0 if sending data successfully, otherwise it is failed.
> > + **/
> > +int vpu_ipi_send(struct platform_device *pdev,
> > +                enum ipi_id id, void *buf,
> > +                unsigned int len);
> > +
> > +/**
> > + * vpu_get_plat_device - get VPU's platform device
> > + *
> > + * @pdev:      the platform device of the module requesting VPU platform
> > + *             device for using VPU API.
> > + *
> > + * Return: Return NULL if it is failed.
> > + * otherwise it is VPU's platform device
> > + **/
> > +struct platform_device *vpu_get_plat_device(struct platform_device *pdev);
> > +
> > +/**
> > + * vpu_wdt_reg_handler - register a VPU watchdog handler
> > + *
> > + * @pdev:               VPU platform device
> > + * @vpu_wdt_reset_func:        the callback reset function
> > + * @private_data:       the private data for reset function
> > + * @rst_id:            reset id
> > + *
> > + * Register a handler performing own tasks when vpu reset by watchdog
> > + *
> > + * Return: Return 0 if the handler is added successfully,
> > + * otherwise it is failed.
> > + *
> > + **/
> > +int vpu_wdt_reg_handler(struct platform_device *pdev,
> > +                       void vpu_wdt_reset_func(void *),
> > +                       void *priv, enum rst_id id);
> > +
> > +/**
> > + * vpu_get_venc_hw_capa - get video encoder hardware capability
> > + *
> > + * @pdev:      VPU platform device
> > + *
> > + * Return: video encoder hardware capability
> > + **/
> > +unsigned int vpu_get_venc_hw_capa(struct platform_device *pdev);
> > +
> > +/**
> > + * vpu_load_firmware - download VPU firmware and boot it
> > + *
> > + * @pdev:      VPU platform device
> > + *
> > + * Return: Return 0 if downloading firmware successfully,
> > + * otherwise it is failed
> > + **/
> > +int vpu_load_firmware(struct platform_device *pdev);
> > +
> > +/**
> > + * vpu_mapping_dm_addr - Mapping DTCM/DMEM to kernel virtual address
> > + *
> > + * @pdev:      VPU platform device
> > + * @dmem_addr: VPU's data memory address
> > + *
> > + * Mapping the VPU's DTCM (Data Tightly-Coupled Memory) /
> > + * DMEM (Data Extended Memory) memory address to
> > + * kernel virtual address.
> > + *
> > + * Return: Return ERR_PTR(-EINVAL) if mapping failed,
> > + * otherwise the mapped kernel virtual address
> > + **/
> > +void *vpu_mapping_dm_addr(struct platform_device *pdev,
> > +                         u32 dtcm_dmem_addr);
> > +#endif /* _MTK_VPU_H */
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html




From dirk.behme at de.bosch.com  Tue Feb 16 01:43:22 2016
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Tue, 16 Feb 2016 10:43:22 +0100
Subject: [PATCH v2] arm64: dts: r8a7795: Add GIC-400 virtual interfaces
Message-ID: <1455615802-9083-1-git-send-email-dirk.behme@de.bosch.com>

Besides the distributor and the CPU interface the GIC-400 additionally
supports the virtual interface control blocks and the virtual CPU interfaces.

Add the physical base addresses and size for these.

See

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0471b/index.html
-> 3.2. GIC-400 register map

and Linux kernel's

Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt

for more details.

For the at GICH Virtual interface control blocks at 0xf1040000 cover the
whole 128kB (0x20000) range. This is done based on the advice from Marc
Zyngier http://www.spinics.net/lists/arm-kernel/msg483139.html

Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
---
Changes in v2: Extend the GICH size to 128kB.

 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 8f1ed23..65f9cc8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -130,7 +130,9 @@
 			#address-cells = <0>;
 			interrupt-controller;
 			reg = <0x0 0xf1010000 0 0x1000>,
-			      <0x0 0xf1020000 0 0x2000>;
+			      <0x0 0xf1020000 0 0x2000>,
+			      <0x0 0xf1040000 0 0x20000>,
+			      <0x0 0xf1060000 0 0x2000>;
 			interrupts = <GIC_PPI 9
 					(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
 		};
-- 
2.5.1



From sudeep.holla at arm.com  Tue Feb 16 01:43:35 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Tue, 16 Feb 2016 09:43:35 +0000
Subject: [PATCH v3 6/7] arm64: dts: r8a7795: Add missing properties to
 CA57 L2 cache node
In-Reply-To: <56C2C471.80000@de.bosch.com>
References: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
 <1455568715-20880-7-git-send-email-geert+renesas@glider.be>
 <56C2C471.80000@de.bosch.com>
Message-ID: <56C2EF47.4080809@arm.com>



On 16/02/16 06:40, Dirk Behme wrote:
> On 15.02.2016 21:38, Geert Uytterhoeven wrote:
>> Add the missing "cache-unified" and "cache-level" properties to the
>> Cortex-A57 cache-controller node.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
>> ---
>> v3:
>>    - Remaining part of "[PATCH v2 6/6] arm64: renesas: r8a7795: Add L2
>>      cache-controller nodes", after dropping the "arm,data-latency" and
>>      "arm,tag-latency" properties.
>> ---
>>   arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> index b5e46e4ff72ad003..c07f4e83b988ba42 100644
>> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> @@ -68,6 +68,8 @@
>>
>>       L2_CA57: cache-controller at 0 {
>>           compatible = "cache";
>> +        cache-unified;
>> +        cache-level = <2>;
>
>
> As this is completely unused on ARMv8 I don't think that we want to have
> these unused entries in the DT.
>
> Sudeep: What do you think?
>

I am fine with that, I don't see any issue having them as they are
static values and highly unlikely to change and hence no threat to
backward compatibility.

The main concern I had with latency values is that it's currently not
used anywhere but if we decide to use say in secure software, having the
untested/early values in DT might cause compatibility issues in future
as they were added much before the actual understanding of it's usage.
So I prefer to defer them until then.

-- 
Regards,
Sudeep


From sudeep.holla at arm.com  Tue Feb 16 01:46:11 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Tue, 16 Feb 2016 09:46:11 +0000
Subject: [PATCH v3 7/7] arm64: dts: r8a7795: Add CA53 L2 cache-controller
 node
In-Reply-To: <CAMuHMdX=Kgb-i+QpP=yNO2e6nw7sXuCutXPoK0U9NwK-OyANFA@mail.gmail.com>
References: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
 <1455568715-20880-8-git-send-email-geert+renesas@glider.be>
 <56C2C534.30704@de.bosch.com>
 <CAMuHMdX=Kgb-i+QpP=yNO2e6nw7sXuCutXPoK0U9NwK-OyANFA@mail.gmail.com>
Message-ID: <56C2EFE3.6010900@arm.com>



On 16/02/16 07:12, Geert Uytterhoeven wrote:
> Hi Dirk,
>
> On Tue, Feb 16, 2016 at 7:44 AM, Dirk Behme <dirk.behme at de.bosch.com> wrote:

[...]

>>
>> As we don't have any CA53 in the device tree yet, and it was rejected to add
>> it, I'd think that we don't want these unused entries at the moment.
>
> This is a preparatory step for adding the SYSC PM Domains.
>
>> I'd propose to add the CA53 entries, first. And then add their L2 cache
>> entries.
>>
>> Based on the outcome of the discussion for the CA57 we have to see if we
>> want to add the unused cache-unified and cache-level, then, too.
>
> These are specified by ePAPR, as I said before.
> Remember, DT describes the hardware, not what Linux (or any other OS) is
> using.
>

I completely agree and I mentioned the same in the other email.

-- 
Regards,
Sudeep


From andre.przywara at arm.com  Tue Feb 16 01:45:57 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 16 Feb 2016 09:45:57 +0000
Subject: [PATCH 1/3] clk: sunxi: improve mux_clk error handling and
 reporting
In-Reply-To: <CAGb2v65hxNiY8XAL=yBbV4qazscJd+six432CKWAm+GfM6bd2Q@mail.gmail.com>
References: <1455289913-29514-1-git-send-email-andre.przywara@arm.com>
 <1455289913-29514-2-git-send-email-andre.przywara@arm.com>
 <CAGb2v65hxNiY8XAL=yBbV4qazscJd+six432CKWAm+GfM6bd2Q@mail.gmail.com>
Message-ID: <56C2EFD5.5080604@arm.com>

Hi Chen-Yu,

On 13/02/16 02:44, Chen-Yu Tsai wrote:
> Hi,
> 
> On Fri, Feb 12, 2016 at 11:11 PM, Andre Przywara <andre.przywara at arm.com> wrote:
>> We now catch and report a failing ioremap, also a failure in the final
>> step of the clock registration is now handled and reported.
>> Also warnings are turned into errors.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>> ---
>>  drivers/clk/sunxi/clk-sunxi.c | 19 +++++++++++++------
>>  1 file changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>> index 49ce283..361f396 100644
>> --- a/drivers/clk/sunxi/clk-sunxi.c
>> +++ b/drivers/clk/sunxi/clk-sunxi.c
>> @@ -690,11 +690,15 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
>>         int i;
>>
>>         reg = of_iomap(node, 0);
>> +       if (!reg) {
>> +               pr_err("Could not map registers for mux-clk: %s\n", node->name);
> 
> of_node_full_name(node->name) is better. node->name is almost always "clk",
> which is useless. (Unless someone goes through the dts files to replace all
> of them.)

Good point. I both fixed the code here as well as amended the node names
in the A64 DT.

> 
>> +               return NULL;
>> +       }
>>
>>         i = of_clk_parent_fill(node, parents, SUNXI_MAX_PARENTS);
>>         if (of_property_read_string(node, "clock-output-names", &clk_name)) {
>> -               pr_warn("%s: could not read clock-output-names for \"%s\"\n",
>> -                       __func__, clk_name);
>> +               pr_err("%s: could not read clock-output-names for \"%s\"\n",
>> +                      __func__, clk_name);
> 
> Same here. clk_name defaults to node->name. If you could, please replace it.

Really? Isn't clk_name directly from the DT clock-output-names strings here?

>>                 goto out_unmap;
>>         }
>>
>> @@ -704,14 +708,17 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
>>                                0, &clk_lock);
>>
>>         if (IS_ERR(clk)) {
>> -               pr_warn("%s: failed to register mux clock %s: %ld\n", __func__,
>> -                       clk_name, PTR_ERR(clk));
>> +               pr_err("%s: failed to register mux clock %s: %ld\n", __func__,
>> +                      clk_name, PTR_ERR(clk));
>>                 goto out_unmap;
>>         }
>>
>> -       of_clk_add_provider(node, of_clk_src_simple_get, clk);
>> +       if (!of_clk_add_provider(node, of_clk_src_simple_get, clk))
>> +               return clk;
>> +
>> +       pr_err("%s: failed to add clock provider for %s\n", __func__, clk_name);
>>
>> -       return clk;
> 
> I'd have all the error path in ifs, and have the normal return path
> here for consistency.
> But I guess this works as well.

Yeah, I wanted to skip that single goto ;-)
But I changed it now as you said and it indeed looks more reasonable.

I took the freedom of applying the comments to the other patches too.

Will send out a v2 in a minute.

Thanks for looking!
Andre.

> 
> Thanks!
> ChenYu
> 
>> +       clk_unregister_divider(clk);
>>
>>  out_unmap:
>>         iounmap(reg);
>> --
>> 2.6.4
>>
> 


From will.deacon at arm.com  Tue Feb 16 01:53:20 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 16 Feb 2016 09:53:20 +0000
Subject: Writes, smp_wmb(), and transitivity?
In-Reply-To: <20160215203512.GL6719@linux.vnet.ibm.com>
References: <20160215175825.GA15878@linux.vnet.ibm.com>
 <20160215185832.GQ6298@arm.com>
 <20160215203512.GL6719@linux.vnet.ibm.com>
Message-ID: <20160216095319.GA14509@arm.com>

On Mon, Feb 15, 2016 at 12:35:12PM -0800, Paul E. McKenney wrote:
> On Mon, Feb 15, 2016 at 06:58:32PM +0000, Will Deacon wrote:
> > On Mon, Feb 15, 2016 at 09:58:25AM -0800, Paul E. McKenney wrote:
> > > Some architectures provide local transitivity for a chain of threads doing
> > > writes separated by smp_wmb(), as exemplified by the litmus tests below.
> > > The pattern is that each thread writes to a its own variable, does an
> > > smp_wmb(), then writes a different value to the next thread's variable.
> > > 
> > > I don't know of a use of this, but if everyone supports it, it might
> > > be good to mandate it.  Status quo is that smp_wmb() is non-transitive,
> > > so it currently isn't supported.
> > > 
> > > Anyone know of any architectures that do -not- support this?
> > > 
> > > Assuming all architectures -do- support this, any arguments -against-
> > > officially supporting it in Linux?
> > > 
> > > 							Thanx, Paul
> > > 
> > > ------------------------------------------------------------------------
> > > 
> > > Two threads:
> > > 
> > > 	int a, b;
> > > 
> > > 	void thread0(void)
> > > 	{
> > > 		WRITE_ONCE(a, 1);
> > > 		smp_wmb();
> > > 		WRITE_ONCE(b, 2);
> > > 	}
> > > 
> > > 	void thread1(void)
> > > 	{
> > > 		WRITE_ONCE(b, 1);
> > > 		smp_wmb();
> > > 		WRITE_ONCE(a, 2);
> > > 	}
> > > 
> > > 	/* After all threads have completed and the dust has settled... */
> > > 
> > > 	BUG_ON(a == 1 && b == 1);
> > 
> > My understanding is that this test, and the generalisation to n threads,
> > is forbidden on ARM. However, the transitivity of DMB ST (used to
> > construct smp_wmb()) has been the subject of long debates, because we
> > allow the following test:
> > 
> > 
> > P0:
> > Wx = 1
> > 
> > P1:
> > Rx == 1
> > DMB ST
> > Wy = 1
> > 
> > P2:
> > Ry == 1
> > <addr dep>
> > Rx == 0
> > 
> > 
> > so I'd be uneasy about saying "it's all transitive".
> 
> Agreed!  For one thing, doesn't DMB ST need writes on both sides?

Yes, but it's a common trap that people fall into where they think the
above is forbidden because the DMB ST in P1 should order P0's write
before its own write of y.

> But that is one reason that I am only semi-enthusiastic about this.
> The potentially locally transitive case is -very- restrictive, applying
> only to situations where -all- accesses are writes.

I think that we will confuse people more by trying to describe the
restricted case where we provide order than if we blanket say that its
not transitive. I know Linus prefers to be as strong as possible, but
this doesn't look like a realistic programming paradigm and having a
straightforward rule that "rmb and wmb are not transitive" is much
easier for people to deal with in my opinion.

Will


From sebott at linux.vnet.ibm.com  Tue Feb 16 01:54:23 2016
From: sebott at linux.vnet.ibm.com (Sebastian Ott)
Date: Tue, 16 Feb 2016 10:54:23 +0100 (CET)
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160215213526.GA9766@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name> <56BE00E7.1010303@de.ibm.com>
 <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
 <alpine.LFD.2.20.1602131238260.1910@schleppi>
 <20160215113159.GA28832@node.shutemov.name>
 <20160215193702.4a15ed5e@thinkpad> <20160215213526.GA9766@node.shutemov.name>
Message-ID: <alpine.LFD.2.20.1602161053410.1762@schleppi>


On Mon, 15 Feb 2016, Kirill A. Shutemov wrote:
> Just to make sure: commit 122afea9626a is fine, commit 61f5d698cc97
> crashes. Correct?

Correct.



From dirk.behme at de.bosch.com  Tue Feb 16 01:55:19 2016
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Tue, 16 Feb 2016 10:55:19 +0100
Subject: [PATCH v3 6/7] arm64: dts: r8a7795: Add missing properties to
 CA57 L2 cache node
In-Reply-To: <56C2EF47.4080809@arm.com>
References: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
 <1455568715-20880-7-git-send-email-geert+renesas@glider.be>
 <56C2C471.80000@de.bosch.com> <56C2EF47.4080809@arm.com>
Message-ID: <56C2F207.2080703@de.bosch.com>

On 16.02.2016 10:43, Sudeep Holla wrote:
>
>
> On 16/02/16 06:40, Dirk Behme wrote:
>> On 15.02.2016 21:38, Geert Uytterhoeven wrote:
>>> Add the missing "cache-unified" and "cache-level" properties to the
>>> Cortex-A57 cache-controller node.
>>>
>>> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
>>> ---
>>> v3:
>>>    - Remaining part of "[PATCH v2 6/6] arm64: renesas: r8a7795: Add L2
>>>      cache-controller nodes", after dropping the "arm,data-latency" and
>>>      "arm,tag-latency" properties.
>>> ---
>>>   arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>> index b5e46e4ff72ad003..c07f4e83b988ba42 100644
>>> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>> @@ -68,6 +68,8 @@
>>>
>>>       L2_CA57: cache-controller at 0 {
>>>           compatible = "cache";
>>> +        cache-unified;
>>> +        cache-level = <2>;
>>
>>
>> As this is completely unused on ARMv8 I don't think that we want to have
>> these unused entries in the DT.
>>
>> Sudeep: What do you think?
>>
>
> I am fine with that, I don't see any issue having them as they are
> static values and highly unlikely to change and hence no threat to
> backward compatibility.
>
> The main concern I had with latency values is that it's currently not
> used anywhere but if we decide to use say in secure software, having the
> untested/early values in DT might cause compatibility issues in future
> as they were added much before the actual understanding of it's usage.
> So I prefer to defer them until then.


Fine with me, thanks! :)

With this clarification:

Acked-by: Dirk Behme <dirk.behme at de.bosch.com>


Thanks again and best regards

Dirk




From geert at linux-m68k.org  Tue Feb 16 01:55:37 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 16 Feb 2016 10:55:37 +0100
Subject: [PATCH v2] arm64: dts: r8a7795: Add GIC-400 virtual interfaces
In-Reply-To: <1455615802-9083-1-git-send-email-dirk.behme@de.bosch.com>
References: <1455615802-9083-1-git-send-email-dirk.behme@de.bosch.com>
Message-ID: <CAMuHMdVP4wA4eXK-fkENndNs=zS2vuUeDww2ZZbXvocfFiOgWQ@mail.gmail.com>

CC Marc

On Tue, Feb 16, 2016 at 10:43 AM, Dirk Behme <dirk.behme at de.bosch.com> wrote:
> Besides the distributor and the CPU interface the GIC-400 additionally
> supports the virtual interface control blocks and the virtual CPU interfaces.
>
> Add the physical base addresses and size for these.
>
> See
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0471b/index.html
> -> 3.2. GIC-400 register map
>
> and Linux kernel's
>
> Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
>
> for more details.
>
> For the at GICH Virtual interface control blocks at 0xf1040000 cover the
> whole 128kB (0x20000) range. This is done based on the advice from Marc
> Zyngier http://www.spinics.net/lists/arm-kernel/msg483139.html
>
> Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>

Thanks!

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>

> ---
> Changes in v2: Extend the GICH size to 128kB.
>
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index 8f1ed23..65f9cc8 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -130,7 +130,9 @@
>                         #address-cells = <0>;
>                         interrupt-controller;
>                         reg = <0x0 0xf1010000 0 0x1000>,
> -                             <0x0 0xf1020000 0 0x2000>;
> +                             <0x0 0xf1020000 0 0x2000>,
> +                             <0x0 0xf1040000 0 0x20000>,
> +                             <0x0 0xf1060000 0 0x2000>;
>                         interrupts = <GIC_PPI 9
>                                         (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>                 };
> --
> 2.5.1

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From marc.zyngier at arm.com  Tue Feb 16 01:55:41 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 16 Feb 2016 09:55:41 +0000
Subject: [PATCH v4 21/23] arm64: hw_breakpoint: Allow EL2 breakpoints if
 running in HYP
In-Reply-To: <20160215190747.GR6298@arm.com>
References: <1455216004-19499-1-git-send-email-marc.zyngier@arm.com>
 <1455216004-19499-22-git-send-email-marc.zyngier@arm.com>
 <20160215174656.GN6298@arm.com> <20160215190747.GR6298@arm.com>
Message-ID: <56C2F21D.90205@arm.com>

On 15/02/16 19:07, Will Deacon wrote:
> On Mon, Feb 15, 2016 at 05:46:56PM +0000, Will Deacon wrote:
>> On Thu, Feb 11, 2016 at 06:40:02PM +0000, Marc Zyngier wrote:
>>> With VHE, we place kernel {watch,break}-points at EL2 to get things
>>> like kgdb and "perf -e mem:..." working.
>>>
>>> This requires a bit of repainting in the low-level encore/decode,
>>> but is otherwise pretty simple.
>>>
>>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>>> ---
>>>  arch/arm64/include/asm/hw_breakpoint.h | 49 +++++++++++++++++++++-------------
>>>  1 file changed, 31 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
>>> index 9732908..4d8d5a8 100644
>>> --- a/arch/arm64/include/asm/hw_breakpoint.h
>>> +++ b/arch/arm64/include/asm/hw_breakpoint.h
>>> @@ -18,6 +18,7 @@
>>>  
>>>  #include <asm/cputype.h>
>>>  #include <asm/cpufeature.h>
>>> +#include <asm/virt.h>
>>>  
>>>  #ifdef __KERNEL__
>>>  
>>> @@ -35,24 +36,6 @@ struct arch_hw_breakpoint {
>>>  	struct arch_hw_breakpoint_ctrl ctrl;
>>>  };
>>>  
>>> -static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
>>> -{
>>> -	return (ctrl.len << 5) | (ctrl.type << 3) | (ctrl.privilege << 1) |
>>> -		ctrl.enabled;
>>> -}
>>> -
>>> -static inline void decode_ctrl_reg(u32 reg,
>>> -				   struct arch_hw_breakpoint_ctrl *ctrl)
>>> -{
>>> -	ctrl->enabled	= reg & 0x1;
>>> -	reg >>= 1;
>>> -	ctrl->privilege	= reg & 0x3;
>>> -	reg >>= 2;
>>> -	ctrl->type	= reg & 0x3;
>>> -	reg >>= 2;
>>> -	ctrl->len	= reg & 0xff;
>>> -}
>>> -
>>>  /* Breakpoint */
>>>  #define ARM_BREAKPOINT_EXECUTE	0
>>>  
>>> @@ -62,6 +45,7 @@ static inline void decode_ctrl_reg(u32 reg,
>>>  #define AARCH64_ESR_ACCESS_MASK	(1 << 6)
>>>  
>>>  /* Privilege Levels */
>>> +#define AARCH64_BREAKPOINT_EL2	0
>>>  #define AARCH64_BREAKPOINT_EL1	1
>>>  #define AARCH64_BREAKPOINT_EL0	2
>>>  
>>> @@ -76,6 +60,35 @@ static inline void decode_ctrl_reg(u32 reg,
>>>  #define ARM_KERNEL_STEP_ACTIVE	1
>>>  #define ARM_KERNEL_STEP_SUSPEND	2
>>>  
>>> +#define DBG_HMC_HYP		(1 << 13)
>>> +#define DBG_SSC_HYP		(3 << 14)
>>
>> Why do we need to touch the SSC field at all?
>>
>>> +
>>> +static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
>>> +{
>>> +	u32 val = (ctrl.len << 5) | (ctrl.type << 3) | ctrl.enabled;
>>> +
>>> +	if (is_kernel_in_hyp_mode() && ctrl.privilege == AARCH64_BREAKPOINT_EL1)
>>> +		val |= DBG_HMC_HYP | DBG_SSC_HYP | (AARCH64_BREAKPOINT_EL2 << 1);
>>
>> I don't think this is correct. We want to allow, for example, a userspace
>> watchpoint to fire thanks to something like put_user, so the encoding
>> really needs to build up the PMC field (like we do already), then orr in
>> the HMC field.
> 
> Hmm, I got my arm and my arm64 mixed up here. For the latter, we don't
> actually support EL0+EL1 watchpoints, but I still think that the
> {HMC,SSC,PMC} encoding of {1,00,xx} is cleaner.

Indeed. So with that in mind, I ended up with the following patch, which is much simpler than the previous one:

diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
index 9732908..115ea2a 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -18,6 +18,7 @@
 
 #include <asm/cputype.h>
 #include <asm/cpufeature.h>
+#include <asm/virt.h>
 
 #ifdef __KERNEL__
 
@@ -35,10 +36,21 @@ struct arch_hw_breakpoint {
 	struct arch_hw_breakpoint_ctrl ctrl;
 };
 
+/* Privilege Levels */
+#define AARCH64_BREAKPOINT_EL1	1
+#define AARCH64_BREAKPOINT_EL0	2
+
+#define DBG_HMC_HYP		(1 << 13)
+
 static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
 {
-	return (ctrl.len << 5) | (ctrl.type << 3) | (ctrl.privilege << 1) |
+	u32 val = (ctrl.len << 5) | (ctrl.type << 3) | (ctrl.privilege << 1) |
 		ctrl.enabled;
+
+	if (is_kernel_in_hyp_mode() && ctrl.privilege == AARCH64_BREAKPOINT_EL1)
+		val |= DBG_HMC_HYP;
+
+	return val;
 }
 
 static inline void decode_ctrl_reg(u32 reg,
@@ -61,10 +73,6 @@ static inline void decode_ctrl_reg(u32 reg,
 #define ARM_BREAKPOINT_STORE	2
 #define AARCH64_ESR_ACCESS_MASK	(1 << 6)
 
-/* Privilege Levels */
-#define AARCH64_BREAKPOINT_EL1	1
-#define AARCH64_BREAKPOINT_EL0	2
-
 /* Lengths */
 #define ARM_BREAKPOINT_LEN_1	0x1
 #define ARM_BREAKPOINT_LEN_2	0x3


Thanks,
	
	M.
-- 
Jazz is not dead. It just smells funny...


From sudeep.holla at arm.com  Tue Feb 16 01:56:54 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Tue, 16 Feb 2016 09:56:54 +0000
Subject: [PATCH] ARM: dts: r8a7794: replace gpio-key,wakeup with
 wakeup-source property
In-Reply-To: <1455572925-27697-1-git-send-email-horms+renesas@verge.net.au>
References: <1455572925-27697-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <56C2F266.5030709@arm.com>



On 15/02/16 21:48, Simon Horman wrote:
> Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
> check for/support the legacy "gpio-key,wakeup" boolean property to
> enable gpio buttons as wakeup source, "wakeup-source" is the new
> standard binding.
>
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property in order to avoid any futher copy-paste
> duplication.
>
> Changelog text from a similar patch by Sudeep Holla.
>
> Cc: Sudeep Holla <sudeep.holla at arm.com>

Thanks for doing this, not sure how I missed it, was this merged in v4.5?

Acked-by: Sudeep Holla <sudeep.holla at arm.com>

-- 
Regards,
Sudeep


From wens at csie.org  Tue Feb 16 01:59:11 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Tue, 16 Feb 2016 17:59:11 +0800
Subject: [PATCH 1/3] clk: sunxi: improve mux_clk error handling and
 reporting
In-Reply-To: <56C2EFD5.5080604@arm.com>
References: <1455289913-29514-1-git-send-email-andre.przywara@arm.com>
 <1455289913-29514-2-git-send-email-andre.przywara@arm.com>
 <CAGb2v65hxNiY8XAL=yBbV4qazscJd+six432CKWAm+GfM6bd2Q@mail.gmail.com>
 <56C2EFD5.5080604@arm.com>
Message-ID: <CAGb2v658dow+qqPdq_G7NjWz72rvhYE_Bn23Z9xK9cpeBR94-Q@mail.gmail.com>

On Tue, Feb 16, 2016 at 5:45 PM, Andre Przywara <andre.przywara at arm.com> wrote:
> Hi Chen-Yu,
>
> On 13/02/16 02:44, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Fri, Feb 12, 2016 at 11:11 PM, Andre Przywara <andre.przywara at arm.com> wrote:
>>> We now catch and report a failing ioremap, also a failure in the final
>>> step of the clock registration is now handled and reported.
>>> Also warnings are turned into errors.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>>> ---
>>>  drivers/clk/sunxi/clk-sunxi.c | 19 +++++++++++++------
>>>  1 file changed, 13 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>>> index 49ce283..361f396 100644
>>> --- a/drivers/clk/sunxi/clk-sunxi.c
>>> +++ b/drivers/clk/sunxi/clk-sunxi.c
>>> @@ -690,11 +690,15 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
>>>         int i;
>>>
>>>         reg = of_iomap(node, 0);
>>> +       if (!reg) {
>>> +               pr_err("Could not map registers for mux-clk: %s\n", node->name);
>>
>> of_node_full_name(node->name) is better. node->name is almost always "clk",
>> which is useless. (Unless someone goes through the dts files to replace all
>> of them.)
>
> Good point. I both fixed the code here as well as amended the node names
> in the A64 DT.
>
>>
>>> +               return NULL;
>>> +       }
>>>
>>>         i = of_clk_parent_fill(node, parents, SUNXI_MAX_PARENTS);
>>>         if (of_property_read_string(node, "clock-output-names", &clk_name)) {
>>> -               pr_warn("%s: could not read clock-output-names for \"%s\"\n",
>>> -                       __func__, clk_name);
>>> +               pr_err("%s: could not read clock-output-names for \"%s\"\n",
>>> +                      __func__, clk_name);
>>
>> Same here. clk_name defaults to node->name. If you could, please replace it.
>
> Really? Isn't clk_name directly from the DT clock-output-names strings here?

It fills it from the DT clock-output-names in the of_property_read_string()
call in the if here. If that failed, obviously something was wrong with
the DT clock-output-names strings. :)

>
>>>                 goto out_unmap;
>>>         }
>>>
>>> @@ -704,14 +708,17 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
>>>                                0, &clk_lock);
>>>
>>>         if (IS_ERR(clk)) {
>>> -               pr_warn("%s: failed to register mux clock %s: %ld\n", __func__,
>>> -                       clk_name, PTR_ERR(clk));
>>> +               pr_err("%s: failed to register mux clock %s: %ld\n", __func__,
>>> +                      clk_name, PTR_ERR(clk));
>>>                 goto out_unmap;
>>>         }
>>>
>>> -       of_clk_add_provider(node, of_clk_src_simple_get, clk);
>>> +       if (!of_clk_add_provider(node, of_clk_src_simple_get, clk))
>>> +               return clk;
>>> +
>>> +       pr_err("%s: failed to add clock provider for %s\n", __func__, clk_name);
>>>
>>> -       return clk;
>>
>> I'd have all the error path in ifs, and have the normal return path
>> here for consistency.
>> But I guess this works as well.
>
> Yeah, I wanted to skip that single goto ;-)
> But I changed it now as you said and it indeed looks more reasonable.
>
> I took the freedom of applying the comments to the other patches too.

Thanks!
ChenYu

>
> Will send out a v2 in a minute.
>
> Thanks for looking!
> Andre.
>
>>
>> Thanks!
>> ChenYu
>>
>>> +       clk_unregister_divider(clk);
>>>
>>>  out_unmap:
>>>         iounmap(reg);
>>> --
>>> 2.6.4
>>>
>>


From maxime.ripard at free-electrons.com  Tue Feb 16 02:02:17 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 16 Feb 2016 11:02:17 +0100
Subject: [PATCH 1/3] clk: sunxi: improve mux_clk error handling and
 reporting
In-Reply-To: <56C2EFD5.5080604@arm.com>
References: <1455289913-29514-1-git-send-email-andre.przywara@arm.com>
 <1455289913-29514-2-git-send-email-andre.przywara@arm.com>
 <CAGb2v65hxNiY8XAL=yBbV4qazscJd+six432CKWAm+GfM6bd2Q@mail.gmail.com>
 <56C2EFD5.5080604@arm.com>
Message-ID: <20160216100217.GK4344@lukather>

On Tue, Feb 16, 2016 at 09:45:57AM +0000, Andre Przywara wrote:
> Hi Chen-Yu,
> 
> On 13/02/16 02:44, Chen-Yu Tsai wrote:
> > Hi,
> > 
> > On Fri, Feb 12, 2016 at 11:11 PM, Andre Przywara <andre.przywara at arm.com> wrote:
> >> We now catch and report a failing ioremap, also a failure in the final
> >> step of the clock registration is now handled and reported.
> >> Also warnings are turned into errors.
> >>
> >> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> >> ---
> >>  drivers/clk/sunxi/clk-sunxi.c | 19 +++++++++++++------
> >>  1 file changed, 13 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> >> index 49ce283..361f396 100644
> >> --- a/drivers/clk/sunxi/clk-sunxi.c
> >> +++ b/drivers/clk/sunxi/clk-sunxi.c
> >> @@ -690,11 +690,15 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
> >>         int i;
> >>
> >>         reg = of_iomap(node, 0);
> >> +       if (!reg) {
> >> +               pr_err("Could not map registers for mux-clk: %s\n", node->name);
> > 
> > of_node_full_name(node->name) is better. node->name is almost always "clk",
> > which is useless. (Unless someone goes through the dts files to replace all
> > of them.)
> 
> Good point. I both fixed the code here as well as amended the node names
> in the A64 DT.

I'm not sure what there is to amend in the DTSI. The node name is
defined as the class or function of the device, so all clocks should
be called clk@<something>.

This doesn't work for clocks that don't have a meaningful unit address
(like the oscillators), but it should be the exception, rather than
the norm.

> 
> > 
> >> +               return NULL;
> >> +       }
> >>
> >>         i = of_clk_parent_fill(node, parents, SUNXI_MAX_PARENTS);
> >>         if (of_property_read_string(node, "clock-output-names", &clk_name)) {
> >> -               pr_warn("%s: could not read clock-output-names for \"%s\"\n",
> >> -                       __func__, clk_name);
> >> +               pr_err("%s: could not read clock-output-names for \"%s\"\n",
> >> +                      __func__, clk_name);
> > 
> > Same here. clk_name defaults to node->name. If you could, please replace it.
> 
> Really? Isn't clk_name directly from the DT clock-output-names strings here?

Only if there is a clock-output-names property in the node. If not,
the string will not be modified by of_property_read_string, and you'll
default to the initial value of clk_name, in this case node->name or
node->full_name.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/bda9826e/attachment.sig>

From andre.przywara at arm.com  Tue Feb 16 02:04:39 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 16 Feb 2016 10:04:39 +0000
Subject: [PATCH 1/3] clk: sunxi: improve mux_clk error handling and
 reporting
In-Reply-To: <CAGb2v658dow+qqPdq_G7NjWz72rvhYE_Bn23Z9xK9cpeBR94-Q@mail.gmail.com>
References: <1455289913-29514-1-git-send-email-andre.przywara@arm.com>
 <1455289913-29514-2-git-send-email-andre.przywara@arm.com>
 <CAGb2v65hxNiY8XAL=yBbV4qazscJd+six432CKWAm+GfM6bd2Q@mail.gmail.com>
 <56C2EFD5.5080604@arm.com>
 <CAGb2v658dow+qqPdq_G7NjWz72rvhYE_Bn23Z9xK9cpeBR94-Q@mail.gmail.com>
Message-ID: <56C2F437.8020806@arm.com>

Hi,

On 16/02/16 09:59, Chen-Yu Tsai wrote:
> On Tue, Feb 16, 2016 at 5:45 PM, Andre Przywara <andre.przywara at arm.com> wrote:
>> Hi Chen-Yu,
>>
>> On 13/02/16 02:44, Chen-Yu Tsai wrote:
>>> Hi,
>>>
>>> On Fri, Feb 12, 2016 at 11:11 PM, Andre Przywara <andre.przywara at arm.com> wrote:
>>>> We now catch and report a failing ioremap, also a failure in the final
>>>> step of the clock registration is now handled and reported.
>>>> Also warnings are turned into errors.
>>>>
>>>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>>>> ---
>>>>  drivers/clk/sunxi/clk-sunxi.c | 19 +++++++++++++------
>>>>  1 file changed, 13 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>>>> index 49ce283..361f396 100644
>>>> --- a/drivers/clk/sunxi/clk-sunxi.c
>>>> +++ b/drivers/clk/sunxi/clk-sunxi.c
>>>> @@ -690,11 +690,15 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
>>>>         int i;
>>>>
>>>>         reg = of_iomap(node, 0);
>>>> +       if (!reg) {
>>>> +               pr_err("Could not map registers for mux-clk: %s\n", node->name);
>>>
>>> of_node_full_name(node->name) is better. node->name is almost always "clk",
>>> which is useless. (Unless someone goes through the dts files to replace all
>>> of them.)
>>
>> Good point. I both fixed the code here as well as amended the node names
>> in the A64 DT.
>>
>>>
>>>> +               return NULL;
>>>> +       }
>>>>
>>>>         i = of_clk_parent_fill(node, parents, SUNXI_MAX_PARENTS);
>>>>         if (of_property_read_string(node, "clock-output-names", &clk_name)) {
>>>> -               pr_warn("%s: could not read clock-output-names for \"%s\"\n",
>>>> -                       __func__, clk_name);
>>>> +               pr_err("%s: could not read clock-output-names for \"%s\"\n",
>>>> +                      __func__, clk_name);
>>>
>>> Same here. clk_name defaults to node->name. If you could, please replace it.
>>
>> Really? Isn't clk_name directly from the DT clock-output-names strings here?
> 
> It fills it from the DT clock-output-names in the of_property_read_string()
> call in the if here. If that failed, obviously something was wrong with
> the DT clock-output-names strings. :)

Of course! I shouldn't write stuff that early in the morning ...

Cheers,
Andre.

>>
>>>>                 goto out_unmap;
>>>>         }
>>>>
>>>> @@ -704,14 +708,17 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
>>>>                                0, &clk_lock);
>>>>
>>>>         if (IS_ERR(clk)) {
>>>> -               pr_warn("%s: failed to register mux clock %s: %ld\n", __func__,
>>>> -                       clk_name, PTR_ERR(clk));
>>>> +               pr_err("%s: failed to register mux clock %s: %ld\n", __func__,
>>>> +                      clk_name, PTR_ERR(clk));
>>>>                 goto out_unmap;
>>>>         }
>>>>
>>>> -       of_clk_add_provider(node, of_clk_src_simple_get, clk);
>>>> +       if (!of_clk_add_provider(node, of_clk_src_simple_get, clk))
>>>> +               return clk;
>>>> +
>>>> +       pr_err("%s: failed to add clock provider for %s\n", __func__, clk_name);
>>>>
>>>> -       return clk;
>>>
>>> I'd have all the error path in ifs, and have the normal return path
>>> here for consistency.
>>> But I guess this works as well.
>>
>> Yeah, I wanted to skip that single goto ;-)
>> But I changed it now as you said and it indeed looks more reasonable.
>>
>> I took the freedom of applying the comments to the other patches too.
> 
> Thanks!
> ChenYu
> 
>>
>> Will send out a v2 in a minute.
>>
>> Thanks for looking!
>> Andre.
>>
>>>
>>> Thanks!
>>> ChenYu
>>>
>>>> +       clk_unregister_divider(clk);
>>>>
>>>>  out_unmap:
>>>>         iounmap(reg);
>>>> --
>>>> 2.6.4
>>>>
>>>
> 


From vladimir.murzin at arm.com  Tue Feb 16 02:08:06 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 10:08:06 +0000
Subject: [PATCH v3 01/10] dt-bindings: document the MPS2 timer bindings
In-Reply-To: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1455617295-23736-2-git-send-email-vladimir.murzin@arm.com>

This adds documentation of device tree bindings for the
timers found on ARM MPS2 platform.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/timer/arm,mps2-timer.txt   |   28 ++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/arm,mps2-timer.txt

diff --git a/Documentation/devicetree/bindings/timer/arm,mps2-timer.txt b/Documentation/devicetree/bindings/timer/arm,mps2-timer.txt
new file mode 100644
index 0000000..48f84d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/arm,mps2-timer.txt
@@ -0,0 +1,28 @@
+ARM MPS2 timer
+
+The MPS2 platform has simple general-purpose 32 bits timers.
+
+Required properties:
+- compatible	: Should be "arm,mps2-timer"
+- reg		: Address and length of the register set
+- interrupts	: Reference to the timer interrupt
+
+Required clocking property, have to be one of:
+- clocks	  : The input clock of the timer
+- clock-frequency : The rate in HZ in input of the ARM MPS2 timer
+
+Examples:
+
+timer1: mps2-timer at 40000000 {
+	compatible = "arm,mps2-timer";
+	reg = <0x40000000 0x1000>;
+	interrupts = <8>;
+	clocks = <&sysclk>;
+};
+
+timer2: mps2-timer at 40001000 {
+	compatible = "arm,mps2-timer";
+	reg = <0x40001000 0x1000>;
+	interrupts = <9>;
+	clock-frequency = <25000000>;
+};
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 16 02:08:05 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 10:08:05 +0000
Subject: [PATCH v3 00/10] Support for Cortex-M Prototyping System
Message-ID: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>

Hi,

This patch series provide the basic support for running ucLinux on V2M-MPS2
platform.

With these patches applied ucLinux can be run on both HW and FVP models
with Cortex-M3/M4/M7 configurations.

Board description:

http://infocenter.arm.com/help/topic/com.arm.doc.100112_0100_03_en/arm_versatile_express_cortex_m_prototyping_system_(v2m_mps2)_technical_reference_manual_100112_0100_03_en.pdf

Application notes (cover Cortex-M3/M4/M7):

http://infocenter.arm.com/help/topic/com.arm.doc.dai0385a/DAI0385A_cortex_m3_on_v2m_mps2.pdf
http://infocenter.arm.com/help/topic/com.arm.doc.dai0386a/DAI0386A_cortex_m4_on_v2m_mps2.pdf
http://infocenter.arm.com/help/topic/com.arm.doc.dai0399a/DAI0399A_cortex_m7_on_v2m_mps2.pdf
http://infocenter.arm.com/help/topic/com.arm.doc.dai0400a/DAI0400A_cortex_m7_on_v2m_mps2.pdf

Cortex-M System Design Kit (referenced as CMDK from documents above):

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0479c/DDI0479C_cortex_m_system_design_kit_r1p0_trm.pdf

I'd be happy to hear any feedback/comments on this series!

Changelog:
  v2  -> v3:
      - rebased on 4.5-rc4
      - fixes for mps2-timer per Thomas
      - swicthed back to ttyMPS naming per Greg

  v1  -> v2:
      - rebased on 4.5-rc2
      - fixes for mps2-timer per Daniel and Rob (added Ack from Daniel)
      - fixes for mps2-uart per Greg and Andy

  RFC -> v1:
      - dropped RFC tag
      - rebased on 4.4-rc3
      - added Acks from Rob
      - updated mps2-timer per Daniel
      - fixed build failures reported by 0-DAY kernel test infrastructure

Thanks!

Vladimir Murzin (10):
  dt-bindings: document the MPS2 timer bindings
  clockevents/drivers: add MPS2 Timer driver
  dt-bindings: document the MPS2 UART bindings
  serial: mps2-uart: add MPS2 UART driver
  serial: mps2-uart: add support for early console
  ARM: mps2: introduce MPS2 platform
  ARM: mps2: add low-level debug support
  ARM: configs: add MPS2 defconfig
  ARM: dts: introduce MPS2 AN385/AN386
  ARM: dts: introduce MPS2 AN399/AN400

 .../devicetree/bindings/serial/arm,mps2-uart.txt   |   22 +
 .../devicetree/bindings/timer/arm,mps2-timer.txt   |   28 +
 arch/arm/Kconfig                                   |    8 +
 arch/arm/Kconfig.debug                             |   12 +-
 arch/arm/Makefile                                  |    1 +
 arch/arm/boot/dts/Makefile                         |    3 +
 arch/arm/boot/dts/mps2-an385.dts                   |   90 +++
 arch/arm/boot/dts/mps2-an399.dts                   |   92 +++
 arch/arm/boot/dts/mps2.dtsi                        |  227 ++++++++
 arch/arm/configs/mps2_defconfig                    |  112 ++++
 arch/arm/include/debug/mps2.S                      |   27 +
 arch/arm/mach-mps2/Makefile                        |    1 +
 arch/arm/mach-mps2/Makefile.boot                   |    3 +
 arch/arm/mach-mps2/dtmachine.c                     |   21 +
 drivers/clocksource/Kconfig                        |    6 +
 drivers/clocksource/Makefile                       |    1 +
 drivers/clocksource/mps2-timer.c                   |  275 +++++++++
 drivers/tty/serial/Kconfig                         |   13 +
 drivers/tty/serial/Makefile                        |    1 +
 drivers/tty/serial/mps2-uart.c                     |  614 ++++++++++++++++++++
 include/uapi/linux/serial_core.h                   |    3 +
 21 files changed, 1559 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/serial/arm,mps2-uart.txt
 create mode 100644 Documentation/devicetree/bindings/timer/arm,mps2-timer.txt
 create mode 100644 arch/arm/boot/dts/mps2-an385.dts
 create mode 100644 arch/arm/boot/dts/mps2-an399.dts
 create mode 100644 arch/arm/boot/dts/mps2.dtsi
 create mode 100644 arch/arm/configs/mps2_defconfig
 create mode 100644 arch/arm/include/debug/mps2.S
 create mode 100644 arch/arm/mach-mps2/Makefile
 create mode 100644 arch/arm/mach-mps2/Makefile.boot
 create mode 100644 arch/arm/mach-mps2/dtmachine.c
 create mode 100644 drivers/clocksource/mps2-timer.c
 create mode 100644 drivers/tty/serial/mps2-uart.c

-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 16 02:08:08 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 10:08:08 +0000
Subject: [PATCH v3 03/10] dt-bindings: document the MPS2 UART bindings
In-Reply-To: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1455617295-23736-4-git-send-email-vladimir.murzin@arm.com>

This adds documentation of device tree bindings for the
UART found on ARM MPS2 platform

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
Acked-by: Rob Herring <robh at kernel.org
---
 .../devicetree/bindings/serial/arm,mps2-uart.txt   |   22 ++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/arm,mps2-uart.txt

diff --git a/Documentation/devicetree/bindings/serial/arm,mps2-uart.txt b/Documentation/devicetree/bindings/serial/arm,mps2-uart.txt
new file mode 100644
index 0000000..b3f7cb1
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/arm,mps2-uart.txt
@@ -0,0 +1,22 @@
+ARM MPS2 UART
+
+Required properties:
+- compatible	: Should be "arm,mps2-uart"
+- reg		: Address and length of the register set
+- interrupts	: Reference to the UART RX, TX and overrun interrupts
+
+Required clocking property:
+- clocks	  : The input clock of the UART
+
+
+Examples:
+
+uart0: serial at 40004000 {
+	compatible = "arm,mps2-uart";
+	reg = <0x40004000 0x1000>;
+	interrupts = <0 1 12>;
+	clocks = <&sysclk>;
+};
+
+
+
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 16 02:08:07 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 10:08:07 +0000
Subject: [PATCH v3 02/10] clockevents/drivers: add MPS2 Timer driver
In-Reply-To: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1455617295-23736-3-git-send-email-vladimir.murzin@arm.com>

MPS2 platform has simple 32 bits general purpose countdown timers.

The driver uses the first detected timer as a clocksource and the rest
of the timers as a clockevent

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
Acked-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 drivers/clocksource/Kconfig      |    6 +
 drivers/clocksource/Makefile     |    1 +
 drivers/clocksource/mps2-timer.c |  275 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 282 insertions(+)
 create mode 100644 drivers/clocksource/mps2-timer.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 33db740..7ce3892 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -185,6 +185,12 @@ config CLKSRC_STM32
 	depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
 	select CLKSRC_MMIO
 
+config CLKSRC_MPS2
+	bool "Clocksource for MPS2 SoCs" if COMPILE_TEST
+	depends on GENERIC_SCHED_CLOCK
+	select CLKSRC_MMIO
+	select CLKSRC_OF
+
 config ARM_ARCH_TIMER
 	bool
 	select CLKSRC_OF if OF
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index dc2b899..b0a3c96 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_CLKSRC_EFM32)	+= time-efm32.o
 obj-$(CONFIG_CLKSRC_STM32)	+= timer-stm32.o
 obj-$(CONFIG_CLKSRC_EXYNOS_MCT)	+= exynos_mct.o
 obj-$(CONFIG_CLKSRC_LPC32XX)	+= time-lpc32xx.o
+obj-$(CONFIG_CLKSRC_MPS2)	+= mps2-timer.o
 obj-$(CONFIG_CLKSRC_SAMSUNG_PWM)	+= samsung_pwm_timer.o
 obj-$(CONFIG_FSL_FTM_TIMER)	+= fsl_ftm_timer.o
 obj-$(CONFIG_VF_PIT_TIMER)	+= vf_pit_timer.o
diff --git a/drivers/clocksource/mps2-timer.c b/drivers/clocksource/mps2-timer.c
new file mode 100644
index 0000000..fe73fd7
--- /dev/null
+++ b/drivers/clocksource/mps2-timer.c
@@ -0,0 +1,275 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.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.
+ *
+ */
+
+#define pr_fmt(fmt)	KBUILD_MODNAME ": " fmt
+
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/clocksource.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/of_address.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/sched_clock.h>
+#include <linux/slab.h>
+
+#define TIMER_CTRL		0x0
+#define TIMER_CTRL_ENABLE	BIT(0)
+#define TIMER_CTRL_IE		BIT(3)
+
+#define TIMER_VALUE		0x4
+#define TIMER_RELOAD		0x8
+#define TIMER_INT		0xc
+
+struct clockevent_mps2 {
+	void __iomem *reg;
+	u32 clock_count_per_tick;
+	struct clock_event_device clkevt;
+};
+
+static void __iomem *sched_clock_base;
+
+static u64 notrace mps2_sched_read(void)
+{
+        return ~readl_relaxed(sched_clock_base + TIMER_VALUE);
+}
+
+static inline struct clockevent_mps2 *to_mps2_clkevt(struct clock_event_device *c)
+{
+	return container_of(c, struct clockevent_mps2, clkevt);
+}
+
+static void clockevent_mps2_writel(u32 val, struct clock_event_device *c, u32 offset)
+{
+	writel_relaxed(val, to_mps2_clkevt(c)->reg + offset);
+}
+
+static int mps2_timer_shutdown(struct clock_event_device *ce)
+{
+	clockevent_mps2_writel(0, ce, TIMER_RELOAD);
+	clockevent_mps2_writel(0, ce, TIMER_CTRL);
+
+	return 0;
+}
+
+static int mps2_timer_set_next_event(unsigned long next, struct clock_event_device *ce)
+{
+	clockevent_mps2_writel(next, ce, TIMER_VALUE);
+	clockevent_mps2_writel(TIMER_CTRL_IE | TIMER_CTRL_ENABLE, ce, TIMER_CTRL);
+
+	return 0;
+}
+
+static int mps2_timer_set_periodic(struct clock_event_device *ce)
+{
+	u32 clock_count_per_tick = to_mps2_clkevt(ce)->clock_count_per_tick;
+
+	clockevent_mps2_writel(clock_count_per_tick, ce, TIMER_RELOAD);
+	clockevent_mps2_writel(clock_count_per_tick, ce, TIMER_VALUE);
+	clockevent_mps2_writel(TIMER_CTRL_IE | TIMER_CTRL_ENABLE, ce, TIMER_CTRL);
+
+	return 0;
+}
+
+static irqreturn_t mps2_timer_interrupt(int irq, void *dev_id)
+{
+	struct clockevent_mps2 *ce = dev_id;
+	u32 status = readl_relaxed(ce->reg + TIMER_INT);
+
+	if (!status) {
+		pr_warn("spurious interrupt\n");
+		return IRQ_NONE;
+	}
+
+	writel_relaxed(1, ce->reg + TIMER_INT);
+
+	ce->clkevt.event_handler(&ce->clkevt);
+
+	return IRQ_HANDLED;
+}
+
+static int __init mps2_clockevent_init(struct device_node *np)
+{
+	void __iomem *base;
+	struct clk *clk = NULL;
+	struct clockevent_mps2 *ce;
+	u32 rate;
+	int irq, ret;
+	const char *name = "mps2-clkevt";
+
+	ret = of_property_read_u32(np, "clock-frequency", &rate);
+	if (ret) {
+		clk = of_clk_get(np, 0);
+		if (IS_ERR(clk)) {
+			ret = PTR_ERR(clk);
+			pr_err("failed to get clock for clockevent: %d\n", ret);
+			goto out;
+		}
+
+		ret = clk_prepare_enable(clk);
+		if (ret) {
+			pr_err("failed to enable clock for clockevent: %d\n", ret);
+			goto out_clk_put;
+		}
+
+		rate = clk_get_rate(clk);
+	}
+
+	base = of_iomap(np, 0);
+	if (!base) {
+		ret = -EADDRNOTAVAIL;
+		pr_err("failed to map register for clockevent: %d\n", ret);
+		goto out_clk_disable;
+	}
+
+	irq = irq_of_parse_and_map(np, 0);
+	if (!irq) {
+		ret = -ENOENT;
+		pr_err("failed to get irq for clockevent: %d\n", ret);
+		goto out_iounmap;
+	}
+
+	ce = kzalloc(sizeof(struct clockevent_mps2), GFP_KERNEL);
+	if (!ce) {
+		ret = -ENOMEM;
+		goto out_iounmap;
+	}
+
+	ce->reg = base;
+	ce->clock_count_per_tick = DIV_ROUND_CLOSEST(rate, HZ);
+	ce->clkevt.irq = irq;
+	ce->clkevt.name = name;
+	ce->clkevt.rating = 200;
+	ce->clkevt.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
+	ce->clkevt.cpumask = cpu_possible_mask;
+	ce->clkevt.set_state_shutdown	= mps2_timer_shutdown,
+	ce->clkevt.set_state_periodic	= mps2_timer_set_periodic,
+	ce->clkevt.set_state_oneshot	= mps2_timer_shutdown,
+	ce->clkevt.set_next_event	= mps2_timer_set_next_event;
+
+	/* Ensure timer is disabled */
+	writel_relaxed(0, base + TIMER_CTRL);
+
+	ret = request_irq(irq, mps2_timer_interrupt, IRQF_TIMER, name, ce);
+	if (ret) {
+		pr_err("failed to request irq for clockevent: %d\n", ret);
+		goto out_kfree;
+	}
+
+	clockevents_config_and_register(&ce->clkevt, rate, 0xf, 0xffffffff);
+
+	return 0;
+
+out_kfree:
+	kfree(ce);
+out_iounmap:
+	iounmap(base);
+out_clk_disable:
+	/* clk_{disable, unprepare, put}() can handle NULL as a parameter */
+	clk_disable_unprepare(clk);
+out_clk_put:
+	clk_put(clk);
+out:
+	return ret;
+}
+
+static int __init mps2_clocksource_init(struct device_node *np)
+{
+	void __iomem *base;
+	struct clk *clk = NULL;
+	u32 rate;
+	int ret;
+	const char *name = "mps2-clksrc";
+
+	ret = of_property_read_u32(np, "clock-frequency", &rate);
+	if (ret) {
+		clk = of_clk_get(np, 0);
+		if (IS_ERR(clk)) {
+			ret = PTR_ERR(clk);
+			pr_err("failed to get clock for clocksource: %d\n", ret);
+			goto out;
+		}
+
+		ret = clk_prepare_enable(clk);
+		if (ret) {
+			pr_err("failed to enable clock for clocksource: %d\n", ret);
+			goto out_clk_put;
+		}
+
+		rate = clk_get_rate(clk);
+	}
+
+	base = of_iomap(np, 0);
+	if (!base) {
+		ret = -EADDRNOTAVAIL;
+		pr_err("failed to map register for clocksource: %d\n", ret);
+		goto out_clk_disable;
+	}
+
+	/* Ensure timer is disabled */
+	writel_relaxed(0, base + TIMER_CTRL);
+
+	/* ... and set it up as free-running clocksource */
+	writel_relaxed(0xffffffff, base + TIMER_VALUE);
+	writel_relaxed(0xffffffff, base + TIMER_RELOAD);
+
+	writel_relaxed(TIMER_CTRL_ENABLE, base + TIMER_CTRL);
+
+	ret = clocksource_mmio_init(base + TIMER_VALUE, name,
+				    rate, 200, 32,
+				    clocksource_mmio_readl_down);
+	if (ret) {
+		pr_err("failed to init clocksource: %d\n", ret);
+		goto out_iounmap;
+	}
+
+	sched_clock_base = base;
+	sched_clock_register(mps2_sched_read, 32, rate);
+
+	return 0;
+
+out_iounmap:
+	iounmap(base);
+out_clk_disable:
+	/* clk_{disable, unprepare, put}() can handle NULL as a parameter */
+	clk_disable_unprepare(clk);
+out_clk_put:
+	clk_put(clk);
+out:
+	return ret;
+}
+
+static void __init mps2_timer_init(struct device_node *np)
+{
+	static int has_clocksource, has_clockevent;
+	int ret;
+
+	if (!has_clocksource) {
+		ret = mps2_clocksource_init(np);
+		if (!ret) {
+			has_clocksource = 1;
+			return;
+		}
+	}
+
+	if (!has_clockevent) {
+		ret = mps2_clockevent_init(np);
+		if (!ret) {
+			has_clockevent = 1;
+			return;
+		}
+	}
+}
+
+CLOCKSOURCE_OF_DECLARE(mps2_timer, "arm,mps2-timer", mps2_timer_init);
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 16 02:08:09 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 10:08:09 +0000
Subject: [PATCH v3 04/10] serial: mps2-uart: add MPS2 UART driver
In-Reply-To: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1455617295-23736-5-git-send-email-vladimir.murzin@arm.com>

This driver adds support to the UART controller found on ARM MPS2
platform.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 drivers/tty/serial/Kconfig       |   12 +
 drivers/tty/serial/Makefile      |    1 +
 drivers/tty/serial/mps2-uart.c   |  584 ++++++++++++++++++++++++++++++++++++++
 include/uapi/linux/serial_core.h |    3 +
 4 files changed, 600 insertions(+)
 create mode 100644 drivers/tty/serial/mps2-uart.c

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 39721ec..3a248be 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1450,6 +1450,18 @@ config SERIAL_EFM32_UART
 	  This driver support the USART and UART ports on
 	  Energy Micro's efm32 SoCs.
 
+config SERIAL_MPS2_UART_CONSOLE
+	bool "MPS2 UART console support"
+	depends on SERIAL_MPS2_UART
+	select SERIAL_CORE_CONSOLE
+
+config SERIAL_MPS2_UART
+	bool "MPS2 UART port"
+	depends on ARM || COMPILE_TEST
+	select SERIAL_CORE
+	help
+	  This driver support the UART ports on ARM MPS2.
+
 config SERIAL_EFM32_UART_CONSOLE
 	bool "EFM32 UART/USART console support"
 	depends on SERIAL_EFM32_UART=y
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index b391c9b..1062503 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
 obj-$(CONFIG_SERIAL_MEN_Z135)	+= men_z135_uart.o
 obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
 obj-$(CONFIG_SERIAL_STM32)	+= stm32-usart.o
+obj-$(CONFIG_SERIAL_MPS2_UART)	+= mps2-uart.o
 
 # GPIOLIB helpers for modem control lines
 obj-$(CONFIG_SERIAL_MCTRL_GPIO)	+= serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
new file mode 100644
index 0000000..d97f3a9
--- /dev/null
+++ b/drivers/tty/serial/mps2-uart.c
@@ -0,0 +1,584 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.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.
+ *
+ * TODO: support for SysRq
+ */
+
+#define pr_fmt(fmt)	KBUILD_MODNAME ": " fmt
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/console.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/serial_core.h>
+#include <linux/tty_flip.h>
+#include <linux/types.h>
+
+#define SERIAL_NAME "ttyMPS"
+#define DRIVER_NAME "mps2-uart"
+#define MAKE_NAME(x) (DRIVER_NAME # x)
+
+#define UARTn_DATA				0x00
+
+#define UARTn_STATE				0x04
+#define UARTn_STATE_TX_FULL			BIT(0)
+#define UARTn_STATE_RX_FULL			BIT(1)
+#define UARTn_STATE_TX_OVERRUN			BIT(2)
+#define UARTn_STATE_RX_OVERRUN			BIT(3)
+
+#define UARTn_CTRL				0x08
+#define UARTn_CTRL_TX_ENABLE			BIT(0)
+#define UARTn_CTRL_RX_ENABLE			BIT(1)
+#define UARTn_CTRL_TX_INT_ENABLE		BIT(2)
+#define UARTn_CTRL_RX_INT_ENABLE		BIT(3)
+#define UARTn_CTRL_TX_OVERRUN_INT_ENABLE	BIT(4)
+#define UARTn_CTRL_RX_OVERRUN_INT_ENABLE	BIT(5)
+
+#define UARTn_INT				0x0c
+#define UARTn_INT_TX				BIT(0)
+#define UARTn_INT_RX				BIT(1)
+#define UARTn_INT_TX_OVERRUN			BIT(2)
+#define UARTn_INT_RX_OVERRUN			BIT(3)
+
+#define UARTn_BAUDDIV				0x10
+#define UARTn_BAUDDIV_MASK			GENMASK(20, 0)
+
+/*
+ * Helpers to make typical enable/disable operations more readable.
+ */
+#define UARTn_CTRL_TX_GRP 			(UARTn_CTRL_TX_ENABLE		 |\
+						 UARTn_CTRL_TX_INT_ENABLE	 |\
+						 UARTn_CTRL_TX_OVERRUN_INT_ENABLE)
+
+#define UARTn_CTRL_RX_GRP 			(UARTn_CTRL_RX_ENABLE		 |\
+						 UARTn_CTRL_RX_INT_ENABLE	 |\
+						 UARTn_CTRL_RX_OVERRUN_INT_ENABLE)
+
+#define MPS2_MAX_PORTS				3
+
+struct mps2_uart_port {
+	struct uart_port port;
+	struct clk *clk;
+	unsigned int tx_irq;
+	unsigned int rx_irq;
+};
+
+static inline struct mps2_uart_port *to_mps2_port(struct uart_port *port)
+{
+	return container_of(port, struct mps2_uart_port, port);
+}
+
+static void mps2_uart_write8(struct uart_port *port, u8 val, unsigned off)
+{
+	struct mps2_uart_port *mps_port = to_mps2_port(port);
+
+	writeb(val, mps_port->port.membase + off);
+}
+
+static u8 mps2_uart_read8(struct uart_port *port, unsigned off)
+{
+	struct mps2_uart_port *mps_port = to_mps2_port(port);
+
+	return readb(mps_port->port.membase + off);
+}
+
+static void mps2_uart_write32(struct uart_port *port, u32 val, unsigned off)
+{
+	struct mps2_uart_port *mps_port = to_mps2_port(port);
+
+	writel_relaxed(val, mps_port->port.membase + off);
+}
+
+static unsigned int mps2_uart_tx_empty(struct uart_port *port)
+{
+	u8 status = mps2_uart_read8(port, UARTn_STATE);
+
+	return (status & UARTn_STATE_TX_FULL) ? 0 : TIOCSER_TEMT;
+}
+
+static void mps2_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+}
+
+static unsigned int mps2_uart_get_mctrl(struct uart_port *port)
+{
+	return TIOCM_CAR | TIOCM_CTS | TIOCM_DSR;
+}
+
+static void mps2_uart_stop_tx(struct uart_port *port)
+{
+	u8 control = mps2_uart_read8(port, UARTn_CTRL);
+
+	control &= ~UARTn_CTRL_TX_GRP;
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+}
+
+static void mps2_uart_tx_chars(struct uart_port *port)
+{
+	struct circ_buf *xmit = &port->state->xmit;
+
+	while (!(mps2_uart_read8(port, UARTn_STATE) & UARTn_STATE_TX_FULL)) {
+		if (port->x_char) {
+			mps2_uart_write8(port, port->x_char, UARTn_DATA);
+			port->x_char = 0;
+			port->icount.tx++;
+			continue;
+		}
+
+		if (uart_circ_empty(xmit) || uart_tx_stopped(port))
+			break;
+
+		mps2_uart_write8(port, xmit->buf[xmit->tail], UARTn_DATA);
+		xmit->tail = (xmit->tail + 1) % UART_XMIT_SIZE;
+		port->icount.tx++;
+	}
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+
+	if (uart_circ_empty(xmit))
+		mps2_uart_stop_tx(port);
+}
+
+static void mps2_uart_start_tx(struct uart_port *port)
+{
+	u8 control = mps2_uart_read8(port, UARTn_CTRL);
+
+	control |= UARTn_CTRL_TX_GRP;
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+	mps2_uart_tx_chars(port);
+}
+
+static void mps2_uart_stop_rx(struct uart_port *port)
+{
+	u8 control = mps2_uart_read8(port, UARTn_CTRL);
+
+	control &= ~UARTn_CTRL_RX_GRP;
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+}
+
+static void mps2_uart_break_ctl(struct uart_port *port, int ctl)
+{
+}
+
+static void mps2_uart_rx_chars(struct uart_port *port)
+{
+	struct tty_port *tport = &port->state->port;
+
+	while (mps2_uart_read8(port, UARTn_STATE) & UARTn_STATE_RX_FULL) {
+		u8 rxdata = mps2_uart_read8(port, UARTn_DATA);
+
+		port->icount.rx++;
+		tty_insert_flip_char(&port->state->port, rxdata, TTY_NORMAL);
+	}
+
+	spin_unlock(&port->lock);
+	tty_flip_buffer_push(tport);
+	spin_lock(&port->lock);
+}
+
+static irqreturn_t mps2_uart_rxirq(int irq, void *data)
+{
+
+	struct uart_port *port = data;
+	u8 irqflag = mps2_uart_read8(port, UARTn_INT);
+
+	if (unlikely(!(irqflag & UARTn_INT_RX)))
+		return IRQ_NONE;
+
+	spin_lock(&port->lock);
+
+	mps2_uart_write8(port, UARTn_INT_RX, UARTn_INT);
+	mps2_uart_rx_chars(port);
+
+	spin_unlock(&port->lock);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t mps2_uart_txirq(int irq, void *data)
+{
+	struct uart_port *port = data;
+	u8 irqflag = mps2_uart_read8(port, UARTn_INT);
+
+	if (unlikely(!(irqflag & UARTn_INT_TX)))
+		return IRQ_NONE;
+
+	mps2_uart_write8(port, UARTn_INT_TX, UARTn_INT);
+	mps2_uart_tx_chars(port);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t mps2_uart_oerrirq(int irq, void *data)
+{
+	irqreturn_t handled = IRQ_NONE;
+	struct uart_port *port = data;
+	u8 irqflag = mps2_uart_read8(port, UARTn_INT);
+
+	spin_lock(&port->lock);
+
+	if (irqflag & UARTn_INT_RX_OVERRUN) {
+		struct tty_port *tport = &port->state->port;
+
+		mps2_uart_write8(port, UARTn_INT_RX_OVERRUN, UARTn_INT);
+		tty_insert_flip_char(tport, 0, TTY_OVERRUN);
+		port->icount.overrun++;
+		handled = IRQ_HANDLED;
+	}
+
+	/*
+	 * It's never been seen in practice and it never *should* happen since
+	 * we check if there is enough room in TX buffer before sending data.
+	 * So we keep this check in case something suspicious has happened.
+	 */
+	if (irqflag & UARTn_INT_TX_OVERRUN) {
+		mps2_uart_write8(port, UARTn_INT_TX_OVERRUN, UARTn_INT);
+		dev_warn(port->dev, "unexpected overrun interrupt\n");
+		handled = IRQ_HANDLED;
+	}
+
+	spin_unlock(&port->lock);
+
+	return handled;
+}
+
+static int mps2_uart_startup(struct uart_port *port)
+{
+	struct mps2_uart_port *mps_port = to_mps2_port(port);
+	u8 control = mps2_uart_read8(port, UARTn_CTRL);
+	int ret;
+
+	control &= ~(UARTn_CTRL_RX_GRP | UARTn_CTRL_TX_GRP);
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+
+	ret = request_irq(mps_port->rx_irq, mps2_uart_rxirq, 0,
+			  MAKE_NAME(-rx), mps_port);
+	if (ret) {
+		dev_err(port->dev, "failed to register rxirq (%d)\n", ret);
+		goto err_no_rxirq;
+	}
+
+	ret = request_irq(mps_port->tx_irq, mps2_uart_txirq, 0,
+			  MAKE_NAME(-tx), mps_port);
+	if (ret) {
+		dev_err(port->dev, "failed to register txirq (%d)\n", ret);
+		goto err_no_txirq;
+	}
+
+	ret = request_irq(port->irq, mps2_uart_oerrirq, IRQF_SHARED,
+			  MAKE_NAME(-overrun), mps_port);
+
+	if (ret) {
+		dev_err(port->dev, "failed to register oerrirq (%d)\n", ret);
+	} else {
+		control |= UARTn_CTRL_RX_GRP | UARTn_CTRL_TX_GRP;
+
+		mps2_uart_write8(port, control, UARTn_CTRL);
+
+		return 0;
+	}
+
+	free_irq(mps_port->tx_irq, mps_port);
+err_no_txirq:
+	free_irq(mps_port->rx_irq, mps_port);
+err_no_rxirq:
+	return ret;
+}
+
+static void mps2_uart_shutdown(struct uart_port *port)
+{
+	struct mps2_uart_port *mps_port = to_mps2_port(port);
+	u8 control = mps2_uart_read8(port, UARTn_CTRL);
+
+	control &= ~(UARTn_CTRL_RX_GRP| UARTn_CTRL_TX_GRP);
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+
+	free_irq(mps_port->rx_irq, mps_port);
+	free_irq(mps_port->tx_irq, mps_port);
+	free_irq(port->irq, mps_port);
+}
+
+static void mps2_uart_set_termios(struct uart_port *port,
+	struct ktermios *new, struct ktermios *old)
+{
+	unsigned long flags;
+	unsigned int baud, bauddiv;
+
+	new->c_cflag &= ~(CRTSCTS | CMSPAR);
+	new->c_cflag &= ~CSIZE;
+	new->c_cflag |= CS8;
+	new->c_cflag &= ~PARENB;
+	new->c_cflag &= ~CSTOPB;
+
+	baud = uart_get_baud_rate(port, new, old,
+			DIV_ROUND_CLOSEST(port->uartclk, UARTn_BAUDDIV_MASK),
+			DIV_ROUND_CLOSEST(port->uartclk, 16));
+
+	bauddiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	uart_update_timeout(port, new->c_cflag, baud);
+	mps2_uart_write32(port, bauddiv, UARTn_BAUDDIV);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *mps2_uart_type(struct uart_port *port)
+{
+	return (port->type == PORT_MPS2UART) ? DRIVER_NAME : NULL;
+}
+
+static void mps2_uart_release_port(struct uart_port *port)
+{
+}
+
+static int mps2_uart_request_port(struct uart_port *port)
+{
+	return 0;
+}
+
+static void mps2_uart_config_port(struct uart_port *port, int type)
+{
+	if (type & UART_CONFIG_TYPE && !mps2_uart_request_port(port))
+		port->type = PORT_MPS2UART;
+}
+
+static int mps2_uart_verify_port(struct uart_port *port, struct serial_struct *serinfo)
+{
+	return -EINVAL;
+}
+
+static const struct uart_ops mps2_uart_pops = {
+	.tx_empty = mps2_uart_tx_empty,
+	.set_mctrl = mps2_uart_set_mctrl,
+	.get_mctrl = mps2_uart_get_mctrl,
+	.stop_tx = mps2_uart_stop_tx,
+	.start_tx = mps2_uart_start_tx,
+	.stop_rx = mps2_uart_stop_rx,
+	.break_ctl = mps2_uart_break_ctl,
+	.startup = mps2_uart_startup,
+	.shutdown = mps2_uart_shutdown,
+	.set_termios = mps2_uart_set_termios,
+	.type = mps2_uart_type,
+	.release_port = mps2_uart_release_port,
+	.request_port = mps2_uart_request_port,
+	.config_port = mps2_uart_config_port,
+	.verify_port = mps2_uart_verify_port,
+};
+
+static struct mps2_uart_port mps2_uart_ports[MPS2_MAX_PORTS];
+
+#ifdef CONFIG_SERIAL_MPS2_UART_CONSOLE
+static void mps2_uart_console_putchar(struct uart_port *port, int ch)
+{
+	while (mps2_uart_read8(port, UARTn_STATE) & UARTn_STATE_TX_FULL)
+		cpu_relax();
+
+	mps2_uart_write8(port, ch, UARTn_DATA);
+}
+
+static void mps2_uart_console_write(struct console *co, const char *s, unsigned int cnt)
+{
+	struct uart_port *port = &mps2_uart_ports[co->index].port;
+
+	uart_console_write(port, s, cnt, mps2_uart_console_putchar);
+}
+
+static int mps2_uart_console_setup(struct console *co, char *options)
+{
+	struct mps2_uart_port *mps_port;
+	int baud = 9600;
+	int bits = 8;
+	int parity = 'n';
+	int flow = 'n';
+
+	if (co->index < 0 || co->index >= MPS2_MAX_PORTS)
+		return -ENODEV;
+
+	mps_port = &mps2_uart_ports[co->index];
+
+	if (options)
+		uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+	return uart_set_options(&mps_port->port, co, baud, parity, bits, flow);
+}
+
+static struct uart_driver mps2_uart_driver;
+
+static struct console mps2_uart_console = {
+	.name = SERIAL_NAME,
+	.device = uart_console_device,
+	.write = mps2_uart_console_write,
+	.setup = mps2_uart_console_setup,
+	.flags = CON_PRINTBUFFER,
+	.index = -1,
+	.data = &mps2_uart_driver,
+};
+
+#define MPS2_SERIAL_CONSOLE (&mps2_uart_console)
+
+#else
+#define MPS2_SERIAL_CONSOLE NULL
+#endif
+
+static struct uart_driver mps2_uart_driver = {
+	.driver_name = DRIVER_NAME,
+	.dev_name = SERIAL_NAME,
+	.nr = MPS2_MAX_PORTS,
+	.cons = MPS2_SERIAL_CONSOLE,
+};
+
+static struct mps2_uart_port *mps2_of_get_port(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int id;
+
+	if (!np)
+		return NULL;
+
+	id = of_alias_get_id(np, "serial");
+	if (id < 0)
+		id = 0;
+
+	if (WARN_ON(id >= MPS2_MAX_PORTS))
+		return NULL;
+
+	mps2_uart_ports[id].port.line = id;
+	return &mps2_uart_ports[id];
+}
+
+static int mps2_init_port(struct mps2_uart_port *mps_port,
+			struct platform_device *pdev)
+{
+	int ret;
+	struct resource *res;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mps_port->port.membase = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(mps_port->port.membase))
+		return PTR_ERR(mps_port->port.membase);
+
+	mps_port->port.mapbase = res->start;
+	mps_port->port.mapsize = resource_size(res);
+
+	mps_port->rx_irq = platform_get_irq(pdev, 0);
+	mps_port->tx_irq = platform_get_irq(pdev, 1);
+	mps_port->port.irq = platform_get_irq(pdev, 2);
+
+	mps_port->port.iotype = UPIO_MEM;
+	mps_port->port.flags = UPF_BOOT_AUTOCONF;
+	mps_port->port.fifosize = 1;
+	mps_port->port.ops = &mps2_uart_pops;
+	mps_port->port.dev = &pdev->dev;
+
+	mps_port->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(mps_port->clk))
+		return PTR_ERR(mps_port->clk);
+
+	ret = clk_prepare_enable(mps_port->clk);
+	if (ret)
+		return ret;
+
+	mps_port->port.uartclk = clk_get_rate(mps_port->clk);
+
+	clk_disable_unprepare(mps_port->clk);
+
+	return ret;
+}
+
+static int mps2_serial_probe(struct platform_device *pdev)
+{
+	struct mps2_uart_port *mps_port;
+	int ret;
+
+	mps_port = mps2_of_get_port(pdev);
+	if (!mps_port)
+		return -ENODEV;
+
+	ret = mps2_init_port(mps_port, pdev);
+	if (ret)
+		return ret;
+
+	ret = uart_add_one_port(&mps2_uart_driver, &mps_port->port);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, mps_port);
+
+	return 0;
+}
+
+static int mps2_serial_remove(struct platform_device *pdev)
+{
+	struct mps2_uart_port *mps_port = platform_get_drvdata(pdev);
+
+	uart_remove_one_port(&mps2_uart_driver, &mps_port->port);
+
+	return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id mps2_match[] = {
+	{ .compatible = "arm,mps2-uart", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mps2_match);
+#endif
+
+static struct platform_driver mps2_serial_driver = {
+	.probe = mps2_serial_probe,
+	.remove = mps2_serial_remove,
+
+	.driver = {
+		.name = DRIVER_NAME,
+		.of_match_table = of_match_ptr(mps2_match),
+	},
+};
+
+static int __init mps2_uart_init(void)
+{
+	int ret;
+
+	ret = uart_register_driver(&mps2_uart_driver);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&mps2_serial_driver);
+	if (ret)
+		uart_unregister_driver(&mps2_uart_driver);
+
+	pr_info("MPS2 UART driver initialized\n");
+
+	return ret;
+}
+module_init(mps2_uart_init);
+
+static void __exit mps2_uart_exit(void)
+{
+	platform_driver_unregister(&mps2_serial_driver);
+	uart_unregister_driver(&mps2_uart_driver);
+}
+module_exit(mps2_uart_exit);
+
+MODULE_AUTHOR("Vladimir Murzin <vladimir.murzin at arm.com>");
+MODULE_DESCRIPTION("MPS2 UART driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:" DRIVER_NAME);
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 3e5d757..1fa57bb 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -261,4 +261,7 @@
 /* STM32 USART */
 #define PORT_STM32	113
 
+/* MPS2 UART */
+#define PORT_MPS2UART	114
+
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 16 02:08:11 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 10:08:11 +0000
Subject: [PATCH v3 06/10] ARM: mps2: introduce MPS2 platform
In-Reply-To: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1455617295-23736-7-git-send-email-vladimir.murzin@arm.com>

The Cortex-M Prototyping System (or V2M-MPS2) is designed for
prototyping and evaluation Cortex-M family of processors including the
latest Cortex-M7

It comes with a range of useful peripherals including 8MB single cycle
SRAM, 16MB PSRAM, Ethernet, QSVGA touch screen panel, 4bit RGB VGA
connector, Audio, SPI and GPIO.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 arch/arm/Kconfig                 |    8 ++++++++
 arch/arm/Makefile                |    1 +
 arch/arm/mach-mps2/Makefile      |    1 +
 arch/arm/mach-mps2/Makefile.boot |    3 +++
 arch/arm/mach-mps2/dtmachine.c   |   21 +++++++++++++++++++++
 5 files changed, 34 insertions(+)
 create mode 100644 arch/arm/mach-mps2/Makefile
 create mode 100644 arch/arm/mach-mps2/Makefile.boot
 create mode 100644 arch/arm/mach-mps2/dtmachine.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4f799e5..48fa6c4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -883,6 +883,14 @@ config ARCH_STM32
 	help
 	  Support for STMicroelectronics STM32 processors.
 
+config ARCH_MPS2
+	bool "ARM MPS2 paltform"
+	depends on ARM_SINGLE_ARMV7M
+	select ARM_AMBA
+	select CLKSRC_MPS2
+	help
+	  Support for ARM MPS2 Cortex-M platform.
+
 # Definitions to make life easier
 config ARCH_ACORN
 	bool
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index fe25410..8cd9ec1 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -182,6 +182,7 @@ machine-$(CONFIG_ARCH_LPC18XX)		+= lpc18xx
 machine-$(CONFIG_ARCH_LPC32XX)		+= lpc32xx
 machine-$(CONFIG_ARCH_MESON)		+= meson
 machine-$(CONFIG_ARCH_MMP)		+= mmp
+machine-$(CONFIG_ARCH_MPS2)		+= mps2
 machine-$(CONFIG_ARCH_MOXART)		+= moxart
 machine-$(CONFIG_ARCH_MV78XX0)		+= mv78xx0
 machine-$(CONFIG_ARCH_MVEBU)		+= mvebu
diff --git a/arch/arm/mach-mps2/Makefile b/arch/arm/mach-mps2/Makefile
new file mode 100644
index 0000000..3a74af7
--- /dev/null
+++ b/arch/arm/mach-mps2/Makefile
@@ -0,0 +1 @@
+obj-y += dtmachine.o
diff --git a/arch/arm/mach-mps2/Makefile.boot b/arch/arm/mach-mps2/Makefile.boot
new file mode 100644
index 0000000..eacfc3f
--- /dev/null
+++ b/arch/arm/mach-mps2/Makefile.boot
@@ -0,0 +1,3 @@
+# Empty file waiting for deletion once Makefile.boot isn't needed any more.
+# Patch waits for application at
+# http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7889/1 .
diff --git a/arch/arm/mach-mps2/dtmachine.c b/arch/arm/mach-mps2/dtmachine.c
new file mode 100644
index 0000000..e7ad9c2
--- /dev/null
+++ b/arch/arm/mach-mps2/dtmachine.c
@@ -0,0 +1,21 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.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.
+ *
+ */
+
+#include <asm/mach/arch.h>
+
+static const char *const mps2_compat[] __initconst = {
+	"arm,mps2",
+	NULL
+};
+
+DT_MACHINE_START(MPS2DT, "MPS2 (Device Tree Support)")
+	.dt_compat = mps2_compat,
+MACHINE_END
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 16 02:08:10 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 10:08:10 +0000
Subject: [PATCH v3 05/10] serial: mps2-uart: add support for early console
In-Reply-To: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1455617295-23736-6-git-send-email-vladimir.murzin@arm.com>

This adds support early console for MPS2 UART which can be enabled via
earlycon=mps2,0x40004000

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 drivers/tty/serial/Kconfig     |    1 +
 drivers/tty/serial/mps2-uart.c |   30 ++++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 3a248be..4ed6e51 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1454,6 +1454,7 @@ config SERIAL_MPS2_UART_CONSOLE
 	bool "MPS2 UART console support"
 	depends on SERIAL_MPS2_UART
 	select SERIAL_CORE_CONSOLE
+	select SERIAL_EARLYCON
 
 config SERIAL_MPS2_UART
 	bool "MPS2 UART port"
diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
index d97f3a9..f3a3bd1 100644
--- a/drivers/tty/serial/mps2-uart.c
+++ b/drivers/tty/serial/mps2-uart.c
@@ -435,6 +435,36 @@ static struct console mps2_uart_console = {
 
 #define MPS2_SERIAL_CONSOLE (&mps2_uart_console)
 
+static void mps2_early_putchar(struct uart_port *port, int ch)
+{
+
+	while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
+		cpu_relax();
+
+	writeb((unsigned char)ch, port->membase + UARTn_DATA);
+}
+
+
+static void mps2_early_write(struct console *con, const char *s, unsigned n)
+{
+	struct earlycon_device *dev = con->data;
+
+	uart_console_write(&dev->port, s, n, mps2_early_putchar);
+}
+
+static int __init mps2_early_console_setup(struct earlycon_device *device,
+					   const char *opt)
+{
+	if (!device->port.membase)
+		return -ENODEV;
+
+	device->con->write = mps2_early_write;
+
+	return 0;
+}
+EARLYCON_DECLARE(mps2, mps2_early_console_setup);
+OF_EARLYCON_DECLARE(mps2, "arm,mps2-uart", mps2_early_console_setup);
+
 #else
 #define MPS2_SERIAL_CONSOLE NULL
 #endif
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 16 02:08:12 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 10:08:12 +0000
Subject: [PATCH v3 07/10] ARM: mps2: add low-level debug support
In-Reply-To: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1455617295-23736-8-git-send-email-vladimir.murzin@arm.com>

Add low-level debug support for MPS2, so that earlyprintk can be enabled
for debugging early boot issues.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 arch/arm/Kconfig.debug        |   12 +++++++++++-
 arch/arm/include/debug/mps2.S |   27 +++++++++++++++++++++++++++
 2 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/debug/mps2.S

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index c6b6175..fcd2e15 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -485,6 +485,13 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on MMP UART3.
 
+	config DEBUG_MPS2_UART
+		bool "Kernel low-level debugging message via MPS2 UART0"
+		depends on ARCH_MPS2
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on MPS2 based platforms.
+
 	config DEBUG_MVEBU_UART0
 		bool "Kernel low-level debugging messages via MVEBU UART0 (old bootloaders)"
 		depends on ARCH_MVEBU
@@ -1415,6 +1422,7 @@ config DEBUG_LL_INCLUDE
 	default "debug/zynq.S" if DEBUG_ZYNQ_UART0 || DEBUG_ZYNQ_UART1
 	default "debug/bcm63xx.S" if DEBUG_BCM63XX_UART
 	default "debug/digicolor.S" if DEBUG_DIGICOLOR_UA0
+	default "debug/mps2.S" if DEBUG_MPS2_UART
 	default "mach/debug-macro.S"
 
 # Compatibility options for PL01x
@@ -1463,6 +1471,7 @@ config DEBUG_UART_PHYS
 	default 0x20201000 if DEBUG_BCM2835
 	default 0x3f201000 if DEBUG_BCM2836
 	default 0x3e000000 if DEBUG_BCM_KONA_UART
+	default 0x40004000 if DEBUG_MPS2_UART
 	default 0x4000e400 if DEBUG_LL_UART_EFM32
 	default 0x40081000 if DEBUG_LPC18XX_UART0
 	default 0x40090000 if DEBUG_LPC32XX
@@ -1539,7 +1548,8 @@ config DEBUG_UART_PHYS
 		DEBUG_S3C64XX_UART || \
 		DEBUG_BCM63XX_UART || DEBUG_ASM9260_UART || \
 		DEBUG_SIRFSOC_UART || DEBUG_DIGICOLOR_UA0 || \
-		DEBUG_AT91_UART
+		DEBUG_AT91_UART || \
+		DEBUG_MPS2_UART
 
 config DEBUG_UART_VIRT
 	hex "Virtual base address of debug UART"
diff --git a/arch/arm/include/debug/mps2.S b/arch/arm/include/debug/mps2.S
new file mode 100644
index 0000000..0ced0ce
--- /dev/null
+++ b/arch/arm/include/debug/mps2.S
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.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.
+ *
+ */
+
+	.macro	addruart, rp, tmp1, tmp2
+	ldr	\rp, =CONFIG_DEBUG_UART_PHYS
+	.endm
+
+	.macro	senduart, rd, rx
+	strb	\rd, [\rx]		@ Data Register
+	.endm
+
+	.macro	busyuart, rd, rx
+1001:	ldrb	\rd, [\rx, #0x4]	@ State Register
+	tst	\rd, #1			@ busy
+	bne	1001b			@ wait until transmit done
+	.endm
+
+	.macro	waituart,rd,rx
+	.endm
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 16 02:08:15 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 10:08:15 +0000
Subject: [PATCH v3 10/10] ARM: dts: introduce MPS2 AN399/AN400
In-Reply-To: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1455617295-23736-11-git-send-email-vladimir.murzin@arm.com>

Application Notes 399 and 400 shares the same memory map and
features. Both are shipped with Cortex-M7 and have the same  peripheral
as AN385/AN386, but with different location of PSRAM and Ethernet
controller.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 arch/arm/boot/dts/Makefile       |    4 +-
 arch/arm/boot/dts/mps2-an399.dts |   92 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 95 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/mps2-an399.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 96418d2..ad5622b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -245,7 +245,9 @@ dtb-$(CONFIG_ARCH_MMP) += \
 dtb-$(CONFIG_MACH_MESON8B) += \
 	meson8b-mxq.dtb \
 	meson8b-odroidc1.dtb
-dtb-$(CONFIG_ARCH_MPS2) += mps2-an385.dtb
+dtb-$(CONFIG_ARCH_MPS2) += \
+	mps2-an385.dtb \
+	mps2-an399.dtb
 dtb-$(CONFIG_ARCH_MOXART) += \
 	moxart-uc7112lx.dtb
 dtb-$(CONFIG_SOC_IMX1) += \
diff --git a/arch/arm/boot/dts/mps2-an399.dts b/arch/arm/boot/dts/mps2-an399.dts
new file mode 100644
index 0000000..e591d75
--- /dev/null
+++ b/arch/arm/boot/dts/mps2-an399.dts
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "mps2.dtsi"
+
+/ {
+	model = "ARM MPS2 Application Note 399/400";
+	compatible = "arm,mps2";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		bootargs = "rdinit=/sbin/init earlycon";
+		stdout-path = "serial0:9600n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x60000000 0x1000000>;
+	};
+
+
+	ethernet at a0000000 {
+		compatible = "smsc,lan9220", "smsc,lan9115";
+		reg = <0xa0000000 0x10000>;
+		interrupts = <13>;
+		interrupt-parent = <&nvic>;
+		smsc,irq-active-high;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+
+&timer0 {
+	status = "okay";
+};
+
+&timer1 {
+	status = "okay";
+};
+
+&wdt {
+	status = "okay";
+};
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 16 02:08:13 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 10:08:13 +0000
Subject: [PATCH v3 08/10] ARM: configs: add MPS2 defconfig
In-Reply-To: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1455617295-23736-9-git-send-email-vladimir.murzin@arm.com>

This patch adds a new config for MPS2 platform.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 arch/arm/configs/mps2_defconfig |  112 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 112 insertions(+)
 create mode 100644 arch/arm/configs/mps2_defconfig

diff --git a/arch/arm/configs/mps2_defconfig b/arch/arm/configs/mps2_defconfig
new file mode 100644
index 0000000..c36c519
--- /dev/null
+++ b/arch/arm/configs/mps2_defconfig
@@ -0,0 +1,112 @@
+# CONFIG_USELIB is not set
+CONFIG_NO_HZ_IDLE=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_LOG_BUF_SHIFT=16
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+# CONFIG_UID16 is not set
+# CONFIG_BASE_FULL is not set
+# CONFIG_FUTEX is not set
+# CONFIG_EPOLL is not set
+# CONFIG_SIGNALFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+CONFIG_EMBEDDED=y
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_BLOCK is not set
+# CONFIG_MMU is not set
+CONFIG_ARM_SINGLE_ARMV7M=y
+CONFIG_ARCH_MPS2=y
+CONFIG_SET_MEM_PARAM=y
+CONFIG_DRAM_BASE=0x21000000
+CONFIG_DRAM_SIZE=0x1000000
+CONFIG_PREEMPT_VOLUNTARY=y
+# CONFIG_ATAGS is not set
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_BINFMT_FLAT=y
+CONFIG_BINFMT_SHARED_FLAT=y
+# CONFIG_COREDUMP is not set
+# CONFIG_SUSPEND is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_WIRELESS is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_FW_LOADER is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NET_CORE is not set
+# 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_EZCHIP is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_HISILICON 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_NET_VENDOR_QUALCOMM is not set
+# CONFIG_NET_VENDOR_RENESAS is not set
+# CONFIG_NET_VENDOR_ROCKER is not set
+# CONFIG_NET_VENDOR_SAMSUNG is not set
+# 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_WLAN is not set
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_NONSTANDARD=y
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_MPS2_UART_CONSOLE=y
+CONFIG_SERIAL_MPS2_UART=y
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HWMON is not set
+CONFIG_WATCHDOG=y
+CONFIG_ARM_SP805_WATCHDOG=y
+CONFIG_MFD_SYSCON=y
+# CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_SYSCON=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_ONESHOT=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_BACKLIGHT=y
+CONFIG_LEDS_TRIGGER_CPU=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_ARM_TIMER_SP804=y
+# CONFIG_DNOTIFY is not set
+# CONFIG_INOTIFY_USER is not set
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_NFS_FS=y
+CONFIG_NFS_V4=y
+CONFIG_NFS_V4_1=y
+CONFIG_NFS_V4_2=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_INFO=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+CONFIG_DEBUG_FS=y
+CONFIG_MAGIC_SYSRQ=y
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+CONFIG_MEMTEST=y
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 16 02:08:14 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 10:08:14 +0000
Subject: [PATCH v3 09/10] ARM: dts: introduce MPS2 AN385/AN386
In-Reply-To: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1455617295-23736-10-git-send-email-vladimir.murzin@arm.com>

Application Notes 385 and 386 shares the same memory map and features
except the CPU is used. AN385 is supplied with Cortex-M3 CPU and AN386
is supplied with Cortex-M4.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 arch/arm/boot/dts/Makefile       |    1 +
 arch/arm/boot/dts/mps2-an385.dts |   90 +++++++++++++++
 arch/arm/boot/dts/mps2.dtsi      |  227 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 318 insertions(+)
 create mode 100644 arch/arm/boot/dts/mps2-an385.dts
 create mode 100644 arch/arm/boot/dts/mps2.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..96418d2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -245,6 +245,7 @@ dtb-$(CONFIG_ARCH_MMP) += \
 dtb-$(CONFIG_MACH_MESON8B) += \
 	meson8b-mxq.dtb \
 	meson8b-odroidc1.dtb
+dtb-$(CONFIG_ARCH_MPS2) += mps2-an385.dtb
 dtb-$(CONFIG_ARCH_MOXART) += \
 	moxart-uc7112lx.dtb
 dtb-$(CONFIG_SOC_IMX1) += \
diff --git a/arch/arm/boot/dts/mps2-an385.dts b/arch/arm/boot/dts/mps2-an385.dts
new file mode 100644
index 0000000..ddb03d3
--- /dev/null
+++ b/arch/arm/boot/dts/mps2-an385.dts
@@ -0,0 +1,90 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "mps2.dtsi"
+
+/ {
+	model = "ARM MPS2 Application Note 385/386";
+	compatible = "arm,mps2";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		bootargs = "init=/sbin/init earlycon";
+		stdout-path = "serial0:9600n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x21000000 0x1000000>;
+	};
+
+	ethernet at 40200000 {
+		compatible = "smsc,lan9220", "smsc,lan9115";
+		reg = <0x40200000 0x10000>;
+		interrupts = <13>;
+		interrupt-parent = <&nvic>;
+		smsc,irq-active-high;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&timer0 {
+	status = "okay";
+};
+
+&timer1 {
+	status = "okay";
+};
+
+&wdt {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/mps2.dtsi b/arch/arm/boot/dts/mps2.dtsi
new file mode 100644
index 0000000..5d2c539
--- /dev/null
+++ b/arch/arm/boot/dts/mps2.dtsi
@@ -0,0 +1,227 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "armv7-m.dtsi"
+
+/ {
+	oscclk0: clk-osc0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <50000000>;
+	};
+
+	oscclk1: clk-osc1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24576000>;
+	};
+
+	oscclk2: clk-osc2 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <25000000>;
+	};
+
+	cfgclk: clk-cfg {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <5000000>;
+	};
+
+	spicfgclk: clk-spicfg {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <75000000>;
+	};
+
+	sysclk: clk-sys {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk0>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	audmclk: clk-audm {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk1>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	audsclk: clk-auds {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk1>;
+		#clock-cells = <0>;
+		clock-div = <8>;
+		clock-mult = <1>;
+	};
+
+	spiclcd: clk-cpiclcd {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk0>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	spicon: clk-spicon {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk0>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	i2cclcd: clk-i2cclcd {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk0>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	i2caud: clk-i2caud {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk0>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		ranges;
+
+		apb {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 0x40000000 0x10000>;
+
+			timer0: mps2-timer0 at 0 {
+				compatible = "arm,mps2-timer";
+				reg = <0x0 0x1000>;
+				interrupts = <8>;
+				clocks = <&sysclk>;
+				status = "disabled";
+			};
+
+			timer1: mps2-timer1 at 1000 {
+				compatible = "arm,mps2-timer";
+				reg = <0x1000 0x1000>;
+				interrupts = <9>;
+				clocks = <&sysclk>;
+				status = "disabled";
+			};
+
+			timer2: dual-timer at 2000 {
+				compatible = "arm,sp804";
+				reg = <0x2000 0x1000>;
+				clocks = <&sysclk>;
+				interrupts = <10>;
+				status = "disabled";
+			};
+
+
+			uart0: serial at 4000 {
+				compatible = "arm,mps2-uart";
+				reg = <0x4000 0x1000>;
+				interrupts = <0 1 12>;
+				clocks = <&sysclk>;
+				status = "disabled";
+			};
+
+			uart1: serial at 5000 {
+				compatible = "arm,mps2-uart";
+				reg = <0x5000 0x1000>;
+				interrupts = <2 3 12>;
+				clocks = <&sysclk>;
+				status = "disabled";
+			};
+
+			uart2: serial at 6000 {
+				compatible = "arm,mps2-uart";
+				reg = <0x6000 0x1000>;
+				interrupts = <4 5 12>;
+				clocks = <&sysclk>;
+				status = "disabled";
+			};
+
+			wdt: watchdog at 8000 {
+				compatible = "arm,sp805", "arm,primecell";
+				arm,primecell-periphid = <0x00141805>;
+				reg = <0x8000 0x1000>;
+				interrupts = <0>;
+				clocks = <&sysclk>;
+				clock-names = "apb_pclk";
+				status = "disabled";
+			};
+		};
+
+		fpgaio {
+			compatible = "syscon", "simple-mfd";
+			reg = <0x40028000 0x10>;
+
+			led at 0 {
+				compatible = "register-bit-led";
+				offset = <0x0>;
+				mask = <0x01>;
+				label = "userled:0";
+				linux,default-trigger = "heartbeat";
+				default-state = "on";
+			};
+
+			led at 1 {
+				compatible = "register-bit-led";
+				offset = <0x0>;
+				mask = <0x02>;
+				label = "userled:1";
+				linux,default-trigger = "usr";
+				default-state = "off";
+			};
+		};
+	};
+};
-- 
1.7.9.5



From thierry.reding at gmail.com  Tue Feb 16 02:16:31 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 16 Feb 2016 11:16:31 +0100
Subject: [PATCH v2] arm64/efi: Make strnlen() available to the EFI namespace
In-Reply-To: <1455563856-1553-1-git-send-email-thierry.reding@gmail.com>
References: <1455563856-1553-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <1455617791-4791-1-git-send-email-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

Changes introduced in the upstream version of libfdt pulled in by commit
91feabc2e224 ("scripts/dtc: Update to upstream commit b06e55c88b9b") use
the strnlen() function, which isn't currently available to the EFI name-
space. Add it to the EFI namespace to avoid a linker error.

Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Rob Herring <robh at kernel.org>
Signed-off-by: Thierry Reding <treding at nvidia.com>
---
Changes in v2:
- mark strnlen() position independent and refer to __pi_strnlen

 arch/arm64/kernel/image.h | 1 +
 arch/arm64/lib/strnlen.S  | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
index 999633bd7294..352f7abd91c9 100644
--- a/arch/arm64/kernel/image.h
+++ b/arch/arm64/kernel/image.h
@@ -89,6 +89,7 @@ __efistub_memcpy		= KALLSYMS_HIDE(__pi_memcpy);
 __efistub_memmove		= KALLSYMS_HIDE(__pi_memmove);
 __efistub_memset		= KALLSYMS_HIDE(__pi_memset);
 __efistub_strlen		= KALLSYMS_HIDE(__pi_strlen);
+__efistub_strnlen		= KALLSYMS_HIDE(__pi_strnlen);
 __efistub_strcmp		= KALLSYMS_HIDE(__pi_strcmp);
 __efistub_strncmp		= KALLSYMS_HIDE(__pi_strncmp);
 __efistub___flush_dcache_area	= KALLSYMS_HIDE(__pi___flush_dcache_area);
diff --git a/arch/arm64/lib/strnlen.S b/arch/arm64/lib/strnlen.S
index 2ca665711bf2..eae38da6e0bb 100644
--- a/arch/arm64/lib/strnlen.S
+++ b/arch/arm64/lib/strnlen.S
@@ -168,4 +168,4 @@ CPU_LE( lsr	tmp2, tmp2, tmp4 )	/* Shift (tmp1 & 63).  */
 .Lhit_limit:
 	mov	len, limit
 	ret
-ENDPROC(strnlen)
+ENDPIPROC(strnlen)
-- 
2.7.1



From linux at arm.linux.org.uk  Tue Feb 16 02:15:10 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 16 Feb 2016 10:15:10 +0000
Subject: [PATCH] drivers/hwtracing: make coresight-* explicitly non-modular
In-Reply-To: <CANLsYkyY84Tp2oxP9JdAq6WGp9rBXQc=7nXS2hfi9hkcrFEKCw@mail.gmail.com>
References: <1455470351-15219-1-git-send-email-paul.gortmaker@windriver.com>
 <CANLsYkyY84Tp2oxP9JdAq6WGp9rBXQc=7nXS2hfi9hkcrFEKCw@mail.gmail.com>
Message-ID: <20160216101509.GB19428@n2100.arm.linux.org.uk>

On Mon, Feb 15, 2016 at 06:25:56PM -0700, Mathieu Poirier wrote:
> On 14 February 2016 at 10:19, Paul Gortmaker
> <paul.gortmaker at windriver.com> wrote:
> > diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
> > index 9006c4e75cf7..3d8dcdd1aeae 100644
> > --- a/include/linux/amba/bus.h
> > +++ b/include/linux/amba/bus.h
> > @@ -163,4 +163,13 @@ struct amba_device name##_device = {                               \
> >  #define module_amba_driver(__amba_drv) \
> >         module_driver(__amba_drv, amba_driver_register, amba_driver_unregister)
> >
> > +/*
> > + * builtin_amba_driver() - Helper macro for drivers that don't do anything
> > + * special in driver initcall.  This eliminates a lot of boilerplate.  Each
> > + * driver may only use this macro once, and calling it replaces the instance
> > + * device_initcall().
> > + */
> > +#define builtin_amba_driver(__amba_drv) \
> > +       builtin_driver(__amba_drv, amba_driver_register)
> > +
> >  #endif
> > --
> > 2.6.1
> >
> 
> I'm good with this patch on the CS side but Russell maintains the amba
> subsystem and as such needs to agree with the new macro.  Russell, I
> offer to take this through my tree if you're fine with the changes.

Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From thierry.reding at gmail.com  Tue Feb 16 02:19:35 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 16 Feb 2016 11:19:35 +0100
Subject: [PATCH] arm64/efi: Make strnlen() available to the EFI namespace
In-Reply-To: <CAKv+Gu86oyHJcBhkjouLQk8FMR=0obrPpwnYvXMFSJkOa3c2pA@mail.gmail.com>
References: <1455563856-1553-1-git-send-email-thierry.reding@gmail.com>
 <CAKv+Gu86oyHJcBhkjouLQk8FMR=0obrPpwnYvXMFSJkOa3c2pA@mail.gmail.com>
Message-ID: <20160216101935.GA4868@ulmo>

On Mon, Feb 15, 2016 at 08:23:22PM +0100, Ard Biesheuvel wrote:
> Hi Thierry,
> 
> On 15 February 2016 at 20:17, Thierry Reding <thierry.reding at gmail.com> wrote:
> > From: Thierry Reding <treding at nvidia.com>
> >
> > Changes introduced in the upstream version of libfdt pulled in by commit
> > 91feabc2e224 ("scripts/dtc: Update to upstream commit b06e55c88b9b") use
> > the strnlen() function, which isn't currently available to the EFI name-
> > space. Add it to the EFI namespace to avoid a linker error.
> >
> > Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > Cc: Will Deacon <will.deacon at arm.com>
> > Cc: Rob Herring <robh at kernel.org>
> > Signed-off-by: Thierry Reding <treding at nvidia.com>
> > ---
> >  arch/arm64/kernel/image.h | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
> > index c9c62cab25a4..8a1978f4a555 100644
> > --- a/arch/arm64/kernel/image.h
> > +++ b/arch/arm64/kernel/image.h
> > @@ -96,6 +96,8 @@ __efistub_strcmp              = KALLSYMS_HIDE(__pi_strcmp);
> >  __efistub_strncmp              = KALLSYMS_HIDE(__pi_strncmp);
> >  __efistub___flush_dcache_area  = KALLSYMS_HIDE(__pi___flush_dcache_area);
> >
> > +__efistub_strnlen              = KALLSYMS_HIDE(strnlen);
> > +
> 
> To align with the existing code, we should use __pi_strnlen here, and
> declare the asm version of strnlen with ENDPIPROC()

Yes, you're absolutely right. For some reason I had missed the ARM64
implementation of strnlen() in the grep output. Sent a v2 now which is
consistent with the existing code.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/a3e4386c/attachment.sig>

From ard.biesheuvel at linaro.org  Tue Feb 16 02:20:13 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 11:20:13 +0100
Subject: [PATCH v2] arm64/efi: Make strnlen() available to the EFI
 namespace
In-Reply-To: <1455617791-4791-1-git-send-email-thierry.reding@gmail.com>
References: <1455563856-1553-1-git-send-email-thierry.reding@gmail.com>
 <1455617791-4791-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <CAKv+Gu-Ms8S-oBvGbbxvh4Xr67UcKXpbuPh8TLO_KdhYgL0eTg@mail.gmail.com>

On 16 February 2016 at 11:16, Thierry Reding <thierry.reding at gmail.com> wrote:
> From: Thierry Reding <treding at nvidia.com>
>
> Changes introduced in the upstream version of libfdt pulled in by commit
> 91feabc2e224 ("scripts/dtc: Update to upstream commit b06e55c88b9b") use
> the strnlen() function, which isn't currently available to the EFI name-
> space. Add it to the EFI namespace to avoid a linker error.
>
> Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Rob Herring <robh at kernel.org>
> Signed-off-by: Thierry Reding <treding at nvidia.com>

Reviewed-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

> ---
> Changes in v2:
> - mark strnlen() position independent and refer to __pi_strnlen
>
>  arch/arm64/kernel/image.h | 1 +
>  arch/arm64/lib/strnlen.S  | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
> index 999633bd7294..352f7abd91c9 100644
> --- a/arch/arm64/kernel/image.h
> +++ b/arch/arm64/kernel/image.h
> @@ -89,6 +89,7 @@ __efistub_memcpy              = KALLSYMS_HIDE(__pi_memcpy);
>  __efistub_memmove              = KALLSYMS_HIDE(__pi_memmove);
>  __efistub_memset               = KALLSYMS_HIDE(__pi_memset);
>  __efistub_strlen               = KALLSYMS_HIDE(__pi_strlen);
> +__efistub_strnlen              = KALLSYMS_HIDE(__pi_strnlen);
>  __efistub_strcmp               = KALLSYMS_HIDE(__pi_strcmp);
>  __efistub_strncmp              = KALLSYMS_HIDE(__pi_strncmp);
>  __efistub___flush_dcache_area  = KALLSYMS_HIDE(__pi___flush_dcache_area);
> diff --git a/arch/arm64/lib/strnlen.S b/arch/arm64/lib/strnlen.S
> index 2ca665711bf2..eae38da6e0bb 100644
> --- a/arch/arm64/lib/strnlen.S
> +++ b/arch/arm64/lib/strnlen.S
> @@ -168,4 +168,4 @@ CPU_LE( lsr tmp2, tmp2, tmp4 )      /* Shift (tmp1 & 63).  */
>  .Lhit_limit:
>         mov     len, limit
>         ret
> -ENDPROC(strnlen)
> +ENDPIPROC(strnlen)
> --
> 2.7.1
>


From will.deacon at arm.com  Tue Feb 16 02:31:04 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 16 Feb 2016 10:31:04 +0000
Subject: [PATCH v2] arm64: add alignment fault hanling
In-Reply-To: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
References: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
Message-ID: <20160216103104.GC14509@arm.com>

On Tue, Feb 16, 2016 at 04:44:35AM +0000, EunTaik Lee wrote:
> Userspace memory is mapped as below:
> F2A7F000--F2A7FFFF Normal Memory
> F2A80000--F2A80FFF Device nGnRnE
> 
> And that userspace application makes a system call
> as below:
> 
> -009 |do_strncpy_from_user(inline)
> -009 |strncpy_from_user()
> -010 |getname_flags()
> -011 |user_path_at_empty()
> -012 |user_path_at()
> -013 |SYSC_faccessat(inline)
> -013 |sys_faccessat()
> -014 |__sys_trace(asm)
>  --> |exception
> 
> The string spans from 0xF2A7FFC1 to 0xF2A7FFFB.
> 
> When do_strncpy_from_user() reads the last (unsigned long)
> value, the alignement fault is triggered. The 8 byte
> from 0xF2A7FFC1 spans to the next page that is mapped as
> Device nGnRnE, which does not allow an unaligned access,
> causes the abort.
> 
> The instruction which caused the alignment fault is registered
> in the fixup table but the exception handler does not reach there.
> 
> This patch registers a alignment fault handler and fixes up the
> pc if appropriate.

As discussed with Catalin previously, we should solve this by adding a
guard page rather than handling the fault.

Will


From s.nawrocki at samsung.com  Tue Feb 16 02:29:39 2016
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Tue, 16 Feb 2016 11:29:39 +0100
Subject: [PATCH v4 2/2] s5p-mfc: add the support of
 V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME.
In-Reply-To: <1453187230-97231-3-git-send-email-wuchengli@chromium.org>
References: <1453187230-97231-1-git-send-email-wuchengli@chromium.org>
 <1453187230-97231-3-git-send-email-wuchengli@chromium.org>
Message-ID: <56C2FA13.3020106@samsung.com>

On 19/01/16 08:07, Wu-Cheng Li wrote:
> There is a new control V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME to
> force an encoder key frame. It is the same as requesting
> V4L2_MPEG_MFC51_VIDEO_FORCE_FRAME_TYPE_I_FRAME.
> 
> Signed-off-by: Wu-Cheng Li <wuchengli at chromium.org>

Acked-by: Sylwester Nawrocki <s.nawrocki at samsung.com>



From will.deacon at arm.com  Tue Feb 16 02:32:54 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 16 Feb 2016 10:32:54 +0000
Subject: [PATCH v2] arm64/efi: Make strnlen() available to the EFI
 namespace
In-Reply-To: <1455617791-4791-1-git-send-email-thierry.reding@gmail.com>
References: <1455563856-1553-1-git-send-email-thierry.reding@gmail.com>
 <1455617791-4791-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <20160216103254.GD14509@arm.com>

On Tue, Feb 16, 2016 at 11:16:31AM +0100, Thierry Reding wrote:
> From: Thierry Reding <treding at nvidia.com>
> 
> Changes introduced in the upstream version of libfdt pulled in by commit
> 91feabc2e224 ("scripts/dtc: Update to upstream commit b06e55c88b9b") use
> the strnlen() function, which isn't currently available to the EFI name-
> space. Add it to the EFI namespace to avoid a linker error.
> 
> Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Rob Herring <robh at kernel.org>
> Signed-off-by: Thierry Reding <treding at nvidia.com>
> ---
> Changes in v2:
> - mark strnlen() position independent and refer to __pi_strnlen

Thanks, I'll queue this on the arm64 fixes branch.

Will


From andy.shevchenko at gmail.com  Tue Feb 16 02:36:09 2016
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Tue, 16 Feb 2016 12:36:09 +0200
Subject: [PATCH v3 05/10] serial: mps2-uart: add support for early console
In-Reply-To: <1455617295-23736-6-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-6-git-send-email-vladimir.murzin@arm.com>
Message-ID: <CAHp75VdugAq0WnzLHmd9CJHCjBOdBwPqCmC3ARSaVF5XMYGoMw@mail.gmail.com>

On Tue, Feb 16, 2016 at 12:08 PM, Vladimir Murzin
<vladimir.murzin at arm.com> wrote:
> This adds support early console for MPS2 UART which can be enabled via
> earlycon=mps2,0x40004000


> --- a/drivers/tty/serial/mps2-uart.c
> +++ b/drivers/tty/serial/mps2-uart.c
> @@ -435,6 +435,36 @@ static struct console mps2_uart_console = {
>
>  #define MPS2_SERIAL_CONSOLE (&mps2_uart_console)
>
> +static void mps2_early_putchar(struct uart_port *port, int ch)
> +{
> +
> +       while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
> +               cpu_relax();

Infinite busy loop?

> +
> +       writeb((unsigned char)ch, port->membase + UARTn_DATA);
> +}
> +
> +
> +static void mps2_early_write(struct console *con, const char *s, unsigned n)
> +{
> +       struct earlycon_device *dev = con->data;
> +
> +       uart_console_write(&dev->port, s, n, mps2_early_putchar);
> +}
> +
> +static int __init mps2_early_console_setup(struct earlycon_device *device,
> +                                          const char *opt)
> +{
> +       if (!device->port.membase)
> +               return -ENODEV;
> +
> +       device->con->write = mps2_early_write;
> +
> +       return 0;
> +}
> +EARLYCON_DECLARE(mps2, mps2_early_console_setup);
> +OF_EARLYCON_DECLARE(mps2, "arm,mps2-uart", mps2_early_console_setup);

IIRC Peter Hurley mentioned you don't need to put both anymore, OF_
one is enough.

-- 
With Best Regards,
Andy Shevchenko


From thierry.reding at gmail.com  Tue Feb 16 02:37:57 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 16 Feb 2016 11:37:57 +0100
Subject: [PATCH] ARM: dts: tegra: replace legacy *,wakeup property with
 wakeup-source
In-Reply-To: <1454968543-12035-1-git-send-email-sudeep.holla@arm.com>
References: <1454968543-12035-1-git-send-email-sudeep.holla@arm.com>
Message-ID: <20160216103757.GA9979@ulmo>

On Mon, Feb 08, 2016 at 09:55:43PM +0000, Sudeep Holla wrote:
> Though the keyboard and other driver will continue to support the legacy
> "gpio-key,wakeup", "nvidia,wakeup-source" boolean property to enable the
> wakeup source, "wakeup-source" is the new standard binding.
> 
> This patch replaces all the legacy wakeup properties with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
> 
> Cc: Stephen Warren <swarren at wwwdotorg.org>
> Cc: Thierry Reding <thierry.reding at gmail.com>
> Cc: Alexandre Courbot <gnurou at gmail.com>
> Cc: linux-tegra at vger.kernel.org
> Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
> ---
>  arch/arm/boot/dts/tegra114-dalmore.dts         | 2 +-
>  arch/arm/boot/dts/tegra114-roth.dts            | 2 +-
>  arch/arm/boot/dts/tegra114-tn7.dts             | 2 +-
>  arch/arm/boot/dts/tegra124-jetson-tk1.dts      | 2 +-
>  arch/arm/boot/dts/tegra124-nyan.dtsi           | 4 ++--
>  arch/arm/boot/dts/tegra124-venice2.dts         | 2 +-
>  arch/arm/boot/dts/tegra20-harmony.dts          | 2 +-
>  arch/arm/boot/dts/tegra20-paz00.dts            | 2 +-
>  arch/arm/boot/dts/tegra20-seaboard.dts         | 4 ++--
>  arch/arm/boot/dts/tegra20-trimslice.dts        | 2 +-
>  arch/arm/boot/dts/tegra20-ventana.dts          | 2 +-
>  arch/arm/boot/dts/tegra20-whistler.dts         | 2 +-
>  arch/arm/boot/dts/tegra30-apalis-eval.dts      | 2 +-
>  arch/arm/boot/dts/tegra30-cardhu.dtsi          | 2 +-
>  arch/arm/boot/dts/tegra30-colibri-eval-v3.dts  | 2 +-
>  arch/arm64/boot/dts/nvidia/tegra132-norrin.dts | 4 ++--
>  16 files changed, 19 insertions(+), 19 deletions(-)

I've applied this for 4.6, though I took the liberty of splitting this
up into ARM and arm64 patches, since the ARM SoC maintainers prefer it
that way.

Thanks,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/bddd51d9/attachment.sig>

From sudeep.holla at arm.com  Tue Feb 16 02:39:41 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Tue, 16 Feb 2016 10:39:41 +0000
Subject: [PATCH] ARM: dts: tegra: replace legacy *,wakeup property with
 wakeup-source
In-Reply-To: <20160216103757.GA9979@ulmo>
References: <1454968543-12035-1-git-send-email-sudeep.holla@arm.com>
 <20160216103757.GA9979@ulmo>
Message-ID: <56C2FC6D.3000709@arm.com>



On 16/02/16 10:37, Thierry Reding wrote:
> On Mon, Feb 08, 2016 at 09:55:43PM +0000, Sudeep Holla wrote:
>> Though the keyboard and other driver will continue to support the legacy
>> "gpio-key,wakeup", "nvidia,wakeup-source" boolean property to enable the
>> wakeup source, "wakeup-source" is the new standard binding.
>>
>> This patch replaces all the legacy wakeup properties with the unified
>> "wakeup-source" property in order to avoid any further copy-paste
>> duplication.
>>
>> Cc: Stephen Warren <swarren at wwwdotorg.org>
>> Cc: Thierry Reding <thierry.reding at gmail.com>
>> Cc: Alexandre Courbot <gnurou at gmail.com>
>> Cc: linux-tegra at vger.kernel.org
>> Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
>> ---
>>   arch/arm/boot/dts/tegra114-dalmore.dts         | 2 +-
>>   arch/arm/boot/dts/tegra114-roth.dts            | 2 +-
>>   arch/arm/boot/dts/tegra114-tn7.dts             | 2 +-
>>   arch/arm/boot/dts/tegra124-jetson-tk1.dts      | 2 +-
>>   arch/arm/boot/dts/tegra124-nyan.dtsi           | 4 ++--
>>   arch/arm/boot/dts/tegra124-venice2.dts         | 2 +-
>>   arch/arm/boot/dts/tegra20-harmony.dts          | 2 +-
>>   arch/arm/boot/dts/tegra20-paz00.dts            | 2 +-
>>   arch/arm/boot/dts/tegra20-seaboard.dts         | 4 ++--
>>   arch/arm/boot/dts/tegra20-trimslice.dts        | 2 +-
>>   arch/arm/boot/dts/tegra20-ventana.dts          | 2 +-
>>   arch/arm/boot/dts/tegra20-whistler.dts         | 2 +-
>>   arch/arm/boot/dts/tegra30-apalis-eval.dts      | 2 +-
>>   arch/arm/boot/dts/tegra30-cardhu.dtsi          | 2 +-
>>   arch/arm/boot/dts/tegra30-colibri-eval-v3.dts  | 2 +-
>>   arch/arm64/boot/dts/nvidia/tegra132-norrin.dts | 4 ++--
>>   16 files changed, 19 insertions(+), 19 deletions(-)
>
> I've applied this for 4.6, though I took the liberty of splitting this
> up into ARM and arm64 patches, since the ARM SoC maintainers prefer it
> that way.

Ah right, I forgot. Thanks for that.

-- 
Regards,
Sudeep


From andre.przywara at arm.com  Tue Feb 16 02:46:05 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 16 Feb 2016 10:46:05 +0000
Subject: [PATCH v2 0/3] clk: sunxi: error checking on clock setup
Message-ID: <1455619568-1906-1-git-send-email-andre.przywara@arm.com>

Setting up the clocks properly is quite critical to the system's
operation, but currently our error handling is not very verbose.
This series adds error handling and reporting to the sunxi clocks,
so that any errors are correctly detected and reported. Also previous
actions are rolled back in case something went wrong.
This proves to be helpful in debugging clock tree issues,
especially when adding support for new SoCs.
I tested this on a BananaPi by deliberately misspelling
"clock-output-names". The resulting kernel crash in
sun4i_timer_interrupt is totally misleading, but now there is a line
in the dmesg before saying:
=======
sunxi_divider_clk_setup: could not read clock-output-names for "apb0"
=======

This applies on top of Maxime's sunxi/for-next branch.

Changes v1 .. v2:
- in all three patches:
  - use of_clock_full_name() instead of node->name
  - don't report the uninitialized clk_name
  - handle error in final check in if-clause

Andre Przywara (3):
  clk: sunxi: improve mux_clk error handling and reporting
  clk: sunxi: improve divider_clk error handling and reporting
  clk: sunxi: Improve divs_clk error handling and reporting

 drivers/clk/sunxi/clk-sunxi.c | 75 ++++++++++++++++++++++++++++++++++++-------
 1 file changed, 63 insertions(+), 12 deletions(-)

-- 
2.6.4



From andre.przywara at arm.com  Tue Feb 16 02:46:08 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 16 Feb 2016 10:46:08 +0000
Subject: [PATCH v2 3/3] clk: sunxi: Improve divs_clk error handling and
 reporting
In-Reply-To: <1455619568-1906-1-git-send-email-andre.przywara@arm.com>
References: <1455619568-1906-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455619568-1906-4-git-send-email-andre.przywara@arm.com>

We catch errors in the base clock registration, failure to ioremap
and failures in the final of_clk_add_provider() call.
Also we unmap the registers when we need to rollback.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 4bd0917..91de0a0 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -985,13 +985,20 @@ static struct clk ** __init sunxi_divs_clk_setup(struct device_node *node,
 
 	/* Set up factor clock that we will be dividing */
 	pclk = sunxi_factors_clk_setup(node, data->factors);
+	if (!pclk)
+		return NULL;
 	parent = __clk_get_name(pclk);
 
 	reg = of_iomap(node, 0);
+	if (!reg) {
+		pr_err("Could not map registers for divs-clk: %s\n",
+		       of_node_full_name(node));
+		return NULL;
+	}
 
 	clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
 	if (!clk_data)
-		return NULL;
+		goto out_unmap;
 
 	clks = kcalloc(ndivs, sizeof(*clks), GFP_KERNEL);
 	if (!clks)
@@ -1074,16 +1081,21 @@ static struct clk ** __init sunxi_divs_clk_setup(struct device_node *node,
 	/* Adjust to the real max */
 	clk_data->clk_num = i;
 
-	of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+	if (of_clk_add_provider(node, of_clk_src_onecell_get, clk_data)) {
+		pr_err("%s: failed to add clock provider for %s\n",
+		       __func__, clk_name);
+		goto free_gate;
+	}
 
 	return clks;
-
 free_gate:
 	kfree(gate);
 free_clks:
 	kfree(clks);
 free_clkdata:
 	kfree(clk_data);
+out_unmap:
+	iounmap(reg);
 	return NULL;
 }
 
-- 
2.6.4



From andre.przywara at arm.com  Tue Feb 16 02:46:06 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 16 Feb 2016 10:46:06 +0000
Subject: [PATCH v2 1/3] clk: sunxi: improve mux_clk error handling and
 reporting
In-Reply-To: <1455619568-1906-1-git-send-email-andre.przywara@arm.com>
References: <1455619568-1906-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455619568-1906-2-git-send-email-andre.przywara@arm.com>

We now catch and report a failing ioremap, also a failure in the final
step of the clock registration is now handled and reported.
Also warnings are turned into errors.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 99f60ef..775e137 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -674,11 +674,16 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
 	int i;
 
 	reg = of_iomap(node, 0);
+	if (!reg) {
+		pr_err("Could not map registers for mux-clk: %s\n",
+		       of_node_full_name(node));
+		return NULL;
+	}
 
 	i = of_clk_parent_fill(node, parents, SUNXI_MAX_PARENTS);
 	if (of_property_read_string(node, "clock-output-names", &clk_name)) {
-		pr_warn("%s: could not read clock-output-names for \"%s\"\n",
-			__func__, clk_name);
+		pr_err("%s: could not read clock-output-names from \"%s\"\n",
+		       __func__, of_node_full_name(node));
 		goto out_unmap;
 	}
 
@@ -688,15 +693,19 @@ static struct clk * __init sunxi_mux_clk_setup(struct device_node *node,
 			       0, &clk_lock);
 
 	if (IS_ERR(clk)) {
-		pr_warn("%s: failed to register mux clock %s: %ld\n", __func__,
-			clk_name, PTR_ERR(clk));
+		pr_err("%s: failed to register mux clock %s: %ld\n", __func__,
+		       clk_name, PTR_ERR(clk));
 		goto out_unmap;
 	}
 
-	of_clk_add_provider(node, of_clk_src_simple_get, clk);
+	if (of_clk_add_provider(node, of_clk_src_simple_get, clk)) {
+		pr_err("%s: failed to add clock provider for %s\n",
+		       __func__, clk_name);
+		clk_unregister_divider(clk);
+		goto out_unmap;
+	}
 
 	return clk;
-
 out_unmap:
 	iounmap(reg);
 	return NULL;
-- 
2.6.4



From andre.przywara at arm.com  Tue Feb 16 02:46:07 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 16 Feb 2016 10:46:07 +0000
Subject: [PATCH v2 2/3] clk: sunxi: improve divider_clk error handling and
 reporting
In-Reply-To: <1455619568-1906-1-git-send-email-andre.przywara@arm.com>
References: <1455619568-1906-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455619568-1906-3-git-send-email-andre.przywara@arm.com>

We now report a failing ioremap, failing output names parsing,
failures in table registration and in the final step.
Also there was a bug where clk_register_divider_table() would return
an ERR_PTR value instead of NULL, which we were checking for.
We now implement proper rollback in case of an error.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 drivers/clk/sunxi/clk-sunxi.c | 36 +++++++++++++++++++++++++++++++++---
 1 file changed, 33 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 775e137..4bd0917 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -805,17 +805,47 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
 	void __iomem *reg;
 
 	reg = of_iomap(node, 0);
+	if (!reg) {
+		pr_err("Could not map registers for mux-clk: %s\n",
+		       of_node_full_name(node));
+		return;
+	}
 
 	clk_parent = of_clk_get_parent_name(node, 0);
 
-	of_property_read_string(node, "clock-output-names", &clk_name);
+	if (of_property_read_string(node, "clock-output-names", &clk_name)) {
+		pr_err("%s: could not read clock-output-names from \"%s\"\n",
+		       __func__, of_node_full_name(node));
+		goto out_unmap;
+	}
 
 	clk = clk_register_divider_table(NULL, clk_name, clk_parent, 0,
 					 reg, data->shift, data->width,
 					 data->pow ? CLK_DIVIDER_POWER_OF_TWO : 0,
 					 data->table, &clk_lock);
-	if (clk)
-		of_clk_add_provider(node, of_clk_src_simple_get, clk);
+	if (IS_ERR(clk)) {
+		pr_err("%s: failed to register divider clock %s: %ld\n",
+		       __func__, clk_name, PTR_ERR(clk));
+		goto out_unmap;
+	}
+
+	if (of_clk_add_provider(node, of_clk_src_simple_get, clk)) {
+		pr_err("%s: failed to add clock provider for %s\n",
+		       __func__, clk_name);
+		goto out_unregister;
+	}
+
+	if (clk_register_clkdev(clk, clk_name, NULL)) {
+		of_clk_del_provider(node);
+		goto out_unregister;
+	}
+
+	return;
+out_unregister:
+	clk_unregister_divider(clk);
+
+out_unmap:
+	iounmap(reg);
 }
 
 static void __init sun4i_ahb_clk_setup(struct device_node *node)
-- 
2.6.4



From andy.shevchenko at gmail.com  Tue Feb 16 02:48:16 2016
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Tue, 16 Feb 2016 12:48:16 +0200
Subject: [PATCH v3 04/10] serial: mps2-uart: add MPS2 UART driver
In-Reply-To: <1455617295-23736-5-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-5-git-send-email-vladimir.murzin@arm.com>
Message-ID: <CAHp75Vcx_xAY2A4XNgQ1ea_U5mUnD1+6=2FxCM3KzsRSpxgRuw@mail.gmail.com>

On Tue, Feb 16, 2016 at 12:08 PM, Vladimir Murzin
<vladimir.murzin at arm.com> wrote:
> This driver adds support to the UART controller found on ARM MPS2
> platform.


> +static irqreturn_t mps2_uart_oerrirq(int irq, void *data)
> +{
> +       irqreturn_t handled = IRQ_NONE;
> +       struct uart_port *port = data;
> +       u8 irqflag = mps2_uart_read8(port, UARTn_INT);
> +
> +       spin_lock(&port->lock);
> +
> +       if (irqflag & UARTn_INT_RX_OVERRUN) {
> +               struct tty_port *tport = &port->state->port;
> +
> +               mps2_uart_write8(port, UARTn_INT_RX_OVERRUN, UARTn_INT);
> +               tty_insert_flip_char(tport, 0, TTY_OVERRUN);
> +               port->icount.overrun++;
> +               handled = IRQ_HANDLED;
> +       }
> +
> +       /*
> +        * It's never been seen in practice and it never *should* happen since
> +        * we check if there is enough room in TX buffer before sending data.
> +        * So we keep this check in case something suspicious has happened.
> +        */
> +       if (irqflag & UARTn_INT_TX_OVERRUN) {
> +               mps2_uart_write8(port, UARTn_INT_TX_OVERRUN, UARTn_INT);

> +               dev_warn(port->dev, "unexpected overrun interrupt\n");

I'm not sure there is no dead lock if this happens on the same port
which is used as console.

> +               handled = IRQ_HANDLED;
> +       }
> +
> +       spin_unlock(&port->lock);
> +
> +       return handled;
> +}
> +
> +static int mps2_uart_startup(struct uart_port *port)
> +{
> +       struct mps2_uart_port *mps_port = to_mps2_port(port);
> +       u8 control = mps2_uart_read8(port, UARTn_CTRL);
> +       int ret;
> +
> +       control &= ~(UARTn_CTRL_RX_GRP | UARTn_CTRL_TX_GRP);
> +
> +       mps2_uart_write8(port, control, UARTn_CTRL);
> +
> +       ret = request_irq(mps_port->rx_irq, mps2_uart_rxirq, 0,
> +                         MAKE_NAME(-rx), mps_port);
> +       if (ret) {
> +               dev_err(port->dev, "failed to register rxirq (%d)\n", ret);
> +               goto err_no_rxirq;

It should be below, here just a plain return.

> +       }
> +
> +       ret = request_irq(mps_port->tx_irq, mps2_uart_txirq, 0,
> +                         MAKE_NAME(-tx), mps_port);
> +       if (ret) {
> +               dev_err(port->dev, "failed to register txirq (%d)\n", ret);
> +               goto err_no_txirq;

goto err_free_rxirq;

> +       }
> +
> +       ret = request_irq(port->irq, mps2_uart_oerrirq, IRQF_SHARED,
> +                         MAKE_NAME(-overrun), mps_port);
> +
> +       if (ret) {
> +               dev_err(port->dev, "failed to register oerrirq (%d)\n", ret);

Why not goto pattern here as well?

goto err_free_txirq;

> +       } else {

?and remove this else.

> +               control |= UARTn_CTRL_RX_GRP | UARTn_CTRL_TX_GRP;
> +
> +               mps2_uart_write8(port, control, UARTn_CTRL);
> +
> +               return 0;
> +       }
> +
> +       free_irq(mps_port->tx_irq, mps_port);
> +err_no_txirq:
> +       free_irq(mps_port->rx_irq, mps_port);
> +err_no_rxirq:
> +       return ret;
> +}


> +static struct mps2_uart_port mps2_uart_ports[MPS2_MAX_PORTS];
> +
> +#ifdef CONFIG_SERIAL_MPS2_UART_CONSOLE
> +static void mps2_uart_console_putchar(struct uart_port *port, int ch)
> +{
> +       while (mps2_uart_read8(port, UARTn_STATE) & UARTn_STATE_TX_FULL)
> +               cpu_relax();

Infinite?

> +
> +       mps2_uart_write8(port, ch, UARTn_DATA);
> +}

> +static int mps2_init_port(struct mps2_uart_port *mps_port,
> +                       struct platform_device *pdev)
> +{
> +       int ret;
> +       struct resource *res;

Maybe:
       struct resource *res;
       int ret;
?

-- 
With Best Regards,
Andy Shevchenko


From james.morse at arm.com  Tue Feb 16 02:50:47 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 10:50:47 +0000
Subject: [PATCH] arm64: mark kernel text segment as MEMBLOCK_NOMAP
In-Reply-To: <1455528512-32491-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455528512-32491-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <56C2FF07.30205@arm.com>

Hi Ard,

On 15/02/16 09:28, Ard Biesheuvel wrote:
> Commit 752af28bd711 ("arm64: move kernel image to base of vmalloc area")
> moves the mapping of the kernel text and data segments out of the linear
> region, and takes care not to create a writable alias of the read-only
> kernel text segment by checking each memblock against overlap when the
> memblocks are mapped into the linear mapping.
> 
> However, it is more correct, and much simpler, to mark the [_stext, _etext]
> interval as MEMBLOCK_NOMAP. This will also prevent the interval from being
> omitted from the linear region, but this fact will now also be reflected
> in the output of pfn_valid(), and so code that expects any pfn_valid()
> page to be mapped and accessible (which is a reasonable assumption) does
> not get surprised by the text segment being inaccessible via the linear
> mapping.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---

With this patch on arm64/for-next/kernmap, I get the following KVM-related boot
failure on Juno:
-----------------------------%<-----------------------------
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
hw perfevents: enabled with armv8_pmuv3 PMU driver, 7 counters available
------------[ cut here ]------------
kernel BUG at ../arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:577!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 4 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc1+ #2022
Hardware name: ARM Juno development board (r1) (DT)
task: ffffffc976cf8000 ti: ffffffc976d60000 task.ti: ffffffc976d60000
PC is at create_hyp_mappings+0x144/0x148
LR is at create_hyp_mappings+0x7c/0x148

[SNIP]

[<ffffff80040abc14>] create_hyp_mappings+0x144/0x148
[<ffffff80040a9be8>] kvm_arch_init+0x198/0x53c
[<ffffff800409fe24>] kvm_init+0x38/0x290
[<ffffff80040a84e4>] arm_init+0x24/0x2c
[<ffffff8004082994>] do_one_initcall+0x94/0x198
[<ffffff8004a22b10>] kernel_init_freeable+0x148/0x1e8
[<ffffff800473e344>] kernel_init+0x20/0xe4
[<ffffff8004085cd0>] ret_from_fork+0x10/0x40

-----------------------------%<-----------------------------

The offending function is:
-----------------------------%<-----------------------------
static phys_addr_t kvm_kaddr_to_phys(void *kaddr)
{
	if (!is_vmalloc_addr(kaddr)) {
		BUG_ON(!virt_addr_valid(kaddr));
		return __pa(kaddr);
	} else {
		return page_to_phys(vmalloc_to_page(kaddr)) +
		       offset_in_page(kaddr);
	}
}
-----------------------------%<-----------------------------

When the BUG_ON() fires, kaddr points into the hole in the linear map left by
the kernel text.


> This should hopefully address the issue reported by James, but I suppose
> more work is required on the hibernate side to ensure the unmapped text
> region is preserved, since it is no longer covered by the linear mapping.

It does, now I have to work out how best to fix hibernate!


Thanks,

James


From arnd at arndb.de  Tue Feb 16 02:56:08 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 11:56:08 +0100
Subject: [PATCH v3 06/10] ARM: mps2: introduce MPS2 platform
In-Reply-To: <1455617295-23736-7-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-7-git-send-email-vladimir.murzin@arm.com>
Message-ID: <29457600.xRDuy0uVjW@wuerfel>

On Tuesday 16 February 2016 10:08:11 Vladimir Murzin wrote:
> The Cortex-M Prototyping System (or V2M-MPS2) is designed for
> prototyping and evaluation Cortex-M family of processors including the
> latest Cortex-M7
> 
> It comes with a range of useful peripherals including 8MB single cycle
> SRAM, 16MB PSRAM, Ethernet, QSVGA touch screen panel, 4bit RGB VGA
> connector, Audio, SPI and GPIO.
> 
> Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
> ---
>  arch/arm/Kconfig                 |    8 ++++++++
>  arch/arm/Makefile                |    1 +
>  arch/arm/mach-mps2/Makefile      |    1 +
>  arch/arm/mach-mps2/Makefile.boot |    3 +++
>  arch/arm/mach-mps2/dtmachine.c   |   21 +++++++++++++++++++++
> 

We are in the (slow) process of consolidating the ARM reference platforms
(versatile, integrator, realview, vexpress) into one place.

I'd suggest adding all this to the mach-vexpress directory rather than
a new directory, so we don't have another one to consolidate.

	Arnd


From sunil.kovvuri at gmail.com  Tue Feb 16 02:59:48 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Tue, 16 Feb 2016 16:29:48 +0530
Subject: [PATCH 0/3] net: thunderx: Miscellaneous fixes
Message-ID: <1455620391-31619-1-git-send-email-sunil.kovvuri@gmail.com>

From: Sunil Goutham <sgoutham at cavium.com>

This patch series fixes couple of issues w.r.t multiqset mode
and receive packet statastics.

Sunil Goutham (3):
  net: thunderx: Fix for multiqset not configured upon interface toggle
  net: thunderx: Fix for HW TSO not enabled for secondary qsets
  net: thunderx: Fix receive packet stats

 drivers/net/ethernet/cavium/thunder/nicvf_main.c   |   18 +++++++++---------
 drivers/net/ethernet/cavium/thunder/nicvf_queues.c |    8 ++------
 drivers/net/ethernet/cavium/thunder/nicvf_queues.h |    3 +--
 3 files changed, 12 insertions(+), 17 deletions(-)



From sunil.kovvuri at gmail.com  Tue Feb 16 02:59:49 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Tue, 16 Feb 2016 16:29:49 +0530
Subject: [PATCH 1/3] net: thunderx: Fix for multiqset not configured upon
 interface toggle
In-Reply-To: <1455620391-31619-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1455620391-31619-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <1455620391-31619-2-git-send-email-sunil.kovvuri@gmail.com>

From: Sunil Goutham <sgoutham at cavium.com>

When a interface is assigned morethan 8 queues and the logical interface
is toggled i.e down & up, additional queues or qsets are not initialized
as secondary qset count is being set to zero while tearing down.

Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/nicvf_main.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index c24cb2a..f8012c4 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -1125,7 +1125,6 @@ int nicvf_stop(struct net_device *netdev)
 
 	/* Clear multiqset info */
 	nic->pnicvf = nic;
-	nic->sqs_count = 0;
 
 	return 0;
 }
-- 
1.7.1



From sunil.kovvuri at gmail.com  Tue Feb 16 02:59:50 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Tue, 16 Feb 2016 16:29:50 +0530
Subject: [PATCH 2/3] net: thunderx: Fix for HW TSO not enabled for secondary
 qsets
In-Reply-To: <1455620391-31619-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1455620391-31619-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <1455620391-31619-3-git-send-email-sunil.kovvuri@gmail.com>

From: Sunil Goutham <sgoutham at cavium.com>

For secondary Qsets 'hw_tso' is not getting set as probe() returns
much earlier. Fixed it by moving silicon revision check.

Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/nicvf_main.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index f8012c4..84c5a33 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -1537,6 +1537,9 @@ static int nicvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 
 	nicvf_send_vf_struct(nic);
 
+	if (!pass1_silicon(nic->pdev))
+		nic->hw_tso = true;
+
 	/* Check if this VF is in QS only mode */
 	if (nic->sqs_mode)
 		return 0;
@@ -1556,9 +1559,6 @@ static int nicvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 
 	netdev->vlan_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO;
 
-	if (!pass1_silicon(nic->pdev))
-		nic->hw_tso = true;
-
 	netdev->netdev_ops = &nicvf_netdev_ops;
 	netdev->watchdog_timeo = NICVF_TX_TIMEOUT;
 
-- 
1.7.1



From sunil.kovvuri at gmail.com  Tue Feb 16 02:59:51 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Tue, 16 Feb 2016 16:29:51 +0530
Subject: [PATCH 3/3] net: thunderx: Fix receive packet stats
In-Reply-To: <1455620391-31619-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1455620391-31619-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <1455620391-31619-4-git-send-email-sunil.kovvuri@gmail.com>

From: Sunil Goutham <sgoutham at cavium.com>

Counting rx packets for every CQE_RX in CQ irq handler is incorrect.
Synchronization is missing when multiple queues are receiving packets
simultaneously. Like transmit packet stats use HW stats here.

Also removed unused 'cqe_type' parameter in nicvf_rcv_pkt_handler().

Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/nicvf_main.c   |   11 ++++++-----
 drivers/net/ethernet/cavium/thunder/nicvf_queues.c |    8 ++------
 drivers/net/ethernet/cavium/thunder/nicvf_queues.h |    3 +--
 3 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 84c5a33..a009bc3 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -574,8 +574,7 @@ static inline void nicvf_set_rxhash(struct net_device *netdev,
 
 static void nicvf_rcv_pkt_handler(struct net_device *netdev,
 				  struct napi_struct *napi,
-				  struct cmp_queue *cq,
-				  struct cqe_rx_t *cqe_rx, int cqe_type)
+				  struct cqe_rx_t *cqe_rx)
 {
 	struct sk_buff *skb;
 	struct nicvf *nic = netdev_priv(netdev);
@@ -591,7 +590,7 @@ static void nicvf_rcv_pkt_handler(struct net_device *netdev,
 	}
 
 	/* Check for errors */
-	err = nicvf_check_cqe_rx_errs(nic, cq, cqe_rx);
+	err = nicvf_check_cqe_rx_errs(nic, cqe_rx);
 	if (err && !cqe_rx->rb_cnt)
 		return;
 
@@ -682,8 +681,7 @@ loop:
 			   cq_idx, cq_desc->cqe_type);
 		switch (cq_desc->cqe_type) {
 		case CQE_TYPE_RX:
-			nicvf_rcv_pkt_handler(netdev, napi, cq,
-					      cq_desc, CQE_TYPE_RX);
+			nicvf_rcv_pkt_handler(netdev, napi, cq_desc);
 			work_done++;
 		break;
 		case CQE_TYPE_SEND:
@@ -1353,6 +1351,9 @@ void nicvf_update_stats(struct nicvf *nic)
 	drv_stats->tx_frames_ok = stats->tx_ucast_frames_ok +
 				  stats->tx_bcast_frames_ok +
 				  stats->tx_mcast_frames_ok;
+	drv_stats->rx_frames_ok = stats->rx_ucast_frames +
+				  stats->rx_bcast_frames +
+				  stats->rx_mcast_frames;
 	drv_stats->rx_drops = stats->rx_drop_red +
 			      stats->rx_drop_overrun;
 	drv_stats->tx_drops = stats->tx_drops;
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index d0d1b54..767347b 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -1329,16 +1329,12 @@ void nicvf_update_sq_stats(struct nicvf *nic, int sq_idx)
 }
 
 /* Check for errors in the receive cmp.queue entry */
-int nicvf_check_cqe_rx_errs(struct nicvf *nic,
-			    struct cmp_queue *cq, struct cqe_rx_t *cqe_rx)
+int nicvf_check_cqe_rx_errs(struct nicvf *nic, struct cqe_rx_t *cqe_rx)
 {
 	struct nicvf_hw_stats *stats = &nic->hw_stats;
-	struct nicvf_drv_stats *drv_stats = &nic->drv_stats;
 
-	if (!cqe_rx->err_level && !cqe_rx->err_opcode) {
-		drv_stats->rx_frames_ok++;
+	if (!cqe_rx->err_level && !cqe_rx->err_opcode)
 		return 0;
-	}
 
 	if (netif_msg_rx_err(nic))
 		netdev_err(nic->netdev,
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
index c5030a7..6673e11 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
@@ -338,8 +338,7 @@ u64  nicvf_queue_reg_read(struct nicvf *nic,
 /* Stats */
 void nicvf_update_rq_stats(struct nicvf *nic, int rq_idx);
 void nicvf_update_sq_stats(struct nicvf *nic, int sq_idx);
-int nicvf_check_cqe_rx_errs(struct nicvf *nic,
-			    struct cmp_queue *cq, struct cqe_rx_t *cqe_rx);
+int nicvf_check_cqe_rx_errs(struct nicvf *nic, struct cqe_rx_t *cqe_rx);
 int nicvf_check_cqe_tx_errs(struct nicvf *nic,
 			    struct cmp_queue *cq, struct cqe_send_t *cqe_tx);
 #endif /* NICVF_QUEUES_H */
-- 
1.7.1



From ard.biesheuvel at linaro.org  Tue Feb 16 02:57:36 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 11:57:36 +0100
Subject: [PATCH] arm64: mark kernel text segment as MEMBLOCK_NOMAP
In-Reply-To: <56C2FF07.30205@arm.com>
References: <1455528512-32491-1-git-send-email-ard.biesheuvel@linaro.org>
 <56C2FF07.30205@arm.com>
Message-ID: <CAKv+Gu_yTz-ohFPS0wMX42iCkDNaSwZoZ8Yi-zsZNNu1LNDkZQ@mail.gmail.com>

On 16 February 2016 at 11:50, James Morse <james.morse at arm.com> wrote:
> Hi Ard,
>
> On 15/02/16 09:28, Ard Biesheuvel wrote:
>> Commit 752af28bd711 ("arm64: move kernel image to base of vmalloc area")
>> moves the mapping of the kernel text and data segments out of the linear
>> region, and takes care not to create a writable alias of the read-only
>> kernel text segment by checking each memblock against overlap when the
>> memblocks are mapped into the linear mapping.
>>
>> However, it is more correct, and much simpler, to mark the [_stext, _etext]
>> interval as MEMBLOCK_NOMAP. This will also prevent the interval from being
>> omitted from the linear region, but this fact will now also be reflected
>> in the output of pfn_valid(), and so code that expects any pfn_valid()
>> page to be mapped and accessible (which is a reasonable assumption) does
>> not get surprised by the text segment being inaccessible via the linear
>> mapping.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> ---
>
> With this patch on arm64/for-next/kernmap, I get the following KVM-related boot
> failure on Juno:
> -----------------------------%<-----------------------------
> RPC: Registered named UNIX socket transport module.
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> hw perfevents: enabled with armv8_pmuv3 PMU driver, 7 counters available
> ------------[ cut here ]------------
> kernel BUG at ../arch/arm64/kvm/../../../arch/arm/kvm/mmu.c:577!
> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 4 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc1+ #2022
> Hardware name: ARM Juno development board (r1) (DT)
> task: ffffffc976cf8000 ti: ffffffc976d60000 task.ti: ffffffc976d60000
> PC is at create_hyp_mappings+0x144/0x148
> LR is at create_hyp_mappings+0x7c/0x148
>
> [SNIP]
>
> [<ffffff80040abc14>] create_hyp_mappings+0x144/0x148
> [<ffffff80040a9be8>] kvm_arch_init+0x198/0x53c
> [<ffffff800409fe24>] kvm_init+0x38/0x290
> [<ffffff80040a84e4>] arm_init+0x24/0x2c
> [<ffffff8004082994>] do_one_initcall+0x94/0x198
> [<ffffff8004a22b10>] kernel_init_freeable+0x148/0x1e8
> [<ffffff800473e344>] kernel_init+0x20/0xe4
> [<ffffff8004085cd0>] ret_from_fork+0x10/0x40
>
> -----------------------------%<-----------------------------
>
> The offending function is:
> -----------------------------%<-----------------------------
> static phys_addr_t kvm_kaddr_to_phys(void *kaddr)
> {
>         if (!is_vmalloc_addr(kaddr)) {
>                 BUG_ON(!virt_addr_valid(kaddr));
>                 return __pa(kaddr);
>         } else {
>                 return page_to_phys(vmalloc_to_page(kaddr)) +
>                        offset_in_page(kaddr);
>         }
> }
> -----------------------------%<-----------------------------
>
> When the BUG_ON() fires, kaddr points into the hole in the linear map left by
> the kernel text.
>

I fixed this in the v6 series I am about to send out. I replaced the
BUG_ON() condition with 'memblock_is_memory(__pa(kaddr))', so that it
takes linear addresses pointing into  MEMBLOCK_NOMAP regions into
account as well.

>
>> This should hopefully address the issue reported by James, but I suppose
>> more work is required on the hibernate side to ensure the unmapped text
>> region is preserved, since it is no longer covered by the linear mapping.
>
> It does, now I have to work out how best to fix hibernate!
>

Indeed. The alternative would be to map the [_stext, _etext] interval
into the linear region as a ro/nx alias of the actual mapping in the
vmalloc region. That would probably make your life easier, but I am
not convinced the overall result is better.

-- 
Ard.


From robin.murphy at arm.com  Tue Feb 16 02:57:49 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue, 16 Feb 2016 10:57:49 +0000
Subject: [PATCH v2] arm64: add alignment fault hanling
In-Reply-To: <20160216103104.GC14509@arm.com>
References: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
 <20160216103104.GC14509@arm.com>
Message-ID: <56C300AD.8070505@arm.com>

On 16/02/16 10:31, Will Deacon wrote:
> On Tue, Feb 16, 2016 at 04:44:35AM +0000, EunTaik Lee wrote:
>> Userspace memory is mapped as below:
>> F2A7F000--F2A7FFFF Normal Memory
>> F2A80000--F2A80FFF Device nGnRnE
>>
>> And that userspace application makes a system call
>> as below:
>>
>> -009 |do_strncpy_from_user(inline)
>> -009 |strncpy_from_user()
>> -010 |getname_flags()
>> -011 |user_path_at_empty()
>> -012 |user_path_at()
>> -013 |SYSC_faccessat(inline)
>> -013 |sys_faccessat()
>> -014 |__sys_trace(asm)
>>   --> |exception
>>
>> The string spans from 0xF2A7FFC1 to 0xF2A7FFFB.
>>
>> When do_strncpy_from_user() reads the last (unsigned long)
>> value, the alignement fault is triggered. The 8 byte
>> from 0xF2A7FFC1 spans to the next page that is mapped as
>> Device nGnRnE, which does not allow an unaligned access,
>> causes the abort.
>>
>> The instruction which caused the alignment fault is registered
>> in the fixup table but the exception handler does not reach there.
>>
>> This patch registers a alignment fault handler and fixes up the
>> pc if appropriate.
>
> As discussed with Catalin previously, we should solve this by adding a
> guard page rather than handling the fault.

...especially since we may not even get a fault. See "Crossing a page 
boundary with different memory types or Shareability attributes" in the 
UNPREDICTABLE spec (K1.2.10 in the latest ARMv8 ARM).

Robin.

>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



From catalin.marinas at arm.com  Tue Feb 16 02:57:59 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 16 Feb 2016 10:57:59 +0000
Subject: [PATCH] arm64: mark kernel text segment as MEMBLOCK_NOMAP
In-Reply-To: <CAKv+Gu9uwcjc0dgO+KOrmhJ=Kyc1ojD1FF32gu7v7VFNFqKpnw@mail.gmail.com>
References: <1455528512-32491-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160215114505.GE13683@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-Y-k_LAbFZJjiPuHq6ssaFCb3WMG_fVGx3ODrvb+hEUQ@mail.gmail.com>
 <20160215120809.GF13683@e104818-lin.cambridge.arm.com>
 <CAKv+Gu9uwcjc0dgO+KOrmhJ=Kyc1ojD1FF32gu7v7VFNFqKpnw@mail.gmail.com>
Message-ID: <20160216105759.GC19413@e104818-lin.cambridge.arm.com>

On Tue, Feb 16, 2016 at 09:49:48AM +0100, Ard Biesheuvel wrote:
> On 15 February 2016 at 13:08, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Mon, Feb 15, 2016 at 12:53:59PM +0100, Ard Biesheuvel wrote:
> >> On 15 February 2016 at 12:45, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> > Ard, I'm about to drop the kernel memory map patches from -next. There
> >> > are several issues like KASAN (which may as well be a KASAN bug but I
> >> > haven't got to the bottom of it yet), initrd (you have patches but
> >> > require additional acks).
> >> >
> >> > I'll keep your stuff on the for-next/kernmap branch and do further
> >> > debugging. If it stabilises in the next 1-2 weeks, I'll merge it into
> >> > for-next/core for 4.6, otherwise, it will have to wait. I would really
> >> > like these patches merged but it looks like they need wider testing.
> > [...]
> >> If you are going to drop it for now anyway, I can do a v6sub1 with
> >> this issue and the initrd issue addressed, but also an issue with the
> >> KVM ksym ref patch with GCC 4.8. Since these issues affect
> >> bisectability, I'd prefer to rebase entirely, and fold all the fixes
> >> rather than apply them on top.
> >
> > That's fine. I'll push one more patch to the for-next/pgtable branch,
> > converting __set_fixmap_offset() back to a macro as it broke other
> > architectures. Otherwise it is not rebased and I'll merge it into
> > for-next core.
> 
> If you are doing for-next/core from scratch, perhaps it is better to
> squash the fixmap patches as well?

I could, assuming you were the only one using the for-next/pgtable
branch and I won't get pull requests against it (I usually cherry-pick
the patches, so not a problem).

-- 
Catalin


From gregory.clement at free-electrons.com  Tue Feb 16 02:51:44 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 11:51:44 +0100
Subject: [PATCH 08/13] ARM: mvebu: enable SRAM support in
 mvebu_v7_defconfig
In-Reply-To: <1448178839-3541-9-git-send-email-mw@semihalf.com> (Marcin
 Wojtas's message of "Sun, 22 Nov 2015 08:53:54 +0100")
References: <1448178839-3541-1-git-send-email-mw@semihalf.com>
 <1448178839-3541-9-git-send-email-mw@semihalf.com>
Message-ID: <874md9udvj.fsf@free-electrons.com>

Hi Marcin,
 
 On dim., nov. 22 2015, Marcin Wojtas <mw at semihalf.com> wrote:

As this config will be needed in any case, I have applied on
mvebu/defconfig. I also added a commit log.

Thanks,

Gregory

> Signed-off-by: Marcin Wojtas <mw at semihalf.com>
> ---
>  arch/arm/configs/mvebu_v7_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
> index c6729bf..fe57e20 100644
> --- a/arch/arm/configs/mvebu_v7_defconfig
> +++ b/arch/arm/configs/mvebu_v7_defconfig
> @@ -58,6 +58,7 @@ CONFIG_MTD_M25P80=y
>  CONFIG_MTD_NAND=y
>  CONFIG_MTD_NAND_PXA3xx=y
>  CONFIG_MTD_SPI_NOR=y
> +CONFIG_SRAM=y
>  CONFIG_EEPROM_AT24=y
>  CONFIG_BLK_DEV_SD=y
>  CONFIG_ATA=y
> -- 
> 1.8.3.1
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From arnd at arndb.de  Tue Feb 16 02:58:42 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 11:58:42 +0100
Subject: [PATCH v3 08/10] ARM: configs: add MPS2 defconfig
In-Reply-To: <1455617295-23736-9-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-9-git-send-email-vladimir.murzin@arm.com>
Message-ID: <2680417.bULLX3O66Y@wuerfel>

On Tuesday 16 February 2016 10:08:13 Vladimir Murzin wrote:
> This patch adds a new config for MPS2 platform.
> 
> Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
> ---
>  arch/arm/configs/mps2_defconfig |  112 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 112 insertions(+)
>  create mode 100644 arch/arm/configs/mps2_defconfig
> 
> diff --git a/arch/arm/configs/mps2_defconfig b/arch/arm/configs/mps2_defconfig
> new file mode 100644
> index 0000000..c36c519
> --- /dev/null
> +++ b/arch/arm/configs/mps2_defconfig
> @@ -0,0 +1,112 @@
> +# CONFIG_USELIB is not set
> +CONFIG_NO_HZ_IDLE=y
> +CONFIG_HIGH_RES_TIMERS=y
> +CONFIG_LOG_BUF_SHIFT=16
> +CONFIG_CC_OPTIMIZE_FOR_SIZE=y
> +# CONFIG_UID16 is not set
> +# CONFIG_BASE_FULL is not set
> +# CONFIG_FUTEX is not set
> +# CONFIG_EPOLL is not set
> +# CONFIG_SIGNALFD is not set
> +# CONFIG_EVENTFD is not set
> +# CONFIG_AIO is not set
> +CONFIG_EMBEDDED=y

Why CONFIG_EMBEDDED? You probably mean CONFIG_EXPERT, but then what do
you need that for?

	Arnd


From arnd at arndb.de  Tue Feb 16 03:01:16 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 12:01:16 +0100
Subject: [PATCH v3 09/10] ARM: dts: introduce MPS2 AN385/AN386
In-Reply-To: <1455617295-23736-10-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-10-git-send-email-vladimir.murzin@arm.com>
Message-ID: <7562697.iiO7rmWd7c@wuerfel>

On Tuesday 16 February 2016 10:08:14 Vladimir Murzin wrote:
> +
> +       ethernet at 40200000 {
> +               compatible = "smsc,lan9220", "smsc,lan9115";
> +               reg = <0x40200000 0x10000>;
> +               interrupts = <13>;
> +               interrupt-parent = <&nvic>;
> +               smsc,irq-active-high;
> +       };
> +};
> +
> 

This node seems slightly misplaced. Is there some external bus interface
that this is connected to? The address suggests that it should be somewhere
below the /soc node, and you probably want to list the external bus
interface with a "ranges" property that identifies the addresses visibile
there, and put the external chip under there.

	Arnd


From gnomes at lxorguk.ukuu.org.uk  Tue Feb 16 03:02:17 2016
From: gnomes at lxorguk.ukuu.org.uk (One Thousand Gnomes)
Date: Tue, 16 Feb 2016 11:02:17 +0000
Subject: [PATCH v3 04/10] serial: mps2-uart: add MPS2 UART driver
In-Reply-To: <1455617295-23736-5-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-5-git-send-email-vladimir.murzin@arm.com>
Message-ID: <20160216110217.3de7c007@lxorguk.ukuu.org.uk>


> +static void mps2_uart_set_termios(struct uart_port *port,
> +	struct ktermios *new, struct ktermios *old)

Not that I care much but you might not want to call it "new". People get
upset when their syntax aware editors get confused by C++ keywords 8)

> +{
> +	unsigned long flags;
> +	unsigned int baud, bauddiv;
> +
> +	new->c_cflag &= ~(CRTSCTS | CMSPAR);
> +	new->c_cflag &= ~CSIZE;
> +	new->c_cflag |= CS8;
> +	new->c_cflag &= ~PARENB;
> +	new->c_cflag &= ~CSTOPB;
> +
> +	baud = uart_get_baud_rate(port, new, old,
> +			DIV_ROUND_CLOSEST(port->uartclk, UARTn_BAUDDIV_MASK),
> +			DIV_ROUND_CLOSEST(port->uartclk, 16));
> +
> +	bauddiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
> +
> +	spin_lock_irqsave(&port->lock, flags);
> +
> +	uart_update_timeout(port, new->c_cflag, baud);
> +	mps2_uart_write32(port, bauddiv, UARTn_BAUDDIV);

This should also set the baud bits back in the termios struct
accordingly. 

	if (tty_termios_baud_rate(new))
		tty_termios_encode_baud_rate(new, baud, baud);


Not a big deal and could certainly be a follow up patch after it's merged.

Alan


From arnd at arndb.de  Tue Feb 16 03:05:37 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 12:05:37 +0100
Subject: [PATCH v3 00/10] Support for Cortex-M Prototyping System
In-Reply-To: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <22011981.Gqc7zXAZ81@wuerfel>

On Tuesday 16 February 2016 10:08:05 Vladimir Murzin wrote:
> Hi,
> 
> This patch series provide the basic support for running ucLinux on V2M-MPS2
> platform.
> 
> With these patches applied ucLinux can be run on both HW and FVP models
> with Cortex-M3/M4/M7 configurations.

Looks very nice overall now. I have mentioned a few details that I noticed
but no show-stoppers.

Most important question for me is how this is going to be maintained
in the long run. Can you add a patch to list the added files in
MAINTAINERS?

My preference from the arm-soc perspective would be to get pull requests for
this together with vexpress and juno through the existing maintainers
(Liviu, Sudeep, Lorenzo), and have you send your patches to them. Does
that work for you all?

	Arnd


From paulmck at linux.vnet.ibm.com  Tue Feb 16 03:13:40 2016
From: paulmck at linux.vnet.ibm.com (Paul E. McKenney)
Date: Tue, 16 Feb 2016 03:13:40 -0800
Subject: Writes, smp_wmb(), and transitivity?
In-Reply-To: <20160216095319.GA14509@arm.com>
References: <20160215175825.GA15878@linux.vnet.ibm.com>
 <20160215185832.GQ6298@arm.com>
 <20160215203512.GL6719@linux.vnet.ibm.com>
 <20160216095319.GA14509@arm.com>
Message-ID: <20160216111340.GS6719@linux.vnet.ibm.com>

On Tue, Feb 16, 2016 at 09:53:20AM +0000, Will Deacon wrote:
> On Mon, Feb 15, 2016 at 12:35:12PM -0800, Paul E. McKenney wrote:
> > On Mon, Feb 15, 2016 at 06:58:32PM +0000, Will Deacon wrote:
> > > On Mon, Feb 15, 2016 at 09:58:25AM -0800, Paul E. McKenney wrote:
> > > > Some architectures provide local transitivity for a chain of threads doing
> > > > writes separated by smp_wmb(), as exemplified by the litmus tests below.
> > > > The pattern is that each thread writes to a its own variable, does an
> > > > smp_wmb(), then writes a different value to the next thread's variable.
> > > > 
> > > > I don't know of a use of this, but if everyone supports it, it might
> > > > be good to mandate it.  Status quo is that smp_wmb() is non-transitive,
> > > > so it currently isn't supported.
> > > > 
> > > > Anyone know of any architectures that do -not- support this?
> > > > 
> > > > Assuming all architectures -do- support this, any arguments -against-
> > > > officially supporting it in Linux?
> > > > 
> > > > 							Thanx, Paul
> > > > 
> > > > ------------------------------------------------------------------------
> > > > 
> > > > Two threads:
> > > > 
> > > > 	int a, b;
> > > > 
> > > > 	void thread0(void)
> > > > 	{
> > > > 		WRITE_ONCE(a, 1);
> > > > 		smp_wmb();
> > > > 		WRITE_ONCE(b, 2);
> > > > 	}
> > > > 
> > > > 	void thread1(void)
> > > > 	{
> > > > 		WRITE_ONCE(b, 1);
> > > > 		smp_wmb();
> > > > 		WRITE_ONCE(a, 2);
> > > > 	}
> > > > 
> > > > 	/* After all threads have completed and the dust has settled... */
> > > > 
> > > > 	BUG_ON(a == 1 && b == 1);
> > > 
> > > My understanding is that this test, and the generalisation to n threads,
> > > is forbidden on ARM. However, the transitivity of DMB ST (used to
> > > construct smp_wmb()) has been the subject of long debates, because we
> > > allow the following test:
> > > 
> > > 
> > > P0:
> > > Wx = 1
> > > 
> > > P1:
> > > Rx == 1
> > > DMB ST
> > > Wy = 1
> > > 
> > > P2:
> > > Ry == 1
> > > <addr dep>
> > > Rx == 0
> > > 
> > > 
> > > so I'd be uneasy about saying "it's all transitive".
> > 
> > Agreed!  For one thing, doesn't DMB ST need writes on both sides?
> 
> Yes, but it's a common trap that people fall into where they think the
> above is forbidden because the DMB ST in P1 should order P0's write
> before its own write of y.

True enough.

> > But that is one reason that I am only semi-enthusiastic about this.
> > The potentially locally transitive case is -very- restrictive, applying
> > only to situations where -all- accesses are writes.
> 
> I think that we will confuse people more by trying to describe the
> restricted case where we provide order than if we blanket say that its
> not transitive. I know Linus prefers to be as strong as possible, but
> this doesn't look like a realistic programming paradigm and having a
> straightforward rule that "rmb and wmb are not transitive" is much
> easier for people to deal with in my opinion.

That is a good explanation of why I am only semi-enthusiastic about
this.  ;-)

							Thanx, Paul



From james.morse at arm.com  Tue Feb 16 03:13:05 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 11:13:05 +0000
Subject: [PATCH] arm64: mark kernel text segment as MEMBLOCK_NOMAP
In-Reply-To: <CAKv+Gu_yTz-ohFPS0wMX42iCkDNaSwZoZ8Yi-zsZNNu1LNDkZQ@mail.gmail.com>
References: <1455528512-32491-1-git-send-email-ard.biesheuvel@linaro.org>	<56C2FF07.30205@arm.com>
 <CAKv+Gu_yTz-ohFPS0wMX42iCkDNaSwZoZ8Yi-zsZNNu1LNDkZQ@mail.gmail.com>
Message-ID: <56C30441.1080003@arm.com>

On 16/02/16 10:57, Ard Biesheuvel wrote:
> On 16 February 2016 at 11:50, James Morse <james.morse at arm.com> wrote:
>> On 15/02/16 09:28, Ard Biesheuvel wrote:
>>> This should hopefully address the issue reported by James, but I suppose
>>> more work is required on the hibernate side to ensure the unmapped text
>>> region is preserved, since it is no longer covered by the linear mapping.
>>
>> It does, now I have to work out how best to fix hibernate!
>>
> 
> Indeed. The alternative would be to map the [_stext, _etext] interval
> into the linear region as a ro/nx alias of the actual mapping in the
> vmalloc region. That would probably make your life easier, but I am
> not convinced the overall result is better.

I assumed you would NACK any approach that looked like that:
It could be done temporarily while the memory snapshot is being taken, only
swsusp_save() would see this mapping, it can be removed again afterwards. But
pfn_valid() will still say those pages aren't there, and there is no
memblock_clear_nomap() to change this.


The current approach involves copying the kernel text into pages that are saved,
and having two lists of pages that need restoring. (wheels within wheels!)
Pretty unpleasant, and requires another patch in the core code, so likely won't
be possible for v4.6. I should have the patches out for review later today.



James


From brian.starkey at arm.com  Tue Feb 16 03:14:26 2016
From: brian.starkey at arm.com (Brian Starkey)
Date: Tue, 16 Feb 2016 11:14:26 +0000
Subject: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag
In-Reply-To: <20160209091501.GA23507@e106950-lin.cambridge.arm.com>
References: <cover.1454950917.git.brian.starkey@arm.com>
 <9085d37fa97a762a46b9d58719c085368682c64f.1454950917.git.brian.starkey@arm.com>
 <20160208183006.GA8429@kroah.com>
 <20160209091501.GA23507@e106950-lin.cambridge.arm.com>
Message-ID: <20160216111426.GA22133@e106950-lin.cambridge.arm.com>

Hi Greg,

Is the documentation OK? Is there any chance of you picking up this
series?

I can rebase onto -next if that's the right place, but they still apply
on 4.5-rc4 and fix a panic, so I thought perhaps they could make 4.5.

Thanks,
Brian

On Tue, Feb 09, 2016 at 09:15:02AM +0000, Brian Starkey wrote:
>Hi Greg,
>
>On Mon, Feb 08, 2016 at 10:30:06AM -0800, Greg KH wrote:
>>On Mon, Feb 08, 2016 at 05:30:50PM +0000, Brian Starkey wrote:
>>>diff --git a/include/linux/io.h b/include/linux/io.h
>>>index 32403b5..e2c8419 100644
>>>--- a/include/linux/io.h
>>>+++ b/include/linux/io.h
>>>@@ -135,6 +135,7 @@ enum {
>>> 	/* See memremap() kernel-doc for usage description... */
>>> 	MEMREMAP_WB = 1 << 0,
>>> 	MEMREMAP_WT = 1 << 1,
>>>+	MEMREMAP_WC = 1 << 2,
>>
>>You didn't update the documentation :(
>>
>
>Maybe I missed something, but I don't think there's anything to update
>here? Like the comment says, the flags are documented in the memremap()
>kernel-doc (which I did update - see the next two hunks of this patch).
>
>Thanks,
>
>Brian


From arnd at arndb.de  Tue Feb 16 03:26:23 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 12:26:23 +0100
Subject: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
In-Reply-To: <m3d1rxqa4p.fsf@t19.piap.pl>
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <4239208.KBB6rfivoa@wuerfel> <m3d1rxqa4p.fsf@t19.piap.pl>
Message-ID: <2702068.KRp0Bplb5Q@wuerfel>

On Tuesday 16 February 2016 10:26:14 Krzysztof Ha?asa wrote:
> Arnd Bergmann <arnd at arndb.de> writes:
> 
> > The barriers on a spinlock synchronize between CPUs but not an external
> > bus, so (on some architectures) a spinlock protecting an MMIO register
> > does not guarantee that two CPUs doing
> >
> >       spin_lock();
> >       __raw_writel(address);
> >       __raw_writel(data);
> >       spin_unlock();
> >
> > would cause pairs of address/data to be seen on the bus.
> >
> > Of course this is meaningless on ixp4xx, as there is only one CPU.
> 
> I still don't get it. If the spinlocks synchronize between CPUs, there
> can only be one CPU (or core) doing the pair of raw_writel(), so how
> would it be possible to not get the address/data pair written out?
> IOW, how is it different from a system with a single CPU?

Both writes leave the CPU core within the spinlock but are not serialized
with anything else, so there is no ordering between the CPUs when they
enter the shared bus, other than having address before data. You'd
expect to see address0, data0, address1, data1, but it could also
be e.g. address0, address1, data1, data0.

> > On powerpc, we have in_le32/in_be32 for SoC-internal register access,
> > while only PCI devices are allowed to be accessed using readl().
> 
> Yeah, this seems like a sane solution.
> 
> > I would suggest using an ixp4xx specific set of accessors that comes down
> > to either readl() or ioread32_be(), depending on whether CONFIG_CPU_BIG_ENDIAN
> > is set. That makes it clear that there is a magic bus involved and that it
> > works on this platform but not in portable code.
> 
> Hmm. This is actually the opposite - while there may be some magic
> (swapping) in readl() and friends, there is absolutely no magic in the
> __raw_readl() etc. They are essentially equivalent to
> *(volatile u32 *)ptr. This is constant and doesn't depend on endianess,
> PCI, anything.

The point is more what the common case is. Almost all machines we support
have fixed-endian devices, and the drivers are correct when using readl()
or in_le32() but are not endian-safe when using __raw_readl().

Using __raw_readl() has the big danger of someone accidentally "fixing"
the driver to work like all the others in order to solve a theoretical
endian problem, while it should really be made obvious that the hardware
actively swaps its data on the bus.

	Arnd


From rabin.vincent at axis.com  Tue Feb 16 03:28:41 2016
From: rabin.vincent at axis.com (Rabin Vincent)
Date: Tue, 16 Feb 2016 12:28:41 +0100
Subject: [PATCH] clocksource: arm_global_timer: register delay timer
In-Reply-To: <55D62468.4050404@linaro.org>
References: <1439991818-31989-1-git-send-email-rabin.vincent@axis.com>
 <55D62468.4050404@linaro.org>
Message-ID: <20160216112841.GA26773@axis.com>

On Thu, Aug 20, 2015 at 09:03:04PM +0200, Daniel Lezcano wrote:
> On 08/19/2015 03:43 PM, Rabin Vincent wrote:
> > Provide a delay timer using the lower 32-bits of the global timer so
> > that we can use that instead of having to calibrating delays.
> >
> > Signed-off-by: Rabin Vincent <rabin.vincent at axis.com>
> 
> Applied to my tree for 4.4

This seems to have got lost?  I don't see it in v4.4 or current mainline
(v4.5-rc4).  It still applies cleanly.

Thanks.


From arnd at arndb.de  Tue Feb 16 03:35:26 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 12:35:26 +0100
Subject: [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
In-Reply-To: <alpine.DEB.2.02.1602151643150.27008@kaball.uk.xensource.com>
References: <1455278707-2008263-1-git-send-email-arnd@arndb.de>
 <alpine.DEB.2.02.1602151643150.27008@kaball.uk.xensource.com>
Message-ID: <2801550.oZPkqjv8nW@wuerfel>

On Monday 15 February 2016 16:51:08 Stefano Stabellini wrote:
> > 
> > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> > index 8ea45a5cd806..fd3d6fd290a9 100644
> > --- a/drivers/video/fbdev/Kconfig
> > +++ b/drivers/video/fbdev/Kconfig
> > @@ -2241,6 +2241,7 @@ config FB_VIRTUAL
> >  config XEN_FBDEV_FRONTEND
> >       tristate "Xen virtual frame buffer support"
> >       depends on FB && XEN
> > +     depends on INPUT || !INPUT_MISC
> >       select FB_SYS_FILLRECT
> >       select FB_SYS_COPYAREA
> >       select FB_SYS_IMAGEBLIT
> 
> This looks very hackish. Couldn't we just do the following?
> 
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 8ea45a5..3c15f6d 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2246,7 +2246,7 @@ config XEN_FBDEV_FRONTEND
>         select FB_SYS_IMAGEBLIT
>         select FB_SYS_FOPS
>         select FB_DEFERRED_IO
> -       select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
> +       select INPUT_XEN_KBDDEV_FRONTEND if (INPUT && INPUT_MISC)
>         select XEN_XENBUS_FRONTEND
>         default y
>         help
> 

No, that doesn't solve the problem:

If XEN_FBDEV_FRONTEND=y, INPUT=m and INPUT_MISC=y, we would still
get INPUT_XEN_KBDDEV_FRONTEND=y, which cannot work because of INPUT=m.

INPUT_MISC already depends on INPUT, so your change has no effect
at all.

	Arnd


From arnd at arndb.de  Tue Feb 16 03:37:57 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 12:37:57 +0100
Subject: [PATCH] rtc: mt6397: Add platform device ID table
In-Reply-To: <56C1E5C8.6040007@osg.samsung.com>
References: <1455016095-13724-1-git-send-email-javier@osg.samsung.com>
 <1455501497.7263.4.camel@mtksdaap41> <56C1E5C8.6040007@osg.samsung.com>
Message-ID: <2416670.q30ahHlzPm@wuerfel>

On Monday 15 February 2016 11:50:48 Javier Martinez Canillas wrote:
> 
> On 02/14/2016 10:58 PM, Eddie Huang wrote:
> 
> [snip]
> 
> >> @@ -412,6 +418,7 @@ static struct platform_driver mtk_rtc_driver = {
> >>      },
> >>      .probe  = mtk_rtc_probe,
> >>      .remove = mtk_rtc_remove,
> >> +    .id_table = mt6397_rtc_id,
> >>   };
> >>
> >>   module_platform_driver(mtk_rtc_driver);
> >> @@ -419,4 +426,3 @@ module_platform_driver(mtk_rtc_driver);
> >>   MODULE_LICENSE("GPL v2");
> >>   MODULE_AUTHOR("Tianping Fang <tianping.fang at mediatek.com>");
> >>   MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC");
> >> -MODULE_ALIAS("platform:mt6397-rtc");
> >
> > This patch looks good to me, but I am wondering, since we tend to use
> > device tree method to match driver, do we still need support platform
> > device ID ?
> >
> 
> I'm not familiar with neither this IP block nor the SoC so it is up to
> you. I just noticed this issue when reviewing a regulator driver for a
> similar PMIC posted by someone from mediatek.
> 
> I thought platform device was needed since the driver has a MODULE_ALIAS()
> but please let me know what you prefer and I can re-spin the patch and
> just remove the MODULE_ALIAS() if that makes more sense for this platform.
>   
> 

I agree. We can alway add a MODULE_DEVICE_TABLE() if we get multiple
users of this driver on architectures that don't use devicetree yet.

	Arnd


From daniel.lezcano at linaro.org  Tue Feb 16 03:42:25 2016
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Tue, 16 Feb 2016 11:42:25 +0000
Subject: [PATCH] clocksource: arm_global_timer: register delay timer
In-Reply-To: <20160216112841.GA26773@axis.com>
References: <1439991818-31989-1-git-send-email-rabin.vincent@axis.com>
 <55D62468.4050404@linaro.org> <20160216112841.GA26773@axis.com>
Message-ID: <56C30B21.4000707@linaro.org>

On 02/16/2016 11:28 AM, Rabin Vincent wrote:
> On Thu, Aug 20, 2015 at 09:03:04PM +0200, Daniel Lezcano wrote:
>> On 08/19/2015 03:43 PM, Rabin Vincent wrote:
>>> Provide a delay timer using the lower 32-bits of the global timer so
>>> that we can use that instead of having to calibrating delays.
>>>
>>> Signed-off-by: Rabin Vincent <rabin.vincent at axis.com>
>>
>> Applied to my tree for 4.4
>
> This seems to have got lost?  I don't see it in v4.4 or current mainline
> (v4.5-rc4).  It still applies cleanly.

Oops, right.

Fixed now [1]. Thanks for the heads up.

   -- Daniel

[1] 
https://git.linaro.org/people/daniel.lezcano/linux.git/commit/23cb25d0f407e83be10747258092843e8e20d535

-- 
  <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog



From linux at arm.linux.org.uk  Tue Feb 16 03:47:33 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 16 Feb 2016 11:47:33 +0000
Subject: [PATCH] ARM: don't print missing L2 cache as error
In-Reply-To: <d67716f9edf83700b18532eb66980316@agner.ch>
References: <1453944439-1070-1-git-send-email-stefan@agner.ch>
 <d67716f9edf83700b18532eb66980316@agner.ch>
Message-ID: <20160216114733.GC19428@n2100.arm.linux.org.uk>

On Mon, Feb 15, 2016 at 07:19:20PM -0800, Stefan Agner wrote:
> Hi Russel,
> 
> Any comment to this? Currently the kernel prints an error message as
> follows on the platform at hand:
> [    0.000000] L2C: failed to init: -19

An alternative patch (8499/1) is queued for the next merge window, as it
isn't a regression and isn't a bug per se.

Thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From szabolcs.nagy at arm.com  Tue Feb 16 03:48:14 2016
From: szabolcs.nagy at arm.com (Szabolcs Nagy)
Date: Tue, 16 Feb 2016 11:48:14 +0000
Subject: [PATCH] arm64: Add support for Half precision floating point
In-Reply-To: <20160128160022.GM775@arm.com>
References: <1453823566-26742-1-git-send-email-suzuki.poulose@arm.com>
 <20160126160257.GB28238@arm.com>
 <20160126161151.GE14823@e104818-lin.cambridge.arm.com>
 <20160128160022.GM775@arm.com>
Message-ID: <56C30C7E.1030005@arm.com>

On 28/01/16 16:00, Will Deacon wrote:
> On Tue, Jan 26, 2016 at 04:11:51PM +0000, Catalin Marinas wrote:
>> On Tue, Jan 26, 2016 at 04:02:58PM +0000, Will Deacon wrote:
>>> On Tue, Jan 26, 2016 at 03:52:46PM +0000, Suzuki K Poulose wrote:
>>>> +#define HWCAP_FPHP		(1 << 9)
>>>> +#define HWCAP_ASIMDHP		(1 << 10)
>>>
>>> Where did we get to with the mrs trapping you proposed here?
>>>
>>>   http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374609.html
>>>
>>> At some point, we need to consider whether or not we want to continue
>>> adding new HWCAPs or whether your suggestion above is actually useful
>>> to userspace.
>>
>> IMO, even if we merge the MRS emulation, I would still like to see
>> HWCAPs exported. We are not short on bits yet (53 to go ;)).
> 
> I'm less keen. HWCAPs don't align well with the way that the ARM
> architecture versions features and we should be encouraging people to
> use the MRS emulation if it exists.
> 
>>> Did the libc guys get anywhere with a prototype? What do we need to do
>>> to make progress with it?
>>
>> This investigation should indeed continue but I think it is orthogonal.
> 
> Not if its intended to replace HWCAPs in the longterm.
> 

userspace needs HWCAP bits independently of the MIDR emulation.

MIDR cannot replace HWCAP:

- MIDR does not map to features in a future-proof way
  (we don't know which MIDR will indicate fp16 availability)

- MIDR would be useful for more fine-grained uarch specific
  tuning decisions, HWCAP is for arch extensions like fp16.

- We don't yet know if the proposed MIDR emulation solves
  all userspace issues we want it to solve. I'll try to
  investigate that as well as the alternative VDSO based
  approach (if VDSO can work, that would be better for
  userspace). There are nasty issues here so the conclusion
  might take a while, but that should not hold up HWCAPs.

thanks



From will.deacon at arm.com  Tue Feb 16 03:53:35 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 16 Feb 2016 11:53:35 +0000
Subject: [PATCH] arm64: Add support for Half precision floating point
In-Reply-To: <56C30C7E.1030005@arm.com>
References: <1453823566-26742-1-git-send-email-suzuki.poulose@arm.com>
 <20160126160257.GB28238@arm.com>
 <20160126161151.GE14823@e104818-lin.cambridge.arm.com>
 <20160128160022.GM775@arm.com> <56C30C7E.1030005@arm.com>
Message-ID: <20160216115335.GE14509@arm.com>

On Tue, Feb 16, 2016 at 11:48:14AM +0000, Szabolcs Nagy wrote:
> On 28/01/16 16:00, Will Deacon wrote:
> > On Tue, Jan 26, 2016 at 04:11:51PM +0000, Catalin Marinas wrote:
> >> On Tue, Jan 26, 2016 at 04:02:58PM +0000, Will Deacon wrote:
> >>> On Tue, Jan 26, 2016 at 03:52:46PM +0000, Suzuki K Poulose wrote:
> >>>> +#define HWCAP_FPHP		(1 << 9)
> >>>> +#define HWCAP_ASIMDHP		(1 << 10)
> >>>
> >>> Where did we get to with the mrs trapping you proposed here?
> >>>
> >>>   http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374609.html
> >>>
> >>> At some point, we need to consider whether or not we want to continue
> >>> adding new HWCAPs or whether your suggestion above is actually useful
> >>> to userspace.
> >>
> >> IMO, even if we merge the MRS emulation, I would still like to see
> >> HWCAPs exported. We are not short on bits yet (53 to go ;)).
> > 
> > I'm less keen. HWCAPs don't align well with the way that the ARM
> > architecture versions features and we should be encouraging people to
> > use the MRS emulation if it exists.
> > 
> >>> Did the libc guys get anywhere with a prototype? What do we need to do
> >>> to make progress with it?
> >>
> >> This investigation should indeed continue but I think it is orthogonal.
> > 
> > Not if its intended to replace HWCAPs in the longterm.
> > 
> 
> userspace needs HWCAP bits independently of the MIDR emulation.
> 
> MIDR cannot replace HWCAP:
> 
> - MIDR does not map to features in a future-proof way
>   (we don't know which MIDR will indicate fp16 availability)
> 
> - MIDR would be useful for more fine-grained uarch specific
>   tuning decisions, HWCAP is for arch extensions like fp16.
> 
> - We don't yet know if the proposed MIDR emulation solves
>   all userspace issues we want it to solve. I'll try to
>   investigate that as well as the alternative VDSO based
>   approach (if VDSO can work, that would be better for
>   userspace). There are nasty issues here so the conclusion
>   might take a while, but that should not hold up HWCAPs.

I'm not solely proposing MIDR as an alternative to HWCAP. I'm proposing
that the feature registers, e.g. ID_AA64MMFR0_EL1 are used instead.

Will


From arnd at arndb.de  Tue Feb 16 03:54:06 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 12:54:06 +0100
Subject: [PATCH 2/3] serial: xuartps: Enable OF earlycon support
In-Reply-To: <23ab10a19b21df2ef17a5bb6ce2a70d2d3fd3551.1455552315.git.michal.simek@xilinx.com>
References: <67c9013fc61f53515934b54847a05df8b8e1504a.1455552315.git.michal.simek@xilinx.com>
 <23ab10a19b21df2ef17a5bb6ce2a70d2d3fd3551.1455552315.git.michal.simek@xilinx.com>
Message-ID: <7244827.meF4e5ZIpB@wuerfel>

On Monday 15 February 2016 17:05:18 Michal Simek wrote:
> Support early console setup via DT for all listed compatible strings.
> 
> Signed-off-by: Michal Simek <michal.simek at xilinx.com>
> ---
> 

I'd suggest we take the whole series through arm-soc, as the third patch
depends on this second one.

Greg, is this ok for you?

	Arnd


From pochun.lin at mediatek.com  Tue Feb 16 03:57:12 2016
From: pochun.lin at mediatek.com (pochun lin)
Date: Tue, 16 Feb 2016 19:57:12 +0800
Subject: [PATCH v4 7/8] [media] vcodec: mediatek: Add Mediatek H264
 Video Encoder Driver
In-Reply-To: <56C1B78F.5050207@xs4all.nl>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-7-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-8-git-send-email-tiffany.lin@mediatek.com>
 <56C1B78F.5050207@xs4all.nl>
Message-ID: <1455623832.14709.3.camel@mtksdaap41>

Hi Hans,

On Mon, 2016-02-15 at 19:33 +0800, Hans Verkuil wrote:
> On 02/04/2016 12:35 PM, Tiffany Lin wrote:
> > Add h264 encoder driver for MT8173
> > 
> > Signed-off-by: Daniel Hsiao <daniel.hsiao at mediatek.com>
> > Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
> > ---
> >  drivers/media/platform/mtk-vcodec/Makefile         |    3 +-
> >  .../media/platform/mtk-vcodec/h264_enc/Makefile    |    6 +
> >  .../platform/mtk-vcodec/h264_enc/venc_h264_if.c    |  540 ++++++++++++++++++++
> >  .../platform/mtk-vcodec/h264_enc/venc_h264_if.h    |  165 ++++++
> >  .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.c   |  309 +++++++++++
> >  .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.h   |   30 ++
> >  drivers/media/platform/mtk-vcodec/venc_drv_if.c    |    3 +
> >  7 files changed, 1055 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/Makefile
> >  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
> >  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
> >  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
> >  create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
> > 
> > diff --git a/drivers/media/platform/mtk-vcodec/Makefile b/drivers/media/platform/mtk-vcodec/Makefile
> > index f4ef502..f47dfc7 100644
> > --- a/drivers/media/platform/mtk-vcodec/Makefile
> > +++ b/drivers/media/platform/mtk-vcodec/Makefile
> > @@ -5,6 +5,7 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk_vcodec_intr.o \
> >  				       mtk_vcodec_enc_pm.o \
> >  				       venc_drv_if.o
> >  
> > -obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += vp8_enc/
> > +
> > +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += vp8_enc/ h264_enc/
> >  
> >  ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
> > diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/Makefile b/drivers/media/platform/mtk-vcodec/h264_enc/Makefile
> > new file mode 100644
> > index 0000000..765b45f
> > --- /dev/null
> > +++ b/drivers/media/platform/mtk-vcodec/h264_enc/Makefile
> > @@ -0,0 +1,6 @@
> > +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += venc_h264_if.o venc_h264_vpu.o
> > +
> > +ccflags-y += \
> > +    -I$(srctree)/drivers/media/platform/mtk-vcodec/ \
> > +    -I$(srctree)/drivers/media/platform/mtk-vcodec/h264_enc \
> > +    -I$(srctree)/drivers/media/platform/mtk-vpu
> > diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
> > new file mode 100644
> > index 0000000..c35fb26
> > --- /dev/null
> > +++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
> > @@ -0,0 +1,540 @@
> > +/*
> > + * Copyright (c) 2015 MediaTek Inc.
> > + * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
> > + *         Daniel Hsiao <daniel.hsiao at mediatek.com>
> > + *         PoChun Lin <pochun.lin at mediatek.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.
> > + */
> > +
> > +#include <linux/interrupt.h>
> > +#include <linux/kernel.h>
> > +#include <linux/slab.h>
> > +
> > +#include "mtk_vcodec_drv.h"
> > +#include "mtk_vcodec_util.h"
> > +#include "mtk_vcodec_intr.h"
> > +#include "mtk_vcodec_enc.h"
> > +#include "mtk_vcodec_pm.h"
> > +#include "mtk_vpu.h"
> > +
> > +#include "venc_h264_if.h"
> > +#include "venc_h264_vpu.h"
> > +
> > +#define VENC_PIC_BITSTREAM_BYTE_CNT 0x0098
> > +
> > +enum venc_h264_irq_status {
> > +	H264_IRQ_STATUS_ENC_SPS_INT = (1 << 0),
> > +	H264_IRQ_STATUS_ENC_PPS_INT = (1 << 1),
> > +	H264_IRQ_STATUS_ENC_FRM_INT = (1 << 2),
> > +};
> > +
> > +static inline void h264_write_reg(struct venc_h264_inst *inst, u32 addr,
> > +				  u32 val)
> > +{
> > +	writel(val, inst->hw_base + addr);
> > +}
> > +
> > +static inline u32 h264_read_reg(struct venc_h264_inst *inst, u32 addr)
> > +{
> > +	return readl(inst->hw_base + addr);
> > +}
> > +
> > +static void h264_enc_free_work_buf(struct venc_h264_inst *inst)
> > +{
> > +	int i;
> > +
> > +	mtk_vcodec_debug_enter(inst);
> > +
> > +	/* Except the SKIP_FRAME buffers,
> > +	 * other buffers need to be freed by AP.
> > +	 */
> > +	for (i = 0; i < VENC_H264_VPU_WORK_BUF_MAX; i++) {
> > +		if (i != VENC_H264_VPU_WORK_BUF_SKIP_FRAME)
> > +			if (inst->work_bufs[i].va != NULL)
> > +				mtk_vcodec_mem_free(inst->ctx,
> > +						    &inst->work_bufs[i]);
> > +	}
> > +
> > +	if (inst->pps_buf.va != NULL)
> > +		mtk_vcodec_mem_free(inst->ctx, &inst->pps_buf);
> > +
> > +	mtk_vcodec_debug_leave(inst);
> > +}
> > +
> > +static int h264_enc_alloc_work_buf(struct venc_h264_inst *inst, void *param)
> > +{
> > +	int i;
> > +	int ret = 0;
> > +	struct venc_h264_vpu_buf *wb = inst->vpu_inst.drv->work_bufs;
> > +	struct venc_enc_prm *enc_param = param;
> > +
> > +	mtk_vcodec_debug_enter(inst);
> > +
> > +	for (i = 0; i < VENC_H264_VPU_WORK_BUF_MAX; i++) {
> > +		/*
> > +		 * This 'wb' structure is set by VPU side and shared to AP for
> > +		 * buffer allocation and IO virtual addr mapping. For most of
> > +		 * the buffers, AP will allocate the buffer according to 'size'
> > +		 * field and store the IO virtual addr in 'iova' field. There
> > +		 * are two exceptions:
> > +		 * (1) RC_CODE buffer, it's pre-allocated in the VPU side, and
> > +		 * save the VPU addr in the 'vpua' field. The AP will translate
> > +		 * the VPU addr to the corresponding IO virtual addr and store
> > +		 * in 'iova' field for reg setting in VPU side.
> > +		 * (2) SKIP_FRAME buffer, it's pre-allocated in the VPU side,
> > +		 * and save the VPU addr in the 'vpua' field. The AP will
> > +		 * translate the VPU addr to the corresponding AP side virtual
> > +		 * address and do some memcpy access to move to bitstream buffer
> > +		 * assigned by v4l2 layer.
> > +		 */
> > +		if (i == VENC_H264_VPU_WORK_BUF_RC_CODE) {
> > +			void *tmp_va;
> > +
> > +			tmp_va = vpu_mapping_dm_addr(inst->dev, wb[i].vpua);
> > +			inst->work_bufs[i].size = wb[i].size;
> > +			if (mtk_vcodec_mem_alloc(inst->ctx,
> > +						 &inst->work_bufs[i])) {
> > +				mtk_vcodec_err(inst,
> > +					       "cannot allocate buf %d", i);
> > +				ret = -ENOMEM;
> > +				goto err_alloc;
> > +			}
> > +			memcpy(inst->work_bufs[i].va, tmp_va, wb[i].size);
> > +			wb[i].iova = inst->work_bufs[i].dma_addr;
> > +		} else if (i == VENC_H264_VPU_WORK_BUF_SKIP_FRAME) {
> > +			inst->work_bufs[i].size = wb[i].size;
> > +			inst->work_bufs[i].va = vpu_mapping_dm_addr(
> > +				inst->dev, wb[i].vpua);
> > +			inst->work_bufs[i].dma_addr = 0;
> > +			wb[i].iova = inst->work_bufs[i].dma_addr;
> > +		} else if (i == VENC_H264_VPU_WORK_BUF_SRC_LUMA ||
> > +			   i == VENC_H264_VPU_WORK_BUF_SRC_CHROMA ||
> > +			   i == VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CB ||
> > +			   i == VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CR) {
> > +			inst->work_bufs[i].size = wb[i].size;
> > +			inst->work_bufs[i].dma_addr = 0;
> > +			inst->work_bufs[i].va = NULL;
> > +			wb[i].iova = inst->work_bufs[i].dma_addr;
> > +		} else {
> > +			inst->work_bufs[i].size = wb[i].size;
> > +			if (mtk_vcodec_mem_alloc(inst->ctx,
> > +						 &inst->work_bufs[i])) {
> > +				mtk_vcodec_err(inst,
> > +					       "cannot allocate buf %d", i);
> > +				ret = -ENOMEM;
> > +				goto err_alloc;
> > +			}
> > +			wb[i].iova = inst->work_bufs[i].dma_addr;
> > +		}
> > +		mtk_vcodec_debug(inst, "buf[%d] va=0x%p iova=0x%p size=0x%lx",
> > +				 i, inst->work_bufs[i].va,
> > +				 (void *)inst->work_bufs[i].dma_addr,
> > +				 inst->work_bufs[i].size);
> > +	}
> > +
> > +	if (enc_param->input_fourcc == VENC_YUV_FORMAT_NV12 ||
> > +	    enc_param->input_fourcc == VENC_YUV_FORMAT_NV21) {
> > +		enc_param->sizeimage[0] =
> > +			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_LUMA].size;
> > +		enc_param->sizeimage[1] =
> > +			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_CHROMA].size;
> > +		enc_param->sizeimage[2] = 0;
> > +	} else {
> > +		enc_param->sizeimage[0] =
> > +			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_LUMA].size;
> > +		enc_param->sizeimage[1] =
> > +			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CB].size;
> > +		enc_param->sizeimage[2] =
> > +			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CR].size;
> > +	}
> > +
> > +	/* the pps_buf is used by AP side only */
> > +	inst->pps_buf.size = 128;
> > +	if (mtk_vcodec_mem_alloc(inst->ctx,
> > +				 &inst->pps_buf)) {
> > +		mtk_vcodec_err(inst, "cannot allocate pps_buf");
> > +		ret = -ENOMEM;
> > +		goto err_alloc;
> > +	}
> > +	mtk_vcodec_debug_leave(inst);
> > +
> > +	return ret;
> > +
> > +err_alloc:
> > +	h264_enc_free_work_buf(inst);
> > +
> > +	return ret;
> > +}
> > +
> > +static unsigned int h264_enc_wait_venc_done(struct venc_h264_inst *inst)
> > +{
> > +	unsigned int irq_status = 0;
> > +	struct mtk_vcodec_ctx *ctx = (struct mtk_vcodec_ctx *)inst->ctx;
> > +
> > +	mtk_vcodec_wait_for_done_ctx(ctx, MTK_INST_IRQ_RECEIVED,
> > +				     WAIT_INTR_TIMEOUT, true);
> > +	irq_status = ctx->irq_status;
> > +	mtk_vcodec_debug(inst, "irq_status %x <-", irq_status);
> > +
> > +	return irq_status;
> > +}
> > +
> > +static int h264_encode_sps(struct venc_h264_inst *inst,
> > +			   struct mtk_vcodec_mem *bs_buf,
> > +			   unsigned int *bs_size)
> > +{
> > +	int ret = 0;
> > +	unsigned int irq_status;
> > +
> > +	mtk_vcodec_debug_enter(inst);
> > +
> > +	ret = h264_enc_vpu_encode(inst, H264_BS_MODE_SPS, NULL,
> > +				  bs_buf, bs_size);
> > +	if (ret)
> > +		return ret;
> > +
> > +	irq_status = h264_enc_wait_venc_done(inst);
> > +	if (irq_status != H264_IRQ_STATUS_ENC_SPS_INT) {
> > +		mtk_vcodec_err(inst, "expect irq status %d",
> > +			       H264_IRQ_STATUS_ENC_SPS_INT);
> > +		return -EINVAL;
> > +	}
> > +
> > +	*bs_size = h264_read_reg(inst, VENC_PIC_BITSTREAM_BYTE_CNT);
> > +	mtk_vcodec_debug(inst, "bs size %d <-", *bs_size);
> > +
> > +	return ret;
> > +}
> > +
> > +static int h264_encode_pps(struct venc_h264_inst *inst,
> > +			   struct mtk_vcodec_mem *bs_buf,
> > +			   unsigned int *bs_size)
> > +{
> > +	int ret = 0;
> > +	unsigned int irq_status;
> > +
> > +	mtk_vcodec_debug_enter(inst);
> > +
> > +	ret = h264_enc_vpu_encode(inst, H264_BS_MODE_PPS, NULL,
> > +				  bs_buf, bs_size);
> > +	if (ret)
> > +		return ret;
> > +
> > +	irq_status = h264_enc_wait_venc_done(inst);
> > +	if (irq_status != H264_IRQ_STATUS_ENC_PPS_INT) {
> > +		mtk_vcodec_err(inst, "expect irq status %d",
> > +			       H264_IRQ_STATUS_ENC_PPS_INT);
> > +		return -EINVAL;
> > +	}
> > +
> > +	*bs_size = h264_read_reg(inst, VENC_PIC_BITSTREAM_BYTE_CNT);
> > +	mtk_vcodec_debug(inst, "bs size %d <-", *bs_size);
> > +
> > +	return ret;
> > +}
> > +
> > +static int h264_encode_frame(struct venc_h264_inst *inst,
> > +			     struct venc_frm_buf *frm_buf,
> > +			     struct mtk_vcodec_mem *bs_buf,
> > +			     unsigned int *bs_size)
> > +{
> > +	int ret = 0;
> > +	unsigned int irq_status;
> > +
> > +	mtk_vcodec_debug_enter(inst);
> > +
> > +	ret = h264_enc_vpu_encode(inst, H264_BS_MODE_FRAME, frm_buf,
> > +				  bs_buf, bs_size);
> > +	if (ret)
> > +		return ret;
> > +
> > +	/*
> > +	 * skip frame case: The skip frame buffer is composed by vpu side only,
> > +	 * it does not trigger the hw, so skip the wait interrupt operation.
> > +	 */
> > +	if (!inst->vpu_inst.wait_int) {
> > +		++inst->frm_cnt;
> > +		return ret;
> > +	}
> > +
> > +	irq_status = h264_enc_wait_venc_done(inst);
> > +	if (irq_status != H264_IRQ_STATUS_ENC_FRM_INT) {
> > +		mtk_vcodec_err(inst, "irq_status=%d failed", irq_status);
> > +		return -EINVAL;
> > +	}
> > +
> > +	*bs_size = h264_read_reg(inst,
> > +				 VENC_PIC_BITSTREAM_BYTE_CNT);
> > +	++inst->frm_cnt;
> > +	mtk_vcodec_debug(inst, "frm %d bs size %d key_frm %d <-",
> > +			 inst->frm_cnt,
> > +			 *bs_size, inst->is_key_frm);
> > +
> > +	return ret;
> > +}
> > +
> > +static void h264_encode_filler(struct venc_h264_inst *inst, void *buf,
> > +			       int size)
> > +{
> > +	unsigned char *p = buf;
> > +
> > +	*p++ = 0x0;
> > +	*p++ = 0x0;
> > +	*p++ = 0x0;
> > +	*p++ = 0x1;
> > +	*p++ = 0xc;
> > +	size -= 5;
> > +	while (size) {
> > +		*p++ = 0xff;
> > +		size -= 1;
> > +	}
> > +}
> > +
> > +static int h264_enc_init(struct mtk_vcodec_ctx *ctx, unsigned long *handle)
> > +{
> > +	int ret = 0;
> > +	struct venc_h264_inst *inst;
> > +
> > +	inst = kzalloc(sizeof(*inst), GFP_KERNEL);
> > +	if (!inst)
> > +		return -ENOMEM;
> > +
> > +	inst->ctx = ctx;
> > +	inst->dev = mtk_vcodec_get_plat_dev(ctx);
> > +	inst->hw_base = mtk_vcodec_get_reg_addr(inst->ctx, VENC_SYS);
> > +
> > +	mtk_vcodec_debug_enter(inst);
> > +	ret = h264_enc_vpu_init(inst);
> > +	if (ret)
> > +		kfree(inst);
> > +	else
> > +		(*handle) = (unsigned long)inst;
> > +
> > +	mtk_vcodec_debug_leave(inst);
> > +
> > +	return ret;
> > +}
> > +
> > +static int h264_enc_encode(unsigned long handle,
> > +			   enum venc_start_opt opt,
> > +			   struct venc_frm_buf *frm_buf,
> > +			   struct mtk_vcodec_mem *bs_buf,
> > +			   struct venc_done_result *result)
> > +{
> > +	int ret = 0;
> > +	struct venc_h264_inst *inst = (struct venc_h264_inst *)handle;
> > +	struct mtk_vcodec_ctx *ctx = inst->ctx;
> > +
> > +	mtk_vcodec_debug(inst, "opt %d ->", opt);
> > +
> > +	enable_irq(ctx->dev->enc_irq);
> > +
> > +	switch (opt) {
> > +	case VENC_START_OPT_ENCODE_SEQUENCE_HEADER: {
> > +		unsigned int bs_size_sps;
> > +		unsigned int bs_size_pps;
> > +
> > +		memset(bs_buf->va, 0x38, 20);
> > +		ret = h264_encode_sps(inst, bs_buf, &bs_size_sps);
> > +		if (ret)
> > +			goto encode_err;
> > +
> > +		memset(inst->pps_buf.va, 0x49, 20);
> > +		ret = h264_encode_pps(inst, &inst->pps_buf, &bs_size_pps);
> > +		if (ret)
> > +			goto encode_err;
> > +
> > +		memcpy(bs_buf->va + bs_size_sps,
> > +		       inst->pps_buf.va,
> > +		       bs_size_pps);
> > +		result->bs_size = bs_size_sps + bs_size_pps;
> > +		result->is_key_frm = false;
> > +	}
> > +	break;
> 
> Wrong indentation for break, put it before the '}'.
> 

I will change this in next version. Thanks.

> > +
> > +	case VENC_START_OPT_ENCODE_FRAME:
> > +		if (inst->prepend_hdr) {
> 
> Invert the condition to make it more readable:
> 
> 		if (!inst->prepend_hdr) {
> 			ret = h264_encode_frame(inst, frm_buf, bs_buf,
> 						&result->bs_size);
> 			if (ret)
> 				goto encode_err;
> 			result->is_key_frm = inst->is_key_frm;
> 			break;
> 		}
> 
> Now you can shift the remainder one tab to the left and join lines that
> are now broken up (probably because they exceed 80 chars).
> 

I will change this in next version. Thanks.

> > +			int hdr_sz;
> > +			int hdr_sz_ext;
> > +			int bs_alignment = 128;
> > +			int filler_sz = 0;
> > +			struct mtk_vcodec_mem tmp_bs_buf;
> > +			unsigned int bs_size_sps;
> > +			unsigned int bs_size_pps;
> > +			unsigned int bs_size_frm;
> > +
> > +			mtk_vcodec_debug(inst,
> > +					 "h264_encode_frame prepend SPS/PPS");
> > +			ret = h264_encode_sps(inst, bs_buf, &bs_size_sps);
> > +			if (ret)
> > +				goto encode_err;
> > +
> > +			ret = h264_encode_pps(inst, &inst->pps_buf,
> > +					      &bs_size_pps);
> > +			if (ret)
> > +				goto encode_err;
> > +
> > +			memcpy(bs_buf->va + bs_size_sps,
> > +			       inst->pps_buf.va,
> > +			       bs_size_pps);
> > +
> > +			hdr_sz = bs_size_sps + bs_size_pps;
> > +			hdr_sz_ext = (hdr_sz & (bs_alignment - 1));
> > +			if (hdr_sz_ext) {
> > +				filler_sz = bs_alignment - hdr_sz_ext;
> > +				if (hdr_sz_ext + 5 > bs_alignment)
> > +					filler_sz += bs_alignment;
> > +				h264_encode_filler(
> > +					inst, bs_buf->va + hdr_sz,
> > +					filler_sz);
> > +			}
> > +
> > +			tmp_bs_buf.va = bs_buf->va + hdr_sz +
> > +				filler_sz;
> > +			tmp_bs_buf.dma_addr = bs_buf->dma_addr + hdr_sz +
> > +				filler_sz;
> > +			tmp_bs_buf.size = bs_buf->size -
> > +				(hdr_sz + filler_sz);
> > +
> > +			ret = h264_encode_frame(inst, frm_buf, &tmp_bs_buf,
> > +						&bs_size_frm);
> > +			if (ret)
> > +				goto encode_err;
> > +
> > +			result->bs_size = hdr_sz + filler_sz + bs_size_frm;
> > +			mtk_vcodec_debug(inst,
> > +					 "hdr %d filler %d frame %d bs %d",
> > +					 hdr_sz, filler_sz, bs_size_frm,
> > +					 result->bs_size);
> > +
> > +			inst->prepend_hdr = 0;
> > +		} else {
> > +			ret = h264_encode_frame(inst, frm_buf, bs_buf,
> > +						&result->bs_size);
> > +			if (ret)
> > +				goto encode_err;
> > +		}
> > +		result->is_key_frm = inst->is_key_frm;
> > +		break;
> > +
> > +	default:
> > +		mtk_vcodec_err(inst, "venc_start_opt %d not supported", opt);
> > +		ret = -EINVAL;
> > +		break;
> > +	}
> > +
> > +encode_err:
> > +	if (ret)
> > +		result->msg = VENC_MESSAGE_ERR;
> > +	else
> > +		result->msg = VENC_MESSAGE_OK;
> > +
> > +	disable_irq(ctx->dev->enc_irq);
> > +	mtk_vcodec_debug(inst, "opt %d <-", opt);
> > +
> > +	return ret;
> > +}
> > +
> > +static int h264_enc_set_param(unsigned long handle,
> > +			      enum venc_set_param_type type, void *in)
> > +{
> > +	int ret = 0;
> > +	struct venc_h264_inst *inst = (struct venc_h264_inst *)handle;
> > +	struct venc_enc_prm *enc_prm;
> > +
> > +	mtk_vcodec_debug(inst, "->type=%d", type);
> > +
> > +	switch (type) {
> > +	case VENC_SET_PARAM_ENC:
> > +		enc_prm = in;
> > +		ret = h264_enc_vpu_set_param(inst, type, enc_prm);
> > +		if (ret)
> > +			break;
> > +		if (inst->work_buf_allocated == 1) {
> > +			h264_enc_free_work_buf(inst);
> > +			inst->work_buf_allocated = 0;
> > +		}
> > +		if (inst->work_buf_allocated == 0) {
> > +			ret = h264_enc_alloc_work_buf(inst, enc_prm);
> > +			if (ret)
> > +				break;
> > +			inst->work_buf_allocated = 1;
> > +		}
> > +		break;
> > +
> > +	case VENC_SET_PARAM_FORCE_INTRA:
> > +		ret = h264_enc_vpu_set_param(inst, type, 0);
> > +		break;
> > +
> > +	case VENC_SET_PARAM_ADJUST_BITRATE:
> > +		enc_prm = in;
> > +		ret = h264_enc_vpu_set_param(inst, type, &enc_prm->bitrate);
> > +		break;
> > +
> > +	case VENC_SET_PARAM_ADJUST_FRAMERATE:
> > +		enc_prm = in;
> > +		ret = h264_enc_vpu_set_param(inst, type, &enc_prm->frm_rate);
> > +		break;
> > +
> > +	case VENC_SET_PARAM_I_FRAME_INTERVAL:
> > +		ret = h264_enc_vpu_set_param(inst, type, in);
> > +		break;
> > +
> > +	case VENC_SET_PARAM_SKIP_FRAME:
> > +		ret = h264_enc_vpu_set_param(inst, type, 0);
> > +		break;
> > +
> > +	case VENC_SET_PARAM_PREPEND_HEADER:
> > +		inst->prepend_hdr = 1;
> > +		mtk_vcodec_debug(inst, "set prepend header mode");
> > +		break;
> > +
> > +	default:
> > +		mtk_vcodec_err(inst, "type %d not supported", type);
> > +		ret = -EINVAL;
> > +		break;
> > +	}
> > +
> > +	mtk_vcodec_debug_leave(inst);
> > +
> > +	return ret;
> > +}
> > +
> > +static int h264_enc_deinit(unsigned long handle)
> > +{
> > +	int ret = 0;
> > +	struct venc_h264_inst *inst = (struct venc_h264_inst *)handle;
> > +
> > +	mtk_vcodec_debug_enter(inst);
> > +
> > +	ret = h264_enc_vpu_deinit(inst);
> > +
> > +	if (inst->work_buf_allocated)
> > +		h264_enc_free_work_buf(inst);
> > +
> > +	mtk_vcodec_debug_leave(inst);
> > +	kfree(inst);
> > +
> > +	return ret;
> > +}
> > +
> > +static struct venc_common_if venc_h264_if = {
> > +	h264_enc_init,
> > +	h264_enc_encode,
> > +	h264_enc_set_param,
> > +	h264_enc_deinit,
> > +};
> > +
> > +struct venc_common_if *get_h264_enc_comm_if(void)
> > +{
> > +	return &venc_h264_if;
> > +}
> > diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
> > new file mode 100644
> > index 0000000..9ac317a
> > --- /dev/null
> > +++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
> > @@ -0,0 +1,165 @@
> > +/*
> > + * Copyright (c) 2015 MediaTek Inc.
> > + * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
> > + *         Daniel Hsiao <daniel.hsiao at mediatek.com>
> > + *         PoChun Lin <pochun.lin at mediatek.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.
> > + */
> > +
> > +#ifndef _VENC_H264_IF_H_
> > +#define _VENC_H264_IF_H_
> > +
> > +#include "venc_drv_base.h"
> > +
> > +/**
> > + * enum venc_h264_vpu_work_buf - h264 encoder buffer index
> > + */
> > +enum venc_h264_vpu_work_buf {
> > +	VENC_H264_VPU_WORK_BUF_RC_INFO,
> > +	VENC_H264_VPU_WORK_BUF_RC_CODE,
> > +	VENC_H264_VPU_WORK_BUF_REC_LUMA,
> > +	VENC_H264_VPU_WORK_BUF_REC_CHROMA,
> > +	VENC_H264_VPU_WORK_BUF_REF_LUMA,
> > +	VENC_H264_VPU_WORK_BUF_REF_CHROMA,
> > +	VENC_H264_VPU_WORK_BUF_MV_INFO_1,
> > +	VENC_H264_VPU_WORK_BUF_MV_INFO_2,
> > +	VENC_H264_VPU_WORK_BUF_SKIP_FRAME,
> > +	VENC_H264_VPU_WORK_BUF_SRC_LUMA,
> > +	VENC_H264_VPU_WORK_BUF_SRC_CHROMA,
> > +	VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CB,
> > +	VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CR,
> > +	VENC_H264_VPU_WORK_BUF_MAX,
> > +};
> > +
> > +/**
> > + * enum venc_h264_bs_mode - for bs_mode argument in h264_enc_vpu_encode
> > + */
> > +enum venc_h264_bs_mode {
> > +	H264_BS_MODE_SPS,
> > +	H264_BS_MODE_PPS,
> > +	H264_BS_MODE_FRAME,
> > +};
> > +
> > +/*
> > + * struct venc_h264_vpu_config - Structure for h264 encoder configuration
> > + * @input_fourcc: input fourcc
> > + * @bitrate: target bitrate (in bps)
> > + * @pic_w: picture width
> > + * @pic_h: picture height
> > + * @buf_w: buffer width
> > + * @buf_h: buffer height
> > + * @intra_period: intra frame period
> > + * @framerate: frame rate
> > + * @profile: as specified in standard
> > + * @level: as specified in standard
> > + * @wfd: WFD mode 1:on, 0:off
> > + */
> > +struct venc_h264_vpu_config {
> > +	u32 input_fourcc;
> > +	u32 bitrate;
> > +	u32 pic_w;
> > +	u32 pic_h;
> > +	u32 buf_w;
> > +	u32 buf_h;
> > +	u32 intra_period;
> > +	u32 framerate;
> > +	u32 profile;
> > +	u32 level;
> > +	u32 wfd;
> > +};
> > +
> > +/*
> > + * struct venc_h264_vpu_buf - Structure for buffer information
> > + * @align: buffer alignment (in bytes)
> > + * @iova: IO virtual address
> > + * @vpua: VPU side memory addr which is used by RC_CODE
> > + * @size: buffer size (in bytes)
> > + */
> > +struct venc_h264_vpu_buf {
> > +	u32 align;
> > +	u32 iova;
> > +	u32 vpua;
> > +	u32 size;
> > +};
> > +
> > +/*
> > + * struct venc_h264_vpu_drv - Structure for VPU driver control and info share
> > + * This structure is allocated in VPU side and shared to AP side.
> > + * @config: h264 encoder configuration
> > + * @work_bufs: working buffer information in VPU side
> > + * The work_bufs here is for storing the 'size' info shared to AP side.
> > + * The similar item in struct venc_h264_inst is for memory allocation
> > + * in AP side. The AP driver will copy the 'size' from here to the one in
> > + * struct mtk_vcodec_mem, then invoke mtk_vcodec_mem_alloc to allocate
> > + * the buffer. After that, bypass the 'dma_addr' to the 'iova' field here for
> > + * register setting in VPU side.
> > + */
> > +struct venc_h264_vpu_drv {
> > +	struct venc_h264_vpu_config config;
> > +	struct venc_h264_vpu_buf work_bufs[VENC_H264_VPU_WORK_BUF_MAX];
> > +};
> > +
> > +/*
> > + * struct venc_h264_vpu_inst - h264 encoder VPU driver instance
> > + * @wq_hd: wait queue used for vpu cmd trigger then wait vpu interrupt done
> > + * @signaled: flag used for checking vpu interrupt done
> > + * @failure: flag to show vpu cmd succeeds or not
> > + * @state: enum venc_ipi_msg_enc_state
> > + * @bs_size: bitstream size for skip frame case usage
> > + * @wait_int: flag to wait interrupt done (0: for skip frame case, 1: normal
> > + *	      case)
> > + * @id: VPU instance id
> > + * @drv: driver structure allocated by VPU side and shared to AP side for
> > + *	 control and info share
> > + */
> > +struct venc_h264_vpu_inst {
> > +	wait_queue_head_t wq_hd;
> > +	int signaled;
> > +	int failure;
> > +	int state;
> > +	int bs_size;
> > +	int wait_int;
> > +	unsigned int id;
> > +	struct venc_h264_vpu_drv *drv;
> > +};
> > +
> > +/*
> > + * struct venc_h264_inst - h264 encoder AP driver instance
> > + * @hw_base: h264 encoder hardware register base
> > + * @work_bufs: working buffer
> > + * @pps_buf: buffer to store the pps bitstream
> > + * @work_buf_allocated: working buffer allocated flag
> > + * @frm_cnt: encoded frame count
> > + * @prepend_hdr: when the v4l2 layer send VENC_SET_PARAM_PREPEND_HEADER cmd
> > + *  through h264_enc_set_param interface, it will set this flag and prepend the
> > + *  sps/pps in h264_enc_encode function.
> > + * @is_key_frm: key frame flag
> > + * @vpu_inst: VPU instance to exchange information between AP and VPU
> > + * @ctx: context for v4l2 layer integration
> > + * @dev: device for v4l2 layer integration
> > + */
> > +struct venc_h264_inst {
> > +	void __iomem *hw_base;
> > +	struct mtk_vcodec_mem work_bufs[VENC_H264_VPU_WORK_BUF_MAX];
> > +	struct mtk_vcodec_mem pps_buf;
> > +	bool work_buf_allocated;
> > +	unsigned int frm_cnt;
> > +	unsigned int prepend_hdr;
> > +	unsigned int is_key_frm;
> > +	struct venc_h264_vpu_inst vpu_inst;
> > +	void *ctx;
> > +	struct platform_device *dev;
> > +};
> > +
> > +struct venc_common_if *get_h264_enc_comm_if(void);
> > +
> > +#endif
> > diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
> > new file mode 100644
> > index 0000000..450be45
> > --- /dev/null
> > +++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
> > @@ -0,0 +1,309 @@
> > +/*
> > + * Copyright (c) 2015 MediaTek Inc.
> > + * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
> > + *         Daniel Hsiao <daniel.hsiao at mediatek.com>
> > + *         PoChun Lin <pochun.lin at mediatek.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.
> > + */
> > +
> > +#include "mtk_vpu.h"
> > +
> > +#include "venc_h264_if.h"
> > +#include "venc_h264_vpu.h"
> > +#include "venc_ipi_msg.h"
> > +
> > +static unsigned int h264_get_profile(unsigned int profile)
> > +{
> > +	/* (Baseline=66, Main=77, High=100) */
> > +	switch (profile) {
> > +	case V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE:
> > +		return 66;
> > +	case V4L2_MPEG_VIDEO_H264_PROFILE_MAIN:
> > +		return 77;
> > +	case V4L2_MPEG_VIDEO_H264_PROFILE_HIGH:
> > +		return 100;
> > +	default:
> > +		return 100;
> > +	}
> > +}
> > +
> > +static unsigned int h264_get_level(unsigned int level)
> > +{
> > +	/* (UpTo4.1(HighProfile)) */
> > +	switch (level) {
> > +	case V4L2_MPEG_VIDEO_H264_LEVEL_1_0:
> > +		return 10;
> > +	case V4L2_MPEG_VIDEO_H264_LEVEL_1_1:
> > +		return 11;
> > +	case V4L2_MPEG_VIDEO_H264_LEVEL_1_2:
> > +		return 12;
> > +	case V4L2_MPEG_VIDEO_H264_LEVEL_1_3:
> > +		return 13;
> > +	case V4L2_MPEG_VIDEO_H264_LEVEL_2_0:
> > +		return 20;
> > +	case V4L2_MPEG_VIDEO_H264_LEVEL_2_1:
> > +		return 21;
> > +	case V4L2_MPEG_VIDEO_H264_LEVEL_2_2:
> > +		return 22;
> > +	case V4L2_MPEG_VIDEO_H264_LEVEL_3_0:
> > +		return 30;
> > +	case V4L2_MPEG_VIDEO_H264_LEVEL_3_1:
> > +		return 31;
> > +	case V4L2_MPEG_VIDEO_H264_LEVEL_3_2:
> > +		return 32;
> > +	case V4L2_MPEG_VIDEO_H264_LEVEL_4_0:
> > +		return 40;
> > +	case V4L2_MPEG_VIDEO_H264_LEVEL_4_1:
> > +		return 41;
> > +	default:
> > +		return 31;
> > +	}
> > +}
> > +
> > +static void handle_h264_enc_init_msg(struct venc_h264_inst *inst, void *data)
> > +{
> > +	struct venc_vpu_ipi_msg_init *msg = data;
> > +
> > +	inst->vpu_inst.id = msg->inst_id;
> > +	inst->vpu_inst.drv = (struct venc_h264_vpu_drv *)vpu_mapping_dm_addr(
> > +		inst->dev, msg->inst_id);
> > +}
> > +
> > +static void handle_h264_enc_encode_msg(struct venc_h264_inst *inst, void *data)
> > +{
> > +	struct venc_vpu_ipi_msg_enc *msg = data;
> > +
> > +	inst->vpu_inst.state = msg->state;
> > +	inst->vpu_inst.bs_size = msg->bs_size;
> > +	inst->is_key_frm = msg->key_frame;
> > +}
> > +
> > +static void h264_enc_vpu_ipi_handler(void *data, unsigned int len, void *priv)
> > +{
> > +	struct venc_vpu_ipi_msg_common *msg = data;
> > +	struct venc_h264_inst *inst = (struct venc_h264_inst *)msg->venc_inst;
> > +
> > +	mtk_vcodec_debug(inst, "msg_id %x inst %p status %d",
> > +			 msg->msg_id, inst, msg->status);
> > +
> > +	switch (msg->msg_id) {
> > +	case VPU_IPIMSG_H264_ENC_INIT_DONE:
> > +		handle_h264_enc_init_msg(inst, data);
> > +		break;
> > +	case VPU_IPIMSG_H264_ENC_SET_PARAM_DONE:
> > +		break;
> > +	case VPU_IPIMSG_H264_ENC_ENCODE_DONE:
> > +		handle_h264_enc_encode_msg(inst, data);
> > +		break;
> > +	case VPU_IPIMSG_H264_ENC_DEINIT_DONE:
> > +		break;
> > +	default:
> > +		mtk_vcodec_err(inst, "unknown msg id %x", msg->msg_id);
> > +		break;
> > +	}
> > +
> > +	inst->vpu_inst.signaled = 1;
> > +	inst->vpu_inst.failure = (msg->status != VENC_IPI_MSG_STATUS_OK);
> > +
> > +	mtk_vcodec_debug_leave(inst);
> > +}
> > +
> > +static int h264_enc_vpu_send_msg(struct venc_h264_inst *inst, void *msg,
> > +				 int len)
> > +{
> > +	int status;
> > +
> > +	mtk_vcodec_debug_enter(inst);
> > +	status = vpu_ipi_send(inst->dev, IPI_VENC_H264, msg, len);
> > +	if (status) {
> > +		mtk_vcodec_err(inst, "vpu_ipi_send msg %x len %d fail %d",
> > +			       *(unsigned int *)msg, len, status);
> > +		return -EINVAL;
> > +	}
> > +	mtk_vcodec_debug_leave(inst);
> > +
> > +	return 0;
> > +}
> > +
> > +int h264_enc_vpu_init(struct venc_h264_inst *inst)
> > +{
> > +	int status;
> > +	struct venc_ap_ipi_msg_init out;
> > +
> > +	mtk_vcodec_debug_enter(inst);
> > +
> > +	init_waitqueue_head(&inst->vpu_inst.wq_hd);
> > +	inst->vpu_inst.signaled = 0;
> > +	inst->vpu_inst.failure = 0;
> > +
> > +	status = vpu_ipi_register(inst->dev, IPI_VENC_H264,
> > +				  h264_enc_vpu_ipi_handler,
> > +				  "h264_enc", NULL);
> > +	if (status) {
> > +		mtk_vcodec_err(inst, "vpu_ipi_register fail %d", status);
> > +		return -EINVAL;
> > +	}
> > +
> > +	out.msg_id = AP_IPIMSG_H264_ENC_INIT;
> > +	out.venc_inst = (unsigned long)inst;
> > +	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
> > +	    inst->vpu_inst.failure) {
> > +		mtk_vcodec_err(inst, "AP_IPIMSG_H264_ENC_INIT failed");
> > +		return -EINVAL;
> > +	}
> > +
> > +	mtk_vcodec_debug_leave(inst);
> > +
> > +	return 0;
> > +}
> > +
> > +int h264_enc_vpu_set_param(struct venc_h264_inst *inst, unsigned int id,
> > +			   void *param)
> > +{
> > +	struct venc_ap_ipi_msg_set_param out;
> > +
> > +	mtk_vcodec_debug(inst, "id %d ->", id);
> > +
> > +	out.msg_id = AP_IPIMSG_H264_ENC_SET_PARAM;
> > +	out.inst_id = inst->vpu_inst.id;
> > +	out.param_id = id;
> > +	switch (id) {
> > +	case VENC_SET_PARAM_ENC: {
> > +		struct venc_enc_prm *enc_param = (struct venc_enc_prm *)param;
> > +
> > +		inst->vpu_inst.drv->config.input_fourcc =
> > +			enc_param->input_fourcc;
> > +		inst->vpu_inst.drv->config.bitrate = enc_param->bitrate;
> > +		inst->vpu_inst.drv->config.pic_w = enc_param->width;
> > +		inst->vpu_inst.drv->config.pic_h = enc_param->height;
> > +		inst->vpu_inst.drv->config.buf_w = enc_param->buf_width;
> > +		inst->vpu_inst.drv->config.buf_h = enc_param->buf_height;
> > +		inst->vpu_inst.drv->config.intra_period =
> > +			enc_param->intra_period;
> > +		inst->vpu_inst.drv->config.framerate = enc_param->frm_rate;
> > +		inst->vpu_inst.drv->config.profile =
> > +			h264_get_profile(enc_param->h264_profile);
> > +		inst->vpu_inst.drv->config.level =
> > +			h264_get_level(enc_param->h264_level);
> > +		inst->vpu_inst.drv->config.wfd = 0;
> > +		out.data_item = 0;
> > +		break;
> > +	}
> > +	case VENC_SET_PARAM_FORCE_INTRA:
> > +		out.data_item = 0;
> > +		break;
> > +	case VENC_SET_PARAM_ADJUST_BITRATE:
> > +		out.data_item = 1;
> > +		out.data[0] = *(unsigned int *)param;
> > +		break;
> > +	case VENC_SET_PARAM_ADJUST_FRAMERATE:
> > +		out.data_item = 1;
> > +		out.data[0] = *(unsigned int *)param;
> > +		break;
> > +	case VENC_SET_PARAM_I_FRAME_INTERVAL:
> > +		out.data_item = 1;
> > +		out.data[0] = *(unsigned int *)param;
> > +		break;
> > +	case VENC_SET_PARAM_SKIP_FRAME:
> > +		out.data_item = 0;
> > +		break;
> > +	}
> > +	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
> > +	    inst->vpu_inst.failure) {
> > +		mtk_vcodec_err(inst,
> > +			       "AP_IPIMSG_H264_ENC_SET_PARAM %d fail", id);
> > +		return -EINVAL;
> > +	}
> > +
> > +	mtk_vcodec_debug(inst, "id %d <-", id);
> > +
> > +	return 0;
> > +}
> > +
> > +int h264_enc_vpu_encode(struct venc_h264_inst *inst, unsigned int bs_mode,
> > +			struct venc_frm_buf *frm_buf,
> > +			struct mtk_vcodec_mem *bs_buf,
> > +			unsigned int *bs_size)
> > +{
> > +	struct venc_ap_ipi_msg_enc out;
> > +
> > +	mtk_vcodec_debug(inst, "bs_mode %d ->", bs_mode);
> > +
> > +	out.msg_id = AP_IPIMSG_H264_ENC_ENCODE;
> > +	out.inst_id = inst->vpu_inst.id;
> > +	out.bs_mode = bs_mode;
> > +	if (frm_buf) {
> > +		if ((frm_buf->fb_addr.dma_addr % 16 == 0) &&
> > +		    (frm_buf->fb_addr1.dma_addr % 16 == 0) &&
> > +		    (frm_buf->fb_addr2.dma_addr % 16 == 0)) {
> > +			out.input_addr[0] = frm_buf->fb_addr.dma_addr;
> > +			out.input_addr[1] = frm_buf->fb_addr1.dma_addr;
> > +			out.input_addr[2] = frm_buf->fb_addr2.dma_addr;
> > +		} else {
> > +			mtk_vcodec_err(inst, "dma_addr not align to 16");
> > +			return -EINVAL;
> > +		}
> > +	} else {
> > +		out.input_addr[0] = 0;
> > +		out.input_addr[1] = 0;
> > +		out.input_addr[2] = 0;
> > +	}
> > +	if (bs_buf) {
> > +		out.bs_addr = bs_buf->dma_addr;
> > +		out.bs_size = bs_buf->size;
> > +	} else {
> > +		out.bs_addr = 0;
> > +		out.bs_size = 0;
> > +	}
> > +	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
> > +	    inst->vpu_inst.failure) {
> > +		mtk_vcodec_err(inst, "AP_IPIMSG_H264_ENC_ENCODE %d fail",
> > +			       bs_mode);
> > +		return -EINVAL;
> > +	}
> > +
> > +	mtk_vcodec_debug(inst, "state %d size %d key_frm %d",
> > +			 inst->vpu_inst.state, inst->vpu_inst.bs_size,
> > +			 inst->is_key_frm);
> > +
> > +	inst->vpu_inst.wait_int = 1;
> > +	if (inst->vpu_inst.state == VEN_IPI_MSG_ENC_STATE_SKIP) {
> > +		*bs_size = inst->vpu_inst.bs_size;
> > +		memcpy(bs_buf->va,
> > +		       inst->work_bufs[VENC_H264_VPU_WORK_BUF_SKIP_FRAME].va,
> > +		       *bs_size);
> > +		inst->vpu_inst.wait_int = 0;
> > +	}
> > +
> > +	mtk_vcodec_debug(inst, "bs_mode %d <-", bs_mode);
> > +
> > +	return 0;
> > +}
> > +
> > +int h264_enc_vpu_deinit(struct venc_h264_inst *inst)
> > +{
> > +	struct venc_ap_ipi_msg_deinit out;
> > +
> > +	mtk_vcodec_debug_enter(inst);
> > +
> > +	out.msg_id = AP_IPIMSG_H264_ENC_DEINIT;
> > +	out.inst_id = inst->vpu_inst.id;
> > +	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
> > +	    inst->vpu_inst.failure) {
> > +		mtk_vcodec_err(inst, "AP_IPIMSG_H264_ENC_DEINIT fail");
> > +		return -EINVAL;
> > +	}
> > +
> > +	mtk_vcodec_debug_leave(inst);
> > +
> > +	return 0;
> > +}
> > diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
> > new file mode 100644
> > index 0000000..deccc6f
> > --- /dev/null
> > +++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
> > @@ -0,0 +1,30 @@
> > +/*
> > + * Copyright (c) 2015 MediaTek Inc.
> > + * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
> > + *         Daniel Hsiao <daniel.hsiao at mediatek.com>
> > + *         PoChun Lin <pochun.lin at mediatek.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.
> > + */
> > +
> > +#ifndef _VENC_H264_VPU_H_
> > +#define _VENC_H264_VPU_H_
> > +
> > +int h264_enc_vpu_init(struct venc_h264_inst *inst);
> > +int h264_enc_vpu_set_param(struct venc_h264_inst *inst, unsigned int id,
> > +			   void *param);
> > +int h264_enc_vpu_encode(struct venc_h264_inst *inst, unsigned int bs_mode,
> > +			struct venc_frm_buf *frm_buf,
> > +			struct mtk_vcodec_mem *bs_buf,
> > +			unsigned int *bs_size);
> > +int h264_enc_vpu_deinit(struct venc_h264_inst *inst);
> > +
> > +#endif
> > diff --git a/drivers/media/platform/mtk-vcodec/venc_drv_if.c b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
> > index d293f2c..28ef4a7 100644
> > --- a/drivers/media/platform/mtk-vcodec/venc_drv_if.c
> > +++ b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
> > @@ -25,6 +25,7 @@
> >  
> >  #include "venc_drv_base.h"
> >  #include "vp8_enc/venc_vp8_if.h"
> > +#include "h264_enc/venc_h264_if.h"
> >  
> >  int venc_if_create(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
> >  {
> > @@ -38,6 +39,8 @@ int venc_if_create(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
> >                  ctx->enc_if = get_vp8_enc_comm_if();
> >                  break;
> >  	case V4L2_PIX_FMT_H264:
> > +	        ctx->enc_if = get_h264_enc_comm_if();
> > +	        break;
> >  	default:
> >  		return -EINVAL;
> >  	}
> > 
> 
> Regards,
> 
> 	Hans

Best Regards
PoChun



From arnd at arndb.de  Tue Feb 16 03:57:30 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 12:57:30 +0100
Subject: [PATCH 1/3] ARM: zynq: Move early printk virtual address to
 vmalloc area
In-Reply-To: <67c9013fc61f53515934b54847a05df8b8e1504a.1455552315.git.michal.simek@xilinx.com>
References: <67c9013fc61f53515934b54847a05df8b8e1504a.1455552315.git.michal.simek@xilinx.com>
Message-ID: <4209295.YSuxZXZMPH@wuerfel>

On Monday 15 February 2016 17:05:17 Michal Simek wrote:
> The patch
> "ARM: 8432/1: move VMALLOC_END from 0xff000000 to 0xff800000"
> (sha1: 6ff0966052c46efb53980b8a1add2e7b49c9f560)
> has moved also start of VMALLOC area because size didn't change.
> That's why origin location of vmalloc was
>    vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
> and now is
>    vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
> 
> That's why uart virtual addresses need to be changed to reflect this new
> memory setup. Starting address should be vmalloc start address.
> 
> Signed-off-by: Michal Simek <michal.simek at xilinx.com>

All three patches look good to me,

Acked-by: Arnd Bergmann <arnd at arndb.de>

I would like to hear back from Nico on this though: is this an expected
outcome of your patch, or is it something you had not considered at
all?

Do we need to audit all platforms for other instances of the same
problem? I see for instance

static struct map_desc jornada720_io_desc[] __initdata = {
        {       /* Epson registers */
                .virtual        = 0xf0000000,
                .pfn            = __phys_to_pfn(EPSONREGSTART),
                .length         = EPSONREGLEN,
                .type           = MT_DEVICE
        }, {    /* Epson frame buffer */

in arch/arm/mach-sa1100/jornada720.c. Could this have the same problem?

I would guess that only machines with 768MB of RAM (or more) can run
into the bug.

	Arnd


From hs.liao at mediatek.com  Tue Feb 16 04:06:22 2016
From: hs.liao at mediatek.com (Horng-Shyang Liao)
Date: Tue, 16 Feb 2016 20:06:22 +0800
Subject: [RFC 1/3] dt-bindings: soc: Add documentation for the MediaTek
 GCE unit
In-Reply-To: <56B8D5A3.3000506@gmail.com>
References: <1453266881-16849-1-git-send-email-hs.liao@mediatek.com>
 <1453266881-16849-2-git-send-email-hs.liao@mediatek.com>
 <20160120163826.GA23400@rob-hp-laptop>
 <1453433893.15298.13.camel@mtksdaap41> <56B8D5A3.3000506@gmail.com>
Message-ID: <1455624382.17318.6.camel@mtksdaap41>

Hi Matthias,

On Mon, 2016-02-08 at 18:51 +0100, Matthias Brugger wrote:
> 
> On 22/01/16 04:38, Horng-Shyang Liao wrote:
> > Hi Rob,
> >
> > On Wed, 2016-01-20 at 10:38 -0600, Rob Herring wrote:
> >> On Wed, Jan 20, 2016 at 01:14:38PM +0800, hs.liao at mediatek.com wrote:
> >>> From: HS Liao <hs.liao at mediatek.com>
> >>>
> >>> This adds documentation for the MediaTek Global Command Engine (GCE) unit
> >>> found in MT8173 SoCs.
> >>>
> >>> Signed-off-by: HS Liao <hs.liao at mediatek.com>
> >>> ---
> >>>   .../devicetree/bindings/soc/mediatek/gce.txt       |   33 ++++++++++++++++++++
> >>>   1 file changed, 33 insertions(+)
> >>>   create mode 100644 Documentation/devicetree/bindings/soc/mediatek/gce.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/soc/mediatek/gce.txt b/Documentation/devicetree/bindings/soc/mediatek/gce.txt
> >>> new file mode 100644
> >>> index 0000000..878b11e
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/soc/mediatek/gce.txt
> >>> @@ -0,0 +1,33 @@
> >>> +MediaTek GCE
> >>> +===============
> >>> +
> >>> +The Global Command Engine (GCE) is used to help read/write registers with
> >>> +critical time limitation, such as updating display configuration during the
> >>> +vblank. The GCE can be used to implement the Command Queue (CMDQ) driver.
> >>> +Currently, the GCE only supports display related hardwares, but we expect
> >>> +it can be extended to other hardwares for future requirements.
> >>
> >> That's a hardware limitation or just s/w is only using it for display?
> >> If the latter, that's not really relevant to this binding and should be
> >> removed.
> >
> > Just s/w is only using it for display.
> > I will remove it from next patch.
> >
> >>> +
> >>> +Required properties:
> >>> +- compatible: Must be "mediatek,mt8173-gce"
> >>> +- reg: Address range of the GCE unit
> >>> +- interrupts: The interrupt signal from the GCE block
> >>> +- clock: Clocks according to the common clock binding
> >>> +- clock-names: Must be "gce" to stand for GCE clock
> >>> +
> >>> +Example:
> >>> +
> >>> +	gce: gce at 10212000 {
> >>> +		compatible = "mediatek,mt8173-gce";
> >>> +		reg = <0 0x10212000 0 0x1000>;
> >>> +		interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_LOW>;
> >>> +		clocks = <&infracfg CLK_INFRA_GCE>;
> >>> +		clock-names = "gce";
> >>> +	};
> >>> +
> >>> +	mmsys: clock-controller at 14000000 {
> >>> +		compatible = "mediatek,mt8173-mmsys", "syscon";
> >>> +		reg = <0 0x14000000 0 0x1000>;
> >>> +		power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> >>> +		#clock-cells = <1>;
> >>> +		mediatek,gce = <&gce>;
> >>
> >> Not documented.
> >
> > It's just an example about how gce is used by display mmsys.
> > After I discussed with Mediatek display owner,
> > we think this can be moved to display device tree document.
> > Do you agree with this suggestion?
> > If so, I will remove it from next patch, too.
> >
> 
> The problem is that mediatek,gce is not documented, but only 
> mediatek,mt8173-gce.

How about this?

Required properties for a client device:
- mediatek,gce: Should point to the respective GCE block

Example for a client device:

mmsys: clock-controller at 14000000 {
	compatible = "mediatek,mt8173-mmsys";
	mediatek,gce = <&gce>;
	...
};


> 
> Regards,
> Matthias

Thanks,
HS Liao



From niklas.soderlund at ragnatech.se  Tue Feb 16 04:06:27 2016
From: niklas.soderlund at ragnatech.se (Niklas =?iso-8859-1?Q?S=F6derlund?=)
Date: Tue, 16 Feb 2016 13:06:27 +0100
Subject: [PATCH v3 1/8] iommu: Add MMIO mapping type
In-Reply-To: <56BCAF66.8010206@arm.com>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <1455065878-11906-2-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <13740597.5lZXKsEG19@avalon> <56BCAF66.8010206@arm.com>
Message-ID: <20160216120626.GA26710@bigcity.dyn.berto.se>

Hi Robin,

Thanks for your update patch I will include it in my next version. But
I'm sorry I do not understand, is your modification an addition or a
substitution to your original patch?

* Robin Murphy <robin.murphy at arm.com> [2016-02-11 15:57:26 +0000]:

> On 11/02/16 00:02, Laurent Pinchart wrote:
> >Hi Niklas,
> >
> >Thank you for the patch.
> >
> >On Wednesday 10 February 2016 01:57:51 Niklas S?derlund wrote:
> >>From: Robin Murphy <robin.murphy at arm.com>
> >>
> >>On some platforms, MMIO regions might need slightly different treatment
> >>compared to mapping regular memory; add the notion of MMIO mappings to
> >>the IOMMU API's memory type flags, so that callers can let the IOMMU
> >>drivers know to do the right thing.
> >>
> >>Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> >>Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> >
> >Answering the question from the cover letter, yes, it's totally fine to pick
> >the ack, that's actually expected.
> >
> >>---
> >>  drivers/iommu/io-pgtable-arm.c | 4 +++-
> >>  include/linux/iommu.h          | 1 +
> >
> >You might be asked to split this patch in two.
>
> Worse than that, you might also be asked to fix it up when the silly author
> remembers that he did this on a stage-2-only ARM SMMU, and the attributes
> for the stage 1 tables that the IPMMU uses are in a different code path:
>
> --->8---
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 5b5c299..7622c6e 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -354,7 +354,10 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
> arm_lpae_io_pgtable *data,
>                 if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
>                         pte |= ARM_LPAE_PTE_AP_RDONLY;
>
> -               if (prot & IOMMU_CACHE)
> +               if (prot & IOMMU_MMIO)
> +                       pte |= (ARM_LPAE_MAIR_ATTR_IDX_DEV
> +                               << ARM_LPAE_PTE_ATTRINDX_SHIFT);
> +               else if (prot & IOMMU_CACHE)
>                         pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE
>                                 << ARM_LPAE_PTE_ATTRINDX_SHIFT);
>         } else {
> --->8---
>
> Sorry for the bother,
> Robin.
>
> >>  2 files changed, 4 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> >>index 381ca5a..3ff4f87 100644
> >>--- a/drivers/iommu/io-pgtable-arm.c
> >>+++ b/drivers/iommu/io-pgtable-arm.c
> >>@@ -364,7 +364,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
> >>arm_lpae_io_pgtable *data, pte |= ARM_LPAE_PTE_HAP_READ;
> >>  		if (prot & IOMMU_WRITE)
> >>  			pte |= ARM_LPAE_PTE_HAP_WRITE;
> >>-		if (prot & IOMMU_CACHE)
> >>+		if (prot & IOMMU_MMIO)
> >>+			pte |= ARM_LPAE_PTE_MEMATTR_DEV;
> >>+		else if (prot & IOMMU_CACHE)
> >>  			pte |= ARM_LPAE_PTE_MEMATTR_OIWB;
> >>  		else
> >>  			pte |= ARM_LPAE_PTE_MEMATTR_NC;
> >>diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> >>index a5c539f..34b6432 100644
> >>--- a/include/linux/iommu.h
> >>+++ b/include/linux/iommu.h
> >>@@ -30,6 +30,7 @@
> >>  #define IOMMU_WRITE	(1 << 1)
> >>  #define IOMMU_CACHE	(1 << 2) /* DMA cache coherency */
> >>  #define IOMMU_NOEXEC	(1 << 3)
> >>+#define IOMMU_MMIO	(1 << 4) /* e.g. things like MSI doorbells */
> >>
> >>  struct iommu_ops;
> >>  struct iommu_group;
> >
>


From ard.biesheuvel at linaro.org  Tue Feb 16 04:11:41 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 13:11:41 +0100
Subject: [PATCH] arm64: mark kernel text segment as MEMBLOCK_NOMAP
In-Reply-To: <56C30441.1080003@arm.com>
References: <1455528512-32491-1-git-send-email-ard.biesheuvel@linaro.org>
 <56C2FF07.30205@arm.com>
 <CAKv+Gu_yTz-ohFPS0wMX42iCkDNaSwZoZ8Yi-zsZNNu1LNDkZQ@mail.gmail.com>
 <56C30441.1080003@arm.com>
Message-ID: <CAKv+Gu9=_qCirHeRJzNqbfgCCXrWb_q4GL0_fWJPHMy4Es8Efg@mail.gmail.com>

On 16 February 2016 at 12:13, James Morse <james.morse at arm.com> wrote:
> On 16/02/16 10:57, Ard Biesheuvel wrote:
>> On 16 February 2016 at 11:50, James Morse <james.morse at arm.com> wrote:
>>> On 15/02/16 09:28, Ard Biesheuvel wrote:
>>>> This should hopefully address the issue reported by James, but I suppose
>>>> more work is required on the hibernate side to ensure the unmapped text
>>>> region is preserved, since it is no longer covered by the linear mapping.
>>>
>>> It does, now I have to work out how best to fix hibernate!
>>>
>>
>> Indeed. The alternative would be to map the [_stext, _etext] interval
>> into the linear region as a ro/nx alias of the actual mapping in the
>> vmalloc region. That would probably make your life easier, but I am
>> not convinced the overall result is better.
>
> I assumed you would NACK any approach that looked like that:
> It could be done temporarily while the memory snapshot is being taken, only
> swsusp_save() would see this mapping, it can be removed again afterwards. But
> pfn_valid() will still say those pages aren't there, and there is no
> memblock_clear_nomap() to change this.
>

Actually, we may have memblock_clear_nomap() at some point, since we
need it to simply relocate_initrd(), i.e., moving the initrd if its
memory is not covered by the linear mapping is much more complicated
than simply adding its memory to the linear mapping, and that requires
clearing the NOMAP flag as well if the region intersects with the UEFI
memory map (this is a corner case but one that does occur in practice)

But in this case, clearing the NOMAP flag only to appease pfn_valid()
is not the right approach, imo. Once the linear mapping is created, we
should not change the underlying memblock regions anymore. Also, what
pfn_valid() tells you should be in sync with what mappings are
actually present in the linear region (i.e., the issue you hit
originally)

> The current approach involves copying the kernel text into pages that are saved,
> and having two lists of pages that need restoring. (wheels within wheels!)
> Pretty unpleasant, and requires another patch in the core code, so likely won't
> be possible for v4.6. I should have the patches out for review later today.
>

I think a ro/nx alias in the linear region for [_stext, _etext] is
pretty harmless, and much preferred over having to add hacks on top of
generic layers like hibernate. The cost in terms of page tables and
TLB entries is zero, since the adjacent regions are mapped anyway, and
the region is never accessed during normal use.

So I will fold that in before sending out my v6.

-- 
Ard.


From stefano.stabellini at eu.citrix.com  Tue Feb 16 04:14:14 2016
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 16 Feb 2016 12:14:14 +0000
Subject: [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
In-Reply-To: <2801550.oZPkqjv8nW@wuerfel>
References: <1455278707-2008263-1-git-send-email-arnd@arndb.de>
 <alpine.DEB.2.02.1602151643150.27008@kaball.uk.xensource.com>
 <2801550.oZPkqjv8nW@wuerfel>
Message-ID: <alpine.DEB.2.02.1602161156160.27008@kaball.uk.xensource.com>

On Tue, 16 Feb 2016, Arnd Bergmann wrote:
> On Monday 15 February 2016 16:51:08 Stefano Stabellini wrote:
> > > 
> > > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> > > index 8ea45a5cd806..fd3d6fd290a9 100644
> > > --- a/drivers/video/fbdev/Kconfig
> > > +++ b/drivers/video/fbdev/Kconfig
> > > @@ -2241,6 +2241,7 @@ config FB_VIRTUAL
> > >  config XEN_FBDEV_FRONTEND
> > >       tristate "Xen virtual frame buffer support"
> > >       depends on FB && XEN
> > > +     depends on INPUT || !INPUT_MISC
> > >       select FB_SYS_FILLRECT
> > >       select FB_SYS_COPYAREA
> > >       select FB_SYS_IMAGEBLIT
> > 
> > This looks very hackish. Couldn't we just do the following?
> > 
> > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> > index 8ea45a5..3c15f6d 100644
> > --- a/drivers/video/fbdev/Kconfig
> > +++ b/drivers/video/fbdev/Kconfig
> > @@ -2246,7 +2246,7 @@ config XEN_FBDEV_FRONTEND
> >         select FB_SYS_IMAGEBLIT
> >         select FB_SYS_FOPS
> >         select FB_DEFERRED_IO
> > -       select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
> > +       select INPUT_XEN_KBDDEV_FRONTEND if (INPUT && INPUT_MISC)
> >         select XEN_XENBUS_FRONTEND
> >         default y
> >         help
> > 
> 
> No, that doesn't solve the problem:
> 
> If XEN_FBDEV_FRONTEND=y, INPUT=m and INPUT_MISC=y, we would still
> get INPUT_XEN_KBDDEV_FRONTEND=y, which cannot work because of INPUT=m.
> 
> INPUT_MISC already depends on INPUT, so your change has no effect
> at all.

Please correct me if I am wrong, but the difference is that with this
change if INPUT=m, then the build system would ask the user whether she
wants to select INPUT_XEN_KBDDEV_FRONTEND as m or y, instead of
unconditionally set INPUT_XEN_KBDDEV_FRONTEND=y.

However it is true that if the users chooses
INPUT_XEN_KBDDEV_FRONTEND=y, then the problem persists.
Maybe we also need:

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 1f2337a..303df24 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -721,7 +721,7 @@ config INPUT_CMA3000_I2C
 
 config INPUT_XEN_KBDDEV_FRONTEND
 	tristate "Xen virtual keyboard and mouse support"
-	depends on XEN
+	depends on XEN && INPUT
 	default y
 	select XEN_XENBUS_FRONTEND
 	help


Do you have a kernel config with INPUT=m that I can use to test with?


From catalin.marinas at arm.com  Tue Feb 16 04:21:53 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 16 Feb 2016 12:21:53 +0000
Subject: [PATCH v2] arm64: add alignment fault hanling
In-Reply-To: <56C300AD.8070505@arm.com>
References: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
 <20160216103104.GC14509@arm.com> <56C300AD.8070505@arm.com>
Message-ID: <20160216122153.GD19413@e104818-lin.cambridge.arm.com>

On Tue, Feb 16, 2016 at 10:57:49AM +0000, Robin Murphy wrote:
> On 16/02/16 10:31, Will Deacon wrote:
> >On Tue, Feb 16, 2016 at 04:44:35AM +0000, EunTaik Lee wrote:
> >>Userspace memory is mapped as below:
> >>F2A7F000--F2A7FFFF Normal Memory
> >>F2A80000--F2A80FFF Device nGnRnE
> >>
> >>And that userspace application makes a system call
> >>as below:
> >>
> >>-009 |do_strncpy_from_user(inline)
> >>-009 |strncpy_from_user()
> >>-010 |getname_flags()
> >>-011 |user_path_at_empty()
> >>-012 |user_path_at()
> >>-013 |SYSC_faccessat(inline)
> >>-013 |sys_faccessat()
> >>-014 |__sys_trace(asm)
> >>  --> |exception
> >>
> >>The string spans from 0xF2A7FFC1 to 0xF2A7FFFB.
> >>
> >>When do_strncpy_from_user() reads the last (unsigned long)
> >>value, the alignement fault is triggered. The 8 byte
> >>from 0xF2A7FFC1 spans to the next page that is mapped as
> >>Device nGnRnE, which does not allow an unaligned access,
> >>causes the abort.
> >>
> >>The instruction which caused the alignment fault is registered
> >>in the fixup table but the exception handler does not reach there.
> >>
> >>This patch registers a alignment fault handler and fixes up the
> >>pc if appropriate.
> >
> >As discussed with Catalin previously, we should solve this by adding a
> >guard page rather than handling the fault.

I don't think we can trivially add this without implementing an arm64
specific arch_get_unmapped_area().

> ...especially since we may not even get a fault. See "Crossing a page
> boundary with different memory types or Shareability attributes" in the
> UNPREDICTABLE spec (K1.2.10 in the latest ARMv8 ARM).

While this is CONSTRAINED UNPREDICTABLE, it still doesn't sound good. If
you end up with such adjacent mappings in user space, you can claim it's
the user's responsibility not to do unpredictable accesses across such
boundary. But in this case, it's the kernel do_strncpy_from_user()
assuming that it can freely go across boundaries and patch the fault
afterwards.

Still digging into this but I think we have a bug.

-- 
Catalin


From linus.walleij at linaro.org  Tue Feb 16 04:28:52 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 16 Feb 2016 13:28:52 +0100
Subject: [PATCH 1/2] pinctrl: mediatek: fix direction control issue
In-Reply-To: <1455612869.11448.22.camel@mtksdaap41>
References: <1454462686-770-1-git-send-email-biao.huang@mediatek.com>
 <1454462686-770-2-git-send-email-biao.huang@mediatek.com>
 <1454555015.4618.10.camel@mussux00>
 <CACRpkdZb2-TX1eY7eyK5qCqOg66MP1e4+OO287roJdP=RB6-Fg@mail.gmail.com>
 <1455242831.35628.15.camel@mussux00>
 <1455612869.11448.22.camel@mtksdaap41>
Message-ID: <CACRpkdb1pVQY0UG-_Z5ivyG6rPZq5YibYcRhzdnDMghfH8jMjA@mail.gmail.com>

On Tue, Feb 16, 2016 at 9:54 AM, Yingjoe Chen <yingjoe.chen at mediatek.com> wrote:

> To make it more clear, for a GPIO pin to get input on MTK chip, we must:
>
> - Enable input for the pad (input-enable)

This should be done by the pin control portions of the driver in
response to the PIN_CONFIG_INPUT_ENABLE generic pin
config setting.

Possibly *also* by just writing the hardware registers
from the callbacks right below here:

> - Set mux to GPIO mode

This should be done by just writing the hardware registers
in these callbacks from struct pinmux_ops:

        int (*gpio_request_enable) (struct pinctrl_dev *pctldev,
                                    struct pinctrl_gpio_range *range,
                                    unsigned offset);
        void (*gpio_disable_free) (struct pinctrl_dev *pctldev,
                                   struct pinctrl_gpio_range *range,
                                   unsigned offset);
        int (*gpio_set_direction) (struct pinctrl_dev *pctldev,
                                   struct pinctrl_gpio_range *range,
                                   unsigned offset,
                                   bool input);

In respons to these functions being called from the corresponding
GPIO driver:

extern int pinctrl_request_gpio(unsigned gpio);
extern void pinctrl_free_gpio(unsigned gpio);
extern int pinctrl_gpio_direction_input(unsigned gpio);
extern int pinctrl_gpio_direction_output(unsigned gpio);

> - Set GPIO direction to input

This should be done in these callbacks from struct gpio_chip:

        int                     (*direction_input)(struct gpio_chip *chip,
                                                unsigned offset);
        int                     (*direction_output)(struct gpio_chip *chip,
                                                unsigned offset, int value);

By just writing the hardware registers.

> Currently user need to add a dts node to set pinmux to GPIO mode with
> input-enable property, the driver need to call gpio_direction_input to
> set direction.

It seems like:

- Your GPIO driver is not calling the pinctrl_request_gpio/
  pinctrl_gpio_direction_* etc.

- Your pinmux driver is not implementing the GPIO-specifif
  .gpio_* functions

> Since input-enable and GPIO direction are 2 different things, we now
> think this patch is inappropriate. Instead, user should not required to
> add pinmux node in dts if all he want is use it as plain GPIO input.

If you sort out the above callbacks (also read
Documentation/pinctrl.txt about GPIO) I think it is
clear what you need to do.

Usually you should only need a special pinmux/pinconf node
for a GPIO line if you need to specify pull-up or similar electronic
things for that GPIO.

Yours,
Linus Walleij


From broonie at kernel.org  Tue Feb 16 04:38:54 2016
From: broonie at kernel.org (Mark Brown)
Date: Tue, 16 Feb 2016 12:38:54 +0000
Subject: [PATCH v5 3/5] mtd: devices: m25p80: add support for mmap read
 request
In-Reply-To: <56C2D731.6050306@ti.com>
References: <1449807000-6457-1-git-send-email-vigneshr@ti.com>
 <1449807000-6457-4-git-send-email-vigneshr@ti.com>
 <20160209193616.GN13270@sirena.org.uk> <56BC1D3E.5020203@ti.com>
 <20160212223711.GD18988@sirena.org.uk> <56C2D731.6050306@ti.com>
Message-ID: <20160216123854.GJ18327@sirena.org.uk>

On Tue, Feb 16, 2016 at 01:30:49PM +0530, Vignesh R wrote:
> On 02/13/2016 04:07 AM, Mark Brown wrote:
> > On Thu, Feb 11, 2016 at 11:03:50AM +0530, Vignesh R wrote:
> >> On 02/10/2016 01:06 AM, Mark Brown wrote:

> >>> Looking at this I can't help but think that spi_flash_read() ought to
> >>> have the stub in rather than the caller.  But given that we're pretty
> >>> much only ever expecting one user I'm not 100% sure it actually matters.

> >> Well, my initial patch set passed long list of arguments to
> >> spi_flash_read(), but Brian suggested to use struct[1] in order to avoid
> >> unnecessary churn when things need changed in the API.

> > I don't see what that has to do with my point?

> AFAIU, your previous comment was to move initialization of
> spi_flash_read_message struct to spi_flash_read(). This would mean

No, not at all.  I'm talking about how we handle the case where we don't
have hardware support for this and need to implement it in software -
currently that's in a separate place to the place where we call the
driver.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/b4c89e33/attachment.sig>

From robin.murphy at arm.com  Tue Feb 16 04:43:40 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue, 16 Feb 2016 12:43:40 +0000
Subject: [PATCH v3 1/8] iommu: Add MMIO mapping type
In-Reply-To: <20160216120626.GA26710@bigcity.dyn.berto.se>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <1455065878-11906-2-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <13740597.5lZXKsEG19@avalon> <56BCAF66.8010206@arm.com>
 <20160216120626.GA26710@bigcity.dyn.berto.se>
Message-ID: <56C3197C.8090903@arm.com>

On 16/02/16 12:06, Niklas S?derlund wrote:
> Hi Robin,
>
> Thanks for your update patch I will include it in my next version. But
> I'm sorry I do not understand, is your modification an addition or a
> substitution to your original patch?

Apologies for being confusing - that was a diff on top of the existing 
patch, to be folded in. My original patch was only handling IOMMU_MMIO 
for stage 2 PTEs, so we also need the extra code to handle the different 
way of setting the appropriate memory type in stage 1 PTEs.

Robin.

> * Robin Murphy <robin.murphy at arm.com> [2016-02-11 15:57:26 +0000]:
>
>> On 11/02/16 00:02, Laurent Pinchart wrote:
>>> Hi Niklas,
>>>
>>> Thank you for the patch.
>>>
>>> On Wednesday 10 February 2016 01:57:51 Niklas S?derlund wrote:
>>>> From: Robin Murphy <robin.murphy at arm.com>
>>>>
>>>> On some platforms, MMIO regions might need slightly different treatment
>>>> compared to mapping regular memory; add the notion of MMIO mappings to
>>>> the IOMMU API's memory type flags, so that callers can let the IOMMU
>>>> drivers know to do the right thing.
>>>>
>>>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>>>> Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
>>>
>>> Answering the question from the cover letter, yes, it's totally fine to pick
>>> the ack, that's actually expected.
>>>
>>>> ---
>>>>   drivers/iommu/io-pgtable-arm.c | 4 +++-
>>>>   include/linux/iommu.h          | 1 +
>>>
>>> You might be asked to split this patch in two.
>>
>> Worse than that, you might also be asked to fix it up when the silly author
>> remembers that he did this on a stage-2-only ARM SMMU, and the attributes
>> for the stage 1 tables that the IPMMU uses are in a different code path:
>>
>> --->8---
>> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
>> index 5b5c299..7622c6e 100644
>> --- a/drivers/iommu/io-pgtable-arm.c
>> +++ b/drivers/iommu/io-pgtable-arm.c
>> @@ -354,7 +354,10 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
>> arm_lpae_io_pgtable *data,
>>                  if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
>>                          pte |= ARM_LPAE_PTE_AP_RDONLY;
>>
>> -               if (prot & IOMMU_CACHE)
>> +               if (prot & IOMMU_MMIO)
>> +                       pte |= (ARM_LPAE_MAIR_ATTR_IDX_DEV
>> +                               << ARM_LPAE_PTE_ATTRINDX_SHIFT);
>> +               else if (prot & IOMMU_CACHE)
>>                          pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE
>>                                  << ARM_LPAE_PTE_ATTRINDX_SHIFT);
>>          } else {
>> --->8---
>>
>> Sorry for the bother,
>> Robin.
>>
>>>>   2 files changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
>>>> index 381ca5a..3ff4f87 100644
>>>> --- a/drivers/iommu/io-pgtable-arm.c
>>>> +++ b/drivers/iommu/io-pgtable-arm.c
>>>> @@ -364,7 +364,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
>>>> arm_lpae_io_pgtable *data, pte |= ARM_LPAE_PTE_HAP_READ;
>>>>   		if (prot & IOMMU_WRITE)
>>>>   			pte |= ARM_LPAE_PTE_HAP_WRITE;
>>>> -		if (prot & IOMMU_CACHE)
>>>> +		if (prot & IOMMU_MMIO)
>>>> +			pte |= ARM_LPAE_PTE_MEMATTR_DEV;
>>>> +		else if (prot & IOMMU_CACHE)
>>>>   			pte |= ARM_LPAE_PTE_MEMATTR_OIWB;
>>>>   		else
>>>>   			pte |= ARM_LPAE_PTE_MEMATTR_NC;
>>>> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
>>>> index a5c539f..34b6432 100644
>>>> --- a/include/linux/iommu.h
>>>> +++ b/include/linux/iommu.h
>>>> @@ -30,6 +30,7 @@
>>>>   #define IOMMU_WRITE	(1 << 1)
>>>>   #define IOMMU_CACHE	(1 << 2) /* DMA cache coherency */
>>>>   #define IOMMU_NOEXEC	(1 << 3)
>>>> +#define IOMMU_MMIO	(1 << 4) /* e.g. things like MSI doorbells */
>>>>
>>>>   struct iommu_ops;
>>>>   struct iommu_group;
>>>
>>
>



From ard.biesheuvel at linaro.org  Tue Feb 16 04:52:31 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 13:52:31 +0100
Subject: [PATCH v6sub1 00/11] arm64: split linear and kernel mappings
Message-ID: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>

At the request of Catalin, this series has been split off from my series
'arm64: implement support for KASLR v4' [1]. This sub-series deals with
moving the kernel out of the linear mapping into the vmalloc area. This
is a prerequisite for independent physical and virtual randomization of
the kernel image. On top of that, considering that these changes allow
the linear mapping to start at an arbitrary offset above PAGE_OFFSET, it
should be an improvement in itself due to the fact that we can now choose
PAGE_OFFSET such that RAM can be mapped using large block sizes.

For instance, on my Seattle A0 box, the kernel is loaded 16 MB into the
lowest GB of RAM, which means __pa(PAGE_OFFSET) is not 1 GB aligned, and
the entire 16 GB of RAM will be mapped using 2 MB blocks. (Similarly,
for 64 KB granule kernels, the entire 16 GB of RAM will be mapped using
pages since __pa(PAGE_OFFSET) is not 512 MB aligned). With these changes
 __pa(PAGE_OFFSET) will always be chosen such that it is aligned to a
quantity that allows efficient mapping.

Note that of the entire KASLR series, this sub-series is the most likely to
cause problems, and hence requires the most careful review and testing. This
is due to the fact that, with these changes, the invariant __va(__pa(x)) == x
no longer holds, and any code that is based on that assumption needs to be
updated.

The complete series can be found here:
https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-kaslr-v6

Changes since v5 [2]:
- fixed an initrd issue, where __va() was called by the generic early FDT code
  before memstart_addr is assigned (#2, #10)
- add patch #3 to fix a circular header dependency so we can use BUG_ON in
  asm/memory.h
- BUG() if __va() is called before memstart_addr is assigned (#11)
- fix a (transient) issue with GCC 4.9 or older in the KVM ksym ref patch  (#8)
  that affects bisectability (the actual issue surfaces after applying patch #9
  and disappears again with patch #11)
- fix a KASAN problem in the previous version of patch #9, where the shadow
  region of the module area was inadvertently populated with KASAN zero pages;
  this fixes at least one of the reported KASAN related issues with this series
- folded __maybe_unused change into patch #9
- folded change to memblock_add() back the entire kernel image instead of only
  the init and data segments after clipping for mem=
- map the linear alias of [_stext, _etext] as read-only/non-executable so its
  contents are visible to subsystems like hibernate in the expected place (#9)
- folded patch that removed clip_memory_range() and reverted to the generic
  memblock_enforce_memory_limit() (#11)

Changes since v4:
- added Marc's ack to patch #6
- round the kasan zero shadow region around the kernel image to swapper block
  size (#7)
- ensure that we don't clip the kernel image when clipping RAM to the linear
  region size (#8)

Patch #1 allows the low mark of memblocks discovered from the FDT to be
overridden by the architecture.

Patch #2 allows the assignment of initrd_start and initrd_end in generic early
FDT code to be overridden by architecture code.

Patch #3 reverses the #include dependencies between asm/bug.h and another
header file so that asm/bug.h can be included (and used) in asm/memory.h

Patch #4 enables the huge-vmap generic feature for arm64. This should be an
improvement in itself, but the significance for this series is that it allows
unmap_kernel_range() to be called on the [__init_begin, __init_end) region,
which may be partially mapped using block mappings.

Patch #5 introduces KIMAGE_VADDR as a separate, preparatory step towards
decoupling the kernel placement from PAGE_OFFSET

Patch #6 implements some translation table accessors that operate on statically
allocate translation tables before the linear mapping is up.

Patch #7 decouples the fixmap initialization from the linear mapping, by using
the accessors implemented by patch #6

Patch #8 removes assumptions made my KVM regarding the placement of the kernel
image inside the linear mapping.

Patch #9 moves the kernel image from the base of the linear mapping to the base
of the vmalloc area. The modules area, which sits right below the kernel image,
is moved along and is put right before the start of the vmalloc area.

Patch #10 defers the __va translation of the initrd to after the assignment of
memstart_addr.

Patch #11 decouples PHYS_OFFSET from PAGE_OFFSET, which allows the linear
mapping to cover all discovered memory, regardless of where the kernel image is
located in it. This effectively allows the kernel to be loaded at any physical
address (provided that the correct alignment is used)

[1] http://thread.gmane.org/gmane.linux.kernel/2135931
[2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/473894

Ard Biesheuvel (11):
  of/fdt: make memblock minimum physical address arch configurable
  of/fdt: factor out assignment of initrd_start/initrd_end
  arm64: prevent potential circular header dependencies in asm/bug.h
  arm64: add support for ioremap() block mappings
  arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
  arm64: pgtable: implement static [pte|pmd|pud]_offset variants
  arm64: decouple early fixmap init from linear mapping
  arm64: kvm: deal with kernel symbols outside of linear mapping
  arm64: move kernel image to base of vmalloc area
  arm64: defer __va translation of initrd_start and initrd_end
  arm64: allow kernel Image to be loaded anywhere in physical memory

 Documentation/arm64/booting.txt                      |  20 ++-
 Documentation/features/vm/huge-vmap/arch-support.txt |   2 +-
 arch/arm/include/asm/kvm_asm.h                       |   2 +
 arch/arm/kvm/arm.c                                   |   8 +-
 arch/arm64/Kconfig                                   |   1 +
 arch/arm64/include/asm/boot.h                        |   6 +
 arch/arm64/include/asm/bug.h                         |   2 +-
 arch/arm64/include/asm/debug-monitors.h              |   2 +-
 arch/arm64/include/asm/kasan.h                       |   2 +-
 arch/arm64/include/asm/kernel-pgtable.h              |  12 ++
 arch/arm64/include/asm/kvm_asm.h                     |   2 +
 arch/arm64/include/asm/kvm_host.h                    |   8 +-
 arch/arm64/include/asm/memory.h                      |  55 +++++--
 arch/arm64/include/asm/pgtable.h                     |  23 ++-
 arch/arm64/kernel/head.S                             |   8 +-
 arch/arm64/kernel/image.h                            |  13 +-
 arch/arm64/kernel/vmlinux.lds.S                      |   4 +-
 arch/arm64/kvm/hyp.S                                 |   6 +-
 arch/arm64/kvm/hyp/debug-sr.c                        |   1 +
 arch/arm64/mm/dump.c                                 |  12 +-
 arch/arm64/mm/init.c                                 |  99 ++++++++++--
 arch/arm64/mm/kasan_init.c                           |  27 +++-
 arch/arm64/mm/mmu.c                                  | 168 +++++++++++++++-----
 drivers/of/fdt.c                                     |  19 ++-
 24 files changed, 381 insertions(+), 121 deletions(-)

-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb 16 04:52:32 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 13:52:32 +0100
Subject: [PATCH v6sub1 01/11] of/fdt: make memblock minimum physical address
 arch configurable
In-Reply-To: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455627162-31600-2-git-send-email-ard.biesheuvel@linaro.org>

By default, early_init_dt_add_memory_arch() ignores memory below
the base of the kernel image since it won't be addressable via the
linear mapping. However, this is not appropriate anymore once we
decouple the kernel text mapping from the linear mapping, so archs
may want to drop the low limit entirely. So allow the minimum to be
overridden by setting MIN_MEMBLOCK_ADDR.

Acked-by: Mark Rutland <mark.rutland at arm.com>
Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/of/fdt.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79db7899..1f98156f8996 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -976,13 +976,16 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
 }
 
 #ifdef CONFIG_HAVE_MEMBLOCK
+#ifndef MIN_MEMBLOCK_ADDR
+#define MIN_MEMBLOCK_ADDR	__pa(PAGE_OFFSET)
+#endif
 #ifndef MAX_MEMBLOCK_ADDR
 #define MAX_MEMBLOCK_ADDR	((phys_addr_t)~0)
 #endif
 
 void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 {
-	const u64 phys_offset = __pa(PAGE_OFFSET);
+	const u64 phys_offset = MIN_MEMBLOCK_ADDR;
 
 	if (!PAGE_ALIGNED(base)) {
 		if (size < PAGE_SIZE - (base & ~PAGE_MASK)) {
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb 16 04:52:33 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 13:52:33 +0100
Subject: [PATCH v6sub1 02/11] of/fdt: factor out assignment of
 initrd_start/initrd_end
In-Reply-To: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455627162-31600-3-git-send-email-ard.biesheuvel@linaro.org>

Since architectures may not yet have their linear mapping up and running
when the initrd address is discovered from the DT, factor out the
assignment of initrd_start and initrd_end, so that an architecture can
override it and use the translation it needs.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/of/fdt.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 1f98156f8996..3e90bce70545 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -760,6 +760,16 @@ const void * __init of_flat_dt_match_machine(const void *default_match,
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
+#ifndef __early_init_dt_declare_initrd
+static void __early_init_dt_declare_initrd(unsigned long start,
+					   unsigned long end)
+{
+	initrd_start = (unsigned long)__va(start);
+	initrd_end = (unsigned long)__va(end);
+	initrd_below_start_ok = 1;
+}
+#endif
+
 /**
  * early_init_dt_check_for_initrd - Decode initrd location from flat tree
  * @node: reference to node containing initrd location ('chosen')
@@ -782,9 +792,7 @@ static void __init early_init_dt_check_for_initrd(unsigned long node)
 		return;
 	end = of_read_number(prop, len/4);
 
-	initrd_start = (unsigned long)__va(start);
-	initrd_end = (unsigned long)__va(end);
-	initrd_below_start_ok = 1;
+	__early_init_dt_declare_initrd(start, end);
 
 	pr_debug("initrd_start=0x%llx  initrd_end=0x%llx\n",
 		 (unsigned long long)start, (unsigned long long)end);
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb 16 04:52:34 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 13:52:34 +0100
Subject: [PATCH v6sub1 03/11] arm64: prevent potential circular header
 dependencies in asm/bug.h
In-Reply-To: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455627162-31600-4-git-send-email-ard.biesheuvel@linaro.org>

Currently, using BUG_ON() in header files is cumbersome, due to the fact
that asm/bug.h transitively includes a lot of other header files, resulting
in the actual BUG_ON() invocation appearing before its definition in the
preprocessor input. So let's reverse the #include dependency between
asm/bug.h and asm/debug-monitors.h, by moving the definition of BUG_BRK_IMM
from the latter to the former. Also fix up one user of asm/debug-monitors.h
which relied on a transitive include.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/bug.h            | 2 +-
 arch/arm64/include/asm/debug-monitors.h | 2 +-
 arch/arm64/kvm/hyp/debug-sr.c           | 1 +
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/bug.h b/arch/arm64/include/asm/bug.h
index 4a748ce9ba1a..679d49221998 100644
--- a/arch/arm64/include/asm/bug.h
+++ b/arch/arm64/include/asm/bug.h
@@ -18,7 +18,7 @@
 #ifndef _ARCH_ARM64_ASM_BUG_H
 #define _ARCH_ARM64_ASM_BUG_H
 
-#include <asm/debug-monitors.h>
+#define BUG_BRK_IMM			0x800
 
 #ifdef CONFIG_GENERIC_BUG
 #define HAVE_ARCH_BUG
diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
index 279c85b5ec09..e893a1fca9c2 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -20,6 +20,7 @@
 
 #include <linux/errno.h>
 #include <linux/types.h>
+#include <asm/bug.h>
 #include <asm/esr.h>
 #include <asm/insn.h>
 #include <asm/ptrace.h>
@@ -57,7 +58,6 @@
 #define FAULT_BRK_IMM			0x100
 #define KGDB_DYN_DBG_BRK_IMM		0x400
 #define KGDB_COMPILED_DBG_BRK_IMM	0x401
-#define BUG_BRK_IMM			0x800
 
 /*
  * BRK instruction encoding
diff --git a/arch/arm64/kvm/hyp/debug-sr.c b/arch/arm64/kvm/hyp/debug-sr.c
index c9c1e97501a9..2f8bca8af295 100644
--- a/arch/arm64/kvm/hyp/debug-sr.c
+++ b/arch/arm64/kvm/hyp/debug-sr.c
@@ -18,6 +18,7 @@
 #include <linux/compiler.h>
 #include <linux/kvm_host.h>
 
+#include <asm/debug-monitors.h>
 #include <asm/kvm_asm.h>
 #include <asm/kvm_mmu.h>
 
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb 16 04:52:35 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 13:52:35 +0100
Subject: [PATCH v6sub1 04/11] arm64: add support for ioremap() block mappings
In-Reply-To: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455627162-31600-5-git-send-email-ard.biesheuvel@linaro.org>

This wires up the existing generic huge-vmap feature, which allows
ioremap() to use PMD or PUD sized block mappings. It also adds support
to the unmap path for dealing with block mappings, which will allow us
to unmap the __init region using unmap_kernel_range() in a subsequent
patch.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 Documentation/features/vm/huge-vmap/arch-support.txt |  2 +-
 arch/arm64/Kconfig                                   |  1 +
 arch/arm64/include/asm/memory.h                      |  6 +++
 arch/arm64/mm/mmu.c                                  | 41 ++++++++++++++++++++
 4 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/Documentation/features/vm/huge-vmap/arch-support.txt b/Documentation/features/vm/huge-vmap/arch-support.txt
index af6816bccb43..df1d1f3c9af2 100644
--- a/Documentation/features/vm/huge-vmap/arch-support.txt
+++ b/Documentation/features/vm/huge-vmap/arch-support.txt
@@ -9,7 +9,7 @@
     |       alpha: | TODO |
     |         arc: | TODO |
     |         arm: | TODO |
-    |       arm64: | TODO |
+    |       arm64: |  ok  |
     |       avr32: | TODO |
     |    blackfin: | TODO |
     |         c6x: | TODO |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc62289a63e..cd767fa3037a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -49,6 +49,7 @@ config ARM64
 	select HAVE_ALIGNED_STRUCT_PAGE if SLUB
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_ARCH_BITREVERSE
+	select HAVE_ARCH_HUGE_VMAP
 	select HAVE_ARCH_JUMP_LABEL
 	select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP && !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
 	select HAVE_ARCH_KGDB
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 853953cd1f08..c65aad7b13dc 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -100,6 +100,12 @@
 #define MT_S2_NORMAL		0xf
 #define MT_S2_DEVICE_nGnRE	0x1
 
+#ifdef CONFIG_ARM64_4K_PAGES
+#define IOREMAP_MAX_ORDER	(PUD_SHIFT)
+#else
+#define IOREMAP_MAX_ORDER	(PMD_SHIFT)
+#endif
+
 #ifndef __ASSEMBLY__
 
 extern phys_addr_t		memstart_addr;
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 7711554a94f4..73383019f212 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -714,3 +714,44 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
 
 	return dt_virt;
 }
+
+int __init arch_ioremap_pud_supported(void)
+{
+	/* only 4k granule supports level 1 block mappings */
+	return IS_ENABLED(CONFIG_ARM64_4K_PAGES);
+}
+
+int __init arch_ioremap_pmd_supported(void)
+{
+	return 1;
+}
+
+int pud_set_huge(pud_t *pud, phys_addr_t phys, pgprot_t prot)
+{
+	BUG_ON(phys & ~PUD_MASK);
+	set_pud(pud, __pud(phys | PUD_TYPE_SECT | pgprot_val(mk_sect_prot(prot))));
+	return 1;
+}
+
+int pmd_set_huge(pmd_t *pmd, phys_addr_t phys, pgprot_t prot)
+{
+	BUG_ON(phys & ~PMD_MASK);
+	set_pmd(pmd, __pmd(phys | PMD_TYPE_SECT | pgprot_val(mk_sect_prot(prot))));
+	return 1;
+}
+
+int pud_clear_huge(pud_t *pud)
+{
+	if (!pud_sect(*pud))
+		return 0;
+	pud_clear(pud);
+	return 1;
+}
+
+int pmd_clear_huge(pmd_t *pmd)
+{
+	if (!pmd_sect(*pmd))
+		return 0;
+	pmd_clear(pmd);
+	return 1;
+}
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb 16 04:52:37 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 13:52:37 +0100
Subject: [PATCH v6sub1 06/11] arm64: pgtable: implement static
 [pte|pmd|pud]_offset variants
In-Reply-To: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455627162-31600-7-git-send-email-ard.biesheuvel@linaro.org>

The page table accessors pte_offset(), pud_offset() and pmd_offset()
rely on __va translations, so they can only be used after the linear
mapping has been installed. For the early fixmap and kasan init routines,
whose page tables are allocated statically in the kernel image, these
functions will return bogus values. So implement pte_offset_kimg(),
pmd_offset_kimg() and pud_offset_kimg(), which can be used instead
before any page tables have been allocated dynamically.

Reviewed-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/pgtable.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 4229f75fd145..87355408d448 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -445,6 +445,9 @@ static inline phys_addr_t pmd_page_paddr(pmd_t pmd)
 
 #define pmd_page(pmd)		pfn_to_page(__phys_to_pfn(pmd_val(pmd) & PHYS_MASK))
 
+/* use ONLY for statically allocated translation tables */
+#define pte_offset_kimg(dir,addr)	((pte_t *)__phys_to_kimg(pte_offset_phys((dir), (addr))))
+
 /*
  * Conversion functions: convert a page and protection to a page entry,
  * and a page entry and page directory to the page they refer to.
@@ -488,6 +491,9 @@ static inline phys_addr_t pud_page_paddr(pud_t pud)
 
 #define pud_page(pud)		pfn_to_page(__phys_to_pfn(pud_val(pud) & PHYS_MASK))
 
+/* use ONLY for statically allocated translation tables */
+#define pmd_offset_kimg(dir,addr)	((pmd_t *)__phys_to_kimg(pmd_offset_phys((dir), (addr))))
+
 #else
 
 #define pud_page_paddr(pud)	({ BUILD_BUG(); 0; })
@@ -497,6 +503,8 @@ static inline phys_addr_t pud_page_paddr(pud_t pud)
 #define pmd_set_fixmap_offset(pudp, addr)	((pmd_t *)pudp)
 #define pmd_clear_fixmap()
 
+#define pmd_offset_kimg(dir,addr)	((pmd_t *)dir)
+
 #endif	/* CONFIG_PGTABLE_LEVELS > 2 */
 
 #if CONFIG_PGTABLE_LEVELS > 3
@@ -535,6 +543,9 @@ static inline phys_addr_t pgd_page_paddr(pgd_t pgd)
 
 #define pgd_page(pgd)		pfn_to_page(__phys_to_pfn(pgd_val(pgd) & PHYS_MASK))
 
+/* use ONLY for statically allocated translation tables */
+#define pud_offset_kimg(dir,addr)	((pud_t *)__phys_to_kimg(pud_offset_phys((dir), (addr))))
+
 #else
 
 #define pgd_page_paddr(pgd)	({ BUILD_BUG(); 0;})
@@ -544,6 +555,8 @@ static inline phys_addr_t pgd_page_paddr(pgd_t pgd)
 #define pud_set_fixmap_offset(pgdp, addr)	((pud_t *)pgdp)
 #define pud_clear_fixmap()
 
+#define pud_offset_kimg(dir,addr)	((pud_t *)dir)
+
 #endif  /* CONFIG_PGTABLE_LEVELS > 3 */
 
 #define pgd_ERROR(pgd)		__pgd_error(__FILE__, __LINE__, pgd_val(pgd))
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb 16 04:52:38 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 13:52:38 +0100
Subject: [PATCH v6sub1 07/11] arm64: decouple early fixmap init from linear
 mapping
In-Reply-To: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455627162-31600-8-git-send-email-ard.biesheuvel@linaro.org>

Since the early fixmap page tables are populated using pages that are
part of the static footprint of the kernel, they are covered by the
initial kernel mapping, and we can refer to them without using __va/__pa
translations, which are tied to the linear mapping.

Since the fixmap page tables are disjoint from the kernel mapping up
to the top level pgd entry, we can refer to bm_pte[] directly, and there
is no need to walk the page tables and perform __pa()/__va() translations
at each step.

Reviewed-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/mm/mmu.c | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 73383019f212..b84915723ea0 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -583,7 +583,7 @@ static inline pud_t * fixmap_pud(unsigned long addr)
 
 	BUG_ON(pgd_none(*pgd) || pgd_bad(*pgd));
 
-	return pud_offset(pgd, addr);
+	return pud_offset_kimg(pgd, addr);
 }
 
 static inline pmd_t * fixmap_pmd(unsigned long addr)
@@ -592,16 +592,12 @@ static inline pmd_t * fixmap_pmd(unsigned long addr)
 
 	BUG_ON(pud_none(*pud) || pud_bad(*pud));
 
-	return pmd_offset(pud, addr);
+	return pmd_offset_kimg(pud, addr);
 }
 
 static inline pte_t * fixmap_pte(unsigned long addr)
 {
-	pmd_t *pmd = fixmap_pmd(addr);
-
-	BUG_ON(pmd_none(*pmd) || pmd_bad(*pmd));
-
-	return pte_offset_kernel(pmd, addr);
+	return &bm_pte[pte_index(addr)];
 }
 
 void __init early_fixmap_init(void)
@@ -613,14 +609,14 @@ void __init early_fixmap_init(void)
 
 	pgd = pgd_offset_k(addr);
 	pgd_populate(&init_mm, pgd, bm_pud);
-	pud = pud_offset(pgd, addr);
+	pud = fixmap_pud(addr);
 	pud_populate(&init_mm, pud, bm_pmd);
-	pmd = pmd_offset(pud, addr);
+	pmd = fixmap_pmd(addr);
 	pmd_populate_kernel(&init_mm, pmd, bm_pte);
 
 	/*
 	 * The boot-ioremap range spans multiple pmds, for which
-	 * we are not preparted:
+	 * we are not prepared:
 	 */
 	BUILD_BUG_ON((__fix_to_virt(FIX_BTMAP_BEGIN) >> PMD_SHIFT)
 		     != (__fix_to_virt(FIX_BTMAP_END) >> PMD_SHIFT));
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb 16 04:52:39 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 13:52:39 +0100
Subject: [PATCH v6sub1 08/11] arm64: kvm: deal with kernel symbols outside of
 linear mapping
In-Reply-To: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455627162-31600-9-git-send-email-ard.biesheuvel@linaro.org>

KVM on arm64 uses a fixed offset between the linear mapping at EL1 and
the HYP mapping at EL2. Before we can move the kernel virtual mapping
out of the linear mapping, we have to make sure that references to kernel
symbols that are accessed via the HYP mapping are translated to their
linear equivalent.

Reviewed-by: Mark Rutland <mark.rutland at arm.com>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm/include/asm/kvm_asm.h    |  2 ++
 arch/arm/kvm/arm.c                |  8 +++++---
 arch/arm64/include/asm/kvm_asm.h  | 17 +++++++++++++++++
 arch/arm64/include/asm/kvm_host.h |  8 +++++---
 arch/arm64/kvm/hyp.S              |  6 +++---
 5 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index 194c91b610ff..c35c349da069 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -79,6 +79,8 @@
 #define rr_lo_hi(a1, a2) a1, a2
 #endif
 
+#define kvm_ksym_ref(kva)	(kva)
+
 #ifndef __ASSEMBLY__
 struct kvm;
 struct kvm_vcpu;
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dda1959f0dde..975da6cfbf59 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -982,7 +982,7 @@ static void cpu_init_hyp_mode(void *dummy)
 	pgd_ptr = kvm_mmu_get_httbr();
 	stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
 	hyp_stack_ptr = stack_page + PAGE_SIZE;
-	vector_ptr = (unsigned long)__kvm_hyp_vector;
+	vector_ptr = (unsigned long)kvm_ksym_ref(__kvm_hyp_vector);
 
 	__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
 
@@ -1074,13 +1074,15 @@ static int init_hyp_mode(void)
 	/*
 	 * Map the Hyp-code called directly from the host
 	 */
-	err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
+	err = create_hyp_mappings(kvm_ksym_ref(__kvm_hyp_code_start),
+				  kvm_ksym_ref(__kvm_hyp_code_end));
 	if (err) {
 		kvm_err("Cannot map world-switch code\n");
 		goto out_free_mappings;
 	}
 
-	err = create_hyp_mappings(__start_rodata, __end_rodata);
+	err = create_hyp_mappings(kvm_ksym_ref(__start_rodata),
+				  kvm_ksym_ref(__end_rodata));
 	if (err) {
 		kvm_err("Cannot map rodata section\n");
 		goto out_free_mappings;
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 52b777b7d407..31b56008f412 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -26,7 +26,24 @@
 #define KVM_ARM64_DEBUG_DIRTY_SHIFT	0
 #define KVM_ARM64_DEBUG_DIRTY		(1 << KVM_ARM64_DEBUG_DIRTY_SHIFT)
 
+#define kvm_ksym_ref(sym)		((void *)&sym + kvm_ksym_shift)
+
 #ifndef __ASSEMBLY__
+#if __GNUC__ > 4
+#define kvm_ksym_shift			(PAGE_OFFSET - KIMAGE_VADDR)
+#else
+/*
+ * GCC versions 4.9 and older will fold the constant below into the addend of
+ * the reference to 'sym' above if kvm_ksym_shift is declared static or if the
+ * constant is used directly. However, since we use the small code model for
+ * the core kernel, the reference to 'sym' will be emitted as a adrp/add pair,
+ * with a +/- 4 GB range, resulting in linker relocation errors if the shift
+ * is sufficiently large. So prevent the compiler from folding the shift into
+ * the addend, by making the shift a variable with external linkage.
+ */
+__weak u64 kvm_ksym_shift = PAGE_OFFSET - KIMAGE_VADDR;
+#endif
+
 struct kvm;
 struct kvm_vcpu;
 
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 689d4c95e12f..e3d67ff8798b 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -307,7 +307,7 @@ static inline void kvm_arch_mmu_notifier_invalidate_page(struct kvm *kvm,
 struct kvm_vcpu *kvm_arm_get_running_vcpu(void);
 struct kvm_vcpu * __percpu *kvm_get_running_vcpus(void);
 
-u64 kvm_call_hyp(void *hypfn, ...);
+u64 __kvm_call_hyp(void *hypfn, ...);
 void force_vm_exit(const cpumask_t *mask);
 void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);
 
@@ -328,8 +328,8 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
 	 * Call initialization code, and switch to the full blown
 	 * HYP code.
 	 */
-	kvm_call_hyp((void *)boot_pgd_ptr, pgd_ptr,
-		     hyp_stack_ptr, vector_ptr);
+	__kvm_call_hyp((void *)boot_pgd_ptr, pgd_ptr,
+		       hyp_stack_ptr, vector_ptr);
 }
 
 static inline void kvm_arch_hardware_disable(void) {}
@@ -343,4 +343,6 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_clear_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu);
 
+#define kvm_call_hyp(f, ...) __kvm_call_hyp(kvm_ksym_ref(f), ##__VA_ARGS__)
+
 #endif /* __ARM64_KVM_HOST_H__ */
diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index 0ccdcbbef3c2..870578f84b1c 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -20,7 +20,7 @@
 #include <asm/assembler.h>
 
 /*
- * u64 kvm_call_hyp(void *hypfn, ...);
+ * u64 __kvm_call_hyp(void *hypfn, ...);
  *
  * This is not really a variadic function in the classic C-way and care must
  * be taken when calling this to ensure parameters are passed in registers
@@ -37,7 +37,7 @@
  * used to implement __hyp_get_vectors in the same way as in
  * arch/arm64/kernel/hyp_stub.S.
  */
-ENTRY(kvm_call_hyp)
+ENTRY(__kvm_call_hyp)
 	hvc	#0
 	ret
-ENDPROC(kvm_call_hyp)
+ENDPROC(__kvm_call_hyp)
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb 16 04:52:36 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 13:52:36 +0100
Subject: [PATCH v6sub1 05/11] arm64: introduce KIMAGE_VADDR as the virtual
 base of the kernel region
In-Reply-To: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455627162-31600-6-git-send-email-ard.biesheuvel@linaro.org>

This introduces the preprocessor symbol KIMAGE_VADDR which will serve as
the symbolic virtual base of the kernel region, i.e., the kernel's virtual
offset will be KIMAGE_VADDR + TEXT_OFFSET. For now, we define it as being
equal to PAGE_OFFSET, but in the future, it will be moved below it once
we move the kernel virtual mapping out of the linear mapping.

Reviewed-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/memory.h | 10 ++++++++--
 arch/arm64/kernel/head.S        |  2 +-
 arch/arm64/kernel/vmlinux.lds.S |  4 ++--
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index c65aad7b13dc..aebc739f5a11 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -51,7 +51,8 @@
 #define VA_BITS			(CONFIG_ARM64_VA_BITS)
 #define VA_START		(UL(0xffffffffffffffff) << VA_BITS)
 #define PAGE_OFFSET		(UL(0xffffffffffffffff) << (VA_BITS - 1))
-#define MODULES_END		(PAGE_OFFSET)
+#define KIMAGE_VADDR		(PAGE_OFFSET)
+#define MODULES_END		(KIMAGE_VADDR)
 #define MODULES_VADDR		(MODULES_END - SZ_64M)
 #define PCI_IO_END		(MODULES_VADDR - SZ_2M)
 #define PCI_IO_START		(PCI_IO_END - PCI_IO_SIZE)
@@ -75,8 +76,13 @@
  * private definitions which should NOT be used outside memory.h
  * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
  */
-#define __virt_to_phys(x)	(((phys_addr_t)(x) - PAGE_OFFSET + PHYS_OFFSET))
+#define __virt_to_phys(x) ({						\
+	phys_addr_t __x = (phys_addr_t)(x);				\
+	__x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :	\
+			     (__x - KIMAGE_VADDR + PHYS_OFFSET); })
+
 #define __phys_to_virt(x)	((unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET))
+#define __phys_to_kimg(x)	((unsigned long)((x) - PHYS_OFFSET + KIMAGE_VADDR))
 
 /*
  * Convert a page to/from a physical address
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 53b9f9f128c2..04d38a058b19 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -389,7 +389,7 @@ __create_page_tables:
 	 * Map the kernel image (starting with PHYS_OFFSET).
 	 */
 	mov	x0, x26				// swapper_pg_dir
-	mov	x5, #PAGE_OFFSET
+	ldr	x5, =KIMAGE_VADDR
 	create_pgd_entry x0, x5, x3, x6
 	ldr	x6, =KERNEL_END			// __va(KERNEL_END)
 	mov	x3, x24				// phys offset
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index b78a3c772294..282e3e64a17e 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -89,7 +89,7 @@ SECTIONS
 		*(.discard.*)
 	}
 
-	. = PAGE_OFFSET + TEXT_OFFSET;
+	. = KIMAGE_VADDR + TEXT_OFFSET;
 
 	.head.text : {
 		_text = .;
@@ -186,4 +186,4 @@ ASSERT(__idmap_text_end - (__idmap_text_start & ~(SZ_4K - 1)) <= SZ_4K,
 /*
  * If padding is applied before .head.text, virt<->phys conversions will fail.
  */
-ASSERT(_text == (PAGE_OFFSET + TEXT_OFFSET), "HEAD is misaligned")
+ASSERT(_text == (KIMAGE_VADDR + TEXT_OFFSET), "HEAD is misaligned")
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb 16 04:52:41 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 13:52:41 +0100
Subject: [PATCH v6sub1 10/11] arm64: defer __va translation of initrd_start
 and initrd_end
In-Reply-To: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455627162-31600-11-git-send-email-ard.biesheuvel@linaro.org>

Before deferring the assignment of memstart_addr in a subsequent patch, to
the moment where all memory has been discovered and possibly clipped based
on the size of the linear region and the presence of a mem= command line
parameter, we need to ensure that memstart_addr is not used to perform __va
translations before it is assigned.

One such use is in the generic early DT discovery of the initrd location,
which is recorded as a virtual address in the globals initrd_start and
initrd_end. So wire up the generic support to declare the initrd addresses,
and implement it without __va() translations, and perform the translation
after memstart_addr has been assigned.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/memory.h |  8 ++++++++
 arch/arm64/mm/init.c            | 13 +++++++++----
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 4388651d1f0d..18b7e77c7495 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -121,6 +121,14 @@
 #define IOREMAP_MAX_ORDER	(PMD_SHIFT)
 #endif
 
+#ifdef CONFIG_BLK_DEV_INITRD
+#define __early_init_dt_declare_initrd(__start, __end)			\
+	do {								\
+		initrd_start = (__start);				\
+		initrd_end = (__end);					\
+	} while (0)
+#endif
+
 #ifndef __ASSEMBLY__
 
 extern phys_addr_t		memstart_addr;
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 1d627cd8121c..52d1fc465885 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -59,8 +59,8 @@ static int __init early_initrd(char *p)
 	if (*endp == ',') {
 		size = memparse(endp + 1, NULL);
 
-		initrd_start = (unsigned long)__va(start);
-		initrd_end = (unsigned long)__va(start + size);
+		initrd_start = start;
+		initrd_end = start + size;
 	}
 	return 0;
 }
@@ -168,8 +168,13 @@ void __init arm64_memblock_init(void)
 	 */
 	memblock_reserve(__pa(_text), _end - _text);
 #ifdef CONFIG_BLK_DEV_INITRD
-	if (initrd_start)
-		memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
+	if (initrd_start) {
+		memblock_reserve(initrd_start, initrd_end - initrd_start);
+
+		/* the generic initrd code expects virtual addresses */
+		initrd_start = __phys_to_virt(initrd_start);
+		initrd_end = __phys_to_virt(initrd_end);
+	}
 #endif
 
 	early_init_fdt_scan_reserved_mem();
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb 16 04:52:40 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 13:52:40 +0100
Subject: [PATCH v6sub1 09/11] arm64: move kernel image to base of vmalloc area
In-Reply-To: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455627162-31600-10-git-send-email-ard.biesheuvel@linaro.org>

This moves the module area to right before the vmalloc area, and moves
the kernel image to the base of the vmalloc area. This is an intermediate
step towards implementing KASLR, which allows the kernel image to be
located anywhere in the vmalloc area.

Since other subsystems such as hibernate may still need to refer to the
kernel text or data segments via their linears addresses, both are mapped
in the linear region as well. The linear alias of the text region is
mapped read-only/non-executable to prevent inadvertent modification or
execution.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/kasan.h   |   2 +-
 arch/arm64/include/asm/memory.h  |  21 ++--
 arch/arm64/include/asm/pgtable.h |  10 +-
 arch/arm64/mm/dump.c             |  12 +--
 arch/arm64/mm/init.c             |  23 ++--
 arch/arm64/mm/kasan_init.c       |  27 ++++-
 arch/arm64/mm/mmu.c              | 110 ++++++++++++++------
 7 files changed, 137 insertions(+), 68 deletions(-)

diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h
index de0d21211c34..71ad0f93eb71 100644
--- a/arch/arm64/include/asm/kasan.h
+++ b/arch/arm64/include/asm/kasan.h
@@ -14,7 +14,7 @@
  * KASAN_SHADOW_END: KASAN_SHADOW_START + 1/8 of kernel virtual addresses.
  */
 #define KASAN_SHADOW_START      (VA_START)
-#define KASAN_SHADOW_END        (KASAN_SHADOW_START + (1UL << (VA_BITS - 3)))
+#define KASAN_SHADOW_END        (KASAN_SHADOW_START + KASAN_SHADOW_SIZE)
 
 /*
  * This value is used to map an address to the corresponding shadow
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index aebc739f5a11..4388651d1f0d 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -45,16 +45,15 @@
  * VA_START - the first kernel virtual address.
  * TASK_SIZE - the maximum size of a user space task.
  * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area.
- * The module space lives between the addresses given by TASK_SIZE
- * and PAGE_OFFSET - it must be within 128MB of the kernel text.
  */
 #define VA_BITS			(CONFIG_ARM64_VA_BITS)
 #define VA_START		(UL(0xffffffffffffffff) << VA_BITS)
 #define PAGE_OFFSET		(UL(0xffffffffffffffff) << (VA_BITS - 1))
-#define KIMAGE_VADDR		(PAGE_OFFSET)
-#define MODULES_END		(KIMAGE_VADDR)
-#define MODULES_VADDR		(MODULES_END - SZ_64M)
-#define PCI_IO_END		(MODULES_VADDR - SZ_2M)
+#define KIMAGE_VADDR		(MODULES_END)
+#define MODULES_END		(MODULES_VADDR + MODULES_VSIZE)
+#define MODULES_VADDR		(VA_START + KASAN_SHADOW_SIZE)
+#define MODULES_VSIZE		(SZ_64M)
+#define PCI_IO_END		(PAGE_OFFSET - SZ_2M)
 #define PCI_IO_START		(PCI_IO_END - PCI_IO_SIZE)
 #define FIXADDR_TOP		(PCI_IO_START - SZ_2M)
 #define TASK_SIZE_64		(UL(1) << VA_BITS)
@@ -72,6 +71,16 @@
 #define TASK_UNMAPPED_BASE	(PAGE_ALIGN(TASK_SIZE / 4))
 
 /*
+ * The size of the KASAN shadow region. This should be 1/8th of the
+ * size of the entire kernel virtual address space.
+ */
+#ifdef CONFIG_KASAN
+#define KASAN_SHADOW_SIZE	(UL(1) << (VA_BITS - 3))
+#else
+#define KASAN_SHADOW_SIZE	(0)
+#endif
+
+/*
  * Physical vs virtual RAM address space conversion.  These are
  * private definitions which should NOT be used outside memory.h
  * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 87355408d448..a440f5a85d08 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -36,19 +36,13 @@
  *
  * VMEMAP_SIZE: allows the whole VA space to be covered by a struct page array
  *	(rounded up to PUD_SIZE).
- * VMALLOC_START: beginning of the kernel VA space
+ * VMALLOC_START: beginning of the kernel vmalloc space
  * VMALLOC_END: extends to the available space below vmmemmap, PCI I/O space,
  *	fixed mappings and modules
  */
 #define VMEMMAP_SIZE		ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) * sizeof(struct page), PUD_SIZE)
 
-#ifndef CONFIG_KASAN
-#define VMALLOC_START		(VA_START)
-#else
-#include <asm/kasan.h>
-#define VMALLOC_START		(KASAN_SHADOW_END + SZ_64K)
-#endif
-
+#define VMALLOC_START		(MODULES_END)
 #define VMALLOC_END		(PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - SZ_64K)
 
 #define vmemmap			((struct page *)(VMALLOC_END + SZ_64K))
diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index 0adbebbc2803..e83ffb00560c 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -35,7 +35,9 @@ struct addr_marker {
 };
 
 enum address_markers_idx {
-	VMALLOC_START_NR = 0,
+	MODULES_START_NR = 0,
+	MODULES_END_NR,
+	VMALLOC_START_NR,
 	VMALLOC_END_NR,
 #ifdef CONFIG_SPARSEMEM_VMEMMAP
 	VMEMMAP_START_NR,
@@ -45,12 +47,12 @@ enum address_markers_idx {
 	FIXADDR_END_NR,
 	PCI_START_NR,
 	PCI_END_NR,
-	MODULES_START_NR,
-	MODULES_END_NR,
 	KERNEL_SPACE_NR,
 };
 
 static struct addr_marker address_markers[] = {
+	{ MODULES_VADDR,	"Modules start" },
+	{ MODULES_END,		"Modules end" },
 	{ VMALLOC_START,	"vmalloc() Area" },
 	{ VMALLOC_END,		"vmalloc() End" },
 #ifdef CONFIG_SPARSEMEM_VMEMMAP
@@ -61,9 +63,7 @@ static struct addr_marker address_markers[] = {
 	{ FIXADDR_TOP,		"Fixmap end" },
 	{ PCI_IO_START,		"PCI I/O start" },
 	{ PCI_IO_END,		"PCI I/O end" },
-	{ MODULES_VADDR,	"Modules start" },
-	{ MODULES_END,		"Modules end" },
-	{ PAGE_OFFSET,		"Kernel Mapping" },
+	{ PAGE_OFFSET,		"Linear Mapping" },
 	{ -1,			NULL },
 };
 
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3b061e67bfe..1d627cd8121c 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -36,6 +36,7 @@
 #include <linux/swiotlb.h>
 
 #include <asm/fixmap.h>
+#include <asm/kasan.h>
 #include <asm/memory.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
@@ -302,22 +303,26 @@ void __init mem_init(void)
 #ifdef CONFIG_KASAN
 		  "    kasan   : 0x%16lx - 0x%16lx   (%6ld GB)\n"
 #endif
+		  "    modules : 0x%16lx - 0x%16lx   (%6ld MB)\n"
 		  "    vmalloc : 0x%16lx - 0x%16lx   (%6ld GB)\n"
+		  "      .init : 0x%p" " - 0x%p" "   (%6ld KB)\n"
+		  "      .text : 0x%p" " - 0x%p" "   (%6ld KB)\n"
+		  "      .data : 0x%p" " - 0x%p" "   (%6ld KB)\n"
 #ifdef CONFIG_SPARSEMEM_VMEMMAP
 		  "    vmemmap : 0x%16lx - 0x%16lx   (%6ld GB maximum)\n"
 		  "              0x%16lx - 0x%16lx   (%6ld MB actual)\n"
 #endif
 		  "    fixed   : 0x%16lx - 0x%16lx   (%6ld KB)\n"
 		  "    PCI I/O : 0x%16lx - 0x%16lx   (%6ld MB)\n"
-		  "    modules : 0x%16lx - 0x%16lx   (%6ld MB)\n"
-		  "    memory  : 0x%16lx - 0x%16lx   (%6ld MB)\n"
-		  "      .init : 0x%p" " - 0x%p" "   (%6ld KB)\n"
-		  "      .text : 0x%p" " - 0x%p" "   (%6ld KB)\n"
-		  "      .data : 0x%p" " - 0x%p" "   (%6ld KB)\n",
+		  "    memory  : 0x%16lx - 0x%16lx   (%6ld MB)\n",
 #ifdef CONFIG_KASAN
 		  MLG(KASAN_SHADOW_START, KASAN_SHADOW_END),
 #endif
+		  MLM(MODULES_VADDR, MODULES_END),
 		  MLG(VMALLOC_START, VMALLOC_END),
+		  MLK_ROUNDUP(__init_begin, __init_end),
+		  MLK_ROUNDUP(_text, _etext),
+		  MLK_ROUNDUP(_sdata, _edata),
 #ifdef CONFIG_SPARSEMEM_VMEMMAP
 		  MLG((unsigned long)vmemmap,
 		      (unsigned long)vmemmap + VMEMMAP_SIZE),
@@ -326,11 +331,7 @@ void __init mem_init(void)
 #endif
 		  MLK(FIXADDR_START, FIXADDR_TOP),
 		  MLM(PCI_IO_START, PCI_IO_END),
-		  MLM(MODULES_VADDR, MODULES_END),
-		  MLM(PAGE_OFFSET, (unsigned long)high_memory),
-		  MLK_ROUNDUP(__init_begin, __init_end),
-		  MLK_ROUNDUP(_text, _etext),
-		  MLK_ROUNDUP(_sdata, _edata));
+		  MLM(PAGE_OFFSET, (unsigned long)high_memory));
 
 #undef MLK
 #undef MLM
@@ -358,8 +359,8 @@ void __init mem_init(void)
 
 void free_initmem(void)
 {
-	fixup_init();
 	free_initmem_default(0);
+	fixup_init();
 }
 
 #ifdef CONFIG_BLK_DEV_INITRD
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index cc569a38bc76..7f10cc91fa8a 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -17,9 +17,11 @@
 #include <linux/start_kernel.h>
 
 #include <asm/mmu_context.h>
+#include <asm/kernel-pgtable.h>
 #include <asm/page.h>
 #include <asm/pgalloc.h>
 #include <asm/pgtable.h>
+#include <asm/sections.h>
 #include <asm/tlbflush.h>
 
 static pgd_t tmp_pg_dir[PTRS_PER_PGD] __initdata __aligned(PGD_SIZE);
@@ -33,7 +35,7 @@ static void __init kasan_early_pte_populate(pmd_t *pmd, unsigned long addr,
 	if (pmd_none(*pmd))
 		pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
 
-	pte = pte_offset_kernel(pmd, addr);
+	pte = pte_offset_kimg(pmd, addr);
 	do {
 		next = addr + PAGE_SIZE;
 		set_pte(pte, pfn_pte(virt_to_pfn(kasan_zero_page),
@@ -51,7 +53,7 @@ static void __init kasan_early_pmd_populate(pud_t *pud,
 	if (pud_none(*pud))
 		pud_populate(&init_mm, pud, kasan_zero_pmd);
 
-	pmd = pmd_offset(pud, addr);
+	pmd = pmd_offset_kimg(pud, addr);
 	do {
 		next = pmd_addr_end(addr, end);
 		kasan_early_pte_populate(pmd, addr, next);
@@ -68,7 +70,7 @@ static void __init kasan_early_pud_populate(pgd_t *pgd,
 	if (pgd_none(*pgd))
 		pgd_populate(&init_mm, pgd, kasan_zero_pud);
 
-	pud = pud_offset(pgd, addr);
+	pud = pud_offset_kimg(pgd, addr);
 	do {
 		next = pud_addr_end(addr, end);
 		kasan_early_pmd_populate(pud, addr, next);
@@ -126,9 +128,13 @@ static void __init clear_pgds(unsigned long start,
 
 void __init kasan_init(void)
 {
+	u64 kimg_shadow_start, kimg_shadow_end;
 	struct memblock_region *reg;
 	int i;
 
+	kimg_shadow_start = (u64)kasan_mem_to_shadow(_text);
+	kimg_shadow_end = (u64)kasan_mem_to_shadow(_end);
+
 	/*
 	 * We are going to perform proper setup of shadow memory.
 	 * At first we should unmap early shadow (clear_pgds() call bellow).
@@ -142,8 +148,23 @@ void __init kasan_init(void)
 
 	clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
 
+	vmemmap_populate(kimg_shadow_start, kimg_shadow_end, NUMA_NO_NODE);
+
+	/*
+	 * vmemmap_populate() has populated the shadow region that covers the
+	 * kernel image with SWAPPER_BLOCK_SIZE mappings, so we have to round
+	 * the start and end addresses to SWAPPER_BLOCK_SIZE as well, to prevent
+	 * kasan_populate_zero_shadow() from replacing the PMD block mappings
+	 * with PMD table mappings at the edges of the shadow region for the
+	 * kernel image.
+	 */
+	if (ARM64_SWAPPER_USES_SECTION_MAPS)
+		kimg_shadow_end = round_up(kimg_shadow_end, SWAPPER_BLOCK_SIZE);
+
 	kasan_populate_zero_shadow((void *)KASAN_SHADOW_START,
 			kasan_mem_to_shadow((void *)MODULES_VADDR));
+	kasan_populate_zero_shadow((void *)kimg_shadow_end,
+			kasan_mem_to_shadow((void *)PAGE_OFFSET));
 
 	for_each_memblock(memory, reg) {
 		void *start = (void *)__phys_to_virt(reg->base);
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index b84915723ea0..6eb8e49889d0 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -53,6 +53,10 @@ u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
 unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_bss;
 EXPORT_SYMBOL(empty_zero_page);
 
+static pte_t bm_pte[PTRS_PER_PTE] __page_aligned_bss;
+static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss __maybe_unused;
+static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss __maybe_unused;
+
 pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
 			      unsigned long size, pgprot_t vma_prot)
 {
@@ -347,16 +351,15 @@ static void create_mapping_late(phys_addr_t phys, unsigned long virt,
 
 static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end)
 {
-
 	unsigned long kernel_start = __pa(_stext);
-	unsigned long kernel_end = __pa(_end);
+	unsigned long kernel_end = __pa(_etext);
 
 	/*
-	 * The kernel itself is mapped at page granularity. Map all other
-	 * memory, making sure we don't overwrite the existing kernel mappings.
+	 * Take care not to create a writable alias for the
+	 * read-only text and rodata sections of the kernel image.
 	 */
 
-	/* No overlap with the kernel. */
+	/* No overlap with the kernel text */
 	if (end < kernel_start || start >= kernel_end) {
 		__create_pgd_mapping(pgd, start, __phys_to_virt(start),
 				     end - start, PAGE_KERNEL,
@@ -365,8 +368,8 @@ static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end
 	}
 
 	/*
-	 * This block overlaps the kernel mapping. Map the portion(s) which
-	 * don't overlap.
+	 * This block overlaps the kernel text mapping.
+	 * Map the portion(s) which don't overlap.
 	 */
 	if (start < kernel_start)
 		__create_pgd_mapping(pgd, start,
@@ -378,6 +381,16 @@ static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end
 				     __phys_to_virt(kernel_end),
 				     end - kernel_end, PAGE_KERNEL,
 				     early_pgtable_alloc);
+
+	/*
+	 * Map the linear alias of the [_stext, _etext) interval as
+	 * read-only/non-executable. This makes the contents of the
+	 * region accessible to subsystems such as hibernate, but
+	 * protects it from inadvertent modification or execution.
+	 */
+	__create_pgd_mapping(pgd, kernel_start, __phys_to_virt(kernel_start),
+			     kernel_end - kernel_start, PAGE_KERNEL_RO,
+			     early_pgtable_alloc);
 }
 
 static void __init map_mem(pgd_t *pgd)
@@ -398,25 +411,28 @@ static void __init map_mem(pgd_t *pgd)
 	}
 }
 
-#ifdef CONFIG_DEBUG_RODATA
 void mark_rodata_ro(void)
 {
+	if (!IS_ENABLED(CONFIG_DEBUG_RODATA))
+		return;
+
 	create_mapping_late(__pa(_stext), (unsigned long)_stext,
 				(unsigned long)_etext - (unsigned long)_stext,
 				PAGE_KERNEL_ROX);
-
 }
-#endif
 
 void fixup_init(void)
 {
-	create_mapping_late(__pa(__init_begin), (unsigned long)__init_begin,
-			(unsigned long)__init_end - (unsigned long)__init_begin,
-			PAGE_KERNEL);
+	/*
+	 * Unmap the __init region but leave the VM area in place. This
+	 * prevents the region from being reused for kernel modules, which
+	 * is not supported by kallsyms.
+	 */
+	unmap_kernel_range((u64)__init_begin, (u64)(__init_end - __init_begin));
 }
 
 static void __init map_kernel_chunk(pgd_t *pgd, void *va_start, void *va_end,
-				    pgprot_t prot)
+				    pgprot_t prot, struct vm_struct *vma)
 {
 	phys_addr_t pa_start = __pa(va_start);
 	unsigned long size = va_end - va_start;
@@ -426,6 +442,14 @@ static void __init map_kernel_chunk(pgd_t *pgd, void *va_start, void *va_end,
 
 	__create_pgd_mapping(pgd, pa_start, (unsigned long)va_start, size, prot,
 			     early_pgtable_alloc);
+
+	vma->addr	= va_start;
+	vma->phys_addr	= pa_start;
+	vma->size	= size;
+	vma->flags	= VM_MAP;
+	vma->caller	= __builtin_return_address(0);
+
+	vm_area_add_early(vma);
 }
 
 /*
@@ -433,17 +457,35 @@ static void __init map_kernel_chunk(pgd_t *pgd, void *va_start, void *va_end,
  */
 static void __init map_kernel(pgd_t *pgd)
 {
+	static struct vm_struct vmlinux_text, vmlinux_init, vmlinux_data;
 
-	map_kernel_chunk(pgd, _stext, _etext, PAGE_KERNEL_EXEC);
-	map_kernel_chunk(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC);
-	map_kernel_chunk(pgd, _data, _end, PAGE_KERNEL);
+	map_kernel_chunk(pgd, _stext, _etext, PAGE_KERNEL_EXEC, &vmlinux_text);
+	map_kernel_chunk(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC,
+			 &vmlinux_init);
+	map_kernel_chunk(pgd, _data, _end, PAGE_KERNEL, &vmlinux_data);
 
-	/*
-	 * The fixmap falls in a separate pgd to the kernel, and doesn't live
-	 * in the carveout for the swapper_pg_dir. We can simply re-use the
-	 * existing dir for the fixmap.
-	 */
-	set_pgd(pgd_offset_raw(pgd, FIXADDR_START), *pgd_offset_k(FIXADDR_START));
+	if (!pgd_val(*pgd_offset_raw(pgd, FIXADDR_START))) {
+		/*
+		 * The fixmap falls in a separate pgd to the kernel, and doesn't
+		 * live in the carveout for the swapper_pg_dir. We can simply
+		 * re-use the existing dir for the fixmap.
+		 */
+		set_pgd(pgd_offset_raw(pgd, FIXADDR_START),
+			*pgd_offset_k(FIXADDR_START));
+	} else if (CONFIG_PGTABLE_LEVELS > 3) {
+		/*
+		 * The fixmap shares its top level pgd entry with the kernel
+		 * mapping. This can really only occur when we are running
+		 * with 16k/4 levels, so we can simply reuse the pud level
+		 * entry instead.
+		 */
+		BUG_ON(!IS_ENABLED(CONFIG_ARM64_16K_PAGES));
+		set_pud(pud_set_fixmap_offset(pgd, FIXADDR_START),
+			__pud(__pa(bm_pmd) | PUD_TYPE_TABLE));
+		pud_clear_fixmap();
+	} else {
+		BUG();
+	}
 
 	kasan_copy_shadow(pgd);
 }
@@ -569,14 +611,6 @@ void vmemmap_free(unsigned long start, unsigned long end)
 }
 #endif	/* CONFIG_SPARSEMEM_VMEMMAP */
 
-static pte_t bm_pte[PTRS_PER_PTE] __page_aligned_bss;
-#if CONFIG_PGTABLE_LEVELS > 2
-static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss;
-#endif
-#if CONFIG_PGTABLE_LEVELS > 3
-static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss;
-#endif
-
 static inline pud_t * fixmap_pud(unsigned long addr)
 {
 	pgd_t *pgd = pgd_offset_k(addr);
@@ -608,8 +642,18 @@ void __init early_fixmap_init(void)
 	unsigned long addr = FIXADDR_START;
 
 	pgd = pgd_offset_k(addr);
-	pgd_populate(&init_mm, pgd, bm_pud);
-	pud = fixmap_pud(addr);
+	if (CONFIG_PGTABLE_LEVELS > 3 && !pgd_none(*pgd)) {
+		/*
+		 * We only end up here if the kernel mapping and the fixmap
+		 * share the top level pgd entry, which should only happen on
+		 * 16k/4 levels configurations.
+		 */
+		BUG_ON(!IS_ENABLED(CONFIG_ARM64_16K_PAGES));
+		pud = pud_offset_kimg(pgd, addr);
+	} else {
+		pgd_populate(&init_mm, pgd, bm_pud);
+		pud = fixmap_pud(addr);
+	}
 	pud_populate(&init_mm, pud, bm_pmd);
 	pmd = fixmap_pmd(addr);
 	pmd_populate_kernel(&init_mm, pmd, bm_pte);
-- 
2.5.0



From ard.biesheuvel at linaro.org  Tue Feb 16 04:52:42 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 13:52:42 +0100
Subject: [PATCH v6sub1 11/11] arm64: allow kernel Image to be loaded anywhere
 in physical memory
In-Reply-To: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1455627162-31600-12-git-send-email-ard.biesheuvel@linaro.org>

This relaxes the kernel Image placement requirements, so that it
may be placed at any 2 MB aligned offset in physical memory.

This is accomplished by ignoring PHYS_OFFSET when installing
memblocks, and accounting for the apparent virtual offset of
the kernel Image. As a result, virtual address references
below PAGE_OFFSET are correctly mapped onto physical references
into the kernel Image regardless of where it sits in memory.

Special care needs to be taken for dealing with memory limits passed
via mem=, since the generic implementation clips memory top down, which
may clip the kernel image itself if it is loaded high up in memory. To
deal with this case, we simply add back the memory covering the kernel
image, which may result in more memory to be retained than was passed
as a mem= parameter.

Since mem= should not be considered a production feature, a panic notifier
handler is installed that dumps the memory limit at panic time if one was
set.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 Documentation/arm64/booting.txt         | 20 ++++---
 arch/arm64/include/asm/boot.h           |  6 ++
 arch/arm64/include/asm/kernel-pgtable.h | 12 ++++
 arch/arm64/include/asm/kvm_asm.h        | 17 +-----
 arch/arm64/include/asm/memory.h         | 18 +++---
 arch/arm64/kernel/head.S                |  6 +-
 arch/arm64/kernel/image.h               | 13 ++--
 arch/arm64/mm/init.c                    | 63 +++++++++++++++++++-
 arch/arm64/mm/mmu.c                     |  3 +
 9 files changed, 119 insertions(+), 39 deletions(-)

diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt
index 701d39d3171a..56d6d8b796db 100644
--- a/Documentation/arm64/booting.txt
+++ b/Documentation/arm64/booting.txt
@@ -109,7 +109,13 @@ Header notes:
 			1 - 4K
 			2 - 16K
 			3 - 64K
-  Bits 3-63:	Reserved.
+  Bit 3:	Kernel physical placement
+			0 - 2MB aligned base should be as close as possible
+			    to the base of DRAM, since memory below it is not
+			    accessible via the linear mapping
+			1 - 2MB aligned base may be anywhere in physical
+			    memory
+  Bits 4-63:	Reserved.
 
 - When image_size is zero, a bootloader should attempt to keep as much
   memory as possible free for use by the kernel immediately after the
@@ -117,14 +123,14 @@ Header notes:
   depending on selected features, and is effectively unbound.
 
 The Image must be placed text_offset bytes from a 2MB aligned base
-address near the start of usable system RAM and called there. Memory
-below that base address is currently unusable by Linux, and therefore it
-is strongly recommended that this location is the start of system RAM.
-The region between the 2 MB aligned base address and the start of the
-image has no special significance to the kernel, and may be used for
-other purposes.
+address anywhere in usable system RAM and called there. The region
+between the 2 MB aligned base address and the start of the image has no
+special significance to the kernel, and may be used for other purposes.
 At least image_size bytes from the start of the image must be free for
 use by the kernel.
+NOTE: versions prior to v4.6 cannot make use of memory below the
+physical offset of the Image so it is recommended that the Image be
+placed as close as possible to the start of system RAM.
 
 Any memory described to the kernel (even that below the start of the
 image) which is not marked as reserved from the kernel (e.g., with a
diff --git a/arch/arm64/include/asm/boot.h b/arch/arm64/include/asm/boot.h
index 81151b67b26b..ebf2481889c3 100644
--- a/arch/arm64/include/asm/boot.h
+++ b/arch/arm64/include/asm/boot.h
@@ -11,4 +11,10 @@
 #define MIN_FDT_ALIGN		8
 #define MAX_FDT_SIZE		SZ_2M
 
+/*
+ * arm64 requires the kernel image to placed
+ * TEXT_OFFSET bytes beyond a 2 MB aligned base
+ */
+#define MIN_KIMG_ALIGN		SZ_2M
+
 #endif
diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
index a459714ee29e..5c6375d8528b 100644
--- a/arch/arm64/include/asm/kernel-pgtable.h
+++ b/arch/arm64/include/asm/kernel-pgtable.h
@@ -79,5 +79,17 @@
 #define SWAPPER_MM_MMUFLAGS	(PTE_ATTRINDX(MT_NORMAL) | SWAPPER_PTE_FLAGS)
 #endif
 
+/*
+ * To make optimal use of block mappings when laying out the linear
+ * mapping, round down the base of physical memory to a size that can
+ * be mapped efficiently, i.e., either PUD_SIZE (4k granule) or PMD_SIZE
+ * (64k granule), or a multiple that can be mapped using contiguous bits
+ * in the page tables: 32 * PMD_SIZE (16k granule)
+ */
+#ifdef CONFIG_ARM64_64K_PAGES
+#define ARM64_MEMSTART_ALIGN	SZ_512M
+#else
+#define ARM64_MEMSTART_ALIGN	SZ_1G
+#endif
 
 #endif	/* __ASM_KERNEL_PGTABLE_H */
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 31b56008f412..054ac25e7c2e 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -26,24 +26,9 @@
 #define KVM_ARM64_DEBUG_DIRTY_SHIFT	0
 #define KVM_ARM64_DEBUG_DIRTY		(1 << KVM_ARM64_DEBUG_DIRTY_SHIFT)
 
-#define kvm_ksym_ref(sym)		((void *)&sym + kvm_ksym_shift)
+#define kvm_ksym_ref(sym)		phys_to_virt((u64)&sym - kimage_voffset)
 
 #ifndef __ASSEMBLY__
-#if __GNUC__ > 4
-#define kvm_ksym_shift			(PAGE_OFFSET - KIMAGE_VADDR)
-#else
-/*
- * GCC versions 4.9 and older will fold the constant below into the addend of
- * the reference to 'sym' above if kvm_ksym_shift is declared static or if the
- * constant is used directly. However, since we use the small code model for
- * the core kernel, the reference to 'sym' will be emitted as a adrp/add pair,
- * with a +/- 4 GB range, resulting in linker relocation errors if the shift
- * is sufficiently large. So prevent the compiler from folding the shift into
- * the addend, by making the shift a variable with external linkage.
- */
-__weak u64 kvm_ksym_shift = PAGE_OFFSET - KIMAGE_VADDR;
-#endif
-
 struct kvm;
 struct kvm_vcpu;
 
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 18b7e77c7495..3239e4d78e0d 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -24,6 +24,7 @@
 #include <linux/compiler.h>
 #include <linux/const.h>
 #include <linux/types.h>
+#include <asm/bug.h>
 #include <asm/sizes.h>
 
 /*
@@ -88,10 +89,10 @@
 #define __virt_to_phys(x) ({						\
 	phys_addr_t __x = (phys_addr_t)(x);				\
 	__x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :	\
-			     (__x - KIMAGE_VADDR + PHYS_OFFSET); })
+			     (__x - kimage_voffset); })
 
 #define __phys_to_virt(x)	((unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET))
-#define __phys_to_kimg(x)	((unsigned long)((x) - PHYS_OFFSET + KIMAGE_VADDR))
+#define __phys_to_kimg(x)	((unsigned long)((x) + kimage_voffset))
 
 /*
  * Convert a page to/from a physical address
@@ -133,15 +134,16 @@
 
 extern phys_addr_t		memstart_addr;
 /* PHYS_OFFSET - the physical address of the start of memory. */
-#define PHYS_OFFSET		({ memstart_addr; })
+#define PHYS_OFFSET		({ BUG_ON(memstart_addr & 1); memstart_addr; })
+
+/* the offset between the kernel virtual and physical mappings */
+extern u64			kimage_voffset;
 
 /*
- * The maximum physical address that the linear direct mapping
- * of system RAM can cover. (PAGE_OFFSET can be interpreted as
- * a 2's complement signed quantity and negated to derive the
- * maximum size of the linear mapping.)
+ * Allow all memory at the discovery stage. We will clip it later.
  */
-#define MAX_MEMBLOCK_ADDR	({ memstart_addr - PAGE_OFFSET - 1; })
+#define MIN_MEMBLOCK_ADDR	0
+#define MAX_MEMBLOCK_ADDR	U64_MAX
 
 /*
  * PFNs are used to describe any physical page; this means
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 04d38a058b19..05b98289093e 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -428,7 +428,11 @@ __mmap_switched:
 	and	x4, x4, #~(THREAD_SIZE - 1)
 	msr	sp_el0, x4			// Save thread_info
 	str_l	x21, __fdt_pointer, x5		// Save FDT pointer
-	str_l	x24, memstart_addr, x6		// Save PHYS_OFFSET
+
+	ldr	x4, =KIMAGE_VADDR		// Save the offset between
+	sub	x4, x4, x24			// the kernel virtual and
+	str_l	x4, kimage_voffset, x5		// physical mappings
+
 	mov	x29, #0
 #ifdef CONFIG_KASAN
 	bl	kasan_early_init
diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
index 999633bd7294..c9c62cab25a4 100644
--- a/arch/arm64/kernel/image.h
+++ b/arch/arm64/kernel/image.h
@@ -42,15 +42,18 @@
 #endif
 
 #ifdef CONFIG_CPU_BIG_ENDIAN
-#define __HEAD_FLAG_BE	1
+#define __HEAD_FLAG_BE		1
 #else
-#define __HEAD_FLAG_BE	0
+#define __HEAD_FLAG_BE		0
 #endif
 
-#define __HEAD_FLAG_PAGE_SIZE ((PAGE_SHIFT - 10) / 2)
+#define __HEAD_FLAG_PAGE_SIZE	((PAGE_SHIFT - 10) / 2)
 
-#define __HEAD_FLAGS	((__HEAD_FLAG_BE << 0) |	\
-			 (__HEAD_FLAG_PAGE_SIZE << 1))
+#define __HEAD_FLAG_PHYS_BASE	1
+
+#define __HEAD_FLAGS		((__HEAD_FLAG_BE << 0) |	\
+				 (__HEAD_FLAG_PAGE_SIZE << 1) |	\
+				 (__HEAD_FLAG_PHYS_BASE << 3))
 
 /*
  * These will output as part of the Image header, which should be little-endian
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 52d1fc465885..c0ea54bd9995 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -35,8 +35,10 @@
 #include <linux/efi.h>
 #include <linux/swiotlb.h>
 
+#include <asm/boot.h>
 #include <asm/fixmap.h>
 #include <asm/kasan.h>
+#include <asm/kernel-pgtable.h>
 #include <asm/memory.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
@@ -46,7 +48,13 @@
 
 #include "mm.h"
 
-phys_addr_t memstart_addr __read_mostly = 0;
+/*
+ * We need to be able to catch inadvertent references to memstart_addr
+ * that occur (potentially in generic code) before arm64_memblock_init()
+ * executes, which assigns it its actual value. So use a default value
+ * that cannot be mistaken for a real physical address.
+ */
+phys_addr_t memstart_addr __read_mostly = ~0ULL;
 phys_addr_t arm64_dma_phys_limit __read_mostly;
 
 #ifdef CONFIG_BLK_DEV_INITRD
@@ -160,7 +168,33 @@ early_param("mem", early_mem);
 
 void __init arm64_memblock_init(void)
 {
-	memblock_enforce_memory_limit(memory_limit);
+	const s64 linear_region_size = -(s64)PAGE_OFFSET;
+
+	/*
+	 * Select a suitable value for the base of physical memory.
+	 */
+	memstart_addr = round_down(memblock_start_of_DRAM(),
+				   ARM64_MEMSTART_ALIGN);
+
+	/*
+	 * Remove the memory that we will not be able to cover with the
+	 * linear mapping. Take care not to clip the kernel which may be
+	 * high in memory.
+	 */
+	memblock_remove(max(memstart_addr + linear_region_size, __pa(_end)),
+			ULLONG_MAX);
+	if (memblock_end_of_DRAM() > linear_region_size)
+		memblock_remove(0, memblock_end_of_DRAM() - linear_region_size);
+
+	/*
+	 * Apply the memory limit if it was set. Since the kernel may be loaded
+	 * high up in memory, add back the kernel region that must be accessible
+	 * via the linear mapping.
+	 */
+	if (memory_limit != (phys_addr_t)ULLONG_MAX) {
+		memblock_enforce_memory_limit(memory_limit);
+		memblock_add(__pa(_text), (u64)(_end - _text));
+	}
 
 	/*
 	 * Register the kernel text, kernel data, initrd, and initial
@@ -386,3 +420,28 @@ static int __init keepinitrd_setup(char *__unused)
 
 __setup("keepinitrd", keepinitrd_setup);
 #endif
+
+/*
+ * Dump out memory limit information on panic.
+ */
+static int dump_mem_limit(struct notifier_block *self, unsigned long v, void *p)
+{
+	if (memory_limit != (phys_addr_t)ULLONG_MAX) {
+		pr_emerg("Memory Limit: %llu MB\n", memory_limit >> 20);
+	} else {
+		pr_emerg("Memory Limit: none\n");
+	}
+	return 0;
+}
+
+static struct notifier_block mem_limit_notifier = {
+	.notifier_call = dump_mem_limit,
+};
+
+static int __init register_mem_limit_dumper(void)
+{
+	atomic_notifier_chain_register(&panic_notifier_list,
+				       &mem_limit_notifier);
+	return 0;
+}
+__initcall(register_mem_limit_dumper);
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 6eb8e49889d0..b83c6bf7f90d 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -46,6 +46,9 @@
 
 u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
 
+u64 kimage_voffset __read_mostly;
+EXPORT_SYMBOL(kimage_voffset);
+
 /*
  * Empty_zero_page is a special page that is used for zero-initialized data
  * and COW.
-- 
2.5.0



From szabolcs.nagy at arm.com  Tue Feb 16 04:57:26 2016
From: szabolcs.nagy at arm.com (Szabolcs Nagy)
Date: Tue, 16 Feb 2016 12:57:26 +0000
Subject: [PATCH] arm64: Add support for Half precision floating point
In-Reply-To: <20160216115335.GE14509@arm.com>
References: <1453823566-26742-1-git-send-email-suzuki.poulose@arm.com>
 <20160126160257.GB28238@arm.com>
 <20160126161151.GE14823@e104818-lin.cambridge.arm.com>
 <20160128160022.GM775@arm.com> <56C30C7E.1030005@arm.com>
 <20160216115335.GE14509@arm.com>
Message-ID: <56C31CB6.7090901@arm.com>

On 16/02/16 11:53, Will Deacon wrote:
> On Tue, Feb 16, 2016 at 11:48:14AM +0000, Szabolcs Nagy wrote:
>> On 28/01/16 16:00, Will Deacon wrote:
>>> On Tue, Jan 26, 2016 at 04:11:51PM +0000, Catalin Marinas wrote:
>>>> On Tue, Jan 26, 2016 at 04:02:58PM +0000, Will Deacon wrote:
>>>>> On Tue, Jan 26, 2016 at 03:52:46PM +0000, Suzuki K Poulose wrote:
>>>>>> +#define HWCAP_FPHP		(1 << 9)
>>>>>> +#define HWCAP_ASIMDHP		(1 << 10)
>>>>>
>>>>> Where did we get to with the mrs trapping you proposed here?
>>>>>
>>>>>   http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374609.html
>>>>>
>>>>> At some point, we need to consider whether or not we want to continue
>>>>> adding new HWCAPs or whether your suggestion above is actually useful
>>>>> to userspace.
>>>>
>>>> IMO, even if we merge the MRS emulation, I would still like to see
>>>> HWCAPs exported. We are not short on bits yet (53 to go ;)).
>>>
>>> I'm less keen. HWCAPs don't align well with the way that the ARM
>>> architecture versions features and we should be encouraging people to
>>> use the MRS emulation if it exists.
>>>
>>>>> Did the libc guys get anywhere with a prototype? What do we need to do
>>>>> to make progress with it?
>>>>
>>>> This investigation should indeed continue but I think it is orthogonal.
>>>
>>> Not if its intended to replace HWCAPs in the longterm.
>>>
>>
>> userspace needs HWCAP bits independently of the MIDR emulation.
>>
>> MIDR cannot replace HWCAP:
>>
>> - MIDR does not map to features in a future-proof way
>>   (we don't know which MIDR will indicate fp16 availability)
>>
>> - MIDR would be useful for more fine-grained uarch specific
>>   tuning decisions, HWCAP is for arch extensions like fp16.
>>
>> - We don't yet know if the proposed MIDR emulation solves
>>   all userspace issues we want it to solve. I'll try to
>>   investigate that as well as the alternative VDSO based
>>   approach (if VDSO can work, that would be better for
>>   userspace). There are nasty issues here so the conclusion
>>   might take a while, but that should not hold up HWCAPs.
> 
> I'm not solely proposing MIDR as an alternative to HWCAP. I'm proposing
> that the feature registers, e.g. ID_AA64MMFR0_EL1 are used instead.
> 

if the ID_* system registers are made available to userspace
(with fixup for heterogeneous systems), that works too.

hwcap is still more accessible in userspace:

- libc gets it without additional syscall/trap
- user code can get it with getauxval(AT_HWCAP)
- ifunc resolvers take a hwcap argument.
- HWCAP_ bits are already exposed in uapi headers.

i'm not familiar with the ID_ regs though.



From aryabinin at virtuozzo.com  Tue Feb 16 04:59:09 2016
From: aryabinin at virtuozzo.com (Andrey Ryabinin)
Date: Tue, 16 Feb 2016 15:59:09 +0300
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
Message-ID: <56C31D1D.50708@virtuozzo.com>



On 02/15/2016 09:59 PM, Catalin Marinas wrote:
> On Mon, Feb 15, 2016 at 05:28:02PM +0300, Andrey Ryabinin wrote:
>> On 02/12/2016 07:06 PM, Catalin Marinas wrote:
>>> So far, we have:
>>>
>>> KASAN+for-next/kernmap goes wrong
>>> KASAN+UBSAN goes wrong
>>>
>>> Enabled individually, KASAN, UBSAN and for-next/kernmap seem fine. I may
>>> have to trim for-next/core down until we figure out where the problem
>>> is.
>>>
>>> BUG: KASAN: stack-out-of-bounds in find_busiest_group+0x164/0x16a0 at addr ffffffc93665bc8c
>>
>> Can it be related to TLB conflicts, which supposed to be fixed in
>> "arm64: kasan: avoid TLB conflicts" patch from "arm64: mm: rework page
>> table creation" series ?
> 
> I can very easily reproduce this with a vanilla 4.5-rc1 series by
> enabling inline instrumentation (maybe Mark's theory is true w.r.t.
> image size).
> 
> Some information, maybe you can shed some light on this. It seems to
> happen only for secondary CPUs on the swapper stack (I think allocated
> via fork_idle()). The code generated looks sane to me, so KASAN should
> not complain but maybe there is some uninitialised shadow, hence the
> error.
> 
> The report:
>

Actually, the first report is a bit more useful. It shows that shadow memory was corrupted:

  ffffffc93665bc00: f1 f1 f1 f1 00 f4 f4 f4 f2 f2 f2 f2 00 00 f1 f1
> ffffffc93665bc80: f1 f1 00 00 00 00 f3 f3 00 f4 f4 f4 f3 f3 f3 f3
                      ^
F1 - left redzone, it indicates start of stack frame
F3 - right redzone, it should be the end of stack frame.

But here we have the second set of F1s without F3s which should close the first set of F1s.
Also those two F3s in the middle cannot be right.

So shadow is corrupted.
Some hypotheses:

1) We share stack between several tasks (e.g. stack overflow, somehow corrupted SP).
    But this probably should cause kernel crash later, after kasan reports.

2) Shadow memory wasn't cleared. GCC poison memory on function entrance and unpoisons it before return.
     If we use some tricky way to exit from function this could cause false-positives like that.
     E.g. some hand-written assembly return code.

3) Screwed shadow mapping. I think the patch below should uncover such problem.
It boot-tested on qemu and didn't show any problem


---
 arch/arm64/mm/kasan_init.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index cf038c7..25d685c 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -117,6 +117,59 @@ static void __init cpu_set_ttbr1(unsigned long ttbr1)
 	: "r" (ttbr1));
 }
 
+static void verify_shadow(void)
+{
+	struct memblock_region *reg;
+	int i = 0;
+
+	for_each_memblock(memory, reg) {
+		void *start = (void *)__phys_to_virt(reg->base);
+		void *end = (void *)__phys_to_virt(reg->base + reg->size);
+		int *shadow_start, *shadow_end;
+
+		if (start >= end)
+			break;
+		shadow_start = (int *)((unsigned long)kasan_mem_to_shadow(start) & ~(PAGE_SIZE - 1));
+		shadow_end =  (int *)kasan_mem_to_shadow(end);
+		for (; shadow_start < shadow_end; shadow_start += PAGE_SIZE/sizeof(int)) {
+			*shadow_start = i;
+			i++;
+		}
+	}
+
+	i = 0;
+	for_each_memblock(memory, reg) {
+		void *start = (void *)__phys_to_virt(reg->base);
+		void *end = (void *)__phys_to_virt(reg->base + reg->size);
+		int *shadow_start, *shadow_end;
+
+		if (start >= end)
+			break;
+		shadow_start = (int *)((unsigned long)kasan_mem_to_shadow(start) & ~(PAGE_SIZE - 1));
+		shadow_end =  (int *)kasan_mem_to_shadow(end);
+		for (; shadow_start < shadow_end; shadow_start += PAGE_SIZE/sizeof(int)) {
+			if (*shadow_start != i) {
+				pr_err("screwed shadow mapping %d, %d\n", *shadow_start, i);
+				goto clear;
+			}
+			i++;
+		}
+	}
+clear:
+	for_each_memblock(memory, reg) {
+		void *start = (void *)__phys_to_virt(reg->base);
+		void *end = (void *)__phys_to_virt(reg->base + reg->size);
+		unsigned long shadow_start, shadow_end;
+
+		if (start >= end)
+			break;
+		shadow_start =  ((unsigned long)kasan_mem_to_shadow(start) & ~(PAGE_SIZE - 1));
+		shadow_end =  (unsigned long)kasan_mem_to_shadow(end);
+		memset((void *)shadow_start, 0, shadow_end - shadow_start);
+	}
+
+}
+
 void __init kasan_init(void)
 {
 	struct memblock_region *reg;
@@ -159,6 +212,8 @@ void __init kasan_init(void)
 	cpu_set_ttbr1(__pa(swapper_pg_dir));
 	flush_tlb_all();
 
+	verify_shadow();
+
 	/* At this point kasan is fully initialized. Enable error messages */
 	init_task.kasan_depth = 0;
 	pr_info("KernelAddressSanitizer initialized\n");
-- 







From vladimir.murzin at arm.com  Tue Feb 16 05:09:51 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 13:09:51 +0000
Subject: [PATCH v3 05/10] serial: mps2-uart: add support for early console
In-Reply-To: <CAHp75VdugAq0WnzLHmd9CJHCjBOdBwPqCmC3ARSaVF5XMYGoMw@mail.gmail.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>	<1455617295-23736-6-git-send-email-vladimir.murzin@arm.com>
 <CAHp75VdugAq0WnzLHmd9CJHCjBOdBwPqCmC3ARSaVF5XMYGoMw@mail.gmail.com>
Message-ID: <56C31F9F.10000@arm.com>

On 16/02/16 10:36, Andy Shevchenko wrote:
> On Tue, Feb 16, 2016 at 12:08 PM, Vladimir Murzin
> <vladimir.murzin at arm.com> wrote:
>> This adds support early console for MPS2 UART which can be enabled via
>> earlycon=mps2,0x40004000
> 
> 
>> --- a/drivers/tty/serial/mps2-uart.c
>> +++ b/drivers/tty/serial/mps2-uart.c
>> @@ -435,6 +435,36 @@ static struct console mps2_uart_console = {
>>
>>  #define MPS2_SERIAL_CONSOLE (&mps2_uart_console)
>>
>> +static void mps2_early_putchar(struct uart_port *port, int ch)
>> +{
>> +
>> +       while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
>> +               cpu_relax();
> 
> Infinite busy loop?

In case of broken hw, yes, but I'm quite unsure how we can help to fix
it. Do you have something in mind?

> 
>> +
>> +       writeb((unsigned char)ch, port->membase + UARTn_DATA);
>> +}
>> +
>> +
>> +static void mps2_early_write(struct console *con, const char *s, unsigned n)
>> +{
>> +       struct earlycon_device *dev = con->data;
>> +
>> +       uart_console_write(&dev->port, s, n, mps2_early_putchar);
>> +}
>> +
>> +static int __init mps2_early_console_setup(struct earlycon_device *device,
>> +                                          const char *opt)
>> +{
>> +       if (!device->port.membase)
>> +               return -ENODEV;
>> +
>> +       device->con->write = mps2_early_write;
>> +
>> +       return 0;
>> +}
>> +EARLYCON_DECLARE(mps2, mps2_early_console_setup);
>> +OF_EARLYCON_DECLARE(mps2, "arm,mps2-uart", mps2_early_console_setup);
> 
> IIRC Peter Hurley mentioned you don't need to put both anymore, OF_
> one is enough.
> 

I've just tried with OF_ only and seems it works fine. Thanks for
pointing at it!

Cheers
Vladimir




From gkulkarni at caviumnetworks.com  Tue Feb 16 05:11:22 2016
From: gkulkarni at caviumnetworks.com (Ganapatrao Kulkarni)
Date: Tue, 16 Feb 2016 18:41:22 +0530
Subject: [PATCH v3] irqchip, gicv3-its,
 numa: Workaround for Cavium thunderx erratum 23144
Message-ID: <1455628282-8939-1-git-send-email-gkulkarni@caviumnetworks.com>

The erratum fixes the hang of ITS SYNC command by avoiding inter node
io and collections/cpu mapping on thunderx dual-socket platform.

This is based on NUMA v10 series.
https://lkml.org/lkml/2016/2/2/134

v3:
updatated as per Marc Zyngier's review comments.
http://www.spinics.net/lists/arm-kernel/msg443462.html

v2:
updatated as per Marc Zyngier's review comments.

Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>

---
 arch/arm64/Kconfig               |  9 ++++++++
 drivers/irqchip/irq-gic-v3-its.c | 46 ++++++++++++++++++++++++++++++++++++++--
 2 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8a7c02a..c3ab043 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -434,6 +434,15 @@ config CAVIUM_ERRATUM_23154
 
 	  If unsure, say Y.
 
+config CAVIUM_ERRATUM_23144
+	bool "Cavium erratum 23144: ITS SYNC hang on dual socket system"
+	depends on NUMA
+	default y
+	help
+	  ITS SYNC command hang for cross node io and collections/cpu mapping.
+
+	  If unsure, say Y.
+
 endmenu
 
 
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index e23d1d1..8999e5e 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -41,6 +41,7 @@
 
 #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING		(1ULL << 0)
 #define ITS_FLAGS_WORKAROUND_CAVIUM_22375	(1ULL << 1)
+#define ITS_FLAGS_WORKAROUND_CAVIUM_23144	(1ULL << 2)
 
 #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING	(1 << 0)
 
@@ -71,6 +72,7 @@ struct its_node {
 	struct list_head	its_device_list;
 	u64			flags;
 	u32			ite_size;
+	int			numa_node;
 };
 
 #define ITS_ITT_ALIGN		SZ_256
@@ -605,11 +607,21 @@ static void its_eoi_irq(struct irq_data *d)
 static int its_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
 			    bool force)
 {
-	unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
+	unsigned int cpu;
+	const struct cpumask *cpu_mask = cpu_online_mask;
 	struct its_device *its_dev = irq_data_get_irq_chip_data(d);
 	struct its_collection *target_col;
 	u32 id = its_get_event_id(d);
 
+       /* lpi cannot be routed to a redistributor that is on a foreign node */
+	if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
+		cpu_mask = cpumask_of_node(its_dev->its->numa_node);
+		if (!cpumask_intersects(mask_val, cpu_mask))
+			return -EINVAL;
+	}
+
+	cpu = cpumask_any_and(mask_val, cpu_mask);
+
 	if (cpu >= nr_cpu_ids)
 		return -EINVAL;
 
@@ -1086,6 +1098,14 @@ static void its_cpu_init_collection(void)
 	list_for_each_entry(its, &its_nodes, entry) {
 		u64 target;
 
+		/* avoid cross node collections and its mapping */
+		if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
+			struct device_node *cpu_node;
+			cpu_node = of_get_cpu_node(cpu, NULL);
+			if (its->numa_node != of_node_to_nid(cpu_node))
+				continue;
+		}
+
 		/*
 		 * We now have to bind each collection to its target
 		 * redistributor.
@@ -1313,9 +1333,14 @@ static void its_irq_domain_activate(struct irq_domain *domain,
 {
 	struct its_device *its_dev = irq_data_get_irq_chip_data(d);
 	u32 event = its_get_event_id(d);
+	const struct cpumask *cpu_mask = cpu_online_mask;
+
+	/* get the cpu_mask of local node */
+	if (IS_ENABLED(CONFIG_NUMA))
+		cpu_mask = cpumask_of_node(its_dev->its->numa_node);
 
 	/* Bind the LPI to the first possible CPU */
-	its_dev->event_map.col_map[event] = cpumask_first(cpu_online_mask);
+	its_dev->event_map.col_map[event] = cpumask_first(cpu_mask);
 
 	/* Map the GIC IRQ and event to the device */
 	its_send_mapvi(its_dev, d->hwirq, event);
@@ -1405,6 +1430,13 @@ static void __maybe_unused its_enable_quirk_cavium_22375(void *data)
 	its->flags |= ITS_FLAGS_WORKAROUND_CAVIUM_22375;
 }
 
+static void __maybe_unused its_enable_quirk_cavium_23144(void *data)
+{
+	struct its_node *its = data;
+
+	its->flags |= ITS_FLAGS_WORKAROUND_CAVIUM_23144;
+}
+
 static const struct gic_quirk its_quirks[] = {
 #ifdef CONFIG_CAVIUM_ERRATUM_22375
 	{
@@ -1414,6 +1446,15 @@ static const struct gic_quirk its_quirks[] = {
 		.init	= its_enable_quirk_cavium_22375,
 	},
 #endif
+
+#ifdef CONFIG_CAVIUM_ERRATUM_23144
+	{
+		.desc	= "ITS: Cavium erratum 23144",
+		.iidr	= 0xa100034c,	/* ThunderX pass 1.x */
+		.mask	= 0xffff0fff,
+		.init	= its_enable_quirk_cavium_23144,
+	},
+#endif
 	{
 	}
 };
@@ -1475,6 +1516,7 @@ static int its_probe(struct device_node *node, struct irq_domain *parent)
 	its->base = its_base;
 	its->phys_base = res.start;
 	its->ite_size = ((readl_relaxed(its_base + GITS_TYPER) >> 4) & 0xf) + 1;
+	its->numa_node = of_node_to_nid(node);
 
 	its->cmd_base = kzalloc(ITS_CMD_QUEUE_SZ, GFP_KERNEL);
 	if (!its->cmd_base) {
-- 
1.8.1.4



From jszhang at marvell.com  Tue Feb 16 05:08:18 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 21:08:18 +0800
Subject: [PATCH v5 00/13] mmc: use sdhci_pltfm_init for private allocation and
 clean up
Message-ID: <1455628111-5583-1-git-send-email-jszhang@marvell.com>

These patches are to complete the TODOs in Commit 0e748234293f ("mmc:
sdhci: Add size for caller in init+register"), I.E:

- todo: migrate clients to using allocation this way
- todo: remove priv variable once migration is complete

Since v4:
 - based on Ulf's latest next branch
 - add Adrian's Ack for all patches, add Thierry's Ack and Test for patch 11
   add S?ren Ack for patch 5.

Since v3:
 - based on v4.5-rc1
 - add Ludovic's ack for sdhci-of-at91 changes
 - fix use-after-free in some drivers: some host drivers still needs to
   access sdhci_pltfm_host->private after sdhci_pltfm_unregister(), but
   the private should be already freed by sdhci_pltfm_unregister.
 - add patch5 to fix one clk bug in sdhci_arasan_remove(). IMHO, It's
   better to add this patch to fixes rather than waiting for next merge
   window

Since v2:
 - based on mmc next tree and remove all priv usage introduced in newly
   commits in this tree
 - don't break two lines if sdhci_pltfm_init() call could be put into
   one line. Thank Ludovic Desroches.

Since v1:
 - add new patch03 to factorise sdhci_msm_pdata outisde of sdhci_msm_host.
   This is to fix drivers/mmc/host/sdhci-msm.c:440:32: warning: 'msm_host'
   is used uninitialized in this function [-Wuninitialized]
 - Add Arnd's Ack for all patches except patch3 which is new in v2


Jisheng Zhang (13):
  mmc: sdhci-bcm2835: use sdhci_pltfm_init for private allocation
  mmc: sdhci-esdhc-imx: use sdhci_pltfm_init for private allocation
  mmc: sdhci-msm: factorise sdhci_msm_pdata outisde of sdhci_msm_host
  mmc: sdhci-msm: use sdhci_pltfm_init for private allocation
  mmc: sdhci-of-arasan: fix clk issue in sdhci_arasan_remove()
  mmc: sdhci-of-arasan: use sdhci_pltfm_init for private allocation
  mmc: sdhci-of-at91: use sdhci_pltfm_init for private allocation
  mmc: sdhci-of-esdhc: use sdhci_pltfm_init for private allocation
  mmc: sdhci-pxav3: use sdhci_pltfm_init for private allocation
  mmc: sdhci-st: use sdhci_pltfm_init for private allocation
  mmc: sdhci-tegra: use sdhci_pltfm_init for private allocation
  mmc: sdhci-pxav2: remove unnecessary assignment of pltfm_host->priv
  mmc: sdhci-pltfm: remove priv variable from sdhci_pltfm_host

 drivers/mmc/host/sdhci-bcm2835.c   | 14 +++----------
 drivers/mmc/host/sdhci-esdhc-imx.c | 38 ++++++++++++++++--------------------
 drivers/mmc/host/sdhci-msm.c       | 25 +++++++++++-------------
 drivers/mmc/host/sdhci-of-arasan.c | 33 +++++++++++++++----------------
 drivers/mmc/host/sdhci-of-at91.c   | 33 ++++++++++++++-----------------
 drivers/mmc/host/sdhci-of-esdhc.c  | 19 +++++++++---------
 drivers/mmc/host/sdhci-pltfm.h     |  1 -
 drivers/mmc/host/sdhci-pxav2.c     |  1 -
 drivers/mmc/host/sdhci-pxav3.c     | 20 ++++++++-----------
 drivers/mmc/host/sdhci-st.c        | 40 +++++++++++++++++++-------------------
 drivers/mmc/host/sdhci-tegra.c     | 21 +++++++-------------
 11 files changed, 106 insertions(+), 139 deletions(-)

-- 
2.7.0



From jszhang at marvell.com  Tue Feb 16 05:08:21 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 21:08:21 +0800
Subject: [PATCH v5 03/13] mmc: sdhci-msm: factorise sdhci_msm_pdata outisde of
 sdhci_msm_host
In-Reply-To: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
References: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
Message-ID: <1455628111-5583-4-git-send-email-jszhang@marvell.com>

There's no need to allocate one sdhci_msm_pdata for each sdhci_msm_host.
This patch removes the sdhci_msm_pdata member from sdhci_msm_host and
uses one static global sdhci_msm_pdata for all sdhci msm hosts. It also
marks sdhci_msm_ops as const.

Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
Acked-by: Adrian Hunter <adrian.hunter at intel.com>
---
 drivers/mmc/host/sdhci-msm.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 4695bee..ffac9b4 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -60,7 +60,6 @@ struct sdhci_msm_host {
 	struct clk *pclk;	/* SDHC peripheral bus clock */
 	struct clk *bus_clk;	/* SDHC bus voter clock */
 	struct mmc_host *mmc;
-	struct sdhci_pltfm_data sdhci_msm_pdata;
 };
 
 /* Platform specific tuning */
@@ -418,7 +417,7 @@ static const struct of_device_id sdhci_msm_dt_match[] = {
 
 MODULE_DEVICE_TABLE(of, sdhci_msm_dt_match);
 
-static struct sdhci_ops sdhci_msm_ops = {
+static const struct sdhci_ops sdhci_msm_ops = {
 	.platform_execute_tuning = sdhci_msm_execute_tuning,
 	.reset = sdhci_reset,
 	.set_clock = sdhci_set_clock,
@@ -426,6 +425,12 @@ static struct sdhci_ops sdhci_msm_ops = {
 	.set_uhs_signaling = sdhci_set_uhs_signaling,
 };
 
+static const struct sdhci_pltfm_data sdhci_msm_pdata = {
+	.quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
+		  SDHCI_QUIRK_SINGLE_POWER_WRITE,
+	.ops = &sdhci_msm_ops,
+};
+
 static int sdhci_msm_probe(struct platform_device *pdev)
 {
 	struct sdhci_host *host;
@@ -441,8 +446,7 @@ static int sdhci_msm_probe(struct platform_device *pdev)
 	if (!msm_host)
 		return -ENOMEM;
 
-	msm_host->sdhci_msm_pdata.ops = &sdhci_msm_ops;
-	host = sdhci_pltfm_init(pdev, &msm_host->sdhci_msm_pdata, 0);
+	host = sdhci_pltfm_init(pdev, &sdhci_msm_pdata, 0);
 	if (IS_ERR(host))
 		return PTR_ERR(host);
 
@@ -522,9 +526,6 @@ static int sdhci_msm_probe(struct platform_device *pdev)
 	/* Set HC_MODE_EN bit in HC_MODE register */
 	writel_relaxed(HC_MODE_EN, (msm_host->core_mem + CORE_HC_MODE));
 
-	host->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
-	host->quirks |= SDHCI_QUIRK_SINGLE_POWER_WRITE;
-
 	host_version = readw_relaxed((host->ioaddr + SDHCI_HOST_VERSION));
 	dev_dbg(&pdev->dev, "Host Version: 0x%x Vendor Version 0x%x\n",
 		host_version, ((host_version & SDHCI_VENDOR_VER_MASK) >>
-- 
2.7.0



From jszhang at marvell.com  Tue Feb 16 05:08:19 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 21:08:19 +0800
Subject: [PATCH v5 01/13] mmc: sdhci-bcm2835: use sdhci_pltfm_init for private
 allocation
In-Reply-To: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
References: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
Message-ID: <1455628111-5583-2-git-send-email-jszhang@marvell.com>

Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates sdhci-bcm2835
to this allocation.

Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Adrian Hunter <adrian.hunter at intel.com>
---
 drivers/mmc/host/sdhci-bcm2835.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c
index 1c65d46..4a6a1d1 100644
--- a/drivers/mmc/host/sdhci-bcm2835.c
+++ b/drivers/mmc/host/sdhci-bcm2835.c
@@ -74,7 +74,7 @@ static inline u32 bcm2835_sdhci_readl(struct sdhci_host *host, int reg)
 static void bcm2835_sdhci_writew(struct sdhci_host *host, u16 val, int reg)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct bcm2835_sdhci *bcm2835_host = pltfm_host->priv;
+	struct bcm2835_sdhci *bcm2835_host = sdhci_pltfm_priv(pltfm_host);
 	u32 oldval = (reg == SDHCI_COMMAND) ? bcm2835_host->shadow :
 		bcm2835_sdhci_readl(host, reg & ~3);
 	u32 word_num = (reg >> 1) & 1;
@@ -152,20 +152,12 @@ static int bcm2835_sdhci_probe(struct platform_device *pdev)
 	struct sdhci_pltfm_host *pltfm_host;
 	int ret;
 
-	host = sdhci_pltfm_init(pdev, &bcm2835_sdhci_pdata, 0);
+	host = sdhci_pltfm_init(pdev, &bcm2835_sdhci_pdata,
+				sizeof(*bcm2835_host));
 	if (IS_ERR(host))
 		return PTR_ERR(host);
 
-	bcm2835_host = devm_kzalloc(&pdev->dev, sizeof(*bcm2835_host),
-					GFP_KERNEL);
-	if (!bcm2835_host) {
-		dev_err(mmc_dev(host->mmc),
-			"failed to allocate bcm2835_sdhci\n");
-		return -ENOMEM;
-	}
-
 	pltfm_host = sdhci_priv(host);
-	pltfm_host->priv = bcm2835_host;
 
 	pltfm_host->clk = devm_clk_get(&pdev->dev, NULL);
 	if (IS_ERR(pltfm_host->clk)) {
-- 
2.7.0



From jszhang at marvell.com  Tue Feb 16 05:08:27 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 21:08:27 +0800
Subject: [PATCH v5 09/13] mmc: sdhci-pxav3: use sdhci_pltfm_init for private
 allocation
In-Reply-To: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
References: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
Message-ID: <1455628111-5583-10-git-send-email-jszhang@marvell.com>

Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates sdhci-pxav3
to this allocation.

Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Adrian Hunter <adrian.hunter at intel.com>
---
 drivers/mmc/host/sdhci-pxav3.c | 20 ++++++++------------
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index f5edf9d..c88d2ba 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -132,7 +132,7 @@ static int armada_38x_quirks(struct platform_device *pdev,
 {
 	struct device_node *np = pdev->dev.of_node;
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_pxa *pxa = pltfm_host->priv;
+	struct sdhci_pxa *pxa = sdhci_pltfm_priv(pltfm_host);
 	struct resource *res;
 
 	host->quirks &= ~SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN;
@@ -201,7 +201,7 @@ static void pxav3_reset(struct sdhci_host *host, u8 mask)
 static void pxav3_gen_init_74_clocks(struct sdhci_host *host, u8 power_mode)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_pxa *pxa = pltfm_host->priv;
+	struct sdhci_pxa *pxa = sdhci_pltfm_priv(pltfm_host);
 	u16 tmp;
 	int count;
 
@@ -250,7 +250,7 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host *host, u8 power_mode)
 static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_pxa *pxa = pltfm_host->priv;
+	struct sdhci_pxa *pxa = sdhci_pltfm_priv(pltfm_host);
 	u16 ctrl_2;
 
 	/*
@@ -370,16 +370,12 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
 	const struct of_device_id *match;
 	int ret;
 
-	pxa = devm_kzalloc(&pdev->dev, sizeof(struct sdhci_pxa), GFP_KERNEL);
-	if (!pxa)
-		return -ENOMEM;
-
-	host = sdhci_pltfm_init(pdev, &sdhci_pxav3_pdata, 0);
+	host = sdhci_pltfm_init(pdev, &sdhci_pxav3_pdata, sizeof(*pxa));
 	if (IS_ERR(host))
 		return PTR_ERR(host);
 
 	pltfm_host = sdhci_priv(host);
-	pltfm_host->priv = pxa;
+	pxa = sdhci_pltfm_priv(pltfm_host);
 
 	pxa->clk_io = devm_clk_get(dev, "io");
 	if (IS_ERR(pxa->clk_io))
@@ -486,7 +482,7 @@ static int sdhci_pxav3_remove(struct platform_device *pdev)
 {
 	struct sdhci_host *host = platform_get_drvdata(pdev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_pxa *pxa = pltfm_host->priv;
+	struct sdhci_pxa *pxa = sdhci_pltfm_priv(pltfm_host);
 
 	pm_runtime_get_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
@@ -535,7 +531,7 @@ static int sdhci_pxav3_runtime_suspend(struct device *dev)
 {
 	struct sdhci_host *host = dev_get_drvdata(dev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_pxa *pxa = pltfm_host->priv;
+	struct sdhci_pxa *pxa = sdhci_pltfm_priv(pltfm_host);
 	int ret;
 
 	ret = sdhci_runtime_suspend_host(host);
@@ -553,7 +549,7 @@ static int sdhci_pxav3_runtime_resume(struct device *dev)
 {
 	struct sdhci_host *host = dev_get_drvdata(dev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_pxa *pxa = pltfm_host->priv;
+	struct sdhci_pxa *pxa = sdhci_pltfm_priv(pltfm_host);
 
 	clk_prepare_enable(pxa->clk_io);
 	if (!IS_ERR(pxa->clk_core))
-- 
2.7.0



From jszhang at marvell.com  Tue Feb 16 05:08:22 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 21:08:22 +0800
Subject: [PATCH v5 04/13] mmc: sdhci-msm: use sdhci_pltfm_init for private
 allocation
In-Reply-To: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
References: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
Message-ID: <1455628111-5583-5-git-send-email-jszhang@marvell.com>

Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates sdhci-msm
to this allocation.

Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Adrian Hunter <adrian.hunter at intel.com>
---
 drivers/mmc/host/sdhci-msm.c | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index ffac9b4..0653fe7 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -442,16 +442,12 @@ static int sdhci_msm_probe(struct platform_device *pdev)
 	u32 core_version, caps;
 	u8 core_major;
 
-	msm_host = devm_kzalloc(&pdev->dev, sizeof(*msm_host), GFP_KERNEL);
-	if (!msm_host)
-		return -ENOMEM;
-
-	host = sdhci_pltfm_init(pdev, &sdhci_msm_pdata, 0);
+	host = sdhci_pltfm_init(pdev, &sdhci_msm_pdata, sizeof(*msm_host));
 	if (IS_ERR(host))
 		return PTR_ERR(host);
 
 	pltfm_host = sdhci_priv(host);
-	pltfm_host->priv = msm_host;
+	msm_host = sdhci_pltfm_priv(pltfm_host);
 	msm_host->mmc = host->mmc;
 	msm_host->pdev = pdev;
 
@@ -571,16 +567,16 @@ static int sdhci_msm_remove(struct platform_device *pdev)
 {
 	struct sdhci_host *host = platform_get_drvdata(pdev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_msm_host *msm_host = pltfm_host->priv;
+	struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
 	int dead = (readl_relaxed(host->ioaddr + SDHCI_INT_STATUS) ==
 		    0xffffffff);
 
 	sdhci_remove_host(host, dead);
-	sdhci_pltfm_free(pdev);
 	clk_disable_unprepare(msm_host->clk);
 	clk_disable_unprepare(msm_host->pclk);
 	if (!IS_ERR(msm_host->bus_clk))
 		clk_disable_unprepare(msm_host->bus_clk);
+	sdhci_pltfm_free(pdev);
 	return 0;
 }
 
-- 
2.7.0



From jszhang at marvell.com  Tue Feb 16 05:08:20 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 21:08:20 +0800
Subject: [PATCH v5 02/13] mmc: sdhci-esdhc-imx: use sdhci_pltfm_init for
 private allocation
In-Reply-To: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
References: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
Message-ID: <1455628111-5583-3-git-send-email-jszhang@marvell.com>

Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates the sdhci
esdhc-imx driver to this allocation.

Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Adrian Hunter <adrian.hunter at intel.com>
---
 drivers/mmc/host/sdhci-esdhc-imx.c | 38 +++++++++++++++++---------------------
 1 file changed, 17 insertions(+), 21 deletions(-)

diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index f25f292..2d300d8 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -260,7 +260,7 @@ static inline void esdhc_clrset_le(struct sdhci_host *host, u32 mask, u32 val, i
 static u32 esdhc_readl_le(struct sdhci_host *host, int reg)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct pltfm_imx_data *imx_data = pltfm_host->priv;
+	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
 	u32 val = readl(host->ioaddr + reg);
 
 	if (unlikely(reg == SDHCI_PRESENT_STATE)) {
@@ -338,7 +338,7 @@ static u32 esdhc_readl_le(struct sdhci_host *host, int reg)
 static void esdhc_writel_le(struct sdhci_host *host, u32 val, int reg)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct pltfm_imx_data *imx_data = pltfm_host->priv;
+	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
 	u32 data;
 
 	if (unlikely(reg == SDHCI_INT_ENABLE || reg == SDHCI_SIGNAL_ENABLE)) {
@@ -388,7 +388,7 @@ static void esdhc_writel_le(struct sdhci_host *host, u32 val, int reg)
 static u16 esdhc_readw_le(struct sdhci_host *host, int reg)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct pltfm_imx_data *imx_data = pltfm_host->priv;
+	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
 	u16 ret = 0;
 	u32 val;
 
@@ -448,7 +448,7 @@ static u16 esdhc_readw_le(struct sdhci_host *host, int reg)
 static void esdhc_writew_le(struct sdhci_host *host, u16 val, int reg)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct pltfm_imx_data *imx_data = pltfm_host->priv;
+	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
 	u32 new_val = 0;
 
 	switch (reg) {
@@ -556,7 +556,7 @@ static void esdhc_writew_le(struct sdhci_host *host, u16 val, int reg)
 static void esdhc_writeb_le(struct sdhci_host *host, u8 val, int reg)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct pltfm_imx_data *imx_data = pltfm_host->priv;
+	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
 	u32 new_val;
 	u32 mask;
 
@@ -633,7 +633,7 @@ static inline void esdhc_pltfm_set_clock(struct sdhci_host *host,
 					 unsigned int clock)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct pltfm_imx_data *imx_data = pltfm_host->priv;
+	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
 	unsigned int host_clock = pltfm_host->clock;
 	int pre_div = 2;
 	int div = 1;
@@ -692,7 +692,7 @@ static inline void esdhc_pltfm_set_clock(struct sdhci_host *host,
 static unsigned int esdhc_pltfm_get_ro(struct sdhci_host *host)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct pltfm_imx_data *imx_data = pltfm_host->priv;
+	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
 	struct esdhc_platform_data *boarddata = &imx_data->boarddata;
 
 	switch (boarddata->wp_type) {
@@ -794,7 +794,7 @@ static int esdhc_change_pinstate(struct sdhci_host *host,
 						unsigned int uhs)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct pltfm_imx_data *imx_data = pltfm_host->priv;
+	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
 	struct pinctrl_state *pinctrl;
 
 	dev_dbg(mmc_dev(host->mmc), "change pinctrl state for uhs %d\n", uhs);
@@ -864,7 +864,7 @@ static void esdhc_set_uhs_signaling(struct sdhci_host *host, unsigned timing)
 {
 	u32 m;
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct pltfm_imx_data *imx_data = pltfm_host->priv;
+	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
 	struct esdhc_platform_data *boarddata = &imx_data->boarddata;
 
 	/* disable ddr mode and disable HS400 mode */
@@ -917,7 +917,7 @@ static void esdhc_reset(struct sdhci_host *host, u8 mask)
 static unsigned int esdhc_get_max_timeout_count(struct sdhci_host *host)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct pltfm_imx_data *imx_data = pltfm_host->priv;
+	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
 
 	return esdhc_is_usdhc(imx_data) ? 1 << 28 : 1 << 27;
 }
@@ -925,7 +925,7 @@ static unsigned int esdhc_get_max_timeout_count(struct sdhci_host *host)
 static void esdhc_set_timeout(struct sdhci_host *host, struct mmc_command *cmd)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct pltfm_imx_data *imx_data = pltfm_host->priv;
+	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
 
 	/* use maximum timeout counter */
 	sdhci_writeb(host, esdhc_is_usdhc(imx_data) ? 0xF : 0xE,
@@ -1100,21 +1100,17 @@ static int sdhci_esdhc_imx_probe(struct platform_device *pdev)
 	int err;
 	struct pltfm_imx_data *imx_data;
 
-	host = sdhci_pltfm_init(pdev, &sdhci_esdhc_imx_pdata, 0);
+	host = sdhci_pltfm_init(pdev, &sdhci_esdhc_imx_pdata,
+				sizeof(*imx_data));
 	if (IS_ERR(host))
 		return PTR_ERR(host);
 
 	pltfm_host = sdhci_priv(host);
 
-	imx_data = devm_kzalloc(&pdev->dev, sizeof(*imx_data), GFP_KERNEL);
-	if (!imx_data) {
-		err = -ENOMEM;
-		goto free_sdhci;
-	}
+	imx_data = sdhci_pltfm_priv(pltfm_host);
 
 	imx_data->socdata = of_id ? of_id->data : (struct esdhc_soc_data *)
 						  pdev->id_entry->driver_data;
-	pltfm_host->priv = imx_data;
 
 	imx_data->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
 	if (IS_ERR(imx_data->clk_ipg)) {
@@ -1241,7 +1237,7 @@ static int sdhci_esdhc_imx_remove(struct platform_device *pdev)
 {
 	struct sdhci_host *host = platform_get_drvdata(pdev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct pltfm_imx_data *imx_data = pltfm_host->priv;
+	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
 	int dead = (readl(host->ioaddr + SDHCI_INT_STATUS) == 0xffffffff);
 
 	pm_runtime_get_sync(&pdev->dev);
@@ -1264,7 +1260,7 @@ static int sdhci_esdhc_runtime_suspend(struct device *dev)
 {
 	struct sdhci_host *host = dev_get_drvdata(dev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct pltfm_imx_data *imx_data = pltfm_host->priv;
+	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
 	int ret;
 
 	ret = sdhci_runtime_suspend_host(host);
@@ -1282,7 +1278,7 @@ static int sdhci_esdhc_runtime_resume(struct device *dev)
 {
 	struct sdhci_host *host = dev_get_drvdata(dev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct pltfm_imx_data *imx_data = pltfm_host->priv;
+	struct pltfm_imx_data *imx_data = sdhci_pltfm_priv(pltfm_host);
 
 	if (!sdhci_sdio_irq_enabled(host)) {
 		clk_prepare_enable(imx_data->clk_per);
-- 
2.7.0



From jszhang at marvell.com  Tue Feb 16 05:08:24 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 21:08:24 +0800
Subject: [PATCH v5 06/13] mmc: sdhci-of-arasan: use sdhci_pltfm_init for
 private allocation
In-Reply-To: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
References: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
Message-ID: <1455628111-5583-7-git-send-email-jszhang@marvell.com>

Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates the
sdhci-of-arasan driver to this allocation.

Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Adrian Hunter <adrian.hunter at intel.com>
---
 drivers/mmc/host/sdhci-of-arasan.c | 28 ++++++++++++----------------
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index 8b4f8f7..1e4b5e0 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -81,7 +81,7 @@ static int sdhci_arasan_suspend(struct device *dev)
 	struct platform_device *pdev = to_platform_device(dev);
 	struct sdhci_host *host = platform_get_drvdata(pdev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_arasan_data *sdhci_arasan = pltfm_host->priv;
+	struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
 	int ret;
 
 	ret = sdhci_suspend_host(host);
@@ -106,7 +106,7 @@ static int sdhci_arasan_resume(struct device *dev)
 	struct platform_device *pdev = to_platform_device(dev);
 	struct sdhci_host *host = platform_get_drvdata(pdev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_arasan_data *sdhci_arasan = pltfm_host->priv;
+	struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
 	int ret;
 
 	ret = clk_enable(sdhci_arasan->clk_ahb);
@@ -137,10 +137,13 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
 	struct sdhci_pltfm_host *pltfm_host;
 	struct sdhci_arasan_data *sdhci_arasan;
 
-	sdhci_arasan = devm_kzalloc(&pdev->dev, sizeof(*sdhci_arasan),
-			GFP_KERNEL);
-	if (!sdhci_arasan)
-		return -ENOMEM;
+	host = sdhci_pltfm_init(pdev, &sdhci_arasan_pdata,
+				sizeof(*sdhci_arasan));
+	if (IS_ERR(host))
+		return PTR_ERR(host);
+
+	pltfm_host = sdhci_priv(host);
+	sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
 
 	sdhci_arasan->clk_ahb = devm_clk_get(&pdev->dev, "clk_ahb");
 	if (IS_ERR(sdhci_arasan->clk_ahb)) {
@@ -166,15 +169,7 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
 		goto clk_dis_ahb;
 	}
 
-	host = sdhci_pltfm_init(pdev, &sdhci_arasan_pdata, 0);
-	if (IS_ERR(host)) {
-		ret = PTR_ERR(host);
-		goto clk_disable_all;
-	}
-
 	sdhci_get_of_property(pdev);
-	pltfm_host = sdhci_priv(host);
-	pltfm_host->priv = sdhci_arasan;
 	pltfm_host->clk = clk_xin;
 
 	ret = mmc_of_parse(host->mmc);
@@ -204,11 +199,12 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
 	int ret;
 	struct sdhci_host *host = platform_get_drvdata(pdev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_arasan_data *sdhci_arasan = pltfm_host->priv;
+	struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
+	struct clk *clk_ahb = sdhci_arasan->clk_ahb;
 
 	ret = sdhci_pltfm_unregister(pdev);
 
-	clk_disable_unprepare(sdhci_arasan->clk_ahb);
+	clk_disable_unprepare(clk_ahb);
 
 	return ret;
 }
-- 
2.7.0



From jszhang at marvell.com  Tue Feb 16 05:08:23 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 21:08:23 +0800
Subject: [PATCH v5 05/13] mmc: sdhci-of-arasan: fix clk issue in
 sdhci_arasan_remove()
In-Reply-To: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
References: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
Message-ID: <1455628111-5583-6-git-send-email-jszhang@marvell.com>

sdhci_pltfm_unregister() could operate host's registers, it will cause
problems if the clk is already disabled and unprepared. Fix this issue
by moving the clk_disable_unprepare() call to the end of remove
function.

Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
Acked-by: S?ren Brinkmann <soren.brinkmann at xilinx.com>
Acked-by: Adrian Hunter <adrian.hunter at intel.com>
---
 drivers/mmc/host/sdhci-of-arasan.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index 5d9fdb3..8b4f8f7 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -201,13 +201,16 @@ clk_dis_ahb:
 
 static int sdhci_arasan_remove(struct platform_device *pdev)
 {
+	int ret;
 	struct sdhci_host *host = platform_get_drvdata(pdev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
 	struct sdhci_arasan_data *sdhci_arasan = pltfm_host->priv;
 
+	ret = sdhci_pltfm_unregister(pdev);
+
 	clk_disable_unprepare(sdhci_arasan->clk_ahb);
 
-	return sdhci_pltfm_unregister(pdev);
+	return ret;
 }
 
 static const struct of_device_id sdhci_arasan_of_match[] = {
-- 
2.7.0



From jszhang at marvell.com  Tue Feb 16 05:08:26 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 21:08:26 +0800
Subject: [PATCH v5 08/13] mmc: sdhci-of-esdhc: use sdhci_pltfm_init for
 private allocation
In-Reply-To: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
References: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
Message-ID: <1455628111-5583-9-git-send-email-jszhang@marvell.com>

Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates the
sdhci-of-esdhc driver to this allocation.

Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Adrian Hunter <adrian.hunter at intel.com>
---
 drivers/mmc/host/sdhci-of-esdhc.c | 19 +++++++++----------
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 83b1226..3f34d35 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -49,7 +49,7 @@ static u32 esdhc_readl_fixup(struct sdhci_host *host,
 				     int spec_reg, u32 value)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_esdhc *esdhc = pltfm_host->priv;
+	struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
 	u32 ret;
 
 	/*
@@ -354,7 +354,7 @@ static void esdhc_le_writeb(struct sdhci_host *host, u8 val, int reg)
 static void esdhc_of_adma_workaround(struct sdhci_host *host, u32 intmask)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_esdhc *esdhc = pltfm_host->priv;
+	struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
 	bool applicable;
 	dma_addr_t dmastart;
 	dma_addr_t dmanow;
@@ -404,7 +404,7 @@ static unsigned int esdhc_of_get_min_clock(struct sdhci_host *host)
 static void esdhc_of_set_clock(struct sdhci_host *host, unsigned int clock)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_esdhc *esdhc = pltfm_host->priv;
+	struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
 	int pre_div = 1;
 	int div = 1;
 	u32 temp;
@@ -569,15 +569,12 @@ static void esdhc_init(struct platform_device *pdev, struct sdhci_host *host)
 	u16 host_ver;
 
 	pltfm_host = sdhci_priv(host);
-	esdhc = devm_kzalloc(&pdev->dev, sizeof(struct sdhci_esdhc),
-			     GFP_KERNEL);
+	esdhc = sdhci_pltfm_priv(pltfm_host);
 
 	host_ver = sdhci_readw(host, SDHCI_HOST_VERSION);
 	esdhc->vendor_ver = (host_ver & SDHCI_VENDOR_VER_MASK) >>
 			     SDHCI_VENDOR_VER_SHIFT;
 	esdhc->spec_ver = host_ver & SDHCI_SPEC_VER_MASK;
-
-	pltfm_host->priv = esdhc;
 }
 
 static int sdhci_esdhc_probe(struct platform_device *pdev)
@@ -591,9 +588,11 @@ static int sdhci_esdhc_probe(struct platform_device *pdev)
 	np = pdev->dev.of_node;
 
 	if (of_get_property(np, "little-endian", NULL))
-		host = sdhci_pltfm_init(pdev, &sdhci_esdhc_le_pdata, 0);
+		host = sdhci_pltfm_init(pdev, &sdhci_esdhc_le_pdata,
+					sizeof(struct sdhci_esdhc));
 	else
-		host = sdhci_pltfm_init(pdev, &sdhci_esdhc_be_pdata, 0);
+		host = sdhci_pltfm_init(pdev, &sdhci_esdhc_be_pdata,
+					sizeof(struct sdhci_esdhc));
 
 	if (IS_ERR(host))
 		return PTR_ERR(host);
@@ -603,7 +602,7 @@ static int sdhci_esdhc_probe(struct platform_device *pdev)
 	sdhci_get_of_property(pdev);
 
 	pltfm_host = sdhci_priv(host);
-	esdhc = pltfm_host->priv;
+	esdhc = sdhci_pltfm_priv(pltfm_host);
 	if (esdhc->vendor_ver == VENDOR_V_22)
 		host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
 
-- 
2.7.0



From jszhang at marvell.com  Tue Feb 16 05:08:25 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 21:08:25 +0800
Subject: [PATCH v5 07/13] mmc: sdhci-of-at91: use sdhci_pltfm_init for private
 allocation
In-Reply-To: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
References: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
Message-ID: <1455628111-5583-8-git-send-email-jszhang@marvell.com>

Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates the
sdhci-of-at91 driver to this allocation.

Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Ludovic Desroches <ludovic.desroches at atmel.com>
Acked-by: Adrian Hunter <adrian.hunter at intel.com>
---
 drivers/mmc/host/sdhci-of-at91.c | 33 +++++++++++++++------------------
 1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-at91.c b/drivers/mmc/host/sdhci-of-at91.c
index 9cb86fb..35c02fc 100644
--- a/drivers/mmc/host/sdhci-of-at91.c
+++ b/drivers/mmc/host/sdhci-of-at91.c
@@ -58,7 +58,7 @@ static int sdhci_at91_runtime_suspend(struct device *dev)
 {
 	struct sdhci_host *host = dev_get_drvdata(dev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_at91_priv *priv = pltfm_host->priv;
+	struct sdhci_at91_priv *priv = sdhci_pltfm_priv(pltfm_host);
 	int ret;
 
 	ret = sdhci_runtime_suspend_host(host);
@@ -74,7 +74,7 @@ static int sdhci_at91_runtime_resume(struct device *dev)
 {
 	struct sdhci_host *host = dev_get_drvdata(dev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_at91_priv *priv = pltfm_host->priv;
+	struct sdhci_at91_priv *priv = sdhci_pltfm_priv(pltfm_host);
 	int ret;
 
 	ret = clk_prepare_enable(priv->mainck);
@@ -124,11 +124,12 @@ static int sdhci_at91_probe(struct platform_device *pdev)
 		return -EINVAL;
 	soc_data = match->data;
 
-	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
-	if (!priv) {
-		dev_err(&pdev->dev, "unable to allocate private data\n");
-		return -ENOMEM;
-	}
+	host = sdhci_pltfm_init(pdev, soc_data, sizeof(*priv));
+	if (IS_ERR(host))
+		return PTR_ERR(host);
+
+	pltfm_host = sdhci_priv(host);
+	priv = sdhci_pltfm_priv(pltfm_host);
 
 	priv->mainck = devm_clk_get(&pdev->dev, "baseclk");
 	if (IS_ERR(priv->mainck)) {
@@ -148,10 +149,6 @@ static int sdhci_at91_probe(struct platform_device *pdev)
 		return PTR_ERR(priv->gck);
 	}
 
-	host = sdhci_pltfm_init(pdev, soc_data, 0);
-	if (IS_ERR(host))
-		return PTR_ERR(host);
-
 	/*
 	 * The mult clock is provided by as a generated clock by the PMC
 	 * controller. In order to set the rate of gck, we have to get the
@@ -191,9 +188,6 @@ static int sdhci_at91_probe(struct platform_device *pdev)
 	clk_prepare_enable(priv->mainck);
 	clk_prepare_enable(priv->gck);
 
-	pltfm_host = sdhci_priv(host);
-	pltfm_host->priv = priv;
-
 	ret = mmc_of_parse(host->mmc);
 	if (ret)
 		goto clocks_disable_unprepare;
@@ -231,7 +225,10 @@ static int sdhci_at91_remove(struct platform_device *pdev)
 {
 	struct sdhci_host	*host = platform_get_drvdata(pdev);
 	struct sdhci_pltfm_host	*pltfm_host = sdhci_priv(host);
-	struct sdhci_at91_priv	*priv = pltfm_host->priv;
+	struct sdhci_at91_priv	*priv = sdhci_pltfm_priv(pltfm_host);
+	struct clk *gck = priv->gck;
+	struct clk *hclock = priv->hclock;
+	struct clk *mainck = priv->mainck;
 
 	pm_runtime_get_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
@@ -239,9 +236,9 @@ static int sdhci_at91_remove(struct platform_device *pdev)
 
 	sdhci_pltfm_unregister(pdev);
 
-	clk_disable_unprepare(priv->gck);
-	clk_disable_unprepare(priv->hclock);
-	clk_disable_unprepare(priv->mainck);
+	clk_disable_unprepare(gck);
+	clk_disable_unprepare(hclock);
+	clk_disable_unprepare(mainck);
 
 	return 0;
 }
-- 
2.7.0



From jszhang at marvell.com  Tue Feb 16 05:08:28 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 21:08:28 +0800
Subject: [PATCH v5 10/13] mmc: sdhci-st: use sdhci_pltfm_init for private
 allocation
In-Reply-To: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
References: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
Message-ID: <1455628111-5583-11-git-send-email-jszhang@marvell.com>

Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates sdhci-st
to this allocation.

Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Adrian Hunter <adrian.hunter at intel.com>
---
 drivers/mmc/host/sdhci-st.c | 40 ++++++++++++++++++++--------------------
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/mmc/host/sdhci-st.c b/drivers/mmc/host/sdhci-st.c
index 969c2b0..320e1c2 100644
--- a/drivers/mmc/host/sdhci-st.c
+++ b/drivers/mmc/host/sdhci-st.c
@@ -251,7 +251,7 @@ static int sdhci_st_set_dll_for_clock(struct sdhci_host *host)
 {
 	int ret = 0;
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct st_mmc_platform_data *pdata = pltfm_host->priv;
+	struct st_mmc_platform_data *pdata = sdhci_pltfm_priv(pltfm_host);
 
 	if (host->clock > CLK_TO_CHECK_DLL_LOCK) {
 		st_mmcss_set_dll(pdata->top_ioaddr);
@@ -265,7 +265,7 @@ static void sdhci_st_set_uhs_signaling(struct sdhci_host *host,
 					unsigned int uhs)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct st_mmc_platform_data *pdata = pltfm_host->priv;
+	struct st_mmc_platform_data *pdata = sdhci_pltfm_priv(pltfm_host);
 	u16 ctrl_2 = sdhci_readw(host, SDHCI_HOST_CONTROL2);
 	int ret = 0;
 
@@ -357,10 +357,7 @@ static int sdhci_st_probe(struct platform_device *pdev)
 	int ret = 0;
 	u16 host_version;
 	struct resource *res;
-
-	pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
-	if (!pdata)
-		return -ENOMEM;
+	struct reset_control *rstc;
 
 	clk =  devm_clk_get(&pdev->dev, "mmc");
 	if (IS_ERR(clk)) {
@@ -368,19 +365,23 @@ static int sdhci_st_probe(struct platform_device *pdev)
 		return PTR_ERR(clk);
 	}
 
-	pdata->rstc = devm_reset_control_get(&pdev->dev, NULL);
-	if (IS_ERR(pdata->rstc))
-		pdata->rstc = NULL;
+	rstc = devm_reset_control_get(&pdev->dev, NULL);
+	if (IS_ERR(rstc))
+		rstc = NULL;
 	else
-		reset_control_deassert(pdata->rstc);
+		reset_control_deassert(rstc);
 
-	host = sdhci_pltfm_init(pdev, &sdhci_st_pdata, 0);
+	host = sdhci_pltfm_init(pdev, &sdhci_st_pdata, sizeof(*pdata));
 	if (IS_ERR(host)) {
 		dev_err(&pdev->dev, "Failed sdhci_pltfm_init\n");
 		ret = PTR_ERR(host);
 		goto err_pltfm_init;
 	}
 
+	pltfm_host = sdhci_priv(host);
+	pdata = sdhci_pltfm_priv(pltfm_host);
+	pdata->rstc = rstc;
+
 	ret = mmc_of_parse(host->mmc);
 	if (ret) {
 		dev_err(&pdev->dev, "Failed mmc_of_parse\n");
@@ -398,8 +399,6 @@ static int sdhci_st_probe(struct platform_device *pdev)
 		pdata->top_ioaddr = NULL;
 	}
 
-	pltfm_host = sdhci_priv(host);
-	pltfm_host->priv = pdata;
 	pltfm_host->clk = clk;
 
 	/* Configure the Arasan HC inside the flashSS */
@@ -427,8 +426,8 @@ err_out:
 err_of:
 	sdhci_pltfm_free(pdev);
 err_pltfm_init:
-	if (pdata->rstc)
-		reset_control_assert(pdata->rstc);
+	if (rstc)
+		reset_control_assert(rstc);
 
 	return ret;
 }
@@ -437,13 +436,14 @@ static int sdhci_st_remove(struct platform_device *pdev)
 {
 	struct sdhci_host *host = platform_get_drvdata(pdev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct st_mmc_platform_data *pdata = pltfm_host->priv;
+	struct st_mmc_platform_data *pdata = sdhci_pltfm_priv(pltfm_host);
+	struct reset_control *rstc = pdata->rstc;
 	int ret;
 
 	ret = sdhci_pltfm_unregister(pdev);
 
-	if (pdata->rstc)
-		reset_control_assert(pdata->rstc);
+	if (rstc)
+		reset_control_assert(rstc);
 
 	return ret;
 }
@@ -453,7 +453,7 @@ static int sdhci_st_suspend(struct device *dev)
 {
 	struct sdhci_host *host = dev_get_drvdata(dev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct st_mmc_platform_data *pdata = pltfm_host->priv;
+	struct st_mmc_platform_data *pdata = sdhci_pltfm_priv(pltfm_host);
 	int ret = sdhci_suspend_host(host);
 
 	if (ret)
@@ -471,7 +471,7 @@ static int sdhci_st_resume(struct device *dev)
 {
 	struct sdhci_host *host = dev_get_drvdata(dev);
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct st_mmc_platform_data *pdata = pltfm_host->priv;
+	struct st_mmc_platform_data *pdata = sdhci_pltfm_priv(pltfm_host);
 	struct device_node *np = dev->of_node;
 
 	clk_prepare_enable(pltfm_host->clk);
-- 
2.7.0



From jszhang at marvell.com  Tue Feb 16 05:08:29 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 21:08:29 +0800
Subject: [PATCH v5 11/13] mmc: sdhci-tegra: use sdhci_pltfm_init for private
 allocation
In-Reply-To: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
References: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
Message-ID: <1455628111-5583-12-git-send-email-jszhang@marvell.com>

Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates sdhci-tegra
to this allocation.

Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Tested-by: Thierry Reding <treding at nvidia.com>
Acked-by: Thierry Reding <treding at nvidia.com>
Acked-by: Adrian Hunter <adrian.hunter at intel.com>
---
 drivers/mmc/host/sdhci-tegra.c | 21 +++++++--------------
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 83c4bf7..2c3c57b 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -63,7 +63,7 @@ struct sdhci_tegra {
 static u16 tegra_sdhci_readw(struct sdhci_host *host, int reg)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_tegra *tegra_host = pltfm_host->priv;
+	struct sdhci_tegra *tegra_host = sdhci_pltfm_priv(pltfm_host);
 	const struct sdhci_tegra_soc_data *soc_data = tegra_host->soc_data;
 
 	if (unlikely((soc_data->nvquirks & NVQUIRK_FORCE_SDHCI_SPEC_200) &&
@@ -99,7 +99,7 @@ static void tegra_sdhci_writew(struct sdhci_host *host, u16 val, int reg)
 static void tegra_sdhci_writel(struct sdhci_host *host, u32 val, int reg)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_tegra *tegra_host = pltfm_host->priv;
+	struct sdhci_tegra *tegra_host = sdhci_pltfm_priv(pltfm_host);
 	const struct sdhci_tegra_soc_data *soc_data = tegra_host->soc_data;
 
 	/* Seems like we're getting spurious timeout and crc errors, so
@@ -131,7 +131,7 @@ static unsigned int tegra_sdhci_get_ro(struct sdhci_host *host)
 static void tegra_sdhci_reset(struct sdhci_host *host, u8 mask)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_tegra *tegra_host = pltfm_host->priv;
+	struct sdhci_tegra *tegra_host = sdhci_pltfm_priv(pltfm_host);
 	const struct sdhci_tegra_soc_data *soc_data = tegra_host->soc_data;
 	u32 misc_ctrl, clk_ctrl;
 
@@ -184,7 +184,7 @@ static void tegra_sdhci_set_bus_width(struct sdhci_host *host, int bus_width)
 static void tegra_sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_tegra *tegra_host = pltfm_host->priv;
+	struct sdhci_tegra *tegra_host = sdhci_pltfm_priv(pltfm_host);
 	unsigned long host_clk;
 
 	if (!clock)
@@ -201,7 +201,7 @@ static void tegra_sdhci_set_uhs_signaling(struct sdhci_host *host,
 					  unsigned timing)
 {
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-	struct sdhci_tegra *tegra_host = pltfm_host->priv;
+	struct sdhci_tegra *tegra_host = sdhci_pltfm_priv(pltfm_host);
 
 	if (timing == MMC_TIMING_UHS_DDR50)
 		tegra_host->ddr_signaling = true;
@@ -380,20 +380,14 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
 		return -EINVAL;
 	soc_data = match->data;
 
-	host = sdhci_pltfm_init(pdev, soc_data->pdata, 0);
+	host = sdhci_pltfm_init(pdev, soc_data->pdata, sizeof(*tegra_host));
 	if (IS_ERR(host))
 		return PTR_ERR(host);
 	pltfm_host = sdhci_priv(host);
 
-	tegra_host = devm_kzalloc(&pdev->dev, sizeof(*tegra_host), GFP_KERNEL);
-	if (!tegra_host) {
-		dev_err(mmc_dev(host->mmc), "failed to allocate tegra_host\n");
-		rc = -ENOMEM;
-		goto err_alloc_tegra_host;
-	}
+	tegra_host = sdhci_pltfm_priv(pltfm_host);
 	tegra_host->ddr_signaling = false;
 	tegra_host->soc_data = soc_data;
-	pltfm_host->priv = tegra_host;
 
 	rc = mmc_of_parse(host->mmc);
 	if (rc)
@@ -429,7 +423,6 @@ err_add_host:
 err_clk_get:
 err_power_req:
 err_parse_dt:
-err_alloc_tegra_host:
 	sdhci_pltfm_free(pdev);
 	return rc;
 }
-- 
2.7.0



From jszhang at marvell.com  Tue Feb 16 05:08:30 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 21:08:30 +0800
Subject: [PATCH v5 12/13] mmc: sdhci-pxav2: remove unnecessary assignment of
 pltfm_host->priv
In-Reply-To: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
References: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
Message-ID: <1455628111-5583-13-git-send-email-jszhang@marvell.com>

The sdhci_pltfm_init() function has initialized the priv member as
NULL, so there's no need to do it again.

Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Adrian Hunter <adrian.hunter at intel.com>
---
 drivers/mmc/host/sdhci-pxav2.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav2.c b/drivers/mmc/host/sdhci-pxav2.c
index beffd86..1d8dd35 100644
--- a/drivers/mmc/host/sdhci-pxav2.c
+++ b/drivers/mmc/host/sdhci-pxav2.c
@@ -177,7 +177,6 @@ static int sdhci_pxav2_probe(struct platform_device *pdev)
 		return PTR_ERR(host);
 
 	pltfm_host = sdhci_priv(host);
-	pltfm_host->priv = NULL;
 
 	clk = clk_get(dev, "PXA-SDHCLK");
 	if (IS_ERR(clk)) {
-- 
2.7.0



From jszhang at marvell.com  Tue Feb 16 05:08:31 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Tue, 16 Feb 2016 21:08:31 +0800
Subject: [PATCH v5 13/13] mmc: sdhci-pltfm: remove priv variable from
 sdhci_pltfm_host
In-Reply-To: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
References: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
Message-ID: <1455628111-5583-14-git-send-email-jszhang@marvell.com>

Now all clients migration to use sdhci_pltfm_init for private
allocation is done and there's no users of the priv variable, so we can
remove it from the sdhci_pltfm_host structure.

Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Adrian Hunter <adrian.hunter at intel.com>
---
 drivers/mmc/host/sdhci-pltfm.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pltfm.h b/drivers/mmc/host/sdhci-pltfm.h
index 04bc248..d38053b 100644
--- a/drivers/mmc/host/sdhci-pltfm.h
+++ b/drivers/mmc/host/sdhci-pltfm.h
@@ -23,7 +23,6 @@ struct sdhci_pltfm_data {
 
 struct sdhci_pltfm_host {
 	struct clk *clk;
-	void *priv; /* to handle quirks across io-accessor calls */
 
 	/* migrate from sdhci_of_host */
 	unsigned int clock;
-- 
2.7.0



From aleksey.makarov at linaro.org  Tue Feb 16 04:52:38 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Tue, 16 Feb 2016 15:52:38 +0300
Subject: [PATCH v6 1/2] ACPI: introduce a function to find the first physical
 device
In-Reply-To: <2019009.4Y5n3ZF6bK@vostro.rjw.lan>
References: <2019009.4Y5n3ZF6bK@vostro.rjw.lan>
Message-ID: <1455627160-10299-1-git-send-email-aleksey.makarov@linaro.org>

Factor out the code that finds the first physical device
of a given ACPI device.  It is used in several places.

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 drivers/acpi/acpi_platform.c | 19 ++-----------------
 drivers/acpi/bus.c           | 26 ++++++++++++++++++++------
 drivers/acpi/internal.h      |  1 +
 3 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 296b7a1..c3af108 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -43,7 +43,6 @@ static const struct acpi_device_id forbidden_id_list[] = {
 struct platform_device *acpi_create_platform_device(struct acpi_device *adev)
 {
 	struct platform_device *pdev = NULL;
-	struct acpi_device *acpi_parent;
 	struct platform_device_info pdevinfo;
 	struct resource_entry *rentry;
 	struct list_head resource_list;
@@ -82,22 +81,8 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev)
 	 * attached to it, that physical device should be the parent of the
 	 * platform device we are about to create.
 	 */
-	pdevinfo.parent = NULL;
-	acpi_parent = adev->parent;
-	if (acpi_parent) {
-		struct acpi_device_physical_node *entry;
-		struct list_head *list;
-
-		mutex_lock(&acpi_parent->physical_node_lock);
-		list = &acpi_parent->physical_node_list;
-		if (!list_empty(list)) {
-			entry = list_first_entry(list,
-					struct acpi_device_physical_node,
-					node);
-			pdevinfo.parent = entry->dev;
-		}
-		mutex_unlock(&acpi_parent->physical_node_lock);
-	}
+	pdevinfo.parent = adev->parent ?
+		acpi_get_first_physical_node(adev->parent) : NULL;
 	pdevinfo.name = dev_name(&adev->dev);
 	pdevinfo.id = -1;
 	pdevinfo.res = resources;
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index a212cef..d27e0f4 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -478,24 +478,38 @@ static void acpi_device_remove_notify_handler(struct acpi_device *device)
                              Device Matching
    -------------------------------------------------------------------------- */
 
-static struct acpi_device *acpi_primary_dev_companion(struct acpi_device *adev,
-						      const struct device *dev)
+/**
+ * acpi_get_first_physical_node - Get first physical node of an ACPI device
+ * @adev:	ACPI device in question
+ *
+ * Return: First physical node of ACPI device @adev
+ */
+struct device *acpi_get_first_physical_node(struct acpi_device *adev)
 {
 	struct mutex *physical_node_lock = &adev->physical_node_lock;
+	struct device *phys_dev;
 
 	mutex_lock(physical_node_lock);
 	if (list_empty(&adev->physical_node_list)) {
-		adev = NULL;
+		phys_dev = NULL;
 	} else {
 		const struct acpi_device_physical_node *node;
 
 		node = list_first_entry(&adev->physical_node_list,
 					struct acpi_device_physical_node, node);
-		if (node->dev != dev)
-			adev = NULL;
+
+		phys_dev = node->dev;
 	}
 	mutex_unlock(physical_node_lock);
-	return adev;
+	return phys_dev;
+}
+
+static struct acpi_device *acpi_primary_dev_companion(struct acpi_device *adev,
+						      const struct device *dev)
+{
+	const struct device *phys_dev = acpi_get_first_physical_node(adev);
+
+	return phys_dev && phys_dev == dev ? adev : NULL;
 }
 
 /**
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 11d87bf..ee9312ba 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -98,6 +98,7 @@ bool acpi_device_is_present(struct acpi_device *adev);
 bool acpi_device_is_battery(struct acpi_device *adev);
 bool acpi_device_is_first_physical_node(struct acpi_device *adev,
 					const struct device *dev);
+struct device *acpi_get_first_physical_node(struct acpi_device *adev);
 
 /* --------------------------------------------------------------------------
                      Device Matching and Notification
-- 
2.7.1



From andy.shevchenko at gmail.com  Tue Feb 16 05:13:50 2016
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Tue, 16 Feb 2016 15:13:50 +0200
Subject: [PATCH v3 05/10] serial: mps2-uart: add support for early console
In-Reply-To: <56C31F9F.10000@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-6-git-send-email-vladimir.murzin@arm.com>
 <CAHp75VdugAq0WnzLHmd9CJHCjBOdBwPqCmC3ARSaVF5XMYGoMw@mail.gmail.com>
 <56C31F9F.10000@arm.com>
Message-ID: <CAHp75Vf_4MgdWunQy5hBMH5GGei+OkktFPYY-ZprY0qOEnD=wA@mail.gmail.com>

On Tue, Feb 16, 2016 at 3:09 PM, Vladimir Murzin
<vladimir.murzin at arm.com> wrote:
> On 16/02/16 10:36, Andy Shevchenko wrote:
>> On Tue, Feb 16, 2016 at 12:08 PM, Vladimir Murzin
>> <vladimir.murzin at arm.com> wrote:
>>> This adds support early console for MPS2 UART which can be enabled via
>>> earlycon=mps2,0x40004000

>>> +static void mps2_early_putchar(struct uart_port *port, int ch)
>>> +{
>>> +
>>> +       while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
>>> +               cpu_relax();
>>
>> Infinite busy loop?
>
> In case of broken hw, yes, but I'm quite unsure how we can help to fix
> it. Do you have something in mind?

Set sane amount of loops like

int count = 100;
?
while (? && --count)

Though I have no idea what to do if count == 0. Perhaps it's a TX overrun state.

You may try to recover by flushing TX queue in HW (fifo and / or Tx
shift register) if HW supports it.

-- 
With Best Regards,
Andy Shevchenko


From eddie.huang at mediatek.com  Tue Feb 16 05:19:07 2016
From: eddie.huang at mediatek.com (Eddie Huang)
Date: Tue, 16 Feb 2016 21:19:07 +0800
Subject: [PATCH] rtc: mt6397: Add platform device ID table
In-Reply-To: <2416670.q30ahHlzPm@wuerfel>
References: <1455016095-13724-1-git-send-email-javier@osg.samsung.com>
 <1455501497.7263.4.camel@mtksdaap41> <56C1E5C8.6040007@osg.samsung.com>
 <2416670.q30ahHlzPm@wuerfel>
Message-ID: <1455628747.2981.4.camel@mtksdaap41>

On Tue, 2016-02-16 at 12:37 +0100, Arnd Bergmann wrote:
> On Monday 15 February 2016 11:50:48 Javier Martinez Canillas wrote:
> > 
> > On 02/14/2016 10:58 PM, Eddie Huang wrote:
> > 
> > [snip]
> > 
> > >> @@ -412,6 +418,7 @@ static struct platform_driver mtk_rtc_driver = {
> > >>      },
> > >>      .probe  = mtk_rtc_probe,
> > >>      .remove = mtk_rtc_remove,
> > >> +    .id_table = mt6397_rtc_id,
> > >>   };
> > >>
> > >>   module_platform_driver(mtk_rtc_driver);
> > >> @@ -419,4 +426,3 @@ module_platform_driver(mtk_rtc_driver);
> > >>   MODULE_LICENSE("GPL v2");
> > >>   MODULE_AUTHOR("Tianping Fang <tianping.fang at mediatek.com>");
> > >>   MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC");
> > >> -MODULE_ALIAS("platform:mt6397-rtc");
> > >
> > > This patch looks good to me, but I am wondering, since we tend to use
> > > device tree method to match driver, do we still need support platform
> > > device ID ?
> > >
> > 
> > I'm not familiar with neither this IP block nor the SoC so it is up to
> > you. I just noticed this issue when reviewing a regulator driver for a
> > similar PMIC posted by someone from mediatek.
> > 
> > I thought platform device was needed since the driver has a MODULE_ALIAS()
> > but please let me know what you prefer and I can re-spin the patch and
> > just remove the MODULE_ALIAS() if that makes more sense for this platform.
> >   
> > 
> 
> I agree. We can alway add a MODULE_DEVICE_TABLE() if we get multiple
> users of this driver on architectures that don't use devicetree yet.
> 

Sure. Thanks the patch to add expandability to this driver.

Acked-by: Eddie Huang <eddie.huang at mediatek.com>

Eddie




From tiffany.lin at mediatek.com  Tue Feb 16 05:20:05 2016
From: tiffany.lin at mediatek.com (tiffany lin)
Date: Tue, 16 Feb 2016 21:20:05 +0800
Subject: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2
 Video Encoder Driver
In-Reply-To: <56C2D371.9090805@xs4all.nl>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
 <56C1B4AF.1030207@xs4all.nl> <1455604653.19396.68.camel@mtksdaap41>
 <56C2D371.9090805@xs4all.nl>
Message-ID: <1455628805.19396.82.camel@mtksdaap41>

On Tue, 2016-02-16 at 08:44 +0100, Hans Verkuil wrote:
> On 02/16/2016 07:37 AM, tiffany lin wrote:
> 
> <snip>
> 
> >>> +static int vidioc_venc_s_parm(struct file *file, void *priv,
> >>> +			      struct v4l2_streamparm *a)
> >>> +{
> >>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> >>> +
> >>> +	if (a->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> >>> +		ctx->enc_params.framerate_num =
> >>> +			a->parm.output.timeperframe.denominator;
> >>> +		ctx->enc_params.framerate_denom =
> >>> +			a->parm.output.timeperframe.numerator;
> >>> +		ctx->param_change |= MTK_ENCODE_PARAM_FRAMERATE;
> >>> +	} else {
> >>> +		return -EINVAL;
> >>> +	}
> >>
> >> I'd invert the test:
> >>
> >> 	if (a->type != V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
> >> 		return -EINVAL;
> >>
> >> and now you can just set ctx->enc_params.
> >>
> > We will fix this in next version.
> > 
> > 
> >>> +	return 0;
> >>> +}
> >>
> >> And if there is an s_parm, then there should be a g_parm as well!
> >>
> > Now our driver does not support g_parm, our use cases do not use g_parm
> > too. 
> > Do we need to add g_parm at this moment? Or we could add it when we need
> > g_parm?
> 
> No, you need it. You can see why if you look at the v4l2-compliance output:
> 
>                  test VIDIOC_G/S_PARM: OK (Not Supported)
> 
> Why does it think it is unsupported? Because (just like most applications) it
> tries to call G_PARM first, and if that succeeds it tries to call S_PARM with
> the value it got from G_PARM. Thus ensuring the application doesn't change the
> driver state. So you can have a 'get' ioctl without the 'set' ioctl, but if
> there is a 'set' ioctl there must always be a 'get' ioctl.
> 
Got it. We will add g_parm in next version.

> <snip>
> 
> >>> +static int vidioc_venc_g_s_selection(struct file *file, void *priv,
> >>> +                                struct v4l2_selection *s)
> >>
> >> Why support s_selection if you can only return the current width and height?
> >> And why support g_selection if you can't change the selection?
> >>
> >> In other words, why implement this at all?
> >>
> >> Unless I am missing something here, I would just drop this.
> >>
> > Now our driver do not support these capabilities, but userspace app will
> > check whether g/s_crop are implemented when using encoder.
> > Because g/s_crop are deprecated as you mentioned in previous v2 review
> > comments. We change to use g_s_selection.
> > We will check if we could add this capability.
> 
> It's true that you should use g/s_selection instead of g/s_crop, but only if
> there is actually something to select. As long as you don't offer this capability,
> just drop this for now.
> 
> When you add the capability later you can just add the g/s_selection functions.
> 
> Getting selection right can be tricky. I wouldn't mind if this is done later in a
> separate patch.
> 
Got it. We will add the capability later.


> > 
> >>> +{
> >>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> >>> +	struct mtk_q_data *q_data;
> >>> +
> >>> +	if (V4L2_TYPE_IS_OUTPUT(s->type)) {
> >>> +		if (s->target !=  V4L2_SEL_TGT_COMPOSE)
> >>> +			return -EINVAL;
> >>> +	} else {
> >>> +		if (s->target != V4L2_SEL_TGT_CROP)
> >>> +			return -EINVAL;
> >>> +	}
> >>> +
> >>> +	if (s->r.left || s->r.top)
> >>> +		return -EINVAL;
> >>> +
> >>> +	q_data = mtk_venc_get_q_data(ctx, s->type);
> >>> +	if (!q_data)
> >>> +		return -EINVAL;
> >>> +
> >>> +	s->r.width = q_data->width;
> >>> +	s->r.height = q_data->height;
> >>> +
> >>> +	return 0;
> >>> +}
> >>> +
> >>> +
> >>> +static int vidioc_venc_qbuf(struct file *file, void *priv,
> >>> +			    struct v4l2_buffer *buf)
> >>> +{
> >>> +
> >>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> >>> +
> >>> +	if (ctx->state == MTK_STATE_ABORT) {
> >>> +		mtk_v4l2_err("[%d] Call on QBUF after unrecoverable error\n", ctx->idx);
> >>> +		return -EIO;
> >>> +	}
> >>> +
> >>> +	return v4l2_m2m_qbuf(file, ctx->m2m_ctx, buf);
> >>> +}
> >>> +
> >>> +static int vidioc_venc_dqbuf(struct file *file, void *priv,
> >>> +			     struct v4l2_buffer *buf)
> >>> +{
> >>> +	struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> >>> +	if (ctx->state == MTK_STATE_ABORT) {
> >>> +		mtk_v4l2_err("[%d] Call on QBUF after unrecoverable error\n", ctx->idx);
> >>> +		return -EIO;
> >>> +	}
> >>> +
> >>> +	return v4l2_m2m_dqbuf(file, ctx->m2m_ctx, buf);
> >>> +}
> >>> +
> >>> +
> >>> +const struct v4l2_ioctl_ops mtk_venc_ioctl_ops = {
> >>> +	.vidioc_streamon		= v4l2_m2m_ioctl_streamon,
> >>> +	.vidioc_streamoff		= v4l2_m2m_ioctl_streamoff,
> >>> +
> >>> +	.vidioc_reqbufs			= v4l2_m2m_ioctl_reqbufs,
> >>> +	.vidioc_querybuf		= v4l2_m2m_ioctl_querybuf,
> >>> +	.vidioc_qbuf			= vidioc_venc_qbuf,
> >>> +	.vidioc_dqbuf			= vidioc_venc_dqbuf,
> >>> +
> >>> +	.vidioc_querycap		= vidioc_venc_querycap,
> >>> +	.vidioc_enum_fmt_vid_cap_mplane = vidioc_enum_fmt_vid_cap_mplane,
> >>> +	.vidioc_enum_fmt_vid_out_mplane = vidioc_enum_fmt_vid_out_mplane,
> >>> +	.vidioc_enum_framesizes		= vidioc_enum_framesizes,
> >>> +
> >>> +	.vidioc_try_fmt_vid_cap_mplane	= vidioc_try_fmt_vid_cap_mplane,
> >>> +	.vidioc_try_fmt_vid_out_mplane	= vidioc_try_fmt_vid_out_mplane,
> >>> +	.vidioc_expbuf			= v4l2_m2m_ioctl_expbuf,
> >>
> >> Please add vidioc_create_bufs and vidioc_prepare_buf as well.
> >>
> > 
> > Currently we do not support these use cases, do we need to add
> > vidioc_create_bufs and vidioc_prepare_buf now?
> 
> I would suggest you do. The vb2 framework gives it (almost) for free.
> prepare_buf is completely free (just add the helper) and create_bufs
> needs a few small changes in the queue_setup function, that's all.
> 
Got it. We will add these in next version.

> > 
> > 
> >>> +	.vidioc_subscribe_event		= v4l2_ctrl_subscribe_event,
> >>> +	.vidioc_unsubscribe_event	= v4l2_event_unsubscribe,
> >>> +
> >>> +	.vidioc_s_parm			= vidioc_venc_s_parm,
> >>> +
> >>> +	.vidioc_s_fmt_vid_cap_mplane	= vidioc_venc_s_fmt,
> >>> +	.vidioc_s_fmt_vid_out_mplane	= vidioc_venc_s_fmt,
> >>> +
> >>> +	.vidioc_g_fmt_vid_cap_mplane	= vidioc_venc_g_fmt,
> >>> +	.vidioc_g_fmt_vid_out_mplane	= vidioc_venc_g_fmt,
> >>> +
> >>> +	.vidioc_g_selection		= vidioc_venc_g_s_selection,
> >>> +	.vidioc_s_selection		= vidioc_venc_g_s_selection,
> >>> +};
> 
> <snip>
> 
> >>> +int mtk_vcodec_enc_queue_init(void *priv, struct vb2_queue *src_vq,
> >>> +			   struct vb2_queue *dst_vq)
> >>> +{
> >>> +	struct mtk_vcodec_ctx *ctx = priv;
> >>> +	int ret;
> >>> +
> >>> +	src_vq->type		= V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
> >>> +	src_vq->io_modes	= VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
> >>
> >> I recomment dropping VB2_USERPTR. That only makes sense for scatter-gather dma,
> >> and you use physically contiguous DMA.
> >>
> > Now our userspace app use VB2_USERPTR. I need to check if we could drop
> > VB2_USERPTR.
> > We use src_vq->mem_ops = &vb2_dma_contig_memops;
> > And there are
> > 	.get_userptr	= vb2_dc_get_userptr,
> > 	.put_userptr	= vb2_dc_put_userptr,
> > I was confused why it only make sense for scatter-gather.
> > Could you kindly explain more?
> 
> VB2_USERPTR indicates that the application can use malloc to allocate buffers
> and pass those to the driver. Since malloc uses virtual memory the physical
> memory is scattered all over. And the first page typically does not start at
> the beginning of the page but at a random offset.
> 
> To support that the DMA generally has to be able to do scatter-gather.
> 
> Now, where things get ugly is that a hack was added to the USERPTR support where
> apps could pass a pointer to physically contiguous memory as a user pointer. This
> was a hack for embedded systems that preallocated a pool of buffers and needed to
> pass those pointers around somehow. So the dma-contig USERPTR support is for that
> 'feature'. If you try to pass a malloc()ed buffer to a dma-contig driver it will
> reject it. One big problem is that this specific hack isn't signaled anywhere, so
> applications have no way of knowing if the USERPTR support is the proper version
> or the hack where physically contiguous memory is expected.
> 
> This hack has been replaced with DMABUF which is the proper way of passing buffers
> around.
> 
> New dma-contig drivers should not use that old hack anymore. Use dmabuf to pass
> external buffers around.
> 
> How do you use it in your app? With malloc()ed buffers? Or with 'special' pointers
> to physically contiguous buffers?
> 
Understood now. Thanks for your explanation.
Now our app use malloc()ed buffers and we hook vb2_dma_contig_memops. 
I don't know why that dma-contig driver do not reject it.
I will try to figure it out.

> > 
> >>> +	src_vq->drv_priv	= ctx;
> >>> +	src_vq->buf_struct_size = sizeof(struct mtk_video_enc_buf);
> >>> +	src_vq->ops		= &mtk_venc_vb2_ops;
> >>> +	src_vq->mem_ops		= &vb2_dma_contig_memops;
> >>> +	src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
> >>> +	src_vq->lock = &ctx->dev->dev_mutex;
> >>> +
> >>> +	ret = vb2_queue_init(src_vq);
> >>> +	if (ret)
> >>> +		return ret;
> >>> +
> >>> +	dst_vq->type		= V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
> >>> +	dst_vq->io_modes	= VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
> >>> +	dst_vq->drv_priv	= ctx;
> >>> +	dst_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
> >>> +	dst_vq->ops		= &mtk_venc_vb2_ops;
> >>> +	dst_vq->mem_ops		= &vb2_dma_contig_memops;
> >>> +	dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
> >>> +	dst_vq->lock = &ctx->dev->dev_mutex;
> >>> +
> >>> +	return vb2_queue_init(dst_vq);
> >>> +}
> 
> Regards,
> 
> 	Hans
> 




From khalasa at piap.pl  Tue Feb 16 05:24:10 2016
From: khalasa at piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=)
Date: Tue, 16 Feb 2016 14:24:10 +0100
Subject: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
In-Reply-To: <2702068.KRp0Bplb5Q@wuerfel> (Arnd Bergmann's message of "Tue, 16
 Feb 2016 12:26:23 +0100")
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <4239208.KBB6rfivoa@wuerfel> <m3d1rxqa4p.fsf@t19.piap.pl>
 <2702068.KRp0Bplb5Q@wuerfel>
Message-ID: <m34md8rdol.fsf@t19.piap.pl>

Arnd Bergmann <arnd at arndb.de> writes:

> Both writes leave the CPU core within the spinlock but are not serialized
> with anything else, so there is no ordering between the CPUs when they
> enter the shared bus, other than having address before data. You'd
> expect to see address0, data0, address1, data1, but it could also
> be e.g. address0, address1, data1, data0.

Ah, so it's a matter of flushing the write buffers before exiting the
spinlock-protected code.

> The point is more what the common case is. Almost all machines we support
> have fixed-endian devices, and the drivers are correct when using readl()
> or in_le32() but are not endian-safe when using __raw_readl().

Sure, e.g. PCI does it this way (eventually swapping the data lanes if
needed).

> Using __raw_readl() has the big danger of someone accidentally "fixing"
> the driver to work like all the others in order to solve a theoretical
> endian problem, while it should really be made obvious that the hardware
> actively swaps its data on the bus.

Sure - if this is the case. On-chip IXP4xx peripherals don't swap data
at all (i.e., they match CPU endianess) - accessing their registers is
like accessing a normal CPU register. That's why they don't use
PCI-style readl() etc. - however a better name than __raw_* would
probably help here.

Using __raw_* in a PCI driver would be generally wrong.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland


From tomi.valkeinen at ti.com  Tue Feb 16 05:29:58 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 16 Feb 2016 15:29:58 +0200
Subject: [PATCH 00/11] CLCD Nomadik+Versatile support
In-Reply-To: <CACRpkda=mgcF8RRymbe0AAKpfCWGZSw_YZP5_6JW2g-mKEt16g@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <CACRpkda=mgcF8RRymbe0AAKpfCWGZSw_YZP5_6JW2g-mKEt16g@mail.gmail.com>
Message-ID: <56C32456.2030800@ti.com>



On 16/02/16 01:34, Linus Walleij wrote:
> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> 
>> Eventually I would like to have patches 1 thru 8 (those with
>> patches to CLCD or the DT bindings) applied through the FBDEV
>> subsystem,
> 
> If there are no comments, would the fbdev people consider
> patches 1 thru 8?

Hmm... Is there a v2 for the 05 patch? I see one in my mailbox, but it's
not sent as a reply to this thread, making it a bit unclear.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/d39da03d/attachment.sig>

From niklas.soderlund at ragnatech.se  Tue Feb 16 05:30:55 2016
From: niklas.soderlund at ragnatech.se (Niklas =?iso-8859-1?Q?S=F6derlund?=)
Date: Tue, 16 Feb 2016 14:30:55 +0100
Subject: [PATCH v3 1/8] iommu: Add MMIO mapping type
In-Reply-To: <56C3197C.8090903@arm.com>
References: <1455065878-11906-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <1455065878-11906-2-git-send-email-niklas.soderlund+renesas@ragnatech.se>
 <13740597.5lZXKsEG19@avalon> <56BCAF66.8010206@arm.com>
 <20160216120626.GA26710@bigcity.dyn.berto.se>
 <56C3197C.8090903@arm.com>
Message-ID: <20160216133055.GB26710@bigcity.dyn.berto.se>

* Robin Murphy <robin.murphy at arm.com> [2016-02-16 12:43:40 +0000]:

> On 16/02/16 12:06, Niklas S?derlund wrote:
> >Hi Robin,
> >
> >Thanks for your update patch I will include it in my next version. But
> >I'm sorry I do not understand, is your modification an addition or a
> >substitution to your original patch?
>
> Apologies for being confusing - that was a diff on top of the existing
> patch, to be folded in. My original patch was only handling IOMMU_MMIO for
> stage 2 PTEs, so we also need the extra code to handle the different way of
> setting the appropriate memory type in stage 1 PTEs.

That's what I though but wanted to be clear, thanks for clarifying. I
will fold the diff into your patch and keep your SoB line and send it
out with my series, hope that's a OK way for me to handle it.

Once more thanks for your patch and feedback.

>
> Robin.
>
> >* Robin Murphy <robin.murphy at arm.com> [2016-02-11 15:57:26 +0000]:
> >
> >>On 11/02/16 00:02, Laurent Pinchart wrote:
> >>>Hi Niklas,
> >>>
> >>>Thank you for the patch.
> >>>
> >>>On Wednesday 10 February 2016 01:57:51 Niklas S?derlund wrote:
> >>>>From: Robin Murphy <robin.murphy at arm.com>
> >>>>
> >>>>On some platforms, MMIO regions might need slightly different treatment
> >>>>compared to mapping regular memory; add the notion of MMIO mappings to
> >>>>the IOMMU API's memory type flags, so that callers can let the IOMMU
> >>>>drivers know to do the right thing.
> >>>>
> >>>>Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> >>>>Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> >>>
> >>>Answering the question from the cover letter, yes, it's totally fine to pick
> >>>the ack, that's actually expected.
> >>>
> >>>>---
> >>>>  drivers/iommu/io-pgtable-arm.c | 4 +++-
> >>>>  include/linux/iommu.h          | 1 +
> >>>
> >>>You might be asked to split this patch in two.
> >>
> >>Worse than that, you might also be asked to fix it up when the silly author
> >>remembers that he did this on a stage-2-only ARM SMMU, and the attributes
> >>for the stage 1 tables that the IPMMU uses are in a different code path:
> >>
> >>--->8---
> >>diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> >>index 5b5c299..7622c6e 100644
> >>--- a/drivers/iommu/io-pgtable-arm.c
> >>+++ b/drivers/iommu/io-pgtable-arm.c
> >>@@ -354,7 +354,10 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
> >>arm_lpae_io_pgtable *data,
> >>                 if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
> >>                         pte |= ARM_LPAE_PTE_AP_RDONLY;
> >>
> >>-               if (prot & IOMMU_CACHE)
> >>+               if (prot & IOMMU_MMIO)
> >>+                       pte |= (ARM_LPAE_MAIR_ATTR_IDX_DEV
> >>+                               << ARM_LPAE_PTE_ATTRINDX_SHIFT);
> >>+               else if (prot & IOMMU_CACHE)
> >>                         pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE
> >>                                 << ARM_LPAE_PTE_ATTRINDX_SHIFT);
> >>         } else {
> >>--->8---
> >>
> >>Sorry for the bother,
> >>Robin.
> >>
> >>>>  2 files changed, 4 insertions(+), 1 deletion(-)
> >>>>
> >>>>diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> >>>>index 381ca5a..3ff4f87 100644
> >>>>--- a/drivers/iommu/io-pgtable-arm.c
> >>>>+++ b/drivers/iommu/io-pgtable-arm.c
> >>>>@@ -364,7 +364,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
> >>>>arm_lpae_io_pgtable *data, pte |= ARM_LPAE_PTE_HAP_READ;
> >>>>  		if (prot & IOMMU_WRITE)
> >>>>  			pte |= ARM_LPAE_PTE_HAP_WRITE;
> >>>>-		if (prot & IOMMU_CACHE)
> >>>>+		if (prot & IOMMU_MMIO)
> >>>>+			pte |= ARM_LPAE_PTE_MEMATTR_DEV;
> >>>>+		else if (prot & IOMMU_CACHE)
> >>>>  			pte |= ARM_LPAE_PTE_MEMATTR_OIWB;
> >>>>  		else
> >>>>  			pte |= ARM_LPAE_PTE_MEMATTR_NC;
> >>>>diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> >>>>index a5c539f..34b6432 100644
> >>>>--- a/include/linux/iommu.h
> >>>>+++ b/include/linux/iommu.h
> >>>>@@ -30,6 +30,7 @@
> >>>>  #define IOMMU_WRITE	(1 << 1)
> >>>>  #define IOMMU_CACHE	(1 << 2) /* DMA cache coherency */
> >>>>  #define IOMMU_NOEXEC	(1 << 3)
> >>>>+#define IOMMU_MMIO	(1 << 4) /* e.g. things like MSI doorbells */
> >>>>
> >>>>  struct iommu_ops;
> >>>>  struct iommu_group;
> >>>
> >>
> >
>


From broonie at kernel.org  Tue Feb 16 05:22:23 2016
From: broonie at kernel.org (Mark Brown)
Date: Tue, 16 Feb 2016 13:22:23 +0000
Subject: [PATCH] spi/rockchip: Add dt-binding for Rockchip rk3399 spi
In-Reply-To: <1455614538-4415-1-git-send-email-jay.xu@rock-chips.com>
References: <1455614538-4415-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <20160216132223.GM18327@sirena.org.uk>

On Tue, Feb 16, 2016 at 05:22:18PM +0800, jianqun.xu wrote:

>  Documentation/devicetree/bindings/spi/spi-rockchip.txt | 1 +
>  1 file changed, 1 insertion(+)

I'd expect this to be added to both the driver and the binding document
not just the document.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/3631ddb2/attachment.sig>

From vladimir.murzin at arm.com  Tue Feb 16 05:38:09 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 13:38:09 +0000
Subject: [PATCH v3 05/10] serial: mps2-uart: add support for early console
In-Reply-To: <CAHp75Vf_4MgdWunQy5hBMH5GGei+OkktFPYY-ZprY0qOEnD=wA@mail.gmail.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>	<1455617295-23736-6-git-send-email-vladimir.murzin@arm.com>	<CAHp75VdugAq0WnzLHmd9CJHCjBOdBwPqCmC3ARSaVF5XMYGoMw@mail.gmail.com>	<56C31F9F.10000@arm.com>
 <CAHp75Vf_4MgdWunQy5hBMH5GGei+OkktFPYY-ZprY0qOEnD=wA@mail.gmail.com>
Message-ID: <56C32641.4020201@arm.com>

On 16/02/16 13:13, Andy Shevchenko wrote:
> On Tue, Feb 16, 2016 at 3:09 PM, Vladimir Murzin
> <vladimir.murzin at arm.com> wrote:
>> On 16/02/16 10:36, Andy Shevchenko wrote:
>>> On Tue, Feb 16, 2016 at 12:08 PM, Vladimir Murzin
>>> <vladimir.murzin at arm.com> wrote:
>>>> This adds support early console for MPS2 UART which can be enabled via
>>>> earlycon=mps2,0x40004000
> 
>>>> +static void mps2_early_putchar(struct uart_port *port, int ch)
>>>> +{
>>>> +
>>>> +       while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
>>>> +               cpu_relax();
>>>
>>> Infinite busy loop?
>>
>> In case of broken hw, yes, but I'm quite unsure how we can help to fix
>> it. Do you have something in mind?
> 
> Set sane amount of loops like
> 
> int count = 100;
> ?
> while (? && --count)
> 
> Though I have no idea what to do if count == 0. Perhaps it's a TX overrun state.

I thought about counter too, like some of drivers do, but had no idea
what to do next after counter reaches zero. In case of TX overrun we
could get it either because of broken hw or because we entered Linux
with that state already set. In both cases, it looks handy to me to
attach a debugger and see that we are spinning in this putchar loop.

If you do insist to have a counter I'll add one, but if you are not
strong about it I'd prefer to leave it as is.

> 
> You may try to recover by flushing TX queue in HW (fifo and / or Tx
> shift register) if HW supports it.
> 

I'm afraid this is not supported.

Thanks
Vladimir


From hansverk at cisco.com  Tue Feb 16 05:48:31 2016
From: hansverk at cisco.com (Hans Verkuil)
Date: Tue, 16 Feb 2016 14:48:31 +0100
Subject: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video
 Encoder Driver
In-Reply-To: <1455628805.19396.82.camel@mtksdaap41>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
 <56C1B4AF.1030207@xs4all.nl> <1455604653.19396.68.camel@mtksdaap41>
 <56C2D371.9090805@xs4all.nl> <1455628805.19396.82.camel@mtksdaap41>
Message-ID: <56C328AF.5030604@cisco.com>

Hi Tiffany,

>>>>> +int mtk_vcodec_enc_queue_init(void *priv, struct vb2_queue *src_vq,
>>>>> +			   struct vb2_queue *dst_vq)
>>>>> +{
>>>>> +	struct mtk_vcodec_ctx *ctx = priv;
>>>>> +	int ret;
>>>>> +
>>>>> +	src_vq->type		= V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
>>>>> +	src_vq->io_modes	= VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
>>>>
>>>> I recomment dropping VB2_USERPTR. That only makes sense for scatter-gather dma,
>>>> and you use physically contiguous DMA.
>>>>
>>> Now our userspace app use VB2_USERPTR. I need to check if we could drop
>>> VB2_USERPTR.
>>> We use src_vq->mem_ops = &vb2_dma_contig_memops;
>>> And there are
>>> 	.get_userptr	= vb2_dc_get_userptr,
>>> 	.put_userptr	= vb2_dc_put_userptr,
>>> I was confused why it only make sense for scatter-gather.
>>> Could you kindly explain more?
>>
>> VB2_USERPTR indicates that the application can use malloc to allocate buffers
>> and pass those to the driver. Since malloc uses virtual memory the physical
>> memory is scattered all over. And the first page typically does not start at
>> the beginning of the page but at a random offset.
>>
>> To support that the DMA generally has to be able to do scatter-gather.
>>
>> Now, where things get ugly is that a hack was added to the USERPTR support where
>> apps could pass a pointer to physically contiguous memory as a user pointer. This
>> was a hack for embedded systems that preallocated a pool of buffers and needed to
>> pass those pointers around somehow. So the dma-contig USERPTR support is for that
>> 'feature'. If you try to pass a malloc()ed buffer to a dma-contig driver it will
>> reject it. One big problem is that this specific hack isn't signaled anywhere, so
>> applications have no way of knowing if the USERPTR support is the proper version
>> or the hack where physically contiguous memory is expected.
>>
>> This hack has been replaced with DMABUF which is the proper way of passing buffers
>> around.
>>
>> New dma-contig drivers should not use that old hack anymore. Use dmabuf to pass
>> external buffers around.
>>
>> How do you use it in your app? With malloc()ed buffers? Or with 'special' pointers
>> to physically contiguous buffers?
>>
> Understood now. Thanks for your explanation.
> Now our app use malloc()ed buffers and we hook vb2_dma_contig_memops. 
> I don't know why that dma-contig driver do not reject it.
> I will try to figure it out.

Is there an iommu involved that turns the scatter-gather list into what looks like
contiguous memory for the DMA?

At the end of vb2_dc_get_userptr() in videobuf2-dma-contig.c there is a check
'if (contig_size < size)' that verifies that the sg DMA is contiguous. This would
work if there is an iommu involved (if I understand it correctly).

If that's the case, then it's OK to keep VB2_USERPTR because you have real sg
support (although not via the DMA engine, but via iommu mappings).

Regards,

	Hans


From tn at semihalf.com  Tue Feb 16 05:53:30 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:30 +0100
Subject: [PATCH V5 00/15] MMCONFIG refactoring and support for ARM64 PCI
 hostbridge init based on ACPI
Message-ID: <1455630825-27253-1-git-send-email-tn@semihalf.com>

>From the functionality point of view this series might be split into the
following logic parts:
1. Make MMCONFIG code arch-agnostic which allows all architectures to collect
   PCI config regions and used when necessary.
2. Move non-arch specific bits to the core code.
3. Use MMCONFIG code and implement generic ACPI based PCI host controller driver.
4. Enable above driver on ARM64

Patches has been built on top of 4.5-rc3 and can be found here:
git at github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v5)

NOTE, this patch set depends on Lorenzo's fixes:
https://patchwork.ozlabs.org/patch/576450/
which can be found in pci-acpi-v5 branch.

This has been tested on Cavium ThunderX server, JunoR2, HP RX2660 IA64, x86,
Hip05, X-Gene and QEMU-aarch64. Any help in reviewing and testing is very appreciated.

v4 -> v5
- dropped MCFG refactoring group patches 1-6 from series v4 and integrated Jayachandran's patch
  https://patchwork.ozlabs.org/patch/575525/
- rewrite PCI legacy IRQs allocation
- squashed two patches 11 and 12 from series v4, fixed bisection issue
- changelog improvements
- rebased to 4.5-rc3

v3 -> v4
- dropped Jiang's fix http://lkml.iu.edu/hypermail/linux/kernel/1601.1/04318.html
- added Lorenzo's fix patch 19/24
- ACPI PCI bus domain number assigning cleanup
- changed resource management, we now claim and reassign resources
- improvements for applying quirks
- dropped Matthew's http://www.spinics.net/lists/linux-pci/msg45950.html dependency
- rebased to 4.5-rc1

v2 -> v3
- fix legacy IRQ assigning and IO ports registration
- remove reference to arch specific companion device for ia64
- move ACPI PCI host controller driver to pci_root.c
- drop generic domain assignment for x86 and ia64 as I am not
  able to run all necessary test variants
- drop patch which cleaned legacy IRQ assignment since it belongs to
  Mathew's series:
  https://patchwork.ozlabs.org/patch/557504/
- extend MCFG quirk code
- rebased to 4.4

v1 -> v2
- moved non-arch specific piece of code to dirver/acpi/ directory
- fixed IO resource handling
- introduced PCI config accessors quirks matching
- moved ACPI_COMPANION_SET to generic code

v1 - https://lkml.org/lkml/2015/10/27/504
v2 - https://lkml.org/lkml/2015/12/16/246
v3 - http://lkml.iu.edu/hypermail/linux/kernel/1601.1/04308.html
v4 - https://lkml.org/lkml/2016/2/4/646

Jayachandran C (1):
  ACPI: MCFG: Move mmcfg_list management to drivers/acpi

Lorenzo Pieralisi (1):
  drivers: pci: add generic code to claim bus resources

Tomasz Nowicki (13):
  acpi, pci, mcfg: Provide default RAW ACPI PCI config space accessors.
  arm64, acpi: Use MCFG library and empty PCI config space accessors
    from pci_mcfg.c file.
  pci, acpi, ecam: Add flag to indicate whether ECAM region was hot
    added or not.
  x86, pci: Cleanup platform specific MCFG data by using ECAM hot_added
    flag.
  pci, acpi, x86, ia64: Move ACPI host bridge device companion
    assignment to core code.
  pci, acpi: Provide generic way to assign bus domain number.
  x86, ia64: Include acpi_pci_{add|remove}_bus to the default
    pcibios_{add|remove}_bus implementation.
  acpi, mcfg: Add default PCI config accessors implementation and
    initial support for related quirks.
  pci, of: Move the PCI I/O space management to PCI core code.
  pci, acpi: Support for ACPI based generic PCI host controller
    initialization
  pci, acpi: Match PCI config space accessors against platfrom specific
    quirks.
  arm64, pci, acpi: Assign legacy IRQs once device is enable.
  arm64, pci, acpi: Start using ACPI based PCI host bridge driver for
    ARM64.

 arch/arm64/Kconfig                 |   5 +
 arch/arm64/kernel/pci.c            |  35 +---
 arch/ia64/hp/common/sba_iommu.c    |   2 +-
 arch/ia64/include/asm/pci.h        |   1 -
 arch/ia64/pci/pci.c                |  26 ---
 arch/ia64/sn/kernel/io_acpi_init.c |   4 +-
 arch/x86/include/asm/pci.h         |   3 -
 arch/x86/include/asm/pci_x86.h     |  24 +--
 arch/x86/pci/acpi.c                |  47 +----
 arch/x86/pci/common.c              |  10 -
 arch/x86/pci/mmconfig-shared.c     | 269 ++++---------------------
 arch/x86/pci/mmconfig_32.c         |   1 +
 arch/x86/pci/mmconfig_64.c         |   1 +
 arch/x86/pci/numachip.c            |   1 +
 drivers/acpi/Kconfig               |   7 +
 drivers/acpi/Makefile              |   1 +
 drivers/acpi/pci_mcfg.c            | 392 +++++++++++++++++++++++++++++++++++++
 drivers/acpi/pci_root.c            | 154 ++++++++++++++-
 drivers/of/address.c               | 116 +----------
 drivers/pci/pci.c                  | 126 +++++++++++-
 drivers/pci/probe.c                |   5 +
 drivers/pci/setup-bus.c            |  63 ++++++
 drivers/xen/pci.c                  |   5 +-
 include/acpi/acpi_bus.h            |   1 +
 include/asm-generic/vmlinux.lds.h  |   7 +
 include/linux/of_address.h         |   9 -
 include/linux/pci-acpi.h           |  68 +++++++
 include/linux/pci.h                |   6 +
 28 files changed, 892 insertions(+), 497 deletions(-)
 create mode 100644 drivers/acpi/pci_mcfg.c

-- 
1.9.1



From tn at semihalf.com  Tue Feb 16 05:53:32 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:32 +0100
Subject: [PATCH V5 02/15] acpi, pci,
 mcfg: Provide default RAW ACPI PCI config space accessors.
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <1455630825-27253-3-git-send-email-tn@semihalf.com>

Lets keep RAW ACPI PCI config space accessors empty by default,
since we are note sure if they are necessary accross all archs.
Once we sort this out, we can provide generic version or let
architectures to overwrite, like now x86.

Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/acpi/pci_mcfg.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index ea84365..0467b00 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -21,6 +21,26 @@
 static DEFINE_MUTEX(pci_mmcfg_lock);
 LIST_HEAD(pci_mmcfg_list);
 
+/*
+ * raw_pci_read/write - raw ACPI PCI config space accessors.
+ *
+ * By defauly (__weak) these accessors are empty and should be overwritten
+ * by architectures which support operations on ACPI PCI_Config regions,
+ * see osl.c file.
+ */
+
+int __weak raw_pci_read(unsigned int domain, unsigned int bus,
+			unsigned int devfn, int reg, int len, u32 *val)
+{
+	return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
+int __weak raw_pci_write(unsigned int domain, unsigned int bus,
+			 unsigned int devfn, int reg, int len, u32 val)
+{
+	return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
 static void list_add_sorted(struct pci_mmcfg_region *new)
 {
 	struct pci_mmcfg_region *cfg;
-- 
1.9.1



From tn at semihalf.com  Tue Feb 16 05:53:31 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:31 +0100
Subject: [PATCH V5 01/15] ACPI: MCFG: Move mmcfg_list management to
 drivers/acpi
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <1455630825-27253-2-git-send-email-tn@semihalf.com>

From: Jayachandran C <jchandra at broadcom.com>

Move pci_mmcfg_list handling to a drivers/acpi/pci_mcfg.c. This is
to share the API and code with ARM64 later. The corresponding
declarations are moved from asm/pci_x86.h to linux/pci-acpi.h

As a part of this we introduce three functions that can be
implemented by the arch code: pci_mmconfig_map_resource() to map a
mcfg entry, pci_mmconfig_unmap_resource to do the corresponding
unmap and pci_mmconfig_enabled to see if the arch setup of
mcfg entries was successful. We also provide weak implementations
of these, which will be used from ARM64. On x86, we retain the
old logic by providing platform specific implementation.

This patch is purely rearranging code, it should not have any
impact on the logic of MCFG parsing or list handling.

Signed-off-by: Jayachandran C <jchandra at broadcom.com>
[Xen parts:]
Acked-by: David Vrabel <david.vrabel at citrix.com>
---
 arch/x86/include/asm/pci_x86.h |  24 +---
 arch/x86/pci/mmconfig-shared.c | 269 +++++------------------------------
 arch/x86/pci/mmconfig_32.c     |   1 +
 arch/x86/pci/mmconfig_64.c     |   1 +
 arch/x86/pci/numachip.c        |   1 +
 drivers/acpi/Makefile          |   1 +
 drivers/acpi/pci_mcfg.c        | 312 +++++++++++++++++++++++++++++++++++++++++
 drivers/xen/pci.c              |   5 +-
 include/linux/pci-acpi.h       |  33 +++++
 9 files changed, 386 insertions(+), 261 deletions(-)
 create mode 100644 drivers/acpi/pci_mcfg.c

diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 46873fb..7824626 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -122,33 +122,11 @@ extern int pci_legacy_init(void);
 extern void pcibios_fixup_irqs(void);
 
 /* pci-mmconfig.c */
-
-/* "PCI MMCONFIG %04x [bus %02x-%02x]" */
-#define PCI_MMCFG_RESOURCE_NAME_LEN (22 + 4 + 2 + 2)
-
-struct pci_mmcfg_region {
-	struct list_head list;
-	struct resource res;
-	u64 address;
-	char __iomem *virt;
-	u16 segment;
-	u8 start_bus;
-	u8 end_bus;
-	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
-};
-
+struct pci_mmcfg_region;
 extern int __init pci_mmcfg_arch_init(void);
 extern void __init pci_mmcfg_arch_free(void);
 extern int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg);
 extern void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg);
-extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
-			       phys_addr_t addr);
-extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
-extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
-
-extern struct list_head pci_mmcfg_list;
-
-#define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
 
 /*
  * On AMD Fam10h CPUs, all PCI MMIO configuration space accesses must use
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index dd30b7e..626710b 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -12,13 +12,12 @@
 
 #include <linux/pci.h>
 #include <linux/init.h>
-#include <linux/sfi_acpi.h>
 #include <linux/bitmap.h>
-#include <linux/dmi.h>
 #include <linux/slab.h>
 #include <linux/mutex.h>
 #include <linux/rculist.h>
 #include <asm/e820.h>
+#include <linux/pci-acpi.h>
 #include <asm/pci_x86.h>
 #include <asm/acpi.h>
 
@@ -27,9 +26,6 @@
 /* Indicate if the mmcfg resources have been placed into the resource table. */
 static bool pci_mmcfg_running_state;
 static bool pci_mmcfg_arch_init_failed;
-static DEFINE_MUTEX(pci_mmcfg_lock);
-
-LIST_HEAD(pci_mmcfg_list);
 
 static void __init pci_mmconfig_remove(struct pci_mmcfg_region *cfg)
 {
@@ -48,83 +44,6 @@ static void __init free_all_mmcfg(void)
 		pci_mmconfig_remove(cfg);
 }
 
-static void list_add_sorted(struct pci_mmcfg_region *new)
-{
-	struct pci_mmcfg_region *cfg;
-
-	/* keep list sorted by segment and starting bus number */
-	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list) {
-		if (cfg->segment > new->segment ||
-		    (cfg->segment == new->segment &&
-		     cfg->start_bus >= new->start_bus)) {
-			list_add_tail_rcu(&new->list, &cfg->list);
-			return;
-		}
-	}
-	list_add_tail_rcu(&new->list, &pci_mmcfg_list);
-}
-
-static struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
-						   int end, u64 addr)
-{
-	struct pci_mmcfg_region *new;
-	struct resource *res;
-
-	if (addr == 0)
-		return NULL;
-
-	new = kzalloc(sizeof(*new), GFP_KERNEL);
-	if (!new)
-		return NULL;
-
-	new->address = addr;
-	new->segment = segment;
-	new->start_bus = start;
-	new->end_bus = end;
-
-	res = &new->res;
-	res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
-	res->end = addr + PCI_MMCFG_BUS_OFFSET(end + 1) - 1;
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
-	snprintf(new->name, PCI_MMCFG_RESOURCE_NAME_LEN,
-		 "PCI MMCONFIG %04x [bus %02x-%02x]", segment, start, end);
-	res->name = new->name;
-
-	return new;
-}
-
-static struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
-							int end, u64 addr)
-{
-	struct pci_mmcfg_region *new;
-
-	new = pci_mmconfig_alloc(segment, start, end, addr);
-	if (new) {
-		mutex_lock(&pci_mmcfg_lock);
-		list_add_sorted(new);
-		mutex_unlock(&pci_mmcfg_lock);
-
-		pr_info(PREFIX
-		       "MMCONFIG for domain %04x [bus %02x-%02x] at %pR "
-		       "(base %#lx)\n",
-		       segment, start, end, &new->res, (unsigned long)addr);
-	}
-
-	return new;
-}
-
-struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus)
-{
-	struct pci_mmcfg_region *cfg;
-
-	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
-		if (cfg->segment == segment &&
-		    cfg->start_bus <= bus && bus <= cfg->end_bus)
-			return cfg;
-
-	return NULL;
-}
-
 static const char *__init pci_mmcfg_e7520(void)
 {
 	u32 win;
@@ -543,73 +462,6 @@ static void __init pci_mmcfg_reject_broken(int early)
 	}
 }
 
-static int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
-					struct acpi_mcfg_allocation *cfg)
-{
-	int year;
-
-	if (cfg->address < 0xFFFFFFFF)
-		return 0;
-
-	if (!strncmp(mcfg->header.oem_id, "SGI", 3))
-		return 0;
-
-	if (mcfg->header.revision >= 1) {
-		if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) &&
-		    year >= 2010)
-			return 0;
-	}
-
-	pr_err(PREFIX "MCFG region for %04x [bus %02x-%02x] at %#llx "
-	       "is above 4GB, ignored\n", cfg->pci_segment,
-	       cfg->start_bus_number, cfg->end_bus_number, cfg->address);
-	return -EINVAL;
-}
-
-static int __init pci_parse_mcfg(struct acpi_table_header *header)
-{
-	struct acpi_table_mcfg *mcfg;
-	struct acpi_mcfg_allocation *cfg_table, *cfg;
-	unsigned long i;
-	int entries;
-
-	if (!header)
-		return -EINVAL;
-
-	mcfg = (struct acpi_table_mcfg *)header;
-
-	/* how many config structures do we have */
-	free_all_mmcfg();
-	entries = 0;
-	i = header->length - sizeof(struct acpi_table_mcfg);
-	while (i >= sizeof(struct acpi_mcfg_allocation)) {
-		entries++;
-		i -= sizeof(struct acpi_mcfg_allocation);
-	}
-	if (entries == 0) {
-		pr_err(PREFIX "MMCONFIG has no entries\n");
-		return -ENODEV;
-	}
-
-	cfg_table = (struct acpi_mcfg_allocation *) &mcfg[1];
-	for (i = 0; i < entries; i++) {
-		cfg = &cfg_table[i];
-		if (acpi_mcfg_check_entry(mcfg, cfg)) {
-			free_all_mmcfg();
-			return -ENODEV;
-		}
-
-		if (pci_mmconfig_add(cfg->pci_segment, cfg->start_bus_number,
-				   cfg->end_bus_number, cfg->address) == NULL) {
-			pr_warn(PREFIX "no memory for MCFG entries\n");
-			free_all_mmcfg();
-			return -ENOMEM;
-		}
-	}
-
-	return 0;
-}
-
 #ifdef CONFIG_ACPI_APEI
 extern int (*arch_apei_filter_addr)(int (*func)(__u64 start, __u64 size,
 				     void *data), void *data);
@@ -662,13 +514,20 @@ static void __init __pci_mmcfg_init(int early)
 
 static int __initdata known_bridge;
 
+static void __init pci_mmcfg_list_setup(void)
+{
+	free_all_mmcfg();
+	if (pci_mmconfig_parse_table())
+		free_all_mmcfg();
+}
+
 void __init pci_mmcfg_early_init(void)
 {
 	if (pci_probe & PCI_PROBE_MMCONF) {
 		if (pci_mmcfg_check_hostbridge())
 			known_bridge = 1;
 		else
-			acpi_sfi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg);
+			pci_mmcfg_list_setup();
 		__pci_mmcfg_init(1);
 
 		set_apei_filter();
@@ -686,7 +545,7 @@ void __init pci_mmcfg_late_init(void)
 
 	/* MMCONFIG hasn't been enabled yet, try again */
 	if (pci_probe & PCI_PROBE_MASK & ~PCI_PROBE_MMCONF) {
-		acpi_sfi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg);
+		pci_mmcfg_list_setup();
 		__pci_mmcfg_init(0);
 	}
 }
@@ -720,99 +579,41 @@ static int __init pci_mmcfg_late_insert_resources(void)
  */
 late_initcall(pci_mmcfg_late_insert_resources);
 
-/* Add MMCFG information for host bridges */
-int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
-			phys_addr_t addr)
+int pci_mmconfig_map_resource(struct device *dev, struct pci_mmcfg_region *cfg)
 {
-	int rc;
-	struct resource *tmp = NULL;
-	struct pci_mmcfg_region *cfg;
+	struct resource *tmp;
 
-	if (!(pci_probe & PCI_PROBE_MMCONF) || pci_mmcfg_arch_init_failed)
-		return -ENODEV;
-
-	if (start > end)
-		return -EINVAL;
-
-	mutex_lock(&pci_mmcfg_lock);
-	cfg = pci_mmconfig_lookup(seg, start);
-	if (cfg) {
-		if (cfg->end_bus < end)
-			dev_info(dev, FW_INFO
-				 "MMCONFIG for "
-				 "domain %04x [bus %02x-%02x] "
-				 "only partially covers this bridge\n",
-				  cfg->segment, cfg->start_bus, cfg->end_bus);
-		mutex_unlock(&pci_mmcfg_lock);
-		return -EEXIST;
-	}
-
-	if (!addr) {
-		mutex_unlock(&pci_mmcfg_lock);
-		return -EINVAL;
-	}
-
-	rc = -EBUSY;
-	cfg = pci_mmconfig_alloc(seg, start, end, addr);
-	if (cfg == NULL) {
-		dev_warn(dev, "fail to add MMCONFIG (out of memory)\n");
-		rc = -ENOMEM;
-	} else if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
+	if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
 		dev_warn(dev, FW_BUG "MMCONFIG %pR isn't reserved\n",
 			 &cfg->res);
-	} else {
-		/* Insert resource if it's not in boot stage */
-		if (pci_mmcfg_running_state)
-			tmp = insert_resource_conflict(&iomem_resource,
-						       &cfg->res);
-
+		return -EBUSY;
+	}
+	/* Insert resource if it's not in boot stage */
+	if (pci_mmcfg_running_state) {
+		tmp = insert_resource_conflict(&iomem_resource,
+					       &cfg->res);
 		if (tmp) {
-			dev_warn(dev,
-				 "MMCONFIG %pR conflicts with "
-				 "%s %pR\n",
-				 &cfg->res, tmp->name, tmp);
-		} else if (pci_mmcfg_arch_map(cfg)) {
-			dev_warn(dev, "fail to map MMCONFIG %pR.\n",
-				 &cfg->res);
-		} else {
-			list_add_sorted(cfg);
-			dev_info(dev, "MMCONFIG at %pR (base %#lx)\n",
-				 &cfg->res, (unsigned long)addr);
-			cfg = NULL;
-			rc = 0;
+			dev_warn(dev, "MMCONFIG %pR conflicts with %s %pR\n",
+				&cfg->res, tmp->name, tmp);
+			return -EBUSY;
 		}
 	}
-
-	if (cfg) {
-		if (cfg->res.parent)
-			release_resource(&cfg->res);
-		kfree(cfg);
+	if (pci_mmcfg_arch_map(cfg)) {
+		dev_warn(dev, "fail to map MMCONFIG %pR.\n", &cfg->res);
+		return -EBUSY;
 	}
-
-	mutex_unlock(&pci_mmcfg_lock);
-
-	return rc;
+	return 0;
 }
 
-/* Delete MMCFG information for host bridges */
-int pci_mmconfig_delete(u16 seg, u8 start, u8 end)
+void pci_mmconfig_unmap_resource(struct pci_mmcfg_region *cfg)
 {
-	struct pci_mmcfg_region *cfg;
-
-	mutex_lock(&pci_mmcfg_lock);
-	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
-		if (cfg->segment == seg && cfg->start_bus == start &&
-		    cfg->end_bus == end) {
-			list_del_rcu(&cfg->list);
-			synchronize_rcu();
-			pci_mmcfg_arch_unmap(cfg);
-			if (cfg->res.parent)
-				release_resource(&cfg->res);
-			mutex_unlock(&pci_mmcfg_lock);
-			kfree(cfg);
-			return 0;
-		}
-	mutex_unlock(&pci_mmcfg_lock);
+	pci_mmcfg_arch_unmap(cfg);
+	if (cfg->res.parent)
+		release_resource(&cfg->res);
+	cfg->res.parent = NULL;
+}
 
-	return -ENOENT;
+int pci_mmconfig_enabled(void)
+{
+	return (pci_probe & PCI_PROBE_MMCONF) && !pci_mmcfg_arch_init_failed;
 }
diff --git a/arch/x86/pci/mmconfig_32.c b/arch/x86/pci/mmconfig_32.c
index 43984bc..38a37f8 100644
--- a/arch/x86/pci/mmconfig_32.c
+++ b/arch/x86/pci/mmconfig_32.c
@@ -12,6 +12,7 @@
 #include <linux/pci.h>
 #include <linux/init.h>
 #include <linux/rcupdate.h>
+#include <linux/pci-acpi.h>
 #include <asm/e820.h>
 #include <asm/pci_x86.h>
 
diff --git a/arch/x86/pci/mmconfig_64.c b/arch/x86/pci/mmconfig_64.c
index bea5249..29253ec 100644
--- a/arch/x86/pci/mmconfig_64.c
+++ b/arch/x86/pci/mmconfig_64.c
@@ -10,6 +10,7 @@
 #include <linux/acpi.h>
 #include <linux/bitmap.h>
 #include <linux/rcupdate.h>
+#include <linux/pci-acpi.h>
 #include <asm/e820.h>
 #include <asm/pci_x86.h>
 
diff --git a/arch/x86/pci/numachip.c b/arch/x86/pci/numachip.c
index 2e565e6..c181eeb 100644
--- a/arch/x86/pci/numachip.c
+++ b/arch/x86/pci/numachip.c
@@ -14,6 +14,7 @@
  */
 
 #include <linux/pci.h>
+#include <linux/pci-acpi.h>
 #include <asm/pci_x86.h>
 
 static u8 limit __read_mostly;
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 7ea903d..e5e4393 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -40,6 +40,7 @@ acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
 acpi-y				+= ec.o
 acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
 acpi-y				+= pci_root.o pci_link.o pci_irq.o
+acpi-$(CONFIG_PCI_MMCONFIG)	+= pci_mcfg.o
 acpi-y				+= acpi_lpss.o acpi_apd.o
 acpi-y				+= acpi_platform.o
 acpi-y				+= acpi_pnp.o
diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
new file mode 100644
index 0000000..ea84365
--- /dev/null
+++ b/drivers/acpi/pci_mcfg.c
@@ -0,0 +1,312 @@
+/*
+ * pci_mcfg.c
+ *
+ * Common code to maintain the MCFG areas and mappings
+ *
+ * This has been extracted from arch/x86/pci/mmconfig-shared.c
+ * and moved here so that other architectures can use this code.
+ */
+
+#include <linux/pci.h>
+#include <linux/init.h>
+#include <linux/dmi.h>
+#include <linux/pci-acpi.h>
+#include <linux/sfi_acpi.h>
+#include <linux/slab.h>
+#include <linux/mutex.h>
+#include <linux/rculist.h>
+
+#define PREFIX	"ACPI: "
+
+static DEFINE_MUTEX(pci_mmcfg_lock);
+LIST_HEAD(pci_mmcfg_list);
+
+static void list_add_sorted(struct pci_mmcfg_region *new)
+{
+	struct pci_mmcfg_region *cfg;
+
+	/* keep list sorted by segment and starting bus number */
+	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list) {
+		if (cfg->segment > new->segment ||
+		    (cfg->segment == new->segment &&
+		     cfg->start_bus >= new->start_bus)) {
+			list_add_tail_rcu(&new->list, &cfg->list);
+			return;
+		}
+	}
+	list_add_tail_rcu(&new->list, &pci_mmcfg_list);
+}
+
+static struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
+						   int end, u64 addr)
+{
+	struct pci_mmcfg_region *new;
+	struct resource *res;
+
+	if (addr == 0)
+		return NULL;
+
+	new = kzalloc(sizeof(*new), GFP_KERNEL);
+	if (!new)
+		return NULL;
+
+	new->address = addr;
+	new->segment = segment;
+	new->start_bus = start;
+	new->end_bus = end;
+
+	res = &new->res;
+	res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
+	res->end = addr + PCI_MMCFG_BUS_OFFSET(end + 1) - 1;
+	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	snprintf(new->name, PCI_MMCFG_RESOURCE_NAME_LEN,
+		 "PCI MMCONFIG %04x [bus %02x-%02x]", segment, start, end);
+	res->name = new->name;
+
+	return new;
+}
+
+struct pci_mmcfg_region *pci_mmconfig_add(int segment, int start,
+							int end, u64 addr)
+{
+	struct pci_mmcfg_region *new;
+
+	new = pci_mmconfig_alloc(segment, start, end, addr);
+	if (new) {
+		mutex_lock(&pci_mmcfg_lock);
+		list_add_sorted(new);
+		mutex_unlock(&pci_mmcfg_lock);
+
+		pr_info(PREFIX
+		       "MMCONFIG for domain %04x [bus %02x-%02x] at %pR "
+		       "(base %#lx)\n",
+		       segment, start, end, &new->res, (unsigned long)addr);
+	}
+
+	return new;
+}
+
+struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus)
+{
+	struct pci_mmcfg_region *cfg;
+
+	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
+		if (cfg->segment == segment &&
+		    cfg->start_bus <= bus && bus <= cfg->end_bus)
+			return cfg;
+
+	return NULL;
+}
+
+/*
+ * Map a pci_mmcfg_region, can be overrriden by arch
+ */
+int __weak pci_mmconfig_map_resource(struct device *dev,
+	struct pci_mmcfg_region *mcfg)
+{
+	struct resource *tmp;
+	void __iomem *vaddr;
+
+	tmp = insert_resource_conflict(&iomem_resource, &mcfg->res);
+	if (tmp) {
+		dev_warn(dev, "MMCONFIG %pR conflicts with %s %pR\n",
+			&mcfg->res, tmp->name, tmp);
+		return -EBUSY;
+	}
+
+	vaddr =  ioremap(mcfg->res.start, resource_size(&mcfg->res));
+	if (!vaddr) {
+		release_resource(&mcfg->res);
+		return -ENOMEM;
+	}
+
+	mcfg->virt = vaddr;
+	return 0;
+}
+
+/*
+ * Unmap a pci_mmcfg_region, can be overrriden by arch
+ */
+void __weak pci_mmconfig_unmap_resource(struct pci_mmcfg_region *mcfg)
+{
+	if (mcfg->virt) {
+		iounmap(mcfg->virt);
+		mcfg->virt = NULL;
+	}
+	if (mcfg->res.parent) {
+		release_resource(&mcfg->res);
+		mcfg->res.parent = NULL;
+	}
+}
+
+/*
+ * check if the mmconfig is enabled and configured
+ */
+int __weak pci_mmconfig_enabled(void)
+{
+	return 1;
+}
+
+/* Add MMCFG information for host bridges */
+int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
+			phys_addr_t addr)
+{
+	struct pci_mmcfg_region *cfg;
+	int rc;
+
+	if (!pci_mmconfig_enabled())
+		return -ENODEV;
+	if (start > end)
+		return -EINVAL;
+
+	mutex_lock(&pci_mmcfg_lock);
+	cfg = pci_mmconfig_lookup(seg, start);
+	if (cfg) {
+		if (cfg->end_bus < end)
+			dev_info(dev, FW_INFO
+				 "MMCONFIG for "
+				 "domain %04x [bus %02x-%02x] "
+				 "only partially covers this bridge\n",
+				  cfg->segment, cfg->start_bus, cfg->end_bus);
+		rc = -EEXIST;
+		goto err;
+	}
+
+	if (!addr) {
+		rc = -EINVAL;
+		goto err;
+	}
+
+	cfg = pci_mmconfig_alloc(seg, start, end, addr);
+	if (cfg == NULL) {
+		dev_warn(dev, "fail to add MMCONFIG (out of memory)\n");
+		rc = -ENOMEM;
+		goto err;
+	}
+	rc = pci_mmconfig_map_resource(dev, cfg);
+	if (!rc) {
+		list_add_sorted(cfg);
+		dev_info(dev, "MMCONFIG at %pR (base %#lx)\n",
+				 &cfg->res, (unsigned long)addr);
+		return 0;
+	} else {
+		if (cfg->res.parent)
+			release_resource(&cfg->res);
+		kfree(cfg);
+	}
+
+err:
+	mutex_unlock(&pci_mmcfg_lock);
+	return rc;
+}
+
+/* Delete MMCFG information for host bridges */
+int pci_mmconfig_delete(u16 seg, u8 start, u8 end)
+{
+	struct pci_mmcfg_region *cfg;
+
+	mutex_lock(&pci_mmcfg_lock);
+	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
+		if (cfg->segment == seg && cfg->start_bus == start &&
+		    cfg->end_bus == end) {
+			list_del_rcu(&cfg->list);
+			synchronize_rcu();
+			pci_mmconfig_unmap_resource(cfg);
+			mutex_unlock(&pci_mmcfg_lock);
+			kfree(cfg);
+			return 0;
+		}
+	mutex_unlock(&pci_mmcfg_lock);
+
+	return -ENOENT;
+}
+
+static int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
+					struct acpi_mcfg_allocation *cfg)
+{
+	int year;
+
+	if (!config_enabled(CONFIG_X86))
+		return 0;
+
+	if (cfg->address < 0xFFFFFFFF)
+		return 0;
+
+	if (!strncmp(mcfg->header.oem_id, "SGI", 3))
+		return 0;
+
+	if (mcfg->header.revision >= 1) {
+		if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) &&
+		    year >= 2010)
+			return 0;
+	}
+
+	pr_err(PREFIX "MCFG region for %04x [bus %02x-%02x] at %#llx "
+	       "is above 4GB, ignored\n", cfg->pci_segment,
+	       cfg->start_bus_number, cfg->end_bus_number, cfg->address);
+	return -EINVAL;
+}
+
+static int __init pci_parse_mcfg(struct acpi_table_header *header)
+{
+	struct acpi_table_mcfg *mcfg;
+	struct acpi_mcfg_allocation *cfg_table, *cfg;
+	unsigned long i;
+	int entries;
+
+	if (!header)
+		return -EINVAL;
+
+	mcfg = (struct acpi_table_mcfg *)header;
+
+	/* how many config structures do we have */
+	entries = 0;
+	i = header->length - sizeof(struct acpi_table_mcfg);
+	while (i >= sizeof(struct acpi_mcfg_allocation)) {
+		entries++;
+		i -= sizeof(struct acpi_mcfg_allocation);
+	}
+	if (entries == 0) {
+		pr_err(PREFIX "MMCONFIG has no entries\n");
+		return -ENODEV;
+	}
+
+	cfg_table = (struct acpi_mcfg_allocation *) &mcfg[1];
+	for (i = 0; i < entries; i++) {
+		cfg = &cfg_table[i];
+		if (acpi_mcfg_check_entry(mcfg, cfg))
+			return -ENODEV;
+
+		if (pci_mmconfig_add(cfg->pci_segment, cfg->start_bus_number,
+				   cfg->end_bus_number, cfg->address) == NULL) {
+			pr_warn(PREFIX "no memory for MCFG entries\n");
+			return -ENOMEM;
+		}
+	}
+
+	return 0;
+}
+
+int __init pci_mmconfig_parse_table(void)
+{
+	return acpi_sfi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg);
+}
+
+void __weak __init pci_mmcfg_late_init(void)
+{
+	int err, n = 0;
+	struct pci_mmcfg_region *cfg;
+
+	err = pci_mmconfig_parse_table();
+	if (err) {
+		pr_err(PREFIX " Failed to parse MCFG (%d)\n", err);
+		return;
+	}
+
+	list_for_each_entry(cfg, &pci_mmcfg_list, list) {
+		pci_mmconfig_map_resource(NULL, cfg);
+		n++;
+	}
+
+	pr_info(PREFIX " MCFG table loaded %d entries\n", n);
+}
diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
index 7494dbe..97aa9d3 100644
--- a/drivers/xen/pci.c
+++ b/drivers/xen/pci.c
@@ -27,9 +27,6 @@
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include "../pci/pci.h"
-#ifdef CONFIG_PCI_MMCONFIG
-#include <asm/pci_x86.h>
-#endif
 
 static bool __read_mostly pci_seg_supported = true;
 
@@ -221,7 +218,7 @@ static int __init xen_mcfg_late(void)
 	if (!xen_initial_domain())
 		return 0;
 
-	if ((pci_probe & PCI_PROBE_MMCONF) == 0)
+	if (!pci_mmconfig_enabled())
 		return 0;
 
 	if (list_empty(&pci_mmcfg_list))
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index 89ab057..e9450ef 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -106,6 +106,39 @@ extern const u8 pci_acpi_dsm_uuid[];
 #define RESET_DELAY_DSM		0x08
 #define FUNCTION_DELAY_DSM	0x09
 
+/* common API to maintain list of MCFG regions */
+/* "PCI MMCONFIG %04x [bus %02x-%02x]" */
+#define PCI_MMCFG_RESOURCE_NAME_LEN (22 + 4 + 2 + 2)
+
+struct pci_mmcfg_region {
+	struct list_head list;
+	struct resource res;
+	u64 address;
+	char __iomem *virt;
+	u16 segment;
+	u8 start_bus;
+	u8 end_bus;
+	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
+};
+
+extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
+			       phys_addr_t addr);
+extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
+
+extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
+extern struct pci_mmcfg_region *pci_mmconfig_add(int segment, int start,
+							int end, u64 addr);
+extern int pci_mmconfig_map_resource(struct device *dev,
+	struct pci_mmcfg_region *mcfg);
+extern void pci_mmconfig_unmap_resource(struct pci_mmcfg_region *mcfg);
+extern int pci_mmconfig_enabled(void);
+extern int __init pci_mmconfig_parse_table(void);
+
+extern struct list_head pci_mmcfg_list;
+
+#define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
+#define PCI_MMCFG_OFFSET(bus, devfn)   ((bus) << 20 | (devfn) << 12)
+
 #else	/* CONFIG_ACPI */
 static inline void acpi_pci_add_bus(struct pci_bus *bus) { }
 static inline void acpi_pci_remove_bus(struct pci_bus *bus) { }
-- 
1.9.1



From tn at semihalf.com  Tue Feb 16 05:53:34 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:34 +0100
Subject: [PATCH V5 04/15] pci, acpi,
 ecam: Add flag to indicate whether ECAM region was hot added or not.
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <1455630825-27253-5-git-send-email-tn@semihalf.com>

There are two ways we can get ECAM (aka MCFG) regions using ACPI,
first from MCFG static table and second from _CBA method. We cannot remove
static regions, however regions coming from _CBA should be removed while
removing bridge device.

In the light of above we need flag to mark hot added ECAM entries
and user to call pci_mmconfig_insert while adding regions from _CBA method.
Similarly pci_mmconfig_delete while removing hot added regions.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/acpi/pci_mcfg.c  | 4 +++-
 include/linux/pci-acpi.h | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index 0467b00..3282f2a 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -74,6 +74,7 @@ static struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
 	new->segment = segment;
 	new->start_bus = start;
 	new->end_bus = end;
+	new->hot_added = false;
 
 	res = &new->res;
 	res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
@@ -205,6 +206,7 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
 	}
 	rc = pci_mmconfig_map_resource(dev, cfg);
 	if (!rc) {
+		cfg->hot_added = true;
 		list_add_sorted(cfg);
 		dev_info(dev, "MMCONFIG at %pR (base %#lx)\n",
 				 &cfg->res, (unsigned long)addr);
@@ -228,7 +230,7 @@ int pci_mmconfig_delete(u16 seg, u8 start, u8 end)
 	mutex_lock(&pci_mmcfg_lock);
 	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
 		if (cfg->segment == seg && cfg->start_bus == start &&
-		    cfg->end_bus == end) {
+		    cfg->end_bus == end && cfg->hot_added) {
 			list_del_rcu(&cfg->list);
 			synchronize_rcu();
 			pci_mmconfig_unmap_resource(cfg);
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index e9450ef..94d8f38 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -119,6 +119,7 @@ struct pci_mmcfg_region {
 	u8 start_bus;
 	u8 end_bus;
 	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
+	bool hot_added;
 };
 
 extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
-- 
1.9.1



From tn at semihalf.com  Tue Feb 16 05:53:33 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:33 +0100
Subject: [PATCH V5 03/15] arm64,
 acpi: Use MCFG library and empty PCI config space accessors from
 pci_mcfg.c file.
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <1455630825-27253-4-git-send-email-tn@semihalf.com>

We can now enable MCFG library. Currently, there is no ARM64 use case for
RAW pci config accessors, so lets use empty ones for now.
At the same time, we can cleanup the old implementation of RAW accessors
from arch/arm64/kernel/pci.c

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 arch/arm64/Kconfig      |  4 ++++
 arch/arm64/kernel/pci.c | 15 ---------------
 2 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc6228..552e996 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -238,6 +238,10 @@ source "drivers/pci/Kconfig"
 source "drivers/pci/pcie/Kconfig"
 source "drivers/pci/hotplug/Kconfig"
 
+config PCI_MMCONFIG
+	def_bool y
+	depends on ACPI
+
 endmenu
 
 menu "Kernel Features"
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index b3d098b..023b983 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -61,21 +61,6 @@ int pcibios_add_device(struct pci_dev *dev)
 	return 0;
 }
 
-/*
- * raw_pci_read/write - Platform-specific PCI config space access.
- */
-int raw_pci_read(unsigned int domain, unsigned int bus,
-		  unsigned int devfn, int reg, int len, u32 *val)
-{
-	return -ENXIO;
-}
-
-int raw_pci_write(unsigned int domain, unsigned int bus,
-		unsigned int devfn, int reg, int len, u32 val)
-{
-	return -ENXIO;
-}
-
 #ifdef CONFIG_ACPI
 /* Root bridge scanning */
 struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
-- 
1.9.1



From tn at semihalf.com  Tue Feb 16 05:53:35 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:35 +0100
Subject: [PATCH V5 05/15] x86,
 pci: Cleanup platform specific MCFG data by using ECAM hot_added flag.
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <1455630825-27253-6-git-send-email-tn@semihalf.com>

x86 uses lots of arch-specific data to maintain MCFG regions.
However, there is no need to. Firstly, information like start_bus, end_bus
can be obtained from acpi_pci_root structure. Secondly, mcfg_added flag
is already integrated to MCFG library, so it is enough to call functions
pci_mmconfig_insert and pci_mmconfig_delete which are handling
hot-plugged MCFG regions internally.

This patch implements above improvements, as a results we get
much smaller pci_root_info structure.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 arch/x86/pci/acpi.c | 30 ++++++++----------------------
 1 file changed, 8 insertions(+), 22 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index cec68e7..081dc70 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -11,11 +11,6 @@
 struct pci_root_info {
 	struct acpi_pci_root_info common;
 	struct pci_sysdata sd;
-#ifdef	CONFIG_PCI_MMCONFIG
-	bool mcfg_added;
-	u8 start_bus;
-	u8 end_bus;
-#endif
 };
 
 static bool pci_use_crs = true;
@@ -179,16 +174,13 @@ static int check_segment(u16 seg, struct device *dev, char *estr)
 
 static int setup_mcfg_map(struct acpi_pci_root_info *ci)
 {
-	int result, seg;
-	struct pci_root_info *info;
+	int result, seg, start, end;
 	struct acpi_pci_root *root = ci->root;
 	struct device *dev = &ci->bridge->dev;
 
-	info = container_of(ci, struct pci_root_info, common);
-	info->start_bus = (u8)root->secondary.start;
-	info->end_bus = (u8)root->secondary.end;
-	info->mcfg_added = false;
-	seg = info->sd.domain;
+	seg = root->segment;
+	start = root->secondary.start;
+	end = root->secondary.end;
 
 	/* return success if MMCFG is not in use */
 	if (raw_pci_ext_ops && raw_pci_ext_ops != &pci_mmcfg)
@@ -197,13 +189,11 @@ static int setup_mcfg_map(struct acpi_pci_root_info *ci)
 	if (!(pci_probe & PCI_PROBE_MMCONF))
 		return check_segment(seg, dev, "MMCONFIG is disabled,");
 
-	result = pci_mmconfig_insert(dev, seg, info->start_bus, info->end_bus,
-				     root->mcfg_addr);
+	result = pci_mmconfig_insert(dev, seg, start, end, root->mcfg_addr);
 	if (result == 0) {
 		/* enable MMCFG if it hasn't been enabled yet */
 		if (raw_pci_ext_ops == NULL)
 			raw_pci_ext_ops = &pci_mmcfg;
-		info->mcfg_added = true;
 	} else if (result != -EEXIST)
 		return check_segment(seg, dev,
 			 "fail to add MMCONFIG information,");
@@ -213,14 +203,10 @@ static int setup_mcfg_map(struct acpi_pci_root_info *ci)
 
 static void teardown_mcfg_map(struct acpi_pci_root_info *ci)
 {
-	struct pci_root_info *info;
+	struct acpi_pci_root *root = ci->root;
 
-	info = container_of(ci, struct pci_root_info, common);
-	if (info->mcfg_added) {
-		pci_mmconfig_delete(info->sd.domain,
-				    info->start_bus, info->end_bus);
-		info->mcfg_added = false;
-	}
+	pci_mmconfig_delete(root->segment, root->secondary.start,
+			    root->secondary.end);
 }
 #else
 static int setup_mcfg_map(struct acpi_pci_root_info *ci)
-- 
1.9.1



From tn at semihalf.com  Tue Feb 16 05:53:37 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:37 +0100
Subject: [PATCH V5 07/15] pci,
 acpi: Provide generic way to assign bus domain number.
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <1455630825-27253-8-git-send-email-tn@semihalf.com>

As we now have valid PCI host bridge device reference we can
introduce code that is going to find its bus domain number using
ACPI _SEG method.

Note that _SEG method is optional, therefore _SEG absence means
that all PCI buses belong to domain 0.

While at it, for the sake of code clarity we put ACPI and DT domain
assign methods into the corresponding helpers.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Reviewed-by: Liviu Dudau <Liviu.Dudau at arm.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/acpi/pci_root.c  | 18 ++++++++++++++++++
 drivers/pci/pci.c        | 11 +++++++++--
 include/linux/pci-acpi.h |  2 ++
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index c2bd6dd..3b284dc 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -419,6 +419,24 @@ out:
 }
 EXPORT_SYMBOL(acpi_pci_osc_control_set);
 
+int acpi_pci_bus_domain_nr(struct device *parent)
+{
+	struct acpi_device *acpi_dev = to_acpi_device(parent);
+	unsigned long long segment = 0;
+	acpi_status status;
+
+	/*
+	 * If _SEG method does not exist, following ACPI spec (6.5.6)
+	 * all PCI buses belong to domain 0.
+	 */
+	status = acpi_evaluate_integer(acpi_dev->handle, METHOD_NAME__SEG, NULL,
+				       &segment);
+	if (ACPI_FAILURE(status) && status != AE_NOT_FOUND)
+		dev_err(&acpi_dev->dev, "can't evaluate _SEG\n");
+
+	return segment;
+}
+
 static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm)
 {
 	u32 support, control, requested;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 602eb42..d6c768e 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -19,6 +19,7 @@
 #include <linux/spinlock.h>
 #include <linux/string.h>
 #include <linux/log2.h>
+#include <linux/pci-acpi.h>
 #include <linux/pci-aspm.h>
 #include <linux/pm_wakeup.h>
 #include <linux/interrupt.h>
@@ -4769,7 +4770,7 @@ int pci_get_new_domain_nr(void)
 }
 
 #ifdef CONFIG_PCI_DOMAINS_GENERIC
-void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
+static int of_pci_bus_domain_nr(struct device *parent)
 {
 	static int use_dt_domains = -1;
 	int domain = of_get_pci_domain_nr(parent->of_node);
@@ -4811,7 +4812,13 @@ void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
 		domain = -1;
 	}
 
-	bus->domain_nr = domain;
+	return domain;
+}
+
+void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
+{
+	bus->domain_nr = acpi_disabled ? of_pci_bus_domain_nr(parent) :
+					 acpi_pci_bus_domain_nr(parent);
 }
 #endif
 #endif
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index 94d8f38..b4f87ba9 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -22,6 +22,7 @@ static inline acpi_status pci_acpi_remove_pm_notifier(struct acpi_device *dev)
 {
 	return acpi_remove_pm_notifier(dev);
 }
+extern int acpi_pci_bus_domain_nr(struct device *parent);
 extern phys_addr_t acpi_pci_root_get_mcfg_addr(acpi_handle handle);
 
 static inline acpi_handle acpi_find_root_bridge_handle(struct pci_dev *pdev)
@@ -143,6 +144,7 @@ extern struct list_head pci_mmcfg_list;
 #else	/* CONFIG_ACPI */
 static inline void acpi_pci_add_bus(struct pci_bus *bus) { }
 static inline void acpi_pci_remove_bus(struct pci_bus *bus) { }
+static inline int acpi_pci_bus_domain_nr(struct device *parent) { return -1; }
 #endif	/* CONFIG_ACPI */
 
 #ifdef CONFIG_ACPI_APEI
-- 
1.9.1



From tn at semihalf.com  Tue Feb 16 05:53:36 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:36 +0100
Subject: [PATCH V5 06/15] pci, acpi, x86,
 ia64: Move ACPI host bridge device companion assignment to core code.
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <1455630825-27253-7-git-send-email-tn@semihalf.com>

Currently we have two platforms (x86 & ia64) capable of PCI ACPI host
bridge initialization. They both use arch-specific sysdata to pass down
parent device reference and both rely on NULL parent in pci_create_root_bus()
to validate sysdata content.

It looks hacky and prevents us from getting some firmware specific
info for PCI host controller based on its acpi_device structure
in generic pci_create_root_bus() function. However, we overcome that
blocker by passing down parent device via pci_create_root_bus parameter
(as the ACPI device type). Then we use ACPI_COMPANION_SET in core code
for ACPI boot method only. ACPI_COMPANION_SET is safe to run for all
cases DT, ACPI and DT&ACPI.

Since now PCI core code is setting ACPI companion device for us,
x86 & ia64 specific ACPI companion device setting turns out to be dead now.
We can get rid of it, including related companion reference from
PCI sysdata structure. Aslo, PCI_CONTROLLER macro cannot return valid
companion device anymore. Therefore we need to convert its usage to
ACPI_COMPANION.

Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 arch/ia64/hp/common/sba_iommu.c    |  2 +-
 arch/ia64/include/asm/pci.h        |  1 -
 arch/ia64/pci/pci.c                | 16 ----------------
 arch/ia64/sn/kernel/io_acpi_init.c |  4 ++--
 arch/x86/include/asm/pci.h         |  3 ---
 arch/x86/pci/acpi.c                | 17 -----------------
 drivers/acpi/pci_root.c            |  8 +++++++-
 drivers/pci/probe.c                |  2 ++
 8 files changed, 12 insertions(+), 41 deletions(-)

diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index a6d6190..78e4444 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -1981,7 +1981,7 @@ sba_connect_bus(struct pci_bus *bus)
 	if (PCI_CONTROLLER(bus)->iommu)
 		return;
 
-	handle = acpi_device_handle(PCI_CONTROLLER(bus)->companion);
+	handle = acpi_device_handle(ACPI_COMPANION(bus->bridge));
 	if (!handle)
 		return;
 
diff --git a/arch/ia64/include/asm/pci.h b/arch/ia64/include/asm/pci.h
index 07039d1..5050748 100644
--- a/arch/ia64/include/asm/pci.h
+++ b/arch/ia64/include/asm/pci.h
@@ -65,7 +65,6 @@ extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
 #define pci_legacy_write platform_pci_legacy_write
 
 struct pci_controller {
-	struct acpi_device *companion;
 	void *iommu;
 	int segment;
 	int node;		/* nearest node with memory or NUMA_NO_NODE for global allocation */
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 8f6ac2f..978d6af 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -301,28 +301,12 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
 	}
 
 	info->controller.segment = root->segment;
-	info->controller.companion = device;
 	info->controller.node = acpi_get_node(device->handle);
 	INIT_LIST_HEAD(&info->io_resources);
 	return acpi_pci_root_create(root, &pci_acpi_root_ops,
 				    &info->common, &info->controller);
 }
 
-int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
-{
-	/*
-	 * We pass NULL as parent to pci_create_root_bus(), so if it is not NULL
-	 * here, pci_create_root_bus() has been called by someone else and
-	 * sysdata is likely to be different from what we expect.  Let it go in
-	 * that case.
-	 */
-	if (!bridge->dev.parent) {
-		struct pci_controller *controller = bridge->bus->sysdata;
-		ACPI_COMPANION_SET(&bridge->dev, controller->companion);
-	}
-	return 0;
-}
-
 void pcibios_fixup_device_resources(struct pci_dev *dev)
 {
 	int idx;
diff --git a/arch/ia64/sn/kernel/io_acpi_init.c b/arch/ia64/sn/kernel/io_acpi_init.c
index 0640739..bcfddc2 100644
--- a/arch/ia64/sn/kernel/io_acpi_init.c
+++ b/arch/ia64/sn/kernel/io_acpi_init.c
@@ -132,7 +132,7 @@ sn_get_bussoft_ptr(struct pci_bus *bus)
 	struct acpi_resource_vendor_typed *vendor;
 
 
-	handle = acpi_device_handle(PCI_CONTROLLER(bus)->companion);
+	handle = acpi_device_handle(ACPI_COMPANION(bus->bridge));
 	status = acpi_get_vendor_resource(handle, METHOD_NAME__CRS,
 					  &sn_uuid, &buffer);
 	if (ACPI_FAILURE(status)) {
@@ -360,7 +360,7 @@ sn_acpi_get_pcidev_info(struct pci_dev *dev, struct pcidev_info **pcidev_info,
 	acpi_status status;
 	struct acpi_buffer name_buffer = { ACPI_ALLOCATE_BUFFER, NULL };
 
-	rootbus_handle = acpi_device_handle(PCI_CONTROLLER(dev)->companion);
+	rootbus_handle = acpi_device_handle(ACPI_COMPANION(dev->bus->bridge));
         status = acpi_evaluate_integer(rootbus_handle, METHOD_NAME__SEG, NULL,
                                        &segment);
         if (ACPI_SUCCESS(status)) {
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 4625943..a98c022 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -14,9 +14,6 @@
 struct pci_sysdata {
 	int		domain;		/* PCI domain */
 	int		node;		/* NUMA node */
-#ifdef CONFIG_ACPI
-	struct acpi_device *companion;	/* ACPI companion device */
-#endif
 #ifdef CONFIG_X86_64
 	void		*iommu;		/* IOMMU private data */
 #endif
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 081dc70..c67932e 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -334,7 +334,6 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
 		struct pci_sysdata sd = {
 			.domain = domain,
 			.node = node,
-			.companion = root->device
 		};
 
 		memcpy(bus->sysdata, &sd, sizeof(sd));
@@ -349,7 +348,6 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
 		else {
 			info->sd.domain = domain;
 			info->sd.node = node;
-			info->sd.companion = root->device;
 			bus = acpi_pci_root_create(root, &acpi_pci_root_ops,
 						   &info->common, &info->sd);
 		}
@@ -367,21 +365,6 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
 	return bus;
 }
 
-int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
-{
-	/*
-	 * We pass NULL as parent to pci_create_root_bus(), so if it is not NULL
-	 * here, pci_create_root_bus() has been called by someone else and
-	 * sysdata is likely to be different from what we expect.  Let it go in
-	 * that case.
-	 */
-	if (!bridge->dev.parent) {
-		struct pci_sysdata *sd = bridge->bus->sysdata;
-		ACPI_COMPANION_SET(&bridge->dev, sd->companion);
-	}
-	return 0;
-}
-
 int __init pci_acpi_init(void)
 {
 	struct pci_dev *dev = NULL;
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index ae3fe4e..c2bd6dd 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -846,7 +846,13 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
 
 	pci_acpi_root_add_resources(info);
 	pci_add_resource(&info->resources, &root->secondary);
-	bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
+
+	/*
+	 * pci_create_root_bus() needs to detect the parent device type,
+	 * so initialize its companion data accordingly.
+	 */
+	ACPI_COMPANION_SET(&device->dev, device);
+	bus = pci_create_root_bus(&device->dev, busnum, ops->pci_ops,
 				  sysdata, &info->resources);
 	if (!bus)
 		goto out_release_info;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 6d7ab9b..88a4734 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2100,6 +2100,8 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
 	bridge->dev.parent = parent;
 	bridge->dev.release = pci_release_host_bridge_dev;
 	dev_set_name(&bridge->dev, "pci%04x:%02x", pci_domain_nr(b), bus);
+	if (parent)
+		ACPI_COMPANION_SET(&bridge->dev, ACPI_COMPANION(parent));
 	error = pcibios_root_bridge_prepare(bridge);
 	if (error) {
 		kfree(bridge);
-- 
1.9.1



From tn at semihalf.com  Tue Feb 16 05:53:40 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:40 +0100
Subject: [PATCH V5 10/15] pci,
 of: Move the PCI I/O space management to PCI core code.
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <1455630825-27253-11-git-send-email-tn@semihalf.com>

No functional changes in this patch.

PCI I/O space mapping code does not depend on OF, therefore it can be
moved to PCI core code. This way we will be able to use it
e.g. in ACPI PCI code.

Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
CC: Arnd Bergmann <arnd at arndb.de>
CC: Liviu Dudau <Liviu.Dudau at arm.com>
CC: Lorenzo Pieralisi <Lorenzo.Pieralisi at arm.com>
---
 drivers/of/address.c       | 116 +--------------------------------------------
 drivers/pci/pci.c          | 115 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of_address.h |   9 ----
 include/linux/pci.h        |   5 ++
 4 files changed, 121 insertions(+), 124 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 91a469d..0a553c0 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -4,6 +4,7 @@
 #include <linux/ioport.h>
 #include <linux/module.h>
 #include <linux/of_address.h>
+#include <linux/pci.h>
 #include <linux/pci_regs.h>
 #include <linux/sizes.h>
 #include <linux/slab.h>
@@ -673,121 +674,6 @@ const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
 }
 EXPORT_SYMBOL(of_get_address);
 
-#ifdef PCI_IOBASE
-struct io_range {
-	struct list_head list;
-	phys_addr_t start;
-	resource_size_t size;
-};
-
-static LIST_HEAD(io_range_list);
-static DEFINE_SPINLOCK(io_range_lock);
-#endif
-
-/*
- * Record the PCI IO range (expressed as CPU physical address + size).
- * Return a negative value if an error has occured, zero otherwise
- */
-int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
-{
-	int err = 0;
-
-#ifdef PCI_IOBASE
-	struct io_range *range;
-	resource_size_t allocated_size = 0;
-
-	/* check if the range hasn't been previously recorded */
-	spin_lock(&io_range_lock);
-	list_for_each_entry(range, &io_range_list, list) {
-		if (addr >= range->start && addr + size <= range->start + size) {
-			/* range already registered, bail out */
-			goto end_register;
-		}
-		allocated_size += range->size;
-	}
-
-	/* range not registed yet, check for available space */
-	if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
-		/* if it's too big check if 64K space can be reserved */
-		if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
-			err = -E2BIG;
-			goto end_register;
-		}
-
-		size = SZ_64K;
-		pr_warn("Requested IO range too big, new size set to 64K\n");
-	}
-
-	/* add the range to the list */
-	range = kzalloc(sizeof(*range), GFP_ATOMIC);
-	if (!range) {
-		err = -ENOMEM;
-		goto end_register;
-	}
-
-	range->start = addr;
-	range->size = size;
-
-	list_add_tail(&range->list, &io_range_list);
-
-end_register:
-	spin_unlock(&io_range_lock);
-#endif
-
-	return err;
-}
-
-phys_addr_t pci_pio_to_address(unsigned long pio)
-{
-	phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
-
-#ifdef PCI_IOBASE
-	struct io_range *range;
-	resource_size_t allocated_size = 0;
-
-	if (pio > IO_SPACE_LIMIT)
-		return address;
-
-	spin_lock(&io_range_lock);
-	list_for_each_entry(range, &io_range_list, list) {
-		if (pio >= allocated_size && pio < allocated_size + range->size) {
-			address = range->start + pio - allocated_size;
-			break;
-		}
-		allocated_size += range->size;
-	}
-	spin_unlock(&io_range_lock);
-#endif
-
-	return address;
-}
-
-unsigned long __weak pci_address_to_pio(phys_addr_t address)
-{
-#ifdef PCI_IOBASE
-	struct io_range *res;
-	resource_size_t offset = 0;
-	unsigned long addr = -1;
-
-	spin_lock(&io_range_lock);
-	list_for_each_entry(res, &io_range_list, list) {
-		if (address >= res->start && address < res->start + res->size) {
-			addr = address - res->start + offset;
-			break;
-		}
-		offset += res->size;
-	}
-	spin_unlock(&io_range_lock);
-
-	return addr;
-#else
-	if (address > IO_SPACE_LIMIT)
-		return (unsigned long)-1;
-
-	return (unsigned long) address;
-#endif
-}
-
 static int __of_address_to_resource(struct device_node *dev,
 		const __be32 *addrp, u64 size, unsigned int flags,
 		const char *name, struct resource *r)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d6c768e..3a516c0 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3023,6 +3023,121 @@ int pci_request_regions_exclusive(struct pci_dev *pdev, const char *res_name)
 }
 EXPORT_SYMBOL(pci_request_regions_exclusive);
 
+#ifdef PCI_IOBASE
+struct io_range {
+	struct list_head list;
+	phys_addr_t start;
+	resource_size_t size;
+};
+
+static LIST_HEAD(io_range_list);
+static DEFINE_SPINLOCK(io_range_lock);
+#endif
+
+/*
+ * Record the PCI IO range (expressed as CPU physical address + size).
+ * Return a negative value if an error has occured, zero otherwise
+ */
+int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
+{
+	int err = 0;
+
+#ifdef PCI_IOBASE
+	struct io_range *range;
+	resource_size_t allocated_size = 0;
+
+	/* check if the range hasn't been previously recorded */
+	spin_lock(&io_range_lock);
+	list_for_each_entry(range, &io_range_list, list) {
+		if (addr >= range->start && addr + size <= range->start + size) {
+			/* range already registered, bail out */
+			goto end_register;
+		}
+		allocated_size += range->size;
+	}
+
+	/* range not registed yet, check for available space */
+	if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
+		/* if it's too big check if 64K space can be reserved */
+		if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
+			err = -E2BIG;
+			goto end_register;
+		}
+
+		size = SZ_64K;
+		pr_warn("Requested IO range too big, new size set to 64K\n");
+	}
+
+	/* add the range to the list */
+	range = kzalloc(sizeof(*range), GFP_ATOMIC);
+	if (!range) {
+		err = -ENOMEM;
+		goto end_register;
+	}
+
+	range->start = addr;
+	range->size = size;
+
+	list_add_tail(&range->list, &io_range_list);
+
+end_register:
+	spin_unlock(&io_range_lock);
+#endif
+
+	return err;
+}
+
+phys_addr_t pci_pio_to_address(unsigned long pio)
+{
+	phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
+
+#ifdef PCI_IOBASE
+	struct io_range *range;
+	resource_size_t allocated_size = 0;
+
+	if (pio > IO_SPACE_LIMIT)
+		return address;
+
+	spin_lock(&io_range_lock);
+	list_for_each_entry(range, &io_range_list, list) {
+		if (pio >= allocated_size && pio < allocated_size + range->size) {
+			address = range->start + pio - allocated_size;
+			break;
+		}
+		allocated_size += range->size;
+	}
+	spin_unlock(&io_range_lock);
+#endif
+
+	return address;
+}
+
+unsigned long __weak pci_address_to_pio(phys_addr_t address)
+{
+#ifdef PCI_IOBASE
+	struct io_range *res;
+	resource_size_t offset = 0;
+	unsigned long addr = -1;
+
+	spin_lock(&io_range_lock);
+	list_for_each_entry(res, &io_range_list, list) {
+		if (address >= res->start && address < res->start + res->size) {
+			addr = address - res->start + offset;
+			break;
+		}
+		offset += res->size;
+	}
+	spin_unlock(&io_range_lock);
+
+	return addr;
+#else
+	if (address > IO_SPACE_LIMIT)
+		return (unsigned long)-1;
+
+	return (unsigned long) address;
+#endif
+}
+
 /**
  *	pci_remap_iospace - Remap the memory mapped I/O space
  *	@res: Resource describing the I/O space
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 01c0a55..3786473 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -47,10 +47,6 @@ void __iomem *of_io_request_and_map(struct device_node *device,
 extern const __be32 *of_get_address(struct device_node *dev, int index,
 			   u64 *size, unsigned int *flags);
 
-extern int pci_register_io_range(phys_addr_t addr, resource_size_t size);
-extern unsigned long pci_address_to_pio(phys_addr_t addr);
-extern phys_addr_t pci_pio_to_address(unsigned long pio);
-
 extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
 			struct device_node *node);
 extern struct of_pci_range *of_pci_range_parser_one(
@@ -86,11 +82,6 @@ static inline const __be32 *of_get_address(struct device_node *dev, int index,
 	return NULL;
 }
 
-static inline phys_addr_t pci_pio_to_address(unsigned long pio)
-{
-	return 0;
-}
-
 static inline int of_pci_range_parser_init(struct of_pci_range_parser *parser,
 			struct device_node *node)
 {
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 27df4a6..dac677c 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1168,6 +1168,9 @@ int __must_check pci_bus_alloc_resource(struct pci_bus *bus,
 			void *alignf_data);
 
 
+int pci_register_io_range(phys_addr_t addr, resource_size_t size);
+unsigned long pci_address_to_pio(phys_addr_t addr);
+phys_addr_t pci_pio_to_address(unsigned long pio);
 int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
 
 static inline pci_bus_addr_t pci_bus_address(struct pci_dev *pdev, int bar)
@@ -1488,6 +1491,8 @@ static inline int pci_request_regions(struct pci_dev *dev, const char *res_name)
 { return -EIO; }
 static inline void pci_release_regions(struct pci_dev *dev) { }
 
+static inline unsigned long pci_address_to_pio(phys_addr_t addr) { return -1; }
+
 static inline void pci_block_cfg_access(struct pci_dev *dev) { }
 static inline int pci_block_cfg_access_in_atomic(struct pci_dev *dev)
 { return 0; }
-- 
1.9.1



From tn at semihalf.com  Tue Feb 16 05:53:41 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:41 +0100
Subject: [PATCH V5 11/15] drivers: pci: add generic code to claim bus resources
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <1455630825-27253-12-git-send-email-tn@semihalf.com>

From: Lorenzo Pieralisi <Lorenzo.Pieralisi at arm.com>

PCI core code contains a set of functions, eg:

pci_assign_unassigned_bus_resources()

that allow to assign the PCI resources for a given bus after
enumeration.

On systems where the PCI BARs are immutable (ie they must not and can
not be assigned), PCI resources must be claimed in order to be
validated and inserted in the PCI resources tree, but there is no generic
PCI kernel function for that purpose and the resource claiming is
implemented in an arch specific fashion which resulted in arches
implementations that contain duplicated code.

This patch, based on the ia64 resource claiming arch implementation,
implements a set of functions in core PCI code that provides a PCI core
interface for resources claiming for a given PCI bus hierarchy, paving
the way for further resource claiming consolidation across architectures.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Bjorn Helgaas <bhelgaas at google.com>
Cc: Yinghai Lu <yinghai at kernel.org>
---
 drivers/pci/setup-bus.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/pci.h     |  1 +
 2 files changed, 64 insertions(+)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 7796d0a..c959398 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1424,6 +1424,69 @@ void pci_bus_assign_resources(const struct pci_bus *bus)
 }
 EXPORT_SYMBOL(pci_bus_assign_resources);
 
+static void pci_claim_device_resources(struct pci_dev *dev)
+{
+	int i;
+
+	for (i = 0; i < PCI_BRIDGE_RESOURCES; i++) {
+		struct resource *r = &dev->resource[i];
+
+		if (!r->flags || r->parent)
+			continue;
+
+		pci_claim_resource(dev, i);
+	}
+}
+
+static void pci_claim_bridge_resources(struct pci_dev *dev)
+{
+	int i;
+
+	for (i = PCI_BRIDGE_RESOURCES; i < PCI_NUM_RESOURCES; i++) {
+		struct resource *r = &dev->resource[i];
+
+		if (!r->flags || r->parent)
+			continue;
+
+		pci_claim_bridge_resource(dev, i);
+	}
+}
+
+static void pci_bus_allocate_dev_resources(struct pci_bus *b)
+{
+	struct pci_dev *dev;
+	struct pci_bus *child;
+
+	list_for_each_entry(dev, &b->devices, bus_list) {
+		pci_claim_device_resources(dev);
+
+		child = dev->subordinate;
+		if (child)
+			pci_bus_allocate_dev_resources(child);
+	}
+}
+
+static void pci_bus_allocate_resources(struct pci_bus *b)
+{
+	struct pci_bus *child;
+
+	/* Depth-First Search on bus tree */
+	if (b->self) {
+		pci_read_bridge_bases(b);
+		pci_claim_bridge_resources(b->self);
+	}
+
+	list_for_each_entry(child, &b->children, node)
+		pci_bus_allocate_resources(child);
+}
+
+void pci_bus_claim_resources(struct pci_bus *b)
+{
+	pci_bus_allocate_resources(b);
+	pci_bus_allocate_dev_resources(b);
+}
+EXPORT_SYMBOL(pci_bus_claim_resources);
+
 static void __pci_bridge_assign_resources(const struct pci_dev *bridge,
 					  struct list_head *add_head,
 					  struct list_head *fail_head)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index dac677c..6faf994 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1119,6 +1119,7 @@ ssize_t pci_write_vpd(struct pci_dev *dev, loff_t pos, size_t count, const void
 /* Helper functions for low-level code (drivers/pci/setup-[bus,res].c) */
 resource_size_t pcibios_retrieve_fw_addr(struct pci_dev *dev, int idx);
 void pci_bus_assign_resources(const struct pci_bus *bus);
+void pci_bus_claim_resources(struct pci_bus *bus);
 void pci_bus_size_bridges(struct pci_bus *bus);
 int pci_claim_resource(struct pci_dev *, int);
 int pci_claim_bridge_resource(struct pci_dev *bridge, int i);
-- 
1.9.1



From tn at semihalf.com  Tue Feb 16 05:53:39 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:39 +0100
Subject: [PATCH V5 09/15] acpi,
 mcfg: Add default PCI config accessors implementation and initial
 support for related quirks.
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <1455630825-27253-10-git-send-email-tn@semihalf.com>

We use generic accessors from access.c by default. However, we already
know platforms that need special handling while accessing to PCI config
space. These platforms will need different accessors set matched against
platform ID, domain, bus touple. Therefore we are going to add (in future)
DECLARE_ACPI_MCFG_FIXUP which will register platform specific custom
accessors. For now, we let pci_mcfg_get_ops to take acpi_pci_root structure
as an arguments and left some space for quirk matching algorithm.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/acpi/pci_mcfg.c  | 30 ++++++++++++++++++++++++++++++
 include/linux/pci-acpi.h | 12 ++++++++++++
 2 files changed, 42 insertions(+)

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index 3282f2a..0062257 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -41,6 +41,36 @@ int __weak raw_pci_write(unsigned int domain, unsigned int bus,
 	return PCIBIOS_DEVICE_NOT_FOUND;
 }
 
+void __iomem *
+pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
+{
+	struct pci_mmcfg_region *cfg;
+
+	cfg = pci_mmconfig_lookup(pci_domain_nr(bus), bus->number);
+	if (cfg && cfg->virt)
+		return cfg->virt +
+			(PCI_MMCFG_BUS_OFFSET(bus->number) | (devfn << 12)) +
+			offset;
+	return NULL;
+}
+
+/* Default generic PCI config accessors */
+static struct pci_ops default_pci_mcfg_ops = {
+	.map_bus = pci_mcfg_dev_base,
+	.read = pci_generic_config_read,
+	.write = pci_generic_config_write,
+};
+
+struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
+{
+	/*
+	 * TODO: Match against platform specific quirks and return
+	 * corresponding PCI config space accessor set.
+	 */
+
+	return &default_pci_mcfg_ops;
+}
+
 static void list_add_sorted(struct pci_mmcfg_region *new)
 {
 	struct pci_mmcfg_region *cfg;
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index b4f87ba9..3dc6a8c 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -141,6 +141,18 @@ extern struct list_head pci_mmcfg_list;
 #define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
 #define PCI_MMCFG_OFFSET(bus, devfn)   ((bus) << 20 | (devfn) << 12)
 
+#ifdef	CONFIG_PCI_MMCONFIG
+extern struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
+extern void __iomem *pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn,
+				       int offset);
+#else
+static inline struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
+{ return NULL; }
+static inline void __iomem *pci_mcfg_dev_base(struct pci_bus *bus,
+					      unsigned int devfn, int offset)
+{ return NULL; }
+#endif
+
 #else	/* CONFIG_ACPI */
 static inline void acpi_pci_add_bus(struct pci_bus *bus) { }
 static inline void acpi_pci_remove_bus(struct pci_bus *bus) { }
-- 
1.9.1



From tn at semihalf.com  Tue Feb 16 05:53:38 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:38 +0100
Subject: [PATCH V5 08/15] x86,
 ia64: Include acpi_pci_{add|remove}_bus to the default
 pcibios_{add|remove}_bus implementation.
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <1455630825-27253-9-git-send-email-tn@semihalf.com>

x86 and ia64 are the only arches that implement pcibios_{add|remove}_bus hooks
and implement them in the same way. Moreover ARM64 is going to do the same.
So it seems that acpi_pci_{add|remove}_bus is generic enough to be default
option for pcibios_{add|remove}_bus hooks. Also, it is always safe to run
acpi_pci_{add|remove}_bus as they have empty stubs for !ACPI case and
return if ACPI has been switched off in run time.

After all we can remove x86 and ia64 pcibios_{add|remove}_bus
implementation.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 arch/ia64/pci/pci.c   | 10 ----------
 arch/x86/pci/common.c | 10 ----------
 drivers/pci/probe.c   |  3 +++
 3 files changed, 3 insertions(+), 20 deletions(-)

diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 978d6af..be4c9ef 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -358,16 +358,6 @@ void pcibios_fixup_bus(struct pci_bus *b)
 	platform_pci_fixup_bus(b);
 }
 
-void pcibios_add_bus(struct pci_bus *bus)
-{
-	acpi_pci_add_bus(bus);
-}
-
-void pcibios_remove_bus(struct pci_bus *bus)
-{
-	acpi_pci_remove_bus(bus);
-}
-
 void pcibios_set_master (struct pci_dev *dev)
 {
 	/* No special bus mastering setup handling */
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 2879efc..5aa25f1 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -171,16 +171,6 @@ void pcibios_fixup_bus(struct pci_bus *b)
 		pcibios_fixup_device_resources(dev);
 }
 
-void pcibios_add_bus(struct pci_bus *bus)
-{
-	acpi_pci_add_bus(bus);
-}
-
-void pcibios_remove_bus(struct pci_bus *bus)
-{
-	acpi_pci_remove_bus(bus);
-}
-
 /*
  * Only use DMI information to set this if nothing was passed
  * on the kernel command line (which was parsed earlier).
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 88a4734..9859b12 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -12,6 +12,7 @@
 #include <linux/slab.h>
 #include <linux/module.h>
 #include <linux/cpumask.h>
+#include <linux/pci-acpi.h>
 #include <linux/pci-aspm.h>
 #include <linux/aer.h>
 #include <linux/acpi.h>
@@ -2060,10 +2061,12 @@ int __weak pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
 
 void __weak pcibios_add_bus(struct pci_bus *bus)
 {
+	acpi_pci_add_bus(bus);
 }
 
 void __weak pcibios_remove_bus(struct pci_bus *bus)
 {
+	acpi_pci_remove_bus(bus);
 }
 
 struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
-- 
1.9.1



From tn at semihalf.com  Tue Feb 16 05:53:44 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:44 +0100
Subject: [PATCH V5 14/15] arm64, pci,
 acpi: Assign legacy IRQs once device is enable.
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <1455630825-27253-15-git-send-email-tn@semihalf.com>

This is the last step before enabling generic ACPI PCI host controller
for ARM64. We need to take care of legacy IRQ mapping for non-MSI(X)
PCI devices. pcibios_alloc_irq() evaluation is not sensitive to
ACPI device enumeration order, so it is the best place to assign
device's IRQs for ACPI boot method. Also, it does not hurt DT to be
initialized form the same place.

NOTE: *This is going to be temporary solution*. There is ongoing work
which aims for cleaning legacy IRQ allocation from arch specific code.
We can consider this patch as the necessary evil which will be removed
once cleanup series lands in mailnline in the near future.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm64/kernel/pci.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 023b983..6e77e1b 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -52,11 +52,16 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
 }
 
 /*
- * Try to assign the IRQ number from DT when adding a new device
+ * Try to assign the IRQ number when probing a new device
  */
-int pcibios_add_device(struct pci_dev *dev)
+int pcibios_alloc_irq(struct pci_dev *dev)
 {
-	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
+	if (acpi_disabled)
+		dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
+#ifdef CONFIG_ACPI
+	else
+		return acpi_pci_irq_enable(dev);
+#endif
 
 	return 0;
 }
-- 
1.9.1



From tn at semihalf.com  Tue Feb 16 05:53:42 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:42 +0100
Subject: [PATCH V5 12/15] pci,
 acpi: Support for ACPI based generic PCI host controller
 initialization
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <1455630825-27253-13-git-send-email-tn@semihalf.com>

This patch is going to implement generic PCI host controller for
ACPI world, similar to what pci-host-generic.c driver does for DT world.

All such drivers, which we have seen so far, were implemented within
arch/ directory since they had some arch assumptions (x86 and ia64).
However, they all are doing similar thing, so it makes sense to find
some common code and abstract it into the generic driver.

This driver aims to initialize PCI host controller without architecture
assumptions. It uses MCFG library to manage PCI config space regions properly.
Also, it parses _CRS content to find out host bridge's resources (i.e. MEM/IO).
As mentioned in Kconfig help section, ACPI_PCI_HOST_GENERIC choice should be
made on a per-architecture basis.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Signed-off-by: Lorenzo Pieralisi <Lorenzo.Pieralisi at arm.com>
TO: Bjorn Helgaas <helgaas at kernel.org>
TO: Rafael J. Wysocki <rafael at kernel.org>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Tested-by: Jeremy Linton <jeremy.linton at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/acpi/Kconfig     |   7 +++
 drivers/acpi/pci_root.c  | 128 +++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/pci-acpi.h |  10 ++--
 3 files changed, 141 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 183ffa3..1c7f57bd 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -346,6 +346,13 @@ config ACPI_PCI_SLOT
 	  i.e., segment/bus/device/function tuples, with physical slots in
 	  the system.  If you are unsure, say N.
 
+config ACPI_PCI_HOST_GENERIC
+	bool
+	help
+	  Select this config option from the architecture Kconfig,
+	  if it is preferred to enable ACPI PCI host controller driver which
+	  has no arch-specific assumptions.
+
 config X86_PM_TIMER
 	bool "Power Management Timer Support" if EXPERT
 	depends on X86
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 3b284dc..02fd690 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -532,6 +532,134 @@ static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm)
 	}
 }
 
+#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
+static int pci_acpi_setup_mcfg_map(struct acpi_pci_root_info *ci)
+{
+	struct acpi_pci_root *root = ci->root;
+	int ret;
+
+	ret = pci_mmconfig_insert(&ci->bridge->dev, root->segment,
+				   root->secondary.start, root->secondary.end,
+				   root->mcfg_addr);
+	if (ret == -EEXIST)
+		ret = 0;
+
+	return ret;
+}
+
+static void pci_acpi_teardown_mcfg_map(struct acpi_pci_root_info *ci)
+{
+	struct acpi_pci_root *root = ci->root;
+
+	pci_mmconfig_delete(root->segment, root->secondary.start,
+			    root->secondary.end);
+	kfree(ci);
+}
+
+static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
+{
+	struct list_head *list = &ci->resources;
+	struct acpi_device *device = ci->bridge;
+	struct resource_entry *entry, *tmp;
+	unsigned long flags;
+	int ret;
+
+	flags = IORESOURCE_IO | IORESOURCE_MEM;
+	ret = acpi_dev_get_resources(device, list,
+				     acpi_dev_filter_resource_type_cb,
+				     (void *)flags);
+	if (ret < 0) {
+		dev_warn(&device->dev,
+			 "failed to parse _CRS method, error code %d\n", ret);
+		return ret;
+	} else if (ret == 0)
+		dev_dbg(&device->dev,
+			"no IO and memory resources present in _CRS\n");
+
+	resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
+		struct resource *res = entry->res;
+
+		if (entry->res->flags & IORESOURCE_DISABLED)
+			resource_list_destroy_entry(entry);
+		else
+			res->name = ci->name;
+
+		if (res->flags & IORESOURCE_IO) {
+			resource_size_t cpu_addr = res->start;
+			resource_size_t pci_addr = cpu_addr - entry->offset;
+			resource_size_t length = resource_size(res);
+			unsigned long port;
+
+			if (pci_register_io_range(cpu_addr, length)) {
+				resource_list_destroy_entry(entry);
+				continue;
+			}
+
+			port = pci_address_to_pio(cpu_addr);
+			if (port == (unsigned long)-1) {
+				resource_list_destroy_entry(entry);
+				continue;
+			}
+
+			res->start = port;
+			res->end = port + length - 1;
+			entry->offset = port - pci_addr;
+
+			if (pci_remap_iospace(res, cpu_addr) < 0)
+				resource_list_destroy_entry(entry);
+		}
+	}
+	return ret;
+}
+
+static struct acpi_pci_root_ops acpi_pci_root_ops = {
+	.init_info = pci_acpi_setup_mcfg_map,
+	.release_info = pci_acpi_teardown_mcfg_map,
+	.prepare_resources = pci_acpi_root_prepare_resources,
+};
+
+/* Root bridge scanning */
+struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
+{
+	int node = acpi_get_node(root->device->handle);
+	int domain = root->segment;
+	int busnum = root->secondary.start;
+	struct acpi_pci_root_info *info;
+	struct pci_bus *bus, *child;
+
+	if (domain && !pci_domains_supported) {
+		pr_warn("PCI %04x:%02x: multiple domains not supported.\n",
+			domain, busnum);
+		return NULL;
+	}
+
+	info = kzalloc_node(sizeof(*info), GFP_KERNEL, node);
+	if (!info) {
+		dev_err(&root->device->dev,
+			"pci_bus %04x:%02x: ignored (out of memory)\n",
+			domain, busnum);
+		return NULL;
+	}
+
+	acpi_pci_root_ops.pci_ops = pci_mcfg_get_ops(root);
+	bus = acpi_pci_root_create(root, &acpi_pci_root_ops, info, root);
+	if (!bus)
+		return NULL;
+
+	pci_bus_claim_resources(bus);
+	pci_assign_unassigned_bus_resources(bus);
+
+	/*
+	 * After the PCI-E bus has been walked and all devices discovered,
+	 * configure any settings of the fabric that might be necessary.
+	 */
+	list_for_each_entry(child, &bus->children, node)
+		pcie_bus_configure_settings(child);
+
+	return bus;
+}
+#endif /* CONFIG_ACPI_PCI_HOST_GENERIC */
+
 static int acpi_pci_root_add(struct acpi_device *device,
 			     const struct acpi_device_id *not_used)
 {
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index 3dc6a8c..93feb04 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -123,10 +123,6 @@ struct pci_mmcfg_region {
 	bool hot_added;
 };
 
-extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
-			       phys_addr_t addr);
-extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
-
 extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
 extern struct pci_mmcfg_region *pci_mmconfig_add(int segment, int start,
 							int end, u64 addr);
@@ -142,10 +138,16 @@ extern struct list_head pci_mmcfg_list;
 #define PCI_MMCFG_OFFSET(bus, devfn)   ((bus) << 20 | (devfn) << 12)
 
 #ifdef	CONFIG_PCI_MMCONFIG
+extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
+			       phys_addr_t addr);
+extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
 extern struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
 extern void __iomem *pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn,
 				       int offset);
 #else
+static inline int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start,
+				      u8 end, phys_addr_t addr) { return 0; }
+static inline int pci_mmconfig_delete(u16 seg, u8 start, u8 end) { return 0; }
 static inline struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
 { return NULL; }
 static inline void __iomem *pci_mcfg_dev_base(struct pci_bus *bus,
-- 
1.9.1



From tn at semihalf.com  Tue Feb 16 05:53:43 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:43 +0100
Subject: [PATCH V5 13/15] pci,
 acpi: Match PCI config space accessors against platfrom specific
 quirks.
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <1455630825-27253-14-git-send-email-tn@semihalf.com>

Some platforms may not be fully compliant with generic set of PCI config
accessors. For these cases we implement the way to overwrite accessors
set prior to PCI buses enumeration. Algorithm traverses available quirk
list, matches against <platform ID (DMI), domain, bus number> tuple and
returns corresponding accessors. All quirks can be defined using:
DECLARE_ACPI_MCFG_FIXUP() and kept self contained. Example,

static const struct dmi_system_id foo_dmi[] = {
        {
                .ident = "<Platform ident string>",
                .callback = <handler>,
                .matches = {
                        DMI_MATCH(DMI_SYS_VENDOR, "<system vendor>"),
                        DMI_MATCH(DMI_PRODUCT_NAME, "<product name>"),
                        DMI_MATCH(DMI_PRODUCT_VERSION, "product version"),
                },
        },
        { }
};

static struct pci_ops foo_ecam_pci_ops = {
        .map_bus = pci_mcfg_dev_base,
        .read = foo_ecam_config_read,
        .write = foo_ecam_config_write,
};
DECLARE_ACPI_MCFG_FIXUP(foo_dmi, NULL, &foo_ecam_pci_ops, <domain_nr>, <bus_nr>);

More custom (non-DMI) matching can be done via an extra call.
Note that there is possibility to assign quirk related private data to
root->sysdata which will be available along read/wriate accessor, example:

static int boo_match(struct pci_mcfg_fixup *fixup, struct acpi_pci_root *root)
{
        return [condition] ? 1 : 0;
}

int boo_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
                          int where, int size, u32 *val)
{
        struct acpi_pci_root *root = bus->sysdata;
        struct boo_priv_data *boo_data = root->sysdata;

        [..]
}

static struct pci_ops boo_ecam_pci_ops = {
	.map_bus = pci_mcfg_dev_base,
	.read = boo_ecam_config_read,
	.write = boo_ecam_config_write,
};
DECLARE_ACPI_MCFG_FIXUP(NULL, boo_match, &boo_ecam_pci_ops, <domain_nr>, <bus_nr>);

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 drivers/acpi/pci_mcfg.c           | 32 ++++++++++++++++++++++++++++++--
 include/acpi/acpi_bus.h           |  1 +
 include/asm-generic/vmlinux.lds.h |  7 +++++++
 include/linux/pci-acpi.h          | 18 ++++++++++++++++++
 4 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index 0062257..b343547 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -41,6 +41,29 @@ int __weak raw_pci_write(unsigned int domain, unsigned int bus,
 	return PCIBIOS_DEVICE_NOT_FOUND;
 }
 
+extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
+
+static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root *root)
+{
+	struct pci_mcfg_fixup *f;
+	int bus_num = root->secondary.start;
+	int domain = root->segment;
+
+	/*
+	 * First match against PCI topology <domain:bus> then use DMI or
+	 * custom match handler.
+	 */
+	for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
+		if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
+		    (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
+		    (f->system ? dmi_check_system(f->system) : 1 &&
+		     f->match ? f->match(f, root) : 1))
+			return f->ops;
+	}
+	return NULL;
+}
+
 void __iomem *
 pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
 {
@@ -63,10 +86,15 @@ static struct pci_ops default_pci_mcfg_ops = {
 
 struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
 {
+	struct pci_ops *pci_mcfg_ops_quirk;
+
 	/*
-	 * TODO: Match against platform specific quirks and return
-	 * corresponding PCI config space accessor set.
+	 * Match against platform specific quirks and return corresponding
+	 * PCI config space accessor set.
 	 */
+	pci_mcfg_ops_quirk = pci_mcfg_check_quirks(root);
+	if (pci_mcfg_ops_quirk)
+		return pci_mcfg_ops_quirk;
 
 	return &default_pci_mcfg_ops;
 }
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 14362a8..0fc6f13 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -556,6 +556,7 @@ struct acpi_pci_root {
 	struct pci_bus *bus;
 	u16 segment;
 	struct resource secondary;	/* downstream bus range */
+	void *sysdata;
 
 	u32 osc_support_set;	/* _OSC state of support bits */
 	u32 osc_control_set;	/* _OSC state of control bits */
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index c4bd0e2..c93fc97 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -298,6 +298,13 @@
 		VMLINUX_SYMBOL(__end_pci_fixups_suspend_late) = .;	\
 	}								\
 									\
+	/* ACPI MCFG quirks */						\
+	.acpi_fixup        : AT(ADDR(.acpi_fixup) - LOAD_OFFSET) {	\
+		VMLINUX_SYMBOL(__start_acpi_mcfg_fixups) = .;		\
+		*(.acpi_fixup_mcfg)					\
+		VMLINUX_SYMBOL(__end_acpi_mcfg_fixups) = .;		\
+	}								\
+									\
 	/* Built-in firmware blobs */					\
 	.builtin_fw        : AT(ADDR(.builtin_fw) - LOAD_OFFSET) {	\
 		VMLINUX_SYMBOL(__start_builtin_fw) = .;			\
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index 93feb04..9e1bedd 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -123,6 +123,24 @@ struct pci_mmcfg_region {
 	bool hot_added;
 };
 
+struct pci_mcfg_fixup {
+	const struct dmi_system_id *system;
+	int (*match)(struct pci_mcfg_fixup *, struct acpi_pci_root *);
+	struct pci_ops *ops;
+	int domain;
+	int bus_num;
+};
+
+#define PCI_MCFG_DOMAIN_ANY	-1
+#define PCI_MCFG_BUS_ANY	-1
+
+/* Designate a routine to fix up buggy MCFG */
+#define DECLARE_ACPI_MCFG_FIXUP(system, match, ops, dom, bus)		\
+	static const struct pci_mcfg_fixup __mcfg_fixup_##system##dom##bus\
+	 __used	__attribute__((__section__(".acpi_fixup_mcfg"),		\
+				aligned((sizeof(void *))))) =		\
+	{ system, match, ops, dom, bus };
+
 extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
 extern struct pci_mmcfg_region *pci_mmconfig_add(int segment, int start,
 							int end, u64 addr);
-- 
1.9.1



From tn at semihalf.com  Tue Feb 16 05:53:45 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Tue, 16 Feb 2016 14:53:45 +0100
Subject: [PATCH V5 15/15] arm64, pci,
 acpi: Start using ACPI based PCI host bridge driver for ARM64.
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <1455630825-27253-16-git-send-email-tn@semihalf.com>

It is perfectly fine to use ACPI_PCI_HOST_GENERIC for ARM64,
so lets get rid of PCI init empty stub, related ACPI header and
go with full-blown PCI host controller driver.

Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
TO: Catalin Marinas <catalin.marinas at arm.com>
TO: Lorenzo Pieralisi <Lorenzo.Pieralisi at arm.com>
TO: Will Deacon <will.deacon at arm.com>
TO: Arnd Bergmann <arnd at arndb.de>
CC: Liviu Dudau <Liviu.Dudau at arm.com>
Tested-by: Duc Dang <dhdang at apm.com>
Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Sinan Kaya <okaya at codeaurora.org>
---
 arch/arm64/Kconfig      | 1 +
 arch/arm64/kernel/pci.c | 9 ---------
 2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 552e996..09c49ea 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2,6 +2,7 @@ config ARM64
 	def_bool y
 	select ACPI_CCA_REQUIRED if ACPI
 	select ACPI_GENERIC_GSI if ACPI
+	select ACPI_PCI_HOST_GENERIC if ACPI
 	select ACPI_REDUCED_HARDWARE_ONLY if ACPI
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 6e77e1b..1de0168 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -65,12 +65,3 @@ int pcibios_alloc_irq(struct pci_dev *dev)
 
 	return 0;
 }
-
-#ifdef CONFIG_ACPI
-/* Root bridge scanning */
-struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
-{
-	/* TODO: Should be revisited when implementing PCI on ACPI */
-	return NULL;
-}
-#endif
-- 
1.9.1



From arnd at arndb.de  Tue Feb 16 05:55:43 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 14:55:43 +0100
Subject: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
In-Reply-To: <m34md8rdol.fsf@t19.piap.pl>
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <2702068.KRp0Bplb5Q@wuerfel> <m34md8rdol.fsf@t19.piap.pl>
Message-ID: <3062977.Ya2ztQYFaM@wuerfel>

On Tuesday 16 February 2016 14:24:10 Krzysztof Ha?asa wrote:
> Arnd Bergmann <arnd at arndb.de> writes:
> 
> > Both writes leave the CPU core within the spinlock but are not serialized
> > with anything else, so there is no ordering between the CPUs when they
> > enter the shared bus, other than having address before data. You'd
> > expect to see address0, data0, address1, data1, but it could also
> > be e.g. address0, address1, data1, data0.
> 
> Ah, so it's a matter of flushing the write buffers before exiting the
> spinlock-protected code.

Yes, whatever the specific architecture requires. The normal readl()
functions are documented to having all the required barriers and
flushes, the __raw_* variants may (e.g. on x86) or may not have that.

> > The point is more what the common case is. Almost all machines we support
> > have fixed-endian devices, and the drivers are correct when using readl()
> > or in_le32() but are not endian-safe when using __raw_readl().
> 
> Sure, e.g. PCI does it this way (eventually swapping the data lanes if
> needed).
> 
> > Using __raw_readl() has the big danger of someone accidentally "fixing"
> > the driver to work like all the others in order to solve a theoretical
> > endian problem, while it should really be made obvious that the hardware
> > actively swaps its data on the bus.
> 
> Sure - if this is the case. On-chip IXP4xx peripherals don't swap data
> at all (i.e., they match CPU endianess) - accessing their registers is
> like accessing a normal CPU register. That's why they don't use
> PCI-style readl() etc. - however a better name than __raw_* would
> probably help here.
> 
> Using __raw_* in a PCI driver would be generally wrong.

I was really talking about built-in devices here. There are other platforms
that have an internal byteswap logic on the bus interface and they also
use that for PCI, see e.g. arch/sh/include/mach-common/mach/mangle-port.h.

ixp4xx is really special in that it performs hardware swapping for
internal devices based on CPU endianess but not on PCI devices.

I think some Broadcom MIPS systems are in the same category as IXP4xx,
but only because they have an extra byteswap on the PCI bus that they
can turn on, but very few other systems are.

Coming back to the specific pxa25x_udc case: using __raw_* accessors
in the driver would possibly end up breaking the PXA25x machines in
the (very unlikely) case that someone wants to make it work with
big-endian kernels, assuming it does not have the same hardware
byteswap logic as ixp4xx.

	Arnd


From javier at osg.samsung.com  Tue Feb 16 05:58:20 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Tue, 16 Feb 2016 10:58:20 -0300
Subject: [PATCH] ARM: dts: Move syscon reboot/poweroff to common dtsi for
 Exynos
In-Reply-To: <56C25982.4020301@samsung.com>
References: <1455042606-10075-1-git-send-email-javier@osg.samsung.com>
 <56C02265.40103@samsung.com> <56C1D4D1.2050108@osg.samsung.com>
 <56C25982.4020301@samsung.com>
Message-ID: <56C32AFC.6030905@osg.samsung.com>

Hello Krzysztof,

On 02/15/2016 08:04 PM, Krzysztof Kozlowski wrote:
> On 15.02.2016 22:38, Javier Martinez Canillas wrote:
>>>
>>> In some of the DTSI this was under "soc" node, not at top-level.
>>> Unfortunately we do not have consistency here - some DTSI have "soc",
>>
>> Yes, I noticed this but as you said not all DTSI have a soc node
>> and that's why I made it top level in the DTSI.
>>
>>> some not. Anyway I think we should move to "soc" version.
>>>
>>
>> Not sure I'm following, did you mean to do it as a follow up or
>> to add a soc node for the missing DTSI as a part of this series?
>
> I meant to send a v2 with this under "soc" node even though on some DTS
> we do not have the "soc". Optional follow up would be to make DTS
> consistent and move nodes under "soc"... but that would be also a lot of
> churn.
>

Thanks for the clarification. I'll post a v2 then moving under a soc node.
  
> Best regards,
> Krzysztof

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America


From andy.shevchenko at gmail.com  Tue Feb 16 06:00:20 2016
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Tue, 16 Feb 2016 16:00:20 +0200
Subject: [PATCH v3 05/10] serial: mps2-uart: add support for early console
In-Reply-To: <56C32641.4020201@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-6-git-send-email-vladimir.murzin@arm.com>
 <CAHp75VdugAq0WnzLHmd9CJHCjBOdBwPqCmC3ARSaVF5XMYGoMw@mail.gmail.com>
 <56C31F9F.10000@arm.com>
 <CAHp75Vf_4MgdWunQy5hBMH5GGei+OkktFPYY-ZprY0qOEnD=wA@mail.gmail.com>
 <56C32641.4020201@arm.com>
Message-ID: <CAHp75VecjR3sBcGmRHFwZPwUjXhPwV-2z4hYYJ7Y+iCOxi8_EA@mail.gmail.com>

On Tue, Feb 16, 2016 at 3:38 PM, Vladimir Murzin
<vladimir.murzin at arm.com> wrote:
> On 16/02/16 13:13, Andy Shevchenko wrote:
>> On Tue, Feb 16, 2016 at 3:09 PM, Vladimir Murzin
>> <vladimir.murzin at arm.com> wrote:
>>> On 16/02/16 10:36, Andy Shevchenko wrote:
>>>> On Tue, Feb 16, 2016 at 12:08 PM, Vladimir Murzin
>>>> <vladimir.murzin at arm.com> wrote:

>>>>> +static void mps2_early_putchar(struct uart_port *port, int ch)
>>>>> +{
>>>>> +
>>>>> +       while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
>>>>> +               cpu_relax();
>>>>
>>>> Infinite busy loop?
>>>
>>> In case of broken hw, yes, but I'm quite unsure how we can help to fix
>>> it. Do you have something in mind?
>>
>> Set sane amount of loops like
>>
>> int count = 100;
>> ?
>> while (? && --count)
>>
>> Though I have no idea what to do if count == 0. Perhaps it's a TX overrun state.
>
> I thought about counter too, like some of drivers do, but had no idea
> what to do next after counter reaches zero. In case of TX overrun we
> could get it either because of broken hw or because we entered Linux
> with that state already set. In both cases, it looks handy to me to
> attach a debugger and see that we are spinning in this putchar loop.
>
> If you do insist to have a counter I'll add one, but if you are not
> strong about it I'd prefer to leave it as is.

I would wait for Peter Hurley, Alan, or other experienced guys to talk.

>> You may try to recover by flushing TX queue in HW (fifo and / or Tx
>> shift register) if HW supports it.
>>
>
> I'm afraid this is not supported.

Maybe soft reset? Anyway, see above.

-- 
With Best Regards,
Andy Shevchenko


From joro at 8bytes.org  Tue Feb 16 06:11:00 2016
From: joro at 8bytes.org (Joerg Roedel)
Date: Tue, 16 Feb 2016 15:11:00 +0100
Subject: [PATCH v8 3/5] memory: mediatek: Add SMI driver
In-Reply-To: <56ADE959.2050309@gmail.com>
References: <1453781562-23556-1-git-send-email-yong.wu@mediatek.com>
 <1453781562-23556-4-git-send-email-yong.wu@mediatek.com>
 <56ADE959.2050309@gmail.com>
Message-ID: <20160216141059.GT18805@8bytes.org>

On Sun, Jan 31, 2016 at 12:00:41PM +0100, Matthias Brugger wrote:
> 
> 
> On 26/01/16 05:12, Yong Wu wrote:
> >This patch add SMI(Smart Multimedia Interface) driver. This driver
> >is responsible to enable/disable iommu and control the power domain
> >and clocks of each local arbiter.
> >
> >Signed-off-by: Yong Wu <yong.wu at mediatek.com>
> >Tested-by: Philipp Zabel <p.zabel at pengutronix.de>
> >---
> 
> Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
> 
> Joerg would you mind to take this through your branch?

Hmm, I somehow missed the patch-set, at least I can't find the v8
patches in my inbox.

Yong, can you please re-send with all Acks and other tags added?


Thanks,

	Joerg



From mark.rutland at arm.com  Tue Feb 16 06:12:59 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 16 Feb 2016 14:12:59 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <56C31D1D.50708@virtuozzo.com>
References: <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com>
Message-ID: <20160216141258.GA8022@leverpostej>

On Tue, Feb 16, 2016 at 03:59:09PM +0300, Andrey Ryabinin wrote:
> 
> On 02/15/2016 09:59 PM, Catalin Marinas wrote:
> > On Mon, Feb 15, 2016 at 05:28:02PM +0300, Andrey Ryabinin wrote:
> >> On 02/12/2016 07:06 PM, Catalin Marinas wrote:
> >>> So far, we have:
> >>>
> >>> KASAN+for-next/kernmap goes wrong
> >>> KASAN+UBSAN goes wrong
> >>>
> >>> Enabled individually, KASAN, UBSAN and for-next/kernmap seem fine. I may
> >>> have to trim for-next/core down until we figure out where the problem
> >>> is.
> >>>
> >>> BUG: KASAN: stack-out-of-bounds in find_busiest_group+0x164/0x16a0 at addr ffffffc93665bc8c
> >>
> >> Can it be related to TLB conflicts, which supposed to be fixed in
> >> "arm64: kasan: avoid TLB conflicts" patch from "arm64: mm: rework page
> >> table creation" series ?
> > 
> > I can very easily reproduce this with a vanilla 4.5-rc1 series by
> > enabling inline instrumentation (maybe Mark's theory is true w.r.t.
> > image size).
> > 
> > Some information, maybe you can shed some light on this. It seems to
> > happen only for secondary CPUs on the swapper stack (I think allocated
> > via fork_idle()). The code generated looks sane to me, so KASAN should
> > not complain but maybe there is some uninitialised shadow, hence the
> > error.
> > 
> > The report:
> >
> 
> Actually, the first report is a bit more useful. It shows that shadow memory was corrupted:
> 
>   ffffffc93665bc00: f1 f1 f1 f1 00 f4 f4 f4 f2 f2 f2 f2 00 00 f1 f1
> > ffffffc93665bc80: f1 f1 00 00 00 00 f3 f3 00 f4 f4 f4 f3 f3 f3 f3
>                       ^
> F1 - left redzone, it indicates start of stack frame
> F3 - right redzone, it should be the end of stack frame.
> 
> But here we have the second set of F1s without F3s which should close the first set of F1s.
> Also those two F3s in the middle cannot be right.
> 
> So shadow is corrupted.
> Some hypotheses:
> 
> 1) We share stack between several tasks (e.g. stack overflow, somehow corrupted SP).
>     But this probably should cause kernel crash later, after kasan reports.
> 
> 2) Shadow memory wasn't cleared. GCC poison memory on function entrance and unpoisons it before return.
>      If we use some tricky way to exit from function this could cause false-positives like that.
>      E.g. some hand-written assembly return code.
> 
> 3) Screwed shadow mapping. I think the patch below should uncover such problem.
> It boot-tested on qemu and didn't show any problem

With that path applied I get:

[    0.000000] kasan: screwed shadow mapping 62184, 62182
[    0.000000] kasan: KernelAddressSanitizer initialized

I'm using v4.5-rc1 with KASAN_INLINE, and a random collection of debug options
to bloat the kernel per prior theory that the text size had somethign to do
with the issue.

Later in the boot process I see lots of failures like:

[   13.292190] ==================================================================
[   13.299543] BUG: KASAN: stack-out-of-bounds in find_busiest_group+0x1950/0x19b8 at addr ffffffc936ad3c8c
[   13.309090] Read of size 4 by task swapper/3/0
[   13.313575] page:ffffffbde6dab4c0 count:0 mapcount:0 mapping:          (null) index:0x0
[   13.321657] flags: 0x4000000000000000()
[   13.325539] page dumped because: kasan: bad access detected
[   13.331150] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.5.0-rc1+ #19
[   13.337528] Hardware name: ARM Juno development board (r1) (DT)
[   13.343471] Call trace:
[   13.345978] [<ffffffc000091400>] dump_backtrace+0x0/0x3c0
[   13.351416] [<ffffffc0000917e4>] show_stack+0x24/0x30
[   13.356507] [<ffffffc0008c3a64>] dump_stack+0xc4/0x150
[   13.361685] [<ffffffc0004032bc>] kasan_report_error+0x52c/0x558
[   13.367640] [<ffffffc0004033fc>] __asan_report_load4_noabort+0x54/0x60
[   13.374200] [<ffffffc0001a46e8>] find_busiest_group+0x1950/0x19b8
[   13.380327] [<ffffffc0001a49ec>] load_balance+0x29c/0x19e0
[   13.385851] [<ffffffc0001a67c0>] pick_next_task_fair+0x690/0xd88
[   13.391896] [<ffffffc001213cf4>] __schedule+0x85c/0x13c8
[   13.397248] [<ffffffc001214d7c>] schedule+0xe4/0x228
[   13.402256] [<ffffffc00121549c>] schedule_preempt_disabled+0x24/0xb8
[   13.408642] [<ffffffc0001b97f8>] cpu_startup_entry+0x188/0x738
[   13.414511] [<ffffffc00009bcfc>] secondary_start_kernel+0x244/0x2b8
[   13.420806] [<0000000080082efc>] 0x80082efc
[   13.425023] Memory state around the buggy address:
[   13.429854]  ffffffc936ad3b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   13.437153]  ffffffc936ad3c00: 00 00 00 00 00 00 f1 f1 f1 f1 f1 f1 00 00 f3 f3
[   13.444451] >ffffffc936ad3c80: f3 f3 00 00 00 00 00 00 00 f4 f4 f4 f3 f3 f3 f3
[   13.451742]                       ^
[   13.455274]  ffffffc936ad3d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   13.462572]  ffffffc936ad3d80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
[   13.469863] ==================================================================

I guess memroy layout has something to do with this. FWIW on this board my
memory map comes from EFI:

[    0.000000] Processing EFI memory map:
[    0.000000]   0x000008000000-0x00000bffffff [Memory Mapped I/O  |RUN|  |XP|  |  |  |   |  |  |  |UC]
[    0.000000]   0x00001c170000-0x00001c170fff [Memory Mapped I/O  |RUN|  |XP|  |  |  |   |  |  |  |UC]
[    0.000000]   0x000080000000-0x00008000ffff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x000080010000-0x00008007ffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x000080080000-0x000081dbffff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x000081dc0000-0x00009fdfffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x00009fe00000-0x00009fe0ffff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x00009fe10000-0x0000dfffffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000e00f0000-0x0000f5a58fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000f5a59000-0x0000f7793fff [Loader Code        |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000f7794000-0x0000f9431fff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000f9432000-0x0000f944ffff [Loader Code        |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000f9450000-0x0000f945ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000f9460000-0x0000f94dffff [ACPI Reclaim Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000f94e0000-0x0000f94effff [ACPI Memory NVS    |   |  |  |  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000f94f0000-0x0000f94fffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000f9500000-0x0000f950ffff [Runtime Code       |RUN|  |  |  |  |RO|   |WB|WT|WC|UC]*
[    0.000000]   0x0000f9510000-0x0000f953ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000f9540000-0x0000f954ffff [Runtime Code       |RUN|  |  |  |  |RO|   |WB|WT|WC|UC]*
[    0.000000]   0x0000f9550000-0x0000f956ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000f9570000-0x0000f958ffff [ACPI Reclaim Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000f9590000-0x0000f960ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000f9610000-0x0000f961ffff [Runtime Code       |RUN|  |  |  |  |RO|   |WB|WT|WC|UC]*
[    0.000000]   0x0000f9620000-0x0000f96effff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000f96f0000-0x0000f96fffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000f9700000-0x0000f970ffff [Runtime Code       |RUN|  |  |  |  |RO|   |WB|WT|WC|UC]*
[    0.000000]   0x0000f9710000-0x0000f974ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000f9750000-0x0000f975ffff [Runtime Code       |RUN|  |  |  |  |RO|   |WB|WT|WC|UC]*
[    0.000000]   0x0000f9760000-0x0000f97cffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000f97d0000-0x0000f97dffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000f97e0000-0x0000f97effff [Runtime Code       |RUN|  |  |  |  |RO|   |WB|WT|WC|UC]*
[    0.000000]   0x0000f97f0000-0x0000f981ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000f9820000-0x0000f9820fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000f9821000-0x0000f9827fff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000f9828000-0x0000f982bfff [Reserved           |   |  |  |  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000f982c000-0x0000fdaedfff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fdaee000-0x0000fdfbefff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fdfbf000-0x0000fdfbffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fdfc0000-0x0000fdffbfff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fdffc000-0x0000fe018fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe019000-0x0000fe020fff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe021000-0x0000fe022fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe023000-0x0000fe02bfff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe02c000-0x0000fe03afff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe03b000-0x0000fe03dfff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe03e000-0x0000fe04efff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe04f000-0x0000fe057fff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe058000-0x0000fe073fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe074000-0x0000fe074fff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe075000-0x0000fe078fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe079000-0x0000fe07bfff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe07c000-0x0000fe07dfff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe07e000-0x0000fe085fff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe086000-0x0000fe087fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe088000-0x0000fe171fff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe172000-0x0000fe198fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe199000-0x0000fe65ffff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe660000-0x0000fe6a2fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe6a3000-0x0000fe7effff [Boot Code          |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe7f0000-0x0000fe7fffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000fe800000-0x0000fe80ffff [Runtime Code       |RUN|  |  |  |  |RO|   |WB|WT|WC|UC]*
[    0.000000]   0x0000fe810000-0x0000fe82ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000fe830000-0x0000fe83ffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe840000-0x0000fe88ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
[    0.000000]   0x0000fe890000-0x0000fe891fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x0000fe892000-0x0000feffffff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x000880000000-0x00099bffffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
[    0.000000]   0x00099c000000-0x0009ffffffff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]

Thanks,
Mark.


From m.szyprowski at samsung.com  Tue Feb 16 06:14:25 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 16 Feb 2016 15:14:25 +0100
Subject: [PATCH] ARM64: dma-mapping: fix IOMMU-based dma_mmap_atts()
 implementation
Message-ID: <1455632065-14620-1-git-send-email-m.szyprowski@samsung.com>

IOMMU-based DMA-mapping implementation doesn't support
dma_declare_coherent() based regions, so there is no point to call
dma_mmap_from_coherent() from __iommu_mmap_atts(). This patch removes
useless code.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 arch/arm64/mm/dma-mapping.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 331c4ca..573b1e6 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -636,14 +636,9 @@ static int __iommu_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
 			      struct dma_attrs *attrs)
 {
 	struct vm_struct *area;
-	int ret;
 
 	vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot,
 					     is_device_dma_coherent(dev));
-
-	if (dma_mmap_from_coherent(dev, vma, cpu_addr, size, &ret))
-		return ret;
-
 	area = find_vm_area(cpu_addr);
 	if (WARN_ON(!area || !area->pages))
 		return -ENXIO;
-- 
1.9.2



From m.szyprowski at samsung.com  Tue Feb 16 06:14:44 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 16 Feb 2016 15:14:44 +0100
Subject: [PATCH] ARM64: dma-mapping: fix handling of devices registered before
 arch_initcall
Message-ID: <1455632084-14666-1-git-send-email-m.szyprowski@samsung.com>

This patch ensures that devices, which got registered before arch_initcall
will be handled correctly by IOMMU-based DMA-mapping code.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 arch/arm64/mm/dma-mapping.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 573b1e6..ce6019f 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -928,6 +928,10 @@ static int __init __iommu_dma_init(void)
 		ret = register_iommu_dma_ops_notifier(&platform_bus_type);
 	if (!ret)
 		ret = register_iommu_dma_ops_notifier(&amba_bustype);
+
+	/* handle devices queued before this arch_initcall */
+	if (!ret)
+		__iommu_attach_notifier(NULL, BUS_NOTIFY_ADD_DEVICE, NULL);
 	return ret;
 }
 arch_initcall(__iommu_dma_init);
-- 
1.9.2



From andre.przywara at arm.com  Tue Feb 16 06:16:19 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Tue, 16 Feb 2016 14:16:19 +0000
Subject: [RFC PATCH] (broken) implementation of A64 MMC delay calibration
Message-ID: <1455632179-8102-1-git-send-email-andre.przywara@arm.com>

Hi,

as people were asking for it, here is my first attempt on proper
Allwinner A64 MMC support.
Former Allwinner MMC implementations used a special MMC clock, where
two clocks could be phase-offset-ed to match the timing requirements.
Those clocks have vanished, instead the phase seems to be now created
internally in the MMC blob using some new registers. Also there is an
auto-calibration feature with should help us to get the right values.

This patch is a naive implementation by just looking at the manual.
Unfortunately it does not work: The first calibration loop seems to
work, but returns all 1's as the result, which sounds suspicious.
The second calibration loop hangs (which reminds me of adding a
timeout):
[ 4.187144] sunxi_mmc: starting sample delay calibration
[ 4.192306] calibrate 0x144: register reads as 0x2000
[ 4.201770] calibrate 0x144: tried 16 times, reg=0x7f00
[ 4.206976] sunxi-mmc: delay for register 0x144: 63
[ 4.211665] calibrate 0x144: writing: 0x7fbf
[ 4.216353] sunxi_mmc: starting data strobe delay calibration
[ 4.221865] calibrate 0x148: register reads as 0x2000
(hang)

I didn't have time (and courage) yet to take a closer look at the BSP
kernel, but it seems like they don't use this feature for some reason?

Also my knowledge of MMC is very limited, so I might be missing
something obvious. Do we need to setup this other register
(SMHC Drive Delay Control Register at 0x0140) as well or are the
default settings good enough?

I am posting this so that other people can have a look or use it as
a base for own experiments.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>

---
 drivers/mmc/host/sunxi-mmc.c | 103 +++++++++++++++++++++++++++++++++----------
 1 file changed, 79 insertions(+), 24 deletions(-)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 8372a41..0c81a4d 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -71,6 +71,8 @@
 #define SDXC_REG_IDIE	(0x8C) /* SMC IDMAC Interrupt Enable Register */
 #define SDXC_REG_CHDA	(0x90)
 #define SDXC_REG_CBDA	(0x94)
+#define SDXC_REG_SAMP_DL_REG	0x144	/* SMC sample delay control */
+#define SDXC_REG_DS_DL_REG	0x148	/* SMC data strobe delay control */
 
 #define mmc_readl(host, reg) \
 	readl((host)->reg_base + SDXC_##reg)
@@ -217,6 +219,13 @@
 #define SDXC_CLK_50M_DDR	3
 #define SDXC_CLK_50M_DDR_8BIT	4
 
+#define SDXC_CAL_START		BIT(15)
+#define SDXC_CAL_DONE		BIT(14)
+#define SDXC_CAL_DL_SHIFT	8
+#define SDXC_CAL_DL_SW_EN	BIT(7)
+#define SDXC_CAL_DL_SW_SHIFT	0
+#define SDXC_CAL_DL_MASK	0x3f
+
 struct sunxi_mmc_clk_delay {
 	u32 output;
 	u32 sample;
@@ -261,6 +270,9 @@ struct sunxi_mmc_host {
 
 	/* vqmmc */
 	bool		vqmmc_enabled;
+
+	/* does the IP block support autocalibration? */
+	bool		can_calibrate;
 };
 
 static int sunxi_mmc_reset_host(struct sunxi_mmc_host *host)
@@ -653,10 +665,62 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
 	return 0;
 }
 
+static int sunxi_mmc_calibrate(struct sunxi_mmc_host *host,
+			       struct mmc_ios *ios, int reg_off)
+{
+	u32 reg = readl(host->reg_base + reg_off);
+	u32 delay;
+
+	reg &= ~(SDXC_CAL_DL_MASK << SDXC_CAL_DL_SW_SHIFT);
+	reg &= ~SDXC_CAL_DL_SW_EN;
+
+	writel(reg | SDXC_CAL_START, host->reg_base + reg_off);
+
+	while (!((reg = readl(host->reg_base + reg_off)) & SDXC_CAL_DONE))
+		cpu_relax();
+
+	delay = (reg >> SDXC_CAL_DL_SHIFT) & SDXC_CAL_DL_MASK;
+
+	reg &= ~SDXC_CAL_START;
+	reg |= (delay << SDXC_CAL_DL_SW_SHIFT) | SDXC_CAL_DL_SW_EN;
+
+	writel(reg, host->reg_base + reg_off);
+
+	return 0;
+}
+
+static int sunxi_mmc_determine_delays(struct sunxi_mmc_host *host,
+				      struct mmc_ios *ios, int rate)
+{
+	int index;
+
+	if (rate <= 400000) {
+		index = SDXC_CLK_400K;
+	} else if (rate <= 25000000) {
+		index = SDXC_CLK_25M;
+	} else if (rate <= 52000000) {
+		if (ios->timing != MMC_TIMING_UHS_DDR50 &&
+		    ios->timing != MMC_TIMING_MMC_DDR52) {
+			index = SDXC_CLK_50M;
+		} else if (ios->bus_width == MMC_BUS_WIDTH_8) {
+			index = SDXC_CLK_50M_DDR_8BIT;
+		} else {
+			index = SDXC_CLK_50M_DDR;
+		}
+	} else {
+		return -EINVAL;
+	}
+
+	clk_set_phase(host->clk_sample, host->clk_delays[index].sample);
+	clk_set_phase(host->clk_output, host->clk_delays[index].output);
+
+	return 0;
+}
+
 static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
 				  struct mmc_ios *ios)
 {
-	u32 rate, oclk_dly, rval, sclk_dly;
+	u32 rate, rval;
 	u32 clock = ios->clock;
 	int ret;
 
@@ -692,32 +756,20 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
 	}
 	mmc_writel(host, REG_CLKCR, rval);
 
-	/* determine delays */
-	if (rate <= 400000) {
-		oclk_dly = host->clk_delays[SDXC_CLK_400K].output;
-		sclk_dly = host->clk_delays[SDXC_CLK_400K].sample;
-	} else if (rate <= 25000000) {
-		oclk_dly = host->clk_delays[SDXC_CLK_25M].output;
-		sclk_dly = host->clk_delays[SDXC_CLK_25M].sample;
-	} else if (rate <= 52000000) {
-		if (ios->timing != MMC_TIMING_UHS_DDR50 &&
-		    ios->timing != MMC_TIMING_MMC_DDR52) {
-			oclk_dly = host->clk_delays[SDXC_CLK_50M].output;
-			sclk_dly = host->clk_delays[SDXC_CLK_50M].sample;
-		} else if (ios->bus_width == MMC_BUS_WIDTH_8) {
-			oclk_dly = host->clk_delays[SDXC_CLK_50M_DDR_8BIT].output;
-			sclk_dly = host->clk_delays[SDXC_CLK_50M_DDR_8BIT].sample;
-		} else {
-			oclk_dly = host->clk_delays[SDXC_CLK_50M_DDR].output;
-			sclk_dly = host->clk_delays[SDXC_CLK_50M_DDR].sample;
-		}
+	if (host->can_calibrate) {
+		ret = sunxi_mmc_calibrate(host, ios, SDXC_REG_SAMP_DL_REG);
+		if (ret)
+			return ret;
+
+		ret = sunxi_mmc_calibrate(host, ios, SDXC_REG_DS_DL_REG);
+		if (ret)
+			return ret;
 	} else {
-		return -EINVAL;
+		ret = sunxi_mmc_determine_delays(host, ios, rate);
+		if (ret)
+			return ret;
 	}
 
-	clk_set_phase(host->clk_sample, sclk_dly);
-	clk_set_phase(host->clk_output, oclk_dly);
-
 	return sunxi_mmc_oclk_onoff(host, 1);
 }
 
@@ -990,6 +1042,9 @@ static int sunxi_mmc_resource_request(struct sunxi_mmc_host *host,
 	else
 		host->clk_delays = sunxi_mmc_clk_delays;
 
+	if (of_device_is_compatible(np, "allwinner,sun50i-a64-mmc"))
+		host->can_calibrate = true;
+
 	ret = mmc_regulator_get_supply(host->mmc);
 	if (ret) {
 		if (ret != -EPROBE_DEFER)
-- 
2.6.4



From lee.jones at linaro.org  Tue Feb 16 06:16:58 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 16 Feb 2016 14:16:58 +0000
Subject: [PATCH 0/3] ARM: stm32: Introduce support for STM32F469
Message-ID: <1455632221-31834-1-git-send-email-lee.jones@linaro.org>

Simple set using the STM32F429 infrastructure as a foundation.
There will be more changes to the DTS files and a requirement for
added hierarchical layering as more differences become apparent.

Lee Jones (3):
  ARM: stm32: Supply a DTS file for the STM32F469 Discovery board
  ARM: configs: Add new config fragment to change RAM start point
  ARM: stm32: Identify a new board - STM32F469

 arch/arm/boot/dts/Makefile              |  1 +
 arch/arm/boot/dts/stm32f469-disco.dts   | 75 +++++++++++++++++++++++++++++++++
 arch/arm/configs/dram_0x00000000.config |  1 +
 arch/arm/mach-stm32/board-dt.c          |  1 +
 4 files changed, 78 insertions(+)
 create mode 100644 arch/arm/boot/dts/stm32f469-disco.dts
 create mode 100644 arch/arm/configs/dram_0x00000000.config

-- 
1.9.1



From lee.jones at linaro.org  Tue Feb 16 06:16:59 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 16 Feb 2016 14:16:59 +0000
Subject: [PATCH 1/3] ARM: stm32: Supply a DTS file for the STM32F469 Discovery
 board
In-Reply-To: <1455632221-31834-1-git-send-email-lee.jones@linaro.org>
References: <1455632221-31834-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1455632221-31834-2-git-send-email-lee.jones@linaro.org>

It's pretty similar to the STM32F429, but there are some
subtle changes required to boot successfully.

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/boot/dts/Makefile            |  1 +
 arch/arm/boot/dts/stm32f469-disco.dts | 75 +++++++++++++++++++++++++++++++++++
 2 files changed, 76 insertions(+)
 create mode 100644 arch/arm/boot/dts/stm32f469-disco.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..c9d8023 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -583,6 +583,7 @@ dtb-$(CONFIG_ARCH_STI) += \
 	stih418-b2199.dtb
 dtb-$(CONFIG_ARCH_STM32)+= \
 	stm32f429-disco.dtb \
+	stm32f469-disco.dtb \
 	stm32429i-eval.dtb
 dtb-$(CONFIG_MACH_SUN4I) += \
 	sun4i-a10-a1000.dtb \
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
new file mode 100644
index 0000000..e911af8
--- /dev/null
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -0,0 +1,75 @@
+/*
+ * Copyright 2016 - Lee Jones <lee.jones at linaro.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this file; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "stm32f429.dtsi"
+
+/ {
+	model = "STMicroelectronics STM32F469i-DISCO board";
+	compatible = "st,stm32f469i-disco", "st,stm32f469";
+
+	chosen {
+		bootargs = "root=/dev/ram rdinit=/linuxrc";
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory {
+		reg = <0x00000000 0x800000>;
+	};
+
+	aliases {
+		serial0 = &usart3;
+	};
+};
+
+&clk_hse {
+	clock-frequency = <8000000>;
+};
+
+&usart3 {
+	status = "okay";
+};
-- 
1.9.1



From lee.jones at linaro.org  Tue Feb 16 06:17:00 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 16 Feb 2016 14:17:00 +0000
Subject: [PATCH 2/3] ARM: configs: Add new config fragment to change RAM start
 point
In-Reply-To: <1455632221-31834-1-git-send-email-lee.jones@linaro.org>
References: <1455632221-31834-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1455632221-31834-3-git-send-email-lee.jones@linaro.org>

Rather than duplicate a defconfig for each difference
between platforms, we can choose to pick a basic defconfig and
manipulate it at run-time using config fragments.  Here we're
adding a new fragment to over-ride the RAM start point to 0x0.

Cc: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/configs/dram_0x00000000.config | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 arch/arm/configs/dram_0x00000000.config

diff --git a/arch/arm/configs/dram_0x00000000.config b/arch/arm/configs/dram_0x00000000.config
new file mode 100644
index 0000000..db96dcb
--- /dev/null
+++ b/arch/arm/configs/dram_0x00000000.config
@@ -0,0 +1 @@
+CONFIG_DRAM_BASE=0x00000000
-- 
1.9.1



From lee.jones at linaro.org  Tue Feb 16 06:17:01 2016
From: lee.jones at linaro.org (Lee Jones)
Date: Tue, 16 Feb 2016 14:17:01 +0000
Subject: [PATCH 3/3] ARM: stm32: Identify a new board - STM32F469
In-Reply-To: <1455632221-31834-1-git-send-email-lee.jones@linaro.org>
References: <1455632221-31834-1-git-send-email-lee.jones@linaro.org>
Message-ID: <1455632221-31834-4-git-send-email-lee.jones@linaro.org>

Signed-off-by: Lee Jones <lee.jones at linaro.org>
---
 arch/arm/mach-stm32/board-dt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-stm32/board-dt.c b/arch/arm/mach-stm32/board-dt.c
index f2ad772..ceee477 100644
--- a/arch/arm/mach-stm32/board-dt.c
+++ b/arch/arm/mach-stm32/board-dt.c
@@ -10,6 +10,7 @@
 
 static const char *const stm32_compat[] __initconst = {
 	"st,stm32f429",
+	"st,stm32f469",
 	NULL
 };
 
-- 
1.9.1



From vladimir.murzin at arm.com  Tue Feb 16 06:25:47 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 14:25:47 +0000
Subject: [PATCH v3 04/10] serial: mps2-uart: add MPS2 UART driver
In-Reply-To: <CAHp75Vcx_xAY2A4XNgQ1ea_U5mUnD1+6=2FxCM3KzsRSpxgRuw@mail.gmail.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>	<1455617295-23736-5-git-send-email-vladimir.murzin@arm.com>
 <CAHp75Vcx_xAY2A4XNgQ1ea_U5mUnD1+6=2FxCM3KzsRSpxgRuw@mail.gmail.com>
Message-ID: <56C3316B.10205@arm.com>

On 16/02/16 10:48, Andy Shevchenko wrote:
> On Tue, Feb 16, 2016 at 12:08 PM, Vladimir Murzin
> <vladimir.murzin at arm.com> wrote:
>> This driver adds support to the UART controller found on ARM MPS2
>> platform.
> 
> 
>> +static irqreturn_t mps2_uart_oerrirq(int irq, void *data)
>> +{
>> +       irqreturn_t handled = IRQ_NONE;
>> +       struct uart_port *port = data;
>> +       u8 irqflag = mps2_uart_read8(port, UARTn_INT);
>> +
>> +       spin_lock(&port->lock);
>> +
>> +       if (irqflag & UARTn_INT_RX_OVERRUN) {
>> +               struct tty_port *tport = &port->state->port;
>> +
>> +               mps2_uart_write8(port, UARTn_INT_RX_OVERRUN, UARTn_INT);
>> +               tty_insert_flip_char(tport, 0, TTY_OVERRUN);
>> +               port->icount.overrun++;
>> +               handled = IRQ_HANDLED;
>> +       }
>> +
>> +       /*
>> +        * It's never been seen in practice and it never *should* happen since
>> +        * we check if there is enough room in TX buffer before sending data.
>> +        * So we keep this check in case something suspicious has happened.
>> +        */
>> +       if (irqflag & UARTn_INT_TX_OVERRUN) {
>> +               mps2_uart_write8(port, UARTn_INT_TX_OVERRUN, UARTn_INT);
> 
>> +               dev_warn(port->dev, "unexpected overrun interrupt\n");
> 
> I'm not sure there is no dead lock if this happens on the same port
> which is used as console.

Right, doesn't look like a good idea...

> 
>> +               handled = IRQ_HANDLED;
>> +       }
>> +
>> +       spin_unlock(&port->lock);
>> +
>> +       return handled;
>> +}
>> +
>> +static int mps2_uart_startup(struct uart_port *port)
>> +{
>> +       struct mps2_uart_port *mps_port = to_mps2_port(port);
>> +       u8 control = mps2_uart_read8(port, UARTn_CTRL);
>> +       int ret;
>> +
>> +       control &= ~(UARTn_CTRL_RX_GRP | UARTn_CTRL_TX_GRP);
>> +
>> +       mps2_uart_write8(port, control, UARTn_CTRL);
>> +
>> +       ret = request_irq(mps_port->rx_irq, mps2_uart_rxirq, 0,
>> +                         MAKE_NAME(-rx), mps_port);
>> +       if (ret) {
>> +               dev_err(port->dev, "failed to register rxirq (%d)\n", ret);
>> +               goto err_no_rxirq;
> 
> It should be below, here just a plain return.
> 
>> +       }
>> +
>> +       ret = request_irq(mps_port->tx_irq, mps2_uart_txirq, 0,
>> +                         MAKE_NAME(-tx), mps_port);
>> +       if (ret) {
>> +               dev_err(port->dev, "failed to register txirq (%d)\n", ret);
>> +               goto err_no_txirq;
> 
> goto err_free_rxirq;
> 
>> +       }
>> +
>> +       ret = request_irq(port->irq, mps2_uart_oerrirq, IRQF_SHARED,
>> +                         MAKE_NAME(-overrun), mps_port);
>> +
>> +       if (ret) {
>> +               dev_err(port->dev, "failed to register oerrirq (%d)\n", ret);
> 
> Why not goto pattern here as well?
> 
> goto err_free_txirq;
> 
>> +       } else {
> 
> ?and remove this else.
> 
>> +               control |= UARTn_CTRL_RX_GRP | UARTn_CTRL_TX_GRP;
>> +
>> +               mps2_uart_write8(port, control, UARTn_CTRL);
>> +
>> +               return 0;
>> +       }
>> +
>> +       free_irq(mps_port->tx_irq, mps_port);
>> +err_no_txirq:
>> +       free_irq(mps_port->rx_irq, mps_port);
>> +err_no_rxirq:
>> +       return ret;
>> +}
> 

Ok. Will rework that.

> 
>> +static struct mps2_uart_port mps2_uart_ports[MPS2_MAX_PORTS];
>> +
>> +#ifdef CONFIG_SERIAL_MPS2_UART_CONSOLE
>> +static void mps2_uart_console_putchar(struct uart_port *port, int ch)
>> +{
>> +       while (mps2_uart_read8(port, UARTn_STATE) & UARTn_STATE_TX_FULL)
>> +               cpu_relax();
> 
> Infinite?
> 

The same as for [5/10].

>> +
>> +       mps2_uart_write8(port, ch, UARTn_DATA);
>> +}
> 
>> +static int mps2_init_port(struct mps2_uart_port *mps_port,
>> +                       struct platform_device *pdev)
>> +{
>> +       int ret;
>> +       struct resource *res;
> 
> Maybe:
>        struct resource *res;
>        int ret;
> ?
> 

Matter of taste :) Will change it since I need to update the patch anyway.

Thanks
Vladimir



From mark.rutland at arm.com  Tue Feb 16 06:29:14 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 16 Feb 2016 14:29:14 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <20160216141258.GA8022@leverpostej>
References: <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160216141258.GA8022@leverpostej>
Message-ID: <20160216142914.GB8022@leverpostej>

On Tue, Feb 16, 2016 at 02:12:59PM +0000, Mark Rutland wrote:
> On Tue, Feb 16, 2016 at 03:59:09PM +0300, Andrey Ryabinin wrote:
> > So shadow is corrupted.
> > Some hypotheses:
> > 
> > 1) We share stack between several tasks (e.g. stack overflow, somehow corrupted SP).
> >     But this probably should cause kernel crash later, after kasan reports.
> > 
> > 2) Shadow memory wasn't cleared. GCC poison memory on function entrance and unpoisons it before return.
> >      If we use some tricky way to exit from function this could cause false-positives like that.
> >      E.g. some hand-written assembly return code.
> > 
> > 3) Screwed shadow mapping. I think the patch below should uncover such problem.
> > It boot-tested on qemu and didn't show any problem
> 
> With that path applied I get:
> 
> [    0.000000] kasan: screwed shadow mapping 62184, 62182
> [    0.000000] kasan: KernelAddressSanitizer initialized
> 
> I'm using v4.5-rc1 with KASAN_INLINE, and a random collection of debug options
> to bloat the kernel per prior theory that the text size had somethign to do
> with the issue.

I hacked kasan_init to dump info as it created each shadow region:

[    0.000000] kasan_init shadowing [ffffffc000000000-ffffffc060000000] @ [ffffff8800000000-ffffff880c000001] nid 0
[    0.000000] kasan_init shadowing [ffffffc0600f0000-ffffffc079450000] @ [ffffff880c01e000-ffffff880f28a001] nid 0
[    0.000000] kasan_init shadowing [ffffffc079450000-ffffffc079820000] @ [ffffff880f28a000-ffffff880f304001] nid 0
[    0.000000] kasan_init shadowing [ffffffc079820000-ffffffc079821000] @ [ffffff880f304000-ffffff880f304201] nid 0
[    0.000000] kasan_init shadowing [ffffffc079821000-ffffffc079822000] @ [ffffff880f304200-ffffff880f304401] nid 0
[    0.000000] kasan_init shadowing [ffffffc079822000-ffffffc079828000] @ [ffffff880f304400-ffffff880f305001] nid 0
[    0.000000] kasan_init shadowing [ffffffc079828000-ffffffc07982c000] @ [ffffff880f305000-ffffff880f305801] nid 0
[    0.000000] kasan_init shadowing [ffffffc07982c000-ffffffc07e7f0000] @ [ffffff880f305800-ffffff880fcfe001] nid 0
[    0.000000] kasan_init shadowing [ffffffc07e7f0000-ffffffc07e830000] @ [ffffff880fcfe000-ffffff880fd06001] nid 0
[    0.000000] kasan_init shadowing [ffffffc07e830000-ffffffc07e840000] @ [ffffff880fd06000-ffffff880fd08001] nid 0
[    0.000000] kasan_init shadowing [ffffffc07e840000-ffffffc07e890000] @ [ffffff880fd08000-ffffff880fd12001] nid 0
[    0.000000] kasan_init shadowing [ffffffc07e890000-ffffffc07f000000] @ [ffffff880fd12000-ffffff880fe00001] nid 0
[    0.000000] kasan_init shadowing [ffffffc800000000-ffffffc980000000] @ [ffffff8900000000-ffffff8930000001] nid 0
[    0.000000] kasan: screwed shadow mapping 62184, 62182
[    0.000000] kasan: KernelAddressSanitizer initialized

I note the the end of each shadow region overlaps the beginning of the next due
to the intentional end+1...

Other than the waste of memory (and the TLB conflict that gets solved by my
pgtable rework), I'm not sure though I'm not sure that's a problem, though.

Mark.

> I guess memroy layout has something to do with this. FWIW on this board my
> memory map comes from EFI:
> 
> [    0.000000] Processing EFI memory map:
> [    0.000000]   0x000008000000-0x00000bffffff [Memory Mapped I/O  |RUN|  |XP|  |  |  |   |  |  |  |UC]
> [    0.000000]   0x00001c170000-0x00001c170fff [Memory Mapped I/O  |RUN|  |XP|  |  |  |   |  |  |  |UC]
> [    0.000000]   0x000080000000-0x00008000ffff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x000080010000-0x00008007ffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x000080080000-0x000081dbffff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x000081dc0000-0x00009fdfffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x00009fe00000-0x00009fe0ffff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x00009fe10000-0x0000dfffffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000e00f0000-0x0000f5a58fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000f5a59000-0x0000f7793fff [Loader Code        |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000f7794000-0x0000f9431fff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000f9432000-0x0000f944ffff [Loader Code        |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000f9450000-0x0000f945ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f9460000-0x0000f94dffff [ACPI Reclaim Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f94e0000-0x0000f94effff [ACPI Memory NVS    |   |  |  |  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f94f0000-0x0000f94fffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f9500000-0x0000f950ffff [Runtime Code       |RUN|  |  |  |  |RO|   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f9510000-0x0000f953ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f9540000-0x0000f954ffff [Runtime Code       |RUN|  |  |  |  |RO|   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f9550000-0x0000f956ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f9570000-0x0000f958ffff [ACPI Reclaim Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f9590000-0x0000f960ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f9610000-0x0000f961ffff [Runtime Code       |RUN|  |  |  |  |RO|   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f9620000-0x0000f96effff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f96f0000-0x0000f96fffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f9700000-0x0000f970ffff [Runtime Code       |RUN|  |  |  |  |RO|   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f9710000-0x0000f974ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f9750000-0x0000f975ffff [Runtime Code       |RUN|  |  |  |  |RO|   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f9760000-0x0000f97cffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f97d0000-0x0000f97dffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f97e0000-0x0000f97effff [Runtime Code       |RUN|  |  |  |  |RO|   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f97f0000-0x0000f981ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f9820000-0x0000f9820fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000f9821000-0x0000f9827fff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000f9828000-0x0000f982bfff [Reserved           |   |  |  |  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000f982c000-0x0000fdaedfff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fdaee000-0x0000fdfbefff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fdfbf000-0x0000fdfbffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fdfc0000-0x0000fdffbfff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fdffc000-0x0000fe018fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe019000-0x0000fe020fff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe021000-0x0000fe022fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe023000-0x0000fe02bfff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe02c000-0x0000fe03afff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe03b000-0x0000fe03dfff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe03e000-0x0000fe04efff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe04f000-0x0000fe057fff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe058000-0x0000fe073fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe074000-0x0000fe074fff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe075000-0x0000fe078fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe079000-0x0000fe07bfff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe07c000-0x0000fe07dfff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe07e000-0x0000fe085fff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe086000-0x0000fe087fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe088000-0x0000fe171fff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe172000-0x0000fe198fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe199000-0x0000fe65ffff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe660000-0x0000fe6a2fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe6a3000-0x0000fe7effff [Boot Code          |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe7f0000-0x0000fe7fffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000fe800000-0x0000fe80ffff [Runtime Code       |RUN|  |  |  |  |RO|   |WB|WT|WC|UC]*
> [    0.000000]   0x0000fe810000-0x0000fe82ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000fe830000-0x0000fe83ffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe840000-0x0000fe88ffff [Runtime Data       |RUN|  |XP|  |  |  |   |WB|WT|WC|UC]*
> [    0.000000]   0x0000fe890000-0x0000fe891fff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x0000fe892000-0x0000feffffff [Boot Data          |   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x000880000000-0x00099bffffff [Conventional Memory|   |  |  |  |  |  |   |WB|WT|WC|UC]
> [    0.000000]   0x00099c000000-0x0009ffffffff [Loader Data        |   |  |  |  |  |  |   |WB|WT|WC|UC]
> 
> Thanks,
> Mark.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From daniel at ffwll.ch  Tue Feb 16 06:31:28 2016
From: daniel at ffwll.ch (Daniel Vetter)
Date: Tue, 16 Feb 2016 15:31:28 +0100
Subject: [PATCH v2 03/17] drm/exynos: removed optional dummy encoder
 mode_fixup function.
In-Reply-To: <CAMeQTsZLdMOnk7-isneoUyFBbQdiRUsGH6+EhD8W1LNB=80LVQ@mail.gmail.com>
References: <cover.1455540137.git.palminha@synopsys.com>
 <3768b670931572de51fca1102efa18d20dd770ee.1455540137.git.palminha@synopsys.com>
 <CAMeQTsZLdMOnk7-isneoUyFBbQdiRUsGH6+EhD8W1LNB=80LVQ@mail.gmail.com>
Message-ID: <20160216143128.GE32705@phenom.ffwll.local>

On Mon, Feb 15, 2016 at 02:49:09PM +0100, Patrik Jakobsson wrote:
> Hi Carlos
> 
> Any particular reason why this patch isn't squashed with patch 8/17?

I've squashed them while applying.
-Daniel

> 
> Thanks
> Patrik
> 
> 
> On Mon, Feb 15, 2016 at 1:58 PM, Carlos Palminha
> <CARLOS.PALMINHA at synopsys.com> wrote:
> > mode_fixup function for encoder drivers became optional with patch
> > http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com
> >
> > This patch set nukes all the dummy mode_fixup implementations.
> >
> > (made on top of Daniel topic/drm-misc branch)
> >
> > Signed-off-by: Carlos Palminha <palminha at synopsys.com>
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 --------
> >  1 file changed, 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > index e977a81..736115c 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > @@ -1597,13 +1597,6 @@ static int exynos_dsi_create_connector(struct drm_encoder *encoder)
> >         return 0;
> >  }
> >
> > -static bool exynos_dsi_mode_fixup(struct drm_encoder *encoder,
> > -                                 const struct drm_display_mode *mode,
> > -                                 struct drm_display_mode *adjusted_mode)
> > -{
> > -       return true;
> > -}
> > -
> >  static void exynos_dsi_mode_set(struct drm_encoder *encoder,
> >                                 struct drm_display_mode *mode,
> >                                 struct drm_display_mode *adjusted_mode)
> > @@ -1623,7 +1616,6 @@ static void exynos_dsi_mode_set(struct drm_encoder *encoder,
> >  }
> >
> >  static const struct drm_encoder_helper_funcs exynos_dsi_encoder_helper_funcs = {
> > -       .mode_fixup = exynos_dsi_mode_fixup,
> >         .mode_set = exynos_dsi_mode_set,
> >         .enable = exynos_dsi_enable,
> >         .disable = exynos_dsi_disable,
> > --
> > 2.5.0
> >
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From heiko at sntech.de  Tue Feb 16 06:35:07 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 16 Feb 2016 15:35:07 +0100
Subject: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver
In-Reply-To: <56C270F9.9030707@rock-chips.com>
References: <1454049768-30872-1-git-send-email-ykk@rock-chips.com>
 <56C270F9.9030707@rock-chips.com>
Message-ID: <1519836.S7OnrkT0mU@phil>

Hi Mark,

Am Dienstag, 16. Februar 2016, 08:44:41 schrieb Mark yao:
> Ping, it seems inno hdmi driver is ready, So I'd like to merge it into
> drm/rockchip if there is no doubt these days.

I think you can just go ahead  with picking them up, I think they have 
ripened enough :-)


Heiko


From vladimir.murzin at arm.com  Tue Feb 16 06:35:43 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 14:35:43 +0000
Subject: [PATCH v3 06/10] ARM: mps2: introduce MPS2 platform
In-Reply-To: <29457600.xRDuy0uVjW@wuerfel>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-7-git-send-email-vladimir.murzin@arm.com>
 <29457600.xRDuy0uVjW@wuerfel>
Message-ID: <56C333BF.1020108@arm.com>

On 16/02/16 10:56, Arnd Bergmann wrote:
> On Tuesday 16 February 2016 10:08:11 Vladimir Murzin wrote:
>> The Cortex-M Prototyping System (or V2M-MPS2) is designed for
>> prototyping and evaluation Cortex-M family of processors including the
>> latest Cortex-M7
>>
>> It comes with a range of useful peripherals including 8MB single cycle
>> SRAM, 16MB PSRAM, Ethernet, QSVGA touch screen panel, 4bit RGB VGA
>> connector, Audio, SPI and GPIO.
>>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
>> ---
>>  arch/arm/Kconfig                 |    8 ++++++++
>>  arch/arm/Makefile                |    1 +
>>  arch/arm/mach-mps2/Makefile      |    1 +
>>  arch/arm/mach-mps2/Makefile.boot |    3 +++
>>  arch/arm/mach-mps2/dtmachine.c   |   21 +++++++++++++++++++++
>>
> 
> We are in the (slow) process of consolidating the ARM reference platforms
> (versatile, integrator, realview, vexpress) into one place.
> 

Thanks for information! Sometime ago I saw on a list you had some
thoughts on consolidating M-class platforms since most of them follow
quite the same pattern (I'm looking at efm32 and stm32). So, shouldn't
this platform consider that way?

> I'd suggest adding all this to the mach-vexpress directory rather than
> a new directory, so we don't have another one to consolidate.
> 

I'm fine with either way.

Thanks
Vladimir

> 	Arnd
> 
> 
> 



From arnd at arndb.de  Tue Feb 16 06:36:03 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 15:36:03 +0100
Subject: [PATCH 0/3] ARM: stm32: Introduce support for STM32F469
In-Reply-To: <1455632221-31834-1-git-send-email-lee.jones@linaro.org>
References: <1455632221-31834-1-git-send-email-lee.jones@linaro.org>
Message-ID: <8086636.p5SR2hZz49@wuerfel>

On Tuesday 16 February 2016 14:16:58 Lee Jones wrote:
> Simple set using the STM32F429 infrastructure as a foundation.
> There will be more changes to the DTS files and a requirement for
> added hierarchical layering as more differences become apparent.
> 
> Lee Jones (3):
>   ARM: stm32: Supply a DTS file for the STM32F469 Discovery board
>   ARM: configs: Add new config fragment to change RAM start point
>   ARM: stm32: Identify a new board - STM32F469
> 

Looks good to me. It's the first use of Kconfig fragments we have on ARM,
but it seems justified.

Acked-by: Arnd Bergmann <arnd at arndb.de


From heiko at sntech.de  Tue Feb 16 06:37:02 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 16 Feb 2016 15:37:02 +0100
Subject: [PATCH] spi/rockchip: Add dt-binding for Rockchip rk3399 spi
In-Reply-To: <20160216132223.GM18327@sirena.org.uk>
References: <1455614538-4415-1-git-send-email-jay.xu@rock-chips.com>
 <20160216132223.GM18327@sirena.org.uk>
Message-ID: <1730751.NYv1NxJVuB@phil>

Am Dienstag, 16. Februar 2016, 13:22:23 schrieb Mark Brown:
> On Tue, Feb 16, 2016 at 05:22:18PM +0800, jianqun.xu wrote:
> >  Documentation/devicetree/bindings/spi/spi-rockchip.txt | 1 +
> >  1 file changed, 1 insertion(+)
> 
> I'd expect this to be added to both the driver and the binding document
> not just the document.

It seems the driver can still use the rk3066-variant - aka nobody has found 
specific issues in the rk3399 IP implementation.

Having the more specific IP names already in the dts before actually using 
them was suggested by devicetree people to not have to exchange everything 
once specific issues were found. 

So right now it's using the fallback-mechanism of binding to the rk3066 
name, but if some obstacle appears it will only take adding the binding in 
the driver to make it work (even with old devicetrees).


From daniel at ffwll.ch  Tue Feb 16 06:38:21 2016
From: daniel at ffwll.ch (Daniel Vetter)
Date: Tue, 16 Feb 2016 15:38:21 +0100
Subject: [PATCH v2 00/17] drm encoders cleanup: nuke optional dummy
 encoder mode_fixup function.
In-Reply-To: <cover.1455540137.git.palminha@synopsys.com>
References: <cover.1455540137.git.palminha@synopsys.com>
Message-ID: <20160216143821.GG32705@phenom.ffwll.local>

On Mon, Feb 15, 2016 at 12:57:04PM +0000, Carlos Palminha wrote:
> mode_fixup function for encoder drivers became optional with patch
> http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha at synopsys.com
> 
> This patch set nukes all the dummy mode_fixup implementations.
> 
> (made on top of Daniel topic/drm-misc branch)
> 
> Changes v1->v2: incorporated Daniel comments
> * added signed-off-by line to all patches
> * threading enabled due to e-mail server constraints
> * common blurb lines to all patches
> * add reviewed by Alex, to patches 4 and 14

I've thrown them all into a topic branch for soaking, and plan to merge
into drm-misc in the next few days.

Thanks, Daniel

> 
> Carlos Palminha (17):
>   drm/virtio: removed optional dummy encoder mode_fixup function.
>   drm/udl: removed optional dummy encoder mode_fixup function.
>   drm/exynos: removed optional dummy encoder mode_fixup function.
>   drm/amdgpu: removed optional dummy encoder mode_fixup function.
>   drm/ast: removed optional dummy encoder mode_fixup function.
>   drm/bochs: removed optional dummy encoder mode_fixup function.
>   drm/cirrus: removed optional dummy encoder mode_fixup function.
>   drm/exynos: removed optional dummy encoder mode_fixup function.
>   drm/gma500: removed optional dummy encoder mode_fixup function.
>   drm/imx: removed optional dummy encoder mode_fixup function.
>   drm/msm/mdp: removed optional dummy encoder mode_fixup function.
>   drm/mgag200: removed optional dummy encoder mode_fixup function.
>   drm/qxl: removed optional dummy encoder mode_fixup function.
>   drm/radeon: removed optional dummy encoder mode_fixup function.
>   drm/rockchip: removed optional dummy encoder mode_fixup function.
>   drm/sti: removed optional dummy encoder mode_fixup function.
>   drm/tilcdc: removed optional dummy encoder mode_fixup function.
> 
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c           |  8 --------
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c           |  8 --------
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c            |  8 --------
>  drivers/gpu/drm/ast/ast_mode.c                   |  8 --------
>  drivers/gpu/drm/bochs/bochs_kms.c                |  8 --------
>  drivers/gpu/drm/cirrus/cirrus_mode.c             |  9 ---------
>  drivers/gpu/drm/exynos/exynos_dp_core.c          |  8 --------
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c          |  8 --------
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c          |  8 --------
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c         |  8 --------
>  drivers/gpu/drm/gma500/cdv_intel_crt.c           |  1 -
>  drivers/gpu/drm/gma500/cdv_intel_hdmi.c          |  1 -
>  drivers/gpu/drm/gma500/gma_display.c             |  7 -------
>  drivers/gpu/drm/gma500/gma_display.h             |  3 ---
>  drivers/gpu/drm/gma500/oaktrail_hdmi.c           |  1 -
>  drivers/gpu/drm/imx/dw_hdmi-imx.c                |  8 --------
>  drivers/gpu/drm/imx/imx-ldb.c                    |  8 --------
>  drivers/gpu/drm/imx/imx-tve.c                    |  8 --------
>  drivers/gpu/drm/imx/parallel-display.c           |  8 --------
>  drivers/gpu/drm/mgag200/mgag200_mode.c           |  8 --------
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_dsi_encoder.c  |  8 --------
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_dtv_encoder.c  |  8 --------
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_lcdc_encoder.c |  8 --------
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c  |  9 ---------
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c      |  8 --------
>  drivers/gpu/drm/qxl/qxl_display.c                |  9 ---------
>  drivers/gpu/drm/radeon/atombios_encoders.c       |  8 --------
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c           |  8 --------
>  drivers/gpu/drm/sti/sti_tvout.c                  | 10 ----------
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c            |  9 ---------
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c           |  9 ---------
>  drivers/gpu/drm/udl/udl_encoder.c                |  8 --------
>  drivers/gpu/drm/virtio/virtgpu_display.c         |  8 --------
>  33 files changed, 244 deletions(-)
> 
> -- 
> 2.5.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


From arnd at arndb.de  Tue Feb 16 06:39:12 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 15:39:12 +0100
Subject: [PATCH v3 06/10] ARM: mps2: introduce MPS2 platform
In-Reply-To: <56C333BF.1020108@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <29457600.xRDuy0uVjW@wuerfel> <56C333BF.1020108@arm.com>
Message-ID: <2949036.dUgqHWXoSe@wuerfel>

On Tuesday 16 February 2016 14:35:43 Vladimir Murzin wrote:
> On 16/02/16 10:56, Arnd Bergmann wrote:
> > On Tuesday 16 February 2016 10:08:11 Vladimir Murzin wrote:
> >> The Cortex-M Prototyping System (or V2M-MPS2) is designed for
> >> prototyping and evaluation Cortex-M family of processors including the
> >> latest Cortex-M7
> >>
> >> It comes with a range of useful peripherals including 8MB single cycle
> >> SRAM, 16MB PSRAM, Ethernet, QSVGA touch screen panel, 4bit RGB VGA
> >> connector, Audio, SPI and GPIO.
> >>
> >> Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
> >> ---
> >>  arch/arm/Kconfig                 |    8 ++++++++
> >>  arch/arm/Makefile                |    1 +
> >>  arch/arm/mach-mps2/Makefile      |    1 +
> >>  arch/arm/mach-mps2/Makefile.boot |    3 +++
> >>  arch/arm/mach-mps2/dtmachine.c   |   21 +++++++++++++++++++++
> >>
> > 
> > We are in the (slow) process of consolidating the ARM reference platforms
> > (versatile, integrator, realview, vexpress) into one place.
> > 
> 
> Thanks for information! Sometime ago I saw on a list you had some
> thoughts on consolidating M-class platforms since most of them follow
> quite the same pattern (I'm looking at efm32 and stm32). So, shouldn't
> this platform consider that way?
> 

Right, that would be another option. vf610 is in the same category as this
one I think, it's currently in mach-imx, and we can probably leave it there.

Unless someone is going to do the patch to consolidate the cortex-m
platforms, I'd stay with mach-vexpress here, but I don't have a strong
opinion.

	Arnd


From rric at kernel.org  Tue Feb 16 06:42:50 2016
From: rric at kernel.org (Robert Richter)
Date: Tue, 16 Feb 2016 15:42:50 +0100
Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <20160215183041.GH3965@htj.duckdns.org>
References: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160214170152.GC3965@htj.duckdns.org>
 <56C147B2.9010303@caviumnetworks.com>
 <20160215183041.GH3965@htj.duckdns.org>
Message-ID: <20160216144250.GD31343@rric.localdomain>

On 15.02.16 13:30:41, Tejun Heo wrote:
> On Sun, Feb 14, 2016 at 07:36:18PM -0800, Tirumalesh Chalamarla wrote:
> > There is no need for special Driver, AHCI is sufficient for ThunderX, the
> > file only contains this interrupt handler,
> > is it preferable if this interrupt handler in libahci.c with others, instead
> > of separate file?
> 
> Yeap, just fold it in ahci.c with surrounding #ifdef guard.

Yes, please use #ifdef CONFIG_CAVIUM_ERRATUM_22536 ... and add a
kconfig entry for this to arch/arm64/Kconfig.

-Robert


From sudeep.holla at arm.com  Tue Feb 16 06:45:57 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Tue, 16 Feb 2016 14:45:57 +0000
Subject: [GIT PULL] firmware: SCPI driver updates for v4.6
Message-ID: <56C33625.5030903@arm.com>

Hi ARM-SoC team,

Here is the set of minor updates to SCPI firmware driver for v4.6
There's a change in HWMON driver which Guenter Roeck has Acked and
agreed to take it via arm-soc tree.

-- 
Regards,
Sudeep

-->8

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git 
tags/scpi-for-v4.6/updates

for you to fetch changes up to fb3b07ef399bd6984f3361a709829618b75e98d8:

   hwmon: (scpi) add energy meter support (2016-02-16 09:26:27 +0000)

----------------------------------------------------------------
SCPI updates and fixes for v4.6

1. Minor fix to restore functionality in big-endian mode

2. Fix race by decreasing Tx timeout to 20ms

3. Adds support for 64-bit sensor values and energy meter

----------------------------------------------------------------
Sudeep Holla (4):
       firmware: arm_scpi: fix send_message and sensor_get_value for 
big-endian
       firmware: arm_scpi: decrease Tx timeout to 20ms
       firmware: arm_scpi: add support for 64-bit sensor values
       hwmon: (scpi) add energy meter support

  drivers/firmware/arm_scpi.c   | 17 ++++++++++-------
  drivers/hwmon/scpi-hwmon.c    | 14 +++++++++++---
  include/linux/scpi_protocol.h |  3 ++-
  3 files changed, 23 insertions(+), 11 deletions(-)


From mark.rutland at arm.com  Tue Feb 16 06:47:31 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 16 Feb 2016 14:47:31 +0000
Subject: [PATCH] KVM: arm/arm64: vgic: ensure bitmaps are long enough
Message-ID: <1455634051-1860-1-git-send-email-mark.rutland@arm.com>

When we allocate bitmaps in vgic_vcpu_init_maps, we divide the number of
bits we need by 8 to figure out how many bytes to allocate. However,
bitmap elements are always accessed as unsigned longs, and if we didn't
happen to allocate a size such that size % sizeof(unsigned long) == 0,
bitmap accesses may go past the end of the allocation.

When using KASAN (which does byte-granular access checks), this results
in a continuous stream of BUGs whenever these bitmaps are accessed:

=============================================================================
BUG kmalloc-128 (Tainted: G    B          ): kasan: bad access detected
-----------------------------------------------------------------------------

INFO: Allocated in vgic_init.part.25+0x55c/0x990 age=7493 cpu=3 pid=1730
INFO: Slab 0xffffffbde6d5da40 objects=16 used=15 fp=0xffffffc935769700 flags=0x4000000000000080
INFO: Object 0xffffffc935769500 @offset=1280 fp=0x          (null)

Bytes b4 ffffffc9357694f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Padding ffffffc9357695b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Padding ffffffc9357695c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Padding ffffffc9357695d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Padding ffffffc9357695e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Padding ffffffc9357695f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
CPU: 3 PID: 1740 Comm: kvm-vcpu-0 Tainted: G    B           4.4.0+ #17
Hardware name: ARM Juno development board (r1) (DT)
Call trace:
[<ffffffc00008e770>] dump_backtrace+0x0/0x280
[<ffffffc00008ea04>] show_stack+0x14/0x20
[<ffffffc000726360>] dump_stack+0x100/0x188
[<ffffffc00030d324>] print_trailer+0xfc/0x168
[<ffffffc000312294>] object_err+0x3c/0x50
[<ffffffc0003140fc>] kasan_report_error+0x244/0x558
[<ffffffc000314548>] __asan_report_load8_noabort+0x48/0x50
[<ffffffc000745688>] __bitmap_or+0xc0/0xc8
[<ffffffc0000d9e44>] kvm_vgic_flush_hwstate+0x1bc/0x650
[<ffffffc0000c514c>] kvm_arch_vcpu_ioctl_run+0x2ec/0xa60
[<ffffffc0000b9a6c>] kvm_vcpu_ioctl+0x474/0xa68
[<ffffffc00036b7b0>] do_vfs_ioctl+0x5b8/0xcb0
[<ffffffc00036bf34>] SyS_ioctl+0x8c/0xa0
[<ffffffc000086cb0>] el0_svc_naked+0x24/0x28
Memory state around the buggy address:
 ffffffc935769400: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffffffc935769480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffffffc935769500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                   ^
 ffffffc935769580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffffffc935769600: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================

Fix the issue by always allocating a multiple of sizeof(unsigned long),
as we do elsewhere in the vgic code.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: Christoffer Dall <christoffer.dall at linaro.org>
---
 virt/kvm/arm/vgic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 7a2f449..5d10f10 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1875,8 +1875,8 @@ void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
 static int vgic_vcpu_init_maps(struct kvm_vcpu *vcpu, int nr_irqs)
 {
 	struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
-
-	int sz = (nr_irqs - VGIC_NR_PRIVATE_IRQS) / 8;
+	int nr_longs = BITS_TO_LONGS(nr_irqs - VGIC_NR_PRIVATE_IRQS);
+	int sz = nr_longs * sizeof(unsigned long);
 	vgic_cpu->pending_shared = kzalloc(sz, GFP_KERNEL);
 	vgic_cpu->active_shared = kzalloc(sz, GFP_KERNEL);
 	vgic_cpu->pend_act_shared = kzalloc(sz, GFP_KERNEL);
-- 
1.9.1



From arnd at arndb.de  Tue Feb 16 06:47:28 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 15:47:28 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack' pointer
Message-ID: <1455634059-1896914-1-git-send-email-arnd@arndb.de>

When CONFIG_SND_JACK is disabled, the hdmi driver tries to create
a new output jack structure and dereferences it even though
the pointer is never assigned:

sound/pci/hda/patch_hdmi.c: In function 'generic_hdmi_build_jack':
sound/pci/hda/patch_hdmi.c:2534:30: error: 'jack' may be used uninitialized in this function [-Werror=maybe-uninitialized]
sound/pci/hda/patch_hdmi.c:2526:19: note: 'jack' was declared here

This uses a compile-time check to avoid calling a nonworking
snd_jack_new() function, and sets an explicit NULL pointer instead.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 788d441a164c ("ALSA: hda - Use component ops for i915 HDMI/DP audio jack handling")
---
 sound/pci/hda/patch_hdmi.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index f4443b5fbf6e..c0872ad80aa0 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2526,6 +2526,11 @@ static int add_hdmi_jack_kctl(struct hda_codec *codec,
 	struct snd_jack *jack;
 	int err;
 
+	if (!IS_ENABLED(CONFIG_SND_JACK)) {
+		spec->pcm_rec[pcm_idx].jack = NULL;
+		return 0;
+	}
+
 	err = snd_jack_new(codec->card, name, SND_JACK_AVOUT, &jack,
 			   true, false);
 	if (err < 0)
-- 
2.7.0



From vladimir.murzin at arm.com  Tue Feb 16 06:51:59 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 14:51:59 +0000
Subject: [PATCH v3 08/10] ARM: configs: add MPS2 defconfig
In-Reply-To: <2680417.bULLX3O66Y@wuerfel>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-9-git-send-email-vladimir.murzin@arm.com>
 <2680417.bULLX3O66Y@wuerfel>
Message-ID: <56C3378F.2010008@arm.com>

On 16/02/16 10:58, Arnd Bergmann wrote:
> On Tuesday 16 February 2016 10:08:13 Vladimir Murzin wrote:
>> This patch adds a new config for MPS2 platform.
>>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
>> ---
>>  arch/arm/configs/mps2_defconfig |  112 +++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 112 insertions(+)
>>  create mode 100644 arch/arm/configs/mps2_defconfig
>>
>> diff --git a/arch/arm/configs/mps2_defconfig b/arch/arm/configs/mps2_defconfig
>> new file mode 100644
>> index 0000000..c36c519
>> --- /dev/null
>> +++ b/arch/arm/configs/mps2_defconfig
>> @@ -0,0 +1,112 @@
>> +# CONFIG_USELIB is not set
>> +CONFIG_NO_HZ_IDLE=y
>> +CONFIG_HIGH_RES_TIMERS=y
>> +CONFIG_LOG_BUF_SHIFT=16
>> +CONFIG_CC_OPTIMIZE_FOR_SIZE=y
>> +# CONFIG_UID16 is not set
>> +# CONFIG_BASE_FULL is not set
>> +# CONFIG_FUTEX is not set
>> +# CONFIG_EPOLL is not set
>> +# CONFIG_SIGNALFD is not set
>> +# CONFIG_EVENTFD is not set
>> +# CONFIG_AIO is not set
>> +CONFIG_EMBEDDED=y
> 
> Why CONFIG_EMBEDDED? You probably mean CONFIG_EXPERT, but then what do
> you need that for?

TBH, I have no special requirement for this option to be set and now,
looking at Kconfig entry for this option, I think that I got it here
because I stated configuration with allnoconfig.

OTOH, I don't see how harmful it can be since description says:

          This option should be enabled if compiling the kernel for
          an embedded system so certain expert options are available
          for configuration

yes, it selects CONFIG_EXPERT and that had side effect that, for
example, CONFIG_NAMESPACE could be compiled out.

Have I missed something around it?

Thanks
Vladimir

> 
> 	Arnd
> 
> 
> 



From arnd at arndb.de  Tue Feb 16 06:53:11 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 15:53:11 +0100
Subject: [PATCH] regulator: s5m8767: fix get_register() error handling
Message-ID: <1455634402-1997203-1-git-send-email-arnd@arndb.de>

The s5m8767_pmic_probe() function calls s5m8767_get_register() to
read data without checking the return code, which produces a compile-time
warning when that data is accessed:

drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe':
drivers/regulator/s5m8767.c:924:7: error: 'enable_reg' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/regulator/s5m8767.c:944:30: error: 'enable_val' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This changes the s5m8767_get_register() function to return a -EINVAL
not just for an invalid register number but also for an invalid
regulator number, as both would result in returning uninitialized
data. The s5m8767_pmic_probe() function is then changed accordingly
to fail on a read error, as all the other callers of s5m8767_get_register()
already do.

In practice this probably cannot happen, as we don't call
s5m8767_get_register() with invalid arguments, but the gcc
warning seems valid in principle, in terms writing safe
error checking.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 9c4c60554acf ("regulator: s5m8767: Convert to use regulator_[enable|disable|is_enabled]_regmap")
---
 drivers/regulator/s5m8767.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index 58f5d3b8e981..27343e1c43ef 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -202,9 +202,10 @@ static int s5m8767_get_register(struct s5m8767_info *s5m8767, int reg_id,
 		}
 	}
 
-	if (i < s5m8767->num_regulators)
-		*enable_ctrl =
-		s5m8767_opmode_reg[reg_id][mode] << S5M8767_ENCTRL_SHIFT;
+	if (i >= s5m8767->num_regulators)
+		return -EINVAL;
+
+	*enable_ctrl = s5m8767_opmode_reg[reg_id][mode] << S5M8767_ENCTRL_SHIFT;
 
 	return 0;
 }
@@ -937,8 +938,12 @@ static int s5m8767_pmic_probe(struct platform_device *pdev)
 			else
 				regulators[id].vsel_mask = 0xff;
 
-			s5m8767_get_register(s5m8767, id, &enable_reg,
+			ret = s5m8767_get_register(s5m8767, id, &enable_reg,
 					     &enable_val);
+			if (ret) {
+				dev_err(s5m8767->dev, "error reading registers\n");
+				return ret;
+			}
 			regulators[id].enable_reg = enable_reg;
 			regulators[id].enable_mask = S5M8767_ENCTRL_MASK;
 			regulators[id].enable_val = enable_val;
-- 
2.7.0



From arnd at arndb.de  Tue Feb 16 06:55:07 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 15:55:07 +0100
Subject: [PATCH] iio: pressure: ms5611: select IIO_BUFFER
Message-ID: <1455634525-2023774-1-git-send-email-arnd@arndb.de>

The ms5611 driver started using the IIO_TRIGGERED_BUFFER infrastructure
which in turn depend on IIO_BUFFER, and it produces a build error now
if that is not enabled:

warning: (... && MS5611 && ...) selects IIO_TRIGGERED_BUFFER which has unmet direct dependencies (IIO && IIO_BUFFER)
buffer/industrialio-triggered-buffer.c: In function 'iio_triggered_buffer_setup':
buffer/industrialio-triggered-buffer.c:58:2: error: implicit declaration of function 'iio_device_attach_buffer' [-Werror=implicit-function-declaration]
pressure/ms5611_core.c: In function 'ms5611_trigger_handler':
pressure/ms5611_core.c:193:2: error: implicit declaration of function 'iio_push_to_buffers_with_timestamp' [-Werror=implicit-function-declaration]

This adds the second select.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 713bbb4efb9d ("iio: pressure: ms5611: Add triggered buffer support")
---
 drivers/iio/pressure/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/pressure/Kconfig b/drivers/iio/pressure/Kconfig
index f15f66d6f527..31c0e1fd2202 100644
--- a/drivers/iio/pressure/Kconfig
+++ b/drivers/iio/pressure/Kconfig
@@ -69,6 +69,7 @@ config MPL3115
 
 config MS5611
 	tristate "Measurement Specialties MS5611 pressure sensor driver"
+	select IIO_BUFFER
 	select IIO_TRIGGERED_BUFFER
 	help
 	  Say Y here to build support for the Measurement Specialties
-- 
2.7.0



From arnd at arndb.de  Tue Feb 16 06:54:24 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 15:54:24 +0100
Subject: [PATCH] mfd: fsl-imx25-tsadc: select IRQ_DOMAIN
Message-ID: <1455634467-2013548-1-git-send-email-arnd@arndb.de>

The newly added tsadc code use irq domains, but it can be enabled
when they are disabled in Kconfig:

drivers/mfd/fsl-imx25-tsadc.c:41:22: error: implicit declaration of function 'irq_find_mapping' [-Werror=implicit-function-declaration]
   generic_handle_irq(irq_find_mapping(tsadc->domain, 1));
drivers/mfd/fsl-imx25-tsadc.c: In function 'mx25_tsadc_setup_irq':
drivers/mfd/fsl-imx25-tsadc.c:80:18: error: implicit declaration of function 'irq_domain_add_simple' [-Werror=implicit-function-declaration]

This adds a 'select IRQ_DOMAIN' code, like we have it in all other
drivers with this requirement.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: e2fccf5c1515 ("mfd: fsl-imx25-tsadc: Register touchscreen ADC driver")
---
 drivers/mfd/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index aa21dc55eb15..8cab3ecca8fc 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -300,6 +300,7 @@ config MFD_MC13XXX_I2C
 config MFD_MX25_TSADC
 	tristate "Freescale i.MX25 integrated Touchscreen and ADC unit"
 	select REGMAP_MMIO
+	select IRQ_DOMAIN
 	depends on (SOC_IMX25 && OF) || COMPILE_TEST
 	help
 	  Enable support for the integrated Touchscreen and ADC unit of the
-- 
2.7.0



From m.szyprowski at samsung.com  Tue Feb 16 06:56:53 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 16 Feb 2016 15:56:53 +0100
Subject: [PATCH 00/11] SYSMMU driver update and support for Exynos 5433
Message-ID: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>

Hello,

This patchset updates Exynos SYSMMU (IOMMU) driver to make use of the
new features in the IOMMU core (support for IOMMU_DOMAIN_DMA) and adds
support for SYSMMU v5 controllers, which are available in Samsung Exynos
5433 SoCs. The driver has been also updated to compile and work on ARM64
architecture.

Best regards
Marek Szyprowski
Samsung R&D Institute Poland


Patch summary:

Marek Szyprowski (11):
  iommu: exynos: rework iommu group initialization
  iommu: exynos: add support for IOMMU_DOMAIN_DMA domain type
  iommu: exynos: remove ARM-specific cache flush interface
  iommu: exynos: simplify master clock operations
  iommu: exynos: refactor code (no direct register access)
  iommu: exynos: refactor fault handling code
  iommu: exynos: refactor init config code
  iommu: exynos: unify code for fldp cache invalidation
  iommu: exynos: update device tree documentation
  iommu: exynos: add support for v5 SYSMMU
  iommu: exynos: add Maintainers entry for Exynos SYSMMU driver

 .../devicetree/bindings/iommu/samsung,sysmmu.txt   |  22 +-
 MAINTAINERS                                        |   6 +
 drivers/iommu/Kconfig                              |   2 +-
 drivers/iommu/exynos-iommu.c                       | 514 ++++++++++++---------
 4 files changed, 318 insertions(+), 226 deletions(-)

-- 
1.9.2



From m.szyprowski at samsung.com  Tue Feb 16 06:56:55 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 16 Feb 2016 15:56:55 +0100
Subject: [PATCH 02/11] iommu: exynos: add support for IOMMU_DOMAIN_DMA domain
 type
In-Reply-To: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
References: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455634624-18130-3-git-send-email-m.szyprowski@samsung.com>

This patch adds support for DMA domain type. Such domain have DMA cookie
prepared and can be used by generic DMA-IOMMU glue layer.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 4fc0790..595e0da 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -25,9 +25,9 @@
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/slab.h>
+#include <linux/dma-iommu.h>
 
 #include <asm/cacheflush.h>
-#include <asm/dma-iommu.h>
 #include <asm/pgtable.h>
 
 typedef u32 sysmmu_iova_t;
@@ -662,16 +662,21 @@ static struct iommu_domain *exynos_iommu_domain_alloc(unsigned type)
 	struct exynos_iommu_domain *domain;
 	int i;
 
-	if (type != IOMMU_DOMAIN_UNMANAGED)
-		return NULL;
 
 	domain = kzalloc(sizeof(*domain), GFP_KERNEL);
 	if (!domain)
 		return NULL;
 
+	if (type == IOMMU_DOMAIN_DMA) {
+		if (iommu_get_dma_cookie(&domain->domain) != 0)
+			goto err_pgtable;
+	} else if (type != IOMMU_DOMAIN_UNMANAGED) {
+		goto err_pgtable;
+	}
+
 	domain->pgtable = (sysmmu_pte_t *)__get_free_pages(GFP_KERNEL, 2);
 	if (!domain->pgtable)
-		goto err_pgtable;
+		goto err_dma_cookie;
 
 	domain->lv2entcnt = (short *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 1);
 	if (!domain->lv2entcnt)
@@ -703,6 +708,9 @@ static struct iommu_domain *exynos_iommu_domain_alloc(unsigned type)
 
 err_counter:
 	free_pages((unsigned long)domain->pgtable, 2);
+err_dma_cookie:
+	if (type == IOMMU_DOMAIN_DMA)
+		iommu_put_dma_cookie(&domain->domain);
 err_pgtable:
 	kfree(domain);
 	return NULL;
@@ -727,6 +735,9 @@ static void exynos_iommu_domain_free(struct iommu_domain *iommu_domain)
 
 	spin_unlock_irqrestore(&domain->lock, flags);
 
+	if (iommu_domain->type == IOMMU_DOMAIN_DMA)
+		iommu_put_dma_cookie(iommu_domain);
+
 	for (i = 0; i < NUM_LV1ENTRIES; i++)
 		if (lv1ent_page(domain->pgtable + i))
 			kmem_cache_free(lv2table_kmem_cache,
-- 
1.9.2



From m.szyprowski at samsung.com  Tue Feb 16 06:56:54 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 16 Feb 2016 15:56:54 +0100
Subject: [PATCH 01/11] iommu: exynos: rework iommu group initialization
In-Reply-To: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
References: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455634624-18130-2-git-send-email-m.szyprowski@samsung.com>

This patch replaces custom code in add_device implementation with
iommu_group_get_for_dev() call and provides the needed callback.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 27 ++++++++++++++++-----------
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 97c41b8..4fc0790 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1114,28 +1114,32 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct iommu_domain *iommu_domain,
 	return phys;
 }
 
+static struct iommu_group *get_device_iommu_group(struct device *dev)
+{
+	struct iommu_group *group;
+
+	group = iommu_group_get(dev);
+	if (!group)
+		group = iommu_group_alloc();
+
+	return group;
+}
+
 static int exynos_iommu_add_device(struct device *dev)
 {
 	struct iommu_group *group;
-	int ret;
 
 	if (!has_sysmmu(dev))
 		return -ENODEV;
 
-	group = iommu_group_get(dev);
+	group = iommu_group_get_for_dev(dev);
 
-	if (!group) {
-		group = iommu_group_alloc();
-		if (IS_ERR(group)) {
-			dev_err(dev, "Failed to allocate IOMMU group\n");
-			return PTR_ERR(group);
-		}
-	}
+	if (IS_ERR(group))
+		return PTR_ERR(group);
 
-	ret = iommu_group_add_device(group, dev);
 	iommu_group_put(group);
 
-	return ret;
+	return 0;
 }
 
 static void exynos_iommu_remove_device(struct device *dev)
@@ -1182,6 +1186,7 @@ static struct iommu_ops exynos_iommu_ops = {
 	.unmap = exynos_iommu_unmap,
 	.map_sg = default_iommu_map_sg,
 	.iova_to_phys = exynos_iommu_iova_to_phys,
+	.device_group = get_device_iommu_group,
 	.add_device = exynos_iommu_add_device,
 	.remove_device = exynos_iommu_remove_device,
 	.pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
-- 
1.9.2



From m.szyprowski at samsung.com  Tue Feb 16 06:56:59 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 16 Feb 2016 15:56:59 +0100
Subject: [PATCH 06/11] iommu: exynos: refactor fault handling code
In-Reply-To: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
References: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455634624-18130-7-git-send-email-m.szyprowski@samsung.com>

This patch provides a new implementation for page fault handing code. The
new implementation is ready for future extensions. No functional changes
have been made.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 109 ++++++++++++++++---------------------------
 1 file changed, 41 insertions(+), 68 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 4275222..3a577a4 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -148,40 +148,25 @@ static sysmmu_pte_t *page_entry(sysmmu_pte_t *sent, sysmmu_iova_t iova)
 				lv2table_base(sent)) + lv2ent_offset(iova);
 }
 
-enum exynos_sysmmu_inttype {
-	SYSMMU_PAGEFAULT,
-	SYSMMU_AR_MULTIHIT,
-	SYSMMU_AW_MULTIHIT,
-	SYSMMU_BUSERROR,
-	SYSMMU_AR_SECURITY,
-	SYSMMU_AR_ACCESS,
-	SYSMMU_AW_SECURITY,
-	SYSMMU_AW_PROTECTION, /* 7 */
-	SYSMMU_FAULT_UNKNOWN,
-	SYSMMU_FAULTS_NUM
-};
-
-static unsigned short fault_reg_offset[SYSMMU_FAULTS_NUM] = {
-	REG_PAGE_FAULT_ADDR,
-	REG_AR_FAULT_ADDR,
-	REG_AW_FAULT_ADDR,
-	REG_DEFAULT_SLAVE_ADDR,
-	REG_AR_FAULT_ADDR,
-	REG_AR_FAULT_ADDR,
-	REG_AW_FAULT_ADDR,
-	REG_AW_FAULT_ADDR
+/*
+ * IOMMU fault information register
+ */
+struct sysmmu_fault_info {
+	unsigned int bit;	/* bit number in STATUS register */
+	unsigned short addr_reg; /* register to read VA fault address */
+	const char *name;	/* human readable fault name */
+	unsigned int type;	/* fault type for report_iommu_fault */
 };
 
-static char *sysmmu_fault_name[SYSMMU_FAULTS_NUM] = {
-	"PAGE FAULT",
-	"AR MULTI-HIT FAULT",
-	"AW MULTI-HIT FAULT",
-	"BUS ERROR",
-	"AR SECURITY PROTECTION FAULT",
-	"AR ACCESS PROTECTION FAULT",
-	"AW SECURITY PROTECTION FAULT",
-	"AW ACCESS PROTECTION FAULT",
-	"UNKNOWN FAULT"
+static const struct sysmmu_fault_info sysmmu_faults[] = {
+	{ 0, REG_PAGE_FAULT_ADDR, "PAGE", IOMMU_FAULT_READ },
+	{ 1, REG_AR_FAULT_ADDR, "AR MULTI-HIT", IOMMU_FAULT_READ },
+	{ 2, REG_AW_FAULT_ADDR, "AW MULTI-HIT", IOMMU_FAULT_WRITE },
+	{ 3, REG_DEFAULT_SLAVE_ADDR, "BUS ERROR", IOMMU_FAULT_READ },
+	{ 4, REG_AR_FAULT_ADDR, "AR SECURITY PROTECTION", IOMMU_FAULT_READ },
+	{ 5, REG_AR_FAULT_ADDR, "AR ACCESS PROTECTION", IOMMU_FAULT_READ },
+	{ 6, REG_AW_FAULT_ADDR, "AW SECURITY PROTECTION", IOMMU_FAULT_WRITE },
+	{ 7, REG_AW_FAULT_ADDR, "AW ACCESS PROTECTION", IOMMU_FAULT_WRITE },
 };
 
 /*
@@ -299,24 +284,19 @@ static void __sysmmu_set_ptbase(struct sysmmu_drvdata *data, phys_addr_t pgd)
 	__sysmmu_tlb_invalidate(data);
 }
 
-static void show_fault_information(const char *name,
-		enum exynos_sysmmu_inttype itype,
-		phys_addr_t pgtable_base, sysmmu_iova_t fault_addr)
+static void show_fault_information(struct sysmmu_drvdata *data,
+				   const struct sysmmu_fault_info *finfo,
+				   sysmmu_iova_t fault_addr)
 {
 	sysmmu_pte_t *ent;
 
-	if ((itype >= SYSMMU_FAULTS_NUM) || (itype < SYSMMU_PAGEFAULT))
-		itype = SYSMMU_FAULT_UNKNOWN;
-
-	pr_err("%s occurred at %#x by %s(Page table base: %pa)\n",
-		sysmmu_fault_name[itype], fault_addr, name, &pgtable_base);
-
-	ent = section_entry(phys_to_virt(pgtable_base), fault_addr);
-	pr_err("\tLv1 entry: %#x\n", *ent);
-
+	dev_err(data->sysmmu, "%s FAULT occurred at %#x (page table base: %pa)\n",
+		finfo->name, fault_addr, &data->pgtable);
+	ent = section_entry(phys_to_virt(data->pgtable), fault_addr);
+	dev_err(data->sysmmu, "\tLv1 entry: %#x\n", *ent);
 	if (lv1ent_page(ent)) {
 		ent = page_entry(ent, fault_addr);
-		pr_err("\t Lv2 entry: %#x\n", *ent);
+		dev_err(data->sysmmu, "\t Lv2 entry: %#x\n", *ent);
 	}
 }
 
@@ -324,8 +304,10 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 {
 	/* SYSMMU is in blocked state when interrupt occurred. */
 	struct sysmmu_drvdata *data = dev_id;
-	enum exynos_sysmmu_inttype itype;
-	sysmmu_iova_t addr = -1;
+	const struct sysmmu_fault_info *finfo = sysmmu_faults;
+	int i, n = ARRAY_SIZE(sysmmu_faults);
+	unsigned int itype;
+	sysmmu_iova_t fault_addr = -1;
 	int ret = -ENOSYS;
 
 	WARN_ON(!is_sysmmu_active(data));
@@ -334,29 +316,20 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 
 	clk_enable(data->clk_master);
 
-	itype = (enum exynos_sysmmu_inttype)
-		__ffs(__raw_readl(data->sfrbase + REG_INT_STATUS));
-	if (WARN_ON(!((itype >= 0) && (itype < SYSMMU_FAULT_UNKNOWN))))
-		itype = SYSMMU_FAULT_UNKNOWN;
-	else
-		addr = __raw_readl(data->sfrbase + fault_reg_offset[itype]);
+	itype = __ffs(__raw_readl(data->sfrbase + REG_INT_STATUS));
+	for (i = 0; i < n; i++, finfo++)
+		if (finfo->bit == itype)
+			break;
+	/* unknown/unsupported fault */
+	BUG_ON(i == n);
 
-	if (itype == SYSMMU_FAULT_UNKNOWN) {
-		pr_err("%s: Fault is not occurred by System MMU '%s'!\n",
-			__func__, dev_name(data->sysmmu));
-		pr_err("%s: Please check if IRQ is correctly configured.\n",
-			__func__);
-		BUG();
-	} else {
-		unsigned int base =
-				__raw_readl(data->sfrbase + REG_PT_BASE_ADDR);
-		show_fault_information(dev_name(data->sysmmu),
-					itype, base, addr);
-		if (data->domain)
-			ret = report_iommu_fault(&data->domain->domain,
-					data->master, addr, itype);
-	}
+	/* print debug message */
+	fault_addr = __raw_readl(data->sfrbase + finfo->addr_reg);
+	show_fault_information(data, finfo, fault_addr);
 
+	if (data->domain)
+		ret = report_iommu_fault(&data->domain->domain,
+					data->master, fault_addr, finfo->type);
 	/* fault is not recovered by fault handler */
 	BUG_ON(ret != 0);
 
-- 
1.9.2



From m.szyprowski at samsung.com  Tue Feb 16 06:57:00 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 16 Feb 2016 15:57:00 +0100
Subject: [PATCH 07/11] iommu: exynos: refactor init config code
In-Reply-To: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
References: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455634624-18130-8-git-send-email-m.szyprowski@samsung.com>

This patch rewrites sysmmu_init_config function to make it easier to read
and understand.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 25 +++++++++----------------
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 3a577a4..15787a1 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -383,24 +383,17 @@ static bool __sysmmu_disable(struct sysmmu_drvdata *data)
 
 static void __sysmmu_init_config(struct sysmmu_drvdata *data)
 {
-	unsigned int cfg = CFG_LRU | CFG_QOS(15);
-	unsigned int ver;
-
-	ver = MMU_RAW_VER(__raw_readl(data->sfrbase + REG_MMU_VERSION));
-	if (MMU_MAJ_VER(ver) == 3) {
-		if (MMU_MIN_VER(ver) >= 2) {
-			cfg |= CFG_FLPDCACHE;
-			if (MMU_MIN_VER(ver) == 3) {
-				cfg |= CFG_ACGEN;
-				cfg &= ~CFG_LRU;
-			} else {
-				cfg |= CFG_SYSSEL;
-			}
-		}
-	}
+	unsigned int cfg;
+
+	data->version = MMU_RAW_VER(__raw_readl(data->sfrbase + REG_MMU_VERSION));
+	if (data->version <= MAKE_MMU_VER(3, 1))
+		cfg = CFG_LRU | CFG_QOS(15);
+	else if (data->version <= MAKE_MMU_VER(3, 2))
+		cfg = CFG_LRU | CFG_QOS(15) | CFG_FLPDCACHE | CFG_SYSSEL;
+	else
+		cfg = CFG_QOS(15) | CFG_FLPDCACHE | CFG_ACGEN;
 
 	__raw_writel(cfg, data->sfrbase + REG_MMU_CFG);
-	data->version = ver;
 }
 
 static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
-- 
1.9.2



From m.szyprowski at samsung.com  Tue Feb 16 06:56:56 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 16 Feb 2016 15:56:56 +0100
Subject: [PATCH 03/11] iommu: exynos: remove ARM-specific cache flush interface
In-Reply-To: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
References: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455634624-18130-4-git-send-email-m.szyprowski@samsung.com>

This patch replaces custom ARM-specific code for performing CPU cache flush
operations with generic code based on DMA-mapping. Domain managing code
is independent of particular SYSMMU device, so the first registered SYSMMU
device is used for DMA-mapping calls. This simplification works fine
because all SYSMMU controllers are in the same address space (where
DMA address equals physical address) and the DMA-mapping calls are done
mainly to flush CPU cache to make changes visible to SYSMMU controllers.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 74 +++++++++++++++++++++++++++++---------------
 1 file changed, 49 insertions(+), 25 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 595e0da..8c8a7f7 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -27,9 +27,6 @@
 #include <linux/slab.h>
 #include <linux/dma-iommu.h>
 
-#include <asm/cacheflush.h>
-#include <asm/pgtable.h>
-
 typedef u32 sysmmu_iova_t;
 typedef u32 sysmmu_pte_t;
 
@@ -83,6 +80,7 @@ static u32 lv2ent_offset(sysmmu_iova_t iova)
 	return (iova >> SPAGE_ORDER) & (NUM_LV2ENTRIES - 1);
 }
 
+#define LV1TABLE_SIZE (NUM_LV1ENTRIES * sizeof(sysmmu_pte_t))
 #define LV2TABLE_SIZE (NUM_LV2ENTRIES * sizeof(sysmmu_pte_t))
 
 #define SPAGES_PER_LPAGE (LPAGE_SIZE / SPAGE_SIZE)
@@ -134,6 +132,7 @@ static u32 lv2ent_offset(sysmmu_iova_t iova)
 
 #define has_sysmmu(dev)		(dev->archdata.iommu != NULL)
 
+static struct device *dma_dev;
 static struct kmem_cache *lv2table_kmem_cache;
 static sysmmu_pte_t *zero_lv2_table;
 #define ZERO_LV2LINK mk_lv1ent_page(virt_to_phys(zero_lv2_table))
@@ -650,16 +649,19 @@ static struct platform_driver exynos_sysmmu_driver __refdata = {
 	}
 };
 
-static inline void pgtable_flush(void *vastart, void *vaend)
+static inline void update_pte(sysmmu_pte_t *ent, sysmmu_pte_t val)
 {
-	dmac_flush_range(vastart, vaend);
-	outer_flush_range(virt_to_phys(vastart),
-				virt_to_phys(vaend));
+	dma_sync_single_for_cpu(dma_dev, virt_to_phys(ent), sizeof(*ent),
+				DMA_TO_DEVICE);
+	*ent = val;
+	dma_sync_single_for_device(dma_dev, virt_to_phys(ent), sizeof(*ent),
+				   DMA_TO_DEVICE);
 }
 
 static struct iommu_domain *exynos_iommu_domain_alloc(unsigned type)
 {
 	struct exynos_iommu_domain *domain;
+	dma_addr_t handle;
 	int i;
 
 
@@ -694,7 +696,10 @@ static struct iommu_domain *exynos_iommu_domain_alloc(unsigned type)
 		domain->pgtable[i + 7] = ZERO_LV2LINK;
 	}
 
-	pgtable_flush(domain->pgtable, domain->pgtable + NUM_LV1ENTRIES);
+	handle = dma_map_single(dma_dev, domain->pgtable, LV1TABLE_SIZE,
+				DMA_TO_DEVICE);
+	/* For mapping page table entries we rely on dma == phys */
+	BUG_ON(handle != virt_to_phys(domain->pgtable));
 
 	spin_lock_init(&domain->lock);
 	spin_lock_init(&domain->pgtablelock);
@@ -738,10 +743,18 @@ static void exynos_iommu_domain_free(struct iommu_domain *iommu_domain)
 	if (iommu_domain->type == IOMMU_DOMAIN_DMA)
 		iommu_put_dma_cookie(iommu_domain);
 
+	dma_unmap_single(dma_dev, virt_to_phys(domain->pgtable), LV1TABLE_SIZE,
+			 DMA_TO_DEVICE);
+
 	for (i = 0; i < NUM_LV1ENTRIES; i++)
-		if (lv1ent_page(domain->pgtable + i))
+		if (lv1ent_page(domain->pgtable + i)) {
+			phys_addr_t base = lv2table_base(domain->pgtable + i);
+
+			dma_unmap_single(dma_dev, base, LV2TABLE_SIZE,
+					 DMA_TO_DEVICE);
 			kmem_cache_free(lv2table_kmem_cache,
-				phys_to_virt(lv2table_base(domain->pgtable + i)));
+					phys_to_virt(base));
+		}
 
 	free_pages((unsigned long)domain->pgtable, 2);
 	free_pages((unsigned long)domain->lv2entcnt, 1);
@@ -834,11 +847,10 @@ static sysmmu_pte_t *alloc_lv2entry(struct exynos_iommu_domain *domain,
 		if (!pent)
 			return ERR_PTR(-ENOMEM);
 
-		*sent = mk_lv1ent_page(virt_to_phys(pent));
+		update_pte(sent, mk_lv1ent_page(virt_to_phys(pent)));
 		kmemleak_ignore(pent);
 		*pgcounter = NUM_LV2ENTRIES;
-		pgtable_flush(pent, pent + NUM_LV2ENTRIES);
-		pgtable_flush(sent, sent + 1);
+		dma_map_single(dma_dev, pent, LV2TABLE_SIZE, DMA_TO_DEVICE);
 
 		/*
 		 * If pre-fetched SLPD is a faulty SLPD in zero_l2_table,
@@ -891,9 +903,7 @@ static int lv1set_section(struct exynos_iommu_domain *domain,
 		*pgcnt = 0;
 	}
 
-	*sent = mk_lv1ent_sect(paddr);
-
-	pgtable_flush(sent, sent + 1);
+	update_pte(sent, mk_lv1ent_sect(paddr));
 
 	spin_lock(&domain->lock);
 	if (lv1ent_page_zero(sent)) {
@@ -917,12 +927,15 @@ static int lv2set_page(sysmmu_pte_t *pent, phys_addr_t paddr, size_t size,
 		if (WARN_ON(!lv2ent_fault(pent)))
 			return -EADDRINUSE;
 
-		*pent = mk_lv2ent_spage(paddr);
-		pgtable_flush(pent, pent + 1);
+		update_pte(pent, mk_lv2ent_spage(paddr));
 		*pgcnt -= 1;
 	} else { /* size == LPAGE_SIZE */
 		int i;
+		dma_addr_t pent_base = virt_to_phys(pent);
 
+		dma_sync_single_for_cpu(dma_dev, pent_base,
+					sizeof(*pent) * SPAGES_PER_LPAGE,
+					DMA_TO_DEVICE);
 		for (i = 0; i < SPAGES_PER_LPAGE; i++, pent++) {
 			if (WARN_ON(!lv2ent_fault(pent))) {
 				if (i > 0)
@@ -932,7 +945,9 @@ static int lv2set_page(sysmmu_pte_t *pent, phys_addr_t paddr, size_t size,
 
 			*pent = mk_lv2ent_lpage(paddr);
 		}
-		pgtable_flush(pent - SPAGES_PER_LPAGE, pent);
+		dma_sync_single_for_device(dma_dev, pent_base,
+					   sizeof(*pent) * SPAGES_PER_LPAGE,
+					   DMA_TO_DEVICE);
 		*pgcnt -= SPAGES_PER_LPAGE;
 	}
 
@@ -1042,8 +1057,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *iommu_domain,
 		}
 
 		/* workaround for h/w bug in System MMU v3.3 */
-		*ent = ZERO_LV2LINK;
-		pgtable_flush(ent, ent + 1);
+		update_pte(ent, ZERO_LV2LINK);
 		size = SECT_SIZE;
 		goto done;
 	}
@@ -1064,9 +1078,8 @@ static size_t exynos_iommu_unmap(struct iommu_domain *iommu_domain,
 	}
 
 	if (lv2ent_small(ent)) {
-		*ent = 0;
+		update_pte(ent, 0);
 		size = SPAGE_SIZE;
-		pgtable_flush(ent, ent + 1);
 		domain->lv2entcnt[lv1ent_offset(iova)] += 1;
 		goto done;
 	}
@@ -1077,9 +1090,13 @@ static size_t exynos_iommu_unmap(struct iommu_domain *iommu_domain,
 		goto err;
 	}
 
+	dma_sync_single_for_cpu(dma_dev, virt_to_phys(ent),
+				sizeof(*ent) * SPAGES_PER_LPAGE,
+				DMA_TO_DEVICE);
 	memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE);
-	pgtable_flush(ent, ent + SPAGES_PER_LPAGE);
-
+	dma_sync_single_for_device(dma_dev, virt_to_phys(ent),
+				   sizeof(*ent) * SPAGES_PER_LPAGE,
+				   DMA_TO_DEVICE);
 	size = LPAGE_SIZE;
 	domain->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE;
 done:
@@ -1261,6 +1278,13 @@ static int __init exynos_iommu_of_setup(struct device_node *np)
 	if (IS_ERR(pdev))
 		return PTR_ERR(pdev);
 
+	/*
+	 * use the first registered sysmmu device for performing
+	 * dma mapping operations on iommu page tables (cpu cache flush)
+	 */
+	if (!dma_dev)
+		dma_dev = &pdev->dev;
+
 	of_iommu_set_ops(np, &exynos_iommu_ops);
 	return 0;
 }
-- 
1.9.2



From m.szyprowski at samsung.com  Tue Feb 16 06:56:57 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 16 Feb 2016 15:56:57 +0100
Subject: [PATCH 04/11] iommu: exynos: simplify master clock operations
In-Reply-To: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
References: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455634624-18130-5-git-send-email-m.szyprowski@samsung.com>

All clock API function can be called on NULL clock, so simplify code avoid
checking of master clock presence.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 32 ++++++++++++--------------------
 1 file changed, 12 insertions(+), 20 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 8c8a7f7..bf6b826 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -333,8 +333,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 
 	spin_lock(&data->lock);
 
-	if (!IS_ERR(data->clk_master))
-		clk_enable(data->clk_master);
+	clk_enable(data->clk_master);
 
 	itype = (enum exynos_sysmmu_inttype)
 		__ffs(__raw_readl(data->sfrbase + REG_INT_STATUS));
@@ -366,8 +365,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 
 	sysmmu_unblock(data->sfrbase);
 
-	if (!IS_ERR(data->clk_master))
-		clk_disable(data->clk_master);
+	clk_disable(data->clk_master);
 
 	spin_unlock(&data->lock);
 
@@ -376,15 +374,13 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 
 static void __sysmmu_disable_nocount(struct sysmmu_drvdata *data)
 {
-	if (!IS_ERR(data->clk_master))
-		clk_enable(data->clk_master);
+	clk_enable(data->clk_master);
 
 	__raw_writel(CTRL_DISABLE, data->sfrbase + REG_MMU_CTRL);
 	__raw_writel(0, data->sfrbase + REG_MMU_CFG);
 
 	clk_disable(data->clk);
-	if (!IS_ERR(data->clk_master))
-		clk_disable(data->clk_master);
+	clk_disable(data->clk_master);
 }
 
 static bool __sysmmu_disable(struct sysmmu_drvdata *data)
@@ -437,8 +433,7 @@ static void __sysmmu_init_config(struct sysmmu_drvdata *data)
 
 static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
 {
-	if (!IS_ERR(data->clk_master))
-		clk_enable(data->clk_master);
+	clk_enable(data->clk_master);
 	clk_enable(data->clk);
 
 	__raw_writel(CTRL_BLOCK, data->sfrbase + REG_MMU_CTRL);
@@ -449,8 +444,7 @@ static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
 
 	__raw_writel(CTRL_ENABLE, data->sfrbase + REG_MMU_CTRL);
 
-	if (!IS_ERR(data->clk_master))
-		clk_disable(data->clk_master);
+	clk_disable(data->clk_master);
 }
 
 static int __sysmmu_enable(struct sysmmu_drvdata *data, phys_addr_t pgtable,
@@ -493,16 +487,14 @@ static void sysmmu_tlb_invalidate_flpdcache(struct sysmmu_drvdata *data,
 {
 	unsigned long flags;
 
-	if (!IS_ERR(data->clk_master))
-		clk_enable(data->clk_master);
+	clk_enable(data->clk_master);
 
 	spin_lock_irqsave(&data->lock, flags);
 	if (is_sysmmu_active(data))
 		__sysmmu_tlb_invalidate_flpdcache(data, iova);
 	spin_unlock_irqrestore(&data->lock, flags);
 
-	if (!IS_ERR(data->clk_master))
-		clk_disable(data->clk_master);
+	clk_disable(data->clk_master);
 }
 
 static void sysmmu_tlb_invalidate_entry(struct sysmmu_drvdata *data,
@@ -514,8 +506,7 @@ static void sysmmu_tlb_invalidate_entry(struct sysmmu_drvdata *data,
 	if (is_sysmmu_active(data)) {
 		unsigned int num_inv = 1;
 
-		if (!IS_ERR(data->clk_master))
-			clk_enable(data->clk_master);
+		clk_enable(data->clk_master);
 
 		/*
 		 * L2TLB invalidation required
@@ -535,8 +526,7 @@ static void sysmmu_tlb_invalidate_entry(struct sysmmu_drvdata *data,
 				data->sfrbase, iova, num_inv);
 			sysmmu_unblock(data->sfrbase);
 		}
-		if (!IS_ERR(data->clk_master))
-			clk_disable(data->clk_master);
+		clk_disable(data->clk_master);
 	} else {
 		dev_dbg(data->master,
 			"disabled. Skipping TLB invalidation @ %#x\n", iova);
@@ -593,6 +583,8 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 			dev_err(dev, "Failed to prepare master's clk\n");
 			return ret;
 		}
+	} else {
+		data->clk_master = NULL;
 	}
 
 	data->sysmmu = dev;
-- 
1.9.2



From m.szyprowski at samsung.com  Tue Feb 16 06:57:02 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 16 Feb 2016 15:57:02 +0100
Subject: [PATCH 09/11] iommu: exynos: update device tree documentation
In-Reply-To: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
References: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455634624-18130-10-git-send-email-m.szyprowski@samsung.com>

Exynos SYSMMU bindings documentation was merged before generic IOMMU
binding have been introduced. This patch updates documentation to match
current state.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 .../devicetree/bindings/iommu/samsung,sysmmu.txt      | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
index bc620fe..f61ca25 100644
--- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
+++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
@@ -23,28 +23,23 @@ MMUs.
   for window 1, 2 and 3.
 * M2M Scalers and G2D in Exynos5420 has one System MMU on the read channel and
   the other System MMU on the write channel.
-The drivers must consider how to handle those System MMUs. One of the idea is
-to implement child devices or sub-devices which are the client devices of the
-System MMU.
 
-Note:
-The current DT binding for the Exynos System MMU is incomplete.
-The following properties can be removed or changed, if found incompatible with
-the "Generic IOMMU Binding" support for attaching devices to the IOMMU.
+For information on assigning System MMU controller to its peripheral devices,
+see generic IOMMU bindings.
 
 Required properties:
 - compatible: Should be "samsung,exynos-sysmmu"
 - reg: A tuple of base address and size of System MMU registers.
+- #iommu-cells: Should be <0>.
 - interrupt-parent: The phandle of the interrupt controller of System MMU
 - interrupts: An interrupt specifier for interrupt signal of System MMU,
 	      according to the format defined by a particular interrupt
 	      controller.
 - clock-names: Should be "sysmmu" if the System MMU is needed to gate its clock.
 	       Optional "master" if the clock to the System MMU is gated by
-	       another gate clock other than "sysmmu".
-	       Exynos4 SoCs, there needs no "master" clock.
-	       Exynos5 SoCs, some System MMUs must have "master" clocks.
-- clocks: Required if the System MMU is needed to gate its clock.
+	       another gate clock other than "sysmmu" (usually main gate clock
+	       of peripheral device this SYSMMU belongs to).
+- clocks: Phandles for respective clocks described by clock-names.
 - power-domains: Required if the System MMU is needed to gate its power.
 	  Please refer to the following document:
 	  Documentation/devicetree/bindings/power/pd-samsung.txt
@@ -57,6 +52,7 @@ Examples:
 		power-domains = <&pd_gsc>;
 		clocks = <&clock CLK_GSCL0>;
 		clock-names = "gscl";
+		iommus = <&sysmmu_gsc0>;
 	};
 
 	sysmmu_gsc0: sysmmu at 13E80000 {
@@ -67,4 +63,5 @@ Examples:
 		clock-names = "sysmmu", "master";
 		clocks = <&clock CLK_SMMU_GSCL0>, <&clock CLK_GSCL0>;
 		power-domains = <&pd_gsc>;
+		#iommu-cells = <0>;
 	};
-- 
1.9.2



From m.szyprowski at samsung.com  Tue Feb 16 06:57:01 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 16 Feb 2016 15:57:01 +0100
Subject: [PATCH 08/11] iommu: exynos: unify code for fldp cache invalidation
In-Reply-To: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
References: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455634624-18130-9-git-send-email-m.szyprowski@samsung.com>

This patch simplifies the code for handling of flpdcache invalidation.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 15787a1..e42a76c 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -440,13 +440,6 @@ static int __sysmmu_enable(struct sysmmu_drvdata *data, phys_addr_t pgtable,
 	return ret;
 }
 
-static void __sysmmu_tlb_invalidate_flpdcache(struct sysmmu_drvdata *data,
-					      sysmmu_iova_t iova)
-{
-	if (data->version == MAKE_MMU_VER(3, 3))
-		__raw_writel(iova | 0x1, data->sfrbase + REG_MMU_FLUSH_ENTRY);
-}
-
 static void sysmmu_tlb_invalidate_flpdcache(struct sysmmu_drvdata *data,
 					    sysmmu_iova_t iova)
 {
@@ -455,8 +448,10 @@ static void sysmmu_tlb_invalidate_flpdcache(struct sysmmu_drvdata *data,
 	clk_enable(data->clk_master);
 
 	spin_lock_irqsave(&data->lock, flags);
-	if (is_sysmmu_active(data))
-		__sysmmu_tlb_invalidate_flpdcache(data, iova);
+	if (is_sysmmu_active(data)) {
+		if (data->version >= MAKE_MMU_VER(3, 3))
+			__sysmmu_tlb_invalidate_entry(data, iova, 1);
+	}
 	spin_unlock_irqrestore(&data->lock, flags);
 
 	clk_disable(data->clk_master);
-- 
1.9.2



From m.szyprowski at samsung.com  Tue Feb 16 06:57:04 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 16 Feb 2016 15:57:04 +0100
Subject: [PATCH 11/11] iommu: exynos: add Maintainers entry for Exynos SYSMMU
 driver
In-Reply-To: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
References: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455634624-18130-12-git-send-email-m.szyprowski@samsung.com>

Add Marek Szyprowski as maintainer for Exynos IOMMU driver.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7bd927e..1e9c4df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4336,6 +4336,12 @@ L:	dri-devel at lists.freedesktop.org
 S:	Maintained
 F:	drivers/gpu/drm/exynos/exynos_dp*
 
+EXYNOS SYSMMU (IOMMU) driver
+M:	Marek Szyprowski <m.szyprowski at samsung.com>
+L:	iommu at lists.linux-foundation.org
+S:	Maintained
+F:	drivers/iommu/exynos-iommu.c
+
 EXYNOS MIPI DISPLAY DRIVERS
 M:	Inki Dae <inki.dae at samsung.com>
 M:	Donghwa Lee <dh09.lee at samsung.com>
-- 
1.9.2



From m.szyprowski at samsung.com  Tue Feb 16 06:56:58 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 16 Feb 2016 15:56:58 +0100
Subject: [PATCH 05/11] iommu: exynos: refactor code (no direct register access)
In-Reply-To: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
References: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455634624-18130-6-git-send-email-m.szyprowski@samsung.com>

This patch changes some internal functions to have access to the state of
sysmmu device instead of having only it's registers. This will make the
code ready for future extensions.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 40 +++++++++++++++++++---------------------
 1 file changed, 19 insertions(+), 21 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index bf6b826..4275222 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -254,50 +254,49 @@ static bool is_sysmmu_active(struct sysmmu_drvdata *data)
 	return data->activations > 0;
 }
 
-static void sysmmu_unblock(void __iomem *sfrbase)
+static void sysmmu_unblock(struct sysmmu_drvdata *data)
 {
-	__raw_writel(CTRL_ENABLE, sfrbase + REG_MMU_CTRL);
+	__raw_writel(CTRL_ENABLE, data->sfrbase + REG_MMU_CTRL);
 }
 
-static bool sysmmu_block(void __iomem *sfrbase)
+static bool sysmmu_block(struct sysmmu_drvdata *data)
 {
 	int i = 120;
 
-	__raw_writel(CTRL_BLOCK, sfrbase + REG_MMU_CTRL);
-	while ((i > 0) && !(__raw_readl(sfrbase + REG_MMU_STATUS) & 1))
+	__raw_writel(CTRL_BLOCK, data->sfrbase + REG_MMU_CTRL);
+	while ((i > 0) && !(__raw_readl(data->sfrbase + REG_MMU_STATUS) & 1))
 		--i;
 
-	if (!(__raw_readl(sfrbase + REG_MMU_STATUS) & 1)) {
-		sysmmu_unblock(sfrbase);
+	if (!(__raw_readl(data->sfrbase + REG_MMU_STATUS) & 1)) {
+		sysmmu_unblock(data);
 		return false;
 	}
 
 	return true;
 }
 
-static void __sysmmu_tlb_invalidate(void __iomem *sfrbase)
+static void __sysmmu_tlb_invalidate(struct sysmmu_drvdata *data)
 {
-	__raw_writel(0x1, sfrbase + REG_MMU_FLUSH);
+	__raw_writel(0x1, data->sfrbase + REG_MMU_FLUSH);
 }
 
-static void __sysmmu_tlb_invalidate_entry(void __iomem *sfrbase,
+static void __sysmmu_tlb_invalidate_entry(struct sysmmu_drvdata *data,
 				sysmmu_iova_t iova, unsigned int num_inv)
 {
 	unsigned int i;
 
 	for (i = 0; i < num_inv; i++) {
 		__raw_writel((iova & SPAGE_MASK) | 1,
-				sfrbase + REG_MMU_FLUSH_ENTRY);
+				data->sfrbase + REG_MMU_FLUSH_ENTRY);
 		iova += SPAGE_SIZE;
 	}
 }
 
-static void __sysmmu_set_ptbase(void __iomem *sfrbase,
-				       phys_addr_t pgd)
+static void __sysmmu_set_ptbase(struct sysmmu_drvdata *data, phys_addr_t pgd)
 {
-	__raw_writel(pgd, sfrbase + REG_PT_BASE_ADDR);
+	__raw_writel(pgd, data->sfrbase + REG_PT_BASE_ADDR);
 
-	__sysmmu_tlb_invalidate(sfrbase);
+	__sysmmu_tlb_invalidate(data);
 }
 
 static void show_fault_information(const char *name,
@@ -363,7 +362,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 
 	__raw_writel(1 << itype, data->sfrbase + REG_INT_CLEAR);
 
-	sysmmu_unblock(data->sfrbase);
+	sysmmu_unblock(data);
 
 	clk_disable(data->clk_master);
 
@@ -440,7 +439,7 @@ static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
 
 	__sysmmu_init_config(data);
 
-	__sysmmu_set_ptbase(data->sfrbase, data->pgtable);
+	__sysmmu_set_ptbase(data, data->pgtable);
 
 	__raw_writel(CTRL_ENABLE, data->sfrbase + REG_MMU_CTRL);
 
@@ -521,10 +520,9 @@ static void sysmmu_tlb_invalidate_entry(struct sysmmu_drvdata *data,
 		if (MMU_MAJ_VER(data->version) == 2)
 			num_inv = min_t(unsigned int, size / PAGE_SIZE, 64);
 
-		if (sysmmu_block(data->sfrbase)) {
-			__sysmmu_tlb_invalidate_entry(
-				data->sfrbase, iova, num_inv);
-			sysmmu_unblock(data->sfrbase);
+		if (sysmmu_block(data)) {
+			__sysmmu_tlb_invalidate_entry(data, iova, num_inv);
+			sysmmu_unblock(data);
 		}
 		clk_disable(data->clk_master);
 	} else {
-- 
1.9.2



From m.szyprowski at samsung.com  Tue Feb 16 06:57:03 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Tue, 16 Feb 2016 15:57:03 +0100
Subject: [PATCH 10/11] iommu: exynos: add support for v5 SYSMMU
In-Reply-To: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
References: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455634624-18130-11-git-send-email-m.szyprowski@samsung.com>

This patch adds support for v5 of SYSMMU controller, found in Samsung
Exynos 5433 SoCs. The main difference of v5 is support for 36-bit physical
address space and some changes in register layout and core clocks hanging.
This patch also adds support for ARM64 architecture, which is used by
Exynos 5433 SoCs.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 .../devicetree/bindings/iommu/samsung,sysmmu.txt   |   5 +-
 drivers/iommu/Kconfig                              |   2 +-
 drivers/iommu/exynos-iommu.c                       | 195 +++++++++++++++------
 3 files changed, 150 insertions(+), 52 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
index f61ca25..85f0688 100644
--- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
+++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
@@ -35,9 +35,10 @@ Required properties:
 - interrupts: An interrupt specifier for interrupt signal of System MMU,
 	      according to the format defined by a particular interrupt
 	      controller.
-- clock-names: Should be "sysmmu" if the System MMU is needed to gate its clock.
+- clock-names: Should be "sysmmu" or a pair of "aclk" and "pclk" to gate
+	       SYSMMU core clocks.
 	       Optional "master" if the clock to the System MMU is gated by
-	       another gate clock other than "sysmmu" (usually main gate clock
+	       another gate clock other core  (usually main gate clock
 	       of peripheral device this SYSMMU belongs to).
 - clocks: Phandles for respective clocks described by clock-names.
 - power-domains: Required if the System MMU is needed to gate its power.
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index a1e75cb..1674de1 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -243,7 +243,7 @@ config TEGRA_IOMMU_SMMU
 
 config EXYNOS_IOMMU
 	bool "Exynos IOMMU Support"
-	depends on ARCH_EXYNOS && ARM && MMU
+	depends on ARCH_EXYNOS && MMU
 	select IOMMU_API
 	select ARM_DMA_USE_IOMMU
 	help
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index e42a76c..f00378a 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1,6 +1,5 @@
-/* linux/drivers/iommu/exynos_iommu.c
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+/*
+ * Copyright (c) 2011,2016 Samsung Electronics Co., Ltd.
  *		http://www.samsung.com
  *
  * This program is free software; you can redistribute it and/or modify
@@ -55,17 +54,25 @@ typedef u32 sysmmu_pte_t;
 #define lv2ent_small(pent) ((*(pent) & 2) == 2)
 #define lv2ent_large(pent) ((*(pent) & 3) == 1)
 
-static u32 sysmmu_page_offset(sysmmu_iova_t iova, u32 size)
-{
-	return iova & (size - 1);
-}
-
-#define section_phys(sent) (*(sent) & SECT_MASK)
-#define section_offs(iova) sysmmu_page_offset((iova), SECT_SIZE)
-#define lpage_phys(pent) (*(pent) & LPAGE_MASK)
-#define lpage_offs(iova) sysmmu_page_offset((iova), LPAGE_SIZE)
-#define spage_phys(pent) (*(pent) & SPAGE_MASK)
-#define spage_offs(iova) sysmmu_page_offset((iova), SPAGE_SIZE)
+/*
+ * v1.x - v3.x SYSMMU supports 32bit physical and 32bit virtual address spaces
+ * v5.0 introduced support for 36bit physical address space by shifting
+ * all page entry values by 4 bits.
+ * All SYSMMU controllers in the system support the address spaces of the same
+ * size, so PG_ENT_SHIFT can be initialized on first SYSMMU probe to proper
+ * value (0 or 4).
+ */
+static short PG_ENT_SHIFT = -1;
+#define SYSMMU_PG_ENT_SHIFT 0
+#define SYSMMU_V5_PG_ENT_SHIFT 4
+
+#define sect_to_phys(ent) (((phys_addr_t) ent) << PG_ENT_SHIFT)
+#define section_phys(sent) (sect_to_phys(*(sent)) & SECT_MASK)
+#define section_offs(iova) (iova & (SECT_SIZE - 1))
+#define lpage_phys(pent) (sect_to_phys(*(pent)) & LPAGE_MASK)
+#define lpage_offs(iova) (iova & (LPAGE_SIZE - 1))
+#define spage_phys(pent) (sect_to_phys(*(pent)) & SPAGE_MASK)
+#define spage_offs(iova) (iova & (SPAGE_SIZE - 1))
 
 #define NUM_LV1ENTRIES 4096
 #define NUM_LV2ENTRIES (SECT_SIZE / SPAGE_SIZE)
@@ -84,13 +91,12 @@ static u32 lv2ent_offset(sysmmu_iova_t iova)
 #define LV2TABLE_SIZE (NUM_LV2ENTRIES * sizeof(sysmmu_pte_t))
 
 #define SPAGES_PER_LPAGE (LPAGE_SIZE / SPAGE_SIZE)
+#define lv2table_base(sent) (sect_to_phys(*(sent) & 0xFFFFFFC0))
 
-#define lv2table_base(sent) (*(sent) & 0xFFFFFC00)
-
-#define mk_lv1ent_sect(pa) ((pa) | 2)
-#define mk_lv1ent_page(pa) ((pa) | 1)
-#define mk_lv2ent_lpage(pa) ((pa) | 1)
-#define mk_lv2ent_spage(pa) ((pa) | 2)
+#define mk_lv1ent_sect(pa) ((pa >> PG_ENT_SHIFT) | 2)
+#define mk_lv1ent_page(pa) ((pa >> PG_ENT_SHIFT) | 1)
+#define mk_lv2ent_lpage(pa) ((pa >> PG_ENT_SHIFT) | 1)
+#define mk_lv2ent_spage(pa) ((pa >> PG_ENT_SHIFT) | 2)
 
 #define CTRL_ENABLE	0x5
 #define CTRL_BLOCK	0x7
@@ -98,14 +104,23 @@ static u32 lv2ent_offset(sysmmu_iova_t iova)
 
 #define CFG_LRU		0x1
 #define CFG_QOS(n)	((n & 0xF) << 7)
-#define CFG_MASK	0x0150FFFF /* Selecting bit 0-15, 20, 22 and 24 */
 #define CFG_ACGEN	(1 << 24) /* System MMU 3.3 only */
 #define CFG_SYSSEL	(1 << 22) /* System MMU 3.2 only */
 #define CFG_FLPDCACHE	(1 << 20) /* System MMU 3.2+ only */
 
+/* common registers */
 #define REG_MMU_CTRL		0x000
 #define REG_MMU_CFG		0x004
 #define REG_MMU_STATUS		0x008
+#define REG_MMU_VERSION		0x034
+
+#define MMU_MAJ_VER(val)	((val) >> 7)
+#define MMU_MIN_VER(val)	((val) & 0x7F)
+#define MMU_RAW_VER(reg)	(((reg) >> 21) & ((1 << 11) - 1)) /* 11 bits */
+
+#define MAKE_MMU_VER(maj, min)	((((maj) & 0xF) << 7) | ((min) & 0x7F))
+
+/* v1.x - v3.x registers */
 #define REG_MMU_FLUSH		0x00C
 #define REG_MMU_FLUSH_ENTRY	0x010
 #define REG_PT_BASE_ADDR	0x014
@@ -117,18 +132,14 @@ static u32 lv2ent_offset(sysmmu_iova_t iova)
 #define REG_AR_FAULT_ADDR	0x02C
 #define REG_DEFAULT_SLAVE_ADDR	0x030
 
-#define REG_MMU_VERSION		0x034
-
-#define MMU_MAJ_VER(val)	((val) >> 7)
-#define MMU_MIN_VER(val)	((val) & 0x7F)
-#define MMU_RAW_VER(reg)	(((reg) >> 21) & ((1 << 11) - 1)) /* 11 bits */
-
-#define MAKE_MMU_VER(maj, min)	((((maj) & 0xF) << 7) | ((min) & 0x7F))
-
-#define REG_PB0_SADDR		0x04C
-#define REG_PB0_EADDR		0x050
-#define REG_PB1_SADDR		0x054
-#define REG_PB1_EADDR		0x058
+/* v5.x registers */
+#define REG_V5_PT_BASE_PFN	0x00C
+#define REG_V5_MMU_FLUSH_ALL	0x010
+#define REG_V5_MMU_FLUSH_ENTRY	0x014
+#define REG_V5_INT_STATUS	0x060
+#define REG_V5_INT_CLEAR	0x064
+#define REG_V5_FAULT_AR_VA	0x070
+#define REG_V5_FAULT_AW_VA	0x080
 
 #define has_sysmmu(dev)		(dev->archdata.iommu != NULL)
 
@@ -169,6 +180,19 @@ static const struct sysmmu_fault_info sysmmu_faults[] = {
 	{ 7, REG_AW_FAULT_ADDR, "AW ACCESS PROTECTION", IOMMU_FAULT_WRITE },
 };
 
+static const struct sysmmu_fault_info sysmmu_v5_faults[] = {
+	{ 0, REG_V5_FAULT_AR_VA, "AR PTW", IOMMU_FAULT_READ },
+	{ 1, REG_V5_FAULT_AR_VA, "AR PAGE", IOMMU_FAULT_READ },
+	{ 2, REG_V5_FAULT_AR_VA, "AR MULTI-HIT", IOMMU_FAULT_READ },
+	{ 3, REG_V5_FAULT_AR_VA, "AR ACCESS PROTECTION", IOMMU_FAULT_READ },
+	{ 4, REG_V5_FAULT_AR_VA, "AR SECURITY PROTECTION", IOMMU_FAULT_READ },
+	{ 16, REG_V5_FAULT_AW_VA, "AW PTW", IOMMU_FAULT_WRITE },
+	{ 17, REG_V5_FAULT_AW_VA, "AW PAGE", IOMMU_FAULT_WRITE },
+	{ 18, REG_V5_FAULT_AW_VA, "AW MULTI-HIT", IOMMU_FAULT_WRITE },
+	{ 19, REG_V5_FAULT_AW_VA, "AW ACCESS PROTECTION", IOMMU_FAULT_WRITE },
+	{ 20, REG_V5_FAULT_AW_VA, "AW SECURITY PROTECTION", IOMMU_FAULT_WRITE },
+};
+
 /*
  * This structure is attached to dev.archdata.iommu of the master device
  * on device add, contains a list of SYSMMU controllers defined by device tree,
@@ -205,6 +229,8 @@ struct sysmmu_drvdata {
 	struct device *master;		/* master device (owner) */
 	void __iomem *sfrbase;		/* our registers */
 	struct clk *clk;		/* SYSMMU's clock */
+	struct clk *aclk;		/* SYSMMU's aclk clock */
+	struct clk *pclk;		/* SYSMMU's pclk clock */
 	struct clk *clk_master;		/* master's device clock */
 	int activations;		/* number of calls to sysmmu_enable */
 	spinlock_t lock;		/* lock for modyfying state */
@@ -262,7 +288,10 @@ static bool sysmmu_block(struct sysmmu_drvdata *data)
 
 static void __sysmmu_tlb_invalidate(struct sysmmu_drvdata *data)
 {
-	__raw_writel(0x1, data->sfrbase + REG_MMU_FLUSH);
+	if (MMU_MAJ_VER(data->version) < 5)
+		__raw_writel(0x1, data->sfrbase + REG_MMU_FLUSH);
+	else
+		__raw_writel(0x1, data->sfrbase + REG_V5_MMU_FLUSH_ALL);
 }
 
 static void __sysmmu_tlb_invalidate_entry(struct sysmmu_drvdata *data,
@@ -271,15 +300,23 @@ static void __sysmmu_tlb_invalidate_entry(struct sysmmu_drvdata *data,
 	unsigned int i;
 
 	for (i = 0; i < num_inv; i++) {
-		__raw_writel((iova & SPAGE_MASK) | 1,
-				data->sfrbase + REG_MMU_FLUSH_ENTRY);
+		if (MMU_MAJ_VER(data->version) < 5)
+			__raw_writel((iova & SPAGE_MASK) | 1,
+				     data->sfrbase + REG_MMU_FLUSH_ENTRY);
+		else
+			__raw_writel((iova & SPAGE_MASK) | 1,
+				     data->sfrbase + REG_V5_MMU_FLUSH_ENTRY);
 		iova += SPAGE_SIZE;
 	}
 }
 
 static void __sysmmu_set_ptbase(struct sysmmu_drvdata *data, phys_addr_t pgd)
 {
-	__raw_writel(pgd, data->sfrbase + REG_PT_BASE_ADDR);
+	if (MMU_MAJ_VER(data->version) < 5)
+		__raw_writel(pgd, data->sfrbase + REG_PT_BASE_ADDR);
+	else
+		__raw_writel(pgd >> PAGE_SHIFT,
+			     data->sfrbase + REG_V5_PT_BASE_PFN);
 
 	__sysmmu_tlb_invalidate(data);
 }
@@ -304,19 +341,31 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 {
 	/* SYSMMU is in blocked state when interrupt occurred. */
 	struct sysmmu_drvdata *data = dev_id;
-	const struct sysmmu_fault_info *finfo = sysmmu_faults;
-	int i, n = ARRAY_SIZE(sysmmu_faults);
-	unsigned int itype;
+	const struct sysmmu_fault_info *finfo;
+	unsigned int i, n, itype;
 	sysmmu_iova_t fault_addr = -1;
+	unsigned short reg_status, reg_clear;
 	int ret = -ENOSYS;
 
 	WARN_ON(!is_sysmmu_active(data));
 
+	if (MMU_MAJ_VER(data->version) < 5) {
+		reg_status = REG_INT_STATUS;
+		reg_clear = REG_INT_CLEAR;
+		finfo = sysmmu_faults;
+		n = ARRAY_SIZE(sysmmu_faults);
+	} else {
+		reg_status = REG_V5_INT_STATUS;
+		reg_clear = REG_V5_INT_CLEAR;
+		finfo = sysmmu_v5_faults;
+		n = ARRAY_SIZE(sysmmu_v5_faults);
+	}
+
 	spin_lock(&data->lock);
 
 	clk_enable(data->clk_master);
 
-	itype = __ffs(__raw_readl(data->sfrbase + REG_INT_STATUS));
+	itype = __ffs(__raw_readl(data->sfrbase + reg_status));
 	for (i = 0; i < n; i++, finfo++)
 		if (finfo->bit == itype)
 			break;
@@ -333,7 +382,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 	/* fault is not recovered by fault handler */
 	BUG_ON(ret != 0);
 
-	__raw_writel(1 << itype, data->sfrbase + REG_INT_CLEAR);
+	__raw_writel(1 << itype, data->sfrbase + reg_clear);
 
 	sysmmu_unblock(data);
 
@@ -351,6 +400,8 @@ static void __sysmmu_disable_nocount(struct sysmmu_drvdata *data)
 	__raw_writel(CTRL_DISABLE, data->sfrbase + REG_MMU_CTRL);
 	__raw_writel(0, data->sfrbase + REG_MMU_CFG);
 
+	clk_disable(data->aclk);
+	clk_disable(data->pclk);
 	clk_disable(data->clk);
 	clk_disable(data->clk_master);
 }
@@ -385,7 +436,6 @@ static void __sysmmu_init_config(struct sysmmu_drvdata *data)
 {
 	unsigned int cfg;
 
-	data->version = MMU_RAW_VER(__raw_readl(data->sfrbase + REG_MMU_VERSION));
 	if (data->version <= MAKE_MMU_VER(3, 1))
 		cfg = CFG_LRU | CFG_QOS(15);
 	else if (data->version <= MAKE_MMU_VER(3, 2))
@@ -400,6 +450,8 @@ static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
 {
 	clk_enable(data->clk_master);
 	clk_enable(data->clk);
+	clk_enable(data->pclk);
+	clk_enable(data->aclk);
 
 	__raw_writel(CTRL_BLOCK, data->sfrbase + REG_MMU_CTRL);
 
@@ -523,22 +575,47 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 	}
 
 	data->clk = devm_clk_get(dev, "sysmmu");
-	if (IS_ERR(data->clk)) {
-		dev_err(dev, "Failed to get clock!\n");
-		return PTR_ERR(data->clk);
-	} else  {
+	if (!IS_ERR(data->clk)) {
 		ret = clk_prepare(data->clk);
 		if (ret) {
 			dev_err(dev, "Failed to prepare clk\n");
 			return ret;
 		}
+	} else {
+		data->clk = NULL;
+	}
+
+	data->aclk = devm_clk_get(dev, "aclk");
+	if (!IS_ERR(data->aclk)) {
+		ret = clk_prepare(data->aclk);
+		if (ret) {
+			dev_err(dev, "Failed to prepare aclk\n");
+			return ret;
+		}
+	} else {
+		data->aclk = NULL;
+	}
+
+	data->pclk = devm_clk_get(dev, "pclk");
+	if (!IS_ERR(data->pclk)) {
+		ret = clk_prepare(data->pclk);
+		if (ret) {
+			dev_err(dev, "Failed to prepare pclk\n");
+			return ret;
+		}
+	} else {
+		data->pclk = NULL;
+	}
+
+	if (!data->clk && (!data->aclk || !data->pclk)) {
+		dev_err(dev, "Failed to get device clock(s)!\n");
+		return -ENOSYS;
 	}
 
 	data->clk_master = devm_clk_get(dev, "master");
 	if (!IS_ERR(data->clk_master)) {
 		ret = clk_prepare(data->clk_master);
 		if (ret) {
-			clk_unprepare(data->clk);
 			dev_err(dev, "Failed to prepare master's clk\n");
 			return ret;
 		}
@@ -551,6 +628,24 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, data);
 
+	clk_enable(data->clk);
+	clk_enable(data->pclk);
+	clk_enable(data->aclk);
+
+	data->version = MMU_RAW_VER(
+				__raw_readl(data->sfrbase + REG_MMU_VERSION));
+
+	if (PG_ENT_SHIFT < 0) {
+		if (MMU_MAJ_VER(data->version) < 5)
+			PG_ENT_SHIFT = SYSMMU_PG_ENT_SHIFT;
+		else
+			PG_ENT_SHIFT = SYSMMU_V5_PG_ENT_SHIFT;
+	}
+
+	clk_disable(data->aclk);
+	clk_disable(data->pclk);
+	clk_disable(data->clk);
+
 	pm_runtime_enable(dev);
 
 	return 0;
@@ -615,6 +710,8 @@ static struct iommu_domain *exynos_iommu_domain_alloc(unsigned type)
 	dma_addr_t handle;
 	int i;
 
+	/* Check if correct PTE offsets are initialized */
+	BUG_ON(PG_ENT_SHIFT < 0 || !dma_dev);
 
 	domain = kzalloc(sizeof(*domain), GFP_KERNEL);
 	if (!domain)
@@ -794,7 +891,7 @@ static sysmmu_pte_t *alloc_lv2entry(struct exynos_iommu_domain *domain,
 		bool need_flush_flpd_cache = lv1ent_zero(sent);
 
 		pent = kmem_cache_zalloc(lv2table_kmem_cache, GFP_ATOMIC);
-		BUG_ON((unsigned int)pent & (LV2TABLE_SIZE - 1));
+		BUG_ON((phys_addr_t)pent & (LV2TABLE_SIZE - 1));
 		if (!pent)
 			return ERR_PTR(-ENOMEM);
 
-- 
1.9.2



From festevam at gmail.com  Tue Feb 16 07:01:19 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 16 Feb 2016 13:01:19 -0200
Subject: noise issues when recording sound on i.MX28
In-Reply-To: <20160211084029.GE13664@pengutronix.de>
References: <20160127105613.GC13664@pengutronix.de>
 <CAOMZO5BpLen517q2heramSta-R6pdESkjM6w=7FRMZebY6ue-Q@mail.gmail.com>
 <20160127144340.GD13664@pengutronix.de>
 <CAOMZO5AE6HwBYz7kOFORt0HTojJLSb0MYUbkb_HCshDHy=d27g@mail.gmail.com>
 <20160210150315.GC13664@pengutronix.de>
 <CAOMZO5D5H4F90nse9kyW9KvsJStN-sCGktup4FDPw_zTeNfS2g@mail.gmail.com>
 <20160211084029.GE13664@pengutronix.de>
Message-ID: <CAOMZO5BDjkWi+cQK1-J7ag8Z48tY1Uwofi4EkovN-drSC4_reA@mail.gmail.com>

On Thu, Feb 11, 2016 at 6:40 AM, Uwe Kleine-K?nig
<u.kleine-koenig at pengutronix.de> wrote:

> root at hostname:/sys/kernel/debug/clk find -name saif?_sel
> ./ref_xtal/pll0/saif0_sel
> ./ref_xtal/pll0/saif1_sel
>
> root at hostname:/sys/kernel/debug/clk cat ./ref_xtal/pll0/saif?_sel/clk_rate
> 480000000
> 480000000

Ok, what about the SAIF0 and SAIF1 sampling rates: are they always the same?


From robin.murphy at arm.com  Tue Feb 16 07:02:21 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue, 16 Feb 2016 15:02:21 +0000
Subject: [PATCH] ARM64: dma-mapping: fix IOMMU-based dma_mmap_atts()
 implementation
In-Reply-To: <1455632065-14620-1-git-send-email-m.szyprowski@samsung.com>
References: <1455632065-14620-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <56C339FD.6040907@arm.com>

Hi Marek,

On 16/02/16 14:14, Marek Szyprowski wrote:
> IOMMU-based DMA-mapping implementation doesn't support
> dma_declare_coherent() based regions, so there is no point to call
> dma_mmap_from_coherent() from __iommu_mmap_atts(). This patch removes
> useless code.

I'm not sure that's the case - AFAICS a device could still have its own 
local memory despite being behind an IOMMU relative to the rest of the 
system. If it uses dma_declare_coherent() for that, the .alloc and .free 
callbacks here might be bypassed by dma_{alloc,free}_attrs() 
short-circuiting into dma_{alloc,release}_from_coherent(), but in the 
case of dma_mmap_attrs() it hits the .mmap callback first and only falls 
back to the from_coherent check in dma_common_mmap() if that isn't 
implemented.

Maybe the right thing to do would be to move this check (with its 
associated guards) out from dma_common_mmap() up to dma_mmap_attrs() to 
be consistent with alloc/free; so that it doesn't need to be 
reimplemented all over arch/{arm,arm64,mips} at all?

Robin.

> Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
> ---
>   arch/arm64/mm/dma-mapping.c | 5 -----
>   1 file changed, 5 deletions(-)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 331c4ca..573b1e6 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -636,14 +636,9 @@ static int __iommu_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
>   			      struct dma_attrs *attrs)
>   {
>   	struct vm_struct *area;
> -	int ret;
>
>   	vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot,
>   					     is_device_dma_coherent(dev));
> -
> -	if (dma_mmap_from_coherent(dev, vma, cpu_addr, size, &ret))
> -		return ret;
> -
>   	area = find_vm_area(cpu_addr);
>   	if (WARN_ON(!area || !area->pages))
>   		return -ENXIO;
>



From arnd at arndb.de  Tue Feb 16 07:03:23 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 16:03:23 +0100
Subject: [PATCH v2] xen kconfig: don't "select INPUT_XEN_KBDDEV_FRONTEND"
In-Reply-To: <alpine.DEB.2.02.1602151708110.27008@kaball.uk.xensource.com>
References: <1455278707-2008263-1-git-send-email-arnd@arndb.de>
 <56C20552.8030305@citrix.com>
 <alpine.DEB.2.02.1602151708110.27008@kaball.uk.xensource.com>
Message-ID: <2479546.WgivMO2bp2@wuerfel>

The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:

drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'

This removes the extra "select", as it just causes more trouble than
it helps. In theory, some defconfig file might break if it has
XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig
fragment we ship in the kernel (kernel/configs/xen.config) however
already enables both, and anyone using an old .config file would
keep having both enabled.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Suggested-by: David Vrabel <david.vrabel at citrix.com>
Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8ea45a5cd806..d889ef2048df 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2246,7 +2246,6 @@ config XEN_FBDEV_FRONTEND
 	select FB_SYS_IMAGEBLIT
 	select FB_SYS_FOPS
 	select FB_DEFERRED_IO
-	select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
 	select XEN_XENBUS_FRONTEND
 	default y
 	help



From arnd at arndb.de  Tue Feb 16 07:05:20 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 16:05:20 +0100
Subject: [PATCH] xen kconfig: clarify INPUT_XEN_KBDDEV_FRONTEND select
In-Reply-To: <alpine.DEB.2.02.1602161156160.27008@kaball.uk.xensource.com>
References: <1455278707-2008263-1-git-send-email-arnd@arndb.de>
 <2801550.oZPkqjv8nW@wuerfel>
 <alpine.DEB.2.02.1602161156160.27008@kaball.uk.xensource.com>
Message-ID: <2697712.W9djLKoMG1@wuerfel>

On Tuesday 16 February 2016 12:14:14 Stefano Stabellini wrote:
> > at all.
> 
> Please correct me if I am wrong, but the difference is that with this
> change if INPUT=m, then the build system would ask the user whether she
> wants to select INPUT_XEN_KBDDEV_FRONTEND as m or y, instead of
> unconditionally set INPUT_XEN_KBDDEV_FRONTEND=y.

INPUT_XEN_KBDDEV_FRONTEND cannot be set by the user to 'y' if
INPUT=m, because of an implied dependency around the input/misc/Kconfig
file.

> However it is true that if the users chooses
> INPUT_XEN_KBDDEV_FRONTEND=y, then the problem persists.
> Maybe we also need:
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 1f2337a..303df24 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -721,7 +721,7 @@ config INPUT_CMA3000_I2C
>  
>  config INPUT_XEN_KBDDEV_FRONTEND
>         tristate "Xen virtual keyboard and mouse support"
> -       depends on XEN
> +       depends on XEN && INPUT
>         default y
>         select XEN_XENBUS_FRONTEND
>         help
> 
> 
> Do you have a kernel config with INPUT=m that I can use to test with?

You can easily set that in any config if you disable CONFIG_VT. I don't
think it's worth spending more time on that, as everyone seems to be
happy with just removing the 'select', and I've sent a replacement
patch to do that.

	Arnd


From arnd at arndb.de  Tue Feb 16 07:08:34 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 16:08:34 +0100
Subject: [PATCH v3 08/10] ARM: configs: add MPS2 defconfig
In-Reply-To: <56C3378F.2010008@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <2680417.bULLX3O66Y@wuerfel> <56C3378F.2010008@arm.com>
Message-ID: <11778979.HbWgmZUCnF@wuerfel>

On Tuesday 16 February 2016 14:51:59 Vladimir Murzin wrote:
> > 
> > Why CONFIG_EMBEDDED? You probably mean CONFIG_EXPERT, but then what do
> > you need that for?
> 
> TBH, I have no special requirement for this option to be set and now,
> looking at Kconfig entry for this option, I think that I got it here
> because I stated configuration with allnoconfig.
> 
> OTOH, I don't see how harmful it can be since description says:
> 
>           This option should be enabled if compiling the kernel for
>           an embedded system so certain expert options are available
>           for configuration
> 
> yes, it selects CONFIG_EXPERT and that had side effect that, for
> example, CONFIG_NAMESPACE could be compiled out.
> 
> Have I missed something around it?

Just the history behind this symbol. We removed it a while ago in
favor if CONFIG_EXPERT, assuming that it makes it clearer that it's
not just for embedded systems, or for systems with small memory.

It's  basically a zombie symbol that nobody should use directly
(independent of what the documentation says...).

	Arnd


From vladimir.murzin at arm.com  Tue Feb 16 07:09:58 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 15:09:58 +0000
Subject: [PATCH v3 04/10] serial: mps2-uart: add MPS2 UART driver
In-Reply-To: <20160216110217.3de7c007@lxorguk.ukuu.org.uk>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-5-git-send-email-vladimir.murzin@arm.com>
 <20160216110217.3de7c007@lxorguk.ukuu.org.uk>
Message-ID: <56C33BC6.1040801@arm.com>

On 16/02/16 11:02, One Thousand Gnomes wrote:
> 
>> +static void mps2_uart_set_termios(struct uart_port *port,
>> +	struct ktermios *new, struct ktermios *old)
> 
> Not that I care much but you might not want to call it "new". People get
> upset when their syntax aware editors get confused by C++ keywords 8)

Just renamed it to have cpp suffix and looks like my editor falls under
that category :)

> 
>> +{
>> +	unsigned long flags;
>> +	unsigned int baud, bauddiv;
>> +
>> +	new->c_cflag &= ~(CRTSCTS | CMSPAR);
>> +	new->c_cflag &= ~CSIZE;
>> +	new->c_cflag |= CS8;
>> +	new->c_cflag &= ~PARENB;
>> +	new->c_cflag &= ~CSTOPB;
>> +
>> +	baud = uart_get_baud_rate(port, new, old,
>> +			DIV_ROUND_CLOSEST(port->uartclk, UARTn_BAUDDIV_MASK),
>> +			DIV_ROUND_CLOSEST(port->uartclk, 16));
>> +
>> +	bauddiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
>> +
>> +	spin_lock_irqsave(&port->lock, flags);
>> +
>> +	uart_update_timeout(port, new->c_cflag, baud);
>> +	mps2_uart_write32(port, bauddiv, UARTn_BAUDDIV);
> 
> This should also set the baud bits back in the termios struct
> accordingly. 
> 
> 	if (tty_termios_baud_rate(new))
> 		tty_termios_encode_baud_rate(new, baud, baud);
> 
> 
> Not a big deal and could certainly be a follow up patch after it's merged.

I'll fold it in the next version.

Thanks
Vladimir

> 
> Alan
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> 
> 



From marc.zyngier at arm.com  Tue Feb 16 07:11:22 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 16 Feb 2016 15:11:22 +0000
Subject: [PATCH] KVM: arm/arm64: vgic: ensure bitmaps are long enough
In-Reply-To: <1455634051-1860-1-git-send-email-mark.rutland@arm.com>
References: <1455634051-1860-1-git-send-email-mark.rutland@arm.com>
Message-ID: <56C33C1A.3090703@arm.com>

On 16/02/16 14:47, Mark Rutland wrote:
> When we allocate bitmaps in vgic_vcpu_init_maps, we divide the number of
> bits we need by 8 to figure out how many bytes to allocate. However,
> bitmap elements are always accessed as unsigned longs, and if we didn't
> happen to allocate a size such that size % sizeof(unsigned long) == 0,
> bitmap accesses may go past the end of the allocation.
> 
> When using KASAN (which does byte-granular access checks), this results
> in a continuous stream of BUGs whenever these bitmaps are accessed:
> 
> =============================================================================
> BUG kmalloc-128 (Tainted: G    B          ): kasan: bad access detected
> -----------------------------------------------------------------------------
> 
> INFO: Allocated in vgic_init.part.25+0x55c/0x990 age=7493 cpu=3 pid=1730
> INFO: Slab 0xffffffbde6d5da40 objects=16 used=15 fp=0xffffffc935769700 flags=0x4000000000000080
> INFO: Object 0xffffffc935769500 @offset=1280 fp=0x          (null)
> 
> Bytes b4 ffffffc9357694f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> Object ffffffc935769500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> Object ffffffc935769510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> Object ffffffc935769520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> Object ffffffc935769530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> Object ffffffc935769540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> Object ffffffc935769550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> Object ffffffc935769560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> Object ffffffc935769570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> Padding ffffffc9357695b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> Padding ffffffc9357695c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> Padding ffffffc9357695d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> Padding ffffffc9357695e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> Padding ffffffc9357695f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> CPU: 3 PID: 1740 Comm: kvm-vcpu-0 Tainted: G    B           4.4.0+ #17
> Hardware name: ARM Juno development board (r1) (DT)
> Call trace:
> [<ffffffc00008e770>] dump_backtrace+0x0/0x280
> [<ffffffc00008ea04>] show_stack+0x14/0x20
> [<ffffffc000726360>] dump_stack+0x100/0x188
> [<ffffffc00030d324>] print_trailer+0xfc/0x168
> [<ffffffc000312294>] object_err+0x3c/0x50
> [<ffffffc0003140fc>] kasan_report_error+0x244/0x558
> [<ffffffc000314548>] __asan_report_load8_noabort+0x48/0x50
> [<ffffffc000745688>] __bitmap_or+0xc0/0xc8
> [<ffffffc0000d9e44>] kvm_vgic_flush_hwstate+0x1bc/0x650
> [<ffffffc0000c514c>] kvm_arch_vcpu_ioctl_run+0x2ec/0xa60
> [<ffffffc0000b9a6c>] kvm_vcpu_ioctl+0x474/0xa68
> [<ffffffc00036b7b0>] do_vfs_ioctl+0x5b8/0xcb0
> [<ffffffc00036bf34>] SyS_ioctl+0x8c/0xa0
> [<ffffffc000086cb0>] el0_svc_naked+0x24/0x28
> Memory state around the buggy address:
>  ffffffc935769400: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  ffffffc935769480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ffffffc935769500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>                    ^
>  ffffffc935769580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  ffffffc935769600: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
> 
> Fix the issue by always allocating a multiple of sizeof(unsigned long),
> as we do elsewhere in the vgic code.
> 
> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> Cc: Marc Zyngier <marc.zyngier at arm.com>
> Cc: Christoffer Dall <christoffer.dall at linaro.org>
> ---
>  virt/kvm/arm/vgic.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> index 7a2f449..5d10f10 100644
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@ -1875,8 +1875,8 @@ void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
>  static int vgic_vcpu_init_maps(struct kvm_vcpu *vcpu, int nr_irqs)
>  {
>  	struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
> -
> -	int sz = (nr_irqs - VGIC_NR_PRIVATE_IRQS) / 8;
> +	int nr_longs = BITS_TO_LONGS(nr_irqs - VGIC_NR_PRIVATE_IRQS);
> +	int sz = nr_longs * sizeof(unsigned long);
>  	vgic_cpu->pending_shared = kzalloc(sz, GFP_KERNEL);
>  	vgic_cpu->active_shared = kzalloc(sz, GFP_KERNEL);
>  	vgic_cpu->pend_act_shared = kzalloc(sz, GFP_KERNEL);
> 

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

Worth mentioning:

Fixes: c1bfb577a ("arm/arm64: KVM: vgic: switch to dynamic allocation")
Cc: stable at vger.kernel.org

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From will.deacon at arm.com  Tue Feb 16 07:12:53 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 16 Feb 2016 15:12:53 +0000
Subject: [PATCH v3 5/5] arm64/perf: Extend event mask for ARMv8.1
In-Reply-To: <20160216080015.GA3490@hardcore>
References: <cover.1454516082.git.jglauber@cavium.com>
 <fa91eaedf581e6a7053899f25b1b08458dbd4b8e.1454516082.git.jglauber@cavium.com>
 <20160215200404.GX6298@arm.com> <20160216080015.GA3490@hardcore>
Message-ID: <20160216151252.GG14509@arm.com>

On Tue, Feb 16, 2016 at 09:00:15AM +0100, Jan Glauber wrote:
> On Mon, Feb 15, 2016 at 08:04:04PM +0000, Will Deacon wrote:
> 
> [...]
> 
> > On Wed, Feb 03, 2016 at 06:12:00PM +0100, Jan Glauber wrote:
> > > +		cpu_pmu->event_mask = 0xffff;	/* ARMv8.1 extended events */
> > > +	else
> > > +		cpu_pmu->event_mask = ARMV8_EVTYPE_EVENT;
> > 
> > ... although can't we just update ARMV8_EVTYPE_EVENT to be 0xffff now?
> > AFAICT, that just eats into bits that used to be RES0, so we shouldn't
> > see any problems. That should make your patch *much* simpler!
> 
> That would of course be easier, but I just can't assess the implications.
> 
> Probably I'm missing something but to me it looks like the event mask is the
> only verification we do for the user-space selectable events. Is it safe for
> implementations that only support 0x3ff events to allow access to the
> whole 0xffff range? What memory would be accessed for non-existing
> events?

Which memory? The worst-case is that we end up writing to some bits in
a register (e.g. PMXEVTYPER) that are RES0 in ARMv8 afaict.

Will


From vladimir.murzin at arm.com  Tue Feb 16 07:14:14 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 15:14:14 +0000
Subject: [PATCH v3 08/10] ARM: configs: add MPS2 defconfig
In-Reply-To: <11778979.HbWgmZUCnF@wuerfel>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <2680417.bULLX3O66Y@wuerfel> <56C3378F.2010008@arm.com>
 <11778979.HbWgmZUCnF@wuerfel>
Message-ID: <56C33CC6.4030509@arm.com>

On 16/02/16 15:08, Arnd Bergmann wrote:
> On Tuesday 16 February 2016 14:51:59 Vladimir Murzin wrote:
>>>
>>> Why CONFIG_EMBEDDED? You probably mean CONFIG_EXPERT, but then what do
>>> you need that for?
>>
>> TBH, I have no special requirement for this option to be set and now,
>> looking at Kconfig entry for this option, I think that I got it here
>> because I stated configuration with allnoconfig.
>>
>> OTOH, I don't see how harmful it can be since description says:
>>
>>           This option should be enabled if compiling the kernel for
>>           an embedded system so certain expert options are available
>>           for configuration
>>
>> yes, it selects CONFIG_EXPERT and that had side effect that, for
>> example, CONFIG_NAMESPACE could be compiled out.
>>
>> Have I missed something around it?
> 
> Just the history behind this symbol. We removed it a while ago in
> favor if CONFIG_EXPERT, assuming that it makes it clearer that it's
> not just for embedded systems, or for systems with small memory.
> 
> It's  basically a zombie symbol that nobody should use directly
> (independent of what the documentation says...).

Good to know! I'll drop it then.

Thanks
Vladimir

> 
> 	Arnd
> 
> 
> 



From ard.biesheuvel at linaro.org  Tue Feb 16 07:17:40 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 16:17:40 +0100
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <56C31D1D.50708@virtuozzo.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com>
Message-ID: <CAKv+Gu8WE=fTZF0Pou24FKDocgshWu8dJRbaC5SJ11E-6T=2Hw@mail.gmail.com>

On 16 February 2016 at 13:59, Andrey Ryabinin <aryabinin at virtuozzo.com> wrote:
>
>
> On 02/15/2016 09:59 PM, Catalin Marinas wrote:
>> On Mon, Feb 15, 2016 at 05:28:02PM +0300, Andrey Ryabinin wrote:
>>> On 02/12/2016 07:06 PM, Catalin Marinas wrote:
>>>> So far, we have:
>>>>
>>>> KASAN+for-next/kernmap goes wrong
>>>> KASAN+UBSAN goes wrong
>>>>
>>>> Enabled individually, KASAN, UBSAN and for-next/kernmap seem fine. I may
>>>> have to trim for-next/core down until we figure out where the problem
>>>> is.
>>>>
>>>> BUG: KASAN: stack-out-of-bounds in find_busiest_group+0x164/0x16a0 at addr ffffffc93665bc8c
>>>
>>> Can it be related to TLB conflicts, which supposed to be fixed in
>>> "arm64: kasan: avoid TLB conflicts" patch from "arm64: mm: rework page
>>> table creation" series ?
>>
>> I can very easily reproduce this with a vanilla 4.5-rc1 series by
>> enabling inline instrumentation (maybe Mark's theory is true w.r.t.
>> image size).
>>
>> Some information, maybe you can shed some light on this. It seems to
>> happen only for secondary CPUs on the swapper stack (I think allocated
>> via fork_idle()). The code generated looks sane to me, so KASAN should
>> not complain but maybe there is some uninitialised shadow, hence the
>> error.
>>
>> The report:
>>
>
> Actually, the first report is a bit more useful. It shows that shadow memory was corrupted:
>
>   ffffffc93665bc00: f1 f1 f1 f1 00 f4 f4 f4 f2 f2 f2 f2 00 00 f1 f1
>> ffffffc93665bc80: f1 f1 00 00 00 00 f3 f3 00 f4 f4 f4 f3 f3 f3 f3
>                       ^
> F1 - left redzone, it indicates start of stack frame
> F3 - right redzone, it should be the end of stack frame.
>
> But here we have the second set of F1s without F3s which should close the first set of F1s.
> Also those two F3s in the middle cannot be right.
>
> So shadow is corrupted.
> Some hypotheses:
>
> 1) We share stack between several tasks (e.g. stack overflow, somehow corrupted SP).
>     But this probably should cause kernel crash later, after kasan reports.
>
> 2) Shadow memory wasn't cleared. GCC poison memory on function entrance and unpoisons it before return.
>      If we use some tricky way to exit from function this could cause false-positives like that.
>      E.g. some hand-written assembly return code.
>
> 3) Screwed shadow mapping. I think the patch below should uncover such problem.
> It boot-tested on qemu and didn't show any problem
>

I think this patch gives false positive warnings in some cases:

>
> ---
>  arch/arm64/mm/kasan_init.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 55 insertions(+)
>
> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
> index cf038c7..25d685c 100644
> --- a/arch/arm64/mm/kasan_init.c
> +++ b/arch/arm64/mm/kasan_init.c
> @@ -117,6 +117,59 @@ static void __init cpu_set_ttbr1(unsigned long ttbr1)
>         : "r" (ttbr1));
>  }
>
> +static void verify_shadow(void)
> +{
> +       struct memblock_region *reg;
> +       int i = 0;
> +
> +       for_each_memblock(memory, reg) {
> +               void *start = (void *)__phys_to_virt(reg->base);
> +               void *end = (void *)__phys_to_virt(reg->base + reg->size);
> +               int *shadow_start, *shadow_end;
> +
> +               if (start >= end)
> +                       break;
> +               shadow_start = (int *)((unsigned long)kasan_mem_to_shadow(start) & ~(PAGE_SIZE - 1));
> +               shadow_end =  (int *)kasan_mem_to_shadow(end);

shadow_start and shadow_end can refer to the same page as in the
previous iteration. For instance, I have these two regions

  0x00006e090000-0x00006e0adfff [Conventional Memory|   |  |  |  |  |
|   |WB|WT|WC|UC]
  0x00006e0ae000-0x00006e0affff [Loader Data        |   |  |  |  |  |
|   |WB|WT|WC|UC]

which are covered by different memblocks since the second one is
marked as MEMBLOCK_NOMAP, due to the fact that it contains the UEFI
memory map.

I get the following output

kasan: screwed shadow mapping 23575, 23573

which I think is simply a result from the fact the shadow_start refers
to the same page as in the previous iteration(s)


> +               for (; shadow_start < shadow_end; shadow_start += PAGE_SIZE/sizeof(int)) {
> +                       *shadow_start = i;
> +                       i++;
> +               }
> +       }
> +
> +       i = 0;
> +       for_each_memblock(memory, reg) {
> +               void *start = (void *)__phys_to_virt(reg->base);
> +               void *end = (void *)__phys_to_virt(reg->base + reg->size);
> +               int *shadow_start, *shadow_end;
> +
> +               if (start >= end)
> +                       break;
> +               shadow_start = (int *)((unsigned long)kasan_mem_to_shadow(start) & ~(PAGE_SIZE - 1));
> +               shadow_end =  (int *)kasan_mem_to_shadow(end);
> +               for (; shadow_start < shadow_end; shadow_start += PAGE_SIZE/sizeof(int)) {
> +                       if (*shadow_start != i) {
> +                               pr_err("screwed shadow mapping %d, %d\n", *shadow_start, i);
> +                               goto clear;
> +                       }
> +                       i++;
> +               }
> +       }
> +clear:
> +       for_each_memblock(memory, reg) {
> +               void *start = (void *)__phys_to_virt(reg->base);
> +               void *end = (void *)__phys_to_virt(reg->base + reg->size);
> +               unsigned long shadow_start, shadow_end;
> +
> +               if (start >= end)
> +                       break;
> +               shadow_start =  ((unsigned long)kasan_mem_to_shadow(start) & ~(PAGE_SIZE - 1));
> +               shadow_end =  (unsigned long)kasan_mem_to_shadow(end);
> +               memset((void *)shadow_start, 0, shadow_end - shadow_start);
> +       }
> +
> +}
> +
>  void __init kasan_init(void)
>  {
>         struct memblock_region *reg;
> @@ -159,6 +212,8 @@ void __init kasan_init(void)
>         cpu_set_ttbr1(__pa(swapper_pg_dir));
>         flush_tlb_all();
>
> +       verify_shadow();
> +
>         /* At this point kasan is fully initialized. Enable error messages */
>         init_task.kasan_depth = 0;
>         pr_info("KernelAddressSanitizer initialized\n");
> --
>
>
>
>
>


From linus.walleij at linaro.org  Tue Feb 16 07:17:31 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 16 Feb 2016 16:17:31 +0100
Subject: [PATCH v3 09/10] ARM: dts: introduce MPS2 AN385/AN386
In-Reply-To: <1455617295-23736-10-git-send-email-vladimir.murzin@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-10-git-send-email-vladimir.murzin@arm.com>
Message-ID: <CACRpkdafDhT=1uJssVNAW+g05eXbRC1xUL+O0+SxcpdczUX0vQ@mail.gmail.com>

On Tue, Feb 16, 2016 at 11:08 AM, Vladimir Murzin
<vladimir.murzin at arm.com> wrote:

> Application Notes 385 and 386 shares the same memory map and features
> except the CPU is used. AN385 is supplied with Cortex-M3 CPU and AN386
> is supplied with Cortex-M4.
>
> Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
(...)
> +               fpgaio {
> +                       compatible = "syscon", "simple-mfd";
> +                       reg = <0x40028000 0x10>;
> +
> +                       led at 0 {
> +                               compatible = "register-bit-led";
> +                               offset = <0x0>;
> +                               mask = <0x01>;
> +                               label = "userled:0";
> +                               linux,default-trigger = "heartbeat";
> +                               default-state = "on";
> +                       };
> +
> +                       led at 1 {
> +                               compatible = "register-bit-led";
> +                               offset = <0x0>;
> +                               mask = <0x02>;
> +                               label = "userled:1";
> +                               linux,default-trigger = "usr";
> +                               default-state = "off";
> +                       };
> +               };

Thanks for using this. I worked hard to massage this into the
core.

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Yours,
Linus Walleij


From pankaj.embedded at gmail.com  Tue Feb 16 07:20:52 2016
From: pankaj.embedded at gmail.com (Pankaj Pandey)
Date: Tue, 16 Feb 2016 20:50:52 +0530
Subject: e1000e: eth0: Detected Hardware Unit Hang
Message-ID: <CAOdCjQsRAOh4duc4-tABduF=9qTR5cNSDaDkEqr4zz4LXGTRSA@mail.gmail.com>

Hi All,

I am booting 3.10 kernel uImage on arm64 based target. During NFS
booting from eth0 port I am getting  "eth0: Detected Hardware Unit
Hang" . Eth0  port is  intel ethernet 1gb  PCIe card.
 Same intel PCIe card  eth0 Port working fine in 4.1 kernel. Please
find the error log below :-

Any pointer what could be reason of below mentioned error in 3.10
kernel and this same error is coming till 4.0 kernel ?

[    0.847742] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
[    0.854820] e1000: Copyright (c) 1999-2006 Intel Corporation.
[    0.860657] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[    0.866522] e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
[    0.872483] e1000e 0000:03:00.0: Disabling ASPM L0s L1
[    0.877765] e1000e 0000:03:00.0: Interrupt Throttling Rate (ints/sec) set to
dynamic conservative mode
[    0.887131] e1000e 0000:03:00.0 (unregistered net_device): Failed to
initialize MSI-X interrupts.  Falling back to MSI interrupts.
[    0.898931] e1000e 0000:03:00.0 (unregistered net_device): Failed to
initialize MSI interrupts.  Falling back to legacy interrupts.
[    1.117898] e1000e 0000:03:00.0 eth0: registered PHC clock
[    1.123412] e1000e 0000:03:00.0 eth0: (PCI Express:2.5GT/s:Width x1)
68:05:ca:3b:99:d1
[    1.131364] e1000e 0000:03:00.0 eth0: Intel(R) PRO/1000 Network Connection
[    1.138280] e1000e 0000:03:00.0 eth0: MAC: 3, PHY: 8, PBA No: E46981-008
......................................
.................................
..................................

[    4.414294] IP-Config: Complete:
[    4.417540]      device=eth0, hwaddr=68:05:ca:3b:99:d1, ipaddr=10.162.10.20,
mask=255.255.0.0, gw=10.162.103.241
[    4.427759]      host=arm64, domain=, nis-domain=(none)
[    4.433182]      bootserver=10.162.103.241, rootserver=10.162.103.241,
rootpath=
[    8.164526] e1000e 0000:03:00.0 eth0: Detected Hardware Unit Hang:
[    8.164526]   TDH                  <1>
[    8.164526]   TDT                  <1>
[    8.164526]   next_to_use          <1>
[    8.164526]   next_to_clean        <0>
[    8.164526] buffer_info[next_to_clean]:
[    8.164526]   time_stamp           <ffffe8e9>
[    8.164526]   next_to_watch        <0>
[    8.164526]   jiffies              <ffffe934>
[    8.164526]   next_to_watch.status <0>
[    8.164526] MAC Status             <80783>
[    8.164526] PHY Status             <796d>
[    8.164526] PHY 1000BASE-T Status  <3800>
[    8.164526] PHY Extended Status    <3000>
[    8.164526] PCI Status             <10>
[   12.164522] e1000e 0000:03:00.0 eth0: Detected Hardware Unit Hang:
[   12.164522]   TDH                  <1>
[   12.164522]   TDT                  <1>
[   12.164522]   next_to_use          <1>
[   12.164522]   next_to_clean        <0>
[   12.164522] buffer_info[next_to_clean]:
[   12.164522]   time_stamp           <ffffe8e9>
[   12.164522]   next_to_watch        <0>
[   12.164522]   jiffies              <ffffe984>
[   12.164522]   next_to_watch.status <0>
[   12.164522] MAC Status             <80783>
[   12.164522] PHY Status             <796d>
[   12.164522] PHY 1000BASE-T Status  <3800>
[   12.164522] PHY Extended Status    <3000>
[   12.164522] PCI Status             <10>
[   14.164136] ------------[ cut here ]------------
[   14.168782] WARNING: at net/sched/sch_generic.c:255
dev_watchdog+0x2d8/0x2e8()
[   14.176037] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out
[   14.182591] Modules linked in:
[   14.185675] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
3.10.94-rt102-04142-gcce5fca-dirty #108
[   14.194238] Call trace:
[   14.196699] [<ffffffc000087c80>] dump_backtrace+0x0/0x128
[   14.202124] [<ffffffc000087dbc>] show_stack+0x14/0x20
[   14.207200] [<ffffffc000541954>] dump_stack+0x20/0x28
[   14.212276] [<ffffffc00009b09c>] warn_slowpath_common+0x7c/0xa0
[   14.218226] [<ffffffc00009b188>] warn_slowpath_fmt+0x50/0x58
[   14.223910] [<ffffffc00049e018>] dev_watchdog+0x2d8/0x2e8
[   14.229333] [<ffffffc0000a978c>] call_timer_fn.isra.30+0x2c/0x90
[   14.235366] [<ffffffc0000aa138>] run_timer_softirq+0x1c0/0x230
[   14.241226] [<ffffffc0000a283c>] __do_softirq+0x184/0x1d8
[   14.246648] [<ffffffc0000a294c>] do_softirq+0x54/0x58
[   14.251724] [<ffffffc0000a3088>] irq_exit+0x88/0xe0
[   14.256626] [<ffffffc0000fb630>] __handle_domain_irq+0x78/0xd8
[   14.262484] [<ffffffc0000813b0>] gic_handle_irq+0x50/0x98
[   14.267909] Exception stack(0xffffffc000713db0 to 0xffffffc000713ed0)
[   14.274379] 3da0:                                     ffffffc0 00710000
ffffffc0 00766300
[   14.282594] 3dc0: ffffffc0 00713f00 ffffffc0 00084d80 00000000 ffffe985
ffffffc1 fefa1780
[   14.290809] 3de0: 00000000 000012ba 00000000 00000000 ffffffc1 fef9d0a4
00000000 00010000
[   14.299022] 3e00: 00000000 00000020 000bebc2 00000000 00000000 28000000
00000001 8d0d2938
[   14.307235] 3e20: ffffffc0 0071b000 ffffffc0 00713ce0 00000000 ffffe986
20537461 74757320
[   14.315451] 3e40: 00000000 00000006 00000000 00000000 00000000 00000003
00000000 00000001
[   14.323666] 3e60: ffffffc1 f6f72e38 ffffffc0 00594210 00000000 00000000
ffffffc0 00710000
[   14.331880] 3e80: ffffffc0 00766300 ffffffc0 0076d420 ffffffc0 0054ae00
ffffffc0 0075ce5c
[   14.340097] 3ea0: ffffffc0 00667498 00000000 00000001 00000000 0007d000
ffffffc0 00080498
[   14.348310] 3ec0: 00000000 00080270 ffffffc0 00713f00
[   14.353383] [<ffffffc000083dac>] el1_irq+0x6c/0xc0
[   14.358198] [<ffffffc0000d5a50>] cpu_startup_entry+0xf8/0x140
[   14.363972] [<ffffffc00053c0f8>] rest_init+0x70/0x78
[   14.368965] [<ffffffc0006e47b4>] start_kernel+0x318/0x328
[   14.374386] ---[ end trace 4804658c584f9eb7 ]---
[   14.379044] e1000e 0000:03:00.0 eth0: Reset adapter unexpectedly
[   17.615130] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control:
Rx/Tx
[   23.164143] e1000e 0000:03:00.0 eth0: Reset adapter unexpectedly
[   26.315131] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control:
Rx/Tx

Regards,
Pankaj Pandey


From mathieu.poirier at linaro.org  Tue Feb 16 07:24:52 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Tue, 16 Feb 2016 08:24:52 -0700
Subject: [PATCH] drivers/hwtracing: make coresight-* explicitly non-modular
In-Reply-To: <20160216101509.GB19428@n2100.arm.linux.org.uk>
References: <1455470351-15219-1-git-send-email-paul.gortmaker@windriver.com>
 <CANLsYkyY84Tp2oxP9JdAq6WGp9rBXQc=7nXS2hfi9hkcrFEKCw@mail.gmail.com>
 <20160216101509.GB19428@n2100.arm.linux.org.uk>
Message-ID: <CANLsYkzDgy1n4AB8MN=gCU0goJaKj=AyoUhEL2x18KG4UiNisQ@mail.gmail.com>

On 16 February 2016 at 03:15, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Mon, Feb 15, 2016 at 06:25:56PM -0700, Mathieu Poirier wrote:
>> On 14 February 2016 at 10:19, Paul Gortmaker
>> <paul.gortmaker at windriver.com> wrote:
>> > diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
>> > index 9006c4e75cf7..3d8dcdd1aeae 100644
>> > --- a/include/linux/amba/bus.h
>> > +++ b/include/linux/amba/bus.h
>> > @@ -163,4 +163,13 @@ struct amba_device name##_device = {                               \
>> >  #define module_amba_driver(__amba_drv) \
>> >         module_driver(__amba_drv, amba_driver_register, amba_driver_unregister)
>> >
>> > +/*
>> > + * builtin_amba_driver() - Helper macro for drivers that don't do anything
>> > + * special in driver initcall.  This eliminates a lot of boilerplate.  Each
>> > + * driver may only use this macro once, and calling it replaces the instance
>> > + * device_initcall().
>> > + */
>> > +#define builtin_amba_driver(__amba_drv) \
>> > +       builtin_driver(__amba_drv, amba_driver_register)
>> > +
>> >  #endif
>> > --
>> > 2.6.1
>> >
>>
>> I'm good with this patch on the CS side but Russell maintains the amba
>> subsystem and as such needs to agree with the new macro.  Russell, I
>> offer to take this through my tree if you're fine with the changes.
>
> Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>
>

Applied - thanks.

> --
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.


From javier at osg.samsung.com  Tue Feb 16 07:25:48 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Tue, 16 Feb 2016 12:25:48 -0300
Subject: [PATCH v2] ARM: dts: Move syscon reboot/poweroff to common dtsi for
 Exynos
Message-ID: <1455636348-14277-1-git-send-email-javier@osg.samsung.com>

All Exynos SoCs have the same syscon reboot and poweroff device nodes so
there is no need to duplicate the same on each SoC dtsi and can be moved
to a common dtsi that can be included by all the SoCs dtsi files.

Suggested-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
Reviewed-by: Alim Akhtar <alim.akhtar at samsung,com>

---
Hello,

The patch was tested on an Exynos5800 Peach Pi Chromebook and an
Exynos5422 Odroid XU4 board. Reboot and poweroff worked for both.

But testing on Exynos3 and Exynos4 will be highly appreciated.

Best regards,
Javier

Changes in v2:
- Added Krzysztof Kozlowski's Suggested-by tag.
- Added Alim Akhtar's Reviewed-by tag.
- Moved the poweroff and reboot nodes under a soc node (Krzysztof Kozlowski).
- Include the dtsi after skeleton dtsi in exynos4.dtsi ((Krzysztof Kozlowski).

 arch/arm/boot/dts/exynos-syscon-restart.dtsi | 27 +++++++++++++++++++++++++++
 arch/arm/boot/dts/exynos3250.dtsi            | 15 +--------------
 arch/arm/boot/dts/exynos4.dtsi               | 15 +--------------
 arch/arm/boot/dts/exynos5.dtsi               | 15 +--------------
 arch/arm/boot/dts/exynos5410.dtsi            | 15 +--------------
 5 files changed, 31 insertions(+), 56 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos-syscon-restart.dtsi

diff --git a/arch/arm/boot/dts/exynos-syscon-restart.dtsi b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
new file mode 100644
index 000000000000..09a2040054ed
--- /dev/null
+++ b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
@@ -0,0 +1,27 @@
+/*
+ * Samsung's Exynos SoC syscon reboot/poweroff nodes common definition.
+ *
+ * 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.
+ */
+
+/ {
+	soc {
+		compatible = "simple-bus";
+
+		poweroff: syscon-poweroff {
+			compatible = "syscon-poweroff";
+			regmap = <&pmu_system_controller>;
+			offset = <0x330C>; /* PS_HOLD_CONTROL */
+			mask = <0x5200>; /* reset value */
+		};
+
+		reboot: syscon-reboot {
+			compatible = "syscon-reboot";
+			regmap = <&pmu_system_controller>;
+			offset = <0x0400>; /* SWRESET */
+			mask = <0x1>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 18e3deffbf48..d9c221517935 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -19,6 +19,7 @@
 
 #include "skeleton.dtsi"
 #include "exynos4-cpu-thermal.dtsi"
+#include "exynos-syscon-restart.dtsi"
 #include <dt-bindings/clock/exynos3250.h>
 
 / {
@@ -152,20 +153,6 @@
 			interrupt-parent = <&gic>;
 		};
 
-		poweroff: syscon-poweroff {
-			compatible = "syscon-poweroff";
-			regmap = <&pmu_system_controller>;
-			offset = <0x330C>; /* PS_HOLD_CONTROL */
-			mask = <0x5200>; /* Reset value */
-		};
-
-		reboot: syscon-reboot {
-			compatible = "syscon-reboot";
-			regmap = <&pmu_system_controller>;
-			offset = <0x0400>; /* SWRESET */
-			mask = <0x1>;
-		};
-
 		mipi_phy: video-phy at 10020710 {
 			compatible = "samsung,s5pv210-mipi-video-phy";
 			#phy-cells = <1>;
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index ca621a92319e..5456094d2f45 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -22,6 +22,7 @@
 #include <dt-bindings/clock/exynos4.h>
 #include <dt-bindings/clock/exynos-audss-clk.h>
 #include "skeleton.dtsi"
+#include "exynos-syscon-restart.dtsi"
 
 / {
 	interrupt-parent = <&gic>;
@@ -163,20 +164,6 @@
 		interrupt-parent = <&gic>;
 	};
 
-	poweroff: syscon-poweroff {
-		compatible = "syscon-poweroff";
-		regmap = <&pmu_system_controller>;
-		offset = <0x330C>; /* PS_HOLD_CONTROL */
-		mask = <0x5200>; /* reset value */
-	};
-
-	reboot: syscon-reboot {
-		compatible = "syscon-reboot";
-		regmap = <&pmu_system_controller>;
-		offset = <0x0400>; /* SWRESET */
-		mask = <0x1>;
-	};
-
 	dsi_0: dsi at 11C80000 {
 		compatible = "samsung,exynos4210-mipi-dsi";
 		reg = <0x11C80000 0x10000>;
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index b61d1f637510..92313cac035e 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -14,6 +14,7 @@
  */
 
 #include "skeleton.dtsi"
+#include "exynos-syscon-restart.dtsi"
 
 / {
 	interrupt-parent = <&gic>;
@@ -93,20 +94,6 @@
 		status = "disabled";
 	};
 
-	poweroff: syscon-poweroff {
-		compatible = "syscon-poweroff";
-		regmap = <&pmu_system_controller>;
-		offset = <0x330C>; /* PS_HOLD_CONTROL */
-		mask = <0x5200>; /* reset value */
-	};
-
-	reboot: syscon-reboot {
-		compatible = "syscon-reboot";
-		regmap = <&pmu_system_controller>;
-		offset = <0x0400>; /* SWRESET */
-		mask = <0x1>;
-	};
-
 	fimd: fimd at 14400000 {
 		compatible = "samsung,exynos5250-fimd";
 		interrupt-parent = <&combiner>;
diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
index f3490f567344..fa558674ac76 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -14,6 +14,7 @@
  */
 
 #include "skeleton.dtsi"
+#include "exynos-syscon-restart.dtsi"
 #include <dt-bindings/clock/exynos5410.h>
 
 / {
@@ -117,20 +118,6 @@
 			reg = <0x10040000 0x5000>;
 		};
 
-		poweroff: syscon-poweroff {
-			compatible = "syscon-poweroff";
-			regmap = <&pmu_system_controller>;
-			offset = <0x330C>; /* PS_HOLD_CONTROL */
-			mask = <0x5200>; /* reset value */
-		};
-
-		reboot: syscon-reboot {
-			compatible = "syscon-reboot";
-			regmap = <&pmu_system_controller>;
-			offset = <0x0400>; /* SWRESET */
-			mask = <0x1>;
-		};
-
 		mct: mct at 101C0000 {
 			compatible = "samsung,exynos4210-mct";
 			reg = <0x101C0000 0xB00>;
-- 
2.5.0



From linux at roeck-us.net  Tue Feb 16 07:29:58 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 16 Feb 2016 07:29:58 -0800
Subject: [PATCH v12 4/4] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <1455611785-2407-5-git-send-email-fu.wei@linaro.org>
References: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>
 <1455611785-2407-5-git-send-email-fu.wei@linaro.org>
Message-ID: <56C34076.1020206@roeck-us.net>

On 02/16/2016 12:36 AM, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei at linaro.org>
>
> According to Server Base System Architecture (SBSA) specification,
> the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0)
> is for alerting the system by interrupt, the second one (WS1) is a real
> hardware reset.
> More details about the hardware specification of this device:
> ARM DEN0029B - Server Base System Architecture (SBSA)
>
> This driver can operate ARM SBSA Generic Watchdog as a single stage watchdog
> or a two stages watchdog, it's set up by the module parameter "action".
> In the single stage mode, when the timeout is reached, your system
> will be reset by WS1. The first signal (WS0) is ignored.
> In the two stages mode, when the timeout is reached, the first signal (WS0)
> will trigger panic. If the system is getting into trouble and cannot be reset
> by panic or restart properly by the kdump kernel(if supported), then the
> second stage (as long as the first stage) will be reached, system will be
> reset by WS1. This function can help administrator to backup the system
> context info by panic console output or kdump.
>
> This driver bases on linux kernel watchdog framework, so it can get
> timeout from module parameter and FDT at the driver init stage.
>
> Signed-off-by: Fu Wei <fu.wei at linaro.org>
> Reviewed-by: Graeme Gregory <graeme.gregory at linaro.org>
> Tested-by: Pratyush Anand <panand at redhat.com>
> Acked-by: Timur Tabi <timur at codeaurora.org>
> Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
> ---
>   drivers/watchdog/Kconfig     |  20 +++
>   drivers/watchdog/Makefile    |   1 +
>   drivers/watchdog/sbsa_gwdt.c | 403 +++++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 424 insertions(+)
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 0f6d851..ed9a5cb 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig

[ ... ]

> +
> +static int sbsa_gwdt_probe(struct platform_device *pdev)
> +{

[ ... ]

> +		if (!action)
> +			dev_warn(dev, "falling back to signle stage mode.\n");

Still:

s/signle/single/

[ ... ]

> +
> +MODULE_DESCRIPTION("SBSA Generic Watchdog Driver");
> +MODULE_AUTHOR("Fu Wei <fu.wei at linaro.org>");
> +MODULE_AUTHOR("Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>");
> +MODULE_AUTHOR("Al Stone <al.stone at linaro.org>");
> +MODULE_AUTHOR("Timur Tabi <timur at codeaurora.org>");
> +MODULE_LICENSE("GPL v2");
>
Do you need a MODULE_ALIAS ?

Guenter



From linux at roeck-us.net  Tue Feb 16 07:30:39 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 16 Feb 2016 07:30:39 -0800
Subject: [PATCH v12 1/4] Documentation: add sbsa-gwdt driver documentation
In-Reply-To: <1455611785-2407-2-git-send-email-fu.wei@linaro.org>
References: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>
 <1455611785-2407-2-git-send-email-fu.wei@linaro.org>
Message-ID: <56C3409F.2020103@roeck-us.net>

On 02/16/2016 12:36 AM, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei at linaro.org>
>
> The sbsa-gwdt.txt documentation in devicetree/bindings/watchdog is for
> introducing SBSA(Server Base System Architecture) Generic Watchdog
> device node info into FDT.
>
> Also add sbsa-gwdt introduction in watchdog-parameters.txt
>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Acked-by: Rob Herring <robh at kernel.org>
> Signed-off-by: Fu Wei <fu.wei at linaro.org>

Reviewed-by: Guenter Roeck <linux at roeck-us.net>

> ---
>   .../devicetree/bindings/watchdog/sbsa-gwdt.txt     | 31 ++++++++++++++++++++++
>   Documentation/watchdog/watchdog-parameters.txt     |  7 +++++
>   2 files changed, 38 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
> new file mode 100644
> index 0000000..6f2d5f9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
> @@ -0,0 +1,31 @@
> +* SBSA (Server Base System Architecture) Generic Watchdog
> +
> +The SBSA Generic Watchdog Timer is used to force a reset of the system
> +after two stages of timeout have elapsed.  A detailed definition of the
> +watchdog timer can be found in the ARM document: ARM-DEN-0029 - Server
> +Base System Architecture (SBSA)
> +
> +Required properties:
> +- compatible: Should at least contain "arm,sbsa-gwdt".
> +
> +- reg: Each entry specifies the base physical address of a register frame
> +  and the length of that frame; currently, two frames must be defined,
> +  in this order:
> +  1: Watchdog control frame;
> +  2: Refresh frame.
> +
> +- interrupts: Should contain the Watchdog Signal 0 (WS0) SPI (Shared
> +  Peripheral Interrupt) number of SBSA Generic Watchdog.
> +
> +Optional properties
> +- timeout-sec: Watchdog timeout values (in seconds).
> +
> +Example for FVP Foundation Model v8:
> +
> +watchdog at 2a440000 {
> +	compatible = "arm,sbsa-gwdt";
> +	reg = <0x0 0x2a440000 0 0x1000>,
> +	      <0x0 0x2a450000 0 0x1000>;
> +	interrupts = <0 27 4>;
> +	timeout-sec = <30>;
> +};
> diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
> index 9f9ec9f..ce7ae4e 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -284,6 +284,13 @@ sbc_fitpc2_wdt:
>   margin: Watchdog margin in seconds (default 60s)
>   nowayout: Watchdog cannot be stopped once started
>   -------------------------------------------------
> +sbsa_gwdt:
> +timeout: Watchdog timeout in seconds. (default 10s)
> +action: Watchdog action at the first stage timeout,
> +	set to 0 to ignore, 1 to panic. (default=0)
> +nowayout: Watchdog cannot be stopped once started
> +	(default=kernel config parameter)
> +-------------------------------------------------
>   sc1200wdt:
>   isapnp: When set to 0 driver ISA PnP support will be disabled (default=1)
>   io: io port
>



From linux at roeck-us.net  Tue Feb 16 07:31:09 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 16 Feb 2016 07:31:09 -0800
Subject: [PATCH v12 2/4] ARM64: add SBSA Generic Watchdog device node in
 foundation-v8.dts
In-Reply-To: <1455611785-2407-3-git-send-email-fu.wei@linaro.org>
References: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>
 <1455611785-2407-3-git-send-email-fu.wei@linaro.org>
Message-ID: <56C340BD.2050700@roeck-us.net>

On 02/16/2016 12:36 AM, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei at linaro.org>
>
> This can be a example of adding SBSA Generic Watchdog device node
> into some dts files for the Soc which contains SBSA Generic Watchdog.
>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Fu Wei <fu.wei at linaro.org>

Reviewed-by: Guenter Roeck <linux at roeck-us.net>

> ---
>   arch/arm64/boot/dts/arm/foundation-v8.dts | 7 +++++++
>   1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dts b/arch/arm64/boot/dts/arm/foundation-v8.dts
> index 4eac8dc..66cb9aa 100644
> --- a/arch/arm64/boot/dts/arm/foundation-v8.dts
> +++ b/arch/arm64/boot/dts/arm/foundation-v8.dts
> @@ -237,4 +237,11 @@
>   			};
>   		};
>   	};
> +	watchdog at 2a440000 {
> +		compatible = "arm,sbsa-gwdt";
> +		reg = <0x0 0x2a440000 0 0x1000>,
> +			<0x0 0x2a450000 0 0x1000>;
> +		interrupts = <0 27 4>;
> +		timeout-sec = <30>;
> +	};
>   };
>



From linux at roeck-us.net  Tue Feb 16 07:31:36 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 16 Feb 2016 07:31:36 -0800
Subject: [PATCH v12 3/4] ARM64: add SBSA Generic Watchdog device node in
 amd-seattle-soc.dtsi
In-Reply-To: <1455611785-2407-4-git-send-email-fu.wei@linaro.org>
References: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>
 <1455611785-2407-4-git-send-email-fu.wei@linaro.org>
Message-ID: <56C340D8.2050302@roeck-us.net>

On 02/16/2016 12:36 AM, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei at linaro.org>
>
> This can be a example of adding SBSA Generic Watchdog device node
> into some dts files for the Soc which contains SBSA Generic Watchdog.
>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
> Signed-off-by: Fu Wei <fu.wei at linaro.org>

Reviewed-by: Guenter Roeck <linux at roeck-us.net>

> ---
>   arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 8 ++++++++
>   1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
> index 2874d92..0a8ca1d 100644
> --- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
> +++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
> @@ -84,6 +84,14 @@
>   			clock-names = "uartclk", "apb_pclk";
>   		};
>
> +		watchdog0: watchdog at e0bb0000 {
> +			compatible = "arm,sbsa-gwdt";
> +			reg = <0x0 0xe0bc0000 0 0x1000>,
> +				<0x0 0xe0bb0000 0 0x1000>;
> +			interrupts = <0 337 4>;
> +			timeout-sec = <15>;
> +		};
> +
>   		spi0: ssp at e1020000 {
>   			status = "disabled";
>   			compatible = "arm,pl022", "arm,primecell";
>



From geert+renesas at glider.be  Tue Feb 16 07:31:51 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Tue, 16 Feb 2016 16:31:51 +0100
Subject: [PATCH 3/4] drivers: sh: Stop using the legacy clock domain on ARM
In-Reply-To: <1455636712-3040-1-git-send-email-geert+renesas@glider.be>
References: <1455636712-3040-1-git-send-email-geert+renesas@glider.be>
Message-ID: <1455636712-3040-4-git-send-email-geert+renesas@glider.be>

Now CONFIG_PM and CONFIG_PM_GENERIC_DOMAINS are enabled unconditionally
for Renesas ARM-based SoCs, the legacy clock domain is no longer used on
these SoCs.
Remove the related support code, and stop entering drivers/sh/ on ARM.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
Notes:
  - This does break booting R-Car Gen2 boards using pre-v4.3 DTSes that
    don't have power-domains properties,
  - This may unbreak SuperH-based ARCH_SHMOBILE platforms, which were
    probably broken since v4.4 by commit 0ba58de231066e47 ("drivers: sh:
    Get rid of CONFIG_ARCH_SHMOBILE_MULTI").
---
 drivers/Makefile        | 1 -
 drivers/sh/pm_runtime.c | 9 ---------
 2 files changed, 10 deletions(-)

diff --git a/drivers/Makefile b/drivers/Makefile
index 8f5d076baeb0e832..6afdb78e21382538 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -127,7 +127,6 @@ obj-$(CONFIG_SGI_SN)		+= sn/
 obj-y				+= firmware/
 obj-$(CONFIG_CRYPTO)		+= crypto/
 obj-$(CONFIG_SUPERH)		+= sh/
-obj-$(CONFIG_ARCH_SHMOBILE)	+= sh/
 ifndef CONFIG_ARCH_USES_GETTIMEOFFSET
 obj-y				+= clocksource/
 endif
diff --git a/drivers/sh/pm_runtime.c b/drivers/sh/pm_runtime.c
index 91a003011acfacb2..c887ecdaf19b7c10 100644
--- a/drivers/sh/pm_runtime.c
+++ b/drivers/sh/pm_runtime.c
@@ -34,15 +34,6 @@ static struct pm_clk_notifier_block platform_bus_notifier = {
 
 static int __init sh_pm_runtime_init(void)
 {
-	if (IS_ENABLED(CONFIG_ARCH_SHMOBILE)) {
-		if (!of_find_compatible_node(NULL, NULL,
-					     "renesas,cpg-mstp-clocks"))
-			return 0;
-		if (IS_ENABLED(CONFIG_PM_GENERIC_DOMAINS_OF) &&
-		    of_find_node_with_property(NULL, "#power-domain-cells"))
-			return 0;
-	}
-
 	pm_clk_add_notifier(&platform_bus_type, &platform_bus_notifier);
 	return 0;
 }
-- 
1.9.1



From geert+renesas at glider.be  Tue Feb 16 07:31:48 2016
From: geert+renesas at glider.be (Geert Uytterhoeven)
Date: Tue, 16 Feb 2016 16:31:48 +0100
Subject: [PATCH 0/4] Enable PM and PM_GENERIC_DOMAINS for SoCs with PM Domains
Message-ID: <1455636712-3040-1-git-send-email-geert+renesas@glider.be>

	Hi Simon, Magnus,

All supported Renesas ARM SoCs (except for Emma Mobile EV2) have clock
domains. Some SoCs also have power domains. To ensure proper operation
of on-SoC modules, module clocks must be ungated, and power domains must
be powered up when needed.

Currently the user can choose to build a kernel with power management
enabled or disabled:
  - If CONFIG_PM=y, power domains and/or module clocks are handled
    dynamically by Runtime PM and the generic power domain.
  - If CONFIG_PM=n, power domains are assumed to be powered up by reset
    state or by the boot loader, and module clocks are handled by the
    legacy clock domain on driver (un)bind.
    The latter is implemented using a platform bus notifier, which
    applies not only to all on-SoC devices, but to all platform devices
    present in the system.

To remove the dependency on implicit assumptions, and to get rid of the
peculiarities of the legacy clock domain, enable CONFIG_PM and
CONFIG_PM_GENERIC_DOMAINS unconditionally, for all Renesas ARM SoCs with
clock and/or power domains.

Patches:
  - Patches 1 and 2 enable PM and PM_GENERIC_DOMAINS,
  - Patch 3 removes the now unused legacy clock domain code for Renesas
    ARM SoCs,
  - Patch 4 relieves you from maintaining drivers/sh/, which is no
    longer used on Renesas ARM SoCs, and returns it to the SuperH
    people.

Notes:
  - This does cause an increase in kernel size.  Given bloat-o-meter
    reports a modest increase of 26 KiB for an RZ/A1H kernel, this
    should not be a problem, even when used on RZ/A1H with XIP and
    internal RAM only.
  - Patch 3 does break booting R-Car Gen2 boards using pre-v4.3 DTSes
    that don't have power-domains properties,
  - Patch 3 may unbreak SuperH-based ARCH_SHMOBILE platforms, which were
    probably broken since v4.4 by commit 0ba58de231066e47 ("drivers: sh:
    Get rid of CONFIG_ARCH_SHMOBILE_MULTI"),
  - Currently CONFIG_PM=n doesn't work anyway on r8a7795 as "drivers:
    sh: Handle PM_GENERIC_DOMAINS_OF=n with new r8a7795 CPG/MSSR
    driver" isn't upstream.

For your convenience, I've also pushed this series to
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git#topic/mandatory-pm-v1

Thanks for your comments!

Geert Uytterhoeven (4):
  ARM: shmobile: Enable PM and PM_GENERIC_DOMAINS for SoCs with PM
    Domains
  arm64: renesas: Enable PM and PM_GENERIC_DOMAINS for SoCs with PM
    Domains
  drivers: sh: Stop using the legacy clock domain on ARM
  MAINTAINERS: Drop drivers/sh/ for Renesas ARM

 MAINTAINERS                    |  1 -
 arch/arm/mach-shmobile/Kconfig | 13 ++++++++-----
 arch/arm64/Kconfig.platforms   |  3 ++-
 drivers/Makefile               |  1 -
 drivers/sh/pm_runtime.c        |  9 ---------
 5 files changed, 10 insertions(+), 17 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From robin.murphy at arm.com  Tue Feb 16 07:32:11 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue, 16 Feb 2016 15:32:11 +0000
Subject: [PATCH v8 3/5] memory: mediatek: Add SMI driver
In-Reply-To: <20160216141059.GT18805@8bytes.org>
References: <1453781562-23556-1-git-send-email-yong.wu@mediatek.com>
 <1453781562-23556-4-git-send-email-yong.wu@mediatek.com>
 <56ADE959.2050309@gmail.com> <20160216141059.GT18805@8bytes.org>
Message-ID: <56C340FB.1050607@arm.com>

Hi Joerg,

On 16/02/16 14:11, Joerg Roedel wrote:
> On Sun, Jan 31, 2016 at 12:00:41PM +0100, Matthias Brugger wrote:
>>
>>
>> On 26/01/16 05:12, Yong Wu wrote:
>>> This patch add SMI(Smart Multimedia Interface) driver. This driver
>>> is responsible to enable/disable iommu and control the power domain
>>> and clocks of each local arbiter.
>>>
>>> Signed-off-by: Yong Wu <yong.wu at mediatek.com>
>>> Tested-by: Philipp Zabel <p.zabel at pengutronix.de>
>>> ---
>>
>> Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
>>
>> Joerg would you mind to take this through your branch?
>
> Hmm, I somehow missed the patch-set, at least I can't find the v8
> patches in my inbox.
>
> Yong, can you please re-send with all Acks and other tags added?

Just to note patch 4 of this series also depends on the v3 io-pgtable 
short-descriptor series posted separately[1] - is that on your radar 
already or would you like that resent as well?

Robin.

[1]:http://thread.gmane.org/gmane.linux.kernel.iommu/12007

>
>
> Thanks,
>
> 	Joerg
>
> _______________________________________________
> iommu mailing list
> iommu at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>



From gregory.clement at free-electrons.com  Tue Feb 16 07:33:36 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 16:33:36 +0100
Subject: [PATCH v2 1/8] ARM: dts: armada-38x: add buffer manager nodes
In-Reply-To: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455636823-14470-2-git-send-email-gregory.clement@free-electrons.com>

From: Marcin Wojtas <mw at semihalf.com>

Armada 38x network controller supports hardware buffer management (BM).
Since it is now enabled in mvneta driver, appropriate nodes can be added
to armada-38x.dtsi - for the actual common BM unit (bm at c8000) and its
internal SRAM (bm-bppi), which is used for indirect access to buffer
pointer ring residing in DRAM.

Pools - ports mapping, bm-bppi entry in 'soc' node's ranges and optional
parameters are supposed to be set in board files.

Signed-off-by: Marcin Wojtas <mw at semihalf.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/boot/dts/armada-38x.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
index e8b7f6726772..1b7d690d8e10 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -540,6 +540,14 @@
 				status = "disabled";
 			};
 
+			bm: bm at c8000 {
+				compatible = "marvell,armada-380-neta-bm";
+				reg = <0xc8000 0xac>;
+				clocks = <&gateclk 13>;
+				internal-mem = <&bm_bppi>;
+				status = "disabled";
+			};
+
 			sata at e0000 {
 				compatible = "marvell,armada-380-ahci";
 				reg = <0xe0000 0x2000>;
@@ -618,6 +626,16 @@
 			#size-cells = <1>;
 			ranges = <0 MBUS_ID(0x09, 0x15) 0 0x800>;
 		};
+
+		bm_bppi: bm-bppi {
+			compatible = "mmio-sram";
+			reg = <MBUS_ID(0x0c, 0x04) 0 0x100000>;
+			ranges = <0 MBUS_ID(0x0c, 0x04) 0 0x100000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&gateclk 13>;
+			status = "disabled";
+		};
 	};
 
 	clocks {
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 07:33:35 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 16:33:35 +0100
Subject: [PATCH v2 net-next 0/8] API set for HW Buffer management
Message-ID: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>

Hello,

A few weeks ago I sent a proposal for a API set for HW Buffer
management, to have a better view of the motivation for this API see
the cover letter of this proposal:
http://thread.gmane.org/gmane.linux.kernel/2125152

Since this version I took into account the review from Florian:
- The hardware buffer management helpers are no more built by default
  and now depend on a hidden config symbol which has to be selected
  by the driver if needed
- The hwbm_pool_refill() and hwbm_pool_add() now receive a gfp_t as
  argument allowing the caller to specify the flag it needs.
- buf_num is now tested to ensure there is no wrapping
- A spinlock has been added to protect the hwbm_pool_add() function in
  SMP or irq context.

I also used pr_warn instead of pr_debug in case of errors.

I fixed the mvneta implementation by returning the buffer to the pool
at various place instead of ignoring it.

About the series itself I tried to make this series easier to merge:
- Squashed "bus: mvenus-mbus: Fix size test for
   mvebu_mbus_get_dram_win_info" into bus: mvebu-mbus: provide api for
   obtaining IO and DRAM window information.
- Added my signed-otf-by on all the patches as submitter of the series.
- Renamed the dts patches with the pattern "ARM: dts: platform:"
- Removed the patch "ARM: mvebu: enable SRAM support in
  mvebu_v7_defconfig" of this series and already applied it
- Rodified the order of the patches.

In order to ease the test the branch mvneta-BM-framework-v2 is
available at git at github.com:MISL-EBU-System-SW/mainline-public.git.

David,

I would like to merge the 4 first patches myself once you will have
take the 4 last patches of the series. Patch 5 do not modify files in
the net subsystem, but as there is a build dependency it is better if
you merge it in the same time as the 3 other ones.

Thanks,

Gregory

Gregory CLEMENT (2):
  net: add a hardware buffer management helper API
  net: mvneta: Use the new hwbm framework

Marcin Wojtas (6):
  ARM: dts: armada-38x: add buffer manager nodes
  ARM: dts: armada-38x: enable buffer manager support on Armada 38x
    boards
  ARM: dts: armada-xp: add buffer manager nodes
  ARM: dts: armada-xp: enable buffer manager support on Armada XP boards
  bus: mvebu-mbus: provide api for obtaining IO and DRAM window
    information
  net: mvneta: bm: add support for hardware buffer management

 .../bindings/net/marvell-armada-370-neta.txt       |  19 +-
 .../devicetree/bindings/net/marvell-neta-bm.txt    |  49 +++
 arch/arm/boot/dts/armada-385-db-ap.dts             |  20 +-
 arch/arm/boot/dts/armada-388-clearfog.dts          |   6 +
 arch/arm/boot/dts/armada-388-db.dts                |  17 +-
 arch/arm/boot/dts/armada-388-gp.dts                |  17 +-
 .../arm/boot/dts/armada-38x-solidrun-microsom.dtsi |  15 +-
 arch/arm/boot/dts/armada-38x.dtsi                  |  18 +
 arch/arm/boot/dts/armada-xp-db.dts                 |  19 +-
 arch/arm/boot/dts/armada-xp-gp.dts                 |  19 +-
 arch/arm/boot/dts/armada-xp.dtsi                   |  18 +
 drivers/bus/mvebu-mbus.c                           |  51 +++
 drivers/net/ethernet/marvell/Kconfig               |  15 +
 drivers/net/ethernet/marvell/Makefile              |   1 +
 drivers/net/ethernet/marvell/mvneta.c              | 430 +++++++++++++++---
 drivers/net/ethernet/marvell/mvneta_bm.c           | 486 +++++++++++++++++++++
 drivers/net/ethernet/marvell/mvneta_bm.h           | 162 +++++++
 include/linux/mbus.h                               |   3 +
 include/net/hwbm.h                                 |  21 +
 net/Kconfig                                        |   3 +
 net/core/Makefile                                  |   1 +
 net/core/hwbm.c                                    |  87 ++++
 22 files changed, 1415 insertions(+), 62 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/marvell-neta-bm.txt
 create mode 100644 drivers/net/ethernet/marvell/mvneta_bm.c
 create mode 100644 drivers/net/ethernet/marvell/mvneta_bm.h
 create mode 100644 include/net/hwbm.h
 create mode 100644 net/core/hwbm.c

-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 07:33:40 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 16:33:40 +0100
Subject: [PATCH v2 net-next 5/8] bus: mvebu-mbus: provide api for obtaining IO
 and DRAM window information
In-Reply-To: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455636823-14470-6-git-send-email-gregory.clement@free-electrons.com>

From: Marcin Wojtas <mw at semihalf.com>

This commit enables finding appropriate mbus window and obtaining its
target id and attribute for given physical address in two separate
routines, both for IO and DRAM windows. This functionality
is needed for Armada XP/38x Network Controller's Buffer Manager and
PnC configuration.

[gregory.clement at free-electrons.com: Fix size test for
mvebu_mbus_get_dram_win_info]

Signed-off-by: Marcin Wojtas <mw at semihalf.com>
[DRAM window information reference in LKv3.10]
Signed-off-by: Evan Wang <xswang at marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mbus.h     |  3 +++
 2 files changed, 55 insertions(+)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index c43c3d2baf73..c2e52864bb03 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -948,6 +948,58 @@ void mvebu_mbus_get_pcie_io_aperture(struct resource *res)
 	*res = mbus_state.pcie_io_aperture;
 }
 
+int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr)
+{
+	const struct mbus_dram_target_info *dram;
+	int i;
+
+	/* Get dram info */
+	dram = mv_mbus_dram_info();
+	if (!dram) {
+		pr_err("missing DRAM information\n");
+		return -ENODEV;
+	}
+
+	/* Try to find matching DRAM window for phyaddr */
+	for (i = 0; i < dram->num_cs; i++) {
+		const struct mbus_dram_window *cs = dram->cs + i;
+
+		if (cs->base <= phyaddr &&
+			phyaddr <= (cs->base + cs->size - 1)) {
+			*target = dram->mbus_dram_target_id;
+			*attr = cs->mbus_attr;
+			return 0;
+		}
+	}
+
+	pr_err("invalid dram address 0x%x\n", phyaddr);
+	return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(mvebu_mbus_get_dram_win_info);
+
+int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size, u8 *target,
+			       u8 *attr)
+{
+	int win;
+
+	for (win = 0; win < mbus_state.soc->num_wins; win++) {
+		u64 wbase;
+		int enabled;
+
+		mvebu_mbus_read_window(&mbus_state, win, &enabled, &wbase,
+				       size, target, attr, NULL);
+
+		if (!enabled)
+			continue;
+
+		if (wbase <= phyaddr && phyaddr <= wbase + *size)
+			return win;
+	}
+
+	return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(mvebu_mbus_get_io_win_info);
+
 static __init int mvebu_mbus_debugfs_init(void)
 {
 	struct mvebu_mbus_state *s = &mbus_state;
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 1f7bc630d225..ea34a867caa0 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -69,6 +69,9 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info_nooverlap(vo
 int mvebu_mbus_save_cpu_target(u32 *store_addr);
 void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
 void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
+int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr);
+int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size, u8 *target,
+			       u8 *attr);
 int mvebu_mbus_add_window_remap_by_id(unsigned int target,
 				      unsigned int attribute,
 				      phys_addr_t base, size_t size,
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 07:33:41 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 16:33:41 +0100
Subject: [PATCH v2 net-next 6/8] net: mvneta: bm: add support for hardware
 buffer management
In-Reply-To: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455636823-14470-7-git-send-email-gregory.clement@free-electrons.com>

From: Marcin Wojtas <mw at semihalf.com>

Buffer manager (BM) is a dedicated hardware unit that can be used by all
ethernet ports of Armada XP and 38x SoC's. It allows to offload CPU on RX
path by sparing DRAM access on refilling buffer pool, hardware-based
filling of descriptor ring data and better memory utilization due to HW
arbitration for using 'short' pools for small packets.

Tests performed with A388 SoC working as a network bridge between two
packet generators showed increase of maximum processed 64B packets by
~20k (~555k packets with BM enabled vs ~535 packets without BM). Also
when pushing 1500B-packets with a line rate achieved, CPU load decreased
from around 25% without BM to 20% with BM.

BM comprise up to 4 buffer pointers' (BP) rings kept in DRAM, which
are called external BP pools - BPPE. Allocating and releasing buffer
pointers (BP) to/from BPPE is performed indirectly by write/read access
to a dedicated internal SRAM, where internal BP pools (BPPI) are placed.
BM hardware controls status of BPPE automatically, as well as assigning
proper buffers to RX descriptors. For more details please refer to
Functional Specification of Armada XP or 38x SoC.

In order to enable support for a separate hardware block, common for all
ports, a new driver has to be implemented ('mvneta_bm'). It provides
initialization sequence of address space, clocks, registers, SRAM,
empty pools' structures and also obtaining optional configuration
from DT (please refer to device tree binding documentation). mvneta_bm
exposes also a necessary API to mvneta driver, as well as a dedicated
structure with BM information (bm_priv), whose presence is used as a
flag notifying of BM usage by port. It has to be ensured that mvneta_bm
probe is executed prior to the ones in ports' driver. In case BM is not
used or its probe fails, mvneta falls back to use software buffer
management.

A sequence executed in mvneta_probe function is modified in order to have
an access to needed resources before possible port's BM initialization is
done. According to port-pools mapping provided by DT appropriate registers
are configured and the buffer pools are filled. RX path is modified
accordingly. Becaues the hardware allows a wide variety of configuration
options, following assumptions are made:
* using BM mechanisms can be selectively disabled/enabled basing
  on DT configuration among the ports
* 'long' pool's single buffer size is tied to port's MTU
* using 'long' pool by port is obligatory and it cannot be shared
* using 'short' pool for smaller packets is optional
* one 'short' pool can be shared among all ports

This commit enables hardware buffer management operation cooperating with
existing mvneta driver. New device tree binding documentation is added and
the one of mvneta is updated accordingly.

[gregory.clement at free-electrons.com: removed the suspend/resume part]

Signed-off-by: Marcin Wojtas <mw at semihalf.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 .../bindings/net/marvell-armada-370-neta.txt       |  19 +-
 .../devicetree/bindings/net/marvell-neta-bm.txt    |  49 ++
 drivers/net/ethernet/marvell/Kconfig               |  14 +
 drivers/net/ethernet/marvell/Makefile              |   1 +
 drivers/net/ethernet/marvell/mvneta.c              | 417 ++++++++++++---
 drivers/net/ethernet/marvell/mvneta_bm.c           | 562 +++++++++++++++++++++
 drivers/net/ethernet/marvell/mvneta_bm.h           | 167 ++++++
 7 files changed, 1169 insertions(+), 60 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/marvell-neta-bm.txt
 create mode 100644 drivers/net/ethernet/marvell/mvneta_bm.c
 create mode 100644 drivers/net/ethernet/marvell/mvneta_bm.h

diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
index d0cb8693963b..73be8970815e 100644
--- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
+++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
@@ -18,15 +18,30 @@ Optional properties:
   "core" for core clock and "bus" for the optional bus clock.
 
 
+Optional properties (valid only for Armada XP/38x):
+
+- buffer-manager: a phandle to a buffer manager node. Please refer to
+  Documentation/devicetree/bindings/net/marvell-neta-bm.txt
+- bm,pool-long: ID of a pool, that will accept all packets of a size
+  higher than 'short' pool's threshold (if set) and up to MTU value.
+  Obligatory, when the port is supposed to use hardware
+  buffer management.
+- bm,pool-short: ID of a pool, that will be used for accepting
+  packets of a size lower than given threshold. If not set, the port
+  will use a single 'long' pool for all packets, as defined above.
+
 Example:
 
-ethernet at d0070000 {
+ethernet at 70000 {
 	compatible = "marvell,armada-370-neta";
-	reg = <0xd0070000 0x2500>;
+	reg = <0x70000 0x2500>;
 	interrupts = <8>;
 	clocks = <&gate_clk 4>;
 	tx-csum-limit = <9800>
 	status = "okay";
 	phy = <&phy0>;
 	phy-mode = "rgmii-id";
+	buffer-manager = <&bm>;
+	bm,pool-long = <0>;
+	bm,pool-short = <1>;
 };
diff --git a/Documentation/devicetree/bindings/net/marvell-neta-bm.txt b/Documentation/devicetree/bindings/net/marvell-neta-bm.txt
new file mode 100644
index 000000000000..c1b1d7c3bde1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/marvell-neta-bm.txt
@@ -0,0 +1,49 @@
+* Marvell Armada 380/XP Buffer Manager driver (BM)
+
+Required properties:
+
+- compatible: should be "marvell,armada-380-neta-bm".
+- reg: address and length of the register set for the device.
+- clocks: a pointer to the reference clock for this device.
+- internal-mem: a phandle to BM internal SRAM definition.
+
+Optional properties (port):
+
+- pool<0 : 3>,capacity: size of external buffer pointers' ring maintained
+  in DRAM. Can be set for each pool (id 0 : 3) separately. The value has
+  to be chosen between 128 and 16352 and it also has to be aligned to 32.
+  Otherwise the driver would adjust a given number or choose default if
+  not set.
+- pool<0 : 3>,pkt-size: maximum size of a packet accepted by a given buffer
+  pointers' pool (id 0 : 3). It will be taken into consideration only when pool
+  type is 'short'. For 'long' ones it would be overridden by port's MTU.
+  If not set a driver will choose a default value.
+
+In order to see how to hook the BM to a given ethernet port, please
+refer to Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt.
+
+Example:
+
+- main node:
+
+bm: bm at c8000 {
+	compatible = "marvell,armada-380-neta-bm";
+	reg = <0xc8000 0xac>;
+	clocks = <&gateclk 13>;
+	internal-mem = <&bm_bppi>;
+	status = "okay";
+	pool2,capacity = <4096>;
+	pool1,pkt-size = <512>;
+};
+
+- internal SRAM node:
+
+bm_bppi: bm-bppi {
+	compatible = "mmio-sram";
+	reg = <MBUS_ID(0x0c, 0x04) 0 0x100000>;
+	ranges = <0 MBUS_ID(0x0c, 0x04) 0 0x100000>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+	clocks = <&gateclk 13>;
+	status = "okay";
+};
diff --git a/drivers/net/ethernet/marvell/Kconfig b/drivers/net/ethernet/marvell/Kconfig
index a1c862b4664d..6c8dc6d62572 100644
--- a/drivers/net/ethernet/marvell/Kconfig
+++ b/drivers/net/ethernet/marvell/Kconfig
@@ -40,11 +40,25 @@ config MVMDIO
 
 	  This driver is used by the MV643XX_ETH and MVNETA drivers.
 
+config MVNETA_BM
+	tristate "Marvell Armada 38x/XP network interface BM support"
+	depends on MVNETA
+	---help---
+	  This driver supports auxiliary block of the network
+	  interface units in the Marvell ARMADA XP and ARMADA 38x SoC
+	  family, which is called buffer manager.
+
+	  This driver, when enabled, strictly cooperates with mvneta
+	  driver and is common for all network ports of the devices,
+	  even for Armada 370 SoC, which doesn't support hardware
+	  buffer management.
+
 config MVNETA
 	tristate "Marvell Armada 370/38x/XP network interface support"
 	depends on PLAT_ORION
 	select MVMDIO
 	select FIXED_PHY
+	select MVNETA_BM
 	---help---
 	  This driver supports the network interface units in the
 	  Marvell ARMADA XP, ARMADA 370 and ARMADA 38x SoC family.
diff --git a/drivers/net/ethernet/marvell/Makefile b/drivers/net/ethernet/marvell/Makefile
index f6425bd2884b..ff1bffa74803 100644
--- a/drivers/net/ethernet/marvell/Makefile
+++ b/drivers/net/ethernet/marvell/Makefile
@@ -4,6 +4,7 @@
 
 obj-$(CONFIG_MVMDIO) += mvmdio.o
 obj-$(CONFIG_MV643XX_ETH) += mv643xx_eth.o
+obj-$(CONFIG_MVNETA_BM) += mvneta_bm.o
 obj-$(CONFIG_MVNETA) += mvneta.o
 obj-$(CONFIG_MVPP2) += mvpp2.o
 obj-$(CONFIG_PXA168_ETH) += pxa168_eth.o
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 662c2ee268c7..1db70565ce8b 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -30,6 +30,7 @@
 #include <linux/phy.h>
 #include <linux/platform_device.h>
 #include <linux/skbuff.h>
+#include "mvneta_bm.h"
 #include <net/ip.h>
 #include <net/ipv6.h>
 #include <net/tso.h>
@@ -37,6 +38,10 @@
 /* Registers */
 #define MVNETA_RXQ_CONFIG_REG(q)                (0x1400 + ((q) << 2))
 #define      MVNETA_RXQ_HW_BUF_ALLOC            BIT(0)
+#define      MVNETA_RXQ_SHORT_POOL_ID_SHIFT	4
+#define      MVNETA_RXQ_SHORT_POOL_ID_MASK	0x30
+#define      MVNETA_RXQ_LONG_POOL_ID_SHIFT	6
+#define      MVNETA_RXQ_LONG_POOL_ID_MASK	0xc0
 #define      MVNETA_RXQ_PKT_OFFSET_ALL_MASK     (0xf    << 8)
 #define      MVNETA_RXQ_PKT_OFFSET_MASK(offs)   ((offs) << 8)
 #define MVNETA_RXQ_THRESHOLD_REG(q)             (0x14c0 + ((q) << 2))
@@ -50,6 +55,9 @@
 #define MVNETA_RXQ_STATUS_UPDATE_REG(q)         (0x1500 + ((q) << 2))
 #define      MVNETA_RXQ_ADD_NON_OCCUPIED_SHIFT  16
 #define      MVNETA_RXQ_ADD_NON_OCCUPIED_MAX    255
+#define MVNETA_PORT_POOL_BUFFER_SZ_REG(pool)	(0x1700 + ((pool) << 2))
+#define      MVNETA_PORT_POOL_BUFFER_SZ_SHIFT	3
+#define      MVNETA_PORT_POOL_BUFFER_SZ_MASK	0xfff8
 #define MVNETA_PORT_RX_RESET                    0x1cc0
 #define      MVNETA_PORT_RX_DMA_RESET           BIT(0)
 #define MVNETA_PHY_ADDR                         0x2000
@@ -107,6 +115,7 @@
 #define MVNETA_GMAC_CLOCK_DIVIDER                0x24f4
 #define      MVNETA_GMAC_1MS_CLOCK_ENABLE        BIT(31)
 #define MVNETA_ACC_MODE                          0x2500
+#define MVNETA_BM_ADDRESS                        0x2504
 #define MVNETA_CPU_MAP(cpu)                      (0x2540 + ((cpu) << 2))
 #define      MVNETA_CPU_RXQ_ACCESS_ALL_MASK      0x000000ff
 #define      MVNETA_CPU_TXQ_ACCESS_ALL_MASK      0x0000ff00
@@ -253,7 +262,10 @@
 #define MVNETA_CPU_D_CACHE_LINE_SIZE    32
 #define MVNETA_TX_CSUM_DEF_SIZE		1600
 #define MVNETA_TX_CSUM_MAX_SIZE		9800
-#define MVNETA_ACC_MODE_EXT		1
+#define MVNETA_ACC_MODE_EXT1		1
+#define MVNETA_ACC_MODE_EXT2		2
+
+#define MVNETA_MAX_DECODE_WIN		6
 
 /* Timeout constants */
 #define MVNETA_TX_DISABLE_TIMEOUT_MSEC	1000
@@ -293,7 +305,8 @@
 	((addr >= txq->tso_hdrs_phys) && \
 	 (addr < txq->tso_hdrs_phys + txq->size * TSO_HEADER_SIZE))
 
-#define MVNETA_RX_BUF_SIZE(pkt_size)   ((pkt_size) + NET_SKB_PAD)
+#define MVNETA_RX_GET_BM_POOL_ID(rxd) \
+	(((rxd)->status & MVNETA_RXD_BM_POOL_MASK) >> MVNETA_RXD_BM_POOL_SHIFT)
 
 struct mvneta_statistic {
 	unsigned short offset;
@@ -359,6 +372,7 @@ struct mvneta_pcpu_port {
 };
 
 struct mvneta_port {
+	u8 id;
 	struct mvneta_pcpu_port __percpu	*ports;
 	struct mvneta_pcpu_stats __percpu	*stats;
 
@@ -389,6 +403,11 @@ struct mvneta_port {
 	unsigned int tx_csum_limit;
 	unsigned int use_inband_status:1;
 
+	struct mvneta_bm *bm_priv;
+	struct mvneta_bm_pool *pool_long;
+	struct mvneta_bm_pool *pool_short;
+	int bm_win_id;
+
 	u64 ethtool_stats[ARRAY_SIZE(mvneta_statistics)];
 
 	u32 indir[MVNETA_RSS_LU_TABLE_SIZE];
@@ -414,6 +433,8 @@ struct mvneta_port {
 #define MVNETA_TX_L4_CSUM_NOT	BIT(31)
 
 #define MVNETA_RXD_ERR_CRC		0x0
+#define MVNETA_RXD_BM_POOL_SHIFT	13
+#define MVNETA_RXD_BM_POOL_MASK		(BIT(13) | BIT(14))
 #define MVNETA_RXD_ERR_SUMMARY		BIT(16)
 #define MVNETA_RXD_ERR_OVERRUN		BIT(17)
 #define MVNETA_RXD_ERR_LEN		BIT(18)
@@ -824,6 +845,214 @@ static void mvneta_rxq_bm_disable(struct mvneta_port *pp,
 	mvreg_write(pp, MVNETA_RXQ_CONFIG_REG(rxq->id), val);
 }
 
+/* Enable buffer management (BM) */
+static void mvneta_rxq_bm_enable(struct mvneta_port *pp,
+				 struct mvneta_rx_queue *rxq)
+{
+	u32 val;
+
+	val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id));
+	val |= MVNETA_RXQ_HW_BUF_ALLOC;
+	mvreg_write(pp, MVNETA_RXQ_CONFIG_REG(rxq->id), val);
+}
+
+/* Notify HW about port's assignment of pool for bigger packets */
+static void mvneta_rxq_long_pool_set(struct mvneta_port *pp,
+				     struct mvneta_rx_queue *rxq)
+{
+	u32 val;
+
+	val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id));
+	val &= ~MVNETA_RXQ_LONG_POOL_ID_MASK;
+	val |= (pp->pool_long->id << MVNETA_RXQ_LONG_POOL_ID_SHIFT);
+
+	mvreg_write(pp, MVNETA_RXQ_CONFIG_REG(rxq->id), val);
+}
+
+/* Notify HW about port's assignment of pool for smaller packets */
+static void mvneta_rxq_short_pool_set(struct mvneta_port *pp,
+				      struct mvneta_rx_queue *rxq)
+{
+	u32 val;
+
+	val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id));
+	val &= ~MVNETA_RXQ_SHORT_POOL_ID_MASK;
+	val |= (pp->pool_short->id << MVNETA_RXQ_SHORT_POOL_ID_SHIFT);
+
+	mvreg_write(pp, MVNETA_RXQ_CONFIG_REG(rxq->id), val);
+}
+
+/* Set port's receive buffer size for assigned BM pool */
+static inline void mvneta_bm_pool_bufsize_set(struct mvneta_port *pp,
+					      int buf_size,
+					      u8 pool_id)
+{
+	u32 val;
+
+	if (!IS_ALIGNED(buf_size, 8)) {
+		dev_warn(pp->dev->dev.parent,
+			 "illegal buf_size value %d, round to %d\n",
+			 buf_size, ALIGN(buf_size, 8));
+		buf_size = ALIGN(buf_size, 8);
+	}
+
+	val = mvreg_read(pp, MVNETA_PORT_POOL_BUFFER_SZ_REG(pool_id));
+	val |= buf_size & MVNETA_PORT_POOL_BUFFER_SZ_MASK;
+	mvreg_write(pp, MVNETA_PORT_POOL_BUFFER_SZ_REG(pool_id), val);
+}
+
+/* Configure MBUS window in order to enable access BM internal SRAM */
+static int mvneta_mbus_io_win_set(struct mvneta_port *pp, u32 base, u32 wsize,
+				  u8 target, u8 attr)
+{
+	u32 win_enable, win_protect;
+	int i;
+
+	win_enable = mvreg_read(pp, MVNETA_BASE_ADDR_ENABLE);
+
+	if (pp->bm_win_id < 0) {
+		/* Find first not occupied window */
+		for (i = 0; i < MVNETA_MAX_DECODE_WIN; i++) {
+			if (win_enable & (1 << i)) {
+				pp->bm_win_id = i;
+				break;
+			}
+		}
+		if (i == MVNETA_MAX_DECODE_WIN)
+			return -ENOMEM;
+	} else {
+		i = pp->bm_win_id;
+	}
+
+	mvreg_write(pp, MVNETA_WIN_BASE(i), 0);
+	mvreg_write(pp, MVNETA_WIN_SIZE(i), 0);
+
+	if (i < 4)
+		mvreg_write(pp, MVNETA_WIN_REMAP(i), 0);
+
+	mvreg_write(pp, MVNETA_WIN_BASE(i), (base & 0xffff0000) |
+		    (attr << 8) | target);
+
+	mvreg_write(pp, MVNETA_WIN_SIZE(i), (wsize - 1) & 0xffff0000);
+
+	win_protect = mvreg_read(pp, MVNETA_ACCESS_PROTECT_ENABLE);
+	win_protect |= 3 << (2 * i);
+	mvreg_write(pp, MVNETA_ACCESS_PROTECT_ENABLE, win_protect);
+
+	win_enable &= ~(1 << i);
+	mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable);
+
+	return 0;
+}
+
+/* Assign and initialize pools for port. In case of fail
+ * buffer manager will remain disabled for current port.
+ */
+static int mvneta_bm_port_init(struct platform_device *pdev,
+			       struct mvneta_port *pp)
+{
+	struct device_node *dn = pdev->dev.of_node;
+	u32 long_pool_id, short_pool_id, wsize;
+	u8 target, attr;
+	int err;
+
+	/* Get BM window information */
+	err = mvebu_mbus_get_io_win_info(pp->bm_priv->bppi_phys_addr, &wsize,
+					 &target, &attr);
+	if (err < 0)
+		return err;
+
+	pp->bm_win_id = -1;
+
+	/* Open NETA -> BM window */
+	err = mvneta_mbus_io_win_set(pp, pp->bm_priv->bppi_phys_addr, wsize,
+				     target, attr);
+	if (err < 0) {
+		netdev_info(pp->dev, "fail to configure mbus window to BM\n");
+		return err;
+	}
+
+	if (of_property_read_u32(dn, "bm,pool-long", &long_pool_id)) {
+		netdev_info(pp->dev, "missing long pool id\n");
+		return -EINVAL;
+	}
+
+	/* Create port's long pool depending on mtu */
+	pp->pool_long = mvneta_bm_pool_use(pp->bm_priv, long_pool_id,
+					   MVNETA_BM_LONG, pp->id,
+					   MVNETA_RX_PKT_SIZE(pp->dev->mtu));
+	if (!pp->pool_long) {
+		netdev_info(pp->dev, "fail to obtain long pool for port\n");
+		return -ENOMEM;
+	}
+
+	pp->pool_long->port_map |= 1 << pp->id;
+
+	mvneta_bm_pool_bufsize_set(pp, pp->pool_long->buf_size,
+				   pp->pool_long->id);
+
+	/* If short pool id is not defined, assume using single pool */
+	if (of_property_read_u32(dn, "bm,pool-short", &short_pool_id))
+		short_pool_id = long_pool_id;
+
+	/* Create port's short pool */
+	pp->pool_short = mvneta_bm_pool_use(pp->bm_priv, short_pool_id,
+					    MVNETA_BM_SHORT, pp->id,
+					    MVNETA_BM_SHORT_PKT_SIZE);
+	if (!pp->pool_short) {
+		netdev_info(pp->dev, "fail to obtain short pool for port\n");
+		mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_long, 1 << pp->id);
+		return -ENOMEM;
+	}
+
+	if (short_pool_id != long_pool_id) {
+		pp->pool_short->port_map |= 1 << pp->id;
+		mvneta_bm_pool_bufsize_set(pp, pp->pool_short->buf_size,
+					   pp->pool_short->id);
+	}
+
+	return 0;
+}
+
+/* Update settings of a pool for bigger packets */
+static void mvneta_bm_update_mtu(struct mvneta_port *pp, int mtu)
+{
+	struct mvneta_bm_pool *bm_pool = pp->pool_long;
+	int num;
+
+	/* Release all buffers from long pool */
+	mvneta_bm_bufs_free(pp->bm_priv, bm_pool, 1 << pp->id);
+	if (bm_pool->buf_num) {
+		WARN(1, "cannot free all buffers in pool %d\n",
+		     bm_pool->id);
+		goto bm_mtu_err;
+	}
+
+	bm_pool->pkt_size = MVNETA_RX_PKT_SIZE(mtu);
+	bm_pool->buf_size = MVNETA_RX_BUF_SIZE(bm_pool->pkt_size);
+	bm_pool->frag_size = SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) +
+			  SKB_DATA_ALIGN(MVNETA_RX_BUF_SIZE(bm_pool->pkt_size));
+
+	/* Fill entire long pool */
+	num = mvneta_bm_bufs_add(pp->bm_priv, bm_pool, bm_pool->size);
+	if (num != bm_pool->size) {
+		WARN(1, "pool %d: %d of %d allocated\n",
+		     bm_pool->id, num, bm_pool->size);
+		goto bm_mtu_err;
+	}
+	mvneta_bm_pool_bufsize_set(pp, bm_pool->buf_size, bm_pool->id);
+
+	return;
+
+bm_mtu_err:
+	mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_long, 1 << pp->id);
+	mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_short, 1 << pp->id);
+
+	pp->bm_priv = NULL;
+	mvreg_write(pp, MVNETA_ACC_MODE, MVNETA_ACC_MODE_EXT1);
+	netdev_info(pp->dev, "fail to update MTU, fall back to software BM\n");
+}
+
 /* Start the Ethernet port RX and TX activity */
 static void mvneta_port_up(struct mvneta_port *pp)
 {
@@ -1111,9 +1340,17 @@ static void mvneta_defaults_set(struct mvneta_port *pp)
 	mvreg_write(pp, MVNETA_PORT_RX_RESET, 0);
 
 	/* Set Port Acceleration Mode */
-	val = MVNETA_ACC_MODE_EXT;
+	if (pp->bm_priv)
+		/* HW buffer management + legacy parser */
+		val = MVNETA_ACC_MODE_EXT2;
+	else
+		/* SW buffer management + legacy parser */
+		val = MVNETA_ACC_MODE_EXT1;
 	mvreg_write(pp, MVNETA_ACC_MODE, val);
 
+	if (pp->bm_priv)
+		mvreg_write(pp, MVNETA_BM_ADDRESS, pp->bm_priv->bppi_phys_addr);
+
 	/* Update val of portCfg register accordingly with all RxQueue types */
 	val = MVNETA_PORT_CONFIG_DEFL_VALUE(pp->rxq_def);
 	mvreg_write(pp, MVNETA_PORT_CONFIG, val);
@@ -1480,23 +1717,7 @@ static void mvneta_txq_done(struct mvneta_port *pp,
 	}
 }
 
-static void *mvneta_frag_alloc(const struct mvneta_port *pp)
-{
-	if (likely(pp->frag_size <= PAGE_SIZE))
-		return netdev_alloc_frag(pp->frag_size);
-	else
-		return kmalloc(pp->frag_size, GFP_ATOMIC);
-}
-
-static void mvneta_frag_free(const struct mvneta_port *pp, void *data)
-{
-	if (likely(pp->frag_size <= PAGE_SIZE))
-		skb_free_frag(data);
-	else
-		kfree(data);
-}
-
-/* Refill processing */
+/* Refill processing for SW buffer management */
 static int mvneta_rx_refill(struct mvneta_port *pp,
 			    struct mvneta_rx_desc *rx_desc)
 
@@ -1504,7 +1725,7 @@ static int mvneta_rx_refill(struct mvneta_port *pp,
 	dma_addr_t phys_addr;
 	void *data;
 
-	data = mvneta_frag_alloc(pp);
+	data = mvneta_frag_alloc(pp->frag_size);
 	if (!data)
 		return -ENOMEM;
 
@@ -1512,7 +1733,7 @@ static int mvneta_rx_refill(struct mvneta_port *pp,
 				   MVNETA_RX_BUF_SIZE(pp->pkt_size),
 				   DMA_FROM_DEVICE);
 	if (unlikely(dma_mapping_error(pp->dev->dev.parent, phys_addr))) {
-		mvneta_frag_free(pp, data);
+		mvneta_frag_free(pp->frag_size, data);
 		return -ENOMEM;
 	}
 
@@ -1558,17 +1779,29 @@ static void mvneta_rxq_drop_pkts(struct mvneta_port *pp,
 	int rx_done, i;
 
 	rx_done = mvneta_rxq_busy_desc_num_get(pp, rxq);
+	if (rx_done)
+		mvneta_rxq_desc_num_update(pp, rxq, rx_done, rx_done);
+
 	for (i = 0; i < rxq->size; i++) {
 		struct mvneta_rx_desc *rx_desc = rxq->descs + i;
-		void *data = (void *)rx_desc->buf_cookie;
+		if (pp->bm_priv) {
+			/* Return the buffer to the pool */
+			u8 pool_id = MVNETA_RX_GET_BM_POOL_ID(rx_desc);
+			struct mvneta_bm_pool *bm_pool;
+
+			bm_pool = &pp->bm_priv->bm_pools[pool_id];
+			mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool,
+					      rx_desc->buf_phys_addr);
+		} else {
+			void *data = (void *)rx_desc->buf_cookie;
 
-		dma_unmap_single(pp->dev->dev.parent, rx_desc->buf_phys_addr,
-				 MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE);
-		mvneta_frag_free(pp, data);
+			dma_unmap_single(pp->dev->dev.parent,
+					 rx_desc->buf_phys_addr,
+					 MVNETA_RX_BUF_SIZE(pp->pkt_size),
+					 DMA_FROM_DEVICE);
+			mvneta_frag_free(pp->frag_size, data);
+		}
 	}
-
-	if (rx_done)
-		mvneta_rxq_desc_num_update(pp, rxq, rx_done, rx_done);
 }
 
 /* Main rx processing */
@@ -1580,6 +1813,7 @@ static int mvneta_rx(struct mvneta_port *pp, int rx_todo,
 	int rx_done;
 	u32 rcvd_pkts = 0;
 	u32 rcvd_bytes = 0;
+	bool bm_in_use;
 
 	/* Get number of received packets */
 	rx_done = mvneta_rxq_busy_desc_num_get(pp, rxq);
@@ -1589,24 +1823,37 @@ static int mvneta_rx(struct mvneta_port *pp, int rx_todo,
 
 	rx_done = 0;
 
+	bm_in_use = pp->bm_priv ? true : false;
+
 	/* Fairness NAPI loop */
 	while (rx_done < rx_todo) {
 		struct mvneta_rx_desc *rx_desc = mvneta_rxq_next_desc_get(rxq);
+		struct mvneta_bm_pool *bm_pool = NULL;
 		struct sk_buff *skb;
 		unsigned char *data;
 		dma_addr_t phys_addr;
-		u32 rx_status;
+		u32 rx_status, frag_size;
 		int rx_bytes, err;
+		u8 pool_id;
 
 		rx_done++;
 		rx_status = rx_desc->status;
 		rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE);
 		data = (unsigned char *)rx_desc->buf_cookie;
 		phys_addr = rx_desc->buf_phys_addr;
+		if (bm_in_use) {
+			pool_id = MVNETA_RX_GET_BM_POOL_ID(rx_desc);
+			bm_pool = &pp->bm_priv->bm_pools[pool_id];
+		}
 
 		if (!mvneta_rxq_desc_is_first_last(rx_status) ||
 		    (rx_status & MVNETA_RXD_ERR_SUMMARY)) {
-		err_drop_frame:
+err_drop_frame_ret_pool:
+			/* Return the buffer to the pool */
+			if (bm_in_use)
+				mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool,
+						      rx_desc->buf_phys_addr);
+err_drop_frame:
 			dev->stats.rx_errors++;
 			mvneta_rx_error(pp, rx_desc);
 			/* leave the descriptor untouched */
@@ -1617,7 +1864,7 @@ static int mvneta_rx(struct mvneta_port *pp, int rx_todo,
 			/* better copy a small frame and not unmap the DMA region */
 			skb = netdev_alloc_skb_ip_align(dev, rx_bytes);
 			if (unlikely(!skb))
-				goto err_drop_frame;
+				goto err_drop_frame_ret_pool;
 
 			dma_sync_single_range_for_cpu(dev->dev.parent,
 			                              rx_desc->buf_phys_addr,
@@ -1635,25 +1882,38 @@ static int mvneta_rx(struct mvneta_port *pp, int rx_todo,
 			rcvd_pkts++;
 			rcvd_bytes += rx_bytes;
 
+			/* Return the buffer to the pool */
+			if (bm_in_use)
+				mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool,
+						      rx_desc->buf_phys_addr);
+
 			/* leave the descriptor and buffer untouched */
 			continue;
 		}
 
 		/* Refill processing */
-		err = mvneta_rx_refill(pp, rx_desc);
+		err = bm_in_use ? mvneta_bm_pool_refill(pp->bm_priv, bm_pool) :
+				  mvneta_rx_refill(pp, rx_desc);
 		if (err) {
 			netdev_err(dev, "Linux processing - Can't refill\n");
 			rxq->missed++;
-			goto err_drop_frame;
+			goto err_drop_frame_ret_pool;
 		}
 
-		skb = build_skb(data, pp->frag_size > PAGE_SIZE ? 0 : pp->frag_size);
+		frag_size = bm_in_use ? bm_pool->frag_size : pp->frag_size;
+
+		skb = build_skb(data, frag_size > PAGE_SIZE ? 0 : frag_size);
 
 		/* After refill old buffer has to be unmapped regardless
 		 * the skb is successfully built or not.
 		 */
-		dma_unmap_single(dev->dev.parent, phys_addr,
-				 MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE);
+		if (bm_in_use)
+			dma_unmap_single(&pp->bm_priv->pdev->dev, phys_addr,
+					 bm_pool->buf_size, DMA_FROM_DEVICE);
+		else
+			dma_unmap_single(dev->dev.parent, phys_addr,
+					 MVNETA_RX_BUF_SIZE(pp->pkt_size),
+					 DMA_FROM_DEVICE);
 
 		if (!skb)
 			goto err_drop_frame;
@@ -2348,9 +2608,17 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
 	mvneta_rx_pkts_coal_set(pp, rxq, rxq->pkts_coal);
 	mvneta_rx_time_coal_set(pp, rxq, rxq->time_coal);
 
-	/* Fill RXQ with buffers from RX pool */
-	mvneta_rxq_buf_size_set(pp, rxq, MVNETA_RX_BUF_SIZE(pp->pkt_size));
-	mvneta_rxq_bm_disable(pp, rxq);
+	if (!pp->bm_priv) {
+		/* Fill RXQ with buffers from RX pool */
+		mvneta_rxq_buf_size_set(pp, rxq,
+					MVNETA_RX_BUF_SIZE(pp->pkt_size));
+		mvneta_rxq_bm_disable(pp, rxq);
+	} else {
+		mvneta_rxq_bm_enable(pp, rxq);
+		mvneta_rxq_long_pool_set(pp, rxq);
+		mvneta_rxq_short_pool_set(pp, rxq);
+	}
+
 	mvneta_rxq_fill(pp, rxq, rxq->size);
 
 	return 0;
@@ -2652,6 +2920,9 @@ static int mvneta_change_mtu(struct net_device *dev, int mtu)
 	dev->mtu = mtu;
 
 	if (!netif_running(dev)) {
+		if (pp->bm_priv)
+			mvneta_bm_update_mtu(pp, mtu);
+
 		netdev_update_features(dev);
 		return 0;
 	}
@@ -2664,6 +2935,9 @@ static int mvneta_change_mtu(struct net_device *dev, int mtu)
 	mvneta_cleanup_txqs(pp);
 	mvneta_cleanup_rxqs(pp);
 
+	if (pp->bm_priv)
+		mvneta_bm_update_mtu(pp, mtu);
+
 	pp->pkt_size = MVNETA_RX_PKT_SIZE(dev->mtu);
 	pp->frag_size = SKB_DATA_ALIGN(MVNETA_RX_BUF_SIZE(pp->pkt_size)) +
 	                SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
@@ -3539,6 +3813,7 @@ static int mvneta_probe(struct platform_device *pdev)
 	struct resource *res;
 	struct device_node *dn = pdev->dev.of_node;
 	struct device_node *phy_node;
+	struct device_node *bm_node;
 	struct mvneta_port *pp;
 	struct net_device *dev;
 	const char *dt_mac_addr;
@@ -3672,26 +3947,51 @@ static int mvneta_probe(struct platform_device *pdev)
 
 	pp->tx_csum_limit = tx_csum_limit;
 
+	dram_target_info = mv_mbus_dram_info();
+	if (dram_target_info)
+		mvneta_conf_mbus_windows(pp, dram_target_info);
+
 	pp->tx_ring_size = MVNETA_MAX_TXD;
 	pp->rx_ring_size = MVNETA_MAX_RXD;
 
 	pp->dev = dev;
 	SET_NETDEV_DEV(dev, &pdev->dev);
 
+	dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO;
+	dev->hw_features |= dev->features;
+	dev->vlan_features |= dev->features;
+	dev->priv_flags |= IFF_UNICAST_FLT;
+	dev->gso_max_segs = MVNETA_MAX_TSO_SEGS;
+
+	err = register_netdev(dev);
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to register\n");
+		goto err_free_stats;
+	}
+
+	pp->id = dev->ifindex;
+
+	/* Obtain access to BM resources if enabled and already initialized */
+	bm_node = of_parse_phandle(dn, "buffer-manager", 0);
+	if (bm_node && bm_node->data) {
+		pp->bm_priv = bm_node->data;
+		err = mvneta_bm_port_init(pdev, pp);
+		if (err < 0) {
+			dev_info(&pdev->dev, "use SW buffer management\n");
+			pp->bm_priv = NULL;
+		}
+	}
+
 	err = mvneta_init(&pdev->dev, pp);
 	if (err < 0)
-		goto err_free_stats;
+		goto err_netdev;
 
 	err = mvneta_port_power_up(pp, phy_mode);
 	if (err < 0) {
 		dev_err(&pdev->dev, "can't power up port\n");
-		goto err_free_stats;
+		goto err_netdev;
 	}
 
-	dram_target_info = mv_mbus_dram_info();
-	if (dram_target_info)
-		mvneta_conf_mbus_windows(pp, dram_target_info);
-
 	for_each_present_cpu(cpu) {
 		struct mvneta_pcpu_port *port = per_cpu_ptr(pp->ports, cpu);
 
@@ -3699,18 +3999,6 @@ static int mvneta_probe(struct platform_device *pdev)
 		port->pp = pp;
 	}
 
-	dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO;
-	dev->hw_features |= dev->features;
-	dev->vlan_features |= dev->features;
-	dev->priv_flags |= IFF_UNICAST_FLT;
-	dev->gso_max_segs = MVNETA_MAX_TSO_SEGS;
-
-	err = register_netdev(dev);
-	if (err < 0) {
-		dev_err(&pdev->dev, "failed to register\n");
-		goto err_free_stats;
-	}
-
 	netdev_info(dev, "Using %s mac address %pM\n", mac_from,
 		    dev->dev_addr);
 
@@ -3726,6 +4014,13 @@ static int mvneta_probe(struct platform_device *pdev)
 
 	return 0;
 
+err_netdev:
+	unregister_netdev(dev);
+	if (pp->bm_priv) {
+		mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_long, 1 << pp->id);
+		mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_short,
+				       1 << pp->id);
+	}
 err_free_stats:
 	free_percpu(pp->stats);
 err_free_ports:
@@ -3757,6 +4052,12 @@ static int mvneta_remove(struct platform_device *pdev)
 	of_node_put(pp->phy_node);
 	free_netdev(dev);
 
+	if (pp->bm_priv) {
+		mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_long, 1 << pp->id);
+		mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_short,
+				       1 << pp->id);
+	}
+
 	return 0;
 }
 
diff --git a/drivers/net/ethernet/marvell/mvneta_bm.c b/drivers/net/ethernet/marvell/mvneta_bm.c
new file mode 100644
index 000000000000..ff7e73c6d31c
--- /dev/null
+++ b/drivers/net/ethernet/marvell/mvneta_bm.c
@@ -0,0 +1,562 @@
+/*
+ * Driver for Marvell NETA network controller Buffer Manager.
+ *
+ * Copyright (C) 2015 Marvell
+ *
+ * Marcin Wojtas <mw at semihalf.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/genalloc.h>
+#include <linux/platform_device.h>
+#include <linux/netdevice.h>
+#include <linux/skbuff.h>
+#include <linux/mbus.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/clk.h>
+#include "mvneta_bm.h"
+
+#define MVNETA_BM_DRIVER_NAME "mvneta_bm"
+#define MVNETA_BM_DRIVER_VERSION "1.0"
+
+static void mvneta_bm_write(struct mvneta_bm *priv, u32 offset, u32 data)
+{
+	writel(data, priv->reg_base + offset);
+}
+
+static u32 mvneta_bm_read(struct mvneta_bm *priv, u32 offset)
+{
+	return readl(priv->reg_base + offset);
+}
+
+static void mvneta_bm_pool_enable(struct mvneta_bm *priv, int pool_id)
+{
+	u32 val;
+
+	val = mvneta_bm_read(priv, MVNETA_BM_POOL_BASE_REG(pool_id));
+	val |= MVNETA_BM_POOL_ENABLE_MASK;
+	mvneta_bm_write(priv, MVNETA_BM_POOL_BASE_REG(pool_id), val);
+
+	/* Clear BM cause register */
+	mvneta_bm_write(priv, MVNETA_BM_INTR_CAUSE_REG, 0);
+}
+
+static void mvneta_bm_pool_disable(struct mvneta_bm *priv, int pool_id)
+{
+	u32 val;
+
+	val = mvneta_bm_read(priv, MVNETA_BM_POOL_BASE_REG(pool_id));
+	val &= ~MVNETA_BM_POOL_ENABLE_MASK;
+	mvneta_bm_write(priv, MVNETA_BM_POOL_BASE_REG(pool_id), val);
+}
+
+static inline void mvneta_bm_config_set(struct mvneta_bm *priv, u32 mask)
+{
+	u32 val;
+
+	val = mvneta_bm_read(priv, MVNETA_BM_CONFIG_REG);
+	val |= mask;
+	mvneta_bm_write(priv, MVNETA_BM_CONFIG_REG, val);
+}
+
+static inline void mvneta_bm_config_clear(struct mvneta_bm *priv, u32 mask)
+{
+	u32 val;
+
+	val = mvneta_bm_read(priv, MVNETA_BM_CONFIG_REG);
+	val &= ~mask;
+	mvneta_bm_write(priv, MVNETA_BM_CONFIG_REG, val);
+}
+
+static void mvneta_bm_pool_target_set(struct mvneta_bm *priv, int pool_id,
+				      u8 target_id, u8 attr)
+{
+	u32 val;
+
+	val = mvneta_bm_read(priv, MVNETA_BM_XBAR_POOL_REG(pool_id));
+	val &= ~MVNETA_BM_TARGET_ID_MASK(pool_id);
+	val &= ~MVNETA_BM_XBAR_ATTR_MASK(pool_id);
+	val |= MVNETA_BM_TARGET_ID_VAL(pool_id, target_id);
+	val |= MVNETA_BM_XBAR_ATTR_VAL(pool_id, attr);
+
+	mvneta_bm_write(priv, MVNETA_BM_XBAR_POOL_REG(pool_id), val);
+}
+
+void *mvneta_frag_alloc(unsigned int frag_size)
+{
+	if (likely(frag_size <= PAGE_SIZE))
+		return netdev_alloc_frag(frag_size);
+	else
+		return kmalloc(frag_size, GFP_ATOMIC);
+}
+EXPORT_SYMBOL_GPL(mvneta_frag_alloc);
+
+void mvneta_frag_free(unsigned int frag_size, void *data)
+{
+	if (likely(frag_size <= PAGE_SIZE))
+		skb_free_frag(data);
+	else
+		kfree(data);
+}
+EXPORT_SYMBOL_GPL(mvneta_frag_free);
+
+/* Allocate skb for BM pool */
+void *mvneta_buf_alloc(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool,
+		       dma_addr_t *buf_phys_addr)
+{
+	void *buf;
+	dma_addr_t phys_addr;
+
+	buf = mvneta_frag_alloc(bm_pool->frag_size);
+	if (!buf)
+		return NULL;
+
+	/* In order to update buf_cookie field of RX descriptor properly,
+	 * BM hardware expects buf virtual address to be placed in the
+	 * first four bytes of mapped buffer.
+	 */
+	*(u32 *)buf = (u32)buf;
+	phys_addr = dma_map_single(&priv->pdev->dev, buf, bm_pool->buf_size,
+				   DMA_FROM_DEVICE);
+	if (unlikely(dma_mapping_error(&priv->pdev->dev, phys_addr))) {
+		mvneta_frag_free(bm_pool->frag_size, buf);
+		return NULL;
+	}
+	*buf_phys_addr = phys_addr;
+
+	return buf;
+}
+
+/* Refill processing for HW buffer management */
+int mvneta_bm_pool_refill(struct mvneta_bm *priv,
+			  struct mvneta_bm_pool *bm_pool)
+{
+	dma_addr_t buf_phys_addr;
+	void *buf;
+
+	buf = mvneta_buf_alloc(priv, bm_pool, &buf_phys_addr);
+	if (!buf)
+		return -ENOMEM;
+
+	mvneta_bm_pool_put_bp(priv, bm_pool, buf_phys_addr);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(mvneta_bm_pool_refill);
+
+/* Allocate buffers for the pool */
+int mvneta_bm_bufs_add(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool,
+		       int buf_num)
+{
+	int err, i;
+
+	if (bm_pool->buf_num == bm_pool->size) {
+		dev_dbg(&priv->pdev->dev, "pool %d already filled\n",
+			bm_pool->id);
+		return bm_pool->buf_num;
+	}
+
+	if (buf_num < 0 ||
+	    (buf_num + bm_pool->buf_num > bm_pool->size)) {
+		dev_err(&priv->pdev->dev,
+			"cannot allocate %d buffers for pool %d\n",
+			buf_num, bm_pool->id);
+		return 0;
+	}
+
+	for (i = 0; i < buf_num; i++) {
+		err = mvneta_bm_pool_refill(priv, bm_pool);
+		if (err < 0)
+			break;
+	}
+
+	/* Update BM driver with number of buffers added to pool */
+	bm_pool->buf_num += i;
+
+	dev_dbg(&priv->pdev->dev,
+		"%s pool %d: pkt_size=%4d, buf_size=%4d, frag_size=%4d\n",
+		bm_pool->type == MVNETA_BM_SHORT ? "short" : "long",
+		bm_pool->id, bm_pool->pkt_size, bm_pool->buf_size,
+		bm_pool->frag_size);
+
+	dev_dbg(&priv->pdev->dev,
+		"%s pool %d: %d of %d buffers added\n",
+		bm_pool->type == MVNETA_BM_SHORT ? "short" : "long",
+		bm_pool->id, i, buf_num);
+
+	return i;
+}
+
+/* Create pool */
+static int mvneta_bm_pool_create(struct mvneta_bm *priv,
+				 struct mvneta_bm_pool *bm_pool)
+{
+	struct platform_device *pdev = priv->pdev;
+	u8 target_id, attr;
+	int size_bytes, err;
+
+	size_bytes = sizeof(u32) * bm_pool->size;
+	bm_pool->virt_addr = dma_alloc_coherent(&pdev->dev, size_bytes,
+						&bm_pool->phys_addr,
+						GFP_KERNEL);
+	if (!bm_pool->virt_addr)
+		return -ENOMEM;
+
+	if (!IS_ALIGNED((u32)bm_pool->virt_addr, MVNETA_BM_POOL_PTR_ALIGN)) {
+		dma_free_coherent(&pdev->dev, size_bytes, bm_pool->virt_addr,
+				  bm_pool->phys_addr);
+		dev_err(&pdev->dev, "BM pool %d is not %d bytes aligned\n",
+			bm_pool->id, MVNETA_BM_POOL_PTR_ALIGN);
+		return -ENOMEM;
+	}
+
+	err = mvebu_mbus_get_dram_win_info(bm_pool->phys_addr, &target_id,
+					   &attr);
+	if (err < 0) {
+		dma_free_coherent(&pdev->dev, size_bytes, bm_pool->virt_addr,
+				  bm_pool->phys_addr);
+		return err;
+	}
+
+	/* Set pool address */
+	mvneta_bm_write(priv, MVNETA_BM_POOL_BASE_REG(bm_pool->id),
+			bm_pool->phys_addr);
+
+	mvneta_bm_pool_target_set(priv, bm_pool->id, target_id,  attr);
+	mvneta_bm_pool_enable(priv, bm_pool->id);
+
+	return 0;
+}
+
+/* Notify the driver that BM pool is being used as specific type and return the
+ * pool pointer on success
+ */
+struct mvneta_bm_pool *mvneta_bm_pool_use(struct mvneta_bm *priv, u8 pool_id,
+					  enum mvneta_bm_type type, u8 port_id,
+					  int pkt_size)
+{
+	struct mvneta_bm_pool *new_pool = &priv->bm_pools[pool_id];
+	int num, err;
+
+	if (new_pool->type == MVNETA_BM_LONG &&
+	    new_pool->port_map != 1 << port_id) {
+		dev_err(&priv->pdev->dev,
+			"long pool cannot be shared by the ports\n");
+		return NULL;
+	}
+
+	if (new_pool->type == MVNETA_BM_SHORT && new_pool->type != type) {
+		dev_err(&priv->pdev->dev,
+			"mixing pools' types between the ports is forbidden\n");
+		return NULL;
+	}
+
+	if (new_pool->pkt_size == 0 || type != MVNETA_BM_SHORT)
+		new_pool->pkt_size = pkt_size;
+
+	/* Allocate buffers in case BM pool hasn't been used yet */
+	if (new_pool->type == MVNETA_BM_FREE) {
+		new_pool->type = type;
+		new_pool->buf_size = MVNETA_RX_BUF_SIZE(new_pool->pkt_size);
+		new_pool->frag_size =
+			SKB_DATA_ALIGN(MVNETA_RX_BUF_SIZE(new_pool->pkt_size)) +
+			SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+
+		/* Create new pool */
+		err = mvneta_bm_pool_create(priv, new_pool);
+		if (err) {
+			dev_err(&priv->pdev->dev, "fail to create pool %d\n",
+				new_pool->id);
+			return NULL;
+		}
+
+		/* Allocate buffers for this pool */
+		num = mvneta_bm_bufs_add(priv, new_pool, new_pool->size);
+		if (num != new_pool->size) {
+			WARN(1, "pool %d: %d of %d allocated\n",
+			     new_pool->id, num, new_pool->size);
+			return NULL;
+		}
+	}
+
+	return new_pool;
+}
+EXPORT_SYMBOL_GPL(mvneta_bm_pool_use);
+
+/* Free all buffers from the pool */
+void mvneta_bm_bufs_free(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool,
+			 u8 port_map)
+{
+	int i;
+
+	bm_pool->port_map &= ~port_map;
+	if (bm_pool->port_map)
+		return;
+
+	mvneta_bm_config_set(priv, MVNETA_BM_EMPTY_LIMIT_MASK);
+
+	for (i = 0; i < bm_pool->buf_num; i++) {
+		dma_addr_t buf_phys_addr;
+		u32 *vaddr;
+
+		/* Get buffer physical address (indirect access) */
+		buf_phys_addr = mvneta_bm_pool_get_bp(priv, bm_pool);
+
+		/* Work-around to the problems when destroying the pool,
+		 * when it occurs that a read access to BPPI returns 0.
+		 */
+		if (buf_phys_addr == 0)
+			continue;
+
+		vaddr = phys_to_virt(buf_phys_addr);
+		if (!vaddr)
+			break;
+
+		dma_unmap_single(&priv->pdev->dev, buf_phys_addr,
+				 bm_pool->buf_size, DMA_FROM_DEVICE);
+		mvneta_frag_free(bm_pool->frag_size, vaddr);
+	}
+
+	mvneta_bm_config_clear(priv, MVNETA_BM_EMPTY_LIMIT_MASK);
+
+	/* Update BM driver with number of buffers removed from pool */
+	bm_pool->buf_num -= i;
+}
+
+/* Cleanup pool */
+void mvneta_bm_pool_destroy(struct mvneta_bm *priv,
+			    struct mvneta_bm_pool *bm_pool, u8 port_map)
+{
+	bm_pool->port_map &= ~port_map;
+	if (bm_pool->port_map)
+		return;
+
+	bm_pool->type = MVNETA_BM_FREE;
+
+	mvneta_bm_bufs_free(priv, bm_pool, port_map);
+	if (bm_pool->buf_num)
+		WARN(1, "cannot free all buffers in pool %d\n", bm_pool->id);
+
+	if (bm_pool->virt_addr) {
+		dma_free_coherent(&priv->pdev->dev, sizeof(u32) * bm_pool->size,
+				  bm_pool->virt_addr, bm_pool->phys_addr);
+		bm_pool->virt_addr = NULL;
+	}
+
+	mvneta_bm_pool_disable(priv, bm_pool->id);
+}
+EXPORT_SYMBOL_GPL(mvneta_bm_pool_destroy);
+
+static void mvneta_bm_pools_init(struct mvneta_bm *priv)
+{
+	struct device_node *dn = priv->pdev->dev.of_node;
+	struct mvneta_bm_pool *bm_pool;
+	char prop[15];
+	u32 size;
+	int i;
+
+	/* Activate BM unit */
+	mvneta_bm_write(priv, MVNETA_BM_COMMAND_REG, MVNETA_BM_START_MASK);
+
+	/* Create all pools with maximum size */
+	for (i = 0; i < MVNETA_BM_POOLS_NUM; i++) {
+		bm_pool = &priv->bm_pools[i];
+		bm_pool->id = i;
+		bm_pool->type = MVNETA_BM_FREE;
+
+		/* Reset read pointer */
+		mvneta_bm_write(priv, MVNETA_BM_POOL_READ_PTR_REG(i), 0);
+
+		/* Reset write pointer */
+		mvneta_bm_write(priv, MVNETA_BM_POOL_WRITE_PTR_REG(i), 0);
+
+		/* Configure pool size according to DT or use default value */
+		sprintf(prop, "pool%d,capacity", i);
+		if (of_property_read_u32(dn, prop, &size)) {
+			size = MVNETA_BM_POOL_CAP_DEF;
+		} else if (size > MVNETA_BM_POOL_CAP_MAX) {
+			dev_warn(&priv->pdev->dev,
+				 "Illegal pool %d capacity %d, set to %d\n",
+				 i, size, MVNETA_BM_POOL_CAP_MAX);
+			size = MVNETA_BM_POOL_CAP_MAX;
+		} else if (size < MVNETA_BM_POOL_CAP_MIN) {
+			dev_warn(&priv->pdev->dev,
+				 "Illegal pool %d capacity %d, set to %d\n",
+				 i, size, MVNETA_BM_POOL_CAP_MIN);
+			size = MVNETA_BM_POOL_CAP_MIN;
+		} else if (!IS_ALIGNED(size, MVNETA_BM_POOL_CAP_ALIGN)) {
+			dev_warn(&priv->pdev->dev,
+				 "Illegal pool %d capacity %d, round to %d\n",
+				 i, size, ALIGN(size,
+				 MVNETA_BM_POOL_CAP_ALIGN));
+			size = ALIGN(size, MVNETA_BM_POOL_CAP_ALIGN);
+		}
+		bm_pool->size = size;
+
+		mvneta_bm_write(priv, MVNETA_BM_POOL_SIZE_REG(i),
+				bm_pool->size);
+
+		/* Obtain custom pkt_size from DT */
+		sprintf(prop, "pool%d,pkt-size", i);
+		if (of_property_read_u32(dn, prop, &bm_pool->pkt_size))
+			bm_pool->pkt_size = 0;
+	}
+}
+
+static void mvneta_bm_default_set(struct mvneta_bm *priv)
+{
+	u32 val;
+
+	/* Mask BM all interrupts */
+	mvneta_bm_write(priv, MVNETA_BM_INTR_MASK_REG, 0);
+
+	/* Clear BM cause register */
+	mvneta_bm_write(priv, MVNETA_BM_INTR_CAUSE_REG, 0);
+
+	/* Set BM configuration register */
+	val = mvneta_bm_read(priv, MVNETA_BM_CONFIG_REG);
+
+	/* Reduce MaxInBurstSize from 32 BPs to 16 BPs */
+	val &= ~MVNETA_BM_MAX_IN_BURST_SIZE_MASK;
+	val |= MVNETA_BM_MAX_IN_BURST_SIZE_16BP;
+	mvneta_bm_write(priv, MVNETA_BM_CONFIG_REG, val);
+}
+
+static int mvneta_bm_init(struct mvneta_bm *priv)
+{
+	mvneta_bm_default_set(priv);
+
+	/* Allocate and initialize BM pools structures */
+	priv->bm_pools = devm_kcalloc(&priv->pdev->dev, MVNETA_BM_POOLS_NUM,
+				      sizeof(struct mvneta_bm_pool),
+				      GFP_KERNEL);
+	if (!priv->bm_pools)
+		return -ENOMEM;
+
+	mvneta_bm_pools_init(priv);
+
+	return 0;
+}
+
+static int mvneta_bm_get_sram(struct device_node *dn,
+			      struct mvneta_bm *priv)
+{
+	priv->bppi_pool = of_gen_pool_get(dn, "internal-mem", 0);
+	if (!priv->bppi_pool)
+		return -ENOMEM;
+
+	priv->bppi_virt_addr = gen_pool_dma_alloc(priv->bppi_pool,
+						  MVNETA_BM_BPPI_SIZE,
+						  &priv->bppi_phys_addr);
+	if (!priv->bppi_virt_addr)
+		return -ENOMEM;
+
+	return 0;
+}
+
+static void mvneta_bm_put_sram(struct mvneta_bm *priv)
+{
+	gen_pool_free(priv->bppi_pool, priv->bppi_phys_addr,
+		      MVNETA_BM_BPPI_SIZE);
+}
+
+static int mvneta_bm_probe(struct platform_device *pdev)
+{
+	struct device_node *dn = pdev->dev.of_node;
+	struct mvneta_bm *priv;
+	struct resource *res;
+	int err;
+
+	priv = devm_kzalloc(&pdev->dev, sizeof(struct mvneta_bm), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	priv->reg_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(priv->reg_base))
+		return PTR_ERR(priv->reg_base);
+
+	priv->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(priv->clk))
+		return PTR_ERR(priv->clk);
+	err = clk_prepare_enable(priv->clk);
+	if (err < 0)
+		return err;
+
+	err = mvneta_bm_get_sram(dn, priv);
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to allocate internal memory\n");
+		goto err_clk;
+	}
+
+	priv->pdev = pdev;
+
+	/* Initialize buffer manager internals */
+	err = mvneta_bm_init(priv);
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to initialize controller\n");
+		goto err_sram;
+	}
+
+	dn->data = priv;
+	platform_set_drvdata(pdev, priv);
+
+	dev_info(&pdev->dev, "Buffer Manager for network controller enabled\n");
+
+	return 0;
+
+err_sram:
+	mvneta_bm_put_sram(priv);
+err_clk:
+	clk_disable_unprepare(priv->clk);
+	return err;
+}
+
+static int mvneta_bm_remove(struct platform_device *pdev)
+{
+	struct mvneta_bm *priv = platform_get_drvdata(pdev);
+	u8 all_ports_map = 0xff;
+	int i = 0;
+
+	for (i = 0; i < MVNETA_BM_POOLS_NUM; i++) {
+		struct mvneta_bm_pool *bm_pool = &priv->bm_pools[i];
+
+		mvneta_bm_pool_destroy(priv, bm_pool, all_ports_map);
+	}
+
+	mvneta_bm_put_sram(priv);
+
+	/* Dectivate BM unit */
+	mvneta_bm_write(priv, MVNETA_BM_COMMAND_REG, MVNETA_BM_STOP_MASK);
+
+	clk_disable_unprepare(priv->clk);
+
+	return 0;
+}
+
+static const struct of_device_id mvneta_bm_match[] = {
+	{ .compatible = "marvell,armada-380-neta-bm" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, mvneta_bm_match);
+
+static struct platform_driver mvneta_bm_driver = {
+	.probe = mvneta_bm_probe,
+	.remove = mvneta_bm_remove,
+	.driver = {
+		.name = MVNETA_BM_DRIVER_NAME,
+		.of_match_table = mvneta_bm_match,
+	},
+};
+
+module_platform_driver(mvneta_bm_driver);
+
+MODULE_DESCRIPTION("Marvell NETA Buffer Manager Driver - www.marvell.com");
+MODULE_AUTHOR("Marcin Wojtas <mw at semihalf.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/net/ethernet/marvell/mvneta_bm.h b/drivers/net/ethernet/marvell/mvneta_bm.h
new file mode 100644
index 000000000000..f2449b843577
--- /dev/null
+++ b/drivers/net/ethernet/marvell/mvneta_bm.h
@@ -0,0 +1,167 @@
+/*
+ * Driver for Marvell NETA network controller Buffer Manager.
+ *
+ * Copyright (C) 2015 Marvell
+ *
+ * Marcin Wojtas <mw at semihalf.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef _MVNETA_BM_H_
+#define _MVNETA_BM_H_
+
+/* BM Configuration Register */
+#define MVNETA_BM_CONFIG_REG			0x0
+#define    MVNETA_BM_STATUS_MASK		0x30
+#define    MVNETA_BM_ACTIVE_MASK		BIT(4)
+#define    MVNETA_BM_MAX_IN_BURST_SIZE_MASK	0x60000
+#define    MVNETA_BM_MAX_IN_BURST_SIZE_16BP	BIT(18)
+#define    MVNETA_BM_EMPTY_LIMIT_MASK		BIT(19)
+
+/* BM Activation Register */
+#define MVNETA_BM_COMMAND_REG			0x4
+#define    MVNETA_BM_START_MASK			BIT(0)
+#define    MVNETA_BM_STOP_MASK			BIT(1)
+#define    MVNETA_BM_PAUSE_MASK			BIT(2)
+
+/* BM Xbar interface Register */
+#define MVNETA_BM_XBAR_01_REG			0x8
+#define MVNETA_BM_XBAR_23_REG			0xc
+#define MVNETA_BM_XBAR_POOL_REG(pool)		\
+		(((pool) < 2) ? MVNETA_BM_XBAR_01_REG : MVNETA_BM_XBAR_23_REG)
+#define     MVNETA_BM_TARGET_ID_OFFS(pool)	(((pool) & 1) ? 16 : 0)
+#define     MVNETA_BM_TARGET_ID_MASK(pool)	\
+		(0xf << MVNETA_BM_TARGET_ID_OFFS(pool))
+#define     MVNETA_BM_TARGET_ID_VAL(pool, id)	\
+		((id) << MVNETA_BM_TARGET_ID_OFFS(pool))
+#define     MVNETA_BM_XBAR_ATTR_OFFS(pool)	(((pool) & 1) ? 20 : 4)
+#define     MVNETA_BM_XBAR_ATTR_MASK(pool)	\
+		(0xff << MVNETA_BM_XBAR_ATTR_OFFS(pool))
+#define     MVNETA_BM_XBAR_ATTR_VAL(pool, attr)	\
+		((attr) << MVNETA_BM_XBAR_ATTR_OFFS(pool))
+
+/* Address of External Buffer Pointers Pool Register */
+#define MVNETA_BM_POOL_BASE_REG(pool)		(0x10 + ((pool) << 4))
+#define     MVNETA_BM_POOL_ENABLE_MASK		BIT(0)
+
+/* External Buffer Pointers Pool RD pointer Register */
+#define MVNETA_BM_POOL_READ_PTR_REG(pool)	(0x14 + ((pool) << 4))
+#define     MVNETA_BM_POOL_SET_READ_PTR_MASK	0xfffc
+#define     MVNETA_BM_POOL_GET_READ_PTR_OFFS	16
+#define     MVNETA_BM_POOL_GET_READ_PTR_MASK	0xfffc0000
+
+/* External Buffer Pointers Pool WR pointer */
+#define MVNETA_BM_POOL_WRITE_PTR_REG(pool)	(0x18 + ((pool) << 4))
+#define     MVNETA_BM_POOL_SET_WRITE_PTR_OFFS	0
+#define     MVNETA_BM_POOL_SET_WRITE_PTR_MASK	0xfffc
+#define     MVNETA_BM_POOL_GET_WRITE_PTR_OFFS	16
+#define     MVNETA_BM_POOL_GET_WRITE_PTR_MASK	0xfffc0000
+
+/* External Buffer Pointers Pool Size Register */
+#define MVNETA_BM_POOL_SIZE_REG(pool)		(0x1c + ((pool) << 4))
+#define     MVNETA_BM_POOL_SIZE_MASK		0x3fff
+
+/* BM Interrupt Cause Register */
+#define MVNETA_BM_INTR_CAUSE_REG		(0x50)
+
+/* BM interrupt Mask Register */
+#define MVNETA_BM_INTR_MASK_REG			(0x54)
+
+/* Other definitions */
+#define MVNETA_BM_SHORT_PKT_SIZE		256
+#define MVNETA_BM_POOLS_NUM			4
+#define MVNETA_BM_POOL_CAP_MIN			128
+#define MVNETA_BM_POOL_CAP_DEF			2048
+#define MVNETA_BM_POOL_CAP_MAX			\
+		(16 * 1024 - MVNETA_BM_POOL_CAP_ALIGN)
+#define MVNETA_BM_POOL_CAP_ALIGN		32
+#define MVNETA_BM_POOL_PTR_ALIGN		32
+
+#define MVNETA_BM_POOL_ACCESS_OFFS		8
+
+#define MVNETA_BM_BPPI_SIZE			0x100000
+
+#define MVNETA_RX_BUF_SIZE(pkt_size)   ((pkt_size) + NET_SKB_PAD)
+
+enum mvneta_bm_type {
+	MVNETA_BM_FREE,
+	MVNETA_BM_LONG,
+	MVNETA_BM_SHORT
+};
+
+struct mvneta_bm {
+	void __iomem *reg_base;
+	struct clk *clk;
+	struct platform_device *pdev;
+
+	struct gen_pool *bppi_pool;
+	/* BPPI virtual base address */
+	void __iomem *bppi_virt_addr;
+	/* BPPI physical base address */
+	dma_addr_t bppi_phys_addr;
+
+	/* BM pools */
+	struct mvneta_bm_pool *bm_pools;
+};
+
+struct mvneta_bm_pool {
+	/* Pool number in the range 0-3 */
+	u8 id;
+	enum mvneta_bm_type type;
+
+	/* Buffer Pointers Pool External (BPPE) size in number of bytes */
+	int size;
+	/* Number of buffers used by this pool */
+	int buf_num;
+	/* Pool buffer size */
+	int buf_size;
+	/* Packet size */
+	int pkt_size;
+	/* Single frag size */
+	u32 frag_size;
+
+	/* BPPE virtual base address */
+	u32 *virt_addr;
+	/* BPPE physical base address */
+	dma_addr_t phys_addr;
+
+	/* Ports using BM pool */
+	u8 port_map;
+
+	struct mvneta_bm *priv;
+};
+
+/* Declarations and definitions */
+void *mvneta_frag_alloc(unsigned int frag_size);
+void mvneta_frag_free(unsigned int frag_size, void *data);
+void mvneta_bm_pool_destroy(struct mvneta_bm *priv,
+			    struct mvneta_bm_pool *bm_pool, u8 port_map);
+void mvneta_bm_bufs_free(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool,
+			 u8 port_map);
+int mvneta_bm_bufs_add(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool,
+		       int buf_num);
+int mvneta_bm_pool_refill(struct mvneta_bm *priv,
+			  struct mvneta_bm_pool *bm_pool);
+struct mvneta_bm_pool *mvneta_bm_pool_use(struct mvneta_bm *priv, u8 pool_id,
+					  enum mvneta_bm_type type, u8 port_id,
+					  int pkt_size);
+
+static inline void mvneta_bm_pool_put_bp(struct mvneta_bm *priv,
+					 struct mvneta_bm_pool *bm_pool,
+					 dma_addr_t buf_phys_addr)
+{
+	writel_relaxed(buf_phys_addr, priv->bppi_virt_addr +
+		       (bm_pool->id << MVNETA_BM_POOL_ACCESS_OFFS));
+}
+
+static inline u32 mvneta_bm_pool_get_bp(struct mvneta_bm *priv,
+					struct mvneta_bm_pool *bm_pool)
+{
+	return readl_relaxed(priv->bppi_virt_addr +
+			     (bm_pool->id << MVNETA_BM_POOL_ACCESS_OFFS));
+}
+
+#endif
-- 
2.5.0



From vladimir.murzin at arm.com  Tue Feb 16 07:37:31 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 15:37:31 +0000
Subject: [PATCH v3 09/10] ARM: dts: introduce MPS2 AN385/AN386
In-Reply-To: <CACRpkdafDhT=1uJssVNAW+g05eXbRC1xUL+O0+SxcpdczUX0vQ@mail.gmail.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>	<1455617295-23736-10-git-send-email-vladimir.murzin@arm.com>
 <CACRpkdafDhT=1uJssVNAW+g05eXbRC1xUL+O0+SxcpdczUX0vQ@mail.gmail.com>
Message-ID: <56C3423B.5070307@arm.com>

On 16/02/16 15:17, Linus Walleij wrote:
> On Tue, Feb 16, 2016 at 11:08 AM, Vladimir Murzin
> <vladimir.murzin at arm.com> wrote:
> 
>> Application Notes 385 and 386 shares the same memory map and features
>> except the CPU is used. AN385 is supplied with Cortex-M3 CPU and AN386
>> is supplied with Cortex-M4.
>>
>> Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
> (...)
>> +               fpgaio {
>> +                       compatible = "syscon", "simple-mfd";
>> +                       reg = <0x40028000 0x10>;
>> +
>> +                       led at 0 {
>> +                               compatible = "register-bit-led";
>> +                               offset = <0x0>;
>> +                               mask = <0x01>;
>> +                               label = "userled:0";
>> +                               linux,default-trigger = "heartbeat";
>> +                               default-state = "on";
>> +                       };
>> +
>> +                       led at 1 {
>> +                               compatible = "register-bit-led";
>> +                               offset = <0x0>;
>> +                               mask = <0x02>;
>> +                               label = "userled:1";
>> +                               linux,default-trigger = "usr";
>> +                               default-state = "off";
>> +                       };
>> +               };
> 
> Thanks for using this. I worked hard to massage this into the
> core.
> 

Thank you for pushing it, it cost me couple of minutes to make these
tiny leds alive :)

> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
> 

Cheers!

Vladimir

> Yours,
> Linus Walleij
> 
> 
> 



From arnd at arndb.de  Tue Feb 16 07:37:59 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 16:37:59 +0100
Subject: [PATCH v2 0/5] gpio: clean up irq_to_gpio and ARCH_NR_GPIOS
In-Reply-To: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
References: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
Message-ID: <1455637086-2794174-1-git-send-email-arnd@arndb.de>

I noticed that arch/arm/include/asm/gpio.h can almost be removed,
after we have already removed the file for most other architectures
now.

When I removed it, I ran into problems with irq_to_gpio(), which
we had already killed off in ARM, but it survived (barely) in the
global headers and accidentally gained an invalid user

This kills it off some more.

The first patch should go as a bugfix into the MIPS tree, the
other ones should only get merged later, but I think that's fine
if they get submitted for 4.6. I left them as a series of five
patches to clarify the build-time dependency. Merging patch
2 before 1 turns the MIPS runtime error into a compiletime
error.

changes in v2:

* the MIPS change should now correctly fix the bug, thanks
  to Lars-Peter.

* I left out the ARM specific change for now, and just adapted
  the generic file so we don't need that any more.

*  Fixed the bug that Russell pointed out

	Arnd



From arnd at arndb.de  Tue Feb 16 07:40:36 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 16:40:36 +0100
Subject: [PATCH v2 3/5] gpio: ks8695: remove irq_to_gpio function
In-Reply-To: <1455637261-2920972-1-git-send-email-arnd@arndb.de>
References: <455637086-2794174-1-git-send-email-arnd@arndb.de>
 <1455637261-2920972-1-git-send-email-arnd@arndb.de>
Message-ID: <1455637261-2920972-3-git-send-email-arnd@arndb.de>

The ks8695 gpio driver has its own copy of the irq_to_gpio()
function. This is completely unused in the mainline kernel
after we converted all remaining users several years ago,
so we can remove the definition as well.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/gpio/gpio-ks8695.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpio/gpio-ks8695.c b/drivers/gpio/gpio-ks8695.c
index 9f86ed9c753b..179723d02f55 100644
--- a/drivers/gpio/gpio-ks8695.c
+++ b/drivers/gpio/gpio-ks8695.c
@@ -205,18 +205,6 @@ static int ks8695_gpio_to_irq(struct gpio_chip *gc, unsigned int pin)
 	return gpio_irq[pin];
 }
 
-/*
- * Map IRQ number to GPIO line.
- */
-int irq_to_gpio(unsigned int irq)
-{
-	if ((irq < KS8695_IRQ_EXTERN0) || (irq > KS8695_IRQ_EXTERN3))
-		return -EINVAL;
-
-	return (irq - KS8695_IRQ_EXTERN0);
-}
-EXPORT_SYMBOL(irq_to_gpio);
-
 /* GPIOLIB interface */
 
 static struct gpio_chip ks8695_gpio_chip = {
-- 
2.7.0



From arnd at arndb.de  Tue Feb 16 07:40:35 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 16:40:35 +0100
Subject: [PATCH v2 2/5] gpio: remove broken irq_to_gpio() interface
In-Reply-To: <1455637261-2920972-1-git-send-email-arnd@arndb.de>
References: <455637086-2794174-1-git-send-email-arnd@arndb.de>
 <1455637261-2920972-1-git-send-email-arnd@arndb.de>
Message-ID: <1455637261-2920972-2-git-send-email-arnd@arndb.de>

gpiolib has removed the irq_to_gpio() API several years ago,
but the global header still provided a non-working stub.

To prevent new users of this broken function from showing
up, let's remove the stubs as well.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 include/linux/gpio.h | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/include/linux/gpio.h b/include/linux/gpio.h
index d12b5d566e4b..6fc1c9e74854 100644
--- a/include/linux/gpio.h
+++ b/include/linux/gpio.h
@@ -70,11 +70,6 @@ static inline int gpio_to_irq(unsigned int gpio)
 	return __gpio_to_irq(gpio);
 }
 
-static inline int irq_to_gpio(unsigned int irq)
-{
-	return -EINVAL;
-}
-
 #endif /* ! CONFIG_ARCH_HAVE_CUSTOM_GPIO_H */
 
 /* CONFIG_GPIOLIB: bindings for managed devices that want to request gpios */
@@ -222,13 +217,6 @@ static inline void gpiochip_unlock_as_irq(struct gpio_chip *chip,
 	WARN_ON(1);
 }
 
-static inline int irq_to_gpio(unsigned irq)
-{
-	/* irq can never have been returned from gpio_to_irq() */
-	WARN_ON(1);
-	return -EINVAL;
-}
-
 static inline int
 gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
 		       unsigned int gpio_offset, unsigned int pin_offset,
-- 
2.7.0



From arnd at arndb.de  Tue Feb 16 07:40:34 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 16:40:34 +0100
Subject: [PATCH v2 1/5] MIPS: jz4740: remove broken irq_to_gpio() call
In-Reply-To: <455637086-2794174-1-git-send-email-arnd@arndb.de>
References: <455637086-2794174-1-git-send-email-arnd@arndb.de>
Message-ID: <1455637261-2920972-1-git-send-email-arnd@arndb.de>

gpiolib has removed the irq_to_gpio() API several years ago,
but the global header still provided a non-working stub.

With a MIPS-wide change to use the generic header file, the jz4740
platform is now using the wrong stub implementation of irq_to_gpio(),
which cannot work.

This uses an open-coded implementation in the only line it
is used in.

Suggested-by: Lars-Peter Clausen <lars at metafoo.de>
Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Cc: <stable at vger.kernel.org> # v4.3+
Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h").
---
 arch/mips/jz4740/gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/jz4740/gpio.c b/arch/mips/jz4740/gpio.c
index 8c6d76c9b2d6..d9907e57e9b9 100644
--- a/arch/mips/jz4740/gpio.c
+++ b/arch/mips/jz4740/gpio.c
@@ -270,7 +270,7 @@ uint32_t jz_gpio_port_get_value(int port, uint32_t mask)
 }
 EXPORT_SYMBOL(jz_gpio_port_get_value);
 
-#define IRQ_TO_BIT(irq) BIT(irq_to_gpio(irq) & 0x1f)
+#define IRQ_TO_BIT(irq) BIT((irq - JZ4740_IRQ_GPIO(0)) & 0x1f)
 
 static void jz_gpio_check_trigger_both(struct jz_gpio_chip *chip, unsigned int irq)
 {
-- 
2.7.0



From arnd at arndb.de  Tue Feb 16 07:40:38 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 16:40:38 +0100
Subject: [PATCH v2 5/5] gpio: allow setting ARCH_NR_GPIOS from Kconfig
In-Reply-To: <1455637261-2920972-1-git-send-email-arnd@arndb.de>
References: <455637086-2794174-1-git-send-email-arnd@arndb.de>
 <1455637261-2920972-1-git-send-email-arnd@arndb.de>
Message-ID: <1455637261-2920972-5-git-send-email-arnd@arndb.de>

The ARM version of asm/gpio.h basically just contains the same definitions
as the gpiolib version, with the exception of ARCH_NR_GPIOS.

This adds the option for overriding the constant through Kconfig to
the architecture-independent header, so we can remove the ARM specific
file later.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 include/asm-generic/gpio.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 40ec1433f05d..8ca627dcea11 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -26,8 +26,12 @@
  */
 
 #ifndef ARCH_NR_GPIOS
+#if defined(CONFIG_ARCH_NR_GPIO) && CONFIG_ARCH_NR_GPIO > 0
+#define ARCH_NR_GPIOS CONFIG_ARCH_NR_GPIO
+#else
 #define ARCH_NR_GPIOS		512
 #endif
+#endif
 
 /*
  * "valid" GPIO numbers are nonnegative and may be passed to
-- 
2.7.0



From arnd at arndb.de  Tue Feb 16 07:40:37 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 16:40:37 +0100
Subject: [PATCH v2 4/5] gpio: ep93xx: remove private irq_to_gpio function
In-Reply-To: <1455637261-2920972-1-git-send-email-arnd@arndb.de>
References: <455637086-2794174-1-git-send-email-arnd@arndb.de>
 <1455637261-2920972-1-git-send-email-arnd@arndb.de>
Message-ID: <1455637261-2920972-4-git-send-email-arnd@arndb.de>

The ep93xx goes through its own back-and-forth dance every time
it wants to know the gpio number for an irq line, when it really
just hardcodes a fixed offset in ep93xx_gpio_to_irq().

This removes the pointless macro and replaces the conversion inside
of the driver with simple add/subtract operations, using an
explicit macro.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/gpio/gpio-ep93xx.c | 37 +++++++++++++++++--------------------
 1 file changed, 17 insertions(+), 20 deletions(-)

diff --git a/drivers/gpio/gpio-ep93xx.c b/drivers/gpio/gpio-ep93xx.c
index 20e5846bda28..cd83d30e8ff7 100644
--- a/drivers/gpio/gpio-ep93xx.c
+++ b/drivers/gpio/gpio-ep93xx.c
@@ -18,12 +18,8 @@
 #include <linux/io.h>
 #include <linux/irq.h>
 #include <linux/slab.h>
-#include <linux/gpio/driver.h>
-/* FIXME: this is here for gpio_to_irq() - get rid of this! */
 #include <linux/gpio.h>
 
-#define irq_to_gpio(irq)	((irq) - gpio_to_irq(0))
-
 void __iomem *ep93xx_gpio_base; /* FIXME: put this into irq_data */
 
 #define EP93XX_GPIO_REG(x)		(ep93xx_gpio_base + (x))
@@ -35,6 +31,7 @@ void __iomem *ep93xx_gpio_base; /* FIXME: put this into irq_data */
 #define EP93XX_GPIO_LINE_MAX		63
 
 /* maximum value for irq capable line identifiers */
+#define EP93XX_GPIO_IRQ_BASE		64
 #define EP93XX_GPIO_LINE_MAX_IRQ	23
 
 
@@ -77,7 +74,7 @@ static void ep93xx_gpio_update_int_params(unsigned port)
 
 static void ep93xx_gpio_int_debounce(unsigned int irq, bool enable)
 {
-	int line = irq_to_gpio(irq);
+	int line = irq - EP93XX_GPIO_IRQ_BASE;
 	int port = line >> 3;
 	int port_mask = 1 << (line & 7);
 
@@ -98,7 +95,7 @@ static void ep93xx_gpio_ab_irq_handler(struct irq_desc *desc)
 	status = readb(EP93XX_GPIO_A_INT_STATUS);
 	for (i = 0; i < 8; i++) {
 		if (status & (1 << i)) {
-			int gpio_irq = gpio_to_irq(0) + i;
+			int gpio_irq = EP93XX_GPIO_IRQ_BASE + i;
 			generic_handle_irq(gpio_irq);
 		}
 	}
@@ -106,7 +103,7 @@ static void ep93xx_gpio_ab_irq_handler(struct irq_desc *desc)
 	status = readb(EP93XX_GPIO_B_INT_STATUS);
 	for (i = 0; i < 8; i++) {
 		if (status & (1 << i)) {
-			int gpio_irq = gpio_to_irq(8) + i;
+			int gpio_irq = EP93XX_GPIO_IRQ_BASE + 8 + i;
 			generic_handle_irq(gpio_irq);
 		}
 	}
@@ -121,14 +118,14 @@ static void ep93xx_gpio_f_irq_handler(struct irq_desc *desc)
 	 */
 	unsigned int irq = irq_desc_get_irq(desc);
 	int port_f_idx = ((irq + 1) & 7) ^ 4; /* {19..22,47..50} -> {0..7} */
-	int gpio_irq = gpio_to_irq(16) + port_f_idx;
+	int gpio_irq = EP93XX_GPIO_IRQ_BASE + 16 + port_f_idx;
 
 	generic_handle_irq(gpio_irq);
 }
 
 static void ep93xx_gpio_irq_ack(struct irq_data *d)
 {
-	int line = irq_to_gpio(d->irq);
+	int line = d->irq - EP93XX_GPIO_IRQ_BASE;
 	int port = line >> 3;
 	int port_mask = 1 << (line & 7);
 
@@ -142,7 +139,7 @@ static void ep93xx_gpio_irq_ack(struct irq_data *d)
 
 static void ep93xx_gpio_irq_mask_ack(struct irq_data *d)
 {
-	int line = irq_to_gpio(d->irq);
+	int line = d->irq - EP93XX_GPIO_IRQ_BASE;
 	int port = line >> 3;
 	int port_mask = 1 << (line & 7);
 
@@ -157,7 +154,7 @@ static void ep93xx_gpio_irq_mask_ack(struct irq_data *d)
 
 static void ep93xx_gpio_irq_mask(struct irq_data *d)
 {
-	int line = irq_to_gpio(d->irq);
+	int line = d->irq - EP93XX_GPIO_IRQ_BASE;
 	int port = line >> 3;
 
 	gpio_int_unmasked[port] &= ~(1 << (line & 7));
@@ -166,7 +163,7 @@ static void ep93xx_gpio_irq_mask(struct irq_data *d)
 
 static void ep93xx_gpio_irq_unmask(struct irq_data *d)
 {
-	int line = irq_to_gpio(d->irq);
+	int line = d->irq - EP93XX_GPIO_IRQ_BASE;
 	int port = line >> 3;
 
 	gpio_int_unmasked[port] |= 1 << (line & 7);
@@ -180,7 +177,7 @@ static void ep93xx_gpio_irq_unmask(struct irq_data *d)
  */
 static int ep93xx_gpio_irq_type(struct irq_data *d, unsigned int type)
 {
-	const int gpio = irq_to_gpio(d->irq);
+	const int gpio = d->irq - EP93XX_GPIO_IRQ_BASE;
 	const int port = gpio >> 3;
 	const int port_mask = 1 << (gpio & 7);
 	irq_flow_handler_t handler;
@@ -241,14 +238,14 @@ static struct irq_chip ep93xx_gpio_irq_chip = {
 
 static void ep93xx_gpio_init_irq(struct platform_device *pdev)
 {
-	int gpio_irq;
+	int gpio;
 	int i;
 
-	for (gpio_irq = gpio_to_irq(0);
-	     gpio_irq <= gpio_to_irq(EP93XX_GPIO_LINE_MAX_IRQ); ++gpio_irq) {
-		irq_set_chip_and_handler(gpio_irq, &ep93xx_gpio_irq_chip,
+	for (gpio = 0; gpio <= EP93XX_GPIO_LINE_MAX_IRQ; ++gpio) {
+		irq_set_chip_and_handler(EP93XX_GPIO_IRQ_BASE + gpio,
+					 &ep93xx_gpio_irq_chip,
 					 handle_level_irq);
-		irq_clear_status_flags(gpio_irq, IRQ_NOREQUEST);
+		irq_clear_status_flags(EP93XX_GPIO_IRQ_BASE + gpio, IRQ_NOREQUEST);
 	}
 
 	irq_set_chained_handler(platform_get_irq(pdev, 0),
@@ -294,7 +291,7 @@ static int ep93xx_gpio_set_debounce(struct gpio_chip *chip,
 				    unsigned offset, unsigned debounce)
 {
 	int gpio = chip->base + offset;
-	int irq = gpio_to_irq(gpio);
+	int irq = EP93XX_GPIO_IRQ_BASE + gpio;
 
 	if (irq < 0)
 		return -EINVAL;
@@ -316,7 +313,7 @@ static int ep93xx_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
 	if (gpio > EP93XX_GPIO_LINE_MAX_IRQ)
 		return -EINVAL;
 
-	return 64 + gpio;
+	return EP93XX_GPIO_IRQ_BASE + gpio;
 }
 
 static int ep93xx_gpio_add_bank(struct gpio_chip *gc, struct device *dev,
-- 
2.7.0



From linus.walleij at linaro.org  Tue Feb 16 07:42:18 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 16 Feb 2016 16:42:18 +0100
Subject: [PATCH 1/4] gpio: remove broken irq_to_gpio() interface
In-Reply-To: <1455551208-2825510-2-git-send-email-arnd@arndb.de>
References: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <1455551208-2825510-1-git-send-email-arnd@arndb.de>
 <1455551208-2825510-2-git-send-email-arnd@arndb.de>
Message-ID: <CACRpkdaQN9_qoTn4_riZGvi4BKRLEVkRRL4CWzKj8e_di7Q2Xg@mail.gmail.com>

On Mon, Feb 15, 2016 at 4:46 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> gpiolib has removed the irq_to_gpio() API several years ago,
> but the global header still provided a non-working stub.
>
> Apparently one new user has shown up in arch/mips, so this patch
> moves the broken definition to where it is used, ensuring that
> we get new users but not changing the current behavior on jz4740.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Patch applied.

I expect the driver maintainer to deal with the resulting
deprecation fallout.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Tue Feb 16 07:43:22 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 16 Feb 2016 16:43:22 +0100
Subject: [PATCH 2/4] gpio: ks8695: remove irq_to_gpio function
In-Reply-To: <1455551208-2825510-3-git-send-email-arnd@arndb.de>
References: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <1455551208-2825510-1-git-send-email-arnd@arndb.de>
 <1455551208-2825510-3-git-send-email-arnd@arndb.de>
Message-ID: <CACRpkdZ0uFKKieDjEvdhsT+QVUBq2YYa64nqbh5rhFnChD9jGQ@mail.gmail.com>

On Mon, Feb 15, 2016 at 4:46 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> The ks8695 gpio driver has its own copy of the irq_to_gpio()
> function. This is completely unused in the mainline kernel
> after we converted all remaining users several years ago,
> so we can remove the definition as well.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Patch applied.

Yours,
Linus Walleij


From arnd at arndb.de  Tue Feb 16 07:45:28 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 16:45:28 +0100
Subject: [PATCH 1/4] gpio: remove broken irq_to_gpio() interface
In-Reply-To: <CACRpkdaQN9_qoTn4_riZGvi4BKRLEVkRRL4CWzKj8e_di7Q2Xg@mail.gmail.com>
References: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <1455551208-2825510-2-git-send-email-arnd@arndb.de>
 <CACRpkdaQN9_qoTn4_riZGvi4BKRLEVkRRL4CWzKj8e_di7Q2Xg@mail.gmail.com>
Message-ID: <2646870.5L1En4yxph@wuerfel>

On Tuesday 16 February 2016 16:42:18 Linus Walleij wrote:
> On Mon, Feb 15, 2016 at 4:46 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> 
> > gpiolib has removed the irq_to_gpio() API several years ago,
> > but the global header still provided a non-working stub.
> >
> > Apparently one new user has shown up in arch/mips, so this patch
> > moves the broken definition to where it is used, ensuring that
> > we get new users but not changing the current behavior on jz4740.
> >
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> 
> Patch applied.
> 
> I expect the driver maintainer to deal with the resulting
> deprecation fallout.
> 

I've just sent v2 of the series, with a separate patch for MIPS
that now conflicts with this one. Can you pick up the new patch
instead?

	Arnd


From lars at metafoo.de  Tue Feb 16 07:47:37 2016
From: lars at metafoo.de (Lars-Peter Clausen)
Date: Tue, 16 Feb 2016 16:47:37 +0100
Subject: [PATCH v2 1/5] MIPS: jz4740: remove broken irq_to_gpio() call
In-Reply-To: <1455637261-2920972-1-git-send-email-arnd@arndb.de>
References: <455637086-2794174-1-git-send-email-arnd@arndb.de>
 <1455637261-2920972-1-git-send-email-arnd@arndb.de>
Message-ID: <56C34499.5010704@metafoo.de>

On 02/16/2016 04:40 PM, Arnd Bergmann wrote:
> gpiolib has removed the irq_to_gpio() API several years ago,
> but the global header still provided a non-working stub.
> 
> With a MIPS-wide change to use the generic header file, the jz4740
> platform is now using the wrong stub implementation of irq_to_gpio(),
> which cannot work.
> 
> This uses an open-coded implementation in the only line it
> is used in.
> 
> Suggested-by: Lars-Peter Clausen <lars at metafoo.de>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: <stable at vger.kernel.org> # v4.3+
> Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h").

Acked-by: Lars-Peter Clausen <lars at metafoo.de>

Thanks.

> ---
>  arch/mips/jz4740/gpio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/mips/jz4740/gpio.c b/arch/mips/jz4740/gpio.c
> index 8c6d76c9b2d6..d9907e57e9b9 100644
> --- a/arch/mips/jz4740/gpio.c
> +++ b/arch/mips/jz4740/gpio.c
> @@ -270,7 +270,7 @@ uint32_t jz_gpio_port_get_value(int port, uint32_t mask)
>  }
>  EXPORT_SYMBOL(jz_gpio_port_get_value);
>  
> -#define IRQ_TO_BIT(irq) BIT(irq_to_gpio(irq) & 0x1f)
> +#define IRQ_TO_BIT(irq) BIT((irq - JZ4740_IRQ_GPIO(0)) & 0x1f)
>  
>  static void jz_gpio_check_trigger_both(struct jz_gpio_chip *chip, unsigned int irq)
>  {
> 



From aryabinin at virtuozzo.com  Tue Feb 16 07:36:36 2016
From: aryabinin at virtuozzo.com (Andrey Ryabinin)
Date: Tue, 16 Feb 2016 18:36:36 +0300
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <CAKv+Gu8WE=fTZF0Pou24FKDocgshWu8dJRbaC5SJ11E-6T=2Hw@mail.gmail.com>
References: <1454324093-15998-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454324093-15998-8-git-send-email-ard.biesheuvel@linaro.org>
 <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com>
 <CAKv+Gu8WE=fTZF0Pou24FKDocgshWu8dJRbaC5SJ11E-6T=2Hw@mail.gmail.com>
Message-ID: <56C34204.60605@virtuozzo.com>



On 02/16/2016 06:17 PM, Ard Biesheuvel wrote:
> On 16 February 2016 at 13:59, Andrey Ryabinin <aryabinin at virtuozzo.com> wrote:
>>
>>
>> On 02/15/2016 09:59 PM, Catalin Marinas wrote:
>>> On Mon, Feb 15, 2016 at 05:28:02PM +0300, Andrey Ryabinin wrote:
>>>> On 02/12/2016 07:06 PM, Catalin Marinas wrote:
>>>>> So far, we have:
>>>>>
>>>>> KASAN+for-next/kernmap goes wrong
>>>>> KASAN+UBSAN goes wrong
>>>>>
>>>>> Enabled individually, KASAN, UBSAN and for-next/kernmap seem fine. I may
>>>>> have to trim for-next/core down until we figure out where the problem
>>>>> is.
>>>>>
>>>>> BUG: KASAN: stack-out-of-bounds in find_busiest_group+0x164/0x16a0 at addr ffffffc93665bc8c
>>>>
>>>> Can it be related to TLB conflicts, which supposed to be fixed in
>>>> "arm64: kasan: avoid TLB conflicts" patch from "arm64: mm: rework page
>>>> table creation" series ?
>>>
>>> I can very easily reproduce this with a vanilla 4.5-rc1 series by
>>> enabling inline instrumentation (maybe Mark's theory is true w.r.t.
>>> image size).
>>>
>>> Some information, maybe you can shed some light on this. It seems to
>>> happen only for secondary CPUs on the swapper stack (I think allocated
>>> via fork_idle()). The code generated looks sane to me, so KASAN should
>>> not complain but maybe there is some uninitialised shadow, hence the
>>> error.
>>>
>>> The report:
>>>
>>
>> Actually, the first report is a bit more useful. It shows that shadow memory was corrupted:
>>
>>   ffffffc93665bc00: f1 f1 f1 f1 00 f4 f4 f4 f2 f2 f2 f2 00 00 f1 f1
>>> ffffffc93665bc80: f1 f1 00 00 00 00 f3 f3 00 f4 f4 f4 f3 f3 f3 f3
>>                       ^
>> F1 - left redzone, it indicates start of stack frame
>> F3 - right redzone, it should be the end of stack frame.
>>
>> But here we have the second set of F1s without F3s which should close the first set of F1s.
>> Also those two F3s in the middle cannot be right.
>>
>> So shadow is corrupted.
>> Some hypotheses:
>>
>> 1) We share stack between several tasks (e.g. stack overflow, somehow corrupted SP).
>>     But this probably should cause kernel crash later, after kasan reports.
>>
>> 2) Shadow memory wasn't cleared. GCC poison memory on function entrance and unpoisons it before return.
>>      If we use some tricky way to exit from function this could cause false-positives like that.
>>      E.g. some hand-written assembly return code.
>>
>> 3) Screwed shadow mapping. I think the patch below should uncover such problem.
>> It boot-tested on qemu and didn't show any problem
>>
> 
> I think this patch gives false positive warnings in some cases:
> 
>>
>> ---
>>  arch/arm64/mm/kasan_init.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 55 insertions(+)
>>
>> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
>> index cf038c7..25d685c 100644
>> --- a/arch/arm64/mm/kasan_init.c
>> +++ b/arch/arm64/mm/kasan_init.c
>> @@ -117,6 +117,59 @@ static void __init cpu_set_ttbr1(unsigned long ttbr1)
>>         : "r" (ttbr1));
>>  }
>>
>> +static void verify_shadow(void)
>> +{
>> +       struct memblock_region *reg;
>> +       int i = 0;
>> +
>> +       for_each_memblock(memory, reg) {
>> +               void *start = (void *)__phys_to_virt(reg->base);
>> +               void *end = (void *)__phys_to_virt(reg->base + reg->size);
>> +               int *shadow_start, *shadow_end;
>> +
>> +               if (start >= end)
>> +                       break;
>> +               shadow_start = (int *)((unsigned long)kasan_mem_to_shadow(start) & ~(PAGE_SIZE - 1));
>> +               shadow_end =  (int *)kasan_mem_to_shadow(end);
> 
> shadow_start and shadow_end can refer to the same page as in the
> previous iteration. For instance, I have these two regions
> 
>   0x00006e090000-0x00006e0adfff [Conventional Memory|   |  |  |  |  |
> |   |WB|WT|WC|UC]
>   0x00006e0ae000-0x00006e0affff [Loader Data        |   |  |  |  |  |
> |   |WB|WT|WC|UC]
> 
> which are covered by different memblocks since the second one is
> marked as MEMBLOCK_NOMAP, due to the fact that it contains the UEFI
> memory map.
> 
> I get the following output
> 
> kasan: screwed shadow mapping 23575, 23573
> 
> which I think is simply a result from the fact the shadow_start refers
> to the same page as in the previous iteration(s)
> 

You are right. 
So we should write 'shadow_start' instead of 'i'.

---
 arch/arm64/mm/kasan_init.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index cf038c7..ee035c2 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -117,6 +117,55 @@ static void __init cpu_set_ttbr1(unsigned long ttbr1)
 	: "r" (ttbr1));
 }
 
+static void verify_shadow(void)
+{
+	struct memblock_region *reg;
+
+	for_each_memblock(memory, reg) {
+		void *start = (void *)__phys_to_virt(reg->base);
+		void *end = (void *)__phys_to_virt(reg->base + reg->size);
+		unsigned long *shadow_start, *shadow_end;
+
+		if (start >= end)
+			break;
+		shadow_start = (unsigned long *)kasan_mem_to_shadow(start);
+		shadow_end =  (unsigned long *)kasan_mem_to_shadow(end);
+		for (; shadow_start < shadow_end; shadow_start += PAGE_SIZE/sizeof(unsigned long)) {
+			*shadow_start = (unsigned long)shadow_start;
+		}
+	}
+
+	for_each_memblock(memory, reg) {
+		void *start = (void *)__phys_to_virt(reg->base);
+		void *end = (void *)__phys_to_virt(reg->base + reg->size);
+		unsigned long *shadow_start, *shadow_end;
+
+		if (start >= end)
+			break;
+		shadow_start = (unsigned long *)kasan_mem_to_shadow(start);
+		shadow_end =  (unsigned long *)kasan_mem_to_shadow(end);
+		for (; shadow_start < shadow_end; shadow_start += PAGE_SIZE/sizeof(unsigned long)) {
+			if (*shadow_start != (unsigned long)shadow_start) {
+				pr_err("screwed shadow mapping %lx, %lx\n", *shadow_start, (unsigned long)shadow_start);
+				goto clear;
+			}
+		}
+	}
+clear:
+	for_each_memblock(memory, reg) {
+		void *start = (void *)__phys_to_virt(reg->base);
+		void *end = (void *)__phys_to_virt(reg->base + reg->size);
+		unsigned long shadow_start, shadow_end;
+
+		if (start >= end)
+			break;
+		shadow_start =  (unsigned long)kasan_mem_to_shadow(start);
+		shadow_end =  (unsigned long)kasan_mem_to_shadow(end);
+		memset((void *)shadow_start, 0, shadow_end - shadow_start);
+	}
+
+}
+
 void __init kasan_init(void)
 {
 	struct memblock_region *reg;
@@ -159,6 +208,8 @@ void __init kasan_init(void)
 	cpu_set_ttbr1(__pa(swapper_pg_dir));
 	flush_tlb_all();
 
+	verify_shadow();
+
 	/* At this point kasan is fully initialized. Enable error messages */
 	init_task.kasan_depth = 0;
 	pr_info("KernelAddressSanitizer initialized\n");
-- 




From linus.walleij at linaro.org  Tue Feb 16 07:35:07 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 16 Feb 2016 16:35:07 +0100
Subject: [PATCH] pinctrl: sunxi: set pin function as input on export
In-Reply-To: <20160216080004.GA24625@box2.japko.eu>
References: <1454942242-25690-1-git-send-email-krzysztof.adamski@tieto.com>
 <CACRpkdbd4f3yj2MnR6PU5SuhV5Tj4HzWLc0UX8jQkcJp7MoTig@mail.gmail.com>
 <20160216080004.GA24625@box2.japko.eu>
Message-ID: <CACRpkdZuNM5GAh5wWpJmAxkX_XVos5j1kd6aZCfgpQJ7zGug7w@mail.gmail.com>

On Tue, Feb 16, 2016 at 9:00 AM, Krzysztof Adamski
<krzysztof.adamski at tieto.com> wrote:

> While sysfs API may be very limited it does have it's strengths too. One of
> them is that it's trivially scriptable even from bash or other scripting
> languages

Feel free to contribute a tool to tools/gpio that perform what you
need from scripts, using a chardev.

But overall it is subject to the same issue as always: we open
a chardev and hold it to keep references to it even if the hardware
goes away. Scripting doesn't seem supergood at opening chardevs
and holding them and are thus inherently fragile.

With a chardev we can handle that gracefully.

As it is right now, files in sysfs can just disappear while your script
is running (if e.g. the GPIO is on a USB device or so) and then all
hell breaks loose I think. So it is very fragile.

> and the other one is that it's there for so long that it's very
> popular and it will take much time before all the tutorials and existing
> applications are updated. So, well, I still find it useful to have good
> support for it.

See commit fe95046e960b4b76e73dc1486955d93f47276134
it is deprecated but will be around until (at least) 2020.

The chardev will be promoted as it is *always* available, whereas
the sysfs has a Kconfig option you must switch on.

> I find current behaviour of sysfs interface broken (it says that GPIO is in
> input mode when in reality it isn't) and still think it's a good idea to fix
> it. But putting sysfs issue aside, wouldn't it be safer to set some well
> known state of the pin when requesting it instead of leaving it at whatever
> was set before?

We have this for in-kernel consumers (<linux/gpio/consumer.h>):

/**
 * Optional flags that can be passed to one of gpiod_* to configure direction
 * and output value. These values cannot be OR'd.
 */
enum gpiod_flags {
        GPIOD_ASIS      = 0,
        GPIOD_IN        = GPIOD_FLAGS_BIT_DIR_SET,
        GPIOD_OUT_LOW   = GPIOD_FLAGS_BIT_DIR_SET | GPIOD_FLAGS_BIT_DIR_OUT,
        GPIOD_OUT_HIGH  = GPIOD_FLAGS_BIT_DIR_SET | GPIOD_FLAGS_BIT_DIR_OUT |
                          GPIOD_FLAGS_BIT_DIR_VAL,
};

We have not yet specified a proper ABI for usespace. Are these
flags the same as you would want for userspace?

My feeling is that unless specified ASIS is what you want.

Especially if there is also an ABI to read the line value.

Let's get the chardev right in this regard and use that.

> The same question goes for freeing, actually, shouldn't the
> pin be disabled when we call gpio_free instead of leaving it at its last
> state?

Well maybe we should have an ABI specifying what state we
want it to be left in, if e.g. the userspace application either quit
without saying anything, or more importantly, if it crashes.

With the chardev we can do that.

> There are existing drivers that set gpio direction to input when requesting
> the pin (for example pinctrl-plgpio.c, pinctrl-sirf.c) so sunxi wouldn't be
> the only driver to do this. This does also show that indeed the problem is
> not sunxi specific, though.

Drivers can do pretty much what they want, they are supposed
to handle the hardware as well as they can. They might be doing this
for a reason or not, better ask the driver writers and/or send them
patches to augment the behaviour.

Yours,
Linus Walleij


From gregory.clement at free-electrons.com  Tue Feb 16 07:33:38 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 16:33:38 +0100
Subject: [PATCH v2 3/8] ARM: dts: armada-xp: add buffer manager nodes
In-Reply-To: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455636823-14470-4-git-send-email-gregory.clement@free-electrons.com>

From: Marcin Wojtas <mw at semihalf.com>

Armada XP network controller supports hardware buffer management (BM).
Since it is now enabled in mvneta driver, appropriate nodes can be added
to armada-xp.dtsi - for the actual common BM unit (bm at c0000) and its
internal SRAM (bm-bppi), which is used for indirect access to buffer
pointer ring residing in DRAM.

Pools - ports mapping, bm-bppi entry in 'soc' node's ranges and optional
parameters are supposed to be set in board files.

Signed-off-by: Marcin Wojtas <mw at semihalf.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/boot/dts/armada-xp.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index be23196829bb..bd459360d7a6 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -253,6 +253,14 @@
 				marvell,crypto-sram-size = <0x800>;
 			};
 
+			bm: bm at c0000 {
+				compatible = "marvell,armada-380-neta-bm";
+				reg = <0xc0000 0xac>;
+				clocks = <&gateclk 13>;
+				internal-mem = <&bm_bppi>;
+				status = "disabled";
+			};
+
 			xor at f0900 {
 				compatible = "marvell,orion-xor";
 				reg = <0xF0900 0x100
@@ -291,6 +299,16 @@
 			#size-cells = <1>;
 			ranges = <0 MBUS_ID(0x09, 0x05) 0 0x800>;
 		};
+
+		bm_bppi: bm-bppi {
+			compatible = "mmio-sram";
+			reg = <MBUS_ID(0x0c, 0x04) 0 0x100000>;
+			ranges = <0 MBUS_ID(0x0c, 0x04) 0 0x100000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			clocks = <&gateclk 13>;
+			status = "disabled";
+		};
 	};
 
 	clocks {
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 07:33:43 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 16:33:43 +0100
Subject: [PATCH v2 net-next 8/8] net: mvneta: Use the new hwbm framework
In-Reply-To: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455636823-14470-9-git-send-email-gregory.clement@free-electrons.com>

Now that the hardware buffer management framework had been introduced,
let's use it.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/net/ethernet/marvell/Kconfig     |   1 +
 drivers/net/ethernet/marvell/mvneta.c    |  45 +++++++---
 drivers/net/ethernet/marvell/mvneta_bm.c | 140 +++++++------------------------
 drivers/net/ethernet/marvell/mvneta_bm.h |  11 +--
 4 files changed, 69 insertions(+), 128 deletions(-)

diff --git a/drivers/net/ethernet/marvell/Kconfig b/drivers/net/ethernet/marvell/Kconfig
index 6c8dc6d62572..3ae9450c7f1c 100644
--- a/drivers/net/ethernet/marvell/Kconfig
+++ b/drivers/net/ethernet/marvell/Kconfig
@@ -43,6 +43,7 @@ config MVMDIO
 config MVNETA_BM
 	tristate "Marvell Armada 38x/XP network interface BM support"
 	depends on MVNETA
+	select HWBM
 	---help---
 	  This driver supports auxiliary block of the network
 	  interface units in the Marvell ARMADA XP and ARMADA 38x SoC
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 1db70565ce8b..981d786b270e 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -30,6 +30,7 @@
 #include <linux/phy.h>
 #include <linux/platform_device.h>
 #include <linux/skbuff.h>
+#include <net/hwbm.h>
 #include "mvneta_bm.h"
 #include <net/ip.h>
 #include <net/ipv6.h>
@@ -1018,11 +1019,12 @@ static int mvneta_bm_port_init(struct platform_device *pdev,
 static void mvneta_bm_update_mtu(struct mvneta_port *pp, int mtu)
 {
 	struct mvneta_bm_pool *bm_pool = pp->pool_long;
+	struct hwbm_pool *hwbm_pool = &bm_pool->hwbm_pool;
 	int num;
 
 	/* Release all buffers from long pool */
 	mvneta_bm_bufs_free(pp->bm_priv, bm_pool, 1 << pp->id);
-	if (bm_pool->buf_num) {
+	if (hwbm_pool->buf_num) {
 		WARN(1, "cannot free all buffers in pool %d\n",
 		     bm_pool->id);
 		goto bm_mtu_err;
@@ -1030,14 +1032,14 @@ static void mvneta_bm_update_mtu(struct mvneta_port *pp, int mtu)
 
 	bm_pool->pkt_size = MVNETA_RX_PKT_SIZE(mtu);
 	bm_pool->buf_size = MVNETA_RX_BUF_SIZE(bm_pool->pkt_size);
-	bm_pool->frag_size = SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) +
+	hwbm_pool->size = SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) +
 			  SKB_DATA_ALIGN(MVNETA_RX_BUF_SIZE(bm_pool->pkt_size));
 
 	/* Fill entire long pool */
-	num = mvneta_bm_bufs_add(pp->bm_priv, bm_pool, bm_pool->size);
-	if (num != bm_pool->size) {
+	num = hwbm_pool_add(hwbm_pool, hwbm_pool->size, GFP_ATOMIC);
+	if (num != hwbm_pool->size) {
 		WARN(1, "pool %d: %d of %d allocated\n",
-		     bm_pool->id, num, bm_pool->size);
+		     bm_pool->id, num, hwbm_pool->size);
 		goto bm_mtu_err;
 	}
 	mvneta_bm_pool_bufsize_set(pp, bm_pool->buf_size, bm_pool->id);
@@ -1717,6 +1719,14 @@ static void mvneta_txq_done(struct mvneta_port *pp,
 	}
 }
 
+void *mvneta_frag_alloc(unsigned int frag_size)
+{
+	if (likely(frag_size <= PAGE_SIZE))
+		return netdev_alloc_frag(frag_size);
+	else
+		return kmalloc(frag_size, GFP_ATOMIC);
+}
+
 /* Refill processing for SW buffer management */
 static int mvneta_rx_refill(struct mvneta_port *pp,
 			    struct mvneta_rx_desc *rx_desc)
@@ -1772,6 +1782,14 @@ static u32 mvneta_skb_tx_csum(struct mvneta_port *pp, struct sk_buff *skb)
 	return MVNETA_TX_L4_CSUM_NOT;
 }
 
+void mvneta_frag_free(unsigned int frag_size, void *data)
+{
+	if (likely(frag_size <= PAGE_SIZE))
+		skb_free_frag(data);
+	else
+		kfree(data);
+}
+
 /* Drop packets received by the RXQ and free buffers */
 static void mvneta_rxq_drop_pkts(struct mvneta_port *pp,
 				 struct mvneta_rx_queue *rxq)
@@ -1892,7 +1910,8 @@ err_drop_frame:
 		}
 
 		/* Refill processing */
-		err = bm_in_use ? mvneta_bm_pool_refill(pp->bm_priv, bm_pool) :
+		err = bm_in_use ? hwbm_pool_refill(&bm_pool->hwbm_pool,
+						   GFP_ATOMIC) :
 				  mvneta_rx_refill(pp, rx_desc);
 		if (err) {
 			netdev_err(dev, "Linux processing - Can't refill\n");
@@ -1900,7 +1919,8 @@ err_drop_frame:
 			goto err_drop_frame_ret_pool;
 		}
 
-		frag_size = bm_in_use ? bm_pool->frag_size : pp->frag_size;
+		frag_size = bm_in_use ? bm_pool->hwbm_pool.size :
+					pp->frag_size;
 
 		skb = build_skb(data, frag_size > PAGE_SIZE ? 0 : frag_size);
 
@@ -3963,11 +3983,6 @@ static int mvneta_probe(struct platform_device *pdev)
 	dev->priv_flags |= IFF_UNICAST_FLT;
 	dev->gso_max_segs = MVNETA_MAX_TSO_SEGS;
 
-	err = register_netdev(dev);
-	if (err < 0) {
-		dev_err(&pdev->dev, "failed to register\n");
-		goto err_free_stats;
-	}
 
 	pp->id = dev->ifindex;
 
@@ -3982,6 +3997,12 @@ static int mvneta_probe(struct platform_device *pdev)
 		}
 	}
 
+	err = register_netdev(dev);
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to register\n");
+		goto err_free_stats;
+	}
+
 	err = mvneta_init(&pdev->dev, pp);
 	if (err < 0)
 		goto err_netdev;
diff --git a/drivers/net/ethernet/marvell/mvneta_bm.c b/drivers/net/ethernet/marvell/mvneta_bm.c
index ff7e73c6d31c..55e8ad4c73f4 100644
--- a/drivers/net/ethernet/marvell/mvneta_bm.c
+++ b/drivers/net/ethernet/marvell/mvneta_bm.c
@@ -10,16 +10,17 @@
  * warranty of any kind, whether express or implied.
  */
 
-#include <linux/kernel.h>
+#include <linux/clk.h>
 #include <linux/genalloc.h>
-#include <linux/platform_device.h>
-#include <linux/netdevice.h>
-#include <linux/skbuff.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
 #include <linux/mbus.h>
 #include <linux/module.h>
-#include <linux/io.h>
+#include <linux/netdevice.h>
 #include <linux/of.h>
-#include <linux/clk.h>
+#include <linux/platform_device.h>
+#include <linux/skbuff.h>
+#include <net/hwbm.h>
 #include "mvneta_bm.h"
 
 #define MVNETA_BM_DRIVER_NAME "mvneta_bm"
@@ -88,35 +89,13 @@ static void mvneta_bm_pool_target_set(struct mvneta_bm *priv, int pool_id,
 	mvneta_bm_write(priv, MVNETA_BM_XBAR_POOL_REG(pool_id), val);
 }
 
-void *mvneta_frag_alloc(unsigned int frag_size)
-{
-	if (likely(frag_size <= PAGE_SIZE))
-		return netdev_alloc_frag(frag_size);
-	else
-		return kmalloc(frag_size, GFP_ATOMIC);
-}
-EXPORT_SYMBOL_GPL(mvneta_frag_alloc);
-
-void mvneta_frag_free(unsigned int frag_size, void *data)
+int mvneta_bm_construct(struct hwbm_pool *hwbm_pool, void *buf)
 {
-	if (likely(frag_size <= PAGE_SIZE))
-		skb_free_frag(data);
-	else
-		kfree(data);
-}
-EXPORT_SYMBOL_GPL(mvneta_frag_free);
-
-/* Allocate skb for BM pool */
-void *mvneta_buf_alloc(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool,
-		       dma_addr_t *buf_phys_addr)
-{
-	void *buf;
+	struct mvneta_bm_pool *bm_pool =
+		(struct mvneta_bm_pool *)hwbm_pool->priv;
+	struct mvneta_bm *priv = bm_pool->priv;
 	dma_addr_t phys_addr;
 
-	buf = mvneta_frag_alloc(bm_pool->frag_size);
-	if (!buf)
-		return NULL;
-
 	/* In order to update buf_cookie field of RX descriptor properly,
 	 * BM hardware expects buf virtual address to be placed in the
 	 * first four bytes of mapped buffer.
@@ -124,74 +103,13 @@ void *mvneta_buf_alloc(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool,
 	*(u32 *)buf = (u32)buf;
 	phys_addr = dma_map_single(&priv->pdev->dev, buf, bm_pool->buf_size,
 				   DMA_FROM_DEVICE);
-	if (unlikely(dma_mapping_error(&priv->pdev->dev, phys_addr))) {
-		mvneta_frag_free(bm_pool->frag_size, buf);
-		return NULL;
-	}
-	*buf_phys_addr = phys_addr;
-
-	return buf;
-}
-
-/* Refill processing for HW buffer management */
-int mvneta_bm_pool_refill(struct mvneta_bm *priv,
-			  struct mvneta_bm_pool *bm_pool)
-{
-	dma_addr_t buf_phys_addr;
-	void *buf;
-
-	buf = mvneta_buf_alloc(priv, bm_pool, &buf_phys_addr);
-	if (!buf)
+	if (unlikely(dma_mapping_error(&priv->pdev->dev, phys_addr)))
 		return -ENOMEM;
 
-	mvneta_bm_pool_put_bp(priv, bm_pool, buf_phys_addr);
-
+	mvneta_bm_pool_put_bp(priv, bm_pool, phys_addr);
 	return 0;
 }
-EXPORT_SYMBOL_GPL(mvneta_bm_pool_refill);
-
-/* Allocate buffers for the pool */
-int mvneta_bm_bufs_add(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool,
-		       int buf_num)
-{
-	int err, i;
-
-	if (bm_pool->buf_num == bm_pool->size) {
-		dev_dbg(&priv->pdev->dev, "pool %d already filled\n",
-			bm_pool->id);
-		return bm_pool->buf_num;
-	}
-
-	if (buf_num < 0 ||
-	    (buf_num + bm_pool->buf_num > bm_pool->size)) {
-		dev_err(&priv->pdev->dev,
-			"cannot allocate %d buffers for pool %d\n",
-			buf_num, bm_pool->id);
-		return 0;
-	}
-
-	for (i = 0; i < buf_num; i++) {
-		err = mvneta_bm_pool_refill(priv, bm_pool);
-		if (err < 0)
-			break;
-	}
-
-	/* Update BM driver with number of buffers added to pool */
-	bm_pool->buf_num += i;
 
-	dev_dbg(&priv->pdev->dev,
-		"%s pool %d: pkt_size=%4d, buf_size=%4d, frag_size=%4d\n",
-		bm_pool->type == MVNETA_BM_SHORT ? "short" : "long",
-		bm_pool->id, bm_pool->pkt_size, bm_pool->buf_size,
-		bm_pool->frag_size);
-
-	dev_dbg(&priv->pdev->dev,
-		"%s pool %d: %d of %d buffers added\n",
-		bm_pool->type == MVNETA_BM_SHORT ? "short" : "long",
-		bm_pool->id, i, buf_num);
-
-	return i;
-}
 
 /* Create pool */
 static int mvneta_bm_pool_create(struct mvneta_bm *priv,
@@ -200,8 +118,7 @@ static int mvneta_bm_pool_create(struct mvneta_bm *priv,
 	struct platform_device *pdev = priv->pdev;
 	u8 target_id, attr;
 	int size_bytes, err;
-
-	size_bytes = sizeof(u32) * bm_pool->size;
+	size_bytes = sizeof(u32) * bm_pool->hwbm_pool.size;
 	bm_pool->virt_addr = dma_alloc_coherent(&pdev->dev, size_bytes,
 						&bm_pool->phys_addr,
 						GFP_KERNEL);
@@ -262,11 +179,16 @@ struct mvneta_bm_pool *mvneta_bm_pool_use(struct mvneta_bm *priv, u8 pool_id,
 
 	/* Allocate buffers in case BM pool hasn't been used yet */
 	if (new_pool->type == MVNETA_BM_FREE) {
+		struct hwbm_pool *hwbm_pool = &new_pool->hwbm_pool;
+
+		new_pool->priv = priv;
 		new_pool->type = type;
 		new_pool->buf_size = MVNETA_RX_BUF_SIZE(new_pool->pkt_size);
-		new_pool->frag_size =
+		hwbm_pool->size =
 			SKB_DATA_ALIGN(MVNETA_RX_BUF_SIZE(new_pool->pkt_size)) +
 			SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
+		hwbm_pool->construct = mvneta_bm_construct;
+		hwbm_pool->priv = new_pool;
 
 		/* Create new pool */
 		err = mvneta_bm_pool_create(priv, new_pool);
@@ -277,10 +199,10 @@ struct mvneta_bm_pool *mvneta_bm_pool_use(struct mvneta_bm *priv, u8 pool_id,
 		}
 
 		/* Allocate buffers for this pool */
-		num = mvneta_bm_bufs_add(priv, new_pool, new_pool->size);
-		if (num != new_pool->size) {
+		num = hwbm_pool_add(hwbm_pool, hwbm_pool->size, GFP_ATOMIC);
+		if (num != hwbm_pool->size) {
 			WARN(1, "pool %d: %d of %d allocated\n",
-			     new_pool->id, num, new_pool->size);
+			     new_pool->id, num, hwbm_pool->size);
 			return NULL;
 		}
 	}
@@ -301,7 +223,7 @@ void mvneta_bm_bufs_free(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool,
 
 	mvneta_bm_config_set(priv, MVNETA_BM_EMPTY_LIMIT_MASK);
 
-	for (i = 0; i < bm_pool->buf_num; i++) {
+	for (i = 0; i < bm_pool->hwbm_pool.buf_num; i++) {
 		dma_addr_t buf_phys_addr;
 		u32 *vaddr;
 
@@ -320,19 +242,20 @@ void mvneta_bm_bufs_free(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool,
 
 		dma_unmap_single(&priv->pdev->dev, buf_phys_addr,
 				 bm_pool->buf_size, DMA_FROM_DEVICE);
-		mvneta_frag_free(bm_pool->frag_size, vaddr);
+		hwbm_buf_free(&bm_pool->hwbm_pool, vaddr);
 	}
 
 	mvneta_bm_config_clear(priv, MVNETA_BM_EMPTY_LIMIT_MASK);
 
 	/* Update BM driver with number of buffers removed from pool */
-	bm_pool->buf_num -= i;
+	bm_pool->hwbm_pool.buf_num -= i;
 }
 
 /* Cleanup pool */
 void mvneta_bm_pool_destroy(struct mvneta_bm *priv,
 			    struct mvneta_bm_pool *bm_pool, u8 port_map)
 {
+	struct hwbm_pool *hwbm_pool = &bm_pool->hwbm_pool;
 	bm_pool->port_map &= ~port_map;
 	if (bm_pool->port_map)
 		return;
@@ -340,11 +263,12 @@ void mvneta_bm_pool_destroy(struct mvneta_bm *priv,
 	bm_pool->type = MVNETA_BM_FREE;
 
 	mvneta_bm_bufs_free(priv, bm_pool, port_map);
-	if (bm_pool->buf_num)
+	if (hwbm_pool->buf_num)
 		WARN(1, "cannot free all buffers in pool %d\n", bm_pool->id);
 
 	if (bm_pool->virt_addr) {
-		dma_free_coherent(&priv->pdev->dev, sizeof(u32) * bm_pool->size,
+		dma_free_coherent(&priv->pdev->dev,
+				  sizeof(u32) * hwbm_pool->size,
 				  bm_pool->virt_addr, bm_pool->phys_addr);
 		bm_pool->virt_addr = NULL;
 	}
@@ -397,10 +321,10 @@ static void mvneta_bm_pools_init(struct mvneta_bm *priv)
 				 MVNETA_BM_POOL_CAP_ALIGN));
 			size = ALIGN(size, MVNETA_BM_POOL_CAP_ALIGN);
 		}
-		bm_pool->size = size;
+		bm_pool->hwbm_pool.size = size;
 
 		mvneta_bm_write(priv, MVNETA_BM_POOL_SIZE_REG(i),
-				bm_pool->size);
+				bm_pool->hwbm_pool.size);
 
 		/* Obtain custom pkt_size from DT */
 		sprintf(prop, "pool%d,pkt-size", i);
diff --git a/drivers/net/ethernet/marvell/mvneta_bm.h b/drivers/net/ethernet/marvell/mvneta_bm.h
index f2449b843577..ea08736d8cb4 100644
--- a/drivers/net/ethernet/marvell/mvneta_bm.h
+++ b/drivers/net/ethernet/marvell/mvneta_bm.h
@@ -108,20 +108,15 @@ struct mvneta_bm {
 };
 
 struct mvneta_bm_pool {
+	struct hwbm_pool hwbm_pool;
 	/* Pool number in the range 0-3 */
 	u8 id;
 	enum mvneta_bm_type type;
 
-	/* Buffer Pointers Pool External (BPPE) size in number of bytes */
-	int size;
-	/* Number of buffers used by this pool */
-	int buf_num;
-	/* Pool buffer size */
-	int buf_size;
 	/* Packet size */
 	int pkt_size;
-	/* Single frag size */
-	u32 frag_size;
+	/* Size of the buffer acces through DMA*/
+	u32 buf_size;
 
 	/* BPPE virtual base address */
 	u32 *virt_addr;
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 07:33:37 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 16:33:37 +0100
Subject: [PATCH v2 2/8] ARM: dts: armada-38x: enable buffer manager support on
 Armada 38x boards
In-Reply-To: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455636823-14470-3-git-send-email-gregory.clement@free-electrons.com>

From: Marcin Wojtas <mw at semihalf.com>

Since mvneta driver supports using hardware buffer management (BM), in
order to use it, board files have to be adjusted accordingly. This commit
enables BM on:
* A385-DB-AP - each port has its own pool for long and common pool for
short packets,
* A388-ClearFog - same as above,
* A388-DB - to each port unique 'short' and 'long' pools are mapped,
* A388-GP - same as above.

Moreover appropriate entry is added to 'soc' node ranges, as well as "okay"
status for 'bm' and 'bm-bppi' (internal SRAM) nodes.

[gregory.clement at free-electrons.com: add suppport for the ClearFog board]

Signed-off-by: Marcin Wojtas <mw at semihalf.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/boot/dts/armada-385-db-ap.dts              | 20 +++++++++++++++++++-
 arch/arm/boot/dts/armada-388-clearfog.dts           |  6 ++++++
 arch/arm/boot/dts/armada-388-db.dts                 | 17 ++++++++++++++++-
 arch/arm/boot/dts/armada-388-gp.dts                 | 17 ++++++++++++++++-
 arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 15 ++++++++++++++-
 5 files changed, 71 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/armada-385-db-ap.dts b/arch/arm/boot/dts/armada-385-db-ap.dts
index acd5b1519edb..5f9451be21ff 100644
--- a/arch/arm/boot/dts/armada-385-db-ap.dts
+++ b/arch/arm/boot/dts/armada-385-db-ap.dts
@@ -61,7 +61,8 @@
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
 			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
 			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
-			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000
+			  MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000>;
 
 		internal-regs {
 			spi1: spi at 10680 {
@@ -138,12 +139,18 @@
 				status = "okay";
 				phy = <&phy2>;
 				phy-mode = "sgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <1>;
+				bm,pool-short = <3>;
 			};
 
 			ethernet at 34000 {
 				status = "okay";
 				phy = <&phy1>;
 				phy-mode = "sgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <2>;
+				bm,pool-short = <3>;
 			};
 
 			ethernet at 70000 {
@@ -157,6 +164,13 @@
 				status = "okay";
 				phy = <&phy0>;
 				phy-mode = "rgmii-id";
+				buffer-manager = <&bm>;
+				bm,pool-long = <0>;
+				bm,pool-short = <3>;
+			};
+
+			bm at c8000 {
+				status = "okay";
 			};
 
 			nfc: flash at d0000 {
@@ -178,6 +192,10 @@
 			};
 		};
 
+		bm-bppi {
+			status = "okay";
+		};
+
 		pcie-controller {
 			status = "okay";
 
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
index c6e180eb3b11..c60206efb583 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog.dts
@@ -78,6 +78,9 @@
 		internal-regs {
 			ethernet at 30000 {
 				phy-mode = "sgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <2>;
+				bm,pool-short = <1>;
 				status = "okay";
 
 				fixed-link {
@@ -88,6 +91,9 @@
 
 			ethernet at 34000 {
 				phy-mode = "sgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <3>;
+				bm,pool-short = <1>;
 				status = "okay";
 
 				fixed-link {
diff --git a/arch/arm/boot/dts/armada-388-db.dts b/arch/arm/boot/dts/armada-388-db.dts
index ff47af57f091..ea93ed727030 100644
--- a/arch/arm/boot/dts/armada-388-db.dts
+++ b/arch/arm/boot/dts/armada-388-db.dts
@@ -66,7 +66,8 @@
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
 			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
 			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
-			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000
+			  MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000>;
 
 		internal-regs {
 			spi at 10600 {
@@ -99,6 +100,9 @@
 				status = "okay";
 				phy = <&phy1>;
 				phy-mode = "rgmii-id";
+				buffer-manager = <&bm>;
+				bm,pool-long = <2>;
+				bm,pool-short = <3>;
 			};
 
 			usb at 58000 {
@@ -109,6 +113,9 @@
 				status = "okay";
 				phy = <&phy0>;
 				phy-mode = "rgmii-id";
+				buffer-manager = <&bm>;
+				bm,pool-long = <0>;
+				bm,pool-short = <1>;
 			};
 
 			mdio at 72004 {
@@ -129,6 +136,10 @@
 				status = "okay";
 			};
 
+			bm at c8000 {
+				status = "okay";
+			};
+
 			flash at d0000 {
 				status = "okay";
 				num-cs = <1>;
@@ -169,6 +180,10 @@
 			};
 		};
 
+		bm-bppi {
+			status = "okay";
+		};
+
 		pcie-controller {
 			status = "okay";
 			/*
diff --git a/arch/arm/boot/dts/armada-388-gp.dts b/arch/arm/boot/dts/armada-388-gp.dts
index cd316021d6ce..466b01eb1038 100644
--- a/arch/arm/boot/dts/armada-388-gp.dts
+++ b/arch/arm/boot/dts/armada-388-gp.dts
@@ -60,7 +60,8 @@
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
 			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
 			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
-			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000
+			  MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000>;
 
 		internal-regs {
 			spi at 10600 {
@@ -133,6 +134,9 @@
 				status = "okay";
 				phy = <&phy1>;
 				phy-mode = "rgmii-id";
+				buffer-manager = <&bm>;
+				bm,pool-long = <2>;
+				bm,pool-short = <3>;
 			};
 
 			/* CON4 */
@@ -152,6 +156,9 @@
 				status = "okay";
 				phy = <&phy0>;
 				phy-mode = "rgmii-id";
+				buffer-manager = <&bm>;
+				bm,pool-long = <0>;
+				bm,pool-short = <1>;
 			};
 
 
@@ -186,6 +193,10 @@
 				};
 			};
 
+			bm at c8000 {
+				status = "okay";
+			};
+
 			sata at e0000 {
 				pinctrl-names = "default";
 				pinctrl-0 = <&sata2_pins>, <&sata3_pins>;
@@ -240,6 +251,10 @@
 			};
 		};
 
+		bm-bppi {
+			status = "okay";
+		};
+
 		pcie-controller {
 			status = "okay";
 			/*
diff --git a/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi b/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
index 3f792a563c05..8c9842237b60 100644
--- a/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
+++ b/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
@@ -58,7 +58,8 @@
 		ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
 			  MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
 			  MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
-			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
+			  MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000
+			  MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000>;
 
 		internal-regs {
 			ethernet at 70000 {
@@ -66,6 +67,9 @@
 				pinctrl-names = "default";
 				phy = <&phy_dedicated>;
 				phy-mode = "rgmii-id";
+				buffer-manager = <&bm>;
+				bm,pool-long = <0>;
+				bm,pool-short = <1>;
 				status = "okay";
 			};
 
@@ -110,6 +114,15 @@
 				pinctrl-names = "default";
 				status = "okay";
 			};
+
+			bm at c8000 {
+				status = "okay";
+			};
 		};
+
+		bm-bppi {
+			status = "okay";
+		};
+
 	};
 };
-- 
2.5.0



From tiwai at suse.de  Tue Feb 16 07:49:42 2016
From: tiwai at suse.de (Takashi Iwai)
Date: Tue, 16 Feb 2016 16:49:42 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
Message-ID: <s5hbn7g7izt.wl-tiwai@suse.de>

On Tue, 16 Feb 2016 15:47:28 +0100,
Arnd Bergmann wrote:
> 
> When CONFIG_SND_JACK is disabled, the hdmi driver tries to create
> a new output jack structure and dereferences it even though
> the pointer is never assigned:
> 
> sound/pci/hda/patch_hdmi.c: In function 'generic_hdmi_build_jack':
> sound/pci/hda/patch_hdmi.c:2534:30: error: 'jack' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> sound/pci/hda/patch_hdmi.c:2526:19: note: 'jack' was declared here
> 
> This uses a compile-time check to avoid calling a nonworking
> snd_jack_new() function, and sets an explicit NULL pointer instead.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 788d441a164c ("ALSA: hda - Use component ops for i915 HDMI/DP audio jack handling")

Thanks for the patch.  But I think it's cleaner to fix Kconfig.

Thinking more of it, maybe splitting jack stuff as a separate module
and does reverse-select to CONFIG_INPUT would be better.  Then its
users can select simply SND_JACK, and everything would fit.

An untested patch is below.  Mark, what do you think?


Takashi

---
diff --git a/sound/core/Kconfig b/sound/core/Kconfig
index a2a1e24becc6..cf4058dde959 100644
--- a/sound/core/Kconfig
+++ b/sound/core/Kconfig
@@ -24,11 +24,9 @@ config SND_RAWMIDI
 config SND_COMPRESS_OFFLOAD
 	tristate
 
-# To be effective this also requires INPUT - users should say:
-#    select SND_JACK if INPUT=y || INPUT=SND
-# to avoid having to force INPUT on.
 config SND_JACK
-	bool
+	tristate
+	select INPUT
 
 config SND_SEQUENCER
 	tristate "Sequencer support"
diff --git a/sound/core/Makefile b/sound/core/Makefile
index 48ab4b8f8279..d16e2b0ba4fb 100644
--- a/sound/core/Makefile
+++ b/sound/core/Makefile
@@ -11,7 +11,8 @@ endif
 snd-$(CONFIG_ISA_DMA_API) += isadma.o
 snd-$(CONFIG_SND_OSSEMUL) += sound_oss.o
 snd-$(CONFIG_SND_VMASTER) += vmaster.o
-snd-$(CONFIG_SND_JACK)	  += ctljack.o jack.o
+
+snd-jack-objs	:= ctljack.o jack.o
 
 snd-pcm-y := pcm.o pcm_native.o pcm_lib.o pcm_misc.o \
 		pcm_memory.o memalloc.o
@@ -41,6 +42,7 @@ obj-$(CONFIG_SND_RTCTIMER)	+= snd-rtctimer.o
 obj-$(CONFIG_SND_PCM)		+= snd-pcm.o
 obj-$(CONFIG_SND_DMAENGINE_PCM)	+= snd-pcm-dmaengine.o
 obj-$(CONFIG_SND_RAWMIDI)	+= snd-rawmidi.o
+obj-$(CONFIG_SND_JACK)		+= snd-jack.o
 
 obj-$(CONFIG_SND_OSSEMUL)	+= oss/
 obj-$(CONFIG_SND_SEQUENCER)	+= seq/
diff --git a/sound/pci/Kconfig b/sound/pci/Kconfig
index 8f6594a7d37f..32151d8c6bb8 100644
--- a/sound/pci/Kconfig
+++ b/sound/pci/Kconfig
@@ -866,7 +866,7 @@ config SND_VIRTUOSO
 	select SND_OXYGEN_LIB
 	select SND_PCM
 	select SND_MPU401_UART
-	select SND_JACK if INPUT=y || INPUT=SND
+	select SND_JACK
 	help
 	  Say Y here to include support for sound cards based on the
 	  Asus AV66/AV100/AV200 chips, i.e., Xonar D1, DX, D2, D2X, DS, DSX,
diff --git a/sound/pci/hda/Kconfig b/sound/pci/hda/Kconfig
index e94cfd5c69f7..bb02c2d48fd5 100644
--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -4,7 +4,7 @@ config SND_HDA
 	tristate
 	select SND_PCM
 	select SND_VMASTER
-	select SND_JACK if INPUT=y || INPUT=SND
+	select SND_JACK
 	select SND_HDA_CORE
 
 config SND_HDA_INTEL
diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 7ea66ee3653f..182d92efc7c8 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -6,7 +6,7 @@ menuconfig SND_SOC
 	tristate "ALSA for SoC audio support"
 	select SND_PCM
 	select AC97_BUS if SND_SOC_AC97_BUS
-	select SND_JACK if INPUT=y || INPUT=SND
+	select SND_JACK
 	select REGMAP_I2C if I2C
 	select REGMAP_SPI if SPI_MASTER
 	---help---



From gregory.clement at free-electrons.com  Tue Feb 16 07:33:42 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 16:33:42 +0100
Subject: [PATCH v2 net-next 7/8] net: add a hardware buffer management helper
 API
In-Reply-To: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455636823-14470-8-git-send-email-gregory.clement@free-electrons.com>

This basic implementation allows to share code between driver using
hardware buffer management. As the code is hardware agnostic, there is
few helpers, most of the optimization brought by the an HW BM has to be
done at driver level.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 include/net/hwbm.h | 21 +++++++++++++
 net/Kconfig        |  3 ++
 net/core/Makefile  |  1 +
 net/core/hwbm.c    | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 112 insertions(+)
 create mode 100644 include/net/hwbm.h
 create mode 100644 net/core/hwbm.c

diff --git a/include/net/hwbm.h b/include/net/hwbm.h
new file mode 100644
index 000000000000..9ae9449a7eda
--- /dev/null
+++ b/include/net/hwbm.h
@@ -0,0 +1,21 @@
+#ifndef _HWBM_H
+#define _HWBM_H
+
+struct hwbm_pool {
+	/* Size of the buffers managed */
+	int size;
+	/* Number of buffers currently used by this pool */
+	int buf_num;
+	/* constructor called during alocation */
+	int (*construct)(struct hwbm_pool *bm_pool, void *buf);
+	/* protect acces to the buffer counter*/
+	spinlock_t lock;
+	/* private data */
+	void *priv;
+};
+
+void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf);
+int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp);
+int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num, gfp_t gfp);
+
+#endif /* _HWBM_H */
diff --git a/net/Kconfig b/net/Kconfig
index 174354618f8a..f50c8af4308b 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -253,6 +253,9 @@ config XPS
 	depends on SMP
 	default y
 
+config HWBM
+       bool
+
 config SOCK_CGROUP_DATA
 	bool
 	default n
diff --git a/net/core/Makefile b/net/core/Makefile
index 0b835de04de3..57e6dd81c6be 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -24,3 +24,4 @@ obj-$(CONFIG_NET_PTP_CLASSIFY) += ptp_classifier.o
 obj-$(CONFIG_CGROUP_NET_PRIO) += netprio_cgroup.o
 obj-$(CONFIG_CGROUP_NET_CLASSID) += netclassid_cgroup.o
 obj-$(CONFIG_LWTUNNEL) += lwtunnel.o
+obj-$(CONFIG_HWBM) += hwbm.o
diff --git a/net/core/hwbm.c b/net/core/hwbm.c
new file mode 100644
index 000000000000..a98d2a74ca02
--- /dev/null
+++ b/net/core/hwbm.c
@@ -0,0 +1,87 @@
+/* Support for hardware buffer manager.
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ */
+#include <linux/kernel.h>
+#include <linux/printk.h>
+#include <linux/skbuff.h>
+#include <net/hwbm.h>
+
+void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf)
+{
+	if (likely(bm_pool->size <= PAGE_SIZE))
+		skb_free_frag(buf);
+	else
+		kfree(buf);
+}
+EXPORT_SYMBOL_GPL(hwbm_buf_free);
+
+/* Refill processing for HW buffer management */
+int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp)
+{
+	int frag_size = bm_pool->size;
+	void *buf;
+
+	if (likely(frag_size <= PAGE_SIZE))
+		buf = netdev_alloc_frag(frag_size);
+	else
+		buf = kmalloc(frag_size, gfp);
+
+	if (!buf)
+		return -ENOMEM;
+
+	if (bm_pool->construct)
+		if (bm_pool->construct(bm_pool, buf)) {
+			hwbm_buf_free(bm_pool, buf);
+			return -ENOMEM;
+		}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(hwbm_pool_refill);
+
+int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num, gfp_t gfp)
+{
+	int err, i;
+	unsigned long flags;
+
+	spin_lock_irqsave(&bm_pool->lock, flags);
+	if (bm_pool->buf_num == bm_pool->size) {
+		pr_warn("pool already filled\n");
+		return bm_pool->buf_num;
+	}
+
+	if (buf_num + bm_pool->buf_num > bm_pool->size) {
+		pr_warn("cannot allocate %d buffers for pool\n",
+			buf_num);
+		return 0;
+	}
+
+	if ((buf_num + bm_pool->buf_num) < bm_pool->buf_num) {
+		pr_warn("Adding %d buffers to the %d current buffers will overflow\n",
+			buf_num,  bm_pool->buf_num);
+		return 0;
+	}
+
+	for (i = 0; i < buf_num; i++) {
+		err = hwbm_pool_refill(bm_pool, gfp);
+		if (err < 0)
+			break;
+	}
+
+	/* Update BM driver with number of buffers added to pool */
+	bm_pool->buf_num += i;
+
+	pr_debug("hwpm pool: %d of %d buffers added\n", i, buf_num);
+	spin_unlock_irqrestore(&bm_pool->lock, flags);
+
+	return i;
+}
+EXPORT_SYMBOL_GPL(hwbm_pool_add);
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 07:33:39 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 16:33:39 +0100
Subject: [PATCH v2 4/8] ARM: dts: armada-xp: enable buffer manager support on
 Armada XP boards
In-Reply-To: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455636823-14470-5-git-send-email-gregory.clement@free-electrons.com>

From: Marcin Wojtas <mw at semihalf.com>

Since mvneta driver supports using hardware buffer management (BM), in
order to use it, board files have to be adjusted accordingly. This commit
enables BM on AXP-DB and AXP-GP in same manner - because number of ports
on those boards is the same as number of possible pools, each port is
supposed to use single pool for all kind of packets.

Moreover appropriate entry is added to 'soc' node ranges, as well as "okay"
status for 'bm' and 'bm-bppi' (internal SRAM) nodes.

Signed-off-by: Marcin Wojtas <mw at semihalf.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-db.dts | 19 ++++++++++++++++++-
 arch/arm/boot/dts/armada-xp-gp.dts | 19 ++++++++++++++++++-
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index f774101416a5..30657302305d 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -77,7 +77,8 @@
 			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
 			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000
 			  MBUS_ID(0x09, 0x09) 0 0 0xf8100000 0x10000
-			  MBUS_ID(0x09, 0x05) 0 0 0xf8110000 0x10000>;
+			  MBUS_ID(0x09, 0x05) 0 0 0xf8110000 0x10000
+			  MBUS_ID(0x0c, 0x04) 0 0 0xf1200000 0x100000>;
 
 		devbus-bootcs {
 			status = "okay";
@@ -181,21 +182,33 @@
 				status = "okay";
 				phy = <&phy0>;
 				phy-mode = "rgmii-id";
+				buffer-manager = <&bm>;
+				bm,pool-long = <0>;
 			};
 			ethernet at 74000 {
 				status = "okay";
 				phy = <&phy1>;
 				phy-mode = "rgmii-id";
+				buffer-manager = <&bm>;
+				bm,pool-long = <1>;
 			};
 			ethernet at 30000 {
 				status = "okay";
 				phy = <&phy2>;
 				phy-mode = "sgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <2>;
 			};
 			ethernet at 34000 {
 				status = "okay";
 				phy = <&phy3>;
 				phy-mode = "sgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <3>;
+			};
+
+			bm at c0000 {
+				status = "okay";
 			};
 
 			mvsdio at d4000 {
@@ -230,5 +243,9 @@
 				};
 			};
 		};
+
+		bm-bppi {
+			status = "okay";
+		};
 	};
 };
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 4878d7353069..a1ded01d0c07 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -96,7 +96,8 @@
 			  MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
 			  MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x1000000
 			  MBUS_ID(0x09, 0x09) 0 0 0xf8100000 0x10000
-			  MBUS_ID(0x09, 0x05) 0 0 0xf8110000 0x10000>;
+			  MBUS_ID(0x09, 0x05) 0 0 0xf8110000 0x10000
+			  MBUS_ID(0x0c, 0x04) 0 0 0xf1200000 0x100000>;
 
 		devbus-bootcs {
 			status = "okay";
@@ -196,21 +197,29 @@
 				status = "okay";
 				phy = <&phy0>;
 				phy-mode = "qsgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <0>;
 			};
 			ethernet at 74000 {
 				status = "okay";
 				phy = <&phy1>;
 				phy-mode = "qsgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <1>;
 			};
 			ethernet at 30000 {
 				status = "okay";
 				phy = <&phy2>;
 				phy-mode = "qsgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <2>;
 			};
 			ethernet at 34000 {
 				status = "okay";
 				phy = <&phy3>;
 				phy-mode = "qsgmii";
+				buffer-manager = <&bm>;
+				bm,pool-long = <3>;
 			};
 
 			/* Front-side USB slot */
@@ -235,6 +244,10 @@
 				};
 			};
 
+			bm at c0000 {
+				status = "okay";
+			};
+
 			nand at d0000 {
 				status = "okay";
 				num-cs = <1>;
@@ -243,5 +256,9 @@
 				nand-on-flash-bbt;
 			};
 		};
+
+		bm-bppi {
+			status = "okay";
+		};
 	};
 };
-- 
2.5.0



From james.morse at arm.com  Tue Feb 16 07:49:21 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:21 +0000
Subject: [PATCH v5 09/15] arm64: Promote KERNEL_START/KERNEL_END definitions
 to a header file
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <1455637767-31561-10-git-send-email-james.morse@arm.com>

KERNEL_START and KERNEL_END are useful outside head.S, move them to a
header file.

Signed-off-by: James Morse <james.morse at arm.com>
---
 arch/arm64/include/asm/memory.h | 3 +++
 arch/arm64/kernel/head.S        | 3 ---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 3239e4d78e0d..04de97734f06 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -71,6 +71,9 @@
 
 #define TASK_UNMAPPED_BASE	(PAGE_ALIGN(TASK_SIZE / 4))
 
+#define KERNEL_START      _text
+#define KERNEL_END        _end
+
 /*
  * The size of the KASAN shadow region. This should be 1/8th of the
  * size of the entire kernel virtual address space.
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 6fad2f814ecf..410a2dc04775 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -48,9 +48,6 @@
 #error TEXT_OFFSET must be less than 2MB
 #endif
 
-#define KERNEL_START	_text
-#define KERNEL_END	_end
-
 /*
  * Kernel startup entry point.
  * ---------------------------
-- 
2.6.2



From james.morse at arm.com  Tue Feb 16 07:49:18 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:18 +0000
Subject: [PATCH v5 06/15] arm64: kernel: Rework finisher callback out of
 __cpu_suspend_enter().
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <1455637767-31561-7-git-send-email-james.morse@arm.com>

Hibernate could make use of the cpu_suspend() code to save/restore cpu
state, however it needs to be able to return '0' from the 'finisher'.

Rework cpu_suspend() so that the finisher is called from C code,
independently from the save/restore of cpu state. Space to save the context
in is allocated in the caller's stack frame, and passed into
__cpu_suspend_enter().

Hibernate's use of this API will look like a copy of the cpu_suspend()
function.

Signed-off-by: James Morse <james.morse at arm.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
---
 arch/arm64/include/asm/suspend.h | 20 +++++++++
 arch/arm64/kernel/asm-offsets.c  |  2 +
 arch/arm64/kernel/sleep.S        | 93 ++++++++++++++--------------------------
 arch/arm64/kernel/suspend.c      | 66 +++++++++++++++++-----------
 4 files changed, 97 insertions(+), 84 deletions(-)

diff --git a/arch/arm64/include/asm/suspend.h b/arch/arm64/include/asm/suspend.h
index 59a5b0f1e81c..365d8cdd0073 100644
--- a/arch/arm64/include/asm/suspend.h
+++ b/arch/arm64/include/asm/suspend.h
@@ -2,6 +2,7 @@
 #define __ASM_SUSPEND_H
 
 #define NR_CTX_REGS 11
+#define NR_CALLEE_SAVED_REGS 12
 
 /*
  * struct cpu_suspend_ctx must be 16-byte aligned since it is allocated on
@@ -21,6 +22,25 @@ struct sleep_save_sp {
 	phys_addr_t save_ptr_stash_phys;
 };
 
+/*
+ * Memory to save the cpu state is allocated on the stack by
+ * __cpu_suspend_enter()'s caller, and populated by __cpu_suspend_enter().
+ * This data must survive until cpu_resume() is called.
+ *
+ * This struct desribes the size and the layout of the saved cpu state.
+ * The layout of the callee_saved_regs is defined by the implementation
+ * of __cpu_suspend_enter(), and cpu_resume(). This struct must be passed
+ * in by the caller as __cpu_suspend_enter()'s stack-frame is gone once it
+ * returns, and the data would be subsequently corrupted by the call to the
+ * finisher.
+ */
+struct sleep_stack_data {
+	struct cpu_suspend_ctx	system_regs;
+	unsigned long		callee_saved_regs[NR_CALLEE_SAVED_REGS];
+};
+
 extern int cpu_suspend(unsigned long arg, int (*fn)(unsigned long));
 extern void cpu_resume(void);
+int __cpu_suspend_enter(struct sleep_stack_data *state);
+void __cpu_suspend_exit(void);
 #endif
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index fffa4ac6c25a..7d7994774e82 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -123,6 +123,8 @@ int main(void)
   DEFINE(SLEEP_SAVE_SP_SZ,	sizeof(struct sleep_save_sp));
   DEFINE(SLEEP_SAVE_SP_PHYS,	offsetof(struct sleep_save_sp, save_ptr_stash_phys));
   DEFINE(SLEEP_SAVE_SP_VIRT,	offsetof(struct sleep_save_sp, save_ptr_stash));
+  DEFINE(SLEEP_STACK_DATA_SYSTEM_REGS,	offsetof(struct sleep_stack_data, system_regs));
+  DEFINE(SLEEP_STACK_DATA_CALLEE_REGS,	offsetof(struct sleep_stack_data, callee_saved_regs));
 #endif
   DEFINE(ARM_SMCCC_RES_X0_OFFS,	offsetof(struct arm_smccc_res, a0));
   DEFINE(ARM_SMCCC_RES_X2_OFFS,	offsetof(struct arm_smccc_res, a2));
diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
index e33fe33876ab..dca81612fe90 100644
--- a/arch/arm64/kernel/sleep.S
+++ b/arch/arm64/kernel/sleep.S
@@ -49,37 +49,30 @@
 	orr	\dst, \dst, \mask		// dst|=(aff3>>rs3)
 	.endm
 /*
- * Save CPU state for a suspend and execute the suspend finisher.
- * On success it will return 0 through cpu_resume - ie through a CPU
- * soft/hard reboot from the reset vector.
- * On failure it returns the suspend finisher return value or force
- * -EOPNOTSUPP if the finisher erroneously returns 0 (the suspend finisher
- * is not allowed to return, if it does this must be considered failure).
- * It saves callee registers, and allocates space on the kernel stack
- * to save the CPU specific registers + some other data for resume.
+ * Save CPU state in the provided sleep_stack_data area, and publish its
+ * location for cpu_resume()'s use in sleep_save_stash.
  *
- *  x0 = suspend finisher argument
- *  x1 = suspend finisher function pointer
+ * cpu_resume() will restore this saved state, and return. Because the
+ * link-register is saved and restored, it will appear to return from this
+ * function. So that the caller can tell the suspend/resume paths apart,
+ * __cpu_suspend_enter() will always return a non-zero value, whereas the
+ * path through cpu_resume() will return 0.
+ *
+ *  x0 = struct sleep_stack_data area
  */
 ENTRY(__cpu_suspend_enter)
-	stp	x29, lr, [sp, #-96]!
-	stp	x19, x20, [sp,#16]
-	stp	x21, x22, [sp,#32]
-	stp	x23, x24, [sp,#48]
-	stp	x25, x26, [sp,#64]
-	stp	x27, x28, [sp,#80]
-	/*
-	 * Stash suspend finisher and its argument in x20 and x19
-	 */
-	mov	x19, x0
-	mov	x20, x1
+	stp	x29, lr, [x0, #SLEEP_STACK_DATA_CALLEE_REGS]
+	stp	x19, x20, [x0,#SLEEP_STACK_DATA_CALLEE_REGS+16]
+	stp	x21, x22, [x0,#SLEEP_STACK_DATA_CALLEE_REGS+32]
+	stp	x23, x24, [x0,#SLEEP_STACK_DATA_CALLEE_REGS+48]
+	stp	x25, x26, [x0,#SLEEP_STACK_DATA_CALLEE_REGS+64]
+	stp	x27, x28, [x0,#SLEEP_STACK_DATA_CALLEE_REGS+80]
+
+	/* save the sp in cpu_suspend_ctx */
 	mov	x2, sp
-	sub	sp, sp, #CPU_SUSPEND_SZ	// allocate cpu_suspend_ctx
-	mov	x0, sp
-	/*
-	 * x0 now points to struct cpu_suspend_ctx allocated on the stack
-	 */
-	str	x2, [x0, #CPU_CTX_SP]
+	str	x2, [x0, #SLEEP_STACK_DATA_SYSTEM_REGS + CPU_CTX_SP]
+
+	/* find the mpidr_hash */
 	ldr	x1, =sleep_save_sp
 	ldr	x1, [x1, #SLEEP_SAVE_SP_VIRT]
 	mrs	x7, mpidr_el1
@@ -93,34 +86,11 @@ ENTRY(__cpu_suspend_enter)
 	ldp	w5, w6, [x9, #(MPIDR_HASH_SHIFTS + 8)]
 	compute_mpidr_hash x8, x3, x4, x5, x6, x7, x10
 	add	x1, x1, x8, lsl #3
+
+	push	x29, lr
 	bl	__cpu_suspend_save
-	/*
-	 * Grab suspend finisher in x20 and its argument in x19
-	 */
-	mov	x0, x19
-	mov	x1, x20
-	/*
-	 * We are ready for power down, fire off the suspend finisher
-	 * in x1, with argument in x0
-	 */
-	blr	x1
-        /*
-	 * Never gets here, unless suspend finisher fails.
-	 * Successful cpu_suspend should return from cpu_resume, returning
-	 * through this code path is considered an error
-	 * If the return value is set to 0 force x0 = -EOPNOTSUPP
-	 * to make sure a proper error condition is propagated
-	 */
-	cmp	x0, #0
-	mov	x3, #-EOPNOTSUPP
-	csel	x0, x3, x0, eq
-	add	sp, sp, #CPU_SUSPEND_SZ	// rewind stack pointer
-	ldp	x19, x20, [sp, #16]
-	ldp	x21, x22, [sp, #32]
-	ldp	x23, x24, [sp, #48]
-	ldp	x25, x26, [sp, #64]
-	ldp	x27, x28, [sp, #80]
-	ldp	x29, lr, [sp], #96
+	pop	x29, lr
+	mov	x0, #1
 	ret
 ENDPROC(__cpu_suspend_enter)
 	.ltorg
@@ -146,12 +116,6 @@ ENDPROC(cpu_resume_mmu)
 	.popsection
 cpu_resume_after_mmu:
 	mov	x0, #0			// return zero on success
-	ldp	x19, x20, [sp, #16]
-	ldp	x21, x22, [sp, #32]
-	ldp	x23, x24, [sp, #48]
-	ldp	x25, x26, [sp, #64]
-	ldp	x27, x28, [sp, #80]
-	ldp	x29, lr, [sp], #96
 	ret
 ENDPROC(cpu_resume_after_mmu)
 
@@ -168,6 +132,8 @@ ENTRY(cpu_resume)
         /* x7 contains hash index, let's use it to grab context pointer */
 	ldr_l	x0, sleep_save_sp + SLEEP_SAVE_SP_PHYS
 	ldr	x0, [x0, x7, lsl #3]
+	add	x29, x0, #SLEEP_STACK_DATA_CALLEE_REGS
+	add	x0, x0, #SLEEP_STACK_DATA_SYSTEM_REGS
 	/* load sp from context */
 	ldr	x2, [x0, #CPU_CTX_SP]
 	/* load physical address of identity map page table in x1 */
@@ -181,5 +147,12 @@ ENTRY(cpu_resume)
 	 * pointer and x1 to contain physical address of 1:1 page tables
 	 */
 	bl	cpu_do_resume		// PC relative jump, MMU off
+	/* Can't access these by physical address once the MMU is on */
+	ldp	x19, x20, [x29, #16]
+	ldp	x21, x22, [x29, #32]
+	ldp	x23, x24, [x29, #48]
+	ldp	x25, x26, [x29, #64]
+	ldp	x27, x28, [x29, #80]
+	ldp	x29, lr, [x29]
 	b	cpu_resume_mmu		// Resume MMU, never returns
 ENDPROC(cpu_resume)
diff --git a/arch/arm64/kernel/suspend.c b/arch/arm64/kernel/suspend.c
index 66055392f445..6fe46100685a 100644
--- a/arch/arm64/kernel/suspend.c
+++ b/arch/arm64/kernel/suspend.c
@@ -10,22 +10,22 @@
 #include <asm/suspend.h>
 #include <asm/tlbflush.h>
 
-extern int __cpu_suspend_enter(unsigned long arg, int (*fn)(unsigned long));
+
 /*
  * This is called by __cpu_suspend_enter() to save the state, and do whatever
  * flushing is required to ensure that when the CPU goes to sleep we have
  * the necessary data available when the caches are not searched.
  *
- * ptr: CPU context virtual address
+ * ptr: sleep_stack_data containing cpu state virtual address.
  * save_ptr: address of the location where the context physical address
  *           must be saved
  */
-void notrace __cpu_suspend_save(struct cpu_suspend_ctx *ptr,
+void notrace __cpu_suspend_save(struct sleep_stack_data *ptr,
 				phys_addr_t *save_ptr)
 {
 	*save_ptr = virt_to_phys(ptr);
 
-	cpu_do_suspend(ptr);
+	cpu_do_suspend(&ptr->system_regs);
 	/*
 	 * Only flush the context that must be retrieved with the MMU
 	 * off. VA primitives ensure the flush is applied to all
@@ -51,6 +51,30 @@ void __init cpu_suspend_set_dbg_restorer(void (*hw_bp_restore)(void *))
 	hw_breakpoint_restore = hw_bp_restore;
 }
 
+void notrace __cpu_suspend_exit(void)
+{
+	/*
+	 * We are resuming from reset with the idmap active in TTBR0_EL1.
+	 * We must uninstall the idmap and restore the expected MMU
+	 * state before we can possibly return to userspace.
+	 */
+	cpu_uninstall_idmap();
+
+	/*
+	 * Restore per-cpu offset before any kernel
+	 * subsystem relying on it has a chance to run.
+	 */
+	set_my_cpu_offset(per_cpu_offset(smp_processor_id()));
+
+	/*
+	 * Restore HW breakpoint registers to sane values
+	 * before debug exceptions are possibly reenabled
+	 * through local_dbg_restore.
+	 */
+	if (hw_breakpoint_restore)
+		hw_breakpoint_restore(NULL);
+}
+
 /*
  * cpu_suspend
  *
@@ -60,8 +84,9 @@ void __init cpu_suspend_set_dbg_restorer(void (*hw_bp_restore)(void *))
  */
 int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
 {
-	int ret;
+	int ret = 0;
 	unsigned long flags;
+	struct sleep_stack_data state;
 
 	/*
 	 * From this point debug exceptions are disabled to prevent
@@ -83,28 +108,21 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
 	 * page tables, so that the thread address space is properly
 	 * set-up on function return.
 	 */
-	ret = __cpu_suspend_enter(arg, fn);
-	if (ret == 0) {
-		/*
-		 * We are resuming from reset with the idmap active in TTBR0_EL1.
-		 * We must uninstall the idmap and restore the expected MMU
-		 * state before we can possibly return to userspace.
-		 */
-		cpu_uninstall_idmap();
-
-		/*
-		 * Restore per-cpu offset before any kernel
-		 * subsystem relying on it has a chance to run.
-		 */
-		set_my_cpu_offset(per_cpu_offset(smp_processor_id()));
+	if (__cpu_suspend_enter(&state)) {
+		/* Call the suspend finisher */
+		ret = fn(arg);
 
 		/*
-		 * Restore HW breakpoint registers to sane values
-		 * before debug exceptions are possibly reenabled
-		 * through local_dbg_restore.
+		 * Never gets here, unless the suspend finisher fails.
+		 * Successful cpu_suspend() should return from cpu_resume(),
+		 * returning through this code path is considered an error
+		 * If the return value is set to 0 force ret = -EOPNOTSUPP
+		 * to make sure a proper error condition is propagated
 		 */
-		if (hw_breakpoint_restore)
-			hw_breakpoint_restore(NULL);
+		if (!ret)
+			ret = -EOPNOTSUPP;
+	} else {
+		__cpu_suspend_exit();
 	}
 
 	unpause_graph_tracing();
-- 
2.6.2



From james.morse at arm.com  Tue Feb 16 07:49:20 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:20 +0000
Subject: [PATCH v5 08/15] arm64: kernel: Include _AC definition in page.h
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <1455637767-31561-9-git-send-email-james.morse@arm.com>

page.h uses '_AC' in the definition of PAGE_SIZE, but doesn't include
linux/const.h where this is defined. This produces build warnings when only
asm/page.h is included by asm code.

Signed-off-by: James Morse <james.morse at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm64/include/asm/page.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index ae615b9d9a55..17b45f7d96d3 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -19,6 +19,8 @@
 #ifndef __ASM_PAGE_H
 #define __ASM_PAGE_H
 
+#include <linux/const.h>
+
 /* PAGE_SHIFT determines the page size */
 /* CONT_SHIFT determines the number of pages which can be tracked together  */
 #ifdef CONFIG_ARM64_64K_PAGES
-- 
2.6.2



From james.morse at arm.com  Tue Feb 16 07:49:25 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:25 +0000
Subject: [PATCH v5 13/15] PM / Hibernate: Call flush_icache_range() on pages
 restored in-place
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <1455637767-31561-14-git-send-email-james.morse@arm.com>

Some architectures require code written to memory as if it were data to be
'cleaned' from any data caches before the processor can fetch them as new
instructions.

During resume from hibernate, the snapshot code copies some pages directly,
meaning these architectures do not get a chance to perform their cache
maintenance. Modify the read and decompress code to call
flush_icache_range() on all pages that are restored, so that the restored
in-place pages are guaranteed to be executable on these architectures.

Signed-off-by: James Morse <james.morse at arm.com>
Acked-by: Pavel Machek <pavel at ucw.cz>
---
 kernel/power/swap.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/kernel/power/swap.c b/kernel/power/swap.c
index 12cd989dadf6..a30645d2e93f 100644
--- a/kernel/power/swap.c
+++ b/kernel/power/swap.c
@@ -37,6 +37,14 @@
 #define HIBERNATE_SIG	"S1SUSPEND"
 
 /*
+ * When reading an {un,}compressed image, we may restore pages in place,
+ * in which case some architectures need these pages cleaning before they
+ * can be executed. We don't know which pages these may be, so clean the lot.
+ */
+bool clean_pages_on_read = false;
+bool clean_pages_on_decompress = false;
+
+/*
  *	The swap map is a data structure used for keeping track of each page
  *	written to a swap partition.  It consists of many swap_map_page
  *	structures that contain each an array of MAP_PAGE_ENTRIES swap entries.
@@ -241,6 +249,9 @@ static void hib_end_io(struct bio *bio)
 
 	if (bio_data_dir(bio) == WRITE)
 		put_page(page);
+	else if (clean_pages_on_read)
+		flush_icache_range((unsigned long)page_address(page),
+				   (unsigned long)page_address(page) + PAGE_SIZE);
 
 	if (bio->bi_error && !hb->error)
 		hb->error = bio->bi_error;
@@ -1049,6 +1060,7 @@ static int load_image(struct swap_map_handle *handle,
 
 	hib_init_batch(&hb);
 
+	clean_pages_on_read = true;
 	printk(KERN_INFO "PM: Loading image data pages (%u pages)...\n",
 		nr_to_read);
 	m = nr_to_read / 10;
@@ -1124,6 +1136,10 @@ static int lzo_decompress_threadfn(void *data)
 		d->unc_len = LZO_UNC_SIZE;
 		d->ret = lzo1x_decompress_safe(d->cmp + LZO_HEADER, d->cmp_len,
 		                               d->unc, &d->unc_len);
+		if (clean_pages_on_decompress)
+			flush_icache_range((unsigned long)d->unc,
+					   (unsigned long)d->unc + d->unc_len);
+
 		atomic_set(&d->stop, 1);
 		wake_up(&d->done);
 	}
@@ -1189,6 +1205,8 @@ static int load_image_lzo(struct swap_map_handle *handle,
 	}
 	memset(crc, 0, offsetof(struct crc_data, go));
 
+	clean_pages_on_decompress = true;
+
 	/*
 	 * Start the decompression threads.
 	 */
-- 
2.6.2



From james.morse at arm.com  Tue Feb 16 07:49:22 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:22 +0000
Subject: [PATCH v5 10/15] arm64: Add new asm macro copy_page
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <1455637767-31561-11-git-send-email-james.morse@arm.com>

From: Geoff Levand <geoff at infradead.org>

Kexec and hibernate need to copy pages of memory, but may not have all
of the kernel mapped, and are unable to call copy_page().

Add a simplistic copy_page() macro, that can be inlined in these
situations. lib/copy_page.S provides a bigger better version, but
uses more registers.

Signed-off-by: Geoff Levand <geoff at infradead.org>
[Changed asm label to 9998, added commit message]
Signed-off-by: James Morse <james.morse at arm.com>
---
This patch comes from v13 of kexec

 arch/arm64/include/asm/assembler.h | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index ec4e37cb3b41..f3854d9b5e31 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -24,6 +24,7 @@
 #define __ASM_ASSEMBLER_H
 
 #include <asm/asm-offsets.h>
+#include <asm/page.h>
 #include <asm/pgtable-hwdef.h>
 #include <asm/ptrace.h>
 #include <asm/thread_info.h>
@@ -285,6 +286,24 @@ lr	.req	x30		// link register
 	.endm
 
 /*
+ * copy_page - copy src to dest using temp registers t1-t8
+ */
+	.macro copy_page dest:req src:req t1:req t2:req t3:req t4:req t5:req t6:req t7:req t8:req
+9998:	ldp	\t1, \t2, [\src]
+	ldp	\t3, \t4, [\src, #16]
+	ldp	\t5, \t6, [\src, #32]
+	ldp	\t7, \t8, [\src, #48]
+	add	\src, \src, #64
+	stnp	\t1, \t2, [\dest]
+	stnp	\t3, \t4, [\dest, #16]
+	stnp	\t5, \t6, [\dest, #32]
+	stnp	\t7, \t8, [\dest, #48]
+	add	\dest, \dest, #64
+	tst	\src, #(PAGE_SIZE - 1)
+	b.ne	9998b
+	.endm
+
+/*
  * Annotate a function as position independent, i.e., safe to be called before
  * the kernel virtual mapping is activated.
  */
-- 
2.6.2



From james.morse at arm.com  Tue Feb 16 07:49:19 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:19 +0000
Subject: [PATCH v5 07/15] arm64: Change cpu_resume() to enable mmu early then
 access sleep_sp by va
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <1455637767-31561-8-git-send-email-james.morse@arm.com>

By enabling the MMU early in cpu_resume(), the sleep_save_sp and stack can
be accessed by VA, which avoids the need to convert-addresses and clean to
PoC on the suspend path.

MMU setup is shared with the boot path, meaning the swapper_pg_dir is
restored directly: ttbr1_el1 is no longer saved/restored.

struct sleep_save_sp is removed, replacing it with a single array of
pointers.

cpu_do_{suspend,resume} could be further reduced to not restore: cpacr_el1,
mdscr_el1, tcr_el1, vbar_el1 and sctlr_el1, all of which are set by
__cpu_setup(). However these values all contain res0 bits that may be used
to enable future features.

Signed-off-by: James Morse <james.morse at arm.com>
---
 arch/arm64/include/asm/suspend.h |  9 +++----
 arch/arm64/kernel/asm-offsets.c  |  3 ---
 arch/arm64/kernel/head.S         |  2 +-
 arch/arm64/kernel/setup.c        |  1 -
 arch/arm64/kernel/sleep.S        | 54 ++++++++++++++--------------------------
 arch/arm64/kernel/suspend.c      | 39 ++++++-----------------------
 arch/arm64/mm/proc.S             | 41 +++++++++++-------------------
 7 files changed, 45 insertions(+), 104 deletions(-)

diff --git a/arch/arm64/include/asm/suspend.h b/arch/arm64/include/asm/suspend.h
index 365d8cdd0073..29d3c71433e1 100644
--- a/arch/arm64/include/asm/suspend.h
+++ b/arch/arm64/include/asm/suspend.h
@@ -1,7 +1,7 @@
 #ifndef __ASM_SUSPEND_H
 #define __ASM_SUSPEND_H
 
-#define NR_CTX_REGS 11
+#define NR_CTX_REGS 10
 #define NR_CALLEE_SAVED_REGS 12
 
 /*
@@ -17,11 +17,6 @@ struct cpu_suspend_ctx {
 	u64 sp;
 } __aligned(16);
 
-struct sleep_save_sp {
-	phys_addr_t *save_ptr_stash;
-	phys_addr_t save_ptr_stash_phys;
-};
-
 /*
  * Memory to save the cpu state is allocated on the stack by
  * __cpu_suspend_enter()'s caller, and populated by __cpu_suspend_enter().
@@ -39,6 +34,8 @@ struct sleep_stack_data {
 	unsigned long		callee_saved_regs[NR_CALLEE_SAVED_REGS];
 };
 
+extern unsigned long *sleep_save_stash;
+
 extern int cpu_suspend(unsigned long arg, int (*fn)(unsigned long));
 extern void cpu_resume(void);
 int __cpu_suspend_enter(struct sleep_stack_data *state);
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 7d7994774e82..d6119c57f28a 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -120,9 +120,6 @@ int main(void)
   DEFINE(CPU_CTX_SP,		offsetof(struct cpu_suspend_ctx, sp));
   DEFINE(MPIDR_HASH_MASK,	offsetof(struct mpidr_hash, mask));
   DEFINE(MPIDR_HASH_SHIFTS,	offsetof(struct mpidr_hash, shift_aff));
-  DEFINE(SLEEP_SAVE_SP_SZ,	sizeof(struct sleep_save_sp));
-  DEFINE(SLEEP_SAVE_SP_PHYS,	offsetof(struct sleep_save_sp, save_ptr_stash_phys));
-  DEFINE(SLEEP_SAVE_SP_VIRT,	offsetof(struct sleep_save_sp, save_ptr_stash));
   DEFINE(SLEEP_STACK_DATA_SYSTEM_REGS,	offsetof(struct sleep_stack_data, system_regs));
   DEFINE(SLEEP_STACK_DATA_CALLEE_REGS,	offsetof(struct sleep_stack_data, callee_saved_regs));
 #endif
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 05b98289093e..6fad2f814ecf 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -636,7 +636,7 @@ ENDPROC(__secondary_switched)
  * If it isn't, park the CPU
  */
 	.section	".idmap.text", "ax"
-__enable_mmu:
+ENTRY(__enable_mmu)
 	mrs	x1, ID_AA64MMFR0_EL1
 	ubfx	x2, x1, #ID_AA64MMFR0_TGRAN_SHIFT, 4
 	cmp	x2, #ID_AA64MMFR0_TGRAN_SUPPORTED
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index cfed56f0ad26..ad290601f4da 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -175,7 +175,6 @@ static void __init smp_build_mpidr_hash(void)
 	 */
 	if (mpidr_hash_size() > 4 * num_possible_cpus())
 		pr_warn("Large number of MPIDR hash buckets detected\n");
-	__flush_dcache_area(&mpidr_hash, sizeof(struct mpidr_hash));
 }
 
 static void __init setup_machine_fdt(phys_addr_t dt_phys)
diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
index dca81612fe90..0e2b36f1fb44 100644
--- a/arch/arm64/kernel/sleep.S
+++ b/arch/arm64/kernel/sleep.S
@@ -73,8 +73,8 @@ ENTRY(__cpu_suspend_enter)
 	str	x2, [x0, #SLEEP_STACK_DATA_SYSTEM_REGS + CPU_CTX_SP]
 
 	/* find the mpidr_hash */
-	ldr	x1, =sleep_save_sp
-	ldr	x1, [x1, #SLEEP_SAVE_SP_VIRT]
+	ldr	x1, =sleep_save_stash
+	ldr	x1, [x1]
 	mrs	x7, mpidr_el1
 	ldr	x9, =mpidr_hash
 	ldr	x10, [x9, #MPIDR_HASH_MASK]
@@ -87,40 +87,26 @@ ENTRY(__cpu_suspend_enter)
 	compute_mpidr_hash x8, x3, x4, x5, x6, x7, x10
 	add	x1, x1, x8, lsl #3
 
+	str	x0, [x1]
+	add	x0, x0, #SLEEP_STACK_DATA_SYSTEM_REGS
 	push	x29, lr
-	bl	__cpu_suspend_save
+	bl	cpu_do_suspend
 	pop	x29, lr
 	mov	x0, #1
 	ret
 ENDPROC(__cpu_suspend_enter)
 	.ltorg
 
-/*
- * x0 must contain the sctlr value retrieved from restored context
- */
-	.pushsection	".idmap.text", "ax"
-ENTRY(cpu_resume_mmu)
-	ldr	x3, =cpu_resume_after_mmu
-	msr	sctlr_el1, x0		// restore sctlr_el1
-	isb
-	/*
-	 * Invalidate the local I-cache so that any instructions fetched
-	 * speculatively from the PoC are discarded, since they may have
-	 * been dynamically patched at the PoU.
-	 */
-	ic	iallu
-	dsb	nsh
-	isb
-	br	x3			// global jump to virtual address
-ENDPROC(cpu_resume_mmu)
-	.popsection
-cpu_resume_after_mmu:
-	mov	x0, #0			// return zero on success
-	ret
-ENDPROC(cpu_resume_after_mmu)
-
 ENTRY(cpu_resume)
 	bl	el2_setup		// if in EL2 drop to EL1 cleanly
+	/* enable the MMU early - so we can access sleep_save_stash by va */
+	adr_l	lr, __enable_mmu	/* __cpu_setup will return here */
+	ldr	x27, =_cpu_resume	/* __enable_mmu will branch here */
+	adrp	x25, idmap_pg_dir
+	adrp	x26, swapper_pg_dir
+	b	__cpu_setup
+
+ENTRY(_cpu_resume)
 	mrs	x1, mpidr_el1
 	adrp	x8, mpidr_hash
 	add x8, x8, #:lo12:mpidr_hash // x8 = struct mpidr_hash phys address
@@ -130,29 +116,27 @@ ENTRY(cpu_resume)
 	ldp	w5, w6, [x8, #(MPIDR_HASH_SHIFTS + 8)]
 	compute_mpidr_hash x7, x3, x4, x5, x6, x1, x2
         /* x7 contains hash index, let's use it to grab context pointer */
-	ldr_l	x0, sleep_save_sp + SLEEP_SAVE_SP_PHYS
+	ldr_l	x0, sleep_save_stash
 	ldr	x0, [x0, x7, lsl #3]
 	add	x29, x0, #SLEEP_STACK_DATA_CALLEE_REGS
 	add	x0, x0, #SLEEP_STACK_DATA_SYSTEM_REGS
 	/* load sp from context */
 	ldr	x2, [x0, #CPU_CTX_SP]
-	/* load physical address of identity map page table in x1 */
-	adrp	x1, idmap_pg_dir
 	mov	sp, x2
 	/* save thread_info */
 	and	x2, x2, #~(THREAD_SIZE - 1)
 	msr	sp_el0, x2
 	/*
-	 * cpu_do_resume expects x0 to contain context physical address
-	 * pointer and x1 to contain physical address of 1:1 page tables
+	 * cpu_do_resume expects x0 to contain context address pointer
 	 */
-	bl	cpu_do_resume		// PC relative jump, MMU off
-	/* Can't access these by physical address once the MMU is on */
+	bl	cpu_do_resume
+
 	ldp	x19, x20, [x29, #16]
 	ldp	x21, x22, [x29, #32]
 	ldp	x23, x24, [x29, #48]
 	ldp	x25, x26, [x29, #64]
 	ldp	x27, x28, [x29, #80]
 	ldp	x29, lr, [x29]
-	b	cpu_resume_mmu		// Resume MMU, never returns
+	mov	x0, #0
+	ret
 ENDPROC(cpu_resume)
diff --git a/arch/arm64/kernel/suspend.c b/arch/arm64/kernel/suspend.c
index 6fe46100685a..2ec2f94d1690 100644
--- a/arch/arm64/kernel/suspend.c
+++ b/arch/arm64/kernel/suspend.c
@@ -10,30 +10,12 @@
 #include <asm/suspend.h>
 #include <asm/tlbflush.h>
 
-
 /*
- * This is called by __cpu_suspend_enter() to save the state, and do whatever
- * flushing is required to ensure that when the CPU goes to sleep we have
- * the necessary data available when the caches are not searched.
- *
- * ptr: sleep_stack_data containing cpu state virtual address.
- * save_ptr: address of the location where the context physical address
- *           must be saved
+ * This is allocate by cpu_suspend_init(), and used in cpuidle to store a
+ * pointer to the 'struct sleep_stack_data' the contains a particular CPUs
+ * state.
  */
-void notrace __cpu_suspend_save(struct sleep_stack_data *ptr,
-				phys_addr_t *save_ptr)
-{
-	*save_ptr = virt_to_phys(ptr);
-
-	cpu_do_suspend(&ptr->system_regs);
-	/*
-	 * Only flush the context that must be retrieved with the MMU
-	 * off. VA primitives ensure the flush is applied to all
-	 * cache levels so context is pushed to DRAM.
-	 */
-	__flush_dcache_area(ptr, sizeof(*ptr));
-	__flush_dcache_area(save_ptr, sizeof(*save_ptr));
-}
+unsigned long *sleep_save_stash;
 
 /*
  * This hook is provided so that cpu_suspend code can restore HW
@@ -137,22 +119,15 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
 	return ret;
 }
 
-struct sleep_save_sp sleep_save_sp;
-
 static int __init cpu_suspend_init(void)
 {
-	void *ctx_ptr;
-
 	/* ctx_ptr is an array of physical addresses */
-	ctx_ptr = kcalloc(mpidr_hash_size(), sizeof(phys_addr_t), GFP_KERNEL);
+	sleep_save_stash = kcalloc(mpidr_hash_size(), sizeof(*sleep_save_stash),
+				   GFP_KERNEL);
 
-	if (WARN_ON(!ctx_ptr))
+	if (WARN_ON(!sleep_save_stash))
 		return -ENOMEM;
 
-	sleep_save_sp.save_ptr_stash = ctx_ptr;
-	sleep_save_sp.save_ptr_stash_phys = virt_to_phys(ctx_ptr);
-	__flush_dcache_area(&sleep_save_sp, sizeof(struct sleep_save_sp));
-
 	return 0;
 }
 early_initcall(cpu_suspend_init);
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index db832c42ae30..a2ef1256a329 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -24,6 +24,7 @@
 #include <asm/asm-offsets.h>
 #include <asm/hwcap.h>
 #include <asm/pgtable.h>
+#include <asm/pgtable-hwdef.h>
 
 #ifdef CONFIG_ARM64_64K_PAGES
 #define TCR_TG_FLAGS	TCR_TG0_64K | TCR_TG1_64K
@@ -61,62 +62,50 @@ ENTRY(cpu_do_suspend)
 	mrs	x2, tpidr_el0
 	mrs	x3, tpidrro_el0
 	mrs	x4, contextidr_el1
-	mrs	x5, mair_el1
 	mrs	x6, cpacr_el1
-	mrs	x7, ttbr1_el1
 	mrs	x8, tcr_el1
 	mrs	x9, vbar_el1
 	mrs	x10, mdscr_el1
 	mrs	x11, oslsr_el1
 	mrs	x12, sctlr_el1
 	stp	x2, x3, [x0]
-	stp	x4, x5, [x0, #16]
-	stp	x6, x7, [x0, #32]
-	stp	x8, x9, [x0, #48]
-	stp	x10, x11, [x0, #64]
-	str	x12, [x0, #80]
+	stp	x4, xzr, [x0, #16]
+	stp	x6, x8, [x0, #32]
+	stp	x9, x10, [x0, #48]
+	stp	x11, x12, [x0, #64]
 	ret
 ENDPROC(cpu_do_suspend)
 
 /**
  * cpu_do_resume - restore CPU register context
  *
- * x0: Physical address of context pointer
- * x1: ttbr0_el1 to be restored
- *
- * Returns:
- *	sctlr_el1 value in x0
+ * x0: Address of context pointer
  */
 ENTRY(cpu_do_resume)
-	/*
-	 * Invalidate local tlb entries before turning on MMU
-	 */
-	tlbi	vmalle1
 	ldp	x2, x3, [x0]
 	ldp	x4, x5, [x0, #16]
-	ldp	x6, x7, [x0, #32]
-	ldp	x8, x9, [x0, #48]
-	ldp	x10, x11, [x0, #64]
-	ldr	x12, [x0, #80]
+	ldp	x6, x8, [x0, #32]
+	ldp	x9, x10, [x0, #48]
+	ldp	x11, x12, [x0, #64]
 	msr	tpidr_el0, x2
 	msr	tpidrro_el0, x3
 	msr	contextidr_el1, x4
-	msr	mair_el1, x5
 	msr	cpacr_el1, x6
-	msr	ttbr0_el1, x1
-	msr	ttbr1_el1, x7
-	tcr_set_idmap_t0sz x8, x7
+
+	/* Don't change t0sz here, mask those bits when restoring */
+	mrs	x5, tcr_el1
+	bfi	x8, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH
+
 	msr	tcr_el1, x8
 	msr	vbar_el1, x9
 	msr	mdscr_el1, x10
+	msr	sctlr_el1, x12
 	/*
 	 * Restore oslsr_el1 by writing oslar_el1
 	 */
 	ubfx	x11, x11, #1, #1
 	msr	oslar_el1, x11
 	reset_pmuserenr_el0 x0			// Disable PMU access from EL0
-	mov	x0, x12
-	dsb	nsh		// Make sure local tlb invalidation completed
 	isb
 	ret
 ENDPROC(cpu_do_resume)
-- 
2.6.2



From james.morse at arm.com  Tue Feb 16 07:49:27 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:27 +0000
Subject: [PATCH v5 15/15] arm64: hibernate: Prevent resume from a different
 kernel version
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <1455637767-31561-16-git-send-email-james.morse@arm.com>

Resuming using a different kernel version is fragile, while there are
sufficient details in the hibernate arch-header to perform the restore,
changes in the boot process can have a long-lasting impact on the system.
In particular, if the EFI stub causes more memory to be allocated, the
amount of memory left for linux is reduced. If we are lucky, this will
cause restore to fail with the message:
> PM: Image mismatch: memory size
If we are unlucky, the system will explode sometime later when an EFI
runtime services call is made.

Prevent resuming with a different kernel version, by making
HIBERNATE_VERSION the current kernel version.

Signed-off-by: James Morse <james.morse at arm.com>
---
 arch/arm64/kernel/hibernate.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index fd2faca358f6..99ebdbb06e85 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -56,14 +56,9 @@ extern int in_suspend;
 
 /*
  * This value is written to the hibernate arch header, and prevents resuming
- * from a hibernate image produced by an incompatible kernel. If you change
- * a value that isn't saved/restored by hibernate, you should change this value.
- *
- * For example, if the mair_el1 values used by the kernel are changed, you
- * should prevent resuming from a kernel with incompatible attributes, as these
- * aren't saved/restored.
+ * from a hibernate image produced by a different kernel version.
  */
-#define HIBERNATE_VERSION	KERNEL_VERSION(4, 6, 0)
+#define HIBERNATE_VERSION	LINUX_VERSION_CODE
 
 /*
  * Start/end of the hibernate exit code, this must be copied to a 'safe'
-- 
2.6.2



From linus.walleij at linaro.org  Tue Feb 16 07:51:57 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 16 Feb 2016 16:51:57 +0100
Subject: [PATCH 3/4] gpio: ep93xx: remove private irq_to_gpio function
In-Reply-To: <1455551208-2825510-4-git-send-email-arnd@arndb.de>
References: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <1455551208-2825510-1-git-send-email-arnd@arndb.de>
 <1455551208-2825510-4-git-send-email-arnd@arndb.de>
Message-ID: <CACRpkdb3nKTEDCvafURhKRPJipJ=K_y1oyE_kKc=-T8E=Bai0g@mail.gmail.com>

On Mon, Feb 15, 2016 at 4:46 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> The ep93xx goes through its own back-and-forth dance every time
> it wants to know the gpio number for an irq line, when it really
> just hardcodes a fixed offset in ep93xx_gpio_to_irq().
>
> This removes the pointless macro and replaces the conversion inside
> of the driver with simple add/subtract operations, using an
> explicit macro.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
(...)

> -#include <linux/gpio/driver.h>
> -/* FIXME: this is here for gpio_to_irq() - get rid of this! */
>  #include <linux/gpio.h>

No, what you want to get rid of is the #include <linux/gpio.h> not the
<linux/gpio/driver.h>, we want to be more specific. Sorry for putting the
comment wrong.

> @@ -35,6 +31,7 @@ void __iomem *ep93xx_gpio_base; /* FIXME: put this into irq_data */
>  #define EP93XX_GPIO_LINE_MAX           63
>
>  /* maximum value for irq capable line identifiers */
> +#define EP93XX_GPIO_IRQ_BASE           64
>  #define EP93XX_GPIO_LINE_MAX_IRQ       23

This doesn't apply to my tree :O

My EP93XX_GPIO_LINE_MAX_IRQ is in
arch/arm/mach-ep93xx/include/mach/gpio-ep93xx.h

So I think you must be having another patch somewhere in the ARM SoC
tree. (I can take it, just send it along with an update of this one.)

Yours,
Linus Walleij


From james.morse at arm.com  Tue Feb 16 07:49:12 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:12 +0000
Subject: [PATCH v5 00/15] arm64: kernel: Add support for
 hibernate/suspend-to-disk
Message-ID: <1455637767-31561-1-git-send-email-james.morse@arm.com>

Hi all,

This version of hibernate is based on v4.5-rc4, with the contents of the arm64
for-next/pgtable branch and Ard's v6sub1 "arm64: split linear and kernel
mappings" series [0]. The patches shared with kexec still come from v13 [1].

I've renumbered the labels in patch 4, per Akashi Takahiro's suggestion.
Parts of patch 5 were reworked from Akashi Takahiro's original version, to
avoid another round of changes to hyp-entry.S:el1_sync.

Resume from hibernate now uses el2_setup() to re-configure el2. This means we
don't assume the old kernel's versions are valid. (Thanks to Lorenzo for the
suggestion). Patches 11 and 12 are needed to support this.

The enable/disable fiq calls have been removed, these were blindly copied
from arch/arm, but aren't needed for arch/arm64.

The explicit call to kvm_arch_hardware_disable() is gone, as patch 5's
hyp_init_cpu_pm_notifier() call will do this for us.

The resume code gained an 'in_suspend = 0'. The hibernate core code has this
as a __no_save variable, and expects it to keep its initial value. When we
have KASLR, or resume with a different kernel version, it gets a random
value from memory instead. x86_64 sets the variable explicitly like this too.


Resuming with a different kernel version, (but one with the same page size
and va bits), does work up until patch 15, which forbids it. Given how
fragile it is if uefi allocates memory in different places, and how hard it
would be to debug, I don't think its worth it, but it would be good to hear
others opinions!

This series can be retrieved from:
git://linux-arm.org/linux-jm.git -b hibernate/v5


Changes since v4:
 * Mask in current T0SZ bits when restoring tcr_el1.
 * Use el2_setup() to reconfigure el2.
 * Remove fiq calls.
 * Removed kvm_arch_hardware_disable() call.
 * Added 'in_suspend = 0' to avoid 'if (uninitialised-memory) ...'.
 * Removed icache-flush from hibernate-asm.S, this was done in hibernate.c.
 * Commented tlbis.
 * Removed dsb after copy_page(), this behaviour is guaranteed by the
   architecture.

Changes since v3:
 * To work with kaslr:
   * hibernate now uses the arch-header to store the address of the page
     tables, and the point to re-enter the resumed kernel.
   * The el2 vectors are reloaded to point to the 'safe' page, then back to the
     resumed kernel.
   * PoC cleaning is done after the jump to the resumed kernel, as we don't
     know the restored kernel's boundaries in advance.
   * Some variables are accessed via aliases in the linear map, as the kernel
     text is not mapped during resume. restore_pblist is one example.
   * Execute the safe page from the bottom of memory, not the top, so that we
     can restore the resumed kernel's page tables directly.

 * Rebased the common patches onto v13 of kexec
 * Changed hibernate-asm.S to use the new copy_page macro.
 * Changed copy_p?d()s to use the do { } while(); pattern.
 * Added some missing barriers. (dsb after ic ialluis).

Changes since v2:
 * Rewrote restore in-place patch - we can't clean pages in copy_page(), we
   need to publish a list for the architecture to clean
 * Added missing pgprot_val() in hibernate.c, spotted by STRICT_MM_TYPECHECKS
 * Removed 'tcr_set_idmap_t0sz' from proc.S - I missed this when rebase-ing
 * Re-imported the first four patches from kexec v12
 * Rebased onto v4.4-rc2
 * Changes from Pavel Machek's comments

Changes since v1:
 * Removed for_each_process(){ for_each_vma() { } }; cache cleaning, replaced
   with icache_flush_range() call in core hibernate code
 * Rebased onto conflicting tcr_ek1.t0sz bug-fix patch


[v4] http://www.spinics.net/lists/arm-kernel/msg477769.html
[v3] http://www.spinics.net/lists/arm-kernel/msg463590.html
[v2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/376450.html
[v1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/376450.html

[0] http://www.spinics.net/lists/arm-kernel/msg483446.html
[1] http://www.spinics.net/lists/arm-kernel/msg474889.html

AKASHI Takahiro (1):
  arm64: kvm: allows kvm cpu hotplug

Geoff Levand (5):
  arm64: Fold proc-macros.S into assembler.h
  arm64: Cleanup SCTLR flags
  arm64: Convert hcalls to use HVC immediate value
  arm64: Add new hcall HVC_CALL_FUNC
  arm64: Add new asm macro copy_page

James Morse (9):
  arm64: kernel: Rework finisher callback out of __cpu_suspend_enter().
  arm64: Change cpu_resume() to enable mmu early then access sleep_sp by va
  arm64: kernel: Include _AC definition in page.h
  arm64: Promote KERNEL_START/KERNEL_END definitions to a header file
  arm64: head.S: Change the register el2_setup() returns its result in x0
  arm64: head.S: el2_setup() to accept sctlr_el1 as an argument
  PM / Hibernate: Call flush_icache_range() on pages restored in-place
  arm64: kernel: Add support for hibernate/suspend-to-disk
  arm64: hibernate: Prevent resume from a different kernel version

 arch/arm/include/asm/kvm_host.h    |  10 +-
 arch/arm/include/asm/kvm_mmu.h     |   1 +
 arch/arm/kvm/arm.c                 |  98 +++++---
 arch/arm/kvm/mmu.c                 |   5 +
 arch/arm64/Kconfig                 |   7 +
 arch/arm64/include/asm/assembler.h | 110 ++++++++-
 arch/arm64/include/asm/kvm_arm.h   |  11 -
 arch/arm64/include/asm/kvm_host.h  |   1 -
 arch/arm64/include/asm/kvm_mmu.h   |  20 ++
 arch/arm64/include/asm/memory.h    |   3 +
 arch/arm64/include/asm/page.h      |   2 +
 arch/arm64/include/asm/processor.h |   2 +
 arch/arm64/include/asm/suspend.h   |  35 ++-
 arch/arm64/include/asm/sysreg.h    |  19 +-
 arch/arm64/include/asm/virt.h      |  40 ++++
 arch/arm64/kernel/Makefile         |   1 +
 arch/arm64/kernel/asm-offsets.c    |  10 +-
 arch/arm64/kernel/head.S           |  42 ++--
 arch/arm64/kernel/hibernate-asm.S  | 149 ++++++++++++
 arch/arm64/kernel/hibernate.c      | 477 +++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/hyp-stub.S       |  49 ++--
 arch/arm64/kernel/setup.c          |   1 -
 arch/arm64/kernel/sleep.S          | 146 ++++--------
 arch/arm64/kernel/suspend.c        |  97 ++++----
 arch/arm64/kernel/vmlinux.lds.S    |  15 ++
 arch/arm64/kvm/hyp-init.S          |  47 +++-
 arch/arm64/kvm/hyp.S               |   3 +-
 arch/arm64/kvm/hyp/hyp-entry.S     |   9 +-
 arch/arm64/mm/cache.S              |   2 -
 arch/arm64/mm/proc-macros.S        |  98 --------
 arch/arm64/mm/proc.S               |  44 ++--
 kernel/power/swap.c                |  18 ++
 32 files changed, 1193 insertions(+), 379 deletions(-)
 create mode 100644 arch/arm64/kernel/hibernate-asm.S
 create mode 100644 arch/arm64/kernel/hibernate.c
 delete mode 100644 arch/arm64/mm/proc-macros.S

-- 
2.6.2



From james.morse at arm.com  Tue Feb 16 07:49:24 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:24 +0000
Subject: [PATCH v5 12/15] arm64: head.S: el2_setup() to accept sctlr_el1 as an
 argument
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <1455637767-31561-13-git-send-email-james.morse@arm.com>

el2_setup() doesn't just configure el2, it configures el1 too. This
means we can't use it to re-configure el2 after resume from hibernate,
as we will be returned to el1 with the MMU turned off.

Split the sctlr_el1 setting code up, so that el2_setup() accepts an
initial value as an argument. This value will be ignored if el2_setup()
is called at el1: the running value will be preserved with endian
correction.

Hibernate can now call el2_setup() to re-configure el2, passing the
current sctlr_el1 as an argument.

Signed-off-by: James Morse <james.morse at arm.com>
---
 arch/arm64/include/asm/assembler.h |  9 +++++++++
 arch/arm64/include/asm/processor.h |  2 +-
 arch/arm64/kernel/head.S           | 19 ++++++++++++-------
 arch/arm64/kernel/sleep.S          |  1 +
 4 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index f3854d9b5e31..9a4746302d8d 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -304,6 +304,15 @@ lr	.req	x30		// link register
 	.endm
 
 /*
+ * Generate the initial sctlr_el1 value for el2_setup to set if we boot at EL2.
+ */
+	.macro init_sctlr_el1 reg
+		mov	\reg, #0x0800		// Set/clear RES{1,0} bits
+CPU_BE(		movk	\reg, #0x33d0, lsl #16)	// Set EE and E0E on BE systems
+CPU_LE(		movk	\reg, #0x30d0, lsl #16)	// Clear EE and E0E on LE systems
+	.endm
+
+/*
  * Annotate a function as position independent, i.e., safe to be called before
  * the kernel virtual mapping is activated.
  */
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 07ac4351538e..8973715e582e 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -188,6 +188,6 @@ static inline void spin_lock_prefetch(const void *x)
 
 void cpu_enable_pan(void *__unused);
 
-int el2_setup(void);
+int el2_setup(unsigned long init_sctlr_el1);
 
 #endif /* __ASM_PROCESSOR_H */
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 5894c7e91e6b..4926093461e9 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -206,6 +206,7 @@ section_table:
 
 ENTRY(stext)
 	bl	preserve_boot_args
+	init_sctlr_el1	x0
 	bl	el2_setup			// Drop to EL1, w0=cpu_boot_mode
 	adrp	x24, __PHYS_OFFSET
 	bl	set_cpu_boot_mode_flag
@@ -448,8 +449,12 @@ ENDPROC(__mmap_switched)
  *
  * Returns either BOOT_CPU_MODE_EL1 or BOOT_CPU_MODE_EL2 if booted in
  * EL1 or EL2 respectively.
+ *
+ * If booted in EL2, SCTLR_EL1 will be initialised with the value in x0
+ * (otherwise the existing value will be preserved, with endian correction).
  */
 ENTRY(el2_setup)
+	mov	x1, x0				// preserve passed-in sctlr_el1
 	mrs	x0, CurrentEL
 	cmp	x0, #CurrentEL_EL2
 	b.ne	1f
@@ -458,7 +463,7 @@ CPU_BE(	orr	x0, x0, #(1 << 25)	)	// Set the EE bit for EL2
 CPU_LE(	bic	x0, x0, #(1 << 25)	)	// Clear the EE bit for EL2
 	msr	sctlr_el2, x0
 	b	2f
-1:	mrs	x0, sctlr_el1
+1:	mrs	x0, sctlr_el1			// ignore passed-in sctlr_el1
 CPU_BE(	orr	x0, x0, #(3 << 24)	)	// Set the EE and E0E bits for EL1
 CPU_LE(	bic	x0, x0, #(3 << 24)	)	// Clear the EE and E0E bits for EL1
 	msr	sctlr_el1, x0
@@ -494,6 +499,10 @@ CPU_LE(	bic	x0, x0, #(3 << 24)	)	// Clear the EE and E0E bits for EL1
 
 3:
 #endif
+	/* use sctlr_el1 value we were provided with */
+CPU_BE(	orr	x1, x1, #(3 << 24)	)	// Set the EE and E0E bits for EL1
+CPU_LE(	bic	x1, x1, #(3 << 24)	)	// Clear the EE and E0E bits for EL1
+	msr	sctlr_el1, x1
 
 	/* Populate ID registers. */
 	mrs	x0, midr_el1
@@ -501,12 +510,6 @@ CPU_LE(	bic	x0, x0, #(3 << 24)	)	// Clear the EE and E0E bits for EL1
 	msr	vpidr_el2, x0
 	msr	vmpidr_el2, x1
 
-	/* sctlr_el1 */
-	mov	x0, #0x0800			// Set/clear RES{1,0} bits
-CPU_BE(	movk	x0, #0x33d0, lsl #16	)	// Set EE and E0E on BE systems
-CPU_LE(	movk	x0, #0x30d0, lsl #16	)	// Clear EE and E0E on LE systems
-	msr	sctlr_el1, x0
-
 	/* Coprocessor traps. */
 	mov	x0, #0x33ff
 	msr	cptr_el2, x0			// Disable copro. traps to EL2
@@ -576,6 +579,7 @@ ENTRY(__boot_cpu_mode)
 	 * cores are held until we're ready for them to initialise.
 	 */
 ENTRY(secondary_holding_pen)
+	init_sctlr_el1	x0
 	bl	el2_setup			// Drop to EL1, w0=cpu_boot_mode
 	bl	set_cpu_boot_mode_flag
 	mrs	x0, mpidr_el1
@@ -594,6 +598,7 @@ ENDPROC(secondary_holding_pen)
 	 * be used where CPUs are brought online dynamically by the kernel.
 	 */
 ENTRY(secondary_entry)
+	init_sctlr_el1	x0
 	bl	el2_setup			// Drop to EL1
 	bl	set_cpu_boot_mode_flag
 	b	secondary_startup
diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
index 0e2b36f1fb44..5c66252d2b9f 100644
--- a/arch/arm64/kernel/sleep.S
+++ b/arch/arm64/kernel/sleep.S
@@ -98,6 +98,7 @@ ENDPROC(__cpu_suspend_enter)
 	.ltorg
 
 ENTRY(cpu_resume)
+	init_sctlr_el1	x0
 	bl	el2_setup		// if in EL2 drop to EL1 cleanly
 	/* enable the MMU early - so we can access sleep_save_stash by va */
 	adr_l	lr, __enable_mmu	/* __cpu_setup will return here */
-- 
2.6.2



From james.morse at arm.com  Tue Feb 16 07:49:26 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:26 +0000
Subject: [PATCH v5 14/15] arm64: kernel: Add support for
 hibernate/suspend-to-disk
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <1455637767-31561-15-git-send-email-james.morse@arm.com>

Add support for hibernate/suspend-to-disk.

Suspend borrows code from cpu_suspend() to write cpu state onto the stack,
before calling swsusp_save() to save the memory image.

Restore creates a set of temporary page tables, covering only the
linear map, copies the restore code to a 'safe' page, then uses the copy to
restore the memory image. The copied code executes in the lower half of the
address space, and once complete, restores the original kernel's page
tables. It then calls into cpu_resume(), and follows the normal
cpu_suspend() path back into the suspend code.

To restore a kernel using KASLR, the address of the page tables, and
cpu_resume() are stored in the hibernate arch-header and the el2
vectors are pivotted via the 'safe' page in low memory. This also permits
us to resume using a different version of the kernel to the version that
hibernated, but because the MMU isn't turned off during resume, the
MMU settings must be the same between both kernels. To ensure this, the
value of the translation control register (TCR_EL1) is also included in the
hibernate arch-header, this means your resume kernel must have the same
page size, and virtual address space size.

Signed-off-by: James Morse <james.morse at arm.com>
Tested-by: Kevin Hilman <khilman at baylibre.com> # Tested on Juno R2
---
 arch/arm64/Kconfig                |   7 +
 arch/arm64/include/asm/suspend.h  |  10 +
 arch/arm64/kernel/Makefile        |   1 +
 arch/arm64/kernel/asm-offsets.c   |   5 +
 arch/arm64/kernel/hibernate-asm.S | 149 ++++++++++++
 arch/arm64/kernel/hibernate.c     | 482 ++++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/vmlinux.lds.S   |  15 ++
 7 files changed, 669 insertions(+)
 create mode 100644 arch/arm64/kernel/hibernate-asm.S
 create mode 100644 arch/arm64/kernel/hibernate.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index cd767fa3037a..d2098e6261a9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -839,6 +839,13 @@ menu "Power management options"
 
 source "kernel/power/Kconfig"
 
+config ARCH_HIBERNATION_POSSIBLE
+	def_bool y
+
+config ARCH_HIBERNATION_HEADER
+	def_bool y
+	depends on HIBERNATION
+
 config ARCH_SUSPEND_POSSIBLE
 	def_bool y
 
diff --git a/arch/arm64/include/asm/suspend.h b/arch/arm64/include/asm/suspend.h
index 29d3c71433e1..4b4c23ad542b 100644
--- a/arch/arm64/include/asm/suspend.h
+++ b/arch/arm64/include/asm/suspend.h
@@ -40,4 +40,14 @@ extern int cpu_suspend(unsigned long arg, int (*fn)(unsigned long));
 extern void cpu_resume(void);
 int __cpu_suspend_enter(struct sleep_stack_data *state);
 void __cpu_suspend_exit(void);
+void _cpu_resume(void);
+
+int swsusp_arch_suspend(void);
+int swsusp_arch_resume(void);
+int arch_hibernation_header_save(void *addr, unsigned int max_size);
+int arch_hibernation_header_restore(void *addr);
+
+/* Perform calling convention fixups for el2_setup() */
+int swsusp_el2_setup_helper(phys_addr_t el2_setup_pa);
+
 #endif
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 83cd7e68e83b..09f7da0f2cf9 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -42,6 +42,7 @@ arm64-obj-$(CONFIG_PCI)			+= pci.o
 arm64-obj-$(CONFIG_ARMV8_DEPRECATED)	+= armv8_deprecated.o
 arm64-obj-$(CONFIG_ACPI)		+= acpi.o
 arm64-obj-$(CONFIG_PARAVIRT)		+= paravirt.o
+arm64-obj-$(CONFIG_HIBERNATION)		+= hibernate.o hibernate-asm.o
 
 obj-y					+= $(arm64-obj-y) vdso/
 obj-m					+= $(arm64-obj-m)
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index d6119c57f28a..2ac2789fda49 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -22,6 +22,7 @@
 #include <linux/mm.h>
 #include <linux/dma-mapping.h>
 #include <linux/kvm_host.h>
+#include <linux/suspend.h>
 #include <asm/thread_info.h>
 #include <asm/memory.h>
 #include <asm/smp_plat.h>
@@ -125,5 +126,9 @@ int main(void)
 #endif
   DEFINE(ARM_SMCCC_RES_X0_OFFS,	offsetof(struct arm_smccc_res, a0));
   DEFINE(ARM_SMCCC_RES_X2_OFFS,	offsetof(struct arm_smccc_res, a2));
+  BLANK();
+  DEFINE(HIBERN_PBE_ORIG,	offsetof(struct pbe, orig_address));
+  DEFINE(HIBERN_PBE_ADDR,	offsetof(struct pbe, address));
+  DEFINE(HIBERN_PBE_NEXT,	offsetof(struct pbe, next));
   return 0;
 }
diff --git a/arch/arm64/kernel/hibernate-asm.S b/arch/arm64/kernel/hibernate-asm.S
new file mode 100644
index 000000000000..220e6e20b9a3
--- /dev/null
+++ b/arch/arm64/kernel/hibernate-asm.S
@@ -0,0 +1,149 @@
+#include <linux/linkage.h>
+#include <linux/errno.h>
+
+#include <asm/asm-offsets.h>
+#include <asm/assembler.h>
+#include <asm/cputype.h>
+#include <asm/memory.h>
+#include <asm/page.h>
+#include <asm/virt.h>
+
+/*
+ * Corrupt memory.
+ *
+ * Loads temporary page tables then restores the memory image.
+ * Finally branches to cpu_resume() to restore the state saved by
+ * swsusp_arch_suspend().
+ *
+ * Because this code has to be copied to a safe_page, it can't call out to
+ * other functions by PC-relative address. Also remember that it may be
+ * mid-way through over-writing other functions. For this reason it contains
+ * code from flush_icache_range() and uses the copy_page() macro.
+ *
+ * All of memory gets written to, including code. We need to clean the kernel
+ * text to the Point of Coherence (PoC) before secondary cores can be booted.
+ * Because the kernel modules and executable pages mapped to user space are
+ * also written as data, we clean all pages we touch to the Point of
+ * Unification (PoU).
+ *
+ * x0: physical address of temporary page tables
+ * x1: physical address of swapper page tables
+ * x2: address of cpu_resume
+ * x3: linear map address of restore_pblist in the current kernel
+ */
+.pushsection    ".hibernate_exit.text", "ax"
+ENTRY(swsusp_arch_suspend_exit)
+	/* Temporary page tables are a copy, so no need for a trampoline here */
+	msr	ttbr1_el1, x0
+	isb
+	tlbi	vmalle1is	// invalidate any intermediate caching entries
+	dsb	ish
+
+	mov	x21, x1
+	mov	x22, x2
+
+	/* walk the restore_pblist and use copy_page() to over-write memory */
+	mov	x19, x3
+
+2:	ldr	x10, [x19, #HIBERN_PBE_ORIG]
+	mov	x0, x10
+	ldr	x1, [x19, #HIBERN_PBE_ADDR]
+
+	copy_page	x0, x1, x2, x3, x4, x5, x6, x7, x8, x9
+
+	add	x1, x10, #PAGE_SIZE
+	/* Clean the copied page to PoU - based on flush_icache_range() */
+	dcache_line_size x2, x3
+	sub	x3, x2, #1
+	bic	x4, x10, x3
+4:	dc	cvau, x4	// clean D line / unified line
+	add	x4, x4, x2
+	cmp	x4, x1
+	b.lo	4b
+
+	ldr	x19, [x19, #HIBERN_PBE_NEXT]
+	cbnz	x19, 2b
+
+	/*
+	 * switch to the restored kernels page tables, and branch to re-enter
+	 * kernel.
+	 */
+	msr	ttbr1_el1, x21  // physical address of swapper page tables.
+	isb
+	tlbi	vmalle1is	// invalidate any intermediate caching entries
+	ic	ialluis
+	dsb	ish		// also waits for PoU cleaning to finish
+	isb			// code at x22 may now be different
+
+	br	x22
+
+	.ltorg
+ENDPROC(swsusp_arch_suspend_exit)
+
+/*
+ * el2_setup() moves lr into elr and erets. Copy lr to another register to
+ * preserve it.
+ *
+ * int swsusp_el2_setup_helper(phys_addr_t el2_setup_pa);
+ */
+ENTRY(swsusp_el2_setup_helper)
+	mov	x16, x30
+	hvc	#0
+	mov	x30, x16
+	ret
+ENDPROC(swsusp_el2_setup_helper)
+
+/*
+ * Restore the hyp stub. Once we know where in memory el2_setup is, we
+ * can use it to re-initialise el2. This must be done before the hibernate
+ * page is unmapped.
+ *
+ * x0: The physical address of el2_setup __pa(el2_setup)
+ */
+el1_sync:
+	mov	x1, x0
+	mrs	lr, elr_el2
+	mrs	x0, sctlr_el1
+	br	x1
+ENDPROC(el1_sync)
+
+.macro invalid_vector	label
+\label:
+	b \label
+ENDPROC(\label)
+.endm
+
+	invalid_vector	el2_sync_invalid
+	invalid_vector	el2_irq_invalid
+	invalid_vector	el2_fiq_invalid
+	invalid_vector	el2_error_invalid
+	invalid_vector	el1_sync_invalid
+	invalid_vector	el1_irq_invalid
+	invalid_vector	el1_fiq_invalid
+	invalid_vector	el1_error_invalid
+
+/* el2 vectors - switch el2 here while we restore the memory image. */
+	.align 11
+ENTRY(hibernate_el2_vectors)
+	ventry	el2_sync_invalid		// Synchronous EL2t
+	ventry	el2_irq_invalid			// IRQ EL2t
+	ventry	el2_fiq_invalid			// FIQ EL2t
+	ventry	el2_error_invalid		// Error EL2t
+
+	ventry	el2_sync_invalid		// Synchronous EL2h
+	ventry	el2_irq_invalid			// IRQ EL2h
+	ventry	el2_fiq_invalid			// FIQ EL2h
+	ventry	el2_error_invalid		// Error EL2h
+
+	ventry	el1_sync			// Synchronous 64-bit EL1
+	ventry	el1_irq_invalid			// IRQ 64-bit EL1
+	ventry	el1_fiq_invalid			// FIQ 64-bit EL1
+	ventry	el1_error_invalid		// Error 64-bit EL1
+
+	ventry	el1_sync_invalid		// Synchronous 32-bit EL1
+	ventry	el1_irq_invalid			// IRQ 32-bit EL1
+	ventry	el1_fiq_invalid			// FIQ 32-bit EL1
+	ventry	el1_error_invalid		// Error 32-bit EL1
+END(hibernate_el2_vectors)
+
+.popsection
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
new file mode 100644
index 000000000000..fd2faca358f6
--- /dev/null
+++ b/arch/arm64/kernel/hibernate.c
@@ -0,0 +1,482 @@
+/*:
+ * Hibernate support specific for ARM64
+ *
+ * Derived from work on ARM hibernation support by:
+ *
+ * Ubuntu project, hibernation support for mach-dove
+ * Copyright (C) 2010 Nokia Corporation (Hiroshi Doyu)
+ * Copyright (C) 2010 Texas Instruments, Inc. (Teerth Reddy et al.)
+ *  https://lkml.org/lkml/2010/6/18/4
+ *  https://lists.linux-foundation.org/pipermail/linux-pm/2010-June/027422.html
+ *  https://patchwork.kernel.org/patch/96442/
+ *
+ * Copyright (C) 2006 Rafael J. Wysocki <rjw at sisk.pl>
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#define pr_fmt(x) "hibernate: " x
+#include <linux/kvm_host.h>
+#include <linux/mm.h>
+#include <linux/pm.h>
+#include <linux/sched.h>
+#include <linux/suspend.h>
+#include <linux/version.h>
+
+#include <asm/barrier.h>
+#include <asm/cacheflush.h>
+#include <asm/irqflags.h>
+#include <asm/memory.h>
+#include <asm/mmu_context.h>
+#include <asm/pgalloc.h>
+#include <asm/pgtable.h>
+#include <asm/pgtable-hwdef.h>
+#include <asm/sections.h>
+#include <asm/suspend.h>
+#include <asm/virt.h>
+
+/* These are necessary to build without ifdefery */
+#ifndef pmd_index
+#define pmd_index(x)	0
+#endif
+#ifndef pud_index
+#define pud_index(x)	0
+#endif
+
+#define TCR_IPS_BITS (0x7UL<<32)
+
+/*
+ * Hibernate core relies on this value being 0 on resume, and marks it
+ * __nosavedata assuming it will keep the resume kernel's '0' value. This
+ * doesn't happen with either KASLR or resuming with a different kernel.
+ *
+ * defined as "__visible int in_suspend __nosavedata" in
+ * kernel/power/hibernate.c
+ */
+extern int in_suspend;
+
+/*
+ * This value is written to the hibernate arch header, and prevents resuming
+ * from a hibernate image produced by an incompatible kernel. If you change
+ * a value that isn't saved/restored by hibernate, you should change this value.
+ *
+ * For example, if the mair_el1 values used by the kernel are changed, you
+ * should prevent resuming from a kernel with incompatible attributes, as these
+ * aren't saved/restored.
+ */
+#define HIBERNATE_VERSION	KERNEL_VERSION(4, 6, 0)
+
+/*
+ * Start/end of the hibernate exit code, this must be copied to a 'safe'
+ * location in memory, and executed from there.
+ */
+extern char __hibernate_exit_text_start[], __hibernate_exit_text_end[];
+
+/* temporary el2 vectors in the __hibernate_exit_text section. */
+extern char hibernate_el2_vectors[];
+
+struct arch_hibernate_hdr_invariants {
+	unsigned long	version;
+	unsigned long	tcr_el1;	/* page_size, va bit etc */
+};
+
+/* These values need to be know across a hibernate/restore. */
+static struct arch_hibernate_hdr {
+	struct arch_hibernate_hdr_invariants invariants;
+
+	/* These are needed to find the relocated kernel if built with kaslr */
+	phys_addr_t	ttbr1_el1;
+	void		(*reenter_kernel)(void);
+} resume_hdr;
+
+static inline struct arch_hibernate_hdr_invariants arch_hdr_invariants(void)
+{
+	struct arch_hibernate_hdr_invariants rv;
+
+	rv.version = HIBERNATE_VERSION;
+	asm volatile("mrs	%0, tcr_el1" : "=r"(rv.tcr_el1));
+
+	/* IPS bits vary on big/little systems, mask them out */
+	rv.tcr_el1 &= ~TCR_IPS_BITS;
+
+	return rv;
+}
+
+int pfn_is_nosave(unsigned long pfn)
+{
+	unsigned long nosave_begin_pfn = virt_to_pfn(&__nosave_begin);
+	unsigned long nosave_end_pfn = virt_to_pfn(&__nosave_end - 1);
+
+	return (pfn >= nosave_begin_pfn) && (pfn <= nosave_end_pfn);
+}
+
+void notrace save_processor_state(void)
+{
+	WARN_ON(num_online_cpus() != 1);
+}
+
+void notrace restore_processor_state(void)
+{
+}
+
+int arch_hibernation_header_save(void *addr, unsigned int max_size)
+{
+	struct arch_hibernate_hdr *hdr = addr;
+
+	if (max_size < sizeof(*hdr))
+		return -EOVERFLOW;
+
+	hdr->invariants		= arch_hdr_invariants();
+	hdr->ttbr1_el1		= virt_to_phys(swapper_pg_dir);
+	hdr->reenter_kernel	= &_cpu_resume;
+
+	return 0;
+}
+EXPORT_SYMBOL(arch_hibernation_header_save);
+
+int arch_hibernation_header_restore(void *addr)
+{
+	struct arch_hibernate_hdr_invariants invariants;
+	struct arch_hibernate_hdr *hdr = addr;
+
+	/*
+	 * If this header is ancient, it may be smaller than we expect.
+	 * Test the version first.
+	 */
+	if (hdr->invariants.version != HIBERNATE_VERSION) {
+		pr_crit("Hibernate image not compatible with this kernel version!\n");
+		return -EINVAL;
+	}
+
+	invariants = arch_hdr_invariants();
+	if (memcmp(&hdr->invariants, &invariants, sizeof(invariants))) {
+		pr_crit("Hibernate image not compatible with this kernel configuration!\n");
+		return -EINVAL;
+	}
+
+	resume_hdr = *hdr;
+
+	return 0;
+}
+EXPORT_SYMBOL(arch_hibernation_header_restore);
+
+/*
+ * Copies length bytes, starting at src_start into an new page,
+ * perform cache maintentance, then map it (nearly) at the bottom of memory
+ * as executable.
+ *
+ * This is used by hibernate to copy the code it needs to execute when
+ * overwriting the kernel text. This function generates a new set of page
+ * tables, which it loads into ttbr0.
+ *
+ * Length is provided as we probably only want 4K of data, even on a 64K
+ * page system. We don't use the very bottom page, so that dereferencing
+ * NULL continues to have the expected behaviour.
+ */
+static int create_safe_exec_page(void *src_start, size_t length,
+				 void **dst_addr, phys_addr_t *phys_dst_addr,
+				 unsigned long (*allocator)(gfp_t mask),
+				 gfp_t mask)
+{
+	int rc = 0;
+	pgd_t *pgd;
+	pud_t *pud;
+	pmd_t *pmd;
+	pte_t *pte;
+	unsigned long dst = allocator(mask);
+
+	if (!dst) {
+		rc = -ENOMEM;
+		goto out;
+	}
+
+	memcpy((void *)dst, src_start, length);
+	flush_icache_range(dst, dst + length);
+
+	pgd = (pgd_t *)allocator(mask) + pgd_index(PAGE_SIZE);
+	if (PTRS_PER_PGD > 1) {
+		pud = (pud_t *)allocator(mask);
+		if (!pud) {
+			rc = -ENOMEM;
+			goto out;
+		}
+		set_pgd(pgd, __pgd(virt_to_phys(pud) | PUD_TYPE_TABLE));
+	}
+
+	pud = pud_offset(pgd, PAGE_SIZE);
+	if (PTRS_PER_PUD > 1) {
+		pmd = (pmd_t *)allocator(mask);
+		if (!pmd) {
+			rc = -ENOMEM;
+			goto out;
+		}
+		set_pud(pud, __pud(virt_to_phys(pmd) | PUD_TYPE_TABLE));
+	}
+
+	pmd = pmd_offset(pud, PAGE_SIZE);
+	if (PTRS_PER_PMD > 1) {
+		pte = (pte_t *)allocator(mask);
+		if (!pte) {
+			rc = -ENOMEM;
+			goto out;
+		}
+		set_pmd(pmd, __pmd(virt_to_phys(pte) | PMD_TYPE_TABLE));
+	}
+
+	pte = pte_offset_kernel(pmd, PAGE_SIZE);
+	set_pte_at(&init_mm, dst, pte,
+		   __pte(virt_to_phys((void *)dst) |
+			 pgprot_val(PAGE_KERNEL_EXEC)));
+
+	/* Load our new page tables */
+	asm volatile("msr	ttbr0_el1, %0;"
+		     "isb;"
+		     "tlbi	vmalle1is;"
+		     "dsb	ish" : : "r"(virt_to_phys(pgd)));
+
+	*dst_addr = (void *)(PAGE_SIZE);
+	*phys_dst_addr = virt_to_phys((void *)dst);
+
+out:
+	return rc;
+}
+
+
+int swsusp_arch_suspend(void)
+{
+	int ret = 0;
+	unsigned long flags;
+	struct sleep_stack_data state;
+
+	local_dbg_save(flags);
+
+	if (__cpu_suspend_enter(&state)) {
+		ret = swsusp_save();
+	} else {
+		void *lm_kernel_start;
+
+		/* Clean kernel to PoC for secondary core startup */
+		lm_kernel_start = phys_to_virt(virt_to_phys(KERNEL_START));
+		__flush_dcache_area(lm_kernel_start, KERNEL_END - KERNEL_START);
+
+		/* Reconfigure EL2 */
+		if (is_hyp_mode_available())
+			swsusp_el2_setup_helper(virt_to_phys(el2_setup));
+
+		/*
+		 * Tell the hibernation core that we've just restored
+		 * the memory
+		 */
+		in_suspend = 0;
+
+		__cpu_suspend_exit();
+	}
+
+	local_dbg_restore(flags);
+
+	return ret;
+}
+
+static int copy_pte(pmd_t *dst_pmd, pmd_t *src_pmd, unsigned long start,
+		    unsigned long end)
+{
+	unsigned long next;
+	unsigned long addr = start;
+	pte_t *src_pte = pte_offset_kernel(src_pmd, start);
+	pte_t *dst_pte = pte_offset_kernel(dst_pmd, start);
+
+	do {
+		next = addr + PAGE_SIZE;
+		if (pte_val(*src_pte))
+			set_pte(dst_pte,
+				__pte(pte_val(*src_pte) & ~PTE_RDONLY));
+	} while (dst_pte++, src_pte++, addr = next, addr != end);
+
+	return 0;
+}
+
+static int copy_pmd(pud_t *dst_pud, pud_t *src_pud, unsigned long start,
+		    unsigned long end)
+{
+	int rc = 0;
+	pte_t *dst_pte;
+	unsigned long next;
+	unsigned long addr = start;
+	pmd_t *src_pmd = pmd_offset(src_pud, start);
+	pmd_t *dst_pmd = pmd_offset(dst_pud, start);
+
+	do {
+		next = pmd_addr_end(addr, end);
+		if (!pmd_val(*src_pmd))
+			continue;
+
+		if (pmd_table(*(src_pmd))) {
+			dst_pte = (pte_t *)get_safe_page(GFP_ATOMIC);
+			if (!dst_pte) {
+				rc = -ENOMEM;
+				break;
+			}
+
+			set_pmd(dst_pmd, __pmd(virt_to_phys(dst_pte)
+					       | PMD_TYPE_TABLE));
+
+			rc = copy_pte(dst_pmd, src_pmd, addr, next);
+			if (rc)
+				break;
+		} else {
+			set_pmd(dst_pmd,
+				__pmd(pmd_val(*src_pmd) & ~PMD_SECT_RDONLY));
+		}
+	} while (dst_pmd++, src_pmd++, addr = next, addr != end);
+
+	return rc;
+}
+
+static int copy_pud(pgd_t *dst_pgd, pgd_t *src_pgd, unsigned long start,
+		    unsigned long end)
+{
+	int rc = 0;
+	pmd_t *dst_pmd;
+	unsigned long next;
+	unsigned long addr = start;
+	pud_t *src_pud = pud_offset(src_pgd, start);
+	pud_t *dst_pud = pud_offset(dst_pgd, start);
+
+	do {
+		next = pud_addr_end(addr, end);
+		if (!pud_val(*src_pud))
+			continue;
+
+		if (pud_table(*(src_pud))) {
+			if (PTRS_PER_PMD != 1) {
+				dst_pmd = (pmd_t *)get_safe_page(GFP_ATOMIC);
+				if (!dst_pmd) {
+					rc = -ENOMEM;
+					break;
+				}
+
+				set_pud(dst_pud, __pud(virt_to_phys(dst_pmd)
+						       | PUD_TYPE_TABLE));
+			}
+
+			rc = copy_pmd(dst_pud, src_pud, addr, next);
+			if (rc)
+				break;
+		} else {
+			set_pud(dst_pud,
+				__pud(pud_val(*src_pud) & ~PMD_SECT_RDONLY));
+		}
+	} while (dst_pud++, src_pud++, addr = next, addr != end);
+
+	return rc;
+}
+
+static int copy_page_tables(pgd_t *dst_pgd, unsigned long start,
+			    unsigned long end)
+{
+	int rc = 0;
+	pud_t *dst_pud;
+	unsigned long next;
+	unsigned long addr = start;
+	pgd_t *src_pgd = pgd_offset_k(start);
+
+	dst_pgd += pgd_index(start);
+
+	do {
+		next = pgd_addr_end(addr, end);
+		if (!pgd_val(*src_pgd))
+			continue;
+
+		if (PTRS_PER_PUD != 1) {
+			dst_pud = (pud_t *)get_safe_page(GFP_ATOMIC);
+			if (!dst_pud) {
+				rc = -ENOMEM;
+				break;
+			}
+
+			set_pgd(dst_pgd, __pgd(virt_to_phys(dst_pud)
+					       | PUD_TYPE_TABLE));
+		}
+
+		rc = copy_pud(dst_pgd, src_pgd, addr, next);
+		if (rc)
+			break;
+	} while (dst_pgd++, src_pgd++, addr = next, addr != end);
+
+	return rc;
+}
+
+/*
+ * Setup then Resume from the hibernate image using swsusp_arch_suspend_exit().
+ *
+ * Memory allocated by get_safe_page() will be dealt with by the hibernate code,
+ * we don't need to free it here.
+ */
+int swsusp_arch_resume(void)
+{
+	int rc = 0;
+	size_t exit_size;
+	pgd_t *tmp_pg_dir;
+	void *lm_restore_pblist;
+	phys_addr_t phys_hibernate_exit;
+	void __noreturn (*hibernate_exit)(phys_addr_t, phys_addr_t, void *, void *);
+
+	/*
+	 * Copy swsusp_arch_suspend_exit() to a safe page. This will generate
+	 * a new set of ttbr0 page tables and load them.
+	 */
+	exit_size = __hibernate_exit_text_end - __hibernate_exit_text_start;
+	rc = create_safe_exec_page(__hibernate_exit_text_start, exit_size,
+				   (void **)&hibernate_exit,
+				   &phys_hibernate_exit,
+				   get_safe_page, GFP_ATOMIC);
+	if (rc) {
+		pr_err("Failed to create safe executable page for hibernate_exit code.");
+		goto out;
+	}
+
+	/*
+	 * The hibernate exit text contains a set of el2 vectors, that will
+	 * be executed at el2 with the mmu off in order to reload hyp-stub.
+	 */
+	__flush_dcache_area(hibernate_exit, exit_size);
+
+	/*
+	 * Restoring the memory image will overwrite the ttbr1 page tables.
+	 * Create a second copy of just the linear map, and use this when
+	 * restoring.
+	 */
+	tmp_pg_dir = (pgd_t *)get_safe_page(GFP_ATOMIC);
+	if (!tmp_pg_dir) {
+		pr_err("Failed to allocate memory for temporary page tables.");
+		rc = -ENOMEM;
+		goto out;
+	}
+	rc = copy_page_tables(tmp_pg_dir, PAGE_OFFSET, 0);
+	if (rc)
+		goto out;
+
+	/*
+	 * Since we only copied the linear map, we need to find restore_pblist's
+	 * linear map address.
+	 */
+	lm_restore_pblist = phys_to_virt(virt_to_phys(restore_pblist));
+
+	/*
+	 * Both KASLR and restoring with a different kernel version will cause
+	 * the el2 vectors to be in a different location in the resumed kernel.
+	 * Load hibernate's temporary copy into el2.
+	 */
+	if (is_hyp_mode_available()) {
+		phys_addr_t el2_vectors = phys_hibernate_exit;  /* base */
+		el2_vectors += hibernate_el2_vectors -
+			       __hibernate_exit_text_start;     /* offset */
+
+		__hyp_set_vectors(el2_vectors);
+	}
+
+	hibernate_exit(virt_to_phys(tmp_pg_dir), resume_hdr.ttbr1_el1,
+		       resume_hdr.reenter_kernel, lm_restore_pblist);
+
+out:
+	return rc;
+}
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 282e3e64a17e..02184c39f7e2 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -46,6 +46,16 @@ jiffies = jiffies_64;
 	*(.idmap.text)					\
 	VMLINUX_SYMBOL(__idmap_text_end) = .;
 
+#ifdef CONFIG_HIBERNATION
+#define HIBERNATE_TEXT					\
+	. = ALIGN(SZ_4K);				\
+	VMLINUX_SYMBOL(__hibernate_exit_text_start) = .;\
+	*(.hibernate_exit.text)				\
+	VMLINUX_SYMBOL(__hibernate_exit_text_end) = .;
+#else
+#define HIBERNATE_TEXT
+#endif
+
 /*
  * The size of the PE/COFF section that covers the kernel image, which
  * runs from stext to _edata, must be a round multiple of the PE/COFF
@@ -107,6 +117,7 @@ SECTIONS
 			LOCK_TEXT
 			HYPERVISOR_TEXT
 			IDMAP_TEXT
+			HIBERNATE_TEXT
 			*(.fixup)
 			*(.gnu.warning)
 		. = ALIGN(16);
@@ -182,6 +193,10 @@ ASSERT(__hyp_idmap_text_end - (__hyp_idmap_text_start & ~(SZ_4K - 1)) <= SZ_4K,
 	"HYP init code too big or misaligned")
 ASSERT(__idmap_text_end - (__idmap_text_start & ~(SZ_4K - 1)) <= SZ_4K,
 	"ID map text too big or misaligned")
+#ifdef CONFIG_HIBERNATION
+ASSERT(__hibernate_exit_text_end - (__hibernate_exit_text_start & ~(SZ_4K - 1))
+	<= SZ_4K, "Hibernate exit text too big or misaligned")
+#endif
 
 /*
  * If padding is applied before .head.text, virt<->phys conversions will fail.
-- 
2.6.2



From linus.walleij at linaro.org  Tue Feb 16 07:53:43 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 16 Feb 2016 16:53:43 +0100
Subject: [PATCH 1/4] gpio: remove broken irq_to_gpio() interface
In-Reply-To: <2646870.5L1En4yxph@wuerfel>
References: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <1455551208-2825510-2-git-send-email-arnd@arndb.de>
 <CACRpkdaQN9_qoTn4_riZGvi4BKRLEVkRRL4CWzKj8e_di7Q2Xg@mail.gmail.com>
 <2646870.5L1En4yxph@wuerfel>
Message-ID: <CACRpkdYDqU7bbZguifQ2cos0r0ywgofzx4XvsmkQ8d73W9183A@mail.gmail.com>

On Tue, Feb 16, 2016 at 4:45 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> I've just sent v2 of the series, with a separate patch for MIPS
> that now conflicts with this one. Can you pick up the new patch
> instead?

OK I'll back out and apply the v2 versions.

Yours,
Linus Walleij


From arnd at arndb.de  Tue Feb 16 07:52:15 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 16:52:15 +0100
Subject: [PATCH] iio: health/afe4403: select REGMAP_SPI
Message-ID: <1455637959-3169264-1-git-send-email-arnd@arndb.de>

The newly added afe4403 driver uses the regmap facility to abstract
the I2C and SPI access. However, it fails to ensure that regmap_spi
is actually present:

drivers/iio/built-in.o: In function `afe4403_probe':
:(.text+0x9bf8): undefined reference to `__devm_regmap_init_spi'

This adds a Kconfig select statement like the afe4404 I2C driver
has.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: eec96d1e2d31 ("iio: health: Add driver for the TI AFE4403 heart monitor")
---
 drivers/iio/health/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iio/health/Kconfig b/drivers/iio/health/Kconfig
index f0c19779ac27..c5f004a8e447 100644
--- a/drivers/iio/health/Kconfig
+++ b/drivers/iio/health/Kconfig
@@ -10,6 +10,7 @@ menu "Heart Rate Monitors"
 config AFE4403
 	tristate "TI AFE4403 Heart Rate Monitor"
 	depends on SPI_MASTER
+	select REGMAP_SPI
 	select IIO_BUFFER
 	select IIO_TRIGGERED_BUFFER
 	help
-- 
2.7.0



From james.morse at arm.com  Tue Feb 16 07:49:16 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:16 +0000
Subject: [PATCH v5 04/15] arm64: Add new hcall HVC_CALL_FUNC
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <1455637767-31561-5-git-send-email-james.morse@arm.com>

From: Geoff Levand <geoff at infradead.org>

Add the new hcall HVC_CALL_FUNC that allows execution of a function at EL2.
During CPU reset the CPU must be brought to the exception level it had on
entry to the kernel.  The HVC_CALL_FUNC hcall will provide the mechanism
needed for this exception level switch.

To allow the HVC_CALL_FUNC exception vector to work without a stack, which
is needed to support an hcall at CPU reset, this implementation uses
register x18 to store the link register across the caller provided
function.  This dictates that the caller provided function must preserve
the contents of register x18.

Signed-off-by: Geoff Levand <geoff at infradead.org>
[Renumbered labels in el1_sync()]
Signed-off-by: James Morse <james.morse at arm.com>
---
This patch comes from v13 of kexec

 arch/arm64/include/asm/virt.h | 13 +++++++++++++
 arch/arm64/kernel/hyp-stub.S  | 19 +++++++++++++++----
 2 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index eb10368c329e..30700961f28c 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -45,6 +45,19 @@
 
 #define HVC_SET_VECTORS 2
 
+/*
+ * HVC_CALL_FUNC - Execute a function at EL2.
+ *
+ * @x0: Physical address of the function to be executed.
+ * @x1: Passed as the first argument to the function.
+ * @x2: Passed as the second argument to the function.
+ * @x3: Passed as the third argument to the function.
+ *
+ * The called function must preserve the contents of register x18.
+ */
+
+#define HVC_CALL_FUNC 3
+
 #define BOOT_CPU_MODE_EL1	(0xe11)
 #define BOOT_CPU_MODE_EL2	(0xe12)
 
diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index 017ab519aaf1..cfacfe55e3ef 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -59,18 +59,29 @@ el1_sync:
 	and	x18, x18, #ESR_ELx_ISS_MASK
 
 	cmp	x17, #ESR_ELx_EC_HVC64
-	b.ne	2f				// Not an HVC trap
+	b.ne	9f				// Not an HVC trap
 
 	cmp	x18, #HVC_GET_VECTORS
 	b.ne	1f
 	mrs	x0, vbar_el2
-	b	2f
+	b	9f
 
 1:	cmp	x18, #HVC_SET_VECTORS
 	b.ne	2f
 	msr	vbar_el2, x0
-
-2:	eret
+	b	9f
+
+2:	cmp	x18, #HVC_CALL_FUNC
+	b.ne	9f
+	mov	x18, lr
+	mov	lr, x0
+	mov	x0, x1
+	mov	x1, x2
+	mov	x2, x3
+	blr	lr
+	mov	lr, x18
+
+9:	eret
 ENDPROC(el1_sync)
 
 .macro invalid_vector	label
-- 
2.6.2



From james.morse at arm.com  Tue Feb 16 07:49:23 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:23 +0000
Subject: [PATCH v5 11/15] arm64: head.S: Change the register el2_setup()
 returns its result in x0
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <1455637767-31561-12-git-send-email-james.morse@arm.com>

Today el2_setup() returns its result in w20. This means we can't call it
like any normal function. Change this to w0.

All three callers of el2_setup() call set_cpu_boot_mode_flag() immediately
afterwards, and don't rely on x0 in later code. Boot cpu code calls
preserve_boot_args() before el2_setup(), so we don't clobber the DT pointer.

Signed-off-by: James Morse <james.morse at arm.com>
---
 arch/arm64/include/asm/processor.h |  2 ++
 arch/arm64/kernel/head.S           | 18 +++++++++---------
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 4acb7ca94fcd..07ac4351538e 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -188,4 +188,6 @@ static inline void spin_lock_prefetch(const void *x)
 
 void cpu_enable_pan(void *__unused);
 
+int el2_setup(void);
+
 #endif /* __ASM_PROCESSOR_H */
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 410a2dc04775..5894c7e91e6b 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -206,7 +206,7 @@ section_table:
 
 ENTRY(stext)
 	bl	preserve_boot_args
-	bl	el2_setup			// Drop to EL1, w20=cpu_boot_mode
+	bl	el2_setup			// Drop to EL1, w0=cpu_boot_mode
 	adrp	x24, __PHYS_OFFSET
 	bl	set_cpu_boot_mode_flag
 	bl	__create_page_tables		// x25=TTBR0, x26=TTBR1
@@ -446,8 +446,8 @@ ENDPROC(__mmap_switched)
  * If we're fortunate enough to boot at EL2, ensure that the world is
  * sane before dropping to EL1.
  *
- * Returns either BOOT_CPU_MODE_EL1 or BOOT_CPU_MODE_EL2 in x20 if
- * booted in EL1 or EL2 respectively.
+ * Returns either BOOT_CPU_MODE_EL1 or BOOT_CPU_MODE_EL2 if booted in
+ * EL1 or EL2 respectively.
  */
 ENTRY(el2_setup)
 	mrs	x0, CurrentEL
@@ -462,7 +462,7 @@ CPU_LE(	bic	x0, x0, #(1 << 25)	)	// Clear the EE bit for EL2
 CPU_BE(	orr	x0, x0, #(3 << 24)	)	// Set the EE and E0E bits for EL1
 CPU_LE(	bic	x0, x0, #(3 << 24)	)	// Clear the EE and E0E bits for EL1
 	msr	sctlr_el1, x0
-	mov	w20, #BOOT_CPU_MODE_EL1		// This cpu booted in EL1
+	mov	w0, #BOOT_CPU_MODE_EL1		// This cpu booted in EL1
 	isb
 	ret
 
@@ -538,20 +538,20 @@ CPU_LE(	movk	x0, #0x30d0, lsl #16	)	// Clear EE and E0E on LE systems
 		      PSR_MODE_EL1h)
 	msr	spsr_el2, x0
 	msr	elr_el2, lr
-	mov	w20, #BOOT_CPU_MODE_EL2		// This CPU booted in EL2
+	mov	w0, #BOOT_CPU_MODE_EL2		// This CPU booted in EL2
 	eret
 ENDPROC(el2_setup)
 
 /*
  * Sets the __boot_cpu_mode flag depending on the CPU boot mode passed
- * in x20. See arch/arm64/include/asm/virt.h for more info.
+ * in w0. See arch/arm64/include/asm/virt.h for more info.
  */
 ENTRY(set_cpu_boot_mode_flag)
 	adr_l	x1, __boot_cpu_mode
-	cmp	w20, #BOOT_CPU_MODE_EL2
+	cmp	w0, #BOOT_CPU_MODE_EL2
 	b.ne	1f
 	add	x1, x1, #4
-1:	str	w20, [x1]			// This CPU has booted in EL1
+1:	str	w0, [x1]			// This CPU has booted in EL1
 	dmb	sy
 	dc	ivac, x1			// Invalidate potentially stale cache line
 	ret
@@ -576,7 +576,7 @@ ENTRY(__boot_cpu_mode)
 	 * cores are held until we're ready for them to initialise.
 	 */
 ENTRY(secondary_holding_pen)
-	bl	el2_setup			// Drop to EL1, w20=cpu_boot_mode
+	bl	el2_setup			// Drop to EL1, w0=cpu_boot_mode
 	bl	set_cpu_boot_mode_flag
 	mrs	x0, mpidr_el1
 	ldr     x1, =MPIDR_HWID_BITMASK
-- 
2.6.2



From james.morse at arm.com  Tue Feb 16 07:49:13 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:13 +0000
Subject: [PATCH v5 01/15] arm64: Fold proc-macros.S into assembler.h
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <1455637767-31561-2-git-send-email-james.morse@arm.com>

From: Geoff Levand <geoff at infradead.org>

To allow the assembler macros defined in arch/arm64/mm/proc-macros.S to
be used outside the mm code move the contents of proc-macros.S to
asm/assembler.h.  Also, delete proc-macros.S, and fix up all references
to proc-macros.S.

Signed-off-by: Geoff Levand <geoff at infradead.org>
Acked-by: Pavel Machek <pavel at ucw.cz>
[rebased, included dcache_by_line_op]
Signed-off-by: James Morse <james.morse at arm.com>
---
This patch comes from v13 of kexec

 arch/arm64/include/asm/assembler.h | 82 ++++++++++++++++++++++++++++++-
 arch/arm64/mm/cache.S              |  2 -
 arch/arm64/mm/proc-macros.S        | 98 --------------------------------------
 arch/arm64/mm/proc.S               |  3 --
 4 files changed, 81 insertions(+), 104 deletions(-)
 delete mode 100644 arch/arm64/mm/proc-macros.S

diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index bb7b72734c24..ec4e37cb3b41 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -1,5 +1,5 @@
 /*
- * Based on arch/arm/include/asm/assembler.h
+ * Based on arch/arm/include/asm/assembler.h, arch/arm/mm/proc-macros.S
  *
  * Copyright (C) 1996-2000 Russell King
  * Copyright (C) 2012 ARM Ltd.
@@ -23,6 +23,8 @@
 #ifndef __ASM_ASSEMBLER_H
 #define __ASM_ASSEMBLER_H
 
+#include <asm/asm-offsets.h>
+#include <asm/pgtable-hwdef.h>
 #include <asm/ptrace.h>
 #include <asm/thread_info.h>
 
@@ -205,6 +207,84 @@ lr	.req	x30		// link register
 	.endm
 
 /*
+ * vma_vm_mm - get mm pointer from vma pointer (vma->vm_mm)
+ */
+	.macro	vma_vm_mm, rd, rn
+	ldr	\rd, [\rn, #VMA_VM_MM]
+	.endm
+
+/*
+ * mmid - get context id from mm pointer (mm->context.id)
+ */
+	.macro	mmid, rd, rn
+	ldr	\rd, [\rn, #MM_CONTEXT_ID]
+	.endm
+
+/*
+ * dcache_line_size - get the minimum D-cache line size from the CTR register.
+ */
+	.macro	dcache_line_size, reg, tmp
+	mrs	\tmp, ctr_el0			// read CTR
+	ubfm	\tmp, \tmp, #16, #19		// cache line size encoding
+	mov	\reg, #4			// bytes per word
+	lsl	\reg, \reg, \tmp		// actual cache line size
+	.endm
+
+/*
+ * icache_line_size - get the minimum I-cache line size from the CTR register.
+ */
+	.macro	icache_line_size, reg, tmp
+	mrs	\tmp, ctr_el0			// read CTR
+	and	\tmp, \tmp, #0xf		// cache line size encoding
+	mov	\reg, #4			// bytes per word
+	lsl	\reg, \reg, \tmp		// actual cache line size
+	.endm
+
+/*
+ * tcr_set_idmap_t0sz - update TCR.T0SZ so that we can load the ID map
+ */
+	.macro	tcr_set_idmap_t0sz, valreg, tmpreg
+#ifndef CONFIG_ARM64_VA_BITS_48
+	ldr_l	\tmpreg, idmap_t0sz
+	bfi	\valreg, \tmpreg, #TCR_T0SZ_OFFSET, #TCR_TxSZ_WIDTH
+#endif
+	.endm
+
+/*
+ * Macro to perform a data cache maintenance for the interval
+ * [kaddr, kaddr + size)
+ *
+ * 	op:		operation passed to dc instruction
+ * 	domain:		domain used in dsb instruciton
+ * 	kaddr:		starting virtual address of the region
+ * 	size:		size of the region
+ * 	Corrupts:	kaddr, size, tmp1, tmp2
+ */
+	.macro dcache_by_line_op op, domain, kaddr, size, tmp1, tmp2
+	dcache_line_size \tmp1, \tmp2
+	add	\size, \kaddr, \size
+	sub	\tmp2, \tmp1, #1
+	bic	\kaddr, \kaddr, \tmp2
+9998:	dc	\op, \kaddr
+	add	\kaddr, \kaddr, \tmp1
+	cmp	\kaddr, \size
+	b.lo	9998b
+	dsb	\domain
+	.endm
+
+/*
+ * reset_pmuserenr_el0 - reset PMUSERENR_EL0 if PMUv3 present
+ */
+	.macro	reset_pmuserenr_el0, tmpreg
+	mrs	\tmpreg, id_aa64dfr0_el1	// Check ID_AA64DFR0_EL1 PMUVer
+	sbfx	\tmpreg, \tmpreg, #8, #4
+	cmp	\tmpreg, #1			// Skip if no PMU present
+	b.lt	9000f
+	msr	pmuserenr_el0, xzr		// Disable PMU access from EL0
+9000:
+	.endm
+
+/*
  * Annotate a function as position independent, i.e., safe to be called before
  * the kernel virtual mapping is activated.
  */
diff --git a/arch/arm64/mm/cache.S b/arch/arm64/mm/cache.S
index 6df07069a025..50ff9ba3a236 100644
--- a/arch/arm64/mm/cache.S
+++ b/arch/arm64/mm/cache.S
@@ -24,8 +24,6 @@
 #include <asm/cpufeature.h>
 #include <asm/alternative.h>
 
-#include "proc-macros.S"
-
 /*
  *	flush_icache_range(start,end)
  *
diff --git a/arch/arm64/mm/proc-macros.S b/arch/arm64/mm/proc-macros.S
deleted file mode 100644
index e6a30e1268a8..000000000000
--- a/arch/arm64/mm/proc-macros.S
+++ /dev/null
@@ -1,98 +0,0 @@
-/*
- * Based on arch/arm/mm/proc-macros.S
- *
- * Copyright (C) 2012 ARM Ltd.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * 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 <asm/asm-offsets.h>
-#include <asm/thread_info.h>
-
-/*
- * vma_vm_mm - get mm pointer from vma pointer (vma->vm_mm)
- */
-	.macro	vma_vm_mm, rd, rn
-	ldr	\rd, [\rn, #VMA_VM_MM]
-	.endm
-
-/*
- * mmid - get context id from mm pointer (mm->context.id)
- */
-	.macro	mmid, rd, rn
-	ldr	\rd, [\rn, #MM_CONTEXT_ID]
-	.endm
-
-/*
- * dcache_line_size - get the minimum D-cache line size from the CTR register.
- */
-	.macro	dcache_line_size, reg, tmp
-	mrs	\tmp, ctr_el0			// read CTR
-	ubfm	\tmp, \tmp, #16, #19		// cache line size encoding
-	mov	\reg, #4			// bytes per word
-	lsl	\reg, \reg, \tmp		// actual cache line size
-	.endm
-
-/*
- * icache_line_size - get the minimum I-cache line size from the CTR register.
- */
-	.macro	icache_line_size, reg, tmp
-	mrs	\tmp, ctr_el0			// read CTR
-	and	\tmp, \tmp, #0xf		// cache line size encoding
-	mov	\reg, #4			// bytes per word
-	lsl	\reg, \reg, \tmp		// actual cache line size
-	.endm
-
-/*
- * tcr_set_idmap_t0sz - update TCR.T0SZ so that we can load the ID map
- */
-	.macro	tcr_set_idmap_t0sz, valreg, tmpreg
-#ifndef CONFIG_ARM64_VA_BITS_48
-	ldr_l	\tmpreg, idmap_t0sz
-	bfi	\valreg, \tmpreg, #TCR_T0SZ_OFFSET, #TCR_TxSZ_WIDTH
-#endif
-	.endm
-
-/*
- * Macro to perform a data cache maintenance for the interval
- * [kaddr, kaddr + size)
- *
- * 	op:		operation passed to dc instruction
- * 	domain:		domain used in dsb instruciton
- * 	kaddr:		starting virtual address of the region
- * 	size:		size of the region
- * 	Corrupts: 	kaddr, size, tmp1, tmp2
- */
-	.macro dcache_by_line_op op, domain, kaddr, size, tmp1, tmp2
-	dcache_line_size \tmp1, \tmp2
-	add	\size, \kaddr, \size
-	sub	\tmp2, \tmp1, #1
-	bic	\kaddr, \kaddr, \tmp2
-9998:	dc	\op, \kaddr
-	add	\kaddr, \kaddr, \tmp1
-	cmp	\kaddr, \size
-	b.lo	9998b
-	dsb	\domain
-	.endm
-
-/*
- * reset_pmuserenr_el0 - reset PMUSERENR_EL0 if PMUv3 present
- */
-	.macro	reset_pmuserenr_el0, tmpreg
-	mrs	\tmpreg, id_aa64dfr0_el1	// Check ID_AA64DFR0_EL1 PMUVer
-	sbfx	\tmpreg, \tmpreg, #8, #4
-	cmp	\tmpreg, #1			// Skip if no PMU present
-	b.lt	9000f
-	msr	pmuserenr_el0, xzr		// Disable PMU access from EL0
-9000:
-	.endm
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 0c19534a901e..db832c42ae30 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -23,11 +23,8 @@
 #include <asm/assembler.h>
 #include <asm/asm-offsets.h>
 #include <asm/hwcap.h>
-#include <asm/pgtable-hwdef.h>
 #include <asm/pgtable.h>
 
-#include "proc-macros.S"
-
 #ifdef CONFIG_ARM64_64K_PAGES
 #define TCR_TG_FLAGS	TCR_TG0_64K | TCR_TG1_64K
 #elif defined(CONFIG_ARM64_16K_PAGES)
-- 
2.6.2



From james.morse at arm.com  Tue Feb 16 07:49:14 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:14 +0000
Subject: [PATCH v5 02/15] arm64: Cleanup SCTLR flags
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <1455637767-31561-3-git-send-email-james.morse@arm.com>

From: Geoff Levand <geoff at infradead.org>

We currently have macros defining flags for the arm64 sctlr registers in
both kvm_arm.h and sysreg.h.  To clean things up and simplify move the
definitions of the SCTLR_EL2 flags from kvm_arm.h to sysreg.h, rename any
SCTLR_EL1 or SCTLR_EL2 flags that are common to both registers to be
SCTLR_ELx, with 'x' indicating a common flag, and fixup all files to
include the proper header or to use the new macro names.

Signed-off-by: Geoff Levand <geoff at infradead.org>
[Restored pgtable-hwdef.h include]
Signed-off-by: James Morse <james.morse at arm.com>
---
This patch comes from v13 of kexec

 arch/arm64/include/asm/kvm_arm.h | 11 -----------
 arch/arm64/include/asm/sysreg.h  | 19 +++++++++++++++----
 arch/arm64/kvm/hyp-init.S        |  5 +++--
 3 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index bef6e9243c63..9e1c0e7b0b73 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -83,17 +83,6 @@
 #define HCR_INT_OVERRIDE   (HCR_FMO | HCR_IMO)
 
 
-/* Hyp System Control Register (SCTLR_EL2) bits */
-#define SCTLR_EL2_EE	(1 << 25)
-#define SCTLR_EL2_WXN	(1 << 19)
-#define SCTLR_EL2_I	(1 << 12)
-#define SCTLR_EL2_SA	(1 << 3)
-#define SCTLR_EL2_C	(1 << 2)
-#define SCTLR_EL2_A	(1 << 1)
-#define SCTLR_EL2_M	1
-#define SCTLR_EL2_FLAGS	(SCTLR_EL2_M | SCTLR_EL2_A | SCTLR_EL2_C |	\
-			 SCTLR_EL2_SA | SCTLR_EL2_I)
-
 /* TCR_EL2 Registers bits */
 #define TCR_EL2_RES1	((1 << 31) | (1 << 23))
 #define TCR_EL2_TBI	(1 << 20)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 4aeebec3d882..99dac2f9f21a 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -82,10 +82,21 @@
 #define SET_PSTATE_PAN(x) __inst_arm(0xd5000000 | REG_PSTATE_PAN_IMM |\
 				     (!!x)<<8 | 0x1f)
 
-/* SCTLR_EL1 */
-#define SCTLR_EL1_CP15BEN	(0x1 << 5)
-#define SCTLR_EL1_SED		(0x1 << 8)
-#define SCTLR_EL1_SPAN		(0x1 << 23)
+/* Common SCTLR_ELx flags. */
+#define SCTLR_ELx_EE    (1 << 25)
+#define SCTLR_ELx_I	(1 << 12)
+#define SCTLR_ELx_SA	(1 << 3)
+#define SCTLR_ELx_C	(1 << 2)
+#define SCTLR_ELx_A	(1 << 1)
+#define SCTLR_ELx_M	1
+
+#define SCTLR_ELx_FLAGS	(SCTLR_ELx_M | SCTLR_ELx_A | SCTLR_ELx_C | \
+			 SCTLR_ELx_SA | SCTLR_ELx_I)
+
+/* SCTLR_EL1 specific flags. */
+#define SCTLR_EL1_SPAN		(1 << 23)
+#define SCTLR_EL1_SED		(1 << 8)
+#define SCTLR_EL1_CP15BEN	(1 << 5)
 
 
 /* id_aa64isar0 */
diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
index 3e568dcd907b..dc6335a7353e 100644
--- a/arch/arm64/kvm/hyp-init.S
+++ b/arch/arm64/kvm/hyp-init.S
@@ -21,6 +21,7 @@
 #include <asm/kvm_arm.h>
 #include <asm/kvm_mmu.h>
 #include <asm/pgtable-hwdef.h>
+#include <asm/sysreg.h>
 
 	.text
 	.pushsection	.hyp.idmap.text, "ax"
@@ -114,8 +115,8 @@ __do_hyp_init:
 	dsb	sy
 
 	mrs	x4, sctlr_el2
-	and	x4, x4, #SCTLR_EL2_EE	// preserve endianness of EL2
-	ldr	x5, =SCTLR_EL2_FLAGS
+	and	x4, x4, #SCTLR_ELx_EE	// preserve endianness of EL2
+	ldr	x5, =SCTLR_ELx_FLAGS
 	orr	x4, x4, x5
 	msr	sctlr_el2, x4
 	isb
-- 
2.6.2



From arnd at arndb.de  Tue Feb 16 07:59:42 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 16:59:42 +0100
Subject: [PATCH] net: igmp: use IS_ENABLED(CONFIG_IP_MULTICAST) instead of
 ifdef
Message-ID: <1455638393-3269483-1-git-send-email-arnd@arndb.de>

A recent change to use correct network namespace in net/ipv4/igmp.c
caused a couple of harmless build warnings when CONFIG_MULTICAST is
disabled:

net/ipv4/igmp.c: In function 'igmp_group_added':
net/ipv4/igmp.c:1227:14: error: unused variable 'net' [-Werror=unused-variable]
net/ipv4/igmp.c: In function 'ip_mc_inc_group':
net/ipv4/igmp.c:1319:14: error: unused variable 'net' [-Werror=unused-variable]
net/ipv4/igmp.c: In function 'ip_mc_init_dev':
net/ipv4/igmp.c:1646:14: error: unused variable 'net' [-Werror=unused-variable]
net/ipv4/igmp.c: In function 'ip_mc_up':
net/ipv4/igmp.c:1665:14: error: unused variable 'net' [-Werror=unused-variable]

This reworks the entire file to change each instance if '#ifdef
CONFIG_IP_MULTICAST' to 'if (IS_ENABLED(CONFIG_IP_MULTICAST)', which
should avoid these problems forever, and makes the whole file more
readable.

Build-tested only.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 87a8a2ae65b7 ("igmp: Namespaceify igmp_llm_reports sysctl knob")
---
 net/ipv4/igmp.c | 141 ++++++++++++++++++++++++--------------------------------
 1 file changed, 59 insertions(+), 82 deletions(-)

diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 7c95335bf85e..bb485b3e2baa 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -107,7 +107,6 @@
 #include <linux/seq_file.h>
 #endif
 
-#ifdef CONFIG_IP_MULTICAST
 /* Parameter names and values are taken from igmp-v2-06 draft */
 
 #define IGMP_V1_ROUTER_PRESENT_TIMEOUT		(400*HZ)
@@ -166,7 +165,6 @@ static void igmpv3_del_delrec(struct in_device *in_dev, __be32 multiaddr);
 static void igmpv3_clear_delrec(struct in_device *in_dev);
 static int sf_setstate(struct ip_mc_list *pmc);
 static void sf_markstate(struct ip_mc_list *pmc);
-#endif
 static void ip_mc_clear_src(struct ip_mc_list *pmc);
 static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
 			 int sfcount, __be32 *psfsrc, int delta);
@@ -189,8 +187,6 @@ static void ip_ma_put(struct ip_mc_list *im)
 	     pmc != NULL;					\
 	     pmc = rtnl_dereference(pmc->next_rcu))
 
-#ifdef CONFIG_IP_MULTICAST
-
 /*
  *	Timer management
  */
@@ -763,7 +759,9 @@ static void igmp_ifc_timer_expire(unsigned long data)
 static void igmp_ifc_event(struct in_device *in_dev)
 {
 	struct net *net = dev_net(in_dev->dev);
-	if (IGMP_V1_SEEN(in_dev) || IGMP_V2_SEEN(in_dev))
+
+	if (!IS_ENABLED(CONFIG_IP_MULTICAST) ||
+	    IGMP_V1_SEEN(in_dev) || IGMP_V2_SEEN(in_dev))
 		return;
 	in_dev->mr_ifc_count = in_dev->mr_qrv ?: net->ipv4.sysctl_igmp_qrv;
 	igmp_ifc_start_timer(in_dev, 1);
@@ -1044,9 +1042,6 @@ drop:
 	return 0;
 }
 
-#endif
-
-
 /*
  *	Add a filter to a device
  */
@@ -1080,7 +1075,6 @@ static void ip_mc_filter_del(struct in_device *in_dev, __be32 addr)
 		dev_mc_del(dev, buf);
 }
 
-#ifdef CONFIG_IP_MULTICAST
 /*
  * deleted ip_mc_list manipulation
  */
@@ -1181,22 +1175,20 @@ static void igmpv3_clear_delrec(struct in_device *in_dev)
 	}
 	rcu_read_unlock();
 }
-#endif
 
 static void igmp_group_dropped(struct ip_mc_list *im)
 {
 	struct in_device *in_dev = im->interface;
-#ifdef CONFIG_IP_MULTICAST
 	struct net *net = dev_net(in_dev->dev);
 	int reporter;
-#endif
 
 	if (im->loaded) {
 		im->loaded = 0;
 		ip_mc_filter_del(in_dev, im->multiaddr);
 	}
 
-#ifdef CONFIG_IP_MULTICAST
+	if (!IS_ENABLED(CONFIG_IP_MULTICAST))
+		return;
 	if (im->multiaddr == IGMP_ALL_HOSTS)
 		return;
 	if (ipv4_is_local_multicast(im->multiaddr) && !net->ipv4.sysctl_igmp_llm_reports)
@@ -1218,7 +1210,6 @@ static void igmp_group_dropped(struct ip_mc_list *im)
 
 		igmp_ifc_event(in_dev);
 	}
-#endif
 }
 
 static void igmp_group_added(struct ip_mc_list *im)
@@ -1231,7 +1222,9 @@ static void igmp_group_added(struct ip_mc_list *im)
 		ip_mc_filter_add(in_dev, im->multiaddr);
 	}
 
-#ifdef CONFIG_IP_MULTICAST
+	if (!IS_ENABLED(CONFIG_IP_MULTICAST))
+		return;
+
 	if (im->multiaddr == IGMP_ALL_HOSTS)
 		return;
 	if (ipv4_is_local_multicast(im->multiaddr) && !net->ipv4.sysctl_igmp_llm_reports)
@@ -1249,7 +1242,6 @@ static void igmp_group_added(struct ip_mc_list *im)
 
 	im->crcount = in_dev->mr_qrv ?: net->ipv4.sysctl_igmp_qrv;
 	igmp_ifc_event(in_dev);
-#endif
 }
 
 
@@ -1341,10 +1333,10 @@ void ip_mc_inc_group(struct in_device *in_dev, __be32 addr)
 	im->sfcount[MCAST_EXCLUDE] = 1;
 	atomic_set(&im->refcnt, 1);
 	spin_lock_init(&im->lock);
-#ifdef CONFIG_IP_MULTICAST
-	setup_timer(&im->timer, igmp_timer_expire, (unsigned long)im);
-	im->unsolicit_count = net->ipv4.sysctl_igmp_qrv;
-#endif
+	if (IS_ENABLED(CONFIG_IP_MULTICAST)) {
+		setup_timer(&im->timer, igmp_timer_expire, (unsigned long)im);
+		im->unsolicit_count = net->ipv4.sysctl_igmp_qrv;
+	}
 
 	im->next_rcu = in_dev->mc_list;
 	in_dev->mc_count++;
@@ -1352,9 +1344,9 @@ void ip_mc_inc_group(struct in_device *in_dev, __be32 addr)
 
 	ip_mc_hash_add(in_dev, im);
 
-#ifdef CONFIG_IP_MULTICAST
-	igmpv3_del_delrec(in_dev, im->multiaddr);
-#endif
+	if (IS_ENABLED(CONFIG_IP_MULTICAST))
+		igmpv3_del_delrec(in_dev, im->multiaddr);
+
 	igmp_group_added(im);
 	if (!in_dev->dead)
 		ip_rt_multicast_event(in_dev);
@@ -1533,11 +1525,13 @@ EXPORT_SYMBOL(ip_mc_check_igmp);
  */
 static void ip_mc_rejoin_groups(struct in_device *in_dev)
 {
-#ifdef CONFIG_IP_MULTICAST
 	struct ip_mc_list *im;
 	int type;
 	struct net *net = dev_net(in_dev->dev);
 
+	if (!IS_ENABLED(CONFIG_IP_MULTICAST))
+		return;
+
 	ASSERT_RTNL();
 
 	for_each_pmc_rtnl(in_dev, im) {
@@ -1558,7 +1552,6 @@ static void ip_mc_rejoin_groups(struct in_device *in_dev)
 			type = IGMPV3_HOST_MEMBERSHIP_REPORT;
 		igmp_send_report(in_dev, im, type);
 	}
-#endif
 }
 
 /*
@@ -1628,15 +1621,15 @@ void ip_mc_down(struct in_device *in_dev)
 	for_each_pmc_rtnl(in_dev, pmc)
 		igmp_group_dropped(pmc);
 
-#ifdef CONFIG_IP_MULTICAST
-	in_dev->mr_ifc_count = 0;
-	if (del_timer(&in_dev->mr_ifc_timer))
-		__in_dev_put(in_dev);
-	in_dev->mr_gq_running = 0;
-	if (del_timer(&in_dev->mr_gq_timer))
-		__in_dev_put(in_dev);
-	igmpv3_clear_delrec(in_dev);
-#endif
+	if (IS_ENABLED(CONFIG_IP_MULTICAST)) {
+		in_dev->mr_ifc_count = 0;
+		if (del_timer(&in_dev->mr_ifc_timer))
+			__in_dev_put(in_dev);
+		in_dev->mr_gq_running = 0;
+		if (del_timer(&in_dev->mr_gq_timer))
+			__in_dev_put(in_dev);
+		igmpv3_clear_delrec(in_dev);
+	}
 
 	ip_mc_dec_group(in_dev, IGMP_ALL_HOSTS);
 }
@@ -1646,13 +1639,13 @@ void ip_mc_init_dev(struct in_device *in_dev)
 	struct net *net = dev_net(in_dev->dev);
 	ASSERT_RTNL();
 
-#ifdef CONFIG_IP_MULTICAST
-	setup_timer(&in_dev->mr_gq_timer, igmp_gq_timer_expire,
-			(unsigned long)in_dev);
-	setup_timer(&in_dev->mr_ifc_timer, igmp_ifc_timer_expire,
-			(unsigned long)in_dev);
-	in_dev->mr_qrv = net->ipv4.sysctl_igmp_qrv;
-#endif
+	if (IS_ENABLED(CONFIG_IP_MULTICAST)) {
+		setup_timer(&in_dev->mr_gq_timer, igmp_gq_timer_expire,
+				(unsigned long)in_dev);
+		setup_timer(&in_dev->mr_ifc_timer, igmp_ifc_timer_expire,
+				(unsigned long)in_dev);
+		in_dev->mr_qrv = net->ipv4.sysctl_igmp_qrv;
+	}
 
 	spin_lock_init(&in_dev->mc_tomb_lock);
 }
@@ -1666,9 +1659,9 @@ void ip_mc_up(struct in_device *in_dev)
 
 	ASSERT_RTNL();
 
-#ifdef CONFIG_IP_MULTICAST
-	in_dev->mr_qrv = net->ipv4.sysctl_igmp_qrv;
-#endif
+	if (IS_ENABLED(CONFIG_IP_MULTICAST))
+		in_dev->mr_qrv = net->ipv4.sysctl_igmp_qrv;
+
 	ip_mc_inc_group(in_dev, IGMP_ALL_HOSTS);
 
 	for_each_pmc_rtnl(in_dev, pmc)
@@ -1755,34 +1748,27 @@ static int ip_mc_del1_src(struct ip_mc_list *pmc, int sfmode,
 		ip_rt_multicast_event(pmc->interface);
 	}
 	if (!psf->sf_count[MCAST_INCLUDE] && !psf->sf_count[MCAST_EXCLUDE]) {
-#ifdef CONFIG_IP_MULTICAST
 		struct in_device *in_dev = pmc->interface;
 		struct net *net = dev_net(in_dev->dev);
-#endif
 
 		/* no more filters for this source */
 		if (psf_prev)
 			psf_prev->sf_next = psf->sf_next;
 		else
 			pmc->sources = psf->sf_next;
-#ifdef CONFIG_IP_MULTICAST
-		if (psf->sf_oldin &&
+		if (IS_ENABLED(CONFIG_IP_MULTICAST) && psf->sf_oldin &&
 		    !IGMP_V1_SEEN(in_dev) && !IGMP_V2_SEEN(in_dev)) {
 			psf->sf_crcount = in_dev->mr_qrv ?: net->ipv4.sysctl_igmp_qrv;
 			psf->sf_next = pmc->tomb;
 			pmc->tomb = psf;
 			rv = 1;
-		} else
-#endif
+		} else {
 			kfree(psf);
+		}
 	}
 	return rv;
 }
 
-#ifndef CONFIG_IP_MULTICAST
-#define igmp_ifc_event(x)	do { } while (0)
-#endif
-
 static int ip_mc_del_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
 			 int sfcount, __be32 *psfsrc, int delta)
 {
@@ -1804,9 +1790,9 @@ static int ip_mc_del_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
 	}
 	spin_lock_bh(&pmc->lock);
 	rcu_read_unlock();
-#ifdef CONFIG_IP_MULTICAST
-	sf_markstate(pmc);
-#endif
+	if (IS_ENABLED(CONFIG_IP_MULTICAST))
+		sf_markstate(pmc);
+
 	if (!delta) {
 		err = -EINVAL;
 		if (!pmc->sfcount[sfmode])
@@ -1821,17 +1807,15 @@ static int ip_mc_del_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
 		if (!err && rv < 0)
 			err = rv;
 	}
-	if (pmc->sfmode == MCAST_EXCLUDE &&
+	if (IS_ENABLED(CONFIG_IP_MULTICAST) &&
+	    pmc->sfmode == MCAST_EXCLUDE &&
 	    pmc->sfcount[MCAST_EXCLUDE] == 0 &&
 	    pmc->sfcount[MCAST_INCLUDE]) {
-#ifdef CONFIG_IP_MULTICAST
 		struct ip_sf_list *psf;
 		struct net *net = dev_net(in_dev->dev);
-#endif
 
 		/* filter mode change */
 		pmc->sfmode = MCAST_INCLUDE;
-#ifdef CONFIG_IP_MULTICAST
 		pmc->crcount = in_dev->mr_qrv ?: net->ipv4.sysctl_igmp_qrv;
 		in_dev->mr_ifc_count = pmc->crcount;
 		for (psf = pmc->sources; psf; psf = psf->sf_next)
@@ -1839,7 +1823,6 @@ static int ip_mc_del_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
 		igmp_ifc_event(pmc->interface);
 	} else if (sf_setstate(pmc) || changerec) {
 		igmp_ifc_event(pmc->interface);
-#endif
 	}
 out_unlock:
 	spin_unlock_bh(&pmc->lock);
@@ -1877,12 +1860,14 @@ static int ip_mc_add1_src(struct ip_mc_list *pmc, int sfmode,
 	return 0;
 }
 
-#ifdef CONFIG_IP_MULTICAST
 static void sf_markstate(struct ip_mc_list *pmc)
 {
 	struct ip_sf_list *psf;
 	int mca_xcount = pmc->sfcount[MCAST_EXCLUDE];
 
+	if (!IS_ENABLED(CONFIG_IP_MULTICAST))
+		return;
+
 	for (psf = pmc->sources; psf; psf = psf->sf_next)
 		if (pmc->sfcount[MCAST_EXCLUDE]) {
 			psf->sf_oldin = mca_xcount ==
@@ -1950,7 +1935,6 @@ static int sf_setstate(struct ip_mc_list *pmc)
 	}
 	return rv;
 }
-#endif
 
 /*
  * Add multicast source filter list to the interface list
@@ -1977,9 +1961,7 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
 	spin_lock_bh(&pmc->lock);
 	rcu_read_unlock();
 
-#ifdef CONFIG_IP_MULTICAST
 	sf_markstate(pmc);
-#endif
 	isexclude = pmc->sfmode == MCAST_EXCLUDE;
 	if (!delta)
 		pmc->sfcount[sfmode]++;
@@ -1997,28 +1979,26 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
 		for (j = 0; j < i; j++)
 			(void) ip_mc_del1_src(pmc, sfmode, &psfsrc[j]);
 	} else if (isexclude != (pmc->sfcount[MCAST_EXCLUDE] != 0)) {
-#ifdef CONFIG_IP_MULTICAST
 		struct ip_sf_list *psf;
 		struct net *net = dev_net(pmc->interface->dev);
 		in_dev = pmc->interface;
-#endif
 
 		/* filter mode change */
 		if (pmc->sfcount[MCAST_EXCLUDE])
 			pmc->sfmode = MCAST_EXCLUDE;
 		else if (pmc->sfcount[MCAST_INCLUDE])
 			pmc->sfmode = MCAST_INCLUDE;
-#ifdef CONFIG_IP_MULTICAST
 		/* else no filters; keep old mode for reports */
-
-		pmc->crcount = in_dev->mr_qrv ?: net->ipv4.sysctl_igmp_qrv;
-		in_dev->mr_ifc_count = pmc->crcount;
-		for (psf = pmc->sources; psf; psf = psf->sf_next)
-			psf->sf_crcount = 0;
-		igmp_ifc_event(in_dev);
-	} else if (sf_setstate(pmc)) {
+		if (IS_ENABLED(CONFIG_IP_MULTICAST)) {
+			pmc->crcount = in_dev->mr_qrv ?:
+				       net->ipv4.sysctl_igmp_qrv;
+			in_dev->mr_ifc_count = pmc->crcount;
+			for (psf = pmc->sources; psf; psf = psf->sf_next)
+				psf->sf_crcount = 0;
+			igmp_ifc_event(in_dev);
+		}
+	} else if (IS_ENABLED(CONFIG_IP_MULTICAST) && sf_setstate(pmc)) {
 		igmp_ifc_event(in_dev);
-#endif
 	}
 	spin_unlock_bh(&pmc->lock);
 	return err;
@@ -2711,13 +2691,10 @@ static int igmp_mc_seq_show(struct seq_file *seq, void *v)
 		char   *querier;
 		long delta;
 
-#ifdef CONFIG_IP_MULTICAST
-		querier = IGMP_V1_SEEN(state->in_dev) ? "V1" :
+		querier = !IS_ENABLED(CONFIG_IP_MULTICAST) ? "NONE" :
+			  IGMP_V1_SEEN(state->in_dev) ? "V1" :
 			  IGMP_V2_SEEN(state->in_dev) ? "V2" :
 			  "V3";
-#else
-		querier = "NONE";
-#endif
 
 		if (rcu_access_pointer(state->in_dev->mc_list) == im) {
 			seq_printf(seq, "%d\t%-10s: %5d %7s\n",
-- 
2.7.0



From will.deacon at arm.com  Tue Feb 16 08:00:55 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 16 Feb 2016 16:00:55 +0000
Subject: [PATCH v2] arm64: add alignment fault hanling
In-Reply-To: <20160216122153.GD19413@e104818-lin.cambridge.arm.com>
References: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
 <20160216103104.GC14509@arm.com> <56C300AD.8070505@arm.com>
 <20160216122153.GD19413@e104818-lin.cambridge.arm.com>
Message-ID: <20160216160055.GH14509@arm.com>

On Tue, Feb 16, 2016 at 12:21:53PM +0000, Catalin Marinas wrote:
> On Tue, Feb 16, 2016 at 10:57:49AM +0000, Robin Murphy wrote:
> > On 16/02/16 10:31, Will Deacon wrote:
> > >On Tue, Feb 16, 2016 at 04:44:35AM +0000, EunTaik Lee wrote:
> > >>Userspace memory is mapped as below:
> > >>F2A7F000--F2A7FFFF Normal Memory
> > >>F2A80000--F2A80FFF Device nGnRnE
> > >>
> > >>And that userspace application makes a system call
> > >>as below:
> > >>
> > >>-009 |do_strncpy_from_user(inline)
> > >>-009 |strncpy_from_user()
> > >>-010 |getname_flags()
> > >>-011 |user_path_at_empty()
> > >>-012 |user_path_at()
> > >>-013 |SYSC_faccessat(inline)
> > >>-013 |sys_faccessat()
> > >>-014 |__sys_trace(asm)
> > >>  --> |exception
> > >>
> > >>The string spans from 0xF2A7FFC1 to 0xF2A7FFFB.
> > >>
> > >>When do_strncpy_from_user() reads the last (unsigned long)
> > >>value, the alignement fault is triggered. The 8 byte
> > >>from 0xF2A7FFC1 spans to the next page that is mapped as
> > >>Device nGnRnE, which does not allow an unaligned access,
> > >>causes the abort.
> > >>
> > >>The instruction which caused the alignment fault is registered
> > >>in the fixup table but the exception handler does not reach there.
> > >>
> > >>This patch registers a alignment fault handler and fixes up the
> > >>pc if appropriate.
> > >
> > >As discussed with Catalin previously, we should solve this by adding a
> > >guard page rather than handling the fault.
> 
> I don't think we can trivially add this without implementing an arm64
> specific arch_get_unmapped_area().

Even overriding arch_get_unmapped_area doesn't help as much as you might
like since, in the case of something like /dev/mem, the memory is remapped
using remap_pfn_range later on, so you can't necessarily tell what the
final attributes are likely to be when you initially allocate the virtual
space.

Will


From arnd at arndb.de  Tue Feb 16 08:03:26 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 17:03:26 +0100
Subject: [PATCH 1/2] ARM: mm: DEBUG_RODATA makes no sense with XIP_KERNEL
Message-ID: <1455638631-3326518-1-git-send-email-arnd@arndb.de>

When CONFIG_DEBUG_ALIGN_RODATA is set, we get a link error:

arch/arm/mm/built-in.o:(.data+0x4bc): undefined reference to `__start_rodata_section_aligned'

However, this combination is useless, as XIP_KERNEL implies that all the
RODATA is already marked readonly, so both CONFIG_DEBUG_RODATA and
CONFIG_DEBUG_ALIGN_RODATA (which depends on the other) are not
needed with XIP_KERNEL, and this patches enforces that using a Kconfig
dependency.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 25362dc496ed ("ARM: 8501/1: mm: flip priority of CONFIG_DEBUG_RODATA")
---
 arch/arm/mm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index fbf2296388ce..8894045caba9 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -1039,7 +1039,7 @@ config ARCH_SUPPORTS_BIG_ENDIAN
 
 config DEBUG_RODATA
 	bool "Make kernel text and rodata read-only"
-	depends on MMU
+	depends on MMU && !XIP_KERNEL
 	default y if CPU_V7
 	help
 	  If this is set, kernel text and rodata memory will be made
-- 
2.7.0



From ralf at linux-mips.org  Tue Feb 16 08:06:09 2016
From: ralf at linux-mips.org (Ralf Baechle)
Date: Tue, 16 Feb 2016 17:06:09 +0100
Subject: [PATCH v2 1/5] MIPS: jz4740: remove broken irq_to_gpio() call
In-Reply-To: <1455637261-2920972-1-git-send-email-arnd@arndb.de>
References: <455637086-2794174-1-git-send-email-arnd@arndb.de>
 <1455637261-2920972-1-git-send-email-arnd@arndb.de>
Message-ID: <20160216160609.GA15268@linux-mips.org>

On Tue, Feb 16, 2016 at 04:40:34PM +0100, Arnd Bergmann wrote:
> Date:   Tue, 16 Feb 2016 16:40:34 +0100
> From: Arnd Bergmann <arnd at arndb.de>
> To: Linus Walleij <linus.walleij at linaro.org>
> Cc: linux-arm-kernel at lists.infradead.org, Arnd Bergmann <arnd at arndb.de>,
>  Russell King <rmk+kernel at arm.linux.org.uk>, Bjorn Helgaas
>  <bhelgaas at google.com>, Alexandre Courbot <gnurou at gmail.com>,
>  linux-gpio at vger.kernel.org, linux-kernel at vger.kernel.org, Lars-Peter
>  Clausen <lars at metafoo.de>, Ralf Baechle <ralf at linux-mips.org>,
>  linux-mips at linux-mips.org, "# v4 . 3+" <stable at vger.kernel.org>, Alban
>  Bedel <albeu at free.fr>, Thomas Gleixner <tglx at linutronix.de>, Paul Burton
>  <paul.burton at imgtec.com>
> Subject: [PATCH v2 1/5] MIPS: jz4740: remove broken irq_to_gpio() call
> 
> gpiolib has removed the irq_to_gpio() API several years ago,
> but the global header still provided a non-working stub.
> 
> With a MIPS-wide change to use the generic header file, the jz4740
> platform is now using the wrong stub implementation of irq_to_gpio(),
> which cannot work.
> 
> This uses an open-coded implementation in the only line it
> is used in.
> 
> Suggested-by: Lars-Peter Clausen <lars at metafoo.de>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Cc: <stable at vger.kernel.org> # v4.3+
> Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h").
> ---
>  arch/mips/jz4740/gpio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/mips/jz4740/gpio.c b/arch/mips/jz4740/gpio.c
> index 8c6d76c9b2d6..d9907e57e9b9 100644
> --- a/arch/mips/jz4740/gpio.c
> +++ b/arch/mips/jz4740/gpio.c
> @@ -270,7 +270,7 @@ uint32_t jz_gpio_port_get_value(int port, uint32_t mask)
>  }
>  EXPORT_SYMBOL(jz_gpio_port_get_value);
>  
> -#define IRQ_TO_BIT(irq) BIT(irq_to_gpio(irq) & 0x1f)
> +#define IRQ_TO_BIT(irq) BIT((irq - JZ4740_IRQ_GPIO(0)) & 0x1f)
>  
>  static void jz_gpio_check_trigger_both(struct jz_gpio_chip *chip, unsigned int irq)
>  {

I've already committed an identical fix locally.

  Ralf


From fu.wei at linaro.org  Tue Feb 16 07:54:04 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Tue, 16 Feb 2016 23:54:04 +0800
Subject: [PATCH v12 4/4] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <56C34076.1020206@roeck-us.net>
References: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>
 <1455611785-2407-5-git-send-email-fu.wei@linaro.org>
 <56C34076.1020206@roeck-us.net>
Message-ID: <CADyBb7vDuZjjy92WkV_jML2Ji13LvtuqkKszAetzvoM47CaY7Q@mail.gmail.com>

On 16 February 2016 at 23:29, Guenter Roeck <linux at roeck-us.net> wrote:
> On 02/16/2016 12:36 AM, fu.wei at linaro.org wrote:
>>
>> From: Fu Wei <fu.wei at linaro.org>
>>
>> According to Server Base System Architecture (SBSA) specification,
>> the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0)
>> is for alerting the system by interrupt, the second one (WS1) is a real
>> hardware reset.
>> More details about the hardware specification of this device:
>> ARM DEN0029B - Server Base System Architecture (SBSA)
>>
>> This driver can operate ARM SBSA Generic Watchdog as a single stage
>> watchdog
>> or a two stages watchdog, it's set up by the module parameter "action".
>> In the single stage mode, when the timeout is reached, your system
>> will be reset by WS1. The first signal (WS0) is ignored.
>> In the two stages mode, when the timeout is reached, the first signal
>> (WS0)
>> will trigger panic. If the system is getting into trouble and cannot be
>> reset
>> by panic or restart properly by the kdump kernel(if supported), then the
>> second stage (as long as the first stage) will be reached, system will be
>> reset by WS1. This function can help administrator to backup the system
>> context info by panic console output or kdump.
>>
>> This driver bases on linux kernel watchdog framework, so it can get
>> timeout from module parameter and FDT at the driver init stage.
>>
>> Signed-off-by: Fu Wei <fu.wei at linaro.org>
>> Reviewed-by: Graeme Gregory <graeme.gregory at linaro.org>
>> Tested-by: Pratyush Anand <panand at redhat.com>
>> Acked-by: Timur Tabi <timur at codeaurora.org>
>> Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
>> ---
>>   drivers/watchdog/Kconfig     |  20 +++
>>   drivers/watchdog/Makefile    |   1 +
>>   drivers/watchdog/sbsa_gwdt.c | 403
>> +++++++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 424 insertions(+)
>>
>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>> index 0f6d851..ed9a5cb 100644
>> --- a/drivers/watchdog/Kconfig
>> +++ b/drivers/watchdog/Kconfig
>
>
> [ ... ]
>
>> +
>> +static int sbsa_gwdt_probe(struct platform_device *pdev)
>> +{
>
>
> [ ... ]
>
>> +               if (!action)
>> +                       dev_warn(dev, "falling back to signle stage
>> mode.\n");
>
>
> Still:
>
> s/signle/single/

sorry, my bad, will fix it

>
> [ ... ]
>
>> +
>> +MODULE_DESCRIPTION("SBSA Generic Watchdog Driver");
>> +MODULE_AUTHOR("Fu Wei <fu.wei at linaro.org>");
>> +MODULE_AUTHOR("Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>");
>> +MODULE_AUTHOR("Al Stone <al.stone at linaro.org>");
>> +MODULE_AUTHOR("Timur Tabi <timur at codeaurora.org>");
>> +MODULE_LICENSE("GPL v2");
>>
> Do you need a MODULE_ALIAS ?

For now, I thinks we don't need it, Hope I didn't miss something :-)
Because this module can be mounted automatically with dtb or ACPI(if
apply my GTDT patch).
Do you have any suggestion or concern? :-)

>
> Guenter
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From james.morse at arm.com  Tue Feb 16 07:49:17 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:17 +0000
Subject: [PATCH v5 05/15] arm64: kvm: allows kvm cpu hotplug
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <1455637767-31561-6-git-send-email-james.morse@arm.com>

From: AKASHI Takahiro <takahiro.akashi at linaro.org>

The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents kexec from rebooting the system at EL2.

This patch adds a cpu tear-down function and also puts an existing cpu-init
code into a separate function, kvm_arch_hardware_disable() and
kvm_arch_hardware_enable() respectively.
We don't need the arm64 specific cpu hotplug hook any more.

Since this patch modifies common code between arm and arm64, one stub
definition, __cpu_reset_hyp_mode(), is added on arm side to avoid
compilation errors.

Signed-off-by: AKASHI Takahiro <takahiro.akashi at linaro.org>
[Moved __kvm_hyp_reset() to use kvm_call_hyp(), instead of having its own
 dedicated entry point in el1_sync. Added some comments and a tlbi.]
Signed-off-by: James Morse <james.morse at arm.com>
---
This patch comes from v13 of kexec

 arch/arm/include/asm/kvm_host.h   | 10 +++-
 arch/arm/include/asm/kvm_mmu.h    |  1 +
 arch/arm/kvm/arm.c                | 98 ++++++++++++++++++++++++---------------
 arch/arm/kvm/mmu.c                |  5 ++
 arch/arm64/include/asm/kvm_host.h |  1 -
 arch/arm64/include/asm/kvm_mmu.h  | 20 ++++++++
 arch/arm64/kvm/hyp-init.S         | 42 +++++++++++++++++
 7 files changed, 137 insertions(+), 40 deletions(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index f9f27792d8ed..8af531d64771 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -220,6 +220,15 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
 	kvm_call_hyp((void*)hyp_stack_ptr, vector_ptr, pgd_ptr);
 }
 
+static inline void __cpu_reset_hyp_mode(phys_addr_t boot_pgd_ptr,
+					phys_addr_t phys_idmap_start)
+{
+	/*
+	 * TODO
+	 * kvm_call_reset(boot_pgd_ptr, phys_idmap_start);
+	 */
+}
+
 static inline int kvm_arch_dev_ioctl_check_extension(long ext)
 {
 	return 0;
@@ -232,7 +241,6 @@ void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);
 
 struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
 
-static inline void kvm_arch_hardware_disable(void) {}
 static inline void kvm_arch_hardware_unsetup(void) {}
 static inline void kvm_arch_sync_events(struct kvm *kvm) {}
 static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index a520b7987a29..4fd9ddb48c0f 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -66,6 +66,7 @@ void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
 phys_addr_t kvm_mmu_get_httbr(void);
 phys_addr_t kvm_mmu_get_boot_httbr(void);
 phys_addr_t kvm_get_idmap_vector(void);
+phys_addr_t kvm_get_idmap_start(void);
 int kvm_mmu_init(void);
 void kvm_clear_hyp_idmap(void);
 
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 975da6cfbf59..ee1bee7884a1 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -16,7 +16,6 @@
  * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
  */
 
-#include <linux/cpu.h>
 #include <linux/cpu_pm.h>
 #include <linux/errno.h>
 #include <linux/err.h>
@@ -65,6 +64,8 @@ static DEFINE_SPINLOCK(kvm_vmid_lock);
 
 static bool vgic_present;
 
+static DEFINE_PER_CPU(unsigned char, kvm_arm_hardware_enabled);
+
 static void kvm_arm_set_running_vcpu(struct kvm_vcpu *vcpu)
 {
 	BUG_ON(preemptible());
@@ -89,11 +90,6 @@ struct kvm_vcpu * __percpu *kvm_get_running_vcpus(void)
 	return &kvm_arm_running_vcpu;
 }
 
-int kvm_arch_hardware_enable(void)
-{
-	return 0;
-}
-
 int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
 {
 	return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
@@ -585,7 +581,13 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
 		/*
 		 * Re-check atomic conditions
 		 */
-		if (signal_pending(current)) {
+		if (unlikely(!__this_cpu_read(kvm_arm_hardware_enabled))) {
+			/* cpu has been torn down */
+			ret = 0;
+			run->exit_reason = KVM_EXIT_FAIL_ENTRY;
+			run->fail_entry.hardware_entry_failure_reason
+					= (u64)-ENOEXEC;
+		} else if (signal_pending(current)) {
 			ret = -EINTR;
 			run->exit_reason = KVM_EXIT_INTR;
 		}
@@ -967,7 +969,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
 	}
 }
 
-static void cpu_init_hyp_mode(void *dummy)
+static void cpu_init_hyp_mode(void)
 {
 	phys_addr_t boot_pgd_ptr;
 	phys_addr_t pgd_ptr;
@@ -989,36 +991,61 @@ static void cpu_init_hyp_mode(void *dummy)
 	kvm_arm_init_debug();
 }
 
-static int hyp_init_cpu_notify(struct notifier_block *self,
-			       unsigned long action, void *cpu)
+static void cpu_reset_hyp_mode(void)
 {
-	switch (action) {
-	case CPU_STARTING:
-	case CPU_STARTING_FROZEN:
-		if (__hyp_get_vectors() == hyp_default_vectors)
-			cpu_init_hyp_mode(NULL);
-		break;
+	phys_addr_t boot_pgd_ptr;
+	phys_addr_t phys_idmap_start;
+
+	boot_pgd_ptr = kvm_mmu_get_boot_httbr();
+	phys_idmap_start = kvm_get_idmap_start();
+
+	__cpu_reset_hyp_mode(boot_pgd_ptr, phys_idmap_start);
+}
+
+int kvm_arch_hardware_enable(void)
+{
+	if (!__this_cpu_read(kvm_arm_hardware_enabled)) {
+		cpu_init_hyp_mode();
+		__this_cpu_write(kvm_arm_hardware_enabled, 1);
 	}
 
-	return NOTIFY_OK;
+	return 0;
 }
 
-static struct notifier_block hyp_init_cpu_nb = {
-	.notifier_call = hyp_init_cpu_notify,
-};
+void kvm_arch_hardware_disable(void)
+{
+	if (!__this_cpu_read(kvm_arm_hardware_enabled))
+		return;
+
+	cpu_reset_hyp_mode();
+	__this_cpu_write(kvm_arm_hardware_enabled, 0);
+}
 
 #ifdef CONFIG_CPU_PM
 static int hyp_init_cpu_pm_notifier(struct notifier_block *self,
 				    unsigned long cmd,
 				    void *v)
 {
-	if (cmd == CPU_PM_EXIT &&
-	    __hyp_get_vectors() == hyp_default_vectors) {
-		cpu_init_hyp_mode(NULL);
+	/*
+	 * kvm_arm_hardware_enabled is left with its old value over
+	 * PM_ENTER->PM_EXIT. It is used to indicate PM_EXIT should
+	 * re-enable hyp.
+	 */
+	switch (cmd) {
+	case CPU_PM_ENTER:
+		if (__this_cpu_read(kvm_arm_hardware_enabled))
+			cpu_reset_hyp_mode();
+
+		return NOTIFY_OK;
+	case CPU_PM_EXIT:
+		if (__this_cpu_read(kvm_arm_hardware_enabled))
+			cpu_init_hyp_mode();
+
 		return NOTIFY_OK;
-	}
 
-	return NOTIFY_DONE;
+	default:
+		return NOTIFY_DONE;
+	}
 }
 
 static struct notifier_block hyp_init_cpu_pm_nb = {
@@ -1124,14 +1151,20 @@ static int init_hyp_mode(void)
 	}
 
 	/*
-	 * Execute the init code on each CPU.
+	 * Init this CPU temporarily to execute kvm_hyp_call()
+	 * during kvm_vgic_hyp_init().
 	 */
-	on_each_cpu(cpu_init_hyp_mode, NULL, 1);
+	preempt_disable();
+	cpu_init_hyp_mode();
 
 	/*
 	 * Init HYP view of VGIC
 	 */
 	err = kvm_vgic_hyp_init();
+
+	cpu_reset_hyp_mode();
+	preempt_enable();
+
 	switch (err) {
 	case 0:
 		vgic_present = true;
@@ -1215,26 +1248,15 @@ int kvm_arch_init(void *opaque)
 		}
 	}
 
-	cpu_notifier_register_begin();
-
 	err = init_hyp_mode();
 	if (err)
 		goto out_err;
 
-	err = __register_cpu_notifier(&hyp_init_cpu_nb);
-	if (err) {
-		kvm_err("Cannot register HYP init CPU notifier (%d)\n", err);
-		goto out_err;
-	}
-
-	cpu_notifier_register_done();
-
 	hyp_cpu_pm_init();
 
 	kvm_coproc_table_init();
 	return 0;
 out_err:
-	cpu_notifier_register_done();
 	return err;
 }
 
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index aba61fd3697a..7a3aed62499a 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -1643,6 +1643,11 @@ phys_addr_t kvm_get_idmap_vector(void)
 	return hyp_idmap_vector;
 }
 
+phys_addr_t kvm_get_idmap_start(void)
+{
+	return hyp_idmap_start;
+}
+
 int kvm_mmu_init(void)
 {
 	int err;
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index e3d67ff8798b..cdf49ce6c1ea 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -332,7 +332,6 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
 		       hyp_stack_ptr, vector_ptr);
 }
 
-static inline void kvm_arch_hardware_disable(void) {}
 static inline void kvm_arch_hardware_unsetup(void) {}
 static inline void kvm_arch_sync_events(struct kvm *kvm) {}
 static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 736433912a1e..1be7703f9de6 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -99,6 +99,7 @@ void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
 phys_addr_t kvm_mmu_get_httbr(void);
 phys_addr_t kvm_mmu_get_boot_httbr(void);
 phys_addr_t kvm_get_idmap_vector(void);
+phys_addr_t kvm_get_idmap_start(void);
 int kvm_mmu_init(void);
 void kvm_clear_hyp_idmap(void);
 
@@ -310,5 +311,24 @@ static inline unsigned int kvm_get_vmid_bits(void)
 	return (cpuid_feature_extract_field(reg, ID_AA64MMFR1_VMIDBITS_SHIFT) == 2) ? 16 : 8;
 }
 
+void __kvm_hyp_reset(phys_addr_t boot_pgd_ptr, phys_addr_t phys_idmap_start);
+
+/*
+ * Call reset code, and switch back to stub hyp vectors. We need to execute
+ * __kvm_hyp_reset() from the trampoline page, we calculate its address here,
+ * and pass it without kimage_voffset translation.
+ */
+static inline void __cpu_reset_hyp_mode(phys_addr_t boot_pgd_ptr,
+					phys_addr_t phys_idmap_start)
+{
+	unsigned long trampoline_hyp_reset;
+
+	trampoline_hyp_reset = TRAMPOLINE_VA +
+			       ((unsigned long)__kvm_hyp_reset & ~PAGE_MASK);
+
+	__kvm_call_hyp((void *)trampoline_hyp_reset,
+		       boot_pgd_ptr, phys_idmap_start);
+}
+
 #endif /* __ASSEMBLY__ */
 #endif /* __ARM64_KVM_MMU_H__ */
diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
index dc6335a7353e..d20d86c7f9d8 100644
--- a/arch/arm64/kvm/hyp-init.S
+++ b/arch/arm64/kvm/hyp-init.S
@@ -150,6 +150,48 @@ merged:
 	eret
 ENDPROC(__kvm_hyp_init)
 
+	/*
+	 * x0: HYP boot pgd
+	 * x1: HYP phys_idmap_start
+	 */
+ENTRY(__kvm_hyp_reset)
+	/*
+	 * Retrieve lr from the stack (pushed by el1_sync()), so we can eret
+	 * from here.
+	 */
+	ldp	lr, xzr, [sp], #16
+
+	/* We're in trampoline code in VA, switch back to boot page tables */
+	msr	ttbr0_el2, x0
+	isb
+
+	/* Ensure the PA branch doesn't find a stale tlb entry. */
+	tlbi	alle2
+	dsb	sy
+
+	/* Branch into PA space */
+	adr	x0, 1f
+	bfi	x1, x0, #0, #PAGE_SHIFT
+	br	x1
+
+	/* We're now in idmap, disable MMU */
+1:	mrs	x0, sctlr_el2
+	ldr	x1, =SCTLR_ELx_FLAGS
+	bic	x0, x0, x1		// Clear SCTL_M and etc
+	msr	sctlr_el2, x0
+	isb
+
+	/* Invalidate the old TLBs */
+	tlbi	alle2
+	dsb	sy
+
+	/* Install stub vectors */
+	adr_l	x0, __hyp_stub_vectors
+	msr	vbar_el2, x0
+
+	eret
+ENDPROC(__kvm_hyp_reset)
+
 	.ltorg
 
 	.popsection
-- 
2.6.2



From james.morse at arm.com  Tue Feb 16 07:49:15 2016
From: james.morse at arm.com (James Morse)
Date: Tue, 16 Feb 2016 15:49:15 +0000
Subject: [PATCH v5 03/15] arm64: Convert hcalls to use HVC immediate value
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <1455637767-31561-4-git-send-email-james.morse@arm.com>

From: Geoff Levand <geoff at infradead.org>

The existing arm64 hcall implementations are limited in that they only
allow for two distinct hcalls; with the x0 register either zero or not
zero.  Also, the API of the hyp-stub exception vector routines and the
KVM exception vector routines differ; hyp-stub uses a non-zero value in
x0 to implement __hyp_set_vectors, whereas KVM uses it to implement
kvm_call_hyp.

To allow for additional hcalls to be defined and to make the arm64 hcall
API more consistent across exception vector routines, change the hcall
implementations to use the 16 bit immediate value of the HVC instruction
to specify the hcall type.

Define three new preprocessor macros HVC_CALL_HYP, HVC_GET_VECTORS, and
HVC_SET_VECTORS to be used as hcall type specifiers and convert the
existing __hyp_get_vectors(), __hyp_set_vectors() and kvm_call_hyp()
routines to use these new macros when executing an HVC call.  Also,
change the corresponding hyp-stub and KVM el1_sync exception vector
routines to use these new macros.

Signed-off-by: Geoff Levand <geoff at infradead.org>
Signed-off-by: James Morse <james.morse at arm.com>
---
This patch comes from v13 of kexec

 arch/arm64/include/asm/virt.h  | 27 +++++++++++++++++++++++++++
 arch/arm64/kernel/hyp-stub.S   | 32 +++++++++++++++++++++-----------
 arch/arm64/kvm/hyp.S           |  3 ++-
 arch/arm64/kvm/hyp/hyp-entry.S |  9 ++++++---
 4 files changed, 56 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 7a5df5252dd7..eb10368c329e 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -18,6 +18,33 @@
 #ifndef __ASM__VIRT_H
 #define __ASM__VIRT_H
 
+/*
+ * The arm64 hcall implementation uses the ISS field of the ESR_EL2 register to
+ * specify the hcall type.  The exception handlers are allowed to use registers
+ * x17 and x18 in their implementation.  Any routine issuing an hcall must not
+ * expect these registers to be preserved.
+ */
+
+/*
+ * HVC_CALL_HYP - Execute a hyp routine.
+ */
+
+#define HVC_CALL_HYP 0
+
+/*
+ * HVC_GET_VECTORS - Return the value of the vbar_el2 register.
+ */
+
+#define HVC_GET_VECTORS 1
+
+/*
+ * HVC_SET_VECTORS - Set the value of the vbar_el2 register.
+ *
+ * @x0: Physical address of the new vector table.
+ */
+
+#define HVC_SET_VECTORS 2
+
 #define BOOT_CPU_MODE_EL1	(0xe11)
 #define BOOT_CPU_MODE_EL2	(0xe12)
 
diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
index a272f335c289..017ab519aaf1 100644
--- a/arch/arm64/kernel/hyp-stub.S
+++ b/arch/arm64/kernel/hyp-stub.S
@@ -22,6 +22,7 @@
 #include <linux/irqchip/arm-gic-v3.h>
 
 #include <asm/assembler.h>
+#include <asm/kvm_arm.h>
 #include <asm/ptrace.h>
 #include <asm/virt.h>
 
@@ -53,14 +54,22 @@ ENDPROC(__hyp_stub_vectors)
 	.align 11
 
 el1_sync:
-	mrs	x1, esr_el2
-	lsr	x1, x1, #26
-	cmp	x1, #0x16
+	mrs	x18, esr_el2
+	lsr	x17, x18, #ESR_ELx_EC_SHIFT
+	and	x18, x18, #ESR_ELx_ISS_MASK
+
+	cmp	x17, #ESR_ELx_EC_HVC64
 	b.ne	2f				// Not an HVC trap
-	cbz	x0, 1f
-	msr	vbar_el2, x0			// Set vbar_el2
+
+	cmp	x18, #HVC_GET_VECTORS
+	b.ne	1f
+	mrs	x0, vbar_el2
 	b	2f
-1:	mrs	x0, vbar_el2			// Return vbar_el2
+
+1:	cmp	x18, #HVC_SET_VECTORS
+	b.ne	2f
+	msr	vbar_el2, x0
+
 2:	eret
 ENDPROC(el1_sync)
 
@@ -100,11 +109,12 @@ ENDPROC(\label)
  * initialisation entry point.
  */
 
-ENTRY(__hyp_get_vectors)
-	mov	x0, xzr
-	// fall through
 ENTRY(__hyp_set_vectors)
-	hvc	#0
+	hvc	#HVC_SET_VECTORS
 	ret
-ENDPROC(__hyp_get_vectors)
 ENDPROC(__hyp_set_vectors)
+
+ENTRY(__hyp_get_vectors)
+	hvc	#HVC_GET_VECTORS
+	ret
+ENDPROC(__hyp_get_vectors)
diff --git a/arch/arm64/kvm/hyp.S b/arch/arm64/kvm/hyp.S
index 870578f84b1c..29e93388ebab 100644
--- a/arch/arm64/kvm/hyp.S
+++ b/arch/arm64/kvm/hyp.S
@@ -18,6 +18,7 @@
 #include <linux/linkage.h>
 
 #include <asm/assembler.h>
+#include <asm/virt.h>
 
 /*
  * u64 __kvm_call_hyp(void *hypfn, ...);
@@ -38,6 +39,6 @@
  * arch/arm64/kernel/hyp_stub.S.
  */
 ENTRY(__kvm_call_hyp)
-	hvc	#0
+	hvc	#HVC_CALL_HYP
 	ret
 ENDPROC(__kvm_call_hyp)
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
index 93e8d983c0bd..a1edf7743df6 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -43,6 +43,7 @@ el1_sync:				// Guest trapped into EL2
 
 	mrs	x1, esr_el2
 	lsr	x2, x1, #ESR_ELx_EC_SHIFT
+	and	x0, x1, #ESR_ELx_ISS_MASK
 
 	cmp	x2, #ESR_ELx_EC_HVC64
 	b.ne	el1_trap
@@ -51,14 +52,16 @@ el1_sync:				// Guest trapped into EL2
 	cbnz	x3, el1_trap		// called HVC
 
 	/* Here, we're pretty sure the host called HVC. */
+	mov	x18, x0
 	restore_x0_to_x3
 
-	/* Check for __hyp_get_vectors */
-	cbnz	x0, 1f
+	cmp	x18, #HVC_GET_VECTORS
+	b.ne	1f
 	mrs	x0, vbar_el2
 	b	2f
 
-1:	stp	lr, xzr, [sp, #-16]!
+1:     /* Default to HVC_CALL_HYP. */
+	push	lr, xzr
 
 	/*
 	 * Compute the function address in EL2, and shuffle the parameters.
-- 
2.6.2



From arnd at arndb.de  Tue Feb 16 08:03:27 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 17:03:27 +0100
Subject: [PATCH 2/2] ARM: mm: hide __start_rodata_section_aligned for
 non-debug builds
In-Reply-To: <1455638631-3326518-1-git-send-email-arnd@arndb.de>
References: <1455638631-3326518-1-git-send-email-arnd@arndb.de>
Message-ID: <1455638631-3326518-2-git-send-email-arnd@arndb.de>

The __start_rodata_section_aligned is only referenced by the
DEBUG_RODATA code, which is only used when the MMU is enabled,
but the definition fails on !MMU builds:

arch/arm/kernel/vmlinux.lds:702: undefined symbol `SECTION_SHIFT' referenced in expression

This hides the symbol whenever DEBUG_RODATA is disabled.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 64ac2e74f0b2 ("ARM: 8502/1: mm: mark section-aligned portion of rodata NX")
---
 arch/arm/kernel/vmlinux.lds.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 2d7085ae1c2f..bb12933aee22 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -322,12 +322,14 @@ SECTIONS
 	STABS_DEBUG
 }
 
+#ifdef CONFIG_DEBUG_RODATA
 /*
  * Without CONFIG_DEBUG_ALIGN_RODATA, __start_rodata_section_aligned will
  * be the first section-aligned location after __start_rodata. Otherwise,
  * it will be equal to __start_rodata.
  */
 __start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
+#endif
 
 /*
  * These must never be empty
-- 
2.7.0



From ard.biesheuvel at linaro.org  Tue Feb 16 08:05:43 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 17:05:43 +0100
Subject: [PATCH 1/2] ARM: mm: DEBUG_RODATA makes no sense with XIP_KERNEL
In-Reply-To: <1455638631-3326518-1-git-send-email-arnd@arndb.de>
References: <1455638631-3326518-1-git-send-email-arnd@arndb.de>
Message-ID: <CAKv+Gu9sMcAxNFPSYmF1y1Go_iZ0zmGwzo1wtEcBu24QjajRMw@mail.gmail.com>

On 16 February 2016 at 17:03, Arnd Bergmann <arnd at arndb.de> wrote:
> When CONFIG_DEBUG_ALIGN_RODATA is set, we get a link error:
>
> arch/arm/mm/built-in.o:(.data+0x4bc): undefined reference to `__start_rodata_section_aligned'
>
> However, this combination is useless, as XIP_KERNEL implies that all the
> RODATA is already marked readonly, so both CONFIG_DEBUG_RODATA and
> CONFIG_DEBUG_ALIGN_RODATA (which depends on the other) are not
> needed with XIP_KERNEL, and this patches enforces that using a Kconfig

s/patches/patch/

> dependency.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Acked-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

> Fixes: 25362dc496ed ("ARM: 8501/1: mm: flip priority of CONFIG_DEBUG_RODATA")
> ---
>  arch/arm/mm/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index fbf2296388ce..8894045caba9 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -1039,7 +1039,7 @@ config ARCH_SUPPORTS_BIG_ENDIAN
>
>  config DEBUG_RODATA
>         bool "Make kernel text and rodata read-only"
> -       depends on MMU
> +       depends on MMU && !XIP_KERNEL
>         default y if CPU_V7
>         help
>           If this is set, kernel text and rodata memory will be made
> --
> 2.7.0
>


From arnd at arndb.de  Tue Feb 16 08:09:43 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 17:09:43 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <s5hbn7g7izt.wl-tiwai@suse.de>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
 <s5hbn7g7izt.wl-tiwai@suse.de>
Message-ID: <2573932.AU4HSxN0NE@wuerfel>

On Tuesday 16 February 2016 16:49:42 Takashi Iwai wrote:
> 
> Thanks for the patch.  But I think it's cleaner to fix Kconfig.
> 
> Thinking more of it, maybe splitting jack stuff as a separate module
> and does reverse-select to CONFIG_INPUT would be better.  Then its
> users can select simply SND_JACK, and everything would fit.
> 
> 

Adding 'select INPUT' is rather nasty, I think that can lead to circular
dependencies, and would likely upset users of small embedded systems
that want to use audio but don't want to use input.

Generally speaking, I would recommend never using 'select' on a user
visible Kconfig symbol.

Another option might would be to change snd_jack_new() to return
an error if that SND_JACK is disabled, and then require all users
to handle the error gracefully, i.e. not fail the probe() function
but just not use the jack.

	Arnd


From joro at 8bytes.org  Tue Feb 16 08:10:09 2016
From: joro at 8bytes.org (Joerg Roedel)
Date: Tue, 16 Feb 2016 17:10:09 +0100
Subject: [PATCH v8 3/5] memory: mediatek: Add SMI driver
In-Reply-To: <56C340FB.1050607@arm.com>
References: <1453781562-23556-1-git-send-email-yong.wu@mediatek.com>
 <1453781562-23556-4-git-send-email-yong.wu@mediatek.com>
 <56ADE959.2050309@gmail.com> <20160216141059.GT18805@8bytes.org>
 <56C340FB.1050607@arm.com>
Message-ID: <20160216161009.GW18805@8bytes.org>

On Tue, Feb 16, 2016 at 03:32:11PM +0000, Robin Murphy wrote:
> Hi Joerg,
> 
> On 16/02/16 14:11, Joerg Roedel wrote:
> >On Sun, Jan 31, 2016 at 12:00:41PM +0100, Matthias Brugger wrote:
> >>
> >>
> >>On 26/01/16 05:12, Yong Wu wrote:
> >>>This patch add SMI(Smart Multimedia Interface) driver. This driver
> >>>is responsible to enable/disable iommu and control the power domain
> >>>and clocks of each local arbiter.
> >>>
> >>>Signed-off-by: Yong Wu <yong.wu at mediatek.com>
> >>>Tested-by: Philipp Zabel <p.zabel at pengutronix.de>
> >>>---
> >>
> >>Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
> >>
> >>Joerg would you mind to take this through your branch?
> >
> >Hmm, I somehow missed the patch-set, at least I can't find the v8
> >patches in my inbox.
> >
> >Yong, can you please re-send with all Acks and other tags added?
> 
> Just to note patch 4 of this series also depends on the v3
> io-pgtable short-descriptor series posted separately[1] - is that on
> your radar already or would you like that resent as well?

No, that was not on my radar, I somehow expected Will to handle this
series :)

So please resend that as well.


Thanks,

	Joerg



From vladimir.murzin at arm.com  Tue Feb 16 08:10:14 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 16:10:14 +0000
Subject: [PATCH v3 09/10] ARM: dts: introduce MPS2 AN385/AN386
In-Reply-To: <7562697.iiO7rmWd7c@wuerfel>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-10-git-send-email-vladimir.murzin@arm.com>
 <7562697.iiO7rmWd7c@wuerfel>
Message-ID: <56C349E6.2000002@arm.com>

On 16/02/16 11:01, Arnd Bergmann wrote:
> On Tuesday 16 February 2016 10:08:14 Vladimir Murzin wrote:
>> +
>> +       ethernet at 40200000 {
>> +               compatible = "smsc,lan9220", "smsc,lan9115";
>> +               reg = <0x40200000 0x10000>;
>> +               interrupts = <13>;
>> +               interrupt-parent = <&nvic>;
>> +               smsc,irq-active-high;
>> +       };
>> +};
>> +
>>
> 
> This node seems slightly misplaced. Is there some external bus interface
> that this is connected to? The address suggests that it should be somewhere
> below the /soc node, and you probably want to list the external bus
> interface with a "ranges" property that identifies the addresses visibile
> there, and put the external chip under there.
> 

I might messed it up since the MAC/PHY connects to the same 16-bit
interface as the 16MB PSRAM external memory and both connected via AHB.

Not sure how it should be expressed, so some help form DT camp would be
appreciated.

Cheers
Vladimir

> 	Arnd
> 
> 
> 



From kernel at kyup.com  Tue Feb 16 08:10:52 2016
From: kernel at kyup.com (Nikolay Borisov)
Date: Tue, 16 Feb 2016 18:10:52 +0200
Subject: [PATCH] net: igmp: use IS_ENABLED(CONFIG_IP_MULTICAST) instead of
 ifdef
In-Reply-To: <1455638393-3269483-1-git-send-email-arnd@arndb.de>
References: <1455638393-3269483-1-git-send-email-arnd@arndb.de>
Message-ID: <56C34A0C.9040207@kyup.com>



On 02/16/2016 05:59 PM, Arnd Bergmann wrote:
> A recent change to use correct network namespace in net/ipv4/igmp.c
> caused a couple of harmless build warnings when CONFIG_MULTICAST is
> disabled:
> 
> net/ipv4/igmp.c: In function 'igmp_group_added':
> net/ipv4/igmp.c:1227:14: error: unused variable 'net' [-Werror=unused-variable]
> net/ipv4/igmp.c: In function 'ip_mc_inc_group':
> net/ipv4/igmp.c:1319:14: error: unused variable 'net' [-Werror=unused-variable]
> net/ipv4/igmp.c: In function 'ip_mc_init_dev':
> net/ipv4/igmp.c:1646:14: error: unused variable 'net' [-Werror=unused-variable]
> net/ipv4/igmp.c: In function 'ip_mc_up':
> net/ipv4/igmp.c:1665:14: error: unused variable 'net' [-Werror=unused-variable]
> 
> This reworks the entire file to change each instance if '#ifdef
> CONFIG_IP_MULTICAST' to 'if (IS_ENABLED(CONFIG_IP_MULTICAST)', which
> should avoid these problems forever, and makes the whole file more
> readable.
> 
> Build-tested only.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 87a8a2ae65b7 ("igmp: Namespaceify igmp_llm_reports sysctl knob")

Overall it looks OK, just 2 minor points I could spot. See below.

[...]
> +		sf_markstate(pmc);
> +
>  	if (!delta) {
>  		err = -EINVAL;
>  		if (!pmc->sfcount[sfmode])
> @@ -1821,17 +1807,15 @@ static int ip_mc_del_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
>  		if (!err && rv < 0)
>  			err = rv;
>  	}
> -	if (pmc->sfmode == MCAST_EXCLUDE &&
> +	if (IS_ENABLED(CONFIG_IP_MULTICAST) &&
> +	    pmc->sfmode == MCAST_EXCLUDE &&
>  	    pmc->sfcount[MCAST_EXCLUDE] == 0 &&
>  	    pmc->sfcount[MCAST_INCLUDE]) {
> -#ifdef CONFIG_IP_MULTICAST
>  		struct ip_sf_list *psf;
>  		struct net *net = dev_net(in_dev->dev);
> -#endif
>  
>  		/* filter mode change */
>  		pmc->sfmode = MCAST_INCLUDE;

The above line was always executed, whereas now it wouldn't execute
unless IS_ENABLED passes.

> -#ifdef CONFIG_IP_MULTICAST
>  		pmc->crcount = in_dev->mr_qrv ?: net->ipv4.sysctl_igmp_qrv;
>  		in_dev->mr_ifc_count = pmc->crcount;
>  		for (psf = pmc->sources; psf; psf = psf->sf_next)
> @@ -1839,7 +1823,6 @@ static int ip_mc_del_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
>  		igmp_ifc_event(pmc->interface);
>  	} else if (sf_setstate(pmc) || changerec) {
>  		igmp_ifc_event(pmc->interface);
> -#endif
>  	}
....
>  /*
>   * Add multicast source filter list to the interface list
> @@ -1977,9 +1961,7 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
>  	spin_lock_bh(&pmc->lock);
>  	rcu_read_unlock();
>  
> -#ifdef CONFIG_IP_MULTICAST
>  	sf_markstate(pmc);
> -#endif

This would be executed unconditionally, which is contrary to the
original intention. Dunno if it makes a difference though.


>  	isexclude = pmc->sfmode == MCAST_EXCLUDE;
>  	if (!delta)
>  		pmc->sfcount[sfmode]++;
> @@ -1997,28 +1979,26 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
>  		for (j = 0; j < i; j++)
>  			(void) ip_mc_del1_src(pmc, sfmode, &psfsrc[j]);
>  	} else if (isexclude != (pmc->sfcount[MCAST_EXCLUDE] != 0)) {
> -#ifdef CONFIG_IP_MULTICAST
>  		struct ip_sf_list *psf;
>  		struct net *net = dev_net(pmc->interface->dev);
>  		in_dev = pmc->interface;
> -#endif
>  
>  		/* filter mode change */
>  		if (pmc->sfcount[MCAST_EXCLUDE])
>  			pmc->sfmode = MCAST_EXCLUDE;
>  		else if (pmc->sfcount[MCAST_INCLUDE])
>  			pmc->sfmode = MCAST_INCLUDE;
> -#ifdef CONFIG_IP_MULTICAST
>  		/* else no filters; keep old mode for reports */
> -
> -		pmc->crcount = in_dev->mr_qrv ?: net->ipv4.sysctl_igmp_qrv;
> -		in_dev->mr_ifc_count = pmc->crcount;
> -		for (psf = pmc->sources; psf; psf = psf->sf_next)
> -			psf->sf_crcount = 0;
> -		igmp_ifc_event(in_dev);
> -	} else if (sf_setstate(pmc)) {
> +		if (IS_ENABLED(CONFIG_IP_MULTICAST)) {
> +			pmc->crcount = in_dev->mr_qrv ?:
> +				       net->ipv4.sysctl_igmp_qrv;
> +			in_dev->mr_ifc_count = pmc->crcount;
> +			for (psf = pmc->sources; psf; psf = psf->sf_next)
> +				psf->sf_crcount = 0;
> +			igmp_ifc_event(in_dev);
> +		}
> +	} else if (IS_ENABLED(CONFIG_IP_MULTICAST) && sf_setstate(pmc)) {
>  		igmp_ifc_event(in_dev);
> -#endif
>  	}
>  	spin_unlock_bh(&pmc->lock);
>  	return err;
> @@ -2711,13 +2691,10 @@ static int igmp_mc_seq_show(struct seq_file *seq, void *v)
>  		char   *querier;
>  		long delta;
>  
> -#ifdef CONFIG_IP_MULTICAST
> -		querier = IGMP_V1_SEEN(state->in_dev) ? "V1" :
> +		querier = !IS_ENABLED(CONFIG_IP_MULTICAST) ? "NONE" :
> +			  IGMP_V1_SEEN(state->in_dev) ? "V1" :
>  			  IGMP_V2_SEEN(state->in_dev) ? "V2" :
>  			  "V3";
> -#else
> -		querier = "NONE";
> -#endif
>  
>  		if (rcu_access_pointer(state->in_dev->mc_list) == im) {
>  			seq_printf(seq, "%d\t%-10s: %5d %7s\n",
> 

Reviewed-by: Nikolay Borisov <kernel at kyup.com>


From ard.biesheuvel at linaro.org  Tue Feb 16 08:12:52 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 17:12:52 +0100
Subject: [PATCH 2/2] ARM: mm: hide __start_rodata_section_aligned for
 non-debug builds
In-Reply-To: <1455638631-3326518-2-git-send-email-arnd@arndb.de>
References: <1455638631-3326518-1-git-send-email-arnd@arndb.de>
 <1455638631-3326518-2-git-send-email-arnd@arndb.de>
Message-ID: <CAKv+Gu8JcWg4BkxZFPqTotkfHFtP744XYdSx6XROJSM_8pmt2w@mail.gmail.com>

On 16 February 2016 at 17:03, Arnd Bergmann <arnd at arndb.de> wrote:
> The __start_rodata_section_aligned is only referenced by the
> DEBUG_RODATA code, which is only used when the MMU is enabled,
> but the definition fails on !MMU builds:
>
> arch/arm/kernel/vmlinux.lds:702: undefined symbol `SECTION_SHIFT' referenced in expression
>
> This hides the symbol whenever DEBUG_RODATA is disabled.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 64ac2e74f0b2 ("ARM: 8502/1: mm: mark section-aligned portion of rodata NX")
> ---
>  arch/arm/kernel/vmlinux.lds.S | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index 2d7085ae1c2f..bb12933aee22 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -322,12 +322,14 @@ SECTIONS
>         STABS_DEBUG
>  }
>
> +#ifdef CONFIG_DEBUG_RODATA
>  /*
>   * Without CONFIG_DEBUG_ALIGN_RODATA, __start_rodata_section_aligned will
>   * be the first section-aligned location after __start_rodata. Otherwise,
>   * it will be equal to __start_rodata.
>   */
>  __start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
> +#endif
>

Does

PROVIDE(__start_rodata_section_aligned = xxx);

do the trick as well? If it does, it's a bit cleaner.


From gnomes at lxorguk.ukuu.org.uk  Tue Feb 16 08:12:56 2016
From: gnomes at lxorguk.ukuu.org.uk (One Thousand Gnomes)
Date: Tue, 16 Feb 2016 16:12:56 +0000
Subject: [PATCH v3 05/10] serial: mps2-uart: add support for early console
In-Reply-To: <CAHp75VecjR3sBcGmRHFwZPwUjXhPwV-2z4hYYJ7Y+iCOxi8_EA@mail.gmail.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-6-git-send-email-vladimir.murzin@arm.com>
 <CAHp75VdugAq0WnzLHmd9CJHCjBOdBwPqCmC3ARSaVF5XMYGoMw@mail.gmail.com>
 <56C31F9F.10000@arm.com>
 <CAHp75Vf_4MgdWunQy5hBMH5GGei+OkktFPYY-ZprY0qOEnD=wA@mail.gmail.com>
 <56C32641.4020201@arm.com>
 <CAHp75VecjR3sBcGmRHFwZPwUjXhPwV-2z4hYYJ7Y+iCOxi8_EA@mail.gmail.com>
Message-ID: <20160216161256.234a2be8@lxorguk.ukuu.org.uk>

> > If you do insist to have a counter I'll add one, but if you are not
> > strong about it I'd prefer to leave it as is.  
> 
> I would wait for Peter Hurley, Alan, or other experienced guys to talk.

I would leave it. Some of the drivers have defensive code of this form,
but mostly because they can be hot unplugged and we don't want to spin
into oblivion because the user ejected a serial card adapter.

Alan


From vladimir.murzin at arm.com  Tue Feb 16 08:14:01 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 16 Feb 2016 16:14:01 +0000
Subject: [PATCH v3 00/10] Support for Cortex-M Prototyping System
In-Reply-To: <22011981.Gqc7zXAZ81@wuerfel>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <22011981.Gqc7zXAZ81@wuerfel>
Message-ID: <56C34AC9.8080509@arm.com>

On 16/02/16 11:05, Arnd Bergmann wrote:
> On Tuesday 16 February 2016 10:08:05 Vladimir Murzin wrote:
>> Hi,
>>
>> This patch series provide the basic support for running ucLinux on V2M-MPS2
>> platform.
>>
>> With these patches applied ucLinux can be run on both HW and FVP models
>> with Cortex-M3/M4/M7 configurations.
> 
> Looks very nice overall now. I have mentioned a few details that I noticed
> but no show-stoppers.
> 
> Most important question for me is how this is going to be maintained
> in the long run. Can you add a patch to list the added files in
> MAINTAINERS?
> 
> My preference from the arm-soc perspective would be to get pull requests for
> this together with vexpress and juno through the existing maintainers
> (Liviu, Sudeep, Lorenzo), and have you send your patches to them. Does
> that work for you all?
> 

I'm quite happy with either way. I'm not targeting for 4.6, so we have
some time to sort it out.

Thanks
Vladimir

> 	Arnd
> 
> 
> 



From afd at ti.com  Tue Feb 16 08:14:48 2016
From: afd at ti.com (Andrew F. Davis)
Date: Tue, 16 Feb 2016 10:14:48 -0600
Subject: [PATCH] iio: health/afe4403: select REGMAP_SPI
In-Reply-To: <1455637959-3169264-1-git-send-email-arnd@arndb.de>
References: <1455637959-3169264-1-git-send-email-arnd@arndb.de>
Message-ID: <56C34AF8.7080104@ti.com>

On 02/16/2016 09:52 AM, Arnd Bergmann wrote:
> The newly added afe4403 driver uses the regmap facility to abstract
> the I2C and SPI access. However, it fails to ensure that regmap_spi
> is actually present:
>
> drivers/iio/built-in.o: In function `afe4403_probe':
> :(.text+0x9bf8): undefined reference to `__devm_regmap_init_spi'
>
> This adds a Kconfig select statement like the afe4404 I2C driver
> has.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: eec96d1e2d31 ("iio: health: Add driver for the TI AFE4403 heart monitor")
> ---
>   drivers/iio/health/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iio/health/Kconfig b/drivers/iio/health/Kconfig
> index f0c19779ac27..c5f004a8e447 100644
> --- a/drivers/iio/health/Kconfig
> +++ b/drivers/iio/health/Kconfig
> @@ -10,6 +10,7 @@ menu "Heart Rate Monitors"
>   config AFE4403
>   	tristate "TI AFE4403 Heart Rate Monitor"
>   	depends on SPI_MASTER
> +	select REGMAP_SPI
>   	select IIO_BUFFER
>   	select IIO_TRIGGERED_BUFFER
>   	help
>

Oversight on my part, thanks for fix.

Acked-by: Andrew F. Davis <afd at ti.com>


From tiwai at suse.de  Tue Feb 16 08:18:29 2016
From: tiwai at suse.de (Takashi Iwai)
Date: Tue, 16 Feb 2016 17:18:29 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <2573932.AU4HSxN0NE@wuerfel>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
 <s5hbn7g7izt.wl-tiwai@suse.de> <2573932.AU4HSxN0NE@wuerfel>
Message-ID: <s5h4md87hnu.wl-tiwai@suse.de>

On Tue, 16 Feb 2016 17:09:43 +0100,
Arnd Bergmann wrote:
> 
> On Tuesday 16 February 2016 16:49:42 Takashi Iwai wrote:
> > 
> > Thanks for the patch.  But I think it's cleaner to fix Kconfig.
> > 
> > Thinking more of it, maybe splitting jack stuff as a separate module
> > and does reverse-select to CONFIG_INPUT would be better.  Then its
> > users can select simply SND_JACK, and everything would fit.
> > 
> > 
> 
> Adding 'select INPUT' is rather nasty, I think that can lead to circular
> dependencies, and would likely upset users of small embedded systems
> that want to use audio but don't want to use input.

Fair enough.

> Generally speaking, I would recommend never using 'select' on a user
> visible Kconfig symbol.
>
> Another option might would be to change snd_jack_new() to return
> an error if that SND_JACK is disabled, and then require all users
> to handle the error gracefully, i.e. not fail the probe() function
> but just not use the jack.

Yes, I thought of that, too.  If select is no good option, it's a good
alternative, indeed.


Takashi


From will.deacon at arm.com  Tue Feb 16 08:20:00 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 16 Feb 2016 16:20:00 +0000
Subject: [PATCH v8 3/5] memory: mediatek: Add SMI driver
In-Reply-To: <20160216161009.GW18805@8bytes.org>
References: <1453781562-23556-1-git-send-email-yong.wu@mediatek.com>
 <1453781562-23556-4-git-send-email-yong.wu@mediatek.com>
 <56ADE959.2050309@gmail.com> <20160216141059.GT18805@8bytes.org>
 <56C340FB.1050607@arm.com> <20160216161009.GW18805@8bytes.org>
Message-ID: <20160216162000.GI14509@arm.com>

On Tue, Feb 16, 2016 at 05:10:09PM +0100, Joerg Roedel wrote:
> On Tue, Feb 16, 2016 at 03:32:11PM +0000, Robin Murphy wrote:
> > On 16/02/16 14:11, Joerg Roedel wrote:
> > >On Sun, Jan 31, 2016 at 12:00:41PM +0100, Matthias Brugger wrote:
> > >>On 26/01/16 05:12, Yong Wu wrote:
> > >>>This patch add SMI(Smart Multimedia Interface) driver. This driver
> > >>>is responsible to enable/disable iommu and control the power domain
> > >>>and clocks of each local arbiter.
> > >>>
> > >>>Signed-off-by: Yong Wu <yong.wu at mediatek.com>
> > >>>Tested-by: Philipp Zabel <p.zabel at pengutronix.de>
> > >>>---
> > >>
> > >>Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
> > >>
> > >>Joerg would you mind to take this through your branch?
> > >
> > >Hmm, I somehow missed the patch-set, at least I can't find the v8
> > >patches in my inbox.
> > >
> > >Yong, can you please re-send with all Acks and other tags added?
> > 
> > Just to note patch 4 of this series also depends on the v3
> > io-pgtable short-descriptor series posted separately[1] - is that on
> > your radar already or would you like that resent as well?
> 
> No, that was not on my radar, I somehow expected Will to handle this
> series :)

I'm more than happy to bake a branch containing all the page table stuff,
but Yong's stuff depends on it so I'll work with whatever is easiest for
you.

Will


From gerald.schaefer at de.ibm.com  Tue Feb 16 08:24:44 2016
From: gerald.schaefer at de.ibm.com (Gerald Schaefer)
Date: Tue, 16 Feb 2016 17:24:44 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe
 also on PowerPC and ARM)
In-Reply-To: <20160215213526.GA9766@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
 <alpine.LFD.2.20.1602131238260.1910@schleppi>
 <20160215113159.GA28832@node.shutemov.name>
 <20160215193702.4a15ed5e@thinkpad>
 <20160215213526.GA9766@node.shutemov.name>
Message-ID: <20160216172444.013988d8@thinkpad>

On Mon, 15 Feb 2016 23:35:26 +0200
"Kirill A. Shutemov" <kirill at shutemov.name> wrote:

> On Mon, Feb 15, 2016 at 07:37:02PM +0100, Gerald Schaefer wrote:
> > On Mon, 15 Feb 2016 13:31:59 +0200
> > "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> > 
> > > On Sat, Feb 13, 2016 at 12:58:31PM +0100, Sebastian Ott wrote:
> > > > 
> > > > On Sat, 13 Feb 2016, Kirill A. Shutemov wrote:
> > > > > Could you check if revert of fecffad25458 helps?
> > > > 
> > > > I reverted fecffad25458 on top of 721675fcf277cf - it oopsed with:
> > > > 
> > > > ? 1851.721062! Unable to handle kernel pointer dereference in virtual kernel address space
> > > > ? 1851.721075! failing address: 0000000000000000 TEID: 0000000000000483
> > > > ? 1851.721078! Fault in home space mode while using kernel ASCE.
> > > > ? 1851.721085! AS:0000000000d5c007 R3:00000000ffff0007 S:00000000ffffa800 P:000000000000003d
> > > > ? 1851.721128! Oops: 0004 ilc:3 ?#1! PREEMPT SMP DEBUG_PAGEALLOC
> > > > ? 1851.721135! Modules linked in: bridge stp llc btrfs mlx4_ib mlx4_en ib_sa ib_mad vxlan xor ip6_udp_tunnel ib_core udp_tunnel ptp pps_core ib_addr ghash_s390raid6_pq prng ecb aes_s390 mlx4_core des_s390 des_generic genwqe_card sha512_s390 sha256_s390 sha1_s390 sha_common crc_itu_t dm_mod scm_block vhost_net tun vhost eadm_sch macvtap macvlan kvm autofs4
> > > > ? 1851.721183! CPU: 7 PID: 256422 Comm: bash Not tainted 4.5.0-rc3-00058-g07923d7-dirty #178
> > > > ? 1851.721186! task: 000000007fbfd290 ti: 000000008c604000 task.ti: 000000008c604000
> > > > ? 1851.721189! Krnl PSW : 0704d00180000000 000000000045d3b8 (__rb_erase_color+0x280/0x308)
> > > > ? 1851.721200!            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
> > > >                Krnl GPRS: 0000000000000001 0000000000000020 0000000000000000 00000000bd07eff1
> > > > ? 1851.721205!            000000000027ca10 0000000000000000 0000000083e45898 0000000077b61198
> > > > ? 1851.721207!            000000007ce1a490 00000000bd07eff0 000000007ce1a548 000000000027ca10
> > > > ? 1851.721210!            00000000bd07c350 00000000bd07eff0 000000008c607aa8 000000008c607a68
> > > > ? 1851.721221! Krnl Code: 000000000045d3aa: e3c0d0080024       stg     %%r12,8(%%r13)
> > > >                           000000000045d3b0: b9040039           lgr     %%r3,%%r9
> > > >                          #000000000045d3b4: a53b0001           oill    %%r3,1
> > > >                          >000000000045d3b8: e33010000024       stg     %%r3,0(%%r1)
> > > >                           000000000045d3be: ec28000e007c       cgij    %%r2,0,8,45d3da
> > > >                           000000000045d3c4: e34020000004       lg      %%r4,0(%%r2)
> > > >                           000000000045d3ca: b904001c           lgr     %%r1,%%r12
> > > >                           000000000045d3ce: ec143f3f0056       rosbg   %%r1,%%r4,63,63,0
> > > > ? 1851.721269! Call Trace:
> > > > ? 1851.721273! (?<0000000083e45898>! 0x83e45898)
> > > > ? 1851.721279!  ?<000000000029342a>! unlink_anon_vmas+0x9a/0x1d8
> > > > ? 1851.721282!  ?<0000000000283f34>! free_pgtables+0xcc/0x148
> > > > ? 1851.721285!  ?<000000000028c376>! exit_mmap+0xd6/0x300
> > > > ? 1851.721289!  ?<0000000000134db8>! mmput+0x90/0x118
> > > > ? 1851.721294!  ?<00000000002d76bc>! flush_old_exec+0x5d4/0x700
> > > > ? 1851.721298!  ?<00000000003369f4>! load_elf_binary+0x2f4/0x13e8
> > > > ? 1851.721301!  ?<00000000002d6e4a>! search_binary_handler+0x9a/0x1f8
> > > > ? 1851.721304!  ?<00000000002d8970>! do_execveat_common.isra.32+0x668/0x9a0
> > > > ? 1851.721307!  ?<00000000002d8cec>! do_execve+0x44/0x58
> > > > ? 1851.721310!  ?<00000000002d8f92>! SyS_execve+0x3a/0x48
> > > > ? 1851.721315!  ?<00000000006fb096>! system_call+0xd6/0x258
> > > > ? 1851.721317!  ?<000003ff997436d6>! 0x3ff997436d6
> > > > ? 1851.721319! INFO: lockdep is turned off.
> > > > ? 1851.721321! Last Breaking-Event-Address:
> > > > ? 1851.721323!  ?<000000000045d31a>! __rb_erase_color+0x1e2/0x308
> > > > ? 1851.721327!
> > > > ? 1851.721329! ---? end trace 0d80041ac00cfae2 !---
> > > > 
> > > > 
> > > > > 
> > > > > And could you share how crashes looks like? I haven't seen backtraces yet.
> > > > > 
> > > > 
> > > > Sure. I didn't because they really looked random to me. Most of the time
> > > > in rcu or list debugging but I thought these have just been the messenger
> > > > observing a corruption first. Anyhow, here is an older one that might look
> > > > interesting:
> > > > 
> > > > [   59.851421] list_del corruption. next->prev should be 000000006e1eb000, but was 0000000000000400
> > > 
> > > This kinda interesting: 0x400 is TAIL_MAPPING.. Hm..
> > > 
> > > Could you check if you see the problem on commit 1c290f642101 and its
> > > immediate parent?
> > > 
> > 
> > How should the page->mapping poison end up as next->prev in the list of
> > pre-allocated THP splitting page tables?
> 
> May be pgtable was casted to struct page or something. I don't know.
> 
> > Also, commit 1c290f642101 is before the THP rework, at least the
> > non-bisectable part, so we should expect not to see the problem there.
> 
> Just to make sure: commit 122afea9626a is fine, commit 61f5d698cc97
> crashes. Correct?
> 
> > 0x400 is also the value of an empty pte on s390, and the thp_deposit/withdraw
> > listheads are placed inside the pre-allocated pagetables instead of page->lru,
> > because we have 2K pagetables on s390 and cannot use struct page == pgtable_t.
> 
> 0x400 from empty pte makes more sense than TAIL_MAPPING. But I guess it
> worth changing TAIL_MAPPING to some other value to make sure.

Right, but we cannot trigger this list corruption symptom reliably, in fact
I didn't hit it at all during the last runs, and previous crash logs also
showed list corruptions with other values than 0x400, which may hint towards
concurrent pagetable freeing and re-use, given that our THP splitting pagetable
listhead is located inside the pre-allocated pagetables.

> 
> > So, for example, two concurrent withdraws could produce such a list
> > corruption, because the first withdraw will overwrite the listhead at the
> > beginning of the pagetable with 2 empty ptes.
> > 
> > Has anything changed regarding the general THP deposit/withdraw logic?
> 
> I don't see any changes in this area.
> 
> To eliminate one more variable, I would propose to disable split pmd lock
> for testing and check if it makes difference.

Disabling ARCH_ENABLE_SPLIT_PMD_PTLOCK didn't make any difference, other
than maybe a little reduction in "randomness" of the crashes, but that
may be pure coincidence. Out of about 10 runs, I always ended up with either
ODEBUG "WARNING: at lib/debugobjects.c:263" and subsequent "kernel BUG at
mm/slub.c:3629", or "bad swap file / page map" with subsequent "kernel BUG
at kernel/cred.c:142", see below for the full traces.

> 
> Is there any chance that I'll be able to trigger the bug using QEMU?
> Does anybody have an QEMU image I can use?
> 

I have no image, but trying to reproduce this under virtualization may
help to trigger this also on other architectures. After ruling out IPI
vs. fast_gup I do not really see why this should be arch-specific, and
it wouldn't be the first time that we hit subtle races first on s390, due
to our virtualized environment (my test case is make -j20 with 10 CPUs and
4GB of memory, no swap).


Here are the full traces from the runs w/o split pmd lock:

1)

[ 2584.391880] cc1 (71885) used greatest stack depth: 10496 bytes left
[ 2951.268250] ld (147667) used greatest stack depth: 10472 bytes left
[ 2972.530753] swap_free: Bad swap file entry 1000000000000000
[ 2972.530763] BUG: Bad page map in process cc1  pte:00000420 pmd:6cfd3000
[ 2972.530766] addr:0000000080d00000 vm_flags:00000875 anon_vma:          (null) mapping:000000005dc6ac70 index
:d00
[ 2972.530776] file:cc1 fault:ext4_filemap_fault mmap:ext4_file_mmap readpage:ext4_readpage
[ 2972.530781] CPU: 6 PID: 152043 Comm: cc1 Not tainted 4.5.0-rc4-00014-g1926e54-dirty #70
[ 2972.530784]        0000000071947a60 0000000071947af0 0000000000000002 0000000000000000 
                      0000000071947b90 0000000071947b08 0000000071947b08 0000000000113d38 
                      0000000000000000 0000000000b70df4 0000000000b4f348 000000000000000b 
                      0000000071947b50 0000000071947af0 0000000000000000 0000000000000000 
                      07000000c3763ae8 0000000000113d38 0000000071947af0 0000000071947b50 
[ 2972.530811] Call Trace:
[ 2972.530818] ([<0000000000113c3c>] show_trace+0x12c/0x150)
[ 2972.530821]  [<0000000000113cee>] show_stack+0x8e/0xf0
[ 2972.530826]  [<000000000068b8ec>] dump_stack+0x9c/0xe0
[ 2972.530830]  [<00000000002bbeda>] print_bad_pte+0x222/0x238
[ 2972.530833]  [<00000000002beb92>] zap_pte_range+0x442/0x790
[ 2972.530835]  [<00000000002bf2c6>] unmap_single_vma+0x3e6/0x400
[ 2972.530837]  [<00000000002c0f46>] unmap_vmas+0x8e/0xc8
[ 2972.530840]  [<00000000002c9a56>] exit_mmap+0xc6/0x300
[ 2972.530844]  [<0000000000138b10>] mmput+0xa0/0x128
[ 2972.530847]  [<000000000013fcb4>] do_exit+0x42c/0xd60
[ 2972.530849]  [<00000000001406f0>] do_group_exit+0x98/0xe0
[ 2972.530851]  [<0000000000140768>] __wake_up_parent+0x0/0x28
[ 2972.530855]  [<0000000000910f2e>] system_call+0xd6/0x270
[ 2972.530883]  [<000003ff89b43698>] 0x3ff89b43698
[ 2972.530886] 1 lock held by cc1/152043:
[ 2972.530887]  #0:  (&(ptlock_ptr(page))->rlock){+.+.-.}, at: [<00000000002be7f6>] zap_pte_range+0xa6/0x790
[ 2972.530897] Disabling lock debugging due to kernel taint
[ 2972.533069] BUG: Bad rss-counter state mm:00000000719d0e00 idx:2 val:-1
[ 5899.109157] ------------[ cut here ]------------
[ 5899.109166] kernel BUG at kernel/cred.c:142!
[ 5899.109211] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 5899.109217] Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc mlx4_ib ib_sa ib_mad mlx4_en ib_core vxlan udp_tunnel ptp ib_addr pps_core ghash_s390 prng ecb aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common mlx4_core eadm_sch nfsd vhost_net tun vhost macvtap auth_rpcgss macvlan kvm oid_registry nfs_acl lockd grace sunrpc dm_multipath dm_mod autofs4
[ 5899.109279] CPU: 1 PID: 12 Comm: ksoftirqd/1 Tainted: G    B           4.5.0-rc4-00014-g1926e54-dirty #70
[ 5899.109283] task: 00000000d09e2a48 ti: 00000000d09f4000 task.ti: 00000000d09f4000
[ 5899.109286] Krnl PSW : 0704c00180000000 00000000001651aa (__put_cred+0x22/0x68)
[ 5899.109296]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
               Krnl GPRS: 0000000000000002 0000000000000020 000000007431f000 00000000c38e3400
[ 5899.109301]            000000000032aaf8 0000000000000002 0000000000000000 000000000000000a
[ 5899.109304]            0000000000000000 000000000032aac0 0000000000000008 00000000749ad000
[ 5899.109306]            00000000c38e3400 000000007431f000 000000000032ab2e 00000000d09f7bf0
[ 5899.109316] Krnl Code: 000000000016519c: 58102004            l       %%r1,4(%%r2)
                          00000000001651a0: ec180005007e        cij     %%r1,0,8,1651aa
                         #00000000001651a6: a7f40001            brc     15,1651a8
                         >00000000001651aa: e3e020080024        stg     %%r14,8(%%r2)
                          00000000001651b0: c01944656144        iilf    %%r1,1147494724
                          00000000001651b6: 50102010            st      %%r1,16(%%r2)
                          00000000001651ba: e31003100004        lg      %%r1,784
                          00000000001651c0: e32018300020        cg      %%r2,2096(%%r1)
[ 5899.109371] Call Trace:
[ 5899.109376] ([<000000000032aaf8>] file_free_rcu+0x38/0x88)
[ 5899.109381]  [<00000000001c5ddc>] rcu_process_callbacks+0x5fc/0x9f0
[ 5899.109385]  [<0000000000141794>] __do_softirq+0x25c/0x570
[ 5899.109387]  [<0000000000141ae6>] run_ksoftirqd+0x3e/0xa0
[ 5899.109391]  [<0000000000167bee>] smpboot_thread_fn+0x30e/0x360
[ 5899.109394]  [<0000000000162f4a>] kthread+0x112/0x128
[ 5899.109398]  [<00000000009110fa>] kernel_thread_starter+0x6/0xc
[ 5899.109401]  [<00000000009110f4>] kernel_thread_starter+0x0/0xc
[ 5899.109403] INFO: lockdep is turned off.
[ 5899.109405] Last Breaking-Event-Address:
[ 5899.109407]  [<00000000001651a6>] __put_cred+0x1e/0x68
[ 5899.109411]  
[ 5899.109414] Kernel panic - not syncing: Fatal exception in interrupt


2)

[ 7790.934295] ODEBUG: active_state not available (active state 0) object type: rcu_head hint:           (null)
[ 7790.934356] ------------[ cut here ]------------
[ 7790.934359] WARNING: at lib/debugobjects.c:263
[ 7790.934361] Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack mlx4_ib ib_sa ipt_REJECT mlx4_en ib_mad nf_reject_ipv4 ib_core vxlan udp_tunnel ptp xt_tcpudp ib_addr pps_core iptable_filter ip_tables x_tables bridge stp llc ghash_s390 prng ecb aes_s390 des_s390 des_generic sha512_s390 sha256_s390 mlx4_core sha1_s390 sha_common eadm_sch vhost_net nfsd tun vhost macvtap macvlan auth_rpcgss kvm oid_registry nfs_acl lockd grace sunrpc dm_multipath dm_mod autofs4
[ 7790.934417] CPU: 8 PID: 40 Comm: ksoftirqd/8 Not tainted 4.5.0-rc4-00014-g1926e54-dirty #149
[ 7790.934420] task: 00000000e2955490 ti: 00000000e2958000 task.ti: 00000000e2958000
[ 7790.934422] Krnl PSW : 0404c00180000000 000000000071c340 (debug_print_object+0xb0/0xd0)
[ 7790.934431]            R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
               Krnl GPRS: 0000000001e6e3c7 00000000e2955490 0000000000000060 00000000e2958000
[ 7790.934435]            000000000071c33c 0000000000000000 0000000000b975e8 0000000001f2b008
[ 7790.934437]            07000000001d7e24 0000000000000000 0000000001f2b010 0000000000bea6b8
[ 7790.934440]            0000000000e241f8 00000000e295bc38 000000000071c33c 00000000e295bb38
[ 7790.934449] Krnl Code: 000000000071c330: c41f00bf6a14        strl    %%r1,1f09758
                          000000000071c336: c0e5ffdbd64d        brasl   %%r14,296fd0
                         #000000000071c33c: a7f40001            brc     15,71c33e
                         >000000000071c340: c41d0036e746        lrl     %%r1,df91cc
                          000000000071c346: e340f0e80004        lg      %%r4,232(%%r15)
                          000000000071c34c: a71a0001            ahi     %%r1,1
                          000000000071c350: eb6ff0a80004        lmg     %%r6,%%r15,168(%%r15)
                          000000000071c356: c41f0036e73b        strl    %%r1,df91cc
[ 7790.934493] Call Trace:
[ 7790.934495] ([<000000000071c33c>] debug_print_object+0xac/0xd0)
[ 7790.934498]  [<000000000071d704>] debug_object_active_state+0x164/0x178
[ 7790.934504]  [<00000000001d7da4>] rcu_process_callbacks+0x57c/0xa00
[ 7790.934508]  [<00000000001487ec>] __do_softirq+0x26c/0x580
[ 7790.934510]  [<0000000000148b50>] run_ksoftirqd+0x50/0xb0
[ 7790.934515]  [<0000000000172b28>] smpboot_thread_fn+0x320/0x378
[ 7790.934517]  [<000000000016d21c>] kthread+0x124/0x138
[ 7790.934521]  [<00000000009a1d72>] kernel_thread_starter+0x6/0xc
[ 7790.934524]  [<00000000009a1d6c>] kernel_thread_starter+0x0/0xc
[ 7790.934526] 1 lock held by ksoftirqd/8/40:
[ 7790.934528]  #0:  (&obj_hash[i].lock){-.-.-.}, at: [<000000000071d64c>] debug_object_active_state+0xac/0x178
[ 7790.934535] Last Breaking-Event-Address:
[ 7790.934537]  [<000000000071c33c>] debug_print_object+0xac/0xd0
[ 7790.934539] ---[ end trace b583bfd967a78637 ]---
[ 7790.934543] ODEBUG: deactivate not available (active state 0) object type: rcu_head hint:           (null)
[ 7790.934551] ------------[ cut here ]------------
[ 7790.934553] WARNING: at lib/debugobjects.c:263
[ 7790.934555] Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack mlx4_ib ib_sa ipt_REJECT mlx4_en ib_mad nf_reject_ipv4 ib_core vxlan udp_tunnel ptp xt_tcpudp ib_addr pps_core iptable_filter ip_tables x_tables bridge stp llc ghash_s390 prng ecb aes_s390 des_s390 des_generic sha512_s390 sha256_s390 mlx4_core sha1_s390 sha_common eadm_sch vhost_net nfsd tun vhost macvtap macvlan auth_rpcgss kvm oid_registry nfs_acl lockd grace sunrpc dm_multipath dm_mod autofs4
[ 7790.934599] CPU: 8 PID: 40 Comm: ksoftirqd/8 Tainted: G        W       4.5.0-rc4-00014-g1926e54-dirty #149
[ 7790.934601] task: 00000000e2955490 ti: 00000000e2958000 task.ti: 00000000e2958000
[ 7790.934603] Krnl PSW : 0404c00180000000 000000000071c340 (debug_print_object+0xb0/0xd0)
[ 7790.934608]            R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
               Krnl GPRS: 0000000001e6e3c7 00000000e2955490 000000000000005e 00000000e2958000
[ 7790.934612]            000000000071c33c 0000000000000000 0000000000b975e8 000000000000000a
[ 7790.934614]            0000000004bcd020 0700000001f2b010 0000000001f2b010 0000000000ba5d0a
[ 7790.934617]            0000000000e241f8 00000000e295bc48 000000000071c33c 00000000e295bb48
[ 7790.934622] Krnl Code: 000000000071c330: c41f00bf6a14        strl    %%r1,1f09758
                          000000000071c336: c0e5ffdbd64d        brasl   %%r14,296fd0
                         #000000000071c33c: a7f40001            brc     15,71c33e
                         >000000000071c340: c41d0036e746        lrl     %%r1,df91cc
                          000000000071c346: e340f0e80004        lg      %%r4,232(%%r15)
                          000000000071c34c: a71a0001            ahi     %%r1,1
                          000000000071c350: eb6ff0a80004        lmg     %%r6,%%r15,168(%%r15)
                          000000000071c356: c41f0036e73b        strl    %%r1,df91cc
[ 7790.934639] Call Trace:
[ 7790.934641] ([<000000000071c33c>] debug_print_object+0xac/0xd0)
[ 7790.934644]  [<000000000071d0a8>] debug_object_deactivate+0x170/0x188
[ 7790.934646]  [<00000000001d7db6>] rcu_process_callbacks+0x58e/0xa00
[ 7790.934648]  [<00000000001487ec>] __do_softirq+0x26c/0x580
[ 7790.934651]  [<0000000000148b50>] run_ksoftirqd+0x50/0xb0
[ 7790.934653]  [<0000000000172b28>] smpboot_thread_fn+0x320/0x378
[ 7790.934655]  [<000000000016d21c>] kthread+0x124/0x138
[ 7790.934657]  [<00000000009a1d72>] kernel_thread_starter+0x6/0xc
[ 7790.934659]  [<00000000009a1d6c>] kernel_thread_starter+0x0/0xc
[ 7790.934661] 1 lock held by ksoftirqd/8/40:
[ 7790.934663]  #0:  (&obj_hash[i].lock){-.-.-.}, at: [<000000000071cfdc>] debug_object_deactivate+0xa4/0x188
[ 7790.934669] Last Breaking-Event-Address:
[ 7790.934671]  [<000000000071c33c>] debug_print_object+0xac/0xd0
[ 7790.934673] ---[ end trace b583bfd967a78638 ]---
[ 7790.934680] ------------[ cut here ]------------
[ 7790.934682] kernel BUG at mm/slub.c:3629!
[ 7790.934707] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 7790.934715] Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack mlx4_ib ib_sa ipt_REJECT mlx4_en ib_mad nf_reject_ipv4 ib_core vxlan udp_tunnel ptp xt_tcpudp ib_addr pps_core iptable_filter ip_tables x_tables bridge stp llc ghash_s390 prng ecb aes_s390 des_s390 des_generic sha512_s390 sha256_s390 mlx4_core sha1_s390 sha_common eadm_sch vhost_net nfsd tun vhost macvtap macvlan auth_rpcgss kvm oid_registry nfs_acl lockd grace sunrpc dm_multipath dm_mod autofs4
[ 7790.934789] CPU: 8 PID: 40 Comm: ksoftirqd/8 Tainted: G        W       4.5.0-rc4-00014-g1926e54-dirty #149
[ 7790.934791] task: 00000000e2955490 ti: 00000000e2958000 task.ti: 00000000e2958000
[ 7790.934794] Krnl PSW : 0704c00180000000 000000000032295a (kfree+0x3f2/0x428)
[ 7790.934801]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
               Krnl GPRS: 0000000000000000 0000000000000100 0000000000000100 0000000000e24260
[ 7790.934806]            00000000001d1c82 0000000000000000 0000000000000000 000000000000000a
[ 7790.934809]            0000000000000001 00000000001d7e0a 0000000000000006 000003d10012f340
[ 7790.934812]            0000000004bcd000 0000000000f0433c 000000000032267a 00000000e295bbb0
[ 7790.934818] Krnl Code: 000000000032294c: c0e50033bef6        brasl   %%r14,99a738
                          0000000000322952: a7f4feba            brc     15,3226c6
                         #0000000000322956: a7f40001            brc     15,322958
                         >000000000032295a: e310b0060090        llgc    %%r1,6(%%r11)
                          0000000000322960: a7110040            tmll    %%r1,64
                          0000000000322964: a774fee9            brc     7,322736
                          0000000000322968: a7f4feeb            brc     15,32273e
                          000000000032296c: c0e50033be32        brasl   %%r14,99a5d0
[ 7790.934838] Call Trace:
[ 7790.934841] ([<000000000032267a>] kfree+0x112/0x428)
[ 7790.934844]  [<00000000001d7e0a>] rcu_process_callbacks+0x5e2/0xa00
[ 7790.934847]  [<00000000001487ec>] __do_softirq+0x26c/0x580
[ 7790.934850]  [<0000000000148b50>] run_ksoftirqd+0x50/0xb0
[ 7790.934854]  [<0000000000172b28>] smpboot_thread_fn+0x320/0x378
[ 7790.934856]  [<000000000016d21c>] kthread+0x124/0x138
[ 7790.934859]  [<00000000009a1d72>] kernel_thread_starter+0x6/0xc
[ 7790.934862]  [<00000000009a1d6c>] kernel_thread_starter+0x0/0xc
[ 7790.934864] INFO: lockdep is turned off.
[ 7790.934866] Last Breaking-Event-Address:
[ 7790.934869]  [<0000000000322956>] kfree+0x3ee/0x428
[ 7790.934873]  
[ 7790.934876] Kernel panic - not syncing: Fatal exception in interrupt



From arnd at arndb.de  Tue Feb 16 08:12:57 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 17:12:57 +0100
Subject: [PATCH 3/4] gpio: ep93xx: remove private irq_to_gpio function
In-Reply-To: <CACRpkdb3nKTEDCvafURhKRPJipJ=K_y1oyE_kKc=-T8E=Bai0g@mail.gmail.com>
References: <20160202194831.10827.63244.stgit@bhelgaas-glaptop2.roam.corp.google.com>
 <1455551208-2825510-4-git-send-email-arnd@arndb.de>
 <CACRpkdb3nKTEDCvafURhKRPJipJ=K_y1oyE_kKc=-T8E=Bai0g@mail.gmail.com>
Message-ID: <12288210.VhBfyMlq8V@wuerfel>

On Tuesday 16 February 2016 16:51:57 Linus Walleij wrote:
> On Mon, Feb 15, 2016 at 4:46 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> 
> > The ep93xx goes through its own back-and-forth dance every time
> > it wants to know the gpio number for an irq line, when it really
> > just hardcodes a fixed offset in ep93xx_gpio_to_irq().
> >
> > This removes the pointless macro and replaces the conversion inside
> > of the driver with simple add/subtract operations, using an
> > explicit macro.
> >
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> (...)
> 
> > -#include <linux/gpio/driver.h>
> > -/* FIXME: this is here for gpio_to_irq() - get rid of this! */
> >  #include <linux/gpio.h>
> 
> No, what you want to get rid of is the #include <linux/gpio.h> not the
> <linux/gpio/driver.h>, we want to be more specific. Sorry for putting the
> comment wrong.

I think I initially did that, but ran into another build error then.

> 
> > @@ -35,6 +31,7 @@ void __iomem *ep93xx_gpio_base; /* FIXME: put this into irq_data */
> >  #define EP93XX_GPIO_LINE_MAX           63
> >
> >  /* maximum value for irq capable line identifiers */
> > +#define EP93XX_GPIO_IRQ_BASE           64
> >  #define EP93XX_GPIO_LINE_MAX_IRQ       23
> 
> This doesn't apply to my tree :O
> 
> My EP93XX_GPIO_LINE_MAX_IRQ is in
> arch/arm/mach-ep93xx/include/mach/gpio-ep93xx.h
> 
> So I think you must be having another patch somewhere in the ARM SoC
> tree. (I can take it, just send it along with an update of this one.)

Ah, that is right. Let's just drop this patch for now,
it's not important.

I have an old patch below to make the driver independent of
the headers, but I have to look at that patch again before
submitting it. I'll sort this one next to it.

	Arnd


From joro at 8bytes.org  Tue Feb 16 08:26:41 2016
From: joro at 8bytes.org (Joerg Roedel)
Date: Tue, 16 Feb 2016 17:26:41 +0100
Subject: [PATCH v8 3/5] memory: mediatek: Add SMI driver
In-Reply-To: <20160216162000.GI14509@arm.com>
References: <1453781562-23556-1-git-send-email-yong.wu@mediatek.com>
 <1453781562-23556-4-git-send-email-yong.wu@mediatek.com>
 <56ADE959.2050309@gmail.com> <20160216141059.GT18805@8bytes.org>
 <56C340FB.1050607@arm.com> <20160216161009.GW18805@8bytes.org>
 <20160216162000.GI14509@arm.com>
Message-ID: <20160216162641.GY18805@8bytes.org>

On Tue, Feb 16, 2016 at 04:20:00PM +0000, Will Deacon wrote:
> I'm more than happy to bake a branch containing all the page table stuff,
> but Yong's stuff depends on it so I'll work with whatever is easiest for
> you.

Okay, to the best is if you would collect all the page table patches and
send me a pull-request. I pull that into my tree then and put Yong's
stuff on-top.



	Joerg



From will.deacon at arm.com  Tue Feb 16 08:28:02 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 16 Feb 2016 16:28:02 +0000
Subject: [PATCH v8 3/5] memory: mediatek: Add SMI driver
In-Reply-To: <20160216162641.GY18805@8bytes.org>
References: <1453781562-23556-1-git-send-email-yong.wu@mediatek.com>
 <1453781562-23556-4-git-send-email-yong.wu@mediatek.com>
 <56ADE959.2050309@gmail.com> <20160216141059.GT18805@8bytes.org>
 <56C340FB.1050607@arm.com> <20160216161009.GW18805@8bytes.org>
 <20160216162000.GI14509@arm.com>
 <20160216162641.GY18805@8bytes.org>
Message-ID: <20160216162801.GJ14509@arm.com>

On Tue, Feb 16, 2016 at 05:26:41PM +0100, Joerg Roedel wrote:
> On Tue, Feb 16, 2016 at 04:20:00PM +0000, Will Deacon wrote:
> > I'm more than happy to bake a branch containing all the page table stuff,
> > but Yong's stuff depends on it so I'll work with whatever is easiest for
> > you.
> 
> Okay, to the best is if you would collect all the page table patches and
> send me a pull-request. I pull that into my tree then and put Yong's
> stuff on-top.

Okey doke, I'll put something together this week.

Cheers,

Will


From kernel at martin.sperl.org  Tue Feb 16 08:31:41 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Tue, 16 Feb 2016 17:31:41 +0100
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in
 console
In-Reply-To: <359843746.379810.6eb6c2f5-8282-417a-83d1-1fa79425ff73.open-xchange@email.1und1.de>
References: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
 <56BC895E.2010108@sperl.org>
 <1617009200.323700.219000a8-c162-4594-aacc-a7e9894518b2.open-xchange@email.1und1.de>
 <662D2FB2-B088-4CFC-8416-A4F35BBAD7DD@sperl.org>
 <F7A2533A-D64C-4187-ABD4-416C446D1637@martin.sperl.org>
 <6CD3FC59-BA17-43D9-897C-A2D122D26EF8@martin.sperl.org>
 <470852136.382408.76a8faee-9235-4ee0-9fd1-e25a1e9f0bb3.open-xchange@email.1und1.de>
 <EE05C090-EB8A-41E8-B9C3-8CCC79F15FE9@martin.sperl.org>
 <359843746.379810.6eb6c2f5-8282-417a-83d1-1fa79425ff73.open-xchange@email.1und1.de>
Message-ID: <D4D8C3EE-7BDC-44F4-A54F-A6861FE0A174@martin.sperl.org>


> On 13.02.2016, at 21:45, Stefan Wahren <stefan.wahren at i2se.com> wrote:
> 
> 
> According to the datasheet busy bit shouldn't be set while changing the clock.
> So this isn't good. I hope this could be fixed, too.
> 

I had hoped that the patch by Eric:
"clk: bcm2835: Fix setting of PLL divider clock rates"
would fix the issue, but that was unfortunately not the case.

Some more investigation using the debugfs patch I had posted,
which exposes the registers showed that:
plld_per_a2w had a value of 4 before starting getty
and a value of 0 after starting getty.

That made me investigate why this value was changed and I found
the culprit in the form of:
@@ -1167,7 +1171,9 @@ static void bcm2835_pll_divider_off(struct clk_hw *hw)
        cprman_write(cprman, data->cm_reg,
                     (cprman_read(cprman, data->cm_reg) &
                      ~data->load_mask) | data->hold_mask);
-       cprman_write(cprman, data->a2w_reg, A2W_PLL_CHANNEL_DISABLE);
+       cprman_write(cprman, data->a2w_reg,
+                    cprman_read(cprman, data->a2w_reg) |
+                       A2W_PLL_CHANNEL_DISABLE);
 }

after that (with plld itself marked as ?prepared? during probe) everything is
working fine.

bcm2835_pll_off shows a similar pattern, but patching that
the same way:
@@ -955,8 +955,12 @@ static void bcm2835_pll_off(struct clk_hw *hw)
        struct bcm2835_cprman *cprman = pll->cprman;
        const struct bcm2835_pll_data *data = pll->data;

-       cprman_write(cprman, data->cm_ctrl_reg, CM_PLL_ANARST);
-       cprman_write(cprman, data->a2w_ctrl_reg, A2W_PLL_CTRL_PWRDN);
+       cprman_write(cprman, data->cm_ctrl_reg,
+                    cprman_read(cprman, data->cm_ctrl_reg) |
+                    CM_PLL_ANARST);
+       cprman_write(cprman, data->a2w_ctrl_reg,
+                    cprman_read(cprman, data->a2w_ctrl_reg) |
+                    A2W_PLL_CTRL_PWRDN);
 }

does not resolve the issue - the system crashes - but without he pll
lock message?

With some debugging messages in place (the register names are
added as a comments indicated via >):

the complete list of writes to the clocks during boot:
[    2.021473] bcm2835_pll_on - pllc - start
[    2.025635] cprman_write - 0x0108 = 0x00000228
> CM_PLLC
[    2.030313] bcm2835_pll_on - pllc - before_wait_pll_lock
[    2.035773] bcm2835_pll_on - pllc - end
[    2.039785] cprman_write - 0x1620 = 0x00000002
> A2W_PLLC_CORE0
[    2.044373] cprman_write - 0x0108 = 0x00000228
> CM_PLLC
[    2.049430] console [ttyS0] disabled
[    2.053237] 20215040.serial: ttyS0 at MMIO 0x0 (irq = 53, base_baud = 31224999) is a 16550
[    2.061878] console [ttyS0] enabled
[    2.069085] bootconsole [earlycon0] disabled
[    2.078668] cprman_write - 0x1520 = 0x00000002
> A2W_PLLC_PER
[    2.083201] cprman_write - 0x0108 = 0x00000228
> CM_PLLC
[    2.087801] cprman_write - 0x01c0 = 0x000002d5
> CM_EMMCCTL
[    2.136432] mmc0: SDHCI controller on 20300000.sdhci [20300000.sdhci] using PIO

dumping the registers for PLLD 
root at raspcm:~# cat /sys/kernel/debug/clk/plld/regdump
cm_ctrl = 0x0000020a
> CM_PLLD
a2w_ctrl = 0x00021034
> A2W_PLLD_PER
frac = 0x00015554
> A2W_PLLD_FRAC
ana0 = 0x00000000
> A2W_PLLD_ANA0
ana1 = 0x00144000
> A2W_PLLD_ANA1
ana2 = 0x00000000
> A2W_PLLD_ANA2
ana3 = 0x00000100
> A2W_PLLD_ANA3

running getty:
root at raspcm:~# /sbin/getty -a root -L ttyAMA0 115200 vt100
[   71.110032] pl011_startup - start
[   71.113452] pl011_hwinit - prepare-enable
[   71.117656] bcm2835_pll_on - plld - start
[   71.121750] cprman_write - 0x010c = 0x0000020a
> CM_PLLD
[   71.126274] bcm2835_pll_on - plld - before_wait_pll_lock
[   71.131728] bcm2835_pll_on - plld - end
[   71.135648] cprman_write - 0x1540 = 0x00000004
> A2W_PLLD_PER
[   71.140228] cprman_write - 0x010c = 0x0000020a
> CM_PLLD
[   71.144760] cprman_write - 0x00f0 = 0x000002d6
> CM_UARTCTL
[   71.149340] pl011_hwinit - prepare-enable - ret = 0
[   71.156743] pl011_startup - exit
[   71.163324] pl011_shutdown - start
[   71.168032] pl011_shutdown - disable_unprepare
[   71.172603] cprman_write - 0x00f0 = 0x00000286
> CM_UARTCTL
[   71.177269] cprman_write - 0x010c = 0x0000028a
> CM_PLLD
[   71.181809] cprman_write - 0x1540 = 0x00000104
> A2W_PLLD_PER
[   71.186334] bcm2835_pll_off - plld - start
[   71.190547] cprman_write - 0x010c = 0x0000038a
> CM_PLLD
[   71.195088] cprman_write - 0x1140 = 0x00031034
> A2W_PLLD_CTRL
[   71.199643] bcm2835_pll_off - plld - end
[   71.203643] pl011_shutdown - exit
[   71.209122] pl011_startup - start
[   71.212522] pl011_hwinit - prepare-enable
[   71.216695] bcm2835_pll_on - plld - start
[   71.220801] cprman_write - 0x010c = 0x0000028a
>  CM_PLLD
[   71.225326] bcm2835_pll_on - plld - before_wait_pll_lock
[   71.230775] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.235840] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.240926] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.245983] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.251067] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.256123] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.261206] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.266272] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.271364] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.276419] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.281523] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.286691] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.291753] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.296838] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.301937] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.307030] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.312087] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.317180] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.322235] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.327319] bcm2835_pll_on - plld - in_pll_lock_loop
[   71.332387] bcm2835-clk 20101000.cprman: plld: couldn't lock PLL
[   71.338532] bcm2835_pll_on - plld - timeout
[   71.342801] pl011_hwinit - prepare-enable - ret = -110
[   71.348080] pl011_startup - error = -110 - disable_unprepare
[   71.353862] ------------[ cut here ]------------
[   71.358593] WARNING: CPU: 0 PID: 2339 at drivers/clk/clk.c:680 clk_core_disab
le+0x34/0xf0()
[   71.367840] ---[ end trace f080e315d858793e ]---
[   71.372614] ------------[ cut here ]------------
[   71.377408] WARNING: CPU: 0 PID: 2339 at drivers/clk/clk.c:575 clk_core_unpre
pare+0x34/0x110()
[   71.387073] ---[ end trace f080e315d858793f ]?

no more activity - system crashed - HDMI looses signal
So disabling PLL itself seems not to be recommended

I could create a patch with the following content as a bandaid:
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 5293338..4dfb8e3 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -37,6 +37,7 @@
  * generator).
  */

+#include <linux/clk.h>
 #include <linux/clk-provider.h>
 #include <linux/clkdev.h>
 #include <linux/clk/bcm2835.h>
@@ -1750,6 +1767,9 @@ static int bcm2835_clk_probe(struct platform_device *pdev)
			clks[i] = desc->clk_register(cprman, desc->data);
 	}
 
+	/* prepare PLLD, so that it never gets unprepared */
+	clk_prepare(clks[BCM2835_PLLD]);
+
 	return of_clk_add_provider(dev->of_node, of_clk_src_onecell_get,
 				   &cprman->onecell);
 }

Note that this this needed on top of the patch to bcm2835_pll_divider_off,
which is applied in the kernel used during reporting...

Martin

From linux at arm.linux.org.uk  Tue Feb 16 08:31:43 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 16 Feb 2016 16:31:43 +0000
Subject: [PATCH v5 RESEND 4/5] ARM: amba: Move reading of periphid to
 amba_match()
In-Reply-To: <20160215175250.GJ10826@n2100.arm.linux.org.uk>
References: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
 <1455101250-11327-5-git-send-email-m.szyprowski@samsung.com>
 <20160215175250.GJ10826@n2100.arm.linux.org.uk>
Message-ID: <20160216163143.GD19428@n2100.arm.linux.org.uk>

On Mon, Feb 15, 2016 at 05:52:50PM +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 10, 2016 at 11:47:29AM +0100, Marek Szyprowski wrote:
> > From: Tomeu Vizoso <tomeu.vizoso at collabora.com>
> > 
> > Reading the periphid when the Primecell device is registered means that
> > the apb pclk must be available by then or the device won't be registered
> > at all.
> > 
> > By reading the periphid in amba_match() we can return -EPROBE_DEFER if
> > the apb pclk isn't there yet and the device will be retried later.
> 
> I've just realised, we can't do this.  We need to read the peripheral
> ID at registration time, because that's published to userspace via
> (a) a sysfs attribute, and (b) as part of the uevent, which will be
> used by udev to locate the driver module.
> 
> So, this will have the side effect of breaking systems which have
> AMBA primecell devices configured as modules.
> 
> Sorry, I can't apply this.  We can't regress existing platforms for
> the sake of introducing new platforms to this code.

I just re-applied the patch set to the amba branch, and then dropped
the last two patches because of this issue.  Please ignore the "applied"
notification for the last two patches from the patch system.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From arnd at arndb.de  Tue Feb 16 08:32:06 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 17:32:06 +0100
Subject: [PATCH v2] net: igmp: use IS_ENABLED(CONFIG_IP_MULTICAST) instead of
 ifdef
Message-ID: <1455640333-3769837-1-git-send-email-arnd@arndb.de>

A recent change to use correct network namespace in net/ipv4/igmp.c
caused a couple of harmless build warnings when CONFIG_MULTICAST is
disabled:

net/ipv4/igmp.c: In function 'igmp_group_added':
net/ipv4/igmp.c:1227:14: error: unused variable 'net' [-Werror=unused-variable]
net/ipv4/igmp.c: In function 'ip_mc_inc_group':
net/ipv4/igmp.c:1319:14: error: unused variable 'net' [-Werror=unused-variable]
net/ipv4/igmp.c: In function 'ip_mc_init_dev':
net/ipv4/igmp.c:1646:14: error: unused variable 'net' [-Werror=unused-variable]
net/ipv4/igmp.c: In function 'ip_mc_up':
net/ipv4/igmp.c:1665:14: error: unused variable 'net' [-Werror=unused-variable]

This reworks the entire file to change each instance if '#ifdef
CONFIG_IP_MULTICAST' to 'if (IS_ENABLED(CONFIG_IP_MULTICAST)', which
should avoid these problems forever, and makes the whole file more
readable.

Build-tested only.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Reviewed-by: Nikolay Borisov <kernel at kyup.com>
Fixes: 87a8a2ae65b7 ("igmp: Namespaceify igmp_llm_reports sysctl knob")
---
 net/ipv4/igmp.c | 142 ++++++++++++++++++++++++++------------------------------
 1 file changed, 66 insertions(+), 76 deletions(-)

diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 7c95335bf85e..2b6dd53adaa4 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -107,7 +107,6 @@
 #include <linux/seq_file.h>
 #endif
 
-#ifdef CONFIG_IP_MULTICAST
 /* Parameter names and values are taken from igmp-v2-06 draft */
 
 #define IGMP_V1_ROUTER_PRESENT_TIMEOUT		(400*HZ)
@@ -166,7 +165,6 @@ static void igmpv3_del_delrec(struct in_device *in_dev, __be32 multiaddr);
 static void igmpv3_clear_delrec(struct in_device *in_dev);
 static int sf_setstate(struct ip_mc_list *pmc);
 static void sf_markstate(struct ip_mc_list *pmc);
-#endif
 static void ip_mc_clear_src(struct ip_mc_list *pmc);
 static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
 			 int sfcount, __be32 *psfsrc, int delta);
@@ -189,8 +187,6 @@ static void ip_ma_put(struct ip_mc_list *im)
 	     pmc != NULL;					\
 	     pmc = rtnl_dereference(pmc->next_rcu))
 
-#ifdef CONFIG_IP_MULTICAST
-
 /*
  *	Timer management
  */
@@ -763,7 +759,9 @@ static void igmp_ifc_timer_expire(unsigned long data)
 static void igmp_ifc_event(struct in_device *in_dev)
 {
 	struct net *net = dev_net(in_dev->dev);
-	if (IGMP_V1_SEEN(in_dev) || IGMP_V2_SEEN(in_dev))
+
+	if (!IS_ENABLED(CONFIG_IP_MULTICAST) ||
+	    IGMP_V1_SEEN(in_dev) || IGMP_V2_SEEN(in_dev))
 		return;
 	in_dev->mr_ifc_count = in_dev->mr_qrv ?: net->ipv4.sysctl_igmp_qrv;
 	igmp_ifc_start_timer(in_dev, 1);
@@ -1044,9 +1042,6 @@ drop:
 	return 0;
 }
 
-#endif
-
-
 /*
  *	Add a filter to a device
  */
@@ -1080,7 +1075,6 @@ static void ip_mc_filter_del(struct in_device *in_dev, __be32 addr)
 		dev_mc_del(dev, buf);
 }
 
-#ifdef CONFIG_IP_MULTICAST
 /*
  * deleted ip_mc_list manipulation
  */
@@ -1181,22 +1175,20 @@ static void igmpv3_clear_delrec(struct in_device *in_dev)
 	}
 	rcu_read_unlock();
 }
-#endif
 
 static void igmp_group_dropped(struct ip_mc_list *im)
 {
 	struct in_device *in_dev = im->interface;
-#ifdef CONFIG_IP_MULTICAST
 	struct net *net = dev_net(in_dev->dev);
 	int reporter;
-#endif
 
 	if (im->loaded) {
 		im->loaded = 0;
 		ip_mc_filter_del(in_dev, im->multiaddr);
 	}
 
-#ifdef CONFIG_IP_MULTICAST
+	if (!IS_ENABLED(CONFIG_IP_MULTICAST))
+		return;
 	if (im->multiaddr == IGMP_ALL_HOSTS)
 		return;
 	if (ipv4_is_local_multicast(im->multiaddr) && !net->ipv4.sysctl_igmp_llm_reports)
@@ -1218,7 +1210,6 @@ static void igmp_group_dropped(struct ip_mc_list *im)
 
 		igmp_ifc_event(in_dev);
 	}
-#endif
 }
 
 static void igmp_group_added(struct ip_mc_list *im)
@@ -1231,7 +1222,9 @@ static void igmp_group_added(struct ip_mc_list *im)
 		ip_mc_filter_add(in_dev, im->multiaddr);
 	}
 
-#ifdef CONFIG_IP_MULTICAST
+	if (!IS_ENABLED(CONFIG_IP_MULTICAST))
+		return;
+
 	if (im->multiaddr == IGMP_ALL_HOSTS)
 		return;
 	if (ipv4_is_local_multicast(im->multiaddr) && !net->ipv4.sysctl_igmp_llm_reports)
@@ -1249,7 +1242,6 @@ static void igmp_group_added(struct ip_mc_list *im)
 
 	im->crcount = in_dev->mr_qrv ?: net->ipv4.sysctl_igmp_qrv;
 	igmp_ifc_event(in_dev);
-#endif
 }
 
 
@@ -1341,10 +1333,10 @@ void ip_mc_inc_group(struct in_device *in_dev, __be32 addr)
 	im->sfcount[MCAST_EXCLUDE] = 1;
 	atomic_set(&im->refcnt, 1);
 	spin_lock_init(&im->lock);
-#ifdef CONFIG_IP_MULTICAST
-	setup_timer(&im->timer, igmp_timer_expire, (unsigned long)im);
-	im->unsolicit_count = net->ipv4.sysctl_igmp_qrv;
-#endif
+	if (IS_ENABLED(CONFIG_IP_MULTICAST)) {
+		setup_timer(&im->timer, igmp_timer_expire, (unsigned long)im);
+		im->unsolicit_count = net->ipv4.sysctl_igmp_qrv;
+	}
 
 	im->next_rcu = in_dev->mc_list;
 	in_dev->mc_count++;
@@ -1352,9 +1344,9 @@ void ip_mc_inc_group(struct in_device *in_dev, __be32 addr)
 
 	ip_mc_hash_add(in_dev, im);
 
-#ifdef CONFIG_IP_MULTICAST
-	igmpv3_del_delrec(in_dev, im->multiaddr);
-#endif
+	if (IS_ENABLED(CONFIG_IP_MULTICAST))
+		igmpv3_del_delrec(in_dev, im->multiaddr);
+
 	igmp_group_added(im);
 	if (!in_dev->dead)
 		ip_rt_multicast_event(in_dev);
@@ -1533,11 +1525,13 @@ EXPORT_SYMBOL(ip_mc_check_igmp);
  */
 static void ip_mc_rejoin_groups(struct in_device *in_dev)
 {
-#ifdef CONFIG_IP_MULTICAST
 	struct ip_mc_list *im;
 	int type;
 	struct net *net = dev_net(in_dev->dev);
 
+	if (!IS_ENABLED(CONFIG_IP_MULTICAST))
+		return;
+
 	ASSERT_RTNL();
 
 	for_each_pmc_rtnl(in_dev, im) {
@@ -1558,7 +1552,6 @@ static void ip_mc_rejoin_groups(struct in_device *in_dev)
 			type = IGMPV3_HOST_MEMBERSHIP_REPORT;
 		igmp_send_report(in_dev, im, type);
 	}
-#endif
 }
 
 /*
@@ -1628,15 +1621,15 @@ void ip_mc_down(struct in_device *in_dev)
 	for_each_pmc_rtnl(in_dev, pmc)
 		igmp_group_dropped(pmc);
 
-#ifdef CONFIG_IP_MULTICAST
-	in_dev->mr_ifc_count = 0;
-	if (del_timer(&in_dev->mr_ifc_timer))
-		__in_dev_put(in_dev);
-	in_dev->mr_gq_running = 0;
-	if (del_timer(&in_dev->mr_gq_timer))
-		__in_dev_put(in_dev);
-	igmpv3_clear_delrec(in_dev);
-#endif
+	if (IS_ENABLED(CONFIG_IP_MULTICAST)) {
+		in_dev->mr_ifc_count = 0;
+		if (del_timer(&in_dev->mr_ifc_timer))
+			__in_dev_put(in_dev);
+		in_dev->mr_gq_running = 0;
+		if (del_timer(&in_dev->mr_gq_timer))
+			__in_dev_put(in_dev);
+		igmpv3_clear_delrec(in_dev);
+	}
 
 	ip_mc_dec_group(in_dev, IGMP_ALL_HOSTS);
 }
@@ -1646,13 +1639,13 @@ void ip_mc_init_dev(struct in_device *in_dev)
 	struct net *net = dev_net(in_dev->dev);
 	ASSERT_RTNL();
 
-#ifdef CONFIG_IP_MULTICAST
-	setup_timer(&in_dev->mr_gq_timer, igmp_gq_timer_expire,
-			(unsigned long)in_dev);
-	setup_timer(&in_dev->mr_ifc_timer, igmp_ifc_timer_expire,
-			(unsigned long)in_dev);
-	in_dev->mr_qrv = net->ipv4.sysctl_igmp_qrv;
-#endif
+	if (IS_ENABLED(CONFIG_IP_MULTICAST)) {
+		setup_timer(&in_dev->mr_gq_timer, igmp_gq_timer_expire,
+				(unsigned long)in_dev);
+		setup_timer(&in_dev->mr_ifc_timer, igmp_ifc_timer_expire,
+				(unsigned long)in_dev);
+		in_dev->mr_qrv = net->ipv4.sysctl_igmp_qrv;
+	}
 
 	spin_lock_init(&in_dev->mc_tomb_lock);
 }
@@ -1666,9 +1659,9 @@ void ip_mc_up(struct in_device *in_dev)
 
 	ASSERT_RTNL();
 
-#ifdef CONFIG_IP_MULTICAST
-	in_dev->mr_qrv = net->ipv4.sysctl_igmp_qrv;
-#endif
+	if (IS_ENABLED(CONFIG_IP_MULTICAST))
+		in_dev->mr_qrv = net->ipv4.sysctl_igmp_qrv;
+
 	ip_mc_inc_group(in_dev, IGMP_ALL_HOSTS);
 
 	for_each_pmc_rtnl(in_dev, pmc)
@@ -1755,34 +1748,27 @@ static int ip_mc_del1_src(struct ip_mc_list *pmc, int sfmode,
 		ip_rt_multicast_event(pmc->interface);
 	}
 	if (!psf->sf_count[MCAST_INCLUDE] && !psf->sf_count[MCAST_EXCLUDE]) {
-#ifdef CONFIG_IP_MULTICAST
 		struct in_device *in_dev = pmc->interface;
 		struct net *net = dev_net(in_dev->dev);
-#endif
 
 		/* no more filters for this source */
 		if (psf_prev)
 			psf_prev->sf_next = psf->sf_next;
 		else
 			pmc->sources = psf->sf_next;
-#ifdef CONFIG_IP_MULTICAST
-		if (psf->sf_oldin &&
+		if (IS_ENABLED(CONFIG_IP_MULTICAST) && psf->sf_oldin &&
 		    !IGMP_V1_SEEN(in_dev) && !IGMP_V2_SEEN(in_dev)) {
 			psf->sf_crcount = in_dev->mr_qrv ?: net->ipv4.sysctl_igmp_qrv;
 			psf->sf_next = pmc->tomb;
 			pmc->tomb = psf;
 			rv = 1;
-		} else
-#endif
+		} else {
 			kfree(psf);
+		}
 	}
 	return rv;
 }
 
-#ifndef CONFIG_IP_MULTICAST
-#define igmp_ifc_event(x)	do { } while (0)
-#endif
-
 static int ip_mc_del_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
 			 int sfcount, __be32 *psfsrc, int delta)
 {
@@ -1804,9 +1790,9 @@ static int ip_mc_del_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
 	}
 	spin_lock_bh(&pmc->lock);
 	rcu_read_unlock();
-#ifdef CONFIG_IP_MULTICAST
+
 	sf_markstate(pmc);
-#endif
+
 	if (!delta) {
 		err = -EINVAL;
 		if (!pmc->sfcount[sfmode])
@@ -1824,14 +1810,15 @@ static int ip_mc_del_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
 	if (pmc->sfmode == MCAST_EXCLUDE &&
 	    pmc->sfcount[MCAST_EXCLUDE] == 0 &&
 	    pmc->sfcount[MCAST_INCLUDE]) {
-#ifdef CONFIG_IP_MULTICAST
 		struct ip_sf_list *psf;
 		struct net *net = dev_net(in_dev->dev);
-#endif
 
 		/* filter mode change */
 		pmc->sfmode = MCAST_INCLUDE;
-#ifdef CONFIG_IP_MULTICAST
+
+		if (!IS_ENABLED(CONFIG_IP_MULTICAST))
+			goto out_unlock;
+
 		pmc->crcount = in_dev->mr_qrv ?: net->ipv4.sysctl_igmp_qrv;
 		in_dev->mr_ifc_count = pmc->crcount;
 		for (psf = pmc->sources; psf; psf = psf->sf_next)
@@ -1839,7 +1826,6 @@ static int ip_mc_del_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
 		igmp_ifc_event(pmc->interface);
 	} else if (sf_setstate(pmc) || changerec) {
 		igmp_ifc_event(pmc->interface);
-#endif
 	}
 out_unlock:
 	spin_unlock_bh(&pmc->lock);
@@ -1877,11 +1863,15 @@ static int ip_mc_add1_src(struct ip_mc_list *pmc, int sfmode,
 	return 0;
 }
 
-#ifdef CONFIG_IP_MULTICAST
 static void sf_markstate(struct ip_mc_list *pmc)
 {
 	struct ip_sf_list *psf;
-	int mca_xcount = pmc->sfcount[MCAST_EXCLUDE];
+	int mca_xcount;
+
+	if (!IS_ENABLED(CONFIG_IP_MULTICAST))
+		return;
+
+	mca_xcount = pmc->sfcount[MCAST_EXCLUDE];
 
 	for (psf = pmc->sources; psf; psf = psf->sf_next)
 		if (pmc->sfcount[MCAST_EXCLUDE]) {
@@ -1895,10 +1885,15 @@ static void sf_markstate(struct ip_mc_list *pmc)
 static int sf_setstate(struct ip_mc_list *pmc)
 {
 	struct ip_sf_list *psf, *dpsf;
-	int mca_xcount = pmc->sfcount[MCAST_EXCLUDE];
-	int qrv = pmc->interface->mr_qrv;
+	int mca_xcount;
+	int qrv;
 	int new_in, rv;
 
+	if (!IS_ENABLED(CONFIG_IP_MULTICAST))
+		return 0;
+
+	mca_xcount = pmc->sfcount[MCAST_EXCLUDE];
+	qrv = pmc->interface->mr_qrv;
 	rv = 0;
 	for (psf = pmc->sources; psf; psf = psf->sf_next) {
 		if (pmc->sfcount[MCAST_EXCLUDE]) {
@@ -1950,7 +1945,6 @@ static int sf_setstate(struct ip_mc_list *pmc)
 	}
 	return rv;
 }
-#endif
 
 /*
  * Add multicast source filter list to the interface list
@@ -1977,9 +1971,7 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
 	spin_lock_bh(&pmc->lock);
 	rcu_read_unlock();
 
-#ifdef CONFIG_IP_MULTICAST
 	sf_markstate(pmc);
-#endif
 	isexclude = pmc->sfmode == MCAST_EXCLUDE;
 	if (!delta)
 		pmc->sfcount[sfmode]++;
@@ -1997,18 +1989,19 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
 		for (j = 0; j < i; j++)
 			(void) ip_mc_del1_src(pmc, sfmode, &psfsrc[j]);
 	} else if (isexclude != (pmc->sfcount[MCAST_EXCLUDE] != 0)) {
-#ifdef CONFIG_IP_MULTICAST
 		struct ip_sf_list *psf;
 		struct net *net = dev_net(pmc->interface->dev);
 		in_dev = pmc->interface;
-#endif
 
 		/* filter mode change */
 		if (pmc->sfcount[MCAST_EXCLUDE])
 			pmc->sfmode = MCAST_EXCLUDE;
 		else if (pmc->sfcount[MCAST_INCLUDE])
 			pmc->sfmode = MCAST_INCLUDE;
-#ifdef CONFIG_IP_MULTICAST
+
+		if (!IS_ENABLED(CONFIG_IP_MULTICAST))
+			goto out_unlock;
+
 		/* else no filters; keep old mode for reports */
 
 		pmc->crcount = in_dev->mr_qrv ?: net->ipv4.sysctl_igmp_qrv;
@@ -2018,8 +2011,8 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
 		igmp_ifc_event(in_dev);
 	} else if (sf_setstate(pmc)) {
 		igmp_ifc_event(in_dev);
-#endif
 	}
+out_unlock:
 	spin_unlock_bh(&pmc->lock);
 	return err;
 }
@@ -2711,13 +2704,10 @@ static int igmp_mc_seq_show(struct seq_file *seq, void *v)
 		char   *querier;
 		long delta;
 
-#ifdef CONFIG_IP_MULTICAST
-		querier = IGMP_V1_SEEN(state->in_dev) ? "V1" :
+		querier = !IS_ENABLED(CONFIG_IP_MULTICAST) ? "NONE" :
+			  IGMP_V1_SEEN(state->in_dev) ? "V1" :
 			  IGMP_V2_SEEN(state->in_dev) ? "V2" :
 			  "V3";
-#else
-		querier = "NONE";
-#endif
 
 		if (rcu_access_pointer(state->in_dev->mc_list) == im) {
 			seq_printf(seq, "%d\t%-10s: %5d %7s\n",
-- 
2.7.0



From fu.wei at linaro.org  Tue Feb 16 08:33:24 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Wed, 17 Feb 2016 00:33:24 +0800
Subject: [PATCH v12 4/4] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <CADyBb7vDuZjjy92WkV_jML2Ji13LvtuqkKszAetzvoM47CaY7Q@mail.gmail.com>
References: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>
 <1455611785-2407-5-git-send-email-fu.wei@linaro.org>
 <56C34076.1020206@roeck-us.net>
 <CADyBb7vDuZjjy92WkV_jML2Ji13LvtuqkKszAetzvoM47CaY7Q@mail.gmail.com>
Message-ID: <CADyBb7s0mf9MLxXeR54wBCPnTBSC7hiNw08C-5vc9EhkORGZww@mail.gmail.com>

On 16 February 2016 at 23:54, Fu Wei <fu.wei at linaro.org> wrote:
> On 16 February 2016 at 23:29, Guenter Roeck <linux at roeck-us.net> wrote:
>> On 02/16/2016 12:36 AM, fu.wei at linaro.org wrote:
>>>
>>> From: Fu Wei <fu.wei at linaro.org>
>>>
>>> According to Server Base System Architecture (SBSA) specification,
>>> the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0)
>>> is for alerting the system by interrupt, the second one (WS1) is a real
>>> hardware reset.
>>> More details about the hardware specification of this device:
>>> ARM DEN0029B - Server Base System Architecture (SBSA)
>>>
>>> This driver can operate ARM SBSA Generic Watchdog as a single stage
>>> watchdog
>>> or a two stages watchdog, it's set up by the module parameter "action".
>>> In the single stage mode, when the timeout is reached, your system
>>> will be reset by WS1. The first signal (WS0) is ignored.
>>> In the two stages mode, when the timeout is reached, the first signal
>>> (WS0)
>>> will trigger panic. If the system is getting into trouble and cannot be
>>> reset
>>> by panic or restart properly by the kdump kernel(if supported), then the
>>> second stage (as long as the first stage) will be reached, system will be
>>> reset by WS1. This function can help administrator to backup the system
>>> context info by panic console output or kdump.
>>>
>>> This driver bases on linux kernel watchdog framework, so it can get
>>> timeout from module parameter and FDT at the driver init stage.
>>>
>>> Signed-off-by: Fu Wei <fu.wei at linaro.org>
>>> Reviewed-by: Graeme Gregory <graeme.gregory at linaro.org>
>>> Tested-by: Pratyush Anand <panand at redhat.com>
>>> Acked-by: Timur Tabi <timur at codeaurora.org>
>>> Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
>>> ---
>>>   drivers/watchdog/Kconfig     |  20 +++
>>>   drivers/watchdog/Makefile    |   1 +
>>>   drivers/watchdog/sbsa_gwdt.c | 403
>>> +++++++++++++++++++++++++++++++++++++++++++
>>>   3 files changed, 424 insertions(+)
>>>
>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>>> index 0f6d851..ed9a5cb 100644
>>> --- a/drivers/watchdog/Kconfig
>>> +++ b/drivers/watchdog/Kconfig
>>
>>
>> [ ... ]
>>
>>> +
>>> +static int sbsa_gwdt_probe(struct platform_device *pdev)
>>> +{
>>
>>
>> [ ... ]
>>
>>> +               if (!action)
>>> +                       dev_warn(dev, "falling back to signle stage
>>> mode.\n");
>>
>>
>> Still:
>>
>> s/signle/single/
>
> sorry, my bad, will fix it
>
>>
>> [ ... ]
>>
>>> +
>>> +MODULE_DESCRIPTION("SBSA Generic Watchdog Driver");
>>> +MODULE_AUTHOR("Fu Wei <fu.wei at linaro.org>");
>>> +MODULE_AUTHOR("Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>");
>>> +MODULE_AUTHOR("Al Stone <al.stone at linaro.org>");
>>> +MODULE_AUTHOR("Timur Tabi <timur at codeaurora.org>");
>>> +MODULE_LICENSE("GPL v2");
>>>
>> Do you need a MODULE_ALIAS ?
>
> For now, I thinks we don't need it, Hope I didn't miss something :-)
> Because this module can be mounted automatically with dtb or ACPI(if
> apply my GTDT patch).
> Do you have any suggestion or concern? :-)

re-think  about that , will add
MODULE_ALIAS("platform:sbsa-gwdt");

Do you agree ?  :-)

>
>>
>> Guenter
>>
>
>
>
> --
> Best regards,
>
> Fu Wei
> Software Engineer
> Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
> Ph: +86 21 61221326(direct)
> Ph: +86 186 2020 4684 (mobile)
> Room 1512, Regus One Corporate Avenue,Level 15,
> One Corporate Avenue,222 Hubin Road,Huangpu District,
> Shanghai,China 200021



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From peter at hurleysoftware.com  Tue Feb 16 08:33:41 2016
From: peter at hurleysoftware.com (Peter Hurley)
Date: Tue, 16 Feb 2016 08:33:41 -0800
Subject: [PATCH 2/3] serial: xuartps: Enable OF earlycon support
In-Reply-To: <23ab10a19b21df2ef17a5bb6ce2a70d2d3fd3551.1455552315.git.michal.simek@xilinx.com>
References: <67c9013fc61f53515934b54847a05df8b8e1504a.1455552315.git.michal.simek@xilinx.com>
 <23ab10a19b21df2ef17a5bb6ce2a70d2d3fd3551.1455552315.git.michal.simek@xilinx.com>
Message-ID: <56C34F65.1040506@hurleysoftware.com>

Hi Michal,

On 02/15/2016 08:05 AM, Michal Simek wrote:
> Support early console setup via DT for all listed compatible strings.
> 
> Signed-off-by: Michal Simek <michal.simek at xilinx.com>
> ---
> 
>  drivers/tty/serial/xilinx_uartps.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
> index 009e0dbc12d2..6f5657766815 100644
> --- a/drivers/tty/serial/xilinx_uartps.c
> +++ b/drivers/tty/serial/xilinx_uartps.c
> @@ -1094,6 +1094,9 @@ static int __init cdns_early_console_setup(struct earlycon_device *device,
>  	return 0;
>  }
>  EARLYCON_DECLARE(cdns, cdns_early_console_setup);
> +OF_EARLYCON_DECLARE(cdns_a, "xlnx,xuartps", cdns_early_console_setup);
> +OF_EARLYCON_DECLARE(cdns_b, "cdns,uart-r1p8", cdns_early_console_setup);
> +OF_EARLYCON_DECLARE(cdns_c, "cdns,uart-r1p12", cdns_early_console_setup);

Earlycon now shares a common framework in linux-next.

The EARLYCON_DECLARE() can be deleted and the OF_EARLYCON_DECLARE()
can all share the same earlycon name. iow,

-EARLYCON_DECLARE(cdns, cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "xlnx,xuartps", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p8", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p12", cdns_early_console_setup);

Regards,
Peter Hurley


>  /**
>   * cdns_uart_console_write - perform write operation
> 



From arnd at arndb.de  Tue Feb 16 08:33:18 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 17:33:18 +0100
Subject: [PATCH] net: igmp: use IS_ENABLED(CONFIG_IP_MULTICAST) instead of
 ifdef
In-Reply-To: <56C34A0C.9040207@kyup.com>
References: <1455638393-3269483-1-git-send-email-arnd@arndb.de>
 <56C34A0C.9040207@kyup.com>
Message-ID: <13046365.7R7s0XiHQi@wuerfel>

On Tuesday 16 February 2016 18:10:52 Nikolay Borisov wrote:
> On 02/16/2016 05:59 PM, Arnd Bergmann wrote:
> > @@ -1821,17 +1807,15 @@ static int ip_mc_del_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
> >  		if (!err && rv < 0)
> >  			err = rv;
> >  	}
> > -	if (pmc->sfmode == MCAST_EXCLUDE &&
> > +	if (IS_ENABLED(CONFIG_IP_MULTICAST) &&
> > +	    pmc->sfmode == MCAST_EXCLUDE &&
> >  	    pmc->sfcount[MCAST_EXCLUDE] == 0 &&
> >  	    pmc->sfcount[MCAST_INCLUDE]) {
> > -#ifdef CONFIG_IP_MULTICAST
> >  		struct ip_sf_list *psf;
> >  		struct net *net = dev_net(in_dev->dev);
> > -#endif
> >  
> >  		/* filter mode change */
> >  		pmc->sfmode = MCAST_INCLUDE;
> 
> The above line was always executed, whereas now it wouldn't execute
> unless IS_ENABLED passes.

This was not intentional, I've sent a v2 patch to fix it up now, and
tried to simplify it a little further, making the logic the
same for  ip_mc_del_src and ip_mc_add_src.

> >  /*
> >   * Add multicast source filter list to the interface list
> > @@ -1977,9 +1961,7 @@ static int ip_mc_add_src(struct in_device *in_dev, __be32 *pmca, int sfmode,
> >  	spin_lock_bh(&pmc->lock);
> >  	rcu_read_unlock();
> >  
> > -#ifdef CONFIG_IP_MULTICAST
> >  	sf_markstate(pmc);
> > -#endif
> 
> This would be executed unconditionally, which is contrary to the
> original intention. Dunno if it makes a difference though.

This was intentional, I have changed sf_markstate() to do nothing when
IP_MULTICAST is disabled. However, there was another caller where
I should have done the same thing rather than adding an if().

> Reviewed-by: Nikolay Borisov <kernel at kyup.com>

Thanks!

	Arnd


From arnd at arndb.de  Tue Feb 16 08:34:30 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 17:34:30 +0100
Subject: [PATCH 2/2] ARM: mm: hide __start_rodata_section_aligned for
 non-debug builds
In-Reply-To: <CAKv+Gu8JcWg4BkxZFPqTotkfHFtP744XYdSx6XROJSM_8pmt2w@mail.gmail.com>
References: <1455638631-3326518-1-git-send-email-arnd@arndb.de>
 <1455638631-3326518-2-git-send-email-arnd@arndb.de>
 <CAKv+Gu8JcWg4BkxZFPqTotkfHFtP744XYdSx6XROJSM_8pmt2w@mail.gmail.com>
Message-ID: <4716656.D1MJCNd1N6@wuerfel>

On Tuesday 16 February 2016 17:12:52 Ard Biesheuvel wrote:
> > +#ifdef CONFIG_DEBUG_RODATA
> >  /*
> >   * Without CONFIG_DEBUG_ALIGN_RODATA, __start_rodata_section_aligned will
> >   * be the first section-aligned location after __start_rodata. Otherwise,
> >   * it will be equal to __start_rodata.
> >   */
> >  __start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
> > +#endif
> >
> 
> Does
> 
> PROVIDE(__start_rodata_section_aligned = xxx);
> 
> do the trick as well? If it does, it's a bit cleaner.
> 

I would assume not, as the problem is that SECTION_SHIFT is a macro that
is not defined when the MMU is disabled.

	Arnd


From ulf.hansson at linaro.org  Tue Feb 16 08:35:33 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Tue, 16 Feb 2016 17:35:33 +0100
Subject: [PATCH] mmc: mediatek: add SD write protect support
In-Reply-To: <1455474660-19864-1-git-send-email-chaotian.jing@mediatek.com>
References: <1455474660-19864-1-git-send-email-chaotian.jing@mediatek.com>
Message-ID: <CAPDyKFoVj9BDsAsuDV+h7=06FD7Kv=ivN=p=LZMMO+yF2QZ67Q@mail.gmail.com>

On 14 February 2016 at 19:31, Chaotian Jing <chaotian.jing at mediatek.com> wrote:
> use mmc core layer's API to support sd write protect
>
> Signed-off-by: Chaotian Jing <chaotian.jing at mediatek.com>

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/mtk-sd.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> index 82a97ac..f01972e 100644
> --- a/drivers/mmc/host/mtk-sd.c
> +++ b/drivers/mmc/host/mtk-sd.c
> @@ -35,6 +35,7 @@
>  #include <linux/mmc/mmc.h>
>  #include <linux/mmc/sd.h>
>  #include <linux/mmc/sdio.h>
> +#include <linux/mmc/slot-gpio.h>
>
>  #define MAX_BD_NUM          1024
>
> @@ -1452,6 +1453,7 @@ static struct mmc_host_ops mt_msdc_ops = {
>         .pre_req = msdc_pre_req,
>         .request = msdc_ops_request,
>         .set_ios = msdc_ops_set_ios,
> +       .get_ro = mmc_gpio_get_ro,
>         .start_signal_voltage_switch = msdc_ops_switch_volt,
>         .card_busy = msdc_card_busy,
>         .execute_tuning = msdc_execute_tuning,
> --
> 1.8.1.1.dirty
>


From ard.biesheuvel at linaro.org  Tue Feb 16 08:36:33 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 16 Feb 2016 17:36:33 +0100
Subject: [PATCH 2/2] ARM: mm: hide __start_rodata_section_aligned for
 non-debug builds
In-Reply-To: <4716656.D1MJCNd1N6@wuerfel>
References: <1455638631-3326518-1-git-send-email-arnd@arndb.de>
 <1455638631-3326518-2-git-send-email-arnd@arndb.de>
 <CAKv+Gu8JcWg4BkxZFPqTotkfHFtP744XYdSx6XROJSM_8pmt2w@mail.gmail.com>
 <4716656.D1MJCNd1N6@wuerfel>
Message-ID: <CAKv+Gu-WAcw1q4s_UgOoM5DGerZ-aM_CToVG6C8-Bt6xzt-LMg@mail.gmail.com>

On 16 February 2016 at 17:34, Arnd Bergmann <arnd at arndb.de> wrote:
> On Tuesday 16 February 2016 17:12:52 Ard Biesheuvel wrote:
>> > +#ifdef CONFIG_DEBUG_RODATA
>> >  /*
>> >   * Without CONFIG_DEBUG_ALIGN_RODATA, __start_rodata_section_aligned will
>> >   * be the first section-aligned location after __start_rodata. Otherwise,
>> >   * it will be equal to __start_rodata.
>> >   */
>> >  __start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
>> > +#endif
>> >
>>
>> Does
>>
>> PROVIDE(__start_rodata_section_aligned = xxx);
>>
>> do the trick as well? If it does, it's a bit cleaner.
>>
>
> I would assume not, as the problem is that SECTION_SHIFT is a macro that
> is not defined when the MMU is disabled.
>

I just tested it myself, and it in fact does work.

PROVIDE() means the expression is evaluated lazily, and SECTION_SHIFT
is just an undefined identifier in the linker script scope if the
preprocessor does not define it.

Anyway, I don't have a strong preference, so ack either way.


From broonie at kernel.org  Tue Feb 16 08:38:40 2016
From: broonie at kernel.org (Mark Brown)
Date: Tue, 16 Feb 2016 16:38:40 +0000
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <s5h4md87hnu.wl-tiwai@suse.de>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
 <s5hbn7g7izt.wl-tiwai@suse.de> <2573932.AU4HSxN0NE@wuerfel>
 <s5h4md87hnu.wl-tiwai@suse.de>
Message-ID: <20160216163840.GA7544@sirena.org.uk>

On Tue, Feb 16, 2016 at 05:18:29PM +0100, Takashi Iwai wrote:
> Arnd Bergmann wrote:

> > Another option might would be to change snd_jack_new() to return
> > an error if that SND_JACK is disabled, and then require all users
> > to handle the error gracefully, i.e. not fail the probe() function
> > but just not use the jack.

> Yes, I thought of that, too.  If select is no good option, it's a good
> alternative, indeed.

It's going to be a bunch of work to implement though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/4932162c/attachment.sig>

From gregory.clement at free-electrons.com  Tue Feb 16 08:18:52 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 17:18:52 +0100
Subject: [PATCH net-next 08/10] bus: mvenus-mbus: Fix size test for
 mvebu_mbus_get_dram_win_info
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CCC5C65@AcuExch.aculab.com>
 (David Laight's message of "Thu, 14 Jan 2016 14:00:21 +0000")
References: <1452625834-22166-1-git-send-email-gregory.clement@free-electrons.com>
 <1452625834-22166-9-git-send-email-gregory.clement@free-electrons.com>
 <063D6719AE5E284EB5DD2968C1650D6D1CCC5C65@AcuExch.aculab.com>
Message-ID: <87mvr0tyqb.fsf@free-electrons.com>

Hi David,
 
 On jeu., janv. 14 2016, David Laight <David.Laight at ACULAB.COM> wrote:

> From: Gregory CLEMENT
>> Sent: 12 January 2016 19:11
>> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
>> ---
>>  drivers/bus/mvebu-mbus.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
>> index 3d1c0c3880ec..214bb964165b 100644
>> --- a/drivers/bus/mvebu-mbus.c
>> +++ b/drivers/bus/mvebu-mbus.c
>> @@ -964,7 +964,7 @@ int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr)
>>  	for (i = 0; i < dram->num_cs; i++) {
>>  		const struct mbus_dram_window *cs = dram->cs + i;
>> 
>> -		if (cs->base <= phyaddr && phyaddr <= (cs->base + cs->size)) {
>> +		if (cs->base <= phyaddr && phyaddr <= (cs->base + cs->size - 1)) {
>
> Wouldn't it be better to change the line to:
>> +		if (cs->base <= phyaddr && phyaddr < (cs->base +
>cs->size)) {

It doesn't work if there is 4GB of memory in this case we can have
cs->base + cs->size which wrap to 0 and the test fails. It was exactly
what happened on Armada XP GP board.

Gregory

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From mark.rutland at arm.com  Tue Feb 16 08:42:45 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 16 Feb 2016 16:42:45 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <56C34204.60605@virtuozzo.com>
References: <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com>
 <CAKv+Gu8WE=fTZF0Pou24FKDocgshWu8dJRbaC5SJ11E-6T=2Hw@mail.gmail.com>
 <56C34204.60605@virtuozzo.com>
Message-ID: <20160216164245.GC8022@leverpostej>

On Tue, Feb 16, 2016 at 06:36:36PM +0300, Andrey Ryabinin wrote:
> 
> On 02/16/2016 06:17 PM, Ard Biesheuvel wrote:
> > On 16 February 2016 at 13:59, Andrey Ryabinin <aryabinin at virtuozzo.com> wrote:
> >> +static void verify_shadow(void)
> >> +{
> >> +       struct memblock_region *reg;
> >> +       int i = 0;
> >> +
> >> +       for_each_memblock(memory, reg) {
> >> +               void *start = (void *)__phys_to_virt(reg->base);
> >> +               void *end = (void *)__phys_to_virt(reg->base + reg->size);
> >> +               int *shadow_start, *shadow_end;
> >> +
> >> +               if (start >= end)
> >> +                       break;
> >> +               shadow_start = (int *)((unsigned long)kasan_mem_to_shadow(start) & ~(PAGE_SIZE - 1));
> >> +               shadow_end =  (int *)kasan_mem_to_shadow(end);
> > 
> > shadow_start and shadow_end can refer to the same page as in the
> > previous iteration. For instance, I have these two regions
> > 
> >   0x00006e090000-0x00006e0adfff [Conventional Memory|   |  |  |  |  |
> > |   |WB|WT|WC|UC]
> >   0x00006e0ae000-0x00006e0affff [Loader Data        |   |  |  |  |  |
> > |   |WB|WT|WC|UC]
> > 
> > which are covered by different memblocks since the second one is
> > marked as MEMBLOCK_NOMAP, due to the fact that it contains the UEFI
> > memory map.
> > 
> > I get the following output
> > 
> > kasan: screwed shadow mapping 23575, 23573
> > 
> > which I think is simply a result from the fact the shadow_start refers
> > to the same page as in the previous iteration(s)
> > 
> 
> You are right. 
> So we should write 'shadow_start' instead of 'i'.

FWIW with the below patch I don't see any "screwed shadow mapping"
warnings on my board, and still later see a tonne of KASAN splats in the
scheduler.

Mark.

> ---
>  arch/arm64/mm/kasan_init.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 51 insertions(+)
> 
> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
> index cf038c7..ee035c2 100644
> --- a/arch/arm64/mm/kasan_init.c
> +++ b/arch/arm64/mm/kasan_init.c
> @@ -117,6 +117,55 @@ static void __init cpu_set_ttbr1(unsigned long ttbr1)
>  	: "r" (ttbr1));
>  }
>  
> +static void verify_shadow(void)
> +{
> +	struct memblock_region *reg;
> +
> +	for_each_memblock(memory, reg) {
> +		void *start = (void *)__phys_to_virt(reg->base);
> +		void *end = (void *)__phys_to_virt(reg->base + reg->size);
> +		unsigned long *shadow_start, *shadow_end;
> +
> +		if (start >= end)
> +			break;
> +		shadow_start = (unsigned long *)kasan_mem_to_shadow(start);
> +		shadow_end =  (unsigned long *)kasan_mem_to_shadow(end);
> +		for (; shadow_start < shadow_end; shadow_start += PAGE_SIZE/sizeof(unsigned long)) {
> +			*shadow_start = (unsigned long)shadow_start;
> +		}
> +	}
> +
> +	for_each_memblock(memory, reg) {
> +		void *start = (void *)__phys_to_virt(reg->base);
> +		void *end = (void *)__phys_to_virt(reg->base + reg->size);
> +		unsigned long *shadow_start, *shadow_end;
> +
> +		if (start >= end)
> +			break;
> +		shadow_start = (unsigned long *)kasan_mem_to_shadow(start);
> +		shadow_end =  (unsigned long *)kasan_mem_to_shadow(end);
> +		for (; shadow_start < shadow_end; shadow_start += PAGE_SIZE/sizeof(unsigned long)) {
> +			if (*shadow_start != (unsigned long)shadow_start) {
> +				pr_err("screwed shadow mapping %lx, %lx\n", *shadow_start, (unsigned long)shadow_start);
> +				goto clear;
> +			}
> +		}
> +	}
> +clear:
> +	for_each_memblock(memory, reg) {
> +		void *start = (void *)__phys_to_virt(reg->base);
> +		void *end = (void *)__phys_to_virt(reg->base + reg->size);
> +		unsigned long shadow_start, shadow_end;
> +
> +		if (start >= end)
> +			break;
> +		shadow_start =  (unsigned long)kasan_mem_to_shadow(start);
> +		shadow_end =  (unsigned long)kasan_mem_to_shadow(end);
> +		memset((void *)shadow_start, 0, shadow_end - shadow_start);
> +	}
> +
> +}
> +
>  void __init kasan_init(void)
>  {
>  	struct memblock_region *reg;
> @@ -159,6 +208,8 @@ void __init kasan_init(void)
>  	cpu_set_ttbr1(__pa(swapper_pg_dir));
>  	flush_tlb_all();
>  
> +	verify_shadow();
> +
>  	/* At this point kasan is fully initialized. Enable error messages */
>  	init_task.kasan_depth = 0;
>  	pr_info("KernelAddressSanitizer initialized\n");
> -- 
> 
> 


From tiwai at suse.de  Tue Feb 16 08:43:24 2016
From: tiwai at suse.de (Takashi Iwai)
Date: Tue, 16 Feb 2016 17:43:24 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <20160216163840.GA7544@sirena.org.uk>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
 <s5hbn7g7izt.wl-tiwai@suse.de> <2573932.AU4HSxN0NE@wuerfel>
 <s5h4md87hnu.wl-tiwai@suse.de>
 <20160216163840.GA7544@sirena.org.uk>
Message-ID: <s5hy4ak61xv.wl-tiwai@suse.de>

On Tue, 16 Feb 2016 17:38:40 +0100,
Mark Brown wrote:
> 
> On Tue, Feb 16, 2016 at 05:18:29PM +0100, Takashi Iwai wrote:
> > Arnd Bergmann wrote:
> 
> > > Another option might would be to change snd_jack_new() to return
> > > an error if that SND_JACK is disabled, and then require all users
> > > to handle the error gracefully, i.e. not fail the probe() function
> > > but just not use the jack.
> 
> > Yes, I thought of that, too.  If select is no good option, it's a good
> > alternative, indeed.
> 
> It's going to be a bunch of work to implement though.

Is it?  Which driver would be broken?  Many ASoC drivers just ignore
the return error completely.  Some treats as a fatal error, and the
behavior would change, yes.  But I don't think that such a driver
would work without CONFIG_SND_JACK properly in anyway.


Takashi


From arnd at arndb.de  Tue Feb 16 08:44:15 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 17:44:15 +0100
Subject: [PATCH v2] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
Message-ID: <1455641066-4014858-1-git-send-email-arnd@arndb.de>

When CONFIG_SND_JACK is disabled, the hdmi driver tries to create
a new output jack structure and dereferences it even though
the pointer is never assigned:

sound/pci/hda/patch_hdmi.c: In function 'generic_hdmi_build_jack':
sound/pci/hda/patch_hdmi.c:2534:30: error: 'jack' may be used uninitialized in this function [-Werror=maybe-uninitialized]
sound/pci/hda/patch_hdmi.c:2526:19: note: 'jack' was declared here

This makes snd_jack_new() return an error when SND_JACK is disabled,
forcing all users to handle errors gracefully and avoiding the
problem in all callers that correctly check the return code.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 788d441a164c ("ALSA: hda - Use component ops for i915 HDMI/DP audio jack handling")
---
 include/sound/jack.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/sound/jack.h b/include/sound/jack.h
index 23bede121c78..1e84a2e413f8 100644
--- a/include/sound/jack.h
+++ b/include/sound/jack.h
@@ -99,7 +99,7 @@ void snd_jack_report(struct snd_jack *jack, int status);
 static inline int snd_jack_new(struct snd_card *card, const char *id, int type,
 			       struct snd_jack **jack, bool initial_kctl, bool phantom_jack)
 {
-	return 0;
+	return -ENXIO;
 }
 
 static inline int snd_jack_add_new_kctl(struct snd_jack *jack, const char * name, int mask)
-- 
2.7.0



From stefano.stabellini at eu.citrix.com  Tue Feb 16 08:55:42 2016
From: stefano.stabellini at eu.citrix.com (Stefano Stabellini)
Date: Tue, 16 Feb 2016 16:55:42 +0000
Subject: [PATCH v2] xen kconfig: don't "select INPUT_XEN_KBDDEV_FRONTEND"
In-Reply-To: <2479546.WgivMO2bp2@wuerfel>
References: <1455278707-2008263-1-git-send-email-arnd@arndb.de>
 <56C20552.8030305@citrix.com>
 <alpine.DEB.2.02.1602151708110.27008@kaball.uk.xensource.com>
 <2479546.WgivMO2bp2@wuerfel>
Message-ID: <alpine.DEB.2.02.1602161655350.27008@kaball.uk.xensource.com>

On Tue, 16 Feb 2016, Arnd Bergmann wrote:
> The Xen framebuffer driver selects the xen keyboard driver, so the latter
> will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
> is a loadable module, this configuration cannot work. On mainline kernels,
> the symbol will be enabled but not used, while in combination with
> a patch I have to detect such useless configurations, we get the
> expected link failure:
> 
> drivers/input/built-in.o: In function `xenkbd_remove':
> xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
> xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
> 
> This removes the extra "select", as it just causes more trouble than
> it helps. In theory, some defconfig file might break if it has
> XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig
> fragment we ship in the kernel (kernel/configs/xen.config) however
> already enables both, and anyone using an old .config file would
> keep having both enabled.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Suggested-by: David Vrabel <david.vrabel at citrix.com>
> Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")

Acked-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>


> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 8ea45a5cd806..d889ef2048df 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2246,7 +2246,6 @@ config XEN_FBDEV_FRONTEND
>  	select FB_SYS_IMAGEBLIT
>  	select FB_SYS_FOPS
>  	select FB_DEFERRED_IO
> -	select INPUT_XEN_KBDDEV_FRONTEND if INPUT_MISC
>  	select XEN_XENBUS_FRONTEND
>  	default y
>  	help
> 


From thomas.petazzoni at free-electrons.com  Tue Feb 16 08:31:55 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Feb 2016 17:31:55 +0100
Subject: [PATCH 5/5] arm64: marvell: add Device Tree files for Armada 7K/8K
In-Reply-To: <56C19B18.8090005@arm.com>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455526065-7307-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <56C19B18.8090005@arm.com>
Message-ID: <20160216173155.4f832646@free-electrons.com>

Marc,

Thanks for the review!

On Mon, 15 Feb 2016 09:32:08 +0000, Marc Zyngier wrote:

> > +				interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> > +				reg = <0x210000 0x1000>,
> > +				      <0x220000 0x1000>,
> 
> Assuming we do have a GIC400 here (which is extremely likely), the GICC
> block should be at least 8kB to reflect the fact that this is a GICv2.

According to the datasheet I have, the GICD, GICC, GICV and GICH blocks
are all 0x10000 in size. Not sure the entire 0x10000 is actually used,
but th memory map is pretty clear.

I'll fix that in the next iteration. Thanks for spotting the
potential issue!

Best regards,

Thomas Petazzoni
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From arnd at arndb.de  Tue Feb 16 08:59:04 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 17:59:04 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <20160216163840.GA7544@sirena.org.uk>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
 <s5h4md87hnu.wl-tiwai@suse.de> <20160216163840.GA7544@sirena.org.uk>
Message-ID: <112888486.mQgaWiH0PI@wuerfel>

On Tuesday 16 February 2016 16:38:40 Mark Brown wrote:
> On Tue, Feb 16, 2016 at 05:18:29PM +0100, Takashi Iwai wrote:
> > Arnd Bergmann wrote:
> 
> > > Another option might would be to change snd_jack_new() to return
> > > an error if that SND_JACK is disabled, and then require all users
> > > to handle the error gracefully, i.e. not fail the probe() function
> > > but just not use the jack.
> 
> > Yes, I thought of that, too.  If select is no good option, it's a good
> > alternative, indeed.
> 
> It's going to be a bunch of work to implement though.
> 

I've already sent a v2 to change the snd_jack_new() function, feel free
to ignore that. I also saw now that the same bug is present in hda_jack.c,
but I think the other drivers are fine.

How about this approach below? That should also make it possible to
use the jack APIs without using a error return.

	Arnd

diff --git a/sound/pci/hda/hda_jack.c b/sound/pci/hda/hda_jack.c
index a33234e04d4f..2f72b3c09d92 100644
--- a/sound/pci/hda/hda_jack.c
+++ b/sound/pci/hda/hda_jack.c
@@ -403,8 +403,10 @@ int snd_hda_jack_add_kctl(struct hda_codec *codec, hda_nid_t nid,
 
 	jack->phantom_jack = !!phantom_jack;
 	jack->type = type;
-	jack->jack->private_data = jack;
-	jack->jack->private_free = hda_free_jack_priv;
+	if (IS_ENABLED(CONFIG_SND_JACK)) {
+		jack->jack->private_data = jack;
+		jack->jack->private_free = hda_free_jack_priv;
+	}
 	state = snd_hda_jack_detect(codec, nid);
 	snd_jack_report(jack->jack, state ? jack->type : 0);
 
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index f4443b5fbf6e..e9a0f67c92ca 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2532,8 +2532,10 @@ static int add_hdmi_jack_kctl(struct hda_codec *codec,
 		return err;
 
 	spec->pcm_rec[pcm_idx].jack = jack;
-	jack->private_data = &spec->pcm_rec[pcm_idx];
-	jack->private_free = free_hdmi_jack_priv;
+	if (IS_ENABLED(CONFIG_SND_JACK)) {
+		jack->private_data = &spec->pcm_rec[pcm_idx];
+		jack->private_free = free_hdmi_jack_priv;
+	}
 	return 0;
 }
 



From will.deacon at arm.com  Tue Feb 16 09:04:09 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 16 Feb 2016 17:04:09 +0000
Subject: [PATCH v2] arm64: add alignment fault hanling
In-Reply-To: <20160216160055.GH14509@arm.com>
References: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
 <20160216103104.GC14509@arm.com> <56C300AD.8070505@arm.com>
 <20160216122153.GD19413@e104818-lin.cambridge.arm.com>
 <20160216160055.GH14509@arm.com>
Message-ID: <20160216170408.GL14509@arm.com>

[replying to self and adding some x86 people]

Background: Euntaik reports a problem where userspace has ended up with
a memory page mapped adjacent to an MMIO page (e.g. from /dev/mem or a
PCI memory bar from someplace in /sys). strncpy_from_user happens with
the word-at-a-time implementation, and we end up reading into the MMIO
page.

Question: Does x86 guarantee that this faults? (Arjan reckoned no, but
wasn't 100%).

On Tue, Feb 16, 2016 at 04:00:55PM +0000, Will Deacon wrote:
> On Tue, Feb 16, 2016 at 12:21:53PM +0000, Catalin Marinas wrote:
> > On Tue, Feb 16, 2016 at 10:57:49AM +0000, Robin Murphy wrote:
> > > On 16/02/16 10:31, Will Deacon wrote:
> > > >On Tue, Feb 16, 2016 at 04:44:35AM +0000, EunTaik Lee wrote:
> > > >>Userspace memory is mapped as below:
> > > >>F2A7F000--F2A7FFFF Normal Memory
> > > >>F2A80000--F2A80FFF Device nGnRnE
> > > >>
> > > >>And that userspace application makes a system call
> > > >>as below:
> > > >>
> > > >>-009 |do_strncpy_from_user(inline)
> > > >>-009 |strncpy_from_user()
> > > >>-010 |getname_flags()
> > > >>-011 |user_path_at_empty()
> > > >>-012 |user_path_at()
> > > >>-013 |SYSC_faccessat(inline)
> > > >>-013 |sys_faccessat()
> > > >>-014 |__sys_trace(asm)
> > > >>  --> |exception
> > > >>
> > > >>The string spans from 0xF2A7FFC1 to 0xF2A7FFFB.
> > > >>
> > > >>When do_strncpy_from_user() reads the last (unsigned long)
> > > >>value, the alignement fault is triggered. The 8 byte
> > > >>from 0xF2A7FFC1 spans to the next page that is mapped as
> > > >>Device nGnRnE, which does not allow an unaligned access,
> > > >>causes the abort.
> > > >>
> > > >>The instruction which caused the alignment fault is registered
> > > >>in the fixup table but the exception handler does not reach there.
> > > >>
> > > >>This patch registers a alignment fault handler and fixes up the
> > > >>pc if appropriate.
> > > >
> > > >As discussed with Catalin previously, we should solve this by adding a
> > > >guard page rather than handling the fault.
> > 
> > I don't think we can trivially add this without implementing an arm64
> > specific arch_get_unmapped_area().
> 
> Even overriding arch_get_unmapped_area doesn't help as much as you might
> like since, in the case of something like /dev/mem, the memory is remapped
> using remap_pfn_range later on, so you can't necessarily tell what the
> final attributes are likely to be when you initially allocate the virtual
> space.

Thinking more about this, we could spit out a guard page between every
VMA, but it's likely to hamper any VMA merging.

Will


From thomas.petazzoni at free-electrons.com  Tue Feb 16 08:38:40 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Feb 2016 17:38:40 +0100
Subject: [PATCH 5/5] arm64: marvell: add Device Tree files for Armada 7K/8K
In-Reply-To: <20160216134219.00045b5b@xhacker>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455526065-7307-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160216134219.00045b5b@xhacker>
Message-ID: <20160216173840.7f93896f@free-electrons.com>

Hello,

On Tue, 16 Feb 2016 13:42:19 +0800, Jisheng Zhang wrote:

> > +/ {
> > +	model = "Marvell Armada AP806";
> > +	compatible = "marvell,armada-ap806";
> > +	#address-cells = <2>;
> > +	#size-cells = <2>;
> > +
> > +	psci {
> > +		compatible = "arm,psci-0.2";
> 
> I guess the firmware is also psci-1.0 compatible.

At boot time, the kernel queries the PSCI firmware, and it says:

[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv0.2 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs

So I think psci-0.2 is correct here. Should this change for the
production revision of the chip, we'll send an update to the Device
Tree accordingly.

> > +	ap806 {
> > +		#address-cells = <2>;
> > +		#size-cells = <2>;
> > +		compatible = "simple-bus";
> > +		interrupt-parent = <&gic>;
> > +		ranges;
> > +
> > +		config-space {
> > +			#address-cells = <1>;
> > +			#size-cells = <1>;
> > +			compatible = "simple-bus";
> > +			ranges = <0x0 0x0 0xf0000000 0x1000000>;
> > +
> > +			gic: interrupt-controller at 210000 {
> > +				compatible = "arm,cortex-a15-gic",
> > +					     "arm,cortex-a9-gic";
> 
> I guess the GIC is neither the one in cortex-a15 or cortex-a9. 

What makes you think this?

The GIC is a GIC400, which is GICv2 compliant, and arm-cortex-a15-gic /
arm-cortex-a9-gic are valid compatible strings to identify a GICv2
compliant interrupt controller.

See:

arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi:              compatible = "arm,gic-400", "arm,cortex-a15-gic";
arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi:           compatible = "arm,gic-400", "arm,cortex-a15-gic";
arch/arm64/boot/dts/apm/apm-shadowcat.dtsi:             compatible = "arm,cortex-a15-gic";
arch/arm64/boot/dts/apm/apm-storm.dtsi:         compatible = "arm,cortex-a15-gic";
arch/arm64/boot/dts/arm/foundation-v8.dts:              compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
arch/arm64/boot/dts/arm/juno-base.dtsi:         compatible = "arm,gic-400", "arm,cortex-a15-gic";
arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts:             compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
arch/arm64/boot/dts/marvell/armada-ap806.dtsi:                          compatible = "arm,cortex-a15-gic",
arch/arm64/boot/dts/nvidia/tegra132.dtsi:               compatible = "arm,cortex-a15-gic";
arch/arm64/boot/dts/xilinx/zynqmp.dtsi:                 compatible = "arm,gic-400", "arm,cortex-a15-gic";

Or do you have a more specific reason to think that this compatible
string is wrong?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From marc.zyngier at arm.com  Tue Feb 16 09:06:00 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 16 Feb 2016 17:06:00 +0000
Subject: [PATCH 5/5] arm64: marvell: add Device Tree files for Armada 7K/8K
In-Reply-To: <20160216173155.4f832646@free-electrons.com>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455526065-7307-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <56C19B18.8090005@arm.com> <20160216173155.4f832646@free-electrons.com>
Message-ID: <56C356F8.8080105@arm.com>

On 16/02/16 16:31, Thomas Petazzoni wrote:
> Marc,
> 
> Thanks for the review!
> 
> On Mon, 15 Feb 2016 09:32:08 +0000, Marc Zyngier wrote:
> 
>>> +				interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>>> +				reg = <0x210000 0x1000>,
>>> +				      <0x220000 0x1000>,
>>
>> Assuming we do have a GIC400 here (which is extremely likely), the GICC
>> block should be at least 8kB to reflect the fact that this is a GICv2.
> 
> According to the datasheet I have, the GICD, GICC, GICV and GICH blocks
> are all 0x10000 in size. Not sure the entire 0x10000 is actually used,
> but th memory map is pretty clear.

No, that's just a way to make sure that you can give the GICV block to a
guest while using 64k pages.

Talking about GICV: are you sure it is 0x10000 and not 0x20000? SBSA
recommends to have the first 4kB GICV page aliased over 64kB, and the
second 4kB page over the second 64kB block. That is to ensure that a
hypervisor can trap access to GICV_DIR register independently of the
rest of the virtual CPU interface.

But hey, almost everybody got it wrong so far, so I wouldn't be
surprised if that was broken on this platform as well...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From arnd at arndb.de  Tue Feb 16 09:09:11 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 18:09:11 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <112888486.mQgaWiH0PI@wuerfel>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
 <20160216163840.GA7544@sirena.org.uk> <112888486.mQgaWiH0PI@wuerfel>
Message-ID: <12468747.ft2nGomr6c@wuerfel>

On Tuesday 16 February 2016 17:59:04 Arnd Bergmann wrote:
> --- a/sound/pci/hda/hda_jack.c
> +++ b/sound/pci/hda/hda_jack.c
> @@ -403,8 +403,10 @@ int snd_hda_jack_add_kctl(struct hda_codec *codec, hda_nid_t nid,
>  
>         jack->phantom_jack = !!phantom_jack;
>         jack->type = type;
> -       jack->jack->private_data = jack;
> -       jack->jack->private_free = hda_free_jack_priv;
> +       if (IS_ENABLED(CONFIG_SND_JACK)) {
> +               jack->jack->private_data = jack;
> +               jack->jack->private_free = hda_free_jack_priv;
> +       }
>         state = snd_hda_jack_detect(codec, nid);
>         snd_jack_report(jack->jack, state ? jack->type : 0);
>  

Or another idea: if we pass private_{data,free} into snd_jack_new()
as arguments, the snd_jack structure can become private to
sound/core/jack.c, so we can be sure to never hit this bug
again.

	Arnd


From catalin.marinas at arm.com  Tue Feb 16 09:09:25 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 16 Feb 2016 17:09:25 +0000
Subject: [PATCH v2] arm64: add alignment fault hanling
In-Reply-To: <20160216160055.GH14509@arm.com>
References: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
 <20160216103104.GC14509@arm.com> <56C300AD.8070505@arm.com>
 <20160216122153.GD19413@e104818-lin.cambridge.arm.com>
 <20160216160055.GH14509@arm.com>
Message-ID: <20160216170924.GA24950@localhost.localdomain>

On Tue, Feb 16, 2016 at 04:00:55PM +0000, Will Deacon wrote:
> On Tue, Feb 16, 2016 at 12:21:53PM +0000, Catalin Marinas wrote:
> > On Tue, Feb 16, 2016 at 10:57:49AM +0000, Robin Murphy wrote:
> > > On 16/02/16 10:31, Will Deacon wrote:
> > > >On Tue, Feb 16, 2016 at 04:44:35AM +0000, EunTaik Lee wrote:
> > > >>Userspace memory is mapped as below:
> > > >>F2A7F000--F2A7FFFF Normal Memory
> > > >>F2A80000--F2A80FFF Device nGnRnE
> > > >>
> > > >>And that userspace application makes a system call
> > > >>as below:
> > > >>
> > > >>-009 |do_strncpy_from_user(inline)
> > > >>-009 |strncpy_from_user()
> > > >>-010 |getname_flags()
> > > >>-011 |user_path_at_empty()
> > > >>-012 |user_path_at()
> > > >>-013 |SYSC_faccessat(inline)
> > > >>-013 |sys_faccessat()
> > > >>-014 |__sys_trace(asm)
> > > >>  --> |exception
> > > >>
> > > >>The string spans from 0xF2A7FFC1 to 0xF2A7FFFB.
> > > >>
> > > >>When do_strncpy_from_user() reads the last (unsigned long)
> > > >>value, the alignement fault is triggered. The 8 byte
> > > >>from 0xF2A7FFC1 spans to the next page that is mapped as
> > > >>Device nGnRnE, which does not allow an unaligned access,
> > > >>causes the abort.
> > > >>
> > > >>The instruction which caused the alignment fault is registered
> > > >>in the fixup table but the exception handler does not reach there.
> > > >>
> > > >>This patch registers a alignment fault handler and fixes up the
> > > >>pc if appropriate.
> > > >
> > > >As discussed with Catalin previously, we should solve this by adding a
> > > >guard page rather than handling the fault.
> > 
> > I don't think we can trivially add this without implementing an arm64
> > specific arch_get_unmapped_area().
> 
> Even overriding arch_get_unmapped_area doesn't help as much as you might
> like since, in the case of something like /dev/mem, the memory is remapped
> using remap_pfn_range later on, so you can't necessarily tell what the
> final attributes are likely to be when you initially allocate the virtual
> space.

This is not about attributes but allowing a guard page on each side of
the mmap range. So do_mmap() would get an unmapped range via
get_unmapped_area() and mmap_region() would populate the vma before
calling file->f_op->mmap(). Of course, we still can't prevent user
asking for specific addresses via mmap(2), but in this case you can say
it's the user's fault.

The do_strncpy_from_user() issue apart, as long as we allow Device
mappings in user space, we need to allow the kernel to handle unaligned
accesses via get_user. This means using do_bad_area for the alignment
fault instead of do_bad.

-- 
Catalin


From tiwai at suse.de  Tue Feb 16 09:10:02 2016
From: tiwai at suse.de (Takashi Iwai)
Date: Tue, 16 Feb 2016 18:10:02 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <112888486.mQgaWiH0PI@wuerfel>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
 <s5h4md87hnu.wl-tiwai@suse.de>
 <20160216163840.GA7544@sirena.org.uk>
 <112888486.mQgaWiH0PI@wuerfel>
Message-ID: <s5hr3gc60ph.wl-tiwai@suse.de>

On Tue, 16 Feb 2016 17:59:04 +0100,
Arnd Bergmann wrote:
> 
> On Tuesday 16 February 2016 16:38:40 Mark Brown wrote:
> > On Tue, Feb 16, 2016 at 05:18:29PM +0100, Takashi Iwai wrote:
> > > Arnd Bergmann wrote:
> > 
> > > > Another option might would be to change snd_jack_new() to return
> > > > an error if that SND_JACK is disabled, and then require all users
> > > > to handle the error gracefully, i.e. not fail the probe() function
> > > > but just not use the jack.
> > 
> > > Yes, I thought of that, too.  If select is no good option, it's a good
> > > alternative, indeed.
> > 
> > It's going to be a bunch of work to implement though.
> > 
> 
> I've already sent a v2 to change the snd_jack_new() function, feel free
> to ignore that. I also saw now that the same bug is present in hda_jack.c,
> but I think the other drivers are fine.
> 
> How about this approach below? That should also make it possible to
> use the jack APIs without using a error return.

I prefer setting NULL explicitly in snd_jack_new(), and let callers
checking NULL.  Then we can avoid ugly IS_ENABLE() while the compiler
should be still capable to optimize out.

OTOH, I think it'd be a waste of time to bikeshedding too much, so I
don't care so much which to take :)


Takashi

---
diff --git a/include/sound/jack.h b/include/sound/jack.h
index 23bede121c78..a27c253a3207 100644
--- a/include/sound/jack.h
+++ b/include/sound/jack.h
@@ -99,6 +99,7 @@ void snd_jack_report(struct snd_jack *jack, int status);
 static inline int snd_jack_new(struct snd_card *card, const char *id, int type,
 			       struct snd_jack **jack, bool initial_kctl, bool phantom_jack)
 {
+	*jack = NULL;
 	return 0;
 }
 
diff --git a/sound/pci/hda/hda_jack.c b/sound/pci/hda/hda_jack.c
index a33234e04d4f..babd3a8864a1 100644
--- a/sound/pci/hda/hda_jack.c
+++ b/sound/pci/hda/hda_jack.c
@@ -403,10 +403,12 @@ int snd_hda_jack_add_kctl(struct hda_codec *codec, hda_nid_t nid,
 
 	jack->phantom_jack = !!phantom_jack;
 	jack->type = type;
-	jack->jack->private_data = jack;
-	jack->jack->private_free = hda_free_jack_priv;
-	state = snd_hda_jack_detect(codec, nid);
-	snd_jack_report(jack->jack, state ? jack->type : 0);
+	if (jack->jack) {
+		jack->jack->private_data = jack;
+		jack->jack->private_free = hda_free_jack_priv;
+		state = snd_hda_jack_detect(codec, nid);
+		snd_jack_report(jack->jack, state ? jack->type : 0);
+	}
 
 	return 0;
 }
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 8ee78dbd4c60..34a7b3aaba11 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2158,8 +2158,10 @@ static int add_acomp_jack_kctl(struct hda_codec *codec,
 	if (err < 0)
 		return err;
 	per_pin->acomp_jack = jack;
-	jack->private_data = per_pin;
-	jack->private_free = free_acomp_jack_priv;
+	if (jack) {
+		jack->private_data = per_pin;
+		jack->private_free = free_acomp_jack_priv;
+	}
 	return 0;
 }
 


From fu.wei at linaro.org  Tue Feb 16 09:08:46 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Wed, 17 Feb 2016 01:08:46 +0800
Subject: [PATCH v13 0/4] Watchdog: introduce ARM SBSA watchdog driver
Message-ID: <1455642530-19103-1-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This patchset:
    (1)Introduce Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
    for FDT info of SBSA Generic Watchdog, and give two examples of
    adding SBSA Generic Watchdog device node into the dts files:
    foundation-v8.dts and amd-seattle-soc.dtsi.

    (2)Introduce ARM SBSA watchdog driver:
        a.Use linux kernel watchdog framework;
        b.Work with FDT on ARM64;
        c.Support getting timeout from parameter and FDT at the driver
          init stage.
        d.The driver works in two modes:
          (1) single stage timeout (ignore WS0 interrupt)
          (2) two stages timeout (register WS0 interrupt, do panic in routine)
        e.User can config working mode by module parameter "action".

This patchset has been tested with watchdog daemon
(ACPI/FDT, module/build-in) on the following platforms:
    (1)ARM Foundation v8 model
    (2)AMD Seattle platform

This patchset has been tested with kdump successfully.

Changelog:
v13:Fix a dev_warn message typo"signle"-->"single"
    Add MODULE_ALIAS
    Add more *ed-by in commit message.

v12:https://lkml.org/lkml/2016/2/16/154
    Fix a dev_warn message typo"fall"--"falling"
    Remove unnecessary "status" in dts
    Add more *ed-by in commit message.

v11:https://lkml.org/lkml/2016/2/9/577
    Merge patch 4 and 5.
    Improve some comments.
    The driver works in two modes, it's configured by "action"(instead of
    panic_enabled).
    Improve the initialization of the timeout limits.
    Feeding dog by writing "0" to WRR.

v10:https://lkml.org/lkml/2016/2/3/817
    Delete pretimeout support.
    Separate the driver to two parts:
        (1) single stage timeout driver(ignore WS0 interrupt);
        (2) register WS0 interrupt for the half timeout panic.
    timeout == (enable --> WS1).

v9: https://lkml.org/lkml/2015/11/9/57
    Rebase to latest kernel version(4.3).
    Update the Documentation of sbsa-gwdt device node info of FDT:
        (1) move some introduction to pretimeout patch
        (2) delete WS1 value from "interrupts" of binding documentation,
            since WS1 won't be handled by Linux.

v8: https://lkml.org/lkml/2015/10/27/466
    Rebase to latest kernel version(4.3-rc7).
    Separate the patches of GTDT support and arm_arch_timer. This
    clocksource relevant patch will upstreamed in a individual patchset.
    Update all the default timeout and pretimeout to 30s and 60s.
    Improve documentation and inline comments.
    Fix a bug in pretimeout support which makes timeout and pretimeout
    parameters initialization fail.

v7: https://lkml.org/lkml/2015/8/24/611
    Rebase to latest kernel version(4.2-rc7).
    Improve FDT support: geting resource by order, instead of name.
    According to the FDT support, Update the example dts file, gtdt.c
    and sbsa_gwdt.c.
    Pass the sparse test, and fix the warning.
    Fix the max_pretimeout and max_timeout value overflow bug.
    Delete the WCV output value.
    

v6: https://lkml.org/lkml/2015/6/23/359
    Improve the dtb example files: reduce the register frame size to 4K.
    Improve pretimeout support:
        (1) improve watchdog_init_timeouts function
	(2) rename watchdog_check_min_max_timeouts back to the original name
        (1) improve watchdog_timeout_invalid/watchdog_pretimeout_invalid
    Add the new features in the sbsa_gwdt driver:
	(1) In the second stage, user can feed the dog without cleaning WS0.
	(2) In the second stage, user can trigger WS1 by setting pretimeout = 0.
	(3) expand the max value of pretimeout, in case 10 second is not enough
	    for a kdump kernel reboot in panic.

v5: https://lkml.org/lkml/2015/6/10/357
    Improve pretimeout support:
        (1)fix typo in documentation and comments.
	(2)fix the timeout limits validation bug.
    Simplify sbsa_gwdt driver:
	(1)integrate all the registers access functions into caller.

v4: https://lkml.org/lkml/2015/6/2/4
    Refactor GTDT support code: remove it from arch/arm64/kernel/acpi.c,
    put it into drivers/acpi/gtdt.c file.
    Integrate the GTDT code of drivers/clocksource/arm_arch_timer.c into
    drivers/acpi/gtdt.c.
    Improve pretimeout support, fix "pretimeout == 0" problem.
    Simplify sbsa_gwdt driver:
        (1)timeout/pretimeout limits setup;
        (2)keepalive function;
        (3)delete "clk == 0" check;
        (4)delete WS0 status bit check in interrupt routine;
        (5)sbsa_gwdt_set_wcv function.

v3: https://lkml.org/lkml/2015/5/25/111
    Delete "export arch_timer_get_rate" patch.
    Driver back to use arch_timer_get_cntfrq.
    Improve watchdog_init_timeouts function and update relevant documentation.
    Improve watchdog_timeout_invalid and watchdog_pretimeout_invalid.
    Improve foundation-v8.dts: delete the unnecessary tag of device node.
    Remove "ARM64 || COMPILE_TEST" from Kconfig.
    Add comments in arch/arm64/kernel/acpi.c
    Fix typoes and incorrect comments.

v2: https://lkml.org/lkml/2015/5/21/172
    Improve watchdog-kernel-api.txt documentation for pretimeout support.
    Export "arch_timer_get_rate" in arm_arch_timer.c.
    Add watchdog_init_timeouts API for pretimeout support in framework.
    Improve suspend and resume foundation in driver
    Improve timeout/pretimeout values init code in driver.
    Delete unnecessary items of the sbsa_gwdt struct and #define.
    Delete all unnecessary debug info in driver.
    Fix 64bit division bug.
    Use the arch_timer interface to get watchdog clock rate.
    Add MODULE_DEVICE_TABLE for platform device id.
    Fix typoes.

v1: https://lkml.org/lkml/2015/5/15/279
    The first version upstream patchset to linux mailing list.

Fu Wei (4):
  Documentation: add sbsa-gwdt driver documentation
  ARM64: add SBSA Generic Watchdog device node in foundation-v8.dts
  ARM64: add SBSA Generic Watchdog device node in amd-seattle-soc.dtsi
  Watchdog: introduce ARM SBSA watchdog driver

 .../devicetree/bindings/watchdog/sbsa-gwdt.txt     |  31 ++
 Documentation/watchdog/watchdog-parameters.txt     |   7 +
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi       |   8 +
 arch/arm64/boot/dts/arm/foundation-v8.dts          |   7 +
 drivers/watchdog/Kconfig                           |  20 +
 drivers/watchdog/Makefile                          |   1 +
 drivers/watchdog/sbsa_gwdt.c                       | 404 +++++++++++++++++++++
 7 files changed, 478 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
 create mode 100644 drivers/watchdog/sbsa_gwdt.c

-- 
2.5.0



From catalin.marinas at arm.com  Tue Feb 16 09:11:33 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 16 Feb 2016 17:11:33 +0000
Subject: [PATCH v2] arm64: add alignment fault hanling
In-Reply-To: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
References: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
Message-ID: <20160216171133.GB24950@localhost.localdomain>

On Tue, Feb 16, 2016 at 04:44:38AM +0000, EunTaik Lee wrote:
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 19211c4..a5ebb99 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -371,6 +371,14 @@ static int __kprobes do_translation_fault(unsigned long addr,
>  	return 0;
>  }
>  
> +static int __kprobes do_alignment_fault(unsigned long addr,
> +					  unsigned int esr,
> +					  struct pt_regs *regs)
> +{
> +	do_bad_area(addr, esr, regs);
> +	return 0;
> +}
> +
>  /*
>   * This abort handler always returns "fault".
>   */
> @@ -418,7 +426,7 @@ static struct fault_info {
>  	{ do_bad,		SIGBUS,  0,		"synchronous parity error (translation table walk" },
>  	{ do_bad,		SIGBUS,  0,		"synchronous parity error (translation table walk" },
>  	{ do_bad,		SIGBUS,  0,		"unknown 32"			},
> -	{ do_bad,		SIGBUS,  BUS_ADRALN,	"alignment fault"		},
> +	{ do_alignment_fault,	SIGBUS,  BUS_ADRALN,	"alignment fault"		},

Do you need a new function, can you not just add do_bad_area in the
fault_info array?

-- 
Catalin


From fu.wei at linaro.org  Tue Feb 16 09:08:47 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Wed, 17 Feb 2016 01:08:47 +0800
Subject: [PATCH v13 1/4] Documentation: add sbsa-gwdt driver documentation
In-Reply-To: <1455642530-19103-1-git-send-email-fu.wei@linaro.org>
References: <1455642530-19103-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1455642530-19103-2-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

The sbsa-gwdt.txt documentation in devicetree/bindings/watchdog is for
introducing SBSA(Server Base System Architecture) Generic Watchdog
device node info into FDT.

Also add sbsa-gwdt introduction in watchdog-parameters.txt

Acked-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Fu Wei <fu.wei at linaro.org>
Reviewed-by: Guenter Roeck <linux at roeck-us.net>
---
 .../devicetree/bindings/watchdog/sbsa-gwdt.txt     | 31 ++++++++++++++++++++++
 Documentation/watchdog/watchdog-parameters.txt     |  7 +++++
 2 files changed, 38 insertions(+)

diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
new file mode 100644
index 0000000..6f2d5f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt
@@ -0,0 +1,31 @@
+* SBSA (Server Base System Architecture) Generic Watchdog
+
+The SBSA Generic Watchdog Timer is used to force a reset of the system
+after two stages of timeout have elapsed.  A detailed definition of the
+watchdog timer can be found in the ARM document: ARM-DEN-0029 - Server
+Base System Architecture (SBSA)
+
+Required properties:
+- compatible: Should at least contain "arm,sbsa-gwdt".
+
+- reg: Each entry specifies the base physical address of a register frame
+  and the length of that frame; currently, two frames must be defined,
+  in this order:
+  1: Watchdog control frame;
+  2: Refresh frame.
+
+- interrupts: Should contain the Watchdog Signal 0 (WS0) SPI (Shared
+  Peripheral Interrupt) number of SBSA Generic Watchdog.
+
+Optional properties
+- timeout-sec: Watchdog timeout values (in seconds).
+
+Example for FVP Foundation Model v8:
+
+watchdog at 2a440000 {
+	compatible = "arm,sbsa-gwdt";
+	reg = <0x0 0x2a440000 0 0x1000>,
+	      <0x0 0x2a450000 0 0x1000>;
+	interrupts = <0 27 4>;
+	timeout-sec = <30>;
+};
diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
index 9f9ec9f..ce7ae4e 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -284,6 +284,13 @@ sbc_fitpc2_wdt:
 margin: Watchdog margin in seconds (default 60s)
 nowayout: Watchdog cannot be stopped once started
 -------------------------------------------------
+sbsa_gwdt:
+timeout: Watchdog timeout in seconds. (default 10s)
+action: Watchdog action at the first stage timeout,
+	set to 0 to ignore, 1 to panic. (default=0)
+nowayout: Watchdog cannot be stopped once started
+	(default=kernel config parameter)
+-------------------------------------------------
 sc1200wdt:
 isapnp: When set to 0 driver ISA PnP support will be disabled (default=1)
 io: io port
-- 
2.5.0



From fu.wei at linaro.org  Tue Feb 16 09:08:48 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Wed, 17 Feb 2016 01:08:48 +0800
Subject: [PATCH v13 2/4] ARM64: add SBSA Generic Watchdog device node in
 foundation-v8.dts
In-Reply-To: <1455642530-19103-1-git-send-email-fu.wei@linaro.org>
References: <1455642530-19103-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1455642530-19103-3-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Fu Wei <fu.wei at linaro.org>
Reviewed-by: Guenter Roeck <linux at roeck-us.net>
---
 arch/arm64/boot/dts/arm/foundation-v8.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dts b/arch/arm64/boot/dts/arm/foundation-v8.dts
index 4eac8dc..66cb9aa 100644
--- a/arch/arm64/boot/dts/arm/foundation-v8.dts
+++ b/arch/arm64/boot/dts/arm/foundation-v8.dts
@@ -237,4 +237,11 @@
 			};
 		};
 	};
+	watchdog at 2a440000 {
+		compatible = "arm,sbsa-gwdt";
+		reg = <0x0 0x2a440000 0 0x1000>,
+			<0x0 0x2a450000 0 0x1000>;
+		interrupts = <0 27 4>;
+		timeout-sec = <30>;
+	};
 };
-- 
2.5.0



From fu.wei at linaro.org  Tue Feb 16 09:08:49 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Wed, 17 Feb 2016 01:08:49 +0800
Subject: [PATCH v13 3/4] ARM64: add SBSA Generic Watchdog device node in
 amd-seattle-soc.dtsi
In-Reply-To: <1455642530-19103-1-git-send-email-fu.wei@linaro.org>
References: <1455642530-19103-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1455642530-19103-4-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

This can be a example of adding SBSA Generic Watchdog device node
into some dts files for the Soc which contains SBSA Generic Watchdog.

Acked-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
Signed-off-by: Fu Wei <fu.wei at linaro.org>
Reviewed-by: Guenter Roeck <linux at roeck-us.net>
---
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index 2874d92..0a8ca1d 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -84,6 +84,14 @@
 			clock-names = "uartclk", "apb_pclk";
 		};
 
+		watchdog0: watchdog at e0bb0000 {
+			compatible = "arm,sbsa-gwdt";
+			reg = <0x0 0xe0bc0000 0 0x1000>,
+				<0x0 0xe0bb0000 0 0x1000>;
+			interrupts = <0 337 4>;
+			timeout-sec = <15>;
+		};
+
 		spi0: ssp at e1020000 {
 			status = "disabled";
 			compatible = "arm,pl022", "arm,primecell";
-- 
2.5.0



From fu.wei at linaro.org  Tue Feb 16 09:08:50 2016
From: fu.wei at linaro.org (fu.wei at linaro.org)
Date: Wed, 17 Feb 2016 01:08:50 +0800
Subject: [PATCH v13 4/4] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <1455642530-19103-1-git-send-email-fu.wei@linaro.org>
References: <1455642530-19103-1-git-send-email-fu.wei@linaro.org>
Message-ID: <1455642530-19103-5-git-send-email-fu.wei@linaro.org>

From: Fu Wei <fu.wei at linaro.org>

According to Server Base System Architecture (SBSA) specification,
the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0)
is for alerting the system by interrupt, the second one (WS1) is a real
hardware reset.
More details about the hardware specification of this device:
ARM DEN0029B - Server Base System Architecture (SBSA)

This driver can operate ARM SBSA Generic Watchdog as a single stage watchdog
or a two stages watchdog, it's set up by the module parameter "action".
In the single stage mode, when the timeout is reached, your system
will be reset by WS1. The first signal (WS0) is ignored.
In the two stages mode, when the timeout is reached, the first signal (WS0)
will trigger panic. If the system is getting into trouble and cannot be reset
by panic or restart properly by the kdump kernel(if supported), then the
second stage (as long as the first stage) will be reached, system will be
reset by WS1. This function can help administrator to backup the system
context info by panic console output or kdump.

This driver bases on linux kernel watchdog framework, so it can get
timeout from module parameter and FDT at the driver init stage.

Signed-off-by: Fu Wei <fu.wei at linaro.org>
Reviewed-by: Graeme Gregory <graeme.gregory at linaro.org>
Tested-by: Pratyush Anand <panand at redhat.com>
Acked-by: Timur Tabi <timur at codeaurora.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
---
 drivers/watchdog/Kconfig     |  20 +++
 drivers/watchdog/Makefile    |   1 +
 drivers/watchdog/sbsa_gwdt.c | 404 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 425 insertions(+)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 0f6d851..38a7f5c 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -202,6 +202,26 @@ config ARM_SP805_WATCHDOG
 	  ARM Primecell SP805 Watchdog timer. This will reboot your system when
 	  the timeout is reached.
 
+config ARM_SBSA_WATCHDOG
+	tristate "ARM SBSA Generic Watchdog"
+	depends on ARM64
+	depends on ARM_ARCH_TIMER
+	select WATCHDOG_CORE
+	help
+	  ARM SBSA Generic Watchdog has two stage timeouts:
+	  the first signal (WS0) is for alerting the system by interrupt,
+	  the second one (WS1) is a real hardware reset.
+	  More details: ARM DEN0029B - Server Base System Architecture (SBSA)
+
+	  This driver can operate ARM SBSA Generic Watchdog as a single stage
+	  or a two stages watchdog, it depends on the module parameter "action".
+
+	  Note: the maximum timeout in the two stages mode is half of that in
+	  the single stage mode.
+
+	  To compile this driver as module, choose M here: The module
+	  will be called sbsa_gwdt.
+
 config ASM9260_WATCHDOG
 	tristate "Alphascale ASM9260 watchdog"
 	depends on MACH_ASM9260
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index f566753..f9826d4 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
 
 # ARM Architecture
 obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
+obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
 obj-$(CONFIG_ASM9260_WATCHDOG) += asm9260_wdt.o
 obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
 obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
new file mode 100644
index 0000000..4a5260f
--- /dev/null
+++ b/drivers/watchdog/sbsa_gwdt.c
@@ -0,0 +1,404 @@
+/*
+ * SBSA(Server Base System Architecture) Generic Watchdog driver
+ *
+ * Copyright (c) 2015, Linaro Ltd.
+ * Author: Fu Wei <fu.wei at linaro.org>
+ *         Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
+ *         Al Stone <al.stone at linaro.org>
+ *         Timur Tabi <timur at codeaurora.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License 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.
+ *
+ * ARM SBSA Generic Watchdog has two stage timeouts:
+ * the first signal (WS0) is for alerting the system by interrupt,
+ * the second one (WS1) is a real hardware reset.
+ * More details about the hardware specification of this device:
+ * ARM DEN0029B - Server Base System Architecture (SBSA)
+ *
+ * This driver can operate ARM SBSA Generic Watchdog as a single stage watchdog
+ * or a two stages watchdog, it's set up by the module parameter "action".
+ * In the single stage mode, when the timeout is reached, your system
+ * will be reset by WS1. The first signal (WS0) is ignored.
+ * In the two stages mode, when the timeout is reached, the first signal (WS0)
+ * will trigger panic. If the system is getting into trouble and cannot be reset
+ * by panic or restart properly by the kdump kernel(if supported), then the
+ * second stage (as long as the first stage) will be reached, system will be
+ * reset by WS1. This function can help administrator to backup the system
+ * context info by panic console output or kdump.
+ *
+ * SBSA GWDT:
+ * if action is 1 (the two stages mode):
+ * |--------WOR-------WS0--------WOR-------WS1
+ * |----timeout-----(panic)----timeout-----reset
+ *
+ * if action is 0 (the single stage mode):
+ * |------WOR-----WS0(ignored)-----WOR------WS1
+ * |--------------timeout-------------------reset
+ *
+ * Note: Since this watchdog timer has two stages, and each stage is determined
+ * by WOR, in the single stage mode, the timeout is (WOR * 2); in the two
+ * stages mode, the timeout is WOR. The maximum timeout in the two stages mode
+ * is half of that in the single stage mode.
+ *
+ */
+
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/uaccess.h>
+#include <linux/watchdog.h>
+#include <asm/arch_timer.h>
+
+/* SBSA Generic Watchdog register definitions */
+/* refresh frame */
+#define SBSA_GWDT_WRR				0x000
+
+/* control frame */
+#define SBSA_GWDT_WCS				0x000
+#define SBSA_GWDT_WOR				0x008
+#define SBSA_GWDT_WCV				0x010
+
+/* refresh/control frame */
+#define SBSA_GWDT_W_IIDR			0xfcc
+#define SBSA_GWDT_IDR				0xfd0
+
+/* Watchdog Control and Status Register */
+#define SBSA_GWDT_WCS_EN			BIT(0)
+#define SBSA_GWDT_WCS_WS0			BIT(1)
+#define SBSA_GWDT_WCS_WS1			BIT(2)
+
+/**
+ * struct sbsa_gwdt - Internal representation of the SBSA GWDT
+ * @wdd:		kernel watchdog_device structure
+ * @clk:		store the System Counter clock frequency, in Hz.
+ * @refresh_base:	Virtual address of the watchdog refresh frame
+ * @control_base:	Virtual address of the watchdog control frame
+ */
+struct sbsa_gwdt {
+	struct watchdog_device	wdd;
+	u32			clk;
+	void __iomem		*refresh_base;
+	void __iomem		*control_base;
+};
+
+#define to_sbsa_gwdt(e) container_of(e, struct sbsa_gwdt, wdd)
+
+#define DEFAULT_TIMEOUT		10 /* seconds, the 1st + 2nd watch periods*/
+
+static unsigned int timeout;
+module_param(timeout, uint, 0);
+MODULE_PARM_DESC(timeout,
+		 "Watchdog timeout in seconds. (>=0, default="
+		 __MODULE_STRING(DEFAULT_TIMEOUT) ")");
+
+/*
+ * action refers to action taken when watchdog gets WS0
+ * 0 = skip
+ * 1 = panic
+ * defaults to skip (0)
+ */
+static int action;
+module_param(action, int, 0);
+MODULE_PARM_DESC(action, "after watchdog gets WS0 interrupt, do: "
+		 "0 = skip(*)  1 = panic");
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, S_IRUGO);
+MODULE_PARM_DESC(nowayout,
+		 "Watchdog cannot be stopped once started (default="
+		 __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+/*
+ * watchdog operation functions
+ */
+static int sbsa_gwdt_set_timeout(struct watchdog_device *wdd,
+				 unsigned int timeout)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	wdd->timeout = timeout;
+
+	if (action)
+		writel(gwdt->clk * timeout,
+		       gwdt->control_base + SBSA_GWDT_WOR);
+	else
+		/*
+		 * In the single stage mode, The first signal (WS0) is ignored,
+		 * the timeout is (WOR * 2), so the WOR should be configured
+		 * to half value of timeout.
+		 */
+		writel(gwdt->clk / 2 * timeout,
+		       gwdt->control_base + SBSA_GWDT_WOR);
+
+	return 0;
+}
+
+static unsigned int sbsa_gwdt_get_timeleft(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+	u64 timeleft = 0;
+
+	/*
+	 * In the single stage mode, if WS0 is deasserted
+	 * (watchdog is in the first stage),
+	 * timeleft = WOR + (WCV - system counter)
+	 */
+	if (!action &&
+	    !(readl(gwdt->control_base + SBSA_GWDT_WCS) & SBSA_GWDT_WCS_WS0))
+		timeleft += readl(gwdt->control_base + SBSA_GWDT_WOR);
+
+	timeleft += readq(gwdt->control_base + SBSA_GWDT_WCV) -
+		    arch_counter_get_cntvct();
+
+	do_div(timeleft, gwdt->clk);
+
+	return timeleft;
+}
+
+static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	/*
+	* Writing WRR for an explicit watchdog refresh.
+	* You can write anyting (like 0).
+	*/
+	writel(0, gwdt->refresh_base + SBSA_GWDT_WRR);
+
+	return 0;
+}
+
+static unsigned int sbsa_gwdt_status(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+	u32 status = readl(gwdt->control_base + SBSA_GWDT_WCS);
+
+	/* is the watchdog timer running? */
+	return (status & SBSA_GWDT_WCS_EN) << WDOG_ACTIVE;
+}
+
+static int sbsa_gwdt_start(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	/* writing WCS will cause an explicit watchdog refresh */
+	writel(SBSA_GWDT_WCS_EN, gwdt->control_base + SBSA_GWDT_WCS);
+
+	return sbsa_gwdt_keepalive(wdd);
+}
+
+static int sbsa_gwdt_stop(struct watchdog_device *wdd)
+{
+	struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
+
+	/* Simply write 0 to WCS to clean WCS_EN bit */
+	writel(0, gwdt->control_base + SBSA_GWDT_WCS);
+
+	return 0;
+}
+
+static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
+{
+	panic("SBSA Watchdog timeout");
+
+	return IRQ_HANDLED;
+}
+
+static struct watchdog_info sbsa_gwdt_info = {
+	.identity	= "SBSA Generic Watchdog",
+	.options	= WDIOF_SETTIMEOUT |
+			  WDIOF_KEEPALIVEPING |
+			  WDIOF_MAGICCLOSE |
+			  WDIOF_CARDRESET,
+};
+
+static struct watchdog_ops sbsa_gwdt_ops = {
+	.owner		= THIS_MODULE,
+	.start		= sbsa_gwdt_start,
+	.stop		= sbsa_gwdt_stop,
+	.status		= sbsa_gwdt_status,
+	.ping		= sbsa_gwdt_keepalive,
+	.set_timeout	= sbsa_gwdt_set_timeout,
+	.get_timeleft	= sbsa_gwdt_get_timeleft,
+};
+
+static int sbsa_gwdt_probe(struct platform_device *pdev)
+{
+	void __iomem *rf_base, *cf_base;
+	struct device *dev = &pdev->dev;
+	struct watchdog_device *wdd;
+	struct sbsa_gwdt *gwdt;
+	struct resource *res;
+	int ret, irq;
+	u32 status;
+
+	gwdt = devm_kzalloc(dev, sizeof(*gwdt), GFP_KERNEL);
+	if (!gwdt)
+		return -ENOMEM;
+	platform_set_drvdata(pdev, gwdt);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	cf_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(cf_base))
+		return PTR_ERR(cf_base);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	rf_base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(rf_base))
+		return PTR_ERR(rf_base);
+
+	if (action) {
+		irq = platform_get_irq(pdev, 0);
+		if (irq < 0) {
+			action = 0;
+			dev_warn(dev, "unable to get ws0 interrupt.\n");
+		} else {
+			if (devm_request_irq(dev, irq, sbsa_gwdt_interrupt, 0,
+					     pdev->name, gwdt)) {
+				action = 0;
+				dev_warn(dev, "unable to request IRQ %d.\n",
+					 irq);
+			}
+		}
+		if (!action)
+			dev_warn(dev, "falling back to single stage mode.\n");
+	}
+
+	/*
+	 * Get the frequency of system counter from the cp15 interface of ARM
+	 * Generic timer. We don't need to check it, because if it returns "0",
+	 * system would panic in very early stage.
+	 */
+	gwdt->clk = arch_timer_get_cntfrq();
+	gwdt->refresh_base = rf_base;
+	gwdt->control_base = cf_base;
+
+	wdd = &gwdt->wdd;
+	wdd->parent = dev;
+	wdd->info = &sbsa_gwdt_info;
+	wdd->ops = &sbsa_gwdt_ops;
+	watchdog_set_drvdata(wdd, gwdt);
+	watchdog_set_nowayout(wdd, nowayout);
+
+	wdd->min_timeout = 1;
+	wdd->max_timeout = U32_MAX / gwdt->clk;
+	/*
+	 * In the single stage mode, The first signal (WS0) is ignored,
+	 * the timeout is (WOR * 2), so the maximum timeout should be double.
+	 */
+	if (!action)
+		wdd->max_timeout *= 2;
+
+	wdd->timeout = DEFAULT_TIMEOUT;
+	watchdog_init_timeout(wdd, timeout, dev);
+
+	status = readl(gwdt->control_base + SBSA_GWDT_WCS);
+	if (status & SBSA_GWDT_WCS_WS1) {
+		dev_warn(dev, "System reset by WDT.\n");
+		wdd->bootstatus |= WDIOF_CARDRESET;
+	}
+
+	ret = watchdog_register_device(wdd);
+	if (ret)
+		return ret;
+
+	/*
+	 * Update timeout to WOR.
+	 * Because of the explicit watchdog refresh mechanism,
+	 * it's also a ping, if watchdog is enabled.
+	 */
+	sbsa_gwdt_set_timeout(wdd, wdd->timeout);
+
+	dev_info(dev, "Initialized with %ds timeout @ %u Hz, action=%d.%s\n",
+		 wdd->timeout, gwdt->clk, action,
+		 status & SBSA_GWDT_WCS_EN ? " [enabled]" : "");
+
+	return 0;
+}
+
+static void sbsa_gwdt_shutdown(struct platform_device *pdev)
+{
+	struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
+
+	sbsa_gwdt_stop(&gwdt->wdd);
+}
+
+static int sbsa_gwdt_remove(struct platform_device *pdev)
+{
+	struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev);
+
+	watchdog_unregister_device(&gwdt->wdd);
+
+	return 0;
+}
+
+/* Disable watchdog if it is active during suspend */
+static int __maybe_unused sbsa_gwdt_suspend(struct device *dev)
+{
+	struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
+
+	if (watchdog_active(&gwdt->wdd))
+		sbsa_gwdt_stop(&gwdt->wdd);
+
+	return 0;
+}
+
+/* Enable watchdog and configure it if necessary */
+static int __maybe_unused sbsa_gwdt_resume(struct device *dev)
+{
+	struct sbsa_gwdt *gwdt = dev_get_drvdata(dev);
+
+	if (watchdog_active(&gwdt->wdd))
+		sbsa_gwdt_start(&gwdt->wdd);
+
+	return 0;
+}
+
+static const struct dev_pm_ops sbsa_gwdt_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(sbsa_gwdt_suspend, sbsa_gwdt_resume)
+};
+
+static const struct of_device_id sbsa_gwdt_of_match[] = {
+	{ .compatible = "arm,sbsa-gwdt", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, sbsa_gwdt_of_match);
+
+static const struct platform_device_id sbsa_gwdt_pdev_match[] = {
+	{ .name = "sbsa-gwdt", },
+	{},
+};
+MODULE_DEVICE_TABLE(platform, sbsa_gwdt_pdev_match);
+
+static struct platform_driver sbsa_gwdt_driver = {
+	.driver = {
+		.name = "sbsa-gwdt",
+		.pm = &sbsa_gwdt_pm_ops,
+		.of_match_table = sbsa_gwdt_of_match,
+	},
+	.probe = sbsa_gwdt_probe,
+	.remove = sbsa_gwdt_remove,
+	.shutdown = sbsa_gwdt_shutdown,
+	.id_table = sbsa_gwdt_pdev_match,
+};
+
+module_platform_driver(sbsa_gwdt_driver);
+
+MODULE_DESCRIPTION("SBSA Generic Watchdog Driver");
+MODULE_AUTHOR("Fu Wei <fu.wei at linaro.org>");
+MODULE_AUTHOR("Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>");
+MODULE_AUTHOR("Al Stone <al.stone at linaro.org>");
+MODULE_AUTHOR("Timur Tabi <timur at codeaurora.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:sbsa-gwdt");
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 09:02:05 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 18:02:05 +0100
Subject: [PATCH v3 09/12] arm64: dts: add the Marvell Armada 3700 family
 and a development board
In-Reply-To: <20160216141627.78ec94bd@xhacker> (Jisheng Zhang's message of
 "Tue, 16 Feb 2016 14:16:27 +0800")
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
 <1454951660-13289-10-git-send-email-gregory.clement@free-electrons.com>
 <20160216141627.78ec94bd@xhacker>
Message-ID: <87egcctwqa.fsf@free-electrons.com>

Hi Jisheng,
 
 On mar., f?vr. 16 2016, Jisheng Zhang <jszhang at marvell.com> wrote:

> Dear Gregory,
> On Mon, 8 Feb 2016 18:14:17 +0100 Gregory CLEMENT wrote:
>
>> Add initial dtsi files to support Marvell Armada 3700 SoC with Cortex-A53
>> CPUs. There are two members in this family: the Armada 3710 (Single CPU)
>> and the Armada 3720 (Dual CPUs).
>> 
>> It also adds a dts file for the Marvell Armada 3720 DB board.
>> 
>> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
>> ---
>>  arch/arm64/boot/dts/marvell/Makefile           |   4 +
>>  arch/arm64/boot/dts/marvell/armada-371x.dtsi   |  53 ++++++++++
>>  arch/arm64/boot/dts/marvell/armada-3720-db.dts |  86 ++++++++++++++++
>>  arch/arm64/boot/dts/marvell/armada-372x.dtsi   |  63 ++++++++++++
>>  arch/arm64/boot/dts/marvell/armada-37xx.dtsi   | 131 +++++++++++++++++++++++++
>>  5 files changed, 337 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/marvell/armada-371x.dtsi
>>  create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-db.dts
>>  create mode 100644 arch/arm64/boot/dts/marvell/armada-372x.dtsi
>>  create mode 100644 arch/arm64/boot/dts/marvell/armada-37xx.dtsi
>> 
>> diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
>> index 348f4db4f313..2114af8d312d 100644
>> --- a/arch/arm64/boot/dts/marvell/Makefile
>> +++ b/arch/arm64/boot/dts/marvell/Makefile
>> @@ -1,6 +1,10 @@
>> +# Berlin SoC Family
>>  dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-dmp.dtb
>>  dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
>>  
>> +# Mvebu SoC Family
>> +dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
>> +
>>  always		:= $(dtb-y)
>>  subdir-y	:= $(dts-dirs)
>>  clean-files	:= *.dtb
>> diff --git a/arch/arm64/boot/dts/marvell/armada-371x.dtsi b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
>> new file mode 100644
>> index 000000000000..c9e5325b8ac3
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
>> @@ -0,0 +1,53 @@
>> +/*
>> + * Device Tree Include file for Marvell Armada 371x family of SoCs
>> + * (also named 88F3710)
>> + *
>> + * Copyright (C) 2016 Marvell
>
> Is it better to Add full Marvell company name, eg. Marvell Technology Group Ltd.
>

Well for mvebu I also saw "Marvell International Ltd." and "Marvell
Semiconductors". So at least Marvell is the common pattern.

>> + *
>> + * Gregory CLEMENT <gregory.clement at free-electrons.com>
>
> What does this mean? in copyright holder list or just author? Is it better
> to add "Author:" prefix or something else?
>
>

I don't know the subtilitis between copyright holder list and author...

> [...]
>
>> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
>> new file mode 100644
>> index 000000000000..ba9df7ff2a72
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
>> @@ -0,0 +1,131 @@
>> +/*
>> + * Device Tree Include file for Marvell Armada 37xx family of SoCs.
>> + *
>> + * Copyright (C) 2016 Marvell
>> + *
>> + * Gregory CLEMENT <gregory.clement at free-electrons.com>
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This file is free software; you can redistribute it and/or
>> + *     modify it under the terms of the GNU General Public License as
>> + *     published by the Free Software Foundation; either version 2 of the
>> + *     License, or (at your option) any later version.
>> + *
>> + *     This file is distributed in the hope that it will be useful
>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *     GNU General Public License for more details.
>> + *
>> + * Or, alternatively
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + *     obtaining a copy of this software and associated documentation
>> + *     files (the "Software"), to deal in the Software without
>> + *     restriction, including without limitation the rights to use
>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>> + *     sell copies of the Software, and to permit persons to whom the
>> + *     Software is furnished to do so, subject to the following
>> + *     conditions:
>> + *
>> + *     The above copyright notice and this permission notice shall be
>> + *     included in all copies or substantial portions of the Software.
>> + *
>> + *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + *     OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +
>> +/ {
>> +	model = "Marvell Armada 37xx SoC";
>> +	compatible = "marvell,armada3700";
>> +	interrupt-parent = <&gic>;
>> +	#address-cells = <2>;
>> +	#size-cells = <2>;
>> +
>> +	aliases {
>> +		serial0 = &uart0;
>> +	};
>> +
>> +	cpus {
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +		cpu at 0 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			reg = <0>;
>> +			enable-method = "psci";
>> +		};
>> +	};
>> +
>> +	psci {
>> +		compatible = "arm,psci-0.2";
>> +		method = "smc";
>> +	};
>> +
>> +	timer {
>> +		compatible = "arm,armv8-timer";
>> +		interrupts = <GIC_PPI 13
>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			     <GIC_PPI 14
>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			     <GIC_PPI 11
>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			     <GIC_PPI 10
>> +			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
>> +	};
>> +
>> +	soc {
>> +		compatible = "simple-bus";
>> +		#address-cells = <2>;
>> +		#size-cells = <2>;
>> +		ranges;
>> +
>> +		internal-regs {
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +			compatible = "simple-bus";
>> +			/* 32M internal register @ 0xd000_0000 */
>> +			ranges = <0x0 0x0 0xd0000000 0x2000000>;
>> +
>> +			uart0: serial at 12000 {
>> +				compatible = "marvell,armada-3700-uart";
>> +				reg = <0x12000 0x400>;
>> +				interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
>> +				status = "disabled";
>> +			};
>> +
>> +			usb3 at 58000 {
>> +				compatible = "generic-xhci";
>> +				reg = <0x58000 0x4000>;
>> +				interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
>> +				status = "disabled";
>> +			};
>> +
>> +			sata at e0000 {
>> +				compatible = "marvell,armada-3700-ahci";
>> +				reg = <0xe0000 0x2000>;
>> +				interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
>> +				status = "disabled";
>> +			};
>> +
>> +			gic: interrupt-controller at 1d00000 {
>> +				compatible = "arm,gic-v3";
>> +				#interrupt-cells = <3>;
>> +				interrupt-controller;
>> +				reg = <0x1d00000 0x10000>, /* GICD */
>> +				      <0x1d40000 0x40000>; /* GICR */
>
> There's no GICC, GICV, GICH?

As far as I know, there is only GICD and GICR.

Gregory


>
>> +			};
>> +		};
>> +	};
>> +};
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From gregory.clement at free-electrons.com  Tue Feb 16 09:03:14 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 18:03:14 +0100
Subject: [PATCH v3 05/12] arm64: add mvebu architecture entry
In-Reply-To: <20160216141212.00f037e5@xhacker> (Jisheng Zhang's message of
 "Tue, 16 Feb 2016 14:12:12 +0800")
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
 <1454951660-13289-6-git-send-email-gregory.clement@free-electrons.com>
 <20160216141212.00f037e5@xhacker>
Message-ID: <87a8n0twod.fsf@free-electrons.com>

Hi Jisheng,
 
 On mar., f?vr. 16 2016, Jisheng Zhang <jszhang at marvell.com> wrote:

> Dear Gregory,
>
> On Mon, 8 Feb 2016 18:14:13 +0100 Gregory CLEMENT wrote:
>
>> The Armada 3700 is an mvebu ARM64 SoC using one or two Cortex-A53 cores
>> depending of the variant.
>> 
>> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
>> Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>> ---
>>  arch/arm64/Kconfig.platforms | 6 ++++++
>>  1 file changed, 6 insertions(+)
>> 
>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>> index 21074f674bde..c621e69ed170 100644
>> --- a/arch/arm64/Kconfig.platforms
>> +++ b/arch/arm64/Kconfig.platforms
>> @@ -1,5 +1,11 @@
>>  menu "Platform selection"
>>  
>> +config ARCH_MVEBU
>
> it's better to keep ARCH_YYZZ sorted in alphabetic order


Yes I should have move the entry when I renamed it.

I will sent a v4 soon for this point.

Gregory

>
> Thanks,
> Jisheng
>
>> +	bool "Marvell EBU SoC Family"
>> +	help
>> +	  This enables support for Marvell EBU family such as the
>> +	  Armada 3700 SoC family.
>> +
>>  config ARCH_BCM_IPROC
>>  	bool "Broadcom iProc SoC Family"
>>  	help
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From arnd at arndb.de  Tue Feb 16 09:26:09 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 18:26:09 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <s5hr3gc60ph.wl-tiwai@suse.de>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
 <112888486.mQgaWiH0PI@wuerfel> <s5hr3gc60ph.wl-tiwai@suse.de>
Message-ID: <2706488.VpKveMVPGI@wuerfel>

On Tuesday 16 February 2016 18:10:02 Takashi Iwai wrote:
> diff --git a/include/sound/jack.h b/include/sound/jack.h
> index 23bede121c78..a27c253a3207 100644
> --- a/include/sound/jack.h
> +++ b/include/sound/jack.h
> @@ -99,6 +99,7 @@ void snd_jack_report(struct snd_jack *jack, int status);
>  static inline int snd_jack_new(struct snd_card *card, const char *id, int type,
>                                struct snd_jack **jack, bool initial_kctl, bool phantom_jack)
>  {
> +       *jack = NULL;
>         return 0;
>  }
>  
> diff --git a/sound/pci/hda/hda_jack.c b/sound/pci/hda/hda_jack.c
> index a33234e04d4f..babd3a8864a1 100644
> --- a/sound/pci/hda/hda_jack.c
> +++ b/sound/pci/hda/hda_jack.c
> @@ -403,10 +403,12 @@ int snd_hda_jack_add_kctl(struct hda_codec *codec, hda_nid_t nid,
>  
>         jack->phantom_jack = !!phantom_jack;
>         jack->type = type;
> -       jack->jack->private_data = jack;
> -       jack->jack->private_free = hda_free_jack_priv;
> -       state = snd_hda_jack_detect(codec, nid);
> -       snd_jack_report(jack->jack, state ? jack->type : 0);
> +       if (jack->jack) {
> +               jack->jack->private_data = jack;
> +               jack->jack->private_free = hda_free_jack_priv;
> +               state = snd_hda_jack_detect(codec, nid);
> +               snd_jack_report(jack->jack, state ? jack->type : 0);
> +       }
>  
>         return 0;
>  }
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index 8ee78dbd4c60..34a7b3aaba11 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -2158,8 +2158,10 @@ static int add_acomp_jack_kctl(struct hda_codec *codec,
>         if (err < 0)
>                 return err;
>         per_pin->acomp_jack = jack;
> -       jack->private_data = per_pin;
> -       jack->private_free = free_acomp_jack_priv;
> +       if (jack) {
> +               jack->private_data = per_pin;
> +               jack->private_free = free_acomp_jack_priv;
> +       }
>         return 0;
>  }
> 
Looks good to me.

Acked-by: Arnd Bergmann <arnd at arndb.de>


From robh at kernel.org  Tue Feb 16 09:28:07 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 16 Feb 2016 11:28:07 -0600
Subject: [PATCH v6sub1 02/11] of/fdt: factor out assignment of
 initrd_start/initrd_end
In-Reply-To: <1455627162-31600-3-git-send-email-ard.biesheuvel@linaro.org>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455627162-31600-3-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <CAL_JsqJEZ+O-VCAYyAbZD4LygRYKyfM4Xh+qMpx5a8-o-OX_Fw@mail.gmail.com>

On Tue, Feb 16, 2016 at 6:52 AM, Ard Biesheuvel
<ard.biesheuvel at linaro.org> wrote:
> Since architectures may not yet have their linear mapping up and running
> when the initrd address is discovered from the DT, factor out the
> assignment of initrd_start and initrd_end, so that an architecture can
> override it and use the translation it needs.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
>  drivers/of/fdt.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)

Acked-by: Rob Herring <robh at kernel.org>


From linux at arm.linux.org.uk  Tue Feb 16 09:32:26 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 16 Feb 2016 17:32:26 +0000
Subject: [PATCH v2] ARM: proc-v7.S: Adjust stack address when XIP_KERNEL
In-Reply-To: <alpine.LFD.2.20.1602011613360.32766@knanqh.ubzr>
References: <1454105474-3009-1-git-send-email-chris.brandt@renesas.com>
 <1454335736-10084-1-git-send-email-chris.brandt@renesas.com>
 <alpine.LFD.2.20.1602011613360.32766@knanqh.ubzr>
Message-ID: <20160216173225.GE19428@n2100.arm.linux.org.uk>

On Mon, Feb 01, 2016 at 04:15:38PM -0500, Nicolas Pitre wrote:
> On Mon, 1 Feb 2016, Chris Brandt wrote:
> 
> > From: Nicolas Pitre <nico at linaro.org>
> > 
> > When XIP_KERNEL is enabled, the virt to phys address translation for RAM
> > is not the same as the virt to phys address translation for .text.
> > The only way to know where physical RAM is located is to use
> > PLAT_PHYS_OFFSET.
> > The MACRO will be useful for other places where there is a similar problem.
> > 
> > Signed-off-by: Nicolas Pitre <nico at linaro.org>
> > Signed-off-by: Chris Brandt <chris.brandt at renesas.com>
> 
> Looks fine.  You may submit it here:
...
> > +#ifdef CONFIG_XIP_KERNEL
> > +#define PHYS_OFFSET_FIXUP \
> > +	( XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR) - PAGE_OFFSET + \
> > +	  PLAT_PHYS_OFFSET - CONFIG_XIP_PHYS_ADDR )
> > +#else
> > +#define PHYS_OFFSET_FIXUP 0
> > +#endif
> > +
> >  #ifndef __ASSEMBLY__
> >  
> >  /*
> > diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> > index 0f92d57..1595fb2 100644
> > --- a/arch/arm/mm/proc-v7.S
> > +++ b/arch/arm/mm/proc-v7.S
> > @@ -487,7 +487,7 @@ __errata_finish:
> >  
> >  	.align	2
> >  __v7_setup_stack_ptr:
> > -	.word	__v7_setup_stack - .
> > +	.word	__v7_setup_stack - . + PHYS_OFFSET_FIXUP

I keep looking at this patch, and I really find that I detest this
PHYS_OFFSET_FIXUP thing - it's really not obvious what's going on
here.  It's taken a _long_ time to work this out, which _really_
isn't good going forward.

Let's instead change things to make it much more obvious - see the
patch below.

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index ebdaaf7dd19f..593e5613184d 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -135,11 +135,18 @@
 #define PLAT_PHYS_OFFSET	UL(CONFIG_PHYS_OFFSET)
 
 #ifdef CONFIG_XIP_KERNEL
-#define PHYS_OFFSET_FIXUP \
-	( XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR) - PAGE_OFFSET + \
-	  PLAT_PHYS_OFFSET - CONFIG_XIP_PHYS_ADDR )
+/*
+ * When referencing data in RAM from the XIP region in a relative manner
+ * with the MMU off, we need the relative offset between the two physical
+ * addresses.  The macro below achieves this, which is:
+ *    __pa(v_data) - __xip_pa(v_text)
+ */
+#define PHYS_RELATIVE(v_data, v_text) \
+	(((v_data) - PAGE_OFFSET + PLAT_PHYS_OFFSET) - \
+	 ((v_text) - XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR) + \
+          CONFIG_XIP_PHYS_ADDR))
 #else
-#define PHYS_OFFSET_FIXUP 0
+#define PHYS_RELATIVE(v_data, v_text) (v_data) - (v_text)
 #endif
 
 #ifndef __ASSEMBLY__
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 1595fb29ec12..0f8963a7e7d9 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -487,7 +487,7 @@ __errata_finish:
 
 	.align	2
 __v7_setup_stack_ptr:
-	.word	__v7_setup_stack - . + PHYS_OFFSET_FIXUP
+	.word	PHYS_RELATIVE(__v7_setup_stack, .)
 ENDPROC(__v7_setup)
 
 	.bss


-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From jason at lakedaemon.net  Tue Feb 16 09:49:37 2016
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 16 Feb 2016 17:49:37 +0000
Subject: [PATCH v3 0/6] irqchip: irq-armada-370-xp: generic MSI
 infrastructure and assorted fixes
In-Reply-To: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20160216174937.GF5183@io.lakedaemon.net>

Hey Thomas,

On Wed, Feb 10, 2016 at 03:46:55PM +0100, Thomas Petazzoni wrote:
> This patch series converts the Armada 370/XP irqchip driver (also used
> on Armada 375, 38x and 39x) to the new MSI infrastructure put in place
> by Marc. It doesn't bring any functional difference other than using
> the right, modern, MSI mechanism, which might ultimately allow Marc to
> remove the old way of implementing MSI support.
> 
> It has been tested on Armada 38x and Armada XP with an Intel e1000e
> NIC and an Intel IGB NIC, both of which use MSI interrupts.
> 
> Note that this patch series depends on the patch series from Marc
> Zyngier for proper operation, which have already been merged in
> tip.git by Thomas Gleixner:
> 
>   http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=530cbe100ef7587aa5b5ac3a4b670cda4d50e598
>   http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=14a0db3cdd114da757197193f66786e63649c91e

When based against v4.5-rc1, I encountered:

drivers/irqchip/irq-armada-370-xp.c:584:41: error: 'DOMAIN_BUS_WIRED' undeclared (first use in this function)

Rebased the branch against v4.5-rc2 to pick up:

  530cbe100ef7 irqdomain: Allow domain lookup with DOMAIN_BUS_WIRED token

Which builds without warning.

> Thomas Petazzoni (6):
>   irqchip: irq-armada-370-xp: add Kconfig option for the driver
>   irqchip: irq-armada-370-xp: use the generic MSI infrastructure
>   irqchip: irq-armada-370-xp: use PCI_MSI_DOORBELL_START where
>     appropriate
>   irqchip: irq-armada-370-xp: use shorter names for irq_chip
>   irqchip: irq-armada-370-xp: allow allocation of multiple MSIs
>   ARM: mvebu: use the ARMADA_370_XP_IRQ option
> 
>  arch/arm/mach-mvebu/Kconfig         |   6 +-
>  drivers/irqchip/Kconfig             |   6 ++
>  drivers/irqchip/Makefile            |   2 +-
>  drivers/irqchip/irq-armada-370-xp.c | 156 +++++++++++++++---------------------
>  4 files changed, 78 insertions(+), 92 deletions(-)

Whole series applied to irqchip/mvebu which will not be rebased.  I'll
only append to it if you send me a patch to add.  ;-)

thx,

Jason.


From stefan at agner.ch  Tue Feb 16 09:50:08 2016
From: stefan at agner.ch (Stefan Agner)
Date: Tue, 16 Feb 2016 09:50:08 -0800
Subject: [PATCH v3 3/3] ARM: dts: vfxxx: Add iio_hwmon node for ADC
 temperature channel
In-Reply-To: <88b677c3ab62d965b70846618fe566523f95c9bb.1455597464.git.maitysanchayan@gmail.com>
References: <cover.1455597464.git.maitysanchayan@gmail.com>
 <88b677c3ab62d965b70846618fe566523f95c9bb.1455597464.git.maitysanchayan@gmail.com>
Message-ID: <06aa0e2a7958c81fb6d3ab9c23164156@agner.ch>

On 2016-02-15 21:00, Sanchayan Maity wrote:
> Add iio-hwmon node to expose the temperature channel on Vybrid as
> hardware monitor device using the iio_hwmon driver.
> 
> Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>

Acked-by: Stefan Agner <stefan at agner.ch>

> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index a5f07e3..24ac5b1 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -673,5 +673,10 @@
>  				status = "disabled";
>  			};
>  		};
> +
> +		iio-hwmon {
> +			compatible = "iio-hwmon";
> +			io-channels = <&adc0 16>, <&adc1 16>;
> +		};
>  	};
>  };


From daniel.baluta at intel.com  Tue Feb 16 10:03:29 2016
From: daniel.baluta at intel.com (Daniel Baluta)
Date: Tue, 16 Feb 2016 20:03:29 +0200
Subject: [PATCH] iio: pressure: ms5611: select IIO_BUFFER
In-Reply-To: <1455634525-2023774-1-git-send-email-arnd@arndb.de>
References: <1455634525-2023774-1-git-send-email-arnd@arndb.de>
Message-ID: <CAEnQRZBk0R-A5VEEd_D+kLKnyhc3nhrm0tv2JOkv0iqywGFtuw@mail.gmail.com>

On Tue, Feb 16, 2016 at 4:55 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> The ms5611 driver started using the IIO_TRIGGERED_BUFFER infrastructure
> which in turn depend on IIO_BUFFER, and it produces a build error now
> if that is not enabled:
>
> warning: (... && MS5611 && ...) selects IIO_TRIGGERED_BUFFER which has unmet direct dependencies (IIO && IIO_BUFFER)
> buffer/industrialio-triggered-buffer.c: In function 'iio_triggered_buffer_setup':
> buffer/industrialio-triggered-buffer.c:58:2: error: implicit declaration of function 'iio_device_attach_buffer' [-Werror=implicit-function-declaration]
> pressure/ms5611_core.c: In function 'ms5611_trigger_handler':
> pressure/ms5611_core.c:193:2: error: implicit declaration of function 'iio_push_to_buffers_with_timestamp' [-Werror=implicit-function-declaration]
>
> This adds the second select.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 713bbb4efb9d ("iio: pressure: ms5611: Add triggered buffer support")

Acked-by: Daniel Baluta <daniel.baluta at intel.com>

> ---
>  drivers/iio/pressure/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iio/pressure/Kconfig b/drivers/iio/pressure/Kconfig
> index f15f66d6f527..31c0e1fd2202 100644
> --- a/drivers/iio/pressure/Kconfig
> +++ b/drivers/iio/pressure/Kconfig
> @@ -69,6 +69,7 @@ config MPL3115
>
>  config MS5611
>         tristate "Measurement Specialties MS5611 pressure sensor driver"
> +       select IIO_BUFFER
>         select IIO_TRIGGERED_BUFFER
>         help
>           Say Y here to build support for the Measurement Specialties
> --
> 2.7.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From keescook at chromium.org  Tue Feb 16 10:10:01 2016
From: keescook at chromium.org (Kees Cook)
Date: Tue, 16 Feb 2016 10:10:01 -0800
Subject: [PATCH] arm64: mm: Mark .rodata as RO
In-Reply-To: <20160212182527.GG20262@leverpostej>
References: <1455293599-6974-1-git-send-email-jeremy.linton@arm.com>
 <20160212182527.GG20262@leverpostej>
Message-ID: <CAGXu5jLpj=ue49_N+LOYvtZcU3rpFR5=WTG15ySDOWprvRzFUA@mail.gmail.com>

On Fri, Feb 12, 2016 at 10:25 AM, Mark Rutland <mark.rutland at arm.com> wrote:
> On Fri, Feb 12, 2016 at 10:13:19AM -0600, Jeremy Linton wrote:
>> Currently the .rodata section is actually still executable when DEBUG_RODATA
>> is enabled. This changes that so the .rodata is actually read only, no execute.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>

Yikes, good catch. Is anyone running the lkdtm tests that check these things?

Reviewed-by: Kees Cook <keescook at chromium.org>

>> ---
>>  arch/arm64/kernel/vmlinux.lds.S |  5 +++--
>>  arch/arm64/mm/mmu.c             | 14 +++++++++++---
>>  2 files changed, 14 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
>> index ab4e436..2e2c053 100644
>> --- a/arch/arm64/kernel/vmlinux.lds.S
>> +++ b/arch/arm64/kernel/vmlinux.lds.S
>> @@ -114,8 +114,9 @@ SECTIONS
>>               *(.got)                 /* Global offset table          */
>>       }
>>
>> -     RO_DATA(PAGE_SIZE)
>> -     EXCEPTION_TABLE(8)
>> +     ALIGN_DEBUG_RO_MIN(0)
>> +     RO_DATA(PAGE_SIZE)              /* everything from this point to */
>> +     EXCEPTION_TABLE(8)              /* _etext will be marked RO NX   */
>>       NOTES
>>
>>       ALIGN_DEBUG_RO_MIN(PAGE_SIZE)
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index ab69a99..a3f4112 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -453,10 +453,18 @@ static void __init map_mem(pgd_t *pgd)
>>  #ifdef CONFIG_DEBUG_RODATA
>>  void mark_rodata_ro(void)
>>  {
>> -     create_mapping_late(__pa(_stext), (unsigned long)_stext,
>> -                             (unsigned long)_etext - (unsigned long)_stext,
>> -                             PAGE_KERNEL_ROX);
>> +     unsigned long section_size;
>>
>> +     section_size = (unsigned long)__start_rodata - (unsigned long)_stext;
>> +     create_mapping_late(__pa(_stext), (unsigned long)_stext,
>> +                         section_size, PAGE_KERNEL_ROX);
>> +     /*
>> +      * mark .rodata as read only. Use _etext rather than __end_rodata to
>> +      * cover NOTES and EXCEPTION_TABLE.
>> +      */
>> +     section_size = (unsigned long)_etext - (unsigned long)__start_rodata;
>> +     create_mapping_late(__pa(__start_rodata), (unsigned long)__start_rodata,
>> +                         section_size, PAGE_KERNEL_RO);
>>  }
>
> As you pointed out in the other thread, we'll also need to update
> map_kernel to use equivalent chunks for .text and .rodata.
>
> I think we can probably make .rodata RO from the outset in map_kernel,
> too.

There's a benefit to marking it late in that .rodata can live in the
same (upcoming) section as .data..ro_after_init, which is marked ro
after mark_rodata_ro() to help constify more things.

> Could you please update mem_init to log .text and .rodata separately?
>
> It looks like some core code makes assumptions about _etext, so I guess
> that has to cover .rodata regardless.
>
> Otherwise, looks good!
>
> Thanks,
> Mark.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security


From eric at anholt.net  Tue Feb 16 10:10:59 2016
From: eric at anholt.net (Eric Anholt)
Date: Tue, 16 Feb 2016 10:10:59 -0800
Subject: [PATCH v5 01/13] mmc: sdhci-bcm2835: use sdhci_pltfm_init for
 private allocation
In-Reply-To: <1455628111-5583-2-git-send-email-jszhang@marvell.com>
References: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
 <1455628111-5583-2-git-send-email-jszhang@marvell.com>
Message-ID: <87y4ak4jbg.fsf@eliezer.anholt.net>

Jisheng Zhang <jszhang at marvell.com> writes:

> Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
> allows users of sdhci_pltfm to allocate private space in calls to
> sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates sdhci-bcm2835
> to this allocation.
>
> Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> Acked-by: Adrian Hunter <adrian.hunter at intel.com>

Acked-by: Eric Anholt <eric at anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160216/ecf41af5/attachment.sig>

From mark.rutland at arm.com  Tue Feb 16 10:15:17 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 16 Feb 2016 18:15:17 +0000
Subject: [PATCHv3] arm64: Rework valid_user_regs
Message-ID: <1455646517-22903-1-git-send-email-mark.rutland@arm.com>

We validate pstate using PSR_MODE32_BIT, which is part of the
user-provided pstate (and cannot be trusted). Also, we conflate
validation of AArch32 and AArch64 pstate values, making the code
difficult to reason about.

Instead, validate the pstate value based on the associated task. The
task may or may not be current (e.g. when using ptrace), so this must be
passed explicitly by callers. To avoid circular header dependencies via
sched.h, is_compat_task is pulled out of asm/ptrace.h.

To make the code possible to reason about, the AArch64 and AArch32
validation is split into separate functions. Software must respect the
RES0 policy for SPSR bits, and thus the kernel mirrors the hardware
policy (RAZ/WI) for bits as-yet unallocated. When these acquire an
architected meaning writes may be permitted (potentially with additional
validation).

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Dave Martin <dave.martin at arm.com>
Cc: James Morse <james.morse at arm.com>
Cc: Peter Maydell <peter.maydell at linaro.org>
Cc: Will Deacon <will.deacon at arm.com>
---
 arch/arm64/include/asm/ptrace.h | 33 +++---------------
 arch/arm64/kernel/ptrace.c      | 77 +++++++++++++++++++++++++++++++++++++++--
 arch/arm64/kernel/signal.c      |  4 +--
 arch/arm64/kernel/signal32.c    |  2 +-
 4 files changed, 82 insertions(+), 34 deletions(-)

Since v1 [1]:
* Clear the full complement of RES0 bits
* Treat IL as RES0
* Treat SS as RES0 when not tracing
* renames: s/aa64/native, s/aa32/compat/

Since v2 [2]:
* Kill PSR_{f,s,x} and refer to fields explicitly
* Add COMPAT_PSR_GE_MASK

Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/406424.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/407386.html

diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index e9e5467..a307eb6 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -58,6 +58,7 @@
 #define COMPAT_PSR_Z_BIT	0x40000000
 #define COMPAT_PSR_N_BIT	0x80000000
 #define COMPAT_PSR_IT_MASK	0x0600fc00	/* If-Then execution state mask */
+#define COMPAT_PSR_GE_MASK	0x000f0000
 
 #ifdef CONFIG_CPU_BIG_ENDIAN
 #define COMPAT_PSR_ENDSTATE	COMPAT_PSR_E_BIT
@@ -151,35 +152,9 @@ static inline unsigned long regs_return_value(struct pt_regs *regs)
 	return regs->regs[0];
 }
 
-/*
- * Are the current registers suitable for user mode? (used to maintain
- * security in signal handlers)
- */
-static inline int valid_user_regs(struct user_pt_regs *regs)
-{
-	if (user_mode(regs) && (regs->pstate & PSR_I_BIT) == 0) {
-		regs->pstate &= ~(PSR_F_BIT | PSR_A_BIT);
-
-		/* The T bit is reserved for AArch64 */
-		if (!(regs->pstate & PSR_MODE32_BIT))
-			regs->pstate &= ~COMPAT_PSR_T_BIT;
-
-		return 1;
-	}
-
-	/*
-	 * Force PSR to something logical...
-	 */
-	regs->pstate &= PSR_f | PSR_s | (PSR_x & ~PSR_A_BIT) | \
-			COMPAT_PSR_T_BIT | PSR_MODE32_BIT;
-
-	if (!(regs->pstate & PSR_MODE32_BIT)) {
-		regs->pstate &= ~COMPAT_PSR_T_BIT;
-		regs->pstate |= PSR_MODE_EL0t;
-	}
-
-	return 0;
-}
+/* We must avoid circular header include via sched.h */
+struct task_struct;
+int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task);
 
 #define instruction_pointer(regs)	((unsigned long)(regs)->pc)
 
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index ff7f132..5026ffb 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -500,7 +500,7 @@ static int gpr_set(struct task_struct *target, const struct user_regset *regset,
 	if (ret)
 		return ret;
 
-	if (!valid_user_regs(&newregs))
+	if (!valid_user_regs(&newregs, target))
 		return -EINVAL;
 
 	task_pt_regs(target)->user_regs = newregs;
@@ -770,7 +770,7 @@ static int compat_gpr_set(struct task_struct *target,
 
 	}
 
-	if (valid_user_regs(&newregs.user_regs))
+	if (valid_user_regs(&newregs.user_regs, target))
 		*task_pt_regs(target) = newregs;
 	else
 		ret = -EINVAL;
@@ -1272,3 +1272,76 @@ asmlinkage void syscall_trace_exit(struct pt_regs *regs)
 	if (test_thread_flag(TIF_SYSCALL_TRACE))
 		tracehook_report_syscall(regs, PTRACE_SYSCALL_EXIT);
 }
+
+/*
+ * Bits which are always architecturally RES0 per ARM DDI 0487A.h
+ * Userspace cannot use these until they have an architectural meaning.
+ * We also reserve IL for the kernel; SS is handled dynamically.
+ */
+#define SPSR_EL1_AARCH64_RES0_BITS \
+	(GENMASK_ULL(63,32) | GENMASK_ULL(27, 22) | GENMASK_ULL(20, 10) | \
+	 GENMASK_ULL(5, 5))
+#define SPSR_EL1_AARCH32_RES0_BITS \
+	(GENMASK_ULL(63,32) | GENMASK_ULL(24, 22) | GENMASK_ULL(20,20))
+
+static int valid_compat_regs(struct user_pt_regs *regs)
+{
+	regs->pstate &= ~SPSR_EL1_AARCH32_RES0_BITS;
+
+	if (!system_supports_mixed_endian_el0()) {
+		if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
+			regs->pstate |= COMPAT_PSR_E_BIT;
+		else
+			regs->pstate &= ~COMPAT_PSR_E_BIT;
+	}
+
+	if (user_mode(regs) && (regs->pstate & PSR_MODE32_BIT) &&
+	    (regs->pstate & COMPAT_PSR_A_BIT) == 0 &&
+	    (regs->pstate & COMPAT_PSR_I_BIT) == 0 &&
+	    (regs->pstate & COMPAT_PSR_F_BIT) == 0) {
+		return 1;
+	}
+
+	/* Force PSR to a valid 32-bit EL0t */
+	regs->pstate &= COMPAT_PSR_N_BIT | COMPAT_PSR_Z_BIT |
+			COMPAT_PSR_C_BIT | COMPAT_PSR_V_BIT |
+			COMPAT_PSR_Q_BIT | COMPAT_PSR_IT_MASK |
+			COMPAT_PSR_GE_MASK | COMPAT_PSR_E_BIT |
+			COMPAT_PSR_T_BIT;
+	regs->pstate |= PSR_MODE32_BIT;
+
+	return 0;
+}
+
+static int valid_native_regs(struct user_pt_regs *regs)
+{
+	regs->pstate &= ~SPSR_EL1_AARCH64_RES0_BITS;
+
+	if (user_mode(regs) && !(regs->pstate & PSR_MODE32_BIT) &&
+	    (regs->pstate & PSR_D_BIT) == 0 &&
+	    (regs->pstate & PSR_A_BIT) == 0 &&
+	    (regs->pstate & PSR_I_BIT) == 0 &&
+	    (regs->pstate & PSR_F_BIT) == 0) {
+		return 1;
+	}
+
+	/* Force PSR to a valid 64-bit EL0t */
+	regs->pstate &= PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;
+
+	return 0;
+}
+
+/*
+ * Are the current registers suitable for user mode? (used to maintain
+ * security in signal handlers)
+ */
+int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
+{
+	if (!test_tsk_thread_flag(task, TIF_SINGLESTEP))
+		regs->pstate &= ~DBG_SPSR_SS;
+
+	if (is_compat_thread(task_thread_info(task)))
+		return valid_compat_regs(regs);
+	else
+		return valid_native_regs(regs);
+}
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index e18c48c..a8eafdb 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -115,7 +115,7 @@ static int restore_sigframe(struct pt_regs *regs,
 	 */
 	regs->syscallno = ~0UL;
 
-	err |= !valid_user_regs(&regs->user_regs);
+	err |= !valid_user_regs(&regs->user_regs, current);
 
 	if (err == 0) {
 		struct fpsimd_context *fpsimd_ctx =
@@ -307,7 +307,7 @@ static void handle_signal(struct ksignal *ksig, struct pt_regs *regs)
 	/*
 	 * Check that the resulting registers are actually sane.
 	 */
-	ret |= !valid_user_regs(&regs->user_regs);
+	ret |= !valid_user_regs(&regs->user_regs, current);
 
 	/*
 	 * Fast forward the stepping logic so we step into the signal
diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index 71ef6dc..1073356 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -356,7 +356,7 @@ static int compat_restore_sigframe(struct pt_regs *regs,
 	 */
 	regs->syscallno = ~0UL;
 
-	err |= !valid_user_regs(&regs->user_regs);
+	err |= !valid_user_regs(&regs->user_regs, current);
 
 	aux = (struct compat_aux_sigframe __user *) sf->uc.uc_regspace;
 	if (err == 0)
-- 
1.9.1



From jason at lakedaemon.net  Tue Feb 16 10:16:58 2016
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 16 Feb 2016 18:16:58 +0000
Subject: [PATCH v3 02/12] irqchip: armada-370-xp: do not enable it by
 default when ARCH_MVEBU is selected
In-Reply-To: <1454951660-13289-3-git-send-email-gregory.clement@free-electrons.com>
References: <1454951660-13289-1-git-send-email-gregory.clement@free-electrons.com>
 <1454951660-13289-3-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160216181658.GH5183@io.lakedaemon.net>

Hey Gregory,

On Mon, Feb 08, 2016 at 06:14:10PM +0100, Gregory CLEMENT wrote:
> The irq-armada-370-xp driver can only be built for ARM 32 bits. The mvebu
> family had grown with a new ARM64 SoC which will also select the
> ARCH_MEVBU configuration. Since "ARM: mvebu: use the ARMADA_370_XP_IRQ
> option", the ARM32 mvebu SoC directly select this new option. Selecting
> it by default when ARCH_MEVBU is selected is no more needed.
> 
> This patch removes this dependency, thanks to this, a kernel for ARM64
> mvebu SoC can be built without error due this driver.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> ---
>  drivers/irqchip/Kconfig | 1 -
>  1 file changed, 1 deletion(-)

Applied to irqchip/mvebu

thx,

Jason.


From will.deacon at arm.com  Tue Feb 16 10:20:05 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 16 Feb 2016 18:20:05 +0000
Subject: [PATCHv3] arm64: Rework valid_user_regs
In-Reply-To: <1455646517-22903-1-git-send-email-mark.rutland@arm.com>
References: <1455646517-22903-1-git-send-email-mark.rutland@arm.com>
Message-ID: <20160216182005.GN14509@arm.com>

On Tue, Feb 16, 2016 at 06:15:17PM +0000, Mark Rutland wrote:
> We validate pstate using PSR_MODE32_BIT, which is part of the
> user-provided pstate (and cannot be trusted). Also, we conflate
> validation of AArch32 and AArch64 pstate values, making the code
> difficult to reason about.
> 
> Instead, validate the pstate value based on the associated task. The
> task may or may not be current (e.g. when using ptrace), so this must be
> passed explicitly by callers. To avoid circular header dependencies via
> sched.h, is_compat_task is pulled out of asm/ptrace.h.
> 
> To make the code possible to reason about, the AArch64 and AArch32
> validation is split into separate functions. Software must respect the
> RES0 policy for SPSR bits, and thus the kernel mirrors the hardware
> policy (RAZ/WI) for bits as-yet unallocated. When these acquire an
> architected meaning writes may be permitted (potentially with additional
> validation).
> 
> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> Cc: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Dave Martin <dave.martin at arm.com>
> Cc: James Morse <james.morse at arm.com>
> Cc: Peter Maydell <peter.maydell at linaro.org>
> Cc: Will Deacon <will.deacon at arm.com>
> ---
>  arch/arm64/include/asm/ptrace.h | 33 +++---------------
>  arch/arm64/kernel/ptrace.c      | 77 +++++++++++++++++++++++++++++++++++++++--
>  arch/arm64/kernel/signal.c      |  4 +--
>  arch/arm64/kernel/signal32.c    |  2 +-
>  4 files changed, 82 insertions(+), 34 deletions(-)

[...]

> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index ff7f132..5026ffb 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -500,7 +500,7 @@ static int gpr_set(struct task_struct *target, const struct user_regset *regset,
>  	if (ret)
>  		return ret;
>  
> -	if (!valid_user_regs(&newregs))
> +	if (!valid_user_regs(&newregs, target))
>  		return -EINVAL;
>  
>  	task_pt_regs(target)->user_regs = newregs;
> @@ -770,7 +770,7 @@ static int compat_gpr_set(struct task_struct *target,
>  
>  	}
>  
> -	if (valid_user_regs(&newregs.user_regs))
> +	if (valid_user_regs(&newregs.user_regs, target))
>  		*task_pt_regs(target) = newregs;
>  	else
>  		ret = -EINVAL;
> @@ -1272,3 +1272,76 @@ asmlinkage void syscall_trace_exit(struct pt_regs *regs)
>  	if (test_thread_flag(TIF_SYSCALL_TRACE))
>  		tracehook_report_syscall(regs, PTRACE_SYSCALL_EXIT);
>  }
> +
> +/*
> + * Bits which are always architecturally RES0 per ARM DDI 0487A.h
> + * Userspace cannot use these until they have an architectural meaning.
> + * We also reserve IL for the kernel; SS is handled dynamically.
> + */
> +#define SPSR_EL1_AARCH64_RES0_BITS \
> +	(GENMASK_ULL(63,32) | GENMASK_ULL(27, 22) | GENMASK_ULL(20, 10) | \
> +	 GENMASK_ULL(5, 5))
> +#define SPSR_EL1_AARCH32_RES0_BITS \
> +	(GENMASK_ULL(63,32) | GENMASK_ULL(24, 22) | GENMASK_ULL(20,20))
> +
> +static int valid_compat_regs(struct user_pt_regs *regs)
> +{
> +	regs->pstate &= ~SPSR_EL1_AARCH32_RES0_BITS;
> +
> +	if (!system_supports_mixed_endian_el0()) {
> +		if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
> +			regs->pstate |= COMPAT_PSR_E_BIT;
> +		else
> +			regs->pstate &= ~COMPAT_PSR_E_BIT;
> +	}
> +
> +	if (user_mode(regs) && (regs->pstate & PSR_MODE32_BIT) &&
> +	    (regs->pstate & COMPAT_PSR_A_BIT) == 0 &&
> +	    (regs->pstate & COMPAT_PSR_I_BIT) == 0 &&
> +	    (regs->pstate & COMPAT_PSR_F_BIT) == 0) {
> +		return 1;
> +	}
> +
> +	/* Force PSR to a valid 32-bit EL0t */
> +	regs->pstate &= COMPAT_PSR_N_BIT | COMPAT_PSR_Z_BIT |
> +			COMPAT_PSR_C_BIT | COMPAT_PSR_V_BIT |
> +			COMPAT_PSR_Q_BIT | COMPAT_PSR_IT_MASK |
> +			COMPAT_PSR_GE_MASK | COMPAT_PSR_E_BIT |
> +			COMPAT_PSR_T_BIT;
> +	regs->pstate |= PSR_MODE32_BIT;

Might be worth an explicit comment to say that we're mirroring arch/arm/
behaviour here.

> +
> +	return 0;
> +}
> +
> +static int valid_native_regs(struct user_pt_regs *regs)
> +{
> +	regs->pstate &= ~SPSR_EL1_AARCH64_RES0_BITS;
> +
> +	if (user_mode(regs) && !(regs->pstate & PSR_MODE32_BIT) &&
> +	    (regs->pstate & PSR_D_BIT) == 0 &&
> +	    (regs->pstate & PSR_A_BIT) == 0 &&
> +	    (regs->pstate & PSR_I_BIT) == 0 &&
> +	    (regs->pstate & PSR_F_BIT) == 0) {
> +		return 1;
> +	}
> +
> +	/* Force PSR to a valid 64-bit EL0t */
> +	regs->pstate &= PSR_N_BIT | PSR_Z_BIT | PSR_C_BIT | PSR_V_BIT;

Can we not just zap the pstate to PSR_MODE_EL0t and be done with it?

Will


From catalin.marinas at arm.com  Tue Feb 16 10:22:35 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 16 Feb 2016 18:22:35 +0000
Subject: [PATCH] arm64: vdso: Mark vDSO code as read-only
In-Reply-To: <1455141142-6838-1-git-send-email-david.brown@linaro.org>
References: <1455141142-6838-1-git-send-email-david.brown@linaro.org>
Message-ID: <20160216182235.GE19413@e104818-lin.cambridge.arm.com>

On Wed, Feb 10, 2016 at 01:52:22PM -0800, David Brown wrote:
> diff --git a/arch/arm64/kernel/vdso/vdso.S b/arch/arm64/kernel/vdso/vdso.S
> index 60c1db5..db7c0f2 100644
> --- a/arch/arm64/kernel/vdso/vdso.S
> +++ b/arch/arm64/kernel/vdso/vdso.S
> @@ -24,6 +24,7 @@
>  	__PAGE_ALIGNED_DATA
>  
>  	.globl vdso_start, vdso_end
> +	.section .rodata
>  	.balign PAGE_SIZE
>  vdso_start:
>  	.incbin "arch/arm64/kernel/vdso/vdso.so"
> -- 
> 2.7.1

Patch applied (and removed __PAGE_ALIGNED_DATA as well). Thanks.

-- 
Catalin


From gregory.clement at free-electrons.com  Tue Feb 16 10:14:52 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 19:14:52 +0100
Subject: [PATCH v4 02/12] irqchip: armada-370-xp: do not enable it by default
 when ARCH_MVEBU is selected
In-Reply-To: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455646502-23834-3-git-send-email-gregory.clement@free-electrons.com>

The irq-armada-370-xp driver can only be built for ARM 32 bits. The mvebu
family had grown with a new ARM64 SoC which will also select the
ARCH_MEVBU configuration. Since "ARM: mvebu: use the ARMADA_370_XP_IRQ
option", the ARM32 mvebu SoC directly select this new option. Selecting
it by default when ARCH_MEVBU is selected is no more needed.

This patch removes this dependency, thanks to this, a kernel for ARM64
mvebu SoC can be built without error due this driver.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/irqchip/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index e2cab879d641..b6e7e86a57e1 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -62,7 +62,6 @@ config ARM_VIC_NR
 
 config ARMADA_370_XP_IRQ
 	bool
-	default y if ARCH_MVEBU
 	select GENERIC_IRQ_CHIP
 
 config ATMEL_AIC_IRQ
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 10:14:54 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 19:14:54 +0100
Subject: [PATCH v4 04/12] ata: ahci_mvebu: add support for Armada 3700 variant
In-Reply-To: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455646502-23834-5-git-send-email-gregory.clement@free-electrons.com>

From: Lior Amsalem <alior at marvell.com>

The main difference in the new Armada 3700 is that no address
decoding needs to take place in the driver probe.

[gregory.clement at free-electrons.com: reformulate the commit log]

Signed-off-by: Lior Amsalem <alior at marvell.com>
Reviewed-by: Nadav Haklai <nadavh at marvell.com>
Tested-by: Nadav Haklai <nadavh at marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 drivers/ata/ahci_mvebu.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/ata/ahci_mvebu.c b/drivers/ata/ahci_mvebu.c
index f7a7fa81740e..de7128d81e9c 100644
--- a/drivers/ata/ahci_mvebu.c
+++ b/drivers/ata/ahci_mvebu.c
@@ -112,12 +112,15 @@ static int ahci_mvebu_probe(struct platform_device *pdev)
 	if (rc)
 		return rc;
 
-	dram = mv_mbus_dram_info();
-	if (!dram)
-		return -ENODEV;
+	if (of_device_is_compatible(pdev->dev.of_node,
+				    "marvell,armada-380-ahci")) {
+		dram = mv_mbus_dram_info();
+		if (!dram)
+			return -ENODEV;
 
-	ahci_mvebu_mbus_config(hpriv, dram);
-	ahci_mvebu_regret_option(hpriv);
+		ahci_mvebu_mbus_config(hpriv, dram);
+		ahci_mvebu_regret_option(hpriv);
+	}
 
 	rc = ahci_platform_init_host(pdev, hpriv, &ahci_mvebu_port_info,
 				     &ahci_platform_sht);
@@ -133,6 +136,7 @@ disable_resources:
 
 static const struct of_device_id ahci_mvebu_of_match[] = {
 	{ .compatible = "marvell,armada-380-ahci", },
+	{ .compatible = "marvell,armada-3700-ahci", },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, ahci_mvebu_of_match);
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 10:14:51 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 19:14:51 +0100
Subject: [PATCH v4 01/12] irqchip: armada-370-xp: add Kconfig option for the
 driver
In-Reply-To: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455646502-23834-2-git-send-email-gregory.clement@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Instead of building the irq-armada-370-xp driver directly when
CONFIG_ARCH_MVEBU is enabled, this commit introduces an intermediate
CONFIG_ARMADA_370_XP_IRQ hidden Kconfig option.

This allows this option to select other interrupt-related Kconfig
options (which will be needed in follow-up commits) rather than having
such selects done from arch/arm/mach-<foo>/.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/irqchip/Kconfig  | 5 +++++
 drivers/irqchip/Makefile | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 715923d5236c..e2cab879d641 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -60,6 +60,11 @@ config ARM_VIC_NR
 	  The maximum number of VICs available in the system, for
 	  power management.
 
+config ARMADA_370_XP_IRQ
+	bool
+	default y if ARCH_MVEBU
+	select GENERIC_IRQ_CHIP
+
 config ATMEL_AIC_IRQ
 	bool
 	select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 18caacb60d58..30dba044d0b8 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -5,7 +5,6 @@ obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2836.o
 obj-$(CONFIG_ARCH_EXYNOS)		+= exynos-combiner.o
 obj-$(CONFIG_ARCH_HIP04)		+= irq-hip04.o
 obj-$(CONFIG_ARCH_MMP)			+= irq-mmp.o
-obj-$(CONFIG_ARCH_MVEBU)		+= irq-armada-370-xp.o
 obj-$(CONFIG_IRQ_MXS)			+= irq-mxs.o
 obj-$(CONFIG_ARCH_TEGRA)		+= irq-tegra.o
 obj-$(CONFIG_ARCH_S3C24XX)		+= irq-s3c24xx.o
@@ -28,6 +27,7 @@ obj-$(CONFIG_ARM_GIC_V3_ITS)		+= irq-gic-v3-its.o irq-gic-v3-its-pci-msi.o irq-g
 obj-$(CONFIG_HISILICON_IRQ_MBIGEN)	+= irq-mbigen.o
 obj-$(CONFIG_ARM_NVIC)			+= irq-nvic.o
 obj-$(CONFIG_ARM_VIC)			+= irq-vic.o
+obj-$(CONFIG_ARMADA_370_XP_IRQ)		+= irq-armada-370-xp.o
 obj-$(CONFIG_ATMEL_AIC_IRQ)		+= irq-atmel-aic-common.o irq-atmel-aic.o
 obj-$(CONFIG_ATMEL_AIC5_IRQ)	+= irq-atmel-aic-common.o irq-atmel-aic5.o
 obj-$(CONFIG_I8259)			+= irq-i8259.o
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 10:14:53 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 19:14:53 +0100
Subject: [PATCH v4 03/12] serial: mvebu-uart: initial support for Armada-3700
 serial port
In-Reply-To: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455646502-23834-4-git-send-email-gregory.clement@free-electrons.com>

From: Wilson Ding <dingwei at marvell.com>

Armada-3700's uart is a simple serial port, which doesn't
support. Configuring the modem control lines. The uart port has a 32
bytes Tx FIFO and a 64 bytes Rx FIFO

The uart driver implements the uart core operations. It also support the
system (early) console based on Armada-3700's serial port.

Known Issue:

The uart driver currently doesn't support clock programming, which means
the baud-rate stays with the default value configured by the bootloader
at boot time

[gregory.clement at free-electrons.com: Rewrite many part which are too long
to enumerate]

Signed-off-by: Wilson Ding <dingwei at marvell.com>
Signed-off-by: Nadav Haklai <nadavh at marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/tty/serial/mvebu-uart.txt  |  13 +
 Documentation/kernel-parameters.txt                |   6 +
 drivers/tty/serial/Kconfig                         |  22 +
 drivers/tty/serial/Makefile                        |   1 +
 drivers/tty/serial/mvebu-uart.c                    | 650 +++++++++++++++++++++
 include/uapi/linux/serial_core.h                   |   3 +
 6 files changed, 695 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
 create mode 100644 drivers/tty/serial/mvebu-uart.c

diff --git a/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
new file mode 100644
index 000000000000..6087defd9f93
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
@@ -0,0 +1,13 @@
+* Marvell UART : Non standard UART used in some of Marvell EBU SoCs (e.g., Armada-3700)
+
+Required properties:
+- compatible: "marvell,armada-3700-uart"
+- reg: offset and length of the register set for the device.
+- interrupts: device interrupt
+
+Example:
+	serial at 12000 {
+		compatible = "marvell,armada-3700-uart";
+		reg = <0x12000 0x400>;
+		interrupts = <43>;
+	};
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 87d40a72f6a1..ea0aba48d616 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1058,6 +1058,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			A valid base address must be provided, and the serial
 			port must already be setup and configured.
 
+		armada3700_uart,<addr>
+			Start an early, polled-mode console on the
+			Armada 3700 serial port at the specified
+			address. The serial port must already be setup
+			and configured. Options are not yet supported.
+
 	earlyprintk=	[X86,SH,BLACKFIN,ARM,M68k]
 			earlyprintk=vga
 			earlyprintk=efi
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 39721ec4f415..b291f934d51b 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1606,6 +1606,28 @@ config SERIAL_STM32_CONSOLE
 	depends on SERIAL_STM32=y
 	select SERIAL_CORE_CONSOLE
 
+config SERIAL_MVEBU_UART
+	bool "Marvell EBU serial port support"
+	select SERIAL_CORE
+	help
+	  This driver is for Marvell EBU SoC's UART. If you have a machine
+	  based on the Armada-3700 SoC and wish to use the on-board serial
+	  port,
+	  say 'Y' here.
+	  Otherwise, say 'N'.
+
+config SERIAL_MVEBU_CONSOLE
+	bool "Console on Marvell EBU serial port"
+	depends on SERIAL_MVEBU_UART
+	select SERIAL_CORE_CONSOLE
+	select SERIAL_EARLYCON
+	default y
+	help
+	  Say 'Y' here if you wish to use Armada-3700 UART as the system console.
+	  (the system console is the device which receives all kernel messages
+	  and warnings and which allows logins in single user mode)
+	  Otherwise, say 'N'.
+
 endmenu
 
 config SERIAL_MCTRL_GPIO
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index b391c9b31960..988167595330 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
 obj-$(CONFIG_SERIAL_MEN_Z135)	+= men_z135_uart.o
 obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
 obj-$(CONFIG_SERIAL_STM32)	+= stm32-usart.o
+obj-$(CONFIG_SERIAL_MVEBU_UART)	+= mvebu-uart.o
 
 # GPIOLIB helpers for modem control lines
 obj-$(CONFIG_SERIAL_MCTRL_GPIO)	+= serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
new file mode 100644
index 000000000000..0ff27818bb87
--- /dev/null
+++ b/drivers/tty/serial/mvebu-uart.c
@@ -0,0 +1,650 @@
+/*
+* ***************************************************************************
+* Copyright (C) 2015 Marvell International Ltd.
+* ***************************************************************************
+* This program is free software: you can redistribute it and/or modify it
+* under the terms of the GNU General Public License as published by the Free
+* Software Foundation, either version 2 of the License, or any later version.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+* GNU General Public License for more details.
+*
+* 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/clk.h>
+#include <linux/console.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/slab.h>
+#include <linux/tty.h>
+#include <linux/tty_flip.h>
+
+/* Register Map */
+#define UART_RBR		0x00
+#define  RBR_BRK_DET		BIT(15)
+#define  RBR_FRM_ERR_DET	BIT(14)
+#define  RBR_PAR_ERR_DET	BIT(13)
+#define  RBR_OVR_ERR_DET	BIT(12)
+
+#define UART_TSH		0x04
+
+#define UART_CTRL		0x08
+#define  CTRL_SOFT_RST		BIT(31)
+#define  CTRL_TXFIFO_RST	BIT(15)
+#define  CTRL_RXFIFO_RST	BIT(14)
+#define  CTRL_ST_MIRR_EN	BIT(13)
+#define  CTRL_LPBK_EN		BIT(12)
+#define  CTRL_SND_BRK_SEQ	BIT(11)
+#define  CTRL_PAR_EN		BIT(10)
+#define  CTRL_TWO_STOP		BIT(9)
+#define  CTRL_TX_HFL_INT	BIT(8)
+#define  CTRL_RX_HFL_INT	BIT(7)
+#define  CTRL_TX_EMP_INT	BIT(6)
+#define  CTRL_TX_RDY_INT	BIT(5)
+#define  CTRL_RX_RDY_INT	BIT(4)
+#define  CTRL_BRK_DET_INT	BIT(3)
+#define  CTRL_FRM_ERR_INT	BIT(2)
+#define  CTRL_PAR_ERR_INT	BIT(1)
+#define  CTRL_OVR_ERR_INT	BIT(0)
+#define  CTRL_RX_INT			(CTRL_RX_RDY_INT | CTRL_BRK_DET_INT |\
+	CTRL_FRM_ERR_INT | CTRL_PAR_ERR_INT | CTRL_OVR_ERR_INT)
+
+#define UART_STAT		0x0c
+#define  STAT_TX_FIFO_EMP	BIT(13)
+#define  STAT_RX_FIFO_EMP	BIT(12)
+#define  STAT_TX_FIFO_FUL	BIT(11)
+#define  STAT_TX_FIFO_HFL	BIT(10)
+#define  STAT_RX_TOGL		BIT(9)
+#define  STAT_RX_FIFO_FUL	BIT(8)
+#define  STAT_RX_FIFO_HFL	BIT(7)
+#define  STAT_TX_EMP		BIT(6)
+#define  STAT_TX_RDY		BIT(5)
+#define  STAT_RX_RDY		BIT(4)
+#define  STAT_BRK_DET		BIT(3)
+#define  STAT_FRM_ERR		BIT(2)
+#define  STAT_PAR_ERR		BIT(1)
+#define  STAT_OVR_ERR		BIT(0)
+#define  STAT_BRK_ERR		(STAT_BRK_DET | STAT_FRM_ERR | STAT_FRM_ERR\
+				 | STAT_PAR_ERR | STAT_OVR_ERR)
+
+#define UART_BRDV		0x10
+
+#define MVEBU_NR_UARTS		1
+
+#define MVEBU_UART_TYPE		"mvebu-uart"
+
+static struct uart_port mvebu_uart_ports[MVEBU_NR_UARTS];
+
+struct mvebu_uart_data {
+	struct uart_port *port;
+	struct clk       *clk;
+};
+
+/* Core UART Driver Operations */
+static unsigned int mvebu_uart_tx_empty(struct uart_port *port)
+{
+	unsigned long flags;
+	unsigned int st;
+
+	spin_lock_irqsave(&port->lock, flags);
+	st = readl(port->membase + UART_STAT);
+	spin_unlock_irqrestore(&port->lock, flags);
+
+	return (st & STAT_TX_FIFO_EMP) ? TIOCSER_TEMT : 0;
+}
+
+static unsigned int mvebu_uart_get_mctrl(struct uart_port *port)
+{
+	return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
+}
+
+static void mvebu_uart_set_mctrl(struct uart_port *port,
+				 unsigned int mctrl)
+{
+/*
+ * Even if we do not support configuring the modem control lines, this
+ * function must be proided to the serial core
+ */
+}
+
+static void mvebu_uart_stop_tx(struct uart_port *port)
+{
+	unsigned int ctl = readl(port->membase + UART_CTRL);
+
+	ctl &= ~CTRL_TX_RDY_INT;
+	writel(ctl, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_start_tx(struct uart_port *port)
+{
+	unsigned int ctl = readl(port->membase + UART_CTRL);
+
+	ctl |= CTRL_TX_RDY_INT;
+	writel(ctl, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_stop_rx(struct uart_port *port)
+{
+	unsigned int ctl = readl(port->membase + UART_CTRL);
+
+	ctl &= ~CTRL_RX_INT;
+	writel(ctl, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_break_ctl(struct uart_port *port, int brk)
+{
+	unsigned int ctl;
+	unsigned long flags;
+
+	spin_lock_irqsave(&port->lock, flags);
+	ctl = readl(port->membase + UART_CTRL);
+	if (brk == -1)
+		ctl |= CTRL_SND_BRK_SEQ;
+	else
+		ctl &= ~CTRL_SND_BRK_SEQ;
+	writel(ctl, port->membase + UART_CTRL);
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static void mvebu_uart_rx_chars(struct uart_port *port, unsigned int status)
+{
+	struct tty_port *tport = &port->state->port;
+	unsigned char ch = 0;
+	char flag = 0;
+
+	do {
+		if (status & STAT_RX_RDY) {
+			ch = readl(port->membase + UART_RBR);
+			ch &= 0xff;
+			flag = TTY_NORMAL;
+			port->icount.rx++;
+
+			if (status & STAT_PAR_ERR)
+				port->icount.parity++;
+		}
+
+		if (status & STAT_BRK_DET) {
+			port->icount.brk++;
+			status &= ~(STAT_FRM_ERR | STAT_PAR_ERR);
+			if (uart_handle_break(port))
+				goto ignore_char;
+		}
+
+		if (status & STAT_OVR_ERR)
+			port->icount.overrun++;
+
+		if (status & STAT_FRM_ERR)
+			port->icount.frame++;
+
+		if (uart_handle_sysrq_char(port, ch))
+			goto ignore_char;
+
+		if (status & port->ignore_status_mask & STAT_PAR_ERR)
+			status &= ~STAT_RX_RDY;
+
+		status &= port->read_status_mask;
+
+		if (status & STAT_PAR_ERR)
+			flag = TTY_PARITY;
+
+		status &= ~port->ignore_status_mask;
+
+		if (status & STAT_RX_RDY)
+			tty_insert_flip_char(tport, ch, flag);
+
+		if (status & STAT_BRK_DET)
+			tty_insert_flip_char(tport, 0, TTY_BREAK);
+
+		if (status & STAT_FRM_ERR)
+			tty_insert_flip_char(tport, 0, TTY_FRAME);
+
+		if (status & STAT_OVR_ERR)
+			tty_insert_flip_char(tport, 0, TTY_OVERRUN);
+
+ignore_char:
+		status = readl(port->membase + UART_STAT);
+	} while (status & (STAT_RX_RDY | STAT_BRK_DET));
+
+	tty_flip_buffer_push(tport);
+}
+
+static void mvebu_uart_tx_chars(struct uart_port *port, unsigned int status)
+{
+	struct circ_buf *xmit = &port->state->xmit;
+	unsigned int count;
+	unsigned int st;
+
+	if (port->x_char) {
+		writel(port->x_char, port->membase + UART_TSH);
+		port->icount.tx++;
+		port->x_char = 0;
+		return;
+	}
+
+	if (uart_circ_empty(xmit) || uart_tx_stopped(port)) {
+		mvebu_uart_stop_tx(port);
+		return;
+	}
+
+	for (count = 0; count < port->fifosize; count++) {
+		writel(xmit->buf[xmit->tail], port->membase + UART_TSH);
+		xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
+		port->icount.tx++;
+
+		if (uart_circ_empty(xmit))
+			break;
+
+		st = readl(port->membase + UART_STAT);
+		if (st & STAT_TX_FIFO_FUL)
+			break;
+	}
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+
+	if (uart_circ_empty(xmit))
+		mvebu_uart_stop_tx(port);
+}
+
+static irqreturn_t mvebu_uart_isr(int irq, void *dev_id)
+{
+	struct uart_port *port = (struct uart_port *)dev_id;
+	unsigned int st = readl(port->membase + UART_STAT);
+
+	if (st & (STAT_RX_RDY | STAT_OVR_ERR | STAT_FRM_ERR | STAT_BRK_DET))
+		mvebu_uart_rx_chars(port, st);
+
+	if (st & STAT_TX_RDY)
+		mvebu_uart_tx_chars(port, st);
+
+	return IRQ_HANDLED;
+}
+
+static int mvebu_uart_startup(struct uart_port *port)
+{
+	int ret;
+
+	writel(CTRL_TXFIFO_RST | CTRL_RXFIFO_RST,
+	       port->membase + UART_CTRL);
+	udelay(1);
+	writel(CTRL_RX_INT, port->membase + UART_CTRL);
+
+	ret = request_irq(port->irq, mvebu_uart_isr, port->irqflags, "serial",
+			  port);
+	if (ret) {
+		dev_err(port->dev, "failed to request irq\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static void mvebu_uart_shutdown(struct uart_port *port)
+{
+	writel(0, port->membase + UART_CTRL);
+}
+
+static void mvebu_uart_set_termios(struct uart_port *port,
+				   struct ktermios *termios,
+				   struct ktermios *old)
+{
+	unsigned long flags;
+	unsigned int baud;
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	port->read_status_mask = STAT_RX_RDY | STAT_OVR_ERR |
+		STAT_TX_RDY | STAT_TX_FIFO_FUL;
+
+	if (termios->c_iflag & INPCK)
+		port->read_status_mask |= STAT_FRM_ERR | STAT_PAR_ERR;
+
+	port->ignore_status_mask = 0;
+	if (termios->c_iflag & IGNPAR)
+		port->ignore_status_mask |=
+			STAT_FRM_ERR | STAT_PAR_ERR | STAT_OVR_ERR;
+
+	if ((termios->c_cflag & CREAD) == 0)
+		port->ignore_status_mask |= STAT_RX_RDY | STAT_BRK_ERR;
+
+	if (old)
+		tty_termios_copy_hw(termios, old);
+
+	baud = uart_get_baud_rate(port, termios, old, 0, 460800);
+	uart_update_timeout(port, termios->c_cflag, baud);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *mvebu_uart_type(struct uart_port *port)
+{
+	return MVEBU_UART_TYPE;
+}
+
+static void mvebu_uart_release_port(struct uart_port *port)
+{
+	/* Nothing to do here */
+}
+
+static int mvebu_uart_request_port(struct uart_port *port)
+{
+	return 0;
+}
+
+#ifdef CONFIG_CONSOLE_POLL
+static int mvebu_uart_get_poll_char(struct uart_port *port)
+{
+	unsigned int st = readl(port->membase + UART_STAT);
+
+	if (!(st & STAT_RX_RDY))
+		return NO_POLL_CHAR;
+
+	return readl(port->membase + UART_RBR);
+}
+
+static void mvebu_uart_put_poll_char(struct uart_port *port, unsigned char c)
+{
+	unsigned int st;
+
+	for (;;) {
+		st = readl(port->membase + UART_STAT);
+
+		if (!(st & STAT_TX_FIFO_FUL))
+			break;
+
+		udelay(1);
+	}
+
+	writel(c, port->membase + UART_TSH);
+}
+#endif
+
+static const struct uart_ops mvebu_uart_ops = {
+	.tx_empty	= mvebu_uart_tx_empty,
+	.set_mctrl	= mvebu_uart_set_mctrl,
+	.get_mctrl	= mvebu_uart_get_mctrl,
+	.stop_tx	= mvebu_uart_stop_tx,
+	.start_tx	= mvebu_uart_start_tx,
+	.stop_rx	= mvebu_uart_stop_rx,
+	.break_ctl	= mvebu_uart_break_ctl,
+	.startup	= mvebu_uart_startup,
+	.shutdown	= mvebu_uart_shutdown,
+	.set_termios	= mvebu_uart_set_termios,
+	.type		= mvebu_uart_type,
+	.release_port	= mvebu_uart_release_port,
+	.request_port	= mvebu_uart_request_port,
+#ifdef CONFIG_CONSOLE_POLL
+	.poll_get_char	= mvebu_uart_get_poll_char,
+	.poll_put_char	= mvebu_uart_put_poll_char,
+#endif
+};
+
+/* Console Driver Operations  */
+
+#ifdef CONFIG_SERIAL_MVEBU_CONSOLE
+/* Early Console */
+static void mvebu_uart_putc(struct uart_port *port, int c)
+{
+	unsigned int st;
+
+	for (;;) {
+		st = readl(port->membase + UART_STAT);
+		if (!(st & STAT_TX_FIFO_FUL))
+			break;
+	}
+
+	writel(c, port->membase + UART_TSH);
+
+	for (;;) {
+		st = readl(port->membase + UART_STAT);
+		if (st & STAT_TX_FIFO_EMP)
+			break;
+	}
+}
+
+static void mvebu_uart_putc_early_write(struct console *con,
+					const char *s,
+					unsigned n)
+{
+	struct earlycon_device *dev = con->data;
+
+	uart_console_write(&dev->port, s, n, mvebu_uart_putc);
+}
+
+static int __init
+mvebu_uart_early_console_setup(struct earlycon_device *device,
+			       const char *opt)
+{
+	if (!device->port.membase)
+		return -ENODEV;
+
+	device->con->write = mvebu_uart_putc_early_write;
+
+	return 0;
+}
+
+EARLYCON_DECLARE(ar3700_uart, mvebu_uart_early_console_setup);
+OF_EARLYCON_DECLARE(ar3700_uart, "marvell,armada-3700-uart",
+		    mvebu_uart_early_console_setup);
+
+static void wait_for_xmitr(struct uart_port *port)
+{
+	u32 val;
+
+	readl_poll_timeout_atomic(port->membase + UART_STAT, val,
+				  (val & STAT_TX_EMP), 1, 10000);
+}
+
+static void mvebu_uart_console_putchar(struct uart_port *port, int ch)
+{
+	wait_for_xmitr(port);
+	writel(ch, port->membase + UART_TSH);
+}
+
+static void mvebu_uart_console_write(struct console *co, const char *s,
+				     unsigned int count)
+{
+	struct uart_port *port = &mvebu_uart_ports[co->index];
+	unsigned long flags;
+	unsigned int ier;
+	int locked = 1;
+
+	if (oops_in_progress)
+		locked = spin_trylock_irqsave(&port->lock, flags);
+	else
+		spin_lock_irqsave(&port->lock, flags);
+
+	ier = readl(port->membase + UART_CTRL) &
+		(CTRL_RX_INT | CTRL_TX_RDY_INT);
+	writel(0, port->membase + UART_CTRL);
+
+	uart_console_write(port, s, count, mvebu_uart_console_putchar);
+
+	wait_for_xmitr(port);
+
+	if (ier)
+		writel(ier, port->membase + UART_CTRL);
+
+	if (locked)
+		spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static int mvebu_uart_console_setup(struct console *co, char *options)
+{
+	struct uart_port *port;
+	int baud = 9600;
+	int bits = 8;
+	int parity = 'n';
+	int flow = 'n';
+
+	if (co->index < 0 || co->index >= MVEBU_NR_UARTS)
+		return -EINVAL;
+
+	port = &mvebu_uart_ports[co->index];
+
+	if (!port->mapbase || !port->membase) {
+		pr_debug("console on ttyMV%i not present\n", co->index);
+		return -ENODEV;
+	}
+
+	if (options)
+		uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+	return uart_set_options(port, co, baud, parity, bits, flow);
+}
+
+static struct uart_driver mvebu_uart_driver;
+
+static struct console mvebu_uart_console = {
+	.name	= "ttyMV",
+	.write	= mvebu_uart_console_write,
+	.device	= uart_console_device,
+	.setup	= mvebu_uart_console_setup,
+	.flags	= CON_PRINTBUFFER,
+	.index	= -1,
+	.data	= &mvebu_uart_driver,
+};
+
+static int __init mvebu_uart_console_init(void)
+{
+	register_console(&mvebu_uart_console);
+	return 0;
+}
+
+console_initcall(mvebu_uart_console_init);
+
+
+#endif /* CONFIG_SERIAL_MVEBU_CONSOLE */
+
+static struct uart_driver mvebu_uart_driver = {
+	.owner			= THIS_MODULE,
+	.driver_name		= "mvebu_serial",
+	.dev_name		= "ttyMV",
+	.nr			= MVEBU_NR_UARTS,
+#ifdef CONFIG_SERIAL_MVEBU_CONSOLE
+	.cons			= &mvebu_uart_console,
+#endif
+};
+
+static int mvebu_uart_probe(struct platform_device *pdev)
+{
+	struct resource *reg = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	struct resource *irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+	struct uart_port *port;
+	struct mvebu_uart_data *data;
+	int ret;
+
+	if (!reg || !irq) {
+		dev_err(&pdev->dev, "no registers/irq defined\n");
+		return -EINVAL;
+	}
+
+	port = &mvebu_uart_ports[0];
+
+	spin_lock_init(&port->lock);
+
+	port->dev        = &pdev->dev;
+	port->type       = PORT_MVEBU;
+	port->ops        = &mvebu_uart_ops;
+	port->regshift   = 0;
+
+	port->fifosize   = 32;
+	port->iotype     = UPIO_MEM32;
+	port->flags      = UPF_FIXED_PORT;
+	port->line       = 0; /* single port: force line number to  0 */
+
+	port->irq        = irq->start;
+	port->irqflags   = 0;
+	port->mapbase    = reg->start;
+
+	port->membase = devm_ioremap_resource(&pdev->dev, reg);
+	if (IS_ERR(port->membase))
+		return -PTR_ERR(port->membase);
+
+	data = devm_kzalloc(&pdev->dev, sizeof(struct mvebu_uart_data),
+			    GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->port = port;
+
+	port->private_data = data;
+	platform_set_drvdata(pdev, data);
+
+	ret = uart_add_one_port(&mvebu_uart_driver, port);
+	if (ret)
+		return ret;
+	return 0;
+}
+
+static int mvebu_uart_remove(struct platform_device *pdev)
+{
+	struct mvebu_uart_data *data = platform_get_drvdata(pdev);
+
+	uart_remove_one_port(&mvebu_uart_driver, data->port);
+	data->port->private_data = NULL;
+	data->port->mapbase      = 0;
+	return 0;
+}
+
+/* Match table for of_platform binding */
+static const struct of_device_id mvebu_uart_of_match[] = {
+	{ .compatible = "marvell,armada-3700-uart", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, mvebu_uart_of_match);
+
+static struct platform_driver mvebu_uart_platform_driver = {
+	.probe	= mvebu_uart_probe,
+	.remove	= mvebu_uart_remove,
+	.driver	= {
+		.owner	= THIS_MODULE,
+		.name  = "mvebu-uart",
+		.of_match_table = of_match_ptr(mvebu_uart_of_match),
+	},
+};
+
+static int __init mvebu_uart_init(void)
+{
+	int ret;
+
+	ret = uart_register_driver(&mvebu_uart_driver);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&mvebu_uart_platform_driver);
+	if (ret)
+		uart_unregister_driver(&mvebu_uart_driver);
+
+	return ret;
+}
+
+static void __exit mvebu_uart_exit(void)
+{
+	platform_driver_unregister(&mvebu_uart_platform_driver);
+	uart_unregister_driver(&mvebu_uart_driver);
+}
+
+arch_initcall(mvebu_uart_init);
+module_exit(mvebu_uart_exit);
+
+MODULE_AUTHOR("Wilson Ding <dingwei at marvell.com>");
+MODULE_DESCRIPTION("Marvell Armada-3700 Serial Driver");
+MODULE_LICENSE("GPL");
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 3e5d757407fb..e513a4ee369b 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -261,4 +261,7 @@
 /* STM32 USART */
 #define PORT_STM32	113
 
+/* MVEBU UART */
+#define PORT_MVEBU	114
+
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 10:15:02 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 19:15:02 +0100
Subject: [PATCH v4 12/12] arm64: defconfig: enable Armada 3700 related config
In-Reply-To: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455646502-23834-13-git-send-email-gregory.clement@free-electrons.com>

This patch enables the configuration for the Armada 3700 family and for
the related driver it uses.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm64/configs/defconfig | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 18ca9fb9e65f..7ca2f0247ec5 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -31,6 +31,7 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_ARCH_MVEBU=y
 CONFIG_ARCH_BCM_IPROC=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_ARCH_EXYNOS7=y
@@ -93,6 +94,7 @@ CONFIG_ATA=y
 CONFIG_SATA_AHCI=y
 CONFIG_SATA_AHCI_PLATFORM=y
 CONFIG_AHCI_CEVA=y
+CONFIG_AHCI_MVEBU=y
 CONFIG_AHCI_XGENE=y
 CONFIG_SATA_RCAR=y
 CONFIG_PATA_PLATFORM=y
@@ -132,6 +134,7 @@ CONFIG_SERIAL_MSM_CONSOLE=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_SERIAL_XILINX_PS_UART=y
 CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
+CONFIG_SERIAL_MVEBU_UART=y
 CONFIG_VIRTIO_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 CONFIG_I2C=y
@@ -162,6 +165,8 @@ CONFIG_SND_SOC=y
 CONFIG_SND_SOC_RCAR=y
 CONFIG_SND_SOC_AK4613=y
 CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_PLATFORM=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
 CONFIG_USB_OHCI_HCD=y
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 10:15:01 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 19:15:01 +0100
Subject: [PATCH v4 11/12] Documentation: arm: update supported Marvell EBU
 processors
In-Reply-To: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455646502-23834-12-git-send-email-gregory.clement@free-electrons.com>

Now that we support Armada 37xx, let's add this family of SoC to the
Marvell documentation, and a reference to a link with more details about
those processors. As for Armda 39x, no datasheet is publicly
available at this time.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 Documentation/arm/Marvell/README | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index ae89b67d8e23..ddbc048bb467 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -118,6 +118,19 @@ EBU Armada family
   Linux kernel mach directory: arch/arm/mach-mvebu
   Linux kernel plat directory: none
 
+EBU Armada family ARMv8
+-----------------------
+
+  Armada 3710/3720 Flavors:
+	88F3710
+	88F3720
+
+  Core: ARM Cortex A53 (ARMv8)
+
+  Homepage     : http://www.marvell.com/embedded-processors/armada-3700/
+
+  Device tree descritpion located in arch/arm64/boot/dts/marvell/armada-37*
+
 Avanta family
 -------------
 
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 10:14:55 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 19:14:55 +0100
Subject: [PATCH v4 05/12] arm64: add mvebu architecture entry
In-Reply-To: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455646502-23834-6-git-send-email-gregory.clement@free-electrons.com>

The Armada 3700 is an mvebu ARM64 SoC using one or two Cortex-A53 cores
depending of the variant.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm64/Kconfig.platforms | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f674bde..85bec422d508 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -48,6 +48,12 @@ config ARCH_MEDIATEK
 	help
 	  Support for Mediatek MT65xx & MT81xx ARMv8 SoCs
 
+config ARCH_MVEBU
+	bool "Marvell EBU SoC Family"
+	help
+	  This enables support for Marvell EBU family such as the
+	  Armada 3700 SoC family.
+
 config ARCH_QCOM
 	bool "Qualcomm Platforms"
 	select PINCTRL
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 10:15:00 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 19:15:00 +0100
Subject: [PATCH v4 10/12] MAINTAINERS: Extend dts entry for ARM64 mvebu files
In-Reply-To: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455646502-23834-11-git-send-email-gregory.clement@free-electrons.com>

Extend the mvebu entry to ARM64 device tree sources.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 30aca4aa5467..ad49b62c5abc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1279,6 +1279,7 @@ F:	arch/arm/mach-mvebu/
 F:	drivers/rtc/rtc-armada38x.c
 F:	arch/arm/boot/dts/armada*
 F:	arch/arm/boot/dts/kirkwood*
+F:	arch/arm64/boot/dts/marvell/armada*
 
 
 ARM/Marvell Berlin SoC support
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 10:14:56 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 19:14:56 +0100
Subject: [PATCH v4 06/12] Documentation: dt-bindings: Add a new compatible for
 the Armada 3700
In-Reply-To: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455646502-23834-7-git-send-email-gregory.clement@free-electrons.com>

The AHCI interfaces used in the Armada 3700 has a few differences with
the one used in the Armada 38x, so it deserves its own compatible string.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/ata/ahci-platform.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index c2340eeeb97f..796e2c23e5df 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -13,6 +13,7 @@ Required properties:
   - "hisilicon,hisi-ahci"
   - "ibm,476gtr-ahci"
   - "marvell,armada-380-ahci"
+  - "marvell,armada-3700-ahci"
   - "snps,dwc-ahci"
   - "snps,exynos5440-ahci"
   - "snps,spear-ahci"
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 10:14:50 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 19:14:50 +0100
Subject: [PATCH v4 00/12] Add support for the Armada 3700 SoC an mvebu ARM64
 based
Message-ID: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>

This series introduce the support of the Armada 3700 family: it is the
first ARM64 SoC of the mvebu family submitted to the mainline!

Currently there are two members of the Armada 3700 family, the only
difference is the number of core: the Armada 3710 comes with one
Cortex-A53 whereas the Armada 3720 comes with 2 Cortex-A53. In this
series we enabled only the minimum to boot, pinctrl and clock tree
will come soon.

The changes in this forth version are even smaller than the former one
(see the changelog).

The first two patches patches are here to be able to use the the
ARCH_MVEBU for the Armada 3700 SoCs. The first ones is only here to
have standalone series but it comes from Thomas Petazzoni's series:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/472625

The third patch introduces a new serial driver for the uart used on
this SoC. The driver remains simple even if the hardware is capable of
doing more.

The forth one adapts the ahci driver to support the Armada 3700 SoC.
The forth patch updates the binding documentation with the new
compatible string.

The fifth patch adds a new entry Kconfig entry for this SoC family.

I took the opportunity of this series to tidy up the Marvell related
files in the binding documentation with the seventh patch.

The eighth patch introduces the compatible string for the SoCs of the
Armada 3700 family.

The ninth patch could be considered as the bulk of this series: it
adds the device tree files for the Armada 3700 SoCs and for the
reference board.

With the introduction of this new family the MAINTAINERS file, the
Marvell README and the ARM64 defconfig files have to be updated: it is
the purpose of the last 3 patches.

The patches 3 and 4 could be taken directly by the maintainer of their
respective subsystem as there is no dependency at all with the rest of
the series. I think that the rest of the series should go through the
arm-soc maintainer but in doubt I also added the ARM64 maintainer as
suggested by get_maintainer.pl.

Thanks,

Gregory

Changelog:
v3 -> v4
- Preserved alphabetical order in arch/arm64/Kconfig.platforms file,
  suggested by Jisheng
- Added Rob acked-by on patch 8
- Fix driver_name field in the uart_driver struct: use "mvebu_serial"
  instead of "serial"

v2 -> v3
- Renamed the remaining ttyS into ttyMV: reported by Greg KH
- Fixed the order of the compatible in the example of the binding
  documentation: pointed by Rob
- Fix a typo in Kconfig entry: pointed by Thomas Petazzoni

v1 -> v2
- Added Rob acked-by on patches 3, 6 and 7
- Used armada3700_uart instead of mvebu_uart for the uart driver:
  suggested by Mark
- In mvebu-uart, do not use anymore TTY_MAJOR, or ttyS, but dynamic
  major and ttyMV: pointed by Alan
- Use tty_termios_copy_hw in mvebu_uart_set_termios: suggested by Alan
- Use ARCH_MVEBU instead of creating ARCH_ARMADA_3700: suggested by
  Jisheng
- Added a new irqchip pacthes to fix build on ARM64 when ARCH_MVEBU is
  selected
- Removed marvell,armada3700 from the device tree binding and directly
  used marvell,armada3710 for common feature: pointed by Rob
- Fix memory node with coorect size in armada-3720-db.dts: suggested
  by Mark

Gregory CLEMENT (9):
  irqchip: armada-370-xp: do not enable it by default when ARCH_MVEBU is
    selected
  arm64: add mvebu architecture entry
  Documentation: dt-bindings: Add a new compatible for the Armada 3700
  Documentation: dt: Tidy up the Marvell related files
  devicetree: bindings: add DT binding for the Marvell Armada 3700 SoC
    family
  arm64: dts: add the Marvell Armada 3700 family and a development board
  MAINTAINERS: Extend dts entry for ARM64 mvebu files
  Documentation: arm: update supported Marvell EBU processors
  arm64: defconfig: enable Armada 3700 related config

Lior Amsalem (1):
  ata: ahci_mvebu: add support for Armada 3700 variant

Thomas Petazzoni (1):
  irqchip: armada-370-xp: add Kconfig option for the driver

Wilson Ding (1):
  serial: mvebu-uart: initial support for Armada-3700 serial port

 Documentation/arm/Marvell/README                   |  13 +
 .../arm/{ => marvell}/armada-370-xp-pmsu.txt       |   0
 .../bindings/arm/{ => marvell}/armada-370-xp.txt   |   0
 .../bindings/arm/{ => marvell}/armada-375.txt      |   0
 .../bindings/arm/marvell/armada-37xx.txt           |  16 +
 .../{ => marvell}/armada-380-mpcore-soc-ctrl.txt   |   0
 .../bindings/arm/{ => marvell}/armada-38x.txt      |   0
 .../bindings/arm/{ => marvell}/armada-39x.txt      |   0
 .../arm/{ => marvell}/armada-cpu-reset.txt         |   0
 .../arm/{ => marvell}/coherency-fabric.txt         |   0
 .../bindings/arm/{ => marvell}/kirkwood.txt        |   0
 .../bindings/arm/{ => marvell}/marvell,berlin.txt  |   0
 .../bindings/arm/{ => marvell}/marvell,dove.txt    |   0
 .../arm/{ => marvell}/marvell,kirkwood.txt         |   0
 .../arm/{ => marvell}/mvebu-cpu-config.txt         |   0
 .../arm/{ => marvell}/mvebu-system-controller.txt  |   0
 .../devicetree/bindings/ata/ahci-platform.txt      |   1 +
 .../devicetree/bindings/tty/serial/mvebu-uart.txt  |  13 +
 Documentation/kernel-parameters.txt                |   6 +
 MAINTAINERS                                        |   1 +
 arch/arm64/Kconfig.platforms                       |   6 +
 arch/arm64/boot/dts/marvell/Makefile               |   4 +
 arch/arm64/boot/dts/marvell/armada-371x.dtsi       |  53 ++
 arch/arm64/boot/dts/marvell/armada-3720-db.dts     |  86 +++
 arch/arm64/boot/dts/marvell/armada-372x.dtsi       |  63 ++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi       | 131 +++++
 arch/arm64/configs/defconfig                       |   5 +
 drivers/ata/ahci_mvebu.c                           |  14 +-
 drivers/irqchip/Kconfig                            |   4 +
 drivers/irqchip/Makefile                           |   2 +-
 drivers/tty/serial/Kconfig                         |  22 +
 drivers/tty/serial/Makefile                        |   1 +
 drivers/tty/serial/mvebu-uart.c                    | 650 +++++++++++++++++++++
 include/uapi/linux/serial_core.h                   |   3 +
 34 files changed, 1088 insertions(+), 6 deletions(-)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp-pmsu.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-375.txt (100%)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-380-mpcore-soc-ctrl.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-38x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-39x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-cpu-reset.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/coherency-fabric.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,berlin.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,dove.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-cpu-config.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-system-controller.txt (100%)
 create mode 100644 Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
 create mode 100644 arch/arm64/boot/dts/marvell/armada-371x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-db.dts
 create mode 100644 arch/arm64/boot/dts/marvell/armada-372x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-37xx.dtsi
 create mode 100644 drivers/tty/serial/mvebu-uart.c

-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 10:14:58 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 19:14:58 +0100
Subject: [PATCH v4 08/12] devicetree: bindings: add DT binding for the Marvell
 Armada 3700 SoC family
In-Reply-To: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455646502-23834-9-git-send-email-gregory.clement@free-electrons.com>

The Marvell Armada 3700 is a family of ARMv8 CA53 SoCs. This commit
introduces the Device Tree binding that documents the top-level
compatible strings for Armada 3700 based platforms.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/arm/marvell/armada-37xx.txt      | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
new file mode 100644
index 000000000000..51336e5fc761
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
@@ -0,0 +1,16 @@
+Marvell Armada 37xx Platforms Device Tree Bindings
+--------------------------------------------------
+
+Boards using a SoC of the Marvell Armada 37xx family must carry the
+following root node property:
+
+ - compatible: must contain "marvell,armada3710"
+
+In addition, boards using the Marvell Armada 3720 SoC shall have the
+following property before the previous one:
+
+ - compatible: must contain "marvell,armada3720"
+
+Example:
+
+compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 10:14:57 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 19:14:57 +0100
Subject: [PATCH v4 07/12] Documentation: dt: Tidy up the Marvell related files
In-Reply-To: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455646502-23834-8-git-send-email-gregory.clement@free-electrons.com>

Over the last releases we have added more and more Marvell related binding
directly in the arm directory. It's time to have our proper directory
inside it, and move all the files in it.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/arm/{ => marvell}/armada-370-xp-pmsu.txt          | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp.txt     | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-375.txt        | 0
 .../devicetree/bindings/arm/{ => marvell}/armada-380-mpcore-soc-ctrl.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-38x.txt        | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-39x.txt        | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/armada-cpu-reset.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/coherency-fabric.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/kirkwood.txt          | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/marvell,berlin.txt    | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/marvell,dove.txt      | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/marvell,kirkwood.txt  | 0
 Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-cpu-config.txt  | 0
 .../devicetree/bindings/arm/{ => marvell}/mvebu-system-controller.txt     | 0
 14 files changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp-pmsu.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-375.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-380-mpcore-soc-ctrl.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-38x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-39x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-cpu-reset.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/coherency-fabric.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,berlin.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,dove.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-cpu-config.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-system-controller.txt (100%)

diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt b/Documentation/devicetree/bindings/arm/marvell/armada-370-xp-pmsu.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-370-xp-pmsu.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp.txt b/Documentation/devicetree/bindings/arm/marvell/armada-370-xp.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-370-xp.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-370-xp.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-375.txt b/Documentation/devicetree/bindings/arm/marvell/armada-375.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-375.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-375.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-38x.txt b/Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-38x.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-38x.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-39x.txt b/Documentation/devicetree/bindings/arm/marvell/armada-39x.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-39x.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-39x.txt
diff --git a/Documentation/devicetree/bindings/arm/armada-cpu-reset.txt b/Documentation/devicetree/bindings/arm/marvell/armada-cpu-reset.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/armada-cpu-reset.txt
rename to Documentation/devicetree/bindings/arm/marvell/armada-cpu-reset.txt
diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/marvell/coherency-fabric.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/coherency-fabric.txt
rename to Documentation/devicetree/bindings/arm/marvell/coherency-fabric.txt
diff --git a/Documentation/devicetree/bindings/arm/kirkwood.txt b/Documentation/devicetree/bindings/arm/marvell/kirkwood.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/kirkwood.txt
rename to Documentation/devicetree/bindings/arm/marvell/kirkwood.txt
diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,berlin.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/marvell,berlin.txt
rename to Documentation/devicetree/bindings/arm/marvell/marvell,berlin.txt
diff --git a/Documentation/devicetree/bindings/arm/marvell,dove.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,dove.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/marvell,dove.txt
rename to Documentation/devicetree/bindings/arm/marvell/marvell,dove.txt
diff --git a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
rename to Documentation/devicetree/bindings/arm/marvell/marvell,kirkwood.txt
diff --git a/Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt b/Documentation/devicetree/bindings/arm/marvell/mvebu-cpu-config.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt
rename to Documentation/devicetree/bindings/arm/marvell/mvebu-cpu-config.txt
diff --git a/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/mvebu-system-controller.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/mvebu-system-controller.txt
rename to Documentation/devicetree/bindings/arm/marvell/mvebu-system-controller.txt
-- 
2.5.0



From gregory.clement at free-electrons.com  Tue Feb 16 10:14:59 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Tue, 16 Feb 2016 19:14:59 +0100
Subject: [PATCH v4 09/12] arm64: dts: add the Marvell Armada 3700 family and a
 development board
In-Reply-To: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <1455646502-23834-10-git-send-email-gregory.clement@free-electrons.com>

Add initial dtsi files to support Marvell Armada 3700 SoC with Cortex-A53
CPUs. There are two members in this family: the Armada 3710 (Single CPU)
and the Armada 3720 (Dual CPUs).

It also adds a dts file for the Marvell Armada 3720 DB board.

Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
---
 arch/arm64/boot/dts/marvell/Makefile           |   4 +
 arch/arm64/boot/dts/marvell/armada-371x.dtsi   |  53 ++++++++++
 arch/arm64/boot/dts/marvell/armada-3720-db.dts |  86 ++++++++++++++++
 arch/arm64/boot/dts/marvell/armada-372x.dtsi   |  63 ++++++++++++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   | 131 +++++++++++++++++++++++++
 5 files changed, 337 insertions(+)
 create mode 100644 arch/arm64/boot/dts/marvell/armada-371x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-db.dts
 create mode 100644 arch/arm64/boot/dts/marvell/armada-372x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-37xx.dtsi

diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index 348f4db4f313..2114af8d312d 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -1,6 +1,10 @@
+# Berlin SoC Family
 dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-dmp.dtb
 dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
 
+# Mvebu SoC Family
+dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
+
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
 clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/marvell/armada-371x.dtsi b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
new file mode 100644
index 000000000000..c9e5325b8ac3
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
@@ -0,0 +1,53 @@
+/*
+ * Device Tree Include file for Marvell Armada 371x family of SoCs
+ * (also named 88F3710)
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "armada-37xx.dtsi"
+
+/ {
+	model = "Marvell Armada 3710 SoC";
+	compatible = "marvell,armada3710", "marvell,armada3700";
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
new file mode 100644
index 000000000000..359050154511
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -0,0 +1,86 @@
+/*
+ * Device Tree file for Marvell Armada 3720 development board
+ * (DB-88F3720-DDR3)
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "armada-372x.dtsi"
+
+/ {
+	model = "Marvell Armada 3720 Development Board DB-88F3720-DDR3";
+	compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x00000000 0x00000000 0x20000000>;
+	};
+
+	soc {
+		internal-regs {
+			/*
+			* Exported on the micro USB connector CON32
+			* through an FTDI
+			*/
+			uart0: serial at 12000 {
+				status = "okay";
+			};
+
+			/* CON31 */
+			usb3 at 58000 {
+				status = "okay";
+			};
+
+			/* CON3 */
+			sata at e0000 {
+			       status = "okay";
+			};
+		};
+	};
+};
+
diff --git a/arch/arm64/boot/dts/marvell/armada-372x.dtsi b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
new file mode 100644
index 000000000000..f292a00ce97c
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
@@ -0,0 +1,63 @@
+/*
+ * Device Tree Include file for Marvell Armada 372x family of SoCs
+ * (also named 88F3720)
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "armada-37xx.dtsi"
+
+/ {
+	model = "Marvell Armada 3720 SoC";
+	compatible = "marvell,armada3720", "marvell,armada3710";
+
+	cpus {
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53","arm,armv8";
+			reg = <0x1>;
+			enable-method = "psci";
+		};
+	};
+
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
new file mode 100644
index 000000000000..ba9df7ff2a72
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -0,0 +1,131 @@
+/*
+ * Device Tree Include file for Marvell Armada 37xx family of SoCs.
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement at free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	model = "Marvell Armada 37xx SoC";
+	compatible = "marvell,armada3700";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0>;
+			enable-method = "psci";
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10
+			(GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		internal-regs {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "simple-bus";
+			/* 32M internal register @ 0xd000_0000 */
+			ranges = <0x0 0x0 0xd0000000 0x2000000>;
+
+			uart0: serial at 12000 {
+				compatible = "marvell,armada-3700-uart";
+				reg = <0x12000 0x400>;
+				interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+				status = "disabled";
+			};
+
+			usb3 at 58000 {
+				compatible = "generic-xhci";
+				reg = <0x58000 0x4000>;
+				interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+				status = "disabled";
+			};
+
+			sata at e0000 {
+				compatible = "marvell,armada-3700-ahci";
+				reg = <0xe0000 0x2000>;
+				interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+				status = "disabled";
+			};
+
+			gic: interrupt-controller at 1d00000 {
+				compatible = "arm,gic-v3";
+				#interrupt-cells = <3>;
+				interrupt-controller;
+				reg = <0x1d00000 0x10000>, /* GICD */
+				      <0x1d40000 0x40000>; /* GICR */
+			};
+		};
+	};
+};
-- 
2.5.0



From keescook at chromium.org  Tue Feb 16 10:38:09 2016
From: keescook at chromium.org (Kees Cook)
Date: Tue, 16 Feb 2016 10:38:09 -0800
Subject: [PATCH] ARM: fix __start_rodata_section_aligned on XIP
Message-ID: <20160216183809.GA26069@www.outflux.net>

This fixes the build for both allnoconfig (!CONFIG_MMU) and with
XIP_KERNEL (due to missing pieces in the linker script), as seen after
both "ARM: 8502/1: mm: mark section-aligned portion of rodata NX" and
"ARM: 8513/1: xip: Move XIP linking to a separate file".

Reported-by: Russell King <linux at arm.linux.org.uk>
Reported-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Kees Cook <keescook at chromium.org>
---
 arch/arm/kernel/vmlinux-xip.lds.S | 18 +++++++++++++++---
 arch/arm/kernel/vmlinux.lds.S     |  4 ++++
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
index 40bc4cadb959..2da60cd1b295 100644
--- a/arch/arm/kernel/vmlinux-xip.lds.S
+++ b/arch/arm/kernel/vmlinux-xip.lds.S
@@ -8,9 +8,7 @@
 #include <asm/thread_info.h>
 #include <asm/memory.h>
 #include <asm/page.h>
-#ifdef CONFIG_DEBUG_RODATA
 #include <asm/pgtable.h>
-#endif
 
 #define PROC_INFO							\
 	. = ALIGN(4);							\
@@ -115,7 +113,7 @@ SECTIONS
 			ARM_CPU_KEEP(PROC_INFO)
 	}
 
-#ifdef CONFIG_DEBUG_RODATA
+#ifdef CONFIG_DEBUG_ALIGN_RODATA
 	. = ALIGN(1<<SECTION_SHIFT);
 #endif
 	RO_DATA(PAGE_SIZE)
@@ -148,6 +146,9 @@ SECTIONS
 
 	NOTES
 
+#ifdef CONFIG_DEBUG_RODATA
+	. = ALIGN(1<<SECTION_SHIFT);
+#endif
 	_etext = .;			/* End of text and rodata section */
 
 	/*
@@ -310,6 +311,17 @@ SECTIONS
 }
 
 /*
+ * Without CONFIG_DEBUG_ALIGN_RODATA, __start_rodata_section_aligned will
+ * be the first section-aligned location after __start_rodata. Otherwise,
+ * it will be equal to __start_rodata.
+ */
+#ifdef CONFIG_MMU
+__start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
+#else
+__start_rodata_section_aligned = __start_rodata;
+#endif
+
+/*
  * These must never be empty
  * If you have to comment these two assert statements out, your
  * binutils is too old (for other reasons as well)
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 1707b9431761..f13960e44955 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -328,7 +328,11 @@ SECTIONS
  * be the first section-aligned location after __start_rodata. Otherwise,
  * it will be equal to __start_rodata.
  */
+#ifdef CONFIG_MMU
 __start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
+#else
+__start_rodata_section_aligned = __start_rodata;
+#endif
 
 /*
  * These must never be empty
-- 
2.6.3


-- 
Kees Cook
Chrome OS & Brillo Security


From catalin.marinas at arm.com  Tue Feb 16 10:40:58 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 16 Feb 2016 18:40:58 +0000
Subject: [PATCH v2] arm64: use local label prefixes for __reg_num symbols
In-Reply-To: <1455526309-18519-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455526309-18519-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160216184058.GF19413@e104818-lin.cambridge.arm.com>

On Mon, Feb 15, 2016 at 09:51:49AM +0100, Ard Biesheuvel wrote:
> The __reg_num_xNN symbols that are used to implement the msr_s and
> mrs_s macros are recorded in the ELF metadata of each object file.
> This does not affect the size of the final binary, but it does clutter
> the output of tools like readelf, i.e.,
> 
>   $ readelf -a vmlinux |grep -c __reg_num_x
>   50976
> 
> So let's use symbols with the .L prefix, these are strictly local,
> and don't end up in the object files.
> 
>   $ readelf -a vmlinux |grep -c __reg_num_x
>   0
> 
> Acked-by: Will Deacon <will.deacon at arm.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

Applied. Thanks.

-- 
Catalin


From keescook at chromium.org  Tue Feb 16 10:41:09 2016
From: keescook at chromium.org (Kees Cook)
Date: Tue, 16 Feb 2016 10:41:09 -0800
Subject: [PATCH 1/2] ARM: mm: DEBUG_RODATA makes no sense with XIP_KERNEL
In-Reply-To: <1455638631-3326518-1-git-send-email-arnd@arndb.de>
References: <1455638631-3326518-1-git-send-email-arnd@arndb.de>
Message-ID: <CAGXu5jJ84FupuH2Zq8TVKNTS3zMTYZiBaSbjWZWWZ1ApBzBtwg@mail.gmail.com>

On Tue, Feb 16, 2016 at 8:03 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> When CONFIG_DEBUG_ALIGN_RODATA is set, we get a link error:
>
> arch/arm/mm/built-in.o:(.data+0x4bc): undefined reference to `__start_rodata_section_aligned'
>
> However, this combination is useless, as XIP_KERNEL implies that all the
> RODATA is already marked readonly, so both CONFIG_DEBUG_RODATA and
> CONFIG_DEBUG_ALIGN_RODATA (which depends on the other) are not
> needed with XIP_KERNEL, and this patches enforces that using a Kconfig
> dependency.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 25362dc496ed ("ARM: 8501/1: mm: flip priority of CONFIG_DEBUG_RODATA")

Oh, hm, I didn't see this before sending my fix for the rodata start issue.

> ---
>  arch/arm/mm/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index fbf2296388ce..8894045caba9 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -1039,7 +1039,7 @@ config ARCH_SUPPORTS_BIG_ENDIAN
>
>  config DEBUG_RODATA
>         bool "Make kernel text and rodata read-only"
> -       depends on MMU
> +       depends on MMU && !XIP_KERNEL

If we do this, we need to probably clean up the xip linker script to
remove all the references to DEBUG_*RODATA too.

-Kees

>         default y if CPU_V7
>         help
>           If this is set, kernel text and rodata memory will be made
> --
> 2.7.0
>



-- 
Kees Cook
Chrome OS & Brillo Security


From borntraeger at de.ibm.com  Tue Feb 16 10:46:03 2016
From: borntraeger at de.ibm.com (Christian Borntraeger)
Date: Tue, 16 Feb 2016 19:46:03 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160215213526.GA9766@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name> <56BE00E7.1010303@de.ibm.com>
 <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
 <alpine.LFD.2.20.1602131238260.1910@schleppi>
 <20160215113159.GA28832@node.shutemov.name>
 <20160215193702.4a15ed5e@thinkpad> <20160215213526.GA9766@node.shutemov.name>
Message-ID: <56C36E6B.70009@de.ibm.com>

On 02/15/2016 10:35 PM, Kirill A. Shutemov wrote:
> 
> Is there any chance that I'll be able to trigger the bug using QEMU?
> Does anybody have an QEMU image I can use?

qemu/TCG on s390 does neither provide SMP nor large pages (only QEMU/KVM does)
so this will probably not help you here. 

Christian



From laura at labbott.name  Tue Feb 16 10:48:31 2016
From: laura at labbott.name (Laura Abbott)
Date: Tue, 16 Feb 2016 10:48:31 -0800
Subject: [PATCH] arm64: mm: Mark .rodata as RO
In-Reply-To: <CAGXu5jLpj=ue49_N+LOYvtZcU3rpFR5=WTG15ySDOWprvRzFUA@mail.gmail.com>
References: <1455293599-6974-1-git-send-email-jeremy.linton@arm.com>
 <20160212182527.GG20262@leverpostej>
 <CAGXu5jLpj=ue49_N+LOYvtZcU3rpFR5=WTG15ySDOWprvRzFUA@mail.gmail.com>
Message-ID: <56C36EFF.9060900@labbott.name>

On 2/16/16 10:10 AM, Kees Cook wrote:
> On Fri, Feb 12, 2016 at 10:25 AM, Mark Rutland <mark.rutland at arm.com> wrote:
>> On Fri, Feb 12, 2016 at 10:13:19AM -0600, Jeremy Linton wrote:
>>> Currently the .rodata section is actually still executable when DEBUG_RODATA
>>> is enabled. This changes that so the .rodata is actually read only, no execute.
>>>
>>> Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
>
> Yikes, good catch. Is anyone running the lkdtm tests that check these things?
>

I don't think the current lkdtm test would have caught this since the exec
test is using rw data and not ro data. That test could be expanded though
to include a rodata buffer as well.
  
Thanks,
Laura


From torvalds at linux-foundation.org  Tue Feb 16 10:50:02 2016
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Tue, 16 Feb 2016 10:50:02 -0800
Subject: [PATCH v2] arm64: add alignment fault hanling
In-Reply-To: <20160216170408.GL14509@arm.com>
References: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
 <20160216103104.GC14509@arm.com> <56C300AD.8070505@arm.com>
 <20160216122153.GD19413@e104818-lin.cambridge.arm.com>
 <20160216160055.GH14509@arm.com> <20160216170408.GL14509@arm.com>
Message-ID: <CA+55aFw-86k4gY46Et=e02HQQSxjUK2Jfz0SJz8tWtk5P8YZFA@mail.gmail.com>

On Tue, Feb 16, 2016 at 9:04 AM, Will Deacon <will.deacon at arm.com> wrote:
> [replying to self and adding some x86 people]
>
> Background: Euntaik reports a problem where userspace has ended up with
> a memory page mapped adjacent to an MMIO page (e.g. from /dev/mem or a
> PCI memory bar from someplace in /sys). strncpy_from_user happens with
> the word-at-a-time implementation, and we end up reading into the MMIO
> page.
>
> Question: Does x86 guarantee that this faults? (Arjan reckoned no, but
> wasn't 100%).

x86 not only does *not* guarantee that that faults, but quite the
reverse: I'm pretty sure it would be considered an architectural bug
if it didn't silently "just work". IOW, the page-crossing unaligned
access will be split up as two accesses, and done as a regular cached
read for the normal RAM page part, and as an uncached IO read for the
MMIO page.

So if somebody passes us a string adjacent to a MMIO mapping, we'll
happily do the access on x86 and touch the MMIO space. No biggie, and
nobody sane actually does that. If you have the rights to do device
mappings, you should probably restrain from doing insane things. "With
great power comes great responsibility".

> Thinking more about this, we could spit out a guard page between every
> VMA, but it's likely to hamper any VMA merging.

More importantly, it wouldn't work for the general case. People often
pass in a specific virtual memory address to mmap because they *need*
adjacent mappings. One example of that case is doing a circular buffer
that is guaranteed to always be accessible linearly (and avoiding the
split case where it hits the end of the circular buffer) by mapping
the same buffer twice.

Of course, no actual real program will do that for mixing MMIO and
non-MMIO, and so we might obviously add code to always add a guard
page for the normal case when a specific address isn't asked for. So
as a heuristic to make sure it doesn't happen by mistake it possibly
makes sense.

You'd still want to make sure that you don't get a kernel oops if some
attacker tries to break ARM64 on purpose, obviously (although even
that is not necessarily a huge deal for somebody who already has
physical IO privileges). So I suspect that Eun Taik Lee's patch makes
perfect sense even if it's not necessarily the full solution in
itself.

                Linus


From Chris.Brandt at renesas.com  Tue Feb 16 10:53:46 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Tue, 16 Feb 2016 18:53:46 +0000
Subject: [PATCH v2] ARM: proc-v7.S: Adjust stack address when XIP_KERNEL
In-Reply-To: <20160216173225.GE19428@n2100.arm.linux.org.uk>
References: <1454105474-3009-1-git-send-email-chris.brandt@renesas.com>
 <1454335736-10084-1-git-send-email-chris.brandt@renesas.com>
 <alpine.LFD.2.20.1602011613360.32766@knanqh.ubzr>
 <20160216173225.GE19428@n2100.arm.linux.org.uk>
Message-ID: <HK2PR06MB0561B01AAD9BA5DAC043B6AC8AAD0@HK2PR06MB0561.apcprd06.prod.outlook.com>

On 16 Feb 2016, Russell King - ARM Linux wrote:

> I keep looking at this patch, and I really find that I detest this
> PHYS_OFFSET_FIXUP thing - it's really not obvious what's going on here.
> It's taken a _long_ time to work this out, which _really_ isn't good
> going forward.
> 
> Let's instead change things to make it much more obvious - see the
> patch below.
> 
> 
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
>  index ebdaaf7dd19f..593e5613184d 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -135,11 +135,18 @@
>  #define PLAT_PHYS_OFFSET	UL(CONFIG_PHYS_OFFSET)
>  
>  #ifdef CONFIG_XIP_KERNEL
> -#define PHYS_OFFSET_FIXUP \
> -	( XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR) - PAGE_OFFSET + \
> -	  PLAT_PHYS_OFFSET - CONFIG_XIP_PHYS_ADDR )
> +/*
> + * When referencing data in RAM from the XIP region in a relative 
> +manner
> + * with the MMU off, we need the relative offset between the two 
> +physical
> + * addresses.  The macro below achieves this, which is:
> + *    __pa(v_data) - __xip_pa(v_text)
> + */
> +#define PHYS_RELATIVE(v_data, v_text) \
> +	(((v_data) - PAGE_OFFSET + PLAT_PHYS_OFFSET) - \
> +	 ((v_text) - XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR) + \
> +          CONFIG_XIP_PHYS_ADDR))
>  #else
> -#define PHYS_OFFSET_FIXUP 0
> +#define PHYS_RELATIVE(v_data, v_text) (v_data) - (v_text)
>  #endif
>  
>  #ifndef __ASSEMBLY__
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index
>  1595fb29ec12..0f8963a7e7d9 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -487,7 +487,7 @@ __errata_finish:
>  
>  	.align	2
>  __v7_setup_stack_ptr:
> -	.word	__v7_setup_stack - . + PHYS_OFFSET_FIXUP
> +	.word	PHYS_RELATIVE(__v7_setup_stack, .)
>  ENDPROC(__v7_setup)
>  
>  	.bss
>


This works fine for me (comes up with the same number either way).

Just tested it with my XIP_KERNEL ARMv7 system.


Chris



From torvalds at linux-foundation.org  Tue Feb 16 10:59:08 2016
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Tue, 16 Feb 2016 10:59:08 -0800
Subject: Writes, smp_wmb(), and transitivity?
In-Reply-To: <20160215175825.GA15878@linux.vnet.ibm.com>
References: <20160215175825.GA15878@linux.vnet.ibm.com>
Message-ID: <CA+55aFxaQEvDrzecmZUQ5QfKzU4ei6E-+NpsW5hYp3ouaLP98g@mail.gmail.com>

On Mon, Feb 15, 2016 at 9:58 AM, Paul E. McKenney
<paulmck at linux.vnet.ibm.com> wrote:
>
> Two threads:
>
>         int a, b;
>
>         void thread0(void)
>         {
>                 WRITE_ONCE(a, 1);
>                 smp_wmb();
>                 WRITE_ONCE(b, 2);
>         }
>
>         void thread1(void)
>         {
>                 WRITE_ONCE(b, 1);
>                 smp_wmb();
>                 WRITE_ONCE(a, 2);
>         }
>
>         /* After all threads have completed and the dust has settled... */
>
>         BUG_ON(a == 1 && b == 1);

So the more I look at that kind of litmus test, the less I think that
we should care, because I can't come up with a scenario in where that
kind of test makes sense. without even a possibility of any causal
relationship between the two, I can't say why we'd ever care about the
ordering of the (independent) writes to the individual variables.

If somebody can make up a causal chain, things differ. But as long as
all the CPU's are just doing locally ordered writes, I don't think we
need to care about a global store ordering.

              Linus


From robin.murphy at arm.com  Tue Feb 16 11:05:59 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue, 16 Feb 2016 19:05:59 +0000
Subject: [PATCH] ARM64: dma-mapping: fix handling of devices registered
 before arch_initcall
In-Reply-To: <1455632084-14666-1-git-send-email-m.szyprowski@samsung.com>
References: <1455632084-14666-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <56C37317.9020104@arm.com>

On 16/02/16 14:14, Marek Szyprowski wrote:
> This patch ensures that devices, which got registered before arch_initcall
> will be handled correctly by IOMMU-based DMA-mapping code.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
> ---
>   arch/arm64/mm/dma-mapping.c | 4 ++++
>   1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 573b1e6..ce6019f 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -928,6 +928,10 @@ static int __init __iommu_dma_init(void)
>   		ret = register_iommu_dma_ops_notifier(&platform_bus_type);
>   	if (!ret)
>   		ret = register_iommu_dma_ops_notifier(&amba_bustype);
> +
> +	/* handle devices queued before this arch_initcall */
> +	if (!ret)
> +		__iommu_attach_notifier(NULL, BUS_NOTIFY_ADD_DEVICE, NULL);

Hmm, surely unless *all* the devices on the relevant buses are created 
before arch_initcall level, then the next one is going to kick off the 
notifier to walk the whole list anyway. Have you seen this being a 
problem in practice?

Robin.

>   	return ret;
>   }
>   arch_initcall(__iommu_dma_init);
>



From mturquette at baylibre.com  Tue Feb 16 10:57:37 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Tue, 16 Feb 2016 10:57:37 -0800
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in
 console
In-Reply-To: <F7B22AC0-58A7-431D-B203-0C7A9802A040@martin.sperl.org>
References: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
 <56BC895E.2010108@sperl.org>
 <1617009200.323700.219000a8-c162-4594-aacc-a7e9894518b2.open-xchange@email.1und1.de>
 <662D2FB2-B088-4CFC-8416-A4F35BBAD7DD@sperl.org>
 <F7A2533A-D64C-4187-ABD4-416C446D1637@martin.sperl.org>
 <6CD3FC59-BA17-43D9-897C-A2D122D26EF8@martin.sperl.org>
 <470852136.382408.76a8faee-9235-4ee0-9fd1-e25a1e9f0bb3.open-xchange@email.1und1.de>
 <F7B22AC0-58A7-431D-B203-0C7A9802A040@martin.sperl.org>
Message-ID: <20160216185737.2278.60129@quark.deferred.io>

Hi Martin & Stefan,

Quoting Martin Sperl (2016-02-13 03:24:43)
> 
> > On 13.02.2016, at 11:01, Stefan Wahren <stefan.wahren at i2se.com> wrote:
> > 
> > Hi Martin,
> > 
> >> Martin Sperl <kernel at martin.sperl.org> hat am 12. Februar 2016 um 20:44
> >> geschrieben:
> >> 
> >> So the issue is triggered as soon as the plld_per
> >> pll divider gets disabled/reenabled.
> >> 
> >> This happens because the clk_hw.core.prepare_count
> >> drops down to 0 and then unprepare is called.
> >> 
> >> So we need to increase the ref-count for the pll
> >> and pll_dividers to at least 1 so that these never
> >> get disabled - at least for now until we can come
> >> up with a better contract with the firmware.
> >> 
> >> Obviously this may impact other drivers as well
> >> where a pll is used for the first time - if nothing
> >> else uses it and the clock gets released, then
> >> the clock would trigger a unprepare of the whole
> >> branch of the clock tree.
> >> 
> >> The question is: how can we solve it in an acceptable
> >> manner?
> >> 
> >> Do we need a driver that just holds a reference to
> >> those clocks? Or should we just prepare the clock
> >> after registering it in clk-bcm2835.c?
> >> 
> >> As for why does this not show up when compiled in?
> >> It seems that in that case the amba_pl011 driver
> >> never gets removed and then probed again.
> >> 
> >> This is possibly related to the optional use of DMA,
> >> with the amba-pl011 driver that retries the install,
> >> which is not supported on the bcm2835 - at least that
> >> is what the datasheet says. And DMA is (probably) not
> >> enabled during the early boot stages, so it does not
> >> fail once when it tries to register DMA.
> >> 
> >> Thanks,
> >> Martin
> >> 
> > 
> > i think i must correct myself. The fixed apb should stay since there is no
> > dynamic replacement and a proper disabling of plld shouldn't cause this freeze.
> > 
> > I have the suspicion the freeze is caused by a clock glitch or lock-up.
> > 
> > Could you please revert your changes and apply the attached patch? Maybe we can
> > see more.
> 
> I will give it a try.
> 
> But to me it seems as if the disabling of PLLD produces a hickup in the 
> firmware (which relies on PLLD-DIV and thus PLL).
> 
> This would also explain the 3-4 second bar/blanking pattern seen on HDMI,
> which I would guess is related to a reset loop...
> 
> I got a simple fix for now, that just prepares a few clocks/pll/pll_divs
> during probing, so that they will never get unprepared/fully stopped):
> 
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index 015e687..fe0c401 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -37,6 +37,7 @@
>   * generator).
>   */
> 
> +#include <linux/clk.h>
>  #include <linux/clk-provider.h>
>  #include <linux/clkdev.h>
>  #include <linux/clk/bcm2835.h>
> @@ -1504,6 +1505,7 @@ static int bcm2835_clk_probe(struct platform_device *pdev)
>         struct clk **clks;
>         struct bcm2835_cprman *cprman;
>         struct resource *res;
> +       int ret;
> 
>         cprman = devm_kzalloc(dev, sizeof(*cprman), GFP_KERNEL);
>         if (!cprman)
> @@ -1597,6 +1599,37 @@ static int bcm2835_clk_probe(struct platform_device *pdev
>         clks[BCM2835_CLOCK_PWM] =
>                 bcm2835_register_clock(cprman, &bcm2835_clock_pwm_data);
> 
> +       /*
> +        * Several PLLs, PLL-dividers and clocks need to get prepared
> +        * so that they are never unprepared and released.
> +        * We run this separately as there may be dependencies that would
> +        * need to be fullfilled first...
> +        * Note: Especially unpreparing PLLD_PER will kill the system
> +        *       (even if it is prepared again almost immediately
> +        *        the HDMI display will fail)
> +        */
> +#define CLK_PREPARE_INITIAL(clkid)                                     \
> +       if (clks[clkid] && (ret = clk_prepare(clks[clkid])))            \
> +               dev_err(dev, "could not prepare clock %pC - %d\n",      \
> +                       clks[clkid], ret);

You should not only prepare the clock, but enable it as well, even if
your .enable callback is no-op. s/clk_prepare/clk_prepare_enable/ should
do it. But instead of all of this stuff below...

> +       CLK_PREPARE_INITIAL(BCM2835_PLLA);
> +       CLK_PREPARE_INITIAL(BCM2835_PLLB);
> +       CLK_PREPARE_INITIAL(BCM2835_PLLC);
> +       CLK_PREPARE_INITIAL(BCM2835_PLLD);
> +       CLK_PREPARE_INITIAL(BCM2835_PLLH);
> +       CLK_PREPARE_INITIAL(BCM2835_PLLA_CORE);
> +       CLK_PREPARE_INITIAL(BCM2835_PLLA_PER);
> +       CLK_PREPARE_INITIAL(BCM2835_PLLC_CORE0);
> +       CLK_PREPARE_INITIAL(BCM2835_PLLC_CORE1);
> +       CLK_PREPARE_INITIAL(BCM2835_PLLC_CORE2);
> +       CLK_PREPARE_INITIAL(BCM2835_PLLC_PER);
> +       CLK_PREPARE_INITIAL(BCM2835_PLLD_CORE);
> +       CLK_PREPARE_INITIAL(BCM2835_PLLD_PER);
> +       CLK_PREPARE_INITIAL(BCM2835_PLLH_RCAL);
> +       CLK_PREPARE_INITIAL(BCM2835_PLLH_AUX);
> +       CLK_PREPARE_INITIAL(BCM2835_PLLH_PIX);
> +       CLK_PREPARE_INITIAL(BCM2835_CLOCK_VPU);

... how about using the shiny new HAND_OFF clocks feature? See:

http://lkml.kernel.org/r/<1455225554-13267-1-git-send-email-mturquette at baylibre.com>

It seems like you need clocks to remain enabled from the time they are
registered until a clk consumer driver claims them and Does The Right
Thing. (e.g. only gates them when it is safe to do so, such as display
being turned off by user).

Let me know if those patches will help you. The first three patches in
the series introduce CRITICAL clocks, which never gate. Patches 4-6 are
a solution that I prefer, allowing the clocks to remain enabled by the
bootloader, and only gated later on when a consumer driver claims them.
No changes to clock consumer drivers are required, the framework handles
the transition of reference counts and the clock provider driver only
has to set the CLK_ENABLE_HAND_OFF flag for the affected clocks.

Regards,
Mike

> +
>         return of_clk_add_provider(dev->of_node, of_clk_src_onecell_get,
>                                    &cprman->onecell);
>  }
> 
> And that resolves the issue and also allows loading/unloading of the
> amba-pl011 module as well without any hickups.
> 
> I guess it would be better if we did make this configurable in the DT.
> (See patch 1 of my RFC patchset, which could get extended to handle this
> as well - at least a portion thereof).
> 
> But in more general terms: we need to come up with some agreement
> on ownership of the clocks between linux and the firmware and how
> to change them without impacting the other. 
> 
> One example is the ?overclocking? that currently happens for
> downstream kernels in the firmware, which impacts some of the
> plls and PLLdivs as well as the sram control registers.
> 
> The reason for this seems to be that for overclocking the SRAM
> parameters also need to get changed and that can only get done
> reliably when running the code from L1/L2 caches - and that
> requirement of not touching SRAM while changing the SRAM parameters
> is probably hard to achieve cleanly on ARM alone.
> 
> Ciao,
>         Martin
> 
> P.s: unloading amba_pl011 gives the following error:
> root at raspcm:~# rmmod amba_pl011
> [  142.318263] Trying to free nonexistent resource <0000000020201000-0000000020201fff>
> but that is an issue not related to clock...
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From msalter at redhat.com  Tue Feb 16 11:11:43 2016
From: msalter at redhat.com (Mark Salter)
Date: Tue, 16 Feb 2016 14:11:43 -0500
Subject: [PATCH v3 0/5] ACPI: parse the SPCR table
In-Reply-To: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1455649903.5681.6.camel@redhat.com>

On Mon, 2016-02-15 at 21:05 +0300, Aleksey Makarov wrote:
> This patchset is based on the patchset by Leif Lindholm [1]
> 
> 'ARM Server Base Boot Requirements' [2] mentions SPCR (Serial Port
> Console Redirection Table) [3] as a mandatory ACPI table that
> specifies the configuration of serial console.
> 
> SPCR support is included in QEMU's ARM mach-virt since 2.4 release.
> 
> Introduce a new function acpi_console_check().? At the uart port
> registration, this function checks if the ACPI SPCR table specifies
> its argument of type struct uart_port to be a console
> and if so calls add_preferred_console().
> 
> Use SPCR to tell if SBSA serial driver should use 32-bit access to registers.
> 
> To be able to access SPCR table each time any console is registered
> change __init to __ref for early_acpi_os_unmap_memory().
> 
> The patchset should be applied to tty-next.

On Mustang, m400, and Seattle:

Tested-by: Mark Salter <msalter at redhat.com>



From tchalamarla at caviumnetworks.com  Tue Feb 16 11:14:44 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Tue, 16 Feb 2016 11:14:44 -0800
Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <20160216144250.GD31343@rric.localdomain>
References: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160214170152.GC3965@htj.duckdns.org> <56C147B2.9010303@caviumnetworks.com>
 <20160215183041.GH3965@htj.duckdns.org>
 <20160216144250.GD31343@rric.localdomain>
Message-ID: <56C37524.5090000@caviumnetworks.com>



On 02/16/2016 06:42 AM, Robert Richter wrote:
> On 15.02.16 13:30:41, Tejun Heo wrote:
>> On Sun, Feb 14, 2016 at 07:36:18PM -0800, Tirumalesh Chalamarla wrote:
>>> There is no need for special Driver, AHCI is sufficient for ThunderX, the
>>> file only contains this interrupt handler,
>>> is it preferable if this interrupt handler in libahci.c with others, instead
>>> of separate file?
>>
>> Yeap, just fold it in ahci.c with surrounding #ifdef guard.
>
> Yes, please use #ifdef CONFIG_CAVIUM_ERRATUM_22536 ... and add a
> kconfig entry for this to arch/arm64/Kconfig.
>
Are you sure, this is not a workaround that is based on alternative 
framework rather on pci device and vendor

do you think CONFIG_ARCH_THUNDER a good alternative?



> -Robert
>


From Chris.Brandt at renesas.com  Tue Feb 16 11:18:51 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Tue, 16 Feb 2016 19:18:51 +0000
Subject: [PATCH v2] ARM: vmlinux-xip.lds: assert that ROM and RAM don't
 overlap
In-Reply-To: <1455278803-27679-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455278803-27679-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <HK2PR06MB05619656241BFD0A9165B6C28AAD0@HK2PR06MB0561.apcprd06.prod.outlook.com>

On 12 Feb 2016, Ard Biesheuvel wrote:

> When building an XIP kernel, the linker produces two disjoint VMA
> regions, where the first is mapped onto ROM and the second onto RAM.
> For this reason, the linker output pointer '.' is updated halfway
> through the linker script, and set to a value that corresponds with
> the start of the RAM region.
> 
> However, in some cases, the ROM region exceeds the expected size, and
> the assignment of the output pointer results in a decrement rather than
> an increment, causing the virtual addresses of the .data region to
> clash with the .text region. Such a kernel cannot boot normally, but it
> also confuses the hell out of kallsyms, since .data symbols may appear
> inside the [_stext, _etext] or [_sinittext, _einittext] intervals in
> the first pass, but not in the second (or vice versa), resulting in
> inconsistent kallsyms data.
> 
> So let's make sure that the output pointer only advances, and never
> jumps back into the ROM region.
> 
> Cc: Chris Brandt <Chris.Brandt at renesas.com>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
> v2: rebased onto the split off XIP linker script
> 
>  arch/arm/kernel/vmlinux-xip.lds.S | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
> index 40bc4cadb959..07c642cff50e 100644
> --- a/arch/arm/kernel/vmlinux-xip.lds.S
> +++ b/arch/arm/kernel/vmlinux-xip.lds.S
> @@ -213,6 +213,7 @@ SECTIONS
>  
>  	_exiprom = .;			/* End of XIP ROM area */
>  	__data_loc = ALIGN(4);		/* location in binary */
> +	ASSERT(. < PAGE_OFFSET + TEXT_OFFSET, "XIP_KERNEL: ROM and RAM 
> +overlap")
>  	. = PAGE_OFFSET + TEXT_OFFSET;
>  
>  	.data : AT(__data_loc) {
> --
> 2.5.0

This looks fine to me. I see no issues with it.
Of course, this is for systems with a much tighter device memory layout than what I usually use.

Chris



From rjw at rjwysocki.net  Tue Feb 16 11:20:32 2016
From: rjw at rjwysocki.net (Rafael J. Wysocki)
Date: Tue, 16 Feb 2016 20:20:32 +0100
Subject: [PATCH v6 1/2] ACPI: introduce a function to find the first
 physical device
In-Reply-To: <1455627160-10299-1-git-send-email-aleksey.makarov@linaro.org>
References: <2019009.4Y5n3ZF6bK@vostro.rjw.lan>
 <1455627160-10299-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <2136886.lSJtFgotV7@vostro.rjw.lan>

On Tuesday, February 16, 2016 03:52:38 PM Aleksey Makarov wrote:
> Factor out the code that finds the first physical device
> of a given ACPI device.  It is used in several places.
> 
> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>

OK, I've queued up this one and the [2/2] for v4.6.

Thanks,
Rafael



From tbaicar at codeaurora.org  Tue Feb 16 11:19:47 2016
From: tbaicar at codeaurora.org (Baicar, Tyler)
Date: Tue, 16 Feb 2016 12:19:47 -0700
Subject: [PATCH v2 1/2] efi: esrt: use memremap not ioremap to access ESRT
 table in memory
In-Reply-To: <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <56C37653.9060807@codeaurora.org>

On 2/15/2016 4:32 AM, Ard Biesheuvel wrote:
> On ARM and arm64, ioremap() and memremap() are not interchangeable like
> on x86, and the use of ioremap() on ordinary RAM is typically flagged
> as an error if the memory region being mapped is also covered by the
> linear mapping, since that would lead to aliases with conflicting
> cacheability attributes.
>
> Since what we are dealing with is not an I/O region with side effects,
> using ioremap() here is arguably incorrect anyway, so let's replace
> it with memremap instead. Also add a missing unmap on the success path,
> and drop a memblock_remove() call which does not belong here, this far
> into the boot sequence.
>
> Cc: Peter Jones <pjones at redhat.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

Tested-by: Tyler Baicar<tbaicar at codeaurora.org>

> ---
>   drivers/firmware/efi/esrt.c | 16 ++++++++--------
>   1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/firmware/efi/esrt.c b/drivers/firmware/efi/esrt.c
> index 22c5285f7705..f096a0a26dbd 100644
> --- a/drivers/firmware/efi/esrt.c
> +++ b/drivers/firmware/efi/esrt.c
> @@ -16,6 +16,7 @@
>   #include <linux/device.h>
>   #include <linux/efi.h>
>   #include <linux/init.h>
> +#include <linux/io.h>
>   #include <linux/kernel.h>
>   #include <linux/kobject.h>
>   #include <linux/list.h>
> @@ -385,15 +386,15 @@ static void cleanup_entry_list(void)
>   static int __init esrt_sysfs_init(void)
>   {
>   	int error;
> -	struct efi_system_resource_table __iomem *ioesrt;
> +	struct efi_system_resource_table *memesrt;
>   
>   	pr_debug("esrt-sysfs: loading.\n");
>   	if (!esrt_data || !esrt_data_size)
>   		return -ENOSYS;
>   
> -	ioesrt = ioremap(esrt_data, esrt_data_size);
> -	if (!ioesrt) {
> -		pr_err("ioremap(%pa, %zu) failed.\n", &esrt_data,
> +	memesrt = memremap(esrt_data, esrt_data_size, MEMREMAP_WB);
> +	if (!memesrt) {
> +		pr_err("memremap(%pa, %zu, MEMREMAP_WB) failed.\n", &esrt_data,
>   		       esrt_data_size);
>   		return -ENOMEM;
>   	}
> @@ -401,11 +402,12 @@ static int __init esrt_sysfs_init(void)
>   	esrt = kmalloc(esrt_data_size, GFP_KERNEL);
>   	if (!esrt) {
>   		pr_err("kmalloc failed. (wanted %zu bytes)\n", esrt_data_size);
> -		iounmap(ioesrt);
> +		memunmap(memesrt);
>   		return -ENOMEM;
>   	}
>   
> -	memcpy_fromio(esrt, ioesrt, esrt_data_size);
> +	memcpy(esrt, memesrt, esrt_data_size);
> +	memunmap(memesrt);
>   
>   	esrt_kobj = kobject_create_and_add("esrt", efi_kobj);
>   	if (!esrt_kobj) {
> @@ -432,8 +434,6 @@ static int __init esrt_sysfs_init(void)
>   	if (error)
>   		goto err_cleanup_list;
>   
> -	memblock_remove(esrt_data, esrt_data_size);
> -
>   	pr_debug("esrt-sysfs: loaded.\n");
>   
>   	return 0;
Thanks,
Tyler

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project



From geert at linux-m68k.org  Tue Feb 16 11:20:50 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 16 Feb 2016 20:20:50 +0100
Subject: [PATCH] ARM: fix __start_rodata_section_aligned on XIP
In-Reply-To: <20160216183809.GA26069@www.outflux.net>
References: <20160216183809.GA26069@www.outflux.net>
Message-ID: <CAMuHMdXuAkXqZ_09iF3ZCksPtWB-pm-9YtAOqw+E3KpFnoegug@mail.gmail.com>

Hi Kees,

On Tue, Feb 16, 2016 at 7:38 PM, Kees Cook <keescook at chromium.org> wrote:
> This fixes the build for both allnoconfig (!CONFIG_MMU) and with
> XIP_KERNEL (due to missing pieces in the linker script), as seen after
> both "ARM: 8502/1: mm: mark section-aligned portion of rodata NX" and
> "ARM: 8513/1: xip: Move XIP linking to a separate file".
>
> Reported-by: Russell King <linux at arm.linux.org.uk>
> Reported-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Kees Cook <keescook at chromium.org>

> diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
> index 40bc4cadb959..2da60cd1b295 100644
> --- a/arch/arm/kernel/vmlinux-xip.lds.S
> +++ b/arch/arm/kernel/vmlinux-xip.lds.S

> @@ -310,6 +311,17 @@ SECTIONS
>  }
>
>  /*
> + * Without CONFIG_DEBUG_ALIGN_RODATA, __start_rodata_section_aligned will
> + * be the first section-aligned location after __start_rodata. Otherwise,
> + * it will be equal to __start_rodata.
> + */
> +#ifdef CONFIG_MMU

CONFIG_DEBUG_ALIGN_RODATA or CONFIG_MMU?

> +__start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
> +#else
> +__start_rodata_section_aligned = __start_rodata;
> +#endif
> +
> +/*
>   * These must never be empty
>   * If you have to comment these two assert statements out, your
>   * binutils is too old (for other reasons as well)
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index 1707b9431761..f13960e44955 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -328,7 +328,11 @@ SECTIONS
>   * be the first section-aligned location after __start_rodata. Otherwise,
>   * it will be equal to __start_rodata.
>   */
> +#ifdef CONFIG_MMU

Likewise (the out-of-scope comment says CONFIG_DEBUG_ALIGN_RODATA)?

>  __start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
> +#else
> +__start_rodata_section_aligned = __start_rodata;
> +#endif

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From rjw at rjwysocki.net  Tue Feb 16 11:27:18 2016
From: rjw at rjwysocki.net (Rafael J. Wysocki)
Date: Tue, 16 Feb 2016 20:27:18 +0100
Subject: [PATCH v5 13/15] PM / Hibernate: Call flush_icache_range() on
 pages restored in-place
In-Reply-To: <1455637767-31561-14-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
 <1455637767-31561-14-git-send-email-james.morse@arm.com>
Message-ID: <2881465.GhJSKR2Hdf@vostro.rjw.lan>

On Tuesday, February 16, 2016 03:49:25 PM James Morse wrote:
> Some architectures require code written to memory as if it were data to be
> 'cleaned' from any data caches before the processor can fetch them as new
> instructions.
> 
> During resume from hibernate, the snapshot code copies some pages directly,
> meaning these architectures do not get a chance to perform their cache
> maintenance. Modify the read and decompress code to call
> flush_icache_range() on all pages that are restored, so that the restored
> in-place pages are guaranteed to be executable on these architectures.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> Acked-by: Pavel Machek <pavel at ucw.cz>

This is fine by me.

Please feel free to add my ACK to it if that helps.

Thanks,
Rafael



From stefan.wahren at i2se.com  Tue Feb 16 11:29:16 2016
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Tue, 16 Feb 2016 20:29:16 +0100 (CET)
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in
 console
In-Reply-To: <D4D8C3EE-7BDC-44F4-A54F-A6861FE0A174@martin.sperl.org>
References: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
 <56BC895E.2010108@sperl.org>
 <1617009200.323700.219000a8-c162-4594-aacc-a7e9894518b2.open-xchange@email.1und1.de>
 <662D2FB2-B088-4CFC-8416-A4F35BBAD7DD@sperl.org>
 <F7A2533A-D64C-4187-ABD4-416C446D1637@martin.sperl.org>
 <6CD3FC59-BA17-43D9-897C-A2D122D26EF8@martin.sperl.org>
 <470852136.382408.76a8faee-9235-4ee0-9fd1-e25a1e9f0bb3.open-xchange@email.1und1.de>
 <EE05C090-EB8A-41E8-B9C3-8CCC79F15FE9@martin.sperl.org>
 <359843746.379810.6eb6c2f5-8282-417a-83d1-1fa79425ff73.open-xchange@email.1und1.de>
 <D4D8C3EE-7BDC-44F4-A54F-A6861FE0A174@martin.sperl.org>
Message-ID: <43491797.472221.74f5f000-03c2-453a-a849-faa85305b11d.open-xchange@email.1und1.de>

Hi Martin,

> Martin Sperl <kernel at martin.sperl.org> hat am 16. Februar 2016 um 17:31
> geschrieben:
>
>
>
> > On 13.02.2016, at 21:45, Stefan Wahren <stefan.wahren at i2se.com> wrote:
> >
> >
> > According to the datasheet busy bit shouldn't be set while changing the
> > clock.
> > So this isn't good. I hope this could be fixed, too.
> >
>
> I had hoped that the patch by Eric:
> "clk: bcm2835: Fix setting of PLL divider clock rates"
> would fix the issue, but that was unfortunately not the case.
>
> Some more investigation using the debugfs patch I had posted,
> which exposes the registers showed that:
> plld_per_a2w had a value of 4 before starting getty
> and a value of 0 after starting getty.
>
> That made me investigate why this value was changed and I found
> the culprit in the form of:
> @@ -1167,7 +1171,9 @@ static void bcm2835_pll_divider_off(struct clk_hw *hw)
> cprman_write(cprman, data->cm_reg,
> (cprman_read(cprman, data->cm_reg) &
> ~data->load_mask) | data->hold_mask);
> - cprman_write(cprman, data->a2w_reg, A2W_PLL_CHANNEL_DISABLE);
> + cprman_write(cprman, data->a2w_reg,
> + cprman_read(cprman, data->a2w_reg) |
> + A2W_PLL_CHANNEL_DISABLE);
> }

good job. This change make sense because the divider value shouldn't be zero.

But maybe we should protect the RMW by a lock like in bcm2835_clock_off?

>
> after that (with plld itself marked as ?prepared? during probe) everything is
> working fine.
>
> bcm2835_pll_off shows a similar pattern, but patching that
> the same way:
> @@ -955,8 +955,12 @@ static void bcm2835_pll_off(struct clk_hw *hw)
> struct bcm2835_cprman *cprman = pll->cprman;
> const struct bcm2835_pll_data *data = pll->data;
>
> - cprman_write(cprman, data->cm_ctrl_reg, CM_PLL_ANARST);
> - cprman_write(cprman, data->a2w_ctrl_reg, A2W_PLL_CTRL_PWRDN);
> + cprman_write(cprman, data->cm_ctrl_reg,
> + cprman_read(cprman, data->cm_ctrl_reg) |
> + CM_PLL_ANARST);
> + cprman_write(cprman, data->a2w_ctrl_reg,
> + cprman_read(cprman, data->a2w_ctrl_reg) |
> + A2W_PLL_CTRL_PWRDN);
> }
>
> does not resolve the issue - the system crashes - but without he pll
> lock message?

Without the knowledge about the registers it's hard to say what exactly causes
the crash.

Regards
Stefan


From u.kleine-koenig at pengutronix.de  Tue Feb 16 11:35:35 2016
From: u.kleine-koenig at pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=)
Date: Tue, 16 Feb 2016 20:35:35 +0100
Subject: noise issues when recording sound on i.MX28
In-Reply-To: <CAOMZO5BDjkWi+cQK1-J7ag8Z48tY1Uwofi4EkovN-drSC4_reA@mail.gmail.com>
References: <20160127105613.GC13664@pengutronix.de>
 <CAOMZO5BpLen517q2heramSta-R6pdESkjM6w=7FRMZebY6ue-Q@mail.gmail.com>
 <20160127144340.GD13664@pengutronix.de>
 <CAOMZO5AE6HwBYz7kOFORt0HTojJLSb0MYUbkb_HCshDHy=d27g@mail.gmail.com>
 <20160210150315.GC13664@pengutronix.de>
 <CAOMZO5D5H4F90nse9kyW9KvsJStN-sCGktup4FDPw_zTeNfS2g@mail.gmail.com>
 <20160211084029.GE13664@pengutronix.de>
 <CAOMZO5BDjkWi+cQK1-J7ag8Z48tY1Uwofi4EkovN-drSC4_reA@mail.gmail.com>
Message-ID: <20160216193535.GB32169@pengutronix.de>

Hello Fabio,

On Tue, Feb 16, 2016 at 01:01:19PM -0200, Fabio Estevam wrote:
> On Thu, Feb 11, 2016 at 6:40 AM, Uwe Kleine-K?nig
> <u.kleine-koenig at pengutronix.de> wrote:
> 
> > root at hostname:/sys/kernel/debug/clk find -name saif?_sel
> > ./ref_xtal/pll0/saif0_sel
> > ./ref_xtal/pll0/saif1_sel
> >
> > root at hostname:/sys/kernel/debug/clk cat ./ref_xtal/pll0/saif?_sel/clk_rate
> > 480000000
> > 480000000
> 
> Ok, what about the SAIF0 and SAIF1 sampling rates: are they always the same?

Lothar found a recipe to reproduce. I didn't try, but it's something
along the lines of (Lothar please correct if I'm wrong):

 - start a recording on one SAIF
 - start playback on the other SAIF
 - using direct access to the registers stop and restart the playback
   SAIF via the RUN bit.

The program I have doesn't provide a reliable reproduction recipe, it
runs in a loop and sometimes need several (>1000) iterations to trigger.
In my setup the sampling rates don't change. The values of
BITCLK_MULT_RATE differ however in my setup, I don't see why though.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |


From paulmck at linux.vnet.ibm.com  Tue Feb 16 11:36:44 2016
From: paulmck at linux.vnet.ibm.com (Paul E. McKenney)
Date: Tue, 16 Feb 2016 11:36:44 -0800
Subject: Writes, smp_wmb(), and transitivity?
In-Reply-To: <CA+55aFxaQEvDrzecmZUQ5QfKzU4ei6E-+NpsW5hYp3ouaLP98g@mail.gmail.com>
References: <20160215175825.GA15878@linux.vnet.ibm.com>
 <CA+55aFxaQEvDrzecmZUQ5QfKzU4ei6E-+NpsW5hYp3ouaLP98g@mail.gmail.com>
Message-ID: <20160216193644.GV6719@linux.vnet.ibm.com>

On Tue, Feb 16, 2016 at 10:59:08AM -0800, Linus Torvalds wrote:
> On Mon, Feb 15, 2016 at 9:58 AM, Paul E. McKenney
> <paulmck at linux.vnet.ibm.com> wrote:
> >
> > Two threads:
> >
> >         int a, b;
> >
> >         void thread0(void)
> >         {
> >                 WRITE_ONCE(a, 1);
> >                 smp_wmb();
> >                 WRITE_ONCE(b, 2);
> >         }
> >
> >         void thread1(void)
> >         {
> >                 WRITE_ONCE(b, 1);
> >                 smp_wmb();
> >                 WRITE_ONCE(a, 2);
> >         }
> >
> >         /* After all threads have completed and the dust has settled... */
> >
> >         BUG_ON(a == 1 && b == 1);
> 
> So the more I look at that kind of litmus test, the less I think that
> we should care, because I can't come up with a scenario in where that
> kind of test makes sense. without even a possibility of any causal
> relationship between the two, I can't say why we'd ever care about the
> ordering of the (independent) writes to the individual variables.
> 
> If somebody can make up a causal chain, things differ. But as long as
> all the CPU's are just doing locally ordered writes, I don't think we
> need to care about a global store ordering.

Works for me!  (Yes, I can artificially generate a use case for this
thing, but all the ones I have come up with have some better and more
sane way to get the job done.  So I completely agree with your not caring
about it.)

So for transitivity, we focus on causal chains, where one task writes
to some variable that the next task reads.

In addition, if all threads use full memory barriers throughout, as in
smp_mb(), then full ordering is of course provided regardless of the
pattern of reads and writes.

							Thanx, Paul



From ddaney at caviumnetworks.com  Tue Feb 16 11:38:59 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Tue, 16 Feb 2016 11:38:59 -0800
Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <56C37524.5090000@caviumnetworks.com>
References: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160214170152.GC3965@htj.duckdns.org> <56C147B2.9010303@caviumnetworks.com>
 <20160215183041.GH3965@htj.duckdns.org>
 <20160216144250.GD31343@rric.localdomain>
 <56C37524.5090000@caviumnetworks.com>
Message-ID: <56C37AD3.4030407@caviumnetworks.com>

On 02/16/2016 11:14 AM, Tirumalesh Chalamarla wrote:
>
>
> On 02/16/2016 06:42 AM, Robert Richter wrote:
>> On 15.02.16 13:30:41, Tejun Heo wrote:
>>> On Sun, Feb 14, 2016 at 07:36:18PM -0800, Tirumalesh Chalamarla wrote:
>>>> There is no need for special Driver, AHCI is sufficient for
>>>> ThunderX, the
>>>> file only contains this interrupt handler,
>>>> is it preferable if this interrupt handler in libahci.c with others,
>>>> instead
>>>> of separate file?
>>>
>>> Yeap, just fold it in ahci.c with surrounding #ifdef guard.
>>
>> Yes, please use #ifdef CONFIG_CAVIUM_ERRATUM_22536 ... and add a
>> kconfig entry for this to arch/arm64/Kconfig.
>>
> Are you sure, this is not a workaround that is based on alternative
> framework rather on pci device and vendor
>
> do you think CONFIG_ARCH_THUNDER a good alternative?

No.  CONFIG_ARCH_THUNDER should be removed all together.

Grouping a bunch of unrelated features under a single config variable 
creates a very brittle system.  What are you going to do when a new 
hardware revision is released?  Create CONFIG_ARCH_THUNDER2?  Which one 
of these two would you select if building a kernel?  It is a choice that 
we don't want to force users (kernel builders) to have to waste mental 
energy on.

Instead, let's try to make things work out of the box without having to 
set a bunch of random config variables.

If a generic arm64 kernel won't get too bloated, I would suggest just 
enabling the compilation of the code unconditionally (at least for 
arm64).  The use of the code would still be gated by the PCI version 
probe that is part of the patch.

David Daney



From robert.jarzmik at free.fr  Tue Feb 16 11:40:21 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Tue, 16 Feb 2016 20:40:21 +0100
Subject: [PATCH] dmaengine: pxa_dma: fix cyclic transfers
Message-ID: <1455651621-3990-1-git-send-email-robert.jarzmik@free.fr>

While testing audio with pxa2xx-ac97, underrun were happening while the
user application was correctly feeding the music. Debug proved that the
cyclic transfer is not cyclic, ie. the last descriptor did not loop on
the first.

This was tested on a pxa27x platform.

Fixes: a57e16cf0333 ("dmaengine: pxa: add pxa dmaengine driver")
Reported-by: Vasily Khoruzhick <anarsoul at gmail.com> 
Tested-by: Vasily Khoruzhick <anarsoul at gmail.com> 
Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
 drivers/dma/pxa_dma.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index f2a0310ae771..ca6c088edc8a 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -583,6 +583,8 @@ static void set_updater_desc(struct pxad_desc_sw *sw_desc,
 		(PXA_DCMD_LENGTH & sizeof(u32));
 	if (flags & DMA_PREP_INTERRUPT)
 		updater->dcmd |= PXA_DCMD_ENDIRQEN;
+	if (sw_desc->cyclic)
+		sw_desc->hw_desc[sw_desc->nb_desc - 2]->ddadr = sw_desc->first;
 }
 
 static bool is_desc_completed(struct virt_dma_desc *vd)
@@ -673,6 +675,10 @@ static irqreturn_t pxad_chan_handler(int irq, void *dev_id)
 		dev_dbg(&chan->vc.chan.dev->device,
 			"%s(): checking txd %p[%x]: completed=%d\n",
 			__func__, vd, vd->tx.cookie, is_desc_completed(vd));
+		if (to_pxad_sw_desc(vd)->cyclic) {
+			vchan_cyclic_callback(vd);
+			break;
+		}
 		if (is_desc_completed(vd)) {
 			list_del(&vd->node);
 			vchan_cookie_complete(vd);
-- 
2.1.4



From tchalamarla at caviumnetworks.com  Tue Feb 16 11:50:44 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Tue, 16 Feb 2016 11:50:44 -0800
Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <56C37AD3.4030407@caviumnetworks.com>
References: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160214170152.GC3965@htj.duckdns.org> <56C147B2.9010303@caviumnetworks.com>
 <20160215183041.GH3965@htj.duckdns.org>
 <20160216144250.GD31343@rric.localdomain>
 <56C37524.5090000@caviumnetworks.com> <56C37AD3.4030407@caviumnetworks.com>
Message-ID: <56C37D94.8080403@caviumnetworks.com>



On 02/16/2016 11:38 AM, David Daney wrote:
> On 02/16/2016 11:14 AM, Tirumalesh Chalamarla wrote:
>>
>>
>> On 02/16/2016 06:42 AM, Robert Richter wrote:
>>> On 15.02.16 13:30:41, Tejun Heo wrote:
>>>> On Sun, Feb 14, 2016 at 07:36:18PM -0800, Tirumalesh Chalamarla wrote:
>>>>> There is no need for special Driver, AHCI is sufficient for
>>>>> ThunderX, the
>>>>> file only contains this interrupt handler,
>>>>> is it preferable if this interrupt handler in libahci.c with others,
>>>>> instead
>>>>> of separate file?
>>>>
>>>> Yeap, just fold it in ahci.c with surrounding #ifdef guard.
>>>
>>> Yes, please use #ifdef CONFIG_CAVIUM_ERRATUM_22536 ... and add a
>>> kconfig entry for this to arch/arm64/Kconfig.
>>>
>> Are you sure, this is not a workaround that is based on alternative
>> framework rather on pci device and vendor
>>
>> do you think CONFIG_ARCH_THUNDER a good alternative?
>
> No.  CONFIG_ARCH_THUNDER should be removed all together.
>
> Grouping a bunch of unrelated features under a single config variable
> creates a very brittle system.  What are you going to do when a new
> hardware revision is released?  Create CONFIG_ARCH_THUNDER2?  Which one
> of these two would you select if building a kernel?  It is a choice that
> we don't want to force users (kernel builders) to have to waste mental
> energy on.
>
> Instead, let's try to make things work out of the box without having to
> set a bunch of random config variables.
>
> If a generic arm64 kernel won't get too bloated, I would suggest just
> enabling the compilation of the code unconditionally (at least for
> arm64).  The use of the code would still be gated by the PCI version
> probe that is part of the patch.
>

exactly, that is my initial choice with v1, and only depends on vendor 
and device id.

but it seems a config is needed. how about ARCH_ARM64 then?

Thanks,
Tirumalesh.

> David Daney
>


From marc.zyngier at arm.com  Tue Feb 16 12:05:29 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 16 Feb 2016 20:05:29 +0000
Subject: [PATCH 0/8] KVM/ARM: Guest Entry/Exit optimizations
In-Reply-To: <20160210204012.GS5171@cbox>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <20160210204012.GS5171@cbox>
Message-ID: <56C38109.3020501@arm.com>

On 10/02/16 20:40, Christoffer Dall wrote:
> On Mon, Feb 08, 2016 at 11:40:14AM +0000, Marc Zyngier wrote:
>> I've recently been looking at our entry/exit costs, and profiling
>> figures did show some very low hanging fruits.
>>
>> The most obvious cost is that accessing the GIC HW is slow. As in
>> "deadly slow", specially when GICv2 is involved. So not hammering the
>> HW when there is nothing to write is immediately beneficial, as this
>> is the most common cases (whatever people seem to think, interrupts
>> are a *rare* event).
>>
>> Another easy thing to fix is the way we handle trapped system
>> registers. We do insist on (mostly) sorting them, but we do perform a
>> linear search on trap. We can switch to a binary search for free, and
>> get immediate benefits (the PMU code, being extremely trap-happy,
>> benefits immediately from this).
>>
>> With these in place, I see an improvement of 20 to 30% (depending on
>> the platform) on our world-switch cycle count when running a set of
>> hand-crafted guests that are designed to only perform traps.
>>
> 
> By the way, I took this whole stack of changes (wsinc, vhe, and
> optimizations) and ran it on Mustang and fired up UEFI and did a reboot
> and things seem to work, so that's a small shallow
> 'tested-by-something-else-than-a-linux-guest' statement from me.

I've ran a slightly heavier set of tests, and the infamous reboot loop
broke, thanks to patch #7.

Notice how we fail to wipe the vgic_apr copy on the "light" exit path?
If you're unlucky (and odds are that you will be), you will inject an
interrupt while its active priority bit is set, and the new interrupt
won't be delivered. Bah.

With that fixed, the reboot loop has been going strong for a few hours.
I'll leave my Seattle cooking overnight and if everything looks good in
the morning, I'll repost a new set of patches.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From tchalamarla at caviumnetworks.com  Tue Feb 16 12:08:49 2016
From: tchalamarla at caviumnetworks.com (tchalamarla at caviumnetworks.com)
Date: Tue, 16 Feb 2016 12:08:49 -0800
Subject: [PATCH V3] AHCI: Workaround for ThunderX Errata#22536
Message-ID: <1455653329-4934-1-git-send-email-tchalamarla@caviumnetworks.com>

From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>

Due to Errata in ThunderX, HOST_IRQ_STAT should be
cleared before leaving the interrupt handler.
The patch attempts to satisfy the need.

Changes from V2:
	- removed newfile
	- code is now under CONFIG_ARM64

Changes from V1:
	- Rebased on top of libata/for-4.6
        - Moved ThunderX intr handler to new file

Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
---
 drivers/ata/ahci.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 546a369..c8496fc 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1325,6 +1325,44 @@ static inline void ahci_gtf_filter_workaround(struct ata_host *host)
 {}
 #endif
 
+#ifdef CONFIG_ARM64
+/* Due to ERRATA#22536, ThunderX need to handle
+ * HOST_IRQ_STAT differently.
+ * Work around is to make sure all pending IRQs
+ * are served before leaving handler
+ */
+static irqreturn_t ahci_thunderx_irq_handler(int irq, void *dev_instance)
+{
+	struct ata_host *host = dev_instance;
+	struct ahci_host_priv *hpriv;
+	unsigned int rc = 0;
+	void __iomem *mmio;
+	u32 irq_stat, irq_masked;
+	unsigned int handled = 1;
+
+	VPRINTK("ENTER\n");
+	hpriv = host->private_data;
+	mmio = hpriv->mmio;
+	irq_stat = readl(mmio + HOST_IRQ_STAT);
+	if (!irq_stat)
+		return IRQ_NONE;
+
+	do {
+		irq_masked = irq_stat & hpriv->port_map;
+		spin_lock(&host->lock);
+		rc = ahci_handle_port_intr(host, irq_masked);
+		if (!rc)
+			handled = 0;
+		writel(irq_stat, mmio + HOST_IRQ_STAT);
+		irq_stat = readl(mmio + HOST_IRQ_STAT);
+		spin_unlock(&host->lock);
+	} while (irq_stat);
+	VPRINTK("EXIT\n");
+
+	return IRQ_RETVAL(handled);
+}
+#endif
+
 /*
  * ahci_init_msix() - optionally enable per-port MSI-X otherwise defer
  * to single msi.
@@ -1560,6 +1598,12 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 	if (ahci_broken_devslp(pdev))
 		hpriv->flags |= AHCI_HFLAG_NO_DEVSLP;
 
+#ifdef CONFIG_ARM64
+	/* this should be done before save config*/
+	if (pdev->vendor == 0x177d && pdev->device == 0xa01c)
+		hpriv->irq_handler = ahci_thunderx_irq_handler;
+#endif
+
 	/* save initial config */
 	ahci_pci_save_initial_config(pdev, hpriv);
 
-- 
2.1.0



From thomas.petazzoni at free-electrons.com  Tue Feb 16 12:09:09 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Feb 2016 21:09:09 +0100
Subject: [PATCH v3 0/6] irqchip: irq-armada-370-xp: generic MSI
 infrastructure and assorted fixes
In-Reply-To: <20160216174937.GF5183@io.lakedaemon.net>
References: <1455115621-22846-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160216174937.GF5183@io.lakedaemon.net>
Message-ID: <20160216210909.09f7f685@free-electrons.com>

Hello,

On Tue, 16 Feb 2016 17:49:37 +0000, Jason Cooper wrote:

> > Note that this patch series depends on the patch series from Marc
> > Zyngier for proper operation, which have already been merged in
> > tip.git by Thomas Gleixner:
> > 
> >   http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=530cbe100ef7587aa5b5ac3a4b670cda4d50e598
> >   http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=14a0db3cdd114da757197193f66786e63649c91e
> 
> When based against v4.5-rc1, I encountered:
> 
> drivers/irqchip/irq-armada-370-xp.c:584:41: error: 'DOMAIN_BUS_WIRED' undeclared (first use in this function)
> 
> Rebased the branch against v4.5-rc2 to pick up:
> 
>   530cbe100ef7 irqdomain: Allow domain lookup with DOMAIN_BUS_WIRED token
> 
> Which builds without warning.

Indeed. See above where I was mentioning which commits I was depending
on.

> >  arch/arm/mach-mvebu/Kconfig         |   6 +-
> >  drivers/irqchip/Kconfig             |   6 ++
> >  drivers/irqchip/Makefile            |   2 +-
> >  drivers/irqchip/irq-armada-370-xp.c | 156 +++++++++++++++---------------------
> >  4 files changed, 78 insertions(+), 92 deletions(-)
> 
> Whole series applied to irqchip/mvebu which will not be rebased.  I'll
> only append to it if you send me a patch to add.  ;-)

Thanks for the merge!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From davem at davemloft.net  Tue Feb 16 12:10:33 2016
From: davem at davemloft.net (David Miller)
Date: Tue, 16 Feb 2016 15:10:33 -0500 (EST)
Subject: [PATCH] net: am79c961a: avoid %? in inline assembly
In-Reply-To: <1454942025-2779812-1-git-send-email-arnd@arndb.de>
References: <1454942025-2779812-1-git-send-email-arnd@arndb.de>
Message-ID: <20160216.151033.337771595038699408.davem@davemloft.net>

From: Arnd Bergmann <arnd at arndb.de>
Date: Mon,  8 Feb 2016 15:33:42 +0100

> The am79c961a.c driver fails to build with clang because of an
> unusual inline assembly construct:
> 
> drivers/net/ethernet/amd/am79c961a.c:53:7: error: invalid % escape in inline assembly string
>  "str%?h        %1, [%2]        @ NET_RAP\n\t"
> 
> The same change has been done a decade ago in arch/arm as of
> 6a39dd6222dd ("[ARM] 3759/2: Remove uses of %?"), but apparently
> some drivers were missed.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Applied, thanks.


From pavel at ucw.cz  Tue Feb 16 12:15:57 2016
From: pavel at ucw.cz (Pavel Machek)
Date: Tue, 16 Feb 2016 21:15:57 +0100
Subject: [PATCH v5 15/15] arm64: hibernate: Prevent resume from a
 different kernel version
In-Reply-To: <1455637767-31561-16-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
 <1455637767-31561-16-git-send-email-james.morse@arm.com>
Message-ID: <20160216201557.GA6526@amd>

On Tue 2016-02-16 15:49:27, James Morse wrote:
> Resuming using a different kernel version is fragile, while there are
> sufficient details in the hibernate arch-header to perform the restore,
> changes in the boot process can have a long-lasting impact on the system.
> In particular, if the EFI stub causes more memory to be allocated, the
> amount of memory left for linux is reduced. If we are lucky, this will
> cause restore to fail with the message:

Well, this does not close the door completely. 4.6-rc0 is going to be
very different from 4.6-rc1. Better solution would be to increase
version every time EFI stub changes, or maybe record ammount of memory
reserved for EFI.

Best regards,
									Pavel
									
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From keescook at chromium.org  Tue Feb 16 12:16:30 2016
From: keescook at chromium.org (Kees Cook)
Date: Tue, 16 Feb 2016 12:16:30 -0800
Subject: [PATCH] ARM: fix __start_rodata_section_aligned on XIP
In-Reply-To: <CAMuHMdXuAkXqZ_09iF3ZCksPtWB-pm-9YtAOqw+E3KpFnoegug@mail.gmail.com>
References: <20160216183809.GA26069@www.outflux.net>
 <CAMuHMdXuAkXqZ_09iF3ZCksPtWB-pm-9YtAOqw+E3KpFnoegug@mail.gmail.com>
Message-ID: <CAGXu5j+8LtBjxBms1qjWHSvyVc_2ajp8QxGOc_Ca+gze7ib=Rg@mail.gmail.com>

On Tue, Feb 16, 2016 at 11:20 AM, Geert Uytterhoeven
<geert at linux-m68k.org> wrote:
> Hi Kees,
>
> On Tue, Feb 16, 2016 at 7:38 PM, Kees Cook <keescook at chromium.org> wrote:
>> This fixes the build for both allnoconfig (!CONFIG_MMU) and with
>> XIP_KERNEL (due to missing pieces in the linker script), as seen after
>> both "ARM: 8502/1: mm: mark section-aligned portion of rodata NX" and
>> "ARM: 8513/1: xip: Move XIP linking to a separate file".
>>
>> Reported-by: Russell King <linux at arm.linux.org.uk>
>> Reported-by: Arnd Bergmann <arnd at arndb.de>
>> Signed-off-by: Kees Cook <keescook at chromium.org>
>
>> diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
>> index 40bc4cadb959..2da60cd1b295 100644
>> --- a/arch/arm/kernel/vmlinux-xip.lds.S
>> +++ b/arch/arm/kernel/vmlinux-xip.lds.S
>
>> @@ -310,6 +311,17 @@ SECTIONS
>>  }
>>
>>  /*
>> + * Without CONFIG_DEBUG_ALIGN_RODATA, __start_rodata_section_aligned will
>> + * be the first section-aligned location after __start_rodata. Otherwise,
>> + * it will be equal to __start_rodata.
>> + */
>> +#ifdef CONFIG_MMU
>
> CONFIG_DEBUG_ALIGN_RODATA or CONFIG_MMU?
>
>> +__start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);

CONFIG_MMU controls the availability of SECTION_SHIFT, so I used that.
Either will work, since without CONFIG_DEBUG_ALIGN_RODATA, the values
will end up being identical, as in the #else.

Though it looks like XIP_KERNEL should kill all of the
CONFIG_DEBUG_*RODATA defines anyway. I think we need a different
version of this combined with the patch from Ard...

-Kees

>> +#else
>> +__start_rodata_section_aligned = __start_rodata;
>> +#endif
>> +
>> +/*
>>   * These must never be empty
>>   * If you have to comment these two assert statements out, your
>>   * binutils is too old (for other reasons as well)
>> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
>> index 1707b9431761..f13960e44955 100644
>> --- a/arch/arm/kernel/vmlinux.lds.S
>> +++ b/arch/arm/kernel/vmlinux.lds.S
>> @@ -328,7 +328,11 @@ SECTIONS
>>   * be the first section-aligned location after __start_rodata. Otherwise,
>>   * it will be equal to __start_rodata.
>>   */
>> +#ifdef CONFIG_MMU
>
> Likewise (the out-of-scope comment says CONFIG_DEBUG_ALIGN_RODATA)?
>
>>  __start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
>> +#else
>> +__start_rodata_section_aligned = __start_rodata;
>> +#endif
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds



-- 
Kees Cook
Chrome OS & Brillo Security


From nicolas.pitre at linaro.org  Tue Feb 16 12:16:35 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 16 Feb 2016 15:16:35 -0500 (EST)
Subject: [PATCH v2] ARM: proc-v7.S: Adjust stack address when
 XIP_KERNEL
In-Reply-To: <20160216173225.GE19428@n2100.arm.linux.org.uk>
References: <1454105474-3009-1-git-send-email-chris.brandt@renesas.com>
 <1454335736-10084-1-git-send-email-chris.brandt@renesas.com>
 <alpine.LFD.2.20.1602011613360.32766@knanqh.ubzr>
 <20160216173225.GE19428@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.20.1602161504400.13632@knanqh.ubzr>

On Tue, 16 Feb 2016, Russell King - ARM Linux wrote:

> > > index 0f92d57..1595fb2 100644
> > > --- a/arch/arm/mm/proc-v7.S
> > > +++ b/arch/arm/mm/proc-v7.S
> > > @@ -487,7 +487,7 @@ __errata_finish:
> > >  
> > >  	.align	2
> > >  __v7_setup_stack_ptr:
> > > -	.word	__v7_setup_stack - .
> > > +	.word	__v7_setup_stack - . + PHYS_OFFSET_FIXUP
> 
> I keep looking at this patch, and I really find that I detest this
> PHYS_OFFSET_FIXUP thing - it's really not obvious what's going on
> here.  It's taken a _long_ time to work this out, which _really_
> isn't good going forward.
> 
> Let's instead change things to make it much more obvious - see the
> patch below.
> 
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index ebdaaf7dd19f..593e5613184d 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -135,11 +135,18 @@
>  #define PLAT_PHYS_OFFSET	UL(CONFIG_PHYS_OFFSET)
>  
>  #ifdef CONFIG_XIP_KERNEL
> -#define PHYS_OFFSET_FIXUP \
> -	( XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR) - PAGE_OFFSET + \
> -	  PLAT_PHYS_OFFSET - CONFIG_XIP_PHYS_ADDR )
> +/*
> + * When referencing data in RAM from the XIP region in a relative manner
> + * with the MMU off, we need the relative offset between the two physical
> + * addresses.  The macro below achieves this, which is:
> + *    __pa(v_data) - __xip_pa(v_text)
> + */
> +#define PHYS_RELATIVE(v_data, v_text) \
> +	(((v_data) - PAGE_OFFSET + PLAT_PHYS_OFFSET) - \
> +	 ((v_text) - XIP_VIRT_ADDR(CONFIG_XIP_PHYS_ADDR) + \
> +          CONFIG_XIP_PHYS_ADDR))

Sure, this is less opaque.

>  #else
> -#define PHYS_OFFSET_FIXUP 0
> +#define PHYS_RELATIVE(v_data, v_text) (v_data) - (v_text)

You should probably surround the whole thing with parents in case this 
gets used in some other computations.


Nicolas


From herbert at gondor.apana.org.au  Tue Feb 16 12:21:36 2016
From: herbert at gondor.apana.org.au (Herbert Xu)
Date: Tue, 16 Feb 2016 20:21:36 +0000
Subject: [PATCH 0/2] crypto: atmel-sha - fix .import()/.export()
 implementation
In-Reply-To: <cover.1454944687.git.cyrille.pitchen@atmel.com>
References: <cover.1454944687.git.cyrille.pitchen@atmel.com>
Message-ID: <20160216202136.GG11908@gondor.apana.org.au>

On Mon, Feb 08, 2016 at 04:26:47PM +0100, Cyrille Pitchen wrote:
> This series of patches includes two fixes for the atmel-sha.c driver.
> 
> The first one fixes the implementation of the import/export hooks, which
> did not pass the recent updates in testmgr.c (partial update exercise).
> The new implementation now passes the tcrypt tests: tested with
> next-20160208.
> 
> The second patch fixes a race condition if acquiring the hardware when it
> is already busy.

All applied.
-- 
Email: Herbert Xu <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


From mturquette at baylibre.com  Tue Feb 16 11:40:04 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Tue, 16 Feb 2016 11:40:04 -0800
Subject: breaking DT compatibility (was: Re: [PATCH v4] clk: sunxi:
 Refactor A31 PLL6 so that it can be reused)
In-Reply-To: <20160216084448.GE4344@lukather>
References: <1454358000-13594-1-git-send-email-maxime.ripard@free-electrons.com>
 <56BB2D79.6090402@arm.com>
 <CABGGiswOKztmRT40w4t_7BD729WgM8ueLtOD-UF_wgMbmcg4cg@mail.gmail.com>
 <20160210143755.GE31506@lukather> <20160210163001.GG2632@leverpostej>
 <20160211100048.GK31506@lukather> <20160211114410.GA32535@leverpostej>
 <20160211170820.GP31506@lukather> <1455270030.3201.71.camel@pengutronix.de>
 <20160216084448.GE4344@lukather>
Message-ID: <20160216194004.2278.85138@quark.deferred.io>

Quoting Maxime Ripard (2016-02-16 00:44:48)
> On Fri, Feb 12, 2016 at 10:40:30AM +0100, Lucas Stach wrote:
> > Am Donnerstag, den 11.02.2016, 18:08 +0100 schrieb Maxime Ripard:
> > [...]
> > > > > > Having code in mainline comes with responsibilities. One of those is to
> > > > > > keep said code working for existing users. Otherwise, why bother having
> > > > > > it in mainline at all?
> > > > > 
> > > > > None of our existing users ever complained.
> > > > 
> > > > I believe that in this case, Andre was complaining about this particular
> > > > breakage, unless I have misunderstood.
> > > > 
> > > > To be clear, I'm arguing for the strategy going forward. If no-one has
> > > > complained about the stuff broken up to this point, let's not waste time
> > > > restoring that.
> > > > 
> > > > Going forward we need to keep old DTBs supported.
> > > 
> > > I find that stand a bit dishonest.
> > > 
> > > You, DT maintainers, admit that you're not doing your job properly,
> > > and that burden relies on the platform maintainers? Or should I take
> > > it as you volunteering to maintain that code?
> > > 
> > > But ok. Let's do that. Make sure that the other platform maintainers
> > > are aware that this is the rule too though. I surely don't want to be
> > > alone in that boat.
> > 
> > FWIW: I always thought it's the platform maintainers job to enforce a
> > reasonable level of DT stability. I don't see how the DT maintainers
> > could provide the necessary in-depth review with every platform being
> > different in many subtle ways.
> > 
> > For the i.MX platform we actually enforced a baseline of DT stability by
> > shooting down patches that break DT stability for the sake of adding new
> > features, or when trying to put "fixes" into the DT, that could be
> > solved entirely inside the kernel.
> > 
> > Yes, mistakes happen and and we can not really prevent all breakage,
> > especially when the bindings were not strictly enough defined and board
> > DT writers may have interpreted them differently, but it is definitely
> > possible to keep DTs reasonably stable if the platform maintainers care
> > about that.
> > 
> > I strongly disagree with platform maintainers denying that duty, by
> > claiming that DTs won't be completely stable ever, so there is no reason
> > to even care.
> 
> A DT is either stable or not. If it is "reasonably" stable, then it's
> not.

Hi all,

I thought I'd pour some gasoline on this fire.

I'm happy for the one-node-per-clock bindings to be fully converted to a
clock-controller style binding, which is a clear compatibility break. In
other words, clock-cells = 0 bindings converted to clock-cells >= 1.

We really didn't have a clue about good DT bindings for a while, and
everyone keeps talking about being reasonable, etc. So with that in
mind, I propose that any clock binding written before 2015 should be
given amnesty to make these incompatible changes, so long as the
platform maintainers consent. Those stakeholders for sunxi are Maxime
Ripard, Chen-Yu Tsai and Emilio L?pez.

/me puts on flame retardant suit.

To be clear, I'm not in the business of telling SoCs to break
compatibility. That is thankfully not my choice to make and any platform
maintainer should have a long, difficult struggle when making that
decision. But I am supportive of merging those changes for clock
provider drivers if the platform maintainer decides to do so.

Regards,
Mike

> 
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com


From tbaicar at codeaurora.org  Tue Feb 16 12:25:55 2016
From: tbaicar at codeaurora.org (Baicar, Tyler)
Date: Tue, 16 Feb 2016 13:25:55 -0700
Subject: [PATCH v2 2/2] arm64/efi: esrt: add missing call to
 efi_esrt_init()
In-Reply-To: <1455535953-5056-3-git-send-email-ard.biesheuvel@linaro.org>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-3-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <56C385D3.3090308@codeaurora.org>

On 2/15/2016 4:32 AM, Ard Biesheuvel wrote:
> ESRT support is built by default for all architectures that define
> CONFIG_EFI. However, this support was not wired up yet for ARM/arm64,
> since efi_esrt_init() was never called. So add the missing call.
>
> Since efi_esrt_init() uses efi_mem_desc_lookup(), which in turn relies
> on efi.memmap having been assigned and populated completetely, add the
> missing assignments of efi.memmap and efi.memmap->nr_map.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
>   drivers/firmware/efi/arm-init.c | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
> index 9e15d571b53c..5c5e799bdb50 100644
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@ -197,10 +197,13 @@ void __init efi_init(void)
>   	memmap.map_end = memmap.map + params.mmap_size;
>   	memmap.desc_size = params.desc_size;
>   	memmap.desc_version = params.desc_ver;
> +	memmap.nr_map = params.mmap_size / params.desc_size;
> +	efi.memmap = &memmap;
>   
>   	if (uefi_init() < 0)
>   		return;
>   
> +	efi_esrt_init();
This call to efi_esrt_init() is failing because efi.flags does not have 
EFI_MEMMAP set. This flag gets set at the end of reserve_regions(). I 
tested moving the set_bit() call from reserve_regions() to just before 
efi_esrt_init() and also tested moving efi_esrt_init() to just after 
reserve_regions(). Both of these options worked.
>   	reserve_regions();
>   	early_memunmap(memmap.map, params.mmap_size);
>   	memblock_mark_nomap(params.mmap & PAGE_MASK,
Thanks,
Tyler

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project



From keescook at chromium.org  Tue Feb 16 12:29:57 2016
From: keescook at chromium.org (Kees Cook)
Date: Tue, 16 Feb 2016 12:29:57 -0800
Subject: [PATCH] ARM: drop unused DEBUG_RODATA from XIP_KERNEL
Message-ID: <20160216202957.GA1826@www.outflux.net>

With CONFIG_DEBUG_RODATA not being sensible under XIP_KERNEL, remove it
from the XIP linker script.

Signed-off-by: Kees Cook <keescook at chromium.org>
---
Effectively the patch after Arnd's "ARM: mm: hide
__start_rodata_section_aligned for non-debug builds"
---
 arch/arm/kernel/vmlinux-xip.lds.S | 10 ----------
 1 files changed, 0 insertions(+), 10 deletions(-)

diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
index 40bc4cadb959..cba1ec899a69 100644
--- a/arch/arm/kernel/vmlinux-xip.lds.S
+++ b/arch/arm/kernel/vmlinux-xip.lds.S
@@ -8,9 +8,6 @@
 #include <asm/thread_info.h>
 #include <asm/memory.h>
 #include <asm/page.h>
-#ifdef CONFIG_DEBUG_RODATA
-#include <asm/pgtable.h>
-#endif
 
 #define PROC_INFO							\
 	. = ALIGN(4);							\
@@ -92,10 +89,6 @@ SECTIONS
 		HEAD_TEXT
 	}
 
-#ifdef CONFIG_DEBUG_RODATA
-	. = ALIGN(1<<SECTION_SHIFT);
-#endif
-
 	.text : {			/* Real text segment		*/
 		_stext = .;		/* Text and read-only data	*/
 			IDMAP_TEXT
@@ -115,9 +108,6 @@ SECTIONS
 			ARM_CPU_KEEP(PROC_INFO)
 	}
 
-#ifdef CONFIG_DEBUG_RODATA
-	. = ALIGN(1<<SECTION_SHIFT);
-#endif
 	RO_DATA(PAGE_SIZE)
 
 	. = ALIGN(4);
-- 
2.6.3


-- 
Kees Cook
Chrome OS & Brillo Security


From keescook at chromium.org  Tue Feb 16 12:31:16 2016
From: keescook at chromium.org (Kees Cook)
Date: Tue, 16 Feb 2016 12:31:16 -0800
Subject: [PATCH 1/2] ARM: mm: DEBUG_RODATA makes no sense with XIP_KERNEL
In-Reply-To: <1455638631-3326518-1-git-send-email-arnd@arndb.de>
References: <1455638631-3326518-1-git-send-email-arnd@arndb.de>
Message-ID: <CAGXu5jJg4SqrHdJsB-5AzcQbNR-hDZv6YsWayf7LefO+ng4Qhg@mail.gmail.com>

On Tue, Feb 16, 2016 at 8:03 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> When CONFIG_DEBUG_ALIGN_RODATA is set, we get a link error:
>
> arch/arm/mm/built-in.o:(.data+0x4bc): undefined reference to `__start_rodata_section_aligned'
>
> However, this combination is useless, as XIP_KERNEL implies that all the
> RODATA is already marked readonly, so both CONFIG_DEBUG_RODATA and
> CONFIG_DEBUG_ALIGN_RODATA (which depends on the other) are not
> needed with XIP_KERNEL, and this patches enforces that using a Kconfig
> dependency.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 25362dc496ed ("ARM: 8501/1: mm: flip priority of CONFIG_DEBUG_RODATA")

For this and the 2/2 patch:

Acked-by: Kees Cook <keescook at chromium.org>

I've sent follow-up to clean up the XIP linker script too, if you want
to take that as the 3rd patch in this series of fixes.

-Kees

> ---
>  arch/arm/mm/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index fbf2296388ce..8894045caba9 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -1039,7 +1039,7 @@ config ARCH_SUPPORTS_BIG_ENDIAN
>
>  config DEBUG_RODATA
>         bool "Make kernel text and rodata read-only"
> -       depends on MMU
> +       depends on MMU && !XIP_KERNEL
>         default y if CPU_V7
>         help
>           If this is set, kernel text and rodata memory will be made
> --
> 2.7.0
>



-- 
Kees Cook
Chrome OS & Brillo Security


From keescook at chromium.org  Tue Feb 16 12:35:42 2016
From: keescook at chromium.org (Kees Cook)
Date: Tue, 16 Feb 2016 12:35:42 -0800
Subject: [PATCH] arm64: mm: Mark .rodata as RO
In-Reply-To: <56C36EFF.9060900@labbott.name>
References: <1455293599-6974-1-git-send-email-jeremy.linton@arm.com>
 <20160212182527.GG20262@leverpostej>
 <CAGXu5jLpj=ue49_N+LOYvtZcU3rpFR5=WTG15ySDOWprvRzFUA@mail.gmail.com>
 <56C36EFF.9060900@labbott.name>
Message-ID: <CAGXu5j+4uYjTjULw7hzdaYhN+JGqtybEpyT2Cihuj-2gXe=saA@mail.gmail.com>

On Tue, Feb 16, 2016 at 10:48 AM, Laura Abbott <laura at labbott.name> wrote:
> On 2/16/16 10:10 AM, Kees Cook wrote:
>>
>> On Fri, Feb 12, 2016 at 10:25 AM, Mark Rutland <mark.rutland at arm.com>
>> wrote:
>>>
>>> On Fri, Feb 12, 2016 at 10:13:19AM -0600, Jeremy Linton wrote:
>>>>
>>>> Currently the .rodata section is actually still executable when
>>>> DEBUG_RODATA
>>>> is enabled. This changes that so the .rodata is actually read only, no
>>>> execute.
>>>>
>>>> Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
>>
>>
>> Yikes, good catch. Is anyone running the lkdtm tests that check these
>> things?
>>
>
> I don't think the current lkdtm test would have caught this since the exec
> test is using rw data and not ro data. That test could be expanded though
> to include a rodata buffer as well.

Oh, yeah, excellent point. I'll send a patch.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security


From davem at davemloft.net  Tue Feb 16 12:37:58 2016
From: davem at davemloft.net (David Miller)
Date: Tue, 16 Feb 2016 15:37:58 -0500 (EST)
Subject: [PATCH] bridge: mdb: avoid uninitialized variable warning
In-Reply-To: <1455116946-2948649-1-git-send-email-arnd@arndb.de>
References: <1455116946-2948649-1-git-send-email-arnd@arndb.de>
Message-ID: <20160216.153758.1508523820142527071.davem@davemloft.net>

From: Arnd Bergmann <arnd at arndb.de>
Date: Wed, 10 Feb 2016 16:09:02 +0100

> A recent change to the mdb code confused the compiler to the point
> where it did not realize that the port-group returned from
> br_mdb_add_group() is always valid when the function returns a nonzero
> return value, so we get a spurious warning:
> 
> net/bridge/br_mdb.c: In function 'br_mdb_add':
> net/bridge/br_mdb.c:542:4: error: 'pg' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>     __br_mdb_notify(dev, entry, RTM_NEWMDB, pg);
> 
> Slightly rearranging the code in br_mdb_add_group() makes the problem
> go away, as gcc is clever enough to see that both functions check
> for 'ret != 0'.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 9e8430f8d60d ("bridge: mdb: Passing the port-group pointer to br_mdb module")

Applied, thanks Arnd.


From niklas.soderlund+renesas at ragnatech.se  Tue Feb 16 12:39:39 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Tue, 16 Feb 2016 21:39:39 +0100
Subject: [PATCH v4 3/8] dma-mapping: add dma_{map,unmap}_resource
In-Reply-To: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455655184-14478-4-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Map/Unmap a device resource from a physical address. If no dma_map_ops
method is available the operation is a no-op.

Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
---
 include/linux/dma-mapping.h | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index e3aba4e..cc305d1 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -216,6 +216,38 @@ static inline void dma_unmap_page(struct device *dev, dma_addr_t addr,
 	debug_dma_unmap_page(dev, addr, size, dir, false);
 }
 
+static inline dma_addr_t dma_map_resource(struct device *dev,
+					  phys_addr_t phys_addr,
+					  size_t size,
+					  enum dma_data_direction dir,
+					  struct dma_attrs *attrs)
+{
+	struct dma_map_ops *ops = get_dma_ops(dev);
+	unsigned long pfn = __phys_to_pfn(phys_addr);
+
+	BUG_ON(!valid_dma_direction(dir));
+
+	/* Don't allow RAM to be mapped */
+	BUG_ON(pfn_valid(pfn));
+
+	if (ops->map_resource)
+		return ops->map_resource(dev, phys_addr, size, dir, attrs);
+
+	return phys_addr;
+}
+
+static inline void dma_unmap_resource(struct device *dev, dma_addr_t addr,
+				      size_t size, enum dma_data_direction dir,
+				      struct dma_attrs *attrs)
+{
+	struct dma_map_ops *ops = get_dma_ops(dev);
+
+	BUG_ON(!valid_dma_direction(dir));
+	if (ops->unmap_resource)
+		ops->unmap_resource(dev, addr, size, dir, attrs);
+
+}
+
 static inline void dma_sync_single_for_cpu(struct device *dev, dma_addr_t addr,
 					   size_t size,
 					   enum dma_data_direction dir)
-- 
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb 16 12:39:37 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Tue, 16 Feb 2016 21:39:37 +0100
Subject: [PATCH v4 1/8] iommu: Add MMIO mapping type
In-Reply-To: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455655184-14478-2-git-send-email-niklas.soderlund+renesas@ragnatech.se>

From: Robin Murphy <robin.murphy at arm.com>

On some platforms, MMIO regions might need slightly different treatment
compared to mapping regular memory; add the notion of MMIO mappings to
the IOMMU API's memory type flags, so that callers can let the IOMMU
drivers know to do the right thing.

Signed-off-by: Robin Murphy <robin.murphy at arm.com>
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
---
 drivers/iommu/io-pgtable-arm.c | 9 +++++++--
 include/linux/iommu.h          | 1 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 381ca5a..9c19989 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -355,7 +355,10 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data,
 		if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
 			pte |= ARM_LPAE_PTE_AP_RDONLY;
 
-		if (prot & IOMMU_CACHE)
+		if (prot & IOMMU_MMIO)
+			pte |= (ARM_LPAE_MAIR_ATTR_IDX_DEV
+				<< ARM_LPAE_PTE_ATTRINDX_SHIFT);
+		else if (prot & IOMMU_CACHE)
 			pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE
 				<< ARM_LPAE_PTE_ATTRINDX_SHIFT);
 	} else {
@@ -364,7 +367,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data,
 			pte |= ARM_LPAE_PTE_HAP_READ;
 		if (prot & IOMMU_WRITE)
 			pte |= ARM_LPAE_PTE_HAP_WRITE;
-		if (prot & IOMMU_CACHE)
+		if (prot & IOMMU_MMIO)
+			pte |= ARM_LPAE_PTE_MEMATTR_DEV;
+		else if (prot & IOMMU_CACHE)
 			pte |= ARM_LPAE_PTE_MEMATTR_OIWB;
 		else
 			pte |= ARM_LPAE_PTE_MEMATTR_NC;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index a5c539f..34b6432 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -30,6 +30,7 @@
 #define IOMMU_WRITE	(1 << 1)
 #define IOMMU_CACHE	(1 << 2) /* DMA cache coherency */
 #define IOMMU_NOEXEC	(1 << 3)
+#define IOMMU_MMIO	(1 << 4) /* e.g. things like MSI doorbells */
 
 struct iommu_ops;
 struct iommu_group;
-- 
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb 16 12:39:38 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Tue, 16 Feb 2016 21:39:38 +0100
Subject: [PATCH v4 2/8] dma-mapping: add {map,unmap}_resource to dma_map_ops
In-Reply-To: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455655184-14478-3-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Add methods to handle mapping of device resources from a physical
address. This is needed for example to be able to map MMIO FIFO
registers to a IOMMU.

Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
 include/linux/dma-mapping.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 75857cd..e3aba4e 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -49,6 +49,12 @@ struct dma_map_ops {
 			 struct scatterlist *sg, int nents,
 			 enum dma_data_direction dir,
 			 struct dma_attrs *attrs);
+	dma_addr_t (*map_resource)(struct device *dev, phys_addr_t phys_addr,
+			       size_t size, enum dma_data_direction dir,
+			       struct dma_attrs *attrs);
+	void (*unmap_resource)(struct device *dev, dma_addr_t dma_handle,
+			   size_t size, enum dma_data_direction dir,
+			   struct dma_attrs *attrs);
 	void (*sync_single_for_cpu)(struct device *dev,
 				    dma_addr_t dma_handle, size_t size,
 				    enum dma_data_direction dir);
-- 
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb 16 12:39:36 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Tue, 16 Feb 2016 21:39:36 +0100
Subject: [PATCH v4 0/8] dmaengine: rcar-dmac: add iommu support for slave
 transfers
Message-ID: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Hi,

This series add iommu support to rcar-dmac. It's tested on Koelsch with
CONFIG_IPMMU_VMSA and by enabling the ipmmu_ds node in r8a7791.dtsi. I verified
operation by interacting with /dev/mmcblk1  which is a device behind the iommu.

The series depends on out of tree patch '[PATCH] dmaengine: use phys_addr_t for
slave configuration' which Vinod now have moved forward whit, thanks!

* Changes since v3
- Folded in a fix from Robin to his patch.
- Added a check to make sure dma_map_resource can not be used to map RAM as
  pointed out by Robin. I use BUG_ON to enforce this. It might not be the best
  method but I saw no other good way since DMA_ERROR_CODE might not be defined
  on all platforms.
- Added comment about that DTS changes will disable 2 DMA channels due to a HW
  (?) but in the DMAC.
- Dropped the use of dma_attrs, no longer needed.
- Collected Acked-by and Reviewed-by from Laurent.
- Various indentation fix ups.

* Changes since v2
- Drop patch to add dma_{map,unmap}_page_attrs.
- Add dma_{map,unmap}_resource to handle the mapping without involving a
  'struct page'. Thanks Laurent and Robin for pointing this out.
- Use size instead of address to keep track of if a mapping exist or not
  since addr == 0 is valid. Thanks Laurent.
- Pick up patch from Robin with Laurents ack (hope it's OK for me to
  attach the ack?) to add IOMMU_MMIO.
- Fix bug in rcar_dmac_device_config where the error check where
  inverted.
- Use DMA_BIDIRECTIONAL in rcar_dmac_device_config since we at that
  point can't be sure what direction the mapping is going to be used.

* Changes since v1
- Add and use a dma_{map,unmap}_page_attrs to be able to map the page
  using attributes DMA_ATTR_NO_KERNEL_MAPPING and
  DMA_ATTR_SKIP_CPU_SYNC. Thanks Laurent.
- Drop check if dmac is part of a iommu group or not, let the DMA
  mapping api handle it.
- Move slave configuration data around in rcar-dmac to avoid code
  duplication.
- Fix build issue reported by 'kbuild test robot' regarding phys_to_page
  not availability on some configurations.
- Add DT information for r8a7791.

* Changes since RFC
- Switch to use the dma-mapping api instead of using the iommu_map()
  directly. Turns out the dma-mapper is much smarter then me...
- Dropped the patch to expose domain->ops->pgsize_bitmap from within the
  iommu api.
- Dropped the patch showing how I tested the RFC.


Niklas S?derlund (7):
  dma-mapping: add {map,unmap}_resource to dma_map_ops
  dma-mapping: add dma_{map,unmap}_resource
  arm: dma-mapping: add {map,unmap}_resource for iommu ops
  dmaengine: rcar-dmac: group slave configuration
  dmaengine: rcar-dmac: add iommu support for slave transfers
  ARM: dts: r8a7790: add iommus to dmac0 and dmac1
  ARM: dts: r8a7791: add iommus to dmac0 and dmac1

Robin Murphy (1):
  iommu: Add MMIO mapping type

 arch/arm/boot/dts/r8a7790.dtsi | 30 ++++++++++++++++
 arch/arm/boot/dts/r8a7791.dtsi | 30 ++++++++++++++++
 arch/arm/mm/dma-mapping.c      | 63 ++++++++++++++++++++++++++++++++
 drivers/dma/sh/rcar-dmac.c     | 81 +++++++++++++++++++++++++++++++++---------
 drivers/iommu/io-pgtable-arm.c |  9 +++--
 include/linux/dma-mapping.h    | 38 ++++++++++++++++++++
 include/linux/iommu.h          |  1 +
 7 files changed, 233 insertions(+), 19 deletions(-)

--
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb 16 12:39:41 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Tue, 16 Feb 2016 21:39:41 +0100
Subject: [PATCH v4 5/8] dmaengine: rcar-dmac: group slave configuration
In-Reply-To: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455655184-14478-6-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Group slave address and transfer size in own structs for source and
destination. This is in preparation for hooking up the dma-mapping API
to the slave addresses.

Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
 drivers/dma/sh/rcar-dmac.c | 37 +++++++++++++++++++++----------------
 1 file changed, 21 insertions(+), 16 deletions(-)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index 7820d07..743873c 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -118,14 +118,21 @@ struct rcar_dmac_desc_page {
 	sizeof(struct rcar_dmac_xfer_chunk))
 
 /*
+ * @slave_addr: slave memory address
+ * @xfer_size: size (in bytes) of hardware transfers
+ */
+struct rcar_dmac_chan_slave {
+	dma_addr_t slave_addr;
+	unsigned int xfer_size;
+};
+
+/*
  * struct rcar_dmac_chan - R-Car Gen2 DMA Controller Channel
  * @chan: base DMA channel object
  * @iomem: channel I/O memory base
  * @index: index of this channel in the controller
- * @src_xfer_size: size (in bytes) of hardware transfers on the source side
- * @dst_xfer_size: size (in bytes) of hardware transfers on the destination side
- * @src_slave_addr: slave source memory address
- * @dst_slave_addr: slave destination memory address
+ * @src: slave memory address and size on the source side
+ * @dst: slave memory address and size on the destination side
  * @mid_rid: hardware MID/RID for the DMA client using this channel
  * @lock: protects the channel CHCR register and the desc members
  * @desc.free: list of free descriptors
@@ -142,10 +149,8 @@ struct rcar_dmac_chan {
 	void __iomem *iomem;
 	unsigned int index;
 
-	unsigned int src_xfer_size;
-	unsigned int dst_xfer_size;
-	dma_addr_t src_slave_addr;
-	dma_addr_t dst_slave_addr;
+	struct rcar_dmac_chan_slave src;
+	struct rcar_dmac_chan_slave dst;
 	int mid_rid;
 
 	spinlock_t lock;
@@ -793,13 +798,13 @@ static void rcar_dmac_chan_configure_desc(struct rcar_dmac_chan *chan,
 	case DMA_DEV_TO_MEM:
 		chcr = RCAR_DMACHCR_DM_INC | RCAR_DMACHCR_SM_FIXED
 		     | RCAR_DMACHCR_RS_DMARS;
-		xfer_size = chan->src_xfer_size;
+		xfer_size = chan->src.xfer_size;
 		break;
 
 	case DMA_MEM_TO_DEV:
 		chcr = RCAR_DMACHCR_DM_FIXED | RCAR_DMACHCR_SM_INC
 		     | RCAR_DMACHCR_RS_DMARS;
-		xfer_size = chan->dst_xfer_size;
+		xfer_size = chan->dst.xfer_size;
 		break;
 
 	case DMA_MEM_TO_MEM:
@@ -1038,7 +1043,7 @@ rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
 	}
 
 	dev_addr = dir == DMA_DEV_TO_MEM
-		 ? rchan->src_slave_addr : rchan->dst_slave_addr;
+		 ? rchan->src.slave_addr : rchan->dst.slave_addr;
 	return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
 				      dir, flags, false);
 }
@@ -1093,7 +1098,7 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
 	}
 
 	dev_addr = dir == DMA_DEV_TO_MEM
-		 ? rchan->src_slave_addr : rchan->dst_slave_addr;
+		 ? rchan->src.slave_addr : rchan->dst.slave_addr;
 	desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
 				      dir, flags, true);
 
@@ -1110,10 +1115,10 @@ static int rcar_dmac_device_config(struct dma_chan *chan,
 	 * We could lock this, but you shouldn't be configuring the
 	 * channel, while using it...
 	 */
-	rchan->src_slave_addr = cfg->src_addr;
-	rchan->dst_slave_addr = cfg->dst_addr;
-	rchan->src_xfer_size = cfg->src_addr_width;
-	rchan->dst_xfer_size = cfg->dst_addr_width;
+	rchan->src.slave_addr = cfg->src_addr;
+	rchan->dst.slave_addr = cfg->dst_addr;
+	rchan->src.xfer_size = cfg->src_addr_width;
+	rchan->dst.xfer_size = cfg->dst_addr_width;
 
 	return 0;
 }
-- 
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb 16 12:39:40 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Tue, 16 Feb 2016 21:39:40 +0100
Subject: [PATCH v4 4/8] arm: dma-mapping: add {map,
 unmap}_resource for iommu ops
In-Reply-To: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455655184-14478-5-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Add methods to map/unmap device resources addresses for dma_map_ops that
are IOMMU aware. This is needed to map a device MMIO register from a
physical address.

Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
 arch/arm/mm/dma-mapping.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 0eca381..ae2b175 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1814,6 +1814,63 @@ static void arm_iommu_unmap_page(struct device *dev, dma_addr_t handle,
 	__free_iova(mapping, iova, len);
 }
 
+/**
+ * arm_iommu_map_resource - map a device resource for DMA
+ * @dev: valid struct device pointer
+ * @phys_addr: physical address of resource
+ * @size: size of resource to map
+ * @dir: DMA transfer direction
+ */
+static dma_addr_t arm_iommu_map_resource(struct device *dev,
+		phys_addr_t phys_addr, size_t size,
+		enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+	dma_addr_t dma_addr;
+	int ret, prot;
+	phys_addr_t addr = phys_addr & PAGE_MASK;
+	int offset = phys_addr & ~PAGE_MASK;
+	int len = PAGE_ALIGN(size + offset);
+
+	dma_addr = __alloc_iova(mapping, size);
+	if (dma_addr == DMA_ERROR_CODE)
+		return dma_addr;
+
+	prot = __dma_direction_to_prot(dir) | IOMMU_MMIO;
+
+	ret = iommu_map(mapping->domain, dma_addr, addr, len, prot);
+	if (ret < 0)
+		goto fail;
+
+	return dma_addr + offset;
+fail:
+	__free_iova(mapping, dma_addr, size);
+	return DMA_ERROR_CODE;
+}
+
+/**
+ * arm_iommu_unmap_resource - unmap a device DMA resource
+ * @dev: valid struct device pointer
+ * @dma_handle: DMA address to resource
+ * @size: size of resource to map
+ * @dir: DMA transfer direction
+ */
+static void arm_iommu_unmap_resource(struct device *dev, dma_addr_t dma_handle,
+		size_t size, enum dma_data_direction dir,
+		struct dma_attrs *attrs)
+{
+	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+	dma_addr_t iova = dma_handle & PAGE_MASK;
+	int offset = dma_handle & ~PAGE_MASK;
+	int len = PAGE_ALIGN(size + offset);
+
+	if (!iova)
+		return;
+
+	iommu_unmap(mapping->domain, iova, len);
+	__free_iova(mapping, iova, len);
+}
+
 static void arm_iommu_sync_single_for_cpu(struct device *dev,
 		dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
@@ -1858,6 +1915,9 @@ struct dma_map_ops iommu_ops = {
 	.sync_sg_for_cpu	= arm_iommu_sync_sg_for_cpu,
 	.sync_sg_for_device	= arm_iommu_sync_sg_for_device,
 
+	.map_resource		= arm_iommu_map_resource,
+	.unmap_resource		= arm_iommu_unmap_resource,
+
 	.set_dma_mask		= arm_dma_set_mask,
 };
 
@@ -1873,6 +1933,9 @@ struct dma_map_ops iommu_coherent_ops = {
 	.map_sg		= arm_coherent_iommu_map_sg,
 	.unmap_sg	= arm_coherent_iommu_unmap_sg,
 
+	.map_resource	= arm_iommu_map_resource,
+	.unmap_resource	= arm_iommu_unmap_resource,
+
 	.set_dma_mask	= arm_dma_set_mask,
 };
 
-- 
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb 16 12:39:44 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Tue, 16 Feb 2016 21:39:44 +0100
Subject: [PATCH v4 8/8] ARM: dts: r8a7791: add iommus to dmac0 and dmac1
In-Reply-To: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455655184-14478-9-git-send-email-niklas.soderlund+renesas@ragnatech.se>

A unconfirmed hardware bug prevents channel 0 and 15 to be used by the
DMAC together with the IPMMU. The DMAC driver will disable the channels
reducing the effective number of channels to 14 per DMAC.

Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
 arch/arm/boot/dts/r8a7791.dtsi | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 2a369dd..6dff061 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -283,6 +283,21 @@
 		power-domains = <&cpg_clocks>;
 		#dma-cells = <1>;
 		dma-channels = <15>;
+		iommus = <&ipmmu_ds 0>,
+			 <&ipmmu_ds 1>,
+			 <&ipmmu_ds 2>,
+			 <&ipmmu_ds 3>,
+			 <&ipmmu_ds 4>,
+			 <&ipmmu_ds 5>,
+			 <&ipmmu_ds 6>,
+			 <&ipmmu_ds 7>,
+			 <&ipmmu_ds 8>,
+			 <&ipmmu_ds 9>,
+			 <&ipmmu_ds 10>,
+			 <&ipmmu_ds 11>,
+			 <&ipmmu_ds 12>,
+			 <&ipmmu_ds 13>,
+			 <&ipmmu_ds 14>;
 	};
 
 	dmac1: dma-controller at e6720000 {
@@ -314,6 +329,21 @@
 		power-domains = <&cpg_clocks>;
 		#dma-cells = <1>;
 		dma-channels = <15>;
+		iommus = <&ipmmu_ds 15>,
+			 <&ipmmu_ds 16>,
+			 <&ipmmu_ds 17>,
+			 <&ipmmu_ds 18>,
+			 <&ipmmu_ds 19>,
+			 <&ipmmu_ds 20>,
+			 <&ipmmu_ds 21>,
+			 <&ipmmu_ds 22>,
+			 <&ipmmu_ds 23>,
+			 <&ipmmu_ds 24>,
+			 <&ipmmu_ds 25>,
+			 <&ipmmu_ds 26>,
+			 <&ipmmu_ds 27>,
+			 <&ipmmu_ds 28>,
+			 <&ipmmu_ds 29>;
 	};
 
 	audma0: dma-controller at ec700000 {
-- 
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb 16 12:39:43 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Tue, 16 Feb 2016 21:39:43 +0100
Subject: [PATCH v4 7/8] ARM: dts: r8a7790: add iommus to dmac0 and dmac1
In-Reply-To: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455655184-14478-8-git-send-email-niklas.soderlund+renesas@ragnatech.se>

A unconfirmed hardware bug prevents channel 0 and 15 to be used by the
DMAC together with the IPMMU. The DMAC driver will disable the channels
reducing the effective number of channels to 14 per DMAC.

Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
 arch/arm/boot/dts/r8a7790.dtsi | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 7dfd393..048bbf8 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -294,6 +294,21 @@
 		power-domains = <&cpg_clocks>;
 		#dma-cells = <1>;
 		dma-channels = <15>;
+		iommus = <&ipmmu_ds 0>,
+			 <&ipmmu_ds 1>,
+			 <&ipmmu_ds 2>,
+			 <&ipmmu_ds 3>,
+			 <&ipmmu_ds 4>,
+			 <&ipmmu_ds 5>,
+			 <&ipmmu_ds 6>,
+			 <&ipmmu_ds 7>,
+			 <&ipmmu_ds 8>,
+			 <&ipmmu_ds 9>,
+			 <&ipmmu_ds 10>,
+			 <&ipmmu_ds 11>,
+			 <&ipmmu_ds 12>,
+			 <&ipmmu_ds 13>,
+			 <&ipmmu_ds 14>;
 	};
 
 	dmac1: dma-controller at e6720000 {
@@ -325,6 +340,21 @@
 		power-domains = <&cpg_clocks>;
 		#dma-cells = <1>;
 		dma-channels = <15>;
+		iommus = <&ipmmu_ds 15>,
+			 <&ipmmu_ds 16>,
+			 <&ipmmu_ds 17>,
+			 <&ipmmu_ds 18>,
+			 <&ipmmu_ds 19>,
+			 <&ipmmu_ds 20>,
+			 <&ipmmu_ds 21>,
+			 <&ipmmu_ds 22>,
+			 <&ipmmu_ds 23>,
+			 <&ipmmu_ds 24>,
+			 <&ipmmu_ds 25>,
+			 <&ipmmu_ds 26>,
+			 <&ipmmu_ds 27>,
+			 <&ipmmu_ds 28>,
+			 <&ipmmu_ds 29>;
 	};
 
 	audma0: dma-controller at ec700000 {
-- 
2.7.1



From niklas.soderlund+renesas at ragnatech.se  Tue Feb 16 12:39:42 2016
From: niklas.soderlund+renesas at ragnatech.se (=?UTF-8?q?Niklas=20S=C3=B6derlund?=)
Date: Tue, 16 Feb 2016 21:39:42 +0100
Subject: [PATCH v4 6/8] dmaengine: rcar-dmac: add iommu support for slave
 transfers
In-Reply-To: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
References: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se>
Message-ID: <1455655184-14478-7-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Enable slave transfers to devices behind IPMMU:s by mapping the slave
addresses using the dma-mapping API.

Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas at ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
---
 drivers/dma/sh/rcar-dmac.c | 52 +++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 47 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index 743873c..6a24847 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -1106,21 +1106,63 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr,
 	return desc;
 }
 
+static int rcar_dmac_set_slave_addr(struct dma_chan *chan,
+				     struct rcar_dmac_chan_slave *slave,
+				     phys_addr_t addr, size_t size)
+{
+	enum dma_data_direction dir;
+
+	/*
+	 * We can't know the direction at this time, see documentation for
+	 * 'direction' in struct dma_slave_config.
+	 */
+	dir = DMA_BIDIRECTIONAL;
+
+	if (slave->xfer_size) {
+		dma_unmap_resource(chan->device->dev, slave->slave_addr,
+				   slave->xfer_size, dir, NULL);
+		slave->slave_addr = 0;
+		slave->xfer_size = 0;
+	}
+
+	if (size) {
+		slave->slave_addr = dma_map_resource(chan->device->dev, addr,
+				size, dir, NULL);
+
+		if (dma_mapping_error(chan->device->dev, slave->slave_addr)) {
+			struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
+
+			dev_err(chan->device->dev,
+				"chan%u: failed to map %zx@%pap", rchan->index,
+				size, &addr);
+			return -EIO;
+		}
+
+		slave->xfer_size = size;
+	}
+
+	return 0;
+}
+
 static int rcar_dmac_device_config(struct dma_chan *chan,
 				   struct dma_slave_config *cfg)
 {
 	struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
+	int ret;
 
 	/*
 	 * We could lock this, but you shouldn't be configuring the
 	 * channel, while using it...
 	 */
-	rchan->src.slave_addr = cfg->src_addr;
-	rchan->dst.slave_addr = cfg->dst_addr;
-	rchan->src.xfer_size = cfg->src_addr_width;
-	rchan->dst.xfer_size = cfg->dst_addr_width;
 
-	return 0;
+	ret = rcar_dmac_set_slave_addr(chan, &rchan->src, cfg->src_addr,
+				       cfg->src_addr_width);
+	if (ret)
+		return ret;
+
+	ret = rcar_dmac_set_slave_addr(chan, &rchan->dst, cfg->dst_addr,
+				       cfg->dst_addr_width);
+	return ret;
 }
 
 static int rcar_dmac_chan_terminate_all(struct dma_chan *chan)
-- 
2.7.1



From nicolas.pitre at linaro.org  Tue Feb 16 12:41:41 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Tue, 16 Feb 2016 15:41:41 -0500 (EST)
Subject: [PATCH] ARM: drop unused DEBUG_RODATA from XIP_KERNEL
In-Reply-To: <20160216202957.GA1826@www.outflux.net>
References: <20160216202957.GA1826@www.outflux.net>
Message-ID: <alpine.LFD.2.20.1602161539550.13632@knanqh.ubzr>

On Tue, 16 Feb 2016, Kees Cook wrote:

> With CONFIG_DEBUG_RODATA not being sensible under XIP_KERNEL, remove it
> from the XIP linker script.

If so you should also make DEBUG_RODATA depend on !XIP_KERNEL in Kconfig 
to avoid offering a config option that does nothing.

> Signed-off-by: Kees Cook <keescook at chromium.org>
> ---
> Effectively the patch after Arnd's "ARM: mm: hide
> __start_rodata_section_aligned for non-debug builds"
> ---
>  arch/arm/kernel/vmlinux-xip.lds.S | 10 ----------
>  1 files changed, 0 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
> index 40bc4cadb959..cba1ec899a69 100644
> --- a/arch/arm/kernel/vmlinux-xip.lds.S
> +++ b/arch/arm/kernel/vmlinux-xip.lds.S
> @@ -8,9 +8,6 @@
>  #include <asm/thread_info.h>
>  #include <asm/memory.h>
>  #include <asm/page.h>
> -#ifdef CONFIG_DEBUG_RODATA
> -#include <asm/pgtable.h>
> -#endif
>  
>  #define PROC_INFO							\
>  	. = ALIGN(4);							\
> @@ -92,10 +89,6 @@ SECTIONS
>  		HEAD_TEXT
>  	}
>  
> -#ifdef CONFIG_DEBUG_RODATA
> -	. = ALIGN(1<<SECTION_SHIFT);
> -#endif
> -
>  	.text : {			/* Real text segment		*/
>  		_stext = .;		/* Text and read-only data	*/
>  			IDMAP_TEXT
> @@ -115,9 +108,6 @@ SECTIONS
>  			ARM_CPU_KEEP(PROC_INFO)
>  	}
>  
> -#ifdef CONFIG_DEBUG_RODATA
> -	. = ALIGN(1<<SECTION_SHIFT);
> -#endif
>  	RO_DATA(PAGE_SIZE)
>  
>  	. = ALIGN(4);
> -- 
> 2.6.3
> 
> 
> -- 
> Kees Cook
> Chrome OS & Brillo Security
> 
> 


From niklas.soderlund at ragnatech.se  Tue Feb 16 12:42:32 2016
From: niklas.soderlund at ragnatech.se (Niklas =?iso-8859-1?Q?S=F6derlund?=)
Date: Tue, 16 Feb 2016 21:42:32 +0100
Subject: [PATCH] dmaengine: use phys_addr_t for slave configuration
In-Reply-To: <20160215173053.GM19598@localhost>
References: <1366967214-20776-1-git-send-email-linus.walleij@linaro.org>
 <CAMuHMdUTzTBT8DyRb5WN048U5DbVsFnhJB0c5tjHBnA4rfetJg@mail.gmail.com>
 <20150710081411.GF836@localhost>
 <CAMuHMdV8a1W1MyJPanUNBzaiNsL96JYzetBVSiZoC3=eKXzo1Q@mail.gmail.com>
 <20151215172649.GK1854@localhost>
 <CAMuHMdXe8i2JbhOP2sWkVkqHEeBnW4AfVBbRaoZW=Kg0s_9m3g@mail.gmail.com>
 <20160209225724.GA1522@katana> <20160215173053.GM19598@localhost>
Message-ID: <20160216204232.GB5268@bigcity.dyn.berto.se>

On 2016-02-15 23:00:53 +0530, Vinod Koul wrote:
> On Tue, Feb 09, 2016 at 11:57:24PM +0100, Wolfram Sang wrote:
> >
> > > This is a dependency for adding iommu support to the rcar-dmac driver, cfr.
> > > "[PATCH v2 0/5] dmaengine: rcar-dmac: add iommu support for slave transfers".
> > > http://www.spinics.net/lists/linux-renesas-soc/msg00066.html
> > > https://www.mail-archive.com/linux-renesas-soc at vger.kernel.org/msg00108.html
> > >
> > > Thank you for applying!
> >
> > Yup, we really need it. Anything we can do to help?
>
> I have done this change and discussing wider changes
> I will send CFT hopefully before EOW, pls test :)

Thanks Vinod for looking at this!


From mmcclint at codeaurora.org  Tue Feb 16 12:43:18 2016
From: mmcclint at codeaurora.org (Matthew McClintock)
Date: Tue, 16 Feb 2016 14:43:18 -0600
Subject: [PATCH v3 5/6] dts: ipq4019: Add support for IPQ4019 DK01 board
In-Reply-To: <20160208224328.GB10791@codeaurora.org>
References: <1447975173-29485-1-git-send-email-mmcclint@qca.qualcomm.com>
 <1447975173-29485-6-git-send-email-mmcclint@qca.qualcomm.com>
 <20160208224328.GB10791@codeaurora.org>
Message-ID: <59152C1B-683F-417D-9C23-C6E3F53D7096@codeaurora.org>

On Feb 8, 2016, at 4:43 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
> 
> On 11/19, Matthew McClintock wrote:
>> +
>> +/ {
>> +	model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK01.1";
>> +	compatible = "qcom,ipq4019";
>> +
>> +	clocks {
>> +                xo: xo {
>> +                        compatible = "fixed-clock";
>> +                        clock-frequency = <48000000>;
>> +                        #clock-cells = <0>;
>> +                };
>> +	};
> 
> Is there a reason the xo is here and the sleep clk is in the SoC
> dtsi file? Both are board clocks so I would think they would be
> added in the same place.

I?m a little bit confused and I wanted to confirm. I can see the xo clock is on the board itself. However, the sleep_clk is not, can you clarify why they would both be in the same place?

-M

From peter at korsgaard.com  Tue Feb 16 13:00:04 2016
From: peter at korsgaard.com (Peter Korsgaard)
Date: Tue, 16 Feb 2016 22:00:04 +0100
Subject: [PATCH] ARM: dts: sun4i: Enable USB DRC on Hyundai-a7hd
Message-ID: <1455656404-31191-1-git-send-email-peter@korsgaard.com>

Enable the OTG USB controller on the A7HD.

Signed-off-by: Peter Korsgaard <peter at korsgaard.com>
---
 arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts | 34 ++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts b/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
index 43f58fb..9103864 100644
--- a/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
+++ b/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
@@ -87,6 +87,30 @@
 	status = "okay";
 };
 
+&otg_sram {
+	status = "okay";
+};
+
+&pio {
+	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
+		allwinner,pins = "PH4";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+	};
+
+	usb0_vbus_detect_pin: usb0_vbus_detect_pin at 0 {
+		allwinner,pins = "PH5";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_PULL_DOWN>;
+	};
+};
+
+&reg_usb0_vbus {
+	status = "okay";
+};
+
 &reg_usb2_vbus {
 	gpio = <&pio 7 6 GPIO_ACTIVE_HIGH>; /* PH6 */
 	status = "okay";
@@ -102,7 +126,17 @@
 	allwinner,pins = "PH6";
 };
 
+&usb_otg {
+	dr_mode = "otg";
+	status = "okay";
+};
+
 &usbphy {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
+	usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+	usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+	usb0_vbus-supply = <&reg_usb0_vbus>;
 	usb2_vbus-supply = <&reg_usb2_vbus>;
 	status = "okay";
 };
-- 
2.1.4



From rric at kernel.org  Tue Feb 16 13:14:10 2016
From: rric at kernel.org (Robert Richter)
Date: Tue, 16 Feb 2016 22:14:10 +0100
Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <56C37D94.8080403@caviumnetworks.com>
References: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160214170152.GC3965@htj.duckdns.org>
 <56C147B2.9010303@caviumnetworks.com>
 <20160215183041.GH3965@htj.duckdns.org>
 <20160216144250.GD31343@rric.localdomain>
 <56C37524.5090000@caviumnetworks.com>
 <56C37AD3.4030407@caviumnetworks.com>
 <56C37D94.8080403@caviumnetworks.com>
Message-ID: <20160216211410.GI25086@rric.localdomain>

On 16.02.16 11:50:44, Tirumalesh Chalamarla wrote:
> 
> 
> On 02/16/2016 11:38 AM, David Daney wrote:
> >On 02/16/2016 11:14 AM, Tirumalesh Chalamarla wrote:
> >>
> >>
> >>On 02/16/2016 06:42 AM, Robert Richter wrote:
> >>>On 15.02.16 13:30:41, Tejun Heo wrote:
> >>>>On Sun, Feb 14, 2016 at 07:36:18PM -0800, Tirumalesh Chalamarla wrote:
> >>>>>There is no need for special Driver, AHCI is sufficient for
> >>>>>ThunderX, the
> >>>>>file only contains this interrupt handler,
> >>>>>is it preferable if this interrupt handler in libahci.c with others,
> >>>>>instead
> >>>>>of separate file?
> >>>>
> >>>>Yeap, just fold it in ahci.c with surrounding #ifdef guard.
> >>>
> >>>Yes, please use #ifdef CONFIG_CAVIUM_ERRATUM_22536 ... and add a
> >>>kconfig entry for this to arch/arm64/Kconfig.
> >>>
> >>Are you sure, this is not a workaround that is based on alternative
> >>framework rather on pci device and vendor
> >>
> >>do you think CONFIG_ARCH_THUNDER a good alternative?
> >
> >No.  CONFIG_ARCH_THUNDER should be removed all together.
> >
> >Grouping a bunch of unrelated features under a single config variable
> >creates a very brittle system.  What are you going to do when a new
> >hardware revision is released?  Create CONFIG_ARCH_THUNDER2?  Which one
> >of these two would you select if building a kernel?  It is a choice that
> >we don't want to force users (kernel builders) to have to waste mental
> >energy on.
> >
> >Instead, let's try to make things work out of the box without having to
> >set a bunch of random config variables.
> >
> >If a generic arm64 kernel won't get too bloated, I would suggest just
> >enabling the compilation of the code unconditionally (at least for
> >arm64).  The use of the code would still be gated by the PCI version
> >probe that is part of the patch.
> >
> 
> exactly, that is my initial choice with v1, and only depends on vendor and
> device id.
> 
> but it seems a config is needed. how about ARCH_ARM64 then?

CONFIG_CAVIUM_ERRATUM_22536 is exactly that you need. It is not only
used for core interrupts, e.g. also for gicv3 devices (and now also
for ahci). Non-core errata (e.g. CONFIG_CAVIUM_ERRATUM_23144) are not
enabled in the arm64 cpu errata framework (not handled in
arch/arm64/kernel/cpu_errata.c).

Thus,

#ifdef CONFIG_CAVIUM_ERRATUM_22536
	if (pdev->vendor == 0x177d && pdev->device == 0xa01c)
		ahci_thunderx_init(&pdev->dev, hpriv);
#endif

is the correct enablement of the workaround by device id.

And, CAVIUM_ERRATUM_* is very easy to handle, enable and document.

-Robert


From arnd at arndb.de  Tue Feb 16 13:17:43 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 22:17:43 +0100
Subject: [PATCH v2] ARM: vmlinux-xip.lds: assert that ROM and RAM don't
 overlap
In-Reply-To: <HK2PR06MB05619656241BFD0A9165B6C28AAD0@HK2PR06MB0561.apcprd06.prod.outlook.com>
References: <1455278803-27679-1-git-send-email-ard.biesheuvel@linaro.org>
 <HK2PR06MB05619656241BFD0A9165B6C28AAD0@HK2PR06MB0561.apcprd06.prod.outlook.com>
Message-ID: <5611698.LJs5sAezys@wuerfel>

On Tuesday 16 February 2016 19:18:51 Chris Brandt wrote:
> 
> This looks fine to me. I see no issues with it.
> Of course, this is for systems with a much tighter device memory layout than what I usually use.

The overlap should only happen when you have really large kernel images
over 16MB of readonly .text+.rodata, and I would assume this rarely happens
in practice.

	Arnd


From arnd at arndb.de  Tue Feb 16 13:20:51 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 22:20:51 +0100
Subject: [PATCH v4 03/12] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <1455646502-23834-4-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
 <1455646502-23834-4-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <3647094.zzYms58VAY@wuerfel>

On Tuesday 16 February 2016 19:14:53 Gregory CLEMENT wrote:
> 
> +config SERIAL_MVEBU_UART
> +       bool "Marvell EBU serial port support"
> +       select SERIAL_CORE

It would be nice to make this a tristate option with

	depends on ARCH_MVEBU || COMPILE_TEST

so we can build it in an allmodconfig kernel as a standalone module
like the other drivers.

> +
> +config SERIAL_MVEBU_CONSOLE
> +       bool "Console on Marvell EBU serial port"
> +       depends on SERIAL_MVEBU_UART

then this one must become

	depends on SERIAL_MVEBU_UART

so it does not get enabled if the driver is not builtin.

	Arnd


From arnd at arndb.de  Tue Feb 16 13:22:11 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 22:22:11 +0100
Subject: [PATCH v4 00/12] Add support for the Armada 3700 SoC an mvebu
 ARM64 based
In-Reply-To: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <2699923.cugyhCaCQy@wuerfel>

On Tuesday 16 February 2016 19:14:50 Gregory CLEMENT wrote:
> This series introduce the support of the Armada 3700 family: it is the
> first ARM64 SoC of the mvebu family submitted to the mainline!
> 
> Currently there are two members of the Armada 3700 family, the only
> difference is the number of core: the Armada 3710 comes with one
> Cortex-A53 whereas the Armada 3720 comes with 2 Cortex-A53. In this
> series we enabled only the minimum to boot, pinctrl and clock tree
> will come soon.
> 

Whole series

Acked-by: Arnd Bergmann <arnd at arndb.de>


From arnd at arndb.de  Tue Feb 16 13:24:10 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 22:24:10 +0100
Subject: [PATCH] ARM: drop unused DEBUG_RODATA from XIP_KERNEL
In-Reply-To: <20160216202957.GA1826@www.outflux.net>
References: <20160216202957.GA1826@www.outflux.net>
Message-ID: <5884144.R9YAlf8Dgt@wuerfel>

On Tuesday 16 February 2016 12:29:57 Kees Cook wrote:
> With CONFIG_DEBUG_RODATA not being sensible under XIP_KERNEL, remove it
> from the XIP linker script.
> 
> Signed-off-by: Kees Cook <keescook at chromium.org>
> 

Acked-by: Arnd Bergmann <arnd at arndb.de>


From thomas.petazzoni at free-electrons.com  Tue Feb 16 13:27:06 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 16 Feb 2016 22:27:06 +0100
Subject: [PATCH v4 03/12] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <3647094.zzYms58VAY@wuerfel>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
 <1455646502-23834-4-git-send-email-gregory.clement@free-electrons.com>
 <3647094.zzYms58VAY@wuerfel>
Message-ID: <20160216222706.6b1d3375@free-electrons.com>

Arnd,

On Tue, 16 Feb 2016 22:20:51 +0100, Arnd Bergmann wrote:

> > +config SERIAL_MVEBU_CONSOLE
> > +       bool "Console on Marvell EBU serial port"
> > +       depends on SERIAL_MVEBU_UART
> 
> then this one must become
> 
> 	depends on SERIAL_MVEBU_UART
> 
> so it does not get enabled if the driver is not builtin.

Hm, what's the different between "depends on SERIAL_MVEBU_UART" and
"depends on SERIAL_MVEBU_UART" ? Is it the late time that causes my
eyes to misunderstand what you mean, or some typo on your side ? :-)

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From arjan at linux.intel.com  Tue Feb 16 13:31:36 2016
From: arjan at linux.intel.com (Arjan van de Ven)
Date: Tue, 16 Feb 2016 13:31:36 -0800
Subject: [PATCH v2] arm64: add alignment fault hanling
In-Reply-To: <CA+55aFw-86k4gY46Et=e02HQQSxjUK2Jfz0SJz8tWtk5P8YZFA@mail.gmail.com>
References: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
 <20160216103104.GC14509@arm.com> <56C300AD.8070505@arm.com>
 <20160216122153.GD19413@e104818-lin.cambridge.arm.com>
 <20160216160055.GH14509@arm.com> <20160216170408.GL14509@arm.com>
 <CA+55aFw-86k4gY46Et=e02HQQSxjUK2Jfz0SJz8tWtk5P8YZFA@mail.gmail.com>
Message-ID: <56C39538.6090009@linux.intel.com>

On 2/16/2016 10:50 AM, Linus Torvalds wrote:
> On Tue, Feb 16, 2016 at 9:04 AM, Will Deacon <will.deacon at arm.com> wrote:
>> [replying to self and adding some x86 people]
>>
>> Background: Euntaik reports a problem where userspace has ended up with
>> a memory page mapped adjacent to an MMIO page (e.g. from /dev/mem or a
>> PCI memory bar from someplace in /sys). strncpy_from_user happens with
>> the word-at-a-time implementation, and we end up reading into the MMIO
>> page.

how does this work if the adjacent page is not accessible?
or has some other magic fault handler, or is on an NFS filesystem where
the server is rebooting?

isn't the general rule for such basic functions "don't touch memory unless you KNOW it is there"



> Of course, no actual real program will do that for mixing MMIO and
> non-MMIO, and so we might obviously add code to always add a guard
> page for the normal case when a specific address isn't asked for. So
> as a heuristic to make sure it doesn't happen by mistake it possibly
> makes sense.

but what happens to the read if the page isn't present?
or is execute-only or .. or ..




From arnd at arndb.de  Tue Feb 16 13:35:14 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 22:35:14 +0100
Subject: [PATCH v4 03/12] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <20160216222706.6b1d3375@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
 <3647094.zzYms58VAY@wuerfel> <20160216222706.6b1d3375@free-electrons.com>
Message-ID: <2634634.yW5ZfZDXSz@wuerfel>

On Tuesday 16 February 2016 22:27:06 Thomas Petazzoni wrote:
> Arnd,
> 
> On Tue, 16 Feb 2016 22:20:51 +0100, Arnd Bergmann wrote:
> 
> > > +config SERIAL_MVEBU_CONSOLE
> > > +       bool "Console on Marvell EBU serial port"
> > > +       depends on SERIAL_MVEBU_UART
> > 
> > then this one must become
> > 
> >       depends on SERIAL_MVEBU_UART
> > 
> > so it does not get enabled if the driver is not builtin.
> 
> Hm, what's the different between "depends on SERIAL_MVEBU_UART" and
> "depends on SERIAL_MVEBU_UART" ? Is it the late time that causes my
> eyes to misunderstand what you mean, or some typo on your side ? 
> 


typo: I meant

	depends on SERIAL_MVEBU_UART=y


	Arnd


From david.brown at linaro.org  Tue Feb 16 13:36:59 2016
From: david.brown at linaro.org (David Brown)
Date: Tue, 16 Feb 2016 14:36:59 -0700
Subject: [PATCH] ARM: vdso: Mark vDSO code as read-only
In-Reply-To: <1453226922-16831-1-git-send-email-keescook@chromium.org>
References: <1453226922-16831-1-git-send-email-keescook@chromium.org>
Message-ID: <20160216213659.GA47194@davidb.org>

Although the arm vDSO is cleanly separated by code/data with the code
being read-only in userspace mappings, the code page is still writable
from the kernel.  There have been exploits (such as
http://itszn.com/blog/?p=21) that take advantage of this on x86 to go
from a bad kernel write to full root.

Prevent this specific exploit on arm by putting the vDSO code page in
post-init read-only memory as well.

Before:
vdso: 1 text pages at base 80927000
root at Vexpress:/ cat /sys/kernel/debug/kernel_page_tables
---[ Modules ]---
---[ Kernel Mapping ]---
0x80000000-0x80100000           1M     RW NX SHD
0x80100000-0x80600000           5M     ro x  SHD
0x80600000-0x80800000           2M     ro NX SHD
0x80800000-0xbe000000         984M     RW NX SHD

After:
vdso: 1 text pages at base 8072b000
root at Vexpress:/ cat /sys/kernel/debug/kernel_page_tables
---[ Modules ]---
---[ Kernel Mapping ]---
0x80000000-0x80100000           1M     RW NX SHD
0x80100000-0x80600000           5M     ro x  SHD
0x80600000-0x80800000           2M     ro NX SHD
0x80800000-0xbe000000         984M     RW NX SHD

Inspired by https://lkml.org/lkml/2016/1/19/494 based on work by the
PaX Team, Brad Spengler, and Kees Cook.

Signed-off-by: David Brown <david.brown at linaro.org>
---
This patch depends on Kees Cook's series
https://lkml.org/lkml/2016/1/19/497 which adds the ro_after_init
section.

 arch/arm/vdso/vdso.S | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/vdso/vdso.S b/arch/arm/vdso/vdso.S
index b2b97e3..a62a7b6 100644
--- a/arch/arm/vdso/vdso.S
+++ b/arch/arm/vdso/vdso.S
@@ -23,9 +23,8 @@
 #include <linux/const.h>
 #include <asm/page.h>
 
-	__PAGE_ALIGNED_DATA
-
 	.globl vdso_start, vdso_end
+	.section .data..ro_after_init
 	.balign PAGE_SIZE
 vdso_start:
 	.incbin "arch/arm/vdso/vdso.so"
-- 
2.7.1



From keescook at chromium.org  Tue Feb 16 13:52:33 2016
From: keescook at chromium.org (Kees Cook)
Date: Tue, 16 Feb 2016 13:52:33 -0800
Subject: [PATCH] ARM: vdso: Mark vDSO code as read-only
In-Reply-To: <20160216213659.GA47194@davidb.org>
References: <1453226922-16831-1-git-send-email-keescook@chromium.org>
 <20160216213659.GA47194@davidb.org>
Message-ID: <CAGXu5j+H63jhcDpHpXK5aWvgUBz=5vB0FK_zRoc+wZEk32B2fg@mail.gmail.com>

On Tue, Feb 16, 2016 at 1:36 PM, David Brown <david.brown at linaro.org> wrote:
> Although the arm vDSO is cleanly separated by code/data with the code
> being read-only in userspace mappings, the code page is still writable
> from the kernel.  There have been exploits (such as
> http://itszn.com/blog/?p=21) that take advantage of this on x86 to go
> from a bad kernel write to full root.
>
> Prevent this specific exploit on arm by putting the vDSO code page in
> post-init read-only memory as well.

Is the vdso dynamically built at init time like on x86, or can this
just use .rodata directly?

-Kees

>
> Before:
> vdso: 1 text pages at base 80927000
> root at Vexpress:/ cat /sys/kernel/debug/kernel_page_tables
> ---[ Modules ]---
> ---[ Kernel Mapping ]---
> 0x80000000-0x80100000           1M     RW NX SHD
> 0x80100000-0x80600000           5M     ro x  SHD
> 0x80600000-0x80800000           2M     ro NX SHD
> 0x80800000-0xbe000000         984M     RW NX SHD
>
> After:
> vdso: 1 text pages at base 8072b000
> root at Vexpress:/ cat /sys/kernel/debug/kernel_page_tables
> ---[ Modules ]---
> ---[ Kernel Mapping ]---
> 0x80000000-0x80100000           1M     RW NX SHD
> 0x80100000-0x80600000           5M     ro x  SHD
> 0x80600000-0x80800000           2M     ro NX SHD
> 0x80800000-0xbe000000         984M     RW NX SHD
>
> Inspired by https://lkml.org/lkml/2016/1/19/494 based on work by the
> PaX Team, Brad Spengler, and Kees Cook.
>
> Signed-off-by: David Brown <david.brown at linaro.org>
> ---
> This patch depends on Kees Cook's series
> https://lkml.org/lkml/2016/1/19/497 which adds the ro_after_init
> section.
>
> arch/arm/vdso/vdso.S | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/vdso/vdso.S b/arch/arm/vdso/vdso.S
> index b2b97e3..a62a7b6 100644
> --- a/arch/arm/vdso/vdso.S
> +++ b/arch/arm/vdso/vdso.S
> @@ -23,9 +23,8 @@
> #include <linux/const.h>
> #include <asm/page.h>
>
> -       __PAGE_ALIGNED_DATA
> -
>         .globl vdso_start, vdso_end
> +       .section .data..ro_after_init
>         .balign PAGE_SIZE
> vdso_start:
>         .incbin "arch/arm/vdso/vdso.so"
> --
> 2.7.1
>



-- 
Kees Cook
Chrome OS & Brillo Security


From robert.jarzmik at free.fr  Tue Feb 16 13:54:02 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Tue, 16 Feb 2016 22:54:02 +0100
Subject: [PATCH v2] dmaengine: pxa_dma: fix cyclic transfers
Message-ID: <1455659642-7746-1-git-send-email-robert.jarzmik@free.fr>

While testing audio with pxa2xx-ac97, underrun were happening while the
user application was correctly feeding the music. Debug proved that the
cyclic transfer is not cyclic, ie. the last descriptor did not loop on
the first.

Another issue is that the descriptor length was always set to 8192,
because of an trivial operator issue.

This was tested on a pxa27x platform.

Fixes: a57e16cf0333 ("dmaengine: pxa: add pxa dmaengine driver")
Reported-by: Vasily Khoruzhick <anarsoul at gmail.com>
Tested-by: Vasily Khoruzhick <anarsoul at gmail.com>
Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
Since v1: add the mask fix suggested by Vasily
---
 drivers/dma/pxa_dma.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index 8ab4a53e5660..77c1c44009d8 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -586,6 +586,8 @@ static void set_updater_desc(struct pxad_desc_sw *sw_desc,
 		(PXA_DCMD_LENGTH & sizeof(u32));
 	if (flags & DMA_PREP_INTERRUPT)
 		updater->dcmd |= PXA_DCMD_ENDIRQEN;
+	if (sw_desc->cyclic)
+		sw_desc->hw_desc[sw_desc->nb_desc - 2]->ddadr = sw_desc->first;
 }
 
 static bool is_desc_completed(struct virt_dma_desc *vd)
@@ -676,6 +678,10 @@ static irqreturn_t pxad_chan_handler(int irq, void *dev_id)
 		dev_dbg(&chan->vc.chan.dev->device,
 			"%s(): checking txd %p[%x]: completed=%d\n",
 			__func__, vd, vd->tx.cookie, is_desc_completed(vd));
+		if (to_pxad_sw_desc(vd)->cyclic) {
+			vchan_cyclic_callback(vd);
+			break;
+		}
 		if (is_desc_completed(vd)) {
 			list_del(&vd->node);
 			vchan_cookie_complete(vd);
@@ -1084,7 +1090,7 @@ pxad_prep_dma_cyclic(struct dma_chan *dchan,
 		return NULL;
 
 	pxad_get_config(chan, dir, &dcmd, &dsadr, &dtadr);
-	dcmd |= PXA_DCMD_ENDIRQEN | (PXA_DCMD_LENGTH | period_len);
+	dcmd |= PXA_DCMD_ENDIRQEN | (PXA_DCMD_LENGTH & period_len);
 	dev_dbg(&chan->vc.chan.dev->device,
 		"%s(): buf_addr=0x%lx len=%zu period=%zu dir=%d flags=%lx\n",
 		__func__, (unsigned long)buf_addr, len, period_len, dir, flags);
-- 
2.1.4



From keescook at chromium.org  Tue Feb 16 13:55:40 2016
From: keescook at chromium.org (Kees Cook)
Date: Tue, 16 Feb 2016 13:55:40 -0800
Subject: [PATCH] ARM: drop unused DEBUG_RODATA from XIP_KERNEL
In-Reply-To: <alpine.LFD.2.20.1602161539550.13632@knanqh.ubzr>
References: <20160216202957.GA1826@www.outflux.net>
 <alpine.LFD.2.20.1602161539550.13632@knanqh.ubzr>
Message-ID: <CAGXu5jJAzrkoNxj48NRQmfUh2Ej1DOfjZETz2wFJQnO_OxJy-Q@mail.gmail.com>

On Tue, Feb 16, 2016 at 12:41 PM, Nicolas Pitre
<nicolas.pitre at linaro.org> wrote:
> On Tue, 16 Feb 2016, Kees Cook wrote:
>
>> With CONFIG_DEBUG_RODATA not being sensible under XIP_KERNEL, remove it
>> from the XIP linker script.
>
> If so you should also make DEBUG_RODATA depend on !XIP_KERNEL in Kconfig
> to avoid offering a config option that does nothing.

Yeah, that's what Arnd's other patch does. This is intended to follow
his cleanups that do this.

-Kees

>
>> Signed-off-by: Kees Cook <keescook at chromium.org>
>> ---
>> Effectively the patch after Arnd's "ARM: mm: hide
>> __start_rodata_section_aligned for non-debug builds"
>> ---
>>  arch/arm/kernel/vmlinux-xip.lds.S | 10 ----------
>>  1 files changed, 0 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
>> index 40bc4cadb959..cba1ec899a69 100644
>> --- a/arch/arm/kernel/vmlinux-xip.lds.S
>> +++ b/arch/arm/kernel/vmlinux-xip.lds.S
>> @@ -8,9 +8,6 @@
>>  #include <asm/thread_info.h>
>>  #include <asm/memory.h>
>>  #include <asm/page.h>
>> -#ifdef CONFIG_DEBUG_RODATA
>> -#include <asm/pgtable.h>
>> -#endif
>>
>>  #define PROC_INFO                                                    \
>>       . = ALIGN(4);                                                   \
>> @@ -92,10 +89,6 @@ SECTIONS
>>               HEAD_TEXT
>>       }
>>
>> -#ifdef CONFIG_DEBUG_RODATA
>> -     . = ALIGN(1<<SECTION_SHIFT);
>> -#endif
>> -
>>       .text : {                       /* Real text segment            */
>>               _stext = .;             /* Text and read-only data      */
>>                       IDMAP_TEXT
>> @@ -115,9 +108,6 @@ SECTIONS
>>                       ARM_CPU_KEEP(PROC_INFO)
>>       }
>>
>> -#ifdef CONFIG_DEBUG_RODATA
>> -     . = ALIGN(1<<SECTION_SHIFT);
>> -#endif
>>       RO_DATA(PAGE_SIZE)
>>
>>       . = ALIGN(4);
>> --
>> 2.6.3
>>
>>
>> --
>> Kees Cook
>> Chrome OS & Brillo Security
>>
>>



-- 
Kees Cook
Chrome OS & Brillo Security


From mturquette at baylibre.com  Tue Feb 16 13:44:57 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Tue, 16 Feb 2016 13:44:57 -0800
Subject: [PATCH 1/2] clk: bcm2835: Fix setting of PLL divider clock rates
In-Reply-To: <1455591838-22725-1-git-send-email-eric@anholt.net>
References: <1455591838-22725-1-git-send-email-eric@anholt.net>
Message-ID: <20160216214457.2278.13701@quark.deferred.io>

Quoting Eric Anholt (2016-02-15 19:03:57)
> Our dividers weren't being set successfully because CM_PASSWORD wasn't
> included in the register write.  It looks easier to just compute the
> divider to write ourselves than to update clk-divider for the ability
> to OR in some arbitrary bits on write.
> 
> Fixes about half of the video modes on my HDMI monitor (everything
> except 720x400).
> 
> Cc: stable at vger.kernel.org
> Signed-off-by: Eric Anholt <eric at anholt.net>

Applied to clk-next.

Regards,
Mike

> ---
>  drivers/clk/bcm/clk-bcm2835.c | 12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index 015e687..9f4df8f 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -1107,13 +1107,15 @@ static int bcm2835_pll_divider_set_rate(struct clk_hw *hw,
>         struct bcm2835_pll_divider *divider = bcm2835_pll_divider_from_hw(hw);
>         struct bcm2835_cprman *cprman = divider->cprman;
>         const struct bcm2835_pll_divider_data *data = divider->data;
> -       u32 cm;
> -       int ret;
> +       u32 cm, div, max_div = 1 << A2W_PLL_DIV_BITS;
>  
> -       ret = clk_divider_ops.set_rate(hw, rate, parent_rate);
> -       if (ret)
> -               return ret;
> +       div = DIV_ROUND_UP_ULL(parent_rate, rate);
> +
> +       div = min(div, max_div);
> +       if (div == max_div)
> +               div = 0;
>  
> +       cprman_write(cprman, data->a2w_reg, div);
>         cm = cprman_read(cprman, data->cm_reg);
>         cprman_write(cprman, data->cm_reg, cm | data->load_mask);
>         cprman_write(cprman, data->cm_reg, cm & ~data->load_mask);
> -- 
> 2.7.0
> 


From mturquette at baylibre.com  Tue Feb 16 13:45:09 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Tue, 16 Feb 2016 13:45:09 -0800
Subject: [PATCH 2/2] clk: bcm2835: Reuse CLK_DIVIDER_MAX_AT_ZERO for
 recalc_rate()
In-Reply-To: <1455591838-22725-2-git-send-email-eric@anholt.net>
References: <1455591838-22725-1-git-send-email-eric@anholt.net>
 <1455591838-22725-2-git-send-email-eric@anholt.net>
Message-ID: <20160216214509.2278.72829@quark.deferred.io>

Quoting Eric Anholt (2016-02-15 19:03:58)
> We were rolling this ourselves, but clk-divider can do it now.
> 
> Signed-off-by: Eric Anholt <eric at anholt.net>

Applied to clk-next.

Regards,
Mike

> ---
>  drivers/clk/bcm/clk-bcm2835.c | 13 ++-----------
>  1 file changed, 2 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index 9f4df8f..353e438 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -1060,16 +1060,7 @@ static long bcm2835_pll_divider_round_rate(struct clk_hw *hw,
>  static unsigned long bcm2835_pll_divider_get_rate(struct clk_hw *hw,
>                                                   unsigned long parent_rate)
>  {
> -       struct bcm2835_pll_divider *divider = bcm2835_pll_divider_from_hw(hw);
> -       struct bcm2835_cprman *cprman = divider->cprman;
> -       const struct bcm2835_pll_divider_data *data = divider->data;
> -       u32 div = cprman_read(cprman, data->a2w_reg);
> -
> -       div &= (1 << A2W_PLL_DIV_BITS) - 1;
> -       if (div == 0)
> -               div = 256;
> -
> -       return parent_rate / div;
> +       return clk_divider_ops.recalc_rate(hw, parent_rate);
>  }
>  
>  static void bcm2835_pll_divider_off(struct clk_hw *hw)
> @@ -1430,7 +1421,7 @@ bcm2835_register_pll_divider(struct bcm2835_cprman *cprman,
>         divider->div.reg = cprman->regs + data->a2w_reg;
>         divider->div.shift = A2W_PLL_DIV_SHIFT;
>         divider->div.width = A2W_PLL_DIV_BITS;
> -       divider->div.flags = 0;
> +       divider->div.flags = CLK_DIVIDER_MAX_AT_ZERO;
>         divider->div.lock = &cprman->regs_lock;
>         divider->div.hw.init = &init;
>         divider->div.table = NULL;
> -- 
> 2.7.0
> 


From arnd at arndb.de  Tue Feb 16 14:08:13 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 16 Feb 2016 23:08:13 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <2706488.VpKveMVPGI@wuerfel>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
 <s5hr3gc60ph.wl-tiwai@suse.de> <2706488.VpKveMVPGI@wuerfel>
Message-ID: <3395859.dhsfOsmVIe@wuerfel>

On Tuesday 16 February 2016 18:26:09 Arnd Bergmann wrote:
> >                 return err;
> >         per_pin->acomp_jack = jack;
> > -       jack->private_data = per_pin;
> > -       jack->private_free = free_acomp_jack_priv;
> > +       if (jack) {
> > +               jack->private_data = per_pin;
> > +               jack->private_free = free_acomp_jack_priv;
> > +       }
> >         return 0;
> >  }
> > 
> Looks good to me.
> 
> Acked-by: Arnd Bergmann <arnd at arndb.de>
> 

Actually, on second thought, there is one notable downside
of this approach: 'jack' is guaranteed to be NULL here, so gcc
won't produce a warning if another driver makes the same mistake:

By default, we only get a warning for uses of uninitialized
variables, but not those that are known to be NULL. I think
some compiler warnings are able to warn about that too, but I
forgot the details.

	Arnd


From linus.walleij at linaro.org  Tue Feb 16 14:30:30 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 16 Feb 2016 23:30:30 +0100
Subject: [PATCH 00/11] CLCD Nomadik+Versatile support
In-Reply-To: <56C32456.2030800@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <CACRpkda=mgcF8RRymbe0AAKpfCWGZSw_YZP5_6JW2g-mKEt16g@mail.gmail.com>
 <56C32456.2030800@ti.com>
Message-ID: <CACRpkdZ-tH++mR2eD8J2-KETKgSW-peh3Xf0XPqHQD3U0T-FUw@mail.gmail.com>

On Tue, Feb 16, 2016 at 2:29 PM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> On 16/02/16 01:34, Linus Walleij wrote:
>> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
>>
>>> Eventually I would like to have patches 1 thru 8 (those with
>>> patches to CLCD or the DT bindings) applied through the FBDEV
>>> subsystem,
>>
>> If there are no comments, would the fbdev people consider
>> patches 1 thru 8?
>
> Hmm... Is there a v2 for the 05 patch? I see one in my mailbox, but it's
> not sent as a reply to this thread, making it a bit unclear.

Yeah there is a v2, I sent that separately as I didn't have any other
patch to follow up on.

I never figured out how to use in-reply-to sorry... maybe I should
learn it :/

If you prefer I can resent the whole 1 thru 8 series, or does it work
like this too?

Yours,
Linus Walleij


From mturquette at baylibre.com  Tue Feb 16 14:31:58 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Tue, 16 Feb 2016 14:31:58 -0800
Subject: [PATCH v5 0/3] arm64/clk: EXYNOS: Consolidate Exynos7 symbol
In-Reply-To: <1455603632-11158-1-git-send-email-k.kozlowski@samsung.com>
References: <1455603632-11158-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <20160216223158.2278.48998@quark.deferred.io>

Quoting Krzysztof Kozlowski (2016-02-15 22:20:29)
> Hi,
> 
> Patchset attempts to remove the ARCH_EXYNOS7 symbol.
> 
> I rebased this on top of James':
>  - clk: Move vendor's Kconfig into CCF menu section
>    http://www.spinics.net/lists/devicetree/msg111953.html
> 
> The third patch depends on previous ones so one way of merging this
> would be to prepare a tag from clk tree with first two patches
> and the dependency. The last third patch would go through arm-soc.

I've done this locally and things look good. I'm just waiting for Acks
to patch #2 and I'll merge patches #1 and #2 and provide a stable tag
named clk-samsung-kconfig, based on v4.5-rc1.

These patches were not based on -rc1, but the fixups were trivial so I'm
fine with them.

Regards,
Mike

> 
> Changes since v4:
> =================
> 1. Rebased on "clk: Move vendor's Kconfig into CCF menu section"
>    existing in clock tree.
> 2. Re-work patch 2/3 (see specific changelog).
> 
> Changes since v3:
> =================
> 1. Rebase on next-20160127 (s3c64xx became multiplatform).
> 
> Changes since v2:
> =================
> 1. Follow Arnd's advice about not enabling silently the newly added
>    EXYNOS_ARM64_COMMON_CLK, when COMPILE_TEST is enabled. This was
>    also a trigger for some changes in placement of Samsung clocks
>    Kconfig entries...
> 2. ... which lead to introducing patch 1.
> 
> 
> Rationale:
> ==========
> We don't need ARCH_EXYNOS7 symbol because all ARMv8 platforms should
> fall under generic ARCH_EXYNOS. In the same time there is no sense
> in building clocks for these ARMv8 SoCs on ARMv7 builds.
> 
> 
> Best regards,
> Krzysztof
> 
> Krzysztof Kozlowski (3):
>   clk: samsung: Enable COMPILE_TEST for Samsung clocks
>   clk: samsung: Don't build ARMv8 clock drivers on ARMv7
>   arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS
> 
>  arch/arm64/Kconfig.platforms        | 11 ++---------
>  arch/arm64/boot/dts/exynos/Makefile |  2 +-
>  arch/arm64/configs/defconfig        |  2 +-
>  drivers/clk/samsung/Kconfig         | 18 +++++++++++++-----
>  drivers/clk/samsung/Makefile        |  4 ++--
>  5 files changed, 19 insertions(+), 18 deletions(-)
> 
> -- 
> 2.5.0
> 


From mturquette at baylibre.com  Tue Feb 16 14:43:01 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Tue, 16 Feb 2016 14:43:01 -0800
Subject: [RESEND PATCH 1/8] clk: rockchip: add id of the tsadc clock found
 on rk3228 SoCs
In-Reply-To: <1455521613-27340-2-git-send-email-wxt@rock-chips.com>
References: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
 <1455521613-27340-2-git-send-email-wxt@rock-chips.com>
Message-ID: <20160216224301.2278.88600@quark.deferred.io>

Quoting Caesar Wang (2016-02-14 23:33:26)
> This patch adds 'SCLK_TSADC' and 'PCLK_TSADC' id found on rk3228 SoCs.
> That will be needed by TSADC controller.
> 
> Signed-off-by: Caesar Wang <wxt at rock-chips.com>

Acked-by: Michael Turquette <mturquette at baylibre.com>

> ---
> 
>  include/dt-bindings/clock/rk3228-cru.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/dt-bindings/clock/rk3228-cru.h b/include/dt-bindings/clock/rk3228-cru.h
> index a78dd89..cd2e06b 100644
> --- a/include/dt-bindings/clock/rk3228-cru.h
> +++ b/include/dt-bindings/clock/rk3228-cru.h
> @@ -29,6 +29,7 @@
>  #define SCLK_SDMMC             68
>  #define SCLK_SDIO              69
>  #define SCLK_EMMC              71
> +#define SCLK_TSADC             72
>  #define SCLK_UART0             77
>  #define SCLK_UART1             78
>  #define SCLK_UART2             79
> @@ -68,6 +69,7 @@
>  #define PCLK_UART0             341
>  #define PCLK_UART1             342
>  #define PCLK_UART2             343
> +#define PCLK_TSADC             344
>  #define PCLK_PWM               350
>  #define PCLK_TIMER             353
>  #define PCLK_PERI              363
> -- 
> 1.9.1
> 


From mturquette at baylibre.com  Tue Feb 16 14:43:10 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Tue, 16 Feb 2016 14:43:10 -0800
Subject: [RESEND PATCH 2/8] clk: rockchip: add the tsadc clocks found on
 rk3228 SoCs
In-Reply-To: <1455521613-27340-3-git-send-email-wxt@rock-chips.com>
References: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
 <1455521613-27340-3-git-send-email-wxt@rock-chips.com>
Message-ID: <20160216224310.2278.75088@quark.deferred.io>

Quoting Caesar Wang (2016-02-14 23:33:27)
> This patch adds the needed clocks for rk3228 tsadc.
> 
> Signed-off-by: Caesar Wang <wxt at rock-chips.com>

Acked-by: Michael Turquette <mturquette at baylibre.com>

> ---
> 
>  drivers/clk/rockchip/clk-rk3228.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/rockchip/clk-rk3228.c b/drivers/clk/rockchip/clk-rk3228.c
> index c515915..ac014b9 100644
> --- a/drivers/clk/rockchip/clk-rk3228.c
> +++ b/drivers/clk/rockchip/clk-rk3228.c
> @@ -424,7 +424,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[] __initdata = {
>         GATE(0, "sclk_otgphy1", "xin24m", 0,
>                         RK2928_CLKGATE_CON(1), 6, GFLAGS),
>  
> -       COMPOSITE_NOMUX(0, "sclk_tsadc", "xin24m", 0,
> +       COMPOSITE_NOMUX(SCLK_TSADC, "sclk_tsadc", "xin24m", 0,
>                         RK2928_CLKSEL_CON(24), 6, 10, DFLAGS,
>                         RK2928_CLKGATE_CON(2), 8, GFLAGS),
>  
> @@ -584,7 +584,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[] __initdata = {
>         GATE(PCLK_UART0, "pclk_uart0", "pclk_cpu", 0, RK2928_CLKGATE_CON(9), 12, GFLAGS),
>         GATE(PCLK_UART1, "pclk_uart1", "pclk_cpu", 0, RK2928_CLKGATE_CON(9), 13, GFLAGS),
>         GATE(PCLK_UART2, "pclk_uart2", "pclk_cpu", 0, RK2928_CLKGATE_CON(9), 14, GFLAGS),
> -       GATE(0, "pclk_tsadc", "pclk_cpu", 0, RK2928_CLKGATE_CON(9), 15, GFLAGS),
> +       GATE(PCLK_TSADC, "pclk_tsadc", "pclk_cpu", 0, RK2928_CLKGATE_CON(9), 15, GFLAGS),
>         GATE(PCLK_GRF, "pclk_grf", "pclk_cpu", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(10), 0, GFLAGS),
>         GATE(0, "pclk_cru", "pclk_cpu", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(10), 1, GFLAGS),
>         GATE(0, "pclk_sgrf", "pclk_cpu", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(10), 2, GFLAGS),
> -- 
> 1.9.1
> 


From shankerd at codeaurora.org  Tue Feb 16 15:03:33 2016
From: shankerd at codeaurora.org (Shanker Donthineni)
Date: Tue, 16 Feb 2016 17:03:33 -0600
Subject: [PATCH] irqchip/gicv3-its: Avoid cache flush beyond ITS_BASERn
 memory size
In-Reply-To: <20160216083549.5c889627@arm.com>
References: <1455594112-27783-1-git-send-email-shankerd@codeaurora.org>
 <20160216083549.5c889627@arm.com>
Message-ID: <56C3AAC5.7020300@codeaurora.org>

Hi Marc,

On 02/16/2016 02:35 AM, Marc Zyngier wrote:
> On Mon, 15 Feb 2016 21:41:52 -0600
> Shanker Donthineni <shankerd at codeaurora.org> wrote:
>
>> Function its_alloc_tables() maintains two local variables, "order" and
>> and "alloc_size", to hold memory size that has been allocated to
>> ITS_BASEn. We don't always refresh the variable alloc_size whenever
>> value of the variable order changes, causing the following two problems.
>>
>>    - Cache flush operation with size more than required.
>>    - Information reported by pr_info is not correct.
>>
>> Use a helper macro that converts page order to size in bytes instead of
>> variable "alloc_size" to fix both the problems.
>>
>> Signed-off-by: Shanker Donthineni <shankerd at codeaurora.org>
>> ---
>>   drivers/irqchip/irq-gic-v3-its.c | 12 +++++++-----
>>   1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index 0a73632..6f717f7 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -78,6 +78,9 @@ struct its_node {
>>   
>>   #define ITS_ITT_ALIGN		SZ_256
>>   
>> +/* Convert page order to size in bytes */
>> +#define PAGE_ORDER_TO_BYTES(o)	(PAGE_SIZE << (o))
>> +
> nit: PAGE_ORDER_TO_size() seems more appropriate.
>
I will change to PAGE_ORDER_TO_SIZE in v2 patch.

>>   struct event_lpi_map {
>>   	unsigned long		*lpi_map;
>>   	u16			*col_map;
>> @@ -846,7 +849,6 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
>>   		u64 type = GITS_BASER_TYPE(val);
>>   		u64 entry_size = GITS_BASER_ENTRY_SIZE(val);
>>   		int order = get_order(psz);
>> -		int alloc_size;
>>   		int alloc_pages;
>>   		u64 tmp;
>>   		void *base;
>> @@ -878,9 +880,8 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
>>   			}
>>   		}
>>   
>> -		alloc_size = (1 << order) * PAGE_SIZE;
>>   retry_alloc_baser:
>> -		alloc_pages = (alloc_size / psz);
>> +		alloc_pages = (PAGE_ORDER_TO_BYTES(order) / psz);
>>   		if (alloc_pages > GITS_BASER_PAGES_MAX) {
>>   			alloc_pages = GITS_BASER_PAGES_MAX;
>>   			order = get_order(GITS_BASER_PAGES_MAX * psz);
>> @@ -933,7 +934,8 @@ retry_baser:
>>   			shr = tmp & GITS_BASER_SHAREABILITY_MASK;
>>   			if (!shr) {
>>   				cache = GITS_BASER_nC;
>> -				__flush_dcache_area(base, alloc_size);
>> +				__flush_dcache_area(base,
>> +						    PAGE_ORDER_TO_BYTES(order));
> Please keep it on the same line. It helps my random grepping...
Sure, I will keep it on the same line in v2 patch.

>>   			}
>>   			goto retry_baser;
>>   		}
>> @@ -966,7 +968,7 @@ retry_baser:
>>   		}
>>   
>>   		pr_info("ITS: allocated %d %s @%lx (psz %dK, shr %d)\n",
>> -			(int)(alloc_size / entry_size),
>> +			(int)(PAGE_ORDER_TO_BYTES(order) / entry_size),
>>   			its_base_type_string[type],
>>   			(unsigned long)virt_to_phys(base),
>>   			psz / SZ_1K, (int)shr >> GITS_BASER_SHAREABILITY_SHIFT);
>
> Otherwise looks good.
>
> Thanks,
>
> 	M.



From catalin.marinas at arm.com  Tue Feb 16 15:04:12 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 16 Feb 2016 23:04:12 +0000
Subject: [PATCH v2] arm64: add alignment fault hanling
In-Reply-To: <56C39538.6090009@linux.intel.com>
References: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
 <20160216103104.GC14509@arm.com> <56C300AD.8070505@arm.com>
 <20160216122153.GD19413@e104818-lin.cambridge.arm.com>
 <20160216160055.GH14509@arm.com> <20160216170408.GL14509@arm.com>
 <CA+55aFw-86k4gY46Et=e02HQQSxjUK2Jfz0SJz8tWtk5P8YZFA@mail.gmail.com>
 <56C39538.6090009@linux.intel.com>
Message-ID: <20160216230409.GA24379@MBP.local>

On Tue, Feb 16, 2016 at 01:31:36PM -0800, Arjan van de Ven wrote:
> On 2/16/2016 10:50 AM, Linus Torvalds wrote:
> >On Tue, Feb 16, 2016 at 9:04 AM, Will Deacon <will.deacon at arm.com> wrote:
> >>[replying to self and adding some x86 people]
> >>
> >>Background: Euntaik reports a problem where userspace has ended up with
> >>a memory page mapped adjacent to an MMIO page (e.g. from /dev/mem or a
> >>PCI memory bar from someplace in /sys). strncpy_from_user happens with
> >>the word-at-a-time implementation, and we end up reading into the MMIO
> >>page.
> 
> how does this work if the adjacent page is not accessible?

do_strncpy_from_user() assumes by default that it can read a word at a
time using get_user() but checks its return value in case it failed and
falls back to byte at a time. What happens on arm64 is that for
alignment faults we don't have a handler that would search the exception
table and run the get_user() fixup.

> isn't the general rule for such basic functions "don't touch memory
> unless you KNOW it is there"

Well, user access routines are in general safe with this via the
exception handling + fixup mechanism (which usually returns -EFAULT).
That's what do_strncpy_from_user() tries to do by optimising away the
boundary checks.

-- 
Catalin


From shankerd at codeaurora.org  Tue Feb 16 15:08:25 2016
From: shankerd at codeaurora.org (Shanker Donthineni)
Date: Tue, 16 Feb 2016 17:08:25 -0600
Subject: [PATCH] irqchip/gicv3-its: Avoid cache flush beyond ITS_BASERn
 memory size
In-Reply-To: <20160216083549.5c889627@arm.com>
References: <1455594112-27783-1-git-send-email-shankerd@codeaurora.org>
 <20160216083549.5c889627@arm.com>
Message-ID: <56C3ABE9.9070302@codeaurora.org>

Hi Marc,

On 02/16/2016 02:35 AM, Marc Zyngier wrote:
> On Mon, 15 Feb 2016 21:41:52 -0600
> Shanker Donthineni <shankerd at codeaurora.org> wrote:
>
>> Function its_alloc_tables() maintains two local variables, "order" and
>> and "alloc_size", to hold memory size that has been allocated to
>> ITS_BASEn. We don't always refresh the variable alloc_size whenever
>> value of the variable order changes, causing the following two problems.
>>
>>    - Cache flush operation with size more than required.
>>    - Information reported by pr_info is not correct.
>>
>> Use a helper macro that converts page order to size in bytes instead of
>> variable "alloc_size" to fix both the problems.
>>
>> Signed-off-by: Shanker Donthineni <shankerd at codeaurora.org>
>> ---
>>   drivers/irqchip/irq-gic-v3-its.c | 12 +++++++-----
>>   1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index 0a73632..6f717f7 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -78,6 +78,9 @@ struct its_node {
>>   
>>   #define ITS_ITT_ALIGN		SZ_256
>>   
>> +/* Convert page order to size in bytes */
>> +#define PAGE_ORDER_TO_BYTES(o)	(PAGE_SIZE << (o))
>> +
> nit: PAGE_ORDER_TO_size() seems more appropriate.
I will change to PAGE_ORDER_TO_SIZE in v2 patch.
>>   struct event_lpi_map {
>>   	unsigned long		*lpi_map;
>>   	u16			*col_map;
>> @@ -846,7 +849,6 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
>>   		u64 type = GITS_BASER_TYPE(val);
>>   		u64 entry_size = GITS_BASER_ENTRY_SIZE(val);
>>   		int order = get_order(psz);
>> -		int alloc_size;
>>   		int alloc_pages;
>>   		u64 tmp;
>>   		void *base;
>> @@ -878,9 +880,8 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
>>   			}
>>   		}
>>   
>> -		alloc_size = (1 << order) * PAGE_SIZE;
>>   retry_alloc_baser:
>> -		alloc_pages = (alloc_size / psz);
>> +		alloc_pages = (PAGE_ORDER_TO_BYTES(order) / psz);
>>   		if (alloc_pages > GITS_BASER_PAGES_MAX) {
>>   			alloc_pages = GITS_BASER_PAGES_MAX;
>>   			order = get_order(GITS_BASER_PAGES_MAX * psz);
>> @@ -933,7 +934,8 @@ retry_baser:
>>   			shr = tmp & GITS_BASER_SHAREABILITY_MASK;
>>   			if (!shr) {
>>   				cache = GITS_BASER_nC;
>> -				__flush_dcache_area(base, alloc_size);
>> +				__flush_dcache_area(base,
>> +						    PAGE_ORDER_TO_BYTES(order));
> Please keep it on the same line. It helps my random grepping...

Sure, I will keep it on the same line in v2 patch.

>>   			}
>>   			goto retry_baser;
>>   		}
>> @@ -966,7 +968,7 @@ retry_baser:
>>   		}
>>   
>>   		pr_info("ITS: allocated %d %s @%lx (psz %dK, shr %d)\n",
>> -			(int)(alloc_size / entry_size),
>> +			(int)(PAGE_ORDER_TO_BYTES(order) / entry_size),
>>   			its_base_type_string[type],
>>   			(unsigned long)virt_to_phys(base),
>>   			psz / SZ_1K, (int)shr >> GITS_BASER_SHAREABILITY_SHIFT);
>
> Otherwise looks good.
>
> Thanks,
>
> 	M.



From keescook at chromium.org  Tue Feb 16 15:12:24 2016
From: keescook at chromium.org (Kees Cook)
Date: Tue, 16 Feb 2016 15:12:24 -0800
Subject: [PATCH 1/2] ARM: mm: DEBUG_RODATA makes no sense with XIP_KERNEL
In-Reply-To: <CAGXu5jJg4SqrHdJsB-5AzcQbNR-hDZv6YsWayf7LefO+ng4Qhg@mail.gmail.com>
References: <1455638631-3326518-1-git-send-email-arnd@arndb.de>
 <CAGXu5jJg4SqrHdJsB-5AzcQbNR-hDZv6YsWayf7LefO+ng4Qhg@mail.gmail.com>
Message-ID: <CAGXu5jK0wmfiY1SANschub++bxxiL46fvxx-y24vdVzihUX5kg@mail.gmail.com>

On Tue, Feb 16, 2016 at 12:31 PM, Kees Cook <keescook at chromium.org> wrote:
> On Tue, Feb 16, 2016 at 8:03 AM, Arnd Bergmann <arnd at arndb.de> wrote:
>> When CONFIG_DEBUG_ALIGN_RODATA is set, we get a link error:
>>
>> arch/arm/mm/built-in.o:(.data+0x4bc): undefined reference to `__start_rodata_section_aligned'
>>
>> However, this combination is useless, as XIP_KERNEL implies that all the
>> RODATA is already marked readonly, so both CONFIG_DEBUG_RODATA and
>> CONFIG_DEBUG_ALIGN_RODATA (which depends on the other) are not
>> needed with XIP_KERNEL, and this patches enforces that using a Kconfig
>> dependency.
>>
>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>> Fixes: 25362dc496ed ("ARM: 8501/1: mm: flip priority of CONFIG_DEBUG_RODATA")
>
> For this and the 2/2 patch:
>
> Acked-by: Kees Cook <keescook at chromium.org>
>
> I've sent follow-up to clean up the XIP linker script too, if you want
> to take that as the 3rd patch in this series of fixes.

Arnd, when you send your 2 patches to the tracker, can you also send
mine (so the ordering is correct)?

Thanks!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security


From tchalamarla at caviumnetworks.com  Tue Feb 16 15:13:32 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Tue, 16 Feb 2016 15:13:32 -0800
Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <20160216211410.GI25086@rric.localdomain>
References: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160214170152.GC3965@htj.duckdns.org> <56C147B2.9010303@caviumnetworks.com>
 <20160215183041.GH3965@htj.duckdns.org>
 <20160216144250.GD31343@rric.localdomain>
 <56C37524.5090000@caviumnetworks.com> <56C37AD3.4030407@caviumnetworks.com>
 <56C37D94.8080403@caviumnetworks.com>
 <20160216211410.GI25086@rric.localdomain>
Message-ID: <56C3AD1C.2000003@caviumnetworks.com>



On 02/16/2016 01:14 PM, Robert Richter wrote:
> On 16.02.16 11:50:44, Tirumalesh Chalamarla wrote:
>>
>>
>> On 02/16/2016 11:38 AM, David Daney wrote:
>>> On 02/16/2016 11:14 AM, Tirumalesh Chalamarla wrote:
>>>>
>>>>
>>>> On 02/16/2016 06:42 AM, Robert Richter wrote:
>>>>> On 15.02.16 13:30:41, Tejun Heo wrote:
>>>>>> On Sun, Feb 14, 2016 at 07:36:18PM -0800, Tirumalesh Chalamarla wrote:
>>>>>>> There is no need for special Driver, AHCI is sufficient for
>>>>>>> ThunderX, the
>>>>>>> file only contains this interrupt handler,
>>>>>>> is it preferable if this interrupt handler in libahci.c with others,
>>>>>>> instead
>>>>>>> of separate file?
>>>>>>
>>>>>> Yeap, just fold it in ahci.c with surrounding #ifdef guard.
>>>>>
>>>>> Yes, please use #ifdef CONFIG_CAVIUM_ERRATUM_22536 ... and add a
>>>>> kconfig entry for this to arch/arm64/Kconfig.
>>>>>
>>>> Are you sure, this is not a workaround that is based on alternative
>>>> framework rather on pci device and vendor
>>>>
>>>> do you think CONFIG_ARCH_THUNDER a good alternative?
>>>
>>> No.  CONFIG_ARCH_THUNDER should be removed all together.
>>>
>>> Grouping a bunch of unrelated features under a single config variable
>>> creates a very brittle system.  What are you going to do when a new
>>> hardware revision is released?  Create CONFIG_ARCH_THUNDER2?  Which one
>>> of these two would you select if building a kernel?  It is a choice that
>>> we don't want to force users (kernel builders) to have to waste mental
>>> energy on.
>>>
>>> Instead, let's try to make things work out of the box without having to
>>> set a bunch of random config variables.
>>>
>>> If a generic arm64 kernel won't get too bloated, I would suggest just
>>> enabling the compilation of the code unconditionally (at least for
>>> arm64).  The use of the code would still be gated by the PCI version
>>> probe that is part of the patch.
>>>
>>
>> exactly, that is my initial choice with v1, and only depends on vendor and
>> device id.
>>
>> but it seems a config is needed. how about ARCH_ARM64 then?
>
> CONFIG_CAVIUM_ERRATUM_22536 is exactly that you need. It is not only
> used for core interrupts, e.g. also for gicv3 devices (and now also
> for ahci). Non-core errata (e.g. CONFIG_CAVIUM_ERRATUM_23144) are not
> enabled in the arm64 cpu errata framework (not handled in
> arch/arm64/kernel/cpu_errata.c).
>
> Thus,
>
> #ifdef CONFIG_CAVIUM_ERRATUM_22536
> 	if (pdev->vendor == 0x177d && pdev->device == 0xa01c)
> 		ahci_thunderx_init(&pdev->dev, hpriv);
> #endif
>
> is the correct enablement of the workaround by device id.
>
> And, CAVIUM_ERRATUM_* is very easy to handle, enable and document.
>
The code will only run for Thunder and AHCI, becuase its PCI.

> -Robert
>


From shankerd at codeaurora.org  Tue Feb 16 15:27:14 2016
From: shankerd at codeaurora.org (Shanker Donthineni)
Date: Tue, 16 Feb 2016 17:27:14 -0600
Subject: [PATCH] irqchip/gicv3-its: Avoid cache flush beyond ITS_BASERn
 memory size
In-Reply-To: <20160216083549.5c889627@arm.com>
References: <1455594112-27783-1-git-send-email-shankerd@codeaurora.org>
 <20160216083549.5c889627@arm.com>
Message-ID: <56C3B052.3090607@codeaurora.org>

Hi Marc,

On 02/16/2016 02:35 AM, Marc Zyngier wrote:
> On Mon, 15 Feb 2016 21:41:52 -0600
> Shanker Donthineni <shankerd at codeaurora.org> wrote:
>
>> Function its_alloc_tables() maintains two local variables, "order" and
>> and "alloc_size", to hold memory size that has been allocated to
>> ITS_BASEn. We don't always refresh the variable alloc_size whenever
>> value of the variable order changes, causing the following two problems.
>>
>>    - Cache flush operation with size more than required.
>>    - Information reported by pr_info is not correct.
>>
>> Use a helper macro that converts page order to size in bytes instead of
>> variable "alloc_size" to fix both the problems.
>>
>> Signed-off-by: Shanker Donthineni <shankerd at codeaurora.org>
>> ---
>>   drivers/irqchip/irq-gic-v3-its.c | 12 +++++++-----
>>   1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index 0a73632..6f717f7 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -78,6 +78,9 @@ struct its_node {
>>   
>>   #define ITS_ITT_ALIGN		SZ_256
>>   
>> +/* Convert page order to size in bytes */
>> +#define PAGE_ORDER_TO_BYTES(o)	(PAGE_SIZE << (o))
>> +
> nit: PAGE_ORDER_TO_size() seems more appropriate.

I will change to PAGE_ORDER_TO_SIZE in v2 patch.

>>   struct event_lpi_map {
>>   	unsigned long		*lpi_map;
>>   	u16			*col_map;
>> @@ -846,7 +849,6 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
>>   		u64 type = GITS_BASER_TYPE(val);
>>   		u64 entry_size = GITS_BASER_ENTRY_SIZE(val);
>>   		int order = get_order(psz);
>> -		int alloc_size;
>>   		int alloc_pages;
>>   		u64 tmp;
>>   		void *base;
>> @@ -878,9 +880,8 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
>>   			}
>>   		}
>>   
>> -		alloc_size = (1 << order) * PAGE_SIZE;
>>   retry_alloc_baser:
>> -		alloc_pages = (alloc_size / psz);
>> +		alloc_pages = (PAGE_ORDER_TO_BYTES(order) / psz);
>>   		if (alloc_pages > GITS_BASER_PAGES_MAX) {
>>   			alloc_pages = GITS_BASER_PAGES_MAX;
>>   			order = get_order(GITS_BASER_PAGES_MAX * psz);
>> @@ -933,7 +934,8 @@ retry_baser:
>>   			shr = tmp & GITS_BASER_SHAREABILITY_MASK;
>>   			if (!shr) {
>>   				cache = GITS_BASER_nC;
>> -				__flush_dcache_area(base, alloc_size);
>> +				__flush_dcache_area(base,
>> +						    PAGE_ORDER_TO_BYTES(order));
> Please keep it on the same line. It helps my random grepping...

Sure, I will keep it on the same line in v2 patch.

>>   			}
>>   			goto retry_baser;
>>   		}
>> @@ -966,7 +968,7 @@ retry_baser:
>>   		}
>>   
>>   		pr_info("ITS: allocated %d %s @%lx (psz %dK, shr %d)\n",
>> -			(int)(alloc_size / entry_size),
>> +			(int)(PAGE_ORDER_TO_BYTES(order) / entry_size),
>>   			its_base_type_string[type],
>>   			(unsigned long)virt_to_phys(base),
>>   			psz / SZ_1K, (int)shr >> GITS_BASER_SHAREABILITY_SHIFT);
>
> Otherwise looks good.
>
> Thanks,
>
> 	M.



From shankerd at codeaurora.org  Tue Feb 16 16:00:36 2016
From: shankerd at codeaurora.org (Shanker Donthineni)
Date: Tue, 16 Feb 2016 18:00:36 -0600
Subject: [PATCH v2] irqchip/gicv3-its: Avoid cache flush beyond ITS_BASERn
 memory size
Message-ID: <1455667236-14913-1-git-send-email-shankerd@codeaurora.org>

Function its_alloc_tables() maintains two local variables, "order" and
and "alloc_size", to hold memory size that has been allocated to
ITS_BASEn. We don't always refresh the variable alloc_size whenever
value of the variable order changes, causing the following two
problems.

  - Cache flush operation with size more than required.
  - Information reported by pr_info is not correct.

Use a helper macro that converts page order to size in bytes instead of
variable "alloc_size" to fix both the problems.

Signed-off-by: Shanker Donthineni <shankerd at codeaurora.org>
---
[v1] -> [v2]:
   Change the macro name from PAGE_ORDER_TO_BYTES to PAGE_ORDER_TO_SIZE.
   Keep function __flush_dcache_area() arguments on the same line.

 drivers/irqchip/irq-gic-v3-its.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 0a73632..cd07556 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -78,6 +78,9 @@ struct its_node {
 
 #define ITS_ITT_ALIGN		SZ_256
 
+/* Convert page order to size in bytes */
+#define PAGE_ORDER_TO_SIZE(o)	(PAGE_SIZE << (o))
+
 struct event_lpi_map {
 	unsigned long		*lpi_map;
 	u16			*col_map;
@@ -846,7 +849,6 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
 		u64 type = GITS_BASER_TYPE(val);
 		u64 entry_size = GITS_BASER_ENTRY_SIZE(val);
 		int order = get_order(psz);
-		int alloc_size;
 		int alloc_pages;
 		u64 tmp;
 		void *base;
@@ -878,9 +880,8 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
 			}
 		}
 
-		alloc_size = (1 << order) * PAGE_SIZE;
 retry_alloc_baser:
-		alloc_pages = (alloc_size / psz);
+		alloc_pages = (PAGE_ORDER_TO_SIZE(order) / psz);
 		if (alloc_pages > GITS_BASER_PAGES_MAX) {
 			alloc_pages = GITS_BASER_PAGES_MAX;
 			order = get_order(GITS_BASER_PAGES_MAX * psz);
@@ -933,7 +934,7 @@ retry_baser:
 			shr = tmp & GITS_BASER_SHAREABILITY_MASK;
 			if (!shr) {
 				cache = GITS_BASER_nC;
-				__flush_dcache_area(base, alloc_size);
+				__flush_dcache_area(base, PAGE_ORDER_TO_SIZE(order));
 			}
 			goto retry_baser;
 		}
@@ -966,7 +967,7 @@ retry_baser:
 		}
 
 		pr_info("ITS: allocated %d %s @%lx (psz %dK, shr %d)\n",
-			(int)(alloc_size / entry_size),
+			(int)(PAGE_ORDER_TO_SIZE(order) / entry_size),
 			its_base_type_string[type],
 			(unsigned long)virt_to_phys(base),
 			psz / SZ_1K, (int)shr >> GITS_BASER_SHAREABILITY_SHIFT);
-- 
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
a Linux Foundation Collaborative Project



From k.kozlowski at samsung.com  Tue Feb 16 16:00:36 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 17 Feb 2016 09:00:36 +0900
Subject: [PATCH] regulator: s5m8767: fix get_register() error handling
In-Reply-To: <1455634402-1997203-1-git-send-email-arnd@arndb.de>
References: <1455634402-1997203-1-git-send-email-arnd@arndb.de>
Message-ID: <56C3B824.9010808@samsung.com>

On 16.02.2016 23:53, Arnd Bergmann wrote:
> The s5m8767_pmic_probe() function calls s5m8767_get_register() to
> read data without checking the return code, which produces a compile-time
> warning when that data is accessed:
> 
> drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe':
> drivers/regulator/s5m8767.c:924:7: error: 'enable_reg' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> drivers/regulator/s5m8767.c:944:30: error: 'enable_val' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This changes the s5m8767_get_register() function to return a -EINVAL
> not just for an invalid register number but also for an invalid
> regulator number, as both would result in returning uninitialized
> data. The s5m8767_pmic_probe() function is then changed accordingly
> to fail on a read error, as all the other callers of s5m8767_get_register()
> already do.
> 
> In practice this probably cannot happen, as we don't call
> s5m8767_get_register() with invalid arguments, but the gcc
> warning seems valid in principle, in terms writing safe
> error checking.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 9c4c60554acf ("regulator: s5m8767: Convert to use regulator_[enable|disable|is_enabled]_regmap")
> ---
>  drivers/regulator/s5m8767.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 

Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>

Best regards,
Krzysztof



From fengguang.wu at intel.com  Tue Feb 16 16:01:53 2016
From: fengguang.wu at intel.com (kbuild test robot)
Date: Wed, 17 Feb 2016 08:01:53 +0800
Subject: [clk:clk-samsung-kconfig 1/2] drivers/clk/samsung/clk.h:29:26:
 error: field 'clk_data' has incomplete type
Message-ID: <201602170850.V9nmoMr3%fengguang.wu@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-samsung-kconfig
head:   e83cb468452c25597e868d1ed778fa73fdaeca4c
commit: 89e08b1b13374a336dfd1d500ebc70aa545579ab [1/2] clk: samsung: Enable COMPILE_TEST for Samsung clocks
config: ia64-allmodconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout 89e08b1b13374a336dfd1d500ebc70aa545579ab
        # save the attached .config to linux build tree
        make.cross ARCH=ia64 

All error/warnings (new ones prefixed by >>):

   In file included from drivers/clk/samsung/clk-s3c2410.c:18:0:
>> drivers/clk/samsung/clk.h:29:26: error: field 'clk_data' has incomplete type
     struct clk_onecell_data clk_data;
                             ^
>> drivers/clk/samsung/clk.h:142:19: error: 'CLK_SET_RATE_NO_REPARENT' undeclared here (not in a function)
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                      ^
>> drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
>> drivers/clk/samsung/clk-s3c2410.c:99:2: note: in expansion of macro 'MUX'
     MUX(FCLK, "fclk", fclk_p, CLKSLOW, 4, 1),
     ^
>> drivers/clk/samsung/clk-s3c2410.c:102:29: error: array type has incomplete element type
    static struct clk_div_table divslow_d[] = {
                                ^
>> drivers/clk/samsung/clk-s3c2410.c:103:2: error: field name not in record or union initializer
     { .val = 0, .div = 1 },
     ^
   drivers/clk/samsung/clk-s3c2410.c:103:2: error: (near initialization for 'divslow_d')
>> drivers/clk/samsung/clk-s3c2410.c:103:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2410.c:103:2: error: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:104:2: error: field name not in record or union initializer
     { .val = 1, .div = 2 },
     ^
   drivers/clk/samsung/clk-s3c2410.c:104:2: error: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:104:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2410.c:104:2: error: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:105:2: error: field name not in record or union initializer
     { .val = 2, .div = 4 },
     ^
   drivers/clk/samsung/clk-s3c2410.c:105:2: error: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:105:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2410.c:105:2: error: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:106:2: error: field name not in record or union initializer
     { .val = 3, .div = 6 },
     ^
   drivers/clk/samsung/clk-s3c2410.c:106:2: error: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:106:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2410.c:106:2: error: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:107:2: error: field name not in record or union initializer
     { .val = 4, .div = 8 },
     ^
   drivers/clk/samsung/clk-s3c2410.c:107:2: error: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:107:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2410.c:107:2: error: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:108:2: error: field name not in record or union initializer
     { .val = 5, .div = 10 },
     ^
   drivers/clk/samsung/clk-s3c2410.c:108:2: error: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:108:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2410.c:108:2: error: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:109:2: error: field name not in record or union initializer
     { .val = 6, .div = 12 },
     ^
   drivers/clk/samsung/clk-s3c2410.c:109:2: error: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:109:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2410.c:109:2: error: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:110:2: error: field name not in record or union initializer
     { .val = 7, .div = 14 },
     ^
   drivers/clk/samsung/clk-s3c2410.c:110:2: error: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:110:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2410.c:110:2: error: (near initialization for 'divslow_d')
>> drivers/clk/samsung/clk-s3c2410.c:115:2: error: initializer element is not constant
     DIV_T(0, "div_slow", "xti", CLKSLOW, 0, 3, divslow_d),
     ^
   drivers/clk/samsung/clk-s3c2410.c:115:2: error: (near initialization for 's3c2410_common_dividers[0].table')
   In file included from drivers/clk/samsung/clk-s3c2410.c:18:0:
>> drivers/clk/samsung/clk-s3c2410.c:125:46: error: 'CLK_IGNORE_UNUSED' undeclared here (not in a function)
     GATE(PCLK_GPIO, "gpio", "pclk", CLKCON, 13, CLK_IGNORE_UNUSED, 0),
                                                 ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
>> drivers/clk/samsung/clk-s3c2410.c:125:2: note: in expansion of macro 'GATE'
     GATE(PCLK_GPIO, "gpio", "pclk", CLKCON, 13, CLK_IGNORE_UNUSED, 0),
     ^
   drivers/clk/samsung/clk-s3c2410.c:125:2: error: initializer element is not constant
   drivers/clk/samsung/clk-s3c2410.c:125:2: error: (near initialization for 's3c2410_common_gates[5].flags')
   In file included from drivers/clk/samsung/clk-s3c2410.c:18:0:
>> drivers/clk/samsung/clk.h:309:13: error: 'CLK_GET_RATE_NOCACHE' undeclared here (not in a function)
      .flags  = CLK_GET_RATE_NOCACHE,   \
                ^
>> drivers/clk/samsung/clk.h:317:2: note: in expansion of macro '__PLL'
     __PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
     ^
>> drivers/clk/samsung/clk-s3c2410.c:197:11: note: in expansion of macro 'PLL'
     [mpll] = PLL(pll_s3c2410_mpll, MPLL, "mpll", "xti",
              ^
   drivers/clk/samsung/clk-s3c2410.c:197:2: error: initializer element is not constant
     [mpll] = PLL(pll_s3c2410_mpll, MPLL, "mpll", "xti",
     ^
   drivers/clk/samsung/clk-s3c2410.c:197:2: error: (near initialization for 's3c2410_plls[0].flags')
   drivers/clk/samsung/clk-s3c2410.c:199:2: error: initializer element is not constant
     [upll] = PLL(pll_s3c2410_upll, UPLL, "upll", "xti",
     ^
   drivers/clk/samsung/clk-s3c2410.c:199:2: error: (near initialization for 's3c2410_plls[1].flags')
   drivers/clk/samsung/clk-s3c2410.c:263:2: error: initializer element is not constant
     [mpll] = PLL(pll_s3c2440_mpll, MPLL, "mpll", "xti",
     ^
   drivers/clk/samsung/clk-s3c2410.c:263:2: error: (near initialization for 's3c244x_common_plls[0].flags')
   drivers/clk/samsung/clk-s3c2410.c:265:2: error: initializer element is not constant
     [upll] = PLL(pll_s3c2410_upll, UPLL, "upll", "xti",
     ^
   drivers/clk/samsung/clk-s3c2410.c:265:2: error: (near initialization for 's3c244x_common_plls[1].flags')
   In file included from drivers/clk/samsung/clk-s3c2410.c:18:0:
>> drivers/clk/samsung/clk.h:142:17: error: invalid operands to binary | (have 'int' and 'struct samsung_pll_clock *')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                    ^
>> drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-s3c2410.c:273:2: note: in expansion of macro 'MUX'
     MUX(HCLK, "hclk", hclk_p, CLKDIVN, 1, 2),
     ^
   In file included from include/linux/io.h:23:0,
                    from include/linux/clk-provider.h:14,
                    from drivers/clk/samsung/clk-s3c2410.c:11:
>> include/linux/bug.h:33:45: error: initializer element is not constant
    #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
                                                ^
   include/linux/compiler-gcc.h:64:28: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
    #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
                               ^
   include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
    #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
                                                              ^
>> drivers/clk/samsung/clk.h:141:18: note: in expansion of macro 'ARRAY_SIZE'
      .num_parents = ARRAY_SIZE(pnames),  \
                     ^
>> drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-s3c2410.c:273:2: note: in expansion of macro 'MUX'
     MUX(HCLK, "hclk", hclk_p, CLKDIVN, 1, 2),
     ^
   include/linux/bug.h:33:45: error: (near initialization for 's3c244x_common_muxes[0].flags')
    #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
                                                ^
   include/linux/compiler-gcc.h:64:28: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
    #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
                               ^
   include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
    #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
                                                              ^
>> drivers/clk/samsung/clk.h:141:18: note: in expansion of macro 'ARRAY_SIZE'
      .num_parents = ARRAY_SIZE(pnames),  \
                     ^
>> drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-s3c2410.c:273:2: note: in expansion of macro 'MUX'
     MUX(HCLK, "hclk", hclk_p, CLKDIVN, 1, 2),
     ^
   In file included from drivers/clk/samsung/clk-s3c2410.c:18:0:
--
   In file included from drivers/clk/samsung/clk-s3c2412.c:19:0:
>> drivers/clk/samsung/clk.h:29:26: error: field 'clk_data' has incomplete type
     struct clk_onecell_data clk_data;
                             ^
>> drivers/clk/samsung/clk-s3c2412.c:89:29: error: array type has incomplete element type
    static struct clk_div_table divxti_d[] = {
                                ^
>> drivers/clk/samsung/clk-s3c2412.c:90:2: error: field name not in record or union initializer
     { .val = 0, .div = 1 },
     ^
   drivers/clk/samsung/clk-s3c2412.c:90:2: error: (near initialization for 'divxti_d')
>> drivers/clk/samsung/clk-s3c2412.c:90:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2412.c:90:2: error: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:91:2: error: field name not in record or union initializer
     { .val = 1, .div = 2 },
     ^
   drivers/clk/samsung/clk-s3c2412.c:91:2: error: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:91:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2412.c:91:2: error: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:92:2: error: field name not in record or union initializer
     { .val = 2, .div = 4 },
     ^
   drivers/clk/samsung/clk-s3c2412.c:92:2: error: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:92:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2412.c:92:2: error: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:93:2: error: field name not in record or union initializer
     { .val = 3, .div = 6 },
     ^
   drivers/clk/samsung/clk-s3c2412.c:93:2: error: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:93:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2412.c:93:2: error: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:94:2: error: field name not in record or union initializer
     { .val = 4, .div = 8 },
     ^
   drivers/clk/samsung/clk-s3c2412.c:94:2: error: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:94:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2412.c:94:2: error: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:95:2: error: field name not in record or union initializer
     { .val = 5, .div = 10 },
     ^
   drivers/clk/samsung/clk-s3c2412.c:95:2: error: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:95:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2412.c:95:2: error: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:96:2: error: field name not in record or union initializer
     { .val = 6, .div = 12 },
     ^
   drivers/clk/samsung/clk-s3c2412.c:96:2: error: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:96:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2412.c:96:2: error: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:97:2: error: field name not in record or union initializer
     { .val = 7, .div = 14 },
     ^
   drivers/clk/samsung/clk-s3c2412.c:97:2: error: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:97:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2412.c:97:2: error: (near initialization for 'divxti_d')
   In file included from drivers/clk/samsung/clk-s3c2412.c:19:0:
>> drivers/clk/samsung/clk-s3c2412.c:114:38: error: 'CLK_SET_RATE_PARENT' undeclared here (not in a function)
     FFACTOR(0, "ff_hclk", "hclk", 2, 1, CLK_SET_RATE_PARENT),
                                         ^
   drivers/clk/samsung/clk.h:104:13: note: in definition of macro 'FFACTOR'
      .flags  = f,   \
                ^
>> drivers/clk/samsung/clk-s3c2412.c:114:2: error: initializer element is not constant
     FFACTOR(0, "ff_hclk", "hclk", 2, 1, CLK_SET_RATE_PARENT),
     ^
   drivers/clk/samsung/clk-s3c2412.c:114:2: error: (near initialization for 's3c2412_ffactor[0].flags')
   In file included from drivers/clk/samsung/clk-s3c2412.c:19:0:
>> drivers/clk/samsung/clk.h:142:19: error: 'CLK_SET_RATE_NO_REPARENT' undeclared here (not in a function)
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                      ^
>> drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
>> drivers/clk/samsung/clk-s3c2412.c:134:2: note: in expansion of macro 'MUX'
     MUX(0, "erefclk", erefclk_p, CLKSRC, 14, 2),
     ^
>> drivers/clk/samsung/clk.h:142:17: error: invalid operands to binary | (have 'int' and 'struct samsung_fixed_factor_clock *')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                    ^
>> drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
>> drivers/clk/samsung/clk-s3c2412.c:134:2: note: in expansion of macro 'MUX'
     MUX(0, "erefclk", erefclk_p, CLKSRC, 14, 2),
     ^
   In file included from include/linux/io.h:23:0,
                    from include/linux/clk-provider.h:14,
                    from drivers/clk/samsung/clk-s3c2412.c:11:
>> include/linux/bug.h:33:45: error: initializer element is not constant
    #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
                                                ^
   include/linux/compiler-gcc.h:64:28: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
    #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
                               ^
   include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
    #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
                                                              ^
>> drivers/clk/samsung/clk.h:141:18: note: in expansion of macro 'ARRAY_SIZE'
      .num_parents = ARRAY_SIZE(pnames),  \
                     ^
>> drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
>> drivers/clk/samsung/clk-s3c2412.c:134:2: note: in expansion of macro 'MUX'
     MUX(0, "erefclk", erefclk_p, CLKSRC, 14, 2),
     ^
   include/linux/bug.h:33:45: error: (near initialization for 's3c2412_muxes[0].flags')
    #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
                                                ^
   include/linux/compiler-gcc.h:64:28: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
    #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
                               ^
   include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
    #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
                                                              ^
>> drivers/clk/samsung/clk.h:141:18: note: in expansion of macro 'ARRAY_SIZE'
      .num_parents = ARRAY_SIZE(pnames),  \
                     ^
>> drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
>> drivers/clk/samsung/clk-s3c2412.c:134:2: note: in expansion of macro 'MUX'
     MUX(0, "erefclk", erefclk_p, CLKSRC, 14, 2),
     ^
   In file included from drivers/clk/samsung/clk-s3c2412.c:19:0:
>> drivers/clk/samsung/clk.h:142:17: error: invalid operands to binary | (have 'int' and 'struct samsung_fixed_factor_clock *')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                    ^
--
   In file included from drivers/clk/samsung/clk-s3c2443.c:19:0:
>> drivers/clk/samsung/clk.h:29:26: error: field 'clk_data' has incomplete type
     struct clk_onecell_data clk_data;
                             ^
>> drivers/clk/samsung/clk.h:142:19: error: 'CLK_SET_RATE_NO_REPARENT' undeclared here (not in a function)
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                      ^
>> drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
>> drivers/clk/samsung/clk-s3c2443.c:117:2: note: in expansion of macro 'MUX'
     MUX(0, "epllref", epllref_p, CLKSRC, 7, 2),
     ^
>> drivers/clk/samsung/clk-s3c2443.c:125:29: error: array type has incomplete element type
    static struct clk_div_table hclk_d[] = {
                                ^
>> drivers/clk/samsung/clk-s3c2443.c:126:2: error: field name not in record or union initializer
     { .val = 0, .div = 1 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:126:2: error: (near initialization for 'hclk_d')
>> drivers/clk/samsung/clk-s3c2443.c:126:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:126:2: error: (near initialization for 'hclk_d')
   drivers/clk/samsung/clk-s3c2443.c:127:2: error: field name not in record or union initializer
     { .val = 1, .div = 2 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:127:2: error: (near initialization for 'hclk_d')
   drivers/clk/samsung/clk-s3c2443.c:127:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:127:2: error: (near initialization for 'hclk_d')
   drivers/clk/samsung/clk-s3c2443.c:128:2: error: field name not in record or union initializer
     { .val = 3, .div = 4 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:128:2: error: (near initialization for 'hclk_d')
   drivers/clk/samsung/clk-s3c2443.c:128:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:128:2: error: (near initialization for 'hclk_d')
   drivers/clk/samsung/clk-s3c2443.c:132:29: error: array type has incomplete element type
    static struct clk_div_table mdivclk_d[] = {
                                ^
   drivers/clk/samsung/clk-s3c2443.c:133:2: error: field name not in record or union initializer
     { .val = 0, .div = 1 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:133:2: error: (near initialization for 'mdivclk_d')
   drivers/clk/samsung/clk-s3c2443.c:133:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:133:2: error: (near initialization for 'mdivclk_d')
   drivers/clk/samsung/clk-s3c2443.c:134:2: error: field name not in record or union initializer
     { .val = 1, .div = 3 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:134:2: error: (near initialization for 'mdivclk_d')
   drivers/clk/samsung/clk-s3c2443.c:134:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:134:2: error: (near initialization for 'mdivclk_d')
   drivers/clk/samsung/clk-s3c2443.c:135:2: error: field name not in record or union initializer
     { .val = 2, .div = 5 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:135:2: error: (near initialization for 'mdivclk_d')
   drivers/clk/samsung/clk-s3c2443.c:135:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:135:2: error: (near initialization for 'mdivclk_d')
   drivers/clk/samsung/clk-s3c2443.c:136:2: error: field name not in record or union initializer
     { .val = 3, .div = 7 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:136:2: error: (near initialization for 'mdivclk_d')
   drivers/clk/samsung/clk-s3c2443.c:136:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:136:2: error: (near initialization for 'mdivclk_d')
   drivers/clk/samsung/clk-s3c2443.c:137:2: error: field name not in record or union initializer
     { .val = 4, .div = 9 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:137:2: error: (near initialization for 'mdivclk_d')
   drivers/clk/samsung/clk-s3c2443.c:137:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:137:2: error: (near initialization for 'mdivclk_d')
   drivers/clk/samsung/clk-s3c2443.c:138:2: error: field name not in record or union initializer
     { .val = 5, .div = 11 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:138:2: error: (near initialization for 'mdivclk_d')
   drivers/clk/samsung/clk-s3c2443.c:138:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:138:2: error: (near initialization for 'mdivclk_d')
   drivers/clk/samsung/clk-s3c2443.c:139:2: error: field name not in record or union initializer
     { .val = 6, .div = 13 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:139:2: error: (near initialization for 'mdivclk_d')
   drivers/clk/samsung/clk-s3c2443.c:139:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:139:2: error: (near initialization for 'mdivclk_d')
   drivers/clk/samsung/clk-s3c2443.c:140:2: error: field name not in record or union initializer
     { .val = 7, .div = 15 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:140:2: error: (near initialization for 'mdivclk_d')
   drivers/clk/samsung/clk-s3c2443.c:140:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:140:2: error: (near initialization for 'mdivclk_d')
>> drivers/clk/samsung/clk-s3c2443.c:145:2: error: initializer element is not constant
     DIV_T(0, "mdivclk", "xti", CLKDIV0, 6, 3, mdivclk_d),
     ^
   drivers/clk/samsung/clk-s3c2443.c:145:2: error: (near initialization for 's3c2443_common_dividers[0].table')
   drivers/clk/samsung/clk-s3c2443.c:147:2: error: initializer element is not constant
     DIV_T(HCLK, "hclk", "prediv", CLKDIV0, 0, 2, hclk_d),
     ^
   drivers/clk/samsung/clk-s3c2443.c:147:2: error: (near initialization for 's3c2443_common_dividers[2].table')
   In file included from drivers/clk/samsung/clk-s3c2443.c:19:0:
>> drivers/clk/samsung/clk-s3c2443.c:164:47: error: 'CLK_IGNORE_UNUSED' undeclared here (not in a function)
     GATE(HCLK_DRAM, "dram", "hclk", HCLKCON, 19, CLK_IGNORE_UNUSED, 0),
                                                  ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
>> drivers/clk/samsung/clk-s3c2443.c:164:2: note: in expansion of macro 'GATE'
     GATE(HCLK_DRAM, "dram", "hclk", HCLKCON, 19, CLK_IGNORE_UNUSED, 0),
     ^
   drivers/clk/samsung/clk-s3c2443.c:164:2: error: initializer element is not constant
   drivers/clk/samsung/clk-s3c2443.c:164:2: error: (near initialization for 's3c2443_common_gates[6].flags')
   drivers/clk/samsung/clk-s3c2443.c:165:2: error: initializer element is not constant
     GATE(HCLK_SSMC, "ssmc", "hclk", HCLKCON, 18, CLK_IGNORE_UNUSED, 0),
     ^
   drivers/clk/samsung/clk-s3c2443.c:165:2: error: (near initialization for 's3c2443_common_gates[7].flags')
   drivers/clk/samsung/clk-s3c2443.c:170:2: error: initializer element is not constant
     GATE(HCLK_DMA5, "dma5", "hclk", HCLKCON, 5, CLK_IGNORE_UNUSED, 0),
     ^
   drivers/clk/samsung/clk-s3c2443.c:170:2: error: (near initialization for 's3c2443_common_gates[12].flags')
   drivers/clk/samsung/clk-s3c2443.c:171:2: error: initializer element is not constant
     GATE(HCLK_DMA4, "dma4", "hclk", HCLKCON, 4, CLK_IGNORE_UNUSED, 0),
     ^
   drivers/clk/samsung/clk-s3c2443.c:171:2: error: (near initialization for 's3c2443_common_gates[13].flags')
   drivers/clk/samsung/clk-s3c2443.c:172:2: error: initializer element is not constant
     GATE(HCLK_DMA3, "dma3", "hclk", HCLKCON, 3, CLK_IGNORE_UNUSED, 0),
     ^
   drivers/clk/samsung/clk-s3c2443.c:172:2: error: (near initialization for 's3c2443_common_gates[14].flags')
   drivers/clk/samsung/clk-s3c2443.c:173:2: error: initializer element is not constant
     GATE(HCLK_DMA2, "dma2", "hclk", HCLKCON, 2, CLK_IGNORE_UNUSED, 0),
     ^
   drivers/clk/samsung/clk-s3c2443.c:173:2: error: (near initialization for 's3c2443_common_gates[15].flags')
   drivers/clk/samsung/clk-s3c2443.c:174:2: error: initializer element is not constant
     GATE(HCLK_DMA1, "dma1", "hclk", HCLKCON, 1, CLK_IGNORE_UNUSED, 0),
     ^
   drivers/clk/samsung/clk-s3c2443.c:174:2: error: (near initialization for 's3c2443_common_gates[16].flags')
   drivers/clk/samsung/clk-s3c2443.c:175:2: error: initializer element is not constant
     GATE(HCLK_DMA0, "dma0", "hclk", HCLKCON, 0, CLK_IGNORE_UNUSED, 0),
     ^
   drivers/clk/samsung/clk-s3c2443.c:175:2: error: (near initialization for 's3c2443_common_gates[17].flags')
   drivers/clk/samsung/clk-s3c2443.c:176:2: error: initializer element is not constant
     GATE(PCLK_GPIO, "gpio", "pclk", PCLKCON, 13, CLK_IGNORE_UNUSED, 0),
     ^
   drivers/clk/samsung/clk-s3c2443.c:176:2: error: (near initialization for 's3c2443_common_gates[18].flags')
   In file included from drivers/clk/samsung/clk-s3c2443.c:19:0:
>> drivers/clk/samsung/clk.h:309:13: error: 'CLK_GET_RATE_NOCACHE' undeclared here (not in a function)
      .flags  = CLK_GET_RATE_NOCACHE,   \
                ^
>> drivers/clk/samsung/clk.h:317:2: note: in expansion of macro '__PLL'
     __PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
     ^
>> drivers/clk/samsung/clk-s3c2443.c:224:11: note: in expansion of macro 'PLL'
     [mpll] = PLL(pll_6552_s3c2416, 0, "mpll", "mpllref",
              ^
   drivers/clk/samsung/clk-s3c2443.c:224:2: error: initializer element is not constant
     [mpll] = PLL(pll_6552_s3c2416, 0, "mpll", "mpllref",
     ^
   drivers/clk/samsung/clk-s3c2443.c:224:2: error: (near initialization for 's3c2416_pll_clks[0].flags')
   drivers/clk/samsung/clk-s3c2443.c:226:2: error: initializer element is not constant
     [epll] = PLL(pll_6553, 0, "epll", "epllref",
     ^
   drivers/clk/samsung/clk-s3c2443.c:226:2: error: (near initialization for 's3c2416_pll_clks[1].flags')
   drivers/clk/samsung/clk-s3c2443.c:234:29: error: array type has incomplete element type
    static struct clk_div_table armdiv_s3c2416_d[] = {
                                ^
   drivers/clk/samsung/clk-s3c2443.c:235:2: error: field name not in record or union initializer
     { .val = 0, .div = 1 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:235:2: error: (near initialization for 'armdiv_s3c2416_d')
   drivers/clk/samsung/clk-s3c2443.c:235:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:235:2: error: (near initialization for 'armdiv_s3c2416_d')
   drivers/clk/samsung/clk-s3c2443.c:236:2: error: field name not in record or union initializer
     { .val = 1, .div = 2 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:236:2: error: (near initialization for 'armdiv_s3c2416_d')
   drivers/clk/samsung/clk-s3c2443.c:236:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:236:2: error: (near initialization for 'armdiv_s3c2416_d')
   drivers/clk/samsung/clk-s3c2443.c:237:2: error: field name not in record or union initializer
     { .val = 2, .div = 3 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:237:2: error: (near initialization for 'armdiv_s3c2416_d')
   drivers/clk/samsung/clk-s3c2443.c:237:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:237:2: error: (near initialization for 'armdiv_s3c2416_d')
   drivers/clk/samsung/clk-s3c2443.c:238:2: error: field name not in record or union initializer
     { .val = 3, .div = 4 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:238:2: error: (near initialization for 'armdiv_s3c2416_d')
   drivers/clk/samsung/clk-s3c2443.c:238:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:238:2: error: (near initialization for 'armdiv_s3c2416_d')
   drivers/clk/samsung/clk-s3c2443.c:239:2: error: field name not in record or union initializer
     { .val = 5, .div = 6 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:239:2: error: (near initialization for 'armdiv_s3c2416_d')
   drivers/clk/samsung/clk-s3c2443.c:239:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:239:2: error: (near initialization for 'armdiv_s3c2416_d')
   drivers/clk/samsung/clk-s3c2443.c:240:2: error: field name not in record or union initializer
     { .val = 7, .div = 8 },
     ^
   drivers/clk/samsung/clk-s3c2443.c:240:2: error: (near initialization for 'armdiv_s3c2416_d')
   drivers/clk/samsung/clk-s3c2443.c:240:2: error: field name not in record or union initializer
   drivers/clk/samsung/clk-s3c2443.c:240:2: error: (near initialization for 'armdiv_s3c2416_d')
   drivers/clk/samsung/clk-s3c2443.c:245:2: error: initializer element is not constant
     DIV_T(ARMDIV, "armdiv", "msysclk", CLKDIV0, 9, 3, armdiv_s3c2416_d),
     ^
   drivers/clk/samsung/clk-s3c2443.c:245:2: error: (near initialization for 's3c2416_dividers[0].table')
   In file included from drivers/clk/samsung/clk-s3c2443.c:19:0:
>> drivers/clk/samsung/clk.h:142:17: error: invalid operands to binary | (have 'int' and 'struct samsung_div_clock *')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                    ^
>> drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-s3c2443.c:251:2: note: in expansion of macro 'MUX'
     MUX(MUX_HSMMC0, "mux_hsmmc0", s3c2416_hsmmc0_p, CLKSRC, 16, 1),
     ^
   In file included from include/linux/io.h:23:0,
                    from include/linux/clk-provider.h:14,
                    from drivers/clk/samsung/clk-s3c2443.c:11:
>> include/linux/bug.h:33:45: error: initializer element is not constant
    #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
                                                ^
   include/linux/compiler-gcc.h:64:28: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
    #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
                               ^
   include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
    #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
                                                              ^
>> drivers/clk/samsung/clk.h:141:18: note: in expansion of macro 'ARRAY_SIZE'
      .num_parents = ARRAY_SIZE(pnames),  \
                     ^
>> drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-s3c2443.c:251:2: note: in expansion of macro 'MUX'
     MUX(MUX_HSMMC0, "mux_hsmmc0", s3c2416_hsmmc0_p, CLKSRC, 16, 1),
     ^
   include/linux/bug.h:33:45: error: (near initialization for 's3c2416_muxes[0].flags')
    #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
                                                ^
   include/linux/compiler-gcc.h:64:28: note: in expansion of macro 'BUILD_BUG_ON_ZERO'
    #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
                               ^
   include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
    #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
                                                              ^
>> drivers/clk/samsung/clk.h:141:18: note: in expansion of macro 'ARRAY_SIZE'
      .num_parents = ARRAY_SIZE(pnames),  \
                     ^
>> drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-s3c2443.c:251:2: note: in expansion of macro 'MUX'
     MUX(MUX_HSMMC0, "mux_hsmmc0", s3c2416_hsmmc0_p, CLKSRC, 16, 1),
     ^
   In file included from drivers/clk/samsung/clk-s3c2443.c:19:0:

vim +/clk_data +29 drivers/clk/samsung/clk.h

976face4 Rahul Sharma     2014-03-12   23   * @reg_base: virtual address for the register base.
976face4 Rahul Sharma     2014-03-12   24   * @clk_data: holds clock related data like clk* and number of clocks.
2e41b9fc Pankaj Dubey     2014-09-29   25   * @lock: maintains exclusion between callbacks for a given clock-provider.
976face4 Rahul Sharma     2014-03-12   26   */
976face4 Rahul Sharma     2014-03-12   27  struct samsung_clk_provider {
976face4 Rahul Sharma     2014-03-12   28  	void __iomem *reg_base;
976face4 Rahul Sharma     2014-03-12  @29  	struct clk_onecell_data clk_data;
976face4 Rahul Sharma     2014-03-12   30  	spinlock_t lock;
976face4 Rahul Sharma     2014-03-12   31  };
976face4 Rahul Sharma     2014-03-12   32  
976face4 Rahul Sharma     2014-03-12   33  /**
5e2e0195 Heiko Stuebner   2013-03-18   34   * struct samsung_clock_alias: information about mux clock
5e2e0195 Heiko Stuebner   2013-03-18   35   * @id: platform specific id of the clock.
5e2e0195 Heiko Stuebner   2013-03-18   36   * @dev_name: name of the device to which this clock belongs.
5e2e0195 Heiko Stuebner   2013-03-18   37   * @alias: optional clock alias name to be assigned to this clock.
5e2e0195 Heiko Stuebner   2013-03-18   38   */
5e2e0195 Heiko Stuebner   2013-03-18   39  struct samsung_clock_alias {
5e2e0195 Heiko Stuebner   2013-03-18   40  	unsigned int		id;
5e2e0195 Heiko Stuebner   2013-03-18   41  	const char		*dev_name;
5e2e0195 Heiko Stuebner   2013-03-18   42  	const char		*alias;
5e2e0195 Heiko Stuebner   2013-03-18   43  };
5e2e0195 Heiko Stuebner   2013-03-18   44  
5e2e0195 Heiko Stuebner   2013-03-18   45  #define ALIAS(_id, dname, a)	\
5e2e0195 Heiko Stuebner   2013-03-18   46  	{							\
5e2e0195 Heiko Stuebner   2013-03-18   47  		.id		= _id,				\
5e2e0195 Heiko Stuebner   2013-03-18   48  		.dev_name	= dname,			\
5e2e0195 Heiko Stuebner   2013-03-18   49  		.alias		= a,				\
5e2e0195 Heiko Stuebner   2013-03-18   50  	}
5e2e0195 Heiko Stuebner   2013-03-18   51  
d2127ac4 Vikas Sajjan     2013-06-11   52  #define MHZ (1000 * 1000)
d2127ac4 Vikas Sajjan     2013-06-11   53  
5e2e0195 Heiko Stuebner   2013-03-18   54  /**
721c42a3 Thomas Abraham   2013-03-09   55   * struct samsung_fixed_rate_clock: information about fixed-rate clock
721c42a3 Thomas Abraham   2013-03-09   56   * @id: platform specific id of the clock.
721c42a3 Thomas Abraham   2013-03-09   57   * @name: name of this fixed-rate clock.
721c42a3 Thomas Abraham   2013-03-09   58   * @parent_name: optional parent clock name.
721c42a3 Thomas Abraham   2013-03-09   59   * @flags: optional fixed-rate clock flags.
721c42a3 Thomas Abraham   2013-03-09   60   * @fixed-rate: fixed clock rate of this clock.
721c42a3 Thomas Abraham   2013-03-09   61   */
721c42a3 Thomas Abraham   2013-03-09   62  struct samsung_fixed_rate_clock {
721c42a3 Thomas Abraham   2013-03-09   63  	unsigned int		id;
721c42a3 Thomas Abraham   2013-03-09   64  	char			*name;
721c42a3 Thomas Abraham   2013-03-09   65  	const char		*parent_name;
721c42a3 Thomas Abraham   2013-03-09   66  	unsigned long		flags;
721c42a3 Thomas Abraham   2013-03-09   67  	unsigned long		fixed_rate;
721c42a3 Thomas Abraham   2013-03-09   68  };
721c42a3 Thomas Abraham   2013-03-09   69  
721c42a3 Thomas Abraham   2013-03-09   70  #define FRATE(_id, cname, pname, f, frate)		\
721c42a3 Thomas Abraham   2013-03-09   71  	{						\
721c42a3 Thomas Abraham   2013-03-09   72  		.id		= _id,			\
721c42a3 Thomas Abraham   2013-03-09   73  		.name		= cname,		\
721c42a3 Thomas Abraham   2013-03-09   74  		.parent_name	= pname,		\
721c42a3 Thomas Abraham   2013-03-09   75  		.flags		= f,			\
721c42a3 Thomas Abraham   2013-03-09   76  		.fixed_rate	= frate,		\
721c42a3 Thomas Abraham   2013-03-09   77  	}
721c42a3 Thomas Abraham   2013-03-09   78  
721c42a3 Thomas Abraham   2013-03-09   79  /*
721c42a3 Thomas Abraham   2013-03-09   80   * struct samsung_fixed_factor_clock: information about fixed-factor clock
721c42a3 Thomas Abraham   2013-03-09   81   * @id: platform specific id of the clock.
721c42a3 Thomas Abraham   2013-03-09   82   * @name: name of this fixed-factor clock.
721c42a3 Thomas Abraham   2013-03-09   83   * @parent_name: parent clock name.
721c42a3 Thomas Abraham   2013-03-09   84   * @mult: fixed multiplication factor.
721c42a3 Thomas Abraham   2013-03-09   85   * @div: fixed division factor.
721c42a3 Thomas Abraham   2013-03-09   86   * @flags: optional fixed-factor clock flags.
721c42a3 Thomas Abraham   2013-03-09   87   */
721c42a3 Thomas Abraham   2013-03-09   88  struct samsung_fixed_factor_clock {
721c42a3 Thomas Abraham   2013-03-09   89  	unsigned int		id;
721c42a3 Thomas Abraham   2013-03-09   90  	char			*name;
721c42a3 Thomas Abraham   2013-03-09   91  	const char		*parent_name;
721c42a3 Thomas Abraham   2013-03-09   92  	unsigned long		mult;
721c42a3 Thomas Abraham   2013-03-09   93  	unsigned long		div;
721c42a3 Thomas Abraham   2013-03-09   94  	unsigned long		flags;
721c42a3 Thomas Abraham   2013-03-09   95  };
721c42a3 Thomas Abraham   2013-03-09   96  
721c42a3 Thomas Abraham   2013-03-09   97  #define FFACTOR(_id, cname, pname, m, d, f)		\
721c42a3 Thomas Abraham   2013-03-09   98  	{						\
721c42a3 Thomas Abraham   2013-03-09   99  		.id		= _id,			\
721c42a3 Thomas Abraham   2013-03-09  100  		.name		= cname,		\
721c42a3 Thomas Abraham   2013-03-09  101  		.parent_name	= pname,		\
721c42a3 Thomas Abraham   2013-03-09  102  		.mult		= m,			\
721c42a3 Thomas Abraham   2013-03-09  103  		.div		= d,			\
721c42a3 Thomas Abraham   2013-03-09  104  		.flags		= f,			\
721c42a3 Thomas Abraham   2013-03-09  105  	}
721c42a3 Thomas Abraham   2013-03-09  106  
721c42a3 Thomas Abraham   2013-03-09  107  /**
721c42a3 Thomas Abraham   2013-03-09  108   * struct samsung_mux_clock: information about mux clock
721c42a3 Thomas Abraham   2013-03-09  109   * @id: platform specific id of the clock.
721c42a3 Thomas Abraham   2013-03-09  110   * @dev_name: name of the device to which this clock belongs.
721c42a3 Thomas Abraham   2013-03-09  111   * @name: name of this mux clock.
721c42a3 Thomas Abraham   2013-03-09  112   * @parent_names: array of pointer to parent clock names.
721c42a3 Thomas Abraham   2013-03-09  113   * @num_parents: number of parents listed in @parent_names.
721c42a3 Thomas Abraham   2013-03-09  114   * @flags: optional flags for basic clock.
721c42a3 Thomas Abraham   2013-03-09  115   * @offset: offset of the register for configuring the mux.
721c42a3 Thomas Abraham   2013-03-09  116   * @shift: starting bit location of the mux control bit-field in @reg.
721c42a3 Thomas Abraham   2013-03-09  117   * @width: width of the mux control bit-field in @reg.
721c42a3 Thomas Abraham   2013-03-09  118   * @mux_flags: flags for mux-type clock.
721c42a3 Thomas Abraham   2013-03-09  119   * @alias: optional clock alias name to be assigned to this clock.
721c42a3 Thomas Abraham   2013-03-09  120   */
721c42a3 Thomas Abraham   2013-03-09  121  struct samsung_mux_clock {
721c42a3 Thomas Abraham   2013-03-09  122  	unsigned int		id;
721c42a3 Thomas Abraham   2013-03-09  123  	const char		*dev_name;
721c42a3 Thomas Abraham   2013-03-09  124  	const char		*name;
4a1caed3 Uwe Kleine-K?nig 2015-05-28  125  	const char		*const *parent_names;
721c42a3 Thomas Abraham   2013-03-09  126  	u8			num_parents;
721c42a3 Thomas Abraham   2013-03-09  127  	unsigned long		flags;
721c42a3 Thomas Abraham   2013-03-09  128  	unsigned long		offset;
721c42a3 Thomas Abraham   2013-03-09  129  	u8			shift;
721c42a3 Thomas Abraham   2013-03-09  130  	u8			width;
721c42a3 Thomas Abraham   2013-03-09  131  	u8			mux_flags;
721c42a3 Thomas Abraham   2013-03-09  132  	const char		*alias;
721c42a3 Thomas Abraham   2013-03-09  133  };
721c42a3 Thomas Abraham   2013-03-09  134  
721c42a3 Thomas Abraham   2013-03-09  135  #define __MUX(_id, dname, cname, pnames, o, s, w, f, mf, a)	\
721c42a3 Thomas Abraham   2013-03-09  136  	{							\
721c42a3 Thomas Abraham   2013-03-09  137  		.id		= _id,				\
721c42a3 Thomas Abraham   2013-03-09  138  		.dev_name	= dname,			\
721c42a3 Thomas Abraham   2013-03-09  139  		.name		= cname,			\
721c42a3 Thomas Abraham   2013-03-09  140  		.parent_names	= pnames,			\
721c42a3 Thomas Abraham   2013-03-09 @141  		.num_parents	= ARRAY_SIZE(pnames),		\
819c1de3 James Hogan      2013-07-29 @142  		.flags		= (f) | CLK_SET_RATE_NO_REPARENT, \
721c42a3 Thomas Abraham   2013-03-09  143  		.offset		= o,				\
721c42a3 Thomas Abraham   2013-03-09  144  		.shift		= s,				\
721c42a3 Thomas Abraham   2013-03-09  145  		.width		= w,				\
721c42a3 Thomas Abraham   2013-03-09  146  		.mux_flags	= mf,				\
721c42a3 Thomas Abraham   2013-03-09  147  		.alias		= a,				\
721c42a3 Thomas Abraham   2013-03-09  148  	}
721c42a3 Thomas Abraham   2013-03-09  149  
721c42a3 Thomas Abraham   2013-03-09  150  #define MUX(_id, cname, pnames, o, s, w)			\
721c42a3 Thomas Abraham   2013-03-09 @151  	__MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
721c42a3 Thomas Abraham   2013-03-09  152  
721c42a3 Thomas Abraham   2013-03-09  153  #define MUX_A(_id, cname, pnames, o, s, w, a)			\
721c42a3 Thomas Abraham   2013-03-09  154  	__MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, a)

:::::: The code at line 29 was first introduced by commit
:::::: 976face4b46ab36b04312b4e404d160296716d46 clk/samsung: add support for multiple clock providers

:::::: TO: Rahul Sharma <rahul.sharma at samsung.com>
:::::: CC: Tomasz Figa <t.figa at samsung.com>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 42298 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/62a9e6f7/attachment-0001.obj>

From linux at roeck-us.net  Tue Feb 16 16:09:38 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 16 Feb 2016 16:09:38 -0800
Subject: [PATCH v12 4/4] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <CADyBb7s0mf9MLxXeR54wBCPnTBSC7hiNw08C-5vc9EhkORGZww@mail.gmail.com>
References: <1455611785-2407-1-git-send-email-fu.wei@linaro.org>
 <1455611785-2407-5-git-send-email-fu.wei@linaro.org>
 <56C34076.1020206@roeck-us.net>
 <CADyBb7vDuZjjy92WkV_jML2Ji13LvtuqkKszAetzvoM47CaY7Q@mail.gmail.com>
 <CADyBb7s0mf9MLxXeR54wBCPnTBSC7hiNw08C-5vc9EhkORGZww@mail.gmail.com>
Message-ID: <20160217000938.GA19355@roeck-us.net>

On Wed, Feb 17, 2016 at 12:33:24AM +0800, Fu Wei wrote:
[ ... ]
> >>> +MODULE_AUTHOR("Fu Wei <fu.wei at linaro.org>");
> >>> +MODULE_AUTHOR("Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>");
> >>> +MODULE_AUTHOR("Al Stone <al.stone at linaro.org>");
> >>> +MODULE_AUTHOR("Timur Tabi <timur at codeaurora.org>");
> >>> +MODULE_LICENSE("GPL v2");
> >>>
> >> Do you need a MODULE_ALIAS ?
> >
> > For now, I thinks we don't need it, Hope I didn't miss something :-)
> > Because this module can be mounted automatically with dtb or ACPI(if
> > apply my GTDT patch).
> > Do you have any suggestion or concern? :-)
> 
> re-think  about that , will add
> MODULE_ALIAS("platform:sbsa-gwdt");
> 
> Do you agree ?  :-)
> 
Sure.

Guenter


From stefan at agner.ch  Tue Feb 16 16:18:37 2016
From: stefan at agner.ch (Stefan Agner)
Date: Tue, 16 Feb 2016 16:18:37 -0800
Subject: [PATCH v2 3/3] ARM: dts: vf-colibri: add carrier boards 3.3V supply
In-Reply-To: <1455668317-15728-1-git-send-email-stefan@agner.ch>
References: <1455668317-15728-1-git-send-email-stefan@agner.ch>
Message-ID: <1455668317-15728-3-git-send-email-stefan@agner.ch>

Add the carrier boards 3.3V supply as fixed regulator. This allows
to specify the power supply for nodes like backlight.

Signed-off-by: Stefan Agner <stefan at agner.ch>
---
 arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
index ca061c9..f9598b8 100644
--- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -50,6 +50,14 @@
 		clock-frequency = <16000000>;
 	};
 
+	reg_3v3: regulator-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "3.3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
 	reg_5v0: regulator-5v0 {
 		compatible = "regulator-fixed";
 		regulator-name = "5V";
@@ -73,6 +81,7 @@
 &bl {
 	brightness-levels = <0 4 8 16 32 64 128 255>;
 	default-brightness-level = <6>;
+	power-supply = <&reg_3v3>;
 	status  = "okay";
 };
 
@@ -123,6 +132,10 @@
 	status = "okay";
 };
 
+&reg_module_3v3 {
+	vin-supply = <&reg_3v3>;
+};
+
 &uart0 {
 	status = "okay";
 };
-- 
2.7.1



From stefan at agner.ch  Tue Feb 16 16:18:36 2016
From: stefan at agner.ch (Stefan Agner)
Date: Tue, 16 Feb 2016 16:18:36 -0800
Subject: [PATCH v2 2/3] ARM: dts: vf-colibri: add basic supply regulators
In-Reply-To: <1455668317-15728-1-git-send-email-stefan@agner.ch>
References: <1455668317-15728-1-git-send-email-stefan@agner.ch>
Message-ID: <1455668317-15728-2-git-send-email-stefan@agner.ch>

Colibri modules need to be powered using the power pins 3V3 and
AVDD_AUDIO. Add fixed regulators which represent this power rails.
Potentially, those power rails could be switched on a carrier
board. A carrier board device tree could add a own regulator with
a GPIO, and reference that regulator in a vin-supply property of
those new module level system regulators.

Signed-off-by: Stefan Agner <stefan at agner.ch>
---
Changes since v1:
- Add module prefix to avoid namespace issue with Carrier Board regulators
- Name the regulators according to schematics

 arch/arm/boot/dts/vf-colibri.dtsi | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi b/arch/arm/boot/dts/vf-colibri.dtsi
index ff6f58e..dcc73b7 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -48,14 +48,32 @@
 		enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
 		status = "disabled";
 	};
+
+	reg_module_3v3: regulator-module-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "+V3.3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
+	reg_module_3v3_avdd: regulator-module-3v3-avdd {
+		compatible = "regulator-fixed";
+		regulator-name = "+V3.3_AVDD_AUDIO";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
 };
 
 &adc0 {
 	status = "okay";
+	vref-supply = <&reg_module_3v3_avdd>;
 };
 
 &adc1 {
 	status = "okay";
+	vref-supply = <&reg_module_3v3_avdd>;
 };
 
 &can0 {
@@ -96,6 +114,7 @@
 
 &fec1 {
 	phy-mode = "rmii";
+	phy-supply = <&reg_module_3v3>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_fec1>;
 };
-- 
2.7.1



From stefan at agner.ch  Tue Feb 16 16:18:35 2016
From: stefan at agner.ch (Stefan Agner)
Date: Tue, 16 Feb 2016 16:18:35 -0800
Subject: [PATCH v2 1/3] ARM: dts: vf-colibri: remove regulator container node
Message-ID: <1455668317-15728-1-git-send-email-stefan@agner.ch>

Drop the fake simple-bus container 'regulators' and put the
regulators directly under the root node. This also makes the
artificial 'reg' properties superfluous. While at it, name
the regulators according to schematics.

Signed-off-by: Stefan Agner <stefan at agner.ch>
---
Changes since v1:
- Rename regulators according to schematics
- Drop sys prefix

 arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 43 ++++++++++++-------------------
 1 file changed, 17 insertions(+), 26 deletions(-)

diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
index b494673..ca061c9 100644
--- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -50,32 +50,23 @@
 		clock-frequency = <16000000>;
 	};
 
-	regulators {
-		compatible = "simple-bus";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		sys_5v0_reg: regulator at 0 {
-			compatible = "regulator-fixed";
-			reg = <0>;
-			regulator-name = "5v0";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			regulator-always-on;
-		};
+	reg_5v0: regulator-5v0 {
+		compatible = "regulator-fixed";
+		regulator-name = "5V";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
 
-		/* USBH_PEN */
-		usbh_vbus_reg: regulator at 1 {
-			compatible = "regulator-fixed";
-			pinctrl-names = "default";
-			pinctrl-0 = <&pinctrl_usbh1_reg>;
-			reg = <1>;
-			regulator-name = "usbh_vbus";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			gpio = <&gpio2 19 GPIO_ACTIVE_LOW>;
-			vin-supply = <&sys_5v0_reg>;
-		};
+	reg_usbh_vbus: regulator-usbh-vbus {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbh1_reg>;
+		regulator-name = "VCC_USB[1-4]";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpio = <&gpio2 19 GPIO_ACTIVE_LOW>; /* USBH_PEN resp. USBH_P_EN */
+		vin-supply = <&reg_5v0>;
 	};
 };
 
@@ -145,7 +136,7 @@
 };
 
 &usbh1 {
-	vbus-supply = <&usbh_vbus_reg>;
+	vbus-supply = <&reg_usbh_vbus>;
 };
 
 &iomuxc {
-- 
2.7.1



From jay.xu at rock-chips.com  Tue Feb 16 16:21:58 2016
From: jay.xu at rock-chips.com (Jianqun Xu)
Date: Wed, 17 Feb 2016 08:21:58 +0800
Subject: [PATCH] spi/rockchip: Add dt-binding for Rockchip rk3399 spi
In-Reply-To: <1730751.NYv1NxJVuB@phil>
References: <1455614538-4415-1-git-send-email-jay.xu@rock-chips.com>
 <20160216132223.GM18327@sirena.org.uk> <1730751.NYv1NxJVuB@phil>
Message-ID: <56C3BD26.3030704@rock-chips.com>

Hi Heiko

? 16/02/2016 22:37, Heiko Stuebner ??:
> Am Dienstag, 16. Februar 2016, 13:22:23 schrieb Mark Brown:
>> On Tue, Feb 16, 2016 at 05:22:18PM +0800, jianqun.xu wrote:
>>>   Documentation/devicetree/bindings/spi/spi-rockchip.txt | 1 +
>>>   1 file changed, 1 insertion(+)
>>
>> I'd expect this to be added to both the driver and the binding document
>> not just the document.
>
> It seems the driver can still use the rk3066-variant - aka nobody has found
> specific issues in the rk3399 IP implementation.
>
> Having the more specific IP names already in the dts before actually using
> them was suggested by devicetree people to not have to exchange everything
> once specific issues were found.
>
> So right now it's using the fallback-mechanism of binding to the rk3066
> name, but if some obstacle appears it will only take adding the binding in
> the driver to make it work (even with old devicetrees).
>
>
Thank you, got it, and I will re-send this patch with the driver patch.
>



From festevam at gmail.com  Tue Feb 16 16:28:05 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Tue, 16 Feb 2016 22:28:05 -0200
Subject: [PATCH v2 2/3] ARM: dts: vf-colibri: add basic supply regulators
In-Reply-To: <1455668317-15728-2-git-send-email-stefan@agner.ch>
References: <1455668317-15728-1-git-send-email-stefan@agner.ch>
 <1455668317-15728-2-git-send-email-stefan@agner.ch>
Message-ID: <CAOMZO5Bb1eGSinoNkUhB_2w8mWdA+RQA0Z4geJp8B-MfGryAHw@mail.gmail.com>

On Tue, Feb 16, 2016 at 10:18 PM, Stefan Agner <stefan at agner.ch> wrote:

> +       reg_module_3v3: regulator-module-3v3 {
> +               compatible = "regulator-fixed";
> +               regulator-name = "+V3.3";
> +               regulator-min-microvolt = <3300000>;
> +               regulator-max-microvolt = <3300000>;
> +               regulator-always-on;

This 'regulator-always-on' property can be removed.

> +       };
> +
> +       reg_module_3v3_avdd: regulator-module-3v3-avdd {
> +               compatible = "regulator-fixed";
> +               regulator-name = "+V3.3_AVDD_AUDIO";
> +               regulator-min-microvolt = <3300000>;
> +               regulator-max-microvolt = <3300000>;
> +               regulator-always-on;

Same here.


From torvalds at linux-foundation.org  Tue Feb 16 16:28:46 2016
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Tue, 16 Feb 2016 16:28:46 -0800
Subject: [PATCH v2] arm64: add alignment fault hanling
In-Reply-To: <CA+55aFz+ttJoEG_WkpkwV=+Wunzxpj9NoHobq-8oFZS0HEEyeA@mail.gmail.com>
References: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
 <20160216103104.GC14509@arm.com> <56C300AD.8070505@arm.com>
 <20160216122153.GD19413@e104818-lin.cambridge.arm.com>
 <20160216160055.GH14509@arm.com> <20160216170408.GL14509@arm.com>
 <CA+55aFw-86k4gY46Et=e02HQQSxjUK2Jfz0SJz8tWtk5P8YZFA@mail.gmail.com>
 <56C39538.6090009@linux.intel.com>
 <CA+55aFz+ttJoEG_WkpkwV=+Wunzxpj9NoHobq-8oFZS0HEEyeA@mail.gmail.com>
Message-ID: <CA+55aFyr56yHSzWA77-+P4hm2nzUgx0cea7Zk8YD0YqJv1W43w@mail.gmail.com>

On Tue, Feb 16, 2016 at 1:42 PM, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> On Feb 16, 2016 1:31 PM, "Arjan van de Ven" <arjan at linux.intel.com> wrote:
>>
>> but what happens to the read if the page isn't present?
>> or is execute-only or .. or ..
>
> If we actually get a fault and handle the exception (not handling the
> exception was the problem on arm), the exception code will just cut off the
> pathname at the page boundary.
>
> So it will see the accessible part, and get zeroes for the inaccessible one.

Actually, looking closer, we only do that for the kernel case (where
pagealloc-debug can cause the unaligned path component in *kernel*
space to trap).

I misremembered because I considered doing it for user accesses too,
but as Catalin correctly says, there we don't actually end up being
that clever, and we just fall back to byte-at-a-time. Which means that
we do get the exact EFAULT behavior even though I'm not 100% convinced
we need to.

See the use of "load_unaligned_zeropad()"  (in the dcache handling) vs
just "get_user()" (in strncpy_from_user()).

The fault case doesn't actually ever happen in practice.

The IS_UNALIGNED() case (on architectures with inefficient unaligned
handling), which also falls back to the byte-at-a-time model, is
likely a much bigger problem. They probably need their own strncpy if
they care about performance. But the common architectures all happily
do efficient unaligneds these days.

             Linus


From gregkh at linuxfoundation.org  Tue Feb 16 16:43:51 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Tue, 16 Feb 2016 16:43:51 -0800
Subject: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag
In-Reply-To: <20160216111426.GA22133@e106950-lin.cambridge.arm.com>
References: <cover.1454950917.git.brian.starkey@arm.com>
 <9085d37fa97a762a46b9d58719c085368682c64f.1454950917.git.brian.starkey@arm.com>
 <20160208183006.GA8429@kroah.com>
 <20160209091501.GA23507@e106950-lin.cambridge.arm.com>
 <20160216111426.GA22133@e106950-lin.cambridge.arm.com>
Message-ID: <20160217004351.GE3037@kroah.com>

On Tue, Feb 16, 2016 at 11:14:26AM +0000, Brian Starkey wrote:
> Hi Greg,
> 
> Is the documentation OK? Is there any chance of you picking up this
> series?
> 
> I can rebase onto -next if that's the right place, but they still apply
> on 4.5-rc4 and fix a panic, so I thought perhaps they could make 4.5.

I think memory stuff like this goes through Andrew's tree, not mine...

thanks,

greg k-h


From mturquette at baylibre.com  Tue Feb 16 16:46:48 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Tue, 16 Feb 2016 16:46:48 -0800
Subject: [RESEND PATCH v8 1/6] clk: hisilicon: add CRG driver for hi3519
 soc
In-Reply-To: <1454639472-17373-2-git-send-email-xuejiancheng@huawei.com>
References: <1454639472-17373-1-git-send-email-xuejiancheng@huawei.com>
 <1454639472-17373-2-git-send-email-xuejiancheng@huawei.com>
Message-ID: <20160217004648.2278.64006@quark.deferred.io>

Hello Jiancheng Xue,

Quoting Jiancheng Xue (2016-02-04 18:31:07)
> diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
> index 74dba31..3f57b09 100644
> --- a/drivers/clk/hisilicon/Makefile
> +++ b/drivers/clk/hisilicon/Makefile
> @@ -4,8 +4,10 @@
>  
>  obj-y  += clk.o clkgate-separated.o clkdivider-hi6220.o
>  
> +obj-$(CONFIG_RESET_CONTROLLER) += reset.o

Do you really want to build reset.o for all hisi SoCs?

>  obj-$(CONFIG_ARCH_HI3xxx)      += clk-hi3620.o
>  obj-$(CONFIG_ARCH_HIP04)       += clk-hip04.o
>  obj-$(CONFIG_ARCH_HIX5HD2)     += clk-hix5hd2.o
>  obj-$(CONFIG_COMMON_CLK_HI6220)        += clk-hi6220.o
>  obj-$(CONFIG_STUB_CLK_HI6220)  += clk-hi6220-stub.o
> +obj-$(CONFIG_COMMON_CLK_HI3519)        += clk-hi3519.o
> diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
> new file mode 100644
> index 0000000..ed983af
> --- /dev/null
> +++ b/drivers/clk/hisilicon/clk-hi3519.c
> @@ -0,0 +1,133 @@
> +/*
> + * Hi3519 Clock Driver
> + *
> + * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * 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 <dt-bindings/clock/hi3519-clock.h>
> +#include <linux/delay.h>

Remove this header.

> +#include <linux/module.h>
> +#include <linux/of_address.h>

Remove this header.

> +#include <linux/of_platform.h>

Remove this header.

> +#include <linux/platform_device.h>
> +#include <linux/slab.h>

Remove this header.

> diff --git a/drivers/clk/hisilicon/clk.c b/drivers/clk/hisilicon/clk.c
> index 9f8e766..06ec3fe 100644
> --- a/drivers/clk/hisilicon/clk.c
> +++ b/drivers/clk/hisilicon/clk.c
> @@ -37,7 +37,7 @@
>  
>  static DEFINE_SPINLOCK(hisi_clk_lock);
>  
> -struct hisi_clock_data __init *hisi_clk_init(struct device_node *np,
> +struct hisi_clock_data *hisi_clk_init(struct device_node *np,
>                                              int nr_clks)
>  {
>         struct hisi_clock_data *clk_data;
> @@ -71,8 +71,9 @@ err_data:
>  err:
>         return NULL;
>  }
> +EXPORT_SYMBOL(hisi_clk_init);
>  
> -void __init hisi_clk_register_fixed_rate(struct hisi_fixed_rate_clock *clks,
> +void hisi_clk_register_fixed_rate(const struct hisi_fixed_rate_clock *clks,
>                                          int nums, struct hisi_clock_data *data)
>  {
>         struct clk *clk;
> @@ -91,8 +92,9 @@ void __init hisi_clk_register_fixed_rate(struct hisi_fixed_rate_clock *clks,
>                 data->clk_data.clks[clks[i].id] = clk;
>         }
>  }
> +EXPORT_SYMBOL(hisi_clk_register_fixed_rate);
>  
> -void __init hisi_clk_register_fixed_factor(struct hisi_fixed_factor_clock *clks,
> +void hisi_clk_register_fixed_factor(const struct hisi_fixed_factor_clock *clks,
>                                            int nums,
>                                            struct hisi_clock_data *data)
>  {
> @@ -112,8 +114,9 @@ void __init hisi_clk_register_fixed_factor(struct hisi_fixed_factor_clock *clks,
>                 data->clk_data.clks[clks[i].id] = clk;
>         }
>  }
> +EXPORT_SYMBOL(hisi_clk_register_fixed_factor);
>  
> -void __init hisi_clk_register_mux(struct hisi_mux_clock *clks,
> +void hisi_clk_register_mux(const struct hisi_mux_clock *clks,
>                                   int nums, struct hisi_clock_data *data)
>  {
>         struct clk *clk;
> @@ -141,8 +144,9 @@ void __init hisi_clk_register_mux(struct hisi_mux_clock *clks,
>                 data->clk_data.clks[clks[i].id] = clk;
>         }
>  }
> +EXPORT_SYMBOL(hisi_clk_register_mux);
>  
> -void __init hisi_clk_register_divider(struct hisi_divider_clock *clks,
> +void hisi_clk_register_divider(const struct hisi_divider_clock *clks,
>                                       int nums, struct hisi_clock_data *data)
>  {
>         struct clk *clk;
> @@ -170,8 +174,9 @@ void __init hisi_clk_register_divider(struct hisi_divider_clock *clks,
>                 data->clk_data.clks[clks[i].id] = clk;
>         }
>  }
> +EXPORT_SYMBOL(hisi_clk_register_divider);
>  
> -void __init hisi_clk_register_gate(struct hisi_gate_clock *clks,
> +void hisi_clk_register_gate(const struct hisi_gate_clock *clks,
>                                        int nums, struct hisi_clock_data *data)
>  {
>         struct clk *clk;
> @@ -198,8 +203,9 @@ void __init hisi_clk_register_gate(struct hisi_gate_clock *clks,
>                 data->clk_data.clks[clks[i].id] = clk;
>         }
>  }
> +EXPORT_SYMBOL(hisi_clk_register_gate);
>  
> -void __init hisi_clk_register_gate_sep(struct hisi_gate_clock *clks,
> +void hisi_clk_register_gate_sep(const struct hisi_gate_clock *clks,
>                                        int nums, struct hisi_clock_data *data)
>  {
>         struct clk *clk;
> @@ -226,8 +232,9 @@ void __init hisi_clk_register_gate_sep(struct hisi_gate_clock *clks,
>                 data->clk_data.clks[clks[i].id] = clk;
>         }
>  }
> +EXPORT_SYMBOL(hisi_clk_register_gate_sep);
>  
> -void __init hi6220_clk_register_divider(struct hi6220_divider_clock *clks,
> +void __init hi6220_clk_register_divider(const struct hi6220_divider_clock *clks,
>                                         int nums, struct hisi_clock_data *data)

It would have been better to break out all of the changes to clk.c into
a separate patch.

>  {
>         struct clk *clk;
> diff --git a/drivers/clk/hisilicon/clk.h b/drivers/clk/hisilicon/clk.h
> index b56fbc1..20d64af 100644
> --- a/drivers/clk/hisilicon/clk.h
> +++ b/drivers/clk/hisilicon/clk.h
> @@ -111,18 +111,18 @@ struct clk *hi6220_register_clkdiv(struct device *dev, const char *name,
>         u8 shift, u8 width, u32 mask_bit, spinlock_t *lock);
>  
>  struct hisi_clock_data *hisi_clk_init(struct device_node *, int);
> -void hisi_clk_register_fixed_rate(struct hisi_fixed_rate_clock *,
> +void hisi_clk_register_fixed_rate(const struct hisi_fixed_rate_clock *,
>                                 int, struct hisi_clock_data *);
> -void hisi_clk_register_fixed_factor(struct hisi_fixed_factor_clock *,
> +void hisi_clk_register_fixed_factor(const struct hisi_fixed_factor_clock *,
>                                 int, struct hisi_clock_data *);
> -void hisi_clk_register_mux(struct hisi_mux_clock *, int,
> +void hisi_clk_register_mux(const struct hisi_mux_clock *, int,
>                                 struct hisi_clock_data *);
> -void hisi_clk_register_divider(struct hisi_divider_clock *,
> +void hisi_clk_register_divider(const struct hisi_divider_clock *,
>                                 int, struct hisi_clock_data *);
> -void hisi_clk_register_gate(struct hisi_gate_clock *,
> +void hisi_clk_register_gate(const struct hisi_gate_clock *,
>                                 int, struct hisi_clock_data *);
> -void hisi_clk_register_gate_sep(struct hisi_gate_clock *,
> +void hisi_clk_register_gate_sep(const struct hisi_gate_clock *,
>                                 int, struct hisi_clock_data *);
> -void hi6220_clk_register_divider(struct hi6220_divider_clock *,
> +void hi6220_clk_register_divider(const struct hi6220_divider_clock *,
>                                 int, struct hisi_clock_data *);
>  #endif /* __HISI_CLK_H */

Ditto.

> diff --git a/drivers/clk/hisilicon/reset.c b/drivers/clk/hisilicon/reset.c
> new file mode 100644
> index 0000000..4fc7c8f
> --- /dev/null
> +++ b/drivers/clk/hisilicon/reset.c
> @@ -0,0 +1,130 @@
> +/*
> + * Hisilicon Reset Controller Driver
> + *
> + * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * 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/err.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset-controller.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +#include <linux/types.h>

I didn't look into these headers but I'm guessing they aren't all
needed?

Best regards,
Mike


From mturquette at baylibre.com  Tue Feb 16 16:56:29 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Tue, 16 Feb 2016 16:56:29 -0800
Subject: [PATCH 1/2] clk: add lpc18xx creg clk driver
In-Reply-To: <CAGhQ9VzOYbHsFZQxM8823OiWpGB6vLEwX8LfvjC=DnL1iqK_qQ@mail.gmail.com>
References: <1436651307-24098-1-git-send-email-manabian@gmail.com>
 <1436651307-24098-2-git-send-email-manabian@gmail.com>
 <20150811204127.31346.16729@quantum>
 <CAGhQ9VwZaM_iWTkQYVTuTiyb6gCG2y6s8WFVySCHt7YHE1qbcA@mail.gmail.com>
 <20150818002604.31346.18322@quantum>
 <CAGhQ9VzOYbHsFZQxM8823OiWpGB6vLEwX8LfvjC=DnL1iqK_qQ@mail.gmail.com>
Message-ID: <20160217005629.2278.90197@quark.deferred.io>

Quoting Joachim Eastwood (2016-02-13 06:38:45)
> Hi Mike,
> 
> Seems your reply got lost in my mailbox and I didn't notice it before
> Stephen replied on the cover letter. Sorry about that.
> 
> On 18 August 2015 at 02:26, Michael Turquette <mturquette at baylibre.com> wrote:
> > Quoting Joachim Eastwood (2015-08-13 13:43:11)
> >> On 11 August 2015 at 22:41, Michael Turquette <mturquette at baylibre.com> wrote:
> >> > Hi Joachim,
> >> >
> >> > Quoting Joachim Eastwood (2015-07-11 14:48:26)
> >> >> +static void __init lpc18xx_creg_clk_init(struct device_node *np)
> >> >> +{
> >> >> +       const char *clk_32khz_parent;
> >> >> +       struct regmap *syscon;
> >> >> +
> >> >> +       syscon = syscon_node_to_regmap(np->parent);
> >> >> +       if (IS_ERR(syscon)) {
> >> >> +               pr_err("%s: syscon lookup failed\n", __func__);
> >> >> +               return;
> >> >> +       }
> >> >> +
> >> >> +       clk_32khz_parent = of_clk_get_parent_name(np, 0);
> >> >> +
> >> >> +       clk_creg[CREG_CLK_32KHZ] =
> >> >> +               clk_register_creg_clk(&clk_creg_clocks[CREG_CLK_32KHZ],
> >> >> +                                     &clk_32khz_parent, syscon);
> >> >> +
> >> >> +       clk_creg[CREG_CLK_1KHZ] =
> >> >> +               clk_register_creg_clk(&clk_creg_clocks[CREG_CLK_1KHZ],
> >> >> +                                     &clk_creg_clocks[CREG_CLK_32KHZ].name,
> >> >> +                                     syscon);
> >> >> +
> >> >> +       of_clk_add_provider(np, of_clk_src_onecell_get, &clk_base_data);
> >> >> +}
> >> >> +CLK_OF_DECLARE(lpc18xx_creg_clk, "nxp,lpc1850-creg-clk", lpc18xx_creg_clk_init);
> >> >
> >> > I'll ask the same question that Stephen asked in your CCU/CGU driver
> >> > series: is it necessary to use CLK_OF_DECLARE here or can you use the
> >> > platform device model?
> >>
> >> The 32 kHz clock from the CREG block is a clock parent to the CGU
> >> block so it's possible that it will required early. This is all
> >> depends on how the boot loader initially configures the CGU.
> >>
> >> Currently in the DTS for lpc18xx cgu it has:
> >> clocks = <&xtal>, <&xtal32>, <...>;
> >> xtal32 is just a temporary placeholder until the CREG clock is in place.
> >
> > Well that seems wrong. Is it just a matter of probe order where you try
> > to probe the cgu driver before the creg driver?
> 
> The ideal probe order for the clk drivers on the lpc18xx platform
> would be; creg-clk, cgu and ccu.
> If the 32k clk is used by any of timers we need creg-clk to enable the
> 32k clock and determine the rate.
> 
> Note that the cgu and ccu driver is using CLK_OF_DECLARE now.
> 
> 
> I have tired to create an overview of the lpc18xx clock system here:
> https://github.com/manabian/linux-lpc/wiki/LPC18xx-LPC43xx-clocks

That's great, thanks a lot for the link and the nice documentation.

It's been a while since I've looked at this thread. Do any of the
creg-clk, cgu or ccu clock drivers need to use CLK_OF_DECLARE? If they
were platform_drivers then you could use -EPROBE_DEFER to solve your
ordering issue.

Regards,
Mike

> 
> 
> regards,
> Joachim Eastwood


From k.kozlowski at samsung.com  Tue Feb 16 17:16:43 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 17 Feb 2016 10:16:43 +0900
Subject: [clk:clk-samsung-kconfig 1/2] drivers/clk/samsung/clk.h:29:26:
 error: field 'clk_data' has incomplete type
In-Reply-To: <201602170850.V9nmoMr3%fengguang.wu@intel.com>
References: <201602170850.V9nmoMr3%fengguang.wu@intel.com>
Message-ID: <56C3C9FB.8090301@samsung.com>

On 17.02.2016 09:01, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-samsung-kconfig
> head:   e83cb468452c25597e868d1ed778fa73fdaeca4c
> commit: 89e08b1b13374a336dfd1d500ebc70aa545579ab [1/2] clk: samsung: Enable COMPILE_TEST for Samsung clocks
> config: ia64-allmodconfig (attached as .config)
> reproduce:
>         wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         git checkout 89e08b1b13374a336dfd1d500ebc70aa545579ab
>         # save the attached .config to linux build tree
>         make.cross ARCH=ia64 
> 

I think the error is a result of missing one patch in the branch - the
"clk: Move vendor's Kconfig into CCF menu section":
https://git.kernel.org/cgit/linux/kernel/git/clk/linux.git/commit/?h=clk-next&id=b9e65ebc654dffeb77d8ef878bd6b2da30c55a94

With mentioned patch these Samsung clocks depends on COMMON_CLK so they
should not be selectable on IA64.

However I don't have IA64 cross compiler to verify this.

Best regards,
Krzysztof


From f.fainelli at gmail.com  Tue Feb 16 17:16:04 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 16 Feb 2016 17:16:04 -0800
Subject: [PATCH 4/4] arm64: cputype info for Broadcom Vulcan
In-Reply-To: <20160215101235.GA1748@arm.com>
References: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
 <1455389195-31870-5-git-send-email-jchandra@broadcom.com>
 <20160215101235.GA1748@arm.com>
Message-ID: <56C3C9D4.4020506@gmail.com>

On 15/02/16 02:12, Will Deacon wrote:
> On Sun, Feb 14, 2016 at 12:16:35AM +0530, Jayachandran C wrote:
>> Add Broadcom Vulcan implementor ID and part ID in cputype.h. This is
>> to document the values.
>>
>> Signed-off-by: Jayachandran C <jchandra at broadcom.com>
>> ---
>>  arch/arm64/include/asm/cputype.h | 2 ++
>>  1 file changed, 2 insertions(+)
> 
> Acked-by: Will Deacon <will.deacon at arm.com>

Would this be picked by Calatin, or should this be sent along with the
ARM/ARM64 SoC changes pull requests (just wondering?), thanks!
-- 
Florian


From mturquette at baylibre.com  Tue Feb 16 17:04:40 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Tue, 16 Feb 2016 17:04:40 -0800
Subject: [PATCH 1/2] dt-bindings: clock: adpll: Add binding documentation
 for TI adpll
In-Reply-To: <1455312009-808-2-git-send-email-tony@atomide.com>
References: <1455312009-808-1-git-send-email-tony@atomide.com>
 <1455312009-808-2-git-send-email-tony@atomide.com>
Message-ID: <20160217010440.2278.62327@quark.deferred.io>

Hi Tony,

Quoting Tony Lindgren (2016-02-12 13:20:08)
> Let's add binding documentation for the ADPLL found on dm814x
> and dra62x. The binding uses the standard clock binding.
> 
> Cc: devicetree at vger.kernel.org
> Cc: Rob Herring <robh+dt at kernel.org>
> Cc: Stephen Boyd <sboyd at codeaurora.org>
> Cc: Tero Kristo <t-kristo at ti.com>
> Acked-by: Michael Turquette <mturquette at baylibre.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> ---
>  .../devicetree/bindings/clock/ti/adpll.txt         | 43 ++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/ti/adpll.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/ti/adpll.txt b/Documentation/devicetree/bindings/clock/ti/adpll.txt
> new file mode 100644
> index 0000000..8516bf0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti/adpll.txt
> @@ -0,0 +1,43 @@
> +Binding for Texas Instruments ADPLL clock.
> +
> +Binding status: Unstable - ABI compatibility may be broken in the future
> +
> +This binding uses the common clock binding[1]. It assumes a
> +register-mapped ADPLL with two to three selectable input clocks
> +and three to four children.
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible : shall be one of "ti,dm814-adpll-s-clock" or
> +  "ti,dm814-adpll-lj-clock" depending on the type of the ADPLL
> +- #clock-cells : from common clock binding; shall be set to 0.

Thanks for the patch.

clock-cells = 1 in both of the examples below (which looks right).

> +- clocks : link phandles of parent clocks clkinp and clkinpulow, note
> +  that the adpll-s-clock also has an optional clkinphif
> +- reg : address and length of the register set for controlling the ADPLL.
> +
> +Examples:
> +       adpll_mpu_ck: adpll at 40 {
> +               #clock-cells = <1>;
> +               compatible = "ti,dm814-adpll-s-clock";
> +               reg = <0x40 0x40>;
> +               clocks = <&devosc_ck &devosc_ck &devosc_ck>;
> +               clock-names = "clkinp", "clkinpulow", "clkinphif";
> +               clock-indices = <0>, <1>, <2>, <3>;

Why is clock-indices necessary?

Best regards,
Mike

> +               clock-output-names = "481c5040.adpll.dcoclkldo",
> +                                    "481c5040.adpll.clkout",
> +                                    "481c5040.adpll.clkoutx2",
> +                                    "481c5040.adpll.clkouthif";
> +       };
> +
> +       adpll_dsp_ck: adpll at 80 {
> +               #clock-cells = <1>;
> +               compatible = "ti,dm814-adpll-lj-clock";
> +               reg = <0x80 0x30>;
> +               clocks = <&devosc_ck &devosc_ck>;
> +               clock-names = "clkinp", "clkinpulow";
> +               clock-indices = <0>, <1>, <2>;
> +               clock-output-names = "481c5080.adpll.dcoclkldo",
> +                                    "481c5080.adpll.clkout",
> +                                    "481c5080.adpll.clkoutldo";
> +       };
> -- 
> 2.7.0
> 


From f.fainelli at gmail.com  Tue Feb 16 17:22:36 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Tue, 16 Feb 2016 17:22:36 -0800
Subject: [PATCH 1/4] arm64: Broadcom Vulcan support
In-Reply-To: <1455389195-31870-2-git-send-email-jchandra@broadcom.com>
References: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
 <1455389195-31870-2-git-send-email-jchandra@broadcom.com>
Message-ID: <56C3CB5C.7080609@gmail.com>

On 13/02/16 10:46, Jayachandran C wrote:
> From: Zi Shen Lim <zlim at broadcom.com>
> 
> Add a configuration option and a device tree for Broadcom's Vulcan
> ARM64 processor. brcm-vulcan.dtsi has the on-chip blocks like the
> PCIe controller, GICv3 with ITS, PMU, system timer and pl011 UART.
> brcm-vulcan-eval.dts has definitions for a basic evaluation board.
> The firmware supports PSCI 0.2 for cpu wakeup.
> 
> Signed-off-by: Zi Shen Lim <zlim at broadcom.com>
> [ updated and split dts - jchandra at broadcom.com ]
> Signed-off-by: Jayachandran C <jchandra at broadcom.com>
> ---
>  arch/arm64/Kconfig.platforms                      |   5 +
>  arch/arm64/boot/dts/broadcom/Makefile             |   1 +
>  arch/arm64/boot/dts/broadcom/brcm-vulcan-eval.dts |  33 +++++
>  arch/arm64/boot/dts/broadcom/brcm-vulcan.dtsi     | 146 ++++++++++++++++++++++
>  4 files changed, 185 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/broadcom/brcm-vulcan-eval.dts
>  create mode 100644 arch/arm64/boot/dts/broadcom/brcm-vulcan.dtsi

You might want a MAINTAINERS entry too for these new files?

[snip]

> +++ b/arch/arm64/boot/dts/broadcom/brcm-vulcan-eval.dts
> @@ -0,0 +1,33 @@
> +/*
> + * dts file for Broadcom (BRCM) Vulcan Eval Platform
> + *
> + * Copyright (C) 2013-2016, Broadcom Corporation.

My little finger tells me we should be using a plain
Broadcom now and drop the Corporation in the license header.
-- 
Florian


From peter at hurleysoftware.com  Tue Feb 16 17:31:48 2016
From: peter at hurleysoftware.com (Peter Hurley)
Date: Tue, 16 Feb 2016 17:31:48 -0800
Subject: [PATCH v2] serial: earlycon: rework common framework for earlycon
 declarations
In-Reply-To: <CAK7LNAS_vietwRRFnH3YhbWSzjRFP4U6rjftYek1KQ3ips2ZSQ@mail.gmail.com>
References: <1455273394-27350-1-git-send-email-yamada.masahiro@socionext.com>
 <56BDF799.1030505@hurleysoftware.com>
 <CAK7LNAS_vietwRRFnH3YhbWSzjRFP4U6rjftYek1KQ3ips2ZSQ@mail.gmail.com>
Message-ID: <56C3CD84.9000504@hurleysoftware.com>

On 02/12/2016 08:30 AM, Masahiro Yamada wrote:
> Hi Peter,
> 
> 
> 2016-02-13 0:17 GMT+09:00 Peter Hurley <peter at hurleysoftware.com>:
>> On 02/12/2016 02:36 AM, Masahiro Yamada wrote:
>>> Commit 71f50c6d9a22 ("of: drop symbols declared by _OF_DECLARE() from
>>> modules") fixed the link error introduced by commit b8d20e06eaad
>>> ("serial: 8250_uniphier: add earlycon support").
>>>
>>> After commit 2eaa790989e0 ("earlycon: Use common framework for
>>> earlycon declarations") was applied, the link error came back
>>> because the commit reworked OF_EARLYCON_DECLARE() to not use
>>> _OF_DECLARE().
>>
>> What link error are you getting?
> 
> The combination of CONFIG_SERIAL_8250_CONSOLE=y
> and CONFIG_SERIAL_8250_UNIPHIER=m causes a link error.
> 
> 
> 
>>
>>> This commit reworks OF_EARLYCON_DECLARE() again based on
>>> _OF_DECLARE().  My motivations are:
>>>
>>>  - Fix the link error in a generic way (without patching
>>>    drivers/tty/serial/8250/8250_uniphier.c)
>>>
>>>  - Delete struct earlycon_id.  This struct is re-inventing the wheel;
>>>    the fields "name", "compatible", "setup" can be implemented in
>>>    struct of_device_id as other frameworks do.
>>
>> This patch basically reverts the common framework.
>> What happens when not building with OF? Does it still declare the
>> earlycon table?
> 
> Ah, I missed this.  (sigh)
> 
> Earlycon must still work without OF.
> My way only works with OF.
> 
> I really screwed up.  Sorry.

Hi Masahiro,

No big deal.

We need to come up with a better way to enable earlycon builds and
opt-in by driver than the current method. Breaking builds with earlycon
support has happened several times in the last couple of years so
it's not just you.

Regards,
Peter Hurley



From mturquette at baylibre.com  Tue Feb 16 17:19:30 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Tue, 16 Feb 2016 17:19:30 -0800
Subject: [PATCH 2/2] clk: ti: Add support for dm814x ADPLL
In-Reply-To: <1455312009-808-3-git-send-email-tony@atomide.com>
References: <1455312009-808-1-git-send-email-tony@atomide.com>
 <1455312009-808-3-git-send-email-tony@atomide.com>
Message-ID: <20160217011930.2278.38316@quark.deferred.io>

Hi Tony,

Quoting Tony Lindgren (2016-02-12 13:20:09)
> On dm814x we have 13 ADPLLs with 3 to 4 outputs on each. The
> ADPLLs have several dividers and muxes controlled by a shared
> control register for each PLL.
> 
> Note that for the clocks to work as device drivers for booting on
> dm814x, this patch depends on "ARM: OMAP2+: Change core_initcall
> levels to postcore_initcall".
> 
> Also note that this patch does not implement clk_set_rate for the
> PLL, that will be posted later on when available.
> 
> Cc: Michael Turquette <mturquette at baylibre.com>
> Cc: Stephen Boyd <sboyd at codeaurora.org>
> Acked-by: Tero Kristo <t-kristo at ti.com>
> Signed-off-by: Tony Lindgren <tony at atomide.com>
> ---
> 
> Changes since v4:
> 
> - Removed ti_adpll_clkout_set_parent() as requested by Tero for his
>   conditional ack
> 
> - Split the device tree binding into a separate patch as requested
>   by Mike for his conditional ack of the binding

Just to make life fun for you, the clk tree is once more merging DT
bindings descriptions and headers. You don't need to merge the patches,
it doesn't matter to me, but just as a heads up for the future.

> 
> - Updated dts patch comments about dynamically generated names as
>   suggested by Tero.
> 
> - Fixed a compiler warning for do_div
> 
> 
>  drivers/clk/Kconfig       |   1 +
>  drivers/clk/ti/Kconfig    |   6 +
>  drivers/clk/ti/Makefile   |   2 +
>  drivers/clk/ti/adpll.c    | 983 ++++++++++++++++++++++++++++++++++++++++++++++
>  drivers/clk/ti/clk-814x.c |  53 +++
>  5 files changed, 1045 insertions(+)
>  create mode 100644 drivers/clk/ti/Kconfig
>  create mode 100644 drivers/clk/ti/adpll.c
> 
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index eca8e01..0b7364a 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -202,6 +202,7 @@ config COMMON_CLK_CDCE706
>  
>  source "drivers/clk/bcm/Kconfig"
>  source "drivers/clk/hisilicon/Kconfig"
> +source "drivers/clk/ti/Kconfig"
>  source "drivers/clk/qcom/Kconfig"
>  
>  endmenu
> diff --git a/drivers/clk/ti/Kconfig b/drivers/clk/ti/Kconfig
> new file mode 100644
> index 0000000..a9d5474
> --- /dev/null
> +++ b/drivers/clk/ti/Kconfig
> @@ -0,0 +1,6 @@
> +config COMMON_CLK_TI_ADPLL
> +       tristate "Clock driver for dm814x ADPLL"
> +       depends on ARCH_OMAP2PLUS
> +       default y if SOC_TI81XX

Can we add COMPILE_TEST here?

...
> +static int ti_adpll_init_inputs(struct ti_adpll_data *d)
> +{
> +       const char *error = "need at least %i inputs";
> +       struct clk *clock;
> +       int nr_inputs;
> +
> +       nr_inputs = of_clk_get_parent_count(d->np);
> +       if (nr_inputs < d->c->nr_max_inputs) {
> +               dev_err(d->dev, error, nr_inputs);
> +               return -EINVAL;
> +       }
> +       of_clk_parent_fill(d->np, d->parent_names, nr_inputs);
> +
> +       clock = devm_clk_get(d->dev, d->parent_names[0]);
> +       if (IS_ERR(clock)) {
> +               dev_err(d->dev, "could not get clkinp\n");
> +               return PTR_ERR(clock);
> +       }
> +       d->parent_clocks[TI_ADPLL_CLKINP] = clock;
> +
> +       clock = devm_clk_get(d->dev, d->parent_names[1]);
> +       if (IS_ERR(clock)) {
> +               dev_err(d->dev, "could not get clkinpulow clock\n");
> +               return PTR_ERR(clock);
> +       }
> +       d->parent_clocks[TI_ADPLL_CLKINPULOW] = clock;

Are the clock parents known at compile-time? Can we just put that data
in C instead of whatever is going on here?

...
> +int __init dm814x_adpll_enable_init_clocks(void)
> +{
> +       int i, err;
> +
> +       if (!timer_clocks_initialized)
> +               return -ENODEV;
> +
> +       for (i = 0; i < ARRAY_SIZE(init_clocks); i++) {
> +               struct clk *clock;
> +
> +               clock = clk_get(NULL, init_clocks[i]);
> +               if (WARN(IS_ERR(clock), "could not find init clock %s\n",
> +                        init_clocks[i]))
> +                       continue;
> +               err = clk_prepare_enable(clock);
> +               if (WARN(err, "could not enable init clock %s\n",
> +                        init_clocks[i]))
> +                       continue;

We have a shiny new series that provides a standard way to do this:

http://lkml.kernel.org/r/<1455225554-13267-1-git-send-email-mturquette at baylibre.com>

Regards,
Mike


From davem at davemloft.net  Tue Feb 16 17:36:13 2016
From: davem at davemloft.net (David Miller)
Date: Tue, 16 Feb 2016 20:36:13 -0500 (EST)
Subject: [PATCH] net: phy: spi_ks8995: include linux/gpio/consumer.h
In-Reply-To: <1455273762-161477-1-git-send-email-arnd@arndb.de>
References: <1455273762-161477-1-git-send-email-arnd@arndb.de>
Message-ID: <20160216.203613.1959933915599102205.davem@davemloft.net>

From: Arnd Bergmann <arnd at arndb.de>
Date: Fri, 12 Feb 2016 11:42:34 +0100

> The ks8995 phy driver just started using gpiod_* functions, which are
> declared in linux/gpio/consumer.h, not linux/gpio.h, resulting in a
> build failure in randconfig builds that do not have CONFIG_GPIOLIB
> enabled:
> 
> drivers/net/phy/spi_ks8995.c: In function 'ks8995_probe':
> drivers/net/phy/spi_ks8995.c:477:3: error: implicit declaration of function 'gpiod_set_value' [-Werror=implicit-function-declaration]
> 
> This changes the header inclusion so it builds in all configurations.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: cd6f288cbaab ("net: phy: spi_ks8995: add support for resetting switch using GPIO")

Applied, thanks Arnd.


From mturquette at baylibre.com  Tue Feb 16 17:37:22 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Tue, 16 Feb 2016 17:37:22 -0800
Subject: [clk:clk-samsung-kconfig 1/2] drivers/clk/samsung/clk.h:29:26:
 error: field 'clk_data' has incomplete type
In-Reply-To: <56C3C9FB.8090301@samsung.com>
References: <201602170850.V9nmoMr3%fengguang.wu@intel.com>
 <56C3C9FB.8090301@samsung.com>
Message-ID: <CAEG3pNAGKRavxOC2aDGuJ4S_RU0DsjmXQiy54MTmkO=qrRE6JQ@mail.gmail.com>

On Tue, Feb 16, 2016 at 5:16 PM, Krzysztof Kozlowski
<k.kozlowski at samsung.com> wrote:
>
> On 17.02.2016 09:01, kbuild test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-samsung-kconfig
> > head:   e83cb468452c25597e868d1ed778fa73fdaeca4c
> > commit: 89e08b1b13374a336dfd1d500ebc70aa545579ab [1/2] clk: samsung: Enable COMPILE_TEST for Samsung clocks
> > config: ia64-allmodconfig (attached as .config)
> > reproduce:
> >         wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> >         chmod +x ~/bin/make.cross
> >         git checkout 89e08b1b13374a336dfd1d500ebc70aa545579ab
> >         # save the attached .config to linux build tree
> >         make.cross ARCH=ia64
> >
>
> I think the error is a result of missing one patch in the branch - the
> "clk: Move vendor's Kconfig into CCF menu section":
> https://git.kernel.org/cgit/linux/kernel/git/clk/linux.git/commit/?h=clk-next&id=b9e65ebc654dffeb77d8ef878bd6b2da30c55a94

OK, I have rebased the clk-samsung branch on top of b9e65ebc654d. This
means the immutable branch will pull in about a dozen unrelated
patches, but I don't want to rebase the whole clk tree just to pull
out James' patch.

Regards,
Mike

>
> With mentioned patch these Samsung clocks depends on COMMON_CLK so they
> should not be selectable on IA64.
>
> However I don't have IA64 cross compiler to verify this.
>
> Best regards,
> Krzysztof




-- 
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/


From jay.xu at rock-chips.com  Tue Feb 16 17:53:06 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Wed, 17 Feb 2016 09:53:06 +0800
Subject: [PATCH 0/6] Add core dtsi for rk3399 from Rockchip
Message-ID: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>

From: Xu Jianqun <jay.xu at rock-chips.com>

There is the new SoCs from Rockchip which named rk3399, the
patches are added to support them.

Two patch of cru from Xing are quoted, but the cru driver will
be pushed by Xing near later.

Xing Zheng (2):
  clk: rockchip: add dt-binding header for rk3399
  dt-bindings: add documentation of rk3399 clock controller

Xu Jianqun (4):
  spi: rockchip: add bindings for rk3399 spi
  ASoC: rockchip: add bindings for rk3399 i2s
  pinctrl: rockchip: add bindings for rk3399 pinctrl
  ARM64: dts: rockchip: add core dtsi file for rk3399

 .../bindings/clock/rockchip,rk3399-cru.txt         |  82 ++
 .../bindings/pinctrl/rockchip,pinctrl.txt          |   2 +-
 .../devicetree/bindings/sound/rockchip-i2s.txt     |   1 +
 .../devicetree/bindings/spi/spi-rockchip.txt       |   1 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           | 989 +++++++++++++++++++++
 include/dt-bindings/clock/rk3399-cru.h             | 610 +++++++++++++
 6 files changed, 1684 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
 create mode 100644 include/dt-bindings/clock/rk3399-cru.h

-- 
1.9.1




From jay.xu at rock-chips.com  Tue Feb 16 17:53:09 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Wed, 17 Feb 2016 09:53:09 +0800
Subject: [PATCH 3/6] ASoC: rockchip: add bindings for rk3399 i2s
In-Reply-To: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455673992-16469-4-git-send-email-jay.xu@rock-chips.com>

From: Xu Jianqun <jay.xu at rock-chips.com>

Add devicetree bindings for i2s controller found on rk3399
processors from rockchip.

Signed-off-by: Xu Jianqun <jay.xu at rock-chips.com>
---
 Documentation/devicetree/bindings/sound/rockchip-i2s.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
index b7f3a93..6e86d8a 100644
--- a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
@@ -9,6 +9,7 @@ Required properties:
    - "rockchip,rk3066-i2s": for rk3066
    - "rockchip,rk3188-i2s", "rockchip,rk3066-i2s": for rk3188
    - "rockchip,rk3288-i2s", "rockchip,rk3066-i2s": for rk3288
+   - "rockchip,rk3399-i2s", "rockchip,rk3066-i2s": for rk3399
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: should contain the I2S interrupt.
-- 
1.9.1




From jay.xu at rock-chips.com  Tue Feb 16 17:53:07 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Wed, 17 Feb 2016 09:53:07 +0800
Subject: [PATCH 1/6] clk: rockchip: add dt-binding header for rk3399
In-Reply-To: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455673992-16469-2-git-send-email-jay.xu@rock-chips.com>

From: Xing Zheng <zhengxing at rock-chips.com>

Add the dt-bindings header for the rk3399, that gets shared between
the clock controller and the clock references in the dts.

Change-Id: I01830a46b679f4630506e8cb48b1a39e113a9952
Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
---
 include/dt-bindings/clock/rk3399-cru.h | 610 +++++++++++++++++++++++++++++++++
 1 file changed, 610 insertions(+)
 create mode 100644 include/dt-bindings/clock/rk3399-cru.h

diff --git a/include/dt-bindings/clock/rk3399-cru.h b/include/dt-bindings/clock/rk3399-cru.h
new file mode 100644
index 0000000..42a1618
--- /dev/null
+++ b/include/dt-bindings/clock/rk3399-cru.h
@@ -0,0 +1,610 @@
+/*
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng <zhengxing at rock-chips.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H
+#define _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H
+
+/* core clocks */
+#define PLL_APLLL		1
+#define PLL_APLLB		2
+#define PLL_DPLL		3
+#define PLL_CPLL		4
+#define PLL_GPLL		5
+#define PLL_NPLL		6
+#define PLL_VPLL		7
+#define PLL_PPLL		8
+#define ARMCLKL			9
+#define ARMCLKB			10
+
+/* sclk gates (special clocks) */
+#define SCLK_GPU_CORE		64
+#define SCLK_SPI0		65
+#define SCLK_SPI1		66
+#define SCLK_SPI2		68
+#define SCLK_SPI3		69
+#define SCLK_SPI4		70
+#define SCLK_SPI5		71
+#define SCLK_SDMMC		72
+#define SCLK_SDIO0		73
+#define SCLK_EMMC		74
+#define SCLK_TSADC		75
+#define SCLK_SARADC		76
+#define SCLK_NANDC0		77
+#define SCLK_UART0		78
+#define SCLK_UART1		79
+#define SCLK_UART2		80
+#define SCLK_UART3		81
+#define SCLK_UART4		82
+#define SCLK_SPDIF_8CH		83
+#define SCLK_I2S0_8CH		84
+#define SCLK_I2S1_8CH		85
+#define SCLK_I2S2_8CH		86
+#define SCLK_TIMER00		87
+#define SCLK_TIMER01		88
+#define SCLK_TIMER02		89
+#define SCLK_TIMER03		90
+#define SCLK_TIMER04		91
+#define SCLK_TIMER05		92
+#define SCLK_TIMER06		93
+#define SCLK_TIMER07		94
+#define SCLK_TIMER08		95
+#define SCLK_TIMER09		96
+#define SCLK_TIMER10		97
+#define SCLK_TIMER11		98
+#define SCLK_HSICPHY480M	99
+#define SCLK_HSICPHY12M		100
+#define SCLK_MACREF		101
+#define SCLK_VOPB_PWM		102
+#define SCLK_VOPL_PWM		103
+#define SCLK_EDP_24M		104
+#define SCLK_EDP		105
+#define SCLK_RGA		106
+#define SCLK_ISP		107
+#define SCLK_HDCP		108
+#define SCLK_HDMI_HDCP		109
+#define SCLK_HDMI_CEC		110
+#define SCLK_HEVC_CABAC		111
+#define SCLK_HEVC_CORE		112
+#define SCLK_I2S_8CH_OUT	113
+#define SCLK_SDMMC_DRV		114
+#define SCLK_SDIO0_DRV		115
+#define SCLK_SDIO1_DRV		116
+#define SCLK_EMMC_DRV		117
+#define SCLK_SDMMC_SAMPLE	118
+#define SCLK_SDIO0_SAMPLE	119
+#define SCLK_SDIO1_SAMPLE	120
+#define SCLK_EMMC_SAMPLE	121
+#define SCLK_USBPHY480M		122
+#define SCLK_PVTM_CORE_L	123
+#define SCLK_PVTM_CORE_B	124
+#define SCLK_PVTM_GPU		125
+#define SCLK_PVTM_PMU		126
+#define SCLK_SFC		127
+#define SCLK_MAC_RX		128
+#define SCLK_MAC_TX		129
+#define SCLK_MAC		130
+#define SCLK_MACREF_OUT		131
+#define SCLK_USB2_PHY0_REF	132
+#define SCLK_USB2_PHY1_REF	133
+#define SCLK_USB3_OTG0_REF	134
+#define SCLK_USB3_OTG1_REF	135
+#define SCLK_USB3_OTG0_SUSPEND	136
+#define SCLK_USB3_OTG1_SUSPEND	137
+#define SCLK_CRYPTO		138
+#define SCLK_CRYPTO1		139
+
+#define DCLK_VOPB		170
+#define DCLK_VOPL		171
+#define MCLK_CRYPTO		172
+#define MCLK_CRYPTO1		173
+
+/* aclk gates */
+#define ACLK_GPU_MEM		192
+#define ACLK_GPU_CFG		193
+#define ACLK_DMAC_BUS		194
+#define ACLK_DMAC_PERI		195
+#define ACLK_PERI_MMU		196
+#define ACLK_GMAC		197
+#define ACLK_VOPB		198
+#define ACLK_VOPL		199
+#define ACLK_RGA		200
+#define ACLK_HDCP		201
+#define ACLK_IEP		202
+#define ACLK_VIO0_NOC		203
+#define ACLK_VIP		204
+#define ACLK_ISP		205
+#define ACLK_VIO1_NOC		206
+#define ACLK_VIDEO		208
+#define ACLK_BUS		209
+#define ACLK_PERI		210
+#define ACLK_EMMC_GPLL		211
+#define ACLK_EMMC_CPLL		212
+#define ACLK_EMMC_CORE		213
+#define ACLK_EMMC_NIU 		214
+#define ACLK_EMMC_GRF 		215
+#define ACLK_USB3_OTG0		216
+#define ACLK_USB3_OTG1		217
+#define ACLK_USB3_GRF 		218
+
+/* pclk gates */
+#define PCLK_GPIO0		320
+#define PCLK_GPIO1		321
+#define PCLK_GPIO2		322
+#define PCLK_GPIO3		323
+#define PCLK_GPIO4		324
+#define PCLK_PMUGRF		325
+#define PCLK_MAILBOX		326
+#define PCLK_GRF		329
+#define PCLK_SGRF		330
+#define PCLK_PMU		331
+#define PCLK_I2C0		332
+#define PCLK_I2C1		333
+#define PCLK_I2C2		334
+#define PCLK_I2C3		335
+#define PCLK_I2C4		336
+#define PCLK_I2C5		337
+#define PCLK_SPI0		338
+#define PCLK_SPI1		339
+#define PCLK_SPI2		340
+#define PCLK_SPI3		341
+#define PCLK_SPI4		342
+#define PCLK_SPI5		343
+#define PCLK_UART0		344
+#define PCLK_UART1		345
+#define PCLK_UART2		346
+#define PCLK_UART3		347
+#define PCLK_UART4		348
+#define PCLK_TSADC		349
+#define PCLK_SARADC		350
+#define PCLK_SIM		351
+#define PCLK_GMAC		352
+#define PCLK_PWM0		353
+#define PCLK_PWM1		354
+#define PCLK_TIMER0		355
+#define PCLK_TIMER1		356
+#define PCLK_EDP_CTRL		357
+#define PCLK_MIPI_DSI0		358
+#define PCLK_MIPI_CSI		359
+#define PCLK_HDCP		360
+#define PCLK_HDMI_CTRL		361
+#define PCLK_VIO_H2P		362
+#define PCLK_BUS		363
+#define PCLK_PERI		364
+#define PCLK_DDRUPCTL		365
+#define PCLK_DDRPHY		366
+#define PCLK_ISP		367
+#define PCLK_VIP		368
+#define PCLK_WDT		369
+
+/* hclk gates */
+#define HCLK_SFC		448
+#define HCLK_HOST0		450
+#define HCLK_HOST1		451
+#define HCLK_HSIC		452
+#define HCLK_NANDC0		453
+#define HCLK_TSP		455
+#define HCLK_SDMMC		456
+#define HCLK_SDIO0		457
+#define HCLK_EMMC		459
+#define HCLK_HSADC		460
+#define HCLK_CRYPTO		461
+#define HCLK_I2S0_8CH		462
+#define HCLK_I2S1_8CH		463
+#define HCLK_I2S2_8CH		464
+#define HCLK_SPDIF		465
+#define HCLK_VOPB		466
+#define HCLK_VOPL		467
+#define HCLK_ROM		468
+#define HCLK_IEP		469
+#define HCLK_ISP		470
+#define HCLK_RGA		471
+#define HCLK_VIO_AHB_ARBI	472
+#define HCLK_VIO_NOC		473
+#define HCLK_VIP		474
+#define HCLK_VIO_H2P		475
+#define HCLK_VIO_HDCPMMU	476
+#define HCLK_VIDEO		477
+#define HCLK_BUS		478
+#define HCLK_PERI		479
+
+/* pmu-clocks indices */
+#define SCLK_CM0S		500
+#define SCLK_SPI5		501
+#define SCLK_TIMER12		502
+#define SCLK_TIMER13		503
+#define SCLK_UART		504
+
+#define CLK_NR_CLKS		(SCLK_UART + 1)
+
+/* soft-reset indices */
+
+/* cru_softrst_con0 */
+#define SRST_CORE_L0			0
+#define SRST_CORE_B0			1
+#define SRST_CORE_PO_L0			2
+#define SRST_CORE_PO_B0			3
+#define SRST_L2_L			4
+#define SRST_L2_B			5
+#define SRST_ADB_L			6
+#define SRST_ADB_B			7
+#define SRST_A_CCI			8
+#define SRST_A_CCIM0_NIU		9
+#define SRST_A_CCIM1_NIU		10
+#define SRST_DBG_NIU			11
+
+/* cru_softrst_con1 */
+#define SRST_CORE_L0_T			16
+#define SRST_CORE_L1			17
+#define SRST_CORE_L2			18
+#define SRST_CORE_L3			19
+#define SRST_CORE_PO_L0_T		20
+#define SRST_CORE_PO_L1			21
+#define SRST_CORE_PO_L2			22
+#define SRST_CORE_PO_L3			23
+#define SRST_A_ADB400_GIC2_CORE_L	24
+#define SRST_A_ADB400_CORE_L_GIC2	25
+#define SRST_P_DBG_L			26
+#define SRST_SOC_DBG_L			27
+#define SRST_L2_L_T			28
+#define SRST_ADB_L_T			29
+#define SRST_A_RKREF_L			30
+#define SRST_PVTM_CORE_L		31
+
+/* cru_softrst_con2 */
+#define SRST_CORE_B0_T			32
+#define SRST_CORE_B1			33
+#define SRST_CORE_PO_B0_T		36
+#define SRST_CORE_PO_B1			37
+#define SRST_A_ADB400_GIC2_CORE_B	40
+#define SRST_A_ADB400_CORE_B_GIC2	41
+#define SRST_P_DBG_B			42
+#define SRST_L2_B_T			43
+#define SRST_SOC_DBG_B			44
+#define SRST_ADB_B_T			45
+#define SRST_A_RKREF_B			46
+#define SRST_PVTM_CORE_B		47
+
+/* cru_softrst_con3 */
+#define SRST_A_CCI_T			50
+#define SRST_A_CCIM0_NIU_T		51
+#define SRST_A_CCIM1_NIU_T		52
+#define SRST_A_ADB400M_PD_CORE_B_T	53
+#define SRST_A_ADB400M_PD_CORE_L_T	54
+#define SRST_DBG_NIU_T			55
+#define SRST_DBG_CXCS			56
+#define SRST_CCI_TRACE			57
+#define SRST_P_CCI_GRF			58
+
+/* cru_softrst_con4 */
+#define SRST_A_CENTER_MAIN_NIU		64
+#define SRST_A_CENTER_PERI_NIU		65
+#define SRST_P_CENTER_MAIN		66
+#define SRST_P_DDRMAON			67
+#define SRST_P_CIC			68
+#define SRST_P_CENTER_SGRF		69
+#define SRST_DDR0_MSCH			70
+#define SRST_DDRCFG0_MSCH		71
+#define SRST_DDR0			72
+#define SRST_DDRPHY0			73
+#define SRST_DDR1_MSCH			74
+#define SRST_DDRCFG1_MSCH		75
+#define SRST_DDR1			76
+#define SRST_DDRPHY1			77
+#define SRST_DDR_CIC			78
+#define SRST_PVTM_DDR			79
+
+/* cru_softrst_con5 */
+#define SRST_A_VCODEC_NIU		80
+#define SRST_A_VCODEC			81
+#define SRST_H_VCODEC_NIU		82
+#define SRST_H_VCODEC			83
+#define SRST_A_VDU_NIU			88
+#define SRST_A_VDU 			89
+#define SRST_H_VDU_NIU			90
+#define SRST_H_VDU			91
+#define SRST_VDU_CORE			92
+#define SRST_VDU_CA			93
+
+/* cru_softrst_con6 */
+#define SRST_A_IEP_NIU			96
+#define SRST_A_VOP_IEP			97
+#define SRST_A_IEP			98
+#define SRST_H_IEP_NIU			99
+#define SRST_H_IEP			100
+#define SRST_A_RGA_NIU			102
+#define SRST_A_RGA			103
+#define SRST_H_RGA_NIU			104
+#define SRST_H_RGA			105
+#define SRST_RGA_CORE			106
+#define SRST_EMMC_NIU			108
+#define SRST_EMMC			109
+#define SRST_EMMC_GRF			110
+#define SRST_EMMCPHY_SYSRX		111
+
+/* cru_softrst_con7 */
+#define SRST_A_PERIHP_NIU		112
+#define SRST_A_PERIHP_GRF		113
+#define SRST_H_PERIHP_NIU		114
+#define SRST_USBHOST0 			115
+#define SRST_HOSTC0_AUX			116
+#define SRST_HOSTC0_ARB			117
+#define SRST_USBHOST1			118
+#define SRST_HOSTC1_AUX			119
+#define SRST_HOSTC1_ARB			120
+#define SRST_SDIO0			121
+#define SRST_SDMMC			122
+#define SRST_HSIC			123
+#define SRST_HSIC_AUX			124
+#define SRST_AHB1TOM			125
+#define SRST_P_PERIHP_NIU		126
+#define SRST_HSICPHY			127
+
+/* cru_softrst_con8 */
+#define SRST_A_PCIE			128
+#define SRST_P_PCIE			129
+#define SRST_PCIE_CORE			130
+#define SRST_PCIE_MGMT			131
+#define SRST_PCIE_MGMT_STICKY		132
+#define SRST_PCIE_PIPE			133
+#define SRST_PCIE_PM			134
+#define SRST_PCIEPHY			135
+#define SRST_A_GMAC_NIU			136
+#define SRST_A_GMAC 			137
+#define SRST_P_GMAC_NIU			138
+#define SRST_P_GMAC			139
+#define SRST_P_GMAC_GRF			140
+#define SRST_HSICPHY_POR		142
+#define SRST_HSICPHY_UTMI		143
+
+/* cru_softrst_con9 */
+#define SRST_USB2PHY0_POR		144
+#define SRST_USB2PHY0_UTMI_PORT0	145
+#define SRST_USB2PHY0_UTMI_PORT1	146
+#define SRST_USB2PHY0_EHCIPHY		147
+#define SRST_UPHY0_PIPE_L00		148
+#define SRST_UPHY0			149
+#define SRST_UPHY0_TCPDPWRUP		150
+#define SRST_USB2PHY1_POR		152
+#define SRST_USB2PHY1_UTMI_PORT0	153
+#define SRST_USB2PHY1_UTMI_PORT1	154
+#define SRST_USB2PHY1_EHCIPHY		155
+#define SRST_UPHY1_PIPE_L00		156
+#define SRST_UPHY1			157
+#define SRST_UPHY1_TCPDPWRUP		158
+
+/* cru_softrst_con10 */
+#define SRST_A_PERILP0_NIU		160
+#define SRST_A_DCF			161
+#define SRST_GIC500			162
+#define SRST_DMAC0_PERILP0		163
+#define SRST_DMAC1_PERILP0		164
+#define SRST_TZMA			165
+#define SRST_INTMEM			166
+#define SRST_ADB400_MST0		167
+#define SRST_ADB400_MST1		168
+#define SRST_ADB400_SLV0		169
+#define SRST_ADB400_SLV1		170
+#define SRST_H_PERILP0			171
+#define SRST_H_PERILP0_NIU		172
+#define SRST_ROM			173
+#define SRST_CRYPTO_S			174
+#define SRST_CRYPTO_M			175
+
+/* cru_softrst_con11 */
+#define SRST_P_DCF			176
+#define SRST_CM0S_NIU			177
+#define SRST_CM0S			178
+#define SRST_CM0S_DBG			179
+#define SRST_CM0S_PO			180
+#define SRST_CRYPTO			181
+#define SRST_P_PERILP1_SGRF		182
+#define SRST_P_PERILP1_GRF		183
+#define SRST_CRYPTO1_S			184
+#define SRST_CRYPTO1_M			185
+#define SRST_CRYPTO1			186
+#define SRST_GIC_NIU			188
+#define SRST_SD_NIU			189
+#define SRST_SDIOAUDIO_BRG		190
+
+/* cru_softrst_con12 */
+#define SRST_H_PERILP1			192
+#define SRST_H_PERILP1_NIU		193
+#define SRST_H_I2S0_8CH			194
+#define SRST_H_I2S1_8CH			195
+#define SRST_H_I2S2_8CH			196
+#define SRST_H_SPDIF_8CH		197
+#define SRST_P_PERILP1_NIU		198
+#define SRST_P_EFUSE_1024		199
+#define SRST_P_EFUSE_1024S		200
+#define SRST_P_I2C0			201
+#define SRST_P_I2C1			202
+#define SRST_P_I2C2			203
+#define SRST_P_I2C3			204
+#define SRST_P_I2C4			205
+#define SRST_P_I2C5			206
+#define SRST_P_MAILBOX0			207
+
+/* cru_softrst_con13 */
+#define SRST_P_UART0			208
+#define SRST_P_UART1			209
+#define SRST_P_UART2			210
+#define SRST_P_UART3			211
+#define SRST_P_SARADC			212
+#define SRST_P_TSADC			213
+#define SRST_P_SPI0			214
+#define SRST_P_SPI1			215
+#define SRST_P_SPI2			216
+#define SRST_P_SPI3			217
+#define SRST_P_SPI4			218
+#define SRST_SPI0			219
+#define SRST_SPI1			220
+#define SRST_SPI2			221
+#define SRST_SPI3			222
+#define SRST_SPI4			223
+
+/* cru_softrst_con14 */
+#define SRST_I2S0_8CH			224
+#define SRST_I2S1_8CH			225
+#define SRST_I2S2_8CH			226
+#define SRST_SPDIF_8CH			227
+#define SRST_UART0			228
+#define SRST_UART1			229
+#define SRST_UART2			230
+#define SRST_UART3			231
+#define SRST_TSADC			232
+#define SRST_I2C0			233
+#define SRST_I2C1			234
+#define SRST_I2C2			235
+#define SRST_I2C3			236
+#define SRST_I2C4			237
+#define SRST_I2C5			238
+#define SRST_SDIOAUDIO_NIU		239
+
+/* cru_softrst_con15 */
+#define SRST_A_VIO_NIU			240
+#define SRST_A_HDCP_NIU			241
+#define SRST_A_HDCP			242
+#define SRST_H_HDCP_NIU			243
+#define SRST_H_HDCP			244
+#define SRST_P_HDCP_NIU			245
+#define SRST_P_HDCP			246
+#define SRST_P_HDMI_CTRL		247
+#define SRST_P_DP_CTRL			248
+#define SRST_S_DP_CTRL			249
+#define SRST_C_DP_CTRL			250
+#define SRST_P_MIPI_DSI0		251
+#define SRST_P_MIPI_DSI1		252
+#define SRST_DP_CORE			253
+#define SRST_DP_I2S			254
+#define SRST_DP_VIF			255
+
+/* cru_softrst_con16 */
+#define SRST_GASKET			256
+#define SRST_VIO_SGRF			257
+#define SRST_VIO_GRF			258
+#define SRST_DPTX_SPDIF_REC		259
+#define SRST_HDMI_CTRL			260
+#define SRST_HDCP_CTRL			261
+#define SRST_A_ISP0_NIU			262
+#define SRST_A_ISP1_NIU			263
+#define SRST_A_ISP0			264
+#define SRST_A_ISP1			265
+#define SRST_H_ISP0_NIU			266
+#define SRST_H_ISP1_NIU			267
+#define SRST_H_ISP0			268
+#define SRST_H_ISP1			269
+#define SRST_ISP0			270
+#define SRST_ISP1			271
+
+/* cru_softrst_con17 */
+#define SRST_A_VOP0_NIU			272
+#define SRST_A_VOP1_NIU			273
+#define SRST_A_VOP0			274
+#define SRST_A_VOP1			275
+#define SRST_H_VOP0_NIU			276
+#define SRST_H_VOP1_NIU			277
+#define SRST_H_VOP0			278
+#define SRST_H_VOP1			279
+#define SRST_D_VOP0			280
+#define SRST_D_VOP1			281
+#define SRST_VOP0_PWM			282
+#define SRST_VOP1_PWM			283
+#define SRST_P_EDP_NIU			284
+#define SRST_P_EDP_CTRL			285
+
+/* cru_softrst_con18 */
+#define SRST_A_GPU			288
+#define SRST_A_GPU_NIU			289
+#define SRST_A_GPU_GRF			290
+#define SRST_PVTM_GPU			291
+#define SRST_A_USB3_NIU			292
+#define SRST_A_USB3_OTG0		293
+#define SRST_A_USB3_OTG1		294
+#define SRST_A_USB3_GRF			295
+#define SRST_PMU			296
+#define SRST_PVTM_PMU			297
+
+/* cru_softrst_con19 */
+#define SRST_P_TIMER0_5			304
+#define SRST_TIMER0			305
+#define SRST_TIMER1			306
+#define SRST_TIMER2			307
+#define SRST_TIMER3			308
+#define SRST_TIMER4			309
+#define SRST_TIME5			310
+#define SRST_P_TIMER6_11		311
+#define SRST_TIMER6			312
+#define SRST_TIMER7			313
+#define SRST_TIMER8			314
+#define SRST_TIMER9			315
+#define SRST_TIMER10			316
+#define SRST_TIMER11			317
+#define SRST_P_INTR_ARB_PMU		318
+#define SRST_P_ALIVE_SGRF		319
+
+/* cru_softrst_con20 */
+#define SRST_P_GPIO2			320
+#define SRST_P_GPIO3			321
+#define SRST_P_GPIO4			322
+#define SRST_P_GRF			323
+#define SRST_P_ALIVE_NIU		324
+#define SRST_P_WDT0			325
+#define SRST_P_WDT1			326
+#define SRST_P_INTR_ARB 		327
+#define SRST_P_UPHY0_DPTX		328
+#define SRST_P_UPHY1_DPTX		329
+#define SRST_P_UPHY0_APB		330
+#define SRST_P_UPHY1_APB		331
+#define SRST_P_UPHY0_TCPHY		332
+#define SRST_P_UPHY1_TCPHY		333
+#define SRST_P_UPHY0_TCPDCTRL		334
+#define SRST_P_UPHY1_TCPDCTRL		335
+
+/* pmu soft-reset indices */
+
+/* pmu_cru_softrst_con0 */
+#define SRST_P_NIU			0
+#define SRST_P_INTMEN			1
+#define SRST_H_CM0S			2
+#define SRST_H_CM0S_NIU			3
+#define SRST_DBG_CM0S			4
+#define SRST_PO_CM0S			5
+#define SRST_P_SPI6			6
+#define SRST_SPI6			7
+#define SRST_P_TIMER_0_1		8
+#define SRST_P_TIMER_0			9
+#define SRST_P_TIMER_1			10
+#define SRST_P_UART4			11
+#define SRST_UART4			12
+#define SRST_P_WDT			13
+
+/* pmu_cru_softrst_con1 */
+#define SRST_P_I2C6			16
+#define SRST_P_I2C7			17
+#define SRST_P_I2C8			18
+#define SRST_P_MAILBOX			19
+#define SRST_P_RKPWM			20
+#define SRST_P_PMUGRF			21
+#define SRST_P_SGRF			22
+#define SRST_P_GPIO0			23
+#define SRST_P_GPIO1			24
+#define SRST_P_CRU			25
+#define SRST_P_INTR			26
+#define SRST_PVTM 			27
+#define SRST_I2C6			28
+#define SRST_I2C7			29
+#define SRST_I2C8			30
+
+#endif
-- 
1.9.1




From jay.xu at rock-chips.com  Tue Feb 16 17:53:08 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Wed, 17 Feb 2016 09:53:08 +0800
Subject: [PATCH 2/6] spi: rockchip: add bindings for rk3399 spi
In-Reply-To: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455673992-16469-3-git-send-email-jay.xu@rock-chips.com>

From: Xu Jianqun <jay.xu at rock-chips.com>

Add devicetree bindings for Rockchip rk3399 spi which found on
Rockchip rk3399 SoCs.

Signed-off-by: Xu Jianqun <jay.xu at rock-chips.com>
---
 Documentation/devicetree/bindings/spi/spi-rockchip.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
index 0c491bd..1b14d69 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
@@ -9,6 +9,7 @@ Required Properties:
     "rockchip,rk3066-spi" for rk3066.
     "rockchip,rk3188-spi", "rockchip,rk3066-spi" for rk3188.
     "rockchip,rk3288-spi", "rockchip,rk3066-spi" for rk3288.
+    "rockchip,rk3399-spi", "rockchip,rk3066-spi" for rk3399.
 - reg: physical base address of the controller and length of memory mapped
        region.
 - interrupts: The interrupt number to the cpu. The interrupt specifier format
-- 
1.9.1




From jay.xu at rock-chips.com  Tue Feb 16 17:53:10 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Wed, 17 Feb 2016 09:53:10 +0800
Subject: [PATCH 4/6] pinctrl: rockchip: add bindings for rk3399 pinctrl
In-Reply-To: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455673992-16469-5-git-send-email-jay.xu@rock-chips.com>

From: Xu Jianqun <jay.xu at rock-chips.com>

Add devicetree bindings for pinctrl found on rk3399
processors from rockchip.

Signed-off-by: Xu Jianqun <jay.xu at rock-chips.com>
---
 Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
index 0cd701b..c68b955 100644
--- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
@@ -22,7 +22,7 @@ Required properties for iomux controller:
   - compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl"
 		       "rockchip,rk3066b-pinctrl", "rockchip,rk3188-pinctrl"
 		       "rockchip,rk3228-pinctrl", "rockchip,rk3288-pinctrl"
-		       "rockchip,rk3368-pinctrl"
+		       "rockchip,rk3368-pinctrl", "rockchip,rk3399-pinctrl"
   - rockchip,grf: phandle referencing a syscon providing the
 	 "general register files"
 
-- 
1.9.1




From jay.xu at rock-chips.com  Tue Feb 16 17:54:49 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Wed, 17 Feb 2016 09:54:49 +0800
Subject: [PATCH 5/6] dt-bindings: add documentation of rk3399 clock controller
In-Reply-To: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455674089-16567-1-git-send-email-jay.xu@rock-chips.com>

From: Xing Zheng <zhengxing at rock-chips.com>

Add the devicetree binding for the cru on the rk3399 which quite
similar structured as previous clock controllers.

Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
---
 .../bindings/clock/rockchip,rk3399-cru.txt         | 82 ++++++++++++++++++++++
 1 file changed, 82 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
new file mode 100644
index 0000000..07bcc6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
@@ -0,0 +1,82 @@
+* Rockchip RK3399 Clock and Reset Unit
+
+The RK3399 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: PMU for CRU should be "rockchip,rk3399-pmucru"
+- compatible: CRU should be "rockchip,rk3399-cru"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+  If missing, pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "xin32k" - rtc clock - optional,
+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_gmac" - external GMAC clock - optional
+ - "ext_hsadc" - external HSADC clock - optional,
+ - "ext_isp" - external ISP clock - optional,
+ - "ext_jtag" - external JTAG clock - optional
+ - "ext_vip" - external VIP clock - optional,
+ - "usbotg_out" - output clock of the pll in the otg phy
+
+Example: General Register Files
+
+	pmugrf: syscon at ff320000 {
+		compatible = "rockchip,rk3399-pmugrf", "syscon";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+	};
+
+	grf: syscon at ff770000 {
+		compatible = "rockchip,rk3399-grf", "syscon";
+		reg = <0x0 0xff770000 0x0 0x10000>;
+	};
+
+Example: Clock controller node:
+
+	pmucru: pmu-clock-controller at ff750000 {
+		compatible = "rockchip,rk3399-pmucru";
+		reg = <0x0 0xff750000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at ff760000 {
+		compatible = "rockchip,rk3399-cru";
+		reg = <0x0 0xff760000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller:
+
+	uart0: serial at ff1a0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff180000 0x0 0x100>;
+		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+	};
-- 
1.9.1




From k.kozlowski at samsung.com  Tue Feb 16 18:02:44 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 17 Feb 2016 11:02:44 +0900
Subject: [PATCH 11/11] iommu: exynos: add Maintainers entry for Exynos
 SYSMMU driver
In-Reply-To: <1455634624-18130-12-git-send-email-m.szyprowski@samsung.com>
References: <1455634624-18130-1-git-send-email-m.szyprowski@samsung.com>
 <1455634624-18130-12-git-send-email-m.szyprowski@samsung.com>
Message-ID: <56C3D4C4.20507@samsung.com>

On 16.02.2016 23:57, Marek Szyprowski wrote:
> Add Marek Szyprowski as maintainer for Exynos IOMMU driver.
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
> ---
>  MAINTAINERS | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Acked-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>

Best regards,
Krzysztof


> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7bd927e..1e9c4df 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4336,6 +4336,12 @@ L:	dri-devel at lists.freedesktop.org
>  S:	Maintained
>  F:	drivers/gpu/drm/exynos/exynos_dp*
>  
> +EXYNOS SYSMMU (IOMMU) driver
> +M:	Marek Szyprowski <m.szyprowski at samsung.com>
> +L:	iommu at lists.linux-foundation.org
> +S:	Maintained
> +F:	drivers/iommu/exynos-iommu.c
> +
>  EXYNOS MIPI DISPLAY DRIVERS
>  M:	Inki Dae <inki.dae at samsung.com>
>  M:	Donghwa Lee <dh09.lee at samsung.com>
> 



From jay.xu at rock-chips.com  Tue Feb 16 18:01:16 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Wed, 17 Feb 2016 10:01:16 +0800
Subject: [PATCH 6/6] ARM64: dts: rockchip: add core dtsi file for rk3399
In-Reply-To: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455674476-16655-1-git-send-email-jay.xu@rock-chips.com>

From: Xu Jianqun <jay.xu at rock-chips.com>

Add dtsi file for Rockchip rk3399 SoCs, which includes some
general nodes such as cpu, pmu, cru, gic, amba and so on.

Change-Id: Ie3b824e8ead967d4cb119d73222b7a198478c29c
Signed-off-by: Xu Jianqun <jay.xu at rock-chips.com>
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 989 +++++++++++++++++++++++++++++++
 1 file changed, 989 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 0000000..eb671f6
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,989 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+#include <dt-bindings/clock/rk3399-cru.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+
+/ {
+	compatible = "rockchip,rk3399";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+	};
+
+	psci {
+		compatible = "arm,psci";
+		method = "smc";
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu_l0>;
+				};
+				core1 {
+					cpu = <&cpu_l1>;
+				};
+				core2 {
+					cpu = <&cpu_l2>;
+				};
+				core3 {
+					cpu = <&cpu_l3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu_b0>;
+				};
+				core1 {
+					cpu = <&cpu_b1>;
+				};
+			};
+		};
+
+		idle-states {
+			entry-method = "psci";
+
+			cpu_sleep: cpu-sleep-0 {
+				compatible = "arm,idle-state";
+			};
+		};
+
+		cpu_l0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x0>;
+			cpu-idle-states = <&cpu_sleep>;
+			enable-method = "psci";
+		};
+
+		cpu_l1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x1>;
+			cpu-idle-states = <&cpu_sleep>;
+			enable-method = "psci";
+		};
+
+		cpu_l2: cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x2>;
+			cpu-idle-states = <&cpu_sleep>;
+			enable-method = "psci";
+		};
+
+		cpu_l3: cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x3>;
+			cpu-idle-states = <&cpu_sleep>;
+			enable-method = "psci";
+		};
+
+		cpu_b0: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x0 0x100>;
+			cpu-idle-states = <&cpu_sleep>;
+			enable-method = "psci";
+		};
+
+		cpu_b1: cpu at 101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x0 0x101>;
+			cpu-idle-states = <&cpu_sleep>;
+			enable-method = "psci";
+		};
+	};
+
+	pmu {
+		compatible = "arm,armv8-pmuv3";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
+		interrupt-affinity = <&cpu_l0>, <&cpu_l1>, <&cpu_l2>,
+				     <&cpu_l3>, <&cpu_b0>, <&cpu_b1>;
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts =
+			<GIC_PPI 13
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			<GIC_PPI 14
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			<GIC_PPI 11
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			<GIC_PPI 10
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+		clock-frequency = <24000000>;
+	};
+
+	xin24m: xin24m {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24000000>;
+		clock-output-names = "xin24m";
+	};
+
+	gic: interrupt-controller at fee00000 {
+		compatible = "arm,gic-v3";
+		#interrupt-cells = <3>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		interrupt-controller;
+
+		reg = <0x0 0xfee00000 0 0x10000>, /* GICD */
+		      <0x0 0xfef00000 0 0xc0000>, /* GICR */
+		      <0x0 0xfff00000 0 0x10000>, /* GICC */
+		      <0x0 0xfff10000 0 0x10000>, /* GICH */
+		      <0x0 0xfff20000 0 0x10000>; /* GICV */
+		interrupts =
+			<GIC_PPI 9
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+		its: interrupt-controller at fee20000 {
+			compatible = "arm,gic-v3-its";
+			msi-controller;
+			reg = <0x0 0xfee20000 0x0 0x20000>;
+		};
+	};
+
+	amba {
+		compatible = "arm,amba-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		dmac_bus: dma-controller at ff6d0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x0 0xff6d0000 0x0 0x4000>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			clocks = <&cru ACLK_DMAC_BUS>;
+			clock-names = "apb_pclk";
+		};
+
+		dmac_peri: dma-controller at ff6e0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x0 0xff6e0000 0x0 0x4000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			clocks = <&cru ACLK_DMAC_PERI>;
+			clock-names = "apb_pclk";
+		};
+	};
+
+	uart0: serial at ff180000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff180000 0x0 0x100>;
+		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart1: serial at ff190000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff190000 0x0 0x100>;
+		clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart2: serial at ff1a0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff1a0000 0x0 0x100>;
+		clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart3: serial at ff1b0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff1b0000 0x0 0x100>;
+		clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	spi0: spi at ff1c0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff110000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI0>, <&cru PCLK_SPI0>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi0_clk &spi0_tx &spi0_rx &spi0_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi1: spi at ff1d0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff120000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI1>, <&cru PCLK_SPI1>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi1_clk &spi1_tx &spi1_rx &spi1_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi2: spi at ff1e0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff130000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI2>, <&cru PCLK_SPI2>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi2_clk &spi2_tx &spi2_rx &spi2_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi4: spi at ff1f0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff120000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI4>, <&cru PCLK_SPI4>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi4_clk &spi4_tx &spi4_rx &spi4_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi5: spi at ff200000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff130000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI5>, <&cru PCLK_SPI5>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi5_clk &spi5_tx &spi5_rx &spi5_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	pmugrf: syscon at ff320000 {
+		compatible = "rockchip,rk3399-pmugrf", "syscon";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+	};
+
+	spi3: spi at ff350000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff110000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI3>, <&cru PCLK_SPI3>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi3_clk &spi3_tx &spi3_rx &spi3_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	uart4: serial at ff370000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff370000 0x0 0x100>;
+		clocks = <&cru SCLK_UART4>, <&cru PCLK_UART4>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	pmucru: pmu-clock-controller at ff750000 {
+		compatible = "rockchip,rk3399-pmucru";
+		reg = <0x0 0xff750000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at ff760000 {
+		compatible = "rockchip,rk3399-cru";
+		reg = <0x0 0xff760000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	grf: syscon at ff770000 {
+		compatible = "rockchip,rk3399-grf", "syscon";
+		reg = <0x0 0xff770000 0x0 0x10000>;
+	};
+
+	i2s0: i2s at ff880000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff880000 0x0 0x1000>;
+		interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 0>, <&dmac_bus 1>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S0_8CH>, <&cru SCLK_I2S0_8CH>;
+		status = "disabled";
+	};
+
+	i2s1: i2s at ff890000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff890000 0x0 0x1000>;
+		interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 2>, <&dmac_bus 3>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S1_8CH>, <&cru SCLK_I2S1_8CH>;
+		status = "disabled";
+	};
+
+	i2s2: i2s at ff8a0000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff8a0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 4>, <&dmac_bus 5>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S2_8CH>, <&cru SCLK_I2S2_8CH>;
+		status = "disabled";
+	};
+
+	pinctrl: pinctrl {
+		compatible = "rockchip,rk3399-pinctrl";
+		rockchip,grf = <&grf>;
+		rockchip,pmu = <&pmugrf>;
+		#address-cells = <0x2>;
+		#size-cells = <0x2>;
+		ranges;
+
+		gpio0: gpio0 at ff720000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff720000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio1: gpio1 at ff730000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff730000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio2: gpio2 at ff780000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff780000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio3: gpio3 at ff788000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff788000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio4: gpio4 at ff790000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff790000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		pcfg_pull_up: pcfg-pull-up {
+			bias-pull-up;
+		};
+
+		pcfg_pull_down: pcfg-pull-down {
+			bias-pull-down;
+		};
+
+		pcfg_pull_none: pcfg-pull-none {
+			bias-disable;
+		};
+
+		pcfg_pull_none_12ma: pcfg-pull-none-12ma {
+			bias-disable;
+			drive-strength = <12>;
+		};
+
+		pcfg_pull_up_8ma: pcfg-pull-up-8ma {
+			bias-pull-up;
+			drive-strength = <8>;
+		};
+
+		pcfg_pull_down_4ma: pcfg-pull-down-4ma {
+			bias-pull-down;
+			drive-strength = <4>;
+		};
+
+		pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+			bias-pull-up;
+			drive-strength = <2>;
+		};
+
+		pcfg_pull_down_12ma: pcfg-pull-down-12ma {
+			bias-pull-down;
+			drive-strength = <12>;
+		};
+
+		emmc {
+			emmc_pwr: emmc-pwr {
+				rockchip,pins =
+					<0 5 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		gmac {
+			rgmii_pins: rgmii-pins {
+				rockchip,pins =
+					<3 11 RK_FUNC_1 &pcfg_pull_none>,
+					<3 13 RK_FUNC_1 &pcfg_pull_none>,
+					<3 8 RK_FUNC_1 &pcfg_pull_none>,
+					<3 4 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 5 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 0 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 1 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 17 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 12 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 6 RK_FUNC_1 &pcfg_pull_none>,
+					<3 7 RK_FUNC_1 &pcfg_pull_none>,
+					<3 2 RK_FUNC_1 &pcfg_pull_none>,
+					<3 3 RK_FUNC_1 &pcfg_pull_none>,
+					<3 14 RK_FUNC_1 &pcfg_pull_none>,
+					<3 9 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			rmii_pins: rmii-pins {
+				rockchip,pins =
+					<3 11 RK_FUNC_1 &pcfg_pull_none>,
+					<3 13 RK_FUNC_1 &pcfg_pull_none>,
+					<3 8 RK_FUNC_1 &pcfg_pull_none>,
+					<3 4 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 5 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 12 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 6 RK_FUNC_1 &pcfg_pull_none>,
+					<3 7 RK_FUNC_1 &pcfg_pull_none>,
+					<3 9 RK_FUNC_1 &pcfg_pull_none>,
+					<3 10 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c0 {
+			i2c0_xfer: i2c0-xfer {
+				rockchip,pins =
+					<1 15 RK_FUNC_2 &pcfg_pull_none>,
+					<1 16 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c1 {
+			i2c1_xfer: i2c1-xfer {
+				rockchip,pins =
+					<4 2 RK_FUNC_1 &pcfg_pull_none>,
+					<4 1 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c2 {
+			i2c2_xfer: i2c2-xfer {
+				rockchip,pins =
+					<2 1 RK_FUNC_2 &pcfg_pull_none_12ma>,
+					<2 0 RK_FUNC_2 &pcfg_pull_none_12ma>;
+			};
+		};
+
+		i2c3 {
+			i2c3_xfer: i2c3-xfer {
+				rockchip,pins =
+					<4 17 RK_FUNC_1 &pcfg_pull_none>,
+					<4 16 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c4 {
+			i2c4_xfer: i2c4-xfer {
+				rockchip,pins =
+					<1 12 RK_FUNC_1 &pcfg_pull_none>,
+					<1 11 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c5 {
+			i2c5_xfer: i2c5-xfer {
+				rockchip,pins =
+					<3 11 RK_FUNC_2 &pcfg_pull_none>,
+					<3 10 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c6 {
+			i2c6_xfer: i2c6-xfer {
+				rockchip,pins =
+					<2 10 RK_FUNC_2 &pcfg_pull_none>,
+					<2 9 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c7 {
+			i2c7_xfer: i2c7-xfer {
+				rockchip,pins =
+					<2 8 RK_FUNC_2 &pcfg_pull_none>,
+					<2 7 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c8 {
+			i2c8_xfer: i2c8-xfer {
+				rockchip,pins =
+					<1 21 RK_FUNC_1 &pcfg_pull_none>,
+					<1 20 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2s0 {
+			i2s0_8ch_bus: i2s0-8ch-bus {
+				rockchip,pins =
+					<3 24 RK_FUNC_1 &pcfg_pull_none>,
+					<3 25 RK_FUNC_1 &pcfg_pull_none>,
+					<3 26 RK_FUNC_1 &pcfg_pull_none>,
+					<3 27 RK_FUNC_1 &pcfg_pull_none>,
+					<3 28 RK_FUNC_1 &pcfg_pull_none>,
+					<3 29 RK_FUNC_1 &pcfg_pull_none>,
+					<3 30 RK_FUNC_1 &pcfg_pull_none>,
+					<3 31 RK_FUNC_1 &pcfg_pull_none>,
+					<4 0 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2s1 {
+			i2s1_2ch_bus: i2s1-2ch-bus {
+				rockchip,pins =
+					<4 3 RK_FUNC_1 &pcfg_pull_none>,
+					<4 4 RK_FUNC_1 &pcfg_pull_none>,
+					<4 5 RK_FUNC_1 &pcfg_pull_none>,
+					<4 6 RK_FUNC_1 &pcfg_pull_none>,
+					<4 7 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		sdio0 {
+			sdio0_bus1: sdio0-bus1 {
+				rockchip,pins =
+					<2 20 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_bus4: sdio0-bus4 {
+				rockchip,pins =
+					<2 20 RK_FUNC_1 &pcfg_pull_up>,
+					<2 21 RK_FUNC_1 &pcfg_pull_up>,
+					<2 22 RK_FUNC_1 &pcfg_pull_up>,
+					<2 23 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_cmd: sdio0-cmd {
+				rockchip,pins =
+					<2 24 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_clk: sdio0-clk {
+				rockchip,pins =
+					<2 25 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			sdio0_cd: sdio0-cd {
+				rockchip,pins =
+					<2 26 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_pwr: sdio0-pwr {
+				rockchip,pins =
+					<2 27 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_bkpwr: sdio0-bkpwr {
+				rockchip,pins =
+					<2 28 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_wp: sdio0-wp {
+				rockchip,pins =
+					<0 3 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_int: sdio0-int {
+				rockchip,pins =
+					<0 4 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		sdmmc {
+			sdmmc_bus1: sdmmc-bus1 {
+				rockchip,pins =
+					<4 8 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_bus4: sdmmc-bus4 {
+				rockchip,pins =
+					<4 8 RK_FUNC_1 &pcfg_pull_up>,
+					<4 9 RK_FUNC_1 &pcfg_pull_up>,
+					<4 10 RK_FUNC_1 &pcfg_pull_up>,
+					<4 11 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_clk: sdmmc-clk {
+				rockchip,pins =
+					<4 12 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			sdmmc_cmd: sdmmc-cmd {
+				rockchip,pins =
+					<4 13 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_cd: sdmcc-cd {
+				rockchip,pins =
+					<0 7 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_wp: sdmmc-wp {
+				rockchip,pins =
+					<0 8 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi0 {
+			spi0_clk: spi0-clk {
+				rockchip,pins =
+					<3 6 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_cs0: spi0-cs0 {
+				rockchip,pins =
+					<3 7 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_cs1: spi0-cs1 {
+				rockchip,pins =
+					<3 8 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_tx: spi0-tx {
+				rockchip,pins =
+					<3 5 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_rx: spi0-rx {
+				rockchip,pins =
+					<3 4 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi1 {
+			spi1_clk: spi1-clk {
+				rockchip,pins =
+					<1 9 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_cs0: spi1-cs0 {
+				rockchip,pins =
+					<1 10 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_rx: spi1-rx {
+				rockchip,pins =
+					<1 7 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_tx: spi1-tx {
+				rockchip,pins =
+					<1 8 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi2 {
+			spi2_clk: spi2-clk {
+				rockchip,pins =
+					<2 11 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_cs0: spi2-cs0 {
+				rockchip,pins =
+					<2 12 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_rx: spi2-rx {
+				rockchip,pins =
+					<2 9 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_tx: spi2-tx {
+				rockchip,pins =
+					<2 10 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi3 {
+			spi3_clk: spi3-clk {
+				rockchip,pins =
+					<1 17 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_cs0: spi3-cs0 {
+				rockchip,pins =
+					<1 18 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_rx: spi3-rx {
+				rockchip,pins =
+					<1 15 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_tx: spi3-tx {
+				rockchip,pins =
+					<1 16 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi4 {
+			spi4_clk: spi4-clk {
+				rockchip,pins =
+					<3 2 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_cs0: spi4-cs0 {
+				rockchip,pins =
+					<3 3 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_rx: spi4-rx {
+				rockchip,pins =
+					<3 0 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_tx: spi4-tx {
+				rockchip,pins =
+					<3 1 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi5 {
+			spi5_clk: spi5-clk {
+				rockchip,pins =
+					<2 22 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_cs0: spi5-cs0 {
+				rockchip,pins =
+					<2 23 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_rx: spi5-rx {
+				rockchip,pins =
+					<2 20 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_tx: spi5-tx {
+				rockchip,pins =
+					<2 21 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		uart0 {
+			uart0_xfer: uart0-xfer {
+				rockchip,pins =
+					<2 16 RK_FUNC_1 &pcfg_pull_up>,
+					<2 17 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			uart0_cts: uart0-cts {
+				rockchip,pins =
+					<2 18 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			uart0_rts: uart0-rts {
+				rockchip,pins =
+					<2 19 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uart1 {
+			uart1_xfer: uart1-xfer {
+				rockchip,pins =
+					<3 12 RK_FUNC_2 &pcfg_pull_up>,
+					<3 13 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2a {
+			uart2a_xfer: uart2a-xfer {
+				rockchip,pins =
+					<4 8 RK_FUNC_2 &pcfg_pull_up>,
+					<4 9 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2b {
+			uart2b_xfer: uart2b-xfer {
+				rockchip,pins =
+					<4 16 RK_FUNC_2 &pcfg_pull_up>,
+					<4 17 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2c {
+			uart2c_xfer: uart2c-xfer {
+				rockchip,pins =
+					<4 19 RK_FUNC_1 &pcfg_pull_up>,
+					<4 20 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uart3 {
+			uart3_xfer: uart3-xfer {
+				rockchip,pins =
+					<3 14 RK_FUNC_2 &pcfg_pull_up>,
+					<3 15 RK_FUNC_2 &pcfg_pull_none>;
+			};
+
+			uart3_cts: uart3-cts {
+				rockchip,pins =
+					<3 18 RK_FUNC_2 &pcfg_pull_none>;
+			};
+
+			uart3_rts: uart3-rts {
+				rockchip,pins =
+					<3 19 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart4 {
+			uart4_xfer: uart4-xfer {
+				rockchip,pins =
+					<1 7 RK_FUNC_1 &pcfg_pull_up>,
+					<1 8 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uarthdcp {
+			uarthdcp_xfer: uarthdcp-xfer {
+				rockchip,pins =
+					<4 21 RK_FUNC_2 &pcfg_pull_up>,
+					<4 22 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		pwm0 {
+			pwm0_pin: pwm0-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			vop0_pwm_pin: vop0-pwm-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		pwm1 {
+			pwm1_pin: pwm1-pin {
+				rockchip,pins =
+					<4 22 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			vop1_pwm_pin: vop1-pwm-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_3 &pcfg_pull_none>;
+			};
+		};
+	};
+};
-- 
1.9.1




From jay.xu at rock-chips.com  Tue Feb 16 18:04:00 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Wed, 17 Feb 2016 10:04:00 +0800
Subject: [PATCH 1/6] clk: rockchip: add dt-binding header for rk3399
In-Reply-To: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455674640-16719-1-git-send-email-jay.xu@rock-chips.com>

From: Xing Zheng <zhengxing at rock-chips.com>

Add the dt-bindings header for the rk3399, that gets shared between
the clock controller and the clock references in the dts.

Change-Id: I01830a46b679f4630506e8cb48b1a39e113a9952
Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
---
 include/dt-bindings/clock/rk3399-cru.h | 610 +++++++++++++++++++++++++++++++++
 1 file changed, 610 insertions(+)
 create mode 100644 include/dt-bindings/clock/rk3399-cru.h

diff --git a/include/dt-bindings/clock/rk3399-cru.h b/include/dt-bindings/clock/rk3399-cru.h
new file mode 100644
index 0000000..42a1618
--- /dev/null
+++ b/include/dt-bindings/clock/rk3399-cru.h
@@ -0,0 +1,610 @@
+/*
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng <zhengxing at rock-chips.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H
+#define _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H
+
+/* core clocks */
+#define PLL_APLLL		1
+#define PLL_APLLB		2
+#define PLL_DPLL		3
+#define PLL_CPLL		4
+#define PLL_GPLL		5
+#define PLL_NPLL		6
+#define PLL_VPLL		7
+#define PLL_PPLL		8
+#define ARMCLKL			9
+#define ARMCLKB			10
+
+/* sclk gates (special clocks) */
+#define SCLK_GPU_CORE		64
+#define SCLK_SPI0		65
+#define SCLK_SPI1		66
+#define SCLK_SPI2		68
+#define SCLK_SPI3		69
+#define SCLK_SPI4		70
+#define SCLK_SPI5		71
+#define SCLK_SDMMC		72
+#define SCLK_SDIO0		73
+#define SCLK_EMMC		74
+#define SCLK_TSADC		75
+#define SCLK_SARADC		76
+#define SCLK_NANDC0		77
+#define SCLK_UART0		78
+#define SCLK_UART1		79
+#define SCLK_UART2		80
+#define SCLK_UART3		81
+#define SCLK_UART4		82
+#define SCLK_SPDIF_8CH		83
+#define SCLK_I2S0_8CH		84
+#define SCLK_I2S1_8CH		85
+#define SCLK_I2S2_8CH		86
+#define SCLK_TIMER00		87
+#define SCLK_TIMER01		88
+#define SCLK_TIMER02		89
+#define SCLK_TIMER03		90
+#define SCLK_TIMER04		91
+#define SCLK_TIMER05		92
+#define SCLK_TIMER06		93
+#define SCLK_TIMER07		94
+#define SCLK_TIMER08		95
+#define SCLK_TIMER09		96
+#define SCLK_TIMER10		97
+#define SCLK_TIMER11		98
+#define SCLK_HSICPHY480M	99
+#define SCLK_HSICPHY12M		100
+#define SCLK_MACREF		101
+#define SCLK_VOPB_PWM		102
+#define SCLK_VOPL_PWM		103
+#define SCLK_EDP_24M		104
+#define SCLK_EDP		105
+#define SCLK_RGA		106
+#define SCLK_ISP		107
+#define SCLK_HDCP		108
+#define SCLK_HDMI_HDCP		109
+#define SCLK_HDMI_CEC		110
+#define SCLK_HEVC_CABAC		111
+#define SCLK_HEVC_CORE		112
+#define SCLK_I2S_8CH_OUT	113
+#define SCLK_SDMMC_DRV		114
+#define SCLK_SDIO0_DRV		115
+#define SCLK_SDIO1_DRV		116
+#define SCLK_EMMC_DRV		117
+#define SCLK_SDMMC_SAMPLE	118
+#define SCLK_SDIO0_SAMPLE	119
+#define SCLK_SDIO1_SAMPLE	120
+#define SCLK_EMMC_SAMPLE	121
+#define SCLK_USBPHY480M		122
+#define SCLK_PVTM_CORE_L	123
+#define SCLK_PVTM_CORE_B	124
+#define SCLK_PVTM_GPU		125
+#define SCLK_PVTM_PMU		126
+#define SCLK_SFC		127
+#define SCLK_MAC_RX		128
+#define SCLK_MAC_TX		129
+#define SCLK_MAC		130
+#define SCLK_MACREF_OUT		131
+#define SCLK_USB2_PHY0_REF	132
+#define SCLK_USB2_PHY1_REF	133
+#define SCLK_USB3_OTG0_REF	134
+#define SCLK_USB3_OTG1_REF	135
+#define SCLK_USB3_OTG0_SUSPEND	136
+#define SCLK_USB3_OTG1_SUSPEND	137
+#define SCLK_CRYPTO		138
+#define SCLK_CRYPTO1		139
+
+#define DCLK_VOPB		170
+#define DCLK_VOPL		171
+#define MCLK_CRYPTO		172
+#define MCLK_CRYPTO1		173
+
+/* aclk gates */
+#define ACLK_GPU_MEM		192
+#define ACLK_GPU_CFG		193
+#define ACLK_DMAC_BUS		194
+#define ACLK_DMAC_PERI		195
+#define ACLK_PERI_MMU		196
+#define ACLK_GMAC		197
+#define ACLK_VOPB		198
+#define ACLK_VOPL		199
+#define ACLK_RGA		200
+#define ACLK_HDCP		201
+#define ACLK_IEP		202
+#define ACLK_VIO0_NOC		203
+#define ACLK_VIP		204
+#define ACLK_ISP		205
+#define ACLK_VIO1_NOC		206
+#define ACLK_VIDEO		208
+#define ACLK_BUS		209
+#define ACLK_PERI		210
+#define ACLK_EMMC_GPLL		211
+#define ACLK_EMMC_CPLL		212
+#define ACLK_EMMC_CORE		213
+#define ACLK_EMMC_NIU 		214
+#define ACLK_EMMC_GRF 		215
+#define ACLK_USB3_OTG0		216
+#define ACLK_USB3_OTG1		217
+#define ACLK_USB3_GRF 		218
+
+/* pclk gates */
+#define PCLK_GPIO0		320
+#define PCLK_GPIO1		321
+#define PCLK_GPIO2		322
+#define PCLK_GPIO3		323
+#define PCLK_GPIO4		324
+#define PCLK_PMUGRF		325
+#define PCLK_MAILBOX		326
+#define PCLK_GRF		329
+#define PCLK_SGRF		330
+#define PCLK_PMU		331
+#define PCLK_I2C0		332
+#define PCLK_I2C1		333
+#define PCLK_I2C2		334
+#define PCLK_I2C3		335
+#define PCLK_I2C4		336
+#define PCLK_I2C5		337
+#define PCLK_SPI0		338
+#define PCLK_SPI1		339
+#define PCLK_SPI2		340
+#define PCLK_SPI3		341
+#define PCLK_SPI4		342
+#define PCLK_SPI5		343
+#define PCLK_UART0		344
+#define PCLK_UART1		345
+#define PCLK_UART2		346
+#define PCLK_UART3		347
+#define PCLK_UART4		348
+#define PCLK_TSADC		349
+#define PCLK_SARADC		350
+#define PCLK_SIM		351
+#define PCLK_GMAC		352
+#define PCLK_PWM0		353
+#define PCLK_PWM1		354
+#define PCLK_TIMER0		355
+#define PCLK_TIMER1		356
+#define PCLK_EDP_CTRL		357
+#define PCLK_MIPI_DSI0		358
+#define PCLK_MIPI_CSI		359
+#define PCLK_HDCP		360
+#define PCLK_HDMI_CTRL		361
+#define PCLK_VIO_H2P		362
+#define PCLK_BUS		363
+#define PCLK_PERI		364
+#define PCLK_DDRUPCTL		365
+#define PCLK_DDRPHY		366
+#define PCLK_ISP		367
+#define PCLK_VIP		368
+#define PCLK_WDT		369
+
+/* hclk gates */
+#define HCLK_SFC		448
+#define HCLK_HOST0		450
+#define HCLK_HOST1		451
+#define HCLK_HSIC		452
+#define HCLK_NANDC0		453
+#define HCLK_TSP		455
+#define HCLK_SDMMC		456
+#define HCLK_SDIO0		457
+#define HCLK_EMMC		459
+#define HCLK_HSADC		460
+#define HCLK_CRYPTO		461
+#define HCLK_I2S0_8CH		462
+#define HCLK_I2S1_8CH		463
+#define HCLK_I2S2_8CH		464
+#define HCLK_SPDIF		465
+#define HCLK_VOPB		466
+#define HCLK_VOPL		467
+#define HCLK_ROM		468
+#define HCLK_IEP		469
+#define HCLK_ISP		470
+#define HCLK_RGA		471
+#define HCLK_VIO_AHB_ARBI	472
+#define HCLK_VIO_NOC		473
+#define HCLK_VIP		474
+#define HCLK_VIO_H2P		475
+#define HCLK_VIO_HDCPMMU	476
+#define HCLK_VIDEO		477
+#define HCLK_BUS		478
+#define HCLK_PERI		479
+
+/* pmu-clocks indices */
+#define SCLK_CM0S		500
+#define SCLK_SPI5		501
+#define SCLK_TIMER12		502
+#define SCLK_TIMER13		503
+#define SCLK_UART		504
+
+#define CLK_NR_CLKS		(SCLK_UART + 1)
+
+/* soft-reset indices */
+
+/* cru_softrst_con0 */
+#define SRST_CORE_L0			0
+#define SRST_CORE_B0			1
+#define SRST_CORE_PO_L0			2
+#define SRST_CORE_PO_B0			3
+#define SRST_L2_L			4
+#define SRST_L2_B			5
+#define SRST_ADB_L			6
+#define SRST_ADB_B			7
+#define SRST_A_CCI			8
+#define SRST_A_CCIM0_NIU		9
+#define SRST_A_CCIM1_NIU		10
+#define SRST_DBG_NIU			11
+
+/* cru_softrst_con1 */
+#define SRST_CORE_L0_T			16
+#define SRST_CORE_L1			17
+#define SRST_CORE_L2			18
+#define SRST_CORE_L3			19
+#define SRST_CORE_PO_L0_T		20
+#define SRST_CORE_PO_L1			21
+#define SRST_CORE_PO_L2			22
+#define SRST_CORE_PO_L3			23
+#define SRST_A_ADB400_GIC2_CORE_L	24
+#define SRST_A_ADB400_CORE_L_GIC2	25
+#define SRST_P_DBG_L			26
+#define SRST_SOC_DBG_L			27
+#define SRST_L2_L_T			28
+#define SRST_ADB_L_T			29
+#define SRST_A_RKREF_L			30
+#define SRST_PVTM_CORE_L		31
+
+/* cru_softrst_con2 */
+#define SRST_CORE_B0_T			32
+#define SRST_CORE_B1			33
+#define SRST_CORE_PO_B0_T		36
+#define SRST_CORE_PO_B1			37
+#define SRST_A_ADB400_GIC2_CORE_B	40
+#define SRST_A_ADB400_CORE_B_GIC2	41
+#define SRST_P_DBG_B			42
+#define SRST_L2_B_T			43
+#define SRST_SOC_DBG_B			44
+#define SRST_ADB_B_T			45
+#define SRST_A_RKREF_B			46
+#define SRST_PVTM_CORE_B		47
+
+/* cru_softrst_con3 */
+#define SRST_A_CCI_T			50
+#define SRST_A_CCIM0_NIU_T		51
+#define SRST_A_CCIM1_NIU_T		52
+#define SRST_A_ADB400M_PD_CORE_B_T	53
+#define SRST_A_ADB400M_PD_CORE_L_T	54
+#define SRST_DBG_NIU_T			55
+#define SRST_DBG_CXCS			56
+#define SRST_CCI_TRACE			57
+#define SRST_P_CCI_GRF			58
+
+/* cru_softrst_con4 */
+#define SRST_A_CENTER_MAIN_NIU		64
+#define SRST_A_CENTER_PERI_NIU		65
+#define SRST_P_CENTER_MAIN		66
+#define SRST_P_DDRMAON			67
+#define SRST_P_CIC			68
+#define SRST_P_CENTER_SGRF		69
+#define SRST_DDR0_MSCH			70
+#define SRST_DDRCFG0_MSCH		71
+#define SRST_DDR0			72
+#define SRST_DDRPHY0			73
+#define SRST_DDR1_MSCH			74
+#define SRST_DDRCFG1_MSCH		75
+#define SRST_DDR1			76
+#define SRST_DDRPHY1			77
+#define SRST_DDR_CIC			78
+#define SRST_PVTM_DDR			79
+
+/* cru_softrst_con5 */
+#define SRST_A_VCODEC_NIU		80
+#define SRST_A_VCODEC			81
+#define SRST_H_VCODEC_NIU		82
+#define SRST_H_VCODEC			83
+#define SRST_A_VDU_NIU			88
+#define SRST_A_VDU 			89
+#define SRST_H_VDU_NIU			90
+#define SRST_H_VDU			91
+#define SRST_VDU_CORE			92
+#define SRST_VDU_CA			93
+
+/* cru_softrst_con6 */
+#define SRST_A_IEP_NIU			96
+#define SRST_A_VOP_IEP			97
+#define SRST_A_IEP			98
+#define SRST_H_IEP_NIU			99
+#define SRST_H_IEP			100
+#define SRST_A_RGA_NIU			102
+#define SRST_A_RGA			103
+#define SRST_H_RGA_NIU			104
+#define SRST_H_RGA			105
+#define SRST_RGA_CORE			106
+#define SRST_EMMC_NIU			108
+#define SRST_EMMC			109
+#define SRST_EMMC_GRF			110
+#define SRST_EMMCPHY_SYSRX		111
+
+/* cru_softrst_con7 */
+#define SRST_A_PERIHP_NIU		112
+#define SRST_A_PERIHP_GRF		113
+#define SRST_H_PERIHP_NIU		114
+#define SRST_USBHOST0 			115
+#define SRST_HOSTC0_AUX			116
+#define SRST_HOSTC0_ARB			117
+#define SRST_USBHOST1			118
+#define SRST_HOSTC1_AUX			119
+#define SRST_HOSTC1_ARB			120
+#define SRST_SDIO0			121
+#define SRST_SDMMC			122
+#define SRST_HSIC			123
+#define SRST_HSIC_AUX			124
+#define SRST_AHB1TOM			125
+#define SRST_P_PERIHP_NIU		126
+#define SRST_HSICPHY			127
+
+/* cru_softrst_con8 */
+#define SRST_A_PCIE			128
+#define SRST_P_PCIE			129
+#define SRST_PCIE_CORE			130
+#define SRST_PCIE_MGMT			131
+#define SRST_PCIE_MGMT_STICKY		132
+#define SRST_PCIE_PIPE			133
+#define SRST_PCIE_PM			134
+#define SRST_PCIEPHY			135
+#define SRST_A_GMAC_NIU			136
+#define SRST_A_GMAC 			137
+#define SRST_P_GMAC_NIU			138
+#define SRST_P_GMAC			139
+#define SRST_P_GMAC_GRF			140
+#define SRST_HSICPHY_POR		142
+#define SRST_HSICPHY_UTMI		143
+
+/* cru_softrst_con9 */
+#define SRST_USB2PHY0_POR		144
+#define SRST_USB2PHY0_UTMI_PORT0	145
+#define SRST_USB2PHY0_UTMI_PORT1	146
+#define SRST_USB2PHY0_EHCIPHY		147
+#define SRST_UPHY0_PIPE_L00		148
+#define SRST_UPHY0			149
+#define SRST_UPHY0_TCPDPWRUP		150
+#define SRST_USB2PHY1_POR		152
+#define SRST_USB2PHY1_UTMI_PORT0	153
+#define SRST_USB2PHY1_UTMI_PORT1	154
+#define SRST_USB2PHY1_EHCIPHY		155
+#define SRST_UPHY1_PIPE_L00		156
+#define SRST_UPHY1			157
+#define SRST_UPHY1_TCPDPWRUP		158
+
+/* cru_softrst_con10 */
+#define SRST_A_PERILP0_NIU		160
+#define SRST_A_DCF			161
+#define SRST_GIC500			162
+#define SRST_DMAC0_PERILP0		163
+#define SRST_DMAC1_PERILP0		164
+#define SRST_TZMA			165
+#define SRST_INTMEM			166
+#define SRST_ADB400_MST0		167
+#define SRST_ADB400_MST1		168
+#define SRST_ADB400_SLV0		169
+#define SRST_ADB400_SLV1		170
+#define SRST_H_PERILP0			171
+#define SRST_H_PERILP0_NIU		172
+#define SRST_ROM			173
+#define SRST_CRYPTO_S			174
+#define SRST_CRYPTO_M			175
+
+/* cru_softrst_con11 */
+#define SRST_P_DCF			176
+#define SRST_CM0S_NIU			177
+#define SRST_CM0S			178
+#define SRST_CM0S_DBG			179
+#define SRST_CM0S_PO			180
+#define SRST_CRYPTO			181
+#define SRST_P_PERILP1_SGRF		182
+#define SRST_P_PERILP1_GRF		183
+#define SRST_CRYPTO1_S			184
+#define SRST_CRYPTO1_M			185
+#define SRST_CRYPTO1			186
+#define SRST_GIC_NIU			188
+#define SRST_SD_NIU			189
+#define SRST_SDIOAUDIO_BRG		190
+
+/* cru_softrst_con12 */
+#define SRST_H_PERILP1			192
+#define SRST_H_PERILP1_NIU		193
+#define SRST_H_I2S0_8CH			194
+#define SRST_H_I2S1_8CH			195
+#define SRST_H_I2S2_8CH			196
+#define SRST_H_SPDIF_8CH		197
+#define SRST_P_PERILP1_NIU		198
+#define SRST_P_EFUSE_1024		199
+#define SRST_P_EFUSE_1024S		200
+#define SRST_P_I2C0			201
+#define SRST_P_I2C1			202
+#define SRST_P_I2C2			203
+#define SRST_P_I2C3			204
+#define SRST_P_I2C4			205
+#define SRST_P_I2C5			206
+#define SRST_P_MAILBOX0			207
+
+/* cru_softrst_con13 */
+#define SRST_P_UART0			208
+#define SRST_P_UART1			209
+#define SRST_P_UART2			210
+#define SRST_P_UART3			211
+#define SRST_P_SARADC			212
+#define SRST_P_TSADC			213
+#define SRST_P_SPI0			214
+#define SRST_P_SPI1			215
+#define SRST_P_SPI2			216
+#define SRST_P_SPI3			217
+#define SRST_P_SPI4			218
+#define SRST_SPI0			219
+#define SRST_SPI1			220
+#define SRST_SPI2			221
+#define SRST_SPI3			222
+#define SRST_SPI4			223
+
+/* cru_softrst_con14 */
+#define SRST_I2S0_8CH			224
+#define SRST_I2S1_8CH			225
+#define SRST_I2S2_8CH			226
+#define SRST_SPDIF_8CH			227
+#define SRST_UART0			228
+#define SRST_UART1			229
+#define SRST_UART2			230
+#define SRST_UART3			231
+#define SRST_TSADC			232
+#define SRST_I2C0			233
+#define SRST_I2C1			234
+#define SRST_I2C2			235
+#define SRST_I2C3			236
+#define SRST_I2C4			237
+#define SRST_I2C5			238
+#define SRST_SDIOAUDIO_NIU		239
+
+/* cru_softrst_con15 */
+#define SRST_A_VIO_NIU			240
+#define SRST_A_HDCP_NIU			241
+#define SRST_A_HDCP			242
+#define SRST_H_HDCP_NIU			243
+#define SRST_H_HDCP			244
+#define SRST_P_HDCP_NIU			245
+#define SRST_P_HDCP			246
+#define SRST_P_HDMI_CTRL		247
+#define SRST_P_DP_CTRL			248
+#define SRST_S_DP_CTRL			249
+#define SRST_C_DP_CTRL			250
+#define SRST_P_MIPI_DSI0		251
+#define SRST_P_MIPI_DSI1		252
+#define SRST_DP_CORE			253
+#define SRST_DP_I2S			254
+#define SRST_DP_VIF			255
+
+/* cru_softrst_con16 */
+#define SRST_GASKET			256
+#define SRST_VIO_SGRF			257
+#define SRST_VIO_GRF			258
+#define SRST_DPTX_SPDIF_REC		259
+#define SRST_HDMI_CTRL			260
+#define SRST_HDCP_CTRL			261
+#define SRST_A_ISP0_NIU			262
+#define SRST_A_ISP1_NIU			263
+#define SRST_A_ISP0			264
+#define SRST_A_ISP1			265
+#define SRST_H_ISP0_NIU			266
+#define SRST_H_ISP1_NIU			267
+#define SRST_H_ISP0			268
+#define SRST_H_ISP1			269
+#define SRST_ISP0			270
+#define SRST_ISP1			271
+
+/* cru_softrst_con17 */
+#define SRST_A_VOP0_NIU			272
+#define SRST_A_VOP1_NIU			273
+#define SRST_A_VOP0			274
+#define SRST_A_VOP1			275
+#define SRST_H_VOP0_NIU			276
+#define SRST_H_VOP1_NIU			277
+#define SRST_H_VOP0			278
+#define SRST_H_VOP1			279
+#define SRST_D_VOP0			280
+#define SRST_D_VOP1			281
+#define SRST_VOP0_PWM			282
+#define SRST_VOP1_PWM			283
+#define SRST_P_EDP_NIU			284
+#define SRST_P_EDP_CTRL			285
+
+/* cru_softrst_con18 */
+#define SRST_A_GPU			288
+#define SRST_A_GPU_NIU			289
+#define SRST_A_GPU_GRF			290
+#define SRST_PVTM_GPU			291
+#define SRST_A_USB3_NIU			292
+#define SRST_A_USB3_OTG0		293
+#define SRST_A_USB3_OTG1		294
+#define SRST_A_USB3_GRF			295
+#define SRST_PMU			296
+#define SRST_PVTM_PMU			297
+
+/* cru_softrst_con19 */
+#define SRST_P_TIMER0_5			304
+#define SRST_TIMER0			305
+#define SRST_TIMER1			306
+#define SRST_TIMER2			307
+#define SRST_TIMER3			308
+#define SRST_TIMER4			309
+#define SRST_TIME5			310
+#define SRST_P_TIMER6_11		311
+#define SRST_TIMER6			312
+#define SRST_TIMER7			313
+#define SRST_TIMER8			314
+#define SRST_TIMER9			315
+#define SRST_TIMER10			316
+#define SRST_TIMER11			317
+#define SRST_P_INTR_ARB_PMU		318
+#define SRST_P_ALIVE_SGRF		319
+
+/* cru_softrst_con20 */
+#define SRST_P_GPIO2			320
+#define SRST_P_GPIO3			321
+#define SRST_P_GPIO4			322
+#define SRST_P_GRF			323
+#define SRST_P_ALIVE_NIU		324
+#define SRST_P_WDT0			325
+#define SRST_P_WDT1			326
+#define SRST_P_INTR_ARB 		327
+#define SRST_P_UPHY0_DPTX		328
+#define SRST_P_UPHY1_DPTX		329
+#define SRST_P_UPHY0_APB		330
+#define SRST_P_UPHY1_APB		331
+#define SRST_P_UPHY0_TCPHY		332
+#define SRST_P_UPHY1_TCPHY		333
+#define SRST_P_UPHY0_TCPDCTRL		334
+#define SRST_P_UPHY1_TCPDCTRL		335
+
+/* pmu soft-reset indices */
+
+/* pmu_cru_softrst_con0 */
+#define SRST_P_NIU			0
+#define SRST_P_INTMEN			1
+#define SRST_H_CM0S			2
+#define SRST_H_CM0S_NIU			3
+#define SRST_DBG_CM0S			4
+#define SRST_PO_CM0S			5
+#define SRST_P_SPI6			6
+#define SRST_SPI6			7
+#define SRST_P_TIMER_0_1		8
+#define SRST_P_TIMER_0			9
+#define SRST_P_TIMER_1			10
+#define SRST_P_UART4			11
+#define SRST_UART4			12
+#define SRST_P_WDT			13
+
+/* pmu_cru_softrst_con1 */
+#define SRST_P_I2C6			16
+#define SRST_P_I2C7			17
+#define SRST_P_I2C8			18
+#define SRST_P_MAILBOX			19
+#define SRST_P_RKPWM			20
+#define SRST_P_PMUGRF			21
+#define SRST_P_SGRF			22
+#define SRST_P_GPIO0			23
+#define SRST_P_GPIO1			24
+#define SRST_P_CRU			25
+#define SRST_P_INTR			26
+#define SRST_PVTM 			27
+#define SRST_I2C6			28
+#define SRST_I2C7			29
+#define SRST_I2C8			30
+
+#endif
-- 
1.9.1




From Mingkai.Hu at freescale.com  Tue Feb 16 18:04:23 2016
From: Mingkai.Hu at freescale.com (Mingkai Hu)
Date: Wed, 17 Feb 2016 10:04:23 +0800
Subject: [PATCH v3] dts/ls2080a: Update PCIe compatible
Message-ID: <1455674663-9273-1-git-send-email-Mingkai.Hu@freescale.com>

From: Minghuan Lian <minghuan.lian at nxp.com>

The patch adds LS2085a to PCIe compatible to fix the compatibility
issue when using firmware with LS2085a compatible property.

Signed-off-by: Minghuan Lian <minghuan.lian at nxp.com>
Signed-off-by: Mingkai Hu <mingkai.hu at nxp.com>
---
v3:
 - Make the compatible consistent between layerscape-pci.txt
   and dts file.

v2:
  - Rebased to latest kernel base

 Documentation/devicetree/bindings/pci/layerscape-pci.txt |  2 +-
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi           | 12 ++++++++----
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index e376785..ef683b2 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -14,7 +14,7 @@ information.
 Required properties:
 - compatible: should contain the platform identifier such as:
         "fsl,ls1021a-pcie", "snps,dw-pcie"
-        "fsl,ls2080a-pcie", "snps,dw-pcie"
+        "fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie"
 - reg: base addresses and lengths of the PCIe controller
 - interrupts: A list of interrupt outputs of the controller. Must contain an
   entry for each entry in the interrupt-names property.
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 2b23d03..1b18d7a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -456,7 +456,8 @@
 		};
 
 		pcie at 3400000 {
-			compatible = "fsl,ls2080a-pcie", "snps,dw-pcie";
+			compatible = "fsl,ls2080a-pcie", "fsl,ls2085a-pcie",
+				     "snps,dw-pcie";
 			reg = <0x00 0x03400000 0x0 0x00100000   /* controller registers */
 			       0x10 0x00000000 0x0 0x00002000>; /* configuration space */
 			reg-names = "regs", "config";
@@ -479,7 +480,8 @@
 		};
 
 		pcie at 3500000 {
-			compatible = "fsl,ls2080a-pcie", "snps,dw-pcie";
+			compatible = "fsl,ls2080a-pcie", "fsl,ls2085a-pcie",
+				     "snps,dw-pcie";
 			reg = <0x00 0x03500000 0x0 0x00100000   /* controller registers */
 			       0x12 0x00000000 0x0 0x00002000>; /* configuration space */
 			reg-names = "regs", "config";
@@ -502,7 +504,8 @@
 		};
 
 		pcie at 3600000 {
-			compatible = "fsl,ls2080a-pcie", "snps,dw-pcie";
+			compatible = "fsl,ls2080a-pcie", "fsl,ls2085a-pcie",
+				     "snps,dw-pcie";
 			reg = <0x00 0x03600000 0x0 0x00100000   /* controller registers */
 			       0x14 0x00000000 0x0 0x00002000>; /* configuration space */
 			reg-names = "regs", "config";
@@ -525,7 +528,8 @@
 		};
 
 		pcie at 3700000 {
-			compatible = "fsl,ls2080a-pcie", "snps,dw-pcie";
+			compatible = "fsl,ls2080a-pcie", "fsl,ls2085a-pcie",
+				     "snps,dw-pcie";
 			reg = <0x00 0x03700000 0x0 0x00100000   /* controller registers */
 			       0x16 0x00000000 0x0 0x00002000>; /* configuration space */
 			reg-names = "regs", "config";
-- 
2.1.0.27.g96db324



From k.kozlowski at samsung.com  Tue Feb 16 18:13:25 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 17 Feb 2016 11:13:25 +0900
Subject: [PATCH v2] ARM: dts: Move syscon reboot/poweroff to common dtsi
 for Exynos
In-Reply-To: <1455636348-14277-1-git-send-email-javier@osg.samsung.com>
References: <1455636348-14277-1-git-send-email-javier@osg.samsung.com>
Message-ID: <56C3D745.7050904@samsung.com>

On 17.02.2016 00:25, Javier Martinez Canillas wrote:
> All Exynos SoCs have the same syscon reboot and poweroff device nodes so
> there is no need to duplicate the same on each SoC dtsi and can be moved
> to a common dtsi that can be included by all the SoCs dtsi files.
> 
> Suggested-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
> Reviewed-by: Alim Akhtar <alim.akhtar at samsung,com>
> 
> ---
> Hello,
> 
> The patch was tested on an Exynos5800 Peach Pi Chromebook and an
> Exynos5422 Odroid XU4 board. Reboot and poweroff worked for both.
> 
> But testing on Exynos3 and Exynos4 will be highly appreciated.
> 
> Best regards,
> Javier
> 
> Changes in v2:
> - Added Krzysztof Kozlowski's Suggested-by tag.
> - Added Alim Akhtar's Reviewed-by tag.
> - Moved the poweroff and reboot nodes under a soc node (Krzysztof Kozlowski).
> - Include the dtsi after skeleton dtsi in exynos4.dtsi ((Krzysztof Kozlowski).
> 
>  arch/arm/boot/dts/exynos-syscon-restart.dtsi | 27 +++++++++++++++++++++++++++
>  arch/arm/boot/dts/exynos3250.dtsi            | 15 +--------------
>  arch/arm/boot/dts/exynos4.dtsi               | 15 +--------------
>  arch/arm/boot/dts/exynos5.dtsi               | 15 +--------------
>  arch/arm/boot/dts/exynos5410.dtsi            | 15 +--------------
>  5 files changed, 31 insertions(+), 56 deletions(-)
>  create mode 100644 arch/arm/boot/dts/exynos-syscon-restart.dtsi
> 
> diff --git a/arch/arm/boot/dts/exynos-syscon-restart.dtsi b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
> new file mode 100644
> index 000000000000..09a2040054ed
> --- /dev/null
> +++ b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
> @@ -0,0 +1,27 @@
> +/*
> + * Samsung's Exynos SoC syscon reboot/poweroff nodes common definition.
> + *
> + * 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.
> + */
> +
> +/ {
> +	soc {
> +		compatible = "simple-bus";

The exynos4 does not have soc node. I wonder whether we should provide
here also address and size:
                #address-cells = <1>;
                #size-cells = <1>;
		ranges;

Without this it works fine but that does not look correct enough.

A minor effect of this patch on Exynos4 is that syscon-poweroff/reboot
are now the only children of "soc" simple-bus (rest of platform devices
is not)... but this is not a problem.

Works fine so only the question about cells/ranges remains. Any comments?

Best regards,
Krzysztof


> +
> +		poweroff: syscon-poweroff {
> +			compatible = "syscon-poweroff";
> +			regmap = <&pmu_system_controller>;
> +			offset = <0x330C>; /* PS_HOLD_CONTROL */
> +			mask = <0x5200>; /* reset value */
> +		};
> +
> +		reboot: syscon-reboot {
> +			compatible = "syscon-reboot";
> +			regmap = <&pmu_system_controller>;
> +			offset = <0x0400>; /* SWRESET */
> +			mask = <0x1>;
> +		};
> +	};
> +};
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
> index 18e3deffbf48..d9c221517935 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -19,6 +19,7 @@
>  
>  #include "skeleton.dtsi"
>  #include "exynos4-cpu-thermal.dtsi"
> +#include "exynos-syscon-restart.dtsi"
>  #include <dt-bindings/clock/exynos3250.h>
>  
>  / {
> @@ -152,20 +153,6 @@
>  			interrupt-parent = <&gic>;
>  		};
>  
> -		poweroff: syscon-poweroff {
> -			compatible = "syscon-poweroff";
> -			regmap = <&pmu_system_controller>;
> -			offset = <0x330C>; /* PS_HOLD_CONTROL */
> -			mask = <0x5200>; /* Reset value */
> -		};
> -
> -		reboot: syscon-reboot {
> -			compatible = "syscon-reboot";
> -			regmap = <&pmu_system_controller>;
> -			offset = <0x0400>; /* SWRESET */
> -			mask = <0x1>;
> -		};
> -
>  		mipi_phy: video-phy at 10020710 {
>  			compatible = "samsung,s5pv210-mipi-video-phy";
>  			#phy-cells = <1>;
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index ca621a92319e..5456094d2f45 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -22,6 +22,7 @@
>  #include <dt-bindings/clock/exynos4.h>
>  #include <dt-bindings/clock/exynos-audss-clk.h>
>  #include "skeleton.dtsi"
> +#include "exynos-syscon-restart.dtsi"
>  
>  / {
>  	interrupt-parent = <&gic>;
> @@ -163,20 +164,6 @@
>  		interrupt-parent = <&gic>;
>  	};
>  
> -	poweroff: syscon-poweroff {
> -		compatible = "syscon-poweroff";
> -		regmap = <&pmu_system_controller>;
> -		offset = <0x330C>; /* PS_HOLD_CONTROL */
> -		mask = <0x5200>; /* reset value */
> -	};
> -
> -	reboot: syscon-reboot {
> -		compatible = "syscon-reboot";
> -		regmap = <&pmu_system_controller>;
> -		offset = <0x0400>; /* SWRESET */
> -		mask = <0x1>;
> -	};
> -
>  	dsi_0: dsi at 11C80000 {
>  		compatible = "samsung,exynos4210-mipi-dsi";
>  		reg = <0x11C80000 0x10000>;
> diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
> index b61d1f637510..92313cac035e 100644
> --- a/arch/arm/boot/dts/exynos5.dtsi
> +++ b/arch/arm/boot/dts/exynos5.dtsi
> @@ -14,6 +14,7 @@
>   */
>  
>  #include "skeleton.dtsi"
> +#include "exynos-syscon-restart.dtsi"
>  
>  / {
>  	interrupt-parent = <&gic>;
> @@ -93,20 +94,6 @@
>  		status = "disabled";
>  	};
>  
> -	poweroff: syscon-poweroff {
> -		compatible = "syscon-poweroff";
> -		regmap = <&pmu_system_controller>;
> -		offset = <0x330C>; /* PS_HOLD_CONTROL */
> -		mask = <0x5200>; /* reset value */
> -	};
> -
> -	reboot: syscon-reboot {
> -		compatible = "syscon-reboot";
> -		regmap = <&pmu_system_controller>;
> -		offset = <0x0400>; /* SWRESET */
> -		mask = <0x1>;
> -	};
> -
>  	fimd: fimd at 14400000 {
>  		compatible = "samsung,exynos5250-fimd";
>  		interrupt-parent = <&combiner>;
> diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
> index f3490f567344..fa558674ac76 100644
> --- a/arch/arm/boot/dts/exynos5410.dtsi
> +++ b/arch/arm/boot/dts/exynos5410.dtsi
> @@ -14,6 +14,7 @@
>   */
>  
>  #include "skeleton.dtsi"
> +#include "exynos-syscon-restart.dtsi"
>  #include <dt-bindings/clock/exynos5410.h>
>  
>  / {
> @@ -117,20 +118,6 @@
>  			reg = <0x10040000 0x5000>;
>  		};
>  
> -		poweroff: syscon-poweroff {
> -			compatible = "syscon-poweroff";
> -			regmap = <&pmu_system_controller>;
> -			offset = <0x330C>; /* PS_HOLD_CONTROL */
> -			mask = <0x5200>; /* reset value */
> -		};
> -
> -		reboot: syscon-reboot {
> -			compatible = "syscon-reboot";
> -			regmap = <&pmu_system_controller>;
> -			offset = <0x0400>; /* SWRESET */
> -			mask = <0x1>;
> -		};
> -
>  		mct: mct at 101C0000 {
>  			compatible = "samsung,exynos4210-mct";
>  			reg = <0x101C0000 0xB00>;
> 



From mingkai.hu at nxp.com  Tue Feb 16 18:17:47 2016
From: mingkai.hu at nxp.com (Mingkai Hu)
Date: Wed, 17 Feb 2016 02:17:47 +0000
Subject: [PATCH] PCI: layerscape: add ls2085a compatible
In-Reply-To: <20160205222525.GA16238@localhost>
References: <1453915925-19198-1-git-send-email-yang.shi@linaro.org>
 <20160205203858.GA11780@localhost> <56B509E5.2050602@linaro.org>
 <20160205222525.GA16238@localhost>
Message-ID: <VI1PR04MB1454676391D9A2D83E7625F48EAE0@VI1PR04MB1454.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas at kernel.org]
> Sent: Saturday, February 06, 2016 6:25 AM
> To: Shi, Yang
> Cc: Mingkai.Hu at freescale.com; Minghuan.Lian at freescale.com;
> bhelgaas at google.com; linux-pci at vger.kernel.org; linux-
> kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linaro-
> kernel at lists.linaro.org; Rob Herring; Pawel Moll; Mark Rutland; Ian
> Campbell; Kumar Gala; devicetree at vger.kernel.org
> Subject: Re: [PATCH] PCI: layerscape: add ls2085a compatible
> 
> On Fri, Feb 05, 2016 at 12:45:25PM -0800, Shi, Yang wrote:
> > On 2/5/2016 12:38 PM, Bjorn Helgaas wrote:
> > >[+cc Rob, et al]
> > >
> > >On Wed, Jan 27, 2016 at 09:32:05AM -0800, Yang Shi wrote:
> > >>The layerscape PCI host driver needs recognize ls2085a compatible
> > >>when using firmware with ls2085a compatible property, otherwise the
> > >>PCI bus won't be detected even though ls2085a compatible is included
> by the dts.
> > >>
> > >>Signed-off-by: Yang Shi <yang.shi at linaro.org>
> > >>---
> > >>  drivers/pci/host/pci-layerscape.c | 1 +
> > >>  1 file changed, 1 insertion(+)
> > >>
> > >>diff --git a/drivers/pci/host/pci-layerscape.c
> > >>b/drivers/pci/host/pci-layerscape.c
> > >>index 3923bed..c40d8b2 100644
> > >>--- a/drivers/pci/host/pci-layerscape.c
> > >>+++ b/drivers/pci/host/pci-layerscape.c
> > >>@@ -203,6 +203,7 @@ static const struct of_device_id
> ls_pcie_of_match[] = {
> > >>  	{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
> > >>  	{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
> > >>  	{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
> > >>+	{ .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },
> > >
> > >Hmm, "fsl,ls2085a-pcie" doesn't appear in
> > >Documentation/devicetree/bindings/pci/.
> > >
> > >Aren't we supposed to add these strings to the bindings before or at
> > >the same time we add them to drivers?
> >
> > The below patch will add it into dts and binding doc. I should
> > mentioned this in the commit log.
> >
> > https://patchwork.kernel.org/patch/7767061/
> 
> OK.  This is really annoying as a reviewer.  To me, adding "fsl,ls2085a-
> pcie" to:
> 
>   - the binding in Documentation/devicetree/bindings/pci/layerscape-
> pci.txt
>   - the DT in arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
>   - the driver in drivers/pci/host/pci-layerscape.c
> 
> are all logically related, and it would make sense to have them all in a
> single patch.
> 
> But whatever.  I applied this to pci/host-layerscape for v4.6.
> 

Bojon,

I have sent version3 of the patch to add strings to the bindings and dts file.
https://patchwork.kernel.org/patch/8333761/

Sorry for the delayed response due to Chinese New Year holiday.

Thanks,
Mingkai




From yu.c.chen at intel.com  Tue Feb 16 18:20:22 2016
From: yu.c.chen at intel.com (Chen, Yu C)
Date: Wed, 17 Feb 2016 02:20:22 +0000
Subject: [PATCH v5 15/15] arm64: hibernate: Prevent resume from a
 different kernel version
In-Reply-To: <20160216201557.GA6526@amd>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
 <1455637767-31561-16-git-send-email-james.morse@arm.com>
 <20160216201557.GA6526@amd>
Message-ID: <36DF59CE26D8EE47B0655C516E9CE640286C4F3C@shsmsx102.ccr.corp.intel.com>

> -----Original Message-----
> From: linux-pm-owner at vger.kernel.org [mailto:linux-pm-
> owner at vger.kernel.org] On Behalf Of Pavel Machek
> Sent: Wednesday, February 17, 2016 4:16 AM
> To: James Morse
> Cc: linux-arm-kernel at lists.infradead.org; Will Deacon; Sudeep Holla; Geoff
> Levand; Catalin Marinas; Lorenzo Pieralisi; Mark Rutland; AKASHI Takahiro;
> Marc Zyngier; Rafael J . Wysocki; linux-pm at vger.kernel.org
> Subject: Re: [PATCH v5 15/15] arm64: hibernate: Prevent resume from a
> different kernel version
> 
> On Tue 2016-02-16 15:49:27, James Morse wrote:
> > Resuming using a different kernel version is fragile, while there are
> > sufficient details in the hibernate arch-header to perform the
> > restore, changes in the boot process can have a long-lasting impact on the
> system.
> > In particular, if the EFI stub causes more memory to be allocated, the
> > amount of memory left for linux is reduced. If we are lucky, this will
> > cause restore to fail with the message:
> 
> Well, this does not close the door completely. 4.6-rc0 is going to be very
> different from 4.6-rc1. Better solution would be to increase version every
> time EFI stub changes, or maybe record ammount of memory reserved for
> EFI.
This reminds me a similar problem I once encountered on x86 : - )
The efi memory layout should be strictly the same before/after hibernation, right?



From javier at osg.samsung.com  Tue Feb 16 18:23:24 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Tue, 16 Feb 2016 23:23:24 -0300
Subject: [PATCH v2] ARM: dts: Move syscon reboot/poweroff to common dtsi
 for Exynos
In-Reply-To: <56C3D745.7050904@samsung.com>
References: <1455636348-14277-1-git-send-email-javier@osg.samsung.com>
 <56C3D745.7050904@samsung.com>
Message-ID: <56C3D99C.3090403@osg.samsung.com>

Hello Krzysztof,

On 02/16/2016 11:13 PM, Krzysztof Kozlowski wrote:

[snip]

>> diff --git a/arch/arm/boot/dts/exynos-syscon-restart.dtsi b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
>> new file mode 100644
>> index 000000000000..09a2040054ed
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
>> @@ -0,0 +1,27 @@
>> +/*
>> + * Samsung's Exynos SoC syscon reboot/poweroff nodes common definition.
>> + *
>> + * 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.
>> + */
>> +
>> +/ {
>> +	soc {
>> +		compatible = "simple-bus";
>
> The exynos4 does not have soc node. I wonder whether we should provide
> here also address and size:
>                  #address-cells = <1>;
>                  #size-cells = <1>;
> 		ranges;
>
> Without this it works fine but that does not look correct enough.
>
> A minor effect of this patch on Exynos4 is that syscon-poweroff/reboot
> are now the only children of "soc" simple-bus (rest of platform devices
> is not)... but this is not a problem.
>
> Works fine so only the question about cells/ranges remains. Any comments?
>

I in fact had the #address-cells and #size-cells at the beginning but then
realized that both the syscon-poweroff and syscon-reboot nodes didn't have
a reg property so it felt strange to me to have those.

Also, I thought that maybe a SoC dtsi may need a different #address-cells
and #size-cells for the other child nodes so having those in this dtsi
could override the values in the SoC dtsi depending where is included.

So I thought it could do more harm than good but I've no strong opinion
and can add those if you prefer.

> Best regards,
> Krzysztof
>
>

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America


From jszhang at marvell.com  Tue Feb 16 18:21:24 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Wed, 17 Feb 2016 10:21:24 +0800
Subject: [PATCH 5/5] arm64: marvell: add Device Tree files for Armada 7K/8K
In-Reply-To: <20160216173840.7f93896f@free-electrons.com>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455526065-7307-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160216134219.00045b5b@xhacker>
 <20160216173840.7f93896f@free-electrons.com>
Message-ID: <20160217102124.7353591f@xhacker>

Dear Thomas,

On Tue, 16 Feb 2016 17:38:40 +0100 Thomas Petazzoni wrote:

> Hello,
> 
> On Tue, 16 Feb 2016 13:42:19 +0800, Jisheng Zhang wrote:
> 
> > > +/ {
> > > +	model = "Marvell Armada AP806";
> > > +	compatible = "marvell,armada-ap806";
> > > +	#address-cells = <2>;
> > > +	#size-cells = <2>;
> > > +
> > > +	psci {
> > > +		compatible = "arm,psci-0.2";  
> > 
> > I guess the firmware is also psci-1.0 compatible.  
> 
> At boot time, the kernel queries the PSCI firmware, and it says:
> 
> [    0.000000] psci: probing for conduit method from DT.
> [    0.000000] psci: PSCIv0.2 detected in firmware.
> [    0.000000] psci: Using standard PSCI v0.2 function IDs
> 
> So I think psci-0.2 is correct here. Should this change for the
> production revision of the chip, we'll send an update to the Device
> Tree accordingly.

Thanks for the information.

> 
> > > +	ap806 {
> > > +		#address-cells = <2>;
> > > +		#size-cells = <2>;
> > > +		compatible = "simple-bus";
> > > +		interrupt-parent = <&gic>;
> > > +		ranges;
> > > +
> > > +		config-space {
> > > +			#address-cells = <1>;
> > > +			#size-cells = <1>;
> > > +			compatible = "simple-bus";
> > > +			ranges = <0x0 0x0 0xf0000000 0x1000000>;
> > > +
> > > +			gic: interrupt-controller at 210000 {
> > > +				compatible = "arm,cortex-a15-gic",
> > > +					     "arm,cortex-a9-gic";  
> > 
> > I guess the GIC is neither the one in cortex-a15 or cortex-a9.   
> 
> What makes you think this?
> 
> The GIC is a GIC400, which is GICv2 compliant, and arm-cortex-a15-gic /

That's my point, why not "gic-400" explicitly?

Thanks,
Jisheng

> arm-cortex-a9-gic are valid compatible strings to identify a GICv2
> compliant interrupt controller.
> 
> See:
> 
> arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi:              compatible = "arm,gic-400", "arm,cortex-a15-gic";
> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi:           compatible = "arm,gic-400", "arm,cortex-a15-gic";
> arch/arm64/boot/dts/apm/apm-shadowcat.dtsi:             compatible = "arm,cortex-a15-gic";
> arch/arm64/boot/dts/apm/apm-storm.dtsi:         compatible = "arm,cortex-a15-gic";
> arch/arm64/boot/dts/arm/foundation-v8.dts:              compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
> arch/arm64/boot/dts/arm/juno-base.dtsi:         compatible = "arm,gic-400", "arm,cortex-a15-gic";
> arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts:             compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
> arch/arm64/boot/dts/marvell/armada-ap806.dtsi:                          compatible = "arm,cortex-a15-gic",
> arch/arm64/boot/dts/nvidia/tegra132.dtsi:               compatible = "arm,cortex-a15-gic";
> arch/arm64/boot/dts/xilinx/zynqmp.dtsi:                 compatible = "arm,gic-400", "arm,cortex-a15-gic";
> 
> Or do you have a more specific reason to think that this compatible
> string is wrong?
> 
> Best regards,
> 
> Thomas



From viro at ZenIV.linux.org.uk  Tue Feb 16 18:33:44 2016
From: viro at ZenIV.linux.org.uk (Al Viro)
Date: Wed, 17 Feb 2016 02:33:44 +0000
Subject: [PATCH 5/7] serial: clps711x: fix IS_ERR_VALUE usage
In-Reply-To: <1455546925-22119-6-git-send-email-a.hajda@samsung.com>
References: <1455546925-22119-1-git-send-email-a.hajda@samsung.com>
 <1455546925-22119-6-git-send-email-a.hajda@samsung.com>
Message-ID: <20160217023344.GJ17997@ZenIV.linux.org.uk>

On Mon, Feb 15, 2016 at 03:35:23PM +0100, Andrzej Hajda wrote:
> IS_ERR_VALUE macro should be used only with unsigned long type.
> For signed types comparison 'ret < 0' should be used.

ACK


From cov at codeaurora.org  Tue Feb 16 18:36:10 2016
From: cov at codeaurora.org (Christopher Covington)
Date: Tue, 16 Feb 2016 21:36:10 -0500
Subject: [PATCH v3 0/5] ACPI: parse the SPCR table
In-Reply-To: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <FD7CEA09-FFB5-4707-A4AE-7F721491C327@codeaurora.org>



On February 15, 2016 1:05:24 PM EST, Aleksey Makarov <aleksey.makarov at linaro.org> wrote:
>This patchset is based on the patchset by Leif Lindholm [1]
>
>'ARM Server Base Boot Requirements' [2] mentions SPCR (Serial Port
>Console Redirection Table) [3] as a mandatory ACPI table that
>specifies the configuration of serial console.
>
>SPCR support is included in QEMU's ARM mach-virt since 2.4 release.
>
>Introduce a new function acpi_console_check().  At the uart port
>registration, this function checks if the ACPI SPCR table specifies
>its argument of type struct uart_port to be a console
>and if so calls add_preferred_console().
>
>Use SPCR to tell if SBSA serial driver should use 32-bit access to
>registers.

On QDF2432:

Tested-by: Christopher Covington <cov at codeaurora.org>

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Sent from my Snapdragon powered Android device with K-9 Mail. Please excuse my brevity.


From lv.zheng at intel.com  Tue Feb 16 18:44:42 2016
From: lv.zheng at intel.com (Zheng, Lv)
Date: Wed, 17 Feb 2016 02:44:42 +0000
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>

Hi,

> -----Original Message-----
> From: linux-acpi-owner at vger.kernel.org [mailto:linux-acpi-
> owner at vger.kernel.org] On Behalf Of Aleksey Makarov
> Sent: Tuesday, February 16, 2016 2:05 AM
> To: linux-acpi at vger.kernel.org
> Cc: linux-serial at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; Aleksey Makarov <aleksey.makarov at linaro.org>;
> Russell King <linux at arm.linux.org.uk>; Greg Kroah-Hartman
> <gregkh at linuxfoundation.org>; Rafael J . Wysocki <rjw at rjwysocki.net>; Leif
> Lindholm <leif.lindholm at linaro.org>; Graeme Gregory
> <graeme.gregory at linaro.org>; Al Stone <ahs3 at redhat.com>; Christopher
> Covington <cov at codeaurora.org>; Len Brown <lenb at kernel.org>
> Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
> early_acpi_os_unmap_memory()
> 
> early_acpi_os_unmap_memory() is marked as __init because it calls
> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is not set.
> 
> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
> so it is safe to call early_acpi_os_unmap_memory() from anywhere
> 
> We need this function to be non-__init because we need access to
> some tables at unpredictable time--it may be before or after
> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port Console
> Redirection) table is needed each time a new console is registered.
> It can be quite early (console_initcall) or when a module is inserted.
> When this table accessed before acpi_gbl_permanent_mmap is set,
> the pointer should be unmapped.  This is exactly what this function
> does.
[Lv Zheng] 
Why don't you use another API instead of early_acpi_os_unmap_memory() in case you want to unmap things in any cases.
acpi_os_unmap_memory() should be the one to match this purpose.
It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
And in fact early_acpi_os_unmap_memory() should be removed.

Thanks and best regards
-Lv

> 
> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> ---
>  drivers/acpi/osl.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index 67da6fb..8a552cd 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void *virt,
> acpi_size size)
>  }
>  EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
> 
> -void __init early_acpi_os_unmap_memory(void __iomem *virt, acpi_size size)
> +/*
> + * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
> + * so it is safe to call early_acpi_os_unmap_memory() from anywhere
> + */
> +void __ref early_acpi_os_unmap_memory(void __iomem *virt, acpi_size size)
>  {
>  	if (!acpi_gbl_permanent_mmap)
>  		__acpi_unmap_table(virt, size);
> --
> 2.7.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From fengguang.wu at intel.com  Tue Feb 16 18:47:08 2016
From: fengguang.wu at intel.com (kbuild test robot)
Date: Wed, 17 Feb 2016 10:47:08 +0800
Subject: [clk:clk-samsung-kconfig 1/2]
 drivers/clk/samsung/clk-s3c2410.c:102:29: error: array type has incomplete
 element type 'struct clk_div_table'
Message-ID: <201602171005.yH78bWkA%fengguang.wu@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-samsung-kconfig
head:   e83cb468452c25597e868d1ed778fa73fdaeca4c
commit: 89e08b1b13374a336dfd1d500ebc70aa545579ab [1/2] clk: samsung: Enable COMPILE_TEST for Samsung clocks
config: mips-allmodconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout 89e08b1b13374a336dfd1d500ebc70aa545579ab
        # save the attached .config to linux build tree
        make.cross ARCH=mips 

All error/warnings (new ones prefixed by >>):

   In file included from drivers/clk/samsung/clk-s3c2410.c:18:0:
   drivers/clk/samsung/clk.h:29:26: error: field 'clk_data' has incomplete type
     struct clk_onecell_data clk_data;
                             ^
   drivers/clk/samsung/clk.h:142:19: error: 'CLK_SET_RATE_NO_REPARENT' undeclared here (not in a function)
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                      ^
   drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-s3c2410.c:99:2: note: in expansion of macro 'MUX'
     MUX(FCLK, "fclk", fclk_p, CLKSLOW, 4, 1),
     ^
>> drivers/clk/samsung/clk-s3c2410.c:102:29: error: array type has incomplete element type 'struct clk_div_table'
    static struct clk_div_table divslow_d[] = {
                                ^
   drivers/clk/samsung/clk-s3c2410.c:103:4: error: field name not in record or union initializer
     { .val = 0, .div = 1 },
       ^
   drivers/clk/samsung/clk-s3c2410.c:103:4: note: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:103:14: error: field name not in record or union initializer
     { .val = 0, .div = 1 },
                 ^
   drivers/clk/samsung/clk-s3c2410.c:103:14: note: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:104:4: error: field name not in record or union initializer
     { .val = 1, .div = 2 },
       ^
   drivers/clk/samsung/clk-s3c2410.c:104:4: note: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:104:14: error: field name not in record or union initializer
     { .val = 1, .div = 2 },
                 ^
   drivers/clk/samsung/clk-s3c2410.c:104:14: note: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:105:4: error: field name not in record or union initializer
     { .val = 2, .div = 4 },
       ^
   drivers/clk/samsung/clk-s3c2410.c:105:4: note: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:105:14: error: field name not in record or union initializer
     { .val = 2, .div = 4 },
                 ^
   drivers/clk/samsung/clk-s3c2410.c:105:14: note: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:106:4: error: field name not in record or union initializer
     { .val = 3, .div = 6 },
       ^
   drivers/clk/samsung/clk-s3c2410.c:106:4: note: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:106:14: error: field name not in record or union initializer
     { .val = 3, .div = 6 },
                 ^
   drivers/clk/samsung/clk-s3c2410.c:106:14: note: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:107:4: error: field name not in record or union initializer
     { .val = 4, .div = 8 },
       ^
   drivers/clk/samsung/clk-s3c2410.c:107:4: note: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:107:14: error: field name not in record or union initializer
     { .val = 4, .div = 8 },
                 ^
   drivers/clk/samsung/clk-s3c2410.c:107:14: note: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:108:4: error: field name not in record or union initializer
     { .val = 5, .div = 10 },
       ^
   drivers/clk/samsung/clk-s3c2410.c:108:4: note: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:108:14: error: field name not in record or union initializer
     { .val = 5, .div = 10 },
                 ^
   drivers/clk/samsung/clk-s3c2410.c:108:14: note: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:109:4: error: field name not in record or union initializer
     { .val = 6, .div = 12 },
       ^
   drivers/clk/samsung/clk-s3c2410.c:109:4: note: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:109:14: error: field name not in record or union initializer
     { .val = 6, .div = 12 },
                 ^
   drivers/clk/samsung/clk-s3c2410.c:109:14: note: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:110:4: error: field name not in record or union initializer
     { .val = 7, .div = 14 },
       ^
   drivers/clk/samsung/clk-s3c2410.c:110:4: note: (near initialization for 'divslow_d')
   drivers/clk/samsung/clk-s3c2410.c:110:14: error: field name not in record or union initializer
     { .val = 7, .div = 14 },
                 ^
   drivers/clk/samsung/clk-s3c2410.c:110:14: note: (near initialization for 'divslow_d')
   In file included from drivers/clk/samsung/clk-s3c2410.c:18:0:
   drivers/clk/samsung/clk-s3c2410.c:115:45: error: initializer element is not constant
     DIV_T(0, "div_slow", "xti", CLKSLOW, 0, 3, divslow_d),
                                                ^
   drivers/clk/samsung/clk.h:200:13: note: in definition of macro '__DIV'
      .table  = t,    \
                ^
>> drivers/clk/samsung/clk-s3c2410.c:115:2: note: in expansion of macro 'DIV_T'
     DIV_T(0, "div_slow", "xti", CLKSLOW, 0, 3, divslow_d),
     ^
   drivers/clk/samsung/clk-s3c2410.c:115:45: note: (near initialization for 's3c2410_common_dividers[0].table')
     DIV_T(0, "div_slow", "xti", CLKSLOW, 0, 3, divslow_d),
                                                ^
   drivers/clk/samsung/clk.h:200:13: note: in definition of macro '__DIV'
      .table  = t,    \
                ^
>> drivers/clk/samsung/clk-s3c2410.c:115:2: note: in expansion of macro 'DIV_T'
     DIV_T(0, "div_slow", "xti", CLKSLOW, 0, 3, divslow_d),
     ^
   drivers/clk/samsung/clk-s3c2410.c:125:46: error: 'CLK_IGNORE_UNUSED' undeclared here (not in a function)
     GATE(PCLK_GPIO, "gpio", "pclk", CLKCON, 13, CLK_IGNORE_UNUSED, 0),
                                                 ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-s3c2410.c:125:2: note: in expansion of macro 'GATE'
     GATE(PCLK_GPIO, "gpio", "pclk", CLKCON, 13, CLK_IGNORE_UNUSED, 0),
     ^
   drivers/clk/samsung/clk-s3c2410.c:125:46: error: initializer element is not constant
     GATE(PCLK_GPIO, "gpio", "pclk", CLKCON, 13, CLK_IGNORE_UNUSED, 0),
                                                 ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-s3c2410.c:125:2: note: in expansion of macro 'GATE'
     GATE(PCLK_GPIO, "gpio", "pclk", CLKCON, 13, CLK_IGNORE_UNUSED, 0),
     ^
   drivers/clk/samsung/clk-s3c2410.c:125:46: note: (near initialization for 's3c2410_common_gates[5].flags')
     GATE(PCLK_GPIO, "gpio", "pclk", CLKCON, 13, CLK_IGNORE_UNUSED, 0),
                                                 ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-s3c2410.c:125:2: note: in expansion of macro 'GATE'
     GATE(PCLK_GPIO, "gpio", "pclk", CLKCON, 13, CLK_IGNORE_UNUSED, 0),
     ^
   drivers/clk/samsung/clk.h:309:13: error: 'CLK_GET_RATE_NOCACHE' undeclared here (not in a function)
      .flags  = CLK_GET_RATE_NOCACHE,   \
                ^
   drivers/clk/samsung/clk.h:317:2: note: in expansion of macro '__PLL'
     __PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
     ^
   drivers/clk/samsung/clk-s3c2410.c:197:11: note: in expansion of macro 'PLL'
     [mpll] = PLL(pll_s3c2410_mpll, MPLL, "mpll", "xti",
              ^
>> drivers/clk/samsung/clk.h:309:13: error: initializer element is not constant
      .flags  = CLK_GET_RATE_NOCACHE,   \
                ^
   drivers/clk/samsung/clk.h:317:2: note: in expansion of macro '__PLL'
     __PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
     ^
   drivers/clk/samsung/clk-s3c2410.c:197:11: note: in expansion of macro 'PLL'
     [mpll] = PLL(pll_s3c2410_mpll, MPLL, "mpll", "xti",
              ^
   drivers/clk/samsung/clk.h:309:13: note: (near initialization for 's3c2410_plls[0].flags')
      .flags  = CLK_GET_RATE_NOCACHE,   \
                ^
   drivers/clk/samsung/clk.h:317:2: note: in expansion of macro '__PLL'
     __PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
     ^
   drivers/clk/samsung/clk-s3c2410.c:197:11: note: in expansion of macro 'PLL'
     [mpll] = PLL(pll_s3c2410_mpll, MPLL, "mpll", "xti",
              ^
>> drivers/clk/samsung/clk.h:309:13: error: initializer element is not constant
      .flags  = CLK_GET_RATE_NOCACHE,   \
                ^
   drivers/clk/samsung/clk.h:317:2: note: in expansion of macro '__PLL'
     __PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
     ^
   drivers/clk/samsung/clk-s3c2410.c:199:11: note: in expansion of macro 'PLL'
     [upll] = PLL(pll_s3c2410_upll, UPLL, "upll", "xti",
              ^
   drivers/clk/samsung/clk.h:309:13: note: (near initialization for 's3c2410_plls[1].flags')
      .flags  = CLK_GET_RATE_NOCACHE,   \
                ^
   drivers/clk/samsung/clk.h:317:2: note: in expansion of macro '__PLL'
     __PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
     ^
   drivers/clk/samsung/clk-s3c2410.c:199:11: note: in expansion of macro 'PLL'
     [upll] = PLL(pll_s3c2410_upll, UPLL, "upll", "xti",
              ^
>> drivers/clk/samsung/clk.h:309:13: error: initializer element is not constant
      .flags  = CLK_GET_RATE_NOCACHE,   \
                ^
   drivers/clk/samsung/clk.h:317:2: note: in expansion of macro '__PLL'
     __PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
     ^
   drivers/clk/samsung/clk-s3c2410.c:263:11: note: in expansion of macro 'PLL'
     [mpll] = PLL(pll_s3c2440_mpll, MPLL, "mpll", "xti",
              ^
   drivers/clk/samsung/clk.h:309:13: note: (near initialization for 's3c244x_common_plls[0].flags')
      .flags  = CLK_GET_RATE_NOCACHE,   \
                ^
   drivers/clk/samsung/clk.h:317:2: note: in expansion of macro '__PLL'
     __PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
     ^
   drivers/clk/samsung/clk-s3c2410.c:263:11: note: in expansion of macro 'PLL'
     [mpll] = PLL(pll_s3c2440_mpll, MPLL, "mpll", "xti",
              ^
>> drivers/clk/samsung/clk.h:309:13: error: initializer element is not constant
      .flags  = CLK_GET_RATE_NOCACHE,   \
                ^
   drivers/clk/samsung/clk.h:317:2: note: in expansion of macro '__PLL'
     __PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
     ^
   drivers/clk/samsung/clk-s3c2410.c:265:11: note: in expansion of macro 'PLL'
     [upll] = PLL(pll_s3c2410_upll, UPLL, "upll", "xti",
              ^
   drivers/clk/samsung/clk.h:309:13: note: (near initialization for 's3c244x_common_plls[1].flags')
      .flags  = CLK_GET_RATE_NOCACHE,   \
                ^
   drivers/clk/samsung/clk.h:317:2: note: in expansion of macro '__PLL'
     __PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
     ^
   drivers/clk/samsung/clk-s3c2410.c:265:11: note: in expansion of macro 'PLL'
     [upll] = PLL(pll_s3c2410_upll, UPLL, "upll", "xti",
              ^
   drivers/clk/samsung/clk.h:142:17: error: invalid operands to binary | (have 'int' and 'struct samsung_pll_clock *')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                    ^
   drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-s3c2410.c:273:2: note: in expansion of macro 'MUX'
     MUX(HCLK, "hclk", hclk_p, CLKDIVN, 1, 2),
     ^
   drivers/clk/samsung/clk.h:142:13: error: initializer element is not constant
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                ^
   drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-s3c2410.c:273:2: note: in expansion of macro 'MUX'
     MUX(HCLK, "hclk", hclk_p, CLKDIVN, 1, 2),
     ^
   drivers/clk/samsung/clk.h:142:13: note: (near initialization for 's3c244x_common_muxes[0].flags')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                ^
   drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-s3c2410.c:273:2: note: in expansion of macro 'MUX'
     MUX(HCLK, "hclk", hclk_p, CLKDIVN, 1, 2),
     ^
   drivers/clk/samsung/clk.h:142:17: error: invalid operands to binary | (have 'int' and 'struct samsung_pll_clock *')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                    ^
   drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-s3c2410.c:274:2: note: in expansion of macro 'MUX'
     MUX(ARMCLK, "armclk", armclk_p, CAMDIVN, 12, 1),
     ^
   drivers/clk/samsung/clk.h:142:13: error: initializer element is not constant
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                ^
   drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-s3c2410.c:274:2: note: in expansion of macro 'MUX'
     MUX(ARMCLK, "armclk", armclk_p, CAMDIVN, 12, 1),
     ^
   drivers/clk/samsung/clk.h:142:13: note: (near initialization for 's3c244x_common_muxes[1].flags')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                ^
   drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-s3c2410.c:274:2: note: in expansion of macro 'MUX'
     MUX(ARMCLK, "armclk", armclk_p, CAMDIVN, 12, 1),
     ^
   drivers/clk/samsung/clk-s3c2410.c:279:40: error: 'CLK_SET_RATE_PARENT' undeclared here (not in a function)
     FFACTOR(0, "ff_cam", "div_cam", 2, 1, CLK_SET_RATE_PARENT),
                                           ^
   drivers/clk/samsung/clk.h:104:13: note: in definition of macro 'FFACTOR'
      .flags  = f,   \
                ^
   drivers/clk/samsung/clk-s3c2410.c:279:40: error: initializer element is not constant
     FFACTOR(0, "ff_cam", "div_cam", 2, 1, CLK_SET_RATE_PARENT),
                                           ^
   drivers/clk/samsung/clk.h:104:13: note: in definition of macro 'FFACTOR'
      .flags  = f,   \
                ^
   drivers/clk/samsung/clk-s3c2410.c:279:40: note: (near initialization for 's3c244x_common_ffactor[1].flags')
     FFACTOR(0, "ff_cam", "div_cam", 2, 1, CLK_SET_RATE_PARENT),
                                           ^
   drivers/clk/samsung/clk.h:104:13: note: in definition of macro 'FFACTOR'
      .flags  = f,   \
                ^
   drivers/clk/samsung/clk-s3c2410.c:282:29: error: array type has incomplete element type 'struct clk_div_table'
    static struct clk_div_table div_hclk_4_d[] = {
                                ^
   drivers/clk/samsung/clk-s3c2410.c:283:4: error: field name not in record or union initializer
     { .val = 0, .div = 4 },
       ^
   drivers/clk/samsung/clk-s3c2410.c:283:4: note: (near initialization for 'div_hclk_4_d')
   drivers/clk/samsung/clk-s3c2410.c:283:14: error: field name not in record or union initializer
     { .val = 0, .div = 4 },
                 ^
   drivers/clk/samsung/clk-s3c2410.c:283:14: note: (near initialization for 'div_hclk_4_d')
--
   In file included from drivers/clk/samsung/clk-s3c2412.c:19:0:
   drivers/clk/samsung/clk.h:29:26: error: field 'clk_data' has incomplete type
     struct clk_onecell_data clk_data;
                             ^
>> drivers/clk/samsung/clk-s3c2412.c:89:29: error: array type has incomplete element type 'struct clk_div_table'
    static struct clk_div_table divxti_d[] = {
                                ^
   drivers/clk/samsung/clk-s3c2412.c:90:4: error: field name not in record or union initializer
     { .val = 0, .div = 1 },
       ^
   drivers/clk/samsung/clk-s3c2412.c:90:4: note: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:90:14: error: field name not in record or union initializer
     { .val = 0, .div = 1 },
                 ^
   drivers/clk/samsung/clk-s3c2412.c:90:14: note: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:91:4: error: field name not in record or union initializer
     { .val = 1, .div = 2 },
       ^
   drivers/clk/samsung/clk-s3c2412.c:91:4: note: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:91:14: error: field name not in record or union initializer
     { .val = 1, .div = 2 },
                 ^
   drivers/clk/samsung/clk-s3c2412.c:91:14: note: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:92:4: error: field name not in record or union initializer
     { .val = 2, .div = 4 },
       ^
   drivers/clk/samsung/clk-s3c2412.c:92:4: note: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:92:14: error: field name not in record or union initializer
     { .val = 2, .div = 4 },
                 ^
   drivers/clk/samsung/clk-s3c2412.c:92:14: note: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:93:4: error: field name not in record or union initializer
     { .val = 3, .div = 6 },
       ^
   drivers/clk/samsung/clk-s3c2412.c:93:4: note: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:93:14: error: field name not in record or union initializer
     { .val = 3, .div = 6 },
                 ^
   drivers/clk/samsung/clk-s3c2412.c:93:14: note: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:94:4: error: field name not in record or union initializer
     { .val = 4, .div = 8 },
       ^
   drivers/clk/samsung/clk-s3c2412.c:94:4: note: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:94:14: error: field name not in record or union initializer
     { .val = 4, .div = 8 },
                 ^
   drivers/clk/samsung/clk-s3c2412.c:94:14: note: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:95:4: error: field name not in record or union initializer
     { .val = 5, .div = 10 },
       ^
   drivers/clk/samsung/clk-s3c2412.c:95:4: note: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:95:14: error: field name not in record or union initializer
     { .val = 5, .div = 10 },
                 ^
   drivers/clk/samsung/clk-s3c2412.c:95:14: note: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:96:4: error: field name not in record or union initializer
     { .val = 6, .div = 12 },
       ^
   drivers/clk/samsung/clk-s3c2412.c:96:4: note: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:96:14: error: field name not in record or union initializer
     { .val = 6, .div = 12 },
                 ^
   drivers/clk/samsung/clk-s3c2412.c:96:14: note: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:97:4: error: field name not in record or union initializer
     { .val = 7, .div = 14 },
       ^
   drivers/clk/samsung/clk-s3c2412.c:97:4: note: (near initialization for 'divxti_d')
   drivers/clk/samsung/clk-s3c2412.c:97:14: error: field name not in record or union initializer
     { .val = 7, .div = 14 },
                 ^
   drivers/clk/samsung/clk-s3c2412.c:97:14: note: (near initialization for 'divxti_d')
   In file included from drivers/clk/samsung/clk-s3c2412.c:19:0:
   drivers/clk/samsung/clk-s3c2412.c:114:38: error: 'CLK_SET_RATE_PARENT' undeclared here (not in a function)
     FFACTOR(0, "ff_hclk", "hclk", 2, 1, CLK_SET_RATE_PARENT),
                                         ^
   drivers/clk/samsung/clk.h:104:13: note: in definition of macro 'FFACTOR'
      .flags  = f,   \
                ^
   drivers/clk/samsung/clk-s3c2412.c:114:38: error: initializer element is not constant
     FFACTOR(0, "ff_hclk", "hclk", 2, 1, CLK_SET_RATE_PARENT),
                                         ^
   drivers/clk/samsung/clk.h:104:13: note: in definition of macro 'FFACTOR'
      .flags  = f,   \
                ^
   drivers/clk/samsung/clk-s3c2412.c:114:38: note: (near initialization for 's3c2412_ffactor[0].flags')
     FFACTOR(0, "ff_hclk", "hclk", 2, 1, CLK_SET_RATE_PARENT),
                                         ^
   drivers/clk/samsung/clk.h:104:13: note: in definition of macro 'FFACTOR'
      .flags  = f,   \
                ^
   drivers/clk/samsung/clk.h:142:19: error: 'CLK_SET_RATE_NO_REPARENT' undeclared here (not in a function)
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                      ^
   drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-s3c2412.c:134:2: note: in expansion of macro 'MUX'
     MUX(0, "erefclk", erefclk_p, CLKSRC, 14, 2),
     ^
   drivers/clk/samsung/clk.h:142:17: error: invalid operands to binary | (have 'int' and 'struct samsung_fixed_factor_clock *')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                    ^
   drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
..

vim +102 drivers/clk/samsung/clk-s3c2410.c

3f7c01ad Heiko Stuebner 2014-05-09   93  static void s3c2410_clk_sleep_init(void) {}
3f7c01ad Heiko Stuebner 2014-05-09   94  #endif
3f7c01ad Heiko Stuebner 2014-05-09   95  
3f7c01ad Heiko Stuebner 2014-05-09   96  PNAME(fclk_p) = { "mpll", "div_slow" };
3f7c01ad Heiko Stuebner 2014-05-09   97  
3f7c01ad Heiko Stuebner 2014-05-09   98  struct samsung_mux_clock s3c2410_common_muxes[] __initdata = {
3f7c01ad Heiko Stuebner 2014-05-09  @99  	MUX(FCLK, "fclk", fclk_p, CLKSLOW, 4, 1),
3f7c01ad Heiko Stuebner 2014-05-09  100  };
3f7c01ad Heiko Stuebner 2014-05-09  101  
3f7c01ad Heiko Stuebner 2014-05-09 @102  static struct clk_div_table divslow_d[] = {
3f7c01ad Heiko Stuebner 2014-05-09  103  	{ .val = 0, .div = 1 },
3f7c01ad Heiko Stuebner 2014-05-09  104  	{ .val = 1, .div = 2 },
3f7c01ad Heiko Stuebner 2014-05-09  105  	{ .val = 2, .div = 4 },
3f7c01ad Heiko Stuebner 2014-05-09  106  	{ .val = 3, .div = 6 },
3f7c01ad Heiko Stuebner 2014-05-09  107  	{ .val = 4, .div = 8 },
3f7c01ad Heiko Stuebner 2014-05-09  108  	{ .val = 5, .div = 10 },
3f7c01ad Heiko Stuebner 2014-05-09  109  	{ .val = 6, .div = 12 },
3f7c01ad Heiko Stuebner 2014-05-09 @110  	{ .val = 7, .div = 14 },
3f7c01ad Heiko Stuebner 2014-05-09  111  	{ /* sentinel */ },
3f7c01ad Heiko Stuebner 2014-05-09  112  };
3f7c01ad Heiko Stuebner 2014-05-09  113  
3f7c01ad Heiko Stuebner 2014-05-09  114  struct samsung_div_clock s3c2410_common_dividers[] __initdata = {
3f7c01ad Heiko Stuebner 2014-05-09 @115  	DIV_T(0, "div_slow", "xti", CLKSLOW, 0, 3, divslow_d),
3f7c01ad Heiko Stuebner 2014-05-09  116  	DIV(PCLK, "pclk", "hclk", CLKDIVN, 0, 1),
3f7c01ad Heiko Stuebner 2014-05-09  117  };
3f7c01ad Heiko Stuebner 2014-05-09  118  

:::::: The code at line 102 was first introduced by commit
:::::: 3f7c01ade226e7006d76e42f8c9b99ada7085312 clk: samsung: add clock controller driver for s3c2410, s3c2440 and s3c2442

:::::: TO: Heiko Stuebner <heiko at sntech.de>
:::::: CC: Kukjin Kim <kgene.kim at samsung.com>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 40448 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/47c79e03/attachment-0001.obj>

From lv.zheng at intel.com  Tue Feb 16 18:51:51 2016
From: lv.zheng at intel.com (Zheng, Lv)
Date: Wed, 17 Feb 2016 02:51:51 +0000
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>

Hi,

> From: linux-acpi-owner at vger.kernel.org [mailto:linux-acpi-
> owner at vger.kernel.org] On Behalf Of Zheng, Lv
> Subject: RE: [PATCH v3 1/5] ACPI: change __init to __ref for
> early_acpi_os_unmap_memory()
> 
> Hi,
> 
> > -----Original Message-----
> > From: linux-acpi-owner at vger.kernel.org [mailto:linux-acpi-
> > owner at vger.kernel.org] On Behalf Of Aleksey Makarov
> > Sent: Tuesday, February 16, 2016 2:05 AM
> > To: linux-acpi at vger.kernel.org
> > Cc: linux-serial at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> > kernel at lists.infradead.org; Aleksey Makarov <aleksey.makarov at linaro.org>;
> > Russell King <linux at arm.linux.org.uk>; Greg Kroah-Hartman
> > <gregkh at linuxfoundation.org>; Rafael J . Wysocki <rjw at rjwysocki.net>; Leif
> > Lindholm <leif.lindholm at linaro.org>; Graeme Gregory
> > <graeme.gregory at linaro.org>; Al Stone <ahs3 at redhat.com>; Christopher
> > Covington <cov at codeaurora.org>; Len Brown <lenb at kernel.org>
> > Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
> > early_acpi_os_unmap_memory()
> >
> > early_acpi_os_unmap_memory() is marked as __init because it calls
> > __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is not set.
> >
> > acpi_gbl_permanent_mmap is set in __init acpi_early_init()
> > so it is safe to call early_acpi_os_unmap_memory() from anywhere
> >
> > We need this function to be non-__init because we need access to
> > some tables at unpredictable time--it may be before or after
> > acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port Console
> > Redirection) table is needed each time a new console is registered.
> > It can be quite early (console_initcall) or when a module is inserted.
> > When this table accessed before acpi_gbl_permanent_mmap is set,
> > the pointer should be unmapped.  This is exactly what this function
> > does.
> [Lv Zheng]
> Why don't you use another API instead of early_acpi_os_unmap_memory() in
> case you want to unmap things in any cases.
> acpi_os_unmap_memory() should be the one to match this purpose.
> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
> And in fact early_acpi_os_unmap_memory() should be removed.
[Lv Zheng] 
One more thing is:
If you can't switch your driver to use acpi_os_unmap_memory() instead of early_acpi_os_unmap_memory(),
then it implies that your driver does have a defect.

There is an early bootup requirement in Linux.
Maps acquired during the early stage should be freed by the driver during the early stage.
And the driver should re-acquire the memory map after booting.

This is because, during early bootup stage, there are only limited slots available for drivers to map memory.
So by changing __init to __ref here, you probably will hide many such defects.
And solving issues in this way doesn't seem to be an improvement.

Thanks and best regards
-Lv

> 
> Thanks and best regards
> -Lv
> 
> >
> > Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> > ---
> >  drivers/acpi/osl.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> > index 67da6fb..8a552cd 100644
> > --- a/drivers/acpi/osl.c
> > +++ b/drivers/acpi/osl.c
> > @@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void *virt,
> > acpi_size size)
> >  }
> >  EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
> >
> > -void __init early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
> size)
> > +/*
> > + * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
> > + * so it is safe to call early_acpi_os_unmap_memory() from anywhere
> > + */
> > +void __ref early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
> size)
> >  {
> >  	if (!acpi_gbl_permanent_mmap)
> >  		__acpi_unmap_table(virt, size);
> > --
> > 2.7.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From biao.huang at mediatek.com  Tue Feb 16 11:16:32 2016
From: biao.huang at mediatek.com (Biao Huang)
Date: Wed, 17 Feb 2016 03:16:32 +0800
Subject: [PATCH 0/2] pinctrl: mediatek: add setting for gpio and eint
Message-ID: <1455650194-9813-1-git-send-email-biao.huang@mediatek.com>

1. add input-enable setting in gpio_request_enable.
2. add input-enable and direction setting for eint resources.

Biao Huang (2):
  pinctrl: mediatek: add input-enable setting in gpio_request_enable
  pinctrl: mediatek: add input-enable and direction setting for eint
    resources

 drivers/pinctrl/mediatek/pinctrl-mtk-common.c |    5 +++++
 1 file changed, 5 insertions(+)

-- 
1.7.9.5



From biao.huang at mediatek.com  Tue Feb 16 11:16:33 2016
From: biao.huang at mediatek.com (Biao Huang)
Date: Wed, 17 Feb 2016 03:16:33 +0800
Subject: [PATCH 1/2] pinctrl: mediatek: add input-enable setting in
 gpio_request_enable
In-Reply-To: <1455650194-9813-1-git-send-email-biao.huang@mediatek.com>
References: <1455650194-9813-1-git-send-email-biao.huang@mediatek.com>
Message-ID: <1455650194-9813-2-git-send-email-biao.huang@mediatek.com>

Since input-disable cuts off input signal of gpio, add input-enable
setting in .gpio_request_enable implementation to ensure gpio function well

Signed-off-by: Biao Huang <biao.huang at mediatek.com>
---
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 6024483..578897a 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -764,6 +764,7 @@ static int mtk_pmx_gpio_request_enable(struct pinctrl_dev *pctldev,
 	}
 
 	mtk_pmx_set_mode(pctldev, offset, muxval);
+	mtk_pconf_set_ies_smt(pctl, offset, 1, PIN_CONFIG_INPUT_ENABLE);
 
 	return 0;
 }
-- 
1.7.9.5



From biao.huang at mediatek.com  Tue Feb 16 11:16:34 2016
From: biao.huang at mediatek.com (Biao Huang)
Date: Wed, 17 Feb 2016 03:16:34 +0800
Subject: [PATCH 2/2] pinctrl: mediatek: add input-enable and direction setting
 for eint resources
In-Reply-To: <1455650194-9813-1-git-send-email-biao.huang@mediatek.com>
References: <1455650194-9813-1-git-send-email-biao.huang@mediatek.com>
Message-ID: <1455650194-9813-3-git-send-email-biao.huang@mediatek.com>

To use pin as eint, user should make sure that:
1. pin is set to right mode, this is done in .irq_request_resources
implementation already.
2. direction of the pin is input, which should call GPIO API to set
pin to input gpio.
We add what step 2 do to .irq_request_resources so that user doesn't
need call GPIO API any more when pin for eint usage.

Signed-off-by: Biao Huang <biao.huang at mediatek.com>
---
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 578897a..342d85b 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -863,6 +863,10 @@ static int mtk_pinctrl_irq_request_resources(struct irq_data *d)
 
 	/* set mux to INT mode */
 	mtk_pmx_set_mode(pctl->pctl_dev, pin->pin.number, pin->eint.eintmux);
+	/* set gpio direction to input */
+	mtk_pmx_gpio_set_direction(pctl->pctl_dev, NULL, pin->pin.number, true);
+	/* set input-enable */
+	mtk_pconf_set_ies_smt(pctl, pin->pin.number, 1, PIN_CONFIG_INPUT_ENABLE);
 
 	return 0;
 }
-- 
1.7.9.5



From xuejiancheng at huawei.com  Tue Feb 16 19:08:19 2016
From: xuejiancheng at huawei.com (xuejiancheng)
Date: Wed, 17 Feb 2016 11:08:19 +0800
Subject: [RESEND PATCH v8 1/6] clk: hisilicon: add CRG driver for hi3519
 soc
In-Reply-To: <20160217004648.2278.64006@quark.deferred.io>
References: <1454639472-17373-1-git-send-email-xuejiancheng@huawei.com>
 <1454639472-17373-2-git-send-email-xuejiancheng@huawei.com>
 <20160217004648.2278.64006@quark.deferred.io>
Message-ID: <56C3E423.5080801@huawei.com>

Hi Mike,
   Thank you very much for your comments.

On 2016/2/17 8:46, Michael Turquette wrote:
> Hello Jiancheng Xue,
> 
> Quoting Jiancheng Xue (2016-02-04 18:31:07)
>> diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
>> index 74dba31..3f57b09 100644
>> --- a/drivers/clk/hisilicon/Makefile
>> +++ b/drivers/clk/hisilicon/Makefile
>> @@ -4,8 +4,10 @@
>>  
>>  obj-y  += clk.o clkgate-separated.o clkdivider-hi6220.o
>>  
>> +obj-$(CONFIG_RESET_CONTROLLER) += reset.o
> 
> Do you really want to build reset.o for all hisi SoCs?
> 

This reset controller driver will be just used in some of hisilicon SOCs.
I'll add a specific config item for it like CONFIG_RESET_HISI. The config
item will be selected by default in SOCs needing this driver.

I'll also fix other issues in next version. Thank you!

Regards,
Jiancheng.





From zhang.chunyan at linaro.org  Tue Feb 16 19:18:50 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Wed, 17 Feb 2016 11:18:50 +0800
Subject: [PATCH V3 6/6] coresight-stm: adding driver for CoreSight STM
 component
In-Reply-To: <VI1PR08MB06708C5EA9DEE2D71C13FFAA8AA90@VI1PR08MB0670.eurprd08.prod.outlook.com>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
 <1454756672-12790-7-git-send-email-zhang.chunyan@linaro.org>
 <CANLsYkxvLFu1C+_H9c0EoMebLQu1gnwt9bqY6_R3j+ua2w+xMg@mail.gmail.com>
 <VI1PR08MB06708C5EA9DEE2D71C13FFAA8AA90@VI1PR08MB0670.eurprd08.prod.outlook.com>
Message-ID: <CAG2=9p9-c5z6yXm6VDkDeqZmpFGt3z88ccNQxZTwia=dm3_GNQ@mail.gmail.com>

Hi Michael,

One question below need to be clarified.

On Fri, Feb 12, 2016 at 10:55 PM, Michael Williams
<Michael.Williams at arm.com> wrote:
> Mathieu Poirier [mailto:mathieu.poirier at linaro.org] wrote:
>> On 6 February 2016 at 04:04, Chunyan Zhang <zhang.chunyan at linaro.org> wrote:
>>> From: Pratik Patel <pratikp at codeaurora.org>
>>>
>>> This driver adds support for the STM CoreSight IP block, allowing any
>>> system compoment (HW or SW) to log and aggregate messages via a
>>> single entity.
>>>
>>> The CoreSight STM exposes an application defined number of channels
>>> called stimulus port.  Configuration is done using entries in sysfs
>>> and channels made available to userspace via configfs.
>>>
>>> Signed-off-by: Pratik Patel <pratikp at codeaurora.org>
>>> Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
>>> Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
>>> ---
>>>  .../ABI/testing/sysfs-bus-coresight-devices-stm    |  53 ++
>>>  Documentation/trace/coresight.txt                  |  37 +-
>>>  drivers/hwtracing/coresight/Kconfig                |  11 +
>>>  drivers/hwtracing/coresight/Makefile               |   1 +
>>>  drivers/hwtracing/coresight/coresight-stm.c        | 928 +++++++++++++++++++++
>>>  include/linux/coresight-stm.h                      |   6 +
>>>  include/uapi/linux/coresight-stm.h                 |  12 +
>>>  7 files changed, 1046 insertions(+), 2 deletions(-)
>>>  create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>>>  create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
>>>  create mode 100644 include/linux/coresight-stm.h
>>>  create mode 100644 include/uapi/linux/coresight-stm.h
>>>

[...]

>>> +static int stm_send(void *addr, const void *data, u32 size, u8 max)
>>> +{
>>> +       u32 len = size;
>>> +       u8 paload[8];
>>> +
>>> +       if (stm_addr_unaligned(data, max)) {
>>> +               memcpy(paload, data, size);
>>> +               data = paload;
>>> +       }
>>> +
>>> +       /* now we are 64bit/32bit aligned */
>>> +#ifdef CONFIG_64BIT
>>> +       if (size == 8)
>>> +               writeq_relaxed(*(u64 *)data, addr);
>>> +#endif
>>
>> We probably don't need an #ifdef here.  Checking the size of the
>> transfer against the fundamental data size will result in the same
>> outcome, i.e preventing 64 bit transfers on a 32 bit architecture.  An
>> error (understandable by the caller) should probably be returned in
>> this case.
>
> In theory this is correct, but if the code is unreachable for non-32-bit architectures, why include it at all?

                            ^^^^^^^
I guess you mean the code is unreachable for "non-64-bit" architectures?

>
>>> +       if (size >= 4) {
>>> +               writel_relaxed(*(u32 *)data, addr);
>>> +               data += 4;
>>> +               size -= 4;
>>> +       }
>>> +
>>> +       if (size >= 2) {
>>> +               writew_relaxed(*(u16 *)data, addr);
>>> +               data += 2;
>>> +               size -= 2;
>>> +       }
>>> +
>>> +       if (size == 1)
>>> +               writeb_relaxed(*(u8 *)data, addr);
>>> +
>>> +       return len;
>>> +}
>
> The API for stm_data::packet (include/linux/stm.h) is not wholly clearly defined, but it does state "sends an STP packet," which I interpret as meaning exactly one packet and no more. This function (which is called from this module's implementation of stm_data::packet) will send multiple STP packets if called with a value that is not exactly 8, 4, 2, or 1.

Yes, understand. Since the only first packet in one STM trace should
be marked timestamp, others should not be(their timestamps are same),
the function "stm_send" should indeed send one STP packet at a time.

I will address this in the next version.

Thanks for your time,
Chunyan

>
> To send only one packet, either:
>
> * These "if" statements are replaced with "else if" (as appropriate), and the function returns the size of data consumed; or
> * The stm_generic_packet() function (below) forces "size" to a power-of-two (<= write_max) before calling stm_send().
>
>>> +static int stm_generic_link(struct stm_data *stm_data,
>>> +                           unsigned int master,  unsigned int channel)
>>> +{
>>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>>> +                                                  struct stm_drvdata, stm);
>>> +       if (!drvdata || !drvdata->csdev)
>>> +               return -EINVAL;
>>> +
>>> +       return coresight_enable(drvdata->csdev);
>>> +}
>>> +
>>> +static void stm_generic_unlink(struct stm_data *stm_data,
>>> +                              unsigned int master,  unsigned int channel)
>>> +{
>>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>>> +                                                  struct stm_drvdata, stm);
>>> +       if (!drvdata || !drvdata->csdev)
>>> +               return;
>>> +
>>> +       stm_disable(drvdata->csdev);
>>> +}
>>> +
>>> +static long stm_generic_set_options(struct stm_data *stm_data,
>>> +                                   unsigned int master,
>>> +                                   unsigned int channel,
>>> +                                   unsigned int nr_chans,
>>> +                                   unsigned long options)
>>> +{
>>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>>> +                                                  struct stm_drvdata, stm);
>>> +       if (!(drvdata && drvdata->enable))
>>> +               return -EINVAL;
>>> +
>>> +       if (channel >= drvdata->numsp)
>>> +               return -EINVAL;
>>> +
>>> +       switch (options) {
>>> +       case STM_OPTION_GUARANTEED:
>>> +               set_bit(channel, drvdata->chs.guaranteed);
>>> +               break;
>>> +
>>> +       case STM_OPTION_INVARIANT:
>>> +               clear_bit(channel, drvdata->chs.guaranteed);
>>> +               break;
>>> +
>>> +       default:
>>> +               return -EINVAL;
>>> +       }
>>> +
>>> +       return 0;
>>> +}
>>> +
>>> +static long stm_generic_get_options(struct stm_data *stm_data,
>>> +                                   unsigned int master,
>>> +                                   unsigned int channel,
>>> +                                   unsigned int nr_chans,
>>> +                                   u64 *options)
>>> +{
>>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>>> +                                                  struct stm_drvdata, stm);
>>> +       if (!(drvdata && drvdata->enable))
>>> +               return -EINVAL;
>>> +
>>> +       if (channel >= drvdata->numsp)
>>> +               return -EINVAL;
>>> +
>>> +       switch (*options) {
>>> +       case STM_OPTION_GUARANTEED:
>>> +               *options = test_bit(channel, drvdata->chs.guaranteed);
>>> +               break;
>>> +
>>> +       default:
>>> +               return -EINVAL;
>>> +       }
>>> +
>>> +       return 0;
>>> +}
>>> +
>>> +static ssize_t stm_generic_packet(struct stm_data *stm_data,
>>> +                                 unsigned int master,
>>> +                                 unsigned int channel,
>>> +                                 unsigned int packet,
>>> +                                 unsigned int flags,
>>> +                                 unsigned int size,
>>> +                                 const unsigned char *payload)
>>> +{
>>> +       unsigned long ch_addr;
>>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>>> +                                                  struct stm_drvdata, stm);
>>> +
>>> +       if (!(drvdata && drvdata->enable))
>>> +               return 0;
>>> +
>>> +       if (channel >= drvdata->numsp)
>>> +               return 0;
>>> +
>>> +       ch_addr = (unsigned long)stm_channel_addr(drvdata, channel);
>>> +
>>> +       flags = (flags == STP_PACKET_TIMESTAMPED) ? STM_FLAG_TIMESTAMPED : 0;
>>> +       flags |= test_bit(channel, drvdata->chs.guaranteed) ?
>>> +                          STM_FLAG_GUARANTEED : 0;
>>> +
>>> +       if (size > drvdata->write_max)
>>> +               size = drvdata->write_max;
>>> +
>>> +       switch (packet) {
>>> +       case STP_PACKET_FLAG:
>>> +               ch_addr |= stm_channel_off(STM_PKT_TYPE_FLAG, flags);
>>> +
>>> +               /* the generic STM API set a size of zero on flag packets. */
>>> +               size = 1;
>>> +               break;
>>> +
>>> +       case STP_PACKET_DATA:
>>> +               ch_addr |= stm_channel_off(STM_PKT_TYPE_DATA, flags);
>>> +               break;
>>> +
>>> +       default:
>>> +               return 0;
>>> +       }
>>> +
>>> +       return stm_send((void *)ch_addr, payload, size, drvdata->write_max);
>>> +}
>>> +
>>> +static ssize_t hwevent_enable_show(struct device *dev,
>>> +                                  struct device_attribute *attr, char *buf)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val = drvdata->stmheer;
>>> +
>>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>>> +}
>>> +
>>> +static ssize_t hwevent_enable_store(struct device *dev,
>>> +                                   struct device_attribute *attr,
>>> +                                   const char *buf, size_t size)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val;
>>> +       int ret = 0;
>>> +
>>> +       ret = kstrtoul(buf, 16, &val);
>>> +       if (ret)
>>> +               return -EINVAL;
>>> +
>>> +       drvdata->stmheer = val;
>>> +       /* HW event enable and trigger go hand in hand */
>>> +       drvdata->stmheter = val;
>>> +
>>> +       return size;
>>> +}
>>> +static DEVICE_ATTR_RW(hwevent_enable);
>>> +
>>> +static ssize_t hwevent_select_show(struct device *dev,
>>> +                                  struct device_attribute *attr, char *buf)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val = drvdata->stmhebsr;
>>> +
>>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>>> +}
>>> +
>>> +static ssize_t hwevent_select_store(struct device *dev,
>>> +                                   struct device_attribute *attr,
>>> +                                   const char *buf, size_t size)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val;
>>> +       int ret = 0;
>>> +
>>> +       ret = kstrtoul(buf, 16, &val);
>>> +       if (ret)
>>> +               return -EINVAL;
>>> +
>>> +       drvdata->stmhebsr = val;
>>> +
>>> +       return size;
>>> +}
>>> +static DEVICE_ATTR_RW(hwevent_select);
>>> +
>>> +static ssize_t port_select_show(struct device *dev,
>>> +                               struct device_attribute *attr, char *buf)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val;
>>> +
>>> +       if (!drvdata->enable) {
>>> +               val = drvdata->stmspscr;
>>> +       } else {
>>> +               spin_lock(&drvdata->spinlock);
>>> +               val = readl_relaxed(drvdata->base + STMSPSCR);
>>> +               spin_unlock(&drvdata->spinlock);
>>> +       }
>>> +
>>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>>> +}
>>> +
>>> +static ssize_t port_select_store(struct device *dev,
>>> +                                struct device_attribute *attr,
>>> +                                const char *buf, size_t size)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val, stmsper;
>>> +       int ret = 0;
>>> +
>>> +       ret = kstrtoul(buf, 16, &val);
>>> +       if (ret)
>>> +               return ret;
>>> +
>>> +       spin_lock(&drvdata->spinlock);
>>> +       drvdata->stmspscr = val;
>>> +
>>> +       if (drvdata->enable) {
>>> +               CS_UNLOCK(drvdata->base);
>>> +               /* Process as per ARM's TRM recommendation */
>>> +               stmsper = readl_relaxed(drvdata->base + STMSPER);
>>> +               writel_relaxed(0x0, drvdata->base + STMSPER);
>>> +               writel_relaxed(drvdata->stmspscr, drvdata->base + STMSPSCR);
>>> +               writel_relaxed(stmsper, drvdata->base + STMSPER);
>>> +               CS_LOCK(drvdata->base);
>>> +       }
>>> +       spin_unlock(&drvdata->spinlock);
>>> +
>>> +       return size;
>>> +}
>>> +static DEVICE_ATTR_RW(port_select);
>>> +
>>> +static ssize_t port_enable_show(struct device *dev,
>>> +                               struct device_attribute *attr, char *buf)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val;
>>> +
>>> +       if (!drvdata->enable) {
>>> +               val = drvdata->stmsper;
>>> +       } else {
>>> +               spin_lock(&drvdata->spinlock);
>>> +               val = readl_relaxed(drvdata->base + STMSPER);
>>> +               spin_unlock(&drvdata->spinlock);
>>> +       }
>>> +
>>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>>> +}
>>> +
>>> +static ssize_t port_enable_store(struct device *dev,
>>> +                                struct device_attribute *attr,
>>> +                                const char *buf, size_t size)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +       unsigned long val;
>>> +       int ret = 0;
>>> +
>>> +       ret = kstrtoul(buf, 16, &val);
>>> +       if (ret)
>>> +               return ret;
>>> +
>>> +       spin_lock(&drvdata->spinlock);
>>> +       drvdata->stmsper = val;
>>> +
>>> +       if (drvdata->enable) {
>>> +               CS_UNLOCK(drvdata->base);
>>> +               writel_relaxed(drvdata->stmsper, drvdata->base + STMSPER);
>>> +               CS_LOCK(drvdata->base);
>>> +       }
>>> +       spin_unlock(&drvdata->spinlock);
>>> +
>>> +       return size;
>>> +}
>>> +static DEVICE_ATTR_RW(port_enable);
>>> +
>>> +static ssize_t traceid_show(struct device *dev,
>>> +                           struct device_attribute *attr, char *buf)
>>> +{
>>> +       unsigned long val;
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +
>>> +       val = drvdata->traceid;
>>> +       return sprintf(buf, "%#lx\n", val);
>>> +}
>>> +
>>> +static ssize_t traceid_store(struct device *dev,
>>> +                            struct device_attribute *attr,
>>> +                            const char *buf, size_t size)
>>> +{
>>> +       int ret;
>>> +       unsigned long val;
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>>> +
>>> +       ret = kstrtoul(buf, 16, &val);
>>> +       if (ret)
>>> +               return ret;
>>> +
>>> +       /* traceid field is 7bit wide on STM32 */
>>> +       drvdata->traceid = val & 0x7f;
>>> +       return size;
>>> +}
>>> +static DEVICE_ATTR_RW(traceid);
>>> +
>>> +#define coresight_simple_func(type, name, offset)                      \
>>> +static ssize_t name##_show(struct device *_dev,                                \
>>> +                          struct device_attribute *attr, char *buf)    \
>>> +{                                                                      \
>>> +       type *drvdata = dev_get_drvdata(_dev->parent);                  \
>>> +       return scnprintf(buf, PAGE_SIZE, "0x%08x\n",                    \
>>> +                        readl_relaxed(drvdata->base + offset));        \
>>> +}                                                                      \
>>> +DEVICE_ATTR_RO(name)
>>> +
>>> +#define coresight_stm_simple_func(name, offset)        \
>>> +       coresight_simple_func(struct stm_drvdata, name, offset)
>>> +
>>> +coresight_stm_simple_func(tcsr, STMTCSR);
>>> +coresight_stm_simple_func(tsfreqr, STMTSFREQR);
>>> +coresight_stm_simple_func(syncr, STMSYNCR);
>>> +coresight_stm_simple_func(sper, STMSPER);
>>> +coresight_stm_simple_func(spter, STMSPTER);
>>> +coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
>>> +coresight_stm_simple_func(spscr, STMSPSCR);
>>> +coresight_stm_simple_func(spmscr, STMSPMSCR);
>>> +coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
>>> +coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
>>> +coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
>>> +coresight_stm_simple_func(devid, CORESIGHT_DEVID);
>>> +
>>> +static struct attribute *coresight_stm_attrs[] = {
>>> +       &dev_attr_hwevent_enable.attr,
>>> +       &dev_attr_hwevent_select.attr,
>>> +       &dev_attr_port_enable.attr,
>>> +       &dev_attr_port_select.attr,
>>> +       &dev_attr_traceid.attr,
>>> +       NULL,
>>> +};
>>> +
>>> +static struct attribute *coresight_stm_mgmt_attrs[] = {
>>> +       &dev_attr_tcsr.attr,
>>> +       &dev_attr_tsfreqr.attr,
>>> +       &dev_attr_syncr.attr,
>>> +       &dev_attr_sper.attr,
>>> +       &dev_attr_spter.attr,
>>> +       &dev_attr_privmaskr.attr,
>>> +       &dev_attr_spscr.attr,
>>> +       &dev_attr_spmscr.attr,
>>> +       &dev_attr_spfeat1r.attr,
>>> +       &dev_attr_spfeat2r.attr,
>>> +       &dev_attr_spfeat3r.attr,
>>> +       &dev_attr_devid.attr,
>>> +       NULL,
>>> +};
>>> +
>>> +static const struct attribute_group coresight_stm_group = {
>>> +       .attrs = coresight_stm_attrs,
>>> +};
>>> +
>>> +static const struct attribute_group coresight_stm_mgmt_group = {
>>> +       .attrs = coresight_stm_mgmt_attrs,
>>> +       .name = "mgmt",
>>> +};
>>> +
>>> +static const struct attribute_group *coresight_stm_groups[] = {
>>> +       &coresight_stm_group,
>>> +       &coresight_stm_mgmt_group,
>>> +       NULL,
>>> +};
>>> +
>>> +static int stm_get_resource_byname(struct device_node *np,
>>> +                                  char *ch_base, struct resource *res)
>>> +{
>>> +       const char *name = NULL;
>>> +       int index = 0, found = 0;
>>> +
>>> +       while (!of_property_read_string_index(np, "reg-names", index, &name)) {
>>> +               if (strcmp(ch_base, name)) {
>>> +                       index++;
>>> +                       continue;
>>> +               }
>>> +
>>> +               /* We have a match and @index is where it's at */
>>> +               found = 1;
>>> +               break;
>>> +       }
>>> +
>>> +       if (!found)
>>> +               return -EINVAL;
>>> +
>>> +       return of_address_to_resource(np, index, res);
>>> +}
>>> +
>>> +static u32 stm_fundamental_data_size(struct stm_drvdata *drvdata)
>>> +{
>>> +       u32 stmspfeat2r;
>>> +
>>> +       stmspfeat2r = readl_relaxed(drvdata->base + STMSPFEAT2R);
>>> +       return BMVAL(stmspfeat2r, 12, 15);
>>> +}
>>> +
>>> +static u32 stm_num_stimulus_port(struct stm_drvdata *drvdata)
>>> +{
>>> +       u32 numsp;
>>> +
>>> +       numsp = readl_relaxed(drvdata->base + CORESIGHT_DEVID);
>>> +       /*
>>> +        * NUMPS in STMDEVID is 17 bit long and if equal to 0x0,
>>> +        * 32 stimulus ports are supported.
>>> +        */
>>> +       numsp &= 0x1ffff;
>>> +       if (!numsp)
>>> +               numsp = STM_32_CHANNEL;
>>> +       return numsp;
>>> +}
>>> +
>>> +static void stm_init_default_data(struct stm_drvdata *drvdata)
>>> +{
>>> +       /* Don't use port selection */
>>> +       drvdata->stmspscr = 0x0;
>>> +       /*
>>> +        * Enable all channel regardless of their number.  When port
>>> +        * selection isn't used (see above) STMSPER applies to all
>>> +        * 32 channel group available, hence setting all 32 bits to 1
>>> +        */
>>> +       drvdata->stmsper = ~0x0;
>>> +
>>> +       /*
>>> +        * Select arbitrary value to start with.  If there is a conflict
>>> +        * with other tracers the framework will deal with it.
>>> +        */
>>> +       drvdata->traceid = 0x20;
>>> +
>>> +       /* Set invariant transaction timing on all channels */
>>> +       bitmap_clear(drvdata->chs.guaranteed, 0, drvdata->numsp);
>>> +}
>>> +
>>> +static void stm_init_generic_data(struct stm_drvdata *drvdata)
>>> +{
>>> +       drvdata->stm.name = dev_name(drvdata->dev);
>>> +       drvdata->stm.mstatic = true;
>>> +       drvdata->stm.sw_nchannels = drvdata->numsp;
>>> +       drvdata->stm.packet = stm_generic_packet;
>>> +       drvdata->stm.link = stm_generic_link;
>>> +       drvdata->stm.unlink = stm_generic_unlink;
>>> +       drvdata->stm.set_options = stm_generic_set_options;
>>> +       drvdata->stm.get_options = stm_generic_get_options;
>>> +}
>>> +
>>> +static int stm_probe(struct amba_device *adev, const struct amba_id *id)
>>> +{
>>> +       int ret;
>>> +       void __iomem *base;
>>> +       unsigned long *guaranteed;
>>> +       struct device *dev = &adev->dev;
>>> +       struct coresight_platform_data *pdata = NULL;
>>> +       struct stm_drvdata *drvdata;
>>> +       struct resource *res = &adev->res;
>>> +       struct resource ch_res;
>>> +       size_t res_size, bitmap_size;
>>> +       struct coresight_desc *desc;
>>> +       struct device_node *np = adev->dev.of_node;
>>> +
>>> +       if (np) {
>>> +               pdata = of_get_coresight_platform_data(dev, np);
>>> +               if (IS_ERR(pdata))
>>> +                       return PTR_ERR(pdata);
>>> +               adev->dev.platform_data = pdata;
>>> +       }
>>> +       drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
>>> +       if (!drvdata)
>>> +               return -ENOMEM;
>>> +
>>> +       drvdata->dev = &adev->dev;
>>> +       drvdata->atclk = devm_clk_get(&adev->dev, "atclk"); /* optional */
>>> +       if (!IS_ERR(drvdata->atclk)) {
>>> +               ret = clk_prepare_enable(drvdata->atclk);
>>> +               if (ret)
>>> +                       return ret;
>>> +       }
>>> +       dev_set_drvdata(dev, drvdata);
>>> +
>>> +       base = devm_ioremap_resource(dev, res);
>>> +       if (IS_ERR(base))
>>> +               return PTR_ERR(base);
>>> +       drvdata->base = base;
>>> +
>>> +       ret = stm_get_resource_byname(np, "stm-stimulus-base", &ch_res);
>>> +       if (ret)
>>> +               return ret;
>>> +
>>> +       base = devm_ioremap_resource(dev, &ch_res);
>>> +       if (IS_ERR(base))
>>> +               return PTR_ERR(base);
>>> +       drvdata->chs.base = base;
>>> +
>>> +       drvdata->write_max = sizeof(u32);
>>
>> Isn't the fundamental data size the maximum an architecture can stand?
>>  Why not simply use that rather than adding another variable?
>>
>>> +       drvdata->write_64bit = stm_fundamental_data_size(drvdata);
>>> +
>>> +#ifndef CONFIG_64BIT
>>> +       if (drvdata->write_64bit)
>>> +               drvdata->write_max = sizeof(u64);
>>> +#endif
>
> It is a bit odd that this code is using sizeof(u64) / sizeof(u32) here, when it is using 8 / 4 explicitly in the functions above.
>
>>
>> In most cases the fundamental data size will follow the architecture
>> size, i.e, 32 bit architecture with 32 bit fundamental data size, 64
>> bit architecture with 64 bit fundamental data size.  A fundamental
>> data size of 32 is also possible on a 64 bit architecture.
>>
>> What needs to be prevented is a 32 bit architecture with a fundamental
>> data size of 64.  In those cases the fundamental data size should be
>> adjusted to be 32 bit.  To do that I suggest to modify
>> stm_fundamental_data_size() to probe the STM's fundamental data size
>> but to adjust it down if on a 32 bit system.  Knowing whether running
>> on a 32/64 bit system is easy when using the IS_ENABLED() macro.
>
> Agreed. For ARM, 64-bit writes to the STM are supported only if BOTH the STM supports 64-bit data and the processor is in 64-bit execution state. Otherwise, the largest size is 32 bits. You are likely to see both 64-bit STM from 32-bit execution state, and 32-bit STM on a SoC with a 64-bit ARM processor.
>
>>> +
>>> +       if (boot_nr_channel) {
>>> +               drvdata->numsp = boot_nr_channel;
>>> +               res_size = min((resource_size_t)(boot_nr_channel *
>>> +                                 BYTES_PER_CHANNEL), resource_size(res));
>>> +       } else {
>>> +               drvdata->numsp = stm_num_stimulus_port(drvdata);
>>> +               res_size = min((resource_size_t)(drvdata->numsp *
>>> +                                BYTES_PER_CHANNEL), resource_size(res));
>>> +       }
>>> +       bitmap_size = BITS_TO_LONGS(drvdata->numsp) * sizeof(long);
>>> +
>>> +       guaranteed = devm_kzalloc(dev, bitmap_size, GFP_KERNEL);
>>> +       if (!guaranteed)
>>> +               return -ENOMEM;
>>> +       drvdata->chs.guaranteed = guaranteed;
>>> +
>>> +       spin_lock_init(&drvdata->spinlock);
>>> +
>>> +       stm_init_default_data(drvdata);
>>> +       stm_init_generic_data(drvdata);
>>> +
>>> +       if (stm_register_device(dev, &drvdata->stm, THIS_MODULE)) {
>>> +               dev_info(dev,
>>> +                        "stm_register_device failed, probing deffered\n");
>>> +               return -EPROBE_DEFER;
>>> +       }
>>> +
>>> +       desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
>>> +       if (!desc) {
>>> +               ret = -ENOMEM;
>>> +               goto stm_unregister;
>>> +       }
>>> +
>>> +       desc->type = CORESIGHT_DEV_TYPE_SOURCE;
>>> +       desc->subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE;
>>> +       desc->ops = &stm_cs_ops;
>>> +       desc->pdata = pdata;
>>> +       desc->dev = dev;
>>> +       desc->groups = coresight_stm_groups;
>>> +       drvdata->csdev = coresight_register(desc);
>>> +       if (IS_ERR(drvdata->csdev)) {
>>> +               ret = PTR_ERR(drvdata->csdev);
>>> +               goto stm_unregister;
>>> +       }
>>> +
>>> +       pm_runtime_put(&adev->dev);
>>> +
>>> +       dev_info(dev, "%s initialized\n", (char *)id->data);
>>> +       return 0;
>>> +
>>> +stm_unregister:
>>> +       stm_unregister_device(&drvdata->stm);
>>> +       return ret;
>>> +}
>>> +
>>> +static int stm_remove(struct amba_device *adev)
>>> +{
>>> +       struct stm_drvdata *drvdata = amba_get_drvdata(adev);
>>> +
>>> +       stm_unregister_device(&drvdata->stm);
>>> +       coresight_unregister(drvdata->csdev);
>>> +       return 0;
>>> +}
>>
>> The xyz_remove() functions is not needed for coresight devices -
>> unbinding a device from its driver will no longer be possible in the
>> 4.6 cycle.
>>
>>> +
>>> +#ifdef CONFIG_PM
>>> +static int stm_runtime_suspend(struct device *dev)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev);
>>> +
>>> +       if (drvdata && !IS_ERR(drvdata->atclk))
>>> +               clk_disable_unprepare(drvdata->atclk);
>>> +
>>> +       return 0;
>>> +}
>>> +
>>> +static int stm_runtime_resume(struct device *dev)
>>> +{
>>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev);
>>> +
>>> +       if (drvdata && !IS_ERR(drvdata->atclk))
>>> +               clk_prepare_enable(drvdata->atclk);
>>> +
>>> +       return 0;
>>> +}
>>> +#endif
>>> +
>>> +static const struct dev_pm_ops stm_dev_pm_ops = {
>>> +       SET_RUNTIME_PM_OPS(stm_runtime_suspend, stm_runtime_resume, NULL)
>>> +};
>>> +
>>> +static struct amba_id stm_ids[] = {
>>> +       {
>>> +               .id     = 0x0003b962,
>>> +               .mask   = 0x0003ffff,
>>> +               .data   = "STM32",
>>> +       },
>>> +       { 0, 0},
>>> +};
>>> +
>>> +static struct amba_driver stm_driver = {
>>> +       .drv = {
>>> +               .name   = "coresight-stm",
>>> +               .owner  = THIS_MODULE,
>>> +               .pm     = &stm_dev_pm_ops,
>>> +       },
>>> +       .probe          = stm_probe,
>>> +       .remove         = stm_remove,
>>> +       .id_table       = stm_ids,
>>> +};
>>> +
>>> +module_amba_driver(stm_driver);
>>> +
>>> +MODULE_LICENSE("GPL v2");
>>> +MODULE_DESCRIPTION("CoreSight System Trace Macrocell driver");
>>> diff --git a/include/linux/coresight-stm.h b/include/linux/coresight-stm.h
>>> new file mode 100644
>>> index 0000000..a978bb8
>>> --- /dev/null
>>> +++ b/include/linux/coresight-stm.h
>>> @@ -0,0 +1,6 @@
>>> +#ifndef __LINUX_CORESIGHT_STM_H_
>>> +#define __LINUX_CORESIGHT_STM_H_
>>> +
>>> +#include <uapi/linux/coresight-stm.h>
>>> +
>>> +#endif
>>> diff --git a/include/uapi/linux/coresight-stm.h b/include/uapi/linux/coresight-stm.h
>>> new file mode 100644
>>> index 0000000..fa35f0b
>>> --- /dev/null
>>> +++ b/include/uapi/linux/coresight-stm.h
>>> @@ -0,0 +1,12 @@
>>> +#ifndef __UAPI_CORESIGHT_STM_H_
>>> +#define __UAPI_CORESIGHT_STM_H_
>>> +
>>> +#define STM_FLAG_TIMESTAMPED   BIT(3)
>>> +#define STM_FLAG_GUARANTEED    BIT(7)
>>> +
>>> +enum {
>>> +       STM_OPTION_GUARANTEED = 0,
>>> +       STM_OPTION_INVARIANT,
>>> +};
>>> +
>>> +#endif
>>> --
>>> 1.9.1
>>>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


From fengguang.wu at intel.com  Tue Feb 16 19:22:07 2016
From: fengguang.wu at intel.com (kbuild test robot)
Date: Wed, 17 Feb 2016 11:22:07 +0800
Subject: [clk:clk-samsung-kconfig 2/2] drivers/clk/samsung/clk.h:142:17:
 error: invalid operands to binary | (have 'struct samsung_pll_clock *' and
 'struct samsung_pll_clock *')
Message-ID: <201602171104.YkeaxmIS%fengguang.wu@intel.com>

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-samsung-kconfig
head:   e83cb468452c25597e868d1ed778fa73fdaeca4c
commit: e83cb468452c25597e868d1ed778fa73fdaeca4c [2/2] clk: samsung: Don't build ARMv8 clock drivers on ARMv7
config: mips-allmodconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout e83cb468452c25597e868d1ed778fa73fdaeca4c
        # save the attached .config to linux build tree
        make.cross ARCH=mips 

All errors (new ones prefixed by >>):

   drivers/clk/samsung/clk-exynos5433.c:3178:7: note: (near initialization for 'bus2_gate_clks[2].flags')
       1, CLK_IGNORE_UNUSED, 0),
          ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3176:2: note: in expansion of macro 'GATE'
     GATE(CLK_ACLK_BUS2BEND_400, "aclk_bus2bend_400",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3181:7: error: initializer element is not constant
       0, CLK_IGNORE_UNUSED, 0),
          ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3179:2: note: in expansion of macro 'GATE'
     GATE(CLK_ACLK_BUS2RTND_400, "aclk_bus2rtnd_400",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3181:7: note: (near initialization for 'bus2_gate_clks[3].flags')
       0, CLK_IGNORE_UNUSED, 0),
          ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3179:2: note: in expansion of macro 'GATE'
     GATE(CLK_ACLK_BUS2RTND_400, "aclk_bus2rtnd_400",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3187:24: error: initializer element is not constant
       ENABLE_PCLK_BUS, 1, CLK_IGNORE_UNUSED, 0),
                           ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3186:2: note: in expansion of macro 'GATE'
     GATE(CLK_PCLK_PMU_BUS, "pclk_pmu_bus2", "div_pclk_bus2_133",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3187:24: note: (near initialization for 'bus2_gate_clks[5].flags')
       ENABLE_PCLK_BUS, 1, CLK_IGNORE_UNUSED, 0),
                           ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3186:2: note: in expansion of macro 'GATE'
     GATE(CLK_PCLK_PMU_BUS, "pclk_pmu_bus2", "div_pclk_bus2_133",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3189:24: error: initializer element is not constant
       ENABLE_PCLK_BUS, 0, CLK_IGNORE_UNUSED, 0),
                           ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3188:2: note: in expansion of macro 'GATE'
     GATE(CLK_PCLK_SYSREG_BUS, "pclk_sysreg_bus2", "div_pclk_bus2_133",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3189:24: note: (near initialization for 'bus2_gate_clks[6].flags')
       ENABLE_PCLK_BUS, 0, CLK_IGNORE_UNUSED, 0),
                           ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3188:2: note: in expansion of macro 'GATE'
     GATE(CLK_PCLK_SYSREG_BUS, "pclk_sysreg_bus2", "div_pclk_bus2_133",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3225:3: error: expected ')' before string constant
      "samsung,exynos5433-cmu-bus"#id,   \
      ^
   drivers/clk/samsung/clk-exynos5433.c:3228:1: note: in expansion of macro 'exynos5433_cmu_bus_init'
    exynos5433_cmu_bus_init(0);
    ^
   drivers/clk/samsung/clk-exynos5433.c:3225:3: error: expected ')' before string constant
      "samsung,exynos5433-cmu-bus"#id,   \
      ^
   drivers/clk/samsung/clk-exynos5433.c:3229:1: note: in expansion of macro 'exynos5433_cmu_bus_init'
    exynos5433_cmu_bus_init(1);
    ^
   drivers/clk/samsung/clk-exynos5433.c:3225:3: error: expected ')' before string constant
      "samsung,exynos5433-cmu-bus"#id,   \
      ^
   drivers/clk/samsung/clk-exynos5433.c:3230:1: note: in expansion of macro 'exynos5433_cmu_bus_init'
    exynos5433_cmu_bus_init(2);
    ^
   In file included from drivers/clk/samsung/clk-exynos5433.c:17:0:
   drivers/clk/samsung/clk.h:309:13: error: initializer element is not constant
      .flags  = CLK_GET_RATE_NOCACHE,   \
                ^
   drivers/clk/samsung/clk.h:317:2: note: in expansion of macro '__PLL'
     __PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
     ^
   drivers/clk/samsung/clk-exynos5433.c:3282:2: note: in expansion of macro 'PLL'
     PLL(pll_35xx, CLK_FOUT_G3D_PLL, "fout_g3d_pll", "oscclk",
     ^
   drivers/clk/samsung/clk.h:309:13: note: (near initialization for 'g3d_pll_clks[0].flags')
      .flags  = CLK_GET_RATE_NOCACHE,   \
                ^
   drivers/clk/samsung/clk.h:317:2: note: in expansion of macro '__PLL'
     __PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
     ^
   drivers/clk/samsung/clk-exynos5433.c:3282:2: note: in expansion of macro 'PLL'
     PLL(pll_35xx, CLK_FOUT_G3D_PLL, "fout_g3d_pll", "oscclk",
     ^
>> drivers/clk/samsung/clk.h:142:17: error: invalid operands to binary | (have 'struct samsung_pll_clock *' and 'struct samsung_pll_clock *')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                    ^
   drivers/clk/samsung/clk.h:157:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, f, mf, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3288:2: note: in expansion of macro 'MUX_F'
     MUX_F(CLK_MOUT_ACLK_G3D_400, "mout_aclk_g3d_400", mout_aclk_g3d_400_p,
     ^
   drivers/clk/samsung/clk.h:142:13: error: initializer element is not constant
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                ^
   drivers/clk/samsung/clk.h:157:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, f, mf, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3288:2: note: in expansion of macro 'MUX_F'
     MUX_F(CLK_MOUT_ACLK_G3D_400, "mout_aclk_g3d_400", mout_aclk_g3d_400_p,
     ^
   drivers/clk/samsung/clk.h:142:13: note: (near initialization for 'g3d_mux_clks[0].flags')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                ^
   drivers/clk/samsung/clk.h:157:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, f, mf, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3288:2: note: in expansion of macro 'MUX_F'
     MUX_F(CLK_MOUT_ACLK_G3D_400, "mout_aclk_g3d_400", mout_aclk_g3d_400_p,
     ^
>> drivers/clk/samsung/clk.h:142:17: error: invalid operands to binary | (have 'struct samsung_pll_clock *' and 'struct samsung_pll_clock *')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                    ^
   drivers/clk/samsung/clk.h:157:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, f, mf, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3290:2: note: in expansion of macro 'MUX_F'
     MUX_F(CLK_MOUT_G3D_PLL, "mout_g3d_pll", mout_g3d_pll_p,
     ^
   drivers/clk/samsung/clk.h:142:13: error: initializer element is not constant
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                ^
   drivers/clk/samsung/clk.h:157:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, f, mf, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3290:2: note: in expansion of macro 'MUX_F'
     MUX_F(CLK_MOUT_G3D_PLL, "mout_g3d_pll", mout_g3d_pll_p,
     ^
   drivers/clk/samsung/clk.h:142:13: note: (near initialization for 'g3d_mux_clks[1].flags')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                ^
   drivers/clk/samsung/clk.h:157:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, f, mf, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3290:2: note: in expansion of macro 'MUX_F'
     MUX_F(CLK_MOUT_G3D_PLL, "mout_g3d_pll", mout_g3d_pll_p,
     ^
   drivers/clk/samsung/clk-exynos5433.c:3301:10: error: initializer element is not constant
       0, 3, CLK_SET_RATE_PARENT, 0),
             ^
   drivers/clk/samsung/clk.h:194:13: note: in definition of macro '__DIV'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3300:2: note: in expansion of macro 'DIV_F'
     DIV_F(CLK_DIV_ACLK_G3D, "div_aclk_g3d", "mout_aclk_g3d_400", DIV_G3D,
     ^
   drivers/clk/samsung/clk-exynos5433.c:3301:10: note: (near initialization for 'g3d_div_clks[2].flags')
       0, 3, CLK_SET_RATE_PARENT, 0),
             ^
   drivers/clk/samsung/clk.h:194:13: note: in definition of macro '__DIV'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3300:2: note: in expansion of macro 'DIV_F'
     DIV_F(CLK_DIV_ACLK_G3D, "div_aclk_g3d", "mout_aclk_g3d_400", DIV_G3D,
     ^
   drivers/clk/samsung/clk-exynos5433.c:3311:24: error: initializer element is not constant
       ENABLE_ACLK_G3D, 5, CLK_IGNORE_UNUSED, 0),
                           ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3310:2: note: in expansion of macro 'GATE'
     GATE(CLK_ACLK_ASYNCAPBS_G3D, "aclk_asyncapbs_g3d", "div_pclk_g3d",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3311:24: note: (near initialization for 'g3d_gate_clks[2].flags')
       ENABLE_ACLK_G3D, 5, CLK_IGNORE_UNUSED, 0),
                           ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3310:2: note: in expansion of macro 'GATE'
     GATE(CLK_ACLK_ASYNCAPBS_G3D, "aclk_asyncapbs_g3d", "div_pclk_g3d",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3313:24: error: initializer element is not constant
       ENABLE_ACLK_G3D, 4, CLK_IGNORE_UNUSED, 0),
                           ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3312:2: note: in expansion of macro 'GATE'
     GATE(CLK_ACLK_ASYNCAPBM_G3D, "aclk_asyncapbm_g3d", "div_aclk_g3d",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3313:24: note: (near initialization for 'g3d_gate_clks[3].flags')
       ENABLE_ACLK_G3D, 4, CLK_IGNORE_UNUSED, 0),
                           ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3312:2: note: in expansion of macro 'GATE'
     GATE(CLK_ACLK_ASYNCAPBM_G3D, "aclk_asyncapbm_g3d", "div_aclk_g3d",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3315:24: error: initializer element is not constant
       ENABLE_ACLK_G3D, 3, CLK_IGNORE_UNUSED, 0),
                           ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3314:2: note: in expansion of macro 'GATE'
     GATE(CLK_ACLK_AHB2APB_G3DP, "aclk_ahb2apb_g3dp", "div_pclk_g3d",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3315:24: note: (near initialization for 'g3d_gate_clks[4].flags')
       ENABLE_ACLK_G3D, 3, CLK_IGNORE_UNUSED, 0),
                           ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3314:2: note: in expansion of macro 'GATE'
     GATE(CLK_ACLK_AHB2APB_G3DP, "aclk_ahb2apb_g3dp", "div_pclk_g3d",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3317:24: error: initializer element is not constant
       ENABLE_ACLK_G3D, 2, CLK_IGNORE_UNUSED, 0),
--
   drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3406:2: note: in expansion of macro 'MUX'
     MUX(CLK_MOUT_ACLK_GSCL_333_USER, "mout_aclk_gscl_333_user",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3420:7: error: initializer element is not constant
       8, CLK_IGNORE_UNUSED, 0),
          ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3418:2: note: in expansion of macro 'GATE'
     GATE(CLK_ACLK_AHB2APB_GSCLP, "aclk_ahb2apb_gsclp",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3420:7: note: (near initialization for 'gscl_gate_clks[3].flags')
       8, CLK_IGNORE_UNUSED, 0),
          ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3418:2: note: in expansion of macro 'GATE'
     GATE(CLK_ACLK_AHB2APB_GSCLP, "aclk_ahb2apb_gsclp",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3424:25: error: initializer element is not constant
       ENABLE_ACLK_GSCL, 6, CLK_IGNORE_UNUSED, 0),
                            ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3423:2: note: in expansion of macro 'GATE'
     GATE(CLK_ACLK_GSCLNP_111, "aclk_gsclnp_111", "mout_aclk_gscl_111_user",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3424:25: note: (near initialization for 'gscl_gate_clks[5].flags')
       ENABLE_ACLK_GSCL, 6, CLK_IGNORE_UNUSED, 0),
                            ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3423:2: note: in expansion of macro 'GATE'
     GATE(CLK_ACLK_GSCLNP_111, "aclk_gsclnp_111", "mout_aclk_gscl_111_user",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3458:25: error: initializer element is not constant
       ENABLE_PCLK_GSCL, 4, CLK_IGNORE_UNUSED, 0),
                            ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3457:2: note: in expansion of macro 'GATE'
     GATE(CLK_PCLK_PMU_GSCL, "pclk_pmu_gscl", "mout_aclk_gscl_111_user",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3458:25: note: (near initialization for 'gscl_gate_clks[18].flags')
       ENABLE_PCLK_GSCL, 4, CLK_IGNORE_UNUSED, 0),
                            ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3457:2: note: in expansion of macro 'GATE'
     GATE(CLK_PCLK_PMU_GSCL, "pclk_pmu_gscl", "mout_aclk_gscl_111_user",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3461:7: error: initializer element is not constant
       3, CLK_IGNORE_UNUSED, 0),
          ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3459:2: note: in expansion of macro 'GATE'
     GATE(CLK_PCLK_SYSREG_GSCL, "pclk_sysreg_gscl",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3461:7: note: (near initialization for 'gscl_gate_clks[19].flags')
       3, CLK_IGNORE_UNUSED, 0),
          ^
   drivers/clk/samsung/clk.h:245:13: note: in definition of macro '__GATE'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3459:2: note: in expansion of macro 'GATE'
     GATE(CLK_PCLK_SYSREG_GSCL, "pclk_sysreg_gscl",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3496:37: error: expected ')' before string constant
    CLK_OF_DECLARE(exynos5433_cmu_gscl, "samsung,exynos5433-cmu-gscl",
                                        ^
   In file included from drivers/clk/samsung/clk-exynos5433.c:17:0:
   drivers/clk/samsung/clk.h:309:13: error: initializer element is not constant
      .flags  = CLK_GET_RATE_NOCACHE,   \
                ^
   drivers/clk/samsung/clk.h:317:2: note: in expansion of macro '__PLL'
     __PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
     ^
   drivers/clk/samsung/clk-exynos5433.c:3577:2: note: in expansion of macro 'PLL'
     PLL(pll_35xx, CLK_FOUT_APOLLO_PLL, "fout_apollo_pll", "oscclk",
     ^
   drivers/clk/samsung/clk.h:309:13: note: (near initialization for 'apollo_pll_clks[0].flags')
      .flags  = CLK_GET_RATE_NOCACHE,   \
                ^
   drivers/clk/samsung/clk.h:317:2: note: in expansion of macro '__PLL'
     __PLL(_typ, _id, NULL, _name, _pname, CLK_GET_RATE_NOCACHE, \
     ^
   drivers/clk/samsung/clk-exynos5433.c:3577:2: note: in expansion of macro 'PLL'
     PLL(pll_35xx, CLK_FOUT_APOLLO_PLL, "fout_apollo_pll", "oscclk",
     ^
>> drivers/clk/samsung/clk.h:142:17: error: invalid operands to binary | (have 'struct samsung_pll_clock *' and 'struct samsung_pll_clock *')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                    ^
   drivers/clk/samsung/clk.h:157:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, f, mf, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3583:2: note: in expansion of macro 'MUX_F'
     MUX_F(CLK_MOUT_APOLLO_PLL, "mout_apollo_pll", mout_apollo_pll_p,
     ^
   drivers/clk/samsung/clk.h:142:13: error: initializer element is not constant
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                ^
   drivers/clk/samsung/clk.h:157:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, f, mf, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3583:2: note: in expansion of macro 'MUX_F'
     MUX_F(CLK_MOUT_APOLLO_PLL, "mout_apollo_pll", mout_apollo_pll_p,
     ^
   drivers/clk/samsung/clk.h:142:13: note: (near initialization for 'apollo_mux_clks[0].flags')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                ^
   drivers/clk/samsung/clk.h:157:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, f, mf, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3583:2: note: in expansion of macro 'MUX_F'
     MUX_F(CLK_MOUT_APOLLO_PLL, "mout_apollo_pll", mout_apollo_pll_p,
     ^
   drivers/clk/samsung/clk.h:142:17: error: invalid operands to binary | (have 'int' and 'struct samsung_pll_clock *')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                    ^
   drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3587:2: note: in expansion of macro 'MUX'
     MUX(CLK_MOUT_BUS_PLL_APOLLO_USER, "mout_bus_pll_apollo_user",
     ^
   drivers/clk/samsung/clk.h:142:13: error: initializer element is not constant
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                ^
   drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3587:2: note: in expansion of macro 'MUX'
     MUX(CLK_MOUT_BUS_PLL_APOLLO_USER, "mout_bus_pll_apollo_user",
     ^
   drivers/clk/samsung/clk.h:142:13: note: (near initialization for 'apollo_mux_clks[1].flags')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                ^
   drivers/clk/samsung/clk.h:151:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3587:2: note: in expansion of macro 'MUX'
     MUX(CLK_MOUT_BUS_PLL_APOLLO_USER, "mout_bus_pll_apollo_user",
     ^
>> drivers/clk/samsung/clk.h:142:17: error: invalid operands to binary | (have 'struct samsung_pll_clock *' and 'struct samsung_pll_clock *')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                    ^
   drivers/clk/samsung/clk.h:157:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, f, mf, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3591:2: note: in expansion of macro 'MUX_F'
     MUX_F(CLK_MOUT_APOLLO, "mout_apollo", mout_apollo_p, MUX_SEL_APOLLO2,
     ^
   drivers/clk/samsung/clk.h:142:13: error: initializer element is not constant
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                ^
   drivers/clk/samsung/clk.h:157:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, f, mf, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3591:2: note: in expansion of macro 'MUX_F'
     MUX_F(CLK_MOUT_APOLLO, "mout_apollo", mout_apollo_p, MUX_SEL_APOLLO2,
     ^
   drivers/clk/samsung/clk.h:142:13: note: (near initialization for 'apollo_mux_clks[2].flags')
      .flags  = (f) | CLK_SET_RATE_NO_REPARENT, \
                ^
   drivers/clk/samsung/clk.h:157:2: note: in expansion of macro '__MUX'
     __MUX(_id, NULL, cname, pnames, o, s, w, f, mf, NULL)
     ^
   drivers/clk/samsung/clk-exynos5433.c:3591:2: note: in expansion of macro 'MUX_F'
     MUX_F(CLK_MOUT_APOLLO, "mout_apollo", mout_apollo_p, MUX_SEL_APOLLO2,
     ^
   drivers/clk/samsung/clk-exynos5433.c:3598:24: error: initializer element is not constant
       DIV_APOLLO0, 24, 3, CLK_GET_RATE_NOCACHE,
                           ^
   drivers/clk/samsung/clk.h:194:13: note: in definition of macro '__DIV'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3597:2: note: in expansion of macro 'DIV_F'
     DIV_F(CLK_DIV_CNTCLK_APOLLO, "div_cntclk_apollo", "div_apollo2",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3598:24: note: (near initialization for 'apollo_div_clks[0].flags')
       DIV_APOLLO0, 24, 3, CLK_GET_RATE_NOCACHE,
                           ^
   drivers/clk/samsung/clk.h:194:13: note: in definition of macro '__DIV'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3597:2: note: in expansion of macro 'DIV_F'
     DIV_F(CLK_DIV_CNTCLK_APOLLO, "div_cntclk_apollo", "div_apollo2",
     ^
>> drivers/clk/samsung/clk-exynos5433.c:3599:4: error: 'CLK_DIVIDER_READ_ONLY' undeclared here (not in a function)
       CLK_DIVIDER_READ_ONLY),
       ^
   drivers/clk/samsung/clk.h:198:16: note: in definition of macro '__DIV'
      .div_flags = df,    \
                   ^
   drivers/clk/samsung/clk-exynos5433.c:3597:2: note: in expansion of macro 'DIV_F'
     DIV_F(CLK_DIV_CNTCLK_APOLLO, "div_cntclk_apollo", "div_apollo2",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3599:4: error: initializer element is not constant
       CLK_DIVIDER_READ_ONLY),
       ^
   drivers/clk/samsung/clk.h:198:16: note: in definition of macro '__DIV'
      .div_flags = df,    \
                   ^
   drivers/clk/samsung/clk-exynos5433.c:3597:2: note: in expansion of macro 'DIV_F'
     DIV_F(CLK_DIV_CNTCLK_APOLLO, "div_cntclk_apollo", "div_apollo2",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3599:4: note: (near initialization for 'apollo_div_clks[0].div_flags')
       CLK_DIVIDER_READ_ONLY),
       ^
   drivers/clk/samsung/clk.h:198:16: note: in definition of macro '__DIV'
      .div_flags = df,    \
                   ^
   drivers/clk/samsung/clk-exynos5433.c:3597:2: note: in expansion of macro 'DIV_F'
     DIV_F(CLK_DIV_CNTCLK_APOLLO, "div_cntclk_apollo", "div_apollo2",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3601:24: error: initializer element is not constant
       DIV_APOLLO0, 20, 3, CLK_GET_RATE_NOCACHE,
                           ^
   drivers/clk/samsung/clk.h:194:13: note: in definition of macro '__DIV'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3600:2: note: in expansion of macro 'DIV_F'
     DIV_F(CLK_DIV_PCLK_DBG_APOLLO, "div_pclk_dbg_apollo", "div_apollo2",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3601:24: note: (near initialization for 'apollo_div_clks[1].flags')
       DIV_APOLLO0, 20, 3, CLK_GET_RATE_NOCACHE,
                           ^
   drivers/clk/samsung/clk.h:194:13: note: in definition of macro '__DIV'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3600:2: note: in expansion of macro 'DIV_F'
     DIV_F(CLK_DIV_PCLK_DBG_APOLLO, "div_pclk_dbg_apollo", "div_apollo2",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3602:4: error: initializer element is not constant
       CLK_DIVIDER_READ_ONLY),
       ^
   drivers/clk/samsung/clk.h:198:16: note: in definition of macro '__DIV'
      .div_flags = df,    \
                   ^
   drivers/clk/samsung/clk-exynos5433.c:3600:2: note: in expansion of macro 'DIV_F'
     DIV_F(CLK_DIV_PCLK_DBG_APOLLO, "div_pclk_dbg_apollo", "div_apollo2",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3602:4: note: (near initialization for 'apollo_div_clks[1].div_flags')
       CLK_DIVIDER_READ_ONLY),
       ^
   drivers/clk/samsung/clk.h:198:16: note: in definition of macro '__DIV'
      .div_flags = df,    \
                   ^
   drivers/clk/samsung/clk-exynos5433.c:3600:2: note: in expansion of macro 'DIV_F'
     DIV_F(CLK_DIV_PCLK_DBG_APOLLO, "div_pclk_dbg_apollo", "div_apollo2",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3604:24: error: initializer element is not constant
       DIV_APOLLO0, 16, 3, CLK_GET_RATE_NOCACHE,
                           ^
   drivers/clk/samsung/clk.h:194:13: note: in definition of macro '__DIV'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3603:2: note: in expansion of macro 'DIV_F'
     DIV_F(CLK_DIV_ATCLK_APOLLO, "div_atclk_apollo", "div_apollo2",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3604:24: note: (near initialization for 'apollo_div_clks[2].flags')
       DIV_APOLLO0, 16, 3, CLK_GET_RATE_NOCACHE,
                           ^
   drivers/clk/samsung/clk.h:194:13: note: in definition of macro '__DIV'
      .flags  = f,    \
                ^
   drivers/clk/samsung/clk-exynos5433.c:3603:2: note: in expansion of macro 'DIV_F'
     DIV_F(CLK_DIV_ATCLK_APOLLO, "div_atclk_apollo", "div_apollo2",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3605:4: error: initializer element is not constant
       CLK_DIVIDER_READ_ONLY),
       ^
   drivers/clk/samsung/clk.h:198:16: note: in definition of macro '__DIV'
      .div_flags = df,    \
                   ^
   drivers/clk/samsung/clk-exynos5433.c:3603:2: note: in expansion of macro 'DIV_F'
     DIV_F(CLK_DIV_ATCLK_APOLLO, "div_atclk_apollo", "div_apollo2",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3605:4: note: (near initialization for 'apollo_div_clks[2].div_flags')
       CLK_DIVIDER_READ_ONLY),
       ^
   drivers/clk/samsung/clk.h:198:16: note: in definition of macro '__DIV'
      .div_flags = df,    \
                   ^
   drivers/clk/samsung/clk-exynos5433.c:3603:2: note: in expansion of macro 'DIV_F'
     DIV_F(CLK_DIV_ATCLK_APOLLO, "div_atclk_apollo", "div_apollo2",
     ^
   drivers/clk/samsung/clk-exynos5433.c:3607:24: error: initializer element is not constant
       DIV_APOLLO0, 12, 3, CLK_GET_RATE_NOCACHE,
..

vim +142 drivers/clk/samsung/clk.h

721c42a3 Thomas Abraham       2013-03-09  136  	{							\
721c42a3 Thomas Abraham       2013-03-09  137  		.id		= _id,				\
721c42a3 Thomas Abraham       2013-03-09  138  		.dev_name	= dname,			\
721c42a3 Thomas Abraham       2013-03-09  139  		.name		= cname,			\
721c42a3 Thomas Abraham       2013-03-09  140  		.parent_names	= pnames,			\
721c42a3 Thomas Abraham       2013-03-09  141  		.num_parents	= ARRAY_SIZE(pnames),		\
819c1de3 James Hogan          2013-07-29 @142  		.flags		= (f) | CLK_SET_RATE_NO_REPARENT, \
721c42a3 Thomas Abraham       2013-03-09  143  		.offset		= o,				\
721c42a3 Thomas Abraham       2013-03-09  144  		.shift		= s,				\
721c42a3 Thomas Abraham       2013-03-09  145  		.width		= w,				\
721c42a3 Thomas Abraham       2013-03-09  146  		.mux_flags	= mf,				\
721c42a3 Thomas Abraham       2013-03-09  147  		.alias		= a,				\
721c42a3 Thomas Abraham       2013-03-09  148  	}
721c42a3 Thomas Abraham       2013-03-09  149  
721c42a3 Thomas Abraham       2013-03-09  150  #define MUX(_id, cname, pnames, o, s, w)			\
721c42a3 Thomas Abraham       2013-03-09  151  	__MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, NULL)
721c42a3 Thomas Abraham       2013-03-09  152  
721c42a3 Thomas Abraham       2013-03-09  153  #define MUX_A(_id, cname, pnames, o, s, w, a)			\
721c42a3 Thomas Abraham       2013-03-09  154  	__MUX(_id, NULL, cname, pnames, o, s, w, 0, 0, a)
721c42a3 Thomas Abraham       2013-03-09  155  
721c42a3 Thomas Abraham       2013-03-09  156  #define MUX_F(_id, cname, pnames, o, s, w, f, mf)		\
721c42a3 Thomas Abraham       2013-03-09  157  	__MUX(_id, NULL, cname, pnames, o, s, w, f, mf, NULL)
721c42a3 Thomas Abraham       2013-03-09  158  
41ccf7f2 Tushar Behera        2013-06-20  159  #define MUX_FA(_id, cname, pnames, o, s, w, f, mf, a)		\
41ccf7f2 Tushar Behera        2013-06-20  160  	__MUX(_id, NULL, cname, pnames, o, s, w, f, mf, a)
41ccf7f2 Tushar Behera        2013-06-20  161  
721c42a3 Thomas Abraham       2013-03-09  162  /**
721c42a3 Thomas Abraham       2013-03-09  163   * @id: platform specific id of the clock.
721c42a3 Thomas Abraham       2013-03-09  164   * struct samsung_div_clock: information about div clock
721c42a3 Thomas Abraham       2013-03-09  165   * @dev_name: name of the device to which this clock belongs.
721c42a3 Thomas Abraham       2013-03-09  166   * @name: name of this div clock.
721c42a3 Thomas Abraham       2013-03-09  167   * @parent_name: name of the parent clock.
721c42a3 Thomas Abraham       2013-03-09  168   * @flags: optional flags for basic clock.
721c42a3 Thomas Abraham       2013-03-09  169   * @offset: offset of the register for configuring the div.
721c42a3 Thomas Abraham       2013-03-09  170   * @shift: starting bit location of the div control bit-field in @reg.
721c42a3 Thomas Abraham       2013-03-09  171   * @div_flags: flags for div-type clock.
721c42a3 Thomas Abraham       2013-03-09  172   * @alias: optional clock alias name to be assigned to this clock.
721c42a3 Thomas Abraham       2013-03-09  173   */
721c42a3 Thomas Abraham       2013-03-09  174  struct samsung_div_clock {
721c42a3 Thomas Abraham       2013-03-09  175  	unsigned int		id;
721c42a3 Thomas Abraham       2013-03-09  176  	const char		*dev_name;
721c42a3 Thomas Abraham       2013-03-09  177  	const char		*name;
721c42a3 Thomas Abraham       2013-03-09  178  	const char		*parent_name;
721c42a3 Thomas Abraham       2013-03-09  179  	unsigned long		flags;
721c42a3 Thomas Abraham       2013-03-09  180  	unsigned long		offset;
721c42a3 Thomas Abraham       2013-03-09  181  	u8			shift;
721c42a3 Thomas Abraham       2013-03-09  182  	u8			width;
721c42a3 Thomas Abraham       2013-03-09  183  	u8			div_flags;
721c42a3 Thomas Abraham       2013-03-09  184  	const char		*alias;
798ed613 Heiko Stuebner       2013-03-18  185  	struct clk_div_table	*table;
721c42a3 Thomas Abraham       2013-03-09  186  };
721c42a3 Thomas Abraham       2013-03-09  187  
798ed613 Heiko Stuebner       2013-03-18  188  #define __DIV(_id, dname, cname, pname, o, s, w, f, df, a, t)	\
721c42a3 Thomas Abraham       2013-03-09  189  	{							\
721c42a3 Thomas Abraham       2013-03-09  190  		.id		= _id,				\
721c42a3 Thomas Abraham       2013-03-09  191  		.dev_name	= dname,			\
721c42a3 Thomas Abraham       2013-03-09  192  		.name		= cname,			\
721c42a3 Thomas Abraham       2013-03-09  193  		.parent_name	= pname,			\
721c42a3 Thomas Abraham       2013-03-09  194  		.flags		= f,				\
721c42a3 Thomas Abraham       2013-03-09  195  		.offset		= o,				\
721c42a3 Thomas Abraham       2013-03-09  196  		.shift		= s,				\
721c42a3 Thomas Abraham       2013-03-09  197  		.width		= w,				\
721c42a3 Thomas Abraham       2013-03-09  198  		.div_flags	= df,				\
721c42a3 Thomas Abraham       2013-03-09  199  		.alias		= a,				\
798ed613 Heiko Stuebner       2013-03-18  200  		.table		= t,				\
721c42a3 Thomas Abraham       2013-03-09  201  	}
721c42a3 Thomas Abraham       2013-03-09  202  
721c42a3 Thomas Abraham       2013-03-09  203  #define DIV(_id, cname, pname, o, s, w)				\
798ed613 Heiko Stuebner       2013-03-18  204  	__DIV(_id, NULL, cname, pname, o, s, w, 0, 0, NULL, NULL)
721c42a3 Thomas Abraham       2013-03-09  205  
721c42a3 Thomas Abraham       2013-03-09  206  #define DIV_A(_id, cname, pname, o, s, w, a)			\
798ed613 Heiko Stuebner       2013-03-18  207  	__DIV(_id, NULL, cname, pname, o, s, w, 0, 0, a, NULL)
721c42a3 Thomas Abraham       2013-03-09  208  
721c42a3 Thomas Abraham       2013-03-09  209  #define DIV_F(_id, cname, pname, o, s, w, f, df)		\
798ed613 Heiko Stuebner       2013-03-18  210  	__DIV(_id, NULL, cname, pname, o, s, w, f, df, NULL, NULL)
798ed613 Heiko Stuebner       2013-03-18  211  
798ed613 Heiko Stuebner       2013-03-18  212  #define DIV_T(_id, cname, pname, o, s, w, t)			\
798ed613 Heiko Stuebner       2013-03-18  213  	__DIV(_id, NULL, cname, pname, o, s, w, 0, 0, NULL, t)
721c42a3 Thomas Abraham       2013-03-09  214  
721c42a3 Thomas Abraham       2013-03-09  215  /**
721c42a3 Thomas Abraham       2013-03-09  216   * struct samsung_gate_clock: information about gate clock
721c42a3 Thomas Abraham       2013-03-09  217   * @id: platform specific id of the clock.
721c42a3 Thomas Abraham       2013-03-09  218   * @dev_name: name of the device to which this clock belongs.
721c42a3 Thomas Abraham       2013-03-09  219   * @name: name of this gate clock.
721c42a3 Thomas Abraham       2013-03-09  220   * @parent_name: name of the parent clock.
721c42a3 Thomas Abraham       2013-03-09  221   * @flags: optional flags for basic clock.
721c42a3 Thomas Abraham       2013-03-09  222   * @offset: offset of the register for configuring the gate.
721c42a3 Thomas Abraham       2013-03-09  223   * @bit_idx: bit index of the gate control bit-field in @reg.
721c42a3 Thomas Abraham       2013-03-09  224   * @gate_flags: flags for gate-type clock.
721c42a3 Thomas Abraham       2013-03-09  225   * @alias: optional clock alias name to be assigned to this clock.
721c42a3 Thomas Abraham       2013-03-09  226   */
721c42a3 Thomas Abraham       2013-03-09  227  struct samsung_gate_clock {
721c42a3 Thomas Abraham       2013-03-09  228  	unsigned int		id;
721c42a3 Thomas Abraham       2013-03-09  229  	const char		*dev_name;
721c42a3 Thomas Abraham       2013-03-09  230  	const char		*name;
721c42a3 Thomas Abraham       2013-03-09  231  	const char		*parent_name;
721c42a3 Thomas Abraham       2013-03-09  232  	unsigned long		flags;
721c42a3 Thomas Abraham       2013-03-09  233  	unsigned long		offset;
721c42a3 Thomas Abraham       2013-03-09  234  	u8			bit_idx;
721c42a3 Thomas Abraham       2013-03-09  235  	u8			gate_flags;
721c42a3 Thomas Abraham       2013-03-09  236  	const char		*alias;
721c42a3 Thomas Abraham       2013-03-09  237  };
721c42a3 Thomas Abraham       2013-03-09  238  
721c42a3 Thomas Abraham       2013-03-09  239  #define __GATE(_id, dname, cname, pname, o, b, f, gf, a)	\
721c42a3 Thomas Abraham       2013-03-09  240  	{							\
721c42a3 Thomas Abraham       2013-03-09  241  		.id		= _id,				\
721c42a3 Thomas Abraham       2013-03-09  242  		.dev_name	= dname,			\
721c42a3 Thomas Abraham       2013-03-09  243  		.name		= cname,			\
721c42a3 Thomas Abraham       2013-03-09  244  		.parent_name	= pname,			\
721c42a3 Thomas Abraham       2013-03-09  245  		.flags		= f,				\
721c42a3 Thomas Abraham       2013-03-09  246  		.offset		= o,				\
721c42a3 Thomas Abraham       2013-03-09  247  		.bit_idx	= b,				\
721c42a3 Thomas Abraham       2013-03-09  248  		.gate_flags	= gf,				\
721c42a3 Thomas Abraham       2013-03-09  249  		.alias		= a,				\
721c42a3 Thomas Abraham       2013-03-09  250  	}
721c42a3 Thomas Abraham       2013-03-09  251  
721c42a3 Thomas Abraham       2013-03-09  252  #define GATE(_id, cname, pname, o, b, f, gf)			\
721c42a3 Thomas Abraham       2013-03-09  253  	__GATE(_id, NULL, cname, pname, o, b, f, gf, NULL)
721c42a3 Thomas Abraham       2013-03-09  254  
721c42a3 Thomas Abraham       2013-03-09  255  #define GATE_A(_id, cname, pname, o, b, f, gf, a)		\
721c42a3 Thomas Abraham       2013-03-09  256  	__GATE(_id, NULL, cname, pname, o, b, f, gf, a)
721c42a3 Thomas Abraham       2013-03-09  257  
721c42a3 Thomas Abraham       2013-03-09  258  #define GATE_D(_id, dname, cname, pname, o, b, f, gf)		\
721c42a3 Thomas Abraham       2013-03-09  259  	__GATE(_id, dname, cname, pname, o, b, f, gf, NULL)
721c42a3 Thomas Abraham       2013-03-09  260  
721c42a3 Thomas Abraham       2013-03-09  261  #define GATE_DA(_id, dname, cname, pname, o, b, f, gf, a)	\
721c42a3 Thomas Abraham       2013-03-09  262  	__GATE(_id, dname, cname, pname, o, b, f, gf, a)
721c42a3 Thomas Abraham       2013-03-09  263  
721c42a3 Thomas Abraham       2013-03-09  264  #define PNAME(x) static const char *x[] __initdata
721c42a3 Thomas Abraham       2013-03-09  265  
721c42a3 Thomas Abraham       2013-03-09  266  /**
721c42a3 Thomas Abraham       2013-03-09  267   * struct samsung_clk_reg_dump: register dump of clock controller registers.
721c42a3 Thomas Abraham       2013-03-09  268   * @offset: clock register offset from the controller base address.
721c42a3 Thomas Abraham       2013-03-09  269   * @value: the value to be register at offset.
721c42a3 Thomas Abraham       2013-03-09  270   */
721c42a3 Thomas Abraham       2013-03-09  271  struct samsung_clk_reg_dump {
721c42a3 Thomas Abraham       2013-03-09  272  	u32	offset;
721c42a3 Thomas Abraham       2013-03-09  273  	u32	value;
721c42a3 Thomas Abraham       2013-03-09  274  };
721c42a3 Thomas Abraham       2013-03-09  275  
07dc76fa Yadwinder Singh Brar 2013-06-11  276  /**
07dc76fa Yadwinder Singh Brar 2013-06-11  277   * struct samsung_pll_clock: information about pll clock
07dc76fa Yadwinder Singh Brar 2013-06-11  278   * @id: platform specific id of the clock.
07dc76fa Yadwinder Singh Brar 2013-06-11  279   * @dev_name: name of the device to which this clock belongs.
07dc76fa Yadwinder Singh Brar 2013-06-11  280   * @name: name of this pll clock.
07dc76fa Yadwinder Singh Brar 2013-06-11  281   * @parent_name: name of the parent clock.
07dc76fa Yadwinder Singh Brar 2013-06-11  282   * @flags: optional flags for basic clock.
07dc76fa Yadwinder Singh Brar 2013-06-11  283   * @con_offset: offset of the register for configuring the PLL.
07dc76fa Yadwinder Singh Brar 2013-06-11  284   * @lock_offset: offset of the register for locking the PLL.
07dc76fa Yadwinder Singh Brar 2013-06-11  285   * @type: Type of PLL to be registered.
07dc76fa Yadwinder Singh Brar 2013-06-11  286   * @alias: optional clock alias name to be assigned to this clock.
07dc76fa Yadwinder Singh Brar 2013-06-11  287   */
07dc76fa Yadwinder Singh Brar 2013-06-11  288  struct samsung_pll_clock {
07dc76fa Yadwinder Singh Brar 2013-06-11  289  	unsigned int		id;
07dc76fa Yadwinder Singh Brar 2013-06-11  290  	const char		*dev_name;
07dc76fa Yadwinder Singh Brar 2013-06-11  291  	const char		*name;
07dc76fa Yadwinder Singh Brar 2013-06-11  292  	const char		*parent_name;
07dc76fa Yadwinder Singh Brar 2013-06-11  293  	unsigned long		flags;
07dc76fa Yadwinder Singh Brar 2013-06-11  294  	int			con_offset;
07dc76fa Yadwinder Singh Brar 2013-06-11  295  	int			lock_offset;
07dc76fa Yadwinder Singh Brar 2013-06-11  296  	enum samsung_pll_type	type;
3ff6e0d8 Yadwinder Singh Brar 2013-06-11  297  	const struct samsung_pll_rate_table *rate_table;
07dc76fa Yadwinder Singh Brar 2013-06-11  298  	const char              *alias;
07dc76fa Yadwinder Singh Brar 2013-06-11  299  };
07dc76fa Yadwinder Singh Brar 2013-06-11  300  
3ff6e0d8 Yadwinder Singh Brar 2013-06-11  301  #define __PLL(_typ, _id, _dname, _name, _pname, _flags, _lock, _con,	\
3ff6e0d8 Yadwinder Singh Brar 2013-06-11  302  		_rtable, _alias)					\
07dc76fa Yadwinder Singh Brar 2013-06-11  303  	{								\
07dc76fa Yadwinder Singh Brar 2013-06-11  304  		.id		= _id,					\
07dc76fa Yadwinder Singh Brar 2013-06-11  305  		.type		= _typ,					\
07dc76fa Yadwinder Singh Brar 2013-06-11  306  		.dev_name	= _dname,				\
07dc76fa Yadwinder Singh Brar 2013-06-11  307  		.name		= _name,				\
07dc76fa Yadwinder Singh Brar 2013-06-11  308  		.parent_name	= _pname,				\
07dc76fa Yadwinder Singh Brar 2013-06-11 @309  		.flags		= CLK_GET_RATE_NOCACHE,			\
07dc76fa Yadwinder Singh Brar 2013-06-11  310  		.con_offset	= _con,					\
07dc76fa Yadwinder Singh Brar 2013-06-11  311  		.lock_offset	= _lock,				\
3ff6e0d8 Yadwinder Singh Brar 2013-06-11  312  		.rate_table	= _rtable,				\

:::::: The code at line 142 was first introduced by commit
:::::: 819c1de344c5b8350bffd35be9a0fa74541292d3 clk: add CLK_SET_RATE_NO_REPARENT flag

:::::: TO: James Hogan <james.hogan at imgtec.com>
:::::: CC: Mike Turquette <mturquette at linaro.org>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 40456 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/701f7c6c/attachment-0001.obj>

From linux at roeck-us.net  Tue Feb 16 19:37:45 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 16 Feb 2016 19:37:45 -0800
Subject: [PATCH v3 0/3] Allow iio_hwmon to accept hypen in node names
In-Reply-To: <cover.1455597464.git.maitysanchayan@gmail.com>
References: <cover.1455597464.git.maitysanchayan@gmail.com>
Message-ID: <56C3EB09.1050803@roeck-us.net>

On 02/15/2016 09:00 PM, Sanchayan Maity wrote:
> Hello,
>
> Initial versions of the patchset intended to introduce the use of
> iio_hwmon for Vybrid SoC's. Currently the iio_hwmon driver has two
> users and as per the binding documentation, the node names use the
> underscore. Use of hypen in device tree node names is acceptable,
> however currently the hwmon core code rejects it due to perhaps user
> space not liking the hypen and getting confused.
>
> As per Guenter Roeck's suggestion, the first patch looks for a hypen
> and replaces it with a underscore in the probe call of iio_hwmon driver
> before calling hwmon_device_register_with_groups for registration. Any
> users of iio_hwmon driver can now use hypen in the node name.
>
> As per Shawn's suggestion, the existing users have been changed to use
> the hypen instead of the underscore and the iio-bindings document
> updated. Third patch introduces the usage for Vybrid itself.
>
> Patchset is based on top of shawn's for-next branch.
>
> Feedbacks and comments most welcome. Thank you for feedbacks.
>
> @Guenter
> I hope I understood and implemented correctly what you had in mind.
>
Yes.

Series applied to hwmon-next (if the dts changes also end up in an arm branch,
no harm done).

Thanks,
Guenter



From k.kozlowski at samsung.com  Tue Feb 16 19:39:21 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 17 Feb 2016 12:39:21 +0900
Subject: [clk:clk-samsung-kconfig 2/2] drivers/clk/samsung/clk.h:142:17:
 error: invalid operands to binary | (have 'struct samsung_pll_clock *' and
 'struct samsung_pll_clock *')
In-Reply-To: <201602171104.YkeaxmIS%fengguang.wu@intel.com>
References: <201602171104.YkeaxmIS%fengguang.wu@intel.com>
Message-ID: <56C3EB69.2000307@samsung.com>

On 17.02.2016 12:22, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-samsung-kconfig
> head:   e83cb468452c25597e868d1ed778fa73fdaeca4c
> commit: e83cb468452c25597e868d1ed778fa73fdaeca4c [2/2] clk: samsung: Don't build ARMv8 clock drivers on ARMv7
> config: mips-allmodconfig (attached as .config)
> reproduce:
>         wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         git checkout e83cb468452c25597e868d1ed778fa73fdaeca4c
>         # save the attached .config to linux build tree
>         make.cross ARCH=mips 
> 

I think this is the same as previous - patch which added dependency on
CLK_COMMON is not present. My tests on MIPS passed fine. Also attached
configs builds fine with the dependency applied.

Best regards,
Krzysztof


From linux at roeck-us.net  Tue Feb 16 19:42:56 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Tue, 16 Feb 2016 19:42:56 -0800
Subject: [PATCH v13 4/4] Watchdog: introduce ARM SBSA watchdog driver
In-Reply-To: <1455642530-19103-5-git-send-email-fu.wei@linaro.org>
References: <1455642530-19103-1-git-send-email-fu.wei@linaro.org>
 <1455642530-19103-5-git-send-email-fu.wei@linaro.org>
Message-ID: <56C3EC40.6080500@roeck-us.net>

On 02/16/2016 09:08 AM, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei at linaro.org>
>
> According to Server Base System Architecture (SBSA) specification,
> the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0)
> is for alerting the system by interrupt, the second one (WS1) is a real
> hardware reset.
> More details about the hardware specification of this device:
> ARM DEN0029B - Server Base System Architecture (SBSA)
>
> This driver can operate ARM SBSA Generic Watchdog as a single stage watchdog
> or a two stages watchdog, it's set up by the module parameter "action".
> In the single stage mode, when the timeout is reached, your system
> will be reset by WS1. The first signal (WS0) is ignored.
> In the two stages mode, when the timeout is reached, the first signal (WS0)
> will trigger panic. If the system is getting into trouble and cannot be reset
> by panic or restart properly by the kdump kernel(if supported), then the
> second stage (as long as the first stage) will be reached, system will be
> reset by WS1. This function can help administrator to backup the system
> context info by panic console output or kdump.
>
> This driver bases on linux kernel watchdog framework, so it can get
> timeout from module parameter and FDT at the driver init stage.
>
> Signed-off-by: Fu Wei <fu.wei at linaro.org>
> Reviewed-by: Graeme Gregory <graeme.gregory at linaro.org>
> Tested-by: Pratyush Anand <panand at redhat.com>
> Acked-by: Timur Tabi <timur at codeaurora.org>
> Reviewed-by: Mathieu Poirier <mathieu.poirier at linaro.org>
> Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>

Reviewed-by: Guenter Roeck <linux at roeck-us.net>



From zhang.chunyan at linaro.org  Tue Feb 16 19:49:35 2016
From: zhang.chunyan at linaro.org (Chunyan Zhang)
Date: Wed, 17 Feb 2016 11:49:35 +0800
Subject: [PATCH V3 6/6] coresight-stm: adding driver for CoreSight STM
 component
In-Reply-To: <CANLsYkxvLFu1C+_H9c0EoMebLQu1gnwt9bqY6_R3j+ua2w+xMg@mail.gmail.com>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
 <1454756672-12790-7-git-send-email-zhang.chunyan@linaro.org>
 <CANLsYkxvLFu1C+_H9c0EoMebLQu1gnwt9bqY6_R3j+ua2w+xMg@mail.gmail.com>
Message-ID: <CAG2=9p8t=j4FfdOGZuCM=3abTcgjL7fiAk52x-+N2pZ+UEtM7A@mail.gmail.com>

On Fri, Feb 12, 2016 at 12:59 AM, Mathieu Poirier
<mathieu.poirier at linaro.org> wrote:
> On 6 February 2016 at 04:04, Chunyan Zhang <zhang.chunyan at linaro.org> wrote:
>> From: Pratik Patel <pratikp at codeaurora.org>
>>
>> This driver adds support for the STM CoreSight IP block, allowing any
>> system compoment (HW or SW) to log and aggregate messages via a
>> single entity.
>>
>> The CoreSight STM exposes an application defined number of channels
>> called stimulus port.  Configuration is done using entries in sysfs
>> and channels made available to userspace via configfs.
>>
>> Signed-off-by: Pratik Patel <pratikp at codeaurora.org>
>> Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
>> Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
>> ---
>>  .../ABI/testing/sysfs-bus-coresight-devices-stm    |  53 ++
>>  Documentation/trace/coresight.txt                  |  37 +-
>>  drivers/hwtracing/coresight/Kconfig                |  11 +
>>  drivers/hwtracing/coresight/Makefile               |   1 +
>>  drivers/hwtracing/coresight/coresight-stm.c        | 928 +++++++++++++++++++++
>>  include/linux/coresight-stm.h                      |   6 +
>>  include/uapi/linux/coresight-stm.h                 |  12 +
>>  7 files changed, 1046 insertions(+), 2 deletions(-)
>>  create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>>  create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
>>  create mode 100644 include/linux/coresight-stm.h
>>  create mode 100644 include/uapi/linux/coresight-stm.h
>>

[...]

>> +static int stm_send(void *addr, const void *data, u32 size, u8 max)
>> +{
>> +       u32 len = size;
>> +       u8 paload[8];
>> +
>> +       if (stm_addr_unaligned(data, max)) {
>> +               memcpy(paload, data, size);
>> +               data = paload;
>> +       }
>> +
>> +       /* now we are 64bit/32bit aligned */
>> +#ifdef CONFIG_64BIT
>> +       if (size == 8)
>> +               writeq_relaxed(*(u64 *)data, addr);
>> +#endif
>
> We probably don't need an #ifdef here.  Checking the size of the
> transfer against the fundamental data size will result in the same
> outcome, i.e preventing 64 bit transfers on a 32 bit architecture.  An
> error (understandable by the caller) should probably be returned in
> this case.

I think we still need this #ifdef, since this checking is only for
64-bit architecture, on 32-bit architecture it's unreachable, since if
the transfer data size on 32-bit architecture is larger than the
32-bit fundamental data size, it would be adjusted down in the caller
of this function.

>
>> +       if (size >= 4) {
>> +               writel_relaxed(*(u32 *)data, addr);
>> +               data += 4;
>> +               size -= 4;
>> +       }
>> +
>> +       if (size >= 2) {
>> +               writew_relaxed(*(u16 *)data, addr);
>> +               data += 2;
>> +               size -= 2;
>> +       }
>> +
>> +       if (size == 1)
>> +               writeb_relaxed(*(u8 *)data, addr);
>> +
>> +       return len;
>> +}
>> +
>> +static int stm_generic_link(struct stm_data *stm_data,
>> +                           unsigned int master,  unsigned int channel)
>> +{
>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>> +                                                  struct stm_drvdata, stm);
>> +       if (!drvdata || !drvdata->csdev)
>> +               return -EINVAL;
>> +
>> +       return coresight_enable(drvdata->csdev);
>> +}
>> +
>> +static void stm_generic_unlink(struct stm_data *stm_data,
>> +                              unsigned int master,  unsigned int channel)
>> +{
>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>> +                                                  struct stm_drvdata, stm);
>> +       if (!drvdata || !drvdata->csdev)
>> +               return;
>> +
>> +       stm_disable(drvdata->csdev);
>> +}
>> +
>> +static long stm_generic_set_options(struct stm_data *stm_data,
>> +                                   unsigned int master,
>> +                                   unsigned int channel,
>> +                                   unsigned int nr_chans,
>> +                                   unsigned long options)
>> +{
>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>> +                                                  struct stm_drvdata, stm);
>> +       if (!(drvdata && drvdata->enable))
>> +               return -EINVAL;
>> +
>> +       if (channel >= drvdata->numsp)
>> +               return -EINVAL;
>> +
>> +       switch (options) {
>> +       case STM_OPTION_GUARANTEED:
>> +               set_bit(channel, drvdata->chs.guaranteed);
>> +               break;
>> +
>> +       case STM_OPTION_INVARIANT:
>> +               clear_bit(channel, drvdata->chs.guaranteed);
>> +               break;
>> +
>> +       default:
>> +               return -EINVAL;
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static long stm_generic_get_options(struct stm_data *stm_data,
>> +                                   unsigned int master,
>> +                                   unsigned int channel,
>> +                                   unsigned int nr_chans,
>> +                                   u64 *options)
>> +{
>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>> +                                                  struct stm_drvdata, stm);
>> +       if (!(drvdata && drvdata->enable))
>> +               return -EINVAL;
>> +
>> +       if (channel >= drvdata->numsp)
>> +               return -EINVAL;
>> +
>> +       switch (*options) {
>> +       case STM_OPTION_GUARANTEED:
>> +               *options = test_bit(channel, drvdata->chs.guaranteed);
>> +               break;
>> +
>> +       default:
>> +               return -EINVAL;
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static ssize_t stm_generic_packet(struct stm_data *stm_data,
>> +                                 unsigned int master,
>> +                                 unsigned int channel,
>> +                                 unsigned int packet,
>> +                                 unsigned int flags,
>> +                                 unsigned int size,
>> +                                 const unsigned char *payload)
>> +{
>> +       unsigned long ch_addr;
>> +       struct stm_drvdata *drvdata = container_of(stm_data,
>> +                                                  struct stm_drvdata, stm);
>> +
>> +       if (!(drvdata && drvdata->enable))
>> +               return 0;
>> +
>> +       if (channel >= drvdata->numsp)
>> +               return 0;
>> +
>> +       ch_addr = (unsigned long)stm_channel_addr(drvdata, channel);
>> +
>> +       flags = (flags == STP_PACKET_TIMESTAMPED) ? STM_FLAG_TIMESTAMPED : 0;
>> +       flags |= test_bit(channel, drvdata->chs.guaranteed) ?
>> +                          STM_FLAG_GUARANTEED : 0;
>> +
>> +       if (size > drvdata->write_max)
>> +               size = drvdata->write_max;
>> +
>> +       switch (packet) {
>> +       case STP_PACKET_FLAG:
>> +               ch_addr |= stm_channel_off(STM_PKT_TYPE_FLAG, flags);
>> +
>> +               /* the generic STM API set a size of zero on flag packets. */
>> +               size = 1;
>> +               break;
>> +
>> +       case STP_PACKET_DATA:
>> +               ch_addr |= stm_channel_off(STM_PKT_TYPE_DATA, flags);
>> +               break;
>> +
>> +       default:
>> +               return 0;
>> +       }
>> +
>> +       return stm_send((void *)ch_addr, payload, size, drvdata->write_max);
>> +}
>> +
>> +static ssize_t hwevent_enable_show(struct device *dev,
>> +                                  struct device_attribute *attr, char *buf)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val = drvdata->stmheer;
>> +
>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>> +}
>> +
>> +static ssize_t hwevent_enable_store(struct device *dev,
>> +                                   struct device_attribute *attr,
>> +                                   const char *buf, size_t size)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val;
>> +       int ret = 0;
>> +
>> +       ret = kstrtoul(buf, 16, &val);
>> +       if (ret)
>> +               return -EINVAL;
>> +
>> +       drvdata->stmheer = val;
>> +       /* HW event enable and trigger go hand in hand */
>> +       drvdata->stmheter = val;
>> +
>> +       return size;
>> +}
>> +static DEVICE_ATTR_RW(hwevent_enable);
>> +
>> +static ssize_t hwevent_select_show(struct device *dev,
>> +                                  struct device_attribute *attr, char *buf)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val = drvdata->stmhebsr;
>> +
>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>> +}
>> +
>> +static ssize_t hwevent_select_store(struct device *dev,
>> +                                   struct device_attribute *attr,
>> +                                   const char *buf, size_t size)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val;
>> +       int ret = 0;
>> +
>> +       ret = kstrtoul(buf, 16, &val);
>> +       if (ret)
>> +               return -EINVAL;
>> +
>> +       drvdata->stmhebsr = val;
>> +
>> +       return size;
>> +}
>> +static DEVICE_ATTR_RW(hwevent_select);
>> +
>> +static ssize_t port_select_show(struct device *dev,
>> +                               struct device_attribute *attr, char *buf)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val;
>> +
>> +       if (!drvdata->enable) {
>> +               val = drvdata->stmspscr;
>> +       } else {
>> +               spin_lock(&drvdata->spinlock);
>> +               val = readl_relaxed(drvdata->base + STMSPSCR);
>> +               spin_unlock(&drvdata->spinlock);
>> +       }
>> +
>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>> +}
>> +
>> +static ssize_t port_select_store(struct device *dev,
>> +                                struct device_attribute *attr,
>> +                                const char *buf, size_t size)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val, stmsper;
>> +       int ret = 0;
>> +
>> +       ret = kstrtoul(buf, 16, &val);
>> +       if (ret)
>> +               return ret;
>> +
>> +       spin_lock(&drvdata->spinlock);
>> +       drvdata->stmspscr = val;
>> +
>> +       if (drvdata->enable) {
>> +               CS_UNLOCK(drvdata->base);
>> +               /* Process as per ARM's TRM recommendation */
>> +               stmsper = readl_relaxed(drvdata->base + STMSPER);
>> +               writel_relaxed(0x0, drvdata->base + STMSPER);
>> +               writel_relaxed(drvdata->stmspscr, drvdata->base + STMSPSCR);
>> +               writel_relaxed(stmsper, drvdata->base + STMSPER);
>> +               CS_LOCK(drvdata->base);
>> +       }
>> +       spin_unlock(&drvdata->spinlock);
>> +
>> +       return size;
>> +}
>> +static DEVICE_ATTR_RW(port_select);
>> +
>> +static ssize_t port_enable_show(struct device *dev,
>> +                               struct device_attribute *attr, char *buf)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val;
>> +
>> +       if (!drvdata->enable) {
>> +               val = drvdata->stmsper;
>> +       } else {
>> +               spin_lock(&drvdata->spinlock);
>> +               val = readl_relaxed(drvdata->base + STMSPER);
>> +               spin_unlock(&drvdata->spinlock);
>> +       }
>> +
>> +       return scnprintf(buf, PAGE_SIZE, "%#lx\n", val);
>> +}
>> +
>> +static ssize_t port_enable_store(struct device *dev,
>> +                                struct device_attribute *attr,
>> +                                const char *buf, size_t size)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +       unsigned long val;
>> +       int ret = 0;
>> +
>> +       ret = kstrtoul(buf, 16, &val);
>> +       if (ret)
>> +               return ret;
>> +
>> +       spin_lock(&drvdata->spinlock);
>> +       drvdata->stmsper = val;
>> +
>> +       if (drvdata->enable) {
>> +               CS_UNLOCK(drvdata->base);
>> +               writel_relaxed(drvdata->stmsper, drvdata->base + STMSPER);
>> +               CS_LOCK(drvdata->base);
>> +       }
>> +       spin_unlock(&drvdata->spinlock);
>> +
>> +       return size;
>> +}
>> +static DEVICE_ATTR_RW(port_enable);
>> +
>> +static ssize_t traceid_show(struct device *dev,
>> +                           struct device_attribute *attr, char *buf)
>> +{
>> +       unsigned long val;
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +
>> +       val = drvdata->traceid;
>> +       return sprintf(buf, "%#lx\n", val);
>> +}
>> +
>> +static ssize_t traceid_store(struct device *dev,
>> +                            struct device_attribute *attr,
>> +                            const char *buf, size_t size)
>> +{
>> +       int ret;
>> +       unsigned long val;
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev->parent);
>> +
>> +       ret = kstrtoul(buf, 16, &val);
>> +       if (ret)
>> +               return ret;
>> +
>> +       /* traceid field is 7bit wide on STM32 */
>> +       drvdata->traceid = val & 0x7f;
>> +       return size;
>> +}
>> +static DEVICE_ATTR_RW(traceid);
>> +
>> +#define coresight_simple_func(type, name, offset)                      \
>> +static ssize_t name##_show(struct device *_dev,                                \
>> +                          struct device_attribute *attr, char *buf)    \
>> +{                                                                      \
>> +       type *drvdata = dev_get_drvdata(_dev->parent);                  \
>> +       return scnprintf(buf, PAGE_SIZE, "0x%08x\n",                    \
>> +                        readl_relaxed(drvdata->base + offset));        \
>> +}                                                                      \
>> +DEVICE_ATTR_RO(name)
>> +
>> +#define coresight_stm_simple_func(name, offset)        \
>> +       coresight_simple_func(struct stm_drvdata, name, offset)
>> +
>> +coresight_stm_simple_func(tcsr, STMTCSR);
>> +coresight_stm_simple_func(tsfreqr, STMTSFREQR);
>> +coresight_stm_simple_func(syncr, STMSYNCR);
>> +coresight_stm_simple_func(sper, STMSPER);
>> +coresight_stm_simple_func(spter, STMSPTER);
>> +coresight_stm_simple_func(privmaskr, STMPRIVMASKR);
>> +coresight_stm_simple_func(spscr, STMSPSCR);
>> +coresight_stm_simple_func(spmscr, STMSPMSCR);
>> +coresight_stm_simple_func(spfeat1r, STMSPFEAT1R);
>> +coresight_stm_simple_func(spfeat2r, STMSPFEAT2R);
>> +coresight_stm_simple_func(spfeat3r, STMSPFEAT3R);
>> +coresight_stm_simple_func(devid, CORESIGHT_DEVID);
>> +
>> +static struct attribute *coresight_stm_attrs[] = {
>> +       &dev_attr_hwevent_enable.attr,
>> +       &dev_attr_hwevent_select.attr,
>> +       &dev_attr_port_enable.attr,
>> +       &dev_attr_port_select.attr,
>> +       &dev_attr_traceid.attr,
>> +       NULL,
>> +};
>> +
>> +static struct attribute *coresight_stm_mgmt_attrs[] = {
>> +       &dev_attr_tcsr.attr,
>> +       &dev_attr_tsfreqr.attr,
>> +       &dev_attr_syncr.attr,
>> +       &dev_attr_sper.attr,
>> +       &dev_attr_spter.attr,
>> +       &dev_attr_privmaskr.attr,
>> +       &dev_attr_spscr.attr,
>> +       &dev_attr_spmscr.attr,
>> +       &dev_attr_spfeat1r.attr,
>> +       &dev_attr_spfeat2r.attr,
>> +       &dev_attr_spfeat3r.attr,
>> +       &dev_attr_devid.attr,
>> +       NULL,
>> +};
>> +
>> +static const struct attribute_group coresight_stm_group = {
>> +       .attrs = coresight_stm_attrs,
>> +};
>> +
>> +static const struct attribute_group coresight_stm_mgmt_group = {
>> +       .attrs = coresight_stm_mgmt_attrs,
>> +       .name = "mgmt",
>> +};
>> +
>> +static const struct attribute_group *coresight_stm_groups[] = {
>> +       &coresight_stm_group,
>> +       &coresight_stm_mgmt_group,
>> +       NULL,
>> +};
>> +
>> +static int stm_get_resource_byname(struct device_node *np,
>> +                                  char *ch_base, struct resource *res)
>> +{
>> +       const char *name = NULL;
>> +       int index = 0, found = 0;
>> +
>> +       while (!of_property_read_string_index(np, "reg-names", index, &name)) {
>> +               if (strcmp(ch_base, name)) {
>> +                       index++;
>> +                       continue;
>> +               }
>> +
>> +               /* We have a match and @index is where it's at */
>> +               found = 1;
>> +               break;
>> +       }
>> +
>> +       if (!found)
>> +               return -EINVAL;
>> +
>> +       return of_address_to_resource(np, index, res);
>> +}
>> +
>> +static u32 stm_fundamental_data_size(struct stm_drvdata *drvdata)
>> +{
>> +       u32 stmspfeat2r;
>> +
>> +       stmspfeat2r = readl_relaxed(drvdata->base + STMSPFEAT2R);
>> +       return BMVAL(stmspfeat2r, 12, 15);
>> +}
>> +
>> +static u32 stm_num_stimulus_port(struct stm_drvdata *drvdata)
>> +{
>> +       u32 numsp;
>> +
>> +       numsp = readl_relaxed(drvdata->base + CORESIGHT_DEVID);
>> +       /*
>> +        * NUMPS in STMDEVID is 17 bit long and if equal to 0x0,
>> +        * 32 stimulus ports are supported.
>> +        */
>> +       numsp &= 0x1ffff;
>> +       if (!numsp)
>> +               numsp = STM_32_CHANNEL;
>> +       return numsp;
>> +}
>> +
>> +static void stm_init_default_data(struct stm_drvdata *drvdata)
>> +{
>> +       /* Don't use port selection */
>> +       drvdata->stmspscr = 0x0;
>> +       /*
>> +        * Enable all channel regardless of their number.  When port
>> +        * selection isn't used (see above) STMSPER applies to all
>> +        * 32 channel group available, hence setting all 32 bits to 1
>> +        */
>> +       drvdata->stmsper = ~0x0;
>> +
>> +       /*
>> +        * Select arbitrary value to start with.  If there is a conflict
>> +        * with other tracers the framework will deal with it.
>> +        */
>> +       drvdata->traceid = 0x20;
>> +
>> +       /* Set invariant transaction timing on all channels */
>> +       bitmap_clear(drvdata->chs.guaranteed, 0, drvdata->numsp);
>> +}
>> +
>> +static void stm_init_generic_data(struct stm_drvdata *drvdata)
>> +{
>> +       drvdata->stm.name = dev_name(drvdata->dev);
>> +       drvdata->stm.mstatic = true;
>> +       drvdata->stm.sw_nchannels = drvdata->numsp;
>> +       drvdata->stm.packet = stm_generic_packet;
>> +       drvdata->stm.link = stm_generic_link;
>> +       drvdata->stm.unlink = stm_generic_unlink;
>> +       drvdata->stm.set_options = stm_generic_set_options;
>> +       drvdata->stm.get_options = stm_generic_get_options;
>> +}
>> +
>> +static int stm_probe(struct amba_device *adev, const struct amba_id *id)
>> +{
>> +       int ret;
>> +       void __iomem *base;
>> +       unsigned long *guaranteed;
>> +       struct device *dev = &adev->dev;
>> +       struct coresight_platform_data *pdata = NULL;
>> +       struct stm_drvdata *drvdata;
>> +       struct resource *res = &adev->res;
>> +       struct resource ch_res;
>> +       size_t res_size, bitmap_size;
>> +       struct coresight_desc *desc;
>> +       struct device_node *np = adev->dev.of_node;
>> +
>> +       if (np) {
>> +               pdata = of_get_coresight_platform_data(dev, np);
>> +               if (IS_ERR(pdata))
>> +                       return PTR_ERR(pdata);
>> +               adev->dev.platform_data = pdata;
>> +       }
>> +       drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
>> +       if (!drvdata)
>> +               return -ENOMEM;
>> +
>> +       drvdata->dev = &adev->dev;
>> +       drvdata->atclk = devm_clk_get(&adev->dev, "atclk"); /* optional */
>> +       if (!IS_ERR(drvdata->atclk)) {
>> +               ret = clk_prepare_enable(drvdata->atclk);
>> +               if (ret)
>> +                       return ret;
>> +       }
>> +       dev_set_drvdata(dev, drvdata);
>> +
>> +       base = devm_ioremap_resource(dev, res);
>> +       if (IS_ERR(base))
>> +               return PTR_ERR(base);
>> +       drvdata->base = base;
>> +
>> +       ret = stm_get_resource_byname(np, "stm-stimulus-base", &ch_res);
>> +       if (ret)
>> +               return ret;
>> +
>> +       base = devm_ioremap_resource(dev, &ch_res);
>> +       if (IS_ERR(base))
>> +               return PTR_ERR(base);
>> +       drvdata->chs.base = base;
>> +
>> +       drvdata->write_max = sizeof(u32);
>
> Isn't the fundamental data size the maximum an architecture can stand?
>  Why not simply use that rather than adding another variable?
>
>> +       drvdata->write_64bit = stm_fundamental_data_size(drvdata);
>> +
>> +#ifndef CONFIG_64BIT
>> +       if (drvdata->write_64bit)
>> +               drvdata->write_max = sizeof(u64);
>> +#endif
>
> In most cases the fundamental data size will follow the architecture
> size, i.e, 32 bit architecture with 32 bit fundamental data size, 64
> bit architecture with 64 bit fundamental data size.  A fundamental
> data size of 32 is also possible on a 64 bit architecture.
>
> What needs to be prevented is a 32 bit architecture with a fundamental
> data size of 64.  In those cases the fundamental data size should be
> adjusted to be 32 bit.  To do that I suggest to modify
> stm_fundamental_data_size() to probe the STM's fundamental data size

I will modify that according to your suggestion.

> but to adjust it down if on a 32 bit system.  Knowing whether running
> on a 32/64 bit system is easy when using the IS_ENABLED() macro.
>
>> +
>> +       if (boot_nr_channel) {
>> +               drvdata->numsp = boot_nr_channel;
>> +               res_size = min((resource_size_t)(boot_nr_channel *
>> +                                 BYTES_PER_CHANNEL), resource_size(res));
>> +       } else {
>> +               drvdata->numsp = stm_num_stimulus_port(drvdata);
>> +               res_size = min((resource_size_t)(drvdata->numsp *
>> +                                BYTES_PER_CHANNEL), resource_size(res));
>> +       }
>> +       bitmap_size = BITS_TO_LONGS(drvdata->numsp) * sizeof(long);
>> +
>> +       guaranteed = devm_kzalloc(dev, bitmap_size, GFP_KERNEL);
>> +       if (!guaranteed)
>> +               return -ENOMEM;
>> +       drvdata->chs.guaranteed = guaranteed;
>> +
>> +       spin_lock_init(&drvdata->spinlock);
>> +
>> +       stm_init_default_data(drvdata);
>> +       stm_init_generic_data(drvdata);
>> +
>> +       if (stm_register_device(dev, &drvdata->stm, THIS_MODULE)) {
>> +               dev_info(dev,
>> +                        "stm_register_device failed, probing deffered\n");
>> +               return -EPROBE_DEFER;
>> +       }
>> +
>> +       desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL);
>> +       if (!desc) {
>> +               ret = -ENOMEM;
>> +               goto stm_unregister;
>> +       }
>> +
>> +       desc->type = CORESIGHT_DEV_TYPE_SOURCE;
>> +       desc->subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_SOFTWARE;
>> +       desc->ops = &stm_cs_ops;
>> +       desc->pdata = pdata;
>> +       desc->dev = dev;
>> +       desc->groups = coresight_stm_groups;
>> +       drvdata->csdev = coresight_register(desc);
>> +       if (IS_ERR(drvdata->csdev)) {
>> +               ret = PTR_ERR(drvdata->csdev);
>> +               goto stm_unregister;
>> +       }
>> +
>> +       pm_runtime_put(&adev->dev);
>> +
>> +       dev_info(dev, "%s initialized\n", (char *)id->data);
>> +       return 0;
>> +
>> +stm_unregister:
>> +       stm_unregister_device(&drvdata->stm);
>> +       return ret;
>> +}
>> +
>> +static int stm_remove(struct amba_device *adev)
>> +{
>> +       struct stm_drvdata *drvdata = amba_get_drvdata(adev);
>> +
>> +       stm_unregister_device(&drvdata->stm);
>> +       coresight_unregister(drvdata->csdev);
>> +       return 0;
>> +}
>
> The xyz_remove() functions is not needed for coresight devices -
> unbinding a device from its driver will no longer be possible in the
> 4.6 cycle.

OK, will remove this.

Thanks for your review,
Chunyan

>
>> +
>> +#ifdef CONFIG_PM
>> +static int stm_runtime_suspend(struct device *dev)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev);
>> +
>> +       if (drvdata && !IS_ERR(drvdata->atclk))
>> +               clk_disable_unprepare(drvdata->atclk);
>> +
>> +       return 0;
>> +}
>> +
>> +static int stm_runtime_resume(struct device *dev)
>> +{
>> +       struct stm_drvdata *drvdata = dev_get_drvdata(dev);
>> +
>> +       if (drvdata && !IS_ERR(drvdata->atclk))
>> +               clk_prepare_enable(drvdata->atclk);
>> +
>> +       return 0;
>> +}
>> +#endif
>> +
>> +static const struct dev_pm_ops stm_dev_pm_ops = {
>> +       SET_RUNTIME_PM_OPS(stm_runtime_suspend, stm_runtime_resume, NULL)
>> +};
>> +
>> +static struct amba_id stm_ids[] = {
>> +       {
>> +               .id     = 0x0003b962,
>> +               .mask   = 0x0003ffff,
>> +               .data   = "STM32",
>> +       },
>> +       { 0, 0},
>> +};
>> +
>> +static struct amba_driver stm_driver = {
>> +       .drv = {
>> +               .name   = "coresight-stm",
>> +               .owner  = THIS_MODULE,
>> +               .pm     = &stm_dev_pm_ops,
>> +       },
>> +       .probe          = stm_probe,
>> +       .remove         = stm_remove,
>> +       .id_table       = stm_ids,
>> +};
>> +
>> +module_amba_driver(stm_driver);
>> +
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("CoreSight System Trace Macrocell driver");
>> diff --git a/include/linux/coresight-stm.h b/include/linux/coresight-stm.h
>> new file mode 100644
>> index 0000000..a978bb8
>> --- /dev/null
>> +++ b/include/linux/coresight-stm.h
>> @@ -0,0 +1,6 @@
>> +#ifndef __LINUX_CORESIGHT_STM_H_
>> +#define __LINUX_CORESIGHT_STM_H_
>> +
>> +#include <uapi/linux/coresight-stm.h>
>> +
>> +#endif
>> diff --git a/include/uapi/linux/coresight-stm.h b/include/uapi/linux/coresight-stm.h
>> new file mode 100644
>> index 0000000..fa35f0b
>> --- /dev/null
>> +++ b/include/uapi/linux/coresight-stm.h
>> @@ -0,0 +1,12 @@
>> +#ifndef __UAPI_CORESIGHT_STM_H_
>> +#define __UAPI_CORESIGHT_STM_H_
>> +
>> +#define STM_FLAG_TIMESTAMPED   BIT(3)
>> +#define STM_FLAG_GUARANTEED    BIT(7)
>> +
>> +enum {
>> +       STM_OPTION_GUARANTEED = 0,
>> +       STM_OPTION_INVARIANT,
>> +};
>> +
>> +#endif
>> --
>> 1.9.1
>>


From majun258 at huawei.com  Tue Feb 16 20:18:52 2016
From: majun258 at huawei.com (majun (F))
Date: Wed, 17 Feb 2016 12:18:52 +0800
Subject: [PATCH v2 4/5] irqchip:create irq domain for each mbigen device
In-Reply-To: <20160216085024.3f573f40@arm.com>
References: <1455604648-20668-1-git-send-email-majun258@huawei.com>
 <1455604648-20668-5-git-send-email-majun258@huawei.com>
 <20160216085024.3f573f40@arm.com>
Message-ID: <56C3F4AC.8020807@huawei.com>



? 2016/2/16 16:50, Marc Zyngier ??:
> On Tue, 16 Feb 2016 14:37:27 +0800
> MaJun <majun258 at huawei.com> wrote:
> 
>> From: Ma Jun <majun258 at huawei.com>
[...]
>> +	unsigned int nid;
>> +
>> +	nid = get_mbigen_nid(hwirq);
>> +
>> +	if (nid < 4)
>> +		return (nid * 4) + REG_MBIGEN_VEC_OFFSET;
>> +	else
>> +		return (nid - 4) * 4 + REG_MBIGEN_EXT_VEC_OFFSET;
>> +}
>> +
>> +static struct irq_chip mbigen_irq_chip = {
>> +	.name =			"mbigen-v1",
>> +};
>> +
>> +static void mbigen_write_msg(struct msi_desc *desc, struct msi_msg *msg)
>> +{
>> +	/* The address of doorbell is encoded in mbigen register by default
>> +	 * So,we don't need to program the doorbell address at here
>> +	 * Besides, the event ID is decided by the hardware pin number,
>> +	 * we can't change it in software.So, we don't need to encode the
>> +	 * event ID in mbigen register.
>> +	 */
> 
> Really? What if tomorrow I decide to change the EventID allocation
> policy in the ITS driver? Have your HW engineers really baked the
> behaviour of the Linux driver into the device?
> 

Yes.
If we really need to support this chip,is there
any possible solution for this problem?

Thanks!
MaJun

> I'm puzzled.
> 
> 	M.
> 



From david.brown at linaro.org  Tue Feb 16 21:20:10 2016
From: david.brown at linaro.org (David Brown)
Date: Tue, 16 Feb 2016 22:20:10 -0700
Subject: [PATCH] ARM: vdso: Mark vDSO code as read-only
In-Reply-To: <CAGXu5j+H63jhcDpHpXK5aWvgUBz=5vB0FK_zRoc+wZEk32B2fg@mail.gmail.com>
References: <1453226922-16831-1-git-send-email-keescook@chromium.org>
 <20160216213659.GA47194@davidb.org>
 <CAGXu5j+H63jhcDpHpXK5aWvgUBz=5vB0FK_zRoc+wZEk32B2fg@mail.gmail.com>
Message-ID: <20160217052010.GA49233@davidb.org>

On Tue, Feb 16, 2016 at 01:52:33PM -0800, Kees Cook wrote:
>On Tue, Feb 16, 2016 at 1:36 PM, David Brown <david.brown at linaro.org> wrote:
>> Although the arm vDSO is cleanly separated by code/data with the code
>> being read-only in userspace mappings, the code page is still writable
>> from the kernel.  There have been exploits (such as
>> http://itszn.com/blog/?p=21) that take advantage of this on x86 to go
>> from a bad kernel write to full root.
>>
>> Prevent this specific exploit on arm by putting the vDSO code page in
>> post-init read-only memory as well.
>
>Is the vdso dynamically built at init time like on x86, or can this
>just use .rodata directly?

On ARM, it is patched during init.  Arm64's is just plain read-only.

David


From horms at verge.net.au  Tue Feb 16 21:38:48 2016
From: horms at verge.net.au (Simon Horman)
Date: Wed, 17 Feb 2016 14:38:48 +0900
Subject: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
In-Reply-To: <56BE3912.9000601@cogentembedded.com>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
 <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
 <874mdhtn7d.wl%kuninori.morimoto.gx@renesas.com>
 <20160210171455.GB17671@verge.net.au>
 <56BE0CB1.4070408@cogentembedded.com>
 <20160212184343.GA31655@verge.net.au>
 <56BE2DC6.4080802@cogentembedded.com>
 <20160212193347.GB23472@verge.net.au>
 <56BE3912.9000601@cogentembedded.com>
Message-ID: <20160217053848.GC11534@verge.net.au>

On Fri, Feb 12, 2016 at 10:57:06PM +0300, Sergei Shtylyov wrote:
> On 02/12/2016 10:33 PM, Simon Horman wrote:
> 
> >>>>>>Sorry for my un-ordered response
> >>>>>>
> >>>>>>>Define the generic R8A7794 part of  the sound device node.
> >>>>>>>This sound device  is a complex one and comprises the Audio Clock Generator
> >>>>>>>(ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
> >>>>>>>(SSI[U]), and Audio DMAC-Peripheral-Peripheral.
> >>>>>>>It is up  to the board file to enable the device.
> >>>>>>>
> >>>>>>>This patch is based on the R8A7791 sound work by Kuninori Morimoto.
> >>>>>>>
> >>>>>>>Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> >>>>>>(snip)
> >>>>>>>+		rcar_sound,src {
> >>>>>>>+			src1: src at 1 {
> >>>>>>>+				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>>>+				dmas = <&audma0 0x87>, <&audma0 0x9c>;
> >>>>>>>+				dma-names = "rx", "tx";
> >>>>>>>+			};
> >>>>>>>+			src2: src at 2 {
> >>>>>>>+				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>>>+				dmas = <&audma0 0x89>, <&audma0 0x9e>;
> >>>>>>>+				dma-names = "rx", "tx";
> >>>>>>>+			};
> >>>>>>>+			src3: src at 3 {
> >>>>>>>+				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>>>+				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
> >>>>>>>+				dma-names = "rx", "tx";
> >>>>>>>+			};
> >>>>>>>+			src4: src at 4 {
> >>>>>>>+				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>>>+				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
> >>>>>>>+				dma-names = "rx", "tx";
> >>>>>>>+			};
> >>>>>>>+			src5: src at 5 {
> >>>>>>>+				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>>>+				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
> >>>>>>>+				dma-names = "rx", "tx";
> >>>>>>>+			};
> >>>>>>>+			src6: src at 6 {
> >>>>>>>+				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>>>+				dmas = <&audma0 0x91>, <&audma0 0xb4>;
> >>>>>>>+				dma-names = "rx", "tx";
> >>>>>>>+			};
> >>>>>>>+		};
> >>>>>>
> >>>>>>I think this can't work correctly, because driver is assuming
> >>>>>>DT has all channles (from 0). (see linux/sound/soc/sh/rcar/src.c :: rsnd_src_probe)
> >>>>>>Can you adds dummy src0 with some comments ? or fix src.c driver ?
> >>>>>
> >>>>>I would prefer the driver to be fixed (I had a similar patchset locally
> >>>>>and I found it doesn't work).
> >>>>
> >>>>    You mean you had R8A7794 sound patch set too?
> >>>
> >>>Yes, I was working on it recently.
> >>>I suppose we should coordinate these things in future to avoid
> >>>duplicated effort.
> >>
> >>    Yes, seems a good idea now. :-)
> >>
> >>>>>The reason is that DT should describe
> >>>>>the hardware rather than the current state of the software.
> >>>>
> >>>>    Yes, of course. Just tell me do I have to fix the driver *before* this
> >>>>patch set is accepted?
> >>
> >>>I did not entirely get to the bottom of the problem, but I think that at
> >>>the very least something needs to be done about the for_each_rsnd_src()
> >>>loop in rsnd_src_probe.
> >>
> >>    It's not that it replies to my question. :-)
> >>    So you're looking at this issue yourself?
> >
> >I have not got very far, as you can see, but I was planning to look into it.
> >I don't mind if you want to do so.
> 
>    After consultation with the management, I'm going to look into this issue
> myself. :-)

Excellent.

FWIW, I can test anything you come up with for the r8a7794 an alt board
or post patches for it once you have r8a7794/silk sorted out.

> >>>My, obviously not satisfactory, hack around there being no src0 was as follows.
> >>>
> >>>diff --git a/sound/soc/sh/rcar/src.c b/sound/soc/sh/rcar/src.c
> >>>index 68b439ed22d7..58a447b0785b 100644
> >>>--- a/sound/soc/sh/rcar/src.c
> >>>+++ b/sound/soc/sh/rcar/src.c
> >>>@@ -1072,7 +1072,7 @@ int rsnd_src_probe(struct platform_device *pdev,
> >>>
> >>>  	for_each_rsnd_src(src, priv, i) {
> >>
> >>    Which tree is this? The recent devel branch of renesas.git has
> >>for_each_child_of_node() here...
> >
> >renesas-devel-20160118-v4.4
> 
>    Ah! :-)
> 
> >I guess the code in question updated in v4.5-rcX.
> 
>    Probably...
> 
> [...]
> 
> MBR, Sergei


From wenyou.yang at atmel.com  Tue Feb 16 21:40:24 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Wed, 17 Feb 2016 13:40:24 +0800
Subject: [PATCH] mtd: atmel_nand: move the hsmc_clk from nfc node to nand node
Message-ID: <1455687624-9488-1-git-send-email-wenyou.yang@atmel.com>

From: Josh Wu <josh.wu at atmel.com>

For sama5d3, sama5d4 chip, the pmecc becomes a part of HSMC, they
need the HSMC clock to be enabled to work.
The NFC is a sub feature for current nand driver, it can be disabled.
But if HSMC clock is controlled by NFC, so disable NFC will also
disable the HSMC clock. then, it will make the PMECC fail to work.

So the solution is to move the HSMC clock out of NFC to nand node.
When nand driver probed, it will check whether the chip has HSMC,
if yes then it will require a HSMC clock.

Signed-off-by: Josh Wu <josh.wu at atmel.com>
Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---

 .../devicetree/bindings/mtd/atmel-nand.txt         |    4 +-
 drivers/mtd/nand/atmel_nand.c                      |   43 +++++++++-----------
 2 files changed, 22 insertions(+), 25 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index d53aba9..29bee7c 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -15,6 +15,7 @@ Required properties:
 - atmel,nand-cmd-offset : offset for the command latch.
 - #address-cells, #size-cells : Must be present if the device has sub-nodes
   representing partitions.
+- clocks: phandle to the peripheral clock
 
 - gpios : specifies the gpio pins to control the NAND device. detect is an
   optional gpio and may be set to 0 if not present.
@@ -43,7 +44,6 @@ Required properties:
 - reg : should specify the address and size used for NFC command registers,
         NFC registers and NFC SRAM. NFC SRAM address and size can be absent
         if don't want to use it.
-- clocks: phandle to the peripheral clock
 Optional properties:
 - atmel,write-by-sram: boolean to enable NFC write by SRAM.
 
@@ -100,13 +100,13 @@ nand0: nand at 40000000 {
 	compatible = "atmel,at91rm9200-nand";
 	#address-cells = <1>;
 	#size-cells = <1>;
+	clocks = <&hsmc_clk>
 	ranges;
         ...
         nfc at 70000000 {
 		compatible = "atmel,sama5d3-nfc";
 		#address-cells = <1>;
 		#size-cells = <1>;
-		clocks = <&hsmc_clk>
 		reg = <
 			0x70000000 0x10000000	/* NFC Command Registers */
 			0xffffc000 0x00000070	/* NFC HSMC regs */
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 20cbaab..a1f4ad2 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -66,6 +66,7 @@ module_param(on_flash_bbt, int, 0);
 struct atmel_nand_caps {
 	bool pmecc_correct_erase_page;
 	uint8_t pmecc_max_correction;
+	bool has_hsmc_clk;
 };
 
 struct atmel_nand_nfc_caps {
@@ -106,8 +107,6 @@ struct atmel_nfc {
 	bool			use_nfc_sram;
 	bool			write_by_sram;
 
-	struct clk		*clk;
-
 	bool			is_initialized;
 	struct completion	comp_ready;
 	struct completion	comp_cmd_done;
@@ -132,6 +131,7 @@ struct atmel_nand_host {
 	struct dma_chan		*dma_chan;
 
 	struct atmel_nfc	*nfc;
+	struct clk		*clk;
 
 	const struct atmel_nand_caps	*caps;
 	bool			has_pmecc;
@@ -2157,6 +2157,19 @@ static int atmel_nand_probe(struct platform_device *pdev)
 	nand_chip->IO_ADDR_R = host->io_base;
 	nand_chip->IO_ADDR_W = host->io_base;
 
+	if (host->caps->has_hsmc_clk) {
+		host->clk = devm_clk_get(&pdev->dev, NULL);
+		if (IS_ERR(host->clk)) {
+			dev_err(&pdev->dev, "HSMC clock is missing, update your Device Tree");
+			res = PTR_ERR(host->clk);
+			goto err_nand_ioremap;
+		}
+
+		res = clk_prepare_enable(host->clk);
+		if (res)
+			goto err_nand_ioremap;
+	}
+
 	if (nand_nfc.is_initialized) {
 		/* NFC driver is probed and initialized */
 		host->nfc = &nand_nfc;
@@ -2321,6 +2334,9 @@ static int atmel_nand_remove(struct platform_device *pdev)
 	if (host->dma_chan)
 		dma_release_channel(host->dma_chan);
 
+	if (!IS_ERR(host->clk))
+		clk_disable_unprepare(host->clk);
+
 	platform_driver_unregister(&atmel_nand_nfc_driver);
 
 	return 0;
@@ -2334,11 +2350,13 @@ static int atmel_nand_remove(struct platform_device *pdev)
 static const struct atmel_nand_caps at91rm9200_caps = {
 	.pmecc_correct_erase_page = false,
 	.pmecc_max_correction = 24,
+	.has_hsmc_clk = false,
 };
 
 static const struct atmel_nand_caps sama5d4_caps = {
 	.pmecc_correct_erase_page = true,
 	.pmecc_max_correction = 24,
+	.has_hsmc_clk = true,
 };
 
 /*
@@ -2363,7 +2381,6 @@ static int atmel_nand_nfc_probe(struct platform_device *pdev)
 {
 	struct atmel_nfc *nfc = &nand_nfc;
 	struct resource *nfc_cmd_regs, *nfc_hsmc_regs, *nfc_sram;
-	int ret;
 
 	nfc_cmd_regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	nfc->base_cmd_regs = devm_ioremap_resource(&pdev->dev, nfc_cmd_regs);
@@ -2401,31 +2418,12 @@ static int atmel_nand_nfc_probe(struct platform_device *pdev)
 	nfc_writel(nfc->hsmc_regs, IDR, 0xffffffff);
 	nfc_readl(nfc->hsmc_regs, SR);	/* clear the NFC_SR */
 
-	nfc->clk = devm_clk_get(&pdev->dev, NULL);
-	if (!IS_ERR(nfc->clk)) {
-		ret = clk_prepare_enable(nfc->clk);
-		if (ret)
-			return ret;
-	} else {
-		dev_warn(&pdev->dev, "NFC clock missing, update your Device Tree");
-	}
-
 	nfc->is_initialized = true;
 	dev_info(&pdev->dev, "NFC is probed.\n");
 
 	return 0;
 }
 
-static int atmel_nand_nfc_remove(struct platform_device *pdev)
-{
-	struct atmel_nfc *nfc = &nand_nfc;
-
-	if (!IS_ERR(nfc->clk))
-		clk_disable_unprepare(nfc->clk);
-
-	return 0;
-}
-
 static const struct atmel_nand_nfc_caps sama5d3_nfc_caps = {
 	.rb_mask = NFC_SR_RB_EDGE0,
 };
@@ -2447,7 +2445,6 @@ static struct platform_driver atmel_nand_nfc_driver = {
 		.of_match_table = of_match_ptr(atmel_nand_nfc_match),
 	},
 	.probe = atmel_nand_nfc_probe,
-	.remove = atmel_nand_nfc_remove,
 };
 
 static struct platform_driver atmel_nand_driver = {
-- 
1.7.9.5



From wenyou.yang at atmel.com  Tue Feb 16 21:42:21 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Wed, 17 Feb 2016 13:42:21 +0800
Subject: [PATCH] ARM: at91: sama5/dts: move hsmc_clk out of nfc node
Message-ID: <1455687741-9625-1-git-send-email-wenyou.yang@atmel.com>

From: Josh Wu <josh.wu at atmel.com>

In sama5d3, sama5d4 chips, pmecc will use the hsmc clock. As pmecc is
part of HSMC. So move out hsmc_clk from nfc node to nand node.

Signed-off-by: Josh Wu <rainyfeeling at outlook.com>
Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---

 arch/arm/boot/dts/sama5d3.dtsi |    2 +-
 arch/arm/boot/dts/sama5d4.dtsi |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index a532791..a242d27 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -1474,6 +1474,7 @@
 			atmel,nand-has-dma;
 			pinctrl-names = "default";
 			pinctrl-0 = <&pinctrl_nand0_ale_cle>;
+			clocks = <&hsmc_clk>;
 			atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
 			status = "disabled";
 
@@ -1486,7 +1487,6 @@
 					0xffffc000 0x00000070	/* NFC HSMC regs */
 					0x00200000 0x00100000	/* NFC SRAM banks */
 					>;
-				clocks = <&hsmc_clk>;
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index b8032bc..1499b33 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -295,6 +295,7 @@
 			atmel,nand-has-dma;
 			pinctrl-names = "default";
 			pinctrl-0 = <&pinctrl_nand>;
+			clocks = <&hsmc_clk>;
 			status = "disabled";
 
 			nfc at 90000000 {
@@ -306,7 +307,6 @@
 					0xfc05c000 0x00000070	/* NFC HSMC regs */
 					0x00100000 0x00100000	/* NFC SRAM banks */
                                          >;
-				clocks = <&hsmc_clk>;
 				atmel,write-by-sram;
 			};
 		};
-- 
1.7.9.5



From horms at verge.net.au  Tue Feb 16 21:53:41 2016
From: horms at verge.net.au (Simon Horman)
Date: Wed, 17 Feb 2016 14:53:41 +0900
Subject: [PATCH v3 0/7] ARM/arm64: dts: renesas: Add/complete L2
 cache-controller nodes
In-Reply-To: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
References: <1455568715-20880-1-git-send-email-geert+renesas@glider.be>
Message-ID: <20160217055340.GD11534@verge.net.au>

On Mon, Feb 15, 2016 at 09:38:28PM +0100, Geert Uytterhoeven wrote:
> 	Hi Simon, Magnus,
> 
> This patch series adds the missing L2 cache-controller nodes to the
> DTSes for various Renesas ARM-based SoCs, or completes the existing
> nodes, and links the CPU nodes to them.
> 
> For R-Mobile APE6 (r8a73a4), the L2 cache-controllers are also linked to
> the respective (already existing) SYSC Power Domains. Fortunately these
> Power Domains were never powered down, as they are parents of the Power
> Domains containing CPU cores. This may change in the future.
> 
> For R-Car Gen2 and Gen3 (r8a779x), this serves as a preparatory step for
> adding SYSC Power Domain support later.
> 
> Changes compared to v2:
>   - Dropped "arm,data-latency" and "arm,tag-latency" properties, as they
>     may not be valid when using virtualization,
>   - Dropped already applied parts of "[PATCH v2 6/6] arm64: renesas:
>     r8a7795: Add L2 cache-controller nodes",
>   - Changed one-line summary prefix to match current arm-soc practices.
> 
> This series is against renesas-devel-20160215-v4.5-rc4.
> It has been tested on r8a73a4/ape6evm, r8a7791/koelsch, r8a7794/alt, and
> r8a7795/salvator-x.
> 
> For your convenience, I've also pushed this series to
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git#topic/l2-cache-v3
> 
> Thanks for applying!
> 
> Geert Uytterhoeven (7):
>   ARM: dts: r8a73a4: Add L2 cache-controller nodes
>   ARM: dts: r8a7790: Add L2 cache-controller nodes
>   ARM: dts: r8a7791: Add L2 cache-controller node
>   ARM: dts: r8a7793: Add L2 cache-controller node
>   ARM: dts: r8a7794: Add L2 cache-controller node
>   arm64: dts: r8a7795: Add missing properties to CA57 L2 cache node
>   arm64: dts: r8a7795: Add CA53 L2 cache-controller node

Thanks, I have queued these up for v4.6.


From horms at verge.net.au  Tue Feb 16 21:54:31 2016
From: horms at verge.net.au (Simon Horman)
Date: Wed, 17 Feb 2016 14:54:31 +0900
Subject: [PATCH] ARM: dts: r8a7794: replace gpio-key,wakeup with
 wakeup-source property
In-Reply-To: <56C2F266.5030709@arm.com>
References: <1455572925-27697-1-git-send-email-horms+renesas@verge.net.au>
 <56C2F266.5030709@arm.com>
Message-ID: <20160217055431.GE11534@verge.net.au>

On Tue, Feb 16, 2016 at 09:56:54AM +0000, Sudeep Holla wrote:
> 
> 
> On 15/02/16 21:48, Simon Horman wrote:
> >Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
> >check for/support the legacy "gpio-key,wakeup" boolean property to
> >enable gpio buttons as wakeup source, "wakeup-source" is the new
> >standard binding.
> >
> >This patch replaces the legacy "gpio-key,wakeup" with the unified
> >"wakeup-source" property in order to avoid any futher copy-paste
> >duplication.
> >
> >Changelog text from a similar patch by Sudeep Holla.
> >
> >Cc: Sudeep Holla <sudeep.holla at arm.com>
> 
> Thanks for doing this, not sure how I missed it, was this merged in v4.5?

I believe it came later and it was my error not to include this in the
change that added the nodes in question.


From horms at verge.net.au  Tue Feb 16 22:33:17 2016
From: horms at verge.net.au (Simon Horman)
Date: Wed, 17 Feb 2016 15:33:17 +0900
Subject: [PATCH v2] arm64: dts: r8a7795: Add GIC-400 virtual interfaces
In-Reply-To: <CAMuHMdVP4wA4eXK-fkENndNs=zS2vuUeDww2ZZbXvocfFiOgWQ@mail.gmail.com>
References: <1455615802-9083-1-git-send-email-dirk.behme@de.bosch.com>
 <CAMuHMdVP4wA4eXK-fkENndNs=zS2vuUeDww2ZZbXvocfFiOgWQ@mail.gmail.com>
Message-ID: <20160217063316.GL11534@verge.net.au>

On Tue, Feb 16, 2016 at 10:55:37AM +0100, Geert Uytterhoeven wrote:
> CC Marc
> 
> On Tue, Feb 16, 2016 at 10:43 AM, Dirk Behme <dirk.behme at de.bosch.com> wrote:
> > Besides the distributor and the CPU interface the GIC-400 additionally
> > supports the virtual interface control blocks and the virtual CPU interfaces.
> >
> > Add the physical base addresses and size for these.
> >
> > See
> >
> > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0471b/index.html
> > -> 3.2. GIC-400 register map
> >
> > and Linux kernel's
> >
> > Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
> >
> > for more details.
> >
> > For the at GICH Virtual interface control blocks at 0xf1040000 cover the
> > whole 128kB (0x20000) range. This is done based on the advice from Marc
> > Zyngier http://www.spinics.net/lists/arm-kernel/msg483139.html
> >
> > Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
> 
> Thanks!
> 
> Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>

Thanks, I have queued this up for v4.6.


From heiko at sntech.de  Tue Feb 16 22:45:09 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Wed, 17 Feb 2016 07:45:09 +0100
Subject: [PATCH] spi/rockchip: Add dt-binding for Rockchip rk3399 spi
In-Reply-To: <56C3BD26.3030704@rock-chips.com>
References: <1455614538-4415-1-git-send-email-jay.xu@rock-chips.com>
 <1730751.NYv1NxJVuB@phil> <56C3BD26.3030704@rock-chips.com>
Message-ID: <4579617.rz6Yi2sU5M@phil>

Hi Jianqun,

Am Mittwoch, 17. Februar 2016, 08:21:58 schrieb Jianqun Xu:
> ? 16/02/2016 22:37, Heiko Stuebner ??:
> > Am Dienstag, 16. Februar 2016, 13:22:23 schrieb Mark Brown:
> >> On Tue, Feb 16, 2016 at 05:22:18PM +0800, jianqun.xu wrote:
> >>>   Documentation/devicetree/bindings/spi/spi-rockchip.txt | 1 +
> >>>   1 file changed, 1 insertion(+)
> >> 
> >> I'd expect this to be added to both the driver and the binding document
> >> not just the document.
> > 
> > It seems the driver can still use the rk3066-variant - aka nobody has
> > found specific issues in the rk3399 IP implementation.
> > 
> > Having the more specific IP names already in the dts before actually
> > using them was suggested by devicetree people to not have to exchange
> > everything once specific issues were found.
> > 
> > So right now it's using the fallback-mechanism of binding to the rk3066
> > name, but if some obstacle appears it will only take adding the binding
> > in the driver to make it work (even with old devicetrees).
> 
> Thank you, got it, and I will re-send this patch with the driver patch.

you have me confused now :-) .

That was meant as a reply to Mark's comment, explaining why the double 
compatible and the driver only binding to the rk3066-one right now.


Heiko


From heiko at sntech.de  Tue Feb 16 22:47:45 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Wed, 17 Feb 2016 07:47:45 +0100
Subject: [PATCH 4/6] pinctrl: rockchip: add bindings for rk3399 pinctrl
In-Reply-To: <1455673992-16469-5-git-send-email-jay.xu@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <1455673992-16469-5-git-send-email-jay.xu@rock-chips.com>
Message-ID: <19942952.P4nUQKPo3g@phil>

Hi Jianqun,

Am Mittwoch, 17. Februar 2016, 09:53:10 schrieb jianqun.xu:
> From: Xu Jianqun <jay.xu at rock-chips.com>
> 
> Add devicetree bindings for pinctrl found on rk3399
> processors from rockchip.
> 
> Signed-off-by: Xu Jianqun <jay.xu at rock-chips.com>
> ---
>  Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index
> 0cd701b..c68b955 100644
> --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
> @@ -22,7 +22,7 @@ Required properties for iomux controller:
>    - compatible: one of "rockchip,rk2928-pinctrl",
> "rockchip,rk3066a-pinctrl" "rockchip,rk3066b-pinctrl",
> "rockchip,rk3188-pinctrl"
>  		       "rockchip,rk3228-pinctrl", "rockchip,rk3288-pinctrl"
> -		       "rockchip,rk3368-pinctrl"
> +		       "rockchip,rk3368-pinctrl", "rockchip,rk3399-pinctrl"
>    - rockchip,grf: phandle referencing a syscon providing the
>  	 "general register files"

that is already contained in David's core pinctrl patch that already got 
applied to the pinctrl tree.


Heiko


From horms at verge.net.au  Tue Feb 16 22:54:03 2016
From: horms at verge.net.au (Simon Horman)
Date: Wed, 17 Feb 2016 15:54:03 +0900
Subject: [GIT PULL] Renesas ARM Based SoC Updates for v4.6
In-Reply-To: <cover.1455303757.git.horms+renesas@verge.net.au>
References: <cover.1455303757.git.horms+renesas@verge.net.au>
Message-ID: <20160217065403.GN11534@verge.net.au>

Hi,

On Fri, Feb 12, 2016 at 08:06:22PM +0100, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
> 
> Please consider these Renesas ARM based SoC updates for v4.6.
> 
> This pull request is based on "Renesas ARM Based SoC Cleanup for v4.6",
> tagged as cleanup-for-v4.6, which you have already pulled.

I would like to withdraw this pull request.

I noticed that there is an error in the base I chose for the pull
request which has resulted in the inclusion of a patch
"ARM: shmobile: Consolidate SCU mapping code", which is already present
in your tree due to another pull request of mine which you have accepted.

I will respin this pull request accordingly.

> The following changes since commit e24f317c859f2d904d1eb87cbb503c309e6dead7:
> 
>   ARM: shmobile: Typo s/MIPDR/MPIDR/ (2016-02-04 15:09:30 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-for-v4.6
> 
> for you to fetch changes up to 9c9c1320111449c770a51488ca74a5902835e227:
> 
>   ARM: shmobile: emev2: Move declaration of emev2_smp_ops to emev2.h (2016-02-09 21:16:16 +0100)
> 
> ----------------------------------------------------------------
> Renesas ARM Based SoC Updates for v4.6
> 
> * Move emev2_smp_ops to emev2
> * Remove legacy map_io callbacks on r8a7740 and emev2 SoCs
> * Clean up SCU mapping code
> * Migrate to generic l2c OF initialization on r8a7740
> 
> ----------------------------------------------------------------
> Geert Uytterhoeven (8):
>       ARM: shmobile: r8a7779: Remove remainings of removed SCU boot setup code
>       ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization
>       ARM: shmobile: r8a7740: Remove mapping of L2 cache controller registers
>       ARM: shmobile: Move shmobile_scu_base from .text to .data
>       ARM: shmobile: Consolidate SCU mapping code
>       ARM: shmobile: r8a7740: Remove legacy machine_desc.map_io() callback
>       ARM: shmobile: emev2: Remove legacy machine_desc.map_io() callback
>       ARM: shmobile: emev2: Move declaration of emev2_smp_ops to emev2.h
> 
>  arch/arm/mach-shmobile/common.h        |  5 ++---
>  arch/arm/mach-shmobile/emev2.h         |  6 ++++++
>  arch/arm/mach-shmobile/headsmp-scu.S   |  6 ------
>  arch/arm/mach-shmobile/platsmp-scu.c   | 11 ++++++++--
>  arch/arm/mach-shmobile/setup-emev2.c   | 22 ++-----------------
>  arch/arm/mach-shmobile/setup-r8a7740.c | 39 ++--------------------------------
>  arch/arm/mach-shmobile/smp-emev2.c     |  5 +++--
>  arch/arm/mach-shmobile/smp-r8a7779.c   |  5 +----
>  arch/arm/mach-shmobile/smp-sh73a0.c    |  3 +--
>  9 files changed, 26 insertions(+), 76 deletions(-)
>  create mode 100644 arch/arm/mach-shmobile/emev2.h
> 


From jitao.shi at mediatek.com  Tue Feb 16 22:50:38 2016
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Wed, 17 Feb 2016 14:50:38 +0800
Subject: [PATCH 1/2] dt-bindings: Add LG lp120up1 panel bindings
Message-ID: <1455691839-2410-1-git-send-email-jitao.shi@mediatek.com>

Add documentation for lp120up1 panel

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
---
 .../bindings/display/panel/lg,lp120up1.txt         |    7 +++++++
 1 file changed, 7 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt

diff --git a/Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt b/Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt
new file mode 100644
index 0000000..ff0b6c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt
@@ -0,0 +1,7 @@
+LG 12.0" (1920x1280 pixels) TFT LCD panel
+
+Required properties:
+- compatible: should be "lg,lp120up1"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
1.7.9.5



From jitao.shi at mediatek.com  Tue Feb 16 22:50:39 2016
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Wed, 17 Feb 2016 14:50:39 +0800
Subject: [PATCH 2/2] drm/panel: Add support for LG lp120up1 panel
In-Reply-To: <1455691839-2410-1-git-send-email-jitao.shi@mediatek.com>
References: <1455691839-2410-1-git-send-email-jitao.shi@mediatek.com>
Message-ID: <1455691839-2410-2-git-send-email-jitao.shi@mediatek.com>

The LG lp120up1 panel is a 12.0" 1920x1280 panel,
which can be supported by the simple panel driver

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
---
 drivers/gpu/drm/panel/panel-simple.c |   26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index f88a631..2030c37 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -982,6 +982,29 @@ static const struct panel_desc lg_lb070wv8 = {
 	.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
 };
 
+static const struct drm_display_mode lg_lp120up1_mode = {
+	.clock = 162300,
+	.hdisplay = 1920,
+	.hsync_start = 1920 + 40,
+	.hsync_end = 1920 + 40 + 40,
+	.htotal = 1920 + 40 + 40+ 80,
+	.vdisplay = 1280,
+	.vsync_start = 1280 + 4,
+	.vsync_end = 1280 + 4 + 4,
+	.vtotal = 1280 + 4 + 4 + 12,
+	.vrefresh = 60,
+};
+
+static const struct panel_desc lg_lp120up1 = {
+	.modes = &lg_lp120up1_mode,
+	.num_modes = 1,
+	.bpc = 8,
+	.size = {
+		.width = 267,
+		.height = 183,
+	},
+};
+
 static const struct drm_display_mode lg_lp129qe_mode = {
 	.clock = 285250,
 	.hdisplay = 2560,
@@ -1256,6 +1279,9 @@ static const struct of_device_id platform_of_match[] = {
 		.compatible = "lg,lb070wv8",
 		.data = &lg_lb070wv8,
 	}, {
+		.compatible = "lg,lp120up1",
+		.data = &lg_lp120up1,
+	}, {
 		.compatible = "lg,lp129qe",
 		.data = &lg_lp129qe,
 	}, {
-- 
1.7.9.5



From k.kozlowski at samsung.com  Tue Feb 16 22:55:25 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 17 Feb 2016 15:55:25 +0900
Subject: [RFC-help needed 0/3] ARM: dts: thermal: Fix Odroid XU3-Lite overheat
Message-ID: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>

Hi,

I mentioned overheating problem of Odroid XU3-Lite after enabling
cpufreq-dt (when busy in a quite warm room). [0]

The patchset tries to fix this by adding CPU cooling device.
Unfortunately apparently I screwed something because on next-20160216
it does not help.

The fan works at full but CPU cooler is not enabled.

Patchset adds 2 additional trip points (so total 5). First 3 trip
points enable the fan. The new two trip points should trigger CPU
cooler.

However after reaching last fan trip point, the thermal zone stops
sending updates to the step-wise governor.
The last log for thermal_zone0 is:

[ 1366.604672] thermal thermal_zone0: last_temperature=71000, current_temperature=71000
[ 1366.604699] thermal thermal_zone0: Trip0[type=0,temp=50000]:trend=0,throttle=1
                                                     instance->upper:
                                                        instance->lower:
                                                           throttle:
[ 1366.604713] thermal cooling_device0: cur_state=0, 1, 0, throttle: 1
[ 1366.604725] thermal cooling_device0: CUR_state=0, 1, 0, throttle: 1
[ 1366.604735] thermal cooling_device0: old_target=1, target=1
[ 1366.604754] thermal thermal_zone0: Trip1[type=0,temp=60000]:trend=0,throttle=1
[ 1366.604776] thermal cooling_device0: cur_state=0, 2, 1, throttle: 1
[ 1366.604786] thermal cooling_device0: CUR_state=0, 2, 1, throttle: 1
[ 1366.604796] thermal cooling_device0: old_target=2, target=2
[ 1366.604810] thermal thermal_zone0: Trip2[type=0,temp=70000]:trend=0,throttle=1
[ 1366.604821] thermal cooling_device0: cur_state=0, 3, 2, throttle: 1
[ 1366.604832] thermal cooling_device0: CUR_state=0, 3, 2, throttle: 1
[ 1366.604841] thermal cooling_device0: old_target=3, target=3
[ 1366.604856] thermal thermal_zone0: Trip4[type=1,temp=90000]:trend=0,throttle=0
[ 1366.604869] thermal cooling_device1: cur_state=0, 3, 0, throttle: 0
[ 1366.604879] thermal cooling_device1: CUR_state=0, 3, 0, throttle: 0
[ 1366.604889] thermal cooling_device1: old_target=-1, target=-1
[ 1366.604901] thermal cooling_device2: cur_state=0, 3, 0, throttle: 0
[ 1366.604911] thermal cooling_device2: CUR_state=0, 3, 0, throttle: 0
[ 1366.604921] thermal cooling_device2: old_target=-1, target=-1
[ 1366.604935] thermal thermal_zone0: Trip5[type=1,temp=110000]:trend=0,throttle=0
[ 1366.604946] thermal cooling_device1: cur_state=0, 7, 7, throttle: 0
[ 1366.604957] thermal cooling_device1: CUR_state=0, 7, 7, throttle: 0
[ 1366.604967] thermal cooling_device1: old_target=-1, target=-1
[ 1366.604977] thermal cooling_device2: cur_state=0, 11, 11, throttle: 0
[ 1366.604988] thermal cooling_device2: CUR_state=0, 11, 11, throttle: 0
[ 1366.604997] thermal cooling_device2: old_target=-1, target=-1

After this, the temperature in zone0 rises but cooling devices do not
receive any pokes...

Did I make some mistake or this is thermal issue?


[0] http://www.spinics.net/lists/arm-kernel/msg482748.html


Best regards,
Krzysztof


Krzysztof Kozlowski (3):
  ARM: dts: Add cooling levels for CPUs on exynos5420
  ARM: dts: Add cooling levels for CPUs on exynos5422/5800
  ARM: dts: Don't overheat the Odroid XU3-Lite on high load

 arch/arm/boot/dts/exynos5420-cpus.dtsi        |  6 ++++
 arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 41 +++++++++++++++++++++++++++
 arch/arm/boot/dts/exynos5422-cpus.dtsi        |  6 ++++
 3 files changed, 53 insertions(+)

-- 
2.5.0



From k.kozlowski at samsung.com  Tue Feb 16 22:55:26 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 17 Feb 2016 15:55:26 +0900
Subject: [RFC 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420
In-Reply-To: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
References: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455692128-28504-2-git-send-email-k.kozlowski@samsung.com>

On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
12 steps for big core (700-1800 MHz). Add respective cooling cells.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---
 arch/arm/boot/dts/exynos5420-cpus.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
index 261d25173f61..498ae82e1cb2 100644
--- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
@@ -33,6 +33,9 @@
 			clock-frequency = <1800000000>;
 			cci-control-port = <&cci_control1>;
 			operating-points-v2 = <&cluster_a15_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <11>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu1: cpu at 1 {
@@ -70,6 +73,9 @@
 			clock-frequency = <1000000000>;
 			cci-control-port = <&cci_control0>;
 			operating-points-v2 = <&cluster_a7_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <7>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu5: cpu at 101 {
-- 
2.5.0



From k.kozlowski at samsung.com  Tue Feb 16 22:55:27 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 17 Feb 2016 15:55:27 +0900
Subject: [RFC 2/3] ARM: dts: Add cooling levels for CPUs on exynos5422/5800
In-Reply-To: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
References: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455692128-28504-3-git-send-email-k.kozlowski@samsung.com>

On Exynos5422 and Exynos5800 we support 12 cpufreq steps (200-1300 MHz) for LITTLE
and 18 steps for big core (200-1700 MHz). Add respective cooling cells.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---
 arch/arm/boot/dts/exynos5422-cpus.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi b/arch/arm/boot/dts/exynos5422-cpus.dtsi
index 9b46b9fbac4e..858bb7f57d76 100644
--- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -32,6 +32,9 @@
 			clock-frequency = <1000000000>;
 			cci-control-port = <&cci_control0>;
 			operating-points-v2 = <&cluster_a7_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <11>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu1: cpu at 101 {
@@ -69,6 +72,9 @@
 			clock-frequency = <1800000000>;
 			cci-control-port = <&cci_control1>;
 			operating-points-v2 = <&cluster_a15_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <15>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu5: cpu at 1 {
-- 
2.5.0



From k.kozlowski at samsung.com  Tue Feb 16 22:55:28 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 17 Feb 2016 15:55:28 +0900
Subject: [RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high load
In-Reply-To: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
References: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455692128-28504-4-git-send-email-k.kozlowski@samsung.com>

After adding cpufreq-dt support to Exynos542x, the Odroid XU3-Lite can
be easily overheated when launching eight CPU-intensive tasks:
	thermal thermal_zone3: critical temperature reached(121 C),shutting down

This seems to be specific to Odroid XU3-Lite board which officially
supports lower frequencies than regular XU3 or XU4. When working at
maximum CPU speed (1800 MHz big and 1300 MHz LITTLE) in warmer place for
longer time, the fan fails to cool down the board and it reaches
critical temperature.

Add CPU cooling to Exynos5422/5800 to fix this issue. When reaching 95
degrees of Celsius, the board will slow down by 3 steps (around
1400/1000 MHz). When reaching 110 degrees of Celsius go to 600 MHz.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---
 arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 41 +++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
index 2b289d7c0d13..66073ce29aee 100644
--- a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
@@ -34,6 +34,16 @@
 					hysteresis = <5000>; /* millicelsius */
 					type = "active";
 				};
+				cpu_alert3: cpu-alert-3 {
+					temperature = <95000>; /* millicelsius */
+					hysteresis = <5000>; /* millicelsius */
+					type = "passive";
+				};
+				cpu_alert4: cpu-alert-4 {
+					temperature = <110000>; /* millicelsius */
+					hysteresis = <5000>; /* millicelsius */
+					type = "passive";
+				};
 				cpu_crit0: cpu-crit-0 {
 					temperature = <120000>; /* millicelsius */
 					hysteresis = <0>; /* millicelsius */
@@ -53,6 +63,37 @@
 				     trip = <&cpu_alert2>;
 				     cooling-device = <&fan0 2 3>;
 				};
+
+				/*
+				 * When reaching cpu_alert3, reduce CPU
+				 * by 3 steps. On Exynos5422/5800 that would
+				 * be: 1400 MHz and 1000 MHz.
+				 */
+				map3 {
+				     trip = <&cpu_alert3>;
+				     cooling-device = <&cpu0 3 3>;
+				};
+				map4 {
+				     trip = <&cpu_alert3>;
+				     cooling-device = <&cpu4 3 3>;
+				};
+
+				/*
+				 * When reaching cpu_alert4, reduce CPU
+				 * to 600 MHz (11 steps for big, 7 steps for
+				 * LITTLE).
+				 * Exynos5420 has less OPPs and reversed
+				 * numbering of CPUs (big/LITTLE) so this
+				 * would not match.
+				 */
+				map5 {
+				     trip = <&cpu_alert4>;
+				     cooling-device = <&cpu0 7 7>;
+				};
+				map6 {
+				     trip = <&cpu_alert4>;
+				     cooling-device = <&cpu4 11 11>;
+				};
 			};
 		};
 	};
-- 
2.5.0



From heiko at sntech.de  Tue Feb 16 23:00:33 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Wed, 17 Feb 2016 08:00:33 +0100
Subject: [PATCH 6/6] ARM64: dts: rockchip: add core dtsi file for rk3399
In-Reply-To: <1455674476-16655-1-git-send-email-jay.xu@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <1455674476-16655-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <2396201.CBcovI4jc4@phil>

Hi Jianqun,

Am Mittwoch, 17. Februar 2016, 10:01:16 schrieb jianqun.xu:
> From: Xu Jianqun <jay.xu at rock-chips.com>
> 
> Add dtsi file for Rockchip rk3399 SoCs, which includes some
> general nodes such as cpu, pmu, cru, gic, amba and so on.
> 
> Change-Id: Ie3b824e8ead967d4cb119d73222b7a198478c29c

please remove any review-cruft like Change-Ids from mainline patches :-)

> Signed-off-by: Xu Jianqun <jay.xu at rock-chips.com>
> ---
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 989
> +++++++++++++++++++++++++++++++ 1 file changed, 989 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi new file mode 100644
> index 0000000..eb671f6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -0,0 +1,989 @@
> +/*
> + * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This library is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +#include <dt-bindings/clock/rk3399-cru.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/pinctrl/rockchip.h>
> +
> +/ {
> +	compatible = "rockchip,rk3399";
> +	interrupt-parent = <&gic>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	aliases {
> +		serial0 = &uart0;
> +		serial1 = &uart1;
> +		serial2 = &uart2;
> +		serial3 = &uart3;
> +	};
> +
> +	psci {
> +		compatible = "arm,psci";
> +		method = "smc";
> +	};
> +
> +	cpus {
> +		#address-cells = <2>;
> +		#size-cells = <0>;
> +
> +		cpu-map {
> +			cluster0 {
> +				core0 {
> +					cpu = <&cpu_l0>;
> +				};
> +				core1 {
> +					cpu = <&cpu_l1>;
> +				};
> +				core2 {
> +					cpu = <&cpu_l2>;
> +				};
> +				core3 {
> +					cpu = <&cpu_l3>;
> +				};
> +			};
> +
> +			cluster1 {
> +				core0 {
> +					cpu = <&cpu_b0>;
> +				};
> +				core1 {
> +					cpu = <&cpu_b1>;
> +				};
> +			};
> +		};
> +
> +		idle-states {
> +			entry-method = "psci";
> +
> +			cpu_sleep: cpu-sleep-0 {
> +				compatible = "arm,idle-state";
> +			};
> +		};

why the essentially empty idle-states, which is probably missing properties? 
In the absence of a real idle driver the kernel will fall back to 
arch_cpu_idle(), which already does WFI handling even on arm64.


> +
> +		cpu_l0: cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			reg = <0x0 0x0>;
> +			cpu-idle-states = <&cpu_sleep>;

that won't compile, as the referenced node is not present


> +			enable-method = "psci";
> +		};
> +
> +		cpu_l1: cpu at 1 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			reg = <0x0 0x1>;
> +			cpu-idle-states = <&cpu_sleep>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu_l2: cpu at 2 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			reg = <0x0 0x2>;
> +			cpu-idle-states = <&cpu_sleep>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu_l3: cpu at 3 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			reg = <0x0 0x3>;
> +			cpu-idle-states = <&cpu_sleep>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu_b0: cpu at 100 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a72", "arm,armv8";
> +			reg = <0x0 0x100>;
> +			cpu-idle-states = <&cpu_sleep>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu_b1: cpu at 101 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a72", "arm,armv8";
> +			reg = <0x0 0x101>;
> +			cpu-idle-states = <&cpu_sleep>;
> +			enable-method = "psci";
> +		};
> +	};
> +
> +	pmu {
> +		compatible = "arm,armv8-pmuv3";
> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
> +		interrupt-affinity = <&cpu_l0>, <&cpu_l1>, <&cpu_l2>,
> +				     <&cpu_l3>, <&cpu_b0>, <&cpu_b1>;
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts =
> +			<GIC_PPI 13
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,

shouldn't that be GIC_CPU_MASK_SIMPLE(6) instead of 4?


> +			<GIC_PPI 14
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			<GIC_PPI 11
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			<GIC_PPI 10
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> +		clock-frequency = <24000000>;
> +	};
> +
> +	xin24m: xin24m {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <24000000>;
> +		clock-output-names = "xin24m";
> +	};
> +
> +	gic: interrupt-controller at fee00000 {
> +		compatible = "arm,gic-v3";
> +		#interrupt-cells = <3>;
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +		interrupt-controller;
> +
> +		reg = <0x0 0xfee00000 0 0x10000>, /* GICD */
> +		      <0x0 0xfef00000 0 0xc0000>, /* GICR */
> +		      <0x0 0xfff00000 0 0x10000>, /* GICC */
> +		      <0x0 0xfff10000 0 0x10000>, /* GICH */
> +		      <0x0 0xfff20000 0 0x10000>; /* GICV */
> +		interrupts =
> +			<GIC_PPI 9
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;

again GIC_CPU_MASK_SIMPLE(6)?

> +		its: interrupt-controller at fee20000 {
> +			compatible = "arm,gic-v3-its";
> +			msi-controller;
> +			reg = <0x0 0xfee20000 0x0 0x20000>;
> +		};
> +	};
> +
> +	amba {
> +		compatible = "arm,amba-bus";
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		dmac_bus: dma-controller at ff6d0000 {
> +			compatible = "arm,pl330", "arm,primecell";
> +			reg = <0x0 0xff6d0000 0x0 0x4000>;
> +			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
> +			#dma-cells = <1>;
> +			clocks = <&cru ACLK_DMAC_BUS>;
> +			clock-names = "apb_pclk";

has the FLUSHP bug gotten fixed? That would be cool.


> +		};

rest looks nice on first glance :-)


Heiko


From viresh.kumar at linaro.org  Tue Feb 16 23:01:05 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Wed, 17 Feb 2016 12:31:05 +0530
Subject: [RFC 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420
In-Reply-To: <1455692128-28504-2-git-send-email-k.kozlowski@samsung.com>
References: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
 <1455692128-28504-2-git-send-email-k.kozlowski@samsung.com>
Message-ID: <20160217070105.GK2454@vireshk-i7>

On 17-02-16, 15:55, Krzysztof Kozlowski wrote:
> On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
> 12 steps for big core (700-1800 MHz). Add respective cooling cells.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> ---
>  arch/arm/boot/dts/exynos5420-cpus.dtsi | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
> index 261d25173f61..498ae82e1cb2 100644
> --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
> @@ -33,6 +33,9 @@
>  			clock-frequency = <1800000000>;
>  			cci-control-port = <&cci_control1>;
>  			operating-points-v2 = <&cluster_a15_opp_table>;
> +			cooling-min-level = <0>;
> +			cooling-max-level = <11>;
> +			#cooling-cells = <2>; /* min followed by max */
>  		};
>  
>  		cpu1: cpu at 1 {
> @@ -70,6 +73,9 @@
>  			clock-frequency = <1000000000>;
>  			cci-control-port = <&cci_control0>;
>  			operating-points-v2 = <&cluster_a7_opp_table>;
> +			cooling-min-level = <0>;
> +			cooling-max-level = <7>;
> +			#cooling-cells = <2>; /* min followed by max */
>  		};

Though it wouldn't matter (for the issue you are getting), but this should be
added for all the CPUs in case some other CPU is booted first.

-- 
viresh


From jamesjj.liao at mediatek.com  Tue Feb 16 23:01:35 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Wed, 17 Feb 2016 15:01:35 +0800
Subject: [PATCH v5 0/4] Mediatek MT2701 SCPSYS power domain support 
Message-ID: <1455692499-56828-1-git-send-email-jamesjj.liao@mediatek.com>

This patchset is based on v4.5-rc4 and adds scpsys power domain support
for Mediatek MT2701.

To share the code between MT2701 and MT8173, this patchset also refined
original mtk-scpsys.c to separate common codes and platform codes, so
that mtk-scpsys.c can support new SoCs more easily.

MT8173 and MT2701 scpsys init level are now subsys_init. Please refer to [1]
to see discussion details.

changes since v4:
- Rebase to v4.5-rc4.
- Remove mtk-scpsys.h and Merge its code into mtk-scpsys.c.
- Add names for every controlling registers and bits.
- Include dt-bindings headers at the beginning of mtk-scpsys.c.
- Sort compatible string in dt-binding documents.

changes since v3:
- Implement MT8173 and MT2701 scpsys drivers in a signle file.
- Remove naming of registers that can't be shared among SoCs.

changes since v2:
- Rebase to mbgg/linux-mediatek v4.4-next/soc [1].
- Remove MTK_SCPSYS_MT8173 and MTK_SCPSYS_MT2701.
- Modify scpsys dt-binding document to support MT2701.

changes since v1:
- Make MTK_SCPSYS in Kconfig invisible from users.
- Add comments for changing scpsys init level to subsys_init.

[1] http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003416.html

James Liao (2):
  soc: mediatek: Refine scpsys to support multiple platform
  soc: mediatek: Init MT8173 scpsys driver earlier

Shunli Wang (2):
  soc: mediatek: Add MT2701 power dt-bindings
  soc: mediatek: Add MT2701 scpsys driver

 .../devicetree/bindings/soc/mediatek/scpsys.txt    |   6 +-
 drivers/soc/mediatek/mtk-scpsys.c                  | 490 +++++++++++++++------
 include/dt-bindings/power/mt2701-power.h           |  27 ++
 3 files changed, 376 insertions(+), 147 deletions(-)
 create mode 100644 include/dt-bindings/power/mt2701-power.h

--
1.9.1



From jamesjj.liao at mediatek.com  Tue Feb 16 23:01:38 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Wed, 17 Feb 2016 15:01:38 +0800
Subject: [PATCH v5 3/4] soc: mediatek: Add MT2701 power dt-bindings
In-Reply-To: <1455692499-56828-1-git-send-email-jamesjj.liao@mediatek.com>
References: <1455692499-56828-1-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <1455692499-56828-4-git-send-email-jamesjj.liao@mediatek.com>

From: Shunli Wang <shunli.wang at mediatek.com>

Add power dt-bindings for MT2701.

Signed-off-by: Shunli Wang <shunli.wang at mediatek.com>
Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
---
 .../devicetree/bindings/soc/mediatek/scpsys.txt    |  6 +++--
 include/dt-bindings/power/mt2701-power.h           | 27 ++++++++++++++++++++++
 2 files changed, 31 insertions(+), 2 deletions(-)
 create mode 100644 include/dt-bindings/power/mt2701-power.h

diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
index e8f15e3..5f3d1c9 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -9,10 +9,12 @@ domain control.
 
 The driver implements the Generic PM domain bindings described in
 power/power_domain.txt. It provides the power domains defined in
-include/dt-bindings/power/mt8173-power.h.
+include/dt-bindings/power/mt8173-power.h and mt2701-power.h.
 
 Required properties:
-- compatible: Must be "mediatek,mt8173-scpsys"
+- compatible: Should be one of:
+	- "mediatek,mt2701-scpsys"
+	- "mediatek,mt8173-scpsys"
 - #power-domain-cells: Must be 1
 - reg: Address range of the SCPSYS unit
 - infracfg: must contain a phandle to the infracfg controller
diff --git a/include/dt-bindings/power/mt2701-power.h b/include/dt-bindings/power/mt2701-power.h
new file mode 100644
index 0000000..64cc826
--- /dev/null
+++ b/include/dt-bindings/power/mt2701-power.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2015 MediaTek Inc.
+ *
+ * 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.
+ */
+
+#ifndef _DT_BINDINGS_POWER_MT2701_POWER_H
+#define _DT_BINDINGS_POWER_MT2701_POWER_H
+
+#define MT2701_POWER_DOMAIN_CONN	0
+#define MT2701_POWER_DOMAIN_DISP	1
+#define MT2701_POWER_DOMAIN_MFG		2
+#define MT2701_POWER_DOMAIN_VDEC	3
+#define MT2701_POWER_DOMAIN_ISP		4
+#define MT2701_POWER_DOMAIN_BDP		5
+#define MT2701_POWER_DOMAIN_ETH		6
+#define MT2701_POWER_DOMAIN_HIF		7
+#define MT2701_POWER_DOMAIN_IFR_MSC	8
+
+#endif /* _DT_BINDINGS_POWER_MT2701_POWER_H */
-- 
1.9.1



From jamesjj.liao at mediatek.com  Tue Feb 16 23:01:37 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Wed, 17 Feb 2016 15:01:37 +0800
Subject: [PATCH v5 2/4] soc: mediatek: Init MT8173 scpsys driver earlier
In-Reply-To: <1455692499-56828-1-git-send-email-jamesjj.liao@mediatek.com>
References: <1455692499-56828-1-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <1455692499-56828-3-git-send-email-jamesjj.liao@mediatek.com>

Some power domain comsumers may init before module_init.
So the power domain provider (scpsys) need to be initialized
earlier too.

Take an example for our IOMMU (M4U) and SMI. SMI is a bridge
between IOMMU and multimedia HW. SMI is responsible to
enable/disable iommu and help transfer data for each multimedia
HW. Both of them have to wait until the power and clocks are
enabled.

So scpsys driver should be initialized before SMI, and SMI should
be initialized before IOMMU, and then init IOMMU consumers
(display/vdec/venc/camera etc.).

IOMMU is subsys_init by default. So we need to init scpsys driver
before subsys_init.

Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
---
 drivers/soc/mediatek/mtk-scpsys.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index 6d2874d..ebfc887 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -625,4 +625,21 @@ static struct platform_driver scpsys_drv = {
 		.of_match_table = of_match_ptr(of_scpsys_match_tbl),
 	},
 };
-builtin_platform_driver_probe(scpsys_drv, scpsys_probe);
+
+static int __init scpsys_drv_init(void)
+{
+	return platform_driver_probe(&scpsys_drv, scpsys_probe);
+}
+
+/*
+ * There are some Mediatek drivers which depend on the power domain driver need
+ * to probe in earlier initcall levels. So scpsys driver also need to probe
+ * earlier.
+ *
+ * IOMMU(M4U) and SMI drivers for example. SMI is a bridge between IOMMU and
+ * multimedia HW. IOMMU depends on SMI, and SMI is a power domain consumer,
+ * so the proper probe sequence should be scpsys -> SMI -> IOMMU driver.
+ * IOMMU drivers are initialized during subsys_init by default, so we need to
+ * move SMI and scpsys drivers to subsys_init or earlier init levels.
+ */
+subsys_initcall(scpsys_drv_init);
-- 
1.9.1



From jamesjj.liao at mediatek.com  Tue Feb 16 23:01:39 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Wed, 17 Feb 2016 15:01:39 +0800
Subject: [PATCH v5 4/4] soc: mediatek: Add MT2701 scpsys driver
In-Reply-To: <1455692499-56828-1-git-send-email-jamesjj.liao@mediatek.com>
References: <1455692499-56828-1-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <1455692499-56828-5-git-send-email-jamesjj.liao@mediatek.com>

From: Shunli Wang <shunli.wang at mediatek.com>

Add scpsys driver for MT2701.

Signed-off-by: Shunli Wang <shunli.wang at mediatek.com>
Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
---
 drivers/soc/mediatek/mtk-scpsys.c | 108 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 107 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index ebfc887..171fd8e 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -20,6 +20,7 @@
 #include <linux/regulator/consumer.h>
 #include <linux/soc/mediatek/infracfg.h>
 
+#include <dt-bindings/power/mt2701-power.h>
 #include <dt-bindings/power/mt8173-power.h>
 
 #define SPM_VDE_PWR_CON			0x0210
@@ -27,8 +28,13 @@
 #define SPM_VEN_PWR_CON			0x0230
 #define SPM_ISP_PWR_CON			0x0238
 #define SPM_DIS_PWR_CON			0x023c
+#define SPM_CONN_PWR_CON		0x0280
 #define SPM_VEN2_PWR_CON		0x0298
-#define SPM_AUDIO_PWR_CON		0x029c
+#define SPM_AUDIO_PWR_CON		0x029c	/* MT8173 */
+#define SPM_BDP_PWR_CON			0x029c	/* MT2701 */
+#define SPM_ETH_PWR_CON			0x02a0
+#define SPM_HIF_PWR_CON			0x02a4
+#define SPM_IFR_MSC_PWR_CON		0x02a8
 #define SPM_MFG_2D_PWR_CON		0x02c0
 #define SPM_MFG_ASYNC_PWR_CON		0x02c4
 #define SPM_USB_PWR_CON			0x02cc
@@ -42,10 +48,15 @@
 #define PWR_ON_2ND_BIT			BIT(3)
 #define PWR_CLK_DIS_BIT			BIT(4)
 
+#define PWR_STATUS_CONN			BIT(1)
 #define PWR_STATUS_DISP			BIT(3)
 #define PWR_STATUS_MFG			BIT(4)
 #define PWR_STATUS_ISP			BIT(5)
 #define PWR_STATUS_VDEC			BIT(7)
+#define PWR_STATUS_BDP			BIT(14)
+#define PWR_STATUS_ETH			BIT(15)
+#define PWR_STATUS_HIF			BIT(16)
+#define PWR_STATUS_IFR_MSC		BIT(17)
 #define PWR_STATUS_VENC_LT		BIT(20)
 #define PWR_STATUS_VENC			BIT(21)
 #define PWR_STATUS_MFG_2D		BIT(22)
@@ -469,6 +480,98 @@ static void mtk_register_power_domains(struct platform_device *pdev,
 }
 
 /*
+ * MT2701 power domain support
+ */
+
+static const struct scp_domain_data scp_domain_data_mt2701[] __initconst = {
+	[MT2701_POWER_DOMAIN_CONN] = {
+		.name = "conn",
+		.sta_mask = PWR_STATUS_CONN,
+		.ctl_offs = SPM_CONN_PWR_CON,
+		.bus_prot_mask = 0x0104,
+		.active_wakeup = true,
+	},
+	[MT2701_POWER_DOMAIN_DISP] = {
+		.name = "disp",
+		.sta_mask = PWR_STATUS_DISP,
+		.ctl_offs = SPM_DIS_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.clk_id = {CLK_MM},
+		.bus_prot_mask = 0x0002,
+		.active_wakeup = true,
+	},
+	[MT2701_POWER_DOMAIN_MFG] = {
+		.name = "mfg",
+		.sta_mask = PWR_STATUS_MFG,
+		.ctl_offs = SPM_MFG_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(12, 12),
+		.active_wakeup = true,
+	},
+	[MT2701_POWER_DOMAIN_VDEC] = {
+		.name = "vdec",
+		.sta_mask = PWR_STATUS_VDEC,
+		.ctl_offs = SPM_VDE_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(12, 12),
+		.clk_id = {CLK_MM},
+		.active_wakeup = true,
+	},
+	[MT2701_POWER_DOMAIN_ISP] = {
+		.name = "isp",
+		.sta_mask = PWR_STATUS_ISP,
+		.ctl_offs = SPM_ISP_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(13, 12),
+		.active_wakeup = true,
+	},
+	[MT2701_POWER_DOMAIN_BDP] = {
+		.name = "bdp",
+		.sta_mask = PWR_STATUS_BDP,
+		.ctl_offs = SPM_BDP_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.active_wakeup = true,
+	},
+	[MT2701_POWER_DOMAIN_ETH] = {
+		.name = "eth",
+		.sta_mask = PWR_STATUS_ETH,
+		.ctl_offs = SPM_ETH_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(15, 12),
+		.active_wakeup = true,
+	},
+	[MT2701_POWER_DOMAIN_HIF] = {
+		.name = "hif",
+		.sta_mask = PWR_STATUS_HIF,
+		.ctl_offs = SPM_HIF_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(15, 12),
+		.active_wakeup = true,
+	},
+	[MT2701_POWER_DOMAIN_IFR_MSC] = {
+		.name = "ifr_msc",
+		.sta_mask = PWR_STATUS_IFR_MSC,
+		.ctl_offs = SPM_IFR_MSC_PWR_CON,
+		.active_wakeup = true,
+	},
+};
+
+#define NUM_DOMAINS_MT2701	ARRAY_SIZE(scp_domain_data_mt2701)
+
+static int __init scpsys_probe_mt2701(struct platform_device *pdev)
+{
+	struct scp *scp;
+
+	scp = init_scp(pdev, scp_domain_data_mt2701, NUM_DOMAINS_MT2701);
+	if (IS_ERR(scp))
+		return PTR_ERR(scp);
+
+	mtk_register_power_domains(pdev, scp, NUM_DOMAINS_MT2701);
+
+	return 0;
+}
+
+/*
  * MT8173 power domain support
  */
 
@@ -597,6 +700,9 @@ static int __init scpsys_probe_mt8173(struct platform_device *pdev)
 
 static const struct of_device_id of_scpsys_match_tbl[] = {
 	{
+		.compatible = "mediatek,mt2701-scpsys",
+		.data = scpsys_probe_mt2701,
+	}, {
 		.compatible = "mediatek,mt8173-scpsys",
 		.data = scpsys_probe_mt8173,
 	}, {
-- 
1.9.1



From jamesjj.liao at mediatek.com  Tue Feb 16 23:01:36 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Wed, 17 Feb 2016 15:01:36 +0800
Subject: [PATCH v5 1/4] soc: mediatek: Refine scpsys to support multiple
 platform
In-Reply-To: <1455692499-56828-1-git-send-email-jamesjj.liao@mediatek.com>
References: <1455692499-56828-1-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <1455692499-56828-2-git-send-email-jamesjj.liao@mediatek.com>

Refine scpsys driver common code to support multiple SoC / platform.

Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
---
 drivers/soc/mediatek/mtk-scpsys.c | 363 +++++++++++++++++++++++---------------
 1 file changed, 220 insertions(+), 143 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
index 0221387..6d2874d 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -11,17 +11,15 @@
  * GNU General Public License for more details.
  */
 #include <linux/clk.h>
-#include <linux/delay.h>
+#include <linux/init.h>
 #include <linux/io.h>
-#include <linux/kernel.h>
 #include <linux/mfd/syscon.h>
-#include <linux/init.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
 #include <linux/pm_domain.h>
-#include <linux/regmap.h>
-#include <linux/soc/mediatek/infracfg.h>
 #include <linux/regulator/consumer.h>
+#include <linux/soc/mediatek/infracfg.h>
+
 #include <dt-bindings/power/mt8173-power.h>
 
 #define SPM_VDE_PWR_CON			0x0210
@@ -34,6 +32,7 @@
 #define SPM_MFG_2D_PWR_CON		0x02c0
 #define SPM_MFG_ASYNC_PWR_CON		0x02c4
 #define SPM_USB_PWR_CON			0x02cc
+
 #define SPM_PWR_STATUS			0x060c
 #define SPM_PWR_STATUS_2ND		0x0610
 
@@ -55,12 +54,12 @@
 #define PWR_STATUS_USB			BIT(25)
 
 enum clk_id {
-	MT8173_CLK_NONE,
-	MT8173_CLK_MM,
-	MT8173_CLK_MFG,
-	MT8173_CLK_VENC,
-	MT8173_CLK_VENC_LT,
-	MT8173_CLK_MAX,
+	CLK_NONE,
+	CLK_MM,
+	CLK_MFG,
+	CLK_VENC,
+	CLK_VENC_LT,
+	CLK_MAX,
 };
 
 #define MAX_CLKS	2
@@ -76,98 +75,6 @@ struct scp_domain_data {
 	bool active_wakeup;
 };
 
-static const struct scp_domain_data scp_domain_data[] __initconst = {
-	[MT8173_POWER_DOMAIN_VDEC] = {
-		.name = "vdec",
-		.sta_mask = PWR_STATUS_VDEC,
-		.ctl_offs = SPM_VDE_PWR_CON,
-		.sram_pdn_bits = GENMASK(11, 8),
-		.sram_pdn_ack_bits = GENMASK(12, 12),
-		.clk_id = {MT8173_CLK_MM},
-	},
-	[MT8173_POWER_DOMAIN_VENC] = {
-		.name = "venc",
-		.sta_mask = PWR_STATUS_VENC,
-		.ctl_offs = SPM_VEN_PWR_CON,
-		.sram_pdn_bits = GENMASK(11, 8),
-		.sram_pdn_ack_bits = GENMASK(15, 12),
-		.clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC},
-	},
-	[MT8173_POWER_DOMAIN_ISP] = {
-		.name = "isp",
-		.sta_mask = PWR_STATUS_ISP,
-		.ctl_offs = SPM_ISP_PWR_CON,
-		.sram_pdn_bits = GENMASK(11, 8),
-		.sram_pdn_ack_bits = GENMASK(13, 12),
-		.clk_id = {MT8173_CLK_MM},
-	},
-	[MT8173_POWER_DOMAIN_MM] = {
-		.name = "mm",
-		.sta_mask = PWR_STATUS_DISP,
-		.ctl_offs = SPM_DIS_PWR_CON,
-		.sram_pdn_bits = GENMASK(11, 8),
-		.sram_pdn_ack_bits = GENMASK(12, 12),
-		.clk_id = {MT8173_CLK_MM},
-		.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
-			MT8173_TOP_AXI_PROT_EN_MM_M1,
-	},
-	[MT8173_POWER_DOMAIN_VENC_LT] = {
-		.name = "venc_lt",
-		.sta_mask = PWR_STATUS_VENC_LT,
-		.ctl_offs = SPM_VEN2_PWR_CON,
-		.sram_pdn_bits = GENMASK(11, 8),
-		.sram_pdn_ack_bits = GENMASK(15, 12),
-		.clk_id = {MT8173_CLK_MM, MT8173_CLK_VENC_LT},
-	},
-	[MT8173_POWER_DOMAIN_AUDIO] = {
-		.name = "audio",
-		.sta_mask = PWR_STATUS_AUDIO,
-		.ctl_offs = SPM_AUDIO_PWR_CON,
-		.sram_pdn_bits = GENMASK(11, 8),
-		.sram_pdn_ack_bits = GENMASK(15, 12),
-		.clk_id = {MT8173_CLK_NONE},
-	},
-	[MT8173_POWER_DOMAIN_USB] = {
-		.name = "usb",
-		.sta_mask = PWR_STATUS_USB,
-		.ctl_offs = SPM_USB_PWR_CON,
-		.sram_pdn_bits = GENMASK(11, 8),
-		.sram_pdn_ack_bits = GENMASK(15, 12),
-		.clk_id = {MT8173_CLK_NONE},
-		.active_wakeup = true,
-	},
-	[MT8173_POWER_DOMAIN_MFG_ASYNC] = {
-		.name = "mfg_async",
-		.sta_mask = PWR_STATUS_MFG_ASYNC,
-		.ctl_offs = SPM_MFG_ASYNC_PWR_CON,
-		.sram_pdn_bits = GENMASK(11, 8),
-		.sram_pdn_ack_bits = 0,
-		.clk_id = {MT8173_CLK_MFG},
-	},
-	[MT8173_POWER_DOMAIN_MFG_2D] = {
-		.name = "mfg_2d",
-		.sta_mask = PWR_STATUS_MFG_2D,
-		.ctl_offs = SPM_MFG_2D_PWR_CON,
-		.sram_pdn_bits = GENMASK(11, 8),
-		.sram_pdn_ack_bits = GENMASK(13, 12),
-		.clk_id = {MT8173_CLK_NONE},
-	},
-	[MT8173_POWER_DOMAIN_MFG] = {
-		.name = "mfg",
-		.sta_mask = PWR_STATUS_MFG,
-		.ctl_offs = SPM_MFG_PWR_CON,
-		.sram_pdn_bits = GENMASK(13, 8),
-		.sram_pdn_ack_bits = GENMASK(21, 16),
-		.clk_id = {MT8173_CLK_NONE},
-		.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MFG_S |
-			MT8173_TOP_AXI_PROT_EN_MFG_M0 |
-			MT8173_TOP_AXI_PROT_EN_MFG_M1 |
-			MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT,
-	},
-};
-
-#define NUM_DOMAINS	ARRAY_SIZE(scp_domain_data)
-
 struct scp;
 
 struct scp_domain {
@@ -184,7 +91,7 @@ struct scp_domain {
 };
 
 struct scp {
-	struct scp_domain domains[NUM_DOMAINS];
+	struct scp_domain *domains;
 	struct genpd_onecell_data pd_data;
 	struct device *dev;
 	void __iomem *base;
@@ -412,57 +319,69 @@ static bool scpsys_active_wakeup(struct device *dev)
 	return scpd->active_wakeup;
 }
 
-static int __init scpsys_probe(struct platform_device *pdev)
+static void init_clks(struct platform_device *pdev, struct clk *clk[CLK_MAX])
+{
+	enum clk_id clk_ids[] = {
+		CLK_MM,
+		CLK_MFG,
+		CLK_VENC,
+		CLK_VENC_LT
+	};
+
+	static const char * const clk_names[] = {
+		"mm",
+		"mfg",
+		"venc",
+		"venc_lt",
+	};
+
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(clk_ids); i++)
+		clk[clk_ids[i]] = devm_clk_get(&pdev->dev, clk_names[i]);
+}
+
+static struct scp *init_scp(struct platform_device *pdev,
+			const struct scp_domain_data *scp_domain_data, int num)
 {
 	struct genpd_onecell_data *pd_data;
 	struct resource *res;
-	int i, j, ret;
+	int i, j;
 	struct scp *scp;
-	struct clk *clk[MT8173_CLK_MAX];
+	struct clk *clk[CLK_MAX];
 
 	scp = devm_kzalloc(&pdev->dev, sizeof(*scp), GFP_KERNEL);
 	if (!scp)
-		return -ENOMEM;
+		return ERR_PTR(-ENOMEM);
 
 	scp->dev = &pdev->dev;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	scp->base = devm_ioremap_resource(&pdev->dev, res);
 	if (IS_ERR(scp->base))
-		return PTR_ERR(scp->base);
-
-	pd_data = &scp->pd_data;
-
-	pd_data->domains = devm_kzalloc(&pdev->dev,
-			sizeof(*pd_data->domains) * NUM_DOMAINS, GFP_KERNEL);
-	if (!pd_data->domains)
-		return -ENOMEM;
-
-	clk[MT8173_CLK_MM] = devm_clk_get(&pdev->dev, "mm");
-	if (IS_ERR(clk[MT8173_CLK_MM]))
-		return PTR_ERR(clk[MT8173_CLK_MM]);
-
-	clk[MT8173_CLK_MFG] = devm_clk_get(&pdev->dev, "mfg");
-	if (IS_ERR(clk[MT8173_CLK_MFG]))
-		return PTR_ERR(clk[MT8173_CLK_MFG]);
-
-	clk[MT8173_CLK_VENC] = devm_clk_get(&pdev->dev, "venc");
-	if (IS_ERR(clk[MT8173_CLK_VENC]))
-		return PTR_ERR(clk[MT8173_CLK_VENC]);
-
-	clk[MT8173_CLK_VENC_LT] = devm_clk_get(&pdev->dev, "venc_lt");
-	if (IS_ERR(clk[MT8173_CLK_VENC_LT]))
-		return PTR_ERR(clk[MT8173_CLK_VENC_LT]);
+		return ERR_CAST(scp->base);
 
 	scp->infracfg = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
 			"infracfg");
 	if (IS_ERR(scp->infracfg)) {
 		dev_err(&pdev->dev, "Cannot find infracfg controller: %ld\n",
 				PTR_ERR(scp->infracfg));
-		return PTR_ERR(scp->infracfg);
+		return ERR_CAST(scp->infracfg);
 	}
 
-	for (i = 0; i < NUM_DOMAINS; i++) {
+	scp->domains = devm_kzalloc(&pdev->dev,
+				sizeof(*scp->domains) * num, GFP_KERNEL);
+	if (!scp->domains)
+		return ERR_PTR(-ENOMEM);
+
+	pd_data = &scp->pd_data;
+
+	pd_data->domains = devm_kzalloc(&pdev->dev,
+			sizeof(*pd_data->domains) * num, GFP_KERNEL);
+	if (!pd_data->domains)
+		return ERR_PTR(-ENOMEM);
+
+	for (i = 0; i < num; i++) {
 		struct scp_domain *scpd = &scp->domains[i];
 		const struct scp_domain_data *data = &scp_domain_data[i];
 
@@ -471,17 +390,31 @@ static int __init scpsys_probe(struct platform_device *pdev)
 			if (PTR_ERR(scpd->supply) == -ENODEV)
 				scpd->supply = NULL;
 			else
-				return PTR_ERR(scpd->supply);
+				return ERR_CAST(scpd->supply);
 		}
 	}
 
-	pd_data->num_domains = NUM_DOMAINS;
+	pd_data->num_domains = num;
 
-	for (i = 0; i < NUM_DOMAINS; i++) {
+	init_clks(pdev, clk);
+
+	for (i = 0; i < num; i++) {
 		struct scp_domain *scpd = &scp->domains[i];
 		struct generic_pm_domain *genpd = &scpd->genpd;
 		const struct scp_domain_data *data = &scp_domain_data[i];
 
+		for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) {
+			struct clk *c = clk[data->clk_id[j]];
+
+			if (IS_ERR(c)) {
+				dev_err(&pdev->dev, "%s: clk unavailable\n",
+					data->name);
+				return ERR_CAST(c);
+			}
+
+			scpd->clk[j] = c;
+		}
+
 		pd_data->domains[i] = genpd;
 		scpd->scp = scp;
 
@@ -491,13 +424,25 @@ static int __init scpsys_probe(struct platform_device *pdev)
 		scpd->sram_pdn_ack_bits = data->sram_pdn_ack_bits;
 		scpd->bus_prot_mask = data->bus_prot_mask;
 		scpd->active_wakeup = data->active_wakeup;
-		for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++)
-			scpd->clk[j] = clk[data->clk_id[j]];
 
 		genpd->name = data->name;
 		genpd->power_off = scpsys_power_off;
 		genpd->power_on = scpsys_power_on;
 		genpd->dev_ops.active_wakeup = scpsys_active_wakeup;
+	}
+
+	return scp;
+}
+
+static void mtk_register_power_domains(struct platform_device *pdev,
+				struct scp *scp, int num)
+{
+	struct genpd_onecell_data *pd_data;
+	int i, ret;
+
+	for (i = 0; i < num; i++) {
+		struct scp_domain *scpd = &scp->domains[i];
+		struct generic_pm_domain *genpd = &scpd->genpd;
 
 		/*
 		 * Initially turn on all domains to make the domains usable
@@ -516,6 +461,123 @@ static int __init scpsys_probe(struct platform_device *pdev)
 	 * valid.
 	 */
 
+	pd_data = &scp->pd_data;
+
+	ret = of_genpd_add_provider_onecell(pdev->dev.of_node, pd_data);
+	if (ret)
+		dev_err(&pdev->dev, "Failed to add OF provider: %d\n", ret);
+}
+
+/*
+ * MT8173 power domain support
+ */
+
+static const struct scp_domain_data scp_domain_data_mt8173[] __initconst = {
+	[MT8173_POWER_DOMAIN_VDEC] = {
+		.name = "vdec",
+		.sta_mask = PWR_STATUS_VDEC,
+		.ctl_offs = SPM_VDE_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(12, 12),
+		.clk_id = {CLK_MM},
+	},
+	[MT8173_POWER_DOMAIN_VENC] = {
+		.name = "venc",
+		.sta_mask = PWR_STATUS_VENC,
+		.ctl_offs = SPM_VEN_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(15, 12),
+		.clk_id = {CLK_MM, CLK_VENC},
+	},
+	[MT8173_POWER_DOMAIN_ISP] = {
+		.name = "isp",
+		.sta_mask = PWR_STATUS_ISP,
+		.ctl_offs = SPM_ISP_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(13, 12),
+		.clk_id = {CLK_MM},
+	},
+	[MT8173_POWER_DOMAIN_MM] = {
+		.name = "mm",
+		.sta_mask = PWR_STATUS_DISP,
+		.ctl_offs = SPM_DIS_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(12, 12),
+		.clk_id = {CLK_MM},
+		.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MM_M0 |
+			MT8173_TOP_AXI_PROT_EN_MM_M1,
+	},
+	[MT8173_POWER_DOMAIN_VENC_LT] = {
+		.name = "venc_lt",
+		.sta_mask = PWR_STATUS_VENC_LT,
+		.ctl_offs = SPM_VEN2_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(15, 12),
+		.clk_id = {CLK_MM, CLK_VENC_LT},
+	},
+	[MT8173_POWER_DOMAIN_AUDIO] = {
+		.name = "audio",
+		.sta_mask = PWR_STATUS_AUDIO,
+		.ctl_offs = SPM_AUDIO_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(15, 12),
+		.clk_id = {CLK_NONE},
+	},
+	[MT8173_POWER_DOMAIN_USB] = {
+		.name = "usb",
+		.sta_mask = PWR_STATUS_USB,
+		.ctl_offs = SPM_USB_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(15, 12),
+		.clk_id = {CLK_NONE},
+		.active_wakeup = true,
+	},
+	[MT8173_POWER_DOMAIN_MFG_ASYNC] = {
+		.name = "mfg_async",
+		.sta_mask = PWR_STATUS_MFG_ASYNC,
+		.ctl_offs = SPM_MFG_ASYNC_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = 0,
+		.clk_id = {CLK_MFG},
+	},
+	[MT8173_POWER_DOMAIN_MFG_2D] = {
+		.name = "mfg_2d",
+		.sta_mask = PWR_STATUS_MFG_2D,
+		.ctl_offs = SPM_MFG_2D_PWR_CON,
+		.sram_pdn_bits = GENMASK(11, 8),
+		.sram_pdn_ack_bits = GENMASK(13, 12),
+		.clk_id = {CLK_NONE},
+	},
+	[MT8173_POWER_DOMAIN_MFG] = {
+		.name = "mfg",
+		.sta_mask = PWR_STATUS_MFG,
+		.ctl_offs = SPM_MFG_PWR_CON,
+		.sram_pdn_bits = GENMASK(13, 8),
+		.sram_pdn_ack_bits = GENMASK(21, 16),
+		.clk_id = {CLK_NONE},
+		.bus_prot_mask = MT8173_TOP_AXI_PROT_EN_MFG_S |
+			MT8173_TOP_AXI_PROT_EN_MFG_M0 |
+			MT8173_TOP_AXI_PROT_EN_MFG_M1 |
+			MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT,
+	},
+};
+
+#define NUM_DOMAINS_MT8173	ARRAY_SIZE(scp_domain_data_mt8173)
+
+static int __init scpsys_probe_mt8173(struct platform_device *pdev)
+{
+	struct scp *scp;
+	struct genpd_onecell_data *pd_data;
+	int ret;
+
+	scp = init_scp(pdev, scp_domain_data_mt8173, NUM_DOMAINS_MT8173);
+	if (IS_ERR(scp))
+		return PTR_ERR(scp);
+
+	mtk_register_power_domains(pdev, scp, NUM_DOMAINS_MT8173);
+
+	pd_data = &scp->pd_data;
+
 	ret = pm_genpd_add_subdomain(pd_data->domains[MT8173_POWER_DOMAIN_MFG_ASYNC],
 		pd_data->domains[MT8173_POWER_DOMAIN_MFG_2D]);
 	if (ret && IS_ENABLED(CONFIG_PM))
@@ -526,21 +588,36 @@ static int __init scpsys_probe(struct platform_device *pdev)
 	if (ret && IS_ENABLED(CONFIG_PM))
 		dev_err(&pdev->dev, "Failed to add subdomain: %d\n", ret);
 
-	ret = of_genpd_add_provider_onecell(pdev->dev.of_node, pd_data);
-	if (ret)
-		dev_err(&pdev->dev, "Failed to add OF provider: %d\n", ret);
-
 	return 0;
 }
 
+/*
+ * scpsys driver init
+ */
+
 static const struct of_device_id of_scpsys_match_tbl[] = {
 	{
 		.compatible = "mediatek,mt8173-scpsys",
+		.data = scpsys_probe_mt8173,
 	}, {
 		/* sentinel */
 	}
 };
 
+static int __init scpsys_probe(struct platform_device *pdev)
+{
+	int (*probe)(struct platform_device *);
+	const struct of_device_id *of_id;
+
+	of_id = of_match_node(of_scpsys_match_tbl, pdev->dev.of_node);
+	if (!of_id || !of_id->data)
+		return -EINVAL;
+
+	probe = of_id->data;
+
+	return probe(pdev);
+}
+
 static struct platform_driver scpsys_drv = {
 	.driver = {
 		.name = "mtk-scpsys",
-- 
1.9.1



From k.kozlowski at samsung.com  Tue Feb 16 23:05:55 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 17 Feb 2016 16:05:55 +0900
Subject: [RFC 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420
In-Reply-To: <20160217070105.GK2454@vireshk-i7>
References: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
 <1455692128-28504-2-git-send-email-k.kozlowski@samsung.com>
 <20160217070105.GK2454@vireshk-i7>
Message-ID: <56C41BD3.3060202@samsung.com>

On 17.02.2016 16:01, Viresh Kumar wrote:
> On 17-02-16, 15:55, Krzysztof Kozlowski wrote:
>> On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
>> 12 steps for big core (700-1800 MHz). Add respective cooling cells.
>>
>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
>> ---
>>  arch/arm/boot/dts/exynos5420-cpus.dtsi | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> index 261d25173f61..498ae82e1cb2 100644
>> --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> @@ -33,6 +33,9 @@
>>  			clock-frequency = <1800000000>;
>>  			cci-control-port = <&cci_control1>;
>>  			operating-points-v2 = <&cluster_a15_opp_table>;
>> +			cooling-min-level = <0>;
>> +			cooling-max-level = <11>;
>> +			#cooling-cells = <2>; /* min followed by max */
>>  		};
>>  
>>  		cpu1: cpu at 1 {
>> @@ -70,6 +73,9 @@
>>  			clock-frequency = <1000000000>;
>>  			cci-control-port = <&cci_control0>;
>>  			operating-points-v2 = <&cluster_a7_opp_table>;
>> +			cooling-min-level = <0>;
>> +			cooling-max-level = <7>;
>> +			#cooling-cells = <2>; /* min followed by max */
>>  		};
> 
> Though it wouldn't matter (for the issue you are getting), but this should be
> added for all the CPUs in case some other CPU is booted first.

Thanks! I'll fix it also for patch 2/3.

Best regards,
Krzysztof



From m.szyprowski at samsung.com  Tue Feb 16 23:06:14 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed, 17 Feb 2016 08:06:14 +0100
Subject: [PATCH] ARM64: dma-mapping: fix handling of devices registered
 before arch_initcall
In-Reply-To: <56C37317.9020104@arm.com>
References: <1455632084-14666-1-git-send-email-m.szyprowski@samsung.com>
 <56C37317.9020104@arm.com>
Message-ID: <56C41BE6.5000203@samsung.com>

Hello,

On 2016-02-16 20:05, Robin Murphy wrote:
> On 16/02/16 14:14, Marek Szyprowski wrote:
>> This patch ensures that devices, which got registered before 
>> arch_initcall
>> will be handled correctly by IOMMU-based DMA-mapping code.
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
>> ---
>>   arch/arm64/mm/dma-mapping.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>> index 573b1e6..ce6019f 100644
>> --- a/arch/arm64/mm/dma-mapping.c
>> +++ b/arch/arm64/mm/dma-mapping.c
>> @@ -928,6 +928,10 @@ static int __init __iommu_dma_init(void)
>>           ret = register_iommu_dma_ops_notifier(&platform_bus_type);
>>       if (!ret)
>>           ret = register_iommu_dma_ops_notifier(&amba_bustype);
>> +
>> +    /* handle devices queued before this arch_initcall */
>> +    if (!ret)
>> +        __iommu_attach_notifier(NULL, BUS_NOTIFY_ADD_DEVICE, NULL);
>
> Hmm, surely unless *all* the devices on the relevant buses are created 
> before arch_initcall level, then the next one is going to kick off the 
> notifier to walk the whole list anyway. Have you seen this being a 
> problem in practice?

Yes, I've observed such situation, that's why I've posted this patch. I was
really surprised that this code doesn't handle all cases.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From jay.xu at rock-chips.com  Tue Feb 16 23:23:14 2016
From: jay.xu at rock-chips.com (Jianqun Xu)
Date: Wed, 17 Feb 2016 15:23:14 +0800
Subject: [PATCH 4/6] pinctrl: rockchip: add bindings for rk3399 pinctrl
In-Reply-To: <19942952.P4nUQKPo3g@phil>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <1455673992-16469-5-git-send-email-jay.xu@rock-chips.com>
 <19942952.P4nUQKPo3g@phil>
Message-ID: <56C41FE2.8020800@rock-chips.com>



? 17/02/2016 14:47, Heiko Stuebner ??:
> Hi Jianqun,
>
> Am Mittwoch, 17. Februar 2016, 09:53:10 schrieb jianqun.xu:
>> From: Xu Jianqun <jay.xu at rock-chips.com>
>>
>> Add devicetree bindings for pinctrl found on rk3399
>> processors from rockchip.
>>
>> Signed-off-by: Xu Jianqun <jay.xu at rock-chips.com>
>> ---
>>   Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
>> b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index
>> 0cd701b..c68b955 100644
>> --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
>> +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
>> @@ -22,7 +22,7 @@ Required properties for iomux controller:
>>     - compatible: one of "rockchip,rk2928-pinctrl",
>> "rockchip,rk3066a-pinctrl" "rockchip,rk3066b-pinctrl",
>> "rockchip,rk3188-pinctrl"
>>   		       "rockchip,rk3228-pinctrl", "rockchip,rk3288-pinctrl"
>> -		       "rockchip,rk3368-pinctrl"
>> +		       "rockchip,rk3368-pinctrl", "rockchip,rk3399-pinctrl"
>>     - rockchip,grf: phandle referencing a syscon providing the
>>   	 "general register files"
>
> that is already contained in David's core pinctrl patch that already got
> applied to the pinctrl tree.
>
Sorry very much, I forgot it after a long time of spring holiday
thanks
>
> Heiko
>
>
>



From zlim.lnx at gmail.com  Tue Feb 16 23:32:57 2016
From: zlim.lnx at gmail.com (Zi Shen Lim)
Date: Tue, 16 Feb 2016 23:32:57 -0800
Subject: [PATCH 4/4] arm64: cputype info for Broadcom Vulcan
In-Reply-To: <1455389195-31870-5-git-send-email-jchandra@broadcom.com>
References: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
 <1455389195-31870-5-git-send-email-jchandra@broadcom.com>
Message-ID: <CAMDttNc-L0_zg_skNg9CyVT8mGgyZQZTLgCdMMGExxwqhSSPDQ@mail.gmail.com>

On Sat, Feb 13, 2016 at 10:46 AM, Jayachandran C <jchandra at broadcom.com> wrote:
>
> Add Broadcom Vulcan implementor ID and part ID in cputype.h. This is
> to document the values.
>
> Signed-off-by: Jayachandran C <jchandra at broadcom.com>
> ---
>  arch/arm64/include/asm/cputype.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
> index 1a59493..3725d59 100644
> --- a/arch/arm64/include/asm/cputype.h
> +++ b/arch/arm64/include/asm/cputype.h
> @@ -65,6 +65,7 @@
>  #define ARM_CPU_IMP_ARM                        0x41
>  #define ARM_CPU_IMP_APM                        0x50
>  #define ARM_CPU_IMP_CAVIUM             0x43
> +#define ARM_CPU_IMP_BRCM               0x42

It's probably not a big deal... guessing this list is chronologically
ordered and should remain so?

>
>  #define ARM_CPU_PART_AEM_V8            0xD0F
>  #define ARM_CPU_PART_FOUNDATION                0xD00
> @@ -74,6 +75,7 @@
>  #define APM_CPU_PART_POTENZA           0x000
>
>  #define CAVIUM_CPU_PART_THUNDERX       0x0A1
> +#define BRCM_CPU_PART_VULCAN           0x516
>
>  #ifndef __ASSEMBLY__
>
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From alison.wang at nxp.com  Tue Feb 16 23:39:06 2016
From: alison.wang at nxp.com (Huan Wang)
Date: Wed, 17 Feb 2016 07:39:06 +0000
Subject: [PATCH] dts: ls102xa: ifc: Add the partition for NOR flash
In-Reply-To: <20160214034444.GG6756@tiger>
References: <1454487404-330-1-git-send-email-b18965@freescale.com>
 <20160214034444.GG6756@tiger>
Message-ID: <VI1PR04MB16006272AA234EA44F8A2EC9F4AE0@VI1PR04MB1600.eurprd04.prod.outlook.com>

> On Wed, Feb 03, 2016 at 04:16:44PM +0800, Alison Wang wrote:
> > According to the new mapping table, the partition for NOR flash is
> > added.
> 
> How do you know that everyone using the board wants the NOR flash to be
> partitioned this way?  It's really a matter of software configuration
> and may vary from system to system.
>
[Alison Wang] Yes, the different partition could be used too. I just want to
provide one partition way.

Best Regards,
Alison Wang
> 
> >
> > Signed-off-by: Alison Wang <alison.wang at nxp.com>
> > ---
> >  arch/arm/boot/dts/ls1021a-qds.dts | 60
> > +++++++++++++++++++++++++++++++++++++++
> >  arch/arm/boot/dts/ls1021a-twr.dts | 60
> > +++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 120 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/ls1021a-qds.dts
> > b/arch/arm/boot/dts/ls1021a-qds.dts
> > index 9408753..904ee09 100644
> > --- a/arch/arm/boot/dts/ls1021a-qds.dts
> > +++ b/arch/arm/boot/dts/ls1021a-qds.dts
> > @@ -237,6 +237,66 @@
> >  		reg = <0x0 0x0 0x8000000>;
> >  		bank-width = <2>;
> >  		device-width = <1>;
> > +
> > +		partition at 0 {
> > +			/* 128KB for bank0 RCW */
> > +			reg = <0x00000000 0x00020000>;
> > +			label = "NOR bank0 RCW Image";
> > +		};
> > +
> > +		partition at 100000 {
> > +			/* 1MB for bank0 u-boot Image */
> > +			reg = <0x00100000 0x00100000>;
> > +			label = "NOR bank0 u-boot Image";
> > +		};
> > +
> > +		partition at 200000 {
> > +			/* 1MB for bank0 DTB */
> > +			reg = <0x00200000 0x00100000>;
> > +			label = "NOR bank0 DTB Image";
> > +		};
> > +
> > +		partition at 300000 {
> > +			/* 7MB for bank0 Linux Kernel */
> > +			reg = <0x00300000 0x00700000>;
> > +			label = "NOR bank0 Linux Kernel Image";
> > +		};
> > +
> > +		partition at a00000 {
> > +			/* 54MB for bank0 Ramdisk Root File System */
> > +			reg = <0x00a00000 0x03600000>;
> > +			label = "NOR bank0 Ramdisk Root File System Image";
> > +		};
> > +
> > +		partition at 4000000 {
> > +			/* 128KB for bank4 RCW */
> > +			reg = <0x04000000 0x00020000>;
> > +			label = "NOR bank4 RCW Image";
> > +		};
> > +
> > +		partition at 4100000 {
> > +			/* 1MB for bank4 u-boot Image */
> > +			reg = <0x04100000 0x00100000>;
> > +			label = "NOR bank4 u-boot Image";
> > +		};
> > +
> > +		partition at 4200000 {
> > +			/* 1MB for bank4 DTB */
> > +			reg = <0x04200000 0x00100000>;
> > +			label = "NOR bank4 DTB Image";
> > +		};
> > +
> > +		partition at 4300000 {
> > +			/* 7MB for bank4 Linux Kernel */
> > +			reg = <0x04300000 0x00700000>;
> > +			label = "NOR bank4 Linux Kernel Image";
> > +		};
> > +
> > +		partition at 4a00000 {
> > +			/* 54MB for bank4 Ramdisk Root File System */
> > +			reg = <0x04a00000 0x03600000>;
> > +			label = "NOR bank4 Ramdisk Root File System Image";
> > +		};
> >  	};
> >
> >  	fpga: board-control at 3,0 {
> > diff --git a/arch/arm/boot/dts/ls1021a-twr.dts
> > b/arch/arm/boot/dts/ls1021a-twr.dts
> > index 75ecaed..f5e9616 100644
> > --- a/arch/arm/boot/dts/ls1021a-twr.dts
> > +++ b/arch/arm/boot/dts/ls1021a-twr.dts
> > @@ -194,6 +194,66 @@
> >  		reg = <0x0 0x0 0x8000000>;
> >  		bank-width = <2>;
> >  		device-width = <1>;
> > +
> > +		partition at 0 {
> > +			/* 128KB for bank0 RCW */
> > +			reg = <0x00000000 0x00020000>;
> > +			label = "NOR bank0 RCW Image";
> > +		};
> > +
> > +		partition at 100000 {
> > +			/* 1MB for bank0 u-boot Image */
> > +			reg = <0x00100000 0x00100000>;
> > +			label = "NOR bank0 u-boot Image";
> > +		};
> > +
> > +		partition at 200000 {
> > +			/* 1MB for bank0 DTB */
> > +			reg = <0x00200000 0x00100000>;
> > +			label = "NOR bank0 DTB Image";
> > +		};
> > +
> > +		partition at 300000 {
> > +			/* 7MB for bank0 Linux Kernel */
> > +			reg = <0x00300000 0x00700000>;
> > +			label = "NOR bank0 Linux Kernel Image";
> > +		};
> > +
> > +		partition at a00000 {
> > +			/* 54MB for bank0 Ramdisk Root File System */
> > +			reg = <0x00a00000 0x03600000>;
> > +			label = "NOR bank0 Ramdisk Root File System Image";
> > +		};
> > +
> > +		partition at 4000000 {
> > +			/* 128KB for bank4 RCW */
> > +			reg = <0x04000000 0x00020000>;
> > +			label = "NOR bank4 RCW Image";
> > +		};
> > +
> > +		partition at 4100000 {
> > +			/* 1MB for bank4 u-boot Image */
> > +			reg = <0x04100000 0x00100000>;
> > +			label = "NOR bank4 u-boot Image";
> > +		};
> > +
> > +		partition at 4200000 {
> > +			/* 1MB for bank4 DTB */
> > +			reg = <0x04200000 0x00100000>;
> > +			label = "NOR bank4 DTB Image";
> > +		};
> > +
> > +		partition at 4300000 {
> > +			/* 7MB for bank4 Linux Kernel */
> > +			reg = <0x04300000 0x00700000>;
> > +			label = "NOR bank4 Linux Kernel Image";
> > +		};
> > +
> > +		partition at 4a00000 {
> > +			/* 54MB for bank4 Ramdisk Root File System */
> > +			reg = <0x04a00000 0x03600000>;
> > +			label = "NOR bank4 Ramdisk Root File System Image";
> > +		};
> >  	};
> >  };
> >
> > --
> > 2.1.0.27.g96db324
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >


From marc.zyngier at arm.com  Tue Feb 16 23:47:40 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 07:47:40 +0000
Subject: [PATCH v2 4/5] irqchip:create irq domain for each mbigen device
In-Reply-To: <56C3F4AC.8020807@huawei.com>
References: <1455604648-20668-1-git-send-email-majun258@huawei.com>
 <1455604648-20668-5-git-send-email-majun258@huawei.com>
 <20160216085024.3f573f40@arm.com> <56C3F4AC.8020807@huawei.com>
Message-ID: <20160217074740.439c53b4@arm.com>

On Wed, 17 Feb 2016 12:18:52 +0800
"majun (F)" <majun258 at huawei.com> wrote:

> 
> 
> ? 2016/2/16 16:50, Marc Zyngier ??:
> > On Tue, 16 Feb 2016 14:37:27 +0800
> > MaJun <majun258 at huawei.com> wrote:
> > 
> >> From: Ma Jun <majun258 at huawei.com>
> [...]
> >> +	unsigned int nid;
> >> +
> >> +	nid = get_mbigen_nid(hwirq);
> >> +
> >> +	if (nid < 4)
> >> +		return (nid * 4) + REG_MBIGEN_VEC_OFFSET;
> >> +	else
> >> +		return (nid - 4) * 4 + REG_MBIGEN_EXT_VEC_OFFSET;
> >> +}
> >> +
> >> +static struct irq_chip mbigen_irq_chip = {
> >> +	.name =			"mbigen-v1",
> >> +};
> >> +
> >> +static void mbigen_write_msg(struct msi_desc *desc, struct msi_msg *msg)
> >> +{
> >> +	/* The address of doorbell is encoded in mbigen register by default
> >> +	 * So,we don't need to program the doorbell address at here
> >> +	 * Besides, the event ID is decided by the hardware pin number,
> >> +	 * we can't change it in software.So, we don't need to encode the
> >> +	 * event ID in mbigen register.
> >> +	 */
> > 
> > Really? What if tomorrow I decide to change the EventID allocation
> > policy in the ITS driver? Have your HW engineers really baked the
> > behaviour of the Linux driver into the device?
> > 
> 
> Yes.
> If we really need to support this chip,is there
> any possible solution for this problem?

You would have to provide some sort of lookup table from the
device-tree, or find a way to pass this information down the ITS code.

The real question is: do we take this as it is and fix it once it
breaks? or do we mandate a proper solution before this has a remote
chance of getting in?

At the moment, I don't know, because the idea of hardcoded MSIs is so
wrong and so against the way the whole stack works that I just want to
say no to this and run away.

I need to think.

	M.
-- 
Jazz is not dead. It just smells funny.


From hverkuil at xs4all.nl  Tue Feb 16 23:47:44 2016
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Wed, 17 Feb 2016 08:47:44 +0100
Subject: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video
 Encoder Driver
In-Reply-To: <1455604653.19396.68.camel@mtksdaap41>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
 <56C1B4AF.1030207@xs4all.nl> <1455604653.19396.68.camel@mtksdaap41>
Message-ID: <56C425A0.6080005@xs4all.nl>

On 02/16/2016 07:37 AM, tiffany lin wrote:
>>> +static int fops_vcodec_open(struct file *file)
>>> +{
>>> +	struct video_device *vfd = video_devdata(file);
>>> +	struct mtk_vcodec_dev *dev = video_drvdata(file);
>>> +	struct mtk_vcodec_ctx *ctx = NULL;
>>> +	int ret = 0;
>>> +
>>> +	mutex_lock(&dev->dev_mutex);
>>> +
>>> +	ctx = devm_kzalloc(&dev->plat_dev->dev, sizeof(*ctx), GFP_KERNEL);
>>> +	if (!ctx) {
>>> +		ret = -ENOMEM;
>>> +		goto err_alloc;
>>> +	}
>>> +
>>> +	if (dev->num_instances >= MTK_VCODEC_MAX_ENCODER_INSTANCES) {
>>> +		mtk_v4l2_err("Too many open contexts\n");
>>> +		ret = -EBUSY;
>>> +		goto err_no_ctx;
>>
>> Hmm. I never like it if you can't open a video node because of a reason like this.
>>
>> I.e. a simple 'v4l2-ctl -D' (i.e. calling QUERYCAP) should never fail.
>>
>> If there are hardware limitation that prevent more than X instances from running at
>> the same time, then those limitations typically kick in when you start to stream
>> (or possibly when calling REQBUFS). But before that it should always be possible to
>> open the device.
>>
>> Having this check at open() is an indication of a poor design.
>>
>> Is this is a hardware limitation at all?
>>
> This is to make sure performance meet requirements, such as bitrate and
> framerate.

Is it the driver's job to make enforce this? What if the application only
deals with low-res video, but wants to encode a lot of those? Or is encoding
a video off-line?

The driver generally doesn't know the use-case, so if this is an artificial
limitation as opposed to a hardware limitation, then I would just drop this.

Regards,

	Hans

> We got your point. We will remove this and move limitation control to
> start_streaming or REQBUFS.
> Appreciated for your suggestion.:)
> 
> 
>>> +	}



From m.szyprowski at samsung.com  Tue Feb 16 23:52:36 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed, 17 Feb 2016 08:52:36 +0100
Subject: [PATCH v5 RESEND 4/5] ARM: amba: Move reading of periphid to
 amba_match()
In-Reply-To: <20160215175250.GJ10826@n2100.arm.linux.org.uk>
References: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
 <1455101250-11327-5-git-send-email-m.szyprowski@samsung.com>
 <20160215175250.GJ10826@n2100.arm.linux.org.uk>
Message-ID: <56C426C4.7040907@samsung.com>

Hello,

On 2016-02-15 18:52, Russell King - ARM Linux wrote:
> On Wed, Feb 10, 2016 at 11:47:29AM +0100, Marek Szyprowski wrote:
>> From: Tomeu Vizoso <tomeu.vizoso at collabora.com>
>>
>> Reading the periphid when the Primecell device is registered means that
>> the apb pclk must be available by then or the device won't be registered
>> at all.
>>
>> By reading the periphid in amba_match() we can return -EPROBE_DEFER if
>> the apb pclk isn't there yet and the device will be retried later.
> I've just realised, we can't do this.  We need to read the peripheral
> ID at registration time, because that's published to userspace via
> (a) a sysfs attribute, and (b) as part of the uevent, which will be
> used by udev to locate the driver module.
>
> So, this will have the side effect of breaking systems which have
> AMBA primecell devices configured as modules.
>
> Sorry, I can't apply this.  We can't regress existing platforms for
> the sake of introducing new platforms to this code.

Then the only solution right now I see is to get back to v1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/388199.html
which at least handles correctly device registration when power domain 
driver
is available. You pointed that the patch cannot be applied, because failure
of dev_pm_domain_attach() will be fatal for device registration. Right now
lack of such call is fatal for the whole system, so there is really not a
big difference. Please also note that amba_get_enable_pclk() calls 
clk_get(),
which also might return -EPROBE_DEFER, which already breaks device
registration the same way.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From LW at KARO-electronics.de  Tue Feb 16 23:55:02 2016
From: LW at KARO-electronics.de (Lothar =?UTF-8?B?V2HDn21hbm4=?=)
Date: Wed, 17 Feb 2016 08:55:02 +0100
Subject: noise issues when recording sound on i.MX28
In-Reply-To: <CAOMZO5BDjkWi+cQK1-J7ag8Z48tY1Uwofi4EkovN-drSC4_reA@mail.gmail.com>
References: <20160127105613.GC13664@pengutronix.de>
 <CAOMZO5BpLen517q2heramSta-R6pdESkjM6w=7FRMZebY6ue-Q@mail.gmail.com>
 <20160127144340.GD13664@pengutronix.de>
 <CAOMZO5AE6HwBYz7kOFORt0HTojJLSb0MYUbkb_HCshDHy=d27g@mail.gmail.com>
 <20160210150315.GC13664@pengutronix.de>
 <CAOMZO5D5H4F90nse9kyW9KvsJStN-sCGktup4FDPw_zTeNfS2g@mail.gmail.com>
 <20160211084029.GE13664@pengutronix.de>
 <CAOMZO5BDjkWi+cQK1-J7ag8Z48tY1Uwofi4EkovN-drSC4_reA@mail.gmail.com>
Message-ID: <20160217085502.39e4cb24@ipc1.ka-ro>

Hi,

On Tue, 16 Feb 2016 13:01:19 -0200 Fabio Estevam wrote:
> On Thu, Feb 11, 2016 at 6:40 AM, Uwe Kleine-K?nig
> <u.kleine-koenig at pengutronix.de> wrote:
> 
> > root at hostname:/sys/kernel/debug/clk find -name saif?_sel
> > ./ref_xtal/pll0/saif0_sel
> > ./ref_xtal/pll0/saif1_sel
> >
> > root at hostname:/sys/kernel/debug/clk cat ./ref_xtal/pll0/saif?_sel/clk_rate
> > 480000000
> > 480000000
> 
> Ok, what about the SAIF0 and SAIF1 sampling rates: are they always the same?
>
Yes, of course. The driver wouldn't allow using both interfaces with
different sample rates any way.


Lothar Wa?mann


From tiffany.lin at mediatek.com  Wed Feb 17 00:01:08 2016
From: tiffany.lin at mediatek.com (tiffany lin)
Date: Wed, 17 Feb 2016 16:01:08 +0800
Subject: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2
 Video Encoder Driver
In-Reply-To: <56C328AF.5030604@cisco.com>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
 <56C1B4AF.1030207@xs4all.nl> <1455604653.19396.68.camel@mtksdaap41>
 <56C2D371.9090805@xs4all.nl> <1455628805.19396.82.camel@mtksdaap41>
 <56C328AF.5030604@cisco.com>
Message-ID: <1455696068.26202.4.camel@mtksdaap41>

On Tue, 2016-02-16 at 14:48 +0100, Hans Verkuil wrote:
> Hi Tiffany,
> 
> >>>>> +int mtk_vcodec_enc_queue_init(void *priv, struct vb2_queue *src_vq,
> >>>>> +			   struct vb2_queue *dst_vq)
> >>>>> +{
> >>>>> +	struct mtk_vcodec_ctx *ctx = priv;
> >>>>> +	int ret;
> >>>>> +
> >>>>> +	src_vq->type		= V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
> >>>>> +	src_vq->io_modes	= VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
> >>>>
> >>>> I recomment dropping VB2_USERPTR. That only makes sense for scatter-gather dma,
> >>>> and you use physically contiguous DMA.
> >>>>
> >>> Now our userspace app use VB2_USERPTR. I need to check if we could drop
> >>> VB2_USERPTR.
> >>> We use src_vq->mem_ops = &vb2_dma_contig_memops;
> >>> And there are
> >>> 	.get_userptr	= vb2_dc_get_userptr,
> >>> 	.put_userptr	= vb2_dc_put_userptr,
> >>> I was confused why it only make sense for scatter-gather.
> >>> Could you kindly explain more?
> >>
> >> VB2_USERPTR indicates that the application can use malloc to allocate buffers
> >> and pass those to the driver. Since malloc uses virtual memory the physical
> >> memory is scattered all over. And the first page typically does not start at
> >> the beginning of the page but at a random offset.
> >>
> >> To support that the DMA generally has to be able to do scatter-gather.
> >>
> >> Now, where things get ugly is that a hack was added to the USERPTR support where
> >> apps could pass a pointer to physically contiguous memory as a user pointer. This
> >> was a hack for embedded systems that preallocated a pool of buffers and needed to
> >> pass those pointers around somehow. So the dma-contig USERPTR support is for that
> >> 'feature'. If you try to pass a malloc()ed buffer to a dma-contig driver it will
> >> reject it. One big problem is that this specific hack isn't signaled anywhere, so
> >> applications have no way of knowing if the USERPTR support is the proper version
> >> or the hack where physically contiguous memory is expected.
> >>
> >> This hack has been replaced with DMABUF which is the proper way of passing buffers
> >> around.
> >>
> >> New dma-contig drivers should not use that old hack anymore. Use dmabuf to pass
> >> external buffers around.
> >>
> >> How do you use it in your app? With malloc()ed buffers? Or with 'special' pointers
> >> to physically contiguous buffers?
> >>
> > Understood now. Thanks for your explanation.
> > Now our app use malloc()ed buffers and we hook vb2_dma_contig_memops. 
> > I don't know why that dma-contig driver do not reject it.
> > I will try to figure it out.
> 
> Is there an iommu involved that turns the scatter-gather list into what looks like
> contiguous memory for the DMA?
> 
Yes, We have iommu that could make scatter-gather list looks like
contiguous memory.

> At the end of vb2_dc_get_userptr() in videobuf2-dma-contig.c there is a check
> 'if (contig_size < size)' that verifies that the sg DMA is contiguous. This would
> work if there is an iommu involved (if I understand it correctly).
> 
I see. We saw this error before we add iommu support.

> If that's the case, then it's OK to keep VB2_USERPTR because you have real sg
> support (although not via the DMA engine, but via iommu mappings).
> 
Got it. We will keep VB2_USERPTR.

> Regards,
> 
> 	Hans




From heiko.carstens at de.ibm.com  Wed Feb 17 00:22:10 2016
From: heiko.carstens at de.ibm.com (Heiko Carstens)
Date: Wed, 17 Feb 2016 09:22:10 +0100
Subject: [PATCH 1/5] all: s390: move wrapper infrastructure to generic
 headers
In-Reply-To: <20160202204156.GA27290@yury-N73SV>
References: <1453741047-5498-1-git-send-email-ynorov@caviumnetworks.com>
 <1453741047-5498-2-git-send-email-ynorov@caviumnetworks.com>
 <20160128121618.GB5418@osiris> <20160128163109.GA8529@yury-N73SV>
 <20160201114251.GB973@yury-N73SV> <20160202073913.GB3990@osiris>
 <20160202154331.GA3003@yury-N73SV> <20160202160826.GF3990@osiris>
 <20160202195434.GA3397@osiris> <20160202204156.GA27290@yury-N73SV>
Message-ID: <20160217082210.GA4175@osiris>

On Tue, Feb 02, 2016 at 11:41:56PM +0300, Yury Norov wrote:
> > However I'll try to write an addon patch to your patch series. Maybe we can
> > still get rid of compat_wrapper.c in a way which makes both of us happy.
> > Also.. the idea with the alias names for compat wrappers does seem to have
> > the disadvantage that it will pollute /proc/kallsyms for example.
> > 
> > Anyway, I'm not sure if I will be able to come up with something this week
> > though.
> 
> Great, I'm looking forward...

Hi Yuri,

after playing around with this a bit I couldn't come up with a solution
that I'm happy with, unfortunately.

So in order to make some progress here I'd vote that we simply move the
existing compat_wrapper.c from arch/s390 to common code like you did in
your first approach and leave the existing SYSCALL macros alone.

That will have hardly any effect to anybody else and your problem is
solved while s390 still works.

Does that make sense?



From thomas.petazzoni at free-electrons.com  Wed Feb 17 00:30:45 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 17 Feb 2016 09:30:45 +0100
Subject: [PATCH 5/5] arm64: marvell: add Device Tree files for Armada 7K/8K
In-Reply-To: <20160217102124.7353591f@xhacker>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455526065-7307-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160216134219.00045b5b@xhacker>
 <20160216173840.7f93896f@free-electrons.com>
 <20160217102124.7353591f@xhacker>
Message-ID: <20160217093045.457e6a54@free-electrons.com>

Hello,

On Wed, 17 Feb 2016 10:21:24 +0800, Jisheng Zhang wrote:

> > > I guess the GIC is neither the one in cortex-a15 or cortex-a9.   
> > 
> > What makes you think this?
> > 
> > The GIC is a GIC400, which is GICv2 compliant, and arm-cortex-a15-gic /
> 
> That's my point, why not "gic-400" explicitly?

Yes, we could use arm,gic-400 instead. Note that implementation-wise,
there is currently zero difference between arm,cortex-a9-gic,
arm,cortex-a15-gic and arm,gic-400. But indeed arm,gic-400 looks better.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From hverkuil at xs4all.nl  Wed Feb 17 00:31:31 2016
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Wed, 17 Feb 2016 09:31:31 +0100
Subject: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video
 Encoder Driver
In-Reply-To: <1455696068.26202.4.camel@mtksdaap41>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
 <56C1B4AF.1030207@xs4all.nl> <1455604653.19396.68.camel@mtksdaap41>
 <56C2D371.9090805@xs4all.nl> <1455628805.19396.82.camel@mtksdaap41>
 <56C328AF.5030604@cisco.com> <1455696068.26202.4.camel@mtksdaap41>
Message-ID: <56C42FE3.8000105@xs4all.nl>

On 02/17/16 09:01, tiffany lin wrote:
> On Tue, 2016-02-16 at 14:48 +0100, Hans Verkuil wrote:
>> Hi Tiffany,
>>
>>>>>>> +int mtk_vcodec_enc_queue_init(void *priv, struct vb2_queue *src_vq,
>>>>>>> +			   struct vb2_queue *dst_vq)
>>>>>>> +{
>>>>>>> +	struct mtk_vcodec_ctx *ctx = priv;
>>>>>>> +	int ret;
>>>>>>> +
>>>>>>> +	src_vq->type		= V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
>>>>>>> +	src_vq->io_modes	= VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
>>>>>>
>>>>>> I recomment dropping VB2_USERPTR. That only makes sense for scatter-gather dma,
>>>>>> and you use physically contiguous DMA.
>>>>>>
>>>>> Now our userspace app use VB2_USERPTR. I need to check if we could drop
>>>>> VB2_USERPTR.
>>>>> We use src_vq->mem_ops = &vb2_dma_contig_memops;
>>>>> And there are
>>>>> 	.get_userptr	= vb2_dc_get_userptr,
>>>>> 	.put_userptr	= vb2_dc_put_userptr,
>>>>> I was confused why it only make sense for scatter-gather.
>>>>> Could you kindly explain more?
>>>>
>>>> VB2_USERPTR indicates that the application can use malloc to allocate buffers
>>>> and pass those to the driver. Since malloc uses virtual memory the physical
>>>> memory is scattered all over. And the first page typically does not start at
>>>> the beginning of the page but at a random offset.
>>>>
>>>> To support that the DMA generally has to be able to do scatter-gather.
>>>>
>>>> Now, where things get ugly is that a hack was added to the USERPTR support where
>>>> apps could pass a pointer to physically contiguous memory as a user pointer. This
>>>> was a hack for embedded systems that preallocated a pool of buffers and needed to
>>>> pass those pointers around somehow. So the dma-contig USERPTR support is for that
>>>> 'feature'. If you try to pass a malloc()ed buffer to a dma-contig driver it will
>>>> reject it. One big problem is that this specific hack isn't signaled anywhere, so
>>>> applications have no way of knowing if the USERPTR support is the proper version
>>>> or the hack where physically contiguous memory is expected.
>>>>
>>>> This hack has been replaced with DMABUF which is the proper way of passing buffers
>>>> around.
>>>>
>>>> New dma-contig drivers should not use that old hack anymore. Use dmabuf to pass
>>>> external buffers around.
>>>>
>>>> How do you use it in your app? With malloc()ed buffers? Or with 'special' pointers
>>>> to physically contiguous buffers?
>>>>
>>> Understood now. Thanks for your explanation.
>>> Now our app use malloc()ed buffers and we hook vb2_dma_contig_memops. 
>>> I don't know why that dma-contig driver do not reject it.
>>> I will try to figure it out.
>>
>> Is there an iommu involved that turns the scatter-gather list into what looks like
>> contiguous memory for the DMA?
>>
> Yes, We have iommu that could make scatter-gather list looks like
> contiguous memory.
> 
>> At the end of vb2_dc_get_userptr() in videobuf2-dma-contig.c there is a check
>> 'if (contig_size < size)' that verifies that the sg DMA is contiguous. This would
>> work if there is an iommu involved (if I understand it correctly).
>>
> I see. We saw this error before we add iommu support.
> 
>> If that's the case, then it's OK to keep VB2_USERPTR because you have real sg
>> support (although not via the DMA engine, but via iommu mappings).
>>
> Got it. We will keep VB2_USERPTR.

Can you add a comment here mentioning that VB2_USERPTR works with dma-contig because
there is an iommu? That should clarify this.

Regards,

	Hans


From ard.biesheuvel at linaro.org  Wed Feb 17 00:32:51 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 17 Feb 2016 09:32:51 +0100
Subject: [PATCH v2 2/2] arm64/efi: esrt: add missing call to
 efi_esrt_init()
In-Reply-To: <56C385D3.3090308@codeaurora.org>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-3-git-send-email-ard.biesheuvel@linaro.org>
 <56C385D3.3090308@codeaurora.org>
Message-ID: <CAKv+Gu9YoUujk2mA7wLyiWZ9=v3XTMkDT6vzgOq5a=FtCcHZwQ@mail.gmail.com>

On 16 February 2016 at 21:25, Baicar, Tyler <tbaicar at codeaurora.org> wrote:
> On 2/15/2016 4:32 AM, Ard Biesheuvel wrote:
>>
>> ESRT support is built by default for all architectures that define
>> CONFIG_EFI. However, this support was not wired up yet for ARM/arm64,
>> since efi_esrt_init() was never called. So add the missing call.
>>
>> Since efi_esrt_init() uses efi_mem_desc_lookup(), which in turn relies
>> on efi.memmap having been assigned and populated completetely, add the
>> missing assignments of efi.memmap and efi.memmap->nr_map.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> ---
>>   drivers/firmware/efi/arm-init.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/firmware/efi/arm-init.c
>> b/drivers/firmware/efi/arm-init.c
>> index 9e15d571b53c..5c5e799bdb50 100644
>> --- a/drivers/firmware/efi/arm-init.c
>> +++ b/drivers/firmware/efi/arm-init.c
>> @@ -197,10 +197,13 @@ void __init efi_init(void)
>>         memmap.map_end = memmap.map + params.mmap_size;
>>         memmap.desc_size = params.desc_size;
>>         memmap.desc_version = params.desc_ver;
>> +       memmap.nr_map = params.mmap_size / params.desc_size;
>> +       efi.memmap = &memmap;
>>         if (uefi_init() < 0)
>>                 return;
>>   +     efi_esrt_init();
>
> This call to efi_esrt_init() is failing because efi.flags does not have
> EFI_MEMMAP set. This flag gets set at the end of reserve_regions(). I tested
> moving the set_bit() call from reserve_regions() to just before
> efi_esrt_init() and also tested moving efi_esrt_init() to just after
> reserve_regions(). Both of these options worked.

Thanks for spotting that. I moved the call around for some reason (I
don't remember why, exactly), but it indeed belongs after the call to
reserve_regions()

I will send out a v2

>>
>>         reserve_regions();
>>         early_memunmap(memmap.map, params.mmap_size);
>>         memblock_mark_nomap(params.mmap & PAGE_MASK,
>
> Thanks,
> Tyler
>
> --
> Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>


From tiffany.lin at mediatek.com  Wed Feb 17 00:33:12 2016
From: tiffany.lin at mediatek.com (tiffany lin)
Date: Wed, 17 Feb 2016 16:33:12 +0800
Subject: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2
 Video Encoder Driver
In-Reply-To: <56C425A0.6080005@xs4all.nl>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
 <56C1B4AF.1030207@xs4all.nl> <1455604653.19396.68.camel@mtksdaap41>
 <56C425A0.6080005@xs4all.nl>
Message-ID: <1455697992.26202.13.camel@mtksdaap41>

Hi Hans,

On Wed, 2016-02-17 at 08:47 +0100, Hans Verkuil wrote:
> On 02/16/2016 07:37 AM, tiffany lin wrote:
> >>> +static int fops_vcodec_open(struct file *file)
> >>> +{
> >>> +	struct video_device *vfd = video_devdata(file);
> >>> +	struct mtk_vcodec_dev *dev = video_drvdata(file);
> >>> +	struct mtk_vcodec_ctx *ctx = NULL;
> >>> +	int ret = 0;
> >>> +
> >>> +	mutex_lock(&dev->dev_mutex);
> >>> +
> >>> +	ctx = devm_kzalloc(&dev->plat_dev->dev, sizeof(*ctx), GFP_KERNEL);
> >>> +	if (!ctx) {
> >>> +		ret = -ENOMEM;
> >>> +		goto err_alloc;
> >>> +	}
> >>> +
> >>> +	if (dev->num_instances >= MTK_VCODEC_MAX_ENCODER_INSTANCES) {
> >>> +		mtk_v4l2_err("Too many open contexts\n");
> >>> +		ret = -EBUSY;
> >>> +		goto err_no_ctx;
> >>
> >> Hmm. I never like it if you can't open a video node because of a reason like this.
> >>
> >> I.e. a simple 'v4l2-ctl -D' (i.e. calling QUERYCAP) should never fail.
> >>
> >> If there are hardware limitation that prevent more than X instances from running at
> >> the same time, then those limitations typically kick in when you start to stream
> >> (or possibly when calling REQBUFS). But before that it should always be possible to
> >> open the device.
> >>
> >> Having this check at open() is an indication of a poor design.
> >>
> >> Is this is a hardware limitation at all?
> >>
> > This is to make sure performance meet requirements, such as bitrate and
> > framerate.
> 
> Is it the driver's job to make enforce this? What if the application only
> deals with low-res video, but wants to encode a lot of those? Or is encoding
> a video off-line?
> 
> The driver generally doesn't know the use-case, so if this is an artificial
> limitation as opposed to a hardware limitation, then I would just drop this.
> 
We got your point, we will remove this artificial limitation in next
version.

best regards,
Tiffany


> Regards,
> 
> 	Hans
> 
> > We got your point. We will remove this and move limitation control to
> > start_streaming or REQBUFS.
> > Appreciated for your suggestion.:)
> > 
> > 
> >>> +	}
> 




From arnd at arndb.de  Wed Feb 17 00:32:58 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 09:32:58 +0100
Subject: [PATCH] staging: rtl8712: reduce stack usage
Message-ID: <1455698012-814399-1-git-send-email-arnd@arndb.de>

The "translate_scan" function in rtl8712 uses a lot of stack, and
gets inlined into its single caller, r8711_wx_get_scan, which
in some configurations now blows the 1024 byte stack warning
limit:

drivers/staging/rtl8712/rtl871x_ioctl_linux.c: In function 'r8711_wx_get_scan':
drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1227:1: error: the frame size of 1032 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

This somewhat reduces the stack usage by moving the translate_scan
function out of line with the noinline_for_stack annotation.
It might be possible to modify translate_scan() a little further
to reduce the stack usage, but with this patch, we can build without
the warning, the the call chain to get here is rather predictable
(sys_ioctl->vfs_ioctl->sock_ioctl->dev_ioctl->wext_ioctl->
r8711_wx_get_scan).

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index db2e31bcdd77..a15f3ce70223 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -137,7 +137,7 @@ static inline void handle_group_key(struct ieee_param *param,
 	}
 }
 
-static inline char *translate_scan(struct _adapter *padapter,
+static noinline_for_stack char *translate_scan(struct _adapter *padapter,
 				   struct iw_request_info *info,
 				   struct wlan_network *pnetwork,
 				   char *start, char *stop)
-- 
2.7.0



From khalasa at piap.pl  Wed Feb 17 00:36:37 2016
From: khalasa at piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=)
Date: Wed, 17 Feb 2016 09:36:37 +0100
Subject: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
In-Reply-To: <3062977.Ya2ztQYFaM@wuerfel> (Arnd Bergmann's message of "Tue, 16
 Feb 2016 14:55:43 +0100")
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <2702068.KRp0Bplb5Q@wuerfel> <m34md8rdol.fsf@t19.piap.pl>
 <3062977.Ya2ztQYFaM@wuerfel>
Message-ID: <m3ziuzpwbu.fsf@t19.piap.pl>

Arnd Bergmann <arnd at arndb.de> writes:

> ixp4xx is really special in that it performs hardware swapping for
> internal devices based on CPU endianess but not on PCI devices.

Again, IXP4xx does not perform hardware (nor any other) swapping for
registers of on-chip devices. The registers are connected 1:1,
bit 0 to bit 0 etc.

(Yes, IXP4xx can be optionally programmed for such swapping, depending
on silicon revision, but it is not used in mainline kernel).

The only hardware swapping happens on PCI bus (in BE mode), to be
compatible with other platforms and non-IXP4xx-specific PCI drivers.

> Coming back to the specific pxa25x_udc case: using __raw_* accessors
> in the driver would possibly end up breaking the PXA25x machines in
> the (very unlikely) case that someone wants to make it work with
> big-endian kernels, assuming it does not have the same hardware
> byteswap logic as ixp4xx.

I'd expect both CPUs to behave in exactly the same manner, i.e., to
not swap anything on the internal bus. If true, it would mean it should
"just work" in both BE and LE modes (including BE mode on PXA, should
it be actually possible).
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland


From yong.wu at mediatek.com  Tue Feb 16 16:46:09 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Wed, 17 Feb 2016 08:46:09 +0800
Subject: [PATCH v9 0/5] MT8173 IOMMU SUPPORT
Message-ID: <1455669974-1527-1-git-send-email-yong.wu@mediatek.com>

  This patch set adds support for m4u(Multimedia Memory Management Unit),
Currently it only support the m4u with 2 levels of pagetable on mt8173.

  It's based on Robin Murphy's Short-descriptor v3[1].
 
  Please check the hardware block diagram of Mediatek IOMMU.
 
              m4u (Multimedia Memory Management Unit)
               |
           SMI Common(Smart Multimedia Interface Common)
               |
       +----------------+-------
       |                |
       |                |
   SMI larb0        SMI larb1   ... SoCs have several SMI local arbiter(larb).
   (display)         (vdec)
       |                |
       |                |
 +-----+-----+     +----+----+
 |     |     |     |    |    |
 |     |     |...  |    |    |  ... There are different ports in each larb.
 |     |     |     |    |    |
OVL0 RDMA0 WDMA0  MC   PP   VLD

  As above, The Multimedia HW will go through SMI and M4U while it
access EMI. SMI is a bridge between m4u and the Multimedia HW. It contain
smi local arbiter and smi common. It will control whether the Multimedia
HW should go though the m4u for translation or bypass it and talk
directly with EMI. And also SMI help control the power domain and clocks for
each local arbiter.
  Normally we specify a local arbiter(larb) for each multimedia HW
like display, video decode, and camera. And there are different ports
in each larb. Take a example, There are many ports like MC, PP, VLD in the
video decode local arbiter, all these ports are according to the video HW.

[1] : http://thread.gmane.org/gmane.linux.kernel.iommu/12007

v9:
 - rebase onto Robin's Short-descriptor v3.
 - add the Acks and other tags for all the patches(No change the code).

v8: http://thread.gmane.org/gmane.linux.kernel.iommu/11974
 - rebase onto v4.5-rc1.
 - add depends on (ARM || ARM64) for MTK_IOMMU in Kconfig to avoid build fail
   in other ARCHs.
 - delete COHERENCE_EN bit.
 - delete a *if* while config iommu information since the iommu is always
   enabled currently.

v7: http://lists.linuxfoundation.org/pipermail/iommu/2015-December/015214.html
- rebase onto Robin's short v2:
  http://lists.linuxfoundation.org/pipermail/iommu/2015-December/015210.html
- Adjust the iommu probe sequence to meet the expectant flow that the iommu
  core help create the domain.
- use component additional data instead of the interface mtk_smi_config_port.
- reconstruct the SMI help function.

v6: http://lists.linuxfoundation.org/pipermail/iommu/2015-December/015105.html
-rebase onto v4.4-rc1.
-Use Robin's reposting Short-decriptor.
 http://lists.linuxfoundation.org/pipermail/iommu/2015-December/015088.html
-Add component for m4u and smi since m4u should depend on smi-larb.
 The master device is the m4u device, and the client one is the smi-larb device. 
-Change mtk iommu-cells from 2 to 1 since the mapping between larb and port is
 fixed. Compare this with v2, we redefine MTK_M4U_ID following this register
 REG_MMU_INT_ID.
-About SMI: Add some help funcion and rename some function and struction for
 more readable. 
 These three above are according to Daniel Kurtz's suggestion.

v5: http://lists.linuxfoundation.org/pipermail/iommu/2015-October/014586.html
-rebase onto v4.3-rc1.
-About MTK iommu: don't return the same domain while domain_alloc, change the
 domain's flow according to the M4U HW.
-About Short-descriptor: Improve many error-handles, NO_PERMS quirk, and 
 add TLBI_MAP quirk following Will's Suggestion; Add io-pgtable don't use 
 dma_to_phys; Add a loop in arm_short_unmap since iommu_unmap don't care the 
 physical address align.
-About SMI driver: Add a help funcion for some similar code. Add PROPRE_DEFER
 for power-domain as MTK SCPSYS is module_init currently.

v4: http://lists.linuxfoundation.org/pipermail/iommu/2015-August/013903.html
-use only one iommu domain here based on the Robin's DMA-v5:
 http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013900.html
-remove flush_pgtable.
-change writel to writel_relaxed.
-about Short-descriptor: move dma_map_single into io-pgtable-arm-short.
 Improve the flow of free pgtable and add NO_XN+NO_PERMS quirk following
 Will's suggestion.
-Change two sytle issues in dtsi according to Daniel's suggestion.

v3: http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013632.html
-rebased onto v4.2-rc1
-improve iommu flow based on the Robin's DMA v3:
 http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013597.html
-change mtk iommu-cells from 1 to 2.
-about Short-descriptor: add split function; add self-test; add some other bits like nG,
 XN according to the spec; add SUPERSECTION and MTK quirk; move io_pgtable_ops_to_pgtable
 out from LPAE to the header file.
-about SMI: move from driver/soc/mediatek to driver/memory; change the clocks from
 clk[2] to clk_apb and clk_smi; add pm.
-add iommu suspend/resume to backup/restore register.

v2: http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013028.html
-add arm short descriptor support.
-seperate smi common from smi and change the clock-names according
 to smi HW.
-delete the hardcode of the port-names in mt8173.
 replace this with larb-portes-nr in dtsi.
-fix some coding style issues.

v1: http://lists.infradead.org/pipermail/linux-mediatek/2015-March/000058.html
-initial version.

Yong Wu (5):
  dt-bindings: iommu: Add binding for mediatek IOMMU
  dt-bindings: mediatek: Add smi dts binding
  memory: mediatek: Add SMI driver
  iommu/mediatek: Add mt8173 IOMMU driver
  dts: mt8173: Add iommu/smi nodes for mt8173

 .../devicetree/bindings/iommu/mediatek,iommu.txt   |  68 ++
 .../memory-controllers/mediatek,smi-common.txt     |  24 +
 .../memory-controllers/mediatek,smi-larb.txt       |  25 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi           |  81 +++
 drivers/iommu/Kconfig                              |  16 +
 drivers/iommu/Makefile                             |   1 +
 drivers/iommu/mtk_iommu.c                          | 732 +++++++++++++++++++++
 drivers/memory/Kconfig                             |   8 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mtk-smi.c                           | 272 ++++++++
 include/dt-bindings/memory/mt8173-larb-port.h      | 111 ++++
 include/soc/mediatek/smi.h                         |  58 ++
 12 files changed, 1397 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
 create mode 100644 drivers/iommu/mtk_iommu.c
 create mode 100644 drivers/memory/mtk-smi.c
 create mode 100644 include/dt-bindings/memory/mt8173-larb-port.h
 create mode 100644 include/soc/mediatek/smi.h

-- 
1.8.1.1.dirty 



From yong.wu at mediatek.com  Tue Feb 16 16:46:10 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Wed, 17 Feb 2016 08:46:10 +0800
Subject: [PATCH v9 1/5] dt-bindings: iommu: Add binding for mediatek IOMMU
In-Reply-To: <1455669974-1527-1-git-send-email-yong.wu@mediatek.com>
References: <1455669974-1527-1-git-send-email-yong.wu@mediatek.com>
Message-ID: <1455669974-1527-2-git-send-email-yong.wu@mediatek.com>

This patch add mediatek iommu dts binding document.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/iommu/mediatek,iommu.txt   | 68 ++++++++++++++++++++++
 1 file changed, 68 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt

diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
new file mode 100644
index 0000000..cd1b1cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
@@ -0,0 +1,68 @@
+* Mediatek IOMMU Architecture Implementation
+
+  Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U) which
+uses the ARM Short-Descriptor translation table format for address translation.
+
+  About the M4U Hardware Block Diagram, please check below:
+
+              EMI (External Memory Interface)
+               |
+              m4u (Multimedia Memory Management Unit)
+               |
+           SMI Common(Smart Multimedia Interface Common)
+               |
+       +----------------+-------
+       |                |
+       |                |
+   SMI larb0        SMI larb1   ... SoCs have several SMI local arbiter(larb).
+   (display)         (vdec)
+       |                |
+       |                |
+ +-----+-----+     +----+----+
+ |     |     |     |    |    |
+ |     |     |...  |    |    |  ... There are different ports in each larb.
+ |     |     |     |    |    |
+OVL0 RDMA0 WDMA0  MC   PP   VLD
+
+  As above, The Multimedia HW will go through SMI and M4U while it
+access EMI. SMI is a bridge between m4u and the Multimedia HW. It contain
+smi local arbiter and smi common. It will control whether the Multimedia
+HW should go though the m4u for translation or bypass it and talk
+directly with EMI. And also SMI help control the power domain and clocks for
+each local arbiter.
+  Normally we specify a local arbiter(larb) for each multimedia HW
+like display, video decode, and camera. And there are different ports
+in each larb. Take a example, There are many ports like MC, PP, VLD in the
+video decode local arbiter, all these ports are according to the video HW.
+
+Required properties:
+- compatible : must be "mediatek,mt8173-m4u".
+- reg : m4u register base and size.
+- interrupts : the interrupt of m4u.
+- clocks : must contain one entry for each clock-names.
+- clock-names : must be "bclk", It is the block clock of m4u.
+- mediatek,larbs : List of phandle to the local arbiters in the current Socs.
+	Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
+	according to the local arbiter index, like larb0, larb1, larb2...
+- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
+	Specifies the mtk_m4u_id as defined in
+	dt-binding/memory/mt8173-larb-port.h.
+
+Example:
+	iommu: iommu at 10205000 {
+		compatible = "mediatek,mt8173-m4u";
+		reg = <0 0x10205000 0 0x1000>;
+		interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>;
+		clocks = <&infracfg CLK_INFRA_M4U>;
+		clock-names = "bclk";
+		mediatek,larbs = <&larb0 &larb1 &larb2 &larb3 &larb4 &larb5>;
+		#iommu-cells = <1>;
+	};
+
+Example for a client device:
+	display {
+		compatible = "mediatek,mt8173-disp";
+		iommus = <&iommu M4U_PORT_DISP_OVL0>,
+			 <&iommu M4U_PORT_DISP_RDMA0>;
+		...
+	};
-- 
1.8.1.1.dirty



From yong.wu at mediatek.com  Tue Feb 16 16:46:11 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Wed, 17 Feb 2016 08:46:11 +0800
Subject: [PATCH v9 2/5] dt-bindings: mediatek: Add smi dts binding
In-Reply-To: <1455669974-1527-1-git-send-email-yong.wu@mediatek.com>
References: <1455669974-1527-1-git-send-email-yong.wu@mediatek.com>
Message-ID: <1455669974-1527-3-git-send-email-yong.wu@mediatek.com>

This patch add smi binding document and smi local arbiter header file.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../memory-controllers/mediatek,smi-common.txt     |  24 +++++
 .../memory-controllers/mediatek,smi-larb.txt       |  25 +++++
 include/dt-bindings/memory/mt8173-larb-port.h      | 111 +++++++++++++++++++++
 3 files changed, 160 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
 create mode 100644 include/dt-bindings/memory/mt8173-larb-port.h

diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
new file mode 100644
index 0000000..06a83ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
@@ -0,0 +1,24 @@
+SMI (Smart Multimedia Interface) Common
+
+The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
+
+Required properties:
+- compatible : must be "mediatek,mt8173-smi-common"
+- reg : the register and size of the SMI block.
+- power-domains : a phandle to the power domain of this local arbiter.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : must contain 2 entries, as follows:
+  - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
+	    the register.
+  - "smi" : It's the clock for transfer data and command.
+  They may be the same if both source clocks are the same.
+
+Example:
+	smi_common: smi at 14022000 {
+		compatible = "mediatek,mt8173-smi-common";
+		reg = <0 0x14022000 0 0x1000>;
+		power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+		clocks = <&mmsys CLK_MM_SMI_COMMON>,
+			 <&mmsys CLK_MM_SMI_COMMON>;
+		clock-names = "apb", "smi";
+	};
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
new file mode 100644
index 0000000..55ff3b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
@@ -0,0 +1,25 @@
+SMI (Smart Multimedia Interface) Local Arbiter
+
+The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
+
+Required properties:
+- compatible : must be "mediatek,mt8173-smi-larb"
+- reg : the register and size of this local arbiter.
+- mediatek,smi : a phandle to the smi_common node.
+- power-domains : a phandle to the power domain of this local arbiter.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names: must contain 2 entries, as follows:
+  - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
+	    the register.
+  - "smi" : It's the clock for transfer data and command.
+
+Example:
+	larb1: larb at 16010000 {
+		compatible = "mediatek,mt8173-smi-larb";
+		reg = <0 0x16010000 0 0x1000>;
+		mediatek,smi = <&smi_common>;
+		power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
+		clocks = <&vdecsys CLK_VDEC_CKEN>,
+			 <&vdecsys CLK_VDEC_LARB_CKEN>;
+		clock-names = "apb", "smi";
+	};
diff --git a/include/dt-bindings/memory/mt8173-larb-port.h b/include/dt-bindings/memory/mt8173-larb-port.h
new file mode 100644
index 0000000..5fef5d1
--- /dev/null
+++ b/include/dt-bindings/memory/mt8173-larb-port.h
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2015-2016 MediaTek Inc.
+ * Author: Yong Wu <yong.wu at mediatek.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.
+ */
+#ifndef __DTS_IOMMU_PORT_MT8173_H
+#define __DTS_IOMMU_PORT_MT8173_H
+
+#define MTK_M4U_ID(larb, port)		(((larb) << 5) | (port))
+/* Local arbiter ID */
+#define MTK_M4U_TO_LARB(id)		(((id) >> 5) & 0x7)
+/* PortID within the local arbiter */
+#define MTK_M4U_TO_PORT(id)		((id) & 0x1f)
+
+#define M4U_LARB0_ID			0
+#define M4U_LARB1_ID			1
+#define M4U_LARB2_ID			2
+#define M4U_LARB3_ID			3
+#define M4U_LARB4_ID			4
+#define M4U_LARB5_ID			5
+
+/* larb0 */
+#define M4U_PORT_DISP_OVL0		MTK_M4U_ID(M4U_LARB0_ID, 0)
+#define M4U_PORT_DISP_RDMA0		MTK_M4U_ID(M4U_LARB0_ID, 1)
+#define M4U_PORT_DISP_WDMA0		MTK_M4U_ID(M4U_LARB0_ID, 2)
+#define M4U_PORT_DISP_OD_R		MTK_M4U_ID(M4U_LARB0_ID, 3)
+#define M4U_PORT_DISP_OD_W		MTK_M4U_ID(M4U_LARB0_ID, 4)
+#define M4U_PORT_MDP_RDMA0		MTK_M4U_ID(M4U_LARB0_ID, 5)
+#define M4U_PORT_MDP_WDMA		MTK_M4U_ID(M4U_LARB0_ID, 6)
+#define M4U_PORT_MDP_WROT0		MTK_M4U_ID(M4U_LARB0_ID, 7)
+
+/* larb1 */
+#define M4U_PORT_HW_VDEC_MC_EXT		MTK_M4U_ID(M4U_LARB1_ID, 0)
+#define M4U_PORT_HW_VDEC_PP_EXT		MTK_M4U_ID(M4U_LARB1_ID, 1)
+#define M4U_PORT_HW_VDEC_UFO_EXT	MTK_M4U_ID(M4U_LARB1_ID, 2)
+#define M4U_PORT_HW_VDEC_VLD_EXT	MTK_M4U_ID(M4U_LARB1_ID, 3)
+#define M4U_PORT_HW_VDEC_VLD2_EXT	MTK_M4U_ID(M4U_LARB1_ID, 4)
+#define M4U_PORT_HW_VDEC_AVC_MV_EXT	MTK_M4U_ID(M4U_LARB1_ID, 5)
+#define M4U_PORT_HW_VDEC_PRED_RD_EXT	MTK_M4U_ID(M4U_LARB1_ID, 6)
+#define M4U_PORT_HW_VDEC_PRED_WR_EXT	MTK_M4U_ID(M4U_LARB1_ID, 7)
+#define M4U_PORT_HW_VDEC_PPWRAP_EXT	MTK_M4U_ID(M4U_LARB1_ID, 8)
+#define M4U_PORT_HW_VDEC_TILE		MTK_M4U_ID(M4U_LARB1_ID, 9)
+
+/* larb2 */
+#define M4U_PORT_IMGO			MTK_M4U_ID(M4U_LARB2_ID, 0)
+#define M4U_PORT_RRZO			MTK_M4U_ID(M4U_LARB2_ID, 1)
+#define M4U_PORT_AAO			MTK_M4U_ID(M4U_LARB2_ID, 2)
+#define M4U_PORT_LCSO			MTK_M4U_ID(M4U_LARB2_ID, 3)
+#define M4U_PORT_ESFKO			MTK_M4U_ID(M4U_LARB2_ID, 4)
+#define M4U_PORT_IMGO_D			MTK_M4U_ID(M4U_LARB2_ID, 5)
+#define M4U_PORT_LSCI			MTK_M4U_ID(M4U_LARB2_ID, 6)
+#define M4U_PORT_LSCI_D			MTK_M4U_ID(M4U_LARB2_ID, 7)
+#define M4U_PORT_BPCI			MTK_M4U_ID(M4U_LARB2_ID, 8)
+#define M4U_PORT_BPCI_D			MTK_M4U_ID(M4U_LARB2_ID, 9)
+#define M4U_PORT_UFDI			MTK_M4U_ID(M4U_LARB2_ID, 10)
+#define M4U_PORT_IMGI			MTK_M4U_ID(M4U_LARB2_ID, 11)
+#define M4U_PORT_IMG2O			MTK_M4U_ID(M4U_LARB2_ID, 12)
+#define M4U_PORT_IMG3O			MTK_M4U_ID(M4U_LARB2_ID, 13)
+#define M4U_PORT_VIPI			MTK_M4U_ID(M4U_LARB2_ID, 14)
+#define M4U_PORT_VIP2I			MTK_M4U_ID(M4U_LARB2_ID, 15)
+#define M4U_PORT_VIP3I			MTK_M4U_ID(M4U_LARB2_ID, 16)
+#define M4U_PORT_LCEI			MTK_M4U_ID(M4U_LARB2_ID, 17)
+#define M4U_PORT_RB			MTK_M4U_ID(M4U_LARB2_ID, 18)
+#define M4U_PORT_RP			MTK_M4U_ID(M4U_LARB2_ID, 19)
+#define M4U_PORT_WR			MTK_M4U_ID(M4U_LARB2_ID, 20)
+
+/* larb3 */
+#define M4U_PORT_VENC_RCPU		MTK_M4U_ID(M4U_LARB3_ID, 0)
+#define M4U_PORT_VENC_REC		MTK_M4U_ID(M4U_LARB3_ID, 1)
+#define M4U_PORT_VENC_BSDMA		MTK_M4U_ID(M4U_LARB3_ID, 2)
+#define M4U_PORT_VENC_SV_COMV		MTK_M4U_ID(M4U_LARB3_ID, 3)
+#define M4U_PORT_VENC_RD_COMV		MTK_M4U_ID(M4U_LARB3_ID, 4)
+#define M4U_PORT_JPGENC_RDMA		MTK_M4U_ID(M4U_LARB3_ID, 5)
+#define M4U_PORT_JPGENC_BSDMA		MTK_M4U_ID(M4U_LARB3_ID, 6)
+#define M4U_PORT_JPGDEC_WDMA		MTK_M4U_ID(M4U_LARB3_ID, 7)
+#define M4U_PORT_JPGDEC_BSDMA		MTK_M4U_ID(M4U_LARB3_ID, 8)
+#define M4U_PORT_VENC_CUR_LUMA		MTK_M4U_ID(M4U_LARB3_ID, 9)
+#define M4U_PORT_VENC_CUR_CHROMA	MTK_M4U_ID(M4U_LARB3_ID, 10)
+#define M4U_PORT_VENC_REF_LUMA		MTK_M4U_ID(M4U_LARB3_ID, 11)
+#define M4U_PORT_VENC_REF_CHROMA	MTK_M4U_ID(M4U_LARB3_ID, 12)
+#define M4U_PORT_VENC_NBM_RDMA		MTK_M4U_ID(M4U_LARB3_ID, 13)
+#define M4U_PORT_VENC_NBM_WDMA		MTK_M4U_ID(M4U_LARB3_ID, 14)
+
+/* larb4 */
+#define M4U_PORT_DISP_OVL1		MTK_M4U_ID(M4U_LARB4_ID, 0)
+#define M4U_PORT_DISP_RDMA1		MTK_M4U_ID(M4U_LARB4_ID, 1)
+#define M4U_PORT_DISP_RDMA2		MTK_M4U_ID(M4U_LARB4_ID, 2)
+#define M4U_PORT_DISP_WDMA1		MTK_M4U_ID(M4U_LARB4_ID, 3)
+#define M4U_PORT_MDP_RDMA1		MTK_M4U_ID(M4U_LARB4_ID, 4)
+#define M4U_PORT_MDP_WROT1		MTK_M4U_ID(M4U_LARB4_ID, 5)
+
+/* larb5 */
+#define M4U_PORT_VENC_RCPU_SET2		MTK_M4U_ID(M4U_LARB5_ID, 0)
+#define M4U_PORT_VENC_REC_FRM_SET2	MTK_M4U_ID(M4U_LARB5_ID, 1)
+#define M4U_PORT_VENC_REF_LUMA_SET2	MTK_M4U_ID(M4U_LARB5_ID, 2)
+#define M4U_PORT_VENC_REC_CHROMA_SET2	MTK_M4U_ID(M4U_LARB5_ID, 3)
+#define M4U_PORT_VENC_BSDMA_SET2	MTK_M4U_ID(M4U_LARB5_ID, 4)
+#define M4U_PORT_VENC_CUR_LUMA_SET2	MTK_M4U_ID(M4U_LARB5_ID, 5)
+#define M4U_PORT_VENC_CUR_CHROMA_SET2	MTK_M4U_ID(M4U_LARB5_ID, 6)
+#define M4U_PORT_VENC_RD_COMA_SET2	MTK_M4U_ID(M4U_LARB5_ID, 7)
+#define M4U_PORT_VENC_SV_COMA_SET2	MTK_M4U_ID(M4U_LARB5_ID, 8)
+
+#endif
-- 
1.8.1.1.dirty



From yong.wu at mediatek.com  Tue Feb 16 16:46:12 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Wed, 17 Feb 2016 08:46:12 +0800
Subject: [PATCH v9 3/5] memory: mediatek: Add SMI driver
In-Reply-To: <1455669974-1527-1-git-send-email-yong.wu@mediatek.com>
References: <1455669974-1527-1-git-send-email-yong.wu@mediatek.com>
Message-ID: <1455669974-1527-4-git-send-email-yong.wu@mediatek.com>

This patch add SMI(Smart Multimedia Interface) driver. This driver
is responsible to enable/disable iommu and control the power domain
and clocks of each local arbiter.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Tested-by: Philipp Zabel <p.zabel at pengutronix.de>
Reviewed-by: Daniel Kurtz <djkurtz at chromium.org>
Tested-by: Daniel Kurtz <djkurtz at chromium.org>
Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
---
 drivers/memory/Kconfig     |   8 ++
 drivers/memory/Makefile    |   1 +
 drivers/memory/mtk-smi.c   | 272 +++++++++++++++++++++++++++++++++++++++++++++
 include/soc/mediatek/smi.h |  58 ++++++++++
 4 files changed, 339 insertions(+)
 create mode 100644 drivers/memory/mtk-smi.c
 create mode 100644 include/soc/mediatek/smi.h

diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 6f31546..51d5cd2 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -114,6 +114,14 @@ config JZ4780_NEMC
 	  the Ingenic JZ4780. This controller is used to handle external
 	  memory devices such as NAND and SRAM.
 
+config MTK_SMI
+	bool
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	help
+	  This driver is for the Memory Controller module in MediaTek SoCs,
+	  mainly help enable/disable iommu and control the power domain and
+	  clocks for each local arbiter.
+
 source "drivers/memory/tegra/Kconfig"
 
 endif
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 1c46af5..890bdf4 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -15,5 +15,6 @@ obj-$(CONFIG_FSL_IFC)		+= fsl_ifc.o
 obj-$(CONFIG_MVEBU_DEVBUS)	+= mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)	+= tegra20-mc.o
 obj-$(CONFIG_JZ4780_NEMC)	+= jz4780-nemc.o
+obj-$(CONFIG_MTK_SMI)		+= mtk-smi.o
 
 obj-$(CONFIG_TEGRA_MC)		+= tegra/
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
new file mode 100644
index 0000000..702f0d2
--- /dev/null
+++ b/drivers/memory/mtk-smi.c
@@ -0,0 +1,272 @@
+/*
+ * Copyright (c) 2015-2016 MediaTek Inc.
+ * Author: Yong Wu <yong.wu at mediatek.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.
+ */
+#include <linux/clk.h>
+#include <linux/component.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <soc/mediatek/smi.h>
+
+#define SMI_LARB_MMU_EN		0xf00
+
+struct mtk_smi {
+	struct device	*dev;
+	struct clk	*clk_apb, *clk_smi;
+};
+
+struct mtk_smi_larb { /* larb: local arbiter */
+	struct mtk_smi  smi;
+	void __iomem	*base;
+	struct device	*smi_common_dev;
+	u32		*mmu;
+};
+
+static int mtk_smi_enable(const struct mtk_smi *smi)
+{
+	int ret;
+
+	ret = pm_runtime_get_sync(smi->dev);
+	if (ret < 0)
+		return ret;
+
+	ret = clk_prepare_enable(smi->clk_apb);
+	if (ret)
+		goto err_put_pm;
+
+	ret = clk_prepare_enable(smi->clk_smi);
+	if (ret)
+		goto err_disable_apb;
+
+	return 0;
+
+err_disable_apb:
+	clk_disable_unprepare(smi->clk_apb);
+err_put_pm:
+	pm_runtime_put_sync(smi->dev);
+	return ret;
+}
+
+static void mtk_smi_disable(const struct mtk_smi *smi)
+{
+	clk_disable_unprepare(smi->clk_smi);
+	clk_disable_unprepare(smi->clk_apb);
+	pm_runtime_put_sync(smi->dev);
+}
+
+int mtk_smi_larb_get(struct device *larbdev)
+{
+	struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
+	struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
+	int ret;
+
+	/* Enable the smi-common's power and clocks */
+	ret = mtk_smi_enable(common);
+	if (ret)
+		return ret;
+
+	/* Enable the larb's power and clocks */
+	ret = mtk_smi_enable(&larb->smi);
+	if (ret) {
+		mtk_smi_disable(common);
+		return ret;
+	}
+
+	/* Configure the iommu info for this larb */
+	writel(*larb->mmu, larb->base + SMI_LARB_MMU_EN);
+
+	return 0;
+}
+
+void mtk_smi_larb_put(struct device *larbdev)
+{
+	struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
+	struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
+
+	/*
+	 * Don't de-configure the iommu info for this larb since there may be
+	 * several modules in this larb.
+	 * The iommu info will be reset after power off.
+	 */
+
+	mtk_smi_disable(&larb->smi);
+	mtk_smi_disable(common);
+}
+
+static int
+mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)
+{
+	struct mtk_smi_larb *larb = dev_get_drvdata(dev);
+	struct mtk_smi_iommu *smi_iommu = data;
+	unsigned int         i;
+
+	for (i = 0; i < smi_iommu->larb_nr; i++) {
+		if (dev == smi_iommu->larb_imu[i].dev) {
+			/* The 'mmu' may be updated in iommu-attach/detach. */
+			larb->mmu = &smi_iommu->larb_imu[i].mmu;
+			return 0;
+		}
+	}
+	return -ENODEV;
+}
+
+static void
+mtk_smi_larb_unbind(struct device *dev, struct device *master, void *data)
+{
+	/* Do nothing as the iommu is always enabled. */
+}
+
+static const struct component_ops mtk_smi_larb_component_ops = {
+	.bind = mtk_smi_larb_bind,
+	.unbind = mtk_smi_larb_unbind,
+};
+
+static int mtk_smi_larb_probe(struct platform_device *pdev)
+{
+	struct mtk_smi_larb *larb;
+	struct resource *res;
+	struct device *dev = &pdev->dev;
+	struct device_node *smi_node;
+	struct platform_device *smi_pdev;
+
+	if (!dev->pm_domain)
+		return -EPROBE_DEFER;
+
+	larb = devm_kzalloc(dev, sizeof(*larb), GFP_KERNEL);
+	if (!larb)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	larb->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(larb->base))
+		return PTR_ERR(larb->base);
+
+	larb->smi.clk_apb = devm_clk_get(dev, "apb");
+	if (IS_ERR(larb->smi.clk_apb))
+		return PTR_ERR(larb->smi.clk_apb);
+
+	larb->smi.clk_smi = devm_clk_get(dev, "smi");
+	if (IS_ERR(larb->smi.clk_smi))
+		return PTR_ERR(larb->smi.clk_smi);
+	larb->smi.dev = dev;
+
+	smi_node = of_parse_phandle(dev->of_node, "mediatek,smi", 0);
+	if (!smi_node)
+		return -EINVAL;
+
+	smi_pdev = of_find_device_by_node(smi_node);
+	of_node_put(smi_node);
+	if (smi_pdev) {
+		larb->smi_common_dev = &smi_pdev->dev;
+	} else {
+		dev_err(dev, "Failed to get the smi_common device\n");
+		return -EINVAL;
+	}
+
+	pm_runtime_enable(dev);
+	platform_set_drvdata(pdev, larb);
+	return component_add(dev, &mtk_smi_larb_component_ops);
+}
+
+static int mtk_smi_larb_remove(struct platform_device *pdev)
+{
+	pm_runtime_disable(&pdev->dev);
+	component_del(&pdev->dev, &mtk_smi_larb_component_ops);
+	return 0;
+}
+
+static const struct of_device_id mtk_smi_larb_of_ids[] = {
+	{ .compatible = "mediatek,mt8173-smi-larb",},
+	{}
+};
+
+static struct platform_driver mtk_smi_larb_driver = {
+	.probe	= mtk_smi_larb_probe,
+	.remove = mtk_smi_larb_remove,
+	.driver	= {
+		.name = "mtk-smi-larb",
+		.of_match_table = mtk_smi_larb_of_ids,
+	}
+};
+
+static int mtk_smi_common_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mtk_smi *common;
+
+	if (!dev->pm_domain)
+		return -EPROBE_DEFER;
+
+	common = devm_kzalloc(dev, sizeof(*common), GFP_KERNEL);
+	if (!common)
+		return -ENOMEM;
+	common->dev = dev;
+
+	common->clk_apb = devm_clk_get(dev, "apb");
+	if (IS_ERR(common->clk_apb))
+		return PTR_ERR(common->clk_apb);
+
+	common->clk_smi = devm_clk_get(dev, "smi");
+	if (IS_ERR(common->clk_smi))
+		return PTR_ERR(common->clk_smi);
+
+	pm_runtime_enable(dev);
+	platform_set_drvdata(pdev, common);
+	return 0;
+}
+
+static int mtk_smi_common_remove(struct platform_device *pdev)
+{
+	pm_runtime_disable(&pdev->dev);
+	return 0;
+}
+
+static const struct of_device_id mtk_smi_common_of_ids[] = {
+	{ .compatible = "mediatek,mt8173-smi-common", },
+	{}
+};
+
+static struct platform_driver mtk_smi_common_driver = {
+	.probe	= mtk_smi_common_probe,
+	.remove = mtk_smi_common_remove,
+	.driver	= {
+		.name = "mtk-smi-common",
+		.of_match_table = mtk_smi_common_of_ids,
+	}
+};
+
+static int __init mtk_smi_init(void)
+{
+	int ret;
+
+	ret = platform_driver_register(&mtk_smi_common_driver);
+	if (ret != 0) {
+		pr_err("Failed to register SMI driver\n");
+		return ret;
+	}
+
+	ret = platform_driver_register(&mtk_smi_larb_driver);
+	if (ret != 0) {
+		pr_err("Failed to register SMI-LARB driver\n");
+		goto err_unreg_smi;
+	}
+	return ret;
+
+err_unreg_smi:
+	platform_driver_unregister(&mtk_smi_common_driver);
+	return ret;
+}
+subsys_initcall(mtk_smi_init);
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
new file mode 100644
index 0000000..8893c5e
--- /dev/null
+++ b/include/soc/mediatek/smi.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright (c) 2015-2016 MediaTek Inc.
+ * Author: Yong Wu <yong.wu at mediatek.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.
+ */
+#ifndef MTK_IOMMU_SMI_H
+#define MTK_IOMMU_SMI_H
+
+#include <linux/bitops.h>
+#include <linux/device.h>
+
+#ifdef CONFIG_MTK_SMI
+
+#define MTK_LARB_NR_MAX		8
+
+#define MTK_SMI_MMU_EN(port)	BIT(port)
+
+struct mtk_smi_larb_iommu {
+	struct device *dev;
+	unsigned int   mmu;
+};
+
+struct mtk_smi_iommu {
+	unsigned int larb_nr;
+	struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX];
+};
+
+/*
+ * mtk_smi_larb_get: Enable the power domain and clocks for this local arbiter.
+ *                   It also initialize some basic setting(like iommu).
+ * mtk_smi_larb_put: Disable the power domain and clocks for this local arbiter.
+ * Both should be called in non-atomic context.
+ *
+ * Returns 0 if successful, negative on failure.
+ */
+int mtk_smi_larb_get(struct device *larbdev);
+void mtk_smi_larb_put(struct device *larbdev);
+
+#else
+
+static inline int mtk_smi_larb_get(struct device *larbdev)
+{
+	return 0;
+}
+
+static inline void mtk_smi_larb_put(struct device *larbdev) { }
+
+#endif
+
+#endif
-- 
1.8.1.1.dirty



From yong.wu at mediatek.com  Tue Feb 16 16:46:13 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Wed, 17 Feb 2016 08:46:13 +0800
Subject: [PATCH v9 4/5] iommu/mediatek: Add mt8173 IOMMU driver
In-Reply-To: <1455669974-1527-1-git-send-email-yong.wu@mediatek.com>
References: <1455669974-1527-1-git-send-email-yong.wu@mediatek.com>
Message-ID: <1455669974-1527-5-git-send-email-yong.wu@mediatek.com>

This patch adds support for mediatek m4u (MultiMedia Memory Management
Unit).

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Reviewed-by: Robin Murphy <robin.murphy at arm.com>
---
 drivers/iommu/Kconfig     |  16 +
 drivers/iommu/Makefile    |   1 +
 drivers/iommu/mtk_iommu.c | 732 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 749 insertions(+)
 create mode 100644 drivers/iommu/mtk_iommu.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index a1e75cb..4922aa8 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -318,4 +318,20 @@ config S390_IOMMU
 	help
 	  Support for the IOMMU API for s390 PCI devices.
 
+config MTK_IOMMU
+	bool "MTK IOMMU Support"
+	depends on ARM || ARM64
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	select IOMMU_API
+	select IOMMU_DMA
+	select IOMMU_IO_PGTABLE_ARMV7S
+	select MEMORY
+	select MTK_SMI
+	help
+	  Support for the M4U on certain Mediatek SOCs. M4U is MultiMedia
+	  Memory Management Unit. This option enables remapping of DMA memory
+	  accesses for the multimedia subsystem.
+
+	  If unsure, say N here.
+
 endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 42fc0c2..44ae2e0 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_INTEL_IOMMU) += intel-iommu.o
 obj-$(CONFIG_INTEL_IOMMU_SVM) += intel-svm.o
 obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
 obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
+obj-$(CONFIG_MTK_IOMMU) += mtk_iommu.o
 obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
 obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
 obj-$(CONFIG_ROCKCHIP_IOMMU) += rockchip-iommu.o
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
new file mode 100644
index 0000000..60fe97b
--- /dev/null
+++ b/drivers/iommu/mtk_iommu.c
@@ -0,0 +1,732 @@
+/*
+ * Copyright (c) 2015-2016 MediaTek Inc.
+ * Author: Yong Wu <yong.wu at mediatek.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.
+ */
+#include <linux/clk.h>
+#include <linux/component.h>
+#include <linux/dma-iommu.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iommu.h>
+#include <linux/iopoll.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_iommu.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <soc/mediatek/smi.h>
+#include <dt-bindings/memory/mt8173-larb-port.h>
+
+#include "io-pgtable.h"
+
+#define REG_MMU_PT_BASE_ADDR			0x000
+
+#define REG_MMU_INVALIDATE			0x020
+#define F_ALL_INVLD				0x2
+#define F_MMU_INV_RANGE				0x1
+
+#define REG_MMU_INVLD_START_A			0x024
+#define REG_MMU_INVLD_END_A			0x028
+
+#define REG_MMU_INV_SEL				0x038
+#define F_INVLD_EN0				BIT(0)
+#define F_INVLD_EN1				BIT(1)
+
+#define REG_MMU_STANDARD_AXI_MODE		0x048
+#define REG_MMU_DCM_DIS				0x050
+
+#define REG_MMU_CTRL_REG			0x110
+#define F_MMU_PREFETCH_RT_REPLACE_MOD		BIT(4)
+#define F_MMU_TF_PROTECT_SEL(prot)		(((prot) & 0x3) << 5)
+
+#define REG_MMU_IVRP_PADDR			0x114
+#define F_MMU_IVRP_PA_SET(pa)			((pa) >> 1)
+
+#define REG_MMU_INT_CONTROL0			0x120
+#define F_L2_MULIT_HIT_EN			BIT(0)
+#define F_TABLE_WALK_FAULT_INT_EN		BIT(1)
+#define F_PREETCH_FIFO_OVERFLOW_INT_EN		BIT(2)
+#define F_MISS_FIFO_OVERFLOW_INT_EN		BIT(3)
+#define F_PREFETCH_FIFO_ERR_INT_EN		BIT(5)
+#define F_MISS_FIFO_ERR_INT_EN			BIT(6)
+#define F_INT_CLR_BIT				BIT(12)
+
+#define REG_MMU_INT_MAIN_CONTROL		0x124
+#define F_INT_TRANSLATION_FAULT			BIT(0)
+#define F_INT_MAIN_MULTI_HIT_FAULT		BIT(1)
+#define F_INT_INVALID_PA_FAULT			BIT(2)
+#define F_INT_ENTRY_REPLACEMENT_FAULT		BIT(3)
+#define F_INT_TLB_MISS_FAULT			BIT(4)
+#define F_INT_MISS_TRANSACTION_FIFO_FAULT	BIT(5)
+#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT	BIT(6)
+
+#define REG_MMU_CPE_DONE			0x12C
+
+#define REG_MMU_FAULT_ST1			0x134
+
+#define REG_MMU_FAULT_VA			0x13c
+#define F_MMU_FAULT_VA_MSK			0xfffff000
+#define F_MMU_FAULT_VA_WRITE_BIT		BIT(1)
+#define F_MMU_FAULT_VA_LAYER_BIT		BIT(0)
+
+#define REG_MMU_INVLD_PA			0x140
+#define REG_MMU_INT_ID				0x150
+#define F_MMU0_INT_ID_LARB_ID(a)		(((a) >> 7) & 0x7)
+#define F_MMU0_INT_ID_PORT_ID(a)		(((a) >> 2) & 0x1f)
+
+#define MTK_PROTECT_PA_ALIGN			128
+
+struct mtk_iommu_suspend_reg {
+	u32				standard_axi_mode;
+	u32				dcm_dis;
+	u32				ctrl_reg;
+	u32				int_control0;
+	u32				int_main_control;
+};
+
+struct mtk_iommu_client_priv {
+	struct list_head		client;
+	unsigned int			mtk_m4u_id;
+	struct device			*m4udev;
+};
+
+struct mtk_iommu_domain {
+	spinlock_t			pgtlock; /* lock for page table */
+
+	struct io_pgtable_cfg		cfg;
+	struct io_pgtable_ops		*iop;
+
+	struct iommu_domain		domain;
+};
+
+struct mtk_iommu_data {
+	void __iomem			*base;
+	int				irq;
+	struct device			*dev;
+	struct clk			*bclk;
+	phys_addr_t			protect_base; /* protect memory base */
+	struct mtk_iommu_suspend_reg	reg;
+	struct mtk_iommu_domain		*m4u_dom;
+	struct iommu_group		*m4u_group;
+	struct mtk_smi_iommu		smi_imu;      /* SMI larb iommu info */
+};
+
+static struct iommu_ops mtk_iommu_ops;
+
+static struct mtk_iommu_domain *to_mtk_domain(struct iommu_domain *dom)
+{
+	return container_of(dom, struct mtk_iommu_domain, domain);
+}
+
+static void mtk_iommu_tlb_flush_all(void *cookie)
+{
+	struct mtk_iommu_data *data = cookie;
+
+	writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0, data->base + REG_MMU_INV_SEL);
+	writel_relaxed(F_ALL_INVLD, data->base + REG_MMU_INVALIDATE);
+	wmb(); /* Make sure the tlb flush all done */
+}
+
+static void mtk_iommu_tlb_add_flush_nosync(unsigned long iova, size_t size,
+					   size_t granule, bool leaf,
+					   void *cookie)
+{
+	struct mtk_iommu_data *data = cookie;
+
+	writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0, data->base + REG_MMU_INV_SEL);
+
+	writel_relaxed(iova, data->base + REG_MMU_INVLD_START_A);
+	writel_relaxed(iova + size - 1, data->base + REG_MMU_INVLD_END_A);
+	writel_relaxed(F_MMU_INV_RANGE, data->base + REG_MMU_INVALIDATE);
+}
+
+static void mtk_iommu_tlb_sync(void *cookie)
+{
+	struct mtk_iommu_data *data = cookie;
+	int ret;
+	u32 tmp;
+
+	ret = readl_poll_timeout_atomic(data->base + REG_MMU_CPE_DONE, tmp,
+					tmp != 0, 10, 100000);
+	if (ret) {
+		dev_warn(data->dev,
+			 "Partial TLB flush timed out, falling back to full flush\n");
+		mtk_iommu_tlb_flush_all(cookie);
+	}
+	/* Clear the CPE status */
+	writel_relaxed(0, data->base + REG_MMU_CPE_DONE);
+}
+
+static const struct iommu_gather_ops mtk_iommu_gather_ops = {
+	.tlb_flush_all = mtk_iommu_tlb_flush_all,
+	.tlb_add_flush = mtk_iommu_tlb_add_flush_nosync,
+	.tlb_sync = mtk_iommu_tlb_sync,
+};
+
+static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
+{
+	struct mtk_iommu_data *data = dev_id;
+	struct mtk_iommu_domain *dom = data->m4u_dom;
+	u32 int_state, regval, fault_iova, fault_pa;
+	unsigned int fault_larb, fault_port;
+	bool layer, write;
+
+	/* Read error info from registers */
+	int_state = readl_relaxed(data->base + REG_MMU_FAULT_ST1);
+	fault_iova = readl_relaxed(data->base + REG_MMU_FAULT_VA);
+	layer = fault_iova & F_MMU_FAULT_VA_LAYER_BIT;
+	write = fault_iova & F_MMU_FAULT_VA_WRITE_BIT;
+	fault_iova &= F_MMU_FAULT_VA_MSK;
+	fault_pa = readl_relaxed(data->base + REG_MMU_INVLD_PA);
+	regval = readl_relaxed(data->base + REG_MMU_INT_ID);
+	fault_larb = F_MMU0_INT_ID_LARB_ID(regval);
+	fault_port = F_MMU0_INT_ID_PORT_ID(regval);
+
+	if (report_iommu_fault(&dom->domain, data->dev, fault_iova,
+			       write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
+		dev_err_ratelimited(
+			data->dev,
+			"fault type=0x%x iova=0x%x pa=0x%x larb=%d port=%d layer=%d %s\n",
+			int_state, fault_iova, fault_pa, fault_larb, fault_port,
+			layer, write ? "write" : "read");
+	}
+
+	/* Interrupt clear */
+	regval = readl_relaxed(data->base + REG_MMU_INT_CONTROL0);
+	regval |= F_INT_CLR_BIT;
+	writel_relaxed(regval, data->base + REG_MMU_INT_CONTROL0);
+
+	mtk_iommu_tlb_flush_all(data);
+
+	return IRQ_HANDLED;
+}
+
+static void mtk_iommu_config(struct mtk_iommu_data *data,
+			     struct device *dev, bool enable)
+{
+	struct mtk_iommu_client_priv *head, *cur, *next;
+	struct mtk_smi_larb_iommu    *larb_mmu;
+	unsigned int                 larbid, portid;
+
+	head = dev->archdata.iommu;
+	list_for_each_entry_safe(cur, next, &head->client, client) {
+		larbid = MTK_M4U_TO_LARB(cur->mtk_m4u_id);
+		portid = MTK_M4U_TO_PORT(cur->mtk_m4u_id);
+		larb_mmu = &data->smi_imu.larb_imu[larbid];
+
+		dev_dbg(dev, "%s iommu port: %d\n",
+			enable ? "enable" : "disable", portid);
+
+		if (enable)
+			larb_mmu->mmu |= MTK_SMI_MMU_EN(portid);
+		else
+			larb_mmu->mmu &= ~MTK_SMI_MMU_EN(portid);
+	}
+}
+
+static int mtk_iommu_domain_finalise(struct mtk_iommu_data *data)
+{
+	struct mtk_iommu_domain *dom = data->m4u_dom;
+
+	spin_lock_init(&dom->pgtlock);
+
+	dom->cfg = (struct io_pgtable_cfg) {
+		.quirks = IO_PGTABLE_QUIRK_ARM_NS |
+			IO_PGTABLE_QUIRK_NO_PERMS |
+			IO_PGTABLE_QUIRK_TLBI_ON_MAP,
+		.pgsize_bitmap = mtk_iommu_ops.pgsize_bitmap,
+		.ias = 32,
+		.oas = 32,
+		.tlb = &mtk_iommu_gather_ops,
+		.iommu_dev = data->dev,
+	};
+
+	dom->iop = alloc_io_pgtable_ops(ARM_V7S, &dom->cfg, data);
+	if (!dom->iop) {
+		dev_err(data->dev, "Failed to alloc io pgtable\n");
+		return -EINVAL;
+	}
+
+	/* Update our support page sizes bitmap */
+	mtk_iommu_ops.pgsize_bitmap = dom->cfg.pgsize_bitmap;
+
+	writel(data->m4u_dom->cfg.arm_v7s_cfg.ttbr[0],
+	       data->base + REG_MMU_PT_BASE_ADDR);
+	return 0;
+}
+
+static struct iommu_domain *mtk_iommu_domain_alloc(unsigned type)
+{
+	struct mtk_iommu_domain *dom;
+
+	if (type != IOMMU_DOMAIN_DMA)
+		return NULL;
+
+	dom = kzalloc(sizeof(*dom), GFP_KERNEL);
+	if (!dom)
+		return NULL;
+
+	if (iommu_get_dma_cookie(&dom->domain)) {
+		kfree(dom);
+		return NULL;
+	}
+
+	dom->domain.geometry.aperture_start = 0;
+	dom->domain.geometry.aperture_end = DMA_BIT_MASK(32);
+	dom->domain.geometry.force_aperture = true;
+
+	return &dom->domain;
+}
+
+static void mtk_iommu_domain_free(struct iommu_domain *domain)
+{
+	iommu_put_dma_cookie(domain);
+	kfree(to_mtk_domain(domain));
+}
+
+static int mtk_iommu_attach_device(struct iommu_domain *domain,
+				   struct device *dev)
+{
+	struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+	struct mtk_iommu_client_priv *priv = dev->archdata.iommu;
+	struct mtk_iommu_data *data;
+	int ret;
+
+	if (!priv)
+		return -ENODEV;
+
+	data = dev_get_drvdata(priv->m4udev);
+	if (!data->m4u_dom) {
+		data->m4u_dom = dom;
+		ret = mtk_iommu_domain_finalise(data);
+		if (ret) {
+			data->m4u_dom = NULL;
+			return ret;
+		}
+	} else if (data->m4u_dom != dom) {
+		/* All the client devices should be in the same m4u domain */
+		dev_err(dev, "try to attach into the error iommu domain\n");
+		return -EPERM;
+	}
+
+	mtk_iommu_config(data, dev, true);
+	return 0;
+}
+
+static void mtk_iommu_detach_device(struct iommu_domain *domain,
+				    struct device *dev)
+{
+	struct mtk_iommu_client_priv *priv = dev->archdata.iommu;
+	struct mtk_iommu_data *data;
+
+	if (!priv)
+		return;
+
+	data = dev_get_drvdata(priv->m4udev);
+	mtk_iommu_config(data, dev, false);
+}
+
+static int mtk_iommu_map(struct iommu_domain *domain, unsigned long iova,
+			 phys_addr_t paddr, size_t size, int prot)
+{
+	struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&dom->pgtlock, flags);
+	ret = dom->iop->map(dom->iop, iova, paddr, size, prot);
+	spin_unlock_irqrestore(&dom->pgtlock, flags);
+
+	return ret;
+}
+
+static size_t mtk_iommu_unmap(struct iommu_domain *domain,
+			      unsigned long iova, size_t size)
+{
+	struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+	unsigned long flags;
+	size_t unmapsz;
+
+	spin_lock_irqsave(&dom->pgtlock, flags);
+	unmapsz = dom->iop->unmap(dom->iop, iova, size);
+	spin_unlock_irqrestore(&dom->pgtlock, flags);
+
+	return unmapsz;
+}
+
+static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
+					  dma_addr_t iova)
+{
+	struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+	unsigned long flags;
+	phys_addr_t pa;
+
+	spin_lock_irqsave(&dom->pgtlock, flags);
+	pa = dom->iop->iova_to_phys(dom->iop, iova);
+	spin_unlock_irqrestore(&dom->pgtlock, flags);
+
+	return pa;
+}
+
+static int mtk_iommu_add_device(struct device *dev)
+{
+	struct iommu_group *group;
+
+	if (!dev->archdata.iommu) /* Not a iommu client device */
+		return -ENODEV;
+
+	group = iommu_group_get_for_dev(dev);
+	if (IS_ERR(group))
+		return PTR_ERR(group);
+
+	iommu_group_put(group);
+	return 0;
+}
+
+static void mtk_iommu_remove_device(struct device *dev)
+{
+	struct mtk_iommu_client_priv *head, *cur, *next;
+
+	head = dev->archdata.iommu;
+	if (!head)
+		return;
+
+	list_for_each_entry_safe(cur, next, &head->client, client) {
+		list_del(&cur->client);
+		kfree(cur);
+	}
+	kfree(head);
+	dev->archdata.iommu = NULL;
+
+	iommu_group_remove_device(dev);
+}
+
+static struct iommu_group *mtk_iommu_device_group(struct device *dev)
+{
+	struct mtk_iommu_data *data;
+	struct mtk_iommu_client_priv *priv;
+
+	priv = dev->archdata.iommu;
+	if (!priv)
+		return ERR_PTR(-ENODEV);
+
+	/* All the client devices are in the same m4u iommu-group */
+	data = dev_get_drvdata(priv->m4udev);
+	if (!data->m4u_group) {
+		data->m4u_group = iommu_group_alloc();
+		if (IS_ERR(data->m4u_group))
+			dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+	}
+	return data->m4u_group;
+}
+
+static int mtk_iommu_of_xlate(struct device *dev, struct of_phandle_args *args)
+{
+	struct mtk_iommu_client_priv *head, *priv, *next;
+	struct platform_device *m4updev;
+
+	if (args->args_count != 1) {
+		dev_err(dev, "invalid #iommu-cells(%d) property for IOMMU\n",
+			args->args_count);
+		return -EINVAL;
+	}
+
+	if (!dev->archdata.iommu) {
+		/* Get the m4u device */
+		m4updev = of_find_device_by_node(args->np);
+		of_node_put(args->np);
+		if (WARN_ON(!m4updev))
+			return -EINVAL;
+
+		head = kzalloc(sizeof(*head), GFP_KERNEL);
+		if (!head)
+			return -ENOMEM;
+
+		dev->archdata.iommu = head;
+		INIT_LIST_HEAD(&head->client);
+		head->m4udev = &m4updev->dev;
+	} else {
+		head = dev->archdata.iommu;
+	}
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		goto err_free_mem;
+
+	priv->mtk_m4u_id = args->args[0];
+	list_add_tail(&priv->client, &head->client);
+
+	return 0;
+
+err_free_mem:
+	list_for_each_entry_safe(priv, next, &head->client, client)
+		kfree(priv);
+	kfree(head);
+	dev->archdata.iommu = NULL;
+	return -ENOMEM;
+}
+
+static struct iommu_ops mtk_iommu_ops = {
+	.domain_alloc	= mtk_iommu_domain_alloc,
+	.domain_free	= mtk_iommu_domain_free,
+	.attach_dev	= mtk_iommu_attach_device,
+	.detach_dev	= mtk_iommu_detach_device,
+	.map		= mtk_iommu_map,
+	.unmap		= mtk_iommu_unmap,
+	.map_sg		= default_iommu_map_sg,
+	.iova_to_phys	= mtk_iommu_iova_to_phys,
+	.add_device	= mtk_iommu_add_device,
+	.remove_device	= mtk_iommu_remove_device,
+	.device_group	= mtk_iommu_device_group,
+	.of_xlate	= mtk_iommu_of_xlate,
+	.pgsize_bitmap	= SZ_4K | SZ_64K | SZ_1M | SZ_16M,
+};
+
+static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
+{
+	u32 regval;
+	int ret;
+
+	ret = clk_prepare_enable(data->bclk);
+	if (ret) {
+		dev_err(data->dev, "Failed to enable iommu bclk(%d)\n", ret);
+		return ret;
+	}
+
+	regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
+		F_MMU_TF_PROTECT_SEL(2);
+	writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
+
+	regval = F_L2_MULIT_HIT_EN |
+		F_TABLE_WALK_FAULT_INT_EN |
+		F_PREETCH_FIFO_OVERFLOW_INT_EN |
+		F_MISS_FIFO_OVERFLOW_INT_EN |
+		F_PREFETCH_FIFO_ERR_INT_EN |
+		F_MISS_FIFO_ERR_INT_EN;
+	writel_relaxed(regval, data->base + REG_MMU_INT_CONTROL0);
+
+	regval = F_INT_TRANSLATION_FAULT |
+		F_INT_MAIN_MULTI_HIT_FAULT |
+		F_INT_INVALID_PA_FAULT |
+		F_INT_ENTRY_REPLACEMENT_FAULT |
+		F_INT_TLB_MISS_FAULT |
+		F_INT_MISS_TRANSACTION_FIFO_FAULT |
+		F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
+	writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
+
+	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base),
+		       data->base + REG_MMU_IVRP_PADDR);
+
+	writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
+	writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
+
+	if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
+			     dev_name(data->dev), (void *)data)) {
+		writel_relaxed(0, data->base + REG_MMU_PT_BASE_ADDR);
+		clk_disable_unprepare(data->bclk);
+		dev_err(data->dev, "Failed @ IRQ-%d Request\n", data->irq);
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+static int compare_of(struct device *dev, void *data)
+{
+	return dev->of_node == data;
+}
+
+static int mtk_iommu_bind(struct device *dev)
+{
+	struct mtk_iommu_data *data = dev_get_drvdata(dev);
+
+	return component_bind_all(dev, &data->smi_imu);
+}
+
+static void mtk_iommu_unbind(struct device *dev)
+{
+	struct mtk_iommu_data *data = dev_get_drvdata(dev);
+
+	component_unbind_all(dev, &data->smi_imu);
+}
+
+static const struct component_master_ops mtk_iommu_com_ops = {
+	.bind		= mtk_iommu_bind,
+	.unbind		= mtk_iommu_unbind,
+};
+
+static int mtk_iommu_probe(struct platform_device *pdev)
+{
+	struct mtk_iommu_data   *data;
+	struct device           *dev = &pdev->dev;
+	struct resource         *res;
+	struct component_match  *match = NULL;
+	void                    *protect;
+	unsigned int            i, larb_nr;
+	int                     ret;
+
+	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+	data->dev = dev;
+
+	/* Protect memory. HW will access here while translation fault.*/
+	protect = devm_kzalloc(dev, MTK_PROTECT_PA_ALIGN * 2, GFP_KERNEL);
+	if (!protect)
+		return -ENOMEM;
+	data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	data->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(data->base))
+		return PTR_ERR(data->base);
+
+	data->irq = platform_get_irq(pdev, 0);
+	if (data->irq < 0)
+		return data->irq;
+
+	data->bclk = devm_clk_get(dev, "bclk");
+	if (IS_ERR(data->bclk))
+		return PTR_ERR(data->bclk);
+
+	larb_nr = of_count_phandle_with_args(dev->of_node,
+					     "mediatek,larbs", NULL);
+	if (larb_nr < 0)
+		return larb_nr;
+	data->smi_imu.larb_nr = larb_nr;
+
+	for (i = 0; i < larb_nr; i++) {
+		struct device_node *larbnode;
+		struct platform_device *plarbdev;
+
+		larbnode = of_parse_phandle(dev->of_node, "mediatek,larbs", i);
+		if (!larbnode)
+			return -EINVAL;
+
+		if (!of_device_is_available(larbnode))
+			continue;
+
+		plarbdev = of_find_device_by_node(larbnode);
+		of_node_put(larbnode);
+		if (!plarbdev) {
+			plarbdev = of_platform_device_create(
+						larbnode, NULL,
+						platform_bus_type.dev_root);
+			if (IS_ERR(plarbdev))
+				return -EPROBE_DEFER;
+		}
+		data->smi_imu.larb_imu[i].dev = &plarbdev->dev;
+
+		component_match_add(dev, &match, compare_of, larbnode);
+	}
+
+	platform_set_drvdata(pdev, data);
+
+	ret = mtk_iommu_hw_init(data);
+	if (ret)
+		return ret;
+
+	if (!iommu_present(&platform_bus_type))
+		bus_set_iommu(&platform_bus_type, &mtk_iommu_ops);
+
+	return component_master_add_with_match(dev, &mtk_iommu_com_ops, match);
+}
+
+static int mtk_iommu_remove(struct platform_device *pdev)
+{
+	struct mtk_iommu_data *data = platform_get_drvdata(pdev);
+
+	if (iommu_present(&platform_bus_type))
+		bus_set_iommu(&platform_bus_type, NULL);
+
+	free_io_pgtable_ops(data->m4u_dom->iop);
+	clk_disable_unprepare(data->bclk);
+	devm_free_irq(&pdev->dev, data->irq, data);
+	component_master_del(&pdev->dev, &mtk_iommu_com_ops);
+	return 0;
+}
+
+static int mtk_iommu_suspend(struct device *dev)
+{
+	struct mtk_iommu_data *data = dev_get_drvdata(dev);
+	struct mtk_iommu_suspend_reg *reg = &data->reg;
+	void __iomem *base = data->base;
+
+	reg->standard_axi_mode = readl_relaxed(base +
+					       REG_MMU_STANDARD_AXI_MODE);
+	reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
+	reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
+	reg->int_control0 = readl_relaxed(base + REG_MMU_INT_CONTROL0);
+	reg->int_main_control = readl_relaxed(base + REG_MMU_INT_MAIN_CONTROL);
+	return 0;
+}
+
+static int mtk_iommu_resume(struct device *dev)
+{
+	struct mtk_iommu_data *data = dev_get_drvdata(dev);
+	struct mtk_iommu_suspend_reg *reg = &data->reg;
+	void __iomem *base = data->base;
+
+	writel_relaxed(data->m4u_dom->cfg.arm_v7s_cfg.ttbr[0],
+		       base + REG_MMU_PT_BASE_ADDR);
+	writel_relaxed(reg->standard_axi_mode,
+		       base + REG_MMU_STANDARD_AXI_MODE);
+	writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
+	writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
+	writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
+	writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
+	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base),
+		       base + REG_MMU_IVRP_PADDR);
+	return 0;
+}
+
+const struct dev_pm_ops mtk_iommu_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(mtk_iommu_suspend, mtk_iommu_resume)
+};
+
+static const struct of_device_id mtk_iommu_of_ids[] = {
+	{ .compatible = "mediatek,mt8173-m4u", },
+	{}
+};
+
+static struct platform_driver mtk_iommu_driver = {
+	.probe	= mtk_iommu_probe,
+	.remove	= mtk_iommu_remove,
+	.driver	= {
+		.name = "mtk-iommu",
+		.of_match_table = mtk_iommu_of_ids,
+		.pm = &mtk_iommu_pm_ops,
+	}
+};
+
+static int mtk_iommu_init_fn(struct device_node *np)
+{
+	int ret;
+	struct platform_device *pdev;
+
+	pdev = of_platform_device_create(np, NULL, platform_bus_type.dev_root);
+	if (IS_ERR(pdev))
+		return PTR_ERR(pdev);
+
+	ret = platform_driver_register(&mtk_iommu_driver);
+	if (ret) {
+		pr_err("%s: Failed to register driver\n", __func__);
+		return ret;
+	}
+
+	of_iommu_set_ops(np, &mtk_iommu_ops);
+	return 0;
+}
+
+IOMMU_OF_DECLARE(mtkm4u, "mediatek,mt8173-m4u", mtk_iommu_init_fn);
-- 
1.8.1.1.dirty



From yong.wu at mediatek.com  Tue Feb 16 16:46:14 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Wed, 17 Feb 2016 08:46:14 +0800
Subject: [PATCH v9 5/5] dts: mt8173: Add iommu/smi nodes for mt8173
In-Reply-To: <1455669974-1527-1-git-send-email-yong.wu@mediatek.com>
References: <1455669974-1527-1-git-send-email-yong.wu@mediatek.com>
Message-ID: <1455669974-1527-6-git-send-email-yong.wu@mediatek.com>

This patch add the iommu/larbs nodes for mt8173

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Reviewed-by: Daniel Kurtz <djkurtz at chromium.org>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 81 ++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index ec135ea..8048811 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -14,6 +14,7 @@
 #include <dt-bindings/clock/mt8173-clk.h>
 #include <dt-bindings/interrupt-controller/irq.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/memory/mt8173-larb-port.h>
 #include <dt-bindings/phy/phy.h>
 #include <dt-bindings/power/mt8173-power.h>
 #include <dt-bindings/reset/mt8173-resets.h>
@@ -277,6 +278,17 @@
 			reg = <0 0x10200620 0 0x20>;
 		};
 
+		iommu: iommu at 10205000 {
+			compatible = "mediatek,mt8173-m4u";
+			reg = <0 0x10205000 0 0x1000>;
+			interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>;
+			clocks = <&infracfg CLK_INFRA_M4U>;
+			clock-names = "bclk";
+			mediatek,larbs = <&larb0 &larb1 &larb2
+					  &larb3 &larb4 &larb5>;
+			#iommu-cells = <1>;
+		};
+
 		apmixedsys: clock-controller at 10209000 {
 			compatible = "mediatek,mt8173-apmixedsys";
 			reg = <0 0x10209000 0 0x1000>;
@@ -589,29 +601,98 @@
 			status = "disabled";
 		};
 
+		larb0: larb at 14021000 {
+			compatible = "mediatek,mt8173-smi-larb";
+			reg = <0 0x14021000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_SMI_LARB0>,
+				 <&mmsys CLK_MM_SMI_LARB0>;
+			clock-names = "apb", "smi";
+		};
+
+		smi_common: smi at 14022000 {
+			compatible = "mediatek,mt8173-smi-common";
+			reg = <0 0x14022000 0 0x1000>;
+			power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_SMI_COMMON>,
+				 <&mmsys CLK_MM_SMI_COMMON>;
+			clock-names = "apb", "smi";
+		};
+
+		larb4: larb at 14027000 {
+			compatible = "mediatek,mt8173-smi-larb";
+			reg = <0 0x14027000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_SMI_LARB4>,
+				 <&mmsys CLK_MM_SMI_LARB4>;
+			clock-names = "apb", "smi";
+		};
+
 		imgsys: clock-controller at 15000000 {
 			compatible = "mediatek,mt8173-imgsys", "syscon";
 			reg = <0 0x15000000 0 0x1000>;
 			#clock-cells = <1>;
 		};
 
+		larb2: larb at 15001000 {
+			compatible = "mediatek,mt8173-smi-larb";
+			reg = <0 0x15001000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			power-domains = <&scpsys MT8173_POWER_DOMAIN_ISP>;
+			clocks = <&imgsys CLK_IMG_LARB2_SMI>,
+				 <&imgsys CLK_IMG_LARB2_SMI>;
+			clock-names = "apb", "smi";
+		};
+
 		vdecsys: clock-controller at 16000000 {
 			compatible = "mediatek,mt8173-vdecsys", "syscon";
 			reg = <0 0x16000000 0 0x1000>;
 			#clock-cells = <1>;
 		};
 
+		larb1: larb at 16010000 {
+			compatible = "mediatek,mt8173-smi-larb";
+			reg = <0 0x16010000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
+			clocks = <&vdecsys CLK_VDEC_CKEN>,
+				 <&vdecsys CLK_VDEC_LARB_CKEN>;
+			clock-names = "apb", "smi";
+		};
+
 		vencsys: clock-controller at 18000000 {
 			compatible = "mediatek,mt8173-vencsys", "syscon";
 			reg = <0 0x18000000 0 0x1000>;
 			#clock-cells = <1>;
 		};
 
+		larb3: larb at 18001000 {
+			compatible = "mediatek,mt8173-smi-larb";
+			reg = <0 0x18001000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			power-domains = <&scpsys MT8173_POWER_DOMAIN_VENC>;
+			clocks = <&vencsys CLK_VENC_CKE1>,
+				 <&vencsys CLK_VENC_CKE0>;
+			clock-names = "apb", "smi";
+		};
+
 		vencltsys: clock-controller at 19000000 {
 			compatible = "mediatek,mt8173-vencltsys", "syscon";
 			reg = <0 0x19000000 0 0x1000>;
 			#clock-cells = <1>;
 		};
+
+		larb5: larb at 19001000 {
+			compatible = "mediatek,mt8173-smi-larb";
+			reg = <0 0x19001000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			power-domains = <&scpsys MT8173_POWER_DOMAIN_VENC_LT>;
+			clocks = <&vencltsys CLK_VENCLT_CKE1>,
+				 <&vencltsys CLK_VENCLT_CKE0>;
+			clock-names = "apb", "smi";
+		};
 	};
 };
 
-- 
1.8.1.1.dirty



From m.szyprowski at samsung.com  Wed Feb 17 00:55:33 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Wed, 17 Feb 2016 09:55:33 +0100
Subject: [PATCH] ARM64: dma-mapping: fix IOMMU-based dma_mmap_atts()
 implementation
In-Reply-To: <56C339FD.6040907@arm.com>
References: <1455632065-14620-1-git-send-email-m.szyprowski@samsung.com>
 <56C339FD.6040907@arm.com>
Message-ID: <56C43585.9030502@samsung.com>

Hello,

On 2016-02-16 16:02, Robin Murphy wrote:
> Hi Marek,
>
> On 16/02/16 14:14, Marek Szyprowski wrote:
>> IOMMU-based DMA-mapping implementation doesn't support
>> dma_declare_coherent() based regions, so there is no point to call
>> dma_mmap_from_coherent() from __iommu_mmap_atts(). This patch removes
>> useless code.
>
> I'm not sure that's the case - AFAICS a device could still have its 
> own local memory despite being behind an IOMMU relative to the rest of 
> the system. If it uses dma_declare_coherent() for that, the .alloc and 
> .free callbacks here might be bypassed by dma_{alloc,free}_attrs() 
> short-circuiting into dma_{alloc,release}_from_coherent(), but in the 
> case of dma_mmap_attrs() it hits the .mmap callback first and only 
> falls back to the from_coherent check in dma_common_mmap() if that 
> isn't implemented.

Okay, I've missed that alloc/free_from_coherent is handled in generic
include/linux/dma-mapping.h. It is still a bit strange case with no real
user, but if this code is already there, then let it be.

>
> Maybe the right thing to do would be to move this check (with its 
> associated guards) out from dma_common_mmap() up to dma_mmap_attrs() 
> to be consistent with alloc/free; so that it doesn't need to be 
> reimplemented all over arch/{arm,arm64,mips} at all?
>

That might be a good idea, although I'm not sure how portable is
pgprot_dmacoherent(), which will be needed by such common code.

Please ignore my patch then.

> Robin.
>
>> Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
>> ---
>>   arch/arm64/mm/dma-mapping.c | 5 -----
>>   1 file changed, 5 deletions(-)
>>
>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>> index 331c4ca..573b1e6 100644
>> --- a/arch/arm64/mm/dma-mapping.c
>> +++ b/arch/arm64/mm/dma-mapping.c
>> @@ -636,14 +636,9 @@ static int __iommu_mmap_attrs(struct device 
>> *dev, struct vm_area_struct *vma,
>>                     struct dma_attrs *attrs)
>>   {
>>       struct vm_struct *area;
>> -    int ret;
>>
>>       vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot,
>>                            is_device_dma_coherent(dev));
>> -
>> -    if (dma_mmap_from_coherent(dev, vma, cpu_addr, size, &ret))
>> -        return ret;
>> -
>>       area = find_vm_area(cpu_addr);
>>       if (WARN_ON(!area || !area->pages))
>>           return -ENXIO;
>

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From tiwai at suse.de  Wed Feb 17 01:03:50 2016
From: tiwai at suse.de (Takashi Iwai)
Date: Wed, 17 Feb 2016 10:03:50 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <3395859.dhsfOsmVIe@wuerfel>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
 <s5hr3gc60ph.wl-tiwai@suse.de> <2706488.VpKveMVPGI@wuerfel>
 <3395859.dhsfOsmVIe@wuerfel>
Message-ID: <s5h8u2j6749.wl-tiwai@suse.de>

On Tue, 16 Feb 2016 23:08:13 +0100,
Arnd Bergmann wrote:
> 
> On Tuesday 16 February 2016 18:26:09 Arnd Bergmann wrote:
> > >                 return err;
> > >         per_pin->acomp_jack = jack;
> > > -       jack->private_data = per_pin;
> > > -       jack->private_free = free_acomp_jack_priv;
> > > +       if (jack) {
> > > +               jack->private_data = per_pin;
> > > +               jack->private_free = free_acomp_jack_priv;
> > > +       }
> > >         return 0;
> > >  }
> > > 
> > Looks good to me.
> > 
> > Acked-by: Arnd Bergmann <arnd at arndb.de>
> > 
> 
> Actually, on second thought, there is one notable downside
> of this approach: 'jack' is guaranteed to be NULL here, so gcc
> won't produce a warning if another driver makes the same mistake:
> 
> By default, we only get a warning for uses of uninitialized
> variables, but not those that are known to be NULL. I think
> some compiler warnings are able to warn about that too, but I
> forgot the details.

Yes, that is a good point.

On third thought, we should look back how this issue came out.

Originally HD-audio driver had another jack implementation using ctl
API, and this could be unconditionally enabled.  The kctl jack was
unified into the input jack layer later, and the dependency issue came
out.  In that sense, the problem is that SND_JACK dependency is still
present although it's not needed -- namely, the jack layer itself can
be implemented in kctl even without input devices.

So, the missing piece is the conditional build of jack.c & co without
CONFIG_INPUT.  Then the dependency in the user's side can be ignored.

Below is the patch to do that.


Takashi

-- 8< --
From: Takashi Iwai <tiwai at suse.de>
Subject: [PATCH] ALSA: jack: Allow building the jack layer without input
 device

Since the recent integration of kctl jack and input jack layers, we
can basically build the jack layer even without input devices.  That
is, the jack layer itself can be built with conditional to enable the
input device support or not, while the users may enable always
CONFIG_SND_JACK unconditionally.

For achieving it, this patch changes the following:
- A new Kconfig, CONFIG_SND_JACK_INPUT_DEV, was introduced to indicate
  whether the jack layer supports the input device,
- A few items in snd_jack struct and relevant codes are conditionally
  built upon CONFIG_SND_JACK_INPUT_DEV,
- The users of CONFIG_SND_JACK drop the messy dependency on
  CONFIG_INPUT, but just select SND_JACK.

This change also automagically fixes a potential bug in HD-audio
driver Arnd reported, where the NULL or uninitialized jack instance is
dereferenced.

Reported-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Takashi Iwai <tiwai at suse.de>
---
 include/sound/jack.h  | 23 ++++++++++++++---------
 sound/core/Kconfig    |  9 ++++++---
 sound/core/jack.c     | 23 ++++++++++++++++++++---
 sound/pci/Kconfig     |  2 +-
 sound/pci/hda/Kconfig |  2 +-
 sound/soc/Kconfig     |  2 +-
 6 files changed, 43 insertions(+), 18 deletions(-)

diff --git a/include/sound/jack.h b/include/sound/jack.h
index 23bede121c78..1e84bfb553cf 100644
--- a/include/sound/jack.h
+++ b/include/sound/jack.h
@@ -72,14 +72,16 @@ enum snd_jack_types {
 #define SND_JACK_SWITCH_TYPES 6
 
 struct snd_jack {
-	struct input_dev *input_dev;
 	struct list_head kctl_list;
 	struct snd_card *card;
+	const char *id;
+#ifdef CONFIG_SND_JACK_INPUT_DEV
+	struct input_dev *input_dev;
 	int registered;
 	int type;
-	const char *id;
 	char name[100];
 	unsigned int key[6];   /* Keep in sync with definitions above */
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 	void *private_data;
 	void (*private_free)(struct snd_jack *);
 };
@@ -89,10 +91,11 @@ struct snd_jack {
 int snd_jack_new(struct snd_card *card, const char *id, int type,
 		 struct snd_jack **jack, bool initial_kctl, bool phantom_jack);
 int snd_jack_add_new_kctl(struct snd_jack *jack, const char * name, int mask);
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 void snd_jack_set_parent(struct snd_jack *jack, struct device *parent);
 int snd_jack_set_key(struct snd_jack *jack, enum snd_jack_types type,
 		     int keytype);
-
+#endif
 void snd_jack_report(struct snd_jack *jack, int status);
 
 #else
@@ -107,6 +110,13 @@ static inline int snd_jack_add_new_kctl(struct snd_jack *jack, const char * name
 	return 0;
 }
 
+static inline void snd_jack_report(struct snd_jack *jack, int status)
+{
+}
+
+#endif
+
+#if !defined(CONFIG_SND_JACK) || !defined(CONFIG_SND_JACK_INPUT_DEV)
 static inline void snd_jack_set_parent(struct snd_jack *jack,
 				       struct device *parent)
 {
@@ -118,11 +128,6 @@ static inline int snd_jack_set_key(struct snd_jack *jack,
 {
 	return 0;
 }
-
-static inline void snd_jack_report(struct snd_jack *jack, int status)
-{
-}
-
-#endif
+#endif /* !CONFIG_SND_JACK || !CONFIG_SND_JACK_INPUT_DEV */
 
 #endif
diff --git a/sound/core/Kconfig b/sound/core/Kconfig
index a2a1e24becc6..8b71e15898cd 100644
--- a/sound/core/Kconfig
+++ b/sound/core/Kconfig
@@ -24,11 +24,14 @@ config SND_RAWMIDI
 config SND_COMPRESS_OFFLOAD
 	tristate
 
-# To be effective this also requires INPUT - users should say:
-#    select SND_JACK if INPUT=y || INPUT=SND
-# to avoid having to force INPUT on.
 config SND_JACK
+	tristate
+
+# enable input device support in jack layer
+config SND_JACK_INPUT_DEV
 	bool
+	depends on SND_JACK
+	default y if INPUT=y || INPUT=SND
 
 config SND_SEQUENCER
 	tristate "Sequencer support"
diff --git a/sound/core/jack.c b/sound/core/jack.c
index 7237acbdcbbc..f652e90efd7e 100644
--- a/sound/core/jack.c
+++ b/sound/core/jack.c
@@ -32,6 +32,7 @@ struct snd_jack_kctl {
 	unsigned int mask_bits; /* only masked status bits are reported via kctl */
 };
 
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 static int jack_switch_types[SND_JACK_SWITCH_TYPES] = {
 	SW_HEADPHONE_INSERT,
 	SW_MICROPHONE_INSERT,
@@ -40,9 +41,11 @@ static int jack_switch_types[SND_JACK_SWITCH_TYPES] = {
 	SW_VIDEOOUT_INSERT,
 	SW_LINEIN_INSERT,
 };
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 
 static int snd_jack_dev_disconnect(struct snd_device *device)
 {
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 	struct snd_jack *jack = device->device_data;
 
 	if (!jack->input_dev)
@@ -55,6 +58,7 @@ static int snd_jack_dev_disconnect(struct snd_device *device)
 	else
 		input_free_device(jack->input_dev);
 	jack->input_dev = NULL;
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 	return 0;
 }
 
@@ -79,6 +83,7 @@ static int snd_jack_dev_free(struct snd_device *device)
 	return 0;
 }
 
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 static int snd_jack_dev_register(struct snd_device *device)
 {
 	struct snd_jack *jack = device->device_data;
@@ -116,6 +121,7 @@ static int snd_jack_dev_register(struct snd_device *device)
 
 	return err;
 }
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 
 static void snd_jack_kctl_private_free(struct snd_kcontrol *kctl)
 {
@@ -209,11 +215,12 @@ int snd_jack_new(struct snd_card *card, const char *id, int type,
 	struct snd_jack *jack;
 	struct snd_jack_kctl *jack_kctl = NULL;
 	int err;
-	int i;
 	static struct snd_device_ops ops = {
 		.dev_free = snd_jack_dev_free,
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 		.dev_register = snd_jack_dev_register,
 		.dev_disconnect = snd_jack_dev_disconnect,
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 	};
 
 	if (initial_kctl) {
@@ -230,6 +237,9 @@ int snd_jack_new(struct snd_card *card, const char *id, int type,
 
 	/* don't creat input device for phantom jack */
 	if (!phantom_jack) {
+#ifdef CONFIG_SND_JACK_INPUT_DEV
+		int i;
+
 		jack->input_dev = input_allocate_device();
 		if (jack->input_dev == NULL) {
 			err = -ENOMEM;
@@ -245,6 +255,7 @@ int snd_jack_new(struct snd_card *card, const char *id, int type,
 				input_set_capability(jack->input_dev, EV_SW,
 						     jack_switch_types[i]);
 
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 	}
 
 	err = snd_device_new(card, SNDRV_DEV_JACK, jack, &ops);
@@ -262,13 +273,16 @@ int snd_jack_new(struct snd_card *card, const char *id, int type,
 	return 0;
 
 fail_input:
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 	input_free_device(jack->input_dev);
+#endif
 	kfree(jack->id);
 	kfree(jack);
 	return err;
 }
 EXPORT_SYMBOL(snd_jack_new);
 
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 /**
  * snd_jack_set_parent - Set the parent device for a jack
  *
@@ -326,10 +340,10 @@ int snd_jack_set_key(struct snd_jack *jack, enum snd_jack_types type,
 
 	jack->type |= type;
 	jack->key[key] = keytype;
-
 	return 0;
 }
 EXPORT_SYMBOL(snd_jack_set_key);
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 
 /**
  * snd_jack_report - Report the current status of a jack
@@ -340,7 +354,9 @@ EXPORT_SYMBOL(snd_jack_set_key);
 void snd_jack_report(struct snd_jack *jack, int status)
 {
 	struct snd_jack_kctl *jack_kctl;
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 	int i;
+#endif
 
 	if (!jack)
 		return;
@@ -349,6 +365,7 @@ void snd_jack_report(struct snd_jack *jack, int status)
 		snd_kctl_jack_report(jack->card, jack_kctl->kctl,
 					    status & jack_kctl->mask_bits);
 
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 	if (!jack->input_dev)
 		return;
 
@@ -369,6 +386,6 @@ void snd_jack_report(struct snd_jack *jack, int status)
 	}
 
 	input_sync(jack->input_dev);
-
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 }
 EXPORT_SYMBOL(snd_jack_report);
diff --git a/sound/pci/Kconfig b/sound/pci/Kconfig
index 8f6594a7d37f..32151d8c6bb8 100644
--- a/sound/pci/Kconfig
+++ b/sound/pci/Kconfig
@@ -866,7 +866,7 @@ config SND_VIRTUOSO
 	select SND_OXYGEN_LIB
 	select SND_PCM
 	select SND_MPU401_UART
-	select SND_JACK if INPUT=y || INPUT=SND
+	select SND_JACK
 	help
 	  Say Y here to include support for sound cards based on the
 	  Asus AV66/AV100/AV200 chips, i.e., Xonar D1, DX, D2, D2X, DS, DSX,
diff --git a/sound/pci/hda/Kconfig b/sound/pci/hda/Kconfig
index e94cfd5c69f7..bb02c2d48fd5 100644
--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -4,7 +4,7 @@ config SND_HDA
 	tristate
 	select SND_PCM
 	select SND_VMASTER
-	select SND_JACK if INPUT=y || INPUT=SND
+	select SND_JACK
 	select SND_HDA_CORE
 
 config SND_HDA_INTEL
diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 7ea66ee3653f..182d92efc7c8 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -6,7 +6,7 @@ menuconfig SND_SOC
 	tristate "ALSA for SoC audio support"
 	select SND_PCM
 	select AC97_BUS if SND_SOC_AC97_BUS
-	select SND_JACK if INPUT=y || INPUT=SND
+	select SND_JACK
 	select REGMAP_I2C if I2C
 	select REGMAP_SPI if SPI_MASTER
 	---help---
-- 
2.7.1



From tomi.valkeinen at ti.com  Wed Feb 17 01:09:46 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Wed, 17 Feb 2016 11:09:46 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
Message-ID: <56C438DA.5040109@ti.com>

On 04/02/16 16:04, Linus Walleij wrote:
> This moves the versatile CLCD configuration to the device tree by:
> 
> - Deleting the board file set-up of CLCD displays and quirks,
>   instead relying on the driver to handle this. The driver will
>   attempt to auto-detect (like the board file did) and match to
>   a corresponding panel in the device tree.
> 
> - Defining all auto-detectable panels in the device tree for the
>   versatile-ab, defaulting the first one to VGA. The right
>   panel will be selected at panel initialization, and should
>   just work for the IB1 daughterboard panels, like EPSON.
> 
> - Creating a special superset DTS file for the IB2 daughterboard
>   (phone form-factor) equipped Versatile, overriding the default VGA
>   display with the Sanyo 2.5" portrait display definitions, so that
>   the IB2-equipped Versatile can be used with this. This follows
>   the pattern of how we define the Versatile PB as a superset of
>   Versatile AB.
> 
> Tested on Versatile AB with just VGA with the default device tree,
> and with the IB2 daughterboard with the custom IB2 device tree.
> Tested to shunt in XVGA by modifying the device tree and this works
> too. Also tested on QEMU for Versatile in both VGA and Sanyo 2.5"
> mode. I don't have the IB1 daughterboard and its add-on displays,
> but it should work as long as the detection mechanism and device
> tree parameters are sound.

Well... I don't like this very much. The .dts should contain
descriptions for hardware that is connected. Have you looked at DT
overlays? I think they would be a much better match for this.

What's the SYS_CLCD register? An EEPROM or such, programmed when the
board is manufactured? Is the panel meant to be switchable by the user,
possibly to a panel that's not "standard"?

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/1978c9c1/attachment.sig>

From tomi.valkeinen at ti.com  Wed Feb 17 01:11:18 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Wed, 17 Feb 2016 11:11:18 +0200
Subject: [PATCH 07/11] Documentation/DT: add Versatile display bindings
In-Reply-To: <1454594660-7532-8-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-8-git-send-email-linus.walleij@linaro.org>
Message-ID: <56C43936.2060808@ti.com>



On 04/02/16 16:04, Linus Walleij wrote:
> This adds bindings for the LCD displays that can be found connected
> to the ARM Versatile reference design, interface boards IB1 and
> IB2.
> 
> Cc: Pawel Moll <pawel.moll at arm.com>
> Cc: Rob Herring <robh at kernel.org>
> Cc: Russell King <linux at arm.linux.org.uk>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
>  .../devicetree/bindings/display/panel/epson,l2f50113t00.txt        | 7 +++++++
>  .../devicetree/bindings/display/panel/sanyo,alr252rgt.txt          | 7 +++++++
>  .../devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt       | 7 +++++++
>  .../devicetree/bindings/display/panel/sharp,lq084v1dg21.txt        | 7 +++++++
>  Documentation/devicetree/bindings/vendor-prefixes.txt              | 1 +
>  5 files changed, 29 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
>  create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,alr252rgt.txt
>  create mode 100644 Documentation/devicetree/bindings/display/panel/sanyo,tm38qv67a02a.txt
>  create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,lq084v1dg21.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt b/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
> new file mode 100644
> index 000000000000..58eca804dbe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/epson,l2f50113t00.txt
> @@ -0,0 +1,7 @@
> +Epson Mobile display
> +
> +Required properties:
> +- compatible: should be "epson,l2f50113t00"
> +
> +This binding is compatible with the panel-dpi binding, which is specified
> +in panel-dpi.txt in this directory.

Do we really want to add new binding doc files for all panels, even if
they just point to a more generic binding? We may end up with quite a
lot of these, each only saying "look at the panel-dpi.txt".

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/39cfbc9c/attachment-0001.sig>

From aryabinin at virtuozzo.com  Wed Feb 17 01:15:15 2016
From: aryabinin at virtuozzo.com (Andrey Ryabinin)
Date: Wed, 17 Feb 2016 12:15:15 +0300
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <20160216164245.GC8022@leverpostej>
References: <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com>
 <CAKv+Gu8WE=fTZF0Pou24FKDocgshWu8dJRbaC5SJ11E-6T=2Hw@mail.gmail.com>
 <56C34204.60605@virtuozzo.com> <20160216164245.GC8022@leverpostej>
Message-ID: <56C43A23.1020301@virtuozzo.com>

On 02/16/2016 07:42 PM, Mark Rutland wrote:
> On Tue, Feb 16, 2016 at 06:36:36PM +0300, Andrey Ryabinin wrote:
>>
>> On 02/16/2016 06:17 PM, Ard Biesheuvel wrote:
>>> On 16 February 2016 at 13:59, Andrey Ryabinin <aryabinin at virtuozzo.com> wrote:
>>>> +static void verify_shadow(void)
>>>> +{
>>>> +       struct memblock_region *reg;
>>>> +       int i = 0;
>>>> +
>>>> +       for_each_memblock(memory, reg) {
>>>> +               void *start = (void *)__phys_to_virt(reg->base);
>>>> +               void *end = (void *)__phys_to_virt(reg->base + reg->size);
>>>> +               int *shadow_start, *shadow_end;
>>>> +
>>>> +               if (start >= end)
>>>> +                       break;
>>>> +               shadow_start = (int *)((unsigned long)kasan_mem_to_shadow(start) & ~(PAGE_SIZE - 1));
>>>> +               shadow_end =  (int *)kasan_mem_to_shadow(end);
>>>
>>> shadow_start and shadow_end can refer to the same page as in the
>>> previous iteration. For instance, I have these two regions
>>>
>>>   0x00006e090000-0x00006e0adfff [Conventional Memory|   |  |  |  |  |
>>> |   |WB|WT|WC|UC]
>>>   0x00006e0ae000-0x00006e0affff [Loader Data        |   |  |  |  |  |
>>> |   |WB|WT|WC|UC]
>>>
>>> which are covered by different memblocks since the second one is
>>> marked as MEMBLOCK_NOMAP, due to the fact that it contains the UEFI
>>> memory map.
>>>
>>> I get the following output
>>>
>>> kasan: screwed shadow mapping 23575, 23573
>>>
>>> which I think is simply a result from the fact the shadow_start refers
>>> to the same page as in the previous iteration(s)
>>>
>>
>> You are right. 
>> So we should write 'shadow_start' instead of 'i'.
> 
> FWIW with the below patch I don't see any "screwed shadow mapping"
> warnings on my board, and still later see a tonne of KASAN splats in the
> scheduler.
> 

It is possible that I missed something, but I think it means that shadow is alright.

I wonder whether this happens on 4.4. If not, than something in 4.5-rc1 caused this, and the obvious suspect
here is irq stack.


From christoffer.dall at linaro.org  Wed Feb 17 01:15:14 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 17 Feb 2016 10:15:14 +0100
Subject: [PATCH] KVM: arm/arm64: vgic: ensure bitmaps are long enough
In-Reply-To: <56C33C1A.3090703@arm.com>
References: <1455634051-1860-1-git-send-email-mark.rutland@arm.com>
 <56C33C1A.3090703@arm.com>
Message-ID: <20160217091514.GA6696@cbox>

On Tue, Feb 16, 2016 at 03:11:22PM +0000, Marc Zyngier wrote:
> On 16/02/16 14:47, Mark Rutland wrote:
> > When we allocate bitmaps in vgic_vcpu_init_maps, we divide the number of
> > bits we need by 8 to figure out how many bytes to allocate. However,
> > bitmap elements are always accessed as unsigned longs, and if we didn't
> > happen to allocate a size such that size % sizeof(unsigned long) == 0,
> > bitmap accesses may go past the end of the allocation.
> > 
> > When using KASAN (which does byte-granular access checks), this results
> > in a continuous stream of BUGs whenever these bitmaps are accessed:
> > 
> > =============================================================================
> > BUG kmalloc-128 (Tainted: G    B          ): kasan: bad access detected
> > -----------------------------------------------------------------------------
> > 
> > INFO: Allocated in vgic_init.part.25+0x55c/0x990 age=7493 cpu=3 pid=1730
> > INFO: Slab 0xffffffbde6d5da40 objects=16 used=15 fp=0xffffffc935769700 flags=0x4000000000000080
> > INFO: Object 0xffffffc935769500 @offset=1280 fp=0x          (null)
> > 
> > Bytes b4 ffffffc9357694f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > Object ffffffc935769500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > Object ffffffc935769510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > Object ffffffc935769520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > Object ffffffc935769530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > Object ffffffc935769540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > Object ffffffc935769550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > Object ffffffc935769560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > Object ffffffc935769570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > Padding ffffffc9357695b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > Padding ffffffc9357695c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > Padding ffffffc9357695d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > Padding ffffffc9357695e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > Padding ffffffc9357695f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > CPU: 3 PID: 1740 Comm: kvm-vcpu-0 Tainted: G    B           4.4.0+ #17
> > Hardware name: ARM Juno development board (r1) (DT)
> > Call trace:
> > [<ffffffc00008e770>] dump_backtrace+0x0/0x280
> > [<ffffffc00008ea04>] show_stack+0x14/0x20
> > [<ffffffc000726360>] dump_stack+0x100/0x188
> > [<ffffffc00030d324>] print_trailer+0xfc/0x168
> > [<ffffffc000312294>] object_err+0x3c/0x50
> > [<ffffffc0003140fc>] kasan_report_error+0x244/0x558
> > [<ffffffc000314548>] __asan_report_load8_noabort+0x48/0x50
> > [<ffffffc000745688>] __bitmap_or+0xc0/0xc8
> > [<ffffffc0000d9e44>] kvm_vgic_flush_hwstate+0x1bc/0x650
> > [<ffffffc0000c514c>] kvm_arch_vcpu_ioctl_run+0x2ec/0xa60
> > [<ffffffc0000b9a6c>] kvm_vcpu_ioctl+0x474/0xa68
> > [<ffffffc00036b7b0>] do_vfs_ioctl+0x5b8/0xcb0
> > [<ffffffc00036bf34>] SyS_ioctl+0x8c/0xa0
> > [<ffffffc000086cb0>] el0_svc_naked+0x24/0x28
> > Memory state around the buggy address:
> >  ffffffc935769400: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >  ffffffc935769480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >> ffffffc935769500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >                    ^
> >  ffffffc935769580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >  ffffffc935769600: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
> > ==================================================================
> > 
> > Fix the issue by always allocating a multiple of sizeof(unsigned long),
> > as we do elsewhere in the vgic code.
> > 
> > Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> > Cc: Marc Zyngier <marc.zyngier at arm.com>
> > Cc: Christoffer Dall <christoffer.dall at linaro.org>
> > ---
> >  virt/kvm/arm/vgic.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> > index 7a2f449..5d10f10 100644
> > --- a/virt/kvm/arm/vgic.c
> > +++ b/virt/kvm/arm/vgic.c
> > @@ -1875,8 +1875,8 @@ void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
> >  static int vgic_vcpu_init_maps(struct kvm_vcpu *vcpu, int nr_irqs)
> >  {
> >  	struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
> > -
> > -	int sz = (nr_irqs - VGIC_NR_PRIVATE_IRQS) / 8;
> > +	int nr_longs = BITS_TO_LONGS(nr_irqs - VGIC_NR_PRIVATE_IRQS);
> > +	int sz = nr_longs * sizeof(unsigned long);
> >  	vgic_cpu->pending_shared = kzalloc(sz, GFP_KERNEL);
> >  	vgic_cpu->active_shared = kzalloc(sz, GFP_KERNEL);
> >  	vgic_cpu->pend_act_shared = kzalloc(sz, GFP_KERNEL);
> > 
> 
> Acked-by: Marc Zyngier <marc.zyngier at arm.com>
> 
> Worth mentioning:
> 
> Fixes: c1bfb577a ("arm/arm64: KVM: vgic: switch to dynamic allocation")
> Cc: stable at vger.kernel.org
> 
Thanks for this fix:

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>


From christoffer.dall at linaro.org  Wed Feb 17 01:15:49 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 17 Feb 2016 10:15:49 +0100
Subject: [PATCH 0/8] KVM/ARM: Guest Entry/Exit optimizations
In-Reply-To: <56C38109.3020501@arm.com>
References: <1454931622-14902-1-git-send-email-marc.zyngier@arm.com>
 <20160210204012.GS5171@cbox> <56C38109.3020501@arm.com>
Message-ID: <20160217091549.GB6696@cbox>

On Tue, Feb 16, 2016 at 08:05:29PM +0000, Marc Zyngier wrote:
> On 10/02/16 20:40, Christoffer Dall wrote:
> > On Mon, Feb 08, 2016 at 11:40:14AM +0000, Marc Zyngier wrote:
> >> I've recently been looking at our entry/exit costs, and profiling
> >> figures did show some very low hanging fruits.
> >>
> >> The most obvious cost is that accessing the GIC HW is slow. As in
> >> "deadly slow", specially when GICv2 is involved. So not hammering the
> >> HW when there is nothing to write is immediately beneficial, as this
> >> is the most common cases (whatever people seem to think, interrupts
> >> are a *rare* event).
> >>
> >> Another easy thing to fix is the way we handle trapped system
> >> registers. We do insist on (mostly) sorting them, but we do perform a
> >> linear search on trap. We can switch to a binary search for free, and
> >> get immediate benefits (the PMU code, being extremely trap-happy,
> >> benefits immediately from this).
> >>
> >> With these in place, I see an improvement of 20 to 30% (depending on
> >> the platform) on our world-switch cycle count when running a set of
> >> hand-crafted guests that are designed to only perform traps.
> >>
> > 
> > By the way, I took this whole stack of changes (wsinc, vhe, and
> > optimizations) and ran it on Mustang and fired up UEFI and did a reboot
> > and things seem to work, so that's a small shallow
> > 'tested-by-something-else-than-a-linux-guest' statement from me.
> 
> I've ran a slightly heavier set of tests, and the infamous reboot loop
> broke, thanks to patch #7.
> 
> Notice how we fail to wipe the vgic_apr copy on the "light" exit path?
> If you're unlucky (and odds are that you will be), you will inject an
> interrupt while its active priority bit is set, and the new interrupt
> won't be delivered. Bah.
> 
> With that fixed, the reboot loop has been going strong for a few hours.
> I'll leave my Seattle cooking overnight and if everything looks good in
> the morning, I'll repost a new set of patches.
> 
Good that you caught this one then!

-Christoffer


From tiffany.lin at mediatek.com  Wed Feb 17 01:23:09 2016
From: tiffany.lin at mediatek.com (tiffany lin)
Date: Wed, 17 Feb 2016 17:23:09 +0800
Subject: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2
 Video Encoder Driver
In-Reply-To: <56C42FE3.8000105@xs4all.nl>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
 <56C1B4AF.1030207@xs4all.nl> <1455604653.19396.68.camel@mtksdaap41>
 <56C2D371.9090805@xs4all.nl> <1455628805.19396.82.camel@mtksdaap41>
 <56C328AF.5030604@cisco.com> <1455696068.26202.4.camel@mtksdaap41>
 <56C42FE3.8000105@xs4all.nl>
Message-ID: <1455700989.3782.7.camel@mtksdaap41>

On Wed, 2016-02-17 at 09:31 +0100, Hans Verkuil wrote:
> On 02/17/16 09:01, tiffany lin wrote:
> > On Tue, 2016-02-16 at 14:48 +0100, Hans Verkuil wrote:
> >> Hi Tiffany,
> >>
> >>>>>>> +int mtk_vcodec_enc_queue_init(void *priv, struct vb2_queue *src_vq,
> >>>>>>> +			   struct vb2_queue *dst_vq)
> >>>>>>> +{
> >>>>>>> +	struct mtk_vcodec_ctx *ctx = priv;
> >>>>>>> +	int ret;
> >>>>>>> +
> >>>>>>> +	src_vq->type		= V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
> >>>>>>> +	src_vq->io_modes	= VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
> >>>>>>
> >>>>>> I recomment dropping VB2_USERPTR. That only makes sense for scatter-gather dma,
> >>>>>> and you use physically contiguous DMA.
> >>>>>>
> >>>>> Now our userspace app use VB2_USERPTR. I need to check if we could drop
> >>>>> VB2_USERPTR.
> >>>>> We use src_vq->mem_ops = &vb2_dma_contig_memops;
> >>>>> And there are
> >>>>> 	.get_userptr	= vb2_dc_get_userptr,
> >>>>> 	.put_userptr	= vb2_dc_put_userptr,
> >>>>> I was confused why it only make sense for scatter-gather.
> >>>>> Could you kindly explain more?
> >>>>
> >>>> VB2_USERPTR indicates that the application can use malloc to allocate buffers
> >>>> and pass those to the driver. Since malloc uses virtual memory the physical
> >>>> memory is scattered all over. And the first page typically does not start at
> >>>> the beginning of the page but at a random offset.
> >>>>
> >>>> To support that the DMA generally has to be able to do scatter-gather.
> >>>>
> >>>> Now, where things get ugly is that a hack was added to the USERPTR support where
> >>>> apps could pass a pointer to physically contiguous memory as a user pointer. This
> >>>> was a hack for embedded systems that preallocated a pool of buffers and needed to
> >>>> pass those pointers around somehow. So the dma-contig USERPTR support is for that
> >>>> 'feature'. If you try to pass a malloc()ed buffer to a dma-contig driver it will
> >>>> reject it. One big problem is that this specific hack isn't signaled anywhere, so
> >>>> applications have no way of knowing if the USERPTR support is the proper version
> >>>> or the hack where physically contiguous memory is expected.
> >>>>
> >>>> This hack has been replaced with DMABUF which is the proper way of passing buffers
> >>>> around.
> >>>>
> >>>> New dma-contig drivers should not use that old hack anymore. Use dmabuf to pass
> >>>> external buffers around.
> >>>>
> >>>> How do you use it in your app? With malloc()ed buffers? Or with 'special' pointers
> >>>> to physically contiguous buffers?
> >>>>
> >>> Understood now. Thanks for your explanation.
> >>> Now our app use malloc()ed buffers and we hook vb2_dma_contig_memops. 
> >>> I don't know why that dma-contig driver do not reject it.
> >>> I will try to figure it out.
> >>
> >> Is there an iommu involved that turns the scatter-gather list into what looks like
> >> contiguous memory for the DMA?
> >>
> > Yes, We have iommu that could make scatter-gather list looks like
> > contiguous memory.
> > 
> >> At the end of vb2_dc_get_userptr() in videobuf2-dma-contig.c there is a check
> >> 'if (contig_size < size)' that verifies that the sg DMA is contiguous. This would
> >> work if there is an iommu involved (if I understand it correctly).
> >>
> > I see. We saw this error before we add iommu support.
> > 
> >> If that's the case, then it's OK to keep VB2_USERPTR because you have real sg
> >> support (although not via the DMA engine, but via iommu mappings).
> >>
> > Got it. We will keep VB2_USERPTR.
> 
> Can you add a comment here mentioning that VB2_USERPTR works with dma-contig because
> there is an iommu? That should clarify this.
> 
Got it. I will add comment before this line.
src_vq->io_modes = VB2_DMABUF | VB2_MMAP | VB2_USERPTR;.

I will also add out IOMMU patches information in cover letter, like:
The following patches are needed to support VB2_USERPTR works with
dma-contig.
https://patchwork.kernel.org/patch/8335461/
https://patchwork.kernel.org/patch/8335471/
https://patchwork.kernel.org/patch/8335481/
https://patchwork.kernel.org/patch/8335491/
https://patchwork.kernel.org/patch/8335501/
https://patchwork.kernel.org/patch/7596181/


best regards,
Tiffany



> Regards,
> 
> 	Hans




From lkp at intel.com  Wed Feb 17 01:24:16 2016
From: lkp at intel.com (kbuild test robot)
Date: Wed, 17 Feb 2016 17:24:16 +0800
Subject: [PATCH] ALSA: jack: Allow building the jack layer without input
In-Reply-To: <s5h8u2j6749.wl-tiwai@suse.de>
Message-ID: <201602171732.VPVdhvvI%fengguang.wu@intel.com>

Hi Takashi,

[auto build test ERROR on sound/for-next]
[also build test ERROR on v4.5-rc4 next-20160217]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Takashi-Iwai/ALSA-jack-Allow-building-the-jack-layer-without-input/20160217-171209
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-next
config: x86_64-randconfig-x012-201607 (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> sound/core/jack.c:184:5: error: redefinition of 'snd_jack_add_new_kctl'
    int snd_jack_add_new_kctl(struct snd_jack *jack, const char * name, int mask)
        ^
   In file included from sound/core/jack.c:25:0:
   include/sound/jack.h:108:19: note: previous definition of 'snd_jack_add_new_kctl' was here
    static inline int snd_jack_add_new_kctl(struct snd_jack *jack, const char * name, int mask)
                      ^
>> sound/core/jack.c:212:5: error: redefinition of 'snd_jack_new'
    int snd_jack_new(struct snd_card *card, const char *id, int type,
        ^
   In file included from sound/core/jack.c:25:0:
   include/sound/jack.h:102:19: note: previous definition of 'snd_jack_new' was here
    static inline int snd_jack_new(struct snd_card *card, const char *id, int type,
                      ^
>> sound/core/jack.c:296:6: error: redefinition of 'snd_jack_set_parent'
    void snd_jack_set_parent(struct snd_jack *jack, struct device *parent)
         ^
   In file included from sound/core/jack.c:25:0:
   include/sound/jack.h:120:20: note: previous definition of 'snd_jack_set_parent' was here
    static inline void snd_jack_set_parent(struct snd_jack *jack,
                       ^
>> sound/core/jack.c:331:5: error: redefinition of 'snd_jack_set_key'
    int snd_jack_set_key(struct snd_jack *jack, enum snd_jack_types type,
        ^
   In file included from sound/core/jack.c:25:0:
   include/sound/jack.h:125:19: note: previous definition of 'snd_jack_set_key' was here
    static inline int snd_jack_set_key(struct snd_jack *jack,
                      ^
>> sound/core/jack.c:354:6: error: redefinition of 'snd_jack_report'
    void snd_jack_report(struct snd_jack *jack, int status)
         ^
   In file included from sound/core/jack.c:25:0:
   include/sound/jack.h:113:20: note: previous definition of 'snd_jack_report' was here
    static inline void snd_jack_report(struct snd_jack *jack, int status)
                       ^

vim +/snd_jack_add_new_kctl +184 sound/core/jack.c

9058cbe1e Jie Yang         2015-04-27  178   *         by this snd_jack_kctl object.
9058cbe1e Jie Yang         2015-04-27  179   *
9058cbe1e Jie Yang         2015-04-27  180   * Creates a new snd_kcontrol object and adds it to the jack kctl_list.
9058cbe1e Jie Yang         2015-04-27  181   *
9058cbe1e Jie Yang         2015-04-27  182   * Return: Zero if successful, or a negative error code on failure.
9058cbe1e Jie Yang         2015-04-27  183   */
9058cbe1e Jie Yang         2015-04-27 @184  int snd_jack_add_new_kctl(struct snd_jack *jack, const char * name, int mask)
9058cbe1e Jie Yang         2015-04-27  185  {
9058cbe1e Jie Yang         2015-04-27  186  	struct snd_jack_kctl *jack_kctl;
9058cbe1e Jie Yang         2015-04-27  187  
9058cbe1e Jie Yang         2015-04-27  188  	jack_kctl = snd_jack_kctl_new(jack->card, name, mask);
9058cbe1e Jie Yang         2015-04-27  189  	if (!jack_kctl)
9058cbe1e Jie Yang         2015-04-27  190  		return -ENOMEM;
9058cbe1e Jie Yang         2015-04-27  191  
9058cbe1e Jie Yang         2015-04-27  192  	snd_jack_kctl_add(jack, jack_kctl);
9058cbe1e Jie Yang         2015-04-27  193  	return 0;
9058cbe1e Jie Yang         2015-04-27  194  }
9058cbe1e Jie Yang         2015-04-27  195  EXPORT_SYMBOL(snd_jack_add_new_kctl);
9058cbe1e Jie Yang         2015-04-27  196  
e76d8ceaa Mark Brown       2008-07-28  197  /**
e76d8ceaa Mark Brown       2008-07-28  198   * snd_jack_new - Create a new jack
e76d8ceaa Mark Brown       2008-07-28  199   * @card:  the card instance
e76d8ceaa Mark Brown       2008-07-28  200   * @id:    an identifying string for this jack
e76d8ceaa Mark Brown       2008-07-28  201   * @type:  a bitmask of enum snd_jack_type values that can be detected by
e76d8ceaa Mark Brown       2008-07-28  202   *         this jack
e76d8ceaa Mark Brown       2008-07-28  203   * @jjack: Used to provide the allocated jack object to the caller.
4e3f0dc65 Jie Yang         2015-04-27  204   * @initial_kctl: if true, create a kcontrol and add it to the jack list.
4e3f0dc65 Jie Yang         2015-04-27  205   * @phantom_jack: Don't create a input device for phantom jacks.
e76d8ceaa Mark Brown       2008-07-28  206   *
e76d8ceaa Mark Brown       2008-07-28  207   * Creates a new jack object.
e76d8ceaa Mark Brown       2008-07-28  208   *
eb7c06e8e Yacine Belkadi   2013-03-11  209   * Return: Zero if successful, or a negative error code on failure.
eb7c06e8e Yacine Belkadi   2013-03-11  210   * On success @jjack will be initialised.
e76d8ceaa Mark Brown       2008-07-28  211   */
e76d8ceaa Mark Brown       2008-07-28 @212  int snd_jack_new(struct snd_card *card, const char *id, int type,
4e3f0dc65 Jie Yang         2015-04-27  213  		 struct snd_jack **jjack, bool initial_kctl, bool phantom_jack)
e76d8ceaa Mark Brown       2008-07-28  214  {
e76d8ceaa Mark Brown       2008-07-28  215  	struct snd_jack *jack;
4e3f0dc65 Jie Yang         2015-04-27  216  	struct snd_jack_kctl *jack_kctl = NULL;
e76d8ceaa Mark Brown       2008-07-28  217  	int err;
e76d8ceaa Mark Brown       2008-07-28  218  	static struct snd_device_ops ops = {
e76d8ceaa Mark Brown       2008-07-28  219  		.dev_free = snd_jack_dev_free,
dbe821f46 Takashi Iwai     2016-02-17  220  #ifdef CONFIG_SND_JACK_INPUT_DEV
e76d8ceaa Mark Brown       2008-07-28  221  		.dev_register = snd_jack_dev_register,
32b854429 Takashi Iwai     2013-11-14  222  		.dev_disconnect = snd_jack_dev_disconnect,
dbe821f46 Takashi Iwai     2016-02-17  223  #endif /* CONFIG_SND_JACK_INPUT_DEV */
e76d8ceaa Mark Brown       2008-07-28  224  	};
e76d8ceaa Mark Brown       2008-07-28  225  
4e3f0dc65 Jie Yang         2015-04-27  226  	if (initial_kctl) {
4e3f0dc65 Jie Yang         2015-04-27  227  		jack_kctl = snd_jack_kctl_new(card, id, type);
4e3f0dc65 Jie Yang         2015-04-27  228  		if (!jack_kctl)
4e3f0dc65 Jie Yang         2015-04-27  229  			return -ENOMEM;
4e3f0dc65 Jie Yang         2015-04-27  230  	}
4e3f0dc65 Jie Yang         2015-04-27  231  
e76d8ceaa Mark Brown       2008-07-28  232  	jack = kzalloc(sizeof(struct snd_jack), GFP_KERNEL);
e76d8ceaa Mark Brown       2008-07-28  233  	if (jack == NULL)
e76d8ceaa Mark Brown       2008-07-28  234  		return -ENOMEM;
e76d8ceaa Mark Brown       2008-07-28  235  
282cd76ff Matthew Ranostay 2008-10-25  236  	jack->id = kstrdup(id, GFP_KERNEL);
e76d8ceaa Mark Brown       2008-07-28  237  
4e3f0dc65 Jie Yang         2015-04-27  238  	/* don't creat input device for phantom jack */
4e3f0dc65 Jie Yang         2015-04-27  239  	if (!phantom_jack) {
dbe821f46 Takashi Iwai     2016-02-17  240  #ifdef CONFIG_SND_JACK_INPUT_DEV
dbe821f46 Takashi Iwai     2016-02-17  241  		int i;
dbe821f46 Takashi Iwai     2016-02-17  242  
e76d8ceaa Mark Brown       2008-07-28  243  		jack->input_dev = input_allocate_device();
e76d8ceaa Mark Brown       2008-07-28  244  		if (jack->input_dev == NULL) {
e76d8ceaa Mark Brown       2008-07-28  245  			err = -ENOMEM;
e76d8ceaa Mark Brown       2008-07-28  246  			goto fail_input;
e76d8ceaa Mark Brown       2008-07-28  247  		}
e76d8ceaa Mark Brown       2008-07-28  248  
e76d8ceaa Mark Brown       2008-07-28  249  		jack->input_dev->phys = "ALSA";
e76d8ceaa Mark Brown       2008-07-28  250  
e76d8ceaa Mark Brown       2008-07-28  251  		jack->type = type;
e76d8ceaa Mark Brown       2008-07-28  252  
53803aead Mark Brown       2012-02-07  253  		for (i = 0; i < SND_JACK_SWITCH_TYPES; i++)
bd8a71a7b Mark Brown       2009-01-03  254  			if (type & (1 << i))
e76d8ceaa Mark Brown       2008-07-28  255  				input_set_capability(jack->input_dev, EV_SW,
1c6e555c3 Mark Brown       2010-03-17  256  						     jack_switch_types[i]);
e76d8ceaa Mark Brown       2008-07-28  257  
dbe821f46 Takashi Iwai     2016-02-17  258  #endif /* CONFIG_SND_JACK_INPUT_DEV */
4e3f0dc65 Jie Yang         2015-04-27  259  	}
4e3f0dc65 Jie Yang         2015-04-27  260  
e76d8ceaa Mark Brown       2008-07-28  261  	err = snd_device_new(card, SNDRV_DEV_JACK, jack, &ops);
e76d8ceaa Mark Brown       2008-07-28  262  	if (err < 0)
e76d8ceaa Mark Brown       2008-07-28  263  		goto fail_input;
e76d8ceaa Mark Brown       2008-07-28  264  
9058cbe1e Jie Yang         2015-04-27  265  	jack->card = card;
9058cbe1e Jie Yang         2015-04-27  266  	INIT_LIST_HEAD(&jack->kctl_list);
9058cbe1e Jie Yang         2015-04-27  267  
4e3f0dc65 Jie Yang         2015-04-27  268  	if (initial_kctl)
4e3f0dc65 Jie Yang         2015-04-27  269  		snd_jack_kctl_add(jack, jack_kctl);
4e3f0dc65 Jie Yang         2015-04-27  270  
e76d8ceaa Mark Brown       2008-07-28  271  	*jjack = jack;
e76d8ceaa Mark Brown       2008-07-28  272  
e76d8ceaa Mark Brown       2008-07-28  273  	return 0;
e76d8ceaa Mark Brown       2008-07-28  274  
e76d8ceaa Mark Brown       2008-07-28  275  fail_input:
dbe821f46 Takashi Iwai     2016-02-17  276  #ifdef CONFIG_SND_JACK_INPUT_DEV
e76d8ceaa Mark Brown       2008-07-28  277  	input_free_device(jack->input_dev);
dbe821f46 Takashi Iwai     2016-02-17  278  #endif
eeda276be Lu Guanqun       2011-02-21  279  	kfree(jack->id);
e76d8ceaa Mark Brown       2008-07-28  280  	kfree(jack);
e76d8ceaa Mark Brown       2008-07-28  281  	return err;
e76d8ceaa Mark Brown       2008-07-28  282  }
e76d8ceaa Mark Brown       2008-07-28  283  EXPORT_SYMBOL(snd_jack_new);
e76d8ceaa Mark Brown       2008-07-28  284  
dbe821f46 Takashi Iwai     2016-02-17  285  #ifdef CONFIG_SND_JACK_INPUT_DEV
e76d8ceaa Mark Brown       2008-07-28  286  /**
e76d8ceaa Mark Brown       2008-07-28  287   * snd_jack_set_parent - Set the parent device for a jack
e76d8ceaa Mark Brown       2008-07-28  288   *
e76d8ceaa Mark Brown       2008-07-28  289   * @jack:   The jack to configure
e76d8ceaa Mark Brown       2008-07-28  290   * @parent: The device to set as parent for the jack.
e76d8ceaa Mark Brown       2008-07-28  291   *
a2e888f0d Mark Brown       2012-05-07  292   * Set the parent for the jack devices in the device tree.  This
e76d8ceaa Mark Brown       2008-07-28  293   * function is only valid prior to registration of the jack.  If no
e76d8ceaa Mark Brown       2008-07-28  294   * parent is configured then the parent device will be the sound card.
e76d8ceaa Mark Brown       2008-07-28  295   */
e76d8ceaa Mark Brown       2008-07-28 @296  void snd_jack_set_parent(struct snd_jack *jack, struct device *parent)
e76d8ceaa Mark Brown       2008-07-28  297  {
e76d8ceaa Mark Brown       2008-07-28  298  	WARN_ON(jack->registered);
43b2cd547 Takashi Iwai     2015-04-30  299  	if (!jack->input_dev)
43b2cd547 Takashi Iwai     2015-04-30  300  		return;
e76d8ceaa Mark Brown       2008-07-28  301  
e76d8ceaa Mark Brown       2008-07-28  302  	jack->input_dev->dev.parent = parent;
e76d8ceaa Mark Brown       2008-07-28  303  }
e76d8ceaa Mark Brown       2008-07-28  304  EXPORT_SYMBOL(snd_jack_set_parent);
e76d8ceaa Mark Brown       2008-07-28  305  
e76d8ceaa Mark Brown       2008-07-28  306  /**
ebb812cb8 Mark Brown       2010-03-17  307   * snd_jack_set_key - Set a key mapping on a jack
ebb812cb8 Mark Brown       2010-03-17  308   *
ebb812cb8 Mark Brown       2010-03-17  309   * @jack:    The jack to configure
ebb812cb8 Mark Brown       2010-03-17  310   * @type:    Jack report type for this key
ebb812cb8 Mark Brown       2010-03-17  311   * @keytype: Input layer key type to be reported
ebb812cb8 Mark Brown       2010-03-17  312   *
ebb812cb8 Mark Brown       2010-03-17  313   * Map a SND_JACK_BTN_ button type to an input layer key, allowing
ebb812cb8 Mark Brown       2010-03-17  314   * reporting of keys on accessories via the jack abstraction.  If no
ebb812cb8 Mark Brown       2010-03-17  315   * mapping is provided but keys are enabled in the jack type then
ebb812cb8 Mark Brown       2010-03-17  316   * BTN_n numeric buttons will be reported.
ebb812cb8 Mark Brown       2010-03-17  317   *
a2e888f0d Mark Brown       2012-05-07  318   * If jacks are not reporting via the input API this call will have no
a2e888f0d Mark Brown       2012-05-07  319   * effect.
a2e888f0d Mark Brown       2012-05-07  320   *
ebb812cb8 Mark Brown       2010-03-17  321   * Note that this is intended to be use by simple devices with small
ebb812cb8 Mark Brown       2010-03-17  322   * numbers of keys that can be reported.  It is also possible to
ebb812cb8 Mark Brown       2010-03-17  323   * access the input device directly - devices with complex input
ebb812cb8 Mark Brown       2010-03-17  324   * capabilities on accessories should consider doing this rather than
ebb812cb8 Mark Brown       2010-03-17  325   * using this abstraction.
ebb812cb8 Mark Brown       2010-03-17  326   *
ebb812cb8 Mark Brown       2010-03-17  327   * This function may only be called prior to registration of the jack.
eb7c06e8e Yacine Belkadi   2013-03-11  328   *
eb7c06e8e Yacine Belkadi   2013-03-11  329   * Return: Zero if successful, or a negative error code on failure.
ebb812cb8 Mark Brown       2010-03-17  330   */
ebb812cb8 Mark Brown       2010-03-17 @331  int snd_jack_set_key(struct snd_jack *jack, enum snd_jack_types type,
ebb812cb8 Mark Brown       2010-03-17  332  		     int keytype)
ebb812cb8 Mark Brown       2010-03-17  333  {
ebb812cb8 Mark Brown       2010-03-17  334  	int key = fls(SND_JACK_BTN_0) - fls(type);
ebb812cb8 Mark Brown       2010-03-17  335  
ebb812cb8 Mark Brown       2010-03-17  336  	WARN_ON(jack->registered);
ebb812cb8 Mark Brown       2010-03-17  337  
ebb812cb8 Mark Brown       2010-03-17  338  	if (!keytype || key >= ARRAY_SIZE(jack->key))
ebb812cb8 Mark Brown       2010-03-17  339  		return -EINVAL;
ebb812cb8 Mark Brown       2010-03-17  340  
ebb812cb8 Mark Brown       2010-03-17  341  	jack->type |= type;
ebb812cb8 Mark Brown       2010-03-17  342  	jack->key[key] = keytype;
ebb812cb8 Mark Brown       2010-03-17  343  	return 0;
ebb812cb8 Mark Brown       2010-03-17  344  }
ebb812cb8 Mark Brown       2010-03-17  345  EXPORT_SYMBOL(snd_jack_set_key);
dbe821f46 Takashi Iwai     2016-02-17  346  #endif /* CONFIG_SND_JACK_INPUT_DEV */
ebb812cb8 Mark Brown       2010-03-17  347  
ebb812cb8 Mark Brown       2010-03-17  348  /**
e76d8ceaa Mark Brown       2008-07-28  349   * snd_jack_report - Report the current status of a jack
e76d8ceaa Mark Brown       2008-07-28  350   *
e76d8ceaa Mark Brown       2008-07-28  351   * @jack:   The jack to report status for
e76d8ceaa Mark Brown       2008-07-28  352   * @status: The current status of the jack
e76d8ceaa Mark Brown       2008-07-28  353   */
e76d8ceaa Mark Brown       2008-07-28 @354  void snd_jack_report(struct snd_jack *jack, int status)
e76d8ceaa Mark Brown       2008-07-28  355  {
9058cbe1e Jie Yang         2015-04-27  356  	struct snd_jack_kctl *jack_kctl;
dbe821f46 Takashi Iwai     2016-02-17  357  #ifdef CONFIG_SND_JACK_INPUT_DEV

:::::: The code at line 184 was first introduced by commit
:::::: 9058cbe1eed29381f84dec9f96980f5a4ea1025f ALSA: jack: implement kctl creating for jack devices

:::::: TO: Jie Yang <yang.jie at intel.com>
:::::: CC: Takashi Iwai <tiwai at suse.de>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 27529 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/e0faed33/attachment-0001.obj>

From tiwai at suse.de  Wed Feb 17 01:35:40 2016
From: tiwai at suse.de (Takashi Iwai)
Date: Wed, 17 Feb 2016 10:35:40 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <s5h8u2j6749.wl-tiwai@suse.de>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
 <s5hr3gc60ph.wl-tiwai@suse.de> <2706488.VpKveMVPGI@wuerfel>
 <3395859.dhsfOsmVIe@wuerfel> <s5h8u2j6749.wl-tiwai@suse.de>
Message-ID: <s5h1t8b65n7.wl-tiwai@suse.de>

On Wed, 17 Feb 2016 10:03:50 +0100,
Takashi Iwai wrote:
> --- a/sound/core/Kconfig
> +++ b/sound/core/Kconfig
> @@ -24,11 +24,14 @@ config SND_RAWMIDI
>  config SND_COMPRESS_OFFLOAD
>  	tristate
>  
> -# To be effective this also requires INPUT - users should say:
> -#    select SND_JACK if INPUT=y || INPUT=SND
> -# to avoid having to force INPUT on.
>  config SND_JACK
> +	tristate

Oops, some unintentional change slipped in.  This must be bool.

Below is the revised patch.


Takashi

-- 8< --
From: Takashi Iwai <tiwai at suse.de>
Subject: [PATCH v2] ALSA: jack: Allow building the jack layer without
 input device

Since the recent integration of kctl jack and input jack layers, we
can basically build the jack layer even without input devices.  That
is, the jack layer itself can be built with conditional to enable the
input device support or not, while the users may enable always
CONFIG_SND_JACK unconditionally.

For achieving it, this patch changes the following:
- A new Kconfig, CONFIG_SND_JACK_INPUT_DEV, was introduced to indicate
  whether the jack layer supports the input device,
- A few items in snd_jack struct and relevant codes are conditionally
  built upon CONFIG_SND_JACK_INPUT_DEV,
- The users of CONFIG_SND_JACK drop the messy dependency on
  CONFIG_INPUT.

This change also automagically fixes a potential bug in HD-audio
driver Arnd reported, where the NULL or uninitialized jack instance is
dereferenced.

Reported-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Takashi Iwai <tiwai at suse.de>
---
 include/sound/jack.h  | 23 ++++++++++++++---------
 sound/core/Kconfig    |  9 ++++++---
 sound/core/jack.c     | 23 ++++++++++++++++++++---
 sound/pci/Kconfig     |  2 +-
 sound/pci/hda/Kconfig |  2 +-
 sound/soc/Kconfig     |  2 +-
 6 files changed, 43 insertions(+), 18 deletions(-)

diff --git a/include/sound/jack.h b/include/sound/jack.h
index 23bede121c78..1e84bfb553cf 100644
--- a/include/sound/jack.h
+++ b/include/sound/jack.h
@@ -72,14 +72,16 @@ enum snd_jack_types {
 #define SND_JACK_SWITCH_TYPES 6
 
 struct snd_jack {
-	struct input_dev *input_dev;
 	struct list_head kctl_list;
 	struct snd_card *card;
+	const char *id;
+#ifdef CONFIG_SND_JACK_INPUT_DEV
+	struct input_dev *input_dev;
 	int registered;
 	int type;
-	const char *id;
 	char name[100];
 	unsigned int key[6];   /* Keep in sync with definitions above */
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 	void *private_data;
 	void (*private_free)(struct snd_jack *);
 };
@@ -89,10 +91,11 @@ struct snd_jack {
 int snd_jack_new(struct snd_card *card, const char *id, int type,
 		 struct snd_jack **jack, bool initial_kctl, bool phantom_jack);
 int snd_jack_add_new_kctl(struct snd_jack *jack, const char * name, int mask);
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 void snd_jack_set_parent(struct snd_jack *jack, struct device *parent);
 int snd_jack_set_key(struct snd_jack *jack, enum snd_jack_types type,
 		     int keytype);
-
+#endif
 void snd_jack_report(struct snd_jack *jack, int status);
 
 #else
@@ -107,6 +110,13 @@ static inline int snd_jack_add_new_kctl(struct snd_jack *jack, const char * name
 	return 0;
 }
 
+static inline void snd_jack_report(struct snd_jack *jack, int status)
+{
+}
+
+#endif
+
+#if !defined(CONFIG_SND_JACK) || !defined(CONFIG_SND_JACK_INPUT_DEV)
 static inline void snd_jack_set_parent(struct snd_jack *jack,
 				       struct device *parent)
 {
@@ -118,11 +128,6 @@ static inline int snd_jack_set_key(struct snd_jack *jack,
 {
 	return 0;
 }
-
-static inline void snd_jack_report(struct snd_jack *jack, int status)
-{
-}
-
-#endif
+#endif /* !CONFIG_SND_JACK || !CONFIG_SND_JACK_INPUT_DEV */
 
 #endif
diff --git a/sound/core/Kconfig b/sound/core/Kconfig
index a2a1e24becc6..6d12ca9bcb80 100644
--- a/sound/core/Kconfig
+++ b/sound/core/Kconfig
@@ -24,12 +24,15 @@ config SND_RAWMIDI
 config SND_COMPRESS_OFFLOAD
 	tristate
 
-# To be effective this also requires INPUT - users should say:
-#    select SND_JACK if INPUT=y || INPUT=SND
-# to avoid having to force INPUT on.
 config SND_JACK
 	bool
 
+# enable input device support in jack layer
+config SND_JACK_INPUT_DEV
+	bool
+	depends on SND_JACK
+	default y if INPUT=y || INPUT=SND
+
 config SND_SEQUENCER
 	tristate "Sequencer support"
 	select SND_TIMER
diff --git a/sound/core/jack.c b/sound/core/jack.c
index 7237acbdcbbc..f652e90efd7e 100644
--- a/sound/core/jack.c
+++ b/sound/core/jack.c
@@ -32,6 +32,7 @@ struct snd_jack_kctl {
 	unsigned int mask_bits; /* only masked status bits are reported via kctl */
 };
 
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 static int jack_switch_types[SND_JACK_SWITCH_TYPES] = {
 	SW_HEADPHONE_INSERT,
 	SW_MICROPHONE_INSERT,
@@ -40,9 +41,11 @@ static int jack_switch_types[SND_JACK_SWITCH_TYPES] = {
 	SW_VIDEOOUT_INSERT,
 	SW_LINEIN_INSERT,
 };
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 
 static int snd_jack_dev_disconnect(struct snd_device *device)
 {
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 	struct snd_jack *jack = device->device_data;
 
 	if (!jack->input_dev)
@@ -55,6 +58,7 @@ static int snd_jack_dev_disconnect(struct snd_device *device)
 	else
 		input_free_device(jack->input_dev);
 	jack->input_dev = NULL;
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 	return 0;
 }
 
@@ -79,6 +83,7 @@ static int snd_jack_dev_free(struct snd_device *device)
 	return 0;
 }
 
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 static int snd_jack_dev_register(struct snd_device *device)
 {
 	struct snd_jack *jack = device->device_data;
@@ -116,6 +121,7 @@ static int snd_jack_dev_register(struct snd_device *device)
 
 	return err;
 }
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 
 static void snd_jack_kctl_private_free(struct snd_kcontrol *kctl)
 {
@@ -209,11 +215,12 @@ int snd_jack_new(struct snd_card *card, const char *id, int type,
 	struct snd_jack *jack;
 	struct snd_jack_kctl *jack_kctl = NULL;
 	int err;
-	int i;
 	static struct snd_device_ops ops = {
 		.dev_free = snd_jack_dev_free,
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 		.dev_register = snd_jack_dev_register,
 		.dev_disconnect = snd_jack_dev_disconnect,
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 	};
 
 	if (initial_kctl) {
@@ -230,6 +237,9 @@ int snd_jack_new(struct snd_card *card, const char *id, int type,
 
 	/* don't creat input device for phantom jack */
 	if (!phantom_jack) {
+#ifdef CONFIG_SND_JACK_INPUT_DEV
+		int i;
+
 		jack->input_dev = input_allocate_device();
 		if (jack->input_dev == NULL) {
 			err = -ENOMEM;
@@ -245,6 +255,7 @@ int snd_jack_new(struct snd_card *card, const char *id, int type,
 				input_set_capability(jack->input_dev, EV_SW,
 						     jack_switch_types[i]);
 
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 	}
 
 	err = snd_device_new(card, SNDRV_DEV_JACK, jack, &ops);
@@ -262,13 +273,16 @@ int snd_jack_new(struct snd_card *card, const char *id, int type,
 	return 0;
 
 fail_input:
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 	input_free_device(jack->input_dev);
+#endif
 	kfree(jack->id);
 	kfree(jack);
 	return err;
 }
 EXPORT_SYMBOL(snd_jack_new);
 
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 /**
  * snd_jack_set_parent - Set the parent device for a jack
  *
@@ -326,10 +340,10 @@ int snd_jack_set_key(struct snd_jack *jack, enum snd_jack_types type,
 
 	jack->type |= type;
 	jack->key[key] = keytype;
-
 	return 0;
 }
 EXPORT_SYMBOL(snd_jack_set_key);
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 
 /**
  * snd_jack_report - Report the current status of a jack
@@ -340,7 +354,9 @@ EXPORT_SYMBOL(snd_jack_set_key);
 void snd_jack_report(struct snd_jack *jack, int status)
 {
 	struct snd_jack_kctl *jack_kctl;
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 	int i;
+#endif
 
 	if (!jack)
 		return;
@@ -349,6 +365,7 @@ void snd_jack_report(struct snd_jack *jack, int status)
 		snd_kctl_jack_report(jack->card, jack_kctl->kctl,
 					    status & jack_kctl->mask_bits);
 
+#ifdef CONFIG_SND_JACK_INPUT_DEV
 	if (!jack->input_dev)
 		return;
 
@@ -369,6 +386,6 @@ void snd_jack_report(struct snd_jack *jack, int status)
 	}
 
 	input_sync(jack->input_dev);
-
+#endif /* CONFIG_SND_JACK_INPUT_DEV */
 }
 EXPORT_SYMBOL(snd_jack_report);
diff --git a/sound/pci/Kconfig b/sound/pci/Kconfig
index 8f6594a7d37f..32151d8c6bb8 100644
--- a/sound/pci/Kconfig
+++ b/sound/pci/Kconfig
@@ -866,7 +866,7 @@ config SND_VIRTUOSO
 	select SND_OXYGEN_LIB
 	select SND_PCM
 	select SND_MPU401_UART
-	select SND_JACK if INPUT=y || INPUT=SND
+	select SND_JACK
 	help
 	  Say Y here to include support for sound cards based on the
 	  Asus AV66/AV100/AV200 chips, i.e., Xonar D1, DX, D2, D2X, DS, DSX,
diff --git a/sound/pci/hda/Kconfig b/sound/pci/hda/Kconfig
index e94cfd5c69f7..bb02c2d48fd5 100644
--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -4,7 +4,7 @@ config SND_HDA
 	tristate
 	select SND_PCM
 	select SND_VMASTER
-	select SND_JACK if INPUT=y || INPUT=SND
+	select SND_JACK
 	select SND_HDA_CORE
 
 config SND_HDA_INTEL
diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 7ea66ee3653f..182d92efc7c8 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -6,7 +6,7 @@ menuconfig SND_SOC
 	tristate "ALSA for SoC audio support"
 	select SND_PCM
 	select AC97_BUS if SND_SOC_AC97_BUS
-	select SND_JACK if INPUT=y || INPUT=SND
+	select SND_JACK
 	select REGMAP_I2C if I2C
 	select REGMAP_SPI if SPI_MASTER
 	---help---
-- 
2.7.1



From arnd at arndb.de  Wed Feb 17 01:40:41 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 10:40:41 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <s5h1t8b65n7.wl-tiwai@suse.de>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
 <s5h8u2j6749.wl-tiwai@suse.de> <s5h1t8b65n7.wl-tiwai@suse.de>
Message-ID: <7110505.tMOluD0MjY@wuerfel>

On Wednesday 17 February 2016 10:35:40 Takashi Iwai wrote:
> From: Takashi Iwai <tiwai at suse.de>
> Subject: [PATCH v2] ALSA: jack: Allow building the jack layer without
>  input device
> 
> Since the recent integration of kctl jack and input jack layers, we
> can basically build the jack layer even without input devices.  That
> is, the jack layer itself can be built with conditional to enable the
> input device support or not, while the users may enable always
> CONFIG_SND_JACK unconditionally.
> 
> For achieving it, this patch changes the following:
> - A new Kconfig, CONFIG_SND_JACK_INPUT_DEV, was introduced to indicate
>   whether the jack layer supports the input device,
> - A few items in snd_jack struct and relevant codes are conditionally
>   built upon CONFIG_SND_JACK_INPUT_DEV,
> - The users of CONFIG_SND_JACK drop the messy dependency on
>   CONFIG_INPUT.
> 
> This change also automagically fixes a potential bug in HD-audio
> driver Arnd reported, where the NULL or uninitialized jack instance is
> dereferenced.
> 
> Reported-by: Arnd Bergmann <arnd at arndb.de>
> Signed-off-by: Takashi Iwai <tiwai at suse.de>
> 

Looks great, that indeed takes care of the issue I reported and
makes the code more useful and more robust overall.

Acked-by: Arnd Bergmann <arnd at arndb.de>


From linux at arm.linux.org.uk  Wed Feb 17 01:41:47 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Feb 2016 09:41:47 +0000
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56C438DA.5040109@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <56C438DA.5040109@ti.com>
Message-ID: <20160217094147.GG19428@n2100.arm.linux.org.uk>

On Wed, Feb 17, 2016 at 11:09:46AM +0200, Tomi Valkeinen wrote:
> What's the SYS_CLCD register? An EEPROM or such, programmed when the
> board is manufactured? Is the panel meant to be switchable by the user,
> possibly to a panel that's not "standard"?

If you read this bit of the patch, which describes the bits in the
register, it gives some clues:

-#define SYS_CLCD_MODE_MASK     (3 << 0)
-#define SYS_CLCD_MODE_888      (0 << 0)
-#define SYS_CLCD_MODE_5551     (1 << 0)
-#define SYS_CLCD_MODE_565_RLSB (2 << 0)
-#define SYS_CLCD_MODE_565_BLSB (3 << 0)
-#define SYS_CLCD_NLCDIOON      (1 << 2)
-#define SYS_CLCD_VDDPOSSWITCH  (1 << 3)
-#define SYS_CLCD_PWR3V5SWITCH  (1 << 4)
-#define SYS_CLCD_ID_MASK       (0x1f << 8)
-#define SYS_CLCD_ID_SANYO_3_8  (0x00 << 8)
-#define SYS_CLCD_ID_UNKNOWN_8_4        (0x01 << 8)
-#define SYS_CLCD_ID_EPSON_2_2  (0x02 << 8)
-#define SYS_CLCD_ID_SANYO_2_5  (0x07 << 8)
-#define SYS_CLCD_ID_VGA                (0x1f << 8)

The LCD panels plug-in to the board, and they have a 5-bit hard-wired
ID, which is signalled through five ID lines into the FPGA.

The register is also writable, which is used to control power supplies
to the LCD and an external MUX which changes the RGB format outside of
the capabilities of the CLCD itself.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From raveendra.padasalagi at broadcom.com  Wed Feb 17 01:43:43 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Wed, 17 Feb 2016 15:13:43 +0530
Subject: [PATCH v2 0/3] Syscon support for iProc touchscreen driver
Message-ID: <1455702226-20599-1-git-send-email-raveendra.padasalagi@broadcom.com>

This patchset is based on v4.5-rc3 tag and its tested on
Broadcom Cygnus SoC.

The patches can be fetched from iproc-tsc-v2 branch of
https://github.com/Broadcom/arm64-linux.git

Changes since v1:
 - Enhanced touchscreen driver to handle syscon based register access if
   "brcm,iproc-touchscreen-syscon" compatible string is provided in dt
 - Normal register access is handled through readl and writel API's if
   "brcm,iproc-touchscreen" compatible string is provided.
 - Updated touchscreen dt node document to reflect the new changes.
 - Updated change logs in each patchset to reflect the new changes.

Raveendra Padasalagi (3):
  input: cygnus-update touchscreen dt node document
  input: syscon support in bcm_iproc_tsc driver
  ARM: dts: use syscon in cygnus touchscreen dt node

 .../input/touchscreen/brcm,iproc-touchscreen.txt   |  57 +++++++-
 arch/arm/boot/dts/bcm-cygnus.dtsi                  |  11 +-
 drivers/input/touchscreen/bcm_iproc_tsc.c          | 152 +++++++++++++++------
 3 files changed, 172 insertions(+), 48 deletions(-)

-- 
1.9.1



From raveendra.padasalagi at broadcom.com  Wed Feb 17 01:43:44 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Wed, 17 Feb 2016 15:13:44 +0530
Subject: [PATCH v2 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <1455702226-20599-1-git-send-email-raveendra.padasalagi@broadcom.com>
References: <1455702226-20599-1-git-send-email-raveendra.padasalagi@broadcom.com>
Message-ID: <1455702226-20599-2-git-send-email-raveendra.padasalagi@broadcom.com>

In Cygnus SOC touch screen controller registers are shared
with ADC and flex timer. Using readl/writel could lead to
race condition. So touch screen driver is enhanced to support

1. If touchscreen register's are not shared. Register access
is handled through readl/writel if "brcm,iproc-touchscreen"
compatible is provided in touchscreen dt node. This will help
for future SOC's if comes with dedicated touchscreen IP register's.

2. If touchscreen register's are shared with other IP's, register
access is handled through syscon framework API's to take care of
mutually exclusive access. This feature can be enabled by selecting
"brcm,iproc-touchscreen-syscon" compatible string in the touchscreen
dt node.

Hence touchscreen dt node bindings document is updated to take care
of above changes in the touchscreen driver.

Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi at broadcom.com>
Reviewed-by: Ray Jui <ray.jui at broadcom.com>
Reviewed-by: Scott Branden <scott.branden at broadcom.com>
---
 .../input/touchscreen/brcm,iproc-touchscreen.txt   | 57 +++++++++++++++++++---
 1 file changed, 51 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
index 34e3382..f530c25 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
@@ -1,12 +1,30 @@
 * Broadcom's IPROC Touchscreen Controller
 
 Required properties:
-- compatible: must be "brcm,iproc-touchscreen"
-- reg: physical base address of the controller and length of memory mapped
-  region.
+- compatible: should be one of
+        "brcm,iproc-touchscreen"
+        "brcm,iproc-touchscreen-syscon"
+- ts_syscon: if "brcm,iproc-touchscreen-syscon" compatible string
+  is selected then "ts_syscon" is mandatory or else not required.
+  The "ts_syscon" is handler of syscon node defining physical base
+  address of the controller and length of memory mapped region.
+  If this property is selected please make sure MFD_SYSCON config
+  is enabled in the defconfig file.
+- reg: if "brcm,iproc-touchscreen" compatible string is selected
+  then "reg" property is mandatory or else not required.
+  The "reg" should be physical base address of the controller and
+  length of memory mapped region.
 - clocks:  The clock provided by the SOC to driver the tsc
 - clock-name:  name for the clock
 - interrupts: The touchscreen controller's interrupt
+- address-cells: Specify the number of u32 entries needed in child nodes.
+                 Should set to 1. This property is mandatory when
+                 "brcm,iproc-touchscreen-syscon" compatible string is selected
+                 or else not required.
+- size-cells: Specify number of u32 entries needed to specify child nodes size
+              in reg property. Should set to 1.This property is mandatory when
+              "brcm,iproc-touchscreen-syscon" compatible string is selected or
+              else not required.
 
 Optional properties:
 - scanning_period: Time between scans. Each step is 1024 us.  Valid 1-256.
@@ -53,13 +71,40 @@ Optional properties:
 - touchscreen-inverted-x: X axis is inverted (boolean)
 - touchscreen-inverted-y: Y axis is inverted (boolean)
 
-Example:
+Example 1: An example of touchscreen node with "brcm,iproc-touchscreen-syscon"
+           compatible string.
+
+	ts_adc_syscon: ts_adc_syscon at 0x180a6000 {
+		compatible = "syscon";
+		reg = <0x180a6000 0xc30>;
+	};
 
 	touchscreen: tsc at 0x180A6000 {
-		compatible = "brcm,iproc-touchscreen";
+		compatible = "brcm,iproc-touchscreen-syscon";
 		#address-cells = <1>;
 		#size-cells = <1>;
-		reg = <0x180A6000 0x40>;
+		ts_syscon = <&ts_adc_syscon>;
+		clocks = <&adc_clk>;
+		clock-names = "tsc_clk";
+		interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
+
+		scanning_period = <5>;
+		debounce_timeout = <40>;
+		settling_timeout = <7>;
+		touch_timeout = <10>;
+		average_data = <5>;
+		fifo_threshold = <1>;
+		/* Touchscreen is rotated 180 degrees. */
+		touchscreen-inverted-x;
+		touchscreen-inverted-y;
+	};
+
+Example 2: An example of touchscreen node with "brcm,iproc-touchscreen"
+          compatible string.
+
+	touchscreen: tsc at 0x180A6000 {
+		compatible = "brcm,iproc-touchscreen";
+		reg = <0x180a6000 0x40>;
 		clocks = <&adc_clk>;
 		clock-names = "tsc_clk";
 		interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
-- 
1.9.1



From raveendra.padasalagi at broadcom.com  Wed Feb 17 01:43:45 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Wed, 17 Feb 2016 15:13:45 +0530
Subject: [PATCH v2 2/3] input: syscon support in bcm_iproc_tsc driver
In-Reply-To: <1455702226-20599-1-git-send-email-raveendra.padasalagi@broadcom.com>
References: <1455702226-20599-1-git-send-email-raveendra.padasalagi@broadcom.com>
Message-ID: <1455702226-20599-3-git-send-email-raveendra.padasalagi@broadcom.com>

In Cygnus SOC touch screen controller registers are shared
with ADC and flex timer. Using readl/writel could lead to
race condition. So touch screen driver is enhanced to support

1. If touchscreen register's are not shared. Register access
is handled through readl/writel if "brcm,iproc-touchscreen"
compatible is provided in touchscreen dt node. This will help
for future SOC's if comes with dedicated touchscreen IP register's.

2. If touchscreen register's are shared with other IP's, register
access is handled through syscon framework API's to take care of
mutually exclusive access. This feature can be enabled by selecting
"brcm,iproc-touchscreen-syscon" compatible string in the touchscreen
dt node.

Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi at broadcom.com>
Reviewed-by: Ray Jui <ray.jui at broadcom.com>
Reviewed-by: Scott Branden <scott.branden at broadcom.com>
---
 drivers/input/touchscreen/bcm_iproc_tsc.c | 152 ++++++++++++++++++++++--------
 1 file changed, 112 insertions(+), 40 deletions(-)

diff --git a/drivers/input/touchscreen/bcm_iproc_tsc.c b/drivers/input/touchscreen/bcm_iproc_tsc.c
index ae460a5c..3ef80c6 100644
--- a/drivers/input/touchscreen/bcm_iproc_tsc.c
+++ b/drivers/input/touchscreen/bcm_iproc_tsc.c
@@ -23,6 +23,8 @@
 #include <linux/io.h>
 #include <linux/clk.h>
 #include <linux/serio.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
 
 #define IPROC_TS_NAME "iproc-ts"
 
@@ -88,7 +90,7 @@
 #define TS_WIRE_MODE_BIT        BIT(1)
 
 #define dbg_reg(dev, priv, reg) \
-	dev_dbg(dev, "%20s= 0x%08x\n", #reg, readl((priv)->regs + reg))
+	dev_dbg(dev, "%20s= 0x%08x\n", #reg, iproc_reg_read(priv, reg))
 
 struct tsc_param {
 	/* Each step is 1024 us.  Valid 1-256 */
@@ -142,12 +144,18 @@ struct iproc_ts_priv {
 	struct input_dev *idev;
 
 	void __iomem *regs;
+	struct regmap *regmap;
 	struct clk *tsc_clk;
 
 	int  pen_status;
 	struct tsc_param cfg_params;
 };
 
+enum iproc_ts_reg_type {
+	IPROC_TS_REG,
+	IPROC_TS_SYSCON,
+};
+
 /*
  * Set default values the same as hardware reset values
  * except for fifo_threshold with is set to 1.
@@ -163,6 +171,41 @@ static const struct tsc_param iproc_default_config = {
 	.max_y            = Y_MAX,
 };
 
+static int iproc_reg_update_bits(struct iproc_ts_priv *priv, u32 reg,
+			   u32 mask, u32 val)
+{
+	int ret = 0;
+	u32 tmp, orig;
+
+	if (priv->regs) {
+		orig = readl(priv->regs);
+		tmp = orig & ~mask;
+		tmp |= val & mask;
+		writel(tmp, priv->regs + reg);
+	} else
+		ret = regmap_update_bits(priv->regmap, reg, mask, val);
+	return ret;
+}
+
+static void iproc_reg_write(struct iproc_ts_priv *priv, u32 reg, u32 val)
+{
+	if (priv->regs)
+		writel(val, priv->regs + reg);
+	else
+		regmap_write(priv->regmap, reg, val);
+}
+
+static u32 iproc_reg_read(struct iproc_ts_priv *priv, u32 reg)
+{
+	u32 val;
+
+	if (priv->regs)
+		val = readl(priv->regs + reg);
+	else
+		regmap_read(priv->regmap, reg, &val);
+	return val;
+}
+
 static void ts_reg_dump(struct iproc_ts_priv *priv)
 {
 	struct device *dev = &priv->pdev->dev;
@@ -196,22 +239,22 @@ static irqreturn_t iproc_touchscreen_interrupt(int irq, void *data)
 	int i;
 	bool needs_sync = false;
 
-	intr_status = readl(priv->regs + INTERRUPT_STATUS);
-	intr_status &= TS_PEN_INTR_MASK | TS_FIFO_INTR_MASK;
+	intr_status = iproc_reg_read(priv, INTERRUPT_STATUS);
+	intr_status &= (TS_PEN_INTR_MASK | TS_FIFO_INTR_MASK);
 	if (intr_status == 0)
 		return IRQ_NONE;
 
 	/* Clear all interrupt status bits, write-1-clear */
-	writel(intr_status, priv->regs + INTERRUPT_STATUS);
-
+	iproc_reg_write(priv, INTERRUPT_STATUS, intr_status);
 	/* Pen up/down */
 	if (intr_status & TS_PEN_INTR_MASK) {
-		if (readl(priv->regs + CONTROLLER_STATUS) & TS_PEN_DOWN)
+		priv->pen_status = iproc_reg_read(priv, CONTROLLER_STATUS);
+		if (priv->pen_status & TS_PEN_DOWN)
 			priv->pen_status = PEN_DOWN_STATUS;
 		else
 			priv->pen_status = PEN_UP_STATUS;
 
-		input_report_key(priv->idev, BTN_TOUCH, priv->pen_status);
+		input_report_key(priv->idev, BTN_TOUCH,	priv->pen_status);
 		needs_sync = true;
 
 		dev_dbg(&priv->pdev->dev,
@@ -221,7 +264,7 @@ static irqreturn_t iproc_touchscreen_interrupt(int irq, void *data)
 	/* coordinates in FIFO exceed the theshold */
 	if (intr_status & TS_FIFO_INTR_MASK) {
 		for (i = 0; i < priv->cfg_params.fifo_threshold; i++) {
-			raw_coordinate = readl(priv->regs + FIFO_DATA);
+			raw_coordinate = iproc_reg_read(priv, FIFO_DATA);
 			if (raw_coordinate == INVALID_COORD)
 				continue;
 
@@ -239,7 +282,7 @@ static irqreturn_t iproc_touchscreen_interrupt(int irq, void *data)
 			x = (x >> 4) & 0x0FFF;
 			y = (y >> 4) & 0x0FFF;
 
-			/* adjust x y according to lcd tsc mount angle */
+			/* Adjust x y according to LCD tsc mount angle. */
 			if (priv->cfg_params.invert_x)
 				x = priv->cfg_params.max_x - x;
 
@@ -262,9 +305,10 @@ static irqreturn_t iproc_touchscreen_interrupt(int irq, void *data)
 
 static int iproc_ts_start(struct input_dev *idev)
 {
-	struct iproc_ts_priv *priv = input_get_drvdata(idev);
 	u32 val;
+	u32 mask;
 	int error;
+	struct iproc_ts_priv *priv = input_get_drvdata(idev);
 
 	/* Enable clock */
 	error = clk_prepare_enable(priv->tsc_clk);
@@ -279,9 +323,10 @@ static int iproc_ts_start(struct input_dev *idev)
 	 *  FIFO reaches the int_th value, and pen event(up/down)
 	 */
 	val = TS_PEN_INTR_MASK | TS_FIFO_INTR_MASK;
-	writel(val, priv->regs + INTERRUPT_MASK);
+	iproc_reg_update_bits(priv, INTERRUPT_MASK, val, val);
 
-	writel(priv->cfg_params.fifo_threshold, priv->regs + INTERRUPT_THRES);
+	val = priv->cfg_params.fifo_threshold;
+	iproc_reg_write(priv, INTERRUPT_THRES, val);
 
 	/* Initialize control reg1 */
 	val = 0;
@@ -289,26 +334,23 @@ static int iproc_ts_start(struct input_dev *idev)
 	val |= priv->cfg_params.debounce_timeout << DEBOUNCE_TIMEOUT_SHIFT;
 	val |= priv->cfg_params.settling_timeout << SETTLING_TIMEOUT_SHIFT;
 	val |= priv->cfg_params.touch_timeout << TOUCH_TIMEOUT_SHIFT;
-	writel(val, priv->regs + REGCTL1);
+	iproc_reg_write(priv, REGCTL1, val);
 
 	/* Try to clear all interrupt status */
-	val = readl(priv->regs + INTERRUPT_STATUS);
-	val |= TS_FIFO_INTR_MASK | TS_PEN_INTR_MASK;
-	writel(val, priv->regs + INTERRUPT_STATUS);
+	val = TS_FIFO_INTR_MASK | TS_PEN_INTR_MASK;
+	iproc_reg_update_bits(priv, INTERRUPT_STATUS, val, val);
 
 	/* Initialize control reg2 */
-	val = readl(priv->regs + REGCTL2);
-	val |= TS_CONTROLLER_EN_BIT | TS_WIRE_MODE_BIT;
-
-	val &= ~TS_CONTROLLER_AVGDATA_MASK;
+	val = TS_CONTROLLER_EN_BIT | TS_WIRE_MODE_BIT;
 	val |= priv->cfg_params.average_data << TS_CONTROLLER_AVGDATA_SHIFT;
 
-	val &= ~(TS_CONTROLLER_PWR_LDO |	/* PWR up LDO */
+	mask = (TS_CONTROLLER_AVGDATA_MASK);
+	mask |= (TS_CONTROLLER_PWR_LDO |	/* PWR up LDO */
 		   TS_CONTROLLER_PWR_ADC |	/* PWR up ADC */
 		   TS_CONTROLLER_PWR_BGP |	/* PWR up BGP */
 		   TS_CONTROLLER_PWR_TS);	/* PWR up TS */
-
-	writel(val, priv->regs + REGCTL2);
+	mask |= val;
+	iproc_reg_update_bits(priv, REGCTL2, mask, val);
 
 	ts_reg_dump(priv);
 
@@ -320,12 +362,17 @@ static void iproc_ts_stop(struct input_dev *dev)
 	u32 val;
 	struct iproc_ts_priv *priv = input_get_drvdata(dev);
 
-	writel(0, priv->regs + INTERRUPT_MASK); /* Disable all interrupts */
+	/*
+	 * Disable FIFO int_th and pen event(up/down)Interrupts only
+	 * as the interrupt mask register is shared between ADC, TS and
+	 * flextimer.
+	 */
+	val = TS_PEN_INTR_MASK | TS_FIFO_INTR_MASK;
+	iproc_reg_update_bits(priv, INTERRUPT_MASK, val, 0);
 
 	/* Only power down touch screen controller */
-	val = readl(priv->regs + REGCTL2);
-	val |= TS_CONTROLLER_PWR_TS;
-	writel(val, priv->regs + REGCTL2);
+	val = TS_CONTROLLER_PWR_TS;
+	iproc_reg_update_bits(priv, REGCTL2, val, val);
 
 	clk_disable(priv->tsc_clk);
 }
@@ -410,25 +457,56 @@ static int iproc_get_tsc_config(struct device *dev, struct iproc_ts_priv *priv)
 	return 0;
 }
 
+static const struct of_device_id iproc_ts_of_match[] = {
+	{.compatible = "brcm,iproc-touchscreen",
+	 .data = (void *) IPROC_TS_REG },
+	{.compatible = "brcm,iproc-touchscreen-syscon",
+	 .data = (void *) IPROC_TS_SYSCON },
+	{},
+};
+MODULE_DEVICE_TABLE(of, iproc_ts_of_match);
+
 static int iproc_ts_probe(struct platform_device *pdev)
 {
 	struct iproc_ts_priv *priv;
 	struct input_dev *idev;
 	struct resource *res;
+	const struct of_device_id *of_id;
 	int irq;
 	int error;
+	enum iproc_ts_reg_type reg_access;
 
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv)
 		return -ENOMEM;
 
-	/* touchscreen controller memory mapped regs */
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	priv->regs = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(priv->regs)) {
-		error = PTR_ERR(priv->regs);
-		dev_err(&pdev->dev, "unable to map I/O memory: %d\n", error);
-		return error;
+	of_id = of_match_node(iproc_ts_of_match, pdev->dev.of_node);
+	if (of_id)
+		reg_access = (enum iproc_ts_reg_type)of_id->data;
+	else
+		return -ENODEV;
+
+	if (reg_access == IPROC_TS_SYSCON) {
+		/* touchscreen controller memory mapped regs via syscon */
+		priv->regmap = syscon_regmap_lookup_by_phandle(
+						pdev->dev.of_node,
+						"ts_syscon");
+		if (IS_ERR(priv->regmap)) {
+			error = PTR_ERR(priv->regs);
+			dev_err(&pdev->dev, "unable to map I/O memory:%d\n",
+				error);
+			return error;
+		}
+	} else {
+		/* touchscreen controller memory mapped regs */
+		res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+		priv->regs = devm_ioremap_resource(&pdev->dev, res);
+		if (IS_ERR(priv->regs)) {
+			error = PTR_ERR(priv->regs);
+			dev_err(&pdev->dev, "unable to map I/O memory:%d\n",
+				error);
+			return error;
+		}
 	}
 
 	priv->tsc_clk = devm_clk_get(&pdev->dev, "tsc_clk");
@@ -501,12 +579,6 @@ static int iproc_ts_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static const struct of_device_id iproc_ts_of_match[] = {
-	{.compatible = "brcm,iproc-touchscreen", },
-	{ },
-};
-MODULE_DEVICE_TABLE(of, iproc_ts_of_match);
-
 static struct platform_driver iproc_ts_driver = {
 	.probe = iproc_ts_probe,
 	.driver = {
-- 
1.9.1



From raveendra.padasalagi at broadcom.com  Wed Feb 17 01:43:46 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Wed, 17 Feb 2016 15:13:46 +0530
Subject: [PATCH v2 3/3] ARM: dts: use syscon in cygnus touchscreen dt node
In-Reply-To: <1455702226-20599-1-git-send-email-raveendra.padasalagi@broadcom.com>
References: <1455702226-20599-1-git-send-email-raveendra.padasalagi@broadcom.com>
Message-ID: <1455702226-20599-4-git-send-email-raveendra.padasalagi@broadcom.com>

In Cygnus SOC touch screen controller registers are shared
with ADC and flex timer. Using readl/writel could lead to
race condition. So in such case register access is handled
through syscon framework API's in the touch screen driver.
This feature is enabled if "brcm,iproc-touchscreen-syscon"
compatible string is selected in touchscreen dt node.

So this patch enables syscon support in touchscreen driver
by adding necessary properties in touchscreen dt node.

Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi at broadcom.com>
Reviewed-by: Ray Jui <ray.jui at broadcom.com>
Reviewed-by: Scott Branden <scott.branden at broadcom.com>
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 3878793..79678c1 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -351,9 +351,16 @@
 					<&pinctrl 142 10 1>;
 		};
 
+		ts_adc_syscon: ts_adc_syscon at 0x180a6000 {
+			compatible = "syscon";
+			reg = <0x180a6000 0xc30>;
+		};
+
 		touchscreen: tsc at 180a6000 {
-			compatible = "brcm,iproc-touchscreen";
-			reg = <0x180a6000 0x40>;
+			compatible = "brcm,iproc-touchscreen-syscon";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ts_syscon = <&ts_adc_syscon>;
 			clocks = <&asiu_clks BCM_CYGNUS_ASIU_ADC_CLK>;
 			clock-names = "tsc_clk";
 			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
-- 
1.9.1



From mingo at kernel.org  Wed Feb 17 01:45:10 2016
From: mingo at kernel.org (Ingo Molnar)
Date: Wed, 17 Feb 2016 10:45:10 +0100
Subject: [PATCH v3 0/2] Consolidate redundant register/stack access code
In-Reply-To: <56BA5226.3090105@linaro.org>
References: <1454996337-7935-1-git-send-email-dave.long@linaro.org>
 <1455010600.13384.3.camel@ellerman.id.au>
 <20160209094526.GB25268@gmail.com> <56BA5226.3090105@linaro.org>
Message-ID: <20160217094510.GA27144@gmail.com>


* David Long <dave.long at linaro.org> wrote:

> On 02/09/2016 04:45 AM, Ingo Molnar wrote:
> >
> >* Michael Ellerman <mpe at ellerman.id.au> wrote:
> >
> >>On Tue, 2016-02-09 at 00:38 -0500, David Long wrote:
> >>
> >>>From: "David A. Long" <dave.long at linaro.org>
> >>>
> >>>Move duplicate and functionally equivalent code for accessing registers
> >>>and stack (CONFIG_HAVE_REGS_AND_STACK_ACCESS_API) from arch subdirs into
> >>>common kernel files.
> >>>
> >>>I'm sending this out again (with updated distribution list) because v2
> >>>just never got pulled in, even though I don't think there were any
> >>>outstanding issues.
> >>
> >>A big cross arch patch like this would often get taken by Andrew Morton, but
> >>AFAICS you didn't CC him - so I just added him, perhaps he'll pick it up for
> >>us :D
> >
> >The other problem is that the second patch is commingling changes to 6 separate
> >architectures:
> >
> >  16 files changed, 106 insertions(+), 343 deletions(-)
> >
> >that should probably be 6 separate patches. Easier to review, easier to bisect to,
> >easier to revert, etc.
> >
> >Thanks,
> >
> >	Ingo
> >
> 
> I see your point but I'm not sure it could have been broken into separate 
> successive patches that would each build for all architectures.

Why? AFAICS all the functionality appears to be conditional on 
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API, so it ought to build standalone as well, on 
a per arch basis, as long as the core kernel patch is applied first.

Thanks,

	Ingo


From arnd at arndb.de  Wed Feb 17 01:45:40 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 10:45:40 +0100
Subject: [PATCH v2 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <1455702226-20599-2-git-send-email-raveendra.padasalagi@broadcom.com>
References: <1455702226-20599-1-git-send-email-raveendra.padasalagi@broadcom.com>
 <1455702226-20599-2-git-send-email-raveendra.padasalagi@broadcom.com>
Message-ID: <13357929.DDBX61jLXt@wuerfel>

On Wednesday 17 February 2016 15:13:44 Raveendra Padasalagi wrote:
> +
> +       ts_adc_syscon: ts_adc_syscon at 0x180a6000 {
> +               compatible = "syscon";
> +               reg = <0x180a6000 0xc30>;
> +       };
> 

This should have a more specific compatible string in addition to the
generic "syscon" one.

	Arnd


From raveendra.padasalagi at broadcom.com  Wed Feb 17 01:53:49 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Wed, 17 Feb 2016 15:23:49 +0530
Subject: [PATCH v2 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <13357929.DDBX61jLXt@wuerfel>
References: <1455702226-20599-1-git-send-email-raveendra.padasalagi@broadcom.com>
 <1455702226-20599-2-git-send-email-raveendra.padasalagi@broadcom.com>
 <13357929.DDBX61jLXt@wuerfel>
Message-ID: <b2adbdb45d34485fbe8a29f580ab0c61@mail.gmail.com>

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 17 February 2016 15:16
> To: Raveendra Padasalagi
> Cc: Dmitry Torokhov; Russell King; Rob Herring;
devicetree at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org; linux-input at vger.kernel.org; Pawel
Moll;
> Mark Rutland; Ian Campbell; Kumar Gala; Jonathan Richardson; Jon Mason;
> Florian Fainelli; Anup Patel; Ray Jui; Scott Branden; linux-
> kernel at vger.kernel.org; bcm-kernel-feedback-list at broadcom.com
> Subject: Re: [PATCH v2 1/3] input: cygnus-update touchscreen dt node
> document
>
> On Wednesday 17 February 2016 15:13:44 Raveendra Padasalagi wrote:
> > +
> > +       ts_adc_syscon: ts_adc_syscon at 0x180a6000 {
> > +               compatible = "syscon";
> > +               reg = <0x180a6000 0xc30>;
> > +       };
> >
>
> This should have a more specific compatible string in addition to the
generic
> "syscon" one.

Ok, Thanks Arnd. I will address this in the next patch.

> 	Arnd


From s.nawrocki at samsung.com  Wed Feb 17 02:03:36 2016
From: s.nawrocki at samsung.com (Sylwester Nawrocki)
Date: Wed, 17 Feb 2016 11:03:36 +0100
Subject: [PATCH v5 2/3] clk: samsung: Don't build ARMv8 clock drivers on
 ARMv7
In-Reply-To: <1455603632-11158-3-git-send-email-k.kozlowski@samsung.com>
References: <1455603632-11158-1-git-send-email-k.kozlowski@samsung.com>
 <1455603632-11158-3-git-send-email-k.kozlowski@samsung.com>
Message-ID: <56C44578.5010009@samsung.com>

On 16/02/16 07:20, Krzysztof Kozlowski wrote:
> Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS
> so it is built also on ARMv7. This does not bring any kind of benefit.
> There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like
> multi_v7 for ARMv7).
> 
> Instead build clock drivers only for respective SoC's architecture.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>

Acked-by: Sylwester Nawrocki <s.nawrocki at samsung.com>



From brian.starkey at arm.com  Wed Feb 17 02:07:34 2016
From: brian.starkey at arm.com (Brian Starkey)
Date: Wed, 17 Feb 2016 10:07:34 +0000
Subject: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag
In-Reply-To: <20160217004351.GE3037@kroah.com>
References: <cover.1454950917.git.brian.starkey@arm.com>
 <9085d37fa97a762a46b9d58719c085368682c64f.1454950917.git.brian.starkey@arm.com>
 <20160208183006.GA8429@kroah.com>
 <20160209091501.GA23507@e106950-lin.cambridge.arm.com>
 <20160216111426.GA22133@e106950-lin.cambridge.arm.com>
 <20160217004351.GE3037@kroah.com>
Message-ID: <20160217100734.GC22133@e106950-lin.cambridge.arm.com>

On Tue, Feb 16, 2016 at 04:43:51PM -0800, Greg Kroah-Hartman wrote:
>On Tue, Feb 16, 2016 at 11:14:26AM +0000, Brian Starkey wrote:
>> Hi Greg,
>>
>> Is the documentation OK? Is there any chance of you picking up this
>> series?
>>
>> I can rebase onto -next if that's the right place, but they still apply
>> on 4.5-rc4 and fix a panic, so I thought perhaps they could make 4.5.
>
>I think memory stuff like this goes through Andrew's tree, not mine...

Right, fair enough. I was just blindly working off get_maintainer.pl

Cheers,

Brian
>
>thanks,
>
>greg k-h
>


From james.morse at arm.com  Wed Feb 17 02:10:00 2016
From: james.morse at arm.com (James Morse)
Date: Wed, 17 Feb 2016 10:10:00 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <56C43A23.1020301@virtuozzo.com>
References: <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com>
 <CAKv+Gu8WE=fTZF0Pou24FKDocgshWu8dJRbaC5SJ11E-6T=2Hw@mail.gmail.com>
 <56C34204.60605@virtuozzo.com> <20160216164245.GC8022@leverpostej>
 <56C43A23.1020301@virtuozzo.com>
Message-ID: <56C446F8.3050906@arm.com>

On 17/02/16 09:15, Andrey Ryabinin wrote:
> On 02/16/2016 07:42 PM, Mark Rutland wrote:
>> On Tue, Feb 16, 2016 at 06:36:36PM +0300, Andrey Ryabinin wrote:
>>> You are right. 
>>> So we should write 'shadow_start' instead of 'i'.
>>
>> FWIW with the below patch I don't see any "screwed shadow mapping"
>> warnings on my board, and still later see a tonne of KASAN splats in the
>> scheduler.
>>
> 
> It is possible that I missed something, but I think it means that shadow is alright.
> 
> I wonder whether this happens on 4.4. If not, than something in 4.5-rc1 caused this, and the obvious suspect
> here is irq stack.

This quick hack will prevent ever switching to the irq stack:

---------------------------%<---------------------------
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 1f7f5a2b61bf..83ae736429b6 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -188,7 +188,7 @@ alternative_endif
         */
        and     x25, x19, #~(THREAD_SIZE - 1)
        cmp     x25, tsk
-       b.ne    9998f
+       b       9998f

        this_cpu_ptr irq_stack, x25, x26
        mov     x26, #IRQ_STACK_START_SP
---------------------------%<---------------------------


James



From catalin.marinas at arm.com  Wed Feb 17 02:18:03 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 17 Feb 2016 10:18:03 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <56C43A23.1020301@virtuozzo.com>
References: <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com>
 <CAKv+Gu8WE=fTZF0Pou24FKDocgshWu8dJRbaC5SJ11E-6T=2Hw@mail.gmail.com>
 <56C34204.60605@virtuozzo.com> <20160216164245.GC8022@leverpostej>
 <56C43A23.1020301@virtuozzo.com>
Message-ID: <20160217101803.GB32714@e104818-lin.cambridge.arm.com>

On Wed, Feb 17, 2016 at 12:15:15PM +0300, Andrey Ryabinin wrote:
> On 02/16/2016 07:42 PM, Mark Rutland wrote:
> > FWIW with the below patch I don't see any "screwed shadow mapping"
> > warnings on my board, and still later see a tonne of KASAN splats in the
> > scheduler.
> 
> It is possible that I missed something, but I think it means that
> shadow is alright.
> 
> I wonder whether this happens on 4.4. If not, than something in
> 4.5-rc1 caused this, and the obvious suspect here is irq stack.

It doesn't seem to happen on 4.4, it starts somewhere before 4.5-rc1. I
tested the arm64 branch that we pushed upstream with the irq stack
changes but it didn't trigger. It could as well be a combination of
multiple change or just something else.

We'll do some bisecting, though it's not that fun going through the
merging window commits, especially since many are based on 4.4-rcX (we
could try on merges only first, there are fewer).

-- 
Catalin


From robin.murphy at arm.com  Wed Feb 17 02:19:17 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 17 Feb 2016 10:19:17 +0000
Subject: [PATCH] ARM64: dma-mapping: fix handling of devices registered
 before arch_initcall
In-Reply-To: <56C41BE6.5000203@samsung.com>
References: <1455632084-14666-1-git-send-email-m.szyprowski@samsung.com>
 <56C37317.9020104@arm.com> <56C41BE6.5000203@samsung.com>
Message-ID: <56C44925.6090406@arm.com>

On 17/02/16 07:06, Marek Szyprowski wrote:
> Hello,
>
> On 2016-02-16 20:05, Robin Murphy wrote:
>> On 16/02/16 14:14, Marek Szyprowski wrote:
>>> This patch ensures that devices, which got registered before
>>> arch_initcall
>>> will be handled correctly by IOMMU-based DMA-mapping code.
>>>
>>> Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
>>> ---
>>>   arch/arm64/mm/dma-mapping.c | 4 ++++
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>>> index 573b1e6..ce6019f 100644
>>> --- a/arch/arm64/mm/dma-mapping.c
>>> +++ b/arch/arm64/mm/dma-mapping.c
>>> @@ -928,6 +928,10 @@ static int __init __iommu_dma_init(void)
>>>           ret = register_iommu_dma_ops_notifier(&platform_bus_type);
>>>       if (!ret)
>>>           ret = register_iommu_dma_ops_notifier(&amba_bustype);
>>> +
>>> +    /* handle devices queued before this arch_initcall */
>>> +    if (!ret)
>>> +        __iommu_attach_notifier(NULL, BUS_NOTIFY_ADD_DEVICE, NULL);
>>
>> Hmm, surely unless *all* the devices on the relevant buses are created
>> before arch_initcall level, then the next one is going to kick off the
>> notifier to walk the whole list anyway. Have you seen this being a
>> problem in practice?
>
> Yes, I've observed such situation, that's why I've posted this patch. I was
> really surprised that this code doesn't handle all cases.

Ok, fair enough - I guess I just didn't consider that being a likely 
possibility. Since I am a fan of correctness:

Acked-by: Robin Murphy <robin.murphy at arm.com>

Thanks,
Robin.

>
> Best regards



From catalin.marinas at arm.com  Wed Feb 17 02:19:41 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 17 Feb 2016 10:19:41 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <56C446F8.3050906@arm.com>
References: <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com>
 <CAKv+Gu8WE=fTZF0Pou24FKDocgshWu8dJRbaC5SJ11E-6T=2Hw@mail.gmail.com>
 <56C34204.60605@virtuozzo.com> <20160216164245.GC8022@leverpostej>
 <56C43A23.1020301@virtuozzo.com> <56C446F8.3050906@arm.com>
Message-ID: <20160217101941.GC32714@e104818-lin.cambridge.arm.com>

On Wed, Feb 17, 2016 at 10:10:00AM +0000, James Morse wrote:
> On 17/02/16 09:15, Andrey Ryabinin wrote:
> > On 02/16/2016 07:42 PM, Mark Rutland wrote:
> >> On Tue, Feb 16, 2016 at 06:36:36PM +0300, Andrey Ryabinin wrote:
> >>> You are right. 
> >>> So we should write 'shadow_start' instead of 'i'.
> >>
> >> FWIW with the below patch I don't see any "screwed shadow mapping"
> >> warnings on my board, and still later see a tonne of KASAN splats in the
> >> scheduler.
> >>
> > 
> > It is possible that I missed something, but I think it means that shadow is alright.
> > 
> > I wonder whether this happens on 4.4. If not, than something in 4.5-rc1 caused this, and the obvious suspect
> > here is irq stack.
> 
> This quick hack will prevent ever switching to the irq stack:
> 
> ---------------------------%<---------------------------
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 1f7f5a2b61bf..83ae736429b6 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -188,7 +188,7 @@ alternative_endif
>          */
>         and     x25, x19, #~(THREAD_SIZE - 1)
>         cmp     x25, tsk
> -       b.ne    9998f
> +       b       9998f
> 
>         this_cpu_ptr irq_stack, x25, x26
>         mov     x26, #IRQ_STACK_START_SP

Thanks James. I'll give it a try.

-- 
Catalin


From catalin.marinas at arm.com  Wed Feb 17 02:36:23 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 17 Feb 2016 10:36:23 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <20160217101941.GC32714@e104818-lin.cambridge.arm.com>
References: <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com>
 <CAKv+Gu8WE=fTZF0Pou24FKDocgshWu8dJRbaC5SJ11E-6T=2Hw@mail.gmail.com>
 <56C34204.60605@virtuozzo.com> <20160216164245.GC8022@leverpostej>
 <56C43A23.1020301@virtuozzo.com> <56C446F8.3050906@arm.com>
 <20160217101941.GC32714@e104818-lin.cambridge.arm.com>
Message-ID: <20160217103623.GD32714@e104818-lin.cambridge.arm.com>

On Wed, Feb 17, 2016 at 10:19:41AM +0000, Catalin Marinas wrote:
> On Wed, Feb 17, 2016 at 10:10:00AM +0000, James Morse wrote:
> > On 17/02/16 09:15, Andrey Ryabinin wrote:
> > > On 02/16/2016 07:42 PM, Mark Rutland wrote:
> > >> On Tue, Feb 16, 2016 at 06:36:36PM +0300, Andrey Ryabinin wrote:
> > >>> You are right. 
> > >>> So we should write 'shadow_start' instead of 'i'.
> > >>
> > >> FWIW with the below patch I don't see any "screwed shadow mapping"
> > >> warnings on my board, and still later see a tonne of KASAN splats in the
> > >> scheduler.
> > >>
> > > 
> > > It is possible that I missed something, but I think it means that shadow is alright.
> > > 
> > > I wonder whether this happens on 4.4. If not, than something in 4.5-rc1 caused this, and the obvious suspect
> > > here is irq stack.
> > 
> > This quick hack will prevent ever switching to the irq stack:
> > 
> > ---------------------------%<---------------------------
> > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > index 1f7f5a2b61bf..83ae736429b6 100644
> > --- a/arch/arm64/kernel/entry.S
> > +++ b/arch/arm64/kernel/entry.S
> > @@ -188,7 +188,7 @@ alternative_endif
> >          */
> >         and     x25, x19, #~(THREAD_SIZE - 1)
> >         cmp     x25, tsk
> > -       b.ne    9998f
> > +       b       9998f
> > 
> >         this_cpu_ptr irq_stack, x25, x26
> >         mov     x26, #IRQ_STACK_START_SP
> 
> Thanks James. I'll give it a try.

And it didn't make any difference (on top of 4.5-rc1), still the same
KASAN warnings.

-- 
Catalin


From arnd at arndb.de  Wed Feb 17 02:36:49 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 11:36:49 +0100
Subject: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
In-Reply-To: <m3ziuzpwbu.fsf@t19.piap.pl>
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <3062977.Ya2ztQYFaM@wuerfel> <m3ziuzpwbu.fsf@t19.piap.pl>
Message-ID: <2926671.iEYNiy920m@wuerfel>

On Wednesday 17 February 2016 09:36:37 Krzysztof Ha?asa wrote:
> Arnd Bergmann <arnd at arndb.de> writes:
> 
> > ixp4xx is really special in that it performs hardware swapping for
> > internal devices based on CPU endianess but not on PCI devices.
> 
> Again, IXP4xx does not perform hardware (nor any other) swapping for
> registers of on-chip devices. The registers are connected 1:1,
> bit 0 to bit 0 etc.
> 
> (Yes, IXP4xx can be optionally programmed for such swapping, depending
> on silicon revision, but it is not used in mainline kernel).
> 
> The only hardware swapping happens on PCI bus (in BE mode), to be
> compatible with other platforms and non-IXP4xx-specific PCI drivers.

Ok, so I guess what this means is that ixp4xx (or xscale in general)
implements its big-endian mode by adding a byteswap on its DRAM
and PCI interfaces in be32 mode, rather than by changing the behavior of
the load/store operations (as be8 mode does) or by having the byteswap
in its load/store pipeline or the top-level AHB bridge?

It's a bit surprising but it sounds plausible and explains most of
the code we see.

I'm still unsure about __indirect_readsl()/ioread32_rep()/insl()/readsl().

insl() does a double-swap on big-endian, which seems right, as we
end up with four swaps total, preserving correct byte order.

__raw_readsl() performs no swap, which would be correct for PCI
(same swap on PCI and RAM, so byteorder is preserved), but wrong
for on-chip FIFO registers (one swap on RAM, no swap on MMIO).
This is probably fine as well, as I don't see any use of __raw_readsl()
on non-PCI devices.

However, when CONFIG_IXP4XX_INDIRECT_PCI is set, both
ioread32_rep() and readsl() call __indirect_readsl(), which
in turn swaps the data once, so I think we actually need this patch:

diff --git a/arch/arm/mach-ixp4xx/include/mach/io.h b/arch/arm/mach-ixp4xx/include/mach/io.h
index e770858b490a..871f92f3504a 100644
--- a/arch/arm/mach-ixp4xx/include/mach/io.h
+++ b/arch/arm/mach-ixp4xx/include/mach/io.h
@@ -85,6 +85,8 @@ u8 __indirect_readb(const volatile void __iomem *p);
 u16 __indirect_readw(const volatile void __iomem *p);
 u32 __indirect_readl(const volatile void __iomem *p);
 
+/* string functions may need to swap data back to revert the byte swap on
+   big-endian __indirect_{read,write}{w,l}() accesses */
 static inline void __indirect_writesb(volatile void __iomem *bus_addr,
 				      const void *p, int count)
 {
@@ -100,7 +102,7 @@ static inline void __indirect_writesw(volatile void __iomem *bus_addr,
 	const u16 *vaddr = p;
 
 	while (count--)
-		writew(*vaddr++, bus_addr);
+		writew((u16 __force)cpu_to_le32(*vaddr++), bus_addr);
 }
 
 static inline void __indirect_writesl(volatile void __iomem *bus_addr,
@@ -108,7 +110,7 @@ static inline void __indirect_writesl(volatile void __iomem *bus_addr,
 {
 	const u32 *vaddr = p;
 	while (count--)
-		writel(*vaddr++, bus_addr);
+		writel((u32 __force)cpu_to_le32(*vaddr++), bus_addr);
 }
 
 static inline void __indirect_readsb(const volatile void __iomem *bus_addr,
@@ -126,7 +128,7 @@ static inline void __indirect_readsw(const volatile void __iomem *bus_addr,
 	u16 *vaddr = p;
 
 	while (count--)
-		*vaddr++ = readw(bus_addr);
+		*vaddr++ = (u16 __force)cpu_to_le16(readw(bus_addr));
 }
 
 static inline void __indirect_readsl(const volatile void __iomem *bus_addr,
@@ -135,7 +137,7 @@ static inline void __indirect_readsl(const volatile void __iomem *bus_addr,
 	u32 *vaddr = p;
 
 	while (count--)
-		*vaddr++ = readl(bus_addr);
+		*vaddr++ = (u32 __force)cpu_to_le32(readl(bus_addr));
 }
 
Does that make sense to you? This is essentially the same thing we already
do for inw/inl/outw/outl.

> > Coming back to the specific pxa25x_udc case: using __raw_* accessors
> > in the driver would possibly end up breaking the PXA25x machines in
> > the (very unlikely) case that someone wants to make it work with
> > big-endian kernels, assuming it does not have the same hardware
> > byteswap logic as ixp4xx.
> 
> I'd expect both CPUs to behave in exactly the same manner, i.e., to
> not swap anything on the internal bus. If true, it would mean it should
> "just work" in both BE and LE modes (including BE mode on PXA, should
> it be actually possible).

Ok, I'll change the patch accordingly and resubmit.

	Arnd


From kernel at martin.sperl.org  Wed Feb 17 02:43:42 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Wed, 17 Feb 2016 11:43:42 +0100
Subject: serial: clk: bcm2835: Strange effects when using aux-uart in
 console
In-Reply-To: <20160216185737.2278.60129@quark.deferred.io>
References: <A5F427B7-9B78-4892-9722-69418C4D0C10@martin.sperl.org>
 <56BC895E.2010108@sperl.org>
 <1617009200.323700.219000a8-c162-4594-aacc-a7e9894518b2.open-xchange@email.1und1.de>
 <662D2FB2-B088-4CFC-8416-A4F35BBAD7DD@sperl.org>
 <F7A2533A-D64C-4187-ABD4-416C446D1637@martin.sperl.org>
 <6CD3FC59-BA17-43D9-897C-A2D122D26EF8@martin.sperl.org>
 <470852136.382408.76a8faee-9235-4ee0-9fd1-e25a1e9f0bb3.open-xchange@email.1und1.de>
 <F7B22AC0-58A7-431D-B203-0C7A9802A040@martin.sperl.org>
 <20160216185737.2278.60129@quark.deferred.io>
Message-ID: <56C44EDE.9020800@martin.sperl.org>


On 16.02.2016 19:57, Michael Turquette wrote:
> Hi Martin & Stefan,
...
> ... how about using the shiny new HAND_OFF clocks feature? See:
>
> http://lkml.kernel.org/r/<1455225554-13267-1-git-send-email-mturquette at baylibre.com>
>
> It seems like you need clocks to remain enabled from the time they are
> registered until a clk consumer driver claims them and Does The Right
> Thing. (e.g. only gates them when it is safe to do so, such as display
> being turned off by user).
>
> Let me know if those patches will help you. The first three patches in
> the series introduce CRITICAL clocks, which never gate. Patches 4-6 are
> a solution that I prefer, allowing the clocks to remain enabled by the
> bootloader, and only gated later on when a consumer driver claims them.
> No changes to clock consumer drivers are required, the framework handles
> the transition of reference counts and the clock provider driver only
> has to set the CLK_ENABLE_HAND_OFF flag for the affected clocks.

I wonder if those patches would really help in this use-case.

HAND_OFF seems to show an issue around the fact that as soon as a
clock is claimed once it is handled "normally".

So when the amba-pl011 driver requests and prepares the uart clock
the "lower" PLLD_per (divider) clock as well as the PLLD (pll) clock
become "prepared" as they are parents.

So fine so good - and that works right now fine.

The problem is that the amba-pl011 driver when loaded as a module
- for some reason - runs clk_unprepare/disable when the tty is closed.

Using stty instead of getty for simplicity (as getty closes and reopens
the tty - or so it seems):
root at raspcm:~# stty -F /dev/ttyAMA0
[ 94.328906] pl011_startup - start
[ 94.332401] pl011_hwinit - prepare-enable
 > HERE PLLD gets prepared/enabled
[ 94.336499] bcm2835_pll_on - plld - start
[ 94.340642] cprman_write - 0x010c = 0x0000020a
[ 94.345170] bcm2835_pll_on - plld - before_wait_pll_lock
[ 94.350637] bcm2835_pll_on - plld - end
 > HERE PLLD_PER gets prepared/enabled
[ 94.354558] cprman_write - 0x1540 = 0x00000004
[ 94.359097] cprman_write - 0x010c = 0x0000020a
 > HERE UART gets prepares/enabled
[ 94.363660] cprman_write - 0x00f0 = 0x000002d6
[ 94.368203] pl011_hwinit - prepare-enable - ret = 0
[ 94.375212] pl011_startup - exit
OUTPUT BY STTY: speed 9600 baud; line = 0;
OUTPUT BY STTY: -brkint -imaxbel
[ 94.381528] pl011_shutdown - start
[ 94.385722] pl011_shutdown - disable_unprepare
 > HERE UART gets disabled/unprepared
[ 94.391024] cprman_write - 0x00f0 = 0x00000286
 > here PLLD_PER gets disabled/unprepared
[ 94.396037] cprman_write - 0x010c = 0x0000028a
[ 94.400616] cprman_write - 0x1540 = 0x00000104
 > HERE PLL gets disabled/unprepared
[ 94.405143] bcm2835_pll_off - plld - start
[ 94.409316] cprman_write - 0x010c = 0x0000038a
[ 94.413906] cprman_write - 0x1140 = 0x00031034
[ 94.418435] bcm2835_pll_off - plld - end
[ 94.422500] pl011_shutdown - exit
root at raspcm:~#

So with the HAND_OFF the PLLD (as it has been prepared) would follow
thru the "release" code as expected, which results in stopping the
PLLD_per clock and subsequently the PLLD clock.

And this disabling of PLLD is what - as far as I can tell - brings
the system to it knees, so this needs to be avoided

And that is what the HAND_OFF flag would not stop, as the clock - at
that time has been claimed - at least when using it directly on PLLD.

Using CLK_IS_CRITICAL instead would solve that issue, as it just does
the prepare/enable inside the framework once and never unprepares it.

I guess it would also help to understand the clock-tree, but
the information on the clock-tree is scarce (or under NDA),
so it is hard to understand why the PLLD impacts the system
in such a way.

Possibly some of the CPU interfaces are sourced from PLLD
(say PLLD_core) and that is why the CPU stops working.

Things that come to mind are:
* SRAM
* AXI bus
* ARM - core (even though that is supposed to be driven of PLLB)
* ARM - L2 cache
* GPU - run by firmware...

And thus disabling the PLLD would impact those interfaces...
(but I could be wrong)

But - as said - documentation on the clock tree details
is unfortunately lacking...

A bit of digging in the source-code shows that the sdram
clock has the clocks in bcm2835_clock_vpu_parents assigned
as parents.

The regdump for the sdram clock shows:
root at raspcm:/build/linux# cat /sys/kernel/debug/clk/sdram/regdump
ctl = 0x00004006
div = 0x00003000

So we use the 6th clock from the list of vpu clocks. (ctl & 0x0f)
and that is the plld_core clock!

This means that obviously disabling PLLD is NOT a good idea, as it
will effectively disable sdram.

Maybe we actually should be forcing the sdram clock to be always
prepared/enabled manually or via CLK_IS_CRITICAL or CLK_HAND_OFF.

Martin

P.s: As far as I understand the reason why the amba_pl011 driver
compiled in is working is because then the driver is used as
the console, so it is always opened and thus the clocks are
always prepared.

Starting getty at a later stage during the boot will thus never
risk getting the prepare_count of the PLLD to 0 - the kernel
console will still hold the prepare reference and thus we
are at 1.


From jan.glauber at caviumnetworks.com  Wed Feb 17 02:47:35 2016
From: jan.glauber at caviumnetworks.com (Jan Glauber)
Date: Wed, 17 Feb 2016 11:47:35 +0100
Subject: [PATCH v3 5/5] arm64/perf: Extend event mask for ARMv8.1
In-Reply-To: <20160216151252.GG14509@arm.com>
References: <cover.1454516082.git.jglauber@cavium.com>
 <fa91eaedf581e6a7053899f25b1b08458dbd4b8e.1454516082.git.jglauber@cavium.com>
 <20160215200404.GX6298@arm.com> <20160216080015.GA3490@hardcore>
 <20160216151252.GG14509@arm.com>
Message-ID: <20160217104735.GA3318@hardcore>

On Tue, Feb 16, 2016 at 03:12:53PM +0000, Will Deacon wrote:
> On Tue, Feb 16, 2016 at 09:00:15AM +0100, Jan Glauber wrote:
> > On Mon, Feb 15, 2016 at 08:04:04PM +0000, Will Deacon wrote:
> > 
> > [...]
> > 
> > > On Wed, Feb 03, 2016 at 06:12:00PM +0100, Jan Glauber wrote:
> > > > +		cpu_pmu->event_mask = 0xffff;	/* ARMv8.1 extended events */
> > > > +	else
> > > > +		cpu_pmu->event_mask = ARMV8_EVTYPE_EVENT;
> > > 
> > > ... although can't we just update ARMV8_EVTYPE_EVENT to be 0xffff now?
> > > AFAICT, that just eats into bits that used to be RES0, so we shouldn't
> > > see any problems. That should make your patch *much* simpler!
> > 
> > That would of course be easier, but I just can't assess the implications.
> > 
> > Probably I'm missing something but to me it looks like the event mask is the
> > only verification we do for the user-space selectable events. Is it safe for
> > implementations that only support 0x3ff events to allow access to the
> > whole 0xffff range? What memory would be accessed for non-existing
> > events?
> 
> Which memory? The worst-case is that we end up writing to some bits in
> a register (e.g. PMXEVTYPER) that are RES0 in ARMv8 afaict.

OK, I see. Than I'm happy to drop 99% of that patch and just increase
the mask.

Jan

> Will


From arnd at arndb.de  Wed Feb 17 02:48:38 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 11:48:38 +0100
Subject: [PATCH 0/7] fix IS_ERR_VALUE usage
In-Reply-To: <1455546925-22119-1-git-send-email-a.hajda@samsung.com>
References: <1455546925-22119-1-git-send-email-a.hajda@samsung.com>
Message-ID: <7443859.JK6ybmGO1A@wuerfel>

On Monday 15 February 2016 15:35:18 Andrzej Hajda wrote:
> 
> Andrzej Hajda (7):
>   netfilter: fix IS_ERR_VALUE usage
>   MIPS: module: fix incorrect IS_ERR_VALUE macro usages
>   drivers: char: mem: fix IS_ERROR_VALUE usage
>   atmel-isi: fix IS_ERR_VALUE usage
>   serial: clps711x: fix IS_ERR_VALUE usage
>   fbdev: exynos: fix IS_ERR_VALUE usage
>   usb: gadget: fsl_qe_udc: fix IS_ERR_VALUE usage
> 

Can you Cc me the next time on all of the patches? I only got
three of them this time.

	Arnd


From mark.rutland at arm.com  Wed Feb 17 02:48:18 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 17 Feb 2016 10:48:18 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <20160217101803.GB32714@e104818-lin.cambridge.arm.com>
References: <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com>
 <CAKv+Gu8WE=fTZF0Pou24FKDocgshWu8dJRbaC5SJ11E-6T=2Hw@mail.gmail.com>
 <56C34204.60605@virtuozzo.com> <20160216164245.GC8022@leverpostej>
 <56C43A23.1020301@virtuozzo.com>
 <20160217101803.GB32714@e104818-lin.cambridge.arm.com>
Message-ID: <20160217104817.GA26303@leverpostej>

On Wed, Feb 17, 2016 at 10:18:03AM +0000, Catalin Marinas wrote:
> On Wed, Feb 17, 2016 at 12:15:15PM +0300, Andrey Ryabinin wrote:
> > On 02/16/2016 07:42 PM, Mark Rutland wrote:
> > > FWIW with the below patch I don't see any "screwed shadow mapping"
> > > warnings on my board, and still later see a tonne of KASAN splats in the
> > > scheduler.
> > 
> > It is possible that I missed something, but I think it means that
> > shadow is alright.
> > 
> > I wonder whether this happens on 4.4. If not, than something in
> > 4.5-rc1 caused this, and the obvious suspect here is irq stack.
> 
> It doesn't seem to happen on 4.4, it starts somewhere before 4.5-rc1. I
> tested the arm64 branch that we pushed upstream with the irq stack
> changes but it didn't trigger. It could as well be a combination of
> multiple change or just something else.
> 
> We'll do some bisecting, though it's not that fun going through the
> merging window commits, especially since many are based on 4.4-rcX (we
> could try on merges only first, there are fewer).

FWIW I did that bisect last night, and that fingered commit
f11aef69b235bc30 ("Merge branch 'pm-cpuidle'") as the first bad commit.

Either there's some subtle interaction, or it's less reproducible than I
thought and the "good" commits are only "possibly-good". I'll try to dig
into that.

FWIW, my bisect log is:

git bisect start
# bad: [92e963f50fc74041b5e9e744c330dca48e04f08d] Linux 4.5-rc1
git bisect bad 92e963f50fc74041b5e9e744c330dca48e04f08d
# good: [afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc] Linux 4.4
git bisect good afd2ff9b7e1b367172f18ba7f693dfb62bdcb2dc
# good: [4dffbfc48d65e5d8157a634fd670065d237a9377] arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP
git bisect good 4dffbfc48d65e5d8157a634fd670065d237a9377
# good: [1289ace5b4f70f1e68ce785735b82c7e483de863] Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
git bisect good 1289ace5b4f70f1e68ce785735b82c7e483de863
# good: [984065055e6e39f8dd812529e11922374bd39352] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux
git bisect good 984065055e6e39f8dd812529e11922374bd39352
# good: [6d1c244803f2c013fb9c31b0904c01f1830b73ab] Merge tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good 6d1c244803f2c013fb9c31b0904c01f1830b73ab
# bad: [0a13daedf7ffc71b0c374a036355da7fddb20d6d] Merge branch 'for-4.5/lightnvm' of git://git.kernel.dk/linux-block
git bisect bad 0a13daedf7ffc71b0c374a036355da7fddb20d6d
# bad: [278e5acae1321978686e85ca92906054a36aa19b] Merge tag 'for-4.5' of git://git.osdn.jp/gitroot/uclinux-h8/linux
git bisect bad 278e5acae1321978686e85ca92906054a36aa19b
# good: [f9cd69fe5eb6347b4de56458d0378bc0fa44bce9] Merge tag 'armsoc-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good f9cd69fe5eb6347b4de56458d0378bc0fa44bce9
# good: [9638685e32af961943b679fcb72d4ddd458eb18f] Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good 9638685e32af961943b679fcb72d4ddd458eb18f
# good: [fa8bb4518771b19460a318fbab3eb36c81db3a50] Merge branch 'pm-devfreq'
git bisect good fa8bb4518771b19460a318fbab3eb36c81db3a50
# bad: [30f05309bde49295e02e45c7e615f73aa4e0ccc2] Merge tag 'pm+acpi-4.5-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 30f05309bde49295e02e45c7e615f73aa4e0ccc2
# good: [5bb1729cbdfbe974ad6385be94b14afbac97e19f] cpuidle: menu: Avoid pointless checks in menu_select()
git bisect good 5bb1729cbdfbe974ad6385be94b14afbac97e19f
# bad: [db2b52f75250c88ee3c6ba3d91bef38f3f1a1e8c] Merge branch 'pm-tools'
git bisect bad db2b52f75250c88ee3c6ba3d91bef38f3f1a1e8c
# good: [38cb76a307821f76c7f9dff7449f73aeb014d5cc] cpupower: Fix build error in cpufreq-info
git bisect good 38cb76a307821f76c7f9dff7449f73aeb014d5cc
# bad: [f11aef69b235bc30c323776d75ac23b43aac45bb] Merge branch 'pm-cpuidle'
git bisect bad f11aef69b235bc30c323776d75ac23b43aac45bb
# first bad commit: [f11aef69b235bc30c323776d75ac23b43aac45bb] Merge branch 'pm-cpuidle'

Thanks,
Mark.


From j-keerthy at ti.com  Wed Feb 17 02:48:43 2016
From: j-keerthy at ti.com (Keerthy)
Date: Wed, 17 Feb 2016 16:18:43 +0530
Subject: [PATCH] ARM: OMAP: DRA7: Make use of omap_revision information for
 soc_is* calls
Message-ID: <1455706123-26497-1-git-send-email-j-keerthy@ti.com>

Currently of_machine_is_compatible is used to detect the soc which
employs string comparison operations. We already have all the required
information in the omap_revision. Hence make use of the same like
the previous OMAPs and avoid costly string comparisons.

Signed-off-by: Keerthy <j-keerthy at ti.com>
---

Couple of checkpatch warnings present but stuck to the code
convention followed in the file already.

Boot tested on both DRA7-EVM and DRA72-EVM.

Previous discussion:

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/378615.html

 arch/arm/mach-omap2/soc.h | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 79ca3c3..70df8f6 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -181,6 +181,14 @@ static inline int is_ti ##class (void)		\
 	return (GET_TI_CLASS == (id)) ? 1 : 0;	\
 }
 
+#define GET_DRA_CLASS	((omap_rev() >> 24) & 0xff)
+
+#define IS_DRA_CLASS(class, id)				\
+static inline int is_dra ##class (void)			\
+{							\
+	return (GET_DRA_CLASS == (id)) ? 1 : 0;		\
+}
+
 #define GET_OMAP_SUBCLASS	((omap_rev() >> 20) & 0x0fff)
 
 #define IS_OMAP_SUBCLASS(subclass, id)			\
@@ -201,6 +209,12 @@ static inline int is_am ##subclass (void)		\
 	return (GET_OMAP_SUBCLASS == (id)) ? 1 : 0;	\
 }
 
+#define IS_DRA_SUBCLASS(subclass, id)			\
+static inline int is_dra ##subclass (void)		\
+{							\
+	return (GET_OMAP_SUBCLASS == (id)) ? 1 : 0;	\
+}
+
 IS_OMAP_CLASS(24xx, 0x24)
 IS_OMAP_CLASS(34xx, 0x34)
 IS_OMAP_CLASS(44xx, 0x44)
@@ -210,6 +224,7 @@ IS_AM_CLASS(33xx, 0x33)
 IS_AM_CLASS(43xx, 0x43)
 
 IS_TI_CLASS(81xx, 0x81)
+IS_DRA_CLASS(7xx, 0x7)
 
 IS_OMAP_SUBCLASS(242x, 0x242)
 IS_OMAP_SUBCLASS(243x, 0x243)
@@ -224,6 +239,8 @@ IS_TI_SUBCLASS(816x, 0x816)
 IS_TI_SUBCLASS(814x, 0x814)
 IS_AM_SUBCLASS(335x, 0x335)
 IS_AM_SUBCLASS(437x, 0x437)
+IS_DRA_SUBCLASS(75x, 0x75)
+IS_DRA_SUBCLASS(72x, 0x72)
 
 #define soc_is_omap24xx()		0
 #define soc_is_omap242x()		0
@@ -397,9 +414,9 @@ IS_OMAP_TYPE(3430, 0x3430)
 #undef soc_is_dra7xx
 #undef soc_is_dra74x
 #undef soc_is_dra72x
-#define soc_is_dra7xx()	(of_machine_is_compatible("ti,dra7"))
-#define soc_is_dra74x()	(of_machine_is_compatible("ti,dra74"))
-#define soc_is_dra72x()	(of_machine_is_compatible("ti,dra72"))
+#define soc_is_dra7xx()	is_dra7xx()
+#define soc_is_dra74x()	is_dra75x()
+#define soc_is_dra72x()	is_dra72x()
 #endif
 
 /* Various silicon revisions for omap2 */
-- 
1.9.1



From broonie at kernel.org  Wed Feb 17 02:53:40 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Feb 2016 10:53:40 +0000
Subject: [PATCH] spi/rockchip: Add dt-binding for Rockchip rk3399 spi
In-Reply-To: <4579617.rz6Yi2sU5M@phil>
References: <1455614538-4415-1-git-send-email-jay.xu@rock-chips.com>
 <1730751.NYv1NxJVuB@phil> <56C3BD26.3030704@rock-chips.com>
 <4579617.rz6Yi2sU5M@phil>
Message-ID: <20160217105340.GI7544@sirena.org.uk>

On Wed, Feb 17, 2016 at 07:45:09AM +0100, Heiko Stuebner wrote:

> That was meant as a reply to Mark's comment, explaining why the double 
> compatible and the driver only binding to the rk3066-one right now.

It's still better to have the compatible explicitly listed in the
driver even if it doesn't change the configuration at all at this time.
That way we've at least got a record that the handling is currently
identical to whatever other devices it is the same as.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/2ce71edf/attachment.sig>

From lorenzo.pieralisi at arm.com  Wed Feb 17 03:00:57 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 17 Feb 2016 11:00:57 +0000
Subject: [PATCH V5 01/15] ACPI: MCFG: Move mmcfg_list management to
 drivers/acpi
In-Reply-To: <1455630825-27253-2-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
 <1455630825-27253-2-git-send-email-tn@semihalf.com>
Message-ID: <20160217110057.GA9794@red-moon>

On Tue, Feb 16, 2016 at 02:53:31PM +0100, Tomasz Nowicki wrote:
> From: Jayachandran C <jchandra at broadcom.com>
> 
> Move pci_mmcfg_list handling to a drivers/acpi/pci_mcfg.c. This is
> to share the API and code with ARM64 later. The corresponding
> declarations are moved from asm/pci_x86.h to linux/pci-acpi.h
> 
> As a part of this we introduce three functions that can be
> implemented by the arch code: pci_mmconfig_map_resource() to map a
> mcfg entry, pci_mmconfig_unmap_resource to do the corresponding
> unmap and pci_mmconfig_enabled to see if the arch setup of
> mcfg entries was successful. We also provide weak implementations
> of these, which will be used from ARM64. On x86, we retain the
> old logic by providing platform specific implementation.
> 
> This patch is purely rearranging code, it should not have any
> impact on the logic of MCFG parsing or list handling.
> 
> Signed-off-by: Jayachandran C <jchandra at broadcom.com>
> [Xen parts:]
> Acked-by: David Vrabel <david.vrabel at citrix.com>
> ---
>  arch/x86/include/asm/pci_x86.h |  24 +---
>  arch/x86/pci/mmconfig-shared.c | 269 +++++------------------------------
>  arch/x86/pci/mmconfig_32.c     |   1 +
>  arch/x86/pci/mmconfig_64.c     |   1 +
>  arch/x86/pci/numachip.c        |   1 +
>  drivers/acpi/Makefile          |   1 +
>  drivers/acpi/pci_mcfg.c        | 312 +++++++++++++++++++++++++++++++++++++++++
>  drivers/xen/pci.c              |   5 +-
>  include/linux/pci-acpi.h       |  33 +++++
>  9 files changed, 386 insertions(+), 261 deletions(-)
>  create mode 100644 drivers/acpi/pci_mcfg.c

This patch makes perfect sense to me and manages to move MCFG handling
to common code in a seamless manner, it is basically a code move with
weak functions to cater for X86 specific legacy bits which are otherwise
pretty complex to untangle, so (apart from a few nits below):

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

[...]

> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> new file mode 100644
> index 0000000..ea84365
> --- /dev/null
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -0,0 +1,312 @@
> +/*
> + * pci_mcfg.c
> + *
> + * Common code to maintain the MCFG areas and mappings
> + *
> + * This has been extracted from arch/x86/pci/mmconfig-shared.c
> + * and moved here so that other architectures can use this code.
> + */
> +
> +#include <linux/pci.h>
> +#include <linux/init.h>
> +#include <linux/dmi.h>
> +#include <linux/pci-acpi.h>
> +#include <linux/sfi_acpi.h>
> +#include <linux/slab.h>
> +#include <linux/mutex.h>
> +#include <linux/rculist.h>

Nit: while at it order them alphabetically.

> +
> +#define PREFIX	"ACPI: "
> +
> +static DEFINE_MUTEX(pci_mmcfg_lock);
> +LIST_HEAD(pci_mmcfg_list);
> +
> +static void list_add_sorted(struct pci_mmcfg_region *new)
> +{
> +	struct pci_mmcfg_region *cfg;
> +
> +	/* keep list sorted by segment and starting bus number */
> +	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list) {
> +		if (cfg->segment > new->segment ||
> +		    (cfg->segment == new->segment &&
> +		     cfg->start_bus >= new->start_bus)) {
> +			list_add_tail_rcu(&new->list, &cfg->list);
> +			return;
> +		}
> +	}
> +	list_add_tail_rcu(&new->list, &pci_mmcfg_list);
> +}
> +
> +static struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
> +						   int end, u64 addr)
> +{
> +	struct pci_mmcfg_region *new;
> +	struct resource *res;
> +
> +	if (addr == 0)
> +		return NULL;
> +
> +	new = kzalloc(sizeof(*new), GFP_KERNEL);
> +	if (!new)
> +		return NULL;
> +
> +	new->address = addr;
> +	new->segment = segment;
> +	new->start_bus = start;
> +	new->end_bus = end;
> +
> +	res = &new->res;
> +	res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
> +	res->end = addr + PCI_MMCFG_BUS_OFFSET(end + 1) - 1;
> +	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> +	snprintf(new->name, PCI_MMCFG_RESOURCE_NAME_LEN,
> +		 "PCI MMCONFIG %04x [bus %02x-%02x]", segment, start, end);
> +	res->name = new->name;
> +
> +	return new;
> +}
> +
> +struct pci_mmcfg_region *pci_mmconfig_add(int segment, int start,
> +							int end, u64 addr)
> +{
> +	struct pci_mmcfg_region *new;
> +
> +	new = pci_mmconfig_alloc(segment, start, end, addr);
> +	if (new) {
> +		mutex_lock(&pci_mmcfg_lock);
> +		list_add_sorted(new);
> +		mutex_unlock(&pci_mmcfg_lock);
> +
> +		pr_info(PREFIX
> +		       "MMCONFIG for domain %04x [bus %02x-%02x] at %pR "
> +		       "(base %#lx)\n",
> +		       segment, start, end, &new->res, (unsigned long)addr);
> +	}
> +
> +	return new;
> +}
> +
> +struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus)
> +{
> +	struct pci_mmcfg_region *cfg;
> +
> +	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
> +		if (cfg->segment == segment &&
> +		    cfg->start_bus <= bus && bus <= cfg->end_bus)
> +			return cfg;
> +
> +	return NULL;
> +}
> +
> +/*
> + * Map a pci_mmcfg_region, can be overrriden by arch

s/overrriden/overridden/

[...]

> +static int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
> +					struct acpi_mcfg_allocation *cfg)
> +{
> +	int year;
> +
> +	if (!config_enabled(CONFIG_X86))
> +		return 0;

This check in generic code may ruffle someone's feathers, I even think we
can run this function safely on ARM64 but to prevent surprises we'd better
keep the X86 check, alternatives like adding a weak function just for a
quirk do not make much sense to me.

Lorenzo

> +
> +	if (cfg->address < 0xFFFFFFFF)
> +		return 0;
> +
> +	if (!strncmp(mcfg->header.oem_id, "SGI", 3))
> +		return 0;
> +
> +	if (mcfg->header.revision >= 1) {
> +		if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) &&
> +		    year >= 2010)
> +			return 0;
> +	}
> +
> +	pr_err(PREFIX "MCFG region for %04x [bus %02x-%02x] at %#llx "
> +	       "is above 4GB, ignored\n", cfg->pci_segment,
> +	       cfg->start_bus_number, cfg->end_bus_number, cfg->address);
> +	return -EINVAL;
> +}
> +
> +static int __init pci_parse_mcfg(struct acpi_table_header *header)
> +{
> +	struct acpi_table_mcfg *mcfg;
> +	struct acpi_mcfg_allocation *cfg_table, *cfg;
> +	unsigned long i;
> +	int entries;
> +
> +	if (!header)
> +		return -EINVAL;
> +
> +	mcfg = (struct acpi_table_mcfg *)header;
> +
> +	/* how many config structures do we have */
> +	entries = 0;
> +	i = header->length - sizeof(struct acpi_table_mcfg);
> +	while (i >= sizeof(struct acpi_mcfg_allocation)) {
> +		entries++;
> +		i -= sizeof(struct acpi_mcfg_allocation);
> +	}
> +	if (entries == 0) {
> +		pr_err(PREFIX "MMCONFIG has no entries\n");
> +		return -ENODEV;
> +	}
> +
> +	cfg_table = (struct acpi_mcfg_allocation *) &mcfg[1];
> +	for (i = 0; i < entries; i++) {
> +		cfg = &cfg_table[i];
> +		if (acpi_mcfg_check_entry(mcfg, cfg))
> +			return -ENODEV;
> +
> +		if (pci_mmconfig_add(cfg->pci_segment, cfg->start_bus_number,
> +				   cfg->end_bus_number, cfg->address) == NULL) {
> +			pr_warn(PREFIX "no memory for MCFG entries\n");
> +			return -ENOMEM;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +int __init pci_mmconfig_parse_table(void)
> +{
> +	return acpi_sfi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg);
> +}
> +
> +void __weak __init pci_mmcfg_late_init(void)
> +{
> +	int err, n = 0;
> +	struct pci_mmcfg_region *cfg;
> +
> +	err = pci_mmconfig_parse_table();
> +	if (err) {
> +		pr_err(PREFIX " Failed to parse MCFG (%d)\n", err);
> +		return;
> +	}
> +
> +	list_for_each_entry(cfg, &pci_mmcfg_list, list) {
> +		pci_mmconfig_map_resource(NULL, cfg);
> +		n++;
> +	}
> +
> +	pr_info(PREFIX " MCFG table loaded %d entries\n", n);
> +}
> diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
> index 7494dbe..97aa9d3 100644
> --- a/drivers/xen/pci.c
> +++ b/drivers/xen/pci.c
> @@ -27,9 +27,6 @@
>  #include <asm/xen/hypervisor.h>
>  #include <asm/xen/hypercall.h>
>  #include "../pci/pci.h"
> -#ifdef CONFIG_PCI_MMCONFIG
> -#include <asm/pci_x86.h>
> -#endif
>  
>  static bool __read_mostly pci_seg_supported = true;
>  
> @@ -221,7 +218,7 @@ static int __init xen_mcfg_late(void)
>  	if (!xen_initial_domain())
>  		return 0;
>  
> -	if ((pci_probe & PCI_PROBE_MMCONF) == 0)
> +	if (!pci_mmconfig_enabled())
>  		return 0;
>  
>  	if (list_empty(&pci_mmcfg_list))
> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
> index 89ab057..e9450ef 100644
> --- a/include/linux/pci-acpi.h
> +++ b/include/linux/pci-acpi.h
> @@ -106,6 +106,39 @@ extern const u8 pci_acpi_dsm_uuid[];
>  #define RESET_DELAY_DSM		0x08
>  #define FUNCTION_DELAY_DSM	0x09
>  
> +/* common API to maintain list of MCFG regions */
> +/* "PCI MMCONFIG %04x [bus %02x-%02x]" */
> +#define PCI_MMCFG_RESOURCE_NAME_LEN (22 + 4 + 2 + 2)
> +
> +struct pci_mmcfg_region {
> +	struct list_head list;
> +	struct resource res;
> +	u64 address;
> +	char __iomem *virt;
> +	u16 segment;
> +	u8 start_bus;
> +	u8 end_bus;
> +	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
> +};
> +
> +extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
> +			       phys_addr_t addr);
> +extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
> +
> +extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
> +extern struct pci_mmcfg_region *pci_mmconfig_add(int segment, int start,
> +							int end, u64 addr);
> +extern int pci_mmconfig_map_resource(struct device *dev,
> +	struct pci_mmcfg_region *mcfg);
> +extern void pci_mmconfig_unmap_resource(struct pci_mmcfg_region *mcfg);
> +extern int pci_mmconfig_enabled(void);
> +extern int __init pci_mmconfig_parse_table(void);
> +
> +extern struct list_head pci_mmcfg_list;
> +
> +#define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
> +#define PCI_MMCFG_OFFSET(bus, devfn)   ((bus) << 20 | (devfn) << 12)
> +
>  #else	/* CONFIG_ACPI */
>  static inline void acpi_pci_add_bus(struct pci_bus *bus) { }
>  static inline void acpi_pci_remove_bus(struct pci_bus *bus) { }
> -- 
> 1.9.1
> 


From broonie at kernel.org  Wed Feb 17 03:03:06 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Feb 2016 11:03:06 +0000
Subject: [PATCH 3/6] ASoC: rockchip: add bindings for rk3399 i2s
In-Reply-To: <1455673992-16469-4-git-send-email-jay.xu@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <1455673992-16469-4-git-send-email-jay.xu@rock-chips.com>
Message-ID: <20160217110306.GJ7544@sirena.org.uk>

On Wed, Feb 17, 2016 at 09:53:09AM +0800, jianqun.xu wrote:

> ---
>  Documentation/devicetree/bindings/sound/rockchip-i2s.txt | 1 +
>  1 file changed, 1 insertion(+)

As with the other patch I'd expect to see a matching driver update if
only for documentation purposes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/ce584e1d/attachment.sig>

From jbe at pengutronix.de  Wed Feb 17 03:10:14 2016
From: jbe at pengutronix.de (Juergen Borleis)
Date: Wed, 17 Feb 2016 12:10:14 +0100
Subject: Using i.MX6 quad's IPU#1/DI#1 to drive parallel port #1 failed
Message-ID: <201602171210.14545.jbe@pengutronix.de>

Hi,

someone here who has a working display (or similar) connected to i.MX6 quad's 
parallel port #1 and driven by IPU#1/DI#1? It seems there is currently no user 
in the mainline supported boards.

In my application the RGB data signals seem present, HSYNC and VSYNC as well 
(with the expected timing), but the display clock and the DE signals are 
missing. We already double checked the pin muxing and the physical connection 
(for example muxing the clock pad to be a GPIO works as expected).

Are there any known restrictions?

Thanks in advance.
Juergen


From marc.zyngier at arm.com  Wed Feb 17 03:27:43 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 11:27:43 +0000
Subject: [PATCH 6/6] ARM64: dts: rockchip: add core dtsi file for rk3399
In-Reply-To: <1455674476-16655-1-git-send-email-jay.xu@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <1455674476-16655-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <56C4592F.4080608@arm.com>

Hi Xu,

On 17/02/16 02:01, jianqun.xu wrote:
> From: Xu Jianqun <jay.xu at rock-chips.com>
> 
> Add dtsi file for Rockchip rk3399 SoCs, which includes some
> general nodes such as cpu, pmu, cru, gic, amba and so on.
> 
> Change-Id: Ie3b824e8ead967d4cb119d73222b7a198478c29c
> Signed-off-by: Xu Jianqun <jay.xu at rock-chips.com>
> ---
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 989 +++++++++++++++++++++++++++++++
>  1 file changed, 989 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> new file mode 100644
> index 0000000..eb671f6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi

[...]

> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts =
> +			<GIC_PPI 13
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			<GIC_PPI 14
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			<GIC_PPI 11
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			<GIC_PPI 10
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;

Please drop these GIC_CPU_MASK_SIMPLE from the interrupt specifiers,
they do not mean anything with GICv3.

> +		clock-frequency = <24000000>;

Are you sure you do need this? Can't your firmware be fixed to correctly
program CNTFRQ_EL0?

> +	};
> +
> +	xin24m: xin24m {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <24000000>;
> +		clock-output-names = "xin24m";
> +	};
> +
> +	gic: interrupt-controller at fee00000 {
> +		compatible = "arm,gic-v3";
> +		#interrupt-cells = <3>;
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +		interrupt-controller;
> +
> +		reg = <0x0 0xfee00000 0 0x10000>, /* GICD */
> +		      <0x0 0xfef00000 0 0xc0000>, /* GICR */
> +		      <0x0 0xfff00000 0 0x10000>, /* GICC */
> +		      <0x0 0xfff10000 0 0x10000>, /* GICH */
> +		      <0x0 0xfff20000 0 0x10000>; /* GICV */
> +		interrupts =
> +			<GIC_PPI 9
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;

Same remark about the mask.

> +		its: interrupt-controller at fee20000 {
> +			compatible = "arm,gic-v3-its";
> +			msi-controller;
> +			reg = <0x0 0xfee20000 0x0 0x20000>;
> +		};

Looks nice. Is there any peripheral capable of generating MSIs on this SoC?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From will.deacon at arm.com  Wed Feb 17 03:29:32 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 17 Feb 2016 11:29:32 +0000
Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <56C3AD1C.2000003@caviumnetworks.com>
References: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160214170152.GC3965@htj.duckdns.org>
 <56C147B2.9010303@caviumnetworks.com>
 <20160215183041.GH3965@htj.duckdns.org>
 <20160216144250.GD31343@rric.localdomain>
 <56C37524.5090000@caviumnetworks.com>
 <56C37AD3.4030407@caviumnetworks.com>
 <56C37D94.8080403@caviumnetworks.com>
 <20160216211410.GI25086@rric.localdomain>
 <56C3AD1C.2000003@caviumnetworks.com>
Message-ID: <20160217112931.GB31970@arm.com>

On Tue, Feb 16, 2016 at 03:13:32PM -0800, Tirumalesh Chalamarla wrote:
> On 02/16/2016 01:14 PM, Robert Richter wrote:
> >CONFIG_CAVIUM_ERRATUM_22536 is exactly that you need. It is not only
> >used for core interrupts, e.g. also for gicv3 devices (and now also
> >for ahci). Non-core errata (e.g. CONFIG_CAVIUM_ERRATUM_23144) are not
> >enabled in the arm64 cpu errata framework (not handled in
> >arch/arm64/kernel/cpu_errata.c).
> >
> >Thus,
> >
> >#ifdef CONFIG_CAVIUM_ERRATUM_22536
> >	if (pdev->vendor == 0x177d && pdev->device == 0xa01c)
> >		ahci_thunderx_init(&pdev->dev, hpriv);
> >#endif
> >
> >is the correct enablement of the workaround by device id.
> >
> >And, CAVIUM_ERRATUM_* is very easy to handle, enable and document.
> >
> The code will only run for Thunder and AHCI, becuase its PCI.

Well, the guards also serve as documentation for exactly why we're having
to do something special here, so I'd say go ahead and add
CONFIG_CAVIUM_ERRATUM_22536 and update
Documentation/arm64/silicon-errata.txt accordingly.



Will


From blogic at openwrt.org  Wed Feb 17 03:37:35 2016
From: blogic at openwrt.org (John Crispin)
Date: Wed, 17 Feb 2016 12:37:35 +0100
Subject: [PATCH V6 1/2] regulator: Add document for MT6323 regulator
Message-ID: <1455709056-50510-1-git-send-email-blogic@openwrt.org>

Signed-off-by: John Crispin <blogic at openwrt.org>
Cc: devicetree at vger.kernel.org

---
Changes in V6
* remove the compatible string

Changes in V5
* regulator vs regulators

Changes in V4
* regulator is a subnode and not a property

 .../bindings/regulator/mt6323-regulator.txt        |  241 ++++++++++++++++++++
 1 file changed, 241 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/mt6323-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
new file mode 100644
index 0000000..67c0780
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
@@ -0,0 +1,241 @@
+Mediatek MT6323 Regulator Driver
+
+All voltage regulators are defined as subnodes of the regulators node. A list
+of regulators provided by this controller are defined as subnodes of the
+drivers node. Each regulator is named according to its regulator type,
+buck_<name> and ldo_<name>. The definition for each of these nodes is defined
+using the standard binding for regulators at
+Documentation/devicetree/bindings/regulator/regulator.txt.
+
+The valid names for regulators are::
+BUCK:
+  buck_vproc, buck_vsys, buck_vpa
+LDO:
+  ldo_vtcxo, ldo_vcn28, ldo_vcn33_bt, ldo_vcn33_wifi, ldo_va, ldo_vcama,
+  ldo_vio28, ldo_vusb, ldo_vmc, ldo_vmch, ldo_vemc3v3, ldo_vgp1, ldo_vgp2,
+  ldo_vgp3, ldo_vcn18, ldo_vsim1, ldo_vsim2, ldo_vrtc, ldo_vcamaf, ldo_vibr,
+  ldo_vrf18, ldo_vm, ldo_vio18, ldo_vcamd, ldo_vcamio
+
+Example:
+
+	pmic: mt6323 {
+		compatible = "mediatek,mt6323";
+
+		mt6323regulator: regulators {
+			compatible = "mediatek,mt6323-regulator";
+
+			mt6323_vproc_reg: buck_vproc{
+				regulator-name = "vproc";
+				regulator-min-microvolt = < 700000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <12500>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vsys_reg: buck_vsys{
+				regulator-name = "vsys";
+				regulator-min-microvolt = <1400000>;
+				regulator-max-microvolt = <2987500>;
+				regulator-ramp-delay = <25000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vpa_reg: buck_vpa{
+				regulator-name = "vpa";
+				regulator-min-microvolt = < 500000>;
+				regulator-max-microvolt = <3650000>;
+			};
+
+			mt6323_vtcxo_reg: ldo_vtcxo{
+				regulator-name = "vtcxo";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <90>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcn28_reg: ldo_vcn28{
+				regulator-name = "vcn28";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <185>;
+			};
+
+			mt6323_vcn33_bt_reg: ldo_vcn33_bt{
+				regulator-name = "vcn33_bt";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3600000>;
+				regulator-enable-ramp-delay = <185>;
+			};
+
+			mt6323_vcn33_wifi_reg: ldo_vcn33_wifi{
+				regulator-name = "vcn33_wifi";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3600000>;
+				regulator-enable-ramp-delay = <185>;
+			};
+
+			mt6323_va_reg: ldo_va{
+				regulator-name = "va";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcama_reg: ldo_vcama{
+				regulator-name = "vcama";
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vio28_reg: ldo_vio28{
+				regulator-name = "vio28";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vusb_reg: ldo_vusb{
+				regulator-name = "vusb";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-boot-on;
+			};
+
+			mt6323_vmc_reg: ldo_vmc{
+				regulator-name = "vmc";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+				regulator-boot-on;
+			};
+
+			mt6323_vmch_reg: ldo_vmch{
+				regulator-name = "vmch";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+				regulator-boot-on;
+			};
+
+			mt6323_vemc3v3_reg: ldo_vemc3v3{
+				regulator-name = "vemc3v3";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+				regulator-boot-on;
+			};
+
+			mt6323_vgp1_reg: ldo_vgp1{
+				regulator-name = "vgp1";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vgp2_reg: ldo_vgp2{
+				regulator-name = "vgp2";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vgp3_reg: ldo_vgp3{
+				regulator-name = "vgp3";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vcn18_reg: ldo_vcn18{
+				regulator-name = "vcn18";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vsim1_reg: ldo_vsim1{
+				regulator-name = "vsim1";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vsim2_reg: ldo_vsim2{
+				regulator-name = "vsim2";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vrtc_reg: ldo_vrtc{
+				regulator-name = "vrtc";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcamaf_reg: ldo_vcamaf{
+				regulator-name = "vcamaf";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vibr_reg: ldo_vibr{
+				regulator-name = "vibr";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+			};
+
+			mt6323_vrf18_reg: ldo_vrf18{
+				regulator-name = "vrf18";
+				regulator-min-microvolt = <1825000>;
+				regulator-max-microvolt = <1825000>;
+				regulator-enable-ramp-delay = <187>;
+			};
+
+			mt6323_vm_reg: ldo_vm{
+				regulator-name = "vm";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vio18_reg: ldo_vio18{
+				regulator-name = "vio18";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcamd_reg: ldo_vcamd{
+				regulator-name = "vcamd";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vcamio_reg: ldo_vcamio{
+				regulator-name = "vcamio";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+		};
+	};
-- 
1.7.10.4


From blogic at openwrt.org  Wed Feb 17 03:37:36 2016
From: blogic at openwrt.org (John Crispin)
Date: Wed, 17 Feb 2016 12:37:36 +0100
Subject: [PATCH V6 2/2] regulator: mt6323: Add support for MT6323 regulator
In-Reply-To: <1455709056-50510-1-git-send-email-blogic@openwrt.org>
References: <1455709056-50510-1-git-send-email-blogic@openwrt.org>
Message-ID: <1455709056-50510-2-git-send-email-blogic@openwrt.org>

From: Chen Zhong <chen.zhong at mediatek.com>

The MT6323 is a regulator found on boards based on MediaTek MT7623 and
probably other SoCs. It is a so called pmic and connects as a slave to
SoC using SPI, wrapped inside the pmic-wrapper.

Signed-off-by: Chen Zhong <chen.zhong at mediatek.com>
Signed-off-by: John Crispin <blogic at openwrt.org>

---
Changes in V6
* add back the set/get mode callbacks

Changes in V5
* remove the code that modifies constraints
* remove the code allows mode changes

Changes in V4:
* add id_table and of_match_table
* use short GPL text
* change MODULE_LICENSE to GPL V2

Changes in V3:
* none

Changes in V2:
* send to the the proper maintainer

 drivers/regulator/Kconfig                  |    9 +
 drivers/regulator/Makefile                 |    1 +
 drivers/regulator/mt6323-regulator.c       |  432 ++++++++++++++++++++++++++++
 include/linux/regulator/mt6323-regulator.h |   52 ++++
 4 files changed, 494 insertions(+)
 create mode 100644 drivers/regulator/mt6323-regulator.c
 create mode 100644 include/linux/regulator/mt6323-regulator.h

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 8155e80..5e49568 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -462,6 +462,15 @@ config REGULATOR_MT6311
 	  This driver supports the control of different power rails of device
 	  through regulator interface.
 
+config REGULATOR_MT6323
+	tristate "MediaTek MT6323 PMIC"
+	depends on MFD_MT6397
+	help
+	  Say y here to select this option to enable the power regulator of
+	  MediaTek MT6323 PMIC.
+	  This driver supports the control of different power rails of device
+	  through regulator interface.
+
 config REGULATOR_MT6397
 	tristate "MediaTek MT6397 PMIC"
 	depends on MFD_MT6397
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 980b194..8fb55640 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
 obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
 obj-$(CONFIG_REGULATOR_MC13XXX_CORE) +=  mc13xxx-regulator-core.o
 obj-$(CONFIG_REGULATOR_MT6311) += mt6311-regulator.o
+obj-$(CONFIG_REGULATOR_MT6323)	+= mt6323-regulator.o
 obj-$(CONFIG_REGULATOR_MT6397)	+= mt6397-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
diff --git a/drivers/regulator/mt6323-regulator.c b/drivers/regulator/mt6323-regulator.c
new file mode 100644
index 0000000..28ebbda
--- /dev/null
+++ b/drivers/regulator/mt6323-regulator.c
@@ -0,0 +1,432 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Chen Zhong <chen.zhong at mediatek.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.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/mfd/mt6397/core.h>
+#include <linux/mfd/mt6323/registers.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/mt6323-regulator.h>
+#include <linux/regulator/of_regulator.h>
+
+#define MT6323_LDO_MODE_NORMAL	0
+#define MT6323_LDO_MODE_LP	1
+
+/*
+ * MT6323 regulators' information
+ *
+ * @desc: standard fields of regulator description.
+ * @qi: Mask for query enable signal status of regulators
+ * @vselon_reg: Register sections for hardware control mode of bucks
+ * @vselctrl_reg: Register for controlling the buck control mode.
+ * @vselctrl_mask: Mask for query buck's voltage control mode.
+ */
+struct mt6323_regulator_info {
+	struct regulator_desc desc;
+	u32 qi;
+	u32 vselon_reg;
+	u32 vselctrl_reg;
+	u32 vselctrl_mask;
+	u32 modeset_reg;
+	u32 modeset_mask;
+};
+
+#define MT6323_BUCK(match, vreg, min, max, step, volt_ranges, enreg,	\
+		vosel, vosel_mask, voselon, vosel_ctrl)			\
+[MT6323_ID_##vreg] = {							\
+	.desc = {							\
+		.name = #vreg,						\
+		.of_match = of_match_ptr(match),			\
+		.ops = &mt6323_volt_range_ops,				\
+		.type = REGULATOR_VOLTAGE,				\
+		.id = MT6323_ID_##vreg,					\
+		.owner = THIS_MODULE,					\
+		.n_voltages = (max - min)/step + 1,			\
+		.linear_ranges = volt_ranges,				\
+		.n_linear_ranges = ARRAY_SIZE(volt_ranges),		\
+		.vsel_reg = vosel,					\
+		.vsel_mask = vosel_mask,				\
+		.enable_reg = enreg,					\
+		.enable_mask = BIT(0),					\
+	},								\
+	.qi = BIT(13),							\
+	.vselon_reg = voselon,						\
+	.vselctrl_reg = vosel_ctrl,					\
+	.vselctrl_mask = BIT(1),					\
+}
+
+#define MT6323_LDO(match, vreg, ldo_volt_table, enreg, enbit, vosel,	\
+		vosel_mask, _modeset_reg, _modeset_mask)		\
+[MT6323_ID_##vreg] = {							\
+	.desc = {							\
+		.name = #vreg,						\
+		.of_match = of_match_ptr(match),			\
+		.ops = &mt6323_volt_table_ops,				\
+		.type = REGULATOR_VOLTAGE,				\
+		.id = MT6323_ID_##vreg,					\
+		.owner = THIS_MODULE,					\
+		.n_voltages = ARRAY_SIZE(ldo_volt_table),		\
+		.volt_table = ldo_volt_table,				\
+		.vsel_reg = vosel,					\
+		.vsel_mask = vosel_mask,				\
+		.enable_reg = enreg,					\
+		.enable_mask = BIT(enbit),				\
+	},								\
+	.qi = BIT(15),							\
+	.modeset_reg = _modeset_reg,					\
+	.modeset_mask = _modeset_mask,					\
+}
+
+#define MT6323_REG_FIXED(match, vreg, enreg, enbit, volt,		\
+		_modeset_reg, _modeset_mask)				\
+[MT6323_ID_##vreg] = {							\
+	.desc = {							\
+		.name = #vreg,						\
+		.of_match = of_match_ptr(match),			\
+		.ops = &mt6323_volt_fixed_ops,				\
+		.type = REGULATOR_VOLTAGE,				\
+		.id = MT6323_ID_##vreg,					\
+		.owner = THIS_MODULE,					\
+		.n_voltages = 1,					\
+		.enable_reg = enreg,					\
+		.enable_mask = BIT(enbit),				\
+		.min_uV = volt,						\
+	},								\
+	.qi = BIT(15),							\
+	.modeset_reg = _modeset_reg,					\
+	.modeset_mask = _modeset_mask,					\
+}
+
+static const struct regulator_linear_range buck_volt_range1[] = {
+	REGULATOR_LINEAR_RANGE(700000, 0, 0x7f, 6250),
+};
+
+static const struct regulator_linear_range buck_volt_range2[] = {
+	REGULATOR_LINEAR_RANGE(1400000, 0, 0x7f, 12500),
+};
+
+static const struct regulator_linear_range buck_volt_range3[] = {
+	REGULATOR_LINEAR_RANGE(500000, 0, 0x3f, 50000),
+};
+
+static const u32 ldo_volt_table1[] = {
+	3300000, 3400000, 3500000, 3600000,
+};
+
+static const u32 ldo_volt_table2[] = {
+	1500000, 1800000, 2500000, 2800000,
+};
+
+static const u32 ldo_volt_table3[] = {
+	1800000, 3300000,
+};
+
+static const u32 ldo_volt_table4[] = {
+	3000000, 3300000,
+};
+
+static const u32 ldo_volt_table5[] = {
+	1200000, 1300000, 1500000, 1800000, 2000000, 2800000, 3000000, 3300000,
+};
+
+static const u32 ldo_volt_table6[] = {
+	1200000, 1300000, 1500000, 1800000, 2500000, 2800000, 3000000, 2000000,
+};
+
+static const u32 ldo_volt_table7[] = {
+	1200000, 1300000, 1500000, 1800000,
+};
+
+static const u32 ldo_volt_table8[] = {
+	1800000, 3000000,
+};
+
+static const u32 ldo_volt_table9[] = {
+	1200000, 1350000, 1500000, 1800000,
+};
+
+static const u32 ldo_volt_table10[] = {
+	1200000, 1300000, 1500000, 1800000,
+};
+
+static int mt6323_get_status(struct regulator_dev *rdev)
+{
+	int ret;
+	u32 regval;
+	struct mt6323_regulator_info *info = rdev_get_drvdata(rdev);
+
+	ret = regmap_read(rdev->regmap, info->desc.enable_reg, &regval);
+	if (ret != 0) {
+		dev_err(&rdev->dev, "Failed to get enable reg: %d\n", ret);
+		return ret;
+	}
+
+	return (regval & info->qi) ? REGULATOR_STATUS_ON : REGULATOR_STATUS_OFF;
+}
+
+static int mt6323_ldo_set_mode(struct regulator_dev *rdev, unsigned int mode)
+{
+	int ret, val = 0;
+	struct mt6323_regulator_info *info = rdev_get_drvdata(rdev);
+
+	if (!info->modeset_mask) {
+		dev_err(&rdev->dev, "regulator %s doesn't support set_mode\n",
+			info->desc.name);
+		return -EINVAL;
+	}
+
+	switch (mode) {
+	case REGULATOR_MODE_STANDBY:
+		val = MT6323_LDO_MODE_LP;
+		break;
+	case REGULATOR_MODE_NORMAL:
+		val = MT6323_LDO_MODE_NORMAL;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	val <<= ffs(info->modeset_mask) - 1;
+
+	ret = regmap_update_bits(rdev->regmap, info->modeset_reg,
+				  info->modeset_mask, val);
+
+	return ret;
+}
+
+static unsigned int mt6323_ldo_get_mode(struct regulator_dev *rdev)
+{
+	unsigned int val;
+	unsigned int mode;
+	int ret;
+	struct mt6323_regulator_info *info = rdev_get_drvdata(rdev);
+
+	if (!info->modeset_mask) {
+		dev_err(&rdev->dev, "regulator %s doesn't support get_mode\n",
+			info->desc.name);
+		return -EINVAL;
+	}
+
+	ret = regmap_read(rdev->regmap, info->modeset_reg, &val);
+	if (ret < 0)
+		return ret;
+
+	val &= info->modeset_mask;
+	val >>= ffs(info->modeset_mask) - 1;
+
+	if (val & 0x1)
+		mode = REGULATOR_MODE_STANDBY;
+	else
+		mode = REGULATOR_MODE_NORMAL;
+
+	return mode;
+}
+
+static struct regulator_ops mt6323_volt_range_ops = {
+	.list_voltage = regulator_list_voltage_linear_range,
+	.map_voltage = regulator_map_voltage_linear_range,
+	.set_voltage_sel = regulator_set_voltage_sel_regmap,
+	.get_voltage_sel = regulator_get_voltage_sel_regmap,
+	.set_voltage_time_sel = regulator_set_voltage_time_sel,
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.is_enabled = regulator_is_enabled_regmap,
+	.get_status = mt6323_get_status,
+};
+
+static struct regulator_ops mt6323_volt_table_ops = {
+	.list_voltage = regulator_list_voltage_table,
+	.map_voltage = regulator_map_voltage_iterate,
+	.set_voltage_sel = regulator_set_voltage_sel_regmap,
+	.get_voltage_sel = regulator_get_voltage_sel_regmap,
+	.set_voltage_time_sel = regulator_set_voltage_time_sel,
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.is_enabled = regulator_is_enabled_regmap,
+	.get_status = mt6323_get_status,
+	.set_mode = mt6323_ldo_set_mode,
+	.get_mode = mt6323_ldo_get_mode,
+};
+
+static struct regulator_ops mt6323_volt_fixed_ops = {
+	.list_voltage = regulator_list_voltage_linear,
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.is_enabled = regulator_is_enabled_regmap,
+	.get_status = mt6323_get_status,
+	.set_mode = mt6323_ldo_set_mode,
+	.get_mode = mt6323_ldo_get_mode,
+};
+
+/* The array is indexed by id(MT6323_ID_XXX) */
+static struct mt6323_regulator_info mt6323_regulators[] = {
+	MT6323_BUCK("buck_vproc", VPROC, 700000, 1493750, 6250,
+		buck_volt_range1, MT6323_VPROC_CON7, MT6323_VPROC_CON9, 0x7f,
+		MT6323_VPROC_CON10, MT6323_VPROC_CON5),
+	MT6323_BUCK("buck_vsys", VSYS, 1400000, 2987500, 12500,
+		buck_volt_range2, MT6323_VSYS_CON7, MT6323_VSYS_CON9, 0x7f,
+		MT6323_VSYS_CON10, MT6323_VSYS_CON5),
+	MT6323_BUCK("buck_vpa", VPA, 500000, 3650000, 50000,
+		buck_volt_range3, MT6323_VPA_CON7, MT6323_VPA_CON9,
+		0x3f, MT6323_VPA_CON10, MT6323_VPA_CON5),
+	MT6323_REG_FIXED("ldo_vtcxo", VTCXO, MT6323_ANALDO_CON1, 10, 2800000,
+		MT6323_ANALDO_CON1, 0x2),
+	MT6323_REG_FIXED("ldo_vcn28", VCN28, MT6323_ANALDO_CON19, 12, 2800000,
+		MT6323_ANALDO_CON20, 0x2),
+	MT6323_LDO("ldo_vcn33_bt", VCN33_BT, ldo_volt_table1,
+		MT6323_ANALDO_CON16, 7, MT6323_ANALDO_CON16, 0xC,
+		MT6323_ANALDO_CON21, 0x2),
+	MT6323_LDO("ldo_vcn33_wifi", VCN33_WIFI, ldo_volt_table1,
+		MT6323_ANALDO_CON17, 12, MT6323_ANALDO_CON16, 0xC,
+		MT6323_ANALDO_CON21, 0x2),
+	MT6323_REG_FIXED("ldo_va", VA, MT6323_ANALDO_CON2, 14, 2800000,
+		MT6323_ANALDO_CON2, 0x2),
+	MT6323_LDO("ldo_vcama", VCAMA, ldo_volt_table2,
+		MT6323_ANALDO_CON4, 15, MT6323_ANALDO_CON10, 0x60, -1, 0),
+	MT6323_REG_FIXED("ldo_vio28", VIO28, MT6323_DIGLDO_CON0, 14, 2800000,
+		MT6323_DIGLDO_CON0, 0x2),
+	MT6323_REG_FIXED("ldo_vusb", VUSB, MT6323_DIGLDO_CON2, 14, 3300000,
+		MT6323_DIGLDO_CON2, 0x2),
+	MT6323_LDO("ldo_vmc", VMC, ldo_volt_table3,
+		MT6323_DIGLDO_CON3, 12, MT6323_DIGLDO_CON24, 0x10,
+		MT6323_DIGLDO_CON3, 0x2),
+	MT6323_LDO("ldo_vmch", VMCH, ldo_volt_table4,
+		MT6323_DIGLDO_CON5, 14, MT6323_DIGLDO_CON26, 0x80,
+		MT6323_DIGLDO_CON5, 0x2),
+	MT6323_LDO("ldo_vemc3v3", VEMC3V3, ldo_volt_table4,
+		MT6323_DIGLDO_CON6, 14, MT6323_DIGLDO_CON27, 0x80,
+		MT6323_DIGLDO_CON6, 0x2),
+	MT6323_LDO("ldo_vgp1", VGP1, ldo_volt_table5,
+		MT6323_DIGLDO_CON7, 15, MT6323_DIGLDO_CON28, 0xE0,
+		MT6323_DIGLDO_CON7, 0x2),
+	MT6323_LDO("ldo_vgp2", VGP2, ldo_volt_table6,
+		MT6323_DIGLDO_CON8, 15, MT6323_DIGLDO_CON29, 0xE0,
+		MT6323_DIGLDO_CON8, 0x2),
+	MT6323_LDO("ldo_vgp3", VGP3, ldo_volt_table7,
+		MT6323_DIGLDO_CON9, 15, MT6323_DIGLDO_CON30, 0x60,
+		MT6323_DIGLDO_CON9, 0x2),
+	MT6323_REG_FIXED("ldo_vcn18", VCN18, MT6323_DIGLDO_CON11, 14, 1800000,
+		MT6323_DIGLDO_CON11, 0x2),
+	MT6323_LDO("ldo_vsim1", VSIM1, ldo_volt_table8,
+		MT6323_DIGLDO_CON13, 15, MT6323_DIGLDO_CON34, 0x20,
+		MT6323_DIGLDO_CON13, 0x2),
+	MT6323_LDO("ldo_vsim2", VSIM2, ldo_volt_table8,
+		MT6323_DIGLDO_CON14, 15, MT6323_DIGLDO_CON35, 0x20,
+		MT6323_DIGLDO_CON14, 0x2),
+	MT6323_REG_FIXED("ldo_vrtc", VRTC, MT6323_DIGLDO_CON15, 8, 2800000,
+		-1, 0),
+	MT6323_LDO("ldo_vcamaf", VCAMAF, ldo_volt_table5,
+		MT6323_DIGLDO_CON31, 15, MT6323_DIGLDO_CON32, 0xE0,
+		MT6323_DIGLDO_CON31, 0x2),
+	MT6323_LDO("ldo_vibr", VIBR, ldo_volt_table5,
+		MT6323_DIGLDO_CON39, 15, MT6323_DIGLDO_CON40, 0xE0,
+		MT6323_DIGLDO_CON39, 0x2),
+	MT6323_REG_FIXED("ldo_vrf18", VRF18, MT6323_DIGLDO_CON45, 15, 1825000,
+		MT6323_DIGLDO_CON45, 0x2),
+	MT6323_LDO("ldo_vm", VM, ldo_volt_table9,
+		MT6323_DIGLDO_CON47, 14, MT6323_DIGLDO_CON48, 0x30,
+		MT6323_DIGLDO_CON47, 0x2),
+	MT6323_REG_FIXED("ldo_vio18", VIO18, MT6323_DIGLDO_CON49, 14, 1800000,
+		MT6323_DIGLDO_CON49, 0x2),
+	MT6323_LDO("ldo_vcamd", VCAMD, ldo_volt_table10,
+		MT6323_DIGLDO_CON51, 14, MT6323_DIGLDO_CON52, 0x60,
+		MT6323_DIGLDO_CON51, 0x2),
+	MT6323_REG_FIXED("ldo_vcamio", VCAMIO, MT6323_DIGLDO_CON53, 14, 1800000,
+		MT6323_DIGLDO_CON53, 0x2),
+};
+
+static int mt6323_set_buck_vosel_reg(struct platform_device *pdev)
+{
+	struct mt6397_chip *mt6323 = dev_get_drvdata(pdev->dev.parent);
+	int i;
+	u32 regval;
+
+	for (i = 0; i < MT6323_MAX_REGULATOR; i++) {
+		if (mt6323_regulators[i].vselctrl_reg) {
+			if (regmap_read(mt6323->regmap,
+				mt6323_regulators[i].vselctrl_reg,
+				&regval) < 0) {
+				dev_err(&pdev->dev,
+					"Failed to read buck ctrl\n");
+				return -EIO;
+			}
+
+			if (regval & mt6323_regulators[i].vselctrl_mask) {
+				mt6323_regulators[i].desc.vsel_reg =
+				mt6323_regulators[i].vselon_reg;
+			}
+		}
+	}
+
+	return 0;
+}
+
+static int mt6323_regulator_probe(struct platform_device *pdev)
+{
+	struct mt6397_chip *mt6323 = dev_get_drvdata(pdev->dev.parent);
+	struct regulator_config config = {};
+	struct regulator_dev *rdev;
+	int i;
+	u32 reg_value;
+
+	/* Query buck controller to select activated voltage register part */
+	if (mt6323_set_buck_vosel_reg(pdev))
+		return -EIO;
+
+	/* Read PMIC chip revision to update constraints and voltage table */
+	if (regmap_read(mt6323->regmap, MT6323_CID, &reg_value) < 0) {
+		dev_err(&pdev->dev, "Failed to read Chip ID\n");
+		return -EIO;
+	}
+	dev_info(&pdev->dev, "Chip ID = 0x%x\n", reg_value);
+
+	for (i = 0; i < MT6323_MAX_REGULATOR; i++) {
+		config.dev = &pdev->dev;
+		config.driver_data = &mt6323_regulators[i];
+		config.regmap = mt6323->regmap;
+		rdev = devm_regulator_register(&pdev->dev,
+				&mt6323_regulators[i].desc, &config);
+		if (IS_ERR(rdev)) {
+			dev_err(&pdev->dev, "failed to register %s\n",
+				mt6323_regulators[i].desc.name);
+			return PTR_ERR(rdev);
+		}
+	}
+	return 0;
+}
+
+static const struct platform_device_id mt6323_platform_ids[] = {
+	{"mt6323-regulator", 0},
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(platform, mt6323_platform_ids);
+
+static const struct of_device_id mt6323_of_match[] = {
+	{ .compatible = "mediatek,mt6323-regulator", },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mt6323_of_match);
+
+static struct platform_driver mt6323_regulator_driver = {
+	.driver = {
+		.name = "mt6323-regulator",
+		.of_match_table = of_match_ptr(mt6323_of_match),
+	},
+	.probe = mt6323_regulator_probe,
+	.id_table = mt6323_platform_ids,
+};
+
+module_platform_driver(mt6323_regulator_driver);
+
+MODULE_AUTHOR("Chen Zhong <chen.zhong at mediatek.com>");
+MODULE_DESCRIPTION("Regulator Driver for MediaTek MT6397 PMIC");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/regulator/mt6323-regulator.h b/include/linux/regulator/mt6323-regulator.h
new file mode 100644
index 0000000..67011cd
--- /dev/null
+++ b/include/linux/regulator/mt6323-regulator.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Chen Zhong <chen.zhong at mediatek.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.
+ */
+
+#ifndef __LINUX_REGULATOR_MT6323_H
+#define __LINUX_REGULATOR_MT6323_H
+
+enum {
+	MT6323_ID_VPROC = 0,
+	MT6323_ID_VSYS,
+	MT6323_ID_VPA,
+	MT6323_ID_VTCXO,
+	MT6323_ID_VCN28,
+	MT6323_ID_VCN33_BT,
+	MT6323_ID_VCN33_WIFI,
+	MT6323_ID_VA,
+	MT6323_ID_VCAMA,
+	MT6323_ID_VIO28 = 9,
+	MT6323_ID_VUSB,
+	MT6323_ID_VMC,
+	MT6323_ID_VMCH,
+	MT6323_ID_VEMC3V3,
+	MT6323_ID_VGP1,
+	MT6323_ID_VGP2,
+	MT6323_ID_VGP3,
+	MT6323_ID_VCN18,
+	MT6323_ID_VSIM1,
+	MT6323_ID_VSIM2,
+	MT6323_ID_VRTC,
+	MT6323_ID_VCAMAF,
+	MT6323_ID_VIBR,
+	MT6323_ID_VRF18,
+	MT6323_ID_VM,
+	MT6323_ID_VIO18,
+	MT6323_ID_VCAMD,
+	MT6323_ID_VCAMIO,
+	MT6323_ID_RG_MAX,
+};
+
+#define MT6323_MAX_REGULATOR	MT6323_ID_RG_MAX
+
+#endif /* __LINUX_REGULATOR_MT6323_H */
-- 
1.7.10.4


From xinliang.liu at linaro.org  Wed Feb 17 03:40:37 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Wed, 17 Feb 2016 19:40:37 +0800
Subject: [PATCH v4 03/11] drm/hisilicon: Add crtc driver for ADE
In-Reply-To: <56B874F5.8020103@codeaurora.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
 <1454729098-79807-4-git-send-email-xinliang.liu@linaro.org>
 <56B874F5.8020103@codeaurora.org>
Message-ID: <CAGd==06c+or8_d_z0NRyKhs86iEg=C5Bi6h6L3gV38EBzCEcBQ@mail.gmail.com>

On 8 February 2016 at 18:59, Archit Taneja <architt at codeaurora.org> wrote:
>
>
> On 02/06/2016 08:54 AM, Xinliang Liu wrote:
>>
>> Add crtc funcs and helper funcs for ADE.
>>
>> v4: None.
>> v3:
>> - Make ade as the master driver.
>> - Use port to connect with encoder.
>> - A few cleanup.
>> v2:
>> - Remove abtraction layer.
>>
>> Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
>> ---
>>   drivers/gpu/drm/hisilicon/kirin/Makefile        |   3 +-
>>   drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 280 +++++++++++++++
>>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 458
>> ++++++++++++++++++++++++
>>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  15 +
>>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |   8 +
>>   5 files changed, 763 insertions(+), 1 deletion(-)
>>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
>>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
>>
>> diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile
>> b/drivers/gpu/drm/hisilicon/kirin/Makefile
>> index cb346de47d48..2a61ab006ddb 100644
>> --- a/drivers/gpu/drm/hisilicon/kirin/Makefile
>> +++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
>> @@ -1,3 +1,4 @@
>> -kirin-drm-y := kirin_drm_drv.o
>> +kirin-drm-y := kirin_drm_drv.o \
>> +              kirin_drm_ade.o
>>
>>   obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
>> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
>> b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
>> new file mode 100644
>> index 000000000000..78020747abfe
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
>> @@ -0,0 +1,280 @@
>> +/*
>> + * Copyright (c) 2016 Linaro Limited.
>> + * Copyright (c) 2014-2016 Hisilicon Limited.
>> + *
>> + * 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.
>> + *
>> + */
>> +
>> +#ifndef __KIRIN_ADE_REG_H__
>> +#define __KIRIN_ADE_REG_H__
>> +
>> +/*
>> + * ADE Registers
>> + */
>> +#define MASK(x)                                (BIT(x) - 1)
>> +
>> +#define ADE_CTRL                       0x0004
>> +#define FRM_END_START_OFST             0
>> +#define FRM_END_START_MASK             MASK(2)
>> +#define ADE_CTRL1                      0x008C
>> +#define AUTO_CLK_GATE_EN_OFST          0
>> +#define AUTO_CLK_GATE_EN               BIT(0)
>> +#define ADE_ROT_SRC_CFG                        0x0010
>> +#define ADE_DISP_SRC_CFG               0x0018
>> +#define ADE_WDMA2_SRC_CFG              0x001C
>> +#define ADE_SEC_OVLY_SRC_CFG           0x0020
>> +#define ADE_WDMA3_SRC_CFG              0x0024
>> +#define ADE_OVLY1_TRANS_CFG            0x002C
>> +#define ADE_EN                         0x0100
>> +#define ADE_DISABLE                    0
>> +#define ADE_ENABLE                     1
>> +#define INTR_MASK_CPU(x)               (0x0C10 + (x) * 0x4)
>> +#define ADE_FRM_DISGARD_CTRL           0x00A4
>> +/* reset and reload regs */
>> +#define ADE_SOFT_RST_SEL(x)            (0x0078 + (x) * 0x4)
>> +#define ADE_RELOAD_DIS(x)              (0x00AC + (x) * 0x4)
>> +#define RDMA_OFST                      0
>> +#define CLIP_OFST                      15
>> +#define SCL_OFST                       21
>> +#define CTRAN_OFST                     24
>> +#define OVLY_OFST                      37 /* 32+5 */
>> +/* channel regs */
>> +#define RD_CH_PE(x)                    (0x1000 + (x) * 0x80)
>> +#define RD_CH_CTRL(x)                  (0x1004 + (x) * 0x80)
>> +#define RD_CH_ADDR(x)                  (0x1008 + (x) * 0x80)
>> +#define RD_CH_SIZE(x)                  (0x100C + (x) * 0x80)
>> +#define RD_CH_STRIDE(x)                        (0x1010 + (x) * 0x80)
>> +#define RD_CH_SPACE(x)                 (0x1014 + (x) * 0x80)
>> +#define RD_CH_PARTIAL_SIZE(x)          (0x1018 + (x) * 0x80)
>> +#define RD_CH_PARTIAL_SPACE(x)         (0x101C + (x) * 0x80)
>> +#define RD_CH_EN(x)                    (0x1020 + (x) * 0x80)
>> +#define RD_CH_STATUS(x)                        (0x1024 + (x) * 0x80)
>> +#define RD_CH_DISP_CTRL                        0x1404
>> +#define RD_CH_DISP_ADDR                        0x1408
>> +#define RD_CH_DISP_SIZE                        0x140C
>> +#define RD_CH_DISP_STRIDE              0x1410
>> +#define RD_CH_DISP_SPACE               0x1414
>> +#define RD_CH_DISP_EN                  0x142C
>> +/* clip regs */
>> +#define ADE_CLIP_DISABLE(x)            (0x6800 + (x) * 0x100)
>> +#define ADE_CLIP_SIZE0(x)              (0x6804 + (x) * 0x100)
>> +#define ADE_CLIP_SIZE1(x)              (0x6808 + (x) * 0x100)
>> +#define ADE_CLIP_SIZE2(x)              (0x680C + (x) * 0x100)
>> +#define ADE_CLIP_CFG_OK(x)             (0x6810 + (x) * 0x100)
>> +/* scale regs */
>> +#define ADE_SCL1_MUX_CFG               0x000C
>> +#define ADE_SCL2_SRC_CFG               0x0014
>> +#define ADE_SCL3_MUX_CFG               0x0008
>> +#define ADE_SCL_CTRL(x)                        (0x3000 + (x) * 0x800)
>> +#define ADE_SCL_HSP(x)                 (0x3004 + (x) * 0x800)
>> +#define ADE_SCL_UV_HSP(x)              (0x3008 + (x) * 0x800)
>> +#define ADE_SCL_VSP(x)                 (0x300C + (x) * 0x800)
>> +#define ADE_SCL_UV_VSP(x)              (0x3010 + (x) * 0x800)
>> +#define ADE_SCL_ORES(x)                        (0x3014 + (x) * 0x800)
>> +#define ADE_SCL_IRES(x)                        (0x3018 + (x) * 0x800)
>> +#define ADE_SCL_START(x)               (0x301C + (x) * 0x800)
>> +#define ADE_SCL_ERR(x)                 (0x3020 + (x) * 0x800)
>> +#define ADE_SCL_PIX_OFST(x)            (0x3024 + (x) * 0x800)
>> +#define ADE_SCL_UV_PIX_OFST(x)         (0x3028 + (x) * 0x800)
>> +#define ADE_SCL_COEF_CLR(x)            (0x3030 + (x) * 0x800)
>> +#define ADE_SCL_HCOEF(x, m, n)         (0x3100 + (x) * 0x800 + \
>> +                                       12 * (m) + 4 * (n))
>> +#define ADE_SCL_VCOEF(x, i, j)         (0x340C + (x) * 0x800 + \
>> +                                       12 * (i) + 4 * (j))
>> +/* ctran regs */
>> +#define ADE_CTRAN5_TRANS_CFG           0x0040
>> +#define ADE_CTRAN_DIS(x)               (0x5004 + (x) * 0x100)
>> +#define CTRAN_BYPASS_ON                        1
>> +#define CTRAN_BYPASS_OFF               0
>> +#define ADE_CTRAN_MODE_CHOOSE(x)       (0x5008 + (x) * 0x100)
>> +#define ADE_CTRAN_STAT(x)              (0x500C + (x) * 0x100)
>> +#define ADE_CTRAN_CHDC0(x)             (0x5010 + (x) * 0x100)
>> +#define ADE_CTRAN_CHDC1(x)             (0x5014 + (x) * 0x100)
>> +#define ADE_CTRAN_CHDC2(x)             (0x5018 + (x) * 0x100)
>> +#define ADE_CTRAN_CHDC3(x)             (0x501C + (x) * 0x100)
>> +#define ADE_CTRAN_CHDC4(x)             (0x5020 + (x) * 0x100)
>> +#define ADE_CTRAN_CHDC5(x)             (0x5024 + (x) * 0x100)
>> +#define ADE_CTRAN_CSC0(x)              (0x5028 + (x) * 0x100)
>> +#define ADE_CTRAN_CSC1(x)              (0x502C + (x) * 0x100)
>> +#define ADE_CTRAN_CSC2(x)              (0x5030 + (x) * 0x100)
>> +#define ADE_CTRAN_CSC3(x)              (0x5034 + (x) * 0x100)
>> +#define ADE_CTRAN_CSC4(x)              (0x5038 + (x) * 0x100)
>> +#define ADE_CTRAN_IMAGE_SIZE(x)                (0x503C + (x) * 0x100)
>> +#define ADE_CTRAN_CFG_OK(x)            (0x5040 + (x) * 0x100)
>> +/* overlay regs */
>> +#define ADE_OVLY_ALPHA_ST              0x2000
>> +#define ADE_OVLY_CH_XY0(x)             (0x2004 + (x) * 4)
>> +#define ADE_OVLY_CH_XY1(x)             (0x2024 + (x) * 4)
>> +#define ADE_OVLY_CH_CTL(x)             (0x204C + (x) * 4)
>> +#define ADE_OVLY_OUTPUT_SIZE(x)                (0x2070 + (x) * 8)
>> +#define OUTPUT_XSIZE_OFST              16
>> +#define ADE_OVLY_BASE_COLOR(x)         (0x2074 + (x) * 8)
>> +#define ADE_OVLYX_CTL(x)               (0x209C + (x) * 4)
>> +#define ADE_OVLY_CTL                   0x0098
>> +#define CH_OVLY_SEL_OFST(x)            ((x) * 4)
>> +#define CH_OVLY_SEL_MASK               MASK(2)
>> +#define CH_OVLY_SEL_VAL(x)             ((x) + 1)
>> +#define CH_ALP_MODE_OFST               0
>> +#define CH_ALP_SEL_OFST                        2
>> +#define CH_UNDER_ALP_SEL_OFST          4
>> +#define CH_EN_OFST                     6
>> +#define CH_ALP_GBL_OFST                        15
>> +#define CH_SEL_OFST                    28
>> +
>> +/*
>> + * LDI Registers
>> + */
>> +#define LDI_HRZ_CTRL0                  0x7400
>> +#define HBP_OFST                       20
>> +#define LDI_HRZ_CTRL1                  0x7404
>> +#define LDI_VRT_CTRL0                  0x7408
>> +#define VBP_OFST                       20
>> +#define LDI_VRT_CTRL1                  0x740C
>> +#define LDI_PLR_CTRL                   0x7410
>> +#define FLAG_NVSYNC                    BIT(0)
>> +#define FLAG_NHSYNC                    BIT(1)
>> +#define FLAG_NPIXCLK                   BIT(2)
>> +#define FLAG_NDE                       BIT(3)
>> +#define LDI_DSP_SIZE                   0x7414
>> +#define VSIZE_OFST                     20
>> +#define LDI_INT_EN                     0x741C
>> +#define FRAME_END_INT_EN_OFST          1
>> +#define LDI_CTRL                       0x7420
>> +#define BPP_OFST                       3
>> +#define DATA_GATE_EN                   BIT(2)
>> +#define LDI_EN                         BIT(0)
>> +#define LDI_ORG_INT                    0x7424
>> +#define LDI_MSK_INT                    0x7428
>> +#define LDI_INT_CLR                    0x742C
>> +#define LDI_WORK_MODE                  0x7430
>> +#define LDI_DE_SPACE_LOW               0x7438
>> +#define LDI_MCU_INTS                   0x7450
>> +#define LDI_MCU_INTE                   0x7454
>> +#define LDI_MCU_INTC                   0x7458
>> +#define LDI_HDMI_DSI_GT                        0x7434
>> +
>> +/*
>> + * media regs
>> + */
>> +#define SC_MEDIA_RSTDIS                                0x0530
>> +#define SC_MEDIA_RSTEN                         0x052C
>> +#define NOC_ADE0_QOSGENERATOR_MODE             0x010C
>> +#define NOC_ADE0_QOSGENERATOR_EXTCONTROL       0x0118
>> +#define NOC_ADE1_QOSGENERATOR_MODE             0x020C
>> +#define NOC_ADE1_QOSGENERATOR_EXTCONTROL       0x0218
>> +
>> +/*
>> + * ADE regs relevant enums
>> + */
>> +enum frame_end_start {
>> +       /* regs take effective in every vsync */
>> +       REG_EFFECTIVE_IN_VSYNC = 0,
>> +       /* regs take effective in fist ade en and every frame end */
>> +       REG_EFFECTIVE_IN_ADEEN_FRMEND,
>> +       /* regs take effective in ade en immediately */
>> +       REG_EFFECTIVE_IN_ADEEN,
>> +       /* regs take effective in first vsync and every frame end */
>> +       REG_EFFECTIVE_IN_VSYNC_FRMEND
>> +};
>> +
>> +enum ade_fb_format {
>> +       ADE_RGB_565 = 0,
>> +       ADE_BGR_565,
>> +       ADE_XRGB_8888,
>> +       ADE_XBGR_8888,
>> +       ADE_ARGB_8888,
>> +       ADE_ABGR_8888,
>> +       ADE_RGBA_8888,
>> +       ADE_BGRA_8888,
>> +       ADE_RGB_888,
>> +       ADE_BGR_888 = 9,
>> +       ADE_FORMAT_NOT_SUPPORT = 800
>> +};
>> +
>> +enum ade_channel {
>> +       ADE_CH1 = 0,    /* channel 1 for primary plane */
>> +       ADE_CH_NUM
>> +};
>> +
>> +enum ade_scale {
>> +       ADE_SCL1 = 0,
>> +       ADE_SCL2,
>> +       ADE_SCL3,
>> +       ADE_SCL_NUM
>> +};
>> +
>> +enum ade_ctran {
>> +       ADE_CTRAN1 = 0,
>> +       ADE_CTRAN2,
>> +       ADE_CTRAN3,
>> +       ADE_CTRAN4,
>> +       ADE_CTRAN5,
>> +       ADE_CTRAN6,
>> +       ADE_CTRAN_NUM
>> +};
>> +
>> +enum ade_overlay {
>> +       ADE_OVLY1 = 0,
>> +       ADE_OVLY2,
>> +       ADE_OVLY3,
>> +       ADE_OVLY_NUM
>> +};
>> +
>> +enum ade_alpha_mode {
>> +       ADE_ALP_GLOBAL = 0,
>> +       ADE_ALP_PIXEL,
>> +       ADE_ALP_PIXEL_AND_GLB
>> +};
>> +
>> +enum ade_alpha_blending_mode {
>> +       ADE_ALP_MUL_COEFF_0 = 0,        /* alpha */
>> +       ADE_ALP_MUL_COEFF_1,            /* 1-alpha */
>> +       ADE_ALP_MUL_COEFF_2,            /* 0 */
>> +       ADE_ALP_MUL_COEFF_3             /* 1 */
>> +};
>> +
>> +/*
>> + * LDI regs relevant enums
>> + */
>> +enum dsi_pclk_en {
>> +       DSI_PCLK_ON = 0,
>> +       DSI_PCLK_OFF
>> +};
>> +
>> +enum ldi_output_format {
>> +       LDI_OUT_RGB_565 = 0,
>> +       LDI_OUT_RGB_666,
>> +       LDI_OUT_RGB_888
>> +};
>> +
>> +enum ldi_work_mode {
>> +       TEST_MODE = 0,
>> +       NORMAL_MODE
>> +};
>> +
>> +enum ldi_input_source {
>> +       DISP_SRC_NONE = 0,
>> +       DISP_SRC_OVLY2,
>> +       DISP_SRC_DISP,
>> +       DISP_SRC_ROT,
>> +       DISP_SRC_SCL2
>> +};
>> +
>> +/*
>> + * Register Write/Read Helper functions
>> + */
>> +static inline void ade_update_bits(void __iomem *addr, u32 bit_start,
>> +                                  u32 mask, u32 val)
>> +{
>> +       u32 tmp, orig;
>> +
>> +       orig = readl(addr);
>> +       tmp = orig & ~(mask << bit_start);
>> +       tmp |= (val & mask) << bit_start;
>> +       writel(tmp, addr);
>> +}
>> +
>> +#endif
>> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
>> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
>> new file mode 100644
>> index 000000000000..b45149616716
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
>> @@ -0,0 +1,458 @@
>> +/*
>> + * Hisilicon Hi6220 SoC ADE(Advanced Display Engine)'s crtc&plane driver
>> + *
>> + * Copyright (c) 2016 Linaro Limited.
>> + * Copyright (c) 2014-2016 Hisilicon Limited.
>> + *
>> + * Author:
>> + *     Xinliang Liu <z.liuxinliang at hisilicon.com>
>> + *     Xinliang Liu <xinliang.liu at linaro.org>
>> + *     Xinwei Kong <kong.kongxinwei at hisilicon.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.
>> + *
>> + */
>> +
>> +#include <linux/bitops.h>
>> +#include <linux/clk.h>
>> +#include <video/display_timing.h>
>> +
>> +#include <drm/drmP.h>
>> +#include <drm/drm_crtc.h>
>> +#include <drm/drm_crtc_helper.h>
>> +#include <drm/drm_atomic.h>
>> +#include <drm/drm_atomic_helper.h>
>> +
>> +#include "kirin_drm_drv.h"
>> +#include "kirin_ade_reg.h"
>> +
>> +#define to_ade_crtc(crtc) \
>> +       container_of(crtc, struct ade_crtc, base)
>> +
>> +struct ade_hw_ctx {
>> +       void __iomem  *base;
>> +       void __iomem  *media_base;
>> +       void __iomem  *media_noc_base;
>> +       int irq;
>> +       struct clk *ade_core_clk;
>> +       struct clk *media_noc_clk;
>> +       struct clk *ade_pix_clk;
>> +       bool power_on;
>> +};
>> +
>> +struct ade_crtc {
>> +       struct drm_crtc base;
>> +       struct ade_hw_ctx *ctx;
>> +       bool enable;
>> +       u32 out_format;
>> +};
>> +
>> +struct ade_data {
>> +       struct ade_crtc acrtc;
>> +       struct ade_hw_ctx ctx;
>> +};
>> +
>> +static void ade_update_reload_bit(void __iomem *base, u32 bit_num, u32
>> val)
>> +{
>> +       u32 bit_ofst, reg_num;
>> +
>> +       bit_ofst = bit_num % 32;
>> +       reg_num = bit_num / 32;
>> +
>> +       ade_update_bits(base + ADE_RELOAD_DIS(reg_num), bit_ofst,
>> +                       MASK(1), !!val);
>> +}
>> +
>> +static u32 ade_read_reload_bit(void __iomem *base, u32 bit_num)
>> +{
>> +       u32 tmp, bit_ofst, reg_num;
>> +
>> +       bit_ofst = bit_num % 32;
>> +       reg_num = bit_num / 32;
>> +
>> +       tmp = readl(base + ADE_RELOAD_DIS(reg_num));
>> +       return !!(BIT(bit_ofst) & tmp);
>> +}
>> +
>> +static void ade_init(struct ade_hw_ctx *ctx)
>> +{
>> +       void __iomem *base = ctx->base;
>> +
>> +       /* enable clk gate */
>> +       ade_update_bits(base + ADE_CTRL1, AUTO_CLK_GATE_EN_OFST,
>> +                       AUTO_CLK_GATE_EN, ADE_ENABLE);
>> +       /* clear overlay */
>> +       writel(0, base + ADE_OVLY1_TRANS_CFG);
>> +       writel(0, base + ADE_OVLY_CTL);
>> +       writel(0, base + ADE_OVLYX_CTL(ADE_OVLY2));
>> +       /* clear reset and reload regs */
>> +       writel(MASK(32), base + ADE_SOFT_RST_SEL(0));
>> +       writel(MASK(32), base + ADE_SOFT_RST_SEL(1));
>> +       writel(MASK(32), base + ADE_RELOAD_DIS(0));
>> +       writel(MASK(32), base + ADE_RELOAD_DIS(1));
>> +       /* for video mode, that ade registers
>> +        * became effective at frame end
>> +        */
>> +       ade_update_bits(base + ADE_CTRL, FRM_END_START_OFST,
>> +                       FRM_END_START_MASK,
>> REG_EFFECTIVE_IN_ADEEN_FRMEND);
>> +}
>> +
>> +static void ade_ldi_set_mode(struct ade_crtc *acrtc,
>> +                            struct drm_display_mode *mode,
>> +                            struct drm_display_mode *adj_mode)
>> +{
>> +       struct ade_hw_ctx *ctx = acrtc->ctx;
>> +       void __iomem *base = ctx->base;
>> +       u32 width = mode->hdisplay;
>> +       u32 height = mode->vdisplay;
>> +       u32 hfp, hbp, hsw, vfp, vbp, vsw;
>> +       u32 plr_flags;
>> +       int ret;
>> +
>> +       plr_flags = (mode->flags & DRM_MODE_FLAG_NVSYNC) ? FLAG_NVSYNC :
>> 0;
>> +       plr_flags |= (mode->flags & DRM_MODE_FLAG_NHSYNC) ? FLAG_NHSYNC :
>> 0;
>> +       hfp = mode->hsync_start - mode->hdisplay;
>> +       hbp = mode->htotal - mode->hsync_end;
>> +       hsw = mode->hsync_end - mode->hsync_start;
>> +       vfp = mode->vsync_start - mode->vdisplay;
>> +       vbp = mode->vtotal - mode->vsync_end;
>> +       vsw = mode->vsync_end - mode->vsync_start;
>> +       if (vsw > 15) {
>> +               DRM_DEBUG_DRIVER("vsw exceeded 15\n");
>> +               vsw = 15;
>> +       }
>> +
>> +       writel((hbp << HBP_OFST) | hfp, base + LDI_HRZ_CTRL0);
>> +        /* the configured value is actual value - 1 */
>> +       writel(hsw - 1, base + LDI_HRZ_CTRL1);
>> +       writel((vbp << VBP_OFST) | vfp, base + LDI_VRT_CTRL0);
>> +        /* the configured value is actual value - 1 */
>> +       writel(vsw - 1, base + LDI_VRT_CTRL1);
>> +        /* the configured value is actual value - 1 */
>> +       writel(((height - 1) << VSIZE_OFST) | (width - 1),
>> +              base + LDI_DSP_SIZE);
>> +       writel(plr_flags, base + LDI_PLR_CTRL);
>> +
>> +       /* Success should be guaranteed in mode_valid call back,
>> +        * so failer shouldn't happen here
>> +        */
>> +       ret = clk_set_rate(ctx->ade_pix_clk, mode->clock * 1000);
>> +       if (ret)
>> +               DRM_ERROR("failed to set pixel clk %dHz (%d)\n",
>> +                         mode->clock * 1000, ret);
>> +       adj_mode->clock = clk_get_rate(ctx->ade_pix_clk) / 1000;
>> +
>> +       /* ctran6 setting */
>> +       writel(CTRAN_BYPASS_ON, base + ADE_CTRAN_DIS(ADE_CTRAN6));
>> +        /* the configured value is actual value - 1 */
>> +       writel(width * height - 1, base +
>> ADE_CTRAN_IMAGE_SIZE(ADE_CTRAN6));
>> +       ade_update_reload_bit(base, CTRAN_OFST + ADE_CTRAN6, 0);
>> +
>> +       DRM_DEBUG_DRIVER("set mode: %dx%d\n", width, height);
>> +}
>> +
>> +static int ade_power_up(struct ade_hw_ctx *ctx)
>> +{
>> +       void __iomem *media_base = ctx->media_base;
>> +       int ret;
>> +
>> +       ret = clk_prepare_enable(ctx->media_noc_clk);
>> +       if (ret) {
>> +               DRM_ERROR("failed to enable media_noc_clk (%d)\n", ret);
>> +               return ret;
>> +       }
>> +
>> +       writel(0x20, media_base + SC_MEDIA_RSTDIS);
>
>
> If this and the write in ade_power_down are to reset the
> ADE block, they should ideally belong to clock/reset subsystem
> and not touched by the driver.

yes, this is to reset ADE block.
you are right! will use reset subsystem to do the reset in v5.
Thanks for letting me know about this.

>
>
>> +
>> +       ret = clk_prepare_enable(ctx->ade_core_clk);
>> +       if (ret) {
>> +               DRM_ERROR("failed to enable ade_core_clk (%d)\n", ret);
>> +               return ret;
>> +       }
>> +
>> +       ade_init(ctx);
>> +       ctx->power_on = true;
>> +       return 0;
>> +}
>> +
>> +static void ade_power_down(struct ade_hw_ctx *ctx)
>> +{
>> +       void __iomem *base = ctx->base;
>> +       void __iomem *media_base = ctx->media_base;
>> +
>> +       writel(ADE_DISABLE, base + LDI_CTRL);
>> +       /* dsi pixel off */
>> +       writel(DSI_PCLK_OFF, base + LDI_HDMI_DSI_GT);
>> +
>> +       clk_disable_unprepare(ctx->ade_core_clk);
>> +       writel(0x20, media_base + SC_MEDIA_RSTEN);
>> +       clk_disable_unprepare(ctx->media_noc_clk);
>> +       ctx->power_on = false;
>> +}
>> +
>> +static void ade_set_medianoc_qos(struct ade_crtc *acrtc)
>> +{
>> +       struct ade_hw_ctx *ctx = acrtc->ctx;
>> +       void __iomem *base = ctx->media_noc_base;
>> +       void __iomem *reg;
>> +       u32 val;
>> +
>> +       reg = base + NOC_ADE0_QOSGENERATOR_MODE;
>> +       val = (readl(reg) & 0xfffffffc) | 0x2;
>> +       writel(val, reg);
>> +
>> +       reg = base + NOC_ADE0_QOSGENERATOR_EXTCONTROL;
>> +       val = readl(reg) | 0x1;
>> +       writel(val, reg);
>> +
>> +       reg = base + NOC_ADE1_QOSGENERATOR_MODE;
>> +       val = (readl(reg) & 0xfffffffc) | 0x2;
>> +       writel(val, reg);
>> +
>> +       reg = base + NOC_ADE1_QOSGENERATOR_EXTCONTROL;
>> +       val = readl(reg) | 0x1;
>> +       writel(val, reg);
>
>
> We could at least try to pass these via syscon, since we
> don't have a framework to configure NoC QoS stuff.

yes, it is better to write regs via syscon. Will fixed in v5.
Thanks for letting me know about this.

Thanks,
-xinliang

>
> Thanks,
> Archit
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation


From andre.przywara at arm.com  Wed Feb 17 03:43:53 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 17 Feb 2016 11:43:53 +0000
Subject: [PATCH v2 1/8] arm64: Introduce Allwinner SoC config option
In-Reply-To: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455709440-8668-2-git-send-email-andre.przywara@arm.com>

To prepare for the Allwinner A64 SoC support, introduce a config
option to allow compiling Allwinner (aka. sunxi) specific drivers
for the arm64 architecture as well.
This patch just defines the ARCH_SUNXI symbol to allow Allwinner
specific drivers to be selected during kernel configuration.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 arch/arm64/Kconfig.platforms | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 8a09522..2f7f69b 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -1,5 +1,10 @@
 menu "Platform selection"
 
+config ARCH_SUNXI
+	bool "Allwinner sunxi 64-bit SoC Family"
+	help
+	  This enables support for Allwinner sunxi based SoCs like the A64.
+
 config ARCH_BCM_IPROC
 	bool "Broadcom iProc SoC Family"
 	help
-- 
2.6.4



From andre.przywara at arm.com  Wed Feb 17 03:43:52 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 17 Feb 2016 11:43:52 +0000
Subject: [PATCH v2 0/8] arm64: Introduce Allwinner A64 and Pine64 support
Message-ID: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>

Hi,

this is an updated version of the Allwinner A64 / Pine64 support series.
It fixes several issues we saw and addresses most ;-) of the comments
I got. Several fixes have found their way into -next already, so I omit
them here. Many thanks to the diligent maintainers!
For a changelog see below.

This series provides initial support for the Allwinner A64 SoC,
which is based on four ARM Cortex-A53 cores implementing the ARMv8
64-bit architecture.
On top of this there is also initial support for the Pine64 board,
for which you can find more information and links in the linux-sunxi
Wiki [1].
The resulting kernel boots fine on my development samples I have
here, though the actual boot process is a bit involved at the moment.
You can find more information and a ready-to-flash image here [2].

Patch 1/8 enables the Allwinner/sunxi platform for the arm64
architecture, so one can select the required drivers during
configuration.
Patch 2/8 adds the pinctrl driver, which has been on the list before.
Patch 3 and 4 add a new generic driver for the bus clock gates which
relies on DT for providing the parent relationship. That makes adding
new SoCs much easier, since there should be no more kernel code
changes necessary.
Patch 5-7 add the new vendor name and the device tree files, the former
for the SoC itself, the latter for the Pine64 boards.
The final patch 8 updates defconfig, so that the generic arm64 kernel
supports the basic SoC drivers out of the box.

In the moment we support the basic peripherals like GIC, timer, clocks,
GPIOs, UARTs and (new in v2) I2C.
The MMC IP block has changed a bit compared to previous SoCs, so the
existing driver is not 100% compatible. However the default delays seem
to work fine for the SD cards, so I included all the necessary bits in
here, since working MMC makes this series indefinitely more usable.
We can fix both the MMC driver and the DT in a compatible way later.

Please have a look and comment on the patches. We might want to split
the series if some patches seem too controversial for being merged
soonish, please let me know if this is the case and I am happy to
rearrange the series.

The patches are based on next-20160217, which has some issues atm.
A working repo can be found over here[3].

Cheers,
Andre

Changelog v1 .. v2:
- Change the naming of DT nodes, identifiers and file names to include
  the wonderful Allwinner architecture prefix everywhere. You asked
  for it, you got it, enjoy!
- Drop SUNXI_MMC to be selected automatically, instead put it in the
  defconfig.
- Add a binding documentation for the new multi-bus-gates driver.
- Add a defconfig update patch.
- Lots of changes in the DTs, see the respective patches for details.

[1] http://linux-sunxi.org/Pine64
[2] https://github.com/apritzel/pine64
[3] https://github.com/apritzel/linux/commits/a64-v2beta

Andre Przywara (8):
  arm64: Introduce Allwinner SoC config option
  drivers: pinctrl: add driver for Allwinner A64 SoC
  DT: clk: sunxi: add binding doc for the multi-bus-gates clock
  clk: sunxi: add generic multi-parent bus clock gates driver
  arm64: dts: add Allwinner A64 SoC .dtsi
  of: add vendor prefix for Pine64
  arm64: dts: add Pine64 support
  arm64: add defconfig options for Allwinner SoCs

 Documentation/devicetree/bindings/arm/sunxi.txt    |   1 +
 Documentation/devicetree/bindings/clock/sunxi.txt  |   7 +
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 arch/arm64/Kconfig.platforms                       |   6 +
 arch/arm64/boot/dts/Makefile                       |   1 +
 arch/arm64/boot/dts/allwinner/Makefile             |   5 +
 .../dts/allwinner/sun50i-a64-pine64-common.dtsi    |  80 +++
 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  |  59 ++
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |  58 ++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      | 642 +++++++++++++++++++++
 arch/arm64/configs/defconfig                       |   7 +
 drivers/clk/sunxi/Makefile                         |   1 +
 drivers/clk/sunxi/clk-multi-gates.c                | 105 ++++
 drivers/pinctrl/sunxi/Kconfig                      |   4 +
 drivers/pinctrl/sunxi/Makefile                     |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c         | 606 +++++++++++++++++++
 17 files changed, 1585 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
 create mode 100644 drivers/clk/sunxi/clk-multi-gates.c
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c

-- 
2.6.4



From andre.przywara at arm.com  Wed Feb 17 03:43:55 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 17 Feb 2016 11:43:55 +0000
Subject: [PATCH v2 3/8] DT: clk: sunxi: add binding doc for the
 multi-bus-gates clock
In-Reply-To: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455709440-8668-4-git-send-email-andre.przywara@arm.com>

Recent Allwinner SoCs introduced a bus gates clock which can have
different parents for individual gates.
For the time being we encoded this relation in the driver.
This commit specifies a new binding which allows to encode this in
the DT by using a child node for each parent clock used. This allows
to specify any kind of relation efficiently and also keeps the very
same kernel driver for all SoCs at the same time.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 Documentation/devicetree/bindings/clock/sunxi.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index c09f59b..323af8e 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -79,6 +79,7 @@ Required properties:
 	"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
 	"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
 	"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
+	"allwinner,sunxi-multi-bus-gates-clk" - for the multi-parent bus gates
 
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
@@ -119,6 +120,11 @@ For "allwinner,sun6i-a31-pll6-clk", there are 2 outputs. The first output
 is the normal PLL6 output, or "pll6". The second output is rate doubled
 PLL6, or "pll6x2".
 
+The "allwinner,sunxi-multi-bus-gates-clk" holds the actual clocks in
+child nodes, where each one specifies the parent clock that the particular
+gates are depending from. The child nodes each follow the common clock
+binding as described in this document.
+
 The "allwinner,*-mmc-clk" clocks have three different outputs: the
 main clock, with the ID 0, and the output and sample clocks, with the
 IDs 1 and 2, respectively.
-- 
2.6.4



From andre.przywara at arm.com  Wed Feb 17 03:43:54 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 17 Feb 2016 11:43:54 +0000
Subject: [PATCH v2 2/8] drivers: pinctrl: add driver for Allwinner A64 SoC
In-Reply-To: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455709440-8668-3-git-send-email-andre.przywara@arm.com>

Based on the Allwinner A64 user manual and on the previous sunxi
pinctrl drivers this introduces the pin multiplex assignments for
the ARMv8 Allwinner A64 SoC.
Port A is apparently used for the fixed function DRAM controller, so
the ports start at B here (the manual mentions "n from 1 to 7", so
not starting at 0).

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 arch/arm64/Kconfig.platforms                       |   1 +
 drivers/pinctrl/sunxi/Kconfig                      |   4 +
 drivers/pinctrl/sunxi/Makefile                     |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c         | 606 +++++++++++++++++++++
 5 files changed, 613 insertions(+)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c

diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index 9213b27..08b2361 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -21,6 +21,7 @@ Required properties:
   "allwinner,sun9i-a80-r-pinctrl"
   "allwinner,sun8i-a83t-pinctrl"
   "allwinner,sun8i-h3-pinctrl"
+  "allwinner,sun50i-a64-pinctrl"
 
 - reg: Should contain the register physical address and length for the
   pin controller.
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 2f7f69b..d15c532 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -2,6 +2,7 @@ menu "Platform selection"
 
 config ARCH_SUNXI
 	bool "Allwinner sunxi 64-bit SoC Family"
+	select PINCTRL_SUN50I_A64
 	help
 	  This enables support for Allwinner sunxi based SoCs like the A64.
 
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index 1868b82..aaf075b 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -68,4 +68,8 @@ config PINCTRL_SUN9I_A80_R
 	depends on RESET_CONTROLLER
 	select PINCTRL_SUNXI
 
+config PINCTRL_SUN50I_A64
+	bool
+	select PINCTRL_SUNXI
+
 endif
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index f22de0e..2d8b64e 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_PINCTRL_SUN7I_A20)		+= pinctrl-sun7i-a20.o
 obj-$(CONFIG_PINCTRL_SUN8I_A23)		+= pinctrl-sun8i-a23.o
 obj-$(CONFIG_PINCTRL_SUN8I_A23_R)	+= pinctrl-sun8i-a23-r.o
 obj-$(CONFIG_PINCTRL_SUN8I_A33)		+= pinctrl-sun8i-a33.o
+obj-$(CONFIG_PINCTRL_SUN50I_A64)	+= pinctrl-sun50i-a64.o
 obj-$(CONFIG_PINCTRL_SUN8I_A83T)	+= pinctrl-sun8i-a83t.o
 obj-$(CONFIG_PINCTRL_SUN8I_H3)		+= pinctrl-sun8i-h3.o
 obj-$(CONFIG_PINCTRL_SUN8I_H3_R)	+= pinctrl-sun8i-h3-r.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c
new file mode 100644
index 0000000..20bd15b
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c
@@ -0,0 +1,606 @@
+/*
+ * Allwinner A64 SoCs pinctrl driver.
+ *
+ * Copyright (C) 2016 - ARM Ltd.
+ * Author: Andre Przywara <andre.przywara at arm.com>
+ *
+ * Based on pinctrl-sun7i-a20.c, which is:
+ * Copyright (C) 2014 Maxime Ripard <maxime.ripard at free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/pinctrl.h>
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin a64_pins[] = {
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* TX */
+		  SUNXI_FUNCTION(0x4, "jtag"),		/* MS0 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),	/* EINT0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* RX */
+		  SUNXI_FUNCTION(0x4, "jtag"),		/* CK0 */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* VCCEN */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),		/* EINT1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* RTS */
+		  SUNXI_FUNCTION(0x4, "jtag"),		/* DO0 */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* VPPEN */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),		/* EINT2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* CTS */
+		  SUNXI_FUNCTION(0x3, "i2s0"),		/* MCLK */
+		  SUNXI_FUNCTION(0x4, "jtag"),		/* DI0 */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* VPPPP */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),		/* EINT3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif2"),		/* SYNC */
+		  SUNXI_FUNCTION(0x3, "i2s0"),		/* SYNC */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* CLK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),		/* EINT4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif2"),		/* BCLK */
+		  SUNXI_FUNCTION(0x3, "i2s0"),		/* BCLK */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* DATA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),		/* EINT5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif2"),		/* DOUT */
+		  SUNXI_FUNCTION(0x3, "i2s0"),		/* DOUT */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* RST */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),		/* EINT6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif2"),		/* DIN */
+		  SUNXI_FUNCTION(0x3, "i2s0"),		/* DIN */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* DET */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),		/* EINT7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x4, "uart0"),		/* TX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),		/* EINT8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x4, "uart0"),		/* RX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),		/* EINT9 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NWE */
+		  SUNXI_FUNCTION(0x4, "spi0")),		/* MOSI */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NALE */
+		  SUNXI_FUNCTION(0x3, "mmc2"),		/* DS */
+		  SUNXI_FUNCTION(0x4, "spi0")),		/* MISO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCLE */
+		  SUNXI_FUNCTION(0x4, "spi0")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE1 */
+		  SUNXI_FUNCTION(0x4, "spi0")),		/* CS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NCE0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NRE# */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NRB0 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* CMD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NRB1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ0 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ1 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ2 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ3 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ4 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ5 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ6 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ7 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 16),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQS */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* RST */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D2 */
+		  SUNXI_FUNCTION(0x3, "uart3"),		/* TX */
+		  SUNXI_FUNCTION(0x4, "spi1"),		/* CS */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D3 */
+		  SUNXI_FUNCTION(0x3, "uart3"),		/* RX */
+		  SUNXI_FUNCTION(0x4, "spi1"),		/* CLK */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* DE */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D4 */
+		  SUNXI_FUNCTION(0x3, "uart4"),		/* TX */
+		  SUNXI_FUNCTION(0x4, "spi1"),		/* MOSI */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* HSYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D5 */
+		  SUNXI_FUNCTION(0x3, "uart4"),		/* RX */
+		  SUNXI_FUNCTION(0x4, "spi1"),		/* MISO */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* VSYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D6 */
+		  SUNXI_FUNCTION(0x3, "uart4"),		/* RTS */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D7 */
+		  SUNXI_FUNCTION(0x3, "uart4"),		/* CTS */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D10 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D11 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D12 */
+		  SUNXI_FUNCTION(0x4, "emac"),		/* ERXD3 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D13 */
+		  SUNXI_FUNCTION(0x4, "emac"),		/* ERXD2 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D14 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ERXD1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D15 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ERXD0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D18 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VP0 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ERXCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D19 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VN0 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ERXCTL */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 14),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D20 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VP1 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ENULL */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 15),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D21 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VN1 */
+		  SUNXI_FUNCTION(0x4, "emac"),		/* ETXD3 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 16),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D22 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VP2 */
+		  SUNXI_FUNCTION(0x4, "emac"),		/* ETXD2 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 17),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D23 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VN2 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ETXD1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 18),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VPC */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ETXD0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 19),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* DE */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VNC */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ETXCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 20),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* HSYNC */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VP3 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ETXCTL */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 21),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* VSYNC */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VN3 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ECLKIN */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 22),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "pwm"),		/* PWM0 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* EMDC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 23),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x4, "emac")),		/* EMDIO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 24),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* PCK */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* CK */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* ERR */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* HSYNC */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* SYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* VSYNC */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* DVLD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D0 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D1 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D2 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D3 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D4 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D5 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D6 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D7 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 14),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "pll"),		/* LOCK_DBG */
+		  SUNXI_FUNCTION(0x3, "i2c2")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 15),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x3, "i2c2")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 16),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 17),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D1 */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* MSI */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D0 */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* DI1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "uart0")),	/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* CMD */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* DO1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D3 */
+		  SUNXI_FUNCTION(0x4, "uart0")),	/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D2 */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* CK1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* CLK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 0)),	/* EINT0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* CMD */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 1)),	/* EINT1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D0 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 2)),	/* EINT2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D1 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 3)),	/* EINT3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D2 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 4)),	/* EINT4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D3 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 5)),	/* EINT5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart1"),		/* TX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 6)),	/* EINT6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart1"),		/* RX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 7)),	/* EINT7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart1"),		/* RTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 8)),	/* EINT8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart1"),		/* CTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 9)),	/* EINT9 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif3"),		/* SYNC */
+		  SUNXI_FUNCTION(0x3, "i2s1"),		/* SYNC */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 10)),	/* EINT10 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif3"),		/* BCLK */
+		  SUNXI_FUNCTION(0x3, "i2s1"),		/* BCLK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 11)),	/* EINT11 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif3"),		/* DOUT */
+		  SUNXI_FUNCTION(0x3, "i2s1"),		/* DOUT */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 12)),	/* EINT12 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif3"),		/* DIN */
+		  SUNXI_FUNCTION(0x3, "i2s1"),		/* DIN */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 13)),	/* EINT13 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c0"),		/* SCK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 0)),	/* EINT0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c0"),		/* SDA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 1)),	/* EINT1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c1"),		/* SCK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 2)),	/* EINT2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c1"),		/* SDA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 3)),	/* EINT3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart3"),		/* TX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 4)),	/* EINT4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart3"),		/* RX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 5)),	/* EINT5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart3"),		/* RTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 6)),	/* EINT6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart3"),		/* CTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 7)),	/* EINT7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "owa"),		/* OUT */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 8)),	/* EINT8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 9)),	/* EINT9 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mic"),		/* CLK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 10)),	/* EINT10 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mic"),		/* DATA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 11)),	/* EINT11 */
+};
+
+static const struct sunxi_pinctrl_desc a64_pinctrl_data = {
+	.pins = a64_pins,
+	.npins = ARRAY_SIZE(a64_pins),
+	.irq_banks = 3,
+};
+
+static int a64_pinctrl_probe(struct platform_device *pdev)
+{
+	return sunxi_pinctrl_init(pdev,
+				  &a64_pinctrl_data);
+}
+
+static const struct of_device_id a64_pinctrl_match[] = {
+	{ .compatible = "allwinner,sun50i-a64-pinctrl", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, a64_pinctrl_match);
+
+static struct platform_driver a64_pinctrl_driver = {
+	.probe	= a64_pinctrl_probe,
+	.driver	= {
+		.name		= "sun50i-a64-pinctrl",
+		.of_match_table	= a64_pinctrl_match,
+	},
+};
+module_platform_driver(a64_pinctrl_driver);
+
+MODULE_AUTHOR("Andre Przywara <andre.przywara at arm.com>");
+MODULE_DESCRIPTION("Allwinner A64 pinctrl driver");
+MODULE_LICENSE("GPL");
-- 
2.6.4



From andre.przywara at arm.com  Wed Feb 17 03:43:56 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 17 Feb 2016 11:43:56 +0000
Subject: [PATCH v2 4/8] clk: sunxi: add generic multi-parent bus clock gates
 driver
In-Reply-To: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455709440-8668-5-git-send-email-andre.przywara@arm.com>

The Allwinner H3 SoC introduced bus clock gates with potentially
different parents per clock gate. The H3 driver chose to hardcode the
actual parent clock relation in the code.
Add a new driver (which has the potential to drive the H3 and also
the simple clock gates as well) which uses the power of DT to describe
this relationship in an elegant and flexible way.
Using one subnode for every parent clock we get away with a single
DT compatible match, which can be used as a fallback value in the
actual DTs without the need to add specific compatible strings to the
code.  This avoids adding a new driver or function for every new SoC.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
Acked-by: Jean-Francois Moine <moinejf at free.fr>
---
 drivers/clk/sunxi/Makefile          |   1 +
 drivers/clk/sunxi/clk-multi-gates.c | 105 ++++++++++++++++++++++++++++++++++++
 2 files changed, 106 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk-multi-gates.c

diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 3fd7901..3a9dc31 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -11,6 +11,7 @@ obj-y += clk-a10-ve.o
 obj-y += clk-a20-gmac.o
 obj-y += clk-mod0.o
 obj-y += clk-simple-gates.o
+obj-y += clk-multi-gates.o
 obj-y += clk-sun8i-bus-gates.o
 obj-y += clk-sun8i-mbus.o
 obj-y += clk-sun9i-core.o
diff --git a/drivers/clk/sunxi/clk-multi-gates.c b/drivers/clk/sunxi/clk-multi-gates.c
new file mode 100644
index 0000000..76e715a
--- /dev/null
+++ b/drivers/clk/sunxi/clk-multi-gates.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ *
+ * Based on clk-sun8i-bus-gates.c, which is:
+ *  Copyright (C) 2015 Jens Kuske <jenskuske at gmail.com>
+ * Based on clk-simple-gates.c, which is:
+ *  Copyright 2015 Maxime Ripard <maxime.ripard at free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+
+static DEFINE_SPINLOCK(gates_lock);
+
+static void __init sunxi_parse_parent(struct device_node *node,
+				      struct clk_onecell_data *clk_data,
+				      void __iomem *reg)
+{
+	const char *parent = of_clk_get_parent_name(node, 0);
+	const char *clk_name;
+	struct property *prop;
+	struct clk *clk;
+	const __be32 *p;
+	int index, i = 0;
+
+	of_property_for_each_u32(node, "clock-indices", prop, p, index) {
+		of_property_read_string_index(node, "clock-output-names",
+					      i, &clk_name);
+
+		clk = clk_register_gate(NULL, clk_name, parent, 0,
+					reg + 4 * (index / 32), index % 32,
+					0, &gates_lock);
+		i++;
+		if (IS_ERR(clk)) {
+			pr_warn("could not register gate clock \"%s\"\n",
+				clk_name);
+			continue;
+		}
+		if (clk_data->clks[index])
+			pr_warn("bus-gate clock %s: index #%d already registered as %s\n",
+				clk_name, index, "?");
+		else
+			clk_data->clks[index] = clk;
+	}
+}
+
+static void __init sunxi_multi_bus_gates_init(struct device_node *node)
+{
+	struct clk_onecell_data *clk_data;
+	struct device_node *child;
+	struct property *prop;
+	struct resource res;
+	void __iomem *reg;
+	const __be32 *p;
+	int number = 0;
+	int index;
+
+	reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+	if (IS_ERR(reg))
+		return;
+
+	clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
+	if (!clk_data)
+		goto err_unmap;
+
+	for_each_child_of_node(node, child)
+		of_property_for_each_u32(child, "clock-indices", prop, p, index)
+			number = max(number, index);
+
+	clk_data->clks = kcalloc(number + 1, sizeof(struct clk *), GFP_KERNEL);
+	if (!clk_data->clks)
+		goto err_free_data;
+
+	for_each_child_of_node(node, child)
+		sunxi_parse_parent(child, clk_data, reg);
+
+	clk_data->clk_num = number + 1;
+	if (of_clk_add_provider(node, of_clk_src_onecell_get, clk_data))
+		pr_err("registering bus-gate clock %s failed\n", node->name);
+
+	return;
+
+err_free_data:
+	kfree(clk_data);
+err_unmap:
+	iounmap(reg);
+	of_address_to_resource(node, 0, &res);
+	release_mem_region(res.start, resource_size(&res));
+}
+
+CLK_OF_DECLARE(sunxi_multi_bus_gates, "allwinner,sunxi-multi-bus-gates-clk",
+	       sunxi_multi_bus_gates_init);
-- 
2.6.4



From andre.przywara at arm.com  Wed Feb 17 03:43:58 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 17 Feb 2016 11:43:58 +0000
Subject: [PATCH v2 6/8] of: add vendor prefix for Pine64
In-Reply-To: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455709440-8668-7-git-send-email-andre.przywara@arm.com>

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index af1c7a6..f514adb 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -177,6 +177,7 @@ parade	Parade Technologies Inc.
 pericom	Pericom Technology Inc.
 phytec	PHYTEC Messtechnik GmbH
 picochip	Picochip Ltd
+pine64	Pine64
 plathome	Plat'Home Co., Ltd.
 plda	PLDA
 pixcir  PIXCIR MICROELECTRONICS Co., Ltd
-- 
2.6.4



From andre.przywara at arm.com  Wed Feb 17 03:44:00 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 17 Feb 2016 11:44:00 +0000
Subject: [PATCH v2 8/8] arm64: add defconfig options for Allwinner SoCs
In-Reply-To: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455709440-8668-9-git-send-email-andre.przywara@arm.com>

With the Allwinner platform now supported, enable it in the defconfig
and add some options to give some decent out-of-the-box experience on
those SoCs.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
Will,

feel free to take this more as a reference than an actual patch.
I can either resend this later or you pick the respective options
yourself.

Cheers,
Andre.

 arch/arm64/configs/defconfig | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 91ae263..8aaa09a 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -30,6 +30,7 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_ARCH_SUNXI=y
 CONFIG_ARCH_BCM_IPROC=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_ARCH_EXYNOS7=y
@@ -138,6 +139,8 @@ CONFIG_SERIAL_XILINX_PS_UART=y
 CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
 CONFIG_VIRTIO_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_MV64XXX=y
 CONFIG_I2C_QUP=y
 CONFIG_I2C_UNIPHIER_F=y
 CONFIG_I2C_RCAR=y
@@ -147,6 +150,7 @@ CONFIG_SPI_QUP=y
 CONFIG_SPMI=y
 CONFIG_PINCTRL_MSM8916=y
 CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
+CONFIG_GPIO_SYSFS=y
 CONFIG_GPIO_PL061=y
 CONFIG_GPIO_RCAR=y
 CONFIG_GPIO_XGENE=y
@@ -191,8 +195,10 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_SDHCI_TEGRA=y
 CONFIG_MMC_SPI=y
+CONFIG_MMC_SUNXI=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_EXYNOS=y
+CONFIG_MMC_BLOCK_MINORS=16
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_SYSCON=y
@@ -202,6 +208,7 @@ CONFIG_LEDS_TRIGGER_CPU=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_EFI=y
 CONFIG_RTC_DRV_PL031=y
+CONFIG_RTC_DRV_SUN6I=y
 CONFIG_RTC_DRV_XGENE=y
 CONFIG_DMADEVICES=y
 CONFIG_QCOM_BAM_DMA=y
-- 
2.6.4



From andre.przywara at arm.com  Wed Feb 17 03:43:59 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 17 Feb 2016 11:43:59 +0000
Subject: [PATCH v2 7/8] arm64: dts: add Pine64 support
In-Reply-To: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455709440-8668-8-git-send-email-andre.przywara@arm.com>

The Pine64 is a cost-efficient development board based on the
Allwinner A64 SoC.
There are three models: the basic version with Fast Ethernet and
512 MB of DRAM (Pine64) and two Pine64+ versions, which both
feature Gigabit Ethernet and additional connectors for touchscreens
and a camera. Or as my son put it: "Those are smaller and these are
missing." ;-)
The two Pine64+ models just differ in the amount of DRAM
(1GB vs. 2GB). Since U-Boot will figure out the right size for us and
patches the DT accordingly we just need to provide one DT for the
Pine64+.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 arch/arm64/boot/dts/Makefile                       |  1 +
 arch/arm64/boot/dts/allwinner/Makefile             |  5 ++
 .../dts/allwinner/sun50i-a64-pine64-common.dtsi    | 80 ++++++++++++++++++++++
 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  | 59 ++++++++++++++++
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 58 ++++++++++++++++
 5 files changed, 203 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index f832b8a..3b7428a 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,3 +1,4 @@
+dts-dirs += allwinner
 dts-dirs += altera
 dts-dirs += amd
 dts-dirs += apm
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
new file mode 100644
index 0000000..1e29a5a
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
+
+always		:= $(dtb-y)
+subdir-y	:= $(dts-dirs)
+clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi
new file mode 100644
index 0000000..d5a7249
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi
@@ -0,0 +1,80 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun50i-a64.dtsi"
+
+/ {
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	soc {
+		reg_vcc3v3: vcc3v3 {
+			compatible = "regulator-fixed";
+			regulator-name = "vcc3v3";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+		};
+	};
+};
+
+&mmc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc0_pins>, <&mmc0_default_cd_pin>;
+	vmmc-supply = <&reg_vcc3v3>;
+	cd-gpios = <&pio 5 6 0>;
+	cd-inverted;
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins_a>;
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins>;
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
new file mode 100644
index 0000000..549dc15
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
@@ -0,0 +1,59 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64-pine64-common.dtsi"
+
+/ {
+	model = "Pine64+";
+	compatible = "pine64,pine64-plus", "allwinner,sun50i-a64";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	/* There is a model with 2GB of DRAM, but U-Boot fixes this for us. */
+	memory {
+		reg = <0x40000000 0x40000000>;
+	};
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
new file mode 100644
index 0000000..ebe029e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -0,0 +1,58 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64-pine64-common.dtsi"
+
+/ {
+	model = "Pine64";
+	compatible = "pine64,pine64", "allwinner,sun50i-a64";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory {
+		reg = <0x40000000 0x20000000>;
+	};
+};
-- 
2.6.4



From andre.przywara at arm.com  Wed Feb 17 03:43:57 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 17 Feb 2016 11:43:57 +0000
Subject: [PATCH v2 5/8] arm64: dts: add Allwinner A64 SoC .dtsi
In-Reply-To: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1455709440-8668-6-git-send-email-andre.przywara@arm.com>

The Allwinner A64 SoC is a low-cost chip with 4 ARM Cortex-A53 cores
and the typical tablet / TV box peripherals.
The SoC is based on the (32-bit) Allwinner H3 chip, sharing most of
the peripherals and the memory map.
Although the cores are proper 64-bit ones, the whole SoC is actually
limited to 4GB (including all the supported DRAM), so we use 32-bit
address and size cells. This has the nice feature of us being able to
reuse the DT for 32-bit kernels as well.
This .dtsi lists the hardware that we support so far.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 Documentation/devicetree/bindings/arm/sunxi.txt   |   1 +
 Documentation/devicetree/bindings/clock/sunxi.txt |   1 +
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi     | 642 ++++++++++++++++++++++
 3 files changed, 644 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi

diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
index 7e79fcc..7e59d8b 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,3 +14,4 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h3
   allwinner,sun9i-a80
+  allwinner,sun50i-a64
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index 323af8e..b7bd40d 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -80,6 +80,7 @@ Required properties:
 	"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
 	"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
 	"allwinner,sunxi-multi-bus-gates-clk" - for the multi-parent bus gates
+	"allwinner,sun50i-a64-bus-gates-clk" - for the bus gates on A64
 
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
new file mode 100644
index 0000000..b99f17a
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -0,0 +1,642 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ * based on the Allwinner H3 dtsi:
+ *    Copyright (C) 2015 Jens Kuske <jenskuske at gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+	interrupt-parent = <&gic>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <0>;
+			enable-method = "psci";
+		};
+
+		cpu at 1 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <1>;
+			enable-method = "psci";
+		};
+
+		cpu at 2 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <2>;
+			enable-method = "psci";
+		};
+
+		cpu at 3 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <3>;
+			enable-method = "psci";
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x40000000 0>;
+	};
+
+	gic: interrupt-controller at 01c81000 {
+		compatible = "arm,gic-400";
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+
+		reg = <0x01c81000 0x1000>,
+		      <0x01c82000 0x2000>,
+		      <0x01c84000 0x2000>,
+		      <0x01c86000 0x2000>;
+		interrupts = <GIC_PPI 9
+		      (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		osc24M: osc24M_clk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <24000000>;
+			clock-output-names = "osc24M";
+		};
+
+		osc32k: osc32k_clk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <32768>;
+			clock-output-names = "osc32k";
+		};
+
+		pll1: pll1_clk at 01c20000 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun8i-a23-pll1-clk";
+			reg = <0x01c20000 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll1";
+		};
+
+		pll6: pll6_clk at 01c20028 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun6i-a31-pll6-clk";
+			reg = <0x01c20028 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll6";
+		};
+
+		pll6x2: pll6x2_clk {
+			#clock-cells = <0>;
+			compatible = "fixed-factor-clock";
+			clock-mult = <2>;
+			clock-div = <1>;
+			clocks = <&pll6>;
+			clock-output-names = "pll6x2";
+		};
+
+		pll6d2: pll6d2_clk {
+			#clock-cells = <0>;
+			compatible = "fixed-factor-clock";
+			clock-div = <2>;
+			clock-mult = <1>;
+			clocks = <&pll6>;
+			clock-output-names = "pll6d2";
+		};
+
+		pll8: pll8_clk at 01c2002c {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun6i-a31-pll6-clk";
+			reg = <0x01c2002c 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll8";
+		};
+
+		pll8x2: pll8x2_clk {
+			#clock-cells = <0>;
+			compatible = "fixed-factor-clock";
+			clock-mult = <2>;
+			clock-div = <1>;
+			clocks = <&pll8>;
+			clock-output-names = "pll8x2";
+		};
+
+		cpu: cpu_clk at 01c20050 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-cpu-clk";
+			reg = <0x01c20050 0x4>;
+			clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
+			clock-output-names = "cpu";
+			critical-clocks = <0>;
+		};
+
+		axi: axi_clk at 01c20050 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-axi-clk";
+			reg = <0x01c20050 0x4>;
+			clocks = <&cpu>;
+			clock-output-names = "axi";
+		};
+
+		ahb1: ahb1_clk at 01c20054 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun6i-a31-ahb1-clk";
+			reg = <0x01c20054 0x4>;
+			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
+			clock-output-names = "ahb1";
+		};
+
+		ahb2: ahb2_clk at 01c2005c {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun8i-h3-ahb2-clk";
+			reg = <0x01c2005c 0x4>;
+			clocks = <&ahb1>, <&pll6d2>;
+			clock-output-names = "ahb2";
+		};
+
+		apb1: apb1_clk at 01c20054 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-apb0-clk";
+			reg = <0x01c20054 0x4>;
+			clocks = <&ahb1>;
+			clock-output-names = "apb1";
+		};
+
+		apb2: apb2_clk at 01c20058 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-apb1-clk";
+			reg = <0x01c20058 0x4>;
+			clocks = <&osc32k>, <&osc24M>, <&pll6x2>, <&pll6x2>;
+			clock-output-names = "apb2";
+		};
+
+		bus_gates: bus_gates_clk at 01c20060 {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun50i-a64-bus-gates-clk",
+				     "allwinner,sunxi-multi-bus-gates-clk";
+			reg = <0x01c20060 0x14>;
+			ahb1_parent {
+				clocks = <&ahb1>;
+				clock-indices = <1>, <5>,
+						<6>, <8>,
+						<9>, <10>,
+						<13>, <14>,
+						<18>, <19>,
+						<20>, <21>,
+						<23>, <24>,
+						<25>, <28>,
+						<32>, <35>,
+						<36>, <37>,
+						<40>, <43>,
+						<44>, <52>,
+						<53>, <54>,
+						<135>;
+				clock-output-names = "bus_mipidsi", "bus_ce",
+						"bus_dma", "bus_mmc0",
+						"bus_mmc1", "bus_mmc2",
+						"bus_nand", "bus_sdram",
+						"bus_ts", "bus_hstimer",
+						"bus_spi0", "bus_spi1",
+						"bus_otg", "bus_otg_ehci0",
+						"bus_ehci0", "bus_otg_ohci0",
+						"bus_ve", "bus_lcd0",
+						"bus_lcd1", "bus_deint",
+						"bus_csi", "bus_hdmi",
+						"bus_de", "bus_gpu",
+						"bus_msgbox", "bus_spinlock",
+						"bus_dbg";
+			};
+			ahb2_parent {
+				clocks = <&ahb2>;
+				clock-indices = <17>, <29>;
+				clock-output-names = "bus_gmac", "bus_ohci0";
+			};
+			apb1_parent {
+				clocks = <&apb1>;
+				clock-indices = <64>, <65>,
+						<69>, <72>,
+						<76>, <77>,
+						<78>;
+				clock-output-names = "bus_codec", "bus_spdif",
+						"bus_pio", "bus_ths",
+						"bus_i2s0", "bus_i2s1",
+						"bus_i2s2";
+			};
+			abp2_parent {
+				clocks = <&apb2>;
+				clock-indices = <96>, <97>,
+						<98>, <101>,
+						<112>, <113>,
+						<114>, <115>,
+						<116>;
+				clock-output-names = "bus_i2c0", "bus_i2c1",
+						"bus_i2c2", "bus_scr",
+						"bus_uart0", "bus_uart1",
+						"bus_uart2", "bus_uart3",
+						"bus_uart4";
+			};
+		};
+
+		mmc0_clk: mmc0_clk at 01c20088 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-mod0-clk";
+			reg = <0x01c20088 0x4>;
+			clocks = <&osc24M>, <&pll6x2>, <&pll8x2>;
+			clock-output-names = "mmc0";
+                };
+
+		mmc1_clk: mmc1_clk at 01c2008c {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-mod0-clk";
+			reg = <0x01c2008c 0x4>;
+			clocks = <&osc24M>, <&pll6x2>, <&pll8x2>;
+			clock-output-names = "mmc1";
+		};
+
+		mmc2_clk: mmc2_clk at 01c20090 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-mod0-clk";
+			reg = <0x01c20090 0x4>;
+			clocks = <&osc24M>, <&pll6x2>, <&pll8x2>;
+			clock-output-names = "mmc2";
+		};
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		mmc0: mmc at 01c0f000 {
+			compatible = "allwinner,sun50i-a64-mmc",
+				     "allwinner,sun5i-a13-mmc";
+			reg = <0x01c0f000 0x1000>;
+			clocks = <&bus_gates 8>, <&mmc0_clk>,
+				 <&mmc0_clk>, <&mmc0_clk>;
+			clock-names = "ahb", "mmc",
+				      "output", "sample";
+			resets = <&ahb_rst 8>;
+			reset-names = "ahb";
+			interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mmc1: mmc at 01c10000 {
+			compatible = "allwinner,sun50i-a64-mmc",
+				     "allwinner,sun5i-a13-mmc";
+			reg = <0x01c10000 0x1000>;
+			clocks = <&bus_gates 9>, <&mmc1_clk>,
+				 <&mmc1_clk>, <&mmc1_clk>;
+			clock-names = "ahb", "mmc",
+				      "output", "sample";
+			resets = <&ahb_rst 9>;
+			reset-names = "ahb";
+			interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mmc2: mmc at 01c11000 {
+			compatible = "allwinner,sun50i-a64-mmc",
+				     "allwinner,sun5i-a13-mmc";
+			reg = <0x01c11000 0x1000>;
+			clocks = <&bus_gates 10>, <&mmc2_clk>,
+				 <&mmc2_clk>, <&mmc2_clk>;
+			clock-names = "ahb", "mmc",
+				      "output", "sample";
+			resets = <&ahb_rst 10>;
+			reset-names = "ahb";
+			interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		pio: pinctrl at 01c20800 {
+			compatible = "allwinner,sun50i-a64-pinctrl";
+			reg = <0x01c20800 0x400>;
+			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&bus_gates 69>;
+			gpio-controller;
+			#gpio-cells = <3>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+
+			uart0_pins_a: uart0 at 0 {
+				allwinner,pins = "PB8", "PB9";
+				allwinner,function = "uart0";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart0_pins_b: uart0 at 1 {
+				allwinner,pins = "PF2", "PF3";
+				allwinner,function = "uart0";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart1_2pins: uart1_2 at 0 {
+				allwinner,pins = "PG6", "PG7";
+				allwinner,function = "uart1";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart1_4pins: uart1_4 at 0 {
+				allwinner,pins = "PG6", "PG7", "PG8", "PG9";
+				allwinner,function = "uart1";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart2_2pins: uart2_2 at 0 {
+				allwinner,pins = "PB0", "PB1";
+				allwinner,function = "uart2";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart2_4pins: uart2_4 at 0 {
+				allwinner,pins = "PB0", "PB1", "PB2", "PB3";
+				allwinner,function = "uart2";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart3_pins_a: uart3 at 0 {
+				allwinner,pins = "PD0", "PD1";
+				allwinner,function = "uart3";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart3_2pins_b: uart3_2 at 1 {
+				allwinner,pins = "PH4", "PH5";
+				allwinner,function = "uart3";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart3_4pins_b: uart3_4 at 1 {
+				allwinner,pins = "PH4", "PH5", "PH6", "PH7";
+				allwinner,function = "uart3";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart4_2pins: uart4_2 at 0 {
+				allwinner,pins = "PD2", "PD3";
+				allwinner,function = "uart4";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart4_4pins: uart4_4 at 0 {
+				allwinner,pins = "PD2", "PD3", "PD4", "PD5";
+				allwinner,function = "uart4";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			mmc0_pins: mmc0 at 0 {
+				allwinner,pins = "PF0", "PF1", "PF2", "PF3",
+						 "PF4", "PF5";
+				allwinner,function = "mmc0";
+				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			mmc0_default_cd_pin: mmc0_cd_pin at 0 {
+				allwinner,pins = "PF6";
+				allwinner,function = "gpio_in";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+			};
+
+			mmc1_pins: mmc1 at 0 {
+				allwinner,pins = "PG0", "PG1", "PG2", "PG3",
+						 "PG4", "PG5";
+				allwinner,function = "mmc1";
+				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			mmc2_pins: mmc2 at 0 {
+				allwinner,pins = "PC1", "PC5", "PC6", "PC8",
+						 "PC9", "PC10";
+				allwinner,function = "mmc2";
+				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			i2c0_pins: i2c0_pins {
+				allwinner,pins = "PH0", "PH1";
+				allwinner,function = "i2c0";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			i2c1_pins: i2c1_pins {
+				allwinner,pins = "PH2", "PH3";
+				allwinner,function = "i2c1";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			i2c2_pins: i2c2_pins {
+				allwinner,pins = "PE14", "PE15";
+				allwinner,function = "i2c2";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+		};
+
+		ahb_rst: reset at 01c202c0 {
+			#reset-cells = <1>;
+			compatible = "allwinner,sun6i-a31-clock-reset";
+			reg = <0x01c202c0 0xc>;
+		};
+
+		apb1_rst: reset at 01c202d0 {
+			#reset-cells = <1>;
+			compatible = "allwinner,sun6i-a31-clock-reset";
+			reg = <0x01c202d0 0x4>;
+		};
+
+		apb2_rst: reset at 01c202d8 {
+			#reset-cells = <1>;
+			compatible = "allwinner,sun6i-a31-clock-reset";
+			reg = <0x01c202d8 0x4>;
+		};
+
+		uart0: serial at 01c28000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28000 0x400>;
+			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&bus_gates 112>;
+			resets = <&apb2_rst 16>;
+			status = "disabled";
+		};
+
+		uart1: serial at 01c28400 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28400 0x400>;
+			interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&bus_gates 113>;
+			resets = <&apb2_rst 17>;
+			status = "disabled";
+		};
+
+		uart2: serial at 01c28800 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28800 0x400>;
+			interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&bus_gates 114>;
+			resets = <&apb2_rst 18>;
+			status = "disabled";
+		};
+
+		uart3: serial at 01c28c00 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28c00 0x400>;
+			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&bus_gates 115>;
+			resets = <&apb2_rst 19>;
+			status = "disabled";
+		};
+
+		uart4: serial at 01c29000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c29000 0x400>;
+			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&bus_gates 116>;
+			resets = <&apb2_rst 20>;
+			status = "disabled";
+		};
+
+		rtc: rtc at 01f00000 {
+			compatible = "allwinner,sun6i-a31-rtc";
+			reg = <0x01f00000 0x54>;
+			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		i2c0: i2c at 01c2ac00 {
+			compatible = "allwinner,sun6i-a31-i2c";
+			reg = <0x01c2ac00 0x400>;
+			interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&bus_gates 96>;
+			resets = <&apb2_rst 0>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c1: i2c at 01c2b000 {
+			compatible = "allwinner,sun6i-a31-i2c";
+			reg = <0x01c2b000 0x400>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&bus_gates 97>;
+			resets = <&apb2_rst 1>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c2: i2c at 01c2b400 {
+			compatible = "allwinner,sun6i-a31-i2c";
+			reg = <0x01c2b400 0x400>;
+			interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&bus_gates 98>;
+			resets = <&apb2_rst 2>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+};
-- 
2.6.4



From xinliang.liu at linaro.org  Wed Feb 17 03:46:41 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Wed, 17 Feb 2016 19:46:41 +0800
Subject: [PATCH v4 01/11] drm/hisilicon: Add device tree binding for
 hi6220 display subsystem
In-Reply-To: <56B87156.1040506@codeaurora.org>
References: <1454729098-79807-1-git-send-email-xinliang.liu@linaro.org>
 <1454729098-79807-2-git-send-email-xinliang.liu@linaro.org>
 <56B87156.1040506@codeaurora.org>
Message-ID: <CAGd==07PtSm6RHHUH-i7O8vL4+OQiuhLMvq7GMrAy+V3SfrgGQ@mail.gmail.com>

On 8 February 2016 at 18:43, Archit Taneja <architt at codeaurora.org> wrote:
> Hi,
>
>
> On 02/06/2016 08:54 AM, Xinliang Liu wrote:
>>
>> Add ADE display controller binding doc.
>> Add DesignWare DSI Host Controller v1.20a binding doc.
>>
>> v4:
>> - Describe more specific of clocks and ports.
>> - Fix indentation.
>> v3:
>> - Make ade as the drm master node.
>> - Use assigned-clocks to set clock rate.
>> - Use ports to connect display relavant nodes.
>> v2:
>> - Move dt binding docs to bindings/display/hisilicon directory.
>>
>> Signed-off-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
>> Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
>> ---
>>   .../bindings/display/hisilicon/dw-dsi.txt          | 77
>> ++++++++++++++++++++++
>>   .../bindings/display/hisilicon/hisi-ade.txt        | 69
>> +++++++++++++++++++
>>   2 files changed, 146 insertions(+)
>>   create mode 100644
>> Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>>   create mode 100644
>> Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>> b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>> new file mode 100644
>> index 000000000000..af6d702f3282
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>> @@ -0,0 +1,77 @@
>> +Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
>> +
>> +A DSI Host Controller resides in the middle of display controller and
>> external
>> +HDMI converter.
>> +
>> +Required properties:
>> +- compatible: value should be "hisilicon,hi6220-dsi".
>> +- reg: physical base address and length of dsi controller's registers.
>> +- clocks: the clocks needed.
>> +- clock-names: the name of the clocks.
>> +- ports: contains DSI controller input and output sub port.
>> +  The input port connects to ADE output port with the reg value "0".
>> +  The output port with the reg value "1", it could connect to panel or
>> +  any other bridge endpoints. And the reg value for bridge endpoint is
>> "0",
>> +  other values for panel endpoint.
>> +  See Documentation/devicetree/bindings/graph.txt for more device graph
>> info.
>> +
>> +A example of HiKey board hi6220 SoC and board specific DT entry:
>> +Example:
>> +
>> +SoC specific:
>> +       dsi: dsi at f4107800 {
>> +               compatible = "hisilicon,hi6220-dsi";
>> +               reg = <0x0 0xf4107800 0x0 0x100>;
>> +               clocks = <&media_ctrl  HI6220_DSI_PCLK>;
>> +               clock-names = "pclk_dsi";
>> +               status = "disabled";
>> +
>> +               ports {
>> +                       #address-cells = <1>;
>> +                       #size-cells = <0>;
>> +
>> +                       /* 0 for input port */
>> +                       port at 0 {
>> +                               reg = <0>;
>> +                               dsi_in: endpoint {
>> +                                       remote-endpoint = <&ade_out>;
>> +                               };
>> +                       };
>> +               };
>> +       };
>> +
>> +
>> +Board specific:
>> +       &dsi {
>> +               status = "ok";
>> +
>> +               ports {
>> +                       /* 1 for output port */
>> +                       port at 1 {
>> +                               #address-cells = <1>;
>> +                               #size-cells = <0>;
>> +                               reg = <1>;
>> +
>> +                               /* 0 for bridge, other value for panel */
>> +                               dsi_out0: endpoint at 0 {
>> +                                       reg = <0>;
>> +                                       remote-endpoint = <&adv7533_in>;
>> +                               };
>> +                       };
>> +               };
>> +       };
>> +
>> +       &i2c2 {
>> +               ...
>> +
>> +               adv7533: adv7533 at 39 {
>> +                       ...
>> +
>> +                       port {
>> +                               adv7533_in: endpoint {
>> +                                       remote-endpoint = <&dsi_out0>;
>> +                               };
>> +                       };
>> +               };
>> +       };
>> +
>> diff --git
>> a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>> b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>> new file mode 100644
>> index 000000000000..1eff5a41b98d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>> @@ -0,0 +1,69 @@
>> +Device-Tree bindings for hisilicon ADE display controller driver
>> +
>> +ADE (Advanced Display Engine) is the display controller which grab image
>> +data from memory, do composition, do post image processing, generate RGB
>> +timing stream and transfer to DSI.
>> +
>> +Required properties:
>> +- compatible: value should be "hisilicon,hi6220-ade".
>> +- reg: physical base address and length of the controller's registers.
>> +  Three reg ranges are used in ADE driver:
>> +  ADE reg range, value should be "<0x0 0xf4100000 0x0 0x7800>";
>> +  media subsystem reg range, value should be "<0x0 0xf4410000 0x0
>> 0x1000>";
>> +  media subsystem NOC QoS reg range, value should be "<0x0 0xf4520000 0x0
>> +  0x1000>".
>> +- reg-names: name of physical base.Valuse should be "ade_base",
>> "media_base"
>> +  and "media_noc_base".
>
>
> The "media_base" and "media_noc_base" don't really look like a part of the
> ADE subsytem's MMIO region. If we need to configure these registers,
> and currently don't have a driver/api to achieve this, I think it would
> be better off to use syscon, because that'll at least ensure that the
> registers are consistent among multiple drivers that have ioremapped
> these regions. The other possibility would be to keep this out of mainline
> linux until we get drivers that support this in a proper way.
>
> Otherwise, this looks good to me.

yes, The "media_base" and "media_noc_base" is not a part of the
ADE subsytem's MMIO region. Actually belong to media controller MMIO region.
Will use syscon and reset framework to do the same work in v5.
Thanks for pointing out this.

Thanks,
-xinliang


>
> Archit
>
>
>> +- interrupt: the ldi vblank interrupt number used.
>> +- clocks: the clocks needed. Three clocks are used in ADE driver:
>> +  ADE core clock, value should be "<&media_ctrl HI6220_ADE_CORE>";
>> +  ADE pixel clok, value should be "<&media_ctrl HI6220_ADE_PIX_SRC>";
>> +  media NOC QoS clock, value should be "<&media_ctrl HI6220_CODEC_JPEG>".
>> +- clock-names: the name of the clocks. Values should be "clk_ade_core",
>> +  "clk_codec_jpeg" and "clk_ade_pix".
>> +- assigned-clocks: clocks to be assigned rate.
>> +- assigned-clock-rates: clock rates which are assigned to
>> assigned-clocks.
>> +  The rate of <&media_ctrl HI6220_ADE_CORE> could be "360000000" or
>> +  "180000000";
>> +  The rate of <&media_ctrl HI6220_CODEC_JPEG> could be less than
>> "1440000000".
>> +- port: the output port. This contains one endpoint subnode, with its
>> +  remote-endpoint set to the phandle of the connected DSI input endpoint.
>> +  See Documentation/devicetree/bindings/graph.txt for more device graph
>> info.
>> +
>> +Optional properties:
>> +- dma-coherent: Present if dma operations are coherent.
>> +
>> +
>> +A example of HiKey board hi6220 SoC specific DT entry:
>> +Example:
>> +
>> +       ade: ade at f4100000 {
>> +               compatible = "hisilicon,hi6220-ade";
>> +               reg = <0x0 0xf4100000 0x0 0x7800>,
>> +                     <0x0 0xf4410000 0x0 0x1000>,
>> +                     <0x0 0xf4520000 0x0 0x1000>;
>> +               reg-names = "ade_base",
>> +                           "media_base",
>> +                           "media_noc_base";
>> +
>> +               interrupts = <0 115 4>; /* ldi interrupt */
>> +
>> +               clocks = <&media_ctrl HI6220_ADE_CORE>,
>> +                        <&media_ctrl HI6220_CODEC_JPEG>,
>> +                        <&media_ctrl HI6220_ADE_PIX_SRC>;
>> +               /*clock name*/
>> +               clock-names  = "clk_ade_core",
>> +                              "clk_codec_jpeg",
>> +                              "clk_ade_pix";
>> +
>> +               assigned-clocks = <&media_ctrl HI6220_ADE_CORE>,
>> +                       <&media_ctrl HI6220_CODEC_JPEG>;
>> +               assigned-clock-rates = <360000000>, <288000000>;
>> +               dma-coherent;
>> +
>> +               port {
>> +                       ade_out: endpoint {
>> +                               remote-endpoint = <&dsi_in>;
>> +                       };
>> +               };
>> +       };
>>
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation


From mark.rutland at arm.com  Wed Feb 17 03:46:46 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 17 Feb 2016 11:46:46 +0000
Subject: [PATCH 6/6] ARM64: dts: rockchip: add core dtsi file for rk3399
In-Reply-To: <1455674476-16655-1-git-send-email-jay.xu@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <1455674476-16655-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <20160217114645.GA32647@leverpostej>

On Wed, Feb 17, 2016 at 10:01:16AM +0800, jianqun.xu wrote:
> From: Xu Jianqun <jay.xu at rock-chips.com>
> 
> Add dtsi file for Rockchip rk3399 SoCs, which includes some
> general nodes such as cpu, pmu, cru, gic, amba and so on.
> 
> Change-Id: Ie3b824e8ead967d4cb119d73222b7a198478c29c

This is meaningless upstream. Please remove any "Change-Id" lines from
upstream commit messages.

> Signed-off-by: Xu Jianqun <jay.xu at rock-chips.com>
> ---
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 989 +++++++++++++++++++++++++++++++
>  1 file changed, 989 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> new file mode 100644
> index 0000000..eb671f6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -0,0 +1,989 @@
> +/*
> + * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This library is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +#include <dt-bindings/clock/rk3399-cru.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/pinctrl/rockchip.h>
> +
> +/ {
> +	compatible = "rockchip,rk3399";
> +	interrupt-parent = <&gic>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	aliases {
> +		serial0 = &uart0;
> +		serial1 = &uart1;
> +		serial2 = &uart2;
> +		serial3 = &uart3;
> +	};
> +
> +	psci {
> +		compatible = "arm,psci";
> +		method = "smc";
> +	};

That compatible string alone is insufficient, as it implies no
particular function IDs. Hotplug and idle cannot possibly work.

Have you tested this DT?

Which PSCI version have you implemented? Are you using a standard
firmware (e.g. ARM Trusted Firmware), or some custom implementation?

> +		cpu_l0: cpu at 0 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			reg = <0x0 0x0>;
> +			cpu-idle-states = <&cpu_sleep>;
> +			enable-method = "psci";
> +		};

> +		cpu_b0: cpu at 100 {
> +			device_type = "cpu";
> +			compatible = "arm,cortex-a72", "arm,armv8";
> +			reg = <0x0 0x100>;
> +			cpu-idle-states = <&cpu_sleep>;
> +			enable-method = "psci";
> +		};
> +

> +	pmu {
> +		compatible = "arm,armv8-pmuv3";
> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
> +		interrupt-affinity = <&cpu_l0>, <&cpu_l1>, <&cpu_l2>,
> +				     <&cpu_l3>, <&cpu_b0>, <&cpu_b1>;
> +	};
> +

This isn't quite right. We should have separate nodes for the A72 and
A53 PMUs.

We can't describe that just yet due to needing cluster-local PPIs. I
believe Will was looking into that.

In the mean time, please drop the PMU node.

> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts =
> +			<GIC_PPI 13
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			<GIC_PPI 14
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			<GIC_PPI 11
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			<GIC_PPI 10
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> +		clock-frequency = <24000000>;
> +	};

Please fix your firmware to program CNTFRQ. Using clock-frequency is
really not sufficient, and new platforms have no excuse for not having
it programmed correctly.

Thanks,
Mark.


From brian.starkey at arm.com  Wed Feb 17 03:53:48 2016
From: brian.starkey at arm.com (Brian Starkey)
Date: Wed, 17 Feb 2016 11:53:48 +0000
Subject: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag
In-Reply-To: <20160209102300.GB23507@e106950-lin.cambridge.arm.com>
References: <cover.1454950917.git.brian.starkey@arm.com>
 <9085d37fa97a762a46b9d58719c085368682c64f.1454950917.git.brian.starkey@arm.com>
 <20160208120317.313409dc0ae7634c25d3f021@linux-foundation.org>
 <20160209102300.GB23507@e106950-lin.cambridge.arm.com>
Message-ID: <20160217115347.GA28433@e106950-lin.cambridge.arm.com>

Hi Andrew,

Would you pick these up if I rebase onto linux-next?

How strongly do you feel about the input argument modification vs.
staying in-line with the rest of the function?

Thanks,

Brian

On Tue, Feb 09, 2016 at 10:23:00AM +0000, Brian Starkey wrote:
>Hi Andrew,
>
>Thanks for taking a look,
>
>On Mon, Feb 08, 2016 at 12:03:17PM -0800, Andrew Morton wrote:
>>On Mon,  8 Feb 2016 17:30:50 +0000 Brian Starkey <brian.starkey at arm.com> wrote:
>>The patch generally looks OK to me.  It generates rejects against
>>linux-next because of some janitorial changes in memremap.c.
>>
>
>Ah yeah, so it does - sorry. I was hoping this could make it into 4.5,
>but I can rebase onto linux-next if that's better. Annoyingly it only
>conflicts because of a couple of quotation marks.
>
>>
>>>@@ -101,6 +107,11 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
>>> 		addr = ioremap_wt(offset, size);
>>> 	}
>>>
>>>+	if (!addr && (flags & MEMREMAP_WC)) {
>>>+		flags &= ~MEMREMAP_WC;
>>>+		addr = ioremap_wc(offset, size);
>>>+	}
>>>+
>>> 	return addr;
>>> }
>>
>>The modifications of `flags' is unneeded (and the compiler will remove
>>it).  And generally the modification of incoming args is a bit nasty
>>IMO - I find it's better to treat them as const - part of the calling
>>environment which can be relied upon to be unaltered as the code
>>evolves.
>>
>
>To be honest I was just mirroring the rest of the function. I guess
>the idea was filtering the different mapping types in case one of the
>'mappers' can handle multiple flags or something. I'll remove it if
>you like, I just thought that extending the functionality in-keeping
>with the current semantics was a better evolution - let me know.
>
>Thanks,
>Brian


From Michael.Williams at arm.com  Wed Feb 17 04:08:17 2016
From: Michael.Williams at arm.com (Michael Williams)
Date: Wed, 17 Feb 2016 12:08:17 +0000
Subject: [PATCH V3 6/6] coresight-stm: adding driver for CoreSight STM
 component
In-Reply-To: <CAG2=9p9-c5z6yXm6VDkDeqZmpFGt3z88ccNQxZTwia=dm3_GNQ@mail.gmail.com>
References: <1454756672-12790-1-git-send-email-zhang.chunyan@linaro.org>
 <1454756672-12790-7-git-send-email-zhang.chunyan@linaro.org>
 <CANLsYkxvLFu1C+_H9c0EoMebLQu1gnwt9bqY6_R3j+ua2w+xMg@mail.gmail.com>
 <VI1PR08MB06708C5EA9DEE2D71C13FFAA8AA90@VI1PR08MB0670.eurprd08.prod.outlook.com>
 <CAG2=9p9-c5z6yXm6VDkDeqZmpFGt3z88ccNQxZTwia=dm3_GNQ@mail.gmail.com>
Message-ID: <VI1PR08MB0670BF982CDE54DA7EE9B0BF8AAE0@VI1PR08MB0670.eurprd08.prod.outlook.com>

Hi Chunyan,

Chunyan Zhang wrote on 2016-02-17:
> Hi Michael,
>
> One question below need to be clarified.
>
> On Fri, Feb 12, 2016 at 10:55 PM, Michael Williams
> <Michael.Williams at arm.com> wrote:
>> Mathieu Poirier [mailto:mathieu.poirier at linaro.org] wrote:
>>> On 6 February 2016 at 04:04, Chunyan Zhang <zhang.chunyan at linaro.org> wrote:
>>>> From: Pratik Patel <pratikp at codeaurora.org>
>>>>
>>>> This driver adds support for the STM CoreSight IP block, allowing any
>>>> system compoment (HW or SW) to log and aggregate messages via a
>>>> single entity.
>>>>
>>>> The CoreSight STM exposes an application defined number of channels
>>>> called stimulus port.  Configuration is done using entries in sysfs
>>>> and channels made available to userspace via configfs.
>>>>
>>>> Signed-off-by: Pratik Patel <pratikp at codeaurora.org>
>>>> Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
>>>> Signed-off-by: Chunyan Zhang <zhang.chunyan at linaro.org>
>>>> ---
>>>>  .../ABI/testing/sysfs-bus-coresight-devices-stm    |  53 ++
>>>>  Documentation/trace/coresight.txt                  |  37 +-
>>>>  drivers/hwtracing/coresight/Kconfig                |  11 +
>>>>  drivers/hwtracing/coresight/Makefile               |   1 +
>>>>  drivers/hwtracing/coresight/coresight-stm.c        | 928 +++++++++++++++++++++
>>>>  include/linux/coresight-stm.h                      |   6 +
>>>>  include/uapi/linux/coresight-stm.h                 |  12 +
>>>>  7 files changed, 1046 insertions(+), 2 deletions(-)
>>>>  create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>>>>  create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
>>>>  create mode 100644 include/linux/coresight-stm.h
>>>>  create mode 100644 include/uapi/linux/coresight-stm.h
>
> [...]
>
>>>> +static int stm_send(void *addr, const void *data, u32 size, u8 max)
>>>> +{
>>>> +       u32 len = size;
>>>> +       u8 paload[8];
>>>> +
>>>> +       if (stm_addr_unaligned(data, max)) {
>>>> +               memcpy(paload, data, size);
>>>> +               data = paload;
>>>> +       }
>>>> +
>>>> +       /* now we are 64bit/32bit aligned */
>>>> +#ifdef CONFIG_64BIT
>>>> +       if (size == 8)
>>>> +               writeq_relaxed(*(u64 *)data, addr);
>>>> +#endif
>>>
>>> We probably don't need an #ifdef here.  Checking the size of the
>>> transfer against the fundamental data size will result in the same
>>> outcome, i.e preventing 64 bit transfers on a 32 bit architecture.  An
>>> error (understandable by the caller) should probably be returned in
>>> this case.
>>
>> In theory this is correct, but if the code is unreachable for non-32-bit architectures,
> why include it at all?
>
>                             ^^^^^^^
> I guess you mean the code is unreachable for "non-64-bit" architectures?

Yes; apologies for my mistake!

[snip]

Mike

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

From robert.richter at caviumnetworks.com  Wed Feb 17 04:16:05 2016
From: robert.richter at caviumnetworks.com (Robert Richter)
Date: Wed, 17 Feb 2016 13:16:05 +0100
Subject: [PATCH v3] irqchip, gicv3-its, numa: Workaround for Cavium
 thunderx erratum 23144
In-Reply-To: <1455628282-8939-1-git-send-email-gkulkarni@caviumnetworks.com>
References: <1455628282-8939-1-git-send-email-gkulkarni@caviumnetworks.com>
Message-ID: <20160217121605.GE24726@rric.localdomain>

On 16.02.16 18:41:22, Ganapatrao Kulkarni wrote:
> The erratum fixes the hang of ITS SYNC command by avoiding inter node
> io and collections/cpu mapping on thunderx dual-socket platform.
> 
> This is based on NUMA v10 series.
> https://lkml.org/lkml/2016/2/2/134
> 
> v3:
> updatated as per Marc Zyngier's review comments.
> http://www.spinics.net/lists/arm-kernel/msg443462.html
> 
> v2:
> updatated as per Marc Zyngier's review comments.
> 
> Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
> 
> ---
>  arch/arm64/Kconfig               |  9 ++++++++
>  drivers/irqchip/irq-gic-v3-its.c | 46 ++++++++++++++++++++++++++++++++++++++--
>  2 files changed, 53 insertions(+), 2 deletions(-)

> @@ -1086,6 +1098,14 @@ static void its_cpu_init_collection(void)
>  	list_for_each_entry(its, &its_nodes, entry) {
>  		u64 target;
>  
> +		/* avoid cross node collections and its mapping */
> +		if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
> +			struct device_node *cpu_node;
> +			cpu_node = of_get_cpu_node(cpu, NULL);
> +			if (its->numa_node != of_node_to_nid(cpu_node))
> +				continue;

I think you may not continue in case of its->numa_node ==
NUMA_NO_NODE. This is the case if no numa node info is provided and
thus ITS is systemwide. So the check needs to be extended accordingly.

-Robert

> +		}
> +
>  		/*
>  		 * We now have to bind each collection to its target
>  		 * redistributor.


From horms at verge.net.au  Wed Feb 17 04:18:41 2016
From: horms at verge.net.au (Simon Horman)
Date: Wed, 17 Feb 2016 21:18:41 +0900
Subject: [PATCH 0/4] Enable PM and PM_GENERIC_DOMAINS for SoCs with PM
 Domains
In-Reply-To: <1455636712-3040-1-git-send-email-geert+renesas@glider.be>
References: <1455636712-3040-1-git-send-email-geert+renesas@glider.be>
Message-ID: <20160217121840.GC346@verge.net.au>

On Tue, Feb 16, 2016 at 04:31:48PM +0100, Geert Uytterhoeven wrote:
> 	Hi Simon, Magnus,
> 
> All supported Renesas ARM SoCs (except for Emma Mobile EV2) have clock
> domains. Some SoCs also have power domains. To ensure proper operation
> of on-SoC modules, module clocks must be ungated, and power domains must
> be powered up when needed.
> 
> Currently the user can choose to build a kernel with power management
> enabled or disabled:
>   - If CONFIG_PM=y, power domains and/or module clocks are handled
>     dynamically by Runtime PM and the generic power domain.
>   - If CONFIG_PM=n, power domains are assumed to be powered up by reset
>     state or by the boot loader, and module clocks are handled by the
>     legacy clock domain on driver (un)bind.
>     The latter is implemented using a platform bus notifier, which
>     applies not only to all on-SoC devices, but to all platform devices
>     present in the system.
> 
> To remove the dependency on implicit assumptions, and to get rid of the
> peculiarities of the legacy clock domain, enable CONFIG_PM and
> CONFIG_PM_GENERIC_DOMAINS unconditionally, for all Renesas ARM SoCs with
> clock and/or power domains.
> 
> Patches:
>   - Patches 1 and 2 enable PM and PM_GENERIC_DOMAINS,
>   - Patch 3 removes the now unused legacy clock domain code for Renesas
>     ARM SoCs,
>   - Patch 4 relieves you from maintaining drivers/sh/, which is no
>     longer used on Renesas ARM SoCs, and returns it to the SuperH
>     people.
> 
> Notes:
>   - This does cause an increase in kernel size.  Given bloat-o-meter
>     reports a modest increase of 26 KiB for an RZ/A1H kernel, this
>     should not be a problem, even when used on RZ/A1H with XIP and
>     internal RAM only.
>   - Patch 3 does break booting R-Car Gen2 boards using pre-v4.3 DTSes
>     that don't have power-domains properties,
>   - Patch 3 may unbreak SuperH-based ARCH_SHMOBILE platforms, which were
>     probably broken since v4.4 by commit 0ba58de231066e47 ("drivers: sh:
>     Get rid of CONFIG_ARCH_SHMOBILE_MULTI"),
>   - Currently CONFIG_PM=n doesn't work anyway on r8a7795 as "drivers:
>     sh: Handle PM_GENERIC_DOMAINS_OF=n with new r8a7795 CPG/MSSR
>     driver" isn't upstream.
> 
> For your convenience, I've also pushed this series to
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git#topic/mandatory-pm-v1
> 
> Thanks for your comments!
> 
> Geert Uytterhoeven (4):
>   ARM: shmobile: Enable PM and PM_GENERIC_DOMAINS for SoCs with PM
>     Domains
>   arm64: renesas: Enable PM and PM_GENERIC_DOMAINS for SoCs with PM
>     Domains

Thanks, I have tentatively queued up the above two patches for v4.6.

With regards to the remaining two patches, I propose deferring them
for a few releases so that we can shake out any regressions that
may occur before making a compatibility change.

>   drivers: sh: Stop using the legacy clock domain on ARM
>   MAINTAINERS: Drop drivers/sh/ for Renesas ARM
> 
>  MAINTAINERS                    |  1 -
>  arch/arm/mach-shmobile/Kconfig | 13 ++++++++-----
>  arch/arm64/Kconfig.platforms   |  3 ++-
>  drivers/Makefile               |  1 -
>  drivers/sh/pm_runtime.c        |  9 ---------
>  5 files changed, 10 insertions(+), 17 deletions(-)


From lorenzo.pieralisi at arm.com  Wed Feb 17 04:39:33 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 17 Feb 2016 12:39:33 +0000
Subject: [PATCH V5 02/15] acpi, pci, mcfg: Provide default RAW ACPI PCI
 config space accessors.
In-Reply-To: <1455630825-27253-3-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
 <1455630825-27253-3-git-send-email-tn@semihalf.com>
Message-ID: <20160217123933.GB9794@red-moon>

On Tue, Feb 16, 2016 at 02:53:32PM +0100, Tomasz Nowicki wrote:
> Lets keep RAW ACPI PCI config space accessors empty by default,
> since we are note sure if they are necessary accross all archs.
> Once we sort this out, we can provide generic version or let
> architectures to overwrite, like now x86.

"ACPICA code requires raw PCI bus accessors in order to give AML
access to PCI_Config regions in platforms where they are actually
used. The raw PCI bus accessors implementation is arch-dependent,
therefore this patch adds a weak generic implementation (for now
empty but can be generalized if common functionality is found among
arches) allowing arches where PCI_Config regions are currently required
to override it (eg x86) as needed and providing at the same time
default stubs for arches that do not require them".

?

> Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
> Tested-by: Jeremy Linton <jeremy.linton at arm.com>
> Tested-by: Duc Dang <dhdang at apm.com>
> Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
> Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
> Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
> Tested-by: Sinan Kaya <okaya at codeaurora.org>
> ---
>  drivers/acpi/pci_mcfg.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index ea84365..0467b00 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -21,6 +21,26 @@
>  static DEFINE_MUTEX(pci_mmcfg_lock);
>  LIST_HEAD(pci_mmcfg_list);
>  
> +/*
> + * raw_pci_read/write - raw ACPI PCI config space accessors.
> + *
> + * By defauly (__weak) these accessors are empty and should be overwritten

s/defauly/default

> + * by architectures which support operations on ACPI PCI_Config regions,
> + * see osl.c file.

Add the path or remove the file reference.

> + */
> +
> +int __weak raw_pci_read(unsigned int domain, unsigned int bus,
> +			unsigned int devfn, int reg, int len, u32 *val)
> +{
> +	return PCIBIOS_DEVICE_NOT_FOUND;
> +}
> +
> +int __weak raw_pci_write(unsigned int domain, unsigned int bus,
> +			 unsigned int devfn, int reg, int len, u32 val)
> +{
> +	return PCIBIOS_DEVICE_NOT_FOUND;
> +}
> +
>  static void list_add_sorted(struct pci_mmcfg_region *new)
>  {
>  	struct pci_mmcfg_region *cfg;

Note: this patch is not strictly required, but it is nice because
it removes the raw/dumb/empty accessors from ARM64 code (where they do not
belong), so:

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>


From julia.lawall at lip6.fr  Wed Feb 17 04:29:05 2016
From: julia.lawall at lip6.fr (Julia Lawall)
Date: Wed, 17 Feb 2016 07:29:05 -0500 (EST)
Subject: [PATCH] input: fix odd_ptr_err.cocci warnings 
Message-ID: <alpine.DEB.2.10.1602170724320.2685@hadrien>

PTR_ERR should access the value just tested by IS_ERR

Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci

Signed-off-by: Fengguang Wu <fengguang.wu at intel.com>
Signed-off-by: Julia Lawall <julia.lawall at lip6.fr>
---

I haven't checked the context in detail. There can be false positives,
when it is the call to IS_ERR that is wrong.

tree:   https://github.com/Broadcom/arm64-linux iproc-tsc-v2
head:   ef32cf1baeb934bfcdf7c9eb8ad345aae266cde5
commit: c3afc7a1c330ce452c52e2183a23b2ab9f70bd4a [2/3] input: syscon
support in bcm_iproc_tsc driver

Please take the patch only if it's a positive warning. Thanks!

 bcm_iproc_tsc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/input/touchscreen/bcm_iproc_tsc.c
+++ b/drivers/input/touchscreen/bcm_iproc_tsc.c
@@ -492,7 +492,7 @@ static int iproc_ts_probe(struct platfor
 						pdev->dev.of_node,
 						"ts_syscon");
 		if (IS_ERR(priv->regmap)) {
-			error = PTR_ERR(priv->regs);
+			error = PTR_ERR(priv->regmap);
 			dev_err(&pdev->dev, "unable to map I/O memory:%d\n",
 				error);
 			return error;


From geert at linux-m68k.org  Wed Feb 17 04:45:37 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 17 Feb 2016 13:45:37 +0100
Subject: [PATCH/RFC v2 04/11] soc: renesas: rcar: Add DT support for SYSC
 PM domains
In-Reply-To: <3535519.g4KL1PCIZy@avalon>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
 <1455571020-18968-5-git-send-email-geert+renesas@glider.be>
 <3535519.g4KL1PCIZy@avalon>
Message-ID: <CAMuHMdVOMgHu2rV98m4GQ3TFJq74efh2jihFzuWBV3qQq39AmQ@mail.gmail.com>

Hi Laurent,

On Mon, Feb 15, 2016 at 11:51 PM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> On Monday 15 February 2016 22:16:53 Geert Uytterhoeven wrote:
>> Populate the SYSC PM domains from DT.
>>
>> Special cases, like PM domains containing CPU cores or SCUs, are
>> handled by scanning the DT topology.
>>
>> The SYSCIER register value is derived from the PM domains found in DT,
>> which will allow to get rid of the hardcoded values in pm-rcar-gen2.c.
>> However, this means we have to scan for PM domains even if CONFIG_PM=n.
>>
>> FIXME:
>>   - This needs better integration with the PM code in pm-rcar-gen2, the
>>     SMP code in smp-r8a7790, and Magnus' DT APMU series.
>
> Have you given this some thoughts already ? Unfortunately smp_prepare_cpus()
> is called before any initcall :-/ How do the other platforms handle this ?

I'm afraid no other platform already handles this.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From arnd at arndb.de  Wed Feb 17 04:55:11 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 13:55:11 +0100
Subject: [PATCH] input: fix odd_ptr_err.cocci warnings
In-Reply-To: <alpine.DEB.2.10.1602170724320.2685@hadrien>
References: <alpine.DEB.2.10.1602170724320.2685@hadrien>
Message-ID: <6833564.Kp6CL1O0GI@wuerfel>

On Wednesday 17 February 2016 07:29:05 Julia Lawall wrote:
> PTR_ERR should access the value just tested by IS_ERR
> 
> Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
> 
> Signed-off-by: Fengguang Wu <fengguang.wu at intel.com>
> Signed-off-by: Julia Lawall <julia.lawall at lip6.fr>
> ---
> 
> I haven't checked the context in detail. There can be false positives,
> when it is the call to IS_ERR that is wrong.
> 
> tree:   https://github.com/Broadcom/arm64-linux iproc-tsc-v2
> head:   ef32cf1baeb934bfcdf7c9eb8ad345aae266cde5
> commit: c3afc7a1c330ce452c52e2183a23b2ab9f70bd4a [2/3] input: syscon
> support in bcm_iproc_tsc driver
> 
> Please take the patch only if it's a positive warning. Thanks!
> 
> 

Looks correct to me

Reviewed-by: Arnd Bergmann <arnd at arndb.de>

>                 if (IS_ERR(priv->regmap)) {
> -                       error = PTR_ERR(priv->regs);
> +                       error = PTR_ERR(priv->regmap);

I think this could have been avoided using

		error = PTR_ERR_OR_ZERO(priv->regmap);
		if (error) {
			...

	Arnd


From aleksey.makarov at linaro.org  Wed Feb 17 05:08:21 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Wed, 17 Feb 2016 16:08:21 +0300
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
Message-ID: <56C470C5.2080203@linaro.org>

Hi Lv,

Thank you for review.

On 02/17/2016 05:51 AM, Zheng, Lv wrote:

[..]

>>> early_acpi_os_unmap_memory() is marked as __init because it calls
>>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is not set.
>>>
>>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>> so it is safe to call early_acpi_os_unmap_memory() from anywhere
>>>
>>> We need this function to be non-__init because we need access to
>>> some tables at unpredictable time--it may be before or after
>>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port Console
>>> Redirection) table is needed each time a new console is registered.
>>> It can be quite early (console_initcall) or when a module is inserted.
>>> When this table accessed before acpi_gbl_permanent_mmap is set,
>>> the pointer should be unmapped.  This is exactly what this function
>>> does.
>> [Lv Zheng]
>> Why don't you use another API instead of early_acpi_os_unmap_memory() in
>> case you want to unmap things in any cases.
>> acpi_os_unmap_memory() should be the one to match this purpose.
>> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().

As far as I understand, there exist two steps in ACPI initialization:

1. Before acpi_gbl_permanent_mmap is set, tables received with acpi_get_table_with_size()
   are mapped by early_memremap().  If a subsystem gets such a pointer it should be unmapped.

2  After acpi_gbl_permanent_mmap is set this pointer should not be unmapped at all.

That exactly what early_acpi_os_unmap_memory() does--it checks acpi_gbl_permanent_mmap.
If I had used acpi_os_unmap_memory() after acpi_gbl_permanent_mmap had been set,
it would have tried to free that pointer with an oops (actually, I checked that and got that oops).

So using acpi_os_unmap_memory() is not an option here, but early_acpi_os_unmap_memory()
match perfectly.

>> And in fact early_acpi_os_unmap_memory() should be removed.

I don't think so -- I have explained why.  It does different thing.
Probably it (and/or other functions in that api) should be renamed.

> [Lv Zheng] 
> One more thing is:
> If you can't switch your driver to use acpi_os_unmap_memory() instead of early_acpi_os_unmap_memory(),
> then it implies that your driver does have a defect.

I still don't understand what defect, sorry.

> There is an early bootup requirement in Linux.
> Maps acquired during the early stage should be freed by the driver during the early stage.
> And the driver should re-acquire the memory map after booting.

Exactly.  That's why I use early_acpi_os_unmap_memory().  The point is that that code can be
called *before* acpi_gbl_permanent_mmap is set (at early initialization of for example 8250 console)
or *after* acpi_gbl_permanent_mmap is set (at insertion of a module that registers a console), 
We just can not tell if the received table pointer should or sould not be freed with early_memunmap()
(actually __acpi_unmap_table() or whatever) without checking acpi_gbl_permanent_mmap,
but that's all too low level.

Another option, as you describe, is to get this pointer early, don't free it untill
acpi_gbl_permanent_mmap is set, then free it (with early_acpi_os_unmap_memory(), that's 
ok because acpi_gbl_permanent_mmap is set in an init code), then get the persistent 
pointer to the table.  The problem with it is that we can not just watch acpi_gbl_permanent_mmap
to catch this exact moment.  And also accessing acpi_gbl_permanent_mmap is not good as it probably is 
an implementation detail (i. e. too lowlevel) of the ACPI code.
Or I probably miss what you are suggesting.

> This is because, during early bootup stage, there are only limited slots available for drivers to map memory.
> So by changing __init to __ref here, you probably will hide many such defects.

What defects?  This funcions checks acpi_gbl_permanent_mmap.
BTW, exactly the same thing is done in the beginning of acpi_os_unmap_memory() and than's ok, 
that function is __ref.

> And solving issues in this way doesn't seem to be an improvement.

Could you please tell me where I am wrong?  I still don't understand your point.

Thank you
Aleksey Makarov

> 
> Thanks and best regards
> -Lv
> 
>>
>> Thanks and best regards
>> -Lv
>>
>>>
>>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
>>> ---
>>>  drivers/acpi/osl.c | 6 +++++-
>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
>>> index 67da6fb..8a552cd 100644
>>> --- a/drivers/acpi/osl.c
>>> +++ b/drivers/acpi/osl.c
>>> @@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void *virt,
>>> acpi_size size)
>>>  }
>>>  EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
>>>
>>> -void __init early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
>> size)
>>> +/*
>>> + * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>> + * so it is safe to call early_acpi_os_unmap_memory() from anywhere
>>> + */
>>> +void __ref early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
>> size)
>>>  {
>>>  	if (!acpi_gbl_permanent_mmap)
>>>  		__acpi_unmap_table(virt, size);
>>> --
>>> 2.7.1
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From LW at KARO-electronics.de  Wed Feb 17 05:09:02 2016
From: LW at KARO-electronics.de (Lothar =?UTF-8?B?V2HDn21hbm4=?=)
Date: Wed, 17 Feb 2016 14:09:02 +0100
Subject: Using i.MX6 quad's IPU#1/DI#1 to drive parallel port #1 failed
In-Reply-To: <201602171210.14545.jbe@pengutronix.de>
References: <201602171210.14545.jbe@pengutronix.de>
Message-ID: <20160217140902.5e24c074@ipc1.ka-ro>

Hi,

On Wed, 17 Feb 2016 12:10:14 +0100 Juergen Borleis wrote:
> Hi,
> 
> someone here who has a working display (or similar) connected to i.MX6 quad's 
> parallel port #1 and driven by IPU#1/DI#1? It seems there is currently no user 
> in the mainline supported boards.
> 
I've got a working configuration with two DVI adapters connected to the
DI0 and DI1 ports on an i.MX6Q board.

The relevant portion of the .dts file looks like this:
	ipu1_disp0: display at di0 {
		compatible = "fsl,imx-parallel-display";
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_disp0_1>;
		interface-pix-fmt = "rgb24";
		status = "okay";

		display-timings {
			native-mode = <&vga0>;

			full-hd {
				clock-frequency = <138500000>;
				hactive = <1920>;
				vactive = <1080>;
				hback-porch = <88>;
				hsync-len = <128>;
				hfront-porch = <40>;
				vback-porch = <33>;
				vsync-len = <2>;
				vfront-porch = <10>;
				hsync-active = <0>;
				vsync-active = <0>;
				de-active = <1>;
				pixelclk-active = <1>;
			};

			vga0: VGA {
				clock-frequency = <25200000>;
				hactive = <640>;
				vactive = <480>;
				hback-porch = <48>;
				hsync-len = <96>;
				hfront-porch = <16>;
				vback-porch = <31>;
				vsync-len = <2>;
				vfront-porch = <12>;
				hsync-active = <0>;
				vsync-active = <0>;
				de-active = <1>;
				pixelclk-active = <0>;
			};
		};

		port {
			display0_in: endpoint {
				remote-endpoint = <&ipu1_di0_disp0>;
			};
		};
	};

	ipu1_disp1: display at di1 {
		compatible = "fsl,imx-parallel-display";
		interface-pix-fmt = "rgb24";
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_disp1>;
		status = "okay";

		display-timings {
			native-mode = <&vga1>;

			full-hd {
				clock-frequency = <138500000>;
				hactive = <1920>;
				vactive = <1080>;
				hback-porch = <88>;
				hsync-len = <128>;
				hfront-porch = <40>;
				vback-porch = <33>;
				vsync-len = <2>;
				vfront-porch = <10>;
				hsync-active = <0>;
				vsync-active = <0>;
				de-active = <1>;
				pixelclk-active = <1>;
			};

			vga1: VGA {
				clock-frequency = <25200000>;
				hactive = <640>;
				vactive = <480>;
				hback-porch = <48>;
				hsync-len = <96>;
				hfront-porch = <16>;
				vback-porch = <31>;
				vsync-len = <2>;
				vfront-porch = <12>;
				hsync-active = <0>;
				vsync-active = <0>;
				de-active = <1>;
				pixelclk-active = <0>;
			};
		};

		port {
			display1_in: endpoint {
				remote-endpoint = <&ipu1_di0_disp1>;
			};
		};
	};

	lcd0_panel: panel0 {
		compatible = "auo,b133htn01", "simple-panel";
		power-supply = <&reg_lcd1_pwr>;
		ddc-i2c-bus = <&i2c2>;
	};

	lcd1_panel: lcd-panel {
		compatible = "auo,b133htn01", "simple-panel";
		power-supply = <&reg_lcd1_pwr>;
		ddc-i2c-bus = <&i2c1>;
	};


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________


From qnguyen at apm.com  Wed Feb 17 05:15:06 2016
From: qnguyen at apm.com (Quan Nguyen)
Date: Wed, 17 Feb 2016 20:15:06 +0700
Subject: [PATCH v7 0/3] Enable X-Gene standby GPIO as interrupt controller
Message-ID: <1455714909-3027-1-git-send-email-qnguyen@apm.com>

V7 Changes:
	- Update Documentation
V6 Changes:
        - Remove redundant irq_ack and irq_shutdown entries
V5 Changes:
        - Add optional properties to describe HW specifics
        - Use irq_create_fwspec_mapping() instead of low level functions
        - Move gpiochip_lock_as_irq() to activate method
        - Remove redundant checks
        - Add optional HW properties description to DT binding document
        - Update "interrupts" property description in DT binding document.
V4 Changes:
        - Convert to hierarchical irq domain
V3 Changes:
        - Picking up from version 2 of "Y Vo <yvo at apm.com>"
        - Get HW resource information from DT
        - Avoid keeping parent IRQ controller
V2 Changes:
        - Support X-Gene standby GPIO as an interrupt controller.

Quan Nguyen (3):
  gpio: xgene: Enable X-Gene standby GPIO as interrupt controller
  Documentation: gpio: Update description for X-Gene standby GPIO
    controller DTS binding
  arm64: dts: Update X-Gene standby GPIO controller DTS entries

 .../devicetree/bindings/gpio/gpio-xgene-sb.txt     |  47 +++-
 arch/arm64/boot/dts/apm/apm-storm.dtsi             |   3 +
 drivers/gpio/gpio-xgene-sb.c                       | 265 ++++++++++++++++++---
 3 files changed, 276 insertions(+), 39 deletions(-)

-- 
1.7.12.4



From qnguyen at apm.com  Wed Feb 17 05:15:08 2016
From: qnguyen at apm.com (Quan Nguyen)
Date: Wed, 17 Feb 2016 20:15:08 +0700
Subject: [PATCH v7 2/3] Documentation: gpio: Update description for X-Gene
 standby GPIO controller DTS binding
In-Reply-To: <1455714909-3027-1-git-send-email-qnguyen@apm.com>
References: <1455714909-3027-1-git-send-email-qnguyen@apm.com>
Message-ID: <1455714909-3027-3-git-send-email-qnguyen@apm.com>

Update description for X-Gene standby GPIO controller DTS binding to
support GPIO line configuration as input, output or external IRQ pin.

Signed-off-by: Y Vo <yvo at apm.com>
Signed-off-by: Quan Nguyen <qnguyen at apm.com>
---
 .../devicetree/bindings/gpio/gpio-xgene-sb.txt     | 47 ++++++++++++++++++----
 1 file changed, 40 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
index dae1300..5490c1d 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
@@ -1,10 +1,20 @@
 APM X-Gene Standby GPIO controller bindings
 
-This is a gpio controller in the standby domain.
-
-There are 20 GPIO pins from 0..21. There is no GPIO_DS14 or GPIO_DS15,
-only GPIO_DS8..GPIO_DS13 support interrupts. The IRQ mapping
-is currently 1-to-1 on interrupts 0x28 thru 0x2d.
+This is a gpio controller in the standby domain. It also supports interrupt in
+some particular pins which are sourced to its parent interrupt controller
+as diagram below:
+                            +-----------------+
+                            | X-Gene standby  |
+                            | GPIO controller +------ GPIO_0
++------------+              |                 | ...
+| Parent IRQ | EXT_INT_0    |                 +------ GPIO_8/EXT_INT_0
+| controller | (SPI40)      |                 | ...
+| (GICv2)    +--------------+                 +------ GPIO_[N+8]/EXT_INT_N
+|            |   ...        |                 |
+|            | EXT_INT_N    |                 +------ GPIO_[N+9]
+|            | (SPI[40 + N])|                 | ...
+|            +--------------+                 +------ GPIO_MAX
++------------+              +-----------------+
 
 Required properties:
 - compatible: "apm,xgene-gpio-sb" for the X-Gene Standby GPIO controller
@@ -15,10 +25,18 @@ Required properties:
 		0 = active high
 		1 = active low
 - gpio-controller: Marks the device node as a GPIO controller.
-- interrupts: Shall contain exactly 6 interrupts.
+- interrupts: The EXT_INT_0 parent interrupt resource must be listed first.
+- interrupt-parent: Phandle of the parent interrupt controller.
+- interrupt-cells: Should be two.
+       - first cell is 0-N coresponding for EXT_INT_0 to EXT_INT_N.
+       - second cell is used to specify flags.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- apm,nr-gpios: Optional, specify number of gpios pin.
+- apm,nr-irqs: Optional, specify number of interrupt pins.
+- apm,irq-start: Optional, specify lowest gpio pin support interrupt.
 
 Example:
-	sbgpio: sbgpio at 17001000 {
+	sbgpio: gpio at 17001000{
 		compatible = "apm,xgene-gpio-sb";
 		reg = <0x0 0x17001000 0x0 0x400>;
 		#gpio-cells = <2>;
@@ -29,4 +47,19 @@ Example:
 				<0x0 0x2b 0x1>,
 				<0x0 0x2c 0x1>,
 				<0x0 0x2d 0x1>;
+		interrupt-parent = <&gic>;
+		#interrupt-cells = <2>;
+		interrupt-controller;
+		apm,nr-gpios = <22>;
+		apm,nr-irqs = <6>;
+		apm,irq-start = <8>;
+	};
+
+	testuser {
+		compatible = "example,testuser";
+		/* Use the GPIO_13/EXT_INT_5 line as an active high triggered
+		 * level interrupt
+		 */
+		interrupts = <5 4>;
+		interrupt-parent = <&sbgpio>;
 	};
-- 
1.7.12.4



From qnguyen at apm.com  Wed Feb 17 05:15:07 2016
From: qnguyen at apm.com (Quan Nguyen)
Date: Wed, 17 Feb 2016 20:15:07 +0700
Subject: [PATCH v7 1/3] gpio: xgene: Enable X-Gene standby GPIO as interrupt
 controller
In-Reply-To: <1455714909-3027-1-git-send-email-qnguyen@apm.com>
References: <1455714909-3027-1-git-send-email-qnguyen@apm.com>
Message-ID: <1455714909-3027-2-git-send-email-qnguyen@apm.com>

Enable X-Gene standby GPIO controller as interrupt controller to provide
its own resources. This avoids ambiguity where GIC interrupt resource is
use as X-Gene standby GPIO interrupt resource in user driver.

Signed-off-by: Y Vo <yvo at apm.com>
Signed-off-by: Quan Nguyen <qnguyen at apm.com>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
---
 drivers/gpio/gpio-xgene-sb.c | 265 +++++++++++++++++++++++++++++++++++++------
 1 file changed, 233 insertions(+), 32 deletions(-)

diff --git a/drivers/gpio/gpio-xgene-sb.c b/drivers/gpio/gpio-xgene-sb.c
index 282004d..b993b86 100644
--- a/drivers/gpio/gpio-xgene-sb.c
+++ b/drivers/gpio/gpio-xgene-sb.c
@@ -2,8 +2,9 @@
  * AppliedMicro X-Gene SoC GPIO-Standby Driver
  *
  * Copyright (c) 2014, Applied Micro Circuits Corporation
- * Author: 	Tin Huynh <tnhuynh at apm.com>.
- * 		Y Vo <yvo at apm.com>.
+ * Author:	Tin Huynh <tnhuynh at apm.com>.
+ *		Y Vo <yvo at apm.com>.
+ *		Quan Nguyen <qnguyen at apm.com>.
  *
  * This program is free software; you can redistribute  it and/or modify it
  * under  the terms of  the GNU General  Public License as published by the
@@ -28,9 +29,14 @@
 
 #include "gpiolib.h"
 
-#define XGENE_MAX_GPIO_DS		22
-#define XGENE_MAX_GPIO_DS_IRQ		6
+/* Common property names */
+#define XGENE_NIRQ_PROPERTY		"apm,nr-irqs"
+#define XGENE_NGPIO_PROPERTY		"apm,nr-gpios"
+#define XGENE_IRQ_START_PROPERTY	"apm,irq-start"
 
+#define XGENE_DFLT_MAX_NGPIO		22
+#define XGENE_DFLT_MAX_NIRQ		6
+#define XGENE_DFLT_IRQ_START_PIN	8
 #define GPIO_MASK(x)			(1U << ((x) % 32))
 
 #define MPA_GPIO_INT_LVL		0x0290
@@ -39,19 +45,32 @@
 #define MPA_GPIO_IN_ADDR 		0x02a4
 #define MPA_GPIO_SEL_LO 		0x0294
 
+#define GPIO_INT_LEVEL_H	0x000001
+#define GPIO_INT_LEVEL_L	0x000000
+
 /**
  * struct xgene_gpio_sb - GPIO-Standby private data structure.
  * @gc:				memory-mapped GPIO controllers.
- * @irq:			Mapping GPIO pins and interrupt number
- * nirq:			Number of GPIO pins that supports interrupt
+ * @regs:			GPIO register base offset
+ * @irq_domain:			GPIO interrupt domain
+ * @irq_start:			GPIO pin that start support interrupt
+ * @nirq:			Number of GPIO pins that supports interrupt
+ * @parent_irq_base:		Start parent HWIRQ
  */
 struct xgene_gpio_sb {
 	struct gpio_chip	gc;
-	u32 *irq;
-	u32 nirq;
+	void __iomem		*regs;
+	struct irq_domain	*irq_domain;
+	u16			irq_start;
+	u16			nirq;
+	u16			parent_irq_base;
 };
 
-static void xgene_gpio_set_bit(struct gpio_chip *gc, void __iomem *reg, u32 gpio, int val)
+#define HWIRQ_TO_GPIO(priv, hwirq) ((hwirq) + (priv)->irq_start)
+#define GPIO_TO_HWIRQ(priv, gpio) ((gpio) - (priv)->irq_start)
+
+static void xgene_gpio_set_bit(struct gpio_chip *gc,
+				void __iomem *reg, u32 gpio, int val)
 {
 	u32 data;
 
@@ -63,23 +82,170 @@ static void xgene_gpio_set_bit(struct gpio_chip *gc, void __iomem *reg, u32 gpio
 	gc->write_reg(reg, data);
 }
 
-static int apm_gpio_sb_to_irq(struct gpio_chip *gc, u32 gpio)
+static int xgene_gpio_sb_irq_set_type(struct irq_data *d, unsigned int type)
+{
+	struct xgene_gpio_sb *priv = irq_data_get_irq_chip_data(d);
+	int gpio = HWIRQ_TO_GPIO(priv, d->hwirq);
+	int lvl_type = GPIO_INT_LEVEL_H;
+
+	switch (type & IRQ_TYPE_SENSE_MASK) {
+	case IRQ_TYPE_EDGE_RISING:
+	case IRQ_TYPE_LEVEL_HIGH:
+		lvl_type = GPIO_INT_LEVEL_H;
+		break;
+	case IRQ_TYPE_EDGE_FALLING:
+	case IRQ_TYPE_LEVEL_LOW:
+		lvl_type = GPIO_INT_LEVEL_L;
+		break;
+	default:
+		break;
+	}
+
+	xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_SEL_LO,
+			gpio * 2, 1);
+	xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_INT_LVL,
+			d->hwirq, lvl_type);
+
+	/* Propagate IRQ type setting to parent */
+	if (type & IRQ_TYPE_EDGE_BOTH)
+		return irq_chip_set_type_parent(d, IRQ_TYPE_EDGE_RISING);
+	else
+		return irq_chip_set_type_parent(d, IRQ_TYPE_LEVEL_HIGH);
+}
+
+static struct irq_chip xgene_gpio_sb_irq_chip = {
+	.name           = "sbgpio",
+	.irq_eoi	= irq_chip_eoi_parent,
+	.irq_mask       = irq_chip_mask_parent,
+	.irq_unmask     = irq_chip_unmask_parent,
+	.irq_set_type   = xgene_gpio_sb_irq_set_type,
+};
+
+static int xgene_gpio_sb_to_irq(struct gpio_chip *gc, u32 gpio)
 {
 	struct xgene_gpio_sb *priv = gpiochip_get_data(gc);
+	struct irq_fwspec fwspec;
+
+	if ((gpio < priv->irq_start) ||
+			(gpio > HWIRQ_TO_GPIO(priv, priv->nirq)))
+		return -ENXIO;
+
+	if (gc->parent->of_node)
+		fwspec.fwnode = of_node_to_fwnode(gc->parent->of_node);
+	else
+		fwspec.fwnode = gc->parent->fwnode;
+	fwspec.param_count = 2;
+	fwspec.param[0] = GPIO_TO_HWIRQ(priv, gpio);
+	fwspec.param[1] = IRQ_TYPE_NONE;
+	return irq_create_fwspec_mapping(&fwspec);
+}
+
+static void xgene_gpio_sb_domain_activate(struct irq_domain *d,
+		struct irq_data *irq_data)
+{
+	struct xgene_gpio_sb *priv = d->host_data;
+	u32 gpio = HWIRQ_TO_GPIO(priv, irq_data->hwirq);
+
+	if (gpiochip_lock_as_irq(&priv->gc, gpio)) {
+		dev_err(priv->gc.parent,
+		"Unable to configure XGene GPIO standby pin %d as IRQ\n",
+				gpio);
+		return;
+	}
+
+	xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_SEL_LO,
+			gpio * 2, 1);
+}
+
+static void xgene_gpio_sb_domain_deactivate(struct irq_domain *d,
+		struct irq_data *irq_data)
+{
+	struct xgene_gpio_sb *priv = d->host_data;
+	u32 gpio = HWIRQ_TO_GPIO(priv, irq_data->hwirq);
+
+	gpiochip_unlock_as_irq(&priv->gc, gpio);
+	xgene_gpio_set_bit(&priv->gc, priv->regs + MPA_GPIO_SEL_LO,
+			gpio * 2, 0);
+}
+
+static int xgene_gpio_sb_domain_translate(struct irq_domain *d,
+		struct irq_fwspec *fwspec,
+		unsigned long *hwirq,
+		unsigned int *type)
+{
+	struct xgene_gpio_sb *priv = d->host_data;
 
-	if (priv->irq[gpio])
-		return priv->irq[gpio];
+	if ((fwspec->param_count != 2) ||
+		(fwspec->param[0] >= priv->nirq))
+		return -EINVAL;
+	*hwirq = fwspec->param[0];
+	*type = fwspec->param[1];
+	return 0;
+}
+
+static int xgene_gpio_sb_domain_alloc(struct irq_domain *domain,
+					unsigned int virq,
+					unsigned int nr_irqs, void *data)
+{
+	struct irq_fwspec *fwspec = data;
+	struct irq_fwspec parent_fwspec;
+	struct xgene_gpio_sb *priv = domain->host_data;
+	irq_hw_number_t hwirq;
+	unsigned int i;
+
+	hwirq = fwspec->param[0];
+	for (i = 0; i < nr_irqs; i++)
+		irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
+				&xgene_gpio_sb_irq_chip, priv);
+
+	parent_fwspec.fwnode = domain->parent->fwnode;
+	if (is_of_node(parent_fwspec.fwnode)) {
+		parent_fwspec.param_count = 3;
+		parent_fwspec.param[0] = 0;/* SPI */
+		/* Skip SGIs and PPIs*/
+		parent_fwspec.param[1] = hwirq + priv->parent_irq_base - 32;
+		parent_fwspec.param[2] = fwspec->param[1];
+	} else if (is_fwnode_irqchip(parent_fwspec.fwnode)) {
+		parent_fwspec.param_count = 2;
+		parent_fwspec.param[0] = hwirq + priv->parent_irq_base;
+		parent_fwspec.param[1] = fwspec->param[1];
+	} else
+		return -EINVAL;
+
+	return irq_domain_alloc_irqs_parent(domain, virq, nr_irqs,
+			&parent_fwspec);
+}
+
+static void xgene_gpio_sb_domain_free(struct irq_domain *domain,
+		unsigned int virq,
+		unsigned int nr_irqs)
+{
+	struct irq_data *d;
+	unsigned int i;
 
-	return -ENXIO;
+	for (i = 0; i < nr_irqs; i++) {
+		d = irq_domain_get_irq_data(domain, virq + i);
+		irq_domain_reset_irq_data(d);
+	}
 }
 
+static const struct irq_domain_ops xgene_gpio_sb_domain_ops = {
+	.translate      = xgene_gpio_sb_domain_translate,
+	.alloc          = xgene_gpio_sb_domain_alloc,
+	.free           = xgene_gpio_sb_domain_free,
+	.activate	= xgene_gpio_sb_domain_activate,
+	.deactivate	= xgene_gpio_sb_domain_deactivate,
+};
+
 static int xgene_gpio_sb_probe(struct platform_device *pdev)
 {
 	struct xgene_gpio_sb *priv;
-	u32 ret, i;
-	u32 default_lines[] = {0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D};
+	u32 ret;
 	struct resource *res;
 	void __iomem *regs;
+	struct irq_domain *parent_domain = NULL;
+	struct fwnode_handle *fwnode;
+	u32 val32;
 
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv)
@@ -90,6 +256,18 @@ static int xgene_gpio_sb_probe(struct platform_device *pdev)
 	if (IS_ERR(regs))
 		return PTR_ERR(regs);
 
+	priv->regs = regs;
+
+	ret = platform_get_irq(pdev, 0);
+	if (ret > 0) {
+		priv->parent_irq_base = irq_get_irq_data(ret)->hwirq;
+		parent_domain = irq_get_irq_data(ret)->domain;
+	}
+	if (!parent_domain) {
+		dev_err(&pdev->dev, "unable to obtain parent domain\n");
+		return -ENODEV;
+	}
+
 	ret = bgpio_init(&priv->gc, &pdev->dev, 4,
 			regs + MPA_GPIO_IN_ADDR,
 			regs + MPA_GPIO_OUT_ADDR, NULL,
@@ -97,30 +275,51 @@ static int xgene_gpio_sb_probe(struct platform_device *pdev)
         if (ret)
                 return ret;
 
-	priv->gc.to_irq = apm_gpio_sb_to_irq;
-	priv->gc.ngpio = XGENE_MAX_GPIO_DS;
+	priv->gc.to_irq = xgene_gpio_sb_to_irq;
 
-	priv->nirq = XGENE_MAX_GPIO_DS_IRQ;
+	/* Retrieve start irq pin, use default if property not found */
+	priv->irq_start = XGENE_DFLT_IRQ_START_PIN;
+	if (!device_property_read_u32(&pdev->dev,
+					XGENE_IRQ_START_PROPERTY, &val32))
+		priv->irq_start = val32;
 
-	priv->irq = devm_kzalloc(&pdev->dev, sizeof(u32) * XGENE_MAX_GPIO_DS,
-				   GFP_KERNEL);
-	if (!priv->irq)
-		return -ENOMEM;
+	/* Retrieve number irqs, use default if property not found */
+	priv->nirq = XGENE_DFLT_MAX_NIRQ;
+	if (!device_property_read_u32(&pdev->dev, XGENE_NIRQ_PROPERTY, &val32))
+		priv->nirq = val32;
 
-	for (i = 0; i < priv->nirq; i++) {
-		priv->irq[default_lines[i]] = platform_get_irq(pdev, i);
-		xgene_gpio_set_bit(&priv->gc, regs + MPA_GPIO_SEL_LO,
-                                   default_lines[i] * 2, 1);
-		xgene_gpio_set_bit(&priv->gc, regs + MPA_GPIO_INT_LVL, i, 1);
-	}
+	/* Retrieve number gpio, use default if property not found */
+	priv->gc.ngpio = XGENE_DFLT_MAX_NGPIO;
+	if (!device_property_read_u32(&pdev->dev, XGENE_NGPIO_PROPERTY, &val32))
+		priv->gc.ngpio = val32;
+
+	dev_info(&pdev->dev, "Support %d gpios, %d irqs start from pin %d\n",
+			priv->gc.ngpio, priv->nirq, priv->irq_start);
 
 	platform_set_drvdata(pdev, priv);
 
-	ret = gpiochip_add_data(&priv->gc, priv);
-	if (ret)
-		dev_err(&pdev->dev, "failed to register X-Gene GPIO Standby driver\n");
+	if (pdev->dev.of_node)
+		fwnode = of_node_to_fwnode(pdev->dev.of_node);
 	else
-		dev_info(&pdev->dev, "X-Gene GPIO Standby driver registered\n");
+		fwnode = pdev->dev.fwnode;
+
+	priv->irq_domain = irq_domain_create_hierarchy(parent_domain,
+					0, priv->nirq, fwnode,
+					&xgene_gpio_sb_domain_ops, priv);
+	if (!priv->irq_domain)
+		return -ENODEV;
+
+	priv->gc.irqdomain = priv->irq_domain;
+
+	ret = gpiochip_add_data(&priv->gc, priv);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"failed to register X-Gene GPIO Standby driver\n");
+		irq_domain_remove(priv->irq_domain);
+		return ret;
+	}
+
+	dev_info(&pdev->dev, "X-Gene GPIO Standby driver registered\n");
 
 	if (priv->nirq > 0) {
 		/* Register interrupt handlers for gpio signaled acpi events */
@@ -138,6 +337,8 @@ static int xgene_gpio_sb_remove(struct platform_device *pdev)
 		acpi_gpiochip_free_interrupts(&priv->gc);
 	}
 
+	irq_domain_remove(priv->irq_domain);
+
 	gpiochip_remove(&priv->gc);
 	return 0;
 }
-- 
1.7.12.4



From qnguyen at apm.com  Wed Feb 17 05:15:09 2016
From: qnguyen at apm.com (Quan Nguyen)
Date: Wed, 17 Feb 2016 20:15:09 +0700
Subject: [PATCH v7 3/3] arm64: dts: Update X-Gene standby GPIO controller DTS
 entries
In-Reply-To: <1455714909-3027-1-git-send-email-qnguyen@apm.com>
References: <1455714909-3027-1-git-send-email-qnguyen@apm.com>
Message-ID: <1455714909-3027-4-git-send-email-qnguyen@apm.com>

Update APM X-Gene standby GPIO controller DTS entries to enable it
as interrupt controller.

Signed-off-by: Y Vo <yvo at apm.com>
Signed-off-by: Quan Nguyen <qnguyen at apm.com>
---
 arch/arm64/boot/dts/apm/apm-storm.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index fe30f76..0f733da 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -883,6 +883,9 @@
 					<0x0 0x2b 0x1>,
 					<0x0 0x2c 0x1>,
 					<0x0 0x2d 0x1>;
+			interrupt-parent = <&gic>;
+			#interrupt-cells = <2>;
+			interrupt-controller;
 		};
 
 		rtc: rtc at 10510000 {
-- 
1.7.12.4



From nsekhar at ti.com  Wed Feb 17 05:26:07 2016
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 17 Feb 2016 18:56:07 +0530
Subject: [PATCH 3/3] ARM: DTS: da850: add DT node for tps6507x-ts
In-Reply-To: <1454308130-12452-5-git-send-email-sushaanth.s@ti.com>
References: <1454308130-12452-1-git-send-email-sushaanth.s@ti.com>
 <1454308130-12452-5-git-send-email-sushaanth.s@ti.com>
Message-ID: <56C474EF.5040006@ti.com>

On Monday 01 February 2016 11:58 AM, Sushaanth Srirangapathi wrote:
> add tps6507x touchscreen device tree node information to
> DA850 EVM
> 
> Signed-off-by: Sushaanth Srirangapathi <sushaanth.s at ti.com>

Acked-by: Sekhar Nori <nsekhar at ti.com>

I can queue 3/3 once driver changes are accepted (let me know about that
because I am not copied on this series).

If Dmitry wants to queue the whole series once he has had a look, thats
fine too. I have nothing that will clash with this.

Regards,
Sekhar



From s.hauer at pengutronix.de  Wed Feb 17 05:28:46 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 14:28:46 +0100
Subject: [PATCH] i.MX SPI DMA cleanup
Message-ID: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>

This picks up a series sent by Anton Bondarenko last year. It
contains the remaining not yet upstreamed patches from Antons series
plus some more DMA related cleanup patches.

My mission was to hunt a bug in the DMA code path sometimes causing
an additional word in the RX FIFO which locked up the driver in the
next transfer. It turned out that this was no bug in the driver but
instead in the device tree: We used the wrong SDMA script for i.MX6.
The ECSPI cores are connected through the SPBA, so according to the
reference manual we need the shp/mcu scripts rather than the app/mcu
scripts.

Shawn, please pick up the last patch. The rest can go through the SPI
tree. The last patch has no dependency on the remaining patches.

Sascha

----------------------------------------------------------------
Anton Bondarenko (3):
      spi: imx: allow only WML aligned transfers to use DMA
      spi: imx: replace fixed timeout with calculated
      spi: imx: add support for all SPI word width for DMA

Sascha Hauer (10):
      spi: imx: use proper dev_* functions for driver messages
      spi: imx: drop fallback to PIO
      spi: imx: initialize usedma earlier
      spi: imx: drop unnecessary read/modify/write
      spi: imx: drop unncessary dma_is_inited variable
      spi: imx: remove unnecessary bit clearing in mx51_ecspi_config
      spi: imx: make some register defines simpler
      spi: imx: set MX51_ECSPI_CTRL_SMC bit in setup function
      spi: imx: drop bogus tests for rx/tx bufs in DMA transfer
      ARM: dts: imx6: Use correct SDMA script for SPI cores

 arch/arm/boot/dts/imx6qdl.dtsi |   8 +-
 drivers/spi/spi-imx.c          | 350 +++++++++++++++++++++--------------------
 2 files changed, 185 insertions(+), 173 deletions(-)


From s.hauer at pengutronix.de  Wed Feb 17 05:28:50 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 14:28:50 +0100
Subject: [PATCH 04/13] spi: imx: drop fallback to PIO
In-Reply-To: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455715739-25161-5-git-send-email-s.hauer@pengutronix.de>

At the moment the driver decides to fallback to PIO mode the buffers
are already mapped for DMA. It's a bug to access them with the CPU
afterwards, so we cannot just fallback to PIO mode.
It should not be necessary anyway, since we only use DMA when we
verified that it's possible in the fist place, so when prep_slave_sg
fails it's a bug, either in the SDMA driver or in the can_dma
implementation.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index b277375..5a48d07 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -945,7 +945,7 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 					tx->sgl, tx->nents, DMA_MEM_TO_DEV,
 					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
 		if (!desc_tx)
-			goto no_dma;
+			return -EINVAL;
 
 		desc_tx->callback = spi_imx_dma_tx_callback;
 		desc_tx->callback_param = (void *)spi_imx;
@@ -957,7 +957,7 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 					rx->sgl, rx->nents, DMA_DEV_TO_MEM,
 					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
 		if (!desc_rx)
-			goto no_dma;
+			return -EINVAL;
 
 		desc_rx->callback = spi_imx_dma_rx_callback;
 		desc_rx->callback_param = (void *)spi_imx;
@@ -1010,10 +1010,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 		ret = transfer->len;
 
 	return ret;
-
-no_dma:
-	dev_warn_once(spi_imx->dev, "DMA not available, falling back to PIO\n");
-	return -EAGAIN;
 }
 
 static int spi_imx_pio_transfer(struct spi_device *spi,
@@ -1040,15 +1036,12 @@ static int spi_imx_pio_transfer(struct spi_device *spi,
 static int spi_imx_transfer(struct spi_device *spi,
 				struct spi_transfer *transfer)
 {
-	int ret;
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
 
 	if (spi_imx->bitbang.master->can_dma &&
 	    spi_imx_can_dma(spi_imx->bitbang.master, spi, transfer)) {
 		spi_imx->usedma = true;
-		ret = spi_imx_dma_transfer(spi_imx, transfer);
-		if (ret != -EAGAIN)
-			return ret;
+		return spi_imx_dma_transfer(spi_imx, transfer);
 	}
 	spi_imx->usedma = false;
 
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 17 05:28:53 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 14:28:53 +0100
Subject: [PATCH 07/13] spi: imx: drop unncessary dma_is_inited variable
In-Reply-To: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455715739-25161-8-git-send-email-s.hauer@pengutronix.de>

There's no need for an extra dma_is_inited variable when we can
equally well check for the existence of a DMA channel.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 073a134..57b7af8 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -102,7 +102,6 @@ struct spi_imx_data {
 	unsigned int txfifo; /* number of words pushed in tx FIFO */
 
 	/* DMA */
-	unsigned int dma_is_inited;
 	unsigned int dma_finished;
 	bool usedma;
 	u32 wml;
@@ -205,7 +204,7 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
 
-	if (spi_imx->dma_is_inited && transfer->len >= spi_imx->wml &&
+	if (master->dma_rx && transfer->len >= spi_imx->wml &&
 	    (transfer->len % spi_imx->wml) == 0)
 		return true;
 	return false;
@@ -827,8 +826,6 @@ static void spi_imx_sdma_exit(struct spi_imx_data *spi_imx)
 		dma_release_channel(master->dma_tx);
 		master->dma_tx = NULL;
 	}
-
-	spi_imx->dma_is_inited = 0;
 }
 
 static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
@@ -888,7 +885,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 	master->max_dma_len = MAX_SDMA_BD_BYTES;
 	spi_imx->bitbang.master->flags = SPI_MASTER_MUST_RX |
 					 SPI_MASTER_MUST_TX;
-	spi_imx->dma_is_inited = 1;
 
 	return 0;
 err:
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 17 05:28:58 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 14:28:58 +0100
Subject: [PATCH 12/13] spi: imx: drop bogus tests for rx/tx bufs in DMA
 transfer
In-Reply-To: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455715739-25161-13-git-send-email-s.hauer@pengutronix.de>

The driver tries to be clever by only setting up DMA channels when
the corresponding sg tables are non NULL. The sg tables are embedded
structs in struct spi_transfer, so they are guaranteed to be non NULL
which makes the if(tx)/if(rx) tests completely bogus. The driver even
sets the SPI_MASTER_MUST_RX / SPI_MASTER_MUST_TX flags which makes sure
the sg tables are not only present but also non empty.
Drop the tests and make the DMA path easier to follow.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 78 +++++++++++++++++++++------------------------------
 1 file changed, 32 insertions(+), 46 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 3512c2f..9fc1de0 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -975,48 +975,37 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 				struct spi_transfer *transfer)
 {
 	struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
-	int ret;
 	unsigned long transfer_timeout;
 	unsigned long timeout;
 	struct spi_master *master = spi_imx->bitbang.master;
 	struct sg_table *tx = &transfer->tx_sg, *rx = &transfer->rx_sg;
 
-	if (tx) {
-		desc_tx = dmaengine_prep_slave_sg(master->dma_tx,
-					tx->sgl, tx->nents, DMA_MEM_TO_DEV,
-					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
-		if (!desc_tx)
-			return -EINVAL;
-
-		desc_tx->callback = spi_imx_dma_tx_callback;
-		desc_tx->callback_param = (void *)spi_imx;
-		dmaengine_submit(desc_tx);
-	}
+	/*
+	 * The TX DMA setup starts the transfer, so make sure RX is configured
+	 * before TX.
+	 */
+	desc_rx = dmaengine_prep_slave_sg(master->dma_rx,
+				rx->sgl, rx->nents, DMA_DEV_TO_MEM,
+				DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	if (!desc_rx)
+		return -EINVAL;
 
-	if (rx) {
-		desc_rx = dmaengine_prep_slave_sg(master->dma_rx,
-					rx->sgl, rx->nents, DMA_DEV_TO_MEM,
-					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
-		if (!desc_rx)
-			return -EINVAL;
+	desc_rx->callback = spi_imx_dma_rx_callback;
+	desc_rx->callback_param = (void *)spi_imx;
+	dmaengine_submit(desc_rx);
+	reinit_completion(&spi_imx->dma_rx_completion);
+	dma_async_issue_pending(master->dma_rx);
 
-		desc_rx->callback = spi_imx_dma_rx_callback;
-		desc_rx->callback_param = (void *)spi_imx;
-		dmaengine_submit(desc_rx);
-	}
+	desc_tx = dmaengine_prep_slave_sg(master->dma_tx,
+				tx->sgl, tx->nents, DMA_MEM_TO_DEV,
+				DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	if (!desc_tx)
+		return -EINVAL;
 
-	reinit_completion(&spi_imx->dma_rx_completion);
+	desc_tx->callback = spi_imx_dma_tx_callback;
+	desc_tx->callback_param = (void *)spi_imx;
+	dmaengine_submit(desc_tx);
 	reinit_completion(&spi_imx->dma_tx_completion);
-
-	/*
-	 * Set these order to avoid potential RX overflow. The overflow may
-	 * happen if we enable SPI HW before starting RX DMA due to rescheduling
-	 * for another task and/or interrupt.
-	 * So RX DMA enabled first to make sure data would be read out from FIFO
-	 * ASAP. TX DMA enabled next to start filling TX FIFO with new data.
-	 * And finaly SPI HW enabled to start actual data transfer.
-	 */
-	dma_async_issue_pending(master->dma_rx);
 	dma_async_issue_pending(master->dma_tx);
 
 	transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len);
@@ -1028,22 +1017,19 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 		dev_err(spi_imx->dev, "I/O Error in DMA TX\n");
 		dmaengine_terminate_all(master->dma_tx);
 		dmaengine_terminate_all(master->dma_rx);
-	} else {
-		timeout = wait_for_completion_timeout(
-				&spi_imx->dma_rx_completion, transfer_timeout);
-		if (!timeout) {
-			dev_err(spi_imx->dev, "I/O Error in DMA RX\n");
-			spi_imx->devtype_data->reset(spi_imx);
-			dmaengine_terminate_all(master->dma_rx);
-		}
+		return -ETIMEDOUT;
 	}
 
-	if (!timeout)
-		ret = -ETIMEDOUT;
-	else
-		ret = transfer->len;
+	timeout = wait_for_completion_timeout(&spi_imx->dma_rx_completion,
+					      transfer_timeout);
+	if (!timeout) {
+		dev_err(&master->dev, "I/O Error in DMA RX\n");
+		spi_imx->devtype_data->reset(spi_imx);
+		dmaengine_terminate_all(master->dma_rx);
+		return -ETIMEDOUT;
+	}
 
-	return ret;
+	return transfer->len;
 }
 
 static int spi_imx_pio_transfer(struct spi_device *spi,
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 17 05:28:47 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 14:28:47 +0100
Subject: [PATCH 01/13] spi: imx: allow only WML aligned transfers to use DMA
In-Reply-To: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455715739-25161-2-git-send-email-s.hauer@pengutronix.de>

From: Anton Bondarenko <anton.bondarenko.sama at gmail.com>

RX DMA tail data handling doesn't work correctly in many cases with current
implementation. It happens because SPI core was setup to generates both RX
and RX TAIL events. And RX TAIL event does not work correctly.
This can be easily verified by sending SPI transaction with size modulus
WML(32 in our case) not equal 0.

Also removing change introduced in f6ee9b582d2db652497b73c1f117591dfb6d3a90
since this change only fix usecases with transfer size from 33 to 128 bytes
and doesn't fix 129 bytes and bigger.

This is output from transaction with len 138 bytes in loopback mode at 10Mhz:
TX0000: a3 97 a2 55 53 be f1 fc f9 79 6b 52 14 13 e9 e2
TX0010: 2d 51 8e 1f 56 08 57 27 a7 05 d4 d0 52 82 77 75
TX0020: 1b 99 4a ed 58 3d 6a 52 36 d5 24 4a 68 8e ad 95
TX0030: 5f 3c 35 b5 c4 8c dd 6c 11 32 3d e2 b4 b4 59 cf
TX0040: ce 23 3d 27 df a7 f9 96 fc 1e e0 66 2c 0e 7b 8c
TX0050: ca 30 42 8f bc 9f 7b ce d1 b8 b1 87 ec 8a d6 bb
TX0060: 2e 15 63 0e 3c dc a4 3a 7a 06 20 a7 93 1b 34 dd
TX0070: 4c f5 ec 88 96 68 d6 68 a0 09 6f 8e 93 47 c9 41
TX0080: db ac cf 97 89 f3 51 05 79 71

RX0000: a3 97 a2 55 53 be f1 fc f9 79 6b 52 14 13 e9 e2
RX0010: 2d 51 8e 1f 56 08 57 27 a7 05 d4 d0 52 82 77 75
RX0020: 1b 99 4a ed 58 3d 6a 52 36 d5 24 4a 68 8e ad 95
RX0030: 5f 3c 35 00 00 b5 00 00 00 c4 00 00 8c 00 00 dd
RX0040: 6c 11 32 3d e2 b4 b4 59 cf ce 23 3d 27 df a7 f9
RX0050: 96 fc 1e e0 66 2c 0e 7b 8c ca 30 42 8f 1f 1f bc
RX0060: 9f 7b ce d1 b8 b1 87 ec 8a d6 bb 2e 15 63 0e ed
RX0070: ed 3c 58 58 58 dc 3d 3d a4 6a 6a 3a 52 52 7a 36
RX0080: 06 20 a7 93 1b 34 dd 4c f5 ec

Zeros at offset 33 and 34 caused by reading empty RX FIFO which not possible
if DMA RX read was triggered by RX event. This mean DMA was triggered
by RX TAIL event.

Signed-off-by: Anton Bondarenko <anton.bondarenko.sama at gmail.com>
Signed-off--by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 17 ++---------------
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index d98c33c..08492d6 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -204,8 +204,8 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
 
-	if (spi_imx->dma_is_inited &&
-	    transfer->len > spi_imx->wml * sizeof(u32))
+	if (spi_imx->dma_is_inited && transfer->len >= spi_imx->wml &&
+	    (transfer->len % spi_imx->wml) == 0)
 		return true;
 	return false;
 }
@@ -919,8 +919,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
 	int ret;
 	unsigned long timeout;
-	u32 dma;
-	int left;
 	struct spi_master *master = spi_imx->bitbang.master;
 	struct sg_table *tx = &transfer->tx_sg, *rx = &transfer->rx_sg;
 
@@ -954,13 +952,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	/* Trigger the cspi module. */
 	spi_imx->dma_finished = 0;
 
-	dma = readl(spi_imx->base + MX51_ECSPI_DMA);
-	dma = dma & (~MX51_ECSPI_DMA_RXT_WML_MASK);
-	/* Change RX_DMA_LENGTH trigger dma fetch tail data */
-	left = transfer->len % spi_imx->wml;
-	if (left)
-		writel(dma | (left << MX51_ECSPI_DMA_RXT_WML_OFFSET),
-				spi_imx->base + MX51_ECSPI_DMA);
 	/*
 	 * Set these order to avoid potential RX overflow. The overflow may
 	 * happen if we enable SPI HW before starting RX DMA due to rescheduling
@@ -992,10 +983,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 			spi_imx->devtype_data->reset(spi_imx);
 			dmaengine_terminate_all(master->dma_rx);
 		}
-		dma &= ~MX51_ECSPI_DMA_RXT_WML_MASK;
-		writel(dma |
-		       spi_imx->wml << MX51_ECSPI_DMA_RXT_WML_OFFSET,
-		       spi_imx->base + MX51_ECSPI_DMA);
 	}
 
 	spi_imx->dma_finished = 1;
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 17 05:28:59 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 14:28:59 +0100
Subject: [PATCH 13/13] ARM: dts: imx6: Use correct SDMA script for SPI cores
In-Reply-To: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455715739-25161-14-git-send-email-s.hauer@pengutronix.de>

According to the reference manual the shp_2_mcu / mcu_2_shp
scripts must be used for devices connected through the SPBA.

This fixes an issue we saw with DMA transfers from SPI NOR Flashes.
Sometimes the SPI controller RX FIFO was not empty after a DMA
transfer and the driver got stuck in the next PIO transfer when
it read one word more than expected.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 arch/arm/boot/dts/imx6qdl.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 4f6ae92..06d2c4e 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -261,7 +261,7 @@
 					clocks = <&clks IMX6QDL_CLK_ECSPI1>,
 						 <&clks IMX6QDL_CLK_ECSPI1>;
 					clock-names = "ipg", "per";
-					dmas = <&sdma 3 7 1>, <&sdma 4 7 2>;
+					dmas = <&sdma 3 8 1>, <&sdma 4 8 2>;
 					dma-names = "rx", "tx";
 					status = "disabled";
 				};
@@ -275,7 +275,7 @@
 					clocks = <&clks IMX6QDL_CLK_ECSPI2>,
 						 <&clks IMX6QDL_CLK_ECSPI2>;
 					clock-names = "ipg", "per";
-					dmas = <&sdma 5 7 1>, <&sdma 6 7 2>;
+					dmas = <&sdma 5 8 1>, <&sdma 6 8 2>;
 					dma-names = "rx", "tx";
 					status = "disabled";
 				};
@@ -289,7 +289,7 @@
 					clocks = <&clks IMX6QDL_CLK_ECSPI3>,
 						 <&clks IMX6QDL_CLK_ECSPI3>;
 					clock-names = "ipg", "per";
-					dmas = <&sdma 7 7 1>, <&sdma 8 7 2>;
+					dmas = <&sdma 7 8 1>, <&sdma 8 8 2>;
 					dma-names = "rx", "tx";
 					status = "disabled";
 				};
@@ -303,7 +303,7 @@
 					clocks = <&clks IMX6QDL_CLK_ECSPI4>,
 						 <&clks IMX6QDL_CLK_ECSPI4>;
 					clock-names = "ipg", "per";
-					dmas = <&sdma 9 7 1>, <&sdma 10 7 2>;
+					dmas = <&sdma 9 8 1>, <&sdma 10 8 2>;
 					dma-names = "rx", "tx";
 					status = "disabled";
 				};
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 17 05:28:49 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 14:28:49 +0100
Subject: [PATCH 03/13] spi: imx: replace fixed timeout with calculated
In-Reply-To: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455715739-25161-4-git-send-email-s.hauer@pengutronix.de>

From: Anton Bondarenko <anton.bondarenko.sama at gmail.com>

Fixed timeout value can fire while transaction is ongoing. This may happen
because there are no strict requirements on SPI transaction duration.
Dynamic timeout value is generated based on SCLK and transaction size.

There is also 4 * SCLK delay between TX bursts related to HW internal CS change.

Signed-off-by: Anton Bondarenko <anton.bondarenko.sama at gmail.com>
---
 drivers/spi/spi-imx.c | 24 +++++++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 7904d45..b277375 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -56,7 +56,6 @@
 
 /* The maximum  bytes that a sdma BD can transfer.*/
 #define MAX_SDMA_BD_BYTES  (1 << 15)
-#define IMX_DMA_TIMEOUT (msecs_to_jiffies(3000))
 struct spi_imx_config {
 	unsigned int speed_hz;
 	unsigned int bpw;
@@ -93,6 +92,7 @@ struct spi_imx_data {
 	struct clk *clk_per;
 	struct clk *clk_ipg;
 	unsigned long spi_clk;
+	unsigned int spi_bus_clk;
 
 	unsigned int count;
 	void (*tx)(struct spi_imx_data *);
@@ -333,6 +333,7 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 
 	/* set clock speed */
 	ctrl |= mx51_ecspi_clkdiv(spi_imx, config->speed_hz, &clk);
+	spi_imx->spi_bus_clk = clk;
 
 	/* set chip select to use */
 	ctrl |= MX51_ECSPI_CTRL_CS(config->cs);
@@ -915,11 +916,26 @@ static void spi_imx_dma_tx_callback(void *cookie)
 	complete(&spi_imx->dma_tx_completion);
 }
 
+static int spi_imx_calculate_timeout(struct spi_imx_data *spi_imx, int size)
+{
+	unsigned long timeout = 0;
+
+	/* Time with actual data transfer and CS change delay related to HW */
+	timeout = (8 + 4) * size / spi_imx->spi_bus_clk;
+
+	/* Add extra second for scheduler related activities */
+	timeout += 1;
+
+	/* Double calculated timeout */
+	return msecs_to_jiffies(2 * timeout * MSEC_PER_SEC);
+}
+
 static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 				struct spi_transfer *transfer)
 {
 	struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
 	int ret;
+	unsigned long transfer_timeout;
 	unsigned long timeout;
 	struct spi_master *master = spi_imx->bitbang.master;
 	struct sg_table *tx = &transfer->tx_sg, *rx = &transfer->rx_sg;
@@ -966,16 +982,18 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	dma_async_issue_pending(master->dma_tx);
 	spi_imx->devtype_data->trigger(spi_imx);
 
+	transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len);
+
 	/* Wait SDMA to finish the data transfer.*/
 	timeout = wait_for_completion_timeout(&spi_imx->dma_tx_completion,
-						IMX_DMA_TIMEOUT);
+						transfer_timeout);
 	if (!timeout) {
 		dev_err(spi_imx->dev, "I/O Error in DMA TX\n");
 		dmaengine_terminate_all(master->dma_tx);
 		dmaengine_terminate_all(master->dma_rx);
 	} else {
 		timeout = wait_for_completion_timeout(
-				&spi_imx->dma_rx_completion, IMX_DMA_TIMEOUT);
+				&spi_imx->dma_rx_completion, transfer_timeout);
 		if (!timeout) {
 			dev_err(spi_imx->dev, "I/O Error in DMA RX\n");
 			spi_imx->devtype_data->reset(spi_imx);
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 17 05:28:56 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 14:28:56 +0100
Subject: [PATCH 10/13] spi: imx: make some register defines simpler
In-Reply-To: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455715739-25161-11-git-send-email-s.hauer@pengutronix.de>

The watermark levels in the DMA register are write only, the driver
should never have to read them back from the hardware. Replace the
current _MASK and _OFFSET defines with defines taking the watermark
level directly.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 2476de7..dee5e28 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -256,12 +256,9 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 #define MX51_ECSPI_INT_RREN		(1 <<  3)
 
 #define MX51_ECSPI_DMA      0x14
-#define MX51_ECSPI_DMA_TX_WML_OFFSET	0
-#define MX51_ECSPI_DMA_TX_WML_MASK	0x3F
-#define MX51_ECSPI_DMA_RX_WML_OFFSET	16
-#define MX51_ECSPI_DMA_RX_WML_MASK	(0x3F << 16)
-#define MX51_ECSPI_DMA_RXT_WML_OFFSET	24
-#define MX51_ECSPI_DMA_RXT_WML_MASK	(0x3F << 24)
+#define MX51_ECSPI_DMA_TX_WML(wml)	((wml) & 0x3f)
+#define MX51_ECSPI_DMA_RX_WML(wml)	(((wml) & 0x3f) << 16)
+#define MX51_ECSPI_DMA_RXT_WML(wml)	(((wml) & 0x3f) << 24)
 
 #define MX51_ECSPI_DMA_TEDEN		(1 << 7)
 #define MX51_ECSPI_DMA_RXDEN		(1 << 23)
@@ -408,9 +405,9 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 	 * and enable DMA request.
 	 */
 
-	writel(spi_imx->wml << MX51_ECSPI_DMA_RX_WML_OFFSET |
-		spi_imx->wml << MX51_ECSPI_DMA_TX_WML_OFFSET |
-		spi_imx->wml << MX51_ECSPI_DMA_RXT_WML_OFFSET |
+	writel(MX51_ECSPI_DMA_RX_WML(spi_imx->wml) |
+		MX51_ECSPI_DMA_TX_WML(spi_imx->wml) |
+		MX51_ECSPI_DMA_RXT_WML(spi_imx->wml) |
 		MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
 		MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
 
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 17 05:28:54 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 14:28:54 +0100
Subject: [PATCH 08/13] spi: imx: add support for all SPI word width for DMA
In-Reply-To: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455715739-25161-9-git-send-email-s.hauer@pengutronix.de>

From: Anton Bondarenko <anton.bondarenko.sama at gmail.com>

DMA transfer for SPI was limited to up to 8 bits word size until now.
Sync in SPI burst size and DMA bus width is necessary to correctly
support 16 and 32 BPW.

Signed-off-by: Anton Bondarenko <anton.bondarenko.sama at gmail.com>
Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 118 ++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 91 insertions(+), 27 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 57b7af8..6a0e004 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -89,11 +89,15 @@ struct spi_imx_data {
 
 	struct completion xfer_done;
 	void __iomem *base;
+	unsigned long base_phys;
+
 	struct clk *clk_per;
 	struct clk *clk_ipg;
 	unsigned long spi_clk;
 	unsigned int spi_bus_clk;
 
+	unsigned int bytes_per_word;
+
 	unsigned int count;
 	void (*tx)(struct spi_imx_data *);
 	void (*rx)(struct spi_imx_data *);
@@ -199,15 +203,35 @@ static unsigned int spi_imx_clkdiv_2(unsigned int fin,
 	return 7;
 }
 
+static int spi_imx_bytes_per_word(const int bpw)
+{
+	return DIV_ROUND_UP(bpw, BITS_PER_BYTE);
+}
+
 static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 			 struct spi_transfer *transfer)
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+	unsigned int bpw = transfer->bits_per_word;
+
+	if (!master->dma_rx)
+		return false;
+
+	if (!bpw)
+		bpw = spi->bits_per_word;
+
+	bpw = spi_imx_bytes_per_word(bpw);
+
+	if (bpw != 1 && bpw != 2 && bpw != 4)
+		return false;
+
+	if (transfer->len < spi_imx->wml * bpw)
+		return false;
+
+	if (transfer->len % (spi_imx->wml * bpw))
+		return false;
 
-	if (master->dma_rx && transfer->len >= spi_imx->wml &&
-	    (transfer->len % spi_imx->wml) == 0)
-		return true;
-	return false;
+	return true;
 }
 
 #define MX51_ECSPI_CTRL		0x08
@@ -775,11 +799,63 @@ static irqreturn_t spi_imx_isr(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static int spi_imx_dma_configure(struct spi_master *master,
+				 int bytes_per_word)
+{
+	int ret;
+	enum dma_slave_buswidth buswidth;
+	struct dma_slave_config rx = {}, tx = {};
+	struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+
+	if (bytes_per_word == spi_imx->bytes_per_word)
+		/* Same as last time */
+		return 0;
+
+	switch (bytes_per_word) {
+	case 4:
+		buswidth = DMA_SLAVE_BUSWIDTH_4_BYTES;
+		break;
+	case 2:
+		buswidth = DMA_SLAVE_BUSWIDTH_2_BYTES;
+		break;
+	case 1:
+		buswidth = DMA_SLAVE_BUSWIDTH_1_BYTE;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	tx.direction = DMA_MEM_TO_DEV;
+	tx.dst_addr = spi_imx->base_phys + MXC_CSPITXDATA;
+	tx.dst_addr_width = buswidth;
+	tx.dst_maxburst = spi_imx->wml;
+	ret = dmaengine_slave_config(master->dma_tx, &tx);
+	if (ret) {
+		dev_err(spi_imx->dev, "TX dma configuration failed with %d\n", ret);
+		return ret;
+	}
+
+	rx.direction = DMA_DEV_TO_MEM;
+	rx.src_addr = spi_imx->base_phys + MXC_CSPIRXDATA;
+	rx.src_addr_width = buswidth;
+	rx.src_maxburst = spi_imx->wml;
+	ret = dmaengine_slave_config(master->dma_rx, &rx);
+	if (ret) {
+		dev_err(spi_imx->dev, "RX dma configuration failed with %d\n", ret);
+		return ret;
+	}
+
+	spi_imx->bytes_per_word = bytes_per_word;
+
+	return 0;
+}
+
 static int spi_imx_setupxfer(struct spi_device *spi,
 				 struct spi_transfer *t)
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
 	struct spi_imx_config config;
+	int ret;
 
 	config.bpw = t ? t->bits_per_word : spi->bits_per_word;
 	config.speed_hz  = t ? t->speed_hz : spi->max_speed_hz;
@@ -808,6 +884,13 @@ static int spi_imx_setupxfer(struct spi_device *spi,
 	else
 		spi_imx->usedma = 0;
 
+	if (spi_imx->usedma) {
+		ret = spi_imx_dma_configure(spi->master,
+					    spi_imx_bytes_per_word(config.bpw));
+		if (ret)
+			return ret;
+	}
+
 	spi_imx->devtype_data->config(spi_imx, &config);
 
 	return 0;
@@ -829,10 +912,8 @@ static void spi_imx_sdma_exit(struct spi_imx_data *spi_imx)
 }
 
 static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
-			     struct spi_master *master,
-			     const struct resource *res)
+			     struct spi_master *master)
 {
-	struct dma_slave_config slave_config = {};
 	int ret;
 
 	/* use pio mode for i.mx6dl chip TKT238285 */
@@ -850,16 +931,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 		goto err;
 	}
 
-	slave_config.direction = DMA_MEM_TO_DEV;
-	slave_config.dst_addr = res->start + MXC_CSPITXDATA;
-	slave_config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
-	slave_config.dst_maxburst = spi_imx->wml;
-	ret = dmaengine_slave_config(master->dma_tx, &slave_config);
-	if (ret) {
-		dev_err(dev, "error in TX dma configuration.\n");
-		goto err;
-	}
-
 	/* Prepare for RX : */
 	master->dma_rx = dma_request_slave_channel_reason(dev, "rx");
 	if (IS_ERR(master->dma_rx)) {
@@ -869,15 +940,7 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 		goto err;
 	}
 
-	slave_config.direction = DMA_DEV_TO_MEM;
-	slave_config.src_addr = res->start + MXC_CSPIRXDATA;
-	slave_config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
-	slave_config.src_maxburst = spi_imx->wml;
-	ret = dmaengine_slave_config(master->dma_rx, &slave_config);
-	if (ret) {
-		dev_err(dev, "error in RX dma configuration.\n");
-		goto err;
-	}
+	spi_imx_dma_configure(master, 1);
 
 	init_completion(&spi_imx->dma_rx_completion);
 	init_completion(&spi_imx->dma_tx_completion);
@@ -1162,6 +1225,7 @@ static int spi_imx_probe(struct platform_device *pdev)
 		ret = PTR_ERR(spi_imx->base);
 		goto out_master_put;
 	}
+	spi_imx->base_phys = res->start;
 
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
@@ -1202,7 +1266,7 @@ static int spi_imx_probe(struct platform_device *pdev)
 	 * other chips.
 	 */
 	if (is_imx51_ecspi(spi_imx)) {
-		ret = spi_imx_sdma_init(&pdev->dev, spi_imx, master, res);
+		ret = spi_imx_sdma_init(&pdev->dev, spi_imx, master);
 		if (ret == -EPROBE_DEFER)
 			goto out_clk_put;
 
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 17 05:28:51 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 14:28:51 +0100
Subject: [PATCH 05/13] spi: imx: initialize usedma earlier
In-Reply-To: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455715739-25161-6-git-send-email-s.hauer@pengutronix.de>

So that the SoC specific config function can know if we will do
DMA or not. Will be needed in following patches.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 5a48d07..7047453 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -815,6 +815,11 @@ static int spi_imx_setupxfer(struct spi_device *spi,
 		spi_imx->tx = spi_imx_buf_tx_u32;
 	}
 
+	if (spi_imx_can_dma(spi_imx->bitbang.master, spi, t))
+		spi_imx->usedma = 1;
+	else
+		spi_imx->usedma = 0;
+
 	spi_imx->devtype_data->config(spi_imx, &config);
 
 	return 0;
@@ -1038,14 +1043,10 @@ static int spi_imx_transfer(struct spi_device *spi,
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
 
-	if (spi_imx->bitbang.master->can_dma &&
-	    spi_imx_can_dma(spi_imx->bitbang.master, spi, transfer)) {
-		spi_imx->usedma = true;
+	if (spi_imx->usedma)
 		return spi_imx_dma_transfer(spi_imx, transfer);
-	}
-	spi_imx->usedma = false;
-
-	return spi_imx_pio_transfer(spi, transfer);
+	else
+		return spi_imx_pio_transfer(spi, transfer);
 }
 
 static int spi_imx_setup(struct spi_device *spi)
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 17 05:28:48 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 14:28:48 +0100
Subject: [PATCH 02/13] spi: imx: use proper dev_* functions for driver messages
In-Reply-To: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455715739-25161-3-git-send-email-s.hauer@pengutronix.de>

Add a struct device * member to the private driver data and use
it to print messages using dev_* functions rather than pr_*.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 27 ++++++++++++---------------
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 08492d6..7904d45 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -86,6 +86,7 @@ struct spi_imx_devtype_data {
 
 struct spi_imx_data {
 	struct spi_bitbang bitbang;
+	struct device *dev;
 
 	struct completion xfer_done;
 	void __iomem *base;
@@ -250,14 +251,15 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 #define MX51_ECSPI_TESTREG_LBC	BIT(31)
 
 /* MX51 eCSPI */
-static unsigned int mx51_ecspi_clkdiv(unsigned int fin, unsigned int fspi,
-				      unsigned int *fres)
+static unsigned int mx51_ecspi_clkdiv(struct spi_imx_data *spi_imx,
+				      unsigned int fspi, unsigned int *fres)
 {
 	/*
 	 * there are two 4-bit dividers, the pre-divider divides by
 	 * $pre, the post-divider by 2^$post
 	 */
 	unsigned int pre, post;
+	unsigned int fin = spi_imx->spi_clk;
 
 	if (unlikely(fspi > fin))
 		return 0;
@@ -270,14 +272,14 @@ static unsigned int mx51_ecspi_clkdiv(unsigned int fin, unsigned int fspi,
 
 	post = max(4U, post) - 4;
 	if (unlikely(post > 0xf)) {
-		pr_err("%s: cannot set clock freq: %u (base freq: %u)\n",
-				__func__, fspi, fin);
+		dev_err(spi_imx->dev, "cannot set clock freq: %u (base freq: %u)\n",
+				fspi, fin);
 		return 0xff;
 	}
 
 	pre = DIV_ROUND_UP(fin, fspi << post) - 1;
 
-	pr_debug("%s: fin: %u, fspi: %u, post: %u, pre: %u\n",
+	dev_dbg(spi_imx->dev, "%s: fin: %u, fspi: %u, post: %u, pre: %u\n",
 			__func__, fin, fspi, post, pre);
 
 	/* Resulting frequency for the SCLK line. */
@@ -330,7 +332,7 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 	ctrl |= MX51_ECSPI_CTRL_MODE_MASK;
 
 	/* set clock speed */
-	ctrl |= mx51_ecspi_clkdiv(spi_imx->spi_clk, config->speed_hz, &clk);
+	ctrl |= mx51_ecspi_clkdiv(spi_imx, config->speed_hz, &clk);
 
 	/* set chip select to use */
 	ctrl |= MX51_ECSPI_CTRL_CS(config->cs);
@@ -968,18 +970,14 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	timeout = wait_for_completion_timeout(&spi_imx->dma_tx_completion,
 						IMX_DMA_TIMEOUT);
 	if (!timeout) {
-		pr_warn("%s %s: I/O Error in DMA TX\n",
-			dev_driver_string(&master->dev),
-			dev_name(&master->dev));
+		dev_err(spi_imx->dev, "I/O Error in DMA TX\n");
 		dmaengine_terminate_all(master->dma_tx);
 		dmaengine_terminate_all(master->dma_rx);
 	} else {
 		timeout = wait_for_completion_timeout(
 				&spi_imx->dma_rx_completion, IMX_DMA_TIMEOUT);
 		if (!timeout) {
-			pr_warn("%s %s: I/O Error in DMA RX\n",
-				dev_driver_string(&master->dev),
-				dev_name(&master->dev));
+			dev_err(spi_imx->dev, "I/O Error in DMA RX\n");
 			spi_imx->devtype_data->reset(spi_imx);
 			dmaengine_terminate_all(master->dma_rx);
 		}
@@ -996,9 +994,7 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	return ret;
 
 no_dma:
-	pr_warn_once("%s %s: DMA not available, falling back to PIO\n",
-		     dev_driver_string(&master->dev),
-		     dev_name(&master->dev));
+	dev_warn_once(spi_imx->dev, "DMA not available, falling back to PIO\n");
 	return -EAGAIN;
 }
 
@@ -1128,6 +1124,7 @@ static int spi_imx_probe(struct platform_device *pdev)
 
 	spi_imx = spi_master_get_devdata(master);
 	spi_imx->bitbang.master = master;
+	spi_imx->dev = &pdev->dev;
 
 	spi_imx->devtype_data = of_id ? of_id->data :
 		(struct spi_imx_devtype_data *)pdev->id_entry->driver_data;
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 17 05:28:52 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 14:28:52 +0100
Subject: [PATCH 06/13] spi: imx: drop unnecessary read/modify/write
In-Reply-To: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455715739-25161-7-git-send-email-s.hauer@pengutronix.de>

When the MX51_ECSPI_DMA is configured we control every single bit
of the register, so there's no need to read/modify/write it. Instead
just write the value we want to have in the register. Also, drop
unnecessary check if we are actually doing DMA. The values written
to the register have no effect in PIO mode and value written there
during the last DMA transfer is still in the register, so we can
equally well always write a value.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 31 ++++++++++---------------------
 1 file changed, 10 insertions(+), 21 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 7047453..073a134 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -240,9 +240,9 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 #define MX51_ECSPI_DMA_RXT_WML_OFFSET	24
 #define MX51_ECSPI_DMA_RXT_WML_MASK	(0x3F << 24)
 
-#define MX51_ECSPI_DMA_TEDEN_OFFSET	7
-#define MX51_ECSPI_DMA_RXDEN_OFFSET	23
-#define MX51_ECSPI_DMA_RXTDEN_OFFSET	31
+#define MX51_ECSPI_DMA_TEDEN		(1 << 7)
+#define MX51_ECSPI_DMA_RXDEN		(1 << 23)
+#define MX51_ECSPI_DMA_RXTDEN		(1 << 31)
 
 #define MX51_ECSPI_STAT		0x18
 #define MX51_ECSPI_STAT_RR		(1 <<  3)
@@ -318,8 +318,7 @@ static void __maybe_unused mx51_ecspi_trigger(struct spi_imx_data *spi_imx)
 static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 		struct spi_imx_config *config)
 {
-	u32 ctrl = MX51_ECSPI_CTRL_ENABLE, cfg = 0, dma = 0;
-	u32 tx_wml_cfg, rx_wml_cfg, rxt_wml_cfg;
+	u32 ctrl = MX51_ECSPI_CTRL_ENABLE, cfg = 0;
 	u32 clk = config->speed_hz, delay, reg;
 
 	/*
@@ -392,22 +391,12 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 	 * Configure the DMA register: setup the watermark
 	 * and enable DMA request.
 	 */
-	if (spi_imx->dma_is_inited) {
-		dma = readl(spi_imx->base + MX51_ECSPI_DMA);
-
-		rx_wml_cfg = spi_imx->wml << MX51_ECSPI_DMA_RX_WML_OFFSET;
-		tx_wml_cfg = spi_imx->wml << MX51_ECSPI_DMA_TX_WML_OFFSET;
-		rxt_wml_cfg = spi_imx->wml << MX51_ECSPI_DMA_RXT_WML_OFFSET;
-		dma = (dma & ~MX51_ECSPI_DMA_TX_WML_MASK
-			   & ~MX51_ECSPI_DMA_RX_WML_MASK
-			   & ~MX51_ECSPI_DMA_RXT_WML_MASK)
-			   | rx_wml_cfg | tx_wml_cfg | rxt_wml_cfg
-			   |(1 << MX51_ECSPI_DMA_TEDEN_OFFSET)
-			   |(1 << MX51_ECSPI_DMA_RXDEN_OFFSET)
-			   |(1 << MX51_ECSPI_DMA_RXTDEN_OFFSET);
-
-		writel(dma, spi_imx->base + MX51_ECSPI_DMA);
-	}
+
+	writel(spi_imx->wml << MX51_ECSPI_DMA_RX_WML_OFFSET |
+		spi_imx->wml << MX51_ECSPI_DMA_TX_WML_OFFSET |
+		spi_imx->wml << MX51_ECSPI_DMA_RXT_WML_OFFSET |
+		MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
+		MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
 
 	return 0;
 }
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 17 05:28:57 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 14:28:57 +0100
Subject: [PATCH 11/13] spi: imx: set MX51_ECSPI_CTRL_SMC bit in setup function
In-Reply-To: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455715739-25161-12-git-send-email-s.hauer@pengutronix.de>

Now that the config function knows whether we are doing DMA or not we
can do the necessary register setup in the config function and no longer
have to do this in the trigger function. With this the trigger function
becomes a no-op for DMA, so instead of testing if we are doing DMA or
not in the trigger function we simply no longer call it in the DMA case.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 21 ++++++---------------
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index dee5e28..3512c2f 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -106,7 +106,6 @@ struct spi_imx_data {
 	unsigned int txfifo; /* number of words pushed in tx FIFO */
 
 	/* DMA */
-	unsigned int dma_finished;
 	bool usedma;
 	u32 wml;
 	struct completion dma_rx_completion;
@@ -324,14 +323,10 @@ static void __maybe_unused mx51_ecspi_intctrl(struct spi_imx_data *spi_imx, int
 
 static void __maybe_unused mx51_ecspi_trigger(struct spi_imx_data *spi_imx)
 {
-	u32 reg = readl(spi_imx->base + MX51_ECSPI_CTRL);
+	u32 reg;
 
-	if (!spi_imx->usedma)
-		reg |= MX51_ECSPI_CTRL_XCH;
-	else if (!spi_imx->dma_finished)
-		reg |= MX51_ECSPI_CTRL_SMC;
-	else
-		reg &= ~MX51_ECSPI_CTRL_SMC;
+	reg = readl(spi_imx->base + MX51_ECSPI_CTRL);
+	reg |= MX51_ECSPI_CTRL_XCH;
 	writel(reg, spi_imx->base + MX51_ECSPI_CTRL);
 }
 
@@ -371,6 +366,9 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 	if (config->mode & SPI_CS_HIGH)
 		cfg |= MX51_ECSPI_CONFIG_SSBPOL(config->cs);
 
+	if (spi_imx->usedma)
+		ctrl |= MX51_ECSPI_CTRL_SMC;
+
 	/* CTRL register always go first to bring out controller from reset */
 	writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
 
@@ -1010,9 +1008,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	reinit_completion(&spi_imx->dma_rx_completion);
 	reinit_completion(&spi_imx->dma_tx_completion);
 
-	/* Trigger the cspi module. */
-	spi_imx->dma_finished = 0;
-
 	/*
 	 * Set these order to avoid potential RX overflow. The overflow may
 	 * happen if we enable SPI HW before starting RX DMA due to rescheduling
@@ -1023,7 +1018,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	 */
 	dma_async_issue_pending(master->dma_rx);
 	dma_async_issue_pending(master->dma_tx);
-	spi_imx->devtype_data->trigger(spi_imx);
 
 	transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len);
 
@@ -1044,9 +1038,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 		}
 	}
 
-	spi_imx->dma_finished = 1;
-	spi_imx->devtype_data->trigger(spi_imx);
-
 	if (!timeout)
 		ret = -ETIMEDOUT;
 	else
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 17 05:28:55 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 14:28:55 +0100
Subject: [PATCH 09/13] spi: imx: remove unnecessary bit clearing in
 mx51_ecspi_config
In-Reply-To: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455715739-25161-10-git-send-email-s.hauer@pengutronix.de>

This reverts patch:

| commit 1476253cef9dbfc1f7f6a1bd19252ca528cd63bd
| Author: Andrew Y. Kuksov <qxovxp at gmail.com>
| Date:   Tue Jul 14 16:23:25 2015 +0300
|
|     spi: imx: fix ecspi mode setup

The patch tried to fix something by clearing bits in the cfg variable,
but cfg is initialized to zero on function entry. There are no bits to
clear.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 6a0e004..2476de7 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -366,20 +366,13 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 
 	if (config->mode & SPI_CPHA)
 		cfg |= MX51_ECSPI_CONFIG_SCLKPHA(config->cs);
-	else
-		cfg &= ~MX51_ECSPI_CONFIG_SCLKPHA(config->cs);
 
 	if (config->mode & SPI_CPOL) {
 		cfg |= MX51_ECSPI_CONFIG_SCLKPOL(config->cs);
 		cfg |= MX51_ECSPI_CONFIG_SCLKCTL(config->cs);
-	} else {
-		cfg &= ~MX51_ECSPI_CONFIG_SCLKPOL(config->cs);
-		cfg &= ~MX51_ECSPI_CONFIG_SCLKCTL(config->cs);
 	}
 	if (config->mode & SPI_CS_HIGH)
 		cfg |= MX51_ECSPI_CONFIG_SSBPOL(config->cs);
-	else
-		cfg &= ~MX51_ECSPI_CONFIG_SSBPOL(config->cs);
 
 	/* CTRL register always go first to bring out controller from reset */
 	writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
-- 
2.7.0



From dirk.behme at de.bosch.com  Wed Feb 17 05:42:33 2016
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Wed, 17 Feb 2016 14:42:33 +0100
Subject: [PATCH] i.MX SPI DMA cleanup
In-Reply-To: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <56C478C9.6050706@de.bosch.com>

Hi Sascha,

On 17.02.2016 14:28, Sascha Hauer wrote:
> This picks up a series sent by Anton Bondarenko last year. It
> contains the remaining not yet upstreamed patches from Antons series
> plus some more DMA related cleanup patches.
>
> My mission was to hunt a bug in the DMA code path sometimes causing
> an additional word in the RX FIFO which locked up the driver in the
> next transfer. It turned out that this was no bug in the driver but
> instead in the device tree: We used the wrong SDMA script for i.MX6.
> The ECSPI cores are connected through the SPBA, so according to the
> reference manual we need the shp/mcu scripts rather than the app/mcu
> scripts.


Are you talking about what is known as "TKT238285 hardware issue"

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/spi/spi-imx.c?id=a02bb401f8ae264be782ee57d98bdd99f14c8022

?

Or are you talking about a different issue?

Best regards

Dirk


From jayachandran.chandrashekaran at broadcom.com  Wed Feb 17 05:44:13 2016
From: jayachandran.chandrashekaran at broadcom.com (Jayachandran Chandrashekaran Nair)
Date: Wed, 17 Feb 2016 19:14:13 +0530
Subject: [PATCH V5 07/15] pci, acpi: Provide generic way to assign bus
 domain number.
In-Reply-To: <1455630825-27253-8-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
 <1455630825-27253-8-git-send-email-tn@semihalf.com>
Message-ID: <CAKc_7PU+i2AwOVCyW2VNt4BZCWw=KBMAbV8v9DVQ2Ess3WE=kw@mail.gmail.com>

Tomasz, Lorenzo,

On Tue, Feb 16, 2016 at 7:23 PM, Tomasz Nowicki <tn at semihalf.com> wrote:
> As we now have valid PCI host bridge device reference we can
> introduce code that is going to find its bus domain number using
> ACPI _SEG method.
>
> Note that _SEG method is optional, therefore _SEG absence means
> that all PCI buses belong to domain 0.
>
> While at it, for the sake of code clarity we put ACPI and DT domain
> assign methods into the corresponding helpers.

In my patchset, I had a slightly different and I think better approach for
this without calling the _SEG method again. Please see
http://www.spinics.net/lists/arm-kernel/msg478167.html
at the last part of http://www.spinics.net/lists/arm-kernel/msg478169.html

JC.


From s.hauer at pengutronix.de  Wed Feb 17 05:54:41 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 14:54:41 +0100
Subject: [PATCH] i.MX SPI DMA cleanup
In-Reply-To: <56C478C9.6050706@de.bosch.com>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
 <56C478C9.6050706@de.bosch.com>
Message-ID: <20160217135441.GA3939@pengutronix.de>

Hi Dirk,

On Wed, Feb 17, 2016 at 02:42:33PM +0100, Dirk Behme wrote:
> Hi Sascha,
> 
> On 17.02.2016 14:28, Sascha Hauer wrote:
> >This picks up a series sent by Anton Bondarenko last year. It
> >contains the remaining not yet upstreamed patches from Antons series
> >plus some more DMA related cleanup patches.
> >
> >My mission was to hunt a bug in the DMA code path sometimes causing
> >an additional word in the RX FIFO which locked up the driver in the
> >next transfer. It turned out that this was no bug in the driver but
> >instead in the device tree: We used the wrong SDMA script for i.MX6.
> >The ECSPI cores are connected through the SPBA, so according to the
> >reference manual we need the shp/mcu scripts rather than the app/mcu
> >scripts.
> 
> 
> Are you talking about what is known as "TKT238285 hardware issue"
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/spi/spi-imx.c?id=a02bb401f8ae264be782ee57d98bdd99f14c8022

I am aware of this issue, but I have no idea if this is the same or
another issue. It says:

> For TKT238285 hardware issue which may cause txfifo store data twice can only
> be caught on i.mx6dl, we use pio mode instead of DMA mode on i.mx6dl.

What I saw here is that there was one word more than expected in the RX
FIFO. Since both RX and TX FIFO act synchronously it could be that the
additional word in the RX FIFO was caused by an additional word in the
TX FIFO as described above.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From ynorov at caviumnetworks.com  Wed Feb 17 05:57:14 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Wed, 17 Feb 2016 16:57:14 +0300
Subject: [PATCH 1/5] all: s390: move wrapper infrastructure to generic
 headers
In-Reply-To: <20160217082210.GA4175@osiris>
References: <1453741047-5498-2-git-send-email-ynorov@caviumnetworks.com>
 <20160128121618.GB5418@osiris> <20160128163109.GA8529@yury-N73SV>
 <20160201114251.GB973@yury-N73SV> <20160202073913.GB3990@osiris>
 <20160202154331.GA3003@yury-N73SV> <20160202160826.GF3990@osiris>
 <20160202195434.GA3397@osiris> <20160202204156.GA27290@yury-N73SV>
 <20160217082210.GA4175@osiris>
Message-ID: <20160217135714.GB13549@yury-N73SV>

On Wed, Feb 17, 2016 at 09:22:10AM +0100, Heiko Carstens wrote:
> On Tue, Feb 02, 2016 at 11:41:56PM +0300, Yury Norov wrote:
> > > However I'll try to write an addon patch to your patch series. Maybe we can
> > > still get rid of compat_wrapper.c in a way which makes both of us happy.
> > > Also.. the idea with the alias names for compat wrappers does seem to have
> > > the disadvantage that it will pollute /proc/kallsyms for example.
> > > 
> > > Anyway, I'm not sure if I will be able to come up with something this week
> > > though.
> > 
> > Great, I'm looking forward...
> 
> Hi Yuri,
> 
> after playing around with this a bit I couldn't come up with a solution
> that I'm happy with, unfortunately.
> 
> So in order to make some progress here I'd vote that we simply move the
> existing compat_wrapper.c from arch/s390 to common code like you did in
> your first approach and leave the existing SYSCALL macros alone.
> 
> That will have hardly any effect to anybody else and your problem is
> solved while s390 still works.
> 
> Does that make sense?
> 

OK. This week I'll split v1 as I did with v2, and send it here. So
we'll have two versions, and so will start true elections. :)

> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From hdegoede at redhat.com  Wed Feb 17 05:59:48 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Wed, 17 Feb 2016 14:59:48 +0100
Subject: [linux-sunxi] [PATCH] ARM: dts: sun4i: Enable USB DRC on
 Hyundai-a7hd
In-Reply-To: <1455656404-31191-1-git-send-email-peter@korsgaard.com>
References: <1455656404-31191-1-git-send-email-peter@korsgaard.com>
Message-ID: <56C47CD4.3080402@redhat.com>

Hi,

On 16-02-16 22:00, Peter Korsgaard wrote:
> Enable the OTG USB controller on the A7HD.
>
> Signed-off-by: Peter Korsgaard <peter at korsgaard.com>

Looks good to me:

Reviewed-by: Hans de Goede <hdegoede at redhat.com>

Regards,

Hans


> ---
>   arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts | 34 ++++++++++++++++++++++++++++
>   1 file changed, 34 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts b/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
> index 43f58fb..9103864 100644
> --- a/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
> @@ -87,6 +87,30 @@
>   	status = "okay";
>   };
>
> +&otg_sram {
> +	status = "okay";
> +};
> +
> +&pio {
> +	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
> +		allwinner,pins = "PH4";
> +		allwinner,function = "gpio_in";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> +	};
> +
> +	usb0_vbus_detect_pin: usb0_vbus_detect_pin at 0 {
> +		allwinner,pins = "PH5";
> +		allwinner,function = "gpio_in";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_PULL_DOWN>;
> +	};
> +};
> +
> +&reg_usb0_vbus {
> +	status = "okay";
> +};
> +
>   &reg_usb2_vbus {
>   	gpio = <&pio 7 6 GPIO_ACTIVE_HIGH>; /* PH6 */
>   	status = "okay";
> @@ -102,7 +126,17 @@
>   	allwinner,pins = "PH6";
>   };
>
> +&usb_otg {
> +	dr_mode = "otg";
> +	status = "okay";
> +};
> +
>   &usbphy {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
> +	usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
> +	usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
> +	usb0_vbus-supply = <&reg_usb0_vbus>;
>   	usb2_vbus-supply = <&reg_usb2_vbus>;
>   	status = "okay";
>   };
>


From thomas.petazzoni at free-electrons.com  Wed Feb 17 06:06:08 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 17 Feb 2016 15:06:08 +0100
Subject: [PATCH 5/5] arm64: marvell: add Device Tree files for Armada 7K/8K
In-Reply-To: <56C356F8.8080105@arm.com>
References: <1455526065-7307-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455526065-7307-6-git-send-email-thomas.petazzoni@free-electrons.com>
 <56C19B18.8090005@arm.com>
 <20160216173155.4f832646@free-electrons.com>
 <56C356F8.8080105@arm.com>
Message-ID: <20160217150608.2c9cdb02@free-electrons.com>

Marc,

On Tue, 16 Feb 2016 17:06:00 +0000, Marc Zyngier wrote:

> > According to the datasheet I have, the GICD, GICC, GICV and GICH blocks
> > are all 0x10000 in size. Not sure the entire 0x10000 is actually used,
> > but th memory map is pretty clear.
> 
> No, that's just a way to make sure that you can give the GICV block to a
> guest while using 64k pages.
> 
> Talking about GICV: are you sure it is 0x10000 and not 0x20000? SBSA
> recommends to have the first 4kB GICV page aliased over 64kB, and the
> second 4kB page over the second 64kB block. That is to ensure that a
> hypervisor can trap access to GICV_DIR register independently of the
> rest of the virtual CPU interface.
> 
> But hey, almost everybody got it wrong so far, so I wouldn't be
> surprised if that was broken on this platform as well...

It seems like Marvell didn't get it wrong, and that my eyes were the
issue.

What I have in the datasheet is:

GICD 0x210000 0x21FFFF Distributor
GICC 0x220000 0x23FFFF Banked per CPU
GICV 0x240000 0x25FFFF Virtual Control
GICH 0x260000 0x27FFFF Hypervisor Control

So: GICD is 64 KB in size, while GICC, GICV and GICH are all 128 KB in
size. I'll fix that up in my v2.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From tn at semihalf.com  Wed Feb 17 06:07:22 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Wed, 17 Feb 2016 15:07:22 +0100
Subject: [PATCH V5 07/15] pci, acpi: Provide generic way to assign bus
 domain number.
In-Reply-To: <CAKc_7PU+i2AwOVCyW2VNt4BZCWw=KBMAbV8v9DVQ2Ess3WE=kw@mail.gmail.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
 <1455630825-27253-8-git-send-email-tn@semihalf.com>
 <CAKc_7PU+i2AwOVCyW2VNt4BZCWw=KBMAbV8v9DVQ2Ess3WE=kw@mail.gmail.com>
Message-ID: <56C47E9A.5010901@semihalf.com>

On 17.02.2016 14:44, Jayachandran Chandrashekaran Nair wrote:
> Tomasz, Lorenzo,
>
> On Tue, Feb 16, 2016 at 7:23 PM, Tomasz Nowicki<tn at semihalf.com>  wrote:
>> >As we now have valid PCI host bridge device reference we can
>> >introduce code that is going to find its bus domain number using
>> >ACPI _SEG method.
>> >
>> >Note that _SEG method is optional, therefore _SEG absence means
>> >that all PCI buses belong to domain 0.
>> >
>> >While at it, for the sake of code clarity we put ACPI and DT domain
>> >assign methods into the corresponding helpers.
> In my patchset, I had a slightly different and I think better approach for
> this without calling the _SEG method again. Please see
> http://www.spinics.net/lists/arm-kernel/msg478167.html
> at the last part ofhttp://www.spinics.net/lists/arm-kernel/msg478169.html

Relying on NULL parent device to make decision on boot method is really 
ugly way. This may hit us again once we want to obtain another firmware 
specific info e.g. numa node. IMO we need to fix it this way.

Tomasz


From dirk.behme at de.bosch.com  Wed Feb 17 06:10:44 2016
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Wed, 17 Feb 2016 15:10:44 +0100
Subject: [PATCH] i.MX SPI DMA cleanup
In-Reply-To: <20160217135441.GA3939@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
 <56C478C9.6050706@de.bosch.com> <20160217135441.GA3939@pengutronix.de>
Message-ID: <56C47F64.1080706@de.bosch.com>

On 17.02.2016 14:54, Sascha Hauer wrote:
> Hi Dirk,
>
> On Wed, Feb 17, 2016 at 02:42:33PM +0100, Dirk Behme wrote:
>> Hi Sascha,
>>
>> On 17.02.2016 14:28, Sascha Hauer wrote:
>>> This picks up a series sent by Anton Bondarenko last year. It
>>> contains the remaining not yet upstreamed patches from Antons series
>>> plus some more DMA related cleanup patches.
>>>
>>> My mission was to hunt a bug in the DMA code path sometimes causing
>>> an additional word in the RX FIFO which locked up the driver in the
>>> next transfer. It turned out that this was no bug in the driver but
>>> instead in the device tree: We used the wrong SDMA script for i.MX6.
>>> The ECSPI cores are connected through the SPBA, so according to the
>>> reference manual we need the shp/mcu scripts rather than the app/mcu
>>> scripts.
>>
>>
>> Are you talking about what is known as "TKT238285 hardware issue"
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/spi/spi-imx.c?id=a02bb401f8ae264be782ee57d98bdd99f14c8022
>
> I am aware of this issue, but I have no idea if this is the same or
> another issue. It says:
>
>> For TKT238285 hardware issue which may cause txfifo store data twice can only
>> be caught on i.mx6dl, we use pio mode instead of DMA mode on i.mx6dl.
>
> What I saw here is that there was one word more than expected in the RX
> FIFO. Since both RX and TX FIFO act synchronously it could be that the
> additional word in the RX FIFO was caused by an additional word in the
> TX FIFO as described above.


The question behind all this is if we could drop

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/spi/spi-imx.c?id=a02bb401f8ae264be782ee57d98bdd99f14c8022

?

And/Or if/how we like to import the FSL workaround for TKT238285

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.14.38_6qp_ga&id=646a751a4d1d0e227a762b461d9b8f92605c26b1

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.14.38_6qp_ga&id=01f180af19a7d5c6f5abc51218be93ea4b5d68ff

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.14.38_6qp_ga&id=321beb210ffb382b8b5378cbf4467f8986efd52f

?

Best regards

Dirk



From broonie at kernel.org  Wed Feb 17 06:16:19 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Feb 2016 14:16:19 +0000
Subject: [PATCH 01/13] spi: imx: allow only WML aligned transfers to use
 DMA
In-Reply-To: <1455715739-25161-2-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
 <1455715739-25161-2-git-send-email-s.hauer@pengutronix.de>
Message-ID: <20160217141619.GR7544@sirena.org.uk>

On Wed, Feb 17, 2016 at 02:28:47PM +0100, Sascha Hauer wrote:

> Also removing change introduced in f6ee9b582d2db652497b73c1f117591dfb6d3a90
> since this change only fix usecases with transfer size from 33 to 128 bytes
> and doesn't fix 129 bytes and bigger.

Please include human readable descriptions of things like commits and
issues being discussed in e-mail in your mails, this makes them much
easier for humans to read especially when they have no internet access.
I do frequently catch up on my mail on flights or while otherwise
travelling so this is even more pressing for me than just being about
making things a bit easier to read.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/6dbb2cba/attachment.sig>

From jbe at pengutronix.de  Wed Feb 17 06:23:55 2016
From: jbe at pengutronix.de (Juergen Borleis)
Date: Wed, 17 Feb 2016 15:23:55 +0100
Subject: Using i.MX6 quad's IPU#1/DI#1 to drive parallel port #1 failed
In-Reply-To: <20160217140902.5e24c074@ipc1.ka-ro>
References: <201602171210.14545.jbe@pengutronix.de>
 <20160217140902.5e24c074@ipc1.ka-ro>
Message-ID: <201602171523.55881.jbe@pengutronix.de>

Hi Lothar,

thank you for your answer. Can you also send me your "pinctrl_disp1" 
definition, please?

Regards,
Juergen


From jayachandran.chandrashekaran at broadcom.com  Wed Feb 17 06:21:48 2016
From: jayachandran.chandrashekaran at broadcom.com (Jayachandran Chandrashekaran Nair)
Date: Wed, 17 Feb 2016 19:51:48 +0530
Subject: [PATCH V5 07/15] pci, acpi: Provide generic way to assign bus
 domain number.
In-Reply-To: <56C47E9A.5010901@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
 <1455630825-27253-8-git-send-email-tn@semihalf.com>
 <CAKc_7PU+i2AwOVCyW2VNt4BZCWw=KBMAbV8v9DVQ2Ess3WE=kw@mail.gmail.com>
 <56C47E9A.5010901@semihalf.com>
Message-ID: <CAKc_7PUiLQhUuJjR8wcuRm7KJdxBYjb+ZBd_cLTtjNPbEro6wA@mail.gmail.com>

On Wed, Feb 17, 2016 at 7:37 PM, Tomasz Nowicki <tn at semihalf.com> wrote:
> On 17.02.2016 14:44, Jayachandran Chandrashekaran Nair wrote:
>>
>> Tomasz, Lorenzo,
>>
>> On Tue, Feb 16, 2016 at 7:23 PM, Tomasz Nowicki<tn at semihalf.com>  wrote:
>>>
>>> >As we now have valid PCI host bridge device reference we can
>>> >introduce code that is going to find its bus domain number using
>>> >ACPI _SEG method.
>>> >
>>> >Note that _SEG method is optional, therefore _SEG absence means
>>> >that all PCI buses belong to domain 0.
>>> >
>>> >While at it, for the sake of code clarity we put ACPI and DT domain
>>> >assign methods into the corresponding helpers.
>>
>> In my patchset, I had a slightly different and I think better approach for
>> this without calling the _SEG method again. Please see
>> http://www.spinics.net/lists/arm-kernel/msg478167.html
>> at the last part ofhttp://www.spinics.net/lists/arm-kernel/msg478169.html
>
> Relying on NULL parent device to make decision on boot method is really ugly
> way. This may hit us again once we want to obtain another firmware specific
> info e.g. numa node. IMO we need to fix it this way.

I am not relying on NULL there, in the current code parent is NULL
in case of ACPI, and the check is needed not to crash (unless that
has changed).

The main part was the macro acpi_pci_get_segment() and the use
of acpi_pci_root_info from sysdata to do this.

JC.


From broonie at kernel.org  Wed Feb 17 06:22:37 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Feb 2016 14:22:37 +0000
Subject: [PATCH 03/13] spi: imx: replace fixed timeout with calculated
In-Reply-To: <1455715739-25161-4-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
 <1455715739-25161-4-git-send-email-s.hauer@pengutronix.de>
Message-ID: <20160217142237.GS7544@sirena.org.uk>

On Wed, Feb 17, 2016 at 02:28:49PM +0100, Sascha Hauer wrote:
> From: Anton Bondarenko <anton.bondarenko.sama at gmail.com>
> 
> Fixed timeout value can fire while transaction is ongoing. This may happen
> because there are no strict requirements on SPI transaction duration.
> Dynamic timeout value is generated based on SCLK and transaction size.
> 
> There is also 4 * SCLK delay between TX bursts related to HW internal CS change.
> 
> Signed-off-by: Anton Bondarenko <anton.bondarenko.sama at gmail.com>
> ---

I can't take this without a signoff from you, sorry - the DCO is very
imporant here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/acd043d2/attachment.sig>

From thomas.petazzoni at free-electrons.com  Wed Feb 17 06:23:33 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 17 Feb 2016 15:23:33 +0100
Subject: [PATCH 0/3] clk: mvebu: initial support for AP806 clocks
In-Reply-To: <CAEG3pNCRa_CQx70aPHfQpG+7jEZ_=_-FxBWDkXVYbgH=j=1rmA@mail.gmail.com>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160215233102.2278.88855@quark.deferred.io>
 <CAEG3pNCRa_CQx70aPHfQpG+7jEZ_=_-FxBWDkXVYbgH=j=1rmA@mail.gmail.com>
Message-ID: <20160217152333.6718d8fc@free-electrons.com>

Hello Michael,

On Mon, 15 Feb 2016 15:36:49 -0800, Michael Turquette wrote:

> > Yay, new SoC! Just FYI, we worked out an agreement in December[0] that
> > the clk git tree can take DT bindings and headers, and we'll always host
> > them in an immutable branch by default in case arm-soc (or anyone else)
> > needs them. Stephen and I are doing this now.
> 
> Oops, I misunderstood your point (and I should have looked at the
> patches before replying). The patches in this series do indeed have
> the clk DT binding descriptions.
> 
> Pardon the noise, nothing to see here, move along ;-)

Yes, each driver comes with its DT binding documentation in the same
patch. Unfortunately, some maintainers prefer to have the DT binding
documentation as separate patches from the driver itself, while some
other maintainers prefer to have both in the same patch. And I never
remember which maintainer has which preference.

So, let me know if you're fine with having both in the same patches. If
not, I can respin by splitting the DT binding documentation in its own
patches.

Other than that, any comments on the drivers themselves? Since they are
quite trivial, I would ideally like to see them in 4.6, if at all
possible.

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From will.deacon at arm.com  Wed Feb 17 06:31:07 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 17 Feb 2016 14:31:07 +0000
Subject: [PATCH v3 1/3] iommu/io-pgtable: Add ARMv7 short descriptor
 support
In-Reply-To: <56AA1A89.6080706@arm.com>
References: <cover.1453723096.git.robin.murphy@arm.com>
 <066c4af0e29c9cc658bd5e48edc5e2d7ba7140a1.1453723096.git.robin.murphy@arm.com>
 <1453857386.28284.4.camel@mhfsdcap03> <56AA1A89.6080706@arm.com>
Message-ID: <20160217143106.GC1459@arm.com>

Hi Robin,

On Thu, Jan 28, 2016 at 01:41:29PM +0000, Robin Murphy wrote:
> On 27/01/16 01:16, Yong Wu wrote:
> >On Tue, 2016-01-26 at 17:13 +0000, Robin Murphy wrote:
> >>Add a nearly-complete ARMv7 short descriptor implementation, omitting
> >>only a few legacy and CPU-centric aspects which shouldn't be necessary
> >>for IOMMU API use anyway.
> >>
> >>Signed-off-by: Yong Wu <yong.wu at mediatek.com>
> >>Signed-off-by: Robin Murphy <robin.murphy at arm.com>
> >
> >This looks good to me.
> >And actually our disp/vdec/venc works well on your v2.
> >
> >You could choose the two below,
> >Reviewed-by: Yong Wu <yong.wu at mediatek.com>
> >Tested-by: Yong Wu <yong.wu at mediatek.com>
> 
> Great, thanks!
> 
> Will, it seems to make the most sense for Joerg to pick these patches up
> directly with the MTK series that depends on them - any objections?

As discussed with Joerg, I'll pick these up and send him a pull request
containing all the pgtable bits. I've taken the liberty of updating
MAINTAINERS too, assuming you don't mind being a reviewer for this?

Will

--->8

>From bccb08d096703bd790fcf2f934553dd9c8503fc9 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon at arm.com>
Date: Wed, 17 Feb 2016 14:18:00 +0000
Subject: [PATCH] MAINTAINERS: update ARM SMMU entry

Ensure that the short-descriptor page table code is included under the
SMMU entry, and add Robin as a designated reviewer.

Cc: Robin Murphy <robin.murphy at arm.com>
Signed-off-by: Will Deacon <will.deacon at arm.com>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index cc2f753cb357..a01bae148b89 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1793,11 +1793,13 @@ F:	drivers/edac/synopsys_edac.c
 
 ARM SMMU DRIVERS
 M:	Will Deacon <will.deacon at arm.com>
+R:	Robin Murphy <robin.murphy at arm.com>
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
 S:	Maintained
 F:	drivers/iommu/arm-smmu.c
 F:	drivers/iommu/arm-smmu-v3.c
 F:	drivers/iommu/io-pgtable-arm.c
+F:	drivers/iommu/io-pgtable-arm-v7s.c
 
 ARM64 PORT (AARCH64 ARCHITECTURE)
 M:	Catalin Marinas <catalin.marinas at arm.com>
-- 
2.1.4



From robin.murphy at arm.com  Wed Feb 17 06:34:08 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 17 Feb 2016 14:34:08 +0000
Subject: [PATCH v3 1/3] iommu/io-pgtable: Add ARMv7 short descriptor
 support
In-Reply-To: <20160217143106.GC1459@arm.com>
References: <cover.1453723096.git.robin.murphy@arm.com>
 <066c4af0e29c9cc658bd5e48edc5e2d7ba7140a1.1453723096.git.robin.murphy@arm.com>
 <1453857386.28284.4.camel@mhfsdcap03> <56AA1A89.6080706@arm.com>
 <20160217143106.GC1459@arm.com>
Message-ID: <56C484E0.3000709@arm.com>

On 17/02/16 14:31, Will Deacon wrote:
> Hi Robin,
>
> On Thu, Jan 28, 2016 at 01:41:29PM +0000, Robin Murphy wrote:
>> On 27/01/16 01:16, Yong Wu wrote:
>>> On Tue, 2016-01-26 at 17:13 +0000, Robin Murphy wrote:
>>>> Add a nearly-complete ARMv7 short descriptor implementation, omitting
>>>> only a few legacy and CPU-centric aspects which shouldn't be necessary
>>>> for IOMMU API use anyway.
>>>>
>>>> Signed-off-by: Yong Wu <yong.wu at mediatek.com>
>>>> Signed-off-by: Robin Murphy <robin.murphy at arm.com>
>>>
>>> This looks good to me.
>>> And actually our disp/vdec/venc works well on your v2.
>>>
>>> You could choose the two below,
>>> Reviewed-by: Yong Wu <yong.wu at mediatek.com>
>>> Tested-by: Yong Wu <yong.wu at mediatek.com>
>>
>> Great, thanks!
>>
>> Will, it seems to make the most sense for Joerg to pick these patches up
>> directly with the MTK series that depends on them - any objections?
>
> As discussed with Joerg, I'll pick these up and send him a pull request
> containing all the pgtable bits. I've taken the liberty of updating
> MAINTAINERS too, assuming you don't mind being a reviewer for this?

Sure, that's fine by me.

> Will
>
> --->8
>
>  From bccb08d096703bd790fcf2f934553dd9c8503fc9 Mon Sep 17 00:00:00 2001
> From: Will Deacon <will.deacon at arm.com>
> Date: Wed, 17 Feb 2016 14:18:00 +0000
> Subject: [PATCH] MAINTAINERS: update ARM SMMU entry
>
> Ensure that the short-descriptor page table code is included under the
> SMMU entry, and add Robin as a designated reviewer.
>
> Cc: Robin Murphy <robin.murphy at arm.com>

s/Cc/Acked-by/

Robin.

> Signed-off-by: Will Deacon <will.deacon at arm.com>
> ---
>   MAINTAINERS | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cc2f753cb357..a01bae148b89 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1793,11 +1793,13 @@ F:	drivers/edac/synopsys_edac.c
>
>   ARM SMMU DRIVERS
>   M:	Will Deacon <will.deacon at arm.com>
> +R:	Robin Murphy <robin.murphy at arm.com>
>   L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>   S:	Maintained
>   F:	drivers/iommu/arm-smmu.c
>   F:	drivers/iommu/arm-smmu-v3.c
>   F:	drivers/iommu/io-pgtable-arm.c
> +F:	drivers/iommu/io-pgtable-arm-v7s.c
>
>   ARM64 PORT (AARCH64 ARCHITECTURE)
>   M:	Catalin Marinas <catalin.marinas at arm.com>
>



From mark.rutland at arm.com  Wed Feb 17 06:39:51 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 17 Feb 2016 14:39:51 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <56C31D1D.50708@virtuozzo.com>
References: <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com>
Message-ID: <20160217143950.GC32647@leverpostej>

On Tue, Feb 16, 2016 at 03:59:09PM +0300, Andrey Ryabinin wrote:
> Actually, the first report is a bit more useful. It shows that shadow memory was corrupted:
> 
>   ffffffc93665bc00: f1 f1 f1 f1 00 f4 f4 f4 f2 f2 f2 f2 00 00 f1 f1
> > ffffffc93665bc80: f1 f1 00 00 00 00 f3 f3 00 f4 f4 f4 f3 f3 f3 f3
>                       ^
> F1 - left redzone, it indicates start of stack frame
> F3 - right redzone, it should be the end of stack frame.
> 
> But here we have the second set of F1s without F3s which should close the first set of F1s.
> Also those two F3s in the middle cannot be right.
> 
> So shadow is corrupted.
> Some hypotheses:

> 2) Shadow memory wasn't cleared. GCC poison memory on function entrance and unpoisons it before return.
>      If we use some tricky way to exit from function this could cause false-positives like that.
>      E.g. some hand-written assembly return code.

I think this is what's happenening, at least for the idle case.

A second attempt at bisecting led me to commit e679660dbb8347f2 ("ARM:
8481/2: drivers: psci: replace psci firmware calls"). Reverting that
makes v4.5-rc1 boot without KASAN splats.

That patch turned __invoke_psci_fn_{smc,hvc} into (ASAN-instrumented) C
functions. Prior to that commit, __invoke_psci_fn_{smc,hvc} were
pure assembly functions which used no stack.

When we go down for idle, in __cpu_suspend_enter we stash some context
to the stack (in assembly). The CPU may return from a cold state via
cpu_resume, where we restore context from the stack.

However, after storing the context we call psci_suspend_finisher, which
calls psci_cpu_suspend, which calls invoke_psci_fn_*. As
psci_cpu_suspend and invoke_psci_fn_* are instrumented, they poison
memory on function entrance, but we never perform the unpoisoning.

That was always the case for psci_suspend_finisher, so there was a
latent issue that we were somehow avoiding. Perhaps we got luck with
stack layout and never hit the poison.

I'm not sure how we fix that, as invoke_psci_fn_* may or may not return
for arbitrary reasons (e.g. a CPU_SUSPEND_CALL may or may not return
depending on whether an interrupt comes in at the right time).

Perhaps the simplest option is to not instrument invoke_psci_fn_* and
psci_suspend_finisher. Do we have a per-function annotation to avoid
KASAN instrumentation, like notrace? I need to investigate, but we may
also need notrace for similar reasons.

Andrey, on a tangential note, what do we do around hotplug? I assume
that we must unpooison the shadow region for the stack of a dead CPU,
but I wasn't able to figure out where we do that. Hopefuly we're not
just getting lucky?

Thanks,
Mark.


From LW at KARO-electronics.de  Wed Feb 17 06:58:14 2016
From: LW at KARO-electronics.de (Lothar =?UTF-8?B?V2HDn21hbm4=?=)
Date: Wed, 17 Feb 2016 15:58:14 +0100
Subject: Using i.MX6 quad's IPU#1/DI#1 to drive parallel port #1 failed
In-Reply-To: <201602171523.55881.jbe@pengutronix.de>
References: <201602171210.14545.jbe@pengutronix.de>
 <20160217140902.5e24c074@ipc1.ka-ro>
 <201602171523.55881.jbe@pengutronix.de>
Message-ID: <20160217155814.7f7132aa@ipc1.ka-ro>

Hi,

On Wed, 17 Feb 2016 15:23:55 +0100 Juergen Borleis wrote:
> Hi Lothar,
> 
> thank you for your answer. Can you also send me your "pinctrl_disp1" 
> definition, please?
> 
		pinctrl_disp1: disp1grp {
			fsl,pins = <
				MX6QDL_PAD_EIM_A16__IPU1_DI1_DISP_CLK	0x10
				MX6QDL_PAD_EIM_DA10__IPU1_DI1_PIN15	0x10
				MX6QDL_PAD_EIM_DA11__IPU1_DI1_PIN02	0x10
				MX6QDL_PAD_EIM_DA12__IPU1_DI1_PIN03	0x10
				MX6QDL_PAD_EIM_DA9__IPU1_DISP1_DATA00	0x10
				MX6QDL_PAD_EIM_DA8__IPU1_DISP1_DATA01	0x10
				MX6QDL_PAD_EIM_DA7__IPU1_DISP1_DATA02	0x10
				MX6QDL_PAD_EIM_DA6__IPU1_DISP1_DATA03	0x10
				MX6QDL_PAD_EIM_DA5__IPU1_DISP1_DATA04	0x10
				MX6QDL_PAD_EIM_DA4__IPU1_DISP1_DATA05	0x10
				MX6QDL_PAD_EIM_DA3__IPU1_DISP1_DATA06	0x10
				MX6QDL_PAD_EIM_DA2__IPU1_DISP1_DATA07	0x10
				MX6QDL_PAD_EIM_DA1__IPU1_DISP1_DATA08	0x10
				MX6QDL_PAD_EIM_DA0__IPU1_DISP1_DATA09	0x10
				MX6QDL_PAD_EIM_EB1__IPU1_DISP1_DATA10	0x10
				MX6QDL_PAD_EIM_EB0__IPU1_DISP1_DATA11	0x10
				MX6QDL_PAD_EIM_A17__IPU1_DISP1_DATA12	0x10
				MX6QDL_PAD_EIM_A18__IPU1_DISP1_DATA13	0x10
				MX6QDL_PAD_EIM_A19__IPU1_DISP1_DATA14	0x10
				MX6QDL_PAD_EIM_A20__IPU1_DISP1_DATA15	0x10
				MX6QDL_PAD_EIM_A21__IPU1_DISP1_DATA16	0x10
				MX6QDL_PAD_EIM_A22__IPU1_DISP1_DATA17	0x10
				MX6QDL_PAD_EIM_A23__IPU1_DISP1_DATA18	0x10
				MX6QDL_PAD_EIM_A24__IPU1_DISP1_DATA19	0x10
				MX6QDL_PAD_EIM_D31__IPU1_DISP1_DATA20	0x10
				MX6QDL_PAD_EIM_D30__IPU1_DISP1_DATA21	0x10
				MX6QDL_PAD_EIM_D26__IPU1_DISP1_DATA22	0x10
				MX6QDL_PAD_EIM_D27__IPU1_DISP1_DATA23	0x10
			>;
		};


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________


From s.hauer at pengutronix.de  Wed Feb 17 06:59:44 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 15:59:44 +0100
Subject: [PATCH] i.MX SPI DMA cleanup
In-Reply-To: <56C47F64.1080706@de.bosch.com>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
 <56C478C9.6050706@de.bosch.com>
 <20160217135441.GA3939@pengutronix.de>
 <56C47F64.1080706@de.bosch.com>
Message-ID: <20160217145944.GB3939@pengutronix.de>

On Wed, Feb 17, 2016 at 03:10:44PM +0100, Dirk Behme wrote:
> On 17.02.2016 14:54, Sascha Hauer wrote:
> >Hi Dirk,
> >
> >On Wed, Feb 17, 2016 at 02:42:33PM +0100, Dirk Behme wrote:
> >>Hi Sascha,
> >>
> >>On 17.02.2016 14:28, Sascha Hauer wrote:
> >>>This picks up a series sent by Anton Bondarenko last year. It
> >>>contains the remaining not yet upstreamed patches from Antons series
> >>>plus some more DMA related cleanup patches.
> >>>
> >>>My mission was to hunt a bug in the DMA code path sometimes causing
> >>>an additional word in the RX FIFO which locked up the driver in the
> >>>next transfer. It turned out that this was no bug in the driver but
> >>>instead in the device tree: We used the wrong SDMA script for i.MX6.
> >>>The ECSPI cores are connected through the SPBA, so according to the
> >>>reference manual we need the shp/mcu scripts rather than the app/mcu
> >>>scripts.
> >>
> >>
> >>Are you talking about what is known as "TKT238285 hardware issue"
> >>
> >>https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/spi/spi-imx.c?id=a02bb401f8ae264be782ee57d98bdd99f14c8022
> >
> >I am aware of this issue, but I have no idea if this is the same or
> >another issue. It says:
> >
> >>For TKT238285 hardware issue which may cause txfifo store data twice can only
> >>be caught on i.mx6dl, we use pio mode instead of DMA mode on i.mx6dl.
> >
> >What I saw here is that there was one word more than expected in the RX
> >FIFO. Since both RX and TX FIFO act synchronously it could be that the
> >additional word in the RX FIFO was caused by an additional word in the
> >TX FIFO as described above.
> 
> 
> The question behind all this is if we could drop
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/spi/spi-imx.c?id=a02bb401f8ae264be782ee57d98bdd99f14c8022
> 
> ?

It seems on the i.MX6DL we (additionally) have another issue. I just
tested here on a i.MX6DL board with a NOR Flash connected. I saw the
same issue as I saw on the i.MX6Q, but on the i.MX6DL it cannot be fixed
by using the shp/mcu SDMA scripts.
Funny enough on the i.MX6DL the RXFIFO issue happens much more
frequently than on the i.MX6Q.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From s.hauer at pengutronix.de  Wed Feb 17 07:01:46 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 17 Feb 2016 16:01:46 +0100
Subject: [PATCH 01/13] spi: imx: allow only WML aligned transfers to use
 DMA
In-Reply-To: <20160217141619.GR7544@sirena.org.uk>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
 <1455715739-25161-2-git-send-email-s.hauer@pengutronix.de>
 <20160217141619.GR7544@sirena.org.uk>
Message-ID: <20160217150146.GC3939@pengutronix.de>

On Wed, Feb 17, 2016 at 02:16:19PM +0000, Mark Brown wrote:
> On Wed, Feb 17, 2016 at 02:28:47PM +0100, Sascha Hauer wrote:
> 
> > Also removing change introduced in f6ee9b582d2db652497b73c1f117591dfb6d3a90
> > since this change only fix usecases with transfer size from 33 to 128 bytes
> > and doesn't fix 129 bytes and bigger.
> 
> Please include human readable descriptions of things like commits and
> issues being discussed in e-mail in your mails, this makes them much
> easier for humans to read especially when they have no internet access.
> I do frequently catch up on my mail on flights or while otherwise
> travelling so this is even more pressing for me than just being about
> making things a bit easier to read.

You seem to have a template for this, I remember having read the same
text before ;)

Will fix this and add a signed-off-by.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From arnd at arndb.de  Wed Feb 17 07:02:30 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 16:02:30 +0100
Subject: [PATCH v3 0/5] serial: 8250: fixes for modular build
Message-ID: <1455721357-4008289-1-git-send-email-arnd@arndb.de>

Hi Greg,

This is a resend of my last week's 8250 series, with a couple of
issues fixed as pointed out by Paul Gortmaker.

Masahiro Yamada had an idea for a nicer solution to the problem of
a modular build, but after some back and forth, the conclusion was
that this does not work any more after the rework done by
Peter Hurley, so we are back to my original approach.

I've done many compile tests over the last week and found another
corner case in the Ingenic driver patch, which is now also fixed,
and I'm no longer getting any invalid symbol references here or
in other drivers.

	Arnd



From arnd at arndb.de  Wed Feb 17 07:02:32 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 16:02:32 +0100
Subject: [PATCH v3 2/5] Revert "drivers/tty/serial: make 8250/8250_ingenic.c
 explicitly non-modular"
In-Reply-To: <1455721357-4008289-1-git-send-email-arnd@arndb.de>
References: <1455721357-4008289-1-git-send-email-arnd@arndb.de>
Message-ID: <1455721357-4008289-3-git-send-email-arnd@arndb.de>

This reverts commit cafe1ac64023  ("drivers/tty: make serial
8250_ingenic.c explicitly non-modular"), which attempted to remove dead
code but did not have the desired effect when the main 8250 driver was
a loadable module itself.

This would normally result in a link error, but as the entire
drivers/tty/serial/8250/ directory is only entered when CONFIG_SERIAL_8250
is set, we never notice that the driver does not get built in this
configuration.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/tty/serial/8250/8250_ingenic.c | 28 +++++++++++++++++++++-------
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_ingenic.c b/drivers/tty/serial/8250/8250_ingenic.c
index b4e1d39805b2..97b78558caed 100644
--- a/drivers/tty/serial/8250/8250_ingenic.c
+++ b/drivers/tty/serial/8250/8250_ingenic.c
@@ -4,8 +4,6 @@
  *
  * Ingenic SoC UART support
  *
- * Author: Paul Burton <paul.burton at imgtec.com>
- *
  * This program is free software; you can redistribute	 it and/or modify it
  * under  the terms of	 the GNU General  Public License as published by the
  * Free Software Foundation;  either version 2 of the	License, or (at your
@@ -20,7 +18,7 @@
 #include <linux/console.h>
 #include <linux/io.h>
 #include <linux/libfdt.h>
-#include <linux/init.h>
+#include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_fdt.h>
 #include <linux/of_device.h>
@@ -303,6 +301,16 @@ out:
 	return err;
 }
 
+static int ingenic_uart_remove(struct platform_device *pdev)
+{
+	struct ingenic_uart_data *data = platform_get_drvdata(pdev);
+
+	serial8250_unregister_port(data->line);
+	clk_disable_unprepare(data->clk_module);
+	clk_disable_unprepare(data->clk_baud);
+	return 0;
+}
+
 static const struct ingenic_uart_config jz4740_uart_config = {
 	.tx_loadsz = 8,
 	.fifosize = 16,
@@ -325,13 +333,19 @@ static const struct of_device_id of_match[] = {
 	{ .compatible = "ingenic,jz4780-uart", .data = &jz4780_uart_config },
 	{ /* sentinel */ }
 };
+MODULE_DEVICE_TABLE(of, of_match);
 
 static struct platform_driver ingenic_uart_platform_driver = {
 	.driver = {
-		.name			= "ingenic-uart",
-		.of_match_table		= of_match,
-		.suppress_bind_attrs	= true,
+		.name		= "ingenic-uart",
+		.of_match_table	= of_match,
 	},
 	.probe			= ingenic_uart_probe,
+	.remove			= ingenic_uart_remove,
 };
-builtin_platform_driver(ingenic_uart_platform_driver);
+
+module_platform_driver(ingenic_uart_platform_driver);
+
+MODULE_AUTHOR("Paul Burton");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Ingenic SoC UART driver");
-- 
2.7.0



From arnd at arndb.de  Wed Feb 17 07:02:31 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 16:02:31 +0100
Subject: [PATCH v3 1/5] Revert "drivers/tty/serial: make 8250/8250_mtk.c
 explicitly non-modular"
In-Reply-To: <1455721357-4008289-1-git-send-email-arnd@arndb.de>
References: <1455721357-4008289-1-git-send-email-arnd@arndb.de>
Message-ID: <1455721357-4008289-2-git-send-email-arnd@arndb.de>

This reverts commit d72d391c126e ("drivers/tty/serial: make
8250/8250_mtk.c explicitly non-modular"), which intended to remove dead
code but did not have the desired effect when the main 8250 driver was
a module itself.

This would normally result in a link error, but as the entire
drivers/tty/serial/8250/ directory is only entered when CONFIG_SERIAL_8250
is set, we never notice that the driver does not get built in this
configuration.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/tty/serial/8250/8250_mtk.c | 35 ++++++++++++++++++++++++++++-------
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
index 9038843cadc7..6ecc6e3e82dc 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -16,7 +16,7 @@
  */
 #include <linux/clk.h>
 #include <linux/io.h>
-#include <linux/init.h>
+#include <linux/module.h>
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
@@ -245,6 +245,23 @@ static int mtk8250_probe(struct platform_device *pdev)
 	return 0;
 }
 
+static int mtk8250_remove(struct platform_device *pdev)
+{
+	struct mtk8250_data *data = platform_get_drvdata(pdev);
+
+	pm_runtime_get_sync(&pdev->dev);
+
+	serial8250_unregister_port(data->line);
+
+	pm_runtime_disable(&pdev->dev);
+	pm_runtime_put_noidle(&pdev->dev);
+
+	if (!pm_runtime_status_suspended(&pdev->dev))
+		mtk8250_runtime_suspend(&pdev->dev);
+
+	return 0;
+}
+
 static int __maybe_unused mtk8250_suspend(struct device *dev)
 {
 	struct mtk8250_data *data = dev_get_drvdata(dev);
@@ -273,18 +290,18 @@ static const struct of_device_id mtk8250_of_match[] = {
 	{ .compatible = "mediatek,mt6577-uart" },
 	{ /* Sentinel */ }
 };
+MODULE_DEVICE_TABLE(of, mtk8250_of_match);
 
 static struct platform_driver mtk8250_platform_driver = {
 	.driver = {
-		.name			= "mt6577-uart",
-		.pm			= &mtk8250_pm_ops,
-		.of_match_table		= mtk8250_of_match,
-		.suppress_bind_attrs	= true,
-
+		.name		= "mt6577-uart",
+		.pm		= &mtk8250_pm_ops,
+		.of_match_table	= mtk8250_of_match,
 	},
 	.probe			= mtk8250_probe,
+	.remove			= mtk8250_remove,
 };
-builtin_platform_driver(mtk8250_platform_driver);
+module_platform_driver(mtk8250_platform_driver);
 
 #ifdef CONFIG_SERIAL_8250_CONSOLE
 static int __init early_mtk8250_setup(struct earlycon_device *device,
@@ -300,3 +317,7 @@ static int __init early_mtk8250_setup(struct earlycon_device *device,
 
 OF_EARLYCON_DECLARE(mtk8250, "mediatek,mt6577-uart", early_mtk8250_setup);
 #endif
+
+MODULE_AUTHOR("Matthias Brugger");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Mediatek 8250 serial port driver");
-- 
2.7.0



From arnd at arndb.de  Wed Feb 17 07:02:33 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 16:02:33 +0100
Subject: [PATCH v3 3/5] serial: 8250/uniphier: fix modular build
In-Reply-To: <1455721357-4008289-1-git-send-email-arnd@arndb.de>
References: <1455721357-4008289-1-git-send-email-arnd@arndb.de>
Message-ID: <1455721357-4008289-4-git-send-email-arnd@arndb.de>

The newly added uniphier serial port driver fails to build as
a loadable module when the base 8250 driver is built-in and
its console support enabled:

ERROR: "early_serial8250_setup" [drivers/tty/serial/8250/8250_uniphier.ko] undefined!

This changes the driver to only provide the early console support
if it is built-in itself as well.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/tty/serial/8250/8250_uniphier.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_uniphier.c b/drivers/tty/serial/8250/8250_uniphier.c
index bab6b3ae2540..1b7bd26555b7 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -35,7 +35,7 @@ struct uniphier8250_priv {
 	spinlock_t atomic_write_lock;
 };
 
-#ifdef CONFIG_SERIAL_8250_CONSOLE
+#if defined(CONFIG_SERIAL_8250_CONSOLE) && !defined(MODULE)
 static int __init uniphier_early_console_setup(struct earlycon_device *device,
 					       const char *options)
 {
-- 
2.7.0



From arnd at arndb.de  Wed Feb 17 07:02:34 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 16:02:34 +0100
Subject: [PATCH v3 4/5] serial: 8250/ingenic: fix building with SERIAL_8250=m
In-Reply-To: <1455721357-4008289-1-git-send-email-arnd@arndb.de>
References: <1455721357-4008289-1-git-send-email-arnd@arndb.de>
Message-ID: <1455721357-4008289-5-git-send-email-arnd@arndb.de>

The Ingenic 8250 driver has a 'bool' Kconfig symbol, but that
breaks when SERIAL_8250 is a loadable module:

drivers/tty/built-in.o: In function `ingenic_uart_probe':
8250_ingenic.c:(.text+0x1c1a0): undefined reference to `serial8250_register_8250_port'

This changes the symbol to a 'tristate', plus a dependency on
SERIAL_8250, which makes it work again. Unlike the other
soc-specific backends, this one has no dependency on an
architecture or a platform. I'm adding a dependency on
MIPS || COMPILE_TEST as well here, to avoid showing the driver
on architectures that are not interested in it.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/tty/serial/8250/8250_ingenic.c | 2 +-
 drivers/tty/serial/8250/Kconfig        | 7 ++++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_ingenic.c b/drivers/tty/serial/8250/8250_ingenic.c
index 97b78558caed..b0677f610863 100644
--- a/drivers/tty/serial/8250/8250_ingenic.c
+++ b/drivers/tty/serial/8250/8250_ingenic.c
@@ -48,7 +48,7 @@ static const struct of_device_id of_match[];
 #define UART_MCR_MDCE	BIT(7)
 #define UART_MCR_FCM	BIT(6)
 
-#ifdef CONFIG_SERIAL_EARLYCON
+#if defined(CONFIG_SERIAL_EARLYCON) && !defined(MODULE)
 static struct earlycon_device *early_device;
 
 static uint8_t __init early_in(struct uart_port *port, int offset)
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index 67ad6b0d595b..1b0638511ac1 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -384,9 +384,10 @@ config SERIAL_8250_UNIPHIER
 	  serial ports, say Y to this option. If unsure, say N.
 
 config SERIAL_8250_INGENIC
-	bool "Support for Ingenic SoC serial ports"
-	depends on OF_FLATTREE
-	select LIBFDT
+	tristate "Support for Ingenic SoC serial ports"
+	depends on SERIAL_8250
+	depends on (OF_FLATTREE && SERIAL_8250_CONSOLE) || !SERIAL_EARLYCON
+	depends on MIPS || COMPILE_TEST
 	help
 	  If you have a system using an Ingenic SoC and wish to make use of
 	  its UARTs, say Y to this option. If unsure, say N.
-- 
2.7.0



From kirill at shutemov.name  Wed Feb 17 07:04:56 2016
From: kirill at shutemov.name (Kirill A. Shutemov)
Date: Wed, 17 Feb 2016 17:04:56 +0200
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160216172444.013988d8@thinkpad>
References: <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
 <alpine.LFD.2.20.1602131238260.1910@schleppi>
 <20160215113159.GA28832@node.shutemov.name>
 <20160215193702.4a15ed5e@thinkpad>
 <20160215213526.GA9766@node.shutemov.name>
 <20160216172444.013988d8@thinkpad>
Message-ID: <20160217150456.GA15882@node.shutemov.name>

On Tue, Feb 16, 2016 at 05:24:44PM +0100, Gerald Schaefer wrote:
> On Mon, 15 Feb 2016 23:35:26 +0200
> "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> 
> > Is there any chance that I'll be able to trigger the bug using QEMU?
> > Does anybody have an QEMU image I can use?
> > 
> 
> I have no image, but trying to reproduce this under virtualization may
> help to trigger this also on other architectures. After ruling out IPI
> vs. fast_gup I do not really see why this should be arch-specific, and
> it wouldn't be the first time that we hit subtle races first on s390, due
> to our virtualized environment (my test case is make -j20 with 10 CPUs and
> 4GB of memory, no swap).

Could you post your kernel config?

It would be nice also to check if disabling split_huge_page() would make
any difference:

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index a75081ca31cf..26d2b7b21021 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3364,6 +3364,8 @@ int split_huge_page_to_list(struct page *page, struct list_head *list)
 	bool mlocked;
 	unsigned long flags;
 
+	return -EBUSY;
+
 	VM_BUG_ON_PAGE(is_huge_zero_page(page), page);
 	VM_BUG_ON_PAGE(!PageAnon(page), page);
 	VM_BUG_ON_PAGE(!PageLocked(page), page);
-- 
 Kirill A. Shutemov


From arnd at arndb.de  Wed Feb 17 07:02:35 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 16:02:35 +0100
Subject: [PATCH v3 5/5] serial: 8250/mediatek: fix building with SERIAL_8250=m
In-Reply-To: <1455721357-4008289-1-git-send-email-arnd@arndb.de>
References: <1455721357-4008289-1-git-send-email-arnd@arndb.de>
Message-ID: <1455721357-4008289-6-git-send-email-arnd@arndb.de>

The Mediatek 8250 driver has a 'bool' Kconfig symbol, but that
breaks when SERIAL_8250 is a loadable module:

drivers/tty/built-in.o: In function `mtk8250_set_termios':
:(.text+0x1bee8): undefined reference to `serial8250_do_set_termios'
:(.text+0x1bf10): undefined reference to `uart_get_baud_rate'
:(.text+0x1c09c): undefined reference to `uart_get_divisor'
drivers/tty/built-in.o: In function `mtk8250_do_pm':
:(.text+0x1c0d0): undefined reference to `serial8250_do_pm'
drivers/tty/built-in.o: In function `mtk8250_probe':
:(.text+0x1c2e4): undefined reference to `serial8250_register_8250_port'
serial/8250/8250_mtk.c:287:242: error: data definition has no type or storage class [-Werror]
serial/8250/8250_mtk.c:287:122: error: 'mtk8250_platform_driver_init' defined but not used [-Werror=unused-function]

This changes the symbol to a 'tristate', so the dependency on
SERIAL_8250 also works when that is set to 'm'.
To actually build the driver, we also need to include <linux/module.h>.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Matthias Brugger <matthias.bgg at gmail.com>
---
 drivers/tty/serial/8250/8250_mtk.c | 2 +-
 drivers/tty/serial/8250/Kconfig    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
index 6ecc6e3e82dc..a0294f3de4f8 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -303,7 +303,7 @@ static struct platform_driver mtk8250_platform_driver = {
 };
 module_platform_driver(mtk8250_platform_driver);
 
-#ifdef CONFIG_SERIAL_8250_CONSOLE
+#if defined(CONFIG_SERIAL_8250_CONSOLE) && !defined(MODULE)
 static int __init early_mtk8250_setup(struct earlycon_device *device,
 					const char *options)
 {
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index 1b0638511ac1..c45a02a7f9e2 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -370,7 +370,7 @@ config SERIAL_8250_LPC18XX
 	  serial port, say Y to this option. If unsure, say Y.
 
 config SERIAL_8250_MT6577
-	bool "Mediatek serial port support"
+	tristate "Mediatek serial port support"
 	depends on SERIAL_8250 && ARCH_MEDIATEK
 	help
 	  If you have a Mediatek based board and want to use the
-- 
2.7.0



From tn at semihalf.com  Wed Feb 17 07:05:41 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Wed, 17 Feb 2016 16:05:41 +0100
Subject: [PATCH V5 07/15] pci, acpi: Provide generic way to assign bus
 domain number.
In-Reply-To: <CAKc_7PUiLQhUuJjR8wcuRm7KJdxBYjb+ZBd_cLTtjNPbEro6wA@mail.gmail.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
 <1455630825-27253-8-git-send-email-tn@semihalf.com>
 <CAKc_7PU+i2AwOVCyW2VNt4BZCWw=KBMAbV8v9DVQ2Ess3WE=kw@mail.gmail.com>
 <56C47E9A.5010901@semihalf.com>
 <CAKc_7PUiLQhUuJjR8wcuRm7KJdxBYjb+ZBd_cLTtjNPbEro6wA@mail.gmail.com>
Message-ID: <56C48C45.7050203@semihalf.com>

On 17.02.2016 15:21, Jayachandran Chandrashekaran Nair wrote:
> On Wed, Feb 17, 2016 at 7:37 PM, Tomasz Nowicki <tn at semihalf.com> wrote:
>> On 17.02.2016 14:44, Jayachandran Chandrashekaran Nair wrote:
>>>
>>> Tomasz, Lorenzo,
>>>
>>> On Tue, Feb 16, 2016 at 7:23 PM, Tomasz Nowicki<tn at semihalf.com>  wrote:
>>>>
>>>>> As we now have valid PCI host bridge device reference we can
>>>>> introduce code that is going to find its bus domain number using
>>>>> ACPI _SEG method.
>>>>>
>>>>> Note that _SEG method is optional, therefore _SEG absence means
>>>>> that all PCI buses belong to domain 0.
>>>>>
>>>>> While at it, for the sake of code clarity we put ACPI and DT domain
>>>>> assign methods into the corresponding helpers.
>>>
>>> In my patchset, I had a slightly different and I think better approach for
>>> this without calling the _SEG method again. Please see
>>> http://www.spinics.net/lists/arm-kernel/msg478167.html
>>> at the last part ofhttp://www.spinics.net/lists/arm-kernel/msg478169.html
>>
>> Relying on NULL parent device to make decision on boot method is really ugly
>> way. This may hit us again once we want to obtain another firmware specific
>> info e.g. numa node. IMO we need to fix it this way.
>
> I am not relying on NULL there, in the current code parent is NULL
> in case of ACPI, and the check is needed not to crash (unless that
> has changed).

This series passes down valid parent, see [PATCH V5 06/15].

>
> The main part was the macro acpi_pci_get_segment() and the use
> of acpi_pci_root_info from sysdata to do this.

Since we can obtain related firmware specific data from valid parent 
device (without defining another accessors), I do not see the point to 
use sysdata. Let me know your opinion.

Tomasz


From balbi at kernel.org  Wed Feb 17 07:08:27 2016
From: balbi at kernel.org (Felipe Balbi)
Date: Wed, 17 Feb 2016 17:08:27 +0200
Subject: [PATCH 1/7] usb: gadget: pxa25x_udc: move register definitions
 from arch
In-Reply-To: <1453997843-3489728-1-git-send-email-arnd@arndb.de>
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <1453997843-3489728-1-git-send-email-arnd@arndb.de>
Message-ID: <87oabfgys4.fsf@ti.com>


Hi,

Arnd Bergmann <arnd at arndb.de> writes:
> ixp4xx and pxa25x both use this driver and provide a slightly
> different set of register definitions for it. Aside from that,
> the definition in the ixp4xx-regs.h header conflicts with the
> on in the pxa27x device driver when compile-testing that:
>
> In file included from ../drivers/usb/gadget/udc/pxa27x_udc.c:37:0:
> ../drivers/usb/gadget/udc/pxa27x_udc.h:26:0: warning: "UDCCR" redefined
>  #define UDCCR  0x0000  /* UDC Control Register */
>  ^
> In file included from ../arch/arm/mach-ixp4xx/include/mach/hardware.h:27:0,
>                  from ../arch/arm/mach-ixp4xx/include/mach/io.h:18,
>                  from ../arch/arm/include/asm/io.h:194,
>                  from ../include/linux/io.h:25,
>                  from ../include/linux/irq.h:24,
>                  from ../drivers/usb/gadget/udc/pxa27x_udc.c:23:
> ../arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h:415:0: note: this is the location of the previous definition
>  #define UDCCR  IXP4XX_USB_REG(IXP4XX_USB_BASE_VIRT+0x0000)
>
> This addresses both issues by moving all the definitions into the
> pxa25x_udc driver itself. It turns out the only difference between
> them was 'UDCCS_IO_ROF', and that could well be a mistake when it
> was incorrectly copied from pxa25x to ixp4xx.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

FYI, this series now sits in my testing/next. If you could just check
that I didn't mess anything up, I'd be glad.

Thanks

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/03af8ac6/attachment.sig>

From nsekhar at ti.com  Wed Feb 17 07:11:17 2016
From: nsekhar at ti.com (Sekhar Nori)
Date: Wed, 17 Feb 2016 20:41:17 +0530
Subject: [PATCH 0/4] ARM Davinci warning fixes
In-Reply-To: <1454358962-640598-1-git-send-email-arnd@arndb.de>
References: <1454358962-640598-1-git-send-email-arnd@arndb.de>
Message-ID: <56C48D95.5090303@ti.com>

On Tuesday 02 February 2016 02:05 AM, Arnd Bergmann wrote:
> Hi Kevin and Sekhar,
> 
> Here are a couple of warning fixes for Davinci that I have
> collected while testing randconfig kernels.
> 
> The first three are rather obvious, the last one might
> need some discussion, maybe there is another way to do this.
> 
> Please apply for 4.6, or Ack

Hi Arnd, I have applied the series for v4.6. I will send a pull request
soon after I am done with some testing on these.

Regards,
Sekhar


From andre.przywara at arm.com  Wed Feb 17 07:21:27 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 17 Feb 2016 15:21:27 +0000
Subject: [PATCH v2 5/8] arm64: dts: add Allwinner A64 SoC .dtsi
In-Reply-To: <1455709440-8668-6-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
 <1455709440-8668-6-git-send-email-andre.przywara@arm.com>
Message-ID: <56C48FF7.90904@arm.com>

Just saw that I forgot the Changelog, sorry about that.

On 17/02/16 11:43, Andre Przywara wrote:
> The Allwinner A64 SoC is a low-cost chip with 4 ARM Cortex-A53 cores
> and the typical tablet / TV box peripherals.
> The SoC is based on the (32-bit) Allwinner H3 chip, sharing most of
> the peripherals and the memory map.
> Although the cores are proper 64-bit ones, the whole SoC is actually
> limited to 4GB (including all the supported DRAM), so we use 32-bit
> address and size cells. This has the nice feature of us being able to
> reuse the DT for 32-bit kernels as well.
> This .dtsi lists the hardware that we support so far.

Changelog v1..v2:
- remove compatible string from the .dtsi
- amend compatible names to include sun50i
- drop PSCI 0.1 compatibility
- use lowercase hex digits in the GIC node too
- make pll6x2 an explicit fixed-factor clock
- make pll8 and pll8x2 proper clocks
- amend MMC clocks to match the manual, they are now mod0 clocks
- adapt MMC nodes to new MMC clocks
- add separate 4-pin and 2-pin definitions for the UARTs
- add I2C pins and driver nodes
- switch ahb_rst node to use normal compatible name, not the special,
  early-registration one.

Cheers,
Andre.

> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  Documentation/devicetree/bindings/arm/sunxi.txt   |   1 +
>  Documentation/devicetree/bindings/clock/sunxi.txt |   1 +
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi     | 642 ++++++++++++++++++++++
>  3 files changed, 644 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
> index 7e79fcc..7e59d8b 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -14,3 +14,4 @@ using one of the following compatible strings:
>    allwinner,sun8i-a83t
>    allwinner,sun8i-h3
>    allwinner,sun9i-a80
> +  allwinner,sun50i-a64
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index 323af8e..b7bd40d 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -80,6 +80,7 @@ Required properties:
>  	"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
>  	"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
>  	"allwinner,sunxi-multi-bus-gates-clk" - for the multi-parent bus gates
> +	"allwinner,sun50i-a64-bus-gates-clk" - for the bus gates on A64
>  
>  Required properties for all clocks:
>  - reg : shall be the control register address for the clock.
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> new file mode 100644
> index 0000000..b99f17a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -0,0 +1,642 @@
> +/*
> + * Copyright (C) 2016 ARM Ltd.
> + * based on the Allwinner H3 dtsi:
> + *    Copyright (C) 2015 Jens Kuske <jenskuske at gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This file is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +
> +/ {
> +	interrupt-parent = <&gic>;
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu at 0 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <0>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu at 1 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <1>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu at 2 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <2>;
> +			enable-method = "psci";
> +		};
> +
> +		cpu at 3 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			device_type = "cpu";
> +			reg = <3>;
> +			enable-method = "psci";
> +		};
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-0.2";
> +		method = "smc";
> +	};
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x40000000 0>;
> +	};
> +
> +	gic: interrupt-controller at 01c81000 {
> +		compatible = "arm,gic-400";
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +		#address-cells = <0>;
> +
> +		reg = <0x01c81000 0x1000>,
> +		      <0x01c82000 0x2000>,
> +		      <0x01c84000 0x2000>,
> +		      <0x01c86000 0x2000>;
> +		interrupts = <GIC_PPI 9
> +		      (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts = <GIC_PPI 13
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 14
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 11
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> +			     <GIC_PPI 10
> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> +	};
> +
> +	clocks {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		osc24M: osc24M_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-clock";
> +			clock-frequency = <24000000>;
> +			clock-output-names = "osc24M";
> +		};
> +
> +		osc32k: osc32k_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-clock";
> +			clock-frequency = <32768>;
> +			clock-output-names = "osc32k";
> +		};
> +
> +		pll1: pll1_clk at 01c20000 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun8i-a23-pll1-clk";
> +			reg = <0x01c20000 0x4>;
> +			clocks = <&osc24M>;
> +			clock-output-names = "pll1";
> +		};
> +
> +		pll6: pll6_clk at 01c20028 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun6i-a31-pll6-clk";
> +			reg = <0x01c20028 0x4>;
> +			clocks = <&osc24M>;
> +			clock-output-names = "pll6";
> +		};
> +
> +		pll6x2: pll6x2_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-factor-clock";
> +			clock-mult = <2>;
> +			clock-div = <1>;
> +			clocks = <&pll6>;
> +			clock-output-names = "pll6x2";
> +		};
> +
> +		pll6d2: pll6d2_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-factor-clock";
> +			clock-div = <2>;
> +			clock-mult = <1>;
> +			clocks = <&pll6>;
> +			clock-output-names = "pll6d2";
> +		};
> +
> +		pll8: pll8_clk at 01c2002c {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun6i-a31-pll6-clk";
> +			reg = <0x01c2002c 0x4>;
> +			clocks = <&osc24M>;
> +			clock-output-names = "pll8";
> +		};
> +
> +		pll8x2: pll8x2_clk {
> +			#clock-cells = <0>;
> +			compatible = "fixed-factor-clock";
> +			clock-mult = <2>;
> +			clock-div = <1>;
> +			clocks = <&pll8>;
> +			clock-output-names = "pll8x2";
> +		};
> +
> +		cpu: cpu_clk at 01c20050 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-a10-cpu-clk";
> +			reg = <0x01c20050 0x4>;
> +			clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
> +			clock-output-names = "cpu";
> +			critical-clocks = <0>;
> +		};
> +
> +		axi: axi_clk at 01c20050 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-a10-axi-clk";
> +			reg = <0x01c20050 0x4>;
> +			clocks = <&cpu>;
> +			clock-output-names = "axi";
> +		};
> +
> +		ahb1: ahb1_clk at 01c20054 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun6i-a31-ahb1-clk";
> +			reg = <0x01c20054 0x4>;
> +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
> +			clock-output-names = "ahb1";
> +		};
> +
> +		ahb2: ahb2_clk at 01c2005c {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun8i-h3-ahb2-clk";
> +			reg = <0x01c2005c 0x4>;
> +			clocks = <&ahb1>, <&pll6d2>;
> +			clock-output-names = "ahb2";
> +		};
> +
> +		apb1: apb1_clk at 01c20054 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-a10-apb0-clk";
> +			reg = <0x01c20054 0x4>;
> +			clocks = <&ahb1>;
> +			clock-output-names = "apb1";
> +		};
> +
> +		apb2: apb2_clk at 01c20058 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-a10-apb1-clk";
> +			reg = <0x01c20058 0x4>;
> +			clocks = <&osc32k>, <&osc24M>, <&pll6x2>, <&pll6x2>;
> +			clock-output-names = "apb2";
> +		};
> +
> +		bus_gates: bus_gates_clk at 01c20060 {
> +			#clock-cells = <1>;
> +			compatible = "allwinner,sun50i-a64-bus-gates-clk",
> +				     "allwinner,sunxi-multi-bus-gates-clk";
> +			reg = <0x01c20060 0x14>;
> +			ahb1_parent {
> +				clocks = <&ahb1>;
> +				clock-indices = <1>, <5>,
> +						<6>, <8>,
> +						<9>, <10>,
> +						<13>, <14>,
> +						<18>, <19>,
> +						<20>, <21>,
> +						<23>, <24>,
> +						<25>, <28>,
> +						<32>, <35>,
> +						<36>, <37>,
> +						<40>, <43>,
> +						<44>, <52>,
> +						<53>, <54>,
> +						<135>;
> +				clock-output-names = "bus_mipidsi", "bus_ce",
> +						"bus_dma", "bus_mmc0",
> +						"bus_mmc1", "bus_mmc2",
> +						"bus_nand", "bus_sdram",
> +						"bus_ts", "bus_hstimer",
> +						"bus_spi0", "bus_spi1",
> +						"bus_otg", "bus_otg_ehci0",
> +						"bus_ehci0", "bus_otg_ohci0",
> +						"bus_ve", "bus_lcd0",
> +						"bus_lcd1", "bus_deint",
> +						"bus_csi", "bus_hdmi",
> +						"bus_de", "bus_gpu",
> +						"bus_msgbox", "bus_spinlock",
> +						"bus_dbg";
> +			};
> +			ahb2_parent {
> +				clocks = <&ahb2>;
> +				clock-indices = <17>, <29>;
> +				clock-output-names = "bus_gmac", "bus_ohci0";
> +			};
> +			apb1_parent {
> +				clocks = <&apb1>;
> +				clock-indices = <64>, <65>,
> +						<69>, <72>,
> +						<76>, <77>,
> +						<78>;
> +				clock-output-names = "bus_codec", "bus_spdif",
> +						"bus_pio", "bus_ths",
> +						"bus_i2s0", "bus_i2s1",
> +						"bus_i2s2";
> +			};
> +			abp2_parent {
> +				clocks = <&apb2>;
> +				clock-indices = <96>, <97>,
> +						<98>, <101>,
> +						<112>, <113>,
> +						<114>, <115>,
> +						<116>;
> +				clock-output-names = "bus_i2c0", "bus_i2c1",
> +						"bus_i2c2", "bus_scr",
> +						"bus_uart0", "bus_uart1",
> +						"bus_uart2", "bus_uart3",
> +						"bus_uart4";
> +			};
> +		};
> +
> +		mmc0_clk: mmc0_clk at 01c20088 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-a10-mod0-clk";
> +			reg = <0x01c20088 0x4>;
> +			clocks = <&osc24M>, <&pll6x2>, <&pll8x2>;
> +			clock-output-names = "mmc0";
> +                };
> +
> +		mmc1_clk: mmc1_clk at 01c2008c {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-a10-mod0-clk";
> +			reg = <0x01c2008c 0x4>;
> +			clocks = <&osc24M>, <&pll6x2>, <&pll8x2>;
> +			clock-output-names = "mmc1";
> +		};
> +
> +		mmc2_clk: mmc2_clk at 01c20090 {
> +			#clock-cells = <0>;
> +			compatible = "allwinner,sun4i-a10-mod0-clk";
> +			reg = <0x01c20090 0x4>;
> +			clocks = <&osc24M>, <&pll6x2>, <&pll8x2>;
> +			clock-output-names = "mmc2";
> +		};
> +	};
> +
> +	soc {
> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		ranges;
> +
> +		mmc0: mmc at 01c0f000 {
> +			compatible = "allwinner,sun50i-a64-mmc",
> +				     "allwinner,sun5i-a13-mmc";
> +			reg = <0x01c0f000 0x1000>;
> +			clocks = <&bus_gates 8>, <&mmc0_clk>,
> +				 <&mmc0_clk>, <&mmc0_clk>;
> +			clock-names = "ahb", "mmc",
> +				      "output", "sample";
> +			resets = <&ahb_rst 8>;
> +			reset-names = "ahb";
> +			interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		mmc1: mmc at 01c10000 {
> +			compatible = "allwinner,sun50i-a64-mmc",
> +				     "allwinner,sun5i-a13-mmc";
> +			reg = <0x01c10000 0x1000>;
> +			clocks = <&bus_gates 9>, <&mmc1_clk>,
> +				 <&mmc1_clk>, <&mmc1_clk>;
> +			clock-names = "ahb", "mmc",
> +				      "output", "sample";
> +			resets = <&ahb_rst 9>;
> +			reset-names = "ahb";
> +			interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		mmc2: mmc at 01c11000 {
> +			compatible = "allwinner,sun50i-a64-mmc",
> +				     "allwinner,sun5i-a13-mmc";
> +			reg = <0x01c11000 0x1000>;
> +			clocks = <&bus_gates 10>, <&mmc2_clk>,
> +				 <&mmc2_clk>, <&mmc2_clk>;
> +			clock-names = "ahb", "mmc",
> +				      "output", "sample";
> +			resets = <&ahb_rst 10>;
> +			reset-names = "ahb";
> +			interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		pio: pinctrl at 01c20800 {
> +			compatible = "allwinner,sun50i-a64-pinctrl";
> +			reg = <0x01c20800 0x400>;
> +			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&bus_gates 69>;
> +			gpio-controller;
> +			#gpio-cells = <3>;
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +
> +			uart0_pins_a: uart0 at 0 {
> +				allwinner,pins = "PB8", "PB9";
> +				allwinner,function = "uart0";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart0_pins_b: uart0 at 1 {
> +				allwinner,pins = "PF2", "PF3";
> +				allwinner,function = "uart0";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart1_2pins: uart1_2 at 0 {
> +				allwinner,pins = "PG6", "PG7";
> +				allwinner,function = "uart1";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart1_4pins: uart1_4 at 0 {
> +				allwinner,pins = "PG6", "PG7", "PG8", "PG9";
> +				allwinner,function = "uart1";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart2_2pins: uart2_2 at 0 {
> +				allwinner,pins = "PB0", "PB1";
> +				allwinner,function = "uart2";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart2_4pins: uart2_4 at 0 {
> +				allwinner,pins = "PB0", "PB1", "PB2", "PB3";
> +				allwinner,function = "uart2";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart3_pins_a: uart3 at 0 {
> +				allwinner,pins = "PD0", "PD1";
> +				allwinner,function = "uart3";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart3_2pins_b: uart3_2 at 1 {
> +				allwinner,pins = "PH4", "PH5";
> +				allwinner,function = "uart3";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart3_4pins_b: uart3_4 at 1 {
> +				allwinner,pins = "PH4", "PH5", "PH6", "PH7";
> +				allwinner,function = "uart3";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart4_2pins: uart4_2 at 0 {
> +				allwinner,pins = "PD2", "PD3";
> +				allwinner,function = "uart4";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			uart4_4pins: uart4_4 at 0 {
> +				allwinner,pins = "PD2", "PD3", "PD4", "PD5";
> +				allwinner,function = "uart4";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			mmc0_pins: mmc0 at 0 {
> +				allwinner,pins = "PF0", "PF1", "PF2", "PF3",
> +						 "PF4", "PF5";
> +				allwinner,function = "mmc0";
> +				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			mmc0_default_cd_pin: mmc0_cd_pin at 0 {
> +				allwinner,pins = "PF6";
> +				allwinner,function = "gpio_in";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> +			};
> +
> +			mmc1_pins: mmc1 at 0 {
> +				allwinner,pins = "PG0", "PG1", "PG2", "PG3",
> +						 "PG4", "PG5";
> +				allwinner,function = "mmc1";
> +				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			mmc2_pins: mmc2 at 0 {
> +				allwinner,pins = "PC1", "PC5", "PC6", "PC8",
> +						 "PC9", "PC10";
> +				allwinner,function = "mmc2";
> +				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			i2c0_pins: i2c0_pins {
> +				allwinner,pins = "PH0", "PH1";
> +				allwinner,function = "i2c0";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			i2c1_pins: i2c1_pins {
> +				allwinner,pins = "PH2", "PH3";
> +				allwinner,function = "i2c1";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +
> +			i2c2_pins: i2c2_pins {
> +				allwinner,pins = "PE14", "PE15";
> +				allwinner,function = "i2c2";
> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> +			};
> +		};
> +
> +		ahb_rst: reset at 01c202c0 {
> +			#reset-cells = <1>;
> +			compatible = "allwinner,sun6i-a31-clock-reset";
> +			reg = <0x01c202c0 0xc>;
> +		};
> +
> +		apb1_rst: reset at 01c202d0 {
> +			#reset-cells = <1>;
> +			compatible = "allwinner,sun6i-a31-clock-reset";
> +			reg = <0x01c202d0 0x4>;
> +		};
> +
> +		apb2_rst: reset at 01c202d8 {
> +			#reset-cells = <1>;
> +			compatible = "allwinner,sun6i-a31-clock-reset";
> +			reg = <0x01c202d8 0x4>;
> +		};
> +
> +		uart0: serial at 01c28000 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x01c28000 0x400>;
> +			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clocks = <&bus_gates 112>;
> +			resets = <&apb2_rst 16>;
> +			status = "disabled";
> +		};
> +
> +		uart1: serial at 01c28400 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x01c28400 0x400>;
> +			interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clocks = <&bus_gates 113>;
> +			resets = <&apb2_rst 17>;
> +			status = "disabled";
> +		};
> +
> +		uart2: serial at 01c28800 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x01c28800 0x400>;
> +			interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clocks = <&bus_gates 114>;
> +			resets = <&apb2_rst 18>;
> +			status = "disabled";
> +		};
> +
> +		uart3: serial at 01c28c00 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x01c28c00 0x400>;
> +			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clocks = <&bus_gates 115>;
> +			resets = <&apb2_rst 19>;
> +			status = "disabled";
> +		};
> +
> +		uart4: serial at 01c29000 {
> +			compatible = "snps,dw-apb-uart";
> +			reg = <0x01c29000 0x400>;
> +			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			clocks = <&bus_gates 116>;
> +			resets = <&apb2_rst 20>;
> +			status = "disabled";
> +		};
> +
> +		rtc: rtc at 01f00000 {
> +			compatible = "allwinner,sun6i-a31-rtc";
> +			reg = <0x01f00000 0x54>;
> +			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
> +		};
> +
> +		i2c0: i2c at 01c2ac00 {
> +			compatible = "allwinner,sun6i-a31-i2c";
> +			reg = <0x01c2ac00 0x400>;
> +			interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&bus_gates 96>;
> +			resets = <&apb2_rst 0>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		i2c1: i2c at 01c2b000 {
> +			compatible = "allwinner,sun6i-a31-i2c";
> +			reg = <0x01c2b000 0x400>;
> +			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&bus_gates 97>;
> +			resets = <&apb2_rst 1>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		i2c2: i2c at 01c2b400 {
> +			compatible = "allwinner,sun6i-a31-i2c";
> +			reg = <0x01c2b400 0x400>;
> +			interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&bus_gates 98>;
> +			resets = <&apb2_rst 2>;
> +			status = "disabled";
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +	};
> +};
> 


From jayachandran.chandrashekaran at broadcom.com  Wed Feb 17 07:21:37 2016
From: jayachandran.chandrashekaran at broadcom.com (Jayachandran Chandrashekaran Nair)
Date: Wed, 17 Feb 2016 20:51:37 +0530
Subject: [PATCH V5 07/15] pci, acpi: Provide generic way to assign bus
 domain number.
In-Reply-To: <56C48C45.7050203@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
 <1455630825-27253-8-git-send-email-tn@semihalf.com>
 <CAKc_7PU+i2AwOVCyW2VNt4BZCWw=KBMAbV8v9DVQ2Ess3WE=kw@mail.gmail.com>
 <56C47E9A.5010901@semihalf.com>
 <CAKc_7PUiLQhUuJjR8wcuRm7KJdxBYjb+ZBd_cLTtjNPbEro6wA@mail.gmail.com>
 <56C48C45.7050203@semihalf.com>
Message-ID: <CAKc_7PV=p7kHt73c673L+v=KCaFV8RzoaSHwcH2gd1g-fWGq5w@mail.gmail.com>

On Wed, Feb 17, 2016 at 8:35 PM, Tomasz Nowicki <tn at semihalf.com> wrote:
> On 17.02.2016 15:21, Jayachandran Chandrashekaran Nair wrote:
>>
>> On Wed, Feb 17, 2016 at 7:37 PM, Tomasz Nowicki <tn at semihalf.com> wrote:
>>>
>>> On 17.02.2016 14:44, Jayachandran Chandrashekaran Nair wrote:
>>>>
>>>>
>>>> Tomasz, Lorenzo,
>>>>
>>>> On Tue, Feb 16, 2016 at 7:23 PM, Tomasz Nowicki<tn at semihalf.com>  wrote:
>>>>>
>>>>>
>>>>>> As we now have valid PCI host bridge device reference we can
>>>>>> introduce code that is going to find its bus domain number using
>>>>>> ACPI _SEG method.
>>>>>>
>>>>>> Note that _SEG method is optional, therefore _SEG absence means
>>>>>> that all PCI buses belong to domain 0.
>>>>>>
>>>>>> While at it, for the sake of code clarity we put ACPI and DT domain
>>>>>> assign methods into the corresponding helpers.
>>>>
>>>>
>>>> In my patchset, I had a slightly different and I think better approach
>>>> for
>>>> this without calling the _SEG method again. Please see
>>>> http://www.spinics.net/lists/arm-kernel/msg478167.html
>>>> at the last part
>>>> ofhttp://www.spinics.net/lists/arm-kernel/msg478169.html
>>>
>>>
>>> Relying on NULL parent device to make decision on boot method is really
>>> ugly
>>> way. This may hit us again once we want to obtain another firmware
>>> specific
>>> info e.g. numa node. IMO we need to fix it this way.
>>
>>
>> I am not relying on NULL there, in the current code parent is NULL
>> in case of ACPI, and the check is needed not to crash (unless that
>> has changed).
>
>
> This series passes down valid parent, see [PATCH V5 06/15].
>
>>
>> The main part was the macro acpi_pci_get_segment() and the use
>> of acpi_pci_root_info from sysdata to do this.
>
>
> Since we can obtain related firmware specific data from valid parent device
> (without defining another accessors), I do not see the point to use sysdata.
> Let me know your opinion.

In the patch, you use the parent info and call _SEG method again.
The segment information is available in the ->root->segment of
acpi_pci_root_info if you setup the sysdata like in my patch

JC.


From andre.przywara at arm.com  Wed Feb 17 07:22:39 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Wed, 17 Feb 2016 15:22:39 +0000
Subject: [PATCH v2 7/8] arm64: dts: add Pine64 support
In-Reply-To: <1455709440-8668-8-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
 <1455709440-8668-8-git-send-email-andre.przywara@arm.com>
Message-ID: <56C4903F.7050509@arm.com>

Again the changelog was missing:

On 17/02/16 11:43, Andre Przywara wrote:
> The Pine64 is a cost-efficient development board based on the
> Allwinner A64 SoC.
> There are three models: the basic version with Fast Ethernet and
> 512 MB of DRAM (Pine64) and two Pine64+ versions, which both
> feature Gigabit Ethernet and additional connectors for touchscreens
> and a camera. Or as my son put it: "Those are smaller and these are
> missing." ;-)
> The two Pine64+ models just differ in the amount of DRAM
> (1GB vs. 2GB). Since U-Boot will figure out the right size for us and
> patches the DT accordingly we just need to provide one DT for the
> Pine64+.

Changelog v1 .. v2:
- move aliases node into the common board DT file
- move fixed MMC regulator into the common board DT file
- drop UARTs 1-4 nodes from the default DT
- add I2C node (pins seem to be dedicated to I2C)

Cheers,
Andre.

> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  arch/arm64/boot/dts/Makefile                       |  1 +
>  arch/arm64/boot/dts/allwinner/Makefile             |  5 ++
>  .../dts/allwinner/sun50i-a64-pine64-common.dtsi    | 80 ++++++++++++++++++++++
>  .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  | 59 ++++++++++++++++
>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 58 ++++++++++++++++
>  5 files changed, 203 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> 
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index f832b8a..3b7428a 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -1,3 +1,4 @@
> +dts-dirs += allwinner
>  dts-dirs += altera
>  dts-dirs += amd
>  dts-dirs += apm
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> new file mode 100644
> index 0000000..1e29a5a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -0,0 +1,5 @@
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
> +
> +always		:= $(dtb-y)
> +subdir-y	:= $(dts-dirs)
> +clean-files	:= *.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi
> new file mode 100644
> index 0000000..d5a7249
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi
> @@ -0,0 +1,80 @@
> +/*
> + * Copyright (c) 2016 ARM Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This library is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "sun50i-a64.dtsi"
> +
> +/ {
> +
> +	aliases {
> +		serial0 = &uart0;
> +	};
> +
> +	soc {
> +		reg_vcc3v3: vcc3v3 {
> +			compatible = "regulator-fixed";
> +			regulator-name = "vcc3v3";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +		};
> +	};
> +};
> +
> +&mmc0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mmc0_pins>, <&mmc0_default_cd_pin>;
> +	vmmc-supply = <&reg_vcc3v3>;
> +	cd-gpios = <&pio 5 6 0>;
> +	cd-inverted;
> +	status = "okay";
> +};
> +
> +&uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_pins_a>;
> +	status = "okay";
> +};
> +
> +&i2c1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c1_pins>;
> +	status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
> new file mode 100644
> index 0000000..549dc15
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
> @@ -0,0 +1,59 @@
> +/*
> + * Copyright (c) 2016 ARM Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This library is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a64-pine64-common.dtsi"
> +
> +/ {
> +	model = "Pine64+";
> +	compatible = "pine64,pine64-plus", "allwinner,sun50i-a64";
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	/* There is a model with 2GB of DRAM, but U-Boot fixes this for us. */
> +	memory {
> +		reg = <0x40000000 0x40000000>;
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> new file mode 100644
> index 0000000..ebe029e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -0,0 +1,58 @@
> +/*
> + * Copyright (c) 2016 ARM Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This library is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a64-pine64-common.dtsi"
> +
> +/ {
> +	model = "Pine64";
> +	compatible = "pine64,pine64", "allwinner,sun50i-a64";
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	memory {
> +		reg = <0x40000000 0x20000000>;
> +	};
> +};
> 


From dirk.behme at de.bosch.com  Wed Feb 17 07:33:47 2016
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Wed, 17 Feb 2016 16:33:47 +0100
Subject: [PATCH] i.MX SPI DMA cleanup
In-Reply-To: <20160217145944.GB3939@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
 <56C478C9.6050706@de.bosch.com> <20160217135441.GA3939@pengutronix.de>
 <56C47F64.1080706@de.bosch.com> <20160217145944.GB3939@pengutronix.de>
Message-ID: <56C492DB.6000405@de.bosch.com>

On 17.02.2016 15:59, Sascha Hauer wrote:
> On Wed, Feb 17, 2016 at 03:10:44PM +0100, Dirk Behme wrote:
>> On 17.02.2016 14:54, Sascha Hauer wrote:
>>> Hi Dirk,
>>>
>>> On Wed, Feb 17, 2016 at 02:42:33PM +0100, Dirk Behme wrote:
>>>> Hi Sascha,
>>>>
>>>> On 17.02.2016 14:28, Sascha Hauer wrote:
>>>>> This picks up a series sent by Anton Bondarenko last year. It
>>>>> contains the remaining not yet upstreamed patches from Antons series
>>>>> plus some more DMA related cleanup patches.
>>>>>
>>>>> My mission was to hunt a bug in the DMA code path sometimes causing
>>>>> an additional word in the RX FIFO which locked up the driver in the
>>>>> next transfer. It turned out that this was no bug in the driver but
>>>>> instead in the device tree: We used the wrong SDMA script for i.MX6.
>>>>> The ECSPI cores are connected through the SPBA, so according to the
>>>>> reference manual we need the shp/mcu scripts rather than the app/mcu
>>>>> scripts.
>>>>
>>>>
>>>> Are you talking about what is known as "TKT238285 hardware issue"
>>>>
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/spi/spi-imx.c?id=a02bb401f8ae264be782ee57d98bdd99f14c8022
>>>
>>> I am aware of this issue, but I have no idea if this is the same or
>>> another issue. It says:
>>>
>>>> For TKT238285 hardware issue which may cause txfifo store data twice can only
>>>> be caught on i.mx6dl, we use pio mode instead of DMA mode on i.mx6dl.
>>>
>>> What I saw here is that there was one word more than expected in the RX
>>> FIFO. Since both RX and TX FIFO act synchronously it could be that the
>>> additional word in the RX FIFO was caused by an additional word in the
>>> TX FIFO as described above.
>>
>>
>> The question behind all this is if we could drop
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/spi/spi-imx.c?id=a02bb401f8ae264be782ee57d98bdd99f14c8022
>>
>> ?
>
> It seems on the i.MX6DL we (additionally) have another issue. I just
> tested here on a i.MX6DL board with a NOR Flash connected. I saw the
> same issue as I saw on the i.MX6Q, but on the i.MX6DL it cannot be fixed
> by using the shp/mcu SDMA scripts.


To my understanding this might depend on the SDMA firmware itself, as in

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.14.38_6qp_ga&id=321beb210ffb382b8b5378cbf4467f8986efd52f

Freescale patches/changes the firmware, too.


> Funny enough on the i.MX6DL the RXFIFO issue happens much more
> frequently than on the i.MX6Q.


To my understanding, the TKT238285 hardware issue exists on both i.MX6Q 
and i.MX6DL. Even though the commit message in

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/spi/spi-imx.c?id=a02bb401f8ae264be782ee57d98bdd99f14c802

states it differently. Maybe due to timing issues it happens less often 
on i.MX6Q and therefore wasn't in the focus there, yet.

Best regards

Dirk


From marc.zyngier at arm.com  Wed Feb 17 07:34:20 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 15:34:20 +0000
Subject: [PATCH] arm/arm64: KVM: Feed initialized memory to MMIO accesses
Message-ID: <1455723260-23793-1-git-send-email-marc.zyngier@arm.com>

On an MMIO access, we always copy the on-stack buffer info
the shared "run" structure, even if this is a read access.
This ends up leaking up to 8 bytes of uninitialized memory
into userspace.

An obvious fix for this one is to only perform the copy if
this is an actual write.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/mmio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
index 7f33b20..0f6600f 100644
--- a/arch/arm/kvm/mmio.c
+++ b/arch/arm/kvm/mmio.c
@@ -206,7 +206,8 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run,
 	run->mmio.is_write	= is_write;
 	run->mmio.phys_addr	= fault_ipa;
 	run->mmio.len		= len;
-	memcpy(run->mmio.data, data_buf, len);
+	if (is_write)
+		memcpy(run->mmio.data, data_buf, len);
 
 	if (!ret) {
 		/* We handled the access successfully in the kernel. */
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 07:34:41 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 15:34:41 +0000
Subject: [PATCH] arm/arm64: KVM: vgic: Handle out-of-bound MMIO access
Message-ID: <1455723281-23846-1-git-send-email-marc.zyngier@arm.com>

When performing a MMIO access via a KVM IO bus, it is possible
that the access will actually be out-of-bounds (the redistributor
handlers do not cover the whole device, for example). In this case,
we return an error code, which leads to escaping to userspace
to handle it. Not that good.

Instead, let's just treat it like any other OOB access, by either
ignoring the write, or by returning a bunch of zeroes.

And let's keep the code quiet while we're at it, as nobody likes
it when a guest can generate zillions on messages on the host's
console...

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 virt/kvm/arm/vgic.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 043032c..2358272 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -830,8 +830,11 @@ static int vgic_handle_mmio_access(struct kvm_vcpu *vcpu,
 	offset = addr - iodev->addr;
 	range = vgic_find_range(iodev->reg_ranges, len, offset);
 	if (unlikely(!range || !range->handle_mmio)) {
-		pr_warn("Unhandled access %d %08llx %d\n", is_write, addr, len);
-		return -ENXIO;
+		/* Treat an OOR access as RAZ/WI. */
+		if (!is_write)
+			memset(val, 0, len);
+		pr_debug("Unhandled access %d %08llx %d\n", is_write, addr, len);
+		return 0;
 	}
 
 	mmio.phys_addr = addr;
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 07:35:12 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 15:35:12 +0000
Subject: [PATCH] arm64: KVM: vgic-v3: Restore ICH_APR0Rn_EL2 before
 ICH_APR0Rn_EL2
Message-ID: <1455723312-23896-1-git-send-email-marc.zyngier@arm.com>

The GICv3 architecture spec says:

Writing to the active priority registers in any order other than
the following order will result in UNPREDICTABLE behavior:
- ICH_AP0R<n>_EL2.
- ICH_AP1R<n>_EL2.

So let's not pointlessly go against the rule...

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/vgic-v3-sr.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
index 9142e082..93f6c5c 100644
--- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
@@ -149,16 +149,6 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
 
 	switch (nr_pri_bits) {
 	case 7:
-		 write_gicreg(cpu_if->vgic_ap1r[3], ICH_AP1R3_EL2);
-		 write_gicreg(cpu_if->vgic_ap1r[2], ICH_AP1R2_EL2);
-	case 6:
-		 write_gicreg(cpu_if->vgic_ap1r[1], ICH_AP1R1_EL2);
-	default:
-		 write_gicreg(cpu_if->vgic_ap1r[0], ICH_AP1R0_EL2);
-	}	 	                           
-		 	                           
-	switch (nr_pri_bits) {
-	case 7:
 		 write_gicreg(cpu_if->vgic_ap0r[3], ICH_AP0R3_EL2);
 		 write_gicreg(cpu_if->vgic_ap0r[2], ICH_AP0R2_EL2);
 	case 6:
@@ -167,6 +157,16 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
 		 write_gicreg(cpu_if->vgic_ap0r[0], ICH_AP0R0_EL2);
 	}
 
+	switch (nr_pri_bits) {
+	case 7:
+		 write_gicreg(cpu_if->vgic_ap1r[3], ICH_AP1R3_EL2);
+		 write_gicreg(cpu_if->vgic_ap1r[2], ICH_AP1R2_EL2);
+	case 6:
+		 write_gicreg(cpu_if->vgic_ap1r[1], ICH_AP1R1_EL2);
+	default:
+		 write_gicreg(cpu_if->vgic_ap1r[0], ICH_AP1R0_EL2);
+	}	 	                           
+		 	                           
 	switch (max_lr_idx) {
 	case 15:
 		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(15)], ICH_LR15_EL2);
-- 
2.1.4



From tn at semihalf.com  Wed Feb 17 07:35:30 2016
From: tn at semihalf.com (Tomasz Nowicki)
Date: Wed, 17 Feb 2016 16:35:30 +0100
Subject: [PATCH V5 07/15] pci, acpi: Provide generic way to assign bus
 domain number.
In-Reply-To: <CAKc_7PV=p7kHt73c673L+v=KCaFV8RzoaSHwcH2gd1g-fWGq5w@mail.gmail.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
 <1455630825-27253-8-git-send-email-tn@semihalf.com>
 <CAKc_7PU+i2AwOVCyW2VNt4BZCWw=KBMAbV8v9DVQ2Ess3WE=kw@mail.gmail.com>
 <56C47E9A.5010901@semihalf.com>
 <CAKc_7PUiLQhUuJjR8wcuRm7KJdxBYjb+ZBd_cLTtjNPbEro6wA@mail.gmail.com>
 <56C48C45.7050203@semihalf.com>
 <CAKc_7PV=p7kHt73c673L+v=KCaFV8RzoaSHwcH2gd1g-fWGq5w@mail.gmail.com>
Message-ID: <56C49342.1070308@semihalf.com>

On 17.02.2016 16:21, Jayachandran Chandrashekaran Nair wrote:
> On Wed, Feb 17, 2016 at 8:35 PM, Tomasz Nowicki <tn at semihalf.com> wrote:
>> On 17.02.2016 15:21, Jayachandran Chandrashekaran Nair wrote:
>>>
>>> On Wed, Feb 17, 2016 at 7:37 PM, Tomasz Nowicki <tn at semihalf.com> wrote:
>>>>
>>>> On 17.02.2016 14:44, Jayachandran Chandrashekaran Nair wrote:
>>>>>
>>>>>
>>>>> Tomasz, Lorenzo,
>>>>>
>>>>> On Tue, Feb 16, 2016 at 7:23 PM, Tomasz Nowicki<tn at semihalf.com>  wrote:
>>>>>>
>>>>>>
>>>>>>> As we now have valid PCI host bridge device reference we can
>>>>>>> introduce code that is going to find its bus domain number using
>>>>>>> ACPI _SEG method.
>>>>>>>
>>>>>>> Note that _SEG method is optional, therefore _SEG absence means
>>>>>>> that all PCI buses belong to domain 0.
>>>>>>>
>>>>>>> While at it, for the sake of code clarity we put ACPI and DT domain
>>>>>>> assign methods into the corresponding helpers.
>>>>>
>>>>>
>>>>> In my patchset, I had a slightly different and I think better approach
>>>>> for
>>>>> this without calling the _SEG method again. Please see
>>>>> http://www.spinics.net/lists/arm-kernel/msg478167.html
>>>>> at the last part
>>>>> ofhttp://www.spinics.net/lists/arm-kernel/msg478169.html
>>>>
>>>>
>>>> Relying on NULL parent device to make decision on boot method is really
>>>> ugly
>>>> way. This may hit us again once we want to obtain another firmware
>>>> specific
>>>> info e.g. numa node. IMO we need to fix it this way.
>>>
>>>
>>> I am not relying on NULL there, in the current code parent is NULL
>>> in case of ACPI, and the check is needed not to crash (unless that
>>> has changed).
>>
>>
>> This series passes down valid parent, see [PATCH V5 06/15].
>>
>>>
>>> The main part was the macro acpi_pci_get_segment() and the use
>>> of acpi_pci_root_info from sysdata to do this.
>>
>>
>> Since we can obtain related firmware specific data from valid parent device
>> (without defining another accessors), I do not see the point to use sysdata.
>> Let me know your opinion.
>
> In the patch, you use the parent info and call _SEG method again.
> The segment information is available in the ->root->segment of
> acpi_pci_root_info if you setup the sysdata like in my patch

I know it is in sysdata->root->segment, but the way it is passed down is 
wrong. sysdata is the pointer to unknown content (void *) so we need to 
validate it before we can use it. If we merge this patch we can remove 
first _SEG call.

Tomasz


From festevam at gmail.com  Wed Feb 17 07:40:42 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 17 Feb 2016 13:40:42 -0200
Subject: [PATCH] i.MX SPI DMA cleanup
In-Reply-To: <56C492DB.6000405@de.bosch.com>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
 <56C478C9.6050706@de.bosch.com>
 <20160217135441.GA3939@pengutronix.de>
 <56C47F64.1080706@de.bosch.com>
 <20160217145944.GB3939@pengutronix.de>
 <56C492DB.6000405@de.bosch.com>
Message-ID: <CAOMZO5Bcwf335VY2809YU2b_-+jntJ_pjNQw_E+jdvEYV==NrQ@mail.gmail.com>

On Wed, Feb 17, 2016 at 1:33 PM, Dirk Behme <dirk.behme at de.bosch.com> wrote:

> To my understanding, the TKT238285 hardware issue exists on both i.MX6Q and
> i.MX6DL. Even though the commit message in
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/spi/spi-imx.c?id=a02bb401f8ae264be782ee57d98bdd99f14c802
>
> states it differently. Maybe due to timing issues it happens less often on
> i.MX6Q and therefore wasn't in the focus there, yet.

Yes, this is my understanding as well.


From davem at davemloft.net  Wed Feb 17 07:51:04 2016
From: davem at davemloft.net (David Miller)
Date: Wed, 17 Feb 2016 10:51:04 -0500 (EST)
Subject: [PATCH] drivers: net: cpsw-phy-sel: add dev_warn() for
 unsupported PHY mode
In-Reply-To: <1455324336-3884-1-git-send-email-drivshin.allworx@gmail.com>
References: <1455324336-3884-1-git-send-email-drivshin.allworx@gmail.com>
Message-ID: <20160217.105104.143723229571677119.davem@davemloft.net>

From: "David Rivshin (Allworx)" <drivshin.allworx at gmail.com>
Date: Fri, 12 Feb 2016 19:45:36 -0500

> From: David Rivshin <drivshin at allworx.com>
> 
> The cpsw-phy-sel driver supports only MII, RMII, and RGMII PHY modes,
> and silently handled any other values as if MII was specified. In a
> case where the PHY mode was incorrectly specified, or a bug elsewhere,
> there would be no indication of a problem. If MII was the correct mode,
> then this will go unnoticed, otherwise the symptom will be a failure
> to transmit/receive data over the RMII/RGMII link.
> 
> Add a dev_warn() to make this condition obvious and provide a
> breadcrumb to follow.
> 
> Cc: Mugunthan V N <mugunthanvnm at ti.com>
> Signed-off-by: David Rivshin <drivshin at allworx.com>

Applied to 'net', thanks.  I don't think I'll queue this up for -stable.

Thanks.


From arnd at arndb.de  Wed Feb 17 08:00:15 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 17:00:15 +0100
Subject: [PATCH 1/7] usb: gadget: pxa25x_udc: move register definitions
 from arch
In-Reply-To: <87oabfgys4.fsf@ti.com>
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <1453997843-3489728-1-git-send-email-arnd@arndb.de> <87oabfgys4.fsf@ti.com>
Message-ID: <16402463.pdHgaqhrJe@wuerfel>

On Wednesday 17 February 2016 17:08:27 Felipe Balbi wrote:
> 
> Hi,
> 
> Arnd Bergmann <arnd at arndb.de> writes:
> > ixp4xx and pxa25x both use this driver and provide a slightly
> > different set of register definitions for it. Aside from that,
> > the definition in the ixp4xx-regs.h header conflicts with the
> > on in the pxa27x device driver when compile-testing that:
> >
> > In file included from ../drivers/usb/gadget/udc/pxa27x_udc.c:37:0:
> > ../drivers/usb/gadget/udc/pxa27x_udc.h:26:0: warning: "UDCCR" redefined
> >  #define UDCCR  0x0000  /* UDC Control Register */
> >  ^
> > In file included from ../arch/arm/mach-ixp4xx/include/mach/hardware.h:27:0,
> >                  from ../arch/arm/mach-ixp4xx/include/mach/io.h:18,
> >                  from ../arch/arm/include/asm/io.h:194,
> >                  from ../include/linux/io.h:25,
> >                  from ../include/linux/irq.h:24,
> >                  from ../drivers/usb/gadget/udc/pxa27x_udc.c:23:
> > ../arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h:415:0: note: this is the location of the previous definition
> >  #define UDCCR  IXP4XX_USB_REG(IXP4XX_USB_BASE_VIRT+0x0000)
> >
> > This addresses both issues by moving all the definitions into the
> > pxa25x_udc driver itself. It turns out the only difference between
> > them was 'UDCCS_IO_ROF', and that could well be a mistake when it
> > was incorrectly copied from pxa25x to ixp4xx.
> >
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> 
> FYI, this series now sits in my testing/next. If you could just check
> that I didn't mess anything up, I'd be glad.
> 

Thank you for merging this and my other patches!

After the latest discussion with Krzysztof, I think it would be good
to include the patch below, either on top or folded into the last
patch of the series (whichever fits your workflow).

	Arnd
 
8<----
>From 3feea5e42eae444e122f3ad51fef9e08d758fc27 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd at arndb.de>
Date: Wed, 17 Feb 2016 16:51:40 +0100
Subject: [PATCH] usb: gadget: pxa25x_udc: document endianess better
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When I wrote the cleanup patch series, it was not clear how
exactly big-endian mode works on ixp4xx, and whether the driver
was doing this correctly. After discussing with Krzysztof Ha?asa,
this has been clarified, so I can update the comment let pxa25x
big-endian (which we don't support) work the same way as ixp4xx.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>

diff --git a/drivers/usb/gadget/udc/pxa25x_udc.c b/drivers/usb/gadget/udc/pxa25x_udc.c
index ca7abdc0eca9..33b7fb84f4fb 100644
--- a/drivers/usb/gadget/udc/pxa25x_udc.c
+++ b/drivers/usb/gadget/udc/pxa25x_udc.c
@@ -289,14 +289,14 @@ static void pullup_on(void)
 		mach->udc_command(PXA2XX_UDC_CMD_CONNECT);
 }
 
-#if defined(CONFIG_ARCH_IXP4XX) && defined(CONFIG_CPU_BIG_ENDIAN)
+#if defined(CONFIG_CPU_BIG_ENDIAN)
 /*
- * not sure if this is the correct behavior on ixp4xx in both
- * bit-endian and little-endian modes, but it's what the driver
- * has always done using direct pointer dereferences:
- * We assume that there is a byteswap done in hardware at the
- * MMIO register that matches what the CPU setting is, so we
- * never swap in software.
+ * IXP4xx has its buses wired up in a way that relies on never doing any
+ * byte swaps, independent of whether it runs in big-endian or little-endian
+ * mode, as explained by Krzysztof Ha?asa.
+ *
+ * We only support pxa25x in little-endian mode, but it is very likely
+ * that it works the same way.
  */
 static inline void udc_set_reg(struct pxa25x_udc *dev, u32 reg, u32 val)
 {



From gregory.clement at free-electrons.com  Wed Feb 17 08:03:15 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed, 17 Feb 2016 17:03:15 +0100
Subject: [PATCH v4 00/12] Add support for the Armada 3700 SoC an mvebu
 ARM64 based
In-Reply-To: <2699923.cugyhCaCQy@wuerfel> (Arnd Bergmann's message of "Tue, 16
 Feb 2016 22:22:11 +0100")
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
 <2699923.cugyhCaCQy@wuerfel>
Message-ID: <87a8mzs4sc.fsf@free-electrons.com>

Hi Arnd,
 
 On mar., f?vr. 16 2016, Arnd Bergmann <arnd at arndb.de> wrote:

> On Tuesday 16 February 2016 19:14:50 Gregory CLEMENT wrote:
>> This series introduce the support of the Armada 3700 family: it is the
>> first ARM64 SoC of the mvebu family submitted to the mainline!
>> 
>> Currently there are two members of the Armada 3700 family, the only
>> difference is the number of core: the Armada 3710 comes with one
>> Cortex-A53 whereas the Armada 3720 comes with 2 Cortex-A53. In this
>> series we enabled only the minimum to boot, pinctrl and clock tree
>> will come soon.
>> 
>
> Whole series
>
> Acked-by: Arnd Bergmann <arnd at arndb.de>

Great!

I am going to do a first pull requests for the mvebu arm64. Let me know
if I do it correctly.

Thanks,

Gregory

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From broonie at kernel.org  Wed Feb 17 08:05:35 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Feb 2016 16:05:35 +0000
Subject: [PATCH 01/13] spi: imx: allow only WML aligned transfers to use
 DMA
In-Reply-To: <20160217150146.GC3939@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
 <1455715739-25161-2-git-send-email-s.hauer@pengutronix.de>
 <20160217141619.GR7544@sirena.org.uk>
 <20160217150146.GC3939@pengutronix.de>
Message-ID: <20160217160535.GW7544@sirena.org.uk>

On Wed, Feb 17, 2016 at 04:01:46PM +0100, Sascha Hauer wrote:

> You seem to have a template for this, I remember having read the same
> text before ;)

I do, but even before I had a template I'd always end up typing the same
thing by hand anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/c79057ee/attachment-0001.sig>

From vigneshr at ti.com  Wed Feb 17 08:11:10 2016
From: vigneshr at ti.com (R, Vignesh)
Date: Wed, 17 Feb 2016 21:41:10 +0530
Subject: [PATCH v5 3/5] mtd: devices: m25p80: add support for mmap read
 request
In-Reply-To: <20160216123854.GJ18327@sirena.org.uk>
References: <1449807000-6457-1-git-send-email-vigneshr@ti.com>
 <1449807000-6457-4-git-send-email-vigneshr@ti.com>
 <20160209193616.GN13270@sirena.org.uk> <56BC1D3E.5020203@ti.com>
 <20160212223711.GD18988@sirena.org.uk> <56C2D731.6050306@ti.com>
 <20160216123854.GJ18327@sirena.org.uk>
Message-ID: <56C49B9E.8060506@ti.com>



On 02/16/2016 06:08 PM, Mark Brown wrote:
> On Tue, Feb 16, 2016 at 01:30:49PM +0530, Vignesh R wrote:
>> On 02/13/2016 04:07 AM, Mark Brown wrote:
>>> On Thu, Feb 11, 2016 at 11:03:50AM +0530, Vignesh R wrote:
>>>> On 02/10/2016 01:06 AM, Mark Brown wrote:
> 
>>>>> Looking at this I can't help but think that spi_flash_read() ought to
>>>>> have the stub in rather than the caller.  But given that we're pretty
>>>>> much only ever expecting one user I'm not 100% sure it actually matters.
> 
>>>> Well, my initial patch set passed long list of arguments to
>>>> spi_flash_read(), but Brian suggested to use struct[1] in order to avoid
>>>> unnecessary churn when things need changed in the API.
> 
>>> I don't see what that has to do with my point?
> 
>> AFAIU, your previous comment was to move initialization of
>> spi_flash_read_message struct to spi_flash_read(). This would mean
> 
> No, not at all.  I'm talking about how we handle the case where we don't
> have hardware support for this and need to implement it in software -
> currently that's in a separate place to the place where we call the
> driver.
> 

Yeah, but AFAIK, hardware accelerated read support is applicable for
m25p80 flashes only, I doubt whether spi_flash_read() will be used by
other types. I felt keeping the software implementation in m25p80_read()
will be consistent with m25p80_write().


-- 
Regards
Vignesh


From gregory.clement at free-electrons.com  Wed Feb 17 08:12:40 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed, 17 Feb 2016 17:12:40 +0100
Subject: [GIT PULL] ARM: mvebu: arm64 for v4.6 (#1)
Message-ID: <878u2js4cn.fsf@free-electrons.com>

Hi,

Here is the first pull request for arm64 for mvebu for v4.6. It is even
the first pull request ever for arm64 for us. Let me know if I am doing
it wrong.

I split my initial series[1] in two parts: device tree related and non
device tree related. I will also let the driver maintainers directly
take the related patch for ATA and serial.

For this non device tree part I have a dependency with the irchip
subsystem. For this I based on the irqchip/mvebu immutable branch form
Jason Cooper located at git://git.infradead.org/users/jcooper/linux.git.

Thanks,

Gregory

[1]: https://lkml.org/lkml/2016/2/16/735

The following changes since commit 63131b636a0ec969e8b98122c1a928b5a2649d3b:

  irqchip/armada-370-xp: Do not enable it by default when ARCH_MVEBU is selected (2016-02-16 18:11:39 +0000)

are available in the git repository at:

  git://git.infradead.org/linux-mvebu.git tags/mvebu-arm64-4.6-1

for you to fetch changes up to e772ca05cceb1480bdc7a7579e042b18558d0959:

  arm64: defconfig: enable Armada 3700 related config (2016-02-17 16:23:20 +0100)

----------------------------------------------------------------
mvebu arm64 for 4.6 (part 1)

Non dt part of the Armada 3700 support:
- Kconfig update
- defconfig update
- documentation update (including MAINTAINERS:)

----------------------------------------------------------------
Gregory CLEMENT (4):
      arm64: add mvebu architecture entry
      MAINTAINERS: Extend dts entry for ARM64 mvebu files
      Documentation: arm: update supported Marvell EBU processors
      arm64: defconfig: enable Armada 3700 related config

 Documentation/arm/Marvell/README | 13 +++++++++++++
 MAINTAINERS                      |  1 +
 arch/arm64/Kconfig.platforms     |  6 ++++++
 arch/arm64/configs/defconfig     |  5 +++++
 4 files changed, 25 insertions(+)


From tglx at linutronix.de  Wed Feb 17 08:12:04 2016
From: tglx at linutronix.de (Thomas Gleixner)
Date: Wed, 17 Feb 2016 17:12:04 +0100 (CET)
Subject: [PATCH V3] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <1455653329-4934-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1455653329-4934-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <alpine.DEB.2.11.1602171710350.19512@nanos>

On Tue, 16 Feb 2016, tchalamarla at caviumnetworks.com wrote:
> +#ifdef CONFIG_ARM64
> +/* Due to ERRATA#22536, ThunderX need to handle
> + * HOST_IRQ_STAT differently.
> + * Work around is to make sure all pending IRQs
> + * are served before leaving handler
> + */
> +static irqreturn_t ahci_thunderx_irq_handler(int irq, void *dev_instance)
> +{
> +	struct ata_host *host = dev_instance;
> +	struct ahci_host_priv *hpriv;
> +	unsigned int rc = 0;
> +	void __iomem *mmio;
> +	u32 irq_stat, irq_masked;
> +	unsigned int handled = 1;
> +
> +	VPRINTK("ENTER\n");

Come on. This VPRINK stuff is really pointless. Enable irq tracepoints, they
already track the enter/exit of interrupt handlers ....

Thanks,

	tglx




From khalasa at piap.pl  Wed Feb 17 08:14:35 2016
From: khalasa at piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=)
Date: Wed, 17 Feb 2016 17:14:35 +0100
Subject: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
In-Reply-To: <2926671.iEYNiy920m@wuerfel> (Arnd Bergmann's message of "Wed, 17
 Feb 2016 11:36:49 +0100")
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <3062977.Ya2ztQYFaM@wuerfel> <m3ziuzpwbu.fsf@t19.piap.pl>
 <2926671.iEYNiy920m@wuerfel>
Message-ID: <m3r3gbpb4k.fsf@t19.piap.pl>

Arnd Bergmann <arnd at arndb.de> writes:

> Ok, so I guess what this means is that ixp4xx (or xscale in general)
> implements its big-endian mode by adding a byteswap on its DRAM
> and PCI interfaces in be32 mode, rather than by changing the behavior of
> the load/store operations (as be8 mode does) or by having the byteswap
> in its load/store pipeline or the top-level AHB bridge?

Hmm... IIRC, there is normally no swapping on DRAM bus. E.g. if you
write 0x12345678 to RAM and change endianness, it will still read as
0x12345678. The CPU will still be able to execute opcodes after
switching endianness, but byte-oriented data will be messed up.

PCI swaps in BE mode, so byte order is preserved but readl() must
"unswap" it.

> I'm still unsure about
> __indirect_readsl()/ioread32_rep()/insl()/readsl().

Indirect ops should behave the same as direct. I think I have tested
them at some point. The "string" operations don't have to swap (on PCI)
because the PCI bus controller does it for them (in BE mode).

> insl() does a double-swap on big-endian, which seems right, as we
> end up with four swaps total, preserving correct byte order.

static inline void insl(u32 io_addr, void *p, u32 count)
{
        u32 *vaddr = p;
        while (count--)
                *vaddr++ = le32_to_cpu(inl(io_addr));
}

inl() does indirect input (preserving value, not byte order), so there seem
to be just one swap here (le32_to_cpu) preserving byte order.

> __raw_readsl() performs no swap, which would be correct for PCI
> (same swap on PCI and RAM, so byteorder is preserved),

No, a single swap on PCI, this means the byte order is preserved :-)

> but wrong
> for on-chip FIFO registers (one swap on RAM, no swap on MMIO).

But there aren't any such registers. Basically, almost all registers are
32-bit, even if they only hold an 8-bit value.
Exceptions such as 16550 UARTs are taken care of in platform structs
(using offset = 3).

> However, when CONFIG_IXP4XX_INDIRECT_PCI is set, both
> ioread32_rep() and readsl() call __indirect_readsl(), which
> in turn swaps the data once, so I think we actually need this patch:
>
> diff --git a/arch/arm/mach-ixp4xx/include/mach/io.h b/arch/arm/mach-ixp4xx/include/mach/io.h

> @@ -100,7 +102,7 @@ static inline void __indirect_writesw(volatile void __iomem *bus_addr,
>  	const u16 *vaddr = p;
>  
>  	while (count--)
> -		writew(*vaddr++, bus_addr);
> +		writew((u16 __force)cpu_to_le32(*vaddr++), bus_addr);
>  }

...

> Does that make sense to you? This is essentially the same thing we already
> do for inw/inl/outw/outl.

Well, we may need something like this. It seems writesw() (and thus
__indirect_writesw()) etc. use le16 values (preserving byte order), so
the above should probably use le16_to_cpu() instead (and le32_to_cpu in
__indirect_writesl()). I think the only thing that can use it on my hw
is VIA PATA adapter (throught ioread32_rep() etc). I will have to dig it
up as well.
I wouldn't rather touch this stuff without verifying that it fixes
things up.


Thanks for looking into this.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland


From gregory.clement at free-electrons.com  Wed Feb 17 08:14:52 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Wed, 17 Feb 2016 17:14:52 +0100
Subject: [GIT PULL] ARM: mvebu: dt64 for v4.6 (#1)
Message-ID: <877fi3s48z.fsf@free-electrons.com>

Hi,

Here is the first pull request for dt64 for mvebu for v4.6.

This is the second part of the Armada 3700 series[1]. This part is
easier to handle as there is no dependency. As for the other one, let me
know if I should do it in a different way.

Thanks,

Gregory

[1]: https://lkml.org/lkml/2016/2/16/735

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.infradead.org/linux-mvebu.git tags/mvebu-dt64-4.6-1

for you to fetch changes up to adbc3695d9e487fa07214140a46b68ac3156fb78:

  arm64: dts: add the Marvell Armada 3700 family and a development board (2016-02-17 16:09:55 +0100)

----------------------------------------------------------------
mvebu dt64 for 4.6 (part 1)

Device tree part of the Armada 3700 support:
- binding for the Armada 3700 SoCs
- device tree files for the SoCs and a board
- tidy up the Marvell related files

----------------------------------------------------------------
Gregory CLEMENT (4):
      Documentation: dt-bindings: Add a new compatible for the Armada 3700
      Documentation: dt: Tidy up the Marvell related files
      devicetree: bindings: add DT binding for the Marvell Armada 3700 SoC family
      arm64: dts: add the Marvell Armada 3700 family and a development board

 .../arm/{ => marvell}/armada-370-xp-pmsu.txt       |   0
 .../bindings/arm/{ => marvell}/armada-370-xp.txt   |   0
 .../bindings/arm/{ => marvell}/armada-375.txt      |   0
 .../bindings/arm/marvell/armada-37xx.txt           |  16 +++
 .../{ => marvell}/armada-380-mpcore-soc-ctrl.txt   |   0
 .../bindings/arm/{ => marvell}/armada-38x.txt      |   0
 .../bindings/arm/{ => marvell}/armada-39x.txt      |   0
 .../arm/{ => marvell}/armada-cpu-reset.txt         |   0
 .../arm/{ => marvell}/coherency-fabric.txt         |   0
 .../bindings/arm/{ => marvell}/kirkwood.txt        |   0
 .../bindings/arm/{ => marvell}/marvell,berlin.txt  |   0
 .../bindings/arm/{ => marvell}/marvell,dove.txt    |   0
 .../arm/{ => marvell}/marvell,kirkwood.txt         |   0
 .../arm/{ => marvell}/mvebu-cpu-config.txt         |   0
 .../arm/{ => marvell}/mvebu-system-controller.txt  |   0
 .../devicetree/bindings/ata/ahci-platform.txt      |   1 +
 arch/arm64/boot/dts/marvell/Makefile               |   4 +
 arch/arm64/boot/dts/marvell/armada-371x.dtsi       |  53 +++++++++
 arch/arm64/boot/dts/marvell/armada-3720-db.dts     |  86 ++++++++++++++
 arch/arm64/boot/dts/marvell/armada-372x.dtsi       |  63 ++++++++++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi       | 131 +++++++++++++++++++++
 21 files changed, 354 insertions(+)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp-pmsu.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-370-xp.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-375.txt (100%)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-380-mpcore-soc-ctrl.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-38x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-39x.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/armada-cpu-reset.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/coherency-fabric.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,berlin.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,dove.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/marvell,kirkwood.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-cpu-config.txt (100%)
 rename Documentation/devicetree/bindings/arm/{ => marvell}/mvebu-system-controller.txt (100%)
 create mode 100644 arch/arm64/boot/dts/marvell/armada-371x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-3720-db.dts
 create mode 100644 arch/arm64/boot/dts/marvell/armada-372x.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-37xx.dtsi


From linus.walleij at linaro.org  Wed Feb 17 08:17:33 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 17 Feb 2016 17:17:33 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56C438DA.5040109@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <56C438DA.5040109@ti.com>
Message-ID: <CACRpkdZ+G17hmVP8AejL7NTqg7k0SBC5kgF55ASjD+kfuGFJhQ@mail.gmail.com>

On Wed, Feb 17, 2016 at 10:09 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:

>> Tested on Versatile AB with just VGA with the default device tree,
>> and with the IB2 daughterboard with the custom IB2 device tree.
>> Tested to shunt in XVGA by modifying the device tree and this works
>> too. Also tested on QEMU for Versatile in both VGA and Sanyo 2.5"
>> mode. I don't have the IB1 daughterboard and its add-on displays,
>> but it should work as long as the detection mechanism and device
>> tree parameters are sound.
>
> Well... I don't like this very much. The .dts should contain
> descriptions for hardware that is connected. Have you looked at DT
> overlays? I think they would be a much better match for this.

I'll look into it. I don't know how good those are. They must be overlaid
at runtime and anyways exist somewhere in memory so they can be
overlaid in there.

> What's the SYS_CLCD register? An EEPROM or such, programmed when the
> board is manufactured? Is the panel meant to be switchable by the user,
> possibly to a panel that's not "standard"?

As Russell points out: it's a register that contains a number saying what
panel is connected.

So it is plug-n-play and I want to preserve this in the patch.

The alternative is to make one DTS per display type connected, but that is
loosing all the nice plug'n'play :(

But if an overlay can do the same, I'm game for it.

Yours,
Linus Walleij


From broonie at kernel.org  Wed Feb 17 08:22:40 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 17 Feb 2016 16:22:40 +0000
Subject: [PATCH] ASoC: atmel_ssc_dai: distinguish the different SSC
In-Reply-To: <56C28F5D.5010000@atmel.com>
References: <1452666910-23586-1-git-send-email-songjun.wu@atmel.com>
 <56966852.8050205@atmel.com> <56C28F5D.5010000@atmel.com>
Message-ID: <20160217162240.GX7544@sirena.org.uk>

On Tue, Feb 16, 2016 at 10:54:21AM +0800, Wu, Songjun wrote:

> Any comments on this patch?

Please don't send content free pings.  Sending content free pings just
adds to the mail volume (if they are seen at all) and if something has
gone wrong you'll have to resend the patches anyway.

Please also don't top post, reply in line with needed context.  This
allows readers to readily follow the flow of conversation and understand
what you are talking about and also helps ensure that everything in the
discussion is being addressed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/18283d7a/attachment.sig>

From fengguang.wu at intel.com  Wed Feb 17 08:26:46 2016
From: fengguang.wu at intel.com (kbuild test robot)
Date: Thu, 18 Feb 2016 00:26:46 +0800
Subject: [arm:for-next 24/31] arch/arm/kernel/hyp-stub.S:168: Error: selected
 processor does not support ARM mode `ubfx r7,r7,#28,#4'
Message-ID: <201602180044.PcvJbrb9%fengguang.wu@intel.com>

tree:   http://repo.or.cz/linux-2.6/linux-2.6-arm.git for-next
head:   5aeac3b523644cbc300f17d67c8fce73df9060c0
commit: e59941b9b3817c9b1dd6662d903150fe3f3c3b0b [24/31] ARM: 8527/1: virt: enable GICv3 system registers
config: arm-allmodconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        git checkout e59941b9b3817c9b1dd6662d903150fe3f3c3b0b
        # save the attached .config to linux build tree
        make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   arch/arm/kernel/hyp-stub.S: Assembler messages:
>> arch/arm/kernel/hyp-stub.S:168: Error: selected processor does not support ARM mode `ubfx r7,r7,#28,#4'
>> arch/arm/kernel/hyp-stub.S:176: Error: selected processor does not support ARM mode `isb'

vim +168 arch/arm/kernel/hyp-stub.S

   162	1:
   163	#endif
   164	
   165	#ifdef CONFIG_ARM_GIC_V3
   166		@ Check whether GICv3 system registers are available
   167		mrc	p15, 0, r7, c0, c1, 1	@ ID_PFR1
 > 168		ubfx	r7, r7, #28, #4
   169		cmp	r7, #1
   170		bne	2f
   171	
   172		@ Enable system register accesses
   173		mrc	p15, 4, r7, c12, c9, 5	@ ICC_HSRE
   174		orr	r7, r7, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
   175		mcr	p15, 4, r7, c12, c9, 5	@ ICC_HSRE
 > 176		isb
   177	
   178		@ SRE bit could be forced to 0 by firmware.
   179		@ Check whether it sticks before accessing any other sysreg

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 56246 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160218/1033e90f/attachment-0001.obj>

From jeremy.linton at arm.com  Wed Feb 17 08:29:52 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Wed, 17 Feb 2016 10:29:52 -0600
Subject: [PATCH v2 0/2] flag contiguous PTEs in linear mapping
Message-ID: <1455726594-16104-1-git-send-email-jeremy.linton@arm.com>

This is a rebase of the previous contiguous ptes in linear map patches
on top of Mark Rutland's fixmap changes. Those changes appear to be sufficient
to allow this patch set to boot on JunoR2, seattle and the xgene/m400. I've
also done basic testing with RODATA turned on. In all cases with ACPI systems.

This patch also adds the ability to align 64k kernels on the 2M CONT boundary
which helps to assure that a number of the sections are completely mapped with
CONT bits. There remain a number of holes due to smaller remapping operations
that don't really affect the page protection states. That can be worked around
in a number of cases if the code gets smart enough to detect that the break
doesn't result in an actual change in permissions. Some of these are visible
in the included example where its not initially obvious why a contigious 2M
region isn't marked as such until digging into it.

Changed v1->v2:
    16k kernels now use CONT_SIZE rather than SECTION_SIZE for alignment.


With 64k pages, and section alignment enabled the kernel looks like:
---[ Kernel Mapping ]---
0xfffffe0000000000-0xfffffe0000200000           2M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0000200000-0xfffffe0001200000          16M     ro x  SHD AF    CON     UXN MEM/NORMAL
0xfffffe0001200000-0xfffffe0001400000           2M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0001400000-0xfffffe0001600000           2M     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe0001600000-0xfffffe0002600000          16M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0002600000-0xfffffe0002800000           2M     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe0002800000-0xfffffe0020000000         472M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0020000000-0xfffffe0060000000           1G     RW NX SHD AF        BLK UXN MEM/NORMAL
0xfffffe00600f0000-0xfffffe0060200000        1088K     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe0060200000-0xfffffe0076400000         354M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0076400000-0xfffffe0076600000           2M     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe0076600000-0xfffffe0078e00000          40M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe00793b0000-0xfffffe0079400000         320K     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe0079400000-0xfffffe007e200000          78M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe007e200000-0xfffffe007e3d0000        1856K     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe007e420000-0xfffffe007e600000        1920K     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe007e600000-0xfffffe007f000000          10M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0800000000-0xfffffe0980000000           6G     RW NX SHD AF        BLK UXN MEM/NORMAL

With 4k pages
---[ Kernel Mapping ]---
0xffffffc000000000-0xffffffc000200000           2M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc000200000-0xffffffc001200000          16M     ro x  SHD AF        BLK UXN MEM/NORMAL
0xffffffc001200000-0xffffffc001400000           2M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc001400000-0xffffffc0015c0000        1792K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc0015c0000-0xffffffc0015d0000          64K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc0015d0000-0xffffffc001600000         192K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc001600000-0xffffffc002600000          16M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc002600000-0xffffffc002620000         128K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc002620000-0xffffffc002630000          64K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc002630000-0xffffffc002800000        1856K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc002800000-0xffffffc060000000        1496M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc0600f0000-0xffffffc060200000        1088K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc060200000-0xffffffc076400000         354M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc076400000-0xffffffc076590000        1600K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc076590000-0xffffffc076595000          20K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc076596000-0xffffffc0765a0000          40K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc0765a0000-0xffffffc076600000         384K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc076600000-0xffffffc078e00000          40M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc0793b0000-0xffffffc079400000         320K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc079400000-0xffffffc07e200000          78M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc07e200000-0xffffffc07e3d0000        1856K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc07e420000-0xffffffc07e600000        1920K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc07e600000-0xffffffc07f000000          10M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc800000000-0xffffffc980000000           6G     RW NX SHD AF        BLK UXN MEM/NORMAL

Jeremy Linton (2):
  arm64: mm: Enable CONT_SIZE aligned sections for 64k page kernels.
  arm64: Mark kernel page ranges contiguous

 arch/arm64/Kconfig.debug        | 12 ++++----
 arch/arm64/kernel/vmlinux.lds.S | 11 +++----
 arch/arm64/mm/mmu.c             | 64 +++++++++++++++++++++++++++++++++++++----
 3 files changed, 70 insertions(+), 17 deletions(-)

-- 
2.4.3



From jeremy.linton at arm.com  Wed Feb 17 08:29:53 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Wed, 17 Feb 2016 10:29:53 -0600
Subject: [PATCH v2 1/2] arm64: mm: Enable CONT_SIZE aligned sections for 64k
 page kernels.
In-Reply-To: <1455726594-16104-1-git-send-email-jeremy.linton@arm.com>
References: <1455726594-16104-1-git-send-email-jeremy.linton@arm.com>
Message-ID: <1455726594-16104-2-git-send-email-jeremy.linton@arm.com>

This change allows ALIGN_RODATA for 16k and 64k kernels.
In the case of 64k kernels it actually aligns to the CONT_SIZE
rather than the SECTION_SIZE (which is 512M). This makes it generally
more useful, especially for CONT enabled kernels.

Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
---
 arch/arm64/Kconfig.debug        | 12 ++++++------
 arch/arm64/kernel/vmlinux.lds.S | 11 ++++++-----
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
index e13c4bf..65705ee 100644
--- a/arch/arm64/Kconfig.debug
+++ b/arch/arm64/Kconfig.debug
@@ -59,15 +59,15 @@ config DEBUG_RODATA
           If in doubt, say Y
 
 config DEBUG_ALIGN_RODATA
-	depends on DEBUG_RODATA && ARM64_4K_PAGES
+	depends on DEBUG_RODATA
 	bool "Align linker sections up to SECTION_SIZE"
 	help
 	  If this option is enabled, sections that may potentially be marked as
-	  read only or non-executable will be aligned up to the section size of
-	  the kernel. This prevents sections from being split into pages and
-	  avoids a potential TLB penalty. The downside is an increase in
-	  alignment and potentially wasted space. Turn on this option if
-	  performance is more important than memory pressure.
+	  read only or non-executable will be aligned up to the section size
+	  or contiguous hint size of the kernel. This prevents sections from
+	  being split into pages and avoids a potential TLB penalty. The downside
+	  is an increase in alignment and potentially wasted space. Turn on
+	  this option if performance is more important than memory pressure.
 
 	  If in doubt, say N
 
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index b78a3c7..8f4fc2c 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -63,13 +63,14 @@ PECOFF_FILE_ALIGNMENT = 0x200;
 #endif
 
 #if defined(CONFIG_DEBUG_ALIGN_RODATA)
-#define ALIGN_DEBUG_RO			. = ALIGN(1<<SECTION_SHIFT);
-#define ALIGN_DEBUG_RO_MIN(min)		ALIGN_DEBUG_RO
+#if defined(CONFIG_ARM64_4K_PAGES)
+#define ALIGN_DEBUG_RO_MIN(min)		. = ALIGN(SECTION_SIZE);
+#else
+#define ALIGN_DEBUG_RO_MIN(min)		. = ALIGN(CONT_SIZE);
+#endif
 #elif defined(CONFIG_DEBUG_RODATA)
-#define ALIGN_DEBUG_RO			. = ALIGN(1<<PAGE_SHIFT);
-#define ALIGN_DEBUG_RO_MIN(min)		ALIGN_DEBUG_RO
+#define ALIGN_DEBUG_RO_MIN(min)		. = ALIGN(PAGE_SIZE);
 #else
-#define ALIGN_DEBUG_RO
 #define ALIGN_DEBUG_RO_MIN(min)		. = ALIGN(min);
 #endif
 
-- 
2.4.3



From jeremy.linton at arm.com  Wed Feb 17 08:29:54 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Wed, 17 Feb 2016 10:29:54 -0600
Subject: [PATCH v2 2/2] arm64: Mark kernel page ranges contiguous
In-Reply-To: <1455726594-16104-1-git-send-email-jeremy.linton@arm.com>
References: <1455726594-16104-1-git-send-email-jeremy.linton@arm.com>
Message-ID: <1455726594-16104-3-git-send-email-jeremy.linton@arm.com>

With 64k pages, the next larger segment size is 512M. The linux
kernel also uses different protection flags to cover its code and data.
Because of this requirement, the vast majority of the kernel code and
data structures end up being mapped with 64k pages instead of the larger
pages common with a 4k page kernel.

Recent ARM processors support a contiguous bit in the
page tables which allows the a TLB to cover a range larger than a
single PTE if that range is mapped into physically contiguous
ram.

So, for the kernel its a good idea to set this flag. Some basic
micro benchmarks show it can significantly reduce the number of
L1 dTLB refills.

Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
---
 arch/arm64/mm/mmu.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 58 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 7711554..ab69a99 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1,3 +1,4 @@
+
 /*
  * Based on arch/arm/mm/mmu.c
  *
@@ -103,17 +104,49 @@ static void split_pmd(pmd_t *pmd, pte_t *pte)
 		 * Need to have the least restrictive permissions available
 		 * permissions will be fixed up later
 		 */
-		set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC));
+		set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC_CONT));
 		pfn++;
 	} while (pte++, i++, i < PTRS_PER_PTE);
 }
 
+static void clear_cont_pte_range(pte_t *pte, unsigned long addr)
+{
+	int i;
+
+	pte -= CONT_RANGE_OFFSET(addr);
+	for (i = 0; i < CONT_PTES; i++) {
+		if (pte_cont(*pte))
+			set_pte(pte, pte_mknoncont(*pte));
+		pte++;
+	}
+	flush_tlb_all();
+}
+
+/*
+ * Given a range of PTEs set the pfn and provided page protection flags
+ */
+static void __populate_init_pte(pte_t *pte, unsigned long addr,
+			       unsigned long end, phys_addr_t phys,
+			       pgprot_t prot)
+{
+	unsigned long pfn = __phys_to_pfn(phys);
+
+	do {
+		/* clear all the bits except the pfn, then apply the prot */
+		set_pte(pte, pfn_pte(pfn, prot));
+		pte++;
+		pfn++;
+		addr += PAGE_SIZE;
+	} while (addr != end);
+}
+
 static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
-				  unsigned long end, unsigned long pfn,
+				  unsigned long end, phys_addr_t phys,
 				  pgprot_t prot,
 				  phys_addr_t (*pgtable_alloc)(void))
 {
 	pte_t *pte;
+	unsigned long next;
 
 	if (pmd_none(*pmd) || pmd_sect(*pmd)) {
 		phys_addr_t pte_phys = pgtable_alloc();
@@ -127,10 +160,29 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
 	BUG_ON(pmd_bad(*pmd));
 
 	pte = pte_set_fixmap_offset(pmd, addr);
+
 	do {
-		set_pte(pte, pfn_pte(pfn, prot));
-		pfn++;
-	} while (pte++, addr += PAGE_SIZE, addr != end);
+		next = min(end, (addr + CONT_SIZE) & CONT_MASK);
+		if (((addr | next | phys) & ~CONT_MASK) == 0) {
+			/* a block of CONT_PTES	 */
+			__populate_init_pte(pte, addr, next, phys,
+					    prot | __pgprot(PTE_CONT));
+		} else {
+			/*
+			 * If the range being split is already inside of a
+			 * contiguous range but this PTE isn't going to be
+			 * contiguous, then we want to unmark the adjacent
+			 * ranges, then update the portion of the range we
+			 * are interrested in.
+			 */
+			clear_cont_pte_range(pte, addr);
+			__populate_init_pte(pte, addr, next, phys, prot);
+		}
+
+		pte += (next - addr) >> PAGE_SHIFT;
+		phys += next - addr;
+		addr = next;
+	} while (addr != end);
 
 	pte_clear_fixmap();
 }
@@ -194,7 +246,7 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
 				}
 			}
 		} else {
-			alloc_init_pte(pmd, addr, next, __phys_to_pfn(phys),
+			alloc_init_pte(pmd, addr, next, phys,
 				       prot, pgtable_alloc);
 		}
 		phys += next - addr;
-- 
2.4.3



From aryabinin at virtuozzo.com  Wed Feb 17 08:31:43 2016
From: aryabinin at virtuozzo.com (Andrey Ryabinin)
Date: Wed, 17 Feb 2016 19:31:43 +0300
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <20160217143950.GC32647@leverpostej>
References: <20160212145844.GI31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
Message-ID: <56C4A06F.3040702@virtuozzo.com>



On 02/17/2016 05:39 PM, Mark Rutland wrote:
> On Tue, Feb 16, 2016 at 03:59:09PM +0300, Andrey Ryabinin wrote:
>> Actually, the first report is a bit more useful. It shows that shadow memory was corrupted:
>>
>>   ffffffc93665bc00: f1 f1 f1 f1 00 f4 f4 f4 f2 f2 f2 f2 00 00 f1 f1
>>> ffffffc93665bc80: f1 f1 00 00 00 00 f3 f3 00 f4 f4 f4 f3 f3 f3 f3
>>                       ^
>> F1 - left redzone, it indicates start of stack frame
>> F3 - right redzone, it should be the end of stack frame.
>>
>> But here we have the second set of F1s without F3s which should close the first set of F1s.
>> Also those two F3s in the middle cannot be right.
>>
>> So shadow is corrupted.
>> Some hypotheses:
> 
>> 2) Shadow memory wasn't cleared. GCC poison memory on function entrance and unpoisons it before return.
>>      If we use some tricky way to exit from function this could cause false-positives like that.
>>      E.g. some hand-written assembly return code.
> 
> I think this is what's happenening, at least for the idle case.
> 
> A second attempt at bisecting led me to commit e679660dbb8347f2 ("ARM:
> 8481/2: drivers: psci: replace psci firmware calls"). Reverting that
> makes v4.5-rc1 boot without KASAN splats.
> 
> That patch turned __invoke_psci_fn_{smc,hvc} into (ASAN-instrumented) C
> functions. Prior to that commit, __invoke_psci_fn_{smc,hvc} were
> pure assembly functions which used no stack.
> 
> When we go down for idle, in __cpu_suspend_enter we stash some context
> to the stack (in assembly). The CPU may return from a cold state via
> cpu_resume, where we restore context from the stack.
> 
> However, after storing the context we call psci_suspend_finisher, which
> calls psci_cpu_suspend, which calls invoke_psci_fn_*. As
> psci_cpu_suspend and invoke_psci_fn_* are instrumented, they poison
> memory on function entrance, but we never perform the unpoisoning.
> 
> That was always the case for psci_suspend_finisher, so there was a
> latent issue that we were somehow avoiding. Perhaps we got luck with
> stack layout and never hit the poison.
> 
> I'm not sure how we fix that, as invoke_psci_fn_* may or may not return
> for arbitrary reasons (e.g. a CPU_SUSPEND_CALL may or may not return
> depending on whether an interrupt comes in at the right time).
> 
> Perhaps the simplest option is to not instrument invoke_psci_fn_* and
> psci_suspend_finisher. Do we have a per-function annotation to avoid
> KASAN instrumentation, like notrace? I need to investigate, but we may
> also need notrace for similar reasons.

include/linux/compiler-gcc.h:
/*
* Tell the compiler that address safety instrumentation (KASAN)
* should not be applied to that function.
* Conflicts with inlining: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
*/
#define __no_sanitize_address __attribute__((no_sanitize_address))

> 
> Andrey, on a tangential note, what do we do around hotplug? I assume
> that we must unpooison the shadow region for the stack of a dead CPU,
> but I wasn't able to figure out where we do that. Hopefuly we're not
> just getting lucky?
> 

We do nothing about it. AFAIU we need to clear swapper's stack, somewhere in secondary_start_kernel() perhaps.



> Thanks,
> Mark.
> 


From marc.zyngier at arm.com  Wed Feb 17 08:40:34 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:34 +0000
Subject: [PATCH v2 02/17] ARM: KVM: Properly sort the invariant table
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-3-git-send-email-marc.zyngier@arm.com>

Not having the invariant table properly sorted is an oddity, and
may get in the way of future optimisations. Let's fix it.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/coproc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index f3d88dc..16c74f8 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -645,6 +645,9 @@ static struct coproc_reg invariant_cp15[] = {
 	{ CRn( 0), CRm( 0), Op1( 0), Op2( 3), is32, NULL, get_TLBTR },
 	{ CRn( 0), CRm( 0), Op1( 0), Op2( 6), is32, NULL, get_REVIDR },
 
+	{ CRn( 0), CRm( 0), Op1( 1), Op2( 1), is32, NULL, get_CLIDR },
+	{ CRn( 0), CRm( 0), Op1( 1), Op2( 7), is32, NULL, get_AIDR },
+
 	{ CRn( 0), CRm( 1), Op1( 0), Op2( 0), is32, NULL, get_ID_PFR0 },
 	{ CRn( 0), CRm( 1), Op1( 0), Op2( 1), is32, NULL, get_ID_PFR1 },
 	{ CRn( 0), CRm( 1), Op1( 0), Op2( 2), is32, NULL, get_ID_DFR0 },
@@ -660,9 +663,6 @@ static struct coproc_reg invariant_cp15[] = {
 	{ CRn( 0), CRm( 2), Op1( 0), Op2( 3), is32, NULL, get_ID_ISAR3 },
 	{ CRn( 0), CRm( 2), Op1( 0), Op2( 4), is32, NULL, get_ID_ISAR4 },
 	{ CRn( 0), CRm( 2), Op1( 0), Op2( 5), is32, NULL, get_ID_ISAR5 },
-
-	{ CRn( 0), CRm( 0), Op1( 1), Op2( 1), is32, NULL, get_CLIDR },
-	{ CRn( 0), CRm( 0), Op1( 1), Op2( 7), is32, NULL, get_AIDR },
 };
 
 /*
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 08:40:33 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:33 +0000
Subject: [PATCH v2 01/17] arm64: KVM: Switch the sys_reg search to be a binary
 search
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-2-git-send-email-marc.zyngier@arm.com>

Our 64bit sys_reg table is about 90 entries long (so far, and the
PMU support is likely to increase this). This means that on average,
it takes 45 comparaisons to find the right entry (and actually the
full 90 if we have to search the invariant table).

Not the most efficient thing. Specially when you think that this
table is already sorted. Switching to a binary search effectively
reduces the search to about 7 comparaisons. Slightly better!

As an added bonus, the comparison is done by comparing all the
fields at once, instead of one at a time.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/sys_regs.c | 40 ++++++++++++++++++++++------------------
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 2e90371..86dfb08 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -20,6 +20,7 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/bsearch.h>
 #include <linux/kvm_host.h>
 #include <linux/mm.h>
 #include <linux/uaccess.h>
@@ -942,29 +943,32 @@ static const struct sys_reg_desc *get_target_table(unsigned target,
 	}
 }
 
+#define reg_to_match_value(x)						\
+	({								\
+		unsigned long val;					\
+		val  = (x)->Op0 << 14;					\
+		val |= (x)->Op1 << 11;					\
+		val |= (x)->CRn << 7;					\
+		val |= (x)->CRm << 3;					\
+		val |= (x)->Op2;					\
+		val;							\
+	 })
+
+static int match_sys_reg(const void *key, const void *elt)
+{
+	const unsigned long pval = (unsigned long)key;
+	const struct sys_reg_desc *r = elt;
+
+	return pval - reg_to_match_value(r);
+}
+
 static const struct sys_reg_desc *find_reg(const struct sys_reg_params *params,
 					 const struct sys_reg_desc table[],
 					 unsigned int num)
 {
-	unsigned int i;
-
-	for (i = 0; i < num; i++) {
-		const struct sys_reg_desc *r = &table[i];
+	unsigned long pval = reg_to_match_value(params);
 
-		if (params->Op0 != r->Op0)
-			continue;
-		if (params->Op1 != r->Op1)
-			continue;
-		if (params->CRn != r->CRn)
-			continue;
-		if (params->CRm != r->CRm)
-			continue;
-		if (params->Op2 != r->Op2)
-			continue;
-
-		return r;
-	}
-	return NULL;
+	return bsearch((void *)pval, table, num, sizeof(table[0]), match_sys_reg);
 }
 
 int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run)
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 08:40:32 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:32 +0000
Subject: [PATCH v2 00/17] KVM/ARM: Guest Entry/Exit optimizations
Message-ID: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>

I've recently been looking at our entry/exit costs, and profiling
figures did show some very low hanging fruits.

The most obvious cost is that accessing the GIC HW is slow. As in
"deadly slow", specially when GICv2 is involved. So not hammering the
HW when there is nothing to write (and even to read) is immediately
beneficial, as this is the most common cases (whatever people seem to
think, interrupts are a *rare* event). Similar work has also been done
for GICv3, with a reduced impact (it was less "bad" to start with).

Another easy thing to fix is the way we handle trapped system
registers. We do insist on (mostly) sorting them, but we do perform a
linear search on trap. We can switch to a binary search for free, and
get immediate benefits (the PMU code, being extremely trap-happy,
benefits immediately from this).

With these in place, I see an improvement of 10 to 40% (depending on
the platform) on our world-switch cycle count when running a set of
hand-crafted guests that are designed to only perform traps.

Please note that VM exits are actually a rare event on ARM. So don't
expect your guest to be 40% faster, this will hardly make a noticable
difference.

Methodology:

* NULL-hypercall guest: Perform 2^20 PSCI_0_2_FN_PSCI_VERSION calls,
and then a power-off:

__start:
	mov	x19, #(1 << 16)
1:	mov	x0, #0x84000000
	hvc	#0
	sub	x19, x19, #1
	cbnz	x19, 1b
	mov	x0, #0x84000000
	add	x0, x0, #9
	hvc	#0
	b	.

* Self IPI guest: Inject and handle 2^20 SGI0 using GICv2 or GICv3,
and then power-off:

__start:
	mov	x19, #(1 << 20)

	mrs	x0, id_aa64pfr0_el1
	ubfx	x0, x0, #24, #4
	and	x0, x0, #0xf
	cbz	x0, do_v2

	mrs	x0, s3_0_c12_c12_5	// ICC_SRE_EL1
	and	x0, x0, #1		// SRE bit
	cbnz	x0, do_v3

do_v2:
	mov	x0, #0x3fff0000		// Dist
	mov	x1, #0x3ffd0000		// CPU
	mov	w2, #1
	str	w2, [x0]		// Enable Group0
	ldr	w2, =0xa0a0a0a0
	str	w2, [x0, 0x400]		// A0 priority for SGI0-3
	mov	w2, #0x0f
	str	w2, [x0, #0x100]	// Enable SGI0-3
	mov	w2, #0xf0
	str	w2, [x1, #4]		// PMR
	mov	w2, #1
	str	w2, [x1]		// Enable CPU interface
	
1:
	mov	w2, #(2 << 24)		// Interrupt self with SGI0
	str	w2, [x0, #0xf00]

2:	ldr	w2, [x1, #0x0c]		// GICC_IAR
	cmp	w2, #0x3ff
	b.ne	3f

	wfi
	b	2b

3:	str	w2, [x1, #0x10]		// EOI

	sub	x19, x19, #1
	cbnz	x19, 1b

die:
	mov	x0, #0x84000000
	add	x0, x0, #9
	hvc	#0
	b	.

do_v3:
	mov	x0, #0x3fff0000		// Dist
	mov	x1, #0x3fbf0000		// Redist 0
	mov	x2, #0x10000
	add	x1, x1, x2		// SGI page
	mov	w2, #2
	str	w2, [x0]		// Enable Group1
	ldr	w2, =0xa0a0a0a0
	str	w2, [x1, 0x400]		// A0 priority for SGI0-3
	mov	w2, #0x0f
	str	w2, [x1, #0x100]	// Enable SGI0-3
	mov	w2, #0xf0
	msr	S3_0_c4_c6_0, x2	// PMR
	mov	w2, #1
	msr	S3_0_C12_C12_7, x2	// Enable Group1

1:
	mov	x2, #1
	msr	S3_0_c12_c11_5, x2	// Self SGI0

2:	mrs	x2, S3_0_c12_c12_0	// Read IAR1
	cmp	w2, #0x3ff
	b.ne	3f

	wfi
	b	2b

3:	msr	S3_0_c12_c12_1, x2	// EOI

	sub	x19, x19, #1
	cbnz	x19, 1b

	b	die

* sysreg trap guest: Perform 2^20 PMSELR_EL0 accesses, and power-off:

__start:
	mov	x19, #(1 << 20)
1:	mrs	x0, PMSELR_EL0
	sub	x19, x19, #1
	cbnz	x19, 1b
	mov	x0, #0x84000000
	add	x0, x0, #9
	hvc	#0
	b	.

* These guests are profiled using perf and kvmtool:

taskset -c 1 perf stat -e cycles:kh lkvm run -c1 --kernel do_sysreg.bin 2>&1 >/dev/null| grep cycles

The result is then divided by the number of iterations (2^20).

These tests have been run on three different platform (two GICv2
based, and one with GICv3 and legacy mode) and shown significant
improvements in all cases. I've only touched the arm64 GIC code, but
obviously the 32bit code should use it as well once we've migrated it
to C.

Vanilla v4.5-rc4
	     A             B            C-v2         C-v3
Null HVC:   8462          6566          6572         6505
Self SGI:  11961          8690          9541         8629
SysReg:     8952          6979          7212         7180

Patched v4.5-rc4
	     A             B            C-v2         C-v3
Null HVC:   5219  -38%    3957  -39%    5175  -21%   5158  -20%
Self SGI:   8946  -25%    6658  -23%    8547  -10%   7299  -15%
SysReg:     5314  -40%    4190  -40%    5417  -25%   5414  -24%

I've pushed out a branch (kvm-arm64/suck-less) to the usual location,
based on -rc4 + a few fixes I also posted today.

Thanks,

	M.

* From v1:
  - Fixed a nasty bug dealing with the active Priority Register
  - Maintenance interrupt lazy saving
  - More LR hackery
  - Adapted most of the series for GICv3 as well

Marc Zyngier (17):
  arm64: KVM: Switch the sys_reg search to be a binary search
  ARM: KVM: Properly sort the invariant table
  ARM: KVM: Enforce sorting of all CP tables
  ARM: KVM: Rename struct coproc_reg::is_64 to is_64bit
  ARM: KVM: Switch the CP reg search to be a binary search
  KVM: arm/arm64: timer: Add active state caching
  arm64: KVM: vgic-v2: Avoid accessing GICH registers
  arm64: KVM: vgic-v2: Save maintenance interrupt state only if required
  arm64: KVM: vgic-v2: Move GICH_ELRSR saving to its own function
  arm64: KVM: vgic-v2: Do not save an LR known to be empty
  arm64: KVM: vgic-v2: Only wipe LRs on vcpu exit
  arm64: KVM: vgic-v2: Make GICD_SGIR quicker to hit
  arm64: KVM: vgic-v3: Avoid accessing ICH registers
  arm64: KVM: vgic-v3: Save maintenance interrupt state only if required
  arm64: KVM: vgic-v3: Do not save an LR known to be empty
  arm64: KVM: vgic-v3: Only wipe LRs on vcpu exit
  arm64: KVM: vgic-v3: Do not save ICH_AP0Rn_EL2 for GICv2 emulation

 arch/arm/kvm/arm.c              |   1 +
 arch/arm/kvm/coproc.c           |  74 +++++----
 arch/arm/kvm/coproc.h           |   8 +-
 arch/arm64/kvm/hyp/vgic-v2-sr.c | 144 +++++++++++++----
 arch/arm64/kvm/hyp/vgic-v3-sr.c | 333 ++++++++++++++++++++++++++--------------
 arch/arm64/kvm/sys_regs.c       |  40 ++---
 include/kvm/arm_arch_timer.h    |   5 +
 include/kvm/arm_vgic.h          |   8 +-
 virt/kvm/arm/arch_timer.c       |  31 ++++
 virt/kvm/arm/vgic-v2-emul.c     |  10 +-
 virt/kvm/arm/vgic-v3.c          |   4 +-
 11 files changed, 452 insertions(+), 206 deletions(-)

-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 08:40:48 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:48 +0000
Subject: [PATCH v2 16/17] arm64: KVM: vgic-v3: Only wipe LRs on vcpu exit
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-17-git-send-email-marc.zyngier@arm.com>

So far, we're always writing all possible LRs, setting the empty
ones with a zero value. This is obvious doing a low of work for
nothing, and we're better off clearing those we've actually
dirtied on the exit path (it is very rare to inject more than one
interrupt at a time anyway).

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/vgic-v3-sr.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
index ff67296..5f12c57 100644
--- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
@@ -199,6 +199,7 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
 			}
 
 			cpu_if->vgic_lr[i] = __gic_v3_get_lr(i);
+			__gic_v3_set_lr(0, i);
 		}
 
 		switch (nr_pri_bits) {
@@ -296,12 +297,10 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
 		}
 		 	                           
 		for (i = 0; i <= max_lr_idx; i++) {
-			val = 0;
-
-			if (live_lrs & (1 << i))
-				val = cpu_if->vgic_lr[i];
+			if (!(live_lrs & (1 << i)))
+				continue;
 
-			__gic_v3_set_lr(val, i);
+			__gic_v3_set_lr(cpu_if->vgic_lr[i], i);
 		}
 	}
 
-- 
2.1.4



From jeremy.linton at arm.com  Wed Feb 17 08:41:13 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Wed, 17 Feb 2016 10:41:13 -0600
Subject: [PATCH v2 1/2] arm64: mm: Mark .rodata as RO
In-Reply-To: <1455727274-16328-1-git-send-email-jeremy.linton@arm.com>
References: <1455727274-16328-1-git-send-email-jeremy.linton@arm.com>
Message-ID: <1455727274-16328-2-git-send-email-jeremy.linton@arm.com>

Currently the .rodata section is actually still executable when DEBUG_RODATA
is enabled. This changes that so the .rodata is actually read only, no execute.

Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
---
 arch/arm64/kernel/vmlinux.lds.S |  5 +++--
 arch/arm64/mm/mmu.c             | 17 +++++++++++++----
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 8f4fc2c..9208f53 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -114,8 +114,9 @@ SECTIONS
 		*(.got)			/* Global offset table		*/
 	}
 
-	RO_DATA(PAGE_SIZE)
-	EXCEPTION_TABLE(8)
+	ALIGN_DEBUG_RO_MIN(0)
+	RO_DATA(PAGE_SIZE)		/* everything from this point to */
+	EXCEPTION_TABLE(8)		/* _etext will be marked RO NX   */
 	NOTES
 
 	ALIGN_DEBUG_RO_MIN(PAGE_SIZE)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index ab69a99..9aa5201 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -453,10 +453,18 @@ static void __init map_mem(pgd_t *pgd)
 #ifdef CONFIG_DEBUG_RODATA
 void mark_rodata_ro(void)
 {
-	create_mapping_late(__pa(_stext), (unsigned long)_stext,
-				(unsigned long)_etext - (unsigned long)_stext,
-				PAGE_KERNEL_ROX);
+	unsigned long section_size;
 
+	section_size = (unsigned long)__start_rodata - (unsigned long)_stext;
+	create_mapping_late(__pa(_stext), (unsigned long)_stext,
+			    section_size, PAGE_KERNEL_ROX);
+	/*
+	 * mark .rodata as read only. Use _etext rather than __end_rodata to
+	 * cover NOTES and EXCEPTION_TABLE.
+	 */
+	section_size = (unsigned long)_etext - (unsigned long)__start_rodata;
+	create_mapping_late(__pa(__start_rodata), (unsigned long)__start_rodata,
+			    section_size, PAGE_KERNEL_RO);
 }
 #endif
 
@@ -486,7 +494,8 @@ static void __init map_kernel_chunk(pgd_t *pgd, void *va_start, void *va_end,
 static void __init map_kernel(pgd_t *pgd)
 {
 
-	map_kernel_chunk(pgd, _stext, _etext, PAGE_KERNEL_EXEC);
+	map_kernel_chunk(pgd, _stext, __start_rodata, PAGE_KERNEL_EXEC);
+	map_kernel_chunk(pgd, __start_rodata, _etext, PAGE_KERNEL_EXEC);
 	map_kernel_chunk(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC);
 	map_kernel_chunk(pgd, _data, _end, PAGE_KERNEL);
 
-- 
2.4.3



From marc.zyngier at arm.com  Wed Feb 17 08:40:35 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:35 +0000
Subject: [PATCH v2 03/17] ARM: KVM: Enforce sorting of all CP tables
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-4-git-send-email-marc.zyngier@arm.com>

Since we're obviously terrible at sorting the CP tables, make sure
we're going to do it properly (or fail to boot). arm64 has had the
same mechanism for a while, and nobody ever broke it...

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/coproc.c | 25 +++++++++++++++++--------
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index 16c74f8..03f5d14 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -381,17 +381,26 @@ static const struct coproc_reg cp15_regs[] = {
 	{ CRn(15), CRm( 0), Op1( 4), Op2( 0), is32, access_cbar},
 };
 
+static int check_reg_table(const struct coproc_reg *table, unsigned int n)
+{
+	unsigned int i;
+
+	for (i = 1; i < n; i++) {
+		if (cmp_reg(&table[i-1], &table[i]) >= 0) {
+			kvm_err("reg table %p out of order (%d)\n", table, i - 1);
+			return 1;
+		}
+	}
+
+	return 0;
+}
+
 /* Target specific emulation tables */
 static struct kvm_coproc_target_table *target_tables[KVM_ARM_NUM_TARGETS];
 
 void kvm_register_target_coproc_table(struct kvm_coproc_target_table *table)
 {
-	unsigned int i;
-
-	for (i = 1; i < table->num; i++)
-		BUG_ON(cmp_reg(&table->table[i-1],
-			       &table->table[i]) >= 0);
-
+	BUG_ON(check_reg_table(table->table, table->num));
 	target_tables[table->target] = table;
 }
 
@@ -1210,8 +1219,8 @@ void kvm_coproc_table_init(void)
 	unsigned int i;
 
 	/* Make sure tables are unique and in order. */
-	for (i = 1; i < ARRAY_SIZE(cp15_regs); i++)
-		BUG_ON(cmp_reg(&cp15_regs[i-1], &cp15_regs[i]) >= 0);
+	BUG_ON(check_reg_table(cp15_regs, ARRAY_SIZE(cp15_regs)));
+	BUG_ON(check_reg_table(invariant_cp15, ARRAY_SIZE(invariant_cp15)));
 
 	/* We abuse the reset function to overwrite the table itself. */
 	for (i = 0; i < ARRAY_SIZE(invariant_cp15); i++)
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 08:40:37 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:37 +0000
Subject: [PATCH v2 05/17] ARM: KVM: Switch the CP reg search to be a binary
 search
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-6-git-send-email-marc.zyngier@arm.com>

Doing a linear search is a bit silly when we can do a binary search.
Not that we trap that so many things that it has become a burden yet,
but it makes sense to align it with the arm64 code.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/coproc.c | 41 +++++++++++++++++++++++------------------
 1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index 2a67f00..4f1c869 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -16,6 +16,8 @@
  * along with this program; if not, write to the Free Software
  * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
  */
+
+#include <linux/bsearch.h>
 #include <linux/mm.h>
 #include <linux/kvm_host.h>
 #include <linux/uaccess.h>
@@ -414,29 +416,32 @@ static const struct coproc_reg *get_target_table(unsigned target, size_t *num)
 	return table->table;
 }
 
+#define reg_to_match_value(x)						\
+	({								\
+		unsigned long val;					\
+		val  = (x)->CRn << 11;					\
+		val |= (x)->CRm << 7;					\
+		val |= (x)->Op1 << 4;					\
+		val |= (x)->Op2 << 1;					\
+		val |= !(x)->is_64bit;					\
+		val;							\
+	 })
+
+static int match_reg(const void *key, const void *elt)
+{
+	const unsigned long pval = (unsigned long)key;
+	const struct coproc_reg *r = elt;
+
+	return pval - reg_to_match_value(r);
+}
+
 static const struct coproc_reg *find_reg(const struct coproc_params *params,
 					 const struct coproc_reg table[],
 					 unsigned int num)
 {
-	unsigned int i;
-
-	for (i = 0; i < num; i++) {
-		const struct coproc_reg *r = &table[i];
+	unsigned long pval = reg_to_match_value(params);
 
-		if (params->is_64bit != r->is_64bit)
-			continue;
-		if (params->CRn != r->CRn)
-			continue;
-		if (params->CRm != r->CRm)
-			continue;
-		if (params->Op1 != r->Op1)
-			continue;
-		if (params->Op2 != r->Op2)
-			continue;
-
-		return r;
-	}
-	return NULL;
+	return bsearch((void *)pval, table, num, sizeof(table[0]), match_reg);
 }
 
 static int emulate_cp15(struct kvm_vcpu *vcpu,
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 08:40:36 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:36 +0000
Subject: [PATCH v2 04/17] ARM: KVM: Rename struct coproc_reg::is_64 to is_64bit
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-5-git-send-email-marc.zyngier@arm.com>

As we're going to play some tricks on the struct coproc_reg,
make sure its 64bit indicator field matches that of coproc_params.

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/coproc.c | 4 ++--
 arch/arm/kvm/coproc.h | 8 ++++----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
index 03f5d14..2a67f00 100644
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -423,7 +423,7 @@ static const struct coproc_reg *find_reg(const struct coproc_params *params,
 	for (i = 0; i < num; i++) {
 		const struct coproc_reg *r = &table[i];
 
-		if (params->is_64bit != r->is_64)
+		if (params->is_64bit != r->is_64bit)
 			continue;
 		if (params->CRn != r->CRn)
 			continue;
@@ -1105,7 +1105,7 @@ static int write_demux_regids(u64 __user *uindices)
 static u64 cp15_to_index(const struct coproc_reg *reg)
 {
 	u64 val = KVM_REG_ARM | (15 << KVM_REG_ARM_COPROC_SHIFT);
-	if (reg->is_64) {
+	if (reg->is_64bit) {
 		val |= KVM_REG_SIZE_U64;
 		val |= (reg->Op1 << KVM_REG_ARM_OPC1_SHIFT);
 		/*
diff --git a/arch/arm/kvm/coproc.h b/arch/arm/kvm/coproc.h
index 88d24a3..5acd097 100644
--- a/arch/arm/kvm/coproc.h
+++ b/arch/arm/kvm/coproc.h
@@ -37,7 +37,7 @@ struct coproc_reg {
 	unsigned long Op1;
 	unsigned long Op2;
 
-	bool is_64;
+	bool is_64bit;
 
 	/* Trapped access from guest, if non-NULL. */
 	bool (*access)(struct kvm_vcpu *,
@@ -141,7 +141,7 @@ static inline int cmp_reg(const struct coproc_reg *i1,
 		return i1->Op1 - i2->Op1;
 	if (i1->Op2 != i2->Op2)
 		return i1->Op2 - i2->Op2;
-	return i2->is_64 - i1->is_64;
+	return i2->is_64bit - i1->is_64bit;
 }
 
 
@@ -150,8 +150,8 @@ static inline int cmp_reg(const struct coproc_reg *i1,
 #define CRm64(_x)       .CRn = _x, .CRm = 0
 #define Op1(_x) 	.Op1 = _x
 #define Op2(_x) 	.Op2 = _x
-#define is64		.is_64 = true
-#define is32		.is_64 = false
+#define is64		.is_64bit = true
+#define is32		.is_64bit = false
 
 bool access_vm_reg(struct kvm_vcpu *vcpu,
 		   const struct coproc_params *p,
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 08:40:47 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:47 +0000
Subject: [PATCH v2 15/17] arm64: KVM: vgic-v3: Do not save an LR known to be
 empty
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-16-git-send-email-marc.zyngier@arm.com>

On exit, any empty LR will be signaled in ICH_ELRSR_EL2. Which
means that we do not have to save it, and we can just clear
its state in the in-memory copy.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/vgic-v3-sr.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
index 3463c0a..ff67296 100644
--- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
@@ -190,8 +190,15 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
 		save_maint_int_state(vcpu, max_lr_idx + 1);
 
 		for (i = 0; i <= max_lr_idx; i++) {
-			if (vcpu->arch.vgic_cpu.live_lrs & (1UL << i))
-				cpu_if->vgic_lr[i] = __gic_v3_get_lr(i);
+			if (!(vcpu->arch.vgic_cpu.live_lrs & (1UL << i)))
+				continue;
+
+			if (cpu_if->vgic_elrsr & (1 << i)) {
+				cpu_if->vgic_lr[i] &= ~ICH_LR_STATE;
+				continue;
+			}
+
+			cpu_if->vgic_lr[i] = __gic_v3_get_lr(i);
 		}
 
 		switch (nr_pri_bits) {
-- 
2.1.4



From jeremy.linton at arm.com  Wed Feb 17 08:41:14 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Wed, 17 Feb 2016 10:41:14 -0600
Subject: [PATCH v2 2/2] arm64/mm: Add .rodata to kernel virtual memory boot
 notice
In-Reply-To: <1455727274-16328-1-git-send-email-jeremy.linton@arm.com>
References: <1455727274-16328-1-git-send-email-jeremy.linton@arm.com>
Message-ID: <1455727274-16328-3-git-send-email-jeremy.linton@arm.com>

Now that .rodata has differing permissions from .text
display it in the mem_init banner as a seperate memory range.

Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
---
 arch/arm64/mm/init.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5dd0831..41be7db 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -325,6 +325,7 @@ void __init mem_init(void)
 		  "    memory  : 0x%16lx - 0x%16lx   (%6ld MB)\n"
 		  "      .init : 0x%p" " - 0x%p" "   (%6ld KB)\n"
 		  "      .text : 0x%p" " - 0x%p" "   (%6ld KB)\n"
+		  "    .rodata : 0x%p" " - 0x%p" "   (%6ld KB)\n"
 		  "      .data : 0x%p" " - 0x%p" "   (%6ld KB)\n",
 #ifdef CONFIG_KASAN
 		  MLG(KASAN_SHADOW_START, KASAN_SHADOW_END),
@@ -341,7 +342,8 @@ void __init mem_init(void)
 		  MLM(MODULES_VADDR, MODULES_END),
 		  MLM(PAGE_OFFSET, (unsigned long)high_memory),
 		  MLK_ROUNDUP(__init_begin, __init_end),
-		  MLK_ROUNDUP(_text, _etext),
+		  MLK_ROUNDUP(_text, __start_rodata),
+		  MLK_ROUNDUP(__start_rodata, _etext),
 		  MLK_ROUNDUP(_sdata, _edata));
 
 #undef MLK
-- 
2.4.3



From marc.zyngier at arm.com  Wed Feb 17 08:40:43 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:43 +0000
Subject: [PATCH v2 11/17] arm64: KVM: vgic-v2: Only wipe LRs on vcpu exit
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-12-git-send-email-marc.zyngier@arm.com>

So far, we're always writing all possible LRs, setting the empty
ones with a zero value. This is obvious doing a low of work for
nothing, and we're better off clearing those we've actually
dirtied on the exit path (it is very rare to inject more than one
interrupt at a time anyway).

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/vgic-v2-sr.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vgic-v2-sr.c b/arch/arm64/kvm/hyp/vgic-v2-sr.c
index 3dbbc6b..e53f131 100644
--- a/arch/arm64/kvm/hyp/vgic-v2-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v2-sr.c
@@ -101,6 +101,7 @@ static void __hyp_text save_lrs(struct kvm_vcpu *vcpu, void __iomem *base)
 		}
 
 		cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
+		writel_relaxed(0, base + GICH_LR0 + (i * 4));
 	}
 }
 
@@ -158,12 +159,11 @@ void __hyp_text __vgic_v2_restore_state(struct kvm_vcpu *vcpu)
 		writel_relaxed(cpu_if->vgic_hcr, base + GICH_HCR);
 		writel_relaxed(cpu_if->vgic_apr, base + GICH_APR);
 		for (i = 0; i < nr_lr; i++) {
-			u32 val = 0;
-
-			if (live_lrs & (1UL << i))
-				val = cpu_if->vgic_lr[i];
+			if (!(live_lrs & (1UL << i)))
+				continue;
 
-			writel_relaxed(val, base + GICH_LR0 + (i * 4));
+			writel_relaxed(cpu_if->vgic_lr[i],
+				       base + GICH_LR0 + (i * 4));
 		}
 	}
 
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 08:40:38 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:38 +0000
Subject: [PATCH v2 06/17] KVM: arm/arm64: timer: Add active state caching
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-7-git-send-email-marc.zyngier@arm.com>

Programming the active state in the (re)distributor can be an
expensive operation so it makes some sense to try and reduce
the number of accesses as much as possible. So far, we
program the active state on each VM entry, but there is some
opportunity to do less.

An obvious solution is to cache the active state in memory,
and only program it in the HW when conditions change. But
because the HW can also change things under our feet (the active
state can transition from 1 to 0 when the guest does an EOI),
some precautions have to be taken, which amount to only caching
an "inactive" state, and always programing it otherwise.

With this in place, we observe a reduction of around 700 cycles
on a 2GHz GICv2 platform for a NULL hypercall.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/arm.c           |  1 +
 include/kvm/arm_arch_timer.h |  5 +++++
 virt/kvm/arm/arch_timer.c    | 31 +++++++++++++++++++++++++++++++
 3 files changed, 37 insertions(+)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dda1959..af7c1a3 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -320,6 +320,7 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
 	vcpu->cpu = -1;
 
 	kvm_arm_set_running_vcpu(NULL);
+	kvm_timer_vcpu_put(vcpu);
 }
 
 int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
index 1800227..b651aed 100644
--- a/include/kvm/arm_arch_timer.h
+++ b/include/kvm/arm_arch_timer.h
@@ -55,6 +55,9 @@ struct arch_timer_cpu {
 
 	/* VGIC mapping */
 	struct irq_phys_map		*map;
+
+	/* Active IRQ state caching */
+	bool				active_cleared_last;
 };
 
 int kvm_timer_hyp_init(void);
@@ -74,4 +77,6 @@ bool kvm_timer_should_fire(struct kvm_vcpu *vcpu);
 void kvm_timer_schedule(struct kvm_vcpu *vcpu);
 void kvm_timer_unschedule(struct kvm_vcpu *vcpu);
 
+void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu);
+
 #endif
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 69bca18..bfec447 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -34,6 +34,11 @@ static struct timecounter *timecounter;
 static struct workqueue_struct *wqueue;
 static unsigned int host_vtimer_irq;
 
+void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu)
+{
+	vcpu->arch.timer_cpu.active_cleared_last = false;
+}
+
 static cycle_t kvm_phys_timer_read(void)
 {
 	return timecounter->cc->read(timecounter->cc);
@@ -130,6 +135,7 @@ static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level)
 
 	BUG_ON(!vgic_initialized(vcpu->kvm));
 
+	timer->active_cleared_last = false;
 	timer->irq.level = new_level;
 	trace_kvm_timer_update_irq(vcpu->vcpu_id, timer->map->virt_irq,
 				   timer->irq.level);
@@ -242,10 +248,35 @@ void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu)
 	else
 		phys_active = false;
 
+	/*
+	 * We want to avoid hitting the (re)distributor as much as
+	 * possible, as this is a potentially expensive MMIO access
+	 * (not to mention locks in the irq layer), and a solution for
+	 * this is to cache the "active" state in memory.
+	 *
+	 * Things to consider: we cannot cache an "active set" state,
+	 * because the HW can change this behind our back (it becomes
+	 * "clear" in the HW). We must then restrict the caching to
+	 * the "clear" state.
+	 *
+	 * The cache is invalidated on:
+	 * - vcpu put, indicating that the HW cannot be trusted to be
+	 *   in a sane state on the next vcpu load,
+	 * - any change in the interrupt state
+	 *
+	 * Usage conditions:
+	 * - cached value is "active clear"
+	 * - value to be programmed is "active clear"
+	 */
+	if (timer->active_cleared_last && !phys_active)
+		return;
+
 	ret = irq_set_irqchip_state(timer->map->irq,
 				    IRQCHIP_STATE_ACTIVE,
 				    phys_active);
 	WARN_ON(ret);
+
+	timer->active_cleared_last = !phys_active;
 }
 
 /**
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 08:40:41 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:41 +0000
Subject: [PATCH v2 09/17] arm64: KVM: vgic-v2: Move GICH_ELRSR saving to its
 own function
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-10-git-send-email-marc.zyngier@arm.com>

In order to make the saving path slightly more readable and
prepare for some more optimizations, let's more the GICH_ELRSR
saving to its own function.

No functional change.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/vgic-v2-sr.c | 36 +++++++++++++++++++++---------------
 1 file changed, 21 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vgic-v2-sr.c b/arch/arm64/kvm/hyp/vgic-v2-sr.c
index 1bda5ce..c281374 100644
--- a/arch/arm64/kvm/hyp/vgic-v2-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v2-sr.c
@@ -66,6 +66,25 @@ static void __hyp_text save_maint_int_state(struct kvm_vcpu *vcpu,
 #endif
 }
 
+static void __hyp_text save_elrsr(struct kvm_vcpu *vcpu, void __iomem *base)
+{
+	struct vgic_v2_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v2;
+	int nr_lr = vcpu->arch.vgic_cpu.nr_lr;
+	u32 elrsr0, elrsr1;
+
+	elrsr0 = readl_relaxed(base + GICH_ELRSR0);
+	if (unlikely(nr_lr > 32))
+		elrsr1 = readl_relaxed(base + GICH_ELRSR1);
+	else
+		elrsr1 = 0;
+
+#ifdef CONFIG_CPU_BIG_ENDIAN
+	cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
+#else
+	cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
+#endif
+}
+
 /* vcpu is already in the HYP VA space */
 void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
 {
@@ -73,7 +92,6 @@ void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
 	struct vgic_v2_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v2;
 	struct vgic_dist *vgic = &kvm->arch.vgic;
 	void __iomem *base = kern_hyp_va(vgic->vctrl_base);
-	u32 elrsr0, elrsr1;
 	int i, nr_lr;
 
 	if (!base)
@@ -83,22 +101,10 @@ void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
 	cpu_if->vgic_vmcr = readl_relaxed(base + GICH_VMCR);
 
 	if (vcpu->arch.vgic_cpu.live_lrs) {
-		elrsr0 = readl_relaxed(base + GICH_ELRSR0);
-		cpu_if->vgic_apr    = readl_relaxed(base + GICH_APR);
-
-		if (unlikely(nr_lr > 32)) {
-			elrsr1 = readl_relaxed(base + GICH_ELRSR1);
-		} else {
-			elrsr1 = 0;
-		}
-
-#ifdef CONFIG_CPU_BIG_ENDIAN
-		cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
-#else
-		cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
-#endif
+		cpu_if->vgic_apr = readl_relaxed(base + GICH_APR);
 
 		save_maint_int_state(vcpu, base);
+		save_elrsr(vcpu, base);
  
 		for (i = 0; i < nr_lr; i++)
 			if (vcpu->arch.vgic_cpu.live_lrs & (1UL << i))
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 08:40:42 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:42 +0000
Subject: [PATCH v2 10/17] arm64: KVM: vgic-v2: Do not save an LR known to be
 empty
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-11-git-send-email-marc.zyngier@arm.com>

On exit, any empty LR will be signaled in GICH_ELRSR*. Which
means that we do not have to save it, and we can just clear
its state in the in-memory copy.

Take this opportunity to move the LR saving code into its
own function.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/vgic-v2-sr.c | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vgic-v2-sr.c b/arch/arm64/kvm/hyp/vgic-v2-sr.c
index c281374..3dbbc6b 100644
--- a/arch/arm64/kvm/hyp/vgic-v2-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v2-sr.c
@@ -85,6 +85,25 @@ static void __hyp_text save_elrsr(struct kvm_vcpu *vcpu, void __iomem *base)
 #endif
 }
 
+static void __hyp_text save_lrs(struct kvm_vcpu *vcpu, void __iomem *base)
+{
+	struct vgic_v2_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v2;
+	int nr_lr = vcpu->arch.vgic_cpu.nr_lr;
+	int i;
+
+	for (i = 0; i < nr_lr; i++) {
+		if (!(vcpu->arch.vgic_cpu.live_lrs & (1UL << i)))
+			continue;
+
+		if (cpu_if->vgic_elrsr & (1UL << i)) {
+			cpu_if->vgic_lr[i] &= ~GICH_LR_STATE;
+			continue;
+		}
+
+		cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
+	}
+}
+
 /* vcpu is already in the HYP VA space */
 void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
 {
@@ -92,12 +111,10 @@ void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
 	struct vgic_v2_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v2;
 	struct vgic_dist *vgic = &kvm->arch.vgic;
 	void __iomem *base = kern_hyp_va(vgic->vctrl_base);
-	int i, nr_lr;
 
 	if (!base)
 		return;
 
-	nr_lr = vcpu->arch.vgic_cpu.nr_lr;
 	cpu_if->vgic_vmcr = readl_relaxed(base + GICH_VMCR);
 
 	if (vcpu->arch.vgic_cpu.live_lrs) {
@@ -105,10 +122,7 @@ void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
 
 		save_maint_int_state(vcpu, base);
 		save_elrsr(vcpu, base);
- 
-		for (i = 0; i < nr_lr; i++)
-			if (vcpu->arch.vgic_cpu.live_lrs & (1UL << i))
-				cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
+		save_lrs(vcpu, base);
 
 		writel_relaxed(0, base + GICH_HCR);
 
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 08:40:40 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:40 +0000
Subject: [PATCH v2 08/17] arm64: KVM: vgic-v2: Save maintenance interrupt
 state only if required
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-9-git-send-email-marc.zyngier@arm.com>

Next on our list of useless accesses is the maintenance interrupt
status registers (GICH_MISR, GICH_EISR{0,1}).

It is pointless to save them if we haven't asked for a maintenance
interrupt the first place, which can only happen for two reasons:
- Underflow: GICH_HCR_UIE will be set,
- EOI: GICH_LR_EOI will be set.

These conditions can be checked on the in-memory copies of the regs.
Should any of these two condition be valid, we must read GICH_MISR.
We can then check for GICH_MISR_EOI, and only when set read
GICH_EISR*.

This means that in most case, we don't have to save them at all.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/vgic-v2-sr.c | 54 +++++++++++++++++++++++++++++++++++------
 1 file changed, 47 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vgic-v2-sr.c b/arch/arm64/kvm/hyp/vgic-v2-sr.c
index 5ab8d63..1bda5ce 100644
--- a/arch/arm64/kvm/hyp/vgic-v2-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v2-sr.c
@@ -23,6 +23,49 @@
 
 #include "hyp.h"
 
+static void __hyp_text save_maint_int_state(struct kvm_vcpu *vcpu,
+					    void __iomem *base)
+{
+	struct vgic_v2_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v2;
+	int nr_lr = vcpu->arch.vgic_cpu.nr_lr;
+	u32 eisr0, eisr1;
+	int i;
+	bool expect_mi;
+
+	expect_mi = !!(cpu_if->vgic_hcr & GICH_HCR_UIE);
+
+	for (i = 0; i < nr_lr; i++) {
+		if (!(vcpu->arch.vgic_cpu.live_lrs & (1UL << i)))
+				continue;
+
+		expect_mi |= (!(cpu_if->vgic_lr[i] & GICH_LR_HW) &&
+			      (cpu_if->vgic_lr[i] & GICH_LR_EOI));
+	}
+
+	if (expect_mi) {
+		cpu_if->vgic_misr = readl_relaxed(base + GICH_MISR);
+
+		if (cpu_if->vgic_misr & GICH_MISR_EOI) {
+			eisr0  = readl_relaxed(base + GICH_EISR0);
+			if (unlikely(nr_lr > 32))
+				eisr1  = readl_relaxed(base + GICH_EISR1);
+			else
+				eisr1 = 0;
+		} else {
+			eisr0 = eisr1 = 0;
+		}
+	} else {
+		cpu_if->vgic_misr = 0;
+		eisr0 = eisr1 = 0;
+	}
+
+#ifdef CONFIG_CPU_BIG_ENDIAN
+	cpu_if->vgic_eisr = ((u64)eisr0 << 32) | eisr1;
+#else
+	cpu_if->vgic_eisr = ((u64)eisr1 << 32) | eisr0;
+#endif
+}
+
 /* vcpu is already in the HYP VA space */
 void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
 {
@@ -30,7 +73,7 @@ void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
 	struct vgic_v2_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v2;
 	struct vgic_dist *vgic = &kvm->arch.vgic;
 	void __iomem *base = kern_hyp_va(vgic->vctrl_base);
-	u32 eisr0, eisr1, elrsr0, elrsr1;
+	u32 elrsr0, elrsr1;
 	int i, nr_lr;
 
 	if (!base)
@@ -40,26 +83,23 @@ void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
 	cpu_if->vgic_vmcr = readl_relaxed(base + GICH_VMCR);
 
 	if (vcpu->arch.vgic_cpu.live_lrs) {
-		eisr0  = readl_relaxed(base + GICH_EISR0);
 		elrsr0 = readl_relaxed(base + GICH_ELRSR0);
-		cpu_if->vgic_misr = readl_relaxed(base + GICH_MISR);
 		cpu_if->vgic_apr    = readl_relaxed(base + GICH_APR);
 
 		if (unlikely(nr_lr > 32)) {
-			eisr1  = readl_relaxed(base + GICH_EISR1);
 			elrsr1 = readl_relaxed(base + GICH_ELRSR1);
 		} else {
-			eisr1 = elrsr1 = 0;
+			elrsr1 = 0;
 		}
 
 #ifdef CONFIG_CPU_BIG_ENDIAN
-		cpu_if->vgic_eisr  = ((u64)eisr0 << 32) | eisr1;
 		cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
 #else
-		cpu_if->vgic_eisr  = ((u64)eisr1 << 32) | eisr0;
 		cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
 #endif
 
+		save_maint_int_state(vcpu, base);
+ 
 		for (i = 0; i < nr_lr; i++)
 			if (vcpu->arch.vgic_cpu.live_lrs & (1UL << i))
 				cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 08:40:44 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:44 +0000
Subject: [PATCH v2 12/17] arm64: KVM: vgic-v2: Make GICD_SGIR quicker to hit
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-13-git-send-email-marc.zyngier@arm.com>

The GICD_SGIR register lives a long way from the beginning of
the handler array, which is searched linearly. As this is hit
pretty often, let's move it up. This saves us some precious
cycles when the guest is generating IPIs.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 virt/kvm/arm/vgic-v2-emul.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/virt/kvm/arm/vgic-v2-emul.c b/virt/kvm/arm/vgic-v2-emul.c
index 1390797..1b0bee0 100644
--- a/virt/kvm/arm/vgic-v2-emul.c
+++ b/virt/kvm/arm/vgic-v2-emul.c
@@ -321,6 +321,11 @@ static bool handle_mmio_sgi_clear(struct kvm_vcpu *vcpu,
 
 static const struct vgic_io_range vgic_dist_ranges[] = {
 	{
+		.base		= GIC_DIST_SOFTINT,
+		.len		= 4,
+		.handle_mmio	= handle_mmio_sgi_reg,
+	},
+	{
 		.base		= GIC_DIST_CTRL,
 		.len		= 12,
 		.bits_per_irq	= 0,
@@ -387,11 +392,6 @@ static const struct vgic_io_range vgic_dist_ranges[] = {
 		.handle_mmio	= handle_mmio_cfg_reg,
 	},
 	{
-		.base		= GIC_DIST_SOFTINT,
-		.len		= 4,
-		.handle_mmio	= handle_mmio_sgi_reg,
-	},
-	{
 		.base		= GIC_DIST_SGI_PENDING_CLEAR,
 		.len		= VGIC_NR_SGIS,
 		.handle_mmio	= handle_mmio_sgi_clear,
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 08:40:39 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:39 +0000
Subject: [PATCH v2 07/17] arm64: KVM: vgic-v2: Avoid accessing GICH registers
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-8-git-send-email-marc.zyngier@arm.com>

GICv2 registers are *slow*. As in "terrifyingly slow". Which is bad.
But we're equaly bad, as we make a point in accessing them even if
we don't have any interrupt in flight.

A good solution is to first find out if we have anything useful to
write into the GIC, and if we don't, to simply not do it. This
involves tracking which LRs actually have something valid there.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/vgic-v2-sr.c | 72 ++++++++++++++++++++++++++++-------------
 include/kvm/arm_vgic.h          |  2 ++
 2 files changed, 52 insertions(+), 22 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vgic-v2-sr.c b/arch/arm64/kvm/hyp/vgic-v2-sr.c
index e717612..5ab8d63 100644
--- a/arch/arm64/kvm/hyp/vgic-v2-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v2-sr.c
@@ -38,28 +38,41 @@ void __hyp_text __vgic_v2_save_state(struct kvm_vcpu *vcpu)
 
 	nr_lr = vcpu->arch.vgic_cpu.nr_lr;
 	cpu_if->vgic_vmcr = readl_relaxed(base + GICH_VMCR);
-	cpu_if->vgic_misr = readl_relaxed(base + GICH_MISR);
-	eisr0  = readl_relaxed(base + GICH_EISR0);
-	elrsr0 = readl_relaxed(base + GICH_ELRSR0);
-	if (unlikely(nr_lr > 32)) {
-		eisr1  = readl_relaxed(base + GICH_EISR1);
-		elrsr1 = readl_relaxed(base + GICH_ELRSR1);
-	} else {
-		eisr1 = elrsr1 = 0;
-	}
+
+	if (vcpu->arch.vgic_cpu.live_lrs) {
+		eisr0  = readl_relaxed(base + GICH_EISR0);
+		elrsr0 = readl_relaxed(base + GICH_ELRSR0);
+		cpu_if->vgic_misr = readl_relaxed(base + GICH_MISR);
+		cpu_if->vgic_apr    = readl_relaxed(base + GICH_APR);
+
+		if (unlikely(nr_lr > 32)) {
+			eisr1  = readl_relaxed(base + GICH_EISR1);
+			elrsr1 = readl_relaxed(base + GICH_ELRSR1);
+		} else {
+			eisr1 = elrsr1 = 0;
+		}
+
 #ifdef CONFIG_CPU_BIG_ENDIAN
-	cpu_if->vgic_eisr  = ((u64)eisr0 << 32) | eisr1;
-	cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
+		cpu_if->vgic_eisr  = ((u64)eisr0 << 32) | eisr1;
+		cpu_if->vgic_elrsr = ((u64)elrsr0 << 32) | elrsr1;
 #else
-	cpu_if->vgic_eisr  = ((u64)eisr1 << 32) | eisr0;
-	cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
+		cpu_if->vgic_eisr  = ((u64)eisr1 << 32) | eisr0;
+		cpu_if->vgic_elrsr = ((u64)elrsr1 << 32) | elrsr0;
 #endif
-	cpu_if->vgic_apr    = readl_relaxed(base + GICH_APR);
 
-	writel_relaxed(0, base + GICH_HCR);
+		for (i = 0; i < nr_lr; i++)
+			if (vcpu->arch.vgic_cpu.live_lrs & (1UL << i))
+				cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
 
-	for (i = 0; i < nr_lr; i++)
-		cpu_if->vgic_lr[i] = readl_relaxed(base + GICH_LR0 + (i * 4));
+		writel_relaxed(0, base + GICH_HCR);
+
+		vcpu->arch.vgic_cpu.live_lrs = 0;
+	} else {
+		cpu_if->vgic_eisr = 0;
+		cpu_if->vgic_elrsr = ~0UL;
+		cpu_if->vgic_misr = 0;
+		cpu_if->vgic_apr = 0;
+	}
 }
 
 /* vcpu is already in the HYP VA space */
@@ -70,15 +83,30 @@ void __hyp_text __vgic_v2_restore_state(struct kvm_vcpu *vcpu)
 	struct vgic_dist *vgic = &kvm->arch.vgic;
 	void __iomem *base = kern_hyp_va(vgic->vctrl_base);
 	int i, nr_lr;
+	u64 live_lrs = 0;
 
 	if (!base)
 		return;
 
-	writel_relaxed(cpu_if->vgic_hcr, base + GICH_HCR);
-	writel_relaxed(cpu_if->vgic_vmcr, base + GICH_VMCR);
-	writel_relaxed(cpu_if->vgic_apr, base + GICH_APR);
-
 	nr_lr = vcpu->arch.vgic_cpu.nr_lr;
+
 	for (i = 0; i < nr_lr; i++)
-		writel_relaxed(cpu_if->vgic_lr[i], base + GICH_LR0 + (i * 4));
+		if (cpu_if->vgic_lr[i] & GICH_LR_STATE)
+			live_lrs |= 1UL << i;
+
+	if (live_lrs) {
+		writel_relaxed(cpu_if->vgic_hcr, base + GICH_HCR);
+		writel_relaxed(cpu_if->vgic_apr, base + GICH_APR);
+		for (i = 0; i < nr_lr; i++) {
+			u32 val = 0;
+
+			if (live_lrs & (1UL << i))
+				val = cpu_if->vgic_lr[i];
+
+			writel_relaxed(val, base + GICH_LR0 + (i * 4));
+		}
+	}
+
+	writel_relaxed(cpu_if->vgic_vmcr, base + GICH_VMCR);
+	vcpu->arch.vgic_cpu.live_lrs = live_lrs;
 }
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 13a3d53..f473fd6 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -321,6 +321,8 @@ struct vgic_cpu {
 
 	/* Protected by the distributor's irq_phys_map_lock */
 	struct list_head	irq_phys_map_list;
+
+	u64		live_lrs;
 };
 
 #define LR_EMPTY	0xff
-- 
2.1.4



From jeremy.linton at arm.com  Wed Feb 17 08:41:12 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Wed, 17 Feb 2016 10:41:12 -0600
Subject: [PATCH v2 0/2] arm64: mm: Mark .rodata as RO
Message-ID: <1455727274-16328-1-git-send-email-jeremy.linton@arm.com>

Currently the .rodata section is actually still executable when DEBUG_RODATA
is enabled. This changes that so the .rodata is actually read only, no execute.

This patch is based on top of "PATCH v2 flag contiguous PTES in linear mapping"

V1->V2
  Added .rodata to kernel VM range notice in mem_init
  Split _stext->_etext into an additional chunk in map_kernel

Jeremy Linton (2):
  arm64: mm: Mark .rodata as RO
  arm64/mm: Add .rodata to kernel virtual memory boot notice

 arch/arm64/kernel/vmlinux.lds.S |  5 +++--
 arch/arm64/mm/init.c            |  4 +++-
 arch/arm64/mm/mmu.c             | 17 +++++++++++++----
 3 files changed, 19 insertions(+), 7 deletions(-)

-- 
2.4.3



From marc.zyngier at arm.com  Wed Feb 17 08:40:49 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:49 +0000
Subject: [PATCH v2 17/17] arm64: KVM: vgic-v3: Do not save ICH_AP0Rn_EL2 for
 GICv2 emulation
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-18-git-send-email-marc.zyngier@arm.com>

The GICv3 specification mandates that ICH_AP0Rn_EL2 are set to
zero when running guests that use the memory mapped registers.

This is fine, as we initialize all ICH_AP0Rn_EL2 registers to
zero, and restore them on entry. But it also means that we
do not need to save these registers on exit. Profit!

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/vgic-v3-sr.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
index 5f12c57..c2f173d 100644
--- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
@@ -202,14 +202,17 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
 			__gic_v3_set_lr(0, i);
 		}
 
-		switch (nr_pri_bits) {
-		case 7:
-			cpu_if->vgic_ap0r[3] = read_gicreg(ICH_AP0R3_EL2);
-			cpu_if->vgic_ap0r[2] = read_gicreg(ICH_AP0R2_EL2);
-		case 6:
-			cpu_if->vgic_ap0r[1] = read_gicreg(ICH_AP0R1_EL2);
-		default:
-			cpu_if->vgic_ap0r[0] = read_gicreg(ICH_AP0R0_EL2);
+		/* ICH_AP0Rn is only valid for SRE==1 */
+		if (cpu_if->vgic_sre & ICC_SRE_EL1_SRE) {
+			switch (nr_pri_bits) {
+			case 7:
+				cpu_if->vgic_ap0r[3] = read_gicreg(ICH_AP0R3_EL2);
+				cpu_if->vgic_ap0r[2] = read_gicreg(ICH_AP0R2_EL2);
+			case 6:
+				cpu_if->vgic_ap0r[1] = read_gicreg(ICH_AP0R1_EL2);
+			default:
+				cpu_if->vgic_ap0r[0] = read_gicreg(ICH_AP0R0_EL2);
+			}
 		}
 
 		switch (nr_pri_bits) {
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 08:40:45 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:45 +0000
Subject: [PATCH v2 13/17] arm64: KVM: vgic-v3: Avoid accessing ICH registers
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-14-git-send-email-marc.zyngier@arm.com>

Just like on GICv2, we're a bit hammer-happy with GICv3, and access
them more often than we should.

Adopt a policy similar to what we do for GICv2, only save/restoring
the minimal set of registers. As we don't access the registers
linearly anymore (we may skip some), the convoluted accessors become
slightly simpler, and we can drop the ugly indexing macro that
tended to confuse the reviewers.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/vgic-v3-sr.c | 294 +++++++++++++++++++++++++---------------
 include/kvm/arm_vgic.h          |   6 -
 virt/kvm/arm/vgic-v3.c          |   4 +-
 3 files changed, 183 insertions(+), 121 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
index 93f6c5c..b62c923 100644
--- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
@@ -39,12 +39,104 @@
 		asm volatile("msr_s " __stringify(r) ", %0" : : "r" (__val));\
 	} while (0)
 
-/* vcpu is already in the HYP VA space */
+static u64 __hyp_text __gic_v3_get_lr(unsigned int lr)
+{
+	switch (lr & 0xf) {
+	case 0:
+		return read_gicreg(ICH_LR0_EL2);
+	case 1:
+		return read_gicreg(ICH_LR1_EL2);
+	case 2:
+		return read_gicreg(ICH_LR2_EL2);
+	case 3:
+		return read_gicreg(ICH_LR3_EL2);
+	case 4:
+		return read_gicreg(ICH_LR4_EL2);
+	case 5:
+		return read_gicreg(ICH_LR5_EL2);
+	case 6:
+		return read_gicreg(ICH_LR6_EL2);
+	case 7:
+		return read_gicreg(ICH_LR7_EL2);
+	case 8:
+		return read_gicreg(ICH_LR8_EL2);
+	case 9:
+		return read_gicreg(ICH_LR9_EL2);
+	case 10:
+		return read_gicreg(ICH_LR10_EL2);
+	case 11:
+		return read_gicreg(ICH_LR11_EL2);
+	case 12:
+		return read_gicreg(ICH_LR12_EL2);
+	case 13:
+		return read_gicreg(ICH_LR13_EL2);
+	case 14:
+		return read_gicreg(ICH_LR14_EL2);
+	case 15:
+		return read_gicreg(ICH_LR15_EL2);
+	}
+
+	unreachable();
+}
+
+static void __hyp_text __gic_v3_set_lr(u64 val, int lr)
+{
+	switch (lr & 0xf) {
+	case 0:
+		write_gicreg(val, ICH_LR0_EL2);
+		break;
+	case 1:
+		write_gicreg(val, ICH_LR1_EL2);
+		break;
+	case 2:
+		write_gicreg(val, ICH_LR2_EL2);
+		break;
+	case 3:
+		write_gicreg(val, ICH_LR3_EL2);
+		break;
+	case 4:
+		write_gicreg(val, ICH_LR4_EL2);
+		break;
+	case 5:
+		write_gicreg(val, ICH_LR5_EL2);
+		break;
+	case 6:
+		write_gicreg(val, ICH_LR6_EL2);
+		break;
+	case 7:
+		write_gicreg(val, ICH_LR7_EL2);
+		break;
+	case 8:
+		write_gicreg(val, ICH_LR8_EL2);
+		break;
+	case 9:
+		write_gicreg(val, ICH_LR9_EL2);
+		break;
+	case 10:
+		write_gicreg(val, ICH_LR10_EL2);
+		break;
+	case 11:
+		write_gicreg(val, ICH_LR11_EL2);
+		break;
+	case 12:
+		write_gicreg(val, ICH_LR12_EL2);
+		break;
+	case 13:
+		write_gicreg(val, ICH_LR13_EL2);
+		break;
+	case 14:
+		write_gicreg(val, ICH_LR14_EL2);
+		break;
+	case 15:
+		write_gicreg(val, ICH_LR15_EL2);
+		break;
+	}
+}
+
 void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
 {
 	struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
 	u64 val;
-	u32 max_lr_idx, nr_pri_bits;
 
 	/*
 	 * Make sure stores to the GIC via the memory mapped interface
@@ -53,68 +145,58 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
 	dsb(st);
 
 	cpu_if->vgic_vmcr  = read_gicreg(ICH_VMCR_EL2);
-	cpu_if->vgic_misr  = read_gicreg(ICH_MISR_EL2);
-	cpu_if->vgic_eisr  = read_gicreg(ICH_EISR_EL2);
-	cpu_if->vgic_elrsr = read_gicreg(ICH_ELSR_EL2);
 
-	write_gicreg(0, ICH_HCR_EL2);
-	val = read_gicreg(ICH_VTR_EL2);
-	max_lr_idx = vtr_to_max_lr_idx(val);
-	nr_pri_bits = vtr_to_nr_pri_bits(val);
+	if (vcpu->arch.vgic_cpu.live_lrs) {
+		int i;
+		u32 max_lr_idx, nr_pri_bits;
 
-	switch (max_lr_idx) {
-	case 15:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(15)] = read_gicreg(ICH_LR15_EL2);
-	case 14:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(14)] = read_gicreg(ICH_LR14_EL2);
-	case 13:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(13)] = read_gicreg(ICH_LR13_EL2);
-	case 12:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(12)] = read_gicreg(ICH_LR12_EL2);
-	case 11:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(11)] = read_gicreg(ICH_LR11_EL2);
-	case 10:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(10)] = read_gicreg(ICH_LR10_EL2);
-	case 9:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(9)] = read_gicreg(ICH_LR9_EL2);
-	case 8:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(8)] = read_gicreg(ICH_LR8_EL2);
-	case 7:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(7)] = read_gicreg(ICH_LR7_EL2);
-	case 6:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(6)] = read_gicreg(ICH_LR6_EL2);
-	case 5:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(5)] = read_gicreg(ICH_LR5_EL2);
-	case 4:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(4)] = read_gicreg(ICH_LR4_EL2);
-	case 3:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(3)] = read_gicreg(ICH_LR3_EL2);
-	case 2:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(2)] = read_gicreg(ICH_LR2_EL2);
-	case 1:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(1)] = read_gicreg(ICH_LR1_EL2);
-	case 0:
-		cpu_if->vgic_lr[VGIC_V3_LR_INDEX(0)] = read_gicreg(ICH_LR0_EL2);
-	}
+		cpu_if->vgic_misr  = read_gicreg(ICH_MISR_EL2);
+		cpu_if->vgic_eisr  = read_gicreg(ICH_EISR_EL2);
+		cpu_if->vgic_elrsr = read_gicreg(ICH_ELSR_EL2);
 
-	switch (nr_pri_bits) {
-	case 7:
-		cpu_if->vgic_ap0r[3] = read_gicreg(ICH_AP0R3_EL2);
-		cpu_if->vgic_ap0r[2] = read_gicreg(ICH_AP0R2_EL2);
-	case 6:
-		cpu_if->vgic_ap0r[1] = read_gicreg(ICH_AP0R1_EL2);
-	default:
-		cpu_if->vgic_ap0r[0] = read_gicreg(ICH_AP0R0_EL2);
-	}
+		write_gicreg(0, ICH_HCR_EL2);
+		val = read_gicreg(ICH_VTR_EL2);
+		max_lr_idx = vtr_to_max_lr_idx(val);
+		nr_pri_bits = vtr_to_nr_pri_bits(val);
 
-	switch (nr_pri_bits) {
-	case 7:
-		cpu_if->vgic_ap1r[3] = read_gicreg(ICH_AP1R3_EL2);
-		cpu_if->vgic_ap1r[2] = read_gicreg(ICH_AP1R2_EL2);
-	case 6:
-		cpu_if->vgic_ap1r[1] = read_gicreg(ICH_AP1R1_EL2);
-	default:
-		cpu_if->vgic_ap1r[0] = read_gicreg(ICH_AP1R0_EL2);
+		for (i = 0; i <= max_lr_idx; i++) {
+			if (vcpu->arch.vgic_cpu.live_lrs & (1UL << i))
+				cpu_if->vgic_lr[i] = __gic_v3_get_lr(i);
+		}
+
+		switch (nr_pri_bits) {
+		case 7:
+			cpu_if->vgic_ap0r[3] = read_gicreg(ICH_AP0R3_EL2);
+			cpu_if->vgic_ap0r[2] = read_gicreg(ICH_AP0R2_EL2);
+		case 6:
+			cpu_if->vgic_ap0r[1] = read_gicreg(ICH_AP0R1_EL2);
+		default:
+			cpu_if->vgic_ap0r[0] = read_gicreg(ICH_AP0R0_EL2);
+		}
+
+		switch (nr_pri_bits) {
+		case 7:
+			cpu_if->vgic_ap1r[3] = read_gicreg(ICH_AP1R3_EL2);
+			cpu_if->vgic_ap1r[2] = read_gicreg(ICH_AP1R2_EL2);
+		case 6:
+			cpu_if->vgic_ap1r[1] = read_gicreg(ICH_AP1R1_EL2);
+		default:
+			cpu_if->vgic_ap1r[0] = read_gicreg(ICH_AP1R0_EL2);
+		}
+
+		vcpu->arch.vgic_cpu.live_lrs = 0;
+	} else {
+		cpu_if->vgic_misr  = 0;
+		cpu_if->vgic_eisr  = 0;
+		cpu_if->vgic_elrsr = 0xffff;
+		cpu_if->vgic_ap0r[0] = 0;
+		cpu_if->vgic_ap0r[1] = 0;
+		cpu_if->vgic_ap0r[2] = 0;
+		cpu_if->vgic_ap0r[3] = 0;
+		cpu_if->vgic_ap1r[0] = 0;
+		cpu_if->vgic_ap1r[1] = 0;
+		cpu_if->vgic_ap1r[2] = 0;
+		cpu_if->vgic_ap1r[3] = 0;
 	}
 
 	val = read_gicreg(ICC_SRE_EL2);
@@ -128,6 +210,8 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
 	struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
 	u64 val;
 	u32 max_lr_idx, nr_pri_bits;
+	u16 live_lrs = 0;
+	int i;
 
 	/*
 	 * VFIQEn is RES1 if ICC_SRE_EL1.SRE is 1. This causes a
@@ -140,68 +224,51 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
 	write_gicreg(cpu_if->vgic_sre, ICC_SRE_EL1);
 	isb();
 
-	write_gicreg(cpu_if->vgic_hcr, ICH_HCR_EL2);
-	write_gicreg(cpu_if->vgic_vmcr, ICH_VMCR_EL2);
-
 	val = read_gicreg(ICH_VTR_EL2);
 	max_lr_idx = vtr_to_max_lr_idx(val);
 	nr_pri_bits = vtr_to_nr_pri_bits(val);
 
-	switch (nr_pri_bits) {
-	case 7:
-		 write_gicreg(cpu_if->vgic_ap0r[3], ICH_AP0R3_EL2);
-		 write_gicreg(cpu_if->vgic_ap0r[2], ICH_AP0R2_EL2);
-	case 6:
-		 write_gicreg(cpu_if->vgic_ap0r[1], ICH_AP0R1_EL2);
-	default:
-		 write_gicreg(cpu_if->vgic_ap0r[0], ICH_AP0R0_EL2);
+	for (i = 0; i <= max_lr_idx; i++) {
+		if (cpu_if->vgic_lr[i] & ICH_LR_STATE)
+			live_lrs |= (1 << i);
 	}
 
-	switch (nr_pri_bits) {
-	case 7:
-		 write_gicreg(cpu_if->vgic_ap1r[3], ICH_AP1R3_EL2);
-		 write_gicreg(cpu_if->vgic_ap1r[2], ICH_AP1R2_EL2);
-	case 6:
-		 write_gicreg(cpu_if->vgic_ap1r[1], ICH_AP1R1_EL2);
-	default:
-		 write_gicreg(cpu_if->vgic_ap1r[0], ICH_AP1R0_EL2);
-	}	 	                           
+	write_gicreg(cpu_if->vgic_vmcr, ICH_VMCR_EL2);
+
+	if (live_lrs) {
+		write_gicreg(cpu_if->vgic_hcr, ICH_HCR_EL2);
+
+		switch (nr_pri_bits) {
+		case 7:
+			write_gicreg(cpu_if->vgic_ap0r[3], ICH_AP0R3_EL2);
+			write_gicreg(cpu_if->vgic_ap0r[2], ICH_AP0R2_EL2);
+		case 6:
+			write_gicreg(cpu_if->vgic_ap0r[1], ICH_AP0R1_EL2);
+		default:
+			write_gicreg(cpu_if->vgic_ap0r[0], ICH_AP0R0_EL2);
+		}
+
+		switch (nr_pri_bits) {
+		case 7:
+			write_gicreg(cpu_if->vgic_ap1r[3], ICH_AP1R3_EL2);
+			write_gicreg(cpu_if->vgic_ap1r[2], ICH_AP1R2_EL2);
+		case 6:
+			write_gicreg(cpu_if->vgic_ap1r[1], ICH_AP1R1_EL2);
+		default:
+			write_gicreg(cpu_if->vgic_ap1r[0], ICH_AP1R0_EL2);
+		}
 		 	                           
-	switch (max_lr_idx) {
-	case 15:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(15)], ICH_LR15_EL2);
-	case 14:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(14)], ICH_LR14_EL2);
-	case 13:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(13)], ICH_LR13_EL2);
-	case 12:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(12)], ICH_LR12_EL2);
-	case 11:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(11)], ICH_LR11_EL2);
-	case 10:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(10)], ICH_LR10_EL2);
-	case 9:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(9)], ICH_LR9_EL2);
-	case 8:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(8)], ICH_LR8_EL2);
-	case 7:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(7)], ICH_LR7_EL2);
-	case 6:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(6)], ICH_LR6_EL2);
-	case 5:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(5)], ICH_LR5_EL2);
-	case 4:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(4)], ICH_LR4_EL2);
-	case 3:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(3)], ICH_LR3_EL2);
-	case 2:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(2)], ICH_LR2_EL2);
-	case 1:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(1)], ICH_LR1_EL2);
-	case 0:
-		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(0)], ICH_LR0_EL2);
+		for (i = 0; i <= max_lr_idx; i++) {
+			val = 0;
+
+			if (live_lrs & (1 << i))
+				val = cpu_if->vgic_lr[i];
+
+			__gic_v3_set_lr(val, i);
+		}
 	}
 
+
 	/*
 	 * Ensures that the above will have reached the
 	 * (re)distributors. This ensure the guest will read the
@@ -209,6 +276,7 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
 	 */
 	isb();
 	dsb(sy);
+	vcpu->arch.vgic_cpu.live_lrs = live_lrs;
 
 	/*
 	 * Prevent the guest from touching the GIC system registers if
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index f473fd6..281caf8 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -279,12 +279,6 @@ struct vgic_v2_cpu_if {
 	u32		vgic_lr[VGIC_V2_MAX_LRS];
 };
 
-/*
- * LRs are stored in reverse order in memory. make sure we index them
- * correctly.
- */
-#define VGIC_V3_LR_INDEX(lr)		(VGIC_V3_MAX_LRS - 1 - lr)
-
 struct vgic_v3_cpu_if {
 #ifdef CONFIG_KVM_ARM_VGIC_V3
 	u32		vgic_hcr;
diff --git a/virt/kvm/arm/vgic-v3.c b/virt/kvm/arm/vgic-v3.c
index 453eafd..11b5ff6 100644
--- a/virt/kvm/arm/vgic-v3.c
+++ b/virt/kvm/arm/vgic-v3.c
@@ -42,7 +42,7 @@ static u32 ich_vtr_el2;
 static struct vgic_lr vgic_v3_get_lr(const struct kvm_vcpu *vcpu, int lr)
 {
 	struct vgic_lr lr_desc;
-	u64 val = vcpu->arch.vgic_cpu.vgic_v3.vgic_lr[VGIC_V3_LR_INDEX(lr)];
+	u64 val = vcpu->arch.vgic_cpu.vgic_v3.vgic_lr[lr];
 
 	if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3)
 		lr_desc.irq = val & ICH_LR_VIRTUALID_MASK;
@@ -106,7 +106,7 @@ static void vgic_v3_set_lr(struct kvm_vcpu *vcpu, int lr,
 		lr_val |= ((u64)lr_desc.hwirq) << ICH_LR_PHYS_ID_SHIFT;
 	}
 
-	vcpu->arch.vgic_cpu.vgic_v3.vgic_lr[VGIC_V3_LR_INDEX(lr)] = lr_val;
+	vcpu->arch.vgic_cpu.vgic_v3.vgic_lr[lr] = lr_val;
 
 	if (!(lr_desc.state & LR_STATE_MASK))
 		vcpu->arch.vgic_cpu.vgic_v3.vgic_elrsr |= (1U << lr);
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 08:40:46 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 16:40:46 +0000
Subject: [PATCH v2 14/17] arm64: KVM: vgic-v3: Save maintenance interrupt
 state only if required
In-Reply-To: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
References: <1455727249-24752-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455727249-24752-15-git-send-email-marc.zyngier@arm.com>

Next on our list of useless accesses is the maintenance interrupt
status registers (ICH_MISR_EL2, ICH_EISR_EL2).

It is pointless to save them if we haven't asked for a maintenance
interrupt the first place, which can only happen for two reasons:
- Underflow: ICH_HCR_UIE will be set,
- EOI: ICH_LR_EOI will be set.

These conditions can be checked on the in-memory copies of the regs.
Should any of these two condition be valid, we must read GICH_MISR.
We can then check for ICH_MISR_EOI, and only when set read
ICH_EISR_EL2.

This means that in most case, we don't have to save them at all.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/vgic-v3-sr.c | 34 ++++++++++++++++++++++++++++++++--
 1 file changed, 32 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
index b62c923..3463c0a 100644
--- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
@@ -133,6 +133,36 @@ static void __hyp_text __gic_v3_set_lr(u64 val, int lr)
 	}
 }
 
+static void __hyp_text save_maint_int_state(struct kvm_vcpu *vcpu, int nr_lr)
+{
+	struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
+	int i;
+	bool expect_mi;
+
+	expect_mi = !!(cpu_if->vgic_hcr & ICH_HCR_UIE);
+
+	for (i = 0; i < nr_lr; i++) {
+		if (!(vcpu->arch.vgic_cpu.live_lrs & (1UL << i)))
+				continue;
+
+		expect_mi |= (!(cpu_if->vgic_lr[i] & ICH_LR_HW) &&
+			      (cpu_if->vgic_lr[i] & ICH_LR_EOI));
+	}
+
+	if (expect_mi) {
+		cpu_if->vgic_misr  = read_gicreg(ICH_MISR_EL2);
+
+		if (cpu_if->vgic_misr & ICH_MISR_EOI) {
+			cpu_if->vgic_eisr = read_gicreg(ICH_EISR_EL2);
+		} else {
+			cpu_if->vgic_eisr = 0;
+		}
+	} else {
+		cpu_if->vgic_misr = 0;
+		cpu_if->vgic_eisr = 0;
+	}
+}
+
 void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
 {
 	struct vgic_v3_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v3;
@@ -150,8 +180,6 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
 		int i;
 		u32 max_lr_idx, nr_pri_bits;
 
-		cpu_if->vgic_misr  = read_gicreg(ICH_MISR_EL2);
-		cpu_if->vgic_eisr  = read_gicreg(ICH_EISR_EL2);
 		cpu_if->vgic_elrsr = read_gicreg(ICH_ELSR_EL2);
 
 		write_gicreg(0, ICH_HCR_EL2);
@@ -159,6 +187,8 @@ void __hyp_text __vgic_v3_save_state(struct kvm_vcpu *vcpu)
 		max_lr_idx = vtr_to_max_lr_idx(val);
 		nr_pri_bits = vtr_to_nr_pri_bits(val);
 
+		save_maint_int_state(vcpu, max_lr_idx + 1);
+
 		for (i = 0; i <= max_lr_idx; i++) {
 			if (vcpu->arch.vgic_cpu.live_lrs & (1UL << i))
 				cpu_if->vgic_lr[i] = __gic_v3_get_lr(i);
-- 
2.1.4



From jonathanh at nvidia.com  Wed Feb 17 08:43:42 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Wed, 17 Feb 2016 16:43:42 +0000
Subject: [PATCH] ARM64: Don't set the default console to ttyAMA0
Message-ID: <1455727422-10733-1-git-send-email-jonathanh@nvidia.com>

When booting Tegra210 with a minimal rootfs it may not be necessary to
specify any boot parameters via the kernel command line as information
for console is described via the "stdout-path" node the device-tree
blob. However, when there are no boot parameter specified, no output is
seen on the console in the case of Tegra210 and this is because the
default command line in the ARM64 defconfig specifies the console as
ttyAMA0 which takes precedence over the "stdout-path" node from
device-tree.

ttyAMAx is used for AMBA PL011 serial ports, but not all ARM64 platforms
use this serial driver. Therefore, remove the default command line
entry from the ARM64 defconfig to ensure that ttyAMA0 does not get set
as the default console if no kernel command line is specified.

Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
---
 arch/arm64/configs/defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d21631760ec7..caecb66188be 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -64,7 +64,6 @@ CONFIG_KSM=y
 CONFIG_TRANSPARENT_HUGEPAGE=y
 CONFIG_CMA=y
 CONFIG_XEN=y
-CONFIG_CMDLINE="console=ttyAMA0"
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 CONFIG_COMPAT=y
 CONFIG_CPU_IDLE=y
-- 
2.1.4



From ard.biesheuvel at linaro.org  Wed Feb 17 08:46:34 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 17 Feb 2016 17:46:34 +0100
Subject: [PATCH v2 1/2] arm64: mm: Mark .rodata as RO
In-Reply-To: <1455727274-16328-2-git-send-email-jeremy.linton@arm.com>
References: <1455727274-16328-1-git-send-email-jeremy.linton@arm.com>
 <1455727274-16328-2-git-send-email-jeremy.linton@arm.com>
Message-ID: <CAKv+Gu82_sXwRjZpqsLDMc_MVwZ3bRLodS4TEQRoRSKQCNQu3A@mail.gmail.com>

On 17 February 2016 at 17:41, Jeremy Linton <jeremy.linton at arm.com> wrote:
> Currently the .rodata section is actually still executable when DEBUG_RODATA
> is enabled. This changes that so the .rodata is actually read only, no execute.
>
> Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
> ---
>  arch/arm64/kernel/vmlinux.lds.S |  5 +++--
>  arch/arm64/mm/mmu.c             | 17 +++++++++++++----
>  2 files changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index 8f4fc2c..9208f53 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -114,8 +114,9 @@ SECTIONS
>                 *(.got)                 /* Global offset table          */
>         }
>
> -       RO_DATA(PAGE_SIZE)
> -       EXCEPTION_TABLE(8)
> +       ALIGN_DEBUG_RO_MIN(0)
> +       RO_DATA(PAGE_SIZE)              /* everything from this point to */
> +       EXCEPTION_TABLE(8)              /* _etext will be marked RO NX   */
>         NOTES
>
>         ALIGN_DEBUG_RO_MIN(PAGE_SIZE)
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index ab69a99..9aa5201 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -453,10 +453,18 @@ static void __init map_mem(pgd_t *pgd)
>  #ifdef CONFIG_DEBUG_RODATA
>  void mark_rodata_ro(void)
>  {
> -       create_mapping_late(__pa(_stext), (unsigned long)_stext,
> -                               (unsigned long)_etext - (unsigned long)_stext,
> -                               PAGE_KERNEL_ROX);
> +       unsigned long section_size;
>
> +       section_size = (unsigned long)__start_rodata - (unsigned long)_stext;
> +       create_mapping_late(__pa(_stext), (unsigned long)_stext,
> +                           section_size, PAGE_KERNEL_ROX);
> +       /*
> +        * mark .rodata as read only. Use _etext rather than __end_rodata to
> +        * cover NOTES and EXCEPTION_TABLE.
> +        */
> +       section_size = (unsigned long)_etext - (unsigned long)__start_rodata;
> +       create_mapping_late(__pa(__start_rodata), (unsigned long)__start_rodata,
> +                           section_size, PAGE_KERNEL_RO);
>  }
>  #endif
>
> @@ -486,7 +494,8 @@ static void __init map_kernel_chunk(pgd_t *pgd, void *va_start, void *va_end,
>  static void __init map_kernel(pgd_t *pgd)
>  {
>
> -       map_kernel_chunk(pgd, _stext, _etext, PAGE_KERNEL_EXEC);
> +       map_kernel_chunk(pgd, _stext, __start_rodata, PAGE_KERNEL_EXEC);
> +       map_kernel_chunk(pgd, __start_rodata, _etext, PAGE_KERNEL_EXEC);

Couldn't we map this non-exec from the start?

>         map_kernel_chunk(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC);
>         map_kernel_chunk(pgd, _data, _end, PAGE_KERNEL);
>
> --
> 2.4.3
>


From vladimir.murzin at arm.com  Wed Feb 17 08:48:44 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Wed, 17 Feb 2016 16:48:44 +0000
Subject: [PATCH v3 09/10] ARM: dts: introduce MPS2 AN385/AN386
In-Reply-To: <56C349E6.2000002@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-10-git-send-email-vladimir.murzin@arm.com>
 <7562697.iiO7rmWd7c@wuerfel> <56C349E6.2000002@arm.com>
Message-ID: <56C4A46C.50506@arm.com>

On 16/02/16 16:10, Vladimir Murzin wrote:
> On 16/02/16 11:01, Arnd Bergmann wrote:
>> On Tuesday 16 February 2016 10:08:14 Vladimir Murzin wrote:
>>> +
>>> +       ethernet at 40200000 {
>>> +               compatible = "smsc,lan9220", "smsc,lan9115";
>>> +               reg = <0x40200000 0x10000>;
>>> +               interrupts = <13>;
>>> +               interrupt-parent = <&nvic>;
>>> +               smsc,irq-active-high;
>>> +       };
>>> +};
>>> +
>>>
>>
>> This node seems slightly misplaced. Is there some external bus interface
>> that this is connected to? The address suggests that it should be somewhere
>> below the /soc node, and you probably want to list the external bus
>> interface with a "ranges" property that identifies the addresses visibile
>> there, and put the external chip under there.
>>
> 
> I might messed it up since the MAC/PHY connects to the same 16-bit
> interface as the 16MB PSRAM external memory and both connected via AHB.
> 
> Not sure how it should be expressed, so some help form DT camp would be
> appreciated.

Arnd,

Does following fixup address your point on where/how ethernet node
should be placed?

diff --git a/arch/arm/boot/dts/mps2-an385.dts b/arch/arm/boot/dts/an385.dts
index 976f86d..50c8d24 100644
--- a/arch/arm/boot/dts/mps2-an385.dts
+++ b/arch/arm/boot/dts/mps2-an385.dts
@@ -63,14 +63,10 @@
 		device_type = "memory";
 		reg = <0x21000000 0x1000000>;
 	};
+};

-	ethernet at 40200000 {
-		compatible = "smsc,lan9220", "smsc,lan9115";
-		reg = <0x40200000 0x10000>;
-		interrupts = <13>;
-		interrupt-parent = <&nvic>;
-		smsc,irq-active-high;
-	};
+&mb {
+	ranges = <0 0x40200000 0x10000>;
 };

 &uart0 {
diff --git a/arch/arm/boot/dts/mps2.dtsi b/arch/arm/boot/dts/mps2.dtsi
index 5d2c539..1673472 100644
--- a/arch/arm/boot/dts/mps2.dtsi
+++ b/arch/arm/boot/dts/mps2.dtsi
@@ -223,5 +223,21 @@
 				default-state = "off";
 			};
 		};
+
+	};
+
+	mb: smb {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		ethernet at 0 {
+			compatible = "smsc,lan9220", "smsc,lan9115";
+			reg = <0x0 0x10000>;
+			interrupts = <13>;
+			interrupt-parent = <&nvic>;
+			smsc,irq-active-high;
+		};
 	};
 };

Cheers
Vladimir

> 
> Cheers
> Vladimir
> 
>> 	Arnd
>>
>>
>>
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> 
> 



From matthias.bgg at gmail.com  Wed Feb 17 08:55:41 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Wed, 17 Feb 2016 17:55:41 +0100
Subject: [PATCH V5 04/11] soc: mediatek: PMIC wrap: split SoC specific
 init into callback
In-Reply-To: <56C0EB32.4080701@openwrt.org>
References: <1454841778-35529-1-git-send-email-blogic@openwrt.org>
 <1454841778-35529-5-git-send-email-blogic@openwrt.org>
 <56BC7674.9030706@gmail.com> <56C0EB32.4080701@openwrt.org>
Message-ID: <56C4A60D.30709@gmail.com>



On 14/02/16 22:01, John Crispin wrote:
>
>
> On 11/02/2016 12:54, Matthias Brugger wrote:
>>> diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c
>>> b/drivers/soc/mediatek/mtk-pmic-wrap.c
>>> index b22b664..e3bbee5 100644
>>> --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
>>> +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
>>> @@ -372,6 +372,7 @@ struct pmic_wrapper_type {
>>>        enum pwrap_type type;
>>>        u32 arb_en_all;
>>>        int (*init_reg_clock)(struct pmic_wrapper *wrp);
>>> +    int (*init_special)(struct pmic_wrapper *wrp);
>>
>> Nit:
>> I wonder if we can find a better name for the callback, as init_special
>> sounds quite generic to me.
>>
>> Thanks,
>> Matthias
>
> Hi,
>
> At first I considered enable_wrapper as the mt8135/8173 code seems to do
> just that. however mt2701 does an init of the ADC. So how about using
> init_soc_specific ?
>

sounds good :)


From ard.biesheuvel at linaro.org  Wed Feb 17 08:55:57 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 17 Feb 2016 17:55:57 +0100
Subject: [PATCH v2 1/2] arm64: mm: Mark .rodata as RO
In-Reply-To: <56C4A5AE.1090602@arm.com>
References: <1455727274-16328-1-git-send-email-jeremy.linton@arm.com>
 <1455727274-16328-2-git-send-email-jeremy.linton@arm.com>
 <CAKv+Gu82_sXwRjZpqsLDMc_MVwZ3bRLodS4TEQRoRSKQCNQu3A@mail.gmail.com>
 <56C4A5AE.1090602@arm.com>
Message-ID: <CAKv+Gu-TgwNHEeqe3+H1ork5N-pVROTrJ4FPzUBvUGo-Z9RehA@mail.gmail.com>

On 17 February 2016 at 17:54, Jeremy Linton <jeremy.linton at arm.com> wrote:
> On 02/17/2016 10:46 AM, Ard Biesheuvel wrote:
>>
>> On 17 February 2016 at 17:41, Jeremy Linton <jeremy.linton at arm.com> wrote:
>>>
>>> Currently the .rodata section is actually still executable when
>>> DEBUG_RODATA
>>> is enabled. This changes that so the .rodata is actually read only, no
>>> execute.
>>>
> (trimming)
>>>
>>>
>>> -       map_kernel_chunk(pgd, _stext, _etext, PAGE_KERNEL_EXEC);
>>> +       map_kernel_chunk(pgd, _stext, __start_rodata, PAGE_KERNEL_EXEC);
>>> +       map_kernel_chunk(pgd, __start_rodata, _etext, PAGE_KERNEL_EXEC);
>>
>>
>> Couldn't we map this non-exec from the start?
>
>
> Probably, Mark suggested that, but Kees seemed to have reasons not to.
> Either way, my opinion is that for that change to make sense we also need to
> always enable the functionality turned on by DEBUG_RODATA.
>

Actually, I think that was about mapping read-only, not non-exec. For
text patching and Kees's __ro_after_init stuff, the region would need
to be writable early on. But I don't think there is a reason to make
it executable.


From jeremy.linton at arm.com  Wed Feb 17 08:54:06 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Wed, 17 Feb 2016 10:54:06 -0600
Subject: [PATCH v2 1/2] arm64: mm: Mark .rodata as RO
In-Reply-To: <CAKv+Gu82_sXwRjZpqsLDMc_MVwZ3bRLodS4TEQRoRSKQCNQu3A@mail.gmail.com>
References: <1455727274-16328-1-git-send-email-jeremy.linton@arm.com>
 <1455727274-16328-2-git-send-email-jeremy.linton@arm.com>
 <CAKv+Gu82_sXwRjZpqsLDMc_MVwZ3bRLodS4TEQRoRSKQCNQu3A@mail.gmail.com>
Message-ID: <56C4A5AE.1090602@arm.com>

On 02/17/2016 10:46 AM, Ard Biesheuvel wrote:
> On 17 February 2016 at 17:41, Jeremy Linton <jeremy.linton at arm.com> wrote:
>> Currently the .rodata section is actually still executable when DEBUG_RODATA
>> is enabled. This changes that so the .rodata is actually read only, no execute.
>>
(trimming)
>>
>> -       map_kernel_chunk(pgd, _stext, _etext, PAGE_KERNEL_EXEC);
>> +       map_kernel_chunk(pgd, _stext, __start_rodata, PAGE_KERNEL_EXEC);
>> +       map_kernel_chunk(pgd, __start_rodata, _etext, PAGE_KERNEL_EXEC);
>
> Couldn't we map this non-exec from the start?

Probably, Mark suggested that, but Kees seemed to have reasons not to. 
Either way, my opinion is that for that change to make sense we also 
need to always enable the functionality turned on by DEBUG_RODATA.

>
>>          map_kernel_chunk(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC);
>>          map_kernel_chunk(pgd, _data, _end, PAGE_KERNEL);
>>
>> --
>> 2.4.3
>>
>



From arnd at arndb.de  Wed Feb 17 08:58:09 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 17:58:09 +0100
Subject: [PATCH v3 09/10] ARM: dts: introduce MPS2 AN385/AN386
In-Reply-To: <56C4A46C.50506@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <56C349E6.2000002@arm.com> <56C4A46C.50506@arm.com>
Message-ID: <7272921.u1gphgWzUn@wuerfel>

On Wednesday 17 February 2016 16:48:44 Vladimir Murzin wrote:
> On 16/02/16 16:10, Vladimir Murzin wrote:
> > On 16/02/16 11:01, Arnd Bergmann wrote:
> >> On Tuesday 16 February 2016 10:08:14 Vladimir Murzin wrote:
> >>> +
> >>> +       ethernet at 40200000 {
> >>> +               compatible = "smsc,lan9220", "smsc,lan9115";
> >>> +               reg = <0x40200000 0x10000>;
> >>> +               interrupts = <13>;
> >>> +               interrupt-parent = <&nvic>;
> >>> +               smsc,irq-active-high;
> >>> +       };
> >>> +};
> >>> +
> >>>
> >>
> >> This node seems slightly misplaced. Is there some external bus interface
> >> that this is connected to? The address suggests that it should be somewhere
> >> below the /soc node, and you probably want to list the external bus
> >> interface with a "ranges" property that identifies the addresses visibile
> >> there, and put the external chip under there.
> >>
> > 
> > I might messed it up since the MAC/PHY connects to the same 16-bit
> > interface as the 16MB PSRAM external memory and both connected via AHB.
> > 
> > Not sure how it should be expressed, so some help form DT camp would be
> > appreciated.
> 
> Does following fixup address your point on where/how ethernet node
> should be placed?



> diff --git a/arch/arm/boot/dts/mps2-an385.dts b/arch/arm/boot/dts/an385.dts
> index 976f86d..50c8d24 100644
> --- a/arch/arm/boot/dts/mps2-an385.dts
> +++ b/arch/arm/boot/dts/mps2-an385.dts
> @@ -63,14 +63,10 @@
>  		device_type = "memory";
>  		reg = <0x21000000 0x1000000>;
>  	};
> +};
> 
> -	ethernet at 40200000 {
> -		compatible = "smsc,lan9220", "smsc,lan9115";
> -		reg = <0x40200000 0x10000>;
> -		interrupts = <13>;
> -		interrupt-parent = <&nvic>;
> -		smsc,irq-active-high;
> -	};
> +&mb {
> +	ranges = <0 0x40200000 0x10000>;
>  };

How is the range being set here? The way I read this is:

"There is an external bus controller whose single CPU physical
address for MMIO is configurable. The chip always connects
a lan9220 device to it (as that is in the dtsi file) and
nothing else is possible, and the bootloader in this
version of the machine has configured the window to be
at address 0x40200000."

Is that what the hardware does?

I would have expected the opposite, with the external bus
interface being hardwired to one or more physical addresses
(more than one if you have multiple chip-selects), and
then allow to connect different devices, which are in the
.dts file, while the bus controller is defined in the
.dtsi file.

	Arnd


From mark.rutland at arm.com  Wed Feb 17 09:01:11 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 17 Feb 2016 17:01:11 +0000
Subject: KASAN issues with idle / hotplug area (was: Re: [PATCH v5sub1 7/8]
 arm64: move kernel image to base of vmalloc area)
In-Reply-To: <20160217143950.GC32647@leverpostej>
References: <CAKv+Gu-x6QPorWsPDP8bqAkmbasqzhqmP39HS=qprfGB4r8JLw@mail.gmail.com>
 <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
Message-ID: <20160217170110.GE32647@leverpostej>

On Wed, Feb 17, 2016 at 02:39:51PM +0000, Mark Rutland wrote:
> When we go down for idle, in __cpu_suspend_enter we stash some context
> to the stack (in assembly). The CPU may return from a cold state via
> cpu_resume, where we restore context from the stack.
> 
> However, after storing the context we call psci_suspend_finisher, which
> calls psci_cpu_suspend, which calls invoke_psci_fn_*. As
> psci_cpu_suspend and invoke_psci_fn_* are instrumented, they poison
> memory on function entrance, but we never perform the unpoisoning.
> 
> That was always the case for psci_suspend_finisher, so there was a
> latent issue that we were somehow avoiding. Perhaps we got luck with
> stack layout and never hit the poison.
> 
> I'm not sure how we fix that, as invoke_psci_fn_* may or may not return
> for arbitrary reasons (e.g. a CPU_SUSPEND_CALL may or may not return
> depending on whether an interrupt comes in at the right time).
> 
> Perhaps the simplest option is to not instrument invoke_psci_fn_* and
> psci_suspend_finisher. Do we have a per-function annotation to avoid
> KASAN instrumentation, like notrace? I need to investigate, but we may
> also need notrace for similar reasons.

I found __no_sanitize_address.

As an aside, could we rename that to nokasan? That would match the style
of notrace, is just as clear, and would make it far easier to write
consistent legible function prototypes...

Otherwise, I came up with the patch below, per the reasoning above.

It _changes_ the KASAN splats (I see errors in tick_program_event rather
than find_busiest_group), but doesn't seem to get rid of them. I'm not
sure if I've missed something, or if we also have another latent issue.

Ideas?

Mark.

---->8----
>From 8f7ae44d8f8862f5300483d45617b5bd05fc652f Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland at arm.com>
Date: Wed, 17 Feb 2016 15:38:22 +0000
Subject: [PATCH] arm64/psci: avoid KASAN splats with idle

When a CPU goes into a deep idle state, we store CPU context in
__cpu_suspend_enter, then call psci_suspend_finisher to invoke the
firmware. If we entered a deep idle state, we do not return directly,
and instead start cold, restoring state in cpu_resume.

Thus we may execute the prologue and body of psci_suspend_finisher and
the PSCI invocation function, but not their epilogue. When using KASAN
this means that we poison a region of shadow memory, but never unpoison
it. After we resume, subsequent stack accesses may hit the stale poison
values, leading to false positives from KASAN.

To avoid this, we must ensure that functions called after the context
save are not instrumented, and do not posion the shadow region, by
annotating them with __no_sanitize_address. As common inlines they may
call are not similarly annotated, and the compiler refuses to allow
function attribute mismatches, we must also avoid calls to such
functions.

ARM is not affected, as it does not support KASAN. When CONFIG_KASAN is
not selected, __no_sanitize_address expands to nothing, so the
annotation should not be harmful.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
---
 arch/arm64/kernel/psci.c | 14 ++++++++------
 drivers/firmware/psci.c  |  3 +++
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index f67f35b..8324ce8 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -32,12 +32,16 @@
 
 static DEFINE_PER_CPU_READ_MOSTLY(u32 *, psci_power_state);
 
+static phys_addr_t cpu_resume_phys;
+
 static int __maybe_unused cpu_psci_cpu_init_idle(unsigned int cpu)
 {
 	int i, ret, count = 0;
 	u32 *psci_states;
 	struct device_node *state_node, *cpu_node;
 
+	cpu_resume_phys = virt_to_phys(cpu_resume);
+
 	cpu_node = of_get_cpu_node(cpu, NULL);
 	if (!cpu_node)
 		return -ENODEV;
@@ -178,12 +182,10 @@ static int cpu_psci_cpu_kill(unsigned int cpu)
 }
 #endif
 
-static int psci_suspend_finisher(unsigned long index)
+__no_sanitize_address
+static int psci_suspend_finisher(unsigned long state)
 {
-	u32 *state = __this_cpu_read(psci_power_state);
-
-	return psci_ops.cpu_suspend(state[index - 1],
-				    virt_to_phys(cpu_resume));
+	return psci_ops.cpu_suspend(state, cpu_resume_phys);
 }
 
 static int __maybe_unused cpu_psci_cpu_suspend(unsigned long index)
@@ -200,7 +202,7 @@ static int __maybe_unused cpu_psci_cpu_suspend(unsigned long index)
 	if (!psci_power_state_loses_context(state[index - 1]))
 		ret = psci_ops.cpu_suspend(state[index - 1], 0);
 	else
-		ret = cpu_suspend(index, psci_suspend_finisher);
+		ret = cpu_suspend(state[index - 1], psci_suspend_finisher);
 
 	return ret;
 }
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index f25cd79..e4e8dc1 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -106,6 +106,7 @@ bool psci_power_state_is_valid(u32 state)
 	return !(state & ~valid_mask);
 }
 
+__no_sanitize_address
 static unsigned long __invoke_psci_fn_hvc(unsigned long function_id,
 			unsigned long arg0, unsigned long arg1,
 			unsigned long arg2)
@@ -116,6 +117,7 @@ static unsigned long __invoke_psci_fn_hvc(unsigned long function_id,
 	return res.a0;
 }
 
+__no_sanitize_address
 static unsigned long __invoke_psci_fn_smc(unsigned long function_id,
 			unsigned long arg0, unsigned long arg1,
 			unsigned long arg2)
@@ -148,6 +150,7 @@ static u32 psci_get_version(void)
 	return invoke_psci_fn(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
 }
 
+__no_sanitize_address
 static int psci_cpu_suspend(u32 state, unsigned long entry_point)
 {
 	int err;
-- 
1.9.1



From mark.rutland at arm.com  Wed Feb 17 09:02:47 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 17 Feb 2016 17:02:47 +0000
Subject: [PATCH v2 1/2] arm64: mm: Mark .rodata as RO
In-Reply-To: <CAKv+Gu-TgwNHEeqe3+H1ork5N-pVROTrJ4FPzUBvUGo-Z9RehA@mail.gmail.com>
References: <1455727274-16328-1-git-send-email-jeremy.linton@arm.com>
 <1455727274-16328-2-git-send-email-jeremy.linton@arm.com>
 <CAKv+Gu82_sXwRjZpqsLDMc_MVwZ3bRLodS4TEQRoRSKQCNQu3A@mail.gmail.com>
 <56C4A5AE.1090602@arm.com>
 <CAKv+Gu-TgwNHEeqe3+H1ork5N-pVROTrJ4FPzUBvUGo-Z9RehA@mail.gmail.com>
Message-ID: <20160217170246.GF32647@leverpostej>

On Wed, Feb 17, 2016 at 05:55:57PM +0100, Ard Biesheuvel wrote:
> On 17 February 2016 at 17:54, Jeremy Linton <jeremy.linton at arm.com> wrote:
> > On 02/17/2016 10:46 AM, Ard Biesheuvel wrote:
> >>
> >> On 17 February 2016 at 17:41, Jeremy Linton <jeremy.linton at arm.com> wrote:
> >>>
> >>> Currently the .rodata section is actually still executable when
> >>> DEBUG_RODATA
> >>> is enabled. This changes that so the .rodata is actually read only, no
> >>> execute.
> >>>
> > (trimming)
> >>>
> >>>
> >>> -       map_kernel_chunk(pgd, _stext, _etext, PAGE_KERNEL_EXEC);
> >>> +       map_kernel_chunk(pgd, _stext, __start_rodata, PAGE_KERNEL_EXEC);
> >>> +       map_kernel_chunk(pgd, __start_rodata, _etext, PAGE_KERNEL_EXEC);
> >>
> >>
> >> Couldn't we map this non-exec from the start?
> >
> >
> > Probably, Mark suggested that, but Kees seemed to have reasons not to.
> > Either way, my opinion is that for that change to make sense we also need to
> > always enable the functionality turned on by DEBUG_RODATA.
> >
> 
> Actually, I think that was about mapping read-only, not non-exec. For
> text patching and Kees's __ro_after_init stuff, the region would need
> to be writable early on. But I don't think there is a reason to make
> it executable.

Yup, we should be able to make it PAGE_KERNEL here, even if we can't
make it PAGE_KERNEL_RO.

Mark.


From mark.rutland at arm.com  Wed Feb 17 09:04:10 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 17 Feb 2016 17:04:10 +0000
Subject: [PATCH v2 2/2] arm64/mm: Add .rodata to kernel virtual memory
 boot notice
In-Reply-To: <1455727274-16328-3-git-send-email-jeremy.linton@arm.com>
References: <1455727274-16328-1-git-send-email-jeremy.linton@arm.com>
 <1455727274-16328-3-git-send-email-jeremy.linton@arm.com>
Message-ID: <20160217170409.GG32647@leverpostej>

On Wed, Feb 17, 2016 at 10:41:14AM -0600, Jeremy Linton wrote:
> Now that .rodata has differing permissions from .text
> display it in the mem_init banner as a seperate memory range.
> 
> Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
> ---
>  arch/arm64/mm/init.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

This looks fine, but I think it would be better to have this folded into
the prior patch.

Mark.

> 
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 5dd0831..41be7db 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -325,6 +325,7 @@ void __init mem_init(void)
>  		  "    memory  : 0x%16lx - 0x%16lx   (%6ld MB)\n"
>  		  "      .init : 0x%p" " - 0x%p" "   (%6ld KB)\n"
>  		  "      .text : 0x%p" " - 0x%p" "   (%6ld KB)\n"
> +		  "    .rodata : 0x%p" " - 0x%p" "   (%6ld KB)\n"
>  		  "      .data : 0x%p" " - 0x%p" "   (%6ld KB)\n",
>  #ifdef CONFIG_KASAN
>  		  MLG(KASAN_SHADOW_START, KASAN_SHADOW_END),
> @@ -341,7 +342,8 @@ void __init mem_init(void)
>  		  MLM(MODULES_VADDR, MODULES_END),
>  		  MLM(PAGE_OFFSET, (unsigned long)high_memory),
>  		  MLK_ROUNDUP(__init_begin, __init_end),
> -		  MLK_ROUNDUP(_text, _etext),
> +		  MLK_ROUNDUP(_text, __start_rodata),
> +		  MLK_ROUNDUP(__start_rodata, _etext),
>  		  MLK_ROUNDUP(_sdata, _edata));
>  
>  #undef MLK
> -- 
> 2.4.3
> 


From davem at davemloft.net  Wed Feb 17 09:05:17 2016
From: davem at davemloft.net (David Miller)
Date: Wed, 17 Feb 2016 12:05:17 -0500 (EST)
Subject: [PATCH net-next v2 1/4] drivers: net: xgene: Add support for
 Classifier engine
In-Reply-To: <1455327425-8294-2-git-send-email-isubramanian@apm.com>
References: <1455327425-8294-1-git-send-email-isubramanian@apm.com>
 <1455327425-8294-2-git-send-email-isubramanian@apm.com>
Message-ID: <20160217.120517.1874370262056055172.davem@davemloft.net>

From: Iyappan Subramanian <isubramanian at apm.com>
Date: Fri, 12 Feb 2016 17:37:02 -0800

> +static void xgene_cle_dn_to_hw(struct xgene_cle_ptree_ewdn *dn,
> +			       u32 *buf, u32 jb)
> +{
> +	u32 i, j = 0;
> +	u32 npp;
> +	struct xgene_cle_ptree_branch *br;

Please order local variables from longest to shortest line (reverse christmas
tree format).

Please address this for your entire submission.

Thank you.


From matthias.bgg at gmail.com  Wed Feb 17 09:05:57 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Wed, 17 Feb 2016 18:05:57 +0100
Subject: [PATCH 2/3] thermal: Add Mediatek thermal controller support
In-Reply-To: <CAGS+omArr0_-ziBXWjEcKS0bqnruNzZc2aq2s3zkghUC7_HfGw@mail.gmail.com>
References: <1448883753-19068-1-git-send-email-s.hauer@pengutronix.de>
 <1448883753-19068-3-git-send-email-s.hauer@pengutronix.de>
 <20151217193332.GB7999@localhost.localdomain>
 <20160104141940.GI13058@pengutronix.de>
 <20160119072917.GA13237@pengutronix.de> <1454295246.22151.6.camel@mtksdaap41>
 <CAGS+omD9U8tKmb02d_gMMAGX18MJZhz0RrugpBK2EuqgZrBy6g@mail.gmail.com>
 <CAGS+omArr0_-ziBXWjEcKS0bqnruNzZc2aq2s3zkghUC7_HfGw@mail.gmail.com>
Message-ID: <56C4A875.6080908@gmail.com>



On 15/02/16 03:14, Daniel Kurtz wrote:
> On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz at chromium.org> wrote:
>> Hi Eduardo, Sascha,
>>
>> On Mon, Feb 1, 2016 at 10:54 AM, Eddie Huang <eddie.huang at mediatek.com> wrote:
>>>
>>> On Tue, 2016-01-19 at 15:29 +0800, Sascha Hauer wrote:
>>>> Eduardo,
>>>>
>>>> On Mon, Jan 04, 2016 at 03:19:40PM +0100, Sascha Hauer wrote:
>>>>> Hi Eduardo,
>>>>>
>>>>>>
>>>>>> That should remove the policy of computing the maximum from this driver.
>>>>>> Please have a look on the work being done [1] to add grouping and
>>>>>> aggregation of thermal zones. With that in place, you should be a matter
>>>>>> of configuring the grouping and selecting max as the aggregation function,
>>>>>> from the thermal core, instead in the driver. Which should give the
>>>>>> system engineer, more flexibility to compose whatever policy based on
>>>>>> the exposed sensors.
>>>>>
>>>>> I think the aggregation of thermal zones is quite useful when it comes
>>>>> to putting different chips together to a system. I am not so sure how
>>>>> useful it is to expose different thermal zones of a single SoC to the
>>>>> device tree.
>>>>> Currently the only control knob we have is the CPU frequency. When any
>>>>> of the sensors on the SoC gets too hot then the only thing we can do is
>>>>> to decrease the CPU frequency. This does not leave much space for
>>>>> configuration in the device tree.
>>>>> What I need to be able is to attach multiple sensors to one thermal
>>>>> zone. The aggregation patch series only partly solves that and I think
>>>>> is inconsistent, but I commented on the series directly.
>>>>
>>>> Any input on this? I really like to get this driver upstream as it is
>>>> currently blocking other Mediatek drivers.
>>>>
>>>
>>> Hi Eduardo,
>>>
>>> Do you have any comment about Sascha's response ? We really hope get
>>> your comment since Mediatek thermal driver already reviewed in public
>>> over half years, and we have other patches [0] [1] depend on thermal
>>> driver.
>>>
>>> [0]:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
>>> [1]:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
>>
>> Friendly ping on the Mediatek thermal driver.
>> The "EFUSE" dependency has now landed in v4.5-rc4.
>
> Actually, it landed in char-misc-next, not v4.5-rc4.
>
>> So, AFAICT, the only thing left that may be blocking landing Mediatek
>> thermal driver is resolution of this discussion about thermal zones.
>> Can we kindly resolve this soon so we have a chance to land it in v4.6.
>>


I think the problem is, that Eduardo wants to see the hierachical 
thermal zones being used. But there is still a discussion ongoing [1].

[1] https://patchwork.kernel.org/patch/7699971/


From mark.rutland at arm.com  Wed Feb 17 09:16:17 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 17 Feb 2016 17:16:17 +0000
Subject: [PATCH 1/4] arm64: Broadcom Vulcan support
In-Reply-To: <1455389195-31870-2-git-send-email-jchandra@broadcom.com>
References: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
 <1455389195-31870-2-git-send-email-jchandra@broadcom.com>
Message-ID: <20160217171616.GH32647@leverpostej>

Hi,

On Sun, Feb 14, 2016 at 12:16:32AM +0530, Jayachandran C wrote:
> From: Zi Shen Lim <zlim at broadcom.com>

> +	compatible = "brcm,vulcan-eval", "brcm,vulcan";

You use "brcm,vulcan" as the compatible string for both the platform and
the CPU nodes. You need different strings.

> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x00000000 0x80000000 0x0 0x80000000>,  /* 2G @ 2G  */
> +		      <0x00000008 0x80000000 0x0 0x80000000>;  /* 2G @ 34G */
> +	};

> +/memreserve/ 0x80000000 0x00010000;

What is this for?

> +
> +/ {
> +	model = "Broadcom Vulcan";
> +	compatible = "brcm,vulcan";

As above, it doesn't make sense to have the same compatible string for
both the platform as a whole and the CPU.

> +			device_type = "cpu";
> +			compatible = "brcm,vulcan", "arm,armv8";
> +			reg = <0x0 0x0>;
> +			enable-method = "psci";
> +		};

Thanks,
Mark.


From xhnjupt at gmail.com  Wed Feb 17 09:13:08 2016
From: xhnjupt at gmail.com (Han Xu)
Date: Thu, 18 Feb 2016 01:13:08 +0800
Subject: [PATCH v4 1/7] mtd: spi-nor: fsl-quadspi: add big-endian support
In-Reply-To: <1453793041-35868-1-git-send-email-yao.yuan@freescale.com>
References: <1453793041-35868-1-git-send-email-yao.yuan@freescale.com>
Message-ID: <20160217171308.GB16812@shlinux2>

On Tue, Jan 26, 2016 at 03:23:55PM +0800, Yuan Yao wrote:
> Add R/W functions for big- or little-endian registers:
> The qSPI controller's endian is independent of the CPU core's endian.
> So far, the qSPI have two versions for big-endian and little-endian.
> 
> Signed-off-by: Yuan Yao <yao.yuan at nxp.com>
> Acked-by: Han xu <han.xu at freescale.com>
> ---
> Changed in v4:
> No changes.
> 
> Changed in v3:
> Update my email to <yao.yuan at nxp.com>
> 
> Changed in v2:
> Rebase to the lastest code.
> ---
>  drivers/mtd/spi-nor/fsl-quadspi.c | 157 +++++++++++++++++++++++---------------
>  1 file changed, 97 insertions(+), 60 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
> index 54640f1..04e8a93 100644
> --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> @@ -275,6 +275,7 @@ struct fsl_qspi {
>  	u32 clk_rate;
>  	unsigned int chip_base_addr; /* We may support two chips. */
>  	bool has_second_chip;
> +	bool big_endian;
>  	struct mutex lock;
>  	struct pm_qos_request pm_qos_req;
>  };
> @@ -300,6 +301,28 @@ static inline int needs_wakeup_wait_mode(struct fsl_qspi *q)
>  }
>  
>  /*
> + * R/W functions for big- or little-endian registers:
> + * The qSPI controller's endian is independent of the CPU core's endian.
> + * So far, although the CPU core is little-endian but the qSPI have two
> + * versions for big-endian and little-endian.
> + */
> +static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem *addr)
> +{
> +	if (q->big_endian)
> +		iowrite32be(val, addr);
> +	else
> +		iowrite32(val, addr);
> +}
> +
> +static u32 qspi_readl(struct fsl_qspi *q, void __iomem *addr)
> +{
> +	if (q->big_endian)
> +		return ioread32be(addr);
> +	else
> +		return ioread32(addr);
> +}
> +
> +/*
>   * An IC bug makes us to re-arrange the 32-bit data.
>   * The following chips, such as IMX6SLX, have fixed this bug.
>   */
> @@ -310,14 +333,14 @@ static inline u32 fsl_qspi_endian_xchg(struct fsl_qspi *q, u32 a)
>  
>  static inline void fsl_qspi_unlock_lut(struct fsl_qspi *q)
>  {
> -	writel(QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
> -	writel(QUADSPI_LCKER_UNLOCK, q->iobase + QUADSPI_LCKCR);
> +	qspi_writel(q, QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
> +	qspi_writel(q, QUADSPI_LCKER_UNLOCK, q->iobase + QUADSPI_LCKCR);
>  }
>  
>  static inline void fsl_qspi_lock_lut(struct fsl_qspi *q)
>  {
> -	writel(QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
> -	writel(QUADSPI_LCKER_LOCK, q->iobase + QUADSPI_LCKCR);
> +	qspi_writel(q, QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
> +	qspi_writel(q, QUADSPI_LCKER_LOCK, q->iobase + QUADSPI_LCKCR);
>  }
>  
>  static irqreturn_t fsl_qspi_irq_handler(int irq, void *dev_id)
> @@ -326,8 +349,8 @@ static irqreturn_t fsl_qspi_irq_handler(int irq, void *dev_id)
>  	u32 reg;
>  
>  	/* clear interrupt */
> -	reg = readl(q->iobase + QUADSPI_FR);
> -	writel(reg, q->iobase + QUADSPI_FR);
> +	reg = qspi_readl(q, q->iobase + QUADSPI_FR);
> +	qspi_writel(q, reg, q->iobase + QUADSPI_FR);
>  
>  	if (reg & QUADSPI_FR_TFF_MASK)
>  		complete(&q->c);
> @@ -348,7 +371,7 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
>  
>  	/* Clear all the LUT table */
>  	for (i = 0; i < QUADSPI_LUT_NUM; i++)
> -		writel(0, base + QUADSPI_LUT_BASE + i * 4);
> +		qspi_writel(q, 0, base + QUADSPI_LUT_BASE + i * 4);
>  
>  	/* Quad Read */
>  	lut_base = SEQID_QUAD_READ * 4;
> @@ -364,14 +387,15 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
>  		dummy = 8;
>  	}
>  
> -	writel(LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
> +	qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
>  			base + QUADSPI_LUT(lut_base));
> -	writel(LUT0(DUMMY, PAD1, dummy) | LUT1(FSL_READ, PAD4, rxfifo),
> +	qspi_writel(q, LUT0(DUMMY, PAD1, dummy) | LUT1(FSL_READ, PAD4, rxfifo),
>  			base + QUADSPI_LUT(lut_base + 1));
>  
>  	/* Write enable */
>  	lut_base = SEQID_WREN * 4;
> -	writel(LUT0(CMD, PAD1, SPINOR_OP_WREN), base + QUADSPI_LUT(lut_base));
> +	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_WREN),
> +			base + QUADSPI_LUT(lut_base));
>  
>  	/* Page Program */
>  	lut_base = SEQID_PP * 4;
> @@ -385,13 +409,15 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
>  		addrlen = ADDR32BIT;
>  	}
>  
> -	writel(LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
> +	qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
>  			base + QUADSPI_LUT(lut_base));
> -	writel(LUT0(FSL_WRITE, PAD1, 0), base + QUADSPI_LUT(lut_base + 1));
> +	qspi_writel(q, LUT0(FSL_WRITE, PAD1, 0),
> +			base + QUADSPI_LUT(lut_base + 1));
>  
>  	/* Read Status */
>  	lut_base = SEQID_RDSR * 4;
> -	writel(LUT0(CMD, PAD1, SPINOR_OP_RDSR) | LUT1(FSL_READ, PAD1, 0x1),
> +	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_RDSR) |
> +			LUT1(FSL_READ, PAD1, 0x1),
>  			base + QUADSPI_LUT(lut_base));
>  
>  	/* Erase a sector */
> @@ -400,40 +426,46 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
>  	cmd = q->nor[0].erase_opcode;
>  	addrlen = q->nor_size <= SZ_16M ? ADDR24BIT : ADDR32BIT;
>  
> -	writel(LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
> +	qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
>  			base + QUADSPI_LUT(lut_base));
>  
>  	/* Erase the whole chip */
>  	lut_base = SEQID_CHIP_ERASE * 4;
> -	writel(LUT0(CMD, PAD1, SPINOR_OP_CHIP_ERASE),
> +	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_CHIP_ERASE),
>  			base + QUADSPI_LUT(lut_base));
>  
>  	/* READ ID */
>  	lut_base = SEQID_RDID * 4;
> -	writel(LUT0(CMD, PAD1, SPINOR_OP_RDID) | LUT1(FSL_READ, PAD1, 0x8),
> +	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_RDID) |
> +			LUT1(FSL_READ, PAD1, 0x8),
>  			base + QUADSPI_LUT(lut_base));
>  
>  	/* Write Register */
>  	lut_base = SEQID_WRSR * 4;
> -	writel(LUT0(CMD, PAD1, SPINOR_OP_WRSR) | LUT1(FSL_WRITE, PAD1, 0x2),
> +	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_WRSR) |
> +			LUT1(FSL_WRITE, PAD1, 0x2),
>  			base + QUADSPI_LUT(lut_base));
>  
>  	/* Read Configuration Register */
>  	lut_base = SEQID_RDCR * 4;
> -	writel(LUT0(CMD, PAD1, SPINOR_OP_RDCR) | LUT1(FSL_READ, PAD1, 0x1),
> +	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_RDCR) |
> +			LUT1(FSL_READ, PAD1, 0x1),
>  			base + QUADSPI_LUT(lut_base));
>  
>  	/* Write disable */
>  	lut_base = SEQID_WRDI * 4;
> -	writel(LUT0(CMD, PAD1, SPINOR_OP_WRDI), base + QUADSPI_LUT(lut_base));
> +	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_WRDI),
> +			base + QUADSPI_LUT(lut_base));
>  
>  	/* Enter 4 Byte Mode (Micron) */
>  	lut_base = SEQID_EN4B * 4;
> -	writel(LUT0(CMD, PAD1, SPINOR_OP_EN4B), base + QUADSPI_LUT(lut_base));
> +	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_EN4B),
> +			base + QUADSPI_LUT(lut_base));
>  
>  	/* Enter 4 Byte Mode (Spansion) */
>  	lut_base = SEQID_BRWR * 4;
> -	writel(LUT0(CMD, PAD1, SPINOR_OP_BRWR), base + QUADSPI_LUT(lut_base));
> +	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_BRWR),
> +			base + QUADSPI_LUT(lut_base));
>  
>  	fsl_qspi_lock_lut(q);
>  }
> @@ -488,15 +520,16 @@ fsl_qspi_runcmd(struct fsl_qspi *q, u8 cmd, unsigned int addr, int len)
>  			q->chip_base_addr, addr, len, cmd);
>  
>  	/* save the reg */
> -	reg = readl(base + QUADSPI_MCR);
> +	reg = qspi_readl(q, base + QUADSPI_MCR);
>  
> -	writel(q->memmap_phy + q->chip_base_addr + addr, base + QUADSPI_SFAR);
> -	writel(QUADSPI_RBCT_WMRK_MASK | QUADSPI_RBCT_RXBRD_USEIPS,
> +	qspi_writel(q, q->memmap_phy + q->chip_base_addr + addr,
> +			base + QUADSPI_SFAR);
> +	qspi_writel(q, QUADSPI_RBCT_WMRK_MASK | QUADSPI_RBCT_RXBRD_USEIPS,
>  			base + QUADSPI_RBCT);
> -	writel(reg | QUADSPI_MCR_CLR_RXF_MASK, base + QUADSPI_MCR);
> +	qspi_writel(q, reg | QUADSPI_MCR_CLR_RXF_MASK, base + QUADSPI_MCR);
>  
>  	do {
> -		reg2 = readl(base + QUADSPI_SR);
> +		reg2 = qspi_readl(q, base + QUADSPI_SR);
>  		if (reg2 & (QUADSPI_SR_IP_ACC_MASK | QUADSPI_SR_AHB_ACC_MASK)) {
>  			udelay(1);
>  			dev_dbg(q->dev, "The controller is busy, 0x%x\n", reg2);
> @@ -507,21 +540,22 @@ fsl_qspi_runcmd(struct fsl_qspi *q, u8 cmd, unsigned int addr, int len)
>  
>  	/* trigger the LUT now */
>  	seqid = fsl_qspi_get_seqid(q, cmd);
> -	writel((seqid << QUADSPI_IPCR_SEQID_SHIFT) | len, base + QUADSPI_IPCR);
> +	qspi_writel(q, (seqid << QUADSPI_IPCR_SEQID_SHIFT) | len,
> +			base + QUADSPI_IPCR);
>  
>  	/* Wait for the interrupt. */
>  	if (!wait_for_completion_timeout(&q->c, msecs_to_jiffies(1000))) {
>  		dev_err(q->dev,
>  			"cmd 0x%.2x timeout, addr@%.8x, FR:0x%.8x, SR:0x%.8x\n",
> -			cmd, addr, readl(base + QUADSPI_FR),
> -			readl(base + QUADSPI_SR));
> +			cmd, addr, qspi_readl(q, base + QUADSPI_FR),
> +			qspi_readl(q, base + QUADSPI_SR));
>  		err = -ETIMEDOUT;
>  	} else {
>  		err = 0;
>  	}
>  
>  	/* restore the MCR */
> -	writel(reg, base + QUADSPI_MCR);
> +	qspi_writel(q, reg, base + QUADSPI_MCR);
>  
>  	return err;
>  }
> @@ -533,7 +567,7 @@ static void fsl_qspi_read_data(struct fsl_qspi *q, int len, u8 *rxbuf)
>  	int i = 0;
>  
>  	while (len > 0) {
> -		tmp = readl(q->iobase + QUADSPI_RBDR + i * 4);
> +		tmp = qspi_readl(q, q->iobase + QUADSPI_RBDR + i * 4);
>  		tmp = fsl_qspi_endian_xchg(q, tmp);
>  		dev_dbg(q->dev, "chip addr:0x%.8x, rcv:0x%.8x\n",
>  				q->chip_base_addr, tmp);
> @@ -561,9 +595,9 @@ static inline void fsl_qspi_invalid(struct fsl_qspi *q)
>  {
>  	u32 reg;
>  
> -	reg = readl(q->iobase + QUADSPI_MCR);
> +	reg = qspi_readl(q, q->iobase + QUADSPI_MCR);
>  	reg |= QUADSPI_MCR_SWRSTHD_MASK | QUADSPI_MCR_SWRSTSD_MASK;
> -	writel(reg, q->iobase + QUADSPI_MCR);
> +	qspi_writel(q, reg, q->iobase + QUADSPI_MCR);
>  
>  	/*
>  	 * The minimum delay : 1 AHB + 2 SFCK clocks.
> @@ -572,7 +606,7 @@ static inline void fsl_qspi_invalid(struct fsl_qspi *q)
>  	udelay(1);
>  
>  	reg &= ~(QUADSPI_MCR_SWRSTHD_MASK | QUADSPI_MCR_SWRSTSD_MASK);
> -	writel(reg, q->iobase + QUADSPI_MCR);
> +	qspi_writel(q, reg, q->iobase + QUADSPI_MCR);
>  }
>  
>  static int fsl_qspi_nor_write(struct fsl_qspi *q, struct spi_nor *nor,
> @@ -586,20 +620,20 @@ static int fsl_qspi_nor_write(struct fsl_qspi *q, struct spi_nor *nor,
>  		q->chip_base_addr, to, count);
>  
>  	/* clear the TX FIFO. */
> -	tmp = readl(q->iobase + QUADSPI_MCR);
> -	writel(tmp | QUADSPI_MCR_CLR_TXF_MASK, q->iobase + QUADSPI_MCR);
> +	tmp = qspi_readl(q, q->iobase + QUADSPI_MCR);
> +	qspi_writel(q, tmp | QUADSPI_MCR_CLR_TXF_MASK, q->iobase + QUADSPI_MCR);
>  
>  	/* fill the TX data to the FIFO */
>  	for (j = 0, i = ((count + 3) / 4); j < i; j++) {
>  		tmp = fsl_qspi_endian_xchg(q, *txbuf);
> -		writel(tmp, q->iobase + QUADSPI_TBDR);
> +		qspi_writel(q, tmp, q->iobase + QUADSPI_TBDR);
>  		txbuf++;
>  	}
>  
>  	/* fill the TXFIFO upto 16 bytes for i.MX7d */
>  	if (needs_fill_txfifo(q))
>  		for (; i < 4; i++)
> -			writel(tmp, q->iobase + QUADSPI_TBDR);
> +			qspi_writel(q, tmp, q->iobase + QUADSPI_TBDR);
>  
>  	/* Trigger it */
>  	ret = fsl_qspi_runcmd(q, opcode, to, count);
> @@ -615,10 +649,10 @@ static void fsl_qspi_set_map_addr(struct fsl_qspi *q)
>  	int nor_size = q->nor_size;
>  	void __iomem *base = q->iobase;
>  
> -	writel(nor_size + q->memmap_phy, base + QUADSPI_SFA1AD);
> -	writel(nor_size * 2 + q->memmap_phy, base + QUADSPI_SFA2AD);
> -	writel(nor_size * 3 + q->memmap_phy, base + QUADSPI_SFB1AD);
> -	writel(nor_size * 4 + q->memmap_phy, base + QUADSPI_SFB2AD);
> +	qspi_writel(q, nor_size + q->memmap_phy, base + QUADSPI_SFA1AD);
> +	qspi_writel(q, nor_size * 2 + q->memmap_phy, base + QUADSPI_SFA2AD);
> +	qspi_writel(q, nor_size * 3 + q->memmap_phy, base + QUADSPI_SFB1AD);
> +	qspi_writel(q, nor_size * 4 + q->memmap_phy, base + QUADSPI_SFB2AD);
>  }
>  
>  /*
> @@ -640,24 +674,26 @@ static void fsl_qspi_init_abh_read(struct fsl_qspi *q)
>  	int seqid;
>  
>  	/* AHB configuration for access buffer 0/1/2 .*/
> -	writel(QUADSPI_BUFXCR_INVALID_MSTRID, base + QUADSPI_BUF0CR);
> -	writel(QUADSPI_BUFXCR_INVALID_MSTRID, base + QUADSPI_BUF1CR);
> -	writel(QUADSPI_BUFXCR_INVALID_MSTRID, base + QUADSPI_BUF2CR);
> +	qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base + QUADSPI_BUF0CR);
> +	qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base + QUADSPI_BUF1CR);
> +	qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base + QUADSPI_BUF2CR);
>  	/*
>  	 * Set ADATSZ with the maximum AHB buffer size to improve the
>  	 * read performance.
>  	 */
> -	writel(QUADSPI_BUF3CR_ALLMST_MASK | ((q->devtype_data->ahb_buf_size / 8)
> -			<< QUADSPI_BUF3CR_ADATSZ_SHIFT), base + QUADSPI_BUF3CR);
> +	qspi_writel(q, QUADSPI_BUF3CR_ALLMST_MASK |
> +			((q->devtype_data->ahb_buf_size / 8)
> +			<< QUADSPI_BUF3CR_ADATSZ_SHIFT),
> +			base + QUADSPI_BUF3CR);
>  
>  	/* We only use the buffer3 */
> -	writel(0, base + QUADSPI_BUF0IND);
> -	writel(0, base + QUADSPI_BUF1IND);
> -	writel(0, base + QUADSPI_BUF2IND);
> +	qspi_writel(q, 0, base + QUADSPI_BUF0IND);
> +	qspi_writel(q, 0, base + QUADSPI_BUF1IND);
> +	qspi_writel(q, 0, base + QUADSPI_BUF2IND);
>  
>  	/* Set the default lut sequence for AHB Read. */
>  	seqid = fsl_qspi_get_seqid(q, q->nor[0].read_opcode);
> -	writel(seqid << QUADSPI_BFGENCR_SEQID_SHIFT,
> +	qspi_writel(q, seqid << QUADSPI_BFGENCR_SEQID_SHIFT,
>  		q->iobase + QUADSPI_BFGENCR);
>  }
>  
> @@ -713,7 +749,7 @@ static int fsl_qspi_nor_setup(struct fsl_qspi *q)
>  		return ret;
>  
>  	/* Reset the module */
> -	writel(QUADSPI_MCR_SWRSTSD_MASK | QUADSPI_MCR_SWRSTHD_MASK,
> +	qspi_writel(q, QUADSPI_MCR_SWRSTSD_MASK | QUADSPI_MCR_SWRSTHD_MASK,
>  		base + QUADSPI_MCR);
>  	udelay(1);
>  
> @@ -721,24 +757,24 @@ static int fsl_qspi_nor_setup(struct fsl_qspi *q)
>  	fsl_qspi_init_lut(q);
>  
>  	/* Disable the module */
> -	writel(QUADSPI_MCR_MDIS_MASK | QUADSPI_MCR_RESERVED_MASK,
> +	qspi_writel(q, QUADSPI_MCR_MDIS_MASK | QUADSPI_MCR_RESERVED_MASK,
>  			base + QUADSPI_MCR);
>  
> -	reg = readl(base + QUADSPI_SMPR);
> -	writel(reg & ~(QUADSPI_SMPR_FSDLY_MASK
> +	reg = qspi_readl(q, base + QUADSPI_SMPR);
> +	qspi_writel(q, reg & ~(QUADSPI_SMPR_FSDLY_MASK
>  			| QUADSPI_SMPR_FSPHS_MASK
>  			| QUADSPI_SMPR_HSENA_MASK
>  			| QUADSPI_SMPR_DDRSMP_MASK), base + QUADSPI_SMPR);
>  
>  	/* Enable the module */
> -	writel(QUADSPI_MCR_RESERVED_MASK | QUADSPI_MCR_END_CFG_MASK,
> +	qspi_writel(q, QUADSPI_MCR_RESERVED_MASK | QUADSPI_MCR_END_CFG_MASK,
>  			base + QUADSPI_MCR);
>  
>  	/* clear all interrupt status */
> -	writel(0xffffffff, q->iobase + QUADSPI_FR);
> +	qspi_writel(q, 0xffffffff, q->iobase + QUADSPI_FR);
>  
>  	/* enable the interrupt */
> -	writel(QUADSPI_RSER_TFIE, q->iobase + QUADSPI_RSER);
> +	qspi_writel(q, QUADSPI_RSER_TFIE, q->iobase + QUADSPI_RSER);
>  
>  	return 0;
>  }
> @@ -954,6 +990,7 @@ static int fsl_qspi_probe(struct platform_device *pdev)
>  	if (IS_ERR(q->iobase))
>  		return PTR_ERR(q->iobase);
>  
> +	q->big_endian = of_property_read_bool(np, "big-endian");
>  	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>  					"QuadSPI-memory");
>  	if (!devm_request_mem_region(dev, res->start, resource_size(res),
> @@ -1101,8 +1138,8 @@ static int fsl_qspi_remove(struct platform_device *pdev)
>  	}
>  
>  	/* disable the hardware */
> -	writel(QUADSPI_MCR_MDIS_MASK, q->iobase + QUADSPI_MCR);
> -	writel(0x0, q->iobase + QUADSPI_RSER);
> +	qspi_writel(q, QUADSPI_MCR_MDIS_MASK, q->iobase + QUADSPI_MCR);
> +	qspi_writel(q, 0x0, q->iobase + QUADSPI_RSER);
>  
>  	mutex_destroy(&q->lock);
>  
> -- 
> 2.1.0.27.g96db324
> 
> 
Acked-by: Han xu <han.xu at nxp.com>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


From mark.rutland at arm.com  Wed Feb 17 09:17:01 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 17 Feb 2016 17:17:01 +0000
Subject: [PATCH 2/4] dt-bindings: Add documentation for Broadcom Vulcan
In-Reply-To: <1455389195-31870-3-git-send-email-jchandra@broadcom.com>
References: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
 <1455389195-31870-3-git-send-email-jchandra@broadcom.com>
Message-ID: <20160217171700.GI32647@leverpostej>

On Sun, Feb 14, 2016 at 12:16:33AM +0530, Jayachandran C wrote:
> Update arm/cpus.txt to add brcm,vulcan CPU. Add documentation
> for Broadcom vulcan boards in arm/bcm/brcm,vulcan.txt
> 
> Signed-off-by: Jayachandran C <jchandra at broadcom.com>
> ---
>  Documentation/devicetree/bindings/arm/bcm/brcm,vulcan.txt | 9 +++++++++
>  Documentation/devicetree/bindings/arm/cpus.txt            | 1 +
>  2 files changed, 10 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,vulcan.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,vulcan.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,vulcan.txt
> new file mode 100644
> index 0000000..dac9eb5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,vulcan.txt
> @@ -0,0 +1,9 @@
> +Broadcom Vulcan device tree bindings
> +------------------------------------
> +
> +Boards with Broadcom Vulcan shall have the following properties:
> +
> +Required root node property:
> +
> +Vulcan Evaluation Board
> +compatible = "brcm,vulcan-eval", "brcm,vulcan";

You can't use "brcm,vulcan" as both a board and CPU string.

Please come up with different strings.

Mark.

> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> index ae9be07..bc43ad7 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -167,6 +167,7 @@ nodes to be present and contain the properties described below.
>  			    "arm,cortex-r5"
>  			    "arm,cortex-r7"
>  			    "brcm,brahma-b15"
> +			    "brcm,vulcan"
>  			    "cavium,thunder"
>  			    "faraday,fa526"
>  			    "intel,sa110"
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From ard.biesheuvel at linaro.org  Wed Feb 17 09:17:46 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 17 Feb 2016 18:17:46 +0100
Subject: [PATCH v2 1/2] arm64: mm: Enable CONT_SIZE aligned sections for
 64k page kernels.
In-Reply-To: <1455726594-16104-2-git-send-email-jeremy.linton@arm.com>
References: <1455726594-16104-1-git-send-email-jeremy.linton@arm.com>
 <1455726594-16104-2-git-send-email-jeremy.linton@arm.com>
Message-ID: <CAKv+Gu8kN_bFfXsgCTyaZXTfuU7UAP9U93SiqvXz0bPRu7D=bg@mail.gmail.com>

On 17 February 2016 at 17:29, Jeremy Linton <jeremy.linton at arm.com> wrote:
> This change allows ALIGN_RODATA for 16k and 64k kernels.
> In the case of 64k kernels it actually aligns to the CONT_SIZE

... and 16k kernels ...

> rather than the SECTION_SIZE (which is 512M). This makes it generally
> more useful, especially for CONT enabled kernels.
>
> Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>

It probably makes sense to mention here that the alignment is 2 MB for
all page sizes.

Reviewed-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

> ---
>  arch/arm64/Kconfig.debug        | 12 ++++++------
>  arch/arm64/kernel/vmlinux.lds.S | 11 ++++++-----
>  2 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> index e13c4bf..65705ee 100644
> --- a/arch/arm64/Kconfig.debug
> +++ b/arch/arm64/Kconfig.debug
> @@ -59,15 +59,15 @@ config DEBUG_RODATA
>            If in doubt, say Y
>
>  config DEBUG_ALIGN_RODATA
> -       depends on DEBUG_RODATA && ARM64_4K_PAGES
> +       depends on DEBUG_RODATA
>         bool "Align linker sections up to SECTION_SIZE"
>         help
>           If this option is enabled, sections that may potentially be marked as
> -         read only or non-executable will be aligned up to the section size of
> -         the kernel. This prevents sections from being split into pages and
> -         avoids a potential TLB penalty. The downside is an increase in
> -         alignment and potentially wasted space. Turn on this option if
> -         performance is more important than memory pressure.
> +         read only or non-executable will be aligned up to the section size
> +         or contiguous hint size of the kernel. This prevents sections from
> +         being split into pages and avoids a potential TLB penalty. The downside
> +         is an increase in alignment and potentially wasted space. Turn on
> +         this option if performance is more important than memory pressure.
>
>           If in doubt, say N
>
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index b78a3c7..8f4fc2c 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -63,13 +63,14 @@ PECOFF_FILE_ALIGNMENT = 0x200;
>  #endif
>
>  #if defined(CONFIG_DEBUG_ALIGN_RODATA)
> -#define ALIGN_DEBUG_RO                 . = ALIGN(1<<SECTION_SHIFT);
> -#define ALIGN_DEBUG_RO_MIN(min)                ALIGN_DEBUG_RO
> +#if defined(CONFIG_ARM64_4K_PAGES)
> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(SECTION_SIZE);
> +#else
> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(CONT_SIZE);
> +#endif
>  #elif defined(CONFIG_DEBUG_RODATA)
> -#define ALIGN_DEBUG_RO                 . = ALIGN(1<<PAGE_SHIFT);
> -#define ALIGN_DEBUG_RO_MIN(min)                ALIGN_DEBUG_RO
> +#define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(PAGE_SIZE);
>  #else
> -#define ALIGN_DEBUG_RO
>  #define ALIGN_DEBUG_RO_MIN(min)                . = ALIGN(min);
>  #endif
>
> --
> 2.4.3
>


From xhnjupt at gmail.com  Wed Feb 17 09:14:36 2016
From: xhnjupt at gmail.com (Han Xu)
Date: Thu, 18 Feb 2016 01:14:36 +0800
Subject: [PATCH v4 2/7] mtd: spi-nor: fsl-quadspi: add support for ls1021a
In-Reply-To: <1453793041-35868-2-git-send-email-yao.yuan@freescale.com>
References: <1453793041-35868-1-git-send-email-yao.yuan@freescale.com>
 <1453793041-35868-2-git-send-email-yao.yuan@freescale.com>
Message-ID: <20160217171436.GC16812@shlinux2>

On Tue, Jan 26, 2016 at 03:23:56PM +0800, Yuan Yao wrote:
> LS1021a also support Freescale Quad SPI controller.
> Add fsl-quadspi support for ls1021a chip and make SPI_FSL_QUADSPI
> selectable for LS1021A SOC hardwares.
> 
> Signed-off-by: Yuan Yao <yao.yuan at nxp.com>
> Acked-by: Han xu <han.xu at freescale.com>
> ---
> Changed in v4:
> No changes.
> 
> Changed in v3:
> No changes.
> 
> Changed in v2:
> Update my email to <yao.yuan at nxp.com>
> ---
>  drivers/mtd/spi-nor/Kconfig       |  2 +-
>  drivers/mtd/spi-nor/fsl-quadspi.c | 10 ++++++++++
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 0dc9275..a28c278 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -30,7 +30,7 @@ config MTD_SPI_NOR_USE_4K_SECTORS
>  
>  config SPI_FSL_QUADSPI
>  	tristate "Freescale Quad SPI controller"
> -	depends on ARCH_MXC || COMPILE_TEST
> +	depends on ARCH_MXC || SOC_LS1021A || COMPILE_TEST
>  	depends on HAS_IOMEM
>  	help
>  	  This enables support for the Quad SPI controller in master mode.
> diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
> index 04e8a93..9ab2b51 100644
> --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> @@ -213,6 +213,7 @@ enum fsl_qspi_devtype {
>  	FSL_QUADSPI_IMX6SX,
>  	FSL_QUADSPI_IMX7D,
>  	FSL_QUADSPI_IMX6UL,
> +	FSL_QUADSPI_LS1021A,
>  };
>  
>  struct fsl_qspi_devtype_data {
> @@ -258,6 +259,14 @@ static struct fsl_qspi_devtype_data imx6ul_data = {
>  		       | QUADSPI_QUIRK_4X_INT_CLK,
>  };
>  
> +static struct fsl_qspi_devtype_data ls1021a_data = {
> +	.devtype = FSL_QUADSPI_LS1021A,
> +	.rxfifo = 128,
> +	.txfifo = 64,
> +	.ahb_buf_size = 1024,
> +	.driver_data = 0,
> +};
> +
>  #define FSL_QSPI_MAX_CHIP	4
>  struct fsl_qspi {
>  	struct spi_nor nor[FSL_QSPI_MAX_CHIP];
> @@ -812,6 +821,7 @@ static const struct of_device_id fsl_qspi_dt_ids[] = {
>  	{ .compatible = "fsl,imx6sx-qspi", .data = (void *)&imx6sx_data, },
>  	{ .compatible = "fsl,imx7d-qspi", .data = (void *)&imx7d_data, },
>  	{ .compatible = "fsl,imx6ul-qspi", .data = (void *)&imx6ul_data, },
> +	{ .compatible = "fsl,ls1021a-qspi", .data = (void *)&ls1021a_data, },
>  	{ /* sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(of, fsl_qspi_dt_ids);
> -- 
> 2.1.0.27.g96db324
> 
Acked-by: Han xu <han.xu at nxp.com>
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


From xhnjupt at gmail.com  Wed Feb 17 09:15:02 2016
From: xhnjupt at gmail.com (Han Xu)
Date: Thu, 18 Feb 2016 01:15:02 +0800
Subject: [PATCH v4 3/7] mtd: spi-nor: fsl-quadspi: add support for
 layerscape
In-Reply-To: <1453793041-35868-3-git-send-email-yao.yuan@freescale.com>
References: <1453793041-35868-1-git-send-email-yao.yuan@freescale.com>
 <1453793041-35868-3-git-send-email-yao.yuan@freescale.com>
Message-ID: <20160217171502.GD16812@shlinux2>

On Tue, Jan 26, 2016 at 03:23:57PM +0800, Yuan Yao wrote:
> LS1043a and LS2080A in the Layerscape family also support Freescale Quad
> SPI, make Quad SPI selectable for these hardwares.
> 
> Signed-off-by: Yuan Yao <yao.yuan at nxp.com>
> ---
> Changed in v4:
> No changes.
> 
> Changed in v3:
> No changes.
> 
> Changed in v2:
> Update my email to <yao.yuan at nxp.com>
> ---
>  drivers/mtd/spi-nor/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index a28c278..6b53deb 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -30,7 +30,7 @@ config MTD_SPI_NOR_USE_4K_SECTORS
>  
>  config SPI_FSL_QUADSPI
>  	tristate "Freescale Quad SPI controller"
> -	depends on ARCH_MXC || SOC_LS1021A || COMPILE_TEST
> +	depends on ARCH_MXC || SOC_LS1021A || ARCH_LAYERSCAPE || COMPILE_TEST
>  	depends on HAS_IOMEM
>  	help
>  	  This enables support for the Quad SPI controller in master mode.
> -- 
> 2.1.0.27.g96db324
> 
> 
Acked-by: Han xu <han.xu at nxp.com>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


From matthias.bgg at gmail.com  Wed Feb 17 09:19:01 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Wed, 17 Feb 2016 18:19:01 +0100
Subject: [PATCH v3 1/5] Revert "drivers/tty/serial: make 8250/8250_mtk.c
 explicitly non-modular"
In-Reply-To: <1455721357-4008289-2-git-send-email-arnd@arndb.de>
References: <1455721357-4008289-1-git-send-email-arnd@arndb.de>
 <1455721357-4008289-2-git-send-email-arnd@arndb.de>
Message-ID: <56C4AB85.7010708@gmail.com>



On 17/02/16 16:02, Arnd Bergmann wrote:
> This reverts commit d72d391c126e ("drivers/tty/serial: make
> 8250/8250_mtk.c explicitly non-modular"), which intended to remove dead
> code but did not have the desired effect when the main 8250 driver was
> a module itself.
>
> This would normally result in a link error, but as the entire
> drivers/tty/serial/8250/ directory is only entered when CONFIG_SERIAL_8250
> is set, we never notice that the driver does not get built in this
> configuration.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---

Acked-by: Matthias Brugger <matthias.bgg at gmail.com>

>   drivers/tty/serial/8250/8250_mtk.c | 35 ++++++++++++++++++++++++++++-------
>   1 file changed, 28 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
> index 9038843cadc7..6ecc6e3e82dc 100644
> --- a/drivers/tty/serial/8250/8250_mtk.c
> +++ b/drivers/tty/serial/8250/8250_mtk.c
> @@ -16,7 +16,7 @@
>    */
>   #include <linux/clk.h>
>   #include <linux/io.h>
> -#include <linux/init.h>
> +#include <linux/module.h>
>   #include <linux/of_irq.h>
>   #include <linux/of_platform.h>
>   #include <linux/platform_device.h>
> @@ -245,6 +245,23 @@ static int mtk8250_probe(struct platform_device *pdev)
>   	return 0;
>   }
>
> +static int mtk8250_remove(struct platform_device *pdev)
> +{
> +	struct mtk8250_data *data = platform_get_drvdata(pdev);
> +
> +	pm_runtime_get_sync(&pdev->dev);
> +
> +	serial8250_unregister_port(data->line);
> +
> +	pm_runtime_disable(&pdev->dev);
> +	pm_runtime_put_noidle(&pdev->dev);
> +
> +	if (!pm_runtime_status_suspended(&pdev->dev))
> +		mtk8250_runtime_suspend(&pdev->dev);
> +
> +	return 0;
> +}
> +
>   static int __maybe_unused mtk8250_suspend(struct device *dev)
>   {
>   	struct mtk8250_data *data = dev_get_drvdata(dev);
> @@ -273,18 +290,18 @@ static const struct of_device_id mtk8250_of_match[] = {
>   	{ .compatible = "mediatek,mt6577-uart" },
>   	{ /* Sentinel */ }
>   };
> +MODULE_DEVICE_TABLE(of, mtk8250_of_match);
>
>   static struct platform_driver mtk8250_platform_driver = {
>   	.driver = {
> -		.name			= "mt6577-uart",
> -		.pm			= &mtk8250_pm_ops,
> -		.of_match_table		= mtk8250_of_match,
> -		.suppress_bind_attrs	= true,
> -
> +		.name		= "mt6577-uart",
> +		.pm		= &mtk8250_pm_ops,
> +		.of_match_table	= mtk8250_of_match,
>   	},
>   	.probe			= mtk8250_probe,
> +	.remove			= mtk8250_remove,
>   };
> -builtin_platform_driver(mtk8250_platform_driver);
> +module_platform_driver(mtk8250_platform_driver);
>
>   #ifdef CONFIG_SERIAL_8250_CONSOLE
>   static int __init early_mtk8250_setup(struct earlycon_device *device,
> @@ -300,3 +317,7 @@ static int __init early_mtk8250_setup(struct earlycon_device *device,
>
>   OF_EARLYCON_DECLARE(mtk8250, "mediatek,mt6577-uart", early_mtk8250_setup);
>   #endif
> +
> +MODULE_AUTHOR("Matthias Brugger");
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Mediatek 8250 serial port driver");
>


From xhnjupt at gmail.com  Wed Feb 17 09:15:26 2016
From: xhnjupt at gmail.com (Han Xu)
Date: Thu, 18 Feb 2016 01:15:26 +0800
Subject: [PATCH v4 4/7] Documentation: fsl-quadspi: Add fsl, ls2080a-dspi
 compatible string
In-Reply-To: <1453793041-35868-4-git-send-email-yao.yuan@freescale.com>
References: <1453793041-35868-1-git-send-email-yao.yuan@freescale.com>
 <1453793041-35868-4-git-send-email-yao.yuan@freescale.com>
Message-ID: <20160217171526.GE16812@shlinux2>

On Tue, Jan 26, 2016 at 03:23:58PM +0800, Yuan Yao wrote:
> new compatible string: "fsl,ls2080a-qspi".
> 
> Signed-off-by: Yuan Yao <yao.yuan at nxp.com>
> Acked-by: Rob Herring <robh at kernel.org>
> ---
> Changed in v4:
> No changes.
> 
> Changed in v3:
> Add the modifier for new compatible string like:
> "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
> 
> Changed in v2:
> Update my email to <yao.yuan at nxp.com>
> ---
>  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> index fa77f87..1ad0fe3 100644
> --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> @@ -1,7 +1,10 @@
>  ARM Freescale DSPI controller
>  
>  Required properties:
> -- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", "fsl,ls2085a-dspi"
> +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
> +		"fsl,ls2085a-dspi"
> +		or
> +		"fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
>  - reg : Offset and length of the register set for the device
>  - interrupts : Should contain SPI controller interrupt
>  - clocks: from common clock binding: handle to dspi clock.
> -- 
> 2.1.0.27.g96db324
> 
> 
Acked-by: Han xu <han.xu at nxp.com>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


From xhnjupt at gmail.com  Wed Feb 17 09:15:57 2016
From: xhnjupt at gmail.com (Han Xu)
Date: Thu, 18 Feb 2016 01:15:57 +0800
Subject: [PATCH v4 5/7] Documentation: fsl-quadspi: Add fsl, ls2080a-qspi
 compatible string
In-Reply-To: <1453793041-35868-5-git-send-email-yao.yuan@freescale.com>
References: <1453793041-35868-1-git-send-email-yao.yuan@freescale.com>
 <1453793041-35868-5-git-send-email-yao.yuan@freescale.com>
Message-ID: <20160217171557.GF16812@shlinux2>

On Tue, Jan 26, 2016 at 03:23:59PM +0800, Yuan Yao wrote:
> new compatible string: "fsl,ls2080a-qspi".
> 
> Signed-off-by: Yuan Yao <yao.yuan at nxp.com>
> Acked-by: Rob Herring <robh at kernel.org>
> ---
> Changed in v4:
> No changes.
> 
> Changed in v3:
> Add the modifier for new compatible string like:
> "fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi"
> 
> Changed in v2:
> Update my email to <yao.yuan at nxp.com>
> ---
>  Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
> index 00c587b..0df2f3a 100644
> --- a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
> +++ b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
> @@ -3,7 +3,9 @@
>  Required properties:
>    - compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
>  		 "fsl,imx7d-qspi", "fsl,imx6ul-qspi",
> -		 "fsl,ls1021-qspi"
> +		 "fsl,ls1021a-qspi"
> +		 or
> +		 "fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi"
>    - reg : the first contains the register location and length,
>            the second contains the memory mapping address and length
>    - reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"
> -- 
> 2.1.0.27.g96db324
> 
> 
Acked-by: Han xu <han.xu at nxp.com>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


From xhnjupt at gmail.com  Wed Feb 17 09:16:27 2016
From: xhnjupt at gmail.com (Han Xu)
Date: Thu, 18 Feb 2016 01:16:27 +0800
Subject: [PATCH v4 6/7] dts/ls2080a: update the DTS for QSPI and DSPI
 support
In-Reply-To: <1453793041-35868-6-git-send-email-yao.yuan@freescale.com>
References: <1453793041-35868-1-git-send-email-yao.yuan@freescale.com>
 <1453793041-35868-6-git-send-email-yao.yuan@freescale.com>
Message-ID: <20160217171627.GG16812@shlinux2>

On Tue, Jan 26, 2016 at 03:24:00PM +0800, Yuan Yao wrote:
> Signed-off-by: Yuan Yao <yao.yuan at nxp.com>
> ---
> Changed in v4:
> No changes.
> 
> Changed in v3:
> No changes.
> 
> Changed in v2:
> Update my email to <yao.yuan at nxp.com>
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts | 9 ++++++++-
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi    | 4 ++--
>  2 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> index 4cb996d..e8801fa 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
> @@ -178,7 +178,14 @@
>  
>  &qspi {
>  	status = "okay";
> -	qflash0: s25fl008k {
> +	flash0: s25fl256s1 at 0 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		compatible = "st,m25p80";
> +		spi-max-frequency = <20000000>;
> +		reg = <0>;
> +	};
> +	flash2: s25fl256s1 at 2 {
>  		#address-cells = <1>;
>  		#size-cells = <1>;
>  		compatible = "st,m25p80";
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> index 2b23d03..65e612a 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> @@ -318,7 +318,7 @@
>  
>  		dspi: dspi at 2100000 {
>  			status = "disabled";
> -			compatible = "fsl,vf610-dspi";
> +			compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
>  			#address-cells = <1>;
>  			#size-cells = <0>;
>  			reg = <0x0 0x2100000 0x0 0x10000>;
> @@ -444,7 +444,7 @@
>  
>  		qspi: quadspi at 20c0000 {
>  			status = "disabled";
> -			compatible = "fsl,vf610-qspi";
> +			compatible = "fsl,ls2080a-qspi", "fsl,ls1021a-qspi";
>  			#address-cells = <1>;
>  			#size-cells = <0>;
>  			reg = <0x0 0x20c0000 0x0 0x10000>,
> -- 
> 2.1.0.27.g96db324
> 
> 
Acked-by: Han xu <han.xu at nxp.com>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


From xhnjupt at gmail.com  Wed Feb 17 09:16:52 2016
From: xhnjupt at gmail.com (Han Xu)
Date: Thu, 18 Feb 2016 01:16:52 +0800
Subject: [PATCH v4 7/7] Documentation: fsl-quadspi: Add optional properties
In-Reply-To: <1453793041-35868-7-git-send-email-yao.yuan@freescale.com>
References: <1453793041-35868-1-git-send-email-yao.yuan@freescale.com>
 <1453793041-35868-7-git-send-email-yao.yuan@freescale.com>
Message-ID: <20160217171652.GH16812@shlinux2>

On Tue, Jan 26, 2016 at 03:24:01PM +0800, Yuan Yao wrote:
> Add optional properties for QSPI:
> big-endian
> if the register is big endian on this platform.
> 
> Signed-off-by: Yuan Yao <yao.yuan at nxp.com>
> Acked-by: Rob Herring <robh at kernel.org>
> ---
> Changed in v4:
> No changes.
> 
> Changed in v3:
> No changes.
> 
> Changed in v2:
> Update my email to <yao.yuan at nxp.com>
> ---
>  Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
> index 0df2f3a..0333ec8 100644
> --- a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
> +++ b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
> @@ -21,6 +21,7 @@ Optional properties:
>  			      But if there are two NOR flashes connected to the
>  			      bus, you should enable this property.
>  			      (Please check the board's schematic.)
> +  - big-endian : That means the IP register is big endian
>  
>  Example:
>  
> -- 
> 2.1.0.27.g96db324
> 
> 
Acked-by: Han xu <han.xu at nxp.com>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


From catalin.marinas at arm.com  Wed Feb 17 09:26:00 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 17 Feb 2016 17:26:00 +0000
Subject: [PATCH 4/4] arm64: cputype info for Broadcom Vulcan
In-Reply-To: <56C3C9D4.4020506@gmail.com>
References: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
 <1455389195-31870-5-git-send-email-jchandra@broadcom.com>
 <20160215101235.GA1748@arm.com> <56C3C9D4.4020506@gmail.com>
Message-ID: <20160217172600.GA26514@e104818-lin.cambridge.arm.com>

On Tue, Feb 16, 2016 at 05:16:04PM -0800, Florian Fainelli wrote:
> On 15/02/16 02:12, Will Deacon wrote:
> > On Sun, Feb 14, 2016 at 12:16:35AM +0530, Jayachandran C wrote:
> >> Add Broadcom Vulcan implementor ID and part ID in cputype.h. This is
> >> to document the values.
> >>
> >> Signed-off-by: Jayachandran C <jchandra at broadcom.com>
> >> ---
> >>  arch/arm64/include/asm/cputype.h | 2 ++
> >>  1 file changed, 2 insertions(+)
> > 
> > Acked-by: Will Deacon <will.deacon at arm.com>
> 
> Would this be picked by Calatin, or should this be sent along with the
> ARM/ARM64 SoC changes pull requests (just wondering?), thanks!

It can go via the arm-soc tree together with the other patches. If you
need another ack:

Acked-by: Catalin Marinas <catalin.marinas at arm.com>


From romain.perier at gmail.com  Wed Feb 17 09:28:32 2016
From: romain.perier at gmail.com (Romain Perier)
Date: Wed, 17 Feb 2016 18:28:32 +0100
Subject: [PATCH 0/2] Adding support to show SoC revision in /proc/cpuinfo
Message-ID: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>

This serie adds support to retrieve the SoC serial and revision of the current
Meson8 platform. Basically, in the first patch I register a soc_device and retrieve
information from a syscon register, then I populate system_rev and system_serial.
In the second patch I add the device_node to the devicetree.

Romain Perier (2):
  ARM: meson: Adding support to retrieve serial and SoC revision
  ARM: dts: meson: Adding hwrev syscon node

 arch/arm/boot/dts/meson8b.dtsi |  5 ++++
 arch/arm/mach-meson/meson.c    | 55 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 60 insertions(+)

-- 
2.5.0



From tony at atomide.com  Wed Feb 17 09:28:36 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 17 Feb 2016 09:28:36 -0800
Subject: [PATCH 1/2] dt-bindings: clock: adpll: Add binding documentation
 for TI adpll
In-Reply-To: <20160217010440.2278.62327@quark.deferred.io>
References: <1455312009-808-1-git-send-email-tony@atomide.com>
 <1455312009-808-2-git-send-email-tony@atomide.com>
 <20160217010440.2278.62327@quark.deferred.io>
Message-ID: <20160217172836.GA21202@atomide.com>

* Michael Turquette <mturquette at baylibre.com> [160216 17:17]:
> Quoting Tony Lindgren (2016-02-12 13:20:08)
> > +Required properties:
> > +- compatible : shall be one of "ti,dm814-adpll-s-clock" or
> > +  "ti,dm814-adpll-lj-clock" depending on the type of the ADPLL
> > +- #clock-cells : from common clock binding; shall be set to 0.
> 
> Thanks for the patch.
> 
> clock-cells = 1 in both of the examples below (which looks right).

Oops thanks, will update to 1.

> > +- clocks : link phandles of parent clocks clkinp and clkinpulow, note
> > +  that the adpll-s-clock also has an optional clkinphif
> > +- reg : address and length of the register set for controlling the ADPLL.
> > +
> > +Examples:
> > +       adpll_mpu_ck: adpll at 40 {
> > +               #clock-cells = <1>;
> > +               compatible = "ti,dm814-adpll-s-clock";
> > +               reg = <0x40 0x40>;
> > +               clocks = <&devosc_ck &devosc_ck &devosc_ck>;
> > +               clock-names = "clkinp", "clkinpulow", "clkinphif";
> > +               clock-indices = <0>, <1>, <2>, <3>;
> 
> Why is clock-indices necessary?

Hmm yeah I don't think it's needed, so will drop.

Regards,

Tony



From romain.perier at gmail.com  Wed Feb 17 09:28:33 2016
From: romain.perier at gmail.com (Romain Perier)
Date: Wed, 17 Feb 2016 18:28:33 +0100
Subject: [PATCH 1/2] ARM: meson: Adding support to retrieve serial and SoC
 revision
In-Reply-To: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
Message-ID: <1455730114-2547-2-git-send-email-romain.perier@gmail.com>

This path adds support to get the revision and the serial of the running
SoC, on Meson8. On these plaforms, these informations can be found into
CBUS registers. To do so, we instanciate a syscon register, then create
a soc_device, and finally we expose everything to the system.

Signed-off-by: Romain Perier <romain.perier at gmail.com>
---
 arch/arm/mach-meson/meson.c | 55 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/arch/arm/mach-meson/meson.c b/arch/arm/mach-meson/meson.c
index 4e23571..2816e30 100644
--- a/arch/arm/mach-meson/meson.c
+++ b/arch/arm/mach-meson/meson.c
@@ -13,8 +13,16 @@
  *
  */
 
+#include <linux/of_address.h>
 #include <linux/of_platform.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/sys_soc.h>
 #include <asm/mach/arch.h>
+#include <asm/system_info.h>
+
+#define MESON_REVISION_REG (0x45c)
 
 static const char * const meson_common_board_compat[] = {
 	"amlogic,meson6",
@@ -23,7 +31,54 @@ static const char * const meson_common_board_compat[] = {
 	NULL,
 };
 
+static void __init meson_init_machine(void)
+{
+	struct soc_device_attribute *soc_dev_attr;
+	struct soc_device *soc_dev;
+	struct regmap *hwrev;
+	unsigned int val;
+	int ret;
+
+	hwrev = syscon_regmap_lookup_by_compatible("amlogic,meson8b-hwrev");
+	if (IS_ERR(hwrev)) {
+		pr_err("hwrev node not found\n");
+		return;
+	}
+
+	soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+	if (!soc_dev_attr)
+		return;
+	ret = regmap_read(hwrev, 0, &val);
+	if (ret < 0) {
+		pr_err("Could not get SoC id\n");
+		return;
+	}
+	system_serial_high = val << 24;
+
+	ret = regmap_read(hwrev, MESON_REVISION_REG, &val);
+	if (ret < 0) {
+		pr_err("Could not get SoC revision\n");
+		return;
+	}
+	system_rev = val == 0x11111111 ? 0xA : 0xB;
+
+	soc_dev_attr->family = "Amlogic Meson";
+	soc_dev_attr->revision = kasprintf(GFP_KERNEL, "0x%x", system_rev);
+	soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "0x%x", system_serial_high);
+
+	soc_dev = soc_device_register(soc_dev_attr);
+	if (IS_ERR(soc_dev)) {
+		pr_err("Could not register soc device\n");
+		kfree(soc_dev_attr);
+		return;
+	}
+
+	pr_info("Amlogic Meson SoC Rev%X (%X:%X)\n", system_rev, system_serial_high, system_rev);
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
+}
+
 DT_MACHINE_START(MESON, "Amlogic Meson platform")
+	.init_machine	= meson_init_machine,
 	.dt_compat	= meson_common_board_compat,
 	.l2c_aux_val	= 0,
 	.l2c_aux_mask	= ~0,
-- 
2.5.0



From romain.perier at gmail.com  Wed Feb 17 09:28:34 2016
From: romain.perier at gmail.com (Romain Perier)
Date: Wed, 17 Feb 2016 18:28:34 +0100
Subject: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
In-Reply-To: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
Message-ID: <1455730114-2547-3-git-send-email-romain.perier@gmail.com>

These are the CBUS registers used to retrieve the revision and the
identifier of the SoC on Meson8.

Signed-off-by: Romain Perier <romain.perier at gmail.com>
---
 arch/arm/boot/dts/meson8b.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index 0477a81..71009dc 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -99,6 +99,11 @@
 		};
 	};
 
+	hwrev at c1107d4c {
+		compatible = "amlogic,meson8b-hwrev", "syscon";
+		reg = <0xc1107d4c 0x460>;
+	};
+
 	sram: sram at d9000000 {
 		compatible = "mmio-sram";
 		reg = <0xd9000000 0x20000>;
-- 
2.5.0



From marc.zyngier at arm.com  Wed Feb 17 09:29:59 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 17:29:59 +0000
Subject: [PATCH 2/2 v3] irqchip/Layerscape: Add SCFG MSI controller support
In-Reply-To: <1454403648-5551-2-git-send-email-Minghuan.Lian@nxp.com>
References: <1454403648-5551-1-git-send-email-Minghuan.Lian@nxp.com>
 <1454403648-5551-2-git-send-email-Minghuan.Lian@nxp.com>
Message-ID: <56C4AE17.4050301@arm.com>

Minguan,

Please CC LKML for any irqchip related patch - see the MAINTAINER file.

On 02/02/16 09:00, Minghuan Lian wrote:
> Some kind of NXP Layerscape SoC provides a MSI
> implementation which uses two SCFG registers MSIIR and
> MSIR to support 32 MSI interrupts for each PCIe controller.
> The patch is to support it.
> 
> Signed-off-by: Minghuan Lian <Minghuan.Lian at nxp.com>
> ---
> 
> Change log
> v3:
> 1. call of_node_to_fwnode()
> v2:
> 1. rename ls1-msi to ls-scfg-msi
> 2. remove reg-names MSIIR MSIR 
> 3. remove calling set_irq_flags()
> 
>  drivers/irqchip/Kconfig           |   5 +
>  drivers/irqchip/Makefile          |   1 +
>  drivers/irqchip/irq-ls-scfg-msi.c | 244 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 250 insertions(+)
>  create mode 100644 drivers/irqchip/irq-ls-scfg-msi.c
> 
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index fb50911..0f2a3c3 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -218,3 +218,8 @@ config IRQ_MXS
>  	def_bool y if MACH_ASM9260 || ARCH_MXS
>  	select IRQ_DOMAIN
>  	select STMP_DEVICE
> +
> +config LS_SCFG_MSI
> +	def_bool y if SOC_LS1021A || ARCH_LAYERSCAPE
> +	depends on PCI && PCI_MSI
> +	select PCI_MSI_IRQ_DOMAIN
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 18caacb..37e12de 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -59,3 +59,4 @@ obj-$(CONFIG_ARCH_SA1100)		+= irq-sa11x0.o
>  obj-$(CONFIG_INGENIC_IRQ)		+= irq-ingenic.o
>  obj-$(CONFIG_IMX_GPCV2)			+= irq-imx-gpcv2.o
>  obj-$(CONFIG_PIC32_EVIC)		+= irq-pic32-evic.o
> +obj-$(CONFIG_LS_SCFG_MSI)		+= irq-ls-scfg-msi.o
> diff --git a/drivers/irqchip/irq-ls-scfg-msi.c b/drivers/irqchip/irq-ls-scfg-msi.c
> new file mode 100644
> index 0000000..f57a72c
> --- /dev/null
> +++ b/drivers/irqchip/irq-ls-scfg-msi.c
> @@ -0,0 +1,244 @@
> +/*
> + * NXP SCFG MSI(-X) support
> + *
> + * Copyright (C) 2016 NXP Semiconductor.
> + *
> + * Author: Minghuan Lian <Minghuan.Lian at nxp.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.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/msi.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/irqchip/chained_irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/of_pci.h>
> +#include <linux/of_platform.h>
> +#include <linux/spinlock.h>
> +
> +#define MSI_MAX_IRQS	32
> +#define MSI_IBS_SHIFT	3
> +#define MSIR		4
> +
> +struct ls_scfg_msi {
> +	spinlock_t		lock;
> +	struct platform_device	*pdev;
> +	struct irq_domain	*parent;
> +	struct irq_domain	*msi_domain;
> +	void __iomem		*regs;
> +	phys_addr_t		msiir_addr;
> +	u32			nr_irqs;
> +	int			irq;
> +	DECLARE_BITMAP(used, MSI_MAX_IRQS);
> +};
> +
> +static struct irq_chip ls_scfg_msi_irq_chip = {
> +	.name = "MSI",
> +	.irq_enable	= pci_msi_unmask_irq,
> +	.irq_disable	= pci_msi_mask_irq,
> +	.irq_mask	= pci_msi_mask_irq,
> +	.irq_unmask	= pci_msi_unmask_irq,
> +};

You don't need all of this. mask/unmask are enough.

> +
> +static struct msi_domain_info ls_scfg_msi_domain_info = {
> +	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS |
> +		   MSI_FLAG_USE_DEF_CHIP_OPS |
> +		   MSI_FLAG_PCI_MSIX),
> +	.chip	= &ls_scfg_msi_irq_chip,
> +};
> +
> +static void ls_scfg_msi_compose_msg(struct irq_data *data, struct msi_msg *msg)
> +{
> +	struct ls_scfg_msi *msi_data = irq_data_get_irq_chip_data(data);
> +
> +	msg->address_hi = upper_32_bits(msi_data->msiir_addr);
> +	msg->address_lo = lower_32_bits(msi_data->msiir_addr);
> +	msg->data = data->hwirq << MSI_IBS_SHIFT;
> +}
> +
> +static int ls_scfg_msi_set_affinity(struct irq_data *irq_data,
> +				    const struct cpumask *mask, bool force)
> +{
> +	return -EINVAL;
> +}
> +
> +static struct irq_chip ls_scfg_msi_parent_chip = {
> +	.name			= "LS SCFG MSI",

Worth making this shorter. "SCFG" should be enough.

> +	.irq_compose_msi_msg	= ls_scfg_msi_compose_msg,
> +	.irq_set_affinity	= ls_scfg_msi_set_affinity,
> +};
> +
> +static int ls_scfg_msi_domain_irq_alloc(struct irq_domain *domain,
> +					unsigned int virq,
> +					unsigned int nr_irqs,
> +					void *args)
> +{
> +	struct ls_scfg_msi *msi_data = domain->host_data;
> +	int pos, err = 0;
> +
> +	WARN_ON(nr_irqs != 1);
> +
> +	spin_lock(&msi_data->lock);
> +	pos = find_first_zero_bit(msi_data->used, msi_data->nr_irqs);
> +	if (pos < msi_data->nr_irqs)
> +		__set_bit(pos, msi_data->used);
> +	else
> +		err = -ENOSPC;
> +	spin_unlock(&msi_data->lock);
> +
> +	if (err)
> +		return err;
> +
> +	irq_domain_set_info(domain, virq, pos,
> +			    &ls_scfg_msi_parent_chip, msi_data,
> +			    handle_simple_irq, NULL, NULL);
> +
> +	return 0;
> +}
> +
> +static void ls_scfg_msi_domain_irq_free(struct irq_domain *domain,
> +				   unsigned int virq, unsigned int nr_irqs)
> +{
> +	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> +	struct ls_scfg_msi *msi_data = irq_data_get_irq_chip_data(d);
> +	int pos;
> +
> +	pos = d->hwirq;
> +	if (pos < 0 || pos >= msi_data->nr_irqs) {
> +		pr_err("failed to teardown msi. Invalid hwirq %d\n", pos);
> +		return;
> +	}
> +
> +	spin_lock(&msi_data->lock);
> +	__clear_bit(pos, msi_data->used);
> +	spin_unlock(&msi_data->lock);
> +}
> +
> +static const struct irq_domain_ops ls_scfg_msi_domain_ops = {
> +	.alloc	= ls_scfg_msi_domain_irq_alloc,
> +	.free	= ls_scfg_msi_domain_irq_free,
> +};
> +
> +static void ls_scfg_msi_irq_handler(struct irq_desc *desc)
> +{
> +	struct ls_scfg_msi *msi_data = irq_desc_get_handler_data(desc);
> +	unsigned long val;
> +	int pos, virq;
> +
> +	chained_irq_enter(irq_desc_get_chip(desc), desc);
> +
> +	val = ioread32be(msi_data->regs + MSIR);

Is the device guaranteed to always be BE?

> +	for_each_set_bit(pos, &val, msi_data->nr_irqs) {
> +		virq = irq_find_mapping(msi_data->parent, (31 - pos));
> +		if (virq)
> +			generic_handle_irq(virq);
> +	}
> +
> +	chained_irq_exit(irq_desc_get_chip(desc), desc);
> +}
> +
> +static int ls_scfg_msi_domains_init(struct ls_scfg_msi *msi_data)
> +{
> +	/* Initialize MSI domain parent */
> +	msi_data->parent = irq_domain_add_linear(NULL,
> +						 msi_data->nr_irqs,
> +						 &ls_scfg_msi_domain_ops,
> +						 msi_data);
> +	if (!msi_data->parent) {
> +		dev_err(&msi_data->pdev->dev, "failed to create IRQ domain\n");
> +		return -ENOMEM;
> +	}
> +
> +	msi_data->msi_domain = pci_msi_create_irq_domain(
> +				of_node_to_fwnode(msi_data->pdev->dev.of_node),
> +				&ls_scfg_msi_domain_info,
> +				msi_data->parent);
> +	if (!msi_data->msi_domain) {
> +		dev_err(&msi_data->pdev->dev, "failed to create MSI domain\n");
> +		irq_domain_remove(msi_data->parent);
> +		return -ENOMEM;
> +	}
> +
> +	return 0;
> +}
> +
> +static int ls_scfg_msi_probe(struct platform_device *pdev)
> +{
> +	struct ls_scfg_msi *msi_data;
> +	struct resource *res;
> +	int ret;
> +
> +	msi_data = devm_kzalloc(&pdev->dev, sizeof(*msi_data), GFP_KERNEL);
> +	if (!msi_data)
> +		return -ENOMEM;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	msi_data->regs = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(msi_data->regs)) {
> +		dev_err(&pdev->dev, "failed to initialize 'regs'\n");
> +		return PTR_ERR(msi_data->regs);
> +	}
> +	msi_data->msiir_addr = res->start;
> +
> +	msi_data->irq = platform_get_irq(pdev, 0);
> +	if (msi_data->irq <= 0) {
> +		dev_err(&pdev->dev, "failed to get MSI irq\n");
> +		return -ENODEV;
> +	}
> +
> +	msi_data->pdev = pdev;
> +	msi_data->nr_irqs = MSI_MAX_IRQS;

So this is hardcoded, always. Why do you need a nr_irqs variable at all?

> +	spin_lock_init(&msi_data->lock);
> +
> +	ret = ls_scfg_msi_domains_init(msi_data);
> +	if (ret)
> +		return ret;
> +
> +	irq_set_chained_handler_and_data(msi_data->irq,
> +					 ls_scfg_msi_irq_handler,
> +					 msi_data);
> +
> +	platform_set_drvdata(pdev, msi_data);
> +
> +	return 0;
> +}
> +
> +static int ls_scfg_msi_remove(struct platform_device *pdev)
> +{
> +	struct ls_scfg_msi *msi_data = platform_get_drvdata(pdev);
> +
> +	irq_set_chained_handler_and_data(msi_data->irq, NULL, NULL);
> +
> +	irq_domain_remove(msi_data->msi_domain);
> +	irq_domain_remove(msi_data->parent);
> +
> +	platform_set_drvdata(pdev, NULL);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id ls_scfg_msi_id[] = {
> +	{ .compatible = "fsl,1s1021a-msi", },
> +	{ .compatible = "fsl,1s1043a-msi", },
> +	{},
> +};
> +
> +static struct platform_driver ls_scfg_msi_driver = {
> +	.driver = {
> +		.name = "ls-scfg-msi",
> +		.of_match_table = ls_scfg_msi_id,
> +	},
> +	.probe = ls_scfg_msi_probe,
> +	.remove = ls_scfg_msi_remove,
> +};
> +
> +module_platform_driver(ls_scfg_msi_driver);
> +
> +MODULE_AUTHOR("Minghuan Lian <Minghuan.Lian at nxp.com>");
> +MODULE_DESCRIPTION("NXP Layerscape SCFG MSI controller driver");
> +MODULE_LICENSE("GPL v2");
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From marc.zyngier at arm.com  Wed Feb 17 09:33:33 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 17:33:33 +0000
Subject: [PATCH 1/2 v3] dt/bindings: Add bindings for Layerscape SCFG MSI
In-Reply-To: <1454403648-5551-1-git-send-email-Minghuan.Lian@nxp.com>
References: <1454403648-5551-1-git-send-email-Minghuan.Lian@nxp.com>
Message-ID: <56C4AEED.4060901@arm.com>

On 02/02/16 09:00, Minghuan Lian wrote:
> Some Layerscape SoCs use a simple MSI controller implementation.
> It contains only two SCFG register to trigger and describe a
> group 32 MSI interrupts. The patch adds bindings to describe
> the controller.
> 
> Signed-off-by: Minghuan Lian <Minghuan.Lian at nxp.com>
> ---
>  .../interrupt-controller/fsl,ls-scfg-msi.txt       | 23 ++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt
> 
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt
> new file mode 100644
> index 0000000..0c41151
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt
> @@ -0,0 +1,23 @@
> +* Freescale Layerscape SCFG PCIe MSI controller
> +
> +Required properties:
> +
> +- compatible: should be "fsl,<soc-name>-msi" to identify
> +	      Layerscape PCIe MSI controller block such as:
> +              "fsl,1s1021a-msi"
> +              "fsl,1s1043a-msi"
> +- msi-controller: indicates that this is a PCIe MSI controller node
> +- reg: physical base address of the controller and length of memory mapped.
> +- interrupts: A interrupt of the controller.

This is an interrupt *to* the the parent interrupt controller.

> +
> +Each PCIe node needs to have property msi-parent that points to
> +MSI controller node
> +
> +Examples:
> +
> +	msi1: msi-controller at 1571000 {
> +		compatible = "fsl,1s1043a-msi";
> +		reg = <0x0 0x1571000 0x0 0x8>,
> +		msi-controller;
> +		interrupts = <0 116 0x4>;
> +	};
> 

Please document the need for an interrupt-parent property. Your example
assumes that there is a default one...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From tony at atomide.com  Wed Feb 17 09:39:49 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 17 Feb 2016 09:39:49 -0800
Subject: [PATCH 2/2] clk: ti: Add support for dm814x ADPLL
In-Reply-To: <20160217011930.2278.38316@quark.deferred.io>
References: <1455312009-808-1-git-send-email-tony@atomide.com>
 <1455312009-808-3-git-send-email-tony@atomide.com>
 <20160217011930.2278.38316@quark.deferred.io>
Message-ID: <20160217173949.GB21202@atomide.com>

* Michael Turquette <mturquette at baylibre.com> [160216 17:32]:
> Quoting Tony Lindgren (2016-02-12 13:20:09)
> > 
> > - Split the device tree binding into a separate patch as requested
> >   by Mike for his conditional ack of the binding
> 
> Just to make life fun for you, the clk tree is once more merging DT
> bindings descriptions and headers. You don't need to merge the patches,
> it doesn't matter to me, but just as a heads up for the future.

OK :)

> > --- /dev/null
> > +++ b/drivers/clk/ti/Kconfig
> > @@ -0,0 +1,6 @@
> > +config COMMON_CLK_TI_ADPLL
> > +       tristate "Clock driver for dm814x ADPLL"
> > +       depends on ARCH_OMAP2PLUS
> > +       default y if SOC_TI81XX
> 
> Can we add COMPILE_TEST here?

Good idea, will add.

> > +static int ti_adpll_init_inputs(struct ti_adpll_data *d)
> > +{
> > +       const char *error = "need at least %i inputs";
> > +       struct clk *clock;
> > +       int nr_inputs;
> > +
> > +       nr_inputs = of_clk_get_parent_count(d->np);
> > +       if (nr_inputs < d->c->nr_max_inputs) {
> > +               dev_err(d->dev, error, nr_inputs);
> > +               return -EINVAL;
> > +       }
> > +       of_clk_parent_fill(d->np, d->parent_names, nr_inputs);
> > +
> > +       clock = devm_clk_get(d->dev, d->parent_names[0]);
> > +       if (IS_ERR(clock)) {
> > +               dev_err(d->dev, "could not get clkinp\n");
> > +               return PTR_ERR(clock);
> > +       }
> > +       d->parent_clocks[TI_ADPLL_CLKINP] = clock;
> > +
> > +       clock = devm_clk_get(d->dev, d->parent_names[1]);
> > +       if (IS_ERR(clock)) {
> > +               dev_err(d->dev, "could not get clkinpulow clock\n");
> > +               return PTR_ERR(clock);
> > +       }
> > +       d->parent_clocks[TI_ADPLL_CLKINPULOW] = clock;
> 
> Are the clock parents known at compile-time? Can we just put that data
> in C instead of whatever is going on here?

No they can be board specific depending how the inputs for
clkin, clkinpulow and clkinphif are wired.

> ...
> > +int __init dm814x_adpll_enable_init_clocks(void)
> > +{
> > +       int i, err;
> > +
> > +       if (!timer_clocks_initialized)
> > +               return -ENODEV;
> > +
> > +       for (i = 0; i < ARRAY_SIZE(init_clocks); i++) {
> > +               struct clk *clock;
> > +
> > +               clock = clk_get(NULL, init_clocks[i]);
> > +               if (WARN(IS_ERR(clock), "could not find init clock %s\n",
> > +                        init_clocks[i]))
> > +                       continue;
> > +               err = clk_prepare_enable(clock);
> > +               if (WARN(err, "could not enable init clock %s\n",
> > +                        init_clocks[i]))
> > +                       continue;
> 
> We have a shiny new series that provides a standard way to do this:
> 
> http://lkml.kernel.org/r/<1455225554-13267-1-git-send-email-mturquette at baylibre.com>

OK nice, so tagging the MPU and DDR clocks with CLK_IS_CRITICAL or
"clock-critical" should allow removing this code. I think in this
case I still need to set CLK_IS_CRITICAL as the clock is output 1
of the dts defined clock and does not have a separate dts node.

I can update when those patches hit Linux next, or I can do a
follow-up patch later on if we want to avoid the dependency
here. Which do you prefer?

Regards,

Tony


From lorenzo.pieralisi at arm.com  Wed Feb 17 09:45:16 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 17 Feb 2016 17:45:16 +0000
Subject: [PATCH V5 07/15] pci, acpi: Provide generic way to assign bus
 domain number.
In-Reply-To: <56C49342.1070308@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
 <1455630825-27253-8-git-send-email-tn@semihalf.com>
 <CAKc_7PU+i2AwOVCyW2VNt4BZCWw=KBMAbV8v9DVQ2Ess3WE=kw@mail.gmail.com>
 <56C47E9A.5010901@semihalf.com>
 <CAKc_7PUiLQhUuJjR8wcuRm7KJdxBYjb+ZBd_cLTtjNPbEro6wA@mail.gmail.com>
 <56C48C45.7050203@semihalf.com>
 <CAKc_7PV=p7kHt73c673L+v=KCaFV8RzoaSHwcH2gd1g-fWGq5w@mail.gmail.com>
 <56C49342.1070308@semihalf.com>
Message-ID: <20160217174516.GA11132@red-moon>

Guys,

On Wed, Feb 17, 2016 at 04:35:30PM +0100, Tomasz Nowicki wrote:

[...]

> >>>>>In my patchset, I had a slightly different and I think better approach
> >>>>>for
> >>>>>this without calling the _SEG method again. Please see
> >>>>>http://www.spinics.net/lists/arm-kernel/msg478167.html
> >>>>>at the last part
> >>>>>ofhttp://www.spinics.net/lists/arm-kernel/msg478169.html
> >>>>
> >>>>
> >>>>Relying on NULL parent device to make decision on boot method is really
> >>>>ugly
> >>>>way. This may hit us again once we want to obtain another firmware
> >>>>specific
> >>>>info e.g. numa node. IMO we need to fix it this way.
> >>>
> >>>
> >>>I am not relying on NULL there, in the current code parent is NULL
> >>>in case of ACPI, and the check is needed not to crash (unless that
> >>>has changed).
> >>
> >>
> >>This series passes down valid parent, see [PATCH V5 06/15].
> >>
> >>>
> >>>The main part was the macro acpi_pci_get_segment() and the use
> >>>of acpi_pci_root_info from sysdata to do this.
> >>
> >>
> >>Since we can obtain related firmware specific data from valid parent device
> >>(without defining another accessors), I do not see the point to use sysdata.
> >>Let me know your opinion.
> >
> >In the patch, you use the parent info and call _SEG method again.
> >The segment information is available in the ->root->segment of
> >acpi_pci_root_info if you setup the sysdata like in my patch
> 
> I know it is in sysdata->root->segment, but the way it is passed
> down is wrong. sysdata is the pointer to unknown content (void *) so
> we need to validate it before we can use it. If we merge this patch
> we can remove first _SEG call.

I personally do not think there is such a significant difference, both
solutions have pros and cons, it is worth keeping in mind though
that reading _SEG again to set the bus domain number works only if
the value we stash in acpi_pci_root.segment is not overridden, if it
is (ie see x86 - agreed that's to fix a FW bug) we have a disconnect.

On the other hand Tomasz's code allows removing some IA64 code in the
process (code that sets the bridge companion, so part of the patch
should be kept regardless).

So, there are two things to do:

- Assign the bridge companion in PCI core code
- Decide where to get the domain number from (acpi_pci_root.segment vs
  calling _SEG again). At present they are equivalent so I do not see
  any compelling reason to change this patch.

Side note: there is already a function (pci_domain_nr()) that you
can implement in ACPI PCI host generic (by deselecting
PCI_DOMAINS_GENERIC if ACPI) so there is no need for acpi_pci_get_segment()
in case we have to override _SEG value in the future, at present
there is no need, comments appreciated.

Lorenzo


From mark.rutland at arm.com  Wed Feb 17 09:56:56 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 17 Feb 2016 17:56:56 +0000
Subject: KASAN issues with idle / hotplug area (was: Re: [PATCH v5sub1
 7/8] arm64: move kernel image to base of vmalloc area)
In-Reply-To: <20160217170110.GE32647@leverpostej>
References: <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
 <20160217170110.GE32647@leverpostej>
Message-ID: <20160217175656.GJ32647@leverpostej>

On Wed, Feb 17, 2016 at 05:01:11PM +0000, Mark Rutland wrote:
> On Wed, Feb 17, 2016 at 02:39:51PM +0000, Mark Rutland wrote:
> > Perhaps the simplest option is to not instrument invoke_psci_fn_* and
> > psci_suspend_finisher. Do we have a per-function annotation to avoid
> > KASAN instrumentation, like notrace? I need to investigate, but we may
> > also need notrace for similar reasons.
>
> I came up with the patch below, per the reasoning above.
> 
> It _changes_ the KASAN splats (I see errors in tick_program_event rather
> than find_busiest_group), but doesn't seem to get rid of them. I'm not
> sure if I've missed something, or if we also have another latent issue.
> 
> Ideas?

I'd missed annotating __cpu_suspend_save. I've fixed that up locally
(along with s/virt_to_phys/__virt_to_phys due to the inlining issue).

I'm still missing somehing; I'm getting KASAN warnings in find_busiest_group
again, and the shadow looks like it's corrupt (the second batch of f3 /
KASAN_STACK_RIGHT don't have a matching f1 / KASAN_STACK_LEFT):

[   13.138791] Memory state around the buggy address:
[   13.143624]  ffffffc936a7fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   13.150929]  ffffffc936a7fc00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
[   13.158232] >ffffffc936a7fc80: f3 f3 f3 f3 00 00 00 00 00 f4 f4 f4 f3 f3 f3 f3
[   13.165530]                       ^
[   13.169066]  ffffffc936a7fd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   13.176369]  ffffffc936a7fd80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1

This is turning into a whack-a-mole game...

Mark.

> ---->8----
> From 8f7ae44d8f8862f5300483d45617b5bd05fc652f Mon Sep 17 00:00:00 2001
> From: Mark Rutland <mark.rutland at arm.com>
> Date: Wed, 17 Feb 2016 15:38:22 +0000
> Subject: [PATCH] arm64/psci: avoid KASAN splats with idle
> 
> When a CPU goes into a deep idle state, we store CPU context in
> __cpu_suspend_enter, then call psci_suspend_finisher to invoke the
> firmware. If we entered a deep idle state, we do not return directly,
> and instead start cold, restoring state in cpu_resume.
> 
> Thus we may execute the prologue and body of psci_suspend_finisher and
> the PSCI invocation function, but not their epilogue. When using KASAN
> this means that we poison a region of shadow memory, but never unpoison
> it. After we resume, subsequent stack accesses may hit the stale poison
> values, leading to false positives from KASAN.
> 
> To avoid this, we must ensure that functions called after the context
> save are not instrumented, and do not posion the shadow region, by
> annotating them with __no_sanitize_address. As common inlines they may
> call are not similarly annotated, and the compiler refuses to allow
> function attribute mismatches, we must also avoid calls to such
> functions.
> 
> ARM is not affected, as it does not support KASAN. When CONFIG_KASAN is
> not selected, __no_sanitize_address expands to nothing, so the
> annotation should not be harmful.
> 
> Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> ---
>  arch/arm64/kernel/psci.c | 14 ++++++++------
>  drivers/firmware/psci.c  |  3 +++
>  2 files changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> index f67f35b..8324ce8 100644
> --- a/arch/arm64/kernel/psci.c
> +++ b/arch/arm64/kernel/psci.c
> @@ -32,12 +32,16 @@
>  
>  static DEFINE_PER_CPU_READ_MOSTLY(u32 *, psci_power_state);
>  
> +static phys_addr_t cpu_resume_phys;
> +
>  static int __maybe_unused cpu_psci_cpu_init_idle(unsigned int cpu)
>  {
>  	int i, ret, count = 0;
>  	u32 *psci_states;
>  	struct device_node *state_node, *cpu_node;
>  
> +	cpu_resume_phys = virt_to_phys(cpu_resume);
> +
>  	cpu_node = of_get_cpu_node(cpu, NULL);
>  	if (!cpu_node)
>  		return -ENODEV;
> @@ -178,12 +182,10 @@ static int cpu_psci_cpu_kill(unsigned int cpu)
>  }
>  #endif
>  
> -static int psci_suspend_finisher(unsigned long index)
> +__no_sanitize_address
> +static int psci_suspend_finisher(unsigned long state)
>  {
> -	u32 *state = __this_cpu_read(psci_power_state);
> -
> -	return psci_ops.cpu_suspend(state[index - 1],
> -				    virt_to_phys(cpu_resume));
> +	return psci_ops.cpu_suspend(state, cpu_resume_phys);
>  }
>  
>  static int __maybe_unused cpu_psci_cpu_suspend(unsigned long index)
> @@ -200,7 +202,7 @@ static int __maybe_unused cpu_psci_cpu_suspend(unsigned long index)
>  	if (!psci_power_state_loses_context(state[index - 1]))
>  		ret = psci_ops.cpu_suspend(state[index - 1], 0);
>  	else
> -		ret = cpu_suspend(index, psci_suspend_finisher);
> +		ret = cpu_suspend(state[index - 1], psci_suspend_finisher);
>  
>  	return ret;
>  }
> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> index f25cd79..e4e8dc1 100644
> --- a/drivers/firmware/psci.c
> +++ b/drivers/firmware/psci.c
> @@ -106,6 +106,7 @@ bool psci_power_state_is_valid(u32 state)
>  	return !(state & ~valid_mask);
>  }
>  
> +__no_sanitize_address
>  static unsigned long __invoke_psci_fn_hvc(unsigned long function_id,
>  			unsigned long arg0, unsigned long arg1,
>  			unsigned long arg2)
> @@ -116,6 +117,7 @@ static unsigned long __invoke_psci_fn_hvc(unsigned long function_id,
>  	return res.a0;
>  }
>  
> +__no_sanitize_address
>  static unsigned long __invoke_psci_fn_smc(unsigned long function_id,
>  			unsigned long arg0, unsigned long arg1,
>  			unsigned long arg2)
> @@ -148,6 +150,7 @@ static u32 psci_get_version(void)
>  	return invoke_psci_fn(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
>  }
>  
> +__no_sanitize_address
>  static int psci_cpu_suspend(u32 state, unsigned long entry_point)
>  {
>  	int err;
> -- 
> 1.9.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From marc.zyngier at arm.com  Wed Feb 17 09:57:39 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 17:57:39 +0000
Subject: [PATCH v4.1] arm64: perf: Count EL2 events if the kernel is running
 in HYP
In-Reply-To: <1455216004-19499-22-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-22-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455731859-26690-1-git-send-email-marc.zyngier@arm.com>

When the kernel is running in HYP (with VHE), it is necessary to
include EL2 events if the user requests counting kernel or
hypervisor events.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kernel/perf_event.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index f7ab14c..1b52269 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -20,6 +20,7 @@
  */
 
 #include <asm/irq_regs.h>
+#include <asm/virt.h>
 
 #include <linux/of.h>
 #include <linux/perf/arm_pmu.h>
@@ -691,9 +692,12 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
 
 	if (attr->exclude_idle)
 		return -EPERM;
+	if (is_kernel_in_hyp_mode() &&
+	    attr->exclude_kernel != attr->exclude_hv)
+		return -EINVAL;
 	if (attr->exclude_user)
 		config_base |= ARMV8_EXCLUDE_EL0;
-	if (attr->exclude_kernel)
+	if (!is_kernel_in_hyp_mode() && attr->exclude_kernel)
 		config_base |= ARMV8_EXCLUDE_EL1;
 	if (!attr->exclude_hv)
 		config_base |= ARMV8_INCLUDE_EL2;
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 17 09:58:43 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 17 Feb 2016 17:58:43 +0000
Subject: [PATCH v4.1] arm64: hw_breakpoint: Allow EL2 breakpoints if running
 in HYP
In-Reply-To: <1455216004-19499-23-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-23-git-send-email-marc.zyngier@arm.com>
Message-ID: <1455731923-26768-1-git-send-email-marc.zyngier@arm.com>

With VHE, we place kernel {watch,break}-points at EL2 to get things
like kgdb and "perf -e mem:..." working.

This requires a bit of repainting in the low-level encore/decode,
but is otherwise pretty simple.

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/hw_breakpoint.h | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
index 9732908..115ea2a 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -18,6 +18,7 @@
 
 #include <asm/cputype.h>
 #include <asm/cpufeature.h>
+#include <asm/virt.h>
 
 #ifdef __KERNEL__
 
@@ -35,10 +36,21 @@ struct arch_hw_breakpoint {
 	struct arch_hw_breakpoint_ctrl ctrl;
 };
 
+/* Privilege Levels */
+#define AARCH64_BREAKPOINT_EL1	1
+#define AARCH64_BREAKPOINT_EL0	2
+
+#define DBG_HMC_HYP		(1 << 13)
+
 static inline u32 encode_ctrl_reg(struct arch_hw_breakpoint_ctrl ctrl)
 {
-	return (ctrl.len << 5) | (ctrl.type << 3) | (ctrl.privilege << 1) |
+	u32 val = (ctrl.len << 5) | (ctrl.type << 3) | (ctrl.privilege << 1) |
 		ctrl.enabled;
+
+	if (is_kernel_in_hyp_mode() && ctrl.privilege == AARCH64_BREAKPOINT_EL1)
+		val |= DBG_HMC_HYP;
+
+	return val;
 }
 
 static inline void decode_ctrl_reg(u32 reg,
@@ -61,10 +73,6 @@ static inline void decode_ctrl_reg(u32 reg,
 #define ARM_BREAKPOINT_STORE	2
 #define AARCH64_ESR_ACCESS_MASK	(1 << 6)
 
-/* Privilege Levels */
-#define AARCH64_BREAKPOINT_EL1	1
-#define AARCH64_BREAKPOINT_EL0	2
-
 /* Lengths */
 #define ARM_BREAKPOINT_LEN_1	0x1
 #define ARM_BREAKPOINT_LEN_2	0x3
-- 
2.1.4



From ray.jui at broadcom.com  Wed Feb 17 10:10:46 2016
From: ray.jui at broadcom.com (Ray Jui)
Date: Wed, 17 Feb 2016 10:10:46 -0800
Subject: [02/11] video: ARM CLCD: support DT signal inversion flags
In-Reply-To: <1454594660-7532-3-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-3-git-send-email-linus.walleij@linaro.org>
Message-ID: <0cebf93a-ee0a-3637-3242-8aed266df091@broadcom.com>

Hi Linus,

A somewhat related question, how do you see the CLKSEL bit in the TIM2 
register will be supported in the future? There are some cases where the 
CLKSEL bit needs to be set, and therefore the "CLCDCLK" instead of 
"HCLK" reference clock source is selected.

Thanks!

Ray

On 2/4/2016 6:04 AM, Linus Walleij wrote:
> The device tree bindings from display-timing.txt allows us to
> specify if data enable, hsync, vsync or the pixed clock should be
> inverted on the way to the display. The driver does not currently
> handle this so add support for those flags as it is needed for
> the Versatile Sanyo LCD display.
>
> Note that the previous behaviour was to invert the pixel clock
> for all displays, so unless the pixel clock polarity is
> explicitly defined in the device tree (i.e. the timings node
> has the "pixelclk-active" property) we fall back to inverting
> the pixel clock. This needs some extra compatibility code.
>
> Since the timing flags have to be set up inside the struct
> clcd_panel, we need to refactor the code a bit to pass around
> the panel rather than just the mode.
>
> Cc: Pawel Moll <pawel.moll at arm.com>
> Cc: Rob Herring <robh at kernel.org>
> Cc: Russell King <linux at arm.linux.org.uk>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
>
> ---
> drivers/video/fbdev/amba-clcd.c | 41 ++++++++++++++++++++++++++++++++++-------
>  1 file changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
> index c5d1e9ca81ab..8903a42c4122 100644
> --- a/drivers/video/fbdev/amba-clcd.c
> +++ b/drivers/video/fbdev/amba-clcd.c
> @@ -567,10 +567,11 @@ static int clcdfb_register(struct clcd_fb *fb)
>
>  #ifdef CONFIG_OF
>  static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
> -		struct fb_videomode *mode)
> +		struct clcd_panel *clcd_panel)
>  {
>  	int err;
>  	struct display_timing timing;
> +	struct device_node *timnp;
>  	struct videomode video;
>
>  	err = of_get_display_timing(node, "panel-timing", &timing);
> @@ -579,10 +580,34 @@ static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
>
>  	videomode_from_timing(&timing, &video);
>
> -	err = fb_videomode_from_videomode(&video, mode);
> +	err = fb_videomode_from_videomode(&video, &clcd_panel->mode);
>  	if (err)
>  		return err;
>
> +	/* Set up some inversion flags */
> +	timnp = of_get_child_by_name(node, "panel-timing");
> +	if (timnp && of_property_read_bool(timnp, "pixelclk-active")) {
> +		if (timing.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> +			clcd_panel->tim2 |= TIM2_IPC;
> +	} else {
> +		/*
> +		 * To preserve backwards compatibility, the IPC (inverted
> +		 * pixel clock) flag needs to be set on any display that
> +		 * doesn't explicitly specify that the pixel clock is
> +		 * active on the negative edge.
> +		 */
> +		clcd_panel->tim2 |= TIM2_IPC;
> +	}
> +
> +	if (timing.flags & DISPLAY_FLAGS_HSYNC_LOW)
> +		clcd_panel->tim2 |= TIM2_IHS;
> +
> +	if (timing.flags & DISPLAY_FLAGS_VSYNC_LOW)
> +		clcd_panel->tim2 |= TIM2_IVS;
> +
> +	if (timing.flags & DISPLAY_FLAGS_DE_LOW)
> +		clcd_panel->tim2 |= TIM2_IOE;
> +
>  	return 0;
>  }
>
> @@ -615,10 +640,11 @@ static int clcdfb_of_get_backlight(struct device_node *endpoint,
>  }
>
>  static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
> -		struct fb_videomode *mode)
> +		struct clcd_panel *clcd_panel)
>  {
>  	int err;
>  	struct device_node *panel;
> +	struct fb_videomode *mode;
>  	char *name;
>  	int len;
>
> @@ -628,11 +654,12 @@ static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
>
>  	/* Only directly connected DPI panels supported for now */
>  	if (of_device_is_compatible(panel, "panel-dpi"))
> -		err = clcdfb_of_get_dpi_panel_mode(panel, mode);
> +		err = clcdfb_of_get_dpi_panel_mode(panel, clcd_panel);
>  	else
>  		err = -ENOENT;
>  	if (err)
>  		return err;
> +	mode = &clcd_panel->mode;
>
>  	len = clcdfb_snprintf_mode(NULL, 0, mode);
>  	name = devm_kzalloc(dev, len + 1, GFP_KERNEL);
> @@ -663,8 +690,8 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
>  	};
>  	int i;
>
> -	/* Bypass pixel clock divider, data output on the falling edge */
> -	fb->panel->tim2 = TIM2_BCD | TIM2_IPC;
> +	/* Bypass pixel clock divider */
> +	fb->panel->tim2 |= TIM2_BCD;
>
>  	/* TFT display, vert. comp. interrupt at the start of the back porch */
>  	fb->panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
> @@ -704,7 +731,7 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
>  	if (err)
>  		return err;
>
> -	err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, &fb->panel->mode);
> +	err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, fb->panel);
>  	if (err)
>  		return err;
>
>


From xhnjupt at gmail.com  Wed Feb 17 10:07:42 2016
From: xhnjupt at gmail.com (Han Xu)
Date: Thu, 18 Feb 2016 02:07:42 +0800
Subject: [PATCH v2 3/4] mtd:spi-nor:fsl-quadspi:Add fast-read mode support
In-Reply-To: <1454326208-4533-3-git-send-email-B56489@freescale.com>
References: <1454326208-4533-1-git-send-email-B56489@freescale.com>
 <1454326208-4533-3-git-send-email-B56489@freescale.com>
Message-ID: <20160217180742.GB17485@shlinux2>

On Mon, Feb 01, 2016 at 07:30:07PM +0800, Yunhui Cui wrote:
> The qspi driver add generic fast-read mode for different
> flash venders. There are some different board flash work on
> different mode, such fast-read, quad-mode.
> So we have to modify the third entrace parameter of spi_nor_scan().
> 
> Signed-off-by: Yunhui Cui <B56489 at freescale.com>
> ---
>  drivers/mtd/spi-nor/fsl-quadspi.c | 27 +++++++++++++++++++++------
>  1 file changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
> index 9861290..0a31cb1 100644
> --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> @@ -389,11 +389,21 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
>  	/* Read */
>  	lut_base = SEQID_READ * 4;
>  
> -	qspi_writel(q, LUT0(CMD, PAD1, read_op) | LUT1(ADDR, PAD1, addrlen),
> -			base + QUADSPI_LUT(lut_base));
> -	qspi_writel(q, LUT0(DUMMY, PAD1, read_dm) |
> -		    LUT1(FSL_READ, PAD4, rxfifo),
> -			base + QUADSPI_LUT(lut_base + 1));
> +	if (nor->flash_read == SPI_NOR_FAST) {
> +		qspi_writel(q, LUT0(CMD, PAD1, read_op) |
> +			    LUT1(ADDR, PAD1, addrlen),
> +				base + QUADSPI_LUT(lut_base));
> +		qspi_writel(q,  LUT0(DUMMY, PAD1, read_dm) |
> +			    LUT1(FSL_READ, PAD1, rxfifo),
> +				base + QUADSPI_LUT(lut_base + 1));
> +	} else if (nor->flash_read == SPI_NOR_QUAD) {
> +		qspi_writel(q, LUT0(CMD, PAD1, read_op) |
> +			    LUT1(ADDR, PAD1, addrlen),
> +				base + QUADSPI_LUT(lut_base));
> +		qspi_writel(q, LUT0(DUMMY, PAD1, read_dm) |
> +			    LUT1(FSL_READ, PAD4, rxfifo),
> +				base + QUADSPI_LUT(lut_base + 1));
> +	}
>  
>  	/* Write enable */
>  	lut_base = SEQID_WREN * 4;
> @@ -468,6 +478,7 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
>  {
>  	switch (cmd) {
>  	case SPINOR_OP_READ_1_1_4:
> +	case SPINOR_OP_READ_FAST:
>  		return SEQID_READ;
>  	case SPINOR_OP_WREN:
>  		return SEQID_WREN;
> @@ -963,6 +974,7 @@ static int fsl_qspi_probe(struct platform_device *pdev)
>  	struct spi_nor *nor;
>  	struct mtd_info *mtd;
>  	int ret, i = 0;
> +	enum read_mode mode = SPI_NOR_QUAD;
>  
>  	q = devm_kzalloc(dev, sizeof(*q), GFP_KERNEL);
>  	if (!q)
> @@ -1064,7 +1076,10 @@ static int fsl_qspi_probe(struct platform_device *pdev)
>  		/* set the chip address for READID */
>  		fsl_qspi_set_base_addr(q, nor);
>  
> -		ret = spi_nor_scan(nor, NULL, SPI_NOR_QUAD);
> +		ret = of_property_read_bool(np, "m25p,fast-read");
> +		mode = (ret) ? SPI_NOR_FAST : SPI_NOR_QUAD;
> +
> +		ret = spi_nor_scan(nor, NULL, mode);
>  		if (ret)
>  			goto mutex_failed;
>  
I understand you want to provide a more generic read mode, but this is a quad
spi driver, I prefer to provide the options, either quad read/quad IO read,
or just normal read.
> -- 
> 2.1.0.27.g96db324
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


From lorenzo.pieralisi at arm.com  Wed Feb 17 10:18:55 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 17 Feb 2016 18:18:55 +0000
Subject: [PATCH V5 14/15] arm64, pci, acpi: Assign legacy IRQs once
 device is enable.
In-Reply-To: <1455630825-27253-15-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
 <1455630825-27253-15-git-send-email-tn@semihalf.com>
Message-ID: <20160217181855.GB11132@red-moon>

[+ Duc, this needs testing on DT PCI hosts that do not call pci_fixup_irqs()]

On Tue, Feb 16, 2016 at 02:53:44PM +0100, Tomasz Nowicki wrote:

Subject is wrong, leftover from previous posting (ie you do not allocate
at device enable anymore).

> This is the last step before enabling generic ACPI PCI host controller
> for ARM64. We need to take care of legacy IRQ mapping for non-MSI(X)

You do not check MSIs anymore.

> PCI devices. pcibios_alloc_irq() evaluation is not sensitive to
> ACPI device enumeration order, so it is the best place to assign
> device's IRQs for ACPI boot method. Also, it does not hurt DT to be
> initialized form the same place.
> 
> NOTE: *This is going to be temporary solution*. There is ongoing work
> which aims for cleaning legacy IRQ allocation from arch specific code.
> We can consider this patch as the necessary evil which will be removed
> once cleanup series lands in mailnline in the near future.

"To enable PCI legacy IRQs on platforms booting with ACPI, arch code
should include ACPI specific callbacks that parse and set-up the
device IRQ number, equivalent to the DT boot path. Owing to the current
ACPI core scan handlers implementation, ACPI PCI legacy IRQs bindings
cannot be parsed at device add time, since that would trigger ACPI scan
handlers ordering issues depending on how the ACPI tables are defined.

To solve this problem and consolidate FW PCI legacy IRQs parsing in
one single pcibios callback (pending final removal), this patch moves
DT PCI IRQ parsing to the pcibios_alloc_irq() callback (called by
PCI core code at device probe time) and adds ACPI PCI legacy IRQs
parsing to the same callback too, so that FW PCI legacy IRQs parsing
is confined in one single arch callback that can be easily removed
when code parsing PCI legacy IRQs is consolidated and moved to core
PCI code".

?

> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
> Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> ---
>  arch/arm64/kernel/pci.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 023b983..6e77e1b 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -52,11 +52,16 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
>  }
>  
>  /*
> - * Try to assign the IRQ number from DT when adding a new device
> + * Try to assign the IRQ number when probing a new device
>   */
> -int pcibios_add_device(struct pci_dev *dev)
> +int pcibios_alloc_irq(struct pci_dev *dev)
>  {
> -	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> +	if (acpi_disabled)
> +		dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> +#ifdef CONFIG_ACPI
> +	else
> +		return acpi_pci_irq_enable(dev);
> +#endif
>  
>  	return 0;
>  }

It is good this code is now in one single function, it will be removed
more quickly :D

So pending APM X-gene DT testing:

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>


From manabian at gmail.com  Wed Feb 17 10:24:12 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Wed, 17 Feb 2016 19:24:12 +0100
Subject: [PATCH 1/2] clk: add lpc18xx creg clk driver
In-Reply-To: <20160217005629.2278.90197@quark.deferred.io>
References: <1436651307-24098-1-git-send-email-manabian@gmail.com>
 <1436651307-24098-2-git-send-email-manabian@gmail.com>
 <20150811204127.31346.16729@quantum>
 <CAGhQ9VwZaM_iWTkQYVTuTiyb6gCG2y6s8WFVySCHt7YHE1qbcA@mail.gmail.com>
 <20150818002604.31346.18322@quantum>
 <CAGhQ9VzOYbHsFZQxM8823OiWpGB6vLEwX8LfvjC=DnL1iqK_qQ@mail.gmail.com>
 <20160217005629.2278.90197@quark.deferred.io>
Message-ID: <CAGhQ9VzB_WgB8b4_c3Z17W+K2MC7Fq7SD9zEvZUN_UJVGDZ3Wg@mail.gmail.com>

On 17 February 2016 at 01:56, Michael Turquette <mturquette at baylibre.com> wrote:
> Quoting Joachim Eastwood (2016-02-13 06:38:45)
>> Hi Mike,
>>
>> Seems your reply got lost in my mailbox and I didn't notice it before
>> Stephen replied on the cover letter. Sorry about that.
>>
>> On 18 August 2015 at 02:26, Michael Turquette <mturquette at baylibre.com> wrote:
>> > Quoting Joachim Eastwood (2015-08-13 13:43:11)
>> >> On 11 August 2015 at 22:41, Michael Turquette <mturquette at baylibre.com> wrote:
>> >> > Hi Joachim,
>> >> >
>> >> > Quoting Joachim Eastwood (2015-07-11 14:48:26)
>> >> >> +static void __init lpc18xx_creg_clk_init(struct device_node *np)
>> >> >> +{
>> >> >> +       const char *clk_32khz_parent;
>> >> >> +       struct regmap *syscon;
>> >> >> +
>> >> >> +       syscon = syscon_node_to_regmap(np->parent);
>> >> >> +       if (IS_ERR(syscon)) {
>> >> >> +               pr_err("%s: syscon lookup failed\n", __func__);
>> >> >> +               return;
>> >> >> +       }
>> >> >> +
>> >> >> +       clk_32khz_parent = of_clk_get_parent_name(np, 0);
>> >> >> +
>> >> >> +       clk_creg[CREG_CLK_32KHZ] =
>> >> >> +               clk_register_creg_clk(&clk_creg_clocks[CREG_CLK_32KHZ],
>> >> >> +                                     &clk_32khz_parent, syscon);
>> >> >> +
>> >> >> +       clk_creg[CREG_CLK_1KHZ] =
>> >> >> +               clk_register_creg_clk(&clk_creg_clocks[CREG_CLK_1KHZ],
>> >> >> +                                     &clk_creg_clocks[CREG_CLK_32KHZ].name,
>> >> >> +                                     syscon);
>> >> >> +
>> >> >> +       of_clk_add_provider(np, of_clk_src_onecell_get, &clk_base_data);
>> >> >> +}
>> >> >> +CLK_OF_DECLARE(lpc18xx_creg_clk, "nxp,lpc1850-creg-clk", lpc18xx_creg_clk_init);
>> >> >
>> >> > I'll ask the same question that Stephen asked in your CCU/CGU driver
>> >> > series: is it necessary to use CLK_OF_DECLARE here or can you use the
>> >> > platform device model?
>> >>
>> >> The 32 kHz clock from the CREG block is a clock parent to the CGU
>> >> block so it's possible that it will required early. This is all
>> >> depends on how the boot loader initially configures the CGU.
>> >>
>> >> Currently in the DTS for lpc18xx cgu it has:
>> >> clocks = <&xtal>, <&xtal32>, <...>;
>> >> xtal32 is just a temporary placeholder until the CREG clock is in place.
>> >
>> > Well that seems wrong. Is it just a matter of probe order where you try
>> > to probe the cgu driver before the creg driver?
>>
>> The ideal probe order for the clk drivers on the lpc18xx platform
>> would be; creg-clk, cgu and ccu.
>> If the 32k clk is used by any of timers we need creg-clk to enable the
>> 32k clock and determine the rate.
>>
>> Note that the cgu and ccu driver is using CLK_OF_DECLARE now.
>>
>>
>> I have tired to create an overview of the lpc18xx clock system here:
>> https://github.com/manabian/linux-lpc/wiki/LPC18xx-LPC43xx-clocks
>
> That's great, thanks a lot for the link and the nice documentation.
>
> It's been a while since I've looked at this thread. Do any of the
> creg-clk, cgu or ccu clock drivers need to use CLK_OF_DECLARE? If they
> were platform_drivers then you could use -EPROBE_DEFER to solve your
> ordering issue.

The clock for the clocksource/timer
(drivers/clocksource/time-lpc32xx.c) comes from cgu/ccu and can also
come from creg-clk. So afaik they must use CLK_OF_DECLARE. Or is there
something I am missing?
Isn't true that most SoC system clock drivers must use CLK_OF_DECLARE
because the system timer require clocks early? I thought this was the
whole point.

Since it is possible that the 32k clock from creg-clk can be use as a
parent clock for the timer doesn't this mean it also must use
CLK_OF_DECLARE?
If it wasn't possible for creg-clk to be used as a parent clock for
the timer it could have been a platform device.


The lpc18xx clock configuration that require creg-clk early would be:
32k - > PLL0 -> BASE_M3/M4_CLK -> CLK_M3/M4_TIMER0. See second figure
on the webpage. Note that this is probably not a common configuration,
but it is a valid one. (PLL0 accepts input down to 14 kHz)


regards,
Joachim Eastwood


From kernel at martin.sperl.org  Wed Feb 17 10:25:45 2016
From: kernel at martin.sperl.org (Martin Sperl)
Date: Wed, 17 Feb 2016 19:25:45 +0100
Subject: [PATCH V4 5/7] clk: bcm2835: add missing 22 HW-clocks.
In-Reply-To: <56B8782C.4060107@martin.sperl.org>
References: <1452867667-2447-1-git-send-email-kernel@martin.sperl.org>
 <1452867667-2447-6-git-send-email-kernel@martin.sperl.org>
 <87h9hr517u.fsf@eliezer.anholt.net> <56B8782C.4060107@martin.sperl.org>
Message-ID: <A977D3F2-1F64-41C8-B8ED-EB9F0B3554B9@martin.sperl.org>


> On 08.02.2016, at 12:12, Martin Sperl <kernel at martin.sperl.org> wrote:
> 
> 
> 
> On 02.02.2016 02:51, Eric Anholt wrote:
>> kernel at martin.sperl.org writes:
>> 
>>> From: Martin Sperl <kernel at martin.sperl.org>
>>> 
>>> There were 22 HW clocks missing from the clock driver.
>>> 
>>> These have been included and int_bits and frac_bits
>>> have been set correctly based on information extracted
>>> from the broadcom videocore headers
>>> (http://www.broadcom.com/docs/support/videocore/Brcm_Android_ICS_Graphics_Stack.tar.gz)
>>> 
>>> For an extracted view of the registers please see:
>>> https://github.com/msperl/rpi-registers/blob/master/md/Region_CM.md
>>> 
>>> bcm2835_clock_per_parents has been assigned as the parent
>>> clock for all new clocks, but this may not be correct
>>> in all cases - documentation on this is not publicly
>>> available, so some modifications may be needed in the
>>> future.
>> 
>> We need the parents to be correct if we're going to land the patch.
>> I'll try to update them.
>> 
>> I'm not a fan of this "let's just shove everything we can find in some
>> header file into the .c and hope for the best."  Most of these clocks
>> were left out intentionally.
> 
> Well - I wanted to get them in just in case we need them later.
> 
> If you have got access to documentation which states the correct
> parent mux, then please share them so that we can implement them
> correctly.
> 
> Also listing all allows us then to expose the values of the registers
> via debugfs in case we need it - see separate RFC-patch 9 -  where
> we expose the raw register values as well.
> 
>>> +static const struct bcm2835_clock_data bcm2835_clock_aveo_data = {
>>> +	.name = "aveo",
>>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>>> +	.parents = bcm2835_clock_per_parents,
>>> +	.ctl_reg = CM_AVEOCTL,
>>> +	.div_reg = CM_AVEODIV,
>>> +	.int_bits = 4,
>>> +	.frac_bits = 12,
>>> +};
>> 
>> AVEO has 0 fractional bits
> 
> Correct - my issue (copy paste - I assume).
> 
>> 
>>> +static const struct bcm2835_clock_data bcm2835_clock_ccp2_data = {
>>> +	/* this is possibly a gate */
>>> +	.name = "ccp2",
>>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>>> +	.parents = bcm2835_clock_per_parents,
>>> +	.ctl_reg = CM_CCP2CTL,
>>> +	.div_reg = CM_CCP2DIV,
>>> +	.int_bits = 1,
>>> +	.frac_bits = 0,
>>> +};
>> 
>> CCP2 is a gate from a different clock source, so this won't work.
> See comment above: please provide parent clock mux.
> See also my comment about 3 clock that may be gates - this applies.
> 
>> 
>>> +static const struct bcm2835_clock_data bcm2835_clock_dsi0p_data = {
>>> +	/* this is possibly a gate */
>>> +	.name = "dsi0p",
>>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>>> +	.parents = bcm2835_clock_per_parents,
>>> +	.ctl_reg = CM_DSI0PCTL,
>>> +	.div_reg = CM_DSI0PDIV,
>>> +	.int_bits = 1,
>>> +	.frac_bits = 0,
>>> +};
>>> +
>>> +static const struct bcm2835_clock_data bcm2835_clock_dsi1p_data = {
>>> +	/* this is possibly a gate */
>>> +	.name = "dsi1p",
>>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>>> +	.parents = bcm2835_clock_per_parents,
>>> +	.ctl_reg = CM_DSI1PCTL,
>>> +	.div_reg = CM_DSI1PDIV,
>>> +	.int_bits = 1,
>>> +	.frac_bits = 0,
>>> +};
>> 
>> DSI0/1 pixel clocks take different clock sources and are gates off of
>> them, so these definitions don't work.
> See comment above: please provide parent clock.
> See also my comment about 3 clock that may be gates.
> 
>> 
>>> +
>>> +static const struct bcm2835_clock_data bcm2835_clock_gnric_data = {
>>> +	.name = "gnric",
>>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>>> +	.parents = bcm2835_clock_per_parents,
>>> +	.ctl_reg = CM_GNRICCTL,
>>> +	.div_reg = CM_GNRICDIV,
>>> +	.int_bits = 12,
>>> +	.frac_bits = 12,
>>> +};
>> 
>> GNRIC isn't an actual clock, it's just what's used for describing the
>> overall structure of clocks.
> 
> Well - there is the corresponding register at 0x7e101000 which reads as:
> ctl = 0x0000636d
> div = 0x0000636d
> 
> So we could remove this one if this is really the case of a dummy -
> even though I wonder why there would be space in io-space reserved for
> this "description" only.
> 
>> 
>>> +static const struct bcm2835_clock_data bcm2835_clock_peria_data = {
>>> +	.name = "peria",
>>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>>> +	.parents = bcm2835_clock_per_parents,
>>> +	.ctl_reg = CM_PERIACTL,
>>> +	.div_reg = CM_PERIADIV,
>>> +	.int_bits = 12,
>>> +	.frac_bits = 12,
>>> +};
>> 
>> This register doesn't do anything, because the debug bit in the power
>> manager is not set.  We don't think we should expose a clock gate if it
>> doesn't work, I think.
> maybe we allow setting debug in the PM at a later point in time?
> 
>> 
>>> +static const struct bcm2835_clock_data bcm2835_clock_pulse_data = {
>>> +	.name = "pulse",
>>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>>> +	.parents = bcm2835_clock_per_parents,
>>> +	.ctl_reg = CM_PULSECTL,
>>> +	.div_reg = CM_PULSEDIV,
>>> +	.int_bits = 12,
>>> +	.frac_bits = 0,
>>> +};
>> 
>> There's some other divider involved in this clock, won't give correct results.
> See comment above: please provide parent clock.
> 
>> 
>>> +static const struct bcm2835_clock_data bcm2835_clock_td0_data = {
>>> +	.name = "td0",
>>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>>> +	.parents = bcm2835_clock_per_parents,
>>> +	.ctl_reg = CM_TD0CTL,
>>> +	.div_reg = CM_TD0DIV,
>>> +	.int_bits = 12,
>>> +	.frac_bits = 12,
>>> +};
>>> +
>>> +static const struct bcm2835_clock_data bcm2835_clock_td1_data = {
>>> +	.name = "td1",
>>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>>> +	.parents = bcm2835_clock_per_parents,
>>> +	.ctl_reg = CM_TD1CTL,
>>> +	.div_reg = CM_TD1DIV,
>>> +	.int_bits = 12,
>>> +	.frac_bits = 12,
>>> +};
>> 
>> These are some other clock generator, not the generic or mash ones used
>> elsewhere.  I wouldn't enable them without testing.
> 
> As long as they are not referenced in the DT these only are read only
> and can get read via debugfs - these are disabled anyway:
> 
> root at raspcm:/build/linux# head /sys/kernel/debug/clk/td*/clk_rate
> ==> /sys/kernel/debug/clk/td0/clk_rate <==
> 0
> 
> ==> /sys/kernel/debug/clk/td1/clk_rate <==
> 0
> 
>> 
>>> +static const struct bcm2835_clock_data bcm2835_clock_tec_data = {
>>> +	.name = "tec",
>>> +	.num_mux_parents = ARRAY_SIZE(bcm2835_clock_per_parents),
>>> +	.parents = bcm2835_clock_per_parents,
>>> +	.ctl_reg = CM_TECCTL,
>>> +	.div_reg = CM_TECDIV,
>>> +	.int_bits = 6,
>>> +	.frac_bits = 0,
>>> +};
>> 
>> TEC should be osc parents.
> I will change that.
> 
>> 
>>> -/*
>>> - * CM_PERIICTL (and CM_PERIACTL, CM_SYSCTL and CM_VPUCTL if
>>> - * you have the debug bit set in the power manager, which we
>>> - * don't bother exposing) are individual gates off of the
>>> - * non-stop vpu clock.
>>> - */
>>>  static const struct bcm2835_gate_data bcm2835_clock_peri_image_data = {
>>>  	.name = "peri_image",
>>>  	.parent = "vpu",
>>>  	.ctl_reg = CM_PERIICTL,
>>>  };
>>> 
>>> +static const struct bcm2835_gate_data bcm2835_clock_sys_data = {
>>> +	.name = "sys",
>>> +	.parent = "vpu",
>>> +	.ctl_reg = CM_SYSCTL,
>>> +};
>> 
>> same concern as peria.
> maybe we allow setting debug in the PM at a later point in time?
> 
> Please propose how to continue to get the clocks in.
> 
> If you want some clocks left out, then that is fine and we
> can accommodate that and just leave the defines in the bindings
> header for later use...
> 
> Just list them.
> 


As I am trying to complete the list of clocks here my ?best? summary
so far of the clock tree for the bcm2835 taken from various sources:
* Datasheet
* broadcom provided VC4 headers (via https://github.com/msperl/rpi-registers)
* mailing list

And I have come up with the following description that
you can put in graphviz or http://www.webgraphviz.com/

--- cut here ---
digraph clocks {
	graph [ordering="out"];

	subgraph cluster_osc {
		label = "Oscillators";

                "GND";
                "OSC";
                "testdebug0";
                "testdebug1";
	}

	subgraph cluster_pll {
		label = "PLLs";

		subgraph cluster_plla {
			label = "PLLA";

			OSC -> PLLA;

			PLLA -> PLLA_core;
			PLLA -> PLLA_per;
			PLLA -> PLLA_dsi0;
			PLLA -> PLLA_ccp2;
		}

		subgraph cluster_pllb {
			label = "PLLB";

			OSC -> PLLB;

			PLLB -> PLLB_ARM;
			PLLB -> PLLB_SP0;
			PLLB -> PLLB_SP1;
			PLLB -> PLLB_SP2;
		}

		subgraph cluster_pllc {
			label = "PLLC";

			OSC -> PLLC;

			PLLC -> PLLC_core0;
			PLLC -> PLLC_core1;
			PLLC -> PLLC_core2;
			PLLC -> PLLC_per;
		}

		subgraph cluster_plld {
			label = "PLLD";

			OSC -> PLLD;

			PLLD -> PLLD_core;
			PLLD -> PLLD_per;
			PLLD -> PLLD_dsi0;
			PLLD -> PLLD_dsi1;
		}

		subgraph cluster_pllh {
			label = "PLLH";

			OSC -> PLLH;

			PLLH -> PLLH_aux;
			PLLH -> PLLH_pix;
			PLLH -> PLLH_rcal;
		}
	}

	subgraph cluster_mux {
		label = "clocks";

		subgraph cluster_vpu_clocks {
			label = "VPU-clocks";

			subgraph cluster_vpu_mux {
				label = "VPU-mux";

				vGND        [label="0: GND"];
				vOSC        [label="1: OSC"];
				vtestdebug0 [label="2: testdebug0"];
				vtestdebug1 [label="3: testdebug1"];
				vPLLA_core  [label="4: PLLA_core"];
				vPLLC_core0 [label="5: PLLC_core0"];
				vPLLD_core  [label="6: PLLD_core"];
				vPLLH_aux   [label="7: PLLH_aux"];
				vPLLC_core1 [label="8: PLLC_core1"];
				vPLLC_core2 [label="9: PLLC_core2"];

				GND        -> vGND        -> vpu_mux;
				OSC        -> vOSC        -> vpu_mux;
				testdebug0 -> vtestdebug0 -> vpu_mux;
				testdebug1 -> vtestdebug1 -> vpu_mux;
				PLLA_core  -> vPLLA_core  -> vpu_mux;
				PLLC_core0 -> vPLLC_core1 -> vpu_mux;
				PLLD_core  -> vPLLD_core  -> vpu_mux;
				PLLH_aux   -> vPLLH_aux   -> vpu_mux;
				PLLC_core1 -> vPLLC_core1 -> vpu_mux;
				PLLC_core2 -> vPLLC_core2 -> vpu_mux;
			}

			vpu_mux -> vpu;
			vpu_mux -> v3d;
			vpu_mux -> isp;
			vpu_mux -> h264;
			vpu_mux -> sdram;
		}

		subgraph cluster_per_clocks {
			label = "Periperial-clocks";

			subgraph cluster_per_mux {
				label = "Periperal-mux";

				pGND        [label="0: GND"];
				pOSC        [label="1: OSC"];
				ptestdebug0 [label="2: testdebug0"];
				ptestdebug1 [label="3: testdebug1"];
				pPLLA_per   [label="4: PLLA_per"];
				pPLLC_per   [label="5: PLLC_per"];
				pPLLD_per   [label="5: PLLD_per"];
				pPLLH_aux   [label="5: PLLH_aux"];

				GND        -> pGND        -> per_mux;
				OSC        -> pOSC        -> per_mux;
				testdebug0 -> ptestdebug0 -> per_mux;
				testdebug1 -> ptestdebug1 -> per_mux;
				PLLA_per   -> pPLLA_per   -> per_mux;
				PLLC_per   -> pPLLC_per   -> per_mux;
				PLLD_per   -> pPLLD_per   -> per_mux;
				PLLH_aux   -> pPLLH_aux   -> per_mux;
			}

			per_mux -> vec;
			per_mux -> uart;
			per_mux -> hsm;
			per_mux -> emmc;
			per_mux -> pwm;
			per_mux -> pcm;
			per_mux -> aveo;
			per_mux -> cam0;
			per_mux -> cam1;
			per_mux -> dft;
			per_mux -> dpi;
			per_mux -> dsi0e;
			per_mux -> dsi1e;
			per_mux -> gp0;
			per_mux -> gp1;
			per_mux -> gp2;
			per_mux -> slim;
			per_mux -> smi;
		}

		subgraph cluster_osc_clocks {
			label = "osc-clocks";

			subgraph cluster_osc_mux {
				label = "osc-mux";

				oGND        [label="0: GND"];
				oOSC        [label="1: OSC"];
				otestdebug0 [label="2: testdebug0"];
				otestdebug1 [label="3: testdebug1"];

				GND        -> oGND        -> osc_mux;
				OSC        -> oOSC        -> osc_mux;
				testdebug0 -> otestdebug0 -> osc_mux;
				testdebug1 -> otestdebug1 -> osc_mux;
			}

			osc_mux -> tsens;
			osc_mux -> tec;
			osc_mux -> otp;
		}

		subgraph cluster_unknown_mux_clocks {
			label = "unknown-parent-mux-clocks";

			ukn_mux -> ccp2;
			ukn_mux -> dsi0pix;
			ukn_mux -> dsi1pix;
			ukn_mux -> pulse;
			ukn_mux -> td0;
			ukn_mux -> td1;
		}

		subgraph cluster_debug_clocks {
			label = "debug-clocks";

			debug_mux -> peria;
			debug_mux -> sys;
		}
	}

	subgraph cluster_aux {
		label = ?auxiliar-clocks";

		vpu -> spi1;
		vpu -> spi2;
		vpu -> uart1;
	}
}
--- cut here ---

I have no idea where we could put this information
in the kernel tree - maybe this would help.

From this you can see that we have:
* PLL that is not configured now:
  * PLLB
* a few more PLL-dividers that are not configured:
  * PLLB_ARM
  * PLLB_SP0
  * PLLB_SP1
  * PLLB_SP2
  * PLLD_dsi0
  * PLLD_dsi1
  * PLLH_rcal
* a few clocks which Eric has said are wrong and where
  the corresponding parents need to get found:
  * ccp2 (gate)
  * dsi0pix (gate - maybe PLLD_dis0?)
  * dis1pix (gate - maybe PLLD_dis1)
  * pulse (gate)
  * td0
  * td1
* debug clocks that require a running debug power domain:
  * peria
  * sys
* missing clocks in the current driver:
  * aveo
  * cam0
  * cam1
  * ccp2 (see note above)
  * dtf
  * dpi
  * dsi0e   (maybe this also uses a different parent clock mux?)
  * dsi0pix (maybe this also uses a different parent clock mux?)
  * dsi1e   (maybe this also uses a different parent clock mux?)
  * dsi1pix (maybe this also uses a different parent clock mux?)
  * gp0
  * gp1
  * gp2
  * peria (see note above)
  * pulse (see note above)
  * slim
  * smi
  * td0 (see note above)
  * td1 (see note above)
  * td2 (see note above)
  * tec
  * sys (see note above)
* generic clock that is supposedly not in use

I can create a new patch that will include all those
missing clocks that are undisputed in their settings
(hence without any comments/notes) - I hope this is acceptable.

If someone has any ideas about those clocks where we 
miss the correct parents/mux, then please add your
wisdom.




From lorenzo.pieralisi at arm.com  Wed Feb 17 10:39:30 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 17 Feb 2016 18:39:30 +0000
Subject: [PATCH V5 09/15] acpi, mcfg: Add default PCI config accessors
 implementation and initial support for related quirks.
In-Reply-To: <1455630825-27253-10-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
 <1455630825-27253-10-git-send-email-tn@semihalf.com>
Message-ID: <20160217183930.GC11132@red-moon>

On Tue, Feb 16, 2016 at 02:53:39PM +0100, Tomasz Nowicki wrote:
> We use generic accessors from access.c by default. However, we already
> know platforms that need special handling while accessing to PCI config
> space. These platforms will need different accessors set matched against
> platform ID, domain, bus touple. Therefore we are going to add (in future)
> DECLARE_ACPI_MCFG_FIXUP which will register platform specific custom
> accessors. For now, we let pci_mcfg_get_ops to take acpi_pci_root structure
> as an arguments and left some space for quirk matching algorithm.

You should not describe the future (because you do not know if/when
that will be implemented), you should describe what the patch does
in its current form.

"This patch implements MCFG based PCI bus operations through MCFG
map function and generic PCI accessors".

> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
> Tested-by: Duc Dang <dhdang at apm.com>
> Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
> Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
> Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
> Tested-by: Sinan Kaya <okaya at codeaurora.org>
> ---
>  drivers/acpi/pci_mcfg.c  | 30 ++++++++++++++++++++++++++++++
>  include/linux/pci-acpi.h | 12 ++++++++++++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index 3282f2a..0062257 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -41,6 +41,36 @@ int __weak raw_pci_write(unsigned int domain, unsigned int bus,
>  	return PCIBIOS_DEVICE_NOT_FOUND;
>  }
>  
> +void __iomem *
> +pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
> +{
> +	struct pci_mmcfg_region *cfg;
> +
> +	cfg = pci_mmconfig_lookup(pci_domain_nr(bus), bus->number);
> +	if (cfg && cfg->virt)
> +		return cfg->virt +
> +			(PCI_MMCFG_BUS_OFFSET(bus->number) | (devfn << 12)) +
> +			offset;
> +	return NULL;
> +}
> +
> +/* Default generic PCI config accessors */
> +static struct pci_ops default_pci_mcfg_ops = {
> +	.map_bus = pci_mcfg_dev_base,
> +	.read = pci_generic_config_read,
> +	.write = pci_generic_config_write,
> +};

Nit: s/default_pci_mcfg_ops/pci_mcfg_ops

> +
> +struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
> +{
> +	/*
> +	 * TODO: Match against platform specific quirks and return
> +	 * corresponding PCI config space accessor set.
> +	 */

Remove this comment, see above.

> +
> +	return &default_pci_mcfg_ops;

See above.

> +}
> +
>  static void list_add_sorted(struct pci_mmcfg_region *new)
>  {
>  	struct pci_mmcfg_region *cfg;
> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
> index b4f87ba9..3dc6a8c 100644
> --- a/include/linux/pci-acpi.h
> +++ b/include/linux/pci-acpi.h
> @@ -141,6 +141,18 @@ extern struct list_head pci_mmcfg_list;
>  #define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
>  #define PCI_MMCFG_OFFSET(bus, devfn)   ((bus) << 20 | (devfn) << 12)
>  
> +#ifdef	CONFIG_PCI_MMCONFIG
> +extern struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
> +extern void __iomem *pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn,
> +				       int offset);
> +#else
> +static inline struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
> +{ return NULL; }
> +static inline void __iomem *pci_mcfg_dev_base(struct pci_bus *bus,
> +					      unsigned int devfn, int offset)
> +{ return NULL; }
> +#endif
> +
>  #else	/* CONFIG_ACPI */
>  static inline void acpi_pci_add_bus(struct pci_bus *bus) { }
>  static inline void acpi_pci_remove_bus(struct pci_bus *bus) { }

I think it can even be squashed, anyway:

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>


From paul at pwsan.com  Wed Feb 17 10:41:23 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 17 Feb 2016 18:41:23 +0000 (UTC)
Subject: [GIT PULL] ARM: OMAP2+: first set of hwmod fixes and additions for
 v4.6
Message-ID: <alpine.DEB.2.02.1602171838420.11377@utopia.booyaka.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tony

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v4.6/omap-hwmod-a

for you to fetch changes up to 8fe097a3d99e22355fb8e3bcee59542bf3f46b2d:

  ARM: DRA7: hwmod: Add reset data for PCIe (2016-02-09 02:18:52 -0700)

- ----------------------------------------------------------------
ARM: OMAP2+: first set of hwmod fixes and additions for v4.6

A few fixes for OMAP hwmod data.  SSI hwmod data for the OMAP 3730,
and some fixes for the DRA7xx hwmod data.  These shouldn't interfere
or impact anything else.

Basic build, boot, and PM test logs are available here:

http://www.pwsan.com/omap/testlogs/omap-hwmod-a-for-v4.6/20160214161224/

- ----------------------------------------------------------------
Kishon Vijay Abraham I (2):
      ARM: DRA7: hwmod: Fix OCP2SCP sysconfig
      ARM: DRA7: hwmod: Add reset data for PCIe

Sebastian Reichel (1):
      ARM: OMAP2+: hwmod data: Add SSI data for omap36xx

 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 +++++++------
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  | 18 ++++++++++++++++--
 arch/arm/mach-omap2/prm7xx.h               |  1 +
 3 files changed, 24 insertions(+), 8 deletions(-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1


vzCJhDnE4VH3QLcUmoWf
=Qyj4
-----END PGP SIGNATURE-----


From agust at denx.de  Wed Feb 17 10:48:19 2016
From: agust at denx.de (Anatolij Gustschin)
Date: Wed, 17 Feb 2016 19:48:19 +0100
Subject: [PATCH] clk: imx: correct pwm7 clock name in driver for i.MX6UL
Message-ID: <1455734900-1913-1-git-send-email-agust@denx.de>

Don't capitalize p in the pwm7 clock name.

Signed-off-by: Anatolij Gustschin <agust at denx.de>
---
 drivers/clk/imx/clk-imx6ul.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index 01718d0..15f2ac8 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -394,7 +394,7 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
 	clks[IMX6UL_CLK_I2C4]		= imx_clk_gate2("i2c4",		"perclk", 	 base + 0x80,	24);
 	clks[IMX6UL_CLK_PWM5]		= imx_clk_gate2("pwm5",		"perclk",	 base + 0x80,	26);
 	clks[IMX6UL_CLK_PWM6]		= imx_clk_gate2("pwm6",		"perclk",	 base +	0x80,	28);
-	clks[IMX6UL_CLK_PWM7]		= imx_clk_gate2("Pwm7",		"perclk",	 base + 0x80,	30);
+	clks[IMX6UL_CLK_PWM7]		= imx_clk_gate2("pwm7",		"perclk",	 base + 0x80,	30);
 
 	/* mask handshake of mmdc */
 	writel_relaxed(BM_CCM_CCDR_MMDC_CH0_MASK, base + CCDR);
-- 
1.7.9.5



From agust at denx.de  Wed Feb 17 10:48:20 2016
From: agust at denx.de (Anatolij Gustschin)
Date: Wed, 17 Feb 2016 19:48:20 +0100
Subject: [PATCH] clk: imx: correct pwm7 clock name in driver for i.MX6UL
In-Reply-To: <1455734900-1913-1-git-send-email-agust@denx.de>
References: <1455734900-1913-1-git-send-email-agust@denx.de>
Message-ID: <1455734900-1913-2-git-send-email-agust@denx.de>

Don't capitalize p in the pwm7 clock name.

Signed-off-by: Anatolij Gustschin <agust at denx.de>
---
 drivers/clk/imx/clk-imx6ul.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index 01718d0..15f2ac8 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -394,7 +394,7 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
 	clks[IMX6UL_CLK_I2C4]		= imx_clk_gate2("i2c4",		"perclk", 	 base + 0x80,	24);
 	clks[IMX6UL_CLK_PWM5]		= imx_clk_gate2("pwm5",		"perclk",	 base + 0x80,	26);
 	clks[IMX6UL_CLK_PWM6]		= imx_clk_gate2("pwm6",		"perclk",	 base +	0x80,	28);
-	clks[IMX6UL_CLK_PWM7]		= imx_clk_gate2("Pwm7",		"perclk",	 base + 0x80,	30);
+	clks[IMX6UL_CLK_PWM7]		= imx_clk_gate2("pwm7",		"perclk",	 base + 0x80,	30);
 
 	/* mask handshake of mmdc */
 	writel_relaxed(BM_CCM_CCDR_MMDC_CH0_MASK, base + CCDR);
-- 
1.7.9.5



From ddaney at caviumnetworks.com  Wed Feb 17 10:57:50 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Wed, 17 Feb 2016 10:57:50 -0800
Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <20160217112931.GB31970@arm.com>
References: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160214170152.GC3965@htj.duckdns.org> <56C147B2.9010303@caviumnetworks.com>
 <20160215183041.GH3965@htj.duckdns.org>
 <20160216144250.GD31343@rric.localdomain>
 <56C37524.5090000@caviumnetworks.com> <56C37AD3.4030407@caviumnetworks.com>
 <56C37D94.8080403@caviumnetworks.com>
 <20160216211410.GI25086@rric.localdomain>
 <56C3AD1C.2000003@caviumnetworks.com> <20160217112931.GB31970@arm.com>
Message-ID: <56C4C2AE.90009@caviumnetworks.com>

On 02/17/2016 03:29 AM, Will Deacon wrote:
> On Tue, Feb 16, 2016 at 03:13:32PM -0800, Tirumalesh Chalamarla wrote:
>> On 02/16/2016 01:14 PM, Robert Richter wrote:
>>> CONFIG_CAVIUM_ERRATUM_22536 is exactly that you need. It is not only
>>> used for core interrupts, e.g. also for gicv3 devices (and now also
>>> for ahci). Non-core errata (e.g. CONFIG_CAVIUM_ERRATUM_23144) are not
>>> enabled in the arm64 cpu errata framework (not handled in
>>> arch/arm64/kernel/cpu_errata.c).
>>>
>>> Thus,
>>>
>>> #ifdef CONFIG_CAVIUM_ERRATUM_22536
>>> 	if (pdev->vendor == 0x177d && pdev->device == 0xa01c)
>>> 		ahci_thunderx_init(&pdev->dev, hpriv);
>>> #endif
>>>
>>> is the correct enablement of the workaround by device id.
>>>
>>> And, CAVIUM_ERRATUM_* is very easy to handle, enable and document.
>>>
>> The code will only run for Thunder and AHCI, becuase its PCI.
>
> Well, the guards also serve as documentation for exactly why we're having
> to do something special here, so I'd say go ahead and add
> CONFIG_CAVIUM_ERRATUM_22536 and update
> Documentation/arm64/silicon-errata.txt accordingly.
>

If the ahci/ata maintainers insist, we can add that.

<sarcasm>
Should we also add some CONFIG_ variables for:

   ahci_mcp89_apple_enable()
   ahci_sb600_enable_64bit()
   ahci_p5wdh_workaround()
   .
   .
   .

Surely we would wish to give people the flexibility to trim that code 
out of the driver if they know that it is not needed.

And don't even get me started on drivers/pci/quirks.c ...

</sarcasm>


>
>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



From festevam at gmail.com  Wed Feb 17 10:58:13 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 17 Feb 2016 16:58:13 -0200
Subject: [PATCH] clk: imx: correct pwm7 clock name in driver for i.MX6UL
In-Reply-To: <1455734900-1913-1-git-send-email-agust@denx.de>
References: <1455734900-1913-1-git-send-email-agust@denx.de>
Message-ID: <CAOMZO5Cwed8uOKz6=Odu=jaaBqoNzUxm2Xv3+6TAxKGsa27Mdw@mail.gmail.com>

On Wed, Feb 17, 2016 at 4:48 PM, Anatolij Gustschin <agust at denx.de> wrote:
> Don't capitalize p in the pwm7 clock name.
>
> Signed-off-by: Anatolij Gustschin <agust at denx.de>

Thanks.

Reviewed-by: Fabio Estevam <fabio.estevam at nxp.com>


From akpm at linux-foundation.org  Wed Feb 17 11:02:31 2016
From: akpm at linux-foundation.org (Andrew Morton)
Date: Wed, 17 Feb 2016 11:02:31 -0800
Subject: [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag
In-Reply-To: <20160217115347.GA28433@e106950-lin.cambridge.arm.com>
References: <cover.1454950917.git.brian.starkey@arm.com>
 <9085d37fa97a762a46b9d58719c085368682c64f.1454950917.git.brian.starkey@arm.com>
 <20160208120317.313409dc0ae7634c25d3f021@linux-foundation.org>
 <20160209102300.GB23507@e106950-lin.cambridge.arm.com>
 <20160217115347.GA28433@e106950-lin.cambridge.arm.com>
Message-ID: <20160217110231.d4040207cc1456bd991ff0e7@linux-foundation.org>

On Wed, 17 Feb 2016 11:53:48 +0000 Brian Starkey <brian.starkey at arm.com> wrote:

> Hi Andrew,
> 
> Would you pick these up if I rebase onto linux-next?

Sure.

> How strongly do you feel about the input argument modification vs.
> staying in-line with the rest of the function?

I see no reason why memremap() is modifying `flags' as it proceeds -
these flags are all disjoint so it's pointless.  I suggest you simply
take all that out in a preparatory patch.



From sebott at linux.vnet.ibm.com  Wed Feb 17 11:04:58 2016
From: sebott at linux.vnet.ibm.com (Sebastian Ott)
Date: Wed, 17 Feb 2016 20:04:58 +0100 (CET)
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160217150456.GA15882@node.shutemov.name>
References: <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name> <56BE00E7.1010303@de.ibm.com>
 <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
 <alpine.LFD.2.20.1602131238260.1910@schleppi>
 <20160215113159.GA28832@node.shutemov.name> <20160215193702.4a15ed5e@thinkpad>
 <20160215213526.GA9766@node.shutemov.name> <20160216172444.013988d8@thinkpad>
 <20160217150456.GA15882@node.shutemov.name>
Message-ID: <alpine.LFD.2.20.1602171954400.1773@schleppi>

Hi,

On Wed, 17 Feb 2016, Kirill A. Shutemov wrote:
> On Tue, Feb 16, 2016 at 05:24:44PM +0100, Gerald Schaefer wrote:
> > On Mon, 15 Feb 2016 23:35:26 +0200
> > "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> > 
> > > Is there any chance that I'll be able to trigger the bug using QEMU?
> > > Does anybody have an QEMU image I can use?
> > > 
> > 
> > I have no image, but trying to reproduce this under virtualization may
> > help to trigger this also on other architectures. After ruling out IPI
> > vs. fast_gup I do not really see why this should be arch-specific, and
> > it wouldn't be the first time that we hit subtle races first on s390, due
> > to our virtualized environment (my test case is make -j20 with 10 CPUs and
> > 4GB of memory, no swap).
> 
> Could you post your kernel config?

Attached.

> It would be nice also to check if disabling split_huge_page() would make
> any difference:
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index a75081ca31cf..26d2b7b21021 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3364,6 +3364,8 @@ int split_huge_page_to_list(struct page *page, struct list_head *list)
>  	bool mlocked;
>  	unsigned long flags;
> 
> +	return -EBUSY;
> +
>  	VM_BUG_ON_PAGE(is_huge_zero_page(page), page);
>  	VM_BUG_ON_PAGE(!PageAnon(page), page);
>  	VM_BUG_ON_PAGE(!PageLocked(page), page);
> -- 

65c23c6 + this patch also oopsed:

? 1707.903808! ODEBUG: active_state not available (active state 0) object type:
rcu_head hint:           (null)
? 1707.903852! ------------? cut here !------------
? 1707.903854! WARNING: at lib/debugobjects.c:263
? 1707.903856! Modules linked in: bridge stp llc btrfs mlx4_ib mlx4_en ib_sa vxl
an ib_mad ip6_udp_tunnel ib_core udp_tunnel ptp pps_core ib_addr xor raid6_pq gh
ash_s390 mlx4_core prng ecb aes_s390 des_s390 des_generic sha512_s390 dm_mod sha
256_s390 genwqe_card sha1_s390 sha_common crc_itu_t scm_block eadm_sch vhost_net
tun vhost macvtap macvlan kvm autofs4
? 1707.903892! CPU: 4 PID: 25215 Comm: git Not tainted 4.5.0-rc4-00037-g65c23c6-
dirty #273
? 1707.903894! task: 0000000006a60000 ti: 0000000063b04000 task.ti: 0000000063b0
4000
? 1707.903896! Krnl PSW : 0404c00180000000 0000000000486ce0 (debug_print_object+
							     0xb0/0xd0)
? 1707.903905!            R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:
3
Krnl GPRS: 0000000001a361c7 0000000006a60000 0000000000000060 0000000000000101
? 1707.903908!            0000000000486cdc 0000000000000000 000000000088cbdc 000
0000001b53848
? 1707.903910!            0700000000000001 0000000000000000 0000000001b53850 000
00000008bb820
? 1707.903912!            0000000000a8d710 00000000dcdd3d38 0000000000486cdc 000
00000dcdd3c38
? 1707.903920! Krnl Code: 0000000000486cd0: c0200021a496        larl    %%r2,8bb
5fc
0000000000486cd6: c0e5ffee03a1       brasl   %%r14,247418
#0000000000486cdc: a7f40001           brc     15,486cde
>0000000000486ce0: c41d002f488e       lrl     %%r1,a6fdfc
0000000000486ce6: e340f0e80004       lg      %%r4,232(%%r15)
0000000000486cec: a71a0001           ahi     %%r1,1
0000000000486cf0: eb6ff0a80004       lmg     %%r6,%%r15,168(%%r15)
0000000000486cf6: c41f002f4883       strl    %%r1,a6fdfc
? 1707.903960! Call Trace:
? 1707.903962! (?<0000000000486cdc>! debug_print_object+0xac/0xd0)
? 1707.903964!  ?<0000000000488094>! debug_object_active_state+0x164/0x178
? 1707.903969!  ?<00000000001b991c>! rcu_process_callbacks+0x564/0x9e8
? 1707.903973!  ?<000000000013d3ee>! __do_softirq+0x256/0x568
? 1707.903975!  ?<000000000013da3a>! irq_exit+0x7a/0xd8
? 1707.903979!  ?<000000000010c87e>! do_IRQ+0x86/0xc0
? 1707.903984!  ?<00000000006fa3f2>! ext_int_handler+0x11e/0x124
? 1707.903987!  ?<0000000000199bfe>! lock_release+0x5ce/0x670
? 1707.903989! (?<0000000000199be0>! lock_release+0x5b0/0x670)
? 1707.903993!  ?<00000000002dffa2>! getname_flags+0x82/0x218
? 1707.903994!  ?<00000000002e04e8>! user_path_at_empty+0x40/0x68
? 1707.903998!  ?<00000000002d44a4>! vfs_fstatat+0x6c/0xc8
? 1707.903999!  ?<00000000002d4894>! SyS_newlstat+0x2c/0x48
? 1707.904002!  ?<00000000006f9cce>! system_call+0xd6/0x258
? 1707.904003!  ?<000003ffb45f1124>! 0x3ffb45f1124
? 1707.904005! 1 lock held by git/25215:
? 1707.904006!  #0:  (&obj_hash?i!.lock){-.-.-.}, at: ?<0000000000487fdc>! debug
_object_active_state+0xac/0x178
? 1707.904012! Last Breaking-Event-Address:
? 1707.904014!  ?<0000000000486cdc>! debug_print_object+0xac/0xd0
? 1707.904016! ---? end trace 8ce68dc422e8321c !---
? 1707.904018! ODEBUG: deactivate not available (active state 0) object type: rc
u_head hint:           (null)
? 1707.904026! ------------? cut here !------------
? 1707.904027! WARNING: at lib/debugobjects.c:263
? 1707.904028! Modules linked in: bridge stp llc btrfs mlx4_ib mlx4_en ib_sa vxl
an ib_mad ip6_udp_tunnel ib_core udp_tunnel ptp pps_core ib_addr xor raid6_pq gh
ash_s390 mlx4_core prng ecb aes_s390 des_s390 des_generic sha512_s390 dm_mod sha
256_s390 genwqe_card sha1_s390 sha_common crc_itu_t scm_block eadm_sch vhost_net
tun vhost macvtap macvlan kvm autofs4
? 1707.904055! CPU: 4 PID: 25215 Comm: git Tainted: G        W       4.5.0-rc4-0
0037-g65c23c6-dirty #273
? 1707.904057! task: 0000000006a60000 ti: 0000000063b04000 task.ti: 0000000063b0
4000
? 1707.904058! Krnl PSW : 0404c00180000000 0000000000486ce0 (debug_print_object+
							     0xb0/0xd0)
? 1707.904062!            R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:
3
Krnl GPRS: 0000000001a361c7 0000000006a60000 000000000000005e 0000000000000101
? 1707.904066!            0000000000486cdc 0000000000000000 000000000088cbdc 000
000000000000a
? 1707.904068!            0000000091cdb020 07000000dcdd3c68 0000000001b53850 000
00000008979ea
? 1707.904069!            0000000000a8d710 00000000dcdd3d48 0000000000486cdc 000
00000dcdd3c48
? 1707.904074! Krnl Code: 0000000000486cd0: c0200021a496        larl    %%r2,8bb
5fc
0000000000486cd6: c0e5ffee03a1       brasl   %%r14,247418
#0000000000486cdc: a7f40001           brc     15,486cde
>0000000000486ce0: c41d002f488e       lrl     %%r1,a6fdfc
0000000000486ce6: e340f0e80004       lg      %%r4,232(%%r15)
0000000000486cec: a71a0001           ahi     %%r1,1
0000000000486cf0: eb6ff0a80004       lmg     %%r6,%%r15,168(%%r15)
0000000000486cf6: c41f002f4883       strl    %%r1,a6fdfc
? 1707.904088! Call Trace:
? 1707.904090! (?<0000000000486cdc>! debug_print_object+0xac/0xd0)
? 1707.904092!  ?<0000000000487a38>! debug_object_deactivate+0x170/0x188
? 1707.904094!  ?<00000000001b992e>! rcu_process_callbacks+0x576/0x9e8
? 1707.904096!  ?<000000000013d3ee>! __do_softirq+0x256/0x568
? 1707.904098!  ?<000000000013da3a>! irq_exit+0x7a/0xd8
? 1707.904100!  ?<000000000010c87e>! do_IRQ+0x86/0xc0
? 1707.904102!  ?<00000000006fa3f2>! ext_int_handler+0x11e/0x124
? 1707.904104!  ?<0000000000199bfe>! lock_release+0x5ce/0x670
? 1707.904106! (?<0000000000199be0>! lock_release+0x5b0/0x670)
? 1707.904108!  ?<00000000002dffa2>! getname_flags+0x82/0x218
? 1707.904109!  ?<00000000002e04e8>! user_path_at_empty+0x40/0x68
? 1707.904111!  ?<00000000002d44a4>! vfs_fstatat+0x6c/0xc8
? 1707.904113!  ?<00000000002d4894>! SyS_newlstat+0x2c/0x48
? 1707.904115!  ?<00000000006f9cce>! system_call+0xd6/0x258
? 1707.904117!  ?<000003ffb45f1124>! 0x3ffb45f1124
? 1707.904118! 1 lock held by git/25215:
? 1707.904119!  #0:  (&obj_hash?i!.lock){-.-.-.}, at: ?<000000000048796c>! debug
_object_deactivate+0xa4/0x188
? 1707.904124! Last Breaking-Event-Address:
? 1707.904126!  ?<0000000000486cdc>! debug_print_object+0xac/0xd0
? 1707.904128! ---? end trace 8ce68dc422e8321d !---
? 1707.904150! ------------? cut here !------------
? 1707.904152! Kernel BUG at 0000000008cf8002 ?verbose debug info unavailable!
? 1707.904197! illegal operation: 0001 ilc:1 ?#1! PREEMPT SMP DEBUG_PAGEALLOC
? 1707.904203! Modules linked in: bridge stp llc btrfs mlx4_ib mlx4_en ib_sa vxl
an ib_mad ip6_udp_tunnel ib_core udp_tunnel ptp pps_core ib_addr xor raid6_pq gh
ash_s390 mlx4_core prng ecb aes_s390 des_s390 des_generic sha512_s390 dm_mod sha
256_s390 genwqe_card sha1_s390 sha_common crc_itu_t scm_block eadm_sch vhost_net
tun vhost macvtap macvlan kvm autofs4
? 1707.904240! CPU: 4 PID: 25215 Comm: git Tainted: G        W       4.5.0-rc4-0
0037-g65c23c6-dirty #273
? 1707.904242! task: 0000000006a60000 ti: 0000000063b04000 task.ti: 0000000063b0
4000
? 1707.904244! Krnl PSW : 0704d00180000000 0000000008cf8002 (0x8cf8002)
? 1707.904248!            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:
3
Krnl GPRS: 0000000000000000 0000000008cf8000 0000000091cdb020 0000000091cdb020
? 1707.904252!            00000000001b9964 0000000000000000 0000000000000000 000
000000000000a
? 1707.904254!            0000000000000000 0000000008cf8000 0000000000000004 000
00000034d6802
? 1707.904256!            00000000dec0f600 00000000007063d8 00000000001b99ae 000
00000dcdd3d18
? 1707.904263! Krnl Code: 0000000008cf7ff6: 5a5a5a5a            a       %%r5,265
0(%%r10,%%r5)
0000000008cf7ffa: 5a5a5a5a           a       %%r5,2650(%%r10,%%r5)
#0000000008cf7ffe: 5a5a0000           a       %%r5,0(%%r10,%%r0)
>0000000008cf8002: 0000               unknown
0000000008cf8004: 0000               unknown
0000000008cf8006: 0020               unknown
0000000008cf8008: 0000               unknown
0000000008cf800a: 0000               unknown
? 1707.904277! Call Trace:
? 1707.904279! (?<00000000001b9964>! rcu_process_callbacks+0x5ac/0x9e8)
? 1707.904282!  ?<000000000013d3ee>! __do_softirq+0x256/0x568
? 1707.904284!  ?<000000000013da3a>! irq_exit+0x7a/0xd8
? 1707.904286!  ?<000000000010c87e>! do_IRQ+0x86/0xc0
? 1707.904289!  ?<00000000006fa3f2>! ext_int_handler+0x11e/0x124
? 1707.904291!  ?<0000000000199bfe>! lock_release+0x5ce/0x670
? 1707.904293! (?<0000000000199be0>! lock_release+0x5b0/0x670)
? 1707.904295!  ?<00000000002dffa2>! getname_flags+0x82/0x218
? 1707.904297!  ?<00000000002e04e8>! user_path_at_empty+0x40/0x68
? 1707.904299!  ?<00000000002d44a4>! vfs_fstatat+0x6c/0xc8
? 1707.904301!  ?<00000000002d4894>! SyS_newlstat+0x2c/0x48
? 1707.904303!  ?<00000000006f9cce>! system_call+0xd6/0x258
? 1707.904305!  ?<000003ffb45f1124>! 0x3ffb45f1124
? 1707.904307! INFO: lockdep is turned off.
? 1707.904308! Last Breaking-Event-Address:
? 1707.904310!  ?<00000000001b99ac>! rcu_process_callbacks+0x5f4/0x9e8
? 1707.904314!
? 1707.904315! Kernel panic - not syncing: Fatal exception in interrupt
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/s390 4.5.0-rc3 Kernel Configuration
#
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_GENERIC_LOCKBREAK=y
CONFIG_PGSTE=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_KEXEC=y
CONFIG_AUDIT_ARCH=y
CONFIG_NO_IOPORT_MAP=y
# CONFIG_PCI_QUIRKS is not set
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_S390=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_CGROUPS=y
# CONFIG_MEMCG is not set
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
# CONFIG_CGROUP_PIDS is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_HUGETLB is not set
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_PERF=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
# CONFIG_USER_NS is not set
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_BPF=y
# CONFIG_EXPERT is not set
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL is not set
CONFIG_SYSFS_SYSCALL=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_HAVE_FUTEX_CMPXCHG=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
# CONFIG_BPF_SYSCALL is not set
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
# CONFIG_USERFAULTFD is not set
CONFIG_MEMBARRIER=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_SLUB_CPU_PARTIAL=y
# CONFIG_SYSTEM_DATA_VERIFICATION is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_KEXEC_CORE=y
CONFIG_OPROFILE=m
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_JUMP_LABEL=y
# CONFIG_STATIC_KEYS_SELFTEST is not set
# CONFIG_UPROBES is not set
CONFIG_HAVE_64BIT_ALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y
CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
# CONFIG_CC_STACKPROTECTOR is not set
CONFIG_HAVE_VIRT_CPU_ACCOUNTING=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_HAVE_ARCH_SOFT_DIRTY=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_RELA=y
CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
CONFIG_CLONE_BACKWARDS2=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y
CONFIG_COMPAT_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
# CONFIG_MODULE_SIG is not set
CONFIG_MODULE_COMPRESS=y
# CONFIG_MODULE_COMPRESS_GZIP is not set
CONFIG_MODULE_COMPRESS_XZ=y
CONFIG_MODULES_TREE_LOOKUP=y
CONFIG_BLOCK=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_BSGLIB=y
CONFIG_BLK_DEV_INTEGRITY=y
CONFIG_BLK_DEV_THROTTLING=y
# CONFIG_BLK_CMDLINE_PARSER is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_AIX_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
CONFIG_IBM_PARTITION=y
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
# CONFIG_CMDLINE_PARTITION is not set
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_CFQ_GROUP_IOSCHED=y
CONFIG_DEFAULT_DEADLINE=y
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="deadline"
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_ASN1=m
CONFIG_ARCH_INLINE_SPIN_TRYLOCK=y
CONFIG_ARCH_INLINE_SPIN_TRYLOCK_BH=y
CONFIG_ARCH_INLINE_SPIN_LOCK=y
CONFIG_ARCH_INLINE_SPIN_LOCK_BH=y
CONFIG_ARCH_INLINE_SPIN_LOCK_IRQ=y
CONFIG_ARCH_INLINE_SPIN_LOCK_IRQSAVE=y
CONFIG_ARCH_INLINE_SPIN_UNLOCK=y
CONFIG_ARCH_INLINE_SPIN_UNLOCK_BH=y
CONFIG_ARCH_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_ARCH_INLINE_SPIN_UNLOCK_IRQRESTORE=y
CONFIG_ARCH_INLINE_READ_TRYLOCK=y
CONFIG_ARCH_INLINE_READ_LOCK=y
CONFIG_ARCH_INLINE_READ_LOCK_BH=y
CONFIG_ARCH_INLINE_READ_LOCK_IRQ=y
CONFIG_ARCH_INLINE_READ_LOCK_IRQSAVE=y
CONFIG_ARCH_INLINE_READ_UNLOCK=y
CONFIG_ARCH_INLINE_READ_UNLOCK_BH=y
CONFIG_ARCH_INLINE_READ_UNLOCK_IRQ=y
CONFIG_ARCH_INLINE_READ_UNLOCK_IRQRESTORE=y
CONFIG_ARCH_INLINE_WRITE_TRYLOCK=y
CONFIG_ARCH_INLINE_WRITE_LOCK=y
CONFIG_ARCH_INLINE_WRITE_LOCK_BH=y
CONFIG_ARCH_INLINE_WRITE_LOCK_IRQ=y
CONFIG_ARCH_INLINE_WRITE_LOCK_IRQSAVE=y
CONFIG_ARCH_INLINE_WRITE_UNLOCK=y
CONFIG_ARCH_INLINE_WRITE_UNLOCK_BH=y
CONFIG_ARCH_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_ARCH_INLINE_WRITE_UNLOCK_IRQRESTORE=y
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
CONFIG_RWSEM_SPIN_ON_OWNER=y
CONFIG_LOCK_SPIN_ON_OWNER=y
CONFIG_FREEZER=y
CONFIG_HAVE_LIVEPATCH=y

#
# Processor type and features
#
CONFIG_HAVE_MARCH_Z900_FEATURES=y
CONFIG_HAVE_MARCH_Z990_FEATURES=y
CONFIG_HAVE_MARCH_Z9_109_FEATURES=y
CONFIG_HAVE_MARCH_Z10_FEATURES=y
CONFIG_HAVE_MARCH_Z196_FEATURES=y
# CONFIG_HAVE_MARCH_ZEC12_FEATURES is not set
# CONFIG_HAVE_MARCH_Z13_FEATURES is not set
# CONFIG_MARCH_Z900 is not set
# CONFIG_MARCH_Z990 is not set
# CONFIG_MARCH_Z9_109 is not set
# CONFIG_MARCH_Z10 is not set
CONFIG_MARCH_Z196=y
# CONFIG_MARCH_ZEC12 is not set
# CONFIG_MARCH_Z13 is not set
# CONFIG_MARCH_Z900_TUNE is not set
# CONFIG_MARCH_Z990_TUNE is not set
# CONFIG_MARCH_Z9_109_TUNE is not set
# CONFIG_MARCH_Z10_TUNE is not set
# CONFIG_MARCH_Z196_TUNE is not set
CONFIG_MARCH_ZEC12_TUNE=y
# CONFIG_MARCH_Z13_TUNE is not set
# CONFIG_TUNE_DEFAULT is not set
# CONFIG_TUNE_Z900 is not set
# CONFIG_TUNE_Z990 is not set
# CONFIG_TUNE_Z9_109 is not set
# CONFIG_TUNE_Z10 is not set
# CONFIG_TUNE_Z196 is not set
CONFIG_TUNE_ZEC12=y
# CONFIG_TUNE_Z13 is not set
CONFIG_64BIT=y
CONFIG_COMPAT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_KEYS_COMPAT=y
CONFIG_SMP=y
CONFIG_NR_CPUS=256
CONFIG_HOTPLUG_CPU=y
# CONFIG_NODES_SPAN_OTHER_NODES is not set
# CONFIG_NUMA is not set
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
CONFIG_SCHED_BOOK=y
CONFIG_SCHED_TOPOLOGY=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y

#
# Memory setup
#
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
CONFIG_FORCE_MAX_ZONEORDER=9
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_HAVE_MEMBLOCK_PHYS_MAP=y
CONFIG_NO_BOOTMEM=y
CONFIG_MEMORY_ISOLATION=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_MEMORY_HOTPLUG=y
CONFIG_MEMORY_HOTPLUG_SPARSE=y
CONFIG_MEMORY_HOTREMOVE=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_MEMORY_BALLOON=y
CONFIG_BALLOON_COMPACTION=y
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
# CONFIG_CMA is not set
# CONFIG_ZPOOL is not set
# CONFIG_ZBUD is not set
# CONFIG_ZSMALLOC is not set
# CONFIG_IDLE_PAGE_TRACKING is not set
CONFIG_PACK_STACK=y
CONFIG_CHECK_STACK=y
CONFIG_STACK_GUARD=256
# CONFIG_WARN_DYNAMIC_STACK is not set

#
# I/O subsystem
#
CONFIG_QDIO=y
CONFIG_PCI=y
CONFIG_PCI_NR_FUNCTIONS=64
CONFIG_PCI_NR_MSI=256
CONFIG_PCI_BUS_ADDR_T_64BIT=y
CONFIG_PCI_MSI=y
CONFIG_PCI_DEBUG=y
# CONFIG_PCI_REALLOC_ENABLE_AUTO is not set
# CONFIG_PCI_STUB is not set
CONFIG_PCI_ATS=y
CONFIG_PCI_IOV=y
# CONFIG_PCI_PRI is not set
# CONFIG_PCI_PASID is not set

#
# PCI host controller drivers
#
# CONFIG_PCIEPORTBUS is not set
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
CONFIG_HOTPLUG_PCI_S390=y
CONFIG_PCI_DOMAINS=y
CONFIG_HAS_IOMEM=y
CONFIG_IOMMU_HELPER=y
CONFIG_HAS_DMA=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_CHSC_SCH=y
CONFIG_SCM_BUS=y
CONFIG_EADM_SCH=m

#
# Dump support
#
CONFIG_CRASH_DUMP=y

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_BINFMT_SCRIPT=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=m
CONFIG_COREDUMP=y
CONFIG_SECCOMP=y

#
# Power Management
#
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_ARCH_SAVE_PAGE_KEYS=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
CONFIG_NET=y
CONFIG_NET_INGRESS=y
CONFIG_NET_EGRESS=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_DIAG=m
CONFIG_UNIX=y
CONFIG_UNIX_DIAG=m
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=m
CONFIG_XFRM_USER=m
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=m
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_IUCV=y
CONFIG_AFIUCV=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_FIB_TRIE_STATS is not set
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_ROUTE_CLASSID=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE_DEMUX=m
CONFIG_NET_IP_TUNNEL=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_SYN_COOKIES=y
CONFIG_NET_IPVTI=m
CONFIG_NET_UDP_TUNNEL=m
# CONFIG_NET_FOU is not set
# CONFIG_NET_FOU_IP_TUNNELS is not set
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_INET_UDP_DIAG=m
# CONFIG_INET_DIAG_DESTROY is not set
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
# CONFIG_TCP_CONG_DCTCP is not set
# CONFIG_TCP_CONG_CDG is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IPV6=y
CONFIG_IPV6_ROUTER_PREF=y
# CONFIG_IPV6_ROUTE_INFO is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=m
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
CONFIG_IPV6_VTI=m
CONFIG_IPV6_SIT=m
# CONFIG_IPV6_SIT_6RD is not set
CONFIG_IPV6_NDISC_NODETYPE=y
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_GRE=m
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_SUBTREES=y
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETLABEL is not set
CONFIG_NETWORK_SECMARK=y
CONFIG_NET_PTP_CLASSIFY=y
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
CONFIG_IP_SCTP=m
CONFIG_NET_SCTPPROBE=m
# CONFIG_SCTP_DBG_OBJCNT is not set
CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_SHA1 is not set
# CONFIG_SCTP_DEFAULT_COOKIE_HMAC_NONE is not set
CONFIG_SCTP_COOKIE_HMAC_MD5=y
# CONFIG_SCTP_COOKIE_HMAC_SHA1 is not set
CONFIG_RDS=m
CONFIG_RDS_RDMA=m
CONFIG_RDS_TCP=m
CONFIG_RDS_DEBUG=y
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
CONFIG_L2TP=m
CONFIG_L2TP_DEBUGFS=m
CONFIG_L2TP_V3=y
CONFIG_L2TP_IP=m
CONFIG_L2TP_ETH=m
CONFIG_STP=m
CONFIG_GARP=m
CONFIG_BRIDGE=m
CONFIG_BRIDGE_IGMP_SNOOPING=y
# CONFIG_BRIDGE_VLAN_FILTERING is not set
CONFIG_VLAN_8021Q=m
CONFIG_VLAN_8021Q_GVRP=y
# CONFIG_VLAN_8021Q_MVRP is not set
# CONFIG_DECNET is not set
CONFIG_LLC=m
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_6LOWPAN is not set
# CONFIG_IEEE802154 is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_MULTIQ=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFB=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_DRR=m
CONFIG_NET_SCH_MQPRIO=m
CONFIG_NET_SCH_CHOKE=m
CONFIG_NET_SCH_QFQ=m
CONFIG_NET_SCH_CODEL=m
CONFIG_NET_SCH_FQ_CODEL=m
# CONFIG_NET_SCH_FQ is not set
# CONFIG_NET_SCH_HHF is not set
# CONFIG_NET_SCH_PIE is not set
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_SCH_PLUG=m

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_FLOW=m
CONFIG_NET_CLS_CGROUP=y
CONFIG_NET_CLS_BPF=m
# CONFIG_NET_CLS_FLOWER is not set
# CONFIG_NET_EMATCH is not set
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
CONFIG_NET_ACT_GACT=m
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=m
CONFIG_NET_ACT_NAT=m
CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SIMP=m
CONFIG_NET_ACT_SKBEDIT=m
CONFIG_NET_ACT_CSUM=m
# CONFIG_NET_ACT_VLAN is not set
# CONFIG_NET_ACT_BPF is not set
# CONFIG_NET_CLS_IND is not set
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_MMAP is not set
# CONFIG_NETLINK_DIAG is not set
# CONFIG_MPLS is not set
# CONFIG_HSR is not set
# CONFIG_NET_SWITCHDEV is not set
# CONFIG_NET_L3_MASTER_DEV is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
CONFIG_SOCK_CGROUP_DATA=y
# CONFIG_CGROUP_NET_PRIO is not set
CONFIG_CGROUP_NET_CLASSID=y
CONFIG_NET_RX_BUSY_POLL=y
CONFIG_BQL=y
CONFIG_BPF_JIT=y
CONFIG_NET_FLOW_LIMIT=y

#
# Network testing
#
CONFIG_NET_PKTGEN=m
CONFIG_NET_TCPPROBE=m
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_CAN is not set
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
# CONFIG_LWTUNNEL is not set
CONFIG_HAVE_BPF_JIT=y
# CONFIG_PCMCIA is not set
CONFIG_CCW=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER=y
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
# CONFIG_DEVTMPFS_MOUNT is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
CONFIG_ALLOW_DEV_COREDUMP=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
CONFIG_SYS_HYPERVISOR=y
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_GENERIC_CPU_AUTOPROBE=y
# CONFIG_DMA_SHARED_BUFFER is not set

#
# Bus devices
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
# CONFIG_OF is not set
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_NULL_BLK is not set
# CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SKD is not set
CONFIG_BLK_DEV_OSD=m
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=32768
# CONFIG_CDROM_PKTCDVD is not set
CONFIG_ATA_OVER_ETH=m

#
# S/390 block device drivers
#
CONFIG_BLK_DEV_XPRAM=m
CONFIG_DCSSBLK=m
CONFIG_DASD=y
CONFIG_DASD_PROFILE=y
CONFIG_DASD_ECKD=y
CONFIG_DASD_FBA=y
CONFIG_DASD_DIAG=y
CONFIG_DASD_EER=y
CONFIG_SCM_BLOCK=m
CONFIG_SCM_BLOCK_CLUSTER_WRITE=y
CONFIG_VIRTIO_BLK=y
# CONFIG_BLK_DEV_RBD is not set
# CONFIG_BLK_DEV_RSXX is not set
# CONFIG_BLK_DEV_NVME is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_SRAM is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_CB710_CORE is not set

#
# Texas Instruments shared transport line discipline
#

#
# Altera FPGA firmware download module
#

#
# Intel MIC Bus Driver
#

#
# SCIF Bus Driver
#

#
# Intel MIC Host Driver
#

#
# Intel MIC Card Driver
#

#
# SCIF Driver
#

#
# Intel MIC Coprocessor State Management (COSM) Drivers
#
CONFIG_GENWQE=m
CONFIG_GENWQE_PLATFORM_ERROR_RECOVERY=0
# CONFIG_ECHO is not set
# CONFIG_CXL_BASE is not set
# CONFIG_CXL_KERNEL_API is not set
# CONFIG_CXL_EEH is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_MQ_DEFAULT=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=y
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_HOST_SMP=y
CONFIG_SCSI_SRP_ATTRS=m
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=m
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_SCSI_CXGB3_ISCSI is not set
# CONFIG_SCSI_CXGB4_ISCSI is not set
# CONFIG_SCSI_BNX2_ISCSI is not set
# CONFIG_SCSI_BNX2X_FCOE is not set
# CONFIG_BE2ISCSI is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_HPSA is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_3W_SAS is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_MVSAS is not set
# CONFIG_SCSI_MVUMI is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_SCSI_ESAS2R is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_MPT3SAS is not set
# CONFIG_SCSI_MPT2SAS is not set
# CONFIG_SCSI_UFSHCD is not set
# CONFIG_SCSI_HPTIOP is not set
CONFIG_LIBFC=m
CONFIG_LIBFCOE=m
# CONFIG_FCOE is not set
# CONFIG_SCSI_SNIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_WD719X is not set
CONFIG_SCSI_DEBUG=m
CONFIG_ZFCP=y
# CONFIG_SCSI_PMCRAID is not set
# CONFIG_SCSI_PM8001 is not set
# CONFIG_SCSI_BFA_FC is not set
CONFIG_SCSI_VIRTIO=m
# CONFIG_SCSI_CHELSIO_FCOE is not set
# CONFIG_SCSI_DH is not set
CONFIG_SCSI_OSD_INITIATOR=m
CONFIG_SCSI_OSD_ULD=m
CONFIG_SCSI_OSD_DPRINT_SENSE=1
# CONFIG_SCSI_OSD_DEBUG is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BCACHE is not set
CONFIG_BLK_DEV_DM_BUILTIN=y
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_MQ_DEFAULT is not set
# CONFIG_DM_DEBUG is not set
# CONFIG_DM_CRYPT is not set
# CONFIG_DM_SNAPSHOT is not set
# CONFIG_DM_THIN_PROVISIONING is not set
# CONFIG_DM_CACHE is not set
# CONFIG_DM_ERA is not set
CONFIG_DM_MIRROR=m
# CONFIG_DM_LOG_USERSPACE is not set
# CONFIG_DM_RAID is not set
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
# CONFIG_DM_UEVENT is not set
# CONFIG_DM_FLAKEY is not set
# CONFIG_DM_VERITY is not set
# CONFIG_DM_SWITCH is not set
# CONFIG_DM_LOG_WRITES is not set
# CONFIG_TARGET_CORE is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_FIREWIRE_NOSY is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
CONFIG_BONDING=m
CONFIG_DUMMY=m
CONFIG_EQUALIZER=m
# CONFIG_NET_FC is not set
CONFIG_IFB=m
# CONFIG_NET_TEAM is not set
CONFIG_MACVLAN=m
CONFIG_MACVTAP=m
# CONFIG_IPVLAN is not set
CONFIG_VXLAN=m
# CONFIG_GENEVE is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
CONFIG_TUN=m
# CONFIG_TUN_VNET_CROSS_LE is not set
CONFIG_VETH=m
CONFIG_VIRTIO_NET=m
CONFIG_NLMON=m
# CONFIG_ARCNET is not set

#
# CAIF transport drivers
#
CONFIG_VHOST_NET=m
CONFIG_VHOST_RING=m
CONFIG_VHOST=m
# CONFIG_VHOST_CROSS_ENDIAN_LEGACY is not set
CONFIG_ETHERNET=y
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_VENDOR_ADAPTEC is not set
# CONFIG_NET_VENDOR_AGERE is not set
# CONFIG_NET_VENDOR_ALTEON is not set
# CONFIG_ALTERA_TSE is not set
# CONFIG_NET_VENDOR_AMD is not set
# CONFIG_NET_VENDOR_ARC is not set
# CONFIG_NET_VENDOR_ATHEROS is not set
# CONFIG_NET_VENDOR_AURORA is not set
# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
# CONFIG_NET_VENDOR_BROCADE is not set
# CONFIG_NET_VENDOR_CAVIUM is not set
# CONFIG_NET_VENDOR_CHELSIO is not set
# CONFIG_NET_VENDOR_CISCO is not set
# CONFIG_DNET is not set
# CONFIG_NET_VENDOR_DEC is not set
# CONFIG_NET_VENDOR_DLINK is not set
CONFIG_NET_VENDOR_EMULEX=y
# CONFIG_BE2NET is not set
# CONFIG_NET_VENDOR_EZCHIP is not set
# CONFIG_NET_VENDOR_EXAR is not set
# CONFIG_NET_VENDOR_HP is not set
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_JME is not set
# CONFIG_NET_VENDOR_MARVELL is not set
CONFIG_NET_VENDOR_MELLANOX=y
CONFIG_MLX4_EN=m
CONFIG_MLX4_EN_VXLAN=y
CONFIG_MLX4_CORE=m
CONFIG_MLX4_DEBUG=y
CONFIG_MLX5_CORE=m
CONFIG_MLX5_CORE_EN=y
CONFIG_MLXSW_CORE=m
CONFIG_MLXSW_PCI=m
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MYRI is not set
# CONFIG_FEALNX is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
CONFIG_NET_VENDOR_NETRONOME=y
# CONFIG_NFP_NETVF is not set
# CONFIG_NET_VENDOR_NVIDIA is not set
# CONFIG_NET_VENDOR_OKI is not set
# CONFIG_ETHOC is not set
# CONFIG_NET_PACKET_ENGINE is not set
# CONFIG_NET_VENDOR_QLOGIC is not set
# CONFIG_NET_VENDOR_QUALCOMM is not set
# CONFIG_NET_VENDOR_REALTEK is not set
# CONFIG_NET_VENDOR_RENESAS is not set
# CONFIG_NET_VENDOR_RDC is not set
# CONFIG_NET_VENDOR_ROCKER is not set
# CONFIG_NET_VENDOR_SAMSUNG is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SILAN is not set
# CONFIG_NET_VENDOR_SIS is not set
# CONFIG_SFC is not set
# CONFIG_NET_VENDOR_SMSC is not set
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_SUN is not set
# CONFIG_NET_VENDOR_SYNOPSYS is not set
# CONFIG_NET_VENDOR_TEHUTI is not set
# CONFIG_NET_VENDOR_TI is not set
# CONFIG_NET_VENDOR_VIA is not set
# CONFIG_NET_VENDOR_WIZNET is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PHYLIB is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# S/390 network device drivers
#
CONFIG_LCS=m
CONFIG_CTCM=m
CONFIG_NETIUCV=m
CONFIG_SMSGIUCV=m
CONFIG_SMSGIUCV_EVENT=m
CONFIG_QETH=y
CONFIG_QETH_L2=y
CONFIG_QETH_L3=y
CONFIG_QETH_IPV6=y
CONFIG_CCWGROUP=y

#
# Host-side USB support is needed for USB Network Adapter support
#

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_VMXNET3 is not set
# CONFIG_NVM is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=0
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVMEM=y
CONFIG_DEVKMEM=y

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_UARTLITE is not set
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_RP2 is not set
# CONFIG_SERIAL_FSL_LPUART is not set
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IUCV=y
CONFIG_VIRTIO_CONSOLE=y
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=m
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_HW_RANDOM_TPM=m
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
CONFIG_RAW_DRIVER=m
CONFIG_MAX_RAW_DEVS=256
CONFIG_HANGCHECK_TIMER=m
CONFIG_TCG_TPM=y
CONFIG_DEVPORT=y

#
# S/390 character device drivers
#
CONFIG_TN3270=y
CONFIG_TN3270_TTY=y
CONFIG_TN3270_FS=y
CONFIG_TN3270_CONSOLE=y
CONFIG_TN3215=y
CONFIG_TN3215_CONSOLE=y
CONFIG_CCW_CONSOLE=y
CONFIG_SCLP_TTY=y
CONFIG_SCLP_CONSOLE=y
CONFIG_SCLP_VT220_TTY=y
CONFIG_SCLP_VT220_CONSOLE=y
CONFIG_SCLP_ASYNC=m
CONFIG_SCLP_ASYNC_ID="000000000"
CONFIG_HMC_DRV=m
# CONFIG_SCLP_OFB is not set
CONFIG_S390_TAPE=m

#
# S/390 tape hardware support
#
CONFIG_S390_TAPE_34XX=m
CONFIG_S390_TAPE_3590=m
CONFIG_VMLOGRDR=m
CONFIG_VMCP=y
CONFIG_MONREADER=m
CONFIG_MONWRITER=m
CONFIG_S390_VMUR=m
# CONFIG_XILLYBUS is not set

#
# I2C support
#
# CONFIG_I2C is not set
# CONFIG_SPI is not set
# CONFIG_SPMI is not set
# CONFIG_HSI is not set

#
# PPS support
#
CONFIG_PPS=m
# CONFIG_PPS_DEBUG is not set

#
# PPS clients support
#
# CONFIG_PPS_CLIENT_KTIMER is not set
# CONFIG_PPS_CLIENT_LDISC is not set
# CONFIG_PPS_CLIENT_GPIO is not set

#
# PPS generators support
#

#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=m

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_POWER_RESET is not set
# CONFIG_POWER_AVS is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
CONFIG_WATCHDOG_NOWAYOUT=y
# CONFIG_WATCHDOG_SYSFS is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_XILINX_WATCHDOG is not set
# CONFIG_CADENCE_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
# CONFIG_MAX63XX_WATCHDOG is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_I6300ESB_WDT is not set
# CONFIG_BCM7038_WDT is not set
CONFIG_DIAG288_WATCHDOG=m

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_LPC_ICH is not set
# CONFIG_LPC_SCH is not set
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_KEMPLD is not set
# CONFIG_MFD_MT6397 is not set
# CONFIG_MFD_RDC321X is not set
# CONFIG_MFD_RTSX_PCI is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_VX855 is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
# CONFIG_DRM is not set

#
# Frame buffer Devices
#
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
# CONFIG_VGASTATE is not set
# CONFIG_SOUND is not set

#
# HID support
#
# CONFIG_HID is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_SUPPORT is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
CONFIG_INFINIBAND=m
# CONFIG_INFINIBAND_USER_MAD is not set
CONFIG_INFINIBAND_USER_ACCESS=m
CONFIG_INFINIBAND_USER_MEM=y
CONFIG_INFINIBAND_ON_DEMAND_PAGING=y
CONFIG_INFINIBAND_ADDR_TRANS=y
CONFIG_INFINIBAND_ADDR_TRANS_CONFIGFS=y
# CONFIG_INFINIBAND_MTHCA is not set
# CONFIG_INFINIBAND_QIB is not set
CONFIG_MLX4_INFINIBAND=m
# CONFIG_MLX5_INFINIBAND is not set
# CONFIG_INFINIBAND_NES is not set
# CONFIG_INFINIBAND_OCRDMA is not set
# CONFIG_INFINIBAND_IPOIB is not set
# CONFIG_INFINIBAND_SRP is not set
# CONFIG_INFINIBAND_ISER is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
CONFIG_VFIO_IOMMU_TYPE1=m
CONFIG_VFIO_VIRQFD=m
CONFIG_VFIO=m
# CONFIG_VFIO_NOIOMMU is not set
CONFIG_VFIO_PCI=m
CONFIG_IRQ_BYPASS_MANAGER=m
# CONFIG_VIRT_DRIVERS is not set
CONFIG_VIRTIO=y

#
# Virtio drivers
#
CONFIG_VIRTIO_PCI=m
CONFIG_VIRTIO_PCI_LEGACY=y
CONFIG_VIRTIO_BALLOON=m
# CONFIG_VIRTIO_INPUT is not set
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set

#
# Hardware Spinlock drivers
#

#
# Clock Source drivers
#
# CONFIG_ATMEL_PIT is not set
# CONFIG_SH_TIMER_CMT is not set
# CONFIG_SH_TIMER_MTU2 is not set
# CONFIG_SH_TIMER_TMU is not set
# CONFIG_EM_TIMER_STI is not set
# CONFIG_MAILBOX is not set
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y

#
# Generic IOMMU Pagetable Support
#
CONFIG_S390_IOMMU=y

#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers
#

#
# SOC (System On Chip) specific Drivers
#
# CONFIG_SUNXI_SRAM is not set
# CONFIG_SOC_TI is not set
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_NTB is not set
# CONFIG_VME_BUS is not set
# CONFIG_PWM is not set
CONFIG_ARM_GIC_MAX_NR=1
# CONFIG_TS4800_IRQ is not set
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
# CONFIG_FMC is not set

#
# PHY Subsystem
#
# CONFIG_GENERIC_PHY is not set
# CONFIG_PHY_PXA_28NM_HSIC is not set
# CONFIG_PHY_PXA_28NM_USB2 is not set
# CONFIG_BCM_KONA_USB2_PHY is not set
# CONFIG_PHY_HI6220_USB is not set
# CONFIG_POWERCAP is not set
# CONFIG_MCB is not set

#
# Performance monitor support
#
# CONFIG_RAS is not set
# CONFIG_THUNDERBOLT is not set

#
# Android
#
# CONFIG_ANDROID is not set
# CONFIG_LIBNVDIMM is not set
# CONFIG_NVMEM is not set
# CONFIG_STM is not set
# CONFIG_STM_DUMMY is not set
# CONFIG_STM_SOURCE_CONSOLE is not set
# CONFIG_INTEL_TH is not set

#
# FPGA Configuration Support
#
# CONFIG_FPGA is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_ENCRYPTION is not set
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD2=y
CONFIG_JBD2_DEBUG=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
# CONFIG_BTRFS_FS_CHECK_INTEGRITY is not set
# CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
# CONFIG_BTRFS_DEBUG is not set
# CONFIG_BTRFS_ASSERT is not set
# CONFIG_NILFS2_FS is not set
# CONFIG_F2FS_FS is not set
# CONFIG_FS_DAX is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
# CONFIG_MANDATORY_FILE_LOCKING is not set
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_FANOTIFY=y
# CONFIG_FANOTIFY_ACCESS_PERMISSIONS is not set
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
CONFIG_PRINT_QUOTA_WARNING=y
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QUOTA_TREE=m
CONFIG_QFMT_V1=m
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set
# CONFIG_OVERLAY_FS is not set

#
# Caches
#
CONFIG_FSCACHE=m
# CONFIG_FSCACHE_STATS is not set
# CONFIG_FSCACHE_HISTOGRAM is not set
# CONFIG_FSCACHE_DEBUG is not set
# CONFIG_FSCACHE_OBJECT_LIST is not set
CONFIG_CACHEFILES=m
# CONFIG_CACHEFILES_DEBUG is not set
# CONFIG_CACHEFILES_HISTOGRAM is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
# CONFIG_PROC_CHILDREN is not set
CONFIG_KERNFS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=m
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_MINIX_FS_NATIVE_ENDIAN is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_EXOFS_FS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set
# CONFIG_NLS is not set
CONFIG_DLM=m
# CONFIG_DLM_DEBUG is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y

#
# printk and dmesg options
#
CONFIG_PRINTK_TIME=y
CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
CONFIG_DYNAMIC_DEBUG=y

#
# Compile-time checks and compiler options
#
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_INFO_SPLIT is not set
# CONFIG_DEBUG_INFO_DWARF4 is not set
# CONFIG_GDB_SCRIPTS is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_READABLE_ASM=y
CONFIG_UNUSED_SYMBOLS=y
# CONFIG_PAGE_OWNER is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
# CONFIG_SECTION_MISMATCH_WARN_ONLY is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
CONFIG_DEBUG_KERNEL=y

#
# Memory Debugging
#
CONFIG_PAGE_EXTENSION=y
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_DEBUG_OBJECTS=y
CONFIG_DEBUG_OBJECTS_SELFTEST=y
CONFIG_DEBUG_OBJECTS_FREE=y
CONFIG_DEBUG_OBJECTS_TIMERS=y
CONFIG_DEBUG_OBJECTS_WORK=y
CONFIG_DEBUG_OBJECTS_RCU_HEAD=y
CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER=y
CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1
CONFIG_SLUB_DEBUG_ON=y
CONFIG_SLUB_STATS=y
CONFIG_HAVE_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400
# CONFIG_DEBUG_KMEMLEAK_TEST is not set
# CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set
CONFIG_DEBUG_STACK_USAGE=y
CONFIG_DEBUG_VM=y
# CONFIG_DEBUG_VM_VMACACHE is not set
CONFIG_DEBUG_VM_RB=y
# CONFIG_DEBUG_VM_PGFLAGS is not set
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_MEMORY_NOTIFIER_ERROR_INJECT=m
CONFIG_DEBUG_PER_CPU_MAPS=y
CONFIG_DEBUG_SHIRQ=y

#
# Debug Lockups and Hangs
#
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
# CONFIG_WQ_WATCHDOG is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_PANIC_TIMEOUT=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHED_INFO=y
CONFIG_SCHEDSTATS=y
# CONFIG_SCHED_STACK_END_CHECK is not set
# CONFIG_DEBUG_TIMEKEEPING is not set
CONFIG_TIMER_STATS=y
CONFIG_DEBUG_PREEMPT=y

#
# Lock Debugging (spinlocks, mutexes, etc...)
#
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
CONFIG_LOCK_STAT=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
# CONFIG_LOCK_TORTURE_TEST is not set
CONFIG_TRACE_IRQFLAGS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_KOBJECT_RELEASE is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_LIST=y
# CONFIG_DEBUG_PI_LIST is not set
CONFIG_DEBUG_SG=y
CONFIG_DEBUG_NOTIFIERS=y
CONFIG_DEBUG_CREDENTIALS=y

#
# RCU Debugging
#
CONFIG_PROVE_RCU=y
# CONFIG_PROVE_RCU_REPEATEDLY is not set
# CONFIG_SPARSE_RCU_POINTER is not set
CONFIG_TORTURE_TEST=m
CONFIG_RCU_TORTURE_TEST=m
# CONFIG_RCU_TORTURE_TEST_SLOW_PREINIT is not set
# CONFIG_RCU_TORTURE_TEST_SLOW_INIT is not set
# CONFIG_RCU_TORTURE_TEST_SLOW_CLEANUP is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=300
# CONFIG_RCU_TRACE is not set
# CONFIG_RCU_EQS_DEBUG is not set
# CONFIG_DEBUG_WQ_FORCE_RR_CPU is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
CONFIG_NOTIFIER_ERROR_INJECTION=m
CONFIG_CPU_NOTIFIER_ERROR_INJECT=m
CONFIG_PM_NOTIFIER_ERROR_INJECT=m
# CONFIG_NETDEV_NOTIFIER_ERROR_INJECT is not set
CONFIG_FAULT_INJECTION=y
CONFIG_FAILSLAB=y
CONFIG_FAIL_PAGE_ALLOC=y
CONFIG_FAIL_MAKE_REQUEST=y
CONFIG_FAIL_IO_TIMEOUT=y
# CONFIG_FAIL_FUTEX is not set
CONFIG_FAULT_INJECTION_DEBUG_FS=y
CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y
CONFIG_LATENCYTOP=y
CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS=y
CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_RING_BUFFER_ALLOW_SWAP=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_TRACER_SNAPSHOT is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
CONFIG_BLK_DEV_IO_TRACE=y
# CONFIG_KPROBE_EVENT is not set
# CONFIG_UPROBE_EVENT is not set
# CONFIG_PROBE_EVENTS is not set
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_TRACEPOINT_BENCHMARK is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_RING_BUFFER_STARTUP_TEST is not set
# CONFIG_TRACE_ENUM_MAP_FILE is not set

#
# Runtime Testing
#
CONFIG_LKDTM=m
CONFIG_TEST_LIST_SORT=y
CONFIG_KPROBES_SANITY_TEST=y
# CONFIG_BACKTRACE_SELF_TEST is not set
CONFIG_RBTREE_TEST=y
CONFIG_INTERVAL_TREE_TEST=m
CONFIG_PERCPU_TEST=m
CONFIG_ATOMIC64_SELFTEST=y
# CONFIG_TEST_HEXDUMP is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_TEST_PRINTF is not set
# CONFIG_TEST_RHASHTABLE is not set
CONFIG_DMA_API_DEBUG=y
# CONFIG_TEST_LKM is not set
# CONFIG_TEST_USER_COPY is not set
# CONFIG_TEST_BPF is not set
# CONFIG_TEST_FIRMWARE is not set
# CONFIG_TEST_UDELAY is not set
# CONFIG_MEMTEST is not set
# CONFIG_TEST_STATIC_KEYS is not set
# CONFIG_SAMPLES is not set
# CONFIG_UBSAN is not set
CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y
# CONFIG_STRICT_DEVMEM is not set
CONFIG_S390_PTDUMP=y
CONFIG_DEBUG_SET_MODULE_RONX=y

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_PERSISTENT_KEYRINGS is not set
# CONFIG_BIG_KEYS is not set
# CONFIG_TRUSTED_KEYS is not set
CONFIG_ENCRYPTED_KEYS=m
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
# CONFIG_SECURITY_PATH is not set
# CONFIG_SECURITY_SELINUX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set
CONFIG_INTEGRITY=y
# CONFIG_INTEGRITY_SIGNATURE is not set
CONFIG_INTEGRITY_AUDIT=y
CONFIG_IMA=y
CONFIG_IMA_MEASURE_PCR_IDX=10
# CONFIG_IMA_TEMPLATE is not set
CONFIG_IMA_NG_TEMPLATE=y
# CONFIG_IMA_SIG_TEMPLATE is not set
CONFIG_IMA_DEFAULT_TEMPLATE="ima-ng"
CONFIG_IMA_DEFAULT_HASH_SHA1=y
# CONFIG_IMA_DEFAULT_HASH_SHA256 is not set
# CONFIG_IMA_DEFAULT_HASH_SHA512 is not set
# CONFIG_IMA_DEFAULT_HASH_WP512 is not set
CONFIG_IMA_DEFAULT_HASH="sha1"
# CONFIG_IMA_WRITE_POLICY is not set
# CONFIG_IMA_READ_POLICY is not set
CONFIG_IMA_APPRAISE=y
# CONFIG_EVM is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_XOR_BLOCKS=m
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_RNG_DEFAULT=m
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_AKCIPHER2=y
# CONFIG_CRYPTO_RSA is not set
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_USER=m
# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_NULL2=y
# CONFIG_CRYPTO_PCRYPT is not set
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=m
# CONFIG_CRYPTO_MCRYPTD is not set
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m

#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
# CONFIG_CRYPTO_CHACHA20POLY1305 is not set
CONFIG_CRYPTO_SEQIV=m
CONFIG_CRYPTO_ECHAINIV=m

#
# Block modes
#
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_CTR=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
# CONFIG_CRYPTO_KEYWRAP is not set

#
# Hash modes
#
CONFIG_CRYPTO_CMAC=m
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_VMAC=m

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32=m
CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_GHASH=m
# CONFIG_CRYPTO_POLY1305 is not set
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_RMD128=m
CONFIG_CRYPTO_RMD160=m
CONFIG_CRYPTO_RMD256=m
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_BLOWFISH_COMMON=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST_COMMON=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SALSA20=m
# CONFIG_CRYPTO_CHACHA20 is not set
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_ZLIB=y
CONFIG_CRYPTO_LZO=m
# CONFIG_CRYPTO_842 is not set
CONFIG_CRYPTO_LZ4=m
CONFIG_CRYPTO_LZ4HC=m

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_DRBG_MENU=m
CONFIG_CRYPTO_DRBG_HMAC=y
# CONFIG_CRYPTO_DRBG_HASH is not set
# CONFIG_CRYPTO_DRBG_CTR is not set
CONFIG_CRYPTO_DRBG=m
CONFIG_CRYPTO_JITTERENTROPY=m
CONFIG_CRYPTO_USER_API=m
CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_SKCIPHER=m
# CONFIG_CRYPTO_USER_API_RNG is not set
# CONFIG_CRYPTO_USER_API_AEAD is not set
CONFIG_CRYPTO_HASH_INFO=y
CONFIG_CRYPTO_HW=y
CONFIG_ZCRYPT=m
CONFIG_CRYPTO_SHA1_S390=m
CONFIG_CRYPTO_SHA256_S390=m
CONFIG_CRYPTO_SHA512_S390=m
CONFIG_CRYPTO_DES_S390=m
CONFIG_CRYPTO_AES_S390=m
CONFIG_S390_PRNG=m
CONFIG_CRYPTO_GHASH_S390=m
CONFIG_ASYMMETRIC_KEY_TYPE=m
CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=m
CONFIG_PUBLIC_KEY_ALGO_RSA=m
CONFIG_X509_CERTIFICATE_PARSER=m
# CONFIG_PKCS7_MESSAGE_PARSER is not set

#
# Certificates for signature checking
#
# CONFIG_SYSTEM_TRUSTED_KEYRING is not set
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_RAID6_PQ=m
CONFIG_BITREVERSE=y
# CONFIG_HAVE_ARCH_BITREVERSE is not set
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_IO=y
CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
CONFIG_CRC7=m
CONFIG_LIBCRC32C=m
CONFIG_CRC8=m
# CONFIG_AUDIT_ARCH_COMPAT_GENERIC is not set
# CONFIG_RANDOM32_SELFTEST is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_LZ4_COMPRESS=m
CONFIG_LZ4HC_COMPRESS=m
CONFIG_LZ4_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_DECOMPRESS_LZ4=y
CONFIG_INTERVAL_TREE=y
CONFIG_ASSOCIATIVE_ARRAY=y
# CONFIG_CPUMASK_OFFSTACK is not set
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_CLZ_TAB=y
CONFIG_CORDIC=m
# CONFIG_DDR is not set
CONFIG_IRQ_POLL=y
CONFIG_MPILIB=m
CONFIG_OID_REGISTRY=m
# CONFIG_SG_SPLIT is not set
CONFIG_ARCH_HAS_SG_CHAIN=y

#
# Virtualization
#
CONFIG_PFAULT=y
CONFIG_CMM=m
CONFIG_CMM_IUCV=y
CONFIG_APPLDATA_BASE=y
CONFIG_APPLDATA_MEM=m
CONFIG_APPLDATA_OS=m
CONFIG_APPLDATA_NET_SUM=m
CONFIG_S390_HYPFS_FS=y
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_IRQFD=y
CONFIG_HAVE_KVM_IRQ_ROUTING=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_KVM_ASYNC_PF_SYNC=y
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y
CONFIG_KVM_VFIO=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_S390_UCONTROL=y
CONFIG_S390_GUEST=y

From sergei.shtylyov at cogentembedded.com  Wed Feb 17 11:07:50 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 17 Feb 2016 22:07:50 +0300
Subject: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
In-Reply-To: <20160217053848.GC11534@verge.net.au>
References: <12033353.rt0nolnBmD@wasted.cogentembedded.com>
 <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
 <874mdhtn7d.wl%kuninori.morimoto.gx@renesas.com>
 <20160210171455.GB17671@verge.net.au> <56BE0CB1.4070408@cogentembedded.com>
 <20160212184343.GA31655@verge.net.au> <56BE2DC6.4080802@cogentembedded.com>
 <20160212193347.GB23472@verge.net.au> <56BE3912.9000601@cogentembedded.com>
 <20160217053848.GC11534@verge.net.au>
Message-ID: <56C4C506.8040803@cogentembedded.com>

On 02/17/2016 08:38 AM, Simon Horman wrote:

>>>>>>>>> Define the generic R8A7794 part of  the sound device node.
>>>>>>>>> This sound device  is a complex one and comprises the Audio Clock Generator
>>>>>>>>> (ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
>>>>>>>>> (SSI[U]), and Audio DMAC-Peripheral-Peripheral.
>>>>>>>>> It is up  to the board file to enable the device.
>>>>>>>>>
>>>>>>>>> This patch is based on the R8A7791 sound work by Kuninori Morimoto.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>>>>>>>> (snip)
>>>>>>>>> +		rcar_sound,src {
>>>>>>>>> +			src1: src at 1 {
>>>>>>>>> +				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>>>> +				dmas = <&audma0 0x87>, <&audma0 0x9c>;
>>>>>>>>> +				dma-names = "rx", "tx";
>>>>>>>>> +			};
>>>>>>>>> +			src2: src at 2 {
>>>>>>>>> +				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>>>> +				dmas = <&audma0 0x89>, <&audma0 0x9e>;
>>>>>>>>> +				dma-names = "rx", "tx";
>>>>>>>>> +			};
>>>>>>>>> +			src3: src at 3 {
>>>>>>>>> +				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>>>> +				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
>>>>>>>>> +				dma-names = "rx", "tx";
>>>>>>>>> +			};
>>>>>>>>> +			src4: src at 4 {
>>>>>>>>> +				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>>>> +				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
>>>>>>>>> +				dma-names = "rx", "tx";
>>>>>>>>> +			};
>>>>>>>>> +			src5: src at 5 {
>>>>>>>>> +				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>>>> +				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
>>>>>>>>> +				dma-names = "rx", "tx";
>>>>>>>>> +			};
>>>>>>>>> +			src6: src at 6 {
>>>>>>>>> +				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>>>> +				dmas = <&audma0 0x91>, <&audma0 0xb4>;
>>>>>>>>> +				dma-names = "rx", "tx";
>>>>>>>>> +			};
>>>>>>>>> +		};
>>>>>>>>
>>>>>>>> I think this can't work correctly, because driver is assuming
>>>>>>>> DT has all channles (from 0). (see linux/sound/soc/sh/rcar/src.c :: rsnd_src_probe)
>>>>>>>> Can you adds dummy src0 with some comments ? or fix src.c driver ?
>>>>>>>
>>>>>>> I would prefer the driver to be fixed (I had a similar patchset locally
>>>>>>> and I found it doesn't work).
>>>>>>
>>>>>>     You mean you had R8A7794 sound patch set too?
>>>>>
>>>>> Yes, I was working on it recently.
>>>>> I suppose we should coordinate these things in future to avoid
>>>>> duplicated effort.
>>>>
>>>>     Yes, seems a good idea now. :-)
>>>>
>>>>>>> The reason is that DT should describe
>>>>>>> the hardware rather than the current state of the software.
>>>>>>
>>>>>>     Yes, of course. Just tell me do I have to fix the driver *before* this
>>>>>> patch set is accepted?
>>>>
>>>>> I did not entirely get to the bottom of the problem, but I think that at
>>>>> the very least something needs to be done about the for_each_rsnd_src()
>>>>> loop in rsnd_src_probe.
>>>>
>>>>     It's not that it replies to my question. :-)
>>>>     So you're looking at this issue yourself?
>>>
>>> I have not got very far, as you can see, but I was planning to look into it.
>>> I don't mind if you want to do so.
>>
>>     After consultation with the management, I'm going to look into this issue
>> myself. :-)
>
> Excellent.

    But not immediately. I have some other things to look at before that (DU 
and AVB), they'll going to take some (significant) time... :-(

> FWIW, I can test anything you come up with for the r8a7794 an alt board

    I have remote access to Alt now, in fact using it currently for the AVB work.

> or post patches for it once you have r8a7794/silk sorted out.

    I already have audio on these working. Or you're going to wait until I fix 
the SRC issue?

[...]

MBR, Sergei



From gerald.schaefer at de.ibm.com  Wed Feb 17 11:13:40 2016
From: gerald.schaefer at de.ibm.com (Gerald Schaefer)
Date: Wed, 17 Feb 2016 20:13:40 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe
 also on PowerPC and ARM)
In-Reply-To: <alpine.LFD.2.20.1602131238260.1910@schleppi>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
 <alpine.LFD.2.20.1602131238260.1910@schleppi>
Message-ID: <20160217201340.2dafad8d@thinkpad>

On Sat, 13 Feb 2016 12:58:31 +0100 (CET)
Sebastian Ott <sebott at linux.vnet.ibm.com> wrote:

> [   59.875935] ------------[ cut here ]------------
> [   59.875937] kernel BUG at mm/huge_memory.c:2884!
> [   59.875979] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [   59.875986] Modules linked in: bridge stp llc btrfs xor mlx4_en vxlan ip6_udp_tunnel udp_tunnel mlx4_ib ptp pps_core ib_sa ib_mad ib_core ib_addr ghash_s390 prng raid6_pq ecb aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 mlx4_core sha_common genwqe_card scm_block crc_itu_t vhost_net tun vhost dm_mod macvtap eadm_sch macvlan kvm autofs4
> [   59.876033] CPU: 2 PID: 5402 Comm: git Tainted: G        W       4.4.0-07794-ga4eff16-dirty #77
> [   59.876036] task: 00000000d2312948 ti: 00000000cfecc000 task.ti: 00000000cfecc000
> [   59.876039] Krnl PSW : 0704d00180000000 00000000002bf3aa (__split_huge_pmd_locked+0x562/0xa10)
> [   59.876045]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
>                Krnl GPRS: 0000000001a7a1cf 000003d10177c000 0000000000044068 000000005df00215
> [   59.876051]            0000000000000001 0000000000000001 0000000000000000 00000000774e6900
> [   59.876054]            000003ff52000000 000000006d403b10 000000006e1eb800 000003ff51f00000
> [   59.876058]            000003d10177c000 0000000000715190 00000000002bf234 00000000cfecfb58
> [   59.876068] Krnl Code: 00000000002bf39c: d507d010a000	clc	16(8,%%r13),0(%%r10)
>                           00000000002bf3a2: a7840004		brc	8,2bf3aa
>                          #00000000002bf3a6: a7f40001		brc	15,2bf3a8
>                          >00000000002bf3aa: 91407440		tm	1088(%%r7),64
>                           00000000002bf3ae: a7840208		brc	8,2bf7be
>                           00000000002bf3b2: a7f401e9		brc	15,2bf784
>                           00000000002bf3b6: 9104a006		tm	6(%%r10),4
>                           00000000002bf3ba: a7740004		brc	7,2bf3c2
> [   59.876089] Call Trace:
> [   59.876092] ([<00000000002bf234>] __split_huge_pmd_locked+0x3ec/0xa10)
> [   59.876095]  [<00000000002c4310>] __split_huge_pmd+0x118/0x218
> [   59.876099]  [<00000000002810e8>] unmap_single_vma+0x2d8/0xb40
> [   59.876102]  [<0000000000282d66>] zap_page_range+0x116/0x318
> [   59.876105]  [<000000000029b834>] SyS_madvise+0x23c/0x5e8
> [   59.876108]  [<00000000006f9f56>] system_call+0xd6/0x258
> [   59.876111]  [<000003ff9bbfd282>] 0x3ff9bbfd282
> [   59.876113] INFO: lockdep is turned off.
> [   59.876115] Last Breaking-Event-Address:
> [   59.876118]  [<00000000002bf3a6>] __split_huge_pmd_locked+0x55e/0xa10

The BUG at mm/huge_memory.c:2884 is interesting, it's the BUG_ON(!pte_none(*pte))
check in __split_huge_pmd_locked(). Obviously we expect the pre-allocated
pagetables to be empty, but in collapse_huge_page() we deposit the original
pagetable instead of allocating a new (empty) one. This saves an allocation,
which is good, but doesn't that mean that if such a collapsed hugepage will
ever be split, we will always run into the BUG_ON(!pte_none(*pte)), or one
of the two other VM_BUG_ONs in mm/huge_memory.c that check the same?

This behavior is not new, it was the same before the THP rework, so I do not
assume that it is related to the current problems, maybe with the exception
of this specific crash. I never saw the BUG at mm/huge_memory.c:2884 myself,
and the other crashes probably cannot be explained with this. Maybe I am
also missing something, but I do not see how collapse_huge_page() and the
(non-empty) pgtable deposit there can work out with the BUG_ON(!pte_none(*pte))
checks. Any thoughts?



From mark.rutland at arm.com  Wed Feb 17 11:16:43 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 17 Feb 2016 19:16:43 +0000
Subject: KASAN issues with idle / hotplug area (was: Re: [PATCH v5sub1
 7/8] arm64: move kernel image to base of vmalloc area)
In-Reply-To: <20160217175656.GJ32647@leverpostej>
References: <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
 <20160217170110.GE32647@leverpostej>
 <20160217175656.GJ32647@leverpostej>
Message-ID: <20160217191643.GK32647@leverpostej>

On Wed, Feb 17, 2016 at 05:56:56PM +0000, Mark Rutland wrote:
> On Wed, Feb 17, 2016 at 05:01:11PM +0000, Mark Rutland wrote:
> > On Wed, Feb 17, 2016 at 02:39:51PM +0000, Mark Rutland wrote:
> > > Perhaps the simplest option is to not instrument invoke_psci_fn_* and
> > > psci_suspend_finisher. Do we have a per-function annotation to avoid
> > > KASAN instrumentation, like notrace? I need to investigate, but we may
> > > also need notrace for similar reasons.
> >
> > I came up with the patch below, per the reasoning above.
> > 
> > It _changes_ the KASAN splats (I see errors in tick_program_event rather
> > than find_busiest_group), but doesn't seem to get rid of them. I'm not
> > sure if I've missed something, or if we also have another latent issue.
> > 
> > Ideas?
> 
> I'd missed annotating __cpu_suspend_save. I've fixed that up locally
> (along with s/virt_to_phys/__virt_to_phys due to the inlining issue).

Thinking about it more, I shouldn't have to annotate __cpu_suspend_save,
as it returns (and hence should have cleaned up after itself).

Looking at the assembly, functions seem to get instrumented regardless
of the __no_sanitize_address annotation. The assembly of
__invoke_psci_fn_{smc,hvc} look identical, even if one has the
annotation and one does not.

In the case below, it looks like __invoke_psci_fn_hvc is storing to the
shadow area even though it's anotated with __no_sanitize_address.  Note
that the adrp symbol resolution is bogus; psci_to_linux_errno happens to
be at offset 0 in the as-yet unlinked psci.o object.

0000000000000420 <__invoke_psci_fn_hvc>:
 420:   d10283ff        sub     sp, sp, #0xa0
 424:   90000004        adrp    x4, 0 <psci_to_linux_errno>
 428:   91000084        add     x4, x4, #0x0
 42c:   90000005        adrp    x5, 0 <psci_to_linux_errno>
 430:   910000a5        add     x5, x5, #0x0
 434:   d2800007        mov     x7, #0x0                        // #0
 438:   a9017bfd        stp     x29, x30, [sp,#16]
 43c:   910043fd        add     x29, sp, #0x10
 440:   d2800006        mov     x6, #0x0                        // #0
 444:   a90253f3        stp     x19, x20, [sp,#32]
 448:   9100c3b3        add     x19, x29, #0x30
 44c:   d2dff214        mov     x20, #0xff9000000000            // #280993940373504
 450:   a90393a5        stp     x5, x4, [x29,#56]
 454:   f2fbfff4        movk    x20, #0xdfff, lsl #48
 458:   d343fe73        lsr     x19, x19, #3
 45c:   d2915664        mov     x4, #0x8ab3                     // #35507
 460:   f9001bf5        str     x21, [sp,#48]
 464:   f2a836a4        movk    x4, #0x41b5, lsl #16
 468:   8b140275        add     x21, x19, x20
 46c:   f9001ba4        str     x4, [x29,#48]
 470:   3204d3e4        mov     w4, #0xf1f1f1f1                 // #-235802127
 474:   b8346a64        str     w4, [x19,x20]
 478:   3204d7e4        mov     w4, #0xf3f3f3f3                 // #-202116109
 47c:   b9000aa4        str     w4, [x21,#8]
 480:   910143a4        add     x4, x29, #0x50
 484:   d2800005        mov     x5, #0x0                        // #0
 488:   f90003e4        str     x4, [sp]
 48c:   d2800004        mov     x4, #0x0                        // #0
 490:   94000000        bl      0 <arm_smccc_hvc>
 494:   f9402ba0        ldr     x0, [x29,#80]
 498:   910003bf        mov     sp, x29
 49c:   b8346a7f        str     wzr, [x19,x20]
 4a0:   b9000abf        str     wzr, [x21,#8]
 4a4:   a94153f3        ldp     x19, x20, [sp,#16]
 4a8:   f94013f5        ldr     x21, [sp,#32]
 4ac:   a8c97bfd        ldp     x29, x30, [sp],#144
 4b0:   d65f03c0        ret
 4b4:   d503201f        nop

For comparison, without KASAN __incoke_psci_fn_hvc looks like:

0000000000000280 <__invoke_psci_fn_hvc>:
 280:   d10103ff        sub     sp, sp, #0x40
 284:   d2800007        mov     x7, #0x0                        // #0
 288:   d2800006        mov     x6, #0x0                        // #0
 28c:   d2800005        mov     x5, #0x0                        // #0
 290:   a9017bfd        stp     x29, x30, [sp,#16]
 294:   910043fd        add     x29, sp, #0x10
 298:   910043a4        add     x4, x29, #0x10
 29c:   f90003e4        str     x4, [sp]
 2a0:   d2800004        mov     x4, #0x0                        // #0
 2a4:   94000000        bl      0 <arm_smccc_hvc>
 2a8:   910003bf        mov     sp, x29
 2ac:   f9400ba0        ldr     x0, [x29,#16]
 2b0:   a8c37bfd        ldp     x29, x30, [sp],#48
 2b4:   d65f03c0        ret

I also tried using __attribute__((no_sanitize_address)) directly, in
case there was some header issue, but that doesn't seem to be the case.

I'm using the Linaro 15.08 AArch64 GCC 5.1. Is anyone else able to
confirm whether they see the same? Does the same happen for x86?

Thanks,
Mark.


From tony at atomide.com  Wed Feb 17 11:27:55 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 17 Feb 2016 11:27:55 -0800
Subject: Bunch of machines are not booting in next again, GPIO regression?
Message-ID: <20160217192755.GC21202@atomide.com>

Hi Linus,

Looks like ff2b13592299 ("gpio: make the gpiochip a real device")
broke booting on all omaps, and probably other machines too according
to this:

https://kernelci.org/boot/all/job/next/kernel/next-20160217/

So far we've gone from 1 failed machine with next-20160216 to
18 failed machines with next-20160217.

The error I'm getting on omaps is below with debug_ll enable,
any ideas?

Regards,

Tony

8< -----------------------
Unable to handle kernel paging request at virtual address d1ba37bc
pgd = c0004000
[d1ba37bc] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc4-next-20160217 #1024
Hardware name: Nokia RX-51 board
task: ce0a8d40 ti: ce0aa000 task.ti: ce0aa000
PC is at kfree+0x50/0x144
LR is at kfree+0x34/0x144
pc : [<c026d690>]    lr : [<c026d674>]    psr: 20000093
sp : ce0abc88  ip : ce0abbf7  fp : 00000000
r10: c0837794  r9 : ce1c0c00  r8 : ce1b30a4
r7 : c0cbf824  r6 : a0000013  r5 : ab51ab30  r4 : ce1c0c10
r3 : d1ba37a8  r2 : cfa8c000  r1 : 00000000  r0 : ab51ab30
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 80004019  DAC: 00000051
Process swapper/0 (pid: 1, stack limit = 0xce0aa218)
Stack: (0xce0abc88 to 0xce0ac000)
bc80:                   ce1c0c10 ce1bfe00 ce1bfe00 ce1b30a4 ce1b30a4 ce1c0c00
bca0: c0837794 c04632e4 ce1b3010 00000000 ce1c0c08 c04f873c 00000000 ce0abcc8
bcc0: c0498560 c09c9f94 00000000 ce1c0c08 c0770730 ce0a8d40 00000001 60000013
bce0: ce1bd010 c018a838 ce1c0c08 ce1bd0a0 00000004 c0770730 00000000 ce1b3010
bd00: ce1916d0 00000000 ce1b30a4 ce1bd010 cfdb137c c0837794 00000000 c049db40
bd20: c149646c c14964b8 ce0a8d40 ce1bd010 ce1bd010 ce1bd010 c0c80c9c fffffdfb
bd40: 00000000 00000000 00000000 c04fe394 ce1bd010 c14964b0 c14964b8 c0c80c9c
bd60: 00000000 c04fca7c 00000000 ce0abda0 c04fcbcc 00000001 00000000 c149646c
bd80: 00000000 c04fae50 ce0b38d4 ce19fed4 ce1bd010 ce1bd044 c0c898e0 c04fc790
bda0: ce1bd010 00000001 c0c8a308 ce1bd018 ce1bd010 c0c898e0 00000000 c04fbc6c
bdc0: ce1bd018 ce1bd010 ce1b5010 c04f9f78 00000000 00000000 00000000 00000001
bde0: ce1bd000 ce1bd010 ce1b5010 cfdb13cc 00000000 ce1b5010 00000000 c05f6f28
be00: 00000000 cfdb137c c0b58048 00000001 c0b61f30 c05f7048 00000000 ce0a92e0
be20: c05f3ec0 60000013 c0c9ec18 c0b58048 00000001 c0b61f30 60000013 c0c9ec18
be40: c0b58048 cfdb137c cfd8275c c0b58048 00000001 c0b61f30 ce1b5010 00000000
be60: 00000000 c05f70a4 00000001 ce0a92e0 c05f3ec0 60000013 c0c9ec18 c0b61f30
be80: c0b58048 00000000 60000013 c0c9ec18 c0b61f30 cfd8275c cfd8176c c0b61f30
bea0: c0b58048 00000000 00000001 c0b4f858 c0b00594 c05f7228 00000001 c05f4928
bec0: c0b581b0 c0b61f30 c0c06950 ce1b13c0 c0b037f8 00000000 00000000 c0b138fc
bee0: c0c06950 c0b134fc c0c06950 c0b03814 c0c06950 c01018b0 c0c3f04c 60000013
bf00: ce0a92e8 00000000 00000000 00000006 ce0a8d40 00000000 cfdff1a7 0000009f
bf20: c082b75c c0155590 ce0a8d40 c0980c40 c0a3d9ac 00000000 00000003 00000003
bf40: c0b684a0 00000003 00000003 c0b4f844 0000009f c0cc4000 c0cc4000 c0b4f858
bf60: c0b00594 c0b00ef0 00000003 00000003 00000000 c0b00594 c5804050 c0b685b4
bf80: c076a14c 00000000 c076a14c 00000000 00000000 00000000 00000000 00000000
bfa0: 00000000 c076a154 00000000 c0107970 00000000 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 1ea05404 55c61c1d
[<c026d690>] (kfree) from [<c04632e4>] (kobject_set_name_vargs+0x7c/0xa4)
[<c04632e4>] (kobject_set_name_vargs) from [<c04f873c>] (dev_set_name+0x24/0x34)
[<c04f873c>] (dev_set_name) from [<c0498560>] (gpiochip_add_data+0x9c/0x76c)
[<c0498560>] (gpiochip_add_data) from [<c049db40>] (omap_gpio_probe+0x2d4/0x690)
[<c049db40>] (omap_gpio_probe) from [<c04fe394>] (platform_drv_probe+0x4c/0xb0)
[<c04fe394>] (platform_drv_probe) from [<c04fca7c>] (driver_probe_device+0x208/0x2c0)
[<c04fca7c>] (driver_probe_device) from [<c04fae50>] (bus_for_each_drv+0x64/0x98)
[<c04fae50>] (bus_for_each_drv) from [<c04fc790>] (__device_attach+0xb0/0x118)
[<c04fc790>] (__device_attach) from [<c04fbc6c>] (bus_probe_device+0x88/0x90)
[<c04fbc6c>] (bus_probe_device) from [<c04f9f78>] (device_add+0x348/0x568)
[<c04f9f78>] (device_add) from [<c05f6f28>] (of_platform_device_create_pdata+0x80/0xb8)
[<c05f6f28>] (of_platform_device_create_pdata) from [<c05f7048>] (of_platform_bus_create+0xdc/0x18c)
[<c05f7048>] (of_platform_bus_create) from [<c05f70a4>] (of_platform_bus_create+0x138/0x18c)
[<c05f70a4>] (of_platform_bus_create) from [<c05f7228>] (of_platform_populate+0x5c/0xac)
[<c05f7228>] (of_platform_populate) from [<c0b138fc>] (pdata_quirks_init+0x54/0x74)
[<c0b138fc>] (pdata_quirks_init) from [<c0b134fc>] (omap_generic_init+0x10/0x1c)
[<c0b134fc>] (omap_generic_init) from [<c0b03814>] (customize_machine+0x1c/0x40)
[<c0b03814>] (customize_machine) from [<c01018b0>] (do_one_initcall+0x80/0x1dc)
[<c01018b0>] (do_one_initcall) from [<c0b00ef0>] (kernel_init_freeable+0x218/0x2ec)
[<c0b00ef0>] (kernel_init_freeable) from [<c076a154>] (kernel_init+0x8/0xf4)
[<c076a154>] (kernel_init) from [<c0107970>] (ret_from_fork+0x14/0x24)
Code: e1a00005 e5922000 e0833183 e0823103 (e5932014) 
---[ end trace ebca4d029d5eaa4e ]---



From jic23 at kernel.org  Wed Feb 17 11:32:09 2016
From: jic23 at kernel.org (Jonathan Cameron)
Date: Wed, 17 Feb 2016 19:32:09 +0000
Subject: [PATCH] iio: health/afe4403: select REGMAP_SPI
In-Reply-To: <56C34AF8.7080104@ti.com>
References: <1455637959-3169264-1-git-send-email-arnd@arndb.de>
 <56C34AF8.7080104@ti.com>
Message-ID: <56C4CAB9.8000609@kernel.org>

On 16/02/16 16:14, Andrew F. Davis wrote:
> On 02/16/2016 09:52 AM, Arnd Bergmann wrote:
>> The newly added afe4403 driver uses the regmap facility to abstract
>> the I2C and SPI access. However, it fails to ensure that regmap_spi
>> is actually present:
>>
>> drivers/iio/built-in.o: In function `afe4403_probe':
>> :(.text+0x9bf8): undefined reference to `__devm_regmap_init_spi'
>>
>> This adds a Kconfig select statement like the afe4404 I2C driver
>> has.
>>
>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>> Fixes: eec96d1e2d31 ("iio: health: Add driver for the TI AFE4403 heart monitor")
>> ---
>>   drivers/iio/health/Kconfig | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/iio/health/Kconfig b/drivers/iio/health/Kconfig
>> index f0c19779ac27..c5f004a8e447 100644
>> --- a/drivers/iio/health/Kconfig
>> +++ b/drivers/iio/health/Kconfig
>> @@ -10,6 +10,7 @@ menu "Heart Rate Monitors"
>>   config AFE4403
>>       tristate "TI AFE4403 Heart Rate Monitor"
>>       depends on SPI_MASTER
>> +    select REGMAP_SPI
>>       select IIO_BUFFER
>>       select IIO_TRIGGERED_BUFFER
>>       help
>>
> 
> Oversight on my part, thanks for fix.
> 
> Acked-by: Andrew F. Davis <afd at ti.com>
Applied to the togreg branch of iio.git - initially pushed out as testing
for the autobuilders to fail to trigger similar issues... (ah well, they can't
hammer everything!)

Thanks Arnd!

Jonathan


From jic23 at kernel.org  Wed Feb 17 11:35:47 2016
From: jic23 at kernel.org (Jonathan Cameron)
Date: Wed, 17 Feb 2016 19:35:47 +0000
Subject: [PATCH] iio: health/afe4403: mark suspend/resume functions
 __maybe_unused
In-Reply-To: <3204595.MT2N1UgYF8@wuerfel>
References: <1455526993-2132098-1-git-send-email-arnd@arndb.de>
 <CAEnQRZBSYy2inu0mUtXEdhEKWQj5i-YUFDL61prvC_8P_L0adQ@mail.gmail.com>
 <3204595.MT2N1UgYF8@wuerfel>
Message-ID: <56C4CB93.3060906@kernel.org>

On 15/02/16 09:20, Arnd Bergmann wrote:
> On Monday 15 February 2016 11:18:20 Daniel Baluta wrote:
>> On Mon, Feb 15, 2016 at 11:02 AM, Arnd Bergmann <arnd at arndb.de> wrote:
>>> The newly added afe4403 driver implements suspend/resume using the
>>> SIMPLE_DEV_PM_OPS() macro, which leaves out references to the actual
>>> functions when CONFIG_PM is disabled, causing a harmless warning:
>>>
>>> health/afe4403.c:509:12: error: 'afe4403_suspend' defined but not used
>>> health/afe4403.c:530:12: error: 'afe4403_resume' defined but not used
>>>
>>> This marks the functions as __maybe_unused so we don't get those
>>> warnings.
>>>
>> Or we could put _suspend and _resume under CONFIG_PM_SLEEP.
> 
> That never works reliably. I still have a backlog of ~50 patches
> of drivers that got this wrong in the past.
> 
>> We have:
>>
>> :~/w/iio/drivers/iio$ ack-grep SIMPLE_DEV_PM_OPS | wc -l
>> 31
>>
>> and only 2 drivers using __maybe_unused.
>>
>> :~/w/iio/drivers/iio$ ack-grep maybe_unused
>> gyro/itg3200_core.c
>> 354:static int __maybe_unused itg3200_suspend(struct device *dev)
>> 365:static int __maybe_unused itg3200_resume(struct device *dev)
>>
>> adc/imx7d_adc.c
>> 553:static int __maybe_unused imx7d_adc_suspend(struct device *dev)
>> 566:static int __maybe_unused imx7d_adc_resume(struct device *dev)
>>
>> For consistency, we should use CONFIG_PM_SLEEP and get rid of __maybe_unused.
> 
> I hope to eventually kill off all the CONFIG_PM_SLEEP checks and then
> make it work automatically by redefining SIMPLE_DEV_PM_OPS so it
> leaves an unused reference to the functions.
Applied to the togreg branch of iio.git

Thanks,

Jonathan
> 
> 	Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



From mark.rutland at arm.com  Wed Feb 17 11:35:33 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 17 Feb 2016 19:35:33 +0000
Subject: [PATCH v5sub1 7/8] arm64: move kernel image to base of vmalloc
 area
In-Reply-To: <56C4A06F.3040702@virtuozzo.com>
References: <20160212151006.GJ31665@e104818-lin.cambridge.arm.com>
 <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
 <56C4A06F.3040702@virtuozzo.com>
Message-ID: <20160217193532.GL32647@leverpostej>

On Wed, Feb 17, 2016 at 07:31:43PM +0300, Andrey Ryabinin wrote:
> On 02/17/2016 05:39 PM, Mark Rutland wrote:
> > Andrey, on a tangential note, what do we do around hotplug? I assume
> > that we must unpooison the shadow region for the stack of a dead CPU,
> > but I wasn't able to figure out where we do that. Hopefuly we're not
> > just getting lucky?
> 
> We do nothing about it. AFAIU we need to clear swapper's stack,
> somewhere in secondary_start_kernel() perhaps.

Oh, joy...

Surely other architectures (e.g. x86) will need to do something similar?

Do they do anything currently? I can't see that they do...

Mark.


From jic23 at kernel.org  Wed Feb 17 11:36:20 2016
From: jic23 at kernel.org (Jonathan Cameron)
Date: Wed, 17 Feb 2016 19:36:20 +0000
Subject: [PATCH] iio: health/afe4404: mark suspend/resume functions
 __maybe_unused
In-Reply-To: <1455527958-2647084-1-git-send-email-arnd@arndb.de>
References: <1455527958-2647084-1-git-send-email-arnd@arndb.de>
Message-ID: <56C4CBB4.3050708@kernel.org>

On 15/02/16 09:19, Arnd Bergmann wrote:
> The newly added afe4404 driver implements suspend/resume using the
> SIMPLE_DEV_PM_OPS() macro, which leaves out references to the actual
> functions when CONFIG_PM is disabled, causing a harmless warning:
> 
> health/afe4404.c:509:12: error: 'afe4404_suspend' defined but not used
> health/afe4404.c:530:12: error: 'afe4404_resume' defined but not used
> 
> This marks the functions as __maybe_unused so we don't get those
> warnings.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 87aec56e27ef ("iio: health: Add driver for the TI AFE4404 heart monitor")
Applied to the togreg branch of iio.git.

Thanks,

Jonathan
> ---
>  drivers/iio/health/afe4404.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/health/afe4404.c b/drivers/iio/health/afe4404.c
> index 0759268f37e0..5096a4643784 100644
> --- a/drivers/iio/health/afe4404.c
> +++ b/drivers/iio/health/afe4404.c
> @@ -477,7 +477,7 @@ static const struct of_device_id afe4404_of_match[] = {
>  MODULE_DEVICE_TABLE(of, afe4404_of_match);
>  #endif
>  
> -static int afe4404_suspend(struct device *dev)
> +static int __maybe_unused afe4404_suspend(struct device *dev)
>  {
>  	struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>  	struct afe4404_data *afe = iio_priv(indio_dev);
> @@ -498,7 +498,7 @@ static int afe4404_suspend(struct device *dev)
>  	return 0;
>  }
>  
> -static int afe4404_resume(struct device *dev)
> +static int __maybe_unused afe4404_resume(struct device *dev)
>  {
>  	struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>  	struct afe4404_data *afe = iio_priv(indio_dev);
> 



From Jean-Philippe.Brucker at arm.com  Wed Feb 17 11:51:28 2016
From: Jean-Philippe.Brucker at arm.com (Jean-Philippe Brucker)
Date: Wed, 17 Feb 2016 19:51:28 +0000
Subject: [arm:for-next 24/31] arch/arm/kernel/hyp-stub.S:168: Error:
 selected processor does not support ARM mode `ubfx r7,r7,#28,#4'
In-Reply-To: <201602180044.PcvJbrb9%fengguang.wu@intel.com>
References: <201602180044.PcvJbrb9%fengguang.wu@intel.com>
Message-ID: <20160217195127.GA4566@e106794-lin.cambridge.arm.com>

On Thu, Feb 18, 2016 at 12:26:46AM +0800, kbuild test robot wrote:
> tree:   http://repo.or.cz/linux-2.6/linux-2.6-arm.git for-next
> head:   5aeac3b523644cbc300f17d67c8fce73df9060c0
> commit: e59941b9b3817c9b1dd6662d903150fe3f3c3b0b [24/31] ARM: 8527/1: virt: enable GICv3 system registers
> config: arm-allmodconfig (attached as .config)
> reproduce:
>         wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         git checkout e59941b9b3817c9b1dd6662d903150fe3f3c3b0b
>         # save the attached .config to linux build tree
>         make.cross ARCH=arm 
> 
> All errors (new ones prefixed by >>):
> 
>    arch/arm/kernel/hyp-stub.S: Assembler messages:
> >> arch/arm/kernel/hyp-stub.S:168: Error: selected processor does not support ARM mode `ubfx r7,r7,#28,#4'
> >> arch/arm/kernel/hyp-stub.S:176: Error: selected processor does not support ARM mode `isb'

Selected processor being arm1136j-s, it doesn't make sense to build
hyp-stub.S at all, in my opinion. We should select ARM_VIRT_EXT only
when CPU_32v6 and lower are deselected (as with LPAE). I realize such a
change might be too invasive for a fix, so I attached a version of my
patch that builds for older architectures. If there is no objection, it
will supersede the previous one.

Thanks,
Jean-Philippe

---
>From 2e188d870dcfeff0db5098d9c6ad3eaa139a7ddd Mon Sep 17 00:00:00 2001
From: Jean-Philippe Brucker <jean-philippe.brucker at arm.com>
Date: Tue, 22 Sep 2015 09:27:17 +0100
Subject: [PATCH v2] ARM: virt: enable GICv3 system registers

ARMv8 introduces system registers for the Generic Interrupt Controller's
CPU and virtual interfaces.
When GICv3 is implemented, EL2 needs to allow the kernel to use those
registers, by changing the value of ICC_HSRE.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker at arm.com>
---
 arch/arm/kernel/hyp-stub.S |   24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S
index 2a55373..6c98210 100644
--- a/arch/arm/kernel/hyp-stub.S
+++ b/arch/arm/kernel/hyp-stub.S
@@ -17,6 +17,7 @@
  */
 
 #include <linux/init.h>
+#include <linux/irqchip/arm-gic-v3.h>
 #include <linux/linkage.h>
 #include <asm/assembler.h>
 #include <asm/virt.h>
@@ -161,6 +162,29 @@ ARM_BE8(orr	r7, r7, #(1 << 25))     @ HSCTLR.EE
 1:
 #endif
 
+#ifdef CONFIG_ARM_GIC_V3
+	@ Check whether GICv3 system registers are available
+	mrc	p15, 0, r7, c0, c1, 1	@ ID_PFR1
+	lsr	r7, r7, #28
+	cmp	r7, #1
+	bne	2f
+
+	@ Enable system register accesses
+	mrc	p15, 4, r7, c12, c9, 5	@ ICC_HSRE
+	orr	r7, r7, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
+	mcr	p15, 4, r7, c12, c9, 5	@ ICC_HSRE
+	instr_sync
+
+	@ SRE bit could be forced to 0 by firmware.
+	@ Check whether it sticks before accessing any other sysreg
+	mrc	p15, 4, r7, c12, c9, 5	@ ICC_HSRE
+	tst	r7, #ICC_SRE_EL2_SRE
+	beq	2f
+	mov	r7, #0
+	mcr	p15, 4, r7, c12, c11, 0	@ ICH_HCR
+2:
+#endif
+
 	bx	lr			@ The boot CPU mode is left in r4.
 ENDPROC(__hyp_stub_install_secondary)
 
-- 
1.7.9.5



From linux.amoon at gmail.com  Wed Feb 17 11:53:14 2016
From: linux.amoon at gmail.com (Anand Moon)
Date: Thu, 18 Feb 2016 01:23:14 +0530
Subject: [RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high
 load
In-Reply-To: <1455692128-28504-4-git-send-email-k.kozlowski@samsung.com>
References: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
 <1455692128-28504-4-git-send-email-k.kozlowski@samsung.com>
Message-ID: <CANAwSgQHiJGSYB7Qhq066Mqfskwrr_3SDQGXH-WN=Wt3SEF-QA@mail.gmail.com>

Hi Krzysztof,

On 17 February 2016 at 12:25, Krzysztof Kozlowski
<k.kozlowski at samsung.com> wrote:
> After adding cpufreq-dt support to Exynos542x, the Odroid XU3-Lite can
> be easily overheated when launching eight CPU-intensive tasks:
>         thermal thermal_zone3: critical temperature reached(121 C),shutting down
>
> This seems to be specific to Odroid XU3-Lite board which officially
> supports lower frequencies than regular XU3 or XU4. When working at
> maximum CPU speed (1800 MHz big and 1300 MHz LITTLE) in warmer place for
> longer time, the fan fails to cool down the board and it reaches
> critical temperature.
>
> Add CPU cooling to Exynos5422/5800 to fix this issue. When reaching 95
> degrees of Celsius, the board will slow down by 3 steps (around
> 1400/1000 MHz). When reaching 110 degrees of Celsius go to 600 MHz.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> ---
>  arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 41 +++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
> index 2b289d7c0d13..66073ce29aee 100644
> --- a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
> @@ -34,6 +34,16 @@
>                                         hysteresis = <5000>; /* millicelsius */
>                                         type = "active";
>                                 };
> +                               cpu_alert3: cpu-alert-3 {
> +                                       temperature = <95000>; /* millicelsius */
> +                                       hysteresis = <5000>; /* millicelsius */
> +                                       type = "passive";
> +                               };
> +                               cpu_alert4: cpu-alert-4 {
> +                                       temperature = <110000>; /* millicelsius */
> +                                       hysteresis = <5000>; /* millicelsius */
> +                                       type = "passive";
> +                               };
>                                 cpu_crit0: cpu-crit-0 {
>                                         temperature = <120000>; /* millicelsius */
>                                         hysteresis = <0>; /* millicelsius */
> @@ -53,6 +63,37 @@
>                                      trip = <&cpu_alert2>;
>                                      cooling-device = <&fan0 2 3>;
>                                 };
> +
> +                               /*
> +                                * When reaching cpu_alert3, reduce CPU
> +                                * by 3 steps. On Exynos5422/5800 that would
> +                                * be: 1400 MHz and 1000 MHz.
> +                                */
> +                               map3 {
> +                                    trip = <&cpu_alert3>;
> +                                    cooling-device = <&cpu0 3 3>;
> +                               };
> +                               map4 {
> +                                    trip = <&cpu_alert3>;
> +                                    cooling-device = <&cpu4 3 3>;
> +                               };
> +
> +                               /*
> +                                * When reaching cpu_alert4, reduce CPU
> +                                * to 600 MHz (11 steps for big, 7 steps for
> +                                * LITTLE).
> +                                * Exynos5420 has less OPPs and reversed
> +                                * numbering of CPUs (big/LITTLE) so this
> +                                * would not match.
> +                                */
> +                               map5 {
> +                                    trip = <&cpu_alert4>;
> +                                    cooling-device = <&cpu0 7 7>;
> +                               };
> +                               map6 {
> +                                    trip = <&cpu_alert4>;
> +                                    cooling-device = <&cpu4 11 11>;
> +                               };
>                         };
>                 };
>         };
> --
> 2.5.0
>

could you append this patch with following changes.

diff --git a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
index 66073ce..4e72637 100644
--- a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
@@ -16,8 +16,8 @@
        thermal-zones {
                cpu0_thermal: cpu0-thermal {
                        thermal-sensors = <&tmu_cpu0 0>;
-                       polling-delay-passive = <0>;
-                       polling-delay = <0>;
+                       polling-delay-passive = <250>; /* milliseconds */
+                       polling-delay = <500>; /* milliseconds */
                        trips {
                                cpu_alert0: cpu-alert-0 {
                                        temperature = <50000>; /*
millicelsius */
---
On running linaro pm-qa diagnostic tool
----------------------------------------------------------

thermal_01.28: checking 'thermal_zone2'/'trip_point_2_temp' ='110000'...    Ok
thermal_01.29: checking 'cdev0_trip_point' exists in
'/sys/devices/virtual/thermal/thermal_zone0'... Ok
thermal_01.30: checking 'thermal_zone0/cdev0_trip_point' valid binding...   Ok
thermal_01.31: checking 'cdev4_trip_point' exists in
'/sys/devices/virtual/thermal/thermal_zone0'... Ok
thermal_01.32: checking 'thermal_zone0/cdev4_trip_point' valid binding...   Err
thermal_01.33: checking 'cdev4_trip_point' exists in
'/sys/devices/virtual/thermal/thermal_zone0'... Ok
thermal_01.34: checking 'thermal_zone0/cdev4_trip_point' valid binding...   Err
thermal_01.35: checking 'cdev4_trip_point' exists in
'/sys/devices/virtual/thermal/thermal_zone0'... Ok
thermal_01.36: checking 'thermal_zone0/cdev4_trip_point' valid binding...   Err
thermal_01.37: checking 'cdev4_trip_point' exists in
'/sys/devices/virtual/thermal/thermal_zone0'... Ok
thermal_01.38: checking 'thermal_zone0/cdev4_trip_point' valid binding...   Err

thermal_01: fail
-------------------------------------------------------
I also got lot's of error.

root at odroidxu4l:~# cpu[ 3050.847663] cpu cpu4: Failed to find dev_opp: -19
[ 3171.640836] cpu cpu4: device_opp_debug_create_link: Failed to create link
[ 3171.646197] cpu cpu4: _add_list_dev: Failed to register opp debugfs (-12)
[ 3171.653574] cpu cpu7: device_opp_debug_create_link: Failed to create link
[ 3171.659752] cpu cpu7: _add_list_dev: Failed to register opp debugfs (-12)
[ 3171.697011] cpu cpu5: cpufreq_init: failed to get clk: -2
[ 3171.732505] cpu cpu6: cpufreq_init: failed to get clk: -2
[ 3171.768160] cpu cpu7: cpufreq_init: failed to get clk: -2

Tested on Odroid-XU4

Reviewed-by: Anand Moon <linux.amoon at gmail.com>
Tested-by: Anand Moon <linux.amoon at gmail.com>

Best Regards
-Anand Moon

> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From joshc at ni.com  Wed Feb 17 11:55:43 2016
From: joshc at ni.com (Josh Cartwright)
Date: Wed, 17 Feb 2016 13:55:43 -0600
Subject: Bunch of machines are not booting in next again, GPIO regression?
In-Reply-To: <20160217192755.GC21202@atomide.com>
References: <20160217192755.GC21202@atomide.com>
Message-ID: <20160217195543.GA871@jcartwri.amer.corp.natinst.com>

On Wed, Feb 17, 2016 at 11:27:55AM -0800, Tony Lindgren wrote:
> Hi Linus,
> 
> Looks like ff2b13592299 ("gpio: make the gpiochip a real device")
> broke booting on all omaps, and probably other machines too according
> to this:
> 
> https://kernelci.org/boot/all/job/next/kernel/next-20160217/
> 
> So far we've gone from 1 failed machine with next-20160216 to
> 18 failed machines with next-20160217.
> 
> The error I'm getting on omaps is below with debug_ll enable,
> any ideas?

Hey Tony-

Looks like the newly allocated gpio_device object isn't zeroed,
confusing dev_set_name.  Can you give this a try?

  Josh

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d8511cd..59f0045 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -435,7 +435,7 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data)
 	 * First: allocate and populate the internal stat container, and
 	 * set up the struct device.
 	 */
-	gdev = kmalloc(sizeof(*gdev), GFP_KERNEL);
+	gdev = kzalloc(sizeof(*gdev), GFP_KERNEL);
 	if (!gdev)
 		return -ENOMEM;
 	gdev->dev.bus = &gpio_bus_type;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/a380e06e/attachment.sig>

From mturquette at baylibre.com  Wed Feb 17 11:57:25 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Wed, 17 Feb 2016 11:57:25 -0800
Subject: [PATCH] clk: imx: correct pwm7 clock name in driver for i.MX6UL
In-Reply-To: <CAOMZO5Cwed8uOKz6=Odu=jaaBqoNzUxm2Xv3+6TAxKGsa27Mdw@mail.gmail.com>
References: <1455734900-1913-1-git-send-email-agust@denx.de>
 <CAOMZO5Cwed8uOKz6=Odu=jaaBqoNzUxm2Xv3+6TAxKGsa27Mdw@mail.gmail.com>
Message-ID: <20160217195725.2278.96780@quark.deferred.io>

Quoting Fabio Estevam (2016-02-17 10:58:13)
> On Wed, Feb 17, 2016 at 4:48 PM, Anatolij Gustschin <agust at denx.de> wrote:
> > Don't capitalize p in the pwm7 clock name.
> >
> > Signed-off-by: Anatolij Gustschin <agust at denx.de>
> 
> Thanks.
> 
> Reviewed-by: Fabio Estevam <fabio.estevam at nxp.com>

Should I apply this to clk-next or is someone (Shawn?) gathering patches
for a pull request?

Regards,
Mike

> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From tj at kernel.org  Wed Feb 17 12:00:29 2016
From: tj at kernel.org (Tejun Heo)
Date: Wed, 17 Feb 2016 15:00:29 -0500
Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <56C4C2AE.90009@caviumnetworks.com>
References: <56C147B2.9010303@caviumnetworks.com>
 <20160215183041.GH3965@htj.duckdns.org>
 <20160216144250.GD31343@rric.localdomain>
 <56C37524.5090000@caviumnetworks.com>
 <56C37AD3.4030407@caviumnetworks.com>
 <56C37D94.8080403@caviumnetworks.com>
 <20160216211410.GI25086@rric.localdomain>
 <56C3AD1C.2000003@caviumnetworks.com>
 <20160217112931.GB31970@arm.com>
 <56C4C2AE.90009@caviumnetworks.com>
Message-ID: <20160217200029.GB4751@mtj.duckdns.org>

Hello, David.

On Wed, Feb 17, 2016 at 10:57:50AM -0800, David Daney wrote:
> If the ahci/ata maintainers insist, we can add that.

I don't mind whether it is CONFIG_ARM64 or something more specific but
I think it's a good idea to gate it some way.

> <sarcasm>

If at all possible, please write plain arguments.

> Should we also add some CONFIG_ variables for:
> 
>   ahci_mcp89_apple_enable()
>   ahci_sb600_enable_64bit()
>   ahci_p5wdh_workaround()

And I think these should be gated behind CONFIG_X86.  The lack of
gating is historic, not intentional.

Thanks.

-- 
tejun


From stefan.wahren at i2se.com  Wed Feb 17 12:01:52 2016
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Wed, 17 Feb 2016 21:01:52 +0100 (CET)
Subject: [PATCH V4 5/7] clk: bcm2835: add missing 22 HW-clocks.
In-Reply-To: <A977D3F2-1F64-41C8-B8ED-EB9F0B3554B9@martin.sperl.org>
References: <1452867667-2447-1-git-send-email-kernel@martin.sperl.org>
 <1452867667-2447-6-git-send-email-kernel@martin.sperl.org>
 <87h9hr517u.fsf@eliezer.anholt.net> <56B8782C.4060107@martin.sperl.org>
 <A977D3F2-1F64-41C8-B8ED-EB9F0B3554B9@martin.sperl.org>
Message-ID: <704229577.519481.7acc7698-e68b-4f4b-8da5-f03a550266a8.open-xchange@email.1und1.de>


> Martin Sperl <kernel at martin.sperl.org> hat am 17. Februar 2016 um 19:25
> geschrieben:
>
> As I am trying to complete the list of clocks here my ?best? summary
> so far of the clock tree for the bcm2835 taken from various sources:
> * Datasheet
> * broadcom provided VC4 headers (via https://github.com/msperl/rpi-registers)
> * mailing list
>
> And I have come up with the following description that
> you can put in graphviz or http://www.webgraphviz.com/
>
> --- cut here ---
> digraph clocks {
> graph [ordering="out"];
>
> subgraph cluster_osc {
> label = "Oscillators";
>
> "GND";
> "OSC";
> "testdebug0";
> "testdebug1";
> }
>
> subgraph cluster_pll {
> label = "PLLs";
>
> subgraph cluster_plla {
> label = "PLLA";
>
> OSC -> PLLA;
>
> PLLA -> PLLA_core;
> PLLA -> PLLA_per;
> PLLA -> PLLA_dsi0;
> PLLA -> PLLA_ccp2;
> }
>
> subgraph cluster_pllb {
> label = "PLLB";
>
> OSC -> PLLB;
>
> PLLB -> PLLB_ARM;
> PLLB -> PLLB_SP0;
> PLLB -> PLLB_SP1;
> PLLB -> PLLB_SP2;
> }
>
> subgraph cluster_pllc {
> label = "PLLC";
>
> OSC -> PLLC;
>
> PLLC -> PLLC_core0;
> PLLC -> PLLC_core1;
> PLLC -> PLLC_core2;
> PLLC -> PLLC_per;
> }
>
> subgraph cluster_plld {
> label = "PLLD";
>
> OSC -> PLLD;
>
> PLLD -> PLLD_core;
> PLLD -> PLLD_per;
> PLLD -> PLLD_dsi0;
> PLLD -> PLLD_dsi1;
> }
>
> subgraph cluster_pllh {
> label = "PLLH";
>
> OSC -> PLLH;
>
> PLLH -> PLLH_aux;
> PLLH -> PLLH_pix;
> PLLH -> PLLH_rcal;
> }
> }
>
> subgraph cluster_mux {
> label = "clocks";
>
> subgraph cluster_vpu_clocks {
> label = "VPU-clocks";
>
> subgraph cluster_vpu_mux {
> label = "VPU-mux";
>
> vGND [label="0: GND"];
> vOSC [label="1: OSC"];
> vtestdebug0 [label="2: testdebug0"];
> vtestdebug1 [label="3: testdebug1"];
> vPLLA_core [label="4: PLLA_core"];
> vPLLC_core0 [label="5: PLLC_core0"];
> vPLLD_core [label="6: PLLD_core"];
> vPLLH_aux [label="7: PLLH_aux"];
> vPLLC_core1 [label="8: PLLC_core1"];
> vPLLC_core2 [label="9: PLLC_core2"];
>
> GND -> vGND -> vpu_mux;
> OSC -> vOSC -> vpu_mux;
> testdebug0 -> vtestdebug0 -> vpu_mux;
> testdebug1 -> vtestdebug1 -> vpu_mux;
> PLLA_core -> vPLLA_core -> vpu_mux;
> PLLC_core0 -> vPLLC_core1 -> vpu_mux;
> PLLD_core -> vPLLD_core -> vpu_mux;
> PLLH_aux -> vPLLH_aux -> vpu_mux;
> PLLC_core1 -> vPLLC_core1 -> vpu_mux;
> PLLC_core2 -> vPLLC_core2 -> vpu_mux;
> }
>
> vpu_mux -> vpu;
> vpu_mux -> v3d;
> vpu_mux -> isp;
> vpu_mux -> h264;
> vpu_mux -> sdram;
> }
>
> subgraph cluster_per_clocks {
> label = "Periperial-clocks";
>
> subgraph cluster_per_mux {
> label = "Periperal-mux";
>
> pGND [label="0: GND"];
> pOSC [label="1: OSC"];
> ptestdebug0 [label="2: testdebug0"];
> ptestdebug1 [label="3: testdebug1"];
> pPLLA_per [label="4: PLLA_per"];
> pPLLC_per [label="5: PLLC_per"];
> pPLLD_per [label="5: PLLD_per"];
> pPLLH_aux [label="5: PLLH_aux"];
>
> GND -> pGND -> per_mux;
> OSC -> pOSC -> per_mux;
> testdebug0 -> ptestdebug0 -> per_mux;
> testdebug1 -> ptestdebug1 -> per_mux;
> PLLA_per -> pPLLA_per -> per_mux;
> PLLC_per -> pPLLC_per -> per_mux;
> PLLD_per -> pPLLD_per -> per_mux;
> PLLH_aux -> pPLLH_aux -> per_mux;
> }
>
> per_mux -> vec;
> per_mux -> uart;
> per_mux -> hsm;
> per_mux -> emmc;
> per_mux -> pwm;
> per_mux -> pcm;
> per_mux -> aveo;
> per_mux -> cam0;
> per_mux -> cam1;
> per_mux -> dft;
> per_mux -> dpi;
> per_mux -> dsi0e;
> per_mux -> dsi1e;
> per_mux -> gp0;
> per_mux -> gp1;
> per_mux -> gp2;
> per_mux -> slim;
> per_mux -> smi;
> }
>
> subgraph cluster_osc_clocks {
> label = "osc-clocks";
>
> subgraph cluster_osc_mux {
> label = "osc-mux";
>
> oGND [label="0: GND"];
> oOSC [label="1: OSC"];
> otestdebug0 [label="2: testdebug0"];
> otestdebug1 [label="3: testdebug1"];
>
> GND -> oGND -> osc_mux;
> OSC -> oOSC -> osc_mux;
> testdebug0 -> otestdebug0 -> osc_mux;
> testdebug1 -> otestdebug1 -> osc_mux;
> }
>
> osc_mux -> tsens;
> osc_mux -> tec;
> osc_mux -> otp;
> }
>
> subgraph cluster_unknown_mux_clocks {
> label = "unknown-parent-mux-clocks";
>
> ukn_mux -> ccp2;
> ukn_mux -> dsi0pix;
> ukn_mux -> dsi1pix;
> ukn_mux -> pulse;
> ukn_mux -> td0;
> ukn_mux -> td1;
> }
>
> subgraph cluster_debug_clocks {
> label = "debug-clocks";
>
> debug_mux -> peria;
> debug_mux -> sys;
> }
> }
>
> subgraph cluster_aux {
> label = ?auxiliar-clocks";
>
> vpu -> spi1;
> vpu -> spi2;
> vpu -> uart1;
> }
> }
> --- cut here ---
>
> I have no idea where we could put this information
> in the kernel tree - maybe this would help.
>

Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt should be a good
place.


From linux at arm.linux.org.uk  Wed Feb 17 12:08:28 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Feb 2016 20:08:28 +0000
Subject: [PATCH v5 RESEND 4/5] ARM: amba: Move reading of periphid to
 amba_match()
In-Reply-To: <56C426C4.7040907@samsung.com>
References: <1455101250-11327-1-git-send-email-m.szyprowski@samsung.com>
 <1455101250-11327-5-git-send-email-m.szyprowski@samsung.com>
 <20160215175250.GJ10826@n2100.arm.linux.org.uk>
 <56C426C4.7040907@samsung.com>
Message-ID: <20160217200828.GH19428@n2100.arm.linux.org.uk>

On Wed, Feb 17, 2016 at 08:52:36AM +0100, Marek Szyprowski wrote:
> Then the only solution right now I see is to get back to v1:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/388199.html
> which at least handles correctly device registration when power domain
> driver is available.

... and which has the ability to break platforms if the PM domain is
not already available.

What's wrong with the patch in the link above _combined_ with a patch
which addresses the concern I have with that patch: build a list of
the failed-to-register devices, and retry them later - maybe from a
late_initcall(), or a similar mechanism?

My view is the risk to existing systems is _too_ high to apply either
this patch, or the patch you link to above, and I refuse to play the
"lets apply it and see if we break anything" lottery with this.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From mwelling at ieee.org  Wed Feb 17 12:13:07 2016
From: mwelling at ieee.org (Michael Welling)
Date: Wed, 17 Feb 2016 14:13:07 -0600
Subject: Bunch of machines are not booting in next again, GPIO regression?
In-Reply-To: <20160217195543.GA871@jcartwri.amer.corp.natinst.com>
References: <20160217192755.GC21202@atomide.com>
 <20160217195543.GA871@jcartwri.amer.corp.natinst.com>
Message-ID: <20160217201259.GA16028@deathstar>

On Wed, Feb 17, 2016 at 01:55:43PM -0600, Josh Cartwright wrote:
> On Wed, Feb 17, 2016 at 11:27:55AM -0800, Tony Lindgren wrote:
> > Hi Linus,
> > 
> > Looks like ff2b13592299 ("gpio: make the gpiochip a real device")
> > broke booting on all omaps, and probably other machines too according
> > to this:
> > 
> > https://kernelci.org/boot/all/job/next/kernel/next-20160217/
> > 
> > So far we've gone from 1 failed machine with next-20160216 to
> > 18 failed machines with next-20160217.
> > 
> > The error I'm getting on omaps is below with debug_ll enable,
> > any ideas?
> 
> Hey Tony-
> 
> Looks like the newly allocated gpio_device object isn't zeroed,
> confusing dev_set_name.  Can you give this a try?
> 
>   Josh
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index d8511cd..59f0045 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -435,7 +435,7 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data)
>  	 * First: allocate and populate the internal stat container, and
>  	 * set up the struct device.
>  	 */
> -	gdev = kmalloc(sizeof(*gdev), GFP_KERNEL);
> +	gdev = kzalloc(sizeof(*gdev), GFP_KERNEL);
>  	if (!gdev)
>  		return -ENOMEM;
>  	gdev->dev.bus = &gpio_bus_type;

As you can see by my post on the GPIO mailing list, a boot failure
was occurring on the Dragonboard 410C:
http://permalink.gmane.org/gmane.linux.kernel.gpio/14360

With the above patch the board now boots. Good catch.



From tony at atomide.com  Wed Feb 17 12:22:25 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 17 Feb 2016 12:22:25 -0800
Subject: Bunch of machines are not booting in next again, GPIO regression?
In-Reply-To: <20160217201259.GA16028@deathstar>
References: <20160217192755.GC21202@atomide.com>
 <20160217195543.GA871@jcartwri.amer.corp.natinst.com>
 <20160217201259.GA16028@deathstar>
Message-ID: <20160217202224.GD21202@atomide.com>

* Michael Welling <mwelling at ieee.org> [160217 12:13]:
> On Wed, Feb 17, 2016 at 01:55:43PM -0600, Josh Cartwright wrote:
> > On Wed, Feb 17, 2016 at 11:27:55AM -0800, Tony Lindgren wrote:
> > > Hi Linus,
> > > 
> > > Looks like ff2b13592299 ("gpio: make the gpiochip a real device")
> > > broke booting on all omaps, and probably other machines too according
> > > to this:
> > > 
> > > https://kernelci.org/boot/all/job/next/kernel/next-20160217/
> > > 
> > > So far we've gone from 1 failed machine with next-20160216 to
> > > 18 failed machines with next-20160217.
> > > 
> > > The error I'm getting on omaps is below with debug_ll enable,
> > > any ideas?
> > 
> > Hey Tony-
> > 
> > Looks like the newly allocated gpio_device object isn't zeroed,
> > confusing dev_set_name.  Can you give this a try?
> > 
> >   Josh
> > 
> > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > index d8511cd..59f0045 100644
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -435,7 +435,7 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data)
> >  	 * First: allocate and populate the internal stat container, and
> >  	 * set up the struct device.
> >  	 */
> > -	gdev = kmalloc(sizeof(*gdev), GFP_KERNEL);
> > +	gdev = kzalloc(sizeof(*gdev), GFP_KERNEL);
> >  	if (!gdev)
> >  		return -ENOMEM;
> >  	gdev->dev.bus = &gpio_bus_type;
> 
> As you can see by my post on the GPIO mailing list, a boot failure
> was occurring on the Dragonboard 410C:
> http://permalink.gmane.org/gmane.linux.kernel.gpio/14360
> 
> With the above patch the board now boots. Good catch.

Yup fixes the issue for me too.

Thanks,

Tony



From carlo at caione.org  Wed Feb 17 12:34:52 2016
From: carlo at caione.org (Carlo Caione)
Date: Wed, 17 Feb 2016 21:34:52 +0100
Subject: [PATCH 1/2] ARM: meson: Adding support to retrieve serial and SoC
 revision
In-Reply-To: <1455730114-2547-2-git-send-email-romain.perier@gmail.com>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <1455730114-2547-2-git-send-email-romain.perier@gmail.com>
Message-ID: <CAOQ7t2b8N+w33zKMfedtQqJ+-u1=kGn0pK4cBXhXB8LGx6qrtQ@mail.gmail.com>

On Wed, Feb 17, 2016 at 6:28 PM, Romain Perier <romain.perier at gmail.com> wrote:
> This path adds support to get the revision and the serial of the running
> SoC, on Meson8. On these plaforms, these informations can be found into

no Meson8b or Meson6?

> CBUS registers. To do so, we instanciate a syscon register, then create

What you mean with syscon register?

> a soc_device, and finally we expose everything to the system.
>
> Signed-off-by: Romain Perier <romain.perier at gmail.com>
> ---
>  arch/arm/mach-meson/meson.c | 55 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 55 insertions(+)
>
> diff --git a/arch/arm/mach-meson/meson.c b/arch/arm/mach-meson/meson.c
> index 4e23571..2816e30 100644
> --- a/arch/arm/mach-meson/meson.c
> +++ b/arch/arm/mach-meson/meson.c
> @@ -13,8 +13,16 @@
>   *
>   */
>
> +#include <linux/of_address.h>
>  #include <linux/of_platform.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/sys_soc.h>
>  #include <asm/mach/arch.h>
> +#include <asm/system_info.h>
> +
> +#define MESON_REVISION_REG (0x45c)
>
>  static const char * const meson_common_board_compat[] = {
>         "amlogic,meson6",
> @@ -23,7 +31,54 @@ static const char * const meson_common_board_compat[] = {
>         NULL,
>  };
>
> +static void __init meson_init_machine(void)
> +{
> +       struct soc_device_attribute *soc_dev_attr;
> +       struct soc_device *soc_dev;
> +       struct regmap *hwrev;
> +       unsigned int val;
> +       int ret;
> +
> +       hwrev = syscon_regmap_lookup_by_compatible("amlogic,meson8b-hwrev");

Is this specific only for Meson8b?

> +       if (IS_ERR(hwrev)) {
> +               pr_err("hwrev node not found\n");
> +               return;
> +       }
> +
> +       soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> +       if (!soc_dev_attr)
> +               return;

Missing blank line

> +       ret = regmap_read(hwrev, 0, &val);
> +       if (ret < 0) {
> +               pr_err("Could not get SoC id\n");

kfree(soc_dev_attr)

> +               return;
> +       }
> +       system_serial_high = val << 24;
> +
> +       ret = regmap_read(hwrev, MESON_REVISION_REG, &val);
> +       if (ret < 0) {
> +               pr_err("Could not get SoC revision\n");

ditto

> +               return;
> +       }
> +       system_rev = val == 0x11111111 ? 0xA : 0xB;
> +
> +       soc_dev_attr->family = "Amlogic Meson";
> +       soc_dev_attr->revision = kasprintf(GFP_KERNEL, "0x%x", system_rev);
> +       soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "0x%x", system_serial_high);
> +
> +       soc_dev = soc_device_register(soc_dev_attr);
> +       if (IS_ERR(soc_dev)) {
> +               pr_err("Could not register soc device\n");
> +               kfree(soc_dev_attr);

leaking soc_dev_attr->revision and  soc_dev_attr->soc_id also any
reason why you are not kasprintf-ing also family?

> +               return;
> +       }
> +
> +       pr_info("Amlogic Meson SoC Rev%X (%X:%X)\n", system_rev, system_serial_high, system_rev);
> +       of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);

Compiling I got:

  CC      arch/arm/mach-meson/meson.o
arch/arm/mach-meson/meson.c: In function 'meson_init_machine':
arch/arm/mach-meson/meson.c:77:63: warning: passing argument 4 of
'of_platform_populate' from incompatible pointer type
  of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
                                                               ^
In file included from arch/arm/mach-meson/meson.c:17:0:
include/linux/of_platform.h:71:12: note: expected 'struct device *'
but argument is of type 'struct soc_device *'
 extern int of_platform_populate(struct device_node *root,
            ^

> +}
> +
>  DT_MACHINE_START(MESON, "Amlogic Meson platform")
> +       .init_machine   = meson_init_machine,

Uhm, you are assuming that this code is valid for Meson8, Meson8b and
also Meson6. Are you sure about that?

>         .dt_compat      = meson_common_board_compat,
>         .l2c_aux_val    = 0,
>         .l2c_aux_mask   = ~0,
> --
> 2.5.0

Thanks for working on this!

-- 
Carlo Caione


From carlo at caione.org  Wed Feb 17 12:36:42 2016
From: carlo at caione.org (Carlo Caione)
Date: Wed, 17 Feb 2016 21:36:42 +0100
Subject: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
In-Reply-To: <1455730114-2547-3-git-send-email-romain.perier@gmail.com>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <1455730114-2547-3-git-send-email-romain.perier@gmail.com>
Message-ID: <CAOQ7t2add21t4hFtTeUBFe9aW0EtNvSi5KS4JMb6qVC60Fj-tA@mail.gmail.com>

On Wed, Feb 17, 2016 at 6:28 PM, Romain Perier <romain.perier at gmail.com> wrote:
> These are the CBUS registers used to retrieve the revision and the
> identifier of the SoC on Meson8.
>
> Signed-off-by: Romain Perier <romain.perier at gmail.com>
> ---
>  arch/arm/boot/dts/meson8b.dtsi | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
> index 0477a81..71009dc 100644
> --- a/arch/arm/boot/dts/meson8b.dtsi
> +++ b/arch/arm/boot/dts/meson8b.dtsi
> @@ -99,6 +99,11 @@
>                 };
>         };
>
> +       hwrev at c1107d4c {
> +               compatible = "amlogic,meson8b-hwrev", "syscon";
> +               reg = <0xc1107d4c 0x460>;

Interesting. Where did you get 0x460?

> +       };
> +
>         sram: sram at d9000000 {
>                 compatible = "mmio-sram";
>                 reg = <0xd9000000 0x20000>;

This patch fails to apply on the current master. Probably because you
have based this patch on a repo containing (as I can see) also my WiP
patches on SMP.

-- 
Carlo Caione


From mturquette at baylibre.com  Wed Feb 17 12:28:24 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Wed, 17 Feb 2016 12:28:24 -0800
Subject: [PATCH 1/2] clk: add lpc18xx creg clk driver
In-Reply-To: <CAGhQ9VzB_WgB8b4_c3Z17W+K2MC7Fq7SD9zEvZUN_UJVGDZ3Wg@mail.gmail.com>
References: <1436651307-24098-1-git-send-email-manabian@gmail.com>
 <1436651307-24098-2-git-send-email-manabian@gmail.com>
 <20150811204127.31346.16729@quantum>
 <CAGhQ9VwZaM_iWTkQYVTuTiyb6gCG2y6s8WFVySCHt7YHE1qbcA@mail.gmail.com>
 <20150818002604.31346.18322@quantum>
 <CAGhQ9VzOYbHsFZQxM8823OiWpGB6vLEwX8LfvjC=DnL1iqK_qQ@mail.gmail.com>
 <20160217005629.2278.90197@quark.deferred.io>
 <CAGhQ9VzB_WgB8b4_c3Z17W+K2MC7Fq7SD9zEvZUN_UJVGDZ3Wg@mail.gmail.com>
Message-ID: <20160217202824.2278.25956@quark.deferred.io>

Quoting Joachim Eastwood (2016-02-17 10:24:12)
> On 17 February 2016 at 01:56, Michael Turquette <mturquette at baylibre.com> wrote:
> > Quoting Joachim Eastwood (2016-02-13 06:38:45)
> >> Hi Mike,
> >>
> >> Seems your reply got lost in my mailbox and I didn't notice it before
> >> Stephen replied on the cover letter. Sorry about that.
> >>
> >> On 18 August 2015 at 02:26, Michael Turquette <mturquette at baylibre.com> wrote:
> >> > Quoting Joachim Eastwood (2015-08-13 13:43:11)
> >> >> On 11 August 2015 at 22:41, Michael Turquette <mturquette at baylibre.com> wrote:
> >> >> > Hi Joachim,
> >> >> >
> >> >> > Quoting Joachim Eastwood (2015-07-11 14:48:26)
> >> >> >> +static void __init lpc18xx_creg_clk_init(struct device_node *np)
> >> >> >> +{
> >> >> >> +       const char *clk_32khz_parent;
> >> >> >> +       struct regmap *syscon;
> >> >> >> +
> >> >> >> +       syscon = syscon_node_to_regmap(np->parent);
> >> >> >> +       if (IS_ERR(syscon)) {
> >> >> >> +               pr_err("%s: syscon lookup failed\n", __func__);
> >> >> >> +               return;
> >> >> >> +       }
> >> >> >> +
> >> >> >> +       clk_32khz_parent = of_clk_get_parent_name(np, 0);
> >> >> >> +
> >> >> >> +       clk_creg[CREG_CLK_32KHZ] =
> >> >> >> +               clk_register_creg_clk(&clk_creg_clocks[CREG_CLK_32KHZ],
> >> >> >> +                                     &clk_32khz_parent, syscon);
> >> >> >> +
> >> >> >> +       clk_creg[CREG_CLK_1KHZ] =
> >> >> >> +               clk_register_creg_clk(&clk_creg_clocks[CREG_CLK_1KHZ],
> >> >> >> +                                     &clk_creg_clocks[CREG_CLK_32KHZ].name,
> >> >> >> +                                     syscon);
> >> >> >> +
> >> >> >> +       of_clk_add_provider(np, of_clk_src_onecell_get, &clk_base_data);
> >> >> >> +}
> >> >> >> +CLK_OF_DECLARE(lpc18xx_creg_clk, "nxp,lpc1850-creg-clk", lpc18xx_creg_clk_init);
> >> >> >
> >> >> > I'll ask the same question that Stephen asked in your CCU/CGU driver
> >> >> > series: is it necessary to use CLK_OF_DECLARE here or can you use the
> >> >> > platform device model?
> >> >>
> >> >> The 32 kHz clock from the CREG block is a clock parent to the CGU
> >> >> block so it's possible that it will required early. This is all
> >> >> depends on how the boot loader initially configures the CGU.
> >> >>
> >> >> Currently in the DTS for lpc18xx cgu it has:
> >> >> clocks = <&xtal>, <&xtal32>, <...>;
> >> >> xtal32 is just a temporary placeholder until the CREG clock is in place.
> >> >
> >> > Well that seems wrong. Is it just a matter of probe order where you try
> >> > to probe the cgu driver before the creg driver?
> >>
> >> The ideal probe order for the clk drivers on the lpc18xx platform
> >> would be; creg-clk, cgu and ccu.
> >> If the 32k clk is used by any of timers we need creg-clk to enable the
> >> 32k clock and determine the rate.
> >>
> >> Note that the cgu and ccu driver is using CLK_OF_DECLARE now.
> >>
> >>
> >> I have tired to create an overview of the lpc18xx clock system here:
> >> https://github.com/manabian/linux-lpc/wiki/LPC18xx-LPC43xx-clocks
> >
> > That's great, thanks a lot for the link and the nice documentation.
> >
> > It's been a while since I've looked at this thread. Do any of the
> > creg-clk, cgu or ccu clock drivers need to use CLK_OF_DECLARE? If they
> > were platform_drivers then you could use -EPROBE_DEFER to solve your
> > ordering issue.
> 
> The clock for the clocksource/timer
> (drivers/clocksource/time-lpc32xx.c) comes from cgu/ccu and can also
> come from creg-clk. So afaik they must use CLK_OF_DECLARE. Or is there
> something I am missing?

No, you're not missing anything. What I want is for clock provider
drivers to actually be real Linux device drivers. Right now the drivers
that only call CLK_OF_DECLARE are essentially just initcall hacks, and
this causes problems down the road when you decide you want your clk
provider driver to have suspend/resume ops, etc. Also I feel that having
proper drivers will be important as runtime pm and the generic power
domains stuff matures.

> Isn't true that most SoC system clock drivers must use CLK_OF_DECLARE
> because the system timer require clocks early? I thought this was the
> whole point.

On ARMv8, mandatory use of architected timers removes the need for the
clk framework to be involved with timer init, so it's definitely not
true for all platforms.

On QCOM's 32-bit platforms they have an always-on clock with a known
fixed rate, so they can either put the fixed-rate clock in DT, or even
just put the frequency as a property into the timer node with no need to
involve the clk framework (which is what they do today). That is also a
bit hacky, but it is why you won't find CLK_OF_DECLARE in
drivers/clk/qcom and all of their drivers are proper platform_drivers.

> 
> Since it is possible that the 32k clock from creg-clk can be use as a
> parent clock for the timer doesn't this mean it also must use
> CLK_OF_DECLARE?

Right, if your 32k clock is a fixed-clock, and if it is provided on the
board (e.g. external extal -> lpc timer) then you could just put the
fixed-rate clock into DT (which uses CLK_OF_DECLARE) and reference that
from your timer node. The rest of the clocks could be registered later
through a platform_driver.

Sounds like your timer clocking scheme is more complicated than that
however.

> If it wasn't possible for creg-clk to be used as a parent clock for
> the timer it could have been a platform device.
> 
> 
> The lpc18xx clock configuration that require creg-clk early would be:
> 32k - > PLL0 -> BASE_M3/M4_CLK -> CLK_M3/M4_TIMER0. See second figure
> on the webpage. Note that this is probably not a common configuration,
> but it is a valid one. (PLL0 accepts input down to 14 kHz)

I was just discussing this with Stephen and we're both curious to know
if the same "nxp,lpc1850-creg-clk" compatible string can be used with
CLK_OF_DECLARE for registering the bare minimum early clks, and also
with a platform_driver using a different table of clocks for late
registration.

The compat string could be the same, and the driver would have different
tables/setup functions to keep from re-registering the same clocks
twice.

I know that nobody likes to be the guinea pig for this type of stuff,
but the lack of participation in the Linux driver model for clk drivers
needs to curbed. Do you think the above proposed scheme could work for
your clock provider drivers?

Regards,
Mike

> 
> 
> regards,
> Joachim Eastwood


From sergei.shtylyov at cogentembedded.com  Wed Feb 17 12:41:57 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 17 Feb 2016 23:41:57 +0300
Subject: [PATCH 0/2] Add R8A7794 EtherAVB DT support
Message-ID: <1926986.gmrsfKE5A2@wasted.cogentembedded.com>

Hello.

   Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20160217v2-v4.5-rc4' tag plus the R8A7794 audio patches posted
last week. Here we add the EtherAVB device tree support for the R8A7794 SoC.

[1/2] ARM: dts: r8a7794: add EtherAVB clock
[2/2] ARM: dts: r8a7794: add EtherAVB support

WBR, Sergei



From fcooper at ti.com  Wed Feb 17 12:42:31 2016
From: fcooper at ti.com (Franklin S Cooper Jr.)
Date: Wed, 17 Feb 2016 14:42:31 -0600
Subject: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS
In-Reply-To: <alpine.DEB.2.02.1508121700500.7154@utopia.booyaka.com>
References: <1433332284-10766-1-git-send-email-vigneshr@ti.com>
 <1433332284-10766-3-git-send-email-vigneshr@ti.com>
 <alpine.DEB.2.02.1507152029460.32764@utopia.booyaka.com>
 <55A7CE59.6010600@ti.com>
 <alpine.DEB.2.02.1508121700500.7154@utopia.booyaka.com>
Message-ID: <56C4DB37.9090802@ti.com>



On 08/31/2015 10:51 AM, Paul Walmsley wrote:
> Hi
>
> On Thu, 16 Jul 2015, R, Vignesh wrote:
>
>> On 07/16/2015 03:24 AM, Paul Walmsley wrote:
>>> On Wed, 3 Jun 2015, Vignesh R wrote:
>>>
>>>> Add hwmod entries for the PWMSS on DRA7.
>>>>
>>>> Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock
>>>> equal to L4PER2_L3_GICLK/2(l3_iclk_div/2).
>>>> As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4,
>>>> clock source to PWMSS is L4PER2_L3_GICLK. But it is actually
>>>> L4PER2_L3_GICLK/2. The TRM does not show the division by 2.
>>> Is the divide-by-two coming from PWMSS_EPWM.EPWM_TBCTL[HSPCLKDIV]?  Or is 
>>> HSPCLKDIV a separate divider after the divide-by-2 you mention above?
>> No, it not related to HSPCLKDIV. The TRM wrongly states L4PER2_L3_GICLK
>> as clock input for PWMSS. But actually  L4PER2_L4_GICLK(=L3_GICLK/2) is
>> the clock input for PWMSS. This will be updated in TRM soon.
> OK
>
>>>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>>> @@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
>>>>  	},
>>>>  };
>>>>  
>>>> +/* pwmss  */
>>>> +static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
>>>> +	.rev_offs	= 0x0,
>>>> +	.sysc_offs	= 0x4,
>>>> +	.sysc_flags	= SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS,
>>> This doesn't match SPRUHZ6 Table 29-13 "PWMSS_SYSCONFIG".  There's no 
>>> RESETSTATUS bit.  There is a SOFTRESET bit. 
>>>
>>> Could you please confirm whether this is intentional?
>> sorry my bad... I will change this in v3.
> OK
>
>>>> +/* ecap0 */
>>>> +struct omap_hwmod dra7xx_ecap0_hwmod = {
>>>> +	.name		= "ecap0",
>>>> +	.class		= &dra7xx_ecap_hwmod_class,
>>>> +	.clkdm_name	= "l4per2_clkdm",
>>>> +	.main_clk	= "l4_root_clk_div",
>>> Looking at SPRUHZ6 Section 29.1.4.2 "PWMSS Modules Local Clock Gating", 
>>> there appears to be a local "mini-PRCM" for the PWMSS which implements 
>>> clock gating and reports back on the status of what I'd guess is the local 
>>> clock gating FSM.
>>>
>>> So from that point of view, you should probably create a clock driver that 
>>> manages both the clock gate request bit and the FSM status bit.  It should 
>>> be something that can be reused for the other PWMSS IP blocks.  Then 
>>> you'd create per-IP block clock nodes and set the main_clk to point to 
>>> that node.
>> Since, this register is within the config space of PWMSS, the individual
>> gating and reporting for the modules within PWMSS
>> (PWMSS_CLKCONFIG) is currently being taken care by pwm-tipwmss.c(almost
>> the sole function this driver is doing). It has been the same since
>> am335x. Adding new clock nodes will result in driver changes and also
>> changes to am335x, am437x (and other platforms) hwmod files. It also
>> involves adding new nodes to clocks.dtsi and it will be difficult to
>> maintain backward compatibility for older platforms. Is it not better to
>> keep this as is, in order to maintain consistency (with am335x, am437x
>> etc) and also that these clock bits are within IP's config space?
> It's certainly possible that we as maintainers didn't look closely enough 
> at the AM33xx data for the PWMSS when we merged it.  But if that's 
> incorrect too, then now is the time to fix this.  Otherwise it will never 
> get fixed, since each new group of people patching this code will keep 
> punting it off to the indeterminate future.
>
> In terms of hwmod data: based on the register maps in sections 29.4.3, 
> 29.3.3, and 29.2.3 of SPRUHZ6, none of these subdevices are hwmod devices.  
> They don't support the Highlander OCP registers, they have no individual 
> PRCM registers or register bitfields, and all of the idle and status 
> reporting is to the PWMSS top-level IP block itself.  So it looks to me 
> like the eCAP, eQEP, and ePWM modules should be registered via DT, rather 
> than via hwmod.  It looks like you can get away with using the 
> "simple-bus" abstraction, but you might ultimately have to define 
> something custom here.  However, the PWMSS top level subsystem, described 
> in section 29.1, does have the OCP registers, sideband signals, etc., and 
> thus should remain a hwmod-registered device (via DT).
>
> In terms of the clock data: based on section 29.1.4, section 29.1.5.2, 
> figure 29-3, and table 29-4, there are several clock gating control bits.  
> These should be modeled as clock nodes in the Linux common clock 
> framework.  Furthermore these registers are located inside the PWMSS 
> subsystem itself, and are only accessible when the PWMSS IP block is 
> functional in a PM runtime point of view: i.e., when the block is mapped 
> into memory space, clocked and out of reset, etc.  So the clock types for 
> the PWMSS_CFG IP block should most likely be implemented in the PWMSS 
> driver.  I think you'll still be able to define the clock node data itself 
> in DT, but this will probably need a closer look.  Ideally, since the 
> clock node register address data is the same for all three subsystem 
> instances, one would be able to simply include a DT include file three 
> times; but the DT binding data format may ultimately make this 
> impractical.
>
> In terms of the transition from the old approach to this approach, it ooks 
> to me like the first thing to do would be to convert
> drivers/pwm/pwm-tipwmss.c to define some clk_ops and register some clock
> nodes with the CCF.  You've got the meat of the clock gating control code
> there already.  Then the next thing to do would be to to get rid of
> pwmss_submodule_state_change() and use
> clk_{prepare,enable,disable,unprepare}*() in the drivers/pwm/pwm-ti*.c
> subdrivers instead.  All of that looks like it should be possible to  
> implement in a backwards-compatible way.  Then you'd convert the eCAP, 
> eQEP, and ePWM code to probe as platform_devices, driven from a simple-bus 
> or pwmss-bus or whatever in the DT data.  Naturally, the AM33xx/43xx data 
> should be fixed also.  

Hi Paul,

Sorry for bringing up this old thread again.

I am working on updating this patchset on behalf of Vignesh
based on your suggestion. During the process of converting
the pwm-tipwmss.c to be a clock provider I discovered that
there is an issue with the PWMSS local clock gates. For
example on AM437x if you run the below commands you will get
a " Custom Error: MASTER M2 (64-bit) TARGET L4_PER_0 (Read):
Data Access in User mode during Functional access" error.

rmmod pwm_tiecap
rmmod pwm_bl
rmmod pwm_tiecap
modprobe pwm_tiecap
modprobe pwm_bl

Full Log: http://pastebin.com/sEyy52HV

On device powerup, the various PWMSS local clock gates are
"unlocked". The remove call in the ecap driver gates the
local PWMSS clock gate for the ecap. The probe of the ecap
driver "unlocks" the clock gate for the ecap. However, once
you try to access any of the ecap registers which is
indirectly accessed by the pwm_bl driver you will get an
error. This is because the ecap clock is still being gated.

This has been verified by hardware folks on our side. Its
been determined these registers are not needed since they
were designed for devices that didn't have a PRCM.
Therefore, the current plan is to update the trms of
AM335x,AM437x,DRA7 and AM57x to make it clear that these
registers shouldn't be touched.

I plan on sending a patch for the pwm-tipwmss.c driver
essentially removing anything that touches the
PWMSS_CLKCONFIG and PWMSS_CLKSTATUS registers. I will also
be sending a v3 version of this patch since I believe the
struct omap_hwmod dra7xx_ecap0_hwmod and similar entries you
had comments about before are ok to leave as is based on the
above findings.
>
>
> - Paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From sergei.shtylyov at cogentembedded.com  Wed Feb 17 12:43:41 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 17 Feb 2016 23:43:41 +0300
Subject: [PATCH 1/2] ARM: dts: r8a7794: add EtherAVB clock
In-Reply-To: <1926986.gmrsfKE5A2@wasted.cogentembedded.com>
References: <1926986.gmrsfKE5A2@wasted.cogentembedded.com>
Message-ID: <29718029.UyjYgE2loj@wasted.cogentembedded.com>

Add the EtherAVB clock to the R8A7794 device tree.

Based on the commit eaa870b30553 ("ARM: shmobile: r8a7791: add EtherAVB clock").

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/boot/dts/r8a7794.dtsi            |    7 ++++---
 include/dt-bindings/clock/r8a7794-clock.h |    1 +
 2 files changed, 5 insertions(+), 3 deletions(-)

Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -1173,13 +1173,14 @@
 		mstp8_clks: mstp8_clks at e6150990 {
 			compatible = "renesas,r8a7794-mstp-clocks", "renesas,cpg-mstp-clocks";
 			reg = <0 0xe6150990 0 4>, <0 0xe61509a0 0 4>;
-			clocks = <&zg_clk>, <&zg_clk>, <&p_clk>;
+			clocks = <&zg_clk>, <&zg_clk>, <&hp_clk>, <&p_clk>;
 			#clock-cells = <1>;
 			clock-indices = <
-				R8A7794_CLK_VIN1 R8A7794_CLK_VIN0 R8A7794_CLK_ETHER
+				R8A7794_CLK_VIN1 R8A7794_CLK_VIN0
+				R8A7794_CLK_ETHERAVB R8A7794_CLK_ETHER
 			>;
 			clock-output-names =
-				"vin1", "vin0", "ether";
+				"vin1", "vin0", "etheravb", "ether";
 		};
 		mstp9_clks: mstp9_clks at e6150994 {
 			compatible = "renesas,r8a7794-mstp-clocks", "renesas,cpg-mstp-clocks";
Index: renesas/include/dt-bindings/clock/r8a7794-clock.h
===================================================================
--- renesas.orig/include/dt-bindings/clock/r8a7794-clock.h
+++ renesas/include/dt-bindings/clock/r8a7794-clock.h
@@ -85,6 +85,7 @@
 /* MSTP8 */
 #define R8A7794_CLK_VIN1		10
 #define R8A7794_CLK_VIN0		11
+#define R8A7794_CLK_ETHERAVB		12
 #define R8A7794_CLK_ETHER		13
 
 /* MSTP9 */



From sergei.shtylyov at cogentembedded.com  Wed Feb 17 12:45:10 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Wed, 17 Feb 2016 23:45:10 +0300
Subject: [PATCH 2/2] ARM: dts: r8a7794: add EtherAVB support
In-Reply-To: <1926986.gmrsfKE5A2@wasted.cogentembedded.com>
References: <1926986.gmrsfKE5A2@wasted.cogentembedded.com>
Message-ID: <3612334.eXmTxlrOol@wasted.cogentembedded.com>

Define the generic R8A7794 part of the EtherAVB device node.

Based on the commit 46ece349aa54 ("ARM: shmobile: r8a7791: add EtherAVB DT
support").

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

---
 arch/arm/boot/dts/r8a7794.dtsi |   12 ++++++++++++
 1 file changed, 12 insertions(+)

Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -572,6 +572,18 @@
 		status = "disabled";
 	};
 
+	avb: ethernet at e6800000 {
+		compatible = "renesas,etheravb-r8a7794",
+			     "renesas,etheravb-rcar-gen2";
+		reg = <0 0xe6800000 0 0x800>, <0 0xee0e8000 0 0x4000>;
+		interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp8_clks R8A7794_CLK_ETHERAVB>;
+		power-domains = <&cpg_clocks>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
 	/* The memory map in the User's Manual maps the cores to bus numbers */
 	i2c0: i2c at e6508000 {
 		compatible = "renesas,i2c-r8a7794";



From arnd at arndb.de  Wed Feb 17 12:50:44 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 21:50:44 +0100
Subject: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
In-Reply-To: <1455730114-2547-3-git-send-email-romain.perier@gmail.com>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <1455730114-2547-3-git-send-email-romain.perier@gmail.com>
Message-ID: <9529888.YxErSS5PS8@wuerfel>

On Wednesday 17 February 2016 18:28:34 Romain Perier wrote:
> diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
> index 0477a81..71009dc 100644
> --- a/arch/arm/boot/dts/meson8b.dtsi
> +++ b/arch/arm/boot/dts/meson8b.dtsi
> @@ -99,6 +99,11 @@
>                 };
>         };
>  
> +       hwrev at c1107d4c {
> +               compatible = "amlogic,meson8b-hwrev", "syscon";
> +               reg = <0xc1107d4c 0x460>;
> +       };
> 

That is a very odd address. Are you sure this is not part of a larger
block of registers?

	Arnd


From jic23 at kernel.org  Wed Feb 17 12:51:14 2016
From: jic23 at kernel.org (Jonathan Cameron)
Date: Wed, 17 Feb 2016 20:51:14 +0000
Subject: [PATCH] iio: pressure: ms5611: select IIO_BUFFER
In-Reply-To: <CAEnQRZBk0R-A5VEEd_D+kLKnyhc3nhrm0tv2JOkv0iqywGFtuw@mail.gmail.com>
References: <1455634525-2023774-1-git-send-email-arnd@arndb.de>
 <CAEnQRZBk0R-A5VEEd_D+kLKnyhc3nhrm0tv2JOkv0iqywGFtuw@mail.gmail.com>
Message-ID: <56C4DD42.9090400@kernel.org>

On 16/02/16 18:03, Daniel Baluta wrote:
> On Tue, Feb 16, 2016 at 4:55 PM, Arnd Bergmann <arnd at arndb.de> wrote:
>> The ms5611 driver started using the IIO_TRIGGERED_BUFFER infrastructure
>> which in turn depend on IIO_BUFFER, and it produces a build error now
>> if that is not enabled:
>>
>> warning: (... && MS5611 && ...) selects IIO_TRIGGERED_BUFFER which has unmet direct dependencies (IIO && IIO_BUFFER)
>> buffer/industrialio-triggered-buffer.c: In function 'iio_triggered_buffer_setup':
>> buffer/industrialio-triggered-buffer.c:58:2: error: implicit declaration of function 'iio_device_attach_buffer' [-Werror=implicit-function-declaration]
>> pressure/ms5611_core.c: In function 'ms5611_trigger_handler':
>> pressure/ms5611_core.c:193:2: error: implicit declaration of function 'iio_push_to_buffers_with_timestamp' [-Werror=implicit-function-declaration]
>>
>> This adds the second select.
>>
>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>> Fixes: 713bbb4efb9d ("iio: pressure: ms5611: Add triggered buffer support")
> 
> Acked-by: Daniel Baluta <daniel.baluta at intel.com>
Applied.

Thanks, I've gotten a bit too reliant on the autobuilders it seems.
Need to keep a closer eye on this stuff to stop wasting Arnd's time!

Jonathan
> 
>> ---
>>  drivers/iio/pressure/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/iio/pressure/Kconfig b/drivers/iio/pressure/Kconfig
>> index f15f66d6f527..31c0e1fd2202 100644
>> --- a/drivers/iio/pressure/Kconfig
>> +++ b/drivers/iio/pressure/Kconfig
>> @@ -69,6 +69,7 @@ config MPL3115
>>
>>  config MS5611
>>         tristate "Measurement Specialties MS5611 pressure sensor driver"
>> +       select IIO_BUFFER
>>         select IIO_TRIGGERED_BUFFER
>>         help
>>           Say Y here to build support for the Measurement Specialties
>> --
>> 2.7.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From mturquette at baylibre.com  Wed Feb 17 12:52:57 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Wed, 17 Feb 2016 12:52:57 -0800
Subject: [PATCH 2/2] clk: ti: Add support for dm814x ADPLL
In-Reply-To: <20160217173949.GB21202@atomide.com>
References: <1455312009-808-1-git-send-email-tony@atomide.com>
 <1455312009-808-3-git-send-email-tony@atomide.com>
 <20160217011930.2278.38316@quark.deferred.io>
 <20160217173949.GB21202@atomide.com>
Message-ID: <20160217205257.2278.11639@quark.deferred.io>

Quoting Tony Lindgren (2016-02-17 09:39:49)
> * Michael Turquette <mturquette at baylibre.com> [160216 17:32]:
> > Quoting Tony Lindgren (2016-02-12 13:20:09)
> > > 
> > > - Split the device tree binding into a separate patch as requested
> > >   by Mike for his conditional ack of the binding
> > 
> > Just to make life fun for you, the clk tree is once more merging DT
> > bindings descriptions and headers. You don't need to merge the patches,
> > it doesn't matter to me, but just as a heads up for the future.
> 
> OK :)
> 
> > > --- /dev/null
> > > +++ b/drivers/clk/ti/Kconfig
> > > @@ -0,0 +1,6 @@
> > > +config COMMON_CLK_TI_ADPLL
> > > +       tristate "Clock driver for dm814x ADPLL"
> > > +       depends on ARCH_OMAP2PLUS
> > > +       default y if SOC_TI81XX
> > 
> > Can we add COMPILE_TEST here?
> 
> Good idea, will add.
> 
> > > +static int ti_adpll_init_inputs(struct ti_adpll_data *d)
> > > +{
> > > +       const char *error = "need at least %i inputs";
> > > +       struct clk *clock;
> > > +       int nr_inputs;
> > > +
> > > +       nr_inputs = of_clk_get_parent_count(d->np);
> > > +       if (nr_inputs < d->c->nr_max_inputs) {
> > > +               dev_err(d->dev, error, nr_inputs);
> > > +               return -EINVAL;
> > > +       }
> > > +       of_clk_parent_fill(d->np, d->parent_names, nr_inputs);
> > > +
> > > +       clock = devm_clk_get(d->dev, d->parent_names[0]);
> > > +       if (IS_ERR(clock)) {
> > > +               dev_err(d->dev, "could not get clkinp\n");
> > > +               return PTR_ERR(clock);
> > > +       }
> > > +       d->parent_clocks[TI_ADPLL_CLKINP] = clock;
> > > +
> > > +       clock = devm_clk_get(d->dev, d->parent_names[1]);
> > > +       if (IS_ERR(clock)) {
> > > +               dev_err(d->dev, "could not get clkinpulow clock\n");
> > > +               return PTR_ERR(clock);
> > > +       }
> > > +       d->parent_clocks[TI_ADPLL_CLKINPULOW] = clock;
> > 
> > Are the clock parents known at compile-time? Can we just put that data
> > in C instead of whatever is going on here?
> 
> No they can be board specific depending how the inputs for
> clkin, clkinpulow and clkinphif are wired.
> 
> > ...
> > > +int __init dm814x_adpll_enable_init_clocks(void)
> > > +{
> > > +       int i, err;
> > > +
> > > +       if (!timer_clocks_initialized)
> > > +               return -ENODEV;
> > > +
> > > +       for (i = 0; i < ARRAY_SIZE(init_clocks); i++) {
> > > +               struct clk *clock;
> > > +
> > > +               clock = clk_get(NULL, init_clocks[i]);
> > > +               if (WARN(IS_ERR(clock), "could not find init clock %s\n",
> > > +                        init_clocks[i]))
> > > +                       continue;
> > > +               err = clk_prepare_enable(clock);
> > > +               if (WARN(err, "could not enable init clock %s\n",
> > > +                        init_clocks[i]))
> > > +                       continue;
> > 
> > We have a shiny new series that provides a standard way to do this:
> > 
> > http://lkml.kernel.org/r/<1455225554-13267-1-git-send-email-mturquette at baylibre.com>
> 
> OK nice, so tagging the MPU and DDR clocks with CLK_IS_CRITICAL or
> "clock-critical" should allow removing this code. I think in this
> case I still need to set CLK_IS_CRITICAL as the clock is output 1
> of the dts defined clock and does not have a separate dts node.

In fact I hate clock-critical as a DT property and it's only there to
support legacy DT bindings that store all clk data in DT and have zero
clk data in C. So please use the CLK_IS_CRITICAL or CLK_ENABLE_HAND_OFF
flags in C.

Do you think you will ever have a driver that wants to gate these
clocks? Probably not for MPU/DDR, but the HAND_OFF flag is a better fit
if you do. It's the same as CRITICAL but transfers the prepare/enable
reference counting to the consumer driver after that driver calls
clk_get() and clk_prepare_enable() on the HAND_OFF clk.

> 
> I can update when those patches hit Linux next, or I can do a
> follow-up patch later on if we want to avoid the dependency
> here. Which do you prefer?

Well, testing is always welcome :-)

If you rebase onto those patches then I'll add your patches to that
series for testing and merge it that way.

Regards,
Mike

> 
> Regards,
> 
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From heiko at sntech.de  Wed Feb 17 13:00:17 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Wed, 17 Feb 2016 22:00:17 +0100
Subject: [PATCH v8.1 1/2] drm/rockchip: hdmi: add Innosilicon HDMI support
In-Reply-To: <1454492697-7837-1-git-send-email-ykk@rock-chips.com>
References: <1454049768-30872-1-git-send-email-ykk@rock-chips.com>
 <1454492697-7837-1-git-send-email-ykk@rock-chips.com>
Message-ID: <3883951.Go5JsyhPRt@phil>

Am Mittwoch, 3. Februar 2016, 17:44:57 schrieb Yakir Yang:
> The Innosilicon HDMI is a low power HDMI 1.4 transmitter
> IP, and it have been integrated on some rockchip CPUs
> (like RK3036, RK312x).
> 
> Signed-off-by: Yakir Yang <ykk at rock-chips.com>

On a Kylin board against 4.5-rc
Tested-by: Heiko Stuebner <heiko at sntech.de>

@Mark: While testing I noticed a black box around my cursor. It moves with 
the cursor, so seems to be the plane itself - the hdmi driver is of course 
innocent. May there exist an issue with plane transparency?


Heiko


From tony at atomide.com  Wed Feb 17 13:20:46 2016
From: tony at atomide.com (Tony Lindgren)
Date: Wed, 17 Feb 2016 13:20:46 -0800
Subject: [PATCH 2/2] clk: ti: Add support for dm814x ADPLL
In-Reply-To: <20160217205257.2278.11639@quark.deferred.io>
References: <1455312009-808-1-git-send-email-tony@atomide.com>
 <1455312009-808-3-git-send-email-tony@atomide.com>
 <20160217011930.2278.38316@quark.deferred.io>
 <20160217173949.GB21202@atomide.com>
 <20160217205257.2278.11639@quark.deferred.io>
Message-ID: <20160217212045.GE21202@atomide.com>

* Michael Turquette <mturquette at baylibre.com> [160217 12:53]:
> Quoting Tony Lindgren (2016-02-17 09:39:49)
> > * Michael Turquette <mturquette at baylibre.com> [160216 17:32]:
> > > 
> > > We have a shiny new series that provides a standard way to do this:
> > > 
> > > http://lkml.kernel.org/r/<1455225554-13267-1-git-send-email-mturquette at baylibre.com>
> > 
> > OK nice, so tagging the MPU and DDR clocks with CLK_IS_CRITICAL or
> > "clock-critical" should allow removing this code. I think in this
> > case I still need to set CLK_IS_CRITICAL as the clock is output 1
> > of the dts defined clock and does not have a separate dts node.
> 
> In fact I hate clock-critical as a DT property and it's only there to
> support legacy DT bindings that store all clk data in DT and have zero
> clk data in C. So please use the CLK_IS_CRITICAL or CLK_ENABLE_HAND_OFF
> flags in C.
> 
> Do you think you will ever have a driver that wants to gate these
> clocks? Probably not for MPU/DDR, but the HAND_OFF flag is a better fit
> if you do. It's the same as CRITICAL but transfers the prepare/enable
> reference counting to the consumer driver after that driver calls
> clk_get() and clk_prepare_enable() on the HAND_OFF clk.

OK I'll use CLK_ENABLE_HAND_OFF then. Who knows maybe somebody
somewhere has code running on one of the coprocessors in SRAM that
actually allows gating these :)

> > I can update when those patches hit Linux next, or I can do a
> > follow-up patch later on if we want to avoid the dependency
> > here. Which do you prefer?
> 
> Well, testing is always welcome :-)
>
> If you rebase onto those patches then I'll add your patches to that
> series for testing and merge it that way.

OK will do and repost after some testing.

Regards,

Tony


From linux at arm.linux.org.uk  Wed Feb 17 13:25:51 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Feb 2016 21:25:51 +0000
Subject: [arm:for-next 24/31] arch/arm/kernel/hyp-stub.S:168: Error:
 selected processor does not support ARM mode `ubfx r7,r7,#28,#4'
In-Reply-To: <20160217195127.GA4566@e106794-lin.cambridge.arm.com>
References: <201602180044.PcvJbrb9%fengguang.wu@intel.com>
 <20160217195127.GA4566@e106794-lin.cambridge.arm.com>
Message-ID: <20160217212551.GJ19428@n2100.arm.linux.org.uk>

On Wed, Feb 17, 2016 at 07:51:28PM +0000, Jean-Philippe Brucker wrote:
> On Thu, Feb 18, 2016 at 12:26:46AM +0800, kbuild test robot wrote:
> > tree:   http://repo.or.cz/linux-2.6/linux-2.6-arm.git for-next
> > head:   5aeac3b523644cbc300f17d67c8fce73df9060c0
> > commit: e59941b9b3817c9b1dd6662d903150fe3f3c3b0b [24/31] ARM: 8527/1: virt: enable GICv3 system registers
> > config: arm-allmodconfig (attached as .config)
> > reproduce:
> >         wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> >         chmod +x ~/bin/make.cross
> >         git checkout e59941b9b3817c9b1dd6662d903150fe3f3c3b0b
> >         # save the attached .config to linux build tree
> >         make.cross ARCH=arm 
> > 
> > All errors (new ones prefixed by >>):
> > 
> >    arch/arm/kernel/hyp-stub.S: Assembler messages:
> > >> arch/arm/kernel/hyp-stub.S:168: Error: selected processor does not support ARM mode `ubfx r7,r7,#28,#4'
> > >> arch/arm/kernel/hyp-stub.S:176: Error: selected processor does not support ARM mode `isb'
> 
> Selected processor being arm1136j-s, it doesn't make sense to build
> hyp-stub.S at all, in my opinion. We should select ARM_VIRT_EXT only
> when CPU_32v6 and lower are deselected (as with LPAE). I realize such a
> change might be too invasive for a fix, so I attached a version of my
> patch that builds for older architectures. If there is no objection, it
> will supersede the previous one.

Well, in order to get to the ubfx instruction, you need the CPU to be
in HYP mode, which these older CPUs aren't going to be.  So, it's safe
to use ubfx here.

The solution to this is to add:

AFLAGS_hyp-stub.o		:=-Wa,-march=armv7

to the makefile so the toolchain will build it for ARMv7 even though
older CPUs are selected.

Thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From linux at arm.linux.org.uk  Wed Feb 17 13:32:50 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Feb 2016 21:32:50 +0000
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CACRpkdZ+G17hmVP8AejL7NTqg7k0SBC5kgF55ASjD+kfuGFJhQ@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <56C438DA.5040109@ti.com>
 <CACRpkdZ+G17hmVP8AejL7NTqg7k0SBC5kgF55ASjD+kfuGFJhQ@mail.gmail.com>
Message-ID: <20160217213250.GK19428@n2100.arm.linux.org.uk>

On Wed, Feb 17, 2016 at 05:17:33PM +0100, Linus Walleij wrote:
> As Russell points out: it's a register that contains a number saying what
> panel is connected.
> 
> So it is plug-n-play and I want to preserve this in the patch.
> 
> The alternative is to make one DTS per display type connected, but that is
> loosing all the nice plug'n'play :(

That's totally insane: we're talking about what's plugged in through
an external connector.  It's not an "internal" device connector.
These displays are external separate boxes to the board.

We don't have separate DT files just because we plugged in a USB device
to a board., or a SDIO card, or an external HDD.

> But if an overlay can do the same, I'm game for it.

That's rather eww, because that means you need to either build the
overlay into the kernel (which IIRC then ties the base DT file to
that exact kernel) or it needs to sit in userland, which means no
LCD display until userland is up and running.  It doesn't sound very
satisfactory, IMHO.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From tchalamarla at caviumnetworks.com  Wed Feb 17 13:46:47 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Wed, 17 Feb 2016 13:46:47 -0800
Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <20160217200029.GB4751@mtj.duckdns.org>
References: <56C147B2.9010303@caviumnetworks.com>
 <20160215183041.GH3965@htj.duckdns.org>
 <20160216144250.GD31343@rric.localdomain>
 <56C37524.5090000@caviumnetworks.com> <56C37AD3.4030407@caviumnetworks.com>
 <56C37D94.8080403@caviumnetworks.com>
 <20160216211410.GI25086@rric.localdomain>
 <56C3AD1C.2000003@caviumnetworks.com> <20160217112931.GB31970@arm.com>
 <56C4C2AE.90009@caviumnetworks.com> <20160217200029.GB4751@mtj.duckdns.org>
Message-ID: <56C4EA47.6010908@caviumnetworks.com>


On 02/17/2016 12:00 PM, Tejun Heo wrote:
> Hello, David.
>
> On Wed, Feb 17, 2016 at 10:57:50AM -0800, David Daney wrote:
>> If the ahci/ata maintainers insist, we can add that.
>
> I don't mind whether it is CONFIG_ARM64 or something more specific but
> I think it's a good idea to gate it some way.
>
Already posted a V3, could you please comment on that.

Thanks,
Tirumalesh.

>> <sarcasm>
>
> If at all possible, please write plain arguments.
>
>> Should we also add some CONFIG_ variables for:
>>
>>    ahci_mcp89_apple_enable()
>>    ahci_sb600_enable_64bit()
>>    ahci_p5wdh_workaround()
>
> And I think these should be gated behind CONFIG_X86.  The lack of
> gating is historic, not intentional.
>
> Thanks.
>


From manabian at gmail.com  Wed Feb 17 13:52:10 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Wed, 17 Feb 2016 22:52:10 +0100
Subject: [PATCH 1/2] clk: add lpc18xx creg clk driver
In-Reply-To: <20160217202824.2278.25956@quark.deferred.io>
References: <1436651307-24098-1-git-send-email-manabian@gmail.com>
 <1436651307-24098-2-git-send-email-manabian@gmail.com>
 <20150811204127.31346.16729@quantum>
 <CAGhQ9VwZaM_iWTkQYVTuTiyb6gCG2y6s8WFVySCHt7YHE1qbcA@mail.gmail.com>
 <20150818002604.31346.18322@quantum>
 <CAGhQ9VzOYbHsFZQxM8823OiWpGB6vLEwX8LfvjC=DnL1iqK_qQ@mail.gmail.com>
 <20160217005629.2278.90197@quark.deferred.io>
 <CAGhQ9VzB_WgB8b4_c3Z17W+K2MC7Fq7SD9zEvZUN_UJVGDZ3Wg@mail.gmail.com>
 <20160217202824.2278.25956@quark.deferred.io>
Message-ID: <CAGhQ9VxPt7FmE4JN_-rBJMNpLpGoKVKocVFPWc3siV29Pk0_mQ@mail.gmail.com>

On 17 February 2016 at 21:28, Michael Turquette <mturquette at baylibre.com> wrote:
> Quoting Joachim Eastwood (2016-02-17 10:24:12)
>> On 17 February 2016 at 01:56, Michael Turquette <mturquette at baylibre.com> wrote:
>> > Quoting Joachim Eastwood (2016-02-13 06:38:45)
>> >> Hi Mike,
>> >>
>> >> Seems your reply got lost in my mailbox and I didn't notice it before
>> >> Stephen replied on the cover letter. Sorry about that.
>> >>
>> >> On 18 August 2015 at 02:26, Michael Turquette <mturquette at baylibre.com> wrote:
>> >> > Quoting Joachim Eastwood (2015-08-13 13:43:11)
>> >> >> On 11 August 2015 at 22:41, Michael Turquette <mturquette at baylibre.com> wrote:
>> >> >> > Hi Joachim,
>> >> >> >
>> >> >> > Quoting Joachim Eastwood (2015-07-11 14:48:26)
>> >> >> >> +static void __init lpc18xx_creg_clk_init(struct device_node *np)
>> >> >> >> +{
>> >> >> >> +       const char *clk_32khz_parent;
>> >> >> >> +       struct regmap *syscon;
>> >> >> >> +
>> >> >> >> +       syscon = syscon_node_to_regmap(np->parent);
>> >> >> >> +       if (IS_ERR(syscon)) {
>> >> >> >> +               pr_err("%s: syscon lookup failed\n", __func__);
>> >> >> >> +               return;
>> >> >> >> +       }
>> >> >> >> +
>> >> >> >> +       clk_32khz_parent = of_clk_get_parent_name(np, 0);
>> >> >> >> +
>> >> >> >> +       clk_creg[CREG_CLK_32KHZ] =
>> >> >> >> +               clk_register_creg_clk(&clk_creg_clocks[CREG_CLK_32KHZ],
>> >> >> >> +                                     &clk_32khz_parent, syscon);
>> >> >> >> +
>> >> >> >> +       clk_creg[CREG_CLK_1KHZ] =
>> >> >> >> +               clk_register_creg_clk(&clk_creg_clocks[CREG_CLK_1KHZ],
>> >> >> >> +                                     &clk_creg_clocks[CREG_CLK_32KHZ].name,
>> >> >> >> +                                     syscon);
>> >> >> >> +
>> >> >> >> +       of_clk_add_provider(np, of_clk_src_onecell_get, &clk_base_data);
>> >> >> >> +}
>> >> >> >> +CLK_OF_DECLARE(lpc18xx_creg_clk, "nxp,lpc1850-creg-clk", lpc18xx_creg_clk_init);
>> >> >> >
>> >> >> > I'll ask the same question that Stephen asked in your CCU/CGU driver
>> >> >> > series: is it necessary to use CLK_OF_DECLARE here or can you use the
>> >> >> > platform device model?
>> >> >>
>> >> >> The 32 kHz clock from the CREG block is a clock parent to the CGU
>> >> >> block so it's possible that it will required early. This is all
>> >> >> depends on how the boot loader initially configures the CGU.
>> >> >>
>> >> >> Currently in the DTS for lpc18xx cgu it has:
>> >> >> clocks = <&xtal>, <&xtal32>, <...>;
>> >> >> xtal32 is just a temporary placeholder until the CREG clock is in place.
>> >> >
>> >> > Well that seems wrong. Is it just a matter of probe order where you try
>> >> > to probe the cgu driver before the creg driver?
>> >>
>> >> The ideal probe order for the clk drivers on the lpc18xx platform
>> >> would be; creg-clk, cgu and ccu.
>> >> If the 32k clk is used by any of timers we need creg-clk to enable the
>> >> 32k clock and determine the rate.
>> >>
>> >> Note that the cgu and ccu driver is using CLK_OF_DECLARE now.
>> >>
>> >>
>> >> I have tired to create an overview of the lpc18xx clock system here:
>> >> https://github.com/manabian/linux-lpc/wiki/LPC18xx-LPC43xx-clocks
>> >
>> > That's great, thanks a lot for the link and the nice documentation.
>> >
>> > It's been a while since I've looked at this thread. Do any of the
>> > creg-clk, cgu or ccu clock drivers need to use CLK_OF_DECLARE? If they
>> > were platform_drivers then you could use -EPROBE_DEFER to solve your
>> > ordering issue.
>>
>> The clock for the clocksource/timer
>> (drivers/clocksource/time-lpc32xx.c) comes from cgu/ccu and can also
>> come from creg-clk. So afaik they must use CLK_OF_DECLARE. Or is there
>> something I am missing?
>
> No, you're not missing anything. What I want is for clock provider
> drivers to actually be real Linux device drivers. Right now the drivers
> that only call CLK_OF_DECLARE are essentially just initcall hacks, and
> this causes problems down the road when you decide you want your clk
> provider driver to have suspend/resume ops, etc. Also I feel that having
> proper drivers will be important as runtime pm and the generic power
> domains stuff matures.
>
>> Isn't true that most SoC system clock drivers must use CLK_OF_DECLARE
>> because the system timer require clocks early? I thought this was the
>> whole point.
>
> On ARMv8, mandatory use of architected timers removes the need for the
> clk framework to be involved with timer init, so it's definitely not
> true for all platforms.
>
> On QCOM's 32-bit platforms they have an always-on clock with a known
> fixed rate, so they can either put the fixed-rate clock in DT, or even
> just put the frequency as a property into the timer node with no need to
> involve the clk framework (which is what they do today). That is also a
> bit hacky, but it is why you won't find CLK_OF_DECLARE in
> drivers/clk/qcom and all of their drivers are proper platform_drivers.
>
>>
>> Since it is possible that the 32k clock from creg-clk can be use as a
>> parent clock for the timer doesn't this mean it also must use
>> CLK_OF_DECLARE?
>
> Right, if your 32k clock is a fixed-clock, and if it is provided on the
> board (e.g. external extal -> lpc timer) then you could just put the
> fixed-rate clock into DT (which uses CLK_OF_DECLARE) and reference that
> from your timer node. The rest of the clocks could be registered later
> through a platform_driver.
>
> Sounds like your timer clocking scheme is more complicated than that
> however.
>
>> If it wasn't possible for creg-clk to be used as a parent clock for
>> the timer it could have been a platform device.
>>
>>
>> The lpc18xx clock configuration that require creg-clk early would be:
>> 32k - > PLL0 -> BASE_M3/M4_CLK -> CLK_M3/M4_TIMER0. See second figure
>> on the webpage. Note that this is probably not a common configuration,
>> but it is a valid one. (PLL0 accepts input down to 14 kHz)
>
> I was just discussing this with Stephen and we're both curious to know
> if the same "nxp,lpc1850-creg-clk" compatible string can be used with
> CLK_OF_DECLARE for registering the bare minimum early clks, and also
> with a platform_driver using a different table of clocks for late
> registration.
>
> The compat string could be the same, and the driver would have different
> tables/setup functions to keep from re-registering the same clocks
> twice.

creg-clk is quite simple with only two clocks and only one of them may
be needed during boot.

> I know that nobody likes to be the guinea pig for this type of stuff,
> but the lack of participation in the Linux driver model for clk drivers
> needs to curbed. Do you think the above proposed scheme could work for
> your clock provider drivers?

For creg-clk it would probably work.

cgu would need to register most of clocks early since it needs to
support whatever setup the bootloader throws at it. The only clocks
that could be taken out is the base clocks (clk_onecell_data
clk_base_data) except for one of them. But splitting this table would
be a bad idea as hw clk numbers are used as indexes for easy look up.

Come to think of it; isn't splitting the clock table between a early
init and platform driver going become a problem?
At least the lookup in the driver or framework would become more complex(?)
And won't you confuse the lookup?
If the early driver register one clock table with
of_clk_add_provider() and then sometime later the platform driver
register another clock table, both using the same of_node. How is that
suppose to work?

ccu has only 4 clocks needed early; CLK_CPU_TIMERx with x = 0..3.


Note that I don't have much time to spare on lpc18xx right now so I
might be a bit slow if you want me to implement and test stuff.


regards,
Joachim Eastwood


From stefan at agner.ch  Wed Feb 17 13:52:07 2016
From: stefan at agner.ch (Stefan Agner)
Date: Wed, 17 Feb 2016 13:52:07 -0800
Subject: [PATCH v2 2/3] ARM: dts: vf-colibri: add basic supply regulators
In-Reply-To: <CAOMZO5Bb1eGSinoNkUhB_2w8mWdA+RQA0Z4geJp8B-MfGryAHw@mail.gmail.com>
References: <1455668317-15728-1-git-send-email-stefan@agner.ch>
 <1455668317-15728-2-git-send-email-stefan@agner.ch>
 <CAOMZO5Bb1eGSinoNkUhB_2w8mWdA+RQA0Z4geJp8B-MfGryAHw@mail.gmail.com>
Message-ID: <a07b405a5c73b092eaa6422b8562b56f@agner.ch>

On 2016-02-16 16:28, Fabio Estevam wrote:
> On Tue, Feb 16, 2016 at 10:18 PM, Stefan Agner <stefan at agner.ch> wrote:
> 
>> +       reg_module_3v3: regulator-module-3v3 {
>> +               compatible = "regulator-fixed";
>> +               regulator-name = "+V3.3";
>> +               regulator-min-microvolt = <3300000>;
>> +               regulator-max-microvolt = <3300000>;
>> +               regulator-always-on;
> 
> This 'regulator-always-on' property can be removed.
> 
>> +       };
>> +
>> +       reg_module_3v3_avdd: regulator-module-3v3-avdd {
>> +               compatible = "regulator-fixed";
>> +               regulator-name = "+V3.3_AVDD_AUDIO";
>> +               regulator-min-microvolt = <3300000>;
>> +               regulator-max-microvolt = <3300000>;
>> +               regulator-always-on;
> 
> Same here.

Hm, should I remove them also in Patch 1/3? It's a fixed regulator too,
hence I guess regulator-always-on is pointless there too...?

--
Stefan


From arnd at arndb.de  Wed Feb 17 14:25:11 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 23:25:11 +0100
Subject: [PATCH] USB: cdc_subset: only build when one driver is enabled
Message-ID: <1455747932-2844084-1-git-send-email-arnd@arndb.de>

This avoids a harmless randconfig warning I get when USB_NET_CDC_SUBSET
is enabled, but all of the more specific drivers are not:

drivers/net/usb/cdc_subset.c:241:2: #warning You need to configure some hardware for this driver

The current behavior is clearly intentional, giving a warning when
a user picks a configuration that won't do anything good. The only
reason for even addressing this is that I'm getting close to
eliminating all 'randconfig' warnings on ARM, and this came up
a couple of times.

My workaround is to not even build the module when none of the
configurations are enable.

Alternatively we could simply remove the #warning (nothing wrong
for compile-testing), turn it into a runtime warning, or
change the Kconfig options into a menu to hide CONFIG_USB_NET_CDC_SUBSET.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/net/usb/Kconfig  | 10 ++++++++++
 drivers/net/usb/Makefile |  2 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 7f83504dfa69..cdde59089f72 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -395,6 +395,10 @@ config USB_NET_RNDIS_HOST
 	  The protocol specification is incomplete, and is controlled by
 	  (and for) Microsoft; it isn't an "Open" ecosystem or market.
 
+config USB_NET_CDC_SUBSET_ENABLE
+	tristate
+	depends on USB_NET_CDC_SUBSET
+
 config USB_NET_CDC_SUBSET
 	tristate "Simple USB Network Links (CDC Ethernet subset)"
 	depends on USB_USBNET
@@ -413,6 +417,7 @@ config USB_NET_CDC_SUBSET
 config USB_ALI_M5632
 	bool "ALi M5632 based 'USB 2.0 Data Link' cables"
 	depends on USB_NET_CDC_SUBSET
+	select USB_NET_CDC_SUBSET_ENABLE
 	help
 	  Choose this option if you're using a host-to-host cable
 	  based on this design, which supports USB 2.0 high speed.
@@ -420,6 +425,7 @@ config USB_ALI_M5632
 config USB_AN2720
 	bool "AnchorChips 2720 based cables (Xircom PGUNET, ...)"
 	depends on USB_NET_CDC_SUBSET
+	select USB_NET_CDC_SUBSET_ENABLE
 	help
 	  Choose this option if you're using a host-to-host cable
 	  based on this design.  Note that AnchorChips is now a
@@ -428,6 +434,7 @@ config USB_AN2720
 config USB_BELKIN
 	bool "eTEK based host-to-host cables (Advance, Belkin, ...)"
 	depends on USB_NET_CDC_SUBSET
+	select USB_NET_CDC_SUBSET_ENABLE
 	default y
 	help
 	  Choose this option if you're using a host-to-host cable
@@ -437,6 +444,7 @@ config USB_BELKIN
 config USB_ARMLINUX
 	bool "Embedded ARM Linux links (iPaq, ...)"
 	depends on USB_NET_CDC_SUBSET
+	select USB_NET_CDC_SUBSET_ENABLE
 	default y
 	help
 	  Choose this option to support the "usb-eth" networking driver
@@ -454,6 +462,7 @@ config USB_ARMLINUX
 config USB_EPSON2888
 	bool "Epson 2888 based firmware (DEVELOPMENT)"
 	depends on USB_NET_CDC_SUBSET
+	select USB_NET_CDC_SUBSET_ENABLE
 	help
 	  Choose this option to support the usb networking links used
 	  by some sample firmware from Epson.
@@ -461,6 +470,7 @@ config USB_EPSON2888
 config USB_KC2190
 	bool "KT Technology KC2190 based cables (InstaNet)"
 	depends on USB_NET_CDC_SUBSET
+	select USB_NET_CDC_SUBSET_ENABLE
 	help
 	  Choose this option if you're using a host-to-host cable
 	  with one of these chips.
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index b5f04068dbe4..37fb46aee341 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -23,7 +23,7 @@ obj-$(CONFIG_USB_NET_GL620A)	+= gl620a.o
 obj-$(CONFIG_USB_NET_NET1080)	+= net1080.o
 obj-$(CONFIG_USB_NET_PLUSB)	+= plusb.o
 obj-$(CONFIG_USB_NET_RNDIS_HOST)	+= rndis_host.o
-obj-$(CONFIG_USB_NET_CDC_SUBSET)	+= cdc_subset.o
+obj-$(CONFIG_USB_NET_CDC_SUBSET_ENABLE)	+= cdc_subset.o
 obj-$(CONFIG_USB_NET_ZAURUS)	+= zaurus.o
 obj-$(CONFIG_USB_NET_MCS7830)	+= mcs7830.o
 obj-$(CONFIG_USB_USBNET)	+= usbnet.o
-- 
2.7.0



From festevam at gmail.com  Wed Feb 17 14:29:11 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Wed, 17 Feb 2016 20:29:11 -0200
Subject: [PATCH v2 2/3] ARM: dts: vf-colibri: add basic supply regulators
In-Reply-To: <a07b405a5c73b092eaa6422b8562b56f@agner.ch>
References: <1455668317-15728-1-git-send-email-stefan@agner.ch>
 <1455668317-15728-2-git-send-email-stefan@agner.ch>
 <CAOMZO5Bb1eGSinoNkUhB_2w8mWdA+RQA0Z4geJp8B-MfGryAHw@mail.gmail.com>
 <a07b405a5c73b092eaa6422b8562b56f@agner.ch>
Message-ID: <CAOMZO5CSw=Gx52H27C_H2ytnkup6emgVxv5=FPmGnmTMEjE9CA@mail.gmail.com>

On Wed, Feb 17, 2016 at 7:52 PM, Stefan Agner <stefan at agner.ch> wrote:

> Hm, should I remove them also in Patch 1/3? It's a fixed regulator too,
> hence I guess regulator-always-on is pointless there too...?

That's correct. And from 3/3 too.


From arnd at arndb.de  Wed Feb 17 14:28:27 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 17 Feb 2016 23:28:27 +0100
Subject: [PATCH] ARM: move __kuser_cmpxchg{32,64} into .kprobes.text
Message-ID: <1455748127-2844701-1-git-send-email-arnd@arndb.de>

When kprobes is used, most of the entry-armv.S file is put into the .kprobes.text
section rather than .text, but the kuser_cmpxchg64_fixup and kuser_cmpxchg32_fixup
code is not, which can lead to a link error when extremely large kernels get
built (typically for randconfig):

arch/arm/kernel/built-in.o: In function `__dabt_usr':
:(.kprobes.text+0x47c): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o: In function `__irq_usr':
:(.kprobes.text+0x4e4): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o: In function `__fiq_usr':
:(.kprobes.text+0x740): relocation truncated to fit: R_ARM_JUMP24 against `.text'

This moves the two remaining functions into the same section as the rest,
to avoid the link error.

The current behavior has existed for many years and has not caused problems in
practice except for extreme randconfig builds, so the patch should not need to
get backported.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: b49c0f24cf67 ("[ARM] 4659/1: remove possibilities for spurious false negative with __kuser_cmpxchg")
Fixes: 785d3cd286f0 ("ARM kprobes: prevent some functions involved with kprobes from being probed")
---
 arch/arm/kernel/entry-armv.S | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index e2550500486d..030e43a0dce8 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -895,7 +895,11 @@ __kuser_cmpxchg64:				@ 0xffff0f60
 	rsbs	r0, r3, #0			@ set return val and C flag
 	ldmfd	sp!, {r4, r5, r6, pc}
 
+#ifdef CONFIG_KPROBES
+	.section	.kprobes.text,"ax",%progbits
+#else
 	.text
+#endif
 kuser_cmpxchg64_fixup:
 	@ Called from kuser_cmpxchg_fixup.
 	@ r4 = address of interrupted insn (must be preserved).
@@ -953,7 +957,11 @@ __kuser_cmpxchg:				@ 0xffff0fc0
 	rsbs	r0, r3, #0			@ set return val and C flag
 	usr_ret	lr
 
+#ifdef CONFIG_KPROBES
+	.section	.kprobes.text,"ax",%progbits
+#else
 	.text
+#endif
 kuser_cmpxchg32_fixup:
 	@ Called from kuser_cmpxchg_check macro.
 	@ r4 = address of interrupted insn (must be preserved).
-- 
2.7.0



From joshc at ni.com  Wed Feb 17 14:44:15 2016
From: joshc at ni.com (Josh Cartwright)
Date: Wed, 17 Feb 2016 16:44:15 -0600
Subject: Bunch of machines are not booting in next again, GPIO regression?
In-Reply-To: <20160217202224.GD21202@atomide.com>
References: <20160217192755.GC21202@atomide.com>
 <20160217195543.GA871@jcartwri.amer.corp.natinst.com>
 <20160217201259.GA16028@deathstar>
 <20160217202224.GD21202@atomide.com>
Message-ID: <20160217224415.GA3866@jcartwri.amer.corp.natinst.com>

On Wed, Feb 17, 2016 at 12:22:25PM -0800, Tony Lindgren wrote:
> * Michael Welling <mwelling at ieee.org> [160217 12:13]:
> > On Wed, Feb 17, 2016 at 01:55:43PM -0600, Josh Cartwright wrote:
> > > On Wed, Feb 17, 2016 at 11:27:55AM -0800, Tony Lindgren wrote:
> > > > Hi Linus,
> > > > 
> > > > Looks like ff2b13592299 ("gpio: make the gpiochip a real device")
> > > > broke booting on all omaps, and probably other machines too according
> > > > to this:
> > > > 
> > > > https://kernelci.org/boot/all/job/next/kernel/next-20160217/
> > > > 
> > > > So far we've gone from 1 failed machine with next-20160216 to
> > > > 18 failed machines with next-20160217.
> > > > 
> > > > The error I'm getting on omaps is below with debug_ll enable,
> > > > any ideas?
> > > 
> > > Hey Tony-
> > > 
> > > Looks like the newly allocated gpio_device object isn't zeroed,
> > > confusing dev_set_name.  Can you give this a try?
> > > 
> > >   Josh
> > > 
> > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > > index d8511cd..59f0045 100644
> > > --- a/drivers/gpio/gpiolib.c
> > > +++ b/drivers/gpio/gpiolib.c
> > > @@ -435,7 +435,7 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data)
> > >  	 * First: allocate and populate the internal stat container, and
> > >  	 * set up the struct device.
> > >  	 */
> > > -	gdev = kmalloc(sizeof(*gdev), GFP_KERNEL);
> > > +	gdev = kzalloc(sizeof(*gdev), GFP_KERNEL);
> > >  	if (!gdev)
> > >  		return -ENOMEM;
> > >  	gdev->dev.bus = &gpio_bus_type;
> > 
> > As you can see by my post on the GPIO mailing list, a boot failure
> > was occurring on the Dragonboard 410C:
> > http://permalink.gmane.org/gmane.linux.kernel.gpio/14360
> > 
> > With the above patch the board now boots. Good catch.
> 
> Yup fixes the issue for me too.

Linus-

Here's a properly cooked patch.  Otherwise, feel free to squash it in if
it's easier for you.

  Josh

-- 8< --
Subject: [PATCH] gpio: use kzalloc to allocate gpio_device

The use of kmalloc() to allocate the gpio_device leaves the contained struct
device object in an unknown state.  Calling dev_set_name() on a struct device
of unknown state can trigger the free() of an invalid pointer, as seen in the
following backtrace (collected by Tony Lindgren):

  kfree
  kobject_set_name_vargs
  dev_set_name
  gpiochip_add_data
  omap_gpio_probe
  platform_drv_probe
  ...

Reported-by: Michael Welling <mwelling at ieee.org>
Reported-by: Tony Lindgren <tony at atomide.com>
Tested-by: Michael Welling <mwelling at ieee.org>
Tested-by: Tony Lindgren <tony at atomide.com>
Signed-off-by: Josh Cartwright <joshc at ni.com>
---
 drivers/gpio/gpiolib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d8511cd..59f0045 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -435,7 +435,7 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data)
 	 * First: allocate and populate the internal stat container, and
 	 * set up the struct device.
 	 */
-	gdev = kmalloc(sizeof(*gdev), GFP_KERNEL);
+	gdev = kzalloc(sizeof(*gdev), GFP_KERNEL);
 	if (!gdev)
 		return -ENOMEM;
 	gdev->dev.bus = &gpio_bus_type;
-- 
2.7.0



From keescook at chromium.org  Wed Feb 17 15:00:52 2016
From: keescook at chromium.org (Kees Cook)
Date: Wed, 17 Feb 2016 15:00:52 -0800
Subject: [PATCH] ARM: vdso: Mark vDSO code as read-only
In-Reply-To: <20160217052010.GA49233@davidb.org>
References: <1453226922-16831-1-git-send-email-keescook@chromium.org>
 <20160216213659.GA47194@davidb.org>
 <CAGXu5j+H63jhcDpHpXK5aWvgUBz=5vB0FK_zRoc+wZEk32B2fg@mail.gmail.com>
 <20160217052010.GA49233@davidb.org>
Message-ID: <CAGXu5jK22LfvLdMfWz_vbQsJ3bbjSdJrYAp=5yWzD4yRNTTGFQ@mail.gmail.com>

On Tue, Feb 16, 2016 at 9:20 PM, David Brown <david.brown at linaro.org> wrote:
> On Tue, Feb 16, 2016 at 01:52:33PM -0800, Kees Cook wrote:
>>
>> On Tue, Feb 16, 2016 at 1:36 PM, David Brown <david.brown at linaro.org>
>> wrote:
>>>
>>> Although the arm vDSO is cleanly separated by code/data with the code
>>> being read-only in userspace mappings, the code page is still writable
>>> from the kernel.  There have been exploits (such as
>>> http://itszn.com/blog/?p=21) that take advantage of this on x86 to go
>>> from a bad kernel write to full root.
>>>
>>> Prevent this specific exploit on arm by putting the vDSO code page in
>>> post-init read-only memory as well.
>>
>>
>> Is the vdso dynamically built at init time like on x86, or can this
>> just use .rodata directly?
>
>
> On ARM, it is patched during init.  Arm64's is just plain read-only.

Okay, great. I've added this to my postinit-readonly series (which I
just refreshed and sent out again...)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security


From w at 1wt.eu  Wed Feb 17 14:59:58 2016
From: w at 1wt.eu (Willy Tarreau)
Date: Wed, 17 Feb 2016 23:59:58 +0100
Subject: [PATCH v2 net-next 0/8] API set for HW Buffer management
In-Reply-To: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
References: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160217225958.GA31113@1wt.eu>

Hi Gregory,

On Tue, Feb 16, 2016 at 04:33:35PM +0100, Gregory CLEMENT wrote:
> Hello,
> 
> A few weeks ago I sent a proposal for a API set for HW Buffer
> management, to have a better view of the motivation for this API see
> the cover letter of this proposal:
> http://thread.gmane.org/gmane.linux.kernel/2125152
> 
> Since this version I took into account the review from Florian:
> - The hardware buffer management helpers are no more built by default
>   and now depend on a hidden config symbol which has to be selected
>   by the driver if needed
> - The hwbm_pool_refill() and hwbm_pool_add() now receive a gfp_t as
>   argument allowing the caller to specify the flag it needs.
> - buf_num is now tested to ensure there is no wrapping
> - A spinlock has been added to protect the hwbm_pool_add() function in
>   SMP or irq context.
> 
> I also used pr_warn instead of pr_debug in case of errors.
> 
> I fixed the mvneta implementation by returning the buffer to the pool
> at various place instead of ignoring it.
> 
> About the series itself I tried to make this series easier to merge:
> - Squashed "bus: mvenus-mbus: Fix size test for
>    mvebu_mbus_get_dram_win_info" into bus: mvebu-mbus: provide api for
>    obtaining IO and DRAM window information.
> - Added my signed-otf-by on all the patches as submitter of the series.
> - Renamed the dts patches with the pattern "ARM: dts: platform:"
> - Removed the patch "ARM: mvebu: enable SRAM support in
>   mvebu_v7_defconfig" of this series and already applied it
> - Rodified the order of the patches.
> 
> In order to ease the test the branch mvneta-BM-framework-v2 is
> available at git at github.com:MISL-EBU-System-SW/mainline-public.git.

Well, I tested this patch series on top of latest master (from today)
on my fresh new clearfog board. I compared carefully with and without
the patchset. My workload was haproxy receiving connections and forwarding
them to my PC via the same port. I tested both with short connections
(HTTP GET of an empty file) and long ones (1 MB or more). No trouble
was detected at all, which is pretty good. I noticed a very tiny
performance drop which is more noticeable on short connections (high
packet rates), my forwarded connection rate went down from 17500/s to
17300/s. But I have not checked yet what can be tuned when using the
BM, nor did I compare CPU usage. I remember having run some tests in
the past, I guess it was on the XP-GP board, and noticed that the BM
could save a significant amount of CPU and improve cache efficiency,
so if this is the case here, we don't really care about a possible 1%
performance drop.

I'll try to provide more results as time permits.

In the mean time if you want (or plan to submit a next batch), feel
free to add a Tested-by: Willy Tarreau <w at 1wt.eu>.

cheers,
Willy



From isubramanian at apm.com  Wed Feb 17 15:00:38 2016
From: isubramanian at apm.com (Iyappan Subramanian)
Date: Wed, 17 Feb 2016 15:00:38 -0800
Subject: [PATCH net-next v3 0/4] Add support for Classifier and RSS
Message-ID: <1455750042-1521-1-git-send-email-isubramanian@apm.com>

This patch set enables,

(i) Classifier engine that is used for parsing
through the packet and extracting a search string that is then used
to search a database to find associative data.

(ii) Receive Side Scaling (RSS) that does dynamic load
balancing of the CPUs by controlling the number of messages enqueued
per CPU though the help of Toeplitz Hash function of 4-tuple of
source TCP/UDP port, destination TCP/UDP port, source IPV4 address and
destination IPV4 address.

(iii) Multi queue, to make advantage of RSS

v3: Address review comments from v2
    - reordered local variables from longest to shortlest line

v2: Address review comments from v1
    - fix kbuild warning
    - add default coalescing

v1:
    - Initial version

Signed-off-by: Iyappan Subramanian <isubramanian at apm.com>
---

Iyappan Subramanian (4):
  drivers: net: xgene: Add support for Classifier engine
  drivers: net: xgene: Add support for RSS
  drivers: net: xgene: Add support for multiple queues
  dtb: xgene: Add irqs to support multi queue

 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi        |   8 +-
 arch/arm64/boot/dts/apm/apm-storm.dtsi            |   8 +-
 drivers/net/ethernet/apm/xgene/Makefile           |   3 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c   | 734 ++++++++++++++++++++++
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.h   | 295 +++++++++
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c    |  12 +
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h    |   6 +
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c  | 482 ++++++++------
 drivers/net/ethernet/apm/xgene/xgene_enet_main.h  |  35 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c |  12 +
 10 files changed, 1395 insertions(+), 200 deletions(-)
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_cle.h

-- 
1.9.1



From isubramanian at apm.com  Wed Feb 17 15:00:39 2016
From: isubramanian at apm.com (Iyappan Subramanian)
Date: Wed, 17 Feb 2016 15:00:39 -0800
Subject: [PATCH net-next v3 1/4] drivers: net: xgene: Add support for
 Classifier engine
In-Reply-To: <1455750042-1521-1-git-send-email-isubramanian@apm.com>
References: <1455750042-1521-1-git-send-email-isubramanian@apm.com>
Message-ID: <1455750042-1521-2-git-send-email-isubramanian@apm.com>

Signed-off-by: Iyappan Subramanian <isubramanian at apm.com>
Signed-off-by: Khuong Dinh <kdinh at apm.com>
Signed-off-by: Tanmay Inamdar <tinamdar at apm.com>
Tested-by: Toan Le <toanle at apm.com>
---
 drivers/net/ethernet/apm/xgene/Makefile          |   3 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c  | 357 +++++++++++++++++++++++
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.h  | 254 ++++++++++++++++
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h   |   1 +
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c |  29 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_main.h |  14 +
 6 files changed, 649 insertions(+), 9 deletions(-)
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_cle.h

diff --git a/drivers/net/ethernet/apm/xgene/Makefile b/drivers/net/ethernet/apm/xgene/Makefile
index 700b5ab..f46321f 100644
--- a/drivers/net/ethernet/apm/xgene/Makefile
+++ b/drivers/net/ethernet/apm/xgene/Makefile
@@ -3,5 +3,6 @@
 #
 
 xgene-enet-objs := xgene_enet_hw.o xgene_enet_sgmac.o xgene_enet_xgmac.o \
-		   xgene_enet_main.o xgene_enet_ring2.o xgene_enet_ethtool.o
+		   xgene_enet_main.o xgene_enet_ring2.o xgene_enet_ethtool.o \
+		   xgene_enet_cle.o
 obj-$(CONFIG_NET_XGENE) += xgene-enet.o
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
new file mode 100644
index 0000000..ff24ca9
--- /dev/null
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
@@ -0,0 +1,357 @@
+/* Applied Micro X-Gene SoC Ethernet Classifier structures
+ *
+ * Copyright (c) 2016, Applied Micro Circuits Corporation
+ * Authors: Khuong Dinh <kdinh at apm.com>
+ *          Tanmay Inamdar <tinamdar at apm.com>
+ *          Iyappan Subramanian <isubramanian at apm.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * 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 "xgene_enet_main.h"
+
+static void xgene_cle_dbptr_to_hw(struct xgene_enet_pdata *pdata,
+				  struct xgene_cle_dbptr *dbptr, u32 *buf)
+{
+	buf[4] = SET_VAL(CLE_FPSEL, dbptr->fpsel) |
+		 SET_VAL(CLE_DSTQIDL, dbptr->dstqid);
+
+	buf[5] = SET_VAL(CLE_DSTQIDH, (u32)dbptr->dstqid >> CLE_DSTQIDL_LEN) |
+		 SET_VAL(CLE_PRIORITY, dbptr->cle_priority);
+}
+
+static void xgene_cle_kn_to_hw(struct xgene_cle_ptree_kn *kn, u32 *buf)
+{
+	u32 i, j = 0;
+	u32 data;
+
+	buf[j++] = SET_VAL(CLE_TYPE, kn->node_type);
+	for (i = 0; i < kn->num_keys; i++) {
+		struct xgene_cle_ptree_key *key = &kn->key[i];
+
+		if (!(i % 2)) {
+			buf[j] = SET_VAL(CLE_KN_PRIO, key->priority) |
+				 SET_VAL(CLE_KN_RPTR, key->result_pointer);
+		} else {
+			data = SET_VAL(CLE_KN_PRIO, key->priority) |
+			       SET_VAL(CLE_KN_RPTR, key->result_pointer);
+			buf[j++] |= (data << 16);
+		}
+	}
+}
+
+static void xgene_cle_dn_to_hw(struct xgene_cle_ptree_ewdn *dn,
+			       u32 *buf, u32 jb)
+{
+	struct xgene_cle_ptree_branch *br;
+	u32 i, j = 0;
+	u32 npp;
+
+	buf[j++] = SET_VAL(CLE_DN_TYPE, dn->node_type) |
+		   SET_VAL(CLE_DN_LASTN, dn->last_node) |
+		   SET_VAL(CLE_DN_HLS, dn->hdr_len_store) |
+		   SET_VAL(CLE_DN_EXT, dn->hdr_extn) |
+		   SET_VAL(CLE_DN_BSTOR, dn->byte_store) |
+		   SET_VAL(CLE_DN_SBSTOR, dn->search_byte_store) |
+		   SET_VAL(CLE_DN_RPTR, dn->result_pointer);
+
+	for (i = 0; i < dn->num_branches; i++) {
+		br = &dn->branch[i];
+		npp = br->next_packet_pointer;
+
+		if ((br->jump_rel == JMP_ABS) && (npp < CLE_PKTRAM_SIZE))
+			npp += jb;
+
+		buf[j++] = SET_VAL(CLE_BR_VALID, br->valid) |
+			   SET_VAL(CLE_BR_NPPTR, npp) |
+			   SET_VAL(CLE_BR_JB, br->jump_bw) |
+			   SET_VAL(CLE_BR_JR, br->jump_rel) |
+			   SET_VAL(CLE_BR_OP, br->operation) |
+			   SET_VAL(CLE_BR_NNODE, br->next_node) |
+			   SET_VAL(CLE_BR_NBR, br->next_branch);
+
+		buf[j++] = SET_VAL(CLE_BR_DATA, br->data) |
+			   SET_VAL(CLE_BR_MASK, br->mask);
+	}
+}
+
+static int xgene_cle_poll_cmd_done(void __iomem *base,
+				   enum xgene_cle_cmd_type cmd)
+{
+	u32 status, loop = 10;
+	int ret = -EBUSY;
+
+	while (loop--) {
+		status = ioread32(base + INDCMD_STATUS);
+		if (status & cmd) {
+			ret = 0;
+			break;
+		}
+		usleep_range(1000, 2000);
+	}
+
+	return ret;
+}
+
+static int xgene_cle_dram_wr(struct xgene_enet_cle *cle, u32 *data, u8 nregs,
+			     u32 index, enum xgene_cle_dram_type type,
+			     enum xgene_cle_cmd_type cmd)
+{
+	enum xgene_cle_parser parser = cle->active_parser;
+	void __iomem *base = cle->base;
+	u32 i, j, ind_addr;
+	u8 port, nparsers;
+	int ret = 0;
+
+	/* PTREE_RAM onwards, DRAM regions are common for all parsers */
+	nparsers = (type >= PTREE_RAM) ? 1 : cle->parsers;
+
+	for (i = 0; i < nparsers; i++) {
+		port = i;
+		if ((type < PTREE_RAM) && (parser != PARSER_ALL))
+			port = parser;
+
+		ind_addr = XGENE_CLE_DRAM(type + (port * 4)) | index;
+		iowrite32(ind_addr, base + INDADDR);
+		for (j = 0; j < nregs; j++)
+			iowrite32(data[j], base + DATA_RAM0 + (j * 4));
+		iowrite32(cmd, base + INDCMD);
+
+		ret = xgene_cle_poll_cmd_done(base, cmd);
+		if (ret)
+			break;
+	}
+
+	return ret;
+}
+
+static void xgene_cle_enable_ptree(struct xgene_enet_pdata *pdata,
+				   struct xgene_enet_cle *cle)
+{
+	struct xgene_cle_ptree *ptree = &cle->ptree;
+	void __iomem *addr, *base = cle->base;
+	u32 offset = CLE_PORT_OFFSET;
+	u32 i;
+
+	/* 1G port has to advance 4 bytes and 10G has to advance 8 bytes */
+	ptree->start_pkt += cle->jump_bytes;
+	for (i = 0; i < cle->parsers; i++) {
+		if (cle->active_parser != PARSER_ALL)
+			addr = base + cle->active_parser * offset;
+		else
+			addr = base + (i * offset);
+
+		iowrite32(ptree->start_node & 0x3fff, addr + SNPTR0);
+		iowrite32(ptree->start_pkt & 0x1ff, addr + SPPTR0);
+	}
+}
+
+static int xgene_cle_setup_dbptr(struct xgene_enet_pdata *pdata,
+				 struct xgene_enet_cle *cle)
+{
+	struct xgene_cle_ptree *ptree = &cle->ptree;
+	u32 buf[CLE_DRAM_REGS];
+	u32 i;
+	int ret;
+
+	memset(buf, 0, sizeof(buf));
+	for (i = 0; i < ptree->num_dbptr; i++) {
+		xgene_cle_dbptr_to_hw(pdata, &ptree->dbptr[i], buf);
+		ret = xgene_cle_dram_wr(cle, buf, 6, i + ptree->start_dbptr,
+					DB_RAM,	CLE_CMD_WR);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int xgene_cle_setup_node(struct xgene_enet_pdata *pdata,
+				struct xgene_enet_cle *cle)
+{
+	struct xgene_cle_ptree *ptree = &cle->ptree;
+	struct xgene_cle_ptree_ewdn *dn = ptree->dn;
+	struct xgene_cle_ptree_kn *kn = ptree->kn;
+	u32 buf[CLE_DRAM_REGS];
+	int i, j, ret;
+
+	memset(buf, 0, sizeof(buf));
+	for (i = 0; i < ptree->num_dn; i++) {
+		xgene_cle_dn_to_hw(&dn[i], buf, cle->jump_bytes);
+		ret = xgene_cle_dram_wr(cle, buf, 17, i + ptree->start_node,
+					PTREE_RAM, CLE_CMD_WR);
+		if (ret)
+			return ret;
+	}
+
+	/* continue node index for key node */
+	memset(buf, 0, sizeof(buf));
+	for (j = i; j < (ptree->num_kn + ptree->num_dn); j++) {
+		xgene_cle_kn_to_hw(&kn[j - ptree->num_dn], buf);
+		ret = xgene_cle_dram_wr(cle, buf, 17, j + ptree->start_node,
+					PTREE_RAM, CLE_CMD_WR);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int xgene_cle_setup_ptree(struct xgene_enet_pdata *pdata,
+				 struct xgene_enet_cle *cle)
+{
+	int ret;
+
+	ret = xgene_cle_setup_node(pdata, cle);
+	if (ret)
+		return ret;
+
+	ret = xgene_cle_setup_dbptr(pdata, cle);
+	if (ret)
+		return ret;
+
+	xgene_cle_enable_ptree(pdata, cle);
+
+	return 0;
+}
+
+static void xgene_cle_setup_def_dbptr(struct xgene_enet_pdata *pdata,
+				      struct xgene_enet_cle *enet_cle,
+				      struct xgene_cle_dbptr *dbptr,
+				      u32 index, u8 priority)
+{
+	void __iomem *base = enet_cle->base;
+	void __iomem *base_addr;
+	u32 buf[CLE_DRAM_REGS];
+	u32 def_cls, offset;
+	u32 i, j;
+
+	memset(buf, 0, sizeof(buf));
+	xgene_cle_dbptr_to_hw(pdata, dbptr, buf);
+
+	for (i = 0; i < enet_cle->parsers; i++) {
+		if (enet_cle->active_parser != PARSER_ALL) {
+			offset = enet_cle->active_parser *
+				CLE_PORT_OFFSET;
+		} else {
+			offset = i * CLE_PORT_OFFSET;
+		}
+
+		base_addr = base + DFCLSRESDB00 + offset;
+		for (j = 0; j < 6; j++)
+			iowrite32(buf[j], base_addr + (j * 4));
+
+		def_cls = ((priority & 0x7) << 10) | (index & 0x3ff);
+		iowrite32(def_cls, base + DFCLSRESDBPTR0 + offset);
+	}
+}
+
+static int xgene_enet_cle_init(struct xgene_enet_pdata *pdata)
+{
+	struct xgene_enet_cle *enet_cle = &pdata->cle;
+	struct xgene_cle_dbptr dbptr[DB_MAX_PTRS];
+	u32 def_qid, def_fpsel, pool_id;
+	struct xgene_cle_ptree *ptree;
+	struct xgene_cle_ptree_kn kn;
+	struct xgene_cle_ptree_ewdn ptree_dn[] = {
+		{
+			/* PKT_TYPE_NODE */
+			.node_type = EWDN,
+			.last_node = 0,
+			.hdr_len_store = 0,
+			.hdr_extn = NO_BYTE,
+			.byte_store = NO_BYTE,
+			.search_byte_store = NO_BYTE,
+			.result_pointer = DB_RES_DROP,
+			.num_branches = 1,
+			.branch = {
+				{
+					/* Allow all packet type */
+					.valid = 0,
+					.next_packet_pointer = 0,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = LAST_NODE,
+					.next_branch = 0,
+					.data = 0x0,
+					.mask = 0xffff
+				}
+			}
+		},
+		{
+			/* LAST NODE */
+			.node_type = EWDN,
+			.last_node = 1,
+			.hdr_len_store = 0,
+			.hdr_extn = NO_BYTE,
+			.byte_store = NO_BYTE,
+			.search_byte_store = NO_BYTE,
+			.result_pointer = DB_RES_DROP,
+			.num_branches = 1,
+			.branch = {
+				{
+					.valid = 0,
+					.next_packet_pointer = 0,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = MAX_NODES,
+					.next_branch = 0,
+					.data = 0,
+					.mask = 0xffff
+				}
+			}
+		}
+	};
+
+	ptree = &enet_cle->ptree;
+	ptree->start_pkt = 12; /* Ethertype */
+
+	def_qid = xgene_enet_dst_ring_num(pdata->rx_ring);
+	pool_id = pdata->rx_ring->buf_pool->id;
+	def_fpsel = xgene_enet_ring_bufnum(pool_id) - 0x20;
+
+	memset(dbptr, 0, sizeof(struct xgene_cle_dbptr) * DB_MAX_PTRS);
+	dbptr[DB_RES_ACCEPT].fpsel =  def_fpsel;
+	dbptr[DB_RES_ACCEPT].dstqid = def_qid;
+	dbptr[DB_RES_ACCEPT].cle_priority = 1;
+
+	dbptr[DB_RES_DEF].fpsel = def_fpsel;
+	dbptr[DB_RES_DEF].dstqid = def_qid;
+	dbptr[DB_RES_DEF].cle_priority = 7;
+	xgene_cle_setup_def_dbptr(pdata, enet_cle, &dbptr[DB_RES_DEF],
+				  DB_RES_ACCEPT, 7);
+
+	dbptr[DB_RES_DROP].drop = 1;
+
+	memset(&kn, 0, sizeof(kn));
+	kn.node_type = KN;
+	kn.num_keys = 1;
+	kn.key[0].priority = 0;
+	kn.key[0].result_pointer = DB_RES_ACCEPT;
+
+	ptree->dn = ptree_dn;
+	ptree->kn = &kn;
+	ptree->dbptr = dbptr;
+	ptree->num_dn = MAX_NODES;
+	ptree->num_kn = 1;
+	ptree->num_dbptr = DB_MAX_PTRS;
+
+	return xgene_cle_setup_ptree(pdata, enet_cle);
+}
+
+struct xgene_cle_ops xgene_cle3in_ops = {
+	.cle_init = xgene_enet_cle_init,
+};
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h
new file mode 100644
index 0000000..1db2fd7
--- /dev/null
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h
@@ -0,0 +1,254 @@
+/* Applied Micro X-Gene SoC Ethernet Classifier structures
+ *
+ * Copyright (c) 2016, Applied Micro Circuits Corporation
+ * Authors: Khuong Dinh <kdinh at apm.com>
+ *          Tanmay Inamdar <tinamdar at apm.com>
+ *          Iyappan Subramanian <isubramanian at apm.com>
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __XGENE_ENET_CLE_H__
+#define __XGENE_ENET_CLE_H__
+
+#include <linux/io.h>
+#include <linux/random.h>
+
+/* Register offsets */
+#define INDADDR			0x04
+#define INDCMD			0x08
+#define INDCMD_STATUS		0x0c
+#define DATA_RAM0		0x10
+#define SNPTR0			0x0100
+#define SPPTR0			0x0104
+#define DFCLSRESDBPTR0		0x0108
+#define DFCLSRESDB00		0x010c
+
+#define CLE_CMD_TO		10	/* ms */
+#define CLE_PKTRAM_SIZE		256	/* bytes */
+#define CLE_PORT_OFFSET		0x200
+#define CLE_DRAM_REGS		17
+
+#define CLE_DN_TYPE_LEN		2
+#define CLE_DN_TYPE_POS		0
+#define CLE_DN_LASTN_LEN	1
+#define CLE_DN_LASTN_POS	2
+#define CLE_DN_HLS_LEN		1
+#define CLE_DN_HLS_POS		3
+#define CLE_DN_EXT_LEN		2
+#define	CLE_DN_EXT_POS		4
+#define CLE_DN_BSTOR_LEN	2
+#define CLE_DN_BSTOR_POS	6
+#define CLE_DN_SBSTOR_LEN	2
+#define CLE_DN_SBSTOR_POS	8
+#define CLE_DN_RPTR_LEN		12
+#define CLE_DN_RPTR_POS		12
+
+#define CLE_BR_VALID_LEN	1
+#define CLE_BR_VALID_POS	0
+#define CLE_BR_NPPTR_LEN	9
+#define CLE_BR_NPPTR_POS	1
+#define CLE_BR_JB_LEN		1
+#define CLE_BR_JB_POS		10
+#define CLE_BR_JR_LEN		1
+#define CLE_BR_JR_POS		11
+#define CLE_BR_OP_LEN		3
+#define CLE_BR_OP_POS		12
+#define CLE_BR_NNODE_LEN	9
+#define CLE_BR_NNODE_POS	15
+#define CLE_BR_NBR_LEN		5
+#define CLE_BR_NBR_POS		24
+
+#define CLE_BR_DATA_LEN		16
+#define CLE_BR_DATA_POS		0
+#define CLE_BR_MASK_LEN		16
+#define CLE_BR_MASK_POS		16
+
+#define CLE_KN_PRIO_POS		0
+#define CLE_KN_PRIO_LEN		3
+#define CLE_KN_RPTR_POS		3
+#define CLE_KN_RPTR_LEN		10
+#define CLE_TYPE_POS		0
+#define CLE_TYPE_LEN		2
+
+#define CLE_DSTQIDL_POS		25
+#define CLE_DSTQIDL_LEN		7
+#define CLE_DSTQIDH_POS		0
+#define CLE_DSTQIDH_LEN		5
+#define CLE_FPSEL_POS		21
+#define CLE_FPSEL_LEN		4
+#define CLE_PRIORITY_POS	5
+#define CLE_PRIORITY_LEN	3
+
+#define JMP_ABS			0
+#define JMP_REL			1
+#define JMP_FW			0
+#define JMP_BW			1
+
+enum xgene_cle_ptree_nodes {
+	PKT_TYPE_NODE,
+	LAST_NODE,
+	MAX_NODES
+};
+
+enum xgene_cle_byte_store {
+	NO_BYTE,
+	FIRST_BYTE,
+	SECOND_BYTE,
+	BOTH_BYTES
+};
+
+/* Preclassification operation types */
+enum xgene_cle_node_type {
+	INV,
+	KN,
+	EWDN,
+	RES_NODE
+};
+
+/* Preclassification operation types */
+enum xgene_cle_op_type {
+	EQT,
+	NEQT,
+	LTEQT,
+	GTEQT,
+	AND,
+	NAND
+};
+
+enum xgene_cle_parser {
+	PARSER0,
+	PARSER1,
+	PARSER2,
+	PARSER_ALL
+};
+
+#define XGENE_CLE_DRAM(type)	(((type) & 0xf) << 28)
+enum xgene_cle_dram_type {
+	PKT_RAM,
+	PTREE_RAM = 0xc,
+	AVL_RAM,
+	DB_RAM
+};
+
+enum xgene_cle_cmd_type {
+	CLE_CMD_WR = 1,
+	CLE_CMD_RD = 2,
+	CLE_CMD_AVL_ADD = 8,
+	CLE_CMD_AVL_DEL = 16,
+	CLE_CMD_AVL_SRCH = 32
+};
+
+enum xgene_cle_ptree_dbptrs {
+	DB_RES_DROP,
+	DB_RES_DEF,
+	DB_RES_ACCEPT,
+	DB_MAX_PTRS
+};
+
+struct xgene_cle_ptree_branch {
+	bool valid;
+	u16 next_packet_pointer;
+	bool jump_bw;
+	bool jump_rel;
+	u8 operation;
+	u16 next_node;
+	u8 next_branch;
+	u16 data;
+	u16 mask;
+};
+
+struct xgene_cle_ptree_ewdn {
+	u8 node_type;
+	bool last_node;
+	bool hdr_len_store;
+	u8 hdr_extn;
+	u8 byte_store;
+	u8 search_byte_store;
+	u16 result_pointer;
+	u8 num_branches;
+	struct xgene_cle_ptree_branch branch[6];
+};
+
+struct xgene_cle_ptree_key {
+	u8 priority;
+	u16 result_pointer;
+};
+
+struct xgene_cle_ptree_kn {
+	u8 node_type;
+	u8 num_keys;
+	struct xgene_cle_ptree_key key[32];
+};
+
+struct xgene_cle_dbptr {
+	u8 split_boundary;
+	u8 mirror_nxtfpsel;
+	u8 mirror_fpsel;
+	u16 mirror_dstqid;
+	u8 drop;
+	u8 mirror;
+	u8 hdr_data_split;
+	u64 hopinfomsbs;
+	u8 DR;
+	u8 HR;
+	u64 hopinfomlsbs;
+	u16 h0enq_num;
+	u8 h0fpsel;
+	u8 nxtfpsel;
+	u8 fpsel;
+	u16 dstqid;
+	u8 cle_priority;
+	u8 cle_flowgroup;
+	u8 cle_perflow;
+	u8 cle_insert_timestamp;
+	u8 stash;
+	u8 in;
+	u8 perprioen;
+	u8 perflowgroupen;
+	u8 perflowen;
+	u8 selhash;
+	u8 selhdrext;
+	u8 mirror_nxtfpsel_msb;
+	u8 mirror_fpsel_msb;
+	u8 hfpsel_msb;
+	u8 nxtfpsel_msb;
+	u8 fpsel_msb;
+};
+
+struct xgene_cle_ptree {
+	struct xgene_cle_ptree_ewdn *dn;
+	struct xgene_cle_ptree_kn *kn;
+	struct xgene_cle_dbptr *dbptr;
+	u32 num_dn;
+	u32 num_kn;
+	u32 num_dbptr;
+	u32 start_node;
+	u32 start_pkt;
+	u32 start_dbptr;
+};
+
+struct xgene_enet_cle {
+	void __iomem *base;
+	struct xgene_cle_ptree ptree;
+	enum xgene_cle_parser active_parser;
+	u32 parsers;
+	u32 max_nodes;
+	u32 max_dbptrs;
+	u32 jump_bytes;
+};
+
+extern struct xgene_cle_ops xgene_cle3in_ops;
+
+#endif /* __XGENE_ENET_CLE_H__ */
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
index 8a90910..45725ec 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
@@ -101,6 +101,7 @@ enum xgene_enet_rm {
 #define MAC_OFFSET			0x30
 
 #define BLOCK_ETH_CSR_OFFSET		0x2000
+#define BLOCK_ETH_CLE_CSR_OFFSET	0x6000
 #define BLOCK_ETH_RING_IF_OFFSET	0x9000
 #define BLOCK_ETH_CLKRST_CSR_OFFSET	0xc000
 #define BLOCK_ETH_DIAG_CSR_OFFSET	0xD000
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 5eb9b20..0bf3924 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -93,13 +93,6 @@ static int xgene_enet_refill_bufpool(struct xgene_enet_desc_ring *buf_pool,
 	return 0;
 }
 
-static u16 xgene_enet_dst_ring_num(struct xgene_enet_desc_ring *ring)
-{
-	struct xgene_enet_pdata *pdata = netdev_priv(ring->ndev);
-
-	return ((u16)pdata->rm << 10) | ring->num;
-}
-
 static u8 xgene_enet_hdr_len(const void *data)
 {
 	const struct ethhdr *eth = data;
@@ -1278,6 +1271,7 @@ static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
 	else
 		base_addr = pdata->base_addr;
 	pdata->eth_csr_addr = base_addr + BLOCK_ETH_CSR_OFFSET;
+	pdata->cle.base = base_addr + BLOCK_ETH_CLE_CSR_OFFSET;
 	pdata->eth_ring_if_addr = base_addr + BLOCK_ETH_RING_IF_OFFSET;
 	pdata->eth_diag_csr_addr = base_addr + BLOCK_ETH_DIAG_CSR_OFFSET;
 	if (pdata->phy_mode == PHY_INTERFACE_MODE_RGMII ||
@@ -1298,6 +1292,7 @@ static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
 
 static int xgene_enet_init_hw(struct xgene_enet_pdata *pdata)
 {
+	struct xgene_enet_cle *enet_cle = &pdata->cle;
 	struct net_device *ndev = pdata->ndev;
 	struct xgene_enet_desc_ring *buf_pool;
 	u16 dst_ring_num;
@@ -1323,7 +1318,24 @@ static int xgene_enet_init_hw(struct xgene_enet_pdata *pdata)
 	}
 
 	dst_ring_num = xgene_enet_dst_ring_num(pdata->rx_ring);
-	pdata->port_ops->cle_bypass(pdata, dst_ring_num, buf_pool->id);
+	if (pdata->phy_mode == PHY_INTERFACE_MODE_XGMII) {
+		/* Initialize and Enable  PreClassifier Tree */
+		enet_cle->max_nodes = 512;
+		enet_cle->max_dbptrs = 1024;
+		enet_cle->parsers = 3;
+		enet_cle->active_parser = PARSER_ALL;
+		enet_cle->ptree.start_node = 0;
+		enet_cle->ptree.start_dbptr = 0;
+		enet_cle->jump_bytes = 8;
+		ret = pdata->cle_ops->cle_init(pdata);
+		if (ret) {
+			netdev_err(ndev, "Preclass Tree init error\n");
+			return ret;
+		}
+	} else {
+		pdata->port_ops->cle_bypass(pdata, dst_ring_num, buf_pool->id);
+	}
+
 	pdata->mac_ops->init(pdata);
 
 	return ret;
@@ -1345,6 +1357,7 @@ static void xgene_enet_setup_ops(struct xgene_enet_pdata *pdata)
 	default:
 		pdata->mac_ops = &xgene_xgmac_ops;
 		pdata->port_ops = &xgene_xgport_ops;
+		pdata->cle_ops = &xgene_cle3in_ops;
 		pdata->rm = RM0;
 		break;
 	}
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
index 248dfc4..05365c1 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
@@ -36,6 +36,7 @@
 #include <linux/if_vlan.h>
 #include <linux/phy.h>
 #include "xgene_enet_hw.h"
+#include "xgene_enet_cle.h"
 #include "xgene_enet_ring2.h"
 
 #define XGENE_DRV_VERSION	"v1.0"
@@ -145,6 +146,10 @@ struct xgene_ring_ops {
 	u32 (*len)(struct xgene_enet_desc_ring *);
 };
 
+struct xgene_cle_ops {
+	int (*cle_init)(struct xgene_enet_pdata *pdata);
+};
+
 /* ethernet private data */
 struct xgene_enet_pdata {
 	struct net_device *ndev;
@@ -174,10 +179,12 @@ struct xgene_enet_pdata {
 	void __iomem *ring_cmd_addr;
 	int phy_mode;
 	enum xgene_enet_rm rm;
+	struct xgene_enet_cle cle;
 	struct rtnl_link_stats64 stats;
 	const struct xgene_mac_ops *mac_ops;
 	const struct xgene_port_ops *port_ops;
 	struct xgene_ring_ops *ring_ops;
+	struct xgene_cle_ops *cle_ops;
 	struct delayed_work link_work;
 	u32 port_id;
 	u8 cpu_bufnum;
@@ -229,6 +236,13 @@ static inline struct device *ndev_to_dev(struct net_device *ndev)
 	return ndev->dev.parent;
 }
 
+static inline u16 xgene_enet_dst_ring_num(struct xgene_enet_desc_ring *ring)
+{
+	struct xgene_enet_pdata *pdata = netdev_priv(ring->ndev);
+
+	return ((u16)pdata->rm << 10) | ring->num;
+}
+
 void xgene_enet_set_ethtool_ops(struct net_device *netdev);
 
 #endif /* __XGENE_ENET_MAIN_H__ */
-- 
1.9.1



From isubramanian at apm.com  Wed Feb 17 15:00:42 2016
From: isubramanian at apm.com (Iyappan Subramanian)
Date: Wed, 17 Feb 2016 15:00:42 -0800
Subject: [PATCH net-next v3 4/4] dtb: xgene: Add irqs to support multi queue
In-Reply-To: <1455750042-1521-1-git-send-email-isubramanian@apm.com>
References: <1455750042-1521-1-git-send-email-isubramanian@apm.com>
Message-ID: <1455750042-1521-5-git-send-email-isubramanian@apm.com>

Signed-off-by: Iyappan Subramanian <isubramanian at apm.com>
Signed-off-by: Khuong Dinh <kdinh at apm.com>
Signed-off-by: Tanmay Inamdar <tinamdar at apm.com>
Tested-by: Toan Le <toanle at apm.com>
---
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 8 +++++++-
 arch/arm64/boot/dts/apm/apm-storm.dtsi     | 8 +++++++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
index 5d87a3d..278f106 100644
--- a/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-shadowcat.dtsi
@@ -621,7 +621,13 @@
 			      <0x0 0x1f600000 0x0 0Xd100>,
 			      <0x0 0x20000000 0x0 0X220000>;
 			interrupts = <0 108 4>,
-				     <0 109 4>;
+				     <0 109 4>,
+				     <0 110 4>,
+				     <0 111 4>,
+				     <0 112 4>,
+				     <0 113 4>,
+				     <0 114 4>,
+				     <0 115 4>;
 			port-id = <1>;
 			dma-coherent;
 			clocks = <&xge1clk 0>;
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index fe30f76..cafb2c2 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -958,7 +958,13 @@
 			      <0x0 0x18000000 0x0 0X200>;
 			reg-names = "enet_csr", "ring_csr", "ring_cmd";
 			interrupts = <0x0 0x60 0x4>,
-				     <0x0 0x61 0x4>;
+				     <0x0 0x61 0x4>,
+				     <0x0 0x62 0x4>,
+				     <0x0 0x63 0x4>,
+				     <0x0 0x64 0x4>,
+				     <0x0 0x65 0x4>,
+				     <0x0 0x66 0x4>,
+				     <0x0 0x67 0x4>;
 			dma-coherent;
 			clocks = <&xge0clk 0>;
 			/* mac address will be overwritten by the bootloader */
-- 
1.9.1



From isubramanian at apm.com  Wed Feb 17 15:00:40 2016
From: isubramanian at apm.com (Iyappan Subramanian)
Date: Wed, 17 Feb 2016 15:00:40 -0800
Subject: [PATCH net-next v3 2/4] drivers: net: xgene: Add support for RSS
In-Reply-To: <1455750042-1521-1-git-send-email-isubramanian@apm.com>
References: <1455750042-1521-1-git-send-email-isubramanian@apm.com>
Message-ID: <1455750042-1521-3-git-send-email-isubramanian@apm.com>

Signed-off-by: Iyappan Subramanian <isubramanian at apm.com>
Signed-off-by: Khuong Dinh <kdinh at apm.com>
Signed-off-by: Tanmay Inamdar <tinamdar at apm.com>
Tested-by: Toan Le <toanle at apm.com>
---
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c | 386 +++++++++++++++++++++++-
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.h |  41 +++
 2 files changed, 422 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
index ff24ca9..c007497 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
@@ -21,6 +21,25 @@
 
 #include "xgene_enet_main.h"
 
+/* interfaces to convert structures to HW recognized bit formats */
+static void xgene_cle_sband_to_hw(u8 frag, enum xgene_cle_prot_version ver,
+				  enum xgene_cle_prot_type type, u32 len,
+				  u32 *reg)
+{
+	*reg =  SET_VAL(SB_IPFRAG, frag) |
+		SET_VAL(SB_IPPROT, type) |
+		SET_VAL(SB_IPVER, ver) |
+		SET_VAL(SB_HDRLEN, len);
+}
+
+static void xgene_cle_idt_to_hw(u32 dstqid, u32 fpsel,
+				u32 nfpsel, u32 *idt_reg)
+{
+	*idt_reg =  SET_VAL(IDT_DSTQID, dstqid) |
+		    SET_VAL(IDT_FPSEL, fpsel) |
+		    SET_VAL(IDT_NFPSEL, nfpsel);
+}
+
 static void xgene_cle_dbptr_to_hw(struct xgene_enet_pdata *pdata,
 				  struct xgene_cle_dbptr *dbptr, u32 *buf)
 {
@@ -257,29 +276,372 @@ static void xgene_cle_setup_def_dbptr(struct xgene_enet_pdata *pdata,
 	}
 }
 
+static int xgene_cle_set_rss_sband(struct xgene_enet_cle *cle)
+{
+	u32 idx = CLE_PKTRAM_SIZE / sizeof(u32);
+	u32 mac_hdr_len = ETH_HLEN;
+	u32 sband, reg = 0;
+	u32 ipv4_ihl = 5;
+	u32 hdr_len;
+	int ret;
+
+	/* Sideband: IPV4/TCP packets */
+	hdr_len = (mac_hdr_len << 5) | ipv4_ihl;
+	xgene_cle_sband_to_hw(0, XGENE_CLE_IPV4, XGENE_CLE_TCP, hdr_len, &reg);
+	sband = reg;
+
+	/* Sideband: IPv4/UDP packets */
+	hdr_len = (mac_hdr_len << 5) | ipv4_ihl;
+	xgene_cle_sband_to_hw(1, XGENE_CLE_IPV4, XGENE_CLE_UDP, hdr_len, &reg);
+	sband |= (reg << 16);
+
+	ret = xgene_cle_dram_wr(cle, &sband, 1, idx, PKT_RAM, CLE_CMD_WR);
+	if (ret)
+		return ret;
+
+	/* Sideband: IPv4/RAW packets */
+	hdr_len = (mac_hdr_len << 5) | ipv4_ihl;
+	xgene_cle_sband_to_hw(0, XGENE_CLE_IPV4, XGENE_CLE_OTHER,
+			      hdr_len, &reg);
+	sband = reg;
+
+	/* Sideband: Ethernet II/RAW packets */
+	hdr_len = (mac_hdr_len << 5);
+	xgene_cle_sband_to_hw(0, XGENE_CLE_IPV4, XGENE_CLE_OTHER,
+			      hdr_len, &reg);
+	sband |= (reg << 16);
+
+	ret = xgene_cle_dram_wr(cle, &sband, 1, idx + 1, PKT_RAM, CLE_CMD_WR);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int xgene_cle_set_rss_skeys(struct xgene_enet_cle *cle)
+{
+	u32 secret_key_ipv4[4];  /* 16 Bytes*/
+	int ret = 0;
+
+	get_random_bytes(secret_key_ipv4, 16);
+	ret = xgene_cle_dram_wr(cle, secret_key_ipv4, 4, 0,
+				RSS_IPV4_HASH_SKEY, CLE_CMD_WR);
+	return ret;
+}
+
+static int xgene_cle_set_rss_idt(struct xgene_enet_pdata *pdata)
+{
+	u32 fpsel, dstqid, nfpsel, idt_reg;
+	int i, ret = 0;
+	u16 pool_id;
+
+	for (i = 0; i < XGENE_CLE_IDT_ENTRIES; i++) {
+		pool_id = pdata->rx_ring->buf_pool->id;
+		fpsel = xgene_enet_ring_bufnum(pool_id) - 0x20;
+		dstqid = xgene_enet_dst_ring_num(pdata->rx_ring);
+		nfpsel = 0;
+		idt_reg = 0;
+
+		xgene_cle_idt_to_hw(dstqid, fpsel, nfpsel, &idt_reg);
+		ret = xgene_cle_dram_wr(&pdata->cle, &idt_reg, 1, i,
+					RSS_IDT, CLE_CMD_WR);
+		if (ret)
+			return ret;
+	}
+
+	ret = xgene_cle_set_rss_skeys(&pdata->cle);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static int xgene_cle_setup_rss(struct xgene_enet_pdata *pdata)
+{
+	struct xgene_enet_cle *cle = &pdata->cle;
+	void __iomem *base = cle->base;
+	u32 offset, val = 0;
+	int i, ret = 0;
+
+	offset = CLE_PORT_OFFSET;
+	for (i = 0; i < cle->parsers; i++) {
+		if (cle->active_parser != PARSER_ALL)
+			offset = cle->active_parser * CLE_PORT_OFFSET;
+		else
+			offset = i * CLE_PORT_OFFSET;
+
+		/* enable RSS */
+		val = (RSS_IPV4_12B << 1) | 0x1;
+		writel(val, base + RSS_CTRL0 + offset);
+	}
+
+	/* setup sideband data */
+	ret = xgene_cle_set_rss_sband(cle);
+	if (ret)
+		return ret;
+
+	/* setup indirection table */
+	ret = xgene_cle_set_rss_idt(pdata);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
 static int xgene_enet_cle_init(struct xgene_enet_pdata *pdata)
 {
 	struct xgene_enet_cle *enet_cle = &pdata->cle;
 	struct xgene_cle_dbptr dbptr[DB_MAX_PTRS];
+	struct xgene_cle_ptree_branch *br;
 	u32 def_qid, def_fpsel, pool_id;
 	struct xgene_cle_ptree *ptree;
 	struct xgene_cle_ptree_kn kn;
+	int ret;
 	struct xgene_cle_ptree_ewdn ptree_dn[] = {
 		{
 			/* PKT_TYPE_NODE */
 			.node_type = EWDN,
 			.last_node = 0,
-			.hdr_len_store = 0,
+			.hdr_len_store = 1,
 			.hdr_extn = NO_BYTE,
 			.byte_store = NO_BYTE,
 			.search_byte_store = NO_BYTE,
 			.result_pointer = DB_RES_DROP,
-			.num_branches = 1,
+			.num_branches = 2,
 			.branch = {
 				{
-					/* Allow all packet type */
+					/* IPV4 */
 					.valid = 0,
-					.next_packet_pointer = 0,
+					.next_packet_pointer = 22,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = PKT_PROT_NODE,
+					.next_branch = 0,
+					.data = 0x8,
+					.mask = 0xffff
+				},
+				{
+					.valid = 0,
+					.next_packet_pointer = 262,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = LAST_NODE,
+					.next_branch = 0,
+					.data = 0x0,
+					.mask = 0xffff
+				}
+			},
+		},
+		{
+			/* PKT_PROT_NODE */
+			.node_type = EWDN,
+			.last_node = 0,
+			.hdr_len_store = 1,
+			.hdr_extn = NO_BYTE,
+			.byte_store = NO_BYTE,
+			.search_byte_store = NO_BYTE,
+			.result_pointer = DB_RES_DROP,
+			.num_branches = 3,
+			.branch = {
+				{
+					/* TCP */
+					.valid = 1,
+					.next_packet_pointer = 26,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 0,
+					.data = 0x0600,
+					.mask = 0xffff
+				},
+				{
+					/* UDP */
+					.valid = 1,
+					.next_packet_pointer = 26,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 0,
+					.data = 0x1100,
+					.mask = 0xffff
+				},
+				{
+					.valid = 0,
+					.next_packet_pointer = 260,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = LAST_NODE,
+					.next_branch = 0,
+					.data = 0x0,
+					.mask = 0xffff
+				}
+			}
+		},
+		{
+			/* RSS_IPV4_TCP_NODE */
+			.node_type = EWDN,
+			.last_node = 0,
+			.hdr_len_store = 1,
+			.hdr_extn = NO_BYTE,
+			.byte_store = NO_BYTE,
+			.search_byte_store = BOTH_BYTES,
+			.result_pointer = DB_RES_DROP,
+			.num_branches = 6,
+			.branch = {
+				{
+					/* SRC IPV4 B01 */
+					.valid = 0,
+					.next_packet_pointer = 28,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 1,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* SRC IPV4 B23 */
+					.valid = 0,
+					.next_packet_pointer = 30,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 2,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* DST IPV4 B01 */
+					.valid = 0,
+					.next_packet_pointer = 32,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 3,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* DST IPV4 B23 */
+					.valid = 0,
+					.next_packet_pointer = 34,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 4,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* TCP SRC Port */
+					.valid = 0,
+					.next_packet_pointer = 36,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_TCP_NODE,
+					.next_branch = 5,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* TCP DST Port */
+					.valid = 0,
+					.next_packet_pointer = 256,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = LAST_NODE,
+					.next_branch = 0,
+					.data = 0x0,
+					.mask = 0xffff
+				}
+			}
+		},
+		{
+			/* RSS_IPV4_UDP_NODE */
+			.node_type = EWDN,
+			.last_node = 0,
+			.hdr_len_store = 1,
+			.hdr_extn = NO_BYTE,
+			.byte_store = NO_BYTE,
+			.search_byte_store = BOTH_BYTES,
+			.result_pointer = DB_RES_DROP,
+			.num_branches = 6,
+			.branch = {
+				{
+					/* SRC IPV4 B01 */
+					.valid = 0,
+					.next_packet_pointer = 28,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 1,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* SRC IPV4 B23 */
+					.valid = 0,
+					.next_packet_pointer = 30,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 2,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* DST IPV4 B01 */
+					.valid = 0,
+					.next_packet_pointer = 32,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 3,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* DST IPV4 B23 */
+					.valid = 0,
+					.next_packet_pointer = 34,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 4,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* TCP SRC Port */
+					.valid = 0,
+					.next_packet_pointer = 36,
+					.jump_bw = JMP_FW,
+					.jump_rel = JMP_ABS,
+					.operation = EQT,
+					.next_node = RSS_IPV4_UDP_NODE,
+					.next_branch = 5,
+					.data = 0x0,
+					.mask = 0xffff
+				},
+				{
+					/* TCP DST Port */
+					.valid = 0,
+					.next_packet_pointer = 256,
 					.jump_bw = JMP_FW,
 					.jump_rel = JMP_ABS,
 					.operation = EQT,
@@ -294,7 +656,7 @@ static int xgene_enet_cle_init(struct xgene_enet_pdata *pdata)
 			/* LAST NODE */
 			.node_type = EWDN,
 			.last_node = 1,
-			.hdr_len_store = 0,
+			.hdr_len_store = 1,
 			.hdr_extn = NO_BYTE,
 			.byte_store = NO_BYTE,
 			.search_byte_store = NO_BYTE,
@@ -318,6 +680,20 @@ static int xgene_enet_cle_init(struct xgene_enet_pdata *pdata)
 
 	ptree = &enet_cle->ptree;
 	ptree->start_pkt = 12; /* Ethertype */
+	if (pdata->phy_mode == PHY_INTERFACE_MODE_XGMII) {
+		ret = xgene_cle_setup_rss(pdata);
+		if (ret) {
+			netdev_err(pdata->ndev, "RSS initialization failed\n");
+			return ret;
+		}
+	} else {
+		br = &ptree_dn[PKT_PROT_NODE].branch[0];
+		br->valid = 0;
+		br->next_packet_pointer = 260;
+		br->next_node = LAST_NODE;
+		br->data = 0x0000;
+		br->mask = 0xffff;
+	}
 
 	def_qid = xgene_enet_dst_ring_num(pdata->rx_ring);
 	pool_id = pdata->rx_ring->buf_pool->id;
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h
index 1db2fd7..29a17ab 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.h
@@ -34,6 +34,7 @@
 #define SPPTR0			0x0104
 #define DFCLSRESDBPTR0		0x0108
 #define DFCLSRESDB00		0x010c
+#define RSS_CTRL0		0x0000013c
 
 #define CLE_CMD_TO		10	/* ms */
 #define CLE_PKTRAM_SIZE		256	/* bytes */
@@ -98,6 +99,9 @@
 
 enum xgene_cle_ptree_nodes {
 	PKT_TYPE_NODE,
+	PKT_PROT_NODE,
+	RSS_IPV4_TCP_NODE,
+	RSS_IPV4_UDP_NODE,
 	LAST_NODE,
 	MAX_NODES
 };
@@ -137,6 +141,8 @@ enum xgene_cle_parser {
 #define XGENE_CLE_DRAM(type)	(((type) & 0xf) << 28)
 enum xgene_cle_dram_type {
 	PKT_RAM,
+	RSS_IDT,
+	RSS_IPV4_HASH_SKEY,
 	PTREE_RAM = 0xc,
 	AVL_RAM,
 	DB_RAM
@@ -150,6 +156,22 @@ enum xgene_cle_cmd_type {
 	CLE_CMD_AVL_SRCH = 32
 };
 
+enum xgene_cle_ipv4_rss_hashtype {
+	RSS_IPV4_8B,
+	RSS_IPV4_12B,
+};
+
+enum xgene_cle_prot_type {
+	XGENE_CLE_TCP,
+	XGENE_CLE_UDP,
+	XGENE_CLE_ESP,
+	XGENE_CLE_OTHER
+};
+
+enum xgene_cle_prot_version {
+	XGENE_CLE_IPV4,
+};
+
 enum xgene_cle_ptree_dbptrs {
 	DB_RES_DROP,
 	DB_RES_DEF,
@@ -157,6 +179,25 @@ enum xgene_cle_ptree_dbptrs {
 	DB_MAX_PTRS
 };
 
+/* RSS sideband signal info */
+#define SB_IPFRAG_POS	0
+#define SB_IPFRAG_LEN	1
+#define SB_IPPROT_POS	1
+#define SB_IPPROT_LEN	2
+#define SB_IPVER_POS	3
+#define SB_IPVER_LEN	1
+#define SB_HDRLEN_POS	4
+#define SB_HDRLEN_LEN	12
+
+/* RSS indirection table */
+#define XGENE_CLE_IDT_ENTRIES	128
+#define IDT_DSTQID_POS		0
+#define IDT_DSTQID_LEN		12
+#define IDT_FPSEL_POS		12
+#define IDT_FPSEL_LEN		4
+#define IDT_NFPSEL_POS		16
+#define IDT_NFPSEL_LEN		4
+
 struct xgene_cle_ptree_branch {
 	bool valid;
 	u16 next_packet_pointer;
-- 
1.9.1



From isubramanian at apm.com  Wed Feb 17 15:00:41 2016
From: isubramanian at apm.com (Iyappan Subramanian)
Date: Wed, 17 Feb 2016 15:00:41 -0800
Subject: [PATCH net-next v3 3/4] drivers: net: xgene: Add support for multiple
 queues
In-Reply-To: <1455750042-1521-1-git-send-email-isubramanian@apm.com>
References: <1455750042-1521-1-git-send-email-isubramanian@apm.com>
Message-ID: <1455750042-1521-4-git-send-email-isubramanian@apm.com>

Signed-off-by: Iyappan Subramanian <isubramanian at apm.com>
Signed-off-by: Khuong Dinh <kdinh at apm.com>
Signed-off-by: Tanmay Inamdar <tinamdar at apm.com>
Tested-by: Toan Le <toanle at apm.com>
---
 drivers/net/ethernet/apm/xgene/xgene_enet_cle.c   |  11 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c    |  12 +
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h    |   5 +
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c  | 453 +++++++++++++---------
 drivers/net/ethernet/apm/xgene/xgene_enet_main.h  |  21 +-
 drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c |  12 +
 6 files changed, 320 insertions(+), 194 deletions(-)

diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
index c007497..b2124886 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_cle.c
@@ -331,14 +331,15 @@ static int xgene_cle_set_rss_skeys(struct xgene_enet_cle *cle)
 
 static int xgene_cle_set_rss_idt(struct xgene_enet_pdata *pdata)
 {
-	u32 fpsel, dstqid, nfpsel, idt_reg;
+	u32 fpsel, dstqid, nfpsel, idt_reg, idx;
 	int i, ret = 0;
 	u16 pool_id;
 
 	for (i = 0; i < XGENE_CLE_IDT_ENTRIES; i++) {
-		pool_id = pdata->rx_ring->buf_pool->id;
+		idx = i % pdata->rxq_cnt;
+		pool_id = pdata->rx_ring[idx]->buf_pool->id;
 		fpsel = xgene_enet_ring_bufnum(pool_id) - 0x20;
-		dstqid = xgene_enet_dst_ring_num(pdata->rx_ring);
+		dstqid = xgene_enet_dst_ring_num(pdata->rx_ring[idx]);
 		nfpsel = 0;
 		idt_reg = 0;
 
@@ -695,8 +696,8 @@ static int xgene_enet_cle_init(struct xgene_enet_pdata *pdata)
 		br->mask = 0xffff;
 	}
 
-	def_qid = xgene_enet_dst_ring_num(pdata->rx_ring);
-	pool_id = pdata->rx_ring->buf_pool->id;
+	def_qid = xgene_enet_dst_ring_num(pdata->rx_ring[0]);
+	pool_id = pdata->rx_ring[0]->buf_pool->id;
 	def_fpsel = xgene_enet_ring_bufnum(pool_id) - 0x20;
 
 	memset(dbptr, 0, sizeof(struct xgene_cle_dbptr) * DB_MAX_PTRS);
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
index db55c9f..39e081a 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
@@ -204,6 +204,17 @@ static u32 xgene_enet_ring_len(struct xgene_enet_desc_ring *ring)
 	return num_msgs;
 }
 
+static void xgene_enet_setup_coalescing(struct xgene_enet_desc_ring *ring)
+{
+	u32 data = 0x7777;
+
+	xgene_enet_ring_wr32(ring, CSR_PBM_COAL, 0x8e);
+	xgene_enet_ring_wr32(ring, CSR_PBM_CTICK1, data);
+	xgene_enet_ring_wr32(ring, CSR_PBM_CTICK2, data << 16);
+	xgene_enet_ring_wr32(ring, CSR_THRESHOLD0_SET1, 0x40);
+	xgene_enet_ring_wr32(ring, CSR_THRESHOLD1_SET1, 0x80);
+}
+
 void xgene_enet_parse_error(struct xgene_enet_desc_ring *ring,
 			    struct xgene_enet_pdata *pdata,
 			    enum xgene_enet_err_code status)
@@ -892,4 +903,5 @@ struct xgene_ring_ops xgene_ring1_ops = {
 	.clear = xgene_enet_clear_ring,
 	.wr_cmd = xgene_enet_wr_cmd,
 	.len = xgene_enet_ring_len,
+	.coalesce = xgene_enet_setup_coalescing,
 };
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
index 45725ec..ba7da98 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
@@ -54,6 +54,11 @@ enum xgene_enet_rm {
 #define IS_BUFFER_POOL		BIT(20)
 #define PREFETCH_BUF_EN		BIT(21)
 #define CSR_RING_ID_BUF		0x000c
+#define CSR_PBM_COAL		0x0014
+#define CSR_PBM_CTICK1		0x001c
+#define CSR_PBM_CTICK2		0x0020
+#define CSR_THRESHOLD0_SET1	0x0030
+#define CSR_THRESHOLD1_SET1	0x0034
 #define CSR_RING_NE_INT_MODE	0x017c
 #define CSR_RING_CONFIG		0x006c
 #define CSR_RING_WR_BASE	0x0070
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
index 0bf3924..8d4c1ad 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
@@ -182,7 +182,6 @@ static int xgene_enet_tx_completion(struct xgene_enet_desc_ring *cp_ring,
 static u64 xgene_enet_work_msg(struct sk_buff *skb)
 {
 	struct net_device *ndev = skb->dev;
-	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 	struct iphdr *iph;
 	u8 l3hlen = 0, l4hlen = 0;
 	u8 ethhdr, proto = 0, csum_enable = 0;
@@ -228,10 +227,6 @@ static u64 xgene_enet_work_msg(struct sk_buff *skb)
 			if (!mss || ((skb->len - hdr_len) <= mss))
 				goto out;
 
-			if (mss != pdata->mss) {
-				pdata->mss = mss;
-				pdata->mac_ops->set_mss(pdata);
-			}
 			hopinfo |= SET_BIT(ET);
 		}
 	} else if (iph->protocol == IPPROTO_UDP) {
@@ -413,7 +408,7 @@ out:
 	raw_desc->m0 = cpu_to_le64(SET_VAL(LL, ll) | SET_VAL(NV, nv) |
 				   SET_VAL(USERINFO, tx_ring->tail));
 	tx_ring->cp_ring->cp_skb[tx_ring->tail] = skb;
-	pdata->tx_level += count;
+	pdata->tx_level[tx_ring->cp_ring->index] += count;
 	tx_ring->tail = tail;
 
 	return count;
@@ -423,15 +418,17 @@ static netdev_tx_t xgene_enet_start_xmit(struct sk_buff *skb,
 					 struct net_device *ndev)
 {
 	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
-	struct xgene_enet_desc_ring *tx_ring = pdata->tx_ring;
-	u32 tx_level = pdata->tx_level;
+	struct xgene_enet_desc_ring *tx_ring;
+	int index = skb->queue_mapping;
+	u32 tx_level = pdata->tx_level[index];
 	int count;
 
-	if (tx_level < pdata->txc_level)
-		tx_level += ((typeof(pdata->tx_level))~0U);
+	tx_ring = pdata->tx_ring[index];
+	if (tx_level < pdata->txc_level[index])
+		tx_level += ((typeof(pdata->tx_level[index]))~0U);
 
-	if ((tx_level - pdata->txc_level) > pdata->tx_qcnt_hi) {
-		netif_stop_queue(ndev);
+	if ((tx_level - pdata->txc_level[index]) > pdata->tx_qcnt_hi) {
+		netif_stop_subqueue(ndev, index);
 		return NETDEV_TX_BUSY;
 	}
 
@@ -529,7 +526,8 @@ static bool is_rx_desc(struct xgene_enet_raw_desc *raw_desc)
 static int xgene_enet_process_ring(struct xgene_enet_desc_ring *ring,
 				   int budget)
 {
-	struct xgene_enet_pdata *pdata = netdev_priv(ring->ndev);
+	struct net_device *ndev = ring->ndev;
+	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 	struct xgene_enet_raw_desc *raw_desc, *exp_desc;
 	u16 head = ring->head;
 	u16 slots = ring->slots - 1;
@@ -573,7 +571,7 @@ static int xgene_enet_process_ring(struct xgene_enet_desc_ring *ring,
 		desc_count++;
 		processed++;
 		if (is_completion)
-			pdata->txc_level += desc_count;
+			pdata->txc_level[ring->index] += desc_count;
 
 		if (ret)
 			break;
@@ -583,8 +581,8 @@ static int xgene_enet_process_ring(struct xgene_enet_desc_ring *ring,
 		pdata->ring_ops->wr_cmd(ring, -count);
 		ring->head = head;
 
-		if (netif_queue_stopped(ring->ndev))
-			netif_start_queue(ring->ndev);
+		if (__netif_subqueue_stopped(ndev, ring->index))
+			netif_start_subqueue(ndev, ring->index);
 	}
 
 	return processed;
@@ -609,8 +607,16 @@ static int xgene_enet_napi(struct napi_struct *napi, const int budget)
 static void xgene_enet_timeout(struct net_device *ndev)
 {
 	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
+	struct netdev_queue *txq;
+	int i;
 
 	pdata->mac_ops->reset(pdata);
+
+	for (i = 0; i < pdata->txq_cnt; i++) {
+		txq = netdev_get_tx_queue(ndev, i);
+		txq->trans_start = jiffies;
+		netif_tx_start_queue(txq);
+	}
 }
 
 static int xgene_enet_register_irq(struct net_device *ndev)
@@ -618,17 +624,21 @@ static int xgene_enet_register_irq(struct net_device *ndev)
 	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 	struct device *dev = ndev_to_dev(ndev);
 	struct xgene_enet_desc_ring *ring;
-	int ret;
+	int ret = 0, i;
 
-	ring = pdata->rx_ring;
-	irq_set_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
-	ret = devm_request_irq(dev, ring->irq, xgene_enet_rx_irq,
-			       IRQF_SHARED, ring->irq_name, ring);
-	if (ret)
-		netdev_err(ndev, "Failed to request irq %s\n", ring->irq_name);
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		ring = pdata->rx_ring[i];
+		irq_set_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
+		ret = devm_request_irq(dev, ring->irq, xgene_enet_rx_irq,
+				       IRQF_SHARED, ring->irq_name, ring);
+		if (ret) {
+			netdev_err(ndev, "Failed to request irq %s\n",
+				   ring->irq_name);
+		}
+	}
 
-	if (pdata->cq_cnt) {
-		ring = pdata->tx_ring->cp_ring;
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		ring = pdata->tx_ring[i]->cp_ring;
 		irq_set_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
 		ret = devm_request_irq(dev, ring->irq, xgene_enet_rx_irq,
 				       IRQF_SHARED, ring->irq_name, ring);
@@ -646,15 +656,19 @@ static void xgene_enet_free_irq(struct net_device *ndev)
 	struct xgene_enet_pdata *pdata;
 	struct xgene_enet_desc_ring *ring;
 	struct device *dev;
+	int i;
 
 	pdata = netdev_priv(ndev);
 	dev = ndev_to_dev(ndev);
-	ring = pdata->rx_ring;
-	irq_clear_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
-	devm_free_irq(dev, ring->irq, ring);
 
-	if (pdata->cq_cnt) {
-		ring = pdata->tx_ring->cp_ring;
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		ring = pdata->rx_ring[i];
+		irq_clear_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
+		devm_free_irq(dev, ring->irq, ring);
+	}
+
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		ring = pdata->tx_ring[i]->cp_ring;
 		irq_clear_status_flags(ring->irq, IRQ_DISABLE_UNLAZY);
 		devm_free_irq(dev, ring->irq, ring);
 	}
@@ -663,12 +677,15 @@ static void xgene_enet_free_irq(struct net_device *ndev)
 static void xgene_enet_napi_enable(struct xgene_enet_pdata *pdata)
 {
 	struct napi_struct *napi;
+	int i;
 
-	napi = &pdata->rx_ring->napi;
-	napi_enable(napi);
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		napi = &pdata->rx_ring[i]->napi;
+		napi_enable(napi);
+	}
 
-	if (pdata->cq_cnt) {
-		napi = &pdata->tx_ring->cp_ring->napi;
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		napi = &pdata->tx_ring[i]->cp_ring->napi;
 		napi_enable(napi);
 	}
 }
@@ -676,12 +693,15 @@ static void xgene_enet_napi_enable(struct xgene_enet_pdata *pdata)
 static void xgene_enet_napi_disable(struct xgene_enet_pdata *pdata)
 {
 	struct napi_struct *napi;
+	int i;
 
-	napi = &pdata->rx_ring->napi;
-	napi_disable(napi);
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		napi = &pdata->rx_ring[i]->napi;
+		napi_disable(napi);
+	}
 
-	if (pdata->cq_cnt) {
-		napi = &pdata->tx_ring->cp_ring->napi;
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		napi = &pdata->tx_ring[i]->cp_ring->napi;
 		napi_disable(napi);
 	}
 }
@@ -692,6 +712,14 @@ static int xgene_enet_open(struct net_device *ndev)
 	const struct xgene_mac_ops *mac_ops = pdata->mac_ops;
 	int ret;
 
+	ret = netif_set_real_num_tx_queues(ndev, pdata->txq_cnt);
+	if (ret)
+		return ret;
+
+	ret = netif_set_real_num_rx_queues(ndev, pdata->rxq_cnt);
+	if (ret)
+		return ret;
+
 	mac_ops->tx_enable(pdata);
 	mac_ops->rx_enable(pdata);
 
@@ -714,6 +742,7 @@ static int xgene_enet_close(struct net_device *ndev)
 {
 	struct xgene_enet_pdata *pdata = netdev_priv(ndev);
 	const struct xgene_mac_ops *mac_ops = pdata->mac_ops;
+	int i;
 
 	netif_stop_queue(ndev);
 
@@ -727,7 +756,8 @@ static int xgene_enet_close(struct net_device *ndev)
 
 	xgene_enet_free_irq(ndev);
 	xgene_enet_napi_disable(pdata);
-	xgene_enet_process_ring(pdata->rx_ring, -1);
+	for (i = 0; i < pdata->rxq_cnt; i++)
+		xgene_enet_process_ring(pdata->rx_ring[i], -1);
 
 	return 0;
 }
@@ -747,18 +777,26 @@ static void xgene_enet_delete_ring(struct xgene_enet_desc_ring *ring)
 static void xgene_enet_delete_desc_rings(struct xgene_enet_pdata *pdata)
 {
 	struct xgene_enet_desc_ring *buf_pool;
+	struct xgene_enet_desc_ring *ring;
+	int i;
 
-	if (pdata->tx_ring) {
-		xgene_enet_delete_ring(pdata->tx_ring);
-		pdata->tx_ring = NULL;
+	for (i = 0; i < pdata->txq_cnt; i++) {
+		ring = pdata->tx_ring[i];
+		if (ring) {
+			xgene_enet_delete_ring(ring);
+			pdata->tx_ring[i] = NULL;
+		}
 	}
 
-	if (pdata->rx_ring) {
-		buf_pool = pdata->rx_ring->buf_pool;
-		xgene_enet_delete_bufpool(buf_pool);
-		xgene_enet_delete_ring(buf_pool);
-		xgene_enet_delete_ring(pdata->rx_ring);
-		pdata->rx_ring = NULL;
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		ring = pdata->rx_ring[i];
+		if (ring) {
+			buf_pool = ring->buf_pool;
+			xgene_enet_delete_bufpool(buf_pool);
+			xgene_enet_delete_ring(buf_pool);
+			xgene_enet_delete_ring(ring);
+			pdata->rx_ring[i] = NULL;
+		}
 	}
 }
 
@@ -813,24 +851,29 @@ static void xgene_enet_free_desc_rings(struct xgene_enet_pdata *pdata)
 {
 	struct device *dev = &pdata->pdev->dev;
 	struct xgene_enet_desc_ring *ring;
+	int i;
 
-	ring = pdata->tx_ring;
-	if (ring) {
-		if (ring->cp_ring && ring->cp_ring->cp_skb)
-			devm_kfree(dev, ring->cp_ring->cp_skb);
-		if (ring->cp_ring && pdata->cq_cnt)
-			xgene_enet_free_desc_ring(ring->cp_ring);
-		xgene_enet_free_desc_ring(ring);
-	}
-
-	ring = pdata->rx_ring;
-	if (ring) {
-		if (ring->buf_pool) {
-			if (ring->buf_pool->rx_skb)
-				devm_kfree(dev, ring->buf_pool->rx_skb);
-			xgene_enet_free_desc_ring(ring->buf_pool);
+	for (i = 0; i < pdata->txq_cnt; i++) {
+		ring = pdata->tx_ring[i];
+		if (ring) {
+			if (ring->cp_ring && ring->cp_ring->cp_skb)
+				devm_kfree(dev, ring->cp_ring->cp_skb);
+			if (ring->cp_ring && pdata->cq_cnt)
+				xgene_enet_free_desc_ring(ring->cp_ring);
+			xgene_enet_free_desc_ring(ring);
+		}
+	}
+
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		ring = pdata->rx_ring[i];
+		if (ring) {
+			if (ring->buf_pool) {
+				if (ring->buf_pool->rx_skb)
+					devm_kfree(dev, ring->buf_pool->rx_skb);
+				xgene_enet_free_desc_ring(ring->buf_pool);
+			}
+			xgene_enet_free_desc_ring(ring);
 		}
-		xgene_enet_free_desc_ring(ring);
 	}
 }
 
@@ -943,104 +986,120 @@ static int xgene_enet_create_desc_rings(struct net_device *ndev)
 	u8 bp_bufnum = pdata->bp_bufnum;
 	u16 ring_num = pdata->ring_num;
 	u16 ring_id;
-	int ret, size;
-
-	/* allocate rx descriptor ring */
-	owner = xgene_derive_ring_owner(pdata);
-	ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU, cpu_bufnum++);
-	rx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
-					      RING_CFGSIZE_16KB, ring_id);
-	if (!rx_ring) {
-		ret = -ENOMEM;
-		goto err;
-	}
-
-	/* allocate buffer pool for receiving packets */
-	owner = xgene_derive_ring_owner(pdata);
-	ring_id = xgene_enet_get_ring_id(owner, bp_bufnum++);
-	buf_pool = xgene_enet_create_desc_ring(ndev, ring_num++,
-					       RING_CFGSIZE_2KB, ring_id);
-	if (!buf_pool) {
-		ret = -ENOMEM;
-		goto err;
-	}
+	int i, ret, size;
 
-	rx_ring->nbufpool = NUM_BUFPOOL;
-	rx_ring->buf_pool = buf_pool;
-	rx_ring->irq = pdata->rx_irq;
-	if (!pdata->cq_cnt) {
-		snprintf(rx_ring->irq_name, IRQ_ID_SIZE, "%s-rx-txc",
-			 ndev->name);
-	} else {
-		snprintf(rx_ring->irq_name, IRQ_ID_SIZE, "%s-rx", ndev->name);
-	}
-	buf_pool->rx_skb = devm_kcalloc(dev, buf_pool->slots,
-					sizeof(struct sk_buff *), GFP_KERNEL);
-	if (!buf_pool->rx_skb) {
-		ret = -ENOMEM;
-		goto err;
-	}
-
-	buf_pool->dst_ring_num = xgene_enet_dst_ring_num(buf_pool);
-	rx_ring->buf_pool = buf_pool;
-	pdata->rx_ring = rx_ring;
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		/* allocate rx descriptor ring */
+		owner = xgene_derive_ring_owner(pdata);
+		ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU, cpu_bufnum++);
+		rx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
+						      RING_CFGSIZE_16KB,
+						      ring_id);
+		if (!rx_ring) {
+			ret = -ENOMEM;
+			goto err;
+		}
 
-	/* allocate tx descriptor ring */
-	owner = xgene_derive_ring_owner(pdata);
-	ring_id = xgene_enet_get_ring_id(owner, eth_bufnum++);
-	tx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
-					      RING_CFGSIZE_16KB, ring_id);
-	if (!tx_ring) {
-		ret = -ENOMEM;
-		goto err;
-	}
+		/* allocate buffer pool for receiving packets */
+		owner = xgene_derive_ring_owner(pdata);
+		ring_id = xgene_enet_get_ring_id(owner, bp_bufnum++);
+		buf_pool = xgene_enet_create_desc_ring(ndev, ring_num++,
+						       RING_CFGSIZE_2KB,
+						       ring_id);
+		if (!buf_pool) {
+			ret = -ENOMEM;
+			goto err;
+		}
 
-	size = (tx_ring->slots / 2) * sizeof(__le64) * MAX_EXP_BUFFS;
-	tx_ring->exp_bufs = dma_zalloc_coherent(dev, size, &dma_exp_bufs,
+		rx_ring->nbufpool = NUM_BUFPOOL;
+		rx_ring->buf_pool = buf_pool;
+		rx_ring->irq = pdata->irqs[i];
+		if (!pdata->cq_cnt) {
+			snprintf(rx_ring->irq_name, IRQ_ID_SIZE, "%s-rx-txc",
+				 ndev->name);
+		} else {
+			snprintf(rx_ring->irq_name, IRQ_ID_SIZE, "%s-rx%d",
+				 ndev->name, i);
+		}
+		buf_pool->rx_skb = devm_kcalloc(dev, buf_pool->slots,
+						sizeof(struct sk_buff *),
 						GFP_KERNEL);
-	if (!tx_ring->exp_bufs) {
-		ret = -ENOMEM;
-		goto err;
-	}
+		if (!buf_pool->rx_skb) {
+			ret = -ENOMEM;
+			goto err;
+		}
 
-	pdata->tx_ring = tx_ring;
+		buf_pool->dst_ring_num = xgene_enet_dst_ring_num(buf_pool);
+		rx_ring->buf_pool = buf_pool;
+		pdata->rx_ring[i] = rx_ring;
+	}
 
-	if (!pdata->cq_cnt) {
-		cp_ring = pdata->rx_ring;
-	} else {
-		/* allocate tx completion descriptor ring */
-		ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU, cpu_bufnum++);
-		cp_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
+	for (i = 0; i < pdata->txq_cnt; i++) {
+		/* allocate tx descriptor ring */
+		owner = xgene_derive_ring_owner(pdata);
+		ring_id = xgene_enet_get_ring_id(owner, eth_bufnum++);
+		tx_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
 						      RING_CFGSIZE_16KB,
 						      ring_id);
-		if (!cp_ring) {
+		if (!tx_ring) {
 			ret = -ENOMEM;
 			goto err;
 		}
-		cp_ring->irq = pdata->txc_irq;
-		snprintf(cp_ring->irq_name, IRQ_ID_SIZE, "%s-txc", ndev->name);
-	}
 
-	cp_ring->cp_skb = devm_kcalloc(dev, tx_ring->slots,
-				       sizeof(struct sk_buff *), GFP_KERNEL);
-	if (!cp_ring->cp_skb) {
-		ret = -ENOMEM;
-		goto err;
-	}
+		size = (tx_ring->slots / 2) * sizeof(__le64) * MAX_EXP_BUFFS;
+		tx_ring->exp_bufs = dma_zalloc_coherent(dev, size,
+							&dma_exp_bufs,
+							GFP_KERNEL);
+		if (!tx_ring->exp_bufs) {
+			ret = -ENOMEM;
+			goto err;
+		}
 
-	size = sizeof(dma_addr_t) * MAX_SKB_FRAGS;
-	cp_ring->frag_dma_addr = devm_kcalloc(dev, tx_ring->slots,
-					      size, GFP_KERNEL);
-	if (!cp_ring->frag_dma_addr) {
-		devm_kfree(dev, cp_ring->cp_skb);
-		ret = -ENOMEM;
-		goto err;
-	}
+		pdata->tx_ring[i] = tx_ring;
 
-	pdata->tx_ring->cp_ring = cp_ring;
-	pdata->tx_ring->dst_ring_num = xgene_enet_dst_ring_num(cp_ring);
+		if (!pdata->cq_cnt) {
+			cp_ring = pdata->rx_ring[i];
+		} else {
+			/* allocate tx completion descriptor ring */
+			ring_id = xgene_enet_get_ring_id(RING_OWNER_CPU,
+							 cpu_bufnum++);
+			cp_ring = xgene_enet_create_desc_ring(ndev, ring_num++,
+							      RING_CFGSIZE_16KB,
+							      ring_id);
+			if (!cp_ring) {
+				ret = -ENOMEM;
+				goto err;
+			}
+
+			cp_ring->irq = pdata->irqs[pdata->rxq_cnt + i];
+			cp_ring->index = i;
+			snprintf(cp_ring->irq_name, IRQ_ID_SIZE, "%s-txc%d",
+				 ndev->name, i);
+		}
+
+		cp_ring->cp_skb = devm_kcalloc(dev, tx_ring->slots,
+					       sizeof(struct sk_buff *),
+					       GFP_KERNEL);
+		if (!cp_ring->cp_skb) {
+			ret = -ENOMEM;
+			goto err;
+		}
 
-	pdata->tx_qcnt_hi = pdata->tx_ring->slots - 128;
+		size = sizeof(dma_addr_t) * MAX_SKB_FRAGS;
+		cp_ring->frag_dma_addr = devm_kcalloc(dev, tx_ring->slots,
+						      size, GFP_KERNEL);
+		if (!cp_ring->frag_dma_addr) {
+			devm_kfree(dev, cp_ring->cp_skb);
+			ret = -ENOMEM;
+			goto err;
+		}
+
+		tx_ring->cp_ring = cp_ring;
+		tx_ring->dst_ring_num = xgene_enet_dst_ring_num(cp_ring);
+	}
+
+	pdata->ring_ops->coalesce(pdata->tx_ring[0]);
+	pdata->tx_qcnt_hi = pdata->tx_ring[0]->slots - 128;
 
 	return 0;
 
@@ -1159,6 +1218,32 @@ static int xgene_get_rx_delay(struct xgene_enet_pdata *pdata)
 	return 0;
 }
 
+static int xgene_enet_get_irqs(struct xgene_enet_pdata *pdata)
+{
+	struct platform_device *pdev = pdata->pdev;
+	struct device *dev = &pdev->dev;
+	int i, ret, max_irqs;
+
+	if (pdata->phy_mode == PHY_INTERFACE_MODE_RGMII)
+		max_irqs = 1;
+	else if (pdata->phy_mode == PHY_INTERFACE_MODE_SGMII)
+		max_irqs = 2;
+	else
+		max_irqs = XGENE_MAX_ENET_IRQ;
+
+	for (i = 0; i < max_irqs; i++) {
+		ret = platform_get_irq(pdev, i);
+		if (ret <= 0) {
+			dev_err(dev, "Unable to get ENET IRQ\n");
+			ret = ret ? : -ENXIO;
+			return ret;
+		}
+		pdata->irqs[i] = ret;
+	}
+
+	return 0;
+}
+
 static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
 {
 	struct platform_device *pdev;
@@ -1240,25 +1325,9 @@ static int xgene_enet_get_resources(struct xgene_enet_pdata *pdata)
 	if (ret)
 		return ret;
 
-	ret = platform_get_irq(pdev, 0);
-	if (ret <= 0) {
-		dev_err(dev, "Unable to get ENET Rx IRQ\n");
-		ret = ret ? : -ENXIO;
+	ret = xgene_enet_get_irqs(pdata);
+	if (ret)
 		return ret;
-	}
-	pdata->rx_irq = ret;
-
-	if (pdata->phy_mode != PHY_INTERFACE_MODE_RGMII) {
-		ret = platform_get_irq(pdev, 1);
-		if (ret <= 0) {
-			pdata->cq_cnt = 0;
-			dev_info(dev, "Unable to get Tx completion IRQ,"
-				 "using Rx IRQ instead\n");
-		} else {
-			pdata->cq_cnt = XGENE_MAX_TXC_RINGS;
-			pdata->txc_irq = ret;
-		}
-	}
 
 	pdata->clk = devm_clk_get(&pdev->dev, NULL);
 	if (IS_ERR(pdata->clk)) {
@@ -1296,7 +1365,7 @@ static int xgene_enet_init_hw(struct xgene_enet_pdata *pdata)
 	struct net_device *ndev = pdata->ndev;
 	struct xgene_enet_desc_ring *buf_pool;
 	u16 dst_ring_num;
-	int ret;
+	int i, ret;
 
 	ret = pdata->port_ops->reset(pdata);
 	if (ret)
@@ -1309,15 +1378,18 @@ static int xgene_enet_init_hw(struct xgene_enet_pdata *pdata)
 	}
 
 	/* setup buffer pool */
-	buf_pool = pdata->rx_ring->buf_pool;
-	xgene_enet_init_bufpool(buf_pool);
-	ret = xgene_enet_refill_bufpool(buf_pool, pdata->rx_buff_cnt);
-	if (ret) {
-		xgene_enet_delete_desc_rings(pdata);
-		return ret;
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		buf_pool = pdata->rx_ring[i]->buf_pool;
+		xgene_enet_init_bufpool(buf_pool);
+		ret = xgene_enet_refill_bufpool(buf_pool, pdata->rx_buff_cnt);
+		if (ret) {
+			xgene_enet_delete_desc_rings(pdata);
+			return ret;
+		}
 	}
 
-	dst_ring_num = xgene_enet_dst_ring_num(pdata->rx_ring);
+	dst_ring_num = xgene_enet_dst_ring_num(pdata->rx_ring[0]);
+	buf_pool = pdata->rx_ring[0]->buf_pool;
 	if (pdata->phy_mode == PHY_INTERFACE_MODE_XGMII) {
 		/* Initialize and Enable  PreClassifier Tree */
 		enet_cle->max_nodes = 512;
@@ -1348,17 +1420,26 @@ static void xgene_enet_setup_ops(struct xgene_enet_pdata *pdata)
 		pdata->mac_ops = &xgene_gmac_ops;
 		pdata->port_ops = &xgene_gport_ops;
 		pdata->rm = RM3;
+		pdata->rxq_cnt = 1;
+		pdata->txq_cnt = 1;
+		pdata->cq_cnt = 0;
 		break;
 	case PHY_INTERFACE_MODE_SGMII:
 		pdata->mac_ops = &xgene_sgmac_ops;
 		pdata->port_ops = &xgene_sgport_ops;
 		pdata->rm = RM1;
+		pdata->rxq_cnt = 1;
+		pdata->txq_cnt = 1;
+		pdata->cq_cnt = 1;
 		break;
 	default:
 		pdata->mac_ops = &xgene_xgmac_ops;
 		pdata->port_ops = &xgene_xgport_ops;
 		pdata->cle_ops = &xgene_cle3in_ops;
 		pdata->rm = RM0;
+		pdata->rxq_cnt = XGENE_NUM_RX_RING;
+		pdata->txq_cnt = XGENE_NUM_TX_RING;
+		pdata->cq_cnt = XGENE_NUM_TXC_RING;
 		break;
 	}
 
@@ -1412,12 +1493,16 @@ static void xgene_enet_setup_ops(struct xgene_enet_pdata *pdata)
 static void xgene_enet_napi_add(struct xgene_enet_pdata *pdata)
 {
 	struct napi_struct *napi;
+	int i;
 
-	napi = &pdata->rx_ring->napi;
-	netif_napi_add(pdata->ndev, napi, xgene_enet_napi, NAPI_POLL_WEIGHT);
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		napi = &pdata->rx_ring[i]->napi;
+		netif_napi_add(pdata->ndev, napi, xgene_enet_napi,
+			       NAPI_POLL_WEIGHT);
+	}
 
-	if (pdata->cq_cnt) {
-		napi = &pdata->tx_ring->cp_ring->napi;
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		napi = &pdata->tx_ring[i]->cp_ring->napi;
 		netif_napi_add(pdata->ndev, napi, xgene_enet_napi,
 			       NAPI_POLL_WEIGHT);
 	}
@@ -1426,12 +1511,15 @@ static void xgene_enet_napi_add(struct xgene_enet_pdata *pdata)
 static void xgene_enet_napi_del(struct xgene_enet_pdata *pdata)
 {
 	struct napi_struct *napi;
+	int i;
 
-	napi = &pdata->rx_ring->napi;
-	netif_napi_del(napi);
+	for (i = 0; i < pdata->rxq_cnt; i++) {
+		napi = &pdata->rx_ring[i]->napi;
+		netif_napi_del(napi);
+	}
 
-	if (pdata->cq_cnt) {
-		napi = &pdata->tx_ring->cp_ring->napi;
+	for (i = 0; i < pdata->cq_cnt; i++) {
+		napi = &pdata->tx_ring[i]->cp_ring->napi;
 		netif_napi_del(napi);
 	}
 }
@@ -1445,7 +1533,8 @@ static int xgene_enet_probe(struct platform_device *pdev)
 	const struct of_device_id *of_id;
 	int ret;
 
-	ndev = alloc_etherdev(sizeof(struct xgene_enet_pdata));
+	ndev = alloc_etherdev_mqs(sizeof(struct xgene_enet_pdata),
+				  XGENE_NUM_RX_RING, XGENE_NUM_TX_RING);
 	if (!ndev)
 		return -ENOMEM;
 
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
index 05365c1..175d188 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.h
@@ -49,6 +49,11 @@
 #define XGENE_ENET_MSS	1448
 #define XGENE_MIN_ENET_FRAME_SIZE	60
 
+#define XGENE_MAX_ENET_IRQ	8
+#define XGENE_NUM_RX_RING	4
+#define XGENE_NUM_TX_RING	4
+#define XGENE_NUM_TXC_RING	4
+
 #define START_CPU_BUFNUM_0	0
 #define START_ETH_BUFNUM_0	2
 #define START_BP_BUFNUM_0	0x22
@@ -73,7 +78,6 @@
 #define X2_START_RING_NUM_1	256
 
 #define IRQ_ID_SIZE		16
-#define XGENE_MAX_TXC_RINGS	1
 
 #define PHY_POLL_LINK_ON	(10 * HZ)
 #define PHY_POLL_LINK_OFF	(PHY_POLL_LINK_ON / 5)
@@ -103,6 +107,7 @@ struct xgene_enet_desc_ring {
 	void *irq_mbox_addr;
 	u16 dst_ring_num;
 	u8 nbufpool;
+	u8 index;
 	struct sk_buff *(*rx_skb);
 	struct sk_buff *(*cp_skb);
 	dma_addr_t *frag_dma_addr;
@@ -144,6 +149,7 @@ struct xgene_ring_ops {
 	void (*clear)(struct xgene_enet_desc_ring *);
 	void (*wr_cmd)(struct xgene_enet_desc_ring *, int);
 	u32 (*len)(struct xgene_enet_desc_ring *);
+	void (*coalesce)(struct xgene_enet_desc_ring *);
 };
 
 struct xgene_cle_ops {
@@ -159,15 +165,16 @@ struct xgene_enet_pdata {
 	struct clk *clk;
 	struct platform_device *pdev;
 	enum xgene_enet_id enet_id;
-	struct xgene_enet_desc_ring *tx_ring;
-	struct xgene_enet_desc_ring *rx_ring;
-	u16 tx_level;
-	u16 txc_level;
+	struct xgene_enet_desc_ring *tx_ring[XGENE_NUM_TX_RING];
+	struct xgene_enet_desc_ring *rx_ring[XGENE_NUM_RX_RING];
+	u16 tx_level[XGENE_NUM_TX_RING];
+	u16 txc_level[XGENE_NUM_TX_RING];
 	char *dev_name;
 	u32 rx_buff_cnt;
 	u32 tx_qcnt_hi;
-	u32 rx_irq;
-	u32 txc_irq;
+	u32 irqs[XGENE_MAX_ENET_IRQ];
+	u8 rxq_cnt;
+	u8 txq_cnt;
 	u8 cq_cnt;
 	void __iomem *eth_csr_addr;
 	void __iomem *eth_ring_if_addr;
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c b/drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c
index 0b6896b..2b76732 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_ring2.c
@@ -190,6 +190,17 @@ static u32 xgene_enet_ring_len(struct xgene_enet_desc_ring *ring)
 	return num_msgs;
 }
 
+static void xgene_enet_setup_coalescing(struct xgene_enet_desc_ring *ring)
+{
+	u32 data = 0x7777;
+
+	xgene_enet_ring_wr32(ring, CSR_PBM_COAL, 0x8e);
+	xgene_enet_ring_wr32(ring, CSR_PBM_CTICK1, data);
+	xgene_enet_ring_wr32(ring, CSR_PBM_CTICK2, data << 16);
+	xgene_enet_ring_wr32(ring, CSR_THRESHOLD0_SET1, 0x40);
+	xgene_enet_ring_wr32(ring, CSR_THRESHOLD1_SET1, 0x80);
+}
+
 struct xgene_ring_ops xgene_ring2_ops = {
 	.num_ring_config = X2_NUM_RING_CONFIG,
 	.num_ring_id_shift = 13,
@@ -197,4 +208,5 @@ struct xgene_ring_ops xgene_ring2_ops = {
 	.clear = xgene_enet_clear_ring,
 	.wr_cmd = xgene_enet_wr_cmd,
 	.len = xgene_enet_ring_len,
+	.coalesce = xgene_enet_setup_coalescing,
 };
-- 
1.9.1



From linux at arm.linux.org.uk  Wed Feb 17 15:05:29 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 17 Feb 2016 23:05:29 +0000
Subject: [PATCH] clk: fix clk-gpio.c with optional clock= DT property
In-Reply-To: <E1aFJ0A-00086Z-0I@rmk-PC.arm.linux.org.uk>
References: <E1aFJ0A-00086Z-0I@rmk-PC.arm.linux.org.uk>
Message-ID: <20160217230529.GM19428@n2100.arm.linux.org.uk>

On Sat, Jan 02, 2016 at 10:01:34AM +0000, Russell King wrote:
> When the clock DT property is not given, of_clk_get_parent_count()
> returns -ENOENT, which then tries to allocate -2 x 4 bytes of memory,
> which of course fails, causing the whole driver to fail to create
> the clock.
> 
> This causes the SolidRun platforms to fail probing the SDHCI1 interface
> which is connected to the WiFi.
> 
> Fix this by detecting errno codes, skipping the allocation, and fixing
> of_clk_gpio_gate_delayed_register_get() to handle a NULL parent_names
> array.
> 
> Fixes: 80eeb1f0f757 ("clk: add gpio controlled clock multiplexer")
> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
> ---
> This goes all the way back to 80eeb1f0f757 ("clk: add gpio controlled
> clock multiplexer") introduced in June in v4.3-rc2 - which raises the
> question why _development_ work in clk is being merged outside of the
> merge window.
> 
> A rewrite of this patch will be necessary to apply to v4.3 kernels.
> 
> This applies on top of v4.4-rc6.
> 
>  drivers/clk/clk-gpio.c | 23 ++++++++++++++---------
>  1 file changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
> index 335322dc403f..05cca9298f44 100644
> --- a/drivers/clk/clk-gpio.c
> +++ b/drivers/clk/clk-gpio.c
> @@ -264,8 +264,8 @@ static struct clk *of_clk_gpio_gate_delayed_register_get(const char *name,
>  		const char * const *parent_names, u8 num_parents,
>  		unsigned gpio, bool active_low)
>  {
> -	return clk_register_gpio_gate(NULL, name, parent_names[0],
> -			gpio, active_low, 0);
> +	return clk_register_gpio_gate(NULL, name, parent_names ?
> +			parent_names[0] : NULL, gpio, active_low, 0);
>  }
>  
>  static struct clk *of_clk_gpio_mux_delayed_register_get(const char *name,
> @@ -292,13 +292,18 @@ static void __init of_gpio_clk_setup(struct device_node *node,
>  		return;
>  
>  	num_parents = of_clk_get_parent_count(node);
> -
> -	parent_names = kcalloc(num_parents, sizeof(char *), GFP_KERNEL);
> -	if (!parent_names)
> -		return;
> -
> -	for (i = 0; i < num_parents; i++)
> -		parent_names[i] = of_clk_get_parent_name(node, i);
> +	if (num_parents > 0) {
> +		parent_names = kcalloc(num_parents, sizeof(char *), GFP_KERNEL);
> +		if (!parent_names) {
> +			kfree(data);
> +			return;
> +		}
> +
> +		for (i = 0; i < num_parents; i++)
> +			parent_names[i] = of_clk_get_parent_name(node, i);
> +	} else {
> +		parent_names = NULL;
> +	}
>  
>  	data->num_parents = num_parents;
>  	data->parent_names = parent_names;
> -- 
> 2.1.0

Yes, indeed, my patch above which fixed clk-gpio.c as can be seen above
does not have the problem that I'm currently seeing...

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From mturquette at baylibre.com  Wed Feb 17 15:02:53 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Wed, 17 Feb 2016 15:02:53 -0800
Subject: [PATCH 2/2] clk: ti: Add support for dm814x ADPLL
In-Reply-To: <20160217212045.GE21202@atomide.com>
References: <1455312009-808-1-git-send-email-tony@atomide.com>
 <1455312009-808-3-git-send-email-tony@atomide.com>
 <20160217011930.2278.38316@quark.deferred.io>
 <20160217173949.GB21202@atomide.com>
 <20160217205257.2278.11639@quark.deferred.io>
 <20160217212045.GE21202@atomide.com>
Message-ID: <20160217230253.2278.80903@quark.deferred.io>

Quoting Tony Lindgren (2016-02-17 13:20:46)
> * Michael Turquette <mturquette at baylibre.com> [160217 12:53]:
> > Quoting Tony Lindgren (2016-02-17 09:39:49)
> > > * Michael Turquette <mturquette at baylibre.com> [160216 17:32]:
> > > > 
> > > > We have a shiny new series that provides a standard way to do this:
> > > > 
> > > > http://lkml.kernel.org/r/<1455225554-13267-1-git-send-email-mturquette at baylibre.com>
> > > 
> > > OK nice, so tagging the MPU and DDR clocks with CLK_IS_CRITICAL or
> > > "clock-critical" should allow removing this code. I think in this
> > > case I still need to set CLK_IS_CRITICAL as the clock is output 1
> > > of the dts defined clock and does not have a separate dts node.
> > 
> > In fact I hate clock-critical as a DT property and it's only there to
> > support legacy DT bindings that store all clk data in DT and have zero
> > clk data in C. So please use the CLK_IS_CRITICAL or CLK_ENABLE_HAND_OFF
> > flags in C.
> > 
> > Do you think you will ever have a driver that wants to gate these
> > clocks? Probably not for MPU/DDR, but the HAND_OFF flag is a better fit
> > if you do. It's the same as CRITICAL but transfers the prepare/enable
> > reference counting to the consumer driver after that driver calls
> > clk_get() and clk_prepare_enable() on the HAND_OFF clk.
> 
> OK I'll use CLK_ENABLE_HAND_OFF then. Who knows maybe somebody
> somewhere has code running on one of the coprocessors in SRAM that
> actually allows gating these :)

Low power mp3 decoder executing out of ARM icache with DDR clock cut ;-)

Regards,
Mike

> 
> > > I can update when those patches hit Linux next, or I can do a
> > > follow-up patch later on if we want to avoid the dependency
> > > here. Which do you prefer?
> > 
> > Well, testing is always welcome :-)
> >
> > If you rebase onto those patches then I'll add your patches to that
> > series for testing and merge it that way.
> 
> OK will do and repost after some testing.
> 
> Regards,
> 
> Tony


From nicolas.pitre at linaro.org  Wed Feb 17 15:11:37 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Wed, 17 Feb 2016 18:11:37 -0500 (EST)
Subject: [PATCH] ARM: move __kuser_cmpxchg{32,64} into .kprobes.text
In-Reply-To: <1455748127-2844701-1-git-send-email-arnd@arndb.de>
References: <1455748127-2844701-1-git-send-email-arnd@arndb.de>
Message-ID: <alpine.LFD.2.20.1602171806230.13632@knanqh.ubzr>

On Wed, 17 Feb 2016, Arnd Bergmann wrote:

> When kprobes is used, most of the entry-armv.S file is put into the .kprobes.text
> section rather than .text, but the kuser_cmpxchg64_fixup and kuser_cmpxchg32_fixup
> code is not, which can lead to a link error when extremely large kernels get
> built (typically for randconfig):
> 
> arch/arm/kernel/built-in.o: In function `__dabt_usr':
> :(.kprobes.text+0x47c): relocation truncated to fit: R_ARM_JUMP24 against `.text'
> arch/arm/kernel/built-in.o: In function `__irq_usr':
> :(.kprobes.text+0x4e4): relocation truncated to fit: R_ARM_JUMP24 against `.text'
> arch/arm/kernel/built-in.o: In function `__fiq_usr':
> :(.kprobes.text+0x740): relocation truncated to fit: R_ARM_JUMP24 against `.text'
> 
> This moves the two remaining functions into the same section as the rest,
> to avoid the link error.
> 
> The current behavior has existed for many years and has not caused problems in
> practice except for extreme randconfig builds, so the patch should not need to
> get backported.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: b49c0f24cf67 ("[ARM] 4659/1: remove possibilities for spurious false negative with __kuser_cmpxchg")
> Fixes: 785d3cd286f0 ("ARM kprobes: prevent some functions involved with kprobes from being probed")

Stylewise it might be worth having something like:

#ifdef CONFIG_KPROBES
#define KPROBE_TEXT  .section .kprobes.text,"ax",%progbits
#else
#define KPROBE_TEXT .text
#endif

and then use that throughout.  Then...

Acked-by: Nicolas Pitre <nico at linaro.org>


> ---
>  arch/arm/kernel/entry-armv.S | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> index e2550500486d..030e43a0dce8 100644
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -895,7 +895,11 @@ __kuser_cmpxchg64:				@ 0xffff0f60
>  	rsbs	r0, r3, #0			@ set return val and C flag
>  	ldmfd	sp!, {r4, r5, r6, pc}
>  
> +#ifdef CONFIG_KPROBES
> +	.section	.kprobes.text,"ax",%progbits
> +#else
>  	.text
> +#endif
>  kuser_cmpxchg64_fixup:
>  	@ Called from kuser_cmpxchg_fixup.
>  	@ r4 = address of interrupted insn (must be preserved).
> @@ -953,7 +957,11 @@ __kuser_cmpxchg:				@ 0xffff0fc0
>  	rsbs	r0, r3, #0			@ set return val and C flag
>  	usr_ret	lr
>  
> +#ifdef CONFIG_KPROBES
> +	.section	.kprobes.text,"ax",%progbits
> +#else
>  	.text
> +#endif
>  kuser_cmpxchg32_fixup:
>  	@ Called from kuser_cmpxchg_check macro.
>  	@ r4 = address of interrupted insn (must be preserved).
> -- 
> 2.7.0
> 
> 


From stefan at agner.ch  Wed Feb 17 15:29:22 2016
From: stefan at agner.ch (Stefan Agner)
Date: Wed, 17 Feb 2016 15:29:22 -0800
Subject: no irq domain found for ... a GPIO interrupt controller
Message-ID: <2dc0519827dc9d210e38c498d830cd97@agner.ch>

Hi Marc,

I get the following warning on our Vybrid based Colibri VF50 module:
[    0.147674] irq: no irq domain found for
/soc/aips-bus at 40000000/gpio at 4004a000 !

The device tree arch/arm/boot/dts/vf500-colibri.dtsi uses the following
interrupt specification in a touchscreen node which seems to trigger the
issue:
interrupt-parent = <&gpio0>;
interrupts = <8 IRQ_TYPE_LEVEL_LOW>;

We use other GPIO interrupts, but I guess it is a matter of
initialization order, and the above specification seems to be parsed
before the GPIO interrupt-controller gets created...?

It seems that Rob Herring addressed a similar issue a while ago in 
9ec36ca ("of/irq: do irq resolution in platform_get_irq")

Is this problem known?

Currently, the device does not get any interrupts. The interrupt seems
to be requested successfully at probe time later, so I am not sure if
the not working device is really related to the message above....

This is a stack trace when I add a WARN_ON(1) in
irq_create_fwspec_mapping:
[    0.147674] irq: no irq domain found for
/soc/aips-bus at 40000000/gpio at 4004a000 !
[    0.147823] ------------[ cut here ]------------
[    0.147941] WARNING: CPU: 0 PID: 1 at kernel/irq/irqdomain.c:584
irq_create_fwspec_mapping+0xf0/0x1e4()
[    0.148056] Modules linked in:
[    0.148142] CPU: 0 PID: 1 Comm: swapper Not tainted
4.4.0-00070-g3690255-dirty #764
[    0.148246] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
[    0.148311] Backtrace:
[    0.148416] [<80013498>] (dump_backtrace) from [<80013690>]
(show_stack+0x18/0x1c)
[    0.148521]  r7:800539f4 r6:00000248 r5:00000009 r4:00000000
[    0.148646] [<80013678>] (show_stack) from [<8029d070>]
(dump_stack+0x24/0x28)
[    0.148782] [<8029d04c>] (dump_stack) from [<800219a4>]
(warn_slowpath_common+0x88/0xb4)
[    0.148916] [<8002191c>] (warn_slowpath_common) from [<80021a74>]
(warn_slowpath_null+0x24/0x2c)
[    0.149021]  r8:00000000 r7:87cf0f88 r6:87cf0f88 r5:00000000
r4:87843ca8
[    0.149158] [<80021a50>] (warn_slowpath_null) from [<800539f4>]
(irq_create_fwspec_mapping+0xf0/0x1e4)
[    0.149294] [<80053904>] (irq_create_fwspec_mapping) from
[<80053b44>] (irq_create_of_mapping+0x5c/0x64)
[    0.149400]  r6:87cf0f88 r5:878bb7c0 r4:00000000
[    0.149508] [<80053ae8>] (irq_create_of_mapping) from [<8045e934>]
(irq_of_parse_and_map+0x2c/0x34)
[    0.149633] [<8045e908>] (irq_of_parse_and_map) from [<8045e95c>]
(of_irq_to_resource+0x20/0xc4)
[    0.149755] [<8045e93c>] (of_irq_to_resource) from [<8045ea44>]
(of_irq_to_resource_table+0x44/0x54)
[    0.149859]  r8:00000001 r7:00000001 r6:87cf0f88 r5:878bb7dc
r4:00000000
[    0.149990] [<8045ea00>] (of_irq_to_resource_table) from [<8045c5b0>]
(of_device_alloc+0x114/0x184)
[    0.150097]  r7:00000000 r6:878be800 r5:87cf0f88 r4:00000000
[    0.150339] [<8045c49c>] (of_device_alloc) from [<8045c678>]
(of_platform_device_create_pdata+0x58/0xd4)
[    0.150457]  r10:00000000 r9:00000000 r8:80650628 r7:00000000
r6:00000000 r5:87cf0f88
[    0.150600]  r4:00000000
[    0.150688] [<8045c620>] (of_platform_device_create_pdata) from
[<8045c800>] (of_platform_bus_create+0xf0/0x194)
[    0.150796]  r7:00000001 r6:00000000 r5:87cf0f88 r4:00000000
[    0.150912] [<8045c710>] (of_platform_bus_create) from [<8045c9e0>]
(of_platform_populate+0x64/0xc0)
[    0.151016]  r10:00000000 r9:00000001 r8:00000000 r7:00000000
r6:80650628 r5:87ce34f4
[    0.151152]  r4:87cf0f88
[    0.151244] [<8045c97c>] (of_platform_populate) from [<80806fa8>]
(vf610_init_machine+0x24/0x2c)
[    0.151352]  r9:807ff5ec r8:000000b0 r7:87896600 r6:80840420
r5:80801a48 r4:80840420
[    0.151515] [<80806f84>] (vf610_init_machine) from [<80801a70>]
(customize_machine+0x28/0x48)
[    0.151640] [<80801a48>] (customize_machine) from [<800095fc>]
(do_one_initcall+0x98/0x1e0)
[    0.151763] [<80009564>] (do_one_initcall) from [<807ffe34>]
(kernel_init_freeable+0x13c/0x1e0)
[    0.151867]  r10:8082b824 r9:807ff5ec r8:000000b0 r7:8086e440
r6:8086e440 r5:00000003
[    0.152004]  r4:80838704
[    0.152091] [<807ffcf8>] (kernel_init_freeable) from [<805ee93c>]
(kernel_init+0x18/0xf0)
[    0.152197]  r10:00000000 r9:00000000 r8:00000000 r7:00000000
r6:00000000 r5:805ee924
[    0.152333]  r4:8086e440
[    0.152424] [<805ee924>] (kernel_init) from [<8000f878>]
(ret_from_fork+0x14/0x3c)
[    0.152526]  r5:805ee924 r4:00000000
[    0.152670] ---[ end trace c2d84d5af0139987 ]---

--
Stefan


From sfr at canb.auug.org.au  Wed Feb 17 15:33:03 2016
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Thu, 18 Feb 2016 10:33:03 +1100
Subject: linux-next: manual merge of the mvebu tree with the arm-soc tree
Message-ID: <20160218103303.4cc2d25e@canb.auug.org.au>

Hi all,

Today's linux-next merge of the mvebu tree got a conflict in:

  arch/arm64/configs/defconfig

between commit:

  efdda175c07f ("arm64: defconfig: add spmi and usb related configs")

from the arm-soc tree and commit:

  e772ca05cceb ("arm64: defconfig: enable Armada 3700 related config")

from the mvebu tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/configs/defconfig
index 91ae2634cae9,00a49b4e61c1..000000000000
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@@ -170,9 -169,9 +173,11 @@@ CONFIG_SND_SOC=
  CONFIG_SND_SOC_RCAR=y
  CONFIG_SND_SOC_AK4613=y
  CONFIG_USB=y
 +CONFIG_USB_OTG=y
+ CONFIG_USB_XHCI_HCD=y
+ CONFIG_USB_XHCI_PLATFORM=y
  CONFIG_USB_EHCI_HCD=y
 +CONFIG_USB_EHCI_MSM=y
  CONFIG_USB_EHCI_HCD_PLATFORM=y
  CONFIG_USB_OHCI_HCD=y
  CONFIG_USB_OHCI_HCD_PLATFORM=y


From lina.iyer at linaro.org  Wed Feb 17 15:38:30 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Wed, 17 Feb 2016 16:38:30 -0700
Subject: [RFC v2 03/12] PM / cpu_domains: Setup PM domains for
 CPUs/clusters
In-Reply-To: <1455310238-8963-4-git-send-email-lina.iyer@linaro.org>
References: <1455310238-8963-1-git-send-email-lina.iyer@linaro.org>
 <1455310238-8963-4-git-send-email-lina.iyer@linaro.org>
Message-ID: <20160217233830.GA1313@linaro.org>

On Fri, Feb 12 2016 at 13:51 -0700, Lina Iyer wrote:

>+static int cpu_pd_power_on(struct generic_pm_domain *genpd)
>+{
>+	struct cpu_pm_domain *pd = to_cpu_pd(genpd);
>+
>+	return pd->ops.power_on();

Needs a check for NULL ops.power_on() here.
>+}
>+
>+static int cpu_pd_power_off(struct generic_pm_domain *genpd)
>+{
>+	struct cpu_pm_domain *pd = to_cpu_pd(genpd);
>+
>+	return pd->ops.power_off(genpd->state_idx,
>+			genpd->states[genpd->state_idx].param);
Needs a check for NULL ops.power_off().

Thanks,
Lina


From stefan at agner.ch  Wed Feb 17 15:40:58 2016
From: stefan at agner.ch (Stefan Agner)
Date: Wed, 17 Feb 2016 15:40:58 -0800
Subject: [PATCH v3 1/3] ARM: dts: vf-colibri: remove regulator container node
Message-ID: <1455752460-2770-1-git-send-email-stefan@agner.ch>

Drop the fake simple-bus container 'regulators' and put the
regulators directly under the root node. This also makes the
artificial 'reg' properties superfluous. While at it, remove
the unnecessary regulator-always-on property and name the
regulators according to schematics.

Signed-off-by: Stefan Agner <stefan at agner.ch>
---
Changes since v2:
- remove regulator-always-on

Changes since v1:
- rename regulators according to schematics
- drop sys prefix

 arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 42 ++++++++++++-------------------
 1 file changed, 16 insertions(+), 26 deletions(-)

diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
index b494673..291e939 100644
--- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -50,32 +50,22 @@
 		clock-frequency = <16000000>;
 	};
 
-	regulators {
-		compatible = "simple-bus";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		sys_5v0_reg: regulator at 0 {
-			compatible = "regulator-fixed";
-			reg = <0>;
-			regulator-name = "5v0";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			regulator-always-on;
-		};
+	reg_5v0: regulator-5v0 {
+		compatible = "regulator-fixed";
+		regulator-name = "5V";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+	};
 
-		/* USBH_PEN */
-		usbh_vbus_reg: regulator at 1 {
-			compatible = "regulator-fixed";
-			pinctrl-names = "default";
-			pinctrl-0 = <&pinctrl_usbh1_reg>;
-			reg = <1>;
-			regulator-name = "usbh_vbus";
-			regulator-min-microvolt = <5000000>;
-			regulator-max-microvolt = <5000000>;
-			gpio = <&gpio2 19 GPIO_ACTIVE_LOW>;
-			vin-supply = <&sys_5v0_reg>;
-		};
+	reg_usbh_vbus: regulator-usbh-vbus {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usbh1_reg>;
+		regulator-name = "VCC_USB[1-4]";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpio = <&gpio2 19 GPIO_ACTIVE_LOW>; /* USBH_PEN resp. USBH_P_EN */
+		vin-supply = <&reg_5v0>;
 	};
 };
 
@@ -145,7 +135,7 @@
 };
 
 &usbh1 {
-	vbus-supply = <&usbh_vbus_reg>;
+	vbus-supply = <&reg_usbh_vbus>;
 };
 
 &iomuxc {
-- 
2.7.1



From stefan at agner.ch  Wed Feb 17 15:41:00 2016
From: stefan at agner.ch (Stefan Agner)
Date: Wed, 17 Feb 2016 15:41:00 -0800
Subject: [PATCH v3 3/3] ARM: dts: vf-colibri: add carrier boards 3.3V supply
In-Reply-To: <1455752460-2770-1-git-send-email-stefan@agner.ch>
References: <1455752460-2770-1-git-send-email-stefan@agner.ch>
Message-ID: <1455752460-2770-3-git-send-email-stefan@agner.ch>

Add the carrier boards 3.3V supply as fixed regulator. This allows
to specify the power supply for nodes like backlight.

Signed-off-by: Stefan Agner <stefan at agner.ch>
---
Changes since v2:
- remove regulator-always-on

 arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
index 291e939..4d8b7f6 100644
--- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -50,6 +50,13 @@
 		clock-frequency = <16000000>;
 	};
 
+	reg_3v3: regulator-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "3.3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
+
 	reg_5v0: regulator-5v0 {
 		compatible = "regulator-fixed";
 		regulator-name = "5V";
@@ -72,6 +79,7 @@
 &bl {
 	brightness-levels = <0 4 8 16 32 64 128 255>;
 	default-brightness-level = <6>;
+	power-supply = <&reg_3v3>;
 	status  = "okay";
 };
 
@@ -122,6 +130,10 @@
 	status = "okay";
 };
 
+&reg_module_3v3 {
+	vin-supply = <&reg_3v3>;
+};
+
 &uart0 {
 	status = "okay";
 };
-- 
2.7.1



From stefan at agner.ch  Wed Feb 17 15:40:59 2016
From: stefan at agner.ch (Stefan Agner)
Date: Wed, 17 Feb 2016 15:40:59 -0800
Subject: [PATCH v3 2/3] ARM: dts: vf-colibri: add basic supply regulators
In-Reply-To: <1455752460-2770-1-git-send-email-stefan@agner.ch>
References: <1455752460-2770-1-git-send-email-stefan@agner.ch>
Message-ID: <1455752460-2770-2-git-send-email-stefan@agner.ch>

Colibri modules need to be powered using the power pins 3V3 and
AVDD_AUDIO. Add fixed regulators which represent this power rails.
Potentially, those power rails could be switched on a carrier
board. A carrier board device tree could add a own regulator with
a GPIO, and reference that regulator in a vin-supply property of
those new module level system regulators.

Signed-off-by: Stefan Agner <stefan at agner.ch>
---
Changes since v2:
- remove regulator-always-on

Changes since v1:
- Add module prefix to avoid namespace issue with Carrier Board regulators
- Name the regulators according to schematics

 arch/arm/boot/dts/vf-colibri.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi b/arch/arm/boot/dts/vf-colibri.dtsi
index ff6f58e..ed4cfc5 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -48,14 +48,30 @@
 		enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
 		status = "disabled";
 	};
+
+	reg_module_3v3: regulator-module-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "+V3.3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
+
+	reg_module_3v3_avdd: regulator-module-3v3-avdd {
+		compatible = "regulator-fixed";
+		regulator-name = "+V3.3_AVDD_AUDIO";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
 };
 
 &adc0 {
 	status = "okay";
+	vref-supply = <&reg_module_3v3_avdd>;
 };
 
 &adc1 {
 	status = "okay";
+	vref-supply = <&reg_module_3v3_avdd>;
 };
 
 &can0 {
@@ -96,6 +112,7 @@
 
 &fec1 {
 	phy-mode = "rmii";
+	phy-supply = <&reg_module_3v3>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_fec1>;
 };
-- 
2.7.1



From david.brown at linaro.org  Wed Feb 17 15:43:06 2016
From: david.brown at linaro.org (David Brown)
Date: Wed, 17 Feb 2016 16:43:06 -0700
Subject: [PATCH] ARM: vdso: Mark vDSO code as read-only
In-Reply-To: <CAGXu5jK22LfvLdMfWz_vbQsJ3bbjSdJrYAp=5yWzD4yRNTTGFQ@mail.gmail.com>
References: <1453226922-16831-1-git-send-email-keescook@chromium.org>
 <20160216213659.GA47194@davidb.org>
 <CAGXu5j+H63jhcDpHpXK5aWvgUBz=5vB0FK_zRoc+wZEk32B2fg@mail.gmail.com>
 <20160217052010.GA49233@davidb.org>
 <CAGXu5jK22LfvLdMfWz_vbQsJ3bbjSdJrYAp=5yWzD4yRNTTGFQ@mail.gmail.com>
Message-ID: <20160217234306.GA59532@davidb.org>

On Wed, Feb 17, 2016 at 03:00:52PM -0800, Kees Cook wrote:
>On Tue, Feb 16, 2016 at 9:20 PM, David Brown <david.brown at linaro.org> wrote:
>> On Tue, Feb 16, 2016 at 01:52:33PM -0800, Kees Cook wrote:
>>>
>>> On Tue, Feb 16, 2016 at 1:36 PM, David Brown <david.brown at linaro.org>
>>> wrote:
>>>>
>>>> Although the arm vDSO is cleanly separated by code/data with the code
>>>> being read-only in userspace mappings, the code page is still writable
>>>> from the kernel.  There have been exploits (such as
>>>> http://itszn.com/blog/?p=21) that take advantage of this on x86 to go
>>>> from a bad kernel write to full root.
>>>>
>>>> Prevent this specific exploit on arm by putting the vDSO code page in
>>>> post-init read-only memory as well.
>>>
>>>
>>> Is the vdso dynamically built at init time like on x86, or can this
>>> just use .rodata directly?
>>
>>
>> On ARM, it is patched during init.  Arm64's is just plain read-only.
>
>Okay, great. I've added this to my postinit-readonly series (which I
>just refreshed and sent out again...)

However, this distinction between .rodata and .data..ro_after_init is
kind of fuzzy, anyway, since they both get made actually read-only at
the same time (post init).  The patch actually does work fine with the
vDSO page in .rodata, since the patching happens during init.

Is there a possible future consideration to perhaps make .rodata read
only much earlier?

David


From stefan at agner.ch  Wed Feb 17 15:44:16 2016
From: stefan at agner.ch (Stefan Agner)
Date: Wed, 17 Feb 2016 15:44:16 -0800
Subject: [PATCH] ARM: dts: vf-colibri: disable write-protection for SD-card
Message-ID: <1455752656-4040-1-git-send-email-stefan@agner.ch>

The Colibri standard does not define a pin for SD-Card write-
protection. Use the disable-wp property to indicate that there
is no physical WP line present.

Signed-off-by: Stefan Agner <stefan at agner.ch>
---
 arch/arm/boot/dts/vf-colibri.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi b/arch/arm/boot/dts/vf-colibri.dtsi
index ff6f58e..e49bbbc 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -92,6 +92,7 @@
 	pinctrl-0 = <&pinctrl_esdhc1>;
 	bus-width = <4>;
 	cd-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+	disable-wp;
 };
 
 &fec1 {
-- 
2.7.1



From keescook at chromium.org  Wed Feb 17 15:48:21 2016
From: keescook at chromium.org (Kees Cook)
Date: Wed, 17 Feb 2016 15:48:21 -0800
Subject: [PATCH] ARM: vdso: Mark vDSO code as read-only
In-Reply-To: <20160217234306.GA59532@davidb.org>
References: <1453226922-16831-1-git-send-email-keescook@chromium.org>
 <20160216213659.GA47194@davidb.org>
 <CAGXu5j+H63jhcDpHpXK5aWvgUBz=5vB0FK_zRoc+wZEk32B2fg@mail.gmail.com>
 <20160217052010.GA49233@davidb.org>
 <CAGXu5jK22LfvLdMfWz_vbQsJ3bbjSdJrYAp=5yWzD4yRNTTGFQ@mail.gmail.com>
 <20160217234306.GA59532@davidb.org>
Message-ID: <CAGXu5jJmpq_2mmTLD0VbnY1SBF5b5Rr04HKWfD1LEaGxnztFdQ@mail.gmail.com>

On Wed, Feb 17, 2016 at 3:43 PM, David Brown <david.brown at linaro.org> wrote:
> On Wed, Feb 17, 2016 at 03:00:52PM -0800, Kees Cook wrote:
>>
>> On Tue, Feb 16, 2016 at 9:20 PM, David Brown <david.brown at linaro.org>
>> wrote:
>>>
>>> On Tue, Feb 16, 2016 at 01:52:33PM -0800, Kees Cook wrote:
>>>>
>>>>
>>>> On Tue, Feb 16, 2016 at 1:36 PM, David Brown <david.brown at linaro.org>
>>>> wrote:
>>>>>
>>>>>
>>>>> Although the arm vDSO is cleanly separated by code/data with the code
>>>>> being read-only in userspace mappings, the code page is still writable
>>>>> from the kernel.  There have been exploits (such as
>>>>> http://itszn.com/blog/?p=21) that take advantage of this on x86 to go
>>>>> from a bad kernel write to full root.
>>>>>
>>>>> Prevent this specific exploit on arm by putting the vDSO code page in
>>>>> post-init read-only memory as well.
>>>>
>>>>
>>>>
>>>> Is the vdso dynamically built at init time like on x86, or can this
>>>> just use .rodata directly?
>>>
>>>
>>>
>>> On ARM, it is patched during init.  Arm64's is just plain read-only.
>>
>>
>> Okay, great. I've added this to my postinit-readonly series (which I
>> just refreshed and sent out again...)
>
>
> However, this distinction between .rodata and .data..ro_after_init is
> kind of fuzzy, anyway, since they both get made actually read-only at
> the same time (post init).  The patch actually does work fine with the
> vDSO page in .rodata, since the patching happens during init.

Yeah, in the ARM case, that's true. I think we should probably keep it
marked "correctly" though.

> Is there a possible future consideration to perhaps make .rodata read
> only much earlier?

Yeah, this will likely be a future improvement. Some architectures
already mark .rodata before the mark_rodata_ro() call. Once we start
to have more use of postinit-readonly, I suspect we'll see more
clarification of when those things happen.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security


From horms at verge.net.au  Wed Feb 17 15:48:57 2016
From: horms at verge.net.au (Simon Horman)
Date: Thu, 18 Feb 2016 08:48:57 +0900
Subject: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
In-Reply-To: <56C4C506.8040803@cogentembedded.com>
References: <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
 <874mdhtn7d.wl%kuninori.morimoto.gx@renesas.com>
 <20160210171455.GB17671@verge.net.au>
 <56BE0CB1.4070408@cogentembedded.com>
 <20160212184343.GA31655@verge.net.au>
 <56BE2DC6.4080802@cogentembedded.com>
 <20160212193347.GB23472@verge.net.au>
 <56BE3912.9000601@cogentembedded.com>
 <20160217053848.GC11534@verge.net.au>
 <56C4C506.8040803@cogentembedded.com>
Message-ID: <20160217234857.GA6886@verge.net.au>

On Wed, Feb 17, 2016 at 10:07:50PM +0300, Sergei Shtylyov wrote:
> On 02/17/2016 08:38 AM, Simon Horman wrote:
> 
> >>>>>>>>>Define the generic R8A7794 part of  the sound device node.
> >>>>>>>>>This sound device  is a complex one and comprises the Audio Clock Generator
> >>>>>>>>>(ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
> >>>>>>>>>(SSI[U]), and Audio DMAC-Peripheral-Peripheral.
> >>>>>>>>>It is up  to the board file to enable the device.
> >>>>>>>>>
> >>>>>>>>>This patch is based on the R8A7791 sound work by Kuninori Morimoto.
> >>>>>>>>>
> >>>>>>>>>Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
> >>>>>>>>(snip)
> >>>>>>>>>+		rcar_sound,src {
> >>>>>>>>>+			src1: src at 1 {
> >>>>>>>>>+				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>>>>>+				dmas = <&audma0 0x87>, <&audma0 0x9c>;
> >>>>>>>>>+				dma-names = "rx", "tx";
> >>>>>>>>>+			};
> >>>>>>>>>+			src2: src at 2 {
> >>>>>>>>>+				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>>>>>+				dmas = <&audma0 0x89>, <&audma0 0x9e>;
> >>>>>>>>>+				dma-names = "rx", "tx";
> >>>>>>>>>+			};
> >>>>>>>>>+			src3: src at 3 {
> >>>>>>>>>+				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>>>>>+				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
> >>>>>>>>>+				dma-names = "rx", "tx";
> >>>>>>>>>+			};
> >>>>>>>>>+			src4: src at 4 {
> >>>>>>>>>+				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>>>>>+				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
> >>>>>>>>>+				dma-names = "rx", "tx";
> >>>>>>>>>+			};
> >>>>>>>>>+			src5: src at 5 {
> >>>>>>>>>+				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>>>>>+				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
> >>>>>>>>>+				dma-names = "rx", "tx";
> >>>>>>>>>+			};
> >>>>>>>>>+			src6: src at 6 {
> >>>>>>>>>+				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>>>>>+				dmas = <&audma0 0x91>, <&audma0 0xb4>;
> >>>>>>>>>+				dma-names = "rx", "tx";
> >>>>>>>>>+			};
> >>>>>>>>>+		};
> >>>>>>>>
> >>>>>>>>I think this can't work correctly, because driver is assuming
> >>>>>>>>DT has all channles (from 0). (see linux/sound/soc/sh/rcar/src.c :: rsnd_src_probe)
> >>>>>>>>Can you adds dummy src0 with some comments ? or fix src.c driver ?
> >>>>>>>
> >>>>>>>I would prefer the driver to be fixed (I had a similar patchset locally
> >>>>>>>and I found it doesn't work).
> >>>>>>
> >>>>>>    You mean you had R8A7794 sound patch set too?
> >>>>>
> >>>>>Yes, I was working on it recently.
> >>>>>I suppose we should coordinate these things in future to avoid
> >>>>>duplicated effort.
> >>>>
> >>>>    Yes, seems a good idea now. :-)
> >>>>
> >>>>>>>The reason is that DT should describe
> >>>>>>>the hardware rather than the current state of the software.
> >>>>>>
> >>>>>>    Yes, of course. Just tell me do I have to fix the driver *before* this
> >>>>>>patch set is accepted?
> >>>>
> >>>>>I did not entirely get to the bottom of the problem, but I think that at
> >>>>>the very least something needs to be done about the for_each_rsnd_src()
> >>>>>loop in rsnd_src_probe.
> >>>>
> >>>>    It's not that it replies to my question. :-)
> >>>>    So you're looking at this issue yourself?
> >>>
> >>>I have not got very far, as you can see, but I was planning to look into it.
> >>>I don't mind if you want to do so.
> >>
> >>    After consultation with the management, I'm going to look into this issue
> >>myself. :-)
> >
> >Excellent.
> 
>    But not immediately. I have some other things to look at before that (DU
> and AVB), they'll going to take some (significant) time... :-(
> 
> >FWIW, I can test anything you come up with for the r8a7794 an alt board
> 
>    I have remote access to Alt now, in fact using it currently for the AVB work.
> 
> >or post patches for it once you have r8a7794/silk sorted out.
> 
>    I already have audio on these working. Or you're going to wait until I
> fix the SRC issue?

I'm happy to merge a subset of your r8a7794/silk patches,
that don't touch the SRC issue if you think that is appropriate.
>From there I could get similar functionality running on the Alt - I don't
expect that to be a difficult task. And then when you come back to the SRC
issue we can enhance support for r8a7794/silk,alt.


From kirill at shutemov.name  Wed Feb 17 15:58:08 2016
From: kirill at shutemov.name (Kirill A. Shutemov)
Date: Thu, 18 Feb 2016 01:58:08 +0200
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160217201340.2dafad8d@thinkpad>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
 <alpine.LFD.2.20.1602131238260.1910@schleppi>
 <20160217201340.2dafad8d@thinkpad>
Message-ID: <20160217235808.GA21696@node.shutemov.name>

On Wed, Feb 17, 2016 at 08:13:40PM +0100, Gerald Schaefer wrote:
> On Sat, 13 Feb 2016 12:58:31 +0100 (CET)
> Sebastian Ott <sebott at linux.vnet.ibm.com> wrote:
> 
> > [   59.875935] ------------[ cut here ]------------
> > [   59.875937] kernel BUG at mm/huge_memory.c:2884!
> > [   59.875979] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> > [   59.875986] Modules linked in: bridge stp llc btrfs xor mlx4_en vxlan ip6_udp_tunnel udp_tunnel mlx4_ib ptp pps_core ib_sa ib_mad ib_core ib_addr ghash_s390 prng raid6_pq ecb aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 mlx4_core sha_common genwqe_card scm_block crc_itu_t vhost_net tun vhost dm_mod macvtap eadm_sch macvlan kvm autofs4
> > [   59.876033] CPU: 2 PID: 5402 Comm: git Tainted: G        W       4.4.0-07794-ga4eff16-dirty #77
> > [   59.876036] task: 00000000d2312948 ti: 00000000cfecc000 task.ti: 00000000cfecc000
> > [   59.876039] Krnl PSW : 0704d00180000000 00000000002bf3aa (__split_huge_pmd_locked+0x562/0xa10)
> > [   59.876045]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
> >                Krnl GPRS: 0000000001a7a1cf 000003d10177c000 0000000000044068 000000005df00215
> > [   59.876051]            0000000000000001 0000000000000001 0000000000000000 00000000774e6900
> > [   59.876054]            000003ff52000000 000000006d403b10 000000006e1eb800 000003ff51f00000
> > [   59.876058]            000003d10177c000 0000000000715190 00000000002bf234 00000000cfecfb58
> > [   59.876068] Krnl Code: 00000000002bf39c: d507d010a000	clc	16(8,%%r13),0(%%r10)
> >                           00000000002bf3a2: a7840004		brc	8,2bf3aa
> >                          #00000000002bf3a6: a7f40001		brc	15,2bf3a8
> >                          >00000000002bf3aa: 91407440		tm	1088(%%r7),64
> >                           00000000002bf3ae: a7840208		brc	8,2bf7be
> >                           00000000002bf3b2: a7f401e9		brc	15,2bf784
> >                           00000000002bf3b6: 9104a006		tm	6(%%r10),4
> >                           00000000002bf3ba: a7740004		brc	7,2bf3c2
> > [   59.876089] Call Trace:
> > [   59.876092] ([<00000000002bf234>] __split_huge_pmd_locked+0x3ec/0xa10)
> > [   59.876095]  [<00000000002c4310>] __split_huge_pmd+0x118/0x218
> > [   59.876099]  [<00000000002810e8>] unmap_single_vma+0x2d8/0xb40
> > [   59.876102]  [<0000000000282d66>] zap_page_range+0x116/0x318
> > [   59.876105]  [<000000000029b834>] SyS_madvise+0x23c/0x5e8
> > [   59.876108]  [<00000000006f9f56>] system_call+0xd6/0x258
> > [   59.876111]  [<000003ff9bbfd282>] 0x3ff9bbfd282
> > [   59.876113] INFO: lockdep is turned off.
> > [   59.876115] Last Breaking-Event-Address:
> > [   59.876118]  [<00000000002bf3a6>] __split_huge_pmd_locked+0x55e/0xa10
> 
> The BUG at mm/huge_memory.c:2884 is interesting, it's the BUG_ON(!pte_none(*pte))
> check in __split_huge_pmd_locked(). Obviously we expect the pre-allocated
> pagetables to be empty, but in collapse_huge_page() we deposit the original
> pagetable instead of allocating a new (empty) one. This saves an allocation,
> which is good, but doesn't that mean that if such a collapsed hugepage will
> ever be split, we will always run into the BUG_ON(!pte_none(*pte)), or one
> of the two other VM_BUG_ONs in mm/huge_memory.c that check the same?
> 
> This behavior is not new, it was the same before the THP rework, so I do not
> assume that it is related to the current problems, maybe with the exception
> of this specific crash. I never saw the BUG at mm/huge_memory.c:2884 myself,
> and the other crashes probably cannot be explained with this. Maybe I am
> also missing something, but I do not see how collapse_huge_page() and the
> (non-empty) pgtable deposit there can work out with the BUG_ON(!pte_none(*pte))
> checks. Any thoughts?

I don't think there's a problem: ptes in the pgtable are cleared with
pte_clear() in __collapse_huge_page_copy().

-- 
 Kirill A. Shutemov


From horms at verge.net.au  Wed Feb 17 16:00:31 2016
From: horms at verge.net.au (Simon Horman)
Date: Thu, 18 Feb 2016 09:00:31 +0900
Subject: [PATCH 0/2] Add R8A7794 EtherAVB DT support
In-Reply-To: <1926986.gmrsfKE5A2@wasted.cogentembedded.com>
References: <1926986.gmrsfKE5A2@wasted.cogentembedded.com>
Message-ID: <20160218000031.GB6886@verge.net.au>

On Wed, Feb 17, 2016 at 11:41:57PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
>    Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
> 'renesas-devel-20160217v2-v4.5-rc4' tag plus the R8A7794 audio patches posted
> last week. Here we add the EtherAVB device tree support for the R8A7794 SoC.
> 
> [1/2] ARM: dts: r8a7794: add EtherAVB clock
> [2/2] ARM: dts: r8a7794: add EtherAVB support

Thanks, I have queued these up for v4.6.


From mturquette at baylibre.com  Wed Feb 17 16:07:47 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Wed, 17 Feb 2016 16:07:47 -0800
Subject: [PATCH] clk: fix clk-gpio.c with optional clock= DT property
In-Reply-To: <20160217230529.GM19428@n2100.arm.linux.org.uk>
References: <E1aFJ0A-00086Z-0I@rmk-PC.arm.linux.org.uk>
 <20160217230529.GM19428@n2100.arm.linux.org.uk>
Message-ID: <20160218000747.2278.46405@quark.deferred.io>

Quoting Russell King - ARM Linux (2016-02-17 15:05:29)
> On Sat, Jan 02, 2016 at 10:01:34AM +0000, Russell King wrote:
> > When the clock DT property is not given, of_clk_get_parent_count()
> > returns -ENOENT, which then tries to allocate -2 x 4 bytes of memory,
> > which of course fails, causing the whole driver to fail to create
> > the clock.
> > 
> > This causes the SolidRun platforms to fail probing the SDHCI1 interface
> > which is connected to the WiFi.
> > 
> > Fix this by detecting errno codes, skipping the allocation, and fixing
> > of_clk_gpio_gate_delayed_register_get() to handle a NULL parent_names
> > array.
> > 
> > Fixes: 80eeb1f0f757 ("clk: add gpio controlled clock multiplexer")
> > Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
> > ---
> > This goes all the way back to 80eeb1f0f757 ("clk: add gpio controlled
> > clock multiplexer") introduced in June in v4.3-rc2 - which raises the
> > question why _development_ work in clk is being merged outside of the
> > merge window.
> > 
> > A rewrite of this patch will be necessary to apply to v4.3 kernels.
> > 
> > This applies on top of v4.4-rc6.
> > 
> >  drivers/clk/clk-gpio.c | 23 ++++++++++++++---------
> >  1 file changed, 14 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
> > index 335322dc403f..05cca9298f44 100644
> > --- a/drivers/clk/clk-gpio.c
> > +++ b/drivers/clk/clk-gpio.c
> > @@ -264,8 +264,8 @@ static struct clk *of_clk_gpio_gate_delayed_register_get(const char *name,
> >               const char * const *parent_names, u8 num_parents,
> >               unsigned gpio, bool active_low)
> >  {
> > -     return clk_register_gpio_gate(NULL, name, parent_names[0],
> > -                     gpio, active_low, 0);
> > +     return clk_register_gpio_gate(NULL, name, parent_names ?
> > +                     parent_names[0] : NULL, gpio, active_low, 0);
> >  }
> >  
> >  static struct clk *of_clk_gpio_mux_delayed_register_get(const char *name,
> > @@ -292,13 +292,18 @@ static void __init of_gpio_clk_setup(struct device_node *node,
> >               return;
> >  
> >       num_parents = of_clk_get_parent_count(node);
> > -
> > -     parent_names = kcalloc(num_parents, sizeof(char *), GFP_KERNEL);
> > -     if (!parent_names)
> > -             return;
> > -
> > -     for (i = 0; i < num_parents; i++)
> > -             parent_names[i] = of_clk_get_parent_name(node, i);
> > +     if (num_parents > 0) {
> > +             parent_names = kcalloc(num_parents, sizeof(char *), GFP_KERNEL);
> > +             if (!parent_names) {
> > +                     kfree(data);
> > +                     return;
> > +             }
> > +
> > +             for (i = 0; i < num_parents; i++)
> > +                     parent_names[i] = of_clk_get_parent_name(node, i);
> > +     } else {
> > +             parent_names = NULL;
> > +     }
> >  
> >       data->num_parents = num_parents;
> >       data->parent_names = parent_names;
> > -- 
> > 2.1.0
> 
> Yes, indeed, my patch above which fixed clk-gpio.c as can be seen above
> does not have the problem that I'm currently seeing...

Hi Russell,

I must be missing something. After merging your patch on top of Brian's,
the code looks like:

        ...
        int i, num_parents;

        num_parents = of_clk_get_parent_count(node);
        if (num_parents < 0)
                return;

        data = kzalloc(sizeof(*data), GFP_KERNEL);
        if (!data)
                return;

        if (num_parents) {
                parent_names = kcalloc(num_parents, sizeof(char *), GFP_KERNEL);
                if (!parent_names) {
                        kfree(data);
                        return;
                }

                for (i = 0; i < num_parents; i++)
                        parent_names[i] = of_clk_get_parent_name(node, i);
        } else {
                parent_names = NULL;
        }

Brian's if (num_parents < 0) check, followed by the if (num_parent)
check appear equivalent to your original patch. Not sure why I merged it
as if (num_parents) instead of if (num_parents > 0) as your original
patch uses, but thanks to the extra check that predates your patch it
should be equivalent.

Let me know if I've lost the plot.

Regards,
Mike

> 
> -- 
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.


From stefan at agner.ch  Wed Feb 17 16:37:00 2016
From: stefan at agner.ch (Stefan Agner)
Date: Wed, 17 Feb 2016 16:37:00 -0800
Subject: [PATCH] ARM: dts: vf610: add performance monitoring unit
Message-ID: <1455755820-31442-1-git-send-email-stefan@agner.ch>

All Freescale Vybrid SoC include a Cortex-A5 core which supports
ARM's standard PMU (performance monitoring unit). Include the
monitoring unit into the Cortex-A5 base device tree vf500.dtsi.

Signed-off-by: Stefan Agner <stefan at agner.ch>
---
 arch/arm/boot/dts/vf500.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/vf500.dtsi b/arch/arm/boot/dts/vf500.dtsi
index b94b992..9cd1ac5 100644
--- a/arch/arm/boot/dts/vf500.dtsi
+++ b/arch/arm/boot/dts/vf500.dtsi
@@ -75,6 +75,16 @@
 				clocks = <&clks VF610_CLK_PLATFORM_BUS>;
 			};
 		};
+
+		aips-bus at 40080000 {
+
+			pmu at 40089000 {
+				compatible = "arm,cortex-a5-pmu";
+				interrupts = <7 IRQ_TYPE_LEVEL_HIGH>;
+				interrupt-affinity = <&a5_cpu>;
+			};
+		};
+
 	};
 };
 
-- 
2.7.1



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:43 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:43 -0700
Subject: [PATCH 01/21] coresight: "DEVICE_ATTR_RO" should defined as static.
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-2-git-send-email-mathieu.poirier@linaro.org>

From: Eric Long <eric.long at linaro.org>

"DEVICE_ATTR_RO(name)" should be defined as static. And
there is an unnecessary space at the front of the code.

The sparse tool output logs as the following:
coresight-etm4x.c:2224:1: warning: symbol 'dev_attr_trcoslsr' was
not declared. Should it be static?
coresight-etm4x.c:2225:1: warning: symbol 'dev_attr_trcpdcr' was
not declared. Should it be static?
coresight-etm4x.c:2226:1: warning: symbol 'dev_attr_trcpdsr' was
not declared. Should it be static?
And the smatch tool output logs as the following:
of_coresight.c:89 of_coresight_alloc_memory() warn:
inconsistent indenting

Signed-off-by: Eric Long <eric.long at linaro.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm4x.c | 2 +-
 drivers/hwtracing/coresight/of_coresight.c    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index b6ae9cb6ff57..d6a92c6d3a66 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -2227,7 +2227,7 @@ static ssize_t name##_show(struct device *_dev,				\
 	return scnprintf(buf, PAGE_SIZE, "0x%x\n",			\
 			 readl_relaxed(drvdata->base + offset));	\
 }									\
-DEVICE_ATTR_RO(name)
+static DEVICE_ATTR_RO(name)
 
 coresight_simple_func(trcoslsr, TRCOSLSR);
 coresight_simple_func(trcpdcr, TRCPDCR);
diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
index b0973617826f..3cc57c1e3b5d 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -86,7 +86,7 @@ static int of_coresight_alloc_memory(struct device *dev,
 		return -ENOMEM;
 
 	/* Children connected to this component via @outports */
-	 pdata->child_names = devm_kzalloc(dev, pdata->nr_outport *
+	pdata->child_names = devm_kzalloc(dev, pdata->nr_outport *
 					  sizeof(*pdata->child_names),
 					  GFP_KERNEL);
 	if (!pdata->child_names)
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:42 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:42 -0700
Subject: [PATCH 00/21] coresight: next v4.5-rc4
Message-ID: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>

Good evening Greg,

Here are more enhancement that I would like to see going in the 4.6 cycle.
Everything will apply cleanly on your 'char-misc-next' branch.  

Thanks,
Mathieu

Eric Long (2):
  coresight: "DEVICE_ATTR_RO" should defined as static.
  coresight: etm4x: Check every parameter used by dma_xx_coherent.

Mathieu Poirier (18):
  coresight: associating path with session rather than tracer
  coresight: add API to get sink from path
  coresight: moving PM runtime operations to core framework
  coresight: etm3x: moving etm_readl/writel to header file
  coresight: etm3x: moving sysFS entries to dedicated file
  coresight: etm3x: unlocking tracers in default arch init
  coresight: etm3x: splitting struct etm_drvdata
  coresight: etm3x: adding operation mode for etm_enable()
  coresight: etm3x: set progbit to stop trace collection
  coresight: etm3x: changing default trace configuration
  coresight: etm3x: consolidating initial config
  coresight: etm3x: implementing user/kernel mode tracing
  coresight: etm3x: implementing perf_enable/disable() API
  coresight: etb10: moving to local atomic operations
  coresight: etb10: adding operation mode for sink->enable()
  coresight: etb10: implementing AUX API
  coresight: etm-perf: new PMU driver for ETM tracers
  coresight: introducing a global trace ID function

Paul Gortmaker (1):
  drivers/hwtracing: make coresight-* explicitly non-modular

 drivers/hwtracing/coresight/Kconfig                |    1 +
 drivers/hwtracing/coresight/Makefile               |    4 +-
 drivers/hwtracing/coresight/coresight-etb10.c      |  282 +++-
 drivers/hwtracing/coresight/coresight-etm-perf.c   |  393 +++++
 drivers/hwtracing/coresight/coresight-etm-perf.h   |   32 +
 drivers/hwtracing/coresight/coresight-etm.h        |  142 +-
 .../hwtracing/coresight/coresight-etm3x-sysfs.c    | 1272 +++++++++++++++
 drivers/hwtracing/coresight/coresight-etm3x.c      | 1724 ++++----------------
 drivers/hwtracing/coresight/coresight-etm4x.c      |   16 +-
 drivers/hwtracing/coresight/coresight-funnel.c     |   11 +-
 drivers/hwtracing/coresight/coresight-priv.h       |   15 +
 .../coresight/coresight-replicator-qcom.c          |    8 +-
 drivers/hwtracing/coresight/coresight-replicator.c |    9 +-
 drivers/hwtracing/coresight/coresight-tmc.c        |   20 +-
 drivers/hwtracing/coresight/coresight-tpiu.c       |   13 +-
 drivers/hwtracing/coresight/coresight.c            |  329 ++--
 drivers/hwtracing/coresight/of_coresight.c         |    3 +-
 include/linux/amba/bus.h                           |    9 +
 include/linux/coresight-pmu.h                      |   39 +
 include/linux/coresight.h                          |   31 +-
 20 files changed, 2740 insertions(+), 1613 deletions(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-etm-perf.c
 create mode 100644 drivers/hwtracing/coresight/coresight-etm-perf.h
 create mode 100644 drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
 create mode 100644 include/linux/coresight-pmu.h

-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:46 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:46 -0700
Subject: [PATCH 04/21] coresight: add API to get sink from path
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-5-git-send-email-mathieu.poirier@linaro.org>

Add an API allowing external code to quickly get a handle on the
sink within a path.  The sink is always last, but adding an API allows
to keep the path's node structure private and remove redundant checks.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-priv.h |  1 +
 drivers/hwtracing/coresight/coresight.c      | 15 +++++++++++++++
 2 files changed, 16 insertions(+)

diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 7b193a34d709..14f245a2018d 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -54,6 +54,7 @@ static inline void CS_UNLOCK(void __iomem *addr)
 
 void coresight_disable_path(struct list_head *path);
 int coresight_enable_path(struct list_head *path);
+struct coresight_device *coresight_get_sink(struct list_head *path);
 struct list_head *coresight_build_path(struct coresight_device *csdev);
 void coresight_release_path(struct list_head *path);
 
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index f26589effb70..2ed48545df26 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -321,6 +321,21 @@ err:
 	goto out;
 }
 
+struct coresight_device *coresight_get_sink(struct list_head *path)
+{
+	struct coresight_device *csdev;
+
+	if (!path)
+		return NULL;
+
+	csdev = list_last_entry(path, struct coresight_node, link)->csdev;
+	if (csdev->type != CORESIGHT_DEV_TYPE_SINK &&
+	    csdev->type != CORESIGHT_DEV_TYPE_LINKSINK)
+		return NULL;
+
+	return csdev;
+}
+
 /**
  * _coresight_build_path - recursively build a path from a @csdev to a sink.
  * @csdev:	The device to start from.
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:44 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:44 -0700
Subject: [PATCH 02/21] coresight: etm4x: Check every parameter used by
 dma_xx_coherent.
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-3-git-send-email-mathieu.poirier@linaro.org>

From: Eric Long <eric.long at linaro.org>

The dma_alloc_coherent return an "void *" not an "void __iomen *".
It uses the wrong parameters when calls dma_free_coherent function.

The sparse tool output logs as the following:
coresight-tmc.c:199:23:    expected void *<noident>
coresight-tmc.c:199:23:    got void [noderef] <asn:2>*vaddr
coresight-tmc.c:336:30: warning: incorrect type in assignment
(different address spaces)
coresight-tmc.c:336:30:    expected char *buf
coresight-tmc.c:336:30:    got void [noderef] <asn:2>*
coresight-tmc.c:769:50: warning: incorrect type in argument 4
(different base types)
coresight-tmc.c:769:50:    expected unsigned long long
[unsigned] [usertype] dma_handle
coresight-tmc.c:769:50:    got restricted gfp_t

Signed-off-by: Eric Long <eric.long at linaro.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-tmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
index 570d96815f78..c4fa70ed14ce 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -124,7 +124,7 @@ struct tmc_drvdata {
 	bool			reading;
 	char			*buf;
 	dma_addr_t		paddr;
-	void __iomem		*vaddr;
+	void			*vaddr;
 	u32			size;
 	bool			enable;
 	enum tmc_config_type	config_type;
@@ -766,7 +766,7 @@ err_misc_register:
 err_devm_kzalloc:
 	if (drvdata->config_type == TMC_CONFIG_TYPE_ETR)
 		dma_free_coherent(dev, drvdata->size,
-				&drvdata->paddr, GFP_KERNEL);
+				drvdata->vaddr, drvdata->paddr);
 	return ret;
 }
 
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:53 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:53 -0700
Subject: [PATCH 11/21] coresight: etm3x: set progbit to stop trace collection
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-12-git-send-email-mathieu.poirier@linaro.org>

There is no need to use the event enable's "always false" event to
stop trace collection.  For that purpose setting the programming bit
(ETMCR:10) is enough.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm3x.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index e16501b41ed8..447459969cb5 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -398,9 +398,6 @@ static void etm_disable_hw(void *info)
 	CS_UNLOCK(drvdata->base);
 	etm_set_prog(drvdata);
 
-	/* Program trace enable to low by using always false event */
-	etm_writel(drvdata, ETM_HARD_WIRE_RES_A | ETM_EVENT_NOT_A, ETMTEEVR);
-
 	/* Read back sequencer and counters for post trace analysis */
 	config->seq_curr_state = (etm_readl(drvdata, ETMSQR) & ETM_SQR_MASK);
 
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:48 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:48 -0700
Subject: [PATCH 06/21] coresight: etm3x: moving etm_readl/writel to header file
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-7-git-send-email-mathieu.poirier@linaro.org>

Moving functions etm_readl/writel to file "coresight-etm.h"
so that the main ETM3x driver can be split in more than one
file.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm.h   | 29 +++++++++++++++++++++++++++
 drivers/hwtracing/coresight/coresight-etm3x.c | 29 ---------------------------
 2 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
index b4481eb29304..34f7db881fa7 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -251,4 +251,33 @@ enum etm_addr_type {
 	ETM_ADDR_TYPE_START,
 	ETM_ADDR_TYPE_STOP,
 };
+
+static inline void etm_writel(struct etm_drvdata *drvdata,
+			      u32 val, u32 off)
+{
+	if (drvdata->use_cp14) {
+		if (etm_writel_cp14(off, val)) {
+			dev_err(drvdata->dev,
+				"invalid CP14 access to ETM reg: %#x", off);
+		}
+	} else {
+		writel_relaxed(val, drvdata->base + off);
+	}
+}
+
+static inline unsigned int etm_readl(struct etm_drvdata *drvdata, u32 off)
+{
+	u32 val;
+
+	if (drvdata->use_cp14) {
+		if (etm_readl_cp14(off, &val)) {
+			dev_err(drvdata->dev,
+				"invalid CP14 access to ETM reg: %#x", off);
+		}
+	} else {
+		val = readl_relaxed(drvdata->base + off);
+	}
+
+	return val;
+}
 #endif
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index fe6791e0c66c..d53440e9af6f 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -42,35 +42,6 @@ module_param_named(boot_enable, boot_enable, int, S_IRUGO);
 static int etm_count;
 static struct etm_drvdata *etmdrvdata[NR_CPUS];
 
-static inline void etm_writel(struct etm_drvdata *drvdata,
-			      u32 val, u32 off)
-{
-	if (drvdata->use_cp14) {
-		if (etm_writel_cp14(off, val)) {
-			dev_err(drvdata->dev,
-				"invalid CP14 access to ETM reg: %#x", off);
-		}
-	} else {
-		writel_relaxed(val, drvdata->base + off);
-	}
-}
-
-static inline unsigned int etm_readl(struct etm_drvdata *drvdata, u32 off)
-{
-	u32 val;
-
-	if (drvdata->use_cp14) {
-		if (etm_readl_cp14(off, &val)) {
-			dev_err(drvdata->dev,
-				"invalid CP14 access to ETM reg: %#x", off);
-		}
-	} else {
-		val = readl_relaxed(drvdata->base + off);
-	}
-
-	return val;
-}
-
 /*
  * Memory mapped writes to clear os lock are not supported on some processors
  * and OS lock must be unlocked before any memory mapped access on such
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:45 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:45 -0700
Subject: [PATCH 03/21] coresight: associating path with session rather than
 tracer
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-4-git-send-email-mathieu.poirier@linaro.org>

When using the Coresight framework from the sysFS interface a
tracer is always handling a single session and as such, a path
can be associated with a tracer.  But when supporting multiple
session per tracer there is no guarantee that sessions will always
have the same path from source to sink.

This patch is removing the automatic association between path and
tracers.  The building of a path and enablement of the components
in the path are decoupled, allowing for the association of a path
with a session rather than a tracer.

To keep backward functionality with the current sysFS access methods
a per-cpu place holder is used to keep a handle on the path built when
tracers are enabled.  Lastly APIs to build paths and enable tracers are
made public so that other subsystem can interact with the Coresight
framework.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-priv.h |   5 +
 drivers/hwtracing/coresight/coresight.c      | 296 ++++++++++++++++++---------
 include/linux/coresight.h                    |   2 -
 3 files changed, 206 insertions(+), 97 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 62fcd98cc7cf..7b193a34d709 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -52,6 +52,11 @@ static inline void CS_UNLOCK(void __iomem *addr)
 	} while (0);
 }
 
+void coresight_disable_path(struct list_head *path);
+int coresight_enable_path(struct list_head *path);
+struct list_head *coresight_build_path(struct coresight_device *csdev);
+void coresight_release_path(struct list_head *path);
+
 #ifdef CONFIG_CORESIGHT_SOURCE_ETM3X
 extern int etm_readl_cp14(u32 off, unsigned int *val);
 extern int etm_writel_cp14(u32 off, u32 val);
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 7e6e9ff27dd1..f26589effb70 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -29,6 +29,22 @@
 
 static DEFINE_MUTEX(coresight_mutex);
 
+/**
+ * struct coresight_node - elements of a path, from source to sink
+ * @csdev:	Address of an element.
+ * @link:	hook to the list.
+ */
+struct coresight_node {
+	struct coresight_device *csdev;
+	struct list_head link;
+};
+
+/*
+ * When operating Coresight drivers from the sysFS interface, only a single
+ * path can exist from a tracer (associated to a CPU) to a sink.
+ */
+static DEFINE_PER_CPU(struct list_head *, sysfs_path);
+
 static int coresight_id_match(struct device *dev, void *data)
 {
 	int trace_id, i_trace_id;
@@ -68,15 +84,12 @@ static int coresight_source_is_unique(struct coresight_device *csdev)
 				 csdev, coresight_id_match);
 }
 
-static int coresight_find_link_inport(struct coresight_device *csdev)
+static int coresight_find_link_inport(struct coresight_device *csdev,
+				      struct coresight_device *parent)
 {
 	int i;
-	struct coresight_device *parent;
 	struct coresight_connection *conn;
 
-	parent = container_of(csdev->path_link.next,
-			      struct coresight_device, path_link);
-
 	for (i = 0; i < parent->nr_outport; i++) {
 		conn = &parent->conns[i];
 		if (conn->child_dev == csdev)
@@ -89,15 +102,12 @@ static int coresight_find_link_inport(struct coresight_device *csdev)
 	return 0;
 }
 
-static int coresight_find_link_outport(struct coresight_device *csdev)
+static int coresight_find_link_outport(struct coresight_device *csdev,
+				       struct coresight_device *child)
 {
 	int i;
-	struct coresight_device *child;
 	struct coresight_connection *conn;
 
-	child = container_of(csdev->path_link.prev,
-			     struct coresight_device, path_link);
-
 	for (i = 0; i < csdev->nr_outport; i++) {
 		conn = &csdev->conns[i];
 		if (conn->child_dev == child)
@@ -138,14 +148,19 @@ static void coresight_disable_sink(struct coresight_device *csdev)
 	}
 }
 
-static int coresight_enable_link(struct coresight_device *csdev)
+static int coresight_enable_link(struct coresight_device *csdev,
+				 struct coresight_device *parent,
+				 struct coresight_device *child)
 {
 	int ret;
 	int link_subtype;
 	int refport, inport, outport;
 
-	inport = coresight_find_link_inport(csdev);
-	outport = coresight_find_link_outport(csdev);
+	if (!parent || !child)
+		return -EINVAL;
+
+	inport = coresight_find_link_inport(csdev, parent);
+	outport = coresight_find_link_outport(csdev, child);
 	link_subtype = csdev->subtype.link_subtype;
 
 	if (link_subtype == CORESIGHT_DEV_SUBTYPE_LINK_MERG)
@@ -168,14 +183,19 @@ static int coresight_enable_link(struct coresight_device *csdev)
 	return 0;
 }
 
-static void coresight_disable_link(struct coresight_device *csdev)
+static void coresight_disable_link(struct coresight_device *csdev,
+				   struct coresight_device *parent,
+				   struct coresight_device *child)
 {
 	int i, nr_conns;
 	int link_subtype;
 	int refport, inport, outport;
 
-	inport = coresight_find_link_inport(csdev);
-	outport = coresight_find_link_outport(csdev);
+	if (!parent || !child)
+		return;
+
+	inport = coresight_find_link_inport(csdev, parent);
+	outport = coresight_find_link_outport(csdev, child);
 	link_subtype = csdev->subtype.link_subtype;
 
 	if (link_subtype == CORESIGHT_DEV_SUBTYPE_LINK_MERG) {
@@ -235,109 +255,167 @@ static void coresight_disable_source(struct coresight_device *csdev)
 	}
 }
 
-static int coresight_enable_path(struct list_head *path)
+void coresight_disable_path(struct list_head *path)
 {
-	int ret = 0;
-	struct coresight_device *cd;
+	struct coresight_node *nd;
+	struct coresight_device *csdev, *parent, *child;
 
-	/*
-	 * At this point we have a full @path, from source to sink.  The
-	 * sink is the first entry and the source the last one.  Go through
-	 * all the components and enable them one by one.
-	 */
-	list_for_each_entry(cd, path, path_link) {
-		if (cd == list_first_entry(path, struct coresight_device,
-					   path_link)) {
-			ret = coresight_enable_sink(cd);
-		} else if (list_is_last(&cd->path_link, path)) {
-			/*
-			 * Don't enable the source just yet - this needs to
-			 * happen at the very end when all links and sink
-			 * along the path have been configured properly.
-			 */
-			;
-		} else {
-			ret = coresight_enable_link(cd);
+	list_for_each_entry(nd, path, link) {
+		csdev = nd->csdev;
+
+		switch (csdev->type) {
+		case CORESIGHT_DEV_TYPE_SINK:
+		case CORESIGHT_DEV_TYPE_LINKSINK:
+			coresight_disable_sink(csdev);
+			break;
+		case CORESIGHT_DEV_TYPE_SOURCE:
+			/* sources are disabled from either sysFS or Perf */
+			break;
+		case CORESIGHT_DEV_TYPE_LINK:
+			parent = list_prev_entry(nd, link)->csdev;
+			child = list_next_entry(nd, link)->csdev;
+			coresight_disable_link(csdev, parent, child);
+			break;
+		default:
+			break;
 		}
-		if (ret)
-			goto err;
 	}
+}
 
-	return 0;
-err:
-	list_for_each_entry_continue_reverse(cd, path, path_link) {
-		if (cd == list_first_entry(path, struct coresight_device,
-					   path_link)) {
-			coresight_disable_sink(cd);
-		} else if (list_is_last(&cd->path_link, path)) {
-			;
-		} else {
-			coresight_disable_link(cd);
+int coresight_enable_path(struct list_head *path)
+{
+
+	int ret = 0;
+	struct coresight_node *nd;
+	struct coresight_device *csdev, *parent, *child;
+
+	list_for_each_entry_reverse(nd, path, link) {
+		csdev = nd->csdev;
+
+		switch (csdev->type) {
+		case CORESIGHT_DEV_TYPE_SINK:
+		case CORESIGHT_DEV_TYPE_LINKSINK:
+			ret = coresight_enable_sink(csdev);
+			if (ret)
+				goto err;
+			break;
+		case CORESIGHT_DEV_TYPE_SOURCE:
+			/* sources are enabled from either sysFS or Perf */
+			break;
+		case CORESIGHT_DEV_TYPE_LINK:
+			parent = list_prev_entry(nd, link)->csdev;
+			child = list_next_entry(nd, link)->csdev;
+			ret = coresight_enable_link(csdev, parent, child);
+			if (ret)
+				goto err;
+			break;
+		default:
+			goto err;
 		}
 	}
 
+out:
 	return ret;
+err:
+	coresight_disable_path(path);
+	goto out;
 }
 
-static int coresight_disable_path(struct list_head *path)
+/**
+ * _coresight_build_path - recursively build a path from a @csdev to a sink.
+ * @csdev:	The device to start from.
+ * @path:	The list to add devices to.
+ *
+ * The tree of Coresight device is traversed until an activated sink is
+ * found.  From there the sink is added to the list along with all the
+ * devices that led to that point - the end result is a list from source
+ * to sink. In that list the source is the first device and the sink the
+ * last one.
+ */
+static int _coresight_build_path(struct coresight_device *csdev,
+				 struct list_head *path)
 {
-	struct coresight_device *cd;
+	int i;
+	bool found = false;
+	struct coresight_node *node;
+	struct coresight_connection *conn;
 
-	list_for_each_entry_reverse(cd, path, path_link) {
-		if (cd == list_first_entry(path, struct coresight_device,
-					   path_link)) {
-			coresight_disable_sink(cd);
-		} else if (list_is_last(&cd->path_link, path)) {
-			/*
-			 * The source has already been stopped, no need
-			 * to do it again here.
-			 */
-			;
-		} else {
-			coresight_disable_link(cd);
+	/* An activated sink has been found.  Enqueue the element */
+	if ((csdev->type == CORESIGHT_DEV_TYPE_SINK ||
+	     csdev->type == CORESIGHT_DEV_TYPE_LINKSINK) && csdev->activated)
+		goto out;
+
+	/* Not a sink - recursively explore each port found on this element */
+	for (i = 0; i < csdev->nr_outport; i++) {
+		conn = &csdev->conns[i];
+		if (_coresight_build_path(conn->child_dev, path) == 0) {
+			found = true;
+			break;
 		}
 	}
 
+	if (!found)
+		return -ENODEV;
+
+out:
+	/*
+	 * A path from this element to a sink has been found.  The elements
+	 * leading to the sink are already enqueued, all that is left to do
+	 * is add a node for this element.
+	 */
+	node = kzalloc(sizeof(struct coresight_node), GFP_KERNEL);
+	if (!node)
+		return -ENOMEM;
+
+	node->csdev = csdev;
+	list_add(&node->link, path);
+
 	return 0;
 }
 
-static int coresight_build_paths(struct coresight_device *csdev,
-				 struct list_head *path,
-				 bool enable)
+struct list_head *coresight_build_path(struct coresight_device *csdev)
 {
-	int i, ret = -EINVAL;
-	struct coresight_connection *conn;
+	struct list_head *path;
 
-	list_add(&csdev->path_link, path);
+	path = kzalloc(sizeof(struct list_head), GFP_KERNEL);
+	if (!path)
+		return NULL;
 
-	if ((csdev->type == CORESIGHT_DEV_TYPE_SINK ||
-	    csdev->type == CORESIGHT_DEV_TYPE_LINKSINK) &&
-	    csdev->activated) {
-		if (enable)
-			ret = coresight_enable_path(path);
-		else
-			ret = coresight_disable_path(path);
-	} else {
-		for (i = 0; i < csdev->nr_outport; i++) {
-			conn = &csdev->conns[i];
-			if (coresight_build_paths(conn->child_dev,
-						    path, enable) == 0)
-				ret = 0;
-		}
+	INIT_LIST_HEAD(path);
+
+	if (_coresight_build_path(csdev, path)) {
+		kfree(path);
+		path = NULL;
 	}
 
-	if (list_first_entry(path, struct coresight_device, path_link) != csdev)
-		dev_err(&csdev->dev, "wrong device in %s\n", __func__);
+	return path;
+}
 
-	list_del(&csdev->path_link);
+/**
+ * coresight_release_path - release a previously built path.
+ * @path:	the path to release.
+ *
+ * Go through all the elements of a path and 1) removed it from the list and
+ * 2) free the memory allocated for each node.
+ */
+void coresight_release_path(struct list_head *path)
+{
+	struct coresight_node *nd, *next;
 
-	return ret;
+	list_for_each_entry_safe(nd, next, path, link) {
+		list_del(&nd->link);
+		kfree(nd);
+	}
+
+	kfree(path);
+	path = NULL;
 }
 
 int coresight_enable(struct coresight_device *csdev)
 {
 	int ret = 0;
-	LIST_HEAD(path);
+	int cpu;
+	struct list_head *path;
 
 	mutex_lock(&coresight_mutex);
 	if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE) {
@@ -348,22 +426,47 @@ int coresight_enable(struct coresight_device *csdev)
 	if (csdev->enable)
 		goto out;
 
-	if (coresight_build_paths(csdev, &path, true)) {
-		dev_err(&csdev->dev, "building path(s) failed\n");
+	path = coresight_build_path(csdev);
+	if (!path) {
+		pr_err("building path(s) failed\n");
 		goto out;
 	}
 
-	if (coresight_enable_source(csdev))
-		dev_err(&csdev->dev, "source enable failed\n");
+	ret = coresight_enable_path(path);
+	if (ret)
+		goto err_path;
+
+	ret = coresight_enable_source(csdev);
+	if (ret)
+		goto err_source;
+
+	/*
+	 * When working from sysFS it is important to keep track
+	 * of the paths that were created so that they can be
+	 * undone in 'coresight_disable()'.  Since there can only
+	 * be a single session per tracer (when working from sysFS)
+	 * a per-cpu variable will do just fine.
+	 */
+	cpu = source_ops(csdev)->cpu_id(csdev);
+	per_cpu(sysfs_path, cpu) = path;
+
 out:
 	mutex_unlock(&coresight_mutex);
 	return ret;
+
+err_source:
+	coresight_disable_path(path);
+
+err_path:
+	coresight_release_path(path);
+	goto out;
 }
 EXPORT_SYMBOL_GPL(coresight_enable);
 
 void coresight_disable(struct coresight_device *csdev)
 {
-	LIST_HEAD(path);
+	int cpu;
+	struct list_head *path;
 
 	mutex_lock(&coresight_mutex);
 	if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE) {
@@ -373,9 +476,12 @@ void coresight_disable(struct coresight_device *csdev)
 	if (!csdev->enable)
 		goto out;
 
+	cpu = source_ops(csdev)->cpu_id(csdev);
+	path = per_cpu(sysfs_path, cpu);
 	coresight_disable_source(csdev);
-	if (coresight_build_paths(csdev, &path, false))
-		dev_err(&csdev->dev, "releasing path(s) failed\n");
+	coresight_disable_path(path);
+	coresight_release_path(path);
+	per_cpu(sysfs_path, cpu) = NULL;
 
 out:
 	mutex_unlock(&coresight_mutex);
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index bf62b265bf52..851ecb22397e 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -152,7 +152,6 @@ struct coresight_connection {
 		by @coresight_ops.
  * @dev:	The device entity associated to this component.
  * @refcnt:	keep track of what is in use.
- * @path_link:	link of current component into the path being enabled.
  * @orphan:	true if the component has connections that haven't been linked.
  * @enable:	'true' if component is currently part of an active path.
  * @activated:	'true' only if a _sink_ has been activated.  A sink can be
@@ -168,7 +167,6 @@ struct coresight_device {
 	const struct coresight_ops *ops;
 	struct device dev;
 	atomic_t *refcnt;
-	struct list_head path_link;
 	bool orphan;
 	bool enable;	/* true only if configured as part of a path */
 	bool activated;	/* true only if a sink is part of a path */
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:47 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:47 -0700
Subject: [PATCH 05/21] coresight: moving PM runtime operations to core
 framework
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-6-git-send-email-mathieu.poirier@linaro.org>

Moving PM runtime operations in Coresight devices enable() and
disable() API to the framework core when a path is setup.  That
way the runtime core doesn't have to be involved everytime a
path is enabled.  It also avoids calling runtime PM operations
in IRQ context.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etb10.c           | 4 ----
 drivers/hwtracing/coresight/coresight-etm3x.c           | 3 ---
 drivers/hwtracing/coresight/coresight-etm4x.c           | 6 ------
 drivers/hwtracing/coresight/coresight-funnel.c          | 2 --
 drivers/hwtracing/coresight/coresight-replicator-qcom.c | 4 ----
 drivers/hwtracing/coresight/coresight-replicator.c      | 2 --
 drivers/hwtracing/coresight/coresight-tmc.c             | 5 -----
 drivers/hwtracing/coresight/coresight-tpiu.c            | 2 --
 drivers/hwtracing/coresight/coresight.c                 | 9 ++++++++-
 9 files changed, 8 insertions(+), 29 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 92969dae739d..917562ecf82a 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -137,8 +137,6 @@ static int etb_enable(struct coresight_device *csdev)
 	struct etb_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	unsigned long flags;
 
-	pm_runtime_get_sync(drvdata->dev);
-
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 	etb_enable_hw(drvdata);
 	drvdata->enable = true;
@@ -247,8 +245,6 @@ static void etb_disable(struct coresight_device *csdev)
 	drvdata->enable = false;
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
 
-	pm_runtime_put(drvdata->dev);
-
 	dev_info(drvdata->dev, "ETB disabled\n");
 }
 
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index aae80e14508d..fe6791e0c66c 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -349,7 +349,6 @@ static int etm_enable(struct coresight_device *csdev)
 	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	int ret;
 
-	pm_runtime_get_sync(csdev->dev.parent);
 	spin_lock(&drvdata->spinlock);
 
 	/*
@@ -373,7 +372,6 @@ static int etm_enable(struct coresight_device *csdev)
 	return 0;
 err:
 	spin_unlock(&drvdata->spinlock);
-	pm_runtime_put(csdev->dev.parent);
 	return ret;
 }
 
@@ -422,7 +420,6 @@ static void etm_disable(struct coresight_device *csdev)
 
 	spin_unlock(&drvdata->spinlock);
 	put_online_cpus();
-	pm_runtime_put(csdev->dev.parent);
 
 	dev_info(drvdata->dev, "ETM tracing disabled\n");
 }
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index d6a92c6d3a66..c2f518fbc9a8 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -79,7 +79,6 @@ static int etm4_trace_id(struct coresight_device *csdev)
 	if (!drvdata->enable)
 		return drvdata->trcid;
 
-	pm_runtime_get_sync(drvdata->dev);
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 
 	CS_UNLOCK(drvdata->base);
@@ -88,7 +87,6 @@ static int etm4_trace_id(struct coresight_device *csdev)
 	CS_LOCK(drvdata->base);
 
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
-	pm_runtime_put(drvdata->dev);
 
 	return trace_id;
 }
@@ -194,7 +192,6 @@ static int etm4_enable(struct coresight_device *csdev)
 	struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	int ret;
 
-	pm_runtime_get_sync(drvdata->dev);
 	spin_lock(&drvdata->spinlock);
 
 	/*
@@ -214,7 +211,6 @@ static int etm4_enable(struct coresight_device *csdev)
 	return 0;
 err:
 	spin_unlock(&drvdata->spinlock);
-	pm_runtime_put(drvdata->dev);
 	return ret;
 }
 
@@ -263,8 +259,6 @@ static void etm4_disable(struct coresight_device *csdev)
 	spin_unlock(&drvdata->spinlock);
 	put_online_cpus();
 
-	pm_runtime_put(drvdata->dev);
-
 	dev_info(drvdata->dev, "ETM tracing disabled\n");
 }
 
diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c
index 25e8ea140a09..fb2c679fbc44 100644
--- a/drivers/hwtracing/coresight/coresight-funnel.c
+++ b/drivers/hwtracing/coresight/coresight-funnel.c
@@ -69,7 +69,6 @@ static int funnel_enable(struct coresight_device *csdev, int inport,
 {
 	struct funnel_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
-	pm_runtime_get_sync(drvdata->dev);
 	funnel_enable_hw(drvdata, inport);
 
 	dev_info(drvdata->dev, "FUNNEL inport %d enabled\n", inport);
@@ -95,7 +94,6 @@ static void funnel_disable(struct coresight_device *csdev, int inport,
 	struct funnel_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
 	funnel_disable_hw(drvdata, inport);
-	pm_runtime_put(drvdata->dev);
 
 	dev_info(drvdata->dev, "FUNNEL inport %d disabled\n", inport);
 }
diff --git a/drivers/hwtracing/coresight/coresight-replicator-qcom.c b/drivers/hwtracing/coresight/coresight-replicator-qcom.c
index 444815179460..286f90b50989 100644
--- a/drivers/hwtracing/coresight/coresight-replicator-qcom.c
+++ b/drivers/hwtracing/coresight/coresight-replicator-qcom.c
@@ -48,8 +48,6 @@ static int replicator_enable(struct coresight_device *csdev, int inport,
 {
 	struct replicator_state *drvdata = dev_get_drvdata(csdev->dev.parent);
 
-	pm_runtime_get_sync(drvdata->dev);
-
 	CS_UNLOCK(drvdata->base);
 
 	/*
@@ -86,8 +84,6 @@ static void replicator_disable(struct coresight_device *csdev, int inport,
 
 	CS_LOCK(drvdata->base);
 
-	pm_runtime_put(drvdata->dev);
-
 	dev_info(drvdata->dev, "REPLICATOR disabled\n");
 }
 
diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
index b77d700a3f0e..0ce98903992c 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -41,7 +41,6 @@ static int replicator_enable(struct coresight_device *csdev, int inport,
 {
 	struct replicator_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
-	pm_runtime_get_sync(drvdata->dev);
 	dev_info(drvdata->dev, "REPLICATOR enabled\n");
 	return 0;
 }
@@ -51,7 +50,6 @@ static void replicator_disable(struct coresight_device *csdev, int inport,
 {
 	struct replicator_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
-	pm_runtime_put(drvdata->dev);
 	dev_info(drvdata->dev, "REPLICATOR disabled\n");
 }
 
diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
index c4fa70ed14ce..b526396d80b6 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -242,12 +242,9 @@ static int tmc_enable(struct tmc_drvdata *drvdata, enum tmc_mode mode)
 {
 	unsigned long flags;
 
-	pm_runtime_get_sync(drvdata->dev);
-
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 	if (drvdata->reading) {
 		spin_unlock_irqrestore(&drvdata->spinlock, flags);
-		pm_runtime_put(drvdata->dev);
 		return -EBUSY;
 	}
 
@@ -381,8 +378,6 @@ out:
 	drvdata->enable = false;
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
 
-	pm_runtime_put(drvdata->dev);
-
 	dev_info(drvdata->dev, "TMC disabled\n");
 }
 
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
index ca50e73d9df7..0d8fce651ff7 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -74,7 +74,6 @@ static int tpiu_enable(struct coresight_device *csdev)
 {
 	struct tpiu_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
-	pm_runtime_get_sync(csdev->dev.parent);
 	tpiu_enable_hw(drvdata);
 
 	dev_info(drvdata->dev, "TPIU enabled\n");
@@ -98,7 +97,6 @@ static void tpiu_disable(struct coresight_device *csdev)
 	struct tpiu_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
 	tpiu_disable_hw(drvdata);
-	pm_runtime_put(csdev->dev.parent);
 
 	dev_info(drvdata->dev, "TPIU disabled\n");
 }
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 2ed48545df26..6b44928c1076 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -24,6 +24,7 @@
 #include <linux/coresight.h>
 #include <linux/of_platform.h>
 #include <linux/delay.h>
+#include <linux/pm_runtime.h>
 
 #include "coresight-priv.h"
 
@@ -376,7 +377,8 @@ out:
 	/*
 	 * A path from this element to a sink has been found.  The elements
 	 * leading to the sink are already enqueued, all that is left to do
-	 * is add a node for this element.
+	 * is tell the PM runtime core we need this element and add a node
+	 * for it.
 	 */
 	node = kzalloc(sizeof(struct coresight_node), GFP_KERNEL);
 	if (!node)
@@ -384,6 +386,7 @@ out:
 
 	node->csdev = csdev;
 	list_add(&node->link, path);
+	pm_runtime_get_sync(csdev->dev.parent);
 
 	return 0;
 }
@@ -415,9 +418,13 @@ struct list_head *coresight_build_path(struct coresight_device *csdev)
  */
 void coresight_release_path(struct list_head *path)
 {
+	struct coresight_device *csdev;
 	struct coresight_node *nd, *next;
 
 	list_for_each_entry_safe(nd, next, path, link) {
+		csdev = nd->csdev;
+
+		pm_runtime_put_sync(csdev->dev.parent);
 		list_del(&nd->link);
 		kfree(nd);
 	}
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:50 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:50 -0700
Subject: [PATCH 08/21] coresight: etm3x: unlocking tracers in default arch init
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-9-git-send-email-mathieu.poirier@linaro.org>

Calling function 'smp_call_function_single()' to unlock a
tracer and calling it again right after to perform the
default initialisation doesn't make sense.

Moving 'etm_os_unlock()' just before making the default
initialisation results in the same outcome while saving
one call to 'smp_call_function_single()'.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm3x.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 6ea35b350958..f2c74bb56993 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -47,11 +47,11 @@ static struct etm_drvdata *etmdrvdata[NR_CPUS];
  * and OS lock must be unlocked before any memory mapped access on such
  * processors, otherwise memory mapped reads/writes will be invalid.
  */
-static void etm_os_unlock(void *info)
+static void etm_os_unlock(struct etm_drvdata *drvdata)
 {
-	struct etm_drvdata *drvdata = (struct etm_drvdata *)info;
 	/* Writing any value to ETMOSLAR unlocks the trace registers */
 	etm_writel(drvdata, 0x0, ETMOSLAR);
+	drvdata->os_unlock = true;
 	isb();
 }
 
@@ -483,6 +483,9 @@ static void etm_init_arch_data(void *info)
 	u32 etmccr;
 	struct etm_drvdata *drvdata = info;
 
+	/* Make sure all registers are accessible */
+	etm_os_unlock(drvdata);
+
 	CS_UNLOCK(drvdata->base);
 
 	/* First dummy read */
@@ -607,9 +610,6 @@ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
 	get_online_cpus();
 	etmdrvdata[drvdata->cpu] = drvdata;
 
-	if (!smp_call_function_single(drvdata->cpu, etm_os_unlock, drvdata, 1))
-		drvdata->os_unlock = true;
-
 	if (smp_call_function_single(drvdata->cpu,
 				     etm_init_arch_data,  drvdata, 1))
 		dev_err(dev, "ETM arch init failed\n");
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:54 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:54 -0700
Subject: [PATCH 12/21] coresight: etm3x: changing default trace configuration
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-13-git-send-email-mathieu.poirier@linaro.org>

Changing default configuration to include the entire address
range rather than just the kernel.  That way traces are more
inclusive and it is easier to narrow down if needed.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm.h   |  2 ++
 drivers/hwtracing/coresight/coresight-etm3x.c | 29 ++++++++++++---------------
 2 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
index 5b29d5540fe5..44585d4adb26 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -146,6 +146,7 @@
  * @startstop_ctrl: setting for register ETMTSSCR.
  * @enable_event: setting for register ETMTEEVR.
  * @enable_ctrl1: setting for register ETMTECR1.
+ * @enable_ctrl2: setting for register ETMTECR2.
  * @fifofull_level: setting for register ETMFFLR.
  * @addr_idx:	index for the address comparator selection.
  * @addr_val:	value for address comparator register.
@@ -179,6 +180,7 @@ struct etm_config {
 	u32				startstop_ctrl;
 	u32				enable_event;
 	u32				enable_ctrl1;
+	u32				enable_ctrl2;
 	u32				fifofull_level;
 	u8				addr_idx;
 	u32				addr_val[ETM_MAX_ADDR_CMP];
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 447459969cb5..92139674bea4 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -579,26 +579,23 @@ static void etm_init_arch_data(void *info)
 
 static void etm_init_default_data(struct etm_config *config)
 {
-	u32 flags = (1 << 0 | /* instruction execute*/
-		     3 << 3 | /* ARM instruction */
-		     0 << 5 | /* No data value comparison */
-		     0 << 7 | /* No exact mach */
-		     0 << 8 | /* Ignore context ID */
-		     0 << 10); /* Security ignored */
-
 	if (WARN_ON_ONCE(!config))
 		return;
 
-	config->ctrl = (ETMCR_CYC_ACC | ETMCR_TIMESTAMP_EN);
-	config->enable_ctrl1 = ETMTECR1_ADDR_COMP_1;
-	config->addr_val[0] = (u32) _stext;
-	config->addr_val[1] = (u32) _etext;
-	config->addr_acctype[0] = flags;
-	config->addr_acctype[1] = flags;
-	config->addr_type[0] = ETM_ADDR_TYPE_RANGE;
-	config->addr_type[1] = ETM_ADDR_TYPE_RANGE;
-
 	etm_set_default(config);
+
+	/*
+	 * Taken verbatim from the TRM:
+	 *
+	 * To trace all memory:
+	 *  set bit [24] in register 0x009, the ETMTECR1, to 1
+	 *  set all other bits in register 0x009, the ETMTECR1, to 0
+	 *  set all bits in register 0x007, the ETMTECR2, to 0
+	 *  set register 0x008, the ETMTEEVR, to 0x6F (TRUE).
+	 */
+	config->enable_ctrl1 = BIT(24);
+	config->enable_ctrl2 = 0x0;
+	config->enable_event = ETM_HARD_WIRE_RES_A;
 }
 
 static void etm_init_trace_id(struct etm_drvdata *drvdata)
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:55 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:55 -0700
Subject: [PATCH 13/21] coresight: etm3x: consolidating initial config
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-14-git-send-email-mathieu.poirier@linaro.org>

There is really no point in having two functions to take care
of doing the initial tracer configuration.  As such moving
everything to 'etm_set_default()'.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm3x.c | 37 ++++++++++-----------------
 1 file changed, 14 insertions(+), 23 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 92139674bea4..34a69583ccbc 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -41,7 +41,6 @@ module_param_named(boot_enable, boot_enable, int, S_IRUGO);
 /* The number of ETM/PTM currently registered */
 static int etm_count;
 static struct etm_drvdata *etmdrvdata[NR_CPUS];
-static void etm_init_default_data(struct etm_config *config);
 
 /*
  * Memory mapped writes to clear os lock are not supported on some processors
@@ -194,6 +193,19 @@ void etm_set_default(struct etm_config *config)
 	if (WARN_ON_ONCE(!config))
 		return;
 
+	/*
+	 * Taken verbatim from the TRM:
+	 *
+	 * To trace all memory:
+	 *  set bit [24] in register 0x009, the ETMTECR1, to 1
+	 *  set all other bits in register 0x009, the ETMTECR1, to 0
+	 *  set all bits in register 0x007, the ETMTECR2, to 0
+	 *  set register 0x008, the ETMTEEVR, to 0x6F (TRUE).
+	 */
+	config->enable_ctrl1 = BIT(24);
+	config->enable_ctrl2 = 0x0;
+	config->enable_event = ETM_HARD_WIRE_RES_A;
+
 	config->trigger_event = ETM_DEFAULT_EVENT_VAL;
 	config->enable_event = ETM_HARD_WIRE_RES_A;
 
@@ -577,27 +589,6 @@ static void etm_init_arch_data(void *info)
 	CS_LOCK(drvdata->base);
 }
 
-static void etm_init_default_data(struct etm_config *config)
-{
-	if (WARN_ON_ONCE(!config))
-		return;
-
-	etm_set_default(config);
-
-	/*
-	 * Taken verbatim from the TRM:
-	 *
-	 * To trace all memory:
-	 *  set bit [24] in register 0x009, the ETMTECR1, to 1
-	 *  set all other bits in register 0x009, the ETMTECR1, to 0
-	 *  set all bits in register 0x007, the ETMTECR2, to 0
-	 *  set register 0x008, the ETMTEEVR, to 0x6F (TRUE).
-	 */
-	config->enable_ctrl1 = BIT(24);
-	config->enable_ctrl2 = 0x0;
-	config->enable_event = ETM_HARD_WIRE_RES_A;
-}
-
 static void etm_init_trace_id(struct etm_drvdata *drvdata)
 {
 	/*
@@ -674,7 +665,7 @@ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
 	}
 
 	etm_init_trace_id(drvdata);
-	etm_init_default_data(&drvdata->config);
+	etm_set_default(&drvdata->config);
 
 	desc->type = CORESIGHT_DEV_TYPE_SOURCE;
 	desc->subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_PROC;
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:52 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:52 -0700
Subject: [PATCH 10/21] coresight: etm3x: adding operation mode for etm_enable()
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-11-git-send-email-mathieu.poirier@linaro.org>

Adding a new mode to source API enable() in order to
distinguish where the request comes from.  That way it is
possible to perform different operations based on where
the request was issued from.

The ETM4x driver is also modified to keep in sync with the
new interface.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm.h        |  5 +-
 .../hwtracing/coresight/coresight-etm3x-sysfs.c    |  4 +-
 drivers/hwtracing/coresight/coresight-etm3x.c      | 68 +++++++++++++++++++---
 drivers/hwtracing/coresight/coresight-etm4x.c      |  2 +-
 drivers/hwtracing/coresight/coresight-priv.h       |  6 ++
 drivers/hwtracing/coresight/coresight.c            |  6 +-
 include/linux/coresight.h                          |  2 +-
 7 files changed, 76 insertions(+), 17 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
index 371fb7d2e829..5b29d5540fe5 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -13,6 +13,7 @@
 #ifndef _CORESIGHT_CORESIGHT_ETM_H
 #define _CORESIGHT_CORESIGHT_ETM_H
 
+#include <asm/local.h>
 #include <linux/spinlock.h>
 #include "coresight-priv.h"
 
@@ -214,7 +215,7 @@ struct etm_config {
  * @port_size:	port size as reported by ETMCR bit 4-6 and 21.
  * @arch:	ETM/PTM version number.
  * @use_cpu14:	true if management registers need to be accessed via CP14.
- * @enable:	is this ETM/PTM currently tracing.
+ * @mode:	this tracer's mode, i.e sysFS, Perf or disabled.
  * @sticky_enable: true if ETM base configuration has been done.
  * @boot_enable:true if we should start tracing at boot time.
  * @os_unlock:	true if access to management registers is allowed.
@@ -238,7 +239,7 @@ struct etm_drvdata {
 	int				port_size;
 	u8				arch;
 	bool				use_cp14;
-	bool				enable;
+	local_t				mode;
 	bool				sticky_enable;
 	bool				boot_enable;
 	bool				os_unlock;
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
index 456df2378a6f..387c79fd9d5e 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
@@ -716,7 +716,7 @@ static ssize_t cntr_val_show(struct device *dev,
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
 	struct etm_config *config = &drvdata->config;
 
-	if (!drvdata->enable) {
+	if (!local_read(&drvdata->mode)) {
 		spin_lock(&drvdata->spinlock);
 		for (i = 0; i < drvdata->nr_cntr; i++)
 			ret += sprintf(buf, "counter %d: %x\n",
@@ -935,7 +935,7 @@ static ssize_t seq_curr_state_show(struct device *dev,
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
 	struct etm_config *config = &drvdata->config;
 
-	if (!drvdata->enable) {
+	if (!local_read(&drvdata->mode)) {
 		val = config->seq_curr_state;
 		goto out;
 	}
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 1952dc31fee4..e16501b41ed8 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -306,7 +306,7 @@ int etm_get_trace_id(struct etm_drvdata *drvdata)
 	if (!drvdata)
 		goto out;
 
-	if (!drvdata->enable)
+	if (!local_read(&drvdata->mode))
 		return drvdata->traceid;
 
 	pm_runtime_get_sync(drvdata->dev);
@@ -332,7 +332,7 @@ static int etm_trace_id(struct coresight_device *csdev)
 	return etm_get_trace_id(drvdata);
 }
 
-static int etm_enable(struct coresight_device *csdev)
+static int etm_enable_sysfs(struct coresight_device *csdev)
 {
 	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	int ret;
@@ -351,18 +351,44 @@ static int etm_enable(struct coresight_device *csdev)
 			goto err;
 	}
 
-	drvdata->enable = true;
 	drvdata->sticky_enable = true;
-
 	spin_unlock(&drvdata->spinlock);
 
 	dev_info(drvdata->dev, "ETM tracing enabled\n");
 	return 0;
+
 err:
 	spin_unlock(&drvdata->spinlock);
 	return ret;
 }
 
+static int etm_enable(struct coresight_device *csdev, u32 mode)
+{
+	int ret;
+	u32 val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	val = local_cmpxchg(&drvdata->mode, CS_MODE_DISABLED, mode);
+
+	/* Someone is already using the tracer */
+	if (val)
+		return -EBUSY;
+
+	switch (mode) {
+	case CS_MODE_SYSFS:
+		ret = etm_enable_sysfs(csdev);
+		break;
+	default:
+		ret = -EINVAL;
+	}
+
+	/* The tracer didn't start */
+	if (ret)
+		local_set(&drvdata->mode, CS_MODE_DISABLED);
+
+	return ret;
+}
+
 static void etm_disable_hw(void *info)
 {
 	int i;
@@ -387,7 +413,7 @@ static void etm_disable_hw(void *info)
 	dev_dbg(drvdata->dev, "cpu: %d disable smp call done\n", drvdata->cpu);
 }
 
-static void etm_disable(struct coresight_device *csdev)
+static void etm_disable_sysfs(struct coresight_device *csdev)
 {
 	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
@@ -405,7 +431,6 @@ static void etm_disable(struct coresight_device *csdev)
 	 * ensures that register writes occur when cpu is powered.
 	 */
 	smp_call_function_single(drvdata->cpu, etm_disable_hw, drvdata, 1);
-	drvdata->enable = false;
 
 	spin_unlock(&drvdata->spinlock);
 	put_online_cpus();
@@ -413,6 +438,33 @@ static void etm_disable(struct coresight_device *csdev)
 	dev_info(drvdata->dev, "ETM tracing disabled\n");
 }
 
+static void etm_disable(struct coresight_device *csdev)
+{
+	u32 mode;
+	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	/*
+	 * For as long as the tracer isn't disabled another entity can't
+	 * change its status.  As such we can read the status here without
+	 * fearing it will change under us.
+	 */
+	mode = local_read(&drvdata->mode);
+
+	switch (mode) {
+	case CS_MODE_DISABLED:
+		break;
+	case CS_MODE_SYSFS:
+		etm_disable_sysfs(csdev);
+		break;
+	default:
+		WARN_ON_ONCE(mode);
+		return;
+	}
+
+	if (mode)
+		local_set(&drvdata->mode, CS_MODE_DISABLED);
+}
+
 static const struct coresight_ops_source etm_source_ops = {
 	.cpu_id		= etm_cpu_id,
 	.trace_id	= etm_trace_id,
@@ -440,7 +492,7 @@ static int etm_cpu_callback(struct notifier_block *nfb, unsigned long action,
 			etmdrvdata[cpu]->os_unlock = true;
 		}
 
-		if (etmdrvdata[cpu]->enable)
+		if (local_read(&etmdrvdata[cpu]->mode))
 			etm_enable_hw(etmdrvdata[cpu]);
 		spin_unlock(&etmdrvdata[cpu]->spinlock);
 		break;
@@ -453,7 +505,7 @@ static int etm_cpu_callback(struct notifier_block *nfb, unsigned long action,
 
 	case CPU_DYING:
 		spin_lock(&etmdrvdata[cpu]->spinlock);
-		if (etmdrvdata[cpu]->enable)
+		if (local_read(&etmdrvdata[cpu]->mode))
 			etm_disable_hw(etmdrvdata[cpu]);
 		spin_unlock(&etmdrvdata[cpu]->spinlock);
 		break;
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index c2f518fbc9a8..0026092fec7f 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -187,7 +187,7 @@ static void etm4_enable_hw(void *info)
 	dev_dbg(drvdata->dev, "cpu: %d enable smp call done\n", drvdata->cpu);
 }
 
-static int etm4_enable(struct coresight_device *csdev)
+static int etm4_enable(struct coresight_device *csdev, u32 mode)
 {
 	struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	int ret;
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 14f245a2018d..ed116b303e87 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -34,6 +34,12 @@
 #define TIMEOUT_US		100
 #define BMVAL(val, lsb, msb)	((val & GENMASK(msb, lsb)) >> lsb)
 
+enum cs_mode {
+	CS_MODE_DISABLED,
+	CS_MODE_SYSFS,
+	CS_MODE_PERF,
+};
+
 static inline void CS_LOCK(void __iomem *addr)
 {
 	do {
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 6b44928c1076..b20afb709141 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -222,7 +222,7 @@ static void coresight_disable_link(struct coresight_device *csdev,
 	csdev->enable = false;
 }
 
-static int coresight_enable_source(struct coresight_device *csdev)
+static int coresight_enable_source(struct coresight_device *csdev, u32 mode)
 {
 	int ret;
 
@@ -234,7 +234,7 @@ static int coresight_enable_source(struct coresight_device *csdev)
 
 	if (!csdev->enable) {
 		if (source_ops(csdev)->enable) {
-			ret = source_ops(csdev)->enable(csdev);
+			ret = source_ops(csdev)->enable(csdev, mode);
 			if (ret)
 				return ret;
 		}
@@ -458,7 +458,7 @@ int coresight_enable(struct coresight_device *csdev)
 	if (ret)
 		goto err_path;
 
-	ret = coresight_enable_source(csdev);
+	ret = coresight_enable_source(csdev, CS_MODE_SYSFS);
 	if (ret)
 		goto err_source;
 
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 851ecb22397e..61dfb8d511ea 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -213,7 +213,7 @@ struct coresight_ops_link {
 struct coresight_ops_source {
 	int (*cpu_id)(struct coresight_device *csdev);
 	int (*trace_id)(struct coresight_device *csdev);
-	int (*enable)(struct coresight_device *csdev);
+	int (*enable)(struct coresight_device *csdev, u32 mode);
 	void (*disable)(struct coresight_device *csdev);
 };
 
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:56 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:56 -0700
Subject: [PATCH 14/21] coresight: etm3x: implementing user/kernel mode tracing
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-15-git-send-email-mathieu.poirier@linaro.org>

Adding new mode to limit tracing to kernel or user space.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm.h        |  6 ++-
 .../hwtracing/coresight/coresight-etm3x-sysfs.c    |  4 ++
 drivers/hwtracing/coresight/coresight-etm3x.c      | 63 ++++++++++++++++++++++
 drivers/hwtracing/coresight/coresight-priv.h       |  3 ++
 4 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
index 44585d4adb26..51597cb2c08a 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -110,7 +110,10 @@
 #define ETM_MODE_STALL		BIT(2)
 #define ETM_MODE_TIMESTAMP	BIT(3)
 #define ETM_MODE_CTXID		BIT(4)
-#define ETM_MODE_ALL		0x1f
+#define ETM_MODE_ALL		(ETM_MODE_EXCLUDE | ETM_MODE_CYCACC | \
+				 ETM_MODE_STALL | ETM_MODE_TIMESTAMP | \
+				 ETM_MODE_CTXID | ETM_MODE_EXCL_KERN | \
+				 ETM_MODE_EXCL_USER)
 
 #define ETM_SQR_MASK		0x3
 #define ETM_TRACEID_MASK	0x3f
@@ -296,5 +299,6 @@ static inline unsigned int etm_readl(struct etm_drvdata *drvdata, u32 off)
 extern const struct attribute_group *coresight_etm_groups[];
 int etm_get_trace_id(struct etm_drvdata *drvdata);
 void etm_set_default(struct etm_config *config);
+void etm_config_trace_mode(struct etm_config *config);
 struct etm_config *get_etm_config(struct etm_drvdata *drvdata);
 #endif
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
index 387c79fd9d5e..cbb4046c1070 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
@@ -162,6 +162,10 @@ static ssize_t mode_store(struct device *dev,
 		config->ctrl |= ETMCR_CTXID_SIZE;
 	else
 		config->ctrl &= ~ETMCR_CTXID_SIZE;
+
+	if (config->mode & (ETM_MODE_EXCL_KERN | ETM_MODE_EXCL_USER))
+		etm_config_trace_mode(config);
+
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 34a69583ccbc..c82d545e68ef 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -234,6 +234,69 @@ void etm_set_default(struct etm_config *config)
 	config->ctxid_mask = 0x0;
 }
 
+void etm_config_trace_mode(struct etm_config *config)
+{
+	u32 flags, mode;
+
+	mode = config->mode;
+
+	mode &= (ETM_MODE_EXCL_KERN | ETM_MODE_EXCL_USER);
+
+	/* excluding kernel AND user space doesn't make sense */
+	if (mode == (ETM_MODE_EXCL_KERN | ETM_MODE_EXCL_USER))
+		return;
+
+	/* nothing to do if neither flags are set */
+	if (!(mode & ETM_MODE_EXCL_KERN) && !(mode & ETM_MODE_EXCL_USER))
+		return;
+
+	flags = (1 << 0 |	/* instruction execute */
+		 3 << 3 |	/* ARM instruction */
+		 0 << 5 |	/* No data value comparison */
+		 0 << 7 |	/* No exact mach */
+		 0 << 8);	/* Ignore context ID */
+
+	/* No need to worry about single address comparators. */
+	config->enable_ctrl2 = 0x0;
+
+	/* Bit 0 is address range comparator 1 */
+	config->enable_ctrl1 = ETMTECR1_ADDR_COMP_1;
+
+	/*
+	 * On ETMv3.5:
+	 * ETMACTRn[13,11] == Non-secure state comparison control
+	 * ETMACTRn[12,10] == Secure state comparison control
+	 *
+	 * b00 == Match in all modes in this state
+	 * b01 == Do not match in any more in this state
+	 * b10 == Match in all modes excepts user mode in this state
+	 * b11 == Match only in user mode in this state
+	 */
+
+	/* Tracing in secure mode is not supported at this time */
+	flags |= (0 << 12 | 1 << 10);
+
+	if (mode & ETM_MODE_EXCL_USER) {
+		/* exclude user, match all modes except user mode */
+		flags |= (1 << 13 | 0 << 11);
+	} else {
+		/* exclude kernel, match only in user mode */
+		flags |= (1 << 13 | 1 << 11);
+	}
+
+	/*
+	 * The ETMEEVR register is already set to "hard wire A".  As such
+	 * all there is to do is setup an address comparator that spans
+	 * the entire address range and configure the state and mode bits.
+	 */
+	config->addr_val[0] = (u32) 0x0;
+	config->addr_val[1] = (u32) ~0x0;
+	config->addr_acctype[0] = flags;
+	config->addr_acctype[1] = flags;
+	config->addr_type[0] = ETM_ADDR_TYPE_RANGE;
+	config->addr_type[1] = ETM_ADDR_TYPE_RANGE;
+}
+
 static void etm_enable_hw(void *info)
 {
 	int i;
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index ed116b303e87..932f34a84d96 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -34,6 +34,9 @@
 #define TIMEOUT_US		100
 #define BMVAL(val, lsb, msb)	((val & GENMASK(msb, lsb)) >> lsb)
 
+#define ETM_MODE_EXCL_KERN	BIT(30)
+#define ETM_MODE_EXCL_USER	BIT(31)
+
 enum cs_mode {
 	CS_MODE_DISABLED,
 	CS_MODE_SYSFS,
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:52:00 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:52:00 -0700
Subject: [PATCH 18/21] coresight: etb10: implementing AUX API
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-19-git-send-email-mathieu.poirier@linaro.org>

Adding an ETB10 specific AUX area operations to be used
by the perf framework when events are initialised.

Part of this operation involves modeling the mmap'ed area
based on the specific ways a sink buffer gathers information.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etb10.c | 234 ++++++++++++++++++++++++++
 include/linux/coresight.h                     |  21 ++-
 2 files changed, 253 insertions(+), 2 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 79099f95ba3f..a2eb6bdeaafa 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -28,6 +28,11 @@
 #include <linux/coresight.h>
 #include <linux/amba/bus.h>
 #include <linux/clk.h>
+#include <linux/circ_buf.h>
+#include <linux/mm.h>
+#include <linux/perf_event.h>
+
+#include <asm/local.h>
 
 #include "coresight-priv.h"
 
@@ -65,6 +70,26 @@
 #define ETB_FRAME_SIZE_WORDS	4
 
 /**
+ * struct cs_buffer - keep track of a recording session' specifics
+ * @cur:	index of the current buffer
+ * @nr_pages:	max number of pages granted to us
+ * @offset:	offset within the current buffer
+ * @data_size:	how much we collected in this run
+ * @lost:	other than zero if we had a HW buffer wrap around
+ * @snapshot:	is this run in snapshot mode
+ * @data_pages:	a handle the ring buffer
+ */
+struct cs_buffers {
+	unsigned int		cur;
+	unsigned int		nr_pages;
+	unsigned long		offset;
+	local_t			data_size;
+	local_t			lost;
+	bool			snapshot;
+	void			**data_pages;
+};
+
+/**
  * struct etb_drvdata - specifics associated to an ETB component
  * @base:	memory mapped base address for this component.
  * @dev:	the device entity associated to this component.
@@ -265,9 +290,218 @@ static void etb_disable(struct coresight_device *csdev)
 	dev_info(drvdata->dev, "ETB disabled\n");
 }
 
+static void *etb_alloc_buffer(struct coresight_device *csdev, int cpu,
+			      void **pages, int nr_pages, bool overwrite)
+{
+	int node;
+	struct cs_buffers *buf;
+
+	if (cpu == -1)
+		cpu = smp_processor_id();
+	node = cpu_to_node(cpu);
+
+	buf = kzalloc_node(sizeof(struct cs_buffers), GFP_KERNEL, node);
+	if (!buf)
+		return NULL;
+
+	buf->snapshot = overwrite;
+	buf->nr_pages = nr_pages;
+	buf->data_pages = pages;
+
+	return buf;
+}
+
+static void etb_free_buffer(void *config)
+{
+	struct cs_buffers *buf = config;
+
+	kfree(buf);
+}
+
+static int etb_set_buffer(struct coresight_device *csdev,
+			  struct perf_output_handle *handle,
+			  void *sink_config)
+{
+	int ret = 0;
+	unsigned long head;
+	struct cs_buffers *buf = sink_config;
+
+	/* wrap head around to the amount of space we have */
+	head = handle->head & ((buf->nr_pages << PAGE_SHIFT) - 1);
+
+	/* find the page to write to */
+	buf->cur = head / PAGE_SIZE;
+
+	/* and offset within that page */
+	buf->offset = head % PAGE_SIZE;
+
+	local_set(&buf->data_size, 0);
+
+	return ret;
+}
+
+static unsigned long etb_reset_buffer(struct coresight_device *csdev,
+				      struct perf_output_handle *handle,
+				      void *sink_config, bool *lost)
+{
+	unsigned long size = 0;
+	struct cs_buffers *buf = sink_config;
+
+	if (buf) {
+		/*
+		 * In snapshot mode ->data_size holds the new address of the
+		 * ring buffer's head.  The size itself is the whole address
+		 * range since we want the latest information.
+		 */
+		if (buf->snapshot)
+			handle->head = local_xchg(&buf->data_size,
+						  buf->nr_pages << PAGE_SHIFT);
+
+		/*
+		 * Tell the tracer PMU how much we got in this run and if
+		 * something went wrong along the way.  Nobody else can use
+		 * this cs_buffers instance until we are done.  As such
+		 * resetting parameters here and squaring off with the ring
+		 * buffer API in the tracer PMU is fine.
+		 */
+		*lost = !!local_xchg(&buf->lost, 0);
+		size = local_xchg(&buf->data_size, 0);
+	}
+
+	return size;
+}
+
+static void etb_update_buffer(struct coresight_device *csdev,
+			      struct perf_output_handle *handle,
+			      void *sink_config)
+{
+	int i, cur;
+	u8 *buf_ptr;
+	u32 read_ptr, write_ptr, capacity;
+	u32 status, read_data, to_read;
+	unsigned long offset;
+	struct cs_buffers *buf = sink_config;
+	struct etb_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	if (!buf)
+		return;
+
+	capacity = drvdata->buffer_depth * ETB_FRAME_SIZE_WORDS;
+
+	CS_UNLOCK(drvdata->base);
+	etb_disable_hw(drvdata);
+
+	/* unit is in words, not bytes */
+	read_ptr = readl_relaxed(drvdata->base + ETB_RAM_READ_POINTER);
+	write_ptr = readl_relaxed(drvdata->base + ETB_RAM_WRITE_POINTER);
+
+	/*
+	 * Entries should be aligned to the frame size.  If they are not
+	 * go back to the last alignement point to give decoding tools a
+	 * chance to fix things.
+	 */
+	if (write_ptr % ETB_FRAME_SIZE_WORDS) {
+		dev_err(drvdata->dev,
+			"write_ptr: %lu not aligned to formatter frame size\n",
+			(unsigned long)write_ptr);
+
+		write_ptr &= ~(ETB_FRAME_SIZE_WORDS - 1);
+		local_inc(&buf->lost);
+	}
+
+	/*
+	 * Get a hold of the status register and see if a wrap around
+	 * has occurred.  If so adjust things accordingly.  Otherwise
+	 * start at the beginning and go until the write pointer has
+	 * been reached.
+	 */
+	status = readl_relaxed(drvdata->base + ETB_STATUS_REG);
+	if (status & ETB_STATUS_RAM_FULL) {
+		local_inc(&buf->lost);
+		to_read = capacity;
+		read_ptr = write_ptr;
+	} else {
+		to_read = CIRC_CNT(write_ptr, read_ptr, drvdata->buffer_depth);
+		to_read *= ETB_FRAME_SIZE_WORDS;
+	}
+
+	/*
+	 * Make sure we don't overwrite data that hasn't been consumed yet.
+	 * It is entirely possible that the HW buffer has more data than the
+	 * ring buffer can currently handle.  If so adjust the start address
+	 * to take only the last traces.
+	 *
+	 * In snapshot mode we are looking to get the latest traces only and as
+	 * such, we don't care about not overwriting data that hasn't been
+	 * processed by user space.
+	 */
+	if (!buf->snapshot && to_read > handle->size) {
+		u32 mask = ~(ETB_FRAME_SIZE_WORDS - 1);
+
+		/* The new read pointer must be frame size aligned */
+		to_read -= handle->size & mask;
+		/*
+		 * Move the RAM read pointer up, keeping in mind that
+		 * everything is in frame size units.
+		 */
+		read_ptr = (write_ptr + drvdata->buffer_depth) -
+					to_read / ETB_FRAME_SIZE_WORDS;
+		/* Wrap around if need be*/
+		read_ptr &= ~(drvdata->buffer_depth - 1);
+		/* let the decoder know we've skipped ahead */
+		local_inc(&buf->lost);
+	}
+
+	/* finally tell HW where we want to start reading from */
+	writel_relaxed(read_ptr, drvdata->base + ETB_RAM_READ_POINTER);
+
+	cur = buf->cur;
+	offset = buf->offset;
+	for (i = 0; i < to_read; i += 4) {
+		buf_ptr = buf->data_pages[cur] + offset;
+		read_data = readl_relaxed(drvdata->base +
+					  ETB_RAM_READ_DATA_REG);
+		*buf_ptr++ = read_data >> 0;
+		*buf_ptr++ = read_data >> 8;
+		*buf_ptr++ = read_data >> 16;
+		*buf_ptr++ = read_data >> 24;
+
+		offset += 4;
+		if (offset >= PAGE_SIZE) {
+			offset = 0;
+			cur++;
+			/* wrap around at the end of the buffer */
+			cur &= buf->nr_pages - 1;
+		}
+	}
+
+	/* reset ETB buffer for next run */
+	writel_relaxed(0x0, drvdata->base + ETB_RAM_READ_POINTER);
+	writel_relaxed(0x0, drvdata->base + ETB_RAM_WRITE_POINTER);
+
+	/*
+	 * In snapshot mode all we have to do is communicate to
+	 * perf_aux_output_end() the address of the current head.  In full
+	 * trace mode the same function expects a size to move rb->aux_head
+	 * forward.
+	 */
+	if (buf->snapshot)
+		local_set(&buf->data_size, (cur * PAGE_SIZE) + offset);
+	else
+		local_add(to_read, &buf->data_size);
+
+	etb_enable_hw(drvdata);
+	CS_LOCK(drvdata->base);
+}
+
 static const struct coresight_ops_sink etb_sink_ops = {
 	.enable		= etb_enable,
 	.disable	= etb_disable,
+	.alloc_buffer	= etb_alloc_buffer,
+	.free_buffer	= etb_free_buffer,
+	.set_buffer	= etb_set_buffer,
+	.reset_buffer	= etb_reset_buffer,
+	.update_buffer	= etb_update_buffer,
 };
 
 static const struct coresight_ops etb_cs_ops = {
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 9fa92dcdd2ea..385d62e64abb 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -182,12 +182,29 @@ struct coresight_device {
 /**
  * struct coresight_ops_sink - basic operations for a sink
  * Operations available for sinks
- * @enable:	enables the sink.
- * @disable:	disables the sink.
+ * @enable:		enables the sink.
+ * @disable:		disables the sink.
+ * @alloc_buffer:	initialises perf's ring buffer for trace collection.
+ * @free_buffer:	release memory allocated in @get_config.
+ * @set_buffer:		initialises buffer mechanic before a trace session.
+ * @reset_buffer:	finalises buffer mechanic after a trace session.
+ * @update_buffer:	update buffer pointers after a trace session.
  */
 struct coresight_ops_sink {
 	int (*enable)(struct coresight_device *csdev, u32 mode);
 	void (*disable)(struct coresight_device *csdev);
+	void *(*alloc_buffer)(struct coresight_device *csdev, int cpu,
+			      void **pages, int nr_pages, bool overwrite);
+	void (*free_buffer)(void *config);
+	int (*set_buffer)(struct coresight_device *csdev,
+			  struct perf_output_handle *handle,
+			  void *sink_config);
+	unsigned long (*reset_buffer)(struct coresight_device *csdev,
+				      struct perf_output_handle *handle,
+				      void *sink_config, bool *lost);
+	void (*update_buffer)(struct coresight_device *csdev,
+			      struct perf_output_handle *handle,
+			      void *sink_config);
 };
 
 /**
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:58 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:58 -0700
Subject: [PATCH 16/21] coresight: etb10: moving to local atomic operations
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-17-git-send-email-mathieu.poirier@linaro.org>

Moving to use local atomic operations to take advantage of the
lockless implementation, something that will come handy when
the ETB is accessed from the Perf subsystem. Also changing the
name of the variable to something more meaningful.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etb10.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 917562ecf82a..162c9ccc8c33 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -10,6 +10,7 @@
  * GNU General Public License for more details.
  */
 
+#include <asm/local.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/init.h>
@@ -71,7 +72,7 @@
  * @csdev:	component vitals needed by the framework.
  * @miscdev:	specifics to handle "/dev/xyz.etb" entry.
  * @spinlock:	only one at a time pls.
- * @in_use:	synchronise user space access to etb buffer.
+ * @reading:	synchronise user space access to etb buffer.
  * @buf:	area of memory where ETB buffer content gets sent.
  * @buffer_depth: size of @buf.
  * @enable:	this ETB is being used.
@@ -84,7 +85,7 @@ struct etb_drvdata {
 	struct coresight_device	*csdev;
 	struct miscdevice	miscdev;
 	spinlock_t		spinlock;
-	atomic_t		in_use;
+	local_t			reading;
 	u8			*buf;
 	u32			buffer_depth;
 	bool			enable;
@@ -277,7 +278,7 @@ static int etb_open(struct inode *inode, struct file *file)
 	struct etb_drvdata *drvdata = container_of(file->private_data,
 						   struct etb_drvdata, miscdev);
 
-	if (atomic_cmpxchg(&drvdata->in_use, 0, 1))
+	if (local_cmpxchg(&drvdata->reading, 0, 1))
 		return -EBUSY;
 
 	dev_dbg(drvdata->dev, "%s: successfully opened\n", __func__);
@@ -313,7 +314,7 @@ static int etb_release(struct inode *inode, struct file *file)
 {
 	struct etb_drvdata *drvdata = container_of(file->private_data,
 						   struct etb_drvdata, miscdev);
-	atomic_set(&drvdata->in_use, 0);
+	local_set(&drvdata->reading, 0);
 
 	dev_dbg(drvdata->dev, "%s: released\n", __func__);
 	return 0;
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:57 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:57 -0700
Subject: [PATCH 15/21] coresight: etm3x: implementing perf_enable/disable() API
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-16-git-send-email-mathieu.poirier@linaro.org>

That way traces can be enabled and disabled automatically
from the Perf subystem using the PMU abstraction.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/Kconfig           |  1 +
 drivers/hwtracing/coresight/coresight-etm3x.c | 95 +++++++++++++++++++++++++--
 drivers/hwtracing/coresight/coresight-etm4x.c |  4 +-
 drivers/hwtracing/coresight/coresight.c       |  2 +-
 include/linux/coresight.h                     |  6 +-
 5 files changed, 99 insertions(+), 9 deletions(-)

diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
index c85935f3525a..db0541031c72 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -4,6 +4,7 @@
 menuconfig CORESIGHT
 	bool "CoreSight Tracing Support"
 	select ARM_AMBA
+	select PERF_EVENTS
 	help
 	  This framework provides a kernel interface for the CoreSight debug
 	  and trace drivers to register themselves with. It's intended to build
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index c82d545e68ef..a9b820ec16aa 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -31,6 +31,7 @@
 #include <linux/seq_file.h>
 #include <linux/uaccess.h>
 #include <linux/clk.h>
+#include <linux/perf_event.h>
 #include <asm/sections.h>
 
 #include "coresight-etm.h"
@@ -297,6 +298,47 @@ void etm_config_trace_mode(struct etm_config *config)
 	config->addr_type[1] = ETM_ADDR_TYPE_RANGE;
 }
 
+#define ETM3X_SUPPORTED_OPTIONS (ETMCR_CYC_ACC | ETMCR_TIMESTAMP_EN)
+
+static int etm_parse_event_config(struct etm_drvdata *drvdata,
+				  struct perf_event_attr *attr)
+{
+	struct etm_config *config = &drvdata->config;
+
+	if (!attr)
+		return -EINVAL;
+
+	/* Clear configuration from previous run */
+	memset(config, 0, sizeof(struct etm_config));
+
+	if (attr->exclude_kernel)
+		config->mode = ETM_MODE_EXCL_KERN;
+
+	if (attr->exclude_user)
+		config->mode = ETM_MODE_EXCL_USER;
+
+	/* Always start from the default config */
+	etm_set_default(config);
+
+	/*
+	 * By default the tracers are configured to trace the whole address
+	 * range.  Narrow the field only if requested by user space.
+	 */
+	if (config->mode)
+		etm_config_trace_mode(config);
+
+	/*
+	 * At this time only cycle accurate and timestamp options are
+	 * available.
+	 */
+	if (attr->config & ~ETM3X_SUPPORTED_OPTIONS)
+		return -EINVAL;
+
+	config->ctrl = attr->config;
+
+	return 0;
+}
+
 static void etm_enable_hw(void *info)
 {
 	int i;
@@ -316,8 +358,10 @@ static void etm_enable_hw(void *info)
 	etm_set_prog(drvdata);
 
 	etmcr = etm_readl(drvdata, ETMCR);
-	etmcr &= (ETMCR_PWD_DWN | ETMCR_ETM_PRG);
+	/* Clear setting from a previous run if need be */
+	etmcr &= ~ETM3X_SUPPORTED_OPTIONS;
 	etmcr |= drvdata->port_size;
+	etmcr |= ETMCR_ETM_EN;
 	etm_writel(drvdata, config->ctrl | etmcr, ETMCR);
 	etm_writel(drvdata, config->trigger_event, ETMTRIGGER);
 	etm_writel(drvdata, config->startstop_ctrl, ETMTSSCR);
@@ -357,9 +401,6 @@ static void etm_enable_hw(void *info)
 	/* No VMID comparator value selected */
 	etm_writel(drvdata, 0x0, ETMVMIDCVR);
 
-	/* Ensures trace output is enabled from this ETM */
-	etm_writel(drvdata, config->ctrl | ETMCR_ETM_EN | etmcr, ETMCR);
-
 	etm_clr_prog(drvdata);
 	CS_LOCK(drvdata->base);
 
@@ -407,6 +448,22 @@ static int etm_trace_id(struct coresight_device *csdev)
 	return etm_get_trace_id(drvdata);
 }
 
+static int etm_enable_perf(struct coresight_device *csdev,
+			   struct perf_event_attr *attr)
+{
+	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	if (WARN_ON_ONCE(drvdata->cpu != smp_processor_id()))
+		return -EINVAL;
+
+	/* Configure the tracer based on the session's specifics */
+	etm_parse_event_config(drvdata, attr);
+	/* And enable it */
+	etm_enable_hw(drvdata);
+
+	return 0;
+}
+
 static int etm_enable_sysfs(struct coresight_device *csdev)
 {
 	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
@@ -437,7 +494,8 @@ err:
 	return ret;
 }
 
-static int etm_enable(struct coresight_device *csdev, u32 mode)
+static int etm_enable(struct coresight_device *csdev,
+		      struct perf_event_attr *attr, u32 mode)
 {
 	int ret;
 	u32 val;
@@ -453,6 +511,9 @@ static int etm_enable(struct coresight_device *csdev, u32 mode)
 	case CS_MODE_SYSFS:
 		ret = etm_enable_sysfs(csdev);
 		break;
+	case CS_MODE_PERF:
+		ret = etm_enable_perf(csdev, attr);
+		break;
 	default:
 		ret = -EINVAL;
 	}
@@ -485,6 +546,27 @@ static void etm_disable_hw(void *info)
 	dev_dbg(drvdata->dev, "cpu: %d disable smp call done\n", drvdata->cpu);
 }
 
+static void etm_disable_perf(struct coresight_device *csdev)
+{
+	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	if (WARN_ON_ONCE(drvdata->cpu != smp_processor_id()))
+		return;
+
+	CS_UNLOCK(drvdata->base);
+
+	/* Setting the prog bit disables tracing immediately */
+	etm_set_prog(drvdata);
+
+	/*
+	 * There is no way to know when the tracer will be used again so
+	 * power down the tracer.
+	 */
+	etm_set_pwrdwn(drvdata);
+
+	CS_LOCK(drvdata->base);
+}
+
 static void etm_disable_sysfs(struct coresight_device *csdev)
 {
 	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
@@ -528,6 +610,9 @@ static void etm_disable(struct coresight_device *csdev)
 	case CS_MODE_SYSFS:
 		etm_disable_sysfs(csdev);
 		break;
+	case CS_MODE_PERF:
+		etm_disable_perf(csdev);
+		break;
 	default:
 		WARN_ON_ONCE(mode);
 		return;
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index 0026092fec7f..d0169ba7fbf2 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -32,6 +32,7 @@
 #include <linux/seq_file.h>
 #include <linux/uaccess.h>
 #include <linux/pm_runtime.h>
+#include <linux/perf_event.h>
 #include <asm/sections.h>
 
 #include "coresight-etm4x.h"
@@ -187,7 +188,8 @@ static void etm4_enable_hw(void *info)
 	dev_dbg(drvdata->dev, "cpu: %d enable smp call done\n", drvdata->cpu);
 }
 
-static int etm4_enable(struct coresight_device *csdev, u32 mode)
+static int etm4_enable(struct coresight_device *csdev,
+		       struct perf_event_attr *attr, u32 mode)
 {
 	struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	int ret;
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index b20afb709141..95cccb179763 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -234,7 +234,7 @@ static int coresight_enable_source(struct coresight_device *csdev, u32 mode)
 
 	if (!csdev->enable) {
 		if (source_ops(csdev)->enable) {
-			ret = source_ops(csdev)->enable(csdev, mode);
+			ret = source_ops(csdev)->enable(csdev, NULL, mode);
 			if (ret)
 				return ret;
 		}
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 61dfb8d511ea..6801dd64ee5d 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -14,6 +14,7 @@
 #define _LINUX_CORESIGHT_H
 
 #include <linux/device.h>
+#include <linux/perf_event.h>
 #include <linux/sched.h>
 
 /* Peripheral id registers (0xFD0-0xFEC) */
@@ -206,14 +207,15 @@ struct coresight_ops_link {
  * @cpu_id:	returns the value of the CPU number this component
  *		is associated to.
  * @trace_id:	returns the value of the component's trace ID as known
-		to the HW.
+ *		to the HW.
  * @enable:	enables tracing for a source.
  * @disable:	disables tracing for a source.
  */
 struct coresight_ops_source {
 	int (*cpu_id)(struct coresight_device *csdev);
 	int (*trace_id)(struct coresight_device *csdev);
-	int (*enable)(struct coresight_device *csdev, u32 mode);
+	int (*enable)(struct coresight_device *csdev,
+		      struct perf_event_attr *attr,  u32 mode);
 	void (*disable)(struct coresight_device *csdev);
 };
 
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:59 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:59 -0700
Subject: [PATCH 17/21] coresight: etb10: adding operation mode for
 sink->enable()
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-18-git-send-email-mathieu.poirier@linaro.org>

Adding an operation mode to the sink->enable() API in order
to prevent simultaneous access from different callers.

TPIU and TMC won't be supplemented with the AUX area
API immediately and as such ignore the new mode.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etb10.c | 30 ++++++++++++++++++++-------
 drivers/hwtracing/coresight/coresight-priv.h  |  2 +-
 drivers/hwtracing/coresight/coresight-tmc.c   |  2 +-
 drivers/hwtracing/coresight/coresight-tpiu.c  |  2 +-
 drivers/hwtracing/coresight/coresight.c       | 10 ++++-----
 include/linux/coresight.h                     |  2 +-
 6 files changed, 32 insertions(+), 16 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index 162c9ccc8c33..79099f95ba3f 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -73,9 +73,9 @@
  * @miscdev:	specifics to handle "/dev/xyz.etb" entry.
  * @spinlock:	only one at a time pls.
  * @reading:	synchronise user space access to etb buffer.
+ * @mode:	this ETB is being used.
  * @buf:	area of memory where ETB buffer content gets sent.
  * @buffer_depth: size of @buf.
- * @enable:	this ETB is being used.
  * @trigger_cntr: amount of words to store after a trigger.
  */
 struct etb_drvdata {
@@ -86,9 +86,9 @@ struct etb_drvdata {
 	struct miscdevice	miscdev;
 	spinlock_t		spinlock;
 	local_t			reading;
+	local_t			mode;
 	u8			*buf;
 	u32			buffer_depth;
-	bool			enable;
 	u32			trigger_cntr;
 };
 
@@ -133,16 +133,31 @@ static void etb_enable_hw(struct etb_drvdata *drvdata)
 	CS_LOCK(drvdata->base);
 }
 
-static int etb_enable(struct coresight_device *csdev)
+static int etb_enable(struct coresight_device *csdev, u32 mode)
 {
-	struct etb_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+	u32 val;
 	unsigned long flags;
+	struct etb_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	val = local_cmpxchg(&drvdata->mode,
+			    CS_MODE_DISABLED, mode);
+	/*
+	 * When accessing from Perf, a HW buffer can be handled
+	 * by a single trace entity.  In sysFS mode many tracers
+	 * can be logging to the same HW buffer.
+	 */
+	if (val == CS_MODE_PERF)
+		return -EBUSY;
+
+	/* Nothing to do, the tracer is already enabled. */
+	if (val == CS_MODE_SYSFS)
+		goto out;
 
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 	etb_enable_hw(drvdata);
-	drvdata->enable = true;
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
 
+out:
 	dev_info(drvdata->dev, "ETB enabled\n");
 	return 0;
 }
@@ -243,9 +258,10 @@ static void etb_disable(struct coresight_device *csdev)
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 	etb_disable_hw(drvdata);
 	etb_dump_hw(drvdata);
-	drvdata->enable = false;
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
 
+	local_set(&drvdata->mode, CS_MODE_DISABLED);
+
 	dev_info(drvdata->dev, "ETB disabled\n");
 }
 
@@ -263,7 +279,7 @@ static void etb_dump(struct etb_drvdata *drvdata)
 	unsigned long flags;
 
 	spin_lock_irqsave(&drvdata->spinlock, flags);
-	if (drvdata->enable) {
+	if (local_read(&drvdata->mode) == CS_MODE_SYSFS) {
 		etb_disable_hw(drvdata);
 		etb_dump_hw(drvdata);
 		etb_enable_hw(drvdata);
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
index 932f34a84d96..333eddaed339 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -62,7 +62,7 @@ static inline void CS_UNLOCK(void __iomem *addr)
 }
 
 void coresight_disable_path(struct list_head *path);
-int coresight_enable_path(struct list_head *path);
+int coresight_enable_path(struct list_head *path, u32 mode);
 struct coresight_device *coresight_get_sink(struct list_head *path);
 struct list_head *coresight_build_path(struct coresight_device *csdev);
 void coresight_release_path(struct list_head *path);
diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
index b526396d80b6..ac91b0b40ec2 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -265,7 +265,7 @@ static int tmc_enable(struct tmc_drvdata *drvdata, enum tmc_mode mode)
 	return 0;
 }
 
-static int tmc_enable_sink(struct coresight_device *csdev)
+static int tmc_enable_sink(struct coresight_device *csdev, u32 mode)
 {
 	struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
index 0d8fce651ff7..71582f6dfd4c 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -70,7 +70,7 @@ static void tpiu_enable_hw(struct tpiu_drvdata *drvdata)
 	CS_LOCK(drvdata->base);
 }
 
-static int tpiu_enable(struct coresight_device *csdev)
+static int tpiu_enable(struct coresight_device *csdev, u32 mode)
 {
 	struct tpiu_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 95cccb179763..6ec2b66af9ee 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -121,13 +121,13 @@ static int coresight_find_link_outport(struct coresight_device *csdev,
 	return 0;
 }
 
-static int coresight_enable_sink(struct coresight_device *csdev)
+static int coresight_enable_sink(struct coresight_device *csdev, u32 mode)
 {
 	int ret;
 
 	if (!csdev->enable) {
 		if (sink_ops(csdev)->enable) {
-			ret = sink_ops(csdev)->enable(csdev);
+			ret = sink_ops(csdev)->enable(csdev, mode);
 			if (ret)
 				return ret;
 		}
@@ -283,7 +283,7 @@ void coresight_disable_path(struct list_head *path)
 	}
 }
 
-int coresight_enable_path(struct list_head *path)
+int coresight_enable_path(struct list_head *path, u32 mode)
 {
 
 	int ret = 0;
@@ -296,7 +296,7 @@ int coresight_enable_path(struct list_head *path)
 		switch (csdev->type) {
 		case CORESIGHT_DEV_TYPE_SINK:
 		case CORESIGHT_DEV_TYPE_LINKSINK:
-			ret = coresight_enable_sink(csdev);
+			ret = coresight_enable_sink(csdev, mode);
 			if (ret)
 				goto err;
 			break;
@@ -454,7 +454,7 @@ int coresight_enable(struct coresight_device *csdev)
 		goto out;
 	}
 
-	ret = coresight_enable_path(path);
+	ret = coresight_enable_path(path, CS_MODE_SYSFS);
 	if (ret)
 		goto err_path;
 
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 6801dd64ee5d..9fa92dcdd2ea 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -186,7 +186,7 @@ struct coresight_device {
  * @disable:	disables the sink.
  */
 struct coresight_ops_sink {
-	int (*enable)(struct coresight_device *csdev);
+	int (*enable)(struct coresight_device *csdev, u32 mode);
 	void (*disable)(struct coresight_device *csdev);
 };
 
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:52:02 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:52:02 -0700
Subject: [PATCH 20/21] coresight: introducing a global trace ID function
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-21-git-send-email-mathieu.poirier@linaro.org>

TraceID values have to be unique for all tracers and
consistent between drivers and user space.  As such
introducing a central function to be used whenever a
traceID value is required.

The patch also account for data traceIDs, which are usually
I(N) + 1.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm3x.c |  7 ++-----
 include/linux/coresight-pmu.h                 | 12 ++++++++++++
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 77b37413803f..0ba1a3981373 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -27,6 +27,7 @@
 #include <linux/cpu.h>
 #include <linux/of.h>
 #include <linux/coresight.h>
+#include <linux/coresight-pmu.h>
 #include <linux/amba/bus.h>
 #include <linux/seq_file.h>
 #include <linux/uaccess.h>
@@ -740,11 +741,7 @@ static void etm_init_arch_data(void *info)
 
 static void etm_init_trace_id(struct etm_drvdata *drvdata)
 {
-	/*
-	 * A trace ID of value 0 is invalid, so let's start at some
-	 * random value that fits in 7 bits and go from there.
-	 */
-	drvdata->traceid = 0x10 + drvdata->cpu;
+	drvdata->traceid = coresight_get_trace_id(drvdata->cpu);
 }
 
 static int etm_probe(struct amba_device *adev, const struct amba_id *id)
diff --git a/include/linux/coresight-pmu.h b/include/linux/coresight-pmu.h
index 6c5386b23b10..7d410260661b 100644
--- a/include/linux/coresight-pmu.h
+++ b/include/linux/coresight-pmu.h
@@ -19,9 +19,21 @@
 #define _LINUX_CORESIGHT_PMU_H
 
 #define CORESIGHT_ETM_PMU_NAME "cs_etm"
+#define CORESIGHT_ETM_PMU_SEED  0x10
 
 /* ETMv3.5/PTM's ETMCR config bit */
 #define ETM_OPT_CYCACC  12
 #define ETM_OPT_TS      28
 
+static inline int coresight_get_trace_id(int cpu)
+{
+	/*
+	 * A trace ID of value 0 is invalid, so let's start at some
+	 * random value that fits in 7 bits and go from there.  Since
+	 * the common convention is to have data trace IDs be I(N) + 1,
+	 * set instruction trace IDs as a function of the CPU number.
+	 */
+	return (CORESIGHT_ETM_PMU_SEED + (cpu * 2));
+}
+
 #endif
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:51 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:51 -0700
Subject: [PATCH 09/21] coresight: etm3x: splitting struct etm_drvdata
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-10-git-send-email-mathieu.poirier@linaro.org>

Splitting "etm_drvdata" in two sections, one for the HW specific
data and another for user configuration.

That way it is easier to manipulate and zero out the configuration
data when more than one concurrent tracing session configuration
is active.

Also taking care of up-lifting all the code affected by this new
arrangement.  No loss or gain of functionality (other than what is
mentioned above) is introduced by this patch.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/coresight-etm.h        | 102 ++++----
 .../hwtracing/coresight/coresight-etm3x-sysfs.c    | 290 ++++++++++++---------
 drivers/hwtracing/coresight/coresight-etm3x.c      | 153 +++++------
 3 files changed, 305 insertions(+), 240 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
index 9a30aa392ed9..371fb7d2e829 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -136,29 +136,9 @@
 #define ETM_DEFAULT_EVENT_VAL	(ETM_HARD_WIRE_RES_A	|	\
 				 ETM_ADD_COMP_0		|	\
 				 ETM_EVENT_NOT_A)
+
 /**
- * struct etm_drvdata - specifics associated to an ETM component
- * @base:	memory mapped base address for this component.
- * @dev:	the device entity associated to this component.
- * @atclk:	optional clock for the core parts of the ETM.
- * @csdev:	component vitals needed by the framework.
- * @spinlock:	only one at a time pls.
- * @cpu:	the cpu this component is affined to.
- * @port_size:	port size as reported by ETMCR bit 4-6 and 21.
- * @arch:	ETM/PTM version number.
- * @use_cpu14:	true if management registers need to be accessed via CP14.
- * @enable:	is this ETM/PTM currently tracing.
- * @sticky_enable: true if ETM base configuration has been done.
- * @boot_enable:true if we should start tracing at boot time.
- * @os_unlock:	true if access to management registers is allowed.
- * @nr_addr_cmp:Number of pairs of address comparators as found in ETMCCR.
- * @nr_cntr:	Number of counters as found in ETMCCR bit 13-15.
- * @nr_ext_inp:	Number of external input as found in ETMCCR bit 17-19.
- * @nr_ext_out:	Number of external output as found in ETMCCR bit 20-22.
- * @nr_ctxid_cmp: Number of contextID comparators as found in ETMCCR bit 24-25.
- * @etmccr:	value of register ETMCCR.
- * @etmccer:	value of register ETMCCER.
- * @traceid:	value of the current ID for this component.
+ * struct etm_config - configuration information related to an ETM
  * @mode:	controls various modes supported by this ETM/PTM.
  * @ctrl:	used in conjunction with @mode.
  * @trigger_event: setting for register ETMTRIGGER.
@@ -189,30 +169,9 @@
  * @ctxid_mask: mask applicable to all the context IDs.
  * @sync_freq:	Synchronisation frequency.
  * @timestamp_event: Defines an event that requests the insertion
-		     of a timestamp into the trace stream.
+ *		     of a timestamp into the trace stream.
  */
-struct etm_drvdata {
-	void __iomem			*base;
-	struct device			*dev;
-	struct clk			*atclk;
-	struct coresight_device		*csdev;
-	spinlock_t			spinlock;
-	int				cpu;
-	int				port_size;
-	u8				arch;
-	bool				use_cp14;
-	bool				enable;
-	bool				sticky_enable;
-	bool				boot_enable;
-	bool				os_unlock;
-	u8				nr_addr_cmp;
-	u8				nr_cntr;
-	u8				nr_ext_inp;
-	u8				nr_ext_out;
-	u8				nr_ctxid_cmp;
-	u32				etmccr;
-	u32				etmccer;
-	u32				traceid;
+struct etm_config {
 	u32				mode;
 	u32				ctrl;
 	u32				trigger_event;
@@ -244,6 +203,56 @@ struct etm_drvdata {
 	u32				timestamp_event;
 };
 
+/**
+ * struct etm_drvdata - specifics associated to an ETM component
+ * @base:	memory mapped base address for this component.
+ * @dev:	the device entity associated to this component.
+ * @atclk:	optional clock for the core parts of the ETM.
+ * @csdev:	component vitals needed by the framework.
+ * @spinlock:	only one at a time pls.
+ * @cpu:	the cpu this component is affined to.
+ * @port_size:	port size as reported by ETMCR bit 4-6 and 21.
+ * @arch:	ETM/PTM version number.
+ * @use_cpu14:	true if management registers need to be accessed via CP14.
+ * @enable:	is this ETM/PTM currently tracing.
+ * @sticky_enable: true if ETM base configuration has been done.
+ * @boot_enable:true if we should start tracing at boot time.
+ * @os_unlock:	true if access to management registers is allowed.
+ * @nr_addr_cmp:Number of pairs of address comparators as found in ETMCCR.
+ * @nr_cntr:	Number of counters as found in ETMCCR bit 13-15.
+ * @nr_ext_inp:	Number of external input as found in ETMCCR bit 17-19.
+ * @nr_ext_out:	Number of external output as found in ETMCCR bit 20-22.
+ * @nr_ctxid_cmp: Number of contextID comparators as found in ETMCCR bit 24-25.
+ * @etmccr:	value of register ETMCCR.
+ * @etmccer:	value of register ETMCCER.
+ * @traceid:	value of the current ID for this component.
+ * @config:	structure holding configuration parameters.
+ */
+struct etm_drvdata {
+	void __iomem			*base;
+	struct device			*dev;
+	struct clk			*atclk;
+	struct coresight_device		*csdev;
+	spinlock_t			spinlock;
+	int				cpu;
+	int				port_size;
+	u8				arch;
+	bool				use_cp14;
+	bool				enable;
+	bool				sticky_enable;
+	bool				boot_enable;
+	bool				os_unlock;
+	u8				nr_addr_cmp;
+	u8				nr_cntr;
+	u8				nr_ext_inp;
+	u8				nr_ext_out;
+	u8				nr_ctxid_cmp;
+	u32				etmccr;
+	u32				etmccer;
+	u32				traceid;
+	struct etm_config		config;
+};
+
 enum etm_addr_type {
 	ETM_ADDR_TYPE_NONE,
 	ETM_ADDR_TYPE_SINGLE,
@@ -283,5 +292,6 @@ static inline unsigned int etm_readl(struct etm_drvdata *drvdata, u32 off)
 
 extern const struct attribute_group *coresight_etm_groups[];
 int etm_get_trace_id(struct etm_drvdata *drvdata);
-void etm_set_default(struct etm_drvdata *drvdata);
+void etm_set_default(struct etm_config *config);
+struct etm_config *get_etm_config(struct etm_drvdata *drvdata);
 #endif
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
index f409f5a88e95..456df2378a6f 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
@@ -78,6 +78,7 @@ static ssize_t reset_store(struct device *dev,
 	int i, ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
@@ -85,19 +86,14 @@ static ssize_t reset_store(struct device *dev,
 
 	if (val) {
 		spin_lock(&drvdata->spinlock);
-		drvdata->mode = ETM_MODE_EXCLUDE;
-		drvdata->ctrl = 0x0;
-		drvdata->trigger_event = ETM_DEFAULT_EVENT_VAL;
-		drvdata->startstop_ctrl = 0x0;
-		drvdata->addr_idx = 0x0;
+		memset(config, 0, sizeof(struct etm_config));
+		config->mode = ETM_MODE_EXCLUDE;
+		config->trigger_event = ETM_DEFAULT_EVENT_VAL;
 		for (i = 0; i < drvdata->nr_addr_cmp; i++) {
-			drvdata->addr_val[i] = 0x0;
-			drvdata->addr_acctype[i] = 0x0;
-			drvdata->addr_type[i] = ETM_ADDR_TYPE_NONE;
+			config->addr_type[i] = ETM_ADDR_TYPE_NONE;
 		}
-		drvdata->cntr_idx = 0x0;
 
-		etm_set_default(drvdata);
+		etm_set_default(config);
 		spin_unlock(&drvdata->spinlock);
 	}
 
@@ -110,8 +106,9 @@ static ssize_t mode_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->mode;
+	val = config->mode;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -122,48 +119,49 @@ static ssize_t mode_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	drvdata->mode = val & ETM_MODE_ALL;
+	config->mode = val & ETM_MODE_ALL;
 
-	if (drvdata->mode & ETM_MODE_EXCLUDE)
-		drvdata->enable_ctrl1 |= ETMTECR1_INC_EXC;
+	if (config->mode & ETM_MODE_EXCLUDE)
+		config->enable_ctrl1 |= ETMTECR1_INC_EXC;
 	else
-		drvdata->enable_ctrl1 &= ~ETMTECR1_INC_EXC;
+		config->enable_ctrl1 &= ~ETMTECR1_INC_EXC;
 
-	if (drvdata->mode & ETM_MODE_CYCACC)
-		drvdata->ctrl |= ETMCR_CYC_ACC;
+	if (config->mode & ETM_MODE_CYCACC)
+		config->ctrl |= ETMCR_CYC_ACC;
 	else
-		drvdata->ctrl &= ~ETMCR_CYC_ACC;
+		config->ctrl &= ~ETMCR_CYC_ACC;
 
-	if (drvdata->mode & ETM_MODE_STALL) {
+	if (config->mode & ETM_MODE_STALL) {
 		if (!(drvdata->etmccr & ETMCCR_FIFOFULL)) {
 			dev_warn(drvdata->dev, "stall mode not supported\n");
 			ret = -EINVAL;
 			goto err_unlock;
 		}
-		drvdata->ctrl |= ETMCR_STALL_MODE;
+		config->ctrl |= ETMCR_STALL_MODE;
 	 } else
-		drvdata->ctrl &= ~ETMCR_STALL_MODE;
+		config->ctrl &= ~ETMCR_STALL_MODE;
 
-	if (drvdata->mode & ETM_MODE_TIMESTAMP) {
+	if (config->mode & ETM_MODE_TIMESTAMP) {
 		if (!(drvdata->etmccer & ETMCCER_TIMESTAMP)) {
 			dev_warn(drvdata->dev, "timestamp not supported\n");
 			ret = -EINVAL;
 			goto err_unlock;
 		}
-		drvdata->ctrl |= ETMCR_TIMESTAMP_EN;
+		config->ctrl |= ETMCR_TIMESTAMP_EN;
 	} else
-		drvdata->ctrl &= ~ETMCR_TIMESTAMP_EN;
+		config->ctrl &= ~ETMCR_TIMESTAMP_EN;
 
-	if (drvdata->mode & ETM_MODE_CTXID)
-		drvdata->ctrl |= ETMCR_CTXID_SIZE;
+	if (config->mode & ETM_MODE_CTXID)
+		config->ctrl |= ETMCR_CTXID_SIZE;
 	else
-		drvdata->ctrl &= ~ETMCR_CTXID_SIZE;
+		config->ctrl &= ~ETMCR_CTXID_SIZE;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -179,8 +177,9 @@ static ssize_t trigger_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->trigger_event;
+	val = config->trigger_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -191,12 +190,13 @@ static ssize_t trigger_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->trigger_event = val & ETM_EVENT_MASK;
+	config->trigger_event = val & ETM_EVENT_MASK;
 
 	return size;
 }
@@ -207,8 +207,9 @@ static ssize_t enable_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->enable_event;
+	val = config->enable_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -219,12 +220,13 @@ static ssize_t enable_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->enable_event = val & ETM_EVENT_MASK;
+	config->enable_event = val & ETM_EVENT_MASK;
 
 	return size;
 }
@@ -235,8 +237,9 @@ static ssize_t fifofull_level_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->fifofull_level;
+	val = config->fifofull_level;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -247,12 +250,13 @@ static ssize_t fifofull_level_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->fifofull_level = val;
+	config->fifofull_level = val;
 
 	return size;
 }
@@ -263,8 +267,9 @@ static ssize_t addr_idx_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->addr_idx;
+	val = config->addr_idx;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -275,6 +280,7 @@ static ssize_t addr_idx_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
@@ -288,7 +294,7 @@ static ssize_t addr_idx_store(struct device *dev,
 	 * dereferenced multiple times within a spinlock block elsewhere.
 	 */
 	spin_lock(&drvdata->spinlock);
-	drvdata->addr_idx = val;
+	config->addr_idx = val;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -301,16 +307,17 @@ static ssize_t addr_single_show(struct device *dev,
 	u8 idx;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
+	idx = config->addr_idx;
+	if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      config->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
 		spin_unlock(&drvdata->spinlock);
 		return -EINVAL;
 	}
 
-	val = drvdata->addr_val[idx];
+	val = config->addr_val[idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -324,21 +331,22 @@ static ssize_t addr_single_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
+	idx = config->addr_idx;
+	if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      config->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
 		spin_unlock(&drvdata->spinlock);
 		return -EINVAL;
 	}
 
-	drvdata->addr_val[idx] = val;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_SINGLE;
+	config->addr_val[idx] = val;
+	config->addr_type[idx] = ETM_ADDR_TYPE_SINGLE;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -351,23 +359,24 @@ static ssize_t addr_range_show(struct device *dev,
 	u8 idx;
 	unsigned long val1, val2;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
+	idx = config->addr_idx;
 	if (idx % 2 != 0) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
-	if (!((drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
-	      (drvdata->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
+	if (!((config->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
+	       config->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
+	      (config->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
+	       config->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
 
-	val1 = drvdata->addr_val[idx];
-	val2 = drvdata->addr_val[idx + 1];
+	val1 = config->addr_val[idx];
+	val2 = config->addr_val[idx + 1];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx %#lx\n", val1, val2);
@@ -380,6 +389,7 @@ static ssize_t addr_range_store(struct device *dev,
 	u8 idx;
 	unsigned long val1, val2;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	if (sscanf(buf, "%lx %lx", &val1, &val2) != 2)
 		return -EINVAL;
@@ -388,24 +398,24 @@ static ssize_t addr_range_store(struct device *dev,
 		return -EINVAL;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
+	idx = config->addr_idx;
 	if (idx % 2 != 0) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
-	if (!((drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
-	      (drvdata->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
+	if (!((config->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
+	       config->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
+	      (config->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
+	       config->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
 
-	drvdata->addr_val[idx] = val1;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_RANGE;
-	drvdata->addr_val[idx + 1] = val2;
-	drvdata->addr_type[idx + 1] = ETM_ADDR_TYPE_RANGE;
-	drvdata->enable_ctrl1 |= (1 << (idx/2));
+	config->addr_val[idx] = val1;
+	config->addr_type[idx] = ETM_ADDR_TYPE_RANGE;
+	config->addr_val[idx + 1] = val2;
+	config->addr_type[idx + 1] = ETM_ADDR_TYPE_RANGE;
+	config->enable_ctrl1 |= (1 << (idx/2));
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -418,16 +428,17 @@ static ssize_t addr_start_show(struct device *dev,
 	u8 idx;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_START)) {
+	idx = config->addr_idx;
+	if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      config->addr_type[idx] == ETM_ADDR_TYPE_START)) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
 
-	val = drvdata->addr_val[idx];
+	val = config->addr_val[idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -441,23 +452,24 @@ static ssize_t addr_start_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_START)) {
+	idx = config->addr_idx;
+	if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      config->addr_type[idx] == ETM_ADDR_TYPE_START)) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
 
-	drvdata->addr_val[idx] = val;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_START;
-	drvdata->startstop_ctrl |= (1 << idx);
-	drvdata->enable_ctrl1 |= BIT(25);
+	config->addr_val[idx] = val;
+	config->addr_type[idx] = ETM_ADDR_TYPE_START;
+	config->startstop_ctrl |= (1 << idx);
+	config->enable_ctrl1 |= BIT(25);
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -470,16 +482,17 @@ static ssize_t addr_stop_show(struct device *dev,
 	u8 idx;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
+	idx = config->addr_idx;
+	if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      config->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
 
-	val = drvdata->addr_val[idx];
+	val = config->addr_val[idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -493,23 +506,24 @@ static ssize_t addr_stop_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
+	idx = config->addr_idx;
+	if (!(config->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      config->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
 		spin_unlock(&drvdata->spinlock);
 		return -EPERM;
 	}
 
-	drvdata->addr_val[idx] = val;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_STOP;
-	drvdata->startstop_ctrl |= (1 << (idx + 16));
-	drvdata->enable_ctrl1 |= ETMTECR1_START_STOP;
+	config->addr_val[idx] = val;
+	config->addr_type[idx] = ETM_ADDR_TYPE_STOP;
+	config->startstop_ctrl |= (1 << (idx + 16));
+	config->enable_ctrl1 |= ETMTECR1_START_STOP;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -521,9 +535,10 @@ static ssize_t addr_acctype_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	val = drvdata->addr_acctype[drvdata->addr_idx];
+	val = config->addr_acctype[config->addr_idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -536,13 +551,14 @@ static ssize_t addr_acctype_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	drvdata->addr_acctype[drvdata->addr_idx] = val;
+	config->addr_acctype[config->addr_idx] = val;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -554,8 +570,9 @@ static ssize_t cntr_idx_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->cntr_idx;
+	val = config->cntr_idx;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -566,6 +583,7 @@ static ssize_t cntr_idx_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
@@ -578,7 +596,7 @@ static ssize_t cntr_idx_store(struct device *dev,
 	 * dereferenced multiple times within a spinlock block elsewhere.
 	 */
 	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_idx = val;
+	config->cntr_idx = val;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -590,9 +608,10 @@ static ssize_t cntr_rld_val_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	val = drvdata->cntr_rld_val[drvdata->cntr_idx];
+	val = config->cntr_rld_val[config->cntr_idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -605,13 +624,14 @@ static ssize_t cntr_rld_val_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_rld_val[drvdata->cntr_idx] = val;
+	config->cntr_rld_val[config->cntr_idx] = val;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -623,9 +643,10 @@ static ssize_t cntr_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	val = drvdata->cntr_event[drvdata->cntr_idx];
+	val = config->cntr_event[config->cntr_idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -638,13 +659,14 @@ static ssize_t cntr_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_event[drvdata->cntr_idx] = val & ETM_EVENT_MASK;
+	config->cntr_event[config->cntr_idx] = val & ETM_EVENT_MASK;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -656,9 +678,10 @@ static ssize_t cntr_rld_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	val = drvdata->cntr_rld_event[drvdata->cntr_idx];
+	val = config->cntr_rld_event[config->cntr_idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -671,13 +694,14 @@ static ssize_t cntr_rld_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_rld_event[drvdata->cntr_idx] = val & ETM_EVENT_MASK;
+	config->cntr_rld_event[config->cntr_idx] = val & ETM_EVENT_MASK;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -690,12 +714,13 @@ static ssize_t cntr_val_show(struct device *dev,
 	int i, ret = 0;
 	u32 val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	if (!drvdata->enable) {
 		spin_lock(&drvdata->spinlock);
 		for (i = 0; i < drvdata->nr_cntr; i++)
 			ret += sprintf(buf, "counter %d: %x\n",
-				       i, drvdata->cntr_val[i]);
+				       i, config->cntr_val[i]);
 		spin_unlock(&drvdata->spinlock);
 		return ret;
 	}
@@ -715,13 +740,14 @@ static ssize_t cntr_val_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
 	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_val[drvdata->cntr_idx] = val;
+	config->cntr_val[config->cntr_idx] = val;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -733,8 +759,9 @@ static ssize_t seq_12_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->seq_12_event;
+	val = config->seq_12_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -745,12 +772,13 @@ static ssize_t seq_12_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->seq_12_event = val & ETM_EVENT_MASK;
+	config->seq_12_event = val & ETM_EVENT_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(seq_12_event);
@@ -760,8 +788,9 @@ static ssize_t seq_21_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->seq_21_event;
+	val = config->seq_21_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -772,12 +801,13 @@ static ssize_t seq_21_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->seq_21_event = val & ETM_EVENT_MASK;
+	config->seq_21_event = val & ETM_EVENT_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(seq_21_event);
@@ -787,8 +817,9 @@ static ssize_t seq_23_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->seq_23_event;
+	val = config->seq_23_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -799,12 +830,13 @@ static ssize_t seq_23_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->seq_23_event = val & ETM_EVENT_MASK;
+	config->seq_23_event = val & ETM_EVENT_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(seq_23_event);
@@ -814,8 +846,9 @@ static ssize_t seq_31_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->seq_31_event;
+	val = config->seq_31_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -826,12 +859,13 @@ static ssize_t seq_31_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->seq_31_event = val & ETM_EVENT_MASK;
+	config->seq_31_event = val & ETM_EVENT_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(seq_31_event);
@@ -841,8 +875,9 @@ static ssize_t seq_32_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->seq_32_event;
+	val = config->seq_32_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -853,12 +888,13 @@ static ssize_t seq_32_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->seq_32_event = val & ETM_EVENT_MASK;
+	config->seq_32_event = val & ETM_EVENT_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(seq_32_event);
@@ -868,8 +904,9 @@ static ssize_t seq_13_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->seq_13_event;
+	val = config->seq_13_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -880,12 +917,13 @@ static ssize_t seq_13_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->seq_13_event = val & ETM_EVENT_MASK;
+	config->seq_13_event = val & ETM_EVENT_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(seq_13_event);
@@ -895,9 +933,10 @@ static ssize_t seq_curr_state_show(struct device *dev,
 {
 	unsigned long val, flags;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	if (!drvdata->enable) {
-		val = drvdata->seq_curr_state;
+		val = config->seq_curr_state;
 		goto out;
 	}
 
@@ -921,6 +960,7 @@ static ssize_t seq_curr_state_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
@@ -929,7 +969,7 @@ static ssize_t seq_curr_state_store(struct device *dev,
 	if (val > ETM_SEQ_STATE_MAX_VAL)
 		return -EINVAL;
 
-	drvdata->seq_curr_state = val;
+	config->seq_curr_state = val;
 
 	return size;
 }
@@ -940,8 +980,9 @@ static ssize_t ctxid_idx_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->ctxid_idx;
+	val = config->ctxid_idx;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -952,6 +993,7 @@ static ssize_t ctxid_idx_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
@@ -965,7 +1007,7 @@ static ssize_t ctxid_idx_store(struct device *dev,
 	 * dereferenced multiple times within a spinlock block elsewhere.
 	 */
 	spin_lock(&drvdata->spinlock);
-	drvdata->ctxid_idx = val;
+	config->ctxid_idx = val;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -977,9 +1019,10 @@ static ssize_t ctxid_pid_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	spin_lock(&drvdata->spinlock);
-	val = drvdata->ctxid_vpid[drvdata->ctxid_idx];
+	val = config->ctxid_vpid[config->ctxid_idx];
 	spin_unlock(&drvdata->spinlock);
 
 	return sprintf(buf, "%#lx\n", val);
@@ -992,6 +1035,7 @@ static ssize_t ctxid_pid_store(struct device *dev,
 	int ret;
 	unsigned long vpid, pid;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &vpid);
 	if (ret)
@@ -1000,8 +1044,8 @@ static ssize_t ctxid_pid_store(struct device *dev,
 	pid = coresight_vpid_to_pid(vpid);
 
 	spin_lock(&drvdata->spinlock);
-	drvdata->ctxid_pid[drvdata->ctxid_idx] = pid;
-	drvdata->ctxid_vpid[drvdata->ctxid_idx] = vpid;
+	config->ctxid_pid[config->ctxid_idx] = pid;
+	config->ctxid_vpid[config->ctxid_idx] = vpid;
 	spin_unlock(&drvdata->spinlock);
 
 	return size;
@@ -1013,8 +1057,9 @@ static ssize_t ctxid_mask_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->ctxid_mask;
+	val = config->ctxid_mask;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -1025,12 +1070,13 @@ static ssize_t ctxid_mask_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->ctxid_mask = val;
+	config->ctxid_mask = val;
 	return size;
 }
 static DEVICE_ATTR_RW(ctxid_mask);
@@ -1040,8 +1086,9 @@ static ssize_t sync_freq_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->sync_freq;
+	val = config->sync_freq;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -1052,12 +1099,13 @@ static ssize_t sync_freq_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->sync_freq = val & ETM_SYNC_MASK;
+	config->sync_freq = val & ETM_SYNC_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(sync_freq);
@@ -1067,8 +1115,9 @@ static ssize_t timestamp_event_show(struct device *dev,
 {
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
-	val = drvdata->timestamp_event;
+	val = config->timestamp_event;
 	return sprintf(buf, "%#lx\n", val);
 }
 
@@ -1079,12 +1128,13 @@ static ssize_t timestamp_event_store(struct device *dev,
 	int ret;
 	unsigned long val;
 	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+	struct etm_config *config = &drvdata->config;
 
 	ret = kstrtoul(buf, 16, &val);
 	if (ret)
 		return ret;
 
-	drvdata->timestamp_event = val & ETM_EVENT_MASK;
+	config->timestamp_event = val & ETM_EVENT_MASK;
 	return size;
 }
 static DEVICE_ATTR_RW(timestamp_event);
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index f2c74bb56993..1952dc31fee4 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -41,6 +41,7 @@ module_param_named(boot_enable, boot_enable, int, S_IRUGO);
 /* The number of ETM/PTM currently registered */
 static int etm_count;
 static struct etm_drvdata *etmdrvdata[NR_CPUS];
+static void etm_init_default_data(struct etm_config *config);
 
 /*
  * Memory mapped writes to clear os lock are not supported on some processors
@@ -186,36 +187,39 @@ static void etm_clr_prog(struct etm_drvdata *drvdata)
 	}
 }
 
-void etm_set_default(struct etm_drvdata *drvdata)
+void etm_set_default(struct etm_config *config)
 {
 	int i;
 
-	drvdata->trigger_event = ETM_DEFAULT_EVENT_VAL;
-	drvdata->enable_event = ETM_HARD_WIRE_RES_A;
-
-	drvdata->seq_12_event = ETM_DEFAULT_EVENT_VAL;
-	drvdata->seq_21_event = ETM_DEFAULT_EVENT_VAL;
-	drvdata->seq_23_event = ETM_DEFAULT_EVENT_VAL;
-	drvdata->seq_31_event = ETM_DEFAULT_EVENT_VAL;
-	drvdata->seq_32_event = ETM_DEFAULT_EVENT_VAL;
-	drvdata->seq_13_event = ETM_DEFAULT_EVENT_VAL;
-	drvdata->timestamp_event = ETM_DEFAULT_EVENT_VAL;
-
-	for (i = 0; i < drvdata->nr_cntr; i++) {
-		drvdata->cntr_rld_val[i] = 0x0;
-		drvdata->cntr_event[i] = ETM_DEFAULT_EVENT_VAL;
-		drvdata->cntr_rld_event[i] = ETM_DEFAULT_EVENT_VAL;
-		drvdata->cntr_val[i] = 0x0;
+	if (WARN_ON_ONCE(!config))
+		return;
+
+	config->trigger_event = ETM_DEFAULT_EVENT_VAL;
+	config->enable_event = ETM_HARD_WIRE_RES_A;
+
+	config->seq_12_event = ETM_DEFAULT_EVENT_VAL;
+	config->seq_21_event = ETM_DEFAULT_EVENT_VAL;
+	config->seq_23_event = ETM_DEFAULT_EVENT_VAL;
+	config->seq_31_event = ETM_DEFAULT_EVENT_VAL;
+	config->seq_32_event = ETM_DEFAULT_EVENT_VAL;
+	config->seq_13_event = ETM_DEFAULT_EVENT_VAL;
+	config->timestamp_event = ETM_DEFAULT_EVENT_VAL;
+
+	for (i = 0; i < ETM_MAX_CNTR; i++) {
+		config->cntr_rld_val[i] = 0x0;
+		config->cntr_event[i] = ETM_DEFAULT_EVENT_VAL;
+		config->cntr_rld_event[i] = ETM_DEFAULT_EVENT_VAL;
+		config->cntr_val[i] = 0x0;
 	}
 
-	drvdata->seq_curr_state = 0x0;
-	drvdata->ctxid_idx = 0x0;
-	for (i = 0; i < drvdata->nr_ctxid_cmp; i++) {
-		drvdata->ctxid_pid[i] = 0x0;
-		drvdata->ctxid_vpid[i] = 0x0;
+	config->seq_curr_state = 0x0;
+	config->ctxid_idx = 0x0;
+	for (i = 0; i < ETM_MAX_CTXID_CMP; i++) {
+		config->ctxid_pid[i] = 0x0;
+		config->ctxid_vpid[i] = 0x0;
 	}
 
-	drvdata->ctxid_mask = 0x0;
+	config->ctxid_mask = 0x0;
 }
 
 static void etm_enable_hw(void *info)
@@ -223,6 +227,7 @@ static void etm_enable_hw(void *info)
 	int i;
 	u32 etmcr;
 	struct etm_drvdata *drvdata = info;
+	struct etm_config *config = &drvdata->config;
 
 	CS_UNLOCK(drvdata->base);
 
@@ -238,39 +243,39 @@ static void etm_enable_hw(void *info)
 	etmcr = etm_readl(drvdata, ETMCR);
 	etmcr &= (ETMCR_PWD_DWN | ETMCR_ETM_PRG);
 	etmcr |= drvdata->port_size;
-	etm_writel(drvdata, drvdata->ctrl | etmcr, ETMCR);
-	etm_writel(drvdata, drvdata->trigger_event, ETMTRIGGER);
-	etm_writel(drvdata, drvdata->startstop_ctrl, ETMTSSCR);
-	etm_writel(drvdata, drvdata->enable_event, ETMTEEVR);
-	etm_writel(drvdata, drvdata->enable_ctrl1, ETMTECR1);
-	etm_writel(drvdata, drvdata->fifofull_level, ETMFFLR);
+	etm_writel(drvdata, config->ctrl | etmcr, ETMCR);
+	etm_writel(drvdata, config->trigger_event, ETMTRIGGER);
+	etm_writel(drvdata, config->startstop_ctrl, ETMTSSCR);
+	etm_writel(drvdata, config->enable_event, ETMTEEVR);
+	etm_writel(drvdata, config->enable_ctrl1, ETMTECR1);
+	etm_writel(drvdata, config->fifofull_level, ETMFFLR);
 	for (i = 0; i < drvdata->nr_addr_cmp; i++) {
-		etm_writel(drvdata, drvdata->addr_val[i], ETMACVRn(i));
-		etm_writel(drvdata, drvdata->addr_acctype[i], ETMACTRn(i));
+		etm_writel(drvdata, config->addr_val[i], ETMACVRn(i));
+		etm_writel(drvdata, config->addr_acctype[i], ETMACTRn(i));
 	}
 	for (i = 0; i < drvdata->nr_cntr; i++) {
-		etm_writel(drvdata, drvdata->cntr_rld_val[i], ETMCNTRLDVRn(i));
-		etm_writel(drvdata, drvdata->cntr_event[i], ETMCNTENRn(i));
-		etm_writel(drvdata, drvdata->cntr_rld_event[i],
+		etm_writel(drvdata, config->cntr_rld_val[i], ETMCNTRLDVRn(i));
+		etm_writel(drvdata, config->cntr_event[i], ETMCNTENRn(i));
+		etm_writel(drvdata, config->cntr_rld_event[i],
 			   ETMCNTRLDEVRn(i));
-		etm_writel(drvdata, drvdata->cntr_val[i], ETMCNTVRn(i));
+		etm_writel(drvdata, config->cntr_val[i], ETMCNTVRn(i));
 	}
-	etm_writel(drvdata, drvdata->seq_12_event, ETMSQ12EVR);
-	etm_writel(drvdata, drvdata->seq_21_event, ETMSQ21EVR);
-	etm_writel(drvdata, drvdata->seq_23_event, ETMSQ23EVR);
-	etm_writel(drvdata, drvdata->seq_31_event, ETMSQ31EVR);
-	etm_writel(drvdata, drvdata->seq_32_event, ETMSQ32EVR);
-	etm_writel(drvdata, drvdata->seq_13_event, ETMSQ13EVR);
-	etm_writel(drvdata, drvdata->seq_curr_state, ETMSQR);
+	etm_writel(drvdata, config->seq_12_event, ETMSQ12EVR);
+	etm_writel(drvdata, config->seq_21_event, ETMSQ21EVR);
+	etm_writel(drvdata, config->seq_23_event, ETMSQ23EVR);
+	etm_writel(drvdata, config->seq_31_event, ETMSQ31EVR);
+	etm_writel(drvdata, config->seq_32_event, ETMSQ32EVR);
+	etm_writel(drvdata, config->seq_13_event, ETMSQ13EVR);
+	etm_writel(drvdata, config->seq_curr_state, ETMSQR);
 	for (i = 0; i < drvdata->nr_ext_out; i++)
 		etm_writel(drvdata, ETM_DEFAULT_EVENT_VAL, ETMEXTOUTEVRn(i));
 	for (i = 0; i < drvdata->nr_ctxid_cmp; i++)
-		etm_writel(drvdata, drvdata->ctxid_pid[i], ETMCIDCVRn(i));
-	etm_writel(drvdata, drvdata->ctxid_mask, ETMCIDCMR);
-	etm_writel(drvdata, drvdata->sync_freq, ETMSYNCFR);
+		etm_writel(drvdata, config->ctxid_pid[i], ETMCIDCVRn(i));
+	etm_writel(drvdata, config->ctxid_mask, ETMCIDCMR);
+	etm_writel(drvdata, config->sync_freq, ETMSYNCFR);
 	/* No external input selected */
 	etm_writel(drvdata, 0x0, ETMEXTINSELR);
-	etm_writel(drvdata, drvdata->timestamp_event, ETMTSEVR);
+	etm_writel(drvdata, config->timestamp_event, ETMTSEVR);
 	/* No auxiliary control selected */
 	etm_writel(drvdata, 0x0, ETMAUXCR);
 	etm_writel(drvdata, drvdata->traceid, ETMTRACEIDR);
@@ -278,7 +283,7 @@ static void etm_enable_hw(void *info)
 	etm_writel(drvdata, 0x0, ETMVMIDCVR);
 
 	/* Ensures trace output is enabled from this ETM */
-	etm_writel(drvdata, drvdata->ctrl | ETMCR_ETM_EN | etmcr, ETMCR);
+	etm_writel(drvdata, config->ctrl | ETMCR_ETM_EN | etmcr, ETMCR);
 
 	etm_clr_prog(drvdata);
 	CS_LOCK(drvdata->base);
@@ -362,6 +367,7 @@ static void etm_disable_hw(void *info)
 {
 	int i;
 	struct etm_drvdata *drvdata = info;
+	struct etm_config *config = &drvdata->config;
 
 	CS_UNLOCK(drvdata->base);
 	etm_set_prog(drvdata);
@@ -370,10 +376,10 @@ static void etm_disable_hw(void *info)
 	etm_writel(drvdata, ETM_HARD_WIRE_RES_A | ETM_EVENT_NOT_A, ETMTEEVR);
 
 	/* Read back sequencer and counters for post trace analysis */
-	drvdata->seq_curr_state = (etm_readl(drvdata, ETMSQR) & ETM_SQR_MASK);
+	config->seq_curr_state = (etm_readl(drvdata, ETMSQR) & ETM_SQR_MASK);
 
 	for (i = 0; i < drvdata->nr_cntr; i++)
-		drvdata->cntr_val[i] = etm_readl(drvdata, ETMCNTVRn(i));
+		config->cntr_val[i] = etm_readl(drvdata, ETMCNTVRn(i));
 
 	etm_set_pwrdwn(drvdata);
 	CS_LOCK(drvdata->base);
@@ -522,14 +528,8 @@ static void etm_init_arch_data(void *info)
 	CS_LOCK(drvdata->base);
 }
 
-static void etm_init_default_data(struct etm_drvdata *drvdata)
+static void etm_init_default_data(struct etm_config *config)
 {
-	/*
-	 * A trace ID of value 0 is invalid, so let's start at some
-	 * random value that fits in 7 bits and will be just as good.
-	 */
-	static int etm3x_traceid = 0x10;
-
 	u32 flags = (1 << 0 | /* instruction execute*/
 		     3 << 3 | /* ARM instruction */
 		     0 << 5 | /* No data value comparison */
@@ -537,25 +537,28 @@ static void etm_init_default_data(struct etm_drvdata *drvdata)
 		     0 << 8 | /* Ignore context ID */
 		     0 << 10); /* Security ignored */
 
+	if (WARN_ON_ONCE(!config))
+		return;
+
+	config->ctrl = (ETMCR_CYC_ACC | ETMCR_TIMESTAMP_EN);
+	config->enable_ctrl1 = ETMTECR1_ADDR_COMP_1;
+	config->addr_val[0] = (u32) _stext;
+	config->addr_val[1] = (u32) _etext;
+	config->addr_acctype[0] = flags;
+	config->addr_acctype[1] = flags;
+	config->addr_type[0] = ETM_ADDR_TYPE_RANGE;
+	config->addr_type[1] = ETM_ADDR_TYPE_RANGE;
+
+	etm_set_default(config);
+}
+
+static void etm_init_trace_id(struct etm_drvdata *drvdata)
+{
 	/*
-	 * Initial configuration only - guarantees sources handled by
-	 * this driver have a unique ID at startup time but not between
-	 * all other types of sources.  For that we lean on the core
-	 * framework.
+	 * A trace ID of value 0 is invalid, so let's start at some
+	 * random value that fits in 7 bits and go from there.
 	 */
-	drvdata->traceid = etm3x_traceid++;
-	drvdata->ctrl = (ETMCR_CYC_ACC | ETMCR_TIMESTAMP_EN);
-	drvdata->enable_ctrl1 = ETMTECR1_ADDR_COMP_1;
-	if (drvdata->nr_addr_cmp >= 2) {
-		drvdata->addr_val[0] = (u32) _stext;
-		drvdata->addr_val[1] = (u32) _etext;
-		drvdata->addr_acctype[0] = flags;
-		drvdata->addr_acctype[1] = flags;
-		drvdata->addr_type[0] = ETM_ADDR_TYPE_RANGE;
-		drvdata->addr_type[1] = ETM_ADDR_TYPE_RANGE;
-	}
-
-	etm_set_default(drvdata);
+	drvdata->traceid = 0x10 + drvdata->cpu;
 }
 
 static int etm_probe(struct amba_device *adev, const struct amba_id *id)
@@ -623,7 +626,9 @@ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
 		ret = -EINVAL;
 		goto err_arch_supported;
 	}
-	etm_init_default_data(drvdata);
+
+	etm_init_trace_id(drvdata);
+	etm_init_default_data(&drvdata->config);
 
 	desc->type = CORESIGHT_DEV_TYPE_SOURCE;
 	desc->subtype.source_subtype = CORESIGHT_DEV_SUBTYPE_SOURCE_PROC;
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:52:01 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:52:01 -0700
Subject: [PATCH 19/21] coresight: etm-perf: new PMU driver for ETM tracers
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-20-git-send-email-mathieu.poirier@linaro.org>

Perf is a well known and used tool for performance monitoring
and much more. A such it is an ideal candidate for integration
with coresight based HW tracing.

This patch introduces a PMU that represent a coresight tracer to
the Perf core.

Cc: Alexander Shishkin <alexander.shishkin at linux.intel.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/Makefile             |   3 +-
 drivers/hwtracing/coresight/coresight-etm-perf.c | 393 +++++++++++++++++++++++
 drivers/hwtracing/coresight/coresight-etm-perf.h |  32 ++
 drivers/hwtracing/coresight/coresight-etm3x.c    |   7 +
 include/linux/coresight-pmu.h                    |  27 ++
 5 files changed, 461 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-etm-perf.c
 create mode 100644 drivers/hwtracing/coresight/coresight-etm-perf.h
 create mode 100644 include/linux/coresight-pmu.h

diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 233d66cf22d3..cf8c6d689747 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_CORESIGHT_SINK_ETBV10) += coresight-etb10.o
 obj-$(CONFIG_CORESIGHT_LINKS_AND_SINKS) += coresight-funnel.o \
 					   coresight-replicator.o
 obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o coresight-etm-cp14.o \
-					coresight-etm3x-sysfs.o
+					coresight-etm3x-sysfs.o \
+					coresight-etm-perf.o
 obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
 obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
new file mode 100644
index 000000000000..36153a77e982
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -0,0 +1,393 @@
+/*
+ * Copyright(C) 2015 Linaro Limited. All rights reserved.
+ * Author: Mathieu Poirier <mathieu.poirier at linaro.org>
+ *
+ * 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/coresight.h>
+#include <linux/coresight-pmu.h>
+#include <linux/cpumask.h>
+#include <linux/device.h>
+#include <linux/list.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/perf_event.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+#include <linux/workqueue.h>
+
+#include "coresight-priv.h"
+
+static struct pmu etm_pmu;
+static bool etm_perf_up;
+
+/**
+ * struct etm_event_data - Coresight specifics associated to an event
+ * @work:		Handle to free allocated memory outside IRQ context.
+ * @mask:		Hold the CPU(s) this event was set for.
+ * @snk_config:		The sink configuration.
+ * @path:		An array of path, each slot for one CPU.
+ */
+struct etm_event_data {
+	struct work_struct work;
+	cpumask_t mask;
+	void *snk_config;
+	struct list_head **path;
+};
+
+static DEFINE_PER_CPU(struct perf_output_handle, ctx_handle);
+static DEFINE_PER_CPU(struct coresight_device *, csdev_src);
+
+/* ETMv3.5/PTM's ETMCR is 'config' */
+PMU_FORMAT_ATTR(cycacc,		"config:" __stringify(ETM_OPT_CYCACC));
+PMU_FORMAT_ATTR(timestamp,	"config:" __stringify(ETM_OPT_TS));
+
+static struct attribute *etm_config_formats_attr[] = {
+	&format_attr_cycacc.attr,
+	&format_attr_timestamp.attr,
+	NULL,
+};
+
+static struct attribute_group etm_pmu_format_group = {
+	.name   = "format",
+	.attrs  = etm_config_formats_attr,
+};
+
+static const struct attribute_group *etm_pmu_attr_groups[] = {
+	&etm_pmu_format_group,
+	NULL,
+};
+
+static void etm_event_read(struct perf_event *event) {}
+
+static int etm_event_init(struct perf_event *event)
+{
+	if (event->attr.type != etm_pmu.type)
+		return -ENOENT;
+
+	return 0;
+}
+
+static void free_event_data(struct work_struct *work)
+{
+	int cpu;
+	cpumask_t *mask;
+	struct etm_event_data *event_data;
+	struct coresight_device *sink;
+
+	event_data = container_of(work, struct etm_event_data, work);
+	mask = &event_data->mask;
+	/*
+	 * First deal with the sink configuration.  See comment in
+	 * etm_setup_aux() about why we take the first available path.
+	 */
+	if (event_data->snk_config) {
+		cpu = cpumask_first(mask);
+		sink = coresight_get_sink(event_data->path[cpu]);
+		if (sink_ops(sink)->free_buffer)
+			sink_ops(sink)->free_buffer(event_data->snk_config);
+	}
+
+	for_each_cpu(cpu, mask) {
+		if (event_data->path[cpu])
+			coresight_release_path(event_data->path[cpu]);
+	}
+
+	kfree(event_data->path);
+	kfree(event_data);
+}
+
+static void *alloc_event_data(int cpu)
+{
+	int size;
+	cpumask_t *mask;
+	struct etm_event_data *event_data;
+
+	/* First get memory for the session's data */
+	event_data = kzalloc(sizeof(struct etm_event_data), GFP_KERNEL);
+	if (!event_data)
+		return NULL;
+
+	/* Make sure nothing disappears under us */
+	get_online_cpus();
+	size = num_online_cpus();
+
+	mask = &event_data->mask;
+	if (cpu != -1)
+		cpumask_set_cpu(cpu, mask);
+	else
+		cpumask_copy(mask, cpu_online_mask);
+	put_online_cpus();
+
+	/*
+	 * Each CPU has a single path between source and destination.  As such
+	 * allocate an array using CPU numbers as indexes.  That way a path
+	 * for any CPU can easily be accessed at any given time.  We proceed
+	 * the same way for sessions involving a single CPU.  The cost of
+	 * unused memory when dealing with single CPU trace scenarios is small
+	 * compared to the cost of searching through an optimized array.
+	 */
+	event_data->path = kcalloc(size,
+				   sizeof(struct list_head *), GFP_KERNEL);
+	if (!event_data->path) {
+		kfree(event_data);
+		return NULL;
+	}
+
+	return event_data;
+}
+
+static void etm_free_aux(void *data)
+{
+	struct etm_event_data *event_data = data;
+
+	schedule_work(&event_data->work);
+}
+
+static void *etm_setup_aux(int event_cpu, void **pages,
+			   int nr_pages, bool overwrite)
+{
+	int cpu;
+	cpumask_t *mask;
+	struct coresight_device *sink;
+	struct etm_event_data *event_data = NULL;
+
+	event_data = alloc_event_data(event_cpu);
+	if (!event_data)
+		return NULL;
+
+	INIT_WORK(&event_data->work, free_event_data);
+
+	mask = &event_data->mask;
+
+	/* Setup the path for each CPU in a trace session */
+	for_each_cpu(cpu, mask) {
+		struct coresight_device *csdev;
+
+		csdev = per_cpu(csdev_src, cpu);
+		if (!csdev)
+			goto err;
+
+		/*
+		 * Building a path doesn't enable it, it simply builds a
+		 * list of devices from source to sink that can be
+		 * referenced later when the path is actually needed.
+		 */
+		event_data->path[cpu] = coresight_build_path(csdev);
+		if (!event_data->path[cpu])
+			goto err;
+	}
+
+	/*
+	 * In theory nothing prevent tracers in a trace session from being
+	 * associated with different sinks, nor having a sink per tracer.  But
+	 * until we have HW with this kind of topology and a way to convey
+	 * sink assignement from the perf cmd line we need to assume tracers
+	 * in a trace session are using the same sink.  Therefore pick the sink
+	 * found at the end of the first available path.
+	 */
+	cpu = cpumask_first(mask);
+	/* Grab the sink at the end of the path */
+	sink = coresight_get_sink(event_data->path[cpu]);
+	if (!sink)
+		goto err;
+
+	if (!sink_ops(sink)->alloc_buffer)
+		goto err;
+
+	/* Get the AUX specific data from the sink buffer */
+	event_data->snk_config =
+			sink_ops(sink)->alloc_buffer(sink, cpu, pages,
+						     nr_pages, overwrite);
+	if (!event_data->snk_config)
+		goto err;
+
+out:
+	return event_data;
+
+err:
+	etm_free_aux(event_data);
+	event_data = NULL;
+	goto out;
+}
+
+static void etm_event_start(struct perf_event *event, int flags)
+{
+	int cpu = smp_processor_id();
+	struct etm_event_data *event_data;
+	struct perf_output_handle *handle = this_cpu_ptr(&ctx_handle);
+	struct coresight_device *sink, *csdev = per_cpu(csdev_src, cpu);
+
+	if (!csdev)
+		goto fail;
+
+	/*
+	 * Deal with the ring buffer API and get a handle on the
+	 * session's information.
+	 */
+	event_data = perf_aux_output_begin(handle, event);
+	if (!event_data)
+		goto fail;
+
+	/* We need a sink, no need to continue without one */
+	sink = coresight_get_sink(event_data->path[cpu]);
+	if (WARN_ON_ONCE(!sink || !sink_ops(sink)->set_buffer))
+		goto fail_end_stop;
+
+	/* Configure the sink */
+	if (sink_ops(sink)->set_buffer(sink, handle,
+				       event_data->snk_config))
+		goto fail_end_stop;
+
+	/* Nothing will happen without a path */
+	if (coresight_enable_path(event_data->path[cpu], CS_MODE_PERF))
+		goto fail_end_stop;
+
+	/* Tell the perf core the event is alive */
+	event->hw.state = 0;
+
+	/* Finally enable the tracer */
+	if (source_ops(csdev)->enable(csdev, &event->attr, CS_MODE_PERF))
+		goto fail_end_stop;
+
+out:
+	return;
+
+fail_end_stop:
+	perf_aux_output_end(handle, 0, true);
+fail:
+	event->hw.state = PERF_HES_STOPPED;
+	goto out;
+}
+
+static void etm_event_stop(struct perf_event *event, int mode)
+{
+	bool lost;
+	int cpu = smp_processor_id();
+	unsigned long size;
+	struct coresight_device *sink, *csdev = per_cpu(csdev_src, cpu);
+	struct perf_output_handle *handle = this_cpu_ptr(&ctx_handle);
+	struct etm_event_data *event_data = perf_get_aux(handle);
+
+	if (event->hw.state == PERF_HES_STOPPED)
+		return;
+
+	if (!csdev)
+		return;
+
+	sink = coresight_get_sink(event_data->path[cpu]);
+	if (!sink)
+		return;
+
+	/* stop tracer */
+	source_ops(csdev)->disable(csdev);
+
+	/* tell the core */
+	event->hw.state = PERF_HES_STOPPED;
+
+	if (mode & PERF_EF_UPDATE) {
+		if (WARN_ON_ONCE(handle->event != event))
+			return;
+
+		/* update trace information */
+		if (!sink_ops(sink)->update_buffer)
+			return;
+
+		sink_ops(sink)->update_buffer(sink, handle,
+					      event_data->snk_config);
+
+		if (!sink_ops(sink)->reset_buffer)
+			return;
+
+		size = sink_ops(sink)->reset_buffer(sink, handle,
+						    event_data->snk_config,
+						    &lost);
+
+		perf_aux_output_end(handle, size, lost);
+	}
+
+	/* Disabling the path make its elements available to other sessions */
+	coresight_disable_path(event_data->path[cpu]);
+}
+
+static int etm_event_add(struct perf_event *event, int mode)
+{
+	int ret = 0;
+	struct hw_perf_event *hwc = &event->hw;
+
+	if (mode & PERF_EF_START) {
+		etm_event_start(event, 0);
+		if (hwc->state & PERF_HES_STOPPED)
+			ret = -EINVAL;
+	} else {
+		hwc->state = PERF_HES_STOPPED;
+	}
+
+	return ret;
+}
+
+static void etm_event_del(struct perf_event *event, int mode)
+{
+	etm_event_stop(event, PERF_EF_UPDATE);
+}
+
+int etm_perf_symlink(struct coresight_device *csdev, bool link)
+{
+	char entry[sizeof("cpu9999999")];
+	int ret = 0, cpu = source_ops(csdev)->cpu_id(csdev);
+	struct device *pmu_dev = etm_pmu.dev;
+	struct device *cs_dev = &csdev->dev;
+
+	sprintf(entry, "cpu%d", cpu);
+
+	if (!etm_perf_up)
+		return -EPROBE_DEFER;
+
+	if (link) {
+		ret = sysfs_create_link(&pmu_dev->kobj, &cs_dev->kobj, entry);
+		if (ret)
+			return ret;
+		per_cpu(csdev_src, cpu) = csdev;
+	} else {
+		sysfs_remove_link(&pmu_dev->kobj, entry);
+		per_cpu(csdev_src, cpu) = NULL;
+	}
+
+	return 0;
+}
+
+static int __init etm_perf_init(void)
+{
+	int ret;
+
+	etm_pmu.capabilities	= PERF_PMU_CAP_EXCLUSIVE;
+
+	etm_pmu.attr_groups	= etm_pmu_attr_groups;
+	etm_pmu.task_ctx_nr	= perf_sw_context;
+	etm_pmu.read		= etm_event_read;
+	etm_pmu.event_init	= etm_event_init;
+	etm_pmu.setup_aux	= etm_setup_aux;
+	etm_pmu.free_aux	= etm_free_aux;
+	etm_pmu.start		= etm_event_start;
+	etm_pmu.stop		= etm_event_stop;
+	etm_pmu.add		= etm_event_add;
+	etm_pmu.del		= etm_event_del;
+
+	ret = perf_pmu_register(&etm_pmu, CORESIGHT_ETM_PMU_NAME, -1);
+	if (ret == 0)
+		etm_perf_up = true;
+
+	return ret;
+}
+module_init(etm_perf_init);
diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.h b/drivers/hwtracing/coresight/coresight-etm-perf.h
new file mode 100644
index 000000000000..87f5a134eb6f
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright(C) 2015 Linaro Limited. All rights reserved.
+ * Author: Mathieu Poirier <mathieu.poirier at linaro.org>
+ *
+ * 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/>.
+ */
+
+#ifndef _CORESIGHT_ETM_PERF_H
+#define _CORESIGHT_ETM_PERF_H
+
+struct coresight_device;
+
+#ifdef CONFIG_CORESIGHT
+int etm_perf_symlink(struct coresight_device *csdev, bool link);
+
+#else
+static inline int etm_perf_symlink(struct coresight_device *csdev, bool link)
+{ return -EINVAL; }
+
+#endif /* CONFIG_CORESIGHT */
+
+#endif
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index a9b820ec16aa..77b37413803f 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -35,6 +35,7 @@
 #include <asm/sections.h>
 
 #include "coresight-etm.h"
+#include "coresight-etm-perf.h"
 
 static int boot_enable;
 module_param_named(boot_enable, boot_enable, int, S_IRUGO);
@@ -827,6 +828,12 @@ static int etm_probe(struct amba_device *adev, const struct amba_id *id)
 		goto err_arch_supported;
 	}
 
+	ret = etm_perf_symlink(drvdata->csdev, true);
+	if (ret) {
+		coresight_unregister(drvdata->csdev);
+		goto err_arch_supported;
+	}
+
 	pm_runtime_put(&adev->dev);
 	dev_info(dev, "%s initialized\n", (char *)id->data);
 
diff --git a/include/linux/coresight-pmu.h b/include/linux/coresight-pmu.h
new file mode 100644
index 000000000000..6c5386b23b10
--- /dev/null
+++ b/include/linux/coresight-pmu.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright(C) 2015 Linaro Limited. All rights reserved.
+ * Author: Mathieu Poirier <mathieu.poirier at linaro.org>
+ *
+ * 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/>.
+ */
+
+#ifndef _LINUX_CORESIGHT_PMU_H
+#define _LINUX_CORESIGHT_PMU_H
+
+#define CORESIGHT_ETM_PMU_NAME "cs_etm"
+
+/* ETMv3.5/PTM's ETMCR config bit */
+#define ETM_OPT_CYCACC  12
+#define ETM_OPT_TS      28
+
+#endif
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:52:03 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:52:03 -0700
Subject: [PATCH 21/21] drivers/hwtracing: make coresight-* explicitly
 non-modular
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-22-git-send-email-mathieu.poirier@linaro.org>

From: Paul Gortmaker <paul.gortmaker at windriver.com>

None of the Kconfig currently controlling compilation of any of
the files here are tristate, meaning that none of it currently
is being built as a module by anyone.

We need not be concerned about .remove functions and blocking the
unbind sysfs operations, since that was already done in a recent
commit.

Lets remove any remaining modular references, so that when reading the
drivers there is no doubt they are builtin-only.

All drivers get mostly the same changes, so they are handled in batch.
Changes are (1) convert to builtin_amba_driver, (2) delete module.h
include where unused, and (3) relocate the description into the
comments so we don't need MODULE_DESCRIPTION and associated tags.

The etm3x and etm4x use module_param_named, and have been adjusted
to just include moduleparam.h for that purpose.

In commit f309d4443130bf814e991f836e919dca22df37ae ("platform_device:
better support builtin boilerplate avoidance") we introduced the
builtin_driver macro.

Here we use that support and extend it to amba driver registration,
so where a driver is clearly non-modular and builtin-only, we can
update with the simple mapping of

     module_amba_driver(...)  ---> builtin_amba_driver(...)

Since module_amba_driver() uses the same init level priority as
builtin_amba_driver() the init ordering remains unchanged with
this commit.

Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>
---
 drivers/hwtracing/coresight/coresight-etb10.c           |  9 +++------
 drivers/hwtracing/coresight/coresight-etm3x.c           | 14 ++++++++------
 drivers/hwtracing/coresight/coresight-etm4x.c           |  4 +---
 drivers/hwtracing/coresight/coresight-funnel.c          |  9 +++------
 drivers/hwtracing/coresight/coresight-replicator-qcom.c |  4 +---
 drivers/hwtracing/coresight/coresight-replicator.c      |  7 ++-----
 drivers/hwtracing/coresight/coresight-tmc.c             |  9 +++------
 drivers/hwtracing/coresight/coresight-tpiu.c            |  9 +++------
 drivers/hwtracing/coresight/coresight.c                 |  3 ---
 drivers/hwtracing/coresight/of_coresight.c              |  1 -
 include/linux/amba/bus.h                                |  9 +++++++++
 11 files changed, 33 insertions(+), 45 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c b/drivers/hwtracing/coresight/coresight-etb10.c
index a2eb6bdeaafa..acbce79934d6 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -1,5 +1,7 @@
 /* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
  *
+ * Description: CoreSight Embedded Trace Buffer driver
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
  * only version 2 as published by the Free Software Foundation.
@@ -12,7 +14,6 @@
 
 #include <asm/local.h>
 #include <linux/kernel.h>
-#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/device.h>
@@ -781,8 +782,4 @@ static struct amba_driver etb_driver = {
 	.probe		= etb_probe,
 	.id_table	= etb_ids,
 };
-
-module_amba_driver(etb_driver);
-
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("CoreSight Embedded Trace Buffer driver");
+builtin_amba_driver(etb_driver);
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index 0ba1a3981373..d83ab82672e4 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -1,5 +1,7 @@
 /* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
  *
+ * Description: CoreSight Program Flow Trace driver
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
  * only version 2 as published by the Free Software Foundation.
@@ -11,7 +13,7 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/module.h>
+#include <linux/moduleparam.h>
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/device.h>
@@ -38,6 +40,10 @@
 #include "coresight-etm.h"
 #include "coresight-etm-perf.h"
 
+/*
+ * Not really modular but using module_param is the easiest way to
+ * remain consistent with existing use cases for now.
+ */
 static int boot_enable;
 module_param_named(boot_enable, boot_enable, int, S_IRUGO);
 
@@ -912,8 +918,4 @@ static struct amba_driver etm_driver = {
 	.probe		= etm_probe,
 	.id_table	= etm_ids,
 };
-
-module_amba_driver(etm_driver);
-
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("CoreSight Program Flow Trace driver");
+builtin_amba_driver(etm_driver);
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
index d0169ba7fbf2..1c59bd36834c 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -15,7 +15,6 @@
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/device.h>
-#include <linux/module.h>
 #include <linux/io.h>
 #include <linux/err.h>
 #include <linux/fs.h>
@@ -2710,5 +2709,4 @@ static struct amba_driver etm4x_driver = {
 	.probe		= etm4_probe,
 	.id_table	= etm4_ids,
 };
-
-module_amba_driver(etm4x_driver);
+builtin_amba_driver(etm4x_driver);
diff --git a/drivers/hwtracing/coresight/coresight-funnel.c b/drivers/hwtracing/coresight/coresight-funnel.c
index fb2c679fbc44..0600ca30649d 100644
--- a/drivers/hwtracing/coresight/coresight-funnel.c
+++ b/drivers/hwtracing/coresight/coresight-funnel.c
@@ -1,5 +1,7 @@
 /* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
  *
+ * Description: CoreSight Funnel driver
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
  * only version 2 as published by the Free Software Foundation.
@@ -11,7 +13,6 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/device.h>
@@ -268,8 +269,4 @@ static struct amba_driver funnel_driver = {
 	.probe		= funnel_probe,
 	.id_table	= funnel_ids,
 };
-
-module_amba_driver(funnel_driver);
-
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("CoreSight Funnel driver");
+builtin_amba_driver(funnel_driver);
diff --git a/drivers/hwtracing/coresight/coresight-replicator-qcom.c b/drivers/hwtracing/coresight/coresight-replicator-qcom.c
index 286f90b50989..700f710e4bfa 100644
--- a/drivers/hwtracing/coresight/coresight-replicator-qcom.c
+++ b/drivers/hwtracing/coresight/coresight-replicator-qcom.c
@@ -15,7 +15,6 @@
 #include <linux/clk.h>
 #include <linux/coresight.h>
 #include <linux/device.h>
-#include <linux/module.h>
 #include <linux/err.h>
 #include <linux/init.h>
 #include <linux/io.h>
@@ -198,5 +197,4 @@ static struct amba_driver replicator_driver = {
 	.probe		= replicator_probe,
 	.id_table	= replicator_ids,
 };
-
-module_amba_driver(replicator_driver);
+builtin_amba_driver(replicator_driver);
diff --git a/drivers/hwtracing/coresight/coresight-replicator.c b/drivers/hwtracing/coresight/coresight-replicator.c
index 0ce98903992c..4299c0569340 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -1,5 +1,7 @@
 /* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
  *
+ * Description: CoreSight Replicator driver
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
  * only version 2 as published by the Free Software Foundation.
@@ -11,7 +13,6 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/module.h>
 #include <linux/device.h>
 #include <linux/platform_device.h>
 #include <linux/io.h>
@@ -166,8 +167,4 @@ static struct platform_driver replicator_driver = {
 		.suppress_bind_attrs = true,
 	},
 };
-
 builtin_platform_driver(replicator_driver);
-
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("CoreSight Replicator driver");
diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
index ac91b0b40ec2..1be191f5d39c 100644
--- a/drivers/hwtracing/coresight/coresight-tmc.c
+++ b/drivers/hwtracing/coresight/coresight-tmc.c
@@ -1,5 +1,7 @@
 /* Copyright (c) 2012, The Linux Foundation. All rights reserved.
  *
+ * Description: CoreSight Trace Memory Controller driver
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
  * only version 2 as published by the Free Software Foundation.
@@ -11,7 +13,6 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/device.h>
@@ -782,8 +783,4 @@ static struct amba_driver tmc_driver = {
 	.probe		= tmc_probe,
 	.id_table	= tmc_ids,
 };
-
-module_amba_driver(tmc_driver);
-
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("CoreSight Trace Memory Controller driver");
+builtin_amba_driver(tmc_driver);
diff --git a/drivers/hwtracing/coresight/coresight-tpiu.c b/drivers/hwtracing/coresight/coresight-tpiu.c
index 71582f6dfd4c..8fb09d9237ab 100644
--- a/drivers/hwtracing/coresight/coresight-tpiu.c
+++ b/drivers/hwtracing/coresight/coresight-tpiu.c
@@ -1,5 +1,7 @@
 /* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
  *
+ * Description: CoreSight Trace Port Interface Unit driver
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
  * only version 2 as published by the Free Software Foundation.
@@ -11,7 +13,6 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/device.h>
 #include <linux/io.h>
@@ -218,8 +219,4 @@ static struct amba_driver tpiu_driver = {
 	.probe		= tpiu_probe,
 	.id_table	= tpiu_ids,
 };
-
-module_amba_driver(tpiu_driver);
-
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("CoreSight Trace Port Interface Unit driver");
+builtin_amba_driver(tpiu_driver);
diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
index 6ec2b66af9ee..2ea5961092c1 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -11,7 +11,6 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/device.h>
@@ -894,5 +893,3 @@ void coresight_unregister(struct coresight_device *csdev)
 	device_unregister(&csdev->dev);
 }
 EXPORT_SYMBOL_GPL(coresight_unregister);
-
-MODULE_LICENSE("GPL v2");
diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
index 3cc57c1e3b5d..b68da1888fd5 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -10,7 +10,6 @@
  * GNU General Public License for more details.
  */
 
-#include <linux/module.h>
 #include <linux/types.h>
 #include <linux/err.h>
 #include <linux/slab.h>
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 9006c4e75cf7..3d8dcdd1aeae 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -163,4 +163,13 @@ struct amba_device name##_device = {				\
 #define module_amba_driver(__amba_drv) \
 	module_driver(__amba_drv, amba_driver_register, amba_driver_unregister)
 
+/*
+ * builtin_amba_driver() - Helper macro for drivers that don't do anything
+ * special in driver initcall.  This eliminates a lot of boilerplate.  Each
+ * driver may only use this macro once, and calling it replaces the instance
+ * device_initcall().
+ */
+#define builtin_amba_driver(__amba_drv) \
+	builtin_driver(__amba_drv, amba_driver_register)
+
 #endif
-- 
2.1.4



From mathieu.poirier at linaro.org  Wed Feb 17 16:51:49 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 17 Feb 2016 17:51:49 -0700
Subject: [PATCH 07/21] coresight: etm3x: moving sysFS entries to dedicated file
In-Reply-To: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
References: <1455756723-8456-1-git-send-email-mathieu.poirier@linaro.org>
Message-ID: <1455756723-8456-8-git-send-email-mathieu.poirier@linaro.org>

SysFS entries are big enough to justify their own file.
As such moving all sysFS related declarations to a dedicated
location.

Signed-off-by: Mathieu Poirier <mathieu.poirier at linaro.org>
---
 drivers/hwtracing/coresight/Makefile               |    3 +-
 drivers/hwtracing/coresight/coresight-etm.h        |    4 +
 .../hwtracing/coresight/coresight-etm3x-sysfs.c    | 1218 +++++++++++++++++++
 drivers/hwtracing/coresight/coresight-etm3x.c      | 1234 +-------------------
 4 files changed, 1241 insertions(+), 1218 deletions(-)
 create mode 100644 drivers/hwtracing/coresight/coresight-etm3x-sysfs.c

diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
index 99f8e5f6256e..233d66cf22d3 100644
--- a/drivers/hwtracing/coresight/Makefile
+++ b/drivers/hwtracing/coresight/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CORESIGHT_SINK_TPIU) += coresight-tpiu.o
 obj-$(CONFIG_CORESIGHT_SINK_ETBV10) += coresight-etb10.o
 obj-$(CONFIG_CORESIGHT_LINKS_AND_SINKS) += coresight-funnel.o \
 					   coresight-replicator.o
-obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o coresight-etm-cp14.o
+obj-$(CONFIG_CORESIGHT_SOURCE_ETM3X) += coresight-etm3x.o coresight-etm-cp14.o \
+					coresight-etm3x-sysfs.o
 obj-$(CONFIG_CORESIGHT_SOURCE_ETM4X) += coresight-etm4x.o
 obj-$(CONFIG_CORESIGHT_QCOM_REPLICATOR) += coresight-replicator-qcom.o
diff --git a/drivers/hwtracing/coresight/coresight-etm.h b/drivers/hwtracing/coresight/coresight-etm.h
index 34f7db881fa7..9a30aa392ed9 100644
--- a/drivers/hwtracing/coresight/coresight-etm.h
+++ b/drivers/hwtracing/coresight/coresight-etm.h
@@ -280,4 +280,8 @@ static inline unsigned int etm_readl(struct etm_drvdata *drvdata, u32 off)
 
 	return val;
 }
+
+extern const struct attribute_group *coresight_etm_groups[];
+int etm_get_trace_id(struct etm_drvdata *drvdata);
+void etm_set_default(struct etm_drvdata *drvdata);
 #endif
diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
new file mode 100644
index 000000000000..f409f5a88e95
--- /dev/null
+++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
@@ -0,0 +1,1218 @@
+/*
+ * Copyright(C) 2015 Linaro Limited. All rights reserved.
+ * Author: Mathieu Poirier <mathieu.poirier at linaro.org>
+ *
+ * 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/pm_runtime.h>
+#include <linux/sysfs.h>
+#include "coresight-etm.h"
+
+static ssize_t nr_addr_cmp_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->nr_addr_cmp;
+	return sprintf(buf, "%#lx\n", val);
+}
+static DEVICE_ATTR_RO(nr_addr_cmp);
+
+static ssize_t nr_cntr_show(struct device *dev,
+			    struct device_attribute *attr, char *buf)
+{	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->nr_cntr;
+	return sprintf(buf, "%#lx\n", val);
+}
+static DEVICE_ATTR_RO(nr_cntr);
+
+static ssize_t nr_ctxid_cmp_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->nr_ctxid_cmp;
+	return sprintf(buf, "%#lx\n", val);
+}
+static DEVICE_ATTR_RO(nr_ctxid_cmp);
+
+static ssize_t etmsr_show(struct device *dev,
+			  struct device_attribute *attr, char *buf)
+{
+	unsigned long flags, val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	pm_runtime_get_sync(drvdata->dev);
+	spin_lock_irqsave(&drvdata->spinlock, flags);
+	CS_UNLOCK(drvdata->base);
+
+	val = etm_readl(drvdata, ETMSR);
+
+	CS_LOCK(drvdata->base);
+	spin_unlock_irqrestore(&drvdata->spinlock, flags);
+	pm_runtime_put(drvdata->dev);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+static DEVICE_ATTR_RO(etmsr);
+
+static ssize_t reset_store(struct device *dev,
+			   struct device_attribute *attr,
+			   const char *buf, size_t size)
+{
+	int i, ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	if (val) {
+		spin_lock(&drvdata->spinlock);
+		drvdata->mode = ETM_MODE_EXCLUDE;
+		drvdata->ctrl = 0x0;
+		drvdata->trigger_event = ETM_DEFAULT_EVENT_VAL;
+		drvdata->startstop_ctrl = 0x0;
+		drvdata->addr_idx = 0x0;
+		for (i = 0; i < drvdata->nr_addr_cmp; i++) {
+			drvdata->addr_val[i] = 0x0;
+			drvdata->addr_acctype[i] = 0x0;
+			drvdata->addr_type[i] = ETM_ADDR_TYPE_NONE;
+		}
+		drvdata->cntr_idx = 0x0;
+
+		etm_set_default(drvdata);
+		spin_unlock(&drvdata->spinlock);
+	}
+
+	return size;
+}
+static DEVICE_ATTR_WO(reset);
+
+static ssize_t mode_show(struct device *dev,
+			 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->mode;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t mode_store(struct device *dev,
+			  struct device_attribute *attr,
+			  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->mode = val & ETM_MODE_ALL;
+
+	if (drvdata->mode & ETM_MODE_EXCLUDE)
+		drvdata->enable_ctrl1 |= ETMTECR1_INC_EXC;
+	else
+		drvdata->enable_ctrl1 &= ~ETMTECR1_INC_EXC;
+
+	if (drvdata->mode & ETM_MODE_CYCACC)
+		drvdata->ctrl |= ETMCR_CYC_ACC;
+	else
+		drvdata->ctrl &= ~ETMCR_CYC_ACC;
+
+	if (drvdata->mode & ETM_MODE_STALL) {
+		if (!(drvdata->etmccr & ETMCCR_FIFOFULL)) {
+			dev_warn(drvdata->dev, "stall mode not supported\n");
+			ret = -EINVAL;
+			goto err_unlock;
+		}
+		drvdata->ctrl |= ETMCR_STALL_MODE;
+	 } else
+		drvdata->ctrl &= ~ETMCR_STALL_MODE;
+
+	if (drvdata->mode & ETM_MODE_TIMESTAMP) {
+		if (!(drvdata->etmccer & ETMCCER_TIMESTAMP)) {
+			dev_warn(drvdata->dev, "timestamp not supported\n");
+			ret = -EINVAL;
+			goto err_unlock;
+		}
+		drvdata->ctrl |= ETMCR_TIMESTAMP_EN;
+	} else
+		drvdata->ctrl &= ~ETMCR_TIMESTAMP_EN;
+
+	if (drvdata->mode & ETM_MODE_CTXID)
+		drvdata->ctrl |= ETMCR_CTXID_SIZE;
+	else
+		drvdata->ctrl &= ~ETMCR_CTXID_SIZE;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+
+err_unlock:
+	spin_unlock(&drvdata->spinlock);
+	return ret;
+}
+static DEVICE_ATTR_RW(mode);
+
+static ssize_t trigger_event_show(struct device *dev,
+				  struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->trigger_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t trigger_event_store(struct device *dev,
+				   struct device_attribute *attr,
+				   const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->trigger_event = val & ETM_EVENT_MASK;
+
+	return size;
+}
+static DEVICE_ATTR_RW(trigger_event);
+
+static ssize_t enable_event_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->enable_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t enable_event_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->enable_event = val & ETM_EVENT_MASK;
+
+	return size;
+}
+static DEVICE_ATTR_RW(enable_event);
+
+static ssize_t fifofull_level_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->fifofull_level;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t fifofull_level_store(struct device *dev,
+				    struct device_attribute *attr,
+				    const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->fifofull_level = val;
+
+	return size;
+}
+static DEVICE_ATTR_RW(fifofull_level);
+
+static ssize_t addr_idx_show(struct device *dev,
+			     struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->addr_idx;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t addr_idx_store(struct device *dev,
+			      struct device_attribute *attr,
+			      const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	if (val >= drvdata->nr_addr_cmp)
+		return -EINVAL;
+
+	/*
+	 * Use spinlock to ensure index doesn't change while it gets
+	 * dereferenced multiple times within a spinlock block elsewhere.
+	 */
+	spin_lock(&drvdata->spinlock);
+	drvdata->addr_idx = val;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(addr_idx);
+
+static ssize_t addr_single_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	u8 idx;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
+		spin_unlock(&drvdata->spinlock);
+		return -EINVAL;
+	}
+
+	val = drvdata->addr_val[idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t addr_single_store(struct device *dev,
+				 struct device_attribute *attr,
+				 const char *buf, size_t size)
+{
+	u8 idx;
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
+		spin_unlock(&drvdata->spinlock);
+		return -EINVAL;
+	}
+
+	drvdata->addr_val[idx] = val;
+	drvdata->addr_type[idx] = ETM_ADDR_TYPE_SINGLE;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(addr_single);
+
+static ssize_t addr_range_show(struct device *dev,
+			       struct device_attribute *attr, char *buf)
+{
+	u8 idx;
+	unsigned long val1, val2;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (idx % 2 != 0) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+	if (!((drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
+	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
+	      (drvdata->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
+	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+
+	val1 = drvdata->addr_val[idx];
+	val2 = drvdata->addr_val[idx + 1];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx %#lx\n", val1, val2);
+}
+
+static ssize_t addr_range_store(struct device *dev,
+			      struct device_attribute *attr,
+			      const char *buf, size_t size)
+{
+	u8 idx;
+	unsigned long val1, val2;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	if (sscanf(buf, "%lx %lx", &val1, &val2) != 2)
+		return -EINVAL;
+	/* Lower address comparator cannot have a higher address value */
+	if (val1 > val2)
+		return -EINVAL;
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (idx % 2 != 0) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+	if (!((drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
+	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
+	      (drvdata->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
+	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+
+	drvdata->addr_val[idx] = val1;
+	drvdata->addr_type[idx] = ETM_ADDR_TYPE_RANGE;
+	drvdata->addr_val[idx + 1] = val2;
+	drvdata->addr_type[idx + 1] = ETM_ADDR_TYPE_RANGE;
+	drvdata->enable_ctrl1 |= (1 << (idx/2));
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(addr_range);
+
+static ssize_t addr_start_show(struct device *dev,
+			       struct device_attribute *attr, char *buf)
+{
+	u8 idx;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_START)) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+
+	val = drvdata->addr_val[idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t addr_start_store(struct device *dev,
+				struct device_attribute *attr,
+				const char *buf, size_t size)
+{
+	u8 idx;
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_START)) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+
+	drvdata->addr_val[idx] = val;
+	drvdata->addr_type[idx] = ETM_ADDR_TYPE_START;
+	drvdata->startstop_ctrl |= (1 << idx);
+	drvdata->enable_ctrl1 |= BIT(25);
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(addr_start);
+
+static ssize_t addr_stop_show(struct device *dev,
+			      struct device_attribute *attr, char *buf)
+{
+	u8 idx;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+
+	val = drvdata->addr_val[idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t addr_stop_store(struct device *dev,
+			       struct device_attribute *attr,
+			       const char *buf, size_t size)
+{
+	u8 idx;
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	idx = drvdata->addr_idx;
+	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
+	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
+		spin_unlock(&drvdata->spinlock);
+		return -EPERM;
+	}
+
+	drvdata->addr_val[idx] = val;
+	drvdata->addr_type[idx] = ETM_ADDR_TYPE_STOP;
+	drvdata->startstop_ctrl |= (1 << (idx + 16));
+	drvdata->enable_ctrl1 |= ETMTECR1_START_STOP;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(addr_stop);
+
+static ssize_t addr_acctype_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	val = drvdata->addr_acctype[drvdata->addr_idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t addr_acctype_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->addr_acctype[drvdata->addr_idx] = val;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(addr_acctype);
+
+static ssize_t cntr_idx_show(struct device *dev,
+			     struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->cntr_idx;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t cntr_idx_store(struct device *dev,
+			      struct device_attribute *attr,
+			      const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	if (val >= drvdata->nr_cntr)
+		return -EINVAL;
+	/*
+	 * Use spinlock to ensure index doesn't change while it gets
+	 * dereferenced multiple times within a spinlock block elsewhere.
+	 */
+	spin_lock(&drvdata->spinlock);
+	drvdata->cntr_idx = val;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(cntr_idx);
+
+static ssize_t cntr_rld_val_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	val = drvdata->cntr_rld_val[drvdata->cntr_idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t cntr_rld_val_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->cntr_rld_val[drvdata->cntr_idx] = val;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(cntr_rld_val);
+
+static ssize_t cntr_event_show(struct device *dev,
+			       struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	val = drvdata->cntr_event[drvdata->cntr_idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t cntr_event_store(struct device *dev,
+				struct device_attribute *attr,
+				const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->cntr_event[drvdata->cntr_idx] = val & ETM_EVENT_MASK;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(cntr_event);
+
+static ssize_t cntr_rld_event_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	val = drvdata->cntr_rld_event[drvdata->cntr_idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t cntr_rld_event_store(struct device *dev,
+				    struct device_attribute *attr,
+				    const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->cntr_rld_event[drvdata->cntr_idx] = val & ETM_EVENT_MASK;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(cntr_rld_event);
+
+static ssize_t cntr_val_show(struct device *dev,
+			     struct device_attribute *attr, char *buf)
+{
+	int i, ret = 0;
+	u32 val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	if (!drvdata->enable) {
+		spin_lock(&drvdata->spinlock);
+		for (i = 0; i < drvdata->nr_cntr; i++)
+			ret += sprintf(buf, "counter %d: %x\n",
+				       i, drvdata->cntr_val[i]);
+		spin_unlock(&drvdata->spinlock);
+		return ret;
+	}
+
+	for (i = 0; i < drvdata->nr_cntr; i++) {
+		val = etm_readl(drvdata, ETMCNTVRn(i));
+		ret += sprintf(buf, "counter %d: %x\n", i, val);
+	}
+
+	return ret;
+}
+
+static ssize_t cntr_val_store(struct device *dev,
+			      struct device_attribute *attr,
+			      const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->cntr_val[drvdata->cntr_idx] = val;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(cntr_val);
+
+static ssize_t seq_12_event_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->seq_12_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t seq_12_event_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->seq_12_event = val & ETM_EVENT_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(seq_12_event);
+
+static ssize_t seq_21_event_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->seq_21_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t seq_21_event_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->seq_21_event = val & ETM_EVENT_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(seq_21_event);
+
+static ssize_t seq_23_event_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->seq_23_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t seq_23_event_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->seq_23_event = val & ETM_EVENT_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(seq_23_event);
+
+static ssize_t seq_31_event_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->seq_31_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t seq_31_event_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->seq_31_event = val & ETM_EVENT_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(seq_31_event);
+
+static ssize_t seq_32_event_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->seq_32_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t seq_32_event_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->seq_32_event = val & ETM_EVENT_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(seq_32_event);
+
+static ssize_t seq_13_event_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->seq_13_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t seq_13_event_store(struct device *dev,
+				  struct device_attribute *attr,
+				  const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->seq_13_event = val & ETM_EVENT_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(seq_13_event);
+
+static ssize_t seq_curr_state_show(struct device *dev,
+				   struct device_attribute *attr, char *buf)
+{
+	unsigned long val, flags;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	if (!drvdata->enable) {
+		val = drvdata->seq_curr_state;
+		goto out;
+	}
+
+	pm_runtime_get_sync(drvdata->dev);
+	spin_lock_irqsave(&drvdata->spinlock, flags);
+
+	CS_UNLOCK(drvdata->base);
+	val = (etm_readl(drvdata, ETMSQR) & ETM_SQR_MASK);
+	CS_LOCK(drvdata->base);
+
+	spin_unlock_irqrestore(&drvdata->spinlock, flags);
+	pm_runtime_put(drvdata->dev);
+out:
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t seq_curr_state_store(struct device *dev,
+				    struct device_attribute *attr,
+				    const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	if (val > ETM_SEQ_STATE_MAX_VAL)
+		return -EINVAL;
+
+	drvdata->seq_curr_state = val;
+
+	return size;
+}
+static DEVICE_ATTR_RW(seq_curr_state);
+
+static ssize_t ctxid_idx_show(struct device *dev,
+			      struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->ctxid_idx;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t ctxid_idx_store(struct device *dev,
+				struct device_attribute *attr,
+				const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	if (val >= drvdata->nr_ctxid_cmp)
+		return -EINVAL;
+
+	/*
+	 * Use spinlock to ensure index doesn't change while it gets
+	 * dereferenced multiple times within a spinlock block elsewhere.
+	 */
+	spin_lock(&drvdata->spinlock);
+	drvdata->ctxid_idx = val;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(ctxid_idx);
+
+static ssize_t ctxid_pid_show(struct device *dev,
+			      struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	spin_lock(&drvdata->spinlock);
+	val = drvdata->ctxid_vpid[drvdata->ctxid_idx];
+	spin_unlock(&drvdata->spinlock);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t ctxid_pid_store(struct device *dev,
+			       struct device_attribute *attr,
+			       const char *buf, size_t size)
+{
+	int ret;
+	unsigned long vpid, pid;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &vpid);
+	if (ret)
+		return ret;
+
+	pid = coresight_vpid_to_pid(vpid);
+
+	spin_lock(&drvdata->spinlock);
+	drvdata->ctxid_pid[drvdata->ctxid_idx] = pid;
+	drvdata->ctxid_vpid[drvdata->ctxid_idx] = vpid;
+	spin_unlock(&drvdata->spinlock);
+
+	return size;
+}
+static DEVICE_ATTR_RW(ctxid_pid);
+
+static ssize_t ctxid_mask_show(struct device *dev,
+			       struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->ctxid_mask;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t ctxid_mask_store(struct device *dev,
+				struct device_attribute *attr,
+				const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->ctxid_mask = val;
+	return size;
+}
+static DEVICE_ATTR_RW(ctxid_mask);
+
+static ssize_t sync_freq_show(struct device *dev,
+			      struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->sync_freq;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t sync_freq_store(struct device *dev,
+			       struct device_attribute *attr,
+			       const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->sync_freq = val & ETM_SYNC_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(sync_freq);
+
+static ssize_t timestamp_event_show(struct device *dev,
+				    struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->timestamp_event;
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t timestamp_event_store(struct device *dev,
+				     struct device_attribute *attr,
+				     const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->timestamp_event = val & ETM_EVENT_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(timestamp_event);
+
+static ssize_t cpu_show(struct device *dev,
+			struct device_attribute *attr, char *buf)
+{
+	int val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = drvdata->cpu;
+	return scnprintf(buf, PAGE_SIZE, "%d\n", val);
+
+}
+static DEVICE_ATTR_RO(cpu);
+
+static ssize_t traceid_show(struct device *dev,
+			    struct device_attribute *attr, char *buf)
+{
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	val = etm_get_trace_id(drvdata);
+
+	return sprintf(buf, "%#lx\n", val);
+}
+
+static ssize_t traceid_store(struct device *dev,
+			     struct device_attribute *attr,
+			     const char *buf, size_t size)
+{
+	int ret;
+	unsigned long val;
+	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+	ret = kstrtoul(buf, 16, &val);
+	if (ret)
+		return ret;
+
+	drvdata->traceid = val & ETM_TRACEID_MASK;
+	return size;
+}
+static DEVICE_ATTR_RW(traceid);
+
+static struct attribute *coresight_etm_attrs[] = {
+	&dev_attr_nr_addr_cmp.attr,
+	&dev_attr_nr_cntr.attr,
+	&dev_attr_nr_ctxid_cmp.attr,
+	&dev_attr_etmsr.attr,
+	&dev_attr_reset.attr,
+	&dev_attr_mode.attr,
+	&dev_attr_trigger_event.attr,
+	&dev_attr_enable_event.attr,
+	&dev_attr_fifofull_level.attr,
+	&dev_attr_addr_idx.attr,
+	&dev_attr_addr_single.attr,
+	&dev_attr_addr_range.attr,
+	&dev_attr_addr_start.attr,
+	&dev_attr_addr_stop.attr,
+	&dev_attr_addr_acctype.attr,
+	&dev_attr_cntr_idx.attr,
+	&dev_attr_cntr_rld_val.attr,
+	&dev_attr_cntr_event.attr,
+	&dev_attr_cntr_rld_event.attr,
+	&dev_attr_cntr_val.attr,
+	&dev_attr_seq_12_event.attr,
+	&dev_attr_seq_21_event.attr,
+	&dev_attr_seq_23_event.attr,
+	&dev_attr_seq_31_event.attr,
+	&dev_attr_seq_32_event.attr,
+	&dev_attr_seq_13_event.attr,
+	&dev_attr_seq_curr_state.attr,
+	&dev_attr_ctxid_idx.attr,
+	&dev_attr_ctxid_pid.attr,
+	&dev_attr_ctxid_mask.attr,
+	&dev_attr_sync_freq.attr,
+	&dev_attr_timestamp_event.attr,
+	&dev_attr_traceid.attr,
+	&dev_attr_cpu.attr,
+	NULL,
+};
+
+#define coresight_simple_func(name, offset)                             \
+static ssize_t name##_show(struct device *_dev,                         \
+			   struct device_attribute *attr, char *buf)    \
+{                                                                       \
+	struct etm_drvdata *drvdata = dev_get_drvdata(_dev->parent);    \
+	return scnprintf(buf, PAGE_SIZE, "0x%x\n",                      \
+			 readl_relaxed(drvdata->base + offset));        \
+}                                                                       \
+DEVICE_ATTR_RO(name)
+
+coresight_simple_func(etmccr, ETMCCR);
+coresight_simple_func(etmccer, ETMCCER);
+coresight_simple_func(etmscr, ETMSCR);
+coresight_simple_func(etmidr, ETMIDR);
+coresight_simple_func(etmcr, ETMCR);
+coresight_simple_func(etmtraceidr, ETMTRACEIDR);
+coresight_simple_func(etmteevr, ETMTEEVR);
+coresight_simple_func(etmtssvr, ETMTSSCR);
+coresight_simple_func(etmtecr1, ETMTECR1);
+coresight_simple_func(etmtecr2, ETMTECR2);
+
+static struct attribute *coresight_etm_mgmt_attrs[] = {
+	&dev_attr_etmccr.attr,
+	&dev_attr_etmccer.attr,
+	&dev_attr_etmscr.attr,
+	&dev_attr_etmidr.attr,
+	&dev_attr_etmcr.attr,
+	&dev_attr_etmtraceidr.attr,
+	&dev_attr_etmteevr.attr,
+	&dev_attr_etmtssvr.attr,
+	&dev_attr_etmtecr1.attr,
+	&dev_attr_etmtecr2.attr,
+	NULL,
+};
+
+static const struct attribute_group coresight_etm_group = {
+	.attrs = coresight_etm_attrs,
+};
+
+static const struct attribute_group coresight_etm_mgmt_group = {
+	.attrs = coresight_etm_mgmt_attrs,
+	.name = "mgmt",
+};
+
+const struct attribute_group *coresight_etm_groups[] = {
+	&coresight_etm_group,
+	&coresight_etm_mgmt_group,
+	NULL,
+};
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c b/drivers/hwtracing/coresight/coresight-etm3x.c
index d53440e9af6f..6ea35b350958 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -186,7 +186,7 @@ static void etm_clr_prog(struct etm_drvdata *drvdata)
 	}
 }
 
-static void etm_set_default(struct etm_drvdata *drvdata)
+void etm_set_default(struct etm_drvdata *drvdata)
 {
 	int i;
 
@@ -293,15 +293,18 @@ static int etm_cpu_id(struct coresight_device *csdev)
 	return drvdata->cpu;
 }
 
-static int etm_trace_id(struct coresight_device *csdev)
+int etm_get_trace_id(struct etm_drvdata *drvdata)
 {
-	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
 	unsigned long flags;
 	int trace_id = -1;
 
+	if (!drvdata)
+		goto out;
+
 	if (!drvdata->enable)
 		return drvdata->traceid;
-	pm_runtime_get_sync(csdev->dev.parent);
+
+	pm_runtime_get_sync(drvdata->dev);
 
 	spin_lock_irqsave(&drvdata->spinlock, flags);
 
@@ -310,9 +313,18 @@ static int etm_trace_id(struct coresight_device *csdev)
 	CS_LOCK(drvdata->base);
 
 	spin_unlock_irqrestore(&drvdata->spinlock, flags);
-	pm_runtime_put(csdev->dev.parent);
+	pm_runtime_put(drvdata->dev);
 
+out:
 	return trace_id;
+
+}
+
+static int etm_trace_id(struct coresight_device *csdev)
+{
+	struct etm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
+
+	return etm_get_trace_id(drvdata);
 }
 
 static int etm_enable(struct coresight_device *csdev)
@@ -406,1218 +418,6 @@ static const struct coresight_ops etm_cs_ops = {
 	.source_ops	= &etm_source_ops,
 };
 
-static ssize_t nr_addr_cmp_show(struct device *dev,
-				struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->nr_addr_cmp;
-	return sprintf(buf, "%#lx\n", val);
-}
-static DEVICE_ATTR_RO(nr_addr_cmp);
-
-static ssize_t nr_cntr_show(struct device *dev,
-			    struct device_attribute *attr, char *buf)
-{	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->nr_cntr;
-	return sprintf(buf, "%#lx\n", val);
-}
-static DEVICE_ATTR_RO(nr_cntr);
-
-static ssize_t nr_ctxid_cmp_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->nr_ctxid_cmp;
-	return sprintf(buf, "%#lx\n", val);
-}
-static DEVICE_ATTR_RO(nr_ctxid_cmp);
-
-static ssize_t etmsr_show(struct device *dev,
-			  struct device_attribute *attr, char *buf)
-{
-	unsigned long flags, val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	pm_runtime_get_sync(drvdata->dev);
-	spin_lock_irqsave(&drvdata->spinlock, flags);
-	CS_UNLOCK(drvdata->base);
-
-	val = etm_readl(drvdata, ETMSR);
-
-	CS_LOCK(drvdata->base);
-	spin_unlock_irqrestore(&drvdata->spinlock, flags);
-	pm_runtime_put(drvdata->dev);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-static DEVICE_ATTR_RO(etmsr);
-
-static ssize_t reset_store(struct device *dev,
-			   struct device_attribute *attr,
-			   const char *buf, size_t size)
-{
-	int i, ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	if (val) {
-		spin_lock(&drvdata->spinlock);
-		drvdata->mode = ETM_MODE_EXCLUDE;
-		drvdata->ctrl = 0x0;
-		drvdata->trigger_event = ETM_DEFAULT_EVENT_VAL;
-		drvdata->startstop_ctrl = 0x0;
-		drvdata->addr_idx = 0x0;
-		for (i = 0; i < drvdata->nr_addr_cmp; i++) {
-			drvdata->addr_val[i] = 0x0;
-			drvdata->addr_acctype[i] = 0x0;
-			drvdata->addr_type[i] = ETM_ADDR_TYPE_NONE;
-		}
-		drvdata->cntr_idx = 0x0;
-
-		etm_set_default(drvdata);
-		spin_unlock(&drvdata->spinlock);
-	}
-
-	return size;
-}
-static DEVICE_ATTR_WO(reset);
-
-static ssize_t mode_show(struct device *dev,
-			 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->mode;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t mode_store(struct device *dev,
-			  struct device_attribute *attr,
-			  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	drvdata->mode = val & ETM_MODE_ALL;
-
-	if (drvdata->mode & ETM_MODE_EXCLUDE)
-		drvdata->enable_ctrl1 |= ETMTECR1_INC_EXC;
-	else
-		drvdata->enable_ctrl1 &= ~ETMTECR1_INC_EXC;
-
-	if (drvdata->mode & ETM_MODE_CYCACC)
-		drvdata->ctrl |= ETMCR_CYC_ACC;
-	else
-		drvdata->ctrl &= ~ETMCR_CYC_ACC;
-
-	if (drvdata->mode & ETM_MODE_STALL) {
-		if (!(drvdata->etmccr & ETMCCR_FIFOFULL)) {
-			dev_warn(drvdata->dev, "stall mode not supported\n");
-			ret = -EINVAL;
-			goto err_unlock;
-		}
-		drvdata->ctrl |= ETMCR_STALL_MODE;
-	 } else
-		drvdata->ctrl &= ~ETMCR_STALL_MODE;
-
-	if (drvdata->mode & ETM_MODE_TIMESTAMP) {
-		if (!(drvdata->etmccer & ETMCCER_TIMESTAMP)) {
-			dev_warn(drvdata->dev, "timestamp not supported\n");
-			ret = -EINVAL;
-			goto err_unlock;
-		}
-		drvdata->ctrl |= ETMCR_TIMESTAMP_EN;
-	} else
-		drvdata->ctrl &= ~ETMCR_TIMESTAMP_EN;
-
-	if (drvdata->mode & ETM_MODE_CTXID)
-		drvdata->ctrl |= ETMCR_CTXID_SIZE;
-	else
-		drvdata->ctrl &= ~ETMCR_CTXID_SIZE;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-
-err_unlock:
-	spin_unlock(&drvdata->spinlock);
-	return ret;
-}
-static DEVICE_ATTR_RW(mode);
-
-static ssize_t trigger_event_show(struct device *dev,
-				  struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->trigger_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t trigger_event_store(struct device *dev,
-				   struct device_attribute *attr,
-				   const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->trigger_event = val & ETM_EVENT_MASK;
-
-	return size;
-}
-static DEVICE_ATTR_RW(trigger_event);
-
-static ssize_t enable_event_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->enable_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t enable_event_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->enable_event = val & ETM_EVENT_MASK;
-
-	return size;
-}
-static DEVICE_ATTR_RW(enable_event);
-
-static ssize_t fifofull_level_show(struct device *dev,
-				   struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->fifofull_level;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t fifofull_level_store(struct device *dev,
-				    struct device_attribute *attr,
-				    const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->fifofull_level = val;
-
-	return size;
-}
-static DEVICE_ATTR_RW(fifofull_level);
-
-static ssize_t addr_idx_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->addr_idx;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t addr_idx_store(struct device *dev,
-			      struct device_attribute *attr,
-			      const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	if (val >= drvdata->nr_addr_cmp)
-		return -EINVAL;
-
-	/*
-	 * Use spinlock to ensure index doesn't change while it gets
-	 * dereferenced multiple times within a spinlock block elsewhere.
-	 */
-	spin_lock(&drvdata->spinlock);
-	drvdata->addr_idx = val;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(addr_idx);
-
-static ssize_t addr_single_show(struct device *dev,
-				struct device_attribute *attr, char *buf)
-{
-	u8 idx;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
-		spin_unlock(&drvdata->spinlock);
-		return -EINVAL;
-	}
-
-	val = drvdata->addr_val[idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t addr_single_store(struct device *dev,
-				 struct device_attribute *attr,
-				 const char *buf, size_t size)
-{
-	u8 idx;
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_SINGLE)) {
-		spin_unlock(&drvdata->spinlock);
-		return -EINVAL;
-	}
-
-	drvdata->addr_val[idx] = val;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_SINGLE;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(addr_single);
-
-static ssize_t addr_range_show(struct device *dev,
-			       struct device_attribute *attr, char *buf)
-{
-	u8 idx;
-	unsigned long val1, val2;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (idx % 2 != 0) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-	if (!((drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
-	      (drvdata->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-
-	val1 = drvdata->addr_val[idx];
-	val2 = drvdata->addr_val[idx + 1];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx %#lx\n", val1, val2);
-}
-
-static ssize_t addr_range_store(struct device *dev,
-			      struct device_attribute *attr,
-			      const char *buf, size_t size)
-{
-	u8 idx;
-	unsigned long val1, val2;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	if (sscanf(buf, "%lx %lx", &val1, &val2) != 2)
-		return -EINVAL;
-	/* Lower address comparator cannot have a higher address value */
-	if (val1 > val2)
-		return -EINVAL;
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (idx % 2 != 0) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-	if (!((drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_NONE) ||
-	      (drvdata->addr_type[idx] == ETM_ADDR_TYPE_RANGE &&
-	       drvdata->addr_type[idx + 1] == ETM_ADDR_TYPE_RANGE))) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-
-	drvdata->addr_val[idx] = val1;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_RANGE;
-	drvdata->addr_val[idx + 1] = val2;
-	drvdata->addr_type[idx + 1] = ETM_ADDR_TYPE_RANGE;
-	drvdata->enable_ctrl1 |= (1 << (idx/2));
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(addr_range);
-
-static ssize_t addr_start_show(struct device *dev,
-			       struct device_attribute *attr, char *buf)
-{
-	u8 idx;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_START)) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-
-	val = drvdata->addr_val[idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t addr_start_store(struct device *dev,
-				struct device_attribute *attr,
-				const char *buf, size_t size)
-{
-	u8 idx;
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_START)) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-
-	drvdata->addr_val[idx] = val;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_START;
-	drvdata->startstop_ctrl |= (1 << idx);
-	drvdata->enable_ctrl1 |= BIT(25);
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(addr_start);
-
-static ssize_t addr_stop_show(struct device *dev,
-			      struct device_attribute *attr, char *buf)
-{
-	u8 idx;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-
-	val = drvdata->addr_val[idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t addr_stop_store(struct device *dev,
-			       struct device_attribute *attr,
-			       const char *buf, size_t size)
-{
-	u8 idx;
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	idx = drvdata->addr_idx;
-	if (!(drvdata->addr_type[idx] == ETM_ADDR_TYPE_NONE ||
-	      drvdata->addr_type[idx] == ETM_ADDR_TYPE_STOP)) {
-		spin_unlock(&drvdata->spinlock);
-		return -EPERM;
-	}
-
-	drvdata->addr_val[idx] = val;
-	drvdata->addr_type[idx] = ETM_ADDR_TYPE_STOP;
-	drvdata->startstop_ctrl |= (1 << (idx + 16));
-	drvdata->enable_ctrl1 |= ETMTECR1_START_STOP;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(addr_stop);
-
-static ssize_t addr_acctype_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	val = drvdata->addr_acctype[drvdata->addr_idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t addr_acctype_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	drvdata->addr_acctype[drvdata->addr_idx] = val;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(addr_acctype);
-
-static ssize_t cntr_idx_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->cntr_idx;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t cntr_idx_store(struct device *dev,
-			      struct device_attribute *attr,
-			      const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	if (val >= drvdata->nr_cntr)
-		return -EINVAL;
-	/*
-	 * Use spinlock to ensure index doesn't change while it gets
-	 * dereferenced multiple times within a spinlock block elsewhere.
-	 */
-	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_idx = val;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(cntr_idx);
-
-static ssize_t cntr_rld_val_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	val = drvdata->cntr_rld_val[drvdata->cntr_idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t cntr_rld_val_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_rld_val[drvdata->cntr_idx] = val;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(cntr_rld_val);
-
-static ssize_t cntr_event_show(struct device *dev,
-			       struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	val = drvdata->cntr_event[drvdata->cntr_idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t cntr_event_store(struct device *dev,
-				struct device_attribute *attr,
-				const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_event[drvdata->cntr_idx] = val & ETM_EVENT_MASK;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(cntr_event);
-
-static ssize_t cntr_rld_event_show(struct device *dev,
-				   struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	val = drvdata->cntr_rld_event[drvdata->cntr_idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t cntr_rld_event_store(struct device *dev,
-				    struct device_attribute *attr,
-				    const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_rld_event[drvdata->cntr_idx] = val & ETM_EVENT_MASK;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(cntr_rld_event);
-
-static ssize_t cntr_val_show(struct device *dev,
-			     struct device_attribute *attr, char *buf)
-{
-	int i, ret = 0;
-	u32 val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	if (!drvdata->enable) {
-		spin_lock(&drvdata->spinlock);
-		for (i = 0; i < drvdata->nr_cntr; i++)
-			ret += sprintf(buf, "counter %d: %x\n",
-				       i, drvdata->cntr_val[i]);
-		spin_unlock(&drvdata->spinlock);
-		return ret;
-	}
-
-	for (i = 0; i < drvdata->nr_cntr; i++) {
-		val = etm_readl(drvdata, ETMCNTVRn(i));
-		ret += sprintf(buf, "counter %d: %x\n", i, val);
-	}
-
-	return ret;
-}
-
-static ssize_t cntr_val_store(struct device *dev,
-			      struct device_attribute *attr,
-			      const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	spin_lock(&drvdata->spinlock);
-	drvdata->cntr_val[drvdata->cntr_idx] = val;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(cntr_val);
-
-static ssize_t seq_12_event_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->seq_12_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t seq_12_event_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->seq_12_event = val & ETM_EVENT_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(seq_12_event);
-
-static ssize_t seq_21_event_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->seq_21_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t seq_21_event_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->seq_21_event = val & ETM_EVENT_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(seq_21_event);
-
-static ssize_t seq_23_event_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->seq_23_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t seq_23_event_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->seq_23_event = val & ETM_EVENT_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(seq_23_event);
-
-static ssize_t seq_31_event_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->seq_31_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t seq_31_event_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->seq_31_event = val & ETM_EVENT_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(seq_31_event);
-
-static ssize_t seq_32_event_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->seq_32_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t seq_32_event_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->seq_32_event = val & ETM_EVENT_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(seq_32_event);
-
-static ssize_t seq_13_event_show(struct device *dev,
-				 struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->seq_13_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t seq_13_event_store(struct device *dev,
-				  struct device_attribute *attr,
-				  const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->seq_13_event = val & ETM_EVENT_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(seq_13_event);
-
-static ssize_t seq_curr_state_show(struct device *dev,
-				   struct device_attribute *attr, char *buf)
-{
-	unsigned long val, flags;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	if (!drvdata->enable) {
-		val = drvdata->seq_curr_state;
-		goto out;
-	}
-
-	pm_runtime_get_sync(drvdata->dev);
-	spin_lock_irqsave(&drvdata->spinlock, flags);
-
-	CS_UNLOCK(drvdata->base);
-	val = (etm_readl(drvdata, ETMSQR) & ETM_SQR_MASK);
-	CS_LOCK(drvdata->base);
-
-	spin_unlock_irqrestore(&drvdata->spinlock, flags);
-	pm_runtime_put(drvdata->dev);
-out:
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t seq_curr_state_store(struct device *dev,
-				    struct device_attribute *attr,
-				    const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	if (val > ETM_SEQ_STATE_MAX_VAL)
-		return -EINVAL;
-
-	drvdata->seq_curr_state = val;
-
-	return size;
-}
-static DEVICE_ATTR_RW(seq_curr_state);
-
-static ssize_t ctxid_idx_show(struct device *dev,
-			      struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->ctxid_idx;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t ctxid_idx_store(struct device *dev,
-				struct device_attribute *attr,
-				const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	if (val >= drvdata->nr_ctxid_cmp)
-		return -EINVAL;
-
-	/*
-	 * Use spinlock to ensure index doesn't change while it gets
-	 * dereferenced multiple times within a spinlock block elsewhere.
-	 */
-	spin_lock(&drvdata->spinlock);
-	drvdata->ctxid_idx = val;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(ctxid_idx);
-
-static ssize_t ctxid_pid_show(struct device *dev,
-			      struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	spin_lock(&drvdata->spinlock);
-	val = drvdata->ctxid_vpid[drvdata->ctxid_idx];
-	spin_unlock(&drvdata->spinlock);
-
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t ctxid_pid_store(struct device *dev,
-			       struct device_attribute *attr,
-			       const char *buf, size_t size)
-{
-	int ret;
-	unsigned long vpid, pid;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &vpid);
-	if (ret)
-		return ret;
-
-	pid = coresight_vpid_to_pid(vpid);
-
-	spin_lock(&drvdata->spinlock);
-	drvdata->ctxid_pid[drvdata->ctxid_idx] = pid;
-	drvdata->ctxid_vpid[drvdata->ctxid_idx] = vpid;
-	spin_unlock(&drvdata->spinlock);
-
-	return size;
-}
-static DEVICE_ATTR_RW(ctxid_pid);
-
-static ssize_t ctxid_mask_show(struct device *dev,
-			       struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->ctxid_mask;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t ctxid_mask_store(struct device *dev,
-				struct device_attribute *attr,
-				const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->ctxid_mask = val;
-	return size;
-}
-static DEVICE_ATTR_RW(ctxid_mask);
-
-static ssize_t sync_freq_show(struct device *dev,
-			      struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->sync_freq;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t sync_freq_store(struct device *dev,
-			       struct device_attribute *attr,
-			       const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->sync_freq = val & ETM_SYNC_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(sync_freq);
-
-static ssize_t timestamp_event_show(struct device *dev,
-				    struct device_attribute *attr, char *buf)
-{
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->timestamp_event;
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t timestamp_event_store(struct device *dev,
-				     struct device_attribute *attr,
-				     const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->timestamp_event = val & ETM_EVENT_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(timestamp_event);
-
-static ssize_t cpu_show(struct device *dev,
-			struct device_attribute *attr, char *buf)
-{
-	int val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	val = drvdata->cpu;
-	return scnprintf(buf, PAGE_SIZE, "%d\n", val);
-
-}
-static DEVICE_ATTR_RO(cpu);
-
-static ssize_t traceid_show(struct device *dev,
-			    struct device_attribute *attr, char *buf)
-{
-	unsigned long val, flags;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	if (!drvdata->enable) {
-		val = drvdata->traceid;
-		goto out;
-	}
-
-	pm_runtime_get_sync(drvdata->dev);
-	spin_lock_irqsave(&drvdata->spinlock, flags);
-	CS_UNLOCK(drvdata->base);
-
-	val = (etm_readl(drvdata, ETMTRACEIDR) & ETM_TRACEID_MASK);
-
-	CS_LOCK(drvdata->base);
-	spin_unlock_irqrestore(&drvdata->spinlock, flags);
-	pm_runtime_put(drvdata->dev);
-out:
-	return sprintf(buf, "%#lx\n", val);
-}
-
-static ssize_t traceid_store(struct device *dev,
-			     struct device_attribute *attr,
-			     const char *buf, size_t size)
-{
-	int ret;
-	unsigned long val;
-	struct etm_drvdata *drvdata = dev_get_drvdata(dev->parent);
-
-	ret = kstrtoul(buf, 16, &val);
-	if (ret)
-		return ret;
-
-	drvdata->traceid = val & ETM_TRACEID_MASK;
-	return size;
-}
-static DEVICE_ATTR_RW(traceid);
-
-static struct attribute *coresight_etm_attrs[] = {
-	&dev_attr_nr_addr_cmp.attr,
-	&dev_attr_nr_cntr.attr,
-	&dev_attr_nr_ctxid_cmp.attr,
-	&dev_attr_etmsr.attr,
-	&dev_attr_reset.attr,
-	&dev_attr_mode.attr,
-	&dev_attr_trigger_event.attr,
-	&dev_attr_enable_event.attr,
-	&dev_attr_fifofull_level.attr,
-	&dev_attr_addr_idx.attr,
-	&dev_attr_addr_single.attr,
-	&dev_attr_addr_range.attr,
-	&dev_attr_addr_start.attr,
-	&dev_attr_addr_stop.attr,
-	&dev_attr_addr_acctype.attr,
-	&dev_attr_cntr_idx.attr,
-	&dev_attr_cntr_rld_val.attr,
-	&dev_attr_cntr_event.attr,
-	&dev_attr_cntr_rld_event.attr,
-	&dev_attr_cntr_val.attr,
-	&dev_attr_seq_12_event.attr,
-	&dev_attr_seq_21_event.attr,
-	&dev_attr_seq_23_event.attr,
-	&dev_attr_seq_31_event.attr,
-	&dev_attr_seq_32_event.attr,
-	&dev_attr_seq_13_event.attr,
-	&dev_attr_seq_curr_state.attr,
-	&dev_attr_ctxid_idx.attr,
-	&dev_attr_ctxid_pid.attr,
-	&dev_attr_ctxid_mask.attr,
-	&dev_attr_sync_freq.attr,
-	&dev_attr_timestamp_event.attr,
-	&dev_attr_traceid.attr,
-	&dev_attr_cpu.attr,
-	NULL,
-};
-
-#define coresight_simple_func(name, offset)                             \
-static ssize_t name##_show(struct device *_dev,                         \
-			   struct device_attribute *attr, char *buf)    \
-{                                                                       \
-	struct etm_drvdata *drvdata = dev_get_drvdata(_dev->parent);    \
-	return scnprintf(buf, PAGE_SIZE, "0x%x\n",                      \
-			 readl_relaxed(drvdata->base + offset));        \
-}                                                                       \
-DEVICE_ATTR_RO(name)
-
-coresight_simple_func(etmccr, ETMCCR);
-coresight_simple_func(etmccer, ETMCCER);
-coresight_simple_func(etmscr, ETMSCR);
-coresight_simple_func(etmidr, ETMIDR);
-coresight_simple_func(etmcr, ETMCR);
-coresight_simple_func(etmtraceidr, ETMTRACEIDR);
-coresight_simple_func(etmteevr, ETMTEEVR);
-coresight_simple_func(etmtssvr, ETMTSSCR);
-coresight_simple_func(etmtecr1, ETMTECR1);
-coresight_simple_func(etmtecr2, ETMTECR2);
-
-static struct attribute *coresight_etm_mgmt_attrs[] = {
-	&dev_attr_etmccr.attr,
-	&dev_attr_etmccer.attr,
-	&dev_attr_etmscr.attr,
-	&dev_attr_etmidr.attr,
-	&dev_attr_etmcr.attr,
-	&dev_attr_etmtraceidr.attr,
-	&dev_attr_etmteevr.attr,
-	&dev_attr_etmtssvr.attr,
-	&dev_attr_etmtecr1.attr,
-	&dev_attr_etmtecr2.attr,
-	NULL,
-};
-
-static const struct attribute_group coresight_etm_group = {
-	.attrs = coresight_etm_attrs,
-};
-
-
-static const struct attribute_group coresight_etm_mgmt_group = {
-	.attrs = coresight_etm_mgmt_attrs,
-	.name = "mgmt",
-};
-
-static const struct attribute_group *coresight_etm_groups[] = {
-	&coresight_etm_group,
-	&coresight_etm_mgmt_group,
-	NULL,
-};
-
 static int etm_cpu_callback(struct notifier_block *nfb, unsigned long action,
 			    void *hcpu)
 {
-- 
2.1.4



From linux at arm.linux.org.uk  Wed Feb 17 16:55:03 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Feb 2016 00:55:03 +0000
Subject: [PATCH] clk: fix clk-gpio.c with optional clock= DT property
In-Reply-To: <20160218000747.2278.46405@quark.deferred.io>
References: <E1aFJ0A-00086Z-0I@rmk-PC.arm.linux.org.uk>
 <20160217230529.GM19428@n2100.arm.linux.org.uk>
 <20160218000747.2278.46405@quark.deferred.io>
Message-ID: <20160218005503.GO19428@n2100.arm.linux.org.uk>

On Wed, Feb 17, 2016 at 04:07:47PM -0800, Michael Turquette wrote:
> Quoting Russell King - ARM Linux (2016-02-17 15:05:29)
> > On Sat, Jan 02, 2016 at 10:01:34AM +0000, Russell King wrote:
> > > When the clock DT property is not given, of_clk_get_parent_count()
> > > returns -ENOENT, which then tries to allocate -2 x 4 bytes of memory,
> > > which of course fails, causing the whole driver to fail to create
> > > the clock.
> > > 
> > > This causes the SolidRun platforms to fail probing the SDHCI1 interface
> > > which is connected to the WiFi.
> > > 
> > > Fix this by detecting errno codes, skipping the allocation, and fixing
> > > of_clk_gpio_gate_delayed_register_get() to handle a NULL parent_names
> > > array.
> > > 
> > > Fixes: 80eeb1f0f757 ("clk: add gpio controlled clock multiplexer")
> > > Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
> > > ---
> > > This goes all the way back to 80eeb1f0f757 ("clk: add gpio controlled
> > > clock multiplexer") introduced in June in v4.3-rc2 - which raises the
> > > question why _development_ work in clk is being merged outside of the
> > > merge window.
> > > 
> > > A rewrite of this patch will be necessary to apply to v4.3 kernels.
> > > 
> > > This applies on top of v4.4-rc6.
> > > 
> > >  drivers/clk/clk-gpio.c | 23 ++++++++++++++---------
> > >  1 file changed, 14 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
> > > index 335322dc403f..05cca9298f44 100644
> > > --- a/drivers/clk/clk-gpio.c
> > > +++ b/drivers/clk/clk-gpio.c
> > > @@ -264,8 +264,8 @@ static struct clk *of_clk_gpio_gate_delayed_register_get(const char *name,
> > >               const char * const *parent_names, u8 num_parents,
> > >               unsigned gpio, bool active_low)
> > >  {
> > > -     return clk_register_gpio_gate(NULL, name, parent_names[0],
> > > -                     gpio, active_low, 0);
> > > +     return clk_register_gpio_gate(NULL, name, parent_names ?
> > > +                     parent_names[0] : NULL, gpio, active_low, 0);
> > >  }
> > >  
> > >  static struct clk *of_clk_gpio_mux_delayed_register_get(const char *name,
> > > @@ -292,13 +292,18 @@ static void __init of_gpio_clk_setup(struct device_node *node,
> > >               return;
> > >  
> > >       num_parents = of_clk_get_parent_count(node);
> > > -
> > > -     parent_names = kcalloc(num_parents, sizeof(char *), GFP_KERNEL);
> > > -     if (!parent_names)
> > > -             return;
> > > -
> > > -     for (i = 0; i < num_parents; i++)
> > > -             parent_names[i] = of_clk_get_parent_name(node, i);
> > > +     if (num_parents > 0) {
> > > +             parent_names = kcalloc(num_parents, sizeof(char *), GFP_KERNEL);
> > > +             if (!parent_names) {
> > > +                     kfree(data);
> > > +                     return;
> > > +             }
> > > +
> > > +             for (i = 0; i < num_parents; i++)
> > > +                     parent_names[i] = of_clk_get_parent_name(node, i);
> > > +     } else {
> > > +             parent_names = NULL;
> > > +     }
> > >  
> > >       data->num_parents = num_parents;
> > >       data->parent_names = parent_names;
> > > -- 
> > > 2.1.0
> > 
> > Yes, indeed, my patch above which fixed clk-gpio.c as can be seen above
> > does not have the problem that I'm currently seeing...
> 
> Hi Russell,
> 
> I must be missing something. After merging your patch on top of Brian's,
> the code looks like:
> 
>         ...
>         int i, num_parents;
> 
>         num_parents = of_clk_get_parent_count(node);
>         if (num_parents < 0)
>                 return;
> 
>         data = kzalloc(sizeof(*data), GFP_KERNEL);
>         if (!data)
>                 return;
> 
>         if (num_parents) {
>                 parent_names = kcalloc(num_parents, sizeof(char *), GFP_KERNEL);
>                 if (!parent_names) {
>                         kfree(data);
>                         return;
>                 }
> 
>                 for (i = 0; i < num_parents; i++)
>                         parent_names[i] = of_clk_get_parent_name(node, i);
>         } else {
>                 parent_names = NULL;
>         }
> 
> Brian's if (num_parents < 0) check, followed by the if (num_parent)
> check appear equivalent to your original patch. Not sure why I merged it
> as if (num_parents) instead of if (num_parents > 0) as your original
> patch uses, but thanks to the extra check that predates your patch it
> should be equivalent.
> 
> Let me know if I've lost the plot.

You have.  Read the commit log on my patch.  Then look at this code:

         num_parents = of_clk_get_parent_count(node);
         if (num_parents < 0)
                 return;

compared to mine:

         num_parents = of_clk_get_parent_count(node);
         if (num_parents > 0) {
                 parent_names = kcalloc(num_parents, sizeof(char *), ...

It is very much _NOT_ equivalent.

The big pointer here is this:
* My patch works.
* The code you have in mainline does not work.

Therefore, they _can't_ be equivalent - because they have _visibly_
different behaviours.  So, they are different.

The former omits the _entire_ registration of the clock if
of_clk_get_parent_count() returns a negative number.  Thus, no
parent clocks, no clock gets registered.

The whole point behind my patch was to restore the regression
that occurred: the regression being that having no parent clocks
used to be explicitly allowed, and the patch I mentioned in my
commit message broke it.

This is even explained in the very first sentence of my commit
log:

| When the clock DT property is not given, of_clk_get_parent_count()
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^
| returns -ENOENT, which then tries to allocate -2 x 4 bytes of memory,
  ^^^^^^^^^^^^^^^

-ENOENT is a negative number.  Now look at the patch which totally
rejects the clock if of_clk_get_parent_count() returns any negative
number...

I assume, therefore, that you did not *even* read my commit log...

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From jay.xu at rock-chips.com  Wed Feb 17 17:07:04 2016
From: jay.xu at rock-chips.com (Jianqun Xu)
Date: Thu, 18 Feb 2016 09:07:04 +0800
Subject: [PATCH 6/6] ARM64: dts: rockchip: add core dtsi file for rk3399
In-Reply-To: <20160217114645.GA32647@leverpostej>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <1455674476-16655-1-git-send-email-jay.xu@rock-chips.com>
 <20160217114645.GA32647@leverpostej>
Message-ID: <56C51938.1060806@rock-chips.com>

Hi Mark

? 17/02/2016 19:46, Mark Rutland ??:
> On Wed, Feb 17, 2016 at 10:01:16AM +0800, jianqun.xu wrote:
>> From: Xu Jianqun <jay.xu at rock-chips.com>
>>
>> Add dtsi file for Rockchip rk3399 SoCs, which includes some
>> general nodes such as cpu, pmu, cru, gic, amba and so on.
>>
>> Change-Id: Ie3b824e8ead967d4cb119d73222b7a198478c29c
>
> This is meaningless upstream. Please remove any "Change-Id" lines from
> upstream commit messages.
ok, next version will remove them. thanks

>
>> Signed-off-by: Xu Jianqun <jay.xu at rock-chips.com>
>> ---
>>   arch/arm64/boot/dts/rockchip/rk3399.dtsi | 989 +++++++++++++++++++++++++++++++
>>   1 file changed, 989 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> new file mode 100644
>> index 0000000..eb671f6
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> @@ -0,0 +1,989 @@
>> +/*
>> + * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This library is free software; you can redistribute it and/or
>> + *     modify it under the terms of the GNU General Public License as
>> + *     published by the Free Software Foundation; either version 2 of the
>> + *     License, or (at your option) any later version.
>> + *
>> + *     This library is distributed in the hope that it will be useful,
>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *     GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + *     obtaining a copy of this software and associated documentation
>> + *     files (the "Software"), to deal in the Software without
>> + *     restriction, including without limitation the rights to use,
>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>> + *     sell copies of the Software, and to permit persons to whom the
>> + *     Software is furnished to do so, subject to the following
>> + *     conditions:
>> + *
>> + *     The above copyright notice and this permission notice shall be
>> + *     included in all copies or substantial portions of the Software.
>> + *
>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + *     OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +#include <dt-bindings/clock/rk3399-cru.h>
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/pinctrl/rockchip.h>
>> +
>> +/ {
>> +	compatible = "rockchip,rk3399";
>> +	interrupt-parent = <&gic>;
>> +	#address-cells = <2>;
>> +	#size-cells = <2>;
>> +
>> +	aliases {
>> +		serial0 = &uart0;
>> +		serial1 = &uart1;
>> +		serial2 = &uart2;
>> +		serial3 = &uart3;
>> +	};
>> +
>> +	psci {
>> +		compatible = "arm,psci";
>> +		method = "smc";
>> +	};
>
> That compatible string alone is insufficient, as it implies no
> particular function IDs. Hotplug and idle cannot possibly work.
>
> Have you tested this DT?
Yes, but only the simple system now, more function IDs will be added later.

>
> Which PSCI version have you implemented? Are you using a standard
> firmware (e.g. ARM Trusted Firmware), or some custom implementation?
>
>> +		cpu_l0: cpu at 0 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			reg = <0x0 0x0>;
>> +			cpu-idle-states = <&cpu_sleep>;
>> +			enable-method = "psci";
>> +		};
>
>> +		cpu_b0: cpu at 100 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a72", "arm,armv8";
>> +			reg = <0x0 0x100>;
>> +			cpu-idle-states = <&cpu_sleep>;
>> +			enable-method = "psci";
>> +		};
>> +
>
>> +	pmu {
>> +		compatible = "arm,armv8-pmuv3";
>> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
>> +		interrupt-affinity = <&cpu_l0>, <&cpu_l1>, <&cpu_l2>,
>> +				     <&cpu_l3>, <&cpu_b0>, <&cpu_b1>;
>> +	};
>> +
>
> This isn't quite right. We should have separate nodes for the A72 and
> A53 PMUs.
>
> We can't describe that just yet due to needing cluster-local PPIs. I
> believe Will was looking into that.
>
> In the mean time, please drop the PMU node.

ok, next version will drop the pmu node first, someone will add them in 
another patch.

>
>> +	timer {
>> +		compatible = "arm,armv8-timer";
>> +		interrupts =
>> +			<GIC_PPI 13
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			<GIC_PPI 14
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			<GIC_PPI 11
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			<GIC_PPI 10
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>> +		clock-frequency = <24000000>;
>> +	};
>
> Please fix your firmware to program CNTFRQ. Using clock-frequency is
> really not sufficient, and new platforms have no excuse for not having
> it programmed correctly.
ok, I will fix it. thanks

>
> Thanks,
> Mark.
>
>
>



From jay.xu at rock-chips.com  Wed Feb 17 17:43:37 2016
From: jay.xu at rock-chips.com (Jianqun Xu)
Date: Thu, 18 Feb 2016 09:43:37 +0800
Subject: [PATCH 6/6] ARM64: dts: rockchip: add core dtsi file for rk3399
In-Reply-To: <2396201.CBcovI4jc4@phil>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <1455674476-16655-1-git-send-email-jay.xu@rock-chips.com>
 <2396201.CBcovI4jc4@phil>
Message-ID: <56C521C9.4050906@rock-chips.com>



? 17/02/2016 15:00, Heiko Stuebner ??:
> Hi Jianqun,
>
> Am Mittwoch, 17. Februar 2016, 10:01:16 schrieb jianqun.xu:
>> From: Xu Jianqun <jay.xu at rock-chips.com>
>>
>> Add dtsi file for Rockchip rk3399 SoCs, which includes some
>> general nodes such as cpu, pmu, cru, gic, amba and so on.
>>
>> Change-Id: Ie3b824e8ead967d4cb119d73222b7a198478c29c
>
> please remove any review-cruft like Change-Ids from mainline patches :-)
ok, will fix it in next version patch
>
>> Signed-off-by: Xu Jianqun <jay.xu at rock-chips.com>
>> ---
>>   arch/arm64/boot/dts/rockchip/rk3399.dtsi | 989
>> +++++++++++++++++++++++++++++++ 1 file changed, 989 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi new file mode 100644
>> index 0000000..eb671f6
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
>> @@ -0,0 +1,989 @@
>> +/*
>> + * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This library is free software; you can redistribute it and/or
>> + *     modify it under the terms of the GNU General Public License as
>> + *     published by the Free Software Foundation; either version 2 of the
>> + *     License, or (at your option) any later version.
>> + *
>> + *     This library is distributed in the hope that it will be useful,
>> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + *     GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + *     obtaining a copy of this software and associated documentation
>> + *     files (the "Software"), to deal in the Software without
>> + *     restriction, including without limitation the rights to use,
>> + *     copy, modify, merge, publish, distribute, sublicense, and/or
>> + *     sell copies of the Software, and to permit persons to whom the
>> + *     Software is furnished to do so, subject to the following
>> + *     conditions:
>> + *
>> + *     The above copyright notice and this permission notice shall be
>> + *     included in all copies or substantial portions of the Software.
>> + *
>> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + *     OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +#include <dt-bindings/clock/rk3399-cru.h>
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/pinctrl/rockchip.h>
>> +
>> +/ {
>> +	compatible = "rockchip,rk3399";
>> +	interrupt-parent = <&gic>;
>> +	#address-cells = <2>;
>> +	#size-cells = <2>;
>> +
>> +	aliases {
>> +		serial0 = &uart0;
>> +		serial1 = &uart1;
>> +		serial2 = &uart2;
>> +		serial3 = &uart3;
>> +	};
>> +
>> +	psci {
>> +		compatible = "arm,psci";
>> +		method = "smc";
>> +	};
>> +
>> +	cpus {
>> +		#address-cells = <2>;
>> +		#size-cells = <0>;
>> +
>> +		cpu-map {
>> +			cluster0 {
>> +				core0 {
>> +					cpu = <&cpu_l0>;
>> +				};
>> +				core1 {
>> +					cpu = <&cpu_l1>;
>> +				};
>> +				core2 {
>> +					cpu = <&cpu_l2>;
>> +				};
>> +				core3 {
>> +					cpu = <&cpu_l3>;
>> +				};
>> +			};
>> +
>> +			cluster1 {
>> +				core0 {
>> +					cpu = <&cpu_b0>;
>> +				};
>> +				core1 {
>> +					cpu = <&cpu_b1>;
>> +				};
>> +			};
>> +		};
>> +
>> +		idle-states {
>> +			entry-method = "psci";
>> +
>> +			cpu_sleep: cpu-sleep-0 {
>> +				compatible = "arm,idle-state";
>> +			};
>> +		};
>
> why the essentially empty idle-states, which is probably missing properties?
> In the absence of a real idle driver the kernel will fall back to
> arch_cpu_idle(), which already does WFI handling even on arm64.
>
the idle node will be added by my colleague with new patch later,
so I will remove it first in next version patch.
>
>> +
>> +		cpu_l0: cpu at 0 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			reg = <0x0 0x0>;
>> +			cpu-idle-states = <&cpu_sleep>;
>
> that won't compile, as the referenced node is not present
>
>
>> +			enable-method = "psci";
>> +		};
>> +
>> +		cpu_l1: cpu at 1 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			reg = <0x0 0x1>;
>> +			cpu-idle-states = <&cpu_sleep>;
>> +			enable-method = "psci";
>> +		};
>> +
>> +		cpu_l2: cpu at 2 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			reg = <0x0 0x2>;
>> +			cpu-idle-states = <&cpu_sleep>;
>> +			enable-method = "psci";
>> +		};
>> +
>> +		cpu_l3: cpu at 3 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a53", "arm,armv8";
>> +			reg = <0x0 0x3>;
>> +			cpu-idle-states = <&cpu_sleep>;
>> +			enable-method = "psci";
>> +		};
>> +
>> +		cpu_b0: cpu at 100 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a72", "arm,armv8";
>> +			reg = <0x0 0x100>;
>> +			cpu-idle-states = <&cpu_sleep>;
>> +			enable-method = "psci";
>> +		};
>> +
>> +		cpu_b1: cpu at 101 {
>> +			device_type = "cpu";
>> +			compatible = "arm,cortex-a72", "arm,armv8";
>> +			reg = <0x0 0x101>;
>> +			cpu-idle-states = <&cpu_sleep>;
>> +			enable-method = "psci";
>> +		};
>> +	};
>> +
>> +	pmu {
>> +		compatible = "arm,armv8-pmuv3";
>> +		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
>> +		interrupt-affinity = <&cpu_l0>, <&cpu_l1>, <&cpu_l2>,
>> +				     <&cpu_l3>, <&cpu_b0>, <&cpu_b1>;
>> +	};
>> +
>> +	timer {
>> +		compatible = "arm,armv8-timer";
>> +		interrupts =
>> +			<GIC_PPI 13
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>
> shouldn't that be GIC_CPU_MASK_SIMPLE(6) instead of 4?
>
ok, will fix it in next version patch
>
>> +			<GIC_PPI 14
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			<GIC_PPI 11
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
>> +			<GIC_PPI 10
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>> +		clock-frequency = <24000000>;
>> +	};
>> +
>> +	xin24m: xin24m {
>> +		compatible = "fixed-clock";
>> +		#clock-cells = <0>;
>> +		clock-frequency = <24000000>;
>> +		clock-output-names = "xin24m";
>> +	};
>> +
>> +	gic: interrupt-controller at fee00000 {
>> +		compatible = "arm,gic-v3";
>> +		#interrupt-cells = <3>;
>> +		#address-cells = <2>;
>> +		#size-cells = <2>;
>> +		ranges;
>> +		interrupt-controller;
>> +
>> +		reg = <0x0 0xfee00000 0 0x10000>, /* GICD */
>> +		      <0x0 0xfef00000 0 0xc0000>, /* GICR */
>> +		      <0x0 0xfff00000 0 0x10000>, /* GICC */
>> +		      <0x0 0xfff10000 0 0x10000>, /* GICH */
>> +		      <0x0 0xfff20000 0 0x10000>; /* GICV */
>> +		interrupts =
>> +			<GIC_PPI 9
>> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>
> again GIC_CPU_MASK_SIMPLE(6)?
ok.
>
>> +		its: interrupt-controller at fee20000 {
>> +			compatible = "arm,gic-v3-its";
>> +			msi-controller;
>> +			reg = <0x0 0xfee20000 0x0 0x20000>;
>> +		};
>> +	};
>> +
>> +	amba {
>> +		compatible = "arm,amba-bus";
>> +		#address-cells = <2>;
>> +		#size-cells = <2>;
>> +		ranges;
>> +
>> +		dmac_bus: dma-controller at ff6d0000 {
>> +			compatible = "arm,pl330", "arm,primecell";
>> +			reg = <0x0 0xff6d0000 0x0 0x4000>;
>> +			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
>> +			#dma-cells = <1>;
>> +			clocks = <&cru ACLK_DMAC_BUS>;
>> +			clock-names = "apb_pclk";
>
> has the FLUSHP bug gotten fixed? That would be cool.
>
Since amba node is added by my colleague, I will double check it, thanks
>
>> +		};
>
> rest looks nice on first glance :-)
>
>
> Heiko
>
>
>



From k.kozlowski at samsung.com  Wed Feb 17 17:47:21 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Thu, 18 Feb 2016 10:47:21 +0900
Subject: [RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high
 load
In-Reply-To: <CANAwSgQHiJGSYB7Qhq066Mqfskwrr_3SDQGXH-WN=Wt3SEF-QA@mail.gmail.com>
References: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
 <1455692128-28504-4-git-send-email-k.kozlowski@samsung.com>
 <CANAwSgQHiJGSYB7Qhq066Mqfskwrr_3SDQGXH-WN=Wt3SEF-QA@mail.gmail.com>
Message-ID: <56C522A9.8070800@samsung.com>

On 18.02.2016 04:53, Anand Moon wrote:
> Hi Krzysztof,
> 
> On 17 February 2016 at 12:25, Krzysztof Kozlowski
> <k.kozlowski at samsung.com> wrote:
>> After adding cpufreq-dt support to Exynos542x, the Odroid XU3-Lite can
>> be easily overheated when launching eight CPU-intensive tasks:
>>         thermal thermal_zone3: critical temperature reached(121 C),shutting down
>>
>> This seems to be specific to Odroid XU3-Lite board which officially
>> supports lower frequencies than regular XU3 or XU4. When working at
>> maximum CPU speed (1800 MHz big and 1300 MHz LITTLE) in warmer place for
>> longer time, the fan fails to cool down the board and it reaches
>> critical temperature.
>>
>> Add CPU cooling to Exynos5422/5800 to fix this issue. When reaching 95
>> degrees of Celsius, the board will slow down by 3 steps (around
>> 1400/1000 MHz). When reaching 110 degrees of Celsius go to 600 MHz.
>>
>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
>> ---
>>  arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 41 +++++++++++++++++++++++++++
>>  1 file changed, 41 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>> index 2b289d7c0d13..66073ce29aee 100644
>> --- a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>> @@ -34,6 +34,16 @@
>>                                         hysteresis = <5000>; /* millicelsius */
>>                                         type = "active";
>>                                 };
>> +                               cpu_alert3: cpu-alert-3 {
>> +                                       temperature = <95000>; /* millicelsius */
>> +                                       hysteresis = <5000>; /* millicelsius */
>> +                                       type = "passive";
>> +                               };
>> +                               cpu_alert4: cpu-alert-4 {
>> +                                       temperature = <110000>; /* millicelsius */
>> +                                       hysteresis = <5000>; /* millicelsius */
>> +                                       type = "passive";
>> +                               };
>>                                 cpu_crit0: cpu-crit-0 {
>>                                         temperature = <120000>; /* millicelsius */
>>                                         hysteresis = <0>; /* millicelsius */
>> @@ -53,6 +63,37 @@
>>                                      trip = <&cpu_alert2>;
>>                                      cooling-device = <&fan0 2 3>;
>>                                 };
>> +
>> +                               /*
>> +                                * When reaching cpu_alert3, reduce CPU
>> +                                * by 3 steps. On Exynos5422/5800 that would
>> +                                * be: 1400 MHz and 1000 MHz.
>> +                                */
>> +                               map3 {
>> +                                    trip = <&cpu_alert3>;
>> +                                    cooling-device = <&cpu0 3 3>;
>> +                               };
>> +                               map4 {
>> +                                    trip = <&cpu_alert3>;
>> +                                    cooling-device = <&cpu4 3 3>;
>> +                               };
>> +
>> +                               /*
>> +                                * When reaching cpu_alert4, reduce CPU
>> +                                * to 600 MHz (11 steps for big, 7 steps for
>> +                                * LITTLE).
>> +                                * Exynos5420 has less OPPs and reversed
>> +                                * numbering of CPUs (big/LITTLE) so this
>> +                                * would not match.
>> +                                */
>> +                               map5 {
>> +                                    trip = <&cpu_alert4>;
>> +                                    cooling-device = <&cpu0 7 7>;
>> +                               };
>> +                               map6 {
>> +                                    trip = <&cpu_alert4>;
>> +                                    cooling-device = <&cpu4 11 11>;
>> +                               };
>>                         };
>>                 };
>>         };
>> --
>> 2.5.0
>>
> 
> could you append this patch with following changes.

Could you describe why?

> diff --git a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
> b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
> index 66073ce..4e72637 100644
> --- a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
> @@ -16,8 +16,8 @@
>         thermal-zones {
>                 cpu0_thermal: cpu0-thermal {
>                         thermal-sensors = <&tmu_cpu0 0>;
> -                       polling-delay-passive = <0>;
> -                       polling-delay = <0>;
> +                       polling-delay-passive = <250>; /* milliseconds */
> +                       polling-delay = <500>; /* milliseconds */
>                         trips {
>                                 cpu_alert0: cpu-alert-0 {
>                                         temperature = <50000>; /*
> millicelsius */
> ---
> On running linaro pm-qa diagnostic tool
> ----------------------------------------------------------
> 
> thermal_01.28: checking 'thermal_zone2'/'trip_point_2_temp' ='110000'...    Ok
> thermal_01.29: checking 'cdev0_trip_point' exists in
> '/sys/devices/virtual/thermal/thermal_zone0'... Ok
> thermal_01.30: checking 'thermal_zone0/cdev0_trip_point' valid binding...   Ok
> thermal_01.31: checking 'cdev4_trip_point' exists in
> '/sys/devices/virtual/thermal/thermal_zone0'... Ok
> thermal_01.32: checking 'thermal_zone0/cdev4_trip_point' valid binding...   Err
> thermal_01.33: checking 'cdev4_trip_point' exists in
> '/sys/devices/virtual/thermal/thermal_zone0'... Ok
> thermal_01.34: checking 'thermal_zone0/cdev4_trip_point' valid binding...   Err
> thermal_01.35: checking 'cdev4_trip_point' exists in
> '/sys/devices/virtual/thermal/thermal_zone0'... Ok
> thermal_01.36: checking 'thermal_zone0/cdev4_trip_point' valid binding...   Err
> thermal_01.37: checking 'cdev4_trip_point' exists in
> '/sys/devices/virtual/thermal/thermal_zone0'... Ok
> thermal_01.38: checking 'thermal_zone0/cdev4_trip_point' valid binding...   Err
> 
> thermal_01: fail
> -------------------------------------------------------
> I also got lot's of error.
> 
> root at odroidxu4l:~# cpu[ 3050.847663] cpu cpu4: Failed to find dev_opp: -19
> [ 3171.640836] cpu cpu4: device_opp_debug_create_link: Failed to create link
> [ 3171.646197] cpu cpu4: _add_list_dev: Failed to register opp debugfs (-12)
> [ 3171.653574] cpu cpu7: device_opp_debug_create_link: Failed to create link
> [ 3171.659752] cpu cpu7: _add_list_dev: Failed to register opp debugfs (-12)
> [ 3171.697011] cpu cpu5: cpufreq_init: failed to get clk: -2
> [ 3171.732505] cpu cpu6: cpufreq_init: failed to get clk: -2
> [ 3171.768160] cpu cpu7: cpufreq_init: failed to get clk: -2
> 
> Tested on Odroid-XU4
> 
> Reviewed-by: Anand Moon <linux.amoon at gmail.com>
> Tested-by: Anand Moon <linux.amoon at gmail.com>

The patch is not sufficient. It does not work the way it should...

BTW, I found the issue. The order of trip points in DT:
thermal_zone0/trip_point_0_hyst:5000
thermal_zone0/trip_point_0_temp:50000
thermal_zone0/trip_point_0_type:active
thermal_zone0/trip_point_1_hyst:5000
thermal_zone0/trip_point_1_temp:60000
thermal_zone0/trip_point_1_type:active
thermal_zone0/trip_point_2_hyst:5000
thermal_zone0/trip_point_2_temp:70000
thermal_zone0/trip_point_2_type:active
thermal_zone0/trip_point_3_hyst:0
thermal_zone0/trip_point_3_temp:120000	<---- this should be last one!
thermal_zone0/trip_point_3_type:critical
thermal_zone0/trip_point_4_hyst:5000
thermal_zone0/trip_point_4_temp:90000
thermal_zone0/trip_point_4_type:passive
thermal_zone0/trip_point_5_hyst:5000
thermal_zone0/trip_point_5_temp:110000
thermal_zone0/trip_point_5_type:passive

After fixing the order in DT, the cpu cooler starts working.

Best regards,
Krzysztof



From yong.wu at mediatek.com  Wed Feb 17 09:52:15 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Thu, 18 Feb 2016 01:52:15 +0800
Subject: [PATCH v8 3/5] memory: mediatek: Add SMI driver
In-Reply-To: <20160216141059.GT18805@8bytes.org>
References: <1453781562-23556-1-git-send-email-yong.wu@mediatek.com>
 <1453781562-23556-4-git-send-email-yong.wu@mediatek.com>
 <56ADE959.2050309@gmail.com> <20160216141059.GT18805@8bytes.org>
Message-ID: <1455731535.10704.8.camel@mhfsdcap03>

On Tue, 2016-02-16 at 15:11 +0100, Joerg Roedel wrote:
> On Sun, Jan 31, 2016 at 12:00:41PM +0100, Matthias Brugger wrote:
> > 
> > 
> > On 26/01/16 05:12, Yong Wu wrote:
> > >This patch add SMI(Smart Multimedia Interface) driver. This driver
> > >is responsible to enable/disable iommu and control the power domain
> > >and clocks of each local arbiter.
> > >
> > >Signed-off-by: Yong Wu <yong.wu at mediatek.com>
> > >Tested-by: Philipp Zabel <p.zabel at pengutronix.de>
> > >---
> > 
> > Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
> > 
> > Joerg would you mind to take this through your branch?
> 
> Hmm, I somehow missed the patch-set, at least I can't find the v8
> patches in my inbox.
> 
> Yong, can you please re-send with all Acks and other tags added?

Hi Joerg,
  
     I have re-sent v9[1] which has added all the tags yesterday.

     Could you find them in your inbox? If not again, please tell me.

     Thanks.

[1]:http://lists.linuxfoundation.org/pipermail/iommu/2016-February/015713.html

> 
> 
> Thanks,
> 
> 	Joerg
> 




From alexandre.belloni at free-electrons.com  Wed Feb 17 17:56:34 2016
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Thu, 18 Feb 2016 02:56:34 +0100
Subject: [GIT PULL] at91: defconfig for 4.6 #1
Message-ID: <20160218015634.GA31609@piout.net>

Arnd, Olof, Kevin,

A defconfig update, adding the sama5d2 ADC to sama5_defconfig.

Thanks,


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.6-defconfig

for you to fetch changes up to 48a2e12adb7f4d1a03720d3923bedbc13ab96143:

  ARM: at91/defconfig: add sama5d2 adc support in sama5_defconfig (2016-02-17 22:51:48 +0100)

----------------------------------------------------------------
defconfig update for 4.6:
 - Addition of sama5d2 ADC to sama5_defconfig

----------------------------------------------------------------
Ludovic Desroches (1):
      ARM: at91/defconfig: add sama5d2 adc support in sama5_defconfig

 arch/arm/configs/sama5_defconfig | 1 +
 1 file changed, 1 insertion(+)

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From jason at lakedaemon.net  Wed Feb 17 18:03:05 2016
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 18 Feb 2016 02:03:05 +0000
Subject: [PATCH] irqchip: bcm2836: Drop extra memory barrier in SMP boot.
In-Reply-To: <1454620468-31303-1-git-send-email-eric@anholt.net>
References: <1454620468-31303-1-git-send-email-eric@anholt.net>
Message-ID: <20160218020305.GR5183@io.lakedaemon.net>

On Thu, Feb 04, 2016 at 01:14:28PM -0800, Eric Anholt wrote:
> The writel() immediately after this has a barrier, anyway.
> 
> Signed-off-by: Eric Anholt <eric at anholt.net>
> ---
>  drivers/irqchip/irq-bcm2836.c | 1 -
>  1 file changed, 1 deletion(-)

Applied to irqchip/core

thx,

Jason.


From alexandre.belloni at free-electrons.com  Wed Feb 17 18:06:08 2016
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Thu, 18 Feb 2016 03:06:08 +0100
Subject: [GIT PULL] at91: drivers for 4.6 #1
Message-ID: <20160218020608.GA31682@piout.net>

Arnd, Olof, Kevin,

This is a rework of the PMC driver. It touches multiple subsystems so
the easiest path is through arm-soc.

Thanks,

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.6-drivers

for you to fetch changes up to 0002ca168f16e5b6ac67415a4e0198cc39af2b7f:

  clk: at91: remove useless includes (2016-02-17 17:53:04 +0100)

----------------------------------------------------------------
drivers update for 4.6:
 - Big PMC rework that touches clk, PM, usb

----------------------------------------------------------------
Alexandre Belloni (11):
      clk: at91: remove IRQ handling and use polling
      clk: at91: pmc: merge at91_pmc_init in atmel_pmc_probe
      clk: at91: pmc: move pmc structures to C file
      ARM: at91: pm: simply call at91_pm_init
      ARM: at91: pm: find and remap the pmc
      ARM: at91: pm: move idle functions to pm.c
      ARM: at91: remove useless includes and function prototypes
      usb: gadget: atmel: access the PMC using regmap
      clk: at91: pmc: drop at91_pmc_base
      clk: at91: pmc: remove useless capacities handling
      clk: at91: remove useless includes

Boris Brezillon (2):
      clk: at91: make use of syscon to share PMC registers in several drivers
      clk: at91: make use of syscon/regmap internally

 arch/arm/mach-at91/Kconfig              |   1 +
 arch/arm/mach-at91/at91rm9200.c         |   2 -
 arch/arm/mach-at91/at91sam9.c           |   2 -
 arch/arm/mach-at91/generic.h            |  13 +-
 arch/arm/mach-at91/pm.c                 |  70 +++++-
 arch/arm/mach-at91/sama5.c              |   2 +-
 drivers/clk/at91/clk-generated.c        |  95 ++++---
 drivers/clk/at91/clk-h32mx.c            |  40 +--
 drivers/clk/at91/clk-main.c             | 324 +++++++++++-------------
 drivers/clk/at91/clk-master.c           |  94 +++----
 drivers/clk/at91/clk-peripheral.c       | 137 +++++-----
 drivers/clk/at91/clk-pll.c              | 150 +++++------
 drivers/clk/at91/clk-plldiv.c           |  44 ++--
 drivers/clk/at91/clk-programmable.c     |  96 +++----
 drivers/clk/at91/clk-slow.c             |  35 +--
 drivers/clk/at91/clk-smd.c              |  56 +++--
 drivers/clk/at91/clk-system.c           |  96 +++----
 drivers/clk/at91/clk-usb.c              | 123 ++++-----
 drivers/clk/at91/clk-utmi.c             |  80 ++----
 drivers/clk/at91/pmc.c                  | 426 +-------------------------------
 drivers/clk/at91/pmc.h                  |  98 +-------
 drivers/usb/gadget/udc/atmel_usba_udc.c |  20 +-
 drivers/usb/gadget/udc/atmel_usba_udc.h |   2 +
 include/linux/clk/at91_pmc.h            |  12 -
 24 files changed, 724 insertions(+), 1294 deletions(-)

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160218/e96f2dc7/attachment-0001.sig>

From Larry.Finger at lwfinger.net  Wed Feb 17 18:20:15 2016
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Wed, 17 Feb 2016 20:20:15 -0600
Subject: [PATCH] staging: rtl8712: reduce stack usage
In-Reply-To: <1455698012-814399-1-git-send-email-arnd@arndb.de>
References: <1455698012-814399-1-git-send-email-arnd@arndb.de>
Message-ID: <56C52A5F.2030302@lwfinger.net>

On 02/17/2016 02:32 AM, Arnd Bergmann wrote:
> The "translate_scan" function in rtl8712 uses a lot of stack, and
> gets inlined into its single caller, r8711_wx_get_scan, which
> in some configurations now blows the 1024 byte stack warning
> limit:
>
> drivers/staging/rtl8712/rtl871x_ioctl_linux.c: In function 'r8711_wx_get_scan':
> drivers/staging/rtl8712/rtl871x_ioctl_linux.c:1227:1: error: the frame size of 1032 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
>
> This somewhat reduces the stack usage by moving the translate_scan
> function out of line with the noinline_for_stack annotation.
> It might be possible to modify translate_scan() a little further
> to reduce the stack usage, but with this patch, we can build without
> the warning, the the call chain to get here is rather predictable
> (sys_ioctl->vfs_ioctl->sock_ioctl->dev_ioctl->wext_ioctl->
> r8711_wx_get_scan).
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>   drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

As there is no reason for translate_scan() to be inlined, this patch seems 
reasonable The largest user of stack likely comes from the line "struct iw_event 
iwe". Changing that to a pointer, and using kalloc to acquire the space would 
likely clear the compile message, but that would require many more changes.

Acked-by: Larry Finger <Larry.Finger at lwfinger.net>

Larry

>
> diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> index db2e31bcdd77..a15f3ce70223 100644
> --- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> +++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
> @@ -137,7 +137,7 @@ static inline void handle_group_key(struct ieee_param *param,
>   	}
>   }
>
> -static inline char *translate_scan(struct _adapter *padapter,
> +static noinline_for_stack char *translate_scan(struct _adapter *padapter,
>   				   struct iw_request_info *info,
>   				   struct wlan_network *pnetwork,
>   				   char *start, char *stop)
>



From alexandre.belloni at free-electrons.com  Wed Feb 17 18:23:11 2016
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Thu, 18 Feb 2016 03:23:11 +0100
Subject: [GIT PULL] at91: dt for 4.6 #1
Message-ID: <20160218022311.GA2466@piout.net>

Arnd, Olof, Kevin,

This is the addition of the ADC support for sama5d2. The driver went
through the iio tree.

Thanks!

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.6-dt

for you to fetch changes up to 5e72c25b40c1e9ed77650f258799514aabd17303:

  ARM: dts: at91: sama5d2 Xplained: enable the adc device (2016-02-18 03:10:05 +0100)

----------------------------------------------------------------
DT changes for 4.6:
 - Addition of the ADC for sama5d2 and sama5d2_xplained

----------------------------------------------------------------
Ludovic Desroches (2):
      ARM: dts: at91: sama5d2: add adc device
      ARM: dts: at91: sama5d2 Xplained: enable the adc device

 arch/arm/boot/dts/at91-sama5d2_xplained.dts | 22 ++++++++++++++++++++++
 arch/arm/boot/dts/sama5d2.dtsi              | 18 ++++++++++++------
 2 files changed, 34 insertions(+), 6 deletions(-)

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160218/80da022e/attachment.sig>

From viresh.kumar at linaro.org  Wed Feb 17 18:36:22 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 18 Feb 2016 08:06:22 +0530
Subject: [RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high
 load
In-Reply-To: <56C522A9.8070800@samsung.com>
References: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
 <1455692128-28504-4-git-send-email-k.kozlowski@samsung.com>
 <CANAwSgQHiJGSYB7Qhq066Mqfskwrr_3SDQGXH-WN=Wt3SEF-QA@mail.gmail.com>
 <56C522A9.8070800@samsung.com>
Message-ID: <20160218023622.GA2610@vireshk-i7>

On 18-02-16, 10:47, Krzysztof Kozlowski wrote:
> On 18.02.2016 04:53, Anand Moon wrote:
> > I also got lot's of error.
> > 
> > root at odroidxu4l:~# cpu[ 3050.847663] cpu cpu4: Failed to find dev_opp: -19
> > [ 3171.640836] cpu cpu4: device_opp_debug_create_link: Failed to create link
> > [ 3171.646197] cpu cpu4: _add_list_dev: Failed to register opp debugfs (-12)
> > [ 3171.653574] cpu cpu7: device_opp_debug_create_link: Failed to create link
> > [ 3171.659752] cpu cpu7: _add_list_dev: Failed to register opp debugfs (-12)
> > [ 3171.697011] cpu cpu5: cpufreq_init: failed to get clk: -2
> > [ 3171.732505] cpu cpu6: cpufreq_init: failed to get clk: -2
> > [ 3171.768160] cpu cpu7: cpufreq_init: failed to get clk: -2
> > 
> > Tested on Odroid-XU4
> > 
> > Reviewed-by: Anand Moon <linux.amoon at gmail.com>
> > Tested-by: Anand Moon <linux.amoon at gmail.com>

What was this Tested-by supposed to mean? You got errors out there ...

> The patch is not sufficient. It does not work the way it should...
> 
> BTW, I found the issue. The order of trip points in DT:
> thermal_zone0/trip_point_0_hyst:5000
> thermal_zone0/trip_point_0_temp:50000
> thermal_zone0/trip_point_0_type:active
> thermal_zone0/trip_point_1_hyst:5000
> thermal_zone0/trip_point_1_temp:60000
> thermal_zone0/trip_point_1_type:active
> thermal_zone0/trip_point_2_hyst:5000
> thermal_zone0/trip_point_2_temp:70000
> thermal_zone0/trip_point_2_type:active
> thermal_zone0/trip_point_3_hyst:0
> thermal_zone0/trip_point_3_temp:120000	<---- this should be last one!
> thermal_zone0/trip_point_3_type:critical
> thermal_zone0/trip_point_4_hyst:5000
> thermal_zone0/trip_point_4_temp:90000
> thermal_zone0/trip_point_4_type:passive
> thermal_zone0/trip_point_5_hyst:5000
> thermal_zone0/trip_point_5_temp:110000
> thermal_zone0/trip_point_5_type:passive
> 
> After fixing the order in DT, the cpu cooler starts working.

Ahh, nice.

-- 
viresh


From jay.xu at rock-chips.com  Wed Feb 17 18:36:19 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Thu, 18 Feb 2016 10:36:19 +0800
Subject: [PATCH v2 0/4] Add core dtsi for rk3399 from Rockchip
Message-ID: <1455762983-29980-1-git-send-email-jay.xu@rock-chips.com>

From: Jianqun Xu <jay.xu at rock-chips.com>

There is the new SoCs from Rockchip which named rk3399, the
patches are added to support them.

Xing Zheng (2):
  clk: rockchip: add dt-binding header for rk3399
  dt-bindings: add documentation of rk3399 clock controller

Xu Jianqun (2):
  spi: rockchip: add bindings for rk3399 spi
  ARM64: dts: rockchip: add core dtsi file for rk3399

 .../bindings/clock/rockchip,rk3399-cru.txt         |  82 ++
 .../devicetree/bindings/spi/spi-rockchip.txt       |   1 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           | 949 +++++++++++++++++++++
 include/dt-bindings/clock/rk3399-cru.h             | 609 +++++++++++++
 4 files changed, 1641 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
 create mode 100644 include/dt-bindings/clock/rk3399-cru.h

-- 
changes in v2:
- remove changeID (Heiko, Mark)
- drop pmu and psci temporary (Mark)
- drop applied patch (Heiko)
- drop GIC_CPU_MASK_SIMPLE from the interrupt specifiers (Marc, Heiko)
- drop clock-frequency of timer (Marc, Mark)
- remove double defination for SCLK_SPI5

1.9.1




From jay.xu at rock-chips.com  Wed Feb 17 18:36:22 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Thu, 18 Feb 2016 10:36:22 +0800
Subject: [PATCH v2 3/4] dt-bindings: add documentation of rk3399 clock
 controller
In-Reply-To: <1455762983-29980-1-git-send-email-jay.xu@rock-chips.com>
References: <1455762983-29980-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455762983-29980-4-git-send-email-jay.xu@rock-chips.com>

From: Xing Zheng <zhengxing at rock-chips.com>

Add the devicetree binding for the cru on the rk3399 which quite
similar structured as previous clock controllers.

Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v2:
- none

 .../bindings/clock/rockchip,rk3399-cru.txt         | 82 ++++++++++++++++++++++
 1 file changed, 82 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
new file mode 100644
index 0000000..07bcc6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
@@ -0,0 +1,82 @@
+* Rockchip RK3399 Clock and Reset Unit
+
+The RK3399 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: PMU for CRU should be "rockchip,rk3399-pmucru"
+- compatible: CRU should be "rockchip,rk3399-cru"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+  If missing, pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "xin32k" - rtc clock - optional,
+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_gmac" - external GMAC clock - optional
+ - "ext_hsadc" - external HSADC clock - optional,
+ - "ext_isp" - external ISP clock - optional,
+ - "ext_jtag" - external JTAG clock - optional
+ - "ext_vip" - external VIP clock - optional,
+ - "usbotg_out" - output clock of the pll in the otg phy
+
+Example: General Register Files
+
+	pmugrf: syscon at ff320000 {
+		compatible = "rockchip,rk3399-pmugrf", "syscon";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+	};
+
+	grf: syscon at ff770000 {
+		compatible = "rockchip,rk3399-grf", "syscon";
+		reg = <0x0 0xff770000 0x0 0x10000>;
+	};
+
+Example: Clock controller node:
+
+	pmucru: pmu-clock-controller at ff750000 {
+		compatible = "rockchip,rk3399-pmucru";
+		reg = <0x0 0xff750000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at ff760000 {
+		compatible = "rockchip,rk3399-cru";
+		reg = <0x0 0xff760000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller:
+
+	uart0: serial at ff1a0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff180000 0x0 0x100>;
+		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+	};
-- 
1.9.1




From jay.xu at rock-chips.com  Wed Feb 17 18:36:21 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Thu, 18 Feb 2016 10:36:21 +0800
Subject: [PATCH v2 2/4] spi: rockchip: add bindings for rk3399 spi
In-Reply-To: <1455762983-29980-1-git-send-email-jay.xu@rock-chips.com>
References: <1455762983-29980-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455762983-29980-3-git-send-email-jay.xu@rock-chips.com>

From: Xu Jianqun <jay.xu at rock-chips.com>

Add devicetree bindings for Rockchip rk3399 spi which found on
Rockchip rk3399 SoCs.

Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v2:
- none

 Documentation/devicetree/bindings/spi/spi-rockchip.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
index 0c491bd..1b14d69 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
@@ -9,6 +9,7 @@ Required Properties:
     "rockchip,rk3066-spi" for rk3066.
     "rockchip,rk3188-spi", "rockchip,rk3066-spi" for rk3188.
     "rockchip,rk3288-spi", "rockchip,rk3066-spi" for rk3288.
+    "rockchip,rk3399-spi", "rockchip,rk3066-spi" for rk3399.
 - reg: physical base address of the controller and length of memory mapped
        region.
 - interrupts: The interrupt number to the cpu. The interrupt specifier format
-- 
1.9.1




From jay.xu at rock-chips.com  Wed Feb 17 18:36:20 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Thu, 18 Feb 2016 10:36:20 +0800
Subject: [PATCH v2 1/4] clk: rockchip: add dt-binding header for rk3399
In-Reply-To: <1455762983-29980-1-git-send-email-jay.xu@rock-chips.com>
References: <1455762983-29980-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455762983-29980-2-git-send-email-jay.xu@rock-chips.com>

From: Xing Zheng <zhengxing at rock-chips.com>

Add the dt-bindings header for the rk3399, that gets shared between
the clock controller and the clock references in the dts.

Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v2:
- remove duplicate defination of SCLK_SPI5

 include/dt-bindings/clock/rk3399-cru.h | 609 +++++++++++++++++++++++++++++++++
 1 file changed, 609 insertions(+)
 create mode 100644 include/dt-bindings/clock/rk3399-cru.h

diff --git a/include/dt-bindings/clock/rk3399-cru.h b/include/dt-bindings/clock/rk3399-cru.h
new file mode 100644
index 0000000..9fbe3dc
--- /dev/null
+++ b/include/dt-bindings/clock/rk3399-cru.h
@@ -0,0 +1,609 @@
+/*
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng <zhengxing at rock-chips.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H
+#define _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H
+
+/* core clocks */
+#define PLL_APLLL		1
+#define PLL_APLLB		2
+#define PLL_DPLL		3
+#define PLL_CPLL		4
+#define PLL_GPLL		5
+#define PLL_NPLL		6
+#define PLL_VPLL		7
+#define PLL_PPLL		8
+#define ARMCLKL			9
+#define ARMCLKB			10
+
+/* sclk gates (special clocks) */
+#define SCLK_GPU_CORE		64
+#define SCLK_SPI0		65
+#define SCLK_SPI1		66
+#define SCLK_SPI2		68
+#define SCLK_SPI3		69
+#define SCLK_SPI4		70
+#define SCLK_SDMMC		72
+#define SCLK_SDIO0		73
+#define SCLK_EMMC		74
+#define SCLK_TSADC		75
+#define SCLK_SARADC		76
+#define SCLK_NANDC0		77
+#define SCLK_UART0		78
+#define SCLK_UART1		79
+#define SCLK_UART2		80
+#define SCLK_UART3		81
+#define SCLK_UART4		82
+#define SCLK_SPDIF_8CH		83
+#define SCLK_I2S0_8CH		84
+#define SCLK_I2S1_8CH		85
+#define SCLK_I2S2_8CH		86
+#define SCLK_TIMER00		87
+#define SCLK_TIMER01		88
+#define SCLK_TIMER02		89
+#define SCLK_TIMER03		90
+#define SCLK_TIMER04		91
+#define SCLK_TIMER05		92
+#define SCLK_TIMER06		93
+#define SCLK_TIMER07		94
+#define SCLK_TIMER08		95
+#define SCLK_TIMER09		96
+#define SCLK_TIMER10		97
+#define SCLK_TIMER11		98
+#define SCLK_HSICPHY480M	99
+#define SCLK_HSICPHY12M		100
+#define SCLK_MACREF		101
+#define SCLK_VOPB_PWM		102
+#define SCLK_VOPL_PWM		103
+#define SCLK_EDP_24M		104
+#define SCLK_EDP		105
+#define SCLK_RGA		106
+#define SCLK_ISP		107
+#define SCLK_HDCP		108
+#define SCLK_HDMI_HDCP		109
+#define SCLK_HDMI_CEC		110
+#define SCLK_HEVC_CABAC		111
+#define SCLK_HEVC_CORE		112
+#define SCLK_I2S_8CH_OUT	113
+#define SCLK_SDMMC_DRV		114
+#define SCLK_SDIO0_DRV		115
+#define SCLK_SDIO1_DRV		116
+#define SCLK_EMMC_DRV		117
+#define SCLK_SDMMC_SAMPLE	118
+#define SCLK_SDIO0_SAMPLE	119
+#define SCLK_SDIO1_SAMPLE	120
+#define SCLK_EMMC_SAMPLE	121
+#define SCLK_USBPHY480M		122
+#define SCLK_PVTM_CORE_L	123
+#define SCLK_PVTM_CORE_B	124
+#define SCLK_PVTM_GPU		125
+#define SCLK_PVTM_PMU		126
+#define SCLK_SFC		127
+#define SCLK_MAC_RX		128
+#define SCLK_MAC_TX		129
+#define SCLK_MAC		130
+#define SCLK_MACREF_OUT		131
+#define SCLK_USB2_PHY0_REF	132
+#define SCLK_USB2_PHY1_REF	133
+#define SCLK_USB3_OTG0_REF	134
+#define SCLK_USB3_OTG1_REF	135
+#define SCLK_USB3_OTG0_SUSPEND	136
+#define SCLK_USB3_OTG1_SUSPEND	137
+#define SCLK_CRYPTO		138
+#define SCLK_CRYPTO1		139
+
+#define DCLK_VOPB		170
+#define DCLK_VOPL		171
+#define MCLK_CRYPTO		172
+#define MCLK_CRYPTO1		173
+
+/* aclk gates */
+#define ACLK_GPU_MEM		192
+#define ACLK_GPU_CFG		193
+#define ACLK_DMAC_BUS		194
+#define ACLK_DMAC_PERI		195
+#define ACLK_PERI_MMU		196
+#define ACLK_GMAC		197
+#define ACLK_VOPB		198
+#define ACLK_VOPL		199
+#define ACLK_RGA		200
+#define ACLK_HDCP		201
+#define ACLK_IEP		202
+#define ACLK_VIO0_NOC		203
+#define ACLK_VIP		204
+#define ACLK_ISP		205
+#define ACLK_VIO1_NOC		206
+#define ACLK_VIDEO		208
+#define ACLK_BUS		209
+#define ACLK_PERI		210
+#define ACLK_EMMC_GPLL		211
+#define ACLK_EMMC_CPLL		212
+#define ACLK_EMMC_CORE		213
+#define ACLK_EMMC_NIU 		214
+#define ACLK_EMMC_GRF 		215
+#define ACLK_USB3_OTG0		216
+#define ACLK_USB3_OTG1		217
+#define ACLK_USB3_GRF 		218
+
+/* pclk gates */
+#define PCLK_GPIO0		320
+#define PCLK_GPIO1		321
+#define PCLK_GPIO2		322
+#define PCLK_GPIO3		323
+#define PCLK_GPIO4		324
+#define PCLK_PMUGRF		325
+#define PCLK_MAILBOX		326
+#define PCLK_GRF		329
+#define PCLK_SGRF		330
+#define PCLK_PMU		331
+#define PCLK_I2C0		332
+#define PCLK_I2C1		333
+#define PCLK_I2C2		334
+#define PCLK_I2C3		335
+#define PCLK_I2C4		336
+#define PCLK_I2C5		337
+#define PCLK_SPI0		338
+#define PCLK_SPI1		339
+#define PCLK_SPI2		340
+#define PCLK_SPI3		341
+#define PCLK_SPI4		342
+#define PCLK_SPI5		343
+#define PCLK_UART0		344
+#define PCLK_UART1		345
+#define PCLK_UART2		346
+#define PCLK_UART3		347
+#define PCLK_UART4		348
+#define PCLK_TSADC		349
+#define PCLK_SARADC		350
+#define PCLK_SIM		351
+#define PCLK_GMAC		352
+#define PCLK_PWM0		353
+#define PCLK_PWM1		354
+#define PCLK_TIMER0		355
+#define PCLK_TIMER1		356
+#define PCLK_EDP_CTRL		357
+#define PCLK_MIPI_DSI0		358
+#define PCLK_MIPI_CSI		359
+#define PCLK_HDCP		360
+#define PCLK_HDMI_CTRL		361
+#define PCLK_VIO_H2P		362
+#define PCLK_BUS		363
+#define PCLK_PERI		364
+#define PCLK_DDRUPCTL		365
+#define PCLK_DDRPHY		366
+#define PCLK_ISP		367
+#define PCLK_VIP		368
+#define PCLK_WDT		369
+
+/* hclk gates */
+#define HCLK_SFC		448
+#define HCLK_HOST0		450
+#define HCLK_HOST1		451
+#define HCLK_HSIC		452
+#define HCLK_NANDC0		453
+#define HCLK_TSP		455
+#define HCLK_SDMMC		456
+#define HCLK_SDIO0		457
+#define HCLK_EMMC		459
+#define HCLK_HSADC		460
+#define HCLK_CRYPTO		461
+#define HCLK_I2S0_8CH		462
+#define HCLK_I2S1_8CH		463
+#define HCLK_I2S2_8CH		464
+#define HCLK_SPDIF		465
+#define HCLK_VOPB		466
+#define HCLK_VOPL		467
+#define HCLK_ROM		468
+#define HCLK_IEP		469
+#define HCLK_ISP		470
+#define HCLK_RGA		471
+#define HCLK_VIO_AHB_ARBI	472
+#define HCLK_VIO_NOC		473
+#define HCLK_VIP		474
+#define HCLK_VIO_H2P		475
+#define HCLK_VIO_HDCPMMU	476
+#define HCLK_VIDEO		477
+#define HCLK_BUS		478
+#define HCLK_PERI		479
+
+/* pmu-clocks indices */
+#define SCLK_CM0S		500
+#define SCLK_SPI5		501
+#define SCLK_TIMER12		502
+#define SCLK_TIMER13		503
+#define SCLK_UART		504
+
+#define CLK_NR_CLKS		(SCLK_UART + 1)
+
+/* soft-reset indices */
+
+/* cru_softrst_con0 */
+#define SRST_CORE_L0			0
+#define SRST_CORE_B0			1
+#define SRST_CORE_PO_L0			2
+#define SRST_CORE_PO_B0			3
+#define SRST_L2_L			4
+#define SRST_L2_B			5
+#define SRST_ADB_L			6
+#define SRST_ADB_B			7
+#define SRST_A_CCI			8
+#define SRST_A_CCIM0_NIU		9
+#define SRST_A_CCIM1_NIU		10
+#define SRST_DBG_NIU			11
+
+/* cru_softrst_con1 */
+#define SRST_CORE_L0_T			16
+#define SRST_CORE_L1			17
+#define SRST_CORE_L2			18
+#define SRST_CORE_L3			19
+#define SRST_CORE_PO_L0_T		20
+#define SRST_CORE_PO_L1			21
+#define SRST_CORE_PO_L2			22
+#define SRST_CORE_PO_L3			23
+#define SRST_A_ADB400_GIC2_CORE_L	24
+#define SRST_A_ADB400_CORE_L_GIC2	25
+#define SRST_P_DBG_L			26
+#define SRST_SOC_DBG_L			27
+#define SRST_L2_L_T			28
+#define SRST_ADB_L_T			29
+#define SRST_A_RKREF_L			30
+#define SRST_PVTM_CORE_L		31
+
+/* cru_softrst_con2 */
+#define SRST_CORE_B0_T			32
+#define SRST_CORE_B1			33
+#define SRST_CORE_PO_B0_T		36
+#define SRST_CORE_PO_B1			37
+#define SRST_A_ADB400_GIC2_CORE_B	40
+#define SRST_A_ADB400_CORE_B_GIC2	41
+#define SRST_P_DBG_B			42
+#define SRST_L2_B_T			43
+#define SRST_SOC_DBG_B			44
+#define SRST_ADB_B_T			45
+#define SRST_A_RKREF_B			46
+#define SRST_PVTM_CORE_B		47
+
+/* cru_softrst_con3 */
+#define SRST_A_CCI_T			50
+#define SRST_A_CCIM0_NIU_T		51
+#define SRST_A_CCIM1_NIU_T		52
+#define SRST_A_ADB400M_PD_CORE_B_T	53
+#define SRST_A_ADB400M_PD_CORE_L_T	54
+#define SRST_DBG_NIU_T			55
+#define SRST_DBG_CXCS			56
+#define SRST_CCI_TRACE			57
+#define SRST_P_CCI_GRF			58
+
+/* cru_softrst_con4 */
+#define SRST_A_CENTER_MAIN_NIU		64
+#define SRST_A_CENTER_PERI_NIU		65
+#define SRST_P_CENTER_MAIN		66
+#define SRST_P_DDRMAON			67
+#define SRST_P_CIC			68
+#define SRST_P_CENTER_SGRF		69
+#define SRST_DDR0_MSCH			70
+#define SRST_DDRCFG0_MSCH		71
+#define SRST_DDR0			72
+#define SRST_DDRPHY0			73
+#define SRST_DDR1_MSCH			74
+#define SRST_DDRCFG1_MSCH		75
+#define SRST_DDR1			76
+#define SRST_DDRPHY1			77
+#define SRST_DDR_CIC			78
+#define SRST_PVTM_DDR			79
+
+/* cru_softrst_con5 */
+#define SRST_A_VCODEC_NIU		80
+#define SRST_A_VCODEC			81
+#define SRST_H_VCODEC_NIU		82
+#define SRST_H_VCODEC			83
+#define SRST_A_VDU_NIU			88
+#define SRST_A_VDU 			89
+#define SRST_H_VDU_NIU			90
+#define SRST_H_VDU			91
+#define SRST_VDU_CORE			92
+#define SRST_VDU_CA			93
+
+/* cru_softrst_con6 */
+#define SRST_A_IEP_NIU			96
+#define SRST_A_VOP_IEP			97
+#define SRST_A_IEP			98
+#define SRST_H_IEP_NIU			99
+#define SRST_H_IEP			100
+#define SRST_A_RGA_NIU			102
+#define SRST_A_RGA			103
+#define SRST_H_RGA_NIU			104
+#define SRST_H_RGA			105
+#define SRST_RGA_CORE			106
+#define SRST_EMMC_NIU			108
+#define SRST_EMMC			109
+#define SRST_EMMC_GRF			110
+#define SRST_EMMCPHY_SYSRX		111
+
+/* cru_softrst_con7 */
+#define SRST_A_PERIHP_NIU		112
+#define SRST_A_PERIHP_GRF		113
+#define SRST_H_PERIHP_NIU		114
+#define SRST_USBHOST0 			115
+#define SRST_HOSTC0_AUX			116
+#define SRST_HOSTC0_ARB			117
+#define SRST_USBHOST1			118
+#define SRST_HOSTC1_AUX			119
+#define SRST_HOSTC1_ARB			120
+#define SRST_SDIO0			121
+#define SRST_SDMMC			122
+#define SRST_HSIC			123
+#define SRST_HSIC_AUX			124
+#define SRST_AHB1TOM			125
+#define SRST_P_PERIHP_NIU		126
+#define SRST_HSICPHY			127
+
+/* cru_softrst_con8 */
+#define SRST_A_PCIE			128
+#define SRST_P_PCIE			129
+#define SRST_PCIE_CORE			130
+#define SRST_PCIE_MGMT			131
+#define SRST_PCIE_MGMT_STICKY		132
+#define SRST_PCIE_PIPE			133
+#define SRST_PCIE_PM			134
+#define SRST_PCIEPHY			135
+#define SRST_A_GMAC_NIU			136
+#define SRST_A_GMAC 			137
+#define SRST_P_GMAC_NIU			138
+#define SRST_P_GMAC			139
+#define SRST_P_GMAC_GRF			140
+#define SRST_HSICPHY_POR		142
+#define SRST_HSICPHY_UTMI		143
+
+/* cru_softrst_con9 */
+#define SRST_USB2PHY0_POR		144
+#define SRST_USB2PHY0_UTMI_PORT0	145
+#define SRST_USB2PHY0_UTMI_PORT1	146
+#define SRST_USB2PHY0_EHCIPHY		147
+#define SRST_UPHY0_PIPE_L00		148
+#define SRST_UPHY0			149
+#define SRST_UPHY0_TCPDPWRUP		150
+#define SRST_USB2PHY1_POR		152
+#define SRST_USB2PHY1_UTMI_PORT0	153
+#define SRST_USB2PHY1_UTMI_PORT1	154
+#define SRST_USB2PHY1_EHCIPHY		155
+#define SRST_UPHY1_PIPE_L00		156
+#define SRST_UPHY1			157
+#define SRST_UPHY1_TCPDPWRUP		158
+
+/* cru_softrst_con10 */
+#define SRST_A_PERILP0_NIU		160
+#define SRST_A_DCF			161
+#define SRST_GIC500			162
+#define SRST_DMAC0_PERILP0		163
+#define SRST_DMAC1_PERILP0		164
+#define SRST_TZMA			165
+#define SRST_INTMEM			166
+#define SRST_ADB400_MST0		167
+#define SRST_ADB400_MST1		168
+#define SRST_ADB400_SLV0		169
+#define SRST_ADB400_SLV1		170
+#define SRST_H_PERILP0			171
+#define SRST_H_PERILP0_NIU		172
+#define SRST_ROM			173
+#define SRST_CRYPTO_S			174
+#define SRST_CRYPTO_M			175
+
+/* cru_softrst_con11 */
+#define SRST_P_DCF			176
+#define SRST_CM0S_NIU			177
+#define SRST_CM0S			178
+#define SRST_CM0S_DBG			179
+#define SRST_CM0S_PO			180
+#define SRST_CRYPTO			181
+#define SRST_P_PERILP1_SGRF		182
+#define SRST_P_PERILP1_GRF		183
+#define SRST_CRYPTO1_S			184
+#define SRST_CRYPTO1_M			185
+#define SRST_CRYPTO1			186
+#define SRST_GIC_NIU			188
+#define SRST_SD_NIU			189
+#define SRST_SDIOAUDIO_BRG		190
+
+/* cru_softrst_con12 */
+#define SRST_H_PERILP1			192
+#define SRST_H_PERILP1_NIU		193
+#define SRST_H_I2S0_8CH			194
+#define SRST_H_I2S1_8CH			195
+#define SRST_H_I2S2_8CH			196
+#define SRST_H_SPDIF_8CH		197
+#define SRST_P_PERILP1_NIU		198
+#define SRST_P_EFUSE_1024		199
+#define SRST_P_EFUSE_1024S		200
+#define SRST_P_I2C0			201
+#define SRST_P_I2C1			202
+#define SRST_P_I2C2			203
+#define SRST_P_I2C3			204
+#define SRST_P_I2C4			205
+#define SRST_P_I2C5			206
+#define SRST_P_MAILBOX0			207
+
+/* cru_softrst_con13 */
+#define SRST_P_UART0			208
+#define SRST_P_UART1			209
+#define SRST_P_UART2			210
+#define SRST_P_UART3			211
+#define SRST_P_SARADC			212
+#define SRST_P_TSADC			213
+#define SRST_P_SPI0			214
+#define SRST_P_SPI1			215
+#define SRST_P_SPI2			216
+#define SRST_P_SPI3			217
+#define SRST_P_SPI4			218
+#define SRST_SPI0			219
+#define SRST_SPI1			220
+#define SRST_SPI2			221
+#define SRST_SPI3			222
+#define SRST_SPI4			223
+
+/* cru_softrst_con14 */
+#define SRST_I2S0_8CH			224
+#define SRST_I2S1_8CH			225
+#define SRST_I2S2_8CH			226
+#define SRST_SPDIF_8CH			227
+#define SRST_UART0			228
+#define SRST_UART1			229
+#define SRST_UART2			230
+#define SRST_UART3			231
+#define SRST_TSADC			232
+#define SRST_I2C0			233
+#define SRST_I2C1			234
+#define SRST_I2C2			235
+#define SRST_I2C3			236
+#define SRST_I2C4			237
+#define SRST_I2C5			238
+#define SRST_SDIOAUDIO_NIU		239
+
+/* cru_softrst_con15 */
+#define SRST_A_VIO_NIU			240
+#define SRST_A_HDCP_NIU			241
+#define SRST_A_HDCP			242
+#define SRST_H_HDCP_NIU			243
+#define SRST_H_HDCP			244
+#define SRST_P_HDCP_NIU			245
+#define SRST_P_HDCP			246
+#define SRST_P_HDMI_CTRL		247
+#define SRST_P_DP_CTRL			248
+#define SRST_S_DP_CTRL			249
+#define SRST_C_DP_CTRL			250
+#define SRST_P_MIPI_DSI0		251
+#define SRST_P_MIPI_DSI1		252
+#define SRST_DP_CORE			253
+#define SRST_DP_I2S			254
+#define SRST_DP_VIF			255
+
+/* cru_softrst_con16 */
+#define SRST_GASKET			256
+#define SRST_VIO_SGRF			257
+#define SRST_VIO_GRF			258
+#define SRST_DPTX_SPDIF_REC		259
+#define SRST_HDMI_CTRL			260
+#define SRST_HDCP_CTRL			261
+#define SRST_A_ISP0_NIU			262
+#define SRST_A_ISP1_NIU			263
+#define SRST_A_ISP0			264
+#define SRST_A_ISP1			265
+#define SRST_H_ISP0_NIU			266
+#define SRST_H_ISP1_NIU			267
+#define SRST_H_ISP0			268
+#define SRST_H_ISP1			269
+#define SRST_ISP0			270
+#define SRST_ISP1			271
+
+/* cru_softrst_con17 */
+#define SRST_A_VOP0_NIU			272
+#define SRST_A_VOP1_NIU			273
+#define SRST_A_VOP0			274
+#define SRST_A_VOP1			275
+#define SRST_H_VOP0_NIU			276
+#define SRST_H_VOP1_NIU			277
+#define SRST_H_VOP0			278
+#define SRST_H_VOP1			279
+#define SRST_D_VOP0			280
+#define SRST_D_VOP1			281
+#define SRST_VOP0_PWM			282
+#define SRST_VOP1_PWM			283
+#define SRST_P_EDP_NIU			284
+#define SRST_P_EDP_CTRL			285
+
+/* cru_softrst_con18 */
+#define SRST_A_GPU			288
+#define SRST_A_GPU_NIU			289
+#define SRST_A_GPU_GRF			290
+#define SRST_PVTM_GPU			291
+#define SRST_A_USB3_NIU			292
+#define SRST_A_USB3_OTG0		293
+#define SRST_A_USB3_OTG1		294
+#define SRST_A_USB3_GRF			295
+#define SRST_PMU			296
+#define SRST_PVTM_PMU			297
+
+/* cru_softrst_con19 */
+#define SRST_P_TIMER0_5			304
+#define SRST_TIMER0			305
+#define SRST_TIMER1			306
+#define SRST_TIMER2			307
+#define SRST_TIMER3			308
+#define SRST_TIMER4			309
+#define SRST_TIME5			310
+#define SRST_P_TIMER6_11		311
+#define SRST_TIMER6			312
+#define SRST_TIMER7			313
+#define SRST_TIMER8			314
+#define SRST_TIMER9			315
+#define SRST_TIMER10			316
+#define SRST_TIMER11			317
+#define SRST_P_INTR_ARB_PMU		318
+#define SRST_P_ALIVE_SGRF		319
+
+/* cru_softrst_con20 */
+#define SRST_P_GPIO2			320
+#define SRST_P_GPIO3			321
+#define SRST_P_GPIO4			322
+#define SRST_P_GRF			323
+#define SRST_P_ALIVE_NIU		324
+#define SRST_P_WDT0			325
+#define SRST_P_WDT1			326
+#define SRST_P_INTR_ARB 		327
+#define SRST_P_UPHY0_DPTX		328
+#define SRST_P_UPHY1_DPTX		329
+#define SRST_P_UPHY0_APB		330
+#define SRST_P_UPHY1_APB		331
+#define SRST_P_UPHY0_TCPHY		332
+#define SRST_P_UPHY1_TCPHY		333
+#define SRST_P_UPHY0_TCPDCTRL		334
+#define SRST_P_UPHY1_TCPDCTRL		335
+
+/* pmu soft-reset indices */
+
+/* pmu_cru_softrst_con0 */
+#define SRST_P_NIU			0
+#define SRST_P_INTMEN			1
+#define SRST_H_CM0S			2
+#define SRST_H_CM0S_NIU			3
+#define SRST_DBG_CM0S			4
+#define SRST_PO_CM0S			5
+#define SRST_P_SPI6			6
+#define SRST_SPI6			7
+#define SRST_P_TIMER_0_1		8
+#define SRST_P_TIMER_0			9
+#define SRST_P_TIMER_1			10
+#define SRST_P_UART4			11
+#define SRST_UART4			12
+#define SRST_P_WDT			13
+
+/* pmu_cru_softrst_con1 */
+#define SRST_P_I2C6			16
+#define SRST_P_I2C7			17
+#define SRST_P_I2C8			18
+#define SRST_P_MAILBOX			19
+#define SRST_P_RKPWM			20
+#define SRST_P_PMUGRF			21
+#define SRST_P_SGRF			22
+#define SRST_P_GPIO0			23
+#define SRST_P_GPIO1			24
+#define SRST_P_CRU			25
+#define SRST_P_INTR			26
+#define SRST_PVTM 			27
+#define SRST_I2C6			28
+#define SRST_I2C7			29
+#define SRST_I2C8			30
+
+#endif
-- 
1.9.1




From jay.xu at rock-chips.com  Wed Feb 17 18:36:23 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Thu, 18 Feb 2016 10:36:23 +0800
Subject: [PATCH v2 4/4] ARM64: dts: rockchip: add core dtsi file for rk3399
In-Reply-To: <1455762983-29980-1-git-send-email-jay.xu@rock-chips.com>
References: <1455762983-29980-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455762983-29980-5-git-send-email-jay.xu@rock-chips.com>

From: Xu Jianqun <jay.xu at rock-chips.com>

Add dtsi file for Rockchip rk3399 SoCs with some
general nodes such as cpu, timer, cru, gic, amba.

Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v2:
- drop pmu and psci temporary (Mark)
- drop two applied patches (Heiko)
- drop GIC_CPU_MASK_SIMPLE from the interrupt specifiers (Marc, Heiko)
- drop clock-frequency of timer (Marc, Mark)

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 949 +++++++++++++++++++++++++++++++
 1 file changed, 949 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 0000000..00fb38a
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,949 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+#include <dt-bindings/clock/rk3399-cru.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+
+/ {
+	compatible = "rockchip,rk3399";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu_l0>;
+				};
+				core1 {
+					cpu = <&cpu_l1>;
+				};
+				core2 {
+					cpu = <&cpu_l2>;
+				};
+				core3 {
+					cpu = <&cpu_l3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu_b0>;
+				};
+				core1 {
+					cpu = <&cpu_b1>;
+				};
+			};
+		};
+
+		cpu_l0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x0>;
+		};
+
+		cpu_l1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x1>;
+		};
+
+		cpu_l2: cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x2>;
+		};
+
+		cpu_l3: cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x3>;
+		};
+
+		cpu_b0: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x0 0x100>;
+		};
+
+		cpu_b1: cpu at 101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x0 0x101>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	xin24m: xin24m {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24000000>;
+		clock-output-names = "xin24m";
+	};
+
+	gic: interrupt-controller at fee00000 {
+		compatible = "arm,gic-v3";
+		#interrupt-cells = <3>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		interrupt-controller;
+
+		reg = <0x0 0xfee00000 0 0x10000>, /* GICD */
+		      <0x0 0xfef00000 0 0xc0000>, /* GICR */
+		      <0x0 0xfff00000 0 0x10000>, /* GICC */
+		      <0x0 0xfff10000 0 0x10000>, /* GICH */
+		      <0x0 0xfff20000 0 0x10000>; /* GICV */
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH)>;
+		its: interrupt-controller at fee20000 {
+			compatible = "arm,gic-v3-its";
+			msi-controller;
+			reg = <0x0 0xfee20000 0x0 0x20000>;
+		};
+	};
+
+	amba {
+		compatible = "arm,amba-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		dmac_bus: dma-controller at ff6d0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x0 0xff6d0000 0x0 0x4000>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			clocks = <&cru ACLK_DMAC_BUS>;
+			clock-names = "apb_pclk";
+		};
+
+		dmac_peri: dma-controller at ff6e0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x0 0xff6e0000 0x0 0x4000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			clocks = <&cru ACLK_DMAC_PERI>;
+			clock-names = "apb_pclk";
+		};
+	};
+
+	uart0: serial at ff180000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff180000 0x0 0x100>;
+		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart1: serial at ff190000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff190000 0x0 0x100>;
+		clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart2: serial at ff1a0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff1a0000 0x0 0x100>;
+		clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart3: serial at ff1b0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff1b0000 0x0 0x100>;
+		clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	spi0: spi at ff1c0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff110000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI0>, <&cru PCLK_SPI0>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi0_clk &spi0_tx &spi0_rx &spi0_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi1: spi at ff1d0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff120000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI1>, <&cru PCLK_SPI1>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi1_clk &spi1_tx &spi1_rx &spi1_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi2: spi at ff1e0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff130000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI2>, <&cru PCLK_SPI2>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi2_clk &spi2_tx &spi2_rx &spi2_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi4: spi at ff1f0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff120000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI4>, <&cru PCLK_SPI4>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi4_clk &spi4_tx &spi4_rx &spi4_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi5: spi at ff200000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff130000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI5>, <&cru PCLK_SPI5>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi5_clk &spi5_tx &spi5_rx &spi5_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	pmugrf: syscon at ff320000 {
+		compatible = "rockchip,rk3399-pmugrf", "syscon";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+	};
+
+	spi3: spi at ff350000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff110000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI3>, <&cru PCLK_SPI3>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi3_clk &spi3_tx &spi3_rx &spi3_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	uart4: serial at ff370000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff370000 0x0 0x100>;
+		clocks = <&cru SCLK_UART4>, <&cru PCLK_UART4>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	pmucru: pmu-clock-controller at ff750000 {
+		compatible = "rockchip,rk3399-pmucru";
+		reg = <0x0 0xff750000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at ff760000 {
+		compatible = "rockchip,rk3399-cru";
+		reg = <0x0 0xff760000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	grf: syscon at ff770000 {
+		compatible = "rockchip,rk3399-grf", "syscon";
+		reg = <0x0 0xff770000 0x0 0x10000>;
+	};
+
+	i2s0: i2s at ff880000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff880000 0x0 0x1000>;
+		interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 0>, <&dmac_bus 1>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S0_8CH>, <&cru SCLK_I2S0_8CH>;
+		status = "disabled";
+	};
+
+	i2s1: i2s at ff890000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff890000 0x0 0x1000>;
+		interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 2>, <&dmac_bus 3>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S1_8CH>, <&cru SCLK_I2S1_8CH>;
+		status = "disabled";
+	};
+
+	i2s2: i2s at ff8a0000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff8a0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 4>, <&dmac_bus 5>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S2_8CH>, <&cru SCLK_I2S2_8CH>;
+		status = "disabled";
+	};
+
+	pinctrl: pinctrl {
+		compatible = "rockchip,rk3399-pinctrl";
+		rockchip,grf = <&grf>;
+		rockchip,pmu = <&pmugrf>;
+		#address-cells = <0x2>;
+		#size-cells = <0x2>;
+		ranges;
+
+		gpio0: gpio0 at ff720000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff720000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio1: gpio1 at ff730000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff730000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio2: gpio2 at ff780000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff780000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio3: gpio3 at ff788000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff788000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio4: gpio4 at ff790000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff790000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		pcfg_pull_up: pcfg-pull-up {
+			bias-pull-up;
+		};
+
+		pcfg_pull_down: pcfg-pull-down {
+			bias-pull-down;
+		};
+
+		pcfg_pull_none: pcfg-pull-none {
+			bias-disable;
+		};
+
+		pcfg_pull_none_12ma: pcfg-pull-none-12ma {
+			bias-disable;
+			drive-strength = <12>;
+		};
+
+		pcfg_pull_up_8ma: pcfg-pull-up-8ma {
+			bias-pull-up;
+			drive-strength = <8>;
+		};
+
+		pcfg_pull_down_4ma: pcfg-pull-down-4ma {
+			bias-pull-down;
+			drive-strength = <4>;
+		};
+
+		pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+			bias-pull-up;
+			drive-strength = <2>;
+		};
+
+		pcfg_pull_down_12ma: pcfg-pull-down-12ma {
+			bias-pull-down;
+			drive-strength = <12>;
+		};
+
+		emmc {
+			emmc_pwr: emmc-pwr {
+				rockchip,pins =
+					<0 5 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		gmac {
+			rgmii_pins: rgmii-pins {
+				rockchip,pins =
+					<3 11 RK_FUNC_1 &pcfg_pull_none>,
+					<3 13 RK_FUNC_1 &pcfg_pull_none>,
+					<3 8 RK_FUNC_1 &pcfg_pull_none>,
+					<3 4 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 5 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 0 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 1 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 17 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 12 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 6 RK_FUNC_1 &pcfg_pull_none>,
+					<3 7 RK_FUNC_1 &pcfg_pull_none>,
+					<3 2 RK_FUNC_1 &pcfg_pull_none>,
+					<3 3 RK_FUNC_1 &pcfg_pull_none>,
+					<3 14 RK_FUNC_1 &pcfg_pull_none>,
+					<3 9 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			rmii_pins: rmii-pins {
+				rockchip,pins =
+					<3 11 RK_FUNC_1 &pcfg_pull_none>,
+					<3 13 RK_FUNC_1 &pcfg_pull_none>,
+					<3 8 RK_FUNC_1 &pcfg_pull_none>,
+					<3 4 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 5 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 12 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 6 RK_FUNC_1 &pcfg_pull_none>,
+					<3 7 RK_FUNC_1 &pcfg_pull_none>,
+					<3 9 RK_FUNC_1 &pcfg_pull_none>,
+					<3 10 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c0 {
+			i2c0_xfer: i2c0-xfer {
+				rockchip,pins =
+					<1 15 RK_FUNC_2 &pcfg_pull_none>,
+					<1 16 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c1 {
+			i2c1_xfer: i2c1-xfer {
+				rockchip,pins =
+					<4 2 RK_FUNC_1 &pcfg_pull_none>,
+					<4 1 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c2 {
+			i2c2_xfer: i2c2-xfer {
+				rockchip,pins =
+					<2 1 RK_FUNC_2 &pcfg_pull_none_12ma>,
+					<2 0 RK_FUNC_2 &pcfg_pull_none_12ma>;
+			};
+		};
+
+		i2c3 {
+			i2c3_xfer: i2c3-xfer {
+				rockchip,pins =
+					<4 17 RK_FUNC_1 &pcfg_pull_none>,
+					<4 16 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c4 {
+			i2c4_xfer: i2c4-xfer {
+				rockchip,pins =
+					<1 12 RK_FUNC_1 &pcfg_pull_none>,
+					<1 11 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c5 {
+			i2c5_xfer: i2c5-xfer {
+				rockchip,pins =
+					<3 11 RK_FUNC_2 &pcfg_pull_none>,
+					<3 10 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c6 {
+			i2c6_xfer: i2c6-xfer {
+				rockchip,pins =
+					<2 10 RK_FUNC_2 &pcfg_pull_none>,
+					<2 9 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c7 {
+			i2c7_xfer: i2c7-xfer {
+				rockchip,pins =
+					<2 8 RK_FUNC_2 &pcfg_pull_none>,
+					<2 7 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c8 {
+			i2c8_xfer: i2c8-xfer {
+				rockchip,pins =
+					<1 21 RK_FUNC_1 &pcfg_pull_none>,
+					<1 20 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2s0 {
+			i2s0_8ch_bus: i2s0-8ch-bus {
+				rockchip,pins =
+					<3 24 RK_FUNC_1 &pcfg_pull_none>,
+					<3 25 RK_FUNC_1 &pcfg_pull_none>,
+					<3 26 RK_FUNC_1 &pcfg_pull_none>,
+					<3 27 RK_FUNC_1 &pcfg_pull_none>,
+					<3 28 RK_FUNC_1 &pcfg_pull_none>,
+					<3 29 RK_FUNC_1 &pcfg_pull_none>,
+					<3 30 RK_FUNC_1 &pcfg_pull_none>,
+					<3 31 RK_FUNC_1 &pcfg_pull_none>,
+					<4 0 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2s1 {
+			i2s1_2ch_bus: i2s1-2ch-bus {
+				rockchip,pins =
+					<4 3 RK_FUNC_1 &pcfg_pull_none>,
+					<4 4 RK_FUNC_1 &pcfg_pull_none>,
+					<4 5 RK_FUNC_1 &pcfg_pull_none>,
+					<4 6 RK_FUNC_1 &pcfg_pull_none>,
+					<4 7 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		sdio0 {
+			sdio0_bus1: sdio0-bus1 {
+				rockchip,pins =
+					<2 20 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_bus4: sdio0-bus4 {
+				rockchip,pins =
+					<2 20 RK_FUNC_1 &pcfg_pull_up>,
+					<2 21 RK_FUNC_1 &pcfg_pull_up>,
+					<2 22 RK_FUNC_1 &pcfg_pull_up>,
+					<2 23 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_cmd: sdio0-cmd {
+				rockchip,pins =
+					<2 24 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_clk: sdio0-clk {
+				rockchip,pins =
+					<2 25 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			sdio0_cd: sdio0-cd {
+				rockchip,pins =
+					<2 26 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_pwr: sdio0-pwr {
+				rockchip,pins =
+					<2 27 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_bkpwr: sdio0-bkpwr {
+				rockchip,pins =
+					<2 28 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_wp: sdio0-wp {
+				rockchip,pins =
+					<0 3 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_int: sdio0-int {
+				rockchip,pins =
+					<0 4 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		sdmmc {
+			sdmmc_bus1: sdmmc-bus1 {
+				rockchip,pins =
+					<4 8 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_bus4: sdmmc-bus4 {
+				rockchip,pins =
+					<4 8 RK_FUNC_1 &pcfg_pull_up>,
+					<4 9 RK_FUNC_1 &pcfg_pull_up>,
+					<4 10 RK_FUNC_1 &pcfg_pull_up>,
+					<4 11 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_clk: sdmmc-clk {
+				rockchip,pins =
+					<4 12 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			sdmmc_cmd: sdmmc-cmd {
+				rockchip,pins =
+					<4 13 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_cd: sdmcc-cd {
+				rockchip,pins =
+					<0 7 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_wp: sdmmc-wp {
+				rockchip,pins =
+					<0 8 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi0 {
+			spi0_clk: spi0-clk {
+				rockchip,pins =
+					<3 6 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_cs0: spi0-cs0 {
+				rockchip,pins =
+					<3 7 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_cs1: spi0-cs1 {
+				rockchip,pins =
+					<3 8 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_tx: spi0-tx {
+				rockchip,pins =
+					<3 5 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_rx: spi0-rx {
+				rockchip,pins =
+					<3 4 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi1 {
+			spi1_clk: spi1-clk {
+				rockchip,pins =
+					<1 9 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_cs0: spi1-cs0 {
+				rockchip,pins =
+					<1 10 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_rx: spi1-rx {
+				rockchip,pins =
+					<1 7 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_tx: spi1-tx {
+				rockchip,pins =
+					<1 8 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi2 {
+			spi2_clk: spi2-clk {
+				rockchip,pins =
+					<2 11 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_cs0: spi2-cs0 {
+				rockchip,pins =
+					<2 12 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_rx: spi2-rx {
+				rockchip,pins =
+					<2 9 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_tx: spi2-tx {
+				rockchip,pins =
+					<2 10 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi3 {
+			spi3_clk: spi3-clk {
+				rockchip,pins =
+					<1 17 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_cs0: spi3-cs0 {
+				rockchip,pins =
+					<1 18 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_rx: spi3-rx {
+				rockchip,pins =
+					<1 15 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_tx: spi3-tx {
+				rockchip,pins =
+					<1 16 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi4 {
+			spi4_clk: spi4-clk {
+				rockchip,pins =
+					<3 2 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_cs0: spi4-cs0 {
+				rockchip,pins =
+					<3 3 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_rx: spi4-rx {
+				rockchip,pins =
+					<3 0 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_tx: spi4-tx {
+				rockchip,pins =
+					<3 1 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi5 {
+			spi5_clk: spi5-clk {
+				rockchip,pins =
+					<2 22 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_cs0: spi5-cs0 {
+				rockchip,pins =
+					<2 23 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_rx: spi5-rx {
+				rockchip,pins =
+					<2 20 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_tx: spi5-tx {
+				rockchip,pins =
+					<2 21 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		uart0 {
+			uart0_xfer: uart0-xfer {
+				rockchip,pins =
+					<2 16 RK_FUNC_1 &pcfg_pull_up>,
+					<2 17 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			uart0_cts: uart0-cts {
+				rockchip,pins =
+					<2 18 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			uart0_rts: uart0-rts {
+				rockchip,pins =
+					<2 19 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uart1 {
+			uart1_xfer: uart1-xfer {
+				rockchip,pins =
+					<3 12 RK_FUNC_2 &pcfg_pull_up>,
+					<3 13 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2a {
+			uart2a_xfer: uart2a-xfer {
+				rockchip,pins =
+					<4 8 RK_FUNC_2 &pcfg_pull_up>,
+					<4 9 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2b {
+			uart2b_xfer: uart2b-xfer {
+				rockchip,pins =
+					<4 16 RK_FUNC_2 &pcfg_pull_up>,
+					<4 17 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2c {
+			uart2c_xfer: uart2c-xfer {
+				rockchip,pins =
+					<4 19 RK_FUNC_1 &pcfg_pull_up>,
+					<4 20 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uart3 {
+			uart3_xfer: uart3-xfer {
+				rockchip,pins =
+					<3 14 RK_FUNC_2 &pcfg_pull_up>,
+					<3 15 RK_FUNC_2 &pcfg_pull_none>;
+			};
+
+			uart3_cts: uart3-cts {
+				rockchip,pins =
+					<3 18 RK_FUNC_2 &pcfg_pull_none>;
+			};
+
+			uart3_rts: uart3-rts {
+				rockchip,pins =
+					<3 19 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart4 {
+			uart4_xfer: uart4-xfer {
+				rockchip,pins =
+					<1 7 RK_FUNC_1 &pcfg_pull_up>,
+					<1 8 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uarthdcp {
+			uarthdcp_xfer: uarthdcp-xfer {
+				rockchip,pins =
+					<4 21 RK_FUNC_2 &pcfg_pull_up>,
+					<4 22 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		pwm0 {
+			pwm0_pin: pwm0-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			vop0_pwm_pin: vop0-pwm-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		pwm1 {
+			pwm1_pin: pwm1-pin {
+				rockchip,pins =
+					<4 22 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			vop1_pwm_pin: vop1-pwm-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_3 &pcfg_pull_none>;
+			};
+		};
+	};
+};
-- 
1.9.1




From mark.yao at rock-chips.com  Wed Feb 17 18:54:02 2016
From: mark.yao at rock-chips.com (Mark yao)
Date: Thu, 18 Feb 2016 10:54:02 +0800
Subject: [PATCH v8.1 1/2] drm/rockchip: hdmi: add Innosilicon HDMI support
In-Reply-To: <3883951.Go5JsyhPRt@phil>
References: <1454049768-30872-1-git-send-email-ykk@rock-chips.com>
 <1454492697-7837-1-git-send-email-ykk@rock-chips.com>
 <3883951.Go5JsyhPRt@phil>
Message-ID: <56C5324A.5080009@rock-chips.com>

On 2016?02?18? 05:00, Heiko Stuebner wrote:
> Am Mittwoch, 3. Februar 2016, 17:44:57 schrieb Yakir Yang:
>> The Innosilicon HDMI is a low power HDMI 1.4 transmitter
>> IP, and it have been integrated on some rockchip CPUs
>> (like RK3036, RK312x).
>>
>> Signed-off-by: Yakir Yang <ykk at rock-chips.com>
> On a Kylin board against 4.5-rc
> Tested-by: Heiko Stuebner <heiko at sntech.de>

Good, Thanks your Tested-by.

> @Mark: While testing I noticed a black box around my cursor. It moves with
> the cursor, so seems to be the plane itself - the hdmi driver is of course
> innocent. May there exist an issue with plane transparency?

Oh, yes, it's my problem, forget to add transparency for rk3036 plane, I 
will do it later soon.

>
>
> Heiko
>
>
>

-- 
?ark Yao




From linux.amoon at gmail.com  Wed Feb 17 18:54:34 2016
From: linux.amoon at gmail.com (Anand Moon)
Date: Thu, 18 Feb 2016 08:24:34 +0530
Subject: [RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high
 load
In-Reply-To: <20160218023622.GA2610@vireshk-i7>
References: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
 <1455692128-28504-4-git-send-email-k.kozlowski@samsung.com>
 <CANAwSgQHiJGSYB7Qhq066Mqfskwrr_3SDQGXH-WN=Wt3SEF-QA@mail.gmail.com>
 <56C522A9.8070800@samsung.com> <20160218023622.GA2610@vireshk-i7>
Message-ID: <CANAwSgTGod7kR0fWMZuCFG9oAnt6CrUXsQs=JWz4LtqWi5P8Tw@mail.gmail.com>

Hi Viresh,

On 18 February 2016 at 08:06, Viresh Kumar <viresh.kumar at linaro.org> wrote:
> On 18-02-16, 10:47, Krzysztof Kozlowski wrote:
>> On 18.02.2016 04:53, Anand Moon wrote:
>> > I also got lot's of error.
>> >
>> > root at odroidxu4l:~# cpu[ 3050.847663] cpu cpu4: Failed to find dev_opp: -19
>> > [ 3171.640836] cpu cpu4: device_opp_debug_create_link: Failed to create link
>> > [ 3171.646197] cpu cpu4: _add_list_dev: Failed to register opp debugfs (-12)
>> > [ 3171.653574] cpu cpu7: device_opp_debug_create_link: Failed to create link
>> > [ 3171.659752] cpu cpu7: _add_list_dev: Failed to register opp debugfs (-12)
>> > [ 3171.697011] cpu cpu5: cpufreq_init: failed to get clk: -2
>> > [ 3171.732505] cpu cpu6: cpufreq_init: failed to get clk: -2
>> > [ 3171.768160] cpu cpu7: cpufreq_init: failed to get clk: -2
>> >
>> > Tested on Odroid-XU4
>> >
>> > Reviewed-by: Anand Moon <linux.amoon at gmail.com>
>> > Tested-by: Anand Moon <linux.amoon at gmail.com>
>
> What was this Tested-by supposed to mean? You got errors out there ...
>

I had done some stress testing, as pointed by Krzysztof.
I got myself in two minds on this part, please don't consider the
Tested-by and Reviewed-by part.
Thanks for pointing out.

-Anand  Moon

>> The patch is not sufficient. It does not work the way it should...
>>
>> BTW, I found the issue. The order of trip points in DT:
>> thermal_zone0/trip_point_0_hyst:5000
>> thermal_zone0/trip_point_0_temp:50000
>> thermal_zone0/trip_point_0_type:active
>> thermal_zone0/trip_point_1_hyst:5000
>> thermal_zone0/trip_point_1_temp:60000
>> thermal_zone0/trip_point_1_type:active
>> thermal_zone0/trip_point_2_hyst:5000
>> thermal_zone0/trip_point_2_temp:70000
>> thermal_zone0/trip_point_2_type:active
>> thermal_zone0/trip_point_3_hyst:0
>> thermal_zone0/trip_point_3_temp:120000        <---- this should be last one!
>> thermal_zone0/trip_point_3_type:critical
>> thermal_zone0/trip_point_4_hyst:5000
>> thermal_zone0/trip_point_4_temp:90000
>> thermal_zone0/trip_point_4_type:passive
>> thermal_zone0/trip_point_5_hyst:5000
>> thermal_zone0/trip_point_5_temp:110000
>> thermal_zone0/trip_point_5_type:passive
>>
>> After fixing the order in DT, the cpu cooler starts working.
>
> Ahh, nice.
>
> --
> viresh


From eric at anholt.net  Wed Feb 17 18:56:47 2016
From: eric at anholt.net (Eric Anholt)
Date: Wed, 17 Feb 2016 18:56:47 -0800
Subject: [GIT PULL 1/2] bcm2835 changes to defconfigs for 4.6
Message-ID: <1455764208-5679-1-git-send-email-eric@anholt.net>

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git at github.com:anholt/linux.git bcm2835-defconfig-next-2016-02-17

for you to fetch changes up to 0a05d3b71ada526ef93019fb3fbd6a95561a8a5f:

  ARM: multi_v7_defconfig: Enable BCM283x (2016-02-17 11:18:05 -0800)

----------------------------------------------------------------
This pull request brings in defconfig changes to enable bcm2836 in the
2835 and multi_v7 defconfigs.

----------------------------------------------------------------
Daniel Stone (1):
      ARM: multi_v7_defconfig: Enable BCM283x

Stefan Wahren (2):
      ARM: bcm2835_defconfig: Enable RPi firmware driver
      ARM: bcm2835_defconfig: Enable RPi power domain driver

Stephen Warren (3):
      ARM: bcm2835_defconfig: rebuild on next-20160205
      ARM: bcm2835_defconfig: disable DEBUG_LL
      ARM: bcm2835_defconfig: enable ARMv7 support

 arch/arm/configs/bcm2835_defconfig  | 11 +++++------
 arch/arm/configs/multi_v7_defconfig | 12 ++++++++++++
 2 files changed, 17 insertions(+), 6 deletions(-)


From eric at anholt.net  Wed Feb 17 18:56:48 2016
From: eric at anholt.net (Eric Anholt)
Date: Wed, 17 Feb 2016 18:56:48 -0800
Subject: [GIT PULL 2/2] bcm2835 changes to DT for 4.6
In-Reply-To: <1455764208-5679-1-git-send-email-eric@anholt.net>
References: <1455764208-5679-1-git-send-email-eric@anholt.net>
Message-ID: <1455764208-5679-2-git-send-email-eric@anholt.net>

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git at github.com:anholt/linux.git bcm2835-dt-next-2016-02-17

for you to fetch changes up to 1305141d1a7254b53b35303ee84f4c4948007bd0:

  ARM: bcm2835: add bcm2835-aux-uart support to DT (2016-02-17 11:01:00 -0800)

----------------------------------------------------------------
This pull request covers mostly DT changes that didn't make it into
4.5 because required header files went through other trees, plus the
AUX uart support this time around.

----------------------------------------------------------------
Alexander Aring (1):
      ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.

Lubomir Rintel (1):
      ARM: bcm2835: dt: Add Raspberry Pi Model A

Martin Sperl (3):
      ARM: bcm2835: add the auxiliary spi1 and spi2 to the device tree
      ARM: bcm2835: follow dt uart node-naming convention
      ARM: bcm2835: add bcm2835-aux-uart support to DT

Remi Pommarel (1):
      ARM: bcm2835: Add PWM clock support to the device tree

 arch/arm/boot/dts/Makefile          |  1 +
 arch/arm/boot/dts/bcm2835-rpi-a.dts | 24 +++++++++++++++++++++
 arch/arm/boot/dts/bcm2835-rpi.dtsi  | 16 ++++++++++++++
 arch/arm/boot/dts/bcm283x.dtsi      | 43 +++++++++++++++++++++++++++++++++++--
 4 files changed, 82 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/boot/dts/bcm2835-rpi-a.dts


From eric at anholt.net  Wed Feb 17 18:57:50 2016
From: eric at anholt.net (Eric Anholt)
Date: Wed, 17 Feb 2016 18:57:50 -0800
Subject: [GIT PULL] bcm2835 DT changes for 4.6
In-Reply-To: <56BEAA57.3050600@gmail.com>
References: <1454977978-17491-1-git-send-email-eric@anholt.net>
 <DDFB1D8B-805B-488F-9582-796EBCEF287B@sperl.org>
 <87d1s42yb8.fsf@eliezer.anholt.net> <56BD55A2.20104@gmail.com>
 <877fi92zxb.fsf@eliezer.anholt.net> <56BEAA57.3050600@gmail.com>
Message-ID: <87mvqyybbl.fsf@eliezer.anholt.net>

Florian Fainelli <f.fainelli at gmail.com> writes:

> On 12/02/2016 16:53, Eric Anholt wrote:
>> Florian Fainelli <f.fainelli at gmail.com> writes:
>> 
>>> On 10/02/2016 10:51, Eric Anholt wrote:
>>>> Martin Sperl <martin at sperl.org> writes:
>>>>
>>>>>> On 09.02.2016, at 01:32, Eric Anholt <eric at anholt.net> wrote:
>>>>>>
>>>>>> Hi Florian.  Here's the first set of patches for bcm2835 for 4.6.
>>>>>> We've got more DT patches that are going to happen for new boards,
>>>>>> too, but they're still getting polished.
>>>>>>
>>>>>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>>>>>
>>>>>>  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>>>>>
>>>>>> are available in the git repository at:
>>>>>>
>>>>>>  git at github.com:anholt/linux.git tags/bcm2835-dt-next-2016-02-04
>>>>>>
>>>>>> for you to fetch changes up to 5ec6f2cd8ec4bcd38ba199ea8711a5ec906d85e7:
>>>>>>
>>>>>>  ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT. (2016-02-02 20:02:45 -0800)
>>>>>>
>>>>>> ----------------------------------------------------------------
>>>>>> This pull request covers mostly DT changes that didn't make it into
>>>>>> 4.5 because required header files went through other trees.
>>>>>>
>>>>>> ----------------------------------------------------------------
>>>>>> Alexander Aring (1):
>>>>>>      ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
>>>>>>
>>>>>> Lubomir Rintel (1):
>>>>>>      ARM: bcm2835: dt: Add Raspberry Pi Model A
>>>>>>
>>>>>> Martin Sperl (2):
>>>>>>      ARM: bcm2835: add the auxiliary spi1 and spi2 to the device tree
>>>>>>      ARM: bcm2835: follow dt uart node-naming convention
>>>>>
>>>>> Do you want me to resend a rebased version of:
>>>>>      ARM: bcm2835: add bcm2835-aux-uart support to default DT
>>>>>
>>>>> The corresponding driver has been added to tty/tty-next.
>>>>
>>>> It hadn't landed last time I checked.  A rebased version that you've
>>>> tested would be great!
>>>
>>> OK, please submit this in the next week or so at most, so we can get
>>> this pull request merged, thanks!
>>>
>>> Eric, do you have other changes outside of Device Tree?
>> 
>> We've got bcm2835_defconfig changes that I need to test and tag.
>
> Ok, so that one needs to be a pull request.
>
>> 
>> There are also the multi_v7_defconfig updates to enable bcm2835.  Would
>> I be pulling those, or someone above me?
>
> This one could too, or it could be an individual patch that the arm-soc
> maintainers take directly, either way is fine AFAIR.

All right, I included it in my pull request.  Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/5b3c6d85/attachment.sig>

From eric at anholt.net  Wed Feb 17 18:58:10 2016
From: eric at anholt.net (Eric Anholt)
Date: Wed, 17 Feb 2016 18:58:10 -0800
Subject: [PATCH] ARM: bcm2835: add bcm2835-aux-uart support to DT
In-Reply-To: <1455275666-15806-1-git-send-email-kernel@martin.sperl.org>
References: <1455275666-15806-1-git-send-email-kernel@martin.sperl.org>
Message-ID: <87k2m2ybb1.fsf@eliezer.anholt.net>

kernel at martin.sperl.org writes:

> From: Martin Sperl <kernel at martin.sperl.org>
>
> Add bcm2835-aux-uart support to the device tree.
>
> Signed-off-by: Martin Sperl <kernel at martin.sperl.org>

Pulled to dt-next.  Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/e6800afa/attachment.sig>

From eric at anholt.net  Wed Feb 17 18:58:47 2016
From: eric at anholt.net (Eric Anholt)
Date: Wed, 17 Feb 2016 18:58:47 -0800
Subject: [PATCH 1/3] ARM: bcm2835_defconfig: rebuild on next-20160205
In-Reply-To: <1454781826-10571-1-git-send-email-swarren@wwwdotorg.org>
References: <1454781826-10571-1-git-send-email-swarren@wwwdotorg.org>
Message-ID: <87h9h6yba0.fsf@eliezer.anholt.net>

Stephen Warren <swarren at wwwdotorg.org> writes:

> This separates explicit changes desired in later patches from "automatic"
> or irrelevant changes caused solely by Kconfig changes.
>
> make ARCH=arm bcm2835_defconfig
> make ARCH=arm savedefconfig
> mv defconfig arch/arm/configs/bcm2835_defconfig
>
> Signed-off-by: Stephen Warren <swarren at wwwdotorg.org>

Pulled to -next (and thanks for the help with debugging the boot
troubles!)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/86bc8c7e/attachment.sig>

From eric at anholt.net  Wed Feb 17 18:58:59 2016
From: eric at anholt.net (Eric Anholt)
Date: Wed, 17 Feb 2016 18:58:59 -0800
Subject: [PATCH 0/2] ARM: bcm2835_defconfig: Enable RPi power domain driver
In-Reply-To: <1454796069-26830-1-git-send-email-stefan.wahren@i2se.com>
References: <1454796069-26830-1-git-send-email-stefan.wahren@i2se.com>
Message-ID: <87egcayb9o.fsf@eliezer.anholt.net>

Stefan Wahren <stefan.wahren at i2se.com> writes:

> This patch series allow us to enable power domains on the Raspberry Pi
> in the defconfig.
>
> This requires Stephen Warren's latest series ("ARM: bcm2835_defconfig:
> rebuild on next-20160205") applied first.

Pulled to -next.  Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/adb7e307/attachment-0001.sig>

From pi-cheng.chen at linaro.org  Wed Feb 17 19:00:49 2016
From: pi-cheng.chen at linaro.org (Pi-Cheng Chen)
Date: Thu, 18 Feb 2016 11:00:49 +0800
Subject: [RFC PATCH 4/5] PM / AVS: thermal: MT8173: Introduce support for
 SVS engine
In-Reply-To: <CAGS+omAYPhJ80kHG=bW4AjFsQzhwUfC6C+nAXa=Ny5UyoCid=w@mail.gmail.com>
References: <1453452029-20843-1-git-send-email-pi-cheng.chen@linaro.org>
 <1453452029-20843-5-git-send-email-pi-cheng.chen@linaro.org>
 <CAGS+omAYPhJ80kHG=bW4AjFsQzhwUfC6C+nAXa=Ny5UyoCid=w@mail.gmail.com>
Message-ID: <20160218030049.GA8780@gmail.com>

Hi Daniel,

Thanks for review.


On Fri, Jan 22, 2016 at 03:38:06PM -0800, Daniel Kurtz wrote:
> Hi Pi-Cheng,
> 
> Thanks for the patch!
> 
> Some review comments inline...
> 
> On Fri, Jan 22, 2016 at 12:40 AM, Pi-Cheng Chen
> <pi-cheng.chen at linaro.org> wrote:
> > The SVS (Smart Voltage Scaling) engine is a piece of hardware which is
> > used to caculate optimized voltage values of several power domains, e.g.
> 
> calculate
> 

Will fix it.

> > CPU clusters, according to chip process corner, temperatures, and other
> > factors. Then DVFS driver could apply those optimized voltage values to
> > reduce power consumption. This engine takes calibration data stored in
> > on-chip E-Fuse device as configuration input during initialization. Once
> > the initialization is done, SVS engine issues interrupts according to
> > temerature changes of power domains to notify DVFS driver to get
> 
> temperature
> 

Will fix it.

> > calculated voltage values.
> >
> > The configuration registers of SVS engine are shared with Mediatek
> > thermal controller, and those registers are banked for different power
> > domains. In addition, the SVS engine also needs some information from
> > Mediatek thermal controller, e.g. the temperature of a specific power
> > domain, part of the thermal calibration data. Therefore the support for
> > SVS engine is integrated with Mediatek thermal controller driver.
> >
> > Also, for platform specific requirement, to make SVS engine work
> > correctly, the initialization of SVS engine should be later then
> > Mediatek thermal controller, and prior to mt8173-cpufreq driver. Hence,
> > the platform device registration code of mt8173-cpufreq is removed here
> > after SVS initialization is done or skipped to ensure the platform
> > specific initialization flow.
> >
> > The functionality of SVS engine is optional for Mediatek thermal
> > controller. If the required resources of SVS engine is absent or SVS
> > failed during initialization stage, the SVS control flow will be
> > skipped and the thermal controller will function normally.
> >
> > CC: Stephen Boyd <sboyd at codeaurora.org>
> >
> > Signed-off-by: Pi-Cheng Chen <pi-cheng.chen at linaro.org>
> > ---
> > This patch relies on the runtime voltage adjustment of OPP introduced in CPR
> > patchset done by Stephen Boyd[1].
> >
> > [1] https://lkml.org/lkml/2015/9/18/833
> > ---
> >  drivers/thermal/mtk_thermal.c | 704 ++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 704 insertions(+)
> >
> > diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> > index f20e784..d8ba9dd 100644
> > --- a/drivers/thermal/mtk_thermal.c
> > +++ b/drivers/thermal/mtk_thermal.c
> > @@ -13,6 +13,9 @@
> >   */
> >
> >  #include <linux/clk.h>
> > +#include <linux/completion.h>
> > +#include <linux/cpu.h>
> > +#include <linux/cpufreq.h>
> >  #include <linux/delay.h>
> >  #include <linux/interrupt.h>
> >  #include <linux/kernel.h>
> > @@ -21,12 +24,15 @@
> >  #include <linux/of.h>
> >  #include <linux/of_address.h>
> >  #include <linux/platform_device.h>
> > +#include <linux/pm_opp.h>
> > +#include <linux/regulator/consumer.h>
> >  #include <linux/slab.h>
> >  #include <linux/io.h>
> >  #include <linux/thermal.h>
> >  #include <linux/reset.h>
> >  #include <linux/types.h>
> >  #include <linux/nvmem-consumer.h>
> > +#include <linux/workqueue.h>
> >
> >  /* AUXADC Registers */
> >  #define AUXADC_CON0_V          0x000
> > @@ -73,7 +79,32 @@
> >
> >  #define TEMP_SPARE0            0x0f0
> >
> > +#define SVS_BANK_CONFIG0       0x200
> > +#define SVS_BANK_CONFIG1       0x204
> > +#define SVS_BANK_CONFIG2       0x208
> > +#define SVS_BANK_CONFIG3       0x20c
> > +#define SVS_BANK_CONFIG4       0x210
> > +#define SVS_BANK_CONFIG5       0x214
> > +#define SVS_BANK_FREQPCT30     0x218
> > +#define SVS_BANK_FREQPCT74     0x21c
> > +#define SVS_BANK_LIMITVALS     0x220
> > +#define SVS_BANK_CONFIG6       0x224
> > +#define SVS_BANK_CONFIG7       0x228
> > +#define SVS_BANK_CONFIG8       0x22c
> > +#define SVS_BANK_CONFIG9       0x230
> > +#define SVS_BANK_CONFIG10      0x234
> > +#define SVS_BANK_EN            0x238
> > +#define SVS_BANK_CONTROL0      0x23c
> > +#define SVS_BANK_CONTROL1      0x240
> > +#define SVS_BANK_CONTROL2      0x244
> > +#define SVS_BANK_VOP30         0x248
> > +#define SVS_BANK_VOP74         0x24c
> > +#define SVS_BANK_INTST         0x254
> > +#define SVS_BANK_CONTROL3      0x25c
> > +#define SVS_BANK_CONTROL4      0x264
> > +
> >  #define PTPCORESEL             0x400
> > +#define SVS_SVSINTST           0x408
> >
> >  #define TEMP_MONCTL1_PERIOD_UNIT(x)    ((x) & 0x3ff)
> >
> > @@ -106,6 +137,24 @@
> >  /* The number of sensing points per bank */
> >  #define MT8173_NUM_SENSORS_PER_ZONE    4
> >
> > +/* The number of OPPs supported by SVS */
> > +#define MT8173_NUM_SVS_OPP             8
> > +
> > +/* Bit masks of SVS enable and IRQ configrations */
> > +#define PHASE_EN_MASK          0x7
> > +#define PHASE_0_EN             0x1
> > +#define PHASE_CON_EN           0x2
> > +#define PHASE_1_EN             0x4
> > +#define PHASE_01_EN            (PHASE_0_EN | PHASE_1_EN)
> > +#define PHASE_01_IRQ           0x1
> > +#define PHASE_CON_IRQ          (0xff << 16)
> > +
> > +/* The number of SVS banks implemented */
> > +#define MT8173_NUM_SVS_BANKS   2
> > +
> > +#define MT8173_SVS_BANK_CA53   0
> > +#define MT8173_SVS_BANK_CA72   1
> > +
> >  /* Layout of the fuses providing the calibration data */
> >  #define MT8173_CALIB_BUF0_VALID                (1 << 0)
> >  #define MT8173_CALIB_BUF1_ADC_GE(x)    (((x) >> 22 ) & 0x3ff)
> > @@ -116,6 +165,22 @@
> >  #define MT8173_CALIB_BUF2_VTS_TSABB(x) (((x) >> 14 ) & 0x1ff)
> >  #define MT8173_CALIB_BUF0_DEGC_CALI(x) (((x) >> 1 ) & 0x3f)
> >  #define MT8173_CALIB_BUF0_O_SLOPE(x)   (((x) >> 26 ) & 0x3f)
> > +#define MT8173_CALIB_BUF0_O_SLOPE_S(x) (((x) >> 7) & 0x1)
> > +
> > +/* Helpers to calculate configuration values from SVS calibration data */
> > +#define SVS_CALIB_VALID        (1)
> > +#define BANK_SHIFT(bank) ((bank == 0) ? 8 : 0)
> > +#define SVS_CALIB_BANK_CONFIG0(buf, s)                         \
> > +       (((((buf[33] >> (s)) & 0xff)) << 8) |                   \
> > +       ((buf[32] >> (s)) & 0xff))
> 
> Align opening parentheses.
> 

Will fix it.

> > +#define SVS_CALIB_BANK_CONFIG1(buf, s)                         \
> > +       ((((buf[34] >> (s)) & 0xff) << 8) | 0x100006)
> > +#define SVS_CALIB_BANK_CONFIG2L(base, s)                       \
> > +       ((buf[0] >> (s)) & 0xff)
> > +#define SVS_CALIB_BANK_CONFIG2H(base, s)                       \
> > +       ((buf[1] >> (s)) & 0xff)
> > +#define SVS_CALIB_BANK_CONFIG3(base, s)                                \
> > +       (((buf[2] >> (s)) & 0xff) << 8)
> >
> >  #define THERMAL_NAME    "mtk-thermal"
> >
> > @@ -126,14 +191,55 @@ struct mtk_thermal_bank {
> >         int id;
> >  };
> >
> > +enum svs_state {
> > +       SVS_PHASE_0 = 0,
> > +       SVS_PHASE_1,
> > +       SVS_PHASE_CONTINUOUS,
> > +};
> > +
> > +struct mtk_svs_bank {
> > +       int bank_id;
> > +       struct mtk_thermal *mt;
> > +       struct completion init_done;
> > +       struct work_struct work;
> > +
> > +       struct device *dev;
> > +       struct regulator *reg;
> > +
> > +       /* SVS per-bank calibration values */
> > +       u32 ctrl0;
> > +       u32 config0;
> > +       u32 config1;
> > +       u32 config2;
> > +       u32 config3;
> > +
> > +       unsigned long freq_table[MT8173_NUM_SVS_OPP];
> > +       int volt_table[MT8173_NUM_SVS_OPP];
> > +       int updated_volt_table[MT8173_NUM_SVS_OPP];
> > +};
> > +
> > +struct mtk_svs_bank_cfg {
> > +       const int dev_id;
> > +       const int ts;
> > +       const int vmin;
> > +       const int vmax;
> > +       const int vboot;
> > +       const unsigned long base_freq;
> > +};
> > +
> >  struct mtk_thermal {
> >         struct device *dev;
> >         void __iomem *thermal_base;
> >
> >         struct clk *clk_peri_therm;
> >         struct clk *clk_auxadc;
> > +       struct clk *svs_mux;
> > +       struct clk *svs_pll;
> >
> >         struct mtk_thermal_bank banks[MT8173_NUM_ZONES];
> > +       struct mtk_svs_bank svs_banks[MT8173_NUM_SVS_BANKS];
> > +
> > +       int svs_irq;
> >
> >         spinlock_t lock;
> >
> > @@ -142,6 +248,9 @@ struct mtk_thermal {
> >         s32 degc_cali;
> >         s32 o_slope;
> >         s32 vts[MT8173_NUM_SENSORS];
> > +       s32 x_roomt[MT8173_NUM_SENSORS];
> 
> AFAICT, this x_roomt isn't used.
> 

Will remove it.

> > +       s32 bts[MT8173_NUM_ZONES];
> > +       s32 mts;
> 
> What are "bts" and "mts".
> Please use more descriptive names, or at least a comment.
> 

Both these values are used to calculate temperature of blocks inside SoC by SVS
hardware:

Block Temperature = MTS * Juntion ADC value + BTS

I will add comments for them.

> >
> >         struct thermal_zone_device *tzd;
> >  };
> > @@ -198,6 +307,25 @@ static const struct mtk_thermal_sense_point
> >         },
> >  };
> >
> > +static const struct mtk_svs_bank_cfg svs_bank_cfgs[MT8173_NUM_SVS_BANKS] = {
> > +       [MT8173_SVS_BANK_CA53] = {
> > +               .dev_id = 0,
> > +               .vmax = 1125,
> > +               .vmin = 800,
> > +               .vboot = 1000,
> > +               .base_freq = 1600000,
> > +               .ts = MT8173_TS3
> > +       },
> > +       [MT8173_SVS_BANK_CA72] = {
> > +               .dev_id = 2,
> > +               .vmax = 1125,
> > +               .vmin = 800,
> > +               .vboot = 1000,
> > +               .base_freq = 2000000,
> > +               .ts = MT8173_TS4
> > +       }
> > +};
> > +
> >  /**
> >   * raw_to_mcelsius - convert a raw ADC value to mcelsius
> >   * @mt:                The thermal controller
> > @@ -222,6 +350,34 @@ static int raw_to_mcelsius(struct mtk_thermal *mt, int sensno, s32 raw)
> >  }
> >
> >  /**
> > + * mvolt_to_config - convert a voltage value to SVS voltage config value
> > + * @mvolt:     voltage value
> > + */
> > +static inline u32 mvolt_to_config(int mvolt)
> > +{
> > +       return ((mvolt - 700) * 100 + 625 - 1) / 625;
> > +}
> > +
> > +/**
> > + * mvolt_to_config - convert a SVS voltage config value to voltage value
> > + * @val:       SVS voltage config value
> > + */
> > +static inline int config_to_mv(u32 val)
> > +{
> > +       return (val * 625 / 100) + 700;
> > +}
> > +
> > +/**
> > + * khz_to_config - convert a frequency value to SVS frequency config value
> > + * @rate:      frequency value
> > + * @base_rate: rate to be used to calculate frequency percentage
> > + */
> > +static inline int khz_to_config(unsigned long rate, unsigned long base_rate)
> > +{
> > +       return (rate * 100 + base_rate - 1) / base_rate;
> > +}
> > +
> > +/**
> >   * mtk_thermal_switch_bank - switch to bank
> >   * @bank:      The bank
> >   *
> > @@ -240,6 +396,46 @@ static void mtk_thermal_switch_bank(struct mtk_thermal_bank *bank)
> >  }
> >
> >  /**
> > + * mtk_svs_update_voltage_table - update the calculated voltage table
> > + * @svs: The SVS bank
> > + * @offset: The voltage offset
> > + *
> > + * Read the calculated voltage values from registers and update the SVS bank
> > + * voltage table which will be write to OPP table entries later. Caller should
> > + * select the bank and hold mt->lock before calling it.
> > + */
> > +static void mtk_svs_update_voltage_table(struct mtk_svs_bank *svs, int offset)
> > +{
> > +       struct mtk_thermal *mt = svs->mt;
> > +       int vmin, vmax, *volt_table;
> > +       u32 reg;
> > +
> > +       vmin = svs_bank_cfgs[svs->bank_id].vmin;
> > +       vmax = svs_bank_cfgs[svs->bank_id].vmax;
> > +       volt_table = svs->updated_volt_table;
> > +
> > +       reg = readl(mt->thermal_base + SVS_BANK_VOP30);
> 
> Please add a comment explaining what are these two registers.
> 

These two registers report the updated voltage values caculated by SVS hardware.
SVS_BANK_VOP30 reports updated values for OPP[0:3] while SVS_BANK_VOP74 for
OPP[4:7]
I will add comments.

> > +       volt_table[0] = clamp(config_to_mv((reg & 0xff) + offset),
> > +                             vmin, vmax);
> > +       volt_table[1] = clamp(config_to_mv(((reg >> 8) & 0xff) + offset),
> > +                             vmin, vmax);
> > +       volt_table[2] = clamp(config_to_mv(((reg >> 16) & 0xff) + offset),
> > +                             vmin, vmax);
> > +       volt_table[3] = clamp(config_to_mv(((reg >> 24) & 0xff) + offset),
> > +                             vmin, vmax);
> > +
> > +       reg = readl(mt->thermal_base + SVS_BANK_VOP74);
> > +       volt_table[4] = clamp(config_to_mv((reg & 0xff) + offset),
> > +                             vmin, vmax);
> > +       volt_table[5] = clamp(config_to_mv(((reg >> 8) & 0xff) + offset),
> > +                             vmin, vmax);
> > +       volt_table[6] = clamp(config_to_mv(((reg >> 16) & 0xff) + offset),
> > +                             vmin, vmax);
> > +       volt_table[7] = clamp(config_to_mv(((reg >> 24) & 0xff) + offset),
> > +                             vmin, vmax);
> > +}
> > +
> > +/**
> >   * mtk_thermal_bank_temperature - get the temperature of a bank
> >   * @bank:      The bank
> >   *
> > @@ -426,6 +622,7 @@ static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_therm
> >         u32 *buf;
> >         size_t len;
> >         int i, ret = 0;
> > +       s32 o_slope_s, ge, oe, gain, x_roomt, temp1, temp2;
> >
> >         /* Start with default values */
> >         mt->adc_ge = 512;
> > @@ -433,6 +630,7 @@ static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_therm
> >                 mt->vts[i] = 260;
> >         mt->degc_cali = 40;
> >         mt->o_slope = 0;
> > +       o_slope_s = 0;
> >
> >         cell = nvmem_cell_get(dev, "calibration-data");
> >         if (IS_ERR(cell)) {
> > @@ -463,23 +661,464 @@ static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_therm
> >                 mt->vts[MT8173_TSABB] = MT8173_CALIB_BUF2_VTS_TSABB(buf[2]);
> >                 mt->degc_cali = MT8173_CALIB_BUF0_DEGC_CALI(buf[0]);
> >                 mt->o_slope = MT8173_CALIB_BUF0_O_SLOPE(buf[0]);
> > +               o_slope_s = MT8173_CALIB_BUF0_O_SLOPE_S(buf[0]);
> 
> Perhaps just do this once, here:
>   o_slope_s = MT8173_CALIB_BUF0_O_SLOPE_S(buf[0]);
>   mt->o_slope = (o_slope ? -1 : 1) * MT8173_CALIB_BUF0_O_SLOPE(buf[0]);
> 
> Don't we need to consider the slope's sign in raw_to_mcelsius(), too?
> 

Not sure about it.

@Dawei,
Would you please comment it?

> >         } else {
> >                 dev_info(dev, "Device not calibrated, using default calibration values\n");
> >         }
> >
> > +       oe = mt->adc_ge - 512;
> > +       ge = oe * 10000 / 4096;
> > +       gain = 10000 + ge;
> > +
> > +       /* calculating MTS */
> > +       mt->mts = (o_slope_s == 0) ?
> > +                 10000 * 100000 / gain * 15 / 18 / (165 + mt->o_slope) :
> > +                 10000 * 100000 / gain * 15 / 18 / (165 - mt->o_slope);
> 
> What are all of these magic numbers?
> Please define some named constants.
> 

Will do it.

> > +
> > +       /* calculating per-bank BTS */
> > +       for (i = 0; i < MT8173_NUM_SVS_BANKS; i++) {
> > +               int ts = svs_bank_cfgs[i].ts;
> > +
> > +               x_roomt = mt->vts[ts] + 3350 - oe * 10000 / 4096 * 10000 / gain;
> > +               temp1 = (10000 * 100000 / 4096 / gain) *
> > +                       ge + x_roomt * 10 * 15 / 18;
> > +               temp2 = (o_slope_s == 0) ? temp1 * 10 / (165 + mt->o_slope) :
> > +                       temp1 * 10 / (165 - mt->o_slope);
> > +               mt->bts[i] = (mt->degc_cali * 10 / 2 + temp2 - 250) * 4 / 10;
> 
> This math would be more clear if the temporary variables and constants
> had meaningful names.
> Also, if you really must do integer division, you probably want to use
> DIV_ROUND_UP().
> 

Will try to make this block more readable.

> > +       }
> > +
> >  out:
> >         kfree(buf);
> >
> >         return ret;
> >  }
> >
> > +static int mtk_svs_get_calibration_data(struct device *dev,
> > +                                       struct mtk_thermal *mt)
> > +{
> > +       struct nvmem_cell *cell;
> > +       u32 *buf;
> > +       size_t len;
> > +       int i, ret = 0;
> > +
> > +       cell = nvmem_cell_get(dev, "svs-calibration-data");
> > +       if (IS_ERR(cell))
> > +               return PTR_ERR(cell);
> > +
> > +       buf = (u32 *)nvmem_cell_read(cell, &len);
> 
> No need to explicitly cast from (void *) to (u32 *).
> 

Will remove the cast.

> > +       nvmem_cell_put(cell);
> > +
> > +       if (IS_ERR(buf)) {
> > +               dev_err(dev, "failed to get svs calibration data: %ld\n",
> > +                       PTR_ERR(buf));
> > +               return PTR_ERR(buf);
> > +       }
> > +
> > +       if (len < 0x8c || !(buf[29] & SVS_CALIB_VALID)) {
> > +               dev_err(dev, "Invalid SVS calibration data\n");
> > +               ret = -EINVAL;
> > +               goto out;
> > +       }
> > +
> > +       for (i = 0; i < MT8173_NUM_SVS_BANKS; i++) {
> > +               u32 temp;
> 
> Move the BANK_SHIFT(i) into SVS_CALIB_BANK_*() macros and the
> following will be more readable.
> 

Will do it.

> > +
> > +               mt->svs_banks[i].config0 =
> > +                               SVS_CALIB_BANK_CONFIG0(buf, BANK_SHIFT(i));
> > +               mt->svs_banks[i].config1 =
> > +                               SVS_CALIB_BANK_CONFIG1(buf, BANK_SHIFT(i));
> > +               mt->svs_banks[i].config3 =
> > +                               SVS_CALIB_BANK_CONFIG3(buf, BANK_SHIFT(i));
> > +
> 
> Add a comment here to explain what you are doing here for config2.
> 

This is a workaround to handle calibration value overflow. Another piece of
code to handle this should be in mtk_svs_set_phase() is missed. I will add it.

> > +               temp = SVS_CALIB_BANK_CONFIG2H(buf, BANK_SHIFT(i));
> > +               if (temp < 128 && i == MT8173_SVS_BANK_CA72)
> > +                       temp = (unsigned char)((temp - 256) / 2);
> > +               temp = ((temp & 0xff) << 8) |
> > +                      SVS_CALIB_BANK_CONFIG2L(buf, BANK_SHIFT(i));
> > +               mt->svs_banks[i].config2 = temp;
> > +       }
> > +
> > +out:
> > +       kfree(buf);
> > +
> > +       return ret;
> > +}
> > +
> > +/* Caller must call this function with mt->lock held */
> > +static void mtk_svs_set_phase(struct mtk_svs_bank *svs, int phase)
> > +{
> > +       struct mtk_thermal *mt = svs->mt;
> > +       unsigned long *freq_tbl, base_freq;
> > +       int id = svs->bank_id;
> > +
> > +       freq_tbl = svs->freq_table;
> > +       base_freq = svs_bank_cfgs[id].base_freq;
> > +
> > +       writel(svs->config0, mt->thermal_base + SVS_BANK_CONFIG0);
> > +       writel(svs->config1, mt->thermal_base + SVS_BANK_CONFIG1);
> > +       writel(svs->config2, mt->thermal_base + SVS_BANK_CONFIG2);
> > +       writel(svs->config3, mt->thermal_base + SVS_BANK_CONFIG3);
> > +       writel(0x555555, mt->thermal_base + SVS_BANK_CONFIG4);
> > +       writel(0x555555, mt->thermal_base + SVS_BANK_CONFIG5);
> > +       writel(0x80000000, mt->thermal_base + SVS_BANK_CONFIG10);
> 
> Define some named constants (macros) for these magic numbers.
> 

Will do it.

> > +
> > +       writel((khz_to_config(freq_tbl[0], base_freq) & 0xff) |
> 
> Just have khz_to_config return a u8 and remove the "& 0xff" here.
> 

Will do it.

> > +              ((khz_to_config(freq_tbl[1], base_freq) & 0xff) << 8) |
> > +              ((khz_to_config(freq_tbl[2], base_freq) & 0xff) << 16) |
> > +              ((khz_to_config(freq_tbl[3], base_freq) & 0xff) << 24),
> > +              mt->thermal_base + SVS_BANK_FREQPCT30);
> 
> Please add a comment here describing what these two registers are for.
> 

These two registers store the frequency percentage value of each OPP for SVS.

Frequency Percentage = Frequency / Max Frequency of this bank

Will add comments.

> > +
> > +       writel((khz_to_config(freq_tbl[4], base_freq) & 0xff) |
> > +              ((khz_to_config(freq_tbl[5], base_freq) & 0xff) << 8) |
> > +              ((khz_to_config(freq_tbl[6], base_freq) & 0xff) << 16) |
> > +              ((khz_to_config(freq_tbl[7], base_freq) & 0xff) << 24),
> > +              mt->thermal_base + SVS_BANK_FREQPCT74);
> > +
> 
> Same thing here for mvolt_to_config().
> 

Will do it.

> > +       writel(((mvolt_to_config(svs_bank_cfgs[id].vmax) & 0xff) << 24) |
> > +              ((mvolt_to_config(svs_bank_cfgs[id].vmin) & 0xff) << 16) | 0x1fe,
> 
> Named constants here for 0x1fe and below...
> 

Will do it.

> > +              mt->thermal_base + SVS_BANK_LIMITVALS);
> > +
> > +       writel(mvolt_to_config(svs_bank_cfgs[id].vboot),
> > +              mt->thermal_base + SVS_BANK_CONFIG6);
> > +       writel(0xa28, mt->thermal_base + SVS_BANK_CONFIG7);
> > +       writel(0xffff, mt->thermal_base + SVS_BANK_CONFIG8);
> > +
> > +       /* clear all pending interrupt */
> > +       writel(0xffffffff, mt->thermal_base + SVS_BANK_INTST);
> 
> Why is this necessary?
> 

It's the program flow provided in house solution code.
I will check if we really need it or not.

> > +
> > +       switch (phase) {
> > +       case SVS_PHASE_0:
> > +               writel(0x5f01, mt->thermal_base + SVS_BANK_CONTROL3);
> > +               writel(PHASE_0_EN, mt->thermal_base + SVS_BANK_EN);
> > +               break;
> > +       case SVS_PHASE_1:
> > +               writel(0x5f01, mt->thermal_base + SVS_BANK_CONTROL3);
> > +               writel(svs->ctrl0, mt->thermal_base + SVS_BANK_CONTROL0);
> > +               writel(PHASE_0_EN | PHASE_1_EN,
> > +                      mt->thermal_base + SVS_BANK_EN);
> > +               break;
> > +       case SVS_PHASE_CONTINUOUS:
> > +               writel(((mt->bts[id] & 0xfff) << 12) | (mt->mts & 0xfff),
> > +                      mt->thermal_base + SVS_BANK_CONFIG9);
> > +               writel(0xff0000, mt->thermal_base + SVS_BANK_CONTROL3);
> > +               writel(PHASE_CON_EN, mt->thermal_base + SVS_BANK_EN);
> > +       }
> > +}
> > +
> > +static void mtk_svs_adjust_voltage(struct mtk_svs_bank *svs)
> > +{
> > +       int i;
> > +
> > +       for (i = 0; i < MT8173_NUM_SVS_OPP; i++) {
> > +               if (!svs->freq_table[i])
> > +                       continue;
> > +
> 
> Don't we need to grab some "whole table" lock before manipulating the
> OPP table entries?
> Otherwise, someone who is iterating over the entire table might see
> something unexpected.
> 

I think ne one else will access this table during this stage. It should be safe
to read it without locking.

> > +               dev_pm_opp_adjust_voltage(svs->dev, svs->freq_table[i] * 1000,
> > +                                         svs->updated_volt_table[i] * 1000);
> > +       }
> > +}
> > +
> > +static void adjust_voltage_work(struct work_struct *work)
> > +{
> > +       struct mtk_svs_bank *svs = container_of(work, struct mtk_svs_bank,
> > +                                               work);
> > +       struct mtk_thermal *mt = svs->mt;
> > +       unsigned long flags;
> > +       int temp, low_temp_offset = 0;
> > +
> > +       spin_lock_irqsave(&mt->lock, flags);
> > +       mtk_thermal_switch_bank(&mt->banks[svs->bank_id]);
> > +
> > +       temp = mtk_thermal_bank_temperature(&mt->banks[svs->bank_id]);
> > +
> > +       spin_unlock_irqrestore(&mt->lock, flags);
> > +
> > +       if (temp <= 33000)
> > +               low_temp_offset = 10;
> 
> Please define some named constants for this threshold temperature and
> the offset voltage.
> 

Will do it.

> > +
> > +       mtk_svs_update_voltage_table(svs, low_temp_offset);
> > +       mtk_svs_adjust_voltage(svs);
> > +}
> > +
> > +static void mtk_svs_bank_disable(struct mtk_svs_bank *svs)
> > +{
> > +       struct mtk_thermal *mt = svs->mt;
> > +       int i;
> > +
> > +       writel(0, mt->thermal_base + SVS_BANK_EN);
> > +       writel(0xffffff, mt->thermal_base + SVS_BANK_INTST);
> > +
> > +       for (i = 0; i < MT8173_NUM_SVS_OPP; i++) {
> > +               if (!svs->freq_table[i])
> > +                       continue;
> > +
> > +               svs->updated_volt_table[i] = svs->volt_table[i];
> > +       }
> > +}
> > +
> > +static irqreturn_t mtk_svs_interrupt(int irqno, void *dev_id)
> > +{
> > +       struct mtk_thermal *mt = dev_id;
> > +       unsigned long flags;
> > +       u32 svs_intst, bank_en, bank_intst;
> > +       int i;
> > +
> > +       spin_lock_irqsave(&mt->lock, flags);
> > +
> > +       svs_intst = readl(mt->thermal_base + SVS_SVSINTST);
> 
> Do you need to acknowledge/clear these interrupt status bits?
> 

It should be cleared after per-bank status are all cleared.

> > +       for (i = 0; i < MT8173_NUM_SVS_BANKS; i++) {
> > +               struct mtk_svs_bank *svs = &mt->svs_banks[i];
> > +
> > +               if ((svs_intst >> i) & 0x1)
> > +                       continue;
> > +
> > +               mtk_thermal_switch_bank(&mt->banks[i]);
> > +
> > +               bank_intst = readl(mt->thermal_base + SVS_BANK_INTST);
> > +               bank_en = readl(mt->thermal_base + SVS_BANK_EN);
> > +
> > +               if (bank_intst == PHASE_01_IRQ && /* phase 0 */
> > +                   (bank_en & PHASE_EN_MASK) == PHASE_0_EN) {
> > +                       u32 reg;
> > +
> > +                       reg = readl(mt->thermal_base + SVS_BANK_CONTROL1);
> > +                       svs->ctrl0 |= (~(reg & 0xffff) + 1) & 0xffff;
> > +                       reg =  readl(mt->thermal_base + SVS_BANK_CONTROL2);
> > +                       svs->ctrl0 |= (reg & 0xffff) << 16;
> > +
> > +                       writel(0, mt->thermal_base + SVS_BANK_EN);
> > +                       writel(PHASE_01_IRQ, mt->thermal_base + SVS_BANK_INTST);
> > +
> > +                       mtk_svs_set_phase(svs, SVS_PHASE_1);
> > +               } else if (bank_intst == PHASE_01_IRQ && /* phase 1 */
> > +                          (bank_en & PHASE_EN_MASK) == PHASE_01_EN) {
> > +                       /*
> > +                        * The cpufreq driver won't work during SVS
> > +                        * initialization stage, so it's safe to update OPP
> > +                        * table here since it won't trigger regulator
> > +                        * operation.
> > +                        */
> > +                       mtk_svs_update_voltage_table(svs, 0);
> 
> Shouldn't this pass in the current temperature to apply the "low
> temperature offset"?
> 

The temperature factor is not taken into consideration in this stage and is
only considered in "continuous phase". So no need to apply the low temperature
offset here.

> > +                       mtk_svs_adjust_voltage(svs);
> > +
> > +                       writel(0, mt->thermal_base + SVS_BANK_EN);
> > +                       writel(PHASE_01_IRQ, mt->thermal_base + SVS_BANK_INTST);
> > +
> > +                       complete(&svs->init_done);
> > +
> > +                       mtk_svs_set_phase(svs, SVS_PHASE_CONTINUOUS);
> > +               } else if (bank_intst && PHASE_CON_IRQ) { /* phase continuous*/
> 
> What triggers PHASE_CON_IRQ interrupts?
> 

After we do mtk_svs_set_phase(svs, SVS_PHASE_CONTINUOUS) above.

> > +                       /*
> > +                        * Schedule a work to update voltages of OPP table
> > +                        * entries.
> > +                        */
> > +                       schedule_work(&svs->work);
> > +
> > +                       writel(PHASE_CON_IRQ,
> > +                              mt->thermal_base + SVS_BANK_INTST);
> > +               } else {
> > +                       mtk_svs_bank_disable(svs);
> > +                       dev_err(mt->svs_banks[i].dev,
> > +                               "SVS engine internal error. disabled.\n");
> > +
> > +                       /*
> > +                        * Schedule a work to reset voltages of OPP table
> > +                        * entries.
> > +                        */
> > +                       schedule_work(&svs->work);
> 
> You'll want to return IRQ_NONE in this case to notify the spurious irq detector.
> 

Will do it.

> > +               }
> > +       }
> > +
> > +       spin_unlock_irqrestore(&mt->lock, flags);
> > +
> > +       return IRQ_HANDLED;
> > +}
> 
> Nothing in this interrupt handler looks very time critical.
> Can we use a threaded interrupt instead, and continue to use a mutex
> for mt->lock.
> We could also then just call adjust_voltage_work() directly rather
> than indirectly through the work.
> 

Yes. I will try it.

> > +
> > +static int mtk_svs_bank_init(struct mtk_svs_bank *svs)
> > +{
> > +       struct dev_pm_opp *opp;
> > +       cpumask_t cpus;
> > +       int ret = 0, count, i;
> > +       unsigned long rate;
> > +
> > +       init_completion(&svs->init_done);
> > +
> > +       INIT_WORK(&svs->work, adjust_voltage_work);
> > +
> > +       svs->dev = get_cpu_device(svs_bank_cfgs[svs->bank_id].dev_id);
> > +       if (!svs->dev) {
> > +               pr_err("failed to get cpu%d device\n",
> > +                      svs_bank_cfgs[svs->bank_id].dev_id);
> > +               return -ENODEV;
> > +       }
> > +
> > +       svs->reg = regulator_get_exclusive(svs->dev, "proc");
> > +       if (IS_ERR(svs->reg)) {
> > +               dev_err(svs->dev, "failed to get proc regulator\n");
> > +               return PTR_ERR(svs->reg);
> > +       }
> > +
> > +       ret = dev_pm_opp_of_get_sharing_cpus(svs->dev, &cpus);
> > +       if (ret) {
> > +               dev_err(svs->dev, "failed to get OPP-sharing information\n");
> > +               return ret;
> > +       }
> > +
> > +       ret = dev_pm_opp_of_cpumask_add_table(&cpus);
> > +       if (ret) {
> > +               dev_err(svs->dev, "no OPP table\n");
> > +               return ret;
> > +       }
> > +
> > +       rcu_read_lock();
> > +       count = dev_pm_opp_get_opp_count(svs->dev);
> > +       if (count > MT8173_NUM_SVS_OPP)
> > +               dev_warn(svs->dev, "%d OPP entries found.\n"
> > +                        "But only %d OPP entry supported.\n", count,
> > +                        MT8173_NUM_SVS_OPP);
> > +
> > +       for (i = 0, rate = (unsigned long)-1; i < MT8173_NUM_SVS_OPP &&
> > +            i < count; i++, rate--) {
> > +               opp = dev_pm_opp_find_freq_floor(svs->dev, &rate);
> > +               if (IS_ERR(opp)) {
> > +                       dev_err(svs->dev, "error opp entry!!\n");
> > +                       rcu_read_unlock();
> > +                       ret = PTR_ERR(opp);
> > +                       goto out;
> > +               }
> > +
> > +               svs->freq_table[i] = rate / 1000;
> > +               svs->volt_table[i] = dev_pm_opp_get_voltage(opp) / 1000;
> 
> Why / 1000?
> Just save the original values.  This will keep us from having to * 1000 later.
> 

Will do it.

> > +       }
> > +
> > +out:
> > +       rcu_read_unlock();
> > +       if (ret) {
> > +               regulator_put(svs->reg);
> > +               dev_pm_opp_of_cpumask_remove_table(&cpus);
> > +       }
> > +
> > +       return ret;
> > +}
> > +
> > +static void mtk_svs_release(struct mtk_thermal *mt)
> > +{
> > +       int i, ret;
> > +       cpumask_t cpus;
> > +
> > +       if (!IS_ERR(mt->svs_pll))
> > +               clk_put(mt->svs_pll);
> 
> devm_clk_put(), devm_free_irq() & devm_regulator_put in this function.
> 

Will do it.

> > +
> > +       if (!IS_ERR(mt->svs_mux))
> > +               clk_put(mt->svs_mux);
> > +
> > +       if (mt->svs_irq != -1)
> > +               free_irq(mt->svs_irq, mt);
> > +
> > +       for (i = 0; i < MT8173_NUM_SVS_BANKS; i++) {
> > +               struct mtk_svs_bank *svs = &mt->svs_banks[i];
> > +
> > +               ret = dev_pm_opp_of_get_sharing_cpus(svs->dev, &cpus);
> > +               if (!ret)
> > +                       dev_pm_opp_of_cpumask_remove_table(&cpus);
> > +
> > +               if (svs->reg)
> > +                       regulator_put(svs->reg);
> > +       }
> > +}
> > +
> > +static int mtk_svs_init(struct platform_device *pdev, struct mtk_thermal *mt)
> > +{
> > +       struct clk *parent;
> > +       int i, ret, vboot;
> > +       unsigned long flags, timeout;
> > +       struct mtk_svs_bank *svs;
> > +
> > +       parent = clk_get_parent(mt->svs_mux);
> > +       ret = clk_set_parent(mt->svs_mux, mt->svs_pll);
> > +       if (ret) {
> > +               dev_err(&pdev->dev,
> > +                       "failed to set svs_mux to svs_pll\n");
> > +               return ret;
> > +       }
> > +
> > +       for (i = 0; i < MT8173_NUM_SVS_BANKS; i++) {
> > +               svs = &mt->svs_banks[i];
> > +
> 
> Why do you do this boot voltage check?
> Doesn't this depend on the specific OPP used by firmware, which is
> outside the control of the kernel?
> 

If the boot voltages are not matched, the calibration environment of SVS also
differs. That will lead to wrong voltage values output by SVS. That also imply
the firmware needs to setup the correct OPP to make SVS work normally. Or we
need some mechanism to pause cpufreq governor and set to specific OPP.

> > +               vboot = regulator_get_voltage(svs->reg) / 1000;
> > +               if (mvolt_to_config(vboot) !=
> > +                   mvolt_to_config(svs_bank_cfgs[i].vboot)) {
> > +                       dev_err(svs->dev, "Vboot value mismatch!\n");
> > +                       ret = -EINVAL;
> > +                       break;
> > +               }
> > +
> > +               ret = regulator_set_mode(svs->reg, REGULATOR_MODE_FAST);
> > +               if (ret) {
> > +                       dev_err(svs->dev,
> > +                               "Failed to set regulator in PWM mode\n");
> > +                       ret = -EINVAL;
> > +                       break;
> > +               }
> 
> Shouldn't this be best effort?
> If we can't set the regulator to fast mode, can we continue anyway?
> 

AFAIK, we need to set the regulator to fast mode to get stable voltage as
possible. I am sure about the details.

@Henry,
Would you please comment it?

Thanks,
Pi-Cheng

> > +
> > +               spin_lock_irqsave(&mt->lock, flags);
> > +               mtk_thermal_switch_bank(&mt->banks[i]);
> > +
> > +               mtk_svs_set_phase(svs, SVS_PHASE_0);
> > +
> > +               spin_unlock_irqrestore(&mt->lock, flags);
> > +
> > +               timeout = wait_for_completion_timeout(&svs->init_done, HZ);
> > +               if (timeout == 0) {
> > +                       dev_err(svs->dev, "SVS initialization timeout.\n");
> > +                       ret = -EINVAL;
> > +                       goto err_bank_init;
> > +               }
> > +
> > +               ret = regulator_set_mode(svs->reg, REGULATOR_MODE_NORMAL);
> > +               if (ret)
> > +                       dev_err(svs->dev,
> > +                               "Failed to set regulator in normal mode\n");
> > +
> > +               regulator_put(svs->reg);
> > +               svs->reg = NULL;
> > +       }
> > +
> > +err_bank_init:
> > +
> > +       if (ret)
> > +               for (i = 0; i < MT8173_NUM_SVS_BANKS; i++) {
> > +                       svs = &mt->svs_banks[i];
> > +
> > +                       spin_lock_irqsave(&mt->lock, flags);
> > +                       mtk_thermal_switch_bank(&mt->banks[i]);
> > +
> > +                       mtk_svs_bank_disable(svs);
> > +
> > +                       spin_unlock_irqrestore(&mt->lock, flags);
> > +
> > +                       mtk_svs_adjust_voltage(svs);
> > +               }
> > +
> > +       ret = clk_set_parent(mt->svs_mux, parent);
> > +       if (ret) {
> > +               dev_err(&pdev->dev,
> > +                       "failed to set svs_mux to original parent\n");
> > +               return ret;
> > +       }
> > +
> > +       return ret;
> > +}
> > +
> >  static int mtk_thermal_probe(struct platform_device *pdev)
> >  {
> >         int ret, i;
> >         struct device_node *auxadc, *apmixedsys, *np = pdev->dev.of_node;
> >         struct mtk_thermal *mt;
> >         struct resource *res;
> > +       struct platform_device *pdev_ret;
> >         u64 auxadc_phys_base, apmixed_phys_base;
> > +       bool skip_svs_init = false;
> >
> >         mt = devm_kzalloc(&pdev->dev, sizeof(*mt), GFP_KERNEL);
> >         if (!mt)
> > @@ -493,6 +1132,23 @@ static int mtk_thermal_probe(struct platform_device *pdev)
> >         if (IS_ERR(mt->clk_auxadc))
> >                 return PTR_ERR(mt->clk_auxadc);
> >
> > +       /*
> > +        * These two clks are optional for mtk-thermal. If present, SVS engine
> > +        * will be activated.
> > +        */
> > +       mt->svs_pll = devm_clk_get(&pdev->dev, "svs_pll");
> > +       mt->svs_mux = devm_clk_get(&pdev->dev, "svs_mux");
> > +       if (IS_ERR(mt->svs_pll) || IS_ERR(mt->svs_mux))
> > +               skip_svs_init = true;
> > +
> > +       mt->svs_irq = platform_get_irq(pdev, 1);
> > +       ret = devm_request_irq(&pdev->dev, mt->svs_irq, mtk_svs_interrupt,
> > +                              IRQF_TRIGGER_LOW, "mtk-svs", mt);
> > +       if (ret) {
> > +               mt->svs_irq = -1;
> > +               skip_svs_init = true;
> > +       }
> > +
> >         res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >         mt->thermal_base = devm_ioremap_resource(&pdev->dev, res);
> >         if (IS_ERR(mt->thermal_base))
> > @@ -502,6 +1158,27 @@ static int mtk_thermal_probe(struct platform_device *pdev)
> >         if (ret)
> >                 return ret;
> >
> > +       ret = mtk_svs_get_calibration_data(&pdev->dev, mt);
> > +       if (ret == -EPROBE_DEFER)
> > +               return ret;
> > +       else if (ret)
> > +               skip_svs_init = true;
> > +
> > +       for (i = 0; i < MT8173_NUM_SVS_BANKS; i++) {
> > +               mt->svs_banks[i].bank_id = i;
> > +               mt->svs_banks[i].mt = mt;
> > +
> > +               ret = mtk_svs_bank_init(&mt->svs_banks[i]);
> > +               if (ret) {
> > +                       if (ret == -EPROBE_DEFER)
> > +                               return ret;
> > +
> > +                       dev_err(&pdev->dev,
> > +                               "failed to initialize mtk svs bank%d\n", i);
> > +                       skip_svs_init = true;
> > +               }
> > +       }
> > +
> >         spin_lock_init(&mt->lock);
> >
> >         mt->dev = &pdev->dev;
> > @@ -562,6 +1239,33 @@ static int mtk_thermal_probe(struct platform_device *pdev)
> >         if (IS_ERR(mt->tzd))
> >                 goto err_register;
> >
> > +       /*
> > +        * SVS engine needs to be initialized after mtk-thermal initialization
> > +        * is done and before the initialization of cpufreq driver.
> > +        */
> > +       if (!skip_svs_init) {
> > +               ret = mtk_svs_init(pdev, mt);
> > +               if (ret) {
> > +                       /* Keep running system with SVS engine disabled. */
> > +                       dev_err(&pdev->dev,
> > +                               "Failed to initialze MTK SVS engine\n");
> > +                       skip_svs_init = true;
> > +               }
> > +       }
> > +
> > +       /*
> > +        * Release all resources needed by SVS if not all required resources
> > +        * are present or SVS initialization failed.
> > +        */
> > +       if (skip_svs_init)
> > +               mtk_svs_release(mt);
> > +
> > +       pdev_ret = platform_device_register_simple("mt8173-cpufreq", -1,
> > +                                                  NULL, 0);
> > +       if (IS_ERR(pdev_ret))
> > +               dev_err(&pdev->dev,
> > +                       "failed to register mt8173-cpufreq device\n");
> > +
> >         return 0;
> >
> >  err_register:
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > Linux-mediatek mailing list
> > Linux-mediatek at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek


From davem at davemloft.net  Wed Feb 17 19:08:58 2016
From: davem at davemloft.net (David Miller)
Date: Wed, 17 Feb 2016 22:08:58 -0500 (EST)
Subject: [PATCH net-next v3 0/4] Add support for Classifier and RSS
In-Reply-To: <1455750042-1521-1-git-send-email-isubramanian@apm.com>
References: <1455750042-1521-1-git-send-email-isubramanian@apm.com>
Message-ID: <20160217.220858.1360154606807063304.davem@davemloft.net>

From: Iyappan Subramanian <isubramanian at apm.com>
Date: Wed, 17 Feb 2016 15:00:38 -0800

> This patch set enables,
> 
> (i) Classifier engine that is used for parsing
> through the packet and extracting a search string that is then used
> to search a database to find associative data.
> 
> (ii) Receive Side Scaling (RSS) that does dynamic load
> balancing of the CPUs by controlling the number of messages enqueued
> per CPU though the help of Toeplitz Hash function of 4-tuple of
> source TCP/UDP port, destination TCP/UDP port, source IPV4 address and
> destination IPV4 address.
> 
> (iii) Multi queue, to make advantage of RSS
 ...

Series applied, thanks.


From linux.amoon at gmail.com  Wed Feb 17 19:17:25 2016
From: linux.amoon at gmail.com (Anand Moon)
Date: Thu, 18 Feb 2016 08:47:25 +0530
Subject: [RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high
 load
In-Reply-To: <56C522A9.8070800@samsung.com>
References: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
 <1455692128-28504-4-git-send-email-k.kozlowski@samsung.com>
 <CANAwSgQHiJGSYB7Qhq066Mqfskwrr_3SDQGXH-WN=Wt3SEF-QA@mail.gmail.com>
 <56C522A9.8070800@samsung.com>
Message-ID: <CANAwSgSOZMxXGFLgu67dL7GVEFh6TEG1NrUviqRY2oAVt16-sg@mail.gmail.com>

Hi Krzysztof

On 18 February 2016 at 07:17, Krzysztof Kozlowski
<k.kozlowski at samsung.com> wrote:
> On 18.02.2016 04:53, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 17 February 2016 at 12:25, Krzysztof Kozlowski
>> <k.kozlowski at samsung.com> wrote:
>>> After adding cpufreq-dt support to Exynos542x, the Odroid XU3-Lite can
>>> be easily overheated when launching eight CPU-intensive tasks:
>>>         thermal thermal_zone3: critical temperature reached(121 C),shutting down
>>>
>>> This seems to be specific to Odroid XU3-Lite board which officially
>>> supports lower frequencies than regular XU3 or XU4. When working at
>>> maximum CPU speed (1800 MHz big and 1300 MHz LITTLE) in warmer place for
>>> longer time, the fan fails to cool down the board and it reaches
>>> critical temperature.
>>>
>>> Add CPU cooling to Exynos5422/5800 to fix this issue. When reaching 95
>>> degrees of Celsius, the board will slow down by 3 steps (around
>>> 1400/1000 MHz). When reaching 110 degrees of Celsius go to 600 MHz.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
>>> ---
>>>  arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 41 +++++++++++++++++++++++++++
>>>  1 file changed, 41 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>>> index 2b289d7c0d13..66073ce29aee 100644
>>> --- a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>>> @@ -34,6 +34,16 @@
>>>                                         hysteresis = <5000>; /* millicelsius */
>>>                                         type = "active";
>>>                                 };
>>> +                               cpu_alert3: cpu-alert-3 {
>>> +                                       temperature = <95000>; /* millicelsius */
>>> +                                       hysteresis = <5000>; /* millicelsius */
>>> +                                       type = "passive";
>>> +                               };
>>> +                               cpu_alert4: cpu-alert-4 {
>>> +                                       temperature = <110000>; /* millicelsius */
>>> +                                       hysteresis = <5000>; /* millicelsius */
>>> +                                       type = "passive";
>>> +                               };
>>>                                 cpu_crit0: cpu-crit-0 {
>>>                                         temperature = <120000>; /* millicelsius */
>>>                                         hysteresis = <0>; /* millicelsius */
>>> @@ -53,6 +63,37 @@
>>>                                      trip = <&cpu_alert2>;
>>>                                      cooling-device = <&fan0 2 3>;
>>>                                 };
>>> +
>>> +                               /*
>>> +                                * When reaching cpu_alert3, reduce CPU
>>> +                                * by 3 steps. On Exynos5422/5800 that would
>>> +                                * be: 1400 MHz and 1000 MHz.
>>> +                                */
>>> +                               map3 {
>>> +                                    trip = <&cpu_alert3>;
>>> +                                    cooling-device = <&cpu0 3 3>;
>>> +                               };
>>> +                               map4 {
>>> +                                    trip = <&cpu_alert3>;
>>> +                                    cooling-device = <&cpu4 3 3>;
>>> +                               };
>>> +
>>> +                               /*
>>> +                                * When reaching cpu_alert4, reduce CPU
>>> +                                * to 600 MHz (11 steps for big, 7 steps for
>>> +                                * LITTLE).
>>> +                                * Exynos5420 has less OPPs and reversed
>>> +                                * numbering of CPUs (big/LITTLE) so this
>>> +                                * would not match.
>>> +                                */
>>> +                               map5 {
>>> +                                    trip = <&cpu_alert4>;
>>> +                                    cooling-device = <&cpu0 7 7>;
>>> +                               };
>>> +                               map6 {
>>> +                                    trip = <&cpu_alert4>;
>>> +                                    cooling-device = <&cpu4 11 11>;
>>> +                               };
>>>                         };
>>>                 };
>>>         };
>>> --
>>> 2.5.0
>>>
>>
>> could you append this patch with following changes.
>
> Could you describe why?
>
>From the documentation.
Documentation/thermal/sysfs-api.txt

passive_delay: number of milliseconds to wait between polls when
performing passive cooling.
polling_delay: number of milliseconds to wait between polls when
checking  whether trip points have been crossed (0 for interrupt
driven systems).

Exynos driver is interrupt driven so please ignore.

Best Regards.
-Anand Moon

>> diff --git a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>> b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>> index 66073ce..4e72637 100644
>> --- a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
>> @@ -16,8 +16,8 @@
>>         thermal-zones {
>>                 cpu0_thermal: cpu0-thermal {
>>                         thermal-sensors = <&tmu_cpu0 0>;
>> -                       polling-delay-passive = <0>;
>> -                       polling-delay = <0>;
>> +                       polling-delay-passive = <250>; /* milliseconds */
>> +                       polling-delay = <500>; /* milliseconds */
>>                         trips {
>>                                 cpu_alert0: cpu-alert-0 {
>>                                         temperature = <50000>; /*
>> millicelsius */
>> ---
>> On running linaro pm-qa diagnostic tool
>> ----------------------------------------------------------
>>
>> thermal_01.28: checking 'thermal_zone2'/'trip_point_2_temp' ='110000'...    Ok
>> thermal_01.29: checking 'cdev0_trip_point' exists in
>> '/sys/devices/virtual/thermal/thermal_zone0'... Ok
>> thermal_01.30: checking 'thermal_zone0/cdev0_trip_point' valid binding...   Ok
>> thermal_01.31: checking 'cdev4_trip_point' exists in
>> '/sys/devices/virtual/thermal/thermal_zone0'... Ok
>> thermal_01.32: checking 'thermal_zone0/cdev4_trip_point' valid binding...   Err
>> thermal_01.33: checking 'cdev4_trip_point' exists in
>> '/sys/devices/virtual/thermal/thermal_zone0'... Ok
>> thermal_01.34: checking 'thermal_zone0/cdev4_trip_point' valid binding...   Err
>> thermal_01.35: checking 'cdev4_trip_point' exists in
>> '/sys/devices/virtual/thermal/thermal_zone0'... Ok
>> thermal_01.36: checking 'thermal_zone0/cdev4_trip_point' valid binding...   Err
>> thermal_01.37: checking 'cdev4_trip_point' exists in
>> '/sys/devices/virtual/thermal/thermal_zone0'... Ok
>> thermal_01.38: checking 'thermal_zone0/cdev4_trip_point' valid binding...   Err
>>
>> thermal_01: fail
>> -------------------------------------------------------
>> I also got lot's of error.
>>
>> root at odroidxu4l:~# cpu[ 3050.847663] cpu cpu4: Failed to find dev_opp: -19
>> [ 3171.640836] cpu cpu4: device_opp_debug_create_link: Failed to create link
>> [ 3171.646197] cpu cpu4: _add_list_dev: Failed to register opp debugfs (-12)
>> [ 3171.653574] cpu cpu7: device_opp_debug_create_link: Failed to create link
>> [ 3171.659752] cpu cpu7: _add_list_dev: Failed to register opp debugfs (-12)
>> [ 3171.697011] cpu cpu5: cpufreq_init: failed to get clk: -2
>> [ 3171.732505] cpu cpu6: cpufreq_init: failed to get clk: -2
>> [ 3171.768160] cpu cpu7: cpufreq_init: failed to get clk: -2
>>
>> Tested on Odroid-XU4
>>
>> Reviewed-by: Anand Moon <linux.amoon at gmail.com>
>> Tested-by: Anand Moon <linux.amoon at gmail.com>
>
> The patch is not sufficient. It does not work the way it should...
>
> BTW, I found the issue. The order of trip points in DT:
> thermal_zone0/trip_point_0_hyst:5000
> thermal_zone0/trip_point_0_temp:50000
> thermal_zone0/trip_point_0_type:active
> thermal_zone0/trip_point_1_hyst:5000
> thermal_zone0/trip_point_1_temp:60000
> thermal_zone0/trip_point_1_type:active
> thermal_zone0/trip_point_2_hyst:5000
> thermal_zone0/trip_point_2_temp:70000
> thermal_zone0/trip_point_2_type:active
> thermal_zone0/trip_point_3_hyst:0
> thermal_zone0/trip_point_3_temp:120000  <---- this should be last one!
> thermal_zone0/trip_point_3_type:critical
> thermal_zone0/trip_point_4_hyst:5000
> thermal_zone0/trip_point_4_temp:90000
> thermal_zone0/trip_point_4_type:passive
> thermal_zone0/trip_point_5_hyst:5000
> thermal_zone0/trip_point_5_temp:110000
> thermal_zone0/trip_point_5_type:passive
>
> After fixing the order in DT, the cpu cooler starts working.
>
> Best regards,
> Krzysztof
>


From eric at anholt.net  Wed Feb 17 19:24:49 2016
From: eric at anholt.net (Eric Anholt)
Date: Wed, 17 Feb 2016 19:24:49 -0800
Subject: [PATCH V2 6/8] dmaengine: bcm2835: move controlblock chain
 generation into separate method
In-Reply-To: <1452187987-2605-7-git-send-email-kernel@martin.sperl.org>
References: <1452187987-2605-1-git-send-email-kernel@martin.sperl.org>
 <1452187987-2605-7-git-send-email-kernel@martin.sperl.org>
Message-ID: <874md6ya2m.fsf@eliezer.anholt.net>

kernel at martin.sperl.org writes:

> From: Martin Sperl <kernel at martin.sperl.org>
>
> In preparation of adding slave_sg functionality this patch moves the
> generation/allocation of bcm2835_desc and the building of
> the corresponding DMA-control-block chain from bcm2835_dma_prep_dma_cyclic
> into the newly created method bcm2835_dma_create_cb_chain.
>
> This new code also takes the limits of LITE channels into account
> and splits the control-block transfers at the correct location.
>
> Tested Audio output with a Hifiberry I2S card.
>
> Signed-off-by: Martin Sperl <kernel at martin.sperl.org>
> ---
>  drivers/dma/bcm2835-dma.c |  288 ++++++++++++++++++++++++++++++---------------
>  1 file changed, 191 insertions(+), 97 deletions(-)
>
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index 43758ba..41a4f0b 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -90,12 +90,12 @@ struct bcm2835_desc {
>  	struct virt_dma_desc vd;
>  	enum dma_transfer_direction dir;
>
> -	struct bcm2835_cb_entry *cb_list;
> -
>  	unsigned int frames;
>  	size_t size;
>
>  	bool cyclic;
> +
> +	struct bcm2835_cb_entry cb_list[];
>  };
>
>  #define BCM2835_DMA_CS		0x00
> @@ -181,6 +181,22 @@ struct bcm2835_desc {
>  #define BCM2835_DMA_IRQ_SHARED		11
>  #define BCM2835_DMA_IRQ_ALL		12
>
> +/* the max dma length for different channels */
> +#define MAX_DMA_LEN SZ_1G
> +#define MAX_LITE_DMA_LEN (SZ_64K - 4)
> +
> +static inline bool bcm2835_dma_is_lite(struct bcm2835_chan *c)
> +{
> +	/* dma channels >= 7 are LITE channels */
> +	return (c->ch >= 7);
> +}

You can ask a channel if it's a LITE engine by checking if the DEBUG reg
has bit 28 set.  Then you don't need to have the software/DT guessing
about it.

However, I'm disappointed to see these changes for adding LITE support
included in the same commit as refactoring chain generation into a
separate function.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/2763337d/attachment.sig>

From davem at davemloft.net  Wed Feb 17 19:25:35 2016
From: davem at davemloft.net (David Miller)
Date: Wed, 17 Feb 2016 22:25:35 -0500 (EST)
Subject: [PATCH 0/3] net: thunderx: Miscellaneous fixes
In-Reply-To: <1455620391-31619-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1455620391-31619-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <20160217.222535.482298677796133147.davem@davemloft.net>

From: sunil.kovvuri at gmail.com
Date: Tue, 16 Feb 2016 16:29:48 +0530

> This patch series fixes couple of issues w.r.t multiqset mode
> and receive packet statastics.

Series applied, thanks.


From jszhang at marvell.com  Wed Feb 17 19:32:07 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Thu, 18 Feb 2016 11:32:07 +0800
Subject: [PATCH v2 1/8] arm64: Introduce Allwinner SoC config option
In-Reply-To: <1455709440-8668-2-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
 <1455709440-8668-2-git-send-email-andre.przywara@arm.com>
Message-ID: <20160218113207.5ffffee2@xhacker>

Dear Andre,

On Wed, 17 Feb 2016 11:43:53 +0000
Andre Przywara <andre.przywara at arm.com> wrote:

> To prepare for the Allwinner A64 SoC support, introduce a config
> option to allow compiling Allwinner (aka. sunxi) specific drivers
> for the arm64 architecture as well.
> This patch just defines the ARCH_SUNXI symbol to allow Allwinner
> specific drivers to be selected during kernel configuration.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  arch/arm64/Kconfig.platforms | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 8a09522..2f7f69b 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -1,5 +1,10 @@
>  menu "Platform selection"
>  
> +config ARCH_SUNXI

it's better to keep ARCH_YYZZ sorted in alphabetic order

Thanks,
Jisheng

> +	bool "Allwinner sunxi 64-bit SoC Family"
> +	help
> +	  This enables support for Allwinner sunxi based SoCs like the A64.
> +
>  config ARCH_BCM_IPROC
>  	bool "Broadcom iProc SoC Family"
>  	help



From lv.zheng at intel.com  Wed Feb 17 19:36:35 2016
From: lv.zheng at intel.com (Zheng, Lv)
Date: Thu, 18 Feb 2016 03:36:35 +0000
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <56C470C5.2080203@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
 <56C470C5.2080203@linaro.org>
Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>

Hi,

> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
> early_acpi_os_unmap_memory()
> 
> Hi Lv,
> 
> Thank you for review.
> 
> On 02/17/2016 05:51 AM, Zheng, Lv wrote:
> 
> [..]
> 
> >>> early_acpi_os_unmap_memory() is marked as __init because it calls
> >>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is not
> set.
> >>>
> >>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
> >>> so it is safe to call early_acpi_os_unmap_memory() from anywhere
> >>>
> >>> We need this function to be non-__init because we need access to
> >>> some tables at unpredictable time--it may be before or after
> >>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port Console
> >>> Redirection) table is needed each time a new console is registered.
> >>> It can be quite early (console_initcall) or when a module is inserted.
> >>> When this table accessed before acpi_gbl_permanent_mmap is set,
> >>> the pointer should be unmapped.  This is exactly what this function
> >>> does.
> >> [Lv Zheng]
> >> Why don't you use another API instead of early_acpi_os_unmap_memory()
> in
> >> case you want to unmap things in any cases.
> >> acpi_os_unmap_memory() should be the one to match this purpose.
> >> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
> 
> As far as I understand, there exist two steps in ACPI initialization:
> 
> 1. Before acpi_gbl_permanent_mmap is set, tables received with
> acpi_get_table_with_size()
>    are mapped by early_memremap().  If a subsystem gets such a pointer it
> should be unmapped.
> 
> 2  After acpi_gbl_permanent_mmap is set this pointer should not be unmapped
> at all.
> 
[Lv Zheng] 
This statement is wrong, this should be:
As long as there is a __reference__ to the mapped table, the pointer should not be unmapped.
In fact, we have a series to introduce acpi_put_table() to achieve this.
So your argument is wrong from very first point.

> That exactly what early_acpi_os_unmap_memory() does--it checks
> acpi_gbl_permanent_mmap.
> If I had used acpi_os_unmap_memory() after acpi_gbl_permanent_mmap had
> been set,
> it would have tried to free that pointer with an oops (actually, I checked that
> and got that oops).
> 
> So using acpi_os_unmap_memory() is not an option here, but
> early_acpi_os_unmap_memory()
> match perfectly.
[Lv Zheng] 
I don't think so.
For definition block tables, we know for sure there will always be references, until "Unload" opcode is invoked by the AML interpreter.
But for the data tables, OSPMs should use them in this way:
1. map the table
2. parse the table and convert it to OS specific structures
3. unmap the table
This helps to shrink virtual memory address space usages.

So from this point of view, all data tables should be unmapped right after being parsed.
Why do you need the map to be persistent in the kernel address space?
You can always map a small table, but what if the table size is very big?

> 
> >> And in fact early_acpi_os_unmap_memory() should be removed.
> 
> I don't think so -- I have explained why.  It does different thing.
> Probably it (and/or other functions in that api) should be renamed.
> 
[Lv Zheng] 
Just let me ask one more question.
eary_acpi_os_unmap_memory() is not used inside of ACPICA.
How ACPICA can work with just acpi_os_unmap_memory()?
You can check drivers/acpi/tbxxx.c.
Especially: acpi_tb_release_temp_table() and the code invoking it.

> > [Lv Zheng]
> > One more thing is:
> > If you can't switch your driver to use acpi_os_unmap_memory() instead of
> early_acpi_os_unmap_memory(),
> > then it implies that your driver does have a defect.
> 
> I still don't understand what defect, sorry.
[Lv Zheng] 
If you can't ensure this sequence for using the data tables:
1. map the table
2. parse the table and convert it to OS specific structure
3. unmap the table
It implies there is a bug in the driver or a bug in the ACPI subsystem core.

> 
> > There is an early bootup requirement in Linux.
> > Maps acquired during the early stage should be freed by the driver during the
> early stage.
> > And the driver should re-acquire the memory map after booting.
> 
> Exactly.  That's why I use early_acpi_os_unmap_memory().  The point is that
> that code can be
> called *before* acpi_gbl_permanent_mmap is set (at early initialization of for
> example 8250 console)
> or *after* acpi_gbl_permanent_mmap is set (at insertion of a module that
> registers a console),
> We just can not tell if the received table pointer should or sould not be freed
> with early_memunmap()
> (actually __acpi_unmap_table() or whatever) without checking
> acpi_gbl_permanent_mmap,
> but that's all too low level.
[Lv Zheng] 
The driver should make sure that:
Map/unmap is paired during early stage.
For late stage, it should be another pair of map/unmap.

> 
> Another option, as you describe, is to get this pointer early, don't free it
[Lv Zheng] 
I mean you should free it early.

> untill acpi_gbl_permanent_mmap is set, then free it (with
> early_acpi_os_unmap_memory(), that's
> ok because acpi_gbl_permanent_mmap is set in an init code), then get the
> persistent
> pointer to the table.  The problem with it is that we can not just watch
> acpi_gbl_permanent_mmap
> to catch this exact moment.  And also accessing acpi_gbl_permanent_mmap is
> not good as it probably is
> an implementation detail (i. e. too lowlevel) of the ACPI code.
> Or I probably miss what you are suggesting.
> 
[Lv Zheng] 
I mean, you should:
During early stage:
acpi_os_map_memory()
Parse the table.
acpi_os_unmap_memory().

> > This is because, during early bootup stage, there are only limited slots
> available for drivers to map memory.
> > So by changing __init to __ref here, you probably will hide many such defects.
> 
> What defects?  This funcions checks acpi_gbl_permanent_mmap.
> BTW, exactly the same thing is done in the beginning of
> acpi_os_unmap_memory() and than's ok,
> that function is __ref.
> 
> > And solving issues in this way doesn't seem to be an improvement.
> 
> Could you please tell me where I am wrong?  I still don't understand your point.
[Lv Zheng] 
But anyway, the defect should be in ACPI subsystem core.
The cause should be the API itself - acpi_get_table().

So I agree you can use early_acpi_os_unmap_memory() during the period the root causes are not cleaned up.
But the bottom line is: the driver need to ensure that early_acpi_os_unmap_memory() is always invoked.
As long as you can ensure this, I don't have objections for deploying early_acpi_os_unmap_memory()  for now.

Thanks and best regards
-Lv

> 
> Thank you
> Aleksey Makarov
> 
> >
> > Thanks and best regards
> > -Lv
> >
> >>
> >> Thanks and best regards
> >> -Lv
> >>
> >>>
> >>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> >>> ---
> >>>  drivers/acpi/osl.c | 6 +++++-
> >>>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> >>> index 67da6fb..8a552cd 100644
> >>> --- a/drivers/acpi/osl.c
> >>> +++ b/drivers/acpi/osl.c
> >>> @@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void *virt,
> >>> acpi_size size)
> >>>  }
> >>>  EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
> >>>
> >>> -void __init early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
> >> size)
> >>> +/*
> >>> + * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
> >>> + * so it is safe to call early_acpi_os_unmap_memory() from anywhere
> >>> + */
> >>> +void __ref early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
> >> size)
> >>>  {
> >>>  	if (!acpi_gbl_permanent_mmap)
> >>>  		__acpi_unmap_table(virt, size);
> >>> --
> >>> 2.7.1
> >>>
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> >>> the body of a message to majordomo at vger.kernel.org
> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> >> the body of a message to majordomo at vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From han.xu at nxp.com  Wed Feb 17 19:55:15 2016
From: han.xu at nxp.com (Han Xu)
Date: Thu, 18 Feb 2016 03:55:15 +0000
Subject: [PATCH] MAINTAINERS: add maintainer entry for FREESCALE GPMI NAND
 driver
Message-ID: <1455767715-621-1-git-send-email-han.xu@nxp.com>

Add a maintainer entry for FREESCALE GPMI NAND driver and add myself as a
maintainer.

Signed-off-by: Han Xu <han.xu at nxp.com>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7bd927e..49baa5b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4543,6 +4543,12 @@ L:	linuxppc-dev at lists.ozlabs.org
 S:	Maintained
 F:	drivers/dma/fsldma.*
 
+FREESCALE GPMI NAND DRIVER
+M:	Han Xu <han.xu at nxp.com>
+L:	linux-mtd at lists.infradead.org
+S:	Maintained
+F:	drivers/mtd/nand/gpmi-nand/*
+
 FREESCALE I2C CPM DRIVER
 M:	Jochen Friedrich <jochen at scram.de>
 L:	linuxppc-dev at lists.ozlabs.org
-- 
2.7.1



From eric at anholt.net  Wed Feb 17 20:09:23 2016
From: eric at anholt.net (Eric Anholt)
Date: Wed, 17 Feb 2016 20:09:23 -0800
Subject: [PATCH V2 3/8] dmaengine: bcm2835: use shared interrupt for
 channel 11 to 14.
In-Reply-To: <1452187987-2605-4-git-send-email-kernel@martin.sperl.org>
References: <1452187987-2605-1-git-send-email-kernel@martin.sperl.org>
 <1452187987-2605-4-git-send-email-kernel@martin.sperl.org>
Message-ID: <87ziuywtfw.fsf@eliezer.anholt.net>

kernel at martin.sperl.org writes:

> From: Martin Sperl <kernel at martin.sperl.org>
>
> The bcm2835 dma channel 11 to 14 only have a single shared irq line,
> so this patch implements shared interrupts for these channels.
>
> To avoid changes to the device tree (with regards to interrupts listed,
> which reflects on pdev->num_resources) a fixed channel count had
> to get used in the code instead.
>
> With this patch applied we now have 11 dma channels available to
> the ARM side of the SOC.
>
> Signed-off-by: Martin Sperl <kernel at martin.sperl.org>

Particularly given the existing DT bindings we have, I actually think
this is a good way to go.  This is internal to the hardware module about
how its features map to interrupt lines that leave the hardware module
(which are exposed in DT appropriately).

I thought about "what if we had the last interrupt line hooked up to a
different interrupt handler that read out and decided which channels to
wake up", but this seems much simpler.

Reviewed-by: Eric Anholt <eric at anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/ca03aa66/attachment.sig>

From eric at anholt.net  Wed Feb 17 20:18:24 2016
From: eric at anholt.net (Eric Anholt)
Date: Wed, 17 Feb 2016 20:18:24 -0800
Subject: [PATCH V2 4/8] dmaengine: bcm2835: add additional defines for
 DMA-registers
In-Reply-To: <1452187987-2605-5-git-send-email-kernel@martin.sperl.org>
References: <1452187987-2605-1-git-send-email-kernel@martin.sperl.org>
 <1452187987-2605-5-git-send-email-kernel@martin.sperl.org>
Message-ID: <87wpq2wt0v.fsf@eliezer.anholt.net>

kernel at martin.sperl.org writes:

> From: Martin Sperl <kernel at martin.sperl.org>
>
> Add additional defines describing the DMA registers
> as well as adding some more documentation to those registers.
>
> Signed-off-by: Martin Sperl <kernel at martin.sperl.org>
> ---
>  drivers/dma/bcm2835-dma.c |   54 ++++++++++++++++++++++++++++++++++++++-------
>  1 file changed, 46 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index 0c04236..7905327 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -99,26 +99,64 @@ struct bcm2835_desc {
>  
>  #define BCM2835_DMA_CS		0x00
>  #define BCM2835_DMA_ADDR	0x04
> +#define BCM2835_DMA_TI		0x08
>  #define BCM2835_DMA_SOURCE_AD	0x0c
>  #define BCM2835_DMA_DEST_AD	0x10
> -#define BCM2835_DMA_NEXTCB	0x1C
> +#define BCM2835_DMA_LEN		0x14
> +#define BCM2835_DMA_STIDE	0x18

s/STIDE/STRIDE/

With that fixed, and optionally Vinod's comment about reformatting the
comment changed,

Reviewed-by: Eric Anholt <eric at anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/6a256ca6/attachment.sig>

From eric at anholt.net  Wed Feb 17 20:19:09 2016
From: eric at anholt.net (Eric Anholt)
Date: Wed, 17 Feb 2016 20:19:09 -0800
Subject: [PATCH V2 5/8] dmaengine: bcm2835: move cyclic member from
 bcm2835_chan into bcm2835_desc
In-Reply-To: <1452187987-2605-6-git-send-email-kernel@martin.sperl.org>
References: <1452187987-2605-1-git-send-email-kernel@martin.sperl.org>
 <1452187987-2605-6-git-send-email-kernel@martin.sperl.org>
Message-ID: <87twl6wszm.fsf@eliezer.anholt.net>

kernel at martin.sperl.org writes:

> From: Martin Sperl <kernel at martin.sperl.org>
>
> In preparation to consolidating code we move the cyclic member
> into the bcm_2835_desc structure.

Reviewed-by: Eric Anholt <eric at anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/b9f7c7f9/attachment.sig>

From shijie.huang at arm.com  Wed Feb 17 20:36:13 2016
From: shijie.huang at arm.com (Huang Shijie)
Date: Thu, 18 Feb 2016 12:36:13 +0800
Subject: [PATCH] MAINTAINERS: add maintainer entry for FREESCALE GPMI
 NAND driver
In-Reply-To: <1455767715-621-1-git-send-email-han.xu@nxp.com>
References: <1455767715-621-1-git-send-email-han.xu@nxp.com>
Message-ID: <20160218043612.GA735@sha-win-210.asiapac.arm.com>

On Thu, Feb 18, 2016 at 03:55:15AM +0000, Han Xu wrote:
> Add a maintainer entry for FREESCALE GPMI NAND driver and add myself as a
> maintainer.
>
> Signed-off-by: Han Xu <han.xu at nxp.com>
> ---
>  MAINTAINERS | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7bd927e..49baa5b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4543,6 +4543,12 @@ L:     linuxppc-dev at lists.ozlabs.org
>  S:   Maintained
>  F:   drivers/dma/fsldma.*
>
> +FREESCALE GPMI NAND DRIVER
> +M:   Han Xu <han.xu at nxp.com>
> +L:   linux-mtd at lists.infradead.org
> +S:   Maintained
> +F:   drivers/mtd/nand/gpmi-nand/*
> +
>  FREESCALE I2C CPM DRIVER
>  M:   Jochen Friedrich <jochen at scram.de>
>  L:   linuxppc-dev at lists.ozlabs.org
> --
> 2.7.1
>
Acked-by: Huang Shijie <shijie.huang at arm.com>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.



From eric at anholt.net  Wed Feb 17 20:39:25 2016
From: eric at anholt.net (Eric Anholt)
Date: Wed, 17 Feb 2016 20:39:25 -0800
Subject: [PATCH V2 7/8] dmaengine: bcm2835: add slave_sg support to
 bcm2835-dma
In-Reply-To: <1452187987-2605-8-git-send-email-kernel@martin.sperl.org>
References: <1452187987-2605-1-git-send-email-kernel@martin.sperl.org>
 <1452187987-2605-8-git-send-email-kernel@martin.sperl.org>
Message-ID: <87oabews1u.fsf@eliezer.anholt.net>

kernel at martin.sperl.org writes:

> From: Martin Sperl <kernel at martin.sperl.org>
>
> Add slave_sg support to bcm2835-dma using shared allocation
> code for bcm2835_desc and DMA-control blocks already used by
> dma_cyclic.
>
> Note that bcm2835_dma_callback had to get modified to support
> both modes of operation (cyclic and non-cyclic).
>
> Tested using:
> * Hifiberry I2S card (using cyclic DMA)
> * fb_st7735r SPI-framebuffer (using slave_sg DMA via spi-bcm2835)
> playing BigBuckBunny for audio and video.
>
> Signed-off-by: Martin Sperl <kernel at martin.sperl.org>

I would have expected bcm2835_dma_create_cb_chain()'s changes to support
slave DMA to be in this patch rather than the refactor patch.  However,
the content of this one and 8/8 are:

Reviewed-by: Eric Anholt <eric at anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160217/9d8c8c3b/attachment.sig>

From k.kozlowski at samsung.com  Wed Feb 17 20:42:03 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Thu, 18 Feb 2016 13:42:03 +0900
Subject: [RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high
 load
In-Reply-To: <20160218023622.GA2610@vireshk-i7>
References: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
 <1455692128-28504-4-git-send-email-k.kozlowski@samsung.com>
 <CANAwSgQHiJGSYB7Qhq066Mqfskwrr_3SDQGXH-WN=Wt3SEF-QA@mail.gmail.com>
 <56C522A9.8070800@samsung.com> <20160218023622.GA2610@vireshk-i7>
Message-ID: <56C54B9B.7030105@samsung.com>

On 18.02.2016 11:36, Viresh Kumar wrote:
>>
>> BTW, I found the issue. The order of trip points in DT:
>> thermal_zone0/trip_point_0_hyst:5000
>> thermal_zone0/trip_point_0_temp:50000
>> thermal_zone0/trip_point_0_type:active
>> thermal_zone0/trip_point_1_hyst:5000
>> thermal_zone0/trip_point_1_temp:60000
>> thermal_zone0/trip_point_1_type:active
>> thermal_zone0/trip_point_2_hyst:5000
>> thermal_zone0/trip_point_2_temp:70000
>> thermal_zone0/trip_point_2_type:active
>> thermal_zone0/trip_point_3_hyst:0
>> thermal_zone0/trip_point_3_temp:120000	<---- this should be last one!
>> thermal_zone0/trip_point_3_type:critical
>> thermal_zone0/trip_point_4_hyst:5000
>> thermal_zone0/trip_point_4_temp:90000
>> thermal_zone0/trip_point_4_type:passive
>> thermal_zone0/trip_point_5_hyst:5000
>> thermal_zone0/trip_point_5_temp:110000
>> thermal_zone0/trip_point_5_type:passive
>>
>> After fixing the order in DT, the cpu cooler starts working.
> 
> Ahh, nice.

Damn, not entirely. I almost fried my Odroid (it survived 130 degrees of
C)... The TMU supports only 4 trip points, so when I added two new trip
points and reordered them... the last two (including critical) was not
receiving interrupts.

Polling mode is needed. I'll sent some patches soon...

BR,
Krzysztof



From davem at davemloft.net  Wed Feb 17 20:43:21 2016
From: davem at davemloft.net (David Miller)
Date: Wed, 17 Feb 2016 23:43:21 -0500 (EST)
Subject: [PATCH v2 net-next 6/8] net: mvneta: bm: add support for
 hardware buffer management
In-Reply-To: <1455636823-14470-7-git-send-email-gregory.clement@free-electrons.com>
References: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
 <1455636823-14470-7-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160217.234321.1202099534402079240.davem@davemloft.net>

From: Gregory CLEMENT <gregory.clement at free-electrons.com>
Date: Tue, 16 Feb 2016 16:33:41 +0100

>  	pp->dev = dev;
>  	SET_NETDEV_DEV(dev, &pdev->dev);
>  
> +	dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO;
> +	dev->hw_features |= dev->features;
> +	dev->vlan_features |= dev->features;
> +	dev->priv_flags |= IFF_UNICAST_FLT;
> +	dev->gso_max_segs = MVNETA_MAX_TSO_SEGS;
> +
> +	err = register_netdev(dev);
> +	if (err < 0) {
> +		dev_err(&pdev->dev, "failed to register\n");
> +		goto err_free_stats;
> +	}
> +
> +	pp->id = dev->ifindex;
> +
> +	/* Obtain access to BM resources if enabled and already initialized */
> +	bm_node = of_parse_phandle(dn, "buffer-manager", 0);
> +	if (bm_node && bm_node->data) {

This set of changes has a lot of problems.

First, the exact moment you call register_netdev() your device must be
fully initialized because ->open() can be invoked immediately.  This
means you must take care of all of this buffer manager stuff before
calling register_netdev().

It must precisely be the last thing you invoke in your probe function
for this reason.

Also you are now adding conditionalized code to every fastpath in your
driver, that is rediculous and is going to hurt performance.

Add seperate code paths for the HWBM vs SWBM, and register a unique
set of netdev_ops as appropriate.


From k.kozlowski at samsung.com  Wed Feb 17 21:13:01 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Thu, 18 Feb 2016 14:13:01 +0900
Subject: [PATCH v2 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420
Message-ID: <1455772383-20598-1-git-send-email-k.kozlowski@samsung.com>

On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
12 steps for big core (700-1800 MHz). Add respective cooling cells.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>

---

Changes since v1:
1. Add cooling properties to all CPUs (suggested by Viresh).
---
 arch/arm/boot/dts/exynos5420-cpus.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
index 261d25173f61..5c052d7ff554 100644
--- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
@@ -33,6 +33,9 @@
 			clock-frequency = <1800000000>;
 			cci-control-port = <&cci_control1>;
 			operating-points-v2 = <&cluster_a15_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <11>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu1: cpu at 1 {
@@ -42,6 +45,9 @@
 			clock-frequency = <1800000000>;
 			cci-control-port = <&cci_control1>;
 			operating-points-v2 = <&cluster_a15_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <11>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu2: cpu at 2 {
@@ -51,6 +57,9 @@
 			clock-frequency = <1800000000>;
 			cci-control-port = <&cci_control1>;
 			operating-points-v2 = <&cluster_a15_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <11>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu3: cpu at 3 {
@@ -60,6 +69,9 @@
 			clock-frequency = <1800000000>;
 			cci-control-port = <&cci_control1>;
 			operating-points-v2 = <&cluster_a15_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <11>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu4: cpu at 100 {
@@ -70,6 +82,9 @@
 			clock-frequency = <1000000000>;
 			cci-control-port = <&cci_control0>;
 			operating-points-v2 = <&cluster_a7_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <7>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu5: cpu at 101 {
@@ -79,6 +94,9 @@
 			clock-frequency = <1000000000>;
 			cci-control-port = <&cci_control0>;
 			operating-points-v2 = <&cluster_a7_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <7>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu6: cpu at 102 {
@@ -88,6 +106,9 @@
 			clock-frequency = <1000000000>;
 			cci-control-port = <&cci_control0>;
 			operating-points-v2 = <&cluster_a7_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <7>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu7: cpu at 103 {
@@ -97,6 +118,9 @@
 			clock-frequency = <1000000000>;
 			cci-control-port = <&cci_control0>;
 			operating-points-v2 = <&cluster_a7_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <7>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 	};
 };
-- 
2.5.0



From k.kozlowski at samsung.com  Wed Feb 17 21:13:02 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Thu, 18 Feb 2016 14:13:02 +0900
Subject: [PATCH v2 2/3] ARM: dts: Add cooling levels for CPUs on
 exynos5422/5800
In-Reply-To: <1455772383-20598-1-git-send-email-k.kozlowski@samsung.com>
References: <1455772383-20598-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455772383-20598-2-git-send-email-k.kozlowski@samsung.com>

On Exynos5422 and Exynos5800 we support 12 cpufreq steps (200-1300 MHz) for LITTLE
and 18 steps for big core (200-1700 MHz). Add respective cooling cells.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>

---

Changes since v1:
1. Add cooling properties to all CPUs (suggested by Viresh).
---
 arch/arm/boot/dts/exynos5422-cpus.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi b/arch/arm/boot/dts/exynos5422-cpus.dtsi
index 9b46b9fbac4e..bf3c6f1ec4ee 100644
--- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -32,6 +32,9 @@
 			clock-frequency = <1000000000>;
 			cci-control-port = <&cci_control0>;
 			operating-points-v2 = <&cluster_a7_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <11>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu1: cpu at 101 {
@@ -41,6 +44,9 @@
 			clock-frequency = <1000000000>;
 			cci-control-port = <&cci_control0>;
 			operating-points-v2 = <&cluster_a7_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <11>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu2: cpu at 102 {
@@ -50,6 +56,9 @@
 			clock-frequency = <1000000000>;
 			cci-control-port = <&cci_control0>;
 			operating-points-v2 = <&cluster_a7_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <11>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu3: cpu at 103 {
@@ -59,6 +68,9 @@
 			clock-frequency = <1000000000>;
 			cci-control-port = <&cci_control0>;
 			operating-points-v2 = <&cluster_a7_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <11>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu4: cpu at 0 {
@@ -69,6 +81,9 @@
 			clock-frequency = <1800000000>;
 			cci-control-port = <&cci_control1>;
 			operating-points-v2 = <&cluster_a15_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <15>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu5: cpu at 1 {
@@ -78,6 +93,9 @@
 			clock-frequency = <1800000000>;
 			cci-control-port = <&cci_control1>;
 			operating-points-v2 = <&cluster_a15_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <15>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu6: cpu at 2 {
@@ -87,6 +105,9 @@
 			clock-frequency = <1800000000>;
 			cci-control-port = <&cci_control1>;
 			operating-points-v2 = <&cluster_a15_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <15>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 
 		cpu7: cpu at 3 {
@@ -96,6 +117,9 @@
 			clock-frequency = <1800000000>;
 			cci-control-port = <&cci_control1>;
 			operating-points-v2 = <&cluster_a15_opp_table>;
+			cooling-min-level = <0>;
+			cooling-max-level = <15>;
+			#cooling-cells = <2>; /* min followed by max */
 		};
 	};
 };
-- 
2.5.0



From k.kozlowski at samsung.com  Wed Feb 17 21:13:03 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Thu, 18 Feb 2016 14:13:03 +0900
Subject: [PATCH v2 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high
 load
In-Reply-To: <1455772383-20598-1-git-send-email-k.kozlowski@samsung.com>
References: <1455772383-20598-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455772383-20598-3-git-send-email-k.kozlowski@samsung.com>

After adding cpufreq-dt support to Exynos542x, the Odroid XU3-Lite can
be easily overheated when launching eight CPU-intensive tasks:
	thermal thermal_zone3: critical temperature reached(121 C),shutting down

This seems to be specific to Odroid XU3-Lite board which officially
supports lower frequencies than regular XU3 or XU4. When working at
maximum CPU speed (1800 MHz big and 1300 MHz LITTLE) in warmer place for
longer time, the fan fails to cool down the board and it reaches
critical temperature.

Add CPU cooling to Exynos5422/5800 to fix this issue. When reaching last
interrupt-driven trip-point (70 degrees of Celsius) start passive
cooling in polling mode (slowing CPU by 2 steps). When reaching 85
degrees of Celsius, start slowing even more, down to 600 MHz.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>

---

Changes since v1:
1. Use polling mode for passive cooling (number of configurable trip
   points in TMU exceeded).

2. Adjust the values (temperature and cooling levels).
---
 arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 46 ++++++++++++++++++++++++++-
 1 file changed, 45 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
index 2b289d7c0d13..3e4c4ad96d63 100644
--- a/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi
@@ -16,7 +16,7 @@
 	thermal-zones {
 		cpu0_thermal: cpu0-thermal {
 			thermal-sensors = <&tmu_cpu0 0>;
-			polling-delay-passive = <0>;
+			polling-delay-passive = <250>;
 			polling-delay = <0>;
 			trips {
 				cpu_alert0: cpu-alert-0 {
@@ -39,6 +39,23 @@
 					hysteresis = <0>; /* millicelsius */
 					type = "critical";
 				};
+				/*
+				 * Exyunos542x support only 4 trip-points
+				 * so for these polling mode is required.
+				 * Start polling at temperature level of last
+				 * interrupt-driven trip: cpu_alert2
+				 */
+				cpu_alert3: cpu-alert-3 {
+					temperature = <70000>; /* millicelsius */
+					hysteresis = <10000>; /* millicelsius */
+					type = "passive";
+				};
+				cpu_alert4: cpu-alert-4 {
+					temperature = <85000>; /* millicelsius */
+					hysteresis = <10000>; /* millicelsius */
+					type = "passive";
+				};
+
 			};
 			cooling-maps {
 				map0 {
@@ -53,6 +70,33 @@
 				     trip = <&cpu_alert2>;
 				     cooling-device = <&fan0 2 3>;
 				};
+				/*
+				 * When reaching cpu_alert3, reduce CPU
+				 * by 2 steps. On Exynos5422/5800 that would
+				 * be: 1500 MHz and 1100 MHz.
+				 */
+				map3 {
+				     trip = <&cpu_alert3>;
+				     cooling-device = <&cpu0 0 2>;
+				};
+				map4 {
+				     trip = <&cpu_alert3>;
+				     cooling-device = <&cpu4 0 2>;
+				};
+
+				/*
+				 * When reaching cpu_alert4, reduce CPU
+				 * further, down to 600 MHz (11 steps for big,
+				 * 7 steps for LITTLE).
+				 */
+				map5 {
+				     trip = <&cpu_alert4>;
+				     cooling-device = <&cpu0 3 7>;
+				};
+				map6 {
+				     trip = <&cpu_alert4>;
+				     cooling-device = <&cpu4 3 11>;
+				};
 			};
 		};
 	};
-- 
2.5.0



From yangyingliang at huawei.com  Wed Feb 17 21:00:58 2016
From: yangyingliang at huawei.com (Yang Yingliang)
Date: Thu, 18 Feb 2016 13:00:58 +0800
Subject: A gic problem about eoi
Message-ID: <56C5500A.2060104@huawei.com>

Hi, Marc

We found if hardware clear pending and active status is slower than
software handling, the new sgi will be merged because of hardware 
status. The new sgi will be lost.

If we add a dsb instruction after gic_write_eoir(), it can avoid this
case happening.

Is it a right way to add a dsb instruction after gic_write_eoir()
in current gic driver code ?

Thanks,
Yang



From k.kozlowski at samsung.com  Wed Feb 17 21:14:18 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Thu, 18 Feb 2016 14:14:18 +0900
Subject: [PATCH 1/3] thermal: exynos: Document compatible for Exynos5433 TMU
Message-ID: <1455772460-20684-1-git-send-email-k.kozlowski@samsung.com>

Commit 488c7455d74c ("thermal: exynos: Add the support for Exynos5433
TMU") added new compatible but forgot to update documentation.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---
 Documentation/devicetree/bindings/thermal/exynos-thermal.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 695150a4136b..34315d7fbfde 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -11,6 +11,7 @@
 	       "samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420
 	       "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4
 			Exynos5420 (Must pass triminfo base and triminfo clock)
+               "samsung,exynos5433-tmu"
 	       "samsung,exynos5440-tmu"
 	       "samsung,exynos7-tmu"
 - interrupt-parent : The phandle for the interrupt controller
-- 
2.5.0



From k.kozlowski at samsung.com  Wed Feb 17 21:14:20 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Thu, 18 Feb 2016 14:14:20 +0900
Subject: [PATCH 3/3] thermal: exynos: Print a message about exceeded number of
 supported trip-points
In-Reply-To: <1455772460-20684-1-git-send-email-k.kozlowski@samsung.com>
References: <1455772460-20684-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455772460-20684-3-git-send-email-k.kozlowski@samsung.com>

When DeviveTree contains more trip-points than SoC can configure
(usually more than four) and polling mode is not enabled, then the
remaining trip-points will be silently ignored. No interrupts will be
generated for them.

This might be quite dangerous when one provides DTB with a
non-configurable critical trip-point, like (assuming four supported
thresholds in TMU):
 - alert @50 C (type: active),
 - alert @60 C (type: active),
 - alert @70 C (type: active),
 - alert @80 C (type: active),
 - critical @120 C (type: critical) <- no interrupts generated.

This is a mistake in DTB so print a message in such case.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---
 drivers/thermal/samsung/exynos_tmu.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index fa61eff88496..6c6f59ba7423 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -184,6 +184,7 @@
  * @temp_error2: fused value of the second point trim.
  * @regulator: pointer to the TMU regulator structure.
  * @reg_conf: pointer to structure to register with core thermal.
+ * @ntrip: number of supported trip points.
  * @tmu_initialize: SoC specific TMU initialization method
  * @tmu_control: SoC specific TMU control method
  * @tmu_read: SoC specific TMU temperature read method
@@ -203,6 +204,7 @@ struct exynos_tmu_data {
 	u16 temp_error1, temp_error2;
 	struct regulator *regulator;
 	struct thermal_zone_device *tzd;
+	unsigned int ntrip;
 
 	int (*tmu_initialize)(struct platform_device *pdev);
 	void (*tmu_control)(struct platform_device *pdev, bool on);
@@ -346,6 +348,14 @@ static int exynos_tmu_initialize(struct platform_device *pdev)
 	struct exynos_tmu_data *data = platform_get_drvdata(pdev);
 	int ret;
 
+	if (of_thermal_get_ntrips(data->tzd) > data->ntrip) {
+		dev_info(&pdev->dev,
+			 "More trip points than supported by this TMU.\n");
+		dev_info(&pdev->dev,
+			 "%d trip points should be configured in polling mode.\n",
+			 (of_thermal_get_ntrips(data->tzd) - data->ntrip));
+	}
+
 	mutex_lock(&data->lock);
 	clk_enable(data->clk);
 	if (!IS_ERR(data->clk_sec))
@@ -1210,6 +1220,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
 		data->tmu_control = exynos4210_tmu_control;
 		data->tmu_read = exynos4210_tmu_read;
 		data->tmu_clear_irqs = exynos4210_tmu_clear_irqs;
+		data->ntrip = 4;
 		break;
 	case SOC_ARCH_EXYNOS3250:
 	case SOC_ARCH_EXYNOS4412:
@@ -1222,6 +1233,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
 		data->tmu_read = exynos4412_tmu_read;
 		data->tmu_set_emulation = exynos4412_tmu_set_emulation;
 		data->tmu_clear_irqs = exynos4210_tmu_clear_irqs;
+		data->ntrip = 4;
 		break;
 	case SOC_ARCH_EXYNOS5433:
 		data->tmu_initialize = exynos5433_tmu_initialize;
@@ -1229,6 +1241,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
 		data->tmu_read = exynos4412_tmu_read;
 		data->tmu_set_emulation = exynos4412_tmu_set_emulation;
 		data->tmu_clear_irqs = exynos4210_tmu_clear_irqs;
+		data->ntrip = 8;
 		break;
 	case SOC_ARCH_EXYNOS5440:
 		data->tmu_initialize = exynos5440_tmu_initialize;
@@ -1236,6 +1249,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
 		data->tmu_read = exynos5440_tmu_read;
 		data->tmu_set_emulation = exynos5440_tmu_set_emulation;
 		data->tmu_clear_irqs = exynos5440_tmu_clear_irqs;
+		data->ntrip = 4;
 		break;
 	case SOC_ARCH_EXYNOS7:
 		data->tmu_initialize = exynos7_tmu_initialize;
@@ -1243,6 +1257,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
 		data->tmu_read = exynos7_tmu_read;
 		data->tmu_set_emulation = exynos4412_tmu_set_emulation;
 		data->tmu_clear_irqs = exynos4210_tmu_clear_irqs;
+		data->ntrip = 8;
 		break;
 	default:
 		dev_err(&pdev->dev, "Platform not supported\n");
-- 
2.5.0



From k.kozlowski at samsung.com  Wed Feb 17 21:14:19 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Thu, 18 Feb 2016 14:14:19 +0900
Subject: [PATCH 2/3] thermal: exynos: Document number of supported trip-points
In-Reply-To: <1455772460-20684-1-git-send-email-k.kozlowski@samsung.com>
References: <1455772460-20684-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1455772460-20684-2-git-send-email-k.kozlowski@samsung.com>

Document the number of configurable temperature thresholds (for
trip-points in interrupt-driven mode).

Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---
 Documentation/devicetree/bindings/thermal/exynos-thermal.txt | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 34315d7fbfde..faa62059b5c5 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -44,6 +44,14 @@
 - vtmu-supply: This entry is optional and provides the regulator node supplying
 		voltage to TMU. If needed this entry can be placed inside
 		board/platform specific dts file.
+
+The Exynos TMU supports generating interrupts when reaching given
+temperature thresholds. Number of supported thermal trip points depends
+on the SoC (only first trip points defined in DT will be configured):
+ - most of SoC: 4
+ - samsung,exynos5433-tmu: 8
+ - samsung,exynos7-tmu: 8
+
 Following properties are mandatory (depending on SoC):
 - samsung,tmu_gain: Gain value for internal TMU operation.
 - samsung,tmu_reference_voltage: Value of TMU IP block's reference voltage
-- 
2.5.0



From cw00.choi at samsung.com  Wed Feb 17 21:20:12 2016
From: cw00.choi at samsung.com (Chanwoo Choi)
Date: Thu, 18 Feb 2016 14:20:12 +0900
Subject: [PATCH 1/3] thermal: exynos: Document compatible for Exynos5433
 TMU
In-Reply-To: <1455772460-20684-1-git-send-email-k.kozlowski@samsung.com>
References: <1455772460-20684-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <56C5548C.7090305@samsung.com>

On 2016? 02? 18? 14:14, Krzysztof Kozlowski wrote:
> Commit 488c7455d74c ("thermal: exynos: Add the support for Exynos5433
> TMU") added new compatible but forgot to update documentation.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> ---
>  Documentation/devicetree/bindings/thermal/exynos-thermal.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index 695150a4136b..34315d7fbfde 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -11,6 +11,7 @@
>  	       "samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420
>  	       "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4
>  			Exynos5420 (Must pass triminfo base and triminfo clock)
> +               "samsung,exynos5433-tmu"
>  	       "samsung,exynos5440-tmu"
>  	       "samsung,exynos7-tmu"
>  - interrupt-parent : The phandle for the interrupt controller
> 

I was implementing the Exynos5433's thermal driver. Looks good to me.

Reviewed-by: Chanwoo Choi <cw00.choi at samsung.com>

Best Regards,
Chanwoo Choi


From cw00.choi at samsung.com  Wed Feb 17 21:21:32 2016
From: cw00.choi at samsung.com (Chanwoo Choi)
Date: Thu, 18 Feb 2016 14:21:32 +0900
Subject: [PATCH 2/3] thermal: exynos: Document number of supported
 trip-points
In-Reply-To: <1455772460-20684-2-git-send-email-k.kozlowski@samsung.com>
References: <1455772460-20684-1-git-send-email-k.kozlowski@samsung.com>
 <1455772460-20684-2-git-send-email-k.kozlowski@samsung.com>
Message-ID: <56C554DC.1040104@samsung.com>

On 2016? 02? 18? 14:14, Krzysztof Kozlowski wrote:
> Document the number of configurable temperature thresholds (for
> trip-points in interrupt-driven mode).
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> ---
>  Documentation/devicetree/bindings/thermal/exynos-thermal.txt | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index 34315d7fbfde..faa62059b5c5 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -44,6 +44,14 @@
>  - vtmu-supply: This entry is optional and provides the regulator node supplying
>  		voltage to TMU. If needed this entry can be placed inside
>  		board/platform specific dts file.
> +
> +The Exynos TMU supports generating interrupts when reaching given
> +temperature thresholds. Number of supported thermal trip points depends
> +on the SoC (only first trip points defined in DT will be configured):
> + - most of SoC: 4
> + - samsung,exynos5433-tmu: 8
> + - samsung,exynos7-tmu: 8
> +
>  Following properties are mandatory (depending on SoC):
>  - samsung,tmu_gain: Gain value for internal TMU operation.
>  - samsung,tmu_reference_voltage: Value of TMU IP block's reference voltage
> 

Exynos5433 has the 8 interrupt for thermal. Looks good to me.
Reviewed-by: Chanwoo Choi <cw00.choi at samsung.com>

Best Regards,
Chanwoo Choi


From j-keerthy at ti.com  Wed Feb 17 21:29:39 2016
From: j-keerthy at ti.com (Keerthy)
Date: Thu, 18 Feb 2016 10:59:39 +0530
Subject: [PATCH 0/2] arm: am43xx: Enable rtc
Message-ID: <1455773381-11839-1-git-send-email-j-keerthy@ti.com>

The patch adds rtc hwmod. This is present on gp and sk evm and not on
epos evm. Hence adding it selectively using a seprate list. 

Keerthy (2):
  ARM: dts: am43x-epos-evm: Add the am438 compatible string
  ARM: AM43XX: HWMOD: Add rtc hwmod

 Documentation/devicetree/bindings/arm/omap/omap.txt |  2 +-
 arch/arm/boot/dts/am43x-epos-evm.dts                |  2 +-
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c          | 14 +++++++++++++-
 3 files changed, 15 insertions(+), 3 deletions(-)

-- 
1.9.1



From j-keerthy at ti.com  Wed Feb 17 21:29:40 2016
From: j-keerthy at ti.com (Keerthy)
Date: Thu, 18 Feb 2016 10:59:40 +0530
Subject: [PATCH 1/2] ARM: dts: am43x-epos-evm: Add the am438 compatible string
In-Reply-To: <1455773381-11839-1-git-send-email-j-keerthy@ti.com>
References: <1455773381-11839-1-git-send-email-j-keerthy@ti.com>
Message-ID: <1455773381-11839-2-git-send-email-j-keerthy@ti.com>

The SoCs on am43x-epos-evm are named am438x.
Hence add the compatibility string and remove the am4372 string.

Signed-off-by: Keerthy <j-keerthy at ti.com>
---
 Documentation/devicetree/bindings/arm/omap/omap.txt | 2 +-
 arch/arm/boot/dts/am43x-epos-evm.dts                | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index a2bd593..739bc48 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -154,7 +154,7 @@ Boards:
   compatible = "compulab,am437x-sbc-t43", "compulab,am437x-cm-t43", "ti,am4372", "ti,am43"
 
 - AM43x EPOS EVM
-  compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
+  compatible = "ti,am43x-epos-evm", "ti,am43", "ti,am438x"
 
 - AM437x GP EVM
   compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index d580e2b..d2408c4 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -18,7 +18,7 @@
 
 / {
 	model = "TI AM43x EPOS EVM";
-	compatible = "ti,am43x-epos-evm","ti,am4372","ti,am43";
+	compatible = "ti,am43x-epos-evm","ti,am438x","ti,am43";
 
 	aliases {
 		display0 = &lcd0;
-- 
1.9.1



From j-keerthy at ti.com  Wed Feb 17 21:29:41 2016
From: j-keerthy at ti.com (Keerthy)
Date: Thu, 18 Feb 2016 10:59:41 +0530
Subject: [PATCH 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod
In-Reply-To: <1455773381-11839-1-git-send-email-j-keerthy@ti.com>
References: <1455773381-11839-1-git-send-email-j-keerthy@ti.com>
Message-ID: <1455773381-11839-3-git-send-email-j-keerthy@ti.com>

The patch adds rtc hwmod. RTC module The RTC module is physically
present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently
disabled. A secure RTC is used instead on these devices, where needed.
. Hence adding it selectively using a seprate list to get RTC Module
functional on the other am43x SoCs used on am437x-gp-evm and
am437x-sk-evm.

Signed-off-by: Keerthy <j-keerthy at ti.com>
---

No Public TRM is available for AM438x SoC as of now.

 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index e97a894..fcffaf8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -1020,9 +1020,21 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
 	NULL,
 };
 
+static struct omap_hwmod_ocp_if *am43xx_rtc_hwmod_ocp_ifs[] __initdata = {
+	&am33xx_l4_wkup__rtc,
+	NULL,
+};
+
 int __init am43xx_hwmod_init(void)
 {
+	int ret;
+
 	omap_hwmod_am43xx_reg();
 	omap_hwmod_init();
-	return omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+	ret = omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+
+	if (!(of_machine_is_compatible("ti,am438x")))
+		ret = omap_hwmod_register_links(am43xx_rtc_hwmod_ocp_ifs);
+
+	return ret;
 }
-- 
1.9.1



From cw00.choi at samsung.com  Wed Feb 17 21:31:59 2016
From: cw00.choi at samsung.com (Chanwoo Choi)
Date: Thu, 18 Feb 2016 14:31:59 +0900
Subject: [PATCH 3/3] thermal: exynos: Print a message about exceeded number
 of supported trip-points
In-Reply-To: <1455772460-20684-3-git-send-email-k.kozlowski@samsung.com>
References: <1455772460-20684-1-git-send-email-k.kozlowski@samsung.com>
 <1455772460-20684-3-git-send-email-k.kozlowski@samsung.com>
Message-ID: <56C5574F.7090900@samsung.com>

On 2016? 02? 18? 14:14, Krzysztof Kozlowski wrote:
> When DeviveTree contains more trip-points than SoC can configure
> (usually more than four) and polling mode is not enabled, then the
> remaining trip-points will be silently ignored. No interrupts will be
> generated for them.
> 
> This might be quite dangerous when one provides DTB with a
> non-configurable critical trip-point, like (assuming four supported
> thresholds in TMU):
>  - alert @50 C (type: active),
>  - alert @60 C (type: active),
>  - alert @70 C (type: active),
>  - alert @80 C (type: active),
>  - critical @120 C (type: critical) <- no interrupts generated.
> 
> This is a mistake in DTB so print a message in such case.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> ---
>  drivers/thermal/samsung/exynos_tmu.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
> index fa61eff88496..6c6f59ba7423 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -184,6 +184,7 @@
>   * @temp_error2: fused value of the second point trim.
>   * @regulator: pointer to the TMU regulator structure.
>   * @reg_conf: pointer to structure to register with core thermal.
> + * @ntrip: number of supported trip points.
>   * @tmu_initialize: SoC specific TMU initialization method
>   * @tmu_control: SoC specific TMU control method
>   * @tmu_read: SoC specific TMU temperature read method
> @@ -203,6 +204,7 @@ struct exynos_tmu_data {
>  	u16 temp_error1, temp_error2;
>  	struct regulator *regulator;
>  	struct thermal_zone_device *tzd;
> +	unsigned int ntrip;
>  
>  	int (*tmu_initialize)(struct platform_device *pdev);
>  	void (*tmu_control)(struct platform_device *pdev, bool on);
> @@ -346,6 +348,14 @@ static int exynos_tmu_initialize(struct platform_device *pdev)
>  	struct exynos_tmu_data *data = platform_get_drvdata(pdev);
>  	int ret;
>  
> +	if (of_thermal_get_ntrips(data->tzd) > data->ntrip) {
> +		dev_info(&pdev->dev,
> +			 "More trip points than supported by this TMU.\n");
> +		dev_info(&pdev->dev,
> +			 "%d trip points should be configured in polling mode.\n",
> +			 (of_thermal_get_ntrips(data->tzd) - data->ntrip));
> +	}
> +
>  	mutex_lock(&data->lock);
>  	clk_enable(data->clk);
>  	if (!IS_ERR(data->clk_sec))
> @@ -1210,6 +1220,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
>  		data->tmu_control = exynos4210_tmu_control;
>  		data->tmu_read = exynos4210_tmu_read;
>  		data->tmu_clear_irqs = exynos4210_tmu_clear_irqs;
> +		data->ntrip = 4;
>  		break;
>  	case SOC_ARCH_EXYNOS3250:
>  	case SOC_ARCH_EXYNOS4412:
> @@ -1222,6 +1233,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
>  		data->tmu_read = exynos4412_tmu_read;
>  		data->tmu_set_emulation = exynos4412_tmu_set_emulation;
>  		data->tmu_clear_irqs = exynos4210_tmu_clear_irqs;
> +		data->ntrip = 4;
>  		break;
>  	case SOC_ARCH_EXYNOS5433:
>  		data->tmu_initialize = exynos5433_tmu_initialize;
> @@ -1229,6 +1241,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
>  		data->tmu_read = exynos4412_tmu_read;
>  		data->tmu_set_emulation = exynos4412_tmu_set_emulation;
>  		data->tmu_clear_irqs = exynos4210_tmu_clear_irqs;
> +		data->ntrip = 8;
>  		break;
>  	case SOC_ARCH_EXYNOS5440:
>  		data->tmu_initialize = exynos5440_tmu_initialize;
> @@ -1236,6 +1249,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
>  		data->tmu_read = exynos5440_tmu_read;
>  		data->tmu_set_emulation = exynos5440_tmu_set_emulation;
>  		data->tmu_clear_irqs = exynos5440_tmu_clear_irqs;
> +		data->ntrip = 4;
>  		break;
>  	case SOC_ARCH_EXYNOS7:
>  		data->tmu_initialize = exynos7_tmu_initialize;
> @@ -1243,6 +1257,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
>  		data->tmu_read = exynos7_tmu_read;
>  		data->tmu_set_emulation = exynos4412_tmu_set_emulation;
>  		data->tmu_clear_irqs = exynos4210_tmu_clear_irqs;
> +		data->ntrip = 8;
>  		break;
>  	default:
>  		dev_err(&pdev->dev, "Platform not supported\n");
> 

Exynos5433 and Exynos7 have the 8 interrupt.

Reviewed-by: Chanwoo Choi <cw00.choi at samsung.com>

Best Regards,
Chanwoo Choi


From mark.yao at rock-chips.com  Wed Feb 17 22:12:02 2016
From: mark.yao at rock-chips.com (Mark yao)
Date: Thu, 18 Feb 2016 14:12:02 +0800
Subject: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver
In-Reply-To: <1454049768-30872-1-git-send-email-ykk@rock-chips.com>
References: <1454049768-30872-1-git-send-email-ykk@rock-chips.com>
Message-ID: <56C560B2.6020208@rock-chips.com>

On 2016?01?29? 14:42, Yakir Yang wrote:
> Here are a brief introduction to Innosilicon HDMI IP:
>    - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter
>    - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec
>    - Digital video interface supports a pixel size of 24, 30, 36, 48bits color depth in RGB
>    - S/PDIF output supports PCM, Dolby Digital, DTS digital audio transmission
>      (32-192kHz Fs) using IEC60958 and IEC 61937
>    - The EDID and CEC function are also supported by Innosilicon HDMI Transmitter Controlle
>
> Changes in v8:
> - Don't check whether encoder output format is RGB colorspace, cause driver
>    default configure the output colorspace to RGB. (ZhengYang)
> - Correct the check condition in inno_hdmi_config_video_csc() (ZhengYang)
>      - if (data->enc_out_format == data->enc_out_format) {
>      + if (data->enc_in_format == data->enc_out_format) {
>
> Changes in v7:
> - Correct the module licnese statement (Paul)
>       - MODULE_LICENSE("GPL");
>       + MODULE_LICENSE("GPLv2");
> - Start indentation with tabs and fix the misspell in Kconfig (Paul)
> - Carry the lost device-binding document (Heiko)
>
> Changes in v6:
> - Rebase the Makefile/Kconfig files which add by Chris's rockchip-mipi driver (Caeser)
>
> Changes in v5:
> - Use hdmi_infoframe helper functions to packed the infoframe (Russell)
> - Remove the unused double wait_for_completion_timeout for ddc transfer (Russell)
> - Remove the unused local variable in "inno_hdmi_i2c_write()" function (Russell)
>
> Changes in v4:
> - Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
> - Correct the "DKMS" to "DPMS" (Mark)
> - Fix over 80 characters problems (Mark)
> - Remove encoder .prepare/.commit helper functions, and move the vop mode
> configure function into encoder .enable helper functions. (Mark)
>
> Changes in v3:
> - Use encoder enable/disable function, and remove the encoder DPMS function
> - Keep HDMI PLL power on in standby mode
>
> Changes in v2:
> - Using DRM atomic helper functions for connector init (Mark)
> - Remove "hdmi->connector.encoder = encoder;" (Mark)
> - Add the Acked-by tags from Rob
> - Correct the misspell "rk3036-dw-hdmi" (Heiko)
>
> Yakir Yang (2):
>    drm/rockchip: hdmi: add Innosilicon HDMI support
>    dt-bindings: add document for Innosilicon HDMI on Rockchip platform
>
>   .../display/rockchip/inno_hdmi-rockchip.txt        |  50 ++
>   drivers/gpu/drm/rockchip/Kconfig                   |   8 +
>   drivers/gpu/drm/rockchip/Makefile                  |   1 +
>   drivers/gpu/drm/rockchip/inno_hdmi.c               | 939 +++++++++++++++++++++
>   drivers/gpu/drm/rockchip/inno_hdmi.h               | 362 ++++++++
>   5 files changed, 1360 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
>   create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
>   create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h
>

Applied to my branch :-) .

Thanks.

-- 
?ark Yao




From wenyou.yang at atmel.com  Wed Feb 17 22:11:03 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Thu, 18 Feb 2016 14:11:03 +0800
Subject: [PATCH v2] mtd: atmel_nand: move the hsmc_clk from nfc node to nand
 node
Message-ID: <1455775863-4559-1-git-send-email-wenyou.yang@atmel.com>

From: Josh Wu <josh.wu at atmel.com>

For sama5d3, sama5d4 chip, the pmecc becomes a part of HSMC, they
need the HSMC clock to be enabled to work.
The NFC is a sub feature for current nand driver, it can be disabled.
But if HSMC clock is controlled by NFC, so disable NFC will also
disable the HSMC clock. then, it will make the PMECC fail to work.

So the solution is to move the HSMC clock out of NFC to nand node.
When nand driver probed, it will check whether the chip has HSMC,
if yes then it will require a HSMC clock.

Signed-off-by: Josh Wu <rainyfeeling at outlook.com>
Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---

Changes in v2:
 - add missing .has_hsmc_clk assignment for sama5d2_caps.

 .../devicetree/bindings/mtd/atmel-nand.txt         |    4 +-
 drivers/mtd/nand/atmel_nand.c                      |   44 ++++++++++----------
 2 files changed, 23 insertions(+), 25 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index d53aba9..29bee7c 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -15,6 +15,7 @@ Required properties:
 - atmel,nand-cmd-offset : offset for the command latch.
 - #address-cells, #size-cells : Must be present if the device has sub-nodes
   representing partitions.
+- clocks: phandle to the peripheral clock
 
 - gpios : specifies the gpio pins to control the NAND device. detect is an
   optional gpio and may be set to 0 if not present.
@@ -43,7 +44,6 @@ Required properties:
 - reg : should specify the address and size used for NFC command registers,
         NFC registers and NFC SRAM. NFC SRAM address and size can be absent
         if don't want to use it.
-- clocks: phandle to the peripheral clock
 Optional properties:
 - atmel,write-by-sram: boolean to enable NFC write by SRAM.
 
@@ -100,13 +100,13 @@ nand0: nand at 40000000 {
 	compatible = "atmel,at91rm9200-nand";
 	#address-cells = <1>;
 	#size-cells = <1>;
+	clocks = <&hsmc_clk>
 	ranges;
         ...
         nfc at 70000000 {
 		compatible = "atmel,sama5d3-nfc";
 		#address-cells = <1>;
 		#size-cells = <1>;
-		clocks = <&hsmc_clk>
 		reg = <
 			0x70000000 0x10000000	/* NFC Command Registers */
 			0xffffc000 0x00000070	/* NFC HSMC regs */
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 20cbaab..26518b0 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -66,6 +66,7 @@ module_param(on_flash_bbt, int, 0);
 struct atmel_nand_caps {
 	bool pmecc_correct_erase_page;
 	uint8_t pmecc_max_correction;
+	bool has_hsmc_clk;
 };
 
 struct atmel_nand_nfc_caps {
@@ -106,8 +107,6 @@ struct atmel_nfc {
 	bool			use_nfc_sram;
 	bool			write_by_sram;
 
-	struct clk		*clk;
-
 	bool			is_initialized;
 	struct completion	comp_ready;
 	struct completion	comp_cmd_done;
@@ -132,6 +131,7 @@ struct atmel_nand_host {
 	struct dma_chan		*dma_chan;
 
 	struct atmel_nfc	*nfc;
+	struct clk		*clk;
 
 	const struct atmel_nand_caps	*caps;
 	bool			has_pmecc;
@@ -2157,6 +2157,19 @@ static int atmel_nand_probe(struct platform_device *pdev)
 	nand_chip->IO_ADDR_R = host->io_base;
 	nand_chip->IO_ADDR_W = host->io_base;
 
+	if (host->caps->has_hsmc_clk) {
+		host->clk = devm_clk_get(&pdev->dev, NULL);
+		if (IS_ERR(host->clk)) {
+			dev_err(&pdev->dev, "HSMC clock is missing, update your Device Tree");
+			res = PTR_ERR(host->clk);
+			goto err_nand_ioremap;
+		}
+
+		res = clk_prepare_enable(host->clk);
+		if (res)
+			goto err_nand_ioremap;
+	}
+
 	if (nand_nfc.is_initialized) {
 		/* NFC driver is probed and initialized */
 		host->nfc = &nand_nfc;
@@ -2321,6 +2334,9 @@ static int atmel_nand_remove(struct platform_device *pdev)
 	if (host->dma_chan)
 		dma_release_channel(host->dma_chan);
 
+	if (!IS_ERR(host->clk))
+		clk_disable_unprepare(host->clk);
+
 	platform_driver_unregister(&atmel_nand_nfc_driver);
 
 	return 0;
@@ -2334,11 +2350,13 @@ static int atmel_nand_remove(struct platform_device *pdev)
 static const struct atmel_nand_caps at91rm9200_caps = {
 	.pmecc_correct_erase_page = false,
 	.pmecc_max_correction = 24,
+	.has_hsmc_clk = false,
 };
 
 static const struct atmel_nand_caps sama5d4_caps = {
 	.pmecc_correct_erase_page = true,
 	.pmecc_max_correction = 24,
+	.has_hsmc_clk = true,
 };
 
 /*
@@ -2348,6 +2366,7 @@ static const struct atmel_nand_caps sama5d4_caps = {
 static const struct atmel_nand_caps sama5d2_caps = {
 	.pmecc_correct_erase_page = true,
 	.pmecc_max_correction = 32,
+	.has_hsmc_clk = true,
 };
 
 static const struct of_device_id atmel_nand_dt_ids[] = {
@@ -2363,7 +2382,6 @@ static int atmel_nand_nfc_probe(struct platform_device *pdev)
 {
 	struct atmel_nfc *nfc = &nand_nfc;
 	struct resource *nfc_cmd_regs, *nfc_hsmc_regs, *nfc_sram;
-	int ret;
 
 	nfc_cmd_regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	nfc->base_cmd_regs = devm_ioremap_resource(&pdev->dev, nfc_cmd_regs);
@@ -2401,31 +2419,12 @@ static int atmel_nand_nfc_probe(struct platform_device *pdev)
 	nfc_writel(nfc->hsmc_regs, IDR, 0xffffffff);
 	nfc_readl(nfc->hsmc_regs, SR);	/* clear the NFC_SR */
 
-	nfc->clk = devm_clk_get(&pdev->dev, NULL);
-	if (!IS_ERR(nfc->clk)) {
-		ret = clk_prepare_enable(nfc->clk);
-		if (ret)
-			return ret;
-	} else {
-		dev_warn(&pdev->dev, "NFC clock missing, update your Device Tree");
-	}
-
 	nfc->is_initialized = true;
 	dev_info(&pdev->dev, "NFC is probed.\n");
 
 	return 0;
 }
 
-static int atmel_nand_nfc_remove(struct platform_device *pdev)
-{
-	struct atmel_nfc *nfc = &nand_nfc;
-
-	if (!IS_ERR(nfc->clk))
-		clk_disable_unprepare(nfc->clk);
-
-	return 0;
-}
-
 static const struct atmel_nand_nfc_caps sama5d3_nfc_caps = {
 	.rb_mask = NFC_SR_RB_EDGE0,
 };
@@ -2447,7 +2446,6 @@ static struct platform_driver atmel_nand_nfc_driver = {
 		.of_match_table = of_match_ptr(atmel_nand_nfc_match),
 	},
 	.probe = atmel_nand_nfc_probe,
-	.remove = atmel_nand_nfc_remove,
 };
 
 static struct platform_driver atmel_nand_driver = {
-- 
1.7.9.5



From viresh.kumar at linaro.org  Wed Feb 17 22:21:13 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 18 Feb 2016 11:51:13 +0530
Subject: [PATCH v2 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420
In-Reply-To: <1455772383-20598-1-git-send-email-k.kozlowski@samsung.com>
References: <1455772383-20598-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <20160218062113.GS2610@vireshk-i7>

On 18-02-16, 14:13, Krzysztof Kozlowski wrote:
> On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
> 12 steps for big core (700-1800 MHz). Add respective cooling cells.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> 
> ---
> 
> Changes since v1:
> 1. Add cooling properties to all CPUs (suggested by Viresh).
> ---
>  arch/arm/boot/dts/exynos5420-cpus.dtsi | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>

-- 
viresh


From viresh.kumar at linaro.org  Wed Feb 17 22:21:33 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 18 Feb 2016 11:51:33 +0530
Subject: [PATCH v2 2/3] ARM: dts: Add cooling levels for CPUs on
 exynos5422/5800
In-Reply-To: <1455772383-20598-2-git-send-email-k.kozlowski@samsung.com>
References: <1455772383-20598-1-git-send-email-k.kozlowski@samsung.com>
 <1455772383-20598-2-git-send-email-k.kozlowski@samsung.com>
Message-ID: <20160218062133.GT2610@vireshk-i7>

On 18-02-16, 14:13, Krzysztof Kozlowski wrote:
> On Exynos5422 and Exynos5800 we support 12 cpufreq steps (200-1300 MHz) for LITTLE
> and 18 steps for big core (200-1700 MHz). Add respective cooling cells.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> 
> ---
> 
> Changes since v1:
> 1. Add cooling properties to all CPUs (suggested by Viresh).
> ---
>  arch/arm/boot/dts/exynos5422-cpus.dtsi | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>

-- 
viresh


From viresh.kumar at linaro.org  Wed Feb 17 22:22:24 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 18 Feb 2016 11:52:24 +0530
Subject: [PATCH v2 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on
 high load
In-Reply-To: <1455772383-20598-3-git-send-email-k.kozlowski@samsung.com>
References: <1455772383-20598-1-git-send-email-k.kozlowski@samsung.com>
 <1455772383-20598-3-git-send-email-k.kozlowski@samsung.com>
Message-ID: <20160218062224.GU2610@vireshk-i7>

On 18-02-16, 14:13, Krzysztof Kozlowski wrote:
> After adding cpufreq-dt support to Exynos542x, the Odroid XU3-Lite can
> be easily overheated when launching eight CPU-intensive tasks:
> 	thermal thermal_zone3: critical temperature reached(121 C),shutting down
> 
> This seems to be specific to Odroid XU3-Lite board which officially
> supports lower frequencies than regular XU3 or XU4. When working at
> maximum CPU speed (1800 MHz big and 1300 MHz LITTLE) in warmer place for
> longer time, the fan fails to cool down the board and it reaches
> critical temperature.
> 
> Add CPU cooling to Exynos5422/5800 to fix this issue. When reaching last
> interrupt-driven trip-point (70 degrees of Celsius) start passive
> cooling in polling mode (slowing CPU by 2 steps). When reaching 85
> degrees of Celsius, start slowing even more, down to 600 MHz.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> 
> ---
> 
> Changes since v1:
> 1. Use polling mode for passive cooling (number of configurable trip
>    points in TMU exceeded).
> 
> 2. Adjust the values (temperature and cooling levels).
> ---
>  arch/arm/boot/dts/exynos5422-cpu-thermal.dtsi | 46 ++++++++++++++++++++++++++-
>  1 file changed, 45 insertions(+), 1 deletion(-)

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>

-- 
viresh


From paul at pwsan.com  Wed Feb 17 22:27:11 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Thu, 18 Feb 2016 06:27:11 +0000 (UTC)
Subject: [PATCH v4 1/3] ARM: hwmod: RTC: Add lock and unlock functions
In-Reply-To: <alpine.DEB.2.02.1602072209460.2182@utopia.booyaka.com>
References: <1454650952-20154-1-git-send-email-lokeshvutla@ti.com>
 <1454650952-20154-2-git-send-email-lokeshvutla@ti.com>
 <alpine.DEB.2.02.1602072209460.2182@utopia.booyaka.com>
Message-ID: <alpine.DEB.2.02.1602180626420.4792@utopia.booyaka.com>

Hi Lokesh

On Sun, 7 Feb 2016, Paul Walmsley wrote:

> A few comments:
> 
> On Fri, 5 Feb 2016, Lokesh Vutla wrote:
> 
> > RTC IP have kicker feature which prevents spurious writes to its registers.
> > In order to write into any of the RTC registers, KICK values has to be
> > written to KICK registers.
> > Introduce omap_hwmod_rtc_unlock/lock functions, which  writes into these
> > KICK registers inorder to lock and unlock RTC registers.
> > 
> > Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
> > ---
> 
> ...
> 
> > +/**
> > + * omap_rtc_wait_not_busy - Wait for the RTC BUSY flag
> > + * @oh: struct omap_hwmod *
> > + *
> > + * For updating certain RTC registers, the MPU must wait
> > + * for the BUSY status in OMAP_RTC_STATUS_REG to become zero.
> > + * Once the BUSY status is zero, there is a 15-?s access
> 
> Probably best just to write out "microseconds" or "us" here to avoid the 
> high-bit character problem.
> 
> > + * period in which the MPU can program.
> > + */
> > +static void omap_rtc_wait_not_busy(struct omap_hwmod *oh)
> > +{
> > +	int i;
> > +
> > +	/* BUSY may stay active for 1/32768 second (~30 usec) */
> > +	omap_test_timeout(omap_hwmod_read(oh, OMAP_RTC_STATUS_REG)
> > +			  & OMAP_RTC_STATUS_REG, OMAP_RTC_MAX_READY_TIME, i);
> 
> This test looks bogus.  Shouldn't it AND the register value with 
> OMAP_RTC_STATUS_BUSY?  Right now the code is AND-ing with 0x44, which 
> doesn't include the BUSY bit.  So I guess the tests that you mentioned in 
> the first message of the series don't cover the BUSY case?
> 
> > +	/* now we have ~15 usec to read/write various registers */
> > +}
> > +
> > +/**
> > + * omap_hwmod_rtc_unlock - Unlock the Kicker mechanism.
> > + * @oh: struct omap_hwmod *
> > + *
> > + * RTC IP have kicker feature. This prevents spurious writes to its registers.
> > + * In order to write into any of the RTC registers, KICK values has te be
> > + * written in respective KICK registers. This is needed for hwmod to write into
> > + * sysconfig register.
> > + */
> > +void omap_hwmod_rtc_unlock(struct omap_hwmod *oh)
> > +{
> > +	local_irq_disable();
> > +	omap_rtc_wait_not_busy(oh);
> > +	omap_hwmod_write(OMAP_RTC_KICK0_VALUE, oh, OMAP_RTC_KICK0_REG);
> > +	omap_hwmod_write(OMAP_RTC_KICK1_VALUE, oh, OMAP_RTC_KICK1_REG);
> > +	local_irq_enable();
> 
> Finally, could you ask the IP block maintainer to confirm the 
> interpretation that, for any STATUS_REG read where the BUSY bit is 0, that 
> we are guaranteed to have at least 15 microseconds from that point in time 
> to access the IP block?  It appears to be this way from my reading of the 
> TRM; but to me, the phrasing is not explicit.  Another interpretation 
> could be that the BUSY bit reflects the IP block's current status.  If 
> this latter case is true, then to ensure that the IP block accesses 
> complete inside the access window, we'll either need to test the BUSY bit 
> after the writes to ensure that it is still 0, and otherwise repeat the 
> busy test and writes; or we'll need to wait for a 0->1 BUSY transition 
> before we wait for a 1->0 BUSY transition.
> 
> > +}
> > +
> > +/**
> > + * omap_hwmod_rtc_lock - Lock the Kicker mechanism.
> > + * @oh: struct omap_hwmod *
> > + *
> > + * RTC IP have kicker feature. This prevents spurious writes to its registers.
> > + * Once the RTC registers are written, KICK mechanism needs to be locked,
> > + * in order to prevent any spurious writes. This function locks back the RTC
> > + * registers once hwmod completes its write into sysconfig register.
> > + */
> > +void omap_hwmod_rtc_lock(struct omap_hwmod *oh)
> > +{
> > +	local_irq_disable();
> > +	omap_rtc_wait_not_busy(oh);
> > +	omap_hwmod_write(0x0, oh, OMAP_RTC_KICK0_REG);
> > +	omap_hwmod_write(0x0, oh, OMAP_RTC_KICK1_REG);
> > +	local_irq_enable();
> > +}

Any update?


- Paul


From paul at pwsan.com  Wed Feb 17 22:42:32 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Thu, 18 Feb 2016 06:42:32 +0000 (UTC)
Subject: [PATCH 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod
In-Reply-To: <1455773381-11839-3-git-send-email-j-keerthy@ti.com>
References: <1455773381-11839-1-git-send-email-j-keerthy@ti.com>
 <1455773381-11839-3-git-send-email-j-keerthy@ti.com>
Message-ID: <alpine.DEB.2.02.1602180634120.4792@utopia.booyaka.com>

Hi Keerthy

On Thu, 18 Feb 2016, Keerthy wrote:

> The patch adds rtc hwmod. RTC module The RTC module is physically
> present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently
> disabled. A secure RTC is used instead on these devices, where needed.
> . Hence adding it selectively using a seprate list to get RTC Module
> functional on the other am43x SoCs used on am437x-gp-evm and
> am437x-sk-evm.
> 
> Signed-off-by: Keerthy <j-keerthy at ti.com>
> ---
> 
> No Public TRM is available for AM438x SoC as of now.
> 
>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> index e97a894..fcffaf8 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> @@ -1020,9 +1020,21 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
>  	NULL,
>  };
>  
> +static struct omap_hwmod_ocp_if *am43xx_rtc_hwmod_ocp_ifs[] __initdata = {
> +	&am33xx_l4_wkup__rtc,
> +	NULL,
> +};
> +
>  int __init am43xx_hwmod_init(void)
>  {
> +	int ret;
> +
>  	omap_hwmod_am43xx_reg();
>  	omap_hwmod_init();
> -	return omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
> +	ret = omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
> +
> +	if (!(of_machine_is_compatible("ti,am438x")))
> +		ret = omap_hwmod_register_links(am43xx_rtc_hwmod_ocp_ifs);
> +
> +	return ret;
>  }

Could you please invert the test of this case such that the RTC hwmod is 
only registered on AM43xx SoCs where it is specifically known to be 
enabled?

That way, if another AM43xx SoC comes out that doesn't have the RTC 
module, it won't inadvertently be registered.  This seems like a safer 
approach.

- Paul


From paul at pwsan.com  Wed Feb 17 22:58:52 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Thu, 18 Feb 2016 06:58:52 +0000 (UTC)
Subject: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS
In-Reply-To: <56C4DB37.9090802@ti.com>
References: <1433332284-10766-1-git-send-email-vigneshr@ti.com>
 <1433332284-10766-3-git-send-email-vigneshr@ti.com>
 <alpine.DEB.2.02.1507152029460.32764@utopia.booyaka.com>
 <55A7CE59.6010600@ti.com>
 <alpine.DEB.2.02.1508121700500.7154@utopia.booyaka.com>
 <56C4DB37.9090802@ti.com>
Message-ID: <alpine.DEB.2.02.1602180652380.4792@utopia.booyaka.com>

Hi Franklin

On Wed, 17 Feb 2016, Franklin S Cooper Jr. wrote:

> On 08/31/2015 10:51 AM, Paul Walmsley wrote:
> > On Thu, 16 Jul 2015, R, Vignesh wrote:
> >> On 07/16/2015 03:24 AM, Paul Walmsley wrote:
> >>> On Wed, 3 Jun 2015, Vignesh R wrote:
> >>>
> >>>> Add hwmod entries for the PWMSS on DRA7.
> >>>>
> >>>> Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock
> >>>> equal to L4PER2_L3_GICLK/2(l3_iclk_div/2).
> >>>> As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4,
> >>>> clock source to PWMSS is L4PER2_L3_GICLK. But it is actually
> >>>> L4PER2_L3_GICLK/2. The TRM does not show the division by 2.
> >>> Is the divide-by-two coming from PWMSS_EPWM.EPWM_TBCTL[HSPCLKDIV]?  Or is 
> >>> HSPCLKDIV a separate divider after the divide-by-2 you mention above?
> >> No, it not related to HSPCLKDIV. The TRM wrongly states L4PER2_L3_GICLK
> >> as clock input for PWMSS. But actually  L4PER2_L4_GICLK(=L3_GICLK/2) is
> >> the clock input for PWMSS. This will be updated in TRM soon.
> > OK
> >
> >>>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> >>>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> >>>> @@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
> >>>>  	},
> >>>>  };
> >>>>  
> >>>> +/* pwmss  */
> >>>> +static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
> >>>> +	.rev_offs	= 0x0,
> >>>> +	.sysc_offs	= 0x4,
> >>>> +	.sysc_flags	= SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS,
> >>> This doesn't match SPRUHZ6 Table 29-13 "PWMSS_SYSCONFIG".  There's no 
> >>> RESETSTATUS bit.  There is a SOFTRESET bit. 
> >>>
> >>> Could you please confirm whether this is intentional?
> >> sorry my bad... I will change this in v3.
> > OK
> >
> >>>> +/* ecap0 */
> >>>> +struct omap_hwmod dra7xx_ecap0_hwmod = {
> >>>> +	.name		= "ecap0",
> >>>> +	.class		= &dra7xx_ecap_hwmod_class,
> >>>> +	.clkdm_name	= "l4per2_clkdm",
> >>>> +	.main_clk	= "l4_root_clk_div",
> >>> Looking at SPRUHZ6 Section 29.1.4.2 "PWMSS Modules Local Clock Gating", 
> >>> there appears to be a local "mini-PRCM" for the PWMSS which implements 
> >>> clock gating and reports back on the status of what I'd guess is the local 
> >>> clock gating FSM.
> >>>
> >>> So from that point of view, you should probably create a clock driver that 
> >>> manages both the clock gate request bit and the FSM status bit.  It should 
> >>> be something that can be reused for the other PWMSS IP blocks.  Then 
> >>> you'd create per-IP block clock nodes and set the main_clk to point to 
> >>> that node.
> >> Since, this register is within the config space of PWMSS, the individual
> >> gating and reporting for the modules within PWMSS
> >> (PWMSS_CLKCONFIG) is currently being taken care by pwm-tipwmss.c(almost
> >> the sole function this driver is doing). It has been the same since
> >> am335x. Adding new clock nodes will result in driver changes and also
> >> changes to am335x, am437x (and other platforms) hwmod files. It also
> >> involves adding new nodes to clocks.dtsi and it will be difficult to
> >> maintain backward compatibility for older platforms. Is it not better to
> >> keep this as is, in order to maintain consistency (with am335x, am437x
> >> etc) and also that these clock bits are within IP's config space?
> > It's certainly possible that we as maintainers didn't look closely enough 
> > at the AM33xx data for the PWMSS when we merged it.  But if that's 
> > incorrect too, then now is the time to fix this.  Otherwise it will never 
> > get fixed, since each new group of people patching this code will keep 
> > punting it off to the indeterminate future.
> >
> > In terms of hwmod data: based on the register maps in sections 29.4.3, 
> > 29.3.3, and 29.2.3 of SPRUHZ6, none of these subdevices are hwmod devices.  
> > They don't support the Highlander OCP registers, they have no individual 
> > PRCM registers or register bitfields, and all of the idle and status 
> > reporting is to the PWMSS top-level IP block itself.  So it looks to me 
> > like the eCAP, eQEP, and ePWM modules should be registered via DT, rather 
> > than via hwmod.  It looks like you can get away with using the 
> > "simple-bus" abstraction, but you might ultimately have to define 
> > something custom here.  However, the PWMSS top level subsystem, described 
> > in section 29.1, does have the OCP registers, sideband signals, etc., and 
> > thus should remain a hwmod-registered device (via DT).
> >
> > In terms of the clock data: based on section 29.1.4, section 29.1.5.2, 
> > figure 29-3, and table 29-4, there are several clock gating control bits.  
> > These should be modeled as clock nodes in the Linux common clock 
> > framework.  Furthermore these registers are located inside the PWMSS 
> > subsystem itself, and are only accessible when the PWMSS IP block is 
> > functional in a PM runtime point of view: i.e., when the block is mapped 
> > into memory space, clocked and out of reset, etc.  So the clock types for 
> > the PWMSS_CFG IP block should most likely be implemented in the PWMSS 
> > driver.  I think you'll still be able to define the clock node data itself 
> > in DT, but this will probably need a closer look.  Ideally, since the 
> > clock node register address data is the same for all three subsystem 
> > instances, one would be able to simply include a DT include file three 
> > times; but the DT binding data format may ultimately make this 
> > impractical.
> >
> > In terms of the transition from the old approach to this approach, it ooks 
> > to me like the first thing to do would be to convert
> > drivers/pwm/pwm-tipwmss.c to define some clk_ops and register some clock
> > nodes with the CCF.  You've got the meat of the clock gating control code
> > there already.  Then the next thing to do would be to to get rid of
> > pwmss_submodule_state_change() and use
> > clk_{prepare,enable,disable,unprepare}*() in the drivers/pwm/pwm-ti*.c
> > subdrivers instead.  All of that looks like it should be possible to  
> > implement in a backwards-compatible way.  Then you'd convert the eCAP, 
> > eQEP, and ePWM code to probe as platform_devices, driven from a simple-bus 
> > or pwmss-bus or whatever in the DT data.  Naturally, the AM33xx/43xx data 
> > should be fixed also.  
> 
> I am working on updating this patchset on behalf of Vignesh
> based on your suggestion. During the process of converting
> the pwm-tipwmss.c to be a clock provider I discovered that
> there is an issue with the PWMSS local clock gates. For
> example on AM437x if you run the below commands you will get
> a " Custom Error: MASTER M2 (64-bit) TARGET L4_PER_0 (Read):
> Data Access in User mode during Functional access" error.
> 
> rmmod pwm_tiecap
> rmmod pwm_bl
> rmmod pwm_tiecap
> modprobe pwm_tiecap
> modprobe pwm_bl
> 
> Full Log: http://pastebin.com/sEyy52HV
> 
> On device powerup, the various PWMSS local clock gates are
> "unlocked". The remove call in the ecap driver gates the
> local PWMSS clock gate for the ecap. The probe of the ecap
> driver "unlocks" the clock gate for the ecap. However, once
> you try to access any of the ecap registers which is
> indirectly accessed by the pwm_bl driver you will get an
> error. This is because the ecap clock is still being gated.

OK I'm not sure I understand what's going on, particularly the part about 
locking and unlocking.  Are you saying that the pwm_bl driver calls into 
the pwm_tiecap module to write to the PWMSS_CLKCONFIG registers to ungate 
the ECAP clock, and then the hardware silently ignores the write?  If 
that's the case, shouldn't we be seeing some warning messages from a 
failure to ungate the clock from a subsequent PWMSS_CLKSTATUS poll?  Or am 
I misunderstanding what's going on here?

> This has been verified by hardware folks on our side. Its
> been determined these registers are not needed since they
> were designed for devices that didn't have a PRCM.
> Therefore, the current plan is to update the trms of
> AM335x,AM437x,DRA7 and AM57x to make it clear that these
> registers shouldn't be touched.

OK 

> I plan on sending a patch for the pwm-tipwmss.c driver
> essentially removing anything that touches the
> PWMSS_CLKCONFIG and PWMSS_CLKSTATUS registers. I will also
> be sending a v3 version of this patch since I believe the
> struct omap_hwmod dra7xx_ecap0_hwmod and similar entries you
> had comments about before are ok to leave as is based on the
> above findings.

Including the comments regarding dra7xx_epwmss_sysc ?  


- Paul


From Sanjeev_Sharma at mentor.com  Wed Feb 17 23:17:41 2016
From: Sanjeev_Sharma at mentor.com (Sharma, Sanjeev)
Date: Thu, 18 Feb 2016 07:17:41 +0000
Subject: [PATCH] PCI: imx6:don't sleep in atomic context
In-Reply-To: <20160106220430.GC16231@localhost>
References: <1447066080-5859-1-git-send-email-sanjeev_sharma@mentor.com>
 <20160106220430.GC16231@localhost>
Message-ID: <FDC088D3B5555644AE135ED28A7ABDE986504C90@EU-MBX-04.mgc.mentorg.com>

-----Original Message-----
From: Bjorn Helgaas [mailto:helgaas at kernel.org] 
Sent: Thursday, January 07, 2016 3:35 AM
To: Sharma, Sanjeev
Cc: Richard.Zhu at freescale.com; l.stach at pengutronix.de; bhelgaas at google.com; linux-pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; David Mueller
Subject: Re: [PATCH] PCI: imx6:don't sleep in atomic context

Hi Sanjeev,

On Mon, Nov 09, 2015 at 04:18:00PM +0530, Sanjeev Sharma wrote:
> If additional PCIe switch get connected between the host and the 
> NIC,the kernel crashes with "BUG:
> scheduling while atomic". To handle this we need to call mdelay() 
> instead of usleep_range().
> 
> For more detail please refer bugzilla.kernel.org, Bug
> 100031
> 
> Signed-off-by: Sanjeev Sharma <sanjeev_sharma at mentor.com>
> Signed-off-by: David Mueller <dave.mueller at gmx.ch>

I'm dropping this for now because we've been kicking around the same solution (with tweaks to the mdelay amount) since June, but no progress on the *real* issue, which is that imx6_pcie_link_up() should never wait; it should simply return the link status.

I'm pretty sure the amount of time I've spent looking into this would have been enough to make some progress on that underlying issue.

Bjorn

Ok ! please share the change you are planning to implement. 

Sanjeev Sharma 
> ---
>  drivers/pci/host/pci-imx6.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c 
> index 233a196..9769b13 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -499,7 +499,7 @@ static int imx6_pcie_link_up(struct pcie_port *pp)
>  		 * Wait a little bit, then re-check if the link finished
>  		 * the training.
>  		 */
> -		usleep_range(1000, 2000);
> +		mdelay(1000);
>  	}
>  	/*
>  	 * From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
> --
> 1.7.11.7
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" 
> in the body of a message to majordomo at vger.kernel.org More majordomo 
> info at  http://vger.kernel.org/majordomo-info.html


From jszhang at marvell.com  Wed Feb 17 23:15:21 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Thu, 18 Feb 2016 15:15:21 +0800
Subject: [PATCH] ARM64: Don't set the default console to ttyAMA0
In-Reply-To: <1455727422-10733-1-git-send-email-jonathanh@nvidia.com>
References: <1455727422-10733-1-git-send-email-jonathanh@nvidia.com>
Message-ID: <20160218151521.66e0cbf7@xhacker>

Dear Jon,

On Wed, 17 Feb 2016 16:43:42 +0000 Jon Hunter wrote:

> When booting Tegra210 with a minimal rootfs it may not be necessary to
> specify any boot parameters via the kernel command line as information
> for console is described via the "stdout-path" node the device-tree
> blob. However, when there are no boot parameter specified, no output is
> seen on the console in the case of Tegra210 and this is because the
> default command line in the ARM64 defconfig specifies the console as
> ttyAMA0 which takes precedence over the "stdout-path" node from
> device-tree.
> 
> ttyAMAx is used for AMBA PL011 serial ports, but not all ARM64 platforms
> use this serial driver. Therefore, remove the default command line
> entry from the ARM64 defconfig to ensure that ttyAMA0 does not get set
> as the default console if no kernel command line is specified.
> 
> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>

We need this patch as well. Thanks

Tested-by: Jisheng Zhang <jszhang at marvell.com>

> ---
>  arch/arm64/configs/defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index d21631760ec7..caecb66188be 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -64,7 +64,6 @@ CONFIG_KSM=y
>  CONFIG_TRANSPARENT_HUGEPAGE=y
>  CONFIG_CMA=y
>  CONFIG_XEN=y
> -CONFIG_CMDLINE="console=ttyAMA0"
>  # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
>  CONFIG_COMPAT=y
>  CONFIG_CPU_IDLE=y



From a0393675 at ti.com  Wed Feb 17 23:45:25 2016
From: a0393675 at ti.com (Keerthy)
Date: Thu, 18 Feb 2016 13:15:25 +0530
Subject: [PATCH 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod
In-Reply-To: <alpine.DEB.2.02.1602180634120.4792@utopia.booyaka.com>
References: <1455773381-11839-1-git-send-email-j-keerthy@ti.com>
 <1455773381-11839-3-git-send-email-j-keerthy@ti.com>
 <alpine.DEB.2.02.1602180634120.4792@utopia.booyaka.com>
Message-ID: <56C57695.3010300@ti.com>

Hi Paul,

On Thursday 18 February 2016 12:12 PM, Paul Walmsley wrote:
> Hi Keerthy
>
> On Thu, 18 Feb 2016, Keerthy wrote:
>
>> The patch adds rtc hwmod. RTC module The RTC module is physically
>> present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently
>> disabled. A secure RTC is used instead on these devices, where needed.
>> . Hence adding it selectively using a seprate list to get RTC Module
>> functional on the other am43x SoCs used on am437x-gp-evm and
>> am437x-sk-evm.
>>
>> Signed-off-by: Keerthy <j-keerthy at ti.com>
>> ---
>>
>> No Public TRM is available for AM438x SoC as of now.
>>
>>   arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +++++++++++++-
>>   1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
>> index e97a894..fcffaf8 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
>> @@ -1020,9 +1020,21 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
>>   	NULL,
>>   };
>>
>> +static struct omap_hwmod_ocp_if *am43xx_rtc_hwmod_ocp_ifs[] __initdata = {
>> +	&am33xx_l4_wkup__rtc,
>> +	NULL,
>> +};
>> +
>>   int __init am43xx_hwmod_init(void)
>>   {
>> +	int ret;
>> +
>>   	omap_hwmod_am43xx_reg();
>>   	omap_hwmod_init();
>> -	return omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
>> +	ret = omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
>> +
>> +	if (!(of_machine_is_compatible("ti,am438x")))
>> +		ret = omap_hwmod_register_links(am43xx_rtc_hwmod_ocp_ifs);
>> +
>> +	return ret;
>>   }
>
> Could you please invert the test of this case such that the RTC hwmod is
> only registered on AM43xx SoCs where it is specifically known to be
> enabled?
>
> That way, if another AM43xx SoC comes out that doesn't have the RTC
> module, it won't inadvertently be registered.  This seems like a safer
> approach.

I get your point but currently only am438x SoC has RTC disabled forever.
So i checked negating am438x. I can add a check with am4372 here and 
register for only those SoCs.

I will resend a v2 in a while.

Thanks for the quick response.

Best Regards,
Keerthy

>
> - Paul
>


From ohad at wizery.com  Wed Feb 17 23:48:45 2016
From: ohad at wizery.com (Ohad Ben-Cohen)
Date: Thu, 18 Feb 2016 09:48:45 +0200
Subject: [PATCH] MAINTAINERS: Add co-maintainer for remoteproc subsystems
In-Reply-To: <1455413719-22412-1-git-send-email-bjorn.andersson@linaro.org>
References: <1455413719-22412-1-git-send-email-bjorn.andersson@linaro.org>
Message-ID: <CAK=WgbYCkpGYi6T3OnQTy+CewALFQXTkXKf+sagr7ZVJdAjs=A@mail.gmail.com>

On Sun, Feb 14, 2016 at 3:35 AM, Bjorn Andersson
<bjorn.andersson at linaro.org> wrote:
>
> Add myself as co-maintainer for the remote processor related subsystems,
> as agreed with Ohad.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson at linaro.org>

Thank you Bjorn for the help!

Acked-by: Ohad Ben-Cohen <ohad at wizery.com>

> ---
>  MAINTAINERS | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4ebe2e886d36..f51056b02fcd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4989,6 +4989,7 @@ F:        include/linux/hw_random.h
>
>  HARDWARE SPINLOCK CORE
>  M:     Ohad Ben-Cohen <ohad at wizery.com>
> +M:     Bjorn Andersson <bjorn.andersson at linaro.org>
>  S:     Maintained
>  T:     git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
>  F:     Documentation/hwspinlock.txt
> @@ -9170,6 +9171,7 @@ F:        include/linux/regmap.h
>
>  REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM
>  M:     Ohad Ben-Cohen <ohad at wizery.com>
> +M:     Bjorn Andersson <bjorn.andersson at linaro.org>
>  T:     git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
>  S:     Maintained
>  F:     drivers/remoteproc/
> @@ -9178,6 +9180,7 @@ F:        include/linux/remoteproc.h
>
>  REMOTE PROCESSOR MESSAGING (RPMSG) SUBSYSTEM
>  M:     Ohad Ben-Cohen <ohad at wizery.com>
> +M:     Bjorn Andersson <bjorn.andersson at linaro.org>
>  T:     git git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git
>  S:     Maintained
>  F:     drivers/rpmsg/
> --
> 2.5.0
>


From ykk at rock-chips.com  Wed Feb 17 23:55:00 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Thu, 18 Feb 2016 15:55:00 +0800
Subject: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver
In-Reply-To: <56C560B2.6020208@rock-chips.com>
References: <1454049768-30872-1-git-send-email-ykk@rock-chips.com>
 <56C560B2.6020208@rock-chips.com>
Message-ID: <56C578D4.30108@rock-chips.com>

Hi Mark,

Thanks for your apply ;)

- Yakir

On 02/18/2016 02:12 PM, Mark yao wrote:
> On 2016?01?29? 14:42, Yakir Yang wrote:
>> Here are a brief introduction to Innosilicon HDMI IP:
>>    - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant 
>> transmitter
>>    - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec
>>    - Digital video interface supports a pixel size of 24, 30, 36, 
>> 48bits color depth in RGB
>>    - S/PDIF output supports PCM, Dolby Digital, DTS digital audio 
>> transmission
>>      (32-192kHz Fs) using IEC60958 and IEC 61937
>>    - The EDID and CEC function are also supported by Innosilicon HDMI 
>> Transmitter Controlle
>>
>> Changes in v8:
>> - Don't check whether encoder output format is RGB colorspace, cause 
>> driver
>>    default configure the output colorspace to RGB. (ZhengYang)
>> - Correct the check condition in inno_hdmi_config_video_csc() 
>> (ZhengYang)
>>      - if (data->enc_out_format == data->enc_out_format) {
>>      + if (data->enc_in_format == data->enc_out_format) {
>>
>> Changes in v7:
>> - Correct the module licnese statement (Paul)
>>       - MODULE_LICENSE("GPL");
>>       + MODULE_LICENSE("GPLv2");
>> - Start indentation with tabs and fix the misspell in Kconfig (Paul)
>> - Carry the lost device-binding document (Heiko)
>>
>> Changes in v6:
>> - Rebase the Makefile/Kconfig files which add by Chris's 
>> rockchip-mipi driver (Caeser)
>>
>> Changes in v5:
>> - Use hdmi_infoframe helper functions to packed the infoframe (Russell)
>> - Remove the unused double wait_for_completion_timeout for ddc 
>> transfer (Russell)
>> - Remove the unused local variable in "inno_hdmi_i2c_write()" 
>> function (Russell)
>>
>> Changes in v4:
>> - Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
>> - Correct the "DKMS" to "DPMS" (Mark)
>> - Fix over 80 characters problems (Mark)
>> - Remove encoder .prepare/.commit helper functions, and move the vop 
>> mode
>> configure function into encoder .enable helper functions. (Mark)
>>
>> Changes in v3:
>> - Use encoder enable/disable function, and remove the encoder DPMS 
>> function
>> - Keep HDMI PLL power on in standby mode
>>
>> Changes in v2:
>> - Using DRM atomic helper functions for connector init (Mark)
>> - Remove "hdmi->connector.encoder = encoder;" (Mark)
>> - Add the Acked-by tags from Rob
>> - Correct the misspell "rk3036-dw-hdmi" (Heiko)
>>
>> Yakir Yang (2):
>>    drm/rockchip: hdmi: add Innosilicon HDMI support
>>    dt-bindings: add document for Innosilicon HDMI on Rockchip platform
>>
>>   .../display/rockchip/inno_hdmi-rockchip.txt        |  50 ++
>>   drivers/gpu/drm/rockchip/Kconfig                   |   8 +
>>   drivers/gpu/drm/rockchip/Makefile                  |   1 +
>>   drivers/gpu/drm/rockchip/inno_hdmi.c               | 939 
>> +++++++++++++++++++++
>>   drivers/gpu/drm/rockchip/inno_hdmi.h               | 362 ++++++++
>>   5 files changed, 1360 insertions(+)
>>   create mode 100644 
>> Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
>>   create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
>>   create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h
>>
>
> Applied to my branch :-) .
>
> Thanks.
>




From michal.simek at xilinx.com  Wed Feb 17 23:57:20 2016
From: michal.simek at xilinx.com (Michal Simek)
Date: Thu, 18 Feb 2016 08:57:20 +0100
Subject: [PATCH v2] serial: xuartps: Enable OF earlycon support
Message-ID: <09f2c419994281fca7968142e52d969542370d1c.1455782238.git.michal.simek@xilinx.com>

Support early console setup via DT for all listed compatible strings.
Remove EARLYCON_DECLARE which was done by:
"Use common framework for earlycon declarations"
(sha1: 2eaa790989e03900298ad24f77f1086dbbc1aebd)
when OF_EARLYCON_DECLARE is defined.

Signed-off-by: Michal Simek <michal.simek at xilinx.com>
---

Changes in v2:
- Separate serial patch from others
- Remove EARLYCON_DECLARE and use the same earlycon name with different
  compatible string as was pointed by Peter Hurley
- Extend commit message

 drivers/tty/serial/xilinx_uartps.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index 131a3117fbbb..cd46e64c4255 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1077,7 +1077,9 @@ static int __init cdns_early_console_setup(struct earlycon_device *device,
 
 	return 0;
 }
-EARLYCON_DECLARE(cdns, cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "xlnx,xuartps", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p8", cdns_early_console_setup);
+OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p12", cdns_early_console_setup);
 
 /**
  * cdns_uart_console_write - perform write operation
-- 
1.9.1



From michal.simek at xilinx.com  Thu Feb 18 00:01:36 2016
From: michal.simek at xilinx.com (Michal Simek)
Date: Thu, 18 Feb 2016 09:01:36 +0100
Subject: [PATCH 2/3] serial: xuartps: Enable OF earlycon support
In-Reply-To: <56C34F65.1040506@hurleysoftware.com>
References: <67c9013fc61f53515934b54847a05df8b8e1504a.1455552315.git.michal.simek@xilinx.com>
 <23ab10a19b21df2ef17a5bb6ce2a70d2d3fd3551.1455552315.git.michal.simek@xilinx.com>
 <56C34F65.1040506@hurleysoftware.com>
Message-ID: <56C57A60.4070600@xilinx.com>

Hi Peter,

On 16.2.2016 17:33, Peter Hurley wrote:
> Hi Michal,
> 
> On 02/15/2016 08:05 AM, Michal Simek wrote:
>> Support early console setup via DT for all listed compatible strings.
>>
>> Signed-off-by: Michal Simek <michal.simek at xilinx.com>
>> ---
>>
>>  drivers/tty/serial/xilinx_uartps.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
>> index 009e0dbc12d2..6f5657766815 100644
>> --- a/drivers/tty/serial/xilinx_uartps.c
>> +++ b/drivers/tty/serial/xilinx_uartps.c
>> @@ -1094,6 +1094,9 @@ static int __init cdns_early_console_setup(struct earlycon_device *device,
>>  	return 0;
>>  }
>>  EARLYCON_DECLARE(cdns, cdns_early_console_setup);
>> +OF_EARLYCON_DECLARE(cdns_a, "xlnx,xuartps", cdns_early_console_setup);
>> +OF_EARLYCON_DECLARE(cdns_b, "cdns,uart-r1p8", cdns_early_console_setup);
>> +OF_EARLYCON_DECLARE(cdns_c, "cdns,uart-r1p12", cdns_early_console_setup);
> 
> Earlycon now shares a common framework in linux-next.
> 
> The EARLYCON_DECLARE() can be deleted and the OF_EARLYCON_DECLARE()
> can all share the same earlycon name. iow,
> 
> -EARLYCON_DECLARE(cdns, cdns_early_console_setup);
> +OF_EARLYCON_DECLARE(cdns, "xlnx,xuartps", cdns_early_console_setup);
> +OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p8", cdns_early_console_setup);
> +OF_EARLYCON_DECLARE(cdns, "cdns,uart-r1p12", cdns_early_console_setup);

I have sent v2 and I have tested it. All looks good. Thanks for pointing
me to that change.
BTW: Is it normal that when earlycon support is enabled that the bootlog
is copied again? All what was printed before bootconsole [xxx] disabled
is printed twice. Or is this just bug in our driver?

Thanks,
Michal




From ard.biesheuvel at linaro.org  Thu Feb 18 00:06:36 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 18 Feb 2016 09:06:36 +0100
Subject: KASAN issues with idle / hotplug area (was: Re: [PATCH v5sub1
 7/8] arm64: move kernel image to base of vmalloc area)
In-Reply-To: <20160217191643.GK32647@leverpostej>
References: <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
 <20160217170110.GE32647@leverpostej>
 <20160217175656.GJ32647@leverpostej>
 <20160217191643.GK32647@leverpostej>
Message-ID: <CAKv+Gu8t6FBeK5FgEcXrDBtJn-9rht=ocZCO0ZAKa887te0veg@mail.gmail.com>

On 17 February 2016 at 20:16, Mark Rutland <mark.rutland at arm.com> wrote:
> On Wed, Feb 17, 2016 at 05:56:56PM +0000, Mark Rutland wrote:
>> On Wed, Feb 17, 2016 at 05:01:11PM +0000, Mark Rutland wrote:
>> > On Wed, Feb 17, 2016 at 02:39:51PM +0000, Mark Rutland wrote:
>> > > Perhaps the simplest option is to not instrument invoke_psci_fn_* and
>> > > psci_suspend_finisher. Do we have a per-function annotation to avoid
>> > > KASAN instrumentation, like notrace? I need to investigate, but we may
>> > > also need notrace for similar reasons.
>> >
>> > I came up with the patch below, per the reasoning above.
>> >
>> > It _changes_ the KASAN splats (I see errors in tick_program_event rather
>> > than find_busiest_group), but doesn't seem to get rid of them. I'm not
>> > sure if I've missed something, or if we also have another latent issue.
>> >
>> > Ideas?
>>
>> I'd missed annotating __cpu_suspend_save. I've fixed that up locally
>> (along with s/virt_to_phys/__virt_to_phys due to the inlining issue).
>
> Thinking about it more, I shouldn't have to annotate __cpu_suspend_save,
> as it returns (and hence should have cleaned up after itself).
>
> Looking at the assembly, functions seem to get instrumented regardless
> of the __no_sanitize_address annotation. The assembly of
> __invoke_psci_fn_{smc,hvc} look identical, even if one has the
> annotation and one does not.
>
> In the case below, it looks like __invoke_psci_fn_hvc is storing to the
> shadow area even though it's anotated with __no_sanitize_address.  Note
> that the adrp symbol resolution is bogus; psci_to_linux_errno happens to
> be at offset 0 in the as-yet unlinked psci.o object.
>
> 0000000000000420 <__invoke_psci_fn_hvc>:
>  420:   d10283ff        sub     sp, sp, #0xa0
>  424:   90000004        adrp    x4, 0 <psci_to_linux_errno>
>  428:   91000084        add     x4, x4, #0x0
>  42c:   90000005        adrp    x5, 0 <psci_to_linux_errno>
>  430:   910000a5        add     x5, x5, #0x0
>  434:   d2800007        mov     x7, #0x0                        // #0
>  438:   a9017bfd        stp     x29, x30, [sp,#16]
>  43c:   910043fd        add     x29, sp, #0x10
>  440:   d2800006        mov     x6, #0x0                        // #0
>  444:   a90253f3        stp     x19, x20, [sp,#32]
>  448:   9100c3b3        add     x19, x29, #0x30
>  44c:   d2dff214        mov     x20, #0xff9000000000            // #280993940373504
>  450:   a90393a5        stp     x5, x4, [x29,#56]
>  454:   f2fbfff4        movk    x20, #0xdfff, lsl #48
>  458:   d343fe73        lsr     x19, x19, #3
>  45c:   d2915664        mov     x4, #0x8ab3                     // #35507
>  460:   f9001bf5        str     x21, [sp,#48]
>  464:   f2a836a4        movk    x4, #0x41b5, lsl #16
>  468:   8b140275        add     x21, x19, x20
>  46c:   f9001ba4        str     x4, [x29,#48]
>  470:   3204d3e4        mov     w4, #0xf1f1f1f1                 // #-235802127
>  474:   b8346a64        str     w4, [x19,x20]
>  478:   3204d7e4        mov     w4, #0xf3f3f3f3                 // #-202116109
>  47c:   b9000aa4        str     w4, [x21,#8]
>  480:   910143a4        add     x4, x29, #0x50
>  484:   d2800005        mov     x5, #0x0                        // #0
>  488:   f90003e4        str     x4, [sp]
>  48c:   d2800004        mov     x4, #0x0                        // #0
>  490:   94000000        bl      0 <arm_smccc_hvc>
>  494:   f9402ba0        ldr     x0, [x29,#80]
>  498:   910003bf        mov     sp, x29
>  49c:   b8346a7f        str     wzr, [x19,x20]
>  4a0:   b9000abf        str     wzr, [x21,#8]
>  4a4:   a94153f3        ldp     x19, x20, [sp,#16]
>  4a8:   f94013f5        ldr     x21, [sp,#32]
>  4ac:   a8c97bfd        ldp     x29, x30, [sp],#144
>  4b0:   d65f03c0        ret
>  4b4:   d503201f        nop
>
> For comparison, without KASAN __incoke_psci_fn_hvc looks like:
>
> 0000000000000280 <__invoke_psci_fn_hvc>:
>  280:   d10103ff        sub     sp, sp, #0x40
>  284:   d2800007        mov     x7, #0x0                        // #0
>  288:   d2800006        mov     x6, #0x0                        // #0
>  28c:   d2800005        mov     x5, #0x0                        // #0
>  290:   a9017bfd        stp     x29, x30, [sp,#16]
>  294:   910043fd        add     x29, sp, #0x10
>  298:   910043a4        add     x4, x29, #0x10
>  29c:   f90003e4        str     x4, [sp]
>  2a0:   d2800004        mov     x4, #0x0                        // #0
>  2a4:   94000000        bl      0 <arm_smccc_hvc>
>  2a8:   910003bf        mov     sp, x29
>  2ac:   f9400ba0        ldr     x0, [x29,#16]
>  2b0:   a8c37bfd        ldp     x29, x30, [sp],#48
>  2b4:   d65f03c0        ret
>
> I also tried using __attribute__((no_sanitize_address)) directly, in
> case there was some header issue, but that doesn't seem to be the case.
>
> I'm using the Linaro 15.08 AArch64 GCC 5.1. Is anyone else able to
> confirm whether they see the same? Does the same happen for x86?
>

I am seeing the same problem with  GCC 5.2.1. Replacing the attribute with

__attribute__((optimize("-fno-sanitize=address")))

works, but appears to affect the whole object file, not just the
function to which it is attached.


From mcoquelin.stm32 at gmail.com  Thu Feb 18 00:19:47 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Thu, 18 Feb 2016 09:19:47 +0100
Subject: [PATCH 0/3] ARM: stm32: Introduce support for STM32F469
In-Reply-To: <1455632221-31834-1-git-send-email-lee.jones@linaro.org>
References: <1455632221-31834-1-git-send-email-lee.jones@linaro.org>
Message-ID: <56C57EA3.4030506@gmail.com>

Hi Lee,

On 02/16/2016 03:16 PM, Lee Jones wrote:
> Simple set using the STM32F429 infrastructure as a foundation.
> There will be more changes to the DTS files and a requirement for
> added hierarchical layering as more differences become apparent.
>
> Lee Jones (3):
>    ARM: stm32: Supply a DTS file for the STM32F469 Discovery board
>    ARM: configs: Add new config fragment to change RAM start point
>    ARM: stm32: Identify a new board - STM32F469
>
>   arch/arm/boot/dts/Makefile              |  1 +
>   arch/arm/boot/dts/stm32f469-disco.dts   | 75 +++++++++++++++++++++++++++++++++
>   arch/arm/configs/dram_0x00000000.config |  1 +
>   arch/arm/mach-stm32/board-dt.c          |  1 +
>   4 files changed, 78 insertions(+)
>   create mode 100644 arch/arm/boot/dts/stm32f469-disco.dts
>   create mode 100644 arch/arm/configs/dram_0x00000000.config
>
Series applied to my tree for v4.6.

Thanks!
Maxime


From aryabinin at virtuozzo.com  Thu Feb 18 00:22:24 2016
From: aryabinin at virtuozzo.com (Andrey Ryabinin)
Date: Thu, 18 Feb 2016 11:22:24 +0300
Subject: KASAN issues with idle / hotplug area
In-Reply-To: <20160217191643.GK32647@leverpostej>
References: <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
 <20160217170110.GE32647@leverpostej> <20160217175656.GJ32647@leverpostej>
 <20160217191643.GK32647@leverpostej>
Message-ID: <56C57F40.3050500@virtuozzo.com>



On 02/17/2016 10:16 PM, Mark Rutland wrote:
> On Wed, Feb 17, 2016 at 05:56:56PM +0000, Mark Rutland wrote:
>> On Wed, Feb 17, 2016 at 05:01:11PM +0000, Mark Rutland wrote:
>>> On Wed, Feb 17, 2016 at 02:39:51PM +0000, Mark Rutland wrote:
>>>> Perhaps the simplest option is to not instrument invoke_psci_fn_* and
>>>> psci_suspend_finisher. Do we have a per-function annotation to avoid
>>>> KASAN instrumentation, like notrace? I need to investigate, but we may
>>>> also need notrace for similar reasons.
>>>
>>> I came up with the patch below, per the reasoning above.
>>>
>>> It _changes_ the KASAN splats (I see errors in tick_program_event rather
>>> than find_busiest_group), but doesn't seem to get rid of them. I'm not
>>> sure if I've missed something, or if we also have another latent issue.
>>>
>>> Ideas?
>>
>> I'd missed annotating __cpu_suspend_save. I've fixed that up locally
>> (along with s/virt_to_phys/__virt_to_phys due to the inlining issue).
> 
> Thinking about it more, I shouldn't have to annotate __cpu_suspend_save,
> as it returns (and hence should have cleaned up after itself).
> 

Right, we need to no-sanitize only functions that passed to 'cpu_suspend(arg, fn);'


> Looking at the assembly, functions seem to get instrumented regardless
> of the __no_sanitize_address annotation. The assembly of
> __invoke_psci_fn_{smc,hvc} look identical, even if one has the
> annotation and one does not.
> 
> In the case below, it looks like __invoke_psci_fn_hvc is storing to the
> shadow area even though it's anotated with __no_sanitize_address.  Note
> that the adrp symbol resolution is bogus; psci_to_linux_errno happens to
> be at offset 0 in the as-yet unlinked psci.o object.
> 

...
> I also tried using __attribute__((no_sanitize_address)) directly, in
> case there was some header issue, but that doesn't seem to be the case.
> 
> I'm using the Linaro 15.08 AArch64 GCC 5.1. Is anyone else able to
> confirm whether they see the same? Does the same happen for x86?
> 

Confirming, this happens on every GCC I have (including x86).
It seems that 'no_sanitize_address' in gcc removes only memory access checks
but it doesn't remove stack redzones.
I think this is wrong, e.g. clang removes instrumentation completely. I'll submit a bug.

But we need fix this in kernel.
I see two options here:
 * completely disable instrumentation for drivers/firmware/psci.c
 * get back to assembly implementation

> Thanks,
> Mark.
> 


From aryabinin at virtuozzo.com  Thu Feb 18 00:42:35 2016
From: aryabinin at virtuozzo.com (Andrey Ryabinin)
Date: Thu, 18 Feb 2016 11:42:35 +0300
Subject: KASAN issues with idle / hotplug area
In-Reply-To: <56C57F40.3050500@virtuozzo.com>
References: <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
 <20160217170110.GE32647@leverpostej> <20160217175656.GJ32647@leverpostej>
 <20160217191643.GK32647@leverpostej> <56C57F40.3050500@virtuozzo.com>
Message-ID: <56C583FB.6070500@virtuozzo.com>



On 02/18/2016 11:22 AM, Andrey Ryabinin wrote:
> I'll submit a bug.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69863


From zhangqing at rock-chips.com  Wed Feb 17 19:07:12 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Thu, 18 Feb 2016 11:07:12 +0800
Subject: [PATCH v2 0/6] rockchip: power-domain: fix pm domain for support
 RK3399 SoC
Message-ID: <1455764838-12928-1-git-send-email-zhangqing@rock-chips.com>

fix some idle handling
support sub-power domain
add rk3399-power.h
modify power domain for RK3399 SoC
modify document for RK3399 Soc

Elaine Zhang (6):
  rockchip: power-domain: make idle handling optional
  rockchip: power-domain: allow domains only handling idle requests
  rockchip: power-domain: add support for sub-power domains
  dt/bindings: power: add RK3399 SoCs header for power-domain
  rockchip: power-domain: Modify power domain driver for rk3399
  dt/bindings: rockchip: modify document of Rockchip power domains

 .../bindings/soc/rockchip/power_domain.txt         |  21 ++++
 drivers/soc/rockchip/pm_domains.c                  | 131 ++++++++++++++++++++-
 include/dt-bindings/power/rk3399-power.h           |  53 +++++++++
 3 files changed, 200 insertions(+), 5 deletions(-)
 create mode 100644 include/dt-bindings/power/rk3399-power.h

-- 
1.9.1




From zhangqing at rock-chips.com  Wed Feb 17 19:07:13 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Thu, 18 Feb 2016 11:07:13 +0800
Subject: [PATCH v2 1/6] rockchip: power-domain: make idle handling optional
In-Reply-To: <1455764838-12928-1-git-send-email-zhangqing@rock-chips.com>
References: <1455764838-12928-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1455764838-12928-2-git-send-email-zhangqing@rock-chips.com>

Not all new socs need to handle idle states on domain state changes,
so add the possibility to make them optional.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 drivers/soc/rockchip/pm_domains.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 6cdffb1..3dcc611 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -63,14 +63,16 @@ struct rockchip_pmu {
 };
 
 #define to_rockchip_pd(gpd) container_of(gpd, struct rockchip_pm_domain, genpd)
+#define NULL_BIT		-32
+#define OVERFLOW_MASK		32
 
 #define DOMAIN(pwr, status, req, idle, ack)	\
 {						\
 	.pwr_mask = BIT(pwr),			\
 	.status_mask = BIT(status),		\
-	.req_mask = BIT(req),			\
-	.idle_mask = BIT(idle),			\
-	.ack_mask = BIT(ack),			\
+	.req_mask = (req >= 0) ? BIT(req) : OVERFLOW_MASK,		\
+	.idle_mask = (idle >= 0) ? BIT(idle) : OVERFLOW_MASK,	\
+	.ack_mask = (ack >= 0) ? BIT(ack) : OVERFLOW_MASK,		\
 }
 
 #define DOMAIN_RK3288(pwr, status, req)		\
@@ -96,6 +98,9 @@ static int rockchip_pmu_set_idle_request(struct rockchip_pm_domain *pd,
 	struct rockchip_pmu *pmu = pd->pmu;
 	unsigned int val;
 
+	if (pd_info->req_mask >= OVERFLOW_MASK)
+		return 0;
+
 	regmap_update_bits(pmu->regmap, pmu->info->req_offset,
 			   pd_info->req_mask, idle ? -1U : 0);
 
-- 
1.9.1




From zhangqing at rock-chips.com  Wed Feb 17 19:07:15 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Thu, 18 Feb 2016 11:07:15 +0800
Subject: [PATCH v2 3/6] rockchip: power-domain: add support for sub-power
 domains
In-Reply-To: <1455764838-12928-1-git-send-email-zhangqing@rock-chips.com>
References: <1455764838-12928-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1455764838-12928-4-git-send-email-zhangqing@rock-chips.com>

This patch adds support for making one power domain a sub-domain of
other domain. This is useful for modeling power dependences,
which needs to have more than one power domain enabled to be operational.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 drivers/soc/rockchip/pm_domains.c | 54 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 350527b..8cdf1b2 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -372,6 +372,54 @@ static void rockchip_configure_pd_cnt(struct rockchip_pmu *pmu,
 	regmap_write(pmu->regmap, domain_reg_offset + 4, count);
 }
 
+static int rockchip_pm_add_subdomain(struct rockchip_pmu *pmu,
+				     struct device_node *parent)
+{
+	struct device_node *np;
+	int error;
+
+	for_each_child_of_node(parent, np) {
+		struct generic_pm_domain *child_domain, *parent_domain;
+		u32 idx = ~0;
+
+		if (of_property_read_u32(parent, "reg", &idx)) {
+			dev_err(pmu->dev,
+				"%s: failed to retrieve domain id (reg)\n",
+				parent->name);
+			of_node_put(parent);
+			return -EINVAL;
+		}
+		parent_domain = pmu->genpd_data.domains[idx];
+
+		error = rockchip_pm_add_one_domain(pmu, np);
+		if (error) {
+			dev_err(pmu->dev, "failed to handle node %s: %d\n",
+				np->name, error);
+			of_node_put(np);
+			return -ENODEV;
+		}
+
+		if (of_property_read_u32(np, "reg", &idx)) {
+			dev_err(pmu->dev,
+				"%s: failed to retrieve domain id (reg)\n",
+				np->name);
+			of_node_put(np);
+			return -EINVAL;
+		}
+		child_domain = pmu->genpd_data.domains[idx];
+
+		if (pm_genpd_add_subdomain(parent_domain, child_domain))
+			pr_warn("%s failed to add subdomain: %s\n",
+				parent_domain->name, child_domain->name);
+		else
+			pr_warn("%s add subdomain: %s\n",
+				parent_domain->name, child_domain->name);
+
+		rockchip_pm_add_subdomain(pmu, np);
+	}
+	return 0;
+}
+
 static int rockchip_pm_domain_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -437,6 +485,12 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
 				node->name, error);
 			goto err_out;
 		}
+		error = rockchip_pm_add_subdomain(pmu, node);
+		if (error < 0) {
+			dev_err(dev, "failed to handle subdomain node %s: %d\n",
+				node->name, error);
+			goto err_out;
+		}
 	}
 
 	if (error) {
-- 
1.9.1




From zhangqing at rock-chips.com  Wed Feb 17 19:07:16 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Thu, 18 Feb 2016 11:07:16 +0800
Subject: [PATCH v2 4/6] dt/bindings: power: add RK3399 SoCs header for
 power-domain
In-Reply-To: <1455764838-12928-1-git-send-email-zhangqing@rock-chips.com>
References: <1455764838-12928-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1455764838-12928-5-git-send-email-zhangqing@rock-chips.com>

According to a description from TRM, add all the power domains

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 include/dt-bindings/power/rk3399-power.h | 53 ++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3399-power.h

diff --git a/include/dt-bindings/power/rk3399-power.h b/include/dt-bindings/power/rk3399-power.h
new file mode 100644
index 0000000..69fbd67
--- /dev/null
+++ b/include/dt-bindings/power/rk3399-power.h
@@ -0,0 +1,53 @@
+#ifndef __DT_BINDINGS_POWER_RK3399_POWER_H__
+#define __DT_BINDINGS_POWER_RK3399_POWER_H__
+
+/* VD_CORE_L */
+#define RK3399_PD_A53_L0	0
+#define RK3399_PD_A53_L1	1
+#define RK3399_PD_A53_L2	2
+#define RK3399_PD_A53_L3	3
+#define RK3399_PD_SCU_L		4
+
+/* VD_CORE_B */
+#define RK3399_PD_A72_B0	5
+#define RK3399_PD_A72_B1	6
+#define RK3399_PD_SCU_B		7
+
+/* VD_CENTER */
+#define RK3399_PD_CENTER	8
+#define RK3399_PD_VCODEC	9
+#define RK3399_PD_RGA		10
+#define RK3399_PD_IEP		11
+#define RK3399_PD_VDU		12
+
+/* VD_LOGIC */
+#define RK3399_PD_PERILP	13
+#define RK3399_PD_PERIHP	14
+#define RK3399_PD_VIO		15
+#define RK3399_PD_VO		16
+#define RK3399_PD_VOPB		17
+#define RK3399_PD_VOPL		18
+#define RK3399_PD_ISP0		19
+#define RK3399_PD_ISP1		20
+#define RK3399_PD_HDCP		21
+#define RK3399_PD_TCPD0		22
+#define RK3399_PD_TCPD1		23
+#define RK3399_PD_GIC		24
+#define RK3399_PD_ALIVE		25
+#define RK3399_PD_USB3		26
+#define RK3399_PD_SD		27
+#define RK3399_PD_CCI		28
+#define RK3399_PD_CCI0		29
+#define RK3399_PD_CCI1		30
+#define RK3399_PD_GMAC		31
+#define RK3399_PD_EMMC		32
+#define RK3399_PD_EDP		33
+#define RK3399_PD_SDIOAUDIO	34
+
+/* VD_GPU */
+#define RK3399_PD_GPU		35
+
+/* VD_PMU */
+#define RK3399_PD_PMU		36
+
+#endif
-- 
1.9.1




From zhangqing at rock-chips.com  Wed Feb 17 19:07:14 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Thu, 18 Feb 2016 11:07:14 +0800
Subject: [PATCH v2 2/6] rockchip: power-domain: allow domains only handling
 idle requests
In-Reply-To: <1455764838-12928-1-git-send-email-zhangqing@rock-chips.com>
References: <1455764838-12928-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1455764838-12928-3-git-send-email-zhangqing@rock-chips.com>

On some Rockchip SoC there exist child-domains only handling their
idle state with the actual power-state handled by a parent-domain.

So allow such types of domains. For them, we can determine their
state (on/of) by checking the inverse idle-state instead.

There exist one special case if both idle as well power handling
were set as not present, but as the domain-data is defined in the
code itself, we can expect the reasonable developer to define them

So allow such types of domains. For them, we can determine their
state (on/of) by checking the inverse idle-state instead.

There exist one special case if both idle as well power handling
were set as not present, but as the domain-data is defined in the
code itself, we can expect the reasonable developer to define them
in a correct, without adding more checks.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
 drivers/soc/rockchip/pm_domains.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 3dcc611..350527b 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -68,8 +68,8 @@ struct rockchip_pmu {
 
 #define DOMAIN(pwr, status, req, idle, ack)	\
 {						\
-	.pwr_mask = BIT(pwr),			\
-	.status_mask = BIT(status),		\
+	.pwr_mask = (pwr >= 0) ? BIT(pwr) : OVERFLOW_MASK,		\
+	.status_mask = (status >= 0) ? BIT(status) : OVERFLOW_MASK,\
 	.req_mask = (req >= 0) ? BIT(req) : OVERFLOW_MASK,		\
 	.idle_mask = (idle >= 0) ? BIT(idle) : OVERFLOW_MASK,	\
 	.ack_mask = (ack >= 0) ? BIT(ack) : OVERFLOW_MASK,		\
@@ -121,6 +121,10 @@ static bool rockchip_pmu_domain_is_on(struct rockchip_pm_domain *pd)
 	struct rockchip_pmu *pmu = pd->pmu;
 	unsigned int val;
 
+	/* check idle status for idle-only domains */
+	if (pd->info->status_mask >= OVERFLOW_MASK)
+		return !rockchip_pmu_domain_is_idle(pd);
+
 	regmap_read(pmu->regmap, pmu->info->status_offset, &val);
 
 	/* 1'b0: power on, 1'b1: power off */
@@ -132,6 +136,9 @@ static void rockchip_do_pmu_set_power_domain(struct rockchip_pm_domain *pd,
 {
 	struct rockchip_pmu *pmu = pd->pmu;
 
+	if (pd->info->pwr_mask >= OVERFLOW_MASK)
+		return;
+
 	regmap_update_bits(pmu->regmap, pmu->info->pwr_offset,
 			   pd->info->pwr_mask, on ? 0 : -1U);
 
-- 
1.9.1




From zhangqing at rock-chips.com  Wed Feb 17 19:08:05 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Thu, 18 Feb 2016 11:08:05 +0800
Subject: [PATCH v2 5/6] rockchip: power-domain: Modify power domain driver for
 rk3399
Message-ID: <1455764885-12979-1-git-send-email-zhangqing@rock-chips.com>

This driver is modified to support RK3399 SoC.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 drivers/soc/rockchip/pm_domains.c | 55 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 8cdf1b2..067e655 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -19,6 +19,7 @@
 #include <linux/mfd/syscon.h>
 #include <dt-bindings/power/rk3288-power.h>
 #include <dt-bindings/power/rk3368-power.h>
+#include <dt-bindings/power/rk3399-power.h>
 
 struct rockchip_domain_info {
 	int pwr_mask;
@@ -81,6 +82,9 @@ struct rockchip_pmu {
 #define DOMAIN_RK3368(pwr, status, req)		\
 	DOMAIN(pwr, status, req, (req) + 16, req)
 
+#define DOMAIN_RK3399(pwr, status, req)                \
+	DOMAIN(pwr, status, req, req, req)
+
 static bool rockchip_pmu_domain_is_idle(struct rockchip_pm_domain *pd)
 {
 	struct rockchip_pmu *pmu = pd->pmu;
@@ -522,6 +526,36 @@ static const struct rockchip_domain_info rk3368_pm_domains[] = {
 	[RK3368_PD_GPU_1]	= DOMAIN_RK3368(17, 16, 2),
 };
 
+static const struct rockchip_domain_info rk3399_pm_domains[] = {
+	[RK3399_PD_TCPD0]       = DOMAIN_RK3399(8, 8, NULL_BIT),
+	[RK3399_PD_TCPD1]       = DOMAIN_RK3399(9, 9, NULL_BIT),
+	[RK3399_PD_CCI]         = DOMAIN_RK3399(10, 10, NULL_BIT),
+	[RK3399_PD_CCI0]        = DOMAIN_RK3399(NULL_BIT, NULL_BIT, 15),
+	[RK3399_PD_CCI1]        = DOMAIN_RK3399(NULL_BIT, NULL_BIT, 16),
+	[RK3399_PD_PERILP]      = DOMAIN_RK3399(11, 11, 1),
+	[RK3399_PD_PERIHP]      = DOMAIN_RK3399(12, 12, 2),
+	[RK3399_PD_CENTER]      = DOMAIN_RK3399(13, 13, 14),
+	[RK3399_PD_VIO]         = DOMAIN_RK3399(14, 14, 17),
+	[RK3399_PD_GPU]         = DOMAIN_RK3399(15, 15, 0),
+	[RK3399_PD_VCODEC]      = DOMAIN_RK3399(16, 16, 3),
+	[RK3399_PD_VDU]         = DOMAIN_RK3399(17, 17, 4),
+	[RK3399_PD_RGA]         = DOMAIN_RK3399(18, 18, 5),
+	[RK3399_PD_IEP]         = DOMAIN_RK3399(19, 19, 6),
+	[RK3399_PD_VO]          = DOMAIN_RK3399(20, 20, NULL_BIT),
+	[RK3399_PD_VOPB]        = DOMAIN_RK3399(NULL_BIT, NULL_BIT, 7),
+	[RK3399_PD_VOPL]        = DOMAIN_RK3399(NULL_BIT, NULL_BIT, 8),
+	[RK3399_PD_ISP0]        = DOMAIN_RK3399(22, 22, 9),
+	[RK3399_PD_ISP1]        = DOMAIN_RK3399(23, 23, 10),
+	[RK3399_PD_HDCP]        = DOMAIN_RK3399(24, 24, 11),
+	[RK3399_PD_GMAC]        = DOMAIN_RK3399(25, 25, 23),
+	[RK3399_PD_EMMC]        = DOMAIN_RK3399(26, 26, 24),
+	[RK3399_PD_USB3]        = DOMAIN_RK3399(27, 27, 12),
+	[RK3399_PD_EDP]         = DOMAIN_RK3399(28, 28, 22),
+	[RK3399_PD_GIC]         = DOMAIN_RK3399(29, 29, 27),
+	[RK3399_PD_SD]          = DOMAIN_RK3399(30, 30, 28),
+	[RK3399_PD_SDIOAUDIO]   = DOMAIN_RK3399(31, 31, 29),
+};
+
 static const struct rockchip_pmu_info rk3288_pmu = {
 	.pwr_offset = 0x08,
 	.status_offset = 0x0c,
@@ -556,6 +590,23 @@ static const struct rockchip_pmu_info rk3368_pmu = {
 	.domain_info = rk3368_pm_domains,
 };
 
+static const struct rockchip_pmu_info rk3399_pmu = {
+	.pwr_offset = 0x14,
+	.status_offset = 0x18,
+	.req_offset = 0x60,
+	.idle_offset = 0x64,
+	.ack_offset = 0x68,
+
+	.core_pwrcnt_offset = 0x9c,
+	.gpu_pwrcnt_offset = 0xa4,
+
+	.core_power_transition_time = 24,
+	.gpu_power_transition_time = 24,
+
+	.num_domains = ARRAY_SIZE(rk3399_pm_domains),
+	.domain_info = rk3399_pm_domains,
+};
+
 static const struct of_device_id rockchip_pm_domain_dt_match[] = {
 	{
 		.compatible = "rockchip,rk3288-power-controller",
@@ -565,6 +616,10 @@ static const struct of_device_id rockchip_pm_domain_dt_match[] = {
 		.compatible = "rockchip,rk3368-power-controller",
 		.data = (void *)&rk3368_pmu,
 	},
+	{
+		.compatible = "rockchip,rk3399-power-controller",
+		.data = (void *)&rk3399_pmu,
+	},
 	{ /* sentinel */ },
 };
 
-- 
1.9.1




From zhangqing at rock-chips.com  Wed Feb 17 19:08:19 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Thu, 18 Feb 2016 11:08:19 +0800
Subject: [PATCH v2 6/6] dt/bindings: rockchip: modify document of Rockchip
 power domains
Message-ID: <1455764899-13028-1-git-send-email-zhangqing@rock-chips.com>

Add binding documentation for the power domains
found on Rockchip RK3399 SoCs

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 .../bindings/soc/rockchip/power_domain.txt          | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
index 13dc6a3..c65d401 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -7,6 +7,7 @@ Required properties for power domain controller:
 - compatible: Should be one of the following.
 	"rockchip,rk3288-power-controller" - for RK3288 SoCs.
 	"rockchip,rk3368-power-controller" - for RK3368 SoCs.
+	"rockchip,rk3399-power-controller" - for RK3399 SoCs.
 - #power-domain-cells: Number of cells in a power-domain specifier.
 	Should be 1 for multiple PM domains.
 - #address-cells: Should be 1.
@@ -16,6 +17,7 @@ Required properties for power domain sub nodes:
 - reg: index of the power domain, should use macros in:
 	"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain.
 	"include/dt-bindings/power/rk3368-power.h" - for RK3368 type power domain.
+	"include/dt-bindings/power/rk3399-power.h" - for RK3399 type power domain.
 - clocks (optional): phandles to clocks which need to be enabled while power domain
 	switches state.
 
@@ -45,12 +47,25 @@ Example:
                 };
         };
 
+	power: power-controller {
+		compatible = "rockchip,rk3399-power-controller";
+		#power-domain-cells = <1>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		pd_gpu {
+			reg = <RK3399_PD_GPU>;
+			clocks = <&cru ACLK_GPU>;
+		};
+	};
+
 Node of a device using power domains must have a power-domains property,
 containing a phandle to the power device node and an index specifying which
 power domain to use.
 The index should use macros in:
 	"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain.
 	"include/dt-bindings/power/rk3368-power.h" - for rk3368 type power domain.
+	"include/dt-bindings/power/rk3399-power.h" - for rk3399 type power domain.
 
 Example of the node using power domain:
 
@@ -65,3 +80,9 @@ Example of the node using power domain:
                 power-domains = <&power RK3368_PD_GPU_1>;
                 /* ... */
         };
+
+	node {
+		/* ... */
+		power-domains = <&power RK3399_PD_GPU>;
+		/* ... */
+	};
-- 
1.9.1




From marc.zyngier at arm.com  Thu Feb 18 01:00:33 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Feb 2016 09:00:33 +0000
Subject: A gic problem about eoi
In-Reply-To: <56C5500A.2060104@huawei.com>
References: <56C5500A.2060104@huawei.com>
Message-ID: <20160218090033.289de1c3@arm.com>

On Thu, 18 Feb 2016 13:00:58 +0800
Yang Yingliang <yangyingliang at huawei.com> wrote:

Hi Yang,

> Hi, Marc
> 
> We found if hardware clear pending and active status is slower than
> software handling, the new sgi will be merged because of hardware 
> status. The new sgi will be lost.
> 
> If we add a dsb instruction after gic_write_eoir(), it can avoid this
> case happening.
> 
> Is it a right way to add a dsb instruction after gic_write_eoir()
> in current gic driver code ?

I suspect your problem is not so much the EOI, but that the read of
ICC_IAR1_EL1 doesn't propagate the Ack quickly enough, leading to the
transition from pending to active to still be in flux when the interrupt
is EOIed. This is where a DSB is required (and was missing until very
recently).

Does 1a1ebd5 ("irqchip/gic-v3: Make sure read from ICC_IAR1_EL1 is
visible on redestributor") solve your problem?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.


From jan.glauber at caviumnetworks.com  Thu Feb 18 01:13:07 2016
From: jan.glauber at caviumnetworks.com (Jan Glauber)
Date: Thu, 18 Feb 2016 10:13:07 +0100
Subject: [PATCH v3 1/5] arm64/perf: Rename Cortex A57 events
In-Reply-To: <20160215200613.GY6298@arm.com>
References: <cover.1454516082.git.jglauber@cavium.com>
 <e0ecaaaffb64cc0b2ecfd8852f718a3f1d642b5c.1454516082.git.jglauber@cavium.com>
 <20160215194037.GU6298@arm.com> <20160215200613.GY6298@arm.com>
Message-ID: <20160218091307.GA4566@hardcore>

On Mon, Feb 15, 2016 at 08:06:13PM +0000, Will Deacon wrote:
> On Mon, Feb 15, 2016 at 07:40:37PM +0000, Will Deacon wrote:
> > On Wed, Feb 03, 2016 at 06:11:56PM +0100, Jan Glauber wrote:
> > > The implemented Cortex A57 events are not A57 specific.
> > > They are recommended by ARM and can be found on other
> > > ARMv8 SOCs like Cavium ThunderX too. Therefore move
> > > these events to the common PMUv3 table.
> > 
> > I can't find anything in the architecture that suggests these event
> > numbers are necessarily portable between implementations. Am I missing
> > something?
> 
> Aha, I just noticed appendix K3.1 (silly me for missing it...).
> 
> Lemme check whether or not that mandates that those encodings can't be
> used for wildly different things.

To me it looks like we would just have duplicated code without the patch,
and at least the event types (e.g. L1D_CACHE_RD) should be identical
across implementations.

But I don't care too much, so please tell me if should drop the patch or
keep it.

thanks,
Jan

> Will


From marc.zyngier at arm.com  Thu Feb 18 01:14:32 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Feb 2016 09:14:32 +0000
Subject: no irq domain found for ... a GPIO interrupt controller
In-Reply-To: <2dc0519827dc9d210e38c498d830cd97@agner.ch>
References: <2dc0519827dc9d210e38c498d830cd97@agner.ch>
Message-ID: <20160218091432.6968b836@arm.com>

On Wed, 17 Feb 2016 15:29:22 -0800
Stefan Agner <stefan at agner.ch> wrote:

Hi Stefan,

> Hi Marc,
> 
> I get the following warning on our Vybrid based Colibri VF50 module:
> [    0.147674] irq: no irq domain found for
> /soc/aips-bus at 40000000/gpio at 4004a000 !
> 
> The device tree arch/arm/boot/dts/vf500-colibri.dtsi uses the following
> interrupt specification in a touchscreen node which seems to trigger the
> issue:
> interrupt-parent = <&gpio0>;
> interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> 
> We use other GPIO interrupts, but I guess it is a matter of
> initialization order, and the above specification seems to be parsed
> before the GPIO interrupt-controller gets created...?

That's very likely. GPIO interrupt controllers tend to be available
quite late in the boot sequence.

> 
> It seems that Rob Herring addressed a similar issue a while ago in 
> 9ec36ca ("of/irq: do irq resolution in platform_get_irq")
> 
> Is this problem known?
> 
> Currently, the device does not get any interrupts. The interrupt seems
> to be requested successfully at probe time later, so I am not sure if
> the not working device is really related to the message above....

That is what Rob's patch fixes: it ensures that the interrupt specifier
is resolved (turned into a Linux IRQ) when you call platform_get_irq.

> 
> This is a stack trace when I add a WARN_ON(1) in
> irq_create_fwspec_mapping:
> [    0.147674] irq: no irq domain found for
> /soc/aips-bus at 40000000/gpio at 4004a000 !
> [    0.147823] ------------[ cut here ]------------
> [    0.147941] WARNING: CPU: 0 PID: 1 at kernel/irq/irqdomain.c:584
> irq_create_fwspec_mapping+0xf0/0x1e4()
> [    0.148056] Modules linked in:
> [    0.148142] CPU: 0 PID: 1 Comm: swapper Not tainted
> 4.4.0-00070-g3690255-dirty #764
> [    0.148246] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
> [    0.148311] Backtrace:
> [    0.148416] [<80013498>] (dump_backtrace) from [<80013690>]
> (show_stack+0x18/0x1c)
> [    0.148521]  r7:800539f4 r6:00000248 r5:00000009 r4:00000000
> [    0.148646] [<80013678>] (show_stack) from [<8029d070>]
> (dump_stack+0x24/0x28)
> [    0.148782] [<8029d04c>] (dump_stack) from [<800219a4>]
> (warn_slowpath_common+0x88/0xb4)
> [    0.148916] [<8002191c>] (warn_slowpath_common) from [<80021a74>]
> (warn_slowpath_null+0x24/0x2c)
> [    0.149021]  r8:00000000 r7:87cf0f88 r6:87cf0f88 r5:00000000
> r4:87843ca8
> [    0.149158] [<80021a50>] (warn_slowpath_null) from [<800539f4>]
> (irq_create_fwspec_mapping+0xf0/0x1e4)
> [    0.149294] [<80053904>] (irq_create_fwspec_mapping) from
> [<80053b44>] (irq_create_of_mapping+0x5c/0x64)
> [    0.149400]  r6:87cf0f88 r5:878bb7c0 r4:00000000
> [    0.149508] [<80053ae8>] (irq_create_of_mapping) from [<8045e934>]
> (irq_of_parse_and_map+0x2c/0x34)
> [    0.149633] [<8045e908>] (irq_of_parse_and_map) from [<8045e95c>]
> (of_irq_to_resource+0x20/0xc4)
> [    0.149755] [<8045e93c>] (of_irq_to_resource) from [<8045ea44>]
> (of_irq_to_resource_table+0x44/0x54)
> [    0.149859]  r8:00000001 r7:00000001 r6:87cf0f88 r5:878bb7dc
> r4:00000000
> [    0.149990] [<8045ea00>] (of_irq_to_resource_table) from [<8045c5b0>]
> (of_device_alloc+0x114/0x184)
> [    0.150097]  r7:00000000 r6:878be800 r5:87cf0f88 r4:00000000
> [    0.150339] [<8045c49c>] (of_device_alloc) from [<8045c678>]
> (of_platform_device_create_pdata+0x58/0xd4)
> [    0.150457]  r10:00000000 r9:00000000 r8:80650628 r7:00000000
> r6:00000000 r5:87cf0f88
> [    0.150600]  r4:00000000
> [    0.150688] [<8045c620>] (of_platform_device_create_pdata) from
> [<8045c800>] (of_platform_bus_create+0xf0/0x194)
> [    0.150796]  r7:00000001 r6:00000000 r5:87cf0f88 r4:00000000
> [    0.150912] [<8045c710>] (of_platform_bus_create) from [<8045c9e0>]
> (of_platform_populate+0x64/0xc0)
> [    0.151016]  r10:00000000 r9:00000001 r8:00000000 r7:00000000
> r6:80650628 r5:87ce34f4
> [    0.151152]  r4:87cf0f88
> [    0.151244] [<8045c97c>] (of_platform_populate) from [<80806fa8>]
> (vf610_init_machine+0x24/0x2c)
> [    0.151352]  r9:807ff5ec r8:000000b0 r7:87896600 r6:80840420
> r5:80801a48 r4:80840420
> [    0.151515] [<80806f84>] (vf610_init_machine) from [<80801a70>]
> (customize_machine+0x28/0x48)
> [    0.151640] [<80801a48>] (customize_machine) from [<800095fc>]
> (do_one_initcall+0x98/0x1e0)
> [    0.151763] [<80009564>] (do_one_initcall) from [<807ffe34>]
> (kernel_init_freeable+0x13c/0x1e0)
> [    0.151867]  r10:8082b824 r9:807ff5ec r8:000000b0 r7:8086e440
> r6:8086e440 r5:00000003
> [    0.152004]  r4:80838704
> [    0.152091] [<807ffcf8>] (kernel_init_freeable) from [<805ee93c>]
> (kernel_init+0x18/0xf0)
> [    0.152197]  r10:00000000 r9:00000000 r8:00000000 r7:00000000
> r6:00000000 r5:805ee924
> [    0.152333]  r4:8086e440
> [    0.152424] [<805ee924>] (kernel_init) from [<8000f878>]
> (ret_from_fork+0x14/0x3c)
> [    0.152526]  r5:805ee924 r4:00000000
> [    0.152670] ---[ end trace c2d84d5af0139987 ]---

What your stack trace shows is that the failure occurs at boot time,
when of_platform_populate() parses the DT and creates the platform
devices. As part of this process, it tries to resolves the interrupt
specifiers, but fails to do so for this particular device, since the
corresponding irqchip and domain have not been created yet (the GPIO
controller is itself a device, while other irqchips are not).

But as long as your device driver uses platform_get_irq(), you will
force the interrupt specifier to be evaluated again, this time giving
you a valid interrupt (and provided that your GPIO driver has
initialized in the meantime - check for -EPROBE_DEFER). At some point,
we'll be able to kill the interrupt resolution from
of_platform_populate().

To summarize, your driver not working may not be related to this issue.

Hope this helps,

	M.
-- 
Jazz is not dead. It just smells funny.


From a0131933 at ti.com  Thu Feb 18 01:19:20 2016
From: a0131933 at ti.com (Lokesh Vutla)
Date: Thu, 18 Feb 2016 14:49:20 +0530
Subject: [PATCH v4 1/3] ARM: hwmod: RTC: Add lock and unlock functions
In-Reply-To: <alpine.DEB.2.02.1602180626420.4792@utopia.booyaka.com>
References: <1454650952-20154-1-git-send-email-lokeshvutla@ti.com>
 <1454650952-20154-2-git-send-email-lokeshvutla@ti.com>
 <alpine.DEB.2.02.1602072209460.2182@utopia.booyaka.com>
 <alpine.DEB.2.02.1602180626420.4792@utopia.booyaka.com>
Message-ID: <56C58C98.2040006@ti.com>

Hi Paul,


On 2/18/2016 11:57 AM, Paul Walmsley wrote:
> Hi Lokesh
>
> On Sun, 7 Feb 2016, Paul Walmsley wrote:
>
>> A few comments:
>>
>> On Fri, 5 Feb 2016, Lokesh Vutla wrote:
>>
>>> RTC IP have kicker feature which prevents spurious writes to its registers.
>>> In order to write into any of the RTC registers, KICK values has to be
>>> written to KICK registers.
>>> Introduce omap_hwmod_rtc_unlock/lock functions, which  writes into these
>>> KICK registers inorder to lock and unlock RTC registers.
>>>
>>> Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
>>> ---
>>
>> ...
>>
>>> +/**
>>> + * omap_rtc_wait_not_busy - Wait for the RTC BUSY flag
>>> + * @oh: struct omap_hwmod *
>>> + *
>>> + * For updating certain RTC registers, the MPU must wait
>>> + * for the BUSY status in OMAP_RTC_STATUS_REG to become zero.
>>> + * Once the BUSY status is zero, there is a 15-?s access
>>
>> Probably best just to write out "microseconds" or "us" here to avoid the
>> high-bit character problem.
>>
>>> + * period in which the MPU can program.
>>> + */
>>> +static void omap_rtc_wait_not_busy(struct omap_hwmod *oh)
>>> +{
>>> +	int i;
>>> +
>>> +	/* BUSY may stay active for 1/32768 second (~30 usec) */
>>> +	omap_test_timeout(omap_hwmod_read(oh, OMAP_RTC_STATUS_REG)
>>> +			  & OMAP_RTC_STATUS_REG, OMAP_RTC_MAX_READY_TIME, i);
>>
>> This test looks bogus.  Shouldn't it AND the register value with
>> OMAP_RTC_STATUS_BUSY?  Right now the code is AND-ing with 0x44, which
>> doesn't include the BUSY bit.  So I guess the tests that you mentioned in
>> the first message of the series don't cover the BUSY case?
>>
>>> +	/* now we have ~15 usec to read/write various registers */
>>> +}
>>> +
>>> +/**
>>> + * omap_hwmod_rtc_unlock - Unlock the Kicker mechanism.
>>> + * @oh: struct omap_hwmod *
>>> + *
>>> + * RTC IP have kicker feature. This prevents spurious writes to its registers.
>>> + * In order to write into any of the RTC registers, KICK values has te be
>>> + * written in respective KICK registers. This is needed for hwmod to write into
>>> + * sysconfig register.
>>> + */
>>> +void omap_hwmod_rtc_unlock(struct omap_hwmod *oh)
>>> +{
>>> +	local_irq_disable();
>>> +	omap_rtc_wait_not_busy(oh);
>>> +	omap_hwmod_write(OMAP_RTC_KICK0_VALUE, oh, OMAP_RTC_KICK0_REG);
>>> +	omap_hwmod_write(OMAP_RTC_KICK1_VALUE, oh, OMAP_RTC_KICK1_REG);
>>> +	local_irq_enable();
>>
>> Finally, could you ask the IP block maintainer to confirm the
>> interpretation that, for any STATUS_REG read where the BUSY bit is 0, that
>> we are guaranteed to have at least 15 microseconds from that point in time
>> to access the IP block?  It appears to be this way from my reading of the
>> TRM; but to me, the phrasing is not explicit.  Another interpretation
>> could be that the BUSY bit reflects the IP block's current status.  If
>> this latter case is true, then to ensure that the IP block accesses
>> complete inside the access window, we'll either need to test the BUSY bit
>> after the writes to ensure that it is still 0, and otherwise repeat the
>> busy test and writes; or we'll need to wait for a 0->1 BUSY transition
>> before we wait for a 1->0 BUSY transition.
>>
>>> +}
>>> +
>>> +/**
>>> + * omap_hwmod_rtc_lock - Lock the Kicker mechanism.
>>> + * @oh: struct omap_hwmod *
>>> + *
>>> + * RTC IP have kicker feature. This prevents spurious writes to its registers.
>>> + * Once the RTC registers are written, KICK mechanism needs to be locked,
>>> + * in order to prevent any spurious writes. This function locks back the RTC
>>> + * registers once hwmod completes its write into sysconfig register.
>>> + */
>>> +void omap_hwmod_rtc_lock(struct omap_hwmod *oh)
>>> +{
>>> +	local_irq_disable();
>>> +	omap_rtc_wait_not_busy(oh);
>>> +	omap_hwmod_write(0x0, oh, OMAP_RTC_KICK0_REG);
>>> +	omap_hwmod_write(0x0, oh, OMAP_RTC_KICK1_REG);
>>> +	local_irq_enable();
>>> +}
>
> Any update?


Sorry for the delay, I am on a vacation right now. I have already sent
a mail to the HW guys. Will update you as soon as I receive a reply
from them.

Thanks and regards,
Lokesh

>
>
> - Paul
>


From arnd at arndb.de  Thu Feb 18 01:21:48 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 10:21:48 +0100
Subject: [PATCH] staging: rtl8712: reduce stack usage
In-Reply-To: <56C52A5F.2030302@lwfinger.net>
References: <1455698012-814399-1-git-send-email-arnd@arndb.de>
 <56C52A5F.2030302@lwfinger.net>
Message-ID: <3642222.ppVDPONLa4@wuerfel>

On Wednesday 17 February 2016 20:20:15 Larry Finger wrote:
> > ---
> >   drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> As there is no reason for translate_scan() to be inlined, this patch seems 
> reasonable The largest user of stack likely comes from the line "struct iw_event 
> iwe". Changing that to a pointer, and using kalloc to acquire the space would 
> likely clear the compile message, but that would require many more changes.
> 
> Acked-by: Larry Finger <Larry.Finger at lwfinger.net>
> 
> 

Thanks!

I believe that the problem is the combination of "struct iw_event"
and the two buffers "u8 wpa_ie[255], rsn_ie[255];" and "u8 wps_ie[512];".
Just to document this better: if we ever decide to use a dynamic allocation,
I would allocate all of the above together.

	Arnd


From rnayak at codeaurora.org  Thu Feb 18 01:31:06 2016
From: rnayak at codeaurora.org (Rajendra Nayak)
Date: Thu, 18 Feb 2016 15:01:06 +0530
Subject: [PATCH] arm64: dts: msm8996: Add #power-domain-cells property
Message-ID: <1455787866-22223-1-git-send-email-rnayak@codeaurora.org>

Add #power-domain-cells property for both the gcc and mmcc
clock controller nodes as they both supports power domains (gdsc's)

Signed-off-by: Rajendra Nayak <rnayak at codeaurora.org>
---
Andy, the gdsc support patches for 8996 are pulled into clk-next.
Can you please pull the dts changes in for 4.6?

 arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 2c2736d..0506fb8 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -147,6 +147,7 @@
 			compatible = "qcom,gcc-msm8996";
 			#clock-cells = <1>;
 			#reset-cells = <1>;
+			#power-domain-cells = <1>;
 			reg = <0x300000 0x90000>;
 		};
 
@@ -251,6 +252,7 @@
 			compatible = "qcom,mmcc-msm8996";
 			#clock-cells = <1>;
 			#reset-cells = <1>;
+			#power-domain-cells = <1>;
 			reg = <0x8c0000 0x40000>;
 			assigned-clocks = <&mmcc MMPLL9_PLL>,
 					  <&mmcc MMPLL1_PLL>,
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation



From andy.gross at linaro.org  Thu Feb 18 01:32:41 2016
From: andy.gross at linaro.org (Andy Gross)
Date: Thu, 18 Feb 2016 09:32:41 +0000
Subject: [PATCH] arm64: dts: msm8996: Add #power-domain-cells property
In-Reply-To: <1455787866-22223-1-git-send-email-rnayak@codeaurora.org>
References: <1455787866-22223-1-git-send-email-rnayak@codeaurora.org>
Message-ID: <20160218093241.GA4931@hector.arm.com>

On Thu, Feb 18, 2016 at 03:01:06PM +0530, Rajendra Nayak wrote:
> Add #power-domain-cells property for both the gcc and mmcc
> clock controller nodes as they both supports power domains (gdsc's)
> 
> Signed-off-by: Rajendra Nayak <rnayak at codeaurora.org>
> ---
> Andy, the gdsc support patches for 8996 are pulled into clk-next.
> Can you please pull the dts changes in for 4.6?

Yes, I'll include it in the next pull.  Thanks!



From marc.zyngier at arm.com  Thu Feb 18 01:34:54 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Feb 2016 09:34:54 +0000
Subject: [RFC v3 02/15] vfio: expose MSI mapping requirement through
 VFIO_IOMMU_GET_INFO
In-Reply-To: <1455264797-2334-3-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
 <1455264797-2334-3-git-send-email-eric.auger@linaro.org>
Message-ID: <20160218093454.660b20c6@arm.com>

On Fri, 12 Feb 2016 08:13:04 +0000
Eric Auger <eric.auger at linaro.org> wrote:

> This patch allows the user-space to retrieve whether msi write
> transaction addresses must be mapped. This is returned through the
> VFIO_IOMMU_GET_INFO API and its new flag: VFIO_IOMMU_INFO_REQUIRE_MSI_MAP.
> 
> Signed-off-by: Bharat Bhushan <Bharat.Bhushan at freescale.com>
> Signed-off-by: Eric Auger <eric.auger at linaro.org>
> 
> ---
> 
> RFC v1 -> v1:
> - derived from
>   [RFC PATCH 3/6] vfio: Extend iommu-info to return MSIs automap state
> - renamed allow_msi_reconfig into require_msi_mapping
> - fixed VFIO_IOMMU_GET_INFO
> ---
>  drivers/vfio/vfio_iommu_type1.c | 26 ++++++++++++++++++++++++++
>  include/uapi/linux/vfio.h       |  1 +
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 6f1ea3d..c5b57e1 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -255,6 +255,29 @@ static int vaddr_get_pfn(unsigned long vaddr, int prot, unsigned long *pfn)
>  }
>  
>  /*
> + * vfio_domains_require_msi_mapping: indicates whether MSI write transaction
> + * addresses must be mapped
> + *
> + * returns true if it does
> + */
> +static bool vfio_domains_require_msi_mapping(struct vfio_iommu *iommu)
> +{
> +	struct vfio_domain *d;
> +	bool ret;
> +
> +	mutex_lock(&iommu->lock);
> +	/* All domains have same require_msi_map property, pick first */
> +	d = list_first_entry(&iommu->domain_list, struct vfio_domain, next);
> +	if (iommu_domain_get_attr(d->domain, DOMAIN_ATTR_MSI_MAPPING, NULL) < 0)
> +		ret = false;
> +	else
> +		ret = true;

nit: this could be simplified as:

ret = (iommu_domain_get_attr(d->domain, DOMAIN_ATTR_MSI_MAPPING, NULL) == 0);

> +	mutex_unlock(&iommu->lock);
> +
> +	return ret;
> +}
> +
> +/*
>   * Attempt to pin pages.  We really don't want to track all the pfns and
>   * the iommu can only map chunks of consecutive pfns anyway, so get the
>   * first page and all consecutive pages with the same locking.
> @@ -997,6 +1020,9 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
>  
>  		info.flags = VFIO_IOMMU_INFO_PGSIZES;
>  
> +		if (vfio_domains_require_msi_mapping(iommu))
> +			info.flags |= VFIO_IOMMU_INFO_REQUIRE_MSI_MAP;
> +
>  		info.iova_pgsizes = vfio_pgsize_bitmap(iommu);
>  
>  		return copy_to_user((void __user *)arg, &info, minsz);
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 7d7a4c6..43e183b 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -400,6 +400,7 @@ struct vfio_iommu_type1_info {
>  	__u32	argsz;
>  	__u32	flags;
>  #define VFIO_IOMMU_INFO_PGSIZES (1 << 0)	/* supported page sizes info */
> +#define VFIO_IOMMU_INFO_REQUIRE_MSI_MAP (1 << 1)/* MSI must be mapped */
>  	__u64	iova_pgsizes;		/* Bitmap of supported page sizes */
>  };
>  


FWIW:

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

	M.
-- 
Jazz is not dead. It just smells funny.


From aryabinin at virtuozzo.com  Thu Feb 18 01:38:09 2016
From: aryabinin at virtuozzo.com (Andrey Ryabinin)
Date: Thu, 18 Feb 2016 12:38:09 +0300
Subject: KASAN issues with idle / hotplug area
In-Reply-To: <56C57F40.3050500@virtuozzo.com>
References: <CAKv+Gu84mVP=YjbLhWoGj9AEUD8m8+Lq8kTCniCHwxJwMWaZtA@mail.gmail.com>
 <20160212152641.GK31665@e104818-lin.cambridge.arm.com>
 <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
 <20160217170110.GE32647@leverpostej> <20160217175656.GJ32647@leverpostej>
 <20160217191643.GK32647@leverpostej> <56C57F40.3050500@virtuozzo.com>
Message-ID: <56C59101.80805@virtuozzo.com>



On 02/18/2016 11:22 AM, Andrey Ryabinin wrote:

> I see two options here:
>  * completely disable instrumentation for drivers/firmware/psci.c
>  * get back to assembly implementation

One more option is to allocate struct arm_smccc_res on stack of arm_smccc_[hvc, smc](), and return res.a0
from arm_smccc_[hvc,smc]().

So it will look like this:

asmlinkage unsigned long arm_smccc_hvc(unsigned long a0, unsigned long a1,
			unsigned long a2, unsigned long a3, unsigned long a4,
			unsigned long a5, unsigned long a6, unsigned long a7);


static unsigned long __invoke_psci_fn_hvc(unsigned long function_id,
			unsigned long arg0, unsigned long arg1,
			unsigned long arg2)
{
	return arm_smccc_hvc(function_id, arg0, arg1, arg2, 0, 0, 0, 0);
}



From lorenzo.pieralisi at arm.com  Thu Feb 18 01:39:38 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 18 Feb 2016 09:39:38 +0000
Subject: KASAN issues with idle / hotplug area
In-Reply-To: <56C57F40.3050500@virtuozzo.com>
References: <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
 <20160217170110.GE32647@leverpostej>
 <20160217175656.GJ32647@leverpostej>
 <20160217191643.GK32647@leverpostej>
 <56C57F40.3050500@virtuozzo.com>
Message-ID: <20160218093938.GB12476@red-moon>

On Thu, Feb 18, 2016 at 11:22:24AM +0300, Andrey Ryabinin wrote:

[...]

> > I also tried using __attribute__((no_sanitize_address)) directly, in
> > case there was some header issue, but that doesn't seem to be the case.
> > 
> > I'm using the Linaro 15.08 AArch64 GCC 5.1. Is anyone else able to
> > confirm whether they see the same? Does the same happen for x86?
> > 
> 
> Confirming, this happens on every GCC I have (including x86).
> It seems that 'no_sanitize_address' in gcc removes only memory access checks
> but it doesn't remove stack redzones.
> I think this is wrong, e.g. clang removes instrumentation completely. I'll submit a bug.
> 
> But we need fix this in kernel.
> I see two options here:
>  * completely disable instrumentation for drivers/firmware/psci.c

We have to have a way to disable instrumentation for functions that
are used to call into FW and return via different code paths.

>  * get back to assembly implementation

No, we are certainly not reverting the SMCCC work because Kasan adds
instrumentation to C functions, that's not even an option.

Is it possible at all to implement a function to remove instrumentation
for a chunk of memory (ie resetting the shadow memory to a clean slate
for a range of stack addresses) ?

Thanks,
Lorenzo


From broonie at kernel.org  Thu Feb 18 01:41:08 2016
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Feb 2016 09:41:08 +0000
Subject: [PATCH v2 2/4] spi: rockchip: add bindings for rk3399 spi
In-Reply-To: <1455762983-29980-3-git-send-email-jay.xu@rock-chips.com>
References: <1455762983-29980-1-git-send-email-jay.xu@rock-chips.com>
 <1455762983-29980-3-git-send-email-jay.xu@rock-chips.com>
Message-ID: <20160218094108.GA7129@sirena.org.uk>

On Thu, Feb 18, 2016 at 10:36:21AM +0800, jianqun.xu wrote:

>  Documentation/devicetree/bindings/spi/spi-rockchip.txt | 1 +
>  1 file changed, 1 insertion(+)

I'd still expect to see the string in the driver.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160218/8899d408/attachment-0001.sig>

From heiko at sntech.de  Thu Feb 18 01:47:31 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Thu, 18 Feb 2016 10:47:31 +0100
Subject: [PATCH v2.1 2/4] spi: rockchip: add bindings for rk3399 spi
In-Reply-To: <20160218094108.GA7129@sirena.org.uk>
References: <1455762983-29980-1-git-send-email-jay.xu@rock-chips.com>
 <1455762983-29980-3-git-send-email-jay.xu@rock-chips.com>
 <20160218094108.GA7129@sirena.org.uk>
Message-ID: <2327512.KAqs6H56Km@phil>

From: Xu Jianqun <jay.xu at rock-chips.com>

Add devicetree bindings for Rockchip rk3399 spi which found on
Rockchip rk3399 SoCs.

Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
Hi Jianqun,
what Mark means is the following.

 Documentation/devicetree/bindings/spi/spi-rockchip.txt | 1 +
 drivers/spi/spi-rockchip.c                             | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
index 0c491bd..1b14d69 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
@@ -9,6 +9,7 @@ Required Properties:
     "rockchip,rk3066-spi" for rk3066.
     "rockchip,rk3188-spi", "rockchip,rk3066-spi" for rk3188.
     "rockchip,rk3288-spi", "rockchip,rk3066-spi" for rk3288.
+    "rockchip,rk3399-spi", "rockchip,rk3066-spi" for rk3399.
 - reg: physical base address of the controller and length of memory mapped
        region.
 - interrupts: The interrupt number to the cpu. The interrupt specifier format
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 79a8bc4..345fefd 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -868,6 +868,7 @@ static const struct of_device_id rockchip_spi_dt_match[] = {
 	{ .compatible = "rockchip,rk3066-spi", },
 	{ .compatible = "rockchip,rk3188-spi", },
 	{ .compatible = "rockchip,rk3288-spi", },
+	{ .compatible = "rockchip,rk3399-spi", },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, rockchip_spi_dt_match);
-- 
2.6.4




From jay.xu at rock-chips.com  Thu Feb 18 01:57:49 2016
From: jay.xu at rock-chips.com (Jianqun Xu)
Date: Thu, 18 Feb 2016 17:57:49 +0800
Subject: [PATCH v2.1 2/4] spi: rockchip: add bindings for rk3399 spi
In-Reply-To: <2327512.KAqs6H56Km@phil>
References: <1455762983-29980-1-git-send-email-jay.xu@rock-chips.com>
 <1455762983-29980-3-git-send-email-jay.xu@rock-chips.com>
 <20160218094108.GA7129@sirena.org.uk> <2327512.KAqs6H56Km@phil>
Message-ID: <56C5959D.3030806@rock-chips.com>

Hi Heiko

Thank you for you kindly explain, now I got your comments.

? 18/02/2016 17:47, Heiko Stuebner ??:
> From: Xu Jianqun <jay.xu at rock-chips.com>
>
> Add devicetree bindings for Rockchip rk3399 spi which found on
> Rockchip rk3399 SoCs.
>
> Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> ---
> Hi Jianqun,
> what Mark means is the following.
>
>   Documentation/devicetree/bindings/spi/spi-rockchip.txt | 1 +
>   drivers/spi/spi-rockchip.c                             | 1 +
>   2 files changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
> index 0c491bd..1b14d69 100644
> --- a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
> @@ -9,6 +9,7 @@ Required Properties:
>       "rockchip,rk3066-spi" for rk3066.
>       "rockchip,rk3188-spi", "rockchip,rk3066-spi" for rk3188.
>       "rockchip,rk3288-spi", "rockchip,rk3066-spi" for rk3288.
> +    "rockchip,rk3399-spi", "rockchip,rk3066-spi" for rk3399.
>   - reg: physical base address of the controller and length of memory mapped
>          region.
>   - interrupts: The interrupt number to the cpu. The interrupt specifier format
> diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
> index 79a8bc4..345fefd 100644
> --- a/drivers/spi/spi-rockchip.c
> +++ b/drivers/spi/spi-rockchip.c
> @@ -868,6 +868,7 @@ static const struct of_device_id rockchip_spi_dt_match[] = {
>   	{ .compatible = "rockchip,rk3066-spi", },
>   	{ .compatible = "rockchip,rk3188-spi", },
>   	{ .compatible = "rockchip,rk3288-spi", },
> +	{ .compatible = "rockchip,rk3399-spi", },
I'm a little confuse, I have upstreamed rockchip-i2s, and the i2s driver 
set the compatible like:
- compatible: should be one of the followings
    - "rockchip,rk3066-i2s": for rk3066
    - "rockchip,rk3188-i2s", "rockchip,rk3066-i2s": for rk3188
    - "rockchip,rk3288-i2s", "rockchip,rk3066-i2s": for rk3288
    - "rockchip,rk3399-i2s", "rockchip,rk3066-i2s": for rk3399
and the driver only has
static const struct of_device_id rockchip_i2s_match[] = {
	{ .compatible = "rockchip,rk3066-i2s", },
	{},
};

The spi of rk3399 as same as rk3066, rk3188, rk3288, like i2s, if they 
are keep different rules ?


>   	{ },
>   };
>   MODULE_DEVICE_TABLE(of, rockchip_spi_dt_match);
>



From m.szyprowski at samsung.com  Thu Feb 18 01:59:19 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 18 Feb 2016 10:59:19 +0100
Subject: [RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high
 load
In-Reply-To: <56C54B9B.7030105@samsung.com>
References: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
 <1455692128-28504-4-git-send-email-k.kozlowski@samsung.com>
 <CANAwSgQHiJGSYB7Qhq066Mqfskwrr_3SDQGXH-WN=Wt3SEF-QA@mail.gmail.com>
 <56C522A9.8070800@samsung.com> <20160218023622.GA2610@vireshk-i7>
 <56C54B9B.7030105@samsung.com>
Message-ID: <56C595F7.1080406@samsung.com>

Hello,

On 2016-02-18 05:42, Krzysztof Kozlowski wrote:
> On 18.02.2016 11:36, Viresh Kumar wrote:
>>> BTW, I found the issue. The order of trip points in DT:
>>> thermal_zone0/trip_point_0_hyst:5000
>>> thermal_zone0/trip_point_0_temp:50000
>>> thermal_zone0/trip_point_0_type:active
>>> thermal_zone0/trip_point_1_hyst:5000
>>> thermal_zone0/trip_point_1_temp:60000
>>> thermal_zone0/trip_point_1_type:active
>>> thermal_zone0/trip_point_2_hyst:5000
>>> thermal_zone0/trip_point_2_temp:70000
>>> thermal_zone0/trip_point_2_type:active
>>> thermal_zone0/trip_point_3_hyst:0
>>> thermal_zone0/trip_point_3_temp:120000	<---- this should be last one!
>>> thermal_zone0/trip_point_3_type:critical
>>> thermal_zone0/trip_point_4_hyst:5000
>>> thermal_zone0/trip_point_4_temp:90000
>>> thermal_zone0/trip_point_4_type:passive
>>> thermal_zone0/trip_point_5_hyst:5000
>>> thermal_zone0/trip_point_5_temp:110000
>>> thermal_zone0/trip_point_5_type:passive
>>>
>>> After fixing the order in DT, the cpu cooler starts working.
>> Ahh, nice.
> Damn, not entirely. I almost fried my Odroid (it survived 130 degrees of
> C)... The TMU supports only 4 trip points, so when I added two new trip
> points and reordered them... the last two (including critical) was not
> receiving interrupts.
>
> Polling mode is needed. I'll sent some patches soon...

Instead of polling the driver should simply use some dynamic window for
the nearest temperature ranges and reconfigure it when interrupt of occurs.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From arnd at arndb.de  Thu Feb 18 02:01:20 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 11:01:20 +0100
Subject: [PATCH v2] ARM: move __kuser_cmpxchg{32,64} into .kprobes.text
Message-ID: <1455789689-2839463-1-git-send-email-arnd@arndb.de>

When kprobes is used, most of the entry-armv.S file is put into the .kprobes.text
section rather than .text, but the kuser_cmpxchg64_fixup and kuser_cmpxchg32_fixup
code is not, which can lead to a link error when extremely large kernels get
built (typically for randconfig):

arch/arm/kernel/built-in.o: In function `__dabt_usr':
:(.kprobes.text+0x47c): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o: In function `__irq_usr':
:(.kprobes.text+0x4e4): relocation truncated to fit: R_ARM_JUMP24 against `.text'
arch/arm/kernel/built-in.o: In function `__fiq_usr':
:(.kprobes.text+0x740): relocation truncated to fit: R_ARM_JUMP24 against `.text'

This moves the two remaining functions into the same section as the rest
using a new macro suggested by Nicolas Pitre, which avoids the link error.

The current behavior has existed for many years and has not caused problems in
practice except for extreme randconfig builds, so the patch should not need to
get backported.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: b49c0f24cf67 ("[ARM] 4659/1: remove possibilities for spurious false negative with __kuser_cmpxchg")
Fixes: 785d3cd286f0 ("ARM kprobes: prevent some functions involved with kprobes from being probed")
Acked-by: Nicolas Pitre <nico at linaro.org>
---
 arch/arm/kernel/entry-armv.S | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index e2550500486d..3bc1a196cb53 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -83,11 +83,12 @@
 	.endm
 
 #ifdef CONFIG_KPROBES
-	.section	.kprobes.text,"ax",%progbits
+#define KPROBE_TEXT	.section .kprobes.text,"ax",%progbits
 #else
-	.text
+#define KPROBE_TEXT	.text
 #endif
 
+	KPROBE_TEXT
 /*
  * Invalid mode handlers
  */
@@ -895,7 +896,7 @@ __kuser_cmpxchg64:				@ 0xffff0f60
 	rsbs	r0, r3, #0			@ set return val and C flag
 	ldmfd	sp!, {r4, r5, r6, pc}
 
-	.text
+	KPROBE_TEXT
 kuser_cmpxchg64_fixup:
 	@ Called from kuser_cmpxchg_fixup.
 	@ r4 = address of interrupted insn (must be preserved).
@@ -953,7 +954,7 @@ __kuser_cmpxchg:				@ 0xffff0fc0
 	rsbs	r0, r3, #0			@ set return val and C flag
 	usr_ret	lr
 
-	.text
+	KPROBE_TEXT
 kuser_cmpxchg32_fixup:
 	@ Called from kuser_cmpxchg_check macro.
 	@ r4 = address of interrupted insn (must be preserved).
-- 
2.7.0



From jbe at pengutronix.de  Thu Feb 18 02:07:40 2016
From: jbe at pengutronix.de (Juergen Borleis)
Date: Thu, 18 Feb 2016 11:07:40 +0100
Subject: Using i.MX6 quad's IPU#1/DI#1 to drive parallel port #1 failed
In-Reply-To: <20160217155814.7f7132aa@ipc1.ka-ro>
References: <201602171210.14545.jbe@pengutronix.de>
 <201602171523.55881.jbe@pengutronix.de> <20160217155814.7f7132aa@ipc1.ka-ro>
Message-ID: <201602181107.41129.jbe@pengutronix.de>

Hi Lothar,

On Wednesday 17 February 2016 15:58:14 Lothar Wa?mann wrote:
> > thank you for your answer. Can you also send me your "pinctrl_disp1"
> > definition, please?
>
> 		pinctrl_disp1: disp1grp {
> 			fsl,pins = <
> 				MX6QDL_PAD_EIM_A16__IPU1_DI1_DISP_CLK	0x10
> 				MX6QDL_PAD_EIM_DA10__IPU1_DI1_PIN15	0x10

The "PIN15" was the key. With your definition it now works here as well.

Thank you for your help.

Regards,
Juergen


From vladimir.murzin at arm.com  Thu Feb 18 02:11:37 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Thu, 18 Feb 2016 10:11:37 +0000
Subject: [PATCH v3 09/10] ARM: dts: introduce MPS2 AN385/AN386
In-Reply-To: <7272921.u1gphgWzUn@wuerfel>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <56C349E6.2000002@arm.com> <56C4A46C.50506@arm.com>
 <7272921.u1gphgWzUn@wuerfel>
Message-ID: <56C598D9.3030001@arm.com>

On 17/02/16 16:58, Arnd Bergmann wrote:
> On Wednesday 17 February 2016 16:48:44 Vladimir Murzin wrote:
>> On 16/02/16 16:10, Vladimir Murzin wrote:
>>> On 16/02/16 11:01, Arnd Bergmann wrote:
>>>> On Tuesday 16 February 2016 10:08:14 Vladimir Murzin wrote:
>>>>> +
>>>>> +       ethernet at 40200000 {
>>>>> +               compatible = "smsc,lan9220", "smsc,lan9115";
>>>>> +               reg = <0x40200000 0x10000>;
>>>>> +               interrupts = <13>;
>>>>> +               interrupt-parent = <&nvic>;
>>>>> +               smsc,irq-active-high;
>>>>> +       };
>>>>> +};
>>>>> +
>>>>>
>>>>
>>>> This node seems slightly misplaced. Is there some external bus interface
>>>> that this is connected to? The address suggests that it should be somewhere
>>>> below the /soc node, and you probably want to list the external bus
>>>> interface with a "ranges" property that identifies the addresses visibile
>>>> there, and put the external chip under there.
>>>>
>>>
>>> I might messed it up since the MAC/PHY connects to the same 16-bit
>>> interface as the 16MB PSRAM external memory and both connected via AHB.
>>>
>>> Not sure how it should be expressed, so some help form DT camp would be
>>> appreciated.
>>
>> Does following fixup address your point on where/how ethernet node
>> should be placed?
> 
> 
> 
>> diff --git a/arch/arm/boot/dts/mps2-an385.dts b/arch/arm/boot/dts/an385.dts
>> index 976f86d..50c8d24 100644
>> --- a/arch/arm/boot/dts/mps2-an385.dts
>> +++ b/arch/arm/boot/dts/mps2-an385.dts
>> @@ -63,14 +63,10 @@
>>  		device_type = "memory";
>>  		reg = <0x21000000 0x1000000>;
>>  	};
>> +};
>>
>> -	ethernet at 40200000 {
>> -		compatible = "smsc,lan9220", "smsc,lan9115";
>> -		reg = <0x40200000 0x10000>;
>> -		interrupts = <13>;
>> -		interrupt-parent = <&nvic>;
>> -		smsc,irq-active-high;
>> -	};
>> +&mb {
>> +	ranges = <0 0x40200000 0x10000>;
>>  };
> 
> How is the range being set here? The way I read this is:
> 
> "There is an external bus controller whose single CPU physical
> address for MMIO is configurable. The chip always connects
> a lan9220 device to it (as that is in the dtsi file) and
> nothing else is possible, and the bootloader in this
> version of the machine has configured the window to be
> at address 0x40200000."
> 
> Is that what the hardware does?
> 
> I would have expected the opposite, with the external bus
> interface being hardwired to one or more physical addresses
> (more than one if you have multiple chip-selects), and
> then allow to connect different devices, which are in the
> .dts file, while the bus controller is defined in the
> .dtsi file.
> 

Right, I thought in a wrong way, in opposite it makes more sense now.

.dtsi

/* below the soc/ */
smb {
	compatible = "simple-bus";
	#address-cells = <2>;
	#size-cells = <1>;
	ranges = <0 0 0x40200000 0x10000>,
		 <1 0 0xa0000000 0x10000>;
};

.dts

smb {
	ethernet at 0,0 {
		compatible = "smsc,lan9220", "smsc,lan9115";
		reg = <0 0x0 0x10000>;
		interrupts = <13>;
		interrupt-parent = <&nvic>;
		smsc,irq-active-high;
};


and looking again at .dtsi it seems to me that fpgaio should be moved
below the soc/ under separate bus interface which would hosts audio and
spi too or I keep missing things around device-tree?

I appreciate your help on this, thanks!

Vladimir

> 	Arnd
> 
> 
> 



From matt at codeblueprint.co.uk  Thu Feb 18 02:15:01 2016
From: matt at codeblueprint.co.uk (Matt Fleming)
Date: Thu, 18 Feb 2016 10:15:01 +0000
Subject: [PATCH v5sub3 4/4] arm64: efi: invoke EFI_RNG_PROTOCOL to supply
 KASLR randomness
In-Reply-To: <1455126905-22688-5-git-send-email-ard.biesheuvel@linaro.org>
References: <1455126905-22688-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455126905-22688-5-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160218101501.GA2651@codeblueprint.co.uk>

On Wed, 10 Feb, at 06:55:05PM, Ard Biesheuvel wrote:
> Since arm64 does not use a decompressor that supplies an execution
> environment where it is feasible to some extent to provide a source of
> randomness, the arm64 KASLR kernel depends on the bootloader to supply
> some random bits in the /chosen/kaslr-seed DT property upon kernel entry.
> 
> On UEFI systems, we can use the EFI_RNG_PROTOCOL, if supplied, to obtain
> some random bits. At the same time, use it to randomize the offset of the
> kernel Image in physical memory.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
>  arch/arm64/Kconfig                        |  5 ++
>  drivers/firmware/efi/libstub/arm-stub.c   | 40 ++++++----
>  drivers/firmware/efi/libstub/arm64-stub.c | 78 ++++++++++++++------
>  drivers/firmware/efi/libstub/fdt.c        | 14 ++++
>  4 files changed, 102 insertions(+), 35 deletions(-)

Reviewed-by: Matt Fleming <matt at codeblueprint.co.uk>


From romain.izard.pro at gmail.com  Thu Feb 18 02:21:06 2016
From: romain.izard.pro at gmail.com (Romain Izard)
Date: Thu, 18 Feb 2016 11:21:06 +0100
Subject: [PATCH] ARM: dts: at91: sama5d2 Xplained: Correct the macb irq
 pinctrl node
Message-ID: <1455790866-13301-1-git-send-email-romain.izard.pro@gmail.com>

All pinctrl nodes for the Atmel pinctrl controller need to have their
bias configuration explicitly defined. Otherwise, the pinctrl mapping
is not valid.

It works for now as the pinctrl driver proceeds even with invalid
mappings, but this can become an issue, if the pinctrl driver starts
to require valid mappings. Additionally, the pin is not protected from
being remapped later by an other driver.

There is an external 1k? pull-up to 3.3V, so no bias is required on
the Ethernet PHY's interrupt line.

Signed-off-by: Romain Izard <romain.izard.pro at gmail.com>
---
 arch/arm/boot/dts/at91-sama5d2_xplained.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index e683856c507c..75341eec2dfd 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -308,6 +308,7 @@
 
 				pinctrl_macb0_phy_irq: macb0_phy_irq {
 					pinmux = <PIN_PC9__GPIO>;
+					bias-disable;
 				};
 
 				pinctrl_pdmic_default: pdmic_default {
-- 
2.5.0



From andre.przywara at arm.com  Thu Feb 18 02:25:01 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 18 Feb 2016 10:25:01 +0000
Subject: [PATCH v2 1/8] arm64: Introduce Allwinner SoC config option
In-Reply-To: <20160218113207.5ffffee2@xhacker>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
 <1455709440-8668-2-git-send-email-andre.przywara@arm.com>
 <20160218113207.5ffffee2@xhacker>
Message-ID: <56C59BFD.20609@arm.com>

Hi,

On 18/02/16 03:32, Jisheng Zhang wrote:
> Dear Andre,
> 
> On Wed, 17 Feb 2016 11:43:53 +0000
> Andre Przywara <andre.przywara at arm.com> wrote:
> 
>> To prepare for the Allwinner A64 SoC support, introduce a config
>> option to allow compiling Allwinner (aka. sunxi) specific drivers
>> for the arm64 architecture as well.
>> This patch just defines the ARCH_SUNXI symbol to allow Allwinner
>> specific drivers to be selected during kernel configuration.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>> ---
>>  arch/arm64/Kconfig.platforms | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>> index 8a09522..2f7f69b 100644
>> --- a/arch/arm64/Kconfig.platforms
>> +++ b/arch/arm64/Kconfig.platforms
>> @@ -1,5 +1,10 @@
>>  menu "Platform selection"
>>  
>> +config ARCH_SUNXI
> 
> it's better to keep ARCH_YYZZ sorted in alphabetic order

Right, I think I originally started with ARCH_ALLWINNER until I found
ARCH_SUNXI, but forgot to move it.
Actually I wonder if we should sort for the user visible config options
instead, but that's another story.

Cheers,
Andre.

> Thanks,
> Jisheng
> 
>> +	bool "Allwinner sunxi 64-bit SoC Family"
>> +	help
>> +	  This enables support for Allwinner sunxi based SoCs like the A64.
>> +
>>  config ARCH_BCM_IPROC
>>  	bool "Broadcom iProc SoC Family"
>>  	help
> 


From matt at codeblueprint.co.uk  Thu Feb 18 02:44:07 2016
From: matt at codeblueprint.co.uk (Matt Fleming)
Date: Thu, 18 Feb 2016 10:44:07 +0000
Subject: [PATCH v2 1/2] efi: esrt: use memremap not ioremap to access
 ESRT table in memory
In-Reply-To: <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160218104407.GC2651@codeblueprint.co.uk>

On Mon, 15 Feb, at 12:32:32PM, Ard Biesheuvel wrote:
> On ARM and arm64, ioremap() and memremap() are not interchangeable like
> on x86, and the use of ioremap() on ordinary RAM is typically flagged
> as an error if the memory region being mapped is also covered by the
> linear mapping, since that would lead to aliases with conflicting
> cacheability attributes.
> 
> Since what we are dealing with is not an I/O region with side effects,
> using ioremap() here is arguably incorrect anyway, so let's replace
> it with memremap instead. Also add a missing unmap on the success path,
> and drop a memblock_remove() call which does not belong here, this far
> into the boot sequence.
> 
> Cc: Peter Jones <pjones at redhat.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
>  drivers/firmware/efi/esrt.c | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 

[...]

> @@ -432,8 +434,6 @@ static int __init esrt_sysfs_init(void)
>  	if (error)
>  		goto err_cleanup_list;
>  
> -	memblock_remove(esrt_data, esrt_data_size);
> -
>  	pr_debug("esrt-sysfs: loaded.\n");
>  
>  	return 0;

Shouldn't we be replacing memblock_remove() with free_bootmem_late()?
The original ESRT region is still reserved at this point, so we should
do our best to release it to the page allocator.


From arnd at arndb.de  Thu Feb 18 02:45:12 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 11:45:12 +0100
Subject: [PATCH v3 09/10] ARM: dts: introduce MPS2 AN385/AN386
In-Reply-To: <56C598D9.3030001@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <7272921.u1gphgWzUn@wuerfel> <56C598D9.3030001@arm.com>
Message-ID: <7245560.jfhuhtPsB8@wuerfel>

On Thursday 18 February 2016 10:11:37 Vladimir Murzin wrote:
> 
> Right, I thought in a wrong way, in opposite it makes more sense now.
> 
> .dtsi
> 
> /* below the soc/ */
> smb {
>         compatible = "simple-bus";
>         #address-cells = <2>;
>         #size-cells = <1>;
>         ranges = <0 0 0x40200000 0x10000>,
>                  <1 0 0xa0000000 0x10000>;
> };

That looks good, yes.

Is 0x10000 the correct maximum addressable size of the external bus
in both cases?

Intuitively, I would guess that the 0xa0000000 range might
be much wider.

> .dts
> 
> smb {
>         ethernet at 0,0 {
>                 compatible = "smsc,lan9220", "smsc,lan9115";
>                 reg = <0 0x0 0x10000>;
>                 interrupts = <13>;
>                 interrupt-parent = <&nvic>;
>                 smsc,irq-active-high;
> };
> 
> 
> and looking again at .dtsi it seems to me that fpgaio should be moved
> below the soc/ under separate bus interface which would hosts audio and
> spi too or I keep missing things around device-tree?
> 

I don't see the audio and spi nodes, so I'm not sure where exactly
you would put them.

Ideally those things should be visible from a block diagram in the
datasheet.

	Arnd


From pageexec at freemail.hu  Thu Feb 18 02:46:42 2016
From: pageexec at freemail.hu (PaX Team)
Date: Thu, 18 Feb 2016 11:46:42 +0100
Subject: [PATCH] ARM: vdso: Mark vDSO code as read-only
In-Reply-To: <CAGXu5jJmpq_2mmTLD0VbnY1SBF5b5Rr04HKWfD1LEaGxnztFdQ@mail.gmail.com>
References: <1453226922-16831-1-git-send-email-keescook@chromium.org>,
 <20160217234306.GA59532@davidb.org>,
 <CAGXu5jJmpq_2mmTLD0VbnY1SBF5b5Rr04HKWfD1LEaGxnztFdQ@mail.gmail.com>
Message-ID: <56C5A112.25195.35DDEA@pageexec.freemail.hu>

On 17 Feb 2016 at 15:48, Kees Cook wrote:

> On Wed, Feb 17, 2016 at 3:43 PM, David Brown <david.brown at linaro.org> wrote:

> > Is there a possible future consideration to perhaps make .rodata read
> > only much earlier?
> 
> Yeah, this will likely be a future improvement. Some architectures
> already mark .rodata before the mark_rodata_ro() call. Once we start
> to have more use of postinit-readonly, I suspect we'll see more
> clarification of when those things happen.

FYI, PaX had enforced early rodata on i386 during the 2.4 series (i.e.,
decade+ ago) but i abandoned it for 2.6 due to the maintenance burden
coupled with its low benefit...



From s.hauer at pengutronix.de  Thu Feb 18 02:56:03 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Thu, 18 Feb 2016 11:56:03 +0100
Subject: [PATCH 2/3] thermal: Add Mediatek thermal controller support
In-Reply-To: <56C4A875.6080908@gmail.com>
References: <1448883753-19068-1-git-send-email-s.hauer@pengutronix.de>
 <1448883753-19068-3-git-send-email-s.hauer@pengutronix.de>
 <20151217193332.GB7999@localhost.localdomain>
 <20160104141940.GI13058@pengutronix.de>
 <20160119072917.GA13237@pengutronix.de>
 <1454295246.22151.6.camel@mtksdaap41>
 <CAGS+omD9U8tKmb02d_gMMAGX18MJZhz0RrugpBK2EuqgZrBy6g@mail.gmail.com>
 <CAGS+omArr0_-ziBXWjEcKS0bqnruNzZc2aq2s3zkghUC7_HfGw@mail.gmail.com>
 <56C4A875.6080908@gmail.com>
Message-ID: <20160218105603.GE3939@pengutronix.de>

On Wed, Feb 17, 2016 at 06:05:57PM +0100, Matthias Brugger wrote:
> 
> 
> On 15/02/16 03:14, Daniel Kurtz wrote:
> >On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz at chromium.org> wrote:
> >>Hi Eduardo, Sascha,
> >>
> >>>>Any input on this? I really like to get this driver upstream as it is
> >>>>currently blocking other Mediatek drivers.
> >>>>
> >>>
> >>>Hi Eduardo,
> >>>
> >>>Do you have any comment about Sascha's response ? We really hope get
> >>>your comment since Mediatek thermal driver already reviewed in public
> >>>over half years, and we have other patches [0] [1] depend on thermal
> >>>driver.
> >>>
> >>>[0]:
> >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> >>>[1]:
> >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
> >>
> >>Friendly ping on the Mediatek thermal driver.
> >>The "EFUSE" dependency has now landed in v4.5-rc4.
> >
> >Actually, it landed in char-misc-next, not v4.5-rc4.
> >
> >>So, AFAICT, the only thing left that may be blocking landing Mediatek
> >>thermal driver is resolution of this discussion about thermal zones.
> >>Can we kindly resolve this soon so we have a chance to land it in v4.6.
> >>
> 
> 
> I think the problem is, that Eduardo wants to see the hierachical thermal
> zones being used. But there is still a discussion ongoing [1].

It seems the original Author lost interest in the hierarchical thermal
zones. I am not convinced that we need hierarchical thermal zones for
the Mediatek driver since from the five sensors we only need the maximum
temperature (If this ever changes we could still rework it).

Given the current speed of communication I am not willing to add
another, possibly controversal, dependency to an otherwise simple
driver. I am even less willing when concerns like these come after *v12*
of this series.

Eduardo, it would really help to get a word from you.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From marc.zyngier at arm.com  Thu Feb 18 03:06:16 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Feb 2016 11:06:16 +0000
Subject: [RFC v3 07/15] iommu: iommu_get/put_single_reserved
In-Reply-To: <1455264797-2334-8-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
 <1455264797-2334-8-git-send-email-eric.auger@linaro.org>
Message-ID: <20160218110616.05108071@arm.com>

On Fri, 12 Feb 2016 08:13:09 +0000
Eric Auger <eric.auger at linaro.org> wrote:

> This patch introduces iommu_get/put_single_reserved.
> 
> iommu_get_single_reserved allows to allocate a new reserved iova page
> and map it onto the physical page that contains a given physical address.
> It returns the iova that is mapped onto the provided physical address.
> Hence the physical address passed in argument does not need to be aligned.
> 
> In case a mapping already exists between both pages, the IOVA mapped
> to the PA is directly returned.
> 
> Each time an iova is successfully returned a binding ref count is
> incremented.
> 
> iommu_put_single_reserved decrements the ref count and when this latter
> is null, the mapping is destroyed and the iova is released.

I wonder if there is a requirement for the caller to find out about the
size of the mapping, or to impose a given size... MSIs clearly do not
have that requirement (this is always a 32bit value), but since
allocations usually pair address and size, I though I'd ask...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.


From robin.murphy at arm.com  Thu Feb 18 03:09:17 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 18 Feb 2016 11:09:17 +0000
Subject: [RFC v3 05/15] iommu/arm-smmu: implement
 alloc/free_reserved_iova_domain
In-Reply-To: <1455264797-2334-6-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
 <1455264797-2334-6-git-send-email-eric.auger@linaro.org>
Message-ID: <56C5A65D.5010401@arm.com>

Hi Eric,

On 12/02/16 08:13, Eric Auger wrote:
> Implement alloc/free_reserved_iova_domain for arm-smmu. we use
> the iova allocator (iova.c). The iova_domain is attached to the
> arm_smmu_domain struct. A mutex is introduced to protect it.

The IOMMU API currently leaves IOVA management entirely up to the caller 
- VFIO is already managing its own IOVA space, so what warrants this 
being pushed all the way down to the IOMMU driver? All I see here is 
abstract code with no hardware-specific details that'll have to be 
copy-pasted into other IOMMU drivers (e.g. SMMUv3), which strongly 
suggests it's the wrong place to do it.

As I understand the problem, VFIO has a generic "configure an IOMMU to 
point at an MSI doorbell" step to do in the process of attaching a 
device, which hasn't needed implementing yet due to VT-d's 
IOMMU_CAP_I_AM_ALSO_ACTUALLY_THE_MSI_CONTROLLER_IN_DISGUISE flag, which 
most of us have managed to misinterpret so far. AFAICS all the IOMMU 
driver should need to know about this is an iommu_map() call (which will 
want a slight extension[1] to make things behave properly). We should be 
fixing the abstraction to be less x86-centric, not hacking up all the 
ARM drivers to emulate x86 hardware behaviour in software.

Robin.

[1]:http://article.gmane.org/gmane.linux.kernel.cross-arch/30833

> Signed-off-by: Eric Auger <eric.auger at linaro.org>
>
> ---
> v2 -> v3:
> - select IOMMU_IOVA when ARM_SMMU or ARM_SMMU_V3 is set
>
> v1 -> v2:
> - formerly implemented in vfio_iommu_type1
> ---
>   drivers/iommu/Kconfig    |  2 ++
>   drivers/iommu/arm-smmu.c | 87 +++++++++++++++++++++++++++++++++++++++---------
>   2 files changed, 74 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index a1e75cb..1106528 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -289,6 +289,7 @@ config ARM_SMMU
>   	bool "ARM Ltd. System MMU (SMMU) Support"
>   	depends on (ARM64 || ARM) && MMU
>   	select IOMMU_API
> +	select IOMMU_IOVA
>   	select IOMMU_IO_PGTABLE_LPAE
>   	select ARM_DMA_USE_IOMMU if ARM
>   	help
> @@ -302,6 +303,7 @@ config ARM_SMMU_V3
>   	bool "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
>   	depends on ARM64 && PCI
>   	select IOMMU_API
> +	select IOMMU_IOVA
>   	select IOMMU_IO_PGTABLE_LPAE
>   	select GENERIC_MSI_IRQ_DOMAIN
>   	help
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index c8b7e71..f42341d 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -42,6 +42,7 @@
>   #include <linux/platform_device.h>
>   #include <linux/slab.h>
>   #include <linux/spinlock.h>
> +#include <linux/iova.h>
>
>   #include <linux/amba/bus.h>
>
> @@ -347,6 +348,9 @@ struct arm_smmu_domain {
>   	enum arm_smmu_domain_stage	stage;
>   	struct mutex			init_mutex; /* Protects smmu pointer */
>   	struct iommu_domain		domain;
> +	struct iova_domain		*reserved_iova_domain;
> +	/* protects reserved domain manipulation */
> +	struct mutex			reserved_mutex;
>   };
>
>   static struct iommu_ops arm_smmu_ops;
> @@ -975,6 +979,7 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
>   		return NULL;
>
>   	mutex_init(&smmu_domain->init_mutex);
> +	mutex_init(&smmu_domain->reserved_mutex);
>   	spin_lock_init(&smmu_domain->pgtbl_lock);
>
>   	return &smmu_domain->domain;
> @@ -1446,22 +1451,74 @@ out_unlock:
>   	return ret;
>   }
>
> +static int arm_smmu_alloc_reserved_iova_domain(struct iommu_domain *domain,
> +					       dma_addr_t iova, size_t size,
> +					       unsigned long order)
> +{
> +	unsigned long granule, mask;
> +	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
> +	int ret = 0;
> +
> +	granule = 1UL << order;
> +	mask = granule - 1;
> +	if (iova & mask || (!size) || (size & mask))
> +		return -EINVAL;
> +
> +	if (smmu_domain->reserved_iova_domain)
> +		return -EEXIST;
> +
> +	mutex_lock(&smmu_domain->reserved_mutex);
> +
> +	smmu_domain->reserved_iova_domain =
> +		kzalloc(sizeof(struct iova_domain), GFP_KERNEL);
> +	if (!smmu_domain->reserved_iova_domain) {
> +		ret = -ENOMEM;
> +		goto unlock;
> +	}
> +
> +	init_iova_domain(smmu_domain->reserved_iova_domain,
> +			 granule, iova >> order, (iova + size - 1) >> order);
> +
> +unlock:
> +	mutex_unlock(&smmu_domain->reserved_mutex);
> +	return ret;
> +}
> +
> +static void arm_smmu_free_reserved_iova_domain(struct iommu_domain *domain)
> +{
> +	struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
> +	struct iova_domain *iovad = smmu_domain->reserved_iova_domain;
> +
> +	if (!iovad)
> +		return;
> +
> +	mutex_lock(&smmu_domain->reserved_mutex);
> +
> +	put_iova_domain(iovad);
> +	kfree(iovad);
> +
> +	mutex_unlock(&smmu_domain->reserved_mutex);
> +}
> +
>   static struct iommu_ops arm_smmu_ops = {
> -	.capable		= arm_smmu_capable,
> -	.domain_alloc		= arm_smmu_domain_alloc,
> -	.domain_free		= arm_smmu_domain_free,
> -	.attach_dev		= arm_smmu_attach_dev,
> -	.detach_dev		= arm_smmu_detach_dev,
> -	.map			= arm_smmu_map,
> -	.unmap			= arm_smmu_unmap,
> -	.map_sg			= default_iommu_map_sg,
> -	.iova_to_phys		= arm_smmu_iova_to_phys,
> -	.add_device		= arm_smmu_add_device,
> -	.remove_device		= arm_smmu_remove_device,
> -	.device_group		= arm_smmu_device_group,
> -	.domain_get_attr	= arm_smmu_domain_get_attr,
> -	.domain_set_attr	= arm_smmu_domain_set_attr,
> -	.pgsize_bitmap		= -1UL, /* Restricted during device attach */
> +	.capable			= arm_smmu_capable,
> +	.domain_alloc			= arm_smmu_domain_alloc,
> +	.domain_free			= arm_smmu_domain_free,
> +	.attach_dev			= arm_smmu_attach_dev,
> +	.detach_dev			= arm_smmu_detach_dev,
> +	.map				= arm_smmu_map,
> +	.unmap				= arm_smmu_unmap,
> +	.map_sg				= default_iommu_map_sg,
> +	.iova_to_phys			= arm_smmu_iova_to_phys,
> +	.add_device			= arm_smmu_add_device,
> +	.remove_device			= arm_smmu_remove_device,
> +	.device_group			= arm_smmu_device_group,
> +	.domain_get_attr		= arm_smmu_domain_get_attr,
> +	.domain_set_attr		= arm_smmu_domain_set_attr,
> +	.alloc_reserved_iova_domain	= arm_smmu_alloc_reserved_iova_domain,
> +	.free_reserved_iova_domain	= arm_smmu_free_reserved_iova_domain,
> +	/* Page size bitmap, restricted during device attach */
> +	.pgsize_bitmap			= -1UL,
>   };
>
>   static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
>



From vladimir.murzin at arm.com  Thu Feb 18 03:13:06 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Thu, 18 Feb 2016 11:13:06 +0000
Subject: [PATCH v3 09/10] ARM: dts: introduce MPS2 AN385/AN386
In-Reply-To: <7245560.jfhuhtPsB8@wuerfel>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <7272921.u1gphgWzUn@wuerfel> <56C598D9.3030001@arm.com>
 <7245560.jfhuhtPsB8@wuerfel>
Message-ID: <56C5A742.8010304@arm.com>

On 18/02/16 10:45, Arnd Bergmann wrote:
> On Thursday 18 February 2016 10:11:37 Vladimir Murzin wrote:
>>
>> Right, I thought in a wrong way, in opposite it makes more sense now.
>>
>> .dtsi
>>
>> /* below the soc/ */
>> smb {
>>         compatible = "simple-bus";
>>         #address-cells = <2>;
>>         #size-cells = <1>;
>>         ranges = <0 0 0x40200000 0x10000>,
>>                  <1 0 0xa0000000 0x10000>;
>> };
> 
> That looks good, yes.
> 
> Is 0x10000 the correct maximum addressable size of the external bus
> in both cases?
> 
> Intuitively, I would guess that the 0xa0000000 range might
> be much wider.

There is only Ethernet connected to this bus (apart from PSRAM), so it
might be wider, but there is no indication of this in documentation.

> 
>> .dts
>>
>> smb {
>>         ethernet at 0,0 {
>>                 compatible = "smsc,lan9220", "smsc,lan9115";
>>                 reg = <0 0x0 0x10000>;
>>                 interrupts = <13>;
>>                 interrupt-parent = <&nvic>;
>>                 smsc,irq-active-high;
>> };
>>
>>
>> and looking again at .dtsi it seems to me that fpgaio should be moved
>> below the soc/ under separate bus interface which would hosts audio and
>> spi too or I keep missing things around device-tree?
>>
> 
> I don't see the audio and spi nodes, so I'm not sure where exactly
> you would put them.

I just keep things simple ;)

> 
> Ideally those things should be visible from a block diagram in the
> datasheet.

Indeed, block diagram indicates all them as a "FPGA APB subsystem" and
clearly draws a line indicating a bus those devices are connected to.
After your point about lan9220, it looks clearer to me to express that
subsystem outside of soc/ node indicating bus interface, so it would
match to those drawings closely.

Cheers
Vladimir

> 
> 	Arnd
> 
> 
> 



From mark.rutland at arm.com  Thu Feb 18 03:15:16 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 18 Feb 2016 11:15:16 +0000
Subject: KASAN issues with idle / hotplug area
In-Reply-To: <56C57F40.3050500@virtuozzo.com>
References: <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
 <20160217170110.GE32647@leverpostej>
 <20160217175656.GJ32647@leverpostej>
 <20160217191643.GK32647@leverpostej>
 <56C57F40.3050500@virtuozzo.com>
Message-ID: <20160218111516.GM32647@leverpostej>

On Thu, Feb 18, 2016 at 11:22:24AM +0300, Andrey Ryabinin wrote:
> 
> On 02/17/2016 10:16 PM, Mark Rutland wrote:
> > Looking at the assembly, functions seem to get instrumented regardless
> > of the __no_sanitize_address annotation. The assembly of
> > __invoke_psci_fn_{smc,hvc} look identical, even if one has the
> > annotation and one does not.
> > 
> > In the case below, it looks like __invoke_psci_fn_hvc is storing to the
> > shadow area even though it's anotated with __no_sanitize_address.  Note
> > that the adrp symbol resolution is bogus; psci_to_linux_errno happens to
> > be at offset 0 in the as-yet unlinked psci.o object.
> > 
> 
> ...
> > I also tried using __attribute__((no_sanitize_address)) directly, in
> > case there was some header issue, but that doesn't seem to be the case.
> > 
> > I'm using the Linaro 15.08 AArch64 GCC 5.1. Is anyone else able to
> > confirm whether they see the same? Does the same happen for x86?
>
> Confirming, this happens on every GCC I have (including x86).
> It seems that 'no_sanitize_address' in gcc removes only memory access checks
> but it doesn't remove stack redzones.
> I think this is wrong, e.g. clang removes instrumentation completely. I'll submit a bug.

Ok.

Unless there's some clever trickery that we can employ, the above
renders the Linux __no_sanitize_address annotation useless for this
style of code.

We should certianly call that out in the commentary in
include/linux/compiler-gcc.h.

> But we need fix this in kernel.
> I see two options here:
>  * completely disable instrumentation for drivers/firmware/psci.c

This is somewhat overkill, and we'd also have to disable instrumentation
for arch/arm64/kernel/psci.c (for psci_suspend_finisher).

I would like to have instrumentation for everything we can safely
instrument.

This is probably the least worst option, though.

>  * get back to assembly implementation

We'd also have to convert psci_suspend_finisher and psci_cpu_suspend,
the latter being generic code. That goes against the consolidation we
were aiming for.

Mark.


From jay.xu at rock-chips.com  Thu Feb 18 03:16:29 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Thu, 18 Feb 2016 19:16:29 +0800
Subject: [PATCH v3 0/4] add core dtsi file for rk3399
Message-ID: <1455794193-4497-1-git-send-email-jay.xu@rock-chips.com>

From: Jianqun Xu <jay.xu at rock-chips.com>

There is the new SoCs from Rockchip which named rk3399, the
patches are added to support them.

Xing Zheng (2):
  clk: rockchip: add dt-binding header for rk3399
  dt-bindings: add documentation of rk3399 clock controller

Xu Jianqun (2):
  spi: rockchip: add bindings for rk3399 spi
  ARM64: dts: rockchip: add core dtsi file for rk3399

 .../bindings/clock/rockchip,rk3399-cru.txt         |  82 ++
 .../devicetree/bindings/spi/spi-rockchip.txt       |   1 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           | 949 +++++++++++++++++++++
 drivers/spi/spi-rockchip.c                         |   1 +
 include/dt-bindings/clock/rk3399-cru.h             | 609 +++++++++++++
 5 files changed, 1642 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
 create mode 100644 include/dt-bindings/clock/rk3399-cru.h

--
changes in v3:
- add compatible for rk3399 spi (Mark, Heiko)

changes in v2:
- remove changeID (Heiko, Mark)
- drop pmu and psci temporary (Mark)
- drop applied patch (Heiko)
- drop GIC_CPU_MASK_SIMPLE from the interrupt specifiers (Marc, Heiko)
- drop clock-frequency of timer (Marc, Mark)
- remove double defination for SCLK_SPI5

1.9.1




From jay.xu at rock-chips.com  Thu Feb 18 03:16:31 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Thu, 18 Feb 2016 19:16:31 +0800
Subject: [PATCH v3 2/4] spi: rockchip: add bindings for rk3399 spi
In-Reply-To: <1455794193-4497-1-git-send-email-jay.xu@rock-chips.com>
References: <1455794193-4497-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455794193-4497-3-git-send-email-jay.xu@rock-chips.com>

From: Xu Jianqun <jay.xu at rock-chips.com>

Add devicetree bindings for Rockchip rk3399 spi which found on
Rockchip rk3399 SoCs.

Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
changes in v3:
- add compatible for rk3399 spi (Mark, Heiko)

 Documentation/devicetree/bindings/spi/spi-rockchip.txt | 1 +
 drivers/spi/spi-rockchip.c                             | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
index 0c491bd..1b14d69 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
@@ -9,6 +9,7 @@ Required Properties:
     "rockchip,rk3066-spi" for rk3066.
     "rockchip,rk3188-spi", "rockchip,rk3066-spi" for rk3188.
     "rockchip,rk3288-spi", "rockchip,rk3066-spi" for rk3288.
+    "rockchip,rk3399-spi", "rockchip,rk3066-spi" for rk3399.
 - reg: physical base address of the controller and length of memory mapped
        region.
 - interrupts: The interrupt number to the cpu. The interrupt specifier format
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 79a8bc4..345fefd 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -868,6 +868,7 @@ static const struct of_device_id rockchip_spi_dt_match[] = {
 	{ .compatible = "rockchip,rk3066-spi", },
 	{ .compatible = "rockchip,rk3188-spi", },
 	{ .compatible = "rockchip,rk3288-spi", },
+	{ .compatible = "rockchip,rk3399-spi", },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, rockchip_spi_dt_match);
-- 
1.9.1




From jay.xu at rock-chips.com  Thu Feb 18 03:16:32 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Thu, 18 Feb 2016 19:16:32 +0800
Subject: [PATCH v3 3/4] dt-bindings: add documentation of rk3399 clock
 controller
In-Reply-To: <1455794193-4497-1-git-send-email-jay.xu@rock-chips.com>
References: <1455794193-4497-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455794193-4497-4-git-send-email-jay.xu@rock-chips.com>

From: Xing Zheng <zhengxing at rock-chips.com>

Add the devicetree binding for the cru on the rk3399 which quite
similar structured as previous clock controllers.

Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v3:
- none

changes in v2:
- none

 .../bindings/clock/rockchip,rk3399-cru.txt         | 82 ++++++++++++++++++++++
 1 file changed, 82 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
new file mode 100644
index 0000000..07bcc6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
@@ -0,0 +1,82 @@
+* Rockchip RK3399 Clock and Reset Unit
+
+The RK3399 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: PMU for CRU should be "rockchip,rk3399-pmucru"
+- compatible: CRU should be "rockchip,rk3399-cru"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+  If missing, pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "xin32k" - rtc clock - optional,
+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_gmac" - external GMAC clock - optional
+ - "ext_hsadc" - external HSADC clock - optional,
+ - "ext_isp" - external ISP clock - optional,
+ - "ext_jtag" - external JTAG clock - optional
+ - "ext_vip" - external VIP clock - optional,
+ - "usbotg_out" - output clock of the pll in the otg phy
+
+Example: General Register Files
+
+	pmugrf: syscon at ff320000 {
+		compatible = "rockchip,rk3399-pmugrf", "syscon";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+	};
+
+	grf: syscon at ff770000 {
+		compatible = "rockchip,rk3399-grf", "syscon";
+		reg = <0x0 0xff770000 0x0 0x10000>;
+	};
+
+Example: Clock controller node:
+
+	pmucru: pmu-clock-controller at ff750000 {
+		compatible = "rockchip,rk3399-pmucru";
+		reg = <0x0 0xff750000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at ff760000 {
+		compatible = "rockchip,rk3399-cru";
+		reg = <0x0 0xff760000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller:
+
+	uart0: serial at ff1a0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff180000 0x0 0x100>;
+		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+	};
-- 
1.9.1




From jay.xu at rock-chips.com  Thu Feb 18 03:16:30 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Thu, 18 Feb 2016 19:16:30 +0800
Subject: [PATCH v3 1/4] clk: rockchip: add dt-binding header for rk3399
In-Reply-To: <1455794193-4497-1-git-send-email-jay.xu@rock-chips.com>
References: <1455794193-4497-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455794193-4497-2-git-send-email-jay.xu@rock-chips.com>

From: Xing Zheng <zhengxing at rock-chips.com>

Add the dt-bindings header for the rk3399, that gets shared between
the clock controller and the clock references in the dts.

Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v3:
- none

changes in v2:
- none

 include/dt-bindings/clock/rk3399-cru.h | 609 +++++++++++++++++++++++++++++++++
 1 file changed, 609 insertions(+)
 create mode 100644 include/dt-bindings/clock/rk3399-cru.h

diff --git a/include/dt-bindings/clock/rk3399-cru.h b/include/dt-bindings/clock/rk3399-cru.h
new file mode 100644
index 0000000..9fbe3dc
--- /dev/null
+++ b/include/dt-bindings/clock/rk3399-cru.h
@@ -0,0 +1,609 @@
+/*
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng <zhengxing at rock-chips.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H
+#define _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H
+
+/* core clocks */
+#define PLL_APLLL		1
+#define PLL_APLLB		2
+#define PLL_DPLL		3
+#define PLL_CPLL		4
+#define PLL_GPLL		5
+#define PLL_NPLL		6
+#define PLL_VPLL		7
+#define PLL_PPLL		8
+#define ARMCLKL			9
+#define ARMCLKB			10
+
+/* sclk gates (special clocks) */
+#define SCLK_GPU_CORE		64
+#define SCLK_SPI0		65
+#define SCLK_SPI1		66
+#define SCLK_SPI2		68
+#define SCLK_SPI3		69
+#define SCLK_SPI4		70
+#define SCLK_SDMMC		72
+#define SCLK_SDIO0		73
+#define SCLK_EMMC		74
+#define SCLK_TSADC		75
+#define SCLK_SARADC		76
+#define SCLK_NANDC0		77
+#define SCLK_UART0		78
+#define SCLK_UART1		79
+#define SCLK_UART2		80
+#define SCLK_UART3		81
+#define SCLK_UART4		82
+#define SCLK_SPDIF_8CH		83
+#define SCLK_I2S0_8CH		84
+#define SCLK_I2S1_8CH		85
+#define SCLK_I2S2_8CH		86
+#define SCLK_TIMER00		87
+#define SCLK_TIMER01		88
+#define SCLK_TIMER02		89
+#define SCLK_TIMER03		90
+#define SCLK_TIMER04		91
+#define SCLK_TIMER05		92
+#define SCLK_TIMER06		93
+#define SCLK_TIMER07		94
+#define SCLK_TIMER08		95
+#define SCLK_TIMER09		96
+#define SCLK_TIMER10		97
+#define SCLK_TIMER11		98
+#define SCLK_HSICPHY480M	99
+#define SCLK_HSICPHY12M		100
+#define SCLK_MACREF		101
+#define SCLK_VOPB_PWM		102
+#define SCLK_VOPL_PWM		103
+#define SCLK_EDP_24M		104
+#define SCLK_EDP		105
+#define SCLK_RGA		106
+#define SCLK_ISP		107
+#define SCLK_HDCP		108
+#define SCLK_HDMI_HDCP		109
+#define SCLK_HDMI_CEC		110
+#define SCLK_HEVC_CABAC		111
+#define SCLK_HEVC_CORE		112
+#define SCLK_I2S_8CH_OUT	113
+#define SCLK_SDMMC_DRV		114
+#define SCLK_SDIO0_DRV		115
+#define SCLK_SDIO1_DRV		116
+#define SCLK_EMMC_DRV		117
+#define SCLK_SDMMC_SAMPLE	118
+#define SCLK_SDIO0_SAMPLE	119
+#define SCLK_SDIO1_SAMPLE	120
+#define SCLK_EMMC_SAMPLE	121
+#define SCLK_USBPHY480M		122
+#define SCLK_PVTM_CORE_L	123
+#define SCLK_PVTM_CORE_B	124
+#define SCLK_PVTM_GPU		125
+#define SCLK_PVTM_PMU		126
+#define SCLK_SFC		127
+#define SCLK_MAC_RX		128
+#define SCLK_MAC_TX		129
+#define SCLK_MAC		130
+#define SCLK_MACREF_OUT		131
+#define SCLK_USB2_PHY0_REF	132
+#define SCLK_USB2_PHY1_REF	133
+#define SCLK_USB3_OTG0_REF	134
+#define SCLK_USB3_OTG1_REF	135
+#define SCLK_USB3_OTG0_SUSPEND	136
+#define SCLK_USB3_OTG1_SUSPEND	137
+#define SCLK_CRYPTO		138
+#define SCLK_CRYPTO1		139
+
+#define DCLK_VOPB		170
+#define DCLK_VOPL		171
+#define MCLK_CRYPTO		172
+#define MCLK_CRYPTO1		173
+
+/* aclk gates */
+#define ACLK_GPU_MEM		192
+#define ACLK_GPU_CFG		193
+#define ACLK_DMAC_BUS		194
+#define ACLK_DMAC_PERI		195
+#define ACLK_PERI_MMU		196
+#define ACLK_GMAC		197
+#define ACLK_VOPB		198
+#define ACLK_VOPL		199
+#define ACLK_RGA		200
+#define ACLK_HDCP		201
+#define ACLK_IEP		202
+#define ACLK_VIO0_NOC		203
+#define ACLK_VIP		204
+#define ACLK_ISP		205
+#define ACLK_VIO1_NOC		206
+#define ACLK_VIDEO		208
+#define ACLK_BUS		209
+#define ACLK_PERI		210
+#define ACLK_EMMC_GPLL		211
+#define ACLK_EMMC_CPLL		212
+#define ACLK_EMMC_CORE		213
+#define ACLK_EMMC_NIU 		214
+#define ACLK_EMMC_GRF 		215
+#define ACLK_USB3_OTG0		216
+#define ACLK_USB3_OTG1		217
+#define ACLK_USB3_GRF 		218
+
+/* pclk gates */
+#define PCLK_GPIO0		320
+#define PCLK_GPIO1		321
+#define PCLK_GPIO2		322
+#define PCLK_GPIO3		323
+#define PCLK_GPIO4		324
+#define PCLK_PMUGRF		325
+#define PCLK_MAILBOX		326
+#define PCLK_GRF		329
+#define PCLK_SGRF		330
+#define PCLK_PMU		331
+#define PCLK_I2C0		332
+#define PCLK_I2C1		333
+#define PCLK_I2C2		334
+#define PCLK_I2C3		335
+#define PCLK_I2C4		336
+#define PCLK_I2C5		337
+#define PCLK_SPI0		338
+#define PCLK_SPI1		339
+#define PCLK_SPI2		340
+#define PCLK_SPI3		341
+#define PCLK_SPI4		342
+#define PCLK_SPI5		343
+#define PCLK_UART0		344
+#define PCLK_UART1		345
+#define PCLK_UART2		346
+#define PCLK_UART3		347
+#define PCLK_UART4		348
+#define PCLK_TSADC		349
+#define PCLK_SARADC		350
+#define PCLK_SIM		351
+#define PCLK_GMAC		352
+#define PCLK_PWM0		353
+#define PCLK_PWM1		354
+#define PCLK_TIMER0		355
+#define PCLK_TIMER1		356
+#define PCLK_EDP_CTRL		357
+#define PCLK_MIPI_DSI0		358
+#define PCLK_MIPI_CSI		359
+#define PCLK_HDCP		360
+#define PCLK_HDMI_CTRL		361
+#define PCLK_VIO_H2P		362
+#define PCLK_BUS		363
+#define PCLK_PERI		364
+#define PCLK_DDRUPCTL		365
+#define PCLK_DDRPHY		366
+#define PCLK_ISP		367
+#define PCLK_VIP		368
+#define PCLK_WDT		369
+
+/* hclk gates */
+#define HCLK_SFC		448
+#define HCLK_HOST0		450
+#define HCLK_HOST1		451
+#define HCLK_HSIC		452
+#define HCLK_NANDC0		453
+#define HCLK_TSP		455
+#define HCLK_SDMMC		456
+#define HCLK_SDIO0		457
+#define HCLK_EMMC		459
+#define HCLK_HSADC		460
+#define HCLK_CRYPTO		461
+#define HCLK_I2S0_8CH		462
+#define HCLK_I2S1_8CH		463
+#define HCLK_I2S2_8CH		464
+#define HCLK_SPDIF		465
+#define HCLK_VOPB		466
+#define HCLK_VOPL		467
+#define HCLK_ROM		468
+#define HCLK_IEP		469
+#define HCLK_ISP		470
+#define HCLK_RGA		471
+#define HCLK_VIO_AHB_ARBI	472
+#define HCLK_VIO_NOC		473
+#define HCLK_VIP		474
+#define HCLK_VIO_H2P		475
+#define HCLK_VIO_HDCPMMU	476
+#define HCLK_VIDEO		477
+#define HCLK_BUS		478
+#define HCLK_PERI		479
+
+/* pmu-clocks indices */
+#define SCLK_CM0S		500
+#define SCLK_SPI5		501
+#define SCLK_TIMER12		502
+#define SCLK_TIMER13		503
+#define SCLK_UART		504
+
+#define CLK_NR_CLKS		(SCLK_UART + 1)
+
+/* soft-reset indices */
+
+/* cru_softrst_con0 */
+#define SRST_CORE_L0			0
+#define SRST_CORE_B0			1
+#define SRST_CORE_PO_L0			2
+#define SRST_CORE_PO_B0			3
+#define SRST_L2_L			4
+#define SRST_L2_B			5
+#define SRST_ADB_L			6
+#define SRST_ADB_B			7
+#define SRST_A_CCI			8
+#define SRST_A_CCIM0_NIU		9
+#define SRST_A_CCIM1_NIU		10
+#define SRST_DBG_NIU			11
+
+/* cru_softrst_con1 */
+#define SRST_CORE_L0_T			16
+#define SRST_CORE_L1			17
+#define SRST_CORE_L2			18
+#define SRST_CORE_L3			19
+#define SRST_CORE_PO_L0_T		20
+#define SRST_CORE_PO_L1			21
+#define SRST_CORE_PO_L2			22
+#define SRST_CORE_PO_L3			23
+#define SRST_A_ADB400_GIC2_CORE_L	24
+#define SRST_A_ADB400_CORE_L_GIC2	25
+#define SRST_P_DBG_L			26
+#define SRST_SOC_DBG_L			27
+#define SRST_L2_L_T			28
+#define SRST_ADB_L_T			29
+#define SRST_A_RKREF_L			30
+#define SRST_PVTM_CORE_L		31
+
+/* cru_softrst_con2 */
+#define SRST_CORE_B0_T			32
+#define SRST_CORE_B1			33
+#define SRST_CORE_PO_B0_T		36
+#define SRST_CORE_PO_B1			37
+#define SRST_A_ADB400_GIC2_CORE_B	40
+#define SRST_A_ADB400_CORE_B_GIC2	41
+#define SRST_P_DBG_B			42
+#define SRST_L2_B_T			43
+#define SRST_SOC_DBG_B			44
+#define SRST_ADB_B_T			45
+#define SRST_A_RKREF_B			46
+#define SRST_PVTM_CORE_B		47
+
+/* cru_softrst_con3 */
+#define SRST_A_CCI_T			50
+#define SRST_A_CCIM0_NIU_T		51
+#define SRST_A_CCIM1_NIU_T		52
+#define SRST_A_ADB400M_PD_CORE_B_T	53
+#define SRST_A_ADB400M_PD_CORE_L_T	54
+#define SRST_DBG_NIU_T			55
+#define SRST_DBG_CXCS			56
+#define SRST_CCI_TRACE			57
+#define SRST_P_CCI_GRF			58
+
+/* cru_softrst_con4 */
+#define SRST_A_CENTER_MAIN_NIU		64
+#define SRST_A_CENTER_PERI_NIU		65
+#define SRST_P_CENTER_MAIN		66
+#define SRST_P_DDRMAON			67
+#define SRST_P_CIC			68
+#define SRST_P_CENTER_SGRF		69
+#define SRST_DDR0_MSCH			70
+#define SRST_DDRCFG0_MSCH		71
+#define SRST_DDR0			72
+#define SRST_DDRPHY0			73
+#define SRST_DDR1_MSCH			74
+#define SRST_DDRCFG1_MSCH		75
+#define SRST_DDR1			76
+#define SRST_DDRPHY1			77
+#define SRST_DDR_CIC			78
+#define SRST_PVTM_DDR			79
+
+/* cru_softrst_con5 */
+#define SRST_A_VCODEC_NIU		80
+#define SRST_A_VCODEC			81
+#define SRST_H_VCODEC_NIU		82
+#define SRST_H_VCODEC			83
+#define SRST_A_VDU_NIU			88
+#define SRST_A_VDU 			89
+#define SRST_H_VDU_NIU			90
+#define SRST_H_VDU			91
+#define SRST_VDU_CORE			92
+#define SRST_VDU_CA			93
+
+/* cru_softrst_con6 */
+#define SRST_A_IEP_NIU			96
+#define SRST_A_VOP_IEP			97
+#define SRST_A_IEP			98
+#define SRST_H_IEP_NIU			99
+#define SRST_H_IEP			100
+#define SRST_A_RGA_NIU			102
+#define SRST_A_RGA			103
+#define SRST_H_RGA_NIU			104
+#define SRST_H_RGA			105
+#define SRST_RGA_CORE			106
+#define SRST_EMMC_NIU			108
+#define SRST_EMMC			109
+#define SRST_EMMC_GRF			110
+#define SRST_EMMCPHY_SYSRX		111
+
+/* cru_softrst_con7 */
+#define SRST_A_PERIHP_NIU		112
+#define SRST_A_PERIHP_GRF		113
+#define SRST_H_PERIHP_NIU		114
+#define SRST_USBHOST0 			115
+#define SRST_HOSTC0_AUX			116
+#define SRST_HOSTC0_ARB			117
+#define SRST_USBHOST1			118
+#define SRST_HOSTC1_AUX			119
+#define SRST_HOSTC1_ARB			120
+#define SRST_SDIO0			121
+#define SRST_SDMMC			122
+#define SRST_HSIC			123
+#define SRST_HSIC_AUX			124
+#define SRST_AHB1TOM			125
+#define SRST_P_PERIHP_NIU		126
+#define SRST_HSICPHY			127
+
+/* cru_softrst_con8 */
+#define SRST_A_PCIE			128
+#define SRST_P_PCIE			129
+#define SRST_PCIE_CORE			130
+#define SRST_PCIE_MGMT			131
+#define SRST_PCIE_MGMT_STICKY		132
+#define SRST_PCIE_PIPE			133
+#define SRST_PCIE_PM			134
+#define SRST_PCIEPHY			135
+#define SRST_A_GMAC_NIU			136
+#define SRST_A_GMAC 			137
+#define SRST_P_GMAC_NIU			138
+#define SRST_P_GMAC			139
+#define SRST_P_GMAC_GRF			140
+#define SRST_HSICPHY_POR		142
+#define SRST_HSICPHY_UTMI		143
+
+/* cru_softrst_con9 */
+#define SRST_USB2PHY0_POR		144
+#define SRST_USB2PHY0_UTMI_PORT0	145
+#define SRST_USB2PHY0_UTMI_PORT1	146
+#define SRST_USB2PHY0_EHCIPHY		147
+#define SRST_UPHY0_PIPE_L00		148
+#define SRST_UPHY0			149
+#define SRST_UPHY0_TCPDPWRUP		150
+#define SRST_USB2PHY1_POR		152
+#define SRST_USB2PHY1_UTMI_PORT0	153
+#define SRST_USB2PHY1_UTMI_PORT1	154
+#define SRST_USB2PHY1_EHCIPHY		155
+#define SRST_UPHY1_PIPE_L00		156
+#define SRST_UPHY1			157
+#define SRST_UPHY1_TCPDPWRUP		158
+
+/* cru_softrst_con10 */
+#define SRST_A_PERILP0_NIU		160
+#define SRST_A_DCF			161
+#define SRST_GIC500			162
+#define SRST_DMAC0_PERILP0		163
+#define SRST_DMAC1_PERILP0		164
+#define SRST_TZMA			165
+#define SRST_INTMEM			166
+#define SRST_ADB400_MST0		167
+#define SRST_ADB400_MST1		168
+#define SRST_ADB400_SLV0		169
+#define SRST_ADB400_SLV1		170
+#define SRST_H_PERILP0			171
+#define SRST_H_PERILP0_NIU		172
+#define SRST_ROM			173
+#define SRST_CRYPTO_S			174
+#define SRST_CRYPTO_M			175
+
+/* cru_softrst_con11 */
+#define SRST_P_DCF			176
+#define SRST_CM0S_NIU			177
+#define SRST_CM0S			178
+#define SRST_CM0S_DBG			179
+#define SRST_CM0S_PO			180
+#define SRST_CRYPTO			181
+#define SRST_P_PERILP1_SGRF		182
+#define SRST_P_PERILP1_GRF		183
+#define SRST_CRYPTO1_S			184
+#define SRST_CRYPTO1_M			185
+#define SRST_CRYPTO1			186
+#define SRST_GIC_NIU			188
+#define SRST_SD_NIU			189
+#define SRST_SDIOAUDIO_BRG		190
+
+/* cru_softrst_con12 */
+#define SRST_H_PERILP1			192
+#define SRST_H_PERILP1_NIU		193
+#define SRST_H_I2S0_8CH			194
+#define SRST_H_I2S1_8CH			195
+#define SRST_H_I2S2_8CH			196
+#define SRST_H_SPDIF_8CH		197
+#define SRST_P_PERILP1_NIU		198
+#define SRST_P_EFUSE_1024		199
+#define SRST_P_EFUSE_1024S		200
+#define SRST_P_I2C0			201
+#define SRST_P_I2C1			202
+#define SRST_P_I2C2			203
+#define SRST_P_I2C3			204
+#define SRST_P_I2C4			205
+#define SRST_P_I2C5			206
+#define SRST_P_MAILBOX0			207
+
+/* cru_softrst_con13 */
+#define SRST_P_UART0			208
+#define SRST_P_UART1			209
+#define SRST_P_UART2			210
+#define SRST_P_UART3			211
+#define SRST_P_SARADC			212
+#define SRST_P_TSADC			213
+#define SRST_P_SPI0			214
+#define SRST_P_SPI1			215
+#define SRST_P_SPI2			216
+#define SRST_P_SPI3			217
+#define SRST_P_SPI4			218
+#define SRST_SPI0			219
+#define SRST_SPI1			220
+#define SRST_SPI2			221
+#define SRST_SPI3			222
+#define SRST_SPI4			223
+
+/* cru_softrst_con14 */
+#define SRST_I2S0_8CH			224
+#define SRST_I2S1_8CH			225
+#define SRST_I2S2_8CH			226
+#define SRST_SPDIF_8CH			227
+#define SRST_UART0			228
+#define SRST_UART1			229
+#define SRST_UART2			230
+#define SRST_UART3			231
+#define SRST_TSADC			232
+#define SRST_I2C0			233
+#define SRST_I2C1			234
+#define SRST_I2C2			235
+#define SRST_I2C3			236
+#define SRST_I2C4			237
+#define SRST_I2C5			238
+#define SRST_SDIOAUDIO_NIU		239
+
+/* cru_softrst_con15 */
+#define SRST_A_VIO_NIU			240
+#define SRST_A_HDCP_NIU			241
+#define SRST_A_HDCP			242
+#define SRST_H_HDCP_NIU			243
+#define SRST_H_HDCP			244
+#define SRST_P_HDCP_NIU			245
+#define SRST_P_HDCP			246
+#define SRST_P_HDMI_CTRL		247
+#define SRST_P_DP_CTRL			248
+#define SRST_S_DP_CTRL			249
+#define SRST_C_DP_CTRL			250
+#define SRST_P_MIPI_DSI0		251
+#define SRST_P_MIPI_DSI1		252
+#define SRST_DP_CORE			253
+#define SRST_DP_I2S			254
+#define SRST_DP_VIF			255
+
+/* cru_softrst_con16 */
+#define SRST_GASKET			256
+#define SRST_VIO_SGRF			257
+#define SRST_VIO_GRF			258
+#define SRST_DPTX_SPDIF_REC		259
+#define SRST_HDMI_CTRL			260
+#define SRST_HDCP_CTRL			261
+#define SRST_A_ISP0_NIU			262
+#define SRST_A_ISP1_NIU			263
+#define SRST_A_ISP0			264
+#define SRST_A_ISP1			265
+#define SRST_H_ISP0_NIU			266
+#define SRST_H_ISP1_NIU			267
+#define SRST_H_ISP0			268
+#define SRST_H_ISP1			269
+#define SRST_ISP0			270
+#define SRST_ISP1			271
+
+/* cru_softrst_con17 */
+#define SRST_A_VOP0_NIU			272
+#define SRST_A_VOP1_NIU			273
+#define SRST_A_VOP0			274
+#define SRST_A_VOP1			275
+#define SRST_H_VOP0_NIU			276
+#define SRST_H_VOP1_NIU			277
+#define SRST_H_VOP0			278
+#define SRST_H_VOP1			279
+#define SRST_D_VOP0			280
+#define SRST_D_VOP1			281
+#define SRST_VOP0_PWM			282
+#define SRST_VOP1_PWM			283
+#define SRST_P_EDP_NIU			284
+#define SRST_P_EDP_CTRL			285
+
+/* cru_softrst_con18 */
+#define SRST_A_GPU			288
+#define SRST_A_GPU_NIU			289
+#define SRST_A_GPU_GRF			290
+#define SRST_PVTM_GPU			291
+#define SRST_A_USB3_NIU			292
+#define SRST_A_USB3_OTG0		293
+#define SRST_A_USB3_OTG1		294
+#define SRST_A_USB3_GRF			295
+#define SRST_PMU			296
+#define SRST_PVTM_PMU			297
+
+/* cru_softrst_con19 */
+#define SRST_P_TIMER0_5			304
+#define SRST_TIMER0			305
+#define SRST_TIMER1			306
+#define SRST_TIMER2			307
+#define SRST_TIMER3			308
+#define SRST_TIMER4			309
+#define SRST_TIME5			310
+#define SRST_P_TIMER6_11		311
+#define SRST_TIMER6			312
+#define SRST_TIMER7			313
+#define SRST_TIMER8			314
+#define SRST_TIMER9			315
+#define SRST_TIMER10			316
+#define SRST_TIMER11			317
+#define SRST_P_INTR_ARB_PMU		318
+#define SRST_P_ALIVE_SGRF		319
+
+/* cru_softrst_con20 */
+#define SRST_P_GPIO2			320
+#define SRST_P_GPIO3			321
+#define SRST_P_GPIO4			322
+#define SRST_P_GRF			323
+#define SRST_P_ALIVE_NIU		324
+#define SRST_P_WDT0			325
+#define SRST_P_WDT1			326
+#define SRST_P_INTR_ARB 		327
+#define SRST_P_UPHY0_DPTX		328
+#define SRST_P_UPHY1_DPTX		329
+#define SRST_P_UPHY0_APB		330
+#define SRST_P_UPHY1_APB		331
+#define SRST_P_UPHY0_TCPHY		332
+#define SRST_P_UPHY1_TCPHY		333
+#define SRST_P_UPHY0_TCPDCTRL		334
+#define SRST_P_UPHY1_TCPDCTRL		335
+
+/* pmu soft-reset indices */
+
+/* pmu_cru_softrst_con0 */
+#define SRST_P_NIU			0
+#define SRST_P_INTMEN			1
+#define SRST_H_CM0S			2
+#define SRST_H_CM0S_NIU			3
+#define SRST_DBG_CM0S			4
+#define SRST_PO_CM0S			5
+#define SRST_P_SPI6			6
+#define SRST_SPI6			7
+#define SRST_P_TIMER_0_1		8
+#define SRST_P_TIMER_0			9
+#define SRST_P_TIMER_1			10
+#define SRST_P_UART4			11
+#define SRST_UART4			12
+#define SRST_P_WDT			13
+
+/* pmu_cru_softrst_con1 */
+#define SRST_P_I2C6			16
+#define SRST_P_I2C7			17
+#define SRST_P_I2C8			18
+#define SRST_P_MAILBOX			19
+#define SRST_P_RKPWM			20
+#define SRST_P_PMUGRF			21
+#define SRST_P_SGRF			22
+#define SRST_P_GPIO0			23
+#define SRST_P_GPIO1			24
+#define SRST_P_CRU			25
+#define SRST_P_INTR			26
+#define SRST_PVTM 			27
+#define SRST_I2C6			28
+#define SRST_I2C7			29
+#define SRST_I2C8			30
+
+#endif
-- 
1.9.1




From jay.xu at rock-chips.com  Thu Feb 18 03:16:33 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Thu, 18 Feb 2016 19:16:33 +0800
Subject: [PATCH 4/4] ARM64: dts: rockchip: add core dtsi file for rk3399
In-Reply-To: <1455794193-4497-1-git-send-email-jay.xu@rock-chips.com>
References: <1455794193-4497-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455794193-4497-5-git-send-email-jay.xu@rock-chips.com>

From: Xu Jianqun <jay.xu at rock-chips.com>

Add dtsi file for Rockchip rk3399 SoCs with some
general nodes such as cpu, timer, cru, gic, amba.

Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v3:
- none

changes in v2:
- drop pmu and psci temporary (Mark)
- drop two applied patches (Heiko)
- drop GIC_CPU_MASK_SIMPLE from the interrupt specifiers (Marc, Heiko)
- drop clock-frequency of timer (Marc, Mark)

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 949 +++++++++++++++++++++++++++++++
 1 file changed, 949 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 0000000..00fb38a
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,949 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+#include <dt-bindings/clock/rk3399-cru.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+
+/ {
+	compatible = "rockchip,rk3399";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu_l0>;
+				};
+				core1 {
+					cpu = <&cpu_l1>;
+				};
+				core2 {
+					cpu = <&cpu_l2>;
+				};
+				core3 {
+					cpu = <&cpu_l3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu_b0>;
+				};
+				core1 {
+					cpu = <&cpu_b1>;
+				};
+			};
+		};
+
+		cpu_l0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x0>;
+		};
+
+		cpu_l1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x1>;
+		};
+
+		cpu_l2: cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x2>;
+		};
+
+		cpu_l3: cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x3>;
+		};
+
+		cpu_b0: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x0 0x100>;
+		};
+
+		cpu_b1: cpu at 101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x0 0x101>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	xin24m: xin24m {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24000000>;
+		clock-output-names = "xin24m";
+	};
+
+	gic: interrupt-controller at fee00000 {
+		compatible = "arm,gic-v3";
+		#interrupt-cells = <3>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		interrupt-controller;
+
+		reg = <0x0 0xfee00000 0 0x10000>, /* GICD */
+		      <0x0 0xfef00000 0 0xc0000>, /* GICR */
+		      <0x0 0xfff00000 0 0x10000>, /* GICC */
+		      <0x0 0xfff10000 0 0x10000>, /* GICH */
+		      <0x0 0xfff20000 0 0x10000>; /* GICV */
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH)>;
+		its: interrupt-controller at fee20000 {
+			compatible = "arm,gic-v3-its";
+			msi-controller;
+			reg = <0x0 0xfee20000 0x0 0x20000>;
+		};
+	};
+
+	amba {
+		compatible = "arm,amba-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		dmac_bus: dma-controller at ff6d0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x0 0xff6d0000 0x0 0x4000>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			clocks = <&cru ACLK_DMAC_BUS>;
+			clock-names = "apb_pclk";
+		};
+
+		dmac_peri: dma-controller at ff6e0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x0 0xff6e0000 0x0 0x4000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			clocks = <&cru ACLK_DMAC_PERI>;
+			clock-names = "apb_pclk";
+		};
+	};
+
+	uart0: serial at ff180000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff180000 0x0 0x100>;
+		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart1: serial at ff190000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff190000 0x0 0x100>;
+		clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart2: serial at ff1a0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff1a0000 0x0 0x100>;
+		clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart3: serial at ff1b0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff1b0000 0x0 0x100>;
+		clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	spi0: spi at ff1c0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff110000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI0>, <&cru PCLK_SPI0>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi0_clk &spi0_tx &spi0_rx &spi0_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi1: spi at ff1d0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff120000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI1>, <&cru PCLK_SPI1>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi1_clk &spi1_tx &spi1_rx &spi1_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi2: spi at ff1e0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff130000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI2>, <&cru PCLK_SPI2>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi2_clk &spi2_tx &spi2_rx &spi2_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi4: spi at ff1f0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff120000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI4>, <&cru PCLK_SPI4>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi4_clk &spi4_tx &spi4_rx &spi4_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi5: spi at ff200000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff130000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI5>, <&cru PCLK_SPI5>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi5_clk &spi5_tx &spi5_rx &spi5_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	pmugrf: syscon at ff320000 {
+		compatible = "rockchip,rk3399-pmugrf", "syscon";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+	};
+
+	spi3: spi at ff350000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff110000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI3>, <&cru PCLK_SPI3>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi3_clk &spi3_tx &spi3_rx &spi3_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	uart4: serial at ff370000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff370000 0x0 0x100>;
+		clocks = <&cru SCLK_UART4>, <&cru PCLK_UART4>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	pmucru: pmu-clock-controller at ff750000 {
+		compatible = "rockchip,rk3399-pmucru";
+		reg = <0x0 0xff750000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at ff760000 {
+		compatible = "rockchip,rk3399-cru";
+		reg = <0x0 0xff760000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	grf: syscon at ff770000 {
+		compatible = "rockchip,rk3399-grf", "syscon";
+		reg = <0x0 0xff770000 0x0 0x10000>;
+	};
+
+	i2s0: i2s at ff880000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff880000 0x0 0x1000>;
+		interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 0>, <&dmac_bus 1>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S0_8CH>, <&cru SCLK_I2S0_8CH>;
+		status = "disabled";
+	};
+
+	i2s1: i2s at ff890000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff890000 0x0 0x1000>;
+		interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 2>, <&dmac_bus 3>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S1_8CH>, <&cru SCLK_I2S1_8CH>;
+		status = "disabled";
+	};
+
+	i2s2: i2s at ff8a0000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff8a0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 4>, <&dmac_bus 5>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S2_8CH>, <&cru SCLK_I2S2_8CH>;
+		status = "disabled";
+	};
+
+	pinctrl: pinctrl {
+		compatible = "rockchip,rk3399-pinctrl";
+		rockchip,grf = <&grf>;
+		rockchip,pmu = <&pmugrf>;
+		#address-cells = <0x2>;
+		#size-cells = <0x2>;
+		ranges;
+
+		gpio0: gpio0 at ff720000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff720000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio1: gpio1 at ff730000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff730000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio2: gpio2 at ff780000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff780000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio3: gpio3 at ff788000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff788000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio4: gpio4 at ff790000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff790000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		pcfg_pull_up: pcfg-pull-up {
+			bias-pull-up;
+		};
+
+		pcfg_pull_down: pcfg-pull-down {
+			bias-pull-down;
+		};
+
+		pcfg_pull_none: pcfg-pull-none {
+			bias-disable;
+		};
+
+		pcfg_pull_none_12ma: pcfg-pull-none-12ma {
+			bias-disable;
+			drive-strength = <12>;
+		};
+
+		pcfg_pull_up_8ma: pcfg-pull-up-8ma {
+			bias-pull-up;
+			drive-strength = <8>;
+		};
+
+		pcfg_pull_down_4ma: pcfg-pull-down-4ma {
+			bias-pull-down;
+			drive-strength = <4>;
+		};
+
+		pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+			bias-pull-up;
+			drive-strength = <2>;
+		};
+
+		pcfg_pull_down_12ma: pcfg-pull-down-12ma {
+			bias-pull-down;
+			drive-strength = <12>;
+		};
+
+		emmc {
+			emmc_pwr: emmc-pwr {
+				rockchip,pins =
+					<0 5 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		gmac {
+			rgmii_pins: rgmii-pins {
+				rockchip,pins =
+					<3 11 RK_FUNC_1 &pcfg_pull_none>,
+					<3 13 RK_FUNC_1 &pcfg_pull_none>,
+					<3 8 RK_FUNC_1 &pcfg_pull_none>,
+					<3 4 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 5 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 0 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 1 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 17 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 12 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 6 RK_FUNC_1 &pcfg_pull_none>,
+					<3 7 RK_FUNC_1 &pcfg_pull_none>,
+					<3 2 RK_FUNC_1 &pcfg_pull_none>,
+					<3 3 RK_FUNC_1 &pcfg_pull_none>,
+					<3 14 RK_FUNC_1 &pcfg_pull_none>,
+					<3 9 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			rmii_pins: rmii-pins {
+				rockchip,pins =
+					<3 11 RK_FUNC_1 &pcfg_pull_none>,
+					<3 13 RK_FUNC_1 &pcfg_pull_none>,
+					<3 8 RK_FUNC_1 &pcfg_pull_none>,
+					<3 4 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 5 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 12 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 6 RK_FUNC_1 &pcfg_pull_none>,
+					<3 7 RK_FUNC_1 &pcfg_pull_none>,
+					<3 9 RK_FUNC_1 &pcfg_pull_none>,
+					<3 10 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c0 {
+			i2c0_xfer: i2c0-xfer {
+				rockchip,pins =
+					<1 15 RK_FUNC_2 &pcfg_pull_none>,
+					<1 16 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c1 {
+			i2c1_xfer: i2c1-xfer {
+				rockchip,pins =
+					<4 2 RK_FUNC_1 &pcfg_pull_none>,
+					<4 1 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c2 {
+			i2c2_xfer: i2c2-xfer {
+				rockchip,pins =
+					<2 1 RK_FUNC_2 &pcfg_pull_none_12ma>,
+					<2 0 RK_FUNC_2 &pcfg_pull_none_12ma>;
+			};
+		};
+
+		i2c3 {
+			i2c3_xfer: i2c3-xfer {
+				rockchip,pins =
+					<4 17 RK_FUNC_1 &pcfg_pull_none>,
+					<4 16 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c4 {
+			i2c4_xfer: i2c4-xfer {
+				rockchip,pins =
+					<1 12 RK_FUNC_1 &pcfg_pull_none>,
+					<1 11 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c5 {
+			i2c5_xfer: i2c5-xfer {
+				rockchip,pins =
+					<3 11 RK_FUNC_2 &pcfg_pull_none>,
+					<3 10 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c6 {
+			i2c6_xfer: i2c6-xfer {
+				rockchip,pins =
+					<2 10 RK_FUNC_2 &pcfg_pull_none>,
+					<2 9 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c7 {
+			i2c7_xfer: i2c7-xfer {
+				rockchip,pins =
+					<2 8 RK_FUNC_2 &pcfg_pull_none>,
+					<2 7 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c8 {
+			i2c8_xfer: i2c8-xfer {
+				rockchip,pins =
+					<1 21 RK_FUNC_1 &pcfg_pull_none>,
+					<1 20 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2s0 {
+			i2s0_8ch_bus: i2s0-8ch-bus {
+				rockchip,pins =
+					<3 24 RK_FUNC_1 &pcfg_pull_none>,
+					<3 25 RK_FUNC_1 &pcfg_pull_none>,
+					<3 26 RK_FUNC_1 &pcfg_pull_none>,
+					<3 27 RK_FUNC_1 &pcfg_pull_none>,
+					<3 28 RK_FUNC_1 &pcfg_pull_none>,
+					<3 29 RK_FUNC_1 &pcfg_pull_none>,
+					<3 30 RK_FUNC_1 &pcfg_pull_none>,
+					<3 31 RK_FUNC_1 &pcfg_pull_none>,
+					<4 0 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2s1 {
+			i2s1_2ch_bus: i2s1-2ch-bus {
+				rockchip,pins =
+					<4 3 RK_FUNC_1 &pcfg_pull_none>,
+					<4 4 RK_FUNC_1 &pcfg_pull_none>,
+					<4 5 RK_FUNC_1 &pcfg_pull_none>,
+					<4 6 RK_FUNC_1 &pcfg_pull_none>,
+					<4 7 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		sdio0 {
+			sdio0_bus1: sdio0-bus1 {
+				rockchip,pins =
+					<2 20 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_bus4: sdio0-bus4 {
+				rockchip,pins =
+					<2 20 RK_FUNC_1 &pcfg_pull_up>,
+					<2 21 RK_FUNC_1 &pcfg_pull_up>,
+					<2 22 RK_FUNC_1 &pcfg_pull_up>,
+					<2 23 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_cmd: sdio0-cmd {
+				rockchip,pins =
+					<2 24 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_clk: sdio0-clk {
+				rockchip,pins =
+					<2 25 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			sdio0_cd: sdio0-cd {
+				rockchip,pins =
+					<2 26 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_pwr: sdio0-pwr {
+				rockchip,pins =
+					<2 27 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_bkpwr: sdio0-bkpwr {
+				rockchip,pins =
+					<2 28 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_wp: sdio0-wp {
+				rockchip,pins =
+					<0 3 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_int: sdio0-int {
+				rockchip,pins =
+					<0 4 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		sdmmc {
+			sdmmc_bus1: sdmmc-bus1 {
+				rockchip,pins =
+					<4 8 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_bus4: sdmmc-bus4 {
+				rockchip,pins =
+					<4 8 RK_FUNC_1 &pcfg_pull_up>,
+					<4 9 RK_FUNC_1 &pcfg_pull_up>,
+					<4 10 RK_FUNC_1 &pcfg_pull_up>,
+					<4 11 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_clk: sdmmc-clk {
+				rockchip,pins =
+					<4 12 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			sdmmc_cmd: sdmmc-cmd {
+				rockchip,pins =
+					<4 13 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_cd: sdmcc-cd {
+				rockchip,pins =
+					<0 7 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_wp: sdmmc-wp {
+				rockchip,pins =
+					<0 8 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi0 {
+			spi0_clk: spi0-clk {
+				rockchip,pins =
+					<3 6 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_cs0: spi0-cs0 {
+				rockchip,pins =
+					<3 7 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_cs1: spi0-cs1 {
+				rockchip,pins =
+					<3 8 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_tx: spi0-tx {
+				rockchip,pins =
+					<3 5 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_rx: spi0-rx {
+				rockchip,pins =
+					<3 4 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi1 {
+			spi1_clk: spi1-clk {
+				rockchip,pins =
+					<1 9 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_cs0: spi1-cs0 {
+				rockchip,pins =
+					<1 10 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_rx: spi1-rx {
+				rockchip,pins =
+					<1 7 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_tx: spi1-tx {
+				rockchip,pins =
+					<1 8 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi2 {
+			spi2_clk: spi2-clk {
+				rockchip,pins =
+					<2 11 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_cs0: spi2-cs0 {
+				rockchip,pins =
+					<2 12 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_rx: spi2-rx {
+				rockchip,pins =
+					<2 9 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_tx: spi2-tx {
+				rockchip,pins =
+					<2 10 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi3 {
+			spi3_clk: spi3-clk {
+				rockchip,pins =
+					<1 17 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_cs0: spi3-cs0 {
+				rockchip,pins =
+					<1 18 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_rx: spi3-rx {
+				rockchip,pins =
+					<1 15 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_tx: spi3-tx {
+				rockchip,pins =
+					<1 16 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi4 {
+			spi4_clk: spi4-clk {
+				rockchip,pins =
+					<3 2 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_cs0: spi4-cs0 {
+				rockchip,pins =
+					<3 3 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_rx: spi4-rx {
+				rockchip,pins =
+					<3 0 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_tx: spi4-tx {
+				rockchip,pins =
+					<3 1 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi5 {
+			spi5_clk: spi5-clk {
+				rockchip,pins =
+					<2 22 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_cs0: spi5-cs0 {
+				rockchip,pins =
+					<2 23 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_rx: spi5-rx {
+				rockchip,pins =
+					<2 20 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_tx: spi5-tx {
+				rockchip,pins =
+					<2 21 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		uart0 {
+			uart0_xfer: uart0-xfer {
+				rockchip,pins =
+					<2 16 RK_FUNC_1 &pcfg_pull_up>,
+					<2 17 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			uart0_cts: uart0-cts {
+				rockchip,pins =
+					<2 18 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			uart0_rts: uart0-rts {
+				rockchip,pins =
+					<2 19 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uart1 {
+			uart1_xfer: uart1-xfer {
+				rockchip,pins =
+					<3 12 RK_FUNC_2 &pcfg_pull_up>,
+					<3 13 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2a {
+			uart2a_xfer: uart2a-xfer {
+				rockchip,pins =
+					<4 8 RK_FUNC_2 &pcfg_pull_up>,
+					<4 9 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2b {
+			uart2b_xfer: uart2b-xfer {
+				rockchip,pins =
+					<4 16 RK_FUNC_2 &pcfg_pull_up>,
+					<4 17 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2c {
+			uart2c_xfer: uart2c-xfer {
+				rockchip,pins =
+					<4 19 RK_FUNC_1 &pcfg_pull_up>,
+					<4 20 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uart3 {
+			uart3_xfer: uart3-xfer {
+				rockchip,pins =
+					<3 14 RK_FUNC_2 &pcfg_pull_up>,
+					<3 15 RK_FUNC_2 &pcfg_pull_none>;
+			};
+
+			uart3_cts: uart3-cts {
+				rockchip,pins =
+					<3 18 RK_FUNC_2 &pcfg_pull_none>;
+			};
+
+			uart3_rts: uart3-rts {
+				rockchip,pins =
+					<3 19 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart4 {
+			uart4_xfer: uart4-xfer {
+				rockchip,pins =
+					<1 7 RK_FUNC_1 &pcfg_pull_up>,
+					<1 8 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uarthdcp {
+			uarthdcp_xfer: uarthdcp-xfer {
+				rockchip,pins =
+					<4 21 RK_FUNC_2 &pcfg_pull_up>,
+					<4 22 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		pwm0 {
+			pwm0_pin: pwm0-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			vop0_pwm_pin: vop0-pwm-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		pwm1 {
+			pwm1_pin: pwm1-pin {
+				rockchip,pins =
+					<4 22 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			vop1_pwm_pin: vop1-pwm-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_3 &pcfg_pull_none>;
+			};
+		};
+	};
+};
-- 
1.9.1




From will.deacon at arm.com  Thu Feb 18 03:24:29 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 18 Feb 2016 11:24:29 +0000
Subject: [PATCH v3 1/5] arm64/perf: Rename Cortex A57 events
In-Reply-To: <20160218091307.GA4566@hardcore>
References: <cover.1454516082.git.jglauber@cavium.com>
 <e0ecaaaffb64cc0b2ecfd8852f718a3f1d642b5c.1454516082.git.jglauber@cavium.com>
 <20160215194037.GU6298@arm.com> <20160215200613.GY6298@arm.com>
 <20160218091307.GA4566@hardcore>
Message-ID: <20160218112429.GC8011@arm.com>

On Thu, Feb 18, 2016 at 10:13:07AM +0100, Jan Glauber wrote:
> On Mon, Feb 15, 2016 at 08:06:13PM +0000, Will Deacon wrote:
> > On Mon, Feb 15, 2016 at 07:40:37PM +0000, Will Deacon wrote:
> > > On Wed, Feb 03, 2016 at 06:11:56PM +0100, Jan Glauber wrote:
> > > > The implemented Cortex A57 events are not A57 specific.
> > > > They are recommended by ARM and can be found on other
> > > > ARMv8 SOCs like Cavium ThunderX too. Therefore move
> > > > these events to the common PMUv3 table.
> > > 
> > > I can't find anything in the architecture that suggests these event
> > > numbers are necessarily portable between implementations. Am I missing
> > > something?
> > 
> > Aha, I just noticed appendix K3.1 (silly me for missing it...).
> > 
> > Lemme check whether or not that mandates that those encodings can't be
> > used for wildly different things.
> 
> To me it looks like we would just have duplicated code without the patch,
> and at least the event types (e.g. L1D_CACHE_RD) should be identical
> across implementations.
> 
> But I don't care too much, so please tell me if should drop the patch or
> keep it.

Tell you what then -- how about we simply rename those to ARMV8_IMPDEF_*
instead of ARMV8_A57_*? That way, we can easily identify them as distinct
from the architected events if we need to in future.

Will


From marc.zyngier at arm.com  Thu Feb 18 03:33:07 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Feb 2016 11:33:07 +0000
Subject: [RFC v3 15/15] irqchip/gicv2m/v3-its-pci-msi: IOMMU map the MSI
 frame when needed
In-Reply-To: <1455264797-2334-16-git-send-email-eric.auger@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
 <1455264797-2334-16-git-send-email-eric.auger@linaro.org>
Message-ID: <20160218113307.2b263b10@arm.com>

On Fri, 12 Feb 2016 08:13:17 +0000
Eric Auger <eric.auger at linaro.org> wrote:

> In case the msi_desc references a device attached to an iommu
> domain, the msi address needs to be mapped in the IOMMU. Else any
> MSI write transaction will cause a fault.
> 
> gic_set_msi_addr detects that case and allocates an iova bound
> to the physical address page comprising the MSI frame. This iova
> then is used as the msi_msg address. Unset operation decrements the
> reference on the binding.
> 
> The functions are called in the irq_write_msi_msg ops implementation.
> At that time we can recognize whether the msi is setup or teared down
> looking at the msi_msg content. Indeed msi_domain_deactivate zeroes all
> the fields.
> 
> Signed-off-by: Eric Auger <eric.auger at linaro.org>
> 
> ---
> 
> v2 -> v3:
> - protect iova/addr manipulation with CONFIG_ARCH_DMA_ADDR_T_64BIT and
>   CONFIG_PHYS_ADDR_T_64BIT
> - only expose gic_pci_msi_domain_write_msg in case CONFIG_IOMMU_API &
>   CONFIG_PCI_MSI_IRQ_DOMAIN are set.
> - gic_set/unset_msi_addr duly become static
> ---
>  drivers/irqchip/irq-gic-common.c         | 69 ++++++++++++++++++++++++++++++++
>  drivers/irqchip/irq-gic-common.h         |  5 +++
>  drivers/irqchip/irq-gic-v2m.c            |  7 +++-
>  drivers/irqchip/irq-gic-v3-its-pci-msi.c |  5 +++
>  4 files changed, 85 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
> index f174ce0..46cd06c 100644
> --- a/drivers/irqchip/irq-gic-common.c
> +++ b/drivers/irqchip/irq-gic-common.c
> @@ -18,6 +18,8 @@
>  #include <linux/io.h>
>  #include <linux/irq.h>
>  #include <linux/irqchip/arm-gic.h>
> +#include <linux/iommu.h>
> +#include <linux/msi.h>
>  
>  #include "irq-gic-common.h"
>  
> @@ -121,3 +123,70 @@ void gic_cpu_config(void __iomem *base, void (*sync_access)(void))
>  	if (sync_access)
>  		sync_access();
>  }
> +
> +#if defined(CONFIG_IOMMU_API) && defined(CONFIG_PCI_MSI_IRQ_DOMAIN)
> +static int gic_set_msi_addr(struct irq_data *data, struct msi_msg *msg)
> +{
> +	struct msi_desc *desc = irq_data_get_msi_desc(data);
> +	struct device *dev = msi_desc_to_dev(desc);
> +	struct iommu_domain *d;
> +	phys_addr_t addr;
> +	dma_addr_t iova;
> +	int ret;
> +
> +	d = iommu_get_domain_for_dev(dev);
> +	if (!d)
> +		return 0;
> +#ifdef CONFIG_PHYS_ADDR_T_64BIT
> +	addr = ((phys_addr_t)(msg->address_hi) << 32) | msg->address_lo;
> +#else
> +	addr = msg->address_lo;
> +#endif
> +
> +	ret = iommu_get_single_reserved(d, addr, IOMMU_WRITE, &iova);
> +
> +	if (!ret) {
> +		msg->address_lo = lower_32_bits(iova);
> +		msg->address_hi = upper_32_bits(iova);
> +	}
> +	return ret;
> +}
> +
> +
> +static void gic_unset_msi_addr(struct irq_data *data)
> +{
> +	struct msi_desc *desc = irq_data_get_msi_desc(data);
> +	struct device *dev;
> +	struct iommu_domain *d;
> +	dma_addr_t iova;
> +
> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> +	iova = ((dma_addr_t)(desc->msg.address_hi) << 32) |
> +		desc->msg.address_lo;
> +#else
> +	iova = desc->msg.address_lo;
> +#endif
> +
> +	dev = msi_desc_to_dev(desc);
> +	if (!dev)
> +		return;
> +
> +	d = iommu_get_domain_for_dev(dev);
> +	if (!d)
> +		return;
> +
> +	iommu_put_single_reserved(d, iova);
> +}
> +
> +void gic_pci_msi_domain_write_msg(struct irq_data *irq_data,
> +				  struct msi_msg *msg)
> +{
> +	if (!msg->address_hi && !msg->address_lo && !msg->data)
> +		gic_unset_msi_addr(irq_data); /* deactivate */
> +	else
> +		gic_set_msi_addr(irq_data, msg); /* activate, set_affinity */
> +
> +	pci_msi_domain_write_msg(irq_data, msg);
> +}

So by doing that, you are specializing this infrastructure to PCI.
If you hijacked irq_compose_msi_msg() instead, you'd have both
platform and PCI MSI for the same price.

I can see a potential problem with the teardown of an MSI (I don't
think the compose method is called on teardown), but I think this could
be easily addressed.

> +#endif
> +
> diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
> index fff697d..98681fd 100644
> --- a/drivers/irqchip/irq-gic-common.h
> +++ b/drivers/irqchip/irq-gic-common.h
> @@ -35,4 +35,9 @@ void gic_cpu_config(void __iomem *base, void (*sync_access)(void));
>  void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
>  		void *data);
>  
> +#if defined(CONFIG_PCI_MSI_IRQ_DOMAIN) && defined(CONFIG_IOMMU_API)
> +void gic_pci_msi_domain_write_msg(struct irq_data *irq_data,
> +				  struct msi_msg *msg);
> +#endif
> +
>  #endif /* _IRQ_GIC_COMMON_H */
> diff --git a/drivers/irqchip/irq-gic-v2m.c b/drivers/irqchip/irq-gic-v2m.c
> index c779f83..692d809 100644
> --- a/drivers/irqchip/irq-gic-v2m.c
> +++ b/drivers/irqchip/irq-gic-v2m.c
> @@ -24,6 +24,7 @@
>  #include <linux/of_pci.h>
>  #include <linux/slab.h>
>  #include <linux/spinlock.h>
> +#include "irq-gic-common.h"
>  
>  /*
>  * MSI_TYPER:
> @@ -83,7 +84,11 @@ static struct irq_chip gicv2m_msi_irq_chip = {
>  	.irq_mask		= gicv2m_mask_msi_irq,
>  	.irq_unmask		= gicv2m_unmask_msi_irq,
>  	.irq_eoi		= irq_chip_eoi_parent,
> -	.irq_write_msi_msg	= pci_msi_domain_write_msg,
> +#ifdef CONFIG_IOMMU_API
> +	.irq_write_msi_msg	= gic_pci_msi_domain_write_msg,
> +#else
> +	.irq_write_msi_msg      = pci_msi_domain_write_msg,
> +#endif

Irrespective of the way you implement the translation procedure, you
should make this unconditional, and have the #ifdefery in the code that
implements it.

>  };
>  
>  static struct msi_domain_info gicv2m_msi_domain_info = {
> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> index 8223765..690504e 100644
> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
> @@ -19,6 +19,7 @@
>  #include <linux/of.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_pci.h>
> +#include "irq-gic-common.h"
>  
>  static void its_mask_msi_irq(struct irq_data *d)
>  {
> @@ -37,7 +38,11 @@ static struct irq_chip its_msi_irq_chip = {
>  	.irq_unmask		= its_unmask_msi_irq,
>  	.irq_mask		= its_mask_msi_irq,
>  	.irq_eoi		= irq_chip_eoi_parent,
> +#ifdef CONFIG_IOMMU_API
> +	.irq_write_msi_msg	= gic_pci_msi_domain_write_msg,
> +#else
>  	.irq_write_msi_msg	= pci_msi_domain_write_msg,
> +#endif
>  };
>  
>  struct its_pci_alias {

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.


From mark.rutland at arm.com  Thu Feb 18 03:34:07 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 18 Feb 2016 11:34:07 +0000
Subject: KASAN issues with idle / hotplug area
In-Reply-To: <56C59101.80805@virtuozzo.com>
References: <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
 <20160217170110.GE32647@leverpostej>
 <20160217175656.GJ32647@leverpostej>
 <20160217191643.GK32647@leverpostej>
 <56C57F40.3050500@virtuozzo.com> <56C59101.80805@virtuozzo.com>
Message-ID: <20160218113407.GN32647@leverpostej>

On Thu, Feb 18, 2016 at 12:38:09PM +0300, Andrey Ryabinin wrote:
> 
> 
> On 02/18/2016 11:22 AM, Andrey Ryabinin wrote:
> 
> > I see two options here:
> >  * completely disable instrumentation for drivers/firmware/psci.c
> >  * get back to assembly implementation
> 
> One more option is to allocate struct arm_smccc_res on stack of arm_smccc_[hvc, smc](), and return res.a0
> from arm_smccc_[hvc,smc]().

In general ARM SMCCC calls can return multiple values, and there are
callers that may care (even if they're not here just yet).

So we can't change the arm_smccc_{smc,hvc} prototypes, and adding
another asm function is somewhat self-defeating (an asm caller
of arm_smccc_* is more complex and slower than a direct SMC/HVC).

> So it will look like this:
> 
> asmlinkage unsigned long arm_smccc_hvc(unsigned long a0, unsigned long a1,
> 			unsigned long a2, unsigned long a3, unsigned long a4,
> 			unsigned long a5, unsigned long a6, unsigned long a7);
> 
> 
> static unsigned long __invoke_psci_fn_hvc(unsigned long function_id,
> 			unsigned long arg0, unsigned long arg1,
> 			unsigned long arg2)
> {
> 	return arm_smccc_hvc(function_id, arg0, arg1, arg2, 0, 0, 0, 0);
> }

While this looks like it might work today, it's going to be _extremely_
fragile -- other instrumentation might cause stack allocation and hence
shadow dirtying.

I'm not keen on this.

Thanks,
Mark.


From mark.rutland at arm.com  Thu Feb 18 03:38:34 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 18 Feb 2016 11:38:34 +0000
Subject: KASAN issues with idle / hotplug area
In-Reply-To: <20160218093938.GB12476@red-moon>
References: <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
 <20160217170110.GE32647@leverpostej>
 <20160217175656.GJ32647@leverpostej>
 <20160217191643.GK32647@leverpostej>
 <56C57F40.3050500@virtuozzo.com> <20160218093938.GB12476@red-moon>
Message-ID: <20160218113833.GO32647@leverpostej>

On Thu, Feb 18, 2016 at 09:39:38AM +0000, Lorenzo Pieralisi wrote:
> On Thu, Feb 18, 2016 at 11:22:24AM +0300, Andrey Ryabinin wrote:
> 
> [...]
> 
> > > I also tried using __attribute__((no_sanitize_address)) directly, in
> > > case there was some header issue, but that doesn't seem to be the case.
> > > 
> > > I'm using the Linaro 15.08 AArch64 GCC 5.1. Is anyone else able to
> > > confirm whether they see the same? Does the same happen for x86?
> > > 
> > 
> > Confirming, this happens on every GCC I have (including x86).
> > It seems that 'no_sanitize_address' in gcc removes only memory access checks
> > but it doesn't remove stack redzones.
> > I think this is wrong, e.g. clang removes instrumentation completely. I'll submit a bug.
> > 
> > But we need fix this in kernel.
> > I see two options here:
> >  * completely disable instrumentation for drivers/firmware/psci.c
> 
> We have to have a way to disable instrumentation for functions that
> are used to call into FW and return via different code paths.
> 
> >  * get back to assembly implementation
> 
> No, we are certainly not reverting the SMCCC work because Kasan adds
> instrumentation to C functions, that's not even an option.
> 
> Is it possible at all to implement a function to remove instrumentation
> for a chunk of memory (ie resetting the shadow memory to a clean slate
> for a range of stack addresses) ?

In mm/kasan/kasan.c (which is uninstrumented) there is:

void kasan_unpoison_shadow(const void *address, size_t size)

Mark.


From lorenzo.pieralisi at arm.com  Thu Feb 18 03:41:27 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 18 Feb 2016 11:41:27 +0000
Subject: [PATCH v5 11/15] arm64: head.S: Change the register el2_setup()
 returns its result in x0
In-Reply-To: <1455637767-31561-12-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
 <1455637767-31561-12-git-send-email-james.morse@arm.com>
Message-ID: <20160218114127.GA12626@red-moon>

Hi James,

On Tue, Feb 16, 2016 at 03:49:23PM +0000, James Morse wrote:
> Today el2_setup() returns its result in w20. This means we can't call it
> like any normal function. Change this to w0.
> 
> All three callers of el2_setup() call set_cpu_boot_mode_flag() immediately
> afterwards, and don't rely on x0 in later code. Boot cpu code calls
> preserve_boot_args() before el2_setup(), so we don't clobber the DT pointer.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> ---
>  arch/arm64/include/asm/processor.h |  2 ++
>  arch/arm64/kernel/head.S           | 18 +++++++++---------
>  2 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> index 4acb7ca94fcd..07ac4351538e 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -188,4 +188,6 @@ static inline void spin_lock_prefetch(const void *x)
>  
>  void cpu_enable_pan(void *__unused);
>  
> +int el2_setup(void);

Do we really need to have this declaration (and this patch) ? We never
treat (and call) el2_setup as a C function anyway, as long as the registers
used to pass in values (and return value) are documented I do not think we
have an issue anyway, am I missing something here ?

Thanks,
Lorenzo

> +
>  #endif /* __ASM_PROCESSOR_H */
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 410a2dc04775..5894c7e91e6b 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -206,7 +206,7 @@ section_table:
>  
>  ENTRY(stext)
>  	bl	preserve_boot_args
> -	bl	el2_setup			// Drop to EL1, w20=cpu_boot_mode
> +	bl	el2_setup			// Drop to EL1, w0=cpu_boot_mode
>  	adrp	x24, __PHYS_OFFSET
>  	bl	set_cpu_boot_mode_flag
>  	bl	__create_page_tables		// x25=TTBR0, x26=TTBR1
> @@ -446,8 +446,8 @@ ENDPROC(__mmap_switched)
>   * If we're fortunate enough to boot at EL2, ensure that the world is
>   * sane before dropping to EL1.
>   *
> - * Returns either BOOT_CPU_MODE_EL1 or BOOT_CPU_MODE_EL2 in x20 if
> - * booted in EL1 or EL2 respectively.
> + * Returns either BOOT_CPU_MODE_EL1 or BOOT_CPU_MODE_EL2 if booted in
> + * EL1 or EL2 respectively.
>   */
>  ENTRY(el2_setup)
>  	mrs	x0, CurrentEL
> @@ -462,7 +462,7 @@ CPU_LE(	bic	x0, x0, #(1 << 25)	)	// Clear the EE bit for EL2
>  CPU_BE(	orr	x0, x0, #(3 << 24)	)	// Set the EE and E0E bits for EL1
>  CPU_LE(	bic	x0, x0, #(3 << 24)	)	// Clear the EE and E0E bits for EL1
>  	msr	sctlr_el1, x0
> -	mov	w20, #BOOT_CPU_MODE_EL1		// This cpu booted in EL1
> +	mov	w0, #BOOT_CPU_MODE_EL1		// This cpu booted in EL1
>  	isb
>  	ret
>  
> @@ -538,20 +538,20 @@ CPU_LE(	movk	x0, #0x30d0, lsl #16	)	// Clear EE and E0E on LE systems
>  		      PSR_MODE_EL1h)
>  	msr	spsr_el2, x0
>  	msr	elr_el2, lr
> -	mov	w20, #BOOT_CPU_MODE_EL2		// This CPU booted in EL2
> +	mov	w0, #BOOT_CPU_MODE_EL2		// This CPU booted in EL2
>  	eret
>  ENDPROC(el2_setup)
>  
>  /*
>   * Sets the __boot_cpu_mode flag depending on the CPU boot mode passed
> - * in x20. See arch/arm64/include/asm/virt.h for more info.
> + * in w0. See arch/arm64/include/asm/virt.h for more info.
>   */
>  ENTRY(set_cpu_boot_mode_flag)
>  	adr_l	x1, __boot_cpu_mode
> -	cmp	w20, #BOOT_CPU_MODE_EL2
> +	cmp	w0, #BOOT_CPU_MODE_EL2
>  	b.ne	1f
>  	add	x1, x1, #4
> -1:	str	w20, [x1]			// This CPU has booted in EL1
> +1:	str	w0, [x1]			// This CPU has booted in EL1
>  	dmb	sy
>  	dc	ivac, x1			// Invalidate potentially stale cache line
>  	ret
> @@ -576,7 +576,7 @@ ENTRY(__boot_cpu_mode)
>  	 * cores are held until we're ready for them to initialise.
>  	 */
>  ENTRY(secondary_holding_pen)
> -	bl	el2_setup			// Drop to EL1, w20=cpu_boot_mode
> +	bl	el2_setup			// Drop to EL1, w0=cpu_boot_mode
>  	bl	set_cpu_boot_mode_flag
>  	mrs	x0, mpidr_el1
>  	ldr     x1, =MPIDR_HWID_BITMASK
> -- 
> 2.6.2
> 


From mw at semihalf.com  Thu Feb 18 03:41:40 2016
From: mw at semihalf.com (Marcin Wojtas)
Date: Thu, 18 Feb 2016 12:41:40 +0100
Subject: [PATCH v2 net-next 6/8] net: mvneta: bm: add support for hardware
 buffer management
In-Reply-To: <20160217.234321.1202099534402079240.davem@davemloft.net>
References: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
 <1455636823-14470-7-git-send-email-gregory.clement@free-electrons.com>
 <20160217.234321.1202099534402079240.davem@davemloft.net>
Message-ID: <CAPv3WKfDo8YV1PksBwhVnL6PLeUomxhWgZzhDMZ7fKX95aSPpw@mail.gmail.com>

Hi David,


2016-02-18 5:43 GMT+01:00 David Miller <davem at davemloft.net>:
> From: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Date: Tue, 16 Feb 2016 16:33:41 +0100
>
>>       pp->dev = dev;
>>       SET_NETDEV_DEV(dev, &pdev->dev);
>>
>> +     dev->features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO;
>> +     dev->hw_features |= dev->features;
>> +     dev->vlan_features |= dev->features;
>> +     dev->priv_flags |= IFF_UNICAST_FLT;
>> +     dev->gso_max_segs = MVNETA_MAX_TSO_SEGS;
>> +
>> +     err = register_netdev(dev);
>> +     if (err < 0) {
>> +             dev_err(&pdev->dev, "failed to register\n");
>> +             goto err_free_stats;
>> +     }
>> +
>> +     pp->id = dev->ifindex;
>> +
>> +     /* Obtain access to BM resources if enabled and already initialized */
>> +     bm_node = of_parse_phandle(dn, "buffer-manager", 0);
>> +     if (bm_node && bm_node->data) {
>
> This set of changes has a lot of problems.
>
> First, the exact moment you call register_netdev() your device must be
> fully initialized because ->open() can be invoked immediately.  This
> means you must take care of all of this buffer manager stuff before
> calling register_netdev().
>
> It must precisely be the last thing you invoke in your probe function
> for this reason.

Ok. I shifted register_netdev in order to obtain port id dynamically
from netdev's ifindex (needed to control port <-> pool mapping). If
this order of registration is problematic, I will add an ID property
to DT.

>
> Also you are now adding conditionalized code to every fastpath in your
> driver, that is rediculous and is going to hurt performance.
>
> Add seperate code paths for the HWBM vs SWBM, and register a unique
> set of netdev_ops as appropriate.

TX is untouched and BM support affects only open, stop and change_mtu
- whose execution is not problematic in terms of performance. However
there are a couple new conditions in mvneta_rx(). It can be reduced to
a single condition check, moved to NAPI callback. I'll try to refactor
code in a way to avoid code duplication. Please bear in mind I don't
want to register to different NAPI functions (exactly the same apart
from one line), as the driver can fall back to SWBM after e.g.
unsuccessful mtu change.

Best regards,
Marcin


From aryabinin at virtuozzo.com  Thu Feb 18 03:45:31 2016
From: aryabinin at virtuozzo.com (Andrey Ryabinin)
Date: Thu, 18 Feb 2016 14:45:31 +0300
Subject: KASAN issues with idle / hotplug area
In-Reply-To: <20160218093938.GB12476@red-moon>
References: <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
 <20160217170110.GE32647@leverpostej> <20160217175656.GJ32647@leverpostej>
 <20160217191643.GK32647@leverpostej> <56C57F40.3050500@virtuozzo.com>
 <20160218093938.GB12476@red-moon>
Message-ID: <56C5AEDB.1070507@virtuozzo.com>



On 02/18/2016 12:39 PM, Lorenzo Pieralisi wrote:
> On Thu, Feb 18, 2016 at 11:22:24AM +0300, Andrey Ryabinin wrote:
> 
> [...]
> 
>>> I also tried using __attribute__((no_sanitize_address)) directly, in
>>> case there was some header issue, but that doesn't seem to be the case.
>>>
>>> I'm using the Linaro 15.08 AArch64 GCC 5.1. Is anyone else able to
>>> confirm whether they see the same? Does the same happen for x86?
>>>
>>
>> Confirming, this happens on every GCC I have (including x86).
>> It seems that 'no_sanitize_address' in gcc removes only memory access checks
>> but it doesn't remove stack redzones.
>> I think this is wrong, e.g. clang removes instrumentation completely. I'll submit a bug.
>>
>> But we need fix this in kernel.
>> I see two options here:
>>  * completely disable instrumentation for drivers/firmware/psci.c
> 
> We have to have a way to disable instrumentation for functions that
> are used to call into FW and return via different code paths.
> 

Unfortunately gcc doesn't allow us to do this yet.


>>  * get back to assembly implementation
> 
> No, we are certainly not reverting the SMCCC work because Kasan adds
> instrumentation to C functions, that's not even an option.
> 
> Is it possible at all to implement a function to remove instrumentation
> for a chunk of memory (ie resetting the shadow memory to a clean slate
> for a range of stack addresses) ?
> 


Yes, that's possible. We can tell that function resume SP, it can zero out all shadow for stack bellow that SP.

> Thanks,
> Lorenzo
> 


From aryabinin at virtuozzo.com  Thu Feb 18 03:46:30 2016
From: aryabinin at virtuozzo.com (Andrey Ryabinin)
Date: Thu, 18 Feb 2016 14:46:30 +0300
Subject: KASAN issues with idle / hotplug area
In-Reply-To: <20160218111516.GM32647@leverpostej>
References: <56BDFC86.5010705@arm.com>
 <20160212160652.GL31665@e104818-lin.cambridge.arm.com>
 <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
 <20160217170110.GE32647@leverpostej> <20160217175656.GJ32647@leverpostej>
 <20160217191643.GK32647@leverpostej> <56C57F40.3050500@virtuozzo.com>
 <20160218111516.GM32647@leverpostej>
Message-ID: <56C5AF16.7020904@virtuozzo.com>



On 02/18/2016 02:15 PM, Mark Rutland wrote:
> On Thu, Feb 18, 2016 at 11:22:24AM +0300, Andrey Ryabinin wrote:
>>
>> On 02/17/2016 10:16 PM, Mark Rutland wrote:
>>> Looking at the assembly, functions seem to get instrumented regardless
>>> of the __no_sanitize_address annotation. The assembly of
>>> __invoke_psci_fn_{smc,hvc} look identical, even if one has the
>>> annotation and one does not.
>>>
>>> In the case below, it looks like __invoke_psci_fn_hvc is storing to the
>>> shadow area even though it's anotated with __no_sanitize_address.  Note
>>> that the adrp symbol resolution is bogus; psci_to_linux_errno happens to
>>> be at offset 0 in the as-yet unlinked psci.o object.
>>>
>>
>> ...
>>> I also tried using __attribute__((no_sanitize_address)) directly, in
>>> case there was some header issue, but that doesn't seem to be the case.
>>>
>>> I'm using the Linaro 15.08 AArch64 GCC 5.1. Is anyone else able to
>>> confirm whether they see the same? Does the same happen for x86?
>>
>> Confirming, this happens on every GCC I have (including x86).
>> It seems that 'no_sanitize_address' in gcc removes only memory access checks
>> but it doesn't remove stack redzones.
>> I think this is wrong, e.g. clang removes instrumentation completely. I'll submit a bug.
> 
> Ok.
> 
> Unless there's some clever trickery that we can employ, the above
> renders the Linux __no_sanitize_address annotation useless for this
> style of code.
> 
> We should certianly call that out in the commentary in
> include/linux/compiler-gcc.h.
> 
>> But we need fix this in kernel.
>> I see two options here:
>>  * completely disable instrumentation for drivers/firmware/psci.c
> 
> This is somewhat overkill, and we'd also have to disable instrumentation
> for arch/arm64/kernel/psci.c (for psci_suspend_finisher).
> 
> I would like to have instrumentation for everything we can safely
> instrument.
> 
> This is probably the least worst option, though.
> 
>>  * get back to assembly implementation
> 
> We'd also have to convert psci_suspend_finisher and psci_cpu_suspend,
> the latter being generic code. That goes against the consolidation we
> were aiming for.
> 

Yup, I missed these two.
In that case the only way is to manually unpoison stack.



From pavel at ucw.cz  Thu Feb 18 03:45:30 2016
From: pavel at ucw.cz (Pavel Machek)
Date: Thu, 18 Feb 2016 12:45:30 +0100
Subject: [PATCH v5 11/15] arm64: head.S: Change the register el2_setup()
 returns its result in x0
In-Reply-To: <20160218114127.GA12626@red-moon>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
 <1455637767-31561-12-git-send-email-james.morse@arm.com>
 <20160218114127.GA12626@red-moon>
Message-ID: <20160218114530.GA23804@amd>

On Thu 2016-02-18 11:41:27, Lorenzo Pieralisi wrote:
> Hi James,
> 
> On Tue, Feb 16, 2016 at 03:49:23PM +0000, James Morse wrote:
> > Today el2_setup() returns its result in w20. This means we can't call it
> > like any normal function. Change this to w0.
> > 
> > All three callers of el2_setup() call set_cpu_boot_mode_flag() immediately
> > afterwards, and don't rely on x0 in later code. Boot cpu code calls
> > preserve_boot_args() before el2_setup(), so we don't clobber the DT pointer.
> > 
> > Signed-off-by: James Morse <james.morse at arm.com>
> > ---
> >  arch/arm64/include/asm/processor.h |  2 ++
> >  arch/arm64/kernel/head.S           | 18 +++++++++---------
> >  2 files changed, 11 insertions(+), 9 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
> > index 4acb7ca94fcd..07ac4351538e 100644
> > --- a/arch/arm64/include/asm/processor.h
> > +++ b/arch/arm64/include/asm/processor.h
> > @@ -188,4 +188,6 @@ static inline void spin_lock_prefetch(const void *x)
> >  
> >  void cpu_enable_pan(void *__unused);
> >  
> > +int el2_setup(void);
> 
> Do we really need to have this declaration (and this patch) ? We never
> treat (and call) el2_setup as a C function anyway, as long as the registers
> used to pass in values (and return value) are documented I do not think we
> have an issue anyway, am I missing something here ?

Well, using non-standard calling convention for something that can use
standard one is very ugly at least.

Best regards,
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From zhizhou.zh at gmail.com  Thu Feb 18 03:48:35 2016
From: zhizhou.zh at gmail.com (Zhi-zhou Zhang)
Date: Thu, 18 Feb 2016 19:48:35 +0800
Subject: [PATCH] arm64: add architecture specified current_pt_regs
Message-ID: <1455796115-7844-1-git-send-email-zhizhou.zh@gmail.com>

From: zhizhou <zhizhou.zh at gmail.com>

This patch is based on the implementation of arm. The generic
current_pt_regs is implemented with current->stack. It need to access
memory that would be too expensive.

Signed-off-by: zhizhou <zhizhou.zh at gmail.com>
---
 arch/arm64/include/asm/ptrace.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index e9e5467..1865d54 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -185,5 +185,9 @@ static inline int valid_user_regs(struct user_pt_regs *regs)
 
 extern unsigned long profile_pc(struct pt_regs *regs);
 
+#define current_pt_regs(void) ({ (struct pt_regs *)			\
+	((current_stack_pointer | (THREAD_SIZE - 1)) - 0xf) - 1;	\
+})
+
 #endif /* __ASSEMBLY__ */
 #endif
-- 
2.5.0



From tomi.valkeinen at ti.com  Thu Feb 18 03:52:32 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Thu, 18 Feb 2016 13:52:32 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <20160217213250.GK19428@n2100.arm.linux.org.uk>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <56C438DA.5040109@ti.com>
 <CACRpkdZ+G17hmVP8AejL7NTqg7k0SBC5kgF55ASjD+kfuGFJhQ@mail.gmail.com>
 <20160217213250.GK19428@n2100.arm.linux.org.uk>
Message-ID: <56C5B080.9090007@ti.com>


On 17/02/16 23:32, Russell King - ARM Linux wrote:
> On Wed, Feb 17, 2016 at 05:17:33PM +0100, Linus Walleij wrote:
>> As Russell points out: it's a register that contains a number saying what
>> panel is connected.
>>
>> So it is plug-n-play and I want to preserve this in the patch.
>>
>> The alternative is to make one DTS per display type connected, but that is
>> loosing all the nice plug'n'play :(
> 
> That's totally insane: we're talking about what's plugged in through
> an external connector.  It's not an "internal" device connector.
> These displays are external separate boxes to the board.
> 
> We don't have separate DT files just because we plugged in a USB device
> to a board., or a SDIO card, or an external HDD.

That's because USB, SDIO, HDD are all standard piece of HW, and any
probing can be done via the bus.

For panels we need DT fragments. The question is where these fragments
are and, possibly, who who loads them.

>> But if an overlay can do the same, I'm game for it.
> 
> That's rather eww, because that means you need to either build the
> overlay into the kernel (which IIRC then ties the base DT file to
> that exact kernel) or it needs to sit in userland, which means no
> LCD display until userland is up and running.  It doesn't sound very
> satisfactory, IMHO.

I don't think there are any satisfactory solutions to this.

For me the eww'est option is what this patch does, adding lots of panels
to the .dts, even if the panels are not connected, and having a board
specific fbdev driver. On the other hand, it's easy solution.

One a bit more general question here is: who should know the details of
the board? Is it the bootloader, kernel or userspace? I think the aim
has been to make the kernel drivers generic, not board specific. If so,
it hints either towards the bootloader or userspace. If userspace, the
panels will only be enabled later, when userspace is up.

In my opinion the best option would be to use DT overlays, but so that
the bootloader would supply them, or construct the dtb. But afaik that's
not possible at the moment. And perhaps I think that's the best option
only because I don't work with the bootloaders =).

So, I don't like this, but I don't have a good suggestion how to do it
better with the infrastructure in place at the moment.

We (TI) are struggling with the same problem at the moment (we don't
even have detection capability in all cases), and so far I've refused to
start adding board specific hacks to the display drivers. So I'm very
interested to find a good solution to this too.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160218/768efc8c/attachment.sig>

From catalin.marinas at arm.com  Thu Feb 18 03:58:24 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 18 Feb 2016 11:58:24 +0000
Subject: [PATCH] arm64: add architecture specified current_pt_regs
In-Reply-To: <1455796115-7844-1-git-send-email-zhizhou.zh@gmail.com>
References: <1455796115-7844-1-git-send-email-zhizhou.zh@gmail.com>
Message-ID: <20160218115824.GA2538@e104818-lin.cambridge.arm.com>

On Thu, Feb 18, 2016 at 07:48:35PM +0800, Zhi-zhou Zhang wrote:
> From: zhizhou <zhizhou.zh at gmail.com>
> 
> This patch is based on the implementation of arm. The generic
> current_pt_regs is implemented with current->stack. It need to access
> memory that would be too expensive.

Do you have any performance numbers?

> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> index e9e5467..1865d54 100644
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -185,5 +185,9 @@ static inline int valid_user_regs(struct user_pt_regs *regs)
>  
>  extern unsigned long profile_pc(struct pt_regs *regs);
>  
> +#define current_pt_regs(void) ({ (struct pt_regs *)			\
> +	((current_stack_pointer | (THREAD_SIZE - 1)) - 0xf) - 1;	\
> +})

I don't think this works well with the separate IRQ stack that we merged
in 4.5-rc1. current_thread_info() explicitly uses "sp_el0" while
current_stack_pointer is just "sp" (though I don't think we ever use
current_pt_regs in interrupt context).

-- 
Catalin


From james.morse at arm.com  Thu Feb 18 03:57:37 2016
From: james.morse at arm.com (James Morse)
Date: Thu, 18 Feb 2016 11:57:37 +0000
Subject: [PATCH v5 11/15] arm64: head.S: Change the register el2_setup()
 returns its result in x0
In-Reply-To: <20160218114127.GA12626@red-moon>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
 <1455637767-31561-12-git-send-email-james.morse@arm.com>
 <20160218114127.GA12626@red-moon>
Message-ID: <56C5B1B1.20205@arm.com>

Hi Lorenzo,

On 18/02/16 11:41, Lorenzo Pieralisi wrote:
> On Tue, Feb 16, 2016 at 03:49:23PM +0000, James Morse wrote:
>> Today el2_setup() returns its result in w20. This means we can't call it
>> like any normal function. Change this to w0.
>>
>> All three callers of el2_setup() call set_cpu_boot_mode_flag() immediately
>> afterwards, and don't rely on x0 in later code. Boot cpu code calls
>> preserve_boot_args() before el2_setup(), so we don't clobber the DT pointer.
>>
>> Signed-off-by: James Morse <james.morse at arm.com>
>> ---
>>  arch/arm64/include/asm/processor.h |  2 ++
>>  arch/arm64/kernel/head.S           | 18 +++++++++---------
>>  2 files changed, 11 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
>> index 4acb7ca94fcd..07ac4351538e 100644
>> --- a/arch/arm64/include/asm/processor.h
>> +++ b/arch/arm64/include/asm/processor.h
>> @@ -188,4 +188,6 @@ static inline void spin_lock_prefetch(const void *x)
>>  
>>  void cpu_enable_pan(void *__unused);
>>  
>> +int el2_setup(void);
> 
> Do we really need to have this declaration (and this patch) ? We never
> treat (and call) el2_setup as a C function anyway, as long as the registers
> used to pass in values (and return value) are documented I do not think we
> have an issue anyway, am I missing something here ?

Without this patch swsusp_el2_setup_helper() in patch 14 needs to know that
el2_setup will clobber w20, and save that value somewhere that it knows won't
get clobbered. It didn't seem right to bake all this knowledge into another
function.

Its not quite perfect, as el2_setup() has "msr el2_lr, lr; eret", any caller
needs to know this.

I added the declaration because this now gets called from hibernate-asm.S, but
this doesn't seem to be normal for asm functions. I will remove it from any
future version.


Thanks,

James


From sricharan at codeaurora.org  Thu Feb 18 04:00:08 2016
From: sricharan at codeaurora.org (Sricharan)
Date: Thu, 18 Feb 2016 17:30:08 +0530
Subject: [PATCH v2 2/4] iommu/arm-smmu: Invoke DT probe from
 arm_smmu_of_setup()
In-Reply-To: <1454908652-15317-3-git-send-email-anup.patel@broadcom.com>
References: <1454908652-15317-1-git-send-email-anup.patel@broadcom.com>
 <1454908652-15317-3-git-send-email-anup.patel@broadcom.com>
Message-ID: <001f01d16a43$ef47d3b0$cdd77b10$@codeaurora.org>

Hi,

> -----Original Message-----
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> bounces at lists.infradead.org] On Behalf Of Anup Patel
> Sent: Monday, February 08, 2016 10:48 AM
> To: Catalin Marinas; Joerg Roedel; Will Deacon; Robin Murphy; Sricharan R;
> Linux IOMMU; Linux ARM Kernel
> Cc: Mark Rutland; Device Tree; Scott Branden; Pawel Moll; Ian Campbell;
Ray
> Jui; Linux Kernel; Vikram Prakash; Rob Herring; BCM Kernel Feedback; Kumar
> Gala; Anup Patel
> Subject: [PATCH v2 2/4] iommu/arm-smmu: Invoke DT probe from
> arm_smmu_of_setup()
> 
> The SMMUv1/SMMUv2 driver is initialized very early using the
> IOMMU_OF_DECLARE() but the actual platform device is probed via normal
> DT probing.
> 
> This patch uses of_platform_device_create() from arm_smmu_of_setup() to
> ensure that SMMU platform device is probed immediately.
> 
> Signed-off-by: Anup Patel <anup.patel at broadcom.com>
> ---
>  drivers/iommu/arm-smmu.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index
> 2c8f871..02cd67d 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -40,6 +40,7 @@
>  #include <linux/of.h>
>  #include <linux/of_address.h>
>  #include <linux/of_iommu.h>
> +#include <linux/of_platform.h>
>  #include <linux/pci.h>
>  #include <linux/platform_device.h>
>  #include <linux/slab.h>
> @@ -1956,10 +1957,15 @@ static int __init arm_smmu_init(void)
> 
>  static int __init arm_smmu_of_setup(struct device_node *np)  {
> +	struct platform_device *pdev;
> 
>  	if (!init_done)
>  		arm_smmu_init();
> 
> +	pdev = of_platform_device_create(np, NULL, NULL);
> +	if (IS_ERR(pdev))
> +		return PTR_ERR(pdev);
> +
>  	of_iommu_set_ops(np, &arm_smmu_ops);

 A question here is,  There was a probe deferral series [1], to take care of
deferred
 probing of devices behind iommus. With that this sort of early device
probing during setup
 should not be required and also it clears other dependencies of iommus on
clocks, etc, if any.
 My intention was to check whats the right way to do this  ? (or) point me
to any updates 
 on the probe deferral series that I miss ?

[1]  http://lkml.iu.edu/hypermail/linux/kernel/1505.3/03280.html
 
Regards,
 Sricharan



From james.morse at arm.com  Thu Feb 18 04:00:00 2016
From: james.morse at arm.com (James Morse)
Date: Thu, 18 Feb 2016 12:00:00 +0000
Subject: [PATCH v5 15/15] arm64: hibernate: Prevent resume from a different
 kernel version
In-Reply-To: <36DF59CE26D8EE47B0655C516E9CE640286C4F3C@shsmsx102.ccr.corp.intel.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
 <1455637767-31561-16-git-send-email-james.morse@arm.com>
 <20160216201557.GA6526@amd>
 <36DF59CE26D8EE47B0655C516E9CE640286C4F3C@shsmsx102.ccr.corp.intel.com>
Message-ID: <56C5B240.40400@arm.com>

On 17/02/16 02:20, Chen, Yu C wrote:
>> On Tue 2016-02-16 15:49:27, James Morse wrote:
>>> Resuming using a different kernel version is fragile, while there are
>>> sufficient details in the hibernate arch-header to perform the
>>> restore, changes in the boot process can have a long-lasting impact on the
>> system.
>>> In particular, if the EFI stub causes more memory to be allocated, the
>>> amount of memory left for linux is reduced. If we are lucky, this will
>>> cause restore to fail with the message:
>>
>> Well, this does not close the door completely. 4.6-rc0 is going to be very
>> different from 4.6-rc1. Better solution would be to increase version every
>> time EFI stub changes, or maybe record ammount of memory reserved for
>> EFI.

I hadn't even considered rcs. Maybe this should be changed to UTS_VERSION.
(There isn't enough space for the struct new_utsname)


> This reminds me a similar problem I once encountered on x86 : - )
> The efi memory layout should be strictly the same before/after hibernation, right?

The kernel hopes it is the same, as the page-tables it uses for runtime services
calls are restored along with the rest of memory, but there is the risk
that these don't match the EFI memory map any more.

Even if the amount of memory is the same, the layout might be different. (Core
hibernate code already has a counter of the number of physical pages.)

I'm still digging through the efi code (and spec), but it is fairly easy to
cause the memory map to change before entry to linux. This doesn't seem to be a
problem, as linux happily overwrites most of the allocated areas, so it may not
be as fragile as I thought.

I received the above 'memory size' error when rebasing between v4.4 and
v4.5-rc1, (Ard's KASLR patches may have been involved too).


Thanks,

James


From maitysanchayan at gmail.com  Thu Feb 18 04:01:01 2016
From: maitysanchayan at gmail.com (maitysanchayan at gmail.com)
Date: Thu, 18 Feb 2016 17:31:01 +0530
Subject: Query on using nvmem consumer API
Message-ID: <20160218120100.GA11366@Sanchayan-Arch.toradex.int>

Hello Srinivas,

I have a device tree node as follows

                        ocotp: ocotp at 400a5000 {
                                compatible = "fsl,vf610-ocotp";
                                #address-cells = <1>;
                                #size-cells = <1>;
                                reg = <0x400a5000 0xCF0>;
                                clocks = <&clks VF610_CLK_OCOTP>;

                                ocotp_cfg: cfg at 410 {
                                        reg = <0x410 0x20>;
                                };
                        };

and a nvmem data consumer node as follows

        soc-bus {
                compatible = "fsl,vf610-soc-bus";
                nvmem = <&ocotp>;
                nvmem-names = "ocotp";
                nvmem-cell = <&ocotp_cfg>;
                nvmem-cell-names = "soc_id";
                status = "okay";
        };

I believe my device tree node entries are incorrect. I did like to
use the devm_nvmem_device/cell_get functions and then read using
cell or device consumer API's. I am looking at the NVMEM bindings
but it is not clear to me as to what the correct DT entries and
the corresponding arguments to devm_nvmem_device/cell_get should
be?

Can you help me out with as to what the correct entries and calls
should be?

I currently have
devm_nvmem_device_get(dev, "ocotp");
devm_nvmem_cell_get(dev, "soc_id");

where dev would be the soc-bus device.

Thanks & Regards,
Sanchayan.


From mark.rutland at arm.com  Thu Feb 18 04:08:05 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 18 Feb 2016 12:08:05 +0000
Subject: KASAN issues with idle / hotplug area
In-Reply-To: <56C5AF16.7020904@virtuozzo.com>
References: <56C1E072.2090909@virtuozzo.com>
 <20160215185957.GB19413@e104818-lin.cambridge.arm.com>
 <56C31D1D.50708@virtuozzo.com> <20160217143950.GC32647@leverpostej>
 <20160217170110.GE32647@leverpostej>
 <20160217175656.GJ32647@leverpostej>
 <20160217191643.GK32647@leverpostej>
 <56C57F40.3050500@virtuozzo.com>
 <20160218111516.GM32647@leverpostej>
 <56C5AF16.7020904@virtuozzo.com>
Message-ID: <20160218120805.GP32647@leverpostej>

On Thu, Feb 18, 2016 at 02:46:30PM +0300, Andrey Ryabinin wrote:
> 
> On 02/18/2016 02:15 PM, Mark Rutland wrote:
> > On Thu, Feb 18, 2016 at 11:22:24AM +0300, Andrey Ryabinin wrote:
> >> I see two options here:
> >>  * completely disable instrumentation for drivers/firmware/psci.c
> > 
> > This is somewhat overkill, and we'd also have to disable instrumentation
> > for arch/arm64/kernel/psci.c (for psci_suspend_finisher).
> > 
> > I would like to have instrumentation for everything we can safely
> > instrument.
> > 
> > This is probably the least worst option, though.
> > 
> >>  * get back to assembly implementation
> > 
> > We'd also have to convert psci_suspend_finisher and psci_cpu_suspend,
> > the latter being generic code. That goes against the consolidation we
> > were aiming for.
> > 
> 
> Yup, I missed these two.
> In that case the only way is to manually unpoison stack.

I'm prototyping this now.

Mark.


From ard.biesheuvel at linaro.org  Thu Feb 18 04:16:05 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 18 Feb 2016 13:16:05 +0100
Subject: [PATCH v2 1/2] efi: esrt: use memremap not ioremap to access ESRT
 table in memory
In-Reply-To: <20160218104407.GC2651@codeblueprint.co.uk>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160218104407.GC2651@codeblueprint.co.uk>
Message-ID: <CAKv+Gu_AW7PKJJOd2mbEu3LKJe+gNaPHnH=sgO=YXM_KWFyKxw@mail.gmail.com>

On 18 February 2016 at 11:44, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> On Mon, 15 Feb, at 12:32:32PM, Ard Biesheuvel wrote:
>> On ARM and arm64, ioremap() and memremap() are not interchangeable like
>> on x86, and the use of ioremap() on ordinary RAM is typically flagged
>> as an error if the memory region being mapped is also covered by the
>> linear mapping, since that would lead to aliases with conflicting
>> cacheability attributes.
>>
>> Since what we are dealing with is not an I/O region with side effects,
>> using ioremap() here is arguably incorrect anyway, so let's replace
>> it with memremap instead. Also add a missing unmap on the success path,
>> and drop a memblock_remove() call which does not belong here, this far
>> into the boot sequence.
>>
>> Cc: Peter Jones <pjones at redhat.com>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> ---
>>  drivers/firmware/efi/esrt.c | 16 ++++++++--------
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
>
> [...]
>
>> @@ -432,8 +434,6 @@ static int __init esrt_sysfs_init(void)
>>       if (error)
>>               goto err_cleanup_list;
>>
>> -     memblock_remove(esrt_data, esrt_data_size);
>> -
>>       pr_debug("esrt-sysfs: loaded.\n");
>>
>>       return 0;
>
> Shouldn't we be replacing memblock_remove() with free_bootmem_late()?
> The original ESRT region is still reserved at this point, so we should
> do our best to release it to the page allocator.

I'd rather we keep it reserved. That way, the config table entry still
points to something valid, which could be useful for kexec(), I think?
At least, that is how I intended to handle config tables on ARM ...


From arnd at arndb.de  Thu Feb 18 04:16:28 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 13:16:28 +0100
Subject: [PATCH v3 09/10] ARM: dts: introduce MPS2 AN385/AN386
In-Reply-To: <56C5A742.8010304@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <7245560.jfhuhtPsB8@wuerfel> <56C5A742.8010304@arm.com>
Message-ID: <5567140.dIBhKTnriP@wuerfel>

On Thursday 18 February 2016 11:13:06 Vladimir Murzin wrote:
> On 18/02/16 10:45, Arnd Bergmann wrote:
> > On Thursday 18 February 2016 10:11:37 Vladimir Murzin wrote:
> >>
> >> Right, I thought in a wrong way, in opposite it makes more sense now.
> >>
> >> .dtsi
> >>
> >> /* below the soc/ */
> >> smb {
> >>         compatible = "simple-bus";
> >>         #address-cells = <2>;
> >>         #size-cells = <1>;
> >>         ranges = <0 0 0x40200000 0x10000>,
> >>                  <1 0 0xa0000000 0x10000>;
> >> };
> > 
> > That looks good, yes.
> > 
> > Is 0x10000 the correct maximum addressable size of the external bus
> > in both cases?
> > 
> > Intuitively, I would guess that the 0xa0000000 range might
> > be much wider.
> 
> There is only Ethernet connected to this bus (apart from PSRAM), so it
> might be wider, but there is no indication of this in documentation.

I see this called "ahb_to_extmem16" in the documentation, which indicates
that it might be use 16 bits of address space, which would match
the 64K you listed.

For SSRAM1 / SSRAM2 / SSRAM3, a 8 MB address space is mentioned
and 16 MB for external PSRAM at 0x21000000.

	Arnd




From romain.perier at gmail.com  Thu Feb 18 04:20:00 2016
From: romain.perier at gmail.com (Romain Perier)
Date: Thu, 18 Feb 2016 13:20:00 +0100
Subject: [PATCH 1/2] ARM: meson: Adding support to retrieve serial and SoC
 revision
In-Reply-To: <CAOQ7t2b8N+w33zKMfedtQqJ+-u1=kGn0pK4cBXhXB8LGx6qrtQ@mail.gmail.com>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <1455730114-2547-2-git-send-email-romain.perier@gmail.com>
 <CAOQ7t2b8N+w33zKMfedtQqJ+-u1=kGn0pK4cBXhXB8LGx6qrtQ@mail.gmail.com>
Message-ID: <CABgxDoKOUd_k4kmrcswnUCaKAN8KQ11f8dUTMXDisySp_SVcMA@mail.gmail.com>

Hi all,

2016-02-17 21:34 GMT+01:00 Carlo Caione <carlo at caione.org>:
> On Wed, Feb 17, 2016 at 6:28 PM, Romain Perier <romain.perier at gmail.com> wrote:
>> This path adds support to get the revision and the serial of the running
>> SoC, on Meson8. On these plaforms, these informations can be found into
>
> no Meson8b or Meson6?

Well, I only tested on Meson8b, I don't know if it works in the same
way on older Meson, however I can take a look to the vendor kernel
probably...

>
>> CBUS registers. To do so, we instanciate a syscon register, then create
>
> What you mean with syscon register?


I mean that we use a syscon regmap to access these registers.


>
>> a soc_device, and finally we expose everything to the system.
>>
>> Signed-off-by: Romain Perier <romain.perier at gmail.com>
>> ---
>>  arch/arm/mach-meson/meson.c | 55 +++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 55 insertions(+)
>>
>> diff --git a/arch/arm/mach-meson/meson.c b/arch/arm/mach-meson/meson.c
>> index 4e23571..2816e30 100644
>> --- a/arch/arm/mach-meson/meson.c
>> +++ b/arch/arm/mach-meson/meson.c
>> @@ -13,8 +13,16 @@
>>   *
>>   */
>>
>> +#include <linux/of_address.h>
>>  #include <linux/of_platform.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/regmap.h>
>> +#include <linux/slab.h>
>> +#include <linux/sys_soc.h>
>>  #include <asm/mach/arch.h>
>> +#include <asm/system_info.h>
>> +
>> +#define MESON_REVISION_REG (0x45c)
>>
>>  static const char * const meson_common_board_compat[] = {
>>         "amlogic,meson6",
>> @@ -23,7 +31,54 @@ static const char * const meson_common_board_compat[] = {
>>         NULL,
>>  };
>>
>> +static void __init meson_init_machine(void)
>> +{
>> +       struct soc_device_attribute *soc_dev_attr;
>> +       struct soc_device *soc_dev;
>> +       struct regmap *hwrev;
>> +       unsigned int val;
>> +       int ret;
>> +
>> +       hwrev = syscon_regmap_lookup_by_compatible("amlogic,meson8b-hwrev");
>
> Is this specific only for Meson8b?


For now, yes. However, As I said, I can to do something generic. What
do you think ?


>
>> +       if (IS_ERR(hwrev)) {
>> +               pr_err("hwrev node not found\n");
>> +               return;
>> +       }
>> +
>> +       soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
>> +       if (!soc_dev_attr)
>> +               return;
>
> Missing blank line
>
>> +       ret = regmap_read(hwrev, 0, &val);
>> +       if (ret < 0) {
>> +               pr_err("Could not get SoC id\n");
>
> kfree(soc_dev_attr)
>
>> +               return;
>> +       }
>> +       system_serial_high = val << 24;
>> +
>> +       ret = regmap_read(hwrev, MESON_REVISION_REG, &val);
>> +       if (ret < 0) {
>> +               pr_err("Could not get SoC revision\n");
>
> ditto
>
>> +               return;
>> +       }
>> +       system_rev = val == 0x11111111 ? 0xA : 0xB;
>> +
>> +       soc_dev_attr->family = "Amlogic Meson";
>> +       soc_dev_attr->revision = kasprintf(GFP_KERNEL, "0x%x", system_rev);
>> +       soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "0x%x", system_serial_high);
>> +
>> +       soc_dev = soc_device_register(soc_dev_attr);
>> +       if (IS_ERR(soc_dev)) {
>> +               pr_err("Could not register soc device\n");
>> +               kfree(soc_dev_attr);
>
> leaking soc_dev_attr->revision and  soc_dev_attr->soc_id also any
> reason why you are not kasprintf-ing also family?
>

My problem is that I cannot use a devm allocation there, right ? I
mean I have no device... Well, I will think about it.

>> +               return;
>> +       }
>> +
>> +       pr_info("Amlogic Meson SoC Rev%X (%X:%X)\n", system_rev, system_serial_high, system_rev);
>> +       of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
>
> Compiling I got:
>
>   CC      arch/arm/mach-meson/meson.o
> arch/arm/mach-meson/meson.c: In function 'meson_init_machine':
> arch/arm/mach-meson/meson.c:77:63: warning: passing argument 4 of
> 'of_platform_populate' from incompatible pointer type
>   of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
>                                                                ^
> In file included from arch/arm/mach-meson/meson.c:17:0:
> include/linux/of_platform.h:71:12: note: expected 'struct device *'
> but argument is of type 'struct soc_device *'
>  extern int of_platform_populate(struct device_node *root,
>             ^
>

Ah, good catch ! I build everything using yocto, so I did not see
these warnings ^^

>> +}
>> +
>>  DT_MACHINE_START(MESON, "Amlogic Meson platform")
>> +       .init_machine   = meson_init_machine,
>
> Uhm, you are assuming that this code is valid for Meson8, Meson8b and
> also Meson6. Are you sure about that?

No, you're right.

Thanks,
Romain


From carlo at endlessm.com  Thu Feb 18 04:24:09 2016
From: carlo at endlessm.com (Carlo Caione)
Date: Thu, 18 Feb 2016 13:24:09 +0100
Subject: [PATCH 1/2] ARM: meson: Adding support to retrieve serial and SoC
 revision
In-Reply-To: <CABgxDoKOUd_k4kmrcswnUCaKAN8KQ11f8dUTMXDisySp_SVcMA@mail.gmail.com>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <1455730114-2547-2-git-send-email-romain.perier@gmail.com>
 <CAOQ7t2b8N+w33zKMfedtQqJ+-u1=kGn0pK4cBXhXB8LGx6qrtQ@mail.gmail.com>
 <CABgxDoKOUd_k4kmrcswnUCaKAN8KQ11f8dUTMXDisySp_SVcMA@mail.gmail.com>
Message-ID: <CAL9uMOHLDtQa7dMJm+7VpVJSRJJ+xoG_-Nx1VpJ7S1sL8TS5bw@mail.gmail.com>

On Thu, Feb 18, 2016 at 1:20 PM, Romain Perier <romain.perier at gmail.com> wrote:
> Hi all,

[cut]

>>> +static void __init meson_init_machine(void)
>>> +{
>>> +       struct soc_device_attribute *soc_dev_attr;
>>> +       struct soc_device *soc_dev;
>>> +       struct regmap *hwrev;
>>> +       unsigned int val;
>>> +       int ret;
>>> +
>>> +       hwrev = syscon_regmap_lookup_by_compatible("amlogic,meson8b-hwrev");
>>
>> Is this specific only for Meson8b?
>
>
> For now, yes. However, As I said, I can to do something generic. What
> do you think ?

my guess is that it works fine for meson8 and meson8b. Not sure about
meson6. You should take a look to the Amlogic SDK to confirm that or
just exclude meson6.
I was actually referring to the name of the compatible that seems a
bit too specific to me.

>>
>>> +               return;
>>> +       }
>>> +       system_rev = val == 0x11111111 ? 0xA : 0xB;
>>> +
>>> +       soc_dev_attr->family = "Amlogic Meson";
>>> +       soc_dev_attr->revision = kasprintf(GFP_KERNEL, "0x%x", system_rev);
>>> +       soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "0x%x", system_serial_high);
>>> +
>>> +       soc_dev = soc_device_register(soc_dev_attr);
>>> +       if (IS_ERR(soc_dev)) {
>>> +               pr_err("Could not register soc device\n");
>>> +               kfree(soc_dev_attr);
>>
>> leaking soc_dev_attr->revision and  soc_dev_attr->soc_id also any
>> reason why you are not kasprintf-ing also family?
>>
>
> My problem is that I cannot use a devm allocation there, right ? I
> mean I have no device... Well, I will think about it.

I mean: you are kfree-ing soc_dev_attr but not soc_dev_attr->revision
and soc_dev_attr->soc_id

>>> +               return;
>>> +       }
>>> +
>>> +       pr_info("Amlogic Meson SoC Rev%X (%X:%X)\n", system_rev, system_serial_high, system_rev);
>>> +       of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
>>
>> Compiling I got:
>>
>>   CC      arch/arm/mach-meson/meson.o
>> arch/arm/mach-meson/meson.c: In function 'meson_init_machine':
>> arch/arm/mach-meson/meson.c:77:63: warning: passing argument 4 of
>> 'of_platform_populate' from incompatible pointer type
>>   of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
>>                                                                ^
>> In file included from arch/arm/mach-meson/meson.c:17:0:
>> include/linux/of_platform.h:71:12: note: expected 'struct device *'
>> but argument is of type 'struct soc_device *'
>>  extern int of_platform_populate(struct device_node *root,
>>             ^
>>
>
> Ah, good catch ! I build everything using yocto, so I did not see
> these warnings ^^

Please, do not use yocto for this ;)

Cheers,

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless


From catalin.marinas at arm.com  Thu Feb 18 04:26:09 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 18 Feb 2016 12:26:09 +0000
Subject: [PATCH v2 3/5] arm64: kernel: Add support for User Access Override
In-Reply-To: <1454684330-892-4-git-send-email-james.morse@arm.com>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
 <1454684330-892-4-git-send-email-james.morse@arm.com>
Message-ID: <20160218122608.GB2538@e104818-lin.cambridge.arm.com>

On Fri, Feb 05, 2016 at 02:58:48PM +0000, James Morse wrote:
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
[...]
> @@ -308,6 +312,20 @@ static void tls_thread_switch(struct task_struct *next)
>  	: : "r" (tpidr), "r" (tpidrro));
>  }
>  
> +/* Restore the UAO state depending on next's addr_limit */
> +static void uao_thread_switch(struct task_struct *next)
> +{
> +	unsigned long next_sp = next->thread.cpu_context.sp;
> +
> +	if (IS_ENABLED(CONFIG_ARM64_UAO) &&
> +	    get_thread_info(next_sp)->addr_limit == KERNEL_DS)

Can you not use task_thread_info(next) directly instead of a new
get_thread_info()?

> +		asm(ALTERNATIVE("nop", SET_PSTATE_UAO(1), ARM64_HAS_UAO,
> +			        CONFIG_ARM64_UAO));
> +	else
> +		asm(ALTERNATIVE("nop", SET_PSTATE_UAO(0), ARM64_HAS_UAO,
> +				CONFIG_ARM64_UAO));
> +}

I think we still end up with some empty asm in this function even though
CONFIG_ARM64_UAO is disabled, I'm not sure the compiler will eliminate
it completely. If that's the case, maybe use two nested "if" blocks.

> +
>  /*
>   * Thread switching.
>   */
> @@ -327,6 +345,8 @@ struct task_struct *__switch_to(struct task_struct *prev,
>  	 */
>  	dsb(ish);
>  
> +	uao_thread_switch(next);

We should place this before the dsb(), together with the other switches.
The pstate change should be self synchronising.

-- 
Catalin


From lorenzo.pieralisi at arm.com  Thu Feb 18 04:32:16 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 18 Feb 2016 12:32:16 +0000
Subject: [PATCH V5 04/15] pci, acpi, ecam: Add flag to indicate whether
 ECAM region was hot added or not.
In-Reply-To: <1455630825-27253-5-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
 <1455630825-27253-5-git-send-email-tn@semihalf.com>
Message-ID: <20160218123216.GB12626@red-moon>

On Tue, Feb 16, 2016 at 02:53:34PM +0100, Tomasz Nowicki wrote:
> There are two ways we can get ECAM (aka MCFG) regions using ACPI,
> first from MCFG static table and second from _CBA method. We cannot remove
> static regions, however regions coming from _CBA should be removed while
> removing bridge device.
> 
> In the light of above we need flag to mark hot added ECAM entries
> and user to call pci_mmconfig_insert while adding regions from _CBA method.
> Similarly pci_mmconfig_delete while removing hot added regions.

"According to the PCI firmware specification, ACPI provides two standard
mechanisms to retrieve ECAM memory mapped configuration regions (aka MCFG).
For non-hot-removable bridges, ECAM bridge configurations are retrieved from
the static MCFG table and have to be considered non-hot-removable for the
current boot; hot-removable PCI host bridges configurations are retrieved
through bridges _CBA methods.

When ECAM regions are added through _CBA methods, they can be marked
as hot-added so that, upon respective PCI host bridge hot-removal, they can
be unmapped and deleted in that no longer needed.

This patch adds a flag to MCFG regions allowing to mark them as hot-added,
so that upon corresponding PCI bridge hot-removal they can be deleted since
no longer needed."

> Signed-off-by: Tomasz Nowicki <tn at semihalf.com>
> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit at amd.com>
> Tested-by: Jeremy Linton <jeremy.linton at arm.com>
> Tested-by: Duc Dang <dhdang at apm.com>
> Tested-by: Dongdong Liu <liudongdong3 at huawei.com>
> Tested-by: Hanjun Guo <hanjun.guo at linaro.org>
> Tested-by: Graeme Gregory <graeme.gregory at linaro.org>
> Tested-by: Sinan Kaya <okaya at codeaurora.org>
> ---
>  drivers/acpi/pci_mcfg.c  | 4 +++-
>  include/linux/pci-acpi.h | 1 +
>  2 files changed, 4 insertions(+), 1 deletion(-)

It would be great if x86 people can have a look, we no longer
associate a MCFG region to a bridge structure, the end result
should be equivalent though, so:

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

> 
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index 0467b00..3282f2a 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -74,6 +74,7 @@ static struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
>  	new->segment = segment;
>  	new->start_bus = start;
>  	new->end_bus = end;
> +	new->hot_added = false;
>  
>  	res = &new->res;
>  	res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
> @@ -205,6 +206,7 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
>  	}
>  	rc = pci_mmconfig_map_resource(dev, cfg);
>  	if (!rc) {
> +		cfg->hot_added = true;
>  		list_add_sorted(cfg);
>  		dev_info(dev, "MMCONFIG at %pR (base %#lx)\n",
>  				 &cfg->res, (unsigned long)addr);
> @@ -228,7 +230,7 @@ int pci_mmconfig_delete(u16 seg, u8 start, u8 end)
>  	mutex_lock(&pci_mmcfg_lock);
>  	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
>  		if (cfg->segment == seg && cfg->start_bus == start &&
> -		    cfg->end_bus == end) {
> +		    cfg->end_bus == end && cfg->hot_added) {
>  			list_del_rcu(&cfg->list);
>  			synchronize_rcu();
>  			pci_mmconfig_unmap_resource(cfg);
> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
> index e9450ef..94d8f38 100644
> --- a/include/linux/pci-acpi.h
> +++ b/include/linux/pci-acpi.h
> @@ -119,6 +119,7 @@ struct pci_mmcfg_region {
>  	u8 start_bus;
>  	u8 end_bus;
>  	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
> +	bool hot_added;
>  };
>  
>  extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
> -- 
> 1.9.1
> 


From romain.perier at gmail.com  Thu Feb 18 04:33:04 2016
From: romain.perier at gmail.com (Romain Perier)
Date: Thu, 18 Feb 2016 13:33:04 +0100
Subject: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
In-Reply-To: <CAOQ7t2add21t4hFtTeUBFe9aW0EtNvSi5KS4JMb6qVC60Fj-tA@mail.gmail.com>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <1455730114-2547-3-git-send-email-romain.perier@gmail.com>
 <CAOQ7t2add21t4hFtTeUBFe9aW0EtNvSi5KS4JMb6qVC60Fj-tA@mail.gmail.com>
Message-ID: <CABgxDo+oGe47hvxiCOAUWz8zfSeVONf=3pFm+=PbNsCbr_jTpg@mail.gmail.com>

Hi,

2016-02-17 21:36 GMT+01:00 Carlo Caione <carlo at caione.org>:
> On Wed, Feb 17, 2016 at 6:28 PM, Romain Perier <romain.perier at gmail.com> wrote:
>> These are the CBUS registers used to retrieve the revision and the
>> identifier of the SoC on Meson8.
>>
>> Signed-off-by: Romain Perier <romain.perier at gmail.com>
>> ---
>>  arch/arm/boot/dts/meson8b.dtsi | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
>> index 0477a81..71009dc 100644
>> --- a/arch/arm/boot/dts/meson8b.dtsi
>> +++ b/arch/arm/boot/dts/meson8b.dtsi
>> @@ -99,6 +99,11 @@
>>                 };
>>         };
>>
>> +       hwrev at c1107d4c {
>> +               compatible = "amlogic,meson8b-hwrev", "syscon";
>> +               reg = <0xc1107d4c 0x460>;
>
> Interesting. Where did you get 0x460?

Carlo, Arnd.

Well, what I did is the following :
- CBUS_PHY_BASE is 0xc1100000   (CBUS is a larger block of registers,
like slcr on zynq)
- the serial is at CBUS_PHY_BASE + 0x7d4c
- the revision is at CBUS_PHY_BASE + 0x81a8

So I decided to create a device_node for hw revision at 0xc1107d4c, in
this case the lenght is 0x460...
Am I wrong ?


>
>> +       };
>> +
>>         sram: sram at d9000000 {
>>                 compatible = "mmio-sram";
>>                 reg = <0xd9000000 0x20000>;
>
> This patch fails to apply on the current master. Probably because you
> have based this patch on a repo containing (as I can see) also my WiP
> patches on SMP.

I used linux-next with your patches on top of it yes... I will rebase it

Thanks,
Romain


From liudongdong3 at huawei.com  Thu Feb 18 04:25:35 2016
From: liudongdong3 at huawei.com (liudongdong (C))
Date: Thu, 18 Feb 2016 20:25:35 +0800
Subject: [Linaro-acpi] [PATCH V5 01/15] ACPI: MCFG: Move mmcfg_list
 management to drivers/acpi
In-Reply-To: <1455630825-27253-2-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
 <1455630825-27253-2-git-send-email-tn@semihalf.com>
Message-ID: <56C5B83F.4010602@huawei.com>

Hi Tomasz

? 2016/2/16 21:53, Tomasz Nowicki ??:
> From: Jayachandran C <jchandra at broadcom.com>
>
> Move pci_mmcfg_list handling to a drivers/acpi/pci_mcfg.c. This is
> to share the API and code with ARM64 later. The corresponding
> declarations are moved from asm/pci_x86.h to linux/pci-acpi.h
>
> As a part of this we introduce three functions that can be
> implemented by the arch code: pci_mmconfig_map_resource() to map a
> mcfg entry, pci_mmconfig_unmap_resource to do the corresponding
> unmap and pci_mmconfig_enabled to see if the arch setup of
> mcfg entries was successful. We also provide weak implementations
> of these, which will be used from ARM64. On x86, we retain the
> old logic by providing platform specific implementation.
>
> This patch is purely rearranging code, it should not have any
> impact on the logic of MCFG parsing or list handling.
>
> Signed-off-by: Jayachandran C <jchandra at broadcom.com>
> [Xen parts:]
> Acked-by: David Vrabel <david.vrabel at citrix.com>
> ---
>   arch/x86/include/asm/pci_x86.h |  24 +---
>   arch/x86/pci/mmconfig-shared.c | 269 +++++------------------------------
>   arch/x86/pci/mmconfig_32.c     |   1 +
>   arch/x86/pci/mmconfig_64.c     |   1 +
>   arch/x86/pci/numachip.c        |   1 +
>   drivers/acpi/Makefile          |   1 +
>   drivers/acpi/pci_mcfg.c        | 312 +++++++++++++++++++++++++++++++++++++++++
>   drivers/xen/pci.c              |   5 +-
>   include/linux/pci-acpi.h       |  33 +++++
>   9 files changed, 386 insertions(+), 261 deletions(-)
>   create mode 100644 drivers/acpi/pci_mcfg.c
>
> diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
> index 46873fb..7824626 100644
> --- a/arch/x86/include/asm/pci_x86.h
> +++ b/arch/x86/include/asm/pci_x86.h
> @@ -122,33 +122,11 @@ extern int pci_legacy_init(void);
>   extern void pcibios_fixup_irqs(void);
>
>   /* pci-mmconfig.c */
> -
> -/* "PCI MMCONFIG %04x [bus %02x-%02x]" */
> -#define PCI_MMCFG_RESOURCE_NAME_LEN (22 + 4 + 2 + 2)
> -
> -struct pci_mmcfg_region {
> -	struct list_head list;
> -	struct resource res;
> -	u64 address;
> -	char __iomem *virt;
> -	u16 segment;
> -	u8 start_bus;
> -	u8 end_bus;
> -	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
> -};
> -
> +struct pci_mmcfg_region;
>   extern int __init pci_mmcfg_arch_init(void);
>   extern void __init pci_mmcfg_arch_free(void);
>   extern int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg);
>   extern void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg);
> -extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
> -			       phys_addr_t addr);
> -extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
> -extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
> -
> -extern struct list_head pci_mmcfg_list;
> -
> -#define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
>
>   /*
>    * On AMD Fam10h CPUs, all PCI MMIO configuration space accesses must use
> diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
> index dd30b7e..626710b 100644
> --- a/arch/x86/pci/mmconfig-shared.c
> +++ b/arch/x86/pci/mmconfig-shared.c
> @@ -12,13 +12,12 @@
>
>   #include <linux/pci.h>
>   #include <linux/init.h>
> -#include <linux/sfi_acpi.h>
>   #include <linux/bitmap.h>
> -#include <linux/dmi.h>
>   #include <linux/slab.h>
>   #include <linux/mutex.h>
>   #include <linux/rculist.h>
>   #include <asm/e820.h>
> +#include <linux/pci-acpi.h>
>   #include <asm/pci_x86.h>
>   #include <asm/acpi.h>
>
> @@ -27,9 +26,6 @@
>   /* Indicate if the mmcfg resources have been placed into the resource table. */
>   static bool pci_mmcfg_running_state;
>   static bool pci_mmcfg_arch_init_failed;
> -static DEFINE_MUTEX(pci_mmcfg_lock);
> -
> -LIST_HEAD(pci_mmcfg_list);
>
>   static void __init pci_mmconfig_remove(struct pci_mmcfg_region *cfg)
>   {
> @@ -48,83 +44,6 @@ static void __init free_all_mmcfg(void)
>   		pci_mmconfig_remove(cfg);
>   }
>
> -static void list_add_sorted(struct pci_mmcfg_region *new)
> -{
> -	struct pci_mmcfg_region *cfg;
> -
> -	/* keep list sorted by segment and starting bus number */
> -	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list) {
> -		if (cfg->segment > new->segment ||
> -		    (cfg->segment == new->segment &&
> -		     cfg->start_bus >= new->start_bus)) {
> -			list_add_tail_rcu(&new->list, &cfg->list);
> -			return;
> -		}
> -	}
> -	list_add_tail_rcu(&new->list, &pci_mmcfg_list);
> -}
> -
> -static struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
> -						   int end, u64 addr)
> -{
> -	struct pci_mmcfg_region *new;
> -	struct resource *res;
> -
> -	if (addr == 0)
> -		return NULL;
> -
> -	new = kzalloc(sizeof(*new), GFP_KERNEL);
> -	if (!new)
> -		return NULL;
> -
> -	new->address = addr;
> -	new->segment = segment;
> -	new->start_bus = start;
> -	new->end_bus = end;
> -
> -	res = &new->res;
> -	res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
> -	res->end = addr + PCI_MMCFG_BUS_OFFSET(end + 1) - 1;
> -	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> -	snprintf(new->name, PCI_MMCFG_RESOURCE_NAME_LEN,
> -		 "PCI MMCONFIG %04x [bus %02x-%02x]", segment, start, end);
> -	res->name = new->name;
> -
> -	return new;
> -}
> -
> -static struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
> -							int end, u64 addr)
> -{
> -	struct pci_mmcfg_region *new;
> -
> -	new = pci_mmconfig_alloc(segment, start, end, addr);
> -	if (new) {
> -		mutex_lock(&pci_mmcfg_lock);
> -		list_add_sorted(new);
> -		mutex_unlock(&pci_mmcfg_lock);
> -
> -		pr_info(PREFIX
> -		       "MMCONFIG for domain %04x [bus %02x-%02x] at %pR "
> -		       "(base %#lx)\n",
> -		       segment, start, end, &new->res, (unsigned long)addr);
> -	}
> -
> -	return new;
> -}
> -
> -struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus)
> -{
> -	struct pci_mmcfg_region *cfg;
> -
> -	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
> -		if (cfg->segment == segment &&
> -		    cfg->start_bus <= bus && bus <= cfg->end_bus)
> -			return cfg;
> -
> -	return NULL;
> -}
> -
>   static const char *__init pci_mmcfg_e7520(void)
>   {
>   	u32 win;
> @@ -543,73 +462,6 @@ static void __init pci_mmcfg_reject_broken(int early)
>   	}
>   }
>
> -static int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
> -					struct acpi_mcfg_allocation *cfg)
> -{
> -	int year;
> -
> -	if (cfg->address < 0xFFFFFFFF)
> -		return 0;
> -
> -	if (!strncmp(mcfg->header.oem_id, "SGI", 3))
> -		return 0;
> -
> -	if (mcfg->header.revision >= 1) {
> -		if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) &&
> -		    year >= 2010)
> -			return 0;
> -	}
> -
> -	pr_err(PREFIX "MCFG region for %04x [bus %02x-%02x] at %#llx "
> -	       "is above 4GB, ignored\n", cfg->pci_segment,
> -	       cfg->start_bus_number, cfg->end_bus_number, cfg->address);
> -	return -EINVAL;
> -}
> -
> -static int __init pci_parse_mcfg(struct acpi_table_header *header)
> -{
> -	struct acpi_table_mcfg *mcfg;
> -	struct acpi_mcfg_allocation *cfg_table, *cfg;
> -	unsigned long i;
> -	int entries;
> -
> -	if (!header)
> -		return -EINVAL;
> -
> -	mcfg = (struct acpi_table_mcfg *)header;
> -
> -	/* how many config structures do we have */
> -	free_all_mmcfg();
> -	entries = 0;
> -	i = header->length - sizeof(struct acpi_table_mcfg);
> -	while (i >= sizeof(struct acpi_mcfg_allocation)) {
> -		entries++;
> -		i -= sizeof(struct acpi_mcfg_allocation);
> -	}
> -	if (entries == 0) {
> -		pr_err(PREFIX "MMCONFIG has no entries\n");
> -		return -ENODEV;
> -	}
> -
> -	cfg_table = (struct acpi_mcfg_allocation *) &mcfg[1];
> -	for (i = 0; i < entries; i++) {
> -		cfg = &cfg_table[i];
> -		if (acpi_mcfg_check_entry(mcfg, cfg)) {
> -			free_all_mmcfg();
> -			return -ENODEV;
> -		}
> -
> -		if (pci_mmconfig_add(cfg->pci_segment, cfg->start_bus_number,
> -				   cfg->end_bus_number, cfg->address) == NULL) {
> -			pr_warn(PREFIX "no memory for MCFG entries\n");
> -			free_all_mmcfg();
> -			return -ENOMEM;
> -		}
> -	}
> -
> -	return 0;
> -}
> -
>   #ifdef CONFIG_ACPI_APEI
>   extern int (*arch_apei_filter_addr)(int (*func)(__u64 start, __u64 size,
>   				     void *data), void *data);
> @@ -662,13 +514,20 @@ static void __init __pci_mmcfg_init(int early)
>
>   static int __initdata known_bridge;
>
> +static void __init pci_mmcfg_list_setup(void)
> +{
> +	free_all_mmcfg();
> +	if (pci_mmconfig_parse_table())
> +		free_all_mmcfg();
> +}
> +
>   void __init pci_mmcfg_early_init(void)
>   {
>   	if (pci_probe & PCI_PROBE_MMCONF) {
>   		if (pci_mmcfg_check_hostbridge())
>   			known_bridge = 1;
>   		else
> -			acpi_sfi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg);
> +			pci_mmcfg_list_setup();
>   		__pci_mmcfg_init(1);
>
>   		set_apei_filter();
> @@ -686,7 +545,7 @@ void __init pci_mmcfg_late_init(void)
>
>   	/* MMCONFIG hasn't been enabled yet, try again */
>   	if (pci_probe & PCI_PROBE_MASK & ~PCI_PROBE_MMCONF) {
> -		acpi_sfi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg);
> +		pci_mmcfg_list_setup();
>   		__pci_mmcfg_init(0);
>   	}
>   }
> @@ -720,99 +579,41 @@ static int __init pci_mmcfg_late_insert_resources(void)
>    */
>   late_initcall(pci_mmcfg_late_insert_resources);
>
> -/* Add MMCFG information for host bridges */
> -int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
> -			phys_addr_t addr)
> +int pci_mmconfig_map_resource(struct device *dev, struct pci_mmcfg_region *cfg)
>   {
> -	int rc;
> -	struct resource *tmp = NULL;
> -	struct pci_mmcfg_region *cfg;
> +	struct resource *tmp;
>
> -	if (!(pci_probe & PCI_PROBE_MMCONF) || pci_mmcfg_arch_init_failed)
> -		return -ENODEV;
> -
> -	if (start > end)
> -		return -EINVAL;
> -
> -	mutex_lock(&pci_mmcfg_lock);
> -	cfg = pci_mmconfig_lookup(seg, start);
> -	if (cfg) {
> -		if (cfg->end_bus < end)
> -			dev_info(dev, FW_INFO
> -				 "MMCONFIG for "
> -				 "domain %04x [bus %02x-%02x] "
> -				 "only partially covers this bridge\n",
> -				  cfg->segment, cfg->start_bus, cfg->end_bus);
> -		mutex_unlock(&pci_mmcfg_lock);
> -		return -EEXIST;
> -	}
> -
> -	if (!addr) {
> -		mutex_unlock(&pci_mmcfg_lock);
> -		return -EINVAL;
> -	}
> -
> -	rc = -EBUSY;
> -	cfg = pci_mmconfig_alloc(seg, start, end, addr);
> -	if (cfg == NULL) {
> -		dev_warn(dev, "fail to add MMCONFIG (out of memory)\n");
> -		rc = -ENOMEM;
> -	} else if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
> +	if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
>   		dev_warn(dev, FW_BUG "MMCONFIG %pR isn't reserved\n",
>   			 &cfg->res);
> -	} else {
> -		/* Insert resource if it's not in boot stage */
> -		if (pci_mmcfg_running_state)
> -			tmp = insert_resource_conflict(&iomem_resource,
> -						       &cfg->res);
> -
> +		return -EBUSY;
> +	}
> +	/* Insert resource if it's not in boot stage */
> +	if (pci_mmcfg_running_state) {
> +		tmp = insert_resource_conflict(&iomem_resource,
> +					       &cfg->res);
>   		if (tmp) {
> -			dev_warn(dev,
> -				 "MMCONFIG %pR conflicts with "
> -				 "%s %pR\n",
> -				 &cfg->res, tmp->name, tmp);
> -		} else if (pci_mmcfg_arch_map(cfg)) {
> -			dev_warn(dev, "fail to map MMCONFIG %pR.\n",
> -				 &cfg->res);
> -		} else {
> -			list_add_sorted(cfg);
> -			dev_info(dev, "MMCONFIG at %pR (base %#lx)\n",
> -				 &cfg->res, (unsigned long)addr);
> -			cfg = NULL;
> -			rc = 0;
> +			dev_warn(dev, "MMCONFIG %pR conflicts with %s %pR\n",
> +				&cfg->res, tmp->name, tmp);
> +			return -EBUSY;
>   		}
>   	}
> -
> -	if (cfg) {
> -		if (cfg->res.parent)
> -			release_resource(&cfg->res);
> -		kfree(cfg);
> +	if (pci_mmcfg_arch_map(cfg)) {
> +		dev_warn(dev, "fail to map MMCONFIG %pR.\n", &cfg->res);
> +		return -EBUSY;
>   	}
> -
> -	mutex_unlock(&pci_mmcfg_lock);
> -
> -	return rc;
> +	return 0;
>   }
>
> -/* Delete MMCFG information for host bridges */
> -int pci_mmconfig_delete(u16 seg, u8 start, u8 end)
> +void pci_mmconfig_unmap_resource(struct pci_mmcfg_region *cfg)
>   {
> -	struct pci_mmcfg_region *cfg;
> -
> -	mutex_lock(&pci_mmcfg_lock);
> -	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
> -		if (cfg->segment == seg && cfg->start_bus == start &&
> -		    cfg->end_bus == end) {
> -			list_del_rcu(&cfg->list);
> -			synchronize_rcu();
> -			pci_mmcfg_arch_unmap(cfg);
> -			if (cfg->res.parent)
> -				release_resource(&cfg->res);
> -			mutex_unlock(&pci_mmcfg_lock);
> -			kfree(cfg);
> -			return 0;
> -		}
> -	mutex_unlock(&pci_mmcfg_lock);
> +	pci_mmcfg_arch_unmap(cfg);
> +	if (cfg->res.parent)
> +		release_resource(&cfg->res);
> +	cfg->res.parent = NULL;
> +}
>
> -	return -ENOENT;
> +int pci_mmconfig_enabled(void)
> +{
> +	return (pci_probe & PCI_PROBE_MMCONF) && !pci_mmcfg_arch_init_failed;
>   }
> diff --git a/arch/x86/pci/mmconfig_32.c b/arch/x86/pci/mmconfig_32.c
> index 43984bc..38a37f8 100644
> --- a/arch/x86/pci/mmconfig_32.c
> +++ b/arch/x86/pci/mmconfig_32.c
> @@ -12,6 +12,7 @@
>   #include <linux/pci.h>
>   #include <linux/init.h>
>   #include <linux/rcupdate.h>
> +#include <linux/pci-acpi.h>
>   #include <asm/e820.h>
>   #include <asm/pci_x86.h>
>
> diff --git a/arch/x86/pci/mmconfig_64.c b/arch/x86/pci/mmconfig_64.c
> index bea5249..29253ec 100644
> --- a/arch/x86/pci/mmconfig_64.c
> +++ b/arch/x86/pci/mmconfig_64.c
> @@ -10,6 +10,7 @@
>   #include <linux/acpi.h>
>   #include <linux/bitmap.h>
>   #include <linux/rcupdate.h>
> +#include <linux/pci-acpi.h>
>   #include <asm/e820.h>
>   #include <asm/pci_x86.h>
>
> diff --git a/arch/x86/pci/numachip.c b/arch/x86/pci/numachip.c
> index 2e565e6..c181eeb 100644
> --- a/arch/x86/pci/numachip.c
> +++ b/arch/x86/pci/numachip.c
> @@ -14,6 +14,7 @@
>    */
>
>   #include <linux/pci.h>
> +#include <linux/pci-acpi.h>
>   #include <asm/pci_x86.h>
>
>   static u8 limit __read_mostly;
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 7ea903d..e5e4393 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -40,6 +40,7 @@ acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
>   acpi-y				+= ec.o
>   acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
>   acpi-y				+= pci_root.o pci_link.o pci_irq.o
> +acpi-$(CONFIG_PCI_MMCONFIG)	+= pci_mcfg.o
>   acpi-y				+= acpi_lpss.o acpi_apd.o
>   acpi-y				+= acpi_platform.o
>   acpi-y				+= acpi_pnp.o
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> new file mode 100644
> index 0000000..ea84365
> --- /dev/null
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -0,0 +1,312 @@
> +/*
> + * pci_mcfg.c
> + *
> + * Common code to maintain the MCFG areas and mappings
> + *
> + * This has been extracted from arch/x86/pci/mmconfig-shared.c
> + * and moved here so that other architectures can use this code.
> + */
> +
> +#include <linux/pci.h>
> +#include <linux/init.h>
> +#include <linux/dmi.h>
> +#include <linux/pci-acpi.h>
> +#include <linux/sfi_acpi.h>
> +#include <linux/slab.h>
> +#include <linux/mutex.h>
> +#include <linux/rculist.h>
> +
> +#define PREFIX	"ACPI: "
> +
> +static DEFINE_MUTEX(pci_mmcfg_lock);
> +LIST_HEAD(pci_mmcfg_list);
> +
> +static void list_add_sorted(struct pci_mmcfg_region *new)
> +{
> +	struct pci_mmcfg_region *cfg;
> +
> +	/* keep list sorted by segment and starting bus number */
> +	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list) {
> +		if (cfg->segment > new->segment ||
> +		    (cfg->segment == new->segment &&
> +		     cfg->start_bus >= new->start_bus)) {
> +			list_add_tail_rcu(&new->list, &cfg->list);
> +			return;
> +		}
> +	}
> +	list_add_tail_rcu(&new->list, &pci_mmcfg_list);
> +}
> +
> +static struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
> +						   int end, u64 addr)
> +{
> +	struct pci_mmcfg_region *new;
> +	struct resource *res;
> +
> +	if (addr == 0)
> +		return NULL;
> +
> +	new = kzalloc(sizeof(*new), GFP_KERNEL);
> +	if (!new)
> +		return NULL;
> +
> +	new->address = addr;
> +	new->segment = segment;
> +	new->start_bus = start;
> +	new->end_bus = end;
> +
> +	res = &new->res;
> +	res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
> +	res->end = addr + PCI_MMCFG_BUS_OFFSET(end + 1) - 1;
> +	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
> +	snprintf(new->name, PCI_MMCFG_RESOURCE_NAME_LEN,
> +		 "PCI MMCONFIG %04x [bus %02x-%02x]", segment, start, end);
> +	res->name = new->name;
> +
> +	return new;
> +}
> +
> +struct pci_mmcfg_region *pci_mmconfig_add(int segment, int start,
> +							int end, u64 addr)
> +{
> +	struct pci_mmcfg_region *new;
> +
> +	new = pci_mmconfig_alloc(segment, start, end, addr);
> +	if (new) {
> +		mutex_lock(&pci_mmcfg_lock);
> +		list_add_sorted(new);
> +		mutex_unlock(&pci_mmcfg_lock);
> +
> +		pr_info(PREFIX
> +		       "MMCONFIG for domain %04x [bus %02x-%02x] at %pR "
> +		       "(base %#lx)\n",
> +		       segment, start, end, &new->res, (unsigned long)addr);
> +	}
> +
> +	return new;
> +}
> +
> +struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus)
> +{
> +	struct pci_mmcfg_region *cfg;
> +
> +	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
> +		if (cfg->segment == segment &&
> +		    cfg->start_bus <= bus && bus <= cfg->end_bus)
> +			return cfg;
> +
> +	return NULL;
> +}
> +
> +/*
> + * Map a pci_mmcfg_region, can be overrriden by arch
> + */
> +int __weak pci_mmconfig_map_resource(struct device *dev,
> +	struct pci_mmcfg_region *mcfg)
> +{
> +	struct resource *tmp;
> +	void __iomem *vaddr;
> +
> +	tmp = insert_resource_conflict(&iomem_resource, &mcfg->res);
> +	if (tmp) {
> +		dev_warn(dev, "MMCONFIG %pR conflicts with %s %pR\n",
> +			&mcfg->res, tmp->name, tmp);
> +		return -EBUSY;
> +	}
> +
> +	vaddr =  ioremap(mcfg->res.start, resource_size(&mcfg->res));
> +	if (!vaddr) {
> +		release_resource(&mcfg->res);
> +		return -ENOMEM;
> +	}
> +
> +	mcfg->virt = vaddr;
Here should be changed to
	mcfg->virt = vaddr - PCI_MMCFG_BUS_OFFSET(mcfg->start_bus);

or when pcie host "start_bus" is not 0, the configuraion access will be wrong.

See v3 or v4 patchset "addr -= PCI_MMCFG_BUS_OFFSET(cfg->start_bus);"
static void __iomem *mcfg_ioremap(struct pci_mmcfg_region *cfg)
{
	void __iomem *addr;
	u64 start, size;
	int num_buses;

	start = cfg->address + PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
	num_buses = cfg->end_bus - cfg->start_bus + 1;
	size = PCI_MMCFG_BUS_OFFSET(num_buses);
	addr = ioremap_nocache(start, size);
	if (addr)
		addr -= PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
	return addr;
}

Dongdong
Thanks

> +	return 0;
> +}
> +
> +/*
> + * Unmap a pci_mmcfg_region, can be overrriden by arch
> + */
> +void __weak pci_mmconfig_unmap_resource(struct pci_mmcfg_region *mcfg)
> +{
> +	if (mcfg->virt) {
> +		iounmap(mcfg->virt);
> +		mcfg->virt = NULL;
> +	}
> +	if (mcfg->res.parent) {
> +		release_resource(&mcfg->res);
> +		mcfg->res.parent = NULL;
> +	}
> +}
> +
> +/*
> + * check if the mmconfig is enabled and configured
> + */
> +int __weak pci_mmconfig_enabled(void)
> +{
> +	return 1;
> +}
> +
> +/* Add MMCFG information for host bridges */
> +int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
> +			phys_addr_t addr)
> +{
> +	struct pci_mmcfg_region *cfg;
> +	int rc;
> +
> +	if (!pci_mmconfig_enabled())
> +		return -ENODEV;
> +	if (start > end)
> +		return -EINVAL;
> +
> +	mutex_lock(&pci_mmcfg_lock);
> +	cfg = pci_mmconfig_lookup(seg, start);
> +	if (cfg) {
> +		if (cfg->end_bus < end)
> +			dev_info(dev, FW_INFO
> +				 "MMCONFIG for "
> +				 "domain %04x [bus %02x-%02x] "
> +				 "only partially covers this bridge\n",
> +				  cfg->segment, cfg->start_bus, cfg->end_bus);
> +		rc = -EEXIST;
> +		goto err;
> +	}
> +
> +	if (!addr) {
> +		rc = -EINVAL;
> +		goto err;
> +	}
> +
> +	cfg = pci_mmconfig_alloc(seg, start, end, addr);
> +	if (cfg == NULL) {
> +		dev_warn(dev, "fail to add MMCONFIG (out of memory)\n");
> +		rc = -ENOMEM;
> +		goto err;
> +	}
> +	rc = pci_mmconfig_map_resource(dev, cfg);
> +	if (!rc) {
> +		list_add_sorted(cfg);
> +		dev_info(dev, "MMCONFIG at %pR (base %#lx)\n",
> +				 &cfg->res, (unsigned long)addr);
> +		return 0;
> +	} else {
> +		if (cfg->res.parent)
> +			release_resource(&cfg->res);
> +		kfree(cfg);
> +	}
> +
> +err:
> +	mutex_unlock(&pci_mmcfg_lock);
> +	return rc;
> +}
> +
> +/* Delete MMCFG information for host bridges */
> +int pci_mmconfig_delete(u16 seg, u8 start, u8 end)
> +{
> +	struct pci_mmcfg_region *cfg;
> +
> +	mutex_lock(&pci_mmcfg_lock);
> +	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
> +		if (cfg->segment == seg && cfg->start_bus == start &&
> +		    cfg->end_bus == end) {
> +			list_del_rcu(&cfg->list);
> +			synchronize_rcu();
> +			pci_mmconfig_unmap_resource(cfg);
> +			mutex_unlock(&pci_mmcfg_lock);
> +			kfree(cfg);
> +			return 0;
> +		}
> +	mutex_unlock(&pci_mmcfg_lock);
> +
> +	return -ENOENT;
> +}
> +
> +static int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
> +					struct acpi_mcfg_allocation *cfg)
> +{
> +	int year;
> +
> +	if (!config_enabled(CONFIG_X86))
> +		return 0;
> +
> +	if (cfg->address < 0xFFFFFFFF)
> +		return 0;
> +
> +	if (!strncmp(mcfg->header.oem_id, "SGI", 3))
> +		return 0;
> +
> +	if (mcfg->header.revision >= 1) {
> +		if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) &&
> +		    year >= 2010)
> +			return 0;
> +	}
> +
> +	pr_err(PREFIX "MCFG region for %04x [bus %02x-%02x] at %#llx "
> +	       "is above 4GB, ignored\n", cfg->pci_segment,
> +	       cfg->start_bus_number, cfg->end_bus_number, cfg->address);
> +	return -EINVAL;
> +}
> +
> +static int __init pci_parse_mcfg(struct acpi_table_header *header)
> +{
> +	struct acpi_table_mcfg *mcfg;
> +	struct acpi_mcfg_allocation *cfg_table, *cfg;
> +	unsigned long i;
> +	int entries;
> +
> +	if (!header)
> +		return -EINVAL;
> +
> +	mcfg = (struct acpi_table_mcfg *)header;
> +
> +	/* how many config structures do we have */
> +	entries = 0;
> +	i = header->length - sizeof(struct acpi_table_mcfg);
> +	while (i >= sizeof(struct acpi_mcfg_allocation)) {
> +		entries++;
> +		i -= sizeof(struct acpi_mcfg_allocation);
> +	}
> +	if (entries == 0) {
> +		pr_err(PREFIX "MMCONFIG has no entries\n");
> +		return -ENODEV;
> +	}
> +
> +	cfg_table = (struct acpi_mcfg_allocation *) &mcfg[1];
> +	for (i = 0; i < entries; i++) {
> +		cfg = &cfg_table[i];
> +		if (acpi_mcfg_check_entry(mcfg, cfg))
> +			return -ENODEV;
> +
> +		if (pci_mmconfig_add(cfg->pci_segment, cfg->start_bus_number,
> +				   cfg->end_bus_number, cfg->address) == NULL) {
> +			pr_warn(PREFIX "no memory for MCFG entries\n");
> +			return -ENOMEM;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +int __init pci_mmconfig_parse_table(void)
> +{
> +	return acpi_sfi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg);
> +}
> +
> +void __weak __init pci_mmcfg_late_init(void)
> +{
> +	int err, n = 0;
> +	struct pci_mmcfg_region *cfg;
> +
> +	err = pci_mmconfig_parse_table();
> +	if (err) {
> +		pr_err(PREFIX " Failed to parse MCFG (%d)\n", err);
> +		return;
> +	}
> +
> +	list_for_each_entry(cfg, &pci_mmcfg_list, list) {
> +		pci_mmconfig_map_resource(NULL, cfg);
> +		n++;
> +	}
> +
> +	pr_info(PREFIX " MCFG table loaded %d entries\n", n);
> +}
> diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
> index 7494dbe..97aa9d3 100644
> --- a/drivers/xen/pci.c
> +++ b/drivers/xen/pci.c
> @@ -27,9 +27,6 @@
>   #include <asm/xen/hypervisor.h>
>   #include <asm/xen/hypercall.h>
>   #include "../pci/pci.h"
> -#ifdef CONFIG_PCI_MMCONFIG
> -#include <asm/pci_x86.h>
> -#endif
>
>   static bool __read_mostly pci_seg_supported = true;
>
> @@ -221,7 +218,7 @@ static int __init xen_mcfg_late(void)
>   	if (!xen_initial_domain())
>   		return 0;
>
> -	if ((pci_probe & PCI_PROBE_MMCONF) == 0)
> +	if (!pci_mmconfig_enabled())
>   		return 0;
>
>   	if (list_empty(&pci_mmcfg_list))
> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
> index 89ab057..e9450ef 100644
> --- a/include/linux/pci-acpi.h
> +++ b/include/linux/pci-acpi.h
> @@ -106,6 +106,39 @@ extern const u8 pci_acpi_dsm_uuid[];
>   #define RESET_DELAY_DSM		0x08
>   #define FUNCTION_DELAY_DSM	0x09
>
> +/* common API to maintain list of MCFG regions */
> +/* "PCI MMCONFIG %04x [bus %02x-%02x]" */
> +#define PCI_MMCFG_RESOURCE_NAME_LEN (22 + 4 + 2 + 2)
> +
> +struct pci_mmcfg_region {
> +	struct list_head list;
> +	struct resource res;
> +	u64 address;
> +	char __iomem *virt;
> +	u16 segment;
> +	u8 start_bus;
> +	u8 end_bus;
> +	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
> +};
> +
> +extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
> +			       phys_addr_t addr);
> +extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
> +
> +extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
> +extern struct pci_mmcfg_region *pci_mmconfig_add(int segment, int start,
> +							int end, u64 addr);
> +extern int pci_mmconfig_map_resource(struct device *dev,
> +	struct pci_mmcfg_region *mcfg);
> +extern void pci_mmconfig_unmap_resource(struct pci_mmcfg_region *mcfg);
> +extern int pci_mmconfig_enabled(void);
> +extern int __init pci_mmconfig_parse_table(void);
> +
> +extern struct list_head pci_mmcfg_list;
> +
> +#define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
> +#define PCI_MMCFG_OFFSET(bus, devfn)   ((bus) << 20 | (devfn) << 12)
> +
>   #else	/* CONFIG_ACPI */
>   static inline void acpi_pci_add_bus(struct pci_bus *bus) { }
>   static inline void acpi_pci_remove_bus(struct pci_bus *bus) { }
>



From rrichter at caviumnetworks.com  Thu Feb 18 04:39:07 2016
From: rrichter at caviumnetworks.com (Robert Richter)
Date: Thu, 18 Feb 2016 13:39:07 +0100
Subject: [PATCH 0/2] net: thunderx: Small cleanups
Message-ID: <1455799149-19590-1-git-send-email-rrichter@caviumnetworks.com>

From: Robert Richter <rrichter at cavium.com>

Sending two small cleanups of the driver fixing issues found during
code review.

Robert Richter (2):
  net: thunderx: Fix const type in nicvf_set_rxfh()
  net, thunderx: Use bool in structs where possible

 drivers/net/ethernet/cavium/thunder/nic.h           | 12 ++++++------
 drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

-- 
2.7.0.rc3



From rrichter at caviumnetworks.com  Thu Feb 18 04:39:08 2016
From: rrichter at caviumnetworks.com (Robert Richter)
Date: Thu, 18 Feb 2016 13:39:08 +0100
Subject: [PATCH 1/2] net: thunderx: Fix const type in nicvf_set_rxfh()
In-Reply-To: <1455799149-19590-1-git-send-email-rrichter@caviumnetworks.com>
References: <1455799149-19590-1-git-send-email-rrichter@caviumnetworks.com>
Message-ID: <1455799149-19590-2-git-send-email-rrichter@caviumnetworks.com>

From: Robert Richter <rrichter at cavium.com>

>From struct ethtool_ops:

        int     (*set_rxfh)(struct net_device *, const u32 *indir,
                            const u8 *key, const u8 hfunc);

Change function arg of hfunc to const type.

Signed-off-by: Robert Richter <rrichter at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
index a12b2e38cf61..fb79529ac8c7 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
@@ -581,7 +581,7 @@ static int nicvf_get_rxfh(struct net_device *dev, u32 *indir, u8 *hkey,
 }
 
 static int nicvf_set_rxfh(struct net_device *dev, const u32 *indir,
-			  const u8 *hkey, u8 hfunc)
+			const u8 *hkey, const u8 hfunc)
 {
 	struct nicvf *nic = netdev_priv(dev);
 	struct nicvf_rss_info *rss = &nic->rss_info;
-- 
2.7.0.rc3



From rrichter at caviumnetworks.com  Thu Feb 18 04:39:09 2016
From: rrichter at caviumnetworks.com (Robert Richter)
Date: Thu, 18 Feb 2016 13:39:09 +0100
Subject: [PATCH 2/2] net, thunderx: Use bool in structs where possible
In-Reply-To: <1455799149-19590-1-git-send-email-rrichter@caviumnetworks.com>
References: <1455799149-19590-1-git-send-email-rrichter@caviumnetworks.com>
Message-ID: <1455799149-19590-3-git-send-email-rrichter@caviumnetworks.com>

From: Robert Richter <rrichter at cavium.com>

Looks like the :1 notation was accidentally introduced (this still
uses 1 byte per flag). Using bool instead, which is the common use.

Signed-off-by: Robert Richter <rrichter at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/nic.h | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nic.h b/drivers/net/ethernet/cavium/thunder/nic.h
index 688828865c48..fa5b1d2d8e23 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -262,9 +262,9 @@ struct nicvf {
 	struct pci_dev		*pdev;
 	u8			vf_id;
 	u8			node;
-	u8			tns_mode:1;
-	u8			sqs_mode:1;
-	u8			loopback_supported:1;
+	bool			tns_mode;
+	bool                    sqs_mode;
+	bool			loopback_supported;
 	bool			hw_tso;
 	u16			mtu;
 	struct queue_set	*qs;
@@ -353,9 +353,9 @@ struct nic_cfg_msg {
 	u8    msg;
 	u8    vf_id;
 	u8    node_id;
-	u8    tns_mode:1;
-	u8    sqs_mode:1;
-	u8    loopback_supported:1;
+	bool  tns_mode;
+	bool  sqs_mode;
+	bool  loopback_supported;
 	u8    mac_addr[ETH_ALEN];
 };
 
-- 
2.7.0.rc3



From ulf.hansson at linaro.org  Thu Feb 18 04:40:47 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 18 Feb 2016 13:40:47 +0100
Subject: [PATCH v5 00/13] mmc: use sdhci_pltfm_init for private allocation
 and clean up
In-Reply-To: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
References: <1455628111-5583-1-git-send-email-jszhang@marvell.com>
Message-ID: <CAPDyKFr2RBOuVM+QeOrbH=uZE+3wymqgZzvDPUa0JUnoK+raWg@mail.gmail.com>

On 16 February 2016 at 14:08, Jisheng Zhang <jszhang at marvell.com> wrote:
> These patches are to complete the TODOs in Commit 0e748234293f ("mmc:
> sdhci: Add size for caller in init+register"), I.E:
>
> - todo: migrate clients to using allocation this way
> - todo: remove priv variable once migration is complete
>
> Since v4:
>  - based on Ulf's latest next branch
>  - add Adrian's Ack for all patches, add Thierry's Ack and Test for patch 11
>    add S?ren Ack for patch 5.
>
> Since v3:
>  - based on v4.5-rc1
>  - add Ludovic's ack for sdhci-of-at91 changes
>  - fix use-after-free in some drivers: some host drivers still needs to
>    access sdhci_pltfm_host->private after sdhci_pltfm_unregister(), but
>    the private should be already freed by sdhci_pltfm_unregister.
>  - add patch5 to fix one clk bug in sdhci_arasan_remove(). IMHO, It's
>    better to add this patch to fixes rather than waiting for next merge
>    window
>
> Since v2:
>  - based on mmc next tree and remove all priv usage introduced in newly
>    commits in this tree
>  - don't break two lines if sdhci_pltfm_init() call could be put into
>    one line. Thank Ludovic Desroches.
>
> Since v1:
>  - add new patch03 to factorise sdhci_msm_pdata outisde of sdhci_msm_host.
>    This is to fix drivers/mmc/host/sdhci-msm.c:440:32: warning: 'msm_host'
>    is used uninitialized in this function [-Wuninitialized]
>  - Add Arnd's Ack for all patches except patch3 which is new in v2
>
>
> Jisheng Zhang (13):
>   mmc: sdhci-bcm2835: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-esdhc-imx: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-msm: factorise sdhci_msm_pdata outisde of sdhci_msm_host
>   mmc: sdhci-msm: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-of-arasan: fix clk issue in sdhci_arasan_remove()
>   mmc: sdhci-of-arasan: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-of-at91: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-of-esdhc: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-pxav3: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-st: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-tegra: use sdhci_pltfm_init for private allocation
>   mmc: sdhci-pxav2: remove unnecessary assignment of pltfm_host->priv
>   mmc: sdhci-pltfm: remove priv variable from sdhci_pltfm_host
>
>  drivers/mmc/host/sdhci-bcm2835.c   | 14 +++----------
>  drivers/mmc/host/sdhci-esdhc-imx.c | 38 ++++++++++++++++--------------------
>  drivers/mmc/host/sdhci-msm.c       | 25 +++++++++++-------------
>  drivers/mmc/host/sdhci-of-arasan.c | 33 +++++++++++++++----------------
>  drivers/mmc/host/sdhci-of-at91.c   | 33 ++++++++++++++-----------------
>  drivers/mmc/host/sdhci-of-esdhc.c  | 19 +++++++++---------
>  drivers/mmc/host/sdhci-pltfm.h     |  1 -
>  drivers/mmc/host/sdhci-pxav2.c     |  1 -
>  drivers/mmc/host/sdhci-pxav3.c     | 20 ++++++++-----------
>  drivers/mmc/host/sdhci-st.c        | 40 +++++++++++++++++++-------------------
>  drivers/mmc/host/sdhci-tegra.c     | 21 +++++++-------------
>  11 files changed, 106 insertions(+), 139 deletions(-)
>
> --
> 2.7.0
>

Thanks, applied for next!

Kind regards
Uffe


From jean-philippe.brucker at arm.com  Thu Feb 18 04:41:49 2016
From: jean-philippe.brucker at arm.com (Jean-Philippe Brucker)
Date: Thu, 18 Feb 2016 12:41:49 +0000
Subject: [PATCH] ARM: virt: fix hyp-stub build for pre-ARMv7 CPUs
In-Reply-To: <20160217212551.GJ19428@n2100.arm.linux.org.uk>
References: <20160217212551.GJ19428@n2100.arm.linux.org.uk>
Message-ID: <1455799309-21300-1-git-send-email-jean-philippe.brucker@arm.com>

ARMv6 CPUs do not have virtualisation extensions, but hyp-stub.S is
still included into the image to keep it generic. In order to use ARMv7
instructions during HYP initialisation, add -march=armv7-a flag to
hyp-stub's build.

On an ARMv6 CPU, __hyp_stub_install returns as soon as it detects that
the mode isn't HYP, so we will never reach those instructions.

Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker at arm.com>
---
 arch/arm/boot/compressed/Makefile |    2 ++
 arch/arm/kernel/Makefile          |    1 +
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 7a6a58e..43788b1 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -195,5 +195,7 @@ CFLAGS_font.o := -Dstatic=
 $(obj)/font.c: $(FONTC)
 	$(call cmd,shipped)
 
+AFLAGS_hyp-stub.o := -Wa,-march=armv7-a
+
 $(obj)/hyp-stub.S: $(srctree)/arch/$(SRCARCH)/kernel/hyp-stub.S
 	$(call cmd,shipped)
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 2c5f160..ad325a8 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_DEBUG_LL)	+= debug.o
 obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
 
 obj-$(CONFIG_ARM_VIRT_EXT)	+= hyp-stub.o
+AFLAGS_hyp-stub.o		:=-Wa,-march=armv7-a
 ifeq ($(CONFIG_ARM_PSCI),y)
 obj-$(CONFIG_SMP)		+= psci_smp.o
 endif
-- 
1.7.9.5



From arnd at arndb.de  Thu Feb 18 04:43:01 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 13:43:01 +0100
Subject: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
In-Reply-To: <CABgxDo+oGe47hvxiCOAUWz8zfSeVONf=3pFm+=PbNsCbr_jTpg@mail.gmail.com>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <CAOQ7t2add21t4hFtTeUBFe9aW0EtNvSi5KS4JMb6qVC60Fj-tA@mail.gmail.com>
 <CABgxDo+oGe47hvxiCOAUWz8zfSeVONf=3pFm+=PbNsCbr_jTpg@mail.gmail.com>
Message-ID: <4158343.mkrTsd5B4G@wuerfel>

On Thursday 18 February 2016 13:33:04 Romain Perier wrote:
> 2016-02-17 21:36 GMT+01:00 Carlo Caione <carlo at caione.org>:
> > On Wed, Feb 17, 2016 at 6:28 PM, Romain Perier <romain.perier at gmail.com> wrote:
> >> These are the CBUS registers used to retrieve the revision and the
> >> identifier of the SoC on Meson8.
> >>
> >> Signed-off-by: Romain Perier <romain.perier at gmail.com>
> >> ---
> >>  arch/arm/boot/dts/meson8b.dtsi | 5 +++++
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
> >> index 0477a81..71009dc 100644
> >> --- a/arch/arm/boot/dts/meson8b.dtsi
> >> +++ b/arch/arm/boot/dts/meson8b.dtsi
> >> @@ -99,6 +99,11 @@
> >>                 };
> >>         };
> >>
> >> +       hwrev at c1107d4c {
> >> +               compatible = "amlogic,meson8b-hwrev", "syscon";
> >> +               reg = <0xc1107d4c 0x460>;
> >
> > Interesting. Where did you get 0x460?
> 
> Carlo, Arnd.
> 
> Well, what I did is the following :
> - CBUS_PHY_BASE is 0xc1100000   (CBUS is a larger block of registers,
> like slcr on zynq)
> - the serial is at CBUS_PHY_BASE + 0x7d4c
> - the revision is at CBUS_PHY_BASE + 0x81a8
> 
> So I decided to create a device_node for hw revision at 0xc1107d4c, in
> this case the lenght is 0x460...
> Am I wrong ?

Yes, you should describe the device that is actually there, which would be
something like

	cbus at c1100000 {
		compatible = "amlogic,meson8b-cbus", "syscon";
		reg = <0xc1100000 0x10000>; /* no idea what the length is, fix it */
	};

Don't just make things up because you happen to access them in a particular
way, but try to stay as close as you can to describing the actual hardware.

Please also check that the register ranges don't overlap with something
that might already be there, in case someone else made the same mistake.

	Arnd


From vladimir.murzin at arm.com  Thu Feb 18 04:47:18 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Thu, 18 Feb 2016 12:47:18 +0000
Subject: [PATCH v3 09/10] ARM: dts: introduce MPS2 AN385/AN386
In-Reply-To: <5567140.dIBhKTnriP@wuerfel>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <7245560.jfhuhtPsB8@wuerfel> <56C5A742.8010304@arm.com>
 <5567140.dIBhKTnriP@wuerfel>
Message-ID: <56C5BD56.2050603@arm.com>

On 18/02/16 12:16, Arnd Bergmann wrote:
> On Thursday 18 February 2016 11:13:06 Vladimir Murzin wrote:
>> On 18/02/16 10:45, Arnd Bergmann wrote:
>>> On Thursday 18 February 2016 10:11:37 Vladimir Murzin wrote:
>>>>
>>>> Right, I thought in a wrong way, in opposite it makes more sense now.
>>>>
>>>> .dtsi
>>>>
>>>> /* below the soc/ */
>>>> smb {
>>>>         compatible = "simple-bus";
>>>>         #address-cells = <2>;
>>>>         #size-cells = <1>;
>>>>         ranges = <0 0 0x40200000 0x10000>,
>>>>                  <1 0 0xa0000000 0x10000>;
>>>> };
>>>
>>> That looks good, yes.
>>>
>>> Is 0x10000 the correct maximum addressable size of the external bus
>>> in both cases?
>>>
>>> Intuitively, I would guess that the 0xa0000000 range might
>>> be much wider.
>>
>> There is only Ethernet connected to this bus (apart from PSRAM), so it
>> might be wider, but there is no indication of this in documentation.
> 
> I see this called "ahb_to_extmem16" in the documentation, which indicates
> that it might be use 16 bits of address space, which would match
> the 64K you listed.
> 
> For SSRAM1 / SSRAM2 / SSRAM3, a 8 MB address space is mentioned
> and 16 MB for external PSRAM at 0x21000000.
> 

Right. I'll incorporate changes in the next version. Thanks for lessons
given and your time!

Cheers
Vladimir

> 	Arnd
> 
> 
> 
> 



From lorenzo.pieralisi at arm.com  Thu Feb 18 04:59:28 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 18 Feb 2016 12:59:28 +0000
Subject: [PATCH V5 00/15] MMCONFIG refactoring and support for ARM64 PCI
 hostbridge init based on ACPI
In-Reply-To: <1455630825-27253-1-git-send-email-tn@semihalf.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
Message-ID: <20160218125928.GA13045@red-moon>

Hi Bjorn, Rafael,

On Tue, Feb 16, 2016 at 02:53:30PM +0100, Tomasz Nowicki wrote:
> From the functionality point of view this series might be split into the
> following logic parts:
> 1. Make MMCONFIG code arch-agnostic which allows all architectures to collect
>    PCI config regions and used when necessary.
> 2. Move non-arch specific bits to the core code.
> 3. Use MMCONFIG code and implement generic ACPI based PCI host controller driver.
> 4. Enable above driver on ARM64

I think that apart from some pending review comments that will force
some minor patches update, the overall structure of this patchset is in
a reasonable shape, I would be grateful if you could have a look
from PCI and ACPI perspectives to see if there is some serious
rework needed and/or you want us to do things differently.

In particular, the MCFG rework (along with some PCI core changes
ie PCI ACPI bridge companion) affects x86 so we definitely need
some feedback on that code, otherwise we are stuck and can't
enable ACPI PCI support for ARM64.

Thank you very much.

Cheers,
Lorenzo

> Patches has been built on top of 4.5-rc3 and can be found here:
> git at github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v5)
> 
> NOTE, this patch set depends on Lorenzo's fixes:
> https://patchwork.ozlabs.org/patch/576450/
> which can be found in pci-acpi-v5 branch.
> 
> This has been tested on Cavium ThunderX server, JunoR2, HP RX2660 IA64, x86,
> Hip05, X-Gene and QEMU-aarch64. Any help in reviewing and testing is very appreciated.
> 
> v4 -> v5
> - dropped MCFG refactoring group patches 1-6 from series v4 and integrated Jayachandran's patch
>   https://patchwork.ozlabs.org/patch/575525/
> - rewrite PCI legacy IRQs allocation
> - squashed two patches 11 and 12 from series v4, fixed bisection issue
> - changelog improvements
> - rebased to 4.5-rc3
> 
> v3 -> v4
> - dropped Jiang's fix http://lkml.iu.edu/hypermail/linux/kernel/1601.1/04318.html
> - added Lorenzo's fix patch 19/24
> - ACPI PCI bus domain number assigning cleanup
> - changed resource management, we now claim and reassign resources
> - improvements for applying quirks
> - dropped Matthew's http://www.spinics.net/lists/linux-pci/msg45950.html dependency
> - rebased to 4.5-rc1
> 
> v2 -> v3
> - fix legacy IRQ assigning and IO ports registration
> - remove reference to arch specific companion device for ia64
> - move ACPI PCI host controller driver to pci_root.c
> - drop generic domain assignment for x86 and ia64 as I am not
>   able to run all necessary test variants
> - drop patch which cleaned legacy IRQ assignment since it belongs to
>   Mathew's series:
>   https://patchwork.ozlabs.org/patch/557504/
> - extend MCFG quirk code
> - rebased to 4.4
> 
> v1 -> v2
> - moved non-arch specific piece of code to dirver/acpi/ directory
> - fixed IO resource handling
> - introduced PCI config accessors quirks matching
> - moved ACPI_COMPANION_SET to generic code
> 
> v1 - https://lkml.org/lkml/2015/10/27/504
> v2 - https://lkml.org/lkml/2015/12/16/246
> v3 - http://lkml.iu.edu/hypermail/linux/kernel/1601.1/04308.html
> v4 - https://lkml.org/lkml/2016/2/4/646
> 
> Jayachandran C (1):
>   ACPI: MCFG: Move mmcfg_list management to drivers/acpi
> 
> Lorenzo Pieralisi (1):
>   drivers: pci: add generic code to claim bus resources
> 
> Tomasz Nowicki (13):
>   acpi, pci, mcfg: Provide default RAW ACPI PCI config space accessors.
>   arm64, acpi: Use MCFG library and empty PCI config space accessors
>     from pci_mcfg.c file.
>   pci, acpi, ecam: Add flag to indicate whether ECAM region was hot
>     added or not.
>   x86, pci: Cleanup platform specific MCFG data by using ECAM hot_added
>     flag.
>   pci, acpi, x86, ia64: Move ACPI host bridge device companion
>     assignment to core code.
>   pci, acpi: Provide generic way to assign bus domain number.
>   x86, ia64: Include acpi_pci_{add|remove}_bus to the default
>     pcibios_{add|remove}_bus implementation.
>   acpi, mcfg: Add default PCI config accessors implementation and
>     initial support for related quirks.
>   pci, of: Move the PCI I/O space management to PCI core code.
>   pci, acpi: Support for ACPI based generic PCI host controller
>     initialization
>   pci, acpi: Match PCI config space accessors against platfrom specific
>     quirks.
>   arm64, pci, acpi: Assign legacy IRQs once device is enable.
>   arm64, pci, acpi: Start using ACPI based PCI host bridge driver for
>     ARM64.
> 
>  arch/arm64/Kconfig                 |   5 +
>  arch/arm64/kernel/pci.c            |  35 +---
>  arch/ia64/hp/common/sba_iommu.c    |   2 +-
>  arch/ia64/include/asm/pci.h        |   1 -
>  arch/ia64/pci/pci.c                |  26 ---
>  arch/ia64/sn/kernel/io_acpi_init.c |   4 +-
>  arch/x86/include/asm/pci.h         |   3 -
>  arch/x86/include/asm/pci_x86.h     |  24 +--
>  arch/x86/pci/acpi.c                |  47 +----
>  arch/x86/pci/common.c              |  10 -
>  arch/x86/pci/mmconfig-shared.c     | 269 ++++---------------------
>  arch/x86/pci/mmconfig_32.c         |   1 +
>  arch/x86/pci/mmconfig_64.c         |   1 +
>  arch/x86/pci/numachip.c            |   1 +
>  drivers/acpi/Kconfig               |   7 +
>  drivers/acpi/Makefile              |   1 +
>  drivers/acpi/pci_mcfg.c            | 392 +++++++++++++++++++++++++++++++++++++
>  drivers/acpi/pci_root.c            | 154 ++++++++++++++-
>  drivers/of/address.c               | 116 +----------
>  drivers/pci/pci.c                  | 126 +++++++++++-
>  drivers/pci/probe.c                |   5 +
>  drivers/pci/setup-bus.c            |  63 ++++++
>  drivers/xen/pci.c                  |   5 +-
>  include/acpi/acpi_bus.h            |   1 +
>  include/asm-generic/vmlinux.lds.h  |   7 +
>  include/linux/of_address.h         |   9 -
>  include/linux/pci-acpi.h           |  68 +++++++
>  include/linux/pci.h                |   6 +
>  28 files changed, 892 insertions(+), 497 deletions(-)
>  create mode 100644 drivers/acpi/pci_mcfg.c
> 
> -- 
> 1.9.1
> 


From shawnguo at kernel.org  Thu Feb 18 05:11:40 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 18 Feb 2016 21:11:40 +0800
Subject: [PATCH 1/3] Documentation: devicetree: add Freescale SCC bindings
In-Reply-To: <73fuwtdp3m.fsf@unicorn.hi.pengutronix.de>
References: <1455199485-24458-1-git-send-email-s.trumtrar@pengutronix.de>
 <20160214075557.GP6756@tiger>
 <73fuwtdp3m.fsf@unicorn.hi.pengutronix.de>
Message-ID: <20160218131140.GV6756@tiger>

On Tue, Feb 16, 2016 at 09:41:17AM +0100, Steffen Trumtrar wrote:
> 
> Hi!
> 
> Shawn Guo writes:
> 
> > On Thu, Feb 11, 2016 at 03:04:43PM +0100, Steffen Trumtrar wrote:
> >> Add documentation for the Freescale Security Controller (SCC)
> >> found on i.MX25 SoCs.
> >> 
> >> Signed-off-by: Steffen Trumtrar <s.trumtrar at pengutronix.de>
> >> ---
> >>  .../devicetree/bindings/crypto/fsl-imx-scc.txt          | 17 +++++++++++++++++
> >>  1 file changed, 17 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
> >> 
> >> diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
> >> new file mode 100644
> >> index 000000000000..9a15ab8da94f
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
> >> @@ -0,0 +1,17 @@
> >> +Freescale Security Controller (SCC)
> >> +
> >> +Required properties:
> >> +- compatible : Should be "fsl,imx25-scc".
> >> +- reg : Should contain register location and length.
> >> +- interrupts : Should contain interrupt numbers for SCM IRQ and SMN IRQ.
> >> +
> >> +Example:
> >> +
> >> +	scc: crypto at 53fac000 {
> >> +		compatible = "fsl,imx25-scc";
> >> +		reg = <0x53fac000 0x4000>;
> >> +		clocks = <&clks 111>;
> >> +		clock-names = "ipg";
> >
> > Shouldn't these two be mentioned in properties list above too?
> >
> 
> What is the current policy on clocks in bindings? There are some with
> and some without.
> 
> Of course I can add them to the required properties if necessary.

I think any required properties should be listed in "Required
properties:" section.

Shawn


From linux at arm.linux.org.uk  Thu Feb 18 05:12:33 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Feb 2016 13:12:33 +0000
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56C5B080.9090007@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <56C438DA.5040109@ti.com>
 <CACRpkdZ+G17hmVP8AejL7NTqg7k0SBC5kgF55ASjD+kfuGFJhQ@mail.gmail.com>
 <20160217213250.GK19428@n2100.arm.linux.org.uk>
 <56C5B080.9090007@ti.com>
Message-ID: <20160218131233.GP19428@n2100.arm.linux.org.uk>

On Thu, Feb 18, 2016 at 01:52:32PM +0200, Tomi Valkeinen wrote:
> In my opinion the best option would be to use DT overlays, but so that
> the bootloader would supply them, or construct the dtb. But afaik that's
> not possible at the moment. And perhaps I think that's the best option
> only because I don't work with the bootloaders =).
> 
> So, I don't like this, but I don't have a good suggestion how to do it
> better with the infrastructure in place at the moment.

The danger of that position is that we end up with nothing happening,
and the problem remaining unresolved, which then pushes people into
maintaining patches out of mainline just to have a working setup -
which then pushes people to vendor trees.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From lorenzo.pieralisi at arm.com  Thu Feb 18 05:20:38 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 18 Feb 2016 13:20:38 +0000
Subject: [Linaro-acpi] [PATCH V5 01/15] ACPI: MCFG: Move mmcfg_list
 management to drivers/acpi
In-Reply-To: <56C5B83F.4010602@huawei.com>
References: <1455630825-27253-1-git-send-email-tn@semihalf.com>
 <1455630825-27253-2-git-send-email-tn@semihalf.com>
 <56C5B83F.4010602@huawei.com>
Message-ID: <20160218132038.GA13229@red-moon>

On Thu, Feb 18, 2016 at 08:25:35PM +0800, liudongdong (C) wrote:

[...]

> >+/*
> >+ * Map a pci_mmcfg_region, can be overrriden by arch
> >+ */
> >+int __weak pci_mmconfig_map_resource(struct device *dev,
> >+	struct pci_mmcfg_region *mcfg)
> >+{
> >+	struct resource *tmp;
> >+	void __iomem *vaddr;
> >+
> >+	tmp = insert_resource_conflict(&iomem_resource, &mcfg->res);
> >+	if (tmp) {
> >+		dev_warn(dev, "MMCONFIG %pR conflicts with %s %pR\n",
> >+			&mcfg->res, tmp->name, tmp);
> >+		return -EBUSY;
> >+	}
> >+
> >+	vaddr =  ioremap(mcfg->res.start, resource_size(&mcfg->res));
               ^^
	       while at it, stray white space

> >+	if (!vaddr) {
> >+		release_resource(&mcfg->res);
> >+		return -ENOMEM;
> >+	}
> >+
> >+	mcfg->virt = vaddr;
> Here should be changed to
> 	mcfg->virt = vaddr - PCI_MMCFG_BUS_OFFSET(mcfg->start_bus);
> 
> or when pcie host "start_bus" is not 0, the configuraion access will be wrong.
Well spotted, thanks.

Lorenzo


From matt at codeblueprint.co.uk  Thu Feb 18 05:28:24 2016
From: matt at codeblueprint.co.uk (Matt Fleming)
Date: Thu, 18 Feb 2016 13:28:24 +0000
Subject: [PATCH v2 1/2] efi: esrt: use memremap not ioremap to access
 ESRT table in memory
In-Reply-To: <CAKv+Gu_AW7PKJJOd2mbEu3LKJe+gNaPHnH=sgO=YXM_KWFyKxw@mail.gmail.com>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160218104407.GC2651@codeblueprint.co.uk>
 <CAKv+Gu_AW7PKJJOd2mbEu3LKJe+gNaPHnH=sgO=YXM_KWFyKxw@mail.gmail.com>
Message-ID: <20160218132824.GE2651@codeblueprint.co.uk>

On Thu, 18 Feb, at 01:16:05PM, Ard Biesheuvel wrote:
> On 18 February 2016 at 11:44, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> > On Mon, 15 Feb, at 12:32:32PM, Ard Biesheuvel wrote:
> >> On ARM and arm64, ioremap() and memremap() are not interchangeable like
> >> on x86, and the use of ioremap() on ordinary RAM is typically flagged
> >> as an error if the memory region being mapped is also covered by the
> >> linear mapping, since that would lead to aliases with conflicting
> >> cacheability attributes.
> >>
> >> Since what we are dealing with is not an I/O region with side effects,
> >> using ioremap() here is arguably incorrect anyway, so let's replace
> >> it with memremap instead. Also add a missing unmap on the success path,
> >> and drop a memblock_remove() call which does not belong here, this far
> >> into the boot sequence.
> >>
> >> Cc: Peter Jones <pjones at redhat.com>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >> ---
> >>  drivers/firmware/efi/esrt.c | 16 ++++++++--------
> >>  1 file changed, 8 insertions(+), 8 deletions(-)
> >>
> >
> > [...]
> >
> >> @@ -432,8 +434,6 @@ static int __init esrt_sysfs_init(void)
> >>       if (error)
> >>               goto err_cleanup_list;
> >>
> >> -     memblock_remove(esrt_data, esrt_data_size);
> >> -
> >>       pr_debug("esrt-sysfs: loaded.\n");
> >>
> >>       return 0;
> >
> > Shouldn't we be replacing memblock_remove() with free_bootmem_late()?
> > The original ESRT region is still reserved at this point, so we should
> > do our best to release it to the page allocator.
> 
> I'd rather we keep it reserved. That way, the config table entry still
> points to something valid, which could be useful for kexec(), I think?
> At least, that is how I intended to handle config tables on ARM ...

If we're going to reserve it why do we need to copy the data out at
all in esrt_sysfs_init()?


From ard.biesheuvel at linaro.org  Thu Feb 18 05:29:32 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 18 Feb 2016 14:29:32 +0100
Subject: [PATCH v2 1/2] efi: esrt: use memremap not ioremap to access ESRT
 table in memory
In-Reply-To: <20160218132824.GE2651@codeblueprint.co.uk>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160218104407.GC2651@codeblueprint.co.uk>
 <CAKv+Gu_AW7PKJJOd2mbEu3LKJe+gNaPHnH=sgO=YXM_KWFyKxw@mail.gmail.com>
 <20160218132824.GE2651@codeblueprint.co.uk>
Message-ID: <CAKv+Gu-s1pzYBzuDG-Z7s3gyo8dPOfeidZQ+rim-uAWZCBcKQQ@mail.gmail.com>

On 18 February 2016 at 14:28, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> On Thu, 18 Feb, at 01:16:05PM, Ard Biesheuvel wrote:
>> On 18 February 2016 at 11:44, Matt Fleming <matt at codeblueprint.co.uk> wrote:
>> > On Mon, 15 Feb, at 12:32:32PM, Ard Biesheuvel wrote:
>> >> On ARM and arm64, ioremap() and memremap() are not interchangeable like
>> >> on x86, and the use of ioremap() on ordinary RAM is typically flagged
>> >> as an error if the memory region being mapped is also covered by the
>> >> linear mapping, since that would lead to aliases with conflicting
>> >> cacheability attributes.
>> >>
>> >> Since what we are dealing with is not an I/O region with side effects,
>> >> using ioremap() here is arguably incorrect anyway, so let's replace
>> >> it with memremap instead. Also add a missing unmap on the success path,
>> >> and drop a memblock_remove() call which does not belong here, this far
>> >> into the boot sequence.
>> >>
>> >> Cc: Peter Jones <pjones at redhat.com>
>> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> >> ---
>> >>  drivers/firmware/efi/esrt.c | 16 ++++++++--------
>> >>  1 file changed, 8 insertions(+), 8 deletions(-)
>> >>
>> >
>> > [...]
>> >
>> >> @@ -432,8 +434,6 @@ static int __init esrt_sysfs_init(void)
>> >>       if (error)
>> >>               goto err_cleanup_list;
>> >>
>> >> -     memblock_remove(esrt_data, esrt_data_size);
>> >> -
>> >>       pr_debug("esrt-sysfs: loaded.\n");
>> >>
>> >>       return 0;
>> >
>> > Shouldn't we be replacing memblock_remove() with free_bootmem_late()?
>> > The original ESRT region is still reserved at this point, so we should
>> > do our best to release it to the page allocator.
>>
>> I'd rather we keep it reserved. That way, the config table entry still
>> points to something valid, which could be useful for kexec(), I think?
>> At least, that is how I intended to handle config tables on ARM ...
>
> If we're going to reserve it why do we need to copy the data out at
> all in esrt_sysfs_init()?

Excellent question. I don't think there is any point to doing that.


From thierry.reding at gmail.com  Thu Feb 18 05:32:10 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 18 Feb 2016 14:32:10 +0100
Subject: [PATCH] PCI: mvebu: Restrict build to 32-bit ARM
Message-ID: <1455802330-17565-1-git-send-email-thierry.reding@gmail.com>

From: Thierry Reding <treding at nvidia.com>

This driver uses PCI glue that is only available on 32-bit ARM. This
used to work fine as long as ARCH_MVEBU and ARCH_DOVE were exclusively
32-bit, but that's changed now, with ARCH_MVEBU also being available
on 64-bit ARM.

Signed-off-by: Thierry Reding <treding at nvidia.com>
---
 drivers/pci/host/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 75a605426538..d1cdd9c992ac 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -14,6 +14,7 @@ config PCI_DRA7XX
 config PCI_MVEBU
 	bool "Marvell EBU PCIe controller"
 	depends on ARCH_MVEBU || ARCH_DOVE
+	depends on ARM
 	depends on OF
 
 config PCIE_DW
-- 
2.7.1



From shawnguo at kernel.org  Thu Feb 18 05:35:39 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 18 Feb 2016 21:35:39 +0800
Subject: [PATCH] ARM: dts: imx6qdl-microsom.dtsi: avoid boot-time UHS
 warning
In-Reply-To: <E1aVMgw-0001wE-5w@rmk-PC.arm.linux.org.uk>
References: <E1aVMgw-0001wE-5w@rmk-PC.arm.linux.org.uk>
Message-ID: <20160218133539.GW6756@tiger>

On Mon, Feb 15, 2016 at 05:12:06PM +0000, Russell King wrote:
> Avoid the following warning:
> 
> sdhci-esdhc-imx 2190000.usdhc: could not get ultra high speed state, work on normal mode
> 
> which occurs at boot each time the SDHCI interface for the Broadcom
> WiFi is probed.
> 
> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>

Not sure why you resend, but I already applied the following series you
sent on Jan. 27 [1].

[PATCH 1/3] ARM: dts: imx6qdl-microsom.dtsi: avoid boot-time UHS warning
[PATCH 2/3] ARM: dts: imx6*-hummingboard: use proper gpio flags definitions
[PATCH 3/3] ARM: dts: imx6*-hummingboard: fix pcie reset GPIO specification

Shawn

[1] http://permalink.gmane.org/gmane.linux.drivers.devicetree/154097


From tomi.valkeinen at ti.com  Thu Feb 18 05:37:01 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Thu, 18 Feb 2016 15:37:01 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <20160218131233.GP19428@n2100.arm.linux.org.uk>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <56C438DA.5040109@ti.com>
 <CACRpkdZ+G17hmVP8AejL7NTqg7k0SBC5kgF55ASjD+kfuGFJhQ@mail.gmail.com>
 <20160217213250.GK19428@n2100.arm.linux.org.uk> <56C5B080.9090007@ti.com>
 <20160218131233.GP19428@n2100.arm.linux.org.uk>
Message-ID: <56C5C8FD.7090004@ti.com>

On 18/02/16 15:12, Russell King - ARM Linux wrote:
> On Thu, Feb 18, 2016 at 01:52:32PM +0200, Tomi Valkeinen wrote:
>> In my opinion the best option would be to use DT overlays, but so that
>> the bootloader would supply them, or construct the dtb. But afaik that's
>> not possible at the moment. And perhaps I think that's the best option
>> only because I don't work with the bootloaders =).
>>
>> So, I don't like this, but I don't have a good suggestion how to do it
>> better with the infrastructure in place at the moment.
> 
> The danger of that position is that we end up with nothing happening,
> and the problem remaining unresolved, which then pushes people into
> maintaining patches out of mainline just to have a working setup -
> which then pushes people to vendor trees.

I agree.

I didn't express my position clearly: I'm ok with the approach, if we
don't come up with anything better.

But if we go with this approach, it must be understood that it may cause
problems later. It's not the most maintainable approach.

I'd also like to have an ack from the DT maintainers, as I think this is
somewhat of an abuse of the DT.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160218/d9a76271/attachment-0001.sig>

From shawnguo at kernel.org  Thu Feb 18 05:38:31 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 18 Feb 2016 21:38:31 +0800
Subject: [PATCH 1/2] ARM: dts: vf-colibri: remove container node of
 regulators
In-Reply-To: <1455588854-6996-1-git-send-email-stefan@agner.ch>
References: <1455588854-6996-1-git-send-email-stefan@agner.ch>
Message-ID: <20160218133831.GX6756@tiger>

On Mon, Feb 15, 2016 at 06:14:13PM -0800, Stefan Agner wrote:
> Drop the fake simple-bus container 'regulators' and put the
> regulators directly under the root node. This also makes the
> artificial 'reg' properties superfluous.
> 
> Signed-off-by: Stefan Agner <stefan at agner.ch>

Applied both, thanks.


From matt at codeblueprint.co.uk  Thu Feb 18 05:43:24 2016
From: matt at codeblueprint.co.uk (Matt Fleming)
Date: Thu, 18 Feb 2016 13:43:24 +0000
Subject: [PATCH v2 1/2] efi: esrt: use memremap not ioremap to access
 ESRT table in memory
In-Reply-To: <CAKv+Gu-s1pzYBzuDG-Z7s3gyo8dPOfeidZQ+rim-uAWZCBcKQQ@mail.gmail.com>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160218104407.GC2651@codeblueprint.co.uk>
 <CAKv+Gu_AW7PKJJOd2mbEu3LKJe+gNaPHnH=sgO=YXM_KWFyKxw@mail.gmail.com>
 <20160218132824.GE2651@codeblueprint.co.uk>
 <CAKv+Gu-s1pzYBzuDG-Z7s3gyo8dPOfeidZQ+rim-uAWZCBcKQQ@mail.gmail.com>
Message-ID: <20160218134324.GG2651@codeblueprint.co.uk>

On Thu, 18 Feb, at 02:29:32PM, Ard Biesheuvel wrote:
> On 18 February 2016 at 14:28, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> > On Thu, 18 Feb, at 01:16:05PM, Ard Biesheuvel wrote:
> >> On 18 February 2016 at 11:44, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> >> > On Mon, 15 Feb, at 12:32:32PM, Ard Biesheuvel wrote:
> >> >> On ARM and arm64, ioremap() and memremap() are not interchangeable like
> >> >> on x86, and the use of ioremap() on ordinary RAM is typically flagged
> >> >> as an error if the memory region being mapped is also covered by the
> >> >> linear mapping, since that would lead to aliases with conflicting
> >> >> cacheability attributes.
> >> >>
> >> >> Since what we are dealing with is not an I/O region with side effects,
> >> >> using ioremap() here is arguably incorrect anyway, so let's replace
> >> >> it with memremap instead. Also add a missing unmap on the success path,
> >> >> and drop a memblock_remove() call which does not belong here, this far
> >> >> into the boot sequence.
> >> >>
> >> >> Cc: Peter Jones <pjones at redhat.com>
> >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >> >> ---
> >> >>  drivers/firmware/efi/esrt.c | 16 ++++++++--------
> >> >>  1 file changed, 8 insertions(+), 8 deletions(-)
> >> >>
> >> >
> >> > [...]
> >> >
> >> >> @@ -432,8 +434,6 @@ static int __init esrt_sysfs_init(void)
> >> >>       if (error)
> >> >>               goto err_cleanup_list;
> >> >>
> >> >> -     memblock_remove(esrt_data, esrt_data_size);
> >> >> -
> >> >>       pr_debug("esrt-sysfs: loaded.\n");
> >> >>
> >> >>       return 0;
> >> >
> >> > Shouldn't we be replacing memblock_remove() with free_bootmem_late()?
> >> > The original ESRT region is still reserved at this point, so we should
> >> > do our best to release it to the page allocator.
> >>
> >> I'd rather we keep it reserved. That way, the config table entry still
> >> points to something valid, which could be useful for kexec(), I think?
> >> At least, that is how I intended to handle config tables on ARM ...
> >
> > If we're going to reserve it why do we need to copy the data out at
> > all in esrt_sysfs_init()?
> 
> Excellent question. I don't think there is any point to doing that.

... Unless the data is contained in an EFI Boot Services region ;-)

Peter?


From ard.biesheuvel at linaro.org  Thu Feb 18 05:44:02 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 18 Feb 2016 14:44:02 +0100
Subject: [PATCH v2 1/2] efi: esrt: use memremap not ioremap to access ESRT
 table in memory
In-Reply-To: <20160218134324.GG2651@codeblueprint.co.uk>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160218104407.GC2651@codeblueprint.co.uk>
 <CAKv+Gu_AW7PKJJOd2mbEu3LKJe+gNaPHnH=sgO=YXM_KWFyKxw@mail.gmail.com>
 <20160218132824.GE2651@codeblueprint.co.uk>
 <CAKv+Gu-s1pzYBzuDG-Z7s3gyo8dPOfeidZQ+rim-uAWZCBcKQQ@mail.gmail.com>
 <20160218134324.GG2651@codeblueprint.co.uk>
Message-ID: <CAKv+Gu875r9RkDC723kNsG4XC0eSE9RPPmSFZrD0sx0QxS+V4g@mail.gmail.com>

On 18 February 2016 at 14:43, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> On Thu, 18 Feb, at 02:29:32PM, Ard Biesheuvel wrote:
>> On 18 February 2016 at 14:28, Matt Fleming <matt at codeblueprint.co.uk> wrote:
>> > On Thu, 18 Feb, at 01:16:05PM, Ard Biesheuvel wrote:
>> >> On 18 February 2016 at 11:44, Matt Fleming <matt at codeblueprint.co.uk> wrote:
>> >> > On Mon, 15 Feb, at 12:32:32PM, Ard Biesheuvel wrote:
>> >> >> On ARM and arm64, ioremap() and memremap() are not interchangeable like
>> >> >> on x86, and the use of ioremap() on ordinary RAM is typically flagged
>> >> >> as an error if the memory region being mapped is also covered by the
>> >> >> linear mapping, since that would lead to aliases with conflicting
>> >> >> cacheability attributes.
>> >> >>
>> >> >> Since what we are dealing with is not an I/O region with side effects,
>> >> >> using ioremap() here is arguably incorrect anyway, so let's replace
>> >> >> it with memremap instead. Also add a missing unmap on the success path,
>> >> >> and drop a memblock_remove() call which does not belong here, this far
>> >> >> into the boot sequence.
>> >> >>
>> >> >> Cc: Peter Jones <pjones at redhat.com>
>> >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> >> >> ---
>> >> >>  drivers/firmware/efi/esrt.c | 16 ++++++++--------
>> >> >>  1 file changed, 8 insertions(+), 8 deletions(-)
>> >> >>
>> >> >
>> >> > [...]
>> >> >
>> >> >> @@ -432,8 +434,6 @@ static int __init esrt_sysfs_init(void)
>> >> >>       if (error)
>> >> >>               goto err_cleanup_list;
>> >> >>
>> >> >> -     memblock_remove(esrt_data, esrt_data_size);
>> >> >> -
>> >> >>       pr_debug("esrt-sysfs: loaded.\n");
>> >> >>
>> >> >>       return 0;
>> >> >
>> >> > Shouldn't we be replacing memblock_remove() with free_bootmem_late()?
>> >> > The original ESRT region is still reserved at this point, so we should
>> >> > do our best to release it to the page allocator.
>> >>
>> >> I'd rather we keep it reserved. That way, the config table entry still
>> >> points to something valid, which could be useful for kexec(), I think?
>> >> At least, that is how I intended to handle config tables on ARM ...
>> >
>> > If we're going to reserve it why do we need to copy the data out at
>> > all in esrt_sysfs_init()?
>>
>> Excellent question. I don't think there is any point to doing that.
>
> ... Unless the data is contained in an EFI Boot Services region ;-)
>
> Peter?

Yes, it usually is. Is that a problem?


From jan.glauber at caviumnetworks.com  Thu Feb 18 05:45:20 2016
From: jan.glauber at caviumnetworks.com (Jan Glauber)
Date: Thu, 18 Feb 2016 14:45:20 +0100
Subject: [PATCH v3 1/5] arm64/perf: Rename Cortex A57 events
In-Reply-To: <20160218112429.GC8011@arm.com>
References: <cover.1454516082.git.jglauber@cavium.com>
 <e0ecaaaffb64cc0b2ecfd8852f718a3f1d642b5c.1454516082.git.jglauber@cavium.com>
 <20160215194037.GU6298@arm.com> <20160215200613.GY6298@arm.com>
 <20160218091307.GA4566@hardcore> <20160218112429.GC8011@arm.com>
Message-ID: <20160218134520.GC2648@hardcore>

On Thu, Feb 18, 2016 at 11:24:29AM +0000, Will Deacon wrote:
> On Thu, Feb 18, 2016 at 10:13:07AM +0100, Jan Glauber wrote:
> > On Mon, Feb 15, 2016 at 08:06:13PM +0000, Will Deacon wrote:
> > > On Mon, Feb 15, 2016 at 07:40:37PM +0000, Will Deacon wrote:
> > > > On Wed, Feb 03, 2016 at 06:11:56PM +0100, Jan Glauber wrote:
> > > > > The implemented Cortex A57 events are not A57 specific.
> > > > > They are recommended by ARM and can be found on other
> > > > > ARMv8 SOCs like Cavium ThunderX too. Therefore move
> > > > > these events to the common PMUv3 table.
> > > > 
> > > > I can't find anything in the architecture that suggests these event
> > > > numbers are necessarily portable between implementations. Am I missing
> > > > something?
> > > 
> > > Aha, I just noticed appendix K3.1 (silly me for missing it...).
> > > 
> > > Lemme check whether or not that mandates that those encodings can't be
> > > used for wildly different things.
> > 
> > To me it looks like we would just have duplicated code without the patch,
> > and at least the event types (e.g. L1D_CACHE_RD) should be identical
> > across implementations.
> > 
> > But I don't care too much, so please tell me if should drop the patch or
> > keep it.
> 
> Tell you what then -- how about we simply rename those to ARMV8_IMPDEF_*
> instead of ARMV8_A57_*? That way, we can easily identify them as distinct
> from the architected events if we need to in future.

Sounds good. I'll refresh and re-post the whole series then.

Jan

> Will


From linus.walleij at linaro.org  Thu Feb 18 05:46:12 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 18 Feb 2016 14:46:12 +0100
Subject: [PATCH 1/3] irqchip: gic/realview: support more RealView DCC variants
Message-ID: <1455803172-22747-1-git-send-email-linus.walleij@linaro.org>

In the add-on file for the GIC dealing with the RealView family
we currently only handle the PB11MPCore, let's extend this to
manage the RealView EB ARM11MPCore as well. The Revision B of the
ARM11MPCore core tile is a bit special and needs special handling
as it moves a system control register around at random.

Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: devicetree at vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
This can be applied in isolation from the other patches so Marc
one you're happy with it, please take it into the IRQchip tree.

There are two compatible strings getting added to the device tree
bindings so CC to the DT list. No biggie though, just figures out
exactly what ARM custom GIC flavor it is.
---
 .../bindings/interrupt-controller/arm,gic.txt      |  2 ++
 drivers/irqchip/irq-gic-realview.c                 | 35 ++++++++++++++++++----
 2 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
index 5a1cb4bc3dfe..0c80e6870645 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
@@ -16,6 +16,8 @@ Main node required properties:
 	"arm,cortex-a15-gic"
 	"arm,cortex-a7-gic"
 	"arm,cortex-a9-gic"
+	"arm,eb11mp-gic"
+	"arm,eb11mp-revb-gic"
 	"arm,gic-400"
 	"arm,pl390"
 	"arm,tc11mp-gic"
diff --git a/drivers/irqchip/irq-gic-realview.c b/drivers/irqchip/irq-gic-realview.c
index aa46eb280a7f..224e83d5c056 100644
--- a/drivers/irqchip/irq-gic-realview.c
+++ b/drivers/irqchip/irq-gic-realview.c
@@ -10,7 +10,8 @@
 #include <linux/irqchip/arm-gic.h>
 
 #define REALVIEW_SYS_LOCK_OFFSET	0x20
-#define REALVIEW_PB11MP_SYS_PLD_CTRL1	0x74
+#define REALVIEW_SYS_PLD_CTRL1		0x74
+#define REALVIEW_EB_REVB_SYS_PLD_CTRL1	0xD8
 #define VERSATILE_LOCK_VAL		0xA05F
 #define PLD_INTMODE_MASK		BIT(22)|BIT(23)|BIT(24)
 #define PLD_INTMODE_LEGACY		0x0
@@ -18,26 +19,50 @@
 #define PLD_INTMODE_NEW_NO_DCC		BIT(23)
 #define PLD_INTMODE_FIQ_ENABLE		BIT(24)
 
+static const struct of_device_id syscon_pldset_of_match[] = {
+	{
+		.compatible = "arm,realview-eb-syscon",
+	},
+	{
+		.compatible = "arm,realview-pb11mp-syscon",
+	},
+	{},
+};
+
 static int __init
 realview_gic_of_init(struct device_node *node, struct device_node *parent)
 {
 	static struct regmap *map;
+	struct device_node *np;
+	struct pld_setting *pldset;
+	u32 pld1_ctrl = REALVIEW_SYS_PLD_CTRL1;
+
+	np = of_find_matching_node_and_match(NULL, syscon_pldset_of_match,
+					     (void *)&pldset);
+	if (!np)
+		return -ENODEV;
+
+	/* For some reason RealView EB Rev B moved this register */
+	if (of_device_is_compatible(np, "arm,eb11mp-revb-gic"))
+		pld1_ctrl = REALVIEW_EB_REVB_SYS_PLD_CTRL1;
 
 	/* The PB11MPCore GIC needs to be configured in the syscon */
-	map = syscon_regmap_lookup_by_compatible("arm,realview-pb11mp-syscon");
+	map = syscon_node_to_regmap(np);
 	if (!IS_ERR(map)) {
 		/* new irq mode with no DCC */
 		regmap_write(map, REALVIEW_SYS_LOCK_OFFSET,
 			     VERSATILE_LOCK_VAL);
-		regmap_update_bits(map, REALVIEW_PB11MP_SYS_PLD_CTRL1,
+		regmap_update_bits(map, pld1_ctrl,
 				   PLD_INTMODE_NEW_NO_DCC,
 				   PLD_INTMODE_MASK);
 		regmap_write(map, REALVIEW_SYS_LOCK_OFFSET, 0x0000);
-		pr_info("TC11MP GIC: set up interrupt controller to NEW mode, no DCC\n");
+		pr_info("RealView GIC: set up interrupt controller to NEW mode, no DCC\n");
 	} else {
-		pr_err("TC11MP GIC setup: could not find syscon\n");
+		pr_err("RealView GIC setup: could not find syscon\n");
 		return -ENXIO;
 	}
 	return gic_of_init(node, parent);
 }
 IRQCHIP_DECLARE(armtc11mp_gic, "arm,tc11mp-gic", realview_gic_of_init);
+IRQCHIP_DECLARE(armeb11mp_gic, "arm,eb11mp-gic", realview_gic_of_init);
+IRQCHIP_DECLARE(armeb11mp_revb_gic, "arm,eb11mp-revb-gic", realview_gic_of_init);
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb 18 05:46:40 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 18 Feb 2016 14:46:40 +0100
Subject: [PATCH 2/3] soc: versatile: dynamically detect RealView HBI numbers
Message-ID: <1455803200-22797-1-git-send-email-linus.walleij@linaro.org>

We cannot pile all numbers on this list, just print the three hex
digits representing the board ID so we can handle all the new
RealView boards.

Cc: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/soc/versatile/soc-realview.c | 19 ++++---------------
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/drivers/soc/versatile/soc-realview.c b/drivers/soc/versatile/soc-realview.c
index c337764de867..282e371378ce 100644
--- a/drivers/soc/versatile/soc-realview.c
+++ b/drivers/soc/versatile/soc-realview.c
@@ -31,18 +31,6 @@ static const struct of_device_id realview_soc_of_match[] = {
 
 static u32 realview_coreid;
 
-static const char *realview_board_str(u32 id)
-{
-	switch ((id >> 16) & 0xfff) {
-	case 0x0147:
-		return "HBI-0147";
-	case 0x0159:
-		return "HBI-0159";
-	default:
-		return "Unknown";
-	}
-}
-
 static const char *realview_arch_str(u32 id)
 {
 	switch ((id >> 8) & 0xf) {
@@ -69,7 +57,7 @@ static ssize_t realview_get_board(struct device *dev,
 			      struct device_attribute *attr,
 			      char *buf)
 {
-	return sprintf(buf, "%s\n", realview_board_str(realview_coreid));
+	return sprintf(buf, "HBI-%03x\n", ((realview_coreid >> 16) & 0xfff));
 }
 
 static struct device_attribute realview_board_attr =
@@ -133,8 +121,9 @@ static int realview_soc_probe(struct platform_device *pdev)
 	device_create_file(soc_device_to_device(soc_dev), &realview_arch_attr);
 	device_create_file(soc_device_to_device(soc_dev), &realview_build_attr);
 
-	dev_info(&pdev->dev, "RealView Syscon Core ID: 0x%08x\n",
-		 realview_coreid);
+	dev_info(&pdev->dev, "RealView Syscon Core ID: 0x%08x, HBI-%03x\n",
+		 realview_coreid,
+		 ((realview_coreid >> 16) & 0xfff));
 	/* FIXME: add attributes for SoC to sysfs */
 	return 0;
 }
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb 18 05:46:51 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 18 Feb 2016 14:46:51 +0100
Subject: [PATCH 3/3] ARM: realview: support all the RealView EB board variants
Message-ID: <1455803211-22843-1-git-send-email-linus.walleij@linaro.org>

The ARM RealView Evaluation Baseboards are basically these:

- The original ARMv5 EB board with an ARM926EJ-S, ARM1136 or
  ARM1176 core tile here described in arm-realview-eb.dts
  no matter which of these core tiles is being used. This
  can be emulated by QEMU "realview-eb" machine, which by
  default will have the ARM926EJ-S core tile.

- The same board with one of three MPCore Core tiles:
  ARM11MPCore, not to be confused with the similar ARM
  PB11MPCore ARM11MPCore test system. This exist in
  two revisions:
  - Revision A modeled in arm-realview-eb-11mp.dts
  - Revision B modeled arm-realview-eb-11mp-revb.dts
    Revision B can be emulated by the QEMU
    "realview-eb-mpcore" machine, but to match the hardware
    also the argument -smp cpus=4 must be passed so that
    it has four CPU cores, like the hardware.

  There is also evidently from the code in the kernel a
  Cortex-A9 core tile for the EB, and this is modeled in
  arm-realview-eb-a9mp.dts based on the kernel boardfile.
  I have not found a user guide for this EB core tile on
  the ARM website and it seems uncommon. It is however
  included for completeness.

Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Peter Maydell <peter.maydell at linaro.org>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/Makefile                      |   6 +-
 arch/arm/boot/dts/arm-realview-eb-11mp-revb.dts |  86 +++++
 arch/arm/boot/dts/arm-realview-eb-11mp.dts      |  74 ++++
 arch/arm/boot/dts/arm-realview-eb-a9mp.dts      |  70 ++++
 arch/arm/boot/dts/arm-realview-eb-mp.dtsi       | 224 ++++++++++++
 arch/arm/boot/dts/arm-realview-eb.dts           | 166 +++++++++
 arch/arm/boot/dts/arm-realview-eb.dtsi          | 453 ++++++++++++++++++++++++
 7 files changed, 1078 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/arm-realview-eb-11mp-revb.dts
 create mode 100644 arch/arm/boot/dts/arm-realview-eb-11mp.dts
 create mode 100644 arch/arm/boot/dts/arm-realview-eb-a9mp.dts
 create mode 100644 arch/arm/boot/dts/arm-realview-eb-mp.dtsi
 create mode 100644 arch/arm/boot/dts/arm-realview-eb.dts
 create mode 100644 arch/arm/boot/dts/arm-realview-eb.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 76baaa51080c..39deb1741465 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -533,7 +533,11 @@ dtb-$(CONFIG_ARCH_QCOM) += \
 	qcom-msm8974-sony-xperia-honami.dtb
 dtb-$(CONFIG_ARCH_REALVIEW) += \
 	arm-realview-pb1176.dtb \
-	arm-realview-pb11mp.dtb
+	arm-realview-pb11mp.dtb \
+	arm-realview-eb.dtb \
+	arm-realview-eb-11mp.dtb \
+	arm-realview-eb-11mp-revb.dtb \
+	arm-realview-eb-a9mp.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3036-evb.dtb \
 	rk3036-kylin.dtb \
diff --git a/arch/arm/boot/dts/arm-realview-eb-11mp-revb.dts b/arch/arm/boot/dts/arm-realview-eb-11mp-revb.dts
new file mode 100644
index 000000000000..02b16e93b9cf
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-eb-11mp-revb.dts
@@ -0,0 +1,86 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "arm-realview-eb-11mp.dts"
+
+/ {
+	model = "ARM RealView EB ARM11MPCore Revision B";
+};
+
+&intc {
+	compatible = "arm,eb11mp-revb-gic";
+	reg = <0x10101000 0x1000>,
+	      <0x10100100 0x100>;
+};
+
+&L2 {
+	reg = <0x10102000 0x1000>;
+};
+
+&scu {
+	reg = <0x10100000 0x100>;
+};
+
+&twd_timer {
+	reg = <0x10100600 0x20>;
+};
+
+&twd_wdog {
+	reg = <0x10100620 0x20>;
+};
+
+/*
+ * On revision B, we cannot reach the secondary interrupt
+ * controller, as a result, some peripherals that are dependent
+ * on their IRQ cannot be reached, so disable them.
+ */
+&intc_second {
+	status = "disabled";
+};
+
+&gpio0 {
+	status = "disabled";
+};
+
+&gpio1 {
+	status = "disabled";
+};
+
+&gpio2 {
+	status = "disabled";
+};
+
+&serial2 {
+	status = "disabled";
+};
+
+&serial3 {
+	status = "disabled";
+};
+
+&ssp {
+	status = "disabled";
+};
+
+&wdog {
+	status = "disabled";
+};
diff --git a/arch/arm/boot/dts/arm-realview-eb-11mp.dts b/arch/arm/boot/dts/arm-realview-eb-11mp.dts
new file mode 100644
index 000000000000..f2a2ffede0b0
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-eb-11mp.dts
@@ -0,0 +1,74 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "arm-realview-eb-mp.dtsi"
+
+/ {
+	model = "ARM RealView EB ARM11MPCore";
+	arm,hbi = <0x146>;
+
+	/*
+	 * This is the ARM11 MPCore tile (HBI-0146) used with the RealView EB.
+	 * Reference: ARM DUI 0318F
+	 *
+	 * To run this machine with QEMU, specify the following:
+	 * qemu-system-arm -M realview-eb-mpcore -smp cpus=4
+	 */
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		enable-method = "arm,realview-smp";
+
+		MP11_0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,arm11mpcore";
+			reg = <0>;
+			next-level-cache = <&L2>;
+		};
+
+		MP11_1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,arm11mpcore";
+			reg = <1>;
+			next-level-cache = <&L2>;
+		};
+
+		MP11_2: cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,arm11mpcore";
+			reg = <2>;
+			next-level-cache = <&L2>;
+		};
+
+		MP11_3: cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,arm11mpcore";
+			reg = <3>;
+			next-level-cache = <&L2>;
+		};
+	};
+};
+
+&pmu {
+	interrupt-affinity = <&MP11_0>, <&MP11_1>, <&MP11_2>, <&MP11_3>;
+};
diff --git a/arch/arm/boot/dts/arm-realview-eb-a9mp.dts b/arch/arm/boot/dts/arm-realview-eb-a9mp.dts
new file mode 100644
index 000000000000..967684b3636c
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-eb-a9mp.dts
@@ -0,0 +1,70 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "arm-realview-eb-mp.dtsi"
+
+/ {
+	model = "ARM RealView EB Cortex A9 MPCore";
+
+	/*
+	 * This is the Cortex A9 MPCore tile used with the
+	 * RealView EB.
+	 */
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		enable-method = "arm,realview-smp";
+
+		A9_0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+			next-level-cache = <&L2>;
+		};
+
+		A9_1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <1>;
+			next-level-cache = <&L2>;
+		};
+
+		A9_2: cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <2>;
+			next-level-cache = <&L2>;
+		};
+
+		A9_3: cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <3>;
+			next-level-cache = <&L2>;
+		};
+	};
+};
+
+&pmu {
+	interrupt-affinity = <&A9_0>, <&A9_1>, <&A9_2>, <&A9_3>;
+};
diff --git a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
new file mode 100644
index 000000000000..6e172895c7e5
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
@@ -0,0 +1,224 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "arm-realview-eb.dtsi"
+
+/*
+ * This is the common include file for all MPCore variants of the
+ * Evaluation Baseboard, i.e. ARM11MPCore, ARM11MPCore Revision B
+ * and Cortex-A9 MPCore.
+ */
+/ {
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "arm,realview-eb-soc", "simple-bus";
+		regmap = <&syscon>;
+		ranges;
+
+		intc: interrupt-controller at 1f000100 {
+			compatible = "arm,eb11mp-gic";
+			#interrupt-cells = <3>;
+			#address-cells = <1>;
+			interrupt-controller;
+			reg = <0x1f001000 0x1000>,
+			      <0x1f000100 0x100>;
+		};
+
+		/* Secondary interrupt controller on the FPGA */
+		intc_second: interrupt-controller at 10040000 {
+			compatible = "arm,gic-400";
+			#interrupt-cells = <3>;
+			#address-cells = <1>;
+			interrupt-controller;
+			reg = <0x10041000 0x1000>,
+			      <0x10040000 0x100>;
+			interrupt-parent = <&intc>;
+			interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		L2: l2-cache {
+			compatible = "arm,l220-cache";
+			reg = <0x1f002000 0x1000>;
+			interrupt-parent = <&intc>;
+			interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 30 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 31 IRQ_TYPE_LEVEL_HIGH>;
+			cache-unified;
+			cache-level = <2>;
+			/*
+			 * Override default cache size, sets and
+			 * associativity as these may be erroneously set
+			 * up by boot loader(s), probably for safety
+			 * since th outer sync operation can cause the
+			 * cache to hang unless disabled.
+			 */
+			cache-size = <1048576>; // 1MB
+			cache-sets = <4096>;
+			cache-line-size = <32>;
+			arm,shared-override;
+			arm,parity-enable;
+			arm,outer-sync-disable;
+		};
+
+		scu: scu at 1f000000 {
+			compatible = "arm,arm11mp-scu";
+			reg = <0x1f000000 0x100>;
+		};
+
+		twd_timer: timer at 1f000600 {
+			compatible = "arm,arm11mp-twd-timer";
+			reg = <0x1f000600 0x20>;
+			interrupt-parent = <&intc>;
+			interrupts = <1 13 0xf04>;
+		};
+
+		twd_wdog: watchdog at 1f000620 {
+			compatible = "arm,arm11mp-twd-wdt";
+			reg = <0x1f000620 0x20>;
+			interrupt-parent = <&intc>;
+			interrupts = <1 14 0xf04>;
+		};
+
+		/* PMU with one IRQ line per core */
+		pmu: pmu at 0 {
+			compatible = "arm,arm11mpcore-pmu";
+			interrupt-parent = <&intc>;
+			interrupts = <0 17 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 18 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 19 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 20 IRQ_TYPE_LEVEL_HIGH>;
+		};
+	};
+};
+
+/*
+ * This adapts all the peripherals to the interrupt routing
+ * to the GIC on the core tile.
+ */
+
+&ethernet {
+	interrupt-parent = <&intc>;
+	interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&usb {
+	interrupt-parent = <&intc>;
+	interrupts = <0 3 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&aaci {
+	interrupt-parent = <&intc>;
+	interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&mmc {
+	interrupt-parent = <&intc>;
+	interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>,
+			<0 15 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&kmi0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&kmi1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&charlcd {
+	interrupt-parent = <&intc>;
+	interrupts = <0  IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer01 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 1 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer23 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&rtc {
+	interrupt-parent = <&intc>;
+	interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+/*
+ * On revision A, these peripherals does not have their IRQ lines
+ * routed to the core tile, but they can be reached on the secondary
+ * GIC.
+ */
+&gpio0 {
+	interrupt-parent = <&intc_second>;
+	interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio1 {
+	interrupt-parent = <&intc_second>;
+	interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio2 {
+	interrupt-parent = <&intc_second>;
+	interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial2 {
+	interrupt-parent = <&intc_second>;
+	interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
+	status = "okay";
+};
+
+&serial3 {
+	interrupt-parent = <&intc_second>;
+	interrupts = <0 15 IRQ_TYPE_LEVEL_HIGH>;
+	status = "okay";
+};
+
+&ssp {
+	interrupt-parent = <&intc_second>;
+	interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+	status = "okay";
+};
+
+&wdog {
+	interrupt-parent = <&intc_second>;
+	interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>;
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/arm-realview-eb.dts b/arch/arm/boot/dts/arm-realview-eb.dts
new file mode 100644
index 000000000000..764bc5b7b958
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-eb.dts
@@ -0,0 +1,166 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "arm-realview-eb.dtsi"
+
+/ {
+	model = "ARM RealView EB";
+	compatible = "arm,realview-eb";
+	arm,hbi = <0x140>;
+
+	/*
+	 * This is the core tile with the CPU and GIC etc for the
+	 * ARM926EJ-S, ARM1136, ARM1176 that does not have L2 cache
+	 * or PMU.
+	 *
+	 * To run this machine with QEMU, specify the following:
+	 * qemu-system-arm -M realview-eb
+	 * Unless specified, QEMU will emulate an ARM926EJ-S core tile.
+	 * Switches -cpu arm1136 or -cpu arm1176 emulates the other
+	 * core tiles.
+	 */
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "arm,realview-eb-soc", "simple-bus";
+		regmap = <&syscon>;
+		ranges;
+
+		intc: interrupt-controller at 10040000 {
+			compatible = "arm,gic-400";
+			#interrupt-cells = <3>;
+			#address-cells = <1>;
+			interrupt-controller;
+			reg = <0x10041000 0x1000>,
+			      <0x10040000 0x100>;
+		};
+	};
+};
+
+/*
+ * This adapts all the peripherals to the interrupt routing
+ * to the GIC on the core tile.
+ */
+
+&ethernet {
+	interrupt-parent = <&intc>;
+	interrupts = <0 28 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&usb {
+	interrupt-parent = <&intc>;
+	interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&aaci {
+	interrupt-parent = <&intc>;
+	interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&mmc {
+	interrupt-parent = <&intc>;
+	interrupts = <0 17 IRQ_TYPE_LEVEL_HIGH>,
+			<0 18 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&kmi0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&kmi1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&charlcd {
+	interrupt-parent = <&intc>;
+	interrupts = <0 22 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 12 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 13 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial2 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial3 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 15 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&ssp {
+	interrupt-parent = <&intc>;
+	interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&wdog {
+	interrupt-parent = <&intc>;
+	interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer01 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer23 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio2 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&rtc {
+	interrupt-parent = <&intc>;
+	interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&clcd {
+	interrupt-parent = <&intc>;
+	interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
+};
diff --git a/arch/arm/boot/dts/arm-realview-eb.dtsi b/arch/arm/boot/dts/arm-realview-eb.dtsi
new file mode 100644
index 000000000000..1c6a040218e3
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-eb.dtsi
@@ -0,0 +1,453 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "skeleton.dtsi"
+
+/ {
+	compatible = "arm,realview-eb";
+
+	chosen { };
+
+	aliases {
+		serial0 = &serial0;
+		serial1 = &serial1;
+		serial2 = &serial2;
+		serial3 = &serial3;
+		i2c0 = &i2c;
+	};
+
+	memory {
+		/* 128 MiB memory @ 0x0 */
+		reg = <0x00000000 0x08000000>;
+	};
+
+	/* The voltage to the MMC card is hardwired at 3.3V */
+	vmmc: fixedregulator at 0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vmmc";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+        };
+
+	veth: fixedregulator at 0 {
+		compatible = "regulator-fixed";
+		regulator-name = "veth";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+	};
+
+	xtal24mhz: xtal24mhz at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <24000000>;
+	};
+
+	timclk: timclk at 1M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <24>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	mclk: mclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	kmiclk: kmiclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	sspclk: sspclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	uartclk: uartclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	wdogclk: wdogclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	/* FIXME: this actually hangs off the PLL clocks */
+	pclk: pclk at 0 {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <0>;
+	};
+
+	flash0 at 40000000 {
+		/* 2 * 32MiB NOR Flash memory */
+		compatible = "arm,versatile-flash", "cfi-flash";
+		reg = <0x40000000 0x04000000>;
+		bank-width = <4>;
+	};
+
+	flash1 at 44000000 {
+		/* 2 * 32MiB NOR Flash memory */
+		compatible = "arm,versatile-flash", "cfi-flash";
+		reg = <0x44000000 0x04000000>;
+		bank-width = <4>;
+	};
+
+	/* SMSC 9118 ethernet with PHY and EEPROM */
+	ethernet: ethernet at 4e000000 {
+		compatible = "smsc,lan9118", "smsc,lan9115";
+		reg = <0x4e000000 0x10000>;
+		phy-mode = "mii";
+		reg-io-width = <4>;
+		smsc,irq-active-high;
+		smsc,irq-push-pull;
+		vdd33a-supply = <&veth>;
+		vddvario-supply = <&veth>;
+	};
+
+	usb: usb at 4f000000 {
+		compatible = "nxp,usb-isp1761";
+		reg = <0x4f000000 0x20000>;
+		port1-otg;
+	};
+
+	/* These peripherals are inside the FPGA */
+	fpga {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		ranges;
+
+		syscon: syscon at 10000000 {
+			compatible = "arm,realview-eb-syscon", "syscon", "simple-mfd";
+			reg = <0x10000000 0x1000>;
+
+			led at 08.0 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x01>;
+				label = "versatile:0";
+				linux,default-trigger = "heartbeat";
+				default-state = "on";
+			};
+			led at 08.1 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x02>;
+				label = "versatile:1";
+				linux,default-trigger = "mmc0";
+				default-state = "off";
+			};
+			led at 08.2 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x04>;
+				label = "versatile:2";
+				linux,default-trigger = "cpu0";
+				default-state = "off";
+			};
+			led at 08.3 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x08>;
+				label = "versatile:3";
+				default-state = "off";
+			};
+			led at 08.4 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x10>;
+				label = "versatile:4";
+				default-state = "off";
+			};
+			led at 08.5 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x20>;
+				label = "versatile:5";
+				default-state = "off";
+			};
+			led at 08.6 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x40>;
+				label = "versatile:6";
+				default-state = "off";
+			};
+			led at 08.7 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x80>;
+				label = "versatile:7";
+				default-state = "off";
+			};
+			oscclk0: osc0 at 0c {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x0C>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk1: osc1 at 10 {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x10>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk2: osc2 at 14 {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x14>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk3: osc3 at 18 {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x18>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk4: osc4 at 1c {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x1c>;
+				clocks = <&xtal24mhz>;
+			};
+		};
+
+		i2c: i2c at 10002000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "arm,versatile-i2c";
+			reg = <0x10002000 0x1000>;
+
+			rtc at 68 {
+				compatible = "dallas,ds1338";
+				reg = <0x68>;
+			};
+		};
+
+		aaci: aaci at 10004000 {
+			compatible = "arm,pl041", "arm,primecell";
+			reg = <0x10004000 0x1000>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		mmc: mmcsd at 10005000 {
+			compatible = "arm,pl18x", "arm,primecell";
+			reg = <0x10005000 0x1000>;
+
+			/* Due to frequent FIFO overruns, use just 500 kHz */
+			max-frequency = <500000>;
+			bus-width = <4>;
+			cap-sd-highspeed;
+			cap-mmc-highspeed;
+			clocks = <&mclk>, <&pclk>;
+			clock-names = "mclk", "apb_pclk";
+			vmmc-supply = <&vmmc>;
+			cd-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
+			wp-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
+		};
+
+		kmi0: kmi at 10006000 {
+			compatible = "arm,pl050", "arm,primecell";
+			reg = <0x10006000 0x1000>;
+			clocks = <&kmiclk>, <&pclk>;
+			clock-names = "KMIREFCLK", "apb_pclk";
+		};
+
+		kmi1: kmi at 10007000 {
+			compatible = "arm,pl050", "arm,primecell";
+			reg = <0x10007000 0x1000>;
+			clocks = <&kmiclk>, <&pclk>;
+			clock-names = "KMIREFCLK", "apb_pclk";
+		};
+
+		charlcd: fpga_charlcd: charlcd at 10008000 {
+			compatible = "arm,versatile-lcd";
+			reg = <0x10008000 0x1000>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		serial0: serial at 10009000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x10009000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+		};
+
+		serial1: serial at 1000a000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x1000a000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+		};
+
+		serial2: serial at 1000b000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x1000b000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+		};
+
+		serial3: serial at 1000c000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x1000c000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+		};
+
+		ssp: ssp at 1000d000 {
+			compatible = "arm,pl022", "arm,primecell";
+			reg = <0x1000d000 0x1000>;
+			clocks = <&sspclk>, <&pclk>;
+			clock-names = "SSPCLK", "apb_pclk";
+		};
+
+		wdog: watchdog at 10010000 {
+			compatible = "arm,sp805", "arm,primecell";
+			reg = <0x10010000 0x1000>;
+			clocks = <&wdogclk>, <&pclk>;
+			clock-names = "wdogclk", "apb_pclk";
+			status = "disabled";
+		};
+
+		timer01: timer at 10011000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x10011000 0x1000>;
+			clocks = <&timclk>, <&timclk>, <&pclk>;
+			clock-names = "timer1", "timer2", "apb_pclk";
+		};
+
+		timer23: timer at 10012000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x10012000 0x1000>;
+			clocks = <&timclk>, <&timclk>, <&pclk>;
+			clock-names = "timer1", "timer2", "apb_pclk";
+		};
+
+		gpio0: gpio at 10013000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x10013000 0x1000>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio1: gpio at 10014000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x10014000 0x1000>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio2: gpio at 10015000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x10015000 0x1000>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		rtc: rtc at 10017000 {
+			compatible = "arm,pl031", "arm,primecell";
+			reg = <0x10017000 0x1000>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		clcd: clcd at 10020000 {
+			compatible = "arm,pl111", "arm,primecell";
+			reg = <0x10020000 0x1000>;
+			interrupt-names = "combined";
+			clocks = <&oscclk0>, <&pclk>;
+			clock-names = "clcdclk", "apb_pclk";
+
+			port {
+				clcd_pads: endpoint {
+					remote-endpoint = <&clcd_panel>;
+					arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+				};
+			};
+
+			panel {
+				compatible = "panel-dpi";
+
+				port {
+					clcd_panel: endpoint {
+						remote-endpoint = <&clcd_pads>;
+					};
+				};
+
+				/* Standard 640x480 VGA timings */
+				panel-timing {
+					clock-frequency = <25175000>;
+					hactive = <640>;
+					hback-porch = <48>;
+					hfront-porch = <16>;
+					hsync-len = <96>;
+					vactive = <480>;
+					vback-porch = <33>;
+					vfront-porch = <10>;
+					vsync-len = <2>;
+				};
+			};
+		};
+	};
+};
-- 
2.4.3



From broonie at kernel.org  Thu Feb 18 05:57:51 2016
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Feb 2016 13:57:51 +0000
Subject: [PATCH v2.1 2/4] spi: rockchip: add bindings for rk3399 spi
In-Reply-To: <56C5959D.3030806@rock-chips.com>
References: <1455762983-29980-1-git-send-email-jay.xu@rock-chips.com>
 <1455762983-29980-3-git-send-email-jay.xu@rock-chips.com>
 <20160218094108.GA7129@sirena.org.uk> <2327512.KAqs6H56Km@phil>
 <56C5959D.3030806@rock-chips.com>
Message-ID: <20160218135751.GE7129@sirena.org.uk>

On Thu, Feb 18, 2016 at 05:57:49PM +0800, Jianqun Xu wrote:

> I'm a little confuse, I have upstreamed rockchip-i2s, and the i2s driver set
> the compatible like:
> - compatible: should be one of the followings
>    - "rockchip,rk3066-i2s": for rk3066
>    - "rockchip,rk3188-i2s", "rockchip,rk3066-i2s": for rk3188
>    - "rockchip,rk3288-i2s", "rockchip,rk3066-i2s": for rk3288
>    - "rockchip,rk3399-i2s", "rockchip,rk3066-i2s": for rk3399
> and the driver only has
> static const struct of_device_id rockchip_i2s_match[] = {
> 	{ .compatible = "rockchip,rk3066-i2s", },
> 	{},
> };

> The spi of rk3399 as same as rk3066, rk3188, rk3288, like i2s, if they are
> keep different rules ?

No, that's just something that got missed in review and which should be
fixed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160218/6cb04dc6/attachment.sig>

From arnd at arndb.de  Thu Feb 18 06:01:52 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 15:01:52 +0100
Subject: [PATCH 0/9] ARM: randconfig testing fallout
Message-ID: <1455804123-2526139-1-git-send-email-arnd@arndb.de>

Here are some new patches that I've collected as part of the randconfig
testing. I don't think any of these are urgent, but it would be nice
to get them merged to cut down on the noise in randconfig testing.

The NR_IPIS patch is the only one that I expect to matter to real
users, but I think it's been broken for several years without anyone
noticing.

	Arnd



From arnd at arndb.de  Thu Feb 18 06:01:53 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 15:01:53 +0100
Subject: [PATCH 1/9] ARM: ARMv7-M uses BE-8, not BE-32
In-Reply-To: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
Message-ID: <1455804123-2526139-2-git-send-email-arnd@arndb.de>

When configuring the kernel for big-endian, we set either BE-8 or BE-32
based on the CPU architecture level. Until linux-4.4, we did not have
any ARMv7-M platform allowing big-endian builds, but now i.MX/Vybrid
is in that category, adn we get a build error because of this:

arch/arm/kernel/module-plts.c: In function 'get_module_plt':
arch/arm/kernel/module-plts.c:60:46: error: implicit declaration of function '__opcode_to_mem_thumb32' [-Werror=implicit-function-declaration]

This comes down to picking the wrong default, ARMv7-M uses BE8
like ARMv7-A does. Changing the default gets the kernel to compile
and presumably works.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 55347662e5ed..ff1637365494 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -723,7 +723,7 @@ config CPU_BIG_ENDIAN
 config CPU_ENDIAN_BE8
 	bool
 	depends on CPU_BIG_ENDIAN
-	default CPU_V6 || CPU_V6K || CPU_V7
+	default CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7M
 	help
 	  Support for the BE-8 (big-endian) mode on ARMv6 and ARMv7 processors.
 
-- 
2.7.0



From arnd at arndb.de  Thu Feb 18 06:01:54 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 15:01:54 +0100
Subject: [PATCH 2/9] ARM: change NR_IPIS to 8
In-Reply-To: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
Message-ID: <1455804123-2526139-3-git-send-email-arnd@arndb.de>

When function tracing for IPIs is enabled, we get a warning for an
overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
as triggered by raise_nmi():

arch/arm/kernel/smp.c: In function 'raise_nmi':
arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds [-Werror=array-bounds]
  trace_ipi_raise(target, ipi_types[ipinr]);

This is a correct warning as we actually overflow the array here.
To make the tracing work correctly, this extends the array by one
entry and increases NR_IPI accordingly.

This only works after patch e7273ff49acf ("ARM: 8488/1: Make
IPI_CPU_BACKTRACE a "non-secure" SGI"), which changed the number
assignment from '15' to '8'. If we decide to backport this patch
to stable kernels, we probably need to backport e7273ff49acf
as well.

As far as I can tell, the problem has existed since the tracepoints
were originally added, but it only triggered a gcc warning with the
later change to NR_IPIS.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI")
Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") # v3.17
---
 arch/arm/include/asm/hardirq.h | 2 +-
 arch/arm/kernel/smp.c          | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
index 3d7351c844aa..fe3ea776dc34 100644
--- a/arch/arm/include/asm/hardirq.h
+++ b/arch/arm/include/asm/hardirq.h
@@ -5,7 +5,7 @@
 #include <linux/threads.h>
 #include <asm/irq.h>
 
-#define NR_IPI	7
+#define NR_IPI	8
 
 typedef struct {
 	unsigned int __softirq_pending;
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index b4048e370730..d021566d71c2 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -482,6 +482,7 @@ static const char *ipi_types[NR_IPI] __tracepoint_string = {
 	S(IPI_CPU_STOP, "CPU stop interrupts"),
 	S(IPI_IRQ_WORK, "IRQ work interrupts"),
 	S(IPI_COMPLETION, "completion interrupts"),
+	S(IPI_CPU_BACKTRACE, "CPU backtrace"),
 };
 
 static void smp_cross_call(const struct cpumask *target, unsigned int ipinr)
-- 
2.7.0



From arnd at arndb.de  Thu Feb 18 06:01:55 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 15:01:55 +0100
Subject: [PATCH 3/9] ARM: make free_memmap as __init
In-Reply-To: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
Message-ID: <1455804123-2526139-4-git-send-email-arnd@arndb.de>

free_memmap is an inline function, but gcc may choose to ignore that
when CONFIG_OPTIMIZE_INLINING is set. In that case it is put in the
.text section, causing a kbuild warning:

WARNING: vmlinux.o(.text.unlikely+0x1a0): Section mismatch in reference from the function free_memmap() to the function .init.text:__memblock_free_early()
The function free_memmap() references
the function __init __memblock_free_early().
This is often because free_memmap lacks a __init
annotation or the annotation of __memblock_free_early is wrong.

FATAL: modpost: Section mismatches detected.
Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them.

This marks the function both inline and __init, which is a
correct annotation and avoids the problem.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mm/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 370581aeb871..a4db267c35b2 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -330,7 +330,7 @@ static inline void poison_init_mem(void *s, size_t count)
 		*p++ = 0xe7fddef0;
 }
 
-static inline void
+static inline void __init
 free_memmap(unsigned long start_pfn, unsigned long end_pfn)
 {
 	struct page *start_pg, *end_pg;
-- 
2.7.0



From arnd at arndb.de  Thu Feb 18 06:01:56 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 15:01:56 +0100
Subject: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values
In-Reply-To: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
Message-ID: <1455804123-2526139-5-git-send-email-arnd@arndb.de>

For platforms that are not yet converted to ARCH_MULTIPLATFORM,
we can disable CONFIG_ARM_PATCH_PHYS_VIRT, which in turn requires
setting a correct address here.

As we actualy know what all the values are supposed to be based
on the old mach/memory.h header file contents (from git history),
we can just add them here.

This also solves a problem in Kconfig where 'make randconfig'
fails to continue if no number is selected for a 'hex' option.
Users can still override the number at configuration time, e.g.
when the memory visible to the kernel starts at a nonstandard
address on some machine, but it should no longer be required
now.

To make this foolproof, another patch is required in mach-davinci
to prevent a configuration with both DMx and DA8xx enabled but
ARM_PATCH_PHYS_VIRT disabled. The two patches however can be
merged independently as there is no direct dependency between
them.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/Kconfig | 20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index be00b53f399b..7839c9923709 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -271,15 +271,29 @@ config PHYS_OFFSET
 	depends on !ARM_PATCH_PHYS_VIRT
 	default DRAM_BASE if !MMU
 	default 0x00000000 if ARCH_EBSA110 || \
+			ARCH_DOVE || \
 			ARCH_FOOTBRIDGE || \
+			(ARCH_GEMINI && GEMINI_MEM_SWAP) || \
 			ARCH_INTEGRATOR || \
+			ARCH_IOP33X || \
 			ARCH_IOP13XX || \
+			ARCH_IXP4XX || \
 			ARCH_KS8695 || \
-			(ARCH_REALVIEW && !REALVIEW_HIGH_PHYS_OFFSET)
-	default 0x10000000 if ARCH_OMAP1 || ARCH_RPC
+			(ARCH_REALVIEW && !REALVIEW_HIGH_PHYS_OFFSET) || \
+			ARCH_W90X900
+	default 0x10000000 if (ARCH_GEMINI && !GEMINI_MEM_SWAP) || \
+			ARCH_OMAP1 || \
+			ARCH_RPC
 	default 0x20000000 if ARCH_S5PV210
+	default 0x30000000 if ARCH_S3C24XX
 	default 0x70000000 if REALVIEW_HIGH_PHYS_OFFSET
-	default 0xc0000000 if ARCH_SA1100
+	default 0x80000000 if (ARCH_DAVINCI_DMx && !ARCH_DAVINCI_DA8XX) || \
+			ARCH_NETX || \
+			ARCH_LPC32XX
+	default 0xa0000000 if ARCH_IOP32X || ARCH_PXA
+	default 0xc0000000 if (ARCH_DAVINCI_DA8XX && !ARCH_DAVINCI_DMx) || \
+			ARCH_CLPS711X || \
+			ARCH_SA1100
 	help
 	  Please provide the physical address corresponding to the
 	  location of main memory in your system.
-- 
2.7.0



From arnd at arndb.de  Thu Feb 18 06:01:57 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 15:01:57 +0100
Subject: [PATCH 5/9] ARM: atags_to_fdt: don't warn about stack size
In-Reply-To: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
Message-ID: <1455804123-2526139-6-git-send-email-arnd@arndb.de>

The merge_fdt_bootargs() function by definition consumes more than 1024
bytes of stack because it has a 1024 byte command line on the stack,
meaning that we always get a warning when building this file:

arch/arm/boot/compressed/atags_to_fdt.c: In function 'merge_fdt_bootargs':
arch/arm/boot/compressed/atags_to_fdt.c:98:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]

However, as this is the decompressor and we know that it has a very shallow
call chain, and we do not actually risk overflowing the kernel stack
at runtime here.

This just shuts up the warning by disabling the warning flag for this
file.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/boot/compressed/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 7a6a58ef8aaf..b5db4c868640 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -85,6 +85,8 @@ $(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: $(srctree)/scripts/dtc/
 $(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \
 	$(addprefix $(obj)/,$(libfdt_hdrs))
 
+CFLAGS_REMOVE_atags_to_fdt.o += -Wframe-larger-than=${CONFIG_FRAME_WARN}
+
 ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
 OBJS	+= $(libfdt_objs) atags_to_fdt.o
 endif
-- 
2.7.0



From arnd at arndb.de  Thu Feb 18 06:01:58 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 15:01:58 +0100
Subject: [PATCH 6/9] ARM: uaccess: avoid warning for NOMMU in access_ok
In-Reply-To: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
Message-ID: <1455804123-2526139-7-git-send-email-arnd@arndb.de>

When CONFIG_MMU is disabled, the access_ok() and __range_ok()
macros always return success, and there is a cast to void
to ensure the compiler does not warn about an unused address
variable. However, at least one driver has a variable for
the size argument as well and does warn about that one:

drivers/vhost/vhost.c: In function 'vq_access_ok':
drivers/vhost/vhost.c:633:9: warning: unused variable 's' [-Wunused-variable]

This changes the macro to also ignore the size argument
explicitly to shut up that warning.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/include/asm/uaccess.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 35c9db857ebe..9c74c84a10d2 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -290,7 +290,7 @@ extern int __put_user_8(void *, unsigned long long);
 
 #define segment_eq(a, b)		(1)
 #define __addr_ok(addr)		((void)(addr), 1)
-#define __range_ok(addr, size)	((void)(addr), 0)
+#define __range_ok(addr, size)	((void)(addr), (void)(size), 0)
 #define get_fs()		(KERNEL_DS)
 
 static inline void set_fs(mm_segment_t fs)
-- 
2.7.0



From arnd at arndb.de  Thu Feb 18 06:01:59 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 15:01:59 +0100
Subject: [PATCH 7/9] ARM: move NO_DMA definition to ecard.h
In-Reply-To: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
Message-ID: <1455804123-2526139-8-git-send-email-arnd@arndb.de>

The NO_DMA macro is only used on the RiscPC ecard bus, and conflicts
with a couple of driver specific macros with the same name:

drivers/scsi/eata.c:571:0: warning: "NO_DMA" redefined
 #define NO_DMA  0xff
In file included from ../drivers/scsi/eata.c:495:0:
arch/arm/include/asm/dma.h:140:0: note: this is the location of the previous definition
 #define NO_DMA 255

This moves the definition out of the asm/dma.h header that is used
by all ISA DMA API users and into the ecard header.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/include/asm/dma.h   | 4 ----
 arch/arm/include/asm/ecard.h | 4 ++++
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/dma.h b/arch/arm/include/asm/dma.h
index bb4fa67da541..573128481fc4 100644
--- a/arch/arm/include/asm/dma.h
+++ b/arch/arm/include/asm/dma.h
@@ -136,10 +136,6 @@ extern void set_dma_speed(unsigned int chan, int cycle_ns);
  */
 extern int  get_dma_residue(unsigned int chan);
 
-#ifndef NO_DMA
-#define NO_DMA	255
-#endif
-
 #endif /* CONFIG_ISA_DMA_API */
 
 #ifdef CONFIG_PCI
diff --git a/arch/arm/include/asm/ecard.h b/arch/arm/include/asm/ecard.h
index eaea14676d57..d3e16628c792 100644
--- a/arch/arm/include/asm/ecard.h
+++ b/arch/arm/include/asm/ecard.h
@@ -83,6 +83,10 @@
 #define CONST const
 #endif
 
+#ifndef NO_DMA
+#define NO_DMA	255
+#endif
+
 #define MAX_ECARDS	9
 
 struct ecard_id {			/* Card ID structure		*/
-- 
2.7.0



From arnd at arndb.de  Thu Feb 18 06:02:00 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 15:02:00 +0100
Subject: [PATCH 8/9] ARM: do not use optimized do_div for ARMv3
In-Reply-To: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
Message-ID: <1455804123-2526139-9-git-send-email-arnd@arndb.de>

The gcc-4.9 optimization goes wrong while building target_core_iblock.c
for ARMv3 and leaves a bogus reference to __aeabi_uldivmod in the
output:

ERROR: "__aeabi_uldivmod" [drivers/target/target_core_iblock.ko] undefined!

I could not find anyone who is interested in fixing it in gcc,
so as a workaround this disables the do_div magic, just like
we do for old compilers and for OABI.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/include/asm/div64.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/include/asm/div64.h b/arch/arm/include/asm/div64.h
index 7d919a9b32e5..958fdc2363f5 100644
--- a/arch/arm/include/asm/div64.h
+++ b/arch/arm/include/asm/div64.h
@@ -58,6 +58,14 @@ static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
  */
 #define do_div(n, base) __div64_32(&(n), base)
 
+#elif defined(CONFIG_CPU_32v3)
+
+/*
+ * modern compiler versions (>= gcc-4.9) tend to misoptimize
+ * the code for ARMv3, and this is not getting fixed any more.
+ */
+#define do_div(n, base) __div64_32(&(n), base)
+
 #else
 
 /*
-- 
2.7.0



From arnd at arndb.de  Thu Feb 18 06:02:01 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 15:02:01 +0100
Subject: [PATCH 9/9] ARM: fix kprobe test with CONFIG_CPU_32v3
In-Reply-To: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
Message-ID: <1455804123-2526139-10-git-send-email-arnd@arndb.de>

ARMv3 did not have 16-bit load/store or 32-bit multiply instructions,
so building the kprobe test code fails with lots of warnings about
these:

/tmp/ccI4SKHx.s:19585: Error: selected processor does not support ARM mode `umull r0,r1,r2,r3'
/tmp/ccI4SKHx.s:19617: Error: selected processor does not support ARM mode `umullls r7,r8,r9,r10'
/tmp/ccI4SKHx.s:19645: Error: selected processor does not support ARM mode `umull lr,r12,r11,r13'
/tmp/ccI4SKHx.s:19727: Error: selected processor does not support ARM mode `umulls r0,r1,r2,r3'
...
/tmp/ccI4SKHx.s:21273: Error: selected processor does not support ARM mode `strh r0,[r1,-r2]'
/tmp/ccI4SKHx.s:21309: Error: selected processor does not support ARM mode `streqh r14,[r11,r12]'
/tmp/ccI4SKHx.s:21333: Error: selected processor does not support ARM mode `streqh r14,[r13,r12]'

This puts all the affected instructions inside an #ifdef section,
like we do for the other architecture levels.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/probes/kprobes/test-arm.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/probes/kprobes/test-arm.c b/arch/arm/probes/kprobes/test-arm.c
index 8866aedfdea2..4e8511f0582d 100644
--- a/arch/arm/probes/kprobes/test-arm.c
+++ b/arch/arm/probes/kprobes/test-arm.c
@@ -391,6 +391,7 @@ void kprobe_arm_test_cases(void)
 	TEST_UNSUPPORTED(__inst_arm(0xe0700090) " @ undef")
 	TEST_UNSUPPORTED(__inst_arm(0xe07fff9f) " @ undef")
 
+#if __LINUX_ARM_ARCH__ >= 4
 	TEST_RR(  "umull	r0, r1, r",2, VAL1,", r",3, VAL2,"")
 	TEST_RR(  "umullls	r7, r8, r",9, VAL2,", r",10, VAL1,"")
 	TEST_R(   "umull	lr, r12, r",11,VAL3,", r13")
@@ -436,6 +437,7 @@ void kprobe_arm_test_cases(void)
 	TEST_UNSUPPORTED(__inst_arm(0xe0f0f392) " @ smlals r0, pc, r2, r3")
 	TEST_UNSUPPORTED(__inst_arm(0xe0f0139f) " @ smlals r0, r1, pc, r3")
 	TEST_UNSUPPORTED(__inst_arm(0xe0f01f92) " @ smlals r0, r1, r2, pc")
+#endif
 
 	TEST_GROUP("Synchronization primitives")
 
@@ -478,7 +480,7 @@ void kprobe_arm_test_cases(void)
 	TEST_UNSUPPORTED("ldrexh	r2, [sp]")
 #endif
 	TEST_GROUP("Extra load/store instructions")
-
+#if __LINUX_ARM_ARCH__ >= 4
 	TEST_RPR(  "strh	r",0, VAL1,", [r",1, 48,", -r",2, 24,"]")
 	TEST_RPR(  "streqh	r",14,VAL2,", [r",11,0, ", r",12, 48,"]")
 	TEST_UNSUPPORTED(  "streqh	r14, [r13, r12]")
@@ -560,6 +562,7 @@ void kprobe_arm_test_cases(void)
 	TEST(      "ldrsh	r0, [pc, #0]")
 	TEST_UNSUPPORTED(__inst_arm(0xe1ffc3f0) "	@ ldrsh r12, [pc, #48]!")
 	TEST_UNSUPPORTED(__inst_arm(0xe0d9f3f0) "	@ ldrsh pc, [r9], #48")
+#endif
 
 #if __LINUX_ARM_ARCH__ >= 7
 	TEST_UNSUPPORTED("strht	r1, [r2], r3")
-- 
2.7.0



From arnd at arndb.de  Thu Feb 18 06:06:23 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 15:06:23 +0100
Subject: [PATCH] PCI: mvebu: Restrict build to 32-bit ARM
In-Reply-To: <1455802330-17565-1-git-send-email-thierry.reding@gmail.com>
References: <1455802330-17565-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <5051836.EUN3ennYNm@wuerfel>

On Thursday 18 February 2016 14:32:10 Thierry Reding wrote:
> From: Thierry Reding <treding at nvidia.com>
> 
> This driver uses PCI glue that is only available on 32-bit ARM. This
> used to work fine as long as ARCH_MVEBU and ARCH_DOVE were exclusively
> 32-bit, but that's changed now, with ARCH_MVEBU also being available
> on 64-bit ARM.
> 
> Signed-off-by: Thierry Reding <treding at nvidia.com>

Looks fine as a temporary workaround, but I think what we really want to
do here is to remove the dependency, as the new ARM64 platforms are going
to need this driver anyway.

	Arnd


From shawnguo at kernel.org  Thu Feb 18 06:09:13 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 18 Feb 2016 22:09:13 +0800
Subject: iMX7d cpu1 issue
In-Reply-To: <56C2D63F.1030408@compulab.co.il>
References: <56C2D63F.1030408@compulab.co.il>
Message-ID: <20160218140913.GY6756@tiger>

On Tue, Feb 16, 2016 at 09:56:47AM +0200, Ilya Ledvich wrote:
> Hi Shawn,
> I'm working on Compulab CL-SOM-IMX7 device (http://www.compulab.co.il/products/computer-on-modules/cl-som-imx7-freescale-i-mx-7-system-on-module)
> based on Freescale iMX7d CPU.
> I use the Freescale latest BSP imx_3.14.52_1.1.0_ga  and the Linux
> mainline v4.4-rc6 as a reference.
> I observe an issue with bringing up the second CPU core. Briefly,
> the kernel can successfully boot only when CPU1 fails to come
> online.
> In this case the boot log shows the following messages:
> ...
> CPU1: failed to come online
> Brought up 1 CPUs
> SMP: Total of 1 processors activated (6.00 BogoMIPS).
> ...
> 
> Otherwise, the device tries to start kernel several times until the
> boot process eventually crashes. Please see attached logs for more
> details.
> This never happens on mainline Linus kernel, because it never tries
> to bring up CPU1.
> Unfortunately, we cannot verify this behavior on reference board
> cause we have no one.
> Have you ever seen such behavior? Could you please advice something?

I never played i.MX7D support on any real hardware.  I copied a couple
Freescale/NXP people here.  Let's see if you can get some help from
them.

Shawn

> Starting kernel ...
> 
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
> Kernel command line: console=ttymxc0,115200 earlyprintk=ttymxc0,115200 root=/dev/nfs ip=dhcp nfsroot=192.168.11.24:/home/ilya/work/rootfs/sid-minbase,v3,tcp rw rootwait
> PID hash table entries: 4096 (order: 2, 16384 bytes)
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Memory: 700996K/1048576K available (6617K kernel code, 353K rwdata, 2280K rodata, 384K init, 421K bss, 347580K reserved, 0K highmem)
> Virtual kernel memory layout:
>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
>     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>     pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)
>     modules : 0x7f000000 - 0x7fe00000   (  14 MB)
>       .text : 0x80008000 - 0x808b8880   (8899 kB)
>       .init : 0x808b9000 - 0x80919080   ( 385 kB)
>       .data : 0x8091a000 - 0x80972680   ( 354 kB)
>        .bss : 0x8097268c - 0x809dbc00   ( 422 kB)
> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> Preemptible hierarchical RCU implementation.
>         RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
> RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
> NR_IRQS:16 nr_irqs:16 16
> Switching to timer-based delay loop
> sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655765682ns
> Architected cp15 timer(s) running at 8.00MHz (phys).
> sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2147483648000ns
> Ignoring duplicate/late registration of read_current_timer delay
> Console: colour dummy device 80x30
> Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=30000)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
> Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
> CPU: Testing write buffer coherency: ok
> /cpus/cpu at 0 missing clock-frequency property
> /cpus/cpu at 1 missing clock-frequency property
> CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> Setting up static identity map for 0x80647850 - 0x806478a8
> Switching to timer-based delay loop
> Calibrating delay loop (skipped) already calibrated this CPU6.00 BogoMIPS (lpj=30000)
> sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655765682ns
> Architected cp15 timer(s) running at 8.00MHz (phys).
> 2147483648000ns
> Current pid: 1 comm: swapper/0 / Idle pid: 0 comm: swapper/0
> Ignoring duplicate/late registra
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> CPU1: failed to come online
> Brought up 1 CPUs
> SMP: Total of 1 processors activated (6.00 BogoMIPS).
> CPU: All CPU(s) started in SVC mode.
> devtmpfs: initialized
> VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
> pinctrl core: initialized pinctrl subsystem
> regulator-dummy: no parameters
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> cpuidle: using governor ladder
> cpuidle: using governor menu
> Use WDOG1 as reset source
> syscon 30340000.iomuxc-gpr: regmap [mem 0x30340000-0x3034ffff] registered
> syscon 30350000.ocotp-ctrl: regmap [mem 0x30350000-0x3035ffff] registered
> syscon 30360000.anatop: regmap [mem 0x30360000-0x3036ffff] registered
> vdd1p0d: 800 <--> 1200 mV at 1000 mV 
> vdd1p2: 1100 <--> 1300 mV 
> syscon 30390000.src: regmap [mem 0x30390000-0x3039ffff] registered
> DDR type is DDR3!
> failed to find ocotp node
> failed to find ocotp node
> hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
> hw-breakpoint: maximum watchpoint size is 8 bytes.
> imx7d-pinctrl 302c0000.iomuxc-lpsr: initialized IMX pinctrl driver
> imx7d-pinctrl 30330000.iomuxc: initialized IMX pinctrl driver
> MU is ready for cross core communication!
> bio: create slab <bio-0> at 0
> mxs-dma 33000000.dma-apbh: initialized
> usb_otg1_vbus: 5000 mV 
> fec1_phy_nreset: 3300 mV 
> platform regulator.15: Driver reg-fixed-voltage requests probe deferral
> tsc2046-reg: 3300 mV 
> platform regulator.17: Driver reg-fixed-voltage requests probe deferral
> platform lcd_nstby_3v3.18: Driver reg-fixed-voltage requests probe deferral
> SCSI subsystem initialized
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> usbphy_nop1.10 supply vcc not found, using dummy regulator
> usbphy_nop2.11 supply vcc not found, using dummy regulator
> i2c i2c-1: IMX I2C adapter registered
> i2c i2c-3: IMX I2C adapter registered
> Linux video capture interface: v2.00
> pps_core: LinuxPPS API ver. 1 registered
> pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti at linux.it>
> PTP clock support registered
> MIPI CSI2 driver module loaded
> Advanced Linux Sound Architecture Driver Initialized.
> Switched to clocksource arch_sys_counter
> cfg80211: Calling CRDA to update world regulatory domain
> NET: Registered protocol family 2
> TCP established hash table entries: 8192 (order: 3, 32768 bytes)
> TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP: reno registered
> UDP hash table entries: 512 (order: 2, 16384 bytes)
> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
> NET: Registered protocol family 1
> RPC: Registered named UNIX socket transport module.
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> imx rpmsg driver is registered.
> Bus freq driver module loaded
> futex hash table entries: 512 (order: 3, 32768 bytes)
> VFS: Disk quotas dquot_6.5.2
> Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
> NFS: Registering the id_resolver key type
> Key type id_resolver registered
> Key type id_legacy registered
> jffs2: version 2.2. (NAND) ???? 2001-2006 Red Hat, Inc.
> fuse init (API version 7.22)
> msgmni has been set to 2009
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> backlight.20 supply power not found, using dummy regulator
> MIPI DSI driver module loaded
> 30730000.lcdif supply lcd not found, using dummy regulator
> mxsfb 30730000.lcdif: failed to find mxc display driver 
> Console: switching to colour frame buffer device 100x30
> mxsfb 30730000.lcdif: initialized
> imx-sdma 30bd0000.sdma: no event needs to be remapped
> imx-sdma 30bd0000.sdma: loaded firmware 4.1
> imx-sdma 30bd0000.sdma: initialized
> pfuze100-regulator 1-0008: Full layer: 1, Metal layer: 1
> pfuze100-regulator 1-0008: FAB: 0, FIN: 0
> pfuze100-regulator 1-0008: pfuze3000 found.
> SW1A: 700 <--> 3300 mV at 1100 mV 
> SW1B: 700 <--> 1475 mV at 1000 mV 
> SW2: 1500 <--> 1850 mV at 1800 mV 
> SW3: 900 <--> 1650 mV at 1350 mV 
> SWBST: 5000 <--> 5150 mV at 5000 mV 
> VSNVS: 1000 <--> 3000 mV at 3000 mV 
> VREFDDR: 750 mV 
> VLDO1: 1800 <--> 3300 mV at 1800 mV 
> VLDO2: 800 <--> 1550 mV at 1500 mV 
> VCCSD: 2850 <--> 3300 mV at 3300 mV 
> V33: 2850 <--> 3300 mV at 3300 mV 
> VLDO3: 1800 <--> 3300 mV at 3300 mV 
> VLDO4: 1800 <--> 3300 mV at 3300 mV 
> Serial: IMX driver
> 30860000.serial: ttymxc0 at MMIO 0x30860000 (irq = 58, base_baud = 1500000) is a IMX
> console [ttymxc0] enabled
> bootconsole [earlycon0] disabled
> serial: Freescale lpuart driver
> imx sema4 driver is registered.
> [drm] Initialized drm 1.1.0 20060810
> [drm] Initialized vivante 1.0.0 20120216 on minor 0
> brd: module loaded
> loop: module loaded
> at24 1-0050: 1024 byte 24c08 EEPROM, writable, 16 bytes/write
> m25p80 spi0.1: m25px16 (2048 Kbytes)
> 3 ofpart partitions found on MTD device spi0.1
> Creating 3 MTD partitions on "spi0.1":
> 0x000000000000-0x0000000c0000 : "uboot"
> 0x0000000c0000-0x000000100000 : "uboot environment"
> 0x000000100000-0x000000200000 : "splash"
> spi_imx 30820000.ecspi: probed
> 30be0000.ethernet supply phy not found, using dummy regulator
> pps pps0: new PPS source ptp0
> libphy: fec_enet_mii_bus: probed
> fec 30be0000.ethernet eth0: registered PHC device 0
> 30bf0000.ethernet supply phy not found, using dummy regulator
> pps pps1: new PPS source ptp1
> fec 30bf0000.ethernet (unregistered net_device): Invalid MAC address: 00:00:00:00:00:00
> fec 30bf0000.ethernet (unregistered net_device): Using random MAC address: c2:a3:b7:db:4d:b0
> fec 30bf0000.ethernet eth1: registered PHC device 1
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-mxc: Freescale On-Chip EHCI Host driver
> usbcore: registered new interface driver usb-storage
> 30b10200.usbmisc supply vbus-wakeup not found, using dummy regulator
> 30b20200.usbmisc supply vbus-wakeup not found, using dummy regulator
> 30b30200.usbmisc supply vbus-wakeup not found, using dummy regulator
> 30b20000.usb supply vbus not found, using dummy regulator
> ci_hdrc ci_hdrc.1: EHCI Host Controller
> ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 1
> ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> imx_usb 30b30000.usb: Can't register ci_hdrc platform device, err=-517
> platform 30b30000.usb: Driver imx_usb requests probe deferral
> mousedev: PS/2 mouse device common for all mice
> input: 30370000.snvs-pwrkey as /devices/soc.3/30000000.aips-bus/30370000.snvs-pwrkey/input/input0
> snvs_pwrkey 30370000.snvs-pwrkey: i.MX snvs powerkey probed
> rtc-em3027 1-0056: rtc core: registered rtc-em3027 as rtc0
> snvs_rtc 30370034.snvs-rtc-lp: rtc core: registered 30370034.snvs-rtc-l as rtc1
> i2c /dev entries driver
> IR NEC protocol handler initialized
> IR RC5(x) protocol handler initialized
> IR RC6 protocol handler initialized
> IR JVC protocol handler initialized
> IR Sony protocol handler initialized
> IR RC5 (streamzap) protocol handler initialized
> IR SANYO protocol handler initialized
> IR MCE Keyboard/mouse protocol handler initialized
> imx2-wdt 30280000.wdog: IMX2+ Watchdog Timer enabled. timeout=60s (nowayout=0)
> sdhci: Secure Digital Host Controller Interface driver
> sdhci: Copyright(c) Pierre Ossman
> sdhci-pltfm: SDHCI platform and OF driver helper
> sdhci-esdhc-imx 30b40000.usdhc: could not get ultra high speed state, work on normal mode
> mmc0: no vqmmc regulator found
> mmc0: no vmmc regulator found
> mmc0: SDHCI controller on 30b40000.usdhc [30b40000.usdhc] using ADMA
> sdhci-esdhc-imx 30b60000.usdhc: could not get ultra high speed state, work on normal mode
> mmc2: no vqmmc regulator found
> mmc2: no vmmc regulator found
> mmc0: new high speed SDHC card at address e624
> mmc2: SDHCI controller on 30b60000.usdhc [30b60000.usdhc] using ADMA
> mmcblk0: mmc0:e624 SS08G 7.40 GiB 
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
>  mmcblk0: unknown partition table
> TCP: cubic registered
> NET: Registered protocol family 10
> sit: IPv6 over IPv4 tunneling driver
> NET: Registered protocol family 17
> Key type dns_resolver registered
> usb 1-1: new high-speed USB device number 2 using ci_hdrc
> Registering SWP/SWPB emulation handler
> SWBST: disabling
> usb_otg1_vbus: disabling
> regulator-dummy: disabling
> imx mcc test is registered.
> fec2_phy_nreset: 3300 mV 
> usb_host_nreset: 3300 mV 
> lcd_nstby_3v3: no parameters
> ci_hdrc ci_hdrc.2: EHCI Host Controller
> ci_hdrc ci_hdrc.2: new USB bus registered, assigned bus number 2
> mmc2: BKOPS_EN bit is not set
> mmc2: new high speed DDR MMC card at address 0001
> mmcblk2: mmc2:0001 SEM04G 3.68 GiB 
> mmcblk2boot0: mmc2:0001 SEM04G partition 1 2.00 MiB
> mmcblk2boot1: mmc2:0001 SEM04G partition 2 2.00 MiB
> mmcblk2rpmb: mmc2:0001 SEM04G partition 3 2.00 MiB
>  mmcblk2: unknown partition table
>  mmcblk2boot1: unknown partition table
>  mmcblk2boot0: unknown partition table
> ci_hdrc ci_hdrc.2: USB 2.0 started, EHCI 1.00
> hub 2-0:1.0: USB hub found
> hub 2-0:1.0: 1 port detected
> Number of LUNs=8
> Mass Storage Function, version: 2009/09/11
> LUN: removable file: (no medium)
> usb-storage 1-1:1.0: USB Mass Storage device detected
> scsi0 : usb-storage 1-1:1.0
> Number of LUNs=1
> no file given for LUN0
> g_mass_storage ci_hdrc.0: failed to start g_mass_storage: -22
> rtc-em3027 1-0056: setting system clock to 2016-02-16 07:32:51 UTC (1455607971)
> fec 30be0000.ethernet eth0: Freescale FEC PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=30be0000.etherne:00, irq=-1)
> IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> fec 30bf0000.ethernet eth1: Freescale FEC PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=30be0000.etherne:01, irq=-1)
> usb 2-1: new high-speed USB device number 2 using ci_hdrc
> IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
> hub 2-1:1.0: USB hub found
> hub 2-1:1.0: 3 ports detected
> scsi 0:0:0:0: Direct-Access     SanDisk  Cruzer Slice     1.14 PQ: 0 ANSI: 2
> sd 0:0:0:0: [sda] 15633408 512-byte logical blocks: (8.00 GB/7.45 GiB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] No Caching mode page found
> sd 0:0:0:0: [sda] Assuming drive cache: write through
> sd 0:0:0:0: [sda] No Caching mode page found
> sd 0:0:0:0: [sda] Assuming drive cache: write through
>  sda: unknown partition table
> sd 0:0:0:0: [sda] No Caching mode page found
> sd 0:0:0:0: [sda] Assuming drive cache: write through
> sd 0:0:0:0: [sda] Attached SCSI removable disk
> libphy: 30be0000.etherne:00 - Link is Up - 1000/Full
> IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> Sending DHCP requests ., OK
> IP-Config: Got DHCP answer from 10.1.1.240, my address is 192.168.27.43
> IP-Config: Complete:
>      device=eth0, hwaddr=00:01:c0:1a:e9:13, ipaddr=192.168.27.43, mask=255.255.0.0, gw=192.168.0.110
>      host=192.168.27.43, domain=compulab.local, nis-domain=(none)
>      bootserver=10.1.1.247, rootserver=192.168.11.24, rootpath=
>      nameserver0=192.168.10.13, nameserver1=10.1.1.247
> ALSA device list:
>   No soundcards found.
> VFS: Mounted root (nfs filesystem) on device 0:13.
> devtmpfs: mounted
> Freeing unused kernel memory: 384K (808b9000 - 80919000)
> random: systemd urandom read with 58 bits of entropy available
> systemd[1]: systemd 228 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
> systemd[1]: Detected architecture arm.
> 
> Welcome to Debian GNU/Linux stretch/sid!
> 

> Starting kernel ...
> 
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
> Kernel command line: console=ttymxc0,115200 earlyprintk=ttymxc0,115200 root=/dev/nfs ip=dhcp nfsroot=192.168.11.24:/home/ilya/work/rootfs/sid-minbase,v3,tcp rw rootwait
> PID hash table entries: 4096 (order: 2, 16384 bytes)
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> Memory: 700996K/1048576K available (6617K kernel code, 353K rwdata, 2280K rodata, 384K init, 421K bss, 347580K reserved, 0K highmem)
> Virtual kernel memory layout:
>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
>     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>     pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)
>     modules : 0x7f000000 - 0x7fe00000   (  14 MB)
>       .text : 0x80008000 - 0x808b8880   (8899 kB)
>       .init : 0x808b9000 - 0x80919080   ( 385 kB)
>       .data : 0x8091a000 - 0x80972680   ( 354 kB)
>        .bss : 0x8097268c - 0x809dbc00   ( 422 kB)
> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> Preemptible hierarchical RCU implementation.
>         RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
> RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
> NR_IRQS:16 nr_irqs:16 16
> Switching to timer-based delay loop
> sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655765682ns
> Architected cp15 timer(s) running at 8.00MHz (phys).
> sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2147483648000ns
> Ignoring duplicate/late registration of read_current_timer delay
> Console: colour dummy device 80x30
> Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=30000)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
> Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
> CPU: Testing write buffer coherency: ok
> /cpus/cpu at 0 missing clock-frequency property
> /cpus/cpu at 1 missing clock-frequency property
> CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> Setting up static identity map for 0x80647850 - 0x806478a8
> Memory: 700996K/1048576K available (6617K kernel code, 353K rwdata, 2280K rodata, 384K init, 421K bss, 347580K reserved, 0K highmem)
> Virtual kernel memory layout:
>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
>     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>     pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)
>     modules : 0x7f000000 - 0x7fe00000   (  14 MB)
>       .text : 0x80008000 - 0x808b8880   (8899 kB)
>       .init : 0x808b9000 - 0x80919080   ( 385 kB)
>       .data : 0x8091a000 - 0x80972680   ( 354 kB)
>        .bss : 0x8097268c - 0x809dbc00   ( 422 kB)
> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> Preemptible hierarchical RCU implementation.
>         RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
> RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
> Calibrating delay loop (skipped) already calibrated this CPU6.00 BogoMIPS (lpj=30000)
> NR_IRQS:16 nr_irqs:16 16
> Switching to timer-based delay loop
> sched_clock: 32 bits at 3000kHz,
> [000001d8] *pgd=00000000
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> Modules linked in:
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> [00000008] *pgd=00000000
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
> Modules linked in:
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> [00000000] *pgd=00000000
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> Modules linked in:
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [00000000] *pgd=00000000
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> Modules linked in:
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [00000000] *pgd=00000000
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> Modules linked in:
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> nPU: PIPT / VIPT nonaliasing data cacCPhUe1,:  VfIaPiTl ealdia stion gc oimnes tornulctiinoe
>  Braoucghhet
> m 1Ma chCiPnUes 
> seSMlP::  CToomtaplu Loafb  S1B C-pirMoXc7es
> asbo oatcctoivnastoelde  (6[.0e0a rBloygcooMnI0P]S )e.n
> AClPeU:d 
> 0c mCaP: UC(MsA:)  rsetsaerrtveedd  i3n20  SMViCB m oadte .ac
> 0000
> cheemvotrmyp fpso:l iciyn:it iDaaltiaz ecda
>  writealloc
> On node 0 totalpages: 262144
> aree_area_init_nVFoPde :s unpopdoer t0,  pvg0d.a3t:  80i9m71p1l0e0m,e nntoord 4e1_ meamr_chmitaepc taubr7e5 9200 0p
> p 3  0D MvAa rzioannet :7  r2e0v4 85 
> tes uspeidn cftorlr c ormee:m mianpi
> i a lDiMzAe dz opnie:n c0t rpalge s sruebsseyrsvteedm
> 
> h DMAre guzloanteo:r -2d62u14m4m yp:a gneos ,p aLrIaFmOe tebrastc
> 31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Binux version 3.14.52+ (ilya at ilya-pc) NE(Tg:c cR evgeirssiotne r4e.d 7pr.o2t (oScoolu fracmeirlyy  C1o6de
> nch Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410DMfAc:0 7p5r]e arlelvoicsaitoend  52 5(6A RKMivB7 )p,o olc rf=1o0rc 5a3to8mi7cd 
> ahCPeU:r PeInPt Ta l/ lVoIcaPtTi noonns
> iasing datacp uciadclhee:,  uVsIPiTn g agloivaesirngn oir nlsatrducdteiro
> : cpauicdhlee
> mpMnagc hignoev emrnoodrel :m enCuo
>  abUs eS BWCD-iOMXG71
>   rbeosoettc osnosuorlcee
> [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> pysOcno nno d3e0 304 0t0o0t0.ailopmaugxecs-:g p2r6:2 r1eg4m4a
> 11freeme _0axr3ea0_3i40n0i0t_0no-d0ex3:0 3no4dfef f0f, ]p grdeagti s8t0er9ed7
> c, snyosdcoen_ m3e0m3_50m0a0p0 .aobc7o5t90p00-
> el  :DM Ar ezgomanpe :[ m2e0m48  0pxa3g0e3s50 00u0s-ed0 xf3o0r3 5mfefmffm]a pr
> o s teDrMeA dz
> : 0 pagseyss croesne r3v0e3d6
> 6f  0D.MaAn zaonteo:p:  2r6e2g1m4a4p  pa[gmeesm, 0 xL3I03F6O0 0b0a0t-c0hx:33013
> ffPE]R CrePgiUs:t eErmbeedd
> d1 8 pvdad1gp0eds:/ c8p0u0  @<a-b-7>3 1520000 0m Vs 8a3t2 01 0r080 1m9V2  
> 056 vdud13p22:7 61810
> x--B>o o1ti3n0g0  mLVin u
> 30 physical CPUsy sc0oxn0 
>  0L0i0n0ux. svrecr:si orne g3m.a1p4 .[m5em2 +0 x(3i0l39y0a0 at i0l0y-a0-xp3c0)3 9f(fgfccf ]v reergsiiosnt e4r.e7.d2
> 9ourcery CodeDBDeRn cthy pLei itse  2D0D1R23.!0
> -64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> sPU: ARMv7 Profacileesdso rt o[ 4f1i0nfdc 0o7c5o]tp  nroedvei
> ofna i5l e(dAR Mtvo 7fi)n,d  corc=o1t0pc 5n38o7dd
> e
> ghUw: -PbIrPeTa k/p oViInPt:T f ounnodn a5l i(a+s1i nrge sdeartvae dc)a cbhree,a kVIpPTo ianltia sianngd  in4s twartucchtpiooinn tc archee
>  mtaecrhsi.ne
> mhewl:- bCroemakppouiLnabt S:B Cm-aixMiXm7u
> etcbhopooticnotn ssoilzee  [eiarsl y8c onb0]y teensab.l
>  d
> 0ma: CMA: reserviemdx 73d2-0p iMnicBt ralt  3a0c20c00000000
> dMoemmuoxrc-yl ppsorl:i icniyt:i Daaltizae dca chIeM X wpriintceatlrlloc 
> noOenr 
> 0 0 tiomtxa7ldp-apgiensc:t r2l6 320134340
>  .frieoem_uarxeac_:i inniitt_inoadlei: zneodd eI M0X,  ppigndcatt r8l0 9dr7i1v1e0r0,
> ode_mem_map ab759000
>   DMUM iAs  zroenaed:y  2f0o4r 8c rpoasgse sc oursee dco mfmourn imceatmimoanp!
> 
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> tooting biLoi:n ucxr eaotne p hsylasbi ca<l bCiPoU- 00>x 0a
> 0 
> 2ux version 3.14.52+ (ilya at ilya-pc) (gcc vmexrss-idomna  43.37.020 00(0S0ou.rcdemray- aCpobdhe:B einnitciha Lliitzeed 
> b2.09-64) us)b _#ot8g 1SM_P vPbRuEsE: M5P0T 0M0o mnV  Fe
> 35 1f4e:c51_5p:h0y8_n rIeSTs e2t:0 136
> 0 m[0V00 0
> 04]pl a*tpgfd=o0r0m 0r0e0g0u0l0at
> =1.P1U5::  DArRMiv7v ePrr orecg-efsisoxre d-[v4o10lftcag0e 7r5e]q ureevisstis opnr 5o (bAeR Mdve7f)e,r raclr
> 453t8s7cd20
> IreCPgU::  P3I3P00T m V/  V
> T plnaotnfaolrima srienggu ldaattoar .c1a7c:h Der,i VvIePrT  reag-lfiiasxiend-gvo litnasgter urcetiqounes tcsa cpher
> liM odedfuelrerasl 
> rpleadt ifn:o
> - lMcadc_hinnsetb y_m3ovde3l.:18 :C omDpruivLera br eSgBC--ifMiXxe7d
> bboolottacgeo rnesqoulees [tesa rplroybec odn0e]f ereranla
> ed
> 0ma: CMASC:S Ir esusbesryvsedt 3e2m0 i nMiitBi aalti zace0d0
> 00
> ieusmbcoorrye :p orleigciys:te rDeatda  necwa chien twerritfeaaclel odcr
>  r Ouns bnofdse
> etoustbaclopraeg:e sr:e g2i6s2t1e4r4
>  nefrwe ei_natreear_fianciet _dnordiev:e rn ohdeu b0
> vpusgbdcato r8e0:97 11r0e0g,i stneordee_dm emn_emwa pd eabv7i5c9e0 d0r0i
> r   uDMsAb 
> oneus:bp h2y0_4n8o pp1.a1g0es  suuspepdl yf ovrc cm enmmoatp f
> dd  ,DM Au siznogn ed: u0m mpayg erse gruelsaetrovre
> 
> nsb  pDMhA yz_onnoep:2 .21612 1s44u ppplayg evsc,c  LnIoFOt  bfaotuncdh,: u3s1i
> edPuEmmRyC PrUeg:u lEamtbeodrd
>  8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>   DMA zone: 2048 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 262144 pages, LIFO batch:31
> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Booting Linux on physical CPU 0x0
> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> Machine model: CompuLab SBC-iMX7
> bootconsole [earlycon0] enabled
> cma: CMA: reserved 320 MiB at ac000000
> Memory policy: Data cache writealloc
> On node 0 totalpages: 262144
> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> [00000000] *pgd=00000000
>   DMA zone: 2048 pages used for memmap
> 



From m.szyprowski at samsung.com  Thu Feb 18 06:12:47 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 18 Feb 2016 15:12:47 +0100
Subject: [PATCH v2 00/13] SYSMMU driver update and support for Exynos 5433
Message-ID: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>

Hello,

This patchset updates Exynos SYSMMU (IOMMU) driver to make use of the
new features in the IOMMU core (support for IOMMU_DOMAIN_DMA) and adds
support for SYSMMU v5 controllers, which are available in Samsung Exynos
5433 SoCs. The driver has been also updated to compile and work on ARM64
architecture.

Best regards
Marek Szyprowski
Samsung R&D Institute Poland

Changelog:
v2:
- added support for multiple calls of device_attach (without detach),
  needed for default domain handling in iommu core (patch no 13), more
  information in the following thread:
  https://lists.linaro.org/pipermail/linaro-mm-sig/2016-February/004625.html
- fixed support for SYSMMU controllers with bogus version register value
  (patch no 9)

v1: http://www.spinics.net/lists/arm-kernel/msg483531.html
- initial version

Patch summary:

Marek Szyprowski (13):
  iommu: exynos: rework iommu group initialization
  iommu: exynos: add support for IOMMU_DOMAIN_DMA domain type
  iommu: exynos: remove ARM-specific cache flush interface
  iommu: exynos: simplify master clock operations
  iommu: exynos: refactor code (no direct register access)
  iommu: exynos: refactor fault handling code
  iommu: exynos: refactor init config code
  iommu: exynos: unify code for fldp cache invalidation
  iommu: exynos: add support for SYSMMU controller with bogus version
    reg
  iommu: exynos: update device tree documentation
  iommu: exynos: add support for v5 SYSMMU
  iommu: exynos: add Maintainers entry for Exynos SYSMMU driver
  iommu: exynos: support multiple attach_device calls

 .../devicetree/bindings/iommu/samsung,sysmmu.txt   |  22 +-
 MAINTAINERS                                        |   6 +
 drivers/iommu/Kconfig                              |   2 +-
 drivers/iommu/exynos-iommu.c                       | 598 ++++++++++++---------
 4 files changed, 372 insertions(+), 256 deletions(-)

-- 
1.9.2



From m.szyprowski at samsung.com  Thu Feb 18 06:12:48 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 18 Feb 2016 15:12:48 +0100
Subject: [PATCH v2 01/13] iommu: exynos: rework iommu group initialization
In-Reply-To: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
References: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455804780-9616-2-git-send-email-m.szyprowski@samsung.com>

This patch replaces custom code in add_device implementation with
iommu_group_get_for_dev() call and provides the needed callback.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 27 ++++++++++++++++-----------
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 97c41b8ab5d9..4fc079073c86 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1114,28 +1114,32 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct iommu_domain *iommu_domain,
 	return phys;
 }
 
+static struct iommu_group *get_device_iommu_group(struct device *dev)
+{
+	struct iommu_group *group;
+
+	group = iommu_group_get(dev);
+	if (!group)
+		group = iommu_group_alloc();
+
+	return group;
+}
+
 static int exynos_iommu_add_device(struct device *dev)
 {
 	struct iommu_group *group;
-	int ret;
 
 	if (!has_sysmmu(dev))
 		return -ENODEV;
 
-	group = iommu_group_get(dev);
+	group = iommu_group_get_for_dev(dev);
 
-	if (!group) {
-		group = iommu_group_alloc();
-		if (IS_ERR(group)) {
-			dev_err(dev, "Failed to allocate IOMMU group\n");
-			return PTR_ERR(group);
-		}
-	}
+	if (IS_ERR(group))
+		return PTR_ERR(group);
 
-	ret = iommu_group_add_device(group, dev);
 	iommu_group_put(group);
 
-	return ret;
+	return 0;
 }
 
 static void exynos_iommu_remove_device(struct device *dev)
@@ -1182,6 +1186,7 @@ static struct iommu_ops exynos_iommu_ops = {
 	.unmap = exynos_iommu_unmap,
 	.map_sg = default_iommu_map_sg,
 	.iova_to_phys = exynos_iommu_iova_to_phys,
+	.device_group = get_device_iommu_group,
 	.add_device = exynos_iommu_add_device,
 	.remove_device = exynos_iommu_remove_device,
 	.pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
-- 
1.9.2



From m.szyprowski at samsung.com  Thu Feb 18 06:12:49 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 18 Feb 2016 15:12:49 +0100
Subject: [PATCH v2 02/13] iommu: exynos: add support for IOMMU_DOMAIN_DMA
 domain type
In-Reply-To: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
References: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455804780-9616-3-git-send-email-m.szyprowski@samsung.com>

This patch adds support for DMA domain type. Such domain have DMA cookie
prepared and can be used by generic DMA-IOMMU glue layer.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 4fc079073c86..595e0da55db4 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -25,9 +25,9 @@
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/slab.h>
+#include <linux/dma-iommu.h>
 
 #include <asm/cacheflush.h>
-#include <asm/dma-iommu.h>
 #include <asm/pgtable.h>
 
 typedef u32 sysmmu_iova_t;
@@ -662,16 +662,21 @@ static struct iommu_domain *exynos_iommu_domain_alloc(unsigned type)
 	struct exynos_iommu_domain *domain;
 	int i;
 
-	if (type != IOMMU_DOMAIN_UNMANAGED)
-		return NULL;
 
 	domain = kzalloc(sizeof(*domain), GFP_KERNEL);
 	if (!domain)
 		return NULL;
 
+	if (type == IOMMU_DOMAIN_DMA) {
+		if (iommu_get_dma_cookie(&domain->domain) != 0)
+			goto err_pgtable;
+	} else if (type != IOMMU_DOMAIN_UNMANAGED) {
+		goto err_pgtable;
+	}
+
 	domain->pgtable = (sysmmu_pte_t *)__get_free_pages(GFP_KERNEL, 2);
 	if (!domain->pgtable)
-		goto err_pgtable;
+		goto err_dma_cookie;
 
 	domain->lv2entcnt = (short *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 1);
 	if (!domain->lv2entcnt)
@@ -703,6 +708,9 @@ static struct iommu_domain *exynos_iommu_domain_alloc(unsigned type)
 
 err_counter:
 	free_pages((unsigned long)domain->pgtable, 2);
+err_dma_cookie:
+	if (type == IOMMU_DOMAIN_DMA)
+		iommu_put_dma_cookie(&domain->domain);
 err_pgtable:
 	kfree(domain);
 	return NULL;
@@ -727,6 +735,9 @@ static void exynos_iommu_domain_free(struct iommu_domain *iommu_domain)
 
 	spin_unlock_irqrestore(&domain->lock, flags);
 
+	if (iommu_domain->type == IOMMU_DOMAIN_DMA)
+		iommu_put_dma_cookie(iommu_domain);
+
 	for (i = 0; i < NUM_LV1ENTRIES; i++)
 		if (lv1ent_page(domain->pgtable + i))
 			kmem_cache_free(lv2table_kmem_cache,
-- 
1.9.2



From m.szyprowski at samsung.com  Thu Feb 18 06:12:55 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 18 Feb 2016 15:12:55 +0100
Subject: [PATCH v2 08/13] iommu: exynos: unify code for fldp cache invalidation
In-Reply-To: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
References: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455804780-9616-9-git-send-email-m.szyprowski@samsung.com>

This patch simplifies the code for handling of flpdcache invalidation.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 15787a177a16..e42a76cc9674 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -440,13 +440,6 @@ static int __sysmmu_enable(struct sysmmu_drvdata *data, phys_addr_t pgtable,
 	return ret;
 }
 
-static void __sysmmu_tlb_invalidate_flpdcache(struct sysmmu_drvdata *data,
-					      sysmmu_iova_t iova)
-{
-	if (data->version == MAKE_MMU_VER(3, 3))
-		__raw_writel(iova | 0x1, data->sfrbase + REG_MMU_FLUSH_ENTRY);
-}
-
 static void sysmmu_tlb_invalidate_flpdcache(struct sysmmu_drvdata *data,
 					    sysmmu_iova_t iova)
 {
@@ -455,8 +448,10 @@ static void sysmmu_tlb_invalidate_flpdcache(struct sysmmu_drvdata *data,
 	clk_enable(data->clk_master);
 
 	spin_lock_irqsave(&data->lock, flags);
-	if (is_sysmmu_active(data))
-		__sysmmu_tlb_invalidate_flpdcache(data, iova);
+	if (is_sysmmu_active(data)) {
+		if (data->version >= MAKE_MMU_VER(3, 3))
+			__sysmmu_tlb_invalidate_entry(data, iova, 1);
+	}
 	spin_unlock_irqrestore(&data->lock, flags);
 
 	clk_disable(data->clk_master);
-- 
1.9.2



From m.szyprowski at samsung.com  Thu Feb 18 06:12:52 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 18 Feb 2016 15:12:52 +0100
Subject: [PATCH v2 05/13] iommu: exynos: refactor code (no direct register
 access)
In-Reply-To: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
References: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455804780-9616-6-git-send-email-m.szyprowski@samsung.com>

This patch changes some internal functions to have access to the state of
sysmmu device instead of having only it's registers. This will make the
code ready for future extensions.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 40 +++++++++++++++++++---------------------
 1 file changed, 19 insertions(+), 21 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index bf6b826b1d8b..4275222cead3 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -254,50 +254,49 @@ static bool is_sysmmu_active(struct sysmmu_drvdata *data)
 	return data->activations > 0;
 }
 
-static void sysmmu_unblock(void __iomem *sfrbase)
+static void sysmmu_unblock(struct sysmmu_drvdata *data)
 {
-	__raw_writel(CTRL_ENABLE, sfrbase + REG_MMU_CTRL);
+	__raw_writel(CTRL_ENABLE, data->sfrbase + REG_MMU_CTRL);
 }
 
-static bool sysmmu_block(void __iomem *sfrbase)
+static bool sysmmu_block(struct sysmmu_drvdata *data)
 {
 	int i = 120;
 
-	__raw_writel(CTRL_BLOCK, sfrbase + REG_MMU_CTRL);
-	while ((i > 0) && !(__raw_readl(sfrbase + REG_MMU_STATUS) & 1))
+	__raw_writel(CTRL_BLOCK, data->sfrbase + REG_MMU_CTRL);
+	while ((i > 0) && !(__raw_readl(data->sfrbase + REG_MMU_STATUS) & 1))
 		--i;
 
-	if (!(__raw_readl(sfrbase + REG_MMU_STATUS) & 1)) {
-		sysmmu_unblock(sfrbase);
+	if (!(__raw_readl(data->sfrbase + REG_MMU_STATUS) & 1)) {
+		sysmmu_unblock(data);
 		return false;
 	}
 
 	return true;
 }
 
-static void __sysmmu_tlb_invalidate(void __iomem *sfrbase)
+static void __sysmmu_tlb_invalidate(struct sysmmu_drvdata *data)
 {
-	__raw_writel(0x1, sfrbase + REG_MMU_FLUSH);
+	__raw_writel(0x1, data->sfrbase + REG_MMU_FLUSH);
 }
 
-static void __sysmmu_tlb_invalidate_entry(void __iomem *sfrbase,
+static void __sysmmu_tlb_invalidate_entry(struct sysmmu_drvdata *data,
 				sysmmu_iova_t iova, unsigned int num_inv)
 {
 	unsigned int i;
 
 	for (i = 0; i < num_inv; i++) {
 		__raw_writel((iova & SPAGE_MASK) | 1,
-				sfrbase + REG_MMU_FLUSH_ENTRY);
+				data->sfrbase + REG_MMU_FLUSH_ENTRY);
 		iova += SPAGE_SIZE;
 	}
 }
 
-static void __sysmmu_set_ptbase(void __iomem *sfrbase,
-				       phys_addr_t pgd)
+static void __sysmmu_set_ptbase(struct sysmmu_drvdata *data, phys_addr_t pgd)
 {
-	__raw_writel(pgd, sfrbase + REG_PT_BASE_ADDR);
+	__raw_writel(pgd, data->sfrbase + REG_PT_BASE_ADDR);
 
-	__sysmmu_tlb_invalidate(sfrbase);
+	__sysmmu_tlb_invalidate(data);
 }
 
 static void show_fault_information(const char *name,
@@ -363,7 +362,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 
 	__raw_writel(1 << itype, data->sfrbase + REG_INT_CLEAR);
 
-	sysmmu_unblock(data->sfrbase);
+	sysmmu_unblock(data);
 
 	clk_disable(data->clk_master);
 
@@ -440,7 +439,7 @@ static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
 
 	__sysmmu_init_config(data);
 
-	__sysmmu_set_ptbase(data->sfrbase, data->pgtable);
+	__sysmmu_set_ptbase(data, data->pgtable);
 
 	__raw_writel(CTRL_ENABLE, data->sfrbase + REG_MMU_CTRL);
 
@@ -521,10 +520,9 @@ static void sysmmu_tlb_invalidate_entry(struct sysmmu_drvdata *data,
 		if (MMU_MAJ_VER(data->version) == 2)
 			num_inv = min_t(unsigned int, size / PAGE_SIZE, 64);
 
-		if (sysmmu_block(data->sfrbase)) {
-			__sysmmu_tlb_invalidate_entry(
-				data->sfrbase, iova, num_inv);
-			sysmmu_unblock(data->sfrbase);
+		if (sysmmu_block(data)) {
+			__sysmmu_tlb_invalidate_entry(data, iova, num_inv);
+			sysmmu_unblock(data);
 		}
 		clk_disable(data->clk_master);
 	} else {
-- 
1.9.2



From m.szyprowski at samsung.com  Thu Feb 18 06:12:51 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 18 Feb 2016 15:12:51 +0100
Subject: [PATCH v2 04/13] iommu: exynos: simplify master clock operations
In-Reply-To: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
References: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455804780-9616-5-git-send-email-m.szyprowski@samsung.com>

All clock API function can be called on NULL clock, so simplify code avoid
checking of master clock presence.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 32 ++++++++++++--------------------
 1 file changed, 12 insertions(+), 20 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 8c8a7f7968d1..bf6b826b1d8b 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -333,8 +333,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 
 	spin_lock(&data->lock);
 
-	if (!IS_ERR(data->clk_master))
-		clk_enable(data->clk_master);
+	clk_enable(data->clk_master);
 
 	itype = (enum exynos_sysmmu_inttype)
 		__ffs(__raw_readl(data->sfrbase + REG_INT_STATUS));
@@ -366,8 +365,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 
 	sysmmu_unblock(data->sfrbase);
 
-	if (!IS_ERR(data->clk_master))
-		clk_disable(data->clk_master);
+	clk_disable(data->clk_master);
 
 	spin_unlock(&data->lock);
 
@@ -376,15 +374,13 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 
 static void __sysmmu_disable_nocount(struct sysmmu_drvdata *data)
 {
-	if (!IS_ERR(data->clk_master))
-		clk_enable(data->clk_master);
+	clk_enable(data->clk_master);
 
 	__raw_writel(CTRL_DISABLE, data->sfrbase + REG_MMU_CTRL);
 	__raw_writel(0, data->sfrbase + REG_MMU_CFG);
 
 	clk_disable(data->clk);
-	if (!IS_ERR(data->clk_master))
-		clk_disable(data->clk_master);
+	clk_disable(data->clk_master);
 }
 
 static bool __sysmmu_disable(struct sysmmu_drvdata *data)
@@ -437,8 +433,7 @@ static void __sysmmu_init_config(struct sysmmu_drvdata *data)
 
 static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
 {
-	if (!IS_ERR(data->clk_master))
-		clk_enable(data->clk_master);
+	clk_enable(data->clk_master);
 	clk_enable(data->clk);
 
 	__raw_writel(CTRL_BLOCK, data->sfrbase + REG_MMU_CTRL);
@@ -449,8 +444,7 @@ static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
 
 	__raw_writel(CTRL_ENABLE, data->sfrbase + REG_MMU_CTRL);
 
-	if (!IS_ERR(data->clk_master))
-		clk_disable(data->clk_master);
+	clk_disable(data->clk_master);
 }
 
 static int __sysmmu_enable(struct sysmmu_drvdata *data, phys_addr_t pgtable,
@@ -493,16 +487,14 @@ static void sysmmu_tlb_invalidate_flpdcache(struct sysmmu_drvdata *data,
 {
 	unsigned long flags;
 
-	if (!IS_ERR(data->clk_master))
-		clk_enable(data->clk_master);
+	clk_enable(data->clk_master);
 
 	spin_lock_irqsave(&data->lock, flags);
 	if (is_sysmmu_active(data))
 		__sysmmu_tlb_invalidate_flpdcache(data, iova);
 	spin_unlock_irqrestore(&data->lock, flags);
 
-	if (!IS_ERR(data->clk_master))
-		clk_disable(data->clk_master);
+	clk_disable(data->clk_master);
 }
 
 static void sysmmu_tlb_invalidate_entry(struct sysmmu_drvdata *data,
@@ -514,8 +506,7 @@ static void sysmmu_tlb_invalidate_entry(struct sysmmu_drvdata *data,
 	if (is_sysmmu_active(data)) {
 		unsigned int num_inv = 1;
 
-		if (!IS_ERR(data->clk_master))
-			clk_enable(data->clk_master);
+		clk_enable(data->clk_master);
 
 		/*
 		 * L2TLB invalidation required
@@ -535,8 +526,7 @@ static void sysmmu_tlb_invalidate_entry(struct sysmmu_drvdata *data,
 				data->sfrbase, iova, num_inv);
 			sysmmu_unblock(data->sfrbase);
 		}
-		if (!IS_ERR(data->clk_master))
-			clk_disable(data->clk_master);
+		clk_disable(data->clk_master);
 	} else {
 		dev_dbg(data->master,
 			"disabled. Skipping TLB invalidation @ %#x\n", iova);
@@ -593,6 +583,8 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 			dev_err(dev, "Failed to prepare master's clk\n");
 			return ret;
 		}
+	} else {
+		data->clk_master = NULL;
 	}
 
 	data->sysmmu = dev;
-- 
1.9.2



From m.szyprowski at samsung.com  Thu Feb 18 06:12:57 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 18 Feb 2016 15:12:57 +0100
Subject: [PATCH v2 10/13] iommu: exynos: update device tree documentation
In-Reply-To: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
References: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455804780-9616-11-git-send-email-m.szyprowski@samsung.com>

Exynos SYSMMU bindings documentation was merged before generic IOMMU
binding have been introduced. This patch updates documentation to match
current state.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 .../devicetree/bindings/iommu/samsung,sysmmu.txt      | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
index bc620fe32a70..f61ca25ca136 100644
--- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
+++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
@@ -23,28 +23,23 @@ MMUs.
   for window 1, 2 and 3.
 * M2M Scalers and G2D in Exynos5420 has one System MMU on the read channel and
   the other System MMU on the write channel.
-The drivers must consider how to handle those System MMUs. One of the idea is
-to implement child devices or sub-devices which are the client devices of the
-System MMU.
 
-Note:
-The current DT binding for the Exynos System MMU is incomplete.
-The following properties can be removed or changed, if found incompatible with
-the "Generic IOMMU Binding" support for attaching devices to the IOMMU.
+For information on assigning System MMU controller to its peripheral devices,
+see generic IOMMU bindings.
 
 Required properties:
 - compatible: Should be "samsung,exynos-sysmmu"
 - reg: A tuple of base address and size of System MMU registers.
+- #iommu-cells: Should be <0>.
 - interrupt-parent: The phandle of the interrupt controller of System MMU
 - interrupts: An interrupt specifier for interrupt signal of System MMU,
 	      according to the format defined by a particular interrupt
 	      controller.
 - clock-names: Should be "sysmmu" if the System MMU is needed to gate its clock.
 	       Optional "master" if the clock to the System MMU is gated by
-	       another gate clock other than "sysmmu".
-	       Exynos4 SoCs, there needs no "master" clock.
-	       Exynos5 SoCs, some System MMUs must have "master" clocks.
-- clocks: Required if the System MMU is needed to gate its clock.
+	       another gate clock other than "sysmmu" (usually main gate clock
+	       of peripheral device this SYSMMU belongs to).
+- clocks: Phandles for respective clocks described by clock-names.
 - power-domains: Required if the System MMU is needed to gate its power.
 	  Please refer to the following document:
 	  Documentation/devicetree/bindings/power/pd-samsung.txt
@@ -57,6 +52,7 @@ Examples:
 		power-domains = <&pd_gsc>;
 		clocks = <&clock CLK_GSCL0>;
 		clock-names = "gscl";
+		iommus = <&sysmmu_gsc0>;
 	};
 
 	sysmmu_gsc0: sysmmu at 13E80000 {
@@ -67,4 +63,5 @@ Examples:
 		clock-names = "sysmmu", "master";
 		clocks = <&clock CLK_SMMU_GSCL0>, <&clock CLK_GSCL0>;
 		power-domains = <&pd_gsc>;
+		#iommu-cells = <0>;
 	};
-- 
1.9.2



From m.szyprowski at samsung.com  Thu Feb 18 06:12:50 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 18 Feb 2016 15:12:50 +0100
Subject: [PATCH v2 03/13] iommu: exynos: remove ARM-specific cache flush
 interface
In-Reply-To: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
References: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455804780-9616-4-git-send-email-m.szyprowski@samsung.com>

This patch replaces custom ARM-specific code for performing CPU cache flush
operations with generic code based on DMA-mapping. Domain managing code
is independent of particular SYSMMU device, so the first registered SYSMMU
device is used for DMA-mapping calls. This simplification works fine
because all SYSMMU controllers are in the same address space (where
DMA address equals physical address) and the DMA-mapping calls are done
mainly to flush CPU cache to make changes visible to SYSMMU controllers.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 74 +++++++++++++++++++++++++++++---------------
 1 file changed, 49 insertions(+), 25 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 595e0da55db4..8c8a7f7968d1 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -27,9 +27,6 @@
 #include <linux/slab.h>
 #include <linux/dma-iommu.h>
 
-#include <asm/cacheflush.h>
-#include <asm/pgtable.h>
-
 typedef u32 sysmmu_iova_t;
 typedef u32 sysmmu_pte_t;
 
@@ -83,6 +80,7 @@ static u32 lv2ent_offset(sysmmu_iova_t iova)
 	return (iova >> SPAGE_ORDER) & (NUM_LV2ENTRIES - 1);
 }
 
+#define LV1TABLE_SIZE (NUM_LV1ENTRIES * sizeof(sysmmu_pte_t))
 #define LV2TABLE_SIZE (NUM_LV2ENTRIES * sizeof(sysmmu_pte_t))
 
 #define SPAGES_PER_LPAGE (LPAGE_SIZE / SPAGE_SIZE)
@@ -134,6 +132,7 @@ static u32 lv2ent_offset(sysmmu_iova_t iova)
 
 #define has_sysmmu(dev)		(dev->archdata.iommu != NULL)
 
+static struct device *dma_dev;
 static struct kmem_cache *lv2table_kmem_cache;
 static sysmmu_pte_t *zero_lv2_table;
 #define ZERO_LV2LINK mk_lv1ent_page(virt_to_phys(zero_lv2_table))
@@ -650,16 +649,19 @@ static struct platform_driver exynos_sysmmu_driver __refdata = {
 	}
 };
 
-static inline void pgtable_flush(void *vastart, void *vaend)
+static inline void update_pte(sysmmu_pte_t *ent, sysmmu_pte_t val)
 {
-	dmac_flush_range(vastart, vaend);
-	outer_flush_range(virt_to_phys(vastart),
-				virt_to_phys(vaend));
+	dma_sync_single_for_cpu(dma_dev, virt_to_phys(ent), sizeof(*ent),
+				DMA_TO_DEVICE);
+	*ent = val;
+	dma_sync_single_for_device(dma_dev, virt_to_phys(ent), sizeof(*ent),
+				   DMA_TO_DEVICE);
 }
 
 static struct iommu_domain *exynos_iommu_domain_alloc(unsigned type)
 {
 	struct exynos_iommu_domain *domain;
+	dma_addr_t handle;
 	int i;
 
 
@@ -694,7 +696,10 @@ static struct iommu_domain *exynos_iommu_domain_alloc(unsigned type)
 		domain->pgtable[i + 7] = ZERO_LV2LINK;
 	}
 
-	pgtable_flush(domain->pgtable, domain->pgtable + NUM_LV1ENTRIES);
+	handle = dma_map_single(dma_dev, domain->pgtable, LV1TABLE_SIZE,
+				DMA_TO_DEVICE);
+	/* For mapping page table entries we rely on dma == phys */
+	BUG_ON(handle != virt_to_phys(domain->pgtable));
 
 	spin_lock_init(&domain->lock);
 	spin_lock_init(&domain->pgtablelock);
@@ -738,10 +743,18 @@ static void exynos_iommu_domain_free(struct iommu_domain *iommu_domain)
 	if (iommu_domain->type == IOMMU_DOMAIN_DMA)
 		iommu_put_dma_cookie(iommu_domain);
 
+	dma_unmap_single(dma_dev, virt_to_phys(domain->pgtable), LV1TABLE_SIZE,
+			 DMA_TO_DEVICE);
+
 	for (i = 0; i < NUM_LV1ENTRIES; i++)
-		if (lv1ent_page(domain->pgtable + i))
+		if (lv1ent_page(domain->pgtable + i)) {
+			phys_addr_t base = lv2table_base(domain->pgtable + i);
+
+			dma_unmap_single(dma_dev, base, LV2TABLE_SIZE,
+					 DMA_TO_DEVICE);
 			kmem_cache_free(lv2table_kmem_cache,
-				phys_to_virt(lv2table_base(domain->pgtable + i)));
+					phys_to_virt(base));
+		}
 
 	free_pages((unsigned long)domain->pgtable, 2);
 	free_pages((unsigned long)domain->lv2entcnt, 1);
@@ -834,11 +847,10 @@ static sysmmu_pte_t *alloc_lv2entry(struct exynos_iommu_domain *domain,
 		if (!pent)
 			return ERR_PTR(-ENOMEM);
 
-		*sent = mk_lv1ent_page(virt_to_phys(pent));
+		update_pte(sent, mk_lv1ent_page(virt_to_phys(pent)));
 		kmemleak_ignore(pent);
 		*pgcounter = NUM_LV2ENTRIES;
-		pgtable_flush(pent, pent + NUM_LV2ENTRIES);
-		pgtable_flush(sent, sent + 1);
+		dma_map_single(dma_dev, pent, LV2TABLE_SIZE, DMA_TO_DEVICE);
 
 		/*
 		 * If pre-fetched SLPD is a faulty SLPD in zero_l2_table,
@@ -891,9 +903,7 @@ static int lv1set_section(struct exynos_iommu_domain *domain,
 		*pgcnt = 0;
 	}
 
-	*sent = mk_lv1ent_sect(paddr);
-
-	pgtable_flush(sent, sent + 1);
+	update_pte(sent, mk_lv1ent_sect(paddr));
 
 	spin_lock(&domain->lock);
 	if (lv1ent_page_zero(sent)) {
@@ -917,12 +927,15 @@ static int lv2set_page(sysmmu_pte_t *pent, phys_addr_t paddr, size_t size,
 		if (WARN_ON(!lv2ent_fault(pent)))
 			return -EADDRINUSE;
 
-		*pent = mk_lv2ent_spage(paddr);
-		pgtable_flush(pent, pent + 1);
+		update_pte(pent, mk_lv2ent_spage(paddr));
 		*pgcnt -= 1;
 	} else { /* size == LPAGE_SIZE */
 		int i;
+		dma_addr_t pent_base = virt_to_phys(pent);
 
+		dma_sync_single_for_cpu(dma_dev, pent_base,
+					sizeof(*pent) * SPAGES_PER_LPAGE,
+					DMA_TO_DEVICE);
 		for (i = 0; i < SPAGES_PER_LPAGE; i++, pent++) {
 			if (WARN_ON(!lv2ent_fault(pent))) {
 				if (i > 0)
@@ -932,7 +945,9 @@ static int lv2set_page(sysmmu_pte_t *pent, phys_addr_t paddr, size_t size,
 
 			*pent = mk_lv2ent_lpage(paddr);
 		}
-		pgtable_flush(pent - SPAGES_PER_LPAGE, pent);
+		dma_sync_single_for_device(dma_dev, pent_base,
+					   sizeof(*pent) * SPAGES_PER_LPAGE,
+					   DMA_TO_DEVICE);
 		*pgcnt -= SPAGES_PER_LPAGE;
 	}
 
@@ -1042,8 +1057,7 @@ static size_t exynos_iommu_unmap(struct iommu_domain *iommu_domain,
 		}
 
 		/* workaround for h/w bug in System MMU v3.3 */
-		*ent = ZERO_LV2LINK;
-		pgtable_flush(ent, ent + 1);
+		update_pte(ent, ZERO_LV2LINK);
 		size = SECT_SIZE;
 		goto done;
 	}
@@ -1064,9 +1078,8 @@ static size_t exynos_iommu_unmap(struct iommu_domain *iommu_domain,
 	}
 
 	if (lv2ent_small(ent)) {
-		*ent = 0;
+		update_pte(ent, 0);
 		size = SPAGE_SIZE;
-		pgtable_flush(ent, ent + 1);
 		domain->lv2entcnt[lv1ent_offset(iova)] += 1;
 		goto done;
 	}
@@ -1077,9 +1090,13 @@ static size_t exynos_iommu_unmap(struct iommu_domain *iommu_domain,
 		goto err;
 	}
 
+	dma_sync_single_for_cpu(dma_dev, virt_to_phys(ent),
+				sizeof(*ent) * SPAGES_PER_LPAGE,
+				DMA_TO_DEVICE);
 	memset(ent, 0, sizeof(*ent) * SPAGES_PER_LPAGE);
-	pgtable_flush(ent, ent + SPAGES_PER_LPAGE);
-
+	dma_sync_single_for_device(dma_dev, virt_to_phys(ent),
+				   sizeof(*ent) * SPAGES_PER_LPAGE,
+				   DMA_TO_DEVICE);
 	size = LPAGE_SIZE;
 	domain->lv2entcnt[lv1ent_offset(iova)] += SPAGES_PER_LPAGE;
 done:
@@ -1261,6 +1278,13 @@ static int __init exynos_iommu_of_setup(struct device_node *np)
 	if (IS_ERR(pdev))
 		return PTR_ERR(pdev);
 
+	/*
+	 * use the first registered sysmmu device for performing
+	 * dma mapping operations on iommu page tables (cpu cache flush)
+	 */
+	if (!dma_dev)
+		dma_dev = &pdev->dev;
+
 	of_iommu_set_ops(np, &exynos_iommu_ops);
 	return 0;
 }
-- 
1.9.2



From m.szyprowski at samsung.com  Thu Feb 18 06:12:59 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 18 Feb 2016 15:12:59 +0100
Subject: [PATCH v2 12/13] iommu: exynos: add Maintainers entry for Exynos
 SYSMMU driver
In-Reply-To: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
References: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455804780-9616-13-git-send-email-m.szyprowski@samsung.com>

Add Marek Szyprowski as maintainer for Exynos IOMMU driver.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
Acked-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index cc2f753cb357..4afc061e878a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4305,6 +4305,12 @@ L:	dri-devel at lists.freedesktop.org
 S:	Maintained
 F:	drivers/gpu/drm/exynos/exynos_dp*
 
+EXYNOS SYSMMU (IOMMU) driver
+M:	Marek Szyprowski <m.szyprowski at samsung.com>
+L:	iommu at lists.linux-foundation.org
+S:	Maintained
+F:	drivers/iommu/exynos-iommu.c
+
 EXYNOS MIPI DISPLAY DRIVERS
 M:	Inki Dae <inki.dae at samsung.com>
 M:	Donghwa Lee <dh09.lee at samsung.com>
-- 
1.9.2



From m.szyprowski at samsung.com  Thu Feb 18 06:12:53 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 18 Feb 2016 15:12:53 +0100
Subject: [PATCH v2 06/13] iommu: exynos: refactor fault handling code
In-Reply-To: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
References: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455804780-9616-7-git-send-email-m.szyprowski@samsung.com>

This patch provides a new implementation for page fault handing code. The
new implementation is ready for future extensions. No functional changes
have been made.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 109 ++++++++++++++++---------------------------
 1 file changed, 41 insertions(+), 68 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 4275222cead3..3a577a473f3c 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -148,40 +148,25 @@ static sysmmu_pte_t *page_entry(sysmmu_pte_t *sent, sysmmu_iova_t iova)
 				lv2table_base(sent)) + lv2ent_offset(iova);
 }
 
-enum exynos_sysmmu_inttype {
-	SYSMMU_PAGEFAULT,
-	SYSMMU_AR_MULTIHIT,
-	SYSMMU_AW_MULTIHIT,
-	SYSMMU_BUSERROR,
-	SYSMMU_AR_SECURITY,
-	SYSMMU_AR_ACCESS,
-	SYSMMU_AW_SECURITY,
-	SYSMMU_AW_PROTECTION, /* 7 */
-	SYSMMU_FAULT_UNKNOWN,
-	SYSMMU_FAULTS_NUM
-};
-
-static unsigned short fault_reg_offset[SYSMMU_FAULTS_NUM] = {
-	REG_PAGE_FAULT_ADDR,
-	REG_AR_FAULT_ADDR,
-	REG_AW_FAULT_ADDR,
-	REG_DEFAULT_SLAVE_ADDR,
-	REG_AR_FAULT_ADDR,
-	REG_AR_FAULT_ADDR,
-	REG_AW_FAULT_ADDR,
-	REG_AW_FAULT_ADDR
+/*
+ * IOMMU fault information register
+ */
+struct sysmmu_fault_info {
+	unsigned int bit;	/* bit number in STATUS register */
+	unsigned short addr_reg; /* register to read VA fault address */
+	const char *name;	/* human readable fault name */
+	unsigned int type;	/* fault type for report_iommu_fault */
 };
 
-static char *sysmmu_fault_name[SYSMMU_FAULTS_NUM] = {
-	"PAGE FAULT",
-	"AR MULTI-HIT FAULT",
-	"AW MULTI-HIT FAULT",
-	"BUS ERROR",
-	"AR SECURITY PROTECTION FAULT",
-	"AR ACCESS PROTECTION FAULT",
-	"AW SECURITY PROTECTION FAULT",
-	"AW ACCESS PROTECTION FAULT",
-	"UNKNOWN FAULT"
+static const struct sysmmu_fault_info sysmmu_faults[] = {
+	{ 0, REG_PAGE_FAULT_ADDR, "PAGE", IOMMU_FAULT_READ },
+	{ 1, REG_AR_FAULT_ADDR, "AR MULTI-HIT", IOMMU_FAULT_READ },
+	{ 2, REG_AW_FAULT_ADDR, "AW MULTI-HIT", IOMMU_FAULT_WRITE },
+	{ 3, REG_DEFAULT_SLAVE_ADDR, "BUS ERROR", IOMMU_FAULT_READ },
+	{ 4, REG_AR_FAULT_ADDR, "AR SECURITY PROTECTION", IOMMU_FAULT_READ },
+	{ 5, REG_AR_FAULT_ADDR, "AR ACCESS PROTECTION", IOMMU_FAULT_READ },
+	{ 6, REG_AW_FAULT_ADDR, "AW SECURITY PROTECTION", IOMMU_FAULT_WRITE },
+	{ 7, REG_AW_FAULT_ADDR, "AW ACCESS PROTECTION", IOMMU_FAULT_WRITE },
 };
 
 /*
@@ -299,24 +284,19 @@ static void __sysmmu_set_ptbase(struct sysmmu_drvdata *data, phys_addr_t pgd)
 	__sysmmu_tlb_invalidate(data);
 }
 
-static void show_fault_information(const char *name,
-		enum exynos_sysmmu_inttype itype,
-		phys_addr_t pgtable_base, sysmmu_iova_t fault_addr)
+static void show_fault_information(struct sysmmu_drvdata *data,
+				   const struct sysmmu_fault_info *finfo,
+				   sysmmu_iova_t fault_addr)
 {
 	sysmmu_pte_t *ent;
 
-	if ((itype >= SYSMMU_FAULTS_NUM) || (itype < SYSMMU_PAGEFAULT))
-		itype = SYSMMU_FAULT_UNKNOWN;
-
-	pr_err("%s occurred at %#x by %s(Page table base: %pa)\n",
-		sysmmu_fault_name[itype], fault_addr, name, &pgtable_base);
-
-	ent = section_entry(phys_to_virt(pgtable_base), fault_addr);
-	pr_err("\tLv1 entry: %#x\n", *ent);
-
+	dev_err(data->sysmmu, "%s FAULT occurred at %#x (page table base: %pa)\n",
+		finfo->name, fault_addr, &data->pgtable);
+	ent = section_entry(phys_to_virt(data->pgtable), fault_addr);
+	dev_err(data->sysmmu, "\tLv1 entry: %#x\n", *ent);
 	if (lv1ent_page(ent)) {
 		ent = page_entry(ent, fault_addr);
-		pr_err("\t Lv2 entry: %#x\n", *ent);
+		dev_err(data->sysmmu, "\t Lv2 entry: %#x\n", *ent);
 	}
 }
 
@@ -324,8 +304,10 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 {
 	/* SYSMMU is in blocked state when interrupt occurred. */
 	struct sysmmu_drvdata *data = dev_id;
-	enum exynos_sysmmu_inttype itype;
-	sysmmu_iova_t addr = -1;
+	const struct sysmmu_fault_info *finfo = sysmmu_faults;
+	int i, n = ARRAY_SIZE(sysmmu_faults);
+	unsigned int itype;
+	sysmmu_iova_t fault_addr = -1;
 	int ret = -ENOSYS;
 
 	WARN_ON(!is_sysmmu_active(data));
@@ -334,29 +316,20 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 
 	clk_enable(data->clk_master);
 
-	itype = (enum exynos_sysmmu_inttype)
-		__ffs(__raw_readl(data->sfrbase + REG_INT_STATUS));
-	if (WARN_ON(!((itype >= 0) && (itype < SYSMMU_FAULT_UNKNOWN))))
-		itype = SYSMMU_FAULT_UNKNOWN;
-	else
-		addr = __raw_readl(data->sfrbase + fault_reg_offset[itype]);
+	itype = __ffs(__raw_readl(data->sfrbase + REG_INT_STATUS));
+	for (i = 0; i < n; i++, finfo++)
+		if (finfo->bit == itype)
+			break;
+	/* unknown/unsupported fault */
+	BUG_ON(i == n);
 
-	if (itype == SYSMMU_FAULT_UNKNOWN) {
-		pr_err("%s: Fault is not occurred by System MMU '%s'!\n",
-			__func__, dev_name(data->sysmmu));
-		pr_err("%s: Please check if IRQ is correctly configured.\n",
-			__func__);
-		BUG();
-	} else {
-		unsigned int base =
-				__raw_readl(data->sfrbase + REG_PT_BASE_ADDR);
-		show_fault_information(dev_name(data->sysmmu),
-					itype, base, addr);
-		if (data->domain)
-			ret = report_iommu_fault(&data->domain->domain,
-					data->master, addr, itype);
-	}
+	/* print debug message */
+	fault_addr = __raw_readl(data->sfrbase + finfo->addr_reg);
+	show_fault_information(data, finfo, fault_addr);
 
+	if (data->domain)
+		ret = report_iommu_fault(&data->domain->domain,
+					data->master, fault_addr, finfo->type);
 	/* fault is not recovered by fault handler */
 	BUG_ON(ret != 0);
 
-- 
1.9.2



From m.szyprowski at samsung.com  Thu Feb 18 06:12:58 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 18 Feb 2016 15:12:58 +0100
Subject: [PATCH v2 11/13] iommu: exynos: add support for v5 SYSMMU
In-Reply-To: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
References: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455804780-9616-12-git-send-email-m.szyprowski@samsung.com>

This patch adds support for v5 of SYSMMU controller, found in Samsung
Exynos 5433 SoCs. The main difference of v5 is support for 36-bit physical
address space and some changes in register layout and core clocks hanging.
This patch also adds support for ARM64 architecture, which is used by
Exynos 5433 SoCs.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 .../devicetree/bindings/iommu/samsung,sysmmu.txt   |   5 +-
 drivers/iommu/Kconfig                              |   2 +-
 drivers/iommu/exynos-iommu.c                       | 187 +++++++++++++++------
 3 files changed, 143 insertions(+), 51 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
index f61ca25ca136..85f068805dd8 100644
--- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
+++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
@@ -35,9 +35,10 @@ Required properties:
 - interrupts: An interrupt specifier for interrupt signal of System MMU,
 	      according to the format defined by a particular interrupt
 	      controller.
-- clock-names: Should be "sysmmu" if the System MMU is needed to gate its clock.
+- clock-names: Should be "sysmmu" or a pair of "aclk" and "pclk" to gate
+	       SYSMMU core clocks.
 	       Optional "master" if the clock to the System MMU is gated by
-	       another gate clock other than "sysmmu" (usually main gate clock
+	       another gate clock other core  (usually main gate clock
 	       of peripheral device this SYSMMU belongs to).
 - clocks: Phandles for respective clocks described by clock-names.
 - power-domains: Required if the System MMU is needed to gate its power.
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index a1e75cba18e0..1674de1cfed0 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -243,7 +243,7 @@ config TEGRA_IOMMU_SMMU
 
 config EXYNOS_IOMMU
 	bool "Exynos IOMMU Support"
-	depends on ARCH_EXYNOS && ARM && MMU
+	depends on ARCH_EXYNOS && MMU
 	select IOMMU_API
 	select ARM_DMA_USE_IOMMU
 	help
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 8e289e2a05fb..9c8ce951158d 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -1,6 +1,5 @@
-/* linux/drivers/iommu/exynos_iommu.c
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+/*
+ * Copyright (c) 2011,2016 Samsung Electronics Co., Ltd.
  *		http://www.samsung.com
  *
  * This program is free software; you can redistribute it and/or modify
@@ -55,17 +54,25 @@ typedef u32 sysmmu_pte_t;
 #define lv2ent_small(pent) ((*(pent) & 2) == 2)
 #define lv2ent_large(pent) ((*(pent) & 3) == 1)
 
-static u32 sysmmu_page_offset(sysmmu_iova_t iova, u32 size)
-{
-	return iova & (size - 1);
-}
-
-#define section_phys(sent) (*(sent) & SECT_MASK)
-#define section_offs(iova) sysmmu_page_offset((iova), SECT_SIZE)
-#define lpage_phys(pent) (*(pent) & LPAGE_MASK)
-#define lpage_offs(iova) sysmmu_page_offset((iova), LPAGE_SIZE)
-#define spage_phys(pent) (*(pent) & SPAGE_MASK)
-#define spage_offs(iova) sysmmu_page_offset((iova), SPAGE_SIZE)
+/*
+ * v1.x - v3.x SYSMMU supports 32bit physical and 32bit virtual address spaces
+ * v5.0 introduced support for 36bit physical address space by shifting
+ * all page entry values by 4 bits.
+ * All SYSMMU controllers in the system support the address spaces of the same
+ * size, so PG_ENT_SHIFT can be initialized on first SYSMMU probe to proper
+ * value (0 or 4).
+ */
+static short PG_ENT_SHIFT = -1;
+#define SYSMMU_PG_ENT_SHIFT 0
+#define SYSMMU_V5_PG_ENT_SHIFT 4
+
+#define sect_to_phys(ent) (((phys_addr_t) ent) << PG_ENT_SHIFT)
+#define section_phys(sent) (sect_to_phys(*(sent)) & SECT_MASK)
+#define section_offs(iova) (iova & (SECT_SIZE - 1))
+#define lpage_phys(pent) (sect_to_phys(*(pent)) & LPAGE_MASK)
+#define lpage_offs(iova) (iova & (LPAGE_SIZE - 1))
+#define spage_phys(pent) (sect_to_phys(*(pent)) & SPAGE_MASK)
+#define spage_offs(iova) (iova & (SPAGE_SIZE - 1))
 
 #define NUM_LV1ENTRIES 4096
 #define NUM_LV2ENTRIES (SECT_SIZE / SPAGE_SIZE)
@@ -84,13 +91,12 @@ static u32 lv2ent_offset(sysmmu_iova_t iova)
 #define LV2TABLE_SIZE (NUM_LV2ENTRIES * sizeof(sysmmu_pte_t))
 
 #define SPAGES_PER_LPAGE (LPAGE_SIZE / SPAGE_SIZE)
+#define lv2table_base(sent) (sect_to_phys(*(sent) & 0xFFFFFFC0))
 
-#define lv2table_base(sent) (*(sent) & 0xFFFFFC00)
-
-#define mk_lv1ent_sect(pa) ((pa) | 2)
-#define mk_lv1ent_page(pa) ((pa) | 1)
-#define mk_lv2ent_lpage(pa) ((pa) | 1)
-#define mk_lv2ent_spage(pa) ((pa) | 2)
+#define mk_lv1ent_sect(pa) ((pa >> PG_ENT_SHIFT) | 2)
+#define mk_lv1ent_page(pa) ((pa >> PG_ENT_SHIFT) | 1)
+#define mk_lv2ent_lpage(pa) ((pa >> PG_ENT_SHIFT) | 1)
+#define mk_lv2ent_spage(pa) ((pa >> PG_ENT_SHIFT) | 2)
 
 #define CTRL_ENABLE	0x5
 #define CTRL_BLOCK	0x7
@@ -98,14 +104,23 @@ static u32 lv2ent_offset(sysmmu_iova_t iova)
 
 #define CFG_LRU		0x1
 #define CFG_QOS(n)	((n & 0xF) << 7)
-#define CFG_MASK	0x0150FFFF /* Selecting bit 0-15, 20, 22 and 24 */
 #define CFG_ACGEN	(1 << 24) /* System MMU 3.3 only */
 #define CFG_SYSSEL	(1 << 22) /* System MMU 3.2 only */
 #define CFG_FLPDCACHE	(1 << 20) /* System MMU 3.2+ only */
 
+/* common registers */
 #define REG_MMU_CTRL		0x000
 #define REG_MMU_CFG		0x004
 #define REG_MMU_STATUS		0x008
+#define REG_MMU_VERSION		0x034
+
+#define MMU_MAJ_VER(val)	((val) >> 7)
+#define MMU_MIN_VER(val)	((val) & 0x7F)
+#define MMU_RAW_VER(reg)	(((reg) >> 21) & ((1 << 11) - 1)) /* 11 bits */
+
+#define MAKE_MMU_VER(maj, min)	((((maj) & 0xF) << 7) | ((min) & 0x7F))
+
+/* v1.x - v3.x registers */
 #define REG_MMU_FLUSH		0x00C
 #define REG_MMU_FLUSH_ENTRY	0x010
 #define REG_PT_BASE_ADDR	0x014
@@ -117,18 +132,14 @@ static u32 lv2ent_offset(sysmmu_iova_t iova)
 #define REG_AR_FAULT_ADDR	0x02C
 #define REG_DEFAULT_SLAVE_ADDR	0x030
 
-#define REG_MMU_VERSION		0x034
-
-#define MMU_MAJ_VER(val)	((val) >> 7)
-#define MMU_MIN_VER(val)	((val) & 0x7F)
-#define MMU_RAW_VER(reg)	(((reg) >> 21) & ((1 << 11) - 1)) /* 11 bits */
-
-#define MAKE_MMU_VER(maj, min)	((((maj) & 0xF) << 7) | ((min) & 0x7F))
-
-#define REG_PB0_SADDR		0x04C
-#define REG_PB0_EADDR		0x050
-#define REG_PB1_SADDR		0x054
-#define REG_PB1_EADDR		0x058
+/* v5.x registers */
+#define REG_V5_PT_BASE_PFN	0x00C
+#define REG_V5_MMU_FLUSH_ALL	0x010
+#define REG_V5_MMU_FLUSH_ENTRY	0x014
+#define REG_V5_INT_STATUS	0x060
+#define REG_V5_INT_CLEAR	0x064
+#define REG_V5_FAULT_AR_VA	0x070
+#define REG_V5_FAULT_AW_VA	0x080
 
 #define has_sysmmu(dev)		(dev->archdata.iommu != NULL)
 
@@ -169,6 +180,19 @@ static const struct sysmmu_fault_info sysmmu_faults[] = {
 	{ 7, REG_AW_FAULT_ADDR, "AW ACCESS PROTECTION", IOMMU_FAULT_WRITE },
 };
 
+static const struct sysmmu_fault_info sysmmu_v5_faults[] = {
+	{ 0, REG_V5_FAULT_AR_VA, "AR PTW", IOMMU_FAULT_READ },
+	{ 1, REG_V5_FAULT_AR_VA, "AR PAGE", IOMMU_FAULT_READ },
+	{ 2, REG_V5_FAULT_AR_VA, "AR MULTI-HIT", IOMMU_FAULT_READ },
+	{ 3, REG_V5_FAULT_AR_VA, "AR ACCESS PROTECTION", IOMMU_FAULT_READ },
+	{ 4, REG_V5_FAULT_AR_VA, "AR SECURITY PROTECTION", IOMMU_FAULT_READ },
+	{ 16, REG_V5_FAULT_AW_VA, "AW PTW", IOMMU_FAULT_WRITE },
+	{ 17, REG_V5_FAULT_AW_VA, "AW PAGE", IOMMU_FAULT_WRITE },
+	{ 18, REG_V5_FAULT_AW_VA, "AW MULTI-HIT", IOMMU_FAULT_WRITE },
+	{ 19, REG_V5_FAULT_AW_VA, "AW ACCESS PROTECTION", IOMMU_FAULT_WRITE },
+	{ 20, REG_V5_FAULT_AW_VA, "AW SECURITY PROTECTION", IOMMU_FAULT_WRITE },
+};
+
 /*
  * This structure is attached to dev.archdata.iommu of the master device
  * on device add, contains a list of SYSMMU controllers defined by device tree,
@@ -205,6 +229,8 @@ struct sysmmu_drvdata {
 	struct device *master;		/* master device (owner) */
 	void __iomem *sfrbase;		/* our registers */
 	struct clk *clk;		/* SYSMMU's clock */
+	struct clk *aclk;		/* SYSMMU's aclk clock */
+	struct clk *pclk;		/* SYSMMU's pclk clock */
 	struct clk *clk_master;		/* master's device clock */
 	int activations;		/* number of calls to sysmmu_enable */
 	spinlock_t lock;		/* lock for modyfying state */
@@ -262,7 +288,10 @@ static bool sysmmu_block(struct sysmmu_drvdata *data)
 
 static void __sysmmu_tlb_invalidate(struct sysmmu_drvdata *data)
 {
-	__raw_writel(0x1, data->sfrbase + REG_MMU_FLUSH);
+	if (MMU_MAJ_VER(data->version) < 5)
+		__raw_writel(0x1, data->sfrbase + REG_MMU_FLUSH);
+	else
+		__raw_writel(0x1, data->sfrbase + REG_V5_MMU_FLUSH_ALL);
 }
 
 static void __sysmmu_tlb_invalidate_entry(struct sysmmu_drvdata *data,
@@ -271,15 +300,23 @@ static void __sysmmu_tlb_invalidate_entry(struct sysmmu_drvdata *data,
 	unsigned int i;
 
 	for (i = 0; i < num_inv; i++) {
-		__raw_writel((iova & SPAGE_MASK) | 1,
-				data->sfrbase + REG_MMU_FLUSH_ENTRY);
+		if (MMU_MAJ_VER(data->version) < 5)
+			__raw_writel((iova & SPAGE_MASK) | 1,
+				     data->sfrbase + REG_MMU_FLUSH_ENTRY);
+		else
+			__raw_writel((iova & SPAGE_MASK) | 1,
+				     data->sfrbase + REG_V5_MMU_FLUSH_ENTRY);
 		iova += SPAGE_SIZE;
 	}
 }
 
 static void __sysmmu_set_ptbase(struct sysmmu_drvdata *data, phys_addr_t pgd)
 {
-	__raw_writel(pgd, data->sfrbase + REG_PT_BASE_ADDR);
+	if (MMU_MAJ_VER(data->version) < 5)
+		__raw_writel(pgd, data->sfrbase + REG_PT_BASE_ADDR);
+	else
+		__raw_writel(pgd >> PAGE_SHIFT,
+			     data->sfrbase + REG_V5_PT_BASE_PFN);
 
 	__sysmmu_tlb_invalidate(data);
 }
@@ -290,6 +327,8 @@ static void __sysmmu_get_version(struct sysmmu_drvdata *data)
 
 	clk_enable(data->clk_master);
 	clk_enable(data->clk);
+	clk_enable(data->pclk);
+	clk_enable(data->aclk);
 
 	ver = __raw_readl(data->sfrbase + REG_MMU_VERSION);
 
@@ -302,6 +341,8 @@ static void __sysmmu_get_version(struct sysmmu_drvdata *data)
 	dev_dbg(data->sysmmu, "hardware version: %d.%d\n",
 		MMU_MAJ_VER(data->version), MMU_MIN_VER(data->version));
 
+	clk_disable(data->aclk);
+	clk_disable(data->pclk);
 	clk_disable(data->clk);
 	clk_disable(data->clk_master);
 }
@@ -326,19 +367,31 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 {
 	/* SYSMMU is in blocked state when interrupt occurred. */
 	struct sysmmu_drvdata *data = dev_id;
-	const struct sysmmu_fault_info *finfo = sysmmu_faults;
-	int i, n = ARRAY_SIZE(sysmmu_faults);
-	unsigned int itype;
+	const struct sysmmu_fault_info *finfo;
+	unsigned int i, n, itype;
 	sysmmu_iova_t fault_addr = -1;
+	unsigned short reg_status, reg_clear;
 	int ret = -ENOSYS;
 
 	WARN_ON(!is_sysmmu_active(data));
 
+	if (MMU_MAJ_VER(data->version) < 5) {
+		reg_status = REG_INT_STATUS;
+		reg_clear = REG_INT_CLEAR;
+		finfo = sysmmu_faults;
+		n = ARRAY_SIZE(sysmmu_faults);
+	} else {
+		reg_status = REG_V5_INT_STATUS;
+		reg_clear = REG_V5_INT_CLEAR;
+		finfo = sysmmu_v5_faults;
+		n = ARRAY_SIZE(sysmmu_v5_faults);
+	}
+
 	spin_lock(&data->lock);
 
 	clk_enable(data->clk_master);
 
-	itype = __ffs(__raw_readl(data->sfrbase + REG_INT_STATUS));
+	itype = __ffs(__raw_readl(data->sfrbase + reg_status));
 	for (i = 0; i < n; i++, finfo++)
 		if (finfo->bit == itype)
 			break;
@@ -355,7 +408,7 @@ static irqreturn_t exynos_sysmmu_irq(int irq, void *dev_id)
 	/* fault is not recovered by fault handler */
 	BUG_ON(ret != 0);
 
-	__raw_writel(1 << itype, data->sfrbase + REG_INT_CLEAR);
+	__raw_writel(1 << itype, data->sfrbase + reg_clear);
 
 	sysmmu_unblock(data);
 
@@ -373,6 +426,8 @@ static void __sysmmu_disable_nocount(struct sysmmu_drvdata *data)
 	__raw_writel(CTRL_DISABLE, data->sfrbase + REG_MMU_CTRL);
 	__raw_writel(0, data->sfrbase + REG_MMU_CFG);
 
+	clk_disable(data->aclk);
+	clk_disable(data->pclk);
 	clk_disable(data->clk);
 	clk_disable(data->clk_master);
 }
@@ -421,6 +476,8 @@ static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
 {
 	clk_enable(data->clk_master);
 	clk_enable(data->clk);
+	clk_enable(data->pclk);
+	clk_enable(data->aclk);
 
 	__raw_writel(CTRL_BLOCK, data->sfrbase + REG_MMU_CTRL);
 
@@ -544,22 +601,47 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 	}
 
 	data->clk = devm_clk_get(dev, "sysmmu");
-	if (IS_ERR(data->clk)) {
-		dev_err(dev, "Failed to get clock!\n");
-		return PTR_ERR(data->clk);
-	} else  {
+	if (!IS_ERR(data->clk)) {
 		ret = clk_prepare(data->clk);
 		if (ret) {
 			dev_err(dev, "Failed to prepare clk\n");
 			return ret;
 		}
+	} else {
+		data->clk = NULL;
+	}
+
+	data->aclk = devm_clk_get(dev, "aclk");
+	if (!IS_ERR(data->aclk)) {
+		ret = clk_prepare(data->aclk);
+		if (ret) {
+			dev_err(dev, "Failed to prepare aclk\n");
+			return ret;
+		}
+	} else {
+		data->aclk = NULL;
+	}
+
+	data->pclk = devm_clk_get(dev, "pclk");
+	if (!IS_ERR(data->pclk)) {
+		ret = clk_prepare(data->pclk);
+		if (ret) {
+			dev_err(dev, "Failed to prepare pclk\n");
+			return ret;
+		}
+	} else {
+		data->pclk = NULL;
+	}
+
+	if (!data->clk && (!data->aclk || !data->pclk)) {
+		dev_err(dev, "Failed to get device clock(s)!\n");
+		return -ENOSYS;
 	}
 
 	data->clk_master = devm_clk_get(dev, "master");
 	if (!IS_ERR(data->clk_master)) {
 		ret = clk_prepare(data->clk_master);
 		if (ret) {
-			clk_unprepare(data->clk);
 			dev_err(dev, "Failed to prepare master's clk\n");
 			return ret;
 		}
@@ -573,6 +655,13 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, data);
 
 	__sysmmu_get_version(data);
+	if (PG_ENT_SHIFT < 0) {
+		if (MMU_MAJ_VER(data->version) < 5)
+			PG_ENT_SHIFT = SYSMMU_PG_ENT_SHIFT;
+		else
+			PG_ENT_SHIFT = SYSMMU_V5_PG_ENT_SHIFT;
+	}
+
 	pm_runtime_enable(dev);
 
 	return 0;
@@ -637,6 +726,8 @@ static struct iommu_domain *exynos_iommu_domain_alloc(unsigned type)
 	dma_addr_t handle;
 	int i;
 
+	/* Check if correct PTE offsets are initialized */
+	BUG_ON(PG_ENT_SHIFT < 0 || !dma_dev);
 
 	domain = kzalloc(sizeof(*domain), GFP_KERNEL);
 	if (!domain)
@@ -816,7 +907,7 @@ static sysmmu_pte_t *alloc_lv2entry(struct exynos_iommu_domain *domain,
 		bool need_flush_flpd_cache = lv1ent_zero(sent);
 
 		pent = kmem_cache_zalloc(lv2table_kmem_cache, GFP_ATOMIC);
-		BUG_ON((unsigned int)pent & (LV2TABLE_SIZE - 1));
+		BUG_ON((phys_addr_t)pent & (LV2TABLE_SIZE - 1));
 		if (!pent)
 			return ERR_PTR(-ENOMEM);
 
-- 
1.9.2



From m.szyprowski at samsung.com  Thu Feb 18 06:12:54 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 18 Feb 2016 15:12:54 +0100
Subject: [PATCH v2 07/13] iommu: exynos: refactor init config code
In-Reply-To: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
References: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455804780-9616-8-git-send-email-m.szyprowski@samsung.com>

This patch rewrites sysmmu_init_config function to make it easier to read
and understand.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 25 +++++++++----------------
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 3a577a473f3c..15787a177a16 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -383,24 +383,17 @@ static bool __sysmmu_disable(struct sysmmu_drvdata *data)
 
 static void __sysmmu_init_config(struct sysmmu_drvdata *data)
 {
-	unsigned int cfg = CFG_LRU | CFG_QOS(15);
-	unsigned int ver;
-
-	ver = MMU_RAW_VER(__raw_readl(data->sfrbase + REG_MMU_VERSION));
-	if (MMU_MAJ_VER(ver) == 3) {
-		if (MMU_MIN_VER(ver) >= 2) {
-			cfg |= CFG_FLPDCACHE;
-			if (MMU_MIN_VER(ver) == 3) {
-				cfg |= CFG_ACGEN;
-				cfg &= ~CFG_LRU;
-			} else {
-				cfg |= CFG_SYSSEL;
-			}
-		}
-	}
+	unsigned int cfg;
+
+	data->version = MMU_RAW_VER(__raw_readl(data->sfrbase + REG_MMU_VERSION));
+	if (data->version <= MAKE_MMU_VER(3, 1))
+		cfg = CFG_LRU | CFG_QOS(15);
+	else if (data->version <= MAKE_MMU_VER(3, 2))
+		cfg = CFG_LRU | CFG_QOS(15) | CFG_FLPDCACHE | CFG_SYSSEL;
+	else
+		cfg = CFG_QOS(15) | CFG_FLPDCACHE | CFG_ACGEN;
 
 	__raw_writel(cfg, data->sfrbase + REG_MMU_CFG);
-	data->version = ver;
 }
 
 static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
-- 
1.9.2



From m.szyprowski at samsung.com  Thu Feb 18 06:13:00 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 18 Feb 2016 15:13:00 +0100
Subject: [PATCH v2 13/13] iommu: exynos: support multiple attach_device calls
In-Reply-To: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
References: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455804780-9616-14-git-send-email-m.szyprowski@samsung.com>

IOMMU core calls attach_device callback without detaching device from
the previous domain. This patch adds support for such unballanced calls.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 72 ++++++++++++++++++++++++--------------------
 1 file changed, 40 insertions(+), 32 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 9c8ce951158d..b0665042bf29 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -201,6 +201,7 @@ static const struct sysmmu_fault_info sysmmu_v5_faults[] = {
 */
 struct exynos_iommu_owner {
 	struct list_head controllers;	/* list of sysmmu_drvdata.owner_node */
+	struct iommu_domain *domain;	/* domain this device is attached */
 };
 
 /*
@@ -825,6 +826,41 @@ static void exynos_iommu_domain_free(struct iommu_domain *iommu_domain)
 	kfree(domain);
 }
 
+static void exynos_iommu_detach_device(struct iommu_domain *iommu_domain,
+				    struct device *dev)
+{
+	struct exynos_iommu_owner *owner = dev->archdata.iommu;
+	struct exynos_iommu_domain *domain = to_exynos_domain(iommu_domain);
+	phys_addr_t pagetable = virt_to_phys(domain->pgtable);
+	struct sysmmu_drvdata *data, *next;
+	unsigned long flags;
+	bool found = false;
+
+	if (!has_sysmmu(dev) || owner->domain != iommu_domain)
+		return;
+
+	spin_lock_irqsave(&domain->lock, flags);
+	list_for_each_entry_safe(data, next, &domain->clients, domain_node) {
+		if (data->master == dev) {
+			if (__sysmmu_disable(data)) {
+				data->master = NULL;
+				list_del_init(&data->domain_node);
+			}
+			pm_runtime_put(data->sysmmu);
+			found = true;
+		}
+	}
+	spin_unlock_irqrestore(&domain->lock, flags);
+
+	owner->domain = NULL;
+
+	if (found)
+		dev_dbg(dev, "%s: Detached IOMMU with pgtable %pa\n",
+					__func__, &pagetable);
+	else
+		dev_err(dev, "%s: No IOMMU is attached\n", __func__);
+}
+
 static int exynos_iommu_attach_device(struct iommu_domain *iommu_domain,
 				   struct device *dev)
 {
@@ -838,6 +874,9 @@ static int exynos_iommu_attach_device(struct iommu_domain *iommu_domain,
 	if (!has_sysmmu(dev))
 		return -ENODEV;
 
+	if (owner->domain)
+		exynos_iommu_detach_device(owner->domain, dev);
+
 	list_for_each_entry(data, &owner->controllers, owner_node) {
 		pm_runtime_get_sync(data->sysmmu);
 		ret = __sysmmu_enable(data, pagetable, domain);
@@ -856,44 +895,13 @@ static int exynos_iommu_attach_device(struct iommu_domain *iommu_domain,
 		return ret;
 	}
 
+	owner->domain = iommu_domain;
 	dev_dbg(dev, "%s: Attached IOMMU with pgtable %pa %s\n",
 		__func__, &pagetable, (ret == 0) ? "" : ", again");
 
 	return ret;
 }
 
-static void exynos_iommu_detach_device(struct iommu_domain *iommu_domain,
-				    struct device *dev)
-{
-	struct exynos_iommu_domain *domain = to_exynos_domain(iommu_domain);
-	phys_addr_t pagetable = virt_to_phys(domain->pgtable);
-	struct sysmmu_drvdata *data, *next;
-	unsigned long flags;
-	bool found = false;
-
-	if (!has_sysmmu(dev))
-		return;
-
-	spin_lock_irqsave(&domain->lock, flags);
-	list_for_each_entry_safe(data, next, &domain->clients, domain_node) {
-		if (data->master == dev) {
-			if (__sysmmu_disable(data)) {
-				data->master = NULL;
-				list_del_init(&data->domain_node);
-			}
-			pm_runtime_put(data->sysmmu);
-			found = true;
-		}
-	}
-	spin_unlock_irqrestore(&domain->lock, flags);
-
-	if (found)
-		dev_dbg(dev, "%s: Detached IOMMU with pgtable %pa\n",
-					__func__, &pagetable);
-	else
-		dev_err(dev, "%s: No IOMMU is attached\n", __func__);
-}
-
 static sysmmu_pte_t *alloc_lv2entry(struct exynos_iommu_domain *domain,
 		sysmmu_pte_t *sent, sysmmu_iova_t iova, short *pgcounter)
 {
-- 
1.9.2



From m.szyprowski at samsung.com  Thu Feb 18 06:12:56 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 18 Feb 2016 15:12:56 +0100
Subject: [PATCH v2 09/13] iommu: exynos: add support for SYSMMU controller with
 bogus version reg
In-Reply-To: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
References: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455804780-9616-10-git-send-email-m.szyprowski@samsung.com>

SYSMMU on some SoCs reports bogus values in VERSION register. Force
hardware version to 1.0 for such controllers. This patch also moves reading
version register to driver's probe() function.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/iommu/exynos-iommu.c | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index e42a76cc9674..8e289e2a05fb 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -284,6 +284,28 @@ static void __sysmmu_set_ptbase(struct sysmmu_drvdata *data, phys_addr_t pgd)
 	__sysmmu_tlb_invalidate(data);
 }
 
+static void __sysmmu_get_version(struct sysmmu_drvdata *data)
+{
+	u32 ver;
+
+	clk_enable(data->clk_master);
+	clk_enable(data->clk);
+
+	ver = __raw_readl(data->sfrbase + REG_MMU_VERSION);
+
+	/* controllers on some SoCs don't report proper version */
+	if (ver == 0x80000001u)
+		data->version = MAKE_MMU_VER(1, 0);
+	else
+		data->version = MMU_RAW_VER(ver);
+
+	dev_dbg(data->sysmmu, "hardware version: %d.%d\n",
+		MMU_MAJ_VER(data->version), MMU_MIN_VER(data->version));
+
+	clk_disable(data->clk);
+	clk_disable(data->clk_master);
+}
+
 static void show_fault_information(struct sysmmu_drvdata *data,
 				   const struct sysmmu_fault_info *finfo,
 				   sysmmu_iova_t fault_addr)
@@ -385,7 +407,6 @@ static void __sysmmu_init_config(struct sysmmu_drvdata *data)
 {
 	unsigned int cfg;
 
-	data->version = MMU_RAW_VER(__raw_readl(data->sfrbase + REG_MMU_VERSION));
 	if (data->version <= MAKE_MMU_VER(3, 1))
 		cfg = CFG_LRU | CFG_QOS(15);
 	else if (data->version <= MAKE_MMU_VER(3, 2))
@@ -551,6 +572,7 @@ static int __init exynos_sysmmu_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, data);
 
+	__sysmmu_get_version(data);
 	pm_runtime_enable(dev);
 
 	return 0;
-- 
1.9.2



From shawnguo at kernel.org  Thu Feb 18 06:14:26 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 18 Feb 2016 22:14:26 +0800
Subject: [PATCH] clk: imx: correct pwm7 clock name in driver for i.MX6UL
In-Reply-To: <20160217195725.2278.96780@quark.deferred.io>
References: <1455734900-1913-1-git-send-email-agust@denx.de>
 <CAOMZO5Cwed8uOKz6=Odu=jaaBqoNzUxm2Xv3+6TAxKGsa27Mdw@mail.gmail.com>
 <20160217195725.2278.96780@quark.deferred.io>
Message-ID: <20160218141426.GZ6756@tiger>

On Wed, Feb 17, 2016 at 11:57:25AM -0800, Michael Turquette wrote:
> Quoting Fabio Estevam (2016-02-17 10:58:13)
> > On Wed, Feb 17, 2016 at 4:48 PM, Anatolij Gustschin <agust at denx.de> wrote:
> > > Don't capitalize p in the pwm7 clock name.
> > >
> > > Signed-off-by: Anatolij Gustschin <agust at denx.de>
> > 
> > Thanks.
> > 
> > Reviewed-by: Fabio Estevam <fabio.estevam at nxp.com>
> 
> Should I apply this to clk-next or is someone (Shawn?) gathering patches
> for a pull request?

Yes, I'm collecting i.MX clock patches for a pull request that will go
to you later.

Patch applied, thanks.

Shawn


From carlo at caione.org  Thu Feb 18 06:14:45 2016
From: carlo at caione.org (Carlo Caione)
Date: Thu, 18 Feb 2016 15:14:45 +0100
Subject: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
In-Reply-To: <4158343.mkrTsd5B4G@wuerfel>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <CAOQ7t2add21t4hFtTeUBFe9aW0EtNvSi5KS4JMb6qVC60Fj-tA@mail.gmail.com>
 <CABgxDo+oGe47hvxiCOAUWz8zfSeVONf=3pFm+=PbNsCbr_jTpg@mail.gmail.com>
 <4158343.mkrTsd5B4G@wuerfel>
Message-ID: <CAOQ7t2byFoW657-1xnsBpeyPkB6K25R=_pPmRDmT32Sjef=kUw@mail.gmail.com>

On Thu, Feb 18, 2016 at 1:43 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 18 February 2016 13:33:04 Romain Perier wrote:
>> 2016-02-17 21:36 GMT+01:00 Carlo Caione <carlo at caione.org>:
>> > On Wed, Feb 17, 2016 at 6:28 PM, Romain Perier <romain.perier at gmail.com> wrote:
>> >> These are the CBUS registers used to retrieve the revision and the
>> >> identifier of the SoC on Meson8.
>> >>
>> >> Signed-off-by: Romain Perier <romain.perier at gmail.com>
>> >> ---
>> >>  arch/arm/boot/dts/meson8b.dtsi | 5 +++++
>> >>  1 file changed, 5 insertions(+)
>> >>
>> >> diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
>> >> index 0477a81..71009dc 100644
>> >> --- a/arch/arm/boot/dts/meson8b.dtsi
>> >> +++ b/arch/arm/boot/dts/meson8b.dtsi
>> >> @@ -99,6 +99,11 @@
>> >>                 };
>> >>         };
>> >>
>> >> +       hwrev at c1107d4c {
>> >> +               compatible = "amlogic,meson8b-hwrev", "syscon";
>> >> +               reg = <0xc1107d4c 0x460>;
>> >
>> > Interesting. Where did you get 0x460?
>>
>> Carlo, Arnd.
>>
>> Well, what I did is the following :
>> - CBUS_PHY_BASE is 0xc1100000   (CBUS is a larger block of registers,
>> like slcr on zynq)
>> - the serial is at CBUS_PHY_BASE + 0x7d4c
>> - the revision is at CBUS_PHY_BASE + 0x81a8
>>
>> So I decided to create a device_node for hw revision at 0xc1107d4c, in
>> this case the lenght is 0x460...
>> Am I wrong ?
>
> Yes, you should describe the device that is actually there, which would be
> something like
>
>         cbus at c1100000 {
>                 compatible = "amlogic,meson8b-cbus", "syscon";
>                 reg = <0xc1100000 0x10000>; /* no idea what the length is, fix it */
>         };
>
> Don't just make things up because you happen to access them in a particular
> way, but try to stay as close as you can to describing the actual hardware.

Arnd,
in the cbus region are mapped a lot of different devices, do you think
that it is a good idea mapping the whole region as a single syscon
device?

-- 
Carlo Caione


From matt at codeblueprint.co.uk  Thu Feb 18 06:15:44 2016
From: matt at codeblueprint.co.uk (Matt Fleming)
Date: Thu, 18 Feb 2016 14:15:44 +0000
Subject: [PATCH v2 1/2] efi: esrt: use memremap not ioremap to access
 ESRT table in memory
In-Reply-To: <CAKv+Gu875r9RkDC723kNsG4XC0eSE9RPPmSFZrD0sx0QxS+V4g@mail.gmail.com>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160218104407.GC2651@codeblueprint.co.uk>
 <CAKv+Gu_AW7PKJJOd2mbEu3LKJe+gNaPHnH=sgO=YXM_KWFyKxw@mail.gmail.com>
 <20160218132824.GE2651@codeblueprint.co.uk>
 <CAKv+Gu-s1pzYBzuDG-Z7s3gyo8dPOfeidZQ+rim-uAWZCBcKQQ@mail.gmail.com>
 <20160218134324.GG2651@codeblueprint.co.uk>
 <CAKv+Gu875r9RkDC723kNsG4XC0eSE9RPPmSFZrD0sx0QxS+V4g@mail.gmail.com>
Message-ID: <20160218141544.GH2651@codeblueprint.co.uk>

On Thu, 18 Feb, at 02:44:02PM, Ard Biesheuvel wrote:
> On 18 February 2016 at 14:43, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> > On Thu, 18 Feb, at 02:29:32PM, Ard Biesheuvel wrote:
> >> On 18 February 2016 at 14:28, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> >> > On Thu, 18 Feb, at 01:16:05PM, Ard Biesheuvel wrote:
> >> >> On 18 February 2016 at 11:44, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> >> >> > On Mon, 15 Feb, at 12:32:32PM, Ard Biesheuvel wrote:
> >> >> >> On ARM and arm64, ioremap() and memremap() are not interchangeable like
> >> >> >> on x86, and the use of ioremap() on ordinary RAM is typically flagged
> >> >> >> as an error if the memory region being mapped is also covered by the
> >> >> >> linear mapping, since that would lead to aliases with conflicting
> >> >> >> cacheability attributes.
> >> >> >>
> >> >> >> Since what we are dealing with is not an I/O region with side effects,
> >> >> >> using ioremap() here is arguably incorrect anyway, so let's replace
> >> >> >> it with memremap instead. Also add a missing unmap on the success path,
> >> >> >> and drop a memblock_remove() call which does not belong here, this far
> >> >> >> into the boot sequence.
> >> >> >>
> >> >> >> Cc: Peter Jones <pjones at redhat.com>
> >> >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >> >> >> ---
> >> >> >>  drivers/firmware/efi/esrt.c | 16 ++++++++--------
> >> >> >>  1 file changed, 8 insertions(+), 8 deletions(-)
> >> >> >>
> >> >> >
> >> >> > [...]
> >> >> >
> >> >> >> @@ -432,8 +434,6 @@ static int __init esrt_sysfs_init(void)
> >> >> >>       if (error)
> >> >> >>               goto err_cleanup_list;
> >> >> >>
> >> >> >> -     memblock_remove(esrt_data, esrt_data_size);
> >> >> >> -
> >> >> >>       pr_debug("esrt-sysfs: loaded.\n");
> >> >> >>
> >> >> >>       return 0;
> >> >> >
> >> >> > Shouldn't we be replacing memblock_remove() with free_bootmem_late()?
> >> >> > The original ESRT region is still reserved at this point, so we should
> >> >> > do our best to release it to the page allocator.
> >> >>
> >> >> I'd rather we keep it reserved. That way, the config table entry still
> >> >> points to something valid, which could be useful for kexec(), I think?
> >> >> At least, that is how I intended to handle config tables on ARM ...
> >> >
> >> > If we're going to reserve it why do we need to copy the data out at
> >> > all in esrt_sysfs_init()?
> >>
> >> Excellent question. I don't think there is any point to doing that.
> >
> > ... Unless the data is contained in an EFI Boot Services region ;-)
> >
> > Peter?
> 
> Yes, it usually is. Is that a problem?

Yes, we free the Boot Services regions before hitting userspace on
x86, see efi_free_boot_services(). We do this map/copy/unmap trick in
the ACPI BGRT driver for that reason.

The Boot Services regions can be many gigabytes in size, which makes
leaving them alone impractical.

For kexec on x86 we simply discard the BGRT table, which isn't the end
of the world because who really needs access to the BGRT image on
kexec reboot? However, I can see the value of preserving the ESRT.

I guess we've got two options, 1) copy out the chunks of Boot Services
regions we're interested in and rewrite the EFI tables to point at
these new allocations and free/discard all of the original Boot
Services regions or 2) only selectively free the Boot Services
regions.

I've always stayed clear of 2) in case there exists cross-region
references in the data that isn't obvious. I'd like to think that
would never happen, but, you know, dragons lurk here, etc.

Though actually, now I think about it, cross-region references can't
possibly exist because they'd cause issues with the current code.

So maybe the best solution is actually 2), where we preserve the Boot
Services regions if any of the drivers (ESRT, BGRT) request them but
free all the others? 

What are the lifetime rules for Boot Services regions on arm*?


From arnd at arndb.de  Thu Feb 18 06:16:36 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 15:16:36 +0100
Subject: [PATCH 1/3] irqchip: gic/realview: support more RealView DCC
 variants
In-Reply-To: <1455803172-22747-1-git-send-email-linus.walleij@linaro.org>
References: <1455803172-22747-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <2593223.OY9PIVzfdv@wuerfel>

On Thursday 18 February 2016 14:46:12 Linus Walleij wrote:
> In the add-on file for the GIC dealing with the RealView family
> we currently only handle the PB11MPCore, let's extend this to
> manage the RealView EB ARM11MPCore as well. The Revision B of the
> ARM11MPCore core tile is a bit special and needs special handling
> as it moves a system control register around at random.
> 
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Marc Zyngier <marc.zyngier at arm.com>
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> This can be applied in isolation from the other patches so Marc
> one you're happy with it, please take it into the IRQchip tree.
> 
> There are two compatible strings getting added to the device tree
> bindings so CC to the DT list. No biggie though, just figures out
> exactly what ARM custom GIC flavor it is.
> 

Looks good to me.

All three patches:

Acked-by: Arnd Bergmann <arnd at arndb.de>


From marc.zyngier at arm.com  Thu Feb 18 06:19:48 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Feb 2016 14:19:48 +0000
Subject: [PATCH 1/3] irqchip: gic/realview: support more RealView DCC
 variants
In-Reply-To: <1455803172-22747-1-git-send-email-linus.walleij@linaro.org>
References: <1455803172-22747-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <56C5D304.5010708@arm.com>

Hi Linus,

On 18/02/16 13:46, Linus Walleij wrote:
> In the add-on file for the GIC dealing with the RealView family
> we currently only handle the PB11MPCore, let's extend this to
> manage the RealView EB ARM11MPCore as well. The Revision B of the
> ARM11MPCore core tile is a bit special and needs special handling
> as it moves a system control register around at random.

Ah, 11MPCore RevB. That thing. Tried to locate one in the magic
cupboard, and failed. Oh well...

> 
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Marc Zyngier <marc.zyngier at arm.com>
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> This can be applied in isolation from the other patches so Marc
> one you're happy with it, please take it into the IRQchip tree.
> 
> There are two compatible strings getting added to the device tree
> bindings so CC to the DT list. No biggie though, just figures out
> exactly what ARM custom GIC flavor it is.
> ---
>  .../bindings/interrupt-controller/arm,gic.txt      |  2 ++
>  drivers/irqchip/irq-gic-realview.c                 | 35 ++++++++++++++++++----
>  2 files changed, 32 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
> index 5a1cb4bc3dfe..0c80e6870645 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
> @@ -16,6 +16,8 @@ Main node required properties:
>  	"arm,cortex-a15-gic"
>  	"arm,cortex-a7-gic"
>  	"arm,cortex-a9-gic"
> +	"arm,eb11mp-gic"
> +	"arm,eb11mp-revb-gic"
>  	"arm,gic-400"
>  	"arm,pl390"
>  	"arm,tc11mp-gic"
> diff --git a/drivers/irqchip/irq-gic-realview.c b/drivers/irqchip/irq-gic-realview.c
> index aa46eb280a7f..224e83d5c056 100644
> --- a/drivers/irqchip/irq-gic-realview.c
> +++ b/drivers/irqchip/irq-gic-realview.c
> @@ -10,7 +10,8 @@
>  #include <linux/irqchip/arm-gic.h>
>  
>  #define REALVIEW_SYS_LOCK_OFFSET	0x20
> -#define REALVIEW_PB11MP_SYS_PLD_CTRL1	0x74
> +#define REALVIEW_SYS_PLD_CTRL1		0x74
> +#define REALVIEW_EB_REVB_SYS_PLD_CTRL1	0xD8
>  #define VERSATILE_LOCK_VAL		0xA05F
>  #define PLD_INTMODE_MASK		BIT(22)|BIT(23)|BIT(24)
>  #define PLD_INTMODE_LEGACY		0x0
> @@ -18,26 +19,50 @@
>  #define PLD_INTMODE_NEW_NO_DCC		BIT(23)
>  #define PLD_INTMODE_FIQ_ENABLE		BIT(24)
>  
> +static const struct of_device_id syscon_pldset_of_match[] = {
> +	{
> +		.compatible = "arm,realview-eb-syscon",
> +	},
> +	{
> +		.compatible = "arm,realview-pb11mp-syscon",
> +	},
> +	{},
> +};
> +
>  static int __init
>  realview_gic_of_init(struct device_node *node, struct device_node *parent)
>  {
>  	static struct regmap *map;
> +	struct device_node *np;
> +	struct pld_setting *pldset;
> +	u32 pld1_ctrl = REALVIEW_SYS_PLD_CTRL1;
> +
> +	np = of_find_matching_node_and_match(NULL, syscon_pldset_of_match,
> +					     (void *)&pldset);
> +	if (!np)
> +		return -ENODEV;
> +
> +	/* For some reason RealView EB Rev B moved this register */
> +	if (of_device_is_compatible(np, "arm,eb11mp-revb-gic"))
> +		pld1_ctrl = REALVIEW_EB_REVB_SYS_PLD_CTRL1;

Associating the PLD control register with the GIC compatible string is a
bit odd, as they are conceptually two different devices. Why not storing
the register address as the data field in the syscon_pldset_of_match
array? One less check, and you get it for free (sort of).

>  
>  	/* The PB11MPCore GIC needs to be configured in the syscon */
> -	map = syscon_regmap_lookup_by_compatible("arm,realview-pb11mp-syscon");
> +	map = syscon_node_to_regmap(np);
>  	if (!IS_ERR(map)) {
>  		/* new irq mode with no DCC */
>  		regmap_write(map, REALVIEW_SYS_LOCK_OFFSET,
>  			     VERSATILE_LOCK_VAL);
> -		regmap_update_bits(map, REALVIEW_PB11MP_SYS_PLD_CTRL1,
> +		regmap_update_bits(map, pld1_ctrl,
>  				   PLD_INTMODE_NEW_NO_DCC,
>  				   PLD_INTMODE_MASK);
>  		regmap_write(map, REALVIEW_SYS_LOCK_OFFSET, 0x0000);
> -		pr_info("TC11MP GIC: set up interrupt controller to NEW mode, no DCC\n");
> +		pr_info("RealView GIC: set up interrupt controller to NEW mode, no DCC\n");
>  	} else {
> -		pr_err("TC11MP GIC setup: could not find syscon\n");
> +		pr_err("RealView GIC setup: could not find syscon\n");
>  		return -ENXIO;

Is that even reachable now that you check for the syscon early in the
function? Also, you are now returning -ENODEV while you were returning
-ENXIO before. Which one is the most correct (I have no idea)?

>  	}
>  	return gic_of_init(node, parent);
>  }
>  IRQCHIP_DECLARE(armtc11mp_gic, "arm,tc11mp-gic", realview_gic_of_init);
> +IRQCHIP_DECLARE(armeb11mp_gic, "arm,eb11mp-gic", realview_gic_of_init);
> +IRQCHIP_DECLARE(armeb11mp_revb_gic, "arm,eb11mp-revb-gic", realview_gic_of_init);
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From tixy at linaro.org  Thu Feb 18 06:21:16 2016
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Thu, 18 Feb 2016 14:21:16 +0000
Subject: [PATCH 9/9] ARM: fix kprobe test with CONFIG_CPU_32v3
In-Reply-To: <1455804123-2526139-10-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-10-git-send-email-arnd@arndb.de>
Message-ID: <1455805276.3036.3.camel@linaro.org>

On Thu, 2016-02-18 at 15:02 +0100, Arnd Bergmann wrote:
> ARMv3 did not have 16-bit load/store or 32-bit multiply instructions,
> so building the kprobe test code fails with lots of warnings about
> these:
> 
> /tmp/ccI4SKHx.s:19585: Error: selected processor does not support ARM mode `umull r0,r1,r2,r3'
> /tmp/ccI4SKHx.s:19617: Error: selected processor does not support ARM mode `umullls r7,r8,r9,r10'
> /tmp/ccI4SKHx.s:19645: Error: selected processor does not support ARM mode `umull lr,r12,r11,r13'
> /tmp/ccI4SKHx.s:19727: Error: selected processor does not support ARM mode `umulls r0,r1,r2,r3'
> ...
> /tmp/ccI4SKHx.s:21273: Error: selected processor does not support ARM mode `strh r0,[r1,-r2]'
> /tmp/ccI4SKHx.s:21309: Error: selected processor does not support ARM mode `streqh r14,[r11,r12]'
> /tmp/ccI4SKHx.s:21333: Error: selected processor does not support ARM mode `streqh r14,[r13,r12]'
> 
> This puts all the affected instructions inside an #ifdef section,
> like we do for the other architecture levels.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---

I was about to say that I didn't know that we supported ARMv3 then got a
feeling of deja vu :-) [1]

Acked-by: Jon Medhurst <tixy at linaro.org>

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/242997.html

>  arch/arm/probes/kprobes/test-arm.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/probes/kprobes/test-arm.c b/arch/arm/probes/kprobes/test-arm.c
> index 8866aedfdea2..4e8511f0582d 100644
> --- a/arch/arm/probes/kprobes/test-arm.c
> +++ b/arch/arm/probes/kprobes/test-arm.c
> @@ -391,6 +391,7 @@ void kprobe_arm_test_cases(void)
>  	TEST_UNSUPPORTED(__inst_arm(0xe0700090) " @ undef")
>  	TEST_UNSUPPORTED(__inst_arm(0xe07fff9f) " @ undef")
>  
> +#if __LINUX_ARM_ARCH__ >= 4
>  	TEST_RR(  "umull	r0, r1, r",2, VAL1,", r",3, VAL2,"")
>  	TEST_RR(  "umullls	r7, r8, r",9, VAL2,", r",10, VAL1,"")
>  	TEST_R(   "umull	lr, r12, r",11,VAL3,", r13")
> @@ -436,6 +437,7 @@ void kprobe_arm_test_cases(void)
>  	TEST_UNSUPPORTED(__inst_arm(0xe0f0f392) " @ smlals r0, pc, r2, r3")
>  	TEST_UNSUPPORTED(__inst_arm(0xe0f0139f) " @ smlals r0, r1, pc, r3")
>  	TEST_UNSUPPORTED(__inst_arm(0xe0f01f92) " @ smlals r0, r1, r2, pc")
> +#endif
>  
>  	TEST_GROUP("Synchronization primitives")
>  
> @@ -478,7 +480,7 @@ void kprobe_arm_test_cases(void)
>  	TEST_UNSUPPORTED("ldrexh	r2, [sp]")
>  #endif
>  	TEST_GROUP("Extra load/store instructions")
> -
> +#if __LINUX_ARM_ARCH__ >= 4
>  	TEST_RPR(  "strh	r",0, VAL1,", [r",1, 48,", -r",2, 24,"]")
>  	TEST_RPR(  "streqh	r",14,VAL2,", [r",11,0, ", r",12, 48,"]")
>  	TEST_UNSUPPORTED(  "streqh	r14, [r13, r12]")
> @@ -560,6 +562,7 @@ void kprobe_arm_test_cases(void)
>  	TEST(      "ldrsh	r0, [pc, #0]")
>  	TEST_UNSUPPORTED(__inst_arm(0xe1ffc3f0) "	@ ldrsh r12, [pc, #48]!")
>  	TEST_UNSUPPORTED(__inst_arm(0xe0d9f3f0) "	@ ldrsh pc, [r9], #48")
> +#endif
>  
>  #if __LINUX_ARM_ARCH__ >= 7
>  	TEST_UNSUPPORTED("strht	r1, [r2], r3")




From arnd at arndb.de  Thu Feb 18 06:22:29 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 15:22:29 +0100
Subject: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
In-Reply-To: <CAOQ7t2byFoW657-1xnsBpeyPkB6K25R=_pPmRDmT32Sjef=kUw@mail.gmail.com>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <4158343.mkrTsd5B4G@wuerfel>
 <CAOQ7t2byFoW657-1xnsBpeyPkB6K25R=_pPmRDmT32Sjef=kUw@mail.gmail.com>
Message-ID: <4136837.fyWFbJqZfO@wuerfel>

On Thursday 18 February 2016 15:14:45 Carlo Caione wrote:
> >
> > Yes, you should describe the device that is actually there, which would be
> > something like
> >
> >         cbus at c1100000 {
> >                 compatible = "amlogic,meson8b-cbus", "syscon";
> >                 reg = <0xc1100000 0x10000>; /* no idea what the length is, fix it */
> >         };
> >
> > Don't just make things up because you happen to access them in a particular
> > way, but try to stay as close as you can to describing the actual hardware.
> 
> Arnd,
> in the cbus region are mapped a lot of different devices, do you think
> that it is a good idea mapping the whole region as a single syscon
> device?

It really depends on what those other devices do with the registers:

If each device just uses a couple of random registers from the cbus,
they should probably all be changed to go through syscon.

However, if some or all of the other devices actually are entirely
made up of register ranges within cbus, that would indicate that
cbus itself is not just a collection of random registers but something
that could be considered a bus of itself in hardware, and then
we could represent the other devices as children of this bus.

Usually once you have a list of all the register locations, you can
identify the hardware structure to a certain degree from that, even
if you don't have access to a data sheet that would clarify this
better.

	Arnd


From shawnguo at kernel.org  Thu Feb 18 06:23:07 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 18 Feb 2016 22:23:07 +0800
Subject: [PATCH v3 1/3] ARM: dts: vf-colibri: remove regulator container
 node
In-Reply-To: <1455752460-2770-1-git-send-email-stefan@agner.ch>
References: <1455752460-2770-1-git-send-email-stefan@agner.ch>
Message-ID: <20160218142307.GA6756@tiger>

On Wed, Feb 17, 2016 at 03:40:58PM -0800, Stefan Agner wrote:
> Drop the fake simple-bus container 'regulators' and put the
> regulators directly under the root node. This also makes the
> artificial 'reg' properties superfluous. While at it, remove
> the unnecessary regulator-always-on property and name the
> regulators according to schematics.
> 
> Signed-off-by: Stefan Agner <stefan at agner.ch>
> ---
> Changes since v2:
> - remove regulator-always-on
> 
> Changes since v1:
> - rename regulators according to schematics
> - drop sys prefix

Okay.  Replaced v1 with v3.

Shawn


From thierry.reding at gmail.com  Thu Feb 18 06:24:09 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Thu, 18 Feb 2016 15:24:09 +0100
Subject: [PATCH] PCI: mvebu: Restrict build to 32-bit ARM
In-Reply-To: <5051836.EUN3ennYNm@wuerfel>
References: <1455802330-17565-1-git-send-email-thierry.reding@gmail.com>
 <5051836.EUN3ennYNm@wuerfel>
Message-ID: <20160218142409.GA4678@ulmo.nvidia.com>

On Thu, Feb 18, 2016 at 03:06:23PM +0100, Arnd Bergmann wrote:
> On Thursday 18 February 2016 14:32:10 Thierry Reding wrote:
> > From: Thierry Reding <treding at nvidia.com>
> > 
> > This driver uses PCI glue that is only available on 32-bit ARM. This
> > used to work fine as long as ARCH_MVEBU and ARCH_DOVE were exclusively
> > 32-bit, but that's changed now, with ARCH_MVEBU also being available
> > on 64-bit ARM.
> > 
> > Signed-off-by: Thierry Reding <treding at nvidia.com>
> 
> Looks fine as a temporary workaround, but I think what we really want to
> do here is to remove the dependency, as the new ARM64 platforms are going
> to need this driver anyway.

Agreed. I've been meaning to do just that for Tegra as well, but the
conversion is somewhat more involved and this is currently breaking the
linux-next builds, so a quick fix, even if temporary, is warranted in my
opinion.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160218/a03a27ec/attachment-0001.sig>

From marc.zyngier at arm.com  Thu Feb 18 06:26:31 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Feb 2016 14:26:31 +0000
Subject: [PATCH 2/9] ARM: change NR_IPIS to 8
In-Reply-To: <1455804123-2526139-3-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-3-git-send-email-arnd@arndb.de>
Message-ID: <56C5D497.7030309@arm.com>

Hi Arnd,

On 18/02/16 14:01, Arnd Bergmann wrote:
> When function tracing for IPIs is enabled, we get a warning for an
> overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
> as triggered by raise_nmi():
> 
> arch/arm/kernel/smp.c: In function 'raise_nmi':
> arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds [-Werror=array-bounds]
>   trace_ipi_raise(target, ipi_types[ipinr]);
> 
> This is a correct warning as we actually overflow the array here.
> To make the tracing work correctly, this extends the array by one
> entry and increases NR_IPI accordingly.
> 
> This only works after patch e7273ff49acf ("ARM: 8488/1: Make
> IPI_CPU_BACKTRACE a "non-secure" SGI"), which changed the number
> assignment from '15' to '8'. If we decide to backport this patch
> to stable kernels, we probably need to backport e7273ff49acf
> as well.

I may actually have made the bug worse in 89d798b ("ARM: 8487/1: Remove
IPI_CALL_FUNC_SINGLE"), which changed NR_IPI from 8 to 7. It would need
to be backported as well (as otherwise we don't have a free non-secure
IP slot).

> 
> As far as I can tell, the problem has existed since the tracepoints
> were originally added, but it only triggered a gcc warning with the
> later change to NR_IPIS.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI")
> Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") # v3.17

Acked-by: Marc Zyngier <marc.zyngier at arm.com>

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From thomas.petazzoni at free-electrons.com  Thu Feb 18 06:29:03 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 18 Feb 2016 15:29:03 +0100
Subject: [PATCH] PCI: mvebu: Restrict build to 32-bit ARM
In-Reply-To: <1455802330-17565-1-git-send-email-thierry.reding@gmail.com>
References: <1455802330-17565-1-git-send-email-thierry.reding@gmail.com>
Message-ID: <20160218152903.7a659ca8@free-electrons.com>

Hello,

On Thu, 18 Feb 2016 14:32:10 +0100, Thierry Reding wrote:
> From: Thierry Reding <treding at nvidia.com>
> 
> This driver uses PCI glue that is only available on 32-bit ARM. This
> used to work fine as long as ARCH_MVEBU and ARCH_DOVE were exclusively
> 32-bit, but that's changed now, with ARCH_MVEBU also being available
> on 64-bit ARM.
> 
> Signed-off-by: Thierry Reding <treding at nvidia.com>
> ---
>  drivers/pci/host/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From robh at kernel.org  Thu Feb 18 06:35:48 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:35:48 -0600
Subject: [PATCH v2 3/8] DT: clk: sunxi: add binding doc for the
 multi-bus-gates clock
In-Reply-To: <1455709440-8668-4-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
 <1455709440-8668-4-git-send-email-andre.przywara@arm.com>
Message-ID: <20160218143548.GD9654@rob-hp-laptop>

On Wed, Feb 17, 2016 at 11:43:55AM +0000, Andre Przywara wrote:
> Recent Allwinner SoCs introduced a bus gates clock which can have
> different parents for individual gates.
> For the time being we encoded this relation in the driver.
> This commit specifies a new binding which allows to encode this in
> the DT by using a child node for each parent clock used. This allows
> to specify any kind of relation efficiently and also keeps the very
> same kernel driver for all SoCs at the same time.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt | 6 ++++++
>  1 file changed, 6 insertions(+)

Whether this makes sense or not for sunxi, I don't know. But for the 
binding:

Acked-by: Rob Herring <robh at kernel.org>




From robh at kernel.org  Thu Feb 18 06:35:43 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:35:43 -0600
Subject: [PATCH v2 2/8] drivers: pinctrl: add driver for Allwinner A64 SoC
In-Reply-To: <1455709440-8668-3-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
 <1455709440-8668-3-git-send-email-andre.przywara@arm.com>
Message-ID: <20160218143543.GC9654@rob-hp-laptop>

On Wed, Feb 17, 2016 at 11:43:54AM +0000, Andre Przywara wrote:
> Based on the Allwinner A64 user manual and on the previous sunxi
> pinctrl drivers this introduces the pin multiplex assignments for
> the ARMv8 Allwinner A64 SoC.
> Port A is apparently used for the fixed function DRAM controller, so
> the ports start at B here (the manual mentions "n from 1 to 7", so
> not starting at 0).
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +

Acked-by: Rob Herring <robh at kernel.org>

>  arch/arm64/Kconfig.platforms                       |   1 +
>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
>  drivers/pinctrl/sunxi/Makefile                     |   1 +
>  drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c         | 606 +++++++++++++++++++++
>  5 files changed, 613 insertions(+)
>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c


From gregory.clement at free-electrons.com  Thu Feb 18 06:34:30 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 18 Feb 2016 15:34:30 +0100
Subject: [PATCH] PCI: mvebu: Restrict build to 32-bit ARM
In-Reply-To: <5051836.EUN3ennYNm@wuerfel> (Arnd Bergmann's message of "Thu, 18
 Feb 2016 15:06:23 +0100")
References: <1455802330-17565-1-git-send-email-thierry.reding@gmail.com>
 <5051836.EUN3ennYNm@wuerfel>
Message-ID: <87egcaqe89.fsf@free-electrons.com>

Hi Arnd,
 
 On jeu., f?vr. 18 2016, Arnd Bergmann <arnd at arndb.de> wrote:

> On Thursday 18 February 2016 14:32:10 Thierry Reding wrote:
>> From: Thierry Reding <treding at nvidia.com>
>> 
>> This driver uses PCI glue that is only available on 32-bit ARM. This
>> used to work fine as long as ARCH_MVEBU and ARCH_DOVE were exclusively
>> 32-bit, but that's changed now, with ARCH_MVEBU also being available
>> on 64-bit ARM.
>> 
>> Signed-off-by: Thierry Reding <treding at nvidia.com>
>
> Looks fine as a temporary workaround, but I think what we really want to
> do here is to remove the dependency, as the new ARM64 platforms are going
> to need this driver anyway.

Actually the mvebu ARM64 platform we know about (Armada 3700, 7K and
8K), won't use the same controller. A7K/A8K will use a synopsis IP and
Armada 3700 a new Marvell IP.

So for me depending on ARM32 is enough.

Gregory

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From robh at kernel.org  Thu Feb 18 06:36:01 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:36:01 -0600
Subject: [PATCH v2 5/8] arm64: dts: add Allwinner A64 SoC .dtsi
In-Reply-To: <1455709440-8668-6-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
 <1455709440-8668-6-git-send-email-andre.przywara@arm.com>
Message-ID: <20160218143601.GE9654@rob-hp-laptop>

On Wed, Feb 17, 2016 at 11:43:57AM +0000, Andre Przywara wrote:
> The Allwinner A64 SoC is a low-cost chip with 4 ARM Cortex-A53 cores
> and the typical tablet / TV box peripherals.
> The SoC is based on the (32-bit) Allwinner H3 chip, sharing most of
> the peripherals and the memory map.
> Although the cores are proper 64-bit ones, the whole SoC is actually
> limited to 4GB (including all the supported DRAM), so we use 32-bit
> address and size cells. This has the nice feature of us being able to
> reuse the DT for 32-bit kernels as well.
> This .dtsi lists the hardware that we support so far.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  Documentation/devicetree/bindings/arm/sunxi.txt   |   1 +
>  Documentation/devicetree/bindings/clock/sunxi.txt |   1 +
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi     | 642 ++++++++++++++++++++++
>  3 files changed, 644 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi

[...]

> +	memory {
> +		device_type = "memory";
> +		reg = <0x40000000 0>;
> +	};
> +
> +	gic: interrupt-controller at 01c81000 {

Remove the numerous leading 0s on the unit addresses.

With that:

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Thu Feb 18 06:36:06 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:36:06 -0600
Subject: [PATCH v2 6/8] of: add vendor prefix for Pine64
In-Reply-To: <1455709440-8668-7-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
 <1455709440-8668-7-git-send-email-andre.przywara@arm.com>
Message-ID: <20160218143606.GF9654@rob-hp-laptop>

On Wed, Feb 17, 2016 at 11:43:58AM +0000, Andre Przywara wrote:
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Thu Feb 18 06:36:10 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:36:10 -0600
Subject: [PATCH V6 1/2] regulator: Add document for MT6323 regulator
In-Reply-To: <1455709056-50510-1-git-send-email-blogic@openwrt.org>
References: <1455709056-50510-1-git-send-email-blogic@openwrt.org>
Message-ID: <20160218143610.GG9654@rob-hp-laptop>

On Wed, Feb 17, 2016 at 12:37:35PM +0100, John Crispin wrote:
> Signed-off-by: John Crispin <blogic at openwrt.org>
> Cc: devicetree at vger.kernel.org
> 
> ---
> Changes in V6
> * remove the compatible string
> 
> Changes in V5
> * regulator vs regulators
> 
> Changes in V4
> * regulator is a subnode and not a property
> 
>  .../bindings/regulator/mt6323-regulator.txt        |  241 ++++++++++++++++++++
>  1 file changed, 241 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
> 
> diff --git a/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
> new file mode 100644
> index 0000000..67c0780
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
> @@ -0,0 +1,241 @@
> +Mediatek MT6323 Regulator Driver
> +
> +All voltage regulators are defined as subnodes of the regulators node. A list
> +of regulators provided by this controller are defined as subnodes of the
> +drivers node. Each regulator is named according to its regulator type,

s/drivers/PMIC's/

> +buck_<name> and ldo_<name>. The definition for each of these nodes is defined
> +using the standard binding for regulators at
> +Documentation/devicetree/bindings/regulator/regulator.txt.
> +
> +The valid names for regulators are::
> +BUCK:
> +  buck_vproc, buck_vsys, buck_vpa
> +LDO:
> +  ldo_vtcxo, ldo_vcn28, ldo_vcn33_bt, ldo_vcn33_wifi, ldo_va, ldo_vcama,
> +  ldo_vio28, ldo_vusb, ldo_vmc, ldo_vmch, ldo_vemc3v3, ldo_vgp1, ldo_vgp2,
> +  ldo_vgp3, ldo_vcn18, ldo_vsim1, ldo_vsim2, ldo_vrtc, ldo_vcamaf, ldo_vibr,
> +  ldo_vrf18, ldo_vm, ldo_vio18, ldo_vcamd, ldo_vcamio
> +
> +Example:
> +
> +	pmic: mt6323 {
> +		compatible = "mediatek,mt6323";
> +
> +		mt6323regulator: regulators {
> +			compatible = "mediatek,mt6323-regulator";

Still have the compatible here...

Otherwise:

Acked-by: Rob Herring <robh at kernel.org>



From robh at kernel.org  Thu Feb 18 06:36:17 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:36:17 -0600
Subject: [PATCH v2 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <1455702226-20599-2-git-send-email-raveendra.padasalagi@broadcom.com>
References: <1455702226-20599-1-git-send-email-raveendra.padasalagi@broadcom.com>
 <1455702226-20599-2-git-send-email-raveendra.padasalagi@broadcom.com>
Message-ID: <20160218143617.GH9654@rob-hp-laptop>

On Wed, Feb 17, 2016 at 03:13:44PM +0530, Raveendra Padasalagi wrote:
> In Cygnus SOC touch screen controller registers are shared
> with ADC and flex timer. Using readl/writel could lead to
> race condition. So touch screen driver is enhanced to support
> 
> 1. If touchscreen register's are not shared. Register access
> is handled through readl/writel if "brcm,iproc-touchscreen"
> compatible is provided in touchscreen dt node. This will help
> for future SOC's if comes with dedicated touchscreen IP register's.
> 
> 2. If touchscreen register's are shared with other IP's, register
> access is handled through syscon framework API's to take care of
> mutually exclusive access. This feature can be enabled by selecting
> "brcm,iproc-touchscreen-syscon" compatible string in the touchscreen
> dt node.
> 
> Hence touchscreen dt node bindings document is updated to take care
> of above changes in the touchscreen driver.
> 
> Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi at broadcom.com>
> Reviewed-by: Ray Jui <ray.jui at broadcom.com>
> Reviewed-by: Scott Branden <scott.branden at broadcom.com>
> ---
>  .../input/touchscreen/brcm,iproc-touchscreen.txt   | 57 +++++++++++++++++++---
>  1 file changed, 51 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
> index 34e3382..f530c25 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
> @@ -1,12 +1,30 @@
>  * Broadcom's IPROC Touchscreen Controller
>  
>  Required properties:
> -- compatible: must be "brcm,iproc-touchscreen"
> -- reg: physical base address of the controller and length of memory mapped
> -  region.
> +- compatible: should be one of
> +        "brcm,iproc-touchscreen"
> +        "brcm,iproc-touchscreen-syscon"

More specific and this is not how you do syscon. Either the block is or 
isn't. You can't have it both ways.

> +- ts_syscon: if "brcm,iproc-touchscreen-syscon" compatible string
> +  is selected then "ts_syscon" is mandatory or else not required.
> +  The "ts_syscon" is handler of syscon node defining physical base
> +  address of the controller and length of memory mapped region.
> +  If this property is selected please make sure MFD_SYSCON config
> +  is enabled in the defconfig file.
> +- reg: if "brcm,iproc-touchscreen" compatible string is selected
> +  then "reg" property is mandatory or else not required.
> +  The "reg" should be physical base address of the controller and
> +  length of memory mapped region.

I thought every chip to date is a syscon. Add reg support when you 
actually need it.

>  - clocks:  The clock provided by the SOC to driver the tsc
>  - clock-name:  name for the clock
>  - interrupts: The touchscreen controller's interrupt
> +- address-cells: Specify the number of u32 entries needed in child nodes.
> +                 Should set to 1. This property is mandatory when
> +                 "brcm,iproc-touchscreen-syscon" compatible string is selected
> +                 or else not required.
> +- size-cells: Specify number of u32 entries needed to specify child nodes size
> +              in reg property. Should set to 1.This property is mandatory when
> +              "brcm,iproc-touchscreen-syscon" compatible string is selected or
> +              else not required.
>  
>  Optional properties:
>  - scanning_period: Time between scans. Each step is 1024 us.  Valid 1-256.
> @@ -53,13 +71,40 @@ Optional properties:
>  - touchscreen-inverted-x: X axis is inverted (boolean)
>  - touchscreen-inverted-y: Y axis is inverted (boolean)
>  
> -Example:
> +Example 1: An example of touchscreen node with "brcm,iproc-touchscreen-syscon"
> +           compatible string.
> +
> +	ts_adc_syscon: ts_adc_syscon at 0x180a6000 {
> +		compatible = "syscon";
> +		reg = <0x180a6000 0xc30>;
> +	};
>  
>  	touchscreen: tsc at 0x180A6000 {

Drop the '0x' and the node name should be touchscreen, not tsc.

> -		compatible = "brcm,iproc-touchscreen";
> +		compatible = "brcm,iproc-touchscreen-syscon";
>  		#address-cells = <1>;
>  		#size-cells = <1>;
> -		reg = <0x180A6000 0x40>;
> +		ts_syscon = <&ts_adc_syscon>;
> +		clocks = <&adc_clk>;
> +		clock-names = "tsc_clk";
> +		interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
> +

> +		scanning_period = <5>;
> +		debounce_timeout = <40>;
> +		settling_timeout = <7>;
> +		touch_timeout = <10>;
> +		average_data = <5>;
> +		fifo_threshold = <1>;

New properties?

> +		/* Touchscreen is rotated 180 degrees. */
> +		touchscreen-inverted-x;
> +		touchscreen-inverted-y;
> +	};
> +
> +Example 2: An example of touchscreen node with "brcm,iproc-touchscreen"
> +          compatible string.
> +
> +	touchscreen: tsc at 0x180A6000 {
> +		compatible = "brcm,iproc-touchscreen";
> +		reg = <0x180a6000 0x40>;
>  		clocks = <&adc_clk>;
>  		clock-names = "tsc_clk";
>  		interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
> -- 
> 1.9.1
> 


From ard.biesheuvel at linaro.org  Thu Feb 18 06:21:25 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 18 Feb 2016 15:21:25 +0100
Subject: [PATCH v2 1/2] efi: esrt: use memremap not ioremap to access ESRT
 table in memory
In-Reply-To: <20160218141544.GH2651@codeblueprint.co.uk>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160218104407.GC2651@codeblueprint.co.uk>
 <CAKv+Gu_AW7PKJJOd2mbEu3LKJe+gNaPHnH=sgO=YXM_KWFyKxw@mail.gmail.com>
 <20160218132824.GE2651@codeblueprint.co.uk>
 <CAKv+Gu-s1pzYBzuDG-Z7s3gyo8dPOfeidZQ+rim-uAWZCBcKQQ@mail.gmail.com>
 <20160218134324.GG2651@codeblueprint.co.uk>
 <CAKv+Gu875r9RkDC723kNsG4XC0eSE9RPPmSFZrD0sx0QxS+V4g@mail.gmail.com>
 <20160218141544.GH2651@codeblueprint.co.uk>
Message-ID: <CAKv+Gu8RP21vw1Ht7UtkHsen2GMUNx8DikH-hLaezV+uZvWO-g@mail.gmail.com>

On 18 February 2016 at 15:15, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> On Thu, 18 Feb, at 02:44:02PM, Ard Biesheuvel wrote:
>> On 18 February 2016 at 14:43, Matt Fleming <matt at codeblueprint.co.uk> wrote:
>> > On Thu, 18 Feb, at 02:29:32PM, Ard Biesheuvel wrote:
>> >> On 18 February 2016 at 14:28, Matt Fleming <matt at codeblueprint.co.uk> wrote:
>> >> > On Thu, 18 Feb, at 01:16:05PM, Ard Biesheuvel wrote:
>> >> >> On 18 February 2016 at 11:44, Matt Fleming <matt at codeblueprint.co.uk> wrote:
>> >> >> > On Mon, 15 Feb, at 12:32:32PM, Ard Biesheuvel wrote:
>> >> >> >> On ARM and arm64, ioremap() and memremap() are not interchangeable like
>> >> >> >> on x86, and the use of ioremap() on ordinary RAM is typically flagged
>> >> >> >> as an error if the memory region being mapped is also covered by the
>> >> >> >> linear mapping, since that would lead to aliases with conflicting
>> >> >> >> cacheability attributes.
>> >> >> >>
>> >> >> >> Since what we are dealing with is not an I/O region with side effects,
>> >> >> >> using ioremap() here is arguably incorrect anyway, so let's replace
>> >> >> >> it with memremap instead. Also add a missing unmap on the success path,
>> >> >> >> and drop a memblock_remove() call which does not belong here, this far
>> >> >> >> into the boot sequence.
>> >> >> >>
>> >> >> >> Cc: Peter Jones <pjones at redhat.com>
>> >> >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> >> >> >> ---
>> >> >> >>  drivers/firmware/efi/esrt.c | 16 ++++++++--------
>> >> >> >>  1 file changed, 8 insertions(+), 8 deletions(-)
>> >> >> >>
>> >> >> >
>> >> >> > [...]
>> >> >> >
>> >> >> >> @@ -432,8 +434,6 @@ static int __init esrt_sysfs_init(void)
>> >> >> >>       if (error)
>> >> >> >>               goto err_cleanup_list;
>> >> >> >>
>> >> >> >> -     memblock_remove(esrt_data, esrt_data_size);
>> >> >> >> -
>> >> >> >>       pr_debug("esrt-sysfs: loaded.\n");
>> >> >> >>
>> >> >> >>       return 0;
>> >> >> >
>> >> >> > Shouldn't we be replacing memblock_remove() with free_bootmem_late()?
>> >> >> > The original ESRT region is still reserved at this point, so we should
>> >> >> > do our best to release it to the page allocator.
>> >> >>
>> >> >> I'd rather we keep it reserved. That way, the config table entry still
>> >> >> points to something valid, which could be useful for kexec(), I think?
>> >> >> At least, that is how I intended to handle config tables on ARM ...
>> >> >
>> >> > If we're going to reserve it why do we need to copy the data out at
>> >> > all in esrt_sysfs_init()?
>> >>
>> >> Excellent question. I don't think there is any point to doing that.
>> >
>> > ... Unless the data is contained in an EFI Boot Services region ;-)
>> >
>> > Peter?
>>
>> Yes, it usually is. Is that a problem?
>
> Yes, we free the Boot Services regions before hitting userspace on
> x86, see efi_free_boot_services(). We do this map/copy/unmap trick in
> the ACPI BGRT driver for that reason.
>
> The Boot Services regions can be many gigabytes in size, which makes
> leaving them alone impractical.
>
> For kexec on x86 we simply discard the BGRT table, which isn't the end
> of the world because who really needs access to the BGRT image on
> kexec reboot? However, I can see the value of preserving the ESRT.
>
> I guess we've got two options, 1) copy out the chunks of Boot Services
> regions we're interested in and rewrite the EFI tables to point at
> these new allocations and free/discard all of the original Boot
> Services regions or 2) only selectively free the Boot Services
> regions.
>
> I've always stayed clear of 2) in case there exists cross-region
> references in the data that isn't obvious. I'd like to think that
> would never happen, but, you know, dragons lurk here, etc.
>
> Though actually, now I think about it, cross-region references can't
> possibly exist because they'd cause issues with the current code.
>
> So maybe the best solution is actually 2), where we preserve the Boot
> Services regions if any of the drivers (ESRT, BGRT) request them but
> free all the others?
>
> What are the lifetime rules for Boot Services regions on arm*?

We treat all Boot Services regions like Loader Code/Data or free
regions: it is all recorded in memblock as usable memory, and only the
regions that are explicitly reserved are protected from further
general use.

I am currently looking into the memory attribute table, and the use
case is very similar. It would be very useful from our pov to simply
memblock_reserve() the region right after having called
efi_config_parse_tables(), and actually consume its data when we get
around to it later. The ESRT handling is already split down the middle
in the same way.


From robh at kernel.org  Thu Feb 18 06:36:23 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:36:23 -0600
Subject: [PATCH v5 3/4] soc: mediatek: Add MT2701 power dt-bindings
In-Reply-To: <1455692499-56828-4-git-send-email-jamesjj.liao@mediatek.com>
References: <1455692499-56828-1-git-send-email-jamesjj.liao@mediatek.com>
 <1455692499-56828-4-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <20160218143623.GI9654@rob-hp-laptop>

On Wed, Feb 17, 2016 at 03:01:38PM +0800, James Liao wrote:
> From: Shunli Wang <shunli.wang at mediatek.com>
> 
> Add power dt-bindings for MT2701.
> 
> Signed-off-by: Shunli Wang <shunli.wang at mediatek.com>
> Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
> ---
>  .../devicetree/bindings/soc/mediatek/scpsys.txt    |  6 +++--
>  include/dt-bindings/power/mt2701-power.h           | 27 ++++++++++++++++++++++
>  2 files changed, 31 insertions(+), 2 deletions(-)
>  create mode 100644 include/dt-bindings/power/mt2701-power.h
> 

Acked-by: Rob Herring <robh at kernel.org>


From nsekhar at ti.com  Thu Feb 18 06:21:43 2016
From: nsekhar at ti.com (Sekhar Nori)
Date: Thu, 18 Feb 2016 19:51:43 +0530
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <56BE1454.3030002@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com> <56BACCDB.2070507@ti.com>
 <alpine.DEB.2.02.1602111921090.20757@utopia.booyaka.com>
 <56BD8091.4090007@ti.com> <56BE1454.3030002@ti.com>
Message-ID: <56C5D377.50901@ti.com>

On Friday 12 February 2016 10:50 PM, Suman Anna wrote:
> Sekhar,
> Will you be following up with above suggestion since Kishon is gonna be out?

Alright, noticed this action for me :) Went through the thread, and 
looks like this is what we want to see?

Thanks,
Sekhar

---8<---
>From e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19 Mon Sep 17 00:00:00 2001
Message-Id: <e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19.1455803758.git.nsekhar at ti.com>
From: Sekhar Nori <nsekhar at ti.com>
Date: Thu, 18 Feb 2016 16:49:56 +0530
Subject: [PATCH 1/1] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS

Add a custom reset handler for DRA7x PCIeSS. This
handler is required to deassert PCIe hardreset lines
after they have been asserted.

This enables the PCIe driver to access registers after
PCIeSS has been runtime enabled without having to
deassert hardreset lines itself.

With this patch applied, used lspci to make sure
connected PCIe device enumerates on DRA74x and DRA72x
EVMs.

Signed-off-by: Sekhar Nori <nsekhar at ti.com>
---
Applies to tag for-v4.6/omap-hwmod-a of Paul W's tree.

 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index b61355e2a771..252b74633e31 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1526,8 +1526,31 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
  *
  */
 
+/*
+ * As noted in documentation for _reset() in omap_hwmod.c, the stock reset
+ * functionality of OMAP HWMOD layer does not deassert the hardreset lines
+ * associated with an IP automatically leaving the driver to handle that
+ * by itself. This does not work for PCIeSS which needs the reset lines
+ * deasserted for the driver to start accessing registers.
+ *
+ * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset
+ * lines after asserting them.
+ */
+static int dra7xx_pciess_reset(struct omap_hwmod *oh)
+{
+	int i;
+
+	for (i = 0; i < oh->rst_lines_cnt; i++) {
+		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);
+		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);
+	}
+
+	return 0;
+}
+
 static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {
 	.name	= "pcie",
+	.reset	= dra7xx_pciess_reset,
 };
 
 /* pcie1 */
-- 
2.6.3




From robh at kernel.org  Thu Feb 18 06:36:39 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:36:39 -0600
Subject: [PATCH v3] dts/ls2080a: Update PCIe compatible
In-Reply-To: <1455674663-9273-1-git-send-email-Mingkai.Hu@freescale.com>
References: <1455674663-9273-1-git-send-email-Mingkai.Hu@freescale.com>
Message-ID: <20160218143639.GK9654@rob-hp-laptop>

On Wed, Feb 17, 2016 at 10:04:23AM +0800, Mingkai Hu wrote:
> From: Minghuan Lian <minghuan.lian at nxp.com>
> 
> The patch adds LS2085a to PCIe compatible to fix the compatibility
> issue when using firmware with LS2085a compatible property.
> 
> Signed-off-by: Minghuan Lian <minghuan.lian at nxp.com>
> Signed-off-by: Mingkai Hu <mingkai.hu at nxp.com>
> ---
> v3:
>  - Make the compatible consistent between layerscape-pci.txt
>    and dts file.
> 
> v2:
>   - Rebased to latest kernel base
> 
>  Documentation/devicetree/bindings/pci/layerscape-pci.txt |  2 +-
>  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi           | 12 ++++++++----
>  2 files changed, 9 insertions(+), 5 deletions(-)
> 

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Thu Feb 18 06:36:33 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:36:33 -0600
Subject: [PATCH 1/2] dt-bindings: Add LG lp120up1 panel bindings
In-Reply-To: <1455691839-2410-1-git-send-email-jitao.shi@mediatek.com>
References: <1455691839-2410-1-git-send-email-jitao.shi@mediatek.com>
Message-ID: <20160218143633.GJ9654@rob-hp-laptop>

On Wed, Feb 17, 2016 at 02:50:38PM +0800, Jitao Shi wrote:
> Add documentation for lp120up1 panel
> 
> Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> ---
>  .../bindings/display/panel/lg,lp120up1.txt         |    7 +++++++
>  1 file changed, 7 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt

Acked-by: Rob Herring <robh at kernel.org>


From javi.merino at arm.com  Thu Feb 18 06:28:34 2016
From: javi.merino at arm.com (Javi Merino)
Date: Thu, 18 Feb 2016 14:28:34 +0000
Subject: [PATCH 2/3] thermal: Add Mediatek thermal controller support
In-Reply-To: <20160218105603.GE3939@pengutronix.de>
References: <1448883753-19068-1-git-send-email-s.hauer@pengutronix.de>
 <1448883753-19068-3-git-send-email-s.hauer@pengutronix.de>
 <20151217193332.GB7999@localhost.localdomain>
 <20160104141940.GI13058@pengutronix.de>
 <20160119072917.GA13237@pengutronix.de>
 <1454295246.22151.6.camel@mtksdaap41>
 <CAGS+omD9U8tKmb02d_gMMAGX18MJZhz0RrugpBK2EuqgZrBy6g@mail.gmail.com>
 <CAGS+omArr0_-ziBXWjEcKS0bqnruNzZc2aq2s3zkghUC7_HfGw@mail.gmail.com>
 <56C4A875.6080908@gmail.com> <20160218105603.GE3939@pengutronix.de>
Message-ID: <20160218142833.GB2943@e104805>

Hi Sascha,

On Thu, Feb 18, 2016 at 11:56:03AM +0100, Sascha Hauer wrote:
> On Wed, Feb 17, 2016 at 06:05:57PM +0100, Matthias Brugger wrote:
> > On 15/02/16 03:14, Daniel Kurtz wrote:
> > >On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz at chromium.org> wrote:
> > >>Hi Eduardo, Sascha,
> > >>
> > >>>>Any input on this? I really like to get this driver upstream as it is
> > >>>>currently blocking other Mediatek drivers.
> > >>>>
> > >>>
> > >>>Hi Eduardo,
> > >>>
> > >>>Do you have any comment about Sascha's response ? We really hope get
> > >>>your comment since Mediatek thermal driver already reviewed in public
> > >>>over half years, and we have other patches [0] [1] depend on thermal
> > >>>driver.
> > >>>
> > >>>[0]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> > >>>[1]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
> > >>
> > >>Friendly ping on the Mediatek thermal driver.
> > >>The "EFUSE" dependency has now landed in v4.5-rc4.
> > >
> > >Actually, it landed in char-misc-next, not v4.5-rc4.
> > >
> > >>So, AFAICT, the only thing left that may be blocking landing Mediatek
> > >>thermal driver is resolution of this discussion about thermal zones.
> > >>Can we kindly resolve this soon so we have a chance to land it in v4.6.
> > >>
> > 
> > 
> > I think the problem is, that Eduardo wants to see the hierachical thermal
> > zones being used. But there is still a discussion ongoing [1].
> 
> It seems the original Author lost interest in the hierarchical thermal
> zones. I am not convinced that we need hierarchical thermal zones for
> the Mediatek driver since from the five sensors we only need the maximum
> temperature (If this ever changes we could still rework it).

I guess that "the original Author" refers to me.  I haven't lost
interest in the hierarchical thermal zones, I just don't have time to
work on it currently.  I'd like to address your review at some point
in the future and continue working on it.
 
> Given the current speed of communication I am not willing to add
> another, possibly controversal, dependency to an otherwise simple
> driver. I am even less willing when concerns like these come after *v12*
> of this series.

I agree.  I don't think we should make this driver depend on the
hierarchical thermal zones series.  When hierarchical thermal zones
get merged we can consider to change the driver to use them but
there's no point in waiting for that to happen.

Cheers,
Javi




From robh at kernel.org  Thu Feb 18 06:36:48 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:36:48 -0600
Subject: [PATCH 5/6] dt-bindings: add documentation of rk3399 clock
 controller
In-Reply-To: <1455674089-16567-1-git-send-email-jay.xu@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <1455674089-16567-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <20160218143648.GL9654@rob-hp-laptop>

On Wed, Feb 17, 2016 at 09:54:49AM +0800, jianqun.xu wrote:
> From: Xing Zheng <zhengxing at rock-chips.com>
> 
> Add the devicetree binding for the cru on the rk3399 which quite
> similar structured as previous clock controllers.
> 
> Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
> ---
>  .../bindings/clock/rockchip,rk3399-cru.txt         | 82 ++++++++++++++++++++++
>  1 file changed, 82 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
> new file mode 100644
> index 0000000..07bcc6e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
> @@ -0,0 +1,82 @@
> +* Rockchip RK3399 Clock and Reset Unit

[...]

> +Example: General Register Files
> +
> +	pmugrf: syscon at ff320000 {
> +		compatible = "rockchip,rk3399-pmugrf", "syscon";

Is this documented?

> +		reg = <0x0 0xff320000 0x0 0x1000>;
> +	};
> +
> +	grf: syscon at ff770000 {
> +		compatible = "rockchip,rk3399-grf", "syscon";

ditto.

> +		reg = <0x0 0xff770000 0x0 0x10000>;
> +	};
> +
> +Example: Clock controller node:
> +
> +	pmucru: pmu-clock-controller at ff750000 {
> +		compatible = "rockchip,rk3399-pmucru";
> +		reg = <0x0 0xff750000 0x0 0x1000>;
> +		#clock-cells = <1>;
> +		#reset-cells = <1>;
> +	};
> +
> +	cru: clock-controller at ff760000 {
> +		compatible = "rockchip,rk3399-cru";
> +		reg = <0x0 0xff760000 0x0 0x1000>;
> +		rockchip,grf = <&grf>;
> +		#clock-cells = <1>;
> +		#reset-cells = <1>;
> +	};
> +
> +Example: UART controller node that consumes the clock generated by the clock
> +  controller:
> +
> +	uart0: serial at ff1a0000 {
> +		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xff180000 0x0 0x100>;
> +		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
> +		clock-names = "baudclk", "apb_pclk";
> +		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
> +		reg-shift = <2>;
> +		reg-io-width = <4>;
> +	};
> -- 
> 1.9.1
> 
> 


From catalin.marinas at arm.com  Thu Feb 18 06:36:48 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 18 Feb 2016 14:36:48 +0000
Subject: [PATCH v2 5/5] arm64: kernel: Don't toggle PAN on systems with UAO
In-Reply-To: <1454684330-892-6-git-send-email-james.morse@arm.com>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
 <1454684330-892-6-git-send-email-james.morse@arm.com>
Message-ID: <20160218143648.GC2538@e104818-lin.cambridge.arm.com>

On Fri, Feb 05, 2016 at 02:58:50PM +0000, James Morse wrote:
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -234,6 +234,9 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
>  	}
>  
>  	if (permission_fault(esr) && (addr < USER_DS)) {
> +		if (get_thread_info(regs->sp)->addr_limit == KERNEL_DS)
> +			panic("Accessing user space memory with fs=KERNEL_DS");

We could simply use "get_fs() == KERNEL_DS" as we should call
do_page_fault() outside the current context.

-- 
Catalin


From robh at kernel.org  Thu Feb 18 06:37:02 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:37:02 -0600
Subject: [PATCH 3/6] ASoC: rockchip: add bindings for rk3399 i2s
In-Reply-To: <20160217110306.GJ7544@sirena.org.uk>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <1455673992-16469-4-git-send-email-jay.xu@rock-chips.com>
 <20160217110306.GJ7544@sirena.org.uk>
Message-ID: <20160218143702.GN9654@rob-hp-laptop>

On Wed, Feb 17, 2016 at 11:03:06AM +0000, Mark Brown wrote:
> On Wed, Feb 17, 2016 at 09:53:09AM +0800, jianqun.xu wrote:
> 
> > ---
> >  Documentation/devicetree/bindings/sound/rockchip-i2s.txt | 1 +
> >  1 file changed, 1 insertion(+)
> 
> As with the other patch I'd expect to see a matching driver update if
> only for documentation purposes.

Why? They match on the prior chip's compatible until there is some 
difference the driver needs to handle.

Rob


From robh at kernel.org  Thu Feb 18 06:36:53 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:36:53 -0600
Subject: [PATCH 3/6] ASoC: rockchip: add bindings for rk3399 i2s
In-Reply-To: <1455673992-16469-4-git-send-email-jay.xu@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <1455673992-16469-4-git-send-email-jay.xu@rock-chips.com>
Message-ID: <20160218143653.GM9654@rob-hp-laptop>

On Wed, Feb 17, 2016 at 09:53:09AM +0800, jianqun.xu wrote:
> From: Xu Jianqun <jay.xu at rock-chips.com>
> 
> Add devicetree bindings for i2s controller found on rk3399
> processors from rockchip.
> 
> Signed-off-by: Xu Jianqun <jay.xu at rock-chips.com>
> ---
>  Documentation/devicetree/bindings/sound/rockchip-i2s.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Thu Feb 18 06:37:07 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:37:07 -0600
Subject: [PATCH 2/6] spi: rockchip: add bindings for rk3399 spi
In-Reply-To: <1455673992-16469-3-git-send-email-jay.xu@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <1455673992-16469-3-git-send-email-jay.xu@rock-chips.com>
Message-ID: <20160218143707.GO9654@rob-hp-laptop>

On Wed, Feb 17, 2016 at 09:53:08AM +0800, jianqun.xu wrote:
> From: Xu Jianqun <jay.xu at rock-chips.com>
> 
> Add devicetree bindings for Rockchip rk3399 spi which found on
> Rockchip rk3399 SoCs.
> 
> Signed-off-by: Xu Jianqun <jay.xu at rock-chips.com>
> ---
>  Documentation/devicetree/bindings/spi/spi-rockchip.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <robh at kernel.org>


From linux at arm.linux.org.uk  Thu Feb 18 06:37:09 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Feb 2016 14:37:09 +0000
Subject: [PATCH 2/9] ARM: change NR_IPIS to 8
In-Reply-To: <1455804123-2526139-3-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-3-git-send-email-arnd@arndb.de>
Message-ID: <20160218143709.GQ19428@n2100.arm.linux.org.uk>

On Thu, Feb 18, 2016 at 03:01:54PM +0100, Arnd Bergmann wrote:
> When function tracing for IPIs is enabled, we get a warning for an
> overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
> as triggered by raise_nmi():
> 
> arch/arm/kernel/smp.c: In function 'raise_nmi':
> arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds [-Werror=array-bounds]
>   trace_ipi_raise(target, ipi_types[ipinr]);

We really don't want to treat the backtrace IPI as a normal IPI at all -
we want it to invoke the least amount of code possible.  Hence this code
which avoids the issue:

        if ((unsigned)ipinr < NR_IPI) {
                trace_ipi_entry_rcuidle(ipi_types[ipinr]);
                __inc_irq_stat(cpu, ipi_irqs[ipinr]);
        }

However, what's missing is that the addition of tracing here missed
that CPU_BACKTRACE is not to be traced.  The call in raise_nmi()
should have been converted to __smp_cross_call() to avoid the
tracing code.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From robh at kernel.org  Thu Feb 18 06:38:08 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:38:08 -0600
Subject: [PATCH v5 1/1] USB: core: let USB device know device node
In-Reply-To: <1455612172-2081-1-git-send-email-peter.chen@nxp.com>
References: <1455612172-2081-1-git-send-email-peter.chen@nxp.com>
Message-ID: <20160218143808.GY9654@rob-hp-laptop>

On Tue, Feb 16, 2016 at 04:42:52PM +0800, Peter Chen wrote:
> From: Peter Chen <peter.chen at freescale.com>
> 
> Although most of USB devices are hot-plug's, there are still some devices
> are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
> If these kinds of USB devices are multiple functions, and they can supply
> other interfaces like i2c, gpios for other devices, we may need to
> describe these at device tree.
> 
> In this commit, it uses "reg" in dts as physical port number to match
> the phyiscal port number decided by USB core, if they are the same,
> then the device node is for the device we are creating for USB core.
> 
> Signed-off-by: Peter Chen <peter.chen at freescale.com>
> ---
> Changes for v5:
> - Refine the code how to get the device node at usb_alloc_dev according
>   to Alan's comment.
> - Point out "usbVID,PID" is the recommented compatible, and others
>   compatibles at binding doc could also be used.
> 
> Changes for v4:
> - The range of "reg" should be 1-31, changing device node address
>   style as in lower case hexadecimal with leading zeroes suppressed
>   [binding doc, usb-device.txt]
> - Improve the example at binding doc, it describes node from the top
>   (the controller)
> - Delete the struct of_node * within struct usb_device
> - Using usb_hcd_find_raw_port_number to get raw port number under root
>   hub port
> 
> Changes for v3:
> - typo: s/descirbe/describe/
> 
> Changes for v2:
> - Fix build error reported by kbuild robot, lack of "static" for
>   inline usb_of_get_child_node
> - Fix typo, "devcie_node" -> "device_node"
> - Add kernel-doc for of_node at struct usb_device
> 
> Changes from RFC:
> - Fix the error address for binding doc, and add compatible for binding doc
> - Change get child node API from "usb_of_find_node" to
>   "usb_of_get_child_node"
> - Delete unecessary header files
> - One typo
> 
>  .../devicetree/bindings/usb/usb-device.txt         | 26 ++++++++++++

Looks good to me. Thanks for driving this to completion.

Acked-by: Rob Herring <robh at kernel.org>

>  drivers/usb/core/Makefile                          |  2 +-
>  drivers/usb/core/of.c                              | 47 ++++++++++++++++++++++
>  drivers/usb/core/usb.c                             | 10 +++++
>  include/linux/usb/of.h                             |  7 ++++
>  5 files changed, 91 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/usb-device.txt
>  create mode 100644 drivers/usb/core/of.c
> 


From robh at kernel.org  Thu Feb 18 06:38:15 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:38:15 -0600
Subject: [PATCH 3/5] dt-bindings: phy: bindings document for common
 Broadcom SATA3 PHY driver
In-Reply-To: <1455604420-11300-4-git-send-email-anup.patel@broadcom.com>
References: <1455604420-11300-1-git-send-email-anup.patel@broadcom.com>
 <1455604420-11300-4-git-send-email-anup.patel@broadcom.com>
Message-ID: <20160218143815.GZ9654@rob-hp-laptop>

On Tue, Feb 16, 2016 at 12:03:38PM +0530, Anup Patel wrote:
> This patch:
> 1. Renames DT bindings document of Broadcom STB SATA3 PHY driver to
> common Broadcom SATA3 PHY driver bindings document
> 2. Adds bindings info for NS2 SATA3 PHY
> 
> Signed-off-by: Anup Patel <anup.patel at broadcom.com>
> ---
>  .../phy/{brcm,brcmstb-sata-phy.txt => brcm-sata-phy.txt}  | 15 +++++++++------
>  1 file changed, 9 insertions(+), 6 deletions(-)
>  rename Documentation/devicetree/bindings/phy/{brcm,brcmstb-sata-phy.txt => brcm-sata-phy.txt} (69%)
> 
> diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-sata-phy.txt b/Documentation/devicetree/bindings/phy/brcm-sata-phy.txt
> similarity index 69%
> rename from Documentation/devicetree/bindings/phy/brcm,brcmstb-sata-phy.txt
> rename to Documentation/devicetree/bindings/phy/brcm-sata-phy.txt
> index d87ab7c..d023120 100644
> --- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-sata-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/brcm-sata-phy.txt
> @@ -1,14 +1,17 @@
> -* Broadcom SATA3 PHY for STB
> +* Broadcom SATA3 PHY
>  
>  Required properties:
>  - compatible: should be one or more of
>       "brcm,bcm7425-sata-phy"
>       "brcm,bcm7445-sata-phy"
> +     "brcm,iproc-ns2-sata-phy"
>       "brcm,phy-sata3"
>  - address-cells: should be 1
>  - size-cells: should be 0
> -- reg: register range for the PHY PCB interface
> -- reg-names: should be "phy"
> +- reg: register ranges for the PHY PCB interface
> +- reg-names: should be "phy" and "phy-ctrl"
> +     The "phy-ctrl" registers are only required for
> +     "brcm,iproc-ns2-sata-phy".
>  
>  Sub-nodes:
>    Each port's PHY should be represented as a sub-node.
> @@ -16,12 +19,12 @@ Sub-nodes:
>  Sub-nodes required properties:
>  - reg: the PHY number
>  - phy-cells: generic PHY binding; must be 0
> -Optional:
> -- brcm,enable-ssc: use spread spectrum clocking (SSC) on this port
>  
> +Sub-nodes optional properties:
> +- brcm,enable-ssc: use spread spectrum clocking (SSC) on this port
> +     This property is not applicable for "brcm,iproc-ns2-sata-phy".

My understanding of SSC is it is required for hosts and optional for 
drives to support (from first hand experience of a host not enabling). 
Not setting this is would not be compliant. The polarity on this is 
somewhat backwards too as the common case should be no property.

Anyway, that's all besides the point of your change. I assume it doesn't 
apply here for you because it is always enabled. 

Acked-by: Rob Herring <robh at kernel.org>

Rob


From robh at kernel.org  Thu Feb 18 06:38:19 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:38:19 -0600
Subject: [PATCH 4/5] dt-bindings: ata: add compatible string for iProc
 AHCI controller
In-Reply-To: <1455604420-11300-5-git-send-email-anup.patel@broadcom.com>
References: <1455604420-11300-1-git-send-email-anup.patel@broadcom.com>
 <1455604420-11300-5-git-send-email-anup.patel@broadcom.com>
Message-ID: <20160218143819.GA9654@rob-hp-laptop>

On Tue, Feb 16, 2016 at 12:03:39PM +0530, Anup Patel wrote:
> The Broadcom iProc SoCs have AHCI compliant SATA controller. This
> patch adds common compatible string for AHCI SATA controller on
> iProc SoCs.
> 
> Signed-off-by: Anup Patel <anup.patel at broadcom.com>
> ---
>  Documentation/devicetree/bindings/ata/ahci-platform.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Thu Feb 18 06:38:26 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:38:26 -0600
Subject: [PATCH/RFC v2 01/11] PM / Domains: Add DT bindings for the R-Car
 System Controller
In-Reply-To: <1455571020-18968-2-git-send-email-geert+renesas@glider.be>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
 <1455571020-18968-2-git-send-email-geert+renesas@glider.be>
Message-ID: <20160218143826.GB9654@rob-hp-laptop>

On Mon, Feb 15, 2016 at 10:16:50PM +0100, Geert Uytterhoeven wrote:
> The Renesas R-Car System Controller provides power management for the
> CPU cores and various coprocessors, following the generic PM domain
> bindings in Documentation/devicetree/bindings/power/power_domain.txt.
> 
> This supports R-Car Gen1, Gen2, and Gen3.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> ---
> Alternatives I considered:
> 
>   - Using a single node per power register block, even if it contains
>     multiple domains, e.g.:
> 
> 	    pd_ca15_scu: ca15_scu at 180 {
> 		    reg = <0x180 0x20>;
> 		    #address-cells = <1>;
> 		    #size-cells = <0>;
> 		    #power-domain-cells = <0>;
> 		    renesas,interrupt-bits = <12>;
> 
> 		    pd_ca15_cpu: ca15_cpu at 40 {
> 			    reg = <0x40 0x20>;
> 			    #power-domain-cells = <1>;
> 			    renesas,pm-domain-indices = <0 1>;
> 			    renesas,pm-domain-names =
> 				    "ca15_cpu0", "ca15_cpu1";
> 			    renesas,interrupt-bits = <0 1>;
> 		    };
> 	    };
> 
>     Notes:
>       - You cannot just have a property with the number of domains, as
> 	index 0 is not used on R-Car H1. Hence the need for
> 	"renesas,pm-domain-indices" and "renesas,interrupt-bits",
>       - "#power-domain-cells = <1>" for nodes with multiple domains,
> 	which allows typos in "power-domains = <&pd_ca15_cpu n>", using
> 	an invalid value of "n".
> 
>   - Using a linear description in DT:
>       - Needs parent links for subdomains,
>       - More complicated to parse (lesson learned from R-Mobile PM
> 	Domain support).
> 
>   - Keeping the power register block offset and the bit number as separate
>     "reg" cells, increasing "#address-cells" from 2 to 3,
> 
>   - Merging the interrupt bit (which needs only 5 bits) in the other "reg"
>     cell, decreasing "#address-cells" from 2 to 1.

I think I'd move to not encoding mulitple things into reg. This seems 
like a bit of abuse of reg. Otherwise, I don't have much to comment on.

Rob


From matt at codeblueprint.co.uk  Thu Feb 18 06:38:25 2016
From: matt at codeblueprint.co.uk (Matt Fleming)
Date: Thu, 18 Feb 2016 14:38:25 +0000
Subject: [PATCH v2 1/2] efi: esrt: use memremap not ioremap to access
 ESRT table in memory
In-Reply-To: <CAKv+Gu8RP21vw1Ht7UtkHsen2GMUNx8DikH-hLaezV+uZvWO-g@mail.gmail.com>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160218104407.GC2651@codeblueprint.co.uk>
 <CAKv+Gu_AW7PKJJOd2mbEu3LKJe+gNaPHnH=sgO=YXM_KWFyKxw@mail.gmail.com>
 <20160218132824.GE2651@codeblueprint.co.uk>
 <CAKv+Gu-s1pzYBzuDG-Z7s3gyo8dPOfeidZQ+rim-uAWZCBcKQQ@mail.gmail.com>
 <20160218134324.GG2651@codeblueprint.co.uk>
 <CAKv+Gu875r9RkDC723kNsG4XC0eSE9RPPmSFZrD0sx0QxS+V4g@mail.gmail.com>
 <20160218141544.GH2651@codeblueprint.co.uk>
 <CAKv+Gu8RP21vw1Ht7UtkHsen2GMUNx8DikH-hLaezV+uZvWO-g@mail.gmail.com>
Message-ID: <20160218143825.GI2651@codeblueprint.co.uk>

On Thu, 18 Feb, at 03:21:25PM, Ard Biesheuvel wrote:
> 
> We treat all Boot Services regions like Loader Code/Data or free
> regions: it is all recorded in memblock as usable memory, and only the
> regions that are explicitly reserved are protected from further
> general use.
> 
> I am currently looking into the memory attribute table, and the use
> case is very similar. It would be very useful from our pov to simply
> memblock_reserve() the region right after having called
> efi_config_parse_tables(), and actually consume its data when we get
> around to it later. The ESRT handling is already split down the middle
> in the same way.

Agreed, this would also be useful in general for kexec. I've got a
couple of patches in flight that try to handle the BGRT case in a
different way,

  https://lkml.kernel.org/r/1455723910-16710-2-git-send-email-matt at codeblueprint.co.uk
  https://lkml.kernel.org/r/1455723910-16710-3-git-send-email-matt at codeblueprint.co.uk

Let me instead take a look at how we might be able to preserve only
those Boot Services regions we care out.


From robh at kernel.org  Thu Feb 18 06:38:31 2016
From: robh at kernel.org (Rob Herring)
Date: Thu, 18 Feb 2016 08:38:31 -0600
Subject: [PATCH v2 1/4] dma: mmp_pdma: Add the #dma-requests DT property
 documentation
In-Reply-To: <1455569868-25017-1-git-send-email-robert.jarzmik@free.fr>
References: <1455569868-25017-1-git-send-email-robert.jarzmik@free.fr>
Message-ID: <20160218143831.GC9654@rob-hp-laptop>

On Mon, Feb 15, 2016 at 09:57:45PM +0100, Robert Jarzmik wrote:
> For pxa based platforms, the number of requestor lines should be
> specified, so that the driver can check if the flow control should be
> activated (when a requestor line is asked for) or not.
> 
> Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
> ---
> Since v1: rename of property to #dma-requests
>       	  modify default value to 32 as suggested by Vinod
> ---
>  Documentation/devicetree/bindings/dma/mmp-dma.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh at kernel.org>


From arnd at arndb.de  Thu Feb 18 06:40:34 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 15:40:34 +0100
Subject: [PATCH 1/3] irqchip: gic/realview: support more RealView DCC
 variants
In-Reply-To: <56C5D304.5010708@arm.com>
References: <1455803172-22747-1-git-send-email-linus.walleij@linaro.org>
 <56C5D304.5010708@arm.com>
Message-ID: <5028476.WAQS3ylXOd@wuerfel>

On Thursday 18 February 2016 14:19:48 Marc Zyngier wrote:
> On 18/02/16 13:46, Linus Walleij wrote:
> > In the add-on file for the GIC dealing with the RealView family
> > we currently only handle the PB11MPCore, let's extend this to
> > manage the RealView EB ARM11MPCore as well. The Revision B of the
> > ARM11MPCore core tile is a bit special and needs special handling
> > as it moves a system control register around at random.
> 
> Ah, 11MPCore RevB. That thing. Tried to locate one in the magic
> cupboard, and failed. Oh well...

What surprised me though is that it's enabled by default:

$ grep REVB arch/arm/configs/realview*
arch/arm/configs/realview_defconfig:CONFIG_REALVIEW_EB_ARM11MP_REVB=y
arch/arm/configs/realview-smp_defconfig:CONFIG_REALVIEW_EB_ARM11MP_REVB=y

With that option set, the defconfig kernel should not be able
to boot on RevC machines. Do you have a RevC machine that works
with the defconfig?

	Arnd


From arnd at arndb.de  Thu Feb 18 06:41:45 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 15:41:45 +0100
Subject: [PATCH] PCI: mvebu: Restrict build to 32-bit ARM
In-Reply-To: <87egcaqe89.fsf@free-electrons.com>
References: <1455802330-17565-1-git-send-email-thierry.reding@gmail.com>
 <5051836.EUN3ennYNm@wuerfel> <87egcaqe89.fsf@free-electrons.com>
Message-ID: <2551766.4Kx1a2F3t1@wuerfel>

On Thursday 18 February 2016 15:34:30 Gregory CLEMENT wrote:
>  On jeu., f?vr. 18 2016, Arnd Bergmann <arnd at arndb.de> wrote:
> 
> > On Thursday 18 February 2016 14:32:10 Thierry Reding wrote:
> >> From: Thierry Reding <treding at nvidia.com>
> >> 
> >> This driver uses PCI glue that is only available on 32-bit ARM. This
> >> used to work fine as long as ARCH_MVEBU and ARCH_DOVE were exclusively
> >> 32-bit, but that's changed now, with ARCH_MVEBU also being available
> >> on 64-bit ARM.
> >> 
> >> Signed-off-by: Thierry Reding <treding at nvidia.com>
> >
> > Looks fine as a temporary workaround, but I think what we really want to
> > do here is to remove the dependency, as the new ARM64 platforms are going
> > to need this driver anyway.
> 
> Actually the mvebu ARM64 platform we know about (Armada 3700, 7K and
> 8K), won't use the same controller. A7K/A8K will use a synopsis IP and
> Armada 3700 a new Marvell IP.
> 
> So for me depending on ARM32 is enough.

Ah, that makes things much easier indeed.

Does this mean no more MBUS on the 64-bit platforms too?

	Arnd


From james.morse at arm.com  Thu Feb 18 06:43:48 2016
From: james.morse at arm.com (James Morse)
Date: Thu, 18 Feb 2016 14:43:48 +0000
Subject: [PATCH v2 5/5] arm64: kernel: Don't toggle PAN on systems with UAO
In-Reply-To: <20160218143648.GC2538@e104818-lin.cambridge.arm.com>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
 <1454684330-892-6-git-send-email-james.morse@arm.com>
 <20160218143648.GC2538@e104818-lin.cambridge.arm.com>
Message-ID: <56C5D8A4.8070505@arm.com>

Hi Catalin,

On 18/02/16 14:36, Catalin Marinas wrote:
> On Fri, Feb 05, 2016 at 02:58:50PM +0000, James Morse wrote:
>> --- a/arch/arm64/mm/fault.c
>> +++ b/arch/arm64/mm/fault.c
>> @@ -234,6 +234,9 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
>>  	}
>>  
>>  	if (permission_fault(esr) && (addr < USER_DS)) {
>> +		if (get_thread_info(regs->sp)->addr_limit == KERNEL_DS)
>> +			panic("Accessing user space memory with fs=KERNEL_DS");
> 
> We could simply use "get_fs() == KERNEL_DS" as we should call
> do_page_fault() outside the current context.

shouldn't?

You're right, it will always be on the same stack, so get_fs() will give us the
right result. This fits better with getting rid of the new get_thread_info() in
patch 3.


Thanks,

James



From marc.zyngier at arm.com  Thu Feb 18 06:47:13 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Feb 2016 14:47:13 +0000
Subject: [PATCH 1/3] irqchip: gic/realview: support more RealView DCC
 variants
In-Reply-To: <5028476.WAQS3ylXOd@wuerfel>
References: <1455803172-22747-1-git-send-email-linus.walleij@linaro.org>
 <56C5D304.5010708@arm.com> <5028476.WAQS3ylXOd@wuerfel>
Message-ID: <56C5D971.6060005@arm.com>

On 18/02/16 14:40, Arnd Bergmann wrote:
> On Thursday 18 February 2016 14:19:48 Marc Zyngier wrote:
>> On 18/02/16 13:46, Linus Walleij wrote:
>>> In the add-on file for the GIC dealing with the RealView family
>>> we currently only handle the PB11MPCore, let's extend this to
>>> manage the RealView EB ARM11MPCore as well. The Revision B of the
>>> ARM11MPCore core tile is a bit special and needs special handling
>>> as it moves a system control register around at random.
>>
>> Ah, 11MPCore RevB. That thing. Tried to locate one in the magic
>> cupboard, and failed. Oh well...
> 
> What surprised me though is that it's enabled by default:
> 
> $ grep REVB arch/arm/configs/realview*
> arch/arm/configs/realview_defconfig:CONFIG_REALVIEW_EB_ARM11MP_REVB=y
> arch/arm/configs/realview-smp_defconfig:CONFIG_REALVIEW_EB_ARM11MP_REVB=y
> 
> With that option set, the defconfig kernel should not be able
> to boot on RevC machines. Do you have a RevC machine that works
> with the defconfig?

No, it looks like someone helped themselves to *all* of the EB-11MPs - I
have a bunch of empty baseboards, and no tile to slap on. I also have a
box of unsoldered 11MPs, but that a different story... ;-)

I guess I should plan for another dumpster diving session.

	M.
-- 
Jazz is not dead. It just smells funny...


From shawnguo at kernel.org  Thu Feb 18 06:47:59 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 18 Feb 2016 22:47:59 +0800
Subject: [PATCH] i.MX SPI DMA cleanup
In-Reply-To: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
References: <1455715739-25161-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <20160218144759.GB6756@tiger>

On Wed, Feb 17, 2016 at 02:28:46PM +0100, Sascha Hauer wrote:
> Shawn, please pick up the last patch. The rest can go through the SPI
> tree. The last patch has no dependency on the remaining patches.

Okay, patch #13 applied.


From blogic at openwrt.org  Thu Feb 18 06:50:10 2016
From: blogic at openwrt.org (John Crispin)
Date: Thu, 18 Feb 2016 15:50:10 +0100
Subject: [PATCH V6 1/2] regulator: Add document for MT6323 regulator
In-Reply-To: <20160218143610.GG9654@rob-hp-laptop>
References: <1455709056-50510-1-git-send-email-blogic@openwrt.org>
 <20160218143610.GG9654@rob-hp-laptop>
Message-ID: <56C5DA22.9080008@openwrt.org>



On 18/02/2016 15:36, Rob Herring wrote:
> On Wed, Feb 17, 2016 at 12:37:35PM +0100, John Crispin wrote:
>> Signed-off-by: John Crispin <blogic at openwrt.org>
>> Cc: devicetree at vger.kernel.org
>>
>> ---
>> Changes in V6
>> * remove the compatible string
>>
>> Changes in V5
>> * regulator vs regulators
>>
>> Changes in V4
>> * regulator is a subnode and not a property
>>
>>  .../bindings/regulator/mt6323-regulator.txt        |  241 ++++++++++++++++++++
>>  1 file changed, 241 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
>>
>> diff --git a/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
>> new file mode 100644
>> index 0000000..67c0780
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
>> @@ -0,0 +1,241 @@
>> +Mediatek MT6323 Regulator Driver
>> +
>> +All voltage regulators are defined as subnodes of the regulators node. A list
>> +of regulators provided by this controller are defined as subnodes of the
>> +drivers node. Each regulator is named according to its regulator type,
> 
> s/drivers/PMIC's/
> 
>> +buck_<name> and ldo_<name>. The definition for each of these nodes is defined
>> +using the standard binding for regulators at
>> +Documentation/devicetree/bindings/regulator/regulator.txt.
>> +
>> +The valid names for regulators are::
>> +BUCK:
>> +  buck_vproc, buck_vsys, buck_vpa
>> +LDO:
>> +  ldo_vtcxo, ldo_vcn28, ldo_vcn33_bt, ldo_vcn33_wifi, ldo_va, ldo_vcama,
>> +  ldo_vio28, ldo_vusb, ldo_vmc, ldo_vmch, ldo_vemc3v3, ldo_vgp1, ldo_vgp2,
>> +  ldo_vgp3, ldo_vcn18, ldo_vsim1, ldo_vsim2, ldo_vrtc, ldo_vcamaf, ldo_vibr,
>> +  ldo_vrf18, ldo_vm, ldo_vio18, ldo_vcamd, ldo_vcamio
>> +
>> +Example:
>> +
>> +	pmic: mt6323 {
>> +		compatible = "mediatek,mt6323";
>> +
>> +		mt6323regulator: regulators {
>> +			compatible = "mediatek,mt6323-regulator";
> 
> Still have the compatible here...
> 
> Otherwise:
> 
> Acked-by: Rob Herring <robh at kernel.org>
> 

grml, i only removed one of the compat strings and did not notice there
are two. do you want me to send a fixup that you can fold into the one
you already merged or do you want me to resend just this one patch with
the fix applied ?

	John


> 
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
> 


From shawnguo at kernel.org  Thu Feb 18 06:57:40 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 18 Feb 2016 22:57:40 +0800
Subject: [PATCH] ARM: imx: Do L2 errata only if the L2 cache isn't enabled
In-Reply-To: <56C03B0E.9000809@gmail.com>
References: <1455261093-11849-1-git-send-email-dirk.behme@de.bosch.com>
 <20160212141654.GA10826@n2100.arm.linux.org.uk>
 <56BDFF64.9090701@gmail.com> <20160214081857.GQ6756@tiger>
 <56C03B0E.9000809@gmail.com>
Message-ID: <20160218145739.GC6756@tiger>

On Sun, Feb 14, 2016 at 09:30:06AM +0100, Dirk Behme wrote:
> On 14.02.2016 09:18, Shawn Guo wrote:
> >On Fri, Feb 12, 2016 at 04:51:00PM +0100, Dirk Behme wrote:
> >>On 12.02.2016 15:16, Russell King - ARM Linux wrote:
> >>>On Fri, Feb 12, 2016 at 08:11:33AM +0100, Dirk Behme wrote:
> >>>>All the generic L2 cache handling code is encapsulated by a
> >>>>check if the L2 cache is enabled. If it's enabled already, the code
> >>>>is skipped.
> >>>>
> >>>>For the i.MX6 specific L2 cache handling we missed this check.
> >>>>Add it.
> >>>
> >>>What's the reasoning behind this?  The prefetch register is writable
> >>>while the L2 cache is enabled, unlike the auxiliary control register.
> >>
> >> From an internal log I have the following info:
> >>
> >>The write to the L2-Cache controller from non-secure world causes an
> >>imprecise
> >>external abort. If Linux runs from normal world the cache controller
> >>is already
> >>enabled and thus no configuration is needed by Linux.
> >
> >Dirk,
> >
> >Do you have a real use case of this, i.e. running Linux on i.MX6 in
> >non-secure world?
> 
> 
> Yes, in a scenario where one of the cores runs a RTOS.

Can you please reword the commit log to have the above non-secure world
user story mentioned in there?

Shawn


From broonie at kernel.org  Thu Feb 18 06:59:54 2016
From: broonie at kernel.org (Mark Brown)
Date: Thu, 18 Feb 2016 14:59:54 +0000
Subject: [PATCH 3/6] ASoC: rockchip: add bindings for rk3399 i2s
In-Reply-To: <20160218143702.GN9654@rob-hp-laptop>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <1455673992-16469-4-git-send-email-jay.xu@rock-chips.com>
 <20160217110306.GJ7544@sirena.org.uk>
 <20160218143702.GN9654@rob-hp-laptop>
Message-ID: <20160218145954.GI7129@sirena.org.uk>

On Thu, Feb 18, 2016 at 08:37:02AM -0600, Rob Herring wrote:
> On Wed, Feb 17, 2016 at 11:03:06AM +0000, Mark Brown wrote:

> > As with the other patch I'd expect to see a matching driver update if
> > only for documentation purposes.

> Why? They match on the prior chip's compatible until there is some 
> difference the driver needs to handle.

That then requires anyone using a compatible string to also know the
full set of other compatible strings that can be used for this device
and that they have to list the others too in the correct order which
isn't something the binding document tells them.  It also feels better
to record in the code how we think we should support the device when we
know it, seems more helpful.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160218/3903df38/attachment.sig>

From gerald.schaefer at de.ibm.com  Thu Feb 18 07:00:37 2016
From: gerald.schaefer at de.ibm.com (Gerald Schaefer)
Date: Thu, 18 Feb 2016 16:00:37 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe
 also on PowerPC and ARM)
In-Reply-To: <20160217235808.GA21696@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
 <alpine.LFD.2.20.1602131238260.1910@schleppi>
 <20160217201340.2dafad8d@thinkpad>
 <20160217235808.GA21696@node.shutemov.name>
Message-ID: <20160218160037.627cc7ec@thinkpad>

On Thu, 18 Feb 2016 01:58:08 +0200
"Kirill A. Shutemov" <kirill at shutemov.name> wrote:

> On Wed, Feb 17, 2016 at 08:13:40PM +0100, Gerald Schaefer wrote:
> > On Sat, 13 Feb 2016 12:58:31 +0100 (CET)
> > Sebastian Ott <sebott at linux.vnet.ibm.com> wrote:
> > 
> > > [   59.875935] ------------[ cut here ]------------
> > > [   59.875937] kernel BUG at mm/huge_memory.c:2884!
> > > [   59.875979] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> > > [   59.875986] Modules linked in: bridge stp llc btrfs xor mlx4_en vxlan ip6_udp_tunnel udp_tunnel mlx4_ib ptp pps_core ib_sa ib_mad ib_core ib_addr ghash_s390 prng raid6_pq ecb aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 mlx4_core sha_common genwqe_card scm_block crc_itu_t vhost_net tun vhost dm_mod macvtap eadm_sch macvlan kvm autofs4
> > > [   59.876033] CPU: 2 PID: 5402 Comm: git Tainted: G        W       4.4.0-07794-ga4eff16-dirty #77
> > > [   59.876036] task: 00000000d2312948 ti: 00000000cfecc000 task.ti: 00000000cfecc000
> > > [   59.876039] Krnl PSW : 0704d00180000000 00000000002bf3aa (__split_huge_pmd_locked+0x562/0xa10)
> > > [   59.876045]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
> > >                Krnl GPRS: 0000000001a7a1cf 000003d10177c000 0000000000044068 000000005df00215
> > > [   59.876051]            0000000000000001 0000000000000001 0000000000000000 00000000774e6900
> > > [   59.876054]            000003ff52000000 000000006d403b10 000000006e1eb800 000003ff51f00000
> > > [   59.876058]            000003d10177c000 0000000000715190 00000000002bf234 00000000cfecfb58
> > > [   59.876068] Krnl Code: 00000000002bf39c: d507d010a000	clc	16(8,%%r13),0(%%r10)
> > >                           00000000002bf3a2: a7840004		brc	8,2bf3aa
> > >                          #00000000002bf3a6: a7f40001		brc	15,2bf3a8
> > >                          >00000000002bf3aa: 91407440		tm	1088(%%r7),64
> > >                           00000000002bf3ae: a7840208		brc	8,2bf7be
> > >                           00000000002bf3b2: a7f401e9		brc	15,2bf784
> > >                           00000000002bf3b6: 9104a006		tm	6(%%r10),4
> > >                           00000000002bf3ba: a7740004		brc	7,2bf3c2
> > > [   59.876089] Call Trace:
> > > [   59.876092] ([<00000000002bf234>] __split_huge_pmd_locked+0x3ec/0xa10)
> > > [   59.876095]  [<00000000002c4310>] __split_huge_pmd+0x118/0x218
> > > [   59.876099]  [<00000000002810e8>] unmap_single_vma+0x2d8/0xb40
> > > [   59.876102]  [<0000000000282d66>] zap_page_range+0x116/0x318
> > > [   59.876105]  [<000000000029b834>] SyS_madvise+0x23c/0x5e8
> > > [   59.876108]  [<00000000006f9f56>] system_call+0xd6/0x258
> > > [   59.876111]  [<000003ff9bbfd282>] 0x3ff9bbfd282
> > > [   59.876113] INFO: lockdep is turned off.
> > > [   59.876115] Last Breaking-Event-Address:
> > > [   59.876118]  [<00000000002bf3a6>] __split_huge_pmd_locked+0x55e/0xa10
> > 
> > The BUG at mm/huge_memory.c:2884 is interesting, it's the BUG_ON(!pte_none(*pte))
> > check in __split_huge_pmd_locked(). Obviously we expect the pre-allocated
> > pagetables to be empty, but in collapse_huge_page() we deposit the original
> > pagetable instead of allocating a new (empty) one. This saves an allocation,
> > which is good, but doesn't that mean that if such a collapsed hugepage will
> > ever be split, we will always run into the BUG_ON(!pte_none(*pte)), or one
> > of the two other VM_BUG_ONs in mm/huge_memory.c that check the same?
> > 
> > This behavior is not new, it was the same before the THP rework, so I do not
> > assume that it is related to the current problems, maybe with the exception
> > of this specific crash. I never saw the BUG at mm/huge_memory.c:2884 myself,
> > and the other crashes probably cannot be explained with this. Maybe I am
> > also missing something, but I do not see how collapse_huge_page() and the
> > (non-empty) pgtable deposit there can work out with the BUG_ON(!pte_none(*pte))
> > checks. Any thoughts?
> 
> I don't think there's a problem: ptes in the pgtable are cleared with
> pte_clear() in __collapse_huge_page_copy().
> 

Ah OK, I didn't see that. Still the BUG_ON() tells us that something went
wrong with the pre-allocated pagetable, or at least with the deposit/withdraw
list, or both. Given that on s390 we keep the listheads for the deposit/withdraw
list inside the pre-allocated pgtables, instead of the struct pages, it may
also explain why we see don't the problems on x86.

We already have the list corruption warning in exit_mmap -> zap_huge_pmd ->
withdraw, and from time to time I also hit the BUG_ON(page->pmd_huge_pte)
in exit_mmap -> free_pgtables -> free_pmd_range, which also indicates some
issues with the deposit/withdraw list, see below:

[ 2489.384069] page:000003d101aa6f00 count:1 mapcount:0 mapping:          (null) index:0x0
[ 2489.384075] flags: 0x0()
[ 2489.384078] page dumped because: VM_BUG_ON_PAGE(page->pmd_huge_pte)
[ 2489.384086] ------------[ cut here ]------------
[ 2489.384088] kernel BUG at include/linux/mm.h:1700!
[ 2489.384131] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 2489.384137] Modules linked in: bridge stp llc mlx4_ib ib_sa ib_mad mlx4_en ib_core vxlan udp_tunnel ptp pps_core ib_addr ghash_s390 prng ecb mlx4_core aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common eadm_sch dm_mod vhost_net tun vhost macvtap macvlan kvm autofs4
[ 2489.384173] CPU: 5 PID: 173619 Comm: cc1 Tainted: G    B   W       4.5.0-rc3-00083-gc05235d #10
[ 2489.384176] task: 00000000c54d0000 ti: 0000000060504000 task.ti: 0000000060504000
[ 2489.384179] Krnl PSW : 0704c00180000000 0000000000283cf4 (free_pgd_range+0x334/0x460)
[ 2489.384184]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
               Krnl GPRS: 0000000001a161c7 0000000000000000 0000000000000037 0000000000000000
[ 2489.384189]            0000000000283cf0 0000000000000000 000003ff7d980000 0000000060507e18
[ 2489.384192]            000003ff00000000 0000000075e43ff0 000003ff7d97ffff 000003ff7d980000
[ 2489.384195]            000000006a9bc000 00000000006cc390 0000000000283cf0 0000000060507c68
[ 2489.384201] Krnl Code: 0000000000283ce4: c030002e14dd        larl    %%r3,84669e
                          0000000000283cea: c0e5ffffd217        brasl   %%r14,27e118
                         #0000000000283cf0: a7f40001            brc     15,283cf2
                         >0000000000283cf4: c0e5fffffe5a        brasl   %%r14,2839a8
                          0000000000283cfa: b9040027            lgr     %%r2,%%r7
                          0000000000283cfe: b904003c            lgr     %%r3,%%r12
                          0000000000283d02: c0e5fff509e3        brasl   %%r14,1250c8
                          0000000000283d08: e31070000004        lg      %%r1,0(%%r7)
[ 2489.384221] Call Trace:
[ 2489.384224] ([<0000000000283cf0>] free_pgd_range+0x330/0x460)
[ 2489.384227]  [<0000000000283f38>] free_pgtables+0x118/0x148
[ 2489.384230]  [<000000000028c32e>] exit_mmap+0xd6/0x300
[ 2489.384233]  [<0000000000134d70>] mmput+0x90/0x118
[ 2489.384235]  [<000000000013a55c>] do_exit+0x41c/0xd18
[ 2489.384238]  [<000000000013c3c2>] do_group_exit+0x92/0xd8
[ 2489.384241]  [<000000000013c432>] SyS_exit_group+0x2a/0x30
[ 2489.384244]  [<00000000006b1a36>] system_call+0xd6/0x258
[ 2489.384246]  [<000003ff7d343698>] 0x3ff7d343698
[ 2489.384248] INFO: lockdep is turned off.
[ 2489.384251] Last Breaking-Event-Address:
[ 2489.384253]  [<0000000000283cf0>] free_pgd_range+0x330/0x460
[ 2489.384256]  
[ 2489.384258] Kernel panic - not syncing: Fatal exception: panic_on_oops

I'll try to add a BUG_ON(pmd_huge(*pmd)) to free_pte_range() and see if that
catches anything, and I'll also check if debug_cow = 1 or use_zero_page = 0
makes any difference.



From krzysztof.adamski at tieto.com  Thu Feb 18 07:03:29 2016
From: krzysztof.adamski at tieto.com (Krzysztof Adamski)
Date: Thu, 18 Feb 2016 16:03:29 +0100
Subject: [PATCH] clk: sunxi: Add missing H3 apb0 clock documentation
In-Reply-To: <CACRpkdbfNeh7_=3ReQtJc7OxkkQEn+BUhZ0O0SKnFsRD=WZiUQ@mail.gmail.com>
References: <CACRpkdbfNeh7_=3ReQtJc7OxkkQEn+BUhZ0O0SKnFsRD=WZiUQ@mail.gmail.com>
Message-ID: <1455807809-30827-1-git-send-email-k@japko.eu>

allwinner,sun8i-h3-apb0-gates-clk was added by
commit ba83a11104ae ("pinctrl: sunxi: Add H3 R_PIO controller support")
but the patch was missing proper binding documentation. This patch fixes
this issue.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index c09f59b..37d0fd6 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -38,6 +38,7 @@ Required properties:
 	"allwinner,sun4i-a10-apb0-clk" - for the APB0 clock
 	"allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31
 	"allwinner,sun8i-a23-apb0-clk" - for the APB0 clock on A23
+	"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
 	"allwinner,sun9i-a80-apb0-clk" - for the APB0 bus clock on A80
 	"allwinner,sun8i-a83t-apb0-gates-clk" - for the APB0 gates on A83T
 	"allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10
-- 
2.1.4



From ulf.hansson at linaro.org  Thu Feb 18 07:06:26 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 18 Feb 2016 16:06:26 +0100
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <56BCB90C.8000302@nvidia.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
 <56BB7AF4.8040708@nvidia.com>
 <CAPDyKFrZ6tWBsQC0tyWWeChiZja3h_zcbaiX25ak-Zyp4MzqVw@mail.gmail.com>
 <56BC50C2.7050609@nvidia.com>
 <CAPDyKFrdmufsMqNL0U7q5gPEUqsg3SrkrNChcziQjEOjvd30Ng@mail.gmail.com>
 <56BC5EE0.2040804@nvidia.com>
 <CAPDyKFq_0t4tcvkgMBW8p8ubJDALWMjdhgGM+_Z6auRxEkSPdA@mail.gmail.com>
 <56BCB90C.8000302@nvidia.com>
Message-ID: <CAPDyKFpO5dd4asjhpEUW69GcwZ_FNPKauKRpVFh0SJk_+smRSg@mail.gmail.com>

On 11 February 2016 at 17:38, Jon Hunter <jonathanh at nvidia.com> wrote:
>
> On 11/02/16 10:28, Ulf Hansson wrote:
>> On 11 February 2016 at 11:13, Jon Hunter <jonathanh at nvidia.com> wrote:
>>>
>>> On 11/02/16 09:57, Ulf Hansson wrote:
>>>> On 11 February 2016 at 10:13, Jon Hunter <jonathanh at nvidia.com> wrote:
>>>>>
>>>>> On 10/02/16 18:25, Ulf Hansson wrote:
>>>>>
>>>>> [snip]
>>>>>
>>>>>>>> Perhaps there's a way to allow the generic PM domain to control this
>>>>>>>> by itself. If we for example used the struct device corresponding to
>>>>>>>> the powergate driver, genpd could use it to distinguish between
>>>>>>>> various instances of genpd structs..!? Maybe it would simplify the way
>>>>>>>> to deal with removing domains?
>>>>>>>
>>>>>>> Yes, that would be ideal. However, would have require changing
>>>>>>> genpd_init()? I am not sure how genpd would be able to access the device
>>>>>>> struct for the powergate driver because we don't provide this via any
>>>>>>> API I am aware of? And I am guessing that you don't wish to expose the
>>>>>>> gpd_list to the world either.
>>>>>>>
>>>>>>> If there is an easy way, I am open to it, but looking at it today, I am
>>>>>>> not sure I see a simple way in which we could add a new API to do this.
>>>>>>> However, may be I am missing something!
>>>>>>
>>>>>> If we add a new __pm_genpd_init() API, that could require a struct
>>>>>> device to be provided. That API will thus invoke the existing
>>>>>> pm_genpd_init() but also deal with the extra things needed here.
>>>>>>
>>>>>> I would also allow such an API to return an error code.
>>>>>>
>>>>>> Correspondingly, pm_genpd_remove() could be required to be provided
>>>>>> with a struct device.
>>>>>>
>>>>>> Existing users of pm_genpd_init() can then convert to
>>>>>> __pm_genpd_init() whenever suitable.
>>>>>>
>>>>>> Of course, another option is just to add new member in the genpd
>>>>>> struct for the struct *device. The caller of pm_genpd_init() could
>>>>>> check it, but allow it to be NULL. Although, the pm_genpd_remove() API
>>>>>> would require that pointer to the struct device to be set...
>>>>>>
>>>>>> What do you think?
>>>>>
>>>>> Yes, sounds good. May be it is simpler just to add a new member and let
>>>>> the platform genpd driver handle it.
>>>>>
>>>>> I am wondering if in addition to pm_genpd_remove(), we then just have a
>>>>> function called pm_genpd_remove_tail(), which allows you to pass the
>>>>> struct device pointer and will remove the last pm-domain from the
>>>>> gpd_list and return the genpd pointer if successful. Internally, it will
>>>>> call pm_genpd_remove(). It seems to me that if there are nested
>>>>> pm-domains, then we probably want to remove them starting from the tail
>>>>> as opposed to the head.
>>>>>
>>>>> How does that sound?
>>>>
>>>> Why not make pm_genpd_remove() to behave as you describe for
>>>> pm_genpd_remove_tail()?
>>>> That's probably the only sane way to remove genpds anyhow!?
>>>
>>> Simply to offer flexibility. I could see that for some devices that have
>>> no dependencies between pm-domains and have a static list of pm-domains,
>>> they can simply call pm_genpd_remove() for a given pm-domain. However,
>>> that said, I can envision a case where a single pm-domain would be
>>> removed by itself and so may be there is no benefit?
>>
>> If I understand correctly, you agree to try with the most simple
>> approach first and thus without providing too much flexibility.
>>
>> Anyway, I am looking forward to review your next version of the patchset! :-)
>
> So one snag I hit with this, is that in order to remove a pm-domain, I
> first need to check if it is a subdomain of any other domains and if so
> remove it as a subdomain first. Before, this was simple because I called
> pm_genpd_remove_subdomain if the domain had a parent, and then called
> pm_genpd_remove().

You certainly have a point here.

One more thing, we not only have to check whether the domain is a
subdomain. we also need to check if the domain is a parent (master)
for other subdomains. It being a parent, prevents us from removing it
until all its subdomains are removed.

>
> With the proposal we have discussed, I no longer have any knowledge of
> whether the pm-domain is a subdomain or not because pm_genpd_remove()
> would remove the tail and then return it. So this means that I now need
> to handle the removal of the subdomain within pm_genpd_remove(), which
> is ok, but creates more changes as I need to parse the slave_links list,
> etc.
>
> I am wondering if it would be better to add a simple function called
> pm_genpd_list_get_tail(struct device *dev) that would return the last
> pm-domain register for a given device and then simply call
> pm_genpd_remove_subdomain() (if needed) and pm_genpd_remove()?

That should work. Please go ahead and have try!

Kind regards
Uffe


From helgaas at kernel.org  Thu Feb 18 07:08:52 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Thu, 18 Feb 2016 09:08:52 -0600
Subject: [PATCH] PCI: imx6:don't sleep in atomic context
In-Reply-To: <FDC088D3B5555644AE135ED28A7ABDE986504C90@EU-MBX-04.mgc.mentorg.com>
References: <1447066080-5859-1-git-send-email-sanjeev_sharma@mentor.com>
 <20160106220430.GC16231@localhost>
 <FDC088D3B5555644AE135ED28A7ABDE986504C90@EU-MBX-04.mgc.mentorg.com>
Message-ID: <20160218150852.GA17588@localhost>

On Thu, Feb 18, 2016 at 07:17:41AM +0000, Sharma, Sanjeev wrote:
> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas at kernel.org] 
> Sent: Thursday, January 07, 2016 3:35 AM
> To: Sharma, Sanjeev
> Cc: Richard.Zhu at freescale.com; l.stach at pengutronix.de; bhelgaas at google.com; linux-pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; David Mueller
> Subject: Re: [PATCH] PCI: imx6:don't sleep in atomic context
> 
> Hi Sanjeev,
> 
> On Mon, Nov 09, 2015 at 04:18:00PM +0530, Sanjeev Sharma wrote:
> > If additional PCIe switch get connected between the host and the 
> > NIC,the kernel crashes with "BUG:
> > scheduling while atomic". To handle this we need to call mdelay() 
> > instead of usleep_range().
> > 
> > For more detail please refer bugzilla.kernel.org, Bug
> > 100031
> > 
> > Signed-off-by: Sanjeev Sharma <sanjeev_sharma at mentor.com>
> > Signed-off-by: David Mueller <dave.mueller at gmx.ch>
> 
> I'm dropping this for now because we've been kicking around the same solution (with tweaks to the mdelay amount) since June, but no progress on the *real* issue, which is that imx6_pcie_link_up() should never wait; it should simply return the link status.
> 
> I'm pretty sure the amount of time I've spent looking into this would have been enough to make some progress on that underlying issue.
> 
> Bjorn
> 
> Ok ! please share the change you are planning to implement. 

I didn't mean I personally was going to do this.  But I think Lucas
stepped up and did it:

https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/host-imx6&id=4d107d3b5a686b5834e533a00b73bf7b1cf59df7

> > ---
> >  drivers/pci/host/pci-imx6.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c 
> > index 233a196..9769b13 100644
> > --- a/drivers/pci/host/pci-imx6.c
> > +++ b/drivers/pci/host/pci-imx6.c
> > @@ -499,7 +499,7 @@ static int imx6_pcie_link_up(struct pcie_port *pp)
> >  		 * Wait a little bit, then re-check if the link finished
> >  		 * the training.
> >  		 */
> > -		usleep_range(1000, 2000);
> > +		mdelay(1000);
> >  	}
> >  	/*
> >  	 * From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
> > --
> > 1.7.11.7
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" 
> > in the body of a message to majordomo at vger.kernel.org More majordomo 
> > info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From shawnguo at kernel.org  Thu Feb 18 07:04:35 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 18 Feb 2016 23:04:35 +0800
Subject: [PATCH] ARM: dts: vf-colibri: disable write-protection for SD-card
In-Reply-To: <1455752656-4040-1-git-send-email-stefan@agner.ch>
References: <1455752656-4040-1-git-send-email-stefan@agner.ch>
Message-ID: <20160218150434.GD6756@tiger>

On Wed, Feb 17, 2016 at 03:44:16PM -0800, Stefan Agner wrote:
> The Colibri standard does not define a pin for SD-Card write-
> protection. Use the disable-wp property to indicate that there
> is no physical WP line present.
> 
> Signed-off-by: Stefan Agner <stefan at agner.ch>

Applied, thanks.

> ---
>  arch/arm/boot/dts/vf-colibri.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/vf-colibri.dtsi b/arch/arm/boot/dts/vf-colibri.dtsi
> index ff6f58e..e49bbbc 100644
> --- a/arch/arm/boot/dts/vf-colibri.dtsi
> +++ b/arch/arm/boot/dts/vf-colibri.dtsi
> @@ -92,6 +92,7 @@
>  	pinctrl-0 = <&pinctrl_esdhc1>;
>  	bus-width = <4>;
>  	cd-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> +	disable-wp;
>  };
>  
>  &fec1 {
> -- 
> 2.7.1
> 
> 


From shawnguo at kernel.org  Thu Feb 18 07:10:42 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Thu, 18 Feb 2016 23:10:42 +0800
Subject: [PATCH] ARM: dts: vf610: add performance monitoring unit
In-Reply-To: <1455755820-31442-1-git-send-email-stefan@agner.ch>
References: <1455755820-31442-1-git-send-email-stefan@agner.ch>
Message-ID: <20160218151042.GE6756@tiger>

On Wed, Feb 17, 2016 at 04:37:00PM -0800, Stefan Agner wrote:
> All Freescale Vybrid SoC include a Cortex-A5 core which supports
> ARM's standard PMU (performance monitoring unit). Include the
> monitoring unit into the Cortex-A5 base device tree vf500.dtsi.
> 
> Signed-off-by: Stefan Agner <stefan at agner.ch>
> ---
>  arch/arm/boot/dts/vf500.dtsi | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vf500.dtsi b/arch/arm/boot/dts/vf500.dtsi
> index b94b992..9cd1ac5 100644
> --- a/arch/arm/boot/dts/vf500.dtsi
> +++ b/arch/arm/boot/dts/vf500.dtsi
> @@ -75,6 +75,16 @@
>  				clocks = <&clks VF610_CLK_PLATFORM_BUS>;
>  			};
>  		};
> +
> +		aips-bus at 40080000 {
> +

This new line is not really necessary.  I applied the patch with it
dropped.

Shawn

> +			pmu at 40089000 {
> +				compatible = "arm,cortex-a5-pmu";
> +				interrupts = <7 IRQ_TYPE_LEVEL_HIGH>;
> +				interrupt-affinity = <&a5_cpu>;
> +			};
> +		};
> +
>  	};
>  };
>  
> -- 
> 2.7.1
> 
> 


From treding at nvidia.com  Thu Feb 18 07:12:45 2016
From: treding at nvidia.com (Thierry Reding)
Date: Thu, 18 Feb 2016 16:12:45 +0100
Subject: [PATCH 2/2] drm/panel: Add support for LG lp120up1 panel
In-Reply-To: <1455691839-2410-2-git-send-email-jitao.shi@mediatek.com>
References: <1455691839-2410-1-git-send-email-jitao.shi@mediatek.com>
 <1455691839-2410-2-git-send-email-jitao.shi@mediatek.com>
Message-ID: <20160218151244.GB5571@ulmo.nvidia.com>

On Wed, Feb 17, 2016 at 02:50:39PM +0800, Jitao Shi wrote:
> The LG lp120up1 panel is a 12.0" 1920x1280 panel,
> which can be supported by the simple panel driver

It'd be nice to mention the type of interface of the panel here. While
at it, please rewrite the commit message to make use of what width you
have (i.e. any line after the subject can be 72 characters wide).

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160218/1b854aba/attachment.sig>

From srinivas.kandagatla at linaro.org  Thu Feb 18 07:13:55 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Thu, 18 Feb 2016 15:13:55 +0000
Subject: Query on using nvmem consumer API
In-Reply-To: <20160218120100.GA11366@Sanchayan-Arch.toradex.int>
References: <20160218120100.GA11366@Sanchayan-Arch.toradex.int>
Message-ID: <56C5DFB3.1020903@linaro.org>



On 18/02/16 12:01, maitysanchayan at gmail.com wrote:
> Hello Srinivas,
>
> I have a device tree node as follows
>
>                          ocotp: ocotp at 400a5000 {
>                                  compatible = "fsl,vf610-ocotp";
>                                  #address-cells = <1>;
>                                  #size-cells = <1>;
>                                  reg = <0x400a5000 0xCF0>;
>                                  clocks = <&clks VF610_CLK_OCOTP>;
>
>                                  ocotp_cfg: cfg at 410 {
>                                          reg = <0x410 0x20>;
>                                  };
>                          };
>
> and a nvmem data consumer node as follows
>
>          soc-bus {
>                  compatible = "fsl,vf610-soc-bus";
>                  nvmem = <&ocotp>;
>                  nvmem-names = "ocotp";
>                  nvmem-cell = <&ocotp_cfg>;
>                  nvmem-cell-names = "soc_id";
>                  status = "okay";
>          };
>
> I believe my device tree node entries are incorrect. I did like to
> use the devm_nvmem_device/cell_get functions and then read using
> cell or device consumer API's. I am looking at the NVMEM bindings
> but it is not clear to me as to what the correct DT entries and
> the corresponding arguments to devm_nvmem_device/cell_get should
> be?
>
> Can you help me out with as to what the correct entries and calls
> should be?

Sure,

Firstly you should grab a nvmem cell and then use it as part of 
nvmem_read/write.

In your case you would do this in soc-bus device.

struct nvmem_cell *soc_id = devm_nvmem_cell_get(dev, "soc_id");
data = nvmem_cell_read(soc_id, &len);

There is some documentation at Documentation/nvmem/nvmem.txt
Let me know if you find any issues with the doc.


thanks,
srini


>
> I currently have
> devm_nvmem_device_get(dev, "ocotp");
> devm_nvmem_cell_get(dev, "soc_id");
>
> where dev would be the soc-bus device.
>
> Thanks & Regards,
> Sanchayan.
>


From anson.huang at nxp.com  Thu Feb 18 07:15:41 2016
From: anson.huang at nxp.com (Yongcai Huang)
Date: Thu, 18 Feb 2016 15:15:41 +0000
Subject: iMX7d cpu1 issue
In-Reply-To: <20160218140913.GY6756@tiger>
References: <56C2D63F.1030408@compulab.co.il>,<20160218140913.GY6756@tiger>
Message-ID: <1F497949-8B77-4376-A109-A2737CFBD9C7@nxp.com>

Hi, llya
        Can you paste the code piece of enabling CPU1 in src.c? I remembered I met similar issue during bring up SMP on MX7D, but it was 1 year ago, I did NOT remembered the detail now. I suspect something wrong in SRC register setting.

From Anson's iPhone 6


> ? 2016?2?18??22:10?Shawn Guo <shawnguo at kernel.org> ???
> 
>> On Tue, Feb 16, 2016 at 09:56:47AM +0200, Ilya Ledvich wrote:
>> Hi Shawn,
>> I'm working on Compulab CL-SOM-IMX7 device (http://www.compulab.co.il/products/computer-on-modules/cl-som-imx7-freescale-i-mx-7-system-on-module)
>> based on Freescale iMX7d CPU.
>> I use the Freescale latest BSP imx_3.14.52_1.1.0_ga  and the Linux
>> mainline v4.4-rc6 as a reference.
>> I observe an issue with bringing up the second CPU core. Briefly,
>> the kernel can successfully boot only when CPU1 fails to come
>> online.
>> In this case the boot log shows the following messages:
>> ...
>> CPU1: failed to come online
>> Brought up 1 CPUs
>> SMP: Total of 1 processors activated (6.00 BogoMIPS).
>> ...
>> 
>> Otherwise, the device tries to start kernel several times until the
>> boot process eventually crashes. Please see attached logs for more
>> details.
>> This never happens on mainline Linus kernel, because it never tries
>> to bring up CPU1.
>> Unfortunately, we cannot verify this behavior on reference board
>> cause we have no one.
>> Have you ever seen such behavior? Could you please advice something?
> 
> I never played i.MX7D support on any real hardware.  I copied a couple
> Freescale/NXP people here.  Let's see if you can get some help from
> them.
> 
> Shawn
> 
>> Starting kernel ...
>> 
>> Uncompressing Linux... done, booting the kernel.
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
>> Kernel command line: console=ttymxc0,115200 earlyprintk=ttymxc0,115200 root=/dev/nfs ip=dhcp nfsroot=192.168.11.24:/home/ilya/work/rootfs/sid-minbase,v3,tcp rw rootwait
>> PID hash table entries: 4096 (order: 2, 16384 bytes)
>> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
>> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
>> Memory: 700996K/1048576K available (6617K kernel code, 353K rwdata, 2280K rodata, 384K init, 421K bss, 347580K reserved, 0K highmem)
>> Virtual kernel memory layout:
>>    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>>    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>>    vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
>>    lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>>    pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)
>>    modules : 0x7f000000 - 0x7fe00000   (  14 MB)
>>      .text : 0x80008000 - 0x808b8880   (8899 kB)
>>      .init : 0x808b9000 - 0x80919080   ( 385 kB)
>>      .data : 0x8091a000 - 0x80972680   ( 354 kB)
>>       .bss : 0x8097268c - 0x809dbc00   ( 422 kB)
>> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
>> Preemptible hierarchical RCU implementation.
>>        RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
>> RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
>> NR_IRQS:16 nr_irqs:16 16
>> Switching to timer-based delay loop
>> sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655765682ns
>> Architected cp15 timer(s) running at 8.00MHz (phys).
>> sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2147483648000ns
>> Ignoring duplicate/late registration of read_current_timer delay
>> Console: colour dummy device 80x30
>> Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=30000)
>> pid_max: default: 32768 minimum: 301
>> Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
>> Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
>> CPU: Testing write buffer coherency: ok
>> /cpus/cpu at 0 missing clock-frequency property
>> /cpus/cpu at 1 missing clock-frequency property
>> CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
>> Setting up static identity map for 0x80647850 - 0x806478a8
>> Switching to timer-based delay loop
>> Calibrating delay loop (skipped) already calibrated this CPU6.00 BogoMIPS (lpj=30000)
>> sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655765682ns
>> Architected cp15 timer(s) running at 8.00MHz (phys).
>> 2147483648000ns
>> Current pid: 1 comm: swapper/0 / Idle pid: 0 comm: swapper/0
>> Ignoring duplicate/late registra
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> CPU1: failed to come online
>> Brought up 1 CPUs
>> SMP: Total of 1 processors activated (6.00 BogoMIPS).
>> CPU: All CPU(s) started in SVC mode.
>> devtmpfs: initialized
>> VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
>> pinctrl core: initialized pinctrl subsystem
>> regulator-dummy: no parameters
>> NET: Registered protocol family 16
>> DMA: preallocated 256 KiB pool for atomic coherent allocations
>> cpuidle: using governor ladder
>> cpuidle: using governor menu
>> Use WDOG1 as reset source
>> syscon 30340000.iomuxc-gpr: regmap [mem 0x30340000-0x3034ffff] registered
>> syscon 30350000.ocotp-ctrl: regmap [mem 0x30350000-0x3035ffff] registered
>> syscon 30360000.anatop: regmap [mem 0x30360000-0x3036ffff] registered
>> vdd1p0d: 800 <--> 1200 mV at 1000 mV 
>> vdd1p2: 1100 <--> 1300 mV 
>> syscon 30390000.src: regmap [mem 0x30390000-0x3039ffff] registered
>> DDR type is DDR3!
>> failed to find ocotp node
>> failed to find ocotp node
>> hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
>> hw-breakpoint: maximum watchpoint size is 8 bytes.
>> imx7d-pinctrl 302c0000.iomuxc-lpsr: initialized IMX pinctrl driver
>> imx7d-pinctrl 30330000.iomuxc: initialized IMX pinctrl driver
>> MU is ready for cross core communication!
>> bio: create slab <bio-0> at 0
>> mxs-dma 33000000.dma-apbh: initialized
>> usb_otg1_vbus: 5000 mV 
>> fec1_phy_nreset: 3300 mV 
>> platform regulator.15: Driver reg-fixed-voltage requests probe deferral
>> tsc2046-reg: 3300 mV 
>> platform regulator.17: Driver reg-fixed-voltage requests probe deferral
>> platform lcd_nstby_3v3.18: Driver reg-fixed-voltage requests probe deferral
>> SCSI subsystem initialized
>> usbcore: registered new interface driver usbfs
>> usbcore: registered new interface driver hub
>> usbcore: registered new device driver usb
>> usbphy_nop1.10 supply vcc not found, using dummy regulator
>> usbphy_nop2.11 supply vcc not found, using dummy regulator
>> i2c i2c-1: IMX I2C adapter registered
>> i2c i2c-3: IMX I2C adapter registered
>> Linux video capture interface: v2.00
>> pps_core: LinuxPPS API ver. 1 registered
>> pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti at linux.it>
>> PTP clock support registered
>> MIPI CSI2 driver module loaded
>> Advanced Linux Sound Architecture Driver Initialized.
>> Switched to clocksource arch_sys_counter
>> cfg80211: Calling CRDA to update world regulatory domain
>> NET: Registered protocol family 2
>> TCP established hash table entries: 8192 (order: 3, 32768 bytes)
>> TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
>> TCP: Hash tables configured (established 8192 bind 8192)
>> TCP: reno registered
>> UDP hash table entries: 512 (order: 2, 16384 bytes)
>> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
>> NET: Registered protocol family 1
>> RPC: Registered named UNIX socket transport module.
>> RPC: Registered udp transport module.
>> RPC: Registered tcp transport module.
>> RPC: Registered tcp NFSv4.1 backchannel transport module.
>> imx rpmsg driver is registered.
>> Bus freq driver module loaded
>> futex hash table entries: 512 (order: 3, 32768 bytes)
>> VFS: Disk quotas dquot_6.5.2
>> Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
>> NFS: Registering the id_resolver key type
>> Key type id_resolver registered
>> Key type id_legacy registered
>> jffs2: version 2.2. (NAND) ???? 2001-2006 Red Hat, Inc.
>> fuse init (API version 7.22)
>> msgmni has been set to 2009
>> io scheduler noop registered
>> io scheduler deadline registered
>> io scheduler cfq registered (default)
>> backlight.20 supply power not found, using dummy regulator
>> MIPI DSI driver module loaded
>> 30730000.lcdif supply lcd not found, using dummy regulator
>> mxsfb 30730000.lcdif: failed to find mxc display driver 
>> Console: switching to colour frame buffer device 100x30
>> mxsfb 30730000.lcdif: initialized
>> imx-sdma 30bd0000.sdma: no event needs to be remapped
>> imx-sdma 30bd0000.sdma: loaded firmware 4.1
>> imx-sdma 30bd0000.sdma: initialized
>> pfuze100-regulator 1-0008: Full layer: 1, Metal layer: 1
>> pfuze100-regulator 1-0008: FAB: 0, FIN: 0
>> pfuze100-regulator 1-0008: pfuze3000 found.
>> SW1A: 700 <--> 3300 mV at 1100 mV 
>> SW1B: 700 <--> 1475 mV at 1000 mV 
>> SW2: 1500 <--> 1850 mV at 1800 mV 
>> SW3: 900 <--> 1650 mV at 1350 mV 
>> SWBST: 5000 <--> 5150 mV at 5000 mV 
>> VSNVS: 1000 <--> 3000 mV at 3000 mV 
>> VREFDDR: 750 mV 
>> VLDO1: 1800 <--> 3300 mV at 1800 mV 
>> VLDO2: 800 <--> 1550 mV at 1500 mV 
>> VCCSD: 2850 <--> 3300 mV at 3300 mV 
>> V33: 2850 <--> 3300 mV at 3300 mV 
>> VLDO3: 1800 <--> 3300 mV at 3300 mV 
>> VLDO4: 1800 <--> 3300 mV at 3300 mV 
>> Serial: IMX driver
>> 30860000.serial: ttymxc0 at MMIO 0x30860000 (irq = 58, base_baud = 1500000) is a IMX
>> console [ttymxc0] enabled
>> bootconsole [earlycon0] disabled
>> serial: Freescale lpuart driver
>> imx sema4 driver is registered.
>> [drm] Initialized drm 1.1.0 20060810
>> [drm] Initialized vivante 1.0.0 20120216 on minor 0
>> brd: module loaded
>> loop: module loaded
>> at24 1-0050: 1024 byte 24c08 EEPROM, writable, 16 bytes/write
>> m25p80 spi0.1: m25px16 (2048 Kbytes)
>> 3 ofpart partitions found on MTD device spi0.1
>> Creating 3 MTD partitions on "spi0.1":
>> 0x000000000000-0x0000000c0000 : "uboot"
>> 0x0000000c0000-0x000000100000 : "uboot environment"
>> 0x000000100000-0x000000200000 : "splash"
>> spi_imx 30820000.ecspi: probed
>> 30be0000.ethernet supply phy not found, using dummy regulator
>> pps pps0: new PPS source ptp0
>> libphy: fec_enet_mii_bus: probed
>> fec 30be0000.ethernet eth0: registered PHC device 0
>> 30bf0000.ethernet supply phy not found, using dummy regulator
>> pps pps1: new PPS source ptp1
>> fec 30bf0000.ethernet (unregistered net_device): Invalid MAC address: 00:00:00:00:00:00
>> fec 30bf0000.ethernet (unregistered net_device): Using random MAC address: c2:a3:b7:db:4d:b0
>> fec 30bf0000.ethernet eth1: registered PHC device 1
>> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>> ehci-mxc: Freescale On-Chip EHCI Host driver
>> usbcore: registered new interface driver usb-storage
>> 30b10200.usbmisc supply vbus-wakeup not found, using dummy regulator
>> 30b20200.usbmisc supply vbus-wakeup not found, using dummy regulator
>> 30b30200.usbmisc supply vbus-wakeup not found, using dummy regulator
>> 30b20000.usb supply vbus not found, using dummy regulator
>> ci_hdrc ci_hdrc.1: EHCI Host Controller
>> ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 1
>> ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
>> hub 1-0:1.0: USB hub found
>> hub 1-0:1.0: 1 port detected
>> imx_usb 30b30000.usb: Can't register ci_hdrc platform device, err=-517
>> platform 30b30000.usb: Driver imx_usb requests probe deferral
>> mousedev: PS/2 mouse device common for all mice
>> input: 30370000.snvs-pwrkey as /devices/soc.3/30000000.aips-bus/30370000.snvs-pwrkey/input/input0
>> snvs_pwrkey 30370000.snvs-pwrkey: i.MX snvs powerkey probed
>> rtc-em3027 1-0056: rtc core: registered rtc-em3027 as rtc0
>> snvs_rtc 30370034.snvs-rtc-lp: rtc core: registered 30370034.snvs-rtc-l as rtc1
>> i2c /dev entries driver
>> IR NEC protocol handler initialized
>> IR RC5(x) protocol handler initialized
>> IR RC6 protocol handler initialized
>> IR JVC protocol handler initialized
>> IR Sony protocol handler initialized
>> IR RC5 (streamzap) protocol handler initialized
>> IR SANYO protocol handler initialized
>> IR MCE Keyboard/mouse protocol handler initialized
>> imx2-wdt 30280000.wdog: IMX2+ Watchdog Timer enabled. timeout=60s (nowayout=0)
>> sdhci: Secure Digital Host Controller Interface driver
>> sdhci: Copyright(c) Pierre Ossman
>> sdhci-pltfm: SDHCI platform and OF driver helper
>> sdhci-esdhc-imx 30b40000.usdhc: could not get ultra high speed state, work on normal mode
>> mmc0: no vqmmc regulator found
>> mmc0: no vmmc regulator found
>> mmc0: SDHCI controller on 30b40000.usdhc [30b40000.usdhc] using ADMA
>> sdhci-esdhc-imx 30b60000.usdhc: could not get ultra high speed state, work on normal mode
>> mmc2: no vqmmc regulator found
>> mmc2: no vmmc regulator found
>> mmc0: new high speed SDHC card at address e624
>> mmc2: SDHCI controller on 30b60000.usdhc [30b60000.usdhc] using ADMA
>> mmcblk0: mmc0:e624 SS08G 7.40 GiB 
>> usbcore: registered new interface driver usbhid
>> usbhid: USB HID core driver
>> mmcblk0: unknown partition table
>> TCP: cubic registered
>> NET: Registered protocol family 10
>> sit: IPv6 over IPv4 tunneling driver
>> NET: Registered protocol family 17
>> Key type dns_resolver registered
>> usb 1-1: new high-speed USB device number 2 using ci_hdrc
>> Registering SWP/SWPB emulation handler
>> SWBST: disabling
>> usb_otg1_vbus: disabling
>> regulator-dummy: disabling
>> imx mcc test is registered.
>> fec2_phy_nreset: 3300 mV 
>> usb_host_nreset: 3300 mV 
>> lcd_nstby_3v3: no parameters
>> ci_hdrc ci_hdrc.2: EHCI Host Controller
>> ci_hdrc ci_hdrc.2: new USB bus registered, assigned bus number 2
>> mmc2: BKOPS_EN bit is not set
>> mmc2: new high speed DDR MMC card at address 0001
>> mmcblk2: mmc2:0001 SEM04G 3.68 GiB 
>> mmcblk2boot0: mmc2:0001 SEM04G partition 1 2.00 MiB
>> mmcblk2boot1: mmc2:0001 SEM04G partition 2 2.00 MiB
>> mmcblk2rpmb: mmc2:0001 SEM04G partition 3 2.00 MiB
>> mmcblk2: unknown partition table
>> mmcblk2boot1: unknown partition table
>> mmcblk2boot0: unknown partition table
>> ci_hdrc ci_hdrc.2: USB 2.0 started, EHCI 1.00
>> hub 2-0:1.0: USB hub found
>> hub 2-0:1.0: 1 port detected
>> Number of LUNs=8
>> Mass Storage Function, version: 2009/09/11
>> LUN: removable file: (no medium)
>> usb-storage 1-1:1.0: USB Mass Storage device detected
>> scsi0 : usb-storage 1-1:1.0
>> Number of LUNs=1
>> no file given for LUN0
>> g_mass_storage ci_hdrc.0: failed to start g_mass_storage: -22
>> rtc-em3027 1-0056: setting system clock to 2016-02-16 07:32:51 UTC (1455607971)
>> fec 30be0000.ethernet eth0: Freescale FEC PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=30be0000.etherne:00, irq=-1)
>> IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>> fec 30bf0000.ethernet eth1: Freescale FEC PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=30be0000.etherne:01, irq=-1)
>> usb 2-1: new high-speed USB device number 2 using ci_hdrc
>> IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
>> hub 2-1:1.0: USB hub found
>> hub 2-1:1.0: 3 ports detected
>> scsi 0:0:0:0: Direct-Access     SanDisk  Cruzer Slice     1.14 PQ: 0 ANSI: 2
>> sd 0:0:0:0: [sda] 15633408 512-byte logical blocks: (8.00 GB/7.45 GiB)
>> sd 0:0:0:0: [sda] Write Protect is off
>> sd 0:0:0:0: [sda] No Caching mode page found
>> sd 0:0:0:0: [sda] Assuming drive cache: write through
>> sd 0:0:0:0: [sda] No Caching mode page found
>> sd 0:0:0:0: [sda] Assuming drive cache: write through
>> sda: unknown partition table
>> sd 0:0:0:0: [sda] No Caching mode page found
>> sd 0:0:0:0: [sda] Assuming drive cache: write through
>> sd 0:0:0:0: [sda] Attached SCSI removable disk
>> libphy: 30be0000.etherne:00 - Link is Up - 1000/Full
>> IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>> Sending DHCP requests ., OK
>> IP-Config: Got DHCP answer from 10.1.1.240, my address is 192.168.27.43
>> IP-Config: Complete:
>>     device=eth0, hwaddr=00:01:c0:1a:e9:13, ipaddr=192.168.27.43, mask=255.255.0.0, gw=192.168.0.110
>>     host=192.168.27.43, domain=compulab.local, nis-domain=(none)
>>     bootserver=10.1.1.247, rootserver=192.168.11.24, rootpath=
>>     nameserver0=192.168.10.13, nameserver1=10.1.1.247
>> ALSA device list:
>>  No soundcards found.
>> VFS: Mounted root (nfs filesystem) on device 0:13.
>> devtmpfs: mounted
>> Freeing unused kernel memory: 384K (808b9000 - 80919000)
>> random: systemd urandom read with 58 bits of entropy available
>> systemd[1]: systemd 228 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
>> systemd[1]: Detected architecture arm.
>> 
>> Welcome to Debian GNU/Linux stretch/sid!
> 
>> Starting kernel ...
>> 
>> Uncompressing Linux... done, booting the kernel.
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
>> Kernel command line: console=ttymxc0,115200 earlyprintk=ttymxc0,115200 root=/dev/nfs ip=dhcp nfsroot=192.168.11.24:/home/ilya/work/rootfs/sid-minbase,v3,tcp rw rootwait
>> PID hash table entries: 4096 (order: 2, 16384 bytes)
>> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
>> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
>> Memory: 700996K/1048576K available (6617K kernel code, 353K rwdata, 2280K rodata, 384K init, 421K bss, 347580K reserved, 0K highmem)
>> Virtual kernel memory layout:
>>    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>>    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>>    vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
>>    lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>>    pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)
>>    modules : 0x7f000000 - 0x7fe00000   (  14 MB)
>>      .text : 0x80008000 - 0x808b8880   (8899 kB)
>>      .init : 0x808b9000 - 0x80919080   ( 385 kB)
>>      .data : 0x8091a000 - 0x80972680   ( 354 kB)
>>       .bss : 0x8097268c - 0x809dbc00   ( 422 kB)
>> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
>> Preemptible hierarchical RCU implementation.
>>        RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
>> RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
>> NR_IRQS:16 nr_irqs:16 16
>> Switching to timer-based delay loop
>> sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655765682ns
>> Architected cp15 timer(s) running at 8.00MHz (phys).
>> sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2147483648000ns
>> Ignoring duplicate/late registration of read_current_timer delay
>> Console: colour dummy device 80x30
>> Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=30000)
>> pid_max: default: 32768 minimum: 301
>> Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
>> Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
>> CPU: Testing write buffer coherency: ok
>> /cpus/cpu at 0 missing clock-frequency property
>> /cpus/cpu at 1 missing clock-frequency property
>> CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
>> Setting up static identity map for 0x80647850 - 0x806478a8
>> Memory: 700996K/1048576K available (6617K kernel code, 353K rwdata, 2280K rodata, 384K init, 421K bss, 347580K reserved, 0K highmem)
>> Virtual kernel memory layout:
>>    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>>    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>>    vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
>>    lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>>    pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)
>>    modules : 0x7f000000 - 0x7fe00000   (  14 MB)
>>      .text : 0x80008000 - 0x808b8880   (8899 kB)
>>      .init : 0x808b9000 - 0x80919080   ( 385 kB)
>>      .data : 0x8091a000 - 0x80972680   ( 354 kB)
>>       .bss : 0x8097268c - 0x809dbc00   ( 422 kB)
>> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
>> Preemptible hierarchical RCU implementation.
>>        RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
>> RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
>> Calibrating delay loop (skipped) already calibrated this CPU6.00 BogoMIPS (lpj=30000)
>> NR_IRQS:16 nr_irqs:16 16
>> Switching to timer-based delay loop
>> sched_clock: 32 bits at 3000kHz,
>> [000001d8] *pgd=00000000
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> Modules linked in:
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> [00000008] *pgd=00000000
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>> Modules linked in:
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> [00000000] *pgd=00000000
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> Modules linked in:
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> [00000000] *pgd=00000000
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> Modules linked in:
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> [00000000] *pgd=00000000
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> Modules linked in:
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> nPU: PIPT / VIPT nonaliasing data cacCPhUe1,:  VfIaPiTl ealdia stion gc oimnes tornulctiinoe
>> Braoucghhet
>> m 1Ma chCiPnUes 
>> seSMlP::  CToomtaplu Loafb  S1B C-pirMoXc7es
>> asbo oatcctoivnastoelde  (6[.0e0a rBloygcooMnI0P]S )e.n
>> AClPeU:d 
>> 0c mCaP: UC(MsA:)  rsetsaerrtveedd  i3n20  SMViCB m oadte .ac
>> 0000
>> cheemvotrmyp fpso:l iciyn:it iDaaltiaz ecda
>> writealloc
>> On node 0 totalpages: 262144
>> aree_area_init_nVFoPde :s unpopdoer t0,  pvg0d.a3t:  80i9m71p1l0e0m,e nntoord 4e1_ meamr_chmitaepc taubr7e5 9200 0p
>> p 3  0D MvAa rzioannet :7  r2e0v4 85 
>> tes uspeidn cftorlr c ormee:m mianpi
>> i a lDiMzAe dz opnie:n c0t rpalge s sruebsseyrsvteedm
>> 
>> h DMAre guzloanteo:r -2d62u14m4m yp:a gneos ,p aLrIaFmOe tebrastc
>> 31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Binux version 3.14.52+ (ilya at ilya-pc) NE(Tg:c cR evgeirssiotne r4e.d 7pr.o2t (oScoolu fracmeirlyy  C1o6de
>> nch Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410DMfAc:0 7p5r]e arlelvoicsaitoend  52 5(6A RKMivB7 )p,o olc rf=1o0rc 5a3to8mi7cd 
>> ahCPeU:r PeInPt Ta l/ lVoIcaPtTi noonns
>> iasing datacp uciadclhee:,  uVsIPiTn g agloivaesirngn oir nlsatrducdteiro
>> : cpauicdhlee
>> mpMnagc hignoev emrnoodrel :m enCuo
>> abUs eS BWCD-iOMXG71
>>  rbeosoettc osnosuorlcee
>> [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> pysOcno nno d3e0 304 0t0o0t0.ailopmaugxecs-:g p2r6:2 r1eg4m4a
>> 11freeme _0axr3ea0_3i40n0i0t_0no-d0ex3:0 3no4dfef f0f, ]p grdeagti s8t0er9ed7
>> c, snyosdcoen_ m3e0m3_50m0a0p0 .aobc7o5t90p00-
>> el  :DM Ar ezgomanpe :[ m2e0m48  0pxa3g0e3s50 00u0s-ed0 xf3o0r3 5mfefmffm]a pr
>> o s teDrMeA dz
>> : 0 pagseyss croesne r3v0e3d6
>> 6f  0D.MaAn zaonteo:p:  2r6e2g1m4a4p  pa[gmeesm, 0 xL3I03F6O0 0b0a0t-c0hx:33013
>> ffPE]R CrePgiUs:t eErmbeedd
>> d1 8 pvdad1gp0eds:/ c8p0u0  @<a-b-7>3 1520000 0m Vs 8a3t2 01 0r080 1m9V2  
>> 056 vdud13p22:7 61810
>> x--B>o o1ti3n0g0  mLVin u
>> 30 physical CPUsy sc0oxn0 
>> 0L0i0n0ux. svrecr:si orne g3m.a1p4 .[m5em2 +0 x(3i0l39y0a0 at i0l0y-a0-xp3c0)3 9f(fgfccf ]v reergsiiosnt e4r.e7.d2
>> 9ourcery CodeDBDeRn cthy pLei itse  2D0D1R23.!0
>> -64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> sPU: ARMv7 Profacileesdso rt o[ 4f1i0nfdc 0o7c5o]tp  nroedvei
>> ofna i5l e(dAR Mtvo 7fi)n,d  corc=o1t0pc 5n38o7dd
>> e
>> ghUw: -PbIrPeTa k/p oViInPt:T f ounnodn a5l i(a+s1i nrge sdeartvae dc)a cbhree,a kVIpPTo ianltia sianngd  in4s twartucchtpiooinn tc archee
>> mtaecrhsi.ne
>> mhewl:- bCroemakppouiLnabt S:B Cm-aixMiXm7u
>> etcbhopooticnotn ssoilzee  [eiarsl y8c onb0]y teensab.l
>> d
>> 0ma: CMA: reserviemdx 73d2-0p iMnicBt ralt  3a0c20c00000000
>> dMoemmuoxrc-yl ppsorl:i icniyt:i Daaltizae dca chIeM X wpriintceatlrlloc 
>> noOenr 
>> 0 0 tiomtxa7ldp-apgiensc:t r2l6 320134340
>> .frieoem_uarxeac_:i inniitt_inoadlei: zneodd eI M0X,  ppigndcatt r8l0 9dr7i1v1e0r0,
>> ode_mem_map ab759000
>>  DMUM iAs  zroenaed:y  2f0o4r 8c rpoasgse sc oursee dco mfmourn imceatmimoanp!
>> 
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> tooting biLoi:n ucxr eaotne p hsylasbi ca<l bCiPoU- 00>x 0a
>> 0 
>> 2ux version 3.14.52+ (ilya at ilya-pc) (gcc vmexrss-idomna  43.37.020 00(0S0ou.rcdemray- aCpobdhe:B einnitciha Lliitzeed 
>> b2.09-64) us)b _#ot8g 1SM_P vPbRuEsE: M5P0T 0M0o mnV  Fe
>> 35 1f4e:c51_5p:h0y8_n rIeSTs e2t:0 136
>> 0 m[0V00 0
>> 04]pl a*tpgfd=o0r0m 0r0e0g0u0l0at
>> =1.P1U5::  DArRMiv7v ePrr orecg-efsisoxre d-[v4o10lftcag0e 7r5e]q ureevisstis opnr 5o (bAeR Mdve7f)e,r raclr
>> 453t8s7cd20
>> IreCPgU::  P3I3P00T m V/  V
>> T plnaotnfaolrima srienggu ldaattoar .c1a7c:h Der,i VvIePrT  reag-lfiiasxiend-gvo litnasgter urcetiqounes tcsa cpher
>> liM odedfuelrerasl 
>> rpleadt ifn:o
>> - lMcadc_hinnsetb y_m3ovde3l.:18 :C omDpruivLera br eSgBC--ifMiXxe7d
>> bboolottacgeo rnesqoulees [tesa rplroybec odn0e]f ereranla
>> ed
>> 0ma: CMASC:S Ir esusbesryvsedt 3e2m0 i nMiitBi aalti zace0d0
>> 00
>> ieusmbcoorrye :p orleigciys:te rDeatda  necwa chien twerritfeaaclel odcr
>> r Ouns bnofdse
>> etoustbaclopraeg:e sr:e g2i6s2t1e4r4
>> nefrwe ei_natreear_fianciet _dnordiev:e rn ohdeu b0
>> vpusgbdcato r8e0:97 11r0e0g,i stneordee_dm emn_emwa pd eabv7i5c9e0 d0r0i
>> r   uDMsAb 
>> oneus:bp h2y0_4n8o pp1.a1g0es  suuspepdl yf ovrc cm enmmoatp f
>> dd  ,DM Au siznogn ed: u0m mpayg erse gruelsaetrovre
>> 
>> nsb  pDMhA yz_onnoep:2 .21612 1s44u ppplayg evsc,c  LnIoFOt  bfaotuncdh,: u3s1i
>> edPuEmmRyC PrUeg:u lEamtbeodrd
>> 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>  DMA zone: 2048 pages used for memmap
>>  DMA zone: 0 pages reserved
>>  DMA zone: 262144 pages, LIFO batch:31
>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>> Booting Linux on physical CPU 0x0
>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> Machine model: CompuLab SBC-iMX7
>> bootconsole [earlycon0] enabled
>> cma: CMA: reserved 320 MiB at ac000000
>> Memory policy: Data cache writealloc
>> On node 0 totalpages: 262144
>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>> [00000000] *pgd=00000000
>>  DMA zone: 2048 pages used for memmap
> 

From edubezval at gmail.com  Thu Feb 18 07:15:54 2016
From: edubezval at gmail.com (Eduardo Valentin)
Date: Thu, 18 Feb 2016 07:15:54 -0800
Subject: [PATCH 2/3] thermal: Add Mediatek thermal controller support
In-Reply-To: <20160218105603.GE3939@pengutronix.de>
References: <1448883753-19068-1-git-send-email-s.hauer@pengutronix.de>
 <1448883753-19068-3-git-send-email-s.hauer@pengutronix.de>
 <20151217193332.GB7999@localhost.localdomain>
 <20160104141940.GI13058@pengutronix.de>
 <20160119072917.GA13237@pengutronix.de>
 <1454295246.22151.6.camel@mtksdaap41>
 <CAGS+omD9U8tKmb02d_gMMAGX18MJZhz0RrugpBK2EuqgZrBy6g@mail.gmail.com>
 <CAGS+omArr0_-ziBXWjEcKS0bqnruNzZc2aq2s3zkghUC7_HfGw@mail.gmail.com>
 <56C4A875.6080908@gmail.com> <20160218105603.GE3939@pengutronix.de>
Message-ID: <20160218151552.GA1852@localhost.localdomain>

Folks,

On Thu, Feb 18, 2016 at 11:56:03AM +0100, Sascha Hauer wrote:
> On Wed, Feb 17, 2016 at 06:05:57PM +0100, Matthias Brugger wrote:
> > 
> > 
> > On 15/02/16 03:14, Daniel Kurtz wrote:
> > >On Mon, Feb 15, 2016 at 10:11 AM, Daniel Kurtz <djkurtz at chromium.org> wrote:
> > >>Hi Eduardo, Sascha,
> > >>
> > >>>>Any input on this? I really like to get this driver upstream as it is
> > >>>>currently blocking other Mediatek drivers.
> > >>>>
> > >>>
> > >>>Hi Eduardo,
> > >>>
> > >>>Do you have any comment about Sascha's response ? We really hope get
> > >>>your comment since Mediatek thermal driver already reviewed in public
> > >>>over half years, and we have other patches [0] [1] depend on thermal
> > >>>driver.
> > >>>
> > >>>[0]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/394084.html
> > >>>[1]:
> > >>>http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401055.html
> > >>
> > >>Friendly ping on the Mediatek thermal driver.
> > >>The "EFUSE" dependency has now landed in v4.5-rc4.
> > >
> > >Actually, it landed in char-misc-next, not v4.5-rc4.
> > >
> > >>So, AFAICT, the only thing left that may be blocking landing Mediatek
> > >>thermal driver is resolution of this discussion about thermal zones.
> > >>Can we kindly resolve this soon so we have a chance to land it in v4.6.
> > >>
> > 
> > 
> > I think the problem is, that Eduardo wants to see the hierachical thermal
> > zones being used. But there is still a discussion ongoing [1].
> 
> It seems the original Author lost interest in the hierarchical thermal
> zones. I am not convinced that we need hierarchical thermal zones for
> the Mediatek driver since from the five sensors we only need the maximum
> temperature (If this ever changes we could still rework it).
> 
> Given the current speed of communication I am not willing to add
> another, possibly controversal, dependency to an otherwise simple
> driver. I am even less willing when concerns like these come after *v12*
> of this series.
> 
> Eduardo, it would really help to get a word from you.

Apologize for the long delays here. In fact I want the hierarchical
support on this driver. But given that it is not really a strong
dependency and the hierarchical support is still an ongoing development,
I don't see why we should not merge this driver.

I also have had the chance to try it out in a board, and seams to work
for me. I am adding to my tree.

Thanks for the perseverance. :-)

> 
> Sascha
> 
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From arnd at arndb.de  Thu Feb 18 07:18:59 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 16:18:59 +0100
Subject: [PATCH 2/9] ARM: change NR_IPIS to 8
In-Reply-To: <20160218143709.GQ19428@n2100.arm.linux.org.uk>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-3-git-send-email-arnd@arndb.de>
 <20160218143709.GQ19428@n2100.arm.linux.org.uk>
Message-ID: <2915766.O3WEnikESX@wuerfel>

On Thursday 18 February 2016 14:37:09 Russell King - ARM Linux wrote:
> On Thu, Feb 18, 2016 at 03:01:54PM +0100, Arnd Bergmann wrote:
> > When function tracing for IPIs is enabled, we get a warning for an
> > overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
> > as triggered by raise_nmi():
> > 
> > arch/arm/kernel/smp.c: In function 'raise_nmi':
> > arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds [-Werror=array-bounds]
> >   trace_ipi_raise(target, ipi_types[ipinr]);
> 
> We really don't want to treat the backtrace IPI as a normal IPI at all -
> we want it to invoke the least amount of code possible.  Hence this code
> which avoids the issue:
> 
>         if ((unsigned)ipinr < NR_IPI) {
>                 trace_ipi_entry_rcuidle(ipi_types[ipinr]);
>                 __inc_irq_stat(cpu, ipi_irqs[ipinr]);
>         }
> 
> However, what's missing is that the addition of tracing here missed
> that CPU_BACKTRACE is not to be traced.  The call in raise_nmi()
> should have been converted to __smp_cross_call() to avoid the
> tracing code.

I've replaced the patch locally with the version below now, and
will throw it into the randconfig build test infrastructure to
make sure I didn't screw up in an obvious way here.

	Arnd

>From 7528c9b0558fdf4de785e62e61f0dd2ffe874110 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd at arndb.de>
Date: Sun, 31 Jan 2016 22:26:21 +0100
Subject: [PATCH] ARM: prevent tracing IPI_CPU_BACKTRACE

When function tracing for IPIs is enabled, we get a warning for an
overflow of the ipi_types array with the IPI_CPU_BACKTRACE type
as triggered by raise_nmi():

arch/arm/kernel/smp.c: In function 'raise_nmi':
arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds [-Werror=array-bounds]
  trace_ipi_raise(target, ipi_types[ipinr]);

This is a correct warning as we actually overflow the array here.

This patch raise_nmi() to call __smp_cross_call() instead of
smp_cross_call(), to avoid calling into ftrace. For clarification,
I'm also adding a two new code comments describing how this one
is special.

The warning appears to have shown up after patch e7273ff49acf
("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI"), which
changed the number assignment from '15' to '8', but as far as I can
tell has existed since the IPI tracepoints were first introduced.
If we decide to backport this patch to stable kernels, we probably
need to backport e7273ff49acf as well.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI")
Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") # v3.17
Signed-off-by: Arnd Bergmann <arnd at arndb.de>

diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
index 3d7351c844aa..2fd0a2619b0b 100644
--- a/arch/arm/include/asm/hardirq.h
+++ b/arch/arm/include/asm/hardirq.h
@@ -5,6 +5,7 @@
 #include <linux/threads.h>
 #include <asm/irq.h>
 
+/* number of IPIS _not_ including IPI_CPU_BACKTRACE */
 #define NR_IPI	7
 
 typedef struct {
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index b4048e370730..9802a94260db 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -72,6 +72,10 @@ enum ipi_msg_type {
 	IPI_CPU_STOP,
 	IPI_IRQ_WORK,
 	IPI_COMPLETION,
+	/*
+	 * CPU_BACKTRACE is special and not included in NR_IPI
+	 * or tracable with trace_ipi_*
+	 */
 	IPI_CPU_BACKTRACE,
 	/*
 	 * SGI8-15 can be reserved by secure firmware, and thus may
@@ -757,7 +761,7 @@ static void raise_nmi(cpumask_t *mask)
 	if (cpumask_test_cpu(smp_processor_id(), mask) && irqs_disabled())
 		nmi_cpu_backtrace(NULL);
 
-	smp_cross_call(mask, IPI_CPU_BACKTRACE);
+	__smp_cross_call(mask, IPI_CPU_BACKTRACE);
 }
 
 void arch_trigger_all_cpu_backtrace(bool include_self)



From eric.auger at linaro.org  Thu Feb 18 07:22:28 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 18 Feb 2016 16:22:28 +0100
Subject: [RFC v3 05/15] iommu/arm-smmu: implement
 alloc/free_reserved_iova_domain
In-Reply-To: <56C5A65D.5010401@arm.com>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
 <1455264797-2334-6-git-send-email-eric.auger@linaro.org>
 <56C5A65D.5010401@arm.com>
Message-ID: <56C5E1B4.20905@linaro.org>

Hi Robin,
On 02/18/2016 12:09 PM, Robin Murphy wrote:
> Hi Eric,
> 
> On 12/02/16 08:13, Eric Auger wrote:
>> Implement alloc/free_reserved_iova_domain for arm-smmu. we use
>> the iova allocator (iova.c). The iova_domain is attached to the
>> arm_smmu_domain struct. A mutex is introduced to protect it.
> 
> The IOMMU API currently leaves IOVA management entirely up to the caller
I agree

> - VFIO is already managing its own IOVA space, so what warrants this
> being pushed all the way down to the IOMMU driver?
In practice, with upstreamed code, VFIO uses IOVA = GPA provided by the
user-space (corresponding to RAM regions) and does not allocate IOVA
itself. The IOVA is passed through the VFIO_IOMMU_MAP_DMA ioctl.

With that series we propose that the user-space provides a pool of
unused IOVA that can be used to map Host physical addresses (MSI frame
address). So effectively someone needs to use an iova allocator to
allocate within that window. This can be vfio or the iommu driver. But
in both cases this is a new capability introduced in either component.

In the first version of this series
(https://lkml.org/lkml/2016/1/26/371) I put this iova allocation in
vfio_iommu_type1. the vfio-pci driver then was using this vfio internal
API to overwrite the physical address written in the PCI device by the
MSI controller.

However I was advised by Alex to move things at a lower level
(http://www.spinics.net/lists/kvm/msg126809.html), IOMMU core or irq
remapping driver; also the MSI controller should directly program the
IOVA address in the PCI device.

On ARM, irq remapping is somehow abstracted in ITS driver. Also we need
that functionality in GICv2M so I eventually chose to put the
functionality in the IOMMU driver. Since iova.c is not compiled by
everyone and since that functionality is needed for a restricted set of
architectures, ARM/ARM64 & PowerPC I chose to implement this in arhc
specific code, for the time being in arm-smmu.c.

This allows the MSI controller to interact with the IOMMU API to bind
its MSI address. I think it may be feasible to have the MSI controller
interact with the vfio external user API but does it look better?

Assuming we can agree on the relevance of adding that functionality at
IOMMU API level, maybe we can create a separate .c file to share code
between arm-smmu and arm-smmu-v3.c? or even I could dare to add this
into the iommu generic part. What is your opinion?

 All I see here is
> abstract code with no hardware-specific details that'll have to be
> copy-pasted into other IOMMU drivers (e.g. SMMUv3), which strongly
> suggests it's the wrong place to do it.
> 
> As I understand the problem, VFIO has a generic "configure an IOMMU to
> point at an MSI doorbell" step to do in the process of attaching a
> device, which hasn't needed implementing yet due to VT-d's
> IOMMU_CAP_I_AM_ALSO_ACTUALLY_THE_MSI_CONTROLLER_IN_DISGUISE flag, which
> most of us have managed to misinterpret so far.

Maybe I misunderstood the above comment but I would say this is the
contrary: ie up to now, VFIO did not need to care about that issue since
MSI addresses were not mapped in the IOMMU on x86. Now they need to be
so we need to extend an existing API, would it be VFIO external user API
or IOMMU API. But please correct if I misunderstood you.

Also I found it more practical to have a all-in-one API doing both the
iova allocation and binding (dma_map_single like). the user of the API
does not have to care about the iommu page size.

Thanks for your time and looking forward to reading from you!

Best Regards

Eric

 AFAICS all the IOMMU
> driver should need to know about this is an iommu_map() call (which will
> want a slight extension[1] to make things behave properly). We should be
> fixing the abstraction to be less x86-centric, not hacking up all the
> ARM drivers to emulate x86 hardware behaviour in software.
> 
> Robin.
> 
> [1]:http://article.gmane.org/gmane.linux.kernel.cross-arch/30833
> 
>> Signed-off-by: Eric Auger <eric.auger at linaro.org>
>>
>> ---
>> v2 -> v3:
>> - select IOMMU_IOVA when ARM_SMMU or ARM_SMMU_V3 is set
>>
>> v1 -> v2:
>> - formerly implemented in vfio_iommu_type1
>> ---
>>   drivers/iommu/Kconfig    |  2 ++
>>   drivers/iommu/arm-smmu.c | 87
>> +++++++++++++++++++++++++++++++++++++++---------
>>   2 files changed, 74 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
>> index a1e75cb..1106528 100644
>> --- a/drivers/iommu/Kconfig
>> +++ b/drivers/iommu/Kconfig
>> @@ -289,6 +289,7 @@ config ARM_SMMU
>>       bool "ARM Ltd. System MMU (SMMU) Support"
>>       depends on (ARM64 || ARM) && MMU
>>       select IOMMU_API
>> +    select IOMMU_IOVA
>>       select IOMMU_IO_PGTABLE_LPAE
>>       select ARM_DMA_USE_IOMMU if ARM
>>       help
>> @@ -302,6 +303,7 @@ config ARM_SMMU_V3
>>       bool "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
>>       depends on ARM64 && PCI
>>       select IOMMU_API
>> +    select IOMMU_IOVA
>>       select IOMMU_IO_PGTABLE_LPAE
>>       select GENERIC_MSI_IRQ_DOMAIN
>>       help
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index c8b7e71..f42341d 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -42,6 +42,7 @@
>>   #include <linux/platform_device.h>
>>   #include <linux/slab.h>
>>   #include <linux/spinlock.h>
>> +#include <linux/iova.h>
>>
>>   #include <linux/amba/bus.h>
>>
>> @@ -347,6 +348,9 @@ struct arm_smmu_domain {
>>       enum arm_smmu_domain_stage    stage;
>>       struct mutex            init_mutex; /* Protects smmu pointer */
>>       struct iommu_domain        domain;
>> +    struct iova_domain        *reserved_iova_domain;
>> +    /* protects reserved domain manipulation */
>> +    struct mutex            reserved_mutex;
>>   };
>>
>>   static struct iommu_ops arm_smmu_ops;
>> @@ -975,6 +979,7 @@ static struct iommu_domain
>> *arm_smmu_domain_alloc(unsigned type)
>>           return NULL;
>>
>>       mutex_init(&smmu_domain->init_mutex);
>> +    mutex_init(&smmu_domain->reserved_mutex);
>>       spin_lock_init(&smmu_domain->pgtbl_lock);
>>
>>       return &smmu_domain->domain;
>> @@ -1446,22 +1451,74 @@ out_unlock:
>>       return ret;
>>   }
>>
>> +static int arm_smmu_alloc_reserved_iova_domain(struct iommu_domain
>> *domain,
>> +                           dma_addr_t iova, size_t size,
>> +                           unsigned long order)
>> +{
>> +    unsigned long granule, mask;
>> +    struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
>> +    int ret = 0;
>> +
>> +    granule = 1UL << order;
>> +    mask = granule - 1;
>> +    if (iova & mask || (!size) || (size & mask))
>> +        return -EINVAL;
>> +
>> +    if (smmu_domain->reserved_iova_domain)
>> +        return -EEXIST;
>> +
>> +    mutex_lock(&smmu_domain->reserved_mutex);
>> +
>> +    smmu_domain->reserved_iova_domain =
>> +        kzalloc(sizeof(struct iova_domain), GFP_KERNEL);
>> +    if (!smmu_domain->reserved_iova_domain) {
>> +        ret = -ENOMEM;
>> +        goto unlock;
>> +    }
>> +
>> +    init_iova_domain(smmu_domain->reserved_iova_domain,
>> +             granule, iova >> order, (iova + size - 1) >> order);
>> +
>> +unlock:
>> +    mutex_unlock(&smmu_domain->reserved_mutex);
>> +    return ret;
>> +}
>> +
>> +static void arm_smmu_free_reserved_iova_domain(struct iommu_domain
>> *domain)
>> +{
>> +    struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
>> +    struct iova_domain *iovad = smmu_domain->reserved_iova_domain;
>> +
>> +    if (!iovad)
>> +        return;
>> +
>> +    mutex_lock(&smmu_domain->reserved_mutex);
>> +
>> +    put_iova_domain(iovad);
>> +    kfree(iovad);
>> +
>> +    mutex_unlock(&smmu_domain->reserved_mutex);
>> +}
>> +
>>   static struct iommu_ops arm_smmu_ops = {
>> -    .capable        = arm_smmu_capable,
>> -    .domain_alloc        = arm_smmu_domain_alloc,
>> -    .domain_free        = arm_smmu_domain_free,
>> -    .attach_dev        = arm_smmu_attach_dev,
>> -    .detach_dev        = arm_smmu_detach_dev,
>> -    .map            = arm_smmu_map,
>> -    .unmap            = arm_smmu_unmap,
>> -    .map_sg            = default_iommu_map_sg,
>> -    .iova_to_phys        = arm_smmu_iova_to_phys,
>> -    .add_device        = arm_smmu_add_device,
>> -    .remove_device        = arm_smmu_remove_device,
>> -    .device_group        = arm_smmu_device_group,
>> -    .domain_get_attr    = arm_smmu_domain_get_attr,
>> -    .domain_set_attr    = arm_smmu_domain_set_attr,
>> -    .pgsize_bitmap        = -1UL, /* Restricted during device attach */
>> +    .capable            = arm_smmu_capable,
>> +    .domain_alloc            = arm_smmu_domain_alloc,
>> +    .domain_free            = arm_smmu_domain_free,
>> +    .attach_dev            = arm_smmu_attach_dev,
>> +    .detach_dev            = arm_smmu_detach_dev,
>> +    .map                = arm_smmu_map,
>> +    .unmap                = arm_smmu_unmap,
>> +    .map_sg                = default_iommu_map_sg,
>> +    .iova_to_phys            = arm_smmu_iova_to_phys,
>> +    .add_device            = arm_smmu_add_device,
>> +    .remove_device            = arm_smmu_remove_device,
>> +    .device_group            = arm_smmu_device_group,
>> +    .domain_get_attr        = arm_smmu_domain_get_attr,
>> +    .domain_set_attr        = arm_smmu_domain_set_attr,
>> +    .alloc_reserved_iova_domain    =
>> arm_smmu_alloc_reserved_iova_domain,
>> +    .free_reserved_iova_domain    = arm_smmu_free_reserved_iova_domain,
>> +    /* Page size bitmap, restricted during device attach */
>> +    .pgsize_bitmap            = -1UL,
>>   };
>>
>>   static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
>>
> 



From frank.li at nxp.com  Thu Feb 18 07:24:50 2016
From: frank.li at nxp.com (Frank Li)
Date: Thu, 18 Feb 2016 15:24:50 +0000
Subject: iMX7d cpu1 issue
In-Reply-To: <20160218140913.GY6756@tiger>
References: <56C2D63F.1030408@compulab.co.il> <20160218140913.GY6756@tiger>
Message-ID: <AMSPR04MB263D00A3F8D9A8D9D3A536D88AF0@AMSPR04MB263.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo at kernel.org]
> Sent: Thursday, February 18, 2016 8:09 AM
> To: Ilya Ledvich <ilya at compulab.co.il>
> Cc: linux-arm-kernel at lists.infradead.org; Frank Li <frank.li at nxp.com>;
> Yongcai Huang <anson.huang at nxp.com>
> Subject: Re: iMX7d cpu1 issue
> 
> On Tue, Feb 16, 2016 at 09:56:47AM +0200, Ilya Ledvich wrote:
> > Hi Shawn,
> > I'm working on Compulab CL-SOM-IMX7 device
> > (http://www.compulab.co.il/products/computer-on-modules/cl-som-
> imx7-fr
> > eescale-i-mx-7-system-on-module)
> > based on Freescale iMX7d CPU.
> > I use the Freescale latest BSP imx_3.14.52_1.1.0_ga  and the Linux
> > mainline v4.4-rc6 as a reference.
> > I observe an issue with bringing up the second CPU core. Briefly, the
> > kernel can successfully boot only when CPU1 fails to come online.
> > In this case the boot log shows the following messages:
> > ...
> > CPU1: failed to come online
> > Brought up 1 CPUs
> > SMP: Total of 1 processors activated (6.00 BogoMIPS).
> > ...
> >
> > Otherwise, the device tries to start kernel several times until the
> > boot process eventually crashes. Please see attached logs for more
> > details.
> > This never happens on mainline Linus kernel, because it never tries to
> > bring up CPU1.
> > Unfortunately, we cannot verify this behavior on reference board cause
> > we have no one.
> > Have you ever seen such behavior? Could you please advice something?

Did you set arm,cpu-registers-not-fw-configured; in arch timer?
How about your uboot version?

Latest upstream uboot already boot A7 as no-security mode.

Best regards
Frank Li

> 
> I never played i.MX7D support on any real hardware.  I copied a couple
> Freescale/NXP people here.  Let's see if you can get some help from them.
> 
> Shawn
> 
> > Starting kernel ...
> >
> > Uncompressing Linux... done, booting the kernel.
> > Booting Linux on physical CPU 0x0
> > Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery
> > CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST
> > 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Built
> > 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
> > Kernel command line: console=ttymxc0,115200
> earlyprintk=ttymxc0,115200
> > root=/dev/nfs ip=dhcp
> > nfsroot=192.168.11.24:/home/ilya/work/rootfs/sid-minbase,v3,tcp rw
> > rootwait PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry
> > cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache
> > hash table entries: 65536 (order: 6, 262144 bytes)
> > Memory: 700996K/1048576K available (6617K kernel code, 353K rwdata,
> > 2280K rodata, 384K init, 421K bss, 347580K reserved, 0K highmem) Virtual
> kernel memory layout:
> >     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> >     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> >     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
> >     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
> >     pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)
> >     modules : 0x7f000000 - 0x7fe00000   (  14 MB)
> >       .text : 0x80008000 - 0x808b8880   (8899 kB)
> >       .init : 0x808b9000 - 0x80919080   ( 385 kB)
> >       .data : 0x8091a000 - 0x80972680   ( 354 kB)
> >        .bss : 0x8097268c - 0x809dbc00   ( 422 kB)
> > SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> Preemptible
> > hierarchical RCU implementation.
> >         RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
> > RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
> > NR_IRQS:16 nr_irqs:16 16
> > Switching to timer-based delay loop
> > sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every
> > 1431655765682ns Architected cp15 timer(s) running at 8.00MHz (phys).
> > sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every
> > 2147483648000ns Ignoring duplicate/late registration of
> > read_current_timer delay
> > Console: colour dummy device 80x30
> > Calibrating delay loop (skipped), value calculated using timer
> > frequency.. 6.00 BogoMIPS (lpj=30000)
> > pid_max: default: 32768 minimum: 301
> > Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
> > Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
> > CPU: Testing write buffer coherency: ok
> > /cpus/cpu at 0 missing clock-frequency property
> > /cpus/cpu at 1 missing clock-frequency property
> > CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 Setting up static
> > identity map for 0x80647850 - 0x806478a8 Switching to timer-based
> > delay loop Calibrating delay loop (skipped) already calibrated this
> > CPU6.00 BogoMIPS (lpj=30000)
> > sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every
> > 1431655765682ns Architected cp15 timer(s) running at 8.00MHz (phys).
> > 2147483648000ns
> > Current pid: 1 comm: swapper/0 / Idle pid: 0 comm: swapper/0 Ignoring
> > duplicate/late registra Booting Linux on physical CPU 0x0 Linux
> > version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench
> > Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc
> > CPU1: failed to come online
> > Brought up 1 CPUs
> > SMP: Total of 1 processors activated (6.00 BogoMIPS).
> > CPU: All CPU(s) started in SVC mode.
> > devtmpfs: initialized
> > VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev
> > 5 pinctrl core: initialized pinctrl subsystem
> > regulator-dummy: no parameters
> > NET: Registered protocol family 16
> > DMA: preallocated 256 KiB pool for atomic coherent allocations
> > cpuidle: using governor ladder
> > cpuidle: using governor menu
> > Use WDOG1 as reset source
> > syscon 30340000.iomuxc-gpr: regmap [mem 0x30340000-0x3034ffff]
> > registered syscon 30350000.ocotp-ctrl: regmap [mem
> > 0x30350000-0x3035ffff] registered syscon 30360000.anatop: regmap
> [mem
> > 0x30360000-0x3036ffff] registered
> > vdd1p0d: 800 <--> 1200 mV at 1000 mV
> > vdd1p2: 1100 <--> 1300 mV
> > syscon 30390000.src: regmap [mem 0x30390000-0x3039ffff] registered
> DDR
> > type is DDR3!
> > failed to find ocotp node
> > failed to find ocotp node
> > hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint
> registers.
> > hw-breakpoint: maximum watchpoint size is 8 bytes.
> > imx7d-pinctrl 302c0000.iomuxc-lpsr: initialized IMX pinctrl driver
> > imx7d-pinctrl 30330000.iomuxc: initialized IMX pinctrl driver MU is
> > ready for cross core communication!
> > bio: create slab <bio-0> at 0
> > mxs-dma 33000000.dma-apbh: initialized
> > usb_otg1_vbus: 5000 mV
> > fec1_phy_nreset: 3300 mV
> > platform regulator.15: Driver reg-fixed-voltage requests probe
> > deferral
> > tsc2046-reg: 3300 mV
> > platform regulator.17: Driver reg-fixed-voltage requests probe
> > deferral platform lcd_nstby_3v3.18: Driver reg-fixed-voltage requests
> > probe deferral SCSI subsystem initialized
> > usbcore: registered new interface driver usbfs
> > usbcore: registered new interface driver hub
> > usbcore: registered new device driver usb
> > usbphy_nop1.10 supply vcc not found, using dummy regulator
> > usbphy_nop2.11 supply vcc not found, using dummy regulator i2c i2c-1:
> > IMX I2C adapter registered i2c i2c-3: IMX I2C adapter registered Linux
> > video capture interface: v2.00
> > pps_core: LinuxPPS API ver. 1 registered
> > pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti
> > <giometti at linux.it> PTP clock support registered MIPI CSI2 driver
> > module loaded Advanced Linux Sound Architecture Driver Initialized.
> > Switched to clocksource arch_sys_counter
> > cfg80211: Calling CRDA to update world regulatory domain
> > NET: Registered protocol family 2
> > TCP established hash table entries: 8192 (order: 3, 32768 bytes) TCP
> > bind hash table entries: 8192 (order: 4, 65536 bytes)
> > TCP: Hash tables configured (established 8192 bind 8192)
> > TCP: reno registered
> > UDP hash table entries: 512 (order: 2, 16384 bytes) UDP-Lite hash
> > table entries: 512 (order: 2, 16384 bytes)
> > NET: Registered protocol family 1
> > RPC: Registered named UNIX socket transport module.
> > RPC: Registered udp transport module.
> > RPC: Registered tcp transport module.
> > RPC: Registered tcp NFSv4.1 backchannel transport module.
> > imx rpmsg driver is registered.
> > Bus freq driver module loaded
> > futex hash table entries: 512 (order: 3, 32768 bytes)
> > VFS: Disk quotas dquot_6.5.2
> > Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
> > NFS: Registering the id_resolver key type Key type id_resolver
> > registered Key type id_legacy registered
> > jffs2: version 2.2. (NAND) ???? 2001-2006 Red Hat, Inc.
> > fuse init (API version 7.22)
> > msgmni has been set to 2009
> > io scheduler noop registered
> > io scheduler deadline registered
> > io scheduler cfq registered (default)
> > backlight.20 supply power not found, using dummy regulator MIPI DSI
> > driver module loaded 30730000.lcdif supply lcd not found, using dummy
> > regulator mxsfb 30730000.lcdif: failed to find mxc display driver
> > Console: switching to colour frame buffer device 100x30 mxsfb
> > 30730000.lcdif: initialized imx-sdma 30bd0000.sdma: no event needs to
> > be remapped imx-sdma 30bd0000.sdma: loaded firmware 4.1 imx-sdma
> > 30bd0000.sdma: initialized pfuze100-regulator 1-0008: Full layer: 1,
> > Metal layer: 1 pfuze100-regulator 1-0008: FAB: 0, FIN: 0
> > pfuze100-regulator 1-0008: pfuze3000 found.
> > SW1A: 700 <--> 3300 mV at 1100 mV
> > SW1B: 700 <--> 1475 mV at 1000 mV
> > SW2: 1500 <--> 1850 mV at 1800 mV
> > SW3: 900 <--> 1650 mV at 1350 mV
> > SWBST: 5000 <--> 5150 mV at 5000 mV
> > VSNVS: 1000 <--> 3000 mV at 3000 mV
> > VREFDDR: 750 mV
> > VLDO1: 1800 <--> 3300 mV at 1800 mV
> > VLDO2: 800 <--> 1550 mV at 1500 mV
> > VCCSD: 2850 <--> 3300 mV at 3300 mV
> > V33: 2850 <--> 3300 mV at 3300 mV
> > VLDO3: 1800 <--> 3300 mV at 3300 mV
> > VLDO4: 1800 <--> 3300 mV at 3300 mV
> > Serial: IMX driver
> > 30860000.serial: ttymxc0 at MMIO 0x30860000 (irq = 58, base_baud =
> > 1500000) is a IMX console [ttymxc0] enabled bootconsole [earlycon0]
> > disabled
> > serial: Freescale lpuart driver
> > imx sema4 driver is registered.
> > [drm] Initialized drm 1.1.0 20060810
> > [drm] Initialized vivante 1.0.0 20120216 on minor 0
> > brd: module loaded
> > loop: module loaded
> > at24 1-0050: 1024 byte 24c08 EEPROM, writable, 16 bytes/write
> > m25p80 spi0.1: m25px16 (2048 Kbytes)
> > 3 ofpart partitions found on MTD device spi0.1 Creating 3 MTD
> > partitions on "spi0.1":
> > 0x000000000000-0x0000000c0000 : "uboot"
> > 0x0000000c0000-0x000000100000 : "uboot environment"
> > 0x000000100000-0x000000200000 : "splash"
> > spi_imx 30820000.ecspi: probed
> > 30be0000.ethernet supply phy not found, using dummy regulator pps
> > pps0: new PPS source ptp0
> > libphy: fec_enet_mii_bus: probed
> > fec 30be0000.ethernet eth0: registered PHC device 0 30bf0000.ethernet
> > supply phy not found, using dummy regulator pps pps1: new PPS source
> > ptp1 fec 30bf0000.ethernet (unregistered net_device): Invalid MAC
> > address: 00:00:00:00:00:00 fec 30bf0000.ethernet (unregistered
> > net_device): Using random MAC address: c2:a3:b7:db:4d:b0 fec
> > 30bf0000.ethernet eth1: registered PHC device 1
> > ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> > ehci-mxc: Freescale On-Chip EHCI Host driver
> > usbcore: registered new interface driver usb-storage 30b10200.usbmisc
> > supply vbus-wakeup not found, using dummy regulator 30b20200.usbmisc
> > supply vbus-wakeup not found, using dummy regulator 30b30200.usbmisc
> > supply vbus-wakeup not found, using dummy regulator 30b20000.usb
> > supply vbus not found, using dummy regulator ci_hdrc ci_hdrc.1: EHCI
> > Host Controller ci_hdrc ci_hdrc.1: new USB bus registered, assigned
> > bus number 1 ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00 hub
> > 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected imx_usb
> > 30b30000.usb: Can't register ci_hdrc platform device, err=-517
> > platform 30b30000.usb: Driver imx_usb requests probe deferral
> > mousedev: PS/2 mouse device common for all mice
> > input: 30370000.snvs-pwrkey as
> > /devices/soc.3/30000000.aips-bus/30370000.snvs-pwrkey/input/input0
> > snvs_pwrkey 30370000.snvs-pwrkey: i.MX snvs powerkey probed
> > rtc-em3027 1-0056: rtc core: registered rtc-em3027 as rtc0 snvs_rtc
> > 30370034.snvs-rtc-lp: rtc core: registered 30370034.snvs-rtc-l as rtc1
> > i2c /dev entries driver IR NEC protocol handler initialized IR RC5(x)
> > protocol handler initialized IR RC6 protocol handler initialized IR
> > JVC protocol handler initialized IR Sony protocol handler initialized
> > IR RC5 (streamzap) protocol handler initialized IR SANYO protocol
> > handler initialized IR MCE Keyboard/mouse protocol handler initialized
> > imx2-wdt 30280000.wdog: IMX2+ Watchdog Timer enabled. timeout=60s
> > (nowayout=0)
> > sdhci: Secure Digital Host Controller Interface driver
> > sdhci: Copyright(c) Pierre Ossman
> > sdhci-pltfm: SDHCI platform and OF driver helper sdhci-esdhc-imx
> > 30b40000.usdhc: could not get ultra high speed state, work on normal
> > mode
> > mmc0: no vqmmc regulator found
> > mmc0: no vmmc regulator found
> > mmc0: SDHCI controller on 30b40000.usdhc [30b40000.usdhc] using ADMA
> > sdhci-esdhc-imx 30b60000.usdhc: could not get ultra high speed state,
> > work on normal mode
> > mmc2: no vqmmc regulator found
> > mmc2: no vmmc regulator found
> > mmc0: new high speed SDHC card at address e624
> > mmc2: SDHCI controller on 30b60000.usdhc [30b60000.usdhc] using ADMA
> > mmcblk0: mmc0:e624 SS08G 7.40 GiB
> > usbcore: registered new interface driver usbhid
> > usbhid: USB HID core driver
> >  mmcblk0: unknown partition table
> > TCP: cubic registered
> > NET: Registered protocol family 10
> > sit: IPv6 over IPv4 tunneling driver
> > NET: Registered protocol family 17
> > Key type dns_resolver registered
> > usb 1-1: new high-speed USB device number 2 using ci_hdrc Registering
> > SWP/SWPB emulation handler
> > SWBST: disabling
> > usb_otg1_vbus: disabling
> > regulator-dummy: disabling
> > imx mcc test is registered.
> > fec2_phy_nreset: 3300 mV
> > usb_host_nreset: 3300 mV
> > lcd_nstby_3v3: no parameters
> > ci_hdrc ci_hdrc.2: EHCI Host Controller ci_hdrc ci_hdrc.2: new USB bus
> > registered, assigned bus number 2
> > mmc2: BKOPS_EN bit is not set
> > mmc2: new high speed DDR MMC card at address 0001
> > mmcblk2: mmc2:0001 SEM04G 3.68 GiB
> > mmcblk2boot0: mmc2:0001 SEM04G partition 1 2.00 MiB
> > mmcblk2boot1: mmc2:0001 SEM04G partition 2 2.00 MiB
> > mmcblk2rpmb: mmc2:0001 SEM04G partition 3 2.00 MiB
> >  mmcblk2: unknown partition table
> >  mmcblk2boot1: unknown partition table
> >  mmcblk2boot0: unknown partition table ci_hdrc ci_hdrc.2: USB 2.0
> > started, EHCI 1.00 hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port
> > detected Number of LUNs=8 Mass Storage Function, version: 2009/09/11
> > LUN: removable file: (no medium)
> > usb-storage 1-1:1.0: USB Mass Storage device detected
> > scsi0 : usb-storage 1-1:1.0
> > Number of LUNs=1
> > no file given for LUN0
> > g_mass_storage ci_hdrc.0: failed to start g_mass_storage: -22
> > rtc-em3027 1-0056: setting system clock to 2016-02-16 07:32:51 UTC
> > (1455607971) fec 30be0000.ethernet eth0: Freescale FEC PHY driver
> > [Atheros 8031 ethernet] (mii_bus:phy_addr=30be0000.etherne:00, irq=-1)
> > IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready fec
> > 30bf0000.ethernet eth1: Freescale FEC PHY driver [Atheros 8031
> > ethernet] (mii_bus:phy_addr=30be0000.etherne:01, irq=-1) usb 2-1: new
> > high-speed USB device number 2 using ci_hdrc
> > IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready hub 2-1:1.0: USB
> > hub found hub 2-1:1.0: 3 ports detected
> > scsi 0:0:0:0: Direct-Access     SanDisk  Cruzer Slice     1.14 PQ: 0 ANSI: 2
> > sd 0:0:0:0: [sda] 15633408 512-byte logical blocks: (8.00 GB/7.45 GiB)
> > sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] No Caching
> > mode page found sd 0:0:0:0: [sda] Assuming drive cache: write through
> > sd 0:0:0:0: [sda] No Caching mode page found sd 0:0:0:0: [sda]
> > Assuming drive cache: write through
> >  sda: unknown partition table
> > sd 0:0:0:0: [sda] No Caching mode page found sd 0:0:0:0: [sda]
> > Assuming drive cache: write through sd 0:0:0:0: [sda] Attached SCSI
> > removable disk
> > libphy: 30be0000.etherne:00 - Link is Up - 1000/Full
> > IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Sending
> DHCP
> > requests ., OK
> > IP-Config: Got DHCP answer from 10.1.1.240, my address is
> > 192.168.27.43
> > IP-Config: Complete:
> >      device=eth0, hwaddr=00:01:c0:1a:e9:13, ipaddr=192.168.27.43,
> mask=255.255.0.0, gw=192.168.0.110
> >      host=192.168.27.43, domain=compulab.local, nis-domain=(none)
> >      bootserver=10.1.1.247, rootserver=192.168.11.24, rootpath=
> >      nameserver0=192.168.10.13, nameserver1=10.1.1.247 ALSA device
> > list:
> >   No soundcards found.
> > VFS: Mounted root (nfs filesystem) on device 0:13.
> > devtmpfs: mounted
> > Freeing unused kernel memory: 384K (808b9000 - 80919000)
> > random: systemd urandom read with 58 bits of entropy available
> > systemd[1]: systemd 228 running in system mode. (+PAM +AUDIT
> +SELINUX
> > +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT
> +GNUTLS
> > +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
> > systemd[1]: Detected architecture arm.
> >
> > Welcome to Debian GNU/Linux stretch/sid!
> >
> 
> > Starting kernel ...
> >
> > Uncompressing Linux... done, booting the kernel.
> > Booting Linux on physical CPU 0x0
> > Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery
> > CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST
> > 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> Built
> > 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
> > Kernel command line: console=ttymxc0,115200
> earlyprintk=ttymxc0,115200
> > root=/dev/nfs ip=dhcp
> > nfsroot=192.168.11.24:/home/ilya/work/rootfs/sid-minbase,v3,tcp rw
> > rootwait PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry
> > cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache
> > hash table entries: 65536 (order: 6, 262144 bytes)
> > Memory: 700996K/1048576K available (6617K kernel code, 353K rwdata,
> > 2280K rodata, 384K init, 421K bss, 347580K reserved, 0K highmem) Virtual
> kernel memory layout:
> >     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> >     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> >     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
> >     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
> >     pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)
> >     modules : 0x7f000000 - 0x7fe00000   (  14 MB)
> >       .text : 0x80008000 - 0x808b8880   (8899 kB)
> >       .init : 0x808b9000 - 0x80919080   ( 385 kB)
> >       .data : 0x8091a000 - 0x80972680   ( 354 kB)
> >        .bss : 0x8097268c - 0x809dbc00   ( 422 kB)
> > SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> Preemptible
> > hierarchical RCU implementation.
> >         RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
> > RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
> > NR_IRQS:16 nr_irqs:16 16
> > Switching to timer-based delay loop
> > sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every
> > 1431655765682ns Architected cp15 timer(s) running at 8.00MHz (phys).
> > sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every
> > 2147483648000ns Ignoring duplicate/late registration of
> > read_current_timer delay
> > Console: colour dummy device 80x30
> > Calibrating delay loop (skipped), value calculated using timer
> > frequency.. 6.00 BogoMIPS (lpj=30000)
> > pid_max: default: 32768 minimum: 301
> > Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
> > Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
> > CPU: Testing write buffer coherency: ok
> > /cpus/cpu at 0 missing clock-frequency property
> > /cpus/cpu at 1 missing clock-frequency property
> > CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 Setting up static
> > identity map for 0x80647850 - 0x806478a8
> > Memory: 700996K/1048576K available (6617K kernel code, 353K rwdata,
> > 2280K rodata, 384K init, 421K bss, 347580K reserved, 0K highmem) Virtual
> kernel memory layout:
> >     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> >     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> >     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
> >     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
> >     pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)
> >     modules : 0x7f000000 - 0x7fe00000   (  14 MB)
> >       .text : 0x80008000 - 0x808b8880   (8899 kB)
> >       .init : 0x808b9000 - 0x80919080   ( 385 kB)
> >       .data : 0x8091a000 - 0x80972680   ( 354 kB)
> >        .bss : 0x8097268c - 0x809dbc00   ( 422 kB)
> > SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> Preemptible
> > hierarchical RCU implementation.
> >         RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
> > RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
> > Calibrating delay loop (skipped) already calibrated this CPU6.00
> > BogoMIPS (lpj=30000)
> > NR_IRQS:16 nr_irqs:16 16
> > Switching to timer-based delay loop
> > sched_clock: 32 bits at 3000kHz,
> > [000001d8] *pgd=00000000
> > Booting Linux on physical CPU 0x0
> > Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery
> > CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST
> 2016 Modules linked in:
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144 [00000008] *pgd=00000000
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap Modules linked in:
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 [00000000] *pgd=00000000 Linux
> > version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench
> > Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > Modules linked in:
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache [00000000] *pgd=00000000 Machine model: CompuLab SBC-iMX7
> > bootconsole [earlycon0] enabled Modules linked in:
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache [00000000] *pgd=00000000 Machine model: CompuLab SBC-iMX7
> > bootconsole [earlycon0] enabled Modules linked in:
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > nPU: PIPT / VIPT nonaliasing data cacCPhUe1,:  VfIaPiTl ealdia stion
> > gc oimnes tornulctiinoe  Braoucghhet m 1Ma chCiPnUes
> > seSMlP::  CToomtaplu Loafb  S1B C-pirMoXc7es asbo oatcctoivnastoelde
> > (6[.0e0a rBloygcooMnI0P]S )e.n AClPeU:d 0c mCaP: UC(MsA:)
> > rsetsaerrtveedd  i3n20  SMViCB m oadte .ac
> > 0000
> > cheemvotrmyp fpso:l iciyn:it iDaaltiaz ecda  writealloc On node 0
> > totalpages: 262144 aree_area_init_nVFoPde :s unpopdoer t0,  pvg0d.a3t:
> > 80i9m71p1l0e0m,e nntoord 4e1_ meamr_chmitaepc taubr7e5 9200 0p p 3
> 0D
> > MvAa rzioannet :7  r2e0v4 85 tes uspeidn cftorlr c ormee:m mianpi i a
> > lDiMzAe dz opnie:n c0t rpalge s sruebsseyrsvteedm
> >
> > h DMAre guzloanteo:r -2d62u14m4m yp:a gneos ,p aLrIaFmOe tebrastc
> > 31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Binux version 3.14.52+
> > (ilya at ilya-pc) NE(Tg:c cR evgeirssiotne r4e.d 7pr.o2t (oScoolu
> > fracmeirlyy  C1o6de nch Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15
> > 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410DMfAc:0 7p5r]e arlelvoicsaitoend  52 5(6A
> > RKMivB7 )p,o olc rf=1o0rc 5a3to8mi7cd ahCPeU:r PeInPt Ta l/ lVoIcaPtTi
> > noonns iasing datacp uciadclhee:,  uVsIPiTn g agloivaesirngn oir
> > nlsatrducdteiro
> > : cpauicdhlee
> > mpMnagc hignoev emrnoodrel :m enCuo
> >  abUs eS BWCD-iOMXG71
> >   rbeosoettc osnosuorlcee
> > [earlycon0] enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc pysOcno nno d3e0 304 0t0o0t0.ailopmaugxecs-:g p2r6:2
> > r1eg4m4a 11freeme _0axr3ea0_3i40n0i0t_0no-d0ex3:0 3no4dfef f0f, ]p
> > grdeagti s8t0er9ed7 c, snyosdcoen_ m3e0m3_50m0a0p0 .aobc7o5t90p00-
> el
> > :DM Ar ezgomanpe :[ m2e0m48  0pxa3g0e3s50 00u0s-ed0 xf3o0r3
> > 5mfefmffm]a pr o s teDrMeA dz
> > : 0 pagseyss croesne r3v0e3d6
> > 6f  0D.MaAn zaonteo:p:  2r6e2g1m4a4p  pa[gmeesm, 0 xL3I03F6O0
> > 0b0a0t-c0hx:33013 ffPE]R CrePgiUs:t eErmbeedd
> > d1 8 pvdad1gp0eds:/ c8p0u0  @<a-b-7>3 1520000 0m Vs 8a3t2 01 0r080
> > 1m9V2
> > 056 vdud13p22:7 61810
> > x--B>o o1ti3n0g0  mLVin u
> > 30 physical CPUsy sc0oxn0
> >  0L0i0n0ux. svrecr:si orne g3m.a1p4 .[m5em2 +0
> > x(3i0l39y0a0 at i0l0y-a0-xp3c0)3 9f(fgfccf ]v reergsiiosnt e4r.e7.d2
> > 9ourcery CodeDBDeRn cthy pLei itse  2D0D1R23.!0
> > -64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > sPU: ARMv7 Profacileesdso rt o[ 4f1i0nfdc 0o7c5o]tp  nroedvei ofna i5l
> > e(dAR Mtvo 7fi)n,d  corc=o1t0pc 5n38o7dd e
> > ghUw: -PbIrPeTa k/p oViInPt:T f ounnodn a5l i(a+s1i nrge sdeartvae
> > dc)a cbhree,a kVIpPTo ianltia sianngd  in4s twartucchtpiooinn tc
> > archee  mtaecrhsi.ne
> > mhewl:- bCroemakppouiLnabt S:B Cm-aixMiXm7u etcbhopooticnotn
> ssoilzee
> > [eiarsl y8c onb0]y teensab.l  d
> > 0ma: CMA: reserviemdx 73d2-0p iMnicBt ralt  3a0c20c00000000
> > dMoemmuoxrc-yl ppsorl:i icniyt:i Daaltizae dca chIeM X
> > wpriintceatlrlloc noOenr
> > 0 0 tiomtxa7ldp-apgiensc:t r2l6 320134340  .frieoem_uarxeac_:i
> > inniitt_inoadlei: zneodd eI M0X,  ppigndcatt r8l0 9dr7i1v1e0r0,
> > ode_mem_map ab759000
> >   DMUM iAs  zroenaed:y  2f0o4r 8c rpoasgse sc oursee dco mfmourn
> imceatmimoanp!
> >
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > tooting biLoi:n ucxr eaotne p hsylasbi ca<l bCiPoU- 00>x 0a
> > 0
> > 2ux version 3.14.52+ (ilya at ilya-pc) (gcc vmexrss-idomna  43.37.020
> > 00(0S0ou.rcdemray- aCpobdhe:B einnitciha Lliitzeed
> > b2.09-64) us)b _#ot8g 1SM_P vPbRuEsE: M5P0T 0M0o mnV  Fe
> > 35 1f4e:c51_5p:h0y8_n rIeSTs e2t:0 136
> > 0 m[0V00 0
> > 04]pl a*tpgfd=o0r0m 0r0e0g0u0l0at
> > =1.P1U5::  DArRMiv7v ePrr orecg-efsisoxre d-[v4o10lftcag0e 7r5e]q
> > ureevisstis opnr 5o (bAeR Mdve7f)e,r raclr
> > 453t8s7cd20
> > IreCPgU::  P3I3P00T m V/  V
> > T plnaotnfaolrima srienggu ldaattoar .c1a7c:h Der,i VvIePrT
> > reag-lfiiasxiend-gvo litnasgter urcetiqounes tcsa cpher liM
> > odedfuelrerasl rpleadt ifn:o
> > - lMcadc_hinnsetb y_m3ovde3l.:18 :C omDpruivLera br eSgBC--ifMiXxe7d
> > bboolottacgeo rnesqoulees [tesa rplroybec odn0e]f ereranla ed
> > 0ma: CMASC:S Ir esusbesryvsedt 3e2m0 i nMiitBi aalti zace0d0
> > 00
> > ieusmbcoorrye :p orleigciys:te rDeatda  necwa chien twerritfeaaclel
> > odcr  r Ouns bnofdse etoustbaclopraeg:e sr:e g2i6s2t1e4r4  nefrwe
> > ei_natreear_fianciet _dnordiev:e rn ohdeu b0 vpusgbdcato r8e0:97
> > 11r0e0g,i stneordee_dm emn_emwa pd eabv7i5c9e0 d0r0i
> > r   uDMsAb
> > oneus:bp h2y0_4n8o pp1.a1g0es  suuspepdl yf ovrc cm enmmoatp f
> dd  ,DM
> > Au siznogn ed: u0m mpayg erse gruelsaetrovre
> >
> > nsb  pDMhA yz_onnoep:2 .21612 1s44u ppplayg evsc,c  LnIoFOt
> > bfaotuncdh,: u3s1i edPuEmmRyC PrUeg:u lEamtbeodrd
> >  8 pages/cpu @ab735000 s8320 r8192 d16256 u32768 Booting Linux on
> > physical CPU 0x0 Linux version 3.14.52+ (ilya at ilya-pc) (gcc version
> > 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb
> 15
> > 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> >   DMA zone: 2048 pages used for memmap
> >   DMA zone: 0 pages reserved
> >   DMA zone: 262144 pages, LIFO batch:31
> > PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
> > Booting Linux on physical CPU 0x0 Linux version 3.14.52+
> > (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64)
> > ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
> > CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> > CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction
> > cache Machine model: CompuLab SBC-iMX7 bootconsole [earlycon0]
> enabled
> > cma: CMA: reserved 320 MiB at ac000000 Memory policy: Data cache
> > writealloc On node 0 totalpages: 262144
> > free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
> > [00000000] *pgd=00000000
> >   DMA zone: 2048 pages used for memmap
> >



From eric.auger at linaro.org  Thu Feb 18 07:26:22 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 18 Feb 2016 16:26:22 +0100
Subject: [RFC v3 02/15] vfio: expose MSI mapping requirement through
 VFIO_IOMMU_GET_INFO
In-Reply-To: <20160218093454.660b20c6@arm.com>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
 <1455264797-2334-3-git-send-email-eric.auger@linaro.org>
 <20160218093454.660b20c6@arm.com>
Message-ID: <56C5E29E.3040809@linaro.org>

Hi Marc,
On 02/18/2016 10:34 AM, Marc Zyngier wrote:
> On Fri, 12 Feb 2016 08:13:04 +0000
> Eric Auger <eric.auger at linaro.org> wrote:
> 
>> This patch allows the user-space to retrieve whether msi write
>> transaction addresses must be mapped. This is returned through the
>> VFIO_IOMMU_GET_INFO API and its new flag: VFIO_IOMMU_INFO_REQUIRE_MSI_MAP.
>>
>> Signed-off-by: Bharat Bhushan <Bharat.Bhushan at freescale.com>
>> Signed-off-by: Eric Auger <eric.auger at linaro.org>
>>
>> ---
>>
>> RFC v1 -> v1:
>> - derived from
>>   [RFC PATCH 3/6] vfio: Extend iommu-info to return MSIs automap state
>> - renamed allow_msi_reconfig into require_msi_mapping
>> - fixed VFIO_IOMMU_GET_INFO
>> ---
>>  drivers/vfio/vfio_iommu_type1.c | 26 ++++++++++++++++++++++++++
>>  include/uapi/linux/vfio.h       |  1 +
>>  2 files changed, 27 insertions(+)
>>
>> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
>> index 6f1ea3d..c5b57e1 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -255,6 +255,29 @@ static int vaddr_get_pfn(unsigned long vaddr, int prot, unsigned long *pfn)
>>  }
>>  
>>  /*
>> + * vfio_domains_require_msi_mapping: indicates whether MSI write transaction
>> + * addresses must be mapped
>> + *
>> + * returns true if it does
>> + */
>> +static bool vfio_domains_require_msi_mapping(struct vfio_iommu *iommu)
>> +{
>> +	struct vfio_domain *d;
>> +	bool ret;
>> +
>> +	mutex_lock(&iommu->lock);
>> +	/* All domains have same require_msi_map property, pick first */
>> +	d = list_first_entry(&iommu->domain_list, struct vfio_domain, next);
>> +	if (iommu_domain_get_attr(d->domain, DOMAIN_ATTR_MSI_MAPPING, NULL) < 0)
>> +		ret = false;
>> +	else
>> +		ret = true;
> 
> nit: this could be simplified as:
> 
> ret = (iommu_domain_get_attr(d->domain, DOMAIN_ATTR_MSI_MAPPING, NULL) == 0);
sure ;-)
> 
>> +	mutex_unlock(&iommu->lock);
>> +
>> +	return ret;
>> +}
>> +
>> +/*
>>   * Attempt to pin pages.  We really don't want to track all the pfns and
>>   * the iommu can only map chunks of consecutive pfns anyway, so get the
>>   * first page and all consecutive pages with the same locking.
>> @@ -997,6 +1020,9 @@ static long vfio_iommu_type1_ioctl(void *iommu_data,
>>  
>>  		info.flags = VFIO_IOMMU_INFO_PGSIZES;
>>  
>> +		if (vfio_domains_require_msi_mapping(iommu))
>> +			info.flags |= VFIO_IOMMU_INFO_REQUIRE_MSI_MAP;
>> +
>>  		info.iova_pgsizes = vfio_pgsize_bitmap(iommu);
>>  
>>  		return copy_to_user((void __user *)arg, &info, minsz);
>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>> index 7d7a4c6..43e183b 100644
>> --- a/include/uapi/linux/vfio.h
>> +++ b/include/uapi/linux/vfio.h
>> @@ -400,6 +400,7 @@ struct vfio_iommu_type1_info {
>>  	__u32	argsz;
>>  	__u32	flags;
>>  #define VFIO_IOMMU_INFO_PGSIZES (1 << 0)	/* supported page sizes info */
>> +#define VFIO_IOMMU_INFO_REQUIRE_MSI_MAP (1 << 1)/* MSI must be mapped */
>>  	__u64	iova_pgsizes;		/* Bitmap of supported page sizes */
>>  };
>>  
> 
> 
> FWIW:
> 
> Acked-by: Marc Zyngier <marc.zyngier at arm.com>
thanks

Eric
> 
> 	M.
> 



From eric.auger at linaro.org  Thu Feb 18 07:33:36 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 18 Feb 2016 16:33:36 +0100
Subject: [RFC v3 15/15] irqchip/gicv2m/v3-its-pci-msi: IOMMU map the MSI
 frame when needed
In-Reply-To: <20160218113307.2b263b10@arm.com>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
 <1455264797-2334-16-git-send-email-eric.auger@linaro.org>
 <20160218113307.2b263b10@arm.com>
Message-ID: <56C5E450.3010501@linaro.org>

Hi Marc,
On 02/18/2016 12:33 PM, Marc Zyngier wrote:
> On Fri, 12 Feb 2016 08:13:17 +0000
> Eric Auger <eric.auger at linaro.org> wrote:
> 
>> In case the msi_desc references a device attached to an iommu
>> domain, the msi address needs to be mapped in the IOMMU. Else any
>> MSI write transaction will cause a fault.
>>
>> gic_set_msi_addr detects that case and allocates an iova bound
>> to the physical address page comprising the MSI frame. This iova
>> then is used as the msi_msg address. Unset operation decrements the
>> reference on the binding.
>>
>> The functions are called in the irq_write_msi_msg ops implementation.
>> At that time we can recognize whether the msi is setup or teared down
>> looking at the msi_msg content. Indeed msi_domain_deactivate zeroes all
>> the fields.
>>
>> Signed-off-by: Eric Auger <eric.auger at linaro.org>
>>
>> ---
>>
>> v2 -> v3:
>> - protect iova/addr manipulation with CONFIG_ARCH_DMA_ADDR_T_64BIT and
>>   CONFIG_PHYS_ADDR_T_64BIT
>> - only expose gic_pci_msi_domain_write_msg in case CONFIG_IOMMU_API &
>>   CONFIG_PCI_MSI_IRQ_DOMAIN are set.
>> - gic_set/unset_msi_addr duly become static
>> ---
>>  drivers/irqchip/irq-gic-common.c         | 69 ++++++++++++++++++++++++++++++++
>>  drivers/irqchip/irq-gic-common.h         |  5 +++
>>  drivers/irqchip/irq-gic-v2m.c            |  7 +++-
>>  drivers/irqchip/irq-gic-v3-its-pci-msi.c |  5 +++
>>  4 files changed, 85 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
>> index f174ce0..46cd06c 100644
>> --- a/drivers/irqchip/irq-gic-common.c
>> +++ b/drivers/irqchip/irq-gic-common.c
>> @@ -18,6 +18,8 @@
>>  #include <linux/io.h>
>>  #include <linux/irq.h>
>>  #include <linux/irqchip/arm-gic.h>
>> +#include <linux/iommu.h>
>> +#include <linux/msi.h>
>>  
>>  #include "irq-gic-common.h"
>>  
>> @@ -121,3 +123,70 @@ void gic_cpu_config(void __iomem *base, void (*sync_access)(void))
>>  	if (sync_access)
>>  		sync_access();
>>  }
>> +
>> +#if defined(CONFIG_IOMMU_API) && defined(CONFIG_PCI_MSI_IRQ_DOMAIN)
>> +static int gic_set_msi_addr(struct irq_data *data, struct msi_msg *msg)
>> +{
>> +	struct msi_desc *desc = irq_data_get_msi_desc(data);
>> +	struct device *dev = msi_desc_to_dev(desc);
>> +	struct iommu_domain *d;
>> +	phys_addr_t addr;
>> +	dma_addr_t iova;
>> +	int ret;
>> +
>> +	d = iommu_get_domain_for_dev(dev);
>> +	if (!d)
>> +		return 0;
>> +#ifdef CONFIG_PHYS_ADDR_T_64BIT
>> +	addr = ((phys_addr_t)(msg->address_hi) << 32) | msg->address_lo;
>> +#else
>> +	addr = msg->address_lo;
>> +#endif
>> +
>> +	ret = iommu_get_single_reserved(d, addr, IOMMU_WRITE, &iova);
>> +
>> +	if (!ret) {
>> +		msg->address_lo = lower_32_bits(iova);
>> +		msg->address_hi = upper_32_bits(iova);
>> +	}
>> +	return ret;
>> +}
>> +
>> +
>> +static void gic_unset_msi_addr(struct irq_data *data)
>> +{
>> +	struct msi_desc *desc = irq_data_get_msi_desc(data);
>> +	struct device *dev;
>> +	struct iommu_domain *d;
>> +	dma_addr_t iova;
>> +
>> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>> +	iova = ((dma_addr_t)(desc->msg.address_hi) << 32) |
>> +		desc->msg.address_lo;
>> +#else
>> +	iova = desc->msg.address_lo;
>> +#endif
>> +
>> +	dev = msi_desc_to_dev(desc);
>> +	if (!dev)
>> +		return;
>> +
>> +	d = iommu_get_domain_for_dev(dev);
>> +	if (!d)
>> +		return;
>> +
>> +	iommu_put_single_reserved(d, iova);
>> +}
>> +
>> +void gic_pci_msi_domain_write_msg(struct irq_data *irq_data,
>> +				  struct msi_msg *msg)
>> +{
>> +	if (!msg->address_hi && !msg->address_lo && !msg->data)
>> +		gic_unset_msi_addr(irq_data); /* deactivate */
>> +	else
>> +		gic_set_msi_addr(irq_data, msg); /* activate, set_affinity */
>> +
>> +	pci_msi_domain_write_msg(irq_data, msg);
>> +}
> 
> So by doing that, you are specializing this infrastructure to PCI.
> If you hijacked irq_compose_msi_msg() instead, you'd have both
> platform and PCI MSI for the same price.
> 
> I can see a potential problem with the teardown of an MSI (I don't
> think the compose method is called on teardown), but I think this could
> be easily addressed.
Yes effectively this is the reason why I moved it from
irq_compose_msi_msg (my original implementation) to irq_write_msi_msg. I
noticed I had no way to detect the teardown whereas the
msi_domain_deactivate also calls irq_write_msi_msg which is quite
practical ;-) To be honest I need to further look at the non PCI
implementation.


> 
>> +#endif
>> +
>> diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
>> index fff697d..98681fd 100644
>> --- a/drivers/irqchip/irq-gic-common.h
>> +++ b/drivers/irqchip/irq-gic-common.h
>> @@ -35,4 +35,9 @@ void gic_cpu_config(void __iomem *base, void (*sync_access)(void));
>>  void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
>>  		void *data);
>>  
>> +#if defined(CONFIG_PCI_MSI_IRQ_DOMAIN) && defined(CONFIG_IOMMU_API)
>> +void gic_pci_msi_domain_write_msg(struct irq_data *irq_data,
>> +				  struct msi_msg *msg);
>> +#endif
>> +
>>  #endif /* _IRQ_GIC_COMMON_H */
>> diff --git a/drivers/irqchip/irq-gic-v2m.c b/drivers/irqchip/irq-gic-v2m.c
>> index c779f83..692d809 100644
>> --- a/drivers/irqchip/irq-gic-v2m.c
>> +++ b/drivers/irqchip/irq-gic-v2m.c
>> @@ -24,6 +24,7 @@
>>  #include <linux/of_pci.h>
>>  #include <linux/slab.h>
>>  #include <linux/spinlock.h>
>> +#include "irq-gic-common.h"
>>  
>>  /*
>>  * MSI_TYPER:
>> @@ -83,7 +84,11 @@ static struct irq_chip gicv2m_msi_irq_chip = {
>>  	.irq_mask		= gicv2m_mask_msi_irq,
>>  	.irq_unmask		= gicv2m_unmask_msi_irq,
>>  	.irq_eoi		= irq_chip_eoi_parent,
>> -	.irq_write_msi_msg	= pci_msi_domain_write_msg,
>> +#ifdef CONFIG_IOMMU_API
>> +	.irq_write_msi_msg	= gic_pci_msi_domain_write_msg,
>> +#else
>> +	.irq_write_msi_msg      = pci_msi_domain_write_msg,
>> +#endif
> 
> Irrespective of the way you implement the translation procedure, you
> should make this unconditional, and have the #ifdefery in the code that
> implements it.

OK

Thanks

Eric
> 
>>  };
>>  
>>  static struct msi_domain_info gicv2m_msi_domain_info = {
>> diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
>> index 8223765..690504e 100644
>> --- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
>> +++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
>> @@ -19,6 +19,7 @@
>>  #include <linux/of.h>
>>  #include <linux/of_irq.h>
>>  #include <linux/of_pci.h>
>> +#include "irq-gic-common.h"
>>  
>>  static void its_mask_msi_irq(struct irq_data *d)
>>  {
>> @@ -37,7 +38,11 @@ static struct irq_chip its_msi_irq_chip = {
>>  	.irq_unmask		= its_unmask_msi_irq,
>>  	.irq_mask		= its_mask_msi_irq,
>>  	.irq_eoi		= irq_chip_eoi_parent,
>> +#ifdef CONFIG_IOMMU_API
>> +	.irq_write_msi_msg	= gic_pci_msi_domain_write_msg,
>> +#else
>>  	.irq_write_msi_msg	= pci_msi_domain_write_msg,
>> +#endif
>>  };
>>  
>>  struct its_pci_alias {
> 
> Thanks,
> 
> 	M.
> 



From fcooper at ti.com  Thu Feb 18 07:33:58 2016
From: fcooper at ti.com (Franklin S Cooper Jr.)
Date: Thu, 18 Feb 2016 09:33:58 -0600
Subject: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS
In-Reply-To: <alpine.DEB.2.02.1602180652380.4792@utopia.booyaka.com>
References: <1433332284-10766-1-git-send-email-vigneshr@ti.com>
 <1433332284-10766-3-git-send-email-vigneshr@ti.com>
 <alpine.DEB.2.02.1507152029460.32764@utopia.booyaka.com>
 <55A7CE59.6010600@ti.com>
 <alpine.DEB.2.02.1508121700500.7154@utopia.booyaka.com>
 <56C4DB37.9090802@ti.com>
 <alpine.DEB.2.02.1602180652380.4792@utopia.booyaka.com>
Message-ID: <56C5E466.2030002@ti.com>

Hi Paul

On 02/18/2016 12:58 AM, Paul Walmsley wrote:
> Hi Franklin
>
> On Wed, 17 Feb 2016, Franklin S Cooper Jr. wrote:
>
>> On 08/31/2015 10:51 AM, Paul Walmsley wrote:
>>> On Thu, 16 Jul 2015, R, Vignesh wrote:
>>>> On 07/16/2015 03:24 AM, Paul Walmsley wrote:
>>>>> On Wed, 3 Jun 2015, Vignesh R wrote:
>>>>>
>>>>>> Add hwmod entries for the PWMSS on DRA7.
>>>>>>
>>>>>> Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock
>>>>>> equal to L4PER2_L3_GICLK/2(l3_iclk_div/2).
>>>>>> As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4,
>>>>>> clock source to PWMSS is L4PER2_L3_GICLK. But it is actually
>>>>>> L4PER2_L3_GICLK/2. The TRM does not show the division by 2.
>>>>> Is the divide-by-two coming from PWMSS_EPWM.EPWM_TBCTL[HSPCLKDIV]?  Or is 
>>>>> HSPCLKDIV a separate divider after the divide-by-2 you mention above?
>>>> No, it not related to HSPCLKDIV. The TRM wrongly states L4PER2_L3_GICLK
>>>> as clock input for PWMSS. But actually  L4PER2_L4_GICLK(=L3_GICLK/2) is
>>>> the clock input for PWMSS. This will be updated in TRM soon.
>>> OK
>>>
>>>>>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>>>>> @@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
>>>>>>  	},
>>>>>>  };
>>>>>>  
>>>>>> +/* pwmss  */
>>>>>> +static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
>>>>>> +	.rev_offs	= 0x0,
>>>>>> +	.sysc_offs	= 0x4,
>>>>>> +	.sysc_flags	= SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS,
>>>>> This doesn't match SPRUHZ6 Table 29-13 "PWMSS_SYSCONFIG".  There's no 
>>>>> RESETSTATUS bit.  There is a SOFTRESET bit. 
>>>>>
>>>>> Could you please confirm whether this is intentional?
>>>> sorry my bad... I will change this in v3.
>>> OK
>>>
>>>>>> +/* ecap0 */
>>>>>> +struct omap_hwmod dra7xx_ecap0_hwmod = {
>>>>>> +	.name		= "ecap0",
>>>>>> +	.class		= &dra7xx_ecap_hwmod_class,
>>>>>> +	.clkdm_name	= "l4per2_clkdm",
>>>>>> +	.main_clk	= "l4_root_clk_div",
>>>>> Looking at SPRUHZ6 Section 29.1.4.2 "PWMSS Modules Local Clock Gating", 
>>>>> there appears to be a local "mini-PRCM" for the PWMSS which implements 
>>>>> clock gating and reports back on the status of what I'd guess is the local 
>>>>> clock gating FSM.
>>>>>
>>>>> So from that point of view, you should probably create a clock driver that 
>>>>> manages both the clock gate request bit and the FSM status bit.  It should 
>>>>> be something that can be reused for the other PWMSS IP blocks.  Then 
>>>>> you'd create per-IP block clock nodes and set the main_clk to point to 
>>>>> that node.
>>>> Since, this register is within the config space of PWMSS, the individual
>>>> gating and reporting for the modules within PWMSS
>>>> (PWMSS_CLKCONFIG) is currently being taken care by pwm-tipwmss.c(almost
>>>> the sole function this driver is doing). It has been the same since
>>>> am335x. Adding new clock nodes will result in driver changes and also
>>>> changes to am335x, am437x (and other platforms) hwmod files. It also
>>>> involves adding new nodes to clocks.dtsi and it will be difficult to
>>>> maintain backward compatibility for older platforms. Is it not better to
>>>> keep this as is, in order to maintain consistency (with am335x, am437x
>>>> etc) and also that these clock bits are within IP's config space?
>>> It's certainly possible that we as maintainers didn't look closely enough 
>>> at the AM33xx data for the PWMSS when we merged it.  But if that's 
>>> incorrect too, then now is the time to fix this.  Otherwise it will never 
>>> get fixed, since each new group of people patching this code will keep 
>>> punting it off to the indeterminate future.
>>>
>>> In terms of hwmod data: based on the register maps in sections 29.4.3, 
>>> 29.3.3, and 29.2.3 of SPRUHZ6, none of these subdevices are hwmod devices.  
>>> They don't support the Highlander OCP registers, they have no individual 
>>> PRCM registers or register bitfields, and all of the idle and status 
>>> reporting is to the PWMSS top-level IP block itself.  So it looks to me 
>>> like the eCAP, eQEP, and ePWM modules should be registered via DT, rather 
>>> than via hwmod.  It looks like you can get away with using the 
>>> "simple-bus" abstraction, but you might ultimately have to define 
>>> something custom here.  However, the PWMSS top level subsystem, described 
>>> in section 29.1, does have the OCP registers, sideband signals, etc., and 
>>> thus should remain a hwmod-registered device (via DT).
>>>
>>> In terms of the clock data: based on section 29.1.4, section 29.1.5.2, 
>>> figure 29-3, and table 29-4, there are several clock gating control bits.  
>>> These should be modeled as clock nodes in the Linux common clock 
>>> framework.  Furthermore these registers are located inside the PWMSS 
>>> subsystem itself, and are only accessible when the PWMSS IP block is 
>>> functional in a PM runtime point of view: i.e., when the block is mapped 
>>> into memory space, clocked and out of reset, etc.  So the clock types for 
>>> the PWMSS_CFG IP block should most likely be implemented in the PWMSS 
>>> driver.  I think you'll still be able to define the clock node data itself 
>>> in DT, but this will probably need a closer look.  Ideally, since the 
>>> clock node register address data is the same for all three subsystem 
>>> instances, one would be able to simply include a DT include file three 
>>> times; but the DT binding data format may ultimately make this 
>>> impractical.
>>>
>>> In terms of the transition from the old approach to this approach, it ooks 
>>> to me like the first thing to do would be to convert
>>> drivers/pwm/pwm-tipwmss.c to define some clk_ops and register some clock
>>> nodes with the CCF.  You've got the meat of the clock gating control code
>>> there already.  Then the next thing to do would be to to get rid of
>>> pwmss_submodule_state_change() and use
>>> clk_{prepare,enable,disable,unprepare}*() in the drivers/pwm/pwm-ti*.c
>>> subdrivers instead.  All of that looks like it should be possible to  
>>> implement in a backwards-compatible way.  Then you'd convert the eCAP, 
>>> eQEP, and ePWM code to probe as platform_devices, driven from a simple-bus 
>>> or pwmss-bus or whatever in the DT data.  Naturally, the AM33xx/43xx data 
>>> should be fixed also.  
>> I am working on updating this patchset on behalf of Vignesh
>> based on your suggestion. During the process of converting
>> the pwm-tipwmss.c to be a clock provider I discovered that
>> there is an issue with the PWMSS local clock gates. For
>> example on AM437x if you run the below commands you will get
>> a " Custom Error: MASTER M2 (64-bit) TARGET L4_PER_0 (Read):
>> Data Access in User mode during Functional access" error.
>>
>> rmmod pwm_tiecap
>> rmmod pwm_bl
>> rmmod pwm_tiecap
>> modprobe pwm_tiecap
>> modprobe pwm_bl
>>
>> Full Log: http://pastebin.com/sEyy52HV
>>
>> On device powerup, the various PWMSS local clock gates are
>> "unlocked". The remove call in the ecap driver gates the
>> local PWMSS clock gate for the ecap. The probe of the ecap
>> driver "unlocks" the clock gate for the ecap. However, once
>> you try to access any of the ecap registers which is
>> indirectly accessed by the pwm_bl driver you will get an
>> error. This is because the ecap clock is still being gated.
> OK I'm not sure I understand what's going on, particularly the part about 
> locking and unlocking.  Are you saying that the pwm_bl driver calls into 
> the pwm_tiecap module to write to the PWMSS_CLKCONFIG registers to ungate 
> the ECAP clock, and then the hardware silently ignores the write?  If 
> that's the case, shouldn't we be seeing some warning messages from a 
> failure to ungate the clock from a subsequent PWMSS_CLKSTATUS poll?  Or am 
> I misunderstanding what's going on here?
Pwm-tipwmss.c exports a function
pwmss_submodule_state_change which interacts with
PWMSS_CLKCONFIG and PWMSS_CLKSTATUS registers. Both
pwm-tiehrpwm.c and pwm-tiecap.c calls this exported function
to unlock the gate at probe time and lock the gate when the
driver is removed.

So when the gate fails to be unlocked after it previously is
locked there isn't a way to know this via the
PWMSS_CLKSTATUS registers. So the driver "believes" that the
gate is unlocked and when pwm_bl runs it calls the
set_polarity function. Set_polarity in the case of AM437x gp
evm maps to the ecap's  ecap_pwm_set_polarity function call.
This call then attempts to write to the ecap registers which
results in the external abort since the clock to the ecap is
still gated.

When the ecap and tihrpwm driver request to unlock the clock
gate it already checks the XXX_CLK_EN_ACK bitfields within
CLKSTATUS and it shows that the clocks "should" be unlocked.
So there is an issue with the IP.

>> This has been verified by hardware folks on our side. Its
>> been determined these registers are not needed since they
>> were designed for devices that didn't have a PRCM.
>> Therefore, the current plan is to update the trms of
>> AM335x,AM437x,DRA7 and AM57x to make it clear that these
>> registers shouldn't be touched.
> OK 
>
>> I plan on sending a patch for the pwm-tipwmss.c driver
>> essentially removing anything that touches the
>> PWMSS_CLKCONFIG and PWMSS_CLKSTATUS registers. I will also
>> be sending a v3 version of this patch since I believe the
>> struct omap_hwmod dra7xx_ecap0_hwmod and similar entries you
>> had comments about before are ok to leave as is based on the
>> above findings.
> Including the comments regarding dra7xx_epwmss_sysc ?  

Yes, I plan on addressing the change Vignesh acknowledged
regarding changing RESETSTATUS to SOFTRESET. For your other
comments I believe he already explained why it has to be set
in that particular way. If there is anything that I missed
or something that isn't clear please let me know.
>
>
> - Paul



From marc.zyngier at arm.com  Thu Feb 18 07:47:19 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Feb 2016 15:47:19 +0000
Subject: [RFC v3 15/15] irqchip/gicv2m/v3-its-pci-msi: IOMMU map the MSI
 frame when needed
In-Reply-To: <56C5E450.3010501@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
 <1455264797-2334-16-git-send-email-eric.auger@linaro.org>
 <20160218113307.2b263b10@arm.com> <56C5E450.3010501@linaro.org>
Message-ID: <56C5E787.9070303@arm.com>

On 18/02/16 15:33, Eric Auger wrote:
> Hi Marc,
> On 02/18/2016 12:33 PM, Marc Zyngier wrote:
>> On Fri, 12 Feb 2016 08:13:17 +0000
>> Eric Auger <eric.auger at linaro.org> wrote:
>>
>>> In case the msi_desc references a device attached to an iommu
>>> domain, the msi address needs to be mapped in the IOMMU. Else any
>>> MSI write transaction will cause a fault.
>>>
>>> gic_set_msi_addr detects that case and allocates an iova bound
>>> to the physical address page comprising the MSI frame. This iova
>>> then is used as the msi_msg address. Unset operation decrements the
>>> reference on the binding.
>>>
>>> The functions are called in the irq_write_msi_msg ops implementation.
>>> At that time we can recognize whether the msi is setup or teared down
>>> looking at the msi_msg content. Indeed msi_domain_deactivate zeroes all
>>> the fields.
>>>
>>> Signed-off-by: Eric Auger <eric.auger at linaro.org>
>>>
>>> ---
>>>
>>> v2 -> v3:
>>> - protect iova/addr manipulation with CONFIG_ARCH_DMA_ADDR_T_64BIT and
>>>   CONFIG_PHYS_ADDR_T_64BIT
>>> - only expose gic_pci_msi_domain_write_msg in case CONFIG_IOMMU_API &
>>>   CONFIG_PCI_MSI_IRQ_DOMAIN are set.
>>> - gic_set/unset_msi_addr duly become static
>>> ---
>>>  drivers/irqchip/irq-gic-common.c         | 69 ++++++++++++++++++++++++++++++++
>>>  drivers/irqchip/irq-gic-common.h         |  5 +++
>>>  drivers/irqchip/irq-gic-v2m.c            |  7 +++-
>>>  drivers/irqchip/irq-gic-v3-its-pci-msi.c |  5 +++
>>>  4 files changed, 85 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
>>> index f174ce0..46cd06c 100644
>>> --- a/drivers/irqchip/irq-gic-common.c
>>> +++ b/drivers/irqchip/irq-gic-common.c
>>> @@ -18,6 +18,8 @@
>>>  #include <linux/io.h>
>>>  #include <linux/irq.h>
>>>  #include <linux/irqchip/arm-gic.h>
>>> +#include <linux/iommu.h>
>>> +#include <linux/msi.h>
>>>  
>>>  #include "irq-gic-common.h"
>>>  
>>> @@ -121,3 +123,70 @@ void gic_cpu_config(void __iomem *base, void (*sync_access)(void))
>>>  	if (sync_access)
>>>  		sync_access();
>>>  }
>>> +
>>> +#if defined(CONFIG_IOMMU_API) && defined(CONFIG_PCI_MSI_IRQ_DOMAIN)
>>> +static int gic_set_msi_addr(struct irq_data *data, struct msi_msg *msg)
>>> +{
>>> +	struct msi_desc *desc = irq_data_get_msi_desc(data);
>>> +	struct device *dev = msi_desc_to_dev(desc);
>>> +	struct iommu_domain *d;
>>> +	phys_addr_t addr;
>>> +	dma_addr_t iova;
>>> +	int ret;
>>> +
>>> +	d = iommu_get_domain_for_dev(dev);
>>> +	if (!d)
>>> +		return 0;
>>> +#ifdef CONFIG_PHYS_ADDR_T_64BIT
>>> +	addr = ((phys_addr_t)(msg->address_hi) << 32) | msg->address_lo;
>>> +#else
>>> +	addr = msg->address_lo;
>>> +#endif
>>> +
>>> +	ret = iommu_get_single_reserved(d, addr, IOMMU_WRITE, &iova);
>>> +
>>> +	if (!ret) {
>>> +		msg->address_lo = lower_32_bits(iova);
>>> +		msg->address_hi = upper_32_bits(iova);
>>> +	}
>>> +	return ret;
>>> +}
>>> +
>>> +
>>> +static void gic_unset_msi_addr(struct irq_data *data)
>>> +{
>>> +	struct msi_desc *desc = irq_data_get_msi_desc(data);
>>> +	struct device *dev;
>>> +	struct iommu_domain *d;
>>> +	dma_addr_t iova;
>>> +
>>> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>>> +	iova = ((dma_addr_t)(desc->msg.address_hi) << 32) |
>>> +		desc->msg.address_lo;
>>> +#else
>>> +	iova = desc->msg.address_lo;
>>> +#endif
>>> +
>>> +	dev = msi_desc_to_dev(desc);
>>> +	if (!dev)
>>> +		return;
>>> +
>>> +	d = iommu_get_domain_for_dev(dev);
>>> +	if (!d)
>>> +		return;
>>> +
>>> +	iommu_put_single_reserved(d, iova);
>>> +}
>>> +
>>> +void gic_pci_msi_domain_write_msg(struct irq_data *irq_data,
>>> +				  struct msi_msg *msg)
>>> +{
>>> +	if (!msg->address_hi && !msg->address_lo && !msg->data)
>>> +		gic_unset_msi_addr(irq_data); /* deactivate */
>>> +	else
>>> +		gic_set_msi_addr(irq_data, msg); /* activate, set_affinity */
>>> +
>>> +	pci_msi_domain_write_msg(irq_data, msg);
>>> +}
>>
>> So by doing that, you are specializing this infrastructure to PCI.
>> If you hijacked irq_compose_msi_msg() instead, you'd have both
>> platform and PCI MSI for the same price.
>>
>> I can see a potential problem with the teardown of an MSI (I don't
>> think the compose method is called on teardown), but I think this could
>> be easily addressed.
> Yes effectively this is the reason why I moved it from
> irq_compose_msi_msg (my original implementation) to irq_write_msi_msg. I
> noticed I had no way to detect the teardown whereas the
> msi_domain_deactivate also calls irq_write_msi_msg which is quite
> practical ;-) To be honest I need to further look at the non PCI
> implementation.

Another thing to consider is that MSI controllers may use different
doorbells for different CPU affinities. With your implementation,
repeatedly changing the affinity from one CPU to another would increase
the refcounting, and never actually lower it (you don't necessarily go
via an "unmap"). Of course, none of that applies to GICv2m/GICv3-ITS,
but that's worth considering.

So I think we may need some better tracking of the IOVA we program in
the device, and offer a generic infrastructure for this instead of
hiding it in the MSI controller drivers.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From edubezval at gmail.com  Thu Feb 18 07:50:25 2016
From: edubezval at gmail.com (Eduardo Valentin)
Date: Thu, 18 Feb 2016 07:50:25 -0800
Subject: [PATCH 1/1] thermal: small style cleanup in mtk_thermal
In-Reply-To: <1448883753-19068-1-git-send-email-s.hauer@pengutronix.de>
References: <1448883753-19068-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455810625-20509-1-git-send-email-edubezval@gmail.com>

Remove all checkpatch.pl --strict errors, checks, and warnings.

Cc: Zhang Rui <rui.zhang at intel.com>
Cc: Matthias Brugger <matthias.bgg at gmail.com>
Cc: linux-pm at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-mediatek at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: Eduardo Valentin <edubezval at gmail.com>
---
Sascha,

Add your v12 in my forlinus branch. But also, on top of it
I cleaned the patch further with the following patch.

BR,

Eduardo

 drivers/thermal/mtk_thermal.c | 56 ++++++++++++++++++++++---------------------
 1 file changed, 29 insertions(+), 27 deletions(-)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 589a138..3d93b1c 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -78,7 +78,7 @@
 
 #define TEMP_MONCTL1_PERIOD_UNIT(x)	((x) & 0x3ff)
 
-#define TEMP_MONCTL2_FILTER_INTERVAL(x)	(((x) & 0x3ff)) << 16
+#define TEMP_MONCTL2_FILTER_INTERVAL(x)	(((x) & 0x3ff) << 16)
 #define TEMP_MONCTL2_SENSOR_INTERVAL(x)	((x) & 0x3ff)
 
 #define TEMP_AHBPOLL_ADC_POLL_INTERVAL(x)	(x)
@@ -108,15 +108,15 @@
 #define MT8173_NUM_SENSORS_PER_ZONE	4
 
 /* Layout of the fuses providing the calibration data */
-#define MT8173_CALIB_BUF0_VALID		(1 << 0)
-#define MT8173_CALIB_BUF1_ADC_GE(x)	(((x) >> 22 ) & 0x3ff)
-#define MT8173_CALIB_BUF0_VTS_TS1(x)	(((x) >> 17 ) & 0x1ff)
-#define MT8173_CALIB_BUF0_VTS_TS2(x)	(((x) >> 8 ) & 0x1ff)
-#define MT8173_CALIB_BUF1_VTS_TS3(x)	(((x) >> 0 ) & 0x1ff)
-#define MT8173_CALIB_BUF2_VTS_TS4(x)	(((x) >> 23 ) & 0x1ff)
-#define MT8173_CALIB_BUF2_VTS_TSABB(x)	(((x) >> 14 ) & 0x1ff)
-#define MT8173_CALIB_BUF0_DEGC_CALI(x)	(((x) >> 1 ) & 0x3f)
-#define MT8173_CALIB_BUF0_O_SLOPE(x)	(((x) >> 26 ) & 0x3f)
+#define MT8173_CALIB_BUF0_VALID		BIT(0)
+#define MT8173_CALIB_BUF1_ADC_GE(x)	(((x) >> 22) & 0x3ff)
+#define MT8173_CALIB_BUF0_VTS_TS1(x)	(((x) >> 17) & 0x1ff)
+#define MT8173_CALIB_BUF0_VTS_TS2(x)	(((x) >> 8) & 0x1ff)
+#define MT8173_CALIB_BUF1_VTS_TS3(x)	(((x) >> 0) & 0x1ff)
+#define MT8173_CALIB_BUF2_VTS_TS4(x)	(((x) >> 23) & 0x1ff)
+#define MT8173_CALIB_BUF2_VTS_TSABB(x)	(((x) >> 14) & 0x1ff)
+#define MT8173_CALIB_BUF0_DEGC_CALI(x)	(((x) >> 1) & 0x3f)
+#define MT8173_CALIB_BUF0_O_SLOPE(x)	(((x) >> 26) & 0x3f)
 
 #define THERMAL_NAME    "mtk-thermal"
 
@@ -136,6 +136,7 @@ struct mtk_thermal {
 
 	struct mtk_thermal_bank banks[MT8173_NUM_ZONES];
 
+	/* lock: for getting and putting banks */
 	struct mutex lock;
 
 	/* Calibration values */
@@ -271,11 +272,9 @@ static void mtk_thermal_put_bank(struct mtk_thermal_bank *bank)
 static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank)
 {
 	struct mtk_thermal *mt = bank->mt;
-	int temp, i, max;
+	int i, temp = INT_MIN, max = INT_MIN;
 	u32 raw;
 
-	temp = max = INT_MIN;
-
 	for (i = 0; i < bank_data[bank->id].num_sensors; i++) {
 		raw = readl(mt->thermal_base + sensing_points[i].msr);
 
@@ -322,7 +321,7 @@ static const struct thermal_zone_of_device_ops mtk_thermal_ops = {
 };
 
 static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
-		u32 apmixed_phys_base, u32 auxadc_phys_base)
+				  u32 apmixed_phys_base, u32 auxadc_phys_base)
 {
 	struct mtk_thermal_bank *bank = &mt->banks[num];
 	const struct mtk_thermal_bank_cfg *cfg = &bank_data[num];
@@ -346,7 +345,7 @@ static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
 
 	/* poll is set to 10u */
 	writel(TEMP_AHBPOLL_ADC_POLL_INTERVAL(768),
-			mt->thermal_base + TEMP_AHBPOLL);
+	       mt->thermal_base + TEMP_AHBPOLL);
 
 	/* temperature sampling control, 1 sample */
 	writel(0x0, mt->thermal_base + TEMP_MSRCTL0);
@@ -375,49 +374,50 @@ static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
 
 	/* AHB address for auxadc mux selection */
 	writel(auxadc_phys_base + AUXADC_CON1_CLR_V,
-			mt->thermal_base + TEMP_ADCMUXADDR);
+	       mt->thermal_base + TEMP_ADCMUXADDR);
 
 	/* AHB address for pnp sensor mux selection */
 	writel(apmixed_phys_base + APMIXED_SYS_TS_CON1,
-			mt->thermal_base + TEMP_PNPMUXADDR);
+	       mt->thermal_base + TEMP_PNPMUXADDR);
 
 	/* AHB value for auxadc enable */
 	writel(BIT(MT8173_TEMP_AUXADC_CHANNEL), mt->thermal_base + TEMP_ADCEN);
 
 	/* AHB address for auxadc enable (channel 0 immediate mode selected) */
 	writel(auxadc_phys_base + AUXADC_CON1_SET_V,
-			mt->thermal_base + TEMP_ADCENADDR);
+	       mt->thermal_base + TEMP_ADCENADDR);
 
 	/* AHB address for auxadc valid bit */
 	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
-			mt->thermal_base + TEMP_ADCVALIDADDR);
+	       mt->thermal_base + TEMP_ADCVALIDADDR);
 
 	/* AHB address for auxadc voltage output */
 	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
-			mt->thermal_base + TEMP_ADCVOLTADDR);
+	       mt->thermal_base + TEMP_ADCVOLTADDR);
 
 	/* read valid & voltage are at the same register */
 	writel(0x0, mt->thermal_base + TEMP_RDCTRL);
 
 	/* indicate where the valid bit is */
 	writel(TEMP_ADCVALIDMASK_VALID_HIGH | TEMP_ADCVALIDMASK_VALID_POS(12),
-			mt->thermal_base + TEMP_ADCVALIDMASK);
+	       mt->thermal_base + TEMP_ADCVALIDMASK);
 
 	/* no shift */
 	writel(0x0, mt->thermal_base + TEMP_ADCVOLTAGESHIFT);
 
 	/* enable auxadc mux write transaction */
 	writel(TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
-			mt->thermal_base + TEMP_ADCWRITECTRL);
+	       mt->thermal_base + TEMP_ADCWRITECTRL);
 
 	for (i = 0; i < cfg->num_sensors; i++)
 		writel(sensor_mux_values[cfg->sensors[i]],
-				mt->thermal_base + sensing_points[i].adcpnp);
+		       mt->thermal_base + sensing_points[i].adcpnp);
 
 	writel((1 << cfg->num_sensors) - 1, mt->thermal_base + TEMP_MONCTL0);
 
-	writel(TEMP_ADCWRITECTRL_ADC_PNP_WRITE | TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
-			mt->thermal_base + TEMP_ADCWRITECTRL);
+	writel(TEMP_ADCWRITECTRL_ADC_PNP_WRITE |
+	       TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
+	       mt->thermal_base + TEMP_ADCWRITECTRL);
 
 	mtk_thermal_put_bank(bank);
 }
@@ -434,7 +434,8 @@ static u64 of_get_phys_base(struct device_node *np)
 	return of_translate_address(np, regaddr_p);
 }
 
-static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
+static int mtk_thermal_get_calibration_data(struct device *dev,
+					    struct mtk_thermal *mt)
 {
 	struct nvmem_cell *cell;
 	u32 *buf;
@@ -567,7 +568,8 @@ static int mtk_thermal_probe(struct platform_device *pdev)
 	}
 
 	for (i = 0; i < MT8173_NUM_ZONES; i++)
-		mtk_thermal_init_bank(mt, i, apmixed_phys_base, auxadc_phys_base);
+		mtk_thermal_init_bank(mt, i, apmixed_phys_base,
+				      auxadc_phys_base);
 
 	platform_set_drvdata(pdev, mt);
 
-- 
2.1.4



From edubezval at gmail.com  Thu Feb 18 07:53:02 2016
From: edubezval at gmail.com (Eduardo Valentin)
Date: Thu, 18 Feb 2016 07:53:02 -0800
Subject: [PATCH v12] Add Mediatek thermal support
In-Reply-To: <1448883753-19068-1-git-send-email-s.hauer@pengutronix.de>
References: <1448883753-19068-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <20160218155300.GA20378@localhost.localdomain>

On Mon, Nov 30, 2015 at 12:42:30PM +0100, Sascha Hauer wrote:
> This series adds support for the thermal sensors included in the
> MT8173 SoC. Currently only basic temperature reading is supported
> without any interrupt support.
> 

Merged v12.

> 
> 	fan: gpio_fan {
> 		compatible = "gpio-fan";
> 		gpios = <&pio 24 0>;
> 		gpio-fan,speed-map = <0    0
> 				      4500 1>;
> 		#cooling-cells = <2>;
> 	};
> 
> 	thermal-zones {
> 			cpu_thermal: cpu_thermal {
> 			polling-delay-passive = <1000>; /* milliseconds */
> 			polling-delay = <1000>; /* milliseconds */
> 
> 			thermal-sensors = <&thermal>;
> 
> 			trips {
> 				cpu_passive: cpu_passive {
> 					temperature = <47000>; /* millicelsius */
> 					hysteresis = <2000>; /* millicelsius */
> 					type = "passive";
> 				};
> 
> 				cpu_crit {
> 					temperature = <90000>; /* millicelsius */
> 					hysteresis = <2000>; /* millicelsius */
> 					type = "critical";
> 				};
> 			};
> 
> 			cooling-maps {
> 				map0 {
> 					trip = <&cpu_passive>;
> 					cooling-device = <&fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> 				};
> 			};
> 		};
> 	};

But, as usual, the dt changes go via your machine tree.

You may add my 
Acked-by: Eduardo Valentin <edubezval at gmail.com>

in your DT patch.

> 


From nicolas.pitre at linaro.org  Thu Feb 18 07:55:59 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Feb 2016 10:55:59 -0500 (EST)
Subject: [PATCH 3/9] ARM: make free_memmap as __init
In-Reply-To: <1455804123-2526139-4-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-4-git-send-email-arnd@arndb.de>
Message-ID: <alpine.LFD.2.20.1602181055320.13632@knanqh.ubzr>

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

> free_memmap is an inline function, but gcc may choose to ignore that
> when CONFIG_OPTIMIZE_INLINING is set. In that case it is put in the
> .text section, causing a kbuild warning:
> 
> WARNING: vmlinux.o(.text.unlikely+0x1a0): Section mismatch in reference from the function free_memmap() to the function .init.text:__memblock_free_early()
> The function free_memmap() references
> the function __init __memblock_free_early().
> This is often because free_memmap lacks a __init
> annotation or the annotation of __memblock_free_early is wrong.
> 
> FATAL: modpost: Section mismatches detected.
> Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them.
> 
> This marks the function both inline and __init, which is a
> correct annotation and avoids the problem.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Acked-by: Nicolas Pitre <nico at linaro.org>

> ---
>  arch/arm/mm/init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 370581aeb871..a4db267c35b2 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -330,7 +330,7 @@ static inline void poison_init_mem(void *s, size_t count)
>  		*p++ = 0xe7fddef0;
>  }
>  
> -static inline void
> +static inline void __init
>  free_memmap(unsigned long start_pfn, unsigned long end_pfn)
>  {
>  	struct page *start_pg, *end_pg;
> -- 
> 2.7.0
> 
> 


From matthias.bgg at gmail.com  Thu Feb 18 07:56:40 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 18 Feb 2016 16:56:40 +0100
Subject: [PATCH 1/1] thermal: small style cleanup in mtk_thermal
In-Reply-To: <1455810625-20509-1-git-send-email-edubezval@gmail.com>
References: <1448883753-19068-1-git-send-email-s.hauer@pengutronix.de>
 <1455810625-20509-1-git-send-email-edubezval@gmail.com>
Message-ID: <56C5E9B8.6030300@gmail.com>



On 18/02/16 16:50, Eduardo Valentin wrote:
> Remove all checkpatch.pl --strict errors, checks, and warnings.
>
> Cc: Zhang Rui <rui.zhang at intel.com>
> Cc: Matthias Brugger <matthias.bgg at gmail.com>
> Cc: linux-pm at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-mediatek at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Eduardo Valentin <edubezval at gmail.com>
> ---

Reviewed-by: Matthias Brugger <matthias.bgg at gmail.com>

> Sascha,
>
> Add your v12 in my forlinus branch. But also, on top of it
> I cleaned the patch further with the following patch.
>
> BR,
>
> Eduardo
>
>   drivers/thermal/mtk_thermal.c | 56 ++++++++++++++++++++++---------------------
>   1 file changed, 29 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> index 589a138..3d93b1c 100644
> --- a/drivers/thermal/mtk_thermal.c
> +++ b/drivers/thermal/mtk_thermal.c
> @@ -78,7 +78,7 @@
>
>   #define TEMP_MONCTL1_PERIOD_UNIT(x)	((x) & 0x3ff)
>
> -#define TEMP_MONCTL2_FILTER_INTERVAL(x)	(((x) & 0x3ff)) << 16
> +#define TEMP_MONCTL2_FILTER_INTERVAL(x)	(((x) & 0x3ff) << 16)
>   #define TEMP_MONCTL2_SENSOR_INTERVAL(x)	((x) & 0x3ff)
>
>   #define TEMP_AHBPOLL_ADC_POLL_INTERVAL(x)	(x)
> @@ -108,15 +108,15 @@
>   #define MT8173_NUM_SENSORS_PER_ZONE	4
>
>   /* Layout of the fuses providing the calibration data */
> -#define MT8173_CALIB_BUF0_VALID		(1 << 0)
> -#define MT8173_CALIB_BUF1_ADC_GE(x)	(((x) >> 22 ) & 0x3ff)
> -#define MT8173_CALIB_BUF0_VTS_TS1(x)	(((x) >> 17 ) & 0x1ff)
> -#define MT8173_CALIB_BUF0_VTS_TS2(x)	(((x) >> 8 ) & 0x1ff)
> -#define MT8173_CALIB_BUF1_VTS_TS3(x)	(((x) >> 0 ) & 0x1ff)
> -#define MT8173_CALIB_BUF2_VTS_TS4(x)	(((x) >> 23 ) & 0x1ff)
> -#define MT8173_CALIB_BUF2_VTS_TSABB(x)	(((x) >> 14 ) & 0x1ff)
> -#define MT8173_CALIB_BUF0_DEGC_CALI(x)	(((x) >> 1 ) & 0x3f)
> -#define MT8173_CALIB_BUF0_O_SLOPE(x)	(((x) >> 26 ) & 0x3f)
> +#define MT8173_CALIB_BUF0_VALID		BIT(0)
> +#define MT8173_CALIB_BUF1_ADC_GE(x)	(((x) >> 22) & 0x3ff)
> +#define MT8173_CALIB_BUF0_VTS_TS1(x)	(((x) >> 17) & 0x1ff)
> +#define MT8173_CALIB_BUF0_VTS_TS2(x)	(((x) >> 8) & 0x1ff)
> +#define MT8173_CALIB_BUF1_VTS_TS3(x)	(((x) >> 0) & 0x1ff)
> +#define MT8173_CALIB_BUF2_VTS_TS4(x)	(((x) >> 23) & 0x1ff)
> +#define MT8173_CALIB_BUF2_VTS_TSABB(x)	(((x) >> 14) & 0x1ff)
> +#define MT8173_CALIB_BUF0_DEGC_CALI(x)	(((x) >> 1) & 0x3f)
> +#define MT8173_CALIB_BUF0_O_SLOPE(x)	(((x) >> 26) & 0x3f)
>
>   #define THERMAL_NAME    "mtk-thermal"
>
> @@ -136,6 +136,7 @@ struct mtk_thermal {
>
>   	struct mtk_thermal_bank banks[MT8173_NUM_ZONES];
>
> +	/* lock: for getting and putting banks */
>   	struct mutex lock;
>
>   	/* Calibration values */
> @@ -271,11 +272,9 @@ static void mtk_thermal_put_bank(struct mtk_thermal_bank *bank)
>   static int mtk_thermal_bank_temperature(struct mtk_thermal_bank *bank)
>   {
>   	struct mtk_thermal *mt = bank->mt;
> -	int temp, i, max;
> +	int i, temp = INT_MIN, max = INT_MIN;
>   	u32 raw;
>
> -	temp = max = INT_MIN;
> -
>   	for (i = 0; i < bank_data[bank->id].num_sensors; i++) {
>   		raw = readl(mt->thermal_base + sensing_points[i].msr);
>
> @@ -322,7 +321,7 @@ static const struct thermal_zone_of_device_ops mtk_thermal_ops = {
>   };
>
>   static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
> -		u32 apmixed_phys_base, u32 auxadc_phys_base)
> +				  u32 apmixed_phys_base, u32 auxadc_phys_base)
>   {
>   	struct mtk_thermal_bank *bank = &mt->banks[num];
>   	const struct mtk_thermal_bank_cfg *cfg = &bank_data[num];
> @@ -346,7 +345,7 @@ static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
>
>   	/* poll is set to 10u */
>   	writel(TEMP_AHBPOLL_ADC_POLL_INTERVAL(768),
> -			mt->thermal_base + TEMP_AHBPOLL);
> +	       mt->thermal_base + TEMP_AHBPOLL);
>
>   	/* temperature sampling control, 1 sample */
>   	writel(0x0, mt->thermal_base + TEMP_MSRCTL0);
> @@ -375,49 +374,50 @@ static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
>
>   	/* AHB address for auxadc mux selection */
>   	writel(auxadc_phys_base + AUXADC_CON1_CLR_V,
> -			mt->thermal_base + TEMP_ADCMUXADDR);
> +	       mt->thermal_base + TEMP_ADCMUXADDR);
>
>   	/* AHB address for pnp sensor mux selection */
>   	writel(apmixed_phys_base + APMIXED_SYS_TS_CON1,
> -			mt->thermal_base + TEMP_PNPMUXADDR);
> +	       mt->thermal_base + TEMP_PNPMUXADDR);
>
>   	/* AHB value for auxadc enable */
>   	writel(BIT(MT8173_TEMP_AUXADC_CHANNEL), mt->thermal_base + TEMP_ADCEN);
>
>   	/* AHB address for auxadc enable (channel 0 immediate mode selected) */
>   	writel(auxadc_phys_base + AUXADC_CON1_SET_V,
> -			mt->thermal_base + TEMP_ADCENADDR);
> +	       mt->thermal_base + TEMP_ADCENADDR);
>
>   	/* AHB address for auxadc valid bit */
>   	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
> -			mt->thermal_base + TEMP_ADCVALIDADDR);
> +	       mt->thermal_base + TEMP_ADCVALIDADDR);
>
>   	/* AHB address for auxadc voltage output */
>   	writel(auxadc_phys_base + AUXADC_DATA(MT8173_TEMP_AUXADC_CHANNEL),
> -			mt->thermal_base + TEMP_ADCVOLTADDR);
> +	       mt->thermal_base + TEMP_ADCVOLTADDR);
>
>   	/* read valid & voltage are at the same register */
>   	writel(0x0, mt->thermal_base + TEMP_RDCTRL);
>
>   	/* indicate where the valid bit is */
>   	writel(TEMP_ADCVALIDMASK_VALID_HIGH | TEMP_ADCVALIDMASK_VALID_POS(12),
> -			mt->thermal_base + TEMP_ADCVALIDMASK);
> +	       mt->thermal_base + TEMP_ADCVALIDMASK);
>
>   	/* no shift */
>   	writel(0x0, mt->thermal_base + TEMP_ADCVOLTAGESHIFT);
>
>   	/* enable auxadc mux write transaction */
>   	writel(TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
> -			mt->thermal_base + TEMP_ADCWRITECTRL);
> +	       mt->thermal_base + TEMP_ADCWRITECTRL);
>
>   	for (i = 0; i < cfg->num_sensors; i++)
>   		writel(sensor_mux_values[cfg->sensors[i]],
> -				mt->thermal_base + sensing_points[i].adcpnp);
> +		       mt->thermal_base + sensing_points[i].adcpnp);
>
>   	writel((1 << cfg->num_sensors) - 1, mt->thermal_base + TEMP_MONCTL0);
>
> -	writel(TEMP_ADCWRITECTRL_ADC_PNP_WRITE | TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
> -			mt->thermal_base + TEMP_ADCWRITECTRL);
> +	writel(TEMP_ADCWRITECTRL_ADC_PNP_WRITE |
> +	       TEMP_ADCWRITECTRL_ADC_MUX_WRITE,
> +	       mt->thermal_base + TEMP_ADCWRITECTRL);
>
>   	mtk_thermal_put_bank(bank);
>   }
> @@ -434,7 +434,8 @@ static u64 of_get_phys_base(struct device_node *np)
>   	return of_translate_address(np, regaddr_p);
>   }
>
> -static int mtk_thermal_get_calibration_data(struct device *dev, struct mtk_thermal *mt)
> +static int mtk_thermal_get_calibration_data(struct device *dev,
> +					    struct mtk_thermal *mt)
>   {
>   	struct nvmem_cell *cell;
>   	u32 *buf;
> @@ -567,7 +568,8 @@ static int mtk_thermal_probe(struct platform_device *pdev)
>   	}
>
>   	for (i = 0; i < MT8173_NUM_ZONES; i++)
> -		mtk_thermal_init_bank(mt, i, apmixed_phys_base, auxadc_phys_base);
> +		mtk_thermal_init_bank(mt, i, apmixed_phys_base,
> +				      auxadc_phys_base);
>
>   	platform_set_drvdata(pdev, mt);
>
>


From thomas.petazzoni at free-electrons.com  Thu Feb 18 07:57:22 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 18 Feb 2016 16:57:22 +0100
Subject: [PATCH v2] dma: mv_xor_v2: new driver
Message-ID: <1455811042-3549-1-git-send-email-thomas.petazzoni@free-electrons.com>

The new mv_xor_v2 driver supports the XOR engines found in the 64-bits
ARM from Marvell of the Armada 7K and Armada 8K family. This XOR
engine is a completely new hardware block, entirely different from the
one used on previous Marvell Armada platforms, which use the existing
mv_xor driver.

The driver is intentionally made available only on ARM64 since the MSI
infrastructure doesn't build on all architectures (e.g OpenRISC). We
plan to work on this in the future, but in the mean time, we enable
the driver only on ARM64.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
Changes v1 -> v2:
 - Add a "depends on ARM64" since the MSI infrastructure doesn't build
   on all architectures for the moment.
 - Remove the useless .owner assignment.
---
 .../devicetree/bindings/dma/mv-xor-v2.txt          |  19 +
 drivers/dma/Kconfig                                |  14 +
 drivers/dma/Makefile                               |   1 +
 drivers/dma/mv_xor_v2.c                            | 879 +++++++++++++++++++++
 4 files changed, 913 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/mv-xor-v2.txt
 create mode 100644 drivers/dma/mv_xor_v2.c

diff --git a/Documentation/devicetree/bindings/dma/mv-xor-v2.txt b/Documentation/devicetree/bindings/dma/mv-xor-v2.txt
new file mode 100644
index 0000000..0a03dcf
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mv-xor-v2.txt
@@ -0,0 +1,19 @@
+* Marvell XOR v2 engines
+
+Required properties:
+- compatible: Should be "marvell,mv-xor-v2"
+- reg: Should contain registers location and length (two sets)
+    the first set is the DMA registers
+    the second set is the global registers
+- msi-parent: Phandle to the MSI-capable interrupt controller used for
+  interrupts.
+
+Example:
+
+	xor0 at 400000 {
+		compatible = "marvell,mv-xor-v2";
+		reg = <0x400000 0x1000>,
+		      <0x410000 0x1000>;
+		msi-parent = <&gic_v2m0>;
+		dma-coherent;
+	};
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 79b1390..f182fef 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -339,6 +339,20 @@ config MV_XOR
 	---help---
 	  Enable support for the Marvell XOR engine.
 
+config MV_XOR_V2
+	bool "Marvell XOR engine version 2 support "
+	depends on ARM64
+	select DMA_ENGINE
+	select DMA_ENGINE_RAID
+	select ASYNC_TX_ENABLE_CHANNEL_SWITCH
+	select GENERIC_MSI_IRQ_DOMAIN
+	---help---
+	  Enable support for the Marvell version 2 XOR engine.
+
+	  This engine provides acceleration for copy, XOR and RAID6
+	  operations, and is available on Marvell Armada 7K and 8K
+	  platforms.
+
 config MXS_DMA
 	bool "MXS DMA support"
 	depends on SOC_IMX23 || SOC_IMX28 || SOC_IMX6Q
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 2dd0a067..da8ca73 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_MMP_TDMA) += mmp_tdma.o
 obj-$(CONFIG_MOXART_DMA) += moxart-dma.o
 obj-$(CONFIG_MPC512X_DMA) += mpc512x_dma.o
 obj-$(CONFIG_MV_XOR) += mv_xor.o
+obj-$(CONFIG_MV_XOR_V2) += mv_xor_v2.o
 obj-$(CONFIG_MXS_DMA) += mxs-dma.o
 obj-$(CONFIG_MX3_IPU) += ipu/
 obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
diff --git a/drivers/dma/mv_xor_v2.c b/drivers/dma/mv_xor_v2.c
new file mode 100644
index 0000000..663d808
--- /dev/null
+++ b/drivers/dma/mv_xor_v2.c
@@ -0,0 +1,879 @@
+/*
+ * Copyright (C) 2015-2016 Marvell International Ltd.
+
+ * This program is free software: you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, either version 2 of the
+ * License, or any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#include <linux/dma-mapping.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/msi.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+
+#include "dmaengine.h"
+
+/* DMA Engine Registers */
+#define DMA_DESQ_BALR_OFF	0x000
+#define DMA_DESQ_BAHR_OFF	0x004
+#define DMA_DESQ_SIZE_OFF	0x008
+#define DMA_DESQ_DONE_OFF	0x00C
+#define   DMA_DESQ_DONE_PENDING_MASK		0x7FFF
+#define   DMA_DESQ_DONE_PENDING_SHIFT		0
+#define   DMA_DESQ_DONE_READ_PTR_MASK		0x1FFF
+#define   DMA_DESQ_DONE_READ_PTR_SHIFT		16
+#define DMA_DESQ_ARATTR_OFF	0x010
+#define   DMA_DESQ_ATTR_CACHE_MASK		0x3F3F
+#define   DMA_DESQ_ATTR_OUTER_SHAREABLE		0x202
+#define   DMA_DESQ_ATTR_CACHEABLE		0x3C3C
+#define DMA_IMSG_CDAT_OFF	0x014
+#define DMA_IMSG_THRD_OFF	0x018
+#define   DMA_IMSG_THRD_MASK			0x7FFF
+#define   DMA_IMSG_THRD_SHIFT			0x0
+#define DMA_DESQ_AWATTR_OFF	0x01C
+  /* Same flags as DMA_DESQ_ARATTR_OFF */
+#define DMA_DESQ_ALLOC_OFF	0x04C
+#define   DMA_DESQ_ALLOC_WRPTR_MASK		0xFFFF
+#define   DMA_DESQ_ALLOC_WRPTR_SHIFT		16
+#define DMA_IMSG_BALR_OFF	0x050
+#define DMA_IMSG_BAHR_OFF	0x054
+#define DMA_DESQ_CTRL_OFF	0x100
+#define	  DMA_DESQ_CTRL_32B			1
+#define   DMA_DESQ_CTRL_128B			7
+#define DMA_DESQ_STOP_OFF	0x800
+#define DMA_DESQ_DEALLOC_OFF	0x804
+#define DMA_DESQ_ADD_OFF	0x808
+
+/* XOR Global registers */
+#define GLOB_BW_CTRL		0x4
+#define   GLOB_BW_CTRL_NUM_OSTD_RD_SHIFT	0
+#define   GLOB_BW_CTRL_NUM_OSTD_RD_VAL		64
+#define   GLOB_BW_CTRL_NUM_OSTD_WR_SHIFT	8
+#define   GLOB_BW_CTRL_NUM_OSTD_WR_VAL		8
+#define   GLOB_BW_CTRL_RD_BURST_LEN_SHIFT	12
+#define   GLOB_BW_CTRL_RD_BURST_LEN_VAL		4
+#define   GLOB_BW_CTRL_WR_BURST_LEN_SHIFT	16
+#define	  GLOB_BW_CTRL_WR_BURST_LEN_VAL		4
+#define GLOB_PAUSE		0x014
+#define   GLOB_PAUSE_AXI_TIME_DIS_VAL		0x8
+#define GLOB_SYS_INT_CAUSE	0x200
+#define GLOB_SYS_INT_MASK	0x204
+#define GLOB_MEM_INT_CAUSE	0x220
+#define GLOB_MEM_INT_MASK	0x224
+
+#define MV_XOR_V2_MIN_DESC_SIZE		32
+#define MV_XOR_V2_EXT_DESC_SIZE		128
+
+#define MV_XOR_V2_DESC_RESERVED_SIZE	12
+#define MV_XOR_V2_DESC_BUFF_D_ADDR_SIZE	12
+
+#define MV_XOR_V2_CMD_LINE_NUM_MAX_D_BUF 8
+
+/* descriptors queue size */
+#define MV_XOR_V2_MAX_DESC_NUM	1024
+
+/**
+ * struct mv_xor_v2_descriptor - DMA HW descriptor
+ * @desc_id: used by S/W and is not affected by H/W.
+ * @flags: error and status flags
+ * @crc32_result: CRC32 calculation result
+ * @desc_ctrl: operation mode and control flags
+ * @buff_size: amount of bytes to be processed
+ * @fill_pattern_src_addr: Fill-Pattern or Source-Address and
+ * AW-Attributes
+ * @data_buff_addr: Source (and might be RAID6 destination)
+ * addresses of data buffers in RAID5 and RAID6
+ * @reserved: reserved
+ */
+struct mv_xor_v2_descriptor {
+	u16 desc_id;
+	u16 flags;
+	u32 crc32_result;
+	u32 desc_ctrl;
+
+	/* Definitions for desc_ctrl */
+#define DESC_NUM_ACTIVE_D_BUF_SHIFT	22
+#define DESC_OP_MODE_SHIFT		28
+#define DESC_OP_MODE_NOP		0	/* Idle operation */
+#define DESC_OP_MODE_MEMCPY		1	/* Pure-DMA operation */
+#define DESC_OP_MODE_MEMSET		2	/* Mem-Fill operation */
+#define DESC_OP_MODE_MEMINIT		3	/* Mem-Init operation */
+#define DESC_OP_MODE_MEM_COMPARE	4	/* Mem-Compare operation */
+#define DESC_OP_MODE_CRC32		5	/* CRC32 calculation */
+#define DESC_OP_MODE_XOR		6	/* RAID5 (XOR) operation */
+#define DESC_OP_MODE_RAID6		7	/* RAID6 P&Q-generation */
+#define DESC_OP_MODE_RAID6_REC		8	/* RAID6 Recovery */
+#define DESC_Q_BUFFER_ENABLE		BIT(16)
+#define DESC_P_BUFFER_ENABLE		BIT(17)
+#define DESC_IOD			BIT(27)
+
+	u32 buff_size;
+	u32 fill_pattern_src_addr[4];
+	u32 data_buff_addr[MV_XOR_V2_DESC_BUFF_D_ADDR_SIZE];
+	u32 reserved[MV_XOR_V2_DESC_RESERVED_SIZE];
+};
+
+/**
+ * struct mv_xor_v2_device - implements a xor device
+ * @sw_ll_lock: serializes enqueue/dequeue operations to the sw
+ * descriptors pool
+ * @push_lock: serializes enqueue operations to the DESCQ
+ * @cookie_lock: serializes of cookies control
+ * @dma_base: memory mapped DMA register base
+ * @glob_base: memory mapped global register base
+ * @irq_tasklet:
+ * @free_sw_desc: linked list of free SW descriptors
+ * @dmadev: dma device
+ * @dmachan: dma channel
+ * @hw_desq: HW descriptors queue
+ * @hw_desq_virt: virtual address of DESCQ
+ * @sw_desq: SW descriptors queue
+ * @desc_size: HW descriptor size
+*/
+struct mv_xor_v2_device {
+	spinlock_t sw_ll_lock;
+	spinlock_t push_lock;
+	spinlock_t cookie_lock;
+	void __iomem *dma_base;
+	void __iomem *glob_base;
+	struct tasklet_struct irq_tasklet;
+	struct list_head free_sw_desc;
+	struct dma_device dmadev;
+	struct dma_chan	dmachan;
+	dma_addr_t hw_desq;
+	struct mv_xor_v2_descriptor *hw_desq_virt;
+	struct mv_xor_v2_sw_desc *sw_desq;
+	int desc_size;
+};
+
+/**
+ * struct mv_xor_v2_sw_desc - implements a xor SW descriptor
+ * @idx: descriptor index
+ * @async_tx: support for the async_tx api
+ * @hw_desc: assosiated HW descriptor
+ * @free_list: node of the free SW descriprots list
+*/
+struct mv_xor_v2_sw_desc {
+	int idx;
+	struct dma_async_tx_descriptor async_tx;
+	struct mv_xor_v2_descriptor hw_desc;
+	struct list_head free_list;
+};
+
+/*
+ * Fill the data buffers to a HW descriptor
+ */
+static void mv_xor_v2_set_data_buffers(struct mv_xor_v2_device *xor_dev,
+					struct mv_xor_v2_descriptor *desc,
+					dma_addr_t src, int index)
+{
+	int arr_index = ((index >> 1) * 3);
+
+	/*
+	 * fill the buffer's addresses to the descriptor
+	 * The format of the buffers address for 2 sequential buffers X and X+1:
+	 *  First word: Buffer-DX-Address-Low[31:0]
+	 *  Second word:Buffer-DX+1-Address-Low[31:0]
+	 *  Third word: DX+1-Buffer-Address-High[47:32] [31:16]
+	 *		DX-Buffer-Address-High[47:32] [15:0]
+	 */
+	if ((index & 0x1) == 0) {
+		desc->data_buff_addr[arr_index] = lower_32_bits(src);
+
+		/* Clear lower 16-bits */
+		desc->data_buff_addr[arr_index + 2] &= ~0xFFFF;
+
+		/* Set them if we have a 64 bits DMA address */
+		if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT))
+			desc->data_buff_addr[arr_index + 2] |=
+				upper_32_bits(src) & 0xFFFF;
+	} else {
+		desc->data_buff_addr[arr_index + 1] =
+			lower_32_bits(src);
+
+		/* Clear upper 16-bits */
+		desc->data_buff_addr[arr_index + 2] &= ~0xFFFF0000;
+
+		/* Set them if we have a 64 bits DMA address */
+		if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT))
+			desc->data_buff_addr[arr_index + 2] |=
+				(upper_32_bits(src) & 0xFFFF) << 16;
+	}
+}
+
+/*
+ * Return the next available index in the DESQ.
+ */
+static inline int mv_xor_v2_get_desq_write_ptr(struct mv_xor_v2_device *xor_dev)
+{
+	/* read the index for the next available descriptor in the DESQ */
+	u32 reg = readl(xor_dev->dma_base + DMA_DESQ_ALLOC_OFF);
+
+	return ((reg >> DMA_DESQ_ALLOC_WRPTR_SHIFT)
+		& DMA_DESQ_ALLOC_WRPTR_MASK);
+}
+
+/*
+ * notify the engine of new descriptors, and update the available index.
+ */
+static void mv_xor_v2_add_desc_to_desq(struct mv_xor_v2_device *xor_dev,
+				       int num_of_desc)
+{
+	/* write the number of new descriptors in the DESQ. */
+	writel(num_of_desc, xor_dev->dma_base + DMA_DESQ_ADD_OFF);
+}
+
+/*
+ * free HW descriptors
+ */
+static void mv_xor_v2_free_desc_from_desq(struct mv_xor_v2_device *xor_dev,
+					  int num_of_desc)
+{
+	/* write the number of new descriptors in the DESQ. */
+	writel(num_of_desc, xor_dev->dma_base + DMA_DESQ_DEALLOC_OFF);
+}
+
+/*
+ * Set descriptor size
+ * Return the HW descriptor size in bytes
+ */
+static int mv_xor_v2_set_desc_size(struct mv_xor_v2_device *xor_dev)
+{
+	writel(DMA_DESQ_CTRL_128B,
+	       xor_dev->dma_base + DMA_DESQ_CTRL_OFF);
+
+	return MV_XOR_V2_EXT_DESC_SIZE;
+}
+
+/*
+ * Allocate resources for a channel
+ */
+static int mv_xor_v2_alloc_chan_resources(struct dma_chan *chan)
+{
+	/* nothing to be done here */
+	return 0;
+}
+
+/*
+ * Free resources of a channel
+ */
+void mv_xor_v2_free_chan_resources(struct dma_chan *chan)
+{
+	/* nothing to be done here */
+}
+
+/*
+ * Set the IMSG threshold
+ */
+static inline
+void mv_xor_v2_set_imsg_thrd(struct mv_xor_v2_device *xor_dev, int thrd_val)
+{
+	u32 reg;
+
+	reg = readl(xor_dev->dma_base + DMA_IMSG_THRD_OFF);
+
+	reg &= (~DMA_IMSG_THRD_MASK << DMA_IMSG_THRD_SHIFT);
+	reg |= (thrd_val << DMA_IMSG_THRD_SHIFT);
+
+	writel(reg, xor_dev->dma_base + DMA_IMSG_THRD_OFF);
+}
+
+static irqreturn_t mv_xor_v2_interrupt_handler(int irq, void *data)
+{
+	struct mv_xor_v2_device *xor_dev = data;
+
+	/*
+	 * Update IMSG threshold, to disable new IMSG interrupts until
+	 * end of the tasklet
+	 */
+	mv_xor_v2_set_imsg_thrd(xor_dev, MV_XOR_V2_MAX_DESC_NUM);
+
+	/* schedule a tasklet to handle descriptors callbacks */
+	tasklet_schedule(&xor_dev->irq_tasklet);
+
+	return IRQ_HANDLED;
+}
+
+/*
+ * submit a descriptor to the DMA engine
+ */
+static dma_cookie_t
+mv_xor_v2_tx_submit(struct dma_async_tx_descriptor *tx)
+{
+	int desq_ptr;
+	void *dest_hw_desc;
+	dma_cookie_t cookie;
+	struct mv_xor_v2_sw_desc *sw_desc =
+		container_of(tx, struct mv_xor_v2_sw_desc, async_tx);
+	struct mv_xor_v2_device *xor_dev =
+		container_of(tx->chan, struct mv_xor_v2_device, dmachan);
+
+	dev_dbg(xor_dev->dmadev.dev,
+		"%s sw_desc %p: async_tx %p\n",
+		__func__, sw_desc, &sw_desc->async_tx);
+
+	/* assign coookie */
+	spin_lock_bh(&xor_dev->cookie_lock);
+	cookie = dma_cookie_assign(tx);
+	spin_unlock_bh(&xor_dev->cookie_lock);
+
+	/* lock enqueue DESCQ */
+	spin_lock_bh(&xor_dev->push_lock);
+
+	/* get the next available slot in the DESQ */
+	desq_ptr = mv_xor_v2_get_desq_write_ptr(xor_dev);
+
+	/* copy the HW descriptor from the SW descriptor to the DESQ */
+	dest_hw_desc = ((void *)xor_dev->hw_desq_virt +
+			(xor_dev->desc_size * desq_ptr));
+
+	memcpy(dest_hw_desc, &sw_desc->hw_desc, xor_dev->desc_size);
+
+	/* update the DMA Engine with the new descriptor */
+	mv_xor_v2_add_desc_to_desq(xor_dev, 1);
+
+	/* unlock enqueue DESCQ */
+	spin_unlock_bh(&xor_dev->push_lock);
+
+	return cookie;
+}
+
+/*
+ * Prepare a SW descriptor
+ */
+static struct mv_xor_v2_sw_desc	*
+mv_xor_v2_prep_sw_desc(struct mv_xor_v2_device *xor_dev)
+{
+	struct mv_xor_v2_sw_desc *sw_desc;
+
+	/* Lock the channel */
+	spin_lock_bh(&xor_dev->sw_ll_lock);
+
+	/* get a free SW descriptor from the SW DESQ */
+	sw_desc = list_first_entry(&xor_dev->free_sw_desc,
+				   struct mv_xor_v2_sw_desc, free_list);
+	list_del(&sw_desc->free_list);
+
+	/* Release the channel */
+	spin_unlock_bh(&xor_dev->sw_ll_lock);
+
+	/* set the async tx descriptor */
+	dma_async_tx_descriptor_init(&sw_desc->async_tx, &xor_dev->dmachan);
+	sw_desc->async_tx.tx_submit = mv_xor_v2_tx_submit;
+	async_tx_ack(&sw_desc->async_tx);
+
+	return sw_desc;
+}
+
+/*
+ * Prepare a HW descriptor for a memcpy operation
+ */
+static struct dma_async_tx_descriptor *
+mv_xor_v2_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest,
+			  dma_addr_t src, size_t len, unsigned long flags)
+{
+	struct mv_xor_v2_sw_desc	*sw_desc;
+	struct mv_xor_v2_descriptor	*hw_descriptor;
+	struct mv_xor_v2_device		*xor_dev;
+
+	xor_dev = container_of(chan, struct mv_xor_v2_device, dmachan);
+
+	dev_dbg(xor_dev->dmadev.dev,
+		"%s len: %zu src %pad dest %pad flags: %ld\n",
+		__func__, len, &src, &dest, flags);
+
+	sw_desc = mv_xor_v2_prep_sw_desc(xor_dev);
+
+	sw_desc->async_tx.flags = flags;
+
+	/* set the HW descriptor */
+	hw_descriptor = &sw_desc->hw_desc;
+
+	/* save the SW descriptor ID to restore when operation is done */
+	hw_descriptor->desc_id = sw_desc->idx;
+
+	/* Set the MEMCPY control word */
+	hw_descriptor->desc_ctrl =
+		DESC_OP_MODE_MEMCPY << DESC_OP_MODE_SHIFT;
+
+	if (flags & DMA_PREP_INTERRUPT)
+		hw_descriptor->desc_ctrl |= DESC_IOD;
+
+	/* Set source address */
+	hw_descriptor->fill_pattern_src_addr[0] = lower_32_bits(src);
+
+	if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT))
+		hw_descriptor->fill_pattern_src_addr[1] =
+			upper_32_bits(src) & 0xFFFF;
+	else
+		hw_descriptor->fill_pattern_src_addr[1] = 0;
+
+	/* Set Destination address */
+	hw_descriptor->fill_pattern_src_addr[2] = lower_32_bits(dest);
+
+	if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT))
+		hw_descriptor->fill_pattern_src_addr[3] =
+			upper_32_bits(dest) & 0xFFFF;
+	else
+		hw_descriptor->fill_pattern_src_addr[3] = 0;
+
+	/* Set buffers size */
+	hw_descriptor->buff_size = len;
+
+	/* return the async tx descriptor */
+	return &sw_desc->async_tx;
+}
+
+/*
+ * Prepare a HW descriptor for a XOR operation
+ */
+static struct dma_async_tx_descriptor *
+mv_xor_v2_prep_dma_xor(struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
+		       unsigned int src_cnt, size_t len, unsigned long flags)
+{
+	struct mv_xor_v2_sw_desc	*sw_desc;
+	struct mv_xor_v2_descriptor	*hw_descriptor;
+	struct mv_xor_v2_device		*xor_dev;
+	int i;
+
+	BUG_ON(src_cnt > MV_XOR_V2_CMD_LINE_NUM_MAX_D_BUF || src_cnt < 1);
+
+	xor_dev = container_of(chan, struct mv_xor_v2_device, dmachan);
+
+	dev_dbg(xor_dev->dmadev.dev,
+		"%s src_cnt: %d len: %zu dest %pad flags: %ld\n",
+		__func__, src_cnt, len, &dest, flags);
+
+	BUG_ON(xor_dev->desc_size != MV_XOR_V2_EXT_DESC_SIZE);
+
+	sw_desc = mv_xor_v2_prep_sw_desc(xor_dev);
+
+	sw_desc->async_tx.flags = flags;
+
+	/* set the HW descriptor */
+	hw_descriptor = &sw_desc->hw_desc;
+
+	/* save the SW descriptor ID to restore when operation is done */
+	hw_descriptor->desc_id = sw_desc->idx;
+
+	/* Set the XOR control word */
+	hw_descriptor->desc_ctrl =
+		DESC_OP_MODE_XOR << DESC_OP_MODE_SHIFT;
+	hw_descriptor->desc_ctrl |= DESC_P_BUFFER_ENABLE;
+
+	if (flags & DMA_PREP_INTERRUPT)
+		hw_descriptor->desc_ctrl |= DESC_IOD;
+
+	/* Set the data buffers */
+	for (i = 0; i < src_cnt; i++)
+		mv_xor_v2_set_data_buffers(xor_dev, hw_descriptor, src[i], i);
+
+	hw_descriptor->desc_ctrl |=
+		src_cnt << DESC_NUM_ACTIVE_D_BUF_SHIFT;
+
+	/* Set Destination address */
+	hw_descriptor->fill_pattern_src_addr[2] = lower_32_bits(dest);
+	if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT))
+		hw_descriptor->fill_pattern_src_addr[3] =
+			upper_32_bits(dest) & 0xFFFF;
+	else
+		hw_descriptor->fill_pattern_src_addr[3] = 0;
+
+	/* Set buffers size */
+	hw_descriptor->buff_size = len;
+
+	/* return the async tx descriptor */
+	return &sw_desc->async_tx;
+}
+
+/*
+ * Prepare a HW descriptor for interrupt operation.
+ */
+static struct dma_async_tx_descriptor *
+mv_xor_v2_prep_dma_interrupt(struct dma_chan *chan, unsigned long flags)
+{
+	struct mv_xor_v2_sw_desc	*sw_desc;
+	struct mv_xor_v2_descriptor	*hw_descriptor;
+	struct mv_xor_v2_device		*xor_dev;
+
+	xor_dev = container_of(chan, struct mv_xor_v2_device, dmachan);
+
+	sw_desc = mv_xor_v2_prep_sw_desc(xor_dev);
+
+	/* set the HW descriptor */
+	hw_descriptor = &sw_desc->hw_desc;
+
+	/* save the SW descriptor ID to restore when operation is done */
+	hw_descriptor->desc_id = sw_desc->idx;
+
+	/* Set the INTERRUPT control word */
+	hw_descriptor->desc_ctrl =
+		DESC_OP_MODE_NOP << DESC_OP_MODE_SHIFT;
+	hw_descriptor->desc_ctrl |= DESC_IOD;
+
+	/* return the async tx descriptor */
+	return &sw_desc->async_tx;
+}
+
+/*
+ * poll for a transaction completion
+ */
+static enum dma_status mv_xor_v2_tx_status(struct dma_chan *chan,
+		dma_cookie_t cookie, struct dma_tx_state *txstate)
+{
+	/* return the transaction status */
+	return dma_cookie_status(chan, cookie, txstate);
+}
+
+/*
+ * push pending transactions to hardware
+ */
+static void mv_xor_v2_issue_pending(struct dma_chan *chan)
+{
+	struct mv_xor_v2_device *xor_dev =
+		container_of(chan, struct mv_xor_v2_device, dmachan);
+
+	/* Activate the channel */
+	writel(0, xor_dev->dma_base + DMA_DESQ_STOP_OFF);
+}
+
+static inline
+int mv_xor_v2_get_pending_params(struct mv_xor_v2_device *xor_dev,
+				 int *pending_ptr)
+{
+	u32 reg;
+
+	reg = readl(xor_dev->dma_base + DMA_DESQ_DONE_OFF);
+
+	/* get the next pending descriptor index */
+	*pending_ptr = ((reg >> DMA_DESQ_DONE_READ_PTR_SHIFT) &
+			DMA_DESQ_DONE_READ_PTR_MASK);
+
+	/* get the number of descriptors pending handle */
+	return ((reg >> DMA_DESQ_DONE_PENDING_SHIFT) &
+		DMA_DESQ_DONE_PENDING_MASK);
+}
+
+/*
+ * handle the descriptors after HW process
+ */
+static void mv_xor_v2_tasklet(unsigned long data)
+{
+	struct mv_xor_v2_device *xor_dev = (struct mv_xor_v2_device *) data;
+	int pending_ptr, num_of_pending, i;
+	struct mv_xor_v2_descriptor *next_pending_hw_desc = NULL;
+	struct mv_xor_v2_sw_desc *next_pending_sw_desc = NULL;
+
+	dev_dbg(xor_dev->dmadev.dev, "%s %d\n", __func__, __LINE__);
+
+	/* get thepending descriptors parameters */
+	num_of_pending = mv_xor_v2_get_pending_params(xor_dev, &pending_ptr);
+
+	/* next HW descriptor */
+	next_pending_hw_desc = (struct mv_xor_v2_descriptor *)
+		((void *)xor_dev->hw_desq_virt +
+		 (xor_dev->desc_size * (pending_ptr)));
+
+	/* loop over free descriptors */
+	for (i = 0; i < num_of_pending; i++) {
+
+		if (pending_ptr > MV_XOR_V2_MAX_DESC_NUM)
+			pending_ptr = 0;
+
+		if (next_pending_sw_desc != NULL)
+			next_pending_hw_desc++;
+
+		/* get the SW descriptor related to the HW descriptor */
+		next_pending_sw_desc =
+			&xor_dev->sw_desq[next_pending_hw_desc->desc_id];
+
+		/* call the callback */
+		if (next_pending_sw_desc->async_tx.cookie > 0) {
+			/*
+			 * update the channel's completed cookie - no
+			 * lock is required the IMSG threshold provide
+			 * the locking
+			 */
+			dma_cookie_complete(&next_pending_sw_desc->async_tx);
+
+			if (next_pending_sw_desc->async_tx.callback)
+				next_pending_sw_desc->async_tx.callback(
+				next_pending_sw_desc->async_tx.callback_param);
+
+			dma_descriptor_unmap(&next_pending_sw_desc->async_tx);
+		}
+
+		dma_run_dependencies(&next_pending_sw_desc->async_tx);
+
+		/* Lock the channel */
+		spin_lock_bh(&xor_dev->sw_ll_lock);
+
+		/* add the SW descriptor to the free descriptors list */
+		list_add(&next_pending_sw_desc->free_list,
+			 &xor_dev->free_sw_desc);
+
+		/* Release the channel */
+		spin_unlock_bh(&xor_dev->sw_ll_lock);
+
+		/* increment the next descriptor */
+		pending_ptr++;
+	}
+
+	if (num_of_pending != 0) {
+		/* free the descriptores */
+		mv_xor_v2_free_desc_from_desq(xor_dev, num_of_pending);
+	}
+
+	/* Update IMSG threshold, to enable new IMSG interrupts */
+	mv_xor_v2_set_imsg_thrd(xor_dev, 0);
+}
+
+/*
+ *	Set DMA Interrupt-message (IMSG) parameters
+ */
+static void mv_xor_v2_set_msi_msg(struct msi_desc *desc, struct msi_msg *msg)
+{
+	struct mv_xor_v2_device *xor_dev = dev_get_drvdata(desc->dev);
+
+	writel(msg->address_lo, xor_dev->dma_base + DMA_IMSG_BALR_OFF);
+	writel(msg->address_hi & 0xFFFF, xor_dev->dma_base + DMA_IMSG_BAHR_OFF);
+	writel(msg->data, xor_dev->dma_base + DMA_IMSG_CDAT_OFF);
+}
+
+static int mv_xor_v2_descq_init(struct mv_xor_v2_device *xor_dev)
+{
+	u32 reg;
+
+	/* write the DESQ size to the DMA engine */
+	writel(MV_XOR_V2_MAX_DESC_NUM, xor_dev->dma_base + DMA_DESQ_SIZE_OFF);
+
+	/* write the DESQ address to the DMA enngine*/
+	writel(xor_dev->hw_desq & 0xFFFFFFFF,
+	       xor_dev->dma_base + DMA_DESQ_BALR_OFF);
+	writel((xor_dev->hw_desq & 0xFFFF00000000) >> 32,
+	       xor_dev->dma_base + DMA_DESQ_BAHR_OFF);
+
+	/* enable the DMA engine */
+	writel(0, xor_dev->dma_base + DMA_DESQ_STOP_OFF);
+
+	/*
+	 * This is a temporary solution, until we activate the
+	 * SMMU. Set the attributes for reading & writing data buffers
+	 * & descriptors to:
+	 *
+	 *  - OuterShareable - Snoops will be performed on CPU caches
+	 *  - Enable cacheable - Bufferable, Modifiable, Other Allocate
+	 *    and Allocate
+	 */
+	reg = readl(xor_dev->dma_base + DMA_DESQ_ARATTR_OFF);
+	reg &= ~DMA_DESQ_ATTR_CACHE_MASK;
+	reg |= DMA_DESQ_ATTR_OUTER_SHAREABLE | DMA_DESQ_ATTR_CACHEABLE;
+	writel(reg, xor_dev->dma_base + DMA_DESQ_ARATTR_OFF);
+
+	reg = readl(xor_dev->dma_base + DMA_DESQ_AWATTR_OFF);
+	reg &= ~DMA_DESQ_ATTR_CACHE_MASK;
+	reg |= DMA_DESQ_ATTR_OUTER_SHAREABLE | DMA_DESQ_ATTR_CACHEABLE;
+	writel(reg, xor_dev->dma_base + DMA_DESQ_AWATTR_OFF);
+
+	/* BW CTRL - set values to optimize the XOR performance:
+	 *
+	 *  - Set WrBurstLen & RdBurstLen - the unit will issue
+	 *    maximum of 256B write/read transactions.
+	 * -  Limit the number of outstanding write & read data
+	 *    (OBB/IBB) requests to the maximal value.
+	*/
+	reg  = GLOB_BW_CTRL_NUM_OSTD_RD_VAL  << GLOB_BW_CTRL_NUM_OSTD_RD_SHIFT;
+	reg |= GLOB_BW_CTRL_NUM_OSTD_WR_VAL  << GLOB_BW_CTRL_NUM_OSTD_WR_SHIFT;
+	reg |= GLOB_BW_CTRL_RD_BURST_LEN_VAL << GLOB_BW_CTRL_RD_BURST_LEN_SHIFT;
+	reg |= GLOB_BW_CTRL_WR_BURST_LEN_VAL << GLOB_BW_CTRL_WR_BURST_LEN_SHIFT;
+	writel(reg, xor_dev->glob_base + GLOB_BW_CTRL);
+
+	/* Disable the AXI timer feature */
+	reg = readl(xor_dev->glob_base + GLOB_PAUSE);
+	reg |= GLOB_PAUSE_AXI_TIME_DIS_VAL;
+	writel(reg, xor_dev->glob_base + GLOB_PAUSE);
+
+	return 0;
+}
+
+static int mv_xor_v2_probe(struct platform_device *pdev)
+{
+	struct mv_xor_v2_device *xor_dev;
+	struct resource *res;
+	int i, ret = 0;
+	struct dma_device *dma_dev;
+	struct mv_xor_v2_sw_desc *sw_desc;
+	struct msi_desc *msi_desc;
+
+	dev_notice(&pdev->dev, "Marvell Version 2 XOR driver\n");
+
+	xor_dev = devm_kzalloc(&pdev->dev, sizeof(*xor_dev), GFP_KERNEL);
+	if (!xor_dev)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	xor_dev->dma_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(xor_dev->dma_base))
+		return PTR_ERR(xor_dev->dma_base);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	xor_dev->glob_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(xor_dev->glob_base))
+		return PTR_ERR(xor_dev->glob_base);
+
+	platform_set_drvdata(pdev, xor_dev);
+
+	ret = platform_msi_domain_alloc_irqs(&pdev->dev, 1,
+					     mv_xor_v2_set_msi_msg);
+	if (ret)
+		return ret;
+
+	msi_desc = first_msi_entry(&pdev->dev);
+	if (!msi_desc)
+		goto free_msi_irqs;
+
+	ret = devm_request_irq(&pdev->dev, msi_desc->irq,
+			       mv_xor_v2_interrupt_handler, 0,
+			       dev_name(&pdev->dev), xor_dev);
+	if (ret)
+		goto free_msi_irqs;
+
+	tasklet_init(&xor_dev->irq_tasklet, mv_xor_v2_tasklet,
+		     (unsigned long) xor_dev);
+
+	xor_dev->desc_size = mv_xor_v2_set_desc_size(xor_dev);
+
+	dma_cookie_init(&xor_dev->dmachan);
+
+	/*
+	 * allocate coherent memory for hardware descriptors
+	 * note: writecombine gives slightly better performance, but
+	 * requires that we explicitly flush the writes
+	 */
+	xor_dev->hw_desq_virt =
+		dma_alloc_coherent(&pdev->dev,
+				   xor_dev->desc_size * MV_XOR_V2_MAX_DESC_NUM,
+				   &xor_dev->hw_desq, GFP_KERNEL);
+	if (!xor_dev->hw_desq_virt) {
+		ret = -ENOMEM;
+		goto free_msi_irqs;
+	}
+
+	/* alloc memory for the SW descriptors */
+	xor_dev->sw_desq = devm_kzalloc(&pdev->dev, sizeof(*sw_desc) *
+					MV_XOR_V2_MAX_DESC_NUM, GFP_KERNEL);
+	if (!xor_dev->sw_desq) {
+		ret = -ENOMEM;
+		goto free_hw_desq;
+	}
+
+	/* init the channel locks */
+	spin_lock_init(&xor_dev->sw_ll_lock);
+	spin_lock_init(&xor_dev->push_lock);
+	spin_lock_init(&xor_dev->cookie_lock);
+
+	/* init the free SW descriptors list */
+	INIT_LIST_HEAD(&xor_dev->free_sw_desc);
+
+	/* add all SW descriptors to the free list */
+	for (i = 0; i < MV_XOR_V2_MAX_DESC_NUM; i++) {
+		xor_dev->sw_desq[i].idx = i;
+		list_add(&xor_dev->sw_desq[i].free_list,
+			 &xor_dev->free_sw_desc);
+	}
+
+	dma_dev = &xor_dev->dmadev;
+
+	/* set DMA capabilities */
+	dma_cap_zero(dma_dev->cap_mask);
+	dma_cap_set(DMA_MEMCPY, dma_dev->cap_mask);
+	dma_cap_set(DMA_XOR, dma_dev->cap_mask);
+	dma_cap_set(DMA_INTERRUPT, dma_dev->cap_mask);
+
+	/* init dma link list */
+	INIT_LIST_HEAD(&dma_dev->channels);
+
+	/* set base routines */
+	dma_dev->device_alloc_chan_resources =
+		mv_xor_v2_alloc_chan_resources;
+	dma_dev->device_free_chan_resources =
+		mv_xor_v2_free_chan_resources;
+	dma_dev->device_tx_status = mv_xor_v2_tx_status;
+	dma_dev->device_issue_pending = mv_xor_v2_issue_pending;
+	dma_dev->dev = &pdev->dev;
+
+	dma_dev->device_prep_dma_memcpy = mv_xor_v2_prep_dma_memcpy;
+	dma_dev->device_prep_dma_interrupt = mv_xor_v2_prep_dma_interrupt;
+	dma_dev->max_xor = 8;
+	dma_dev->device_prep_dma_xor = mv_xor_v2_prep_dma_xor;
+
+	xor_dev->dmachan.device = dma_dev;
+
+	list_add_tail(&xor_dev->dmachan.device_node,
+		      &dma_dev->channels);
+
+	mv_xor_v2_descq_init(xor_dev);
+
+	ret = dma_async_device_register(dma_dev);
+	if (ret)
+		goto free_hw_desq;
+
+	return 0;
+
+free_hw_desq:
+	dma_free_coherent(&pdev->dev,
+			  xor_dev->desc_size * MV_XOR_V2_MAX_DESC_NUM,
+			  xor_dev->hw_desq_virt, xor_dev->hw_desq);
+free_msi_irqs:
+	platform_msi_domain_free_irqs(&pdev->dev);
+	return ret;
+}
+
+static int mv_xor_v2_remove(struct platform_device *pdev)
+{
+	struct mv_xor_v2_device *xor_dev = platform_get_drvdata(pdev);
+
+	dma_async_device_unregister(&xor_dev->dmadev);
+
+	dma_free_coherent(&pdev->dev,
+			  xor_dev->desc_size * MV_XOR_V2_MAX_DESC_NUM,
+			  xor_dev->hw_desq_virt, xor_dev->hw_desq);
+
+	platform_msi_domain_free_irqs(&pdev->dev);
+
+	return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id mv_xor_v2_dt_ids[] = {
+	{ .compatible = "marvell,mv-xor-v2", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mv_xor_v2_dt_ids);
+#endif
+
+static struct platform_driver mv_xor_v2_driver = {
+	.probe		= mv_xor_v2_probe,
+	.remove		= mv_xor_v2_remove,
+	.driver		= {
+		.name	= "mv_xor_v2",
+		.of_match_table = of_match_ptr(mv_xor_v2_dt_ids),
+	},
+};
+
+module_platform_driver(mv_xor_v2_driver);
+
+MODULE_DESCRIPTION("DMA engine driver for Marvell's Version 2 of XOR engine");
+MODULE_LICENSE("GPL");
+
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Thu Feb 18 07:58:54 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 18 Feb 2016 16:58:54 +0100
Subject: [PATCH v2] irqchip: irq-mvebu-odmi: new driver for platform MSI on
 Marvell 7K/8K
Message-ID: <1455811134-3679-1-git-send-email-thomas.petazzoni@free-electrons.com>

This commits adds a new irqchip driver that handles the ODMI
controller found on Marvell 7K/8K processors. The ODMI controller
provide MSI interrupt functionality to on-board peripherals, much like
the GIC-v2m.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
Changes v1 -> v2:
 - Better commit title, as suggested by Marc Zyngier.
 - Improve the DT binding documentation, as suggested by Marc Zingier:
   add a reference to the GIC documentation, be more specific about
   the marvell,spi-base values, and add the requirement of the
   interrupt-parent property.
 - As suggested by Marc Zyngier, use a single global bitmap to
   allocate all ODMIs, regardless of the frame they belong to. As part
   of this change, the hwirq used to identify the interrupt inside the
   ODMI irqdomain are 0-based (instead of being based on their
   corresponding SPI base value), which allows to significantly
   simplify the allocation/free logic.
---
 .../marvell,odmi-controller.txt                    |  41 ++++
 drivers/irqchip/Kconfig                            |   4 +
 drivers/irqchip/Makefile                           |   1 +
 drivers/irqchip/irq-mvebu-odmi.c                   | 248 +++++++++++++++++++++
 4 files changed, 294 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
 create mode 100644 drivers/irqchip/irq-mvebu-odmi.c

diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
new file mode 100644
index 0000000..252d5c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
@@ -0,0 +1,41 @@
+
+* Marvell ODMI for MSI support
+
+Some Marvell SoCs have an On-Die Message Interrupt (ODMI) controller
+which can be used by on-board peripheral for MSI interrupts.
+
+Required properties:
+
+- compatible           : The value here should contain "marvell,odmi-controller".
+
+- interrupt,controller : Identifies the node as an interrupt controller.
+
+- msi-controller       : Identifies the node as an MSI controller.
+
+- marvell,odmi-frames  : Number of ODMI frames available. Each frame
+                         provides a number of events.
+
+- reg                  : List of register definitions, one for each
+                         ODMI frame.
+
+- marvell,spi-base     : List of GIC base SPI interrupts, one for each
+                         ODMI frame. Those SPI interrupts are 0-based,
+                         i.e marvell,spi-base = <128> will use SPI #96.
+                         See Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
+                         for details about the GIC Device Tree binding.
+
+- interrupt-parent     : Reference to the parent interrupt controller.
+
+Example:
+
+	odmi: odmi at 300000 {
+		compatible = "marvell,odmi-controller";
+		interrupt-controller;
+		msi-controller;
+		marvell,odmi-frames = <4>;
+		reg = <0x300000 0x4000>,
+		      <0x304000 0x4000>,
+		      <0x308000 0x4000>,
+		      <0x30C000 0x4000>;
+		marvell,spi-base = <128>, <136>, <144>, <152>;
+	};
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 715923d..18bed3c 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -217,3 +217,7 @@ config IRQ_MXS
 	def_bool y if MACH_ASM9260 || ARCH_MXS
 	select IRQ_DOMAIN
 	select STMP_DEVICE
+
+config MVEBU_ODMI
+	bool
+	select GENERIC_MSI_IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 18caacb..29c388f 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -59,3 +59,4 @@ obj-$(CONFIG_ARCH_SA1100)		+= irq-sa11x0.o
 obj-$(CONFIG_INGENIC_IRQ)		+= irq-ingenic.o
 obj-$(CONFIG_IMX_GPCV2)			+= irq-imx-gpcv2.o
 obj-$(CONFIG_PIC32_EVIC)		+= irq-pic32-evic.o
+obj-$(CONFIG_MVEBU_ODMI)		+= irq-mvebu-odmi.o
diff --git a/drivers/irqchip/irq-mvebu-odmi.c b/drivers/irqchip/irq-mvebu-odmi.c
new file mode 100644
index 0000000..0017f05
--- /dev/null
+++ b/drivers/irqchip/irq-mvebu-odmi.c
@@ -0,0 +1,248 @@
+/*
+ * Copyright (C) 2016 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#define pr_fmt(fmt) "GIC-ODMI: " fmt
+
+#include <linux/irq.h>
+#include <linux/irqchip.h>
+#include <linux/irqdomain.h>
+#include <linux/kernel.h>
+#include <linux/msi.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+#define GICP_ODMIN_SET			0x40
+#define   GICP_ODMI_INT_NUM_SHIFT	12
+#define GICP_ODMIN_GM_EP_R0		0x110
+#define GICP_ODMIN_GM_EP_R1		0x114
+#define GICP_ODMIN_GM_EA_R0		0x108
+#define GICP_ODMIN_GM_EA_R1		0x118
+
+/*
+ * We don't support the group events, so we simply have 8 interrupts
+ * per frame.
+ */
+#define NODMIS_PER_FRAME 8
+#define NODMIS_SHIFT     3
+#define NODMIS_MASK      7
+
+struct odmi_data {
+	struct resource res;
+	void __iomem *base;
+	unsigned int spi_base;
+};
+
+static struct odmi_data *odmis;
+static unsigned long *odmis_bm;
+static unsigned int odmis_count;
+
+/* Protects odmis_bm */
+static DEFINE_SPINLOCK(odmis_bm_lock);
+
+static int odmi_set_affinity(struct irq_data *d,
+			     const struct cpumask *mask, bool force)
+{
+	int ret;
+
+	ret = irq_chip_set_affinity_parent(d, mask, force);
+	if (ret == IRQ_SET_MASK_OK)
+		ret = IRQ_SET_MASK_OK_DONE;
+
+	return ret;
+}
+
+static void odmi_compose_msi_msg(struct irq_data *d, struct msi_msg *msg)
+{
+	struct odmi_data *odmi;
+	phys_addr_t addr;
+	unsigned int odmin;
+
+	if (WARN_ON(d->hwirq >= odmis_count * NODMIS_PER_FRAME))
+		return;
+
+	odmi = &odmis[d->hwirq >> NODMIS_SHIFT];
+	odmin = d->hwirq & NODMIS_MASK;
+
+	addr = odmi->res.start + GICP_ODMIN_SET;
+
+	msg->address_hi = upper_32_bits(addr);
+	msg->address_lo = lower_32_bits(addr);
+	msg->data = odmin << GICP_ODMI_INT_NUM_SHIFT;
+}
+
+static struct irq_chip odmi_irq_chip = {
+	.name			= "ODMI",
+	.irq_mask		= irq_chip_mask_parent,
+	.irq_unmask		= irq_chip_unmask_parent,
+	.irq_eoi		= irq_chip_eoi_parent,
+	.irq_set_affinity	= odmi_set_affinity,
+	.irq_compose_msi_msg	= odmi_compose_msi_msg,
+};
+
+static int odmi_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+				 unsigned int nr_irqs, void *args)
+{
+	struct odmi_data *odmi = NULL;
+	struct irq_fwspec fwspec;
+	struct irq_data *d;
+	unsigned int hwirq, odmin;
+	int ret;
+
+	spin_lock(&odmis_bm_lock);
+	hwirq = find_first_zero_bit(odmis_bm, NODMIS_PER_FRAME * odmis_count);
+	if (hwirq >= NODMIS_PER_FRAME * odmis_count) {
+		spin_unlock(&odmis_bm_lock);
+		return -ENOSPC;
+	}
+
+	__set_bit(hwirq, odmis_bm);
+	spin_unlock(&odmis_bm_lock);
+
+	odmi = &odmis[hwirq >> NODMIS_SHIFT];
+	odmin = hwirq & NODMIS_MASK;
+
+	fwspec.fwnode = domain->parent->fwnode;
+	fwspec.param_count = 3;
+	fwspec.param[0] = GIC_SPI;
+	fwspec.param[1] = odmi->spi_base - 32 + odmin;
+	fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
+
+	ret = irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
+	if (ret) {
+		pr_err("Cannot allocate parent IRQ\n");
+		spin_lock(&odmis_bm_lock);
+		__clear_bit(odmin, odmis_bm);
+		spin_unlock(&odmis_bm_lock);
+		return ret;
+	}
+
+	/* Configure the interrupt line to be edge */
+	d = irq_domain_get_irq_data(domain->parent, virq);
+	d->chip->irq_set_type(d, IRQ_TYPE_EDGE_RISING);
+
+	irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
+				      &odmi_irq_chip, NULL);
+
+	return 0;
+}
+
+static void odmi_irq_domain_free(struct irq_domain *domain,
+				 unsigned int virq, unsigned int nr_irqs)
+{
+	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+
+	if (d->hwirq >= odmis_count * NODMIS_PER_FRAME) {
+		pr_err("Failed to teardown msi. Invalid hwirq %lu\n", d->hwirq);
+		return;
+	}
+
+	irq_domain_free_irqs_parent(domain, virq, nr_irqs);
+
+	/* Actually free the MSI */
+	spin_lock(&odmis_bm_lock);
+	__clear_bit(d->hwirq, odmis_bm);
+	spin_unlock(&odmis_bm_lock);
+}
+
+static const struct irq_domain_ops odmi_domain_ops = {
+	.alloc	= odmi_irq_domain_alloc,
+	.free	= odmi_irq_domain_free,
+};
+
+static struct irq_chip odmi_msi_irq_chip = {
+	.name	= "ODMI",
+};
+
+static struct msi_domain_ops odmi_msi_ops = {
+};
+
+static struct msi_domain_info odmi_msi_domain_info = {
+	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),
+	.ops	= &odmi_msi_ops,
+	.chip	= &odmi_msi_irq_chip,
+};
+
+static int __init mvebu_odmi_init(struct device_node *node,
+				  struct device_node *parent)
+{
+	struct irq_domain *inner_domain, *plat_domain;
+	int ret, i;
+
+	if (of_property_read_u32(node, "marvell,odmi-frames", &odmis_count))
+		return -EINVAL;
+
+	odmis = kcalloc(odmis_count, sizeof(struct odmi_data), GFP_KERNEL);
+	if (!odmis)
+		return -ENOMEM;
+
+	odmis_bm = kzalloc(odmis_count * NODMIS_PER_FRAME / BITS_PER_BYTE,
+			   GFP_KERNEL);
+	if (!odmis_bm) {
+		ret = -ENOMEM;
+		goto err_alloc;
+	}
+
+	for (i = 0; i < odmis_count; i++) {
+		struct odmi_data *odmi = &odmis[i];
+
+		ret = of_address_to_resource(node, i, &odmi->res);
+		if (ret)
+			goto err_unmap;
+
+		odmi->base = of_io_request_and_map(node, i, "odmi");
+		if (IS_ERR(odmi->base)) {
+			ret = PTR_ERR(odmi->base);
+			goto err_unmap;
+		}
+
+		if (of_property_read_u32_index(node, "marvell,spi-base",
+					       i, &odmi->spi_base)) {
+			ret = -EINVAL;
+			goto err_unmap;
+		}
+	}
+
+	inner_domain = irq_domain_create_linear(of_node_to_fwnode(node),
+						odmis_count * NODMIS_PER_FRAME,
+						&odmi_domain_ops, NULL);
+	if (!inner_domain) {
+		ret = -ENOMEM;
+		goto err_unmap;
+	}
+
+	inner_domain->parent = irq_find_host(parent);
+
+	plat_domain = platform_msi_create_irq_domain(of_node_to_fwnode(node),
+						     &odmi_msi_domain_info,
+						     inner_domain);
+	if (!plat_domain) {
+		ret = -ENOMEM;
+		goto err_remove_inner;
+	}
+
+	return 0;
+
+err_remove_inner:
+	irq_domain_remove(inner_domain);
+err_unmap:
+	for (i = 0; i < odmis_count; i++) {
+		struct odmi_data *odmi = &odmis[i];
+
+		if (odmi->base && !IS_ERR(odmi->base))
+			iounmap(odmis[i].base);
+	}
+	kfree(odmis_bm);
+err_alloc:
+	kfree(odmis);
+	return ret;
+}
+
+IRQCHIP_DECLARE(mvebu_odmi, "marvell,odmi-controller", mvebu_odmi_init);
-- 
2.6.4



From ulf.hansson at linaro.org  Thu Feb 18 08:00:08 2016
From: ulf.hansson at linaro.org (Ulf Hansson)
Date: Thu, 18 Feb 2016 17:00:08 +0100
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <56C1B62B.5060708@nvidia.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
 <7hh9hdzflv.fsf@baylibre.com> <56C1B62B.5060708@nvidia.com>
Message-ID: <CAPDyKFoPrFoMOFxC37zXX4L3VdLKknaw_LUTw7ycr9mfa_=7_A@mail.gmail.com>

[...]

>>
>> What about the pm_clk_* API which was built for tracking clocks
>> associated with devices for runtime PM.
>>
>> IOW, you could pm_clk_add(pg->pmc->dev, pg->clks[i]) and then your
>> _enable_clocks() would become pm_clk_suspend() an dyour
>> _disable_clocks() would become pm_clk_resume().
>
> Very interesting, I was not aware of this.
>
>> I might not be following the mapping between PMC and PGs though so not
>> sure pg->pmc->dev is the right struct device, but you get the idea.
>
> Yes, so this will not work here as-is, because the pmc->dev is common to
> all pm-domains (it is the device that creates all the pm-domains). So to
> make this work, I would need to create a device for each pm-domain and
> add the clocks to that.
>
> I see that this works very well for normal drivers, but it does not feel
> so natural for pm-domains where we don't have a device struct today. By
> the way, the rockchip pm-domains implementation is very much in the same
> boat as tegra, where there are multiple clocks per pm-domain and it is
> handled by a simple list. So I am not sure if you think that we should
> be turning all pm-domains registered by pm_genpd_init() into a device
> and then we can make use of these pm_clk_XXXX() APIs?
>
> I have implemented the generic clk APIs that Ulf and I discussed for
> handling multiple clocks, but if we think that this is a better way,
> then I will hold off for now.

I think Kevin has a point that we already have PM clocks to build upon.
Could we perhaps try to extend that API instead to suite this needs as well?

I do realize that it will make this patchset more complicated. As I
stated earlier, this was just an idea I had, so to be clear I won't
hold back an ack for this patchset, if you decide to deal with this in
separate "improvement" step.

Kind regards
Uffe


From nicolas.pitre at linaro.org  Thu Feb 18 08:02:33 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Feb 2016 11:02:33 -0500 (EST)
Subject: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values
In-Reply-To: <1455804123-2526139-5-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-5-git-send-email-arnd@arndb.de>
Message-ID: <alpine.LFD.2.20.1602181100410.13632@knanqh.ubzr>

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

> For platforms that are not yet converted to ARCH_MULTIPLATFORM,
> we can disable CONFIG_ARM_PATCH_PHYS_VIRT, which in turn requires
> setting a correct address here.
> 
> As we actualy know what all the values are supposed to be based
> on the old mach/memory.h header file contents (from git history),
> we can just add them here.
> 
> This also solves a problem in Kconfig where 'make randconfig'
> fails to continue if no number is selected for a 'hex' option.
> Users can still override the number at configuration time, e.g.
> when the memory visible to the kernel starts at a nonstandard
> address on some machine, but it should no longer be required
> now.
> 
> To make this foolproof, another patch is required in mach-davinci
> to prevent a configuration with both DMx and DA8xx enabled but
> ARM_PATCH_PHYS_VIRT disabled. The two patches however can be
> merged independently as there is no direct dependency between
> them.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Acked-by: Nicolas Pitre <nico at linaro.org>

Is there a way to provide a default for defaults?


> ---
>  arch/arm/Kconfig | 20 +++++++++++++++++---
>  1 file changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index be00b53f399b..7839c9923709 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -271,15 +271,29 @@ config PHYS_OFFSET
>  	depends on !ARM_PATCH_PHYS_VIRT
>  	default DRAM_BASE if !MMU
>  	default 0x00000000 if ARCH_EBSA110 || \
> +			ARCH_DOVE || \
>  			ARCH_FOOTBRIDGE || \
> +			(ARCH_GEMINI && GEMINI_MEM_SWAP) || \
>  			ARCH_INTEGRATOR || \
> +			ARCH_IOP33X || \
>  			ARCH_IOP13XX || \
> +			ARCH_IXP4XX || \
>  			ARCH_KS8695 || \
> -			(ARCH_REALVIEW && !REALVIEW_HIGH_PHYS_OFFSET)
> -	default 0x10000000 if ARCH_OMAP1 || ARCH_RPC
> +			(ARCH_REALVIEW && !REALVIEW_HIGH_PHYS_OFFSET) || \
> +			ARCH_W90X900
> +	default 0x10000000 if (ARCH_GEMINI && !GEMINI_MEM_SWAP) || \
> +			ARCH_OMAP1 || \
> +			ARCH_RPC
>  	default 0x20000000 if ARCH_S5PV210
> +	default 0x30000000 if ARCH_S3C24XX
>  	default 0x70000000 if REALVIEW_HIGH_PHYS_OFFSET
> -	default 0xc0000000 if ARCH_SA1100
> +	default 0x80000000 if (ARCH_DAVINCI_DMx && !ARCH_DAVINCI_DA8XX) || \
> +			ARCH_NETX || \
> +			ARCH_LPC32XX
> +	default 0xa0000000 if ARCH_IOP32X || ARCH_PXA
> +	default 0xc0000000 if (ARCH_DAVINCI_DA8XX && !ARCH_DAVINCI_DMx) || \
> +			ARCH_CLPS711X || \
> +			ARCH_SA1100
>  	help
>  	  Please provide the physical address corresponding to the
>  	  location of main memory in your system.
> -- 
> 2.7.0
> 
> 


From davem at davemloft.net  Thu Feb 18 08:05:14 2016
From: davem at davemloft.net (David Miller)
Date: Thu, 18 Feb 2016 11:05:14 -0500 (EST)
Subject: [PATCH 2/2] net, thunderx: Use bool in structs where possible
In-Reply-To: <1455799149-19590-3-git-send-email-rrichter@caviumnetworks.com>
References: <1455799149-19590-1-git-send-email-rrichter@caviumnetworks.com>
 <1455799149-19590-3-git-send-email-rrichter@caviumnetworks.com>
Message-ID: <20160218.110514.652169911099659792.davem@davemloft.net>

From: Robert Richter <rrichter at caviumnetworks.com>
Date: Thu, 18 Feb 2016 13:39:09 +0100

> From: Robert Richter <rrichter at cavium.com>
> 
> Looks like the :1 notation was accidentally introduced (this still
> uses 1 byte per flag). Using bool instead, which is the common use.
> 
> Signed-off-by: Robert Richter <rrichter at cavium.com>

Such cleanups are not appropriate for 'net'.  Only real bug fixes should
be targetted that.

Respin these patches targetting the correct tree(s).


From nicolas.pitre at linaro.org  Thu Feb 18 08:06:08 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Feb 2016 11:06:08 -0500 (EST)
Subject: [PATCH 1/9] ARM: ARMv7-M uses BE-8, not BE-32
In-Reply-To: <1455804123-2526139-2-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-2-git-send-email-arnd@arndb.de>
Message-ID: <alpine.LFD.2.20.1602181102570.13632@knanqh.ubzr>

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

> When configuring the kernel for big-endian, we set either BE-8 or BE-32
> based on the CPU architecture level. Until linux-4.4, we did not have
> any ARMv7-M platform allowing big-endian builds, but now i.MX/Vybrid
> is in that category, adn we get a build error because of this:
> 
> arch/arm/kernel/module-plts.c: In function 'get_module_plt':
> arch/arm/kernel/module-plts.c:60:46: error: implicit declaration of function '__opcode_to_mem_thumb32' [-Werror=implicit-function-declaration]
> 
> This comes down to picking the wrong default, ARMv7-M uses BE8
> like ARMv7-A does. Changing the default gets the kernel to compile
> and presumably works.

Was it tested without BE8 when it was submitted upstream? I don't think 
you can switch this freely on a given hardware platform and expect it to 
still work.




> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/mm/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> index 55347662e5ed..ff1637365494 100644
> --- a/arch/arm/mm/Kconfig
> +++ b/arch/arm/mm/Kconfig
> @@ -723,7 +723,7 @@ config CPU_BIG_ENDIAN
>  config CPU_ENDIAN_BE8
>  	bool
>  	depends on CPU_BIG_ENDIAN
> -	default CPU_V6 || CPU_V6K || CPU_V7
> +	default CPU_V6 || CPU_V6K || CPU_V7 || CPU_V7M
>  	help
>  	  Support for the BE-8 (big-endian) mode on ARMv6 and ARMv7 processors.
>  
> -- 
> 2.7.0
> 
> 


From alex.williamson at redhat.com  Thu Feb 18 08:06:08 2016
From: alex.williamson at redhat.com (Alex Williamson)
Date: Thu, 18 Feb 2016 09:06:08 -0700
Subject: [RFC v3 05/15] iommu/arm-smmu: implement
 alloc/free_reserved_iova_domain
In-Reply-To: <56C5A65D.5010401@arm.com>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
 <1455264797-2334-6-git-send-email-eric.auger@linaro.org>
 <56C5A65D.5010401@arm.com>
Message-ID: <20160218090608.025a5103@t450s.home>

On Thu, 18 Feb 2016 11:09:17 +0000
Robin Murphy <robin.murphy at arm.com> wrote:

> Hi Eric,
> 
> On 12/02/16 08:13, Eric Auger wrote:
> > Implement alloc/free_reserved_iova_domain for arm-smmu. we use
> > the iova allocator (iova.c). The iova_domain is attached to the
> > arm_smmu_domain struct. A mutex is introduced to protect it.  
> 
> The IOMMU API currently leaves IOVA management entirely up to the caller 
> - VFIO is already managing its own IOVA space, so what warrants this 
> being pushed all the way down to the IOMMU driver? All I see here is 
> abstract code with no hardware-specific details that'll have to be 
> copy-pasted into other IOMMU drivers (e.g. SMMUv3), which strongly 
> suggests it's the wrong place to do it.
> 
> As I understand the problem, VFIO has a generic "configure an IOMMU to 
> point at an MSI doorbell" step to do in the process of attaching a 
> device, which hasn't needed implementing yet due to VT-d's 
> IOMMU_CAP_I_AM_ALSO_ACTUALLY_THE_MSI_CONTROLLER_IN_DISGUISE flag, which 
> most of us have managed to misinterpret so far. AFAICS all the IOMMU 
> driver should need to know about this is an iommu_map() call (which will 
> want a slight extension[1] to make things behave properly). We should be 
> fixing the abstraction to be less x86-centric, not hacking up all the 
> ARM drivers to emulate x86 hardware behaviour in software.

The gap I see is that, that the I_AM_ALSO_ACTUALLY_THE_MSI...
solution transparently fixes, is that there's no connection between
pci_enable_msi{x}_range and the IOMMU API.  If I want to allow a device
managed by an IOMMU API domain to perform MSI, I need to go scrape the
MSI vectors out of the device, setup a translation into my IOVA space,
and re-write those vectors.  Not to mention that as an end user, I
have no idea what might be sharing the page where those vectors are
targeted and what I might be allowing the user DMA access to.  MSI
setup is necessarily making use of the IOVA space of the device, so
there's clearly an opportunity to interact with the IOMMU API to manage
that IOVA usage.  x86 has an implicit range of IOVA space for MSI, this
makes an explicit range, reserved by the IOMMU API user for this
purpose.  At the vfio level, I just want to be able to call the PCI
MSI/X setup routines and have them automatically program vectors that
make use of IOVA space that I've already marked reserved for this
purpose.  I don't see how that's x86-centric other than x86 has already
managed to make this transparent and spoiled users into expecting
working IOVAs on the device after using standard MSI vector setup
callbacks.  That's the goal I'm looking for.  Thanks,

Alex


From arnd at arndb.de  Thu Feb 18 08:08:05 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 17:08:05 +0100
Subject: [PATCH v2] irqchip: irq-mvebu-odmi: new driver for platform MSI
 on Marvell 7K/8K
In-Reply-To: <1455811134-3679-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455811134-3679-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <3923904.c50oLNXXZ1@wuerfel>

On Thursday 18 February 2016 16:58:54 Thomas Petazzoni wrote:
> +- marvell,spi-base     : List of GIC base SPI interrupts, one for each
> +                         ODMI frame. Those SPI interrupts are 0-based,
> +                         i.e marvell,spi-base = <128> will use SPI #96.
> +                         See Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
> +                         for details about the GIC Device Tree binding.
> 

Why are these not just in an 'interrupts' property as we do for other
nested irqchips?

	Arnd


From arnd at arndb.de  Thu Feb 18 08:12:13 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 17:12:13 +0100
Subject: [PATCH 1/9] ARM: ARMv7-M uses BE-8, not BE-32
In-Reply-To: <alpine.LFD.2.20.1602181102570.13632@knanqh.ubzr>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-2-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602181102570.13632@knanqh.ubzr>
Message-ID: <2702301.CTWUiSsjZR@wuerfel>

On Thursday 18 February 2016 11:06:08 Nicolas Pitre wrote:
> On Thu, 18 Feb 2016, Arnd Bergmann wrote:
> 
> > When configuring the kernel for big-endian, we set either BE-8 or BE-32
> > based on the CPU architecture level. Until linux-4.4, we did not have
> > any ARMv7-M platform allowing big-endian builds, but now i.MX/Vybrid
> > is in that category, adn we get a build error because of this:
> > 
> > arch/arm/kernel/module-plts.c: In function 'get_module_plt':
> > arch/arm/kernel/module-plts.c:60:46: error: implicit declaration of function '__opcode_to_mem_thumb32' [-Werror=implicit-function-declaration]
> > 
> > This comes down to picking the wrong default, ARMv7-M uses BE8
> > like ARMv7-A does. Changing the default gets the kernel to compile
> > and presumably works.
> 
> Was it tested without BE8 when it was submitted upstream? I don't think 
> you can switch this freely on a given hardware platform and expect it to 
> still work.
> 
> 

mach-imx contains a number of different SoCs, and one SoC was recently
tested successfully after a number of endianess bugs got fixed. This was
an i.mx6 using a Cortex-A9 core, but we are now also able to build
vybrid vf610 big-endian based on that selection. This SoC supports
Linux running either on its Cortex-A5 or its Cortex-M3 (or M4?) cores.

I am rather sure nobody has ever run Linux in big-endian mode on the
Cortex-M platform, specifically because it was always wrong and could
not be enabled in Kconfig.

	Arnd


From nicolas.pitre at linaro.org  Thu Feb 18 08:13:52 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Feb 2016 11:13:52 -0500 (EST)
Subject: [PATCH 5/9] ARM: atags_to_fdt: don't warn about stack size
In-Reply-To: <1455804123-2526139-6-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-6-git-send-email-arnd@arndb.de>
Message-ID: <alpine.LFD.2.20.1602181112310.13632@knanqh.ubzr>

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

> The merge_fdt_bootargs() function by definition consumes more than 1024
> bytes of stack because it has a 1024 byte command line on the stack,
> meaning that we always get a warning when building this file:
> 
> arch/arm/boot/compressed/atags_to_fdt.c: In function 'merge_fdt_bootargs':
> arch/arm/boot/compressed/atags_to_fdt.c:98:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> 
> However, as this is the decompressor and we know that it has a very shallow
> call chain, and we do not actually risk overflowing the kernel stack
> at runtime here.
> 
> This just shuts up the warning by disabling the warning flag for this
> file.

What about setting the warning to 2048 instead?



> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/boot/compressed/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index 7a6a58ef8aaf..b5db4c868640 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -85,6 +85,8 @@ $(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: $(srctree)/scripts/dtc/
>  $(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \
>  	$(addprefix $(obj)/,$(libfdt_hdrs))
>  
> +CFLAGS_REMOVE_atags_to_fdt.o += -Wframe-larger-than=${CONFIG_FRAME_WARN}
> +
>  ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
>  OBJS	+= $(libfdt_objs) atags_to_fdt.o
>  endif
> -- 
> 2.7.0
> 
> 


From nicolas.pitre at linaro.org  Thu Feb 18 08:15:32 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Feb 2016 11:15:32 -0500 (EST)
Subject: [PATCH 6/9] ARM: uaccess: avoid warning for NOMMU in access_ok
In-Reply-To: <1455804123-2526139-7-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-7-git-send-email-arnd@arndb.de>
Message-ID: <alpine.LFD.2.20.1602181115040.13632@knanqh.ubzr>

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

> When CONFIG_MMU is disabled, the access_ok() and __range_ok()
> macros always return success, and there is a cast to void
> to ensure the compiler does not warn about an unused address
> variable. However, at least one driver has a variable for
> the size argument as well and does warn about that one:
> 
> drivers/vhost/vhost.c: In function 'vq_access_ok':
> drivers/vhost/vhost.c:633:9: warning: unused variable 's' [-Wunused-variable]
> 
> This changes the macro to also ignore the size argument
> explicitly to shut up that warning.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Acked-by: Nicolas Pitre <nico at linaro.org>

> ---
>  arch/arm/include/asm/uaccess.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
> index 35c9db857ebe..9c74c84a10d2 100644
> --- a/arch/arm/include/asm/uaccess.h
> +++ b/arch/arm/include/asm/uaccess.h
> @@ -290,7 +290,7 @@ extern int __put_user_8(void *, unsigned long long);
>  
>  #define segment_eq(a, b)		(1)
>  #define __addr_ok(addr)		((void)(addr), 1)
> -#define __range_ok(addr, size)	((void)(addr), 0)
> +#define __range_ok(addr, size)	((void)(addr), (void)(size), 0)
>  #define get_fs()		(KERNEL_DS)
>  
>  static inline void set_fs(mm_segment_t fs)
> -- 
> 2.7.0
> 
> 


From thomas.petazzoni at free-electrons.com  Thu Feb 18 08:16:23 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 18 Feb 2016 17:16:23 +0100
Subject: [PATCH v2] irqchip: irq-mvebu-odmi: new driver for platform MSI
 on Marvell 7K/8K
In-Reply-To: <3923904.c50oLNXXZ1@wuerfel>
References: <1455811134-3679-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <3923904.c50oLNXXZ1@wuerfel>
Message-ID: <20160218171623.664dabd1@free-electrons.com>

Arnd,

On Thu, 18 Feb 2016 17:08:05 +0100, Arnd Bergmann wrote:
> On Thursday 18 February 2016 16:58:54 Thomas Petazzoni wrote:
> > +- marvell,spi-base     : List of GIC base SPI interrupts, one for each
> > +                         ODMI frame. Those SPI interrupts are 0-based,
> > +                         i.e marvell,spi-base = <128> will use SPI #96.
> > +                         See Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
> > +                         for details about the GIC Device Tree binding.
> > 
> 
> Why are these not just in an 'interrupts' property as we do for other
> nested irqchips?

I modeled this after the GICv2m bindings. I think the reason is that if
we were to use the interrupts property, we should be listing *all*
interrupts of the parent interrupt controller we are using. Which would
be quite painful when your ODMI interrupt controller uses 32 interrupts
of the parent controller (I think for the GICv2m, it's even more).

I.e, we currently say:

	marvell,spi-base = <128>, <136>, <144>, <152>

but in fact we are using 128, 129, 130, 131, 132, 133, 134, 135, 136,
137, etc. until 159.

If you think

	interrupts = <128>, <136>, <144>, <152>

is still correct, then why not. But I believe this might be confusing,
as people will think that we are only using interrupts 128, 136, 144
and 152, and not 129, 133, 147 or 158.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From stuart.yoder at nxp.com  Thu Feb 18 08:16:26 2016
From: stuart.yoder at nxp.com (Stuart Yoder)
Date: Thu, 18 Feb 2016 16:16:26 +0000
Subject: RFC: extend IOMMU attributes
Message-ID: <HE1PR04MB1641F22E38710B68F4ED891F8DAF0@HE1PR04MB1641.eurprd04.prod.outlook.com>

Hi Joerg and Will,

We are implementing support for some specialized NXP SoC network
devices and have the desire to extend the mapping attributes beyond
those currently in iommu.h. (I see there is a recent proposal to
add an IOMMU_MMIO flag)

What we have right now in Linux is a least-common-denominator set of
attributes, while for the ARM SMMU there is a much richer set of
attributes that seem useful to support. Specifically, we have one
SoC device we're dealing with right now that is the target of DMA
that functionally requires a "cacheable, non-shareable" attribute
in its SMMU mapping.

In addition, there are many other attributes such as r/w allocate
hints, transient hints, write-back/write-thru, etc in the SMMU.

We wanted to see what your thinking is with respect to the
direction the Linux IOMMU layer will head over the longer term with
respect to attributes.

Is there anything problematic with continuing to grow the
attributes in iommu.h?...e.g.:

 #define IOMMU_READ            (1 << 0)
 #define IOMMU_WRITE           (1 << 1)
-#define IOMMU_CACHE           (1 << 2) /* DMA cache coherency */
+#define IOMMU_CACHE_COHERENT  (1 << 2) /* cacheable and coherent */
 #define IOMMU_NOEXEC          (1 << 3)
 #define IOMMU_MMIO            (1 << 4) /* e.g. things like MSI doorbells */
+#define IOMMU_CACHEABLE       (1 << 5) /* cacheable, not coherent */
+#define IOMMU_CACHE_ALLOCATE  (1 << 6) /* hint to allocate in the cache */

Also, are we willing to let somewhat architecture specific flags
onto that list?  For, example the ARM 'transient' hint.

Another potential direction would be to provide some approach
where IOMMU PTE attributes could be somehow derived from a
corresponding MMU PTE in an arch-specific manner and the IOMMU
API itself would not have to explicitly define all possible
attributes.

Thoughts?

Thanks,
Stuart


From stefan at agner.ch  Thu Feb 18 08:13:59 2016
From: stefan at agner.ch (Stefan Agner)
Date: Thu, 18 Feb 2016 08:13:59 -0800
Subject: no irq domain found for ... a GPIO interrupt controller
In-Reply-To: <20160218091432.6968b836@arm.com>
References: <2dc0519827dc9d210e38c498d830cd97@agner.ch>
 <20160218091432.6968b836@arm.com>
Message-ID: <11a0b1f5808af5bdabaab657366918d4@agner.ch>

Hi Marc,

On 2016-02-18 01:14, Marc Zyngier wrote:
<snip>
> What your stack trace shows is that the failure occurs at boot time,
> when of_platform_populate() parses the DT and creates the platform
> devices. As part of this process, it tries to resolves the interrupt
> specifiers, but fails to do so for this particular device, since the
> corresponding irqchip and domain have not been created yet (the GPIO
> controller is itself a device, while other irqchips are not).
> 
> But as long as your device driver uses platform_get_irq(), you will
> force the interrupt specifier to be evaluated again, this time giving
> you a valid interrupt (and provided that your GPIO driver has
> initialized in the meantime - check for -EPROBE_DEFER). At some point,
> we'll be able to kill the interrupt resolution from
> of_platform_populate().

The device driver is using platform_get_irq. However, I think it
currently would not handle EPROBE_DEFER right, but seems also not to
happen in practice...

> 
> To summarize, your driver not working may not be related to this issue.

So this means that despite the warning, nothing I really need to worry
right? Does this warning will go away in the future?

--
Stefan


From nicolas.pitre at linaro.org  Thu Feb 18 08:17:36 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Feb 2016 11:17:36 -0500 (EST)
Subject: [PATCH 7/9] ARM: move NO_DMA definition to ecard.h
In-Reply-To: <1455804123-2526139-8-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-8-git-send-email-arnd@arndb.de>
Message-ID: <alpine.LFD.2.20.1602181116410.13632@knanqh.ubzr>

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

> The NO_DMA macro is only used on the RiscPC ecard bus, and conflicts
> with a couple of driver specific macros with the same name:
> 
> drivers/scsi/eata.c:571:0: warning: "NO_DMA" redefined
>  #define NO_DMA  0xff
> In file included from ../drivers/scsi/eata.c:495:0:
> arch/arm/include/asm/dma.h:140:0: note: this is the location of the previous definition
>  #define NO_DMA 255
> 
> This moves the definition out of the asm/dma.h header that is used
> by all ISA DMA API users and into the ecard header.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Acked-by: Nicolas Pitre <nico at linaro.org>



> ---
>  arch/arm/include/asm/dma.h   | 4 ----
>  arch/arm/include/asm/ecard.h | 4 ++++
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/include/asm/dma.h b/arch/arm/include/asm/dma.h
> index bb4fa67da541..573128481fc4 100644
> --- a/arch/arm/include/asm/dma.h
> +++ b/arch/arm/include/asm/dma.h
> @@ -136,10 +136,6 @@ extern void set_dma_speed(unsigned int chan, int cycle_ns);
>   */
>  extern int  get_dma_residue(unsigned int chan);
>  
> -#ifndef NO_DMA
> -#define NO_DMA	255
> -#endif
> -
>  #endif /* CONFIG_ISA_DMA_API */
>  
>  #ifdef CONFIG_PCI
> diff --git a/arch/arm/include/asm/ecard.h b/arch/arm/include/asm/ecard.h
> index eaea14676d57..d3e16628c792 100644
> --- a/arch/arm/include/asm/ecard.h
> +++ b/arch/arm/include/asm/ecard.h
> @@ -83,6 +83,10 @@
>  #define CONST const
>  #endif
>  
> +#ifndef NO_DMA
> +#define NO_DMA	255
> +#endif
> +
>  #define MAX_ECARDS	9
>  
>  struct ecard_id {			/* Card ID structure		*/
> -- 
> 2.7.0
> 
> 


From matthias.bgg at gmail.com  Thu Feb 18 08:18:49 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Thu, 18 Feb 2016 17:18:49 +0100
Subject: [PATCH 3/3] ARM64: dts: mt8173: Add thermal/auxadc device nodes
In-Reply-To: <1448883753-19068-4-git-send-email-s.hauer@pengutronix.de>
References: <1448883753-19068-1-git-send-email-s.hauer@pengutronix.de>
 <1448883753-19068-4-git-send-email-s.hauer@pengutronix.de>
Message-ID: <56C5EEE9.4020407@gmail.com>

Hi Sascha,

On 30/11/15 12:42, Sascha Hauer wrote:
> This adds the thermal controller and auxadc nodes to the Mediatek MT8173
> dtsi file.
>
> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
> Reviewed-by: Daniel Kurtz <djkurtz at chromium.org>
> ---
>   arch/arm64/boot/dts/mediatek/mt8173.dtsi | 17 +++++++++++++++++
>   1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 06a1564..e2ddd03 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -277,6 +277,11 @@
>   				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
>   		};
>
> +		auxadc: auxadc at 11001000 {
> +			compatible = "mediatek,mt8173-auxadc";

Can you please write a small Documentation about the binding.
I suppose it will be mediatek,auxadc and mediatek,mt8173-auxadc.

I can't do it my self, as my datasheet lacks the auxadc registers.

Thanks,
Matthias

> +			reg = <0 0x11001000 0 0x1000>;
> +		};
> +
>   		uart0: serial at 11002000 {
>   			compatible = "mediatek,mt8173-uart",
>   				     "mediatek,mt6577-uart";
> @@ -487,6 +492,18 @@
>   			clock-names = "source", "hclk";
>   			status = "disabled";
>   		};
> +
> +		thermal: thermal at 1100b000 {
> +			#thermal-sensor-cells = <0>;
> +			compatible = "mediatek,mt8173-thermal";
> +			reg = <0 0x1100b000 0 0x1000>;
> +			interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
> +			clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
> +			clock-names = "therm", "auxadc";
> +			resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
> +			mediatek,auxadc = <&auxadc>;
> +			mediatek,apmixedsys = <&apmixedsys>;
> +		};
>   	};
>   };
>
>


From thomas.petazzoni at free-electrons.com  Thu Feb 18 08:20:28 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 18 Feb 2016 17:20:28 +0100
Subject: [PATCH v2 4/6] Documentation: arm: add Marvell Armada 7K and 8K
 families
In-Reply-To: <1455812430-4656-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455812430-4656-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455812430-4656-5-git-send-email-thomas.petazzoni@free-electrons.com>

As we are adding support for the Armada 7K and 8K families, this
commit adds them to the Marvell documentation listing all supported
SoCs, together with references to their Product Brief, Homepage and
Device Tree files.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 Documentation/arm/Marvell/README | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index fe867f1..b5bb7f5 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -135,6 +135,26 @@ EBU Armada family ARMv8
 	Product Brief: http://www.marvell.com/embedded-processors/assets/PB-88F3700-FNL.pdf
 	Device tree files: arch/arm64/boot/dts/marvell/armada-37*
 
+  Armada 7K Flavors:
+	88F7020 (AP806 Dual + one CP110)
+	88F7040 (AP806 Quad + one CP110)
+	Core: ARM Cortex A72
+
+	Homepage: http://www.marvell.com/embedded-processors/armada-70xx/
+	Product Brief: http://www.marvell.com/embedded-processors/assets/Armada7020PB-Jan2016.pdf
+		       http://www.marvell.com/embedded-processors/assets/Armada7040PB-Jan2016.pdf
+	Device tree files: arch/arm64/boot/dts/marvell/armada-70*
+
+  Armada 8K Flavors:
+	88F8020 (AP806 Dual + two CP110)
+	88F8040 (AP806 Quad + two CP110)
+	Core: ARM Cortex A72
+
+	Homepage: http://www.marvell.com/embedded-processors/armada-80xx/
+	Product Brief: http://www.marvell.com/embedded-processors/assets/Armada8020PB-Jan2016.pdf
+		       http://www.marvell.com/embedded-processors/assets/Armada8040PB-Jan2016.pdf
+	Device tree files: arch/arm64/boot/dts/marvell/armada-80*
+
 Avanta family
 -------------
 
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Thu Feb 18 08:20:27 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 18 Feb 2016 17:20:27 +0100
Subject: [PATCH v2 3/6] Documentation: arm: add link to Armada 38x Functional
 Spec
In-Reply-To: <1455812430-4656-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455812430-4656-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455812430-4656-4-git-send-email-thomas.petazzoni@free-electrons.com>

The Armada 38x Functional Spec is now available (after registration
unfortunately), so add a link to it.

While at it, fix a typo in the reference to the Armada 38x product
page.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 Documentation/arm/Marvell/README | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index a78453b..fe867f1 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -97,7 +97,8 @@ EBU Armada family
 	88F6810	Armada 380
 	88F6820 Armada 385
 	88F6828 Armada 388
-    Produce infos: http://www.marvell.com/embedded-processors/armada-38x/
+    Product infos:   http://www.marvell.com/embedded-processors/armada-38x/
+    Functional Spec: https://marvellcorp.wufoo.com/forms/marvell-armada-38x-functional-specifications/
     Core: ARM Cortex-A9
 
   Armada 39x Flavors:
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Thu Feb 18 08:20:24 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 18 Feb 2016 17:20:24 +0100
Subject: [PATCH v2 0/6] arm64: Initial support for Marvell Armada 7K/8K
Message-ID: <1455812430-4656-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hello,

This series adds initial support for the new Armada 7K and 8K Marvell
64 bits processors. Details about those processors based on the
Cortex-A72 can be found at:

  http://www.marvell.com/embedded-processors/armada-70xx/
  http://www.marvell.com/embedded-processors/armada-80xx/

One characteristic of those processors is that internally they are
built from several components:

 - One "AP", which contains the processor itself and a few core IP
   blocks. The AP in 7K and 8K is called AP806, and is available on
   two variants: dual Cortex-A72 and quad Cortex-A72.

 - Or or two "CP", which contains most of the I/Os (SATA, PCIe,
   etc.). The CP in 7K and 8K is called CP110. One CP110 is available
   in the 7K family, while two CP110 are available in the 8K family,
   doubling the number of I/O interfaces.

The support added in this series only brings minimal support for the
AP side (and not yet all IP blocks, obviously). Support for the CP
part will come in the future.

Since the series touches similar files as the Armada 3700 series from
Gregory Clement, it is based on it (its 4th version).

Changes since v1:

 - Add initial patch from Arnd which updates the Marvell README, and
   did a few adjustements to it.

 - Use arm,gic-400 as the compatible string identifying the GIC, as
   suggested by Jisheng.

 - Rework the patch series on top of Gregory's latest patch series for
   Armada 3700, since the patch series interact a little bit on a few
   aspects (usage of the ARCH_MVEBU Kconfig option, for example).

 - Fix the size of the register areas used for the GIC to be in line
   with the datasheet. Follows some questions from Marc Zyngier.

Best regards,

Thomas

Arnd Bergmann (1):
  Documentation: arm: update Marvell product listing

Thomas Petazzoni (5):
  Documentation: arm: improve Armada 37xx description
  Documentation: arm: add link to Armada 38x Functional Spec
  Documentation: arm: add Marvell Armada 7K and 8K families
  arm64: update ARCH_MVEBU for Marvell Armada 7K/8K support
  arm64: marvell: add Device Tree files for Armada 7K/8K

 Documentation/arm/Marvell/README                   | 158 +++++++++++---
 .../bindings/arm/marvell/armada-7k-8k.txt          |  24 +++
 arch/arm64/Kconfig.platforms                       |  11 +-
 arch/arm64/boot/dts/marvell/Makefile               |   1 +
 arch/arm64/boot/dts/marvell/armada-7020.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-7040-db.dts     |  92 ++++++++
 arch/arm64/boot/dts/marvell/armada-7040.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-8020.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-8040.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi |  71 +++++++
 arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi |  84 ++++++++
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi      | 234 +++++++++++++++++++++
 12 files changed, 858 insertions(+), 33 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
 create mode 100644 arch/arm64/boot/dts/marvell/armada-7020.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-7040-db.dts
 create mode 100644 arch/arm64/boot/dts/marvell/armada-7040.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-8020.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-8040.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806.dtsi

-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Thu Feb 18 08:20:25 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 18 Feb 2016 17:20:25 +0100
Subject: [PATCH v2 1/6] Documentation: arm: update Marvell product listing
In-Reply-To: <1455812430-4656-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455812430-4656-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455812430-4656-2-git-send-email-thomas.petazzoni@free-electrons.com>

From: Arnd Bergmann <arnd at arndb.de>

I'm still getting confused regarding which core specifically
is used in which SoC, so I've added some more detail to the
Marvell README file. I got most of this from random sources
on the internet, so it's possible that some of the information
is wrong, but most of it should be pretty obvious.

There are a few remaining points I could not find out:

* The CPU core in Orion 88F6183
* The difference (if any) between PJ4B-MP and PJ4C
* The naming of Feroceon/Jolteon/Flareon/Sheeva/Mohawk/PJ1/PJ4
  is still confusing, as they tend to overlap.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
[Thomas:
 - move Armada SP out from the EBU family into its own "Storage"
   family. This chip is indeed not part of the EBU family.
 - fixed the URL for the Armada SP information, since the link of the
   original patch no longer existed
 - explicitly indicate that there is no support in upstream for the
   Armada SP
 - indent the "Core: " description for the Armada XP to be clearly
   under the Armada XP category, so that it is clear it applies to
   Armada XP only, and not other cores of the EBU family.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 Documentation/arm/Marvell/README | 132 +++++++++++++++++++++++++++++++--------
 1 file changed, 105 insertions(+), 27 deletions(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index ddbc048..981164f 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -22,7 +22,7 @@ Orion family
         88F5281
                Datasheet               : http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf
         88F6183
-  Core: Feroceon ARMv5 compatible
+  Core: Feroceon 88fr331 (88f51xx) or 88fr531-vd (88f52xx) ARMv5 compatible
   Linux kernel mach directory: arch/arm/mach-orion5x
   Linux kernel plat directory: arch/arm/plat-orion
 
@@ -52,7 +52,7 @@ Kirkwood family
                 Hardware Spec  : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
                 Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
   Homepage: http://www.marvell.com/embedded-processors/kirkwood/
-  Core: Feroceon ARMv5 compatible
+  Core: Feroceon 88fr131 ARMv5 compatible
   Linux kernel mach directory: arch/arm/mach-mvebu
   Linux kernel plat directory: none
 
@@ -71,7 +71,7 @@ Discovery family
         MV76100
                 Not supported by the Linux kernel.
 
-  Core: Feroceon ARMv5 compatible
+  Core: Feroceon 88fr571-vd ARMv5 compatible
 
   Linux kernel mach directory: arch/arm/mach-mv78xx0
   Linux kernel plat directory: arch/arm/plat-orion
@@ -86,20 +86,25 @@ EBU Armada family
     Product Brief:   http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
     Hardware Spec:   http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
     Functional Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
+    Core: Sheeva ARMv7 compatible PJ4B
 
   Armada 375 Flavors:
 	88F6720
     Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf
-
-  Armada 380/385 Flavors:
-	88F6810
-	88F6820
-	88F6828
-
-  Armada 390/398 Flavors:
-	88F6920
-	88F6928
+    Core: ARM Cortex-A9
+
+  Armada 38x Flavors:
+	88F6810	Armada 380
+	88F6820 Armada 385
+	88F6828 Armada 388
+    Produce infos: http://www.marvell.com/embedded-processors/armada-38x/
+    Core: ARM Cortex-A9
+
+  Armada 39x Flavors:
+	88F6920 Armada 390
+	88F6928 Armada 398
     Product infos: http://www.marvell.com/embedded-processors/armada-39x/
+    Core: ARM Cortex-A9
 
   Armada XP Flavors:
         MV78230
@@ -112,8 +117,7 @@ EBU Armada family
       http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF
       http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
       http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
-
-  Core: Sheeva ARMv7 compatible
+    Core: Sheeva ARMv7 compatible Dual-core or Quad-core PJ4B-MP
 
   Linux kernel mach directory: arch/arm/mach-mvebu
   Linux kernel plat directory: none
@@ -148,6 +152,15 @@ Avanta family
   Linux kernel mach directory: no code in mainline yet, planned for the future
   Linux kernel plat directory: no code in mainline yet, planned for the future
 
+Storage family
+--------------
+
+  Armada SP:
+	88RC1580
+    Product infos: http://www.marvell.com/storage/armada-sp/
+    Core: Sheeva ARMv7 comatible Quad-core PJ4C
+    (not supported in upstream Linux kernel)
+
 Dove family (application processor)
 -----------------------------------
 
@@ -168,7 +181,7 @@ PXA 2xx/3xx/93x/95x family
   Flavors:
         PXA21x, PXA25x, PXA26x
              Application processor only
-             Core: ARMv5 XScale core
+             Core: ARMv5 XScale1 core
         PXA270, PXA271, PXA272
              Product Brief         : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_pb.pdf
              Design guide          : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_design_guide.pdf
@@ -176,7 +189,7 @@ PXA 2xx/3xx/93x/95x family
              Specification         : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_emts.pdf
              Specification update  : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_spec_update.pdf
              Application processor only
-             Core: ARMv5 XScale core
+             Core: ARMv5 XScale2 core
         PXA300, PXA310, PXA320
              PXA 300 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA300_PB_R4.pdf
              PXA 310 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA310_PB_R4.pdf
@@ -187,10 +200,10 @@ PXA 2xx/3xx/93x/95x family
              Specification Update  : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Spec_Update.zip
              Reference Manual      : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_TavorP_BootROM_Ref_Manual.pdf
              Application processor only
-             Core: ARMv5 XScale core
+             Core: ARMv5 XScale3 core
         PXA930, PXA935
              Application processor with Communication processor
-             Core: ARMv5 XScale core
+             Core: ARMv5 XScale3 core
         PXA955
              Application processor with Communication processor
              Core: ARMv7 compatible Sheeva PJ4 core
@@ -209,7 +222,7 @@ PXA 2xx/3xx/93x/95x family
    Linux kernel mach directory: arch/arm/mach-pxa
    Linux kernel plat directory: arch/arm/plat-pxa
 
-MMP/MMP2 family (communication processor)
+MMP/MMP2/MMP3 family (communication processor)
 -----------------------------------------
 
    Flavors:
@@ -222,16 +235,32 @@ MMP/MMP2 family (communication processor)
              Boot ROM manual      : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_ref_manual.pdf
              App node package     : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_app_note_package.pdf
              Application processor only
-             Core: ARMv5 compatible Marvell PJ1 (Mohawk)
-        PXA910
+             Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
+        PXA910/PXA920
              Homepage             : http://www.marvell.com/communication-processors/pxa910/
              Product Brief        : http://www.marvell.com/communication-processors/pxa910/assets/Marvell_PXA910_Platform-001_PB_final.pdf
              Application processor with Communication processor
-             Core: ARMv5 compatible Marvell PJ1 (Mohawk)
-        MMP2, a.k.a Armada 610
+             Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
+        PXA688, a.k.a. MMP2, a.k.a Armada 610
              Product Brief        : http://www.marvell.com/application-processors/armada-600/assets/armada610_pb.pdf
              Application processor only
-             Core: ARMv7 compatible Sheeva PJ4 core
+             Core: ARMv7 compatible Sheeva PJ4 88sv581x core
+	PXA2128, a.k.a. MMP3 (OLPC XO4, Linux support not upstream)
+	     Product Brief	  : http://www.marvell.com/application-processors/armada/pxa2128/assets/Marvell-ARMADA-PXA2128-SoC-PB.pdf
+	     Application processor only
+	     Core: Dual-core ARMv7 compatible Sheeva PJ4C core
+	PXA960/PXA968/PXA978 (Linux support not upstream)
+	     Application processor with Communication Processor
+	     Core: ARMv7 compatible Sheeva PJ4 core
+	PXA986/PXA988 (Linux support not upstream)
+	     Application processor with Communication Processor
+	     Core: Dual-core ARMv7 compatible Sheeva PJ4B-MP core
+	PXA1088/PXA1920 (Linux support not upstream)
+	     Application processor with Communication Processor
+	     Core: quad-core ARMv7 Cortex-A7
+	PXA1908/PXA1928/PXA1936
+	     Application processor with Communication Processor
+	     Core: multi-core ARMv8 Cortex-A53
 
    Comments:
 
@@ -250,6 +279,10 @@ Berlin family (Multimedia Solutions)
 -------------------------------------
 
   Flavors:
+	88DE3010, Armada 1000 (no Linux support)
+		Core:		Marvell PJ1 (ARMv5TE), Dual-core
+		Product Brief:	http://www.marvell.com.cn/digital-entertainment/assets/armada_1000_pb.pdf
+	88DE3005, Armada 1500-mini
 	88DE3005, Armada 1500 Mini
 		Design name:	BG2CD
 		Core:		ARM Cortex-A9, PL310 L2CC
@@ -260,14 +293,16 @@ Berlin family (Multimedia Solutions)
                 Homepage:       http://www.marvell.com/multimedia-solutions/armada-1500-mini-plus/
 	88DE3100, Armada 1500
 		Design name:	BG2
-		Core:		Marvell PJ4B (ARMv7), Tauros3 L2CC
-		Product Brief:	http://www.marvell.com/multimedia-solutions/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
+		Core:		Marvell PJ4B-MP (ARMv7), Tauros3 L2CC
+		Product Brief:	http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
 	88DE3114, Armada 1500 Pro
 		Design name:	BG2Q
 		Core:		Quad Core ARM Cortex-A9, PL310 L2CC
-	88DE????
+	88DE3214, Armada 1500 Pro 4K
 		Design name:	BG3
 		Core:		ARM Cortex-A15, CA15 integrated L2CC
+	88DE3218, ARMADA 1500 Ultra
+		Core:		ARM Cortex-A53
 
   Homepage: http://www.marvell.com/multimedia-solutions/
   Directory: arch/arm/mach-berlin
@@ -276,6 +311,49 @@ Berlin family (Multimedia Solutions)
    * This line of SoCs is based on Marvell Sheeva or ARM Cortex CPUs
      with Synopsys DesignWare (IRQ, GPIO, Timers, ...) and PXA IP (SDHCI, USB, ETH, ...).
 
+CPU Cores
+---------
+
+The XScale cores were designed by Intel, and shipped by Marvell in the older
+PXA processors. Feroceon is a Marvell designed core that developed in-house,
+and that evolved into Sheeva. The XScale and Feroceon cores were phased out
+over time and replaced with Sheeva cores in later products, which subsequently
+got replaced with licensed ARM Cortex-A cores.
+
+  XScale 1
+	CPUID 0x69052xxx
+	ARMv5, iWMMXt
+  XScale 2
+	CPUID 0x69054xxx
+	ARMv5, iWMMXt
+  XScale 3
+	CPUID 0x69056xxx or 0x69056xxx
+	ARMv5, iWMMXt
+  Feroceon-1850 88fr331 "Mohawk"
+	CPUID 0x5615331x or 0x41xx926x
+	ARMv5TE, single issue
+  Feroceon-2850 88fr531-vd "Jolteon"
+	CPUID 0x5605531x or 0x41xx926x
+	ARMv5TE, VFP, dual-issue
+  Feroceon 88fr571-vd "Jolteon"
+	CPUID 0x5615571x
+	ARMv5TE, VFP, dual-issue
+  Feroceon 88fr131 "Mohawk-D"
+	CPUID 0x5625131x
+	ARMv5TE, single-issue in-order
+  Sheeva PJ1 88sv331 "Mohawk"
+	CPUID 0x561584xx
+	ARMv5, single-issue iWMMXt v2
+  Sheeva PJ4 88sv581x "Flareon"
+	CPUID 0x560f581x
+	ARMv7, idivt, optional iWMMXt v2
+  Sheeva PJ4B 88sv581x
+	CPUID 0x561f581x
+	ARMv7, idivt, optional iWMMXt v2
+  Sheeva PJ4B-MP / PJ4C
+	CPUID 0x562f584x
+	ARMv7, idivt/idiva, LPAE, optional iWMMXt v2 and/or NEON
+
 Long-term plans
 ---------------
 
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Thu Feb 18 08:20:30 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 18 Feb 2016 17:20:30 +0100
Subject: [PATCH v2 6/6] arm64: marvell: add Device Tree files for Armada 7K/8K
In-Reply-To: <1455812430-4656-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455812430-4656-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455812430-4656-7-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adds the base Device Tree files for the Armada 7K and 8K
SoCs, as well as the Armada 8040 DB board.

The Armada 7020, 7040 (7K family) and 8020, 8040 (8K family) are
composed of:

 - An AP806 block that contains the CPU core and a few basic
   peripherals. The AP806 is available in dual core configurations
   (used in 7020 and 8020) and quad core configurations (used in 8020
   and 8040).

 - One or two CP110 blocks that contain all the high-speed interfaces
   (SATA, PCIe, Ethernet, etc.). The 7K family chips have one CP110,
   and the 8K family chips have two CP110, giving them twice the
   number of HW interfaces.

In order to represent this from a Device Tree point of view, this
commit creates the following hierarchy:

 * armada-ap806.dtsi - definitions common to dual/quad ap806
   * armada-ap806-dual.dtsi - description of the two CPUs
     * armada-7020.dtsi - description of the 7020 SoC
     * armada-8020.dtsi - description of the 8020 SoC
   * armada-ap806-quad.dtsi - description of the four CPUs
     * armada-7040.dtsi - description of the 7040 SoC
       * armada-7040-db.dts - description of the 7040 board
     * armada-8040.dtsi - description of the 8040 SoC

The CP110 blocks are not described yet, and will be part of future
patch series.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../bindings/arm/marvell/armada-7k-8k.txt          |  24 +++
 arch/arm64/boot/dts/marvell/Makefile               |   1 +
 arch/arm64/boot/dts/marvell/armada-7020.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-7040-db.dts     |  92 ++++++++
 arch/arm64/boot/dts/marvell/armada-7040.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-8020.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-8040.dtsi       |  54 +++++
 arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi |  71 +++++++
 arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi |  84 ++++++++
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi      | 234 +++++++++++++++++++++
 10 files changed, 722 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
 create mode 100644 arch/arm64/boot/dts/marvell/armada-7020.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-7040-db.dts
 create mode 100644 arch/arm64/boot/dts/marvell/armada-7040.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-8020.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-8040.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
 create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806.dtsi

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
new file mode 100644
index 0000000..df98a9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
@@ -0,0 +1,24 @@
+Marvell Armada 7K/8K Platforms Device Tree Bindings
+---------------------------------------------------
+
+Boards using a SoC of the Marvell Armada 7K or 8K families must carry
+the following root node property:
+
+ - compatible, with one of the following values:
+
+   - "marvell,armada7020", "marvell,armada-ap806-dual", "marvell,armada-ap806"
+      when the SoC being used is the Armada 7020
+
+   - "marvell,armada7040", "marvell,armada-ap806-quad", "marvell,armada-ap806"
+      when the SoC being used is the Armada 7040
+
+   - "marvell,armada8020", "marvell,armada-ap806-dual", "marvell,armada-ap806"
+      when the SoC being used is the Armada 8020
+
+   - "marvell,armada8040", "marvell,armada-ap806-quad", "marvell,armada-ap806"
+      when the SoC being used is the Armada 8040
+
+Example:
+
+compatible = "marvell,armada7040-db", "marvell,armada7040",
+             "marvell,armada-ap806-quad", "marvell,armada-ap806";
diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index 2114af8..308468d 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
 
 # Mvebu SoC Family
 dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-7040-db.dtb
 
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
diff --git a/arch/arm64/boot/dts/marvell/armada-7020.dtsi b/arch/arm64/boot/dts/marvell/armada-7020.dtsi
new file mode 100644
index 0000000..5257575
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-7020.dtsi
@@ -0,0 +1,54 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for the Armada 7020 SoC, made of an AP806 Dual and
+ * one CP110.
+ */
+
+#include "armada-ap806-dual.dtsi"
+
+/ {
+	model = "Marvell Armada 7020";
+	compatible = "marvell,armada7020", "marvell,armada-ap806-dual",
+		     "marvell,armada-ap806";
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
new file mode 100644
index 0000000..064a251
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for Marvell Armada 7040 Development board platform
+ */
+
+#include "armada-7040.dtsi"
+
+/ {
+	model = "Marvell Armada 7040 DB board";
+	compatible = "marvell,armada7040-db", "marvell,armada7040",
+		     "marvell,armada-ap806-quad", "marvell,armada-ap806";
+
+	memory at 00000000 {
+		device_type = "memory";
+		reg = <0x0 0x0 0x0 0x80000000>;
+	};
+
+	ap806 {
+		config-space {
+			spi at 510600 {
+				status = "okay";
+
+				spi-flash at 0 {
+					#address-cells = <1>;
+					#size-cells = <1>;
+					compatible = "n25q128a13";
+					reg = <0>; /* Chip select 0 */
+					spi-max-frequency = <10000000>;
+
+					partition at 0 {
+						label = "U-Boot";
+						reg = <0 0x200000>;
+					};
+					partition at 400000 {
+						label = "Filesystem";
+						reg = <0x200000 0xce0000>;
+					};
+				};
+			};
+
+			i2c at 511000 {
+				status = "okay";
+				clock-frequency = <100000>;
+			};
+
+			serial at 512000 {
+				status = "okay";
+			};
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-7040.dtsi b/arch/arm64/boot/dts/marvell/armada-7040.dtsi
new file mode 100644
index 0000000..7a2de8b
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-7040.dtsi
@@ -0,0 +1,54 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for the Armada 7040 SoC, made of an AP806 Quad and
+ * one CP110.
+ */
+
+#include "armada-ap806-quad.dtsi"
+
+/ {
+	model = "Marvell Armada 7040";
+	compatible = "marvell,armada7040", "marvell,armada-ap806-quad",
+		     "marvell,armada-ap806";
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-8020.dtsi b/arch/arm64/boot/dts/marvell/armada-8020.dtsi
new file mode 100644
index 0000000..73d69d9
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-8020.dtsi
@@ -0,0 +1,54 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for the Armada 8020 SoC, made of an AP806 Dual and
+ * two CP110.
+ */
+
+#include "armada-ap806-dual.dtsi"
+
+/ {
+	model = "Marvell Armada 8020";
+	compatible = "marvell,armada8020", "marvell,armada-ap806-dual",
+		     "marvell,armada-ap806";
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-8040.dtsi b/arch/arm64/boot/dts/marvell/armada-8040.dtsi
new file mode 100644
index 0000000..a1406a4
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-8040.dtsi
@@ -0,0 +1,54 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for the Armada 8040 SoC, made of an AP806 Quad and
+ * two CP110.
+ */
+
+#include "armada-ap806-quad.dtsi"
+
+/ {
+	model = "Marvell Armada 8040";
+	compatible = "marvell,armada8040", "marvell,armada-ap806-quad",
+		     "marvell,armada-ap806";
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi
new file mode 100644
index 0000000..f25c5c1
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi
@@ -0,0 +1,71 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for Marvell Armada AP806.
+ */
+
+#include "armada-ap806.dtsi"
+
+/ {
+	model = "Marvell Armada AP806 Dual";
+	compatible = "marvell,armada-ap806-dual", "marvell,armada-ap806";
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 000 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x000>;
+			enable-method = "psci";
+		};
+		cpu at 001 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x001>;
+			enable-method = "psci";
+		};
+	};
+};
+
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
new file mode 100644
index 0000000..baa7d9a
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
@@ -0,0 +1,84 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for Marvell Armada AP806.
+ */
+
+#include "armada-ap806.dtsi"
+
+/ {
+	model = "Marvell Armada AP806 Quad";
+	compatible = "marvell,armada-ap806-quad", "marvell,armada-ap806";
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 000 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x000>;
+			enable-method = "psci";
+		};
+		cpu at 001 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x001>;
+			enable-method = "psci";
+		};
+		cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x100>;
+			enable-method = "psci";
+		};
+		cpu at 101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x101>;
+			enable-method = "psci";
+		};
+	};
+
+};
+
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
new file mode 100644
index 0000000..63f25ce
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
@@ -0,0 +1,234 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/*
+ * Device Tree file for Marvell Armada AP806.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/dts-v1/;
+
+/ {
+	model = "Marvell Armada AP806";
+	compatible = "marvell,armada-ap806";
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+
+	ap806 {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		compatible = "simple-bus";
+		interrupt-parent = <&gic>;
+		ranges;
+
+		config-space {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "simple-bus";
+			ranges = <0x0 0x0 0xf0000000 0x1000000>;
+
+			gic: interrupt-controller at 210000 {
+				compatible = "arm,gic-400";
+				#interrupt-cells = <3>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges;
+				interrupt-controller;
+				interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+				reg = <0x210000 0x10000>,
+				      <0x220000 0x20000>,
+				      <0x240000 0x20000>,
+				      <0x260000 0x20000>;
+
+				gic_v2m0: v2m at 280000 {
+					compatible = "arm,gic-v2m-frame";
+					msi-controller;
+					reg = <0x280000 0x1000>;
+					arm,msi-base-spi = <160>;
+					arm,msi-num-spis = <32>;
+				};
+				gic_v2m1: v2m at 290000 {
+					compatible = "arm,gic-v2m-frame";
+					msi-controller;
+					reg = <0x290000 0x1000>;
+					arm,msi-base-spi = <192>;
+					arm,msi-num-spis = <32>;
+				};
+				gic_v2m2: v2m at 2a0000 {
+					compatible = "arm,gic-v2m-frame";
+					msi-controller;
+					reg = <0x2a0000 0x1000>;
+					arm,msi-base-spi = <224>;
+					arm,msi-num-spis = <32>;
+				};
+				gic_v2m3: v2m at 2b0000 {
+					compatible = "arm,gic-v2m-frame";
+					msi-controller;
+					reg = <0x2b0000 0x1000>;
+					arm,msi-base-spi = <256>;
+					arm,msi-num-spis = <32>;
+				};
+			};
+
+			timer {
+				compatible = "arm,armv8-timer";
+				interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_EDGE_RISING)>,
+					     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_EDGE_RISING)>,
+					     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_EDGE_RISING)>,
+					     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_EDGE_RISING)>;
+			};
+
+			odmi: odmi at 300000 {
+				compatible = "marvell,odmi-controller";
+				interrupt-controller;
+				msi-controller;
+				marvell,odmi-frames = <4>;
+				reg = <0x300000 0x4000>,
+				      <0x304000 0x4000>,
+				      <0x308000 0x4000>,
+				      <0x30C000 0x4000>;
+				marvell,spi-base = <128>, <136>, <144>, <152>;
+			};
+
+			spi0: spi at 510600 {
+				compatible = "marvell,armada-380-spi";
+				reg = <0x510600 0x50>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				cell-index = <0>;
+				interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&ringclk 2>;
+				status = "disabled";
+			};
+
+			i2c0: i2c at 511000 {
+				compatible = "marvell,mv64xxx-i2c";
+				reg = <0x511000 0x20>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+				timeout-ms = <1000>;
+				clocks = <&ringclk 2>;
+				status = "disabled";
+			};
+
+			serial at 512000 {
+				compatible = "snps,dw-apb-uart";
+				reg = <0x512000 0x100>;
+				reg-shift = <2>;
+				interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+				reg-io-width = <1>;
+				clocks = <&ringclk 2>;
+				status = "disabled";
+			};
+
+			serial at 512100 {
+				compatible = "snps,dw-apb-uart";
+				reg = <0x512100 0x100>;
+				reg-shift = <2>;
+				interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+				reg-io-width = <1>;
+				clocks = <&ringclk 2>;
+				status = "disabled";
+
+			};
+
+			coreclk: clk at 0x6F8204 {
+				compatible = "marvell,armada-ap806-core-clock";
+				reg = <0x6F8204 0x04>;
+				#clock-cells = <1>;
+				clock-output-names = "ddr", "ring", "cpu";
+			};
+
+			ringclk: clk at 0x6F8250 {
+				compatible = "marvell,armada-ap806-ring-clock";
+				reg = <0x6F8250 0x04>;
+				#clock-cells = <1>;
+				clock-output-names = "ring-0", "ring-2",
+						     "ring-3", "ring-4",
+						     "ring-5";
+				clocks = <&coreclk 1>;
+			};
+
+			xor0 at 400000 {
+				compatible = "marvell,mv-xor-v2";
+				reg = <0x400000 0x1000>,
+				      <0x410000 0x1000>;
+				msi-parent = <&gic_v2m0>;
+				dma-coherent;
+			};
+
+			xor1 at 420000 {
+				compatible = "marvell,mv-xor-v2";
+				reg = <0x420000 0x1000>,
+				      <0x430000 0x1000>;
+				msi-parent = <&gic_v2m0>;
+				dma-coherent;
+			};
+
+			xor2 at 440000 {
+				compatible = "marvell,mv-xor-v2";
+				reg = <0x440000 0x1000>,
+				      <0x450000 0x1000>;
+				msi-parent = <&gic_v2m0>;
+				dma-coherent;
+			};
+
+			xor3 at 460000 {
+				compatible = "marvell,mv-xor-v2";
+				reg = <0x460000 0x1000>,
+				      <0x470000 0x1000>;
+				msi-parent = <&gic_v2m0>;
+				dma-coherent;
+			};
+		};
+	};
+
+};
+
-- 
2.6.4



From will.deacon at arm.com  Thu Feb 18 08:21:45 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 18 Feb 2016 16:21:45 +0000
Subject: RFC: extend IOMMU attributes
In-Reply-To: <HE1PR04MB1641F22E38710B68F4ED891F8DAF0@HE1PR04MB1641.eurprd04.prod.outlook.com>
References: <HE1PR04MB1641F22E38710B68F4ED891F8DAF0@HE1PR04MB1641.eurprd04.prod.outlook.com>
Message-ID: <20160218162145.GB16883@arm.com>

Hi Stuart,

On Thu, Feb 18, 2016 at 04:16:26PM +0000, Stuart Yoder wrote:
> We are implementing support for some specialized NXP SoC network
> devices and have the desire to extend the mapping attributes beyond
> those currently in iommu.h. (I see there is a recent proposal to
> add an IOMMU_MMIO flag)
> 
> What we have right now in Linux is a least-common-denominator set of
> attributes, while for the ARM SMMU there is a much richer set of
> attributes that seem useful to support. Specifically, we have one
> SoC device we're dealing with right now that is the target of DMA
> that functionally requires a "cacheable, non-shareable" attribute
> in its SMMU mapping.
> 
> In addition, there are many other attributes such as r/w allocate
> hints, transient hints, write-back/write-thru, etc in the SMMU.
> 
> We wanted to see what your thinking is with respect to the
> direction the Linux IOMMU layer will head over the longer term with
> respect to attributes.
> 
> Is there anything problematic with continuing to grow the
> attributes in iommu.h?...e.g.:
> 
>  #define IOMMU_READ            (1 << 0)
>  #define IOMMU_WRITE           (1 << 1)
> -#define IOMMU_CACHE           (1 << 2) /* DMA cache coherency */
> +#define IOMMU_CACHE_COHERENT  (1 << 2) /* cacheable and coherent */
>  #define IOMMU_NOEXEC          (1 << 3)
>  #define IOMMU_MMIO            (1 << 4) /* e.g. things like MSI doorbells */
> +#define IOMMU_CACHEABLE       (1 << 5) /* cacheable, not coherent */

What does that even mean?

> +#define IOMMU_CACHE_ALLOCATE  (1 << 6) /* hint to allocate in the cache */
> 
> Also, are we willing to let somewhat architecture specific flags
> onto that list?  For, example the ARM 'transient' hint.

If we're going to support fine-grained attribute control, I think it needs
to be done in a page-table specific manner. That is, io-pgtable-arm could
provide those attribute controls which feature in the ARMv8 architecture...

...but that brings me onto my next question: Who on Earth is actually
going to provide these attributes to the IOMMU API?

There seems to be a missing piece.

Will


From thomas.petazzoni at free-electrons.com  Thu Feb 18 08:20:26 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 18 Feb 2016 17:20:26 +0100
Subject: [PATCH v2 2/6] Documentation: arm: improve Armada 37xx description
In-Reply-To: <1455812430-4656-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455812430-4656-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455812430-4656-3-git-send-email-thomas.petazzoni@free-electrons.com>

In preparation to the introduction of other SoCs in the ARMv8 Armada
EBU family, this commit tweaks the existing description of Armada 37xx
by making the core, homepage and other informations be visible "under"
the Armada 37xx item. Indeed, the new SoCs will not share the same
core or homepage.

In addition, a link to the Product Brief is added.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 Documentation/arm/Marvell/README | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index 981164f..a78453b 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -128,12 +128,11 @@ EBU Armada family ARMv8
   Armada 3710/3720 Flavors:
 	88F3710
 	88F3720
+	Core: ARM Cortex A53 (ARMv8)
 
-  Core: ARM Cortex A53 (ARMv8)
-
-  Homepage     : http://www.marvell.com/embedded-processors/armada-3700/
-
-  Device tree descritpion located in arch/arm64/boot/dts/marvell/armada-37*
+	Homepage: http://www.marvell.com/embedded-processors/armada-3700/
+	Product Brief: http://www.marvell.com/embedded-processors/assets/PB-88F3700-FNL.pdf
+	Device tree files: arch/arm64/boot/dts/marvell/armada-37*
 
 Avanta family
 -------------
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Thu Feb 18 08:20:29 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 18 Feb 2016 17:20:29 +0100
Subject: [PATCH v2 5/6] arm64: update ARCH_MVEBU for Marvell Armada 7K/8K
 support
In-Reply-To: <1455812430-4656-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455812430-4656-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1455812430-4656-6-git-send-email-thomas.petazzoni@free-electrons.com>

This commit updates the ARCH_MVEBU Kconfig option introduced for
Armada 3700 to also be used for the Armada 7K and 8K platforms, by:

 - Selecting the appropriate clock and irqchip drivers
 - Updating the help text to mention Armada 7K and 8K

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm64/Kconfig.platforms | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 85bec42..c9a184b 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -50,9 +50,14 @@ config ARCH_MEDIATEK
 
 config ARCH_MVEBU
 	bool "Marvell EBU SoC Family"
-	help
-	  This enables support for Marvell EBU family such as the
-	  Armada 3700 SoC family.
+	select ARMADA_AP806_CORE_CLK
+	select ARMADA_AP806_RING_CLK
+	select MVEBU_ODMI
+	help
+	  This enables support for Marvell EBU familly, including:
+	   - Armada 3700 SoC Family
+	   - Armada 7K SoC Family
+	   - Armada 8K SoC Family
 
 config ARCH_QCOM
 	bool "Qualcomm Platforms"
-- 
2.6.4



From nicolas.pitre at linaro.org  Thu Feb 18 08:21:45 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Feb 2016 11:21:45 -0500 (EST)
Subject: [PATCH 9/9] ARM: fix kprobe test with CONFIG_CPU_32v3
In-Reply-To: <1455804123-2526139-10-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-10-git-send-email-arnd@arndb.de>
Message-ID: <alpine.LFD.2.20.1602181121170.13632@knanqh.ubzr>

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

> ARMv3 did not have 16-bit load/store or 32-bit multiply instructions,
> so building the kprobe test code fails with lots of warnings about
> these:
> 
> /tmp/ccI4SKHx.s:19585: Error: selected processor does not support ARM mode `umull r0,r1,r2,r3'
> /tmp/ccI4SKHx.s:19617: Error: selected processor does not support ARM mode `umullls r7,r8,r9,r10'
> /tmp/ccI4SKHx.s:19645: Error: selected processor does not support ARM mode `umull lr,r12,r11,r13'
> /tmp/ccI4SKHx.s:19727: Error: selected processor does not support ARM mode `umulls r0,r1,r2,r3'
> ...
> /tmp/ccI4SKHx.s:21273: Error: selected processor does not support ARM mode `strh r0,[r1,-r2]'
> /tmp/ccI4SKHx.s:21309: Error: selected processor does not support ARM mode `streqh r14,[r11,r12]'
> /tmp/ccI4SKHx.s:21333: Error: selected processor does not support ARM mode `streqh r14,[r13,r12]'
> 
> This puts all the affected instructions inside an #ifdef section,
> like we do for the other architecture levels.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Acked-by: Nicolas Pitre <nico at linaro.org>

> ---
>  arch/arm/probes/kprobes/test-arm.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/probes/kprobes/test-arm.c b/arch/arm/probes/kprobes/test-arm.c
> index 8866aedfdea2..4e8511f0582d 100644
> --- a/arch/arm/probes/kprobes/test-arm.c
> +++ b/arch/arm/probes/kprobes/test-arm.c
> @@ -391,6 +391,7 @@ void kprobe_arm_test_cases(void)
>  	TEST_UNSUPPORTED(__inst_arm(0xe0700090) " @ undef")
>  	TEST_UNSUPPORTED(__inst_arm(0xe07fff9f) " @ undef")
>  
> +#if __LINUX_ARM_ARCH__ >= 4
>  	TEST_RR(  "umull	r0, r1, r",2, VAL1,", r",3, VAL2,"")
>  	TEST_RR(  "umullls	r7, r8, r",9, VAL2,", r",10, VAL1,"")
>  	TEST_R(   "umull	lr, r12, r",11,VAL3,", r13")
> @@ -436,6 +437,7 @@ void kprobe_arm_test_cases(void)
>  	TEST_UNSUPPORTED(__inst_arm(0xe0f0f392) " @ smlals r0, pc, r2, r3")
>  	TEST_UNSUPPORTED(__inst_arm(0xe0f0139f) " @ smlals r0, r1, pc, r3")
>  	TEST_UNSUPPORTED(__inst_arm(0xe0f01f92) " @ smlals r0, r1, r2, pc")
> +#endif
>  
>  	TEST_GROUP("Synchronization primitives")
>  
> @@ -478,7 +480,7 @@ void kprobe_arm_test_cases(void)
>  	TEST_UNSUPPORTED("ldrexh	r2, [sp]")
>  #endif
>  	TEST_GROUP("Extra load/store instructions")
> -
> +#if __LINUX_ARM_ARCH__ >= 4
>  	TEST_RPR(  "strh	r",0, VAL1,", [r",1, 48,", -r",2, 24,"]")
>  	TEST_RPR(  "streqh	r",14,VAL2,", [r",11,0, ", r",12, 48,"]")
>  	TEST_UNSUPPORTED(  "streqh	r14, [r13, r12]")
> @@ -560,6 +562,7 @@ void kprobe_arm_test_cases(void)
>  	TEST(      "ldrsh	r0, [pc, #0]")
>  	TEST_UNSUPPORTED(__inst_arm(0xe1ffc3f0) "	@ ldrsh r12, [pc, #48]!")
>  	TEST_UNSUPPORTED(__inst_arm(0xe0d9f3f0) "	@ ldrsh pc, [r9], #48")
> +#endif
>  
>  #if __LINUX_ARM_ARCH__ >= 7
>  	TEST_UNSUPPORTED("strht	r1, [r2], r3")
> -- 
> 2.7.0
> 
> 


From arnd at arndb.de  Thu Feb 18 08:26:56 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 17:26:56 +0100
Subject: [PATCH v2] ARM: atags_to_fdt: don't warn about stack size
In-Reply-To: <alpine.LFD.2.20.1602181112310.13632@knanqh.ubzr>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-6-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602181112310.13632@knanqh.ubzr>
Message-ID: <7301172.5fH67MHlU9@wuerfel>

The merge_fdt_bootargs() function by definition consumes more than 1024
bytes of stack because it has a 1024 byte command line on the stack,
meaning that we always get a warning when building this file:

arch/arm/boot/compressed/atags_to_fdt.c: In function 'merge_fdt_bootargs':
arch/arm/boot/compressed/atags_to_fdt.c:98:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]

However, as this is the decompressor and we know that it has a very shallow
call chain, and we do not actually risk overflowing the kernel stack
at runtime here.

This just shuts up the warning by slightly increasing the limit for this
file.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
On Thursday 18 February 2016 11:13:52 Nicolas Pitre wrote:
> What about setting the warning to 2048 instead?

Sure, actually 1280 is more than enough I think.

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 7a6a58ef8aaf..2cc63038d6c8 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -85,6 +85,8 @@ $(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: $(srctree)/scripts/dtc/
 $(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \
 	$(addprefix $(obj)/,$(libfdt_hdrs))
 
+CFLAGS_atags_to_fdt.o += -Wframe-larger-than=1280
+
 ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
 OBJS	+= $(libfdt_objs) atags_to_fdt.o
 endif



From arnd at arndb.de  Thu Feb 18 08:27:48 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 17:27:48 +0100
Subject: [PATCH v2] irqchip: irq-mvebu-odmi: new driver for platform MSI
 on Marvell 7K/8K
In-Reply-To: <20160218171623.664dabd1@free-electrons.com>
References: <1455811134-3679-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <3923904.c50oLNXXZ1@wuerfel> <20160218171623.664dabd1@free-electrons.com>
Message-ID: <3474575.KNRGuJK4d6@wuerfel>

On Thursday 18 February 2016 17:16:23 Thomas Petazzoni wrote:
> 
> On Thu, 18 Feb 2016 17:08:05 +0100, Arnd Bergmann wrote:
> > On Thursday 18 February 2016 16:58:54 Thomas Petazzoni wrote:
> > > +- marvell,spi-base     : List of GIC base SPI interrupts, one for each
> > > +                         ODMI frame. Those SPI interrupts are 0-based,
> > > +                         i.e marvell,spi-base = <128> will use SPI #96.
> > > +                         See Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
> > > +                         for details about the GIC Device Tree binding.
> > > 
> > 
> > Why are these not just in an 'interrupts' property as we do for other
> > nested irqchips?
> 
> I modeled this after the GICv2m bindings. I think the reason is that if
> we were to use the interrupts property, we should be listing *all*
> interrupts of the parent interrupt controller we are using. Which would
> be quite painful when your ODMI interrupt controller uses 32 interrupts
> of the parent controller (I think for the GICv2m, it's even more).
> 
> I.e, we currently say:
> 
>         marvell,spi-base = <128>, <136>, <144>, <152>
> 
> but in fact we are using 128, 129, 130, 131, 132, 133, 134, 135, 136,
> 137, etc. until 159.
> 
> If you think
> 
>         interrupts = <128>, <136>, <144>, <152>
> 
> is still correct, then why not. But I believe this might be confusing,
> as people will think that we are only using interrupts 128, 136, 144
> and 152, and not 129, 133, 147 or 158.
> 

Ok, got it. Your current version seems fine then.

	Arnd


From jonathanh at nvidia.com  Thu Feb 18 08:31:22 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Thu, 18 Feb 2016 16:31:22 +0000
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <CAPDyKFoPrFoMOFxC37zXX4L3VdLKknaw_LUTw7ycr9mfa_=7_A@mail.gmail.com>
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
 <7hh9hdzflv.fsf@baylibre.com> <56C1B62B.5060708@nvidia.com>
 <CAPDyKFoPrFoMOFxC37zXX4L3VdLKknaw_LUTw7ycr9mfa_=7_A@mail.gmail.com>
Message-ID: <56C5F1DA.2060705@nvidia.com>


On 18/02/16 16:00, Ulf Hansson wrote:
> [...]
> 
>>>
>>> What about the pm_clk_* API which was built for tracking clocks
>>> associated with devices for runtime PM.
>>>
>>> IOW, you could pm_clk_add(pg->pmc->dev, pg->clks[i]) and then your
>>> _enable_clocks() would become pm_clk_suspend() an dyour
>>> _disable_clocks() would become pm_clk_resume().
>>
>> Very interesting, I was not aware of this.
>>
>>> I might not be following the mapping between PMC and PGs though so not
>>> sure pg->pmc->dev is the right struct device, but you get the idea.
>>
>> Yes, so this will not work here as-is, because the pmc->dev is common to
>> all pm-domains (it is the device that creates all the pm-domains). So to
>> make this work, I would need to create a device for each pm-domain and
>> add the clocks to that.
>>
>> I see that this works very well for normal drivers, but it does not feel
>> so natural for pm-domains where we don't have a device struct today. By
>> the way, the rockchip pm-domains implementation is very much in the same
>> boat as tegra, where there are multiple clocks per pm-domain and it is
>> handled by a simple list. So I am not sure if you think that we should
>> be turning all pm-domains registered by pm_genpd_init() into a device
>> and then we can make use of these pm_clk_XXXX() APIs?
>>
>> I have implemented the generic clk APIs that Ulf and I discussed for
>> handling multiple clocks, but if we think that this is a better way,
>> then I will hold off for now.
> 
> I think Kevin has a point that we already have PM clocks to build upon.
> Could we perhaps try to extend that API instead to suite this needs as well?

We certainly could and I am not against it, however, it means that we
need to create a device structure for each pm-domain. If you and Kevin
are ok with me adding this to pm_genpd_init(), then I can give it a try.

> I do realize that it will make this patchset more complicated. As I
> stated earlier, this was just an idea I had, so to be clear I won't
> hold back an ack for this patchset, if you decide to deal with this in
> separate "improvement" step.

Thanks
Jon



From ilya at compulab.co.il  Thu Feb 18 08:33:13 2016
From: ilya at compulab.co.il (Ilya Ledvich)
Date: Thu, 18 Feb 2016 18:33:13 +0200
Subject: iMX7d cpu1 issue
In-Reply-To: <1F497949-8B77-4376-A109-A2737CFBD9C7@nxp.com>
References: <56C2D63F.1030408@compulab.co.il> <20160218140913.GY6756@tiger>
 <1F497949-8B77-4376-A109-A2737CFBD9C7@nxp.com>
Message-ID: <56C5F249.6030708@compulab.co.il>

Hi guys,
Your help is much appreciated.
Please see below the code piece enabling the CPU1:
...
	if (cpu_is_imx7d()) {
		/* enable core */
		if (enable)
			imx_gpcv2_set_core1_pdn_pup_by_software(false);
		mask = 1 << (BP_SRC_A7RCR1_A7_CORE1_ENABLE + cpu - 1);
		val = readl_relaxed(src_base + SRC_A7RCR1);
		val = enable ? val | mask : val & ~mask;
		writel_relaxed(val, src_base + SRC_A7RCR1);
	}
...

Kind rgeards,
Ilya.

On 02/18/2016 05:15 PM, Yongcai Huang wrote:
> Hi, llya
>          Can you paste the code piece of enabling CPU1 in src.c? I remembered I met similar issue during bring up SMP on MX7D, but it was 1 year ago, I did NOT remembered the detail now. I suspect something wrong in SRC register setting.
>
>  From Anson's iPhone 6
>
>
>> ? 2016?2?18??22:10?Shawn Guo <shawnguo at kernel.org> ???
>>
>>> On Tue, Feb 16, 2016 at 09:56:47AM +0200, Ilya Ledvich wrote:
>>> Hi Shawn,
>>> I'm working on Compulab CL-SOM-IMX7 device (http://www.compulab.co.il/products/computer-on-modules/cl-som-imx7-freescale-i-mx-7-system-on-module)
>>> based on Freescale iMX7d CPU.
>>> I use the Freescale latest BSP imx_3.14.52_1.1.0_ga  and the Linux
>>> mainline v4.4-rc6 as a reference.
>>> I observe an issue with bringing up the second CPU core. Briefly,
>>> the kernel can successfully boot only when CPU1 fails to come
>>> online.
>>> In this case the boot log shows the following messages:
>>> ...
>>> CPU1: failed to come online
>>> Brought up 1 CPUs
>>> SMP: Total of 1 processors activated (6.00 BogoMIPS).
>>> ...
>>>
>>> Otherwise, the device tries to start kernel several times until the
>>> boot process eventually crashes. Please see attached logs for more
>>> details.
>>> This never happens on mainline Linus kernel, because it never tries
>>> to bring up CPU1.
>>> Unfortunately, we cannot verify this behavior on reference board
>>> cause we have no one.
>>> Have you ever seen such behavior? Could you please advice something?
>>
>> I never played i.MX7D support on any real hardware.  I copied a couple
>> Freescale/NXP people here.  Let's see if you can get some help from
>> them.
>>
>> Shawn
>>
>>> Starting kernel ...
>>>
>>> Uncompressing Linux... done, booting the kernel.
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
>>> Kernel command line: console=ttymxc0,115200 earlyprintk=ttymxc0,115200 root=/dev/nfs ip=dhcp nfsroot=192.168.11.24:/home/ilya/work/rootfs/sid-minbase,v3,tcp rw rootwait
>>> PID hash table entries: 4096 (order: 2, 16384 bytes)
>>> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
>>> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
>>> Memory: 700996K/1048576K available (6617K kernel code, 353K rwdata, 2280K rodata, 384K init, 421K bss, 347580K reserved, 0K highmem)
>>> Virtual kernel memory layout:
>>>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>>>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>>>     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
>>>     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>>>     pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)
>>>     modules : 0x7f000000 - 0x7fe00000   (  14 MB)
>>>       .text : 0x80008000 - 0x808b8880   (8899 kB)
>>>       .init : 0x808b9000 - 0x80919080   ( 385 kB)
>>>       .data : 0x8091a000 - 0x80972680   ( 354 kB)
>>>        .bss : 0x8097268c - 0x809dbc00   ( 422 kB)
>>> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
>>> Preemptible hierarchical RCU implementation.
>>>         RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
>>> RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
>>> NR_IRQS:16 nr_irqs:16 16
>>> Switching to timer-based delay loop
>>> sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655765682ns
>>> Architected cp15 timer(s) running at 8.00MHz (phys).
>>> sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2147483648000ns
>>> Ignoring duplicate/late registration of read_current_timer delay
>>> Console: colour dummy device 80x30
>>> Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=30000)
>>> pid_max: default: 32768 minimum: 301
>>> Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
>>> Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
>>> CPU: Testing write buffer coherency: ok
>>> /cpus/cpu at 0 missing clock-frequency property
>>> /cpus/cpu at 1 missing clock-frequency property
>>> CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
>>> Setting up static identity map for 0x80647850 - 0x806478a8
>>> Switching to timer-based delay loop
>>> Calibrating delay loop (skipped) already calibrated this CPU6.00 BogoMIPS (lpj=30000)
>>> sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655765682ns
>>> Architected cp15 timer(s) running at 8.00MHz (phys).
>>> 2147483648000ns
>>> Current pid: 1 comm: swapper/0 / Idle pid: 0 comm: swapper/0
>>> Ignoring duplicate/late registra
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> CPU1: failed to come online
>>> Brought up 1 CPUs
>>> SMP: Total of 1 processors activated (6.00 BogoMIPS).
>>> CPU: All CPU(s) started in SVC mode.
>>> devtmpfs: initialized
>>> VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
>>> pinctrl core: initialized pinctrl subsystem
>>> regulator-dummy: no parameters
>>> NET: Registered protocol family 16
>>> DMA: preallocated 256 KiB pool for atomic coherent allocations
>>> cpuidle: using governor ladder
>>> cpuidle: using governor menu
>>> Use WDOG1 as reset source
>>> syscon 30340000.iomuxc-gpr: regmap [mem 0x30340000-0x3034ffff] registered
>>> syscon 30350000.ocotp-ctrl: regmap [mem 0x30350000-0x3035ffff] registered
>>> syscon 30360000.anatop: regmap [mem 0x30360000-0x3036ffff] registered
>>> vdd1p0d: 800 <--> 1200 mV at 1000 mV
>>> vdd1p2: 1100 <--> 1300 mV
>>> syscon 30390000.src: regmap [mem 0x30390000-0x3039ffff] registered
>>> DDR type is DDR3!
>>> failed to find ocotp node
>>> failed to find ocotp node
>>> hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
>>> hw-breakpoint: maximum watchpoint size is 8 bytes.
>>> imx7d-pinctrl 302c0000.iomuxc-lpsr: initialized IMX pinctrl driver
>>> imx7d-pinctrl 30330000.iomuxc: initialized IMX pinctrl driver
>>> MU is ready for cross core communication!
>>> bio: create slab <bio-0> at 0
>>> mxs-dma 33000000.dma-apbh: initialized
>>> usb_otg1_vbus: 5000 mV
>>> fec1_phy_nreset: 3300 mV
>>> platform regulator.15: Driver reg-fixed-voltage requests probe deferral
>>> tsc2046-reg: 3300 mV
>>> platform regulator.17: Driver reg-fixed-voltage requests probe deferral
>>> platform lcd_nstby_3v3.18: Driver reg-fixed-voltage requests probe deferral
>>> SCSI subsystem initialized
>>> usbcore: registered new interface driver usbfs
>>> usbcore: registered new interface driver hub
>>> usbcore: registered new device driver usb
>>> usbphy_nop1.10 supply vcc not found, using dummy regulator
>>> usbphy_nop2.11 supply vcc not found, using dummy regulator
>>> i2c i2c-1: IMX I2C adapter registered
>>> i2c i2c-3: IMX I2C adapter registered
>>> Linux video capture interface: v2.00
>>> pps_core: LinuxPPS API ver. 1 registered
>>> pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti at linux.it>
>>> PTP clock support registered
>>> MIPI CSI2 driver module loaded
>>> Advanced Linux Sound Architecture Driver Initialized.
>>> Switched to clocksource arch_sys_counter
>>> cfg80211: Calling CRDA to update world regulatory domain
>>> NET: Registered protocol family 2
>>> TCP established hash table entries: 8192 (order: 3, 32768 bytes)
>>> TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
>>> TCP: Hash tables configured (established 8192 bind 8192)
>>> TCP: reno registered
>>> UDP hash table entries: 512 (order: 2, 16384 bytes)
>>> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
>>> NET: Registered protocol family 1
>>> RPC: Registered named UNIX socket transport module.
>>> RPC: Registered udp transport module.
>>> RPC: Registered tcp transport module.
>>> RPC: Registered tcp NFSv4.1 backchannel transport module.
>>> imx rpmsg driver is registered.
>>> Bus freq driver module loaded
>>> futex hash table entries: 512 (order: 3, 32768 bytes)
>>> VFS: Disk quotas dquot_6.5.2
>>> Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
>>> NFS: Registering the id_resolver key type
>>> Key type id_resolver registered
>>> Key type id_legacy registered
>>> jffs2: version 2.2. (NAND) ???? 2001-2006 Red Hat, Inc.
>>> fuse init (API version 7.22)
>>> msgmni has been set to 2009
>>> io scheduler noop registered
>>> io scheduler deadline registered
>>> io scheduler cfq registered (default)
>>> backlight.20 supply power not found, using dummy regulator
>>> MIPI DSI driver module loaded
>>> 30730000.lcdif supply lcd not found, using dummy regulator
>>> mxsfb 30730000.lcdif: failed to find mxc display driver
>>> Console: switching to colour frame buffer device 100x30
>>> mxsfb 30730000.lcdif: initialized
>>> imx-sdma 30bd0000.sdma: no event needs to be remapped
>>> imx-sdma 30bd0000.sdma: loaded firmware 4.1
>>> imx-sdma 30bd0000.sdma: initialized
>>> pfuze100-regulator 1-0008: Full layer: 1, Metal layer: 1
>>> pfuze100-regulator 1-0008: FAB: 0, FIN: 0
>>> pfuze100-regulator 1-0008: pfuze3000 found.
>>> SW1A: 700 <--> 3300 mV at 1100 mV
>>> SW1B: 700 <--> 1475 mV at 1000 mV
>>> SW2: 1500 <--> 1850 mV at 1800 mV
>>> SW3: 900 <--> 1650 mV at 1350 mV
>>> SWBST: 5000 <--> 5150 mV at 5000 mV
>>> VSNVS: 1000 <--> 3000 mV at 3000 mV
>>> VREFDDR: 750 mV
>>> VLDO1: 1800 <--> 3300 mV at 1800 mV
>>> VLDO2: 800 <--> 1550 mV at 1500 mV
>>> VCCSD: 2850 <--> 3300 mV at 3300 mV
>>> V33: 2850 <--> 3300 mV at 3300 mV
>>> VLDO3: 1800 <--> 3300 mV at 3300 mV
>>> VLDO4: 1800 <--> 3300 mV at 3300 mV
>>> Serial: IMX driver
>>> 30860000.serial: ttymxc0 at MMIO 0x30860000 (irq = 58, base_baud = 1500000) is a IMX
>>> console [ttymxc0] enabled
>>> bootconsole [earlycon0] disabled
>>> serial: Freescale lpuart driver
>>> imx sema4 driver is registered.
>>> [drm] Initialized drm 1.1.0 20060810
>>> [drm] Initialized vivante 1.0.0 20120216 on minor 0
>>> brd: module loaded
>>> loop: module loaded
>>> at24 1-0050: 1024 byte 24c08 EEPROM, writable, 16 bytes/write
>>> m25p80 spi0.1: m25px16 (2048 Kbytes)
>>> 3 ofpart partitions found on MTD device spi0.1
>>> Creating 3 MTD partitions on "spi0.1":
>>> 0x000000000000-0x0000000c0000 : "uboot"
>>> 0x0000000c0000-0x000000100000 : "uboot environment"
>>> 0x000000100000-0x000000200000 : "splash"
>>> spi_imx 30820000.ecspi: probed
>>> 30be0000.ethernet supply phy not found, using dummy regulator
>>> pps pps0: new PPS source ptp0
>>> libphy: fec_enet_mii_bus: probed
>>> fec 30be0000.ethernet eth0: registered PHC device 0
>>> 30bf0000.ethernet supply phy not found, using dummy regulator
>>> pps pps1: new PPS source ptp1
>>> fec 30bf0000.ethernet (unregistered net_device): Invalid MAC address: 00:00:00:00:00:00
>>> fec 30bf0000.ethernet (unregistered net_device): Using random MAC address: c2:a3:b7:db:4d:b0
>>> fec 30bf0000.ethernet eth1: registered PHC device 1
>>> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
>>> ehci-mxc: Freescale On-Chip EHCI Host driver
>>> usbcore: registered new interface driver usb-storage
>>> 30b10200.usbmisc supply vbus-wakeup not found, using dummy regulator
>>> 30b20200.usbmisc supply vbus-wakeup not found, using dummy regulator
>>> 30b30200.usbmisc supply vbus-wakeup not found, using dummy regulator
>>> 30b20000.usb supply vbus not found, using dummy regulator
>>> ci_hdrc ci_hdrc.1: EHCI Host Controller
>>> ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 1
>>> ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
>>> hub 1-0:1.0: USB hub found
>>> hub 1-0:1.0: 1 port detected
>>> imx_usb 30b30000.usb: Can't register ci_hdrc platform device, err=-517
>>> platform 30b30000.usb: Driver imx_usb requests probe deferral
>>> mousedev: PS/2 mouse device common for all mice
>>> input: 30370000.snvs-pwrkey as /devices/soc.3/30000000.aips-bus/30370000.snvs-pwrkey/input/input0
>>> snvs_pwrkey 30370000.snvs-pwrkey: i.MX snvs powerkey probed
>>> rtc-em3027 1-0056: rtc core: registered rtc-em3027 as rtc0
>>> snvs_rtc 30370034.snvs-rtc-lp: rtc core: registered 30370034.snvs-rtc-l as rtc1
>>> i2c /dev entries driver
>>> IR NEC protocol handler initialized
>>> IR RC5(x) protocol handler initialized
>>> IR RC6 protocol handler initialized
>>> IR JVC protocol handler initialized
>>> IR Sony protocol handler initialized
>>> IR RC5 (streamzap) protocol handler initialized
>>> IR SANYO protocol handler initialized
>>> IR MCE Keyboard/mouse protocol handler initialized
>>> imx2-wdt 30280000.wdog: IMX2+ Watchdog Timer enabled. timeout=60s (nowayout=0)
>>> sdhci: Secure Digital Host Controller Interface driver
>>> sdhci: Copyright(c) Pierre Ossman
>>> sdhci-pltfm: SDHCI platform and OF driver helper
>>> sdhci-esdhc-imx 30b40000.usdhc: could not get ultra high speed state, work on normal mode
>>> mmc0: no vqmmc regulator found
>>> mmc0: no vmmc regulator found
>>> mmc0: SDHCI controller on 30b40000.usdhc [30b40000.usdhc] using ADMA
>>> sdhci-esdhc-imx 30b60000.usdhc: could not get ultra high speed state, work on normal mode
>>> mmc2: no vqmmc regulator found
>>> mmc2: no vmmc regulator found
>>> mmc0: new high speed SDHC card at address e624
>>> mmc2: SDHCI controller on 30b60000.usdhc [30b60000.usdhc] using ADMA
>>> mmcblk0: mmc0:e624 SS08G 7.40 GiB
>>> usbcore: registered new interface driver usbhid
>>> usbhid: USB HID core driver
>>> mmcblk0: unknown partition table
>>> TCP: cubic registered
>>> NET: Registered protocol family 10
>>> sit: IPv6 over IPv4 tunneling driver
>>> NET: Registered protocol family 17
>>> Key type dns_resolver registered
>>> usb 1-1: new high-speed USB device number 2 using ci_hdrc
>>> Registering SWP/SWPB emulation handler
>>> SWBST: disabling
>>> usb_otg1_vbus: disabling
>>> regulator-dummy: disabling
>>> imx mcc test is registered.
>>> fec2_phy_nreset: 3300 mV
>>> usb_host_nreset: 3300 mV
>>> lcd_nstby_3v3: no parameters
>>> ci_hdrc ci_hdrc.2: EHCI Host Controller
>>> ci_hdrc ci_hdrc.2: new USB bus registered, assigned bus number 2
>>> mmc2: BKOPS_EN bit is not set
>>> mmc2: new high speed DDR MMC card at address 0001
>>> mmcblk2: mmc2:0001 SEM04G 3.68 GiB
>>> mmcblk2boot0: mmc2:0001 SEM04G partition 1 2.00 MiB
>>> mmcblk2boot1: mmc2:0001 SEM04G partition 2 2.00 MiB
>>> mmcblk2rpmb: mmc2:0001 SEM04G partition 3 2.00 MiB
>>> mmcblk2: unknown partition table
>>> mmcblk2boot1: unknown partition table
>>> mmcblk2boot0: unknown partition table
>>> ci_hdrc ci_hdrc.2: USB 2.0 started, EHCI 1.00
>>> hub 2-0:1.0: USB hub found
>>> hub 2-0:1.0: 1 port detected
>>> Number of LUNs=8
>>> Mass Storage Function, version: 2009/09/11
>>> LUN: removable file: (no medium)
>>> usb-storage 1-1:1.0: USB Mass Storage device detected
>>> scsi0 : usb-storage 1-1:1.0
>>> Number of LUNs=1
>>> no file given for LUN0
>>> g_mass_storage ci_hdrc.0: failed to start g_mass_storage: -22
>>> rtc-em3027 1-0056: setting system clock to 2016-02-16 07:32:51 UTC (1455607971)
>>> fec 30be0000.ethernet eth0: Freescale FEC PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=30be0000.etherne:00, irq=-1)
>>> IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>> fec 30bf0000.ethernet eth1: Freescale FEC PHY driver [Atheros 8031 ethernet] (mii_bus:phy_addr=30be0000.etherne:01, irq=-1)
>>> usb 2-1: new high-speed USB device number 2 using ci_hdrc
>>> IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
>>> hub 2-1:1.0: USB hub found
>>> hub 2-1:1.0: 3 ports detected
>>> scsi 0:0:0:0: Direct-Access     SanDisk  Cruzer Slice     1.14 PQ: 0 ANSI: 2
>>> sd 0:0:0:0: [sda] 15633408 512-byte logical blocks: (8.00 GB/7.45 GiB)
>>> sd 0:0:0:0: [sda] Write Protect is off
>>> sd 0:0:0:0: [sda] No Caching mode page found
>>> sd 0:0:0:0: [sda] Assuming drive cache: write through
>>> sd 0:0:0:0: [sda] No Caching mode page found
>>> sd 0:0:0:0: [sda] Assuming drive cache: write through
>>> sda: unknown partition table
>>> sd 0:0:0:0: [sda] No Caching mode page found
>>> sd 0:0:0:0: [sda] Assuming drive cache: write through
>>> sd 0:0:0:0: [sda] Attached SCSI removable disk
>>> libphy: 30be0000.etherne:00 - Link is Up - 1000/Full
>>> IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>> Sending DHCP requests ., OK
>>> IP-Config: Got DHCP answer from 10.1.1.240, my address is 192.168.27.43
>>> IP-Config: Complete:
>>>      device=eth0, hwaddr=00:01:c0:1a:e9:13, ipaddr=192.168.27.43, mask=255.255.0.0, gw=192.168.0.110
>>>      host=192.168.27.43, domain=compulab.local, nis-domain=(none)
>>>      bootserver=10.1.1.247, rootserver=192.168.11.24, rootpath=
>>>      nameserver0=192.168.10.13, nameserver1=10.1.1.247
>>> ALSA device list:
>>>   No soundcards found.
>>> VFS: Mounted root (nfs filesystem) on device 0:13.
>>> devtmpfs: mounted
>>> Freeing unused kernel memory: 384K (808b9000 - 80919000)
>>> random: systemd urandom read with 58 bits of entropy available
>>> systemd[1]: systemd 228 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
>>> systemd[1]: Detected architecture arm.
>>>
>>> Welcome to Debian GNU/Linux stretch/sid!
>>
>>> Starting kernel ...
>>>
>>> Uncompressing Linux... done, booting the kernel.
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
>>> Kernel command line: console=ttymxc0,115200 earlyprintk=ttymxc0,115200 root=/dev/nfs ip=dhcp nfsroot=192.168.11.24:/home/ilya/work/rootfs/sid-minbase,v3,tcp rw rootwait
>>> PID hash table entries: 4096 (order: 2, 16384 bytes)
>>> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
>>> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
>>> Memory: 700996K/1048576K available (6617K kernel code, 353K rwdata, 2280K rodata, 384K init, 421K bss, 347580K reserved, 0K highmem)
>>> Virtual kernel memory layout:
>>>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>>>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>>>     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
>>>     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>>>     pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)
>>>     modules : 0x7f000000 - 0x7fe00000   (  14 MB)
>>>       .text : 0x80008000 - 0x808b8880   (8899 kB)
>>>       .init : 0x808b9000 - 0x80919080   ( 385 kB)
>>>       .data : 0x8091a000 - 0x80972680   ( 354 kB)
>>>        .bss : 0x8097268c - 0x809dbc00   ( 422 kB)
>>> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
>>> Preemptible hierarchical RCU implementation.
>>>         RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
>>> RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
>>> NR_IRQS:16 nr_irqs:16 16
>>> Switching to timer-based delay loop
>>> sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 1431655765682ns
>>> Architected cp15 timer(s) running at 8.00MHz (phys).
>>> sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2147483648000ns
>>> Ignoring duplicate/late registration of read_current_timer delay
>>> Console: colour dummy device 80x30
>>> Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=30000)
>>> pid_max: default: 32768 minimum: 301
>>> Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
>>> Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
>>> CPU: Testing write buffer coherency: ok
>>> /cpus/cpu at 0 missing clock-frequency property
>>> /cpus/cpu at 1 missing clock-frequency property
>>> CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
>>> Setting up static identity map for 0x80647850 - 0x806478a8
>>> Memory: 700996K/1048576K available (6617K kernel code, 353K rwdata, 2280K rodata, 384K init, 421K bss, 347580K reserved, 0K highmem)
>>> Virtual kernel memory layout:
>>>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>>>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>>>     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
>>>     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
>>>     pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)
>>>     modules : 0x7f000000 - 0x7fe00000   (  14 MB)
>>>       .text : 0x80008000 - 0x808b8880   (8899 kB)
>>>       .init : 0x808b9000 - 0x80919080   ( 385 kB)
>>>       .data : 0x8091a000 - 0x80972680   ( 354 kB)
>>>        .bss : 0x8097268c - 0x809dbc00   ( 422 kB)
>>> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
>>> Preemptible hierarchical RCU implementation.
>>>         RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
>>> RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
>>> Calibrating delay loop (skipped) already calibrated this CPU6.00 BogoMIPS (lpj=30000)
>>> NR_IRQS:16 nr_irqs:16 16
>>> Switching to timer-based delay loop
>>> sched_clock: 32 bits at 3000kHz,
>>> [000001d8] *pgd=00000000
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> Modules linked in:
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> [00000008] *pgd=00000000
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>> Modules linked in:
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> [00000000] *pgd=00000000
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> Modules linked in:
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> [00000000] *pgd=00000000
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> Modules linked in:
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> [00000000] *pgd=00000000
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> Modules linked in:
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> nPU: PIPT / VIPT nonaliasing data cacCPhUe1,:  VfIaPiTl ealdia stion gc oimnes tornulctiinoe
>>> Braoucghhet
>>> m 1Ma chCiPnUes
>>> seSMlP::  CToomtaplu Loafb  S1B C-pirMoXc7es
>>> asbo oatcctoivnastoelde  (6[.0e0a rBloygcooMnI0P]S )e.n
>>> AClPeU:d
>>> 0c mCaP: UC(MsA:)  rsetsaerrtveedd  i3n20  SMViCB m oadte .ac
>>> 0000
>>> cheemvotrmyp fpso:l iciyn:it iDaaltiaz ecda
>>> writealloc
>>> On node 0 totalpages: 262144
>>> aree_area_init_nVFoPde :s unpopdoer t0,  pvg0d.a3t:  80i9m71p1l0e0m,e nntoord 4e1_ meamr_chmitaepc taubr7e5 9200 0p
>>> p 3  0D MvAa rzioannet :7  r2e0v4 85
>>> tes uspeidn cftorlr c ormee:m mianpi
>>> i a lDiMzAe dz opnie:n c0t rpalge s sruebsseyrsvteedm
>>>
>>> h DMAre guzloanteo:r -2d62u14m4m yp:a gneos ,p aLrIaFmOe tebrastc
>>> 31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Binux version 3.14.52+ (ilya at ilya-pc) NE(Tg:c cR evgeirssiotne r4e.d 7pr.o2t (oScoolu fracmeirlyy  C1o6de
>>> nch Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410DMfAc:0 7p5r]e arlelvoicsaitoend  52 5(6A RKMivB7 )p,o olc rf=1o0rc 5a3to8mi7cd
>>> ahCPeU:r PeInPt Ta l/ lVoIcaPtTi noonns
>>> iasing datacp uciadclhee:,  uVsIPiTn g agloivaesirngn oir nlsatrducdteiro
>>> : cpauicdhlee
>>> mpMnagc hignoev emrnoodrel :m enCuo
>>> abUs eS BWCD-iOMXG71
>>>   rbeosoettc osnosuorlcee
>>> [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> pysOcno nno d3e0 304 0t0o0t0.ailopmaugxecs-:g p2r6:2 r1eg4m4a
>>> 11freeme _0axr3ea0_3i40n0i0t_0no-d0ex3:0 3no4dfef f0f, ]p grdeagti s8t0er9ed7
>>> c, snyosdcoen_ m3e0m3_50m0a0p0 .aobc7o5t90p00-
>>> el  :DM Ar ezgomanpe :[ m2e0m48  0pxa3g0e3s50 00u0s-ed0 xf3o0r3 5mfefmffm]a pr
>>> o s teDrMeA dz
>>> : 0 pagseyss croesne r3v0e3d6
>>> 6f  0D.MaAn zaonteo:p:  2r6e2g1m4a4p  pa[gmeesm, 0 xL3I03F6O0 0b0a0t-c0hx:33013
>>> ffPE]R CrePgiUs:t eErmbeedd
>>> d1 8 pvdad1gp0eds:/ c8p0u0  @<a-b-7>3 1520000 0m Vs 8a3t2 01 0r080 1m9V2
>>> 056 vdud13p22:7 61810
>>> x--B>o o1ti3n0g0  mLVin u
>>> 30 physical CPUsy sc0oxn0
>>> 0L0i0n0ux. svrecr:si orne g3m.a1p4 .[m5em2 +0 x(3i0l39y0a0 at i0l0y-a0-xp3c0)3 9f(fgfccf ]v reergsiiosnt e4r.e7.d2
>>> 9ourcery CodeDBDeRn cthy pLei itse  2D0D1R23.!0
>>> -64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> sPU: ARMv7 Profacileesdso rt o[ 4f1i0nfdc 0o7c5o]tp  nroedvei
>>> ofna i5l e(dAR Mtvo 7fi)n,d  corc=o1t0pc 5n38o7dd
>>> e
>>> ghUw: -PbIrPeTa k/p oViInPt:T f ounnodn a5l i(a+s1i nrge sdeartvae dc)a cbhree,a kVIpPTo ianltia sianngd  in4s twartucchtpiooinn tc archee
>>> mtaecrhsi.ne
>>> mhewl:- bCroemakppouiLnabt S:B Cm-aixMiXm7u
>>> etcbhopooticnotn ssoilzee  [eiarsl y8c onb0]y teensab.l
>>> d
>>> 0ma: CMA: reserviemdx 73d2-0p iMnicBt ralt  3a0c20c00000000
>>> dMoemmuoxrc-yl ppsorl:i icniyt:i Daaltizae dca chIeM X wpriintceatlrlloc
>>> noOenr
>>> 0 0 tiomtxa7ldp-apgiensc:t r2l6 320134340
>>> .frieoem_uarxeac_:i inniitt_inoadlei: zneodd eI M0X,  ppigndcatt r8l0 9dr7i1v1e0r0,
>>> ode_mem_map ab759000
>>>   DMUM iAs  zroenaed:y  2f0o4r 8c rpoasgse sc oursee dco mfmourn imceatmimoanp!
>>>
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> tooting biLoi:n ucxr eaotne p hsylasbi ca<l bCiPoU- 00>x 0a
>>> 0
>>> 2ux version 3.14.52+ (ilya at ilya-pc) (gcc vmexrss-idomna  43.37.020 00(0S0ou.rcdemray- aCpobdhe:B einnitciha Lliitzeed
>>> b2.09-64) us)b _#ot8g 1SM_P vPbRuEsE: M5P0T 0M0o mnV  Fe
>>> 35 1f4e:c51_5p:h0y8_n rIeSTs e2t:0 136
>>> 0 m[0V00 0
>>> 04]pl a*tpgfd=o0r0m 0r0e0g0u0l0at
>>> =1.P1U5::  DArRMiv7v ePrr orecg-efsisoxre d-[v4o10lftcag0e 7r5e]q ureevisstis opnr 5o (bAeR Mdve7f)e,r raclr
>>> 453t8s7cd20
>>> IreCPgU::  P3I3P00T m V/  V
>>> T plnaotnfaolrima srienggu ldaattoar .c1a7c:h Der,i VvIePrT  reag-lfiiasxiend-gvo litnasgter urcetiqounes tcsa cpher
>>> liM odedfuelrerasl
>>> rpleadt ifn:o
>>> - lMcadc_hinnsetb y_m3ovde3l.:18 :C omDpruivLera br eSgBC--ifMiXxe7d
>>> bboolottacgeo rnesqoulees [tesa rplroybec odn0e]f ereranla
>>> ed
>>> 0ma: CMASC:S Ir esusbesryvsedt 3e2m0 i nMiitBi aalti zace0d0
>>> 00
>>> ieusmbcoorrye :p orleigciys:te rDeatda  necwa chien twerritfeaaclel odcr
>>> r Ouns bnofdse
>>> etoustbaclopraeg:e sr:e g2i6s2t1e4r4
>>> nefrwe ei_natreear_fianciet _dnordiev:e rn ohdeu b0
>>> vpusgbdcato r8e0:97 11r0e0g,i stneordee_dm emn_emwa pd eabv7i5c9e0 d0r0i
>>> r   uDMsAb
>>> oneus:bp h2y0_4n8o pp1.a1g0es  suuspepdl yf ovrc cm enmmoatp f
>>> dd  ,DM Au siznogn ed: u0m mpayg erse gruelsaetrovre
>>>
>>> nsb  pDMhA yz_onnoep:2 .21612 1s44u ppplayg evsc,c  LnIoFOt  bfaotuncdh,: u3s1i
>>> edPuEmmRyC PrUeg:u lEamtbeodrd
>>> 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>>   DMA zone: 2048 pages used for memmap
>>>   DMA zone: 0 pages reserved
>>>   DMA zone: 262144 pages, LIFO batch:31
>>> PERCPU: Embedded 8 pages/cpu @ab735000 s8320 r8192 d16256 u32768
>>> Booting Linux on physical CPU 0x0
>>> Linux version 3.14.52+ (ilya at ilya-pc) (gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-64) ) #8 SMP PREEMPT Mon Feb 15 14:55:08 IST 2016
>>> CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> Machine model: CompuLab SBC-iMX7
>>> bootconsole [earlycon0] enabled
>>> cma: CMA: reserved 320 MiB at ac000000
>>> Memory policy: Data cache writealloc
>>> On node 0 totalpages: 262144
>>> free_area_init_node: node 0, pgdat 80971100, node_mem_map ab759000
>>> [00000000] *pgd=00000000
>>>   DMA zone: 2048 pages used for memmap
>>




From arnd at arndb.de  Thu Feb 18 08:34:48 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 17:34:48 +0100
Subject: [PATCH] [RESEND] ARM: PJ4: don't use PJ4B code on PJ4
Message-ID: <1455813309-2556471-1-git-send-email-arnd@arndb.de>

We can have multiplatform kernels with PJ4 (Dove, MMP2) in combination
with PJ4B (Armada 370) or PJ4B-MP (Berlin, Armada XP), and the processor
functions that are defined for PJ4B use a mask that covers all three
core types, rather than using the default ARMv7 type for the original
PJ4.

This adds a second entry for PJ4B-MP, so we at least get a consistent
behavior between single-machine kernels and combined ones.

I suspect however that we actually want different contents for each
of the three cores, as PJ4B and PJ4B-MP appear to be at least as
different as PJ4 is from PJ4B, in particular the support for
the standard architecture extensions like IDIV and LPAE, and the
PJ4B_ERRATA_4742 workaround apparently does not apply to PJ4B-MP
but might apply to PJ4.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 049be07053eb ("ARM: 7754/1: Fix the CPU ID and the mask associated to the PJ4B")
---
I sent this out previously as an RFC but did not get any reply. I'm
pretty sure we still need the patch, or an extended version of it,
but I'd be much happier if someone could actually look into the
contents.
---
 arch/arm/mm/proc-v7.S | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 0f8963a7e7d9..7239fd55b159 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -576,10 +576,17 @@ __v7_ca8_proc_info:
 #ifdef CONFIG_CPU_PJ4B
 	.type   __v7_pj4b_proc_info, #object
 __v7_pj4b_proc_info:
-	.long	0x560f5800
-	.long	0xff0fff00
+	.long	0x562f5840
+	.long	0xfffffff0
 	__v7_proc __v7_pj4b_proc_info, __v7_pj4b_setup, proc_fns = pj4b_processor_functions
 	.size	__v7_pj4b_proc_info, . - __v7_pj4b_proc_info
+
+	.type   __v7_pj4bmp_proc_info, #object
+__v7_pj4bmp_proc_info:
+	.long	0x561f5810
+	.long	0xfffffff0
+	__v7_proc __v7_pj4bmp_proc_info, __v7_pj4b_setup, proc_fns = pj4b_processor_functions
+	.size	__v7_pj4bmp_proc_info, . - __v7_pj4bmp_proc_info
 #endif
 
 	/*
-- 
2.7.0



From marc.zyngier at arm.com  Thu Feb 18 08:41:23 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Feb 2016 16:41:23 +0000
Subject: [PATCH v2] irqchip: irq-mvebu-odmi: new driver for platform MSI
 on Marvell 7K/8K
In-Reply-To: <1455811134-3679-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455811134-3679-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <56C5F433.8010701@arm.com>

Hey Thomas,

It looks really nice, except for a couple of points, see below.

On 18/02/16 15:58, Thomas Petazzoni wrote:
> This commits adds a new irqchip driver that handles the ODMI
> controller found on Marvell 7K/8K processors. The ODMI controller
> provide MSI interrupt functionality to on-board peripherals, much like
> the GIC-v2m.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
> Changes v1 -> v2:
>  - Better commit title, as suggested by Marc Zyngier.
>  - Improve the DT binding documentation, as suggested by Marc Zingier:
>    add a reference to the GIC documentation, be more specific about
>    the marvell,spi-base values, and add the requirement of the
>    interrupt-parent property.
>  - As suggested by Marc Zyngier, use a single global bitmap to
>    allocate all ODMIs, regardless of the frame they belong to. As part
>    of this change, the hwirq used to identify the interrupt inside the
>    ODMI irqdomain are 0-based (instead of being based on their
>    corresponding SPI base value), which allows to significantly
>    simplify the allocation/free logic.
> ---
>  .../marvell,odmi-controller.txt                    |  41 ++++
>  drivers/irqchip/Kconfig                            |   4 +
>  drivers/irqchip/Makefile                           |   1 +
>  drivers/irqchip/irq-mvebu-odmi.c                   | 248 +++++++++++++++++++++
>  4 files changed, 294 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
>  create mode 100644 drivers/irqchip/irq-mvebu-odmi.c
> 
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
> new file mode 100644
> index 0000000..252d5c9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
> @@ -0,0 +1,41 @@
> +
> +* Marvell ODMI for MSI support
> +
> +Some Marvell SoCs have an On-Die Message Interrupt (ODMI) controller
> +which can be used by on-board peripheral for MSI interrupts.
> +
> +Required properties:
> +
> +- compatible           : The value here should contain "marvell,odmi-controller".
> +
> +- interrupt,controller : Identifies the node as an interrupt controller.
> +
> +- msi-controller       : Identifies the node as an MSI controller.
> +
> +- marvell,odmi-frames  : Number of ODMI frames available. Each frame
> +                         provides a number of events.
> +
> +- reg                  : List of register definitions, one for each
> +                         ODMI frame.
> +
> +- marvell,spi-base     : List of GIC base SPI interrupts, one for each
> +                         ODMI frame. Those SPI interrupts are 0-based,
> +                         i.e marvell,spi-base = <128> will use SPI #96.
> +                         See Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
> +                         for details about the GIC Device Tree binding.
> +
> +- interrupt-parent     : Reference to the parent interrupt controller.
> +
> +Example:
> +
> +	odmi: odmi at 300000 {
> +		compatible = "marvell,odmi-controller";
> +		interrupt-controller;
> +		msi-controller;
> +		marvell,odmi-frames = <4>;
> +		reg = <0x300000 0x4000>,
> +		      <0x304000 0x4000>,
> +		      <0x308000 0x4000>,
> +		      <0x30C000 0x4000>;
> +		marvell,spi-base = <128>, <136>, <144>, <152>;
> +	};
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index 715923d..18bed3c 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -217,3 +217,7 @@ config IRQ_MXS
>  	def_bool y if MACH_ASM9260 || ARCH_MXS
>  	select IRQ_DOMAIN
>  	select STMP_DEVICE
> +
> +config MVEBU_ODMI
> +	bool
> +	select GENERIC_MSI_IRQ_DOMAIN
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 18caacb..29c388f 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -59,3 +59,4 @@ obj-$(CONFIG_ARCH_SA1100)		+= irq-sa11x0.o
>  obj-$(CONFIG_INGENIC_IRQ)		+= irq-ingenic.o
>  obj-$(CONFIG_IMX_GPCV2)			+= irq-imx-gpcv2.o
>  obj-$(CONFIG_PIC32_EVIC)		+= irq-pic32-evic.o
> +obj-$(CONFIG_MVEBU_ODMI)		+= irq-mvebu-odmi.o
> diff --git a/drivers/irqchip/irq-mvebu-odmi.c b/drivers/irqchip/irq-mvebu-odmi.c
> new file mode 100644
> index 0000000..0017f05
> --- /dev/null
> +++ b/drivers/irqchip/irq-mvebu-odmi.c
> @@ -0,0 +1,248 @@
> +/*
> + * Copyright (C) 2016 Marvell
> + *
> + * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#define pr_fmt(fmt) "GIC-ODMI: " fmt
> +
> +#include <linux/irq.h>
> +#include <linux/irqchip.h>
> +#include <linux/irqdomain.h>
> +#include <linux/kernel.h>
> +#include <linux/msi.h>
> +#include <linux/of_address.h>
> +#include <linux/slab.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +#define GICP_ODMIN_SET			0x40
> +#define   GICP_ODMI_INT_NUM_SHIFT	12
> +#define GICP_ODMIN_GM_EP_R0		0x110
> +#define GICP_ODMIN_GM_EP_R1		0x114
> +#define GICP_ODMIN_GM_EA_R0		0x108
> +#define GICP_ODMIN_GM_EA_R1		0x118
> +
> +/*
> + * We don't support the group events, so we simply have 8 interrupts
> + * per frame.
> + */
> +#define NODMIS_PER_FRAME 8
> +#define NODMIS_SHIFT     3
> +#define NODMIS_MASK      7

All these values are directly related, so it would be nice if they would
be expressed in term of each other:

#define NODMIS_SHIFT	 3
#define NODMIS_PER_FRAME (1 << NODMIS_SHIFT)
#define NODMIS_MASK      (NODMIS_PER_FRAME - 1)


> +
> +struct odmi_data {
> +	struct resource res;
> +	void __iomem *base;
> +	unsigned int spi_base;
> +};
> +
> +static struct odmi_data *odmis;
> +static unsigned long *odmis_bm;
> +static unsigned int odmis_count;
> +
> +/* Protects odmis_bm */
> +static DEFINE_SPINLOCK(odmis_bm_lock);
> +
> +static int odmi_set_affinity(struct irq_data *d,
> +			     const struct cpumask *mask, bool force)
> +{
> +	int ret;
> +
> +	ret = irq_chip_set_affinity_parent(d, mask, force);
> +	if (ret == IRQ_SET_MASK_OK)
> +		ret = IRQ_SET_MASK_OK_DONE;
> +
> +	return ret;
> +}
> +
> +static void odmi_compose_msi_msg(struct irq_data *d, struct msi_msg *msg)
> +{
> +	struct odmi_data *odmi;
> +	phys_addr_t addr;
> +	unsigned int odmin;
> +
> +	if (WARN_ON(d->hwirq >= odmis_count * NODMIS_PER_FRAME))
> +		return;
> +
> +	odmi = &odmis[d->hwirq >> NODMIS_SHIFT];
> +	odmin = d->hwirq & NODMIS_MASK;
> +
> +	addr = odmi->res.start + GICP_ODMIN_SET;
> +
> +	msg->address_hi = upper_32_bits(addr);
> +	msg->address_lo = lower_32_bits(addr);
> +	msg->data = odmin << GICP_ODMI_INT_NUM_SHIFT;
> +}
> +
> +static struct irq_chip odmi_irq_chip = {
> +	.name			= "ODMI",
> +	.irq_mask		= irq_chip_mask_parent,
> +	.irq_unmask		= irq_chip_unmask_parent,
> +	.irq_eoi		= irq_chip_eoi_parent,
> +	.irq_set_affinity	= odmi_set_affinity,
> +	.irq_compose_msi_msg	= odmi_compose_msi_msg,
> +};
> +
> +static int odmi_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> +				 unsigned int nr_irqs, void *args)
> +{
> +	struct odmi_data *odmi = NULL;
> +	struct irq_fwspec fwspec;
> +	struct irq_data *d;
> +	unsigned int hwirq, odmin;
> +	int ret;
> +
> +	spin_lock(&odmis_bm_lock);
> +	hwirq = find_first_zero_bit(odmis_bm, NODMIS_PER_FRAME * odmis_count);
> +	if (hwirq >= NODMIS_PER_FRAME * odmis_count) {
> +		spin_unlock(&odmis_bm_lock);
> +		return -ENOSPC;
> +	}
> +
> +	__set_bit(hwirq, odmis_bm);
> +	spin_unlock(&odmis_bm_lock);
> +
> +	odmi = &odmis[hwirq >> NODMIS_SHIFT];
> +	odmin = hwirq & NODMIS_MASK;
> +
> +	fwspec.fwnode = domain->parent->fwnode;
> +	fwspec.param_count = 3;
> +	fwspec.param[0] = GIC_SPI;
> +	fwspec.param[1] = odmi->spi_base - 32 + odmin;
> +	fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
> +
> +	ret = irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
> +	if (ret) {
> +		pr_err("Cannot allocate parent IRQ\n");
> +		spin_lock(&odmis_bm_lock);
> +		__clear_bit(odmin, odmis_bm);
> +		spin_unlock(&odmis_bm_lock);
> +		return ret;
> +	}
> +
> +	/* Configure the interrupt line to be edge */
> +	d = irq_domain_get_irq_data(domain->parent, virq);
> +	d->chip->irq_set_type(d, IRQ_TYPE_EDGE_RISING);
> +
> +	irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
> +				      &odmi_irq_chip, NULL);
> +
> +	return 0;
> +}
> +
> +static void odmi_irq_domain_free(struct irq_domain *domain,
> +				 unsigned int virq, unsigned int nr_irqs)
> +{
> +	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> +
> +	if (d->hwirq >= odmis_count * NODMIS_PER_FRAME) {
> +		pr_err("Failed to teardown msi. Invalid hwirq %lu\n", d->hwirq);
> +		return;
> +	}
> +
> +	irq_domain_free_irqs_parent(domain, virq, nr_irqs);
> +
> +	/* Actually free the MSI */
> +	spin_lock(&odmis_bm_lock);
> +	__clear_bit(d->hwirq, odmis_bm);
> +	spin_unlock(&odmis_bm_lock);
> +}
> +
> +static const struct irq_domain_ops odmi_domain_ops = {
> +	.alloc	= odmi_irq_domain_alloc,
> +	.free	= odmi_irq_domain_free,
> +};
> +
> +static struct irq_chip odmi_msi_irq_chip = {
> +	.name	= "ODMI",
> +};
> +
> +static struct msi_domain_ops odmi_msi_ops = {
> +};
> +
> +static struct msi_domain_info odmi_msi_domain_info = {
> +	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),
> +	.ops	= &odmi_msi_ops,
> +	.chip	= &odmi_msi_irq_chip,
> +};
> +
> +static int __init mvebu_odmi_init(struct device_node *node,
> +				  struct device_node *parent)
> +{
> +	struct irq_domain *inner_domain, *plat_domain;
> +	int ret, i;
> +
> +	if (of_property_read_u32(node, "marvell,odmi-frames", &odmis_count))
> +		return -EINVAL;
> +
> +	odmis = kcalloc(odmis_count, sizeof(struct odmi_data), GFP_KERNEL);
> +	if (!odmis)
> +		return -ENOMEM;
> +
> +	odmis_bm = kzalloc(odmis_count * NODMIS_PER_FRAME / BITS_PER_BYTE,
> +			   GFP_KERNEL);

Blah. this will allocate the exact number of bytes, which you will then
access as longs, touching memory that's not yours in the process (I've
been recently bitten and publicly shamed...).

Consider the following:

odmis_bm = kzalloc(BITS_TO_LONGS(odmis_count * NODMIS_PER_FRAME) *
sizeof(long), GFP_KERNEL);

> +	if (!odmis_bm) {
> +		ret = -ENOMEM;
> +		goto err_alloc;
> +	}
> +
> +	for (i = 0; i < odmis_count; i++) {
> +		struct odmi_data *odmi = &odmis[i];
> +
> +		ret = of_address_to_resource(node, i, &odmi->res);
> +		if (ret)
> +			goto err_unmap;
> +
> +		odmi->base = of_io_request_and_map(node, i, "odmi");
> +		if (IS_ERR(odmi->base)) {
> +			ret = PTR_ERR(odmi->base);
> +			goto err_unmap;
> +		}
> +
> +		if (of_property_read_u32_index(node, "marvell,spi-base",
> +					       i, &odmi->spi_base)) {
> +			ret = -EINVAL;
> +			goto err_unmap;
> +		}
> +	}
> +
> +	inner_domain = irq_domain_create_linear(of_node_to_fwnode(node),
> +						odmis_count * NODMIS_PER_FRAME,
> +						&odmi_domain_ops, NULL);
> +	if (!inner_domain) {
> +		ret = -ENOMEM;
> +		goto err_unmap;
> +	}
> +
> +	inner_domain->parent = irq_find_host(parent);
> +
> +	plat_domain = platform_msi_create_irq_domain(of_node_to_fwnode(node),
> +						     &odmi_msi_domain_info,
> +						     inner_domain);
> +	if (!plat_domain) {
> +		ret = -ENOMEM;
> +		goto err_remove_inner;
> +	}
> +
> +	return 0;
> +
> +err_remove_inner:
> +	irq_domain_remove(inner_domain);
> +err_unmap:
> +	for (i = 0; i < odmis_count; i++) {
> +		struct odmi_data *odmi = &odmis[i];
> +
> +		if (odmi->base && !IS_ERR(odmi->base))
> +			iounmap(odmis[i].base);
> +	}
> +	kfree(odmis_bm);
> +err_alloc:
> +	kfree(odmis);
> +	return ret;
> +}
> +
> +IRQCHIP_DECLARE(mvebu_odmi, "marvell,odmi-controller", mvebu_odmi_init);
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From robert.richter at caviumnetworks.com  Thu Feb 18 08:42:17 2016
From: robert.richter at caviumnetworks.com (Robert Richter)
Date: Thu, 18 Feb 2016 17:42:17 +0100
Subject: [PATCH 2/2] net, thunderx: Use bool in structs where possible
In-Reply-To: <20160218.110514.652169911099659792.davem@davemloft.net>
References: <1455799149-19590-1-git-send-email-rrichter@caviumnetworks.com>
 <1455799149-19590-3-git-send-email-rrichter@caviumnetworks.com>
 <20160218.110514.652169911099659792.davem@davemloft.net>
Message-ID: <20160218164217.GP24726@rric.localdomain>

On 18.02.16 11:05:14, David Miller wrote:
> From: Robert Richter <rrichter at caviumnetworks.com>
> Date: Thu, 18 Feb 2016 13:39:09 +0100
> 
> > From: Robert Richter <rrichter at cavium.com>
> > 
> > Looks like the :1 notation was accidentally introduced (this still
> > uses 1 byte per flag). Using bool instead, which is the common use.
> > 
> > Signed-off-by: Robert Richter <rrichter at cavium.com>
> 
> Such cleanups are not appropriate for 'net'.  Only real bug fixes should
> be targetted that.
> 
> Respin these patches targetting the correct tree(s).

Do you mean posting the two as "trivial" patches?

Thanks,

-Robert


From eric.auger at linaro.org  Thu Feb 18 08:42:26 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 18 Feb 2016 17:42:26 +0100
Subject: [RFC v3 07/15] iommu: iommu_get/put_single_reserved
In-Reply-To: <20160218110616.05108071@arm.com>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
 <1455264797-2334-8-git-send-email-eric.auger@linaro.org>
 <20160218110616.05108071@arm.com>
Message-ID: <56C5F472.1020003@linaro.org>

Hello,
On 02/18/2016 12:06 PM, Marc Zyngier wrote:
> On Fri, 12 Feb 2016 08:13:09 +0000
> Eric Auger <eric.auger at linaro.org> wrote:
> 
>> This patch introduces iommu_get/put_single_reserved.
>>
>> iommu_get_single_reserved allows to allocate a new reserved iova page
>> and map it onto the physical page that contains a given physical address.
>> It returns the iova that is mapped onto the provided physical address.
>> Hence the physical address passed in argument does not need to be aligned.
>>
>> In case a mapping already exists between both pages, the IOVA mapped
>> to the PA is directly returned.
>>
>> Each time an iova is successfully returned a binding ref count is
>> incremented.
>>
>> iommu_put_single_reserved decrements the ref count and when this latter
>> is null, the mapping is destroyed and the iova is released.
> 
> I wonder if there is a requirement for the caller to find out about the
> size of the mapping, or to impose a given size... MSIs clearly do not
> have that requirement (this is always a 32bit value), but since. 
> allocations usually pair address and size, I though I'd ask...
Yes. Currently this only makes sure the host PA is mapped and returns
the corresponding IOVA. It is part of the discussion we need to have on
the API besides the problematic of which API it should belong to.

Thanks

Eric
> 
> Thanks,
> 
> 	M.
> 



From marc.zyngier at arm.com  Thu Feb 18 08:43:17 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Feb 2016 16:43:17 +0000
Subject: no irq domain found for ... a GPIO interrupt controller
In-Reply-To: <11a0b1f5808af5bdabaab657366918d4@agner.ch>
References: <2dc0519827dc9d210e38c498d830cd97@agner.ch>
 <20160218091432.6968b836@arm.com> <11a0b1f5808af5bdabaab657366918d4@agner.ch>
Message-ID: <56C5F4A5.2000206@arm.com>

Hi Stefan,

On 18/02/16 16:13, Stefan Agner wrote:
> Hi Marc,
> 
> On 2016-02-18 01:14, Marc Zyngier wrote:
> <snip>
>> What your stack trace shows is that the failure occurs at boot time,
>> when of_platform_populate() parses the DT and creates the platform
>> devices. As part of this process, it tries to resolves the interrupt
>> specifiers, but fails to do so for this particular device, since the
>> corresponding irqchip and domain have not been created yet (the GPIO
>> controller is itself a device, while other irqchips are not).
>>
>> But as long as your device driver uses platform_get_irq(), you will
>> force the interrupt specifier to be evaluated again, this time giving
>> you a valid interrupt (and provided that your GPIO driver has
>> initialized in the meantime - check for -EPROBE_DEFER). At some point,
>> we'll be able to kill the interrupt resolution from
>> of_platform_populate().
> 
> The device driver is using platform_get_irq. However, I think it
> currently would not handle EPROBE_DEFER right, but seems also not to
> happen in practice...
> 
>>
>> To summarize, your driver not working may not be related to this issue.
> 
> So this means that despite the warning, nothing I really need to worry
> right? Does this warning will go away in the future?

It is unlikely that the warning will go away anytime soon (there is a
truckload of drivers to fix), but you can safely ignore it as long as
you end up getting a interrupt from platform_get_irq().

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From ilya at compulab.co.il  Thu Feb 18 08:44:07 2016
From: ilya at compulab.co.il (Ilya Ledvich)
Date: Thu, 18 Feb 2016 18:44:07 +0200
Subject: iMX7d cpu1 issue
In-Reply-To: <AMSPR04MB263D00A3F8D9A8D9D3A536D88AF0@AMSPR04MB263.eurprd04.prod.outlook.com>
References: <56C2D63F.1030408@compulab.co.il> <20160218140913.GY6756@tiger>
 <AMSPR04MB263D00A3F8D9A8D9D3A536D88AF0@AMSPR04MB263.eurprd04.prod.outlook.com>
Message-ID: <56C5F4D7.1070704@compulab.co.il>

Hi!

On 02/18/2016 05:24 PM, Frank Li wrote:
>
>
>> -----Original Message-----
>> From: Shawn Guo [mailto:shawnguo at kernel.org]
>> Sent: Thursday, February 18, 2016 8:09 AM
>> To: Ilya Ledvich <ilya at compulab.co.il>
>> Cc: linux-arm-kernel at lists.infradead.org; Frank Li <frank.li at nxp.com>;
>> Yongcai Huang <anson.huang at nxp.com>
>> Subject: Re: iMX7d cpu1 issue
>>
>> On Tue, Feb 16, 2016 at 09:56:47AM +0200, Ilya Ledvich wrote:
>>> Hi Shawn,
>>> I'm working on Compulab CL-SOM-IMX7 device
>>> (http://www.compulab.co.il/products/computer-on-modules/cl-som-
>> imx7-fr
>>> eescale-i-mx-7-system-on-module)
>>> based on Freescale iMX7d CPU.
>>> I use the Freescale latest BSP imx_3.14.52_1.1.0_ga  and the Linux
>>> mainline v4.4-rc6 as a reference.
>>> I observe an issue with bringing up the second CPU core. Briefly, the
>>> kernel can successfully boot only when CPU1 fails to come online.
>>> In this case the boot log shows the following messages:
>>> ...
>>> CPU1: failed to come online
>>> Brought up 1 CPUs
>>> SMP: Total of 1 processors activated (6.00 BogoMIPS).
>>> ...
>>>
>>> Otherwise, the device tries to start kernel several times until the
>>> boot process eventually crashes. Please see attached logs for more
>>> details.
>>> This never happens on mainline Linus kernel, because it never tries to
>>> bring up CPU1.
>>> Unfortunately, we cannot verify this behavior on reference board cause
>>> we have no one.
>>> Have you ever seen such behavior? Could you please advice something?
>
> Did you set arm,cpu-registers-not-fw-configured; in arch timer?

Yes, it's set in the imx7d.dtsi file included by my device .dts.

> How about your uboot version?
>
> Latest upstream uboot already boot A7 as no-security mode.

I actually use v2016.01 from the upstream and u-boot sources are based 
on on mx7dsabresd.c.

>
> Best regards
> Frank Li
>

Kind regards,
Ilya.


From jglauber at cavium.com  Thu Feb 18 08:50:09 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Thu, 18 Feb 2016 17:50:09 +0100
Subject: [PATCH v4 0/5] Cavium ThunderX PMU support
Message-ID: <cover.1455810755.git.jglauber@cavium.com>

Hi,

this should address all comments. With the simplified event mask
arm isn't touched anymore and also the cpuid check vanished.

Changes to v3:
- renamed A57 events to IMPDEF
- changed comment about 64 bit cycle counter overflow
- unconditionally increase event mask

Changes to v2:
- fixed arm compile errors

Changes to v1:
- renamed thunderx dt pmu binding to thunder

Jan

--------------------------------------------------------

Jan Glauber (5):
  arm64/perf: Rename Cortex A57 events
  arm64/perf: Add Cavium ThunderX PMU support
  arm64: dts: Add Cavium ThunderX specific PMU
  arm64/perf: Enable PMCR long cycle counter bit
  arm64/perf: Extend event mask for ARMv8.1

 Documentation/devicetree/bindings/arm/pmu.txt |   1 +
 arch/arm64/boot/dts/cavium/thunder-88xx.dtsi  |   5 ++
 arch/arm64/kernel/perf_event.c                | 120 +++++++++++++++++++++-----
 3 files changed, 105 insertions(+), 21 deletions(-)

-- 
1.9.1



From jglauber at cavium.com  Thu Feb 18 08:50:13 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Thu, 18 Feb 2016 17:50:13 +0100
Subject: [PATCH v4 4/5] arm64/perf: Enable PMCR long cycle counter bit
In-Reply-To: <cover.1455810755.git.jglauber@cavium.com>
References: <cover.1455810755.git.jglauber@cavium.com>
Message-ID: <467597048eda3004bd69f1fbe3981aab111e00dd.1455810755.git.jglauber@cavium.com>

With the long cycle counter bit (LC) disabled the cycle counter is not
working on ThunderX SOC (ThunderX only implements Aarch64).
Also, according to documentation LC == 0 is deprecated.

To keep the code simple the patch does not introduce 64 bit wide counter
functions. Instead writing the cycle counter always sets the upper
32 bits so overflow interrupts are generated as before.

Original patch from Andrew Pinksi <Andrew.Pinksi at caviumnetworks.com>

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 arch/arm64/kernel/perf_event.c | 21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 0ed05f6..c68fa98 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -405,6 +405,7 @@ static const struct attribute_group *armv8_pmuv3_attr_groups[] = {
 #define ARMV8_PMCR_D		(1 << 3) /* CCNT counts every 64th cpu cycle */
 #define ARMV8_PMCR_X		(1 << 4) /* Export to ETM */
 #define ARMV8_PMCR_DP		(1 << 5) /* Disable CCNT if non-invasive debug*/
+#define ARMV8_PMCR_LC		(1 << 6) /* Overflow on 64 bit cycle counter */
 #define	ARMV8_PMCR_N_SHIFT	11	 /* Number of counters supported */
 #define	ARMV8_PMCR_N_MASK	0x1f
 #define	ARMV8_PMCR_MASK		0x3f	 /* Mask for writable bits */
@@ -494,9 +495,16 @@ static inline void armv8pmu_write_counter(struct perf_event *event, u32 value)
 	if (!armv8pmu_counter_valid(cpu_pmu, idx))
 		pr_err("CPU%u writing wrong counter %d\n",
 			smp_processor_id(), idx);
-	else if (idx == ARMV8_IDX_CYCLE_COUNTER)
-		asm volatile("msr pmccntr_el0, %0" :: "r" (value));
-	else if (armv8pmu_select_counter(idx) == idx)
+	else if (idx == ARMV8_IDX_CYCLE_COUNTER) {
+		/*
+		 * Set the upper 32bits as this is a 64bit counter but we only
+		 * count using the lower 32bits and we want an interrupt when
+		 * it overflows.
+		 */
+		u64 value64 = 0xffffffff00000000ULL | value;
+
+		asm volatile("msr pmccntr_el0, %0" :: "r" (value64));
+	} else if (armv8pmu_select_counter(idx) == idx)
 		asm volatile("msr pmxevcntr_el0, %0" :: "r" (value));
 }
 
@@ -768,8 +776,11 @@ static void armv8pmu_reset(void *info)
 		armv8pmu_disable_intens(idx);
 	}
 
-	/* Initialize & Reset PMNC: C and P bits. */
-	armv8pmu_pmcr_write(ARMV8_PMCR_P | ARMV8_PMCR_C);
+	/*
+	 * Initialize & Reset PMNC. Request overflow interrupt for
+	 * 64 bit cycle counter but cheat in armv8pmu_write_counter().
+	 */
+	armv8pmu_pmcr_write(ARMV8_PMCR_P | ARMV8_PMCR_C | ARMV8_PMCR_LC);
 }
 
 static int armv8_pmuv3_map_event(struct perf_event *event)
-- 
1.9.1



From jglauber at cavium.com  Thu Feb 18 08:50:11 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Thu, 18 Feb 2016 17:50:11 +0100
Subject: [PATCH v4 2/5] arm64/perf: Add Cavium ThunderX PMU support
In-Reply-To: <cover.1455810755.git.jglauber@cavium.com>
References: <cover.1455810755.git.jglauber@cavium.com>
Message-ID: <cbce6ebf42efa8c0bcfc590b2569bf57cb0fd763.1455810755.git.jglauber@cavium.com>

Support PMU events on Caviums ThunderX SOC. ThunderX supports
some additional counters compared to the default ARMv8 PMUv3:

- branch instructions counter
- stall frontend & backend counters
- L1 dcache load & store counters
- L1 icache counters
- iTLB & dTLB counters
- L1 dcache & icache prefetch counters

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 arch/arm64/kernel/perf_event.c | 69 +++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 68 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 2adbcb5..0ed05f6 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -97,6 +97,15 @@
 #define ARMV8_IMPDEF_PERFCTR_L1_DCACHE_REFILL_ST		0x43
 #define ARMV8_IMPDEF_PERFCTR_DTLB_REFILL_LD			0x4c
 #define ARMV8_IMPDEF_PERFCTR_DTLB_REFILL_ST			0x4d
+#define ARMV8_IMPDEF_PERFCTR_DTLB_ACCESS_LD			0x4e
+#define ARMV8_IMPDEF_PERFCTR_DTLB_ACCESS_ST			0x4f
+
+/* ARMv8 Cavium ThunderX specific event types. */
+#define ARMV8_THUNDER_PERFCTR_L1_DCACHE_MISS_ST			0xE9
+#define ARMV8_THUNDER_PERFCTR_L1_DCACHE_PREF_ACCESS		0xea
+#define ARMV8_THUNDER_PERFCTR_L1_DCACHE_PREF_MISS		0xeb
+#define ARMV8_THUNDER_PERFCTR_L1_ICACHE_PREF_ACCESS		0xec
+#define ARMV8_THUNDER_PERFCTR_L1_ICACHE_PREF_MISS		0xed
 
 /* PMUv3 HW events mapping. */
 static const unsigned armv8_pmuv3_perf_map[PERF_COUNT_HW_MAX] = {
@@ -131,6 +140,18 @@ static const unsigned armv8_a57_perf_map[PERF_COUNT_HW_MAX] = {
 	[PERF_COUNT_HW_BUS_CYCLES]		= ARMV8_PMUV3_PERFCTR_BUS_CYCLES,
 };
 
+static const unsigned armv8_thunder_perf_map[PERF_COUNT_HW_MAX] = {
+	PERF_MAP_ALL_UNSUPPORTED,
+	[PERF_COUNT_HW_CPU_CYCLES]		= ARMV8_PMUV3_PERFCTR_CLOCK_CYCLES,
+	[PERF_COUNT_HW_INSTRUCTIONS]		= ARMV8_PMUV3_PERFCTR_INSTR_EXECUTED,
+	[PERF_COUNT_HW_CACHE_REFERENCES]	= ARMV8_PMUV3_PERFCTR_L1_DCACHE_ACCESS,
+	[PERF_COUNT_HW_CACHE_MISSES]		= ARMV8_PMUV3_PERFCTR_L1_DCACHE_REFILL,
+	[PERF_COUNT_HW_BRANCH_INSTRUCTIONS]	= ARMV8_PMUV3_PERFCTR_PC_WRITE,
+	[PERF_COUNT_HW_BRANCH_MISSES]		= ARMV8_PMUV3_PERFCTR_PC_BRANCH_MIS_PRED,
+	[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = ARMV8_PMUV3_PERFCTR_STALL_FRONTEND,
+	[PERF_COUNT_HW_STALLED_CYCLES_BACKEND]	= ARMV8_PMUV3_PERFCTR_STALL_BACKEND,
+};
+
 static const unsigned armv8_pmuv3_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
 						[PERF_COUNT_HW_CACHE_OP_MAX]
 						[PERF_COUNT_HW_CACHE_RESULT_MAX] = {
@@ -193,6 +214,36 @@ static const unsigned armv8_a57_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
 	[C(BPU)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_PC_BRANCH_MIS_PRED,
 };
 
+static const unsigned armv8_thunder_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
+						   [PERF_COUNT_HW_CACHE_OP_MAX]
+						   [PERF_COUNT_HW_CACHE_RESULT_MAX] = {
+	PERF_CACHE_MAP_ALL_UNSUPPORTED,
+
+	[C(L1D)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_IMPDEF_PERFCTR_L1_DCACHE_ACCESS_LD,
+	[C(L1D)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_IMPDEF_PERFCTR_L1_DCACHE_REFILL_LD,
+	[C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)]	= ARMV8_IMPDEF_PERFCTR_L1_DCACHE_ACCESS_ST,
+	[C(L1D)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_THUNDER_PERFCTR_L1_DCACHE_MISS_ST,
+	[C(L1D)][C(OP_PREFETCH)][C(RESULT_ACCESS)] = ARMV8_THUNDER_PERFCTR_L1_DCACHE_PREF_ACCESS,
+	[C(L1D)][C(OP_PREFETCH)][C(RESULT_MISS)] = ARMV8_THUNDER_PERFCTR_L1_DCACHE_PREF_MISS,
+
+	[C(L1I)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_L1_ICACHE_ACCESS,
+	[C(L1I)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_L1_ICACHE_REFILL,
+	[C(L1I)][C(OP_PREFETCH)][C(RESULT_ACCESS)] = ARMV8_THUNDER_PERFCTR_L1_ICACHE_PREF_ACCESS,
+	[C(L1I)][C(OP_PREFETCH)][C(RESULT_MISS)] = ARMV8_THUNDER_PERFCTR_L1_ICACHE_PREF_MISS,
+
+	[C(DTLB)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_IMPDEF_PERFCTR_DTLB_ACCESS_LD,
+	[C(DTLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_IMPDEF_PERFCTR_DTLB_REFILL_LD,
+	[C(DTLB)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_IMPDEF_PERFCTR_DTLB_ACCESS_ST,
+	[C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_IMPDEF_PERFCTR_DTLB_REFILL_ST,
+
+	[C(ITLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_ITLB_REFILL,
+
+	[C(BPU)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_PC_BRANCH_PRED,
+	[C(BPU)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_PC_BRANCH_MIS_PRED,
+	[C(BPU)][C(OP_WRITE)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_PC_BRANCH_PRED,
+	[C(BPU)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_PC_BRANCH_MIS_PRED,
+};
+
 #define ARMV8_EVENT_ATTR_RESOLVE(m) #m
 #define ARMV8_EVENT_ATTR(name, config) \
 	PMU_EVENT_ATTR_STRING(name, armv8_event_attr_##name, \
@@ -324,7 +375,6 @@ static const struct attribute_group *armv8_pmuv3_attr_groups[] = {
 	NULL,
 };
 
-
 /*
  * Perf Events' indices
  */
@@ -743,6 +793,13 @@ static int armv8_a57_map_event(struct perf_event *event)
 				ARMV8_EVTYPE_EVENT);
 }
 
+static int armv8_thunder_map_event(struct perf_event *event)
+{
+	return armpmu_map_event(event, &armv8_thunder_perf_map,
+				&armv8_thunder_perf_cache_map,
+				ARMV8_EVTYPE_EVENT);
+}
+
 static void armv8pmu_read_num_pmnc_events(void *info)
 {
 	int *nb_cnt = info;
@@ -811,11 +868,21 @@ static int armv8_a72_pmu_init(struct arm_pmu *cpu_pmu)
 	return armv8pmu_probe_num_events(cpu_pmu);
 }
 
+static int armv8_thunder_pmu_init(struct arm_pmu *cpu_pmu)
+{
+	armv8_pmu_init(cpu_pmu);
+	cpu_pmu->name			= "armv8_cavium_thunder";
+	cpu_pmu->map_event		= armv8_thunder_map_event;
+	cpu_pmu->pmu.attr_groups	= armv8_pmuv3_attr_groups;
+	return armv8pmu_probe_num_events(cpu_pmu);
+}
+
 static const struct of_device_id armv8_pmu_of_device_ids[] = {
 	{.compatible = "arm,armv8-pmuv3",	.data = armv8_pmuv3_init},
 	{.compatible = "arm,cortex-a53-pmu",	.data = armv8_a53_pmu_init},
 	{.compatible = "arm,cortex-a57-pmu",	.data = armv8_a57_pmu_init},
 	{.compatible = "arm,cortex-a72-pmu",	.data = armv8_a72_pmu_init},
+	{.compatible = "cavium,thunder-pmu",	.data = armv8_thunder_pmu_init},
 	{},
 };
 
-- 
1.9.1



From jglauber at cavium.com  Thu Feb 18 08:50:10 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Thu, 18 Feb 2016 17:50:10 +0100
Subject: [PATCH v4 1/5] arm64/perf: Rename Cortex A57 events
In-Reply-To: <cover.1455810755.git.jglauber@cavium.com>
References: <cover.1455810755.git.jglauber@cavium.com>
Message-ID: <f974b2901758c907119aaf453f8730be8c9aca59.1455810755.git.jglauber@cavium.com>

The implemented Cortex A57 events are strictly-speaking not
A57 specific. They are ARM recommended implementation defined events
and can be found on other ARMv8 SOCs like Cavium ThunderX too.

Therefore rename these events to allow using them in other
implementations too.

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 arch/arm64/kernel/perf_event.c | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index f7ab14c..2adbcb5 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -90,13 +90,13 @@
 /* ARMv8 Cortex-A53 specific event types. */
 #define ARMV8_A53_PERFCTR_PREFETCH_LINEFILL			0xC2
 
-/* ARMv8 Cortex-A57 and Cortex-A72 specific event types. */
-#define ARMV8_A57_PERFCTR_L1_DCACHE_ACCESS_LD			0x40
-#define ARMV8_A57_PERFCTR_L1_DCACHE_ACCESS_ST			0x41
-#define ARMV8_A57_PERFCTR_L1_DCACHE_REFILL_LD			0x42
-#define ARMV8_A57_PERFCTR_L1_DCACHE_REFILL_ST			0x43
-#define ARMV8_A57_PERFCTR_DTLB_REFILL_LD			0x4c
-#define ARMV8_A57_PERFCTR_DTLB_REFILL_ST			0x4d
+/* ARMv8 implementation defined event types. */
+#define ARMV8_IMPDEF_PERFCTR_L1_DCACHE_ACCESS_LD		0x40
+#define ARMV8_IMPDEF_PERFCTR_L1_DCACHE_ACCESS_ST		0x41
+#define ARMV8_IMPDEF_PERFCTR_L1_DCACHE_REFILL_LD		0x42
+#define ARMV8_IMPDEF_PERFCTR_L1_DCACHE_REFILL_ST		0x43
+#define ARMV8_IMPDEF_PERFCTR_DTLB_REFILL_LD			0x4c
+#define ARMV8_IMPDEF_PERFCTR_DTLB_REFILL_ST			0x4d
 
 /* PMUv3 HW events mapping. */
 static const unsigned armv8_pmuv3_perf_map[PERF_COUNT_HW_MAX] = {
@@ -174,16 +174,16 @@ static const unsigned armv8_a57_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
 					      [PERF_COUNT_HW_CACHE_RESULT_MAX] = {
 	PERF_CACHE_MAP_ALL_UNSUPPORTED,
 
-	[C(L1D)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_A57_PERFCTR_L1_DCACHE_ACCESS_LD,
-	[C(L1D)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_A57_PERFCTR_L1_DCACHE_REFILL_LD,
-	[C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)]	= ARMV8_A57_PERFCTR_L1_DCACHE_ACCESS_ST,
-	[C(L1D)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_A57_PERFCTR_L1_DCACHE_REFILL_ST,
+	[C(L1D)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_IMPDEF_PERFCTR_L1_DCACHE_ACCESS_LD,
+	[C(L1D)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_IMPDEF_PERFCTR_L1_DCACHE_REFILL_LD,
+	[C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)]	= ARMV8_IMPDEF_PERFCTR_L1_DCACHE_ACCESS_ST,
+	[C(L1D)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_IMPDEF_PERFCTR_L1_DCACHE_REFILL_ST,
 
 	[C(L1I)][C(OP_READ)][C(RESULT_ACCESS)]	= ARMV8_PMUV3_PERFCTR_L1_ICACHE_ACCESS,
 	[C(L1I)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_L1_ICACHE_REFILL,
 
-	[C(DTLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_A57_PERFCTR_DTLB_REFILL_LD,
-	[C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_A57_PERFCTR_DTLB_REFILL_ST,
+	[C(DTLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_IMPDEF_PERFCTR_DTLB_REFILL_LD,
+	[C(DTLB)][C(OP_WRITE)][C(RESULT_MISS)]	= ARMV8_IMPDEF_PERFCTR_DTLB_REFILL_ST,
 
 	[C(ITLB)][C(OP_READ)][C(RESULT_MISS)]	= ARMV8_PMUV3_PERFCTR_ITLB_REFILL,
 
-- 
1.9.1



From jglauber at cavium.com  Thu Feb 18 08:50:12 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Thu, 18 Feb 2016 17:50:12 +0100
Subject: [PATCH v4 3/5] arm64: dts: Add Cavium ThunderX specific PMU
In-Reply-To: <cover.1455810755.git.jglauber@cavium.com>
References: <cover.1455810755.git.jglauber@cavium.com>
Message-ID: <2b8c963d3e63ecfc412bfd6fab804890a1586b16.1455810755.git.jglauber@cavium.com>

Add a compatible string for the Cavium ThunderX PMU.

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 Documentation/devicetree/bindings/arm/pmu.txt | 1 +
 arch/arm64/boot/dts/cavium/thunder-88xx.dtsi  | 5 +++++
 2 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt
index 5651883..d3999a1 100644
--- a/Documentation/devicetree/bindings/arm/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/pmu.txt
@@ -25,6 +25,7 @@ Required properties:
 	"qcom,scorpion-pmu"
 	"qcom,scorpion-mp-pmu"
 	"qcom,krait-pmu"
+	"cavium,thunder-pmu"
 - interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu
                interrupt (PPI) then 1 interrupt should be specified.
 
diff --git a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
index 9cb7cf9..2eb9b22 100644
--- a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
+++ b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
@@ -360,6 +360,11 @@
 		             <1 10 0xff01>;
 	};
 
+	pmu {
+		compatible = "cavium,thunder-pmu", "arm,armv8-pmuv3";
+		interrupts = <1 7 4>;
+	};
+
 	soc {
 		compatible = "simple-bus";
 		#address-cells = <2>;
-- 
1.9.1



From jglauber at cavium.com  Thu Feb 18 08:50:14 2016
From: jglauber at cavium.com (Jan Glauber)
Date: Thu, 18 Feb 2016 17:50:14 +0100
Subject: [PATCH v4 5/5] arm64/perf: Extend event mask for ARMv8.1
In-Reply-To: <cover.1455810755.git.jglauber@cavium.com>
References: <cover.1455810755.git.jglauber@cavium.com>
Message-ID: <028b5d83ded39048ec996fe4d4912702704f156b.1455810755.git.jglauber@cavium.com>

ARMv8.1 increases the PMU event number space to 16 bit so increase
the EVTYPE mask.

Signed-off-by: Jan Glauber <jglauber at cavium.com>
---
 arch/arm64/kernel/perf_event.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index c68fa98..8746781 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -419,8 +419,8 @@ static const struct attribute_group *armv8_pmuv3_attr_groups[] = {
 /*
  * PMXEVTYPER: Event selection reg
  */
-#define	ARMV8_EVTYPE_MASK	0xc80003ff	/* Mask for writable bits */
-#define	ARMV8_EVTYPE_EVENT	0x3ff		/* Mask for EVENT bits */
+#define	ARMV8_EVTYPE_MASK	0xc800ffff	/* Mask for writable bits */
+#define	ARMV8_EVTYPE_EVENT	0xffff		/* Mask for EVENT bits */
 
 /*
  * Event filters for PMUv3
-- 
1.9.1



From peter at hurleysoftware.com  Thu Feb 18 08:50:56 2016
From: peter at hurleysoftware.com (Peter Hurley)
Date: Thu, 18 Feb 2016 08:50:56 -0800
Subject: [PATCH v2] serial: xuartps: Enable OF earlycon support
In-Reply-To: <09f2c419994281fca7968142e52d969542370d1c.1455782238.git.michal.simek@xilinx.com>
References: <09f2c419994281fca7968142e52d969542370d1c.1455782238.git.michal.simek@xilinx.com>
Message-ID: <56C5F670.50005@hurleysoftware.com>

On 02/17/2016 11:57 PM, Michal Simek wrote:
> Support early console setup via DT for all listed compatible strings.
> Remove EARLYCON_DECLARE which was done by:
> "Use common framework for earlycon declarations"
> (sha1: 2eaa790989e03900298ad24f77f1086dbbc1aebd)
> when OF_EARLYCON_DECLARE is defined.

Reviewed-by: Peter Hurley <peter at hurleysoftware.com>



From marc.zyngier at arm.com  Thu Feb 18 08:51:05 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Thu, 18 Feb 2016 16:51:05 +0000
Subject: [RFC v3 07/15] iommu: iommu_get/put_single_reserved
In-Reply-To: <56C5F472.1020003@linaro.org>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
 <1455264797-2334-8-git-send-email-eric.auger@linaro.org>
 <20160218110616.05108071@arm.com> <56C5F472.1020003@linaro.org>
Message-ID: <56C5F679.8000002@arm.com>

On 18/02/16 16:42, Eric Auger wrote:
> Hello,
> On 02/18/2016 12:06 PM, Marc Zyngier wrote:
>> On Fri, 12 Feb 2016 08:13:09 +0000
>> Eric Auger <eric.auger at linaro.org> wrote:
>>
>>> This patch introduces iommu_get/put_single_reserved.
>>>
>>> iommu_get_single_reserved allows to allocate a new reserved iova page
>>> and map it onto the physical page that contains a given physical address.
>>> It returns the iova that is mapped onto the provided physical address.
>>> Hence the physical address passed in argument does not need to be aligned.
>>>
>>> In case a mapping already exists between both pages, the IOVA mapped
>>> to the PA is directly returned.
>>>
>>> Each time an iova is successfully returned a binding ref count is
>>> incremented.
>>>
>>> iommu_put_single_reserved decrements the ref count and when this latter
>>> is null, the mapping is destroyed and the iova is released.
>>
>> I wonder if there is a requirement for the caller to find out about the
>> size of the mapping, or to impose a given size... MSIs clearly do not
>> have that requirement (this is always a 32bit value), but since. 
>> allocations usually pair address and size, I though I'd ask...
> Yes. Currently this only makes sure the host PA is mapped and returns
> the corresponding IOVA. It is part of the discussion we need to have on
> the API besides the problematic of which API it should belong to.

One of the issues I have with the API at the moment is that there is no
control on the page size. Imagine you have allocated a 4kB IOVA window
for your MSI, but your IOMMU can only map 64kB (not unreasonable to
imagine on arm64). What happens then?

Somehow, userspace should be told about it, one way or another.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From p.zabel at pengutronix.de  Thu Feb 18 08:50:51 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 18 Feb 2016 17:50:51 +0100
Subject: [PATCH v8 3/5] memory: mediatek: Add SMI driver
In-Reply-To: <20160216162641.GY18805@8bytes.org>
References: <1453781562-23556-1-git-send-email-yong.wu@mediatek.com>
 <1453781562-23556-4-git-send-email-yong.wu@mediatek.com>
 <56ADE959.2050309@gmail.com> <20160216141059.GT18805@8bytes.org>
 <56C340FB.1050607@arm.com> <20160216161009.GW18805@8bytes.org>
 <20160216162000.GI14509@arm.com> <20160216162641.GY18805@8bytes.org>
Message-ID: <1455814251.3937.27.camel@pengutronix.de>

Hi Joerg,

Am Dienstag, den 16.02.2016, 17:26 +0100 schrieb Joerg Roedel:
> On Tue, Feb 16, 2016 at 04:20:00PM +0000, Will Deacon wrote:
> > I'm more than happy to bake a branch containing all the page table stuff,
> > but Yong's stuff depends on it so I'll work with whatever is easiest for
> > you.
> 
> Okay, to the best is if you would collect all the page table patches and
> send me a pull-request. I pull that into my tree then and put Yong's
> stuff on-top.

could you provide a branch that I may then pull in, stack the
mediatek-drm driver patches (that depend on the SMI driver) on top and
have them merged via drm-next?

regards
Philipp



From frank.li at nxp.com  Thu Feb 18 08:56:22 2016
From: frank.li at nxp.com (Frank Li)
Date: Thu, 18 Feb 2016 16:56:22 +0000
Subject: iMX7d cpu1 issue
In-Reply-To: <56C5F4D7.1070704@compulab.co.il>
References: <56C2D63F.1030408@compulab.co.il> <20160218140913.GY6756@tiger>
 <AMSPR04MB263D00A3F8D9A8D9D3A536D88AF0@AMSPR04MB263.eurprd04.prod.outlook.com>
 <56C5F4D7.1070704@compulab.co.il>
Message-ID: <AMSPR04MB26334EB884FA8A4B565278188AF0@AMSPR04MB263.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Ilya Ledvich [mailto:ilya at compulab.co.il]
> Sent: Thursday, February 18, 2016 10:44 AM
> To: Frank Li <frank.li at nxp.com>; Shawn Guo <shawnguo at kernel.org>
> Cc: linux-arm-kernel at lists.infradead.org; Yongcai Huang
> <anson.huang at nxp.com>
> Subject: Re: iMX7d cpu1 issue
> 
> Hi!
> 
> On 02/18/2016 05:24 PM, Frank Li wrote:
> >
> >
> >> -----Original Message-----
> >> From: Shawn Guo [mailto:shawnguo at kernel.org]
> >> Sent: Thursday, February 18, 2016 8:09 AM
> >> To: Ilya Ledvich <ilya at compulab.co.il>
> >> Cc: linux-arm-kernel at lists.infradead.org; Frank Li
> >> <frank.li at nxp.com>; Yongcai Huang <anson.huang at nxp.com>
> >> Subject: Re: iMX7d cpu1 issue
> >>
> >> On Tue, Feb 16, 2016 at 09:56:47AM +0200, Ilya Ledvich wrote:
> >>> Hi Shawn,
> >>> I'm working on Compulab CL-SOM-IMX7 device
> >>> (http://www.compulab.co.il/products/computer-on-modules/cl-som-
> >> imx7-fr
> >>> eescale-i-mx-7-system-on-module)
> >>> based on Freescale iMX7d CPU.
> >>> I use the Freescale latest BSP imx_3.14.52_1.1.0_ga  and the Linux
> >>> mainline v4.4-rc6 as a reference.
> >>> I observe an issue with bringing up the second CPU core. Briefly,
> >>> the kernel can successfully boot only when CPU1 fails to come online.
> >>> In this case the boot log shows the following messages:
> >>> ...
> >>> CPU1: failed to come online
> >>> Brought up 1 CPUs
> >>> SMP: Total of 1 processors activated (6.00 BogoMIPS).
> >>> ...
> >>>
> >>> Otherwise, the device tries to start kernel several times until the
> >>> boot process eventually crashes. Please see attached logs for more
> >>> details.
> >>> This never happens on mainline Linus kernel, because it never tries
> >>> to bring up CPU1.
> >>> Unfortunately, we cannot verify this behavior on reference board
> >>> cause we have no one.
> >>> Have you ever seen such behavior? Could you please advice something?
> >
> > Did you set arm,cpu-registers-not-fw-configured; in arch timer?
> 
> Yes, it's set in the imx7d.dtsi file included by my device .dts.
> 
> > How about your uboot version?
> >
> > Latest upstream uboot already boot A7 as no-security mode.
> 
> I actually use v2016.01 from the upstream and u-boot sources are based on
> on mx7dsabresd.c.

Can you try to disable NOSEC?

#define CONFIG_MX7_SEC

include/configs/mx7_common.h

Best regards
Frank Li

> 
> >
> > Best regards
> > Frank Li
> >
> 
> Kind regards,
> Ilya.


From eric.auger at linaro.org  Thu Feb 18 08:58:45 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 18 Feb 2016 17:58:45 +0100
Subject: [RFC v3 15/15] irqchip/gicv2m/v3-its-pci-msi: IOMMU map the MSI
 frame when needed
In-Reply-To: <56C5E787.9070303@arm.com>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
 <1455264797-2334-16-git-send-email-eric.auger@linaro.org>
 <20160218113307.2b263b10@arm.com> <56C5E450.3010501@linaro.org>
 <56C5E787.9070303@arm.com>
Message-ID: <56C5F845.7020408@linaro.org>

Hi Marc,
On 02/18/2016 04:47 PM, Marc Zyngier wrote:
> On 18/02/16 15:33, Eric Auger wrote:
>> Hi Marc,
>> On 02/18/2016 12:33 PM, Marc Zyngier wrote:
>>> On Fri, 12 Feb 2016 08:13:17 +0000
>>> Eric Auger <eric.auger at linaro.org> wrote:
>>>
>>>> In case the msi_desc references a device attached to an iommu
>>>> domain, the msi address needs to be mapped in the IOMMU. Else any
>>>> MSI write transaction will cause a fault.
>>>>
>>>> gic_set_msi_addr detects that case and allocates an iova bound
>>>> to the physical address page comprising the MSI frame. This iova
>>>> then is used as the msi_msg address. Unset operation decrements the
>>>> reference on the binding.
>>>>
>>>> The functions are called in the irq_write_msi_msg ops implementation.
>>>> At that time we can recognize whether the msi is setup or teared down
>>>> looking at the msi_msg content. Indeed msi_domain_deactivate zeroes all
>>>> the fields.
>>>>
>>>> Signed-off-by: Eric Auger <eric.auger at linaro.org>
>>>>
>>>> ---
>>>>
>>>> v2 -> v3:
>>>> - protect iova/addr manipulation with CONFIG_ARCH_DMA_ADDR_T_64BIT and
>>>>   CONFIG_PHYS_ADDR_T_64BIT
>>>> - only expose gic_pci_msi_domain_write_msg in case CONFIG_IOMMU_API &
>>>>   CONFIG_PCI_MSI_IRQ_DOMAIN are set.
>>>> - gic_set/unset_msi_addr duly become static
>>>> ---
>>>>  drivers/irqchip/irq-gic-common.c         | 69 ++++++++++++++++++++++++++++++++
>>>>  drivers/irqchip/irq-gic-common.h         |  5 +++
>>>>  drivers/irqchip/irq-gic-v2m.c            |  7 +++-
>>>>  drivers/irqchip/irq-gic-v3-its-pci-msi.c |  5 +++
>>>>  4 files changed, 85 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
>>>> index f174ce0..46cd06c 100644
>>>> --- a/drivers/irqchip/irq-gic-common.c
>>>> +++ b/drivers/irqchip/irq-gic-common.c
>>>> @@ -18,6 +18,8 @@
>>>>  #include <linux/io.h>
>>>>  #include <linux/irq.h>
>>>>  #include <linux/irqchip/arm-gic.h>
>>>> +#include <linux/iommu.h>
>>>> +#include <linux/msi.h>
>>>>  
>>>>  #include "irq-gic-common.h"
>>>>  
>>>> @@ -121,3 +123,70 @@ void gic_cpu_config(void __iomem *base, void (*sync_access)(void))
>>>>  	if (sync_access)
>>>>  		sync_access();
>>>>  }
>>>> +
>>>> +#if defined(CONFIG_IOMMU_API) && defined(CONFIG_PCI_MSI_IRQ_DOMAIN)
>>>> +static int gic_set_msi_addr(struct irq_data *data, struct msi_msg *msg)
>>>> +{
>>>> +	struct msi_desc *desc = irq_data_get_msi_desc(data);
>>>> +	struct device *dev = msi_desc_to_dev(desc);
>>>> +	struct iommu_domain *d;
>>>> +	phys_addr_t addr;
>>>> +	dma_addr_t iova;
>>>> +	int ret;
>>>> +
>>>> +	d = iommu_get_domain_for_dev(dev);
>>>> +	if (!d)
>>>> +		return 0;
>>>> +#ifdef CONFIG_PHYS_ADDR_T_64BIT
>>>> +	addr = ((phys_addr_t)(msg->address_hi) << 32) | msg->address_lo;
>>>> +#else
>>>> +	addr = msg->address_lo;
>>>> +#endif
>>>> +
>>>> +	ret = iommu_get_single_reserved(d, addr, IOMMU_WRITE, &iova);
>>>> +
>>>> +	if (!ret) {
>>>> +		msg->address_lo = lower_32_bits(iova);
>>>> +		msg->address_hi = upper_32_bits(iova);
>>>> +	}
>>>> +	return ret;
>>>> +}
>>>> +
>>>> +
>>>> +static void gic_unset_msi_addr(struct irq_data *data)
>>>> +{
>>>> +	struct msi_desc *desc = irq_data_get_msi_desc(data);
>>>> +	struct device *dev;
>>>> +	struct iommu_domain *d;
>>>> +	dma_addr_t iova;
>>>> +
>>>> +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>>>> +	iova = ((dma_addr_t)(desc->msg.address_hi) << 32) |
>>>> +		desc->msg.address_lo;
>>>> +#else
>>>> +	iova = desc->msg.address_lo;
>>>> +#endif
>>>> +
>>>> +	dev = msi_desc_to_dev(desc);
>>>> +	if (!dev)
>>>> +		return;
>>>> +
>>>> +	d = iommu_get_domain_for_dev(dev);
>>>> +	if (!d)
>>>> +		return;
>>>> +
>>>> +	iommu_put_single_reserved(d, iova);
>>>> +}
>>>> +
>>>> +void gic_pci_msi_domain_write_msg(struct irq_data *irq_data,
>>>> +				  struct msi_msg *msg)
>>>> +{
>>>> +	if (!msg->address_hi && !msg->address_lo && !msg->data)
>>>> +		gic_unset_msi_addr(irq_data); /* deactivate */
>>>> +	else
>>>> +		gic_set_msi_addr(irq_data, msg); /* activate, set_affinity */
>>>> +
>>>> +	pci_msi_domain_write_msg(irq_data, msg);
>>>> +}
>>>
>>> So by doing that, you are specializing this infrastructure to PCI.
>>> If you hijacked irq_compose_msi_msg() instead, you'd have both
>>> platform and PCI MSI for the same price.
>>>
>>> I can see a potential problem with the teardown of an MSI (I don't
>>> think the compose method is called on teardown), but I think this could
>>> be easily addressed.
>> Yes effectively this is the reason why I moved it from
>> irq_compose_msi_msg (my original implementation) to irq_write_msi_msg. I
>> noticed I had no way to detect the teardown whereas the
>> msi_domain_deactivate also calls irq_write_msi_msg which is quite
>> practical ;-) To be honest I need to further look at the non PCI
>> implementation.
> 
> Another thing to consider is that MSI controllers may use different
> doorbells for different CPU affinities.

OK thanks for pointing this out.

This is also a good confirmation that a single IOVA address is not
always sufficient (at some point we wondered if we could directly use
the MSI controller guest PA instead of having the user-space providing
an IOVA pool)

 With your implementation,
> repeatedly changing the affinity from one CPU to another would increase
> the refcounting, and never actually lower it (you don't necessarily go
> via an "unmap").

 Of course, none of that applies to GICv2m/GICv3-ITS,
> but that's worth considering.
> 
> So I think we may need some better tracking of the IOVA we program in
> the device, and offer a generic infrastructure for this instead of
> hiding it in the MSI controller drivers.
OK I will study that.

Thanks for your time!

Eric
> 
> Thanks,
> 
> 	M.
> 



From arnd at arndb.de  Thu Feb 18 09:05:06 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 18:05:06 +0100
Subject: [PATCH 0/3] ARM llvmlinux/clang build errors
Message-ID: <1455815113-2562966-1-git-send-email-arnd@arndb.de>

These three patches address build errors I got while testing with
clang. I've sent them two weeks ago but got no reply. Resending
wiht a couple more people on Cc this time.

	Arnd



From arnd at arndb.de  Thu Feb 18 09:05:07 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 18:05:07 +0100
Subject: [PATCH 1/3] [RESEND] ARM: pass -march=armv7-a when building NEON
 files with clang
In-Reply-To: <1455815113-2562966-1-git-send-email-arnd@arndb.de>
References: <1455815113-2562966-1-git-send-email-arnd@arndb.de>
Message-ID: <1455815113-2562966-2-git-send-email-arnd@arndb.de>

clang ignores the -mfpu=neon flag when building with -march=armv6:

In file included from lib/raid6/neon1.c:27:
clang/3.8.0/include/arm_neon.h:28:2: error: "NEON support not enabled"

There is no real need to build the file with -march=armv6 in a
multi-CPU enabled kernel, as nothing in here will ever get called
on an ARMv6 CPU. Adding -march=armv7 doesn't hurt and can only
improve the code quality.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/lib/Makefile | 2 +-
 lib/raid6/Makefile    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index d8a780799506..a86c6c8e0648 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -35,7 +35,7 @@ $(obj)/csumpartialcopy.o:	$(obj)/csumpartialcopygeneric.S
 $(obj)/csumpartialcopyuser.o:	$(obj)/csumpartialcopygeneric.S
 
 ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
-  NEON_FLAGS			:= -mfloat-abi=softfp -mfpu=neon
+  NEON_FLAGS			:= -mfloat-abi=softfp -mfpu=neon -march=armv7-a
   CFLAGS_xor-neon.o		+= $(NEON_FLAGS)
   obj-$(CONFIG_XOR_BLOCKS)	+= xor-neon.o
 endif
diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
index 3b10a48fa040..4ef3e800fb39 100644
--- a/lib/raid6/Makefile
+++ b/lib/raid6/Makefile
@@ -23,7 +23,7 @@ endif
 ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
 NEON_FLAGS := -ffreestanding
 ifeq ($(ARCH),arm)
-NEON_FLAGS += -mfloat-abi=softfp -mfpu=neon
+NEON_FLAGS += -mfloat-abi=softfp -mfpu=neon -march=armv7-a
 endif
 ifeq ($(ARCH),arm64)
 CFLAGS_REMOVE_neon1.o += -mgeneral-regs-only
-- 
2.7.0



From arnd at arndb.de  Thu Feb 18 09:05:08 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 18:05:08 +0100
Subject: [PATCH 2/3] [RESEND] ARM: fix copypage-*.c building with clang
In-Reply-To: <1455815113-2562966-1-git-send-email-arnd@arndb.de>
References: <1455815113-2562966-1-git-send-email-arnd@arndb.de>
Message-ID: <1455815113-2562966-3-git-send-email-arnd@arndb.de>

clang does not allow inline assembly in __naked functions to
have any register parameters and throws an error:

arch/arm/mm/copypage-v4wb.c:47:9: error: parameter references not allowed in naked functions
        : "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64));

Fortunately, all of these functions are trivial to convert to
using the registers directly.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mm/copypage-feroceon.c |  4 ++--
 arch/arm/mm/copypage-v4mc.c     | 26 +++++++++++++-------------
 arch/arm/mm/copypage-v4wb.c     |  4 ++--
 arch/arm/mm/copypage-v4wt.c     |  4 ++--
 arch/arm/mm/copypage-xsc3.c     |  4 ++--
 arch/arm/mm/copypage-xscale.c   |  4 ++--
 6 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mm/copypage-feroceon.c b/arch/arm/mm/copypage-feroceon.c
index 49ee0c1a7209..e69bf2f15f32 100644
--- a/arch/arm/mm/copypage-feroceon.c
+++ b/arch/arm/mm/copypage-feroceon.c
@@ -18,7 +18,7 @@ feroceon_copy_user_page(void *kto, const void *kfrom)
 {
 	asm("\
 	stmfd	sp!, {r4-r9, lr}		\n\
-	mov	ip, %2				\n\
+	mov	ip, %0				\n\
 1:	mov	lr, r1				\n\
 	ldmia	r1!, {r2 - r9}			\n\
 	pld	[lr, #32]			\n\
@@ -64,7 +64,7 @@ feroceon_copy_user_page(void *kto, const void *kfrom)
 	mcr	p15, 0, ip, c7, c10, 4		@ drain WB\n\
 	ldmfd	sp!, {r4-r9, pc}"
 	:
-	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE));
+	: "I" (PAGE_SIZE));
 }
 
 void feroceon_copy_user_highpage(struct page *to, struct page *from,
diff --git a/arch/arm/mm/copypage-v4mc.c b/arch/arm/mm/copypage-v4mc.c
index 1267e64133b9..ea89722c00db 100644
--- a/arch/arm/mm/copypage-v4mc.c
+++ b/arch/arm/mm/copypage-v4mc.c
@@ -45,23 +45,23 @@ mc_copy_user_page(void *from, void *to)
 {
 	asm volatile(
 	"stmfd	sp!, {r4, lr}			@ 2\n\
-	mov	r4, %2				@ 1\n\
-	ldmia	%0!, {r2, r3, ip, lr}		@ 4\n\
-1:	mcr	p15, 0, %1, c7, c6, 1		@ 1   invalidate D line\n\
-	stmia	%1!, {r2, r3, ip, lr}		@ 4\n\
-	ldmia	%0!, {r2, r3, ip, lr}		@ 4+1\n\
-	stmia	%1!, {r2, r3, ip, lr}		@ 4\n\
-	ldmia	%0!, {r2, r3, ip, lr}		@ 4\n\
-	mcr	p15, 0, %1, c7, c6, 1		@ 1   invalidate D line\n\
-	stmia	%1!, {r2, r3, ip, lr}		@ 4\n\
-	ldmia	%0!, {r2, r3, ip, lr}		@ 4\n\
+	mov	r4, %0				@ 1\n\
+	ldmia	r0!, {r2, r3, ip, lr}		@ 4\n\
+1:	mcr	p15, 0, r1, c7, c6, 1		@ 1   invalidate D line\n\
+	stmia	r1!, {r2, r3, ip, lr}		@ 4\n\
+	ldmia	r0!, {r2, r3, ip, lr}		@ 4+1\n\
+	stmia	r1!, {r2, r3, ip, lr}		@ 4\n\
+	ldmia	r0!, {r2, r3, ip, lr}		@ 4\n\
+	mcr	p15, 0, r1, c7, c6, 1		@ 1   invalidate D line\n\
+	stmia	r1!, {r2, r3, ip, lr}		@ 4\n\
+	ldmia	r0!, {r2, r3, ip, lr}		@ 4\n\
 	subs	r4, r4, #1			@ 1\n\
-	stmia	%1!, {r2, r3, ip, lr}		@ 4\n\
-	ldmneia	%0!, {r2, r3, ip, lr}		@ 4\n\
+	stmia	r1!, {r2, r3, ip, lr}		@ 4\n\
+	ldmneia	r0!, {r2, r3, ip, lr}		@ 4\n\
 	bne	1b				@ 1\n\
 	ldmfd	sp!, {r4, pc}			@ 3"
 	:
-	: "r" (from), "r" (to), "I" (PAGE_SIZE / 64));
+	: "I" (PAGE_SIZE / 64));
 }
 
 void v4_mc_copy_user_highpage(struct page *to, struct page *from,
diff --git a/arch/arm/mm/copypage-v4wb.c b/arch/arm/mm/copypage-v4wb.c
index 067d0fdd630c..7ea9cf07bd5c 100644
--- a/arch/arm/mm/copypage-v4wb.c
+++ b/arch/arm/mm/copypage-v4wb.c
@@ -27,7 +27,7 @@ v4wb_copy_user_page(void *kto, const void *kfrom)
 {
 	asm("\
 	stmfd	sp!, {r4, lr}			@ 2\n\
-	mov	r2, %2				@ 1\n\
+	mov	r2, %0				@ 1\n\
 	ldmia	r1!, {r3, r4, ip, lr}		@ 4\n\
 1:	mcr	p15, 0, r0, c7, c6, 1		@ 1   invalidate D line\n\
 	stmia	r0!, {r3, r4, ip, lr}		@ 4\n\
@@ -44,7 +44,7 @@ v4wb_copy_user_page(void *kto, const void *kfrom)
 	mcr	p15, 0, r1, c7, c10, 4		@ 1   drain WB\n\
 	ldmfd	 sp!, {r4, pc}			@ 3"
 	:
-	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64));
+	: "I" (PAGE_SIZE / 64));
 }
 
 void v4wb_copy_user_highpage(struct page *to, struct page *from,
diff --git a/arch/arm/mm/copypage-v4wt.c b/arch/arm/mm/copypage-v4wt.c
index b85c5da2e510..c742ab24efd6 100644
--- a/arch/arm/mm/copypage-v4wt.c
+++ b/arch/arm/mm/copypage-v4wt.c
@@ -25,7 +25,7 @@ v4wt_copy_user_page(void *kto, const void *kfrom)
 {
 	asm("\
 	stmfd	sp!, {r4, lr}			@ 2\n\
-	mov	r2, %2				@ 1\n\
+	mov	r2, %0				@ 1\n\
 	ldmia	r1!, {r3, r4, ip, lr}		@ 4\n\
 1:	stmia	r0!, {r3, r4, ip, lr}		@ 4\n\
 	ldmia	r1!, {r3, r4, ip, lr}		@ 4+1\n\
@@ -40,7 +40,7 @@ v4wt_copy_user_page(void *kto, const void *kfrom)
 	mcr	p15, 0, r2, c7, c7, 0		@ flush ID cache\n\
 	ldmfd	sp!, {r4, pc}			@ 3"
 	:
-	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64));
+	: "I" (PAGE_SIZE / 64));
 }
 
 void v4wt_copy_user_highpage(struct page *to, struct page *from,
diff --git a/arch/arm/mm/copypage-xsc3.c b/arch/arm/mm/copypage-xsc3.c
index 03a2042aced5..17e4e11c4612 100644
--- a/arch/arm/mm/copypage-xsc3.c
+++ b/arch/arm/mm/copypage-xsc3.c
@@ -34,7 +34,7 @@ xsc3_mc_copy_user_page(void *kto, const void *kfrom)
 {
 	asm("\
 	stmfd	sp!, {r4, r5, lr}		\n\
-	mov	lr, %2				\n\
+	mov	lr, %0				\n\
 						\n\
 	pld	[r1, #0]			\n\
 	pld	[r1, #32]			\n\
@@ -67,7 +67,7 @@ xsc3_mc_copy_user_page(void *kto, const void *kfrom)
 						\n\
 	ldmfd	sp!, {r4, r5, pc}"
 	:
-	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64 - 1));
+	: "I" (PAGE_SIZE / 64 - 1));
 }
 
 void xsc3_mc_copy_user_highpage(struct page *to, struct page *from,
diff --git a/arch/arm/mm/copypage-xscale.c b/arch/arm/mm/copypage-xscale.c
index 0fb85025344d..1034b4ce80cc 100644
--- a/arch/arm/mm/copypage-xscale.c
+++ b/arch/arm/mm/copypage-xscale.c
@@ -45,7 +45,7 @@ mc_copy_user_page(void *from, void *to)
 	 */
 	asm volatile(
 	"stmfd	sp!, {r4, r5, lr}		\n\
-	mov	lr, %2				\n\
+	mov	lr, %0				\n\
 	pld	[r0, #0]			\n\
 	pld	[r0, #32]			\n\
 	pld	[r1, #0]			\n\
@@ -81,7 +81,7 @@ mc_copy_user_page(void *from, void *to)
 	beq	2b				\n\
 	ldmfd	sp!, {r4, r5, pc}		"
 	:
-	: "r" (from), "r" (to), "I" (PAGE_SIZE / 64 - 1));
+	: "I" (PAGE_SIZE / 64 - 1));
 }
 
 void xscale_mc_copy_user_highpage(struct page *to, struct page *from,
-- 
2.7.0



From arnd at arndb.de  Thu Feb 18 09:05:09 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 18 Feb 2016 18:05:09 +0100
Subject: [PATCH 3/3] [RESEND] ARM: kprobes: use "I" constraint for inline
 assembly offsets
In-Reply-To: <1455815113-2562966-1-git-send-email-arnd@arndb.de>
References: <1455815113-2562966-1-git-send-email-arnd@arndb.de>
Message-ID: <1455815113-2562966-4-git-send-email-arnd@arndb.de>

build-testing with clang showed that the "J" constraint does not take
positive arguments on clang when building in for Thumb-2:

core.c:540:3: error: invalid operand for inline asm constraint 'J'

This has been reported as llvm bug https://llvm.org/bugs/show_bug.cgi?id=26061

However, looking at the source code in depth, I found that the
kernel is also wrong, and it should not use "J" at all, but should
use "I" to pass an immediate argument to the inline assembly when that
is used as an offset to an 'ldr' instruction rather than the 'sub'
argument.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/probes/kprobes/core.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
index a4ec240ee7ba..4b34b40ca917 100644
--- a/arch/arm/probes/kprobes/core.c
+++ b/arch/arm/probes/kprobes/core.c
@@ -570,10 +570,10 @@ void __kprobes jprobe_return(void)
 		:
 		: "r" (kcb->jprobe_saved_regs.ARM_sp),
 		  "I" (sizeof(struct pt_regs) * 2),
-		  "J" (offsetof(struct pt_regs, ARM_sp)),
-		  "J" (offsetof(struct pt_regs, ARM_pc)),
-		  "J" (offsetof(struct pt_regs, ARM_cpsr)),
-		  "J" (offsetof(struct pt_regs, ARM_lr))
+		  "I" (offsetof(struct pt_regs, ARM_sp)),
+		  "I" (offsetof(struct pt_regs, ARM_pc)),
+		  "I" (offsetof(struct pt_regs, ARM_cpsr)),
+		  "I" (offsetof(struct pt_regs, ARM_lr))
 		: "memory", "cc");
 }
 
-- 
2.7.0



From kirill at shutemov.name  Thu Feb 18 09:06:58 2016
From: kirill at shutemov.name (Kirill A. Shutemov)
Date: Thu, 18 Feb 2016 19:06:58 +0200
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160218160037.627cc7ec@thinkpad>
References: <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
 <alpine.LFD.2.20.1602131238260.1910@schleppi>
 <20160217201340.2dafad8d@thinkpad>
 <20160217235808.GA21696@node.shutemov.name>
 <20160218160037.627cc7ec@thinkpad>
Message-ID: <20160218170658.GC28184@node.shutemov.name>

On Thu, Feb 18, 2016 at 04:00:37PM +0100, Gerald Schaefer wrote:
> On Thu, 18 Feb 2016 01:58:08 +0200
> "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> 
> > On Wed, Feb 17, 2016 at 08:13:40PM +0100, Gerald Schaefer wrote:
> > > On Sat, 13 Feb 2016 12:58:31 +0100 (CET)
> > > Sebastian Ott <sebott at linux.vnet.ibm.com> wrote:
> > > 
> > > > [   59.875935] ------------[ cut here ]------------
> > > > [   59.875937] kernel BUG at mm/huge_memory.c:2884!
> > > > [   59.875979] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> > > > [   59.875986] Modules linked in: bridge stp llc btrfs xor mlx4_en vxlan ip6_udp_tunnel udp_tunnel mlx4_ib ptp pps_core ib_sa ib_mad ib_core ib_addr ghash_s390 prng raid6_pq ecb aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 mlx4_core sha_common genwqe_card scm_block crc_itu_t vhost_net tun vhost dm_mod macvtap eadm_sch macvlan kvm autofs4
> > > > [   59.876033] CPU: 2 PID: 5402 Comm: git Tainted: G        W       4.4.0-07794-ga4eff16-dirty #77
> > > > [   59.876036] task: 00000000d2312948 ti: 00000000cfecc000 task.ti: 00000000cfecc000
> > > > [   59.876039] Krnl PSW : 0704d00180000000 00000000002bf3aa (__split_huge_pmd_locked+0x562/0xa10)
> > > > [   59.876045]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
> > > >                Krnl GPRS: 0000000001a7a1cf 000003d10177c000 0000000000044068 000000005df00215
> > > > [   59.876051]            0000000000000001 0000000000000001 0000000000000000 00000000774e6900
> > > > [   59.876054]            000003ff52000000 000000006d403b10 000000006e1eb800 000003ff51f00000
> > > > [   59.876058]            000003d10177c000 0000000000715190 00000000002bf234 00000000cfecfb58
> > > > [   59.876068] Krnl Code: 00000000002bf39c: d507d010a000	clc	16(8,%%r13),0(%%r10)
> > > >                           00000000002bf3a2: a7840004		brc	8,2bf3aa
> > > >                          #00000000002bf3a6: a7f40001		brc	15,2bf3a8
> > > >                          >00000000002bf3aa: 91407440		tm	1088(%%r7),64
> > > >                           00000000002bf3ae: a7840208		brc	8,2bf7be
> > > >                           00000000002bf3b2: a7f401e9		brc	15,2bf784
> > > >                           00000000002bf3b6: 9104a006		tm	6(%%r10),4
> > > >                           00000000002bf3ba: a7740004		brc	7,2bf3c2
> > > > [   59.876089] Call Trace:
> > > > [   59.876092] ([<00000000002bf234>] __split_huge_pmd_locked+0x3ec/0xa10)
> > > > [   59.876095]  [<00000000002c4310>] __split_huge_pmd+0x118/0x218
> > > > [   59.876099]  [<00000000002810e8>] unmap_single_vma+0x2d8/0xb40
> > > > [   59.876102]  [<0000000000282d66>] zap_page_range+0x116/0x318
> > > > [   59.876105]  [<000000000029b834>] SyS_madvise+0x23c/0x5e8
> > > > [   59.876108]  [<00000000006f9f56>] system_call+0xd6/0x258
> > > > [   59.876111]  [<000003ff9bbfd282>] 0x3ff9bbfd282
> > > > [   59.876113] INFO: lockdep is turned off.
> > > > [   59.876115] Last Breaking-Event-Address:
> > > > [   59.876118]  [<00000000002bf3a6>] __split_huge_pmd_locked+0x55e/0xa10
> > > 
> > > The BUG at mm/huge_memory.c:2884 is interesting, it's the BUG_ON(!pte_none(*pte))
> > > check in __split_huge_pmd_locked(). Obviously we expect the pre-allocated
> > > pagetables to be empty, but in collapse_huge_page() we deposit the original
> > > pagetable instead of allocating a new (empty) one. This saves an allocation,
> > > which is good, but doesn't that mean that if such a collapsed hugepage will
> > > ever be split, we will always run into the BUG_ON(!pte_none(*pte)), or one
> > > of the two other VM_BUG_ONs in mm/huge_memory.c that check the same?
> > > 
> > > This behavior is not new, it was the same before the THP rework, so I do not
> > > assume that it is related to the current problems, maybe with the exception
> > > of this specific crash. I never saw the BUG at mm/huge_memory.c:2884 myself,
> > > and the other crashes probably cannot be explained with this. Maybe I am
> > > also missing something, but I do not see how collapse_huge_page() and the
> > > (non-empty) pgtable deposit there can work out with the BUG_ON(!pte_none(*pte))
> > > checks. Any thoughts?
> > 
> > I don't think there's a problem: ptes in the pgtable are cleared with
> > pte_clear() in __collapse_huge_page_copy().
> > 
> 
> Ah OK, I didn't see that. Still the BUG_ON() tells us that something went
> wrong with the pre-allocated pagetable, or at least with the deposit/withdraw
> list, or both. Given that on s390 we keep the listheads for the deposit/withdraw
> list inside the pre-allocated pgtables, instead of the struct pages, it may
> also explain why we see don't the problems on x86.
> 
> We already have the list corruption warning in exit_mmap -> zap_huge_pmd ->
> withdraw, and from time to time I also hit the BUG_ON(page->pmd_huge_pte)
> in exit_mmap -> free_pgtables -> free_pmd_range, which also indicates some
> issues with the deposit/withdraw list, see below:
> 
> [ 2489.384069] page:000003d101aa6f00 count:1 mapcount:0 mapping:          (null) index:0x0
> [ 2489.384075] flags: 0x0()
> [ 2489.384078] page dumped because: VM_BUG_ON_PAGE(page->pmd_huge_pte)
> [ 2489.384086] ------------[ cut here ]------------
> [ 2489.384088] kernel BUG at include/linux/mm.h:1700!
> [ 2489.384131] illegal operation: 0001 ilc:1 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [ 2489.384137] Modules linked in: bridge stp llc mlx4_ib ib_sa ib_mad mlx4_en ib_core vxlan udp_tunnel ptp pps_core ib_addr ghash_s390 prng ecb mlx4_core aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common eadm_sch dm_mod vhost_net tun vhost macvtap macvlan kvm autofs4
> [ 2489.384173] CPU: 5 PID: 173619 Comm: cc1 Tainted: G    B   W       4.5.0-rc3-00083-gc05235d #10
> [ 2489.384176] task: 00000000c54d0000 ti: 0000000060504000 task.ti: 0000000060504000
> [ 2489.384179] Krnl PSW : 0704c00180000000 0000000000283cf4 (free_pgd_range+0x334/0x460)
> [ 2489.384184]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
>                Krnl GPRS: 0000000001a161c7 0000000000000000 0000000000000037 0000000000000000
> [ 2489.384189]            0000000000283cf0 0000000000000000 000003ff7d980000 0000000060507e18
> [ 2489.384192]            000003ff00000000 0000000075e43ff0 000003ff7d97ffff 000003ff7d980000
> [ 2489.384195]            000000006a9bc000 00000000006cc390 0000000000283cf0 0000000060507c68
> [ 2489.384201] Krnl Code: 0000000000283ce4: c030002e14dd        larl    %%r3,84669e
>                           0000000000283cea: c0e5ffffd217        brasl   %%r14,27e118
>                          #0000000000283cf0: a7f40001            brc     15,283cf2
>                          >0000000000283cf4: c0e5fffffe5a        brasl   %%r14,2839a8
>                           0000000000283cfa: b9040027            lgr     %%r2,%%r7
>                           0000000000283cfe: b904003c            lgr     %%r3,%%r12
>                           0000000000283d02: c0e5fff509e3        brasl   %%r14,1250c8
>                           0000000000283d08: e31070000004        lg      %%r1,0(%%r7)
> [ 2489.384221] Call Trace:
> [ 2489.384224] ([<0000000000283cf0>] free_pgd_range+0x330/0x460)
> [ 2489.384227]  [<0000000000283f38>] free_pgtables+0x118/0x148
> [ 2489.384230]  [<000000000028c32e>] exit_mmap+0xd6/0x300
> [ 2489.384233]  [<0000000000134d70>] mmput+0x90/0x118
> [ 2489.384235]  [<000000000013a55c>] do_exit+0x41c/0xd18
> [ 2489.384238]  [<000000000013c3c2>] do_group_exit+0x92/0xd8
> [ 2489.384241]  [<000000000013c432>] SyS_exit_group+0x2a/0x30
> [ 2489.384244]  [<00000000006b1a36>] system_call+0xd6/0x258
> [ 2489.384246]  [<000003ff7d343698>] 0x3ff7d343698
> [ 2489.384248] INFO: lockdep is turned off.
> [ 2489.384251] Last Breaking-Event-Address:
> [ 2489.384253]  [<0000000000283cf0>] free_pgd_range+0x330/0x460
> [ 2489.384256]  
> [ 2489.384258] Kernel panic - not syncing: Fatal exception: panic_on_oops
> 
> I'll try to add a BUG_ON(pmd_huge(*pmd)) to free_pte_range() and see if that
> catches anything, and I'll also check if debug_cow = 1 or use_zero_page = 0
> makes any difference.

I worth minimizing kernel config on which you can see the bug. Things like
CONFIG_DEBUG_PAGEALLOC used to interfere with THP before.

You can also disable khugepaged, just in case.

One more thing: try add smp_wmb() in pgtable_trans_huge_withdraw() just
before return to make sure all CPUs sees _PAGE_INVALID.
I don't think it would make a difference. Again, just in case.

-- 
 Kirill A. Shutemov


From wens at csie.org  Thu Feb 18 09:07:16 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Thu, 18 Feb 2016 09:07:16 -0800
Subject: [PATCH] clk: sunxi: Add missing H3 apb0 clock documentation
In-Reply-To: <1455807809-30827-1-git-send-email-k@japko.eu>
References: <CACRpkdbfNeh7_=3ReQtJc7OxkkQEn+BUhZ0O0SKnFsRD=WZiUQ@mail.gmail.com>
 <1455807809-30827-1-git-send-email-k@japko.eu>
Message-ID: <CAGb2v67PiQHVQfhbsk2f3aQFOaDXHy3P+NJDoTw-+GshubWaYQ@mail.gmail.com>

On Thu, Feb 18, 2016 at 7:03 AM, Krzysztof Adamski
<krzysztof.adamski at tieto.com> wrote:
> allwinner,sun8i-h3-apb0-gates-clk was added by
> commit ba83a11104ae ("pinctrl: sunxi: Add H3 R_PIO controller support")
> but the patch was missing proper binding documentation. This patch fixes
> this issue.

What are you talking about? The commit you mentioned only adds the pinctrl
driver. Your H3 PRCM related clock and reset patches are still pending.
No need for this patch as your earlier patches includes this.

ChenYu

>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index c09f59b..37d0fd6 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -38,6 +38,7 @@ Required properties:
>         "allwinner,sun4i-a10-apb0-clk" - for the APB0 clock
>         "allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31
>         "allwinner,sun8i-a23-apb0-clk" - for the APB0 clock on A23
> +       "allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
>         "allwinner,sun9i-a80-apb0-clk" - for the APB0 bus clock on A80
>         "allwinner,sun8i-a83t-apb0-gates-clk" - for the APB0 gates on A83T
>         "allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10
> --
> 2.1.4
>


From lorenzo.pieralisi at arm.com  Thu Feb 18 09:13:36 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 18 Feb 2016 17:13:36 +0000
Subject: [PATCH v5 14/15] arm64: kernel: Add support for
 hibernate/suspend-to-disk
In-Reply-To: <1455637767-31561-15-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
 <1455637767-31561-15-git-send-email-james.morse@arm.com>
Message-ID: <20160218171336.GB13296@red-moon>

On Tue, Feb 16, 2016 at 03:49:26PM +0000, James Morse wrote:
> Add support for hibernate/suspend-to-disk.
> 
> Suspend borrows code from cpu_suspend() to write cpu state onto the stack,
> before calling swsusp_save() to save the memory image.
> 
> Restore creates a set of temporary page tables, covering only the
> linear map, copies the restore code to a 'safe' page, then uses the copy to
> restore the memory image. The copied code executes in the lower half of the
> address space, and once complete, restores the original kernel's page
> tables. It then calls into cpu_resume(), and follows the normal
> cpu_suspend() path back into the suspend code.
> 
> To restore a kernel using KASLR, the address of the page tables, and
> cpu_resume() are stored in the hibernate arch-header and the el2
> vectors are pivotted via the 'safe' page in low memory. This also permits
> us to resume using a different version of the kernel to the version that
> hibernated, but because the MMU isn't turned off during resume, the
> MMU settings must be the same between both kernels. To ensure this, the
> value of the translation control register (TCR_EL1) is also included in the
> hibernate arch-header, this means your resume kernel must have the same
> page size, and virtual address space size.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> Tested-by: Kevin Hilman <khilman at baylibre.com> # Tested on Juno R2
> ---

[...]

> +/*
> + * el2_setup() moves lr into elr and erets. Copy lr to another register to
> + * preserve it.
> + *
> + * int swsusp_el2_setup_helper(phys_addr_t el2_setup_pa);
> + */
> +ENTRY(swsusp_el2_setup_helper)
> +	mov	x16, x30
> +	hvc	#0
> +	mov	x30, x16
> +	ret
> +ENDPROC(swsusp_el2_setup_helper)
> +
> +/*
> + * Restore the hyp stub. Once we know where in memory el2_setup is, we
> + * can use it to re-initialise el2. This must be done before the hibernate
> + * page is unmapped.
> + *
> + * x0: The physical address of el2_setup __pa(el2_setup)
> + */
> +el1_sync:
> +	mov	x1, x0
> +	mrs	lr, elr_el2
> +	mrs	x0, sctlr_el1

You may make el2_setup return straight to swsusp_el2_setup_helper caller,
but anyway, I think you can do something even simpler.

You can stash el2_setup physical address (and a flag to check if you
have to reboot HYP or not) in the hibernate header, then, before
jumping to the _cpu_resume address you store in the header you restore
HYP by calling el2_setup_phys and you are done with that, this saves
you an extra call in C.

[...]

> +int swsusp_arch_suspend(void)
> +{
> +	int ret = 0;
> +	unsigned long flags;
> +	struct sleep_stack_data state;
> +
> +	local_dbg_save(flags);
> +
> +	if (__cpu_suspend_enter(&state)) {
> +		ret = swsusp_save();
> +	} else {
> +		void *lm_kernel_start;
> +
> +		/* Clean kernel to PoC for secondary core startup */
> +		lm_kernel_start = phys_to_virt(virt_to_phys(KERNEL_START));
> +		__flush_dcache_area(lm_kernel_start, KERNEL_END - KERNEL_START);
> +
> +		/* Reconfigure EL2 */
> +		if (is_hyp_mode_available())
> +			swsusp_el2_setup_helper(virt_to_phys(el2_setup));

I am referring to this code here, I think it is nicer to restore el2
before getting here anyway as I say above, you do know you have to call
el2_setup anyway, stash the data/address you need in the hibernate header
and just execute it in the code page set aside to resume from hibernate
(ie swsusp_arch_suspend_exit).

Thanks !
Lorenzo

> +
> +		/*
> +		 * Tell the hibernation core that we've just restored
> +		 * the memory
> +		 */
> +		in_suspend = 0;
> +
> +		__cpu_suspend_exit();
> +	}
> +
> +	local_dbg_restore(flags);
> +
> +	return ret;
> +}
> +
> +static int copy_pte(pmd_t *dst_pmd, pmd_t *src_pmd, unsigned long start,
> +		    unsigned long end)
> +{
> +	unsigned long next;
> +	unsigned long addr = start;
> +	pte_t *src_pte = pte_offset_kernel(src_pmd, start);
> +	pte_t *dst_pte = pte_offset_kernel(dst_pmd, start);
> +
> +	do {
> +		next = addr + PAGE_SIZE;
> +		if (pte_val(*src_pte))
> +			set_pte(dst_pte,
> +				__pte(pte_val(*src_pte) & ~PTE_RDONLY));
> +	} while (dst_pte++, src_pte++, addr = next, addr != end);
> +
> +	return 0;
> +}
> +
> +static int copy_pmd(pud_t *dst_pud, pud_t *src_pud, unsigned long start,
> +		    unsigned long end)
> +{
> +	int rc = 0;
> +	pte_t *dst_pte;
> +	unsigned long next;
> +	unsigned long addr = start;
> +	pmd_t *src_pmd = pmd_offset(src_pud, start);
> +	pmd_t *dst_pmd = pmd_offset(dst_pud, start);
> +
> +	do {
> +		next = pmd_addr_end(addr, end);
> +		if (!pmd_val(*src_pmd))
> +			continue;
> +
> +		if (pmd_table(*(src_pmd))) {
> +			dst_pte = (pte_t *)get_safe_page(GFP_ATOMIC);
> +			if (!dst_pte) {
> +				rc = -ENOMEM;
> +				break;
> +			}
> +
> +			set_pmd(dst_pmd, __pmd(virt_to_phys(dst_pte)
> +					       | PMD_TYPE_TABLE));
> +
> +			rc = copy_pte(dst_pmd, src_pmd, addr, next);
> +			if (rc)
> +				break;
> +		} else {
> +			set_pmd(dst_pmd,
> +				__pmd(pmd_val(*src_pmd) & ~PMD_SECT_RDONLY));
> +		}
> +	} while (dst_pmd++, src_pmd++, addr = next, addr != end);
> +
> +	return rc;
> +}
> +
> +static int copy_pud(pgd_t *dst_pgd, pgd_t *src_pgd, unsigned long start,
> +		    unsigned long end)
> +{
> +	int rc = 0;
> +	pmd_t *dst_pmd;
> +	unsigned long next;
> +	unsigned long addr = start;
> +	pud_t *src_pud = pud_offset(src_pgd, start);
> +	pud_t *dst_pud = pud_offset(dst_pgd, start);
> +
> +	do {
> +		next = pud_addr_end(addr, end);
> +		if (!pud_val(*src_pud))
> +			continue;
> +
> +		if (pud_table(*(src_pud))) {
> +			if (PTRS_PER_PMD != 1) {
> +				dst_pmd = (pmd_t *)get_safe_page(GFP_ATOMIC);
> +				if (!dst_pmd) {
> +					rc = -ENOMEM;
> +					break;
> +				}
> +
> +				set_pud(dst_pud, __pud(virt_to_phys(dst_pmd)
> +						       | PUD_TYPE_TABLE));
> +			}
> +
> +			rc = copy_pmd(dst_pud, src_pud, addr, next);
> +			if (rc)
> +				break;
> +		} else {
> +			set_pud(dst_pud,
> +				__pud(pud_val(*src_pud) & ~PMD_SECT_RDONLY));
> +		}
> +	} while (dst_pud++, src_pud++, addr = next, addr != end);
> +
> +	return rc;
> +}
> +
> +static int copy_page_tables(pgd_t *dst_pgd, unsigned long start,
> +			    unsigned long end)
> +{
> +	int rc = 0;
> +	pud_t *dst_pud;
> +	unsigned long next;
> +	unsigned long addr = start;
> +	pgd_t *src_pgd = pgd_offset_k(start);
> +
> +	dst_pgd += pgd_index(start);
> +
> +	do {
> +		next = pgd_addr_end(addr, end);
> +		if (!pgd_val(*src_pgd))
> +			continue;
> +
> +		if (PTRS_PER_PUD != 1) {
> +			dst_pud = (pud_t *)get_safe_page(GFP_ATOMIC);
> +			if (!dst_pud) {
> +				rc = -ENOMEM;
> +				break;
> +			}
> +
> +			set_pgd(dst_pgd, __pgd(virt_to_phys(dst_pud)
> +					       | PUD_TYPE_TABLE));
> +		}
> +
> +		rc = copy_pud(dst_pgd, src_pgd, addr, next);
> +		if (rc)
> +			break;
> +	} while (dst_pgd++, src_pgd++, addr = next, addr != end);
> +
> +	return rc;
> +}
> +
> +/*
> + * Setup then Resume from the hibernate image using swsusp_arch_suspend_exit().
> + *
> + * Memory allocated by get_safe_page() will be dealt with by the hibernate code,
> + * we don't need to free it here.
> + */
> +int swsusp_arch_resume(void)
> +{
> +	int rc = 0;
> +	size_t exit_size;
> +	pgd_t *tmp_pg_dir;
> +	void *lm_restore_pblist;
> +	phys_addr_t phys_hibernate_exit;
> +	void __noreturn (*hibernate_exit)(phys_addr_t, phys_addr_t, void *, void *);
> +
> +	/*
> +	 * Copy swsusp_arch_suspend_exit() to a safe page. This will generate
> +	 * a new set of ttbr0 page tables and load them.
> +	 */
> +	exit_size = __hibernate_exit_text_end - __hibernate_exit_text_start;
> +	rc = create_safe_exec_page(__hibernate_exit_text_start, exit_size,
> +				   (void **)&hibernate_exit,
> +				   &phys_hibernate_exit,
> +				   get_safe_page, GFP_ATOMIC);
> +	if (rc) {
> +		pr_err("Failed to create safe executable page for hibernate_exit code.");
> +		goto out;
> +	}
> +
> +	/*
> +	 * The hibernate exit text contains a set of el2 vectors, that will
> +	 * be executed at el2 with the mmu off in order to reload hyp-stub.
> +	 */
> +	__flush_dcache_area(hibernate_exit, exit_size);
> +
> +	/*
> +	 * Restoring the memory image will overwrite the ttbr1 page tables.
> +	 * Create a second copy of just the linear map, and use this when
> +	 * restoring.
> +	 */
> +	tmp_pg_dir = (pgd_t *)get_safe_page(GFP_ATOMIC);
> +	if (!tmp_pg_dir) {
> +		pr_err("Failed to allocate memory for temporary page tables.");
> +		rc = -ENOMEM;
> +		goto out;
> +	}
> +	rc = copy_page_tables(tmp_pg_dir, PAGE_OFFSET, 0);
> +	if (rc)
> +		goto out;
> +
> +	/*
> +	 * Since we only copied the linear map, we need to find restore_pblist's
> +	 * linear map address.
> +	 */
> +	lm_restore_pblist = phys_to_virt(virt_to_phys(restore_pblist));
> +
> +	/*
> +	 * Both KASLR and restoring with a different kernel version will cause
> +	 * the el2 vectors to be in a different location in the resumed kernel.
> +	 * Load hibernate's temporary copy into el2.
> +	 */
> +	if (is_hyp_mode_available()) {
> +		phys_addr_t el2_vectors = phys_hibernate_exit;  /* base */
> +		el2_vectors += hibernate_el2_vectors -
> +			       __hibernate_exit_text_start;     /* offset */
> +
> +		__hyp_set_vectors(el2_vectors);
> +	}
> +
> +	hibernate_exit(virt_to_phys(tmp_pg_dir), resume_hdr.ttbr1_el1,
> +		       resume_hdr.reenter_kernel, lm_restore_pblist);
> +
> +out:
> +	return rc;
> +}
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index 282e3e64a17e..02184c39f7e2 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -46,6 +46,16 @@ jiffies = jiffies_64;
>  	*(.idmap.text)					\
>  	VMLINUX_SYMBOL(__idmap_text_end) = .;
>  
> +#ifdef CONFIG_HIBERNATION
> +#define HIBERNATE_TEXT					\
> +	. = ALIGN(SZ_4K);				\
> +	VMLINUX_SYMBOL(__hibernate_exit_text_start) = .;\
> +	*(.hibernate_exit.text)				\
> +	VMLINUX_SYMBOL(__hibernate_exit_text_end) = .;
> +#else
> +#define HIBERNATE_TEXT
> +#endif
> +
>  /*
>   * The size of the PE/COFF section that covers the kernel image, which
>   * runs from stext to _edata, must be a round multiple of the PE/COFF
> @@ -107,6 +117,7 @@ SECTIONS
>  			LOCK_TEXT
>  			HYPERVISOR_TEXT
>  			IDMAP_TEXT
> +			HIBERNATE_TEXT
>  			*(.fixup)
>  			*(.gnu.warning)
>  		. = ALIGN(16);
> @@ -182,6 +193,10 @@ ASSERT(__hyp_idmap_text_end - (__hyp_idmap_text_start & ~(SZ_4K - 1)) <= SZ_4K,
>  	"HYP init code too big or misaligned")
>  ASSERT(__idmap_text_end - (__idmap_text_start & ~(SZ_4K - 1)) <= SZ_4K,
>  	"ID map text too big or misaligned")
> +#ifdef CONFIG_HIBERNATION
> +ASSERT(__hibernate_exit_text_end - (__hibernate_exit_text_start & ~(SZ_4K - 1))
> +	<= SZ_4K, "Hibernate exit text too big or misaligned")
> +#endif
>  
>  /*
>   * If padding is applied before .head.text, virt<->phys conversions will fail.
> -- 
> 2.6.2
> 


From nicolas.pitre at linaro.org  Thu Feb 18 09:14:06 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Feb 2016 12:14:06 -0500 (EST)
Subject: [PATCH v2] ARM: atags_to_fdt: don't warn about stack size
In-Reply-To: <7301172.5fH67MHlU9@wuerfel>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-6-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602181112310.13632@knanqh.ubzr>
 <7301172.5fH67MHlU9@wuerfel>
Message-ID: <alpine.LFD.2.20.1602181213260.13632@knanqh.ubzr>

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

> The merge_fdt_bootargs() function by definition consumes more than 1024
> bytes of stack because it has a 1024 byte command line on the stack,
> meaning that we always get a warning when building this file:
> 
> arch/arm/boot/compressed/atags_to_fdt.c: In function 'merge_fdt_bootargs':
> arch/arm/boot/compressed/atags_to_fdt.c:98:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]
> 
> However, as this is the decompressor and we know that it has a very shallow
> call chain, and we do not actually risk overflowing the kernel stack
> at runtime here.
> 
> This just shuts up the warning by slightly increasing the limit for this
> file.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Acked-by: Nicolas Pitre <nico at linaro.org>


> ---
> On Thursday 18 February 2016 11:13:52 Nicolas Pitre wrote:
> > What about setting the warning to 2048 instead?
> 
> Sure, actually 1280 is more than enough I think.
> 
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index 7a6a58ef8aaf..2cc63038d6c8 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -85,6 +85,8 @@ $(addprefix $(obj)/,$(libfdt) $(libfdt_hdrs)): $(obj)/%: $(srctree)/scripts/dtc/
>  $(addprefix $(obj)/,$(libfdt_objs) atags_to_fdt.o): \
>  	$(addprefix $(obj)/,$(libfdt_hdrs))
>  
> +CFLAGS_atags_to_fdt.o += -Wframe-larger-than=1280
> +
>  ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
>  OBJS	+= $(libfdt_objs) atags_to_fdt.o
>  endif
> 
> 


From paul at pwsan.com  Thu Feb 18 09:17:42 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Thu, 18 Feb 2016 17:17:42 +0000 (UTC)
Subject: [PATCH v4 1/3] ARM: hwmod: RTC: Add lock and unlock functions
In-Reply-To: <56C58C98.2040006@ti.com>
References: <1454650952-20154-1-git-send-email-lokeshvutla@ti.com>
 <1454650952-20154-2-git-send-email-lokeshvutla@ti.com>
 <alpine.DEB.2.02.1602072209460.2182@utopia.booyaka.com>
 <alpine.DEB.2.02.1602180626420.4792@utopia.booyaka.com>
 <56C58C98.2040006@ti.com>
Message-ID: <alpine.DEB.2.02.1602181717260.4792@utopia.booyaka.com>

On Thu, 18 Feb 2016, Lokesh Vutla wrote:

> Sorry for the delay, I am on a vacation right now. I have already sent
> a mail to the HW guys. Will update you as soon as I receive a reply
> from them.

Got it; thanks Lokesh.


- Paul


From geert at linux-m68k.org  Thu Feb 18 09:18:56 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Thu, 18 Feb 2016 18:18:56 +0100
Subject: [PATCH/RFC v2 01/11] PM / Domains: Add DT bindings for the R-Car
 System Controller
In-Reply-To: <20160218143826.GB9654@rob-hp-laptop>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
 <1455571020-18968-2-git-send-email-geert+renesas@glider.be>
 <20160218143826.GB9654@rob-hp-laptop>
Message-ID: <CAMuHMdXqVL6_P6Lnea6z8jFtR2v4NFnzn=ibZVyauZ8-ODb6dg@mail.gmail.com>

Hi Rob,

On Thu, Feb 18, 2016 at 3:38 PM, Rob Herring <robh at kernel.org> wrote:
> On Mon, Feb 15, 2016 at 10:16:50PM +0100, Geert Uytterhoeven wrote:
>> The Renesas R-Car System Controller provides power management for the
>> CPU cores and various coprocessors, following the generic PM domain
>> bindings in Documentation/devicetree/bindings/power/power_domain.txt.
>>
>> This supports R-Car Gen1, Gen2, and Gen3.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
>> ---
>> Alternatives I considered:
>>
>>   - Using a single node per power register block, even if it contains
>>     multiple domains, e.g.:
>>
>>           pd_ca15_scu: ca15_scu at 180 {
>>                   reg = <0x180 0x20>;
>>                   #address-cells = <1>;
>>                   #size-cells = <0>;
>>                   #power-domain-cells = <0>;
>>                   renesas,interrupt-bits = <12>;
>>
>>                   pd_ca15_cpu: ca15_cpu at 40 {
>>                           reg = <0x40 0x20>;
>>                           #power-domain-cells = <1>;
>>                           renesas,pm-domain-indices = <0 1>;
>>                           renesas,pm-domain-names =
>>                                   "ca15_cpu0", "ca15_cpu1";
>>                           renesas,interrupt-bits = <0 1>;
>>                   };
>>           };
>>
>>     Notes:
>>       - You cannot just have a property with the number of domains, as
>>       index 0 is not used on R-Car H1. Hence the need for
>>       "renesas,pm-domain-indices" and "renesas,interrupt-bits",
>>       - "#power-domain-cells = <1>" for nodes with multiple domains,
>>       which allows typos in "power-domains = <&pd_ca15_cpu n>", using
>>       an invalid value of "n".
>>
>>   - Using a linear description in DT:
>>       - Needs parent links for subdomains,
>>       - More complicated to parse (lesson learned from R-Mobile PM
>>       Domain support).
>>
>>   - Keeping the power register block offset and the bit number as separate
>>     "reg" cells, increasing "#address-cells" from 2 to 3,
>>
>>   - Merging the interrupt bit (which needs only 5 bits) in the other "reg"
>>     cell, decreasing "#address-cells" from 2 to 1.
>
> I think I'd move to not encoding mulitple things into reg. This seems
> like a bit of abuse of reg. Otherwise, I don't have much to comment on.

Thanks!

(quoting the encoding of the reg properties)
> +== PM Domain Nodes ==
> +
> +Each of the PM domain nodes represents a PM domain, as documented by the
> +generic PM domain bindings in
> +Documentation/devicetree/bindings/power/power_domain.txt.
> +
> +Required properties:
> +  - #power-domain-cells: Must be 0.
> +  - reg: This property must contain 2 values:
> +          - The first value is the number of the interrupt bit representing
> +            the power area in the various Interrupt Registers (e.g. SYSCISR,
> +            Interrupt Status Register),
> +          - The second value encodes the power register block offset (which is
> +            a multiple of 64), and the number of the bit representing the
> +            power area in the various Power Control Registers (e.g. PWROFFSR,
> +            Power Shutoff Status Register). This value is created by ORing
> +            these two numbers.

Not encoding multiple things into reg means adding more properties to provide
that information, iff we want to describe the PM Domain Nodes in DT.
I considered the reg property a two-dimensional address space.

Taking the lessons from CCF and the new CPG/MSSR bindings into account
(which was BTW designed after the SYSC DT bindings), perhaps the PM Domain
hierarchy should be moved from DT to C, in the driver, too?

That would mean we have in DT:
  1) "#power-domain-cells = <1>"
  2) defines for the various domains, e.g. "#define R8A7791_PD_CA15_SCU      12"
  3) e.g. "power-domains = <&sysc R8A7791_PD_CA15_SCU>"
  4) and we can get rid of the fallback compatibility strings again.

Thoughts?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From eric.auger at linaro.org  Thu Feb 18 09:18:44 2016
From: eric.auger at linaro.org (Eric Auger)
Date: Thu, 18 Feb 2016 18:18:44 +0100
Subject: [RFC v3 07/15] iommu: iommu_get/put_single_reserved
In-Reply-To: <56C5F679.8000002@arm.com>
References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org>
 <1455264797-2334-8-git-send-email-eric.auger@linaro.org>
 <20160218110616.05108071@arm.com> <56C5F472.1020003@linaro.org>
 <56C5F679.8000002@arm.com>
Message-ID: <56C5FCF4.4010509@linaro.org>

Hi Marc,
On 02/18/2016 05:51 PM, Marc Zyngier wrote:
> On 18/02/16 16:42, Eric Auger wrote:
>> Hello,
>> On 02/18/2016 12:06 PM, Marc Zyngier wrote:
>>> On Fri, 12 Feb 2016 08:13:09 +0000
>>> Eric Auger <eric.auger at linaro.org> wrote:
>>>
>>>> This patch introduces iommu_get/put_single_reserved.
>>>>
>>>> iommu_get_single_reserved allows to allocate a new reserved iova page
>>>> and map it onto the physical page that contains a given physical address.
>>>> It returns the iova that is mapped onto the provided physical address.
>>>> Hence the physical address passed in argument does not need to be aligned.
>>>>
>>>> In case a mapping already exists between both pages, the IOVA mapped
>>>> to the PA is directly returned.
>>>>
>>>> Each time an iova is successfully returned a binding ref count is
>>>> incremented.
>>>>
>>>> iommu_put_single_reserved decrements the ref count and when this latter
>>>> is null, the mapping is destroyed and the iova is released.
>>>
>>> I wonder if there is a requirement for the caller to find out about the
>>> size of the mapping, or to impose a given size... MSIs clearly do not
>>> have that requirement (this is always a 32bit value), but since. 
>>> allocations usually pair address and size, I though I'd ask...
>> Yes. Currently this only makes sure the host PA is mapped and returns
>> the corresponding IOVA. It is part of the discussion we need to have on
>> the API besides the problematic of which API it should belong to.
> 
> One of the issues I have with the API at the moment is that there is no
> control on the page size. Imagine you have allocated a 4kB IOVA window
> for your MSI, but your IOMMU can only map 64kB (not unreasonable to
> imagine on arm64). What happens then?
The code checks the IOVA window size is aligned with the IOMMU page size
so I think that case is handled at iova domain creation
(arm_smmu_alloc_reserved_iova_domain).
> 
> Somehow, userspace should be told about it, one way or another.
I agree on that point. The user-space should be provided with the
information about the requested iova pool size and alignments. This is
missing in current rfc series.

Best Regards

Eric
> 
> Thanks,
> 
> 	M.
> 



From peter at hurleysoftware.com  Thu Feb 18 09:20:32 2016
From: peter at hurleysoftware.com (Peter Hurley)
Date: Thu, 18 Feb 2016 09:20:32 -0800
Subject: [PATCH 2/3] serial: xuartps: Enable OF earlycon support
In-Reply-To: <56C57A60.4070600@xilinx.com>
References: <67c9013fc61f53515934b54847a05df8b8e1504a.1455552315.git.michal.simek@xilinx.com>
 <23ab10a19b21df2ef17a5bb6ce2a70d2d3fd3551.1455552315.git.michal.simek@xilinx.com>
 <56C34F65.1040506@hurleysoftware.com> <56C57A60.4070600@xilinx.com>
Message-ID: <56C5FD60.4090906@hurleysoftware.com>

On 02/18/2016 12:01 AM, Michal Simek wrote:
> BTW: Is it normal that when earlycon support is enabled that the bootlog
> is copied again? All what was printed before bootconsole [xxx] disabled
> is printed twice.

I think it has to do with the dummy console bug w/ OF.

Masahiro Yamada reported this back with 4.4-rc1 [1] but problem occurs before
then as well.

[1] http://www.gossamer-threads.com/lists/linux/kernel/2313050

> Or is this just bug in our driver?

No.

Regards,
Peter Hurley


From nicolas.pitre at linaro.org  Thu Feb 18 09:20:51 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Feb 2016 12:20:51 -0500 (EST)
Subject: [PATCH 8/9] ARM: do not use optimized do_div for ARMv3
In-Reply-To: <1455804123-2526139-9-git-send-email-arnd@arndb.de>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-9-git-send-email-arnd@arndb.de>
Message-ID: <alpine.LFD.2.20.1602181215310.13632@knanqh.ubzr>

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

> The gcc-4.9 optimization goes wrong while building target_core_iblock.c
> for ARMv3 and leaves a bogus reference to __aeabi_uldivmod in the
> output:
> 
> ERROR: "__aeabi_uldivmod" [drivers/target/target_core_iblock.ko] undefined!
> 
> I could not find anyone who is interested in fixing it in gcc,
> so as a workaround this disables the do_div magic, just like
> we do for old compilers and for OABI.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

I suppose this is good enough for the purpose of keeping RiscPC 
buildable. Whether or not it is still used is another question.  If it 
is then its user probably expects it to be slow already.

Acked-by: Nicolas Pitre <nico at linaro.org>

Still unfortunate having to use a big hammer such as -march=armv3 just 
to avoid halfword memory accesses.


> ---
>  arch/arm/include/asm/div64.h | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/include/asm/div64.h b/arch/arm/include/asm/div64.h
> index 7d919a9b32e5..958fdc2363f5 100644
> --- a/arch/arm/include/asm/div64.h
> +++ b/arch/arm/include/asm/div64.h
> @@ -58,6 +58,14 @@ static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
>   */
>  #define do_div(n, base) __div64_32(&(n), base)
>  
> +#elif defined(CONFIG_CPU_32v3)
> +
> +/*
> + * modern compiler versions (>= gcc-4.9) tend to misoptimize
> + * the code for ARMv3, and this is not getting fixed any more.
> + */
> +#define do_div(n, base) __div64_32(&(n), base)
> +
>  #else
>  
>  /*
> -- 
> 2.7.0
> 
> 


From paul at pwsan.com  Thu Feb 18 09:21:28 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Thu, 18 Feb 2016 17:21:28 +0000 (UTC)
Subject: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS
In-Reply-To: <56C5E466.2030002@ti.com>
References: <1433332284-10766-1-git-send-email-vigneshr@ti.com>
 <1433332284-10766-3-git-send-email-vigneshr@ti.com>
 <alpine.DEB.2.02.1507152029460.32764@utopia.booyaka.com>
 <55A7CE59.6010600@ti.com>
 <alpine.DEB.2.02.1508121700500.7154@utopia.booyaka.com>
 <56C4DB37.9090802@ti.com>
 <alpine.DEB.2.02.1602180652380.4792@utopia.booyaka.com>
 <56C5E466.2030002@ti.com>
Message-ID: <alpine.DEB.2.02.1602181718560.4792@utopia.booyaka.com>

Hi Franklin, 

On Thu, 18 Feb 2016, Franklin S Cooper Jr. wrote:

> On 02/18/2016 12:58 AM, Paul Walmsley wrote:
>
> > OK I'm not sure I understand what's going on, particularly the part about 
> > locking and unlocking.  Are you saying that the pwm_bl driver calls into 
> > the pwm_tiecap module to write to the PWMSS_CLKCONFIG registers to ungate 
> > the ECAP clock, and then the hardware silently ignores the write?  If 
> > that's the case, shouldn't we be seeing some warning messages from a 
> > failure to ungate the clock from a subsequent PWMSS_CLKSTATUS poll?  Or am 
> > I misunderstanding what's going on here?
> Pwm-tipwmss.c exports a function
> pwmss_submodule_state_change which interacts with
> PWMSS_CLKCONFIG and PWMSS_CLKSTATUS registers. Both
> pwm-tiehrpwm.c and pwm-tiecap.c calls this exported function
> to unlock the gate at probe time and lock the gate when the
> driver is removed.
> 
> So when the gate fails to be unlocked after it previously is
> locked there isn't a way to know this via the
> PWMSS_CLKSTATUS registers.

OK I understand now.  Sounds like the gating -> ungating transition is 
effectively a one-time operation, and once the ungating -> gating 
transition is done, there's no way to reverse it.  Please correct me if 
I've got it wrong.

>  So the driver "believes" that the gate is unlocked and when pwm_bl runs 
> it calls the set_polarity function. Set_polarity in the case of AM437x 
> gp evm maps to the ecap's ecap_pwm_set_polarity function call. This call 
> then attempts to write to the ecap registers which results in the 
> external abort since the clock to the ecap is still gated.
>
> When the ecap and tihrpwm driver request to unlock the clock
> gate it already checks the XXX_CLK_EN_ACK bitfields within
> CLKSTATUS and it shows that the clocks "should" be unlocked.
> So there is an issue with the IP.

OK

> Yes, I plan on addressing the change Vignesh acknowledged
> regarding changing RESETSTATUS to SOFTRESET. For your other
> comments I believe he already explained why it has to be set
> in that particular way. If there is anything that I missed
> or something that isn't clear please let me know.

Perfect, thanks for the good description and the followup.


- Paul


From paul at pwsan.com  Thu Feb 18 09:23:53 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Thu, 18 Feb 2016 17:23:53 +0000 (UTC)
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <56C5D377.50901@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com> <56BACCDB.2070507@ti.com>
 <alpine.DEB.2.02.1602111921090.20757@utopia.booyaka.com>
 <56BD8091.4090007@ti.com> <56BE1454.3030002@ti.com> <56C5D377.50901@ti.com>
Message-ID: <alpine.DEB.2.02.1602181721530.4792@utopia.booyaka.com>


On Thu, 18 Feb 2016, Sekhar Nori wrote:

> On Friday 12 February 2016 10:50 PM, Suman Anna wrote:
> > Sekhar,
> > Will you be following up with above suggestion since Kishon is gonna be out?
> 
> Alright, noticed this action for me :) Went through the thread, and 
> looks like this is what we want to see?

Thanks Sekhar.  Did you try the driver unbind/bind sequence a few times to 
ensure that works, per Suman's earlier E-mail? 

Suman, is there any further testing that you are planning to do on this 
patch?

- Paul


> 
> Thanks,
> Sekhar
> 
> ---8<---
> >From e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19 Mon Sep 17 00:00:00 2001
> Message-Id: <e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19.1455803758.git.nsekhar at ti.com>
> From: Sekhar Nori <nsekhar at ti.com>
> Date: Thu, 18 Feb 2016 16:49:56 +0530
> Subject: [PATCH 1/1] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS
> 
> Add a custom reset handler for DRA7x PCIeSS. This
> handler is required to deassert PCIe hardreset lines
> after they have been asserted.
> 
> This enables the PCIe driver to access registers after
> PCIeSS has been runtime enabled without having to
> deassert hardreset lines itself.
> 
> With this patch applied, used lspci to make sure
> connected PCIe device enumerates on DRA74x and DRA72x
> EVMs.
> 
> Signed-off-by: Sekhar Nori <nsekhar at ti.com>
> ---
> Applies to tag for-v4.6/omap-hwmod-a of Paul W's tree.
> 
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index b61355e2a771..252b74633e31 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1526,8 +1526,31 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
>   *
>   */
>  
> +/*
> + * As noted in documentation for _reset() in omap_hwmod.c, the stock reset
> + * functionality of OMAP HWMOD layer does not deassert the hardreset lines
> + * associated with an IP automatically leaving the driver to handle that
> + * by itself. This does not work for PCIeSS which needs the reset lines
> + * deasserted for the driver to start accessing registers.
> + *
> + * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset
> + * lines after asserting them.
> + */
> +static int dra7xx_pciess_reset(struct omap_hwmod *oh)
> +{
> +	int i;
> +
> +	for (i = 0; i < oh->rst_lines_cnt; i++) {
> +		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);
> +		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);
> +	}
> +
> +	return 0;
> +}
> +
>  static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {
>  	.name	= "pcie",
> +	.reset	= dra7xx_pciess_reset,
>  };
>  
>  /* pcie1 */
> -- 
> 2.6.3
> 
> 


- Paul


From chris.brandt at renesas.com  Thu Feb 18 09:25:10 2016
From: chris.brandt at renesas.com (Chris Brandt)
Date: Thu, 18 Feb 2016 12:25:10 -0500
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
Message-ID: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>

As Multiplatform seems to be the way of the future, you should not restrict
from selecting XIP. Whether it makes sense or not depends on how you
configure the rest of the kernel (as in, removing individual platforms).
Also, it stands to reason that if you select MULTIPLATFORM and XIP_KERNEL,
you either know what you are doing...or have NO idea what you are doing.

Signed-off-by: Chris Brandt <chris.brandt at renesas.com>
---
 arch/arm/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index cc95ff8..2e4a127 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -327,7 +327,7 @@ config ARCH_MULTIPLATFORM
 	depends on MMU
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_HAS_SG_CHAIN
-	select ARM_PATCH_PHYS_VIRT
+	select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL
 	select AUTO_ZRELADDR
 	select CLKSRC_OF
 	select COMMON_CLK
@@ -1919,7 +1919,7 @@ endchoice
 
 config XIP_KERNEL
 	bool "Kernel Execute-In-Place from ROM"
-	depends on !ARM_LPAE && !ARCH_MULTIPLATFORM
+	depends on !ARM_LPAE
 	help
 	  Execute-In-Place allows the kernel to run from non-volatile storage
 	  directly addressable by the CPU, such as NOR flash. This saves RAM
-- 
1.9.1




From mark.rutland at arm.com  Thu Feb 18 09:27:38 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 18 Feb 2016 17:27:38 +0000
Subject: [PATCH] arm64: kasan: clear stale stack poison
Message-ID: <1455816458-19485-1-git-send-email-mark.rutland@arm.com>

This patch is a followup to the discussion in [1].

When using KASAN and CPU idle and/or CPU hotplug, KASAN leaves the stack shadow
poisoned on exit from the kernel, and this poison is later hit when a CPU is
brought online and reuses that portion of the stack. Hitting the poison depends
on stackframe layout, so the bug only manifests in some configurations.

I think that the hotplug issue is generic, and x86 is affected. I couldn't spot
magic around idle, so x86 may be fine there. It would be great if someone
familiar with the x86 code could prove/disprove either of those assertions.

If x86 is affected, it likely makes sense to unpoison the stack in common code
prior to bringing a CPU online to avoid that.

For idle I'm not keen on having to perform a memset of THREAD_SIZE/8 every time
a CPU re-enters the kernel. I don't yet have numbers for how bad that is, but
it doesn't sound good.

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/408961.html

---->8----
When a CPU is shut down or placed into a low power state, the functions
on the critical path to firmware never return, and hence their epilogues
never execute. When using KASAN, this means that the shadow entries for
the corresponding stack are poisoned but never unpoisoned. When a CPU
subsequently re-enters the kernel via another path, and begins using
the stack, it may hit stale poison values, leading to false-positive
KASAN failures.

We can't ensure that all functions on the critical path are not
instrumented. For CPU hotplug this includes lots of core code starting
from secondary_start_kernel, and for CPU idle we can't ensure that
specific functions are not instrumented, as the compiler always poisons
the stack even when told to not instrument a function:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69863

This patch works around the issue by forcefully unpoisoning the shadow
region for all stack on the critical path, before we return to
instrumented C code. As we cannot statically determine the stack usage
of code in the critical path, we must clear the shadow for all remaining
stack, meaning that we must clear up to 2K of shadow memory each time a
CPU enters the kernel from idle or hotplug.

Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Cc: Andrey Ryabinin <aryabinin at virtuozzo.com>
Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
---
 arch/arm64/include/asm/kasan.h  | 40 ++++++++++++++++++++++++++++++++++------
 arch/arm64/kernel/asm-offsets.c |  1 +
 arch/arm64/kernel/head.S        |  2 ++
 arch/arm64/kernel/sleep.S       |  2 ++
 4 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h
index 2774fa3..b75b171 100644
--- a/arch/arm64/include/asm/kasan.h
+++ b/arch/arm64/include/asm/kasan.h
@@ -1,10 +1,30 @@
 #ifndef __ASM_KASAN_H
 #define __ASM_KASAN_H
 
-#ifndef __ASSEMBLY__
-
+#ifndef LINKER_SCRIPT
 #ifdef CONFIG_KASAN
 
+#ifdef __ASSEMBLY__
+
+#include <asm/asm-offsets.h>
+#include <asm/thread_info.h>
+
+	/*
+	 * Remove stale shadow posion for the stack left over from a prior
+	 * hot-unplug or idle exit, covering up to offset bytes above the
+	 * current stack pointer. Shadow poison above this is preserved.
+	 */
+	.macro kasan_unpoison_stack offset=0
+	add	x1, sp, #\offset
+	and	x0, x1, #~(THREAD_SIZE - 1)
+	add	x0, x0, #THREAD_INFO_SIZE
+	and	x1, x1, #(THREAD_SIZE - 1)
+	sub	x1, x1, #THREAD_INFO_SIZE
+	bl	kasan_unpoison_shadow
+	.endm
+
+#else /* __ASSEMBLY__ */
+
 #include <linux/linkage.h>
 #include <asm/memory.h>
 
@@ -30,9 +50,17 @@
 void kasan_init(void);
 asmlinkage void kasan_early_init(void);
 
-#else
+#endif /* __ASSEMBLY__ */
+
+#else /* CONFIG_KASAN */
+
+#ifdef __ASSEMBLY__
+	.macro kasan_unpoison_stack offset
+	.endm
+#else /* __ASSEMBLY */
 static inline void kasan_init(void) { }
-#endif
+#endif /* __ASSEMBLY__ */
 
-#endif
-#endif
+#endif /* CONFIG_KASAN */
+#endif /* LINKER_SCRIPT */
+#endif /* __ASM_KASAN_H */
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index fffa4ac6..c615fa3 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -39,6 +39,7 @@ int main(void)
   DEFINE(TI_ADDR_LIMIT,		offsetof(struct thread_info, addr_limit));
   DEFINE(TI_TASK,		offsetof(struct thread_info, task));
   DEFINE(TI_CPU,		offsetof(struct thread_info, cpu));
+  DEFINE(THREAD_INFO_SIZE,	sizeof(struct thread_info));
   BLANK();
   DEFINE(THREAD_CPU_CONTEXT,	offsetof(struct task_struct, thread.cpu_context));
   BLANK();
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index ffe9c2b..a0c3ec7 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -29,6 +29,7 @@
 #include <asm/asm-offsets.h>
 #include <asm/cache.h>
 #include <asm/cputype.h>
+#include <asm/kasan.h>
 #include <asm/kernel-pgtable.h>
 #include <asm/memory.h>
 #include <asm/pgtable-hwdef.h>
@@ -611,6 +612,7 @@ ENTRY(__secondary_switched)
 	and	x0, x0, #~(THREAD_SIZE - 1)
 	msr	sp_el0, x0			// save thread_info
 	mov	x29, #0
+	kasan_unpoison_stack
 	b	secondary_start_kernel
 ENDPROC(__secondary_switched)
 
diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
index e33fe33..3b95841 100644
--- a/arch/arm64/kernel/sleep.S
+++ b/arch/arm64/kernel/sleep.S
@@ -2,6 +2,7 @@
 #include <linux/linkage.h>
 #include <asm/asm-offsets.h>
 #include <asm/assembler.h>
+#include <asm/kasan.h>
 
 	.text
 /*
@@ -145,6 +146,7 @@ ENTRY(cpu_resume_mmu)
 ENDPROC(cpu_resume_mmu)
 	.popsection
 cpu_resume_after_mmu:
+	kasan_unpoison_stack 96
 	mov	x0, #0			// return zero on success
 	ldp	x19, x20, [sp, #16]
 	ldp	x21, x22, [sp, #32]
-- 
1.9.1



From wens at csie.org  Thu Feb 18 09:28:13 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Thu, 18 Feb 2016 09:28:13 -0800
Subject: [PATCH v2 2/8] drivers: pinctrl: add driver for Allwinner A64 SoC
In-Reply-To: <1455709440-8668-3-git-send-email-andre.przywara@arm.com>
References: <1455709440-8668-1-git-send-email-andre.przywara@arm.com>
 <1455709440-8668-3-git-send-email-andre.przywara@arm.com>
Message-ID: <CAGb2v67UkRv86rUMfY9u+szv7CKAK9wh8kfoqWh8XUCkifjjUQ@mail.gmail.com>

Hi,

On Wed, Feb 17, 2016 at 3:43 AM, Andre Przywara <andre.przywara at arm.com> wrote:
> Based on the Allwinner A64 user manual and on the previous sunxi
> pinctrl drivers this introduces the pin multiplex assignments for
> the ARMv8 Allwinner A64 SoC.
> Port A is apparently used for the fixed function DRAM controller, so
> the ports start at B here (the manual mentions "n from 1 to 7", so
> not starting at 0).
>
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
>  arch/arm64/Kconfig.platforms                       |   1 +
>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
>  drivers/pinctrl/sunxi/Makefile                     |   1 +
>  drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c         | 606 +++++++++++++++++++++
>  5 files changed, 613 insertions(+)
>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> index 9213b27..08b2361 100644
> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> @@ -21,6 +21,7 @@ Required properties:
>    "allwinner,sun9i-a80-r-pinctrl"
>    "allwinner,sun8i-a83t-pinctrl"
>    "allwinner,sun8i-h3-pinctrl"
> +  "allwinner,sun50i-a64-pinctrl"
>
>  - reg: Should contain the register physical address and length for the
>    pin controller.
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 2f7f69b..d15c532 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -2,6 +2,7 @@ menu "Platform selection"
>
>  config ARCH_SUNXI
>         bool "Allwinner sunxi 64-bit SoC Family"
> +       select PINCTRL_SUN50I_A64
>         help
>           This enables support for Allwinner sunxi based SoCs like the A64.
>
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index 1868b82..aaf075b 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -68,4 +68,8 @@ config PINCTRL_SUN9I_A80_R
>         depends on RESET_CONTROLLER
>         select PINCTRL_SUNXI
>
> +config PINCTRL_SUN50I_A64
> +       bool
> +       select PINCTRL_SUNXI
> +
>  endif
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index f22de0e..2d8b64e 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_PINCTRL_SUN7I_A20)               += pinctrl-sun7i-a20.o
>  obj-$(CONFIG_PINCTRL_SUN8I_A23)                += pinctrl-sun8i-a23.o
>  obj-$(CONFIG_PINCTRL_SUN8I_A23_R)      += pinctrl-sun8i-a23-r.o
>  obj-$(CONFIG_PINCTRL_SUN8I_A33)                += pinctrl-sun8i-a33.o
> +obj-$(CONFIG_PINCTRL_SUN50I_A64)       += pinctrl-sun50i-a64.o
>  obj-$(CONFIG_PINCTRL_SUN8I_A83T)       += pinctrl-sun8i-a83t.o
>  obj-$(CONFIG_PINCTRL_SUN8I_H3)         += pinctrl-sun8i-h3.o
>  obj-$(CONFIG_PINCTRL_SUN8I_H3_R)       += pinctrl-sun8i-h3-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c
> new file mode 100644
> index 0000000..20bd15b
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c
> @@ -0,0 +1,606 @@
> +/*
> + * Allwinner A64 SoCs pinctrl driver.
> + *
> + * Copyright (C) 2016 - ARM Ltd.
> + * Author: Andre Przywara <andre.przywara at arm.com>
> + *
> + * Based on pinctrl-sun7i-a20.c, which is:
> + * Copyright (C) 2014 Maxime Ripard <maxime.ripard at free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/pinctrl/pinctrl.h>
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin a64_pins[] = {

[...]

> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 8),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION(0x2, "owa"),           /* OUT */

This is better known as spdif.

> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 8)),  /* EINT8 */
> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 9),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 9)),  /* EINT9 */
> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 10),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION(0x2, "mic"),           /* CLK */
> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 10)), /* EINT10 */
> +       SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 11),
> +                 SUNXI_FUNCTION(0x0, "gpio_in"),
> +                 SUNXI_FUNCTION(0x1, "gpio_out"),
> +                 SUNXI_FUNCTION(0x2, "mic"),           /* DATA */
> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 11)), /* EINT11 */
> +};
> +
> +static const struct sunxi_pinctrl_desc a64_pinctrl_data = {
> +       .pins = a64_pins,
> +       .npins = ARRAY_SIZE(a64_pins),
> +       .irq_banks = 3,
> +};
> +
> +static int a64_pinctrl_probe(struct platform_device *pdev)
> +{
> +       return sunxi_pinctrl_init(pdev,
> +                                 &a64_pinctrl_data);
> +}
> +
> +static const struct of_device_id a64_pinctrl_match[] = {
> +       { .compatible = "allwinner,sun50i-a64-pinctrl", },
> +       {}
> +};
> +MODULE_DEVICE_TABLE(of, a64_pinctrl_match);
> +
> +static struct platform_driver a64_pinctrl_driver = {
> +       .probe  = a64_pinctrl_probe,
> +       .driver = {
> +               .name           = "sun50i-a64-pinctrl",
> +               .of_match_table = a64_pinctrl_match,
> +       },
> +};
> +module_platform_driver(a64_pinctrl_driver);

Since the Kconfig symbol is bool, you could probably use
builtin_platform_driver and drop MODULE_*.

Regards
ChenYu

> +
> +MODULE_AUTHOR("Andre Przywara <andre.przywara at arm.com>");
> +MODULE_DESCRIPTION("Allwinner A64 pinctrl driver");
> +MODULE_LICENSE("GPL");
> --
> 2.6.4
>


From lina.iyer at linaro.org  Thu Feb 18 09:29:33 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Thu, 18 Feb 2016 10:29:33 -0700
Subject: [BUG FIX] PM / cpu_domains: Check for NULL callbacks
In-Reply-To: <1455310238-8963-4-git-send-email-lina.iyer@linaro.org>
References: <1455310238-8963-4-git-send-email-lina.iyer@linaro.org>
Message-ID: <1455816573-43849-1-git-send-email-lina.iyer@linaro.org>

Check for NULL platform callback before calling.

Signed-off-by: Lina Iyer <lina.iyer at linaro.org>
---
 drivers/base/power/cpu_domains.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/base/power/cpu_domains.c b/drivers/base/power/cpu_domains.c
index 7069411..bcaa474 100644
--- a/drivers/base/power/cpu_domains.c
+++ b/drivers/base/power/cpu_domains.c
@@ -157,16 +157,22 @@ static int cpu_pd_power_on(struct generic_pm_domain *genpd)
 {
 	struct cpu_pm_domain *pd = to_cpu_pd(genpd);
 
-	return pd->ops.power_on();
+	if (pd->ops.power_on)
+		return pd->ops.power_on();
+
+	return 0;
 }
 
 static int cpu_pd_power_off(struct generic_pm_domain *genpd)
 {
 	struct cpu_pm_domain *pd = to_cpu_pd(genpd);
 
-	return pd->ops.power_off(genpd->state_idx,
+	if (pd->ops.power_off)
+		return pd->ops.power_off(genpd->state_idx,
 			genpd->states[genpd->state_idx].param,
 			pd->cpus);
+
+	return 0;
 }
 
 /**
-- 
2.1.4



From nicolas.pitre at linaro.org  Thu Feb 18 09:31:35 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Feb 2016 12:31:35 -0500 (EST)
Subject: [PATCH 1/3] [RESEND] ARM: pass -march=armv7-a when building NEON
 files with clang
In-Reply-To: <1455815113-2562966-2-git-send-email-arnd@arndb.de>
References: <1455815113-2562966-1-git-send-email-arnd@arndb.de>
 <1455815113-2562966-2-git-send-email-arnd@arndb.de>
Message-ID: <alpine.LFD.2.20.1602181230440.13632@knanqh.ubzr>

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

> clang ignores the -mfpu=neon flag when building with -march=armv6:
> 
> In file included from lib/raid6/neon1.c:27:
> clang/3.8.0/include/arm_neon.h:28:2: error: "NEON support not enabled"
> 
> There is no real need to build the file with -march=armv6 in a
> multi-CPU enabled kernel, as nothing in here will ever get called
> on an ARMv6 CPU. Adding -march=armv7 doesn't hurt and can only
> improve the code quality.

Is this enough to override a previous -mfpu for gcc?


> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/lib/Makefile | 2 +-
>  lib/raid6/Makefile    | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index d8a780799506..a86c6c8e0648 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -35,7 +35,7 @@ $(obj)/csumpartialcopy.o:	$(obj)/csumpartialcopygeneric.S
>  $(obj)/csumpartialcopyuser.o:	$(obj)/csumpartialcopygeneric.S
>  
>  ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
> -  NEON_FLAGS			:= -mfloat-abi=softfp -mfpu=neon
> +  NEON_FLAGS			:= -mfloat-abi=softfp -mfpu=neon -march=armv7-a
>    CFLAGS_xor-neon.o		+= $(NEON_FLAGS)
>    obj-$(CONFIG_XOR_BLOCKS)	+= xor-neon.o
>  endif
> diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
> index 3b10a48fa040..4ef3e800fb39 100644
> --- a/lib/raid6/Makefile
> +++ b/lib/raid6/Makefile
> @@ -23,7 +23,7 @@ endif
>  ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
>  NEON_FLAGS := -ffreestanding
>  ifeq ($(ARCH),arm)
> -NEON_FLAGS += -mfloat-abi=softfp -mfpu=neon
> +NEON_FLAGS += -mfloat-abi=softfp -mfpu=neon -march=armv7-a
>  endif
>  ifeq ($(ARCH),arm64)
>  CFLAGS_REMOVE_neon1.o += -mgeneral-regs-only
> -- 
> 2.7.0
> 
> 


From will.deacon at arm.com  Thu Feb 18 09:32:48 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 18 Feb 2016 17:32:48 +0000
Subject: [PATCH v4 3/5] arm64: dts: Add Cavium ThunderX specific PMU
In-Reply-To: <2b8c963d3e63ecfc412bfd6fab804890a1586b16.1455810755.git.jglauber@cavium.com>
References: <cover.1455810755.git.jglauber@cavium.com>
 <2b8c963d3e63ecfc412bfd6fab804890a1586b16.1455810755.git.jglauber@cavium.com>
Message-ID: <20160218173248.GD16883@arm.com>

On Thu, Feb 18, 2016 at 05:50:12PM +0100, Jan Glauber wrote:
> Add a compatible string for the Cavium ThunderX PMU.

Stupid question, but is "thunder" the name of the CPU or the SoC or ...?

Whatever we use to describe the PMU, should probably also identify the
CPU uniquely.

Will

> Signed-off-by: Jan Glauber <jglauber at cavium.com>
> ---
>  Documentation/devicetree/bindings/arm/pmu.txt | 1 +
>  arch/arm64/boot/dts/cavium/thunder-88xx.dtsi  | 5 +++++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt
> index 5651883..d3999a1 100644
> --- a/Documentation/devicetree/bindings/arm/pmu.txt
> +++ b/Documentation/devicetree/bindings/arm/pmu.txt
> @@ -25,6 +25,7 @@ Required properties:
>  	"qcom,scorpion-pmu"
>  	"qcom,scorpion-mp-pmu"
>  	"qcom,krait-pmu"
> +	"cavium,thunder-pmu"
>  - interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu
>                 interrupt (PPI) then 1 interrupt should be specified.
>  
> diff --git a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
> index 9cb7cf9..2eb9b22 100644
> --- a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
> +++ b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
> @@ -360,6 +360,11 @@
>  		             <1 10 0xff01>;
>  	};
>  
> +	pmu {
> +		compatible = "cavium,thunder-pmu", "arm,armv8-pmuv3";
> +		interrupts = <1 7 4>;
> +	};
> +
>  	soc {
>  		compatible = "simple-bus";
>  		#address-cells = <2>;
> -- 
> 1.9.1
> 


From gregory.clement at free-electrons.com  Thu Feb 18 09:32:23 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 18 Feb 2016 18:32:23 +0100
Subject: [PATCH v2 net-next 0/8] API set for HW Buffer management
In-Reply-To: <20160217225958.GA31113@1wt.eu> (Willy Tarreau's message of "Wed, 
 17 Feb 2016 23:59:58 +0100")
References: <1455636823-14470-1-git-send-email-gregory.clement@free-electrons.com>
 <20160217225958.GA31113@1wt.eu>
Message-ID: <877fi1rkk8.fsf@free-electrons.com>

Hi Willy,
 
 On mer., f?vr. 17 2016, Willy Tarreau <w at 1wt.eu> wrote:

> Hi Gregory,
>
> On Tue, Feb 16, 2016 at 04:33:35PM +0100, Gregory CLEMENT wrote:
>> Hello,
>> 
>> A few weeks ago I sent a proposal for a API set for HW Buffer
>> management, to have a better view of the motivation for this API see
>> the cover letter of this proposal:
>> http://thread.gmane.org/gmane.linux.kernel/2125152
>> 
>> Since this version I took into account the review from Florian:
>> - The hardware buffer management helpers are no more built by default
>>   and now depend on a hidden config symbol which has to be selected
>>   by the driver if needed
>> - The hwbm_pool_refill() and hwbm_pool_add() now receive a gfp_t as
>>   argument allowing the caller to specify the flag it needs.
>> - buf_num is now tested to ensure there is no wrapping
>> - A spinlock has been added to protect the hwbm_pool_add() function in
>>   SMP or irq context.
>> 
>> I also used pr_warn instead of pr_debug in case of errors.
>> 
>> I fixed the mvneta implementation by returning the buffer to the pool
>> at various place instead of ignoring it.
>> 
>> About the series itself I tried to make this series easier to merge:
>> - Squashed "bus: mvenus-mbus: Fix size test for
>>    mvebu_mbus_get_dram_win_info" into bus: mvebu-mbus: provide api for
>>    obtaining IO and DRAM window information.
>> - Added my signed-otf-by on all the patches as submitter of the series.
>> - Renamed the dts patches with the pattern "ARM: dts: platform:"
>> - Removed the patch "ARM: mvebu: enable SRAM support in
>>   mvebu_v7_defconfig" of this series and already applied it
>> - Rodified the order of the patches.
>> 
>> In order to ease the test the branch mvneta-BM-framework-v2 is
>> available at git at github.com:MISL-EBU-System-SW/mainline-public.git.
>
> Well, I tested this patch series on top of latest master (from today)
> on my fresh new clearfog board. I compared carefully with and without
> the patchset. My workload was haproxy receiving connections and forwarding
> them to my PC via the same port. I tested both with short connections
> (HTTP GET of an empty file) and long ones (1 MB or more). No trouble
> was detected at all, which is pretty good. I noticed a very tiny
> performance drop which is more noticeable on short connections (high
> packet rates), my forwarded connection rate went down from 17500/s to
> 17300/s. But I have not checked yet what can be tuned when using the
> BM, nor did I compare CPU usage. I remember having run some tests in
> the past, I guess it was on the XP-GP board, and noticed that the BM
> could save a significant amount of CPU and improve cache efficiency,
> so if this is the case here, we don't really care about a possible 1%
> performance drop.
>
> I'll try to provide more results as time permits.
>
> In the mean time if you want (or plan to submit a next batch), feel
> free to add a Tested-by: Willy Tarreau <w at 1wt.eu>.

Great!  thanks for testing.

Gregory

>
> cheers,
> Willy
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From nicolas.pitre at linaro.org  Thu Feb 18 09:34:17 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Feb 2016 12:34:17 -0500 (EST)
Subject: [PATCH 2/3] [RESEND] ARM: fix copypage-*.c building with clang
In-Reply-To: <1455815113-2562966-3-git-send-email-arnd@arndb.de>
References: <1455815113-2562966-1-git-send-email-arnd@arndb.de>
 <1455815113-2562966-3-git-send-email-arnd@arndb.de>
Message-ID: <alpine.LFD.2.20.1602181233480.13632@knanqh.ubzr>

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

> clang does not allow inline assembly in __naked functions to
> have any register parameters and throws an error:
> 
> arch/arm/mm/copypage-v4wb.c:47:9: error: parameter references not allowed in naked functions
>         : "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64));
> 
> Fortunately, all of these functions are trivial to convert to
> using the registers directly.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Acked-by: Nicolas Pitre <nico at linaro.org>


> ---
>  arch/arm/mm/copypage-feroceon.c |  4 ++--
>  arch/arm/mm/copypage-v4mc.c     | 26 +++++++++++++-------------
>  arch/arm/mm/copypage-v4wb.c     |  4 ++--
>  arch/arm/mm/copypage-v4wt.c     |  4 ++--
>  arch/arm/mm/copypage-xsc3.c     |  4 ++--
>  arch/arm/mm/copypage-xscale.c   |  4 ++--
>  6 files changed, 23 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/arm/mm/copypage-feroceon.c b/arch/arm/mm/copypage-feroceon.c
> index 49ee0c1a7209..e69bf2f15f32 100644
> --- a/arch/arm/mm/copypage-feroceon.c
> +++ b/arch/arm/mm/copypage-feroceon.c
> @@ -18,7 +18,7 @@ feroceon_copy_user_page(void *kto, const void *kfrom)
>  {
>  	asm("\
>  	stmfd	sp!, {r4-r9, lr}		\n\
> -	mov	ip, %2				\n\
> +	mov	ip, %0				\n\
>  1:	mov	lr, r1				\n\
>  	ldmia	r1!, {r2 - r9}			\n\
>  	pld	[lr, #32]			\n\
> @@ -64,7 +64,7 @@ feroceon_copy_user_page(void *kto, const void *kfrom)
>  	mcr	p15, 0, ip, c7, c10, 4		@ drain WB\n\
>  	ldmfd	sp!, {r4-r9, pc}"
>  	:
> -	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE));
> +	: "I" (PAGE_SIZE));
>  }
>  
>  void feroceon_copy_user_highpage(struct page *to, struct page *from,
> diff --git a/arch/arm/mm/copypage-v4mc.c b/arch/arm/mm/copypage-v4mc.c
> index 1267e64133b9..ea89722c00db 100644
> --- a/arch/arm/mm/copypage-v4mc.c
> +++ b/arch/arm/mm/copypage-v4mc.c
> @@ -45,23 +45,23 @@ mc_copy_user_page(void *from, void *to)
>  {
>  	asm volatile(
>  	"stmfd	sp!, {r4, lr}			@ 2\n\
> -	mov	r4, %2				@ 1\n\
> -	ldmia	%0!, {r2, r3, ip, lr}		@ 4\n\
> -1:	mcr	p15, 0, %1, c7, c6, 1		@ 1   invalidate D line\n\
> -	stmia	%1!, {r2, r3, ip, lr}		@ 4\n\
> -	ldmia	%0!, {r2, r3, ip, lr}		@ 4+1\n\
> -	stmia	%1!, {r2, r3, ip, lr}		@ 4\n\
> -	ldmia	%0!, {r2, r3, ip, lr}		@ 4\n\
> -	mcr	p15, 0, %1, c7, c6, 1		@ 1   invalidate D line\n\
> -	stmia	%1!, {r2, r3, ip, lr}		@ 4\n\
> -	ldmia	%0!, {r2, r3, ip, lr}		@ 4\n\
> +	mov	r4, %0				@ 1\n\
> +	ldmia	r0!, {r2, r3, ip, lr}		@ 4\n\
> +1:	mcr	p15, 0, r1, c7, c6, 1		@ 1   invalidate D line\n\
> +	stmia	r1!, {r2, r3, ip, lr}		@ 4\n\
> +	ldmia	r0!, {r2, r3, ip, lr}		@ 4+1\n\
> +	stmia	r1!, {r2, r3, ip, lr}		@ 4\n\
> +	ldmia	r0!, {r2, r3, ip, lr}		@ 4\n\
> +	mcr	p15, 0, r1, c7, c6, 1		@ 1   invalidate D line\n\
> +	stmia	r1!, {r2, r3, ip, lr}		@ 4\n\
> +	ldmia	r0!, {r2, r3, ip, lr}		@ 4\n\
>  	subs	r4, r4, #1			@ 1\n\
> -	stmia	%1!, {r2, r3, ip, lr}		@ 4\n\
> -	ldmneia	%0!, {r2, r3, ip, lr}		@ 4\n\
> +	stmia	r1!, {r2, r3, ip, lr}		@ 4\n\
> +	ldmneia	r0!, {r2, r3, ip, lr}		@ 4\n\
>  	bne	1b				@ 1\n\
>  	ldmfd	sp!, {r4, pc}			@ 3"
>  	:
> -	: "r" (from), "r" (to), "I" (PAGE_SIZE / 64));
> +	: "I" (PAGE_SIZE / 64));
>  }
>  
>  void v4_mc_copy_user_highpage(struct page *to, struct page *from,
> diff --git a/arch/arm/mm/copypage-v4wb.c b/arch/arm/mm/copypage-v4wb.c
> index 067d0fdd630c..7ea9cf07bd5c 100644
> --- a/arch/arm/mm/copypage-v4wb.c
> +++ b/arch/arm/mm/copypage-v4wb.c
> @@ -27,7 +27,7 @@ v4wb_copy_user_page(void *kto, const void *kfrom)
>  {
>  	asm("\
>  	stmfd	sp!, {r4, lr}			@ 2\n\
> -	mov	r2, %2				@ 1\n\
> +	mov	r2, %0				@ 1\n\
>  	ldmia	r1!, {r3, r4, ip, lr}		@ 4\n\
>  1:	mcr	p15, 0, r0, c7, c6, 1		@ 1   invalidate D line\n\
>  	stmia	r0!, {r3, r4, ip, lr}		@ 4\n\
> @@ -44,7 +44,7 @@ v4wb_copy_user_page(void *kto, const void *kfrom)
>  	mcr	p15, 0, r1, c7, c10, 4		@ 1   drain WB\n\
>  	ldmfd	 sp!, {r4, pc}			@ 3"
>  	:
> -	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64));
> +	: "I" (PAGE_SIZE / 64));
>  }
>  
>  void v4wb_copy_user_highpage(struct page *to, struct page *from,
> diff --git a/arch/arm/mm/copypage-v4wt.c b/arch/arm/mm/copypage-v4wt.c
> index b85c5da2e510..c742ab24efd6 100644
> --- a/arch/arm/mm/copypage-v4wt.c
> +++ b/arch/arm/mm/copypage-v4wt.c
> @@ -25,7 +25,7 @@ v4wt_copy_user_page(void *kto, const void *kfrom)
>  {
>  	asm("\
>  	stmfd	sp!, {r4, lr}			@ 2\n\
> -	mov	r2, %2				@ 1\n\
> +	mov	r2, %0				@ 1\n\
>  	ldmia	r1!, {r3, r4, ip, lr}		@ 4\n\
>  1:	stmia	r0!, {r3, r4, ip, lr}		@ 4\n\
>  	ldmia	r1!, {r3, r4, ip, lr}		@ 4+1\n\
> @@ -40,7 +40,7 @@ v4wt_copy_user_page(void *kto, const void *kfrom)
>  	mcr	p15, 0, r2, c7, c7, 0		@ flush ID cache\n\
>  	ldmfd	sp!, {r4, pc}			@ 3"
>  	:
> -	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64));
> +	: "I" (PAGE_SIZE / 64));
>  }
>  
>  void v4wt_copy_user_highpage(struct page *to, struct page *from,
> diff --git a/arch/arm/mm/copypage-xsc3.c b/arch/arm/mm/copypage-xsc3.c
> index 03a2042aced5..17e4e11c4612 100644
> --- a/arch/arm/mm/copypage-xsc3.c
> +++ b/arch/arm/mm/copypage-xsc3.c
> @@ -34,7 +34,7 @@ xsc3_mc_copy_user_page(void *kto, const void *kfrom)
>  {
>  	asm("\
>  	stmfd	sp!, {r4, r5, lr}		\n\
> -	mov	lr, %2				\n\
> +	mov	lr, %0				\n\
>  						\n\
>  	pld	[r1, #0]			\n\
>  	pld	[r1, #32]			\n\
> @@ -67,7 +67,7 @@ xsc3_mc_copy_user_page(void *kto, const void *kfrom)
>  						\n\
>  	ldmfd	sp!, {r4, r5, pc}"
>  	:
> -	: "r" (kto), "r" (kfrom), "I" (PAGE_SIZE / 64 - 1));
> +	: "I" (PAGE_SIZE / 64 - 1));
>  }
>  
>  void xsc3_mc_copy_user_highpage(struct page *to, struct page *from,
> diff --git a/arch/arm/mm/copypage-xscale.c b/arch/arm/mm/copypage-xscale.c
> index 0fb85025344d..1034b4ce80cc 100644
> --- a/arch/arm/mm/copypage-xscale.c
> +++ b/arch/arm/mm/copypage-xscale.c
> @@ -45,7 +45,7 @@ mc_copy_user_page(void *from, void *to)
>  	 */
>  	asm volatile(
>  	"stmfd	sp!, {r4, r5, lr}		\n\
> -	mov	lr, %2				\n\
> +	mov	lr, %0				\n\
>  	pld	[r0, #0]			\n\
>  	pld	[r0, #32]			\n\
>  	pld	[r1, #0]			\n\
> @@ -81,7 +81,7 @@ mc_copy_user_page(void *from, void *to)
>  	beq	2b				\n\
>  	ldmfd	sp!, {r4, r5, pc}		"
>  	:
> -	: "r" (from), "r" (to), "I" (PAGE_SIZE / 64 - 1));
> +	: "I" (PAGE_SIZE / 64 - 1));
>  }
>  
>  void xscale_mc_copy_user_highpage(struct page *to, struct page *from,
> -- 
> 2.7.0
> 
> 


From will.deacon at arm.com  Thu Feb 18 09:34:28 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 18 Feb 2016 17:34:28 +0000
Subject: [PATCH v4 4/5] arm64/perf: Enable PMCR long cycle counter bit
In-Reply-To: <467597048eda3004bd69f1fbe3981aab111e00dd.1455810755.git.jglauber@cavium.com>
References: <cover.1455810755.git.jglauber@cavium.com>
 <467597048eda3004bd69f1fbe3981aab111e00dd.1455810755.git.jglauber@cavium.com>
Message-ID: <20160218173428.GE16883@arm.com>

On Thu, Feb 18, 2016 at 05:50:13PM +0100, Jan Glauber wrote:
> With the long cycle counter bit (LC) disabled the cycle counter is not
> working on ThunderX SOC (ThunderX only implements Aarch64).
> Also, according to documentation LC == 0 is deprecated.
> 
> To keep the code simple the patch does not introduce 64 bit wide counter
> functions. Instead writing the cycle counter always sets the upper
> 32 bits so overflow interrupts are generated as before.
> 
> Original patch from Andrew Pinksi <Andrew.Pinksi at caviumnetworks.com>

What does this mean? Do we need Andrew's S-o-B, or is this a fresh patch?

Will


From gregory.clement at free-electrons.com  Thu Feb 18 09:37:51 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 18 Feb 2016 18:37:51 +0100
Subject: [PATCH v4 03/12] serial: mvebu-uart: initial support for
 Armada-3700 serial port
In-Reply-To: <1455646502-23834-4-git-send-email-gregory.clement@free-electrons.com>
 (Gregory CLEMENT's message of "Tue, 16 Feb 2016 19:14:53 +0100")
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
 <1455646502-23834-4-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <8737sprkb4.fsf@free-electrons.com>

Hi Greg and Jiri
 
 On mar., f?vr. 16 2016, Gregory CLEMENT <gregory.clement at free-electrons.com> wrote:

> From: Wilson Ding <dingwei at marvell.com>
>
> Armada-3700's uart is a simple serial port, which doesn't
> support. Configuring the modem control lines. The uart port has a 32
> bytes Tx FIFO and a 64 bytes Rx FIFO
>
> The uart driver implements the uart core operations. It also support the
> system (early) console based on Armada-3700's serial port.
>
> Known Issue:
>
> The uart driver currently doesn't support clock programming, which means
> the baud-rate stays with the default value configured by the bootloader
> at boot time
>
> [gregory.clement at free-electrons.com: Rewrite many part which are too long
> to enumerate]
>
> Signed-off-by: Wilson Ding <dingwei at marvell.com>
> Signed-off-by: Nadav Haklai <nadavh at marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Acked-by: Rob Herring <robh at kernel.org>

I took care of the arm related part of the series, but I will let you
apply this patch in the serial subsystem once you have reviewed it. But
if for any reason you preferred that I took it through mvebu just tell
me.

Thanks,

Gregory

> ---
>  .../devicetree/bindings/tty/serial/mvebu-uart.txt  |  13 +
>  Documentation/kernel-parameters.txt                |   6 +
>  drivers/tty/serial/Kconfig                         |  22 +
>  drivers/tty/serial/Makefile                        |   1 +
>  drivers/tty/serial/mvebu-uart.c                    | 650 +++++++++++++++++++++
>  include/uapi/linux/serial_core.h                   |   3 +
>  6 files changed, 695 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
>  create mode 100644 drivers/tty/serial/mvebu-uart.c
>
> diff --git a/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
> new file mode 100644
> index 000000000000..6087defd9f93
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/tty/serial/mvebu-uart.txt
> @@ -0,0 +1,13 @@
> +* Marvell UART : Non standard UART used in some of Marvell EBU SoCs (e.g., Armada-3700)
> +
> +Required properties:
> +- compatible: "marvell,armada-3700-uart"
> +- reg: offset and length of the register set for the device.
> +- interrupts: device interrupt
> +
> +Example:
> +	serial at 12000 {
> +		compatible = "marvell,armada-3700-uart";
> +		reg = <0x12000 0x400>;
> +		interrupts = <43>;
> +	};
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 87d40a72f6a1..ea0aba48d616 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1058,6 +1058,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>  			A valid base address must be provided, and the serial
>  			port must already be setup and configured.
>  
> +		armada3700_uart,<addr>
> +			Start an early, polled-mode console on the
> +			Armada 3700 serial port at the specified
> +			address. The serial port must already be setup
> +			and configured. Options are not yet supported.
> +
>  	earlyprintk=	[X86,SH,BLACKFIN,ARM,M68k]
>  			earlyprintk=vga
>  			earlyprintk=efi
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 39721ec4f415..b291f934d51b 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1606,6 +1606,28 @@ config SERIAL_STM32_CONSOLE
>  	depends on SERIAL_STM32=y
>  	select SERIAL_CORE_CONSOLE
>  
> +config SERIAL_MVEBU_UART
> +	bool "Marvell EBU serial port support"
> +	select SERIAL_CORE
> +	help
> +	  This driver is for Marvell EBU SoC's UART. If you have a machine
> +	  based on the Armada-3700 SoC and wish to use the on-board serial
> +	  port,
> +	  say 'Y' here.
> +	  Otherwise, say 'N'.
> +
> +config SERIAL_MVEBU_CONSOLE
> +	bool "Console on Marvell EBU serial port"
> +	depends on SERIAL_MVEBU_UART
> +	select SERIAL_CORE_CONSOLE
> +	select SERIAL_EARLYCON
> +	default y
> +	help
> +	  Say 'Y' here if you wish to use Armada-3700 UART as the system console.
> +	  (the system console is the device which receives all kernel messages
> +	  and warnings and which allows logins in single user mode)
> +	  Otherwise, say 'N'.
> +
>  endmenu
>  
>  config SERIAL_MCTRL_GPIO
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index b391c9b31960..988167595330 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -91,6 +91,7 @@ obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
>  obj-$(CONFIG_SERIAL_MEN_Z135)	+= men_z135_uart.o
>  obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
>  obj-$(CONFIG_SERIAL_STM32)	+= stm32-usart.o
> +obj-$(CONFIG_SERIAL_MVEBU_UART)	+= mvebu-uart.o
>  
>  # GPIOLIB helpers for modem control lines
>  obj-$(CONFIG_SERIAL_MCTRL_GPIO)	+= serial_mctrl_gpio.o
> diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
> new file mode 100644
> index 000000000000..0ff27818bb87
> --- /dev/null
> +++ b/drivers/tty/serial/mvebu-uart.c
> @@ -0,0 +1,650 @@
> +/*
> +* ***************************************************************************
> +* Copyright (C) 2015 Marvell International Ltd.
> +* ***************************************************************************
> +* This program is free software: you can redistribute it and/or modify it
> +* under the terms of the GNU General Public License as published by the Free
> +* Software Foundation, either version 2 of the License, or any later version.
> +*
> +* This program is distributed in the hope that it will be useful,
> +* but WITHOUT ANY WARRANTY; without even the implied warranty of
> +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +* GNU General Public License for more details.
> +*
> +* 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/clk.h>
> +#include <linux/console.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_device.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/serial.h>
> +#include <linux/serial_core.h>
> +#include <linux/slab.h>
> +#include <linux/tty.h>
> +#include <linux/tty_flip.h>
> +
> +/* Register Map */
> +#define UART_RBR		0x00
> +#define  RBR_BRK_DET		BIT(15)
> +#define  RBR_FRM_ERR_DET	BIT(14)
> +#define  RBR_PAR_ERR_DET	BIT(13)
> +#define  RBR_OVR_ERR_DET	BIT(12)
> +
> +#define UART_TSH		0x04
> +
> +#define UART_CTRL		0x08
> +#define  CTRL_SOFT_RST		BIT(31)
> +#define  CTRL_TXFIFO_RST	BIT(15)
> +#define  CTRL_RXFIFO_RST	BIT(14)
> +#define  CTRL_ST_MIRR_EN	BIT(13)
> +#define  CTRL_LPBK_EN		BIT(12)
> +#define  CTRL_SND_BRK_SEQ	BIT(11)
> +#define  CTRL_PAR_EN		BIT(10)
> +#define  CTRL_TWO_STOP		BIT(9)
> +#define  CTRL_TX_HFL_INT	BIT(8)
> +#define  CTRL_RX_HFL_INT	BIT(7)
> +#define  CTRL_TX_EMP_INT	BIT(6)
> +#define  CTRL_TX_RDY_INT	BIT(5)
> +#define  CTRL_RX_RDY_INT	BIT(4)
> +#define  CTRL_BRK_DET_INT	BIT(3)
> +#define  CTRL_FRM_ERR_INT	BIT(2)
> +#define  CTRL_PAR_ERR_INT	BIT(1)
> +#define  CTRL_OVR_ERR_INT	BIT(0)
> +#define  CTRL_RX_INT			(CTRL_RX_RDY_INT | CTRL_BRK_DET_INT |\
> +	CTRL_FRM_ERR_INT | CTRL_PAR_ERR_INT | CTRL_OVR_ERR_INT)
> +
> +#define UART_STAT		0x0c
> +#define  STAT_TX_FIFO_EMP	BIT(13)
> +#define  STAT_RX_FIFO_EMP	BIT(12)
> +#define  STAT_TX_FIFO_FUL	BIT(11)
> +#define  STAT_TX_FIFO_HFL	BIT(10)
> +#define  STAT_RX_TOGL		BIT(9)
> +#define  STAT_RX_FIFO_FUL	BIT(8)
> +#define  STAT_RX_FIFO_HFL	BIT(7)
> +#define  STAT_TX_EMP		BIT(6)
> +#define  STAT_TX_RDY		BIT(5)
> +#define  STAT_RX_RDY		BIT(4)
> +#define  STAT_BRK_DET		BIT(3)
> +#define  STAT_FRM_ERR		BIT(2)
> +#define  STAT_PAR_ERR		BIT(1)
> +#define  STAT_OVR_ERR		BIT(0)
> +#define  STAT_BRK_ERR		(STAT_BRK_DET | STAT_FRM_ERR | STAT_FRM_ERR\
> +				 | STAT_PAR_ERR | STAT_OVR_ERR)
> +
> +#define UART_BRDV		0x10
> +
> +#define MVEBU_NR_UARTS		1
> +
> +#define MVEBU_UART_TYPE		"mvebu-uart"
> +
> +static struct uart_port mvebu_uart_ports[MVEBU_NR_UARTS];
> +
> +struct mvebu_uart_data {
> +	struct uart_port *port;
> +	struct clk       *clk;
> +};
> +
> +/* Core UART Driver Operations */
> +static unsigned int mvebu_uart_tx_empty(struct uart_port *port)
> +{
> +	unsigned long flags;
> +	unsigned int st;
> +
> +	spin_lock_irqsave(&port->lock, flags);
> +	st = readl(port->membase + UART_STAT);
> +	spin_unlock_irqrestore(&port->lock, flags);
> +
> +	return (st & STAT_TX_FIFO_EMP) ? TIOCSER_TEMT : 0;
> +}
> +
> +static unsigned int mvebu_uart_get_mctrl(struct uart_port *port)
> +{
> +	return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
> +}
> +
> +static void mvebu_uart_set_mctrl(struct uart_port *port,
> +				 unsigned int mctrl)
> +{
> +/*
> + * Even if we do not support configuring the modem control lines, this
> + * function must be proided to the serial core
> + */
> +}
> +
> +static void mvebu_uart_stop_tx(struct uart_port *port)
> +{
> +	unsigned int ctl = readl(port->membase + UART_CTRL);
> +
> +	ctl &= ~CTRL_TX_RDY_INT;
> +	writel(ctl, port->membase + UART_CTRL);
> +}
> +
> +static void mvebu_uart_start_tx(struct uart_port *port)
> +{
> +	unsigned int ctl = readl(port->membase + UART_CTRL);
> +
> +	ctl |= CTRL_TX_RDY_INT;
> +	writel(ctl, port->membase + UART_CTRL);
> +}
> +
> +static void mvebu_uart_stop_rx(struct uart_port *port)
> +{
> +	unsigned int ctl = readl(port->membase + UART_CTRL);
> +
> +	ctl &= ~CTRL_RX_INT;
> +	writel(ctl, port->membase + UART_CTRL);
> +}
> +
> +static void mvebu_uart_break_ctl(struct uart_port *port, int brk)
> +{
> +	unsigned int ctl;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&port->lock, flags);
> +	ctl = readl(port->membase + UART_CTRL);
> +	if (brk == -1)
> +		ctl |= CTRL_SND_BRK_SEQ;
> +	else
> +		ctl &= ~CTRL_SND_BRK_SEQ;
> +	writel(ctl, port->membase + UART_CTRL);
> +	spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +static void mvebu_uart_rx_chars(struct uart_port *port, unsigned int status)
> +{
> +	struct tty_port *tport = &port->state->port;
> +	unsigned char ch = 0;
> +	char flag = 0;
> +
> +	do {
> +		if (status & STAT_RX_RDY) {
> +			ch = readl(port->membase + UART_RBR);
> +			ch &= 0xff;
> +			flag = TTY_NORMAL;
> +			port->icount.rx++;
> +
> +			if (status & STAT_PAR_ERR)
> +				port->icount.parity++;
> +		}
> +
> +		if (status & STAT_BRK_DET) {
> +			port->icount.brk++;
> +			status &= ~(STAT_FRM_ERR | STAT_PAR_ERR);
> +			if (uart_handle_break(port))
> +				goto ignore_char;
> +		}
> +
> +		if (status & STAT_OVR_ERR)
> +			port->icount.overrun++;
> +
> +		if (status & STAT_FRM_ERR)
> +			port->icount.frame++;
> +
> +		if (uart_handle_sysrq_char(port, ch))
> +			goto ignore_char;
> +
> +		if (status & port->ignore_status_mask & STAT_PAR_ERR)
> +			status &= ~STAT_RX_RDY;
> +
> +		status &= port->read_status_mask;
> +
> +		if (status & STAT_PAR_ERR)
> +			flag = TTY_PARITY;
> +
> +		status &= ~port->ignore_status_mask;
> +
> +		if (status & STAT_RX_RDY)
> +			tty_insert_flip_char(tport, ch, flag);
> +
> +		if (status & STAT_BRK_DET)
> +			tty_insert_flip_char(tport, 0, TTY_BREAK);
> +
> +		if (status & STAT_FRM_ERR)
> +			tty_insert_flip_char(tport, 0, TTY_FRAME);
> +
> +		if (status & STAT_OVR_ERR)
> +			tty_insert_flip_char(tport, 0, TTY_OVERRUN);
> +
> +ignore_char:
> +		status = readl(port->membase + UART_STAT);
> +	} while (status & (STAT_RX_RDY | STAT_BRK_DET));
> +
> +	tty_flip_buffer_push(tport);
> +}
> +
> +static void mvebu_uart_tx_chars(struct uart_port *port, unsigned int status)
> +{
> +	struct circ_buf *xmit = &port->state->xmit;
> +	unsigned int count;
> +	unsigned int st;
> +
> +	if (port->x_char) {
> +		writel(port->x_char, port->membase + UART_TSH);
> +		port->icount.tx++;
> +		port->x_char = 0;
> +		return;
> +	}
> +
> +	if (uart_circ_empty(xmit) || uart_tx_stopped(port)) {
> +		mvebu_uart_stop_tx(port);
> +		return;
> +	}
> +
> +	for (count = 0; count < port->fifosize; count++) {
> +		writel(xmit->buf[xmit->tail], port->membase + UART_TSH);
> +		xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
> +		port->icount.tx++;
> +
> +		if (uart_circ_empty(xmit))
> +			break;
> +
> +		st = readl(port->membase + UART_STAT);
> +		if (st & STAT_TX_FIFO_FUL)
> +			break;
> +	}
> +
> +	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
> +		uart_write_wakeup(port);
> +
> +	if (uart_circ_empty(xmit))
> +		mvebu_uart_stop_tx(port);
> +}
> +
> +static irqreturn_t mvebu_uart_isr(int irq, void *dev_id)
> +{
> +	struct uart_port *port = (struct uart_port *)dev_id;
> +	unsigned int st = readl(port->membase + UART_STAT);
> +
> +	if (st & (STAT_RX_RDY | STAT_OVR_ERR | STAT_FRM_ERR | STAT_BRK_DET))
> +		mvebu_uart_rx_chars(port, st);
> +
> +	if (st & STAT_TX_RDY)
> +		mvebu_uart_tx_chars(port, st);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static int mvebu_uart_startup(struct uart_port *port)
> +{
> +	int ret;
> +
> +	writel(CTRL_TXFIFO_RST | CTRL_RXFIFO_RST,
> +	       port->membase + UART_CTRL);
> +	udelay(1);
> +	writel(CTRL_RX_INT, port->membase + UART_CTRL);
> +
> +	ret = request_irq(port->irq, mvebu_uart_isr, port->irqflags, "serial",
> +			  port);
> +	if (ret) {
> +		dev_err(port->dev, "failed to request irq\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static void mvebu_uart_shutdown(struct uart_port *port)
> +{
> +	writel(0, port->membase + UART_CTRL);
> +}
> +
> +static void mvebu_uart_set_termios(struct uart_port *port,
> +				   struct ktermios *termios,
> +				   struct ktermios *old)
> +{
> +	unsigned long flags;
> +	unsigned int baud;
> +
> +	spin_lock_irqsave(&port->lock, flags);
> +
> +	port->read_status_mask = STAT_RX_RDY | STAT_OVR_ERR |
> +		STAT_TX_RDY | STAT_TX_FIFO_FUL;
> +
> +	if (termios->c_iflag & INPCK)
> +		port->read_status_mask |= STAT_FRM_ERR | STAT_PAR_ERR;
> +
> +	port->ignore_status_mask = 0;
> +	if (termios->c_iflag & IGNPAR)
> +		port->ignore_status_mask |=
> +			STAT_FRM_ERR | STAT_PAR_ERR | STAT_OVR_ERR;
> +
> +	if ((termios->c_cflag & CREAD) == 0)
> +		port->ignore_status_mask |= STAT_RX_RDY | STAT_BRK_ERR;
> +
> +	if (old)
> +		tty_termios_copy_hw(termios, old);
> +
> +	baud = uart_get_baud_rate(port, termios, old, 0, 460800);
> +	uart_update_timeout(port, termios->c_cflag, baud);
> +
> +	spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +static const char *mvebu_uart_type(struct uart_port *port)
> +{
> +	return MVEBU_UART_TYPE;
> +}
> +
> +static void mvebu_uart_release_port(struct uart_port *port)
> +{
> +	/* Nothing to do here */
> +}
> +
> +static int mvebu_uart_request_port(struct uart_port *port)
> +{
> +	return 0;
> +}
> +
> +#ifdef CONFIG_CONSOLE_POLL
> +static int mvebu_uart_get_poll_char(struct uart_port *port)
> +{
> +	unsigned int st = readl(port->membase + UART_STAT);
> +
> +	if (!(st & STAT_RX_RDY))
> +		return NO_POLL_CHAR;
> +
> +	return readl(port->membase + UART_RBR);
> +}
> +
> +static void mvebu_uart_put_poll_char(struct uart_port *port, unsigned char c)
> +{
> +	unsigned int st;
> +
> +	for (;;) {
> +		st = readl(port->membase + UART_STAT);
> +
> +		if (!(st & STAT_TX_FIFO_FUL))
> +			break;
> +
> +		udelay(1);
> +	}
> +
> +	writel(c, port->membase + UART_TSH);
> +}
> +#endif
> +
> +static const struct uart_ops mvebu_uart_ops = {
> +	.tx_empty	= mvebu_uart_tx_empty,
> +	.set_mctrl	= mvebu_uart_set_mctrl,
> +	.get_mctrl	= mvebu_uart_get_mctrl,
> +	.stop_tx	= mvebu_uart_stop_tx,
> +	.start_tx	= mvebu_uart_start_tx,
> +	.stop_rx	= mvebu_uart_stop_rx,
> +	.break_ctl	= mvebu_uart_break_ctl,
> +	.startup	= mvebu_uart_startup,
> +	.shutdown	= mvebu_uart_shutdown,
> +	.set_termios	= mvebu_uart_set_termios,
> +	.type		= mvebu_uart_type,
> +	.release_port	= mvebu_uart_release_port,
> +	.request_port	= mvebu_uart_request_port,
> +#ifdef CONFIG_CONSOLE_POLL
> +	.poll_get_char	= mvebu_uart_get_poll_char,
> +	.poll_put_char	= mvebu_uart_put_poll_char,
> +#endif
> +};
> +
> +/* Console Driver Operations  */
> +
> +#ifdef CONFIG_SERIAL_MVEBU_CONSOLE
> +/* Early Console */
> +static void mvebu_uart_putc(struct uart_port *port, int c)
> +{
> +	unsigned int st;
> +
> +	for (;;) {
> +		st = readl(port->membase + UART_STAT);
> +		if (!(st & STAT_TX_FIFO_FUL))
> +			break;
> +	}
> +
> +	writel(c, port->membase + UART_TSH);
> +
> +	for (;;) {
> +		st = readl(port->membase + UART_STAT);
> +		if (st & STAT_TX_FIFO_EMP)
> +			break;
> +	}
> +}
> +
> +static void mvebu_uart_putc_early_write(struct console *con,
> +					const char *s,
> +					unsigned n)
> +{
> +	struct earlycon_device *dev = con->data;
> +
> +	uart_console_write(&dev->port, s, n, mvebu_uart_putc);
> +}
> +
> +static int __init
> +mvebu_uart_early_console_setup(struct earlycon_device *device,
> +			       const char *opt)
> +{
> +	if (!device->port.membase)
> +		return -ENODEV;
> +
> +	device->con->write = mvebu_uart_putc_early_write;
> +
> +	return 0;
> +}
> +
> +EARLYCON_DECLARE(ar3700_uart, mvebu_uart_early_console_setup);
> +OF_EARLYCON_DECLARE(ar3700_uart, "marvell,armada-3700-uart",
> +		    mvebu_uart_early_console_setup);
> +
> +static void wait_for_xmitr(struct uart_port *port)
> +{
> +	u32 val;
> +
> +	readl_poll_timeout_atomic(port->membase + UART_STAT, val,
> +				  (val & STAT_TX_EMP), 1, 10000);
> +}
> +
> +static void mvebu_uart_console_putchar(struct uart_port *port, int ch)
> +{
> +	wait_for_xmitr(port);
> +	writel(ch, port->membase + UART_TSH);
> +}
> +
> +static void mvebu_uart_console_write(struct console *co, const char *s,
> +				     unsigned int count)
> +{
> +	struct uart_port *port = &mvebu_uart_ports[co->index];
> +	unsigned long flags;
> +	unsigned int ier;
> +	int locked = 1;
> +
> +	if (oops_in_progress)
> +		locked = spin_trylock_irqsave(&port->lock, flags);
> +	else
> +		spin_lock_irqsave(&port->lock, flags);
> +
> +	ier = readl(port->membase + UART_CTRL) &
> +		(CTRL_RX_INT | CTRL_TX_RDY_INT);
> +	writel(0, port->membase + UART_CTRL);
> +
> +	uart_console_write(port, s, count, mvebu_uart_console_putchar);
> +
> +	wait_for_xmitr(port);
> +
> +	if (ier)
> +		writel(ier, port->membase + UART_CTRL);
> +
> +	if (locked)
> +		spin_unlock_irqrestore(&port->lock, flags);
> +}
> +
> +static int mvebu_uart_console_setup(struct console *co, char *options)
> +{
> +	struct uart_port *port;
> +	int baud = 9600;
> +	int bits = 8;
> +	int parity = 'n';
> +	int flow = 'n';
> +
> +	if (co->index < 0 || co->index >= MVEBU_NR_UARTS)
> +		return -EINVAL;
> +
> +	port = &mvebu_uart_ports[co->index];
> +
> +	if (!port->mapbase || !port->membase) {
> +		pr_debug("console on ttyMV%i not present\n", co->index);
> +		return -ENODEV;
> +	}
> +
> +	if (options)
> +		uart_parse_options(options, &baud, &parity, &bits, &flow);
> +
> +	return uart_set_options(port, co, baud, parity, bits, flow);
> +}
> +
> +static struct uart_driver mvebu_uart_driver;
> +
> +static struct console mvebu_uart_console = {
> +	.name	= "ttyMV",
> +	.write	= mvebu_uart_console_write,
> +	.device	= uart_console_device,
> +	.setup	= mvebu_uart_console_setup,
> +	.flags	= CON_PRINTBUFFER,
> +	.index	= -1,
> +	.data	= &mvebu_uart_driver,
> +};
> +
> +static int __init mvebu_uart_console_init(void)
> +{
> +	register_console(&mvebu_uart_console);
> +	return 0;
> +}
> +
> +console_initcall(mvebu_uart_console_init);
> +
> +
> +#endif /* CONFIG_SERIAL_MVEBU_CONSOLE */
> +
> +static struct uart_driver mvebu_uart_driver = {
> +	.owner			= THIS_MODULE,
> +	.driver_name		= "mvebu_serial",
> +	.dev_name		= "ttyMV",
> +	.nr			= MVEBU_NR_UARTS,
> +#ifdef CONFIG_SERIAL_MVEBU_CONSOLE
> +	.cons			= &mvebu_uart_console,
> +#endif
> +};
> +
> +static int mvebu_uart_probe(struct platform_device *pdev)
> +{
> +	struct resource *reg = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	struct resource *irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> +	struct uart_port *port;
> +	struct mvebu_uart_data *data;
> +	int ret;
> +
> +	if (!reg || !irq) {
> +		dev_err(&pdev->dev, "no registers/irq defined\n");
> +		return -EINVAL;
> +	}
> +
> +	port = &mvebu_uart_ports[0];
> +
> +	spin_lock_init(&port->lock);
> +
> +	port->dev        = &pdev->dev;
> +	port->type       = PORT_MVEBU;
> +	port->ops        = &mvebu_uart_ops;
> +	port->regshift   = 0;
> +
> +	port->fifosize   = 32;
> +	port->iotype     = UPIO_MEM32;
> +	port->flags      = UPF_FIXED_PORT;
> +	port->line       = 0; /* single port: force line number to  0 */
> +
> +	port->irq        = irq->start;
> +	port->irqflags   = 0;
> +	port->mapbase    = reg->start;
> +
> +	port->membase = devm_ioremap_resource(&pdev->dev, reg);
> +	if (IS_ERR(port->membase))
> +		return -PTR_ERR(port->membase);
> +
> +	data = devm_kzalloc(&pdev->dev, sizeof(struct mvebu_uart_data),
> +			    GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	data->port = port;
> +
> +	port->private_data = data;
> +	platform_set_drvdata(pdev, data);
> +
> +	ret = uart_add_one_port(&mvebu_uart_driver, port);
> +	if (ret)
> +		return ret;
> +	return 0;
> +}
> +
> +static int mvebu_uart_remove(struct platform_device *pdev)
> +{
> +	struct mvebu_uart_data *data = platform_get_drvdata(pdev);
> +
> +	uart_remove_one_port(&mvebu_uart_driver, data->port);
> +	data->port->private_data = NULL;
> +	data->port->mapbase      = 0;
> +	return 0;
> +}
> +
> +/* Match table for of_platform binding */
> +static const struct of_device_id mvebu_uart_of_match[] = {
> +	{ .compatible = "marvell,armada-3700-uart", },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, mvebu_uart_of_match);
> +
> +static struct platform_driver mvebu_uart_platform_driver = {
> +	.probe	= mvebu_uart_probe,
> +	.remove	= mvebu_uart_remove,
> +	.driver	= {
> +		.owner	= THIS_MODULE,
> +		.name  = "mvebu-uart",
> +		.of_match_table = of_match_ptr(mvebu_uart_of_match),
> +	},
> +};
> +
> +static int __init mvebu_uart_init(void)
> +{
> +	int ret;
> +
> +	ret = uart_register_driver(&mvebu_uart_driver);
> +	if (ret)
> +		return ret;
> +
> +	ret = platform_driver_register(&mvebu_uart_platform_driver);
> +	if (ret)
> +		uart_unregister_driver(&mvebu_uart_driver);
> +
> +	return ret;
> +}
> +
> +static void __exit mvebu_uart_exit(void)
> +{
> +	platform_driver_unregister(&mvebu_uart_platform_driver);
> +	uart_unregister_driver(&mvebu_uart_driver);
> +}
> +
> +arch_initcall(mvebu_uart_init);
> +module_exit(mvebu_uart_exit);
> +
> +MODULE_AUTHOR("Wilson Ding <dingwei at marvell.com>");
> +MODULE_DESCRIPTION("Marvell Armada-3700 Serial Driver");
> +MODULE_LICENSE("GPL");
> diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
> index 3e5d757407fb..e513a4ee369b 100644
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -261,4 +261,7 @@
>  /* STM32 USART */
>  #define PORT_STM32	113
>  
> +/* MVEBU UART */
> +#define PORT_MVEBU	114
> +
>  #endif /* _UAPILINUX_SERIAL_CORE_H */
> -- 
> 2.5.0
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From gregory.clement at free-electrons.com  Thu Feb 18 09:39:26 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 18 Feb 2016 18:39:26 +0100
Subject: [PATCH v4 04/12] ata: ahci_mvebu: add support for Armada 3700
 variant
In-Reply-To: <1455646502-23834-5-git-send-email-gregory.clement@free-electrons.com>
 (Gregory CLEMENT's message of "Tue, 16 Feb 2016 19:14:54 +0100")
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
 <1455646502-23834-5-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <87y4ahq5o1.fsf@free-electrons.com>

Hi Tejun and Hans,
 
 On mar., f?vr. 16 2016, Gregory CLEMENT <gregory.clement at free-electrons.com> wrote:

> From: Lior Amsalem <alior at marvell.com>
>
> The main difference in the new Armada 3700 is that no address
> decoding needs to take place in the driver probe.
>
> [gregory.clement at free-electrons.com: reformulate the commit log]
>
> Signed-off-by: Lior Amsalem <alior at marvell.com>
> Reviewed-by: Nadav Haklai <nadavh at marvell.com>
> Tested-by: Nadav Haklai <nadavh at marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>

I took care of the arm related part of the series, but I will let you
apply this patch in the sata subsystem once you have reviewed it. But
if for any reason you preferred that I took it through mvebu just tell
me.

Thanks,

Gregory


> ---
>  drivers/ata/ahci_mvebu.c | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/ata/ahci_mvebu.c b/drivers/ata/ahci_mvebu.c
> index f7a7fa81740e..de7128d81e9c 100644
> --- a/drivers/ata/ahci_mvebu.c
> +++ b/drivers/ata/ahci_mvebu.c
> @@ -112,12 +112,15 @@ static int ahci_mvebu_probe(struct platform_device *pdev)
>  	if (rc)
>  		return rc;
>  
> -	dram = mv_mbus_dram_info();
> -	if (!dram)
> -		return -ENODEV;
> +	if (of_device_is_compatible(pdev->dev.of_node,
> +				    "marvell,armada-380-ahci")) {
> +		dram = mv_mbus_dram_info();
> +		if (!dram)
> +			return -ENODEV;
>  
> -	ahci_mvebu_mbus_config(hpriv, dram);
> -	ahci_mvebu_regret_option(hpriv);
> +		ahci_mvebu_mbus_config(hpriv, dram);
> +		ahci_mvebu_regret_option(hpriv);
> +	}
>  
>  	rc = ahci_platform_init_host(pdev, hpriv, &ahci_mvebu_port_info,
>  				     &ahci_platform_sht);
> @@ -133,6 +136,7 @@ disable_resources:
>  
>  static const struct of_device_id ahci_mvebu_of_match[] = {
>  	{ .compatible = "marvell,armada-380-ahci", },
> +	{ .compatible = "marvell,armada-3700-ahci", },
>  	{ },
>  };
>  MODULE_DEVICE_TABLE(of, ahci_mvebu_of_match);
> -- 
> 2.5.0
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From tj at kernel.org  Thu Feb 18 09:41:56 2016
From: tj at kernel.org (Tejun Heo)
Date: Thu, 18 Feb 2016 12:41:56 -0500
Subject: [PATCH v4 04/12] ata: ahci_mvebu: add support for Armada 3700
 variant
In-Reply-To: <1455646502-23834-5-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
 <1455646502-23834-5-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160218174156.GF13177@mtj.duckdns.org>

On Tue, Feb 16, 2016 at 07:14:54PM +0100, Gregory CLEMENT wrote:
> From: Lior Amsalem <alior at marvell.com>
> 
> The main difference in the new Armada 3700 is that no address
> decoding needs to take place in the driver probe.
> 
> [gregory.clement at free-electrons.com: reformulate the commit log]
> 
> Signed-off-by: Lior Amsalem <alior at marvell.com>
> Reviewed-by: Nadav Haklai <nadavh at marvell.com>
> Tested-by: Nadav Haklai <nadavh at marvell.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>

Applied to libata/for-4.6.

Thanks.

-- 
tejun


From rafael at kernel.org  Thu Feb 18 09:46:40 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Thu, 18 Feb 2016 18:46:40 +0100
Subject: [BUG FIX] PM / cpu_domains: Check for NULL callbacks
In-Reply-To: <1455816573-43849-1-git-send-email-lina.iyer@linaro.org>
References: <1455310238-8963-4-git-send-email-lina.iyer@linaro.org>
 <1455816573-43849-1-git-send-email-lina.iyer@linaro.org>
Message-ID: <CAJZ5v0gXd573OM_xQBsqqaZoRWvT_px64Cx2avR5dCxCwmMWjA@mail.gmail.com>

On Thu, Feb 18, 2016 at 6:29 PM, Lina Iyer <lina.iyer at linaro.org> wrote:
> Check for NULL platform callback before calling.
>
> Signed-off-by: Lina Iyer <lina.iyer at linaro.org>
> ---
>  drivers/base/power/cpu_domains.c | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/power/cpu_domains.c b/drivers/base/power/cpu_domains.c
> index 7069411..bcaa474 100644
> --- a/drivers/base/power/cpu_domains.c
> +++ b/drivers/base/power/cpu_domains.c
> @@ -157,16 +157,22 @@ static int cpu_pd_power_on(struct generic_pm_domain *genpd)
>  {
>         struct cpu_pm_domain *pd = to_cpu_pd(genpd);
>
> -       return pd->ops.power_on();
> +       if (pd->ops.power_on)
> +               return pd->ops.power_on();
> +
> +       return 0;
>  }

I usually write things like that as

return pd->ops.power_on ? pd->ops.power_on() : 0;

That gets the job done in just one line of code instead of 4 and in
one statement instead of 3.

Thanks,
Rafael


From nicolas.pitre at linaro.org  Thu Feb 18 09:48:28 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Feb 2016 12:48:28 -0500 (EST)
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
Message-ID: <alpine.LFD.2.20.1602181244490.13632@knanqh.ubzr>

On Thu, 18 Feb 2016, Chris Brandt wrote:

> As Multiplatform seems to be the way of the future, you should not restrict
> from selecting XIP. Whether it makes sense or not depends on how you
> configure the rest of the kernel (as in, removing individual platforms).
> Also, it stands to reason that if you select MULTIPLATFORM and XIP_KERNEL,
> you either know what you are doing...or have NO idea what you are doing.

There are simply too many people who don't know what they're doing.

And realistically it makes no sense to use XIP (surely because you 
need to save space) and have multi-platform support in your kernel.

IMHO it should be clear that with XIP there is only one platform that 
can be supported.




> 
> Signed-off-by: Chris Brandt <chris.brandt at renesas.com>
> ---
>  arch/arm/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index cc95ff8..2e4a127 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -327,7 +327,7 @@ config ARCH_MULTIPLATFORM
>  	depends on MMU
>  	select ARCH_WANT_OPTIONAL_GPIOLIB
>  	select ARM_HAS_SG_CHAIN
> -	select ARM_PATCH_PHYS_VIRT
> +	select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL
>  	select AUTO_ZRELADDR
>  	select CLKSRC_OF
>  	select COMMON_CLK
> @@ -1919,7 +1919,7 @@ endchoice
>  
>  config XIP_KERNEL
>  	bool "Kernel Execute-In-Place from ROM"
> -	depends on !ARM_LPAE && !ARCH_MULTIPLATFORM
> +	depends on !ARM_LPAE
>  	help
>  	  Execute-In-Place allows the kernel to run from non-volatile storage
>  	  directly addressable by the CPU, such as NOR flash. This saves RAM
> -- 
> 1.9.1
> 
> 
> 


From will.deacon at arm.com  Thu Feb 18 09:49:18 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 18 Feb 2016 17:49:18 +0000
Subject: [GIT PULL] iommu/io-pgtable: Updates for 4.6
Message-ID: <20160218174918.GF16883@arm.com>

Hi Joerg,

Here are the io-pgtable updates from Robin for 4.6.

The bulk of this is adding support for the ARM v7s page table format,
which will be used by the Mediatek IOMMU driver from Yong Wu. Subsequent
work may also enable this format for the ARM SMMU.

Cheers,

Will

--->8

The following changes since commit 18558cae0272f8fd9647e69d3fec1565a7949865:

  Linux 4.5-rc4 (2016-02-14 13:05:20 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-joerg/io-pgtable

for you to fetch changes up to c8bff3a68f33b94e53f65aa9a4c0e9be34b6b514:

  MAINTAINERS: update ARM SMMU entry (2016-02-17 14:43:40 +0000)

----------------------------------------------------------------
Robin Murphy (4):
      iommu/io-pgtable: Add ARMv7 short descriptor support
      iommu/io-pgtable: Add helper functions for TLB ops
      iommu/io-pgtable: Avoid redundant TLB syncs
      iommu/io-pgtable: Rationalise quirk handling

Will Deacon (1):
      MAINTAINERS: update ARM SMMU entry

 MAINTAINERS                        |   2 +
 drivers/iommu/Kconfig              |  19 +
 drivers/iommu/Makefile             |   1 +
 drivers/iommu/io-pgtable-arm-v7s.c | 846 +++++++++++++++++++++++++++++++++++++
 drivers/iommu/io-pgtable-arm.c     |  34 +-
 drivers/iommu/io-pgtable.c         |   5 +-
 drivers/iommu/io-pgtable.h         |  53 ++-
 7 files changed, 943 insertions(+), 17 deletions(-)
 create mode 100644 drivers/iommu/io-pgtable-arm-v7s.c


From catalin.marinas at arm.com  Thu Feb 18 09:54:47 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 18 Feb 2016 17:54:47 +0000
Subject: [PATCH] arm64: kasan: clear stale stack poison
In-Reply-To: <1455816458-19485-1-git-send-email-mark.rutland@arm.com>
References: <1455816458-19485-1-git-send-email-mark.rutland@arm.com>
Message-ID: <20160218175447.GD2538@e104818-lin.cambridge.arm.com>

On Thu, Feb 18, 2016 at 05:27:38PM +0000, Mark Rutland wrote:
> @@ -145,6 +146,7 @@ ENTRY(cpu_resume_mmu)
>  ENDPROC(cpu_resume_mmu)
>  	.popsection
>  cpu_resume_after_mmu:
> +	kasan_unpoison_stack 96

I don't think the 96 here is needed since we populate the stack in
assembly (__cpu_suspend_enter) and unwind it again still in assembly
(cpu_resume_after_mmu), so no KASAN shadow writes/reads.

Otherwise the patch looks fine.

-- 
Catalin


From punit.agrawal at arm.com  Thu Feb 18 09:58:09 2016
From: punit.agrawal at arm.com (Punit Agrawal)
Date: Thu, 18 Feb 2016 17:58:09 +0000
Subject: [PATCH v2 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420
In-Reply-To: <1455772383-20598-1-git-send-email-k.kozlowski@samsung.com>
 (Krzysztof Kozlowski's message of "Thu, 18 Feb 2016 14:13:01 +0900")
References: <1455772383-20598-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <87h9h599zi.fsf@e105922-lin.cambridge.arm.com>

Hi Krzysztof,

Krzysztof Kozlowski <k.kozlowski at samsung.com> writes:

> On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
> 12 steps for big core (700-1800 MHz). Add respective cooling cells.
>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
>
> ---
>
> Changes since v1:
> 1. Add cooling properties to all CPUs (suggested by Viresh).
> ---
>  arch/arm/boot/dts/exynos5420-cpus.dtsi | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
> index 261d25173f61..5c052d7ff554 100644
> --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
> @@ -33,6 +33,9 @@
>  			clock-frequency = <1800000000>;
>  			cci-control-port = <&cci_control1>;
>  			operating-points-v2 = <&cluster_a15_opp_table>;
> +			cooling-min-level = <0>;
> +			cooling-max-level = <11>;

Although the above two properties are defined they aren't parsed in the
kernel.

Setting min / max extents for cooling devices via cooling maps does work
though.


[...]



From catalin.marinas at arm.com  Thu Feb 18 10:03:13 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 18 Feb 2016 18:03:13 +0000
Subject: [PATCH v2 0/5] arm64: kernel: Add support for User Access Override
In-Reply-To: <1454684330-892-1-git-send-email-james.morse@arm.com>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
Message-ID: <20160218180313.GE2538@e104818-lin.cambridge.arm.com>

On Fri, Feb 05, 2016 at 02:58:45PM +0000, James Morse wrote:
> James Morse (5):
>   arm64: cpufeature: Change read_cpuid() to use sysreg's mrs_s macro
>   arm64: add ARMv8.2 id_aa64mmfr2 boiler plate
>   arm64: kernel: Add support for User Access Override
>   arm64: cpufeature: Test 'matches' pointer to find the end of the list
>   arm64: kernel: Don't toggle PAN on systems with UAO

Patches applied with an additional fixup on top for removing
get_thread_info().

Thanks.

-- 
Catalin


From will.deacon at arm.com  Thu Feb 18 10:03:54 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 18 Feb 2016 18:03:54 +0000
Subject: [PATCH] arm64: kasan: clear stale stack poison
In-Reply-To: <20160218175447.GD2538@e104818-lin.cambridge.arm.com>
References: <1455816458-19485-1-git-send-email-mark.rutland@arm.com>
 <20160218175447.GD2538@e104818-lin.cambridge.arm.com>
Message-ID: <20160218180353.GG16883@arm.com>

On Thu, Feb 18, 2016 at 05:54:47PM +0000, Catalin Marinas wrote:
> On Thu, Feb 18, 2016 at 05:27:38PM +0000, Mark Rutland wrote:
> > @@ -145,6 +146,7 @@ ENTRY(cpu_resume_mmu)
> >  ENDPROC(cpu_resume_mmu)
> >  	.popsection
> >  cpu_resume_after_mmu:
> > +	kasan_unpoison_stack 96
> 
> I don't think the 96 here is needed since we populate the stack in
> assembly (__cpu_suspend_enter) and unwind it again still in assembly
> (cpu_resume_after_mmu), so no KASAN shadow writes/reads.
> 
> Otherwise the patch looks fine.

I'd much rather it was written in C -- is there a reason we can't do
that if we use a separate compilation unit where the compiler will
honour the fno-sanitize flag?

Will


From tixy at linaro.org  Thu Feb 18 10:12:15 2016
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Thu, 18 Feb 2016 18:12:15 +0000
Subject: [PATCH 3/3] [RESEND] ARM: kprobes: use "I" constraint for
 inline assembly offsets
In-Reply-To: <1455815113-2562966-4-git-send-email-arnd@arndb.de>
References: <1455815113-2562966-1-git-send-email-arnd@arndb.de>
 <1455815113-2562966-4-git-send-email-arnd@arndb.de>
Message-ID: <1455819135.2958.6.camel@linaro.org>

On Thu, 2016-02-18 at 18:05 +0100, Arnd Bergmann wrote:
> build-testing with clang showed that the "J" constraint does not take
> positive arguments on clang when building in for Thumb-2:
> 
> core.c:540:3: error: invalid operand for inline asm constraint 'J'
> 
> This has been reported as llvm bug https://llvm.org/bugs/show_bug.cgi?id=26061
> 
> However, looking at the source code in depth, I found that the
> kernel is also wrong, and it should not use "J" at all, but should
> use "I" to pass an immediate argument to the inline assembly when that
> is used as an offset to an 'ldr' instruction rather than the 'sub'
> argument.

This patch doesn't seem correct to me.

The ARM ARM says the immediate offset to an ARM ldr instructions is "any
value in the range 0-4095" and offsets may be added or subtracted,
leading to values from ?4095 to 4095".

And GCC machine constraints [1] says

I
    Integer that is valid as an immediate operand in a data processing
    instruction. That is, an integer in the range 0 to 255 rotated by a
    multiple of 2
J
    Integer in the range ?4095 to 4095 

So the current use of 'J' seems correct to me.

[1] https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints


> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/probes/kprobes/core.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
> index a4ec240ee7ba..4b34b40ca917 100644
> --- a/arch/arm/probes/kprobes/core.c
> +++ b/arch/arm/probes/kprobes/core.c
> @@ -570,10 +570,10 @@ void __kprobes jprobe_return(void)
>  		:
>  		: "r" (kcb->jprobe_saved_regs.ARM_sp),
>  		  "I" (sizeof(struct pt_regs) * 2),
> -		  "J" (offsetof(struct pt_regs, ARM_sp)),
> -		  "J" (offsetof(struct pt_regs, ARM_pc)),
> -		  "J" (offsetof(struct pt_regs, ARM_cpsr)),
> -		  "J" (offsetof(struct pt_regs, ARM_lr))
> +		  "I" (offsetof(struct pt_regs, ARM_sp)),
> +		  "I" (offsetof(struct pt_regs, ARM_pc)),
> +		  "I" (offsetof(struct pt_regs, ARM_cpsr)),
> +		  "I" (offsetof(struct pt_regs, ARM_lr))
>  		: "memory", "cc");
>  }
>  




From catalin.marinas at arm.com  Thu Feb 18 10:13:57 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 18 Feb 2016 18:13:57 +0000
Subject: [PATCH] arm64: kasan: clear stale stack poison
In-Reply-To: <20160218180353.GG16883@arm.com>
References: <1455816458-19485-1-git-send-email-mark.rutland@arm.com>
 <20160218175447.GD2538@e104818-lin.cambridge.arm.com>
 <20160218180353.GG16883@arm.com>
Message-ID: <20160218181356.GF2538@e104818-lin.cambridge.arm.com>

On Thu, Feb 18, 2016 at 06:03:54PM +0000, Will Deacon wrote:
> On Thu, Feb 18, 2016 at 05:54:47PM +0000, Catalin Marinas wrote:
> > On Thu, Feb 18, 2016 at 05:27:38PM +0000, Mark Rutland wrote:
> > > @@ -145,6 +146,7 @@ ENTRY(cpu_resume_mmu)
> > >  ENDPROC(cpu_resume_mmu)
> > >  	.popsection
> > >  cpu_resume_after_mmu:
> > > +	kasan_unpoison_stack 96
> > 
> > I don't think the 96 here is needed since we populate the stack in
> > assembly (__cpu_suspend_enter) and unwind it again still in assembly
> > (cpu_resume_after_mmu), so no KASAN shadow writes/reads.
> > 
> > Otherwise the patch looks fine.
> 
> I'd much rather it was written in C -- is there a reason we can't do
> that if we use a separate compilation unit where the compiler will
> honour the fno-sanitize flag?

A simple, non-sanitised C wrapper around __cpu_suspend_enter() would
probably work. We need to make sure it is static inline when !KASAN to
avoid an unnecessary function call. Or we just move cpu_suspend() to a
different compilation unit, though that's a slightly larger function
which we may want to track under KASAN.

-- 
Catalin


From ray.jui at broadcom.com  Thu Feb 18 10:15:11 2016
From: ray.jui at broadcom.com (Ray Jui)
Date: Thu, 18 Feb 2016 10:15:11 -0800
Subject: [1/4] arm64: Broadcom Vulcan support
In-Reply-To: <1455389195-31870-2-git-send-email-jchandra@broadcom.com>
References: <1455389195-31870-2-git-send-email-jchandra@broadcom.com>
Message-ID: <0c75ddd6-d353-bb73-62e4-bae0ff95a3b0@broadcom.com>

+ bcm-kernel-feedback-list mailing list

On 2/13/2016 10:46 AM, Jayachandran C. wrote:
> From: Zi Shen Lim <zlim at broadcom.com>
>
> Add a configuration option and a device tree for Broadcom's Vulcan
> ARM64 processor. brcm-vulcan.dtsi has the on-chip blocks like the
> PCIe controller, GICv3 with ITS, PMU, system timer and pl011 UART.
> brcm-vulcan-eval.dts has definitions for a basic evaluation board.
> The firmware supports PSCI 0.2 for cpu wakeup.
>
> Signed-off-by: Zi Shen Lim <zlim at broadcom.com>
> [ updated and split dts - jchandra at broadcom.com ]
> Signed-off-by: Jayachandran C <jchandra at broadcom.com>
>
> ---
> arch/arm64/Kconfig.platforms                      |   5 +
>  arch/arm64/boot/dts/broadcom/Makefile             |   1 +
>  arch/arm64/boot/dts/broadcom/brcm-vulcan-eval.dts |  33 +++++
>  arch/arm64/boot/dts/broadcom/brcm-vulcan.dtsi     | 146 ++++++++++++++++++++++
>  4 files changed, 185 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/broadcom/brcm-vulcan-eval.dts
>  create mode 100644 arch/arm64/boot/dts/broadcom/brcm-vulcan.dtsi

Could you please name the files "vulcan.dtsi" and "vulcan-eval.dts" so 
it's consistent with the rest of files in the same directory?

Thanks,

Ray


From Chris.Brandt at renesas.com  Thu Feb 18 10:18:02 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Thu, 18 Feb 2016 18:18:02 +0000
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <alpine.LFD.2.20.1602181244490.13632@knanqh.ubzr>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
 <alpine.LFD.2.20.1602181244490.13632@knanqh.ubzr>
Message-ID: <HK2PR06MB0561377EABB3B4B8E94F22328AAF0@HK2PR06MB0561.apcprd06.prod.outlook.com>

> And realistically it makes no sense to use XIP (surely because you need
> to save space) and have multi-platform support in your kernel.


The problem is that you don't have a choice: Multi-platform is your only choice for many devices (MMU devices that is).

So for XIP, it comes down to either:

A) Go back to making individual configs for each MPU

B) Let everything keep getting grouped together into multi-platform, and then just de-selecting the MPU you don't want.

I can tell you when I build my upstream XIP kernel for testing for the RZ/A1, it's ARCH_MULTIPLATFORM (all Renesas parts are multiplatform) and then remove everything I don't want/need, my kernel size is 3.4MB.


> IMHO it should be clear that with XIP there is only one platform that can
> be supported.

I would be fine if there was some way you could only select XIP_KERNEL if only 1 of the MPUs in the multiplatform group were selected...but I can't figure out how to do that in the kbuild system (without adding lots of chunky configs all over the place...which is not what I want)

Is there some way you can do a PLATFORM_COUNTER++ for each device that is selected, and then XIP_KERNEL would depend on PLATFORM_COUNTER == 1 ?


Chris



From javier at osg.samsung.com  Thu Feb 18 10:19:09 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Thu, 18 Feb 2016 15:19:09 -0300
Subject: [PATCH 1/3] thermal: exynos: List vtmu-supply as optional property in
 DT binding
In-Reply-To: <1455819551-4666-1-git-send-email-javier@osg.samsung.com>
References: <1455819551-4666-1-git-send-email-javier@osg.samsung.com>
Message-ID: <1455819551-4666-2-git-send-email-javier@osg.samsung.com>

The Exynos Thermal Management Unit binding says that the vtmu-supply
is optional but is listed in the required properties section. Add an
optional properties section and move the regulator property there.

Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
---

 Documentation/devicetree/bindings/thermal/exynos-thermal.txt | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index faa62059b5c5..70b4c16c7ed8 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -41,9 +41,6 @@
 		for current TMU channel
 	-- "tmu_sclk" clock for functional operation of the current TMU
 		channel
-- vtmu-supply: This entry is optional and provides the regulator node supplying
-		voltage to TMU. If needed this entry can be placed inside
-		board/platform specific dts file.
 
 The Exynos TMU supports generating interrupts when reaching given
 temperature thresholds. Number of supported thermal trip points depends
@@ -65,6 +62,12 @@ Following properties are mandatory (depending on SoC):
 - samsung,tmu_default_temp_offset: Default temperature offset
 - samsung,tmu_cal_type: Callibration type
 
+** Optional properties:
+
+- vtmu-supply: This entry is optional and provides the regulator node supplying
+		voltage to TMU. If needed this entry can be placed inside
+		board/platform specific dts file.
+
 Example 1):
 
 	tmu at 100C0000 {
-- 
2.5.0



From javier at osg.samsung.com  Thu Feb 18 10:19:08 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Thu, 18 Feb 2016 15:19:08 -0300
Subject: [PATCH 0/3] thermal: exynos: Fixes for vtmu-supply regulator handling
Message-ID: <1455819551-4666-1-git-send-email-javier@osg.samsung.com>

Hello,

On a recent patch series to build a PMIC chip as a module [0], Krzysztof
asked me to check if all the consumer drivers, using the resources that
this PMIC provides, already support probe deferral.

While investigating that, I noticed that the Exynos TMU didn't do it so
this series fix that bug and other two minor issues that I noticed while
reviewing the driver and its DT binding.

The series are on top of Krzysztof's patches [1,2,3] not because there's
a dependency but to avoid merge conflicts with in-flight patches. Please
let me know if you prefer to use a different base instead.

[0]: https://lkml.org/lkml/2016/2/11/857
[1]: https://patchwork.kernel.org/patch/8345791/
[2]: https://patchwork.kernel.org/patch/8345741/
[3]: https://patchwork.kernel.org/patch/8345701/

Best regards,
Javier


Javier Martinez Canillas (3):
  thermal: exynos: List vtmu-supply as optional property in DT binding
  thermal: exynos: Use devm_regulator_get_optional() for vtmu
  thermal: exynos: Defer probe if vtmu is present but not registered

 Documentation/devicetree/bindings/thermal/exynos-thermal.txt | 9 ++++++---
 drivers/thermal/samsung/exynos_tmu.c                         | 4 +++-
 2 files changed, 9 insertions(+), 4 deletions(-)

-- 
2.5.0



From javier at osg.samsung.com  Thu Feb 18 10:19:10 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Thu, 18 Feb 2016 15:19:10 -0300
Subject: [PATCH 2/3] thermal: exynos: Use devm_regulator_get_optional() for
 vtmu
In-Reply-To: <1455819551-4666-1-git-send-email-javier@osg.samsung.com>
References: <1455819551-4666-1-git-send-email-javier@osg.samsung.com>
Message-ID: <1455819551-4666-3-git-send-email-javier@osg.samsung.com>

The Exynos TMU DT binding says that the vtmu-supply is optional but the
driver uses devm_regulator_get() that creates a dummy regulator if it's
not defined in the DT. For example the following message is in the log:

10060000.tmu supply vtmu not found, using dummy regulator

Use the optional version of regulator_get() that doesn't create a dummy
regulator and instead returns a -ENODEV errno code. Since it's expected
that a regulator may not be defined and the driver will inform about it:

exynos-tmu 10060000.tmu: Regulator node (vtmu) not found

Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
---

 drivers/thermal/samsung/exynos_tmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index 6c6f59ba7423..f4f36bba7be9 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1310,7 +1310,7 @@ static int exynos_tmu_probe(struct platform_device *pdev)
 	 * TODO: Add regulator as an SOC feature, so that regulator enable
 	 * is a compulsory call.
 	 */
-	data->regulator = devm_regulator_get(&pdev->dev, "vtmu");
+	data->regulator = devm_regulator_get_optional(&pdev->dev, "vtmu");
 	if (!IS_ERR(data->regulator)) {
 		ret = regulator_enable(data->regulator);
 		if (ret) {
-- 
2.5.0



From javier at osg.samsung.com  Thu Feb 18 10:19:11 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Thu, 18 Feb 2016 15:19:11 -0300
Subject: [PATCH 3/3] thermal: exynos: Defer probe if vtmu is present but not
 registered
In-Reply-To: <1455819551-4666-1-git-send-email-javier@osg.samsung.com>
References: <1455819551-4666-1-git-send-email-javier@osg.samsung.com>
Message-ID: <1455819551-4666-4-git-send-email-javier@osg.samsung.com>

The driver doesn't check if the regulator_get_optional return value is
-EPROBE_DEFER so it will wrongly assume that the regulator couldn't be
found just because the regulator driver wasn't registered yet, i.e:

exynos-tmu 10060000.tmu: Regulator node (vtmu) not found

In this case the return value should be propagated to allow the driver
probe function to be deferred until the regulator driver is registered.

Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>

---

 drivers/thermal/samsung/exynos_tmu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
index f4f36bba7be9..f3ce94ec73b5 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1318,6 +1318,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
 			return ret;
 		}
 	} else {
+		if (PTR_ERR(data->regulator) == -EPROBE_DEFER)
+			return -EPROBE_DEFER;
 		dev_info(&pdev->dev, "Regulator node (vtmu) not found\n");
 	}
 
-- 
2.5.0



From tchalamarla at caviumnetworks.com  Thu Feb 18 10:23:37 2016
From: tchalamarla at caviumnetworks.com (tchalamarla at caviumnetworks.com)
Date: Thu, 18 Feb 2016 10:23:37 -0800
Subject: [PATCH] iommu/arm-smmu-v2: Add support for 16 bit VMID
Message-ID: <1455819817-8432-1-git-send-email-tchalamarla@caviumnetworks.com>

From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>

ARM-SMMUv2 supports upto 16 bit VMID. This patch enables
16 bit VMID when requested from device-tree.

Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
---
 .../devicetree/bindings/iommu/arm,smmu.txt          |  2 ++
 drivers/iommu/arm-smmu.c                            | 21 ++++++++++++++++++++-
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index 7180745..bb7e569 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -55,6 +55,8 @@ conditions.
                   aliases of secure registers have to be used during
                   SMMU configuration.
 
+- smmu-enable-vmid16 : Enable 16 bit VMID, if allowed.
+
 Example:
 
         smmu {
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 59ee4b8..003c442 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -93,6 +93,7 @@
 #define sCR0_VMIDPNE			(1 << 11)
 #define sCR0_PTM			(1 << 12)
 #define sCR0_FB				(1 << 13)
+#define sCR0_VMID16EN			(1 << 31)
 #define sCR0_BSU_SHIFT			14
 #define sCR0_BSU_MASK			0x3
 
@@ -140,6 +141,7 @@
 #define ID2_PTFS_4K			(1 << 12)
 #define ID2_PTFS_16K			(1 << 13)
 #define ID2_PTFS_64K			(1 << 14)
+#define ID2_VMID16			(1 << 15)
 
 /* Global TLB invalidation */
 #define ARM_SMMU_GR0_TLBIVMID		0x64
@@ -189,6 +191,8 @@
 #define ARM_SMMU_GR1_CBA2R(n)		(0x800 + ((n) << 2))
 #define CBA2R_RW64_32BIT		(0 << 0)
 #define CBA2R_RW64_64BIT		(1 << 0)
+#define CBA2R_VMID_SHIFT		16
+#define CBA2R_VMID_MASK			0xffff
 
 /* Translation context bank */
 #define ARM_SMMU_CB_BASE(smmu)		((smmu)->base + ((smmu)->size >> 1))
@@ -300,6 +304,7 @@ struct arm_smmu_device {
 	u32				features;
 
 #define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
+#define ARM_SMMU_OPT_ENABLE_VMID16	(1 << 1)
 	u32				options;
 	enum arm_smmu_arch_version	version;
 
@@ -361,6 +366,7 @@ struct arm_smmu_option_prop {
 
 static struct arm_smmu_option_prop arm_smmu_options[] = {
 	{ ARM_SMMU_OPT_SECURE_CFG_ACCESS, "calxeda,smmu-secure-config-access" },
+	{ ARM_SMMU_OPT_ENABLE_VMID16, "smmu-enable-vmid16" },
 	{ 0, NULL},
 };
 
@@ -736,6 +742,10 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 #else
 		reg = CBA2R_RW64_32BIT;
 #endif
+		/* if 16bit VMID required set VMID in CBA2R */
+		if (smmu->options & ARM_SMMU_OPT_ENABLE_VMID16)
+			reg |= ARM_SMMU_CB_VMID(cfg) << CBA2R_VMID_SHIFT;
+
 		writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBA2R(cfg->cbndx));
 	}
 
@@ -751,7 +761,8 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 	if (stage1) {
 		reg |= (CBAR_S1_BPSHCFG_NSH << CBAR_S1_BPSHCFG_SHIFT) |
 			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
-	} else {
+	} else if (!(smmu->options & ARM_SMMU_OPT_ENABLE_VMID16)) {
+		/*16 bit VMID is not enabled set 8 bit VMID here */
 		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
 	}
 	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
@@ -1508,6 +1519,14 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
 	/* Don't upgrade barriers */
 	reg &= ~(sCR0_BSU_MASK << sCR0_BSU_SHIFT);
 
+	/* See if 16bit VMID is required */
+	if (smmu->options & ARM_SMMU_OPT_ENABLE_VMID16) {
+		u32 id = readl_relaxed(gr0_base + ARM_SMMU_GR0_ID2);
+		/* Check to see if HW accepts */
+		if (id & ID2_VMID16)
+			reg |= (sCR0_VMID16EN);
+	}
+
 	/* Push the button */
 	__arm_smmu_tlb_sync(smmu);
 	writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
-- 
2.1.0



From lorenzo.pieralisi at arm.com  Thu Feb 18 10:26:02 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 18 Feb 2016 18:26:02 +0000
Subject: [PATCH v5 07/15] arm64: Change cpu_resume() to enable mmu early
 then access sleep_sp by va
In-Reply-To: <1455637767-31561-8-git-send-email-james.morse@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
 <1455637767-31561-8-git-send-email-james.morse@arm.com>
Message-ID: <20160218182602.GA17589@red-moon>

On Tue, Feb 16, 2016 at 03:49:19PM +0000, James Morse wrote:
> By enabling the MMU early in cpu_resume(), the sleep_save_sp and stack can
> be accessed by VA, which avoids the need to convert-addresses and clean to
> PoC on the suspend path.
> 
> MMU setup is shared with the boot path, meaning the swapper_pg_dir is
> restored directly: ttbr1_el1 is no longer saved/restored.
> 
> struct sleep_save_sp is removed, replacing it with a single array of
> pointers.
> 
> cpu_do_{suspend,resume} could be further reduced to not restore: cpacr_el1,
> mdscr_el1, tcr_el1, vbar_el1 and sctlr_el1, all of which are set by
> __cpu_setup(). However these values all contain res0 bits that may be used
> to enable future features.
> 
> Signed-off-by: James Morse <james.morse at arm.com>
> ---

[...]

> diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
> index dca81612fe90..0e2b36f1fb44 100644
> --- a/arch/arm64/kernel/sleep.S
> +++ b/arch/arm64/kernel/sleep.S
> @@ -73,8 +73,8 @@ ENTRY(__cpu_suspend_enter)
>  	str	x2, [x0, #SLEEP_STACK_DATA_SYSTEM_REGS + CPU_CTX_SP]
>  
>  	/* find the mpidr_hash */
> -	ldr	x1, =sleep_save_sp
> -	ldr	x1, [x1, #SLEEP_SAVE_SP_VIRT]
> +	ldr	x1, =sleep_save_stash
> +	ldr	x1, [x1]
>  	mrs	x7, mpidr_el1
>  	ldr	x9, =mpidr_hash
>  	ldr	x10, [x9, #MPIDR_HASH_MASK]
> @@ -87,40 +87,26 @@ ENTRY(__cpu_suspend_enter)
>  	compute_mpidr_hash x8, x3, x4, x5, x6, x7, x10
>  	add	x1, x1, x8, lsl #3
>  
> +	str	x0, [x1]
> +	add	x0, x0, #SLEEP_STACK_DATA_SYSTEM_REGS

Mmm...this instruction does not really belong in this patch,
it should be part of patch 6, correct ? What I mean is, the new
struct to stash system regs (struct sleep_stack_data) was added in
patch 6, if the offset #SLEEP_STACK_DATA_SYSTEM_REGS (which is 0) had
to be added it had to be added in patch 6 too, it does not belong
in this patch, am I right ?

>  	push	x29, lr
> -	bl	__cpu_suspend_save
> +	bl	cpu_do_suspend
>  	pop	x29, lr
>  	mov	x0, #1
>  	ret
>  ENDPROC(__cpu_suspend_enter)
>  	.ltorg
>  
> -/*
> - * x0 must contain the sctlr value retrieved from restored context
> - */
> -	.pushsection	".idmap.text", "ax"
> -ENTRY(cpu_resume_mmu)
> -	ldr	x3, =cpu_resume_after_mmu
> -	msr	sctlr_el1, x0		// restore sctlr_el1
> -	isb
> -	/*
> -	 * Invalidate the local I-cache so that any instructions fetched
> -	 * speculatively from the PoC are discarded, since they may have
> -	 * been dynamically patched at the PoU.
> -	 */
> -	ic	iallu
> -	dsb	nsh
> -	isb
> -	br	x3			// global jump to virtual address
> -ENDPROC(cpu_resume_mmu)
> -	.popsection
> -cpu_resume_after_mmu:
> -	mov	x0, #0			// return zero on success
> -	ret
> -ENDPROC(cpu_resume_after_mmu)
> -
>  ENTRY(cpu_resume)
>  	bl	el2_setup		// if in EL2 drop to EL1 cleanly
> +	/* enable the MMU early - so we can access sleep_save_stash by va */
> +	adr_l	lr, __enable_mmu	/* __cpu_setup will return here */
> +	ldr	x27, =_cpu_resume	/* __enable_mmu will branch here */
> +	adrp	x25, idmap_pg_dir
> +	adrp	x26, swapper_pg_dir
> +	b	__cpu_setup
> +
> +ENTRY(_cpu_resume)
>  	mrs	x1, mpidr_el1
>  	adrp	x8, mpidr_hash
>  	add x8, x8, #:lo12:mpidr_hash // x8 = struct mpidr_hash phys address
> @@ -130,29 +116,27 @@ ENTRY(cpu_resume)
>  	ldp	w5, w6, [x8, #(MPIDR_HASH_SHIFTS + 8)]
>  	compute_mpidr_hash x7, x3, x4, x5, x6, x1, x2
>          /* x7 contains hash index, let's use it to grab context pointer */
> -	ldr_l	x0, sleep_save_sp + SLEEP_SAVE_SP_PHYS
> +	ldr_l	x0, sleep_save_stash
>  	ldr	x0, [x0, x7, lsl #3]
>  	add	x29, x0, #SLEEP_STACK_DATA_CALLEE_REGS
>  	add	x0, x0, #SLEEP_STACK_DATA_SYSTEM_REGS
>  	/* load sp from context */
>  	ldr	x2, [x0, #CPU_CTX_SP]
> -	/* load physical address of identity map page table in x1 */
> -	adrp	x1, idmap_pg_dir
>  	mov	sp, x2
>  	/* save thread_info */
>  	and	x2, x2, #~(THREAD_SIZE - 1)
>  	msr	sp_el0, x2
>  	/*
> -	 * cpu_do_resume expects x0 to contain context physical address
> -	 * pointer and x1 to contain physical address of 1:1 page tables
> +	 * cpu_do_resume expects x0 to contain context address pointer
>  	 */
> -	bl	cpu_do_resume		// PC relative jump, MMU off
> -	/* Can't access these by physical address once the MMU is on */
> +	bl	cpu_do_resume
> +
>  	ldp	x19, x20, [x29, #16]
>  	ldp	x21, x22, [x29, #32]
>  	ldp	x23, x24, [x29, #48]
>  	ldp	x25, x26, [x29, #64]
>  	ldp	x27, x28, [x29, #80]
>  	ldp	x29, lr, [x29]
> -	b	cpu_resume_mmu		// Resume MMU, never returns
> +	mov	x0, #0
> +	ret
>  ENDPROC(cpu_resume)
> diff --git a/arch/arm64/kernel/suspend.c b/arch/arm64/kernel/suspend.c
> index 6fe46100685a..2ec2f94d1690 100644
> --- a/arch/arm64/kernel/suspend.c
> +++ b/arch/arm64/kernel/suspend.c
> @@ -10,30 +10,12 @@
>  #include <asm/suspend.h>
>  #include <asm/tlbflush.h>
>  
> -
>  /*
> - * This is called by __cpu_suspend_enter() to save the state, and do whatever
> - * flushing is required to ensure that when the CPU goes to sleep we have
> - * the necessary data available when the caches are not searched.
> - *
> - * ptr: sleep_stack_data containing cpu state virtual address.
> - * save_ptr: address of the location where the context physical address
> - *           must be saved
> + * This is allocate by cpu_suspend_init(), and used in cpuidle to store a

Nit: s/allocate/allocated

"and used to store", it is not just used in cpuidle, also S2R and now
we have hibernate too.

[...]

> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index db832c42ae30..a2ef1256a329 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -24,6 +24,7 @@
>  #include <asm/asm-offsets.h>
>  #include <asm/hwcap.h>
>  #include <asm/pgtable.h>
> +#include <asm/pgtable-hwdef.h>
>  
>  #ifdef CONFIG_ARM64_64K_PAGES
>  #define TCR_TG_FLAGS	TCR_TG0_64K | TCR_TG1_64K
> @@ -61,62 +62,50 @@ ENTRY(cpu_do_suspend)
>  	mrs	x2, tpidr_el0
>  	mrs	x3, tpidrro_el0
>  	mrs	x4, contextidr_el1
> -	mrs	x5, mair_el1
>  	mrs	x6, cpacr_el1
> -	mrs	x7, ttbr1_el1
>  	mrs	x8, tcr_el1
>  	mrs	x9, vbar_el1
>  	mrs	x10, mdscr_el1
>  	mrs	x11, oslsr_el1
>  	mrs	x12, sctlr_el1
>  	stp	x2, x3, [x0]
> -	stp	x4, x5, [x0, #16]
> -	stp	x6, x7, [x0, #32]
> -	stp	x8, x9, [x0, #48]
> -	stp	x10, x11, [x0, #64]
> -	str	x12, [x0, #80]
> +	stp	x4, xzr, [x0, #16]
> +	stp	x6, x8, [x0, #32]
> +	stp	x9, x10, [x0, #48]
> +	stp	x11, x12, [x0, #64]

Nit: You may want to re-enumerate the registers.

With the last updates it seems fine by me, so:

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

>  	ret
>  ENDPROC(cpu_do_suspend)
>  
>  /**
>   * cpu_do_resume - restore CPU register context
>   *
> - * x0: Physical address of context pointer
> - * x1: ttbr0_el1 to be restored
> - *
> - * Returns:
> - *	sctlr_el1 value in x0
> + * x0: Address of context pointer
>   */
>  ENTRY(cpu_do_resume)
> -	/*
> -	 * Invalidate local tlb entries before turning on MMU
> -	 */
> -	tlbi	vmalle1
>  	ldp	x2, x3, [x0]
>  	ldp	x4, x5, [x0, #16]
> -	ldp	x6, x7, [x0, #32]
> -	ldp	x8, x9, [x0, #48]
> -	ldp	x10, x11, [x0, #64]
> -	ldr	x12, [x0, #80]
> +	ldp	x6, x8, [x0, #32]
> +	ldp	x9, x10, [x0, #48]
> +	ldp	x11, x12, [x0, #64]
>  	msr	tpidr_el0, x2
>  	msr	tpidrro_el0, x3
>  	msr	contextidr_el1, x4
> -	msr	mair_el1, x5
>  	msr	cpacr_el1, x6
> -	msr	ttbr0_el1, x1
> -	msr	ttbr1_el1, x7
> -	tcr_set_idmap_t0sz x8, x7
> +
> +	/* Don't change t0sz here, mask those bits when restoring */
> +	mrs	x5, tcr_el1
> +	bfi	x8, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH
> +
>  	msr	tcr_el1, x8
>  	msr	vbar_el1, x9
>  	msr	mdscr_el1, x10
> +	msr	sctlr_el1, x12
>  	/*
>  	 * Restore oslsr_el1 by writing oslar_el1
>  	 */
>  	ubfx	x11, x11, #1, #1
>  	msr	oslar_el1, x11
>  	reset_pmuserenr_el0 x0			// Disable PMU access from EL0
> -	mov	x0, x12
> -	dsb	nsh		// Make sure local tlb invalidation completed
>  	isb
>  	ret
>  ENDPROC(cpu_do_resume)
> -- 
> 2.6.2
> 


From nicolas.pitre at linaro.org  Thu Feb 18 10:24:58 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Feb 2016 13:24:58 -0500 (EST)
Subject: [PATCH 3/3] [RESEND] ARM: kprobes: use "I" constraint for inline
 assembly offsets
In-Reply-To: <1455815113-2562966-4-git-send-email-arnd@arndb.de>
References: <1455815113-2562966-1-git-send-email-arnd@arndb.de>
 <1455815113-2562966-4-git-send-email-arnd@arndb.de>
Message-ID: <alpine.LFD.2.20.1602181248430.13632@knanqh.ubzr>

On Thu, 18 Feb 2016, Arnd Bergmann wrote:

> build-testing with clang showed that the "J" constraint does not take
> positive arguments on clang when building in for Thumb-2:
> 
> core.c:540:3: error: invalid operand for inline asm constraint 'J'
> 
> This has been reported as llvm bug https://llvm.org/bugs/show_bug.cgi?id=26061
> 
> However, looking at the source code in depth, I found that the
> kernel is also wrong, and it should not use "J" at all, but should
> use "I" to pass an immediate argument to the inline assembly when that
> is used as an offset to an 'ldr' instruction rather than the 'sub'
> argument.

I don't follow you.

>From the gcc manual:

     'I'
          Integer that is valid as an immediate operand in a data
          processing instruction.  That is, an integer in the range 0 to
          255 rotated by a multiple of 2

     'J'
          Integer in the range -4095 to 4095

>From the ARM ARM:

   LDR<c> <Rt>, [<Rn>{, #+/-<imm12>}]



where imm12 is a constant between 0 and 4095.

So J is really the appropriate constraint here.

Sure, in this case it is very likely that I would just works given that 
offset_of() is unlikely to exceed shifted 8 bits and that's what people 
use in most cases. But strictly speaking it's J that perfectly matches 
the LDR/STR instructions.








> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/probes/kprobes/core.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
> index a4ec240ee7ba..4b34b40ca917 100644
> --- a/arch/arm/probes/kprobes/core.c
> +++ b/arch/arm/probes/kprobes/core.c
> @@ -570,10 +570,10 @@ void __kprobes jprobe_return(void)
>  		:
>  		: "r" (kcb->jprobe_saved_regs.ARM_sp),
>  		  "I" (sizeof(struct pt_regs) * 2),
> -		  "J" (offsetof(struct pt_regs, ARM_sp)),
> -		  "J" (offsetof(struct pt_regs, ARM_pc)),
> -		  "J" (offsetof(struct pt_regs, ARM_cpsr)),
> -		  "J" (offsetof(struct pt_regs, ARM_lr))
> +		  "I" (offsetof(struct pt_regs, ARM_sp)),
> +		  "I" (offsetof(struct pt_regs, ARM_pc)),
> +		  "I" (offsetof(struct pt_regs, ARM_cpsr)),
> +		  "I" (offsetof(struct pt_regs, ARM_lr))
>  		: "memory", "cc");
>  }
>  
> -- 
> 2.7.0
> 
> 


From catalin.marinas at arm.com  Thu Feb 18 10:25:09 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Thu, 18 Feb 2016 18:25:09 +0000
Subject: [PATCH v6sub1 00/11] arm64: split linear and kernel mappings
In-Reply-To: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160218182509.GG2538@e104818-lin.cambridge.arm.com>

On Tue, Feb 16, 2016 at 01:52:31PM +0100, Ard Biesheuvel wrote:
> Ard Biesheuvel (11):
>   of/fdt: make memblock minimum physical address arch configurable
>   of/fdt: factor out assignment of initrd_start/initrd_end
>   arm64: prevent potential circular header dependencies in asm/bug.h
>   arm64: add support for ioremap() block mappings
>   arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
>   arm64: pgtable: implement static [pte|pmd|pud]_offset variants
>   arm64: decouple early fixmap init from linear mapping
>   arm64: kvm: deal with kernel symbols outside of linear mapping
>   arm64: move kernel image to base of vmalloc area
>   arm64: defer __va translation of initrd_start and initrd_end
>   arm64: allow kernel Image to be loaded anywhere in physical memory

I queued this patches (again) for 4.6. I'll wait a few days with the
rest of KASLR until these get a bit more coverage in -next.

Thanks.

-- 
Catalin


From ard.biesheuvel at linaro.org  Thu Feb 18 10:27:18 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 18 Feb 2016 19:27:18 +0100
Subject: [PATCH v6sub1 00/11] arm64: split linear and kernel mappings
In-Reply-To: <20160218182509.GG2538@e104818-lin.cambridge.arm.com>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160218182509.GG2538@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu_UqoYB5QAWOU9_iZDoRO=rqHu8o87JboSAqNqOhoOCXw@mail.gmail.com>

On 18 February 2016 at 19:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Tue, Feb 16, 2016 at 01:52:31PM +0100, Ard Biesheuvel wrote:
>> Ard Biesheuvel (11):
>>   of/fdt: make memblock minimum physical address arch configurable
>>   of/fdt: factor out assignment of initrd_start/initrd_end
>>   arm64: prevent potential circular header dependencies in asm/bug.h
>>   arm64: add support for ioremap() block mappings
>>   arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
>>   arm64: pgtable: implement static [pte|pmd|pud]_offset variants
>>   arm64: decouple early fixmap init from linear mapping
>>   arm64: kvm: deal with kernel symbols outside of linear mapping
>>   arm64: move kernel image to base of vmalloc area
>>   arm64: defer __va translation of initrd_start and initrd_end
>>   arm64: allow kernel Image to be loaded anywhere in physical memory
>
> I queued this patches (again) for 4.6. I'll wait a few days with the
> rest of KASLR until these get a bit more coverage in -next.
>
> Thanks.
>

Fingers crossed :-)


From s-anna at ti.com  Thu Feb 18 10:27:57 2016
From: s-anna at ti.com (Suman Anna)
Date: Thu, 18 Feb 2016 12:27:57 -0600
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <alpine.DEB.2.02.1602181721530.4792@utopia.booyaka.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com> <56BACCDB.2070507@ti.com>
 <alpine.DEB.2.02.1602111921090.20757@utopia.booyaka.com>
 <56BD8091.4090007@ti.com> <56BE1454.3030002@ti.com> <56C5D377.50901@ti.com>
 <alpine.DEB.2.02.1602181721530.4792@utopia.booyaka.com>
Message-ID: <56C60D2D.2060108@ti.com>

On 02/18/2016 11:23 AM, Paul Walmsley wrote:
> 
> On Thu, 18 Feb 2016, Sekhar Nori wrote:
> 
>> On Friday 12 February 2016 10:50 PM, Suman Anna wrote:
>>> Sekhar,
>>> Will you be following up with above suggestion since Kishon is gonna be out?
>>
>> Alright, noticed this action for me :) Went through the thread, and 
>> looks like this is what we want to see?
> 
> Thanks Sekhar.  Did you try the driver unbind/bind sequence a few times to 
> ensure that works, per Suman's earlier E-mail? 

Should work since the assert/deassert is now out of the driver
probe/remove path and is done only at init time, but will let Sekhar
confirm this.

> 
> Suman, is there any further testing that you are planning to do on this 
> patch?

No, nothing on my side, since this is now localized to PCIe and only on
DRA7xx. I will relook at your custom flags solution when I consolidate
the reset for OMAP IOMMUs and remoteprocs, that looks promising to
remove the pdata quirks for resets or dependencies in drivers against a
reset API.

> 
> - Paul
> 
> 
>>
>> Thanks,
>> Sekhar
>>
>> ---8<---
>> >From e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19 Mon Sep 17 00:00:00 2001
>> Message-Id: <e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19.1455803758.git.nsekhar at ti.com>
>> From: Sekhar Nori <nsekhar at ti.com>
>> Date: Thu, 18 Feb 2016 16:49:56 +0530
>> Subject: [PATCH 1/1] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS
>>
>> Add a custom reset handler for DRA7x PCIeSS. This
>> handler is required to deassert PCIe hardreset lines
>> after they have been asserted.
>>
>> This enables the PCIe driver to access registers after
>> PCIeSS has been runtime enabled without having to
>> deassert hardreset lines itself.
>>
>> With this patch applied, used lspci to make sure
>> connected PCIe device enumerates on DRA74x and DRA72x
>> EVMs.

Yep, this is what I had in mind. Glad that it resolves the issue.

>>
>> Signed-off-by: Sekhar Nori <nsekhar at ti.com>
>> ---
>> Applies to tag for-v4.6/omap-hwmod-a of Paul W's tree.
>>
>>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++
>>  1 file changed, 23 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> index b61355e2a771..252b74633e31 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> @@ -1526,8 +1526,31 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
>>   *
>>   */
>>  
>> +/*
>> + * As noted in documentation for _reset() in omap_hwmod.c, the stock reset
>> + * functionality of OMAP HWMOD layer does not deassert the hardreset lines
>> + * associated with an IP automatically leaving the driver to handle that
>> + * by itself. This does not work for PCIeSS which needs the reset lines
>> + * deasserted for the driver to start accessing registers.
>> + *
>> + * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset
>> + * lines after asserting them.
>> + */
>> +static int dra7xx_pciess_reset(struct omap_hwmod *oh)
>> +{
>> +	int i;
>> +
>> +	for (i = 0; i < oh->rst_lines_cnt; i++) {
>> +		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);
>> +		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);

Hmm, ignoring return values??

regards
Suman

>> +	}
>> +
>> +	return 0;
>> +}
>> +
>>  static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {
>>  	.name	= "pcie",
>> +	.reset	= dra7xx_pciess_reset,
>>  };
>>  
>>  /* pcie1 */
>> -- 
>> 2.6.3
>>
>>
> 
> 
> - Paul
> 



From jan.glauber at caviumnetworks.com  Thu Feb 18 10:28:50 2016
From: jan.glauber at caviumnetworks.com (Jan Glauber)
Date: Thu, 18 Feb 2016 19:28:50 +0100
Subject: [PATCH v4 4/5] arm64/perf: Enable PMCR long cycle counter bit
In-Reply-To: <20160218173428.GE16883@arm.com>
References: <cover.1455810755.git.jglauber@cavium.com>
 <467597048eda3004bd69f1fbe3981aab111e00dd.1455810755.git.jglauber@cavium.com>
 <20160218173428.GE16883@arm.com>
Message-ID: <20160218182850.GC16782@hardcore>

On Thu, Feb 18, 2016 at 05:34:28PM +0000, Will Deacon wrote:
> On Thu, Feb 18, 2016 at 05:50:13PM +0100, Jan Glauber wrote:
> > With the long cycle counter bit (LC) disabled the cycle counter is not
> > working on ThunderX SOC (ThunderX only implements Aarch64).
> > Also, according to documentation LC == 0 is deprecated.
> > 
> > To keep the code simple the patch does not introduce 64 bit wide counter
> > functions. Instead writing the cycle counter always sets the upper
> > 32 bits so overflow interrupts are generated as before.
> > 
> > Original patch from Andrew Pinksi <Andrew.Pinksi at caviumnetworks.com>
> 
> What does this mean? Do we need Andrew's S-o-B, or is this a fresh patch?
> 
> Will

I've modified Andrew's patch. I assumed his formal S-o-B is not
required. Please correct me if I'm wrong.

Jan


From tchalamarla at caviumnetworks.com  Thu Feb 18 10:29:18 2016
From: tchalamarla at caviumnetworks.com (tchalamarla at caviumnetworks.com)
Date: Thu, 18 Feb 2016 10:29:18 -0800
Subject: [PATCH V2] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
Message-ID: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>

From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>

Due to Errata#27704 CN88xx SMMUv2,supports  only shared ASID and VMID
namespaces; specifically within a given node SMMU0 and SMMU1 share,
as does SMMU2 and SMMU3.

This patch tries to address these issuee by supplying asid and vmid
base from devicetree.

changes from V1:
	- rebased on top of 16 bit VMID patch
	- removed redundent options from DT
	- insted of transform, DT now supplies starting ASID/VMID

Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
---
 .../devicetree/bindings/iommu/arm,smmu.txt         |  8 +++++
 drivers/iommu/arm-smmu.c                           | 37 +++++++++++++++-------
 2 files changed, 34 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index bb7e569..80b8484 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -57,6 +57,14 @@ conditions.
 
 - smmu-enable-vmid16 : Enable 16 bit VMID, if allowed.
 
+- asid-base :	Buggy SMMUv2 implementations which doesn't satisfy the
+		ASID namespace needs, use this field to specify starting
+		ASID for the SMMU.
+
+- vmid-base :	Buggy SMMUv2 implementations which doesn't satisfy the VMID
+		namespace needs, use this field to specify starting VMID
+		for the SMMU.
+
 Example:
 
         smmu {
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 003c442..dc46b9a 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -320,6 +320,9 @@ struct arm_smmu_device {
 	unsigned long			ipa_size;
 	unsigned long			pa_size;
 
+	u32				asid_base;
+	u32				vmid_base;
+
 	u32				num_global_irqs;
 	u32				num_context_irqs;
 	unsigned int			*irqs;
@@ -335,8 +338,8 @@ struct arm_smmu_cfg {
 };
 #define INVALID_IRPTNDX			0xff
 
-#define ARM_SMMU_CB_ASID(cfg)		((cfg)->cbndx)
-#define ARM_SMMU_CB_VMID(cfg)		((cfg)->cbndx + 1)
+#define ARM_SMMU_CB_ASID(smmu, cfg)	((u16)((smmu)->asid_base + (cfg)->cbndx))
+#define ARM_SMMU_CB_VMID(smmu, cfg)	((u16)((smmu)->vmid_base + (cfg)->cbndx))
 
 enum arm_smmu_domain_stage {
 	ARM_SMMU_DOMAIN_S1 = 0,
@@ -576,11 +579,11 @@ static void arm_smmu_tlb_inv_context(void *cookie)
 
 	if (stage1) {
 		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
-		writel_relaxed(ARM_SMMU_CB_ASID(cfg),
+		writel_relaxed(ARM_SMMU_CB_ASID(smmu, cfg),
 			       base + ARM_SMMU_CB_S1_TLBIASID);
 	} else {
 		base = ARM_SMMU_GR0(smmu);
-		writel_relaxed(ARM_SMMU_CB_VMID(cfg),
+		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg),
 			       base + ARM_SMMU_GR0_TLBIVMID);
 	}
 
@@ -602,7 +605,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
 
 		if (!IS_ENABLED(CONFIG_64BIT) || smmu->version == ARM_SMMU_V1) {
 			iova &= ~12UL;
-			iova |= ARM_SMMU_CB_ASID(cfg);
+			iova |= ARM_SMMU_CB_ASID(smmu, cfg);
 			do {
 				writel_relaxed(iova, reg);
 				iova += granule;
@@ -610,7 +613,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
 #ifdef CONFIG_64BIT
 		} else {
 			iova >>= 12;
-			iova |= (u64)ARM_SMMU_CB_ASID(cfg) << 48;
+			iova |= (u64)ARM_SMMU_CB_ASID(smmu, cfg) << 48;
 			do {
 				writeq_relaxed(iova, reg);
 				iova += granule >> 12;
@@ -630,7 +633,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
 #endif
 	} else {
 		reg = ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_TLBIVMID;
-		writel_relaxed(ARM_SMMU_CB_VMID(cfg), reg);
+		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg), reg);
 	}
 }
 
@@ -744,7 +747,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 #endif
 		/* if 16bit VMID required set VMID in CBA2R */
 		if (smmu->options & ARM_SMMU_OPT_ENABLE_VMID16)
-			reg |= ARM_SMMU_CB_VMID(cfg) << CBA2R_VMID_SHIFT;
+			reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBA2R_VMID_SHIFT;
 
 		writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBA2R(cfg->cbndx));
 	}
@@ -763,7 +766,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
 	} else if (!(smmu->options & ARM_SMMU_OPT_ENABLE_VMID16)) {
 		/*16 bit VMID is not enabled set 8 bit VMID here */
-		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
+		reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBAR_VMID_SHIFT;
 	}
 	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
 
@@ -771,11 +774,11 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 	if (stage1) {
 		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
 
-		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
+		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
 		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR0);
 
 		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
-		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
+		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
 		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR1);
 	} else {
 		reg64 = pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
@@ -1812,6 +1815,18 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 
 	parse_driver_options(smmu);
 
+	if (of_property_read_u32(dev->of_node, "#asid-base",
+				 &smmu->asid_base)) {
+		smmu->asid_base = 0;
+	}
+
+	if (of_property_read_u32(dev->of_node, "#vmid-base",
+				 &smmu->vmid_base)) {
+		smmu->vmid_base = 1;
+	}
+	if (smmu->vmid_base == 0)
+		smmu->vmid_base = 1;
+
 	if (smmu->version > ARM_SMMU_V1 &&
 	    smmu->num_context_banks != smmu->num_context_irqs) {
 		dev_err(dev,
-- 
2.1.0



From linus.walleij at linaro.org  Thu Feb 18 10:30:27 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 18 Feb 2016 19:30:27 +0100
Subject: [PATCH 1/3] irqchip: gic/realview: support more RealView DCC
 variants
In-Reply-To: <5028476.WAQS3ylXOd@wuerfel>
References: <1455803172-22747-1-git-send-email-linus.walleij@linaro.org>
 <56C5D304.5010708@arm.com> <5028476.WAQS3ylXOd@wuerfel>
Message-ID: <CACRpkdZD_qg0p8spr9HnFBSzXidi59J_kR8XBo-s8z-tSqKs5g@mail.gmail.com>

On Thu, Feb 18, 2016 at 3:40 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 18 February 2016 14:19:48 Marc Zyngier wrote:
>> On 18/02/16 13:46, Linus Walleij wrote:
>> > In the add-on file for the GIC dealing with the RealView family
>> > we currently only handle the PB11MPCore, let's extend this to
>> > manage the RealView EB ARM11MPCore as well. The Revision B of the
>> > ARM11MPCore core tile is a bit special and needs special handling
>> > as it moves a system control register around at random.
>>
>> Ah, 11MPCore RevB. That thing. Tried to locate one in the magic
>> cupboard, and failed. Oh well...
>
> What surprised me though is that it's enabled by default:

Looks like my fault according to git-blame...

I think this happened when making cover-all defconfigs for
multiplatform. I think I just turned everything on... not realizing
that turning on RevB disabled RevA+RevC.

However since it is the *only* version that works with QEMU
it actually makes some kind of weird sense to have it enabled
since the QEMU version is probably more common than
RevA+RevC...

Yours,
Linus Walleij


From nicolas.pitre at linaro.org  Thu Feb 18 10:31:56 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Thu, 18 Feb 2016 13:31:56 -0500 (EST)
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <HK2PR06MB0561377EABB3B4B8E94F22328AAF0@HK2PR06MB0561.apcprd06.prod.outlook.com>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
 <alpine.LFD.2.20.1602181244490.13632@knanqh.ubzr>
 <HK2PR06MB0561377EABB3B4B8E94F22328AAF0@HK2PR06MB0561.apcprd06.prod.outlook.com>
Message-ID: <alpine.LFD.2.20.1602181327060.13632@knanqh.ubzr>

On Thu, 18 Feb 2016, Chris Brandt wrote:

> > And realistically it makes no sense to use XIP (surely because you need
> > to save space) and have multi-platform support in your kernel.
> 
> 
> The problem is that you don't have a choice: Multi-platform is your only choice for many devices (MMU devices that is).
> 
> So for XIP, it comes down to either:
> 
> A) Go back to making individual configs for each MPU
> 
> B) Let everything keep getting grouped together into multi-platform, and then just de-selecting the MPU you don't want.
> 
> I can tell you when I build my upstream XIP kernel for testing for the RZ/A1, it's ARCH_MULTIPLATFORM (all Renesas parts are multiplatform) and then remove everything I don't want/need, my kernel size is 3.4MB.
> 
> 
> > IMHO it should be clear that with XIP there is only one platform that can
> > be supported.
> 
> I would be fine if there was some way you could only select XIP_KERNEL 
> if only 1 of the MPUs in the multiplatform group were selected...but I 
> can't figure out how to do that in the kbuild system (without adding 
> lots of chunky configs all over the place...which is not what I want)
> 
> Is there some way you can do a PLATFORM_COUNTER++ for each device that 
> is selected, and then XIP_KERNEL would depend on PLATFORM_COUNTER == 1 
> ?

I don't know all the Kconfig possibilities.

But would something like this work?

config FOO
	depends on !(XIP && CHOICE_MADE)
	select CHOICE_MADE

?


Nicolas


From ddaney at caviumnetworks.com  Thu Feb 18 10:37:45 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Thu, 18 Feb 2016 10:37:45 -0800
Subject: [PATCH v4 3/5] arm64: dts: Add Cavium ThunderX specific PMU
In-Reply-To: <20160218173248.GD16883@arm.com>
References: <cover.1455810755.git.jglauber@cavium.com>
 <2b8c963d3e63ecfc412bfd6fab804890a1586b16.1455810755.git.jglauber@cavium.com>
 <20160218173248.GD16883@arm.com>
Message-ID: <56C60F79.5060908@caviumnetworks.com>

On 02/18/2016 09:32 AM, Will Deacon wrote:
> On Thu, Feb 18, 2016 at 05:50:12PM +0100, Jan Glauber wrote:
>> Add a compatible string for the Cavium ThunderX PMU.
>
> Stupid question, but is "thunder" the name of the CPU or the SoC or ...?

At a high level Cavium ThunderX (tm) is a family of SoCs.  Since the SoC 
contains many different functional blocks ...

>
> Whatever we use to describe the PMU, should probably also identify the
> CPU uniquely.

... In the context of this patch, "cavium,thunder-pmu" refers to the PMU 
of Cavium's implementation of the ARMv8 Processing Element (PE) 
specification (i.e. the CPU), as found on the CN88XX family of SoCs.

If we think of this in terms of MIDR_EL1, That would be:

    Implementer: 0x43
    PartNum: 0xA1


>
> Will
>
>> Signed-off-by: Jan Glauber <jglauber at cavium.com>
>> ---
>>   Documentation/devicetree/bindings/arm/pmu.txt | 1 +
>>   arch/arm64/boot/dts/cavium/thunder-88xx.dtsi  | 5 +++++
>>   2 files changed, 6 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt
>> index 5651883..d3999a1 100644
>> --- a/Documentation/devicetree/bindings/arm/pmu.txt
>> +++ b/Documentation/devicetree/bindings/arm/pmu.txt
>> @@ -25,6 +25,7 @@ Required properties:
>>   	"qcom,scorpion-pmu"
>>   	"qcom,scorpion-mp-pmu"
>>   	"qcom,krait-pmu"
>> +	"cavium,thunder-pmu"
>>   - interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu
>>                  interrupt (PPI) then 1 interrupt should be specified.
>>
>> diff --git a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
>> index 9cb7cf9..2eb9b22 100644
>> --- a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
>> +++ b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
>> @@ -360,6 +360,11 @@
>>   		             <1 10 0xff01>;
>>   	};
>>
>> +	pmu {
>> +		compatible = "cavium,thunder-pmu", "arm,armv8-pmuv3";
>> +		interrupts = <1 7 4>;
>> +	};
>> +
>>   	soc {
>>   		compatible = "simple-bus";
>>   		#address-cells = <2>;
>> --
>> 1.9.1
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



From stern at rowland.harvard.edu  Thu Feb 18 10:46:23 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Thu, 18 Feb 2016 13:46:23 -0500 (EST)
Subject: [PATCH v5 1/1] USB: core: let USB device know device node
In-Reply-To: <1455612172-2081-1-git-send-email-peter.chen@nxp.com>
Message-ID: <Pine.LNX.4.44L0.1602181345570.1280-100000@iolanthe.rowland.org>

On Tue, 16 Feb 2016, Peter Chen wrote:

> From: Peter Chen <peter.chen at freescale.com>
> 
> Although most of USB devices are hot-plug's, there are still some devices
> are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
> If these kinds of USB devices are multiple functions, and they can supply
> other interfaces like i2c, gpios for other devices, we may need to
> describe these at device tree.
> 
> In this commit, it uses "reg" in dts as physical port number to match
> the phyiscal port number decided by USB core, if they are the same,
> then the device node is for the device we are creating for USB core.
> 
> Signed-off-by: Peter Chen <peter.chen at freescale.com>

Acked-by: Alan Stern <stern at rowland.harvard.edu>



From linus.walleij at linaro.org  Thu Feb 18 10:55:17 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 18 Feb 2016 19:55:17 +0100
Subject: Bunch of machines are not booting in next again, GPIO regression?
In-Reply-To: <20160217224415.GA3866@jcartwri.amer.corp.natinst.com>
References: <20160217192755.GC21202@atomide.com>
 <20160217195543.GA871@jcartwri.amer.corp.natinst.com>
 <20160217201259.GA16028@deathstar>
 <20160217202224.GD21202@atomide.com>
 <20160217224415.GA3866@jcartwri.amer.corp.natinst.com>
Message-ID: <CACRpkdY2=mYVDU2BXzN1rY7=mP_iyG3UEaCNVom4HFJDf61+0Q@mail.gmail.com>

On Wed, Feb 17, 2016 at 11:44 PM, Josh Cartwright <joshc at ni.com> wrote:

> Here's a properly cooked patch.  Otherwise, feel free to squash it in if
> it's easier for you.
>
> -- 8< --
> Subject: [PATCH] gpio: use kzalloc to allocate gpio_device

Patch applied, of course.

Big hugs and thanks for fixing my stupid mistake!

N?ras,
Linus Walleij


From ddaney at caviumnetworks.com  Thu Feb 18 10:57:55 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Thu, 18 Feb 2016 10:57:55 -0800
Subject: [PATCH v4 4/5] arm64/perf: Enable PMCR long cycle counter bit
In-Reply-To: <20160218173428.GE16883@arm.com>
References: <cover.1455810755.git.jglauber@cavium.com>
 <467597048eda3004bd69f1fbe3981aab111e00dd.1455810755.git.jglauber@cavium.com>
 <20160218173428.GE16883@arm.com>
Message-ID: <56C61433.2090006@caviumnetworks.com>

On 02/18/2016 09:34 AM, Will Deacon wrote:
> On Thu, Feb 18, 2016 at 05:50:13PM +0100, Jan Glauber wrote:
>> With the long cycle counter bit (LC) disabled the cycle counter is not
>> working on ThunderX SOC (ThunderX only implements Aarch64).
>> Also, according to documentation LC == 0 is deprecated.
>>
>> To keep the code simple the patch does not introduce 64 bit wide counter
>> functions. Instead writing the cycle counter always sets the upper
>> 32 bits so overflow interrupts are generated as before.
>>
>> Original patch from Andrew Pinksi <Andrew.Pinksi at caviumnetworks.com>
>
> What does this mean? Do we need Andrew's S-o-B, or is this a fresh patch?

I don't believe we need Andrew's S-o-B as the assertion of the 
Developer's Certificate of Origin 1.1 clauses (a), (b) and (d) is being 
made.  Specifically, clause (c) does not apply.

However this may be a gray area, so we could put on Andrew's S-o-B if 
that would make everybody happier.

David Daney


>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



From robin.murphy at arm.com  Thu Feb 18 10:59:18 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Thu, 18 Feb 2016 18:59:18 +0000
Subject: [PATCH 3/3] [RESEND] ARM: kprobes: use "I" constraint for inline
 assembly offsets
In-Reply-To: <1455819135.2958.6.camel@linaro.org>
References: <1455815113-2562966-1-git-send-email-arnd@arndb.de>
 <1455815113-2562966-4-git-send-email-arnd@arndb.de>
 <1455819135.2958.6.camel@linaro.org>
Message-ID: <56C61486.9070803@arm.com>

On 18/02/16 18:12, Jon Medhurst (Tixy) wrote:
> On Thu, 2016-02-18 at 18:05 +0100, Arnd Bergmann wrote:
>> build-testing with clang showed that the "J" constraint does not take
>> positive arguments on clang when building in for Thumb-2:
>>
>> core.c:540:3: error: invalid operand for inline asm constraint 'J'
>>
>> This has been reported as llvm bug https://llvm.org/bugs/show_bug.cgi?id=26061
>>
>> However, looking at the source code in depth, I found that the
>> kernel is also wrong, and it should not use "J" at all, but should
>> use "I" to pass an immediate argument to the inline assembly when that
>> is used as an offset to an 'ldr' instruction rather than the 'sub'
>> argument.
>
> This patch doesn't seem correct to me.
>
> The ARM ARM says the immediate offset to an ARM ldr instructions is "any
> value in the range 0-4095" and offsets may be added or subtracted,
> leading to values from ?4095 to 4095".
>
> And GCC machine constraints [1] says
>
> I
>      Integer that is valid as an immediate operand in a data processing
>      instruction. That is, an integer in the range 0 to 255 rotated by a
>      multiple of 2
> J
>      Integer in the range ?4095 to 4095
>
> So the current use of 'J' seems correct to me.

Hmm, Arnd reports the failure when building for Thumb-2, and the code 
under #ifdef CONFIG_THUMB2_KERNEL contains an ldrd, which takes a 
different immediate of the form imm8 * 4. Maybe it's just operand %5 
which needs fixing, although I don't see that a suitable constraint for 
that actually exists...

Robin.

> [1] https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints
>
>
>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>> ---
>>   arch/arm/probes/kprobes/core.c | 8 ++++----
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
>> index a4ec240ee7ba..4b34b40ca917 100644
>> --- a/arch/arm/probes/kprobes/core.c
>> +++ b/arch/arm/probes/kprobes/core.c
>> @@ -570,10 +570,10 @@ void __kprobes jprobe_return(void)
>>   		:
>>   		: "r" (kcb->jprobe_saved_regs.ARM_sp),
>>   		  "I" (sizeof(struct pt_regs) * 2),
>> -		  "J" (offsetof(struct pt_regs, ARM_sp)),
>> -		  "J" (offsetof(struct pt_regs, ARM_pc)),
>> -		  "J" (offsetof(struct pt_regs, ARM_cpsr)),
>> -		  "J" (offsetof(struct pt_regs, ARM_lr))
>> +		  "I" (offsetof(struct pt_regs, ARM_sp)),
>> +		  "I" (offsetof(struct pt_regs, ARM_pc)),
>> +		  "I" (offsetof(struct pt_regs, ARM_cpsr)),
>> +		  "I" (offsetof(struct pt_regs, ARM_lr))
>>   		: "memory", "cc");
>>   }
>>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>



From pjones at redhat.com  Thu Feb 18 11:16:24 2016
From: pjones at redhat.com (Peter Jones)
Date: Thu, 18 Feb 2016 14:16:24 -0500
Subject: [PATCH v2 1/2] efi: esrt: use memremap not ioremap to access
 ESRT table in memory
In-Reply-To: <20160218141544.GH2651@codeblueprint.co.uk>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160218104407.GC2651@codeblueprint.co.uk>
 <CAKv+Gu_AW7PKJJOd2mbEu3LKJe+gNaPHnH=sgO=YXM_KWFyKxw@mail.gmail.com>
 <20160218132824.GE2651@codeblueprint.co.uk>
 <CAKv+Gu-s1pzYBzuDG-Z7s3gyo8dPOfeidZQ+rim-uAWZCBcKQQ@mail.gmail.com>
 <20160218134324.GG2651@codeblueprint.co.uk>
 <CAKv+Gu875r9RkDC723kNsG4XC0eSE9RPPmSFZrD0sx0QxS+V4g@mail.gmail.com>
 <20160218141544.GH2651@codeblueprint.co.uk>
Message-ID: <20160218191624.GA1515@redhat.com>

On Thu, Feb 18, 2016 at 02:15:44PM +0000, Matt Fleming wrote:
> On Thu, 18 Feb, at 02:44:02PM, Ard Biesheuvel wrote:
> > On 18 February 2016 at 14:43, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> > > On Thu, 18 Feb, at 02:29:32PM, Ard Biesheuvel wrote:
> > >> On 18 February 2016 at 14:28, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> > >> > On Thu, 18 Feb, at 01:16:05PM, Ard Biesheuvel wrote:
> > >> >> On 18 February 2016 at 11:44, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> > >> >> > On Mon, 15 Feb, at 12:32:32PM, Ard Biesheuvel wrote:
> > >> >> >> On ARM and arm64, ioremap() and memremap() are not interchangeable like
> > >> >> >> on x86, and the use of ioremap() on ordinary RAM is typically flagged
> > >> >> >> as an error if the memory region being mapped is also covered by the
> > >> >> >> linear mapping, since that would lead to aliases with conflicting
> > >> >> >> cacheability attributes.
> > >> >> >>
> > >> >> >> Since what we are dealing with is not an I/O region with side effects,
> > >> >> >> using ioremap() here is arguably incorrect anyway, so let's replace
> > >> >> >> it with memremap instead. Also add a missing unmap on the success path,
> > >> >> >> and drop a memblock_remove() call which does not belong here, this far
> > >> >> >> into the boot sequence.
> > >> >> >>
> > >> >> >> Cc: Peter Jones <pjones at redhat.com>
> > >> >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> > >> >> >> ---
> > >> >> >>  drivers/firmware/efi/esrt.c | 16 ++++++++--------
> > >> >> >>  1 file changed, 8 insertions(+), 8 deletions(-)
> > >> >> >>
> > >> >> >
> > >> >> > [...]
> > >> >> >
> > >> >> >> @@ -432,8 +434,6 @@ static int __init esrt_sysfs_init(void)
> > >> >> >>       if (error)
> > >> >> >>               goto err_cleanup_list;
> > >> >> >>
> > >> >> >> -     memblock_remove(esrt_data, esrt_data_size);
> > >> >> >> -
> > >> >> >>       pr_debug("esrt-sysfs: loaded.\n");
> > >> >> >>
> > >> >> >>       return 0;
> > >> >> >
> > >> >> > Shouldn't we be replacing memblock_remove() with free_bootmem_late()?
> > >> >> > The original ESRT region is still reserved at this point, so we should
> > >> >> > do our best to release it to the page allocator.
> > >> >>
> > >> >> I'd rather we keep it reserved. That way, the config table entry still
> > >> >> points to something valid, which could be useful for kexec(), I think?
> > >> >> At least, that is how I intended to handle config tables on ARM ...
> > >> >
> > >> > If we're going to reserve it why do we need to copy the data out at
> > >> > all in esrt_sysfs_init()?
> > >>
> > >> Excellent question. I don't think there is any point to doing that.
> > >
> > > ... Unless the data is contained in an EFI Boot Services region ;-)
> > >
> > > Peter?
> > 
> > Yes, it usually is. Is that a problem?
> 
> Yes, we free the Boot Services regions before hitting userspace on
> x86, see efi_free_boot_services(). We do this map/copy/unmap trick in
> the ACPI BGRT driver for that reason.
> 
> The Boot Services regions can be many gigabytes in size, which makes
> leaving them alone impractical.
> 
> For kexec on x86 we simply discard the BGRT table, which isn't the end
> of the world because who really needs access to the BGRT image on
> kexec reboot? However, I can see the value of preserving the ESRT.
> 
> I guess we've got two options, 1) copy out the chunks of Boot Services
> regions we're interested in and rewrite the EFI tables to point at
> these new allocations and free/discard all of the original Boot
> Services regions or 2) only selectively free the Boot Services
> regions.

I think we've got to copy them out anyway and give a new copy to any
kexec'd kernel.  In 5.6 in the spec, it says of the table data:

  The VendorGuid associated with a given VendorTable pointer defines
  whether or not a particular address reported in the table gets fixed
  up when a call to SetVirtualAddressMap() is made. It is the
  responsibility of the specification defining the VendorTable to
  specify whether to convert the addresses reported in the table.

Of course the ESRT definition doesn't say anything about that, since
it actually says it's in BootServicesData, and so remapping its address
doesn't really make a lot of sense.  Unfortunately the others are
actually *less* well defined.  Here's a list of the tables defined in
the 2.6 spec, and what they say about either their allocation region
or their remap policy:

ACPI20		nada			Physical Address (PA)
ACPI		nada			PA
SAL		nada			PA
SMBIOS		nada			PA
SMBIOS3		nada			PA
MPS		nada			PA
properties	nada			PA
memory attrs	nada			nada
debugimage info	nada			nada
IEIT		nada			nada
ESRT		BootServicesData	nada

So... for the ones specified by physical addresses, we know we can
access them early on, and it probably doesn't matter what allocation
pool they're in, because we're reserving them anyway.  Memory attributes
I would /guess/ have to also be specified by PAs; it's in the very next
subsection of the spec from all the other ones, and I think it just got
omitted from the list.  That leaves the last three.  As an aside, since
these definitions are so very poor, I'm going to put it on my TODO for
USST to clarify and fix these up, as well as to look at systemic fixes
for this problem in the future.

Anyway, the last three.  I think it's safe to assume that they are
mapped to virtual addresses we can read from *before*
SetVirtualAddressMap() and ExitBootServices() are called, especially
since we generally have an identity map before then anyway, but we
really don't know anything at all after that.  We also don't know the
sizes without parsing the tables themselves, which continues to be a
pain in the ass.

> I've always stayed clear of 2) in case there exists cross-region
> references in the data that isn't obvious. I'd like to think that
> would never happen, but, you know, dragons lurk here, etc.
> 
> Though actually, now I think about it, cross-region references can't
> possibly exist because they'd cause issues with the current code.

I would think any single table has to be entirely within the same
region, yes.

> So maybe the best solution is actually 2), where we preserve the Boot
> Services regions if any of the drivers (ESRT, BGRT) request them but
> free all the others? 

Note that BGRT is an ACPI table rather than an EFI Configuration Table,
and as such we actually have bounds for it.  The others are... special.

- Debug Image Info actually has a size.  That's nice of it.  It's also
  the table we've never talked about using.
- ESRT you have to compute the size as your parse it, and it has
  variable length members, so the driver for it needs to figure it out.
- IEIT has a number of entries at the top level, and then each entry has
  a size.  Probably still best to have the driver that's parsing it
  figure the size out.
- the Memory Attributes Table has a number of entries and a size of each
  entry, so you can just multiply.

> What are the lifetime rules for Boot Services regions on arm*?

I'll leave this for Ard and friends.

So the question I have is: would you rather chop up regions and reserve
the space, or allocate a new copy and update the configuration table
(after ExitBootServices()) to point to it?  The latter makes it pretty
easy to do from an API that all these drivers can use, and it makes the
kexec case completely transparent.

Up to you.

-- 
  Peter


From sergei.shtylyov at cogentembedded.com  Thu Feb 18 11:31:31 2016
From: sergei.shtylyov at cogentembedded.com (Sergei Shtylyov)
Date: Thu, 18 Feb 2016 22:31:31 +0300
Subject: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
In-Reply-To: <20160217234857.GA6886@verge.net.au>
References: <2543047.yYrDdYb9v5@wasted.cogentembedded.com>
 <874mdhtn7d.wl%kuninori.morimoto.gx@renesas.com>
 <20160210171455.GB17671@verge.net.au> <56BE0CB1.4070408@cogentembedded.com>
 <20160212184343.GA31655@verge.net.au> <56BE2DC6.4080802@cogentembedded.com>
 <20160212193347.GB23472@verge.net.au> <56BE3912.9000601@cogentembedded.com>
 <20160217053848.GC11534@verge.net.au> <56C4C506.8040803@cogentembedded.com>
 <20160217234857.GA6886@verge.net.au>
Message-ID: <56C61C13.8000301@cogentembedded.com>

On 02/18/2016 02:48 AM, Simon Horman wrote:

>>>>>>>>>>> Define the generic R8A7794 part of  the sound device node.
>>>>>>>>>>> This sound device  is a complex one and comprises the Audio Clock Generator
>>>>>>>>>>> (ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface [Unit]
>>>>>>>>>>> (SSI[U]), and Audio DMAC-Peripheral-Peripheral.
>>>>>>>>>>> It is up  to the board file to enable the device.
>>>>>>>>>>>
>>>>>>>>>>> This patch is based on the R8A7791 sound work by Kuninori Morimoto.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
>>>>>>>>>> (snip)
>>>>>>>>>>> +		rcar_sound,src {
>>>>>>>>>>> +			src1: src at 1 {
>>>>>>>>>>> +				interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>>>>>> +				dmas = <&audma0 0x87>, <&audma0 0x9c>;
>>>>>>>>>>> +				dma-names = "rx", "tx";
>>>>>>>>>>> +			};
>>>>>>>>>>> +			src2: src at 2 {
>>>>>>>>>>> +				interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>>>>>> +				dmas = <&audma0 0x89>, <&audma0 0x9e>;
>>>>>>>>>>> +				dma-names = "rx", "tx";
>>>>>>>>>>> +			};
>>>>>>>>>>> +			src3: src at 3 {
>>>>>>>>>>> +				interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>>>>>> +				dmas = <&audma0 0x8b>, <&audma0 0xa0>;
>>>>>>>>>>> +				dma-names = "rx", "tx";
>>>>>>>>>>> +			};
>>>>>>>>>>> +			src4: src at 4 {
>>>>>>>>>>> +				interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>>>>>> +				dmas = <&audma0 0x8d>, <&audma0 0xb0>;
>>>>>>>>>>> +				dma-names = "rx", "tx";
>>>>>>>>>>> +			};
>>>>>>>>>>> +			src5: src at 5 {
>>>>>>>>>>> +				interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>>>>>> +				dmas = <&audma0 0x8f>, <&audma0 0xb2>;
>>>>>>>>>>> +				dma-names = "rx", "tx";
>>>>>>>>>>> +			};
>>>>>>>>>>> +			src6: src at 6 {
>>>>>>>>>>> +				interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
>>>>>>>>>>> +				dmas = <&audma0 0x91>, <&audma0 0xb4>;
>>>>>>>>>>> +				dma-names = "rx", "tx";
>>>>>>>>>>> +			};
>>>>>>>>>>> +		};
>>>>>>>>>>
>>>>>>>>>> I think this can't work correctly, because driver is assuming
>>>>>>>>>> DT has all channles (from 0). (see linux/sound/soc/sh/rcar/src.c :: rsnd_src_probe)
>>>>>>>>>> Can you adds dummy src0 with some comments ? or fix src.c driver ?
>>>>>>>>>
>>>>>>>>> I would prefer the driver to be fixed (I had a similar patchset locally
>>>>>>>>> and I found it doesn't work).
>>>>>>>>
>>>>>>>>     You mean you had R8A7794 sound patch set too?
>>>>>>>
>>>>>>> Yes, I was working on it recently.
>>>>>>> I suppose we should coordinate these things in future to avoid
>>>>>>> duplicated effort.
>>>>>>
>>>>>>     Yes, seems a good idea now. :-)
>>>>>>
>>>>>>>>> The reason is that DT should describe
>>>>>>>>> the hardware rather than the current state of the software.
>>>>>>>>
>>>>>>>>     Yes, of course. Just tell me do I have to fix the driver *before* this
>>>>>>>> patch set is accepted?
>>>>>>
>>>>>>> I did not entirely get to the bottom of the problem, but I think that at
>>>>>>> the very least something needs to be done about the for_each_rsnd_src()
>>>>>>> loop in rsnd_src_probe.
>>>>>>
>>>>>>     It's not that it replies to my question. :-)
>>>>>>     So you're looking at this issue yourself?
>>>>>
>>>>> I have not got very far, as you can see, but I was planning to look into it.
>>>>> I don't mind if you want to do so.
>>>>
>>>>     After consultation with the management, I'm going to look into this issue
>>>> myself. :-)
>>>
>>> Excellent.
>>
>>     But not immediately. I have some other things to look at before that (DU
>> and AVB), they'll going to take some (significant) time... :-(
>>
>>> FWIW, I can test anything you come up with for the r8a7794 an alt board
>>
>>     I have remote access to Alt now, in fact using it currently for the AVB work.
>>
>>> or post patches for it once you have r8a7794/silk sorted out.
>>
>>     I already have audio on these working. Or you're going to wait until I
>> fix the SRC issue?
>
> I'm happy to merge a subset of your r8a7794/silk patches,
> that don't touch the SRC issue if you think that is appropriate.

    I think you can merge everything R8A7794 specific. The SILK patch doesn't 
make use of SRCs yet but depends on the PFC patches, so makes sense to hold it 
up...

>  From there I could get similar functionality running on the Alt - I don't
> expect that to be a difficult task.

    Sure -- if you have direct access to the board.

> And then when you come back to the SRC
> issue we can enhance support for r8a7794/silk,alt.

    Yes.

MBR, Sergei



From stuart.yoder at nxp.com  Thu Feb 18 11:33:19 2016
From: stuart.yoder at nxp.com (Stuart Yoder)
Date: Thu, 18 Feb 2016 19:33:19 +0000
Subject: RFC: extend IOMMU attributes
In-Reply-To: <20160218162145.GB16883@arm.com>
References: <HE1PR04MB1641F22E38710B68F4ED891F8DAF0@HE1PR04MB1641.eurprd04.prod.outlook.com>
 <20160218162145.GB16883@arm.com>
Message-ID: <HE1PR04MB16418B721EF4A95F6860542B8DAF0@HE1PR04MB1641.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: Thursday, February 18, 2016 10:22 AM
> To: Stuart Yoder <stuart.yoder at nxp.com>
> Cc: joro at 8bytes.org; robin.murphy at arm.com; iommu at lists.linux-foundation.org; linux-arm-
> kernel at lists.infradead.org; Varun Sethi <V.Sethi at nxp.com>; Bharat Bhushan
> <bharat.bhushan at nxp.com>; Nipun Gupta <nipun.gupta at nxp.com>; Peter Newton
> <peter.newton at nxp.com>
> Subject: Re: RFC: extend IOMMU attributes
> 
> Hi Stuart,
> 
> On Thu, Feb 18, 2016 at 04:16:26PM +0000, Stuart Yoder wrote:
> > We are implementing support for some specialized NXP SoC network
> > devices and have the desire to extend the mapping attributes beyond
> > those currently in iommu.h. (I see there is a recent proposal to
> > add an IOMMU_MMIO flag)
> >
> > What we have right now in Linux is a least-common-denominator set of
> > attributes, while for the ARM SMMU there is a much richer set of
> > attributes that seem useful to support. Specifically, we have one
> > SoC device we're dealing with right now that is the target of DMA
> > that functionally requires a "cacheable, non-shareable" attribute
> > in its SMMU mapping.
> >
> > In addition, there are many other attributes such as r/w allocate
> > hints, transient hints, write-back/write-thru, etc in the SMMU.
> >
> > We wanted to see what your thinking is with respect to the
> > direction the Linux IOMMU layer will head over the longer term with
> > respect to attributes.
> >
> > Is there anything problematic with continuing to grow the
> > attributes in iommu.h?...e.g.:
> >
> >  #define IOMMU_READ            (1 << 0)
> >  #define IOMMU_WRITE           (1 << 1)
> > -#define IOMMU_CACHE           (1 << 2) /* DMA cache coherency */
> > +#define IOMMU_CACHE_COHERENT  (1 << 2) /* cacheable and coherent */
> >  #define IOMMU_NOEXEC          (1 << 3)
> >  #define IOMMU_MMIO            (1 << 4) /* e.g. things like MSI doorbells */
> > +#define IOMMU_CACHEABLE       (1 << 5) /* cacheable, not coherent */
> 
> What does that even mean?

It means allocate in the cache, but don't propagate coherency.
In our case we have a device using an A57 cluster ACP port
to do stashing.  

             cluster
       +------------------+
       |   A57     A57    |                +----+
       |           ......ACP..<............|SMMU|<...device
       |  +--------.--+   |  non-coherent  +----+
       |  |    L2  v  |   | write w/allocate
       |  +--------.--+   |
       +-----------.------+
                   .
       +-----------v------+
       |     CCN-504      |
       +-------------.----+
                     .
              +------v------+
              |    device   |
              | (descriptor |
              |    rings)   | 
              +-------------+

The device in question is doing a cacheable write targeting some
device descriptor rings.  The purpose of this transaction is to stash
the descriptor ring data in the L2 cache so the driver on the
A57s can get at it with low latency.  It has to be non-coherent
because of stuff related to how things are hooked up to CCN-504
(can take more details offline if you want).  Because it is non
coherent, the driver obviously has to be affined to the cluster.
It's a lot of hoops to jump through, but the performance benefit
is worth it.

> > +#define IOMMU_CACHE_ALLOCATE  (1 << 6) /* hint to allocate in the cache */
> >
> > Also, are we willing to let somewhat architecture specific flags
> > onto that list?  For, example the ARM 'transient' hint.
> 
> If we're going to support fine-grained attribute control, I think it needs
> to be done in a page-table specific manner. That is, io-pgtable-arm could
> provide those attribute controls which feature in the ARMv8 architecture...

So there would be some new API for users like vfio?

> ...but that brings me onto my next question: Who on Earth is actually
> going to provide these attributes to the IOMMU API?
> 
> There seems to be a missing piece.

Currently it would be vfio, because the driver is in user space.
There are some details to be worked out regarding how vfio would
determine and provide the attributes.  This is a device on the
fsl-mc bus (see drivers/staging/fsl-mc/README.txt) and the
vfio-fsl-mc bus layer should be able to determine what attributes
to use.

Once the kernel dma map API is hooked up to the SMMU, I think there
could be similar requirements down the road for kernel drivers.
If a driver is  intelligent enough to use some of the fine grained
attributes, how can that be supported?

Thanks,
Stuart


From ard.biesheuvel at linaro.org  Thu Feb 18 11:38:45 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 18 Feb 2016 20:38:45 +0100
Subject: [PATCH v6sub1 00/11] arm64: split linear and kernel mappings
In-Reply-To: <CAKv+Gu_UqoYB5QAWOU9_iZDoRO=rqHu8o87JboSAqNqOhoOCXw@mail.gmail.com>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160218182509.GG2538@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_UqoYB5QAWOU9_iZDoRO=rqHu8o87JboSAqNqOhoOCXw@mail.gmail.com>
Message-ID: <CAKv+Gu_25mz37gdgVx5Yz7DJ+QbOMNa4rYBymFL1nL7nGOzBVQ@mail.gmail.com>

On 18 February 2016 at 19:27, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 18 February 2016 at 19:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> On Tue, Feb 16, 2016 at 01:52:31PM +0100, Ard Biesheuvel wrote:
>>> Ard Biesheuvel (11):
>>>   of/fdt: make memblock minimum physical address arch configurable
>>>   of/fdt: factor out assignment of initrd_start/initrd_end
>>>   arm64: prevent potential circular header dependencies in asm/bug.h
>>>   arm64: add support for ioremap() block mappings
>>>   arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
>>>   arm64: pgtable: implement static [pte|pmd|pud]_offset variants
>>>   arm64: decouple early fixmap init from linear mapping
>>>   arm64: kvm: deal with kernel symbols outside of linear mapping
>>>   arm64: move kernel image to base of vmalloc area
>>>   arm64: defer __va translation of initrd_start and initrd_end
>>>   arm64: allow kernel Image to be loaded anywhere in physical memory
>>
>> I queued this patches (again) for 4.6. I'll wait a few days with the
>> rest of KASLR until these get a bit more coverage in -next.
>>

I rebased the remaining patches onto for-next/core, and pushed it here:
https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-kaslr-v6

I need to check if everything still works, and if it does, I will send
them out as v6sub2
Note that I have included the arm64 extable patch plus its generic
dependency, and the kallsyms patches as well. We can decide later how
to proceed with those, but for now, I included them for completeness.


From Chris.Brandt at renesas.com  Thu Feb 18 11:42:20 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Thu, 18 Feb 2016 19:42:20 +0000
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <alpine.LFD.2.20.1602181327060.13632@knanqh.ubzr>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
 <alpine.LFD.2.20.1602181244490.13632@knanqh.ubzr>
 <HK2PR06MB0561377EABB3B4B8E94F22328AAF0@HK2PR06MB0561.apcprd06.prod.outlook.com>
 <alpine.LFD.2.20.1602181327060.13632@knanqh.ubzr>
Message-ID: <HK2PR06MB0561C0EEA846C516645239338AAF0@HK2PR06MB0561.apcprd06.prod.outlook.com>

On Thu, 18 Feb 2016, Nicolas Pitre wrote:

> > Is there some way you can do a PLATFORM_COUNTER++ for each device that 
> > is selected, and then XIP_KERNEL would depend on PLATFORM_COUNTER == 1 
> > ?
>
> I don't know all the Kconfig possibilities.
>
> But would something like this work?
>
> config FOO
>	depends on !(XIP && CHOICE_MADE)
>	select CHOICE_MADE

I follow your logic and that might work: If you made multiple choices, it would just take the first one.

However...I just tried it and it crashes.

scripts/kconfig/mconf  Kconfig
make[2]: *** [menuconfig] Segmentation fault (core dumped)
make[1]: *** [menuconfig] Error 2


It looks like you can't depend on something not being set that you are going to set yourself. Basically..."do as I say, not as I do"


Chris



From k at japko.eu  Thu Feb 18 11:42:56 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Thu, 18 Feb 2016 20:42:56 +0100
Subject: [linux-sunxi] Re: [PATCH] clk: sunxi: Add missing H3 apb0 clock
 documentation
In-Reply-To: <CAGb2v67PiQHVQfhbsk2f3aQFOaDXHy3P+NJDoTw-+GshubWaYQ@mail.gmail.com>
References: <CACRpkdbfNeh7_=3ReQtJc7OxkkQEn+BUhZ0O0SKnFsRD=WZiUQ@mail.gmail.com>
 <1455807809-30827-1-git-send-email-k@japko.eu>
 <CAGb2v67PiQHVQfhbsk2f3aQFOaDXHy3P+NJDoTw-+GshubWaYQ@mail.gmail.com>
Message-ID: <20160218194255.GD18745@box2.japko.eu>

On Thu, Feb 18, 2016 at 09:07:16AM -0800, Chen-Yu Tsai wrote:
>On Thu, Feb 18, 2016 at 7:03 AM, Krzysztof Adamski
><krzysztof.adamski at tieto.com> wrote:
>> allwinner,sun8i-h3-apb0-gates-clk was added by
>> commit ba83a11104ae ("pinctrl: sunxi: Add H3 R_PIO controller support")
>> but the patch was missing proper binding documentation. This patch fixes
>> this issue.
>
>What are you talking about? The commit you mentioned only adds the pinctrl
>driver. Your H3 PRCM related clock and reset patches are still pending.
>No need for this patch as your earlier patches includes this.

Damn, I messed up patches, I must have been tired or something. It was 
documentation for "allwinner,sun8i-h3-r-pinctrl" that was missing. I'm 
sending a new patch. Sorry for confusion.

Best regards,
Krzysztof Adamski


From k at japko.eu  Thu Feb 18 11:49:31 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Thu, 18 Feb 2016 20:49:31 +0100
Subject: [PATCH] pinctrl: sunxi: Add missing H3 R_PIO binding documentation
In-Reply-To: <CACRpkdbfNeh7_=3ReQtJc7OxkkQEn+BUhZ0O0SKnFsRD=WZiUQ@mail.gmail.com>
References: <CACRpkdbfNeh7_=3ReQtJc7OxkkQEn+BUhZ0O0SKnFsRD=WZiUQ@mail.gmail.com>
Message-ID: <20160218194931.GA16393@box2.japko.eu>

allwinner,sun8i-h3-r-pinctrl was added by
commit ba83a11104ae ("pinctrl: sunxi: Add H3 R_PIO controller support")
but the patch was missing proper binding documentation. This patch fixes
this issue.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index 9213b27..3e56b16 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -21,6 +21,7 @@ Required properties:
   "allwinner,sun9i-a80-r-pinctrl"
   "allwinner,sun8i-a83t-pinctrl"
   "allwinner,sun8i-h3-pinctrl"
+  "allwinner,sun8i-h3-r-pinctrl"
 
 - reg: Should contain the register physical address and length for the
   pin controller.
-- 
2.1.4



From davem at davemloft.net  Thu Feb 18 12:06:31 2016
From: davem at davemloft.net (David Miller)
Date: Thu, 18 Feb 2016 15:06:31 -0500 (EST)
Subject: [PATCH 2/2] net, thunderx: Use bool in structs where possible
In-Reply-To: <20160218164217.GP24726@rric.localdomain>
References: <1455799149-19590-3-git-send-email-rrichter@caviumnetworks.com>
 <20160218.110514.652169911099659792.davem@davemloft.net>
 <20160218164217.GP24726@rric.localdomain>
Message-ID: <20160218.150631.574392083739567663.davem@davemloft.net>

From: Robert Richter <robert.richter at caviumnetworks.com>
Date: Thu, 18 Feb 2016 17:42:17 +0100

> On 18.02.16 11:05:14, David Miller wrote:
>> From: Robert Richter <rrichter at caviumnetworks.com>
>> Date: Thu, 18 Feb 2016 13:39:09 +0100
>> 
>> > From: Robert Richter <rrichter at cavium.com>
>> > 
>> > Looks like the :1 notation was accidentally introduced (this still
>> > uses 1 byte per flag). Using bool instead, which is the common use.
>> > 
>> > Signed-off-by: Robert Richter <rrichter at cavium.com>
>> 
>> Such cleanups are not appropriate for 'net'.  Only real bug fixes should
>> be targetted that.
>> 
>> Respin these patches targetting the correct tree(s).
> 
> Do you mean posting the two as "trivial" patches?

No I mean posting #1 targetted at my 'net' GIT tree as a bug fix,
and posting #2 targetted separately at my 'net-next' GIT tree as
a cleanup.

This is how we've been doing things for more than a decade.


From f.fainelli at gmail.com  Thu Feb 18 12:12:05 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Thu, 18 Feb 2016 12:12:05 -0800
Subject: [GIT PULL 2/2] bcm2835 changes to DT for 4.6
In-Reply-To: <1455764208-5679-2-git-send-email-eric@anholt.net>
References: <1455764208-5679-1-git-send-email-eric@anholt.net>
 <1455764208-5679-2-git-send-email-eric@anholt.net>
Message-ID: <56C62595.7020802@gmail.com>

On 17/02/16 18:56, Eric Anholt wrote:
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git at github.com:anholt/linux.git bcm2835-dt-next-2016-02-17

I cannot find this branch, could you verify it is pushed and create a
tag for me to pull from instead?

Thanks!

> 
> for you to fetch changes up to 1305141d1a7254b53b35303ee84f4c4948007bd0:
> 
>   ARM: bcm2835: add bcm2835-aux-uart support to DT (2016-02-17 11:01:00 -0800)
> 
> ----------------------------------------------------------------
> This pull request covers mostly DT changes that didn't make it into
> 4.5 because required header files went through other trees, plus the
> AUX uart support this time around.
> 
> ----------------------------------------------------------------
> Alexander Aring (1):
>       ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
> 
> Lubomir Rintel (1):
>       ARM: bcm2835: dt: Add Raspberry Pi Model A
> 
> Martin Sperl (3):
>       ARM: bcm2835: add the auxiliary spi1 and spi2 to the device tree
>       ARM: bcm2835: follow dt uart node-naming convention
>       ARM: bcm2835: add bcm2835-aux-uart support to DT
> 
> Remi Pommarel (1):
>       ARM: bcm2835: Add PWM clock support to the device tree
> 
>  arch/arm/boot/dts/Makefile          |  1 +
>  arch/arm/boot/dts/bcm2835-rpi-a.dts | 24 +++++++++++++++++++++
>  arch/arm/boot/dts/bcm2835-rpi.dtsi  | 16 ++++++++++++++
>  arch/arm/boot/dts/bcm283x.dtsi      | 43 +++++++++++++++++++++++++++++++++++--
>  4 files changed, 82 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/boot/dts/bcm2835-rpi-a.dts
> 


-- 
Florian


From f.fainelli at gmail.com  Thu Feb 18 12:13:04 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Thu, 18 Feb 2016 12:13:04 -0800
Subject: [GIT PULL 1/2] bcm2835 changes to defconfigs for 4.6
In-Reply-To: <1455764208-5679-1-git-send-email-eric@anholt.net>
References: <1455764208-5679-1-git-send-email-eric@anholt.net>
Message-ID: <56C625D0.3010504@gmail.com>

On 17/02/16 18:56, Eric Anholt wrote:
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git at github.com:anholt/linux.git bcm2835-defconfig-next-2016-02-17

Same here, could not find this branch, should I pull from
bcm2835-defconfig-next directly?

> 
> for you to fetch changes up to 0a05d3b71ada526ef93019fb3fbd6a95561a8a5f:
> 
>   ARM: multi_v7_defconfig: Enable BCM283x (2016-02-17 11:18:05 -0800)
> 
> ----------------------------------------------------------------
> This pull request brings in defconfig changes to enable bcm2836 in the
> 2835 and multi_v7 defconfigs.
> 
> ----------------------------------------------------------------
> Daniel Stone (1):
>       ARM: multi_v7_defconfig: Enable BCM283x
> 
> Stefan Wahren (2):
>       ARM: bcm2835_defconfig: Enable RPi firmware driver
>       ARM: bcm2835_defconfig: Enable RPi power domain driver
> 
> Stephen Warren (3):
>       ARM: bcm2835_defconfig: rebuild on next-20160205
>       ARM: bcm2835_defconfig: disable DEBUG_LL
>       ARM: bcm2835_defconfig: enable ARMv7 support
> 
>  arch/arm/configs/bcm2835_defconfig  | 11 +++++------
>  arch/arm/configs/multi_v7_defconfig | 12 ++++++++++++
>  2 files changed, 17 insertions(+), 6 deletions(-)
> 


-- 
Florian


From linus.walleij at linaro.org  Thu Feb 18 12:31:30 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 18 Feb 2016 21:31:30 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56C5C8FD.7090004@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <56C438DA.5040109@ti.com>
 <CACRpkdZ+G17hmVP8AejL7NTqg7k0SBC5kgF55ASjD+kfuGFJhQ@mail.gmail.com>
 <20160217213250.GK19428@n2100.arm.linux.org.uk>
 <56C5B080.9090007@ti.com>
 <20160218131233.GP19428@n2100.arm.linux.org.uk>
 <56C5C8FD.7090004@ti.com>
Message-ID: <CACRpkdYRNLdsR1fdJ0WyVpRbtca+1zSjohSKKQcmSgARhRejhA@mail.gmail.com>

On Thu, Feb 18, 2016 at 2:37 PM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> On 18/02/16 15:12, Russell King - ARM Linux wrote:
>> On Thu, Feb 18, 2016 at 01:52:32PM +0200, Tomi Valkeinen wrote:
>>> In my opinion the best option would be to use DT overlays, but so that
>>> the bootloader would supply them, or construct the dtb. But afaik that's
>>> not possible at the moment. And perhaps I think that's the best option
>>> only because I don't work with the bootloaders =).
>>>
>>> So, I don't like this, but I don't have a good suggestion how to do it
>>> better with the infrastructure in place at the moment.
>>
>> The danger of that position is that we end up with nothing happening,
>> and the problem remaining unresolved, which then pushes people into
>> maintaining patches out of mainline just to have a working setup -
>> which then pushes people to vendor trees.
>
> I agree.
>
> I didn't express my position clearly: I'm ok with the approach, if we
> don't come up with anything better.

I'm checking to see if I can use the overlay primitives directly from
the kernel.

It seems possible, basically to have a panel defined in the device tree
for VGA as default, and then augment it depending on what we detect.
Meaning I start to overwrite clock-frequency, pixelclk-active, hactive etc.
It basically means we go back to having a database in the kernel.

I would then even overwrite the .compatible string from the kernel.

It may be more elegant than this solution though?

> But if we go with this approach, it must be understood that it may cause
> problems later. It's not the most maintainable approach.
>
> I'd also like to have an ack from the DT maintainers, as I think this is
> somewhat of an abuse of the DT.

What I am doing in this patch is sort of a "Schr?dinger's cat approach",
I basically say that the cat is both dead and alive until we open the
box, i.e. all displays are connected until we figure out which one it
actually is.

Basically the approach taken could even handle the case of switching
a display at runtime. Though I don't think the hardware would like that.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Feb 18 12:48:43 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 18 Feb 2016 21:48:43 +0100
Subject: [PATCH 07/11] Documentation/DT: add Versatile display bindings
In-Reply-To: <56C43936.2060808@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-8-git-send-email-linus.walleij@linaro.org>
 <56C43936.2060808@ti.com>
Message-ID: <CACRpkdbGqbjEwHcspcRW0_889YO0RpVTef2mhVdP_9vJHMD8gQ@mail.gmail.com>

On Wed, Feb 17, 2016 at 10:11 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:

>> +Required properties:
>> +- compatible: should be "epson,l2f50113t00"
>> +
>> +This binding is compatible with the panel-dpi binding, which is specified
>> +in panel-dpi.txt in this directory.
>
> Do we really want to add new binding doc files for all panels, even if
> they just point to a more generic binding? We may end up with quite a
> lot of these, each only saying "look at the panel-dpi.txt".

That's sort of what I'm asking too. But there was some other
file doing exactly this :(

What do you say about just putting a list of compatible panels
directly into panel-dpi.txt?

Yours,
Linus Walleij


From davem at davemloft.net  Thu Feb 18 13:00:09 2016
From: davem at davemloft.net (David Miller)
Date: Thu, 18 Feb 2016 16:00:09 -0500 (EST)
Subject: [PATCH] USB: cdc_subset: only build when one driver is enabled
In-Reply-To: <1455747932-2844084-1-git-send-email-arnd@arndb.de>
References: <1455747932-2844084-1-git-send-email-arnd@arndb.de>
Message-ID: <20160218.160009.1485326686227753180.davem@davemloft.net>

From: Arnd Bergmann <arnd at arndb.de>
Date: Wed, 17 Feb 2016 23:25:11 +0100

> This avoids a harmless randconfig warning I get when USB_NET_CDC_SUBSET
> is enabled, but all of the more specific drivers are not:
> 
> drivers/net/usb/cdc_subset.c:241:2: #warning You need to configure some hardware for this driver
> 
> The current behavior is clearly intentional, giving a warning when
> a user picks a configuration that won't do anything good. The only
> reason for even addressing this is that I'm getting close to
> eliminating all 'randconfig' warnings on ARM, and this came up
> a couple of times.
> 
> My workaround is to not even build the module when none of the
> configurations are enable.
> 
> Alternatively we could simply remove the #warning (nothing wrong
> for compile-testing), turn it into a runtime warning, or
> change the Kconfig options into a menu to hide CONFIG_USB_NET_CDC_SUBSET.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Applied, thanks Arnd.


From carlo at caione.org  Thu Feb 18 13:04:41 2016
From: carlo at caione.org (Carlo Caione)
Date: Thu, 18 Feb 2016 22:04:41 +0100
Subject: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
In-Reply-To: <4136837.fyWFbJqZfO@wuerfel>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <4158343.mkrTsd5B4G@wuerfel>
 <CAOQ7t2byFoW657-1xnsBpeyPkB6K25R=_pPmRDmT32Sjef=kUw@mail.gmail.com>
 <4136837.fyWFbJqZfO@wuerfel>
Message-ID: <CAOQ7t2aqZj3STFsdTSQZMTK5U+8Oem8oFroxHKWkt=AeP+Zczg@mail.gmail.com>

On Thu, Feb 18, 2016 at 3:22 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 18 February 2016 15:14:45 Carlo Caione wrote:
>> >
>> > Yes, you should describe the device that is actually there, which would be
>> > something like
>> >
>> >         cbus at c1100000 {
>> >                 compatible = "amlogic,meson8b-cbus", "syscon";
>> >                 reg = <0xc1100000 0x10000>; /* no idea what the length is, fix it */
>> >         };
>> >
>> > Don't just make things up because you happen to access them in a particular
>> > way, but try to stay as close as you can to describing the actual hardware.
>>
>> Arnd,
>> in the cbus region are mapped a lot of different devices, do you think
>> that it is a good idea mapping the whole region as a single syscon
>> device?
>
> It really depends on what those other devices do with the registers:
>
> If each device just uses a couple of random registers from the cbus,
> they should probably all be changed to go through syscon.

In our case each device (pinmux, GPIO IRQ, clock controller, ...) uses
a consistent and contiguous set of registers inside cbus.
But in the same cbus sometimes we have also some registers that are
used for something different or peculiar like in this case. Usually
it's matter of one or two registers though, that's why I was a bit
curious about such a huge size 0x460.

> However, if some or all of the other devices actually are entirely
> made up of register ranges within cbus, that would indicate that
> cbus itself is not just a collection of random registers but something
> that could be considered a bus of itself in hardware, and then
> we could represent the other devices as children of this bus.

I think that this is exactly the case. We are missing this cbus in the
DTS because (for lacking of proper documentation) we are not sure
about start / end / size.

> Usually once you have a list of all the register locations, you can
> identify the hardware structure to a certain degree from that, even
> if you don't have access to a data sheet that would clarify this
> better.

Yes, in general for each single device the registers of interest are
contiguous inside cbus.

Thanks,

-- 
Carlo Caione


From laurent.pinchart at ideasonboard.com  Thu Feb 18 13:14:57 2016
From: laurent.pinchart at ideasonboard.com (Laurent Pinchart)
Date: Thu, 18 Feb 2016 23:14:57 +0200
Subject: [PATCH/RFC v2 01/11] PM / Domains: Add DT bindings for the R-Car
 System Controller
In-Reply-To: <CAMuHMdXqVL6_P6Lnea6z8jFtR2v4NFnzn=ibZVyauZ8-ODb6dg@mail.gmail.com>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
 <20160218143826.GB9654@rob-hp-laptop>
 <CAMuHMdXqVL6_P6Lnea6z8jFtR2v4NFnzn=ibZVyauZ8-ODb6dg@mail.gmail.com>
Message-ID: <15010857.2cVvcc6676@avalon>

Hi Geert,

On Thursday 18 February 2016 18:18:56 Geert Uytterhoeven wrote:
> On Thu, Feb 18, 2016 at 3:38 PM, Rob Herring <robh at kernel.org> wrote:
> > On Mon, Feb 15, 2016 at 10:16:50PM +0100, Geert Uytterhoeven wrote:
> >> The Renesas R-Car System Controller provides power management for the
> >> CPU cores and various coprocessors, following the generic PM domain
> >> bindings in Documentation/devicetree/bindings/power/power_domain.txt.
> >> 
> >> This supports R-Car Gen1, Gen2, and Gen3.
> >> 
> >> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> >> ---
> >> 
> >> Alternatives I considered:
> >>   - Using a single node per power register block, even if it contains
> >>     multiple domains, e.g.:
> >>           pd_ca15_scu: ca15_scu at 180 {
> >>                   reg = <0x180 0x20>;
> >>                   #address-cells = <1>;
> >>                   #size-cells = <0>;
> >>                   #power-domain-cells = <0>;
> >>                   renesas,interrupt-bits = <12>;
> >>                   
> >>                   pd_ca15_cpu: ca15_cpu at 40 {
> >>                           reg = <0x40 0x20>;
> >>                           #power-domain-cells = <1>;
> >>                           renesas,pm-domain-indices = <0 1>;
> >>                           renesas,pm-domain-names =
> >>                                   "ca15_cpu0", "ca15_cpu1";
> >>                           renesas,interrupt-bits = <0 1>;
> >>                   };
> >>           };
> >>     
> >>     Notes:
> >>       - You cannot just have a property with the number of domains, as
> >>       index 0 is not used on R-Car H1. Hence the need for
> >>       "renesas,pm-domain-indices" and "renesas,interrupt-bits",
> >>       - "#power-domain-cells = <1>" for nodes with multiple domains,
> >>       which allows typos in "power-domains = <&pd_ca15_cpu n>", using
> >>       an invalid value of "n".
> >>   
> >>   - Using a linear description in DT:
> >>       - Needs parent links for subdomains,
> >>       - More complicated to parse (lesson learned from R-Mobile PM
> >>       Domain support).
> >>   
> >>   - Keeping the power register block offset and the bit number as
> >>   separate
> >>     "reg" cells, increasing "#address-cells" from 2 to 3,
> >>   
> >>   - Merging the interrupt bit (which needs only 5 bits) in the other
> >>   "reg"
> >>     cell, decreasing "#address-cells" from 2 to 1.
> > 
> > I think I'd move to not encoding mulitple things into reg. This seems
> > like a bit of abuse of reg. Otherwise, I don't have much to comment on.
> 
> Thanks!
> 
> (quoting the encoding of the reg properties)
> 
> > +== PM Domain Nodes ==
> > +
> > +Each of the PM domain nodes represents a PM domain, as documented by the
> > +generic PM domain bindings in
> > +Documentation/devicetree/bindings/power/power_domain.txt.
> > +
> > +Required properties:
> > +  - #power-domain-cells: Must be 0.
> > +  - reg: This property must contain 2 values:
> > +          - The first value is the number of the interrupt bit
> > representing
> > +            the power area in the various Interrupt Registers (e.g.
> > SYSCISR,
> > +            Interrupt Status Register),
> > +          - The second value encodes the power register block offset
> > (which is
> > +            a multiple of 64), and the number of the bit representing the
> > +            power area in the various Power Control Registers (e.g.
> > PWROFFSR,
> > +            Power Shutoff Status Register). This value is created by
> > ORing
> > +            these two numbers.
> 
> Not encoding multiple things into reg means adding more properties to
> provide that information, iff we want to describe the PM Domain Nodes in
> DT. I considered the reg property a two-dimensional address space.
> 
> Taking the lessons from CCF and the new CPG/MSSR bindings into account
> (which was BTW designed after the SYSC DT bindings), perhaps the PM Domain
> hierarchy should be moved from DT to C, in the driver, too?
> 
> That would mean we have in DT:
>   1) "#power-domain-cells = <1>"
>   2) defines for the various domains, e.g. "#define R8A7791_PD_CA15_SCU     
> 12"
>   3) e.g. "power-domains = <&sysc R8A7791_PD_CA15_SCU>"
>   4) and we can get rid of the fallback compatibility strings again.
> 
> Thoughts?

That simplifies DT and will give more flexibility to handle all the weird 
details in C code, so I like it.

Additionally the amount of per-SoC data related to power domains is pretty 
limited, so we shouldn't have a size issue, even for multi-platform kernels. 
The removal of DT parsing code might even make the kernel smaller. The only 
driver I'm concerned about when it comes to per-SoC data size is the PFC 
driver.

-- 
Regards,

Laurent Pinchart



From jeremy.linton at arm.com  Thu Feb 18 13:15:44 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Thu, 18 Feb 2016 15:15:44 -0600
Subject: [PATCH v3 0/5] ACPI: parse the SPCR table
In-Reply-To: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <56C63480.5020605@arm.com>

On 02/15/2016 12:05 PM, Aleksey Makarov wrote:
> This patchset is based on the patchset by Leif Lindholm [1]
>
> 'ARM Server Base Boot Requirements' [2] mentions SPCR (Serial Port
> Console Redirection Table) [3] as a mandatory ACPI table that
> specifies the configuration of serial console.
>
> SPCR support is included in QEMU's ARM mach-virt since 2.4 release.
>
> Introduce a new function acpi_console_check().  At the uart port
> registration, this function checks if the ACPI SPCR table specifies
> its argument of type struct uart_port to be a console
> and if so calls add_preferred_console().
>
> Use SPCR to tell if SBSA serial driver should use 32-bit access to registers.
>
> To be able to access SPCR table each time any console is registered
> change __init to __ref for early_acpi_os_unmap_memory().
>
> The patchset should be applied to tty-next.
(trimming)

This works on the JunoR2 with a new enough firmware to have the SPCR table.

Tested-by: Jeremy Linton <jeremy.linton at arm.com>



From carlo at endlessm.com  Thu Feb 18 13:24:24 2016
From: carlo at endlessm.com (Carlo Caione)
Date: Thu, 18 Feb 2016 22:24:24 +0100
Subject: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
In-Reply-To: <CAOQ7t2aqZj3STFsdTSQZMTK5U+8Oem8oFroxHKWkt=AeP+Zczg@mail.gmail.com>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <4158343.mkrTsd5B4G@wuerfel>
 <CAOQ7t2byFoW657-1xnsBpeyPkB6K25R=_pPmRDmT32Sjef=kUw@mail.gmail.com>
 <4136837.fyWFbJqZfO@wuerfel>
 <CAOQ7t2aqZj3STFsdTSQZMTK5U+8Oem8oFroxHKWkt=AeP+Zczg@mail.gmail.com>
Message-ID: <CAL9uMOGy=sP+gg8v=9N5zhrWGNA2Aq7N34JYgUON-+GH4b1d0w@mail.gmail.com>

On Thu, Feb 18, 2016 at 10:04 PM, Carlo Caione <carlo at caione.org> wrote:
> On Thu, Feb 18, 2016 at 3:22 PM, Arnd Bergmann <arnd at arndb.de> wrote:

>> However, if some or all of the other devices actually are entirely
>> made up of register ranges within cbus, that would indicate that
>> cbus itself is not just a collection of random registers but something
>> that could be considered a bus of itself in hardware, and then
>> we could represent the other devices as children of this bus.
>
> I think that this is exactly the case. We are missing this cbus in the
> DTS because (for lacking of proper documentation) we are not sure
> about start / end / size.

This is not entirely correct actually.
CBUS starts at 0xc1100000 with a size of 0x00100000 according to the Amlogic SDK

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless


From drake at endlessm.com  Thu Feb 18 13:27:06 2016
From: drake at endlessm.com (Daniel Drake)
Date: Thu, 18 Feb 2016 15:27:06 -0600
Subject: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
In-Reply-To: <CAOQ7t2aqZj3STFsdTSQZMTK5U+8Oem8oFroxHKWkt=AeP+Zczg@mail.gmail.com>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <4158343.mkrTsd5B4G@wuerfel>
 <CAOQ7t2byFoW657-1xnsBpeyPkB6K25R=_pPmRDmT32Sjef=kUw@mail.gmail.com>
 <4136837.fyWFbJqZfO@wuerfel>
 <CAOQ7t2aqZj3STFsdTSQZMTK5U+8Oem8oFroxHKWkt=AeP+Zczg@mail.gmail.com>
Message-ID: <CAD8Lp47LGUc3-MFpU+3iNjXJL0i4nLTY_49NUxFXeZ2SokDuaQ@mail.gmail.com>

On Thu, Feb 18, 2016 at 3:04 PM, Carlo Caione <carlo at caione.org> wrote:
>> However, if some or all of the other devices actually are entirely
>> made up of register ranges within cbus, that would indicate that
>> cbus itself is not just a collection of random registers but something
>> that could be considered a bus of itself in hardware, and then
>> we could represent the other devices as children of this bus.
>
> I think that this is exactly the case. We are missing this cbus in the
> DTS because (for lacking of proper documentation) we are not sure
> about start / end / size.

Here's a hint from the vendor kernel
https://github.com/endlessm/linux-meson/blob/master/arch/arm/mach-meson8b/iomapping.c#L87

Having a cbus bus node with child devices does sound like it would
reflect this particular view of the hardware design. How would we then
represent the hwrev registers under that?

I am also curious if this is the common practice. We were working with
Exynos devices before, and even though many of the components are on
the AXI bus there, there is no AXI bus representation in the DT. But
now that I go digging, I see other SoCs that do have a DT bus
representation very similar to what's being described, such as the apb
and axi busses in mmp2.dtsi. Is one approach preferred over the other
for new SoC support?

Daniel


From slemieux.tyco at gmail.com  Thu Feb 18 13:35:22 2016
From: slemieux.tyco at gmail.com (slemieux.tyco at gmail.com)
Date: Thu, 18 Feb 2016 16:35:22 -0500
Subject: [PATCH 0/2] arm: lpc32xx: restart: add support for soft reset
Message-ID: <1455831324-8909-1-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

The LPC32xx provide the capability to perform a soft or hard reset;
a soft reset will no reset the external peripheral
(i.e. RESOUT_N output not asserted).

The default behavior (i.e. hard reset) remain unchanged.

Sylvain Lemieux (2):
  arm: lpc32xx: restart: add support for soft reset
  arm: lpc32xx: restart: support "cmd" from userspace

 arch/arm/mach-lpc32xx/common.c | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

-- 
1.8.3.1



From slemieux.tyco at gmail.com  Thu Feb 18 13:35:23 2016
From: slemieux.tyco at gmail.com (slemieux.tyco at gmail.com)
Date: Thu, 18 Feb 2016 16:35:23 -0500
Subject: [PATCH 1/2] arm: lpc32xx: restart: add support for soft reset
In-Reply-To: <1455831324-8909-1-git-send-email-slemieux.tyco@gmail.com>
References: <1455831324-8909-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1455831324-8909-2-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Add support for explicit soft reset using the reboot mode.

The default reboot mode behavior is unchanged;
you can specified the default reboot type in the board specific file
"DT_MACHINE_START" definition using the "reboot_mode" parameter.

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
 arch/arm/mach-lpc32xx/common.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-lpc32xx/common.c b/arch/arm/mach-lpc32xx/common.c
index 716e83e..9eb9f22 100644
--- a/arch/arm/mach-lpc32xx/common.c
+++ b/arch/arm/mach-lpc32xx/common.c
@@ -200,9 +200,16 @@ void lpc23xx_restart(enum reboot_mode mode, const char *cmd)
 	__raw_writel(LPC32XX_CLKPWR_PWMCLK_WDOG_EN,
 		LPC32XX_CLKPWR_TIMER_CLK_CTRL);
 
-	/* Instant assert of RESETOUT_N with pulse length 1mS */
-	__raw_writel(13000, io_p2v(LPC32XX_WDTIM_BASE + 0x18));
-	__raw_writel(0x70, io_p2v(LPC32XX_WDTIM_BASE + 0xC));
+	if (mode == REBOOT_SOFT) {
+		/* Force match output active */
+		__raw_writel(0x01, io_p2v(LPC32XX_WDTIM_BASE + 0x14));
+		/* Enable internal reset on match output (RESOUT_N not asserted) */
+		__raw_writel(0x08, io_p2v(LPC32XX_WDTIM_BASE + 0xC));
+	} else {
+		/* Instant assert of RESETOUT_N with pulse length 1mS */
+		__raw_writel(13000, io_p2v(LPC32XX_WDTIM_BASE + 0x18));
+		__raw_writel(0x70, io_p2v(LPC32XX_WDTIM_BASE + 0xC));
+	}
 
 	/* Wait for watchdog to reset system */
 	while (1)
-- 
1.8.3.1



From slemieux.tyco at gmail.com  Thu Feb 18 13:35:24 2016
From: slemieux.tyco at gmail.com (slemieux.tyco at gmail.com)
Date: Thu, 18 Feb 2016 16:35:24 -0500
Subject: [PATCH 2/2] arm: lpc32xx: restart: support "cmd" from userspace
In-Reply-To: <1455831324-8909-1-git-send-email-slemieux.tyco@gmail.com>
References: <1455831324-8909-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1455831324-8909-3-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Add the support to verify if a "cmd" is passed from the userspace program rebooting the system;
- if a valid "cmd" is available, it will be handle;
- If the received "cmd" is not supported, the default reboot mode is used.

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
 arch/arm/mach-lpc32xx/common.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/mach-lpc32xx/common.c b/arch/arm/mach-lpc32xx/common.c
index 9eb9f22..ba61839 100644
--- a/arch/arm/mach-lpc32xx/common.c
+++ b/arch/arm/mach-lpc32xx/common.c
@@ -196,6 +196,19 @@ void __init lpc32xx_map_io(void)
 
 void lpc23xx_restart(enum reboot_mode mode, const char *cmd)
 {
+	/*
+	 * Verify if a "cmd" passed from the userspace program rebooting
+	 * the system; if available, and handle it.
+	 * - For details, see the 'reboot' syscall in kernel/reboot.c
+	 * - If the received "cmd" is not supported, use the default mode.
+	 */
+	if (cmd) {
+		if (cmd[0] == 'h')
+			mode = REBOOT_HARD;
+		else if (cmd[0] == 's')
+			mode = REBOOT_SOFT;
+	}
+
 	/* Make sure WDT clocks are enabled */
 	__raw_writel(LPC32XX_CLKPWR_PWMCLK_WDOG_EN,
 		LPC32XX_CLKPWR_TIMER_CLK_CTRL);
-- 
1.8.3.1



From peter at hurleysoftware.com  Thu Feb 18 14:03:33 2016
From: peter at hurleysoftware.com (Peter Hurley)
Date: Thu, 18 Feb 2016 14:03:33 -0800
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
 <56C470C5.2080203@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>
Message-ID: <56C63FB5.2030907@hurleysoftware.com>

On 02/17/2016 07:36 PM, Zheng, Lv wrote:
> Hi,
> 
>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>> early_acpi_os_unmap_memory()
>>
>> Hi Lv,
>>
>> Thank you for review.
>>
>> On 02/17/2016 05:51 AM, Zheng, Lv wrote:
>>
>> [..]
>>
>>>>> early_acpi_os_unmap_memory() is marked as __init because it calls
>>>>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is not
>> set.
>>>>>
>>>>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>> so it is safe to call early_acpi_os_unmap_memory() from anywhere
>>>>>
>>>>> We need this function to be non-__init because we need access to
>>>>> some tables at unpredictable time--it may be before or after
>>>>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port Console
>>>>> Redirection) table is needed each time a new console is registered.
>>>>> It can be quite early (console_initcall) or when a module is inserted.
>>>>> When this table accessed before acpi_gbl_permanent_mmap is set,
>>>>> the pointer should be unmapped.  This is exactly what this function
>>>>> does.
>>>> [Lv Zheng]
>>>> Why don't you use another API instead of early_acpi_os_unmap_memory()
>> in
>>>> case you want to unmap things in any cases.
>>>> acpi_os_unmap_memory() should be the one to match this purpose.
>>>> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
>>
>> As far as I understand, there exist two steps in ACPI initialization:
>>
>> 1. Before acpi_gbl_permanent_mmap is set, tables received with
>> acpi_get_table_with_size()
>>    are mapped by early_memremap().  If a subsystem gets such a pointer it
>> should be unmapped.
>>
>> 2  After acpi_gbl_permanent_mmap is set this pointer should not be unmapped
>> at all.
>>
> [Lv Zheng] 
> This statement is wrong, this should be:
> As long as there is a __reference__ to the mapped table, the pointer should not be unmapped.
> In fact, we have a series to introduce acpi_put_table() to achieve this.
> So your argument is wrong from very first point.
> 
>> That exactly what early_acpi_os_unmap_memory() does--it checks
>> acpi_gbl_permanent_mmap.
>> If I had used acpi_os_unmap_memory() after acpi_gbl_permanent_mmap had
>> been set,
>> it would have tried to free that pointer with an oops (actually, I checked that
>> and got that oops).
>>
>> So using acpi_os_unmap_memory() is not an option here, but
>> early_acpi_os_unmap_memory()
>> match perfectly.
> [Lv Zheng] 
> I don't think so.
> For definition block tables, we know for sure there will always be references, until "Unload" opcode is invoked by the AML interpreter.
> But for the data tables, OSPMs should use them in this way:
> 1. map the table
> 2. parse the table and convert it to OS specific structures
> 3. unmap the table
> This helps to shrink virtual memory address space usages.
> 
> So from this point of view, all data tables should be unmapped right after being parsed.
> Why do you need the map to be persistent in the kernel address space?
> You can always map a small table, but what if the table size is very big?
> 
>>
>>>> And in fact early_acpi_os_unmap_memory() should be removed.
>>
>> I don't think so -- I have explained why.  It does different thing.
>> Probably it (and/or other functions in that api) should be renamed.
>>
> [Lv Zheng] 
> Just let me ask one more question.
> eary_acpi_os_unmap_memory() is not used inside of ACPICA.
> How ACPICA can work with just acpi_os_unmap_memory()?
> You can check drivers/acpi/tbxxx.c.
> Especially: acpi_tb_release_temp_table() and the code invoking it.
> 
>>> [Lv Zheng]
>>> One more thing is:
>>> If you can't switch your driver to use acpi_os_unmap_memory() instead of
>> early_acpi_os_unmap_memory(),
>>> then it implies that your driver does have a defect.
>>
>> I still don't understand what defect, sorry.
> [Lv Zheng] 
> If you can't ensure this sequence for using the data tables:
> 1. map the table
> 2. parse the table and convert it to OS specific structure
> 3. unmap the table
> It implies there is a bug in the driver or a bug in the ACPI subsystem core.

Exactly.

The central problem here is the way Aleksey is trying to hookup a console.

What should be happening in this series is:
1. early map SPCR
2. parse the SPCR table
3. call add_preferred_console() to add the SPCR console to the console table
4. unmap SPCR

This trivial and unobtrusive method would already have a 8250 console
running via SPCR. I've already pointed this out in previous reviews.

Further, the above method *will be required anyway* for the DBG2 table to
start an earlycon, which I've already pointed out in previous reviews.

Then to enable amba-pl011 console via ACPI, add a console match() method
similar to the 8250 console match() method, univ8250_console_match().

FWIW, PCI earlycon + console support was already submitted once before but
never picked up by GregKH. I think I'll just grab that and re-submit so
you would know what to emit for console options in the add_preferred_console().


Regards,
Peter Hurley


>>> There is an early bootup requirement in Linux.
>>> Maps acquired during the early stage should be freed by the driver during the
>> early stage.
>>> And the driver should re-acquire the memory map after booting.
>>
>> Exactly.  That's why I use early_acpi_os_unmap_memory().  The point is that
>> that code can be
>> called *before* acpi_gbl_permanent_mmap is set (at early initialization of for
>> example 8250 console)
>> or *after* acpi_gbl_permanent_mmap is set (at insertion of a module that
>> registers a console),
>> We just can not tell if the received table pointer should or sould not be freed
>> with early_memunmap()
>> (actually __acpi_unmap_table() or whatever) without checking
>> acpi_gbl_permanent_mmap,
>> but that's all too low level.
> [Lv Zheng] 
> The driver should make sure that:
> Map/unmap is paired during early stage.
> For late stage, it should be another pair of map/unmap.
> 
>>
>> Another option, as you describe, is to get this pointer early, don't free it
> [Lv Zheng] 
> I mean you should free it early.
> 
>> untill acpi_gbl_permanent_mmap is set, then free it (with
>> early_acpi_os_unmap_memory(), that's
>> ok because acpi_gbl_permanent_mmap is set in an init code), then get the
>> persistent
>> pointer to the table.  The problem with it is that we can not just watch
>> acpi_gbl_permanent_mmap
>> to catch this exact moment.  And also accessing acpi_gbl_permanent_mmap is
>> not good as it probably is
>> an implementation detail (i. e. too lowlevel) of the ACPI code.
>> Or I probably miss what you are suggesting.
>>
> [Lv Zheng] 
> I mean, you should:
> During early stage:
> acpi_os_map_memory()
> Parse the table.
> acpi_os_unmap_memory().
> 
>>> This is because, during early bootup stage, there are only limited slots
>> available for drivers to map memory.
>>> So by changing __init to __ref here, you probably will hide many such defects.
>>
>> What defects?  This funcions checks acpi_gbl_permanent_mmap.
>> BTW, exactly the same thing is done in the beginning of
>> acpi_os_unmap_memory() and than's ok,
>> that function is __ref.
>>
>>> And solving issues in this way doesn't seem to be an improvement.
>>
>> Could you please tell me where I am wrong?  I still don't understand your point.
> [Lv Zheng] 
> But anyway, the defect should be in ACPI subsystem core.
> The cause should be the API itself - acpi_get_table().
> 
> So I agree you can use early_acpi_os_unmap_memory() during the period the root causes are not cleaned up.
> But the bottom line is: the driver need to ensure that early_acpi_os_unmap_memory() is always invoked.
> As long as you can ensure this, I don't have objections for deploying early_acpi_os_unmap_memory()  for now.
> 
> Thanks and best regards
> -Lv
> 
>>
>> Thank you
>> Aleksey Makarov
>>
>>>
>>> Thanks and best regards
>>> -Lv
>>>
>>>>
>>>> Thanks and best regards
>>>> -Lv
>>>>
>>>>>
>>>>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
>>>>> ---
>>>>>  drivers/acpi/osl.c | 6 +++++-
>>>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
>>>>> index 67da6fb..8a552cd 100644
>>>>> --- a/drivers/acpi/osl.c
>>>>> +++ b/drivers/acpi/osl.c
>>>>> @@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void *virt,
>>>>> acpi_size size)
>>>>>  }
>>>>>  EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
>>>>>
>>>>> -void __init early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
>>>> size)
>>>>> +/*
>>>>> + * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>> + * so it is safe to call early_acpi_os_unmap_memory() from anywhere
>>>>> + */
>>>>> +void __ref early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
>>>> size)
>>>>>  {
>>>>>  	if (!acpi_gbl_permanent_mmap)
>>>>>  		__acpi_unmap_table(virt, size);
>>>>> --
>>>>> 2.7.1
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>>>>> the body of a message to majordomo at vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From manabian at gmail.com  Thu Feb 18 14:07:35 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Thu, 18 Feb 2016 23:07:35 +0100
Subject: [PATCH 0/2] arm: lpc32xx: restart: add support for soft reset
In-Reply-To: <1455831324-8909-1-git-send-email-slemieux.tyco@gmail.com>
References: <1455831324-8909-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <CAGhQ9VwPc0RA0n8JmpcqJuV6SmdFZbBjgVCz5iExBA+z74LH_g@mail.gmail.com>

Hi Sylvain,

On 18 February 2016 at 22:35,  <slemieux.tyco at gmail.com> wrote:
> From: Sylvain Lemieux <slemieux at tycoint.com>
>
> The LPC32xx provide the capability to perform a soft or hard reset;
> a soft reset will no reset the external peripheral
> (i.e. RESOUT_N output not asserted).
>
> The default behavior (i.e. hard reset) remain unchanged.
>
> Sylvain Lemieux (2):
>   arm: lpc32xx: restart: add support for soft reset
>   arm: lpc32xx: restart: support "cmd" from userspace
>
>  arch/arm/mach-lpc32xx/common.c | 26 +++++++++++++++++++++++---
>  1 file changed, 23 insertions(+), 3 deletions(-)

Instead of adding more code to mach-lpc32xx could this code be moved
to the watchdog driver (pnx4008_wdt.c) ?
See register_restart_handler() and how it's used in other watchdog drivers.

Then maybe the restart hook in phy3250.c could be removed all together.


regards,
Joachim Eastwood


From peter at hurleysoftware.com  Thu Feb 18 14:19:18 2016
From: peter at hurleysoftware.com (Peter Hurley)
Date: Thu, 18 Feb 2016 14:19:18 -0800
Subject: [PATCH v3 2/5] ACPI: parse SPCR and enable matching console
In-Reply-To: <1455559532-8305-3-git-send-email-aleksey.makarov@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-3-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <56C64366.2070702@hurleysoftware.com>

On 02/15/2016 10:05 AM, Aleksey Makarov wrote:
> 'ARM Server Base Boot Requiremets' [1] mentions SPCR (Serial Port
> Console Redirection Table) [2] as a mandatory ACPI table that
> specifies the configuration of serial console.
> 
> Parse this table and check if any registered console match the
> description.  If it does, enable that console.
> 
> Introduce a new function acpi_console_check().  At the uart port
> registration, this function checks if the ACPI SPCR table specifies
> its argument of type struct uart_port to be a console
> and if so calls add_preferred_console().
> 
> [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
> [2] http://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
> 
> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> ---
>  drivers/acpi/Kconfig             |  3 ++
>  drivers/acpi/Makefile            |  1 +
>  drivers/acpi/spcr.c              | 97 ++++++++++++++++++++++++++++++++++++++++
>  drivers/tty/serial/serial_core.c | 14 +++++-
>  include/linux/acpi.h             | 10 +++++
>  5 files changed, 123 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/acpi/spcr.c
> 
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 65fb483..5611eb6 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -77,6 +77,9 @@ config ACPI_DEBUGGER_USER
>  
>  endif
>  
> +config ACPI_SPCR_TABLE
> +	bool
> +
>  config ACPI_SLEEP
>  	bool
>  	depends on SUSPEND || HIBERNATION
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 346101c..708b143 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -81,6 +81,7 @@ obj-$(CONFIG_ACPI_EC_DEBUGFS)	+= ec_sys.o
>  obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
>  obj-$(CONFIG_ACPI_BGRT)		+= bgrt.o
>  obj-$(CONFIG_ACPI_CPPC_LIB)	+= cppc_acpi.o
> +obj-$(CONFIG_ACPI_SPCR_TABLE)	+= spcr.o
>  obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
>  
>  # processor has its own "processor." module_param namespace
> diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
> new file mode 100644
> index 0000000..a1eca91
> --- /dev/null
> +++ b/drivers/acpi/spcr.c
> @@ -0,0 +1,97 @@
> +/*
> + * Copyright (c) 2012, Intel Corporation
> + * Copyright (c) 2015, Red Hat, Inc.
> + * Copyright (c) 2015, 2016 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#define pr_fmt(fmt) "ACPI: SPCR: " fmt
> +
> +#include <linux/acpi.h>
> +#include <linux/console.h>
> +#include <linux/kernel.h>
> +#include <linux/serial_core.h>
> +
> +static int acpi_table_parse_spcr(int (*handler)(struct acpi_table_spcr *table,
> +						void *data), void *data)
> +{
> +	struct acpi_table_spcr *table = NULL;
> +	acpi_size table_size;
> +	acpi_status status;
> +	int err;
> +
> +	status = acpi_get_table_with_size(ACPI_SIG_SPCR, 0,
> +					  (struct acpi_table_header **)&table,
> +					  &table_size);
> +
> +	if (ACPI_FAILURE(status))
> +		return -ENODEV;
> +
> +	err = handler(table, data);
> +
> +	early_acpi_os_unmap_memory(table, table_size);
> +
> +	return err;
> +}
> +
> +static int spcr_table_handler_check(struct acpi_table_spcr *table, void *data)
> +{
> +	struct uart_port *uport = data;
> +	char *options;
> +
> +	if (table->header.revision < 2)
> +		return -EOPNOTSUPP;
> +
> +	switch (table->baud_rate) {
> +	case 3:
> +		options = "9600";
> +		break;
> +	case 4:
> +		options = "19200";
> +		break;
> +	case 6:
> +		options = "57600";
> +		break;
> +	case 7:
> +		options = "115200";
> +		break;
> +	default:
> +		options = "";
> +		break;
> +	}
> +
> +	if ((table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY &&
> +	     table->serial_port.address == (u64)uport->mapbase) ||
> +	    (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_IO &&
> +	     table->serial_port.address == (u64)uport->iobase)) {
> +		pr_info("adding preferred console [%s%d]\n", uport->cons->name,
> +			uport->line);
> +		add_preferred_console(uport->cons->name, uport->line, options);
> +		return 1;
> +
> +	}
> +
> +	return 0;
> +}
> +
> +/**
> + * acpi_console_check - Check if uart matches the console specified by SPCR.
> + *
> + * @uport:	uart port to check
> + *
> + * This function checks if the ACPI SPCR table specifies @uport to be a console
> + * and if so calls add_preferred_console()
> + *
> + * Return: a non-error value if the console matches.
> + */
> +bool acpi_console_check(struct uart_port *uport)
> +{
> +	if (acpi_disabled || console_set_on_cmdline)
> +		return false;
> +
> +	return acpi_table_parse_spcr(spcr_table_handler_check, uport) > 0;
> +}
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index a126a60..459ab54 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -34,6 +34,7 @@
>  #include <linux/serial_core.h>
>  #include <linux/delay.h>
>  #include <linux/mutex.h>
> +#include <linux/acpi.h>
>  
>  #include <asm/irq.h>
>  #include <asm/uaccess.h>
> @@ -2654,8 +2655,17 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
>  		spin_lock_init(&uport->lock);
>  		lockdep_set_class(&uport->lock, &port_lock_key);
>  	}
> -	if (uport->cons && uport->dev)
> -		of_console_check(uport->dev->of_node, uport->cons->name, uport->line);
> +
> +	/*
> +	 * Support both open FW and ACPI access to console definitions.
> +	 * Both of_console_check() and acpi_console_check() will call
> +	 * add_preferred_console() if a console definition is found.
> +	 */
> +	if (uport->cons && uport->dev) {
> +		if (!acpi_console_check(uport))
> +			of_console_check(uport->dev->of_node, uport->cons->name,
> +					 uport->line);

of_console_check() is not a good model for enabling a console.
It's a hack with several shortcomings (and bugs) that is tolerated here
because of its broad applicability to a wide range of platforms and drivers.

I specifically added console matching to enable exactly this kind of
console-selection-via-firmware. Please use that facility.

Regards,
Peter Hurley


> +	}
>  
>  	uart_configure_port(drv, state, uport);
>  
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 06ed7e5..ea0c297 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -1004,4 +1004,14 @@ static inline struct fwnode_handle *acpi_get_next_subnode(struct device *dev,
>  #define acpi_probe_device_table(t)	({ int __r = 0; __r;})
>  #endif
>  
> +struct uart_port;
> +#ifdef CONFIG_ACPI_SPCR_TABLE
> +bool acpi_console_check(struct uart_port *uport);
> +#else
> +static inline bool acpi_console_check(struct uart_port *uport)
> +{
> +	return FALSE;
> +}
> +#endif
> +
>  #endif	/*_LINUX_ACPI_H*/
> 



From linux at arm.linux.org.uk  Thu Feb 18 14:33:12 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Feb 2016 22:33:12 +0000
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <HK2PR06MB0561C0EEA846C516645239338AAF0@HK2PR06MB0561.apcprd06.prod.outlook.com>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
 <alpine.LFD.2.20.1602181244490.13632@knanqh.ubzr>
 <HK2PR06MB0561377EABB3B4B8E94F22328AAF0@HK2PR06MB0561.apcprd06.prod.outlook.com>
 <alpine.LFD.2.20.1602181327060.13632@knanqh.ubzr>
 <HK2PR06MB0561C0EEA846C516645239338AAF0@HK2PR06MB0561.apcprd06.prod.outlook.com>
Message-ID: <20160218223312.GT19428@n2100.arm.linux.org.uk>

On Thu, Feb 18, 2016 at 07:42:20PM +0000, Chris Brandt wrote:
> On Thu, 18 Feb 2016, Nicolas Pitre wrote:
> 
> > > Is there some way you can do a PLATFORM_COUNTER++ for each device that 
> > > is selected, and then XIP_KERNEL would depend on PLATFORM_COUNTER == 1 
> > > ?
> >
> > I don't know all the Kconfig possibilities.
> >
> > But would something like this work?
> >
> > config FOO
> >	depends on !(XIP && CHOICE_MADE)
> >	select CHOICE_MADE
> 
> I follow your logic and that might work: If you made multiple choices, it would just take the first one.
> 
> However...I just tried it and it crashes.
> 
> scripts/kconfig/mconf  Kconfig
> make[2]: *** [menuconfig] Segmentation fault (core dumped)
> make[1]: *** [menuconfig] Error 2
> 
> 
> It looks like you can't depend on something not being set that you are going to set yourself. Basically..."do as I say, not as I do"

It's missing a bool/tristate.  Every config option needs to be typed.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From ynorov at caviumnetworks.com  Thu Feb 18 14:35:06 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Fri, 19 Feb 2016 01:35:06 +0300
Subject: [RFC5 PATCH v6 00/21] ILP32 for ARM64
In-Reply-To: <56AC38F1.2030608@huawei.com>
References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com>
 <56AB3805.1040308@huawei.com> <20160129170929.GA3543@yury-N73SV>
 <56AC38F1.2030608@huawei.com>
Message-ID: <20160218223506.GA7816@yury-N73SV>

On Sat, Jan 30, 2016 at 12:15:45PM +0800, Zhangjian (Bamvor) wrote:
> Hi, Yury
> 
> On 1:09 2016/1/30, Yury Norov wrote:
> >On Fri, Jan 29, 2016 at 05:59:33PM +0800, Zhangjian (Bamvor) wrote:
> >>Hi,
> >>
> >>On 1:22 2016/1/15, Yury Norov wrote:
> >>>This is still RFC because we have no glibc yet, that correspnds new ABI
> >>>introduced here. And so we cannot run tests. LP64 and AARCH32 tests show
> >>>no regression though.
> >>Hi,
> >>
> >>Glad to see this version. I hope I could test it. Where could I find the
> >>corresponding glibc? I could not find it in
> >>http://github.com/norov/glibc.git. Or is there a plan to do it?
> >>
> >>Besides compat wrappers discussed in these series, is there any other
> >>blockers for upstream? I would suppose everyone is intestested in the
> >>result of LTP...
> >>
> >>Regards
> >>
> >>Bamvor
> >>
> >
> >Hi, Bamvor,
> >
> >Just to order all commits, I created new ILP32 branch at [1], that
> >based on 4.4 kernel + [2] + [3]. There's no new glibc suitable for
> >rfc5. But I started with it, and I hope there will be progress soon.
> Cool:)
> >
> >You cannot run LTP as there are some syscalls that are called during
> >dynamic loading that fail, but you can try to build your test statically
> >agaginst current glibc, and there's a big chance it will work.
> >I have a set of 'hello-worlds' working that way.
> Currrently, I got 300+ in ltplite with you glibc[1]. I will try static link
> later.
> >
> >If you have some specific test that you cannot run, you can send it to
> >me, and I will take a look on it.
> Sure, I am reading the test results. Hope we could fix these failure
> together.
> 
> Regards
> 
> Bamvor
> 
> [1] https://github.com/norov/glibc/tree/thunderx-ilp32-32time_toff_t
> >
> >Yury
> >
> >[1] https://github.com/norov/linux/tree/rfc5
> >[2] http://permalink.gmane.org/gmane.linux.kernel/2116021
> >[3] http://comments.gmane.org/gmane.linux.kernel/2134747
> >
> >>>
> >>>  v3: https://lkml.org/lkml/2014/9/3/704
> >>>  v4: https://lkml.org/lkml/2015/4/13/691
> >>>  v5: https://lkml.org/lkml/2015/9/29/911
> >>>

Hi Bamvor, everybody,

I have new glibc that follows new ABI:
https://github.com/norov/glibc/tree/new-api

It's very draft and dirty, but you can try it with RFC5.
My fail list for ltplite looks like this:
pipeio_4                       FAIL       11   
abort01                        FAIL       2    
clone02                        FAIL       4    
kill10                         FAIL       2    
kill11                         FAIL       2    
lstat01A                       FAIL       1    
lstat02                        FAIL       1    
mmap16                         FAIL       6    
nanosleep03                    FAIL       1    
nftw01                         FAIL       1    
nftw6401                       FAIL       1    
open12                         FAIL       2    
pathconf01                     FAIL       1    
pipe07                         FAIL       2    
profil01                       FAIL       11   
readdir01                      FAIL       1    
readlink01A                    FAIL       1    
rename11                       FAIL       2    
rmdir02                        FAIL       2    
sigaltstack01                  FAIL       1    
sigaltstack02                  FAIL       1    
stat03                         FAIL       1    
stat04                         FAIL       1    
stat06                         FAIL       1    
umount2_01                     FAIL       2    
umount2_02                     FAIL       2    
umount2_03                     FAIL       2    
utime06                        FAIL       2    
writev01                       FAIL       1    
mtest06                        FAIL       11   
rwtest01                       FAIL       2    
rwtest02                       FAIL       2    
rwtest03                       FAIL       2    
rwtest04                       FAIL       2    
rwtest05                       FAIL       2

Float tests are exluded, but also fail. Totally, ~40 of 787 tests
fail.

Yury


From lina.iyer at linaro.org  Thu Feb 18 14:51:46 2016
From: lina.iyer at linaro.org (Lina Iyer)
Date: Thu, 18 Feb 2016 15:51:46 -0700
Subject: [BUG FIX] PM / cpu_domains: Check for NULL callbacks
In-Reply-To: <CAJZ5v0gXd573OM_xQBsqqaZoRWvT_px64Cx2avR5dCxCwmMWjA@mail.gmail.com>
References: <1455310238-8963-4-git-send-email-lina.iyer@linaro.org>
 <1455816573-43849-1-git-send-email-lina.iyer@linaro.org>
 <CAJZ5v0gXd573OM_xQBsqqaZoRWvT_px64Cx2avR5dCxCwmMWjA@mail.gmail.com>
Message-ID: <20160218225146.GB1313@linaro.org>

On Thu, Feb 18 2016 at 10:46 -0700, Rafael J. Wysocki wrote:
>On Thu, Feb 18, 2016 at 6:29 PM, Lina Iyer <lina.iyer at linaro.org> wrote:
>> Check for NULL platform callback before calling.
>>
>> Signed-off-by: Lina Iyer <lina.iyer at linaro.org>
>> ---
>>  drivers/base/power/cpu_domains.c | 10 ++++++++--
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/base/power/cpu_domains.c b/drivers/base/power/cpu_domains.c
>> index 7069411..bcaa474 100644
>> --- a/drivers/base/power/cpu_domains.c
>> +++ b/drivers/base/power/cpu_domains.c
>> @@ -157,16 +157,22 @@ static int cpu_pd_power_on(struct generic_pm_domain *genpd)
>>  {
>>         struct cpu_pm_domain *pd = to_cpu_pd(genpd);
>>
>> -       return pd->ops.power_on();
>> +       if (pd->ops.power_on)
>> +               return pd->ops.power_on();
>> +
>> +       return 0;
>>  }
>
>I usually write things like that as
>
>return pd->ops.power_on ? pd->ops.power_on() : 0;
>
>That gets the job done in just one line of code instead of 4 and in
>one statement instead of 3.
>
Sure. Thanks. Will roll this in with the next submission.

Thanks,
Lina


From linus.walleij at linaro.org  Thu Feb 18 15:19:18 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 19 Feb 2016 00:19:18 +0100
Subject: [PATCH v2 1/5] MIPS: jz4740: remove broken irq_to_gpio() call
In-Reply-To: <20160216160609.GA15268@linux-mips.org>
References: <455637086-2794174-1-git-send-email-arnd@arndb.de>
 <1455637261-2920972-1-git-send-email-arnd@arndb.de>
 <20160216160609.GA15268@linux-mips.org>
Message-ID: <CACRpkda=TFuUWzV_pLKoVhCZp1zWbEjoGmCey_w87bsuQZZ=jg@mail.gmail.com>

On Tue, Feb 16, 2016 at 5:06 PM, Ralf Baechle <ralf at linux-mips.org> wrote:

>> -#define IRQ_TO_BIT(irq) BIT(irq_to_gpio(irq) & 0x1f)
>> +#define IRQ_TO_BIT(irq) BIT((irq - JZ4740_IRQ_GPIO(0)) & 0x1f)
>>
>>  static void jz_gpio_check_trigger_both(struct jz_gpio_chip *chip, unsigned int irq)
>>  {
>
> I've already committed an identical fix locally.
>
>   Ralf

I took that fix out of linux-next and applied to the GPIO tree so I can apply
the rest of the patches without build problems. If you keep it
around without changing it, git should cope I guess.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Feb 18 15:19:46 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 19 Feb 2016 00:19:46 +0100
Subject: [PATCH v2 2/5] gpio: remove broken irq_to_gpio() interface
In-Reply-To: <1455637261-2920972-2-git-send-email-arnd@arndb.de>
References: <455637086-2794174-1-git-send-email-arnd@arndb.de>
 <1455637261-2920972-1-git-send-email-arnd@arndb.de>
 <1455637261-2920972-2-git-send-email-arnd@arndb.de>
Message-ID: <CACRpkdaNA0p95f8i4o0+Abqc-YshvaBhOBAWbi=s1AfFmeHY_A@mail.gmail.com>

On Tue, Feb 16, 2016 at 4:40 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> gpiolib has removed the irq_to_gpio() API several years ago,
> but the global header still provided a non-working stub.
>
> To prevent new users of this broken function from showing
> up, let's remove the stubs as well.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Patch applied.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Feb 18 15:20:53 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 19 Feb 2016 00:20:53 +0100
Subject: [PATCH v2 3/5] gpio: ks8695: remove irq_to_gpio function
In-Reply-To: <1455637261-2920972-3-git-send-email-arnd@arndb.de>
References: <455637086-2794174-1-git-send-email-arnd@arndb.de>
 <1455637261-2920972-1-git-send-email-arnd@arndb.de>
 <1455637261-2920972-3-git-send-email-arnd@arndb.de>
Message-ID: <CACRpkdZEvuA2H7WaFtYtzOTRoZo1t5wpHu+O2oHGudoK63F8Gg@mail.gmail.com>

On Tue, Feb 16, 2016 at 4:40 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> The ks8695 gpio driver has its own copy of the irq_to_gpio()
> function. This is completely unused in the mainline kernel
> after we converted all remaining users several years ago,
> so we can remove the definition as well.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Patch applied.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Feb 18 15:21:51 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 19 Feb 2016 00:21:51 +0100
Subject: [PATCH v2 4/5] gpio: ep93xx: remove private irq_to_gpio function
In-Reply-To: <1455637261-2920972-4-git-send-email-arnd@arndb.de>
References: <455637086-2794174-1-git-send-email-arnd@arndb.de>
 <1455637261-2920972-1-git-send-email-arnd@arndb.de>
 <1455637261-2920972-4-git-send-email-arnd@arndb.de>
Message-ID: <CACRpkdYrUxkOGvxi85zAn8O32otLNGtBGrvQPSqvnm1htp=+-w@mail.gmail.com>

On Tue, Feb 16, 2016 at 4:40 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> The ep93xx goes through its own back-and-forth dance every time
> it wants to know the gpio number for an irq line, when it really
> just hardcodes a fixed offset in ep93xx_gpio_to_irq().
>
> This removes the pointless macro and replaces the conversion inside
> of the driver with simple add/subtract operations, using an
> explicit macro.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Holding this back waiting for the dependent cleanup to come in.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Feb 18 15:23:39 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 19 Feb 2016 00:23:39 +0100
Subject: [PATCH v2 5/5] gpio: allow setting ARCH_NR_GPIOS from Kconfig
In-Reply-To: <1455637261-2920972-5-git-send-email-arnd@arndb.de>
References: <455637086-2794174-1-git-send-email-arnd@arndb.de>
 <1455637261-2920972-1-git-send-email-arnd@arndb.de>
 <1455637261-2920972-5-git-send-email-arnd@arndb.de>
Message-ID: <CACRpkdaSxhBrSt5qcUUJPcN6nv9Go96TP52cyU_nBZZM0phuPA@mail.gmail.com>

On Tue, Feb 16, 2016 at 4:40 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> The ARM version of asm/gpio.h basically just contains the same definitions
> as the gpiolib version, with the exception of ARCH_NR_GPIOS.
>
> This adds the option for overriding the constant through Kconfig to
> the architecture-independent header, so we can remove the ARM specific
> file later.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Patch applied.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Feb 18 15:31:03 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 19 Feb 2016 00:31:03 +0100
Subject: [PATCH 2/2] pinctrl: mediatek: add input-enable and direction
 setting for eint resources
In-Reply-To: <1455650194-9813-3-git-send-email-biao.huang@mediatek.com>
References: <1455650194-9813-1-git-send-email-biao.huang@mediatek.com>
 <1455650194-9813-3-git-send-email-biao.huang@mediatek.com>
Message-ID: <CACRpkdYeyAejh5Dtw7SKb7o790PcQgnz4tWpT+79hQ2_H6Lj5Q@mail.gmail.com>

On Tue, Feb 16, 2016 at 8:16 PM, Biao Huang <biao.huang at mediatek.com> wrote:

> To use pin as eint, user should make sure that:
> 1. pin is set to right mode, this is done in .irq_request_resources
> implementation already.
> 2. direction of the pin is input, which should call GPIO API to set
> pin to input gpio.
> We add what step 2 do to .irq_request_resources so that user doesn't
> need call GPIO API any more when pin for eint usage.
>
> Signed-off-by: Biao Huang <biao.huang at mediatek.com>

Patch applied.

Yours,
Linus Walleij


From vincent.stehle at laposte.net  Thu Feb 18 15:31:17 2016
From: vincent.stehle at laposte.net (=?UTF-8?q?Vincent=20Stehl=C3=A9?=)
Date: Fri, 19 Feb 2016 00:31:17 +0100
Subject: [PATCH next] ARM: virt: fix build of hyp-stub
Message-ID: <1455838277-11083-1-git-send-email-vincent.stehle@laposte.net>

Compile hyp-stub explicitly for arm v7-a. This fixes the following build
errors:

  arch/arm/kernel/hyp-stub.S: Assembler messages:
  arch/arm/kernel/hyp-stub.S:168: Error: selected processor does not support `ubfx r7,r7,#28,#4' in ARM mode
  arch/arm/kernel/hyp-stub.S:176: Error: selected processor does not support `isb' in ARM mode

Signed-off-by: Vincent Stehl? <vincent.stehle at laposte.net>
Cc: Jean-Philippe Brucker <jean-philippe.brucker at arm.com>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
---


Hi,

This can be seen with linux next-20160218 and arm e.g. allmodconfig.

Best regards,

V.


 arch/arm/kernel/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 2c5f160..15684c5 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -88,6 +88,8 @@ obj-$(CONFIG_DEBUG_LL)	+= debug.o
 obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
 
 obj-$(CONFIG_ARM_VIRT_EXT)	+= hyp-stub.o
+AFLAGS_hyp-stub.o		:=-Wa,-march=armv7-a
+
 ifeq ($(CONFIG_ARM_PSCI),y)
 obj-$(CONFIG_SMP)		+= psci_smp.o
 endif
-- 
2.7.0



From linux at arm.linux.org.uk  Thu Feb 18 15:41:44 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 18 Feb 2016 23:41:44 +0000
Subject: [PATCH] ARM: virt: fix hyp-stub build for pre-ARMv7 CPUs
In-Reply-To: <1455799309-21300-1-git-send-email-jean-philippe.brucker@arm.com>
References: <20160217212551.GJ19428@n2100.arm.linux.org.uk>
 <1455799309-21300-1-git-send-email-jean-philippe.brucker@arm.com>
Message-ID: <20160218234144.GU19428@n2100.arm.linux.org.uk>

On Thu, Feb 18, 2016 at 12:41:49PM +0000, Jean-Philippe Brucker wrote:
> ARMv6 CPUs do not have virtualisation extensions, but hyp-stub.S is
> still included into the image to keep it generic. In order to use ARMv7
> instructions during HYP initialisation, add -march=armv7-a flag to
> hyp-stub's build.
> 
> On an ARMv6 CPU, __hyp_stub_install returns as soon as it detects that
> the mode isn't HYP, so we will never reach those instructions.
> 
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker at arm.com>

Please drop this in the patch system, thanks.

> ---
>  arch/arm/boot/compressed/Makefile |    2 ++
>  arch/arm/kernel/Makefile          |    1 +
>  2 files changed, 3 insertions(+)
> 
> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
> index 7a6a58e..43788b1 100644
> --- a/arch/arm/boot/compressed/Makefile
> +++ b/arch/arm/boot/compressed/Makefile
> @@ -195,5 +195,7 @@ CFLAGS_font.o := -Dstatic=
>  $(obj)/font.c: $(FONTC)
>  	$(call cmd,shipped)
>  
> +AFLAGS_hyp-stub.o := -Wa,-march=armv7-a
> +
>  $(obj)/hyp-stub.S: $(srctree)/arch/$(SRCARCH)/kernel/hyp-stub.S
>  	$(call cmd,shipped)
> diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
> index 2c5f160..ad325a8 100644
> --- a/arch/arm/kernel/Makefile
> +++ b/arch/arm/kernel/Makefile
> @@ -88,6 +88,7 @@ obj-$(CONFIG_DEBUG_LL)	+= debug.o
>  obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
>  
>  obj-$(CONFIG_ARM_VIRT_EXT)	+= hyp-stub.o
> +AFLAGS_hyp-stub.o		:=-Wa,-march=armv7-a
>  ifeq ($(CONFIG_ARM_PSCI),y)
>  obj-$(CONFIG_SMP)		+= psci_smp.o
>  endif
> -- 
> 1.7.9.5
> 

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From dave.long at linaro.org  Thu Feb 18 15:48:13 2016
From: dave.long at linaro.org (David Long)
Date: Thu, 18 Feb 2016 18:48:13 -0500
Subject: [PATCH 0/8] arm64: Add kernel probes (kprobes) support
Message-ID: <1455839301-26464-1-git-send-email-dave.long@linaro.org>

From: "David A. Long" <dave.long at linaro.org>

This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
first seen in October 2013. This version attempts to address concerns raised by
reviewers and also fixes problems discovered during testing.

This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
and return probes(kretprobes) support for ARM64.

The kprobes mechanism makes use of software breakpoint and single stepping
support available in the ARM v8 kernel.

Changes since v2 include:

1) Removal of NOP padding in kprobe XOL slots. Slots are now exactly one
instruction long.
2) Disabling of interrupts during execution in single-step mode.
3) Fixing of numerous problems in instruction simulation code (mostly
thanks to Will Cohen).
4) Support for the HAVE_REGS_AND_STACK_ACCESS_API feature is added, to allow
access to kprobes through debugfs.
5) kprobes is *not* enabled in defconfig.
6) Numerous complaints from checkpatch have been cleaned up, although a couple
remain as removing the function pointer typedefs results in ugly code.

Changes since v3 include:

1) Remove table-driven instruction parsing and replace with an if statement
calling out to old and new instruction test functions in insn.c.
2) I removed the addition of orig_x0 to ptrace.h.
3) Reorder the patches.
4) Replace the previous interrupt disabling (from Will Cohen) with
an improved solution (from Steve Capper).

Changes since v4 include:

1) Added insn.c functions to detect exception instructions and DAIF
   read/write instructions, and use them to reject probing same.
2) Changed adr detect function to also recognize adrp. Reject both.
3) Added missing __kprobes for some new functions.
4) Added call to kprobes_fault_handler from mm do_page_fault.
5) Reject all non-simulated branch/ret instructions, not just those
   that use an immediate offset.
6) Moved software breakpoint definitions into debug-monitors.h.
7) Removed "!XIP_KERNEL" from Kconfig.
8) changed kprobes_condition_check_t and kprobes_prepare_t to probes_*,
   for future sharing with uprobes.
9) Removed bogus call to kprobes_restore_local_irqflag() from 
   trampoline_probe_handler().

Changes since v5 include:

1) Replaced installation of breakpoint hook with direct call from the
handlers in debug-monitors.c, as requested.
2) Reject probing of instructions that read the interrupt mask, in
addition to instructions that set it.
3) Cleaned up comments describing usage of Debug Mask.
4) Added KPROBE_REENTER case in reenter_kprobe.
5) Corrected the ifdef'd definitions for notify_page_fault() to be
consistent when KPROBES is not configed.
6) Changed "cpsr" to "pstate" for HAVE_REGS_AND_STACK_ACCESS_API feature.
7) Added back in missing new files in previous patch.
8) Changed two instances of pr_warning() to pr_warn().

Note that there seems to be at least a potential issue with kprobes
on multiple (possibly all) platforms having to do with use of kfree
inside of the kretprobes trampoline handler.  This has manifested
occasionally in systemtap testing on arm64.  There does not appear to
be an simple solution to the problem.

Changes since v6 include:

1) New trampoline code from Will Cohen fixes the occasional failure seen
when processing kretprobes by replacing the software breakpoint with
assembly code to implement the return to the original execution stream.
2) Changed ip0, ip1, fp, and lr to plain numbered registers for purposes
of recognizing them as an ascii string in the stack/reg access code.
3) Removed orig_x0.
4) Moved ARM_x* defines from arch/arm64/include/uapi/asm/ptrace.h to
arch/arm64/kernel/ptrace.c.

Changes since v7 include:

1) Move trampoline entry/return code into separate ".S" file instead
of making it a macro in a header file.
2) Add missing register name definitions in asm-offsets.c and use them
in place of hard-coded integer offsets in the trampoline code.
3) Correct the values used to decode MSR immediate instructions, in insn.h.
4) Remove the currently unused simulate_none() function.

Changes since v8 include:

1) Replaced use of REG_OFFSET_NAME with GPR_OFFSET_NAME for numbered
registers.
2) Added an alias for "lr" in the register name lookup table, which perf
tools need to be able to recognize.
3) Changed the code for checking instruction types for probeability and
steppability as per review feedback.
4) Fixed the size of cache being flushed when filling single-step slot.
5) Fixed big-endian issues.
6) Blacklisted copy_to/from_user to avoid aborts while single-stepping.
7) Record conditional instructions that fail the conditional test just
like any other probed (non-conditional) instruction.
8) Removed use of magic number for detecting jprobe return and just
check the breakpoint address instead.
9) Got rid of the unnecessary arch/arm64/kprobes.h.
10) The PSTATE and SP are now properly saved in the kretprobe trampoline
code.
11) This patch no longer depends on the "Consolidate redundant
register/stack access code" patch set.
12) Remove call to fixup_exception from kprobe_fault_handler.

David A. Long (3):
  arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
  arm64: Add more test functions to insn.c
  arm64: add copy_to/from_user to kprobes blacklist

Sandeepa Prabhu (4):
  arm64: Kprobes with single stepping support
  arm64: kprobes instruction simulation support
  arm64: Add kernel return probes support (kretprobes)
  kprobes: Add arm64 case in kprobe example module

William Cohen (1):
  arm64: Add trampoline code for kretprobes

 arch/arm64/Kconfig                       |   3 +
 arch/arm64/include/asm/debug-monitors.h  |   5 +
 arch/arm64/include/asm/insn.h            |  40 ++
 arch/arm64/include/asm/kprobes.h         |  62 ++++
 arch/arm64/include/asm/probes.h          |  45 +++
 arch/arm64/include/asm/ptrace.h          |  33 +-
 arch/arm64/kernel/Makefile               |   6 +-
 arch/arm64/kernel/asm-offsets.c          |  22 ++
 arch/arm64/kernel/debug-monitors.c       |  18 +-
 arch/arm64/kernel/insn.c                 | 145 ++++++++
 arch/arm64/kernel/kprobes-arm64.c        | 150 ++++++++
 arch/arm64/kernel/kprobes-arm64.h        |  35 ++
 arch/arm64/kernel/kprobes.c              | 615 +++++++++++++++++++++++++++++++
 arch/arm64/kernel/kprobes_trampoline.S   |  67 ++++
 arch/arm64/kernel/probes-simulate-insn.c | 187 ++++++++++
 arch/arm64/kernel/probes-simulate-insn.h |  30 ++
 arch/arm64/kernel/ptrace.c               | 117 ++++++
 arch/arm64/kernel/vmlinux.lds.S          |   1 +
 arch/arm64/lib/copy_from_user.S          |   1 +
 arch/arm64/lib/copy_to_user.S            |   1 +
 arch/arm64/mm/fault.c                    |  25 ++
 samples/kprobes/kprobe_example.c         |   8 +
 22 files changed, 1610 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm64/include/asm/kprobes.h
 create mode 100644 arch/arm64/include/asm/probes.h
 create mode 100644 arch/arm64/kernel/kprobes-arm64.c
 create mode 100644 arch/arm64/kernel/kprobes-arm64.h
 create mode 100644 arch/arm64/kernel/kprobes.c
 create mode 100644 arch/arm64/kernel/kprobes_trampoline.S
 create mode 100644 arch/arm64/kernel/probes-simulate-insn.c
 create mode 100644 arch/arm64/kernel/probes-simulate-insn.h

-- 
2.5.0



From dave.long at linaro.org  Thu Feb 18 15:48:14 2016
From: dave.long at linaro.org (David Long)
Date: Thu, 18 Feb 2016 18:48:14 -0500
Subject: [PATCH 1/8] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
In-Reply-To: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
References: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
Message-ID: <1455839301-26464-2-git-send-email-dave.long@linaro.org>

From: "David A. Long" <dave.long at linaro.org>

Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.

Signed-off-by: David A. Long <dave.long at linaro.org>
---
 arch/arm64/Kconfig              |   1 +
 arch/arm64/include/asm/ptrace.h |  31 +++++++++++
 arch/arm64/kernel/ptrace.c      | 117 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 149 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc6228..4211b0d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -78,6 +78,7 @@ config ARM64
 	select HAVE_PERF_EVENTS
 	select HAVE_PERF_REGS
 	select HAVE_PERF_USER_STACK_DUMP
+	select HAVE_REGS_AND_STACK_ACCESS_API
 	select HAVE_RCU_TABLE_FREE
 	select HAVE_SYSCALL_TRACEPOINTS
 	select IOMMU_DMA if IOMMU_SUPPORT
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index e9e5467..7bd6445 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -118,6 +118,8 @@ struct pt_regs {
 	u64 syscallno;
 };
 
+#define MAX_REG_OFFSET offsetof(struct user_pt_regs, pstate)
+
 #define arch_has_single_step()	(1)
 
 #ifdef CONFIG_COMPAT
@@ -146,6 +148,35 @@ struct pt_regs {
 #define user_stack_pointer(regs) \
 	(!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
 
+extern int regs_query_register_offset(const char *name);
+extern const char *regs_query_register_name(unsigned int offset);
+extern bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr);
+extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
+					       unsigned int n);
+
+/**
+ * regs_get_register() - get register value from its offset
+ * @regs:	   pt_regs from which register value is gotten
+ * @offset:    offset number of the register.
+ *
+ * regs_get_register returns the value of a register whose offset from @regs.
+ * The @offset is the offset of the register in struct pt_regs.
+ * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
+ */
+static inline u64 regs_get_register(struct pt_regs *regs,
+					      unsigned int offset)
+{
+	if (unlikely(offset > MAX_REG_OFFSET))
+		return 0;
+	return *(u64 *)((u64)regs + offset);
+}
+
+/* Valid only for Kernel mode traps. */
+static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
+{
+	return regs->sp;
+}
+
 static inline unsigned long regs_return_value(struct pt_regs *regs)
 {
 	return regs->regs[0];
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index ff7f132..efebf0f 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -48,6 +48,123 @@
 #define CREATE_TRACE_POINTS
 #include <trace/events/syscalls.h>
 
+struct pt_regs_offset {
+	const char *name;
+	int offset;
+};
+
+#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+#define	GPR_OFFSET_NAME(r)	\
+	{.name = "x" #r, .offset = offsetof(struct pt_regs, regs[r])}
+
+static const struct pt_regs_offset regoffset_table[] = {
+	GPR_OFFSET_NAME(0),
+	GPR_OFFSET_NAME(1),
+	GPR_OFFSET_NAME(2),
+	GPR_OFFSET_NAME(3),
+	GPR_OFFSET_NAME(4),
+	GPR_OFFSET_NAME(5),
+	GPR_OFFSET_NAME(6),
+	GPR_OFFSET_NAME(7),
+	GPR_OFFSET_NAME(8),
+	GPR_OFFSET_NAME(9),
+	GPR_OFFSET_NAME(10),
+	GPR_OFFSET_NAME(11),
+	GPR_OFFSET_NAME(12),
+	GPR_OFFSET_NAME(13),
+	GPR_OFFSET_NAME(14),
+	GPR_OFFSET_NAME(15),
+	GPR_OFFSET_NAME(16),
+	GPR_OFFSET_NAME(17),
+	GPR_OFFSET_NAME(18),
+	GPR_OFFSET_NAME(19),
+	GPR_OFFSET_NAME(20),
+	GPR_OFFSET_NAME(21),
+	GPR_OFFSET_NAME(22),
+	GPR_OFFSET_NAME(23),
+	GPR_OFFSET_NAME(24),
+	GPR_OFFSET_NAME(25),
+	GPR_OFFSET_NAME(26),
+	GPR_OFFSET_NAME(27),
+	GPR_OFFSET_NAME(28),
+	GPR_OFFSET_NAME(29),
+	GPR_OFFSET_NAME(30),
+	{.name = "lr", .offset = offsetof(struct pt_regs, regs[30])},
+	REG_OFFSET_NAME(sp),
+	REG_OFFSET_NAME(pc),
+	REG_OFFSET_NAME(pstate),
+	REG_OFFSET_END,
+};
+
+/**
+ * regs_query_register_offset() - query register offset from its name
+ * @name:	the name of a register
+ *
+ * regs_query_register_offset() returns the offset of a register in struct
+ * pt_regs from its name. If the name is invalid, this returns -EINVAL;
+ */
+int regs_query_register_offset(const char *name)
+{
+	const struct pt_regs_offset *roff;
+
+	for (roff = regoffset_table; roff->name != NULL; roff++)
+		if (!strcmp(roff->name, name))
+			return roff->offset;
+	return -EINVAL;
+}
+
+/**
+ * regs_query_register_name() - query register name from its offset
+ * @offset:	the offset of a register in struct pt_regs.
+ *
+ * regs_query_register_name() returns the name of a register from its
+ * offset in struct pt_regs. If the @offset is invalid, this returns NULL;
+ */
+const char *regs_query_register_name(unsigned int offset)
+{
+	const struct pt_regs_offset *roff;
+
+	for (roff = regoffset_table; roff->name != NULL; roff++)
+		if (roff->offset == offset)
+			return roff->name;
+	return NULL;
+}
+
+/**
+ * regs_within_kernel_stack() - check the address in the stack
+ * @regs:      pt_regs which contains kernel stack pointer.
+ * @addr:      address which is checked.
+ *
+ * regs_within_kernel_stack() checks @addr is within the kernel stack page(s).
+ * If @addr is within the kernel stack, it returns true. If not, returns false.
+ */
+bool regs_within_kernel_stack(struct pt_regs *regs, unsigned long addr)
+{
+	return ((addr & ~(THREAD_SIZE - 1))  ==
+		(kernel_stack_pointer(regs) & ~(THREAD_SIZE - 1)));
+}
+
+/**
+ * regs_get_kernel_stack_nth() - get Nth entry of the stack
+ * @regs:	pt_regs which contains kernel stack pointer.
+ * @n:		stack entry number.
+ *
+ * regs_get_kernel_stack_nth() returns @n th entry of the kernel stack which
+ * is specified by @regs. If the @n th entry is NOT in the kernel stack,
+ * this returns 0.
+ */
+unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs, unsigned int n)
+{
+	unsigned long *addr = (unsigned long *)kernel_stack_pointer(regs);
+
+	addr += n;
+	if (regs_within_kernel_stack(regs, (unsigned long)addr))
+		return *addr;
+	else
+		return 0;
+}
+
 /*
  * TODO: does not yet catch signals sent when the child dies.
  * in exit.c or in signal.c.
-- 
2.5.0



From dave.long at linaro.org  Thu Feb 18 15:48:15 2016
From: dave.long at linaro.org (David Long)
Date: Thu, 18 Feb 2016 18:48:15 -0500
Subject: [PATCH 2/8] arm64: Add more test functions to insn.c
In-Reply-To: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
References: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
Message-ID: <1455839301-26464-3-git-send-email-dave.long@linaro.org>

From: "David A. Long" <dave.long at linaro.org>

Certain instructions are hard to execute correctly out-of-line (as in
kprobes).  Test functions are added to insn.[hc] to identify these.  The
instructions include any that use PC-relative addressing, change the PC,
or change interrupt masking. For efficiency and simplicity test
functions are also added for small collections of related instructions.

Signed-off-by: David A. Long <dave.long at linaro.org>
---
 arch/arm64/include/asm/insn.h | 35 +++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/insn.c      | 34 ++++++++++++++++++++++++++++++++++
 2 files changed, 69 insertions(+)

diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index 30e50eb..662b42a 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -120,6 +120,29 @@ enum aarch64_insn_register {
 	AARCH64_INSN_REG_SP = 31  /* Stack pointer: as load/store base reg */
 };
 
+enum aarch64_insn_special_register {
+	AARCH64_INSN_SPCLREG_SPSR_EL1	= 0xC200,
+	AARCH64_INSN_SPCLREG_ELR_EL1	= 0xC201,
+	AARCH64_INSN_SPCLREG_SP_EL0	= 0xC208,
+	AARCH64_INSN_SPCLREG_SPSEL	= 0xC210,
+	AARCH64_INSN_SPCLREG_CURRENTEL	= 0xC212,
+	AARCH64_INSN_SPCLREG_DAIF	= 0xDA11,
+	AARCH64_INSN_SPCLREG_NZCV	= 0xDA10,
+	AARCH64_INSN_SPCLREG_FPCR	= 0xDA20,
+	AARCH64_INSN_SPCLREG_DSPSR_EL0	= 0xDA28,
+	AARCH64_INSN_SPCLREG_DLR_EL0	= 0xDA29,
+	AARCH64_INSN_SPCLREG_SPSR_EL2	= 0xE200,
+	AARCH64_INSN_SPCLREG_ELR_EL2	= 0xE201,
+	AARCH64_INSN_SPCLREG_SP_EL1	= 0xE208,
+	AARCH64_INSN_SPCLREG_SPSR_INQ	= 0xE218,
+	AARCH64_INSN_SPCLREG_SPSR_ABT	= 0xE219,
+	AARCH64_INSN_SPCLREG_SPSR_UND	= 0xE21A,
+	AARCH64_INSN_SPCLREG_SPSR_FIQ	= 0xE21B,
+	AARCH64_INSN_SPCLREG_SPSR_EL3	= 0xF200,
+	AARCH64_INSN_SPCLREG_ELR_EL3	= 0xF201,
+	AARCH64_INSN_SPCLREG_SP_EL2	= 0xF210
+};
+
 enum aarch64_insn_variant {
 	AARCH64_INSN_VARIANT_32BIT,
 	AARCH64_INSN_VARIANT_64BIT
@@ -223,8 +246,13 @@ static __always_inline bool aarch64_insn_is_##abbr(u32 code) \
 static __always_inline u32 aarch64_insn_get_##abbr##_value(void) \
 { return (val); }
 
+__AARCH64_INSN_FUNCS(adr_adrp,	0x1F000000, 0x10000000)
+__AARCH64_INSN_FUNCS(prfm_lit,	0xFF000000, 0xD8000000)
 __AARCH64_INSN_FUNCS(str_reg,	0x3FE0EC00, 0x38206800)
 __AARCH64_INSN_FUNCS(ldr_reg,	0x3FE0EC00, 0x38606800)
+__AARCH64_INSN_FUNCS(ldr_lit,	0xBF000000, 0x18000000)
+__AARCH64_INSN_FUNCS(ldrsw_lit,	0xFF000000, 0x98000000)
+__AARCH64_INSN_FUNCS(exclusive,	0x3F800000, 0x08000000)
 __AARCH64_INSN_FUNCS(stp_post,	0x7FC00000, 0x28800000)
 __AARCH64_INSN_FUNCS(ldp_post,	0x7FC00000, 0x28C00000)
 __AARCH64_INSN_FUNCS(stp_pre,	0x7FC00000, 0x29800000)
@@ -273,10 +301,14 @@ __AARCH64_INSN_FUNCS(svc,	0xFFE0001F, 0xD4000001)
 __AARCH64_INSN_FUNCS(hvc,	0xFFE0001F, 0xD4000002)
 __AARCH64_INSN_FUNCS(smc,	0xFFE0001F, 0xD4000003)
 __AARCH64_INSN_FUNCS(brk,	0xFFE0001F, 0xD4200000)
+__AARCH64_INSN_FUNCS(exception,	0xFF000000, 0xD4000000)
 __AARCH64_INSN_FUNCS(hint,	0xFFFFF01F, 0xD503201F)
 __AARCH64_INSN_FUNCS(br,	0xFFFFFC1F, 0xD61F0000)
 __AARCH64_INSN_FUNCS(blr,	0xFFFFFC1F, 0xD63F0000)
 __AARCH64_INSN_FUNCS(ret,	0xFFFFFC1F, 0xD65F0000)
+__AARCH64_INSN_FUNCS(mrs,	0xFFF00000, 0xD5300000)
+__AARCH64_INSN_FUNCS(msr_imm,	0xFFF8F01F, 0xD500401F)
+__AARCH64_INSN_FUNCS(msr_reg,	0xFFF00000, 0xD5100000)
 
 #undef	__AARCH64_INSN_FUNCS
 
@@ -286,6 +318,8 @@ bool aarch64_insn_is_branch_imm(u32 insn);
 int aarch64_insn_read(void *addr, u32 *insnp);
 int aarch64_insn_write(void *addr, u32 insn);
 enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
+bool aarch64_insn_uses_literal(u32 insn);
+bool aarch64_insn_is_branch(u32 insn);
 u64 aarch64_insn_decode_immediate(enum aarch64_insn_imm_type type, u32 insn);
 u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
 				  u32 insn, u64 imm);
@@ -367,6 +401,7 @@ bool aarch32_insn_is_wide(u32 insn);
 #define A32_RT_OFFSET	12
 #define A32_RT2_OFFSET	 0
 
+u32 aarch64_extract_system_register(u32 insn);
 u32 aarch32_insn_extract_reg_num(u32 insn, int offset);
 u32 aarch32_insn_mcr_extract_opc2(u32 insn);
 u32 aarch32_insn_mcr_extract_crm(u32 insn);
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 7371455..60c1c71 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -162,6 +162,32 @@ static bool __kprobes __aarch64_insn_hotpatch_safe(u32 insn)
 		aarch64_insn_is_nop(insn);
 }
 
+bool __kprobes aarch64_insn_uses_literal(u32 insn)
+{
+	/* ldr/ldrsw (literal), prfm */
+
+	return aarch64_insn_is_ldr_lit(insn) ||
+		aarch64_insn_is_ldrsw_lit(insn) ||
+		aarch64_insn_is_adr_adrp(insn) ||
+		aarch64_insn_is_prfm_lit(insn);
+}
+
+bool __kprobes aarch64_insn_is_branch(u32 insn)
+{
+	/* b, bl, cb*, tb*, b.cond, br, blr */
+
+	return aarch64_insn_is_b(insn) ||
+		aarch64_insn_is_bl(insn) ||
+		aarch64_insn_is_cbz(insn) ||
+		aarch64_insn_is_cbnz(insn) ||
+		aarch64_insn_is_tbz(insn) ||
+		aarch64_insn_is_tbnz(insn) ||
+		aarch64_insn_is_ret(insn) ||
+		aarch64_insn_is_br(insn) ||
+		aarch64_insn_is_blr(insn) ||
+		aarch64_insn_is_bcond(insn);
+}
+
 /*
  * ARM Architecture Reference Manual for ARMv8 Profile-A, Issue A.a
  * Section B2.6.5 "Concurrent modification and execution of instructions":
@@ -1175,6 +1201,14 @@ u32 aarch64_set_branch_offset(u32 insn, s32 offset)
 	BUG();
 }
 
+/*
+ * Extract the Op/CR data from a msr/mrs instruction.
+ */
+u32 aarch64_insn_extract_system_reg(u32 insn)
+{
+	return (insn & 0x1FFFE0) >> 5;
+}
+
 bool aarch32_insn_is_wide(u32 insn)
 {
 	return insn >= 0xe800;
-- 
2.5.0



From dave.long at linaro.org  Thu Feb 18 15:48:16 2016
From: dave.long at linaro.org (David Long)
Date: Thu, 18 Feb 2016 18:48:16 -0500
Subject: [PATCH 3/8] arm64: add copy_to/from_user to kprobes blacklist
In-Reply-To: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
References: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
Message-ID: <1455839301-26464-4-git-send-email-dave.long@linaro.org>

From: "David A. Long" <dave.long at linaro.org>

Currrently taking exceptions when accessing user data from a kprobe'd
instruction doesn't work. Avoid this situation by blacklisting the relevant
functions.

Signed-off-by: David A. Long <dave.long at linaro.org>
---
 arch/arm64/lib/copy_from_user.S | 1 +
 arch/arm64/lib/copy_to_user.S   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S
index 4699cd7..0ac2131 100644
--- a/arch/arm64/lib/copy_from_user.S
+++ b/arch/arm64/lib/copy_from_user.S
@@ -66,6 +66,7 @@
 	.endm
 
 end	.req	x5
+	.section .kprobes.text,"ax",%progbits
 ENTRY(__copy_from_user)
 ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
 	    CONFIG_ARM64_PAN)
diff --git a/arch/arm64/lib/copy_to_user.S b/arch/arm64/lib/copy_to_user.S
index 7512bbb..e4eb84c 100644
--- a/arch/arm64/lib/copy_to_user.S
+++ b/arch/arm64/lib/copy_to_user.S
@@ -65,6 +65,7 @@
 	.endm
 
 end	.req	x5
+	.section .kprobes.text,"ax",%progbits
 ENTRY(__copy_to_user)
 ALTERNATIVE("nop", __stringify(SET_PSTATE_PAN(0)), ARM64_HAS_PAN, \
 	    CONFIG_ARM64_PAN)
-- 
2.5.0



From dave.long at linaro.org  Thu Feb 18 15:48:17 2016
From: dave.long at linaro.org (David Long)
Date: Thu, 18 Feb 2016 18:48:17 -0500
Subject: [PATCH 4/8] arm64: Kprobes with single stepping support
In-Reply-To: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
References: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
Message-ID: <1455839301-26464-5-git-send-email-dave.long@linaro.org>

From: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>

Add support for basic kernel probes(kprobes) and jump probes
(jprobes) for ARM64.

Kprobes utilizes software breakpoint and single step debug
exceptions supported on ARM v8.

A software breakpoint is placed at the probe address to trap the
kernel execution into the kprobe handler.

ARM v8 supports enabling single stepping before the break exception
return (ERET), with next PC in exception return address (ELR_EL1). The
kprobe handler prepares an executable memory slot for out-of-line
execution with a copy of the original instruction being probed, and
enables single stepping. The PC is set to the out-of-line slot address
before the ERET. With this scheme, the instruction is executed with the
exact same register context except for the PC (and DAIF) registers.

Debug mask (PSTATE.D) is enabled only when single stepping a recursive
kprobe, e.g.: during kprobes reenter so that probed instruction can be
single stepped within the kprobe handler -exception- context.
The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
any further re-entry is prevented by not calling handlers and the case
counted as a missed kprobe).

Single stepping from the x-o-l slot has a drawback for PC-relative accesses
like branching and symbolic literals access as the offset from the new PC
(slot address) may not be ensured to fit in the immediate value of
the opcode. Such instructions need simulation, so reject
probing them.

Instructions generating exceptions or cpu mode change are rejected
for probing.

Exclusive load/store instructions are rejected too.  Additionally, the
code is checked to see if it is inside an exclusive load/store sequence
(code from Pratyush).

System instructions are mostly enabled for stepping, except MSR/MRS
accesses to "DAIF" flags in PSTATE, which are not safe for
probing.

Thanks to Steve Capper and Pratyush Anand for several suggested
Changes.

Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>
Signed-off-by: David A. Long <dave.long at linaro.org>
Signed-off-by: Pratyush Anand <panand at redhat.com>
---
 arch/arm64/Kconfig                      |   1 +
 arch/arm64/include/asm/debug-monitors.h |   5 +
 arch/arm64/include/asm/insn.h           |   4 +-
 arch/arm64/include/asm/kprobes.h        |  60 ++++
 arch/arm64/include/asm/probes.h         |  44 +++
 arch/arm64/include/asm/ptrace.h         |   2 +-
 arch/arm64/kernel/Makefile              |   1 +
 arch/arm64/kernel/debug-monitors.c      |  18 +-
 arch/arm64/kernel/kprobes-arm64.c       | 121 ++++++++
 arch/arm64/kernel/kprobes-arm64.h       |  35 +++
 arch/arm64/kernel/kprobes.c             | 511 ++++++++++++++++++++++++++++++++
 arch/arm64/kernel/vmlinux.lds.S         |   1 +
 arch/arm64/mm/fault.c                   |  25 ++
 13 files changed, 823 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm64/include/asm/kprobes.h
 create mode 100644 arch/arm64/include/asm/probes.h
 create mode 100644 arch/arm64/kernel/kprobes-arm64.c
 create mode 100644 arch/arm64/kernel/kprobes-arm64.h
 create mode 100644 arch/arm64/kernel/kprobes.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4211b0d..c395386 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -81,6 +81,7 @@ config ARM64
 	select HAVE_REGS_AND_STACK_ACCESS_API
 	select HAVE_RCU_TABLE_FREE
 	select HAVE_SYSCALL_TRACEPOINTS
+	select HAVE_KPROBES
 	select IOMMU_DMA if IOMMU_SUPPORT
 	select IRQ_DOMAIN
 	select IRQ_FORCED_THREADING
diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
index 279c85b5..274ab60 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -78,6 +78,11 @@
 
 #define CACHE_FLUSH_IS_SAFE		1
 
+/* kprobes BRK opcodes with ESR encoding  */
+#define BRK64_ESR_MASK		0xFFFF
+#define BRK64_ESR_KPROBES	0x0004
+#define BRK64_OPCODE_KPROBES	(AARCH64_BREAK_MON | (BRK64_ESR_KPROBES << 5))
+
 /* AArch32 */
 #define DBG_ESR_EVT_BKPT	0x4
 #define DBG_ESR_EVT_VECC	0x5
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index 662b42a..cf43773 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -253,6 +253,8 @@ __AARCH64_INSN_FUNCS(ldr_reg,	0x3FE0EC00, 0x38606800)
 __AARCH64_INSN_FUNCS(ldr_lit,	0xBF000000, 0x18000000)
 __AARCH64_INSN_FUNCS(ldrsw_lit,	0xFF000000, 0x98000000)
 __AARCH64_INSN_FUNCS(exclusive,	0x3F800000, 0x08000000)
+__AARCH64_INSN_FUNCS(load_ex,	0x3F400000, 0x08400000)
+__AARCH64_INSN_FUNCS(store_ex,	0x3F400000, 0x08000000)
 __AARCH64_INSN_FUNCS(stp_post,	0x7FC00000, 0x28800000)
 __AARCH64_INSN_FUNCS(ldp_post,	0x7FC00000, 0x28C00000)
 __AARCH64_INSN_FUNCS(stp_pre,	0x7FC00000, 0x29800000)
@@ -401,7 +403,7 @@ bool aarch32_insn_is_wide(u32 insn);
 #define A32_RT_OFFSET	12
 #define A32_RT2_OFFSET	 0
 
-u32 aarch64_extract_system_register(u32 insn);
+u32 aarch64_insn_extract_system_reg(u32 insn);
 u32 aarch32_insn_extract_reg_num(u32 insn, int offset);
 u32 aarch32_insn_mcr_extract_opc2(u32 insn);
 u32 aarch32_insn_mcr_extract_crm(u32 insn);
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
new file mode 100644
index 0000000..79c9511
--- /dev/null
+++ b/arch/arm64/include/asm/kprobes.h
@@ -0,0 +1,60 @@
+/*
+ * arch/arm64/include/asm/kprobes.h
+ *
+ * Copyright (C) 2013 Linaro Limited
+ *
+ * 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.
+ */
+
+#ifndef _ARM_KPROBES_H
+#define _ARM_KPROBES_H
+
+#include <linux/types.h>
+#include <linux/ptrace.h>
+#include <linux/percpu.h>
+
+#define __ARCH_WANT_KPROBES_INSN_SLOT
+#define MAX_INSN_SIZE			1
+#define MAX_STACK_SIZE			128
+
+#define flush_insn_slot(p)		do { } while (0)
+#define kretprobe_blacklist_size	0
+
+#include <asm/probes.h>
+
+struct prev_kprobe {
+	struct kprobe *kp;
+	unsigned int status;
+};
+
+/* Single step context for kprobe */
+struct kprobe_step_ctx {
+	unsigned long ss_pending;
+	unsigned long match_addr;
+};
+
+/* per-cpu kprobe control block */
+struct kprobe_ctlblk {
+	unsigned int kprobe_status;
+	unsigned long saved_irqflag;
+	struct prev_kprobe prev_kprobe;
+	struct kprobe_step_ctx ss_ctx;
+	struct pt_regs jprobe_saved_regs;
+	char jprobes_stack[MAX_STACK_SIZE];
+};
+
+void arch_remove_kprobe(struct kprobe *);
+int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
+int kprobe_exceptions_notify(struct notifier_block *self,
+			     unsigned long val, void *data);
+int kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr);
+int kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr);
+
+#endif /* _ARM_KPROBES_H */
diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
new file mode 100644
index 0000000..c5fcbe6
--- /dev/null
+++ b/arch/arm64/include/asm/probes.h
@@ -0,0 +1,44 @@
+/*
+ * arch/arm64/include/asm/probes.h
+ *
+ * Copyright (C) 2013 Linaro Limited
+ *
+ * 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.
+ */
+#ifndef _ARM_PROBES_H
+#define _ARM_PROBES_H
+
+struct kprobe;
+struct arch_specific_insn;
+
+typedef u32 kprobe_opcode_t;
+typedef unsigned long (kprobes_pstate_check_t)(unsigned long);
+typedef void (kprobes_handler_t) (u32 opcode, long addr, struct pt_regs *);
+
+enum pc_restore_type {
+	NO_RESTORE,
+	RESTORE_PC,
+};
+
+struct kprobe_pc_restore {
+	enum pc_restore_type type;
+	unsigned long addr;
+};
+
+/* architecture specific copy of original instruction */
+struct arch_specific_insn {
+	kprobe_opcode_t *insn;
+	kprobes_pstate_check_t *pstate_cc;
+	kprobes_handler_t *handler;
+	/* restore address after step xol */
+	struct kprobe_pc_restore restore;
+};
+
+#endif
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index 7bd6445..88b0a7e 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -212,7 +212,7 @@ static inline int valid_user_regs(struct user_pt_regs *regs)
 	return 0;
 }
 
-#define instruction_pointer(regs)	((unsigned long)(regs)->pc)
+#define instruction_pointer(regs)	((regs)->pc)
 
 extern unsigned long profile_pc(struct pt_regs *regs);
 
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 83cd7e6..5b0ee7d 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -37,6 +37,7 @@ arm64-obj-$(CONFIG_CPU_PM)		+= sleep.o suspend.o
 arm64-obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
 arm64-obj-$(CONFIG_JUMP_LABEL)		+= jump_label.o
 arm64-obj-$(CONFIG_KGDB)		+= kgdb.o
+arm64-obj-$(CONFIG_KPROBES)		+= kprobes.o kprobes-arm64.o
 arm64-obj-$(CONFIG_EFI)			+= efi.o efi-entry.stub.o
 arm64-obj-$(CONFIG_PCI)			+= pci.o
 arm64-obj-$(CONFIG_ARMV8_DEPRECATED)	+= armv8_deprecated.o
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index 8aee3ae..5e13e79 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -23,6 +23,7 @@
 #include <linux/hardirq.h>
 #include <linux/init.h>
 #include <linux/ptrace.h>
+#include <linux/kprobes.h>
 #include <linux/stat.h>
 #include <linux/uaccess.h>
 
@@ -253,10 +254,14 @@ static int single_step_handler(unsigned long addr, unsigned int esr,
 		 */
 		user_rewind_single_step(current);
 	} else {
+#ifdef	CONFIG_KPROBES
+		if (kprobe_single_step_handler(regs, esr) == DBG_HOOK_HANDLED)
+			return 0;
+#endif
 		if (call_step_hook(regs, esr) == DBG_HOOK_HANDLED)
 			return 0;
 
-		pr_warning("Unexpected kernel single-step exception at EL1\n");
+		pr_warn("Unexpected kernel single-step exception at EL1\n");
 		/*
 		 * Re-enable stepping since we know that we will be
 		 * returning to regs.
@@ -318,8 +323,15 @@ static int brk_handler(unsigned long addr, unsigned int esr,
 		};
 
 		force_sig_info(SIGTRAP, &info, current);
-	} else if (call_break_hook(regs, esr) != DBG_HOOK_HANDLED) {
-		pr_warning("Unexpected kernel BRK exception at EL1\n");
+	}
+#ifdef	CONFIG_KPROBES
+	else if ((esr & BRK64_ESR_MASK) == BRK64_ESR_KPROBES) {
+		if (kprobe_breakpoint_handler(regs, esr) != DBG_HOOK_HANDLED)
+			return -EFAULT;
+	}
+#endif
+	else if (call_break_hook(regs, esr) != DBG_HOOK_HANDLED) {
+		pr_warn("Unexpected kernel BRK exception at EL1\n");
 		return -EFAULT;
 	}
 
diff --git a/arch/arm64/kernel/kprobes-arm64.c b/arch/arm64/kernel/kprobes-arm64.c
new file mode 100644
index 0000000..e07727a
--- /dev/null
+++ b/arch/arm64/kernel/kprobes-arm64.c
@@ -0,0 +1,121 @@
+/*
+ * arch/arm64/kernel/kprobes-arm64.c
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/kprobes.h>
+#include <linux/module.h>
+#include <asm/kprobes.h>
+#include <asm/insn.h>
+#include <asm/sections.h>
+
+#include "kprobes-arm64.h"
+
+static bool __kprobes aarch64_insn_is_steppable(u32 insn)
+{
+	if (aarch64_get_insn_class(insn) == AARCH64_INSN_CLS_BR_SYS) {
+		if (aarch64_insn_is_branch(insn) ||
+		    aarch64_insn_is_msr_imm(insn) ||
+		    aarch64_insn_is_msr_reg(insn) ||
+		    aarch64_insn_is_exception(insn))
+			return false;
+
+		if (aarch64_insn_is_mrs(insn))
+			return aarch64_insn_extract_system_reg(insn)
+			     != AARCH64_INSN_SPCLREG_DAIF;
+
+		if (aarch64_insn_is_hint(insn))
+			return aarch64_insn_is_nop(insn);
+
+		return true;
+	}
+
+	if (aarch64_insn_uses_literal(insn) ||
+	    aarch64_insn_is_exclusive(insn))
+		return false;
+
+	return true;
+}
+
+/* Return:
+ *   INSN_REJECTED     If instruction is one not allowed to kprobe,
+ *   INSN_GOOD         If instruction is supported and uses instruction slot,
+ *   INSN_GOOD_NO_SLOT If instruction is supported but doesn't use its slot.
+ */
+static enum kprobe_insn __kprobes
+arm_probe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi)
+{
+	/*
+	 * Instructions reading or modifying the PC won't work from the XOL
+	 * slot.
+	 */
+	if (aarch64_insn_is_steppable(insn))
+		return INSN_GOOD;
+	else
+		return INSN_REJECTED;
+}
+
+static bool __kprobes
+is_probed_address_atomic(kprobe_opcode_t *scan_start, kprobe_opcode_t *scan_end)
+{
+	while (scan_start > scan_end) {
+		/*
+		 * atomic region starts from exclusive load and ends with
+		 * exclusive store.
+		 */
+		if (aarch64_insn_is_store_ex(le32_to_cpu(*scan_start)))
+			return false;
+		else if (aarch64_insn_is_load_ex(le32_to_cpu(*scan_start)))
+			return true;
+		scan_start--;
+	}
+
+	return false;
+}
+
+enum kprobe_insn __kprobes
+arm_kprobe_decode_insn(kprobe_opcode_t *addr, struct arch_specific_insn *asi)
+{
+	enum kprobe_insn decoded;
+	kprobe_opcode_t insn = le32_to_cpu(*addr);
+	kprobe_opcode_t *scan_start = addr - 1;
+	kprobe_opcode_t *scan_end = addr - MAX_ATOMIC_CONTEXT_SIZE;
+#if defined(CONFIG_MODULES) && defined(MODULES_VADDR)
+	struct module *mod;
+#endif
+
+	if (addr >= (kprobe_opcode_t *)_text &&
+	    scan_end < (kprobe_opcode_t *)_text)
+		scan_end = (kprobe_opcode_t *)_text;
+#if defined(CONFIG_MODULES) && defined(MODULES_VADDR)
+	else {
+		preempt_disable();
+		mod = __module_address((unsigned long)addr);
+		if (mod && within_module_init((unsigned long)addr, mod) &&
+			!within_module_init((unsigned long)scan_end, mod))
+			scan_end = (kprobe_opcode_t *)mod->init_layout.base;
+		else if (mod && within_module_core((unsigned long)addr, mod) &&
+			!within_module_core((unsigned long)scan_end, mod))
+			scan_end = (kprobe_opcode_t *)mod->core_layout.base;
+		preempt_enable();
+	}
+#endif
+	decoded = arm_probe_decode_insn(insn, asi);
+
+	if (decoded == INSN_REJECTED ||
+			is_probed_address_atomic(scan_start, scan_end))
+		return INSN_REJECTED;
+
+	return decoded;
+}
diff --git a/arch/arm64/kernel/kprobes-arm64.h b/arch/arm64/kernel/kprobes-arm64.h
new file mode 100644
index 0000000..e8378d3
--- /dev/null
+++ b/arch/arm64/kernel/kprobes-arm64.h
@@ -0,0 +1,35 @@
+/*
+ * arch/arm64/kernel/kprobes-arm64.h
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ *
+ * 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.
+ */
+
+#ifndef _ARM_KERNEL_KPROBES_ARM64_H
+#define _ARM_KERNEL_KPROBES_ARM64_H
+
+/*
+ * ARM strongly recommends a limit of 128 bytes between LoadExcl and
+ * StoreExcl instructions in a single thread of execution. So keep the
+ * max atomic context size as 32.
+ */
+#define MAX_ATOMIC_CONTEXT_SIZE	(128 / sizeof(kprobe_opcode_t))
+
+enum kprobe_insn {
+	INSN_REJECTED,
+	INSN_GOOD_NO_SLOT,
+	INSN_GOOD,
+};
+
+enum kprobe_insn __kprobes
+arm_kprobe_decode_insn(kprobe_opcode_t *addr, struct arch_specific_insn *asi);
+
+#endif /* _ARM_KERNEL_KPROBES_ARM64_H */
diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
new file mode 100644
index 0000000..8db71a4
--- /dev/null
+++ b/arch/arm64/kernel/kprobes.c
@@ -0,0 +1,511 @@
+/*
+ * arch/arm64/kernel/kprobes.c
+ *
+ * Kprobes support for ARM64
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ * Author: Sandeepa Prabhu <sandeepa.prabhu at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/kprobes.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/stop_machine.h>
+#include <linux/stringify.h>
+#include <asm/traps.h>
+#include <asm/ptrace.h>
+#include <asm/cacheflush.h>
+#include <asm/debug-monitors.h>
+#include <asm/system_misc.h>
+#include <asm/insn.h>
+#include <asm/uaccess.h>
+
+#include "kprobes-arm64.h"
+
+#define MIN_STACK_SIZE(addr)	min((unsigned long)MAX_STACK_SIZE,	\
+	(unsigned long)current_thread_info() + THREAD_START_SP - (addr))
+
+void jprobe_return_break(void);
+
+DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
+DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
+
+static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
+{
+	/* prepare insn slot */
+	p->ainsn.insn[0] = cpu_to_le32(p->opcode);
+
+	flush_icache_range((uintptr_t) (p->ainsn.insn),
+			   (uintptr_t) (p->ainsn.insn) +
+			   MAX_INSN_SIZE * sizeof(kprobe_opcode_t));
+
+	/*
+	 * Needs restoring of return address after stepping xol.
+	 */
+	p->ainsn.restore.addr = (unsigned long) p->addr +
+	  sizeof(kprobe_opcode_t);
+	p->ainsn.restore.type = RESTORE_PC;
+}
+
+int __kprobes arch_prepare_kprobe(struct kprobe *p)
+{
+	unsigned long probe_addr = (unsigned long)p->addr;
+
+	/* copy instruction */
+	p->opcode = le32_to_cpu(*p->addr);
+
+	if (in_exception_text(probe_addr))
+		return -EINVAL;
+
+	/* decode instruction */
+	switch (arm_kprobe_decode_insn(p->addr, &p->ainsn)) {
+	case INSN_REJECTED:	/* insn not supported */
+		return -EINVAL;
+
+	case INSN_GOOD_NO_SLOT:	/* insn need simulation */
+		return -EINVAL;
+
+	case INSN_GOOD:	/* instruction uses slot */
+		p->ainsn.insn = get_insn_slot();
+		if (!p->ainsn.insn)
+			return -ENOMEM;
+		break;
+	};
+
+	/* prepare the instruction */
+	arch_prepare_ss_slot(p);
+
+	return 0;
+}
+
+static int __kprobes patch_text(kprobe_opcode_t *addr, u32 opcode)
+{
+	void *addrs[1];
+	u32 insns[1];
+
+	addrs[0] = (void *)addr;
+	insns[0] = (u32)opcode;
+
+	return aarch64_insn_patch_text(addrs, insns, 1);
+}
+
+/* arm kprobe: install breakpoint in text */
+void __kprobes arch_arm_kprobe(struct kprobe *p)
+{
+	patch_text(p->addr, BRK64_OPCODE_KPROBES);
+}
+
+/* disarm kprobe: remove breakpoint from text */
+void __kprobes arch_disarm_kprobe(struct kprobe *p)
+{
+	patch_text(p->addr, p->opcode);
+}
+
+void __kprobes arch_remove_kprobe(struct kprobe *p)
+{
+	if (p->ainsn.insn) {
+		free_insn_slot(p->ainsn.insn, 0);
+		p->ainsn.insn = NULL;
+	}
+}
+
+static void __kprobes save_previous_kprobe(struct kprobe_ctlblk *kcb)
+{
+	kcb->prev_kprobe.kp = kprobe_running();
+	kcb->prev_kprobe.status = kcb->kprobe_status;
+}
+
+static void __kprobes restore_previous_kprobe(struct kprobe_ctlblk *kcb)
+{
+	__this_cpu_write(current_kprobe, kcb->prev_kprobe.kp);
+	kcb->kprobe_status = kcb->prev_kprobe.status;
+}
+
+static void __kprobes set_current_kprobe(struct kprobe *p)
+{
+	__this_cpu_write(current_kprobe, p);
+}
+
+/*
+ * The D-flag (Debug mask) is set (masked) upon deug exception entry.
+ * Kprobes needs to clear (unmask) D-flag -ONLY- in case of recursive
+ * probe i.e. when probe hit from kprobe handler context upon
+ * executing the pre/post handlers. In this case we return with
+ * D-flag clear so that single-stepping can be carried-out.
+ *
+ * Leave D-flag set in all other cases.
+ */
+static void __kprobes
+spsr_set_debug_flag(struct pt_regs *regs, int mask)
+{
+	unsigned long spsr = regs->pstate;
+
+	if (mask)
+		spsr |= PSR_D_BIT;
+	else
+		spsr &= ~PSR_D_BIT;
+
+	regs->pstate = spsr;
+}
+
+/*
+ * Interrupts need to be disabled before single-step mode is set, and not
+ * reenabled until after single-step mode ends.
+ * Without disabling interrupt on local CPU, there is a chance of
+ * interrupt occurrence in the period of exception return and  start of
+ * out-of-line single-step, that result in wrongly single stepping
+ * into the interrupt handler.
+ */
+static void __kprobes kprobes_save_local_irqflag(struct pt_regs *regs)
+{
+	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+
+	kcb->saved_irqflag = regs->pstate;
+	regs->pstate |= PSR_I_BIT;
+}
+
+static void __kprobes kprobes_restore_local_irqflag(struct pt_regs *regs)
+{
+	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+
+	if (kcb->saved_irqflag & PSR_I_BIT)
+		regs->pstate |= PSR_I_BIT;
+	else
+		regs->pstate &= ~PSR_I_BIT;
+}
+
+static void __kprobes
+set_ss_context(struct kprobe_ctlblk *kcb, unsigned long addr)
+{
+	kcb->ss_ctx.ss_pending = true;
+	kcb->ss_ctx.match_addr = addr + sizeof(kprobe_opcode_t);
+}
+
+static void __kprobes clear_ss_context(struct kprobe_ctlblk *kcb)
+{
+	kcb->ss_ctx.ss_pending = false;
+	kcb->ss_ctx.match_addr = 0;
+}
+
+static void __kprobes setup_singlestep(struct kprobe *p,
+				       struct pt_regs *regs,
+				       struct kprobe_ctlblk *kcb, int reenter)
+{
+	unsigned long slot;
+
+	if (reenter) {
+		save_previous_kprobe(kcb);
+		set_current_kprobe(p);
+		kcb->kprobe_status = KPROBE_REENTER;
+	} else {
+		kcb->kprobe_status = KPROBE_HIT_SS;
+	}
+
+	if (p->ainsn.insn) {
+		/* prepare for single stepping */
+		slot = (unsigned long)p->ainsn.insn;
+
+		set_ss_context(kcb, slot);	/* mark pending ss */
+
+		if (kcb->kprobe_status == KPROBE_REENTER)
+			spsr_set_debug_flag(regs, 0);
+
+		/* IRQs and single stepping do not mix well. */
+		kprobes_save_local_irqflag(regs);
+		kernel_enable_single_step(regs);
+		instruction_pointer(regs) = slot;
+	} else	{
+		BUG();
+	}
+}
+
+static int __kprobes reenter_kprobe(struct kprobe *p,
+				    struct pt_regs *regs,
+				    struct kprobe_ctlblk *kcb)
+{
+	switch (kcb->kprobe_status) {
+	case KPROBE_HIT_SSDONE:
+	case KPROBE_HIT_ACTIVE:
+		kprobes_inc_nmissed_count(p);
+		setup_singlestep(p, regs, kcb, 1);
+		break;
+	case KPROBE_HIT_SS:
+	case KPROBE_REENTER:
+		pr_warn("Unrecoverable kprobe detected at %p.\n", p->addr);
+		dump_kprobe(p);
+		BUG();
+		break;
+	default:
+		WARN_ON(1);
+		return 0;
+	}
+
+	return 1;
+}
+
+static void __kprobes
+post_kprobe_handler(struct kprobe_ctlblk *kcb, struct pt_regs *regs)
+{
+	struct kprobe *cur = kprobe_running();
+
+	if (!cur)
+		return;
+
+	/* return addr restore if non-branching insn */
+	if (cur->ainsn.restore.type == RESTORE_PC) {
+		instruction_pointer(regs) = cur->ainsn.restore.addr;
+		if (!instruction_pointer(regs))
+			BUG();
+	}
+
+	/* restore back original saved kprobe variables and continue */
+	if (kcb->kprobe_status == KPROBE_REENTER) {
+		restore_previous_kprobe(kcb);
+		return;
+	}
+	/* call post handler */
+	kcb->kprobe_status = KPROBE_HIT_SSDONE;
+	if (cur->post_handler)	{
+		/* post_handler can hit breakpoint and single step
+		 * again, so we enable D-flag for recursive exception.
+		 */
+		cur->post_handler(cur, regs, 0);
+	}
+
+	reset_current_kprobe();
+}
+
+int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
+{
+	struct kprobe *cur = kprobe_running();
+	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+
+	switch (kcb->kprobe_status) {
+	case KPROBE_HIT_SS:
+	case KPROBE_REENTER:
+		/*
+		 * We are here because the instruction being single
+		 * stepped caused a page fault. We reset the current
+		 * kprobe and the ip points back to the probe address
+		 * and allow the page fault handler to continue as a
+		 * normal page fault.
+		 */
+		instruction_pointer(regs) = (unsigned long)cur->addr;
+		if (!instruction_pointer(regs))
+			BUG();
+		if (kcb->kprobe_status == KPROBE_REENTER)
+			restore_previous_kprobe(kcb);
+		else
+			reset_current_kprobe();
+
+		break;
+	case KPROBE_HIT_ACTIVE:
+	case KPROBE_HIT_SSDONE:
+		/*
+		 * We increment the nmissed count for accounting,
+		 * we can also use npre/npostfault count for accounting
+		 * these specific fault cases.
+		 */
+		kprobes_inc_nmissed_count(cur);
+
+		/*
+		 * We come here because instructions in the pre/post
+		 * handler caused the page_fault, this could happen
+		 * if handler tries to access user space by
+		 * copy_from_user(), get_user() etc. Let the
+		 * user-specified handler try to fix it first.
+		 */
+		if (cur->fault_handler && cur->fault_handler(cur, regs, fsr))
+			return 1;
+
+		/*
+		 * In case the user-specified fault handler returned
+		 * zero, try to fix up.
+		 */
+		return 1;
+	}
+	return 0;
+}
+
+int __kprobes kprobe_exceptions_notify(struct notifier_block *self,
+				       unsigned long val, void *data)
+{
+	return NOTIFY_DONE;
+}
+
+static void __kprobes kprobe_handler(struct pt_regs *regs)
+{
+	struct kprobe *p, *cur_kprobe;
+	struct kprobe_ctlblk *kcb;
+	unsigned long addr = instruction_pointer(regs);
+
+	kcb = get_kprobe_ctlblk();
+	cur_kprobe = kprobe_running();
+
+	p = get_kprobe((kprobe_opcode_t *) addr);
+
+	if (p) {
+		if (cur_kprobe) {
+			if (reenter_kprobe(p, regs, kcb))
+				return;
+		} else {
+			/* Probe hit */
+			set_current_kprobe(p);
+			kcb->kprobe_status = KPROBE_HIT_ACTIVE;
+
+			/*
+			 * If we have no pre-handler or it returned 0, we
+			 * continue with normal processing.  If we have a
+			 * pre-handler and it returned non-zero, it prepped
+			 * for calling the break_handler below on re-entry,
+			 * so get out doing nothing more here.
+			 *
+			 * pre_handler can hit a breakpoint and can step thru
+			 * before return, keep PSTATE D-flag enabled until
+			 * pre_handler return back.
+			 */
+			if (!p->pre_handler || !p->pre_handler(p, regs)) {
+				kcb->kprobe_status = KPROBE_HIT_SS;
+				setup_singlestep(p, regs, kcb, 0);
+				return;
+			}
+		}
+	} else if ((le32_to_cpu(*(kprobe_opcode_t *) addr) ==
+	    BRK64_OPCODE_KPROBES) && cur_kprobe) {
+		/* We probably hit a jprobe.  Call its break handler. */
+		if (cur_kprobe->break_handler  &&
+		     cur_kprobe->break_handler(cur_kprobe, regs)) {
+			kcb->kprobe_status = KPROBE_HIT_SS;
+			setup_singlestep(cur_kprobe, regs, kcb, 0);
+			return;
+		}
+	}
+	/*
+	 * The breakpoint instruction was removed right
+	 * after we hit it.  Another cpu has removed
+	 * either a probepoint or a debugger breakpoint
+	 * at this address.  In either case, no further
+	 * handling of this interrupt is appropriate.
+	 * Return back to original instruction, and continue.
+	 */
+}
+
+static int __kprobes
+kprobe_ss_hit(struct kprobe_ctlblk *kcb, unsigned long addr)
+{
+	if ((kcb->ss_ctx.ss_pending)
+	    && (kcb->ss_ctx.match_addr == addr)) {
+		clear_ss_context(kcb);	/* clear pending ss */
+		return DBG_HOOK_HANDLED;
+	}
+	/* not ours, kprobes should ignore it */
+	return DBG_HOOK_ERROR;
+}
+
+int __kprobes
+kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr)
+{
+	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+	int retval;
+
+	/* return error if this is not our step */
+	retval = kprobe_ss_hit(kcb, instruction_pointer(regs));
+
+	if (retval == DBG_HOOK_HANDLED) {
+		kprobes_restore_local_irqflag(regs);
+		kernel_disable_single_step();
+
+		if (kcb->kprobe_status == KPROBE_REENTER)
+			spsr_set_debug_flag(regs, 1);
+
+		post_kprobe_handler(kcb, regs);
+	}
+
+	return retval;
+}
+
+int __kprobes
+kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr)
+{
+	kprobe_handler(regs);
+	return DBG_HOOK_HANDLED;
+}
+
+int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs)
+{
+	struct jprobe *jp = container_of(p, struct jprobe, kp);
+	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+	long stack_ptr = kernel_stack_pointer(regs);
+
+	kcb->jprobe_saved_regs = *regs;
+	memcpy(kcb->jprobes_stack, (void *)stack_ptr,
+	       MIN_STACK_SIZE(stack_ptr));
+
+	instruction_pointer(regs) = (long)jp->entry;
+	preempt_disable();
+	return 1;
+}
+
+void __kprobes jprobe_return(void)
+{
+	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+
+	/*
+	 * Jprobe handler return by entering break exception,
+	 * encoded same as kprobe, but with following conditions
+	 * -a magic number in x0 to identify from rest of other kprobes.
+	 * -restore stack addr to original saved pt_regs
+	 */
+	asm volatile ("ldr x0, [%0]\n\t"
+		      "mov sp, x0\n\t"
+		      ".globl jprobe_return_break\n\t"
+		      "jprobe_return_break:\n\t"
+		      "brk %1\n\t"
+		      :
+		      : "r"(&kcb->jprobe_saved_regs.sp),
+		      "I"(BRK64_ESR_KPROBES)
+		      : "memory");
+}
+
+int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
+{
+	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+	long stack_addr = kcb->jprobe_saved_regs.sp;
+	long orig_sp = kernel_stack_pointer(regs);
+	struct jprobe *jp = container_of(p, struct jprobe, kp);
+
+	if (instruction_pointer(regs) != (u64) jprobe_return_break)
+		return 0;
+
+	if (orig_sp != stack_addr) {
+		struct pt_regs *saved_regs =
+		    (struct pt_regs *)kcb->jprobe_saved_regs.sp;
+		pr_err("current sp %lx does not match saved sp %lx\n",
+		       orig_sp, stack_addr);
+		pr_err("Saved registers for jprobe %p\n", jp);
+		show_regs(saved_regs);
+		pr_err("Current registers\n");
+		show_regs(regs);
+		BUG();
+	}
+	*regs = kcb->jprobe_saved_regs;
+	memcpy((void *)stack_addr, kcb->jprobes_stack,
+	       MIN_STACK_SIZE(stack_addr));
+	preempt_enable_no_resched();
+	return 1;
+}
+
+int __init arch_init_kprobes(void)
+{
+	return 0;
+}
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index e3928f5..5a163a6 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -105,6 +105,7 @@ SECTIONS
 			TEXT_TEXT
 			SCHED_TEXT
 			LOCK_TEXT
+			KPROBES_TEXT
 			HYPERVISOR_TEXT
 			IDMAP_TEXT
 			*(.fixup)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 92ddac1..5ce28de 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -41,6 +41,28 @@
 
 static const char *fault_name(unsigned int esr);
 
+#ifdef CONFIG_KPROBES
+static inline int notify_page_fault(struct pt_regs *regs, unsigned int esr)
+{
+	int ret = 0;
+
+	/* kprobe_running() needs smp_processor_id() */
+	if (!user_mode(regs)) {
+		preempt_disable();
+		if (kprobe_running() && kprobe_fault_handler(regs, esr))
+			ret = 1;
+		preempt_enable();
+	}
+
+	return ret;
+}
+#else
+static inline int notify_page_fault(struct pt_regs *regs, unsigned int esr)
+{
+	return 0;
+}
+#endif
+
 /*
  * Dump out the page tables associated with 'addr' in mm 'mm'.
  */
@@ -201,6 +223,9 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr,
 	unsigned long vm_flags = VM_READ | VM_WRITE | VM_EXEC;
 	unsigned int mm_flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
 
+	if (notify_page_fault(regs, esr))
+		return 0;
+
 	tsk = current;
 	mm  = tsk->mm;
 
-- 
2.5.0



From dave.long at linaro.org  Thu Feb 18 15:48:18 2016
From: dave.long at linaro.org (David Long)
Date: Thu, 18 Feb 2016 18:48:18 -0500
Subject: [PATCH 5/8] arm64: kprobes instruction simulation support
In-Reply-To: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
References: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
Message-ID: <1455839301-26464-6-git-send-email-dave.long@linaro.org>

From: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>

Kprobes needs simulation of instructions that cannot be stepped
from different memory location, e.g.: those instructions
that uses PC-relative addressing. In simulation, the behaviour
of the instruction is implemented using a copy of pt_regs.

Following instruction catagories are simulated:
 - All branching instructions(conditional, register, and immediate)
 - Literal access instructions(load-literal, adr/adrp)

Conditional execution is limited to branching instructions in
ARM v8. If conditions at PSTATE do not match the condition fields
of opcode, the instruction is effectively NOP. Kprobes considers
this case as 'miss'.

This code also replaces the use of arch/arm/opcodes.c for
arm_check_condition().

Thanks to Will Cohen for assorted suggested changes.

Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>
Signed-off-by: William Cohen <wcohen at redhat.com>
Signed-off-by: David A. Long <dave.long at linaro.org>
---
 arch/arm64/include/asm/insn.h            |   3 +
 arch/arm64/include/asm/probes.h          |   5 +-
 arch/arm64/kernel/Makefile               |   6 +-
 arch/arm64/kernel/insn.c                 | 111 ++++++++++++++++++
 arch/arm64/kernel/kprobes-arm64.c        |  29 +++++
 arch/arm64/kernel/kprobes.c              |  32 +++++-
 arch/arm64/kernel/probes-simulate-insn.c | 187 +++++++++++++++++++++++++++++++
 arch/arm64/kernel/probes-simulate-insn.h |  30 +++++
 8 files changed, 395 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm64/kernel/probes-simulate-insn.c
 create mode 100644 arch/arm64/kernel/probes-simulate-insn.h

diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index cf43773..2cac976 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -407,6 +407,9 @@ u32 aarch64_insn_extract_system_reg(u32 insn);
 u32 aarch32_insn_extract_reg_num(u32 insn, int offset);
 u32 aarch32_insn_mcr_extract_opc2(u32 insn);
 u32 aarch32_insn_mcr_extract_crm(u32 insn);
+
+typedef unsigned long (pstate_check_t)(unsigned long);
+
 #endif /* __ASSEMBLY__ */
 
 #endif	/* __ASM_INSN_H */
diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
index c5fcbe6..d524f7d 100644
--- a/arch/arm64/include/asm/probes.h
+++ b/arch/arm64/include/asm/probes.h
@@ -15,11 +15,12 @@
 #ifndef _ARM_PROBES_H
 #define _ARM_PROBES_H
 
+#include <asm/opcodes.h>
+
 struct kprobe;
 struct arch_specific_insn;
 
 typedef u32 kprobe_opcode_t;
-typedef unsigned long (kprobes_pstate_check_t)(unsigned long);
 typedef void (kprobes_handler_t) (u32 opcode, long addr, struct pt_regs *);
 
 enum pc_restore_type {
@@ -35,7 +36,7 @@ struct kprobe_pc_restore {
 /* architecture specific copy of original instruction */
 struct arch_specific_insn {
 	kprobe_opcode_t *insn;
-	kprobes_pstate_check_t *pstate_cc;
+	pstate_check_t *pstate_cc;
 	kprobes_handler_t *handler;
 	/* restore address after step xol */
 	struct kprobe_pc_restore restore;
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 5b0ee7d..08325e5 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -26,8 +26,7 @@ $(obj)/%.stub.o: $(obj)/%.o FORCE
 	$(call if_changed,objcopy)
 
 arm64-obj-$(CONFIG_COMPAT)		+= sys32.o kuser32.o signal32.o 	\
-					   sys_compat.o entry32.o		\
-					   ../../arm/kernel/opcodes.o
+					   sys_compat.o entry32.o
 arm64-obj-$(CONFIG_FUNCTION_TRACER)	+= ftrace.o entry-ftrace.o
 arm64-obj-$(CONFIG_MODULES)		+= arm64ksyms.o module.o
 arm64-obj-$(CONFIG_PERF_EVENTS)		+= perf_regs.o perf_callchain.o
@@ -37,7 +36,8 @@ arm64-obj-$(CONFIG_CPU_PM)		+= sleep.o suspend.o
 arm64-obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
 arm64-obj-$(CONFIG_JUMP_LABEL)		+= jump_label.o
 arm64-obj-$(CONFIG_KGDB)		+= kgdb.o
-arm64-obj-$(CONFIG_KPROBES)		+= kprobes.o kprobes-arm64.o
+arm64-obj-$(CONFIG_KPROBES)		+= kprobes.o kprobes-arm64.o		\
+					   probes-simulate-insn.o
 arm64-obj-$(CONFIG_EFI)			+= efi.o efi-entry.stub.o
 arm64-obj-$(CONFIG_PCI)			+= pci.o
 arm64-obj-$(CONFIG_ARMV8_DEPRECATED)	+= armv8_deprecated.o
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 60c1c71..74a08db 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -30,6 +30,7 @@
 #include <asm/cacheflush.h>
 #include <asm/debug-monitors.h>
 #include <asm/fixmap.h>
+#include <asm/opcodes.h>
 #include <asm/insn.h>
 
 #define AARCH64_INSN_SF_BIT	BIT(31)
@@ -1234,3 +1235,113 @@ u32 aarch32_insn_mcr_extract_crm(u32 insn)
 {
 	return insn & CRM_MASK;
 }
+
+#define	ARM_OPCODE_CONDITION_UNCOND	0xf
+
+static unsigned long __kprobes __check_eq(unsigned long pstate)
+{
+	return pstate & PSR_Z_BIT;
+}
+
+static unsigned long __kprobes __check_ne(unsigned long pstate)
+{
+	return (~pstate) & PSR_Z_BIT;
+}
+
+static unsigned long __kprobes __check_cs(unsigned long pstate)
+{
+	return pstate & PSR_C_BIT;
+}
+
+static unsigned long __kprobes __check_cc(unsigned long pstate)
+{
+	return (~pstate) & PSR_C_BIT;
+}
+
+static unsigned long __kprobes __check_mi(unsigned long pstate)
+{
+	return pstate & PSR_N_BIT;
+}
+
+static unsigned long __kprobes __check_pl(unsigned long pstate)
+{
+	return (~pstate) & PSR_N_BIT;
+}
+
+static unsigned long __kprobes __check_vs(unsigned long pstate)
+{
+	return pstate & PSR_V_BIT;
+}
+
+static unsigned long __kprobes __check_vc(unsigned long pstate)
+{
+	return (~pstate) & PSR_V_BIT;
+}
+
+static unsigned long __kprobes __check_hi(unsigned long pstate)
+{
+	pstate &= ~(pstate >> 1);	/* PSR_C_BIT &= ~PSR_Z_BIT */
+	return pstate & PSR_C_BIT;
+}
+
+static unsigned long __kprobes __check_ls(unsigned long pstate)
+{
+	pstate &= ~(pstate >> 1);	/* PSR_C_BIT &= ~PSR_Z_BIT */
+	return (~pstate) & PSR_C_BIT;
+}
+
+static unsigned long __kprobes __check_ge(unsigned long pstate)
+{
+	pstate ^= (pstate << 3);	/* PSR_N_BIT ^= PSR_V_BIT */
+	return (~pstate) & PSR_N_BIT;
+}
+
+static unsigned long __kprobes __check_lt(unsigned long pstate)
+{
+	pstate ^= (pstate << 3);	/* PSR_N_BIT ^= PSR_V_BIT */
+	return pstate & PSR_N_BIT;
+}
+
+static unsigned long __kprobes __check_gt(unsigned long pstate)
+{
+	/*PSR_N_BIT ^= PSR_V_BIT */
+	unsigned long temp = pstate ^ (pstate << 3);
+
+	temp |= (pstate << 1);	/*PSR_N_BIT |= PSR_Z_BIT */
+	return (~temp) & PSR_N_BIT;
+}
+
+static unsigned long __kprobes __check_le(unsigned long pstate)
+{
+	/*PSR_N_BIT ^= PSR_V_BIT */
+	unsigned long temp = pstate ^ (pstate << 3);
+
+	temp |= (pstate << 1);	/*PSR_N_BIT |= PSR_Z_BIT */
+	return temp & PSR_N_BIT;
+}
+
+static unsigned long __kprobes __check_al(unsigned long pstate)
+{
+	return true;
+}
+
+pstate_check_t * const opcode_condition_checks[16] = {
+	&__check_eq, &__check_ne, &__check_cs, &__check_cc,
+	&__check_mi, &__check_pl, &__check_vs, &__check_vc,
+	&__check_hi, &__check_ls, &__check_ge, &__check_lt,
+	&__check_gt, &__check_le, &__check_al, &__check_al
+};
+
+asmlinkage unsigned int __kprobes arm_check_condition(u32 opcode, u32 psr)
+{
+	u32 cc_bits  = opcode >> 28;
+
+	if (cc_bits != ARM_OPCODE_CONDITION_UNCOND) {
+		if ((*opcode_condition_checks[cc_bits])(psr))
+			return ARM_OPCODE_CONDTEST_PASS;
+		else
+			return ARM_OPCODE_CONDTEST_FAIL;
+	}
+	return ARM_OPCODE_CONDTEST_UNCOND;
+}
+EXPORT_SYMBOL_GPL(arm_check_condition);
diff --git a/arch/arm64/kernel/kprobes-arm64.c b/arch/arm64/kernel/kprobes-arm64.c
index e07727a..487238a 100644
--- a/arch/arm64/kernel/kprobes-arm64.c
+++ b/arch/arm64/kernel/kprobes-arm64.c
@@ -21,6 +21,7 @@
 #include <asm/sections.h>
 
 #include "kprobes-arm64.h"
+#include "probes-simulate-insn.h"
 
 static bool __kprobes aarch64_insn_is_steppable(u32 insn)
 {
@@ -62,8 +63,36 @@ arm_probe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi)
 	 */
 	if (aarch64_insn_is_steppable(insn))
 		return INSN_GOOD;
+
+	if (aarch64_insn_is_bcond(insn)) {
+		asi->handler = simulate_b_cond;
+	} else if (aarch64_insn_is_cbz(insn) ||
+	    aarch64_insn_is_cbnz(insn)) {
+		asi->handler = simulate_cbz_cbnz;
+	} else if (aarch64_insn_is_tbz(insn) ||
+	    aarch64_insn_is_tbnz(insn)) {
+		asi->handler = simulate_tbz_tbnz;
+	} else if (aarch64_insn_is_adr_adrp(insn))
+		asi->handler = simulate_adr_adrp;
+	else if (aarch64_insn_is_b(insn) ||
+	    aarch64_insn_is_bl(insn))
+		asi->handler = simulate_b_bl;
+	else if (aarch64_insn_is_br(insn) ||
+	    aarch64_insn_is_blr(insn) ||
+	    aarch64_insn_is_ret(insn))
+		asi->handler = simulate_br_blr_ret;
+	else if (aarch64_insn_is_ldr_lit(insn))
+		asi->handler = simulate_ldr_literal;
+	else if (aarch64_insn_is_ldrsw_lit(insn))
+		asi->handler = simulate_ldrsw_literal;
 	else
+		/*
+		 * Instruction cannot be stepped out-of-line and we don't
+		 * (yet) simulate it.
+		 */
 		return INSN_REJECTED;
+
+	return INSN_GOOD_NO_SLOT;
 }
 
 static bool __kprobes
diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
index 8db71a4..52f6c3d 100644
--- a/arch/arm64/kernel/kprobes.c
+++ b/arch/arm64/kernel/kprobes.c
@@ -40,6 +40,9 @@ void jprobe_return_break(void);
 DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
 DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
 
+static void __kprobes
+post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
+
 static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
 {
 	/* prepare insn slot */
@@ -57,6 +60,24 @@ static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
 	p->ainsn.restore.type = RESTORE_PC;
 }
 
+static void __kprobes arch_prepare_simulate(struct kprobe *p)
+{
+	/* This instructions is not executed xol. No need to adjust the PC */
+	p->ainsn.restore.addr = 0;
+	p->ainsn.restore.type = NO_RESTORE;
+}
+
+static void __kprobes arch_simulate_insn(struct kprobe *p, struct pt_regs *regs)
+{
+	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
+
+	if (p->ainsn.handler)
+		p->ainsn.handler((u32)p->opcode, (long)p->addr, regs);
+
+	/* single step simulated, now go for post processing */
+	post_kprobe_handler(kcb, regs);
+}
+
 int __kprobes arch_prepare_kprobe(struct kprobe *p)
 {
 	unsigned long probe_addr = (unsigned long)p->addr;
@@ -73,7 +94,8 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
 		return -EINVAL;
 
 	case INSN_GOOD_NO_SLOT:	/* insn need simulation */
-		return -EINVAL;
+		p->ainsn.insn = NULL;
+		break;
 
 	case INSN_GOOD:	/* instruction uses slot */
 		p->ainsn.insn = get_insn_slot();
@@ -83,7 +105,10 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
 	};
 
 	/* prepare the instruction */
-	arch_prepare_ss_slot(p);
+	if (p->ainsn.insn)
+		arch_prepare_ss_slot(p);
+	else
+		arch_prepare_simulate(p);
 
 	return 0;
 }
@@ -225,7 +250,8 @@ static void __kprobes setup_singlestep(struct kprobe *p,
 		kernel_enable_single_step(regs);
 		instruction_pointer(regs) = slot;
 	} else	{
-		BUG();
+		/* insn simulation */
+		arch_simulate_insn(p, regs);
 	}
 }
 
diff --git a/arch/arm64/kernel/probes-simulate-insn.c b/arch/arm64/kernel/probes-simulate-insn.c
new file mode 100644
index 0000000..dfcece9
--- /dev/null
+++ b/arch/arm64/kernel/probes-simulate-insn.c
@@ -0,0 +1,187 @@
+/*
+ * arch/arm64/kernel/probes-simulate-insn.c
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/kprobes.h>
+#include <linux/module.h>
+
+#include "probes-simulate-insn.h"
+
+#define sign_extend(x, signbit)		\
+	((x) | (0 - ((x) & (1 << (signbit)))))
+
+#define bbl_displacement(insn)		\
+	sign_extend(((insn) & 0x3ffffff) << 2, 27)
+
+#define bcond_displacement(insn)	\
+	sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
+
+#define cbz_displacement(insn)	\
+	sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
+
+#define tbz_displacement(insn)	\
+	sign_extend(((insn >> 5) & 0x3fff) << 2, 15)
+
+#define ldr_displacement(insn)	\
+	sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
+
+
+static unsigned long __kprobes check_cbz(u32 opcode, struct pt_regs *regs)
+{
+	int xn = opcode & 0x1f;
+
+	return (opcode & (1 << 31)) ?
+	    !(regs->regs[xn]) : !(regs->regs[xn] & 0xffffffff);
+}
+
+static unsigned long __kprobes check_cbnz(u32 opcode, struct pt_regs *regs)
+{
+	int xn = opcode & 0x1f;
+
+	return (opcode & (1 << 31)) ?
+	    (regs->regs[xn]) : (regs->regs[xn] & 0xffffffff);
+}
+
+static unsigned long __kprobes check_tbz(u32 opcode, struct pt_regs *regs)
+{
+	int xn = opcode & 0x1f;
+	int bit_pos = ((opcode & (1 << 31)) >> 26) | ((opcode >> 19) & 0x1f);
+
+	return !((regs->regs[xn] >> bit_pos) & 0x1);
+}
+
+static unsigned long __kprobes check_tbnz(u32 opcode, struct pt_regs *regs)
+{
+	int xn = opcode & 0x1f;
+	int bit_pos = ((opcode & (1 << 31)) >> 26) | ((opcode >> 19) & 0x1f);
+
+	return (regs->regs[xn] >> bit_pos) & 0x1;
+}
+
+/*
+ * instruction simulation functions
+ */
+void __kprobes
+simulate_adr_adrp(u32 opcode, long addr, struct pt_regs *regs)
+{
+	long imm, xn, val;
+
+	xn = opcode & 0x1f;
+	imm = ((opcode >> 3) & 0x1ffffc) | ((opcode >> 29) & 0x3);
+	imm = sign_extend(imm, 20);
+	if (opcode & 0x80000000)
+		val = (imm<<12) + (addr & 0xfffffffffffff000);
+	else
+		val = imm + addr;
+
+	regs->regs[xn] = val;
+
+	instruction_pointer(regs) += 4;
+}
+
+void __kprobes
+simulate_b_bl(u32 opcode, long addr, struct pt_regs *regs)
+{
+	int disp = bbl_displacement(opcode);
+
+	/* Link register is x30 */
+	if (opcode & (1 << 31))
+		regs->regs[30] = addr + 4;
+
+	instruction_pointer(regs) = addr + disp;
+}
+
+void __kprobes
+simulate_b_cond(u32 opcode, long addr, struct pt_regs *regs)
+{
+	int disp = 4;
+
+	if (opcode_condition_checks[opcode & 0xf](regs->pstate & 0xffffffff))
+		disp = bcond_displacement(opcode);
+
+	instruction_pointer(regs) = addr + disp;
+}
+
+void __kprobes
+simulate_br_blr_ret(u32 opcode, long addr, struct pt_regs *regs)
+{
+	int xn = (opcode >> 5) & 0x1f;
+
+	/* Link register is x30 */
+	if (((opcode >> 21) & 0x3) == 1)
+		regs->regs[30] = addr + 4;
+
+	instruction_pointer(regs) = regs->regs[xn];
+}
+
+void __kprobes
+simulate_cbz_cbnz(u32 opcode, long addr, struct pt_regs *regs)
+{
+	int disp = 4;
+
+	if (opcode & (1 << 24)) {
+		if (check_cbnz(opcode, regs))
+			disp = cbz_displacement(opcode);
+	} else {
+		if (check_cbz(opcode, regs))
+			disp = cbz_displacement(opcode);
+	}
+	instruction_pointer(regs) = addr + disp;
+}
+
+void __kprobes
+simulate_tbz_tbnz(u32 opcode, long addr, struct pt_regs *regs)
+{
+	int disp = 4;
+
+	if (opcode & (1 << 24)) {
+		if (check_tbnz(opcode, regs))
+			disp = tbz_displacement(opcode);
+	} else {
+		if (check_tbz(opcode, regs))
+			disp = tbz_displacement(opcode);
+	}
+	instruction_pointer(regs) = addr + disp;
+}
+
+void __kprobes
+simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs)
+{
+	u64 *load_addr;
+	int xn = opcode & 0x1f;
+	int disp = ldr_displacement(opcode);
+
+	load_addr = (u64 *) (addr + disp);
+
+	if (opcode & (1 << 30))	/* x0-x31 */
+		regs->regs[xn] = *load_addr;
+	else			/* w0-w31 */
+		*(u32 *) (&regs->regs[xn]) = (*(u32 *) (load_addr));
+
+	instruction_pointer(regs) += 4;
+}
+
+void __kprobes
+simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs)
+{
+	s32 *load_addr;
+	int xn = opcode & 0x1f;
+	int disp = ldr_displacement(opcode);
+
+	load_addr = (s32 *) (addr + disp);
+	regs->regs[xn] = *load_addr;
+
+	instruction_pointer(regs) += 4;
+}
diff --git a/arch/arm64/kernel/probes-simulate-insn.h b/arch/arm64/kernel/probes-simulate-insn.h
new file mode 100644
index 0000000..337384e
--- /dev/null
+++ b/arch/arm64/kernel/probes-simulate-insn.h
@@ -0,0 +1,30 @@
+/*
+ * arch/arm64/kernel/probes-simulate-insn.h
+ *
+ * Copyright (C) 2013 Linaro Limited
+ *
+ * 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.
+ */
+
+#ifndef _ARM_KERNEL_PROBES_SIMULATE_INSN_H
+#define _ARM_KERNEL_PROBES_SIMULATE_INSN_H
+
+extern pstate_check_t * const opcode_condition_checks[16];
+
+void simulate_adr_adrp(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_b_bl(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_b_cond(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_br_blr_ret(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_cbz_cbnz(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_tbz_tbnz(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs);
+void simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs);
+
+#endif /* _ARM_KERNEL_PROBES_SIMULATE_INSN_H */
-- 
2.5.0



From dave.long at linaro.org  Thu Feb 18 15:48:21 2016
From: dave.long at linaro.org (David Long)
Date: Thu, 18 Feb 2016 18:48:21 -0500
Subject: [PATCH 8/8] kprobes: Add arm64 case in kprobe example module
In-Reply-To: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
References: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
Message-ID: <1455839301-26464-9-git-send-email-dave.long@linaro.org>

From: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>

Add info prints in sample kprobe handlers for ARM64

Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>
---
 samples/kprobes/kprobe_example.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
index 727eb21..0c72b8a 100644
--- a/samples/kprobes/kprobe_example.c
+++ b/samples/kprobes/kprobe_example.c
@@ -42,6 +42,10 @@ static int handler_pre(struct kprobe *p, struct pt_regs *regs)
 			" ex1 = 0x%lx\n",
 		p->addr, regs->pc, regs->ex1);
 #endif
+#ifdef CONFIG_ARM64
+	pr_info("pre_handler: p->addr = 0x%p, pc = 0x%lx\n",
+		p->addr, (long)regs->pc);
+#endif
 
 	/* A dump_stack() here will give a stack backtrace */
 	return 0;
@@ -67,6 +71,10 @@ static void handler_post(struct kprobe *p, struct pt_regs *regs,
 	printk(KERN_INFO "post_handler: p->addr = 0x%p, ex1 = 0x%lx\n",
 		p->addr, regs->ex1);
 #endif
+#ifdef CONFIG_ARM64
+	pr_info("post_handler: p->addr = 0x%p, pc = 0x%lx\n",
+		p->addr, (long)regs->pc);
+#endif
 }
 
 /*
-- 
2.5.0



From dave.long at linaro.org  Thu Feb 18 15:48:20 2016
From: dave.long at linaro.org (David Long)
Date: Thu, 18 Feb 2016 18:48:20 -0500
Subject: [PATCH 7/8] arm64: Add kernel return probes support (kretprobes)
In-Reply-To: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
References: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
Message-ID: <1455839301-26464-8-git-send-email-dave.long@linaro.org>

From: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>

The pre-handler of this special 'trampoline' kprobe executes the return
probe handler functions and restores original return address in ELR_EL1.
This way the saved pt_regs still hold the original register context to be
carried back to the probed kernel function.

Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>
Signed-off-by: David A. Long <dave.long at linaro.org>
---
 arch/arm64/Kconfig          |  1 +
 arch/arm64/kernel/kprobes.c | 75 ++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c395386..72412de 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -82,6 +82,7 @@ config ARM64
 	select HAVE_RCU_TABLE_FREE
 	select HAVE_SYSCALL_TRACEPOINTS
 	select HAVE_KPROBES
+	select HAVE_KRETPROBES if HAVE_KPROBES
 	select IOMMU_DMA if IOMMU_SUPPORT
 	select IRQ_DOMAIN
 	select IRQ_FORCED_THREADING
diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
index 0ce4637..a699d03 100644
--- a/arch/arm64/kernel/kprobes.c
+++ b/arch/arm64/kernel/kprobes.c
@@ -533,7 +533,80 @@ int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
 
 void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs)
 {
-	return (void *) 0;
+	struct kretprobe_instance *ri = NULL;
+	struct hlist_head *head, empty_rp;
+	struct hlist_node *tmp;
+	unsigned long flags, orig_ret_addr = 0;
+	unsigned long trampoline_address =
+		(unsigned long)&kretprobe_trampoline;
+
+	INIT_HLIST_HEAD(&empty_rp);
+	kretprobe_hash_lock(current, &head, &flags);
+
+	/*
+	 * It is possible to have multiple instances associated with a given
+	 * task either because multiple functions in the call path have
+	 * a return probe installed on them, and/or more than one return
+	 * probe was registered for a target function.
+	 *
+	 * We can handle this because:
+	 *     - instances are always inserted at the head of the list
+	 *     - when multiple return probes are registered for the same
+	 *       function, the first instance's ret_addr will point to the
+	 *       real return address, and all the rest will point to
+	 *       kretprobe_trampoline
+	 */
+	hlist_for_each_entry_safe(ri, tmp, head, hlist) {
+		if (ri->task != current)
+			/* another task is sharing our hash bucket */
+			continue;
+
+		if (ri->rp && ri->rp->handler) {
+			__this_cpu_write(current_kprobe, &ri->rp->kp);
+			get_kprobe_ctlblk()->kprobe_status = KPROBE_HIT_ACTIVE;
+			ri->rp->handler(ri, regs);
+			__this_cpu_write(current_kprobe, NULL);
+		}
+
+		orig_ret_addr = (unsigned long)ri->ret_addr;
+		recycle_rp_inst(ri, &empty_rp);
+
+		if (orig_ret_addr != trampoline_address)
+			/*
+			 * This is the real return address. Any other
+			 * instances associated with this task are for
+			 * other calls deeper on the call stack
+			 */
+			break;
+	}
+
+	kretprobe_assert(ri, orig_ret_addr, trampoline_address);
+	/* restore the original return address */
+	instruction_pointer(regs) = orig_ret_addr;
+	reset_current_kprobe();
+	kretprobe_hash_unlock(current, &flags);
+
+	hlist_for_each_entry_safe(ri, tmp, &empty_rp, hlist) {
+		hlist_del(&ri->hlist);
+		kfree(ri);
+	}
+
+	/* return 1 so that post handlers not called */
+	return (void *) orig_ret_addr;
+}
+
+void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri,
+				      struct pt_regs *regs)
+{
+	ri->ret_addr = (kprobe_opcode_t *)regs->regs[30];
+
+	/* replace return addr (x30) with trampoline */
+	regs->regs[30] = (long)&kretprobe_trampoline;
+}
+
+int __kprobes arch_trampoline_kprobe(struct kprobe *p)
+{
+	return 0;
 }
 
 int __init arch_init_kprobes(void)
-- 
2.5.0



From dave.long at linaro.org  Thu Feb 18 15:48:19 2016
From: dave.long at linaro.org (David Long)
Date: Thu, 18 Feb 2016 18:48:19 -0500
Subject: [PATCH 6/8] arm64: Add trampoline code for kretprobes
In-Reply-To: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
References: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
Message-ID: <1455839301-26464-7-git-send-email-dave.long@linaro.org>

From: William Cohen <wcohen at redhat.com>

The trampoline code is used by kretprobes to capture a return from a probed
function.  This is done by saving the registers, calling the handler, and
restoring the registers.  The code then returns to the original saved caller
return address.  It is necessary to do this directly instead of using a
software breakpoint because the code used in processing that breakpoint
could itself be kprobe'd and cause a problematic reentry into the debug
exception handler.

Signed-off-by: William Cohen <wcohen at redhat.com>
Signed-off-by: David A. Long <dave.long at linaro.org>
---
 arch/arm64/include/asm/kprobes.h       |  2 +
 arch/arm64/kernel/Makefile             |  1 +
 arch/arm64/kernel/asm-offsets.c        | 22 +++++++++++
 arch/arm64/kernel/kprobes.c            |  5 +++
 arch/arm64/kernel/kprobes_trampoline.S | 67 ++++++++++++++++++++++++++++++++++
 5 files changed, 97 insertions(+)
 create mode 100644 arch/arm64/kernel/kprobes_trampoline.S

diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
index 79c9511..61b4915 100644
--- a/arch/arm64/include/asm/kprobes.h
+++ b/arch/arm64/include/asm/kprobes.h
@@ -56,5 +56,7 @@ int kprobe_exceptions_notify(struct notifier_block *self,
 			     unsigned long val, void *data);
 int kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr);
 int kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr);
+void kretprobe_trampoline(void);
+void __kprobes *trampoline_probe_handler(struct pt_regs *regs);
 
 #endif /* _ARM_KPROBES_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 08325e5..f192b7d 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -37,6 +37,7 @@ arm64-obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
 arm64-obj-$(CONFIG_JUMP_LABEL)		+= jump_label.o
 arm64-obj-$(CONFIG_KGDB)		+= kgdb.o
 arm64-obj-$(CONFIG_KPROBES)		+= kprobes.o kprobes-arm64.o		\
+					   kprobes_trampoline.o			\
 					   probes-simulate-insn.o
 arm64-obj-$(CONFIG_EFI)			+= efi.o efi-entry.stub.o
 arm64-obj-$(CONFIG_PCI)			+= pci.o
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index fffa4ac6..460b54c 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -50,6 +50,28 @@ int main(void)
   DEFINE(S_X5,			offsetof(struct pt_regs, regs[5]));
   DEFINE(S_X6,			offsetof(struct pt_regs, regs[6]));
   DEFINE(S_X7,			offsetof(struct pt_regs, regs[7]));
+  DEFINE(S_X8,			offsetof(struct pt_regs, regs[8]));
+  DEFINE(S_X9,			offsetof(struct pt_regs, regs[9]));
+  DEFINE(S_X10,			offsetof(struct pt_regs, regs[10]));
+  DEFINE(S_X11,			offsetof(struct pt_regs, regs[11]));
+  DEFINE(S_X12,			offsetof(struct pt_regs, regs[12]));
+  DEFINE(S_X13,			offsetof(struct pt_regs, regs[13]));
+  DEFINE(S_X14,			offsetof(struct pt_regs, regs[14]));
+  DEFINE(S_X15,			offsetof(struct pt_regs, regs[15]));
+  DEFINE(S_X16,			offsetof(struct pt_regs, regs[16]));
+  DEFINE(S_X17,			offsetof(struct pt_regs, regs[17]));
+  DEFINE(S_X18,			offsetof(struct pt_regs, regs[18]));
+  DEFINE(S_X19,			offsetof(struct pt_regs, regs[19]));
+  DEFINE(S_X20,			offsetof(struct pt_regs, regs[20]));
+  DEFINE(S_X21,			offsetof(struct pt_regs, regs[21]));
+  DEFINE(S_X22,			offsetof(struct pt_regs, regs[22]));
+  DEFINE(S_X23,			offsetof(struct pt_regs, regs[23]));
+  DEFINE(S_X24,			offsetof(struct pt_regs, regs[24]));
+  DEFINE(S_X25,			offsetof(struct pt_regs, regs[25]));
+  DEFINE(S_X26,			offsetof(struct pt_regs, regs[26]));
+  DEFINE(S_X27,			offsetof(struct pt_regs, regs[27]));
+  DEFINE(S_X28,			offsetof(struct pt_regs, regs[28]));
+  DEFINE(S_X29,			offsetof(struct pt_regs, regs[29]));
   DEFINE(S_LR,			offsetof(struct pt_regs, regs[30]));
   DEFINE(S_SP,			offsetof(struct pt_regs, sp));
 #ifdef CONFIG_COMPAT
diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
index 52f6c3d..0ce4637 100644
--- a/arch/arm64/kernel/kprobes.c
+++ b/arch/arm64/kernel/kprobes.c
@@ -531,6 +531,11 @@ int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs)
 	return 1;
 }
 
+void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs)
+{
+	return (void *) 0;
+}
+
 int __init arch_init_kprobes(void)
 {
 	return 0;
diff --git a/arch/arm64/kernel/kprobes_trampoline.S b/arch/arm64/kernel/kprobes_trampoline.S
new file mode 100644
index 0000000..5a336cf
--- /dev/null
+++ b/arch/arm64/kernel/kprobes_trampoline.S
@@ -0,0 +1,67 @@
+/*
+ * trampoline entry and return code for kretprobes.
+ */
+
+#include <linux/linkage.h>
+#include <generated/asm-offsets.h>
+
+	.text
+
+ENTRY(kretprobe_trampoline)
+
+	sub sp, sp, #S_FRAME_SIZE
+
+	stp x0, x1, [sp, #S_X0]
+	stp x2, x3, [sp, #S_X2]
+	stp x4, x5, [sp, #S_X4]
+	stp x6, x7, [sp, #S_X6]
+	stp x8, x9, [sp, #S_X8]
+	stp x10, x11, [sp, #S_X10]
+	stp x12, x13, [sp, #S_X12]
+	stp x14, x15, [sp, #S_X14]
+	stp x16, x17, [sp, #S_X16]
+	stp x18, x19, [sp, #S_X18]
+	stp x20, x21, [sp, #S_X20]
+	stp x22, x23, [sp, #S_X22]
+	stp x24, x25, [sp, #S_X24]
+	stp x26, x27, [sp, #S_X26]
+	stp x28, x29, [sp, #S_X28]
+	str x30, [sp, #S_LR]
+	add x0, sp, #S_FRAME_SIZE
+	str x0, [sp, #S_SP]
+	mrs x0, nzcv
+	mrs x1, daif
+	orr x0, x0, x1
+	/* There seems no easy way to get the mode field so make one up */
+	add x0, x0, #5
+	str x0, [sp, #S_PSTATE]
+
+	mov x0, sp
+	bl trampoline_probe_handler
+	/* Replace trampoline address in lr with actual
+	   orig_ret_addr return address. */
+	str x0, [sp, #S_LR]
+
+	ldr x0, [sp, #S_PSTATE]
+	msr nzcv, x0
+	ldp x0, x1, [sp, #S_X0]
+	ldp x2, x3, [sp, #S_X2]
+	ldp x4, x5, [sp, #S_X4]
+	ldp x6, x7, [sp, #S_X6]
+	ldp x8, x9, [sp, #S_X8]
+	ldp x10, x11, [sp, #S_X10]
+	ldp x12, x13, [sp, #S_X12]
+	ldp x14, x15, [sp, #S_X14]
+	ldp x16, x17, [sp, #S_X16]
+	ldp x18, x19, [sp, #S_X18]
+	ldp x20, x21, [sp, #S_X20]
+	ldp x22, x23, [sp, #S_X22]
+	ldp x24, x25, [sp, #S_X24]
+	ldp x26, x27, [sp, #S_X26]
+	ldp x28, x29, [sp, #S_X28]
+	ldr x30, [sp, #S_LR]
+
+	add sp, sp, #S_FRAME_SIZE
+	ret
+
+ENDPROC(kretprobe_trampoline)
-- 
2.5.0



From heiko at sntech.de  Thu Feb 18 15:52:19 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 19 Feb 2016 00:52:19 +0100
Subject: [PATCH v2 6/6] dt/bindings: rockchip: modify document of Rockchip
 power domains
In-Reply-To: <1455764899-13028-1-git-send-email-zhangqing@rock-chips.com>
References: <1455764899-13028-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <2204493.j28NF0gtji@phil>

Am Donnerstag, 18. Februar 2016, 11:08:19 schrieb Elaine Zhang:
> Add binding documentation for the power domains
> found on Rockchip RK3399 SoCs
> 
> Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>

This patch should probably include the devicetree people

Rob Herring <robh+dt at kernel.org>
Pawel Moll <pawel.moll at arm.com>
Mark Rutland <mark.rutland at arm.com>
Ian Campbell <ijc+devicetree at hellion.org.uk>
Kumar Gala <galak at codeaurora.org>
devicetree at vger.kernel.org


> ---
>  .../bindings/soc/rockchip/power_domain.txt          | 21
> +++++++++++++++++++++ 1 file changed, 21 insertions(+)
> 
> diff --git
> a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
> b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt index
> 13dc6a3..c65d401 100644
> --- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
> +++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
> @@ -7,6 +7,7 @@ Required properties for power domain controller:
>  - compatible: Should be one of the following.
>  	"rockchip,rk3288-power-controller" - for RK3288 SoCs.
>  	"rockchip,rk3368-power-controller" - for RK3368 SoCs.
> +	"rockchip,rk3399-power-controller" - for RK3399 SoCs.
>  - #power-domain-cells: Number of cells in a power-domain specifier.
>  	Should be 1 for multiple PM domains.
>  - #address-cells: Should be 1.
> @@ -16,6 +17,7 @@ Required properties for power domain sub nodes:
>  - reg: index of the power domain, should use macros in:
>  	"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power
> domain. "include/dt-bindings/power/rk3368-power.h" - for RK3368 type
> power domain. +	"include/dt-bindings/power/rk3399-power.h" - for RK3399
> type power domain. - clocks (optional): phandles to clocks which need to
> be enabled while power domain switches state.
> 
> @@ -45,12 +47,25 @@ Example:
>                  };
>          };
> 
> +	power: power-controller {
> +		compatible = "rockchip,rk3399-power-controller";
> +		#power-domain-cells = <1>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		pd_gpu {
> +			reg = <RK3399_PD_GPU>;
> +			clocks = <&cru ACLK_GPU>;
> +		};
> +	};
> +

I don't think we need to add another example for every type of power-domain controller :-) .

>  Node of a device using power domains must have a power-domains property,
>  containing a phandle to the power device node and an index specifying
> which power domain to use.
>  The index should use macros in:
>  	"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power
> domain. "include/dt-bindings/power/rk3368-power.h" - for rk3368 type
> power domain. +	"include/dt-bindings/power/rk3399-power.h" - for rk3399
> type power domain.
> 
>  Example of the node using power domain:
> 
> @@ -65,3 +80,9 @@ Example of the node using power domain:
>                  power-domains = <&power RK3368_PD_GPU_1>;
>                  /* ... */
>          };
> +
> +	node {
> +		/* ... */
> +		power-domains = <&power RK3399_PD_GPU>;
> +		/* ... */
> +	};

same here


Heiko


From heiko at sntech.de  Thu Feb 18 15:54:59 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 19 Feb 2016 00:54:59 +0100
Subject: [PATCH v2 5/6] rockchip: power-domain: Modify power domain driver
 for rk3399
In-Reply-To: <1455764885-12979-1-git-send-email-zhangqing@rock-chips.com>
References: <1455764885-12979-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1977372.gr1KGjTNYc@phil>

Am Donnerstag, 18. Februar 2016, 11:08:05 schrieb Elaine Zhang:
> This driver is modified to support RK3399 SoC.
> 
> Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
> ---
>  drivers/soc/rockchip/pm_domains.c | 55
> +++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+)
> 
> diff --git a/drivers/soc/rockchip/pm_domains.c
> b/drivers/soc/rockchip/pm_domains.c index 8cdf1b2..067e655 100644
> --- a/drivers/soc/rockchip/pm_domains.c
> +++ b/drivers/soc/rockchip/pm_domains.c
> @@ -19,6 +19,7 @@
>  #include <linux/mfd/syscon.h>
>  #include <dt-bindings/power/rk3288-power.h>
>  #include <dt-bindings/power/rk3368-power.h>
> +#include <dt-bindings/power/rk3399-power.h>
> 
>  struct rockchip_domain_info {
>  	int pwr_mask;
> @@ -81,6 +82,9 @@ struct rockchip_pmu {
>  #define DOMAIN_RK3368(pwr, status, req)		\
>  	DOMAIN(pwr, status, req, (req) + 16, req)
> 
> +#define DOMAIN_RK3399(pwr, status, req)                \
> +	DOMAIN(pwr, status, req, req, req)
> +
>  static bool rockchip_pmu_domain_is_idle(struct rockchip_pm_domain *pd)
>  {
>  	struct rockchip_pmu *pmu = pd->pmu;
> @@ -522,6 +526,36 @@ static const struct rockchip_domain_info
> rk3368_pm_domains[] = { [RK3368_PD_GPU_1]	= DOMAIN_RK3368(17, 16, 2),
>  };
> 
> +static const struct rockchip_domain_info rk3399_pm_domains[] = {
> +	[RK3399_PD_TCPD0]       = DOMAIN_RK3399(8, 8, NULL_BIT),
> +	[RK3399_PD_TCPD1]       = DOMAIN_RK3399(9, 9, NULL_BIT),
> +	[RK3399_PD_CCI]         = DOMAIN_RK3399(10, 10, NULL_BIT),
> +	[RK3399_PD_CCI0]        = DOMAIN_RK3399(NULL_BIT, NULL_BIT, 15),
> +	[RK3399_PD_CCI1]        = DOMAIN_RK3399(NULL_BIT, NULL_BIT, 16),
> +	[RK3399_PD_PERILP]      = DOMAIN_RK3399(11, 11, 1),
> +	[RK3399_PD_PERIHP]      = DOMAIN_RK3399(12, 12, 2),
> +	[RK3399_PD_CENTER]      = DOMAIN_RK3399(13, 13, 14),
> +	[RK3399_PD_VIO]         = DOMAIN_RK3399(14, 14, 17),
> +	[RK3399_PD_GPU]         = DOMAIN_RK3399(15, 15, 0),
> +	[RK3399_PD_VCODEC]      = DOMAIN_RK3399(16, 16, 3),
> +	[RK3399_PD_VDU]         = DOMAIN_RK3399(17, 17, 4),
> +	[RK3399_PD_RGA]         = DOMAIN_RK3399(18, 18, 5),
> +	[RK3399_PD_IEP]         = DOMAIN_RK3399(19, 19, 6),
> +	[RK3399_PD_VO]          = DOMAIN_RK3399(20, 20, NULL_BIT),
> +	[RK3399_PD_VOPB]        = DOMAIN_RK3399(NULL_BIT, NULL_BIT, 7),
> +	[RK3399_PD_VOPL]        = DOMAIN_RK3399(NULL_BIT, NULL_BIT, 8),
> +	[RK3399_PD_ISP0]        = DOMAIN_RK3399(22, 22, 9),
> +	[RK3399_PD_ISP1]        = DOMAIN_RK3399(23, 23, 10),
> +	[RK3399_PD_HDCP]        = DOMAIN_RK3399(24, 24, 11),
> +	[RK3399_PD_GMAC]        = DOMAIN_RK3399(25, 25, 23),
> +	[RK3399_PD_EMMC]        = DOMAIN_RK3399(26, 26, 24),
> +	[RK3399_PD_USB3]        = DOMAIN_RK3399(27, 27, 12),
> +	[RK3399_PD_EDP]         = DOMAIN_RK3399(28, 28, 22),
> +	[RK3399_PD_GIC]         = DOMAIN_RK3399(29, 29, 27),
> +	[RK3399_PD_SD]          = DOMAIN_RK3399(30, 30, 28),
> +	[RK3399_PD_SDIOAUDIO]   = DOMAIN_RK3399(31, 31, 29),

tabs indead of spaces between [index] and "=" please

otherwise looks nice :-)


Heiko


From heiko at sntech.de  Thu Feb 18 15:48:44 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 19 Feb 2016 00:48:44 +0100
Subject: [PATCH v2 0/6] rockchip: power-domain: fix pm domain for support
 RK3399 SoC
In-Reply-To: <1455764838-12928-1-git-send-email-zhangqing@rock-chips.com>
References: <1455764838-12928-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1552427.8VgrhmbCO1@phil>

Hi Elaine,

your sending mechanism could use some improvements :-)
I always get patches 1-4 correctly as replies to the cover-letter while 
patches 5+6 always come separately (missing in-reply-to?).

I guess using git send-email might help with that.

Also, Kevin Hilman was very involved in reviewing the original Rockchip 
power-domain driver, so it might be nice to include him in further versions.


Heiko

Am Donnerstag, 18. Februar 2016, 11:07:12 schrieb Elaine Zhang:
> fix some idle handling
> support sub-power domain
> add rk3399-power.h
> modify power domain for RK3399 SoC
> modify document for RK3399 Soc
> 
> Elaine Zhang (6):
>   rockchip: power-domain: make idle handling optional
>   rockchip: power-domain: allow domains only handling idle requests
>   rockchip: power-domain: add support for sub-power domains
>   dt/bindings: power: add RK3399 SoCs header for power-domain
>   rockchip: power-domain: Modify power domain driver for rk3399
>   dt/bindings: rockchip: modify document of Rockchip power domains
> 
>  .../bindings/soc/rockchip/power_domain.txt         |  21 ++++
>  drivers/soc/rockchip/pm_domains.c                  | 131
> ++++++++++++++++++++- include/dt-bindings/power/rk3399-power.h          
> |  53 +++++++++ 3 files changed, 200 insertions(+), 5 deletions(-)
>  create mode 100644 include/dt-bindings/power/rk3399-power.h


From k.kozlowski at samsung.com  Thu Feb 18 15:55:10 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 19 Feb 2016 08:55:10 +0900
Subject: [RFC 3/3] ARM: dts: Don't overheat the Odroid XU3-Lite on high
 load
In-Reply-To: <56C595F7.1080406@samsung.com>
References: <1455692128-28504-1-git-send-email-k.kozlowski@samsung.com>
 <1455692128-28504-4-git-send-email-k.kozlowski@samsung.com>
 <CANAwSgQHiJGSYB7Qhq066Mqfskwrr_3SDQGXH-WN=Wt3SEF-QA@mail.gmail.com>
 <56C522A9.8070800@samsung.com> <20160218023622.GA2610@vireshk-i7>
 <56C54B9B.7030105@samsung.com> <56C595F7.1080406@samsung.com>
Message-ID: <56C659DE.8010402@samsung.com>

On 18.02.2016 18:59, Marek Szyprowski wrote:
> Hello,
> 
> On 2016-02-18 05:42, Krzysztof Kozlowski wrote:
>> On 18.02.2016 11:36, Viresh Kumar wrote:
>>>> BTW, I found the issue. The order of trip points in DT:
>>>> thermal_zone0/trip_point_0_hyst:5000
>>>> thermal_zone0/trip_point_0_temp:50000
>>>> thermal_zone0/trip_point_0_type:active
>>>> thermal_zone0/trip_point_1_hyst:5000
>>>> thermal_zone0/trip_point_1_temp:60000
>>>> thermal_zone0/trip_point_1_type:active
>>>> thermal_zone0/trip_point_2_hyst:5000
>>>> thermal_zone0/trip_point_2_temp:70000
>>>> thermal_zone0/trip_point_2_type:active
>>>> thermal_zone0/trip_point_3_hyst:0
>>>> thermal_zone0/trip_point_3_temp:120000    <---- this should be last
>>>> one!
>>>> thermal_zone0/trip_point_3_type:critical
>>>> thermal_zone0/trip_point_4_hyst:5000
>>>> thermal_zone0/trip_point_4_temp:90000
>>>> thermal_zone0/trip_point_4_type:passive
>>>> thermal_zone0/trip_point_5_hyst:5000
>>>> thermal_zone0/trip_point_5_temp:110000
>>>> thermal_zone0/trip_point_5_type:passive
>>>>
>>>> After fixing the order in DT, the cpu cooler starts working.
>>> Ahh, nice.
>> Damn, not entirely. I almost fried my Odroid (it survived 130 degrees of
>> C)... The TMU supports only 4 trip points, so when I added two new trip
>> points and reordered them... the last two (including critical) was not
>> receiving interrupts.
>>
>> Polling mode is needed. I'll sent some patches soon...
> 
> Instead of polling the driver should simply use some dynamic window for
> the nearest temperature ranges and reconfigure it when interrupt of occurs.


Thanks for feedback, Marek!

First of all the polling happens only when initial trip point for
passive cooling is reached (70 degrees C). This fortunately reduces the
polling overhead.

Yours idea seems interesting... but driver does not support it now, does
it? I can put this on TODO list, maybe someone will extend the exynos
thermal driver.

Best regards,
Krzysztof


From heiko at sntech.de  Thu Feb 18 16:05:38 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 19 Feb 2016 01:05:38 +0100
Subject: [PATCH v2 1/6] rockchip: power-domain: make idle handling optional
In-Reply-To: <1455764838-12928-2-git-send-email-zhangqing@rock-chips.com>
References: <1455764838-12928-1-git-send-email-zhangqing@rock-chips.com>
 <1455764838-12928-2-git-send-email-zhangqing@rock-chips.com>
Message-ID: <291170080.OevJ1dsWVH@phil>

Am Donnerstag, 18. Februar 2016, 11:07:13 schrieb Elaine Zhang:
> Not all new socs need to handle idle states on domain state changes,
> so add the possibility to make them optional.
> 
> Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>

What's up with the Signed-off-bys? I remember creating the draft of this 
change, so either my authorship of the patch should be retained or the 
Signed-off-by with my name removed :-)

git send-email will keep patch authorship nicely.


> ---
>  drivers/soc/rockchip/pm_domains.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/soc/rockchip/pm_domains.c
> b/drivers/soc/rockchip/pm_domains.c index 6cdffb1..3dcc611 100644
> --- a/drivers/soc/rockchip/pm_domains.c
> +++ b/drivers/soc/rockchip/pm_domains.c
> @@ -63,14 +63,16 @@ struct rockchip_pmu {
>  };
> 
>  #define to_rockchip_pd(gpd) container_of(gpd, struct rockchip_pm_domain,
> genpd) +#define NULL_BIT		-32
> +#define OVERFLOW_MASK		32

I don't really understand why you need this NULL_BIT / OVERFLOW_MASK.
Defining the unset things to -1 should work nicely as well and is already 
regularly used elsewhere - so people will already know this scheme. That way 
you also don't need to introduce two new constants someone will have to look 
up later.

> 
>  #define DOMAIN(pwr, status, req, idle, ack)	\
>  {						\
>  	.pwr_mask = BIT(pwr),			\
>  	.status_mask = BIT(status),		\
> -	.req_mask = BIT(req),			\
> -	.idle_mask = BIT(idle),			\
> -	.ack_mask = BIT(ack),			\
> +	.req_mask = (req >= 0) ? BIT(req) : OVERFLOW_MASK,		\
> +	.idle_mask = (idle >= 0) ? BIT(idle) : OVERFLOW_MASK,	\
> +	.ack_mask = (ack >= 0) ? BIT(ack) : OVERFLOW_MASK,		\
>  }
> 
>  #define DOMAIN_RK3288(pwr, status, req)		\
> @@ -96,6 +98,9 @@ static int rockchip_pmu_set_idle_request(struct
> rockchip_pm_domain *pd, struct rockchip_pmu *pmu = pd->pmu;
>  	unsigned int val;
> 
> +	if (pd_info->req_mask >= OVERFLOW_MASK)
> +		return 0;
> +
>  	regmap_update_bits(pmu->regmap, pmu->info->req_offset,
>  			   pd_info->req_mask, idle ? -1U : 0);



From heiko at sntech.de  Thu Feb 18 16:20:03 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 19 Feb 2016 01:20:03 +0100
Subject: [PATCH v2 3/6] rockchip: power-domain: add support for sub-power
 domains
In-Reply-To: <1455764838-12928-4-git-send-email-zhangqing@rock-chips.com>
References: <1455764838-12928-1-git-send-email-zhangqing@rock-chips.com>
 <1455764838-12928-4-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1828664.WUMlfLyMuz@phil>

Hi Elaine,

Am Donnerstag, 18. Februar 2016, 11:07:15 schrieb Elaine Zhang:
> This patch adds support for making one power domain a sub-domain of
> other domain. This is useful for modeling power dependences,
> which needs to have more than one power domain enabled to be operational.
> 
> Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
> ---
>  drivers/soc/rockchip/pm_domains.c | 54
> +++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+)
> 
> diff --git a/drivers/soc/rockchip/pm_domains.c
> b/drivers/soc/rockchip/pm_domains.c index 350527b..8cdf1b2 100644
> --- a/drivers/soc/rockchip/pm_domains.c
> +++ b/drivers/soc/rockchip/pm_domains.c
> @@ -372,6 +372,54 @@ static void rockchip_configure_pd_cnt(struct
> rockchip_pmu *pmu, regmap_write(pmu->regmap, domain_reg_offset + 4,
> count);
>  }
> 
> +static int rockchip_pm_add_subdomain(struct rockchip_pmu *pmu,
> +				     struct device_node *parent)
> +{
> +	struct device_node *np;
> +	int error;
> +
> +	for_each_child_of_node(parent, np) {
> +		struct generic_pm_domain *child_domain, *parent_domain;
> +		u32 idx = ~0;
> +
> +		if (of_property_read_u32(parent, "reg", &idx)) {
> +			dev_err(pmu->dev,
> +				"%s: failed to retrieve domain id (reg)\n",
> +				parent->name);
> +			of_node_put(parent);
> +			return -EINVAL;
> +		}
> +		parent_domain = pmu->genpd_data.domains[idx];
> +
> +		error = rockchip_pm_add_one_domain(pmu, np);
> +		if (error) {
> +			dev_err(pmu->dev, "failed to handle node %s: %d\n",
> +				np->name, error);
> +			of_node_put(np);
> +			return -ENODEV;
> +		}
> +
> +		if (of_property_read_u32(np, "reg", &idx)) {
> +			dev_err(pmu->dev,
> +				"%s: failed to retrieve domain id (reg)\n",
> +				np->name);
> +			of_node_put(np);
> +			return -EINVAL;
> +		}
> +		child_domain = pmu->genpd_data.domains[idx];
> +
> +		if (pm_genpd_add_subdomain(parent_domain, child_domain))
> +			pr_warn("%s failed to add subdomain: %s\n",
> +				parent_domain->name, child_domain->name);

should probably be dev_err here


> +		else
> +			pr_warn("%s add subdomain: %s\n",
> +				parent_domain->name, child_domain->name);

you don't need pr_warn / dev_warn on sucess

> +
> +		rockchip_pm_add_subdomain(pmu, np);
> +	}
> +	return 0;
> +}
> +

In general the code looks like you're going to group the domains 
hirarchically, like

       power: power-controller {
               compatible = "rockchip,rk3399-power-controller";

               pd_cci {
                       reg = <RK3399_PD_CCI>;
                       clocks = ...;

			pd_cci0 {
				reg = <RK3399_PD_CCI0>;
				clocks = ...;
			};
               };
       };

This isn't documented in the dt-binding and also isn't really improving
reading these declarations. Instead as I said before, I think I'd like more 
get inspiration from how Exynos is doing that already (arch/arm/mach-
exynos/pm_domains.c at "Assign the child power domains to their parents") 
simply declaring an additional power-domains property like:

       power: power-controller {
               compatible = "rockchip,rk3399-power-controller";

               pd_cci {
                       reg = <RK3399_PD_CCI>;
                       clocks = ...;
               };

		pd_cci0 {
			reg = <RK3399_PD_CCI0>;
			clocks = ...;
			power-domains = <&power RK3399_PD_CCI>;
		};
       };

>  static int rockchip_pm_domain_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> @@ -437,6 +485,12 @@ static int rockchip_pm_domain_probe(struct
> platform_device *pdev) node->name, error);
>  			goto err_out;
>  		}

blank line here

> +		error = rockchip_pm_add_subdomain(pmu, node);
> +		if (error < 0) {
> +			dev_err(dev, "failed to handle subdomain node %s: %d\n",
> +				node->name, error);
> +			goto err_out;
> +		}
>  	}
> 
>  	if (error) {



From k.kozlowski at samsung.com  Thu Feb 18 16:26:48 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 19 Feb 2016 09:26:48 +0900
Subject: [PATCH 1/3] thermal: exynos: List vtmu-supply as optional property
 in DT binding
In-Reply-To: <1455819551-4666-2-git-send-email-javier@osg.samsung.com>
References: <1455819551-4666-1-git-send-email-javier@osg.samsung.com>
 <1455819551-4666-2-git-send-email-javier@osg.samsung.com>
Message-ID: <56C66148.5060006@samsung.com>

On 19.02.2016 03:19, Javier Martinez Canillas wrote:
> The Exynos Thermal Management Unit binding says that the vtmu-supply
> is optional but is listed in the required properties section. Add an
> optional properties section and move the regulator property there.
> 
> Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
> ---
> 
>  Documentation/devicetree/bindings/thermal/exynos-thermal.txt | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 

Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>

Best regards,
Krzysztof




From k.kozlowski at samsung.com  Thu Feb 18 16:33:03 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 19 Feb 2016 09:33:03 +0900
Subject: [PATCH 2/3] thermal: exynos: Use devm_regulator_get_optional() for
 vtmu
In-Reply-To: <1455819551-4666-3-git-send-email-javier@osg.samsung.com>
References: <1455819551-4666-1-git-send-email-javier@osg.samsung.com>
 <1455819551-4666-3-git-send-email-javier@osg.samsung.com>
Message-ID: <56C662BF.5080903@samsung.com>

On 19.02.2016 03:19, Javier Martinez Canillas wrote:
> The Exynos TMU DT binding says that the vtmu-supply is optional but the
> driver uses devm_regulator_get() that creates a dummy regulator if it's
> not defined in the DT. For example the following message is in the log:
> 
> 10060000.tmu supply vtmu not found, using dummy regulator
> 
> Use the optional version of regulator_get() that doesn't create a dummy
> regulator and instead returns a -ENODEV errno code. Since it's expected
> that a regulator may not be defined and the driver will inform about it:
> 
> exynos-tmu 10060000.tmu: Regulator node (vtmu) not found
> 
> Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
> ---
> 
>  drivers/thermal/samsung/exynos_tmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>

Best regards,
Krzysztof



From k.kozlowski at samsung.com  Thu Feb 18 16:37:00 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 19 Feb 2016 09:37:00 +0900
Subject: [PATCH 3/3] thermal: exynos: Defer probe if vtmu is present but
 not registered
In-Reply-To: <1455819551-4666-4-git-send-email-javier@osg.samsung.com>
References: <1455819551-4666-1-git-send-email-javier@osg.samsung.com>
 <1455819551-4666-4-git-send-email-javier@osg.samsung.com>
Message-ID: <56C663AC.7030601@samsung.com>

On 19.02.2016 03:19, Javier Martinez Canillas wrote:
> The driver doesn't check if the regulator_get_optional return value is
> -EPROBE_DEFER so it will wrongly assume that the regulator couldn't be
> found just because the regulator driver wasn't registered yet, i.e:
> 
> exynos-tmu 10060000.tmu: Regulator node (vtmu) not found
> 
> In this case the return value should be propagated to allow the driver
> probe function to be deferred until the regulator driver is registered.
> 
> Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
> 
> ---
> 
>  drivers/thermal/samsung/exynos_tmu.c | 2 ++
>  1 file changed, 2 insertions(+)
> 

Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>

Best regards,
Krzysztof



From jay.xu at rock-chips.com  Thu Feb 18 16:48:15 2016
From: jay.xu at rock-chips.com (Jianqun Xu)
Date: Fri, 19 Feb 2016 08:48:15 +0800
Subject: [PATCH 5/6] dt-bindings: add documentation of rk3399 clock
 controller
In-Reply-To: <20160218143648.GL9654@rob-hp-laptop>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <1455674089-16567-1-git-send-email-jay.xu@rock-chips.com>
 <20160218143648.GL9654@rob-hp-laptop>
Message-ID: <56C6664F.8070600@rock-chips.com>

Hi Rob

? 18/02/2016 22:36, Rob Herring ??:
> On Wed, Feb 17, 2016 at 09:54:49AM +0800, jianqun.xu wrote:
>> From: Xing Zheng <zhengxing at rock-chips.com>
>>
>> Add the devicetree binding for the cru on the rk3399 which quite
>> similar structured as previous clock controllers.
>>
>> Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
>> ---
>>   .../bindings/clock/rockchip,rk3399-cru.txt         | 82 ++++++++++++++++++++++
>>   1 file changed, 82 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
>>
>> diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
>> new file mode 100644
>> index 0000000..07bcc6e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
>> @@ -0,0 +1,82 @@
>> +* Rockchip RK3399 Clock and Reset Unit
>
> [...]
>
>> +Example: General Register Files
>> +
>> +	pmugrf: syscon at ff320000 {
>> +		compatible = "rockchip,rk3399-pmugrf", "syscon";
>
> Is this documented?
Since there is no documentation for rockchip grf from early SoCs, I 
think if we need to add a new devicetree documentation, such as
Documentation/devicetree/bindings/clock/rockchip,rk3399-grf.txt ?

If you agree, I will add it in next patch

>
>> +		reg = <0x0 0xff320000 0x0 0x1000>;
>> +	};
>> +
>> +	grf: syscon at ff770000 {
>> +		compatible = "rockchip,rk3399-grf", "syscon";
>
> ditto.
>
>> +		reg = <0x0 0xff770000 0x0 0x10000>;
>> +	};
>> +
>> +Example: Clock controller node:
>> +
>> +	pmucru: pmu-clock-controller at ff750000 {
>> +		compatible = "rockchip,rk3399-pmucru";
>> +		reg = <0x0 0xff750000 0x0 0x1000>;
>> +		#clock-cells = <1>;
>> +		#reset-cells = <1>;
>> +	};
>> +
>> +	cru: clock-controller at ff760000 {
>> +		compatible = "rockchip,rk3399-cru";
>> +		reg = <0x0 0xff760000 0x0 0x1000>;
>> +		rockchip,grf = <&grf>;
>> +		#clock-cells = <1>;
>> +		#reset-cells = <1>;
>> +	};
>> +
>> +Example: UART controller node that consumes the clock generated by the clock
>> +  controller:
>> +
>> +	uart0: serial at ff1a0000 {
>> +		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
>> +		reg = <0x0 0xff180000 0x0 0x100>;
>> +		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
>> +		clock-names = "baudclk", "apb_pclk";
>> +		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
>> +		reg-shift = <2>;
>> +		reg-io-width = <4>;
>> +	};
>> --
>> 1.9.1
>>
>>
>
>
>



From heiko at sntech.de  Thu Feb 18 16:53:52 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 19 Feb 2016 01:53:52 +0100
Subject: [PATCH 5/6] dt-bindings: add documentation of rk3399 clock
 controller
In-Reply-To: <56C6664F.8070600@rock-chips.com>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <20160218143648.GL9654@rob-hp-laptop> <56C6664F.8070600@rock-chips.com>
Message-ID: <1758156.nKISImzkM9@phil>

Am Freitag, 19. Februar 2016, 08:48:15 schrieb Jianqun Xu:
> Hi Rob
> 
> ? 18/02/2016 22:36, Rob Herring ??:
> > On Wed, Feb 17, 2016 at 09:54:49AM +0800, jianqun.xu wrote:
> >> From: Xing Zheng <zhengxing at rock-chips.com>
> >> 
> >> Add the devicetree binding for the cru on the rk3399 which quite
> >> similar structured as previous clock controllers.
> >> 
> >> Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
> >> ---
> >> 
> >>   .../bindings/clock/rockchip,rk3399-cru.txt         | 82
> >>   ++++++++++++++++++++++ 1 file changed, 82 insertions(+)
> >>   create mode 100644
> >>   Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt>> 
> >> diff --git
> >> a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
> >> b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt new
> >> file mode 100644
> >> index 0000000..07bcc6e
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
> >> @@ -0,0 +1,82 @@
> >> +* Rockchip RK3399 Clock and Reset Unit
> > 
> > [...]
> > 
> >> +Example: General Register Files
> >> +
> >> +	pmugrf: syscon at ff320000 {
> >> +		compatible = "rockchip,rk3399-pmugrf", "syscon";
> > 
> > Is this documented?
> 
> Since there is no documentation for rockchip grf from early SoCs, I
> think if we need to add a new devicetree documentation, such as
> Documentation/devicetree/bindings/clock/rockchip,rk3399-grf.txt ?

The grf is not clock-specific, so the directory is probably not correct.
I'd think bindings/arm/rockchip/grf.txt might be better or
bindings/soc/rockchip/grf.txt or somewhere else. And define the properties 
for all per-soc GRFs in there.

In any case we really should add the missing grf binding documentation (in a 
separate patch of course), as the grf is a pretty commonly used shared 
component.


> 
> If you agree, I will add it in next patch
> 
> >> +		reg = <0x0 0xff320000 0x0 0x1000>;
> >> +	};
> >> +
> >> +	grf: syscon at ff770000 {
> >> +		compatible = "rockchip,rk3399-grf", "syscon";
> > 
> > ditto.
> > 
> >> +		reg = <0x0 0xff770000 0x0 0x10000>;
> >> +	};
> >> +
> >> +Example: Clock controller node:
> >> +
> >> +	pmucru: pmu-clock-controller at ff750000 {
> >> +		compatible = "rockchip,rk3399-pmucru";
> >> +		reg = <0x0 0xff750000 0x0 0x1000>;
> >> +		#clock-cells = <1>;
> >> +		#reset-cells = <1>;
> >> +	};
> >> +
> >> +	cru: clock-controller at ff760000 {
> >> +		compatible = "rockchip,rk3399-cru";
> >> +		reg = <0x0 0xff760000 0x0 0x1000>;
> >> +		rockchip,grf = <&grf>;
> >> +		#clock-cells = <1>;
> >> +		#reset-cells = <1>;
> >> +	};
> >> +
> >> +Example: UART controller node that consumes the clock generated by the
> >> clock +  controller:
> >> +
> >> +	uart0: serial at ff1a0000 {
> >> +		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
> >> +		reg = <0x0 0xff180000 0x0 0x100>;
> >> +		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
> >> +		clock-names = "baudclk", "apb_pclk";
> >> +		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
> >> +		reg-shift = <2>;
> >> +		reg-io-width = <4>;
> >> +	};
> >> --
> >> 1.9.1



From jay.xu at rock-chips.com  Thu Feb 18 17:05:13 2016
From: jay.xu at rock-chips.com (Jianqun Xu)
Date: Fri, 19 Feb 2016 09:05:13 +0800
Subject: [PATCH 5/6] dt-bindings: add documentation of rk3399 clock
 controller
In-Reply-To: <1758156.nKISImzkM9@phil>
References: <1455673992-16469-1-git-send-email-jay.xu@rock-chips.com>
 <20160218143648.GL9654@rob-hp-laptop> <56C6664F.8070600@rock-chips.com>
 <1758156.nKISImzkM9@phil>
Message-ID: <56C66A49.2080501@rock-chips.com>

Hi Heiko

? 19/02/2016 08:53, Heiko Stuebner ??:
> Am Freitag, 19. Februar 2016, 08:48:15 schrieb Jianqun Xu:
>> Hi Rob
>>
>> ? 18/02/2016 22:36, Rob Herring ??:
>>> On Wed, Feb 17, 2016 at 09:54:49AM +0800, jianqun.xu wrote:
>>>> From: Xing Zheng <zhengxing at rock-chips.com>
>>>>
>>>> Add the devicetree binding for the cru on the rk3399 which quite
>>>> similar structured as previous clock controllers.
>>>>
>>>> Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
>>>> ---
>>>>
>>>>    .../bindings/clock/rockchip,rk3399-cru.txt         | 82
>>>>    ++++++++++++++++++++++ 1 file changed, 82 insertions(+)
>>>>    create mode 100644
>>>>    Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
>>>> b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt new
>>>> file mode 100644
>>>> index 0000000..07bcc6e
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
>>>> @@ -0,0 +1,82 @@
>>>> +* Rockchip RK3399 Clock and Reset Unit
>>>
>>> [...]
>>>
>>>> +Example: General Register Files
>>>> +
>>>> +	pmugrf: syscon at ff320000 {
>>>> +		compatible = "rockchip,rk3399-pmugrf", "syscon";
>>>
>>> Is this documented?
>>
>> Since there is no documentation for rockchip grf from early SoCs, I
>> think if we need to add a new devicetree documentation, such as
>> Documentation/devicetree/bindings/clock/rockchip,rk3399-grf.txt ?
>
> The grf is not clock-specific, so the directory is probably not correct.
> I'd think bindings/arm/rockchip/grf.txt might be better or
> bindings/soc/rockchip/grf.txt or somewhere else. And define the properties
> for all per-soc GRFs in there.
>
> In any case we really should add the missing grf binding documentation (in a
> separate patch of course), as the grf is a pretty commonly used shared
> component.
>
Got it, I will add bindings/soc/rockchip/grf.txt in next patch
Thanks !
>
>>
>> If you agree, I will add it in next patch
>>
>>>> +		reg = <0x0 0xff320000 0x0 0x1000>;
>>>> +	};
>>>> +
>>>> +	grf: syscon at ff770000 {
>>>> +		compatible = "rockchip,rk3399-grf", "syscon";
>>>
>>> ditto.
>>>
>>>> +		reg = <0x0 0xff770000 0x0 0x10000>;
>>>> +	};
>>>> +
>>>> +Example: Clock controller node:
>>>> +
>>>> +	pmucru: pmu-clock-controller at ff750000 {
>>>> +		compatible = "rockchip,rk3399-pmucru";
>>>> +		reg = <0x0 0xff750000 0x0 0x1000>;
>>>> +		#clock-cells = <1>;
>>>> +		#reset-cells = <1>;
>>>> +	};
>>>> +
>>>> +	cru: clock-controller at ff760000 {
>>>> +		compatible = "rockchip,rk3399-cru";
>>>> +		reg = <0x0 0xff760000 0x0 0x1000>;
>>>> +		rockchip,grf = <&grf>;
>>>> +		#clock-cells = <1>;
>>>> +		#reset-cells = <1>;
>>>> +	};
>>>> +
>>>> +Example: UART controller node that consumes the clock generated by the
>>>> clock +  controller:
>>>> +
>>>> +	uart0: serial at ff1a0000 {
>>>> +		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
>>>> +		reg = <0x0 0xff180000 0x0 0x100>;
>>>> +		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
>>>> +		clock-names = "baudclk", "apb_pclk";
>>>> +		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
>>>> +		reg-shift = <2>;
>>>> +		reg-io-width = <4>;
>>>> +	};
>>>> --
>>>> 1.9.1
>
>
>
>



From eric at anholt.net  Thu Feb 18 17:12:55 2016
From: eric at anholt.net (Eric Anholt)
Date: Thu, 18 Feb 2016 17:12:55 -0800
Subject: [PATCH] i2c: bcm2835: Don't complain on -EPROBE_DEFER from getting
 our clock
Message-ID: <1455844375-15019-1-git-send-email-eric@anholt.net>

Fixes dmesg spam when we just need to wait a moment for the clock
driver to probe.

Signed-off-by: Eric Anholt <eric at anholt.net>
---
 drivers/i2c/busses/i2c-bcm2835.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
index 818b051..d4f3239 100644
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -253,7 +253,8 @@ static int bcm2835_i2c_probe(struct platform_device *pdev)
 
 	i2c_dev->clk = devm_clk_get(&pdev->dev, NULL);
 	if (IS_ERR(i2c_dev->clk)) {
-		dev_err(&pdev->dev, "Could not get clock\n");
+		if (PTR_ERR(i2c_dev->clk) != -EPROBE_DEFER)
+			dev_err(&pdev->dev, "Could not get clock\n");
 		return PTR_ERR(i2c_dev->clk);
 	}
 
-- 
2.7.0



From jay.xu at rock-chips.com  Thu Feb 18 17:56:12 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Fri, 19 Feb 2016 09:56:12 +0800
Subject: [PATCH v4 0/6] Add core dtsi for rk3399 from Rockchip
Message-ID: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>

From: Jianqun Xu <jay.xu at rock-chips.com>

There is the new SoCs from Rockchip which named rk3399, the
patches are added to support them.

Jianque Xu (4):
  soc: rockchip: add bindings for Rockchip grf
  spi: rockchip: add bindings for rk3399 spi
  ASoC: rockchip: add bindings for rk3399 i2s
  ARM64: dts: rockchip: add core dtsi file for rk3399

Xing Zheng (2):
  clk: rockchip: add dt-binding header for rk3399
  dt-bindings: add documentation of rk3399 clock controller

 .../bindings/clock/rockchip,rk3399-cru.txt         |  82 ++
 .../devicetree/bindings/soc/rockchip/grf.txt       |  35 +
 .../devicetree/bindings/sound/rockchip-i2s.txt     |   1 +
 .../devicetree/bindings/spi/spi-rockchip.txt       |   1 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           | 949 +++++++++++++++++++++
 drivers/spi/spi-rockchip.c                         |   1 +
 include/dt-bindings/clock/rk3399-cru.h             | 609 +++++++++++++
 7 files changed, 1678 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
 create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
 create mode 100644 include/dt-bindings/clock/rk3399-cru.h

-- 
changes in v4:
- restore rockchip-i2s.txt patch for rk3399-i2s (Rob)
- add grf.txt for rockchip grf (Rob, Heiko)
- reset my author name to keep same with signoff

changes in v3:
- add compatible for rk3399 spi (Mark, Heiko)

changes in v2:
- remove changeID (Heiko, Mark)
- drop pmu and psci temporary (Mark)
- drop applied patch (Heiko)
- drop GIC_CPU_MASK_SIMPLE from the interrupt specifiers (Marc, Heiko)
- drop clock-frequency of timer (Marc, Mark)
- remove double defination for SCLK_SPI5

1.9.1




From jay.xu at rock-chips.com  Thu Feb 18 17:56:14 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Fri, 19 Feb 2016 09:56:14 +0800
Subject: [PATCH v4 2/6] soc: rockchip: add bindings for Rockchip grf
In-Reply-To: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
References: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455846978-4272-3-git-send-email-jay.xu@rock-chips.com>

From: Jianqun Xu <jay.xu at rock-chips.com>

Add devicetree bindings for Rockchip grf which found on
Rockchip SoCs.

Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v4:
- new add

 .../devicetree/bindings/soc/rockchip/grf.txt       | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt

diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
new file mode 100644
index 0000000..7fb0410
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
@@ -0,0 +1,35 @@
+* Rockchip General Register Files (GRF)
+
+The general register file will be used to do static set by software, which
+is composed of many registers for system control.
+
+From RK3368 SoCs, the GRF is divided into two sections,
+- GRF, used for general non-secure system,
+- PMUGRF, used for always on sysyem
+
+Required Properties:
+
+- compatible: GRF should be one of the followings
+   - "rockchip,rk3066-grf", "syscon": for rk3066
+   - "rockchip,rk3188-grf", "syscon": for rk3188
+   - "rockchip,rk3228-grf", "syscon": for rk3228
+   - "rockchip,rk3288-grf", "syscon": for rk3288
+   - "rockchip,rk3368-grf", "syscon": for rk3368
+   - "rockchip,rk3399-grf", "syscon": for rk3399
+- compatible: PMUGRF should be one of the followings
+   - "rockchip,rk3368-pmugrf", "syscon": for rk3368
+   - "rockchip,rk3399-pmugrf", "syscon": for rk3399
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+Example: GRF and PMUGRF of RK3399 SoCs
+
+	pmugrf: syscon at ff320000 {
+		compatible = "rockchip,rk3399-pmugrf", "syscon";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+	};
+
+	grf: syscon at ff770000 {
+		compatible = "rockchip,rk3399-grf", "syscon";
+		reg = <0x0 0xff770000 0x0 0x10000>;
+	};
-- 
1.9.1




From jay.xu at rock-chips.com  Thu Feb 18 17:56:13 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Fri, 19 Feb 2016 09:56:13 +0800
Subject: [PATCH v4 1/6] clk: rockchip: add dt-binding header for rk3399
In-Reply-To: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
References: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455846978-4272-2-git-send-email-jay.xu@rock-chips.com>

From: Xing Zheng <zhengxing at rock-chips.com>

Add the dt-bindings header for the rk3399, that gets shared between
the clock controller and the clock references in the dts.

Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v4:
- none

changes in v3:
- none

changes in v2:
- remove duplicate defination of SCLK_SPI5

 include/dt-bindings/clock/rk3399-cru.h | 609 +++++++++++++++++++++++++++++++++
 1 file changed, 609 insertions(+)
 create mode 100644 include/dt-bindings/clock/rk3399-cru.h

diff --git a/include/dt-bindings/clock/rk3399-cru.h b/include/dt-bindings/clock/rk3399-cru.h
new file mode 100644
index 0000000..9fbe3dc
--- /dev/null
+++ b/include/dt-bindings/clock/rk3399-cru.h
@@ -0,0 +1,609 @@
+/*
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng <zhengxing at rock-chips.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H
+#define _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H
+
+/* core clocks */
+#define PLL_APLLL		1
+#define PLL_APLLB		2
+#define PLL_DPLL		3
+#define PLL_CPLL		4
+#define PLL_GPLL		5
+#define PLL_NPLL		6
+#define PLL_VPLL		7
+#define PLL_PPLL		8
+#define ARMCLKL			9
+#define ARMCLKB			10
+
+/* sclk gates (special clocks) */
+#define SCLK_GPU_CORE		64
+#define SCLK_SPI0		65
+#define SCLK_SPI1		66
+#define SCLK_SPI2		68
+#define SCLK_SPI3		69
+#define SCLK_SPI4		70
+#define SCLK_SDMMC		72
+#define SCLK_SDIO0		73
+#define SCLK_EMMC		74
+#define SCLK_TSADC		75
+#define SCLK_SARADC		76
+#define SCLK_NANDC0		77
+#define SCLK_UART0		78
+#define SCLK_UART1		79
+#define SCLK_UART2		80
+#define SCLK_UART3		81
+#define SCLK_UART4		82
+#define SCLK_SPDIF_8CH		83
+#define SCLK_I2S0_8CH		84
+#define SCLK_I2S1_8CH		85
+#define SCLK_I2S2_8CH		86
+#define SCLK_TIMER00		87
+#define SCLK_TIMER01		88
+#define SCLK_TIMER02		89
+#define SCLK_TIMER03		90
+#define SCLK_TIMER04		91
+#define SCLK_TIMER05		92
+#define SCLK_TIMER06		93
+#define SCLK_TIMER07		94
+#define SCLK_TIMER08		95
+#define SCLK_TIMER09		96
+#define SCLK_TIMER10		97
+#define SCLK_TIMER11		98
+#define SCLK_HSICPHY480M	99
+#define SCLK_HSICPHY12M		100
+#define SCLK_MACREF		101
+#define SCLK_VOPB_PWM		102
+#define SCLK_VOPL_PWM		103
+#define SCLK_EDP_24M		104
+#define SCLK_EDP		105
+#define SCLK_RGA		106
+#define SCLK_ISP		107
+#define SCLK_HDCP		108
+#define SCLK_HDMI_HDCP		109
+#define SCLK_HDMI_CEC		110
+#define SCLK_HEVC_CABAC		111
+#define SCLK_HEVC_CORE		112
+#define SCLK_I2S_8CH_OUT	113
+#define SCLK_SDMMC_DRV		114
+#define SCLK_SDIO0_DRV		115
+#define SCLK_SDIO1_DRV		116
+#define SCLK_EMMC_DRV		117
+#define SCLK_SDMMC_SAMPLE	118
+#define SCLK_SDIO0_SAMPLE	119
+#define SCLK_SDIO1_SAMPLE	120
+#define SCLK_EMMC_SAMPLE	121
+#define SCLK_USBPHY480M		122
+#define SCLK_PVTM_CORE_L	123
+#define SCLK_PVTM_CORE_B	124
+#define SCLK_PVTM_GPU		125
+#define SCLK_PVTM_PMU		126
+#define SCLK_SFC		127
+#define SCLK_MAC_RX		128
+#define SCLK_MAC_TX		129
+#define SCLK_MAC		130
+#define SCLK_MACREF_OUT		131
+#define SCLK_USB2_PHY0_REF	132
+#define SCLK_USB2_PHY1_REF	133
+#define SCLK_USB3_OTG0_REF	134
+#define SCLK_USB3_OTG1_REF	135
+#define SCLK_USB3_OTG0_SUSPEND	136
+#define SCLK_USB3_OTG1_SUSPEND	137
+#define SCLK_CRYPTO		138
+#define SCLK_CRYPTO1		139
+
+#define DCLK_VOPB		170
+#define DCLK_VOPL		171
+#define MCLK_CRYPTO		172
+#define MCLK_CRYPTO1		173
+
+/* aclk gates */
+#define ACLK_GPU_MEM		192
+#define ACLK_GPU_CFG		193
+#define ACLK_DMAC_BUS		194
+#define ACLK_DMAC_PERI		195
+#define ACLK_PERI_MMU		196
+#define ACLK_GMAC		197
+#define ACLK_VOPB		198
+#define ACLK_VOPL		199
+#define ACLK_RGA		200
+#define ACLK_HDCP		201
+#define ACLK_IEP		202
+#define ACLK_VIO0_NOC		203
+#define ACLK_VIP		204
+#define ACLK_ISP		205
+#define ACLK_VIO1_NOC		206
+#define ACLK_VIDEO		208
+#define ACLK_BUS		209
+#define ACLK_PERI		210
+#define ACLK_EMMC_GPLL		211
+#define ACLK_EMMC_CPLL		212
+#define ACLK_EMMC_CORE		213
+#define ACLK_EMMC_NIU 		214
+#define ACLK_EMMC_GRF 		215
+#define ACLK_USB3_OTG0		216
+#define ACLK_USB3_OTG1		217
+#define ACLK_USB3_GRF 		218
+
+/* pclk gates */
+#define PCLK_GPIO0		320
+#define PCLK_GPIO1		321
+#define PCLK_GPIO2		322
+#define PCLK_GPIO3		323
+#define PCLK_GPIO4		324
+#define PCLK_PMUGRF		325
+#define PCLK_MAILBOX		326
+#define PCLK_GRF		329
+#define PCLK_SGRF		330
+#define PCLK_PMU		331
+#define PCLK_I2C0		332
+#define PCLK_I2C1		333
+#define PCLK_I2C2		334
+#define PCLK_I2C3		335
+#define PCLK_I2C4		336
+#define PCLK_I2C5		337
+#define PCLK_SPI0		338
+#define PCLK_SPI1		339
+#define PCLK_SPI2		340
+#define PCLK_SPI3		341
+#define PCLK_SPI4		342
+#define PCLK_SPI5		343
+#define PCLK_UART0		344
+#define PCLK_UART1		345
+#define PCLK_UART2		346
+#define PCLK_UART3		347
+#define PCLK_UART4		348
+#define PCLK_TSADC		349
+#define PCLK_SARADC		350
+#define PCLK_SIM		351
+#define PCLK_GMAC		352
+#define PCLK_PWM0		353
+#define PCLK_PWM1		354
+#define PCLK_TIMER0		355
+#define PCLK_TIMER1		356
+#define PCLK_EDP_CTRL		357
+#define PCLK_MIPI_DSI0		358
+#define PCLK_MIPI_CSI		359
+#define PCLK_HDCP		360
+#define PCLK_HDMI_CTRL		361
+#define PCLK_VIO_H2P		362
+#define PCLK_BUS		363
+#define PCLK_PERI		364
+#define PCLK_DDRUPCTL		365
+#define PCLK_DDRPHY		366
+#define PCLK_ISP		367
+#define PCLK_VIP		368
+#define PCLK_WDT		369
+
+/* hclk gates */
+#define HCLK_SFC		448
+#define HCLK_HOST0		450
+#define HCLK_HOST1		451
+#define HCLK_HSIC		452
+#define HCLK_NANDC0		453
+#define HCLK_TSP		455
+#define HCLK_SDMMC		456
+#define HCLK_SDIO0		457
+#define HCLK_EMMC		459
+#define HCLK_HSADC		460
+#define HCLK_CRYPTO		461
+#define HCLK_I2S0_8CH		462
+#define HCLK_I2S1_8CH		463
+#define HCLK_I2S2_8CH		464
+#define HCLK_SPDIF		465
+#define HCLK_VOPB		466
+#define HCLK_VOPL		467
+#define HCLK_ROM		468
+#define HCLK_IEP		469
+#define HCLK_ISP		470
+#define HCLK_RGA		471
+#define HCLK_VIO_AHB_ARBI	472
+#define HCLK_VIO_NOC		473
+#define HCLK_VIP		474
+#define HCLK_VIO_H2P		475
+#define HCLK_VIO_HDCPMMU	476
+#define HCLK_VIDEO		477
+#define HCLK_BUS		478
+#define HCLK_PERI		479
+
+/* pmu-clocks indices */
+#define SCLK_CM0S		500
+#define SCLK_SPI5		501
+#define SCLK_TIMER12		502
+#define SCLK_TIMER13		503
+#define SCLK_UART		504
+
+#define CLK_NR_CLKS		(SCLK_UART + 1)
+
+/* soft-reset indices */
+
+/* cru_softrst_con0 */
+#define SRST_CORE_L0			0
+#define SRST_CORE_B0			1
+#define SRST_CORE_PO_L0			2
+#define SRST_CORE_PO_B0			3
+#define SRST_L2_L			4
+#define SRST_L2_B			5
+#define SRST_ADB_L			6
+#define SRST_ADB_B			7
+#define SRST_A_CCI			8
+#define SRST_A_CCIM0_NIU		9
+#define SRST_A_CCIM1_NIU		10
+#define SRST_DBG_NIU			11
+
+/* cru_softrst_con1 */
+#define SRST_CORE_L0_T			16
+#define SRST_CORE_L1			17
+#define SRST_CORE_L2			18
+#define SRST_CORE_L3			19
+#define SRST_CORE_PO_L0_T		20
+#define SRST_CORE_PO_L1			21
+#define SRST_CORE_PO_L2			22
+#define SRST_CORE_PO_L3			23
+#define SRST_A_ADB400_GIC2_CORE_L	24
+#define SRST_A_ADB400_CORE_L_GIC2	25
+#define SRST_P_DBG_L			26
+#define SRST_SOC_DBG_L			27
+#define SRST_L2_L_T			28
+#define SRST_ADB_L_T			29
+#define SRST_A_RKREF_L			30
+#define SRST_PVTM_CORE_L		31
+
+/* cru_softrst_con2 */
+#define SRST_CORE_B0_T			32
+#define SRST_CORE_B1			33
+#define SRST_CORE_PO_B0_T		36
+#define SRST_CORE_PO_B1			37
+#define SRST_A_ADB400_GIC2_CORE_B	40
+#define SRST_A_ADB400_CORE_B_GIC2	41
+#define SRST_P_DBG_B			42
+#define SRST_L2_B_T			43
+#define SRST_SOC_DBG_B			44
+#define SRST_ADB_B_T			45
+#define SRST_A_RKREF_B			46
+#define SRST_PVTM_CORE_B		47
+
+/* cru_softrst_con3 */
+#define SRST_A_CCI_T			50
+#define SRST_A_CCIM0_NIU_T		51
+#define SRST_A_CCIM1_NIU_T		52
+#define SRST_A_ADB400M_PD_CORE_B_T	53
+#define SRST_A_ADB400M_PD_CORE_L_T	54
+#define SRST_DBG_NIU_T			55
+#define SRST_DBG_CXCS			56
+#define SRST_CCI_TRACE			57
+#define SRST_P_CCI_GRF			58
+
+/* cru_softrst_con4 */
+#define SRST_A_CENTER_MAIN_NIU		64
+#define SRST_A_CENTER_PERI_NIU		65
+#define SRST_P_CENTER_MAIN		66
+#define SRST_P_DDRMAON			67
+#define SRST_P_CIC			68
+#define SRST_P_CENTER_SGRF		69
+#define SRST_DDR0_MSCH			70
+#define SRST_DDRCFG0_MSCH		71
+#define SRST_DDR0			72
+#define SRST_DDRPHY0			73
+#define SRST_DDR1_MSCH			74
+#define SRST_DDRCFG1_MSCH		75
+#define SRST_DDR1			76
+#define SRST_DDRPHY1			77
+#define SRST_DDR_CIC			78
+#define SRST_PVTM_DDR			79
+
+/* cru_softrst_con5 */
+#define SRST_A_VCODEC_NIU		80
+#define SRST_A_VCODEC			81
+#define SRST_H_VCODEC_NIU		82
+#define SRST_H_VCODEC			83
+#define SRST_A_VDU_NIU			88
+#define SRST_A_VDU 			89
+#define SRST_H_VDU_NIU			90
+#define SRST_H_VDU			91
+#define SRST_VDU_CORE			92
+#define SRST_VDU_CA			93
+
+/* cru_softrst_con6 */
+#define SRST_A_IEP_NIU			96
+#define SRST_A_VOP_IEP			97
+#define SRST_A_IEP			98
+#define SRST_H_IEP_NIU			99
+#define SRST_H_IEP			100
+#define SRST_A_RGA_NIU			102
+#define SRST_A_RGA			103
+#define SRST_H_RGA_NIU			104
+#define SRST_H_RGA			105
+#define SRST_RGA_CORE			106
+#define SRST_EMMC_NIU			108
+#define SRST_EMMC			109
+#define SRST_EMMC_GRF			110
+#define SRST_EMMCPHY_SYSRX		111
+
+/* cru_softrst_con7 */
+#define SRST_A_PERIHP_NIU		112
+#define SRST_A_PERIHP_GRF		113
+#define SRST_H_PERIHP_NIU		114
+#define SRST_USBHOST0 			115
+#define SRST_HOSTC0_AUX			116
+#define SRST_HOSTC0_ARB			117
+#define SRST_USBHOST1			118
+#define SRST_HOSTC1_AUX			119
+#define SRST_HOSTC1_ARB			120
+#define SRST_SDIO0			121
+#define SRST_SDMMC			122
+#define SRST_HSIC			123
+#define SRST_HSIC_AUX			124
+#define SRST_AHB1TOM			125
+#define SRST_P_PERIHP_NIU		126
+#define SRST_HSICPHY			127
+
+/* cru_softrst_con8 */
+#define SRST_A_PCIE			128
+#define SRST_P_PCIE			129
+#define SRST_PCIE_CORE			130
+#define SRST_PCIE_MGMT			131
+#define SRST_PCIE_MGMT_STICKY		132
+#define SRST_PCIE_PIPE			133
+#define SRST_PCIE_PM			134
+#define SRST_PCIEPHY			135
+#define SRST_A_GMAC_NIU			136
+#define SRST_A_GMAC 			137
+#define SRST_P_GMAC_NIU			138
+#define SRST_P_GMAC			139
+#define SRST_P_GMAC_GRF			140
+#define SRST_HSICPHY_POR		142
+#define SRST_HSICPHY_UTMI		143
+
+/* cru_softrst_con9 */
+#define SRST_USB2PHY0_POR		144
+#define SRST_USB2PHY0_UTMI_PORT0	145
+#define SRST_USB2PHY0_UTMI_PORT1	146
+#define SRST_USB2PHY0_EHCIPHY		147
+#define SRST_UPHY0_PIPE_L00		148
+#define SRST_UPHY0			149
+#define SRST_UPHY0_TCPDPWRUP		150
+#define SRST_USB2PHY1_POR		152
+#define SRST_USB2PHY1_UTMI_PORT0	153
+#define SRST_USB2PHY1_UTMI_PORT1	154
+#define SRST_USB2PHY1_EHCIPHY		155
+#define SRST_UPHY1_PIPE_L00		156
+#define SRST_UPHY1			157
+#define SRST_UPHY1_TCPDPWRUP		158
+
+/* cru_softrst_con10 */
+#define SRST_A_PERILP0_NIU		160
+#define SRST_A_DCF			161
+#define SRST_GIC500			162
+#define SRST_DMAC0_PERILP0		163
+#define SRST_DMAC1_PERILP0		164
+#define SRST_TZMA			165
+#define SRST_INTMEM			166
+#define SRST_ADB400_MST0		167
+#define SRST_ADB400_MST1		168
+#define SRST_ADB400_SLV0		169
+#define SRST_ADB400_SLV1		170
+#define SRST_H_PERILP0			171
+#define SRST_H_PERILP0_NIU		172
+#define SRST_ROM			173
+#define SRST_CRYPTO_S			174
+#define SRST_CRYPTO_M			175
+
+/* cru_softrst_con11 */
+#define SRST_P_DCF			176
+#define SRST_CM0S_NIU			177
+#define SRST_CM0S			178
+#define SRST_CM0S_DBG			179
+#define SRST_CM0S_PO			180
+#define SRST_CRYPTO			181
+#define SRST_P_PERILP1_SGRF		182
+#define SRST_P_PERILP1_GRF		183
+#define SRST_CRYPTO1_S			184
+#define SRST_CRYPTO1_M			185
+#define SRST_CRYPTO1			186
+#define SRST_GIC_NIU			188
+#define SRST_SD_NIU			189
+#define SRST_SDIOAUDIO_BRG		190
+
+/* cru_softrst_con12 */
+#define SRST_H_PERILP1			192
+#define SRST_H_PERILP1_NIU		193
+#define SRST_H_I2S0_8CH			194
+#define SRST_H_I2S1_8CH			195
+#define SRST_H_I2S2_8CH			196
+#define SRST_H_SPDIF_8CH		197
+#define SRST_P_PERILP1_NIU		198
+#define SRST_P_EFUSE_1024		199
+#define SRST_P_EFUSE_1024S		200
+#define SRST_P_I2C0			201
+#define SRST_P_I2C1			202
+#define SRST_P_I2C2			203
+#define SRST_P_I2C3			204
+#define SRST_P_I2C4			205
+#define SRST_P_I2C5			206
+#define SRST_P_MAILBOX0			207
+
+/* cru_softrst_con13 */
+#define SRST_P_UART0			208
+#define SRST_P_UART1			209
+#define SRST_P_UART2			210
+#define SRST_P_UART3			211
+#define SRST_P_SARADC			212
+#define SRST_P_TSADC			213
+#define SRST_P_SPI0			214
+#define SRST_P_SPI1			215
+#define SRST_P_SPI2			216
+#define SRST_P_SPI3			217
+#define SRST_P_SPI4			218
+#define SRST_SPI0			219
+#define SRST_SPI1			220
+#define SRST_SPI2			221
+#define SRST_SPI3			222
+#define SRST_SPI4			223
+
+/* cru_softrst_con14 */
+#define SRST_I2S0_8CH			224
+#define SRST_I2S1_8CH			225
+#define SRST_I2S2_8CH			226
+#define SRST_SPDIF_8CH			227
+#define SRST_UART0			228
+#define SRST_UART1			229
+#define SRST_UART2			230
+#define SRST_UART3			231
+#define SRST_TSADC			232
+#define SRST_I2C0			233
+#define SRST_I2C1			234
+#define SRST_I2C2			235
+#define SRST_I2C3			236
+#define SRST_I2C4			237
+#define SRST_I2C5			238
+#define SRST_SDIOAUDIO_NIU		239
+
+/* cru_softrst_con15 */
+#define SRST_A_VIO_NIU			240
+#define SRST_A_HDCP_NIU			241
+#define SRST_A_HDCP			242
+#define SRST_H_HDCP_NIU			243
+#define SRST_H_HDCP			244
+#define SRST_P_HDCP_NIU			245
+#define SRST_P_HDCP			246
+#define SRST_P_HDMI_CTRL		247
+#define SRST_P_DP_CTRL			248
+#define SRST_S_DP_CTRL			249
+#define SRST_C_DP_CTRL			250
+#define SRST_P_MIPI_DSI0		251
+#define SRST_P_MIPI_DSI1		252
+#define SRST_DP_CORE			253
+#define SRST_DP_I2S			254
+#define SRST_DP_VIF			255
+
+/* cru_softrst_con16 */
+#define SRST_GASKET			256
+#define SRST_VIO_SGRF			257
+#define SRST_VIO_GRF			258
+#define SRST_DPTX_SPDIF_REC		259
+#define SRST_HDMI_CTRL			260
+#define SRST_HDCP_CTRL			261
+#define SRST_A_ISP0_NIU			262
+#define SRST_A_ISP1_NIU			263
+#define SRST_A_ISP0			264
+#define SRST_A_ISP1			265
+#define SRST_H_ISP0_NIU			266
+#define SRST_H_ISP1_NIU			267
+#define SRST_H_ISP0			268
+#define SRST_H_ISP1			269
+#define SRST_ISP0			270
+#define SRST_ISP1			271
+
+/* cru_softrst_con17 */
+#define SRST_A_VOP0_NIU			272
+#define SRST_A_VOP1_NIU			273
+#define SRST_A_VOP0			274
+#define SRST_A_VOP1			275
+#define SRST_H_VOP0_NIU			276
+#define SRST_H_VOP1_NIU			277
+#define SRST_H_VOP0			278
+#define SRST_H_VOP1			279
+#define SRST_D_VOP0			280
+#define SRST_D_VOP1			281
+#define SRST_VOP0_PWM			282
+#define SRST_VOP1_PWM			283
+#define SRST_P_EDP_NIU			284
+#define SRST_P_EDP_CTRL			285
+
+/* cru_softrst_con18 */
+#define SRST_A_GPU			288
+#define SRST_A_GPU_NIU			289
+#define SRST_A_GPU_GRF			290
+#define SRST_PVTM_GPU			291
+#define SRST_A_USB3_NIU			292
+#define SRST_A_USB3_OTG0		293
+#define SRST_A_USB3_OTG1		294
+#define SRST_A_USB3_GRF			295
+#define SRST_PMU			296
+#define SRST_PVTM_PMU			297
+
+/* cru_softrst_con19 */
+#define SRST_P_TIMER0_5			304
+#define SRST_TIMER0			305
+#define SRST_TIMER1			306
+#define SRST_TIMER2			307
+#define SRST_TIMER3			308
+#define SRST_TIMER4			309
+#define SRST_TIME5			310
+#define SRST_P_TIMER6_11		311
+#define SRST_TIMER6			312
+#define SRST_TIMER7			313
+#define SRST_TIMER8			314
+#define SRST_TIMER9			315
+#define SRST_TIMER10			316
+#define SRST_TIMER11			317
+#define SRST_P_INTR_ARB_PMU		318
+#define SRST_P_ALIVE_SGRF		319
+
+/* cru_softrst_con20 */
+#define SRST_P_GPIO2			320
+#define SRST_P_GPIO3			321
+#define SRST_P_GPIO4			322
+#define SRST_P_GRF			323
+#define SRST_P_ALIVE_NIU		324
+#define SRST_P_WDT0			325
+#define SRST_P_WDT1			326
+#define SRST_P_INTR_ARB 		327
+#define SRST_P_UPHY0_DPTX		328
+#define SRST_P_UPHY1_DPTX		329
+#define SRST_P_UPHY0_APB		330
+#define SRST_P_UPHY1_APB		331
+#define SRST_P_UPHY0_TCPHY		332
+#define SRST_P_UPHY1_TCPHY		333
+#define SRST_P_UPHY0_TCPDCTRL		334
+#define SRST_P_UPHY1_TCPDCTRL		335
+
+/* pmu soft-reset indices */
+
+/* pmu_cru_softrst_con0 */
+#define SRST_P_NIU			0
+#define SRST_P_INTMEN			1
+#define SRST_H_CM0S			2
+#define SRST_H_CM0S_NIU			3
+#define SRST_DBG_CM0S			4
+#define SRST_PO_CM0S			5
+#define SRST_P_SPI6			6
+#define SRST_SPI6			7
+#define SRST_P_TIMER_0_1		8
+#define SRST_P_TIMER_0			9
+#define SRST_P_TIMER_1			10
+#define SRST_P_UART4			11
+#define SRST_UART4			12
+#define SRST_P_WDT			13
+
+/* pmu_cru_softrst_con1 */
+#define SRST_P_I2C6			16
+#define SRST_P_I2C7			17
+#define SRST_P_I2C8			18
+#define SRST_P_MAILBOX			19
+#define SRST_P_RKPWM			20
+#define SRST_P_PMUGRF			21
+#define SRST_P_SGRF			22
+#define SRST_P_GPIO0			23
+#define SRST_P_GPIO1			24
+#define SRST_P_CRU			25
+#define SRST_P_INTR			26
+#define SRST_PVTM 			27
+#define SRST_I2C6			28
+#define SRST_I2C7			29
+#define SRST_I2C8			30
+
+#endif
-- 
1.9.1




From jay.xu at rock-chips.com  Thu Feb 18 17:56:15 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Fri, 19 Feb 2016 09:56:15 +0800
Subject: [PATCH v4 3/6] spi: rockchip: add bindings for rk3399 spi
In-Reply-To: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
References: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455846978-4272-4-git-send-email-jay.xu@rock-chips.com>

From: Jianqun Xu <jay.xu at rock-chips.com>

Add devicetree bindings for Rockchip rk3399 spi which found on
Rockchip rk3399 SoCs.

Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
changes in v4:
- none
changes in v3:
- add compatible for rk3399 spi (Mark, Heiko)
changes in v2:
- none

 Documentation/devicetree/bindings/spi/spi-rockchip.txt | 1 +
 drivers/spi/spi-rockchip.c                             | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
index 0c491bd..1b14d69 100644
--- a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
+++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
@@ -9,6 +9,7 @@ Required Properties:
     "rockchip,rk3066-spi" for rk3066.
     "rockchip,rk3188-spi", "rockchip,rk3066-spi" for rk3188.
     "rockchip,rk3288-spi", "rockchip,rk3066-spi" for rk3288.
+    "rockchip,rk3399-spi", "rockchip,rk3066-spi" for rk3399.
 - reg: physical base address of the controller and length of memory mapped
        region.
 - interrupts: The interrupt number to the cpu. The interrupt specifier format
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 79a8bc4..345fefd 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -868,6 +868,7 @@ static const struct of_device_id rockchip_spi_dt_match[] = {
 	{ .compatible = "rockchip,rk3066-spi", },
 	{ .compatible = "rockchip,rk3188-spi", },
 	{ .compatible = "rockchip,rk3288-spi", },
+	{ .compatible = "rockchip,rk3399-spi", },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, rockchip_spi_dt_match);
-- 
1.9.1




From jay.xu at rock-chips.com  Thu Feb 18 17:56:16 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Fri, 19 Feb 2016 09:56:16 +0800
Subject: [PATCH v4 4/6] ASoC: rockchip: add bindings for rk3399 i2s
In-Reply-To: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
References: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455846978-4272-5-git-send-email-jay.xu@rock-chips.com>

From: Jianqun Xu <jay.xu at rock-chips.com>

Add devicetree bindings for i2s controller found on rk3399
processors from rockchip.

Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v4:
- restore
- add acked-by (Rob)
changes in v3:
- none
changes in v2:
- removed

 Documentation/devicetree/bindings/sound/rockchip-i2s.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
index b7f3a93..6e86d8a 100644
--- a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
@@ -9,6 +9,7 @@ Required properties:
    - "rockchip,rk3066-i2s": for rk3066
    - "rockchip,rk3188-i2s", "rockchip,rk3066-i2s": for rk3188
    - "rockchip,rk3288-i2s", "rockchip,rk3066-i2s": for rk3288
+   - "rockchip,rk3399-i2s", "rockchip,rk3066-i2s": for rk3399
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: should contain the I2S interrupt.
-- 
1.9.1




From jay.xu at rock-chips.com  Thu Feb 18 17:59:46 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Fri, 19 Feb 2016 09:59:46 +0800
Subject: [PATCH v4 5/6] dt-bindings: add documentation of rk3399 clock
 controller
In-Reply-To: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
References: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455847186-4423-1-git-send-email-jay.xu@rock-chips.com>

From: Xing Zheng <zhengxing at rock-chips.com>

Add the devicetree binding for the cru on the rk3399 which quite
similar structured as previous clock controllers.

Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v4:
- none
changes in v3:
- none
changes in v2:
- none

 .../bindings/clock/rockchip,rk3399-cru.txt         | 82 ++++++++++++++++++++++
 1 file changed, 82 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
new file mode 100644
index 0000000..07bcc6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
@@ -0,0 +1,82 @@
+* Rockchip RK3399 Clock and Reset Unit
+
+The RK3399 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: PMU for CRU should be "rockchip,rk3399-pmucru"
+- compatible: CRU should be "rockchip,rk3399-cru"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+  If missing, pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "xin32k" - rtc clock - optional,
+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_gmac" - external GMAC clock - optional
+ - "ext_hsadc" - external HSADC clock - optional,
+ - "ext_isp" - external ISP clock - optional,
+ - "ext_jtag" - external JTAG clock - optional
+ - "ext_vip" - external VIP clock - optional,
+ - "usbotg_out" - output clock of the pll in the otg phy
+
+Example: General Register Files
+
+	pmugrf: syscon at ff320000 {
+		compatible = "rockchip,rk3399-pmugrf", "syscon";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+	};
+
+	grf: syscon at ff770000 {
+		compatible = "rockchip,rk3399-grf", "syscon";
+		reg = <0x0 0xff770000 0x0 0x10000>;
+	};
+
+Example: Clock controller node:
+
+	pmucru: pmu-clock-controller at ff750000 {
+		compatible = "rockchip,rk3399-pmucru";
+		reg = <0x0 0xff750000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at ff760000 {
+		compatible = "rockchip,rk3399-cru";
+		reg = <0x0 0xff760000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller:
+
+	uart0: serial at ff1a0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff180000 0x0 0x100>;
+		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+	};
-- 
1.9.1




From jay.xu at rock-chips.com  Thu Feb 18 18:03:47 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Fri, 19 Feb 2016 10:03:47 +0800
Subject: [PATCH 6/6] ARM64: dts: rockchip: add core dtsi file for rk3399
In-Reply-To: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
References: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455847427-4498-1-git-send-email-jay.xu@rock-chips.com>

From: Jianqun Xu <jay.xu at rock-chips.com>

Add dtsi file for Rockchip rk3399 SoCs with some
general nodes such as cpu, timer, cru, gic, amba.

Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v4:
- none
changes in v3:
- none
changes in v2:
- drop pmu and psci temporary (Mark)
- drop two applied patches (Heiko)
- drop GIC_CPU_MASK_SIMPLE from the interrupt specifiers (Marc, Heiko)
- drop clock-frequency of timer (Marc, Mark)

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 949 +++++++++++++++++++++++++++++++
 1 file changed, 949 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 0000000..00fb38a
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,949 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+#include <dt-bindings/clock/rk3399-cru.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+
+/ {
+	compatible = "rockchip,rk3399";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu_l0>;
+				};
+				core1 {
+					cpu = <&cpu_l1>;
+				};
+				core2 {
+					cpu = <&cpu_l2>;
+				};
+				core3 {
+					cpu = <&cpu_l3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu_b0>;
+				};
+				core1 {
+					cpu = <&cpu_b1>;
+				};
+			};
+		};
+
+		cpu_l0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x0>;
+		};
+
+		cpu_l1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x1>;
+		};
+
+		cpu_l2: cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x2>;
+		};
+
+		cpu_l3: cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x3>;
+		};
+
+		cpu_b0: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x0 0x100>;
+		};
+
+		cpu_b1: cpu at 101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x0 0x101>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	xin24m: xin24m {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24000000>;
+		clock-output-names = "xin24m";
+	};
+
+	gic: interrupt-controller at fee00000 {
+		compatible = "arm,gic-v3";
+		#interrupt-cells = <3>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		interrupt-controller;
+
+		reg = <0x0 0xfee00000 0 0x10000>, /* GICD */
+		      <0x0 0xfef00000 0 0xc0000>, /* GICR */
+		      <0x0 0xfff00000 0 0x10000>, /* GICC */
+		      <0x0 0xfff10000 0 0x10000>, /* GICH */
+		      <0x0 0xfff20000 0 0x10000>; /* GICV */
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH)>;
+		its: interrupt-controller at fee20000 {
+			compatible = "arm,gic-v3-its";
+			msi-controller;
+			reg = <0x0 0xfee20000 0x0 0x20000>;
+		};
+	};
+
+	amba {
+		compatible = "arm,amba-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		dmac_bus: dma-controller at ff6d0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x0 0xff6d0000 0x0 0x4000>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			clocks = <&cru ACLK_DMAC_BUS>;
+			clock-names = "apb_pclk";
+		};
+
+		dmac_peri: dma-controller at ff6e0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x0 0xff6e0000 0x0 0x4000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			clocks = <&cru ACLK_DMAC_PERI>;
+			clock-names = "apb_pclk";
+		};
+	};
+
+	uart0: serial at ff180000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff180000 0x0 0x100>;
+		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart1: serial at ff190000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff190000 0x0 0x100>;
+		clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart2: serial at ff1a0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff1a0000 0x0 0x100>;
+		clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart3: serial at ff1b0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff1b0000 0x0 0x100>;
+		clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	spi0: spi at ff1c0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff110000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI0>, <&cru PCLK_SPI0>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi0_clk &spi0_tx &spi0_rx &spi0_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi1: spi at ff1d0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff120000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI1>, <&cru PCLK_SPI1>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi1_clk &spi1_tx &spi1_rx &spi1_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi2: spi at ff1e0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff130000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI2>, <&cru PCLK_SPI2>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi2_clk &spi2_tx &spi2_rx &spi2_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi4: spi at ff1f0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff120000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI4>, <&cru PCLK_SPI4>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi4_clk &spi4_tx &spi4_rx &spi4_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi5: spi at ff200000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff130000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI5>, <&cru PCLK_SPI5>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi5_clk &spi5_tx &spi5_rx &spi5_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	pmugrf: syscon at ff320000 {
+		compatible = "rockchip,rk3399-pmugrf", "syscon";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+	};
+
+	spi3: spi at ff350000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff110000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI3>, <&cru PCLK_SPI3>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi3_clk &spi3_tx &spi3_rx &spi3_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	uart4: serial at ff370000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff370000 0x0 0x100>;
+		clocks = <&cru SCLK_UART4>, <&cru PCLK_UART4>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	pmucru: pmu-clock-controller at ff750000 {
+		compatible = "rockchip,rk3399-pmucru";
+		reg = <0x0 0xff750000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at ff760000 {
+		compatible = "rockchip,rk3399-cru";
+		reg = <0x0 0xff760000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	grf: syscon at ff770000 {
+		compatible = "rockchip,rk3399-grf", "syscon";
+		reg = <0x0 0xff770000 0x0 0x10000>;
+	};
+
+	i2s0: i2s at ff880000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff880000 0x0 0x1000>;
+		interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 0>, <&dmac_bus 1>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S0_8CH>, <&cru SCLK_I2S0_8CH>;
+		status = "disabled";
+	};
+
+	i2s1: i2s at ff890000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff890000 0x0 0x1000>;
+		interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 2>, <&dmac_bus 3>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S1_8CH>, <&cru SCLK_I2S1_8CH>;
+		status = "disabled";
+	};
+
+	i2s2: i2s at ff8a0000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff8a0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 4>, <&dmac_bus 5>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S2_8CH>, <&cru SCLK_I2S2_8CH>;
+		status = "disabled";
+	};
+
+	pinctrl: pinctrl {
+		compatible = "rockchip,rk3399-pinctrl";
+		rockchip,grf = <&grf>;
+		rockchip,pmu = <&pmugrf>;
+		#address-cells = <0x2>;
+		#size-cells = <0x2>;
+		ranges;
+
+		gpio0: gpio0 at ff720000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff720000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio1: gpio1 at ff730000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff730000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio2: gpio2 at ff780000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff780000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio3: gpio3 at ff788000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff788000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio4: gpio4 at ff790000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff790000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		pcfg_pull_up: pcfg-pull-up {
+			bias-pull-up;
+		};
+
+		pcfg_pull_down: pcfg-pull-down {
+			bias-pull-down;
+		};
+
+		pcfg_pull_none: pcfg-pull-none {
+			bias-disable;
+		};
+
+		pcfg_pull_none_12ma: pcfg-pull-none-12ma {
+			bias-disable;
+			drive-strength = <12>;
+		};
+
+		pcfg_pull_up_8ma: pcfg-pull-up-8ma {
+			bias-pull-up;
+			drive-strength = <8>;
+		};
+
+		pcfg_pull_down_4ma: pcfg-pull-down-4ma {
+			bias-pull-down;
+			drive-strength = <4>;
+		};
+
+		pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+			bias-pull-up;
+			drive-strength = <2>;
+		};
+
+		pcfg_pull_down_12ma: pcfg-pull-down-12ma {
+			bias-pull-down;
+			drive-strength = <12>;
+		};
+
+		emmc {
+			emmc_pwr: emmc-pwr {
+				rockchip,pins =
+					<0 5 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		gmac {
+			rgmii_pins: rgmii-pins {
+				rockchip,pins =
+					<3 11 RK_FUNC_1 &pcfg_pull_none>,
+					<3 13 RK_FUNC_1 &pcfg_pull_none>,
+					<3 8 RK_FUNC_1 &pcfg_pull_none>,
+					<3 4 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 5 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 0 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 1 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 17 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 12 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 6 RK_FUNC_1 &pcfg_pull_none>,
+					<3 7 RK_FUNC_1 &pcfg_pull_none>,
+					<3 2 RK_FUNC_1 &pcfg_pull_none>,
+					<3 3 RK_FUNC_1 &pcfg_pull_none>,
+					<3 14 RK_FUNC_1 &pcfg_pull_none>,
+					<3 9 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			rmii_pins: rmii-pins {
+				rockchip,pins =
+					<3 11 RK_FUNC_1 &pcfg_pull_none>,
+					<3 13 RK_FUNC_1 &pcfg_pull_none>,
+					<3 8 RK_FUNC_1 &pcfg_pull_none>,
+					<3 4 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 5 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 12 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 6 RK_FUNC_1 &pcfg_pull_none>,
+					<3 7 RK_FUNC_1 &pcfg_pull_none>,
+					<3 9 RK_FUNC_1 &pcfg_pull_none>,
+					<3 10 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c0 {
+			i2c0_xfer: i2c0-xfer {
+				rockchip,pins =
+					<1 15 RK_FUNC_2 &pcfg_pull_none>,
+					<1 16 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c1 {
+			i2c1_xfer: i2c1-xfer {
+				rockchip,pins =
+					<4 2 RK_FUNC_1 &pcfg_pull_none>,
+					<4 1 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c2 {
+			i2c2_xfer: i2c2-xfer {
+				rockchip,pins =
+					<2 1 RK_FUNC_2 &pcfg_pull_none_12ma>,
+					<2 0 RK_FUNC_2 &pcfg_pull_none_12ma>;
+			};
+		};
+
+		i2c3 {
+			i2c3_xfer: i2c3-xfer {
+				rockchip,pins =
+					<4 17 RK_FUNC_1 &pcfg_pull_none>,
+					<4 16 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c4 {
+			i2c4_xfer: i2c4-xfer {
+				rockchip,pins =
+					<1 12 RK_FUNC_1 &pcfg_pull_none>,
+					<1 11 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c5 {
+			i2c5_xfer: i2c5-xfer {
+				rockchip,pins =
+					<3 11 RK_FUNC_2 &pcfg_pull_none>,
+					<3 10 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c6 {
+			i2c6_xfer: i2c6-xfer {
+				rockchip,pins =
+					<2 10 RK_FUNC_2 &pcfg_pull_none>,
+					<2 9 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c7 {
+			i2c7_xfer: i2c7-xfer {
+				rockchip,pins =
+					<2 8 RK_FUNC_2 &pcfg_pull_none>,
+					<2 7 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c8 {
+			i2c8_xfer: i2c8-xfer {
+				rockchip,pins =
+					<1 21 RK_FUNC_1 &pcfg_pull_none>,
+					<1 20 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2s0 {
+			i2s0_8ch_bus: i2s0-8ch-bus {
+				rockchip,pins =
+					<3 24 RK_FUNC_1 &pcfg_pull_none>,
+					<3 25 RK_FUNC_1 &pcfg_pull_none>,
+					<3 26 RK_FUNC_1 &pcfg_pull_none>,
+					<3 27 RK_FUNC_1 &pcfg_pull_none>,
+					<3 28 RK_FUNC_1 &pcfg_pull_none>,
+					<3 29 RK_FUNC_1 &pcfg_pull_none>,
+					<3 30 RK_FUNC_1 &pcfg_pull_none>,
+					<3 31 RK_FUNC_1 &pcfg_pull_none>,
+					<4 0 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2s1 {
+			i2s1_2ch_bus: i2s1-2ch-bus {
+				rockchip,pins =
+					<4 3 RK_FUNC_1 &pcfg_pull_none>,
+					<4 4 RK_FUNC_1 &pcfg_pull_none>,
+					<4 5 RK_FUNC_1 &pcfg_pull_none>,
+					<4 6 RK_FUNC_1 &pcfg_pull_none>,
+					<4 7 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		sdio0 {
+			sdio0_bus1: sdio0-bus1 {
+				rockchip,pins =
+					<2 20 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_bus4: sdio0-bus4 {
+				rockchip,pins =
+					<2 20 RK_FUNC_1 &pcfg_pull_up>,
+					<2 21 RK_FUNC_1 &pcfg_pull_up>,
+					<2 22 RK_FUNC_1 &pcfg_pull_up>,
+					<2 23 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_cmd: sdio0-cmd {
+				rockchip,pins =
+					<2 24 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_clk: sdio0-clk {
+				rockchip,pins =
+					<2 25 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			sdio0_cd: sdio0-cd {
+				rockchip,pins =
+					<2 26 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_pwr: sdio0-pwr {
+				rockchip,pins =
+					<2 27 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_bkpwr: sdio0-bkpwr {
+				rockchip,pins =
+					<2 28 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_wp: sdio0-wp {
+				rockchip,pins =
+					<0 3 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_int: sdio0-int {
+				rockchip,pins =
+					<0 4 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		sdmmc {
+			sdmmc_bus1: sdmmc-bus1 {
+				rockchip,pins =
+					<4 8 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_bus4: sdmmc-bus4 {
+				rockchip,pins =
+					<4 8 RK_FUNC_1 &pcfg_pull_up>,
+					<4 9 RK_FUNC_1 &pcfg_pull_up>,
+					<4 10 RK_FUNC_1 &pcfg_pull_up>,
+					<4 11 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_clk: sdmmc-clk {
+				rockchip,pins =
+					<4 12 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			sdmmc_cmd: sdmmc-cmd {
+				rockchip,pins =
+					<4 13 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_cd: sdmcc-cd {
+				rockchip,pins =
+					<0 7 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_wp: sdmmc-wp {
+				rockchip,pins =
+					<0 8 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi0 {
+			spi0_clk: spi0-clk {
+				rockchip,pins =
+					<3 6 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_cs0: spi0-cs0 {
+				rockchip,pins =
+					<3 7 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_cs1: spi0-cs1 {
+				rockchip,pins =
+					<3 8 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_tx: spi0-tx {
+				rockchip,pins =
+					<3 5 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_rx: spi0-rx {
+				rockchip,pins =
+					<3 4 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi1 {
+			spi1_clk: spi1-clk {
+				rockchip,pins =
+					<1 9 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_cs0: spi1-cs0 {
+				rockchip,pins =
+					<1 10 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_rx: spi1-rx {
+				rockchip,pins =
+					<1 7 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_tx: spi1-tx {
+				rockchip,pins =
+					<1 8 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi2 {
+			spi2_clk: spi2-clk {
+				rockchip,pins =
+					<2 11 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_cs0: spi2-cs0 {
+				rockchip,pins =
+					<2 12 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_rx: spi2-rx {
+				rockchip,pins =
+					<2 9 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_tx: spi2-tx {
+				rockchip,pins =
+					<2 10 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi3 {
+			spi3_clk: spi3-clk {
+				rockchip,pins =
+					<1 17 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_cs0: spi3-cs0 {
+				rockchip,pins =
+					<1 18 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_rx: spi3-rx {
+				rockchip,pins =
+					<1 15 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_tx: spi3-tx {
+				rockchip,pins =
+					<1 16 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi4 {
+			spi4_clk: spi4-clk {
+				rockchip,pins =
+					<3 2 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_cs0: spi4-cs0 {
+				rockchip,pins =
+					<3 3 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_rx: spi4-rx {
+				rockchip,pins =
+					<3 0 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_tx: spi4-tx {
+				rockchip,pins =
+					<3 1 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi5 {
+			spi5_clk: spi5-clk {
+				rockchip,pins =
+					<2 22 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_cs0: spi5-cs0 {
+				rockchip,pins =
+					<2 23 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_rx: spi5-rx {
+				rockchip,pins =
+					<2 20 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_tx: spi5-tx {
+				rockchip,pins =
+					<2 21 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		uart0 {
+			uart0_xfer: uart0-xfer {
+				rockchip,pins =
+					<2 16 RK_FUNC_1 &pcfg_pull_up>,
+					<2 17 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			uart0_cts: uart0-cts {
+				rockchip,pins =
+					<2 18 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			uart0_rts: uart0-rts {
+				rockchip,pins =
+					<2 19 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uart1 {
+			uart1_xfer: uart1-xfer {
+				rockchip,pins =
+					<3 12 RK_FUNC_2 &pcfg_pull_up>,
+					<3 13 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2a {
+			uart2a_xfer: uart2a-xfer {
+				rockchip,pins =
+					<4 8 RK_FUNC_2 &pcfg_pull_up>,
+					<4 9 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2b {
+			uart2b_xfer: uart2b-xfer {
+				rockchip,pins =
+					<4 16 RK_FUNC_2 &pcfg_pull_up>,
+					<4 17 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2c {
+			uart2c_xfer: uart2c-xfer {
+				rockchip,pins =
+					<4 19 RK_FUNC_1 &pcfg_pull_up>,
+					<4 20 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uart3 {
+			uart3_xfer: uart3-xfer {
+				rockchip,pins =
+					<3 14 RK_FUNC_2 &pcfg_pull_up>,
+					<3 15 RK_FUNC_2 &pcfg_pull_none>;
+			};
+
+			uart3_cts: uart3-cts {
+				rockchip,pins =
+					<3 18 RK_FUNC_2 &pcfg_pull_none>;
+			};
+
+			uart3_rts: uart3-rts {
+				rockchip,pins =
+					<3 19 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart4 {
+			uart4_xfer: uart4-xfer {
+				rockchip,pins =
+					<1 7 RK_FUNC_1 &pcfg_pull_up>,
+					<1 8 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uarthdcp {
+			uarthdcp_xfer: uarthdcp-xfer {
+				rockchip,pins =
+					<4 21 RK_FUNC_2 &pcfg_pull_up>,
+					<4 22 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		pwm0 {
+			pwm0_pin: pwm0-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			vop0_pwm_pin: vop0-pwm-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		pwm1 {
+			pwm1_pin: pwm1-pin {
+				rockchip,pins =
+					<4 22 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			vop1_pwm_pin: vop1-pwm-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_3 &pcfg_pull_none>;
+			};
+		};
+	};
+};
-- 
1.9.1




From jay.xu at rock-chips.com  Thu Feb 18 18:05:40 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Fri, 19 Feb 2016 10:05:40 +0800
Subject: [PATCH v4 6/6] ARM64: dts: rockchip: add core dtsi file for rk3399
In-Reply-To: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
References: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1455847540-4545-1-git-send-email-jay.xu@rock-chips.com>

From: Jianqun Xu <jay.xu at rock-chips.com>

Add dtsi file for Rockchip rk3399 SoCs with some
general nodes such as cpu, timer, cru, gic, amba.

Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v4:
- none
changes in v3:
- none
changes in v2:
- drop pmu and psci temporary (Mark)
- drop two applied patches (Heiko)
- drop GIC_CPU_MASK_SIMPLE from the interrupt specifiers (Marc, Heiko)
- drop clock-frequency of timer (Marc, Mark)

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 949 +++++++++++++++++++++++++++++++
 1 file changed, 949 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 0000000..00fb38a
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,949 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+#include <dt-bindings/clock/rk3399-cru.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+
+/ {
+	compatible = "rockchip,rk3399";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu_l0>;
+				};
+				core1 {
+					cpu = <&cpu_l1>;
+				};
+				core2 {
+					cpu = <&cpu_l2>;
+				};
+				core3 {
+					cpu = <&cpu_l3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu_b0>;
+				};
+				core1 {
+					cpu = <&cpu_b1>;
+				};
+			};
+		};
+
+		cpu_l0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x0>;
+		};
+
+		cpu_l1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x1>;
+		};
+
+		cpu_l2: cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x2>;
+		};
+
+		cpu_l3: cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x3>;
+		};
+
+		cpu_b0: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x0 0x100>;
+		};
+
+		cpu_b1: cpu at 101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x0 0x101>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	xin24m: xin24m {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24000000>;
+		clock-output-names = "xin24m";
+	};
+
+	gic: interrupt-controller at fee00000 {
+		compatible = "arm,gic-v3";
+		#interrupt-cells = <3>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		interrupt-controller;
+
+		reg = <0x0 0xfee00000 0 0x10000>, /* GICD */
+		      <0x0 0xfef00000 0 0xc0000>, /* GICR */
+		      <0x0 0xfff00000 0 0x10000>, /* GICC */
+		      <0x0 0xfff10000 0 0x10000>, /* GICH */
+		      <0x0 0xfff20000 0 0x10000>; /* GICV */
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH)>;
+		its: interrupt-controller at fee20000 {
+			compatible = "arm,gic-v3-its";
+			msi-controller;
+			reg = <0x0 0xfee20000 0x0 0x20000>;
+		};
+	};
+
+	amba {
+		compatible = "arm,amba-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		dmac_bus: dma-controller at ff6d0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x0 0xff6d0000 0x0 0x4000>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			clocks = <&cru ACLK_DMAC_BUS>;
+			clock-names = "apb_pclk";
+		};
+
+		dmac_peri: dma-controller at ff6e0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x0 0xff6e0000 0x0 0x4000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			clocks = <&cru ACLK_DMAC_PERI>;
+			clock-names = "apb_pclk";
+		};
+	};
+
+	uart0: serial at ff180000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff180000 0x0 0x100>;
+		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart1: serial at ff190000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff190000 0x0 0x100>;
+		clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart2: serial at ff1a0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff1a0000 0x0 0x100>;
+		clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart3: serial at ff1b0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff1b0000 0x0 0x100>;
+		clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	spi0: spi at ff1c0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff110000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI0>, <&cru PCLK_SPI0>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi0_clk &spi0_tx &spi0_rx &spi0_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi1: spi at ff1d0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff120000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI1>, <&cru PCLK_SPI1>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi1_clk &spi1_tx &spi1_rx &spi1_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi2: spi at ff1e0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff130000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI2>, <&cru PCLK_SPI2>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi2_clk &spi2_tx &spi2_rx &spi2_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi4: spi at ff1f0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff120000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI4>, <&cru PCLK_SPI4>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi4_clk &spi4_tx &spi4_rx &spi4_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi5: spi at ff200000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff130000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI5>, <&cru PCLK_SPI5>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi5_clk &spi5_tx &spi5_rx &spi5_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	pmugrf: syscon at ff320000 {
+		compatible = "rockchip,rk3399-pmugrf", "syscon";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+	};
+
+	spi3: spi at ff350000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff110000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI3>, <&cru PCLK_SPI3>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi3_clk &spi3_tx &spi3_rx &spi3_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	uart4: serial at ff370000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff370000 0x0 0x100>;
+		clocks = <&cru SCLK_UART4>, <&cru PCLK_UART4>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	pmucru: pmu-clock-controller at ff750000 {
+		compatible = "rockchip,rk3399-pmucru";
+		reg = <0x0 0xff750000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at ff760000 {
+		compatible = "rockchip,rk3399-cru";
+		reg = <0x0 0xff760000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	grf: syscon at ff770000 {
+		compatible = "rockchip,rk3399-grf", "syscon";
+		reg = <0x0 0xff770000 0x0 0x10000>;
+	};
+
+	i2s0: i2s at ff880000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff880000 0x0 0x1000>;
+		interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 0>, <&dmac_bus 1>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S0_8CH>, <&cru SCLK_I2S0_8CH>;
+		status = "disabled";
+	};
+
+	i2s1: i2s at ff890000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff890000 0x0 0x1000>;
+		interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 2>, <&dmac_bus 3>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S1_8CH>, <&cru SCLK_I2S1_8CH>;
+		status = "disabled";
+	};
+
+	i2s2: i2s at ff8a0000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff8a0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 4>, <&dmac_bus 5>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S2_8CH>, <&cru SCLK_I2S2_8CH>;
+		status = "disabled";
+	};
+
+	pinctrl: pinctrl {
+		compatible = "rockchip,rk3399-pinctrl";
+		rockchip,grf = <&grf>;
+		rockchip,pmu = <&pmugrf>;
+		#address-cells = <0x2>;
+		#size-cells = <0x2>;
+		ranges;
+
+		gpio0: gpio0 at ff720000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff720000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio1: gpio1 at ff730000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff730000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio2: gpio2 at ff780000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff780000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio3: gpio3 at ff788000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff788000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio4: gpio4 at ff790000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff790000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		pcfg_pull_up: pcfg-pull-up {
+			bias-pull-up;
+		};
+
+		pcfg_pull_down: pcfg-pull-down {
+			bias-pull-down;
+		};
+
+		pcfg_pull_none: pcfg-pull-none {
+			bias-disable;
+		};
+
+		pcfg_pull_none_12ma: pcfg-pull-none-12ma {
+			bias-disable;
+			drive-strength = <12>;
+		};
+
+		pcfg_pull_up_8ma: pcfg-pull-up-8ma {
+			bias-pull-up;
+			drive-strength = <8>;
+		};
+
+		pcfg_pull_down_4ma: pcfg-pull-down-4ma {
+			bias-pull-down;
+			drive-strength = <4>;
+		};
+
+		pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+			bias-pull-up;
+			drive-strength = <2>;
+		};
+
+		pcfg_pull_down_12ma: pcfg-pull-down-12ma {
+			bias-pull-down;
+			drive-strength = <12>;
+		};
+
+		emmc {
+			emmc_pwr: emmc-pwr {
+				rockchip,pins =
+					<0 5 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		gmac {
+			rgmii_pins: rgmii-pins {
+				rockchip,pins =
+					<3 11 RK_FUNC_1 &pcfg_pull_none>,
+					<3 13 RK_FUNC_1 &pcfg_pull_none>,
+					<3 8 RK_FUNC_1 &pcfg_pull_none>,
+					<3 4 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 5 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 0 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 1 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 17 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 12 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 6 RK_FUNC_1 &pcfg_pull_none>,
+					<3 7 RK_FUNC_1 &pcfg_pull_none>,
+					<3 2 RK_FUNC_1 &pcfg_pull_none>,
+					<3 3 RK_FUNC_1 &pcfg_pull_none>,
+					<3 14 RK_FUNC_1 &pcfg_pull_none>,
+					<3 9 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			rmii_pins: rmii-pins {
+				rockchip,pins =
+					<3 11 RK_FUNC_1 &pcfg_pull_none>,
+					<3 13 RK_FUNC_1 &pcfg_pull_none>,
+					<3 8 RK_FUNC_1 &pcfg_pull_none>,
+					<3 4 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 5 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 12 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 6 RK_FUNC_1 &pcfg_pull_none>,
+					<3 7 RK_FUNC_1 &pcfg_pull_none>,
+					<3 9 RK_FUNC_1 &pcfg_pull_none>,
+					<3 10 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c0 {
+			i2c0_xfer: i2c0-xfer {
+				rockchip,pins =
+					<1 15 RK_FUNC_2 &pcfg_pull_none>,
+					<1 16 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c1 {
+			i2c1_xfer: i2c1-xfer {
+				rockchip,pins =
+					<4 2 RK_FUNC_1 &pcfg_pull_none>,
+					<4 1 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c2 {
+			i2c2_xfer: i2c2-xfer {
+				rockchip,pins =
+					<2 1 RK_FUNC_2 &pcfg_pull_none_12ma>,
+					<2 0 RK_FUNC_2 &pcfg_pull_none_12ma>;
+			};
+		};
+
+		i2c3 {
+			i2c3_xfer: i2c3-xfer {
+				rockchip,pins =
+					<4 17 RK_FUNC_1 &pcfg_pull_none>,
+					<4 16 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c4 {
+			i2c4_xfer: i2c4-xfer {
+				rockchip,pins =
+					<1 12 RK_FUNC_1 &pcfg_pull_none>,
+					<1 11 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c5 {
+			i2c5_xfer: i2c5-xfer {
+				rockchip,pins =
+					<3 11 RK_FUNC_2 &pcfg_pull_none>,
+					<3 10 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c6 {
+			i2c6_xfer: i2c6-xfer {
+				rockchip,pins =
+					<2 10 RK_FUNC_2 &pcfg_pull_none>,
+					<2 9 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c7 {
+			i2c7_xfer: i2c7-xfer {
+				rockchip,pins =
+					<2 8 RK_FUNC_2 &pcfg_pull_none>,
+					<2 7 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c8 {
+			i2c8_xfer: i2c8-xfer {
+				rockchip,pins =
+					<1 21 RK_FUNC_1 &pcfg_pull_none>,
+					<1 20 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2s0 {
+			i2s0_8ch_bus: i2s0-8ch-bus {
+				rockchip,pins =
+					<3 24 RK_FUNC_1 &pcfg_pull_none>,
+					<3 25 RK_FUNC_1 &pcfg_pull_none>,
+					<3 26 RK_FUNC_1 &pcfg_pull_none>,
+					<3 27 RK_FUNC_1 &pcfg_pull_none>,
+					<3 28 RK_FUNC_1 &pcfg_pull_none>,
+					<3 29 RK_FUNC_1 &pcfg_pull_none>,
+					<3 30 RK_FUNC_1 &pcfg_pull_none>,
+					<3 31 RK_FUNC_1 &pcfg_pull_none>,
+					<4 0 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2s1 {
+			i2s1_2ch_bus: i2s1-2ch-bus {
+				rockchip,pins =
+					<4 3 RK_FUNC_1 &pcfg_pull_none>,
+					<4 4 RK_FUNC_1 &pcfg_pull_none>,
+					<4 5 RK_FUNC_1 &pcfg_pull_none>,
+					<4 6 RK_FUNC_1 &pcfg_pull_none>,
+					<4 7 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		sdio0 {
+			sdio0_bus1: sdio0-bus1 {
+				rockchip,pins =
+					<2 20 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_bus4: sdio0-bus4 {
+				rockchip,pins =
+					<2 20 RK_FUNC_1 &pcfg_pull_up>,
+					<2 21 RK_FUNC_1 &pcfg_pull_up>,
+					<2 22 RK_FUNC_1 &pcfg_pull_up>,
+					<2 23 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_cmd: sdio0-cmd {
+				rockchip,pins =
+					<2 24 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_clk: sdio0-clk {
+				rockchip,pins =
+					<2 25 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			sdio0_cd: sdio0-cd {
+				rockchip,pins =
+					<2 26 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_pwr: sdio0-pwr {
+				rockchip,pins =
+					<2 27 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_bkpwr: sdio0-bkpwr {
+				rockchip,pins =
+					<2 28 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_wp: sdio0-wp {
+				rockchip,pins =
+					<0 3 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_int: sdio0-int {
+				rockchip,pins =
+					<0 4 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		sdmmc {
+			sdmmc_bus1: sdmmc-bus1 {
+				rockchip,pins =
+					<4 8 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_bus4: sdmmc-bus4 {
+				rockchip,pins =
+					<4 8 RK_FUNC_1 &pcfg_pull_up>,
+					<4 9 RK_FUNC_1 &pcfg_pull_up>,
+					<4 10 RK_FUNC_1 &pcfg_pull_up>,
+					<4 11 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_clk: sdmmc-clk {
+				rockchip,pins =
+					<4 12 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			sdmmc_cmd: sdmmc-cmd {
+				rockchip,pins =
+					<4 13 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_cd: sdmcc-cd {
+				rockchip,pins =
+					<0 7 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_wp: sdmmc-wp {
+				rockchip,pins =
+					<0 8 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi0 {
+			spi0_clk: spi0-clk {
+				rockchip,pins =
+					<3 6 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_cs0: spi0-cs0 {
+				rockchip,pins =
+					<3 7 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_cs1: spi0-cs1 {
+				rockchip,pins =
+					<3 8 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_tx: spi0-tx {
+				rockchip,pins =
+					<3 5 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_rx: spi0-rx {
+				rockchip,pins =
+					<3 4 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi1 {
+			spi1_clk: spi1-clk {
+				rockchip,pins =
+					<1 9 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_cs0: spi1-cs0 {
+				rockchip,pins =
+					<1 10 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_rx: spi1-rx {
+				rockchip,pins =
+					<1 7 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_tx: spi1-tx {
+				rockchip,pins =
+					<1 8 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi2 {
+			spi2_clk: spi2-clk {
+				rockchip,pins =
+					<2 11 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_cs0: spi2-cs0 {
+				rockchip,pins =
+					<2 12 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_rx: spi2-rx {
+				rockchip,pins =
+					<2 9 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_tx: spi2-tx {
+				rockchip,pins =
+					<2 10 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi3 {
+			spi3_clk: spi3-clk {
+				rockchip,pins =
+					<1 17 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_cs0: spi3-cs0 {
+				rockchip,pins =
+					<1 18 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_rx: spi3-rx {
+				rockchip,pins =
+					<1 15 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_tx: spi3-tx {
+				rockchip,pins =
+					<1 16 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi4 {
+			spi4_clk: spi4-clk {
+				rockchip,pins =
+					<3 2 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_cs0: spi4-cs0 {
+				rockchip,pins =
+					<3 3 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_rx: spi4-rx {
+				rockchip,pins =
+					<3 0 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_tx: spi4-tx {
+				rockchip,pins =
+					<3 1 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi5 {
+			spi5_clk: spi5-clk {
+				rockchip,pins =
+					<2 22 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_cs0: spi5-cs0 {
+				rockchip,pins =
+					<2 23 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_rx: spi5-rx {
+				rockchip,pins =
+					<2 20 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_tx: spi5-tx {
+				rockchip,pins =
+					<2 21 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		uart0 {
+			uart0_xfer: uart0-xfer {
+				rockchip,pins =
+					<2 16 RK_FUNC_1 &pcfg_pull_up>,
+					<2 17 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			uart0_cts: uart0-cts {
+				rockchip,pins =
+					<2 18 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			uart0_rts: uart0-rts {
+				rockchip,pins =
+					<2 19 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uart1 {
+			uart1_xfer: uart1-xfer {
+				rockchip,pins =
+					<3 12 RK_FUNC_2 &pcfg_pull_up>,
+					<3 13 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2a {
+			uart2a_xfer: uart2a-xfer {
+				rockchip,pins =
+					<4 8 RK_FUNC_2 &pcfg_pull_up>,
+					<4 9 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2b {
+			uart2b_xfer: uart2b-xfer {
+				rockchip,pins =
+					<4 16 RK_FUNC_2 &pcfg_pull_up>,
+					<4 17 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2c {
+			uart2c_xfer: uart2c-xfer {
+				rockchip,pins =
+					<4 19 RK_FUNC_1 &pcfg_pull_up>,
+					<4 20 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uart3 {
+			uart3_xfer: uart3-xfer {
+				rockchip,pins =
+					<3 14 RK_FUNC_2 &pcfg_pull_up>,
+					<3 15 RK_FUNC_2 &pcfg_pull_none>;
+			};
+
+			uart3_cts: uart3-cts {
+				rockchip,pins =
+					<3 18 RK_FUNC_2 &pcfg_pull_none>;
+			};
+
+			uart3_rts: uart3-rts {
+				rockchip,pins =
+					<3 19 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart4 {
+			uart4_xfer: uart4-xfer {
+				rockchip,pins =
+					<1 7 RK_FUNC_1 &pcfg_pull_up>,
+					<1 8 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uarthdcp {
+			uarthdcp_xfer: uarthdcp-xfer {
+				rockchip,pins =
+					<4 21 RK_FUNC_2 &pcfg_pull_up>,
+					<4 22 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		pwm0 {
+			pwm0_pin: pwm0-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			vop0_pwm_pin: vop0-pwm-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		pwm1 {
+			pwm1_pin: pwm1-pin {
+				rockchip,pins =
+					<4 22 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			vop1_pwm_pin: vop1-pwm-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_3 &pcfg_pull_none>;
+			};
+		};
+	};
+};
-- 
1.9.1




From zhizhou.zh at gmail.com  Thu Feb 18 18:30:09 2016
From: zhizhou.zh at gmail.com (Zhi-zhou)
Date: Fri, 19 Feb 2016 10:30:09 +0800
Subject: [PATCH] arm64: add architecture specified current_pt_regs
In-Reply-To: <20160218115824.GA2538@e104818-lin.cambridge.arm.com>
References: <1455796115-7844-1-git-send-email-zhizhou.zh@gmail.com>
 <20160218115824.GA2538@e104818-lin.cambridge.arm.com>
Message-ID: <CAN1e=SF4iAVZzvs=+rJxmUX_z7KNSwegxWaor3gDfXD-=MAQ4Q@mail.gmail.com>

On Thu, Feb 18, 2016 at 7:58 PM, Catalin Marinas
<catalin.marinas at arm.com> wrote:
>
> On Thu, Feb 18, 2016 at 07:48:35PM +0800, Zhi-zhou Zhang wrote:
> > From: zhizhou <zhizhou.zh at gmail.com>
> >
> > This patch is based on the implementation of arm. The generic
> > current_pt_regs is implemented with current->stack. It need to access
> > memory that would be too expensive.
>
> Do you have any performance numbers?

I'm using QEMU, so no. Actually this macro isn't heavily used. I just
think using the generic
implementation is not very nice. It get task_struct from sp_el0, then
get stack(which is
equal to sp_el0) from task_struct. There are two unnecessary memory accesses.
>
>
> > diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> > index e9e5467..1865d54 100644
> > --- a/arch/arm64/include/asm/ptrace.h
> > +++ b/arch/arm64/include/asm/ptrace.h
> > @@ -185,5 +185,9 @@ static inline int valid_user_regs(struct user_pt_regs *regs)
> >
> >  extern unsigned long profile_pc(struct pt_regs *regs);
> >
> > +#define current_pt_regs(void) ({ (struct pt_regs *)                  \
> > +     ((current_stack_pointer | (THREAD_SIZE - 1)) - 0xf) - 1;        \
> > +})
>
> I don't think this works well with the separate IRQ stack that we merged
> in 4.5-rc1. current_thread_info() explicitly uses "sp_el0" while
> current_stack_pointer is just "sp" (though I don't think we ever use
> current_pt_regs in interrupt context).
>
Thank you, that's a problem. So how about write it like this?

diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index e9e5467..b68e01c 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -185,5 +185,10 @@ static inline int valid_user_regs(struct
user_pt_regs *regs)

 extern unsigned long profile_pc(struct pt_regs *regs);

+#define current_pt_regs(void) ({ (struct pt_regs *)            \
+               (((unsigned long)current_thread_info() |        \
+               (THREAD_SIZE - 1)) - 0xf) - 1;                  \
+})
+
 #endif /* __ASSEMBLY__ */
 #endif

> --
> Catalin




-- 
Regards,
Zhi-zhou


From sboyd at codeaurora.org  Thu Feb 18 18:36:45 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Feb 2016 18:36:45 -0800
Subject: [PATCH 1/2] clk: add lpc18xx creg clk driver
In-Reply-To: <CAGhQ9VxPt7FmE4JN_-rBJMNpLpGoKVKocVFPWc3siV29Pk0_mQ@mail.gmail.com>
References: <1436651307-24098-1-git-send-email-manabian@gmail.com>
 <1436651307-24098-2-git-send-email-manabian@gmail.com>
 <20150811204127.31346.16729@quantum>
 <CAGhQ9VwZaM_iWTkQYVTuTiyb6gCG2y6s8WFVySCHt7YHE1qbcA@mail.gmail.com>
 <20150818002604.31346.18322@quantum>
 <CAGhQ9VzOYbHsFZQxM8823OiWpGB6vLEwX8LfvjC=DnL1iqK_qQ@mail.gmail.com>
 <20160217005629.2278.90197@quark.deferred.io>
 <CAGhQ9VzB_WgB8b4_c3Z17W+K2MC7Fq7SD9zEvZUN_UJVGDZ3Wg@mail.gmail.com>
 <20160217202824.2278.25956@quark.deferred.io>
 <CAGhQ9VxPt7FmE4JN_-rBJMNpLpGoKVKocVFPWc3siV29Pk0_mQ@mail.gmail.com>
Message-ID: <20160219023645.GP4847@codeaurora.org>

On 02/17, Joachim Eastwood wrote:
> 
> For creg-clk it would probably work.
> 
> cgu would need to register most of clocks early since it needs to
> support whatever setup the bootloader throws at it. The only clocks
> that could be taken out is the base clocks (clk_onecell_data
> clk_base_data) except for one of them. But splitting this table would
> be a bad idea as hw clk numbers are used as indexes for easy look up.
> 
> Come to think of it; isn't splitting the clock table between a early
> init and platform driver going become a problem?
> At least the lookup in the driver or framework would become more complex(?)
> And won't you confuse the lookup?
> If the early driver register one clock table with
> of_clk_add_provider() and then sometime later the platform driver
> register another clock table, both using the same of_node. How is that
> suppose to work?

I believe that should work, although I haven't tested it. The
code looks until it finds a provider that matches the device node
and gives us a valid clk pointer. If we don't get a valid pointer
we keep looking for another provider until we exhaust all
providers.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From pc.liao at mediatek.com  Thu Feb 18 18:35:59 2016
From: pc.liao at mediatek.com (PC Liao)
Date: Fri, 19 Feb 2016 10:35:59 +0800
Subject: [PATCH] ASoC: mediatek: Add machine driver for ALC5650 codec
Message-ID: <1455849359-14581-1-git-send-email-pc.liao@mediatek.com>

From: Koro Chen <koro.chen at mediatek.com>

This is the DPCM based machine driver with rt5650

Signed-off-by: Nicolas Boichat <drinkcat at chromium.org>
Signed-off-by: Koro Chen <koro.chen at mediatek.com>
Signed-off-by: PC Liao <pc.liao at mediatek.com>
---
 .../devicetree/bindings/sound/mt8173-rt5650.txt    |   15 ++
 sound/soc/mediatek/Kconfig                         |   10 +
 sound/soc/mediatek/Makefile                        |    1 +
 sound/soc/mediatek/mt8173-rt5650.c                 |  236 ++++++++++++++++++++
 4 files changed, 262 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/mt8173-rt5650.txt
 create mode 100644 sound/soc/mediatek/mt8173-rt5650.c

diff --git a/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt b/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt
new file mode 100644
index 0000000..fe5a5ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt
@@ -0,0 +1,15 @@
+MT8173 with RT5650 CODECS
+
+Required properties:
+- compatible : "mediatek,mt8173-rt5650"
+- mediatek,audio-codec: the phandles of rt5650 codecs
+- mediatek,platform: the phandle of MT8173 ASoC platform
+
+Example:
+
+	sound {
+		compatible = "mediatek,mt8173-rt5650";
+		mediatek,audio-codec = <&rt5650>;
+		mediatek,platform = <&afe>;
+	};
+
diff --git a/sound/soc/mediatek/Kconfig b/sound/soc/mediatek/Kconfig
index 9769676..6c88087 100644
--- a/sound/soc/mediatek/Kconfig
+++ b/sound/soc/mediatek/Kconfig
@@ -17,6 +17,16 @@ config SND_SOC_MT8173_MAX98090
 	  Select Y if you have such device.
 	  If unsure select "N".
 
+config SND_SOC_MT8173_RT5650
+        tristate "ASoC Audio driver for MT8173 with RT5650 codec"
+        depends on SND_SOC_MEDIATEK && I2C
+        select SND_SOC_RT5645
+        help
+          This adds ASoC driver for Mediatek MT8173 boards
+          with the RT5650 audio codec.
+          Select Y if you have such device.
+          If unsure select "N".
+
 config SND_SOC_MT8173_RT5650_RT5676
 	tristate "ASoC Audio driver for MT8173 with RT5650 RT5676 codecs"
 	depends on SND_SOC_MEDIATEK && I2C
diff --git a/sound/soc/mediatek/Makefile b/sound/soc/mediatek/Makefile
index 75effbe..bcdcb06 100644
--- a/sound/soc/mediatek/Makefile
+++ b/sound/soc/mediatek/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_SND_SOC_MEDIATEK) += mtk-afe-pcm.o
 # Machine support
 obj-$(CONFIG_SND_SOC_MT8173_MAX98090) += mt8173-max98090.o
 obj-$(CONFIG_SND_SOC_MT8173_RT5650_RT5676) += mt8173-rt5650-rt5676.o
+obj-$(CONFIG_SND_SOC_MT8173_RT5650) += mt8173-rt5650.o
diff --git a/sound/soc/mediatek/mt8173-rt5650.c b/sound/soc/mediatek/mt8173-rt5650.c
new file mode 100644
index 0000000..bb09bb1
--- /dev/null
+++ b/sound/soc/mediatek/mt8173-rt5650.c
@@ -0,0 +1,236 @@
+/*
+ * mt8173-rt5650.c  --  MT8173 machine driver with RT5650 codecs
+ *
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Koro Chen <koro.chen at mediatek.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 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+#include <sound/soc.h>
+#include <sound/jack.h>
+#include "../codecs/rt5645.h"
+
+#define MCLK_FOR_CODECS		12288000
+
+static const struct snd_soc_dapm_widget mt8173_rt5650_widgets[] = {
+	SND_SOC_DAPM_SPK("Speaker", NULL),
+	SND_SOC_DAPM_MIC("Int Mic", NULL),
+	SND_SOC_DAPM_HP("Headphone", NULL),
+	SND_SOC_DAPM_MIC("Headset Mic", NULL),
+};
+
+static const struct snd_soc_dapm_route mt8173_rt5650_routes[] = {
+	{"Speaker", NULL, "SPOL"},
+	{"Speaker", NULL, "SPOR"},
+	{"DMIC L1", NULL, "Int Mic"},
+	{"DMIC R1", NULL, "Int Mic"},
+	{"Headphone", NULL, "HPOL"},
+	{"Headphone", NULL, "HPOR"},
+	{"Headset Mic", NULL, "micbias1"},
+	{"Headset Mic", NULL, "micbias2"},
+	{"IN1P", NULL, "Headset Mic"},
+	{"IN1N", NULL, "Headset Mic"},
+};
+
+static const struct snd_kcontrol_new mt8173_rt5650_controls[] = {
+	SOC_DAPM_PIN_SWITCH("Speaker"),
+	SOC_DAPM_PIN_SWITCH("Int Mic"),
+	SOC_DAPM_PIN_SWITCH("Headphone"),
+	SOC_DAPM_PIN_SWITCH("Headset Mic"),
+};
+
+static int mt8173_rt5650_hw_params(struct snd_pcm_substream *substream,
+				   struct snd_pcm_hw_params *params)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	int i, ret;
+
+	for (i = 0; i < rtd->num_codecs; i++) {
+		struct snd_soc_dai *codec_dai = rtd->codec_dais[i];
+
+		/* pll from mclk 12.288M */
+		ret = snd_soc_dai_set_pll(codec_dai, 0, 0, MCLK_FOR_CODECS,
+					  params_rate(params) * 512);
+		if (ret)
+			return ret;
+
+		/* sysclk from pll */
+		ret = snd_soc_dai_set_sysclk(codec_dai, 1,
+					     params_rate(params) * 512,
+					     SND_SOC_CLOCK_IN);
+		if (ret)
+			return ret;
+	}
+	return 0;
+}
+
+static struct snd_soc_ops mt8173_rt5650_ops = {
+	.hw_params = mt8173_rt5650_hw_params,
+};
+
+static struct snd_soc_jack mt8173_rt5650_jack;
+
+static int mt8173_rt5650_init(struct snd_soc_pcm_runtime *runtime)
+{
+	struct snd_soc_card *card = runtime->card;
+	struct snd_soc_codec *codec = runtime->codec_dais[0]->codec;
+	int ret;
+
+	rt5645_sel_asrc_clk_src(codec,
+				RT5645_DA_STEREO_FILTER |
+				RT5645_AD_STEREO_FILTER,
+				RT5645_CLK_SEL_I2S1_ASRC);
+	/* enable jack detection */
+	ret = snd_soc_card_jack_new(card, "Headset Jack",
+				    SND_JACK_HEADPHONE | SND_JACK_MICROPHONE |
+				    SND_JACK_BTN_0 | SND_JACK_BTN_1 |
+				    SND_JACK_BTN_2 | SND_JACK_BTN_3,
+				    &mt8173_rt5650_jack, NULL, 0);
+	if (ret) {
+		dev_err(card->dev, "Can't new Headset Jack %d\n", ret);
+		return ret;
+	}
+
+	return rt5645_set_jack_detect(codec,
+				      &mt8173_rt5650_jack,
+				      &mt8173_rt5650_jack,
+				      &mt8173_rt5650_jack);
+}
+
+static struct snd_soc_dai_link_component mt8173_rt5650_codecs[] = {
+	{
+		.dai_name = "rt5645-aif1",
+	},
+};
+
+enum {
+	DAI_LINK_PLAYBACK,
+	DAI_LINK_CAPTURE,
+	DAI_LINK_CODEC_I2S,
+};
+
+/* Digital audio interface glue - connects codec <---> CPU */
+static struct snd_soc_dai_link mt8173_rt5650_dais[] = {
+	/* Front End DAI links */
+	[DAI_LINK_PLAYBACK] = {
+		.name = "rt5650 Playback",
+		.stream_name = "rt5650 Playback",
+		.cpu_dai_name = "DL1",
+		.codec_name = "snd-soc-dummy",
+		.codec_dai_name = "snd-soc-dummy-dai",
+		.trigger = {SND_SOC_DPCM_TRIGGER_POST, SND_SOC_DPCM_TRIGGER_POST},
+		.dynamic = 1,
+		.dpcm_playback = 1,
+	},
+	[DAI_LINK_CAPTURE] = {
+		.name = "rt5650 Capture",
+		.stream_name = "rt5650 Capture",
+		.cpu_dai_name = "VUL",
+		.codec_name = "snd-soc-dummy",
+		.codec_dai_name = "snd-soc-dummy-dai",
+		.trigger = {SND_SOC_DPCM_TRIGGER_POST, SND_SOC_DPCM_TRIGGER_POST},
+		.dynamic = 1,
+		.dpcm_capture = 1,
+	},
+	/* Back End DAI links */
+	[DAI_LINK_CODEC_I2S] = {
+		.name = "Codec",
+		.cpu_dai_name = "I2S",
+		.no_pcm = 1,
+		.codecs = mt8173_rt5650_codecs,
+		.num_codecs = 1,
+		.init = mt8173_rt5650_init,
+		.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+			   SND_SOC_DAIFMT_CBS_CFS,
+		.ops = &mt8173_rt5650_ops,
+		.ignore_pmdown_time = 1,
+		.dpcm_playback = 1,
+		.dpcm_capture = 1,
+	},
+};
+
+static struct snd_soc_card mt8173_rt5650_card = {
+	.name = "mtk-rt5650",
+	.owner = THIS_MODULE,
+	.dai_link = mt8173_rt5650_dais,
+	.num_links = ARRAY_SIZE(mt8173_rt5650_dais),
+	.controls = mt8173_rt5650_controls,
+	.num_controls = ARRAY_SIZE(mt8173_rt5650_controls),
+	.dapm_widgets = mt8173_rt5650_widgets,
+	.num_dapm_widgets = ARRAY_SIZE(mt8173_rt5650_widgets),
+	.dapm_routes = mt8173_rt5650_routes,
+	.num_dapm_routes = ARRAY_SIZE(mt8173_rt5650_routes),
+};
+
+static int mt8173_rt5650_dev_probe(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = &mt8173_rt5650_card;
+	struct device_node *platform_node;
+	int i, ret;
+
+	platform_node = of_parse_phandle(pdev->dev.of_node,
+					 "mediatek,platform", 0);
+	if (!platform_node) {
+		dev_err(&pdev->dev, "Property 'platform' missing or invalid\n");
+		return -EINVAL;
+	}
+
+	for (i = 0; i < card->num_links; i++) {
+		if (mt8173_rt5650_dais[i].platform_name)
+			continue;
+		mt8173_rt5650_dais[i].platform_of_node = platform_node;
+	}
+
+	mt8173_rt5650_codecs[0].of_node =
+		of_parse_phandle(pdev->dev.of_node, "mediatek,audio-codec", 0);
+	if (!mt8173_rt5650_codecs[0].of_node) {
+		dev_err(&pdev->dev,
+			"Property 'audio-codec' missing or invalid\n");
+		return -EINVAL;
+	}
+	card->dev = &pdev->dev;
+	platform_set_drvdata(pdev, card);
+
+	ret = devm_snd_soc_register_card(&pdev->dev, card);
+	if (ret)
+		dev_err(&pdev->dev, "%s snd_soc_register_card fail %d\n",
+			__func__, ret);
+	return ret;
+}
+
+static const struct of_device_id mt8173_rt5650_dt_match[] = {
+	{ .compatible = "mediatek,mt8173-rt5650", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, mt8173_rt5650_dt_match);
+
+static struct platform_driver mt8173_rt5650_driver = {
+	.driver = {
+		   .name = "mtk-rt5650",
+		   .of_match_table = mt8173_rt5650_dt_match,
+#ifdef CONFIG_PM
+		   .pm = &snd_soc_pm_ops,
+#endif
+	},
+	.probe = mt8173_rt5650_dev_probe,
+};
+
+module_platform_driver(mt8173_rt5650_driver);
+
+/* Module information */
+MODULE_DESCRIPTION("MT8173 RT5650 SoC machine driver");
+MODULE_AUTHOR("Koro Chen <koro.chen at mediatek.com>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:mtk-rt5650");
+
-- 
1.7.9.5



From sboyd at codeaurora.org  Thu Feb 18 18:43:50 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Feb 2016 18:43:50 -0800
Subject: [PATCH v3 5/6] dts: ipq4019: Add support for IPQ4019 DK01 board
In-Reply-To: <59152C1B-683F-417D-9C23-C6E3F53D7096@codeaurora.org>
References: <1447975173-29485-1-git-send-email-mmcclint@qca.qualcomm.com>
 <1447975173-29485-6-git-send-email-mmcclint@qca.qualcomm.com>
 <20160208224328.GB10791@codeaurora.org>
 <59152C1B-683F-417D-9C23-C6E3F53D7096@codeaurora.org>
Message-ID: <20160219024350.GQ4847@codeaurora.org>

On 02/16, Matthew McClintock wrote:
> On Feb 8, 2016, at 4:43 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
> > 
> > On 11/19, Matthew McClintock wrote:
> >> +
> >> +/ {
> >> +	model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK01.1";
> >> +	compatible = "qcom,ipq4019";
> >> +
> >> +	clocks {
> >> +                xo: xo {
> >> +                        compatible = "fixed-clock";
> >> +                        clock-frequency = <48000000>;
> >> +                        #clock-cells = <0>;
> >> +                };
> >> +	};
> > 
> > Is there a reason the xo is here and the sleep clk is in the SoC
> > dtsi file? Both are board clocks so I would think they would be
> > added in the same place.
> 
> I?m a little bit confused and I wanted to confirm. I can see the xo clock is on the board itself. However, the sleep_clk is not, can you clarify why they would both be in the same place?
> 

The sleep clk is typically a pin on the SoC package. Look at your
schematic. Same goes for the XO.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From jay.xu at rock-chips.com  Thu Feb 18 18:44:42 2016
From: jay.xu at rock-chips.com (Jianqun Xu)
Date: Fri, 19 Feb 2016 10:44:42 +0800
Subject: [PATCH v2.1 2/4] spi: rockchip: add bindings for rk3399 spi
In-Reply-To: <20160218135751.GE7129@sirena.org.uk>
References: <1455762983-29980-1-git-send-email-jay.xu@rock-chips.com>
 <1455762983-29980-3-git-send-email-jay.xu@rock-chips.com>
 <20160218094108.GA7129@sirena.org.uk> <2327512.KAqs6H56Km@phil>
 <56C5959D.3030806@rock-chips.com> <20160218135751.GE7129@sirena.org.uk>
Message-ID: <56C6819A.8090106@rock-chips.com>

Hi Mark

? 18/02/2016 21:57, Mark Brown ??:
> On Thu, Feb 18, 2016 at 05:57:49PM +0800, Jianqun Xu wrote:
>
>> I'm a little confuse, I have upstreamed rockchip-i2s, and the i2s driver set
>> the compatible like:
>> - compatible: should be one of the followings
>>     - "rockchip,rk3066-i2s": for rk3066
>>     - "rockchip,rk3188-i2s", "rockchip,rk3066-i2s": for rk3188
>>     - "rockchip,rk3288-i2s", "rockchip,rk3066-i2s": for rk3288
>>     - "rockchip,rk3399-i2s", "rockchip,rk3066-i2s": for rk3399
>> and the driver only has
>> static const struct of_device_id rockchip_i2s_match[] = {
>> 	{ .compatible = "rockchip,rk3066-i2s", },
>> 	{},
>> };
>
>> The spi of rk3399 as same as rk3066, rk3188, rk3288, like i2s, if they are
>> keep different rules ?
>
> No, that's just something that got missed in review and which should be
> fixed.
>
Got it, it's will be fixed in a separate patch later, thank you very much.



From lv.zheng at intel.com  Thu Feb 18 18:58:10 2016
From: lv.zheng at intel.com (Zheng, Lv)
Date: Fri, 19 Feb 2016 02:58:10 +0000
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <56C63FB5.2030907@hurleysoftware.com>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
 <56C470C5.2080203@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>
 <56C63FB5.2030907@hurleysoftware.com>
Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB4D5A0@SHSMSX101.ccr.corp.intel.com>

Hi,

> From: Peter Hurley [mailto:peter at hurleysoftware.com]
> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
> early_acpi_os_unmap_memory()
> 
> On 02/17/2016 07:36 PM, Zheng, Lv wrote:
> > Hi,
> >
> >> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
> >> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
> >> early_acpi_os_unmap_memory()
> >>
> >> Hi Lv,
> >>
> >> Thank you for review.
> >>
> >> On 02/17/2016 05:51 AM, Zheng, Lv wrote:
> >>
> >> [..]
> >>
> >>>>> early_acpi_os_unmap_memory() is marked as __init because it calls
> >>>>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is not
> >> set.
> >>>>>
> >>>>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
> >>>>> so it is safe to call early_acpi_os_unmap_memory() from anywhere
> >>>>>
> >>>>> We need this function to be non-__init because we need access to
> >>>>> some tables at unpredictable time--it may be before or after
> >>>>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port
> Console
> >>>>> Redirection) table is needed each time a new console is registered.
> >>>>> It can be quite early (console_initcall) or when a module is inserted.
> >>>>> When this table accessed before acpi_gbl_permanent_mmap is set,
> >>>>> the pointer should be unmapped.  This is exactly what this function
> >>>>> does.
> >>>> [Lv Zheng]
> >>>> Why don't you use another API instead of
> early_acpi_os_unmap_memory()
> >> in
> >>>> case you want to unmap things in any cases.
> >>>> acpi_os_unmap_memory() should be the one to match this purpose.
> >>>> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
> >>
> >> As far as I understand, there exist two steps in ACPI initialization:
> >>
> >> 1. Before acpi_gbl_permanent_mmap is set, tables received with
> >> acpi_get_table_with_size()
> >>    are mapped by early_memremap().  If a subsystem gets such a pointer it
> >> should be unmapped.
> >>
> >> 2  After acpi_gbl_permanent_mmap is set this pointer should not be
> unmapped
> >> at all.
> >>
> > [Lv Zheng]
> > This statement is wrong, this should be:
> > As long as there is a __reference__ to the mapped table, the pointer should
> not be unmapped.
> > In fact, we have a series to introduce acpi_put_table() to achieve this.
> > So your argument is wrong from very first point.
> >
> >> That exactly what early_acpi_os_unmap_memory() does--it checks
> >> acpi_gbl_permanent_mmap.
> >> If I had used acpi_os_unmap_memory() after acpi_gbl_permanent_mmap
> had
> >> been set,
> >> it would have tried to free that pointer with an oops (actually, I checked that
> >> and got that oops).
> >>
> >> So using acpi_os_unmap_memory() is not an option here, but
> >> early_acpi_os_unmap_memory()
> >> match perfectly.
> > [Lv Zheng]
> > I don't think so.
> > For definition block tables, we know for sure there will always be references,
> until "Unload" opcode is invoked by the AML interpreter.
> > But for the data tables, OSPMs should use them in this way:
> > 1. map the table
> > 2. parse the table and convert it to OS specific structures
> > 3. unmap the table
> > This helps to shrink virtual memory address space usages.
> >
> > So from this point of view, all data tables should be unmapped right after
> being parsed.
> > Why do you need the map to be persistent in the kernel address space?
> > You can always map a small table, but what if the table size is very big?
> >
> >>
> >>>> And in fact early_acpi_os_unmap_memory() should be removed.
> >>
> >> I don't think so -- I have explained why.  It does different thing.
> >> Probably it (and/or other functions in that api) should be renamed.
> >>
> > [Lv Zheng]
> > Just let me ask one more question.
> > eary_acpi_os_unmap_memory() is not used inside of ACPICA.
> > How ACPICA can work with just acpi_os_unmap_memory()?
> > You can check drivers/acpi/tbxxx.c.
> > Especially: acpi_tb_release_temp_table() and the code invoking it.
> >
> >>> [Lv Zheng]
> >>> One more thing is:
> >>> If you can't switch your driver to use acpi_os_unmap_memory() instead of
> >> early_acpi_os_unmap_memory(),
> >>> then it implies that your driver does have a defect.
> >>
> >> I still don't understand what defect, sorry.
> > [Lv Zheng]
> > If you can't ensure this sequence for using the data tables:
> > 1. map the table
> > 2. parse the table and convert it to OS specific structure
> > 3. unmap the table
> > It implies there is a bug in the driver or a bug in the ACPI subsystem core.
> 
> Exactly.
[Lv Zheng] 
So it looks to me:
Changing __init to __ref here is entirely not acceptable.
This API should stay being invoked during early stage.
Otherwise, it may leave us untrackable code that maps tables during early stage and leaks maps to the late stage.
If Linux contains such kind of code, I'm afraid, it will become impossible to introduce acpi_put_table() to clean up the mappings.
Because when acpi_put_table() is called during the late stage to free a map acquired during the early stage, it then obviously will end up with panic.

Thanks and best regards
-Lv

> The central problem here is the way Aleksey is trying to hookup a console.
> 
> What should be happening in this series is:
> 1. early map SPCR
> 2. parse the SPCR table
> 3. call add_preferred_console() to add the SPCR console to the console table
> 4. unmap SPCR
> 
> This trivial and unobtrusive method would already have a 8250 console
> running via SPCR. I've already pointed this out in previous reviews.
> 
> Further, the above method *will be required anyway* for the DBG2 table to
> start an earlycon, which I've already pointed out in previous reviews.
> 
> Then to enable amba-pl011 console via ACPI, add a console match() method
> similar to the 8250 console match() method, univ8250_console_match().
> 
> FWIW, PCI earlycon + console support was already submitted once before but
> never picked up by GregKH. I think I'll just grab that and re-submit so
> you would know what to emit for console options in the
> add_preferred_console().
> 
> 
> Regards,
> Peter Hurley
> 
> 
> >>> There is an early bootup requirement in Linux.
> >>> Maps acquired during the early stage should be freed by the driver during
> the
> >> early stage.
> >>> And the driver should re-acquire the memory map after booting.
> >>
> >> Exactly.  That's why I use early_acpi_os_unmap_memory().  The point is that
> >> that code can be
> >> called *before* acpi_gbl_permanent_mmap is set (at early initialization of
> for
> >> example 8250 console)
> >> or *after* acpi_gbl_permanent_mmap is set (at insertion of a module that
> >> registers a console),
> >> We just can not tell if the received table pointer should or sould not be freed
> >> with early_memunmap()
> >> (actually __acpi_unmap_table() or whatever) without checking
> >> acpi_gbl_permanent_mmap,
> >> but that's all too low level.
> > [Lv Zheng]
> > The driver should make sure that:
> > Map/unmap is paired during early stage.
> > For late stage, it should be another pair of map/unmap.
> >
> >>
> >> Another option, as you describe, is to get this pointer early, don't free it
> > [Lv Zheng]
> > I mean you should free it early.
> >
> >> untill acpi_gbl_permanent_mmap is set, then free it (with
> >> early_acpi_os_unmap_memory(), that's
> >> ok because acpi_gbl_permanent_mmap is set in an init code), then get the
> >> persistent
> >> pointer to the table.  The problem with it is that we can not just watch
> >> acpi_gbl_permanent_mmap
> >> to catch this exact moment.  And also accessing acpi_gbl_permanent_mmap
> is
> >> not good as it probably is
> >> an implementation detail (i. e. too lowlevel) of the ACPI code.
> >> Or I probably miss what you are suggesting.
> >>
> > [Lv Zheng]
> > I mean, you should:
> > During early stage:
> > acpi_os_map_memory()
> > Parse the table.
> > acpi_os_unmap_memory().
> >
> >>> This is because, during early bootup stage, there are only limited slots
> >> available for drivers to map memory.
> >>> So by changing __init to __ref here, you probably will hide many such
> defects.
> >>
> >> What defects?  This funcions checks acpi_gbl_permanent_mmap.
> >> BTW, exactly the same thing is done in the beginning of
> >> acpi_os_unmap_memory() and than's ok,
> >> that function is __ref.
> >>
> >>> And solving issues in this way doesn't seem to be an improvement.
> >>
> >> Could you please tell me where I am wrong?  I still don't understand your
> point.
> > [Lv Zheng]
> > But anyway, the defect should be in ACPI subsystem core.
> > The cause should be the API itself - acpi_get_table().
> >
> > So I agree you can use early_acpi_os_unmap_memory() during the period the
> root causes are not cleaned up.
> > But the bottom line is: the driver need to ensure that
> early_acpi_os_unmap_memory() is always invoked.
> > As long as you can ensure this, I don't have objections for deploying
> early_acpi_os_unmap_memory()  for now.
> >
> > Thanks and best regards
> > -Lv
> >
> >>
> >> Thank you
> >> Aleksey Makarov
> >>
> >>>
> >>> Thanks and best regards
> >>> -Lv
> >>>
> >>>>
> >>>> Thanks and best regards
> >>>> -Lv
> >>>>
> >>>>>
> >>>>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> >>>>> ---
> >>>>>  drivers/acpi/osl.c | 6 +++++-
> >>>>>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> >>>>> index 67da6fb..8a552cd 100644
> >>>>> --- a/drivers/acpi/osl.c
> >>>>> +++ b/drivers/acpi/osl.c
> >>>>> @@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void *virt,
> >>>>> acpi_size size)
> >>>>>  }
> >>>>>  EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
> >>>>>
> >>>>> -void __init early_acpi_os_unmap_memory(void __iomem *virt,
> acpi_size
> >>>> size)
> >>>>> +/*
> >>>>> + * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
> >>>>> + * so it is safe to call early_acpi_os_unmap_memory() from anywhere
> >>>>> + */
> >>>>> +void __ref early_acpi_os_unmap_memory(void __iomem *virt,
> acpi_size
> >>>> size)
> >>>>>  {
> >>>>>  	if (!acpi_gbl_permanent_mmap)
> >>>>>  		__acpi_unmap_table(virt, size);
> >>>>> --
> >>>>> 2.7.1
> >>>>>
> >>>>> --
> >>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> >>>>> the body of a message to majordomo at vger.kernel.org
> >>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>> --
> >>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> >>>> the body of a message to majordomo at vger.kernel.org
> >>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From sboyd at codeaurora.org  Thu Feb 18 19:07:31 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Feb 2016 19:07:31 -0800
Subject: [PATCH] clk: fix clk-gpio.c with optional clock= DT property
In-Reply-To: <20160218005503.GO19428@n2100.arm.linux.org.uk>
References: <E1aFJ0A-00086Z-0I@rmk-PC.arm.linux.org.uk>
 <20160217230529.GM19428@n2100.arm.linux.org.uk>
 <20160218000747.2278.46405@quark.deferred.io>
 <20160218005503.GO19428@n2100.arm.linux.org.uk>
Message-ID: <20160219030731.GS4847@codeaurora.org>

On 02/18, Russell King - ARM Linux wrote:
> This is even explained in the very first sentence of my commit
> log:
> 
> | When the clock DT property is not given, of_clk_get_parent_count()
>                                            ^^^^^^^^^^^^^^^^^^^^^^^^^
> | returns -ENOENT, which then tries to allocate -2 x 4 bytes of memory,
>   ^^^^^^^^^^^^^^^
> 
> -ENOENT is a negative number.  Now look at the patch which totally
> rejects the clock if of_clk_get_parent_count() returns any negative
> number...
> 
> I assume, therefore, that you did not *even* read my commit log...
> 

Ok. So the simplest fix is to just do this? I'll write up some
commit text and get this into the rc.

---8<---
diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 19fed65587e8..7b09a265d79f 100644
--- a/drivers/clk/clk-gpio.c
+++ b/drivers/clk/clk-gpio.c
@@ -289,7 +289,7 @@ static void __init of_gpio_clk_setup(struct device_node *node,
 
 	num_parents = of_clk_get_parent_count(node);
 	if (num_parents < 0)
-		return;
+		num_parents = 0;
 
 	data = kzalloc(sizeof(*data), GFP_KERNEL);
 	if (!data)

Maybe we should change of_clk_get_parent_count() to return an
unsigned int as well. I'm not sure why anyone would care whether
or not a node has "clocks" or not as a property. It seems that
all the callers of this function want to know how many parents
there are. In fact, some TI drivers assign the return value from
this function directly to clk_init_data::num_parents which is an
unsigned value. That's horribly broken if there isn't a proper DT
node.

So how about we apply this patch for the next release? We could
also change the return type to unsigned so that people don't get
the wrong idea. That type of change will be a bit larger though
because we'll have to remove impossible < 0 checks in drivers;
not a huge deal but slightly annoying. I can do that legwork
tomorrow.

----8<---
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 67cd2f116c3b..cdf18f76acb0 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3020,9 +3020,21 @@ struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
 	return __of_clk_get_from_provider(clkspec, NULL, __func__);
 }
 
+/**
+ * of_clk_get_parent_count() - Count the number of clocks a device node has
+ * @np: device node to count
+ *
+ * Returns: The number of clocks that are possible parents of this node
+ */
 int of_clk_get_parent_count(struct device_node *np)
 {
-	return of_count_phandle_with_args(np, "clocks", "#clock-cells");
+	int count;
+
+	count = of_count_phandle_with_args(np, "clocks", "#clock-cells");
+	if (count < 0)
+		return 0;
+
+	return count;
 }
 EXPORT_SYMBOL_GPL(of_clk_get_parent_count);
 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From sboyd at codeaurora.org  Thu Feb 18 19:12:05 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 18 Feb 2016 19:12:05 -0800
Subject: [PATCH] clk: gpio: Really allow an optional clock= DT property
In-Reply-To: <20160219030731.GS4847@codeaurora.org>
Message-ID: <1455851525-18972-1-git-send-email-sboyd@codeaurora.org>

We mis-merged the original patch from Russell here and so the
patch went almost all the way, except that we still failed to
probe when there wasn't a clocks property in the DT node. Allow
that case by making a negative value from
of_clk_get_parent_count() into "no parents", like the original
patch did.

Fixes: 7ed88aa2efa5 ("clk: fix clk-gpio.c with optional clock= DT property")
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
Cc: Michael Turquette <mturquette at baylibre.com>
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/clk-gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 19fed65587e8..7b09a265d79f 100644
--- a/drivers/clk/clk-gpio.c
+++ b/drivers/clk/clk-gpio.c
@@ -289,7 +289,7 @@ static void __init of_gpio_clk_setup(struct device_node *node,
 
 	num_parents = of_clk_get_parent_count(node);
 	if (num_parents < 0)
-		return;
+		num_parents = 0;
 
 	data = kzalloc(sizeof(*data), GFP_KERNEL);
 	if (!data)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



From anup.patel at broadcom.com  Thu Feb 18 19:14:20 2016
From: anup.patel at broadcom.com (Anup Patel)
Date: Fri, 19 Feb 2016 08:44:20 +0530
Subject: [PATCH v2 2/4] iommu/arm-smmu: Invoke DT probe from
 arm_smmu_of_setup()
In-Reply-To: <001f01d16a43$ef47d3b0$cdd77b10$@codeaurora.org>
References: <1454908652-15317-1-git-send-email-anup.patel@broadcom.com>
 <1454908652-15317-3-git-send-email-anup.patel@broadcom.com>
 <001f01d16a43$ef47d3b0$cdd77b10$@codeaurora.org>
Message-ID: <CAALAos-62Oo8KxODCvkLto5yeKfaTaXKfdrfVUz8nEmTb2p68Q@mail.gmail.com>

On Thu, Feb 18, 2016 at 5:30 PM, Sricharan <sricharan at codeaurora.org> wrote:
> Hi,
>
>> -----Original Message-----
>> From: linux-arm-kernel [mailto:linux-arm-kernel-
>> bounces at lists.infradead.org] On Behalf Of Anup Patel
>> Sent: Monday, February 08, 2016 10:48 AM
>> To: Catalin Marinas; Joerg Roedel; Will Deacon; Robin Murphy; Sricharan R;
>> Linux IOMMU; Linux ARM Kernel
>> Cc: Mark Rutland; Device Tree; Scott Branden; Pawel Moll; Ian Campbell;
> Ray
>> Jui; Linux Kernel; Vikram Prakash; Rob Herring; BCM Kernel Feedback; Kumar
>> Gala; Anup Patel
>> Subject: [PATCH v2 2/4] iommu/arm-smmu: Invoke DT probe from
>> arm_smmu_of_setup()
>>
>> The SMMUv1/SMMUv2 driver is initialized very early using the
>> IOMMU_OF_DECLARE() but the actual platform device is probed via normal
>> DT probing.
>>
>> This patch uses of_platform_device_create() from arm_smmu_of_setup() to
>> ensure that SMMU platform device is probed immediately.
>>
>> Signed-off-by: Anup Patel <anup.patel at broadcom.com>
>> ---
>>  drivers/iommu/arm-smmu.c | 6 ++++++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index
>> 2c8f871..02cd67d 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -40,6 +40,7 @@
>>  #include <linux/of.h>
>>  #include <linux/of_address.h>
>>  #include <linux/of_iommu.h>
>> +#include <linux/of_platform.h>
>>  #include <linux/pci.h>
>>  #include <linux/platform_device.h>
>>  #include <linux/slab.h>
>> @@ -1956,10 +1957,15 @@ static int __init arm_smmu_init(void)
>>
>>  static int __init arm_smmu_of_setup(struct device_node *np)  {
>> +     struct platform_device *pdev;
>>
>>       if (!init_done)
>>               arm_smmu_init();
>>
>> +     pdev = of_platform_device_create(np, NULL, NULL);
>> +     if (IS_ERR(pdev))
>> +             return PTR_ERR(pdev);
>> +
>>       of_iommu_set_ops(np, &arm_smmu_ops);
>
>  A question here is,  There was a probe deferral series [1], to take care of
> deferred
>  probing of devices behind iommus. With that this sort of early device
> probing during setup
>  should not be required and also it clears other dependencies of iommus on
> clocks, etc, if any.
>  My intention was to check whats the right way to do this  ? (or) point me
> to any updates
>  on the probe deferral series that I miss ?
>
> [1]  http://lkml.iu.edu/hypermail/linux/kernel/1505.3/03280.html

I think probe deferral is better way of handling this. I will drop this
patch.

Thanks,
Anup


From shawnguo at kernel.org  Thu Feb 18 19:28:30 2016
From: shawnguo at kernel.org (Shawn Guo)
Date: Fri, 19 Feb 2016 11:28:30 +0800
Subject: [PATCH v2 2/2] ARM64: dts: add LS1043a-QDS board support
In-Reply-To: <1450948298-33238-2-git-send-email-Zhiqiang.Hou@freescale.com>
References: <1450948298-33238-1-git-send-email-Zhiqiang.Hou@freescale.com>
 <1450948298-33238-2-git-send-email-Zhiqiang.Hou@freescale.com>
Message-ID: <20160219032830.GG6756@tiger>

On Thu, Dec 24, 2015 at 05:11:38PM +0800, Zhiqiang Hou wrote:
> From: Shaohui Xie <Shaohui.Xie at freescale.com>
> 

Empty commit log is generally not welcomed.  You can have something here
to introduce the board briefly.

We generally use lowercase for arm64 patch subject prefix, i.e.
"arm64: dts: ...".  Yes, this is different from ARM.

> Signed-off-by: Shaohui Xie <Shaohui.Xie at freescale.com>
> Signed-off-by: Mingkai Hu <Mingkai.Hu at freescale.com>
> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou at freescale.com>
> ---
> v2:
>  - add root node compatible property
> 
>  arch/arm64/boot/dts/freescale/Makefile            |   1 +
>  arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 168 ++++++++++++++++++++++
>  2 files changed, 169 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> 
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index f3c2516..1423fa4 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -2,6 +2,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-qds.dtb
>  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
>  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
>  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1043a-rdb.dtb
> +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1043a-qds.dtb

The list should be sorted alphabetically.  But it's not your fault, as
fsl-ls1043a-rdb.dtb is already wrong.

>   
>  always		:= $(dtb-y)
>  subdir-y	:= $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> new file mode 100644
> index 0000000..d7aae69
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> @@ -0,0 +1,168 @@
> +/*
> + * Device Tree Include file for Freescale Layerscape-1043A family SoC.
> + *
> + * Copyright 2014-2015, Freescale Semiconductor
> + *
> + * Mingkai Hu <Mingkai.hu at freescale.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPLv2 or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + *     modify it under the terms of the GNU General Public License as
> + *     published by the Free Software Foundation; either version 2 of the
> + *     License, or (at your option) any later version.
> + *
> + *     This library is distributed in the hope that it will be useful,
> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *     GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + *     obtaining a copy of this software and associated documentation
> + *     files (the "Software"), to deal in the Software without
> + *     restriction, including without limitation the rights to use,
> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> + *     sell copies of the Software, and to permit persons to whom the
> + *     Software is furnished to do so, subject to the following
> + *     conditions:
> + *
> + *     The above copyright notice and this permission notice shall be
> + *     included in all copies or substantial portions of the Software.
> + *
> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + *     OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +/include/ "fsl-ls1043a.dtsi"
> +
> +/ {
> +	model = "LS1043A QDS Board";
> +	compatible = "fsl,ls1043a-qds", "fsl,ls1043a";
> +
> +	aliases {
> +		serial0 = &lpuart0;
> +		serial1 = &lpuart1;
> +		serial2 = &lpuart2;
> +		serial3 = &lpuart3;
> +		serial4 = &lpuart4;
> +		serial5 = &lpuart5;
> +

This new line is not really necessary.

> +		gpio0 = &gpio1;
> +		gpio1 = &gpio2;
> +		gpio2 = &gpio3;
> +		gpio3 = &gpio4;

I suggest to sort all these aliases entries alphabetically.

> +	};
> +};
> +
> +&i2c0 {
> +	status = "okay";

I suggest to have a new line between properties and sub-node.

> +	pca9547 at 77 {
> +		compatible = "philips,pca9547";

I cannot find this compatible string in either binding docs or driver
code.

> +		reg = <0x77>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		i2c at 0 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x0>;
> +
> +			rtc at 68 {
> +				compatible = "dallas,ds3232";
> +				reg = <0x68>;
> +				/* IRQ10_B */
> +				interrupts = <0 150 0x4>;
> +			};
> +		};
> +
> +		i2c at 2 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x2>;
> +
> +			ina220 at 40 {
> +				compatible = "ti,ina220";
> +				reg = <0x40>;
> +				shunt-resistor = <1000>;
> +			};
> +
> +			ina220 at 41 {
> +				compatible = "ti,ina220";
> +				reg = <0x41>;
> +				shunt-resistor = <1000>;
> +			};
> +		};
> +
> +		i2c at 3 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x3>;
> +
> +			eeprom at 56 {
> +				compatible = "at24,24c512";

Unsupported/undocumented compatible?

> +				reg = <0x56>;
> +			};
> +
> +			eeprom at 57 {
> +				compatible = "at24,24c512";
> +				reg = <0x57>;
> +			};
> +
> +			adt7461a at 4c {

temp-sensor should be a better node name, if I understand the device
correctly.

> +				compatible = "adt7461a";

It should be "adi,adt7461a" per
Documentation/devicetree/bindings/hwmon/lm90.txt?

> +				reg = <0x4c>;
> +			};
> +		};
> +	};
> +};
> +
> +&ifc {
> +	status = "okay";

We generally put it at the bottom of the property list.

> +	#address-cells = <2>;
> +	#size-cells = <1>;
> +	/* NOR, NAND Flashes and FPGA on board */
> +	ranges = <0x0 0x0 0x0 0x60000000 0x08000000
> +		  0x1 0x0 0x0 0x7e800000 0x00010000
> +		  0x2 0x0 0x0 0x7fb00000 0x00000100>;
> +
> +	nor at 0,0 {
> +		compatible = "cfi-flash";
> +		reg = <0x0 0x0 0x8000000>;
> +		bank-width = <2>;
> +		device-width = <1>;
> +	};
> +
> +	nand at 1,0 {
> +		compatible = "fsl,ifc-nand";
> +		reg = <0x1 0x0 0x10000>;
> +	};
> +
> +	fpga: board-control at 2,0 {
> +		compatible = "fsl,ls1043aqds-fpga", "fsl,fpga-qixis";
> +		reg = <0x2 0x0 0x0000100>;
> +	};
> +};
> +
> +&lpuart0 {
> +	status = "okay";
> +};
> +
> +&duart0 {
> +	status = "okay";
> +};
> +
> +&duart1 {
> +	status = "okay";
> +};

I suggest you sort these node alphabetically per label name.

Shawn

> -- 
> 2.1.0.27.g96db324
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From Chris.Brandt at renesas.com  Thu Feb 18 19:39:38 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Fri, 19 Feb 2016 03:39:38 +0000
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <20160218223312.GT19428@n2100.arm.linux.org.uk>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
 <alpine.LFD.2.20.1602181244490.13632@knanqh.ubzr>
 <HK2PR06MB0561377EABB3B4B8E94F22328AAF0@HK2PR06MB0561.apcprd06.prod.outlook.com>
 <alpine.LFD.2.20.1602181327060.13632@knanqh.ubzr>
 <HK2PR06MB0561C0EEA846C516645239338AAF0@HK2PR06MB0561.apcprd06.prod.outlook.com>
 <20160218223312.GT19428@n2100.arm.linux.org.uk>
Message-ID: <HK2PR06MB05617E2ED835CFE20F65E3D38AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>

On Thu, 18 Feb 2016, Russell King - ARM Linux wrote:

> On Thu, Feb 18, 2016 at 07:42:20PM +0000, Chris Brandt wrote:
> > On Thu, 18 Feb 2016, Nicolas Pitre wrote:
> > 
> > > > Is there some way you can do a PLATFORM_COUNTER++ for each device 
> > > > that is selected, and then XIP_KERNEL would depend on 
> > > > PLATFORM_COUNTER == 1 ?
> > >
> > > I don't know all the Kconfig possibilities.
> > >
> > > But would something like this work?
> > >
> > > config FOO
> > >	depends on !(XIP && CHOICE_MADE)
> > >	select CHOICE_MADE
> > 
> > I follow your logic and that might work: If you made multiple choices,
> > it would just take the first one.
> > 
> > However...I just tried it and it crashes.
> > 
> > scripts/kconfig/mconf  Kconfig
> > make[2]: *** [menuconfig] Segmentation fault (core dumped)
> > make[1]: *** [menuconfig] Error 2
> > 
> > 
> > It looks like you can't depend on something not being set that you are
> > going to set yourself. Basically..."do as I say, not as I do"
> 
> It's missing a bool/tristate.  Every config option needs to be typed.


Thank you! That makes things better.

Technically, it seems to work (you can only select 1), but the menu system is a little flakey when you try jumping back and forth between what device to select. Somehow when 2 get selected, I need to get kbuild to go back and do a full refresh or something.


I'm going to play with it some more before I start shouting victory.


Chris




From k.kozlowski at samsung.com  Thu Feb 18 19:51:48 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 19 Feb 2016 12:51:48 +0900
Subject: [PATCH v2 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420
In-Reply-To: <87h9h599zi.fsf@e105922-lin.cambridge.arm.com>
References: <1455772383-20598-1-git-send-email-k.kozlowski@samsung.com>
 <87h9h599zi.fsf@e105922-lin.cambridge.arm.com>
Message-ID: <56C69154.40608@samsung.com>

On 19.02.2016 02:58, Punit Agrawal wrote:
> Hi Krzysztof,
> 
> Krzysztof Kozlowski <k.kozlowski at samsung.com> writes:
> 
>> On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
>> 12 steps for big core (700-1800 MHz). Add respective cooling cells.
>>
>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
>>
>> ---
>>
>> Changes since v1:
>> 1. Add cooling properties to all CPUs (suggested by Viresh).
>> ---
>>  arch/arm/boot/dts/exynos5420-cpus.dtsi | 24 ++++++++++++++++++++++++
>>  1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> index 261d25173f61..5c052d7ff554 100644
>> --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> @@ -33,6 +33,9 @@
>>  			clock-frequency = <1800000000>;
>>  			cci-control-port = <&cci_control1>;
>>  			operating-points-v2 = <&cluster_a15_opp_table>;
>> +			cooling-min-level = <0>;
>> +			cooling-max-level = <11>;
> 
> Although the above two properties are defined they aren't parsed in the
> kernel.
> 
> Setting min / max extents for cooling devices via cooling maps does work
> though.

It is described as optional property in
Documentation/devicetree/bindings/thermal/thermal.txt ... but indeed it
is totally ignored.

So what is the recommendation? Get rid of it from DTS and documentation
or leave it because it will be implemented someday?

Thanks for feedback!

Best regards,
Krzysztof



From andi.shyti at samsung.com  Thu Feb 18 20:20:14 2016
From: andi.shyti at samsung.com (Andi Shyti)
Date: Fri, 19 Feb 2016 13:20:14 +0900
Subject: [PATCH 3/3] thermal: exynos: Defer probe if vtmu is present but
 not registered
In-Reply-To: <1455819551-4666-4-git-send-email-javier@osg.samsung.com>
References: <1455819551-4666-1-git-send-email-javier@osg.samsung.com>
 <1455819551-4666-4-git-send-email-javier@osg.samsung.com>
Message-ID: <20160219042014.GB27936@samsunx.samsung>

Hi Javier,

Just a question...

> diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
> index f4f36bba7be9..f3ce94ec73b5 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -1318,6 +1318,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
>  			return ret;
>  		}
>  	} else {
> +		if (PTR_ERR(data->regulator) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;

shouldn't we return also in case of -ENOMEM? -ENOMEM is a Kernel
failure, not depending on the regulator itself.

Andi

>  		dev_info(&pdev->dev, "Regulator node (vtmu) not found\n");
>  	}


From k.kozlowski at samsung.com  Thu Feb 18 20:25:05 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 19 Feb 2016 13:25:05 +0900
Subject: [PATCH 3/3] thermal: exynos: Defer probe if vtmu is present but
 not registered
In-Reply-To: <20160219042014.GB27936@samsunx.samsung>
References: <1455819551-4666-1-git-send-email-javier@osg.samsung.com>
 <1455819551-4666-4-git-send-email-javier@osg.samsung.com>
 <20160219042014.GB27936@samsunx.samsung>
Message-ID: <56C69921.4050201@samsung.com>

On 19.02.2016 13:20, Andi Shyti wrote:
> Hi Javier,
> 
> Just a question...
> 
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
>> index f4f36bba7be9..f3ce94ec73b5 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -1318,6 +1318,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
>>  			return ret;
>>  		}
>>  	} else {
>> +		if (PTR_ERR(data->regulator) == -EPROBE_DEFER)
>> +			return -EPROBE_DEFER;
> 
> shouldn't we return also in case of -ENOMEM? -ENOMEM is a Kernel
> failure, not depending on the regulator itself.

Usually not because that would make this error path quite complicated
and difficult to keep consistent. If you choose this way then you will
have to probably extend the black list (e.g. EINVAL, some other)... or
use a white list.

Additionally the error codes can come from deeper layers. These layer
now can return ESOMETHING but later it might change to EDIFFERENT... you
cannot predict that.

Whatever the reason was (except defer), just ignore the regulator.

Best regards,
Krzysztof



From andi.shyti at samsung.com  Thu Feb 18 20:29:54 2016
From: andi.shyti at samsung.com (Andi Shyti)
Date: Fri, 19 Feb 2016 13:29:54 +0900
Subject: [PATCH 0/3] thermal: exynos: Fixes for vtmu-supply regulator
 handling
In-Reply-To: <1455819551-4666-1-git-send-email-javier@osg.samsung.com>
References: <1455819551-4666-1-git-send-email-javier@osg.samsung.com>
Message-ID: <20160219042954.GD27936@samsunx.samsung>

Hi Javier,

> Javier Martinez Canillas (3):
>   thermal: exynos: List vtmu-supply as optional property in DT binding
>   thermal: exynos: Use devm_regulator_get_optional() for vtmu
>   thermal: exynos: Defer probe if vtmu is present but not registered
> 
>  Documentation/devicetree/bindings/thermal/exynos-thermal.txt | 9 ++++++---
>  drivers/thermal/samsung/exynos_tmu.c                         | 4 +++-
>  2 files changed, 9 insertions(+), 4 deletions(-)

for all of them:

Reviewed-by: Andi Shyti <andi.shyti at samsung.com>

Andi


From j-keerthy at ti.com  Thu Feb 18 20:38:54 2016
From: j-keerthy at ti.com (Keerthy)
Date: Fri, 19 Feb 2016 10:08:54 +0530
Subject: [PATCH v2 1/2] ARM: dts: am43x-epos-evm: Add the am438 compatible
 string
In-Reply-To: <1455856735-11515-1-git-send-email-j-keerthy@ti.com>
References: <1455856735-11515-1-git-send-email-j-keerthy@ti.com>
Message-ID: <1455856735-11515-2-git-send-email-j-keerthy@ti.com>

The SoCs on am43x-epos-evm are named am438x.
Hence add the compatibility string and remove the am4372 string.

Signed-off-by: Keerthy <j-keerthy at ti.com>
---
 Documentation/devicetree/bindings/arm/omap/omap.txt | 2 +-
 arch/arm/boot/dts/am43x-epos-evm.dts                | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index a2bd593..739bc48 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -154,7 +154,7 @@ Boards:
   compatible = "compulab,am437x-sbc-t43", "compulab,am437x-cm-t43", "ti,am4372", "ti,am43"
 
 - AM43x EPOS EVM
-  compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
+  compatible = "ti,am43x-epos-evm", "ti,am43", "ti,am438x"
 
 - AM437x GP EVM
   compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index d580e2b..d2408c4 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -18,7 +18,7 @@
 
 / {
 	model = "TI AM43x EPOS EVM";
-	compatible = "ti,am43x-epos-evm","ti,am4372","ti,am43";
+	compatible = "ti,am43x-epos-evm","ti,am438x","ti,am43";
 
 	aliases {
 		display0 = &lcd0;
-- 
1.9.1



From j-keerthy at ti.com  Thu Feb 18 20:38:55 2016
From: j-keerthy at ti.com (Keerthy)
Date: Fri, 19 Feb 2016 10:08:55 +0530
Subject: [PATCH v2 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod
In-Reply-To: <1455856735-11515-1-git-send-email-j-keerthy@ti.com>
References: <1455856735-11515-1-git-send-email-j-keerthy@ti.com>
Message-ID: <1455856735-11515-3-git-send-email-j-keerthy@ti.com>

The patch adds rtc hwmod. RTC module The RTC module is physically
present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently
disabled. A secure RTC is used instead on these devices, where needed.
. Hence adding it selectively using a seprate list to get RTC Module
functional on the other am43x SoCs used on am437x-gp-evm and
am437x-sk-evm.

Signed-off-by: Keerthy <j-keerthy at ti.com>
---

Changes in v2:

Inverted the checking logic to accommodate registering for all
the SoCs compatible to am4372 and removed the negating am438x logic
to register rtc hwmods as suggested by Paul.

 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index e97a894..97fd399 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -1020,9 +1020,21 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
 	NULL,
 };
 
+static struct omap_hwmod_ocp_if *am43xx_rtc_hwmod_ocp_ifs[] __initdata = {
+	&am33xx_l4_wkup__rtc,
+	NULL,
+};
+
 int __init am43xx_hwmod_init(void)
 {
+	int ret;
+
 	omap_hwmod_am43xx_reg();
 	omap_hwmod_init();
-	return omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+	ret = omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+
+	if (!ret && of_machine_is_compatible("ti,am4372"))
+		ret = omap_hwmod_register_links(am43xx_rtc_hwmod_ocp_ifs);
+
+	return ret;
 }
-- 
1.9.1



From j-keerthy at ti.com  Thu Feb 18 20:38:53 2016
From: j-keerthy at ti.com (Keerthy)
Date: Fri, 19 Feb 2016 10:08:53 +0530
Subject: [PATCH v2 0/2] arm: am43xx: Register rtc hwmod
Message-ID: <1455856735-11515-1-git-send-email-j-keerthy@ti.com>

The patch adds rtc hwmod. This is present on gp and sk evm and not on
epos evm. Hence adding it selectively using a seprate list.

Boot tested on AM437X-GP-EVM and AM437X-SK-EVM and checked
for rtc ticking on AM437X-GP-EVM.

Keerthy (2):
  ARM: dts: am43x-epos-evm: Add the am438 compatible string
  ARM: AM43XX: HWMOD: Add rtc hwmod

 Documentation/devicetree/bindings/arm/omap/omap.txt |  2 +-
 arch/arm/boot/dts/am43x-epos-evm.dts                |  2 +-
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c          | 14 +++++++++++++-
 3 files changed, 15 insertions(+), 3 deletions(-)

-- 
1.9.1



From henryc.chen at mediatek.com  Thu Feb 18 21:08:02 2016
From: henryc.chen at mediatek.com (Henry Chen)
Date: Fri, 19 Feb 2016 13:08:02 +0800
Subject: [RFC PATCH 4/5] PM / AVS: thermal: MT8173: Introduce support
 for SVS engine
In-Reply-To: <20160218030049.GA8780@gmail.com>
References: <1453452029-20843-1-git-send-email-pi-cheng.chen@linaro.org>
 <1453452029-20843-5-git-send-email-pi-cheng.chen@linaro.org>
 <CAGS+omAYPhJ80kHG=bW4AjFsQzhwUfC6C+nAXa=Ny5UyoCid=w@mail.gmail.com>
 <20160218030049.GA8780@gmail.com>
Message-ID: <1455858482.17104.13.camel@mtksdaap41>


On Thu, 2016-02-18 at 11:00 +0800, Pi-Cheng Chen wrote:

> > > +               vboot = regulator_get_voltage(svs->reg) / 1000;
> > > +               if (mvolt_to_config(vboot) !=
> > > +                   mvolt_to_config(svs_bank_cfgs[i].vboot)) {
> > > +                       dev_err(svs->dev, "Vboot value mismatch!\n");
> > > +                       ret = -EINVAL;
> > > +                       break;
> > > +               }
> > > +
> > > +               ret = regulator_set_mode(svs->reg, REGULATOR_MODE_FAST);
> > > +               if (ret) {
> > > +                       dev_err(svs->dev,
> > > +                               "Failed to set regulator in PWM mode\n");
> > > +                       ret = -EINVAL;
> > > +                       break;
> > > +               }
> > 
> > Shouldn't this be best effort?
> > If we can't set the regulator to fast mode, can we continue anyway?
> > 
> 
> AFAIK, we need to set the regulator to fast mode to get stable voltage as
> possible. I am sure about the details.
> 
> @Henry,
> Would you please comment it?

Hi,

Yes, as you said, PTPOD need the more precisely voltage as possible when
driver initialize, there has two mode in mt6397: pwm/auto mode, the pwm
mode which can get the more stable Vout than auto mode.

Thanks,
Henry




From guodong.xu at linaro.org  Thu Feb 18 21:19:03 2016
From: guodong.xu at linaro.org (Guodong Xu)
Date: Fri, 19 Feb 2016 13:19:03 +0800
Subject: [PATCH 0/5] add DTS for hi6220 and HiKey
Message-ID: <1455859148-29098-1-git-send-email-guodong.xu@linaro.org>

This patchset include more dts changes for hi6220 SoC and HiKey board.

Patch 1 adds pinctrl to uart ports in SoC and enables them for HiKey board.
Patch 2 adds gpio LEDs device nodes.
Patch 3 adds dwmmc nodes description for hi6220. It refers to two LDO's
which are defined in regulator patchsets which pending on review:
[PATCH v8 5/5] arm64: dts: hisilicon: Add hi655x pmic dts node
http://thread.gmane.org/gmane.linux.kernel/2151688

Patch 4 adds resets property into dwmmc nodes.
Patch 5 adds wifi device nodes (TI's wl1835) for HiKey board.

Guodong Xu (4):
  arm64: dts: hi6220: add pinctrl for uarts and enable them
  arm64: dts: add LED nodes for hi6220-hikey
  arm64: dts: hi6220: add resets property into dwmmc nodes
  arm64: dts: add wifi nodes support for hi6220-hikey

Xinwei Kong (1):
  arm64: dts: add dwmmc nodes for hi6220

 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 81 ++++++++++++++++++++++++++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi      | 66 +++++++++++++++++++++
 2 files changed, 147 insertions(+)

-- 
1.9.1



From guodong.xu at linaro.org  Thu Feb 18 21:19:04 2016
From: guodong.xu at linaro.org (Guodong Xu)
Date: Fri, 19 Feb 2016 13:19:04 +0800
Subject: [PATCH 1/5] arm64: dts: hi6220: add pinctrl for uarts and enable them
In-Reply-To: <1455859148-29098-1-git-send-email-guodong.xu@linaro.org>
References: <1455859148-29098-1-git-send-email-guodong.xu@linaro.org>
Message-ID: <1455859148-29098-2-git-send-email-guodong.xu@linaro.org>

Add pinctrl for uart2 uart3 and uart4. Enable uart1 uart2 and uart3.

Signed-off-by: Guodong Xu <guodong.xu at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 12 ++++++++++++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi      |  9 +++++++++
 2 files changed, 21 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index e00e9ec..c4f560a 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -50,6 +50,18 @@
 		i2c1: i2c at f7101000 {
 			status = "ok";
 		};
+
+		uart1: uart at f7111000 {
+			status = "ok";
+		};
+
+		uart2: uart at f7112000 {
+			status = "ok";
+		};
+
+		uart3: uart at f7113000 {
+			status = "ok";
+		};
 	};
 };
 
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index a7ca40b..6afd327 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -266,6 +266,8 @@
 			clocks = <&sys_ctrl HI6220_UART1_PCLK>,
 				 <&sys_ctrl HI6220_UART1_PCLK>;
 			clock-names = "uartclk", "apb_pclk";
+			pinctrl-names = "default";
+			pinctrl-0 = <&uart1_pmx_func &uart1_cfg_func1 &uart1_cfg_func2>;
 			status = "disabled";
 		};
 
@@ -276,6 +278,8 @@
 			clocks = <&sys_ctrl HI6220_UART2_PCLK>,
 				 <&sys_ctrl HI6220_UART2_PCLK>;
 			clock-names = "uartclk", "apb_pclk";
+			pinctrl-names = "default";
+			pinctrl-0 = <&uart2_pmx_func &uart2_cfg_func>;
 			status = "disabled";
 		};
 
@@ -286,6 +290,9 @@
 			clocks = <&sys_ctrl HI6220_UART3_PCLK>,
 				 <&sys_ctrl HI6220_UART3_PCLK>;
 			clock-names = "uartclk", "apb_pclk";
+			pinctrl-names = "default";
+			pinctrl-0 = <&uart3_pmx_func &uart3_cfg_func>;
+			status = "disabled";
 		};
 
 		uart4: uart at f7114000 {
@@ -295,6 +302,8 @@
 			clocks = <&sys_ctrl HI6220_UART4_PCLK>,
 				 <&sys_ctrl HI6220_UART4_PCLK>;
 			clock-names = "uartclk", "apb_pclk";
+			pinctrl-names = "default";
+			pinctrl-0 = <&uart4_pmx_func &uart4_cfg_func>;
 			status = "disabled";
 		};
 
-- 
1.9.1



From guodong.xu at linaro.org  Thu Feb 18 21:19:05 2016
From: guodong.xu at linaro.org (Guodong Xu)
Date: Fri, 19 Feb 2016 13:19:05 +0800
Subject: [PATCH 2/5] arm64: dts: add LED nodes for hi6220-hikey
In-Reply-To: <1455859148-29098-1-git-send-email-guodong.xu@linaro.org>
References: <1455859148-29098-1-git-send-email-guodong.xu@linaro.org>
Message-ID: <1455859148-29098-3-git-send-email-guodong.xu@linaro.org>

Signed-off-by: Guodong Xu <guodong.xu at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 41 ++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index c4f560a..5a004b4 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -63,6 +63,47 @@
 			status = "ok";
 		};
 	};
+
+	leds {
+		compatible = "gpio-leds";
+		user_led1 {
+			label = "user_led4";
+			gpios = <&gpio4 0 0>; /* <&gpio_user_led_1>; */
+			linux,default-trigger = "heartbeat";
+		};
+
+		user_led2 {
+			label = "user_led3";
+			gpios = <&gpio4 1 0>; /* <&gpio_user_led_2>; */
+			linux,default-trigger = "mmc0";
+		};
+
+		user_led3 {
+			label = "user_led2";
+			gpios = <&gpio4 2 0>; /* <&gpio_user_led_3>; */
+			linux,default-trigger = "mmc1";
+		};
+
+		user_led4 {
+			label = "user_led1";
+			gpios = <&gpio4 3 0>; /* <&gpio_user_led_4>; */
+			linux,default-trigger = "cpu0";
+		};
+
+		wlan_active_led {
+			label = "wifi_active";
+			gpios = <&gpio3 5 0>; /* <&gpio_wlan_active_led>; */
+			linux,default-trigger = "phy0tx";
+			default-state = "off";
+		};
+
+		bt_active_led {
+			label = "bt_active";
+			gpios = <&gpio4 7 0>; /* <&gpio_bt_active_led>; */
+			linux,default-trigger = "hci0rx";
+			default-state = "off";
+		};
+	};
 };
 
 &uart2 {
-- 
1.9.1



From guodong.xu at linaro.org  Thu Feb 18 21:19:06 2016
From: guodong.xu at linaro.org (Guodong Xu)
Date: Fri, 19 Feb 2016 13:19:06 +0800
Subject: [PATCH 3/5] arm64: dts: add dwmmc nodes for hi6220
In-Reply-To: <1455859148-29098-1-git-send-email-guodong.xu@linaro.org>
References: <1455859148-29098-1-git-send-email-guodong.xu@linaro.org>
Message-ID: <1455859148-29098-4-git-send-email-guodong.xu@linaro.org>

From: Xinwei Kong <kong.kongxinwei at hisilicon.com>

Add all three dwmmc nodes description for hi6220

Signed-off-by: Guodong Xu <guodong.xu at linaro.org>
Signed-off-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 53 +++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 6afd327..28bd441 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -738,5 +738,58 @@
 			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
 			#mbox-cells = <3>;
 		};
+
+		dwmmc_0: dwmmc0 at f723d000 {
+			compatible = "hisilicon,hi6220-dw-mshc";
+			num-slots = <0x1>;
+			cap-mmc-highspeed;
+			non-removable;
+			reg = <0x0 0xf723d000 0x0 0x1000>;
+			interrupts = <0x0 0x48 0x4>;
+			clocks = <&sys_ctrl 2>, <&sys_ctrl 1>;
+			clock-names = "ciu", "biu";
+			bus-width = <0x8>;
+			vmmc-supply = <&ldo19>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&emmc_pmx_func &emmc_clk_cfg_func
+				     &emmc_cfg_func &emmc_rst_cfg_func>;
+		};
+
+		dwmmc_1: dwmmc1 at f723e000 {
+			compatible = "hisilicon,hi6220-dw-mshc";
+			num-slots = <0x1>;
+			card-detect-delay = <200>;
+			hisilicon,peripheral-syscon = <&ao_ctrl>;
+			cap-sd-highspeed;
+			reg = <0x0 0xf723e000 0x0 0x1000>;
+			interrupts = <0x0 0x49 0x4>;
+			#address-cells = <0x1>;
+			#size-cells = <0x0>;
+			clocks = <&sys_ctrl 4>, <&sys_ctrl 3>;
+			clock-names = "ciu", "biu";
+			vqmmc-supply = <&ldo7>;
+			vmmc-supply = <&ldo10>;
+			bus-width = <0x4>;
+			disable-wp;
+			cd-gpios = <&gpio1 0 1>;
+			pinctrl-names = "default", "idle";
+			pinctrl-0 = <&sd_pmx_func &sd_clk_cfg_func &sd_cfg_func>;
+			pinctrl-1 = <&sd_pmx_idle &sd_clk_cfg_idle &sd_cfg_idle>;
+		};
+
+		dwmmc_2: dwmmc2 at f723f000 {
+			compatible = "hisilicon,hi6220-dw-mshc";
+			status = "okay";
+			num-slots = <0x1>;
+			reg = <0x0 0xf723f000 0x0 0x1000>;
+			interrupts = <0x0 0x4a 0x4>;
+			clocks = <&sys_ctrl HI6220_MMC2_CIUCLK>, <&sys_ctrl HI6220_MMC2_CLK>;
+			clock-names = "ciu", "biu";
+			bus-width = <0x4>;
+			broken-cd;
+			pinctrl-names = "default", "idle";
+			pinctrl-0 = <&sdio_pmx_func &sdio_clk_cfg_func &sdio_cfg_func>;
+			pinctrl-1 = <&sdio_pmx_idle &sdio_clk_cfg_idle &sdio_cfg_idle>;
+		};
 	};
 };
-- 
1.9.1



From guodong.xu at linaro.org  Thu Feb 18 21:19:07 2016
From: guodong.xu at linaro.org (Guodong Xu)
Date: Fri, 19 Feb 2016 13:19:07 +0800
Subject: [PATCH 4/5] arm64: dts: hi6220: add resets property into dwmmc nodes
In-Reply-To: <1455859148-29098-1-git-send-email-guodong.xu@linaro.org>
References: <1455859148-29098-1-git-send-email-guodong.xu@linaro.org>
Message-ID: <1455859148-29098-5-git-send-email-guodong.xu@linaro.org>

Add resets property into dwmmc_0, dwmmc_1 and dwmmc_2 for hi6220

Signed-off-by: Guodong Xu <guodong.xu at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 28bd441..7452359 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -7,6 +7,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/hi6220-clock.h>
 #include <dt-bindings/pinctrl/hisi.h>
+#include <dt-bindings/reset/hisi,hi6220-resets.h>
 
 / {
 	compatible = "hisilicon,hi6220";
@@ -748,6 +749,7 @@
 			interrupts = <0x0 0x48 0x4>;
 			clocks = <&sys_ctrl 2>, <&sys_ctrl 1>;
 			clock-names = "ciu", "biu";
+			resets = <&sys_ctrl PERIPH_RSTDIS0_MMC0>;
 			bus-width = <0x8>;
 			vmmc-supply = <&ldo19>;
 			pinctrl-names = "default";
@@ -767,6 +769,7 @@
 			#size-cells = <0x0>;
 			clocks = <&sys_ctrl 4>, <&sys_ctrl 3>;
 			clock-names = "ciu", "biu";
+			resets = <&sys_ctrl PERIPH_RSTDIS0_MMC1>;
 			vqmmc-supply = <&ldo7>;
 			vmmc-supply = <&ldo10>;
 			bus-width = <0x4>;
@@ -785,6 +788,7 @@
 			interrupts = <0x0 0x4a 0x4>;
 			clocks = <&sys_ctrl HI6220_MMC2_CIUCLK>, <&sys_ctrl HI6220_MMC2_CLK>;
 			clock-names = "ciu", "biu";
+			resets = <&sys_ctrl PERIPH_RSTDIS0_MMC2>;
 			bus-width = <0x4>;
 			broken-cd;
 			pinctrl-names = "default", "idle";
-- 
1.9.1



From guodong.xu at linaro.org  Thu Feb 18 21:19:08 2016
From: guodong.xu at linaro.org (Guodong Xu)
Date: Fri, 19 Feb 2016 13:19:08 +0800
Subject: [PATCH 5/5] arm64: dts: add wifi nodes support for hi6220-hikey
In-Reply-To: <1455859148-29098-1-git-send-email-guodong.xu@linaro.org>
References: <1455859148-29098-1-git-send-email-guodong.xu@linaro.org>
Message-ID: <1455859148-29098-6-git-send-email-guodong.xu@linaro.org>

Add wifi nodes support for hi6220-hikey

Signed-off-by: Guodong Xu <guodong.xu at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 28 ++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 5a004b4..eba6ec7 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -47,6 +47,7 @@
 		i2c0: i2c at f7100000 {
 			status = "ok";
 		};
+
 		i2c1: i2c at f7101000 {
 			status = "ok";
 		};
@@ -62,6 +63,33 @@
 		uart3: uart at f7113000 {
 			status = "ok";
 		};
+
+		dwmmc_2: dwmmc2 at f723f000 {
+			/* WL_EN */
+			vmmc-supply = <&wlan_en_reg>;
+
+			#address-cells = <0x1>;
+			#size-cells = <0x0>;
+			wlcore: wlcore at 2 {
+				compatible = "ti,wl1835";
+				reg = <2>;	/* sdio func num */
+				/* WL_IRQ, WL_HOST_WAKE_GPIO1_3 */
+				interrupt-parent = <&gpio1>;
+				interrupts = <3 IRQ_TYPE_EDGE_RISING>;
+			};
+		};
+
+		wlan_en_reg: fixedregulator at 1 {
+			compatible = "regulator-fixed";
+			regulator-name = "wlan-en-regulator";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			/* WLAN_EN GPIO */
+			gpio = <&gpio0 5 0>;
+			/* WLAN card specific delay */
+			startup-delay-us = <70000>;
+			enable-active-high;
+		};
 	};
 
 	leds {
-- 
1.9.1



From henryc.chen at mediatek.com  Thu Feb 18 21:31:25 2016
From: henryc.chen at mediatek.com (Henry Chen)
Date: Fri, 19 Feb 2016 13:31:25 +0800
Subject: [RFC PATCH 4/5] PM / AVS: thermal: MT8173: Introduce support
 for SVS engine
In-Reply-To: <1455858482.17104.13.camel@mtksdaap41>
References: <1453452029-20843-1-git-send-email-pi-cheng.chen@linaro.org>
 <1453452029-20843-5-git-send-email-pi-cheng.chen@linaro.org>
 <CAGS+omAYPhJ80kHG=bW4AjFsQzhwUfC6C+nAXa=Ny5UyoCid=w@mail.gmail.com>
 <20160218030049.GA8780@gmail.com> <1455858482.17104.13.camel@mtksdaap41>
Message-ID: <1455859885.17104.21.camel@mtksdaap41>

On Fri, 2016-02-19 at 13:08 +0800, Henry Chen wrote:
> On Thu, 2016-02-18 at 11:00 +0800, Pi-Cheng Chen wrote:
> 
> > > > +               vboot = regulator_get_voltage(svs->reg) / 1000;
> > > > +               if (mvolt_to_config(vboot) !=
> > > > +                   mvolt_to_config(svs_bank_cfgs[i].vboot)) {
> > > > +                       dev_err(svs->dev, "Vboot value mismatch!\n");
> > > > +                       ret = -EINVAL;
> > > > +                       break;
> > > > +               }
> > > > +
> > > > +               ret = regulator_set_mode(svs->reg, REGULATOR_MODE_FAST);
> > > > +               if (ret) {
> > > > +                       dev_err(svs->dev,
> > > > +                               "Failed to set regulator in PWM mode\n");
> > > > +                       ret = -EINVAL;
> > > > +                       break;
> > > > +               }
> > > 
> > > Shouldn't this be best effort?
> > > If we can't set the regulator to fast mode, can we continue anyway?
> > > 
> > 
> > AFAIK, we need to set the regulator to fast mode to get stable voltage as
> > possible. I am sure about the details.
> > 
> > @Henry,
> > Would you please comment it?
> 

Hi,

Correct typos.Sorry for the wrong module name. 

Yes, as you said, SVS need the more precisely voltage as possible when
driver initialize, there has two mode in mt6397: pwm/auto mode, the pwm
mode which can get the more stable Vout than auto mode.

Thanks,
Henry



From eddie.huang at mediatek.com  Thu Feb 18 22:00:43 2016
From: eddie.huang at mediatek.com (Eddie Huang)
Date: Fri, 19 Feb 2016 14:00:43 +0800
Subject: [PATCH] ARM64: dts: Mediatek: mt8173-evb: fix access MMC fail issue
Message-ID: <1455861643-24307-1-git-send-email-eddie.huang@mediatek.com>

MT8173 E1 chip has one bug that if turn off USB power domain, vcore
power will also be off, thus cause modules using vcore power domain
fail, like MMC. The E1 chip only found on MT8173-evb board and this
board only has E1 chip, so implement this as a board specific
workaround.

Pwrapper use vcore power, so add pwrapper using USB power domain to
keep USB power domain not to zero and disabled.

Signed-off-by: Eddie Huang <eddie.huang at mediatek.com>

---
Sascha sent similar patch before[0], but MMC support runtime-pm,
vcore power domain still be disabled after MMC and USB suspend.
This silicon bug already fix in MT8173 MP chip.

[0]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358065.html
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index e427f04..7453a47 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -214,6 +214,9 @@
 };
 
 &pwrap {
+	/* Only MT8173 E1 needs USB power domain */
+	power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+
 	pmic: mt6397 {
 		compatible = "mediatek,mt6397";
 		interrupt-parent = <&pio>;
-- 
1.9.1



From yamada.masahiro at socionext.com  Thu Feb 18 22:05:50 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 19 Feb 2016 15:05:50 +0900
Subject: [PATCH] arm64, kbuild:  make "make install" not depend on vmlinux
Message-ID: <1455861950-21832-1-git-send-email-yamada.masahiro@socionext.com>

For the same reason as commit 19514fc665ff (arm, kbuild: make "make
install" not depend on vmlinux), the install targets should never
trigger the rebuild of the kernel.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm64/Makefile        |  2 +-
 arch/arm64/boot/Makefile   |  4 ++--
 arch/arm64/boot/install.sh | 14 ++++++++++++++
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 307237c..b5e3f6d 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -88,7 +88,7 @@ Image: vmlinux
 Image.%: vmlinux
 	$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
 
-zinstall install: vmlinux
+zinstall install:
 	$(Q)$(MAKE) $(build)=$(boot) $@
 
 %.dtb: scripts
diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
index abcbba2..305c552 100644
--- a/arch/arm64/boot/Makefile
+++ b/arch/arm64/boot/Makefile
@@ -34,10 +34,10 @@ $(obj)/Image.lzma: $(obj)/Image FORCE
 $(obj)/Image.lzo: $(obj)/Image FORCE
 	$(call if_changed,lzo)
 
-install: $(obj)/Image
+install:
 	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
 	$(obj)/Image System.map "$(INSTALL_PATH)"
 
-zinstall: $(obj)/Image.gz
+zinstall:
 	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
 	$(obj)/Image.gz System.map "$(INSTALL_PATH)"
diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh
index 12ed78a..d91e1f0 100644
--- a/arch/arm64/boot/install.sh
+++ b/arch/arm64/boot/install.sh
@@ -20,6 +20,20 @@
 #   $4 - default install path (blank if root directory)
 #
 
+verify () {
+	if [ ! -f "$1" ]; then
+		echo ""                                                   1>&2
+		echo " *** Missing file: $1"                              1>&2
+		echo ' *** You need to run "make" before "make install".' 1>&2
+		echo ""                                                   1>&2
+		exit 1
+	fi
+}
+
+# Make sure the files actually exist
+verify "$2"
+verify "$3"
+
 # User may have a custom install script
 if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi
 if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} "$@"; fi
-- 
1.9.1



From horms+renesas at verge.net.au  Thu Feb 18 22:09:46 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Feb 2016 15:09:46 +0900
Subject: [GIT PULL] Renesas ARM Based SoC Fixes for v4.5
Message-ID: <cover.1455859965.git.horms+renesas@verge.net.au>

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM based SoC fixes for v4.5.

This pull request is comprised of patches from Geert Uytterhoeven to avoid
writing to .text.

* "ARM: shmobile: Move shmobile_scu_base from .text to .bss"

  Resolves a problem for XIP kernels as writing to .text is not allowed.
  For non-XIP kernels a problem does not manifst as the pages are mapped
  read-only during late kernel startup.

* The remaining patches resolve a kernel-crash that occurs during system
  suspend for CONFIG_DEBUG_RODATA=y kernels.


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-fixes-for-v4.5

for you to fetch changes up to 901c5ffaaed117a38be9d0c29247c4888d6c8636:

  ARM: shmobile: Remove shmobile_boot_arg (2016-02-17 18:27:21 +0900)

----------------------------------------------------------------
Renesas ARM Based SoC Fixes for v4.5

* Avoid writing to .text

----------------------------------------------------------------
Geert Uytterhoeven (4):
      ARM: shmobile: Move shmobile_scu_base from .text to .bss
      ARM: shmobile: r8a7779: Remove remainings of removed SCU boot setup code
      ARM: shmobile: Move shmobile_smp_{mpidr, fn, arg}[] from .text to .bss
      ARM: shmobile: Remove shmobile_boot_arg

 arch/arm/mach-shmobile/common.h       |  1 -
 arch/arm/mach-shmobile/headsmp-scu.S  |  6 ------
 arch/arm/mach-shmobile/headsmp.S      | 28 ++++++++++++++++------------
 arch/arm/mach-shmobile/platsmp-apmu.c |  1 -
 arch/arm/mach-shmobile/platsmp-scu.c  |  4 +++-
 arch/arm/mach-shmobile/smp-r8a7779.c  |  2 --
 6 files changed, 19 insertions(+), 23 deletions(-)


From horms+renesas at verge.net.au  Thu Feb 18 22:09:44 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Feb 2016 15:09:44 +0900
Subject: [PATCH 1/4] ARM: shmobile: Move shmobile_scu_base from .text to .bss
In-Reply-To: <cover.1455859965.git.horms+renesas@verge.net.au>
References: <cover.1455859965.git.horms+renesas@verge.net.au>
Message-ID: <d2613f56ce0287211d70a86443a143cae1887911.1455859965.git.horms+renesas@verge.net.au>

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

shmobile_scu_base is being written to, so it doesn't belong in the .text
section. Fix this by moving it from asm .text to C .bss, as it's no
longer used from asm code since commit 4f6da36f7edd5790 ("ARM: shmobile:
Remove old SCU boot code").

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/headsmp-scu.S | 6 ------
 arch/arm/mach-shmobile/platsmp-scu.c | 3 +++
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/headsmp-scu.S b/arch/arm/mach-shmobile/headsmp-scu.S
index fa5248c52399..5e503d91ad70 100644
--- a/arch/arm/mach-shmobile/headsmp-scu.S
+++ b/arch/arm/mach-shmobile/headsmp-scu.S
@@ -38,9 +38,3 @@ ENTRY(shmobile_boot_scu)
 
 	b	secondary_startup
 ENDPROC(shmobile_boot_scu)
-
-	.text
-	.align	2
-	.globl	shmobile_scu_base
-shmobile_scu_base:
-	.space	4
diff --git a/arch/arm/mach-shmobile/platsmp-scu.c b/arch/arm/mach-shmobile/platsmp-scu.c
index 64663110ab6c..f2198c9c7435 100644
--- a/arch/arm/mach-shmobile/platsmp-scu.c
+++ b/arch/arm/mach-shmobile/platsmp-scu.c
@@ -17,6 +17,9 @@
 #include <asm/smp_scu.h>
 #include "common.h"
 
+
+void __iomem *shmobile_scu_base;
+
 static int shmobile_smp_scu_notifier_call(struct notifier_block *nfb,
 					  unsigned long action, void *hcpu)
 {
-- 
2.1.4



From horms+renesas at verge.net.au  Thu Feb 18 22:09:45 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Feb 2016 15:09:45 +0900
Subject: [PATCH 2/4] ARM: shmobile: r8a7779: Remove remainings of removed SCU
 boot setup code
In-Reply-To: <cover.1455859965.git.horms+renesas@verge.net.au>
References: <cover.1455859965.git.horms+renesas@verge.net.au>
Message-ID: <b1568d80123a7e7ab528f587ef6896b2d5413b61.1455859965.git.horms+renesas@verge.net.au>

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

Commit 0ca2894b5a900709 ("ARM: shmobile: Use shared SCU SMP boot code on
r8a7779") obsoleted the r8a7779-specific SCU boot code, but forgot to
remove the setup of shmobile_boot_fn and shmobile_boot_arg, which is
overwritten by shmobile_smp_scu_prepare_cpus().

Note that shmobile_scu_base wasn't initialized at that point yet anyway.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/smp-r8a7779.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/smp-r8a7779.c b/arch/arm/mach-shmobile/smp-r8a7779.c
index b854fe2095ad..0b024a9dbd43 100644
--- a/arch/arm/mach-shmobile/smp-r8a7779.c
+++ b/arch/arm/mach-shmobile/smp-r8a7779.c
@@ -92,8 +92,6 @@ static void __init r8a7779_smp_prepare_cpus(unsigned int max_cpus)
 {
 	/* Map the reset vector (in headsmp-scu.S, headsmp.S) */
 	__raw_writel(__pa(shmobile_boot_vector), AVECR);
-	shmobile_boot_fn = virt_to_phys(shmobile_boot_scu);
-	shmobile_boot_arg = (unsigned long)shmobile_scu_base;
 
 	/* setup r8a7779 specific SCU bits */
 	shmobile_scu_base = IOMEM(R8A7779_SCU_BASE);
-- 
2.1.4



From horms+renesas at verge.net.au  Thu Feb 18 22:09:46 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Feb 2016 15:09:46 +0900
Subject: [PATCH 3/4] ARM: shmobile: Move shmobile_smp_{mpidr, fn,
 arg}[] from .text to .bss
In-Reply-To: <cover.1455859965.git.horms+renesas@verge.net.au>
References: <cover.1455859965.git.horms+renesas@verge.net.au>
Message-ID: <4e960f52fce16a3bf3261fa92c34cf2306059ba2.1455859965.git.horms+renesas@verge.net.au>

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

If CONFIG_DEBUG_RODATA=y, the kernel crashes during system suspend:

    Freezing user space processes ... (elapsed 0.004 seconds) done.
    Freezing remaining freezable tasks ... (elapsed 0.002 seconds)
    done.
    PM: suspend of devices complete after 111.948 msecs
    PM: late suspend of devices complete after 1.086 msecs
    PM: noirq suspend of devices complete after 11.576 msecs
    Disabling non-boot CPUs ...
    Kernel panic - not syncing: Attempted to kill the idle task!
    1014ec ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
    CPU0: stopping

This happens because the .text section is marked read-only, while the
arrays shmobile_smp_mpidr[], shmobile_smp_fn[], and shmobile_smp_arg[]
are being written to.

Fix this by moving these arrays from the .text to the .bss section.
This requires accessing them through PC-relative offsets.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Reviewed-by: Kees Cook <keescook at chromium.org>
Reviewed-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/headsmp.S | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index 330c1fc63197..94d86ed16414 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -50,9 +50,11 @@ ENTRY(shmobile_smp_boot)
 	mrc	p15, 0, r1, c0, c0, 5		@ r1 = MPIDR
 	and	r0, r1, r0			@ r0 = cpu_logical_map() value
 	mov	r1, #0				@ r1 = CPU index
-	adr	r5, 1f				@ array of per-cpu mpidr values
-	adr	r6, 2f				@ array of per-cpu functions
-	adr	r7, 3f				@ array of per-cpu arguments
+	adr	r2, 1f
+	ldmia	r2, {r5, r6, r7}
+	add	r5, r5, r2			@ array of per-cpu mpidr values
+	add	r6, r6, r2			@ array of per-cpu functions
+	add	r7, r7, r2			@ array of per-cpu arguments
 
 shmobile_smp_boot_find_mpidr:
 	ldr	r8, [r5, r1, lsl #2]
@@ -80,12 +82,18 @@ ENTRY(shmobile_smp_sleep)
 	b	shmobile_smp_boot
 ENDPROC(shmobile_smp_sleep)
 
+	.align	2
+1:	.long	shmobile_smp_mpidr - .
+	.long	shmobile_smp_fn - 1b
+	.long	shmobile_smp_arg - 1b
+
+	.bss
 	.globl	shmobile_smp_mpidr
 shmobile_smp_mpidr:
-1:	.space	NR_CPUS * 4
+	.space	NR_CPUS * 4
 	.globl	shmobile_smp_fn
 shmobile_smp_fn:
-2:	.space	NR_CPUS * 4
+	.space	NR_CPUS * 4
 	.globl	shmobile_smp_arg
 shmobile_smp_arg:
-3:	.space	NR_CPUS * 4
+	.space	NR_CPUS * 4
-- 
2.1.4



From horms+renesas at verge.net.au  Thu Feb 18 22:09:47 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 19 Feb 2016 15:09:47 +0900
Subject: [PATCH 4/4] ARM: shmobile: Remove shmobile_boot_arg
In-Reply-To: <cover.1455859965.git.horms+renesas@verge.net.au>
References: <cover.1455859965.git.horms+renesas@verge.net.au>
Message-ID: <901c5ffaaed117a38be9d0c29247c4888d6c8636.1455859965.git.horms+renesas@verge.net.au>

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

CPU boot configuration writes to shmobile_boot_arg, which is located in
the .text section, and thus should not be written to.

As of commit 1d33a354bbb618ba ("ARM: shmobile: Per-CPU SMP boot / sleep
code for SCU SoCs"), and ignoring accidental remainings,
shmobile_boot_arg is always set to MPIDR_HWID_BITMASK by C code.
Hence we can just hardcode this in the assembler code, and remove the
variable, and thus also remove the need to write to this variable.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/common.h       | 1 -
 arch/arm/mach-shmobile/headsmp.S      | 8 ++------
 arch/arm/mach-shmobile/platsmp-apmu.c | 1 -
 arch/arm/mach-shmobile/platsmp-scu.c  | 1 -
 4 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-shmobile/common.h b/arch/arm/mach-shmobile/common.h
index 9cb11215ceba..b3a4ed5289ec 100644
--- a/arch/arm/mach-shmobile/common.h
+++ b/arch/arm/mach-shmobile/common.h
@@ -4,7 +4,6 @@
 extern void shmobile_init_delay(void);
 extern void shmobile_boot_vector(void);
 extern unsigned long shmobile_boot_fn;
-extern unsigned long shmobile_boot_arg;
 extern unsigned long shmobile_boot_size;
 extern void shmobile_smp_boot(void);
 extern void shmobile_smp_sleep(void);
diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S
index 94d86ed16414..32e0bf6e3ccb 100644
--- a/arch/arm/mach-shmobile/headsmp.S
+++ b/arch/arm/mach-shmobile/headsmp.S
@@ -24,7 +24,6 @@
 	.arm
 	.align  12
 ENTRY(shmobile_boot_vector)
-	ldr     r0, 2f
 	ldr     r1, 1f
 	bx	r1
 
@@ -34,9 +33,6 @@ ENDPROC(shmobile_boot_vector)
 	.globl	shmobile_boot_fn
 shmobile_boot_fn:
 1:	.space	4
-	.globl	shmobile_boot_arg
-shmobile_boot_arg:
-2:	.space	4
 	.globl	shmobile_boot_size
 shmobile_boot_size:
 	.long	. - shmobile_boot_vector
@@ -46,9 +42,9 @@ shmobile_boot_size:
  */
 
 ENTRY(shmobile_smp_boot)
-						@ r0 = MPIDR_HWID_BITMASK
 	mrc	p15, 0, r1, c0, c0, 5		@ r1 = MPIDR
-	and	r0, r1, r0			@ r0 = cpu_logical_map() value
+	and	r0, r1, #0xffffff		@ MPIDR_HWID_BITMASK
+						@ r0 = cpu_logical_map() value
 	mov	r1, #0				@ r1 = CPU index
 	adr	r2, 1f
 	ldmia	r2, {r5, r6, r7}
diff --git a/arch/arm/mach-shmobile/platsmp-apmu.c b/arch/arm/mach-shmobile/platsmp-apmu.c
index 911884f7e28b..aba75c89f9c1 100644
--- a/arch/arm/mach-shmobile/platsmp-apmu.c
+++ b/arch/arm/mach-shmobile/platsmp-apmu.c
@@ -123,7 +123,6 @@ void __init shmobile_smp_apmu_prepare_cpus(unsigned int max_cpus,
 {
 	/* install boot code shared by all CPUs */
 	shmobile_boot_fn = virt_to_phys(shmobile_smp_boot);
-	shmobile_boot_arg = MPIDR_HWID_BITMASK;
 
 	/* perform per-cpu setup */
 	apmu_parse_cfg(apmu_init_cpu, apmu_config, num);
diff --git a/arch/arm/mach-shmobile/platsmp-scu.c b/arch/arm/mach-shmobile/platsmp-scu.c
index f2198c9c7435..081a097c9219 100644
--- a/arch/arm/mach-shmobile/platsmp-scu.c
+++ b/arch/arm/mach-shmobile/platsmp-scu.c
@@ -44,7 +44,6 @@ void __init shmobile_smp_scu_prepare_cpus(unsigned int max_cpus)
 {
 	/* install boot code shared by all CPUs */
 	shmobile_boot_fn = virt_to_phys(shmobile_smp_boot);
-	shmobile_boot_arg = MPIDR_HWID_BITMASK;
 
 	/* enable SCU and cache coherency on booting CPU */
 	scu_enable(shmobile_scu_base);
-- 
2.1.4



From raveendra.padasalagi at broadcom.com  Thu Feb 18 22:13:50 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Fri, 19 Feb 2016 11:43:50 +0530
Subject: [PATCH v2 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <20160218143617.GH9654@rob-hp-laptop>
References: <1455702226-20599-1-git-send-email-raveendra.padasalagi@broadcom.com>
 <1455702226-20599-2-git-send-email-raveendra.padasalagi@broadcom.com>
 <20160218143617.GH9654@rob-hp-laptop>
Message-ID: <CAAFb_vq6_uQbcWvwV8TZqVqH_C-ueUd+gBRA=mXUQrWqxoz=ww@mail.gmail.com>

On Thu, Feb 18, 2016 at 8:06 PM, Rob Herring <robh at kernel.org> wrote:
> On Wed, Feb 17, 2016 at 03:13:44PM +0530, Raveendra Padasalagi wrote:
>> In Cygnus SOC touch screen controller registers are shared
>> with ADC and flex timer. Using readl/writel could lead to
>> race condition. So touch screen driver is enhanced to support
>>
>> 1. If touchscreen register's are not shared. Register access
>> is handled through readl/writel if "brcm,iproc-touchscreen"
>> compatible is provided in touchscreen dt node. This will help
>> for future SOC's if comes with dedicated touchscreen IP register's.
>>
>> 2. If touchscreen register's are shared with other IP's, register
>> access is handled through syscon framework API's to take care of
>> mutually exclusive access. This feature can be enabled by selecting
>> "brcm,iproc-touchscreen-syscon" compatible string in the touchscreen
>> dt node.
>>
>> Hence touchscreen dt node bindings document is updated to take care
>> of above changes in the touchscreen driver.
>>
>> Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi at broadcom.com>
>> Reviewed-by: Ray Jui <ray.jui at broadcom.com>
>> Reviewed-by: Scott Branden <scott.branden at broadcom.com>
>> ---
>>  .../input/touchscreen/brcm,iproc-touchscreen.txt   | 57 +++++++++++++++++++---
>>  1 file changed, 51 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>> index 34e3382..f530c25 100644
>> --- a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>> +++ b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>> @@ -1,12 +1,30 @@
>>  * Broadcom's IPROC Touchscreen Controller
>>
>>  Required properties:
>> -- compatible: must be "brcm,iproc-touchscreen"
>> -- reg: physical base address of the controller and length of memory mapped
>> -  region.
>> +- compatible: should be one of
>> +        "brcm,iproc-touchscreen"
>> +        "brcm,iproc-touchscreen-syscon"
>
> More specific and this is not how you do syscon. Either the block is or
> isn't. You can't have it both ways.

Existing driver has support for reg, if we modify now to support only syscon
then this driver will not work if some one wishes to use previous
kernel version's
dt and vice versa. Basically this breaks dt compatibility. Is that ok ?

>> +- ts_syscon: if "brcm,iproc-touchscreen-syscon" compatible string
>> +  is selected then "ts_syscon" is mandatory or else not required.
>> +  The "ts_syscon" is handler of syscon node defining physical base
>> +  address of the controller and length of memory mapped region.
>> +  If this property is selected please make sure MFD_SYSCON config
>> +  is enabled in the defconfig file.
>> +- reg: if "brcm,iproc-touchscreen" compatible string is selected
>> +  then "reg" property is mandatory or else not required.
>> +  The "reg" should be physical base address of the controller and
>> +  length of memory mapped region.
>
> I thought every chip to date is a syscon. Add reg support when you
> actually need it.

Since the existing driver has support for reg and now if we modify it to
support syscon only then we break the dt compatibility with previous kernel
versions. So keeping support for both will help to avoid dt
compatibility issues.

I will change the driver if you still think syscon only support is fine.
Let me know your opinion.

>>  - clocks:  The clock provided by the SOC to driver the tsc
>>  - clock-name:  name for the clock
>>  - interrupts: The touchscreen controller's interrupt
>> +- address-cells: Specify the number of u32 entries needed in child nodes.
>> +                 Should set to 1. This property is mandatory when
>> +                 "brcm,iproc-touchscreen-syscon" compatible string is selected
>> +                 or else not required.
>> +- size-cells: Specify number of u32 entries needed to specify child nodes size
>> +              in reg property. Should set to 1.This property is mandatory when
>> +              "brcm,iproc-touchscreen-syscon" compatible string is selected or
>> +              else not required.
>>
>>  Optional properties:
>>  - scanning_period: Time between scans. Each step is 1024 us.  Valid 1-256.
>> @@ -53,13 +71,40 @@ Optional properties:
>>  - touchscreen-inverted-x: X axis is inverted (boolean)
>>  - touchscreen-inverted-y: Y axis is inverted (boolean)
>>
>> -Example:
>> +Example 1: An example of touchscreen node with "brcm,iproc-touchscreen-syscon"
>> +           compatible string.
>> +
>> +     ts_adc_syscon: ts_adc_syscon at 0x180a6000 {
>> +             compatible = "syscon";
>> +             reg = <0x180a6000 0xc30>;
>> +     };
>>
>>       touchscreen: tsc at 0x180A6000 {
>
> Drop the '0x' and the node name should be touchscreen, not tsc.

I will address this in the next patch.

>> -             compatible = "brcm,iproc-touchscreen";
>> +             compatible = "brcm,iproc-touchscreen-syscon";
>>               #address-cells = <1>;
>>               #size-cells = <1>;
>> -             reg = <0x180A6000 0x40>;
>> +             ts_syscon = <&ts_adc_syscon>;
>> +             clocks = <&adc_clk>;
>> +             clock-names = "tsc_clk";
>> +             interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
>> +
>
>> +             scanning_period = <5>;
>> +             debounce_timeout = <40>;
>> +             settling_timeout = <7>;
>> +             touch_timeout = <10>;
>> +             average_data = <5>;
>> +             fifo_threshold = <1>;
>
> New properties?

No, These are existing properties.

>> +             /* Touchscreen is rotated 180 degrees. */
>> +             touchscreen-inverted-x;
>> +             touchscreen-inverted-y;
>> +     };
>> +
>> +Example 2: An example of touchscreen node with "brcm,iproc-touchscreen"
>> +          compatible string.
>> +
>> +     touchscreen: tsc at 0x180A6000 {
>> +             compatible = "brcm,iproc-touchscreen";
>> +             reg = <0x180a6000 0x40>;
>>               clocks = <&adc_clk>;
>>               clock-names = "tsc_clk";
>>               interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
>> --
>> 1.9.1
>>


From heiko at sntech.de  Thu Feb 18 22:31:10 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 19 Feb 2016 07:31:10 +0100
Subject: [PATCH v4 3/6] spi: rockchip: add bindings for rk3399 spi
In-Reply-To: <1455846978-4272-4-git-send-email-jay.xu@rock-chips.com>
References: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
 <1455846978-4272-4-git-send-email-jay.xu@rock-chips.com>
Message-ID: <2298327.hkyYk2mMRK@phil>

Hi Jianqun,

Am Freitag, 19. Februar 2016, 09:56:15 schrieb jianqun.xu:
> From: Jianqun Xu <jay.xu at rock-chips.com>
> 
> Add devicetree bindings for Rockchip rk3399 spi which found on
> Rockchip rk3399 SoCs.
> 
> Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>

Mark already applied this patch yesterday.


Heiko


From wei at redhat.com  Thu Feb 18 22:36:15 2016
From: wei at redhat.com (Wei Huang)
Date: Fri, 19 Feb 2016 00:36:15 -0600
Subject: [PATCH v2 0/6] arm64: Add support of KVM with ACPI
In-Reply-To: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
References: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
Message-ID: <56C6B7DF.4090606@redhat.com>



On 02/11/2016 09:33 AM, Julien Grall wrote:
> Hello,
> 
> This small series allows an ARM64 ACPI based platform to use KVM.
> 
> Currently the KVM code has to parse the firmware table to get the necessary
> information to setup the virtual timer and virtual GIC.
> 
> However the parsing of those tables are already done in the GIC and arch
> timer drivers.
> 
> This patch series introduces different helpers to retrieve the information
> from different drivers avoiding to duplicate the parsing code.
> 
> Note there is patch series ([1] and [2]) adding support of KVM on ACPI,
> although the approach chosen is completely different. The code to parse
> the firmware tables are duplicated which I think make more complex to
> support new firmware tables.

I backported these patches to my internal tree. It booted on an ARM64
machine. Even though I haven't got the chance to test it on an GICv3
machine (will update later), I think you can add my name as Tested-by if
needed.

-Wei

> 
> See the changes since v1 in the different patches.
> 
> Regards,
> 
> [1] https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018482.html
> [2] https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018355.html
> 
> Julien Grall (6):
>   KVM: arm/arm64: arch_timer: Gather KVM specific information in a
>     structure
>   KVM: arm/arm64: arch_timer: Rely on the arch timer to parse the
>     firmware tables
>   irqchip/gic-v2: Gather ACPI specific data in a single structure
>   irqchip/gic-v2: Parse and export virtual GIC information
>   irqchip/gic-v3: Parse and export virtual GIC information
>   KVM: arm/arm64: vgic: Rely on the GIC driver to parse the firmware
>     tables
> 
>  drivers/clocksource/arm_arch_timer.c   | 11 ++--
>  drivers/irqchip/irq-gic-common.c       | 13 +++++
>  drivers/irqchip/irq-gic-common.h       |  3 ++
>  drivers/irqchip/irq-gic-v3.c           | 36 ++++++++++++++
>  drivers/irqchip/irq-gic.c              | 91 ++++++++++++++++++++++++++++++++--
>  include/clocksource/arm_arch_timer.h   | 13 ++---
>  include/kvm/arm_vgic.h                 |  7 +--
>  include/linux/irqchip/arm-gic-common.h | 34 +++++++++++++
>  virt/kvm/arm/arch_timer.c              | 39 ++++-----------
>  virt/kvm/arm/vgic-v2.c                 | 67 +++++++++----------------
>  virt/kvm/arm/vgic-v3.c                 | 45 +++++------------
>  virt/kvm/arm/vgic.c                    | 50 ++++++++++---------
>  12 files changed, 264 insertions(+), 145 deletions(-)
>  create mode 100644 include/linux/irqchip/arm-gic-common.h
> 


From jay.xu at rock-chips.com  Thu Feb 18 22:38:17 2016
From: jay.xu at rock-chips.com (Jianqun Xu)
Date: Fri, 19 Feb 2016 14:38:17 +0800
Subject: [PATCH v4 3/6] spi: rockchip: add bindings for rk3399 spi
In-Reply-To: <2298327.hkyYk2mMRK@phil>
References: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
 <1455846978-4272-4-git-send-email-jay.xu@rock-chips.com>
 <2298327.hkyYk2mMRK@phil>
Message-ID: <56C6B859.8060608@rock-chips.com>

Hi Heiko

? 19/02/2016 14:31, Heiko Stuebner ??:
> Hi Jianqun,
>
> Am Freitag, 19. Februar 2016, 09:56:15 schrieb jianqun.xu:
>> From: Jianqun Xu <jay.xu at rock-chips.com>
>>
>> Add devicetree bindings for Rockchip rk3399 spi which found on
>> Rockchip rk3399 SoCs.
>>
>> Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
>> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
>
> Mark already applied this patch yesterday.
>

Good news, so the patch will be removed in next version's patchset.

thanks
>
> Heiko
>
>
>



From yangyingliang at huawei.com  Thu Feb 18 22:39:17 2016
From: yangyingliang at huawei.com (Yang Yingliang)
Date: Fri, 19 Feb 2016 14:39:17 +0800
Subject: A gic problem about eoi
In-Reply-To: <20160218090033.289de1c3@arm.com>
References: <56C5500A.2060104@huawei.com> <20160218090033.289de1c3@arm.com>
Message-ID: <56C6B895.6070400@huawei.com>



On 2016/2/18 17:00, Marc Zyngier wrote:
> On Thu, 18 Feb 2016 13:00:58 +0800
> Yang Yingliang <yangyingliang at huawei.com> wrote:
>
> Hi Yang,
>
>> Hi, Marc
>>
>> We found if hardware clear pending and active status is slower than
>> software handling, the new sgi will be merged because of hardware
>> status. The new sgi will be lost.
>>
>> If we add a dsb instruction after gic_write_eoir(), it can avoid this
>> case happening.
>>
>> Is it a right way to add a dsb instruction after gic_write_eoir()
>> in current gic driver code ?
>
> I suspect your problem is not so much the EOI, but that the read of
> ICC_IAR1_EL1 doesn't propagate the Ack quickly enough, leading to the
> transition from pending to active to still be in flux when the interrupt
> is EOIed. This is where a DSB is required (and was missing until very
> recently).
>
> Does 1a1ebd5 ("irqchip/gic-v3: Make sure read from ICC_IAR1_EL1 is
> visible on redestributor") solve your problem?

I tested this patch, it can solve the problem.

Will this patch queue to stable ?



From dirk.behme at de.bosch.com  Thu Feb 18 22:50:12 2016
From: dirk.behme at de.bosch.com (Dirk Behme)
Date: Fri, 19 Feb 2016 07:50:12 +0100
Subject: [PATCH v2] ARM: imx: Do L2 errata only if the L2 cache isn't enabled
Message-ID: <1455864612-12089-1-git-send-email-dirk.behme@de.bosch.com>

All the generic L2 cache handling code is encapsulated by a
check if the L2 cache is enabled. If it's enabled already, the code
is skipped. The write to the L2-Cache controller from non-secure
world causes an imprecise external abort. This is needed in
scenarios where one of the cores runs an other OS, e.g. an RTOS.

For the i.MX6 specific L2 cache handling we missed this check.
Add it.

Signed-off-by: Marcel Grosshans <MarcelViktor.Grosshans at de.bosch.com>
Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
---
Changes in v2: Update the commit message regarding the non-secure use case.

 arch/arm/mach-imx/system.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-imx/system.c b/arch/arm/mach-imx/system.c
index 51c3501..a600bd7 100644
--- a/arch/arm/mach-imx/system.c
+++ b/arch/arm/mach-imx/system.c
@@ -106,6 +106,9 @@ void __init imx_init_l2cache(void)
 		goto out;
 	}
 
+	if (readl_relaxed(l2x0_base + L2X0_CTRL) & L2X0_CTRL_EN)
+		goto skip_if_enabled;
+
 	/* Configure the L2 PREFETCH and POWER registers */
 	val = readl_relaxed(l2x0_base + L310_PREFETCH_CTRL);
 	val |= 0x70800000;
@@ -122,6 +125,7 @@ void __init imx_init_l2cache(void)
 		val &= ~(1 << 30 | 1 << 23);
 	writel_relaxed(val, l2x0_base + L310_PREFETCH_CTRL);
 
+skip_if_enabled:
 	iounmap(l2x0_base);
 	of_node_put(np);
 
-- 
2.5.0



From jayachandran.chandrashekaran at broadcom.com  Thu Feb 18 22:58:26 2016
From: jayachandran.chandrashekaran at broadcom.com (Jayachandran Chandrashekaran Nair)
Date: Fri, 19 Feb 2016 12:28:26 +0530
Subject: [PATCH 1/4] arm64: Broadcom Vulcan support
In-Reply-To: <20160217171616.GH32647@leverpostej>
References: <1455389195-31870-1-git-send-email-jchandra@broadcom.com>
 <1455389195-31870-2-git-send-email-jchandra@broadcom.com>
 <20160217171616.GH32647@leverpostej>
Message-ID: <CAKc_7PXte5nmtFRv4cQXJSFuWtAWnrBazYQJAEejX8ifxXRaMQ@mail.gmail.com>

On Wed, Feb 17, 2016 at 10:46 PM, Mark Rutland <mark.rutland at arm.com> wrote:
> Hi,
>
> On Sun, Feb 14, 2016 at 12:16:32AM +0530, Jayachandran C wrote:
>> From: Zi Shen Lim <zlim at broadcom.com>
>
>> +     compatible = "brcm,vulcan-eval", "brcm,vulcan";
>
> You use "brcm,vulcan" as the compatible string for both the platform and
> the CPU nodes. You need different strings.
>
>> +
>> +     memory {
>> +             device_type = "memory";
>> +             reg = <0x00000000 0x80000000 0x0 0x80000000>,  /* 2G @ 2G  */
>> +                   <0x00000008 0x80000000 0x0 0x80000000>;  /* 2G @ 34G */
>> +     };
>
>> +/memreserve/ 0x80000000 0x00010000;
>
> What is this for?

This seems to left over from the time we were using spin. Will take
it out. Thanks.

>> +
>> +/ {
>> +     model = "Broadcom Vulcan";
>> +     compatible = "brcm,vulcan";
>
> As above, it doesn't make sense to have the same compatible string for
> both the platform as a whole and the CPU.

Will fix this in v2.

>> +                     device_type = "cpu";
>> +                     compatible = "brcm,vulcan", "arm,armv8";
>> +                     reg = <0x0 0x0>;
>> +                     enable-method = "psci";
>> +             };

Thanks for the review.

JC.


From blogic at openwrt.org  Thu Feb 18 23:17:17 2016
From: blogic at openwrt.org (John Crispin)
Date: Fri, 19 Feb 2016 08:17:17 +0100
Subject: [PATCH V2 1/2] pinctrl: mediatek: Modify pinctrl bindings for mt7623
Message-ID: <1455866238-6102-1-git-send-email-blogic@openwrt.org>

Signed-off-by: John Crispin <blogic at openwrt.org>
Cc: devicetree at vger.kernel.org
---
please apply to the devel-mt2701 branch

Changes in V2
* make mt7623-pinfunc.h part of patch 1/2
* make sure the list stays sorted

 .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt |    1 +
 include/dt-bindings/pinctrl/mt7623-pinfunc.h       |  520 ++++++++++++++++++++
 2 files changed, 521 insertions(+)
 create mode 100644 include/dt-bindings/pinctrl/mt7623-pinfunc.h

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
index 9ffb0b2..17631d0 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
@@ -6,6 +6,7 @@ Required properties:
 - compatible: value should be one of the following.
 	"mediatek,mt2701-pinctrl", compatible with mt2701 pinctrl.
 	"mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl.
+	"mediatek,mt7623-pinctrl", compatible with mt7623 pinctrl.
 	"mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl.
 	"mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl.
 	"mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl.
diff --git a/include/dt-bindings/pinctrl/mt7623-pinfunc.h b/include/dt-bindings/pinctrl/mt7623-pinfunc.h
new file mode 100644
index 0000000..2f00bdc
--- /dev/null
+++ b/include/dt-bindings/pinctrl/mt7623-pinfunc.h
@@ -0,0 +1,520 @@
+#ifndef __DTS_MT7623_PINFUNC_H
+#define __DTS_MT7623_PINFUNC_H
+
+#include <dt-bindings/pinctrl/mt65xx.h>
+
+#define MT7623_PIN_0_PWRAP_SPI0_MI_FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
+#define MT7623_PIN_0_PWRAP_SPI0_MI_FUNC_PWRAP_SPIDO (MTK_PIN_NO(0) | 1)
+#define MT7623_PIN_0_PWRAP_SPI0_MI_FUNC_PWRAP_SPIDI (MTK_PIN_NO(0) | 2)
+
+#define MT7623_PIN_1_PWRAP_SPI0_MO_FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
+#define MT7623_PIN_1_PWRAP_SPI0_MO_FUNC_PWRAP_SPIDI (MTK_PIN_NO(1) | 1)
+#define MT7623_PIN_1_PWRAP_SPI0_MO_FUNC_PWRAP_SPIDO (MTK_PIN_NO(1) | 2)
+
+#define MT7623_PIN_2_PWRAP_INT_FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
+#define MT7623_PIN_2_PWRAP_INT_FUNC_PWRAP_INT (MTK_PIN_NO(2) | 1)
+
+#define MT7623_PIN_3_PWRAP_SPI0_CK_FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
+#define MT7623_PIN_3_PWRAP_SPI0_CK_FUNC_PWRAP_SPICK_I (MTK_PIN_NO(3) | 1)
+
+#define MT7623_PIN_4_PWRAP_SPI0_CSN_FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
+#define MT7623_PIN_4_PWRAP_SPI0_CSN_FUNC_PWRAP_SPICS_B_I (MTK_PIN_NO(4) | 1)
+
+#define MT7623_PIN_5_PWRAP_SPI0_CK2_FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
+#define MT7623_PIN_5_PWRAP_SPI0_CK2_FUNC_PWRAP_SPICK2_I (MTK_PIN_NO(5) | 1)
+
+#define MT7623_PIN_6_PWRAP_SPI0_CSN2_FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
+#define MT7623_PIN_6_PWRAP_SPI0_CSN2_FUNC_PWRAP_SPICS2_B_I (MTK_PIN_NO(6) | 1)
+
+#define MT7623_PIN_7_SPI1_CSN_FUNC_GPIO7 (MTK_PIN_NO(7) | 0)
+#define MT7623_PIN_7_SPI1_CSN_FUNC_SPI1_CS (MTK_PIN_NO(7) | 1)
+
+#define MT7623_PIN_8_SPI1_MI_FUNC_GPIO8 (MTK_PIN_NO(8) | 0)
+#define MT7623_PIN_8_SPI1_MI_FUNC_SPI1_MI (MTK_PIN_NO(8) | 1)
+#define MT7623_PIN_8_SPI1_MI_FUNC_SPI1_MO (MTK_PIN_NO(8) | 2)
+
+#define MT7623_PIN_9_SPI1_MO_FUNC_GPIO9 (MTK_PIN_NO(9) | 0)
+#define MT7623_PIN_9_SPI1_MO_FUNC_SPI1_MO (MTK_PIN_NO(9) | 1)
+#define MT7623_PIN_9_SPI1_MO_FUNC_SPI1_MI (MTK_PIN_NO(9) | 2)
+
+#define MT7623_PIN_10_RTC32K_CK_FUNC_GPIO10 (MTK_PIN_NO(10) | 0)
+#define MT7623_PIN_10_RTC32K_CK_FUNC_RTC32K_CK (MTK_PIN_NO(10) | 1)
+
+#define MT7623_PIN_11_WATCHDOG_FUNC_GPIO11 (MTK_PIN_NO(11) | 0)
+#define MT7623_PIN_11_WATCHDOG_FUNC_WATCHDOG (MTK_PIN_NO(11) | 1)
+
+#define MT7623_PIN_12_SRCLKENA_FUNC_GPIO12 (MTK_PIN_NO(12) | 0)
+#define MT7623_PIN_12_SRCLKENA_FUNC_SRCLKENA (MTK_PIN_NO(12) | 1)
+
+#define MT7623_PIN_13_SRCLKENAI_FUNC_GPIO13 (MTK_PIN_NO(13) | 0)
+#define MT7623_PIN_13_SRCLKENAI_FUNC_SRCLKENAI (MTK_PIN_NO(13) | 1)
+
+#define MT7623_PIN_14_GPIO14_FUNC_GPIO14 (MTK_PIN_NO(14) | 0)
+#define MT7623_PIN_14_GPIO14_FUNC_URXD2 (MTK_PIN_NO(14) | 1)
+#define MT7623_PIN_14_GPIO14_FUNC_UTXD2 (MTK_PIN_NO(14) | 2)
+
+#define MT7623_PIN_15_GPIO15_FUNC_GPIO15 (MTK_PIN_NO(15) | 0)
+#define MT7623_PIN_15_GPIO15_FUNC_UTXD2 (MTK_PIN_NO(15) | 1)
+#define MT7623_PIN_15_GPIO15_FUNC_URXD2 (MTK_PIN_NO(15) | 2)
+
+#define MT7623_PIN_18_PCM_CLK_FUNC_GPIO18 (MTK_PIN_NO(18) | 0)
+#define MT7623_PIN_18_PCM_CLK_FUNC_PCM_CLK0 (MTK_PIN_NO(18) | 1)
+#define MT7623_PIN_18_PCM_CLK_FUNC_AP_PCM_CLKO (MTK_PIN_NO(18) | 6)
+
+#define MT7623_PIN_19_PCM_SYNC_FUNC_GPIO19 (MTK_PIN_NO(19) | 0)
+#define MT7623_PIN_19_PCM_SYNC_FUNC_PCM_SYNC (MTK_PIN_NO(19) | 1)
+#define MT7623_PIN_19_PCM_SYNC_FUNC_AP_PCM_SYNC (MTK_PIN_NO(19) | 6)
+
+#define MT7623_PIN_20_PCM_RX_FUNC_GPIO20 (MTK_PIN_NO(20) | 0)
+#define MT7623_PIN_20_PCM_RX_FUNC_PCM_RX (MTK_PIN_NO(20) | 1)
+#define MT7623_PIN_20_PCM_RX_FUNC_PCM_TX (MTK_PIN_NO(20) | 4)
+#define MT7623_PIN_20_PCM_RX_FUNC_AP_PCM_RX (MTK_PIN_NO(20) | 6)
+
+#define MT7623_PIN_21_PCM_TX_FUNC_GPIO21 (MTK_PIN_NO(21) | 0)
+#define MT7623_PIN_21_PCM_TX_FUNC_PCM_TX (MTK_PIN_NO(21) | 1)
+#define MT7623_PIN_21_PCM_TX_FUNC_PCM_RX (MTK_PIN_NO(21) | 4)
+#define MT7623_PIN_21_PCM_TX_FUNC_AP_PCM_TX (MTK_PIN_NO(21) | 6)
+
+#define MT7623_PIN_22_EINT0_FUNC_GPIO22 (MTK_PIN_NO(22) | 0)
+#define MT7623_PIN_22_EINT0_FUNC_UCTS0 (MTK_PIN_NO(22) | 1)
+#define MT7623_PIN_22_EINT0_FUNC_PCIE0_PERST_N (MTK_PIN_NO(22) | 2)
+
+#define MT7623_PIN_23_EINT1_FUNC_GPIO23 (MTK_PIN_NO(23) | 0)
+#define MT7623_PIN_23_EINT1_FUNC_URTS0 (MTK_PIN_NO(23) | 1)
+#define MT7623_PIN_23_EINT1_FUNC_PCIE1_PERST_N (MTK_PIN_NO(23) | 2)
+
+#define MT7623_PIN_24_EINT2_FUNC_GPIO24 (MTK_PIN_NO(24) | 0)
+#define MT7623_PIN_24_EINT2_FUNC_UCTS1 (MTK_PIN_NO(24) | 1)
+#define MT7623_PIN_24_EINT2_FUNC_PCIE2_PERST_N (MTK_PIN_NO(24) | 2)
+
+#define MT7623_PIN_25_EINT3_FUNC_GPIO25 (MTK_PIN_NO(25) | 0)
+#define MT7623_PIN_25_EINT3_FUNC_URTS1 (MTK_PIN_NO(25) | 1)
+
+#define MT7623_PIN_26_EINT4_FUNC_GPIO26 (MTK_PIN_NO(26) | 0)
+#define MT7623_PIN_26_EINT4_FUNC_UCTS3 (MTK_PIN_NO(26) | 1)
+#define MT7623_PIN_26_EINT4_FUNC_PCIE2_WAKE_N (MTK_PIN_NO(26) | 6)
+
+#define MT7623_PIN_27_EINT5_FUNC_GPIO27 (MTK_PIN_NO(27) | 0)
+#define MT7623_PIN_27_EINT5_FUNC_URTS3 (MTK_PIN_NO(27) | 1)
+#define MT7623_PIN_27_EINT5_FUNC_PCIE1_WAKE_N (MTK_PIN_NO(27) | 6)
+
+#define MT7623_PIN_28_EINT6_FUNC_GPIO28 (MTK_PIN_NO(28) | 0)
+#define MT7623_PIN_28_EINT6_FUNC_DRV_VBUS (MTK_PIN_NO(28) | 1)
+#define MT7623_PIN_28_EINT6_FUNC_PCIE0_WAKE_N (MTK_PIN_NO(28) | 6)
+
+#define MT7623_PIN_29_EINT7_FUNC_GPIO29 (MTK_PIN_NO(29) | 0)
+#define MT7623_PIN_29_EINT7_FUNC_IDDIG (MTK_PIN_NO(29) | 1)
+#define MT7623_PIN_29_EINT7_FUNC_MSDC1_WP (MTK_PIN_NO(29) | 2)
+#define MT7623_PIN_29_EINT7_FUNC_PCIE2_PERST_N (MTK_PIN_NO(29) | 6)
+
+#define MT7623_PIN_33_I2S1_DATA_FUNC_GPIO33 (MTK_PIN_NO(33) | 0)
+#define MT7623_PIN_33_I2S1_DATA_FUNC_I2S1_DATA (MTK_PIN_NO(33) | 1)
+#define MT7623_PIN_33_I2S1_DATA_FUNC_PCM_TX (MTK_PIN_NO(33) | 3)
+#define MT7623_PIN_33_I2S1_DATA_FUNC_AP_PCM_TX (MTK_PIN_NO(33) | 6)
+
+#define MT7623_PIN_34_I2S1_DATA_IN_FUNC_GPIO34 (MTK_PIN_NO(34) | 0)
+#define MT7623_PIN_34_I2S1_DATA_IN_FUNC_I2S1_DATA_IN (MTK_PIN_NO(34) | 1)
+#define MT7623_PIN_34_I2S1_DATA_IN_FUNC_PCM_RX (MTK_PIN_NO(34) | 3)
+#define MT7623_PIN_34_I2S1_DATA_IN_FUNC_AP_PCM_RX (MTK_PIN_NO(34) | 6)
+
+#define MT7623_PIN_35_I2S1_BCK_FUNC_GPIO35 (MTK_PIN_NO(35) | 0)
+#define MT7623_PIN_35_I2S1_BCK_FUNC_I2S1_BCK (MTK_PIN_NO(35) | 1)
+#define MT7623_PIN_35_I2S1_BCK_FUNC_PCM_CLK0 (MTK_PIN_NO(35) | 3)
+#define MT7623_PIN_35_I2S1_BCK_FUNC_AP_PCM_CLKO (MTK_PIN_NO(35) | 6)
+
+#define MT7623_PIN_36_I2S1_LRCK_FUNC_GPIO36 (MTK_PIN_NO(36) | 0)
+#define MT7623_PIN_36_I2S1_LRCK_FUNC_I2S1_LRCK (MTK_PIN_NO(36) | 1)
+#define MT7623_PIN_36_I2S1_LRCK_FUNC_PCM_SYNC (MTK_PIN_NO(36) | 3)
+#define MT7623_PIN_36_I2S1_LRCK_FUNC_AP_PCM_SYNC (MTK_PIN_NO(36) | 6)
+
+#define MT7623_PIN_37_I2S1_MCLK_FUNC_GPIO37 (MTK_PIN_NO(37) | 0)
+#define MT7623_PIN_37_I2S1_MCLK_FUNC_I2S1_MCLK (MTK_PIN_NO(37) | 1)
+
+#define MT7623_PIN_39_JTMS_FUNC_GPIO39 (MTK_PIN_NO(39) | 0)
+#define MT7623_PIN_39_JTMS_FUNC_JTMS (MTK_PIN_NO(39) | 1)
+
+#define MT7623_PIN_40_JTCK_FUNC_GPIO40 (MTK_PIN_NO(40) | 0)
+#define MT7623_PIN_40_JTCK_FUNC_JTCK (MTK_PIN_NO(40) | 1)
+
+#define MT7623_PIN_41_JTDI_FUNC_GPIO41 (MTK_PIN_NO(41) | 0)
+#define MT7623_PIN_41_JTDI_FUNC_JTDI (MTK_PIN_NO(41) | 1)
+
+#define MT7623_PIN_42_JTDO_FUNC_GPIO42 (MTK_PIN_NO(42) | 0)
+#define MT7623_PIN_42_JTDO_FUNC_JTDO (MTK_PIN_NO(42) | 1)
+
+#define MT7623_PIN_43_NCLE_FUNC_GPIO43 (MTK_PIN_NO(43) | 0)
+#define MT7623_PIN_43_NCLE_FUNC_NCLE (MTK_PIN_NO(43) | 1)
+#define MT7623_PIN_43_NCLE_FUNC_EXT_XCS2 (MTK_PIN_NO(43) | 2)
+
+#define MT7623_PIN_44_NCEB1_FUNC_GPIO44 (MTK_PIN_NO(44) | 0)
+#define MT7623_PIN_44_NCEB1_FUNC_NCEB1 (MTK_PIN_NO(44) | 1)
+#define MT7623_PIN_44_NCEB1_FUNC_IDDIG (MTK_PIN_NO(44) | 2)
+
+#define MT7623_PIN_45_NCEB0_FUNC_GPIO45 (MTK_PIN_NO(45) | 0)
+#define MT7623_PIN_45_NCEB0_FUNC_NCEB0 (MTK_PIN_NO(45) | 1)
+#define MT7623_PIN_45_NCEB0_FUNC_DRV_VBUS (MTK_PIN_NO(45) | 2)
+
+#define MT7623_PIN_46_IR_FUNC_GPIO46 (MTK_PIN_NO(46) | 0)
+#define MT7623_PIN_46_IR_FUNC_IR (MTK_PIN_NO(46) | 1)
+
+#define MT7623_PIN_47_NREB_FUNC_GPIO47 (MTK_PIN_NO(47) | 0)
+#define MT7623_PIN_47_NREB_FUNC_NREB (MTK_PIN_NO(47) | 1)
+
+#define MT7623_PIN_48_NRNB_FUNC_GPIO48 (MTK_PIN_NO(48) | 0)
+#define MT7623_PIN_48_NRNB_FUNC_NRNB (MTK_PIN_NO(48) | 1)
+
+#define MT7623_PIN_49_I2S0_DATA_FUNC_GPIO49 (MTK_PIN_NO(49) | 0)
+#define MT7623_PIN_49_I2S0_DATA_FUNC_I2S0_DATA (MTK_PIN_NO(49) | 1)
+#define MT7623_PIN_49_I2S0_DATA_FUNC_PCM_TX (MTK_PIN_NO(49) | 3)
+#define MT7623_PIN_49_I2S0_DATA_FUNC_AP_I2S_DO (MTK_PIN_NO(49) | 6)
+
+#define MT7623_PIN_53_SPI0_CSN_FUNC_GPIO53 (MTK_PIN_NO(53) | 0)
+#define MT7623_PIN_53_SPI0_CSN_FUNC_SPI0_CS (MTK_PIN_NO(53) | 1)
+#define MT7623_PIN_53_SPI0_CSN_FUNC_PWM1 (MTK_PIN_NO(53) | 5)
+
+#define MT7623_PIN_54_SPI0_CK_FUNC_GPIO54 (MTK_PIN_NO(54) | 0)
+#define MT7623_PIN_54_SPI0_CK_FUNC_SPI0_CK (MTK_PIN_NO(54) | 1)
+
+#define MT7623_PIN_55_SPI0_MI_FUNC_GPIO55 (MTK_PIN_NO(55) | 0)
+#define MT7623_PIN_55_SPI0_MI_FUNC_SPI0_MI (MTK_PIN_NO(55) | 1)
+#define MT7623_PIN_55_SPI0_MI_FUNC_SPI0_MO (MTK_PIN_NO(55) | 2)
+#define MT7623_PIN_55_SPI0_MI_FUNC_MSDC1_WP (MTK_PIN_NO(55) | 3)
+#define MT7623_PIN_55_SPI0_MI_FUNC_PWM2 (MTK_PIN_NO(55) | 5)
+
+#define MT7623_PIN_56_SPI0_MO_FUNC_GPIO56 (MTK_PIN_NO(56) | 0)
+#define MT7623_PIN_56_SPI0_MO_FUNC_SPI0_MO (MTK_PIN_NO(56) | 1)
+#define MT7623_PIN_56_SPI0_MO_FUNC_SPI0_MI (MTK_PIN_NO(56) | 2)
+
+#define MT7623_PIN_60_WB_RSTB_FUNC_GPIO60 (MTK_PIN_NO(60) | 0)
+#define MT7623_PIN_60_WB_RSTB_FUNC_WB_RSTB (MTK_PIN_NO(60) | 1)
+
+#define MT7623_PIN_61_GPIO61_FUNC_GPIO61 (MTK_PIN_NO(61) | 0)
+#define MT7623_PIN_61_GPIO61_FUNC_TEST_FD (MTK_PIN_NO(61) | 1)
+
+#define MT7623_PIN_62_GPIO62_FUNC_GPIO62 (MTK_PIN_NO(62) | 0)
+#define MT7623_PIN_62_GPIO62_FUNC_TEST_FC (MTK_PIN_NO(62) | 1)
+
+#define MT7623_PIN_63_WB_SCLK_FUNC_GPIO63 (MTK_PIN_NO(63) | 0)
+#define MT7623_PIN_63_WB_SCLK_FUNC_WB_SCLK (MTK_PIN_NO(63) | 1)
+
+#define MT7623_PIN_64_WB_SDATA_FUNC_GPIO64 (MTK_PIN_NO(64) | 0)
+#define MT7623_PIN_64_WB_SDATA_FUNC_WB_SDATA (MTK_PIN_NO(64) | 1)
+
+#define MT7623_PIN_65_WB_SEN_FUNC_GPIO65 (MTK_PIN_NO(65) | 0)
+#define MT7623_PIN_65_WB_SEN_FUNC_WB_SEN (MTK_PIN_NO(65) | 1)
+
+#define MT7623_PIN_66_WB_CRTL0_FUNC_GPIO66 (MTK_PIN_NO(66) | 0)
+#define MT7623_PIN_66_WB_CRTL0_FUNC_WB_CRTL0 (MTK_PIN_NO(66) | 1)
+
+#define MT7623_PIN_67_WB_CRTL1_FUNC_GPIO67 (MTK_PIN_NO(67) | 0)
+#define MT7623_PIN_67_WB_CRTL1_FUNC_WB_CRTL1 (MTK_PIN_NO(67) | 1)
+
+#define MT7623_PIN_68_WB_CRTL2_FUNC_GPIO68 (MTK_PIN_NO(68) | 0)
+#define MT7623_PIN_68_WB_CRTL2_FUNC_WB_CRTL2 (MTK_PIN_NO(68) | 1)
+
+#define MT7623_PIN_69_WB_CRTL3_FUNC_GPIO69 (MTK_PIN_NO(69) | 0)
+#define MT7623_PIN_69_WB_CRTL3_FUNC_WB_CRTL3 (MTK_PIN_NO(69) | 1)
+
+#define MT7623_PIN_70_WB_CRTL4_FUNC_GPIO70 (MTK_PIN_NO(70) | 0)
+#define MT7623_PIN_70_WB_CRTL4_FUNC_WB_CRTL4 (MTK_PIN_NO(70) | 1)
+
+#define MT7623_PIN_71_WB_CRTL5_FUNC_GPIO71 (MTK_PIN_NO(71) | 0)
+#define MT7623_PIN_71_WB_CRTL5_FUNC_WB_CRTL5 (MTK_PIN_NO(71) | 1)
+
+#define MT7623_PIN_72_I2S0_DATA_IN_FUNC_GPIO72 (MTK_PIN_NO(72) | 0)
+#define MT7623_PIN_72_I2S0_DATA_IN_FUNC_I2S0_DATA_IN (MTK_PIN_NO(72) | 1)
+#define MT7623_PIN_72_I2S0_DATA_IN_FUNC_PCM_RX (MTK_PIN_NO(72) | 3)
+#define MT7623_PIN_72_I2S0_DATA_IN_FUNC_PWM0 (MTK_PIN_NO(72) | 4)
+#define MT7623_PIN_72_I2S0_DATA_IN_FUNC_DISP_PWM (MTK_PIN_NO(72) | 5)
+#define MT7623_PIN_72_I2S0_DATA_IN_FUNC_AP_I2S_DI (MTK_PIN_NO(72) | 6)
+
+#define MT7623_PIN_73_I2S0_LRCK_FUNC_GPIO73 (MTK_PIN_NO(73) | 0)
+#define MT7623_PIN_73_I2S0_LRCK_FUNC_I2S0_LRCK (MTK_PIN_NO(73) | 1)
+#define MT7623_PIN_73_I2S0_LRCK_FUNC_PCM_SYNC (MTK_PIN_NO(73) | 3)
+#define MT7623_PIN_73_I2S0_LRCK_FUNC_AP_I2S_LRCK (MTK_PIN_NO(73) | 6)
+
+#define MT7623_PIN_74_I2S0_BCK_FUNC_GPIO74 (MTK_PIN_NO(74) | 0)
+#define MT7623_PIN_74_I2S0_BCK_FUNC_I2S0_BCK (MTK_PIN_NO(74) | 1)
+#define MT7623_PIN_74_I2S0_BCK_FUNC_PCM_CLK0 (MTK_PIN_NO(74) | 3)
+#define MT7623_PIN_74_I2S0_BCK_FUNC_AP_I2S_BCK (MTK_PIN_NO(74) | 6)
+
+#define MT7623_PIN_75_SDA0_FUNC_GPIO75 (MTK_PIN_NO(75) | 0)
+#define MT7623_PIN_75_SDA0_FUNC_SDA0 (MTK_PIN_NO(75) | 1)
+
+#define MT7623_PIN_76_SCL0_FUNC_GPIO76 (MTK_PIN_NO(76) | 0)
+#define MT7623_PIN_76_SCL0_FUNC_SCL0 (MTK_PIN_NO(76) | 1)
+
+#define MT7623_PIN_83_LCM_RST_FUNC_GPIO83 (MTK_PIN_NO(83) | 0)
+#define MT7623_PIN_83_LCM_RST_FUNC_LCM_RST (MTK_PIN_NO(83) | 1)
+
+#define MT7623_PIN_84_DSI_TE_FUNC_GPIO84 (MTK_PIN_NO(84) | 0)
+#define MT7623_PIN_84_DSI_TE_FUNC_DSI_TE (MTK_PIN_NO(84) | 1)
+
+#define MT7623_PIN_95_MIPI_TCN_FUNC_GPIO95 (MTK_PIN_NO(95) | 0)
+#define MT7623_PIN_95_MIPI_TCN_FUNC_TCN (MTK_PIN_NO(95) | 1)
+
+#define MT7623_PIN_96_MIPI_TCP_FUNC_GPIO96 (MTK_PIN_NO(96) | 0)
+#define MT7623_PIN_96_MIPI_TCP_FUNC_TCP (MTK_PIN_NO(96) | 1)
+
+#define MT7623_PIN_97_MIPI_TDN1_FUNC_GPIO97 (MTK_PIN_NO(97) | 0)
+#define MT7623_PIN_97_MIPI_TDN1_FUNC_TDN1 (MTK_PIN_NO(97) | 1)
+
+#define MT7623_PIN_98_MIPI_TDP1_FUNC_GPIO98 (MTK_PIN_NO(98) | 0)
+#define MT7623_PIN_98_MIPI_TDP1_FUNC_TDP1 (MTK_PIN_NO(98) | 1)
+
+#define MT7623_PIN_99_MIPI_TDN0_FUNC_GPIO99 (MTK_PIN_NO(99) | 0)
+#define MT7623_PIN_99_MIPI_TDN0_FUNC_TDN0 (MTK_PIN_NO(99) | 1)
+
+#define MT7623_PIN_100_MIPI_TDP0_FUNC_GPIO100 (MTK_PIN_NO(100) | 0)
+#define MT7623_PIN_100_MIPI_TDP0_FUNC_TDP0 (MTK_PIN_NO(100) | 1)
+
+#define MT7623_PIN_105_MSDC1_CMD_FUNC_GPIO105 (MTK_PIN_NO(105) | 0)
+#define MT7623_PIN_105_MSDC1_CMD_FUNC_MSDC1_CMD (MTK_PIN_NO(105) | 1)
+#define MT7623_PIN_105_MSDC1_CMD_FUNC_SDA1 (MTK_PIN_NO(105) | 3)
+#define MT7623_PIN_105_MSDC1_CMD_FUNC_I2SOUT_BCK (MTK_PIN_NO(105) | 6)
+
+#define MT7623_PIN_106_MSDC1_CLK_FUNC_GPIO106 (MTK_PIN_NO(106) | 0)
+#define MT7623_PIN_106_MSDC1_CLK_FUNC_MSDC1_CLK (MTK_PIN_NO(106) | 1)
+#define MT7623_PIN_106_MSDC1_CLK_FUNC_SCL1 (MTK_PIN_NO(106) | 3)
+#define MT7623_PIN_106_MSDC1_CLK_FUNC_I2SOUT_LRCK (MTK_PIN_NO(106) | 6)
+
+#define MT7623_PIN_107_MSDC1_DAT0_FUNC_GPIO107 (MTK_PIN_NO(107) | 0)
+#define MT7623_PIN_107_MSDC1_DAT0_FUNC_MSDC1_DAT0 (MTK_PIN_NO(107) | 1)
+#define MT7623_PIN_107_MSDC1_DAT0_FUNC_UTXD0 (MTK_PIN_NO(107) | 5)
+#define MT7623_PIN_107_MSDC1_DAT0_FUNC_I2SOUT_DATA_OUT (MTK_PIN_NO(107) | 6)
+
+#define MT7623_PIN_108_MSDC1_DAT1_FUNC_GPIO108 (MTK_PIN_NO(108) | 0)
+#define MT7623_PIN_108_MSDC1_DAT1_FUNC_MSDC1_DAT1 (MTK_PIN_NO(108) | 1)
+#define MT7623_PIN_108_MSDC1_DAT1_FUNC_PWM0 (MTK_PIN_NO(108) | 3)
+#define MT7623_PIN_108_MSDC1_DAT1_FUNC_URXD0 (MTK_PIN_NO(108) | 5)
+#define MT7623_PIN_108_MSDC1_DAT1_FUNC_PWM1 (MTK_PIN_NO(108) | 6)
+
+#define MT7623_PIN_109_MSDC1_DAT2_FUNC_GPIO109 (MTK_PIN_NO(109) | 0)
+#define MT7623_PIN_109_MSDC1_DAT2_FUNC_MSDC1_DAT2 (MTK_PIN_NO(109) | 1)
+#define MT7623_PIN_109_MSDC1_DAT2_FUNC_SDA2 (MTK_PIN_NO(109) | 3)
+#define MT7623_PIN_109_MSDC1_DAT2_FUNC_UTXD1 (MTK_PIN_NO(109) | 5)
+#define MT7623_PIN_109_MSDC1_DAT2_FUNC_PWM2 (MTK_PIN_NO(109) | 6)
+
+#define MT7623_PIN_110_MSDC1_DAT3_FUNC_GPIO110 (MTK_PIN_NO(110) | 0)
+#define MT7623_PIN_110_MSDC1_DAT3_FUNC_MSDC1_DAT3 (MTK_PIN_NO(110) | 1)
+#define MT7623_PIN_110_MSDC1_DAT3_FUNC_SCL2 (MTK_PIN_NO(110) | 3)
+#define MT7623_PIN_110_MSDC1_DAT3_FUNC_URXD1 (MTK_PIN_NO(110) | 5)
+#define MT7623_PIN_110_MSDC1_DAT3_FUNC_PWM3 (MTK_PIN_NO(110) | 6)
+
+#define MT7623_PIN_111_MSDC0_DAT7_FUNC_GPIO111 (MTK_PIN_NO(111) | 0)
+#define MT7623_PIN_111_MSDC0_DAT7_FUNC_MSDC0_DAT7 (MTK_PIN_NO(111) | 1)
+#define MT7623_PIN_111_MSDC0_DAT7_FUNC_NLD7 (MTK_PIN_NO(111) | 4)
+
+#define MT7623_PIN_112_MSDC0_DAT6_FUNC_GPIO112 (MTK_PIN_NO(112) | 0)
+#define MT7623_PIN_112_MSDC0_DAT6_FUNC_MSDC0_DAT6 (MTK_PIN_NO(112) | 1)
+#define MT7623_PIN_112_MSDC0_DAT6_FUNC_NLD6 (MTK_PIN_NO(112) | 4)
+
+#define MT7623_PIN_113_MSDC0_DAT5_FUNC_GPIO113 (MTK_PIN_NO(113) | 0)
+#define MT7623_PIN_113_MSDC0_DAT5_FUNC_MSDC0_DAT5 (MTK_PIN_NO(113) | 1)
+#define MT7623_PIN_113_MSDC0_DAT5_FUNC_NLD5 (MTK_PIN_NO(113) | 4)
+
+#define MT7623_PIN_114_MSDC0_DAT4_FUNC_GPIO114 (MTK_PIN_NO(114) | 0)
+#define MT7623_PIN_114_MSDC0_DAT4_FUNC_MSDC0_DAT4 (MTK_PIN_NO(114) | 1)
+#define MT7623_PIN_114_MSDC0_DAT4_FUNC_NLD4 (MTK_PIN_NO(114) | 4)
+
+#define MT7623_PIN_115_MSDC0_RSTB_FUNC_GPIO115 (MTK_PIN_NO(115) | 0)
+#define MT7623_PIN_115_MSDC0_RSTB_FUNC_MSDC0_RSTB (MTK_PIN_NO(115) | 1)
+#define MT7623_PIN_115_MSDC0_RSTB_FUNC_NLD8 (MTK_PIN_NO(115) | 4)
+
+#define MT7623_PIN_116_MSDC0_CMD_FUNC_GPIO116 (MTK_PIN_NO(116) | 0)
+#define MT7623_PIN_116_MSDC0_CMD_FUNC_MSDC0_CMD (MTK_PIN_NO(116) | 1)
+#define MT7623_PIN_116_MSDC0_CMD_FUNC_NALE (MTK_PIN_NO(116) | 4)
+
+#define MT7623_PIN_117_MSDC0_CLK_FUNC_GPIO117 (MTK_PIN_NO(117) | 0)
+#define MT7623_PIN_117_MSDC0_CLK_FUNC_MSDC0_CLK (MTK_PIN_NO(117) | 1)
+#define MT7623_PIN_117_MSDC0_CLK_FUNC_NWEB (MTK_PIN_NO(117) | 4)
+
+#define MT7623_PIN_118_MSDC0_DAT3_FUNC_GPIO118 (MTK_PIN_NO(118) | 0)
+#define MT7623_PIN_118_MSDC0_DAT3_FUNC_MSDC0_DAT3 (MTK_PIN_NO(118) | 1)
+#define MT7623_PIN_118_MSDC0_DAT3_FUNC_NLD3 (MTK_PIN_NO(118) | 4)
+
+#define MT7623_PIN_119_MSDC0_DAT2_FUNC_GPIO119 (MTK_PIN_NO(119) | 0)
+#define MT7623_PIN_119_MSDC0_DAT2_FUNC_MSDC0_DAT2 (MTK_PIN_NO(119) | 1)
+#define MT7623_PIN_119_MSDC0_DAT2_FUNC_NLD2 (MTK_PIN_NO(119) | 4)
+
+#define MT7623_PIN_120_MSDC0_DAT1_FUNC_GPIO120 (MTK_PIN_NO(120) | 0)
+#define MT7623_PIN_120_MSDC0_DAT1_FUNC_MSDC0_DAT1 (MTK_PIN_NO(120) | 1)
+#define MT7623_PIN_120_MSDC0_DAT1_FUNC_NLD1 (MTK_PIN_NO(120) | 4)
+
+#define MT7623_PIN_121_MSDC0_DAT0_FUNC_GPIO121 (MTK_PIN_NO(121) | 0)
+#define MT7623_PIN_121_MSDC0_DAT0_FUNC_MSDC0_DAT0 (MTK_PIN_NO(121) | 1)
+#define MT7623_PIN_121_MSDC0_DAT0_FUNC_NLD0 (MTK_PIN_NO(121) | 4)
+#define MT7623_PIN_121_MSDC0_DAT0_FUNC_WATCHDOG (MTK_PIN_NO(121) | 5)
+
+#define MT7623_PIN_122_GPIO122_FUNC_GPIO122 (MTK_PIN_NO(122) | 0)
+#define MT7623_PIN_122_GPIO122_FUNC_TEST (MTK_PIN_NO(122) | 1)
+#define MT7623_PIN_122_GPIO122_FUNC_SDA2 (MTK_PIN_NO(122) | 4)
+#define MT7623_PIN_122_GPIO122_FUNC_URXD0 (MTK_PIN_NO(122) | 5)
+
+#define MT7623_PIN_123_GPIO123_FUNC_GPIO123 (MTK_PIN_NO(123) | 0)
+#define MT7623_PIN_123_GPIO123_FUNC_TEST (MTK_PIN_NO(123) | 1)
+#define MT7623_PIN_123_GPIO123_FUNC_SCL2 (MTK_PIN_NO(123) | 4)
+#define MT7623_PIN_123_GPIO123_FUNC_UTXD0 (MTK_PIN_NO(123) | 5)
+
+#define MT7623_PIN_124_GPIO124_FUNC_GPIO124 (MTK_PIN_NO(124) | 0)
+#define MT7623_PIN_124_GPIO124_FUNC_TEST (MTK_PIN_NO(124) | 1)
+#define MT7623_PIN_124_GPIO124_FUNC_SDA1 (MTK_PIN_NO(124) | 4)
+#define MT7623_PIN_124_GPIO124_FUNC_PWM3 (MTK_PIN_NO(124) | 5)
+
+#define MT7623_PIN_125_GPIO125_FUNC_GPIO125 (MTK_PIN_NO(125) | 0)
+#define MT7623_PIN_125_GPIO125_FUNC_TEST (MTK_PIN_NO(125) | 1)
+#define MT7623_PIN_125_GPIO125_FUNC_SCL1 (MTK_PIN_NO(125) | 4)
+#define MT7623_PIN_125_GPIO125_FUNC_PWM4 (MTK_PIN_NO(125) | 5)
+
+#define MT7623_PIN_126_I2S0_MCLK_FUNC_GPIO126 (MTK_PIN_NO(126) | 0)
+#define MT7623_PIN_126_I2S0_MCLK_FUNC_I2S0_MCLK (MTK_PIN_NO(126) | 1)
+#define MT7623_PIN_126_I2S0_MCLK_FUNC_AP_I2S_MCLK (MTK_PIN_NO(126) | 6)
+
+#define MT7623_PIN_199_SPI1_CK_FUNC_GPIO199 (MTK_PIN_NO(199) | 0)
+#define MT7623_PIN_199_SPI1_CK_FUNC_SPI1_CK (MTK_PIN_NO(199) | 1)
+
+#define MT7623_PIN_200_URXD2_FUNC_GPIO200 (MTK_PIN_NO(200) | 0)
+#define MT7623_PIN_200_URXD2_FUNC_URXD2 (MTK_PIN_NO(200) | 6)
+
+#define MT7623_PIN_201_UTXD2_FUNC_GPIO201 (MTK_PIN_NO(201) | 0)
+#define MT7623_PIN_201_UTXD2_FUNC_UTXD2 (MTK_PIN_NO(201) | 6)
+
+#define MT7623_PIN_203_PWM0_FUNC_GPIO203 (MTK_PIN_NO(203) | 0)
+#define MT7623_PIN_203_PWM0_FUNC_PWM0 (MTK_PIN_NO(203) | 1)
+#define MT7623_PIN_203_PWM0_FUNC_DISP_PWM (MTK_PIN_NO(203) | 2)
+
+#define MT7623_PIN_204_PWM1_FUNC_GPIO204 (MTK_PIN_NO(204) | 0)
+#define MT7623_PIN_204_PWM1_FUNC_PWM1 (MTK_PIN_NO(204) | 1)
+
+#define MT7623_PIN_205_PWM2_FUNC_GPIO205 (MTK_PIN_NO(205) | 0)
+#define MT7623_PIN_205_PWM2_FUNC_PWM2 (MTK_PIN_NO(205) | 1)
+
+#define MT7623_PIN_206_PWM3_FUNC_GPIO206 (MTK_PIN_NO(206) | 0)
+#define MT7623_PIN_206_PWM3_FUNC_PWM3 (MTK_PIN_NO(206) | 1)
+
+#define MT7623_PIN_207_PWM4_FUNC_GPIO207 (MTK_PIN_NO(207) | 0)
+#define MT7623_PIN_207_PWM4_FUNC_PWM4 (MTK_PIN_NO(207) | 1)
+
+#define MT7623_PIN_208_AUD_EXT_CK1_FUNC_GPIO208 (MTK_PIN_NO(208) | 0)
+#define MT7623_PIN_208_AUD_EXT_CK1_FUNC_AUD_EXT_CK1 (MTK_PIN_NO(208) | 1)
+#define MT7623_PIN_208_AUD_EXT_CK1_FUNC_PWM0 (MTK_PIN_NO(208) | 2)
+#define MT7623_PIN_208_AUD_EXT_CK1_FUNC_PCIE0_PERST_N (MTK_PIN_NO(208) | 3)
+#define MT7623_PIN_208_AUD_EXT_CK1_FUNC_DISP_PWM (MTK_PIN_NO(208) | 5)
+
+#define MT7623_PIN_209_AUD_EXT_CK2_FUNC_GPIO209 (MTK_PIN_NO(209) | 0)
+#define MT7623_PIN_209_AUD_EXT_CK2_FUNC_AUD_EXT_CK2 (MTK_PIN_NO(209) | 1)
+#define MT7623_PIN_209_AUD_EXT_CK2_FUNC_MSDC1_WP (MTK_PIN_NO(209) | 2)
+#define MT7623_PIN_209_AUD_EXT_CK2_FUNC_PCIE1_PERST_N (MTK_PIN_NO(209) | 3)
+#define MT7623_PIN_209_AUD_EXT_CK2_FUNC_PWM1 (MTK_PIN_NO(209) | 5)
+
+#define MT7623_PIN_236_EXT_SDIO3_FUNC_GPIO236 (MTK_PIN_NO(236) | 0)
+#define MT7623_PIN_236_EXT_SDIO3_FUNC_EXT_SDIO3 (MTK_PIN_NO(236) | 1)
+#define MT7623_PIN_236_EXT_SDIO3_FUNC_IDDIG (MTK_PIN_NO(236) | 2)
+
+#define MT7623_PIN_237_EXT_SDIO2_FUNC_GPIO237 (MTK_PIN_NO(237) | 0)
+#define MT7623_PIN_237_EXT_SDIO2_FUNC_EXT_SDIO2 (MTK_PIN_NO(237) | 1)
+#define MT7623_PIN_237_EXT_SDIO2_FUNC_DRV_VBUS (MTK_PIN_NO(237) | 2)
+
+#define MT7623_PIN_238_EXT_SDIO1_FUNC_GPIO238 (MTK_PIN_NO(238) | 0)
+#define MT7623_PIN_238_EXT_SDIO1_FUNC_EXT_SDIO1 (MTK_PIN_NO(238) | 1)
+
+#define MT7623_PIN_239_EXT_SDIO0_FUNC_GPIO239 (MTK_PIN_NO(239) | 0)
+#define MT7623_PIN_239_EXT_SDIO0_FUNC_EXT_SDIO0 (MTK_PIN_NO(239) | 1)
+
+#define MT7623_PIN_240_EXT_XCS_FUNC_GPIO240 (MTK_PIN_NO(240) | 0)
+#define MT7623_PIN_240_EXT_XCS_FUNC_EXT_XCS (MTK_PIN_NO(240) | 1)
+
+#define MT7623_PIN_241_EXT_SCK_FUNC_GPIO241 (MTK_PIN_NO(241) | 0)
+#define MT7623_PIN_241_EXT_SCK_FUNC_EXT_SCK (MTK_PIN_NO(241) | 1)
+
+#define MT7623_PIN_242_URTS2_FUNC_GPIO242 (MTK_PIN_NO(242) | 0)
+#define MT7623_PIN_242_URTS2_FUNC_URTS2 (MTK_PIN_NO(242) | 1)
+#define MT7623_PIN_242_URTS2_FUNC_UTXD3 (MTK_PIN_NO(242) | 2)
+#define MT7623_PIN_242_URTS2_FUNC_URXD3 (MTK_PIN_NO(242) | 3)
+#define MT7623_PIN_242_URTS2_FUNC_SCL1 (MTK_PIN_NO(242) | 4)
+
+#define MT7623_PIN_243_UCTS2_FUNC_GPIO243 (MTK_PIN_NO(243) | 0)
+#define MT7623_PIN_243_UCTS2_FUNC_UCTS2 (MTK_PIN_NO(243) | 1)
+#define MT7623_PIN_243_UCTS2_FUNC_URXD3 (MTK_PIN_NO(243) | 2)
+#define MT7623_PIN_243_UCTS2_FUNC_UTXD3 (MTK_PIN_NO(243) | 3)
+#define MT7623_PIN_243_UCTS2_FUNC_SDA1 (MTK_PIN_NO(243) | 4)
+
+#define MT7623_PIN_250_GPIO250_FUNC_GPIO250 (MTK_PIN_NO(250) | 0)
+#define MT7623_PIN_250_GPIO250_FUNC_TEST_MD7 (MTK_PIN_NO(250) | 1)
+#define MT7623_PIN_250_GPIO250_FUNC_PCIE0_CLKREQ_N (MTK_PIN_NO(250) | 6)
+
+#define MT7623_PIN_251_GPIO251_FUNC_GPIO251 (MTK_PIN_NO(251) | 0)
+#define MT7623_PIN_251_GPIO251_FUNC_TEST_MD6 (MTK_PIN_NO(251) | 1)
+#define MT7623_PIN_251_GPIO251_FUNC_PCIE0_WAKE_N (MTK_PIN_NO(251) | 6)
+
+#define MT7623_PIN_252_GPIO252_FUNC_GPIO252 (MTK_PIN_NO(252) | 0)
+#define MT7623_PIN_252_GPIO252_FUNC_TEST_MD5 (MTK_PIN_NO(252) | 1)
+#define MT7623_PIN_252_GPIO252_FUNC_PCIE1_CLKREQ_N (MTK_PIN_NO(252) | 6)
+
+#define MT7623_PIN_253_GPIO253_FUNC_GPIO253 (MTK_PIN_NO(253) | 0)
+#define MT7623_PIN_253_GPIO253_FUNC_TEST_MD4 (MTK_PIN_NO(253) | 1)
+#define MT7623_PIN_253_GPIO253_FUNC_PCIE1_WAKE_N (MTK_PIN_NO(253) | 6)
+
+#define MT7623_PIN_254_GPIO254_FUNC_GPIO254 (MTK_PIN_NO(254) | 0)
+#define MT7623_PIN_254_GPIO254_FUNC_TEST_MD3 (MTK_PIN_NO(254) | 1)
+#define MT7623_PIN_254_GPIO254_FUNC_PCIE2_CLKREQ_N (MTK_PIN_NO(254) | 6)
+
+#define MT7623_PIN_255_GPIO255_FUNC_GPIO255 (MTK_PIN_NO(255) | 0)
+#define MT7623_PIN_255_GPIO255_FUNC_TEST_MD2 (MTK_PIN_NO(255) | 1)
+#define MT7623_PIN_255_GPIO255_FUNC_PCIE2_WAKE_N (MTK_PIN_NO(255) | 6)
+
+#define MT7623_PIN_256_GPIO256_FUNC_GPIO256 (MTK_PIN_NO(256) | 0)
+#define MT7623_PIN_256_GPIO256_FUNC_TEST_MD1 (MTK_PIN_NO(256) | 1)
+
+#define MT7623_PIN_257_GPIO257_FUNC_GPIO257 (MTK_PIN_NO(257) | 0)
+#define MT7623_PIN_257_GPIO257_FUNC_TEST_MD0 (MTK_PIN_NO(257) | 1)
+
+#define MT7623_PIN_261_MSDC1_INS_FUNC_GPIO261 (MTK_PIN_NO(261) | 0)
+#define MT7623_PIN_261_MSDC1_INS_FUNC_MSDC1_INS (MTK_PIN_NO(261) | 1)
+
+#define MT7623_PIN_262_G2_TXEN_FUNC_GPIO262 (MTK_PIN_NO(262) | 0)
+#define MT7623_PIN_262_G2_TXEN_FUNC_G2_TXEN (MTK_PIN_NO(262) | 1)
+
+#define MT7623_PIN_263_G2_TXD3_FUNC_GPIO263 (MTK_PIN_NO(263) | 0)
+#define MT7623_PIN_263_G2_TXD3_FUNC_G2_TXD3 (MTK_PIN_NO(263) | 1)
+
+#define MT7623_PIN_264_G2_TXD2_FUNC_GPIO264 (MTK_PIN_NO(264) | 0)
+#define MT7623_PIN_264_G2_TXD2_FUNC_G2_TXD2 (MTK_PIN_NO(264) | 1)
+
+#define MT7623_PIN_265_G2_TXD1_FUNC_GPIO265 (MTK_PIN_NO(265) | 0)
+#define MT7623_PIN_265_G2_TXD1_FUNC_G2_TXD1 (MTK_PIN_NO(265) | 1)
+
+#define MT7623_PIN_266_G2_TXD0_FUNC_GPIO266 (MTK_PIN_NO(266) | 0)
+#define MT7623_PIN_266_G2_TXD0_FUNC_G2_TXD0 (MTK_PIN_NO(266) | 1)
+
+#define MT7623_PIN_267_G2_TXCLK_FUNC_GPIO267 (MTK_PIN_NO(267) | 0)
+#define MT7623_PIN_267_G2_TXCLK_FUNC_G2_TXC (MTK_PIN_NO(267) | 1)
+
+#define MT7623_PIN_268_G2_RXCLK_FUNC_GPIO268 (MTK_PIN_NO(268) | 0)
+#define MT7623_PIN_268_G2_RXCLK_FUNC_G2_RXC (MTK_PIN_NO(268) | 1)
+
+#define MT7623_PIN_269_G2_RXD0_FUNC_GPIO269 (MTK_PIN_NO(269) | 0)
+#define MT7623_PIN_269_G2_RXD0_FUNC_G2_RXD0 (MTK_PIN_NO(269) | 1)
+
+#define MT7623_PIN_270_G2_RXD1_FUNC_GPIO270 (MTK_PIN_NO(270) | 0)
+#define MT7623_PIN_270_G2_RXD1_FUNC_G2_RXD1 (MTK_PIN_NO(270) | 1)
+
+#define MT7623_PIN_271_G2_RXD2_FUNC_GPIO271 (MTK_PIN_NO(271) | 0)
+#define MT7623_PIN_271_G2_RXD2_FUNC_G2_RXD2 (MTK_PIN_NO(271) | 1)
+
+#define MT7623_PIN_272_G2_RXD3_FUNC_GPIO272 (MTK_PIN_NO(272) | 0)
+#define MT7623_PIN_272_G2_RXD3_FUNC_G2_RXD3 (MTK_PIN_NO(272) | 1)
+
+#define MT7623_PIN_274_G2_RXDV_FUNC_GPIO274 (MTK_PIN_NO(274) | 0)
+#define MT7623_PIN_274_G2_RXDV_FUNC_G2_RXDV (MTK_PIN_NO(274) | 1)
+
+#define MT7623_PIN_275_G2_MDC_FUNC_GPIO275 (MTK_PIN_NO(275) | 0)
+#define MT7623_PIN_275_G2_MDC_FUNC_MDC (MTK_PIN_NO(275) | 1)
+
+#define MT7623_PIN_276_G2_MDIO_FUNC_GPIO276 (MTK_PIN_NO(276) | 0)
+#define MT7623_PIN_276_G2_MDIO_FUNC_MDIO (MTK_PIN_NO(276) | 1)
+
+#define MT7623_PIN_278_JTAG_RESET_FUNC_GPIO278 (MTK_PIN_NO(278) | 0)
+#define MT7623_PIN_278_JTAG_RESET_FUNC_JTAG_RESET (MTK_PIN_NO(278) | 1)
+
+#endif /* __DTS_MT7623_PINFUNC_H */
-- 
1.7.10.4


From blogic at openwrt.org  Thu Feb 18 23:17:18 2016
From: blogic at openwrt.org (John Crispin)
Date: Fri, 19 Feb 2016 08:17:18 +0100
Subject: [PATCH V2 2/2] pinctrl: mediatek: Add Pinctrl/GPIO/EINT driver for
 MT7623
In-Reply-To: <1455866238-6102-1-git-send-email-blogic@openwrt.org>
References: <1455866238-6102-1-git-send-email-blogic@openwrt.org>
Message-ID: <1455866238-6102-2-git-send-email-blogic@openwrt.org>

Add the driver and header files required to make pinctrl work on MediaTek
MT7623.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
please apply to the devel-mt2701 branch

Changes in V2
* fix typo in Kconfig
* move mt7623-pinfunc.h into 1/2

 drivers/pinctrl/mediatek/Kconfig              |    6 +
 drivers/pinctrl/mediatek/Makefile             |    1 +
 drivers/pinctrl/mediatek/pinctrl-mt7623.c     |  380 +++++
 drivers/pinctrl/mediatek/pinctrl-mtk-mt7623.h | 1936 +++++++++++++++++++++++++
 4 files changed, 2323 insertions(+)
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7623.c
 create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt7623.h

diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 13e9939..78654a8 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -15,6 +15,12 @@ config PINCTRL_MT2701
 	default MACH_MT2701
 	select PINCTRL_MTK_COMMON
 
+config PINCTRL_MT7623
+	bool "Mediatek MT7623 pin control" if COMPILE_TEST && !MACH_MT7623
+	depends on OF
+	default MACH_MT7623
+	select PINCTRL_MTK_COMMON
+
 config PINCTRL_MT8135
 	bool "Mediatek MT8135 pin control" if COMPILE_TEST && !MACH_MT8135
 	depends on OF
diff --git a/drivers/pinctrl/mediatek/Makefile b/drivers/pinctrl/mediatek/Makefile
index da30314..1be2f3f 100644
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PINCTRL_MTK_COMMON)	+= pinctrl-mtk-common.o
 
 # SoC Drivers
 obj-$(CONFIG_PINCTRL_MT2701)		+= pinctrl-mt2701.o
+obj-$(CONFIG_PINCTRL_MT7623)		+= pinctrl-mt7623.o
 obj-$(CONFIG_PINCTRL_MT8135)		+= pinctrl-mt8135.o
 obj-$(CONFIG_PINCTRL_MT8127)		+= pinctrl-mt8127.o
 obj-$(CONFIG_PINCTRL_MT8173)		+= pinctrl-mt8173.o
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7623.c b/drivers/pinctrl/mediatek/pinctrl-mt7623.c
new file mode 100644
index 0000000..bf0d05b
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7623.c
@@ -0,0 +1,380 @@
+/*
+ * Copyright (c) 2016 John Crispin <blogic at openwrt.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <dt-bindings/pinctrl/mt65xx.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/regmap.h>
+
+#include "pinctrl-mtk-common.h"
+#include "pinctrl-mtk-mt7623.h"
+
+static const struct mtk_drv_group_desc mt7623_drv_grp[] =  {
+	/* 0E4E8SR 4/8/12/16 */
+	MTK_DRV_GRP(4, 16, 1, 2, 4),
+	/* 0E2E4SR  2/4/6/8 */
+	MTK_DRV_GRP(2, 8, 1, 2, 2),
+	/* E8E4E2  2/4/6/8/10/12/14/16 */
+	MTK_DRV_GRP(2, 16, 0, 2, 2)
+};
+
+#define DRV_SEL0	0xf50
+#define DRV_SEL1	0xf60
+#define DRV_SEL2	0xf70
+#define DRV_SEL3	0xf80
+#define DRV_SEL4	0xf90
+#define DRV_SEL5	0xfa0
+#define DRV_SEL6	0xfb0
+#define DRV_SEL7	0xfe0
+#define DRV_SEL8	0xfd0
+#define DRV_SEL9	0xff0
+#define DRV_SEL10	0xf00
+
+#define MSDC0_CTRL0	0xcc0
+#define MSDC0_CTRL1	0xcd0
+#define MSDC0_CTRL2	0xce0
+#define MSDC0_CTRL3	0xcf0
+#define MSDC0_CTRL4	0xd00
+#define MSDC0_CTRL5	0xd10
+#define MSDC0_CTRL6	0xd20
+#define MSDC1_CTRL0	0xd30
+#define MSDC1_CTRL1	0xd40
+#define MSDC1_CTRL2	0xd50
+#define MSDC1_CTRL3	0xd60
+#define MSDC1_CTRL4	0xd70
+#define MSDC1_CTRL5	0xd80
+#define MSDC1_CTRL6	0xd90
+
+#define IES_EN0		0xb20
+#define IES_EN1		0xb30
+#define IES_EN2		0xb40
+
+#define SMT_EN0		0xb50
+#define SMT_EN1		0xb60
+#define SMT_EN2		0xb70
+
+static const struct mtk_pin_drv_grp mt7623_pin_drv[] = {
+	MTK_PIN_DRV_GRP(0, DRV_SEL0, 0, 1),
+	MTK_PIN_DRV_GRP(1, DRV_SEL0, 0, 1),
+	MTK_PIN_DRV_GRP(2, DRV_SEL0, 0, 1),
+	MTK_PIN_DRV_GRP(3, DRV_SEL0, 0, 1),
+	MTK_PIN_DRV_GRP(4, DRV_SEL0, 0, 1),
+	MTK_PIN_DRV_GRP(5, DRV_SEL0, 0, 1),
+	MTK_PIN_DRV_GRP(6, DRV_SEL0, 0, 1),
+	MTK_PIN_DRV_GRP(7, DRV_SEL0, 4, 1),
+	MTK_PIN_DRV_GRP(8, DRV_SEL0, 4, 1),
+	MTK_PIN_DRV_GRP(9, DRV_SEL0, 4, 1),
+	MTK_PIN_DRV_GRP(10, DRV_SEL0, 8, 1),
+	MTK_PIN_DRV_GRP(11, DRV_SEL0, 8, 1),
+	MTK_PIN_DRV_GRP(12, DRV_SEL0, 8, 1),
+	MTK_PIN_DRV_GRP(13, DRV_SEL0, 8, 1),
+	MTK_PIN_DRV_GRP(14, DRV_SEL0, 12, 0),
+	MTK_PIN_DRV_GRP(15, DRV_SEL0, 12, 0),
+	MTK_PIN_DRV_GRP(18, DRV_SEL1, 4, 0),
+	MTK_PIN_DRV_GRP(19, DRV_SEL1, 4, 0),
+	MTK_PIN_DRV_GRP(20, DRV_SEL1, 4, 0),
+	MTK_PIN_DRV_GRP(21, DRV_SEL1, 4, 0),
+	MTK_PIN_DRV_GRP(22, DRV_SEL1, 8, 0),
+	MTK_PIN_DRV_GRP(23, DRV_SEL1, 8, 0),
+	MTK_PIN_DRV_GRP(24, DRV_SEL1, 8, 0),
+	MTK_PIN_DRV_GRP(25, DRV_SEL1, 8, 0),
+	MTK_PIN_DRV_GRP(26, DRV_SEL1, 8, 0),
+	MTK_PIN_DRV_GRP(27, DRV_SEL1, 12, 0),
+	MTK_PIN_DRV_GRP(28, DRV_SEL1, 12, 0),
+	MTK_PIN_DRV_GRP(29, DRV_SEL1, 12, 0),
+	MTK_PIN_DRV_GRP(33, DRV_SEL2, 0, 0),
+	MTK_PIN_DRV_GRP(34, DRV_SEL2, 0, 0),
+	MTK_PIN_DRV_GRP(35, DRV_SEL2, 0, 0),
+	MTK_PIN_DRV_GRP(36, DRV_SEL2, 0, 0),
+	MTK_PIN_DRV_GRP(37, DRV_SEL2, 0, 0),
+	MTK_PIN_DRV_GRP(39, DRV_SEL2, 8, 1),
+	MTK_PIN_DRV_GRP(40, DRV_SEL2, 8, 1),
+	MTK_PIN_DRV_GRP(41, DRV_SEL2, 8, 1),
+	MTK_PIN_DRV_GRP(42, DRV_SEL2, 8, 1),
+	MTK_PIN_DRV_GRP(43, DRV_SEL2, 12, 0),
+	MTK_PIN_DRV_GRP(44, DRV_SEL2, 12, 0),
+	MTK_PIN_DRV_GRP(45, DRV_SEL2, 12, 0),
+	MTK_PIN_DRV_GRP(47, DRV_SEL3, 0, 0),
+	MTK_PIN_DRV_GRP(48, DRV_SEL3, 0, 0),
+	MTK_PIN_DRV_GRP(49, DRV_SEL3, 4, 0),
+	MTK_PIN_DRV_GRP(53, DRV_SEL3, 12, 0),
+	MTK_PIN_DRV_GRP(54, DRV_SEL3, 12, 0),
+	MTK_PIN_DRV_GRP(55, DRV_SEL3, 12, 0),
+	MTK_PIN_DRV_GRP(56, DRV_SEL3, 12, 0),
+	MTK_PIN_DRV_GRP(60, DRV_SEL4, 8, 1),
+	MTK_PIN_DRV_GRP(61, DRV_SEL4, 8, 1),
+	MTK_PIN_DRV_GRP(62, DRV_SEL4, 8, 1),
+	MTK_PIN_DRV_GRP(63, DRV_SEL4, 12, 1),
+	MTK_PIN_DRV_GRP(64, DRV_SEL4, 12, 1),
+	MTK_PIN_DRV_GRP(65, DRV_SEL4, 12, 1),
+	MTK_PIN_DRV_GRP(66, DRV_SEL5, 0, 1),
+	MTK_PIN_DRV_GRP(67, DRV_SEL5, 0, 1),
+	MTK_PIN_DRV_GRP(68, DRV_SEL5, 0, 1),
+	MTK_PIN_DRV_GRP(69, DRV_SEL5, 0, 1),
+	MTK_PIN_DRV_GRP(70, DRV_SEL5, 0, 1),
+	MTK_PIN_DRV_GRP(71, DRV_SEL5, 0, 1),
+	MTK_PIN_DRV_GRP(72, DRV_SEL3, 4, 0),
+	MTK_PIN_DRV_GRP(73, DRV_SEL3, 4, 0),
+	MTK_PIN_DRV_GRP(74, DRV_SEL3, 4, 0),
+	MTK_PIN_DRV_GRP(83, DRV_SEL5, 0, 1),
+	MTK_PIN_DRV_GRP(84, DRV_SEL5, 0, 1),
+	MTK_PIN_DRV_GRP(105, MSDC1_CTRL1, 0, 1),
+	MTK_PIN_DRV_GRP(106, MSDC1_CTRL0, 0, 1),
+	MTK_PIN_DRV_GRP(107, MSDC1_CTRL2, 0, 1),
+	MTK_PIN_DRV_GRP(108, MSDC1_CTRL2, 0, 1),
+	MTK_PIN_DRV_GRP(109, MSDC1_CTRL2, 0, 1),
+	MTK_PIN_DRV_GRP(110, MSDC1_CTRL2, 0, 1),
+	MTK_PIN_DRV_GRP(111, MSDC0_CTRL2, 0, 1),
+	MTK_PIN_DRV_GRP(112, MSDC0_CTRL2, 0, 1),
+	MTK_PIN_DRV_GRP(113, MSDC0_CTRL2, 0, 1),
+	MTK_PIN_DRV_GRP(114, MSDC0_CTRL2, 0, 1),
+	MTK_PIN_DRV_GRP(115, MSDC0_CTRL2, 0, 1),
+	MTK_PIN_DRV_GRP(116, MSDC0_CTRL1, 0, 1),
+	MTK_PIN_DRV_GRP(117, MSDC0_CTRL0, 0, 1),
+	MTK_PIN_DRV_GRP(118, MSDC0_CTRL2, 0, 1),
+	MTK_PIN_DRV_GRP(119, MSDC0_CTRL2, 0, 1),
+	MTK_PIN_DRV_GRP(120, MSDC0_CTRL2, 0, 1),
+	MTK_PIN_DRV_GRP(121, MSDC0_CTRL2, 0, 1),
+	MTK_PIN_DRV_GRP(126, DRV_SEL3, 4, 0),
+	MTK_PIN_DRV_GRP(199, DRV_SEL0, 4, 1),
+	MTK_PIN_DRV_GRP(200, DRV_SEL8, 0, 0),
+	MTK_PIN_DRV_GRP(201, DRV_SEL8, 0, 0),
+	MTK_PIN_DRV_GRP(203, DRV_SEL8, 4, 0),
+	MTK_PIN_DRV_GRP(204, DRV_SEL8, 4, 0),
+	MTK_PIN_DRV_GRP(205, DRV_SEL8, 4, 0),
+	MTK_PIN_DRV_GRP(206, DRV_SEL8, 4, 0),
+	MTK_PIN_DRV_GRP(207, DRV_SEL8, 4, 0),
+	MTK_PIN_DRV_GRP(208, DRV_SEL8, 8, 0),
+	MTK_PIN_DRV_GRP(209, DRV_SEL8, 8, 0),
+	MTK_PIN_DRV_GRP(236, DRV_SEL9, 4, 0),
+	MTK_PIN_DRV_GRP(237, DRV_SEL9, 4, 0),
+	MTK_PIN_DRV_GRP(238, DRV_SEL9, 4, 0),
+	MTK_PIN_DRV_GRP(239, DRV_SEL9, 4, 0),
+	MTK_PIN_DRV_GRP(240, DRV_SEL9, 4, 0),
+	MTK_PIN_DRV_GRP(241, DRV_SEL9, 4, 0),
+	MTK_PIN_DRV_GRP(242, DRV_SEL9, 8, 0),
+	MTK_PIN_DRV_GRP(243, DRV_SEL9, 8, 0),
+	MTK_PIN_DRV_GRP(257, MSDC0_CTRL2, 0, 1),
+	MTK_PIN_DRV_GRP(261, MSDC1_CTRL2, 0, 1),
+	MTK_PIN_DRV_GRP(262, DRV_SEL10, 8, 0),
+	MTK_PIN_DRV_GRP(263, DRV_SEL10, 8, 0),
+	MTK_PIN_DRV_GRP(264, DRV_SEL10, 8, 0),
+	MTK_PIN_DRV_GRP(265, DRV_SEL10, 8, 0),
+	MTK_PIN_DRV_GRP(266, DRV_SEL10, 8, 0),
+	MTK_PIN_DRV_GRP(267, DRV_SEL10, 8, 0),
+	MTK_PIN_DRV_GRP(268, DRV_SEL10, 8, 0),
+	MTK_PIN_DRV_GRP(269, DRV_SEL10, 8, 0),
+	MTK_PIN_DRV_GRP(270, DRV_SEL10, 8, 0),
+	MTK_PIN_DRV_GRP(271, DRV_SEL10, 8, 0),
+	MTK_PIN_DRV_GRP(272, DRV_SEL10, 8, 0),
+	MTK_PIN_DRV_GRP(274, DRV_SEL10, 8, 0),
+	MTK_PIN_DRV_GRP(275, DRV_SEL10, 8, 0),
+	MTK_PIN_DRV_GRP(276, DRV_SEL10, 8, 0),
+	MTK_PIN_DRV_GRP(278, DRV_SEL2, 8, 1),
+};
+
+static const struct mtk_pin_spec_pupd_set_samereg mt7623_spec_pupd[] = {
+	MTK_PIN_PUPD_SPEC_SR(105, MSDC1_CTRL1, 8, 9, 10),
+	MTK_PIN_PUPD_SPEC_SR(106, MSDC1_CTRL0, 8, 9, 10),
+	MTK_PIN_PUPD_SPEC_SR(107, MSDC1_CTRL3, 0, 1, 2),
+	MTK_PIN_PUPD_SPEC_SR(108, MSDC1_CTRL3, 4, 5, 6),
+	MTK_PIN_PUPD_SPEC_SR(109, MSDC1_CTRL3, 8, 9, 10),
+	MTK_PIN_PUPD_SPEC_SR(110, MSDC1_CTRL3, 12, 13, 14),
+	MTK_PIN_PUPD_SPEC_SR(111, MSDC0_CTRL4, 12, 13, 14),
+	MTK_PIN_PUPD_SPEC_SR(112, MSDC0_CTRL4, 8, 9, 10),
+	MTK_PIN_PUPD_SPEC_SR(113, MSDC0_CTRL4, 4, 5, 6),
+	MTK_PIN_PUPD_SPEC_SR(114, MSDC0_CTRL4, 0, 1, 2),
+	MTK_PIN_PUPD_SPEC_SR(115, MSDC0_CTRL5, 0, 1, 2),
+	MTK_PIN_PUPD_SPEC_SR(116, MSDC0_CTRL1, 8, 9, 10),
+	MTK_PIN_PUPD_SPEC_SR(117, MSDC0_CTRL0, 8, 9, 10),
+	MTK_PIN_PUPD_SPEC_SR(118, MSDC0_CTRL3, 12, 13, 14),
+	MTK_PIN_PUPD_SPEC_SR(119, MSDC0_CTRL3, 8, 9, 10),
+	MTK_PIN_PUPD_SPEC_SR(120, MSDC0_CTRL3, 4, 5, 6),
+	MTK_PIN_PUPD_SPEC_SR(121, MSDC0_CTRL3, 0, 1, 2),
+};
+
+static int mt7623_spec_pull_set(struct regmap *regmap, unsigned int pin,
+		unsigned char align, bool isup, unsigned int r1r0)
+{
+	return mtk_pctrl_spec_pull_set_samereg(regmap, mt7623_spec_pupd,
+		ARRAY_SIZE(mt7623_spec_pupd), pin, align, isup, r1r0);
+}
+
+static const struct mtk_pin_ies_smt_set mt7623_ies_set[] = {
+	MTK_PIN_IES_SMT_SPEC(0, 6, IES_EN0, 0),
+	MTK_PIN_IES_SMT_SPEC(7, 9, IES_EN0, 1),
+	MTK_PIN_IES_SMT_SPEC(10, 13, IES_EN0, 2),
+	MTK_PIN_IES_SMT_SPEC(14, 15, IES_EN0, 3),
+	MTK_PIN_IES_SMT_SPEC(18, 21, IES_EN0, 5),
+	MTK_PIN_IES_SMT_SPEC(22, 26, IES_EN0, 6),
+	MTK_PIN_IES_SMT_SPEC(27, 29, IES_EN0, 7),
+	MTK_PIN_IES_SMT_SPEC(33, 37, IES_EN0, 8),
+	MTK_PIN_IES_SMT_SPEC(39, 42, IES_EN0, 9),
+	MTK_PIN_IES_SMT_SPEC(43, 45, IES_EN0, 10),
+	MTK_PIN_IES_SMT_SPEC(47, 48, IES_EN0, 11),
+	MTK_PIN_IES_SMT_SPEC(49, 49, IES_EN0, 12),
+	MTK_PIN_IES_SMT_SPEC(53, 56, IES_EN0, 14),
+	MTK_PIN_IES_SMT_SPEC(60, 62, IES_EN1, 0),
+	MTK_PIN_IES_SMT_SPEC(63, 65, IES_EN1, 1),
+	MTK_PIN_IES_SMT_SPEC(66, 71, IES_EN1, 2),
+	MTK_PIN_IES_SMT_SPEC(72, 74, IES_EN0, 12),
+	MTK_PIN_IES_SMT_SPEC(75, 76, IES_EN1, 3),
+	MTK_PIN_IES_SMT_SPEC(83, 84, IES_EN1, 2),
+	MTK_PIN_IES_SMT_SPEC(105, 121, MSDC1_CTRL1, 4),
+	MTK_PIN_IES_SMT_SPEC(122, 125, IES_EN1, 7),
+	MTK_PIN_IES_SMT_SPEC(126, 126, IES_EN0, 12),
+	MTK_PIN_IES_SMT_SPEC(199, 201, IES_EN0, 1),
+	MTK_PIN_IES_SMT_SPEC(203, 207, IES_EN2, 2),
+	MTK_PIN_IES_SMT_SPEC(208, 209, IES_EN2, 3),
+	MTK_PIN_IES_SMT_SPEC(236, 241, IES_EN2, 6),
+	MTK_PIN_IES_SMT_SPEC(242, 243, IES_EN2, 7),
+	MTK_PIN_IES_SMT_SPEC(261, 261, MSDC1_CTRL2, 4),
+	MTK_PIN_IES_SMT_SPEC(262, 272, IES_EN2, 12),
+	MTK_PIN_IES_SMT_SPEC(274, 276, IES_EN2, 12),
+	MTK_PIN_IES_SMT_SPEC(278, 278, IES_EN2, 13),
+};
+
+static const struct mtk_pin_ies_smt_set mt7623_smt_set[] = {
+	MTK_PIN_IES_SMT_SPEC(0, 6, SMT_EN0, 0),
+	MTK_PIN_IES_SMT_SPEC(7, 9, SMT_EN0, 1),
+	MTK_PIN_IES_SMT_SPEC(10, 13, SMT_EN0, 2),
+	MTK_PIN_IES_SMT_SPEC(14, 15, SMT_EN0, 3),
+	MTK_PIN_IES_SMT_SPEC(18, 21, SMT_EN0, 5),
+	MTK_PIN_IES_SMT_SPEC(22, 26, SMT_EN0, 6),
+	MTK_PIN_IES_SMT_SPEC(27, 29, SMT_EN0, 7),
+	MTK_PIN_IES_SMT_SPEC(33, 37, SMT_EN0, 8),
+	MTK_PIN_IES_SMT_SPEC(39, 42, SMT_EN0, 9),
+	MTK_PIN_IES_SMT_SPEC(43, 45, SMT_EN0, 10),
+	MTK_PIN_IES_SMT_SPEC(47, 48, SMT_EN0, 11),
+	MTK_PIN_IES_SMT_SPEC(49, 49, SMT_EN0, 12),
+	MTK_PIN_IES_SMT_SPEC(53, 56, SMT_EN0, 14),
+	MTK_PIN_IES_SMT_SPEC(60, 62, SMT_EN1, 0),
+	MTK_PIN_IES_SMT_SPEC(63, 65, SMT_EN1, 1),
+	MTK_PIN_IES_SMT_SPEC(66, 71, SMT_EN1, 2),
+	MTK_PIN_IES_SMT_SPEC(72, 74, SMT_EN0, 12),
+	MTK_PIN_IES_SMT_SPEC(75, 76, SMT_EN1, 3),
+	MTK_PIN_IES_SMT_SPEC(83, 84, SMT_EN1, 2),
+	MTK_PIN_IES_SMT_SPEC(105, 106, MSDC1_CTRL1, 11),
+	MTK_PIN_IES_SMT_SPEC(107, 107, MSDC1_CTRL3, 3),
+	MTK_PIN_IES_SMT_SPEC(108, 108, MSDC1_CTRL3, 7),
+	MTK_PIN_IES_SMT_SPEC(109, 109, MSDC1_CTRL3, 11),
+	MTK_PIN_IES_SMT_SPEC(110, 111, MSDC1_CTRL3, 15),
+	MTK_PIN_IES_SMT_SPEC(112, 112, MSDC0_CTRL4, 11),
+	MTK_PIN_IES_SMT_SPEC(113, 113, MSDC0_CTRL4, 7),
+	MTK_PIN_IES_SMT_SPEC(114, 115, MSDC0_CTRL4, 3),
+	MTK_PIN_IES_SMT_SPEC(116, 117, MSDC0_CTRL1, 11),
+	MTK_PIN_IES_SMT_SPEC(118, 118, MSDC0_CTRL3, 15),
+	MTK_PIN_IES_SMT_SPEC(119, 119, MSDC0_CTRL3, 11),
+	MTK_PIN_IES_SMT_SPEC(120, 120, MSDC0_CTRL3, 7),
+	MTK_PIN_IES_SMT_SPEC(121, 121, MSDC0_CTRL3, 3),
+	MTK_PIN_IES_SMT_SPEC(122, 125, SMT_EN1, 7),
+	MTK_PIN_IES_SMT_SPEC(126, 126, SMT_EN0, 12),
+	MTK_PIN_IES_SMT_SPEC(199, 201, SMT_EN0, 1),
+	MTK_PIN_IES_SMT_SPEC(203, 207, SMT_EN2, 2),
+	MTK_PIN_IES_SMT_SPEC(208, 209, SMT_EN2, 3),
+	MTK_PIN_IES_SMT_SPEC(236, 241, SMT_EN2, 6),
+	MTK_PIN_IES_SMT_SPEC(242, 243, SMT_EN2, 7),
+	MTK_PIN_IES_SMT_SPEC(261, 261, MSDC1_CTRL6, 3),
+	MTK_PIN_IES_SMT_SPEC(262, 272, SMT_EN2, 12),
+	MTK_PIN_IES_SMT_SPEC(274, 276, SMT_EN2, 12),
+	MTK_PIN_IES_SMT_SPEC(278, 278, SMT_EN2, 13),
+};
+
+static int mt7623_ies_smt_set(struct regmap *regmap, unsigned int pin,
+		unsigned char align, int value, enum pin_config_param arg)
+{
+	if (arg == PIN_CONFIG_INPUT_ENABLE)
+		return mtk_pconf_spec_set_ies_smt_range(regmap, mt7623_ies_set,
+			ARRAY_SIZE(mt7623_ies_set), pin, align, value);
+	else if (arg == PIN_CONFIG_INPUT_SCHMITT_ENABLE)
+		return mtk_pconf_spec_set_ies_smt_range(regmap, mt7623_smt_set,
+			ARRAY_SIZE(mt7623_smt_set), pin, align, value);
+	return -EINVAL;
+}
+
+static const struct mtk_pinctrl_devdata mt7623_pinctrl_data = {
+	.pins = mtk_pins_mt7623,
+	.npins = ARRAY_SIZE(mtk_pins_mt7623),
+	.grp_desc = mt7623_drv_grp,
+	.n_grp_cls = ARRAY_SIZE(mt7623_drv_grp),
+	.pin_drv_grp = mt7623_pin_drv,
+	.n_pin_drv_grps = ARRAY_SIZE(mt7623_pin_drv),
+	.spec_pull_set = mt7623_spec_pull_set,
+	.spec_ies_smt_set = mt7623_ies_smt_set,
+	.dir_offset = 0x0000,
+	.pullen_offset = 0x0150,
+	.pullsel_offset = 0x0280,
+	.dout_offset = 0x0500,
+	.din_offset = 0x0630,
+	.pinmux_offset = 0x0760,
+	.type1_start = 280,
+	.type1_end = 280,
+	.port_shf = 4,
+	.port_mask = 0x1f,
+	.port_align = 4,
+	.eint_offsets = {
+		.name = "mt7623_eint",
+		.stat      = 0x000,
+		.ack       = 0x040,
+		.mask      = 0x080,
+		.mask_set  = 0x0c0,
+		.mask_clr  = 0x100,
+		.sens      = 0x140,
+		.sens_set  = 0x180,
+		.sens_clr  = 0x1c0,
+		.soft      = 0x200,
+		.soft_set  = 0x240,
+		.soft_clr  = 0x280,
+		.pol       = 0x300,
+		.pol_set   = 0x340,
+		.pol_clr   = 0x380,
+		.dom_en    = 0x400,
+		.dbnc_ctrl = 0x500,
+		.dbnc_set  = 0x600,
+		.dbnc_clr  = 0x700,
+		.port_mask = 6,
+		.ports     = 6,
+	},
+	.ap_num = 169,
+	.db_cnt = 16,
+};
+
+static int mt7623_pinctrl_probe(struct platform_device *pdev)
+{
+	return mtk_pctrl_init(pdev, &mt7623_pinctrl_data, NULL);
+}
+
+static const struct of_device_id mt7623_pctrl_match[] = {
+	{ .compatible = "mediatek,mt7623-pinctrl", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, mt7623_pctrl_match);
+
+static struct platform_driver mtk_pinctrl_driver = {
+	.probe = mt7623_pinctrl_probe,
+	.driver = {
+		.name = "mediatek-mt7623-pinctrl",
+		.owner = THIS_MODULE,
+		.of_match_table = mt7623_pctrl_match,
+	},
+};
+
+static int __init mtk_pinctrl_init(void)
+{
+	return platform_driver_register(&mtk_pinctrl_driver);
+}
+
+arch_initcall(mtk_pinctrl_init);
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-mt7623.h b/drivers/pinctrl/mediatek/pinctrl-mtk-mt7623.h
new file mode 100644
index 0000000..3472a76
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-mt7623.h
@@ -0,0 +1,1936 @@
+/*
+ * Copyright (c) 2016 John Crispin <blogic at openwrt.org>
+ *
+ * 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.
+ */
+
+#ifndef __PINCTRL_MTK_MT7623_H
+#define __PINCTRL_MTK_MT7623_H
+
+#include <linux/pinctrl/pinctrl.h>
+#include "pinctrl-mtk-common.h"
+
+static const struct mtk_desc_pin mtk_pins_mt7623[] = {
+	MTK_PIN(
+		PINCTRL_PIN(0, "PWRAP_SPI0_MI"),
+		"J20", "mt7623",
+		MTK_EINT_FUNCTION(0, 148),
+		MTK_FUNCTION(0, "GPIO0"),
+		MTK_FUNCTION(1, "PWRAP_SPIDO"),
+		MTK_FUNCTION(2, "PWRAP_SPIDI")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(1, "PWRAP_SPI0_MO"),
+		"D10", "mt7623",
+		MTK_EINT_FUNCTION(0, 149),
+		MTK_FUNCTION(0, "GPIO1"),
+		MTK_FUNCTION(1, "PWRAP_SPIDI"),
+		MTK_FUNCTION(2, "PWRAP_SPIDO")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(2, "PWRAP_INT"),
+		"E11", "mt7623",
+		MTK_EINT_FUNCTION(0, 150),
+		MTK_FUNCTION(0, "GPIO2"),
+		MTK_FUNCTION(1, "PWRAP_INT")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(3, "PWRAP_SPI0_CK"),
+		"H12", "mt7623",
+		MTK_EINT_FUNCTION(0, 151),
+		MTK_FUNCTION(0, "GPIO3"),
+		MTK_FUNCTION(1, "PWRAP_SPICK_I")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(4, "PWRAP_SPI0_CSN"),
+		"E12", "mt7623",
+		MTK_EINT_FUNCTION(0, 152),
+		MTK_FUNCTION(0, "GPIO4"),
+		MTK_FUNCTION(1, "PWRAP_SPICS_B_I")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(5, "PWRAP_SPI0_CK2"),
+		"H11", "mt7623",
+		MTK_EINT_FUNCTION(0, 155),
+		MTK_FUNCTION(0, "GPIO5"),
+		MTK_FUNCTION(1, "PWRAP_SPICK2_I")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(6, "PWRAP_SPI0_CSN2"),
+		"G11", "mt7623",
+		MTK_EINT_FUNCTION(0, 156),
+		MTK_FUNCTION(0, "GPIO6"),
+		MTK_FUNCTION(1, "PWRAP_SPICS2_B_I")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(7, "SPI1_CSN"),
+		"G19", "mt7623",
+		MTK_EINT_FUNCTION(0, 153),
+		MTK_FUNCTION(0, "GPIO7"),
+		MTK_FUNCTION(1, "SPI1_CS")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(8, "SPI1_MI"),
+		"F19", "mt7623",
+		MTK_EINT_FUNCTION(0, 154),
+		MTK_FUNCTION(0, "GPIO8"),
+		MTK_FUNCTION(1, "SPI1_MI"),
+		MTK_FUNCTION(2, "SPI1_MO")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(9, "SPI1_MO"),
+		"G20", "mt7623",
+		MTK_EINT_FUNCTION(0, 157),
+		MTK_FUNCTION(0, "GPIO9"),
+		MTK_FUNCTION(1, "SPI1_MO"),
+		MTK_FUNCTION(2, "SPI1_MI")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(10, "RTC32K_CK"),
+		"A13", "mt7623",
+		MTK_EINT_FUNCTION(0, 158),
+		MTK_FUNCTION(0, "GPIO10"),
+		MTK_FUNCTION(1, "RTC32K_CK")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(11, "WATCHDOG"),
+		"D14", "mt7623",
+		MTK_EINT_FUNCTION(0, 159),
+		MTK_FUNCTION(0, "GPIO11"),
+		MTK_FUNCTION(1, "WATCHDOG")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(12, "SRCLKENA"),
+		"C13", "mt7623",
+		MTK_EINT_FUNCTION(0, 169),
+		MTK_FUNCTION(0, "GPIO12"),
+		MTK_FUNCTION(1, "SRCLKENA")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(13, "SRCLKENAI"),
+		"B13", "mt7623",
+		MTK_EINT_FUNCTION(0, 161),
+		MTK_FUNCTION(0, "GPIO13"),
+		MTK_FUNCTION(1, "SRCLKENAI")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(14, "GPIO14"),
+		"E18", "mt7623",
+		MTK_EINT_FUNCTION(0, 162),
+		MTK_FUNCTION(0, "GPIO14"),
+		MTK_FUNCTION(1, "URXD2"),
+		MTK_FUNCTION(2, "UTXD2")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(15, "GPIO15"),
+		"E17", "mt7623",
+		MTK_EINT_FUNCTION(0, 163),
+		MTK_FUNCTION(0, "GPIO15"),
+		MTK_FUNCTION(1, "UTXD2"),
+		MTK_FUNCTION(2, "URXD2")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(16, "GPIO16"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO16")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(17, "GPIO17"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO17")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(18, "PCM_CLK"),
+		"C19", "mt7623",
+		MTK_EINT_FUNCTION(0, 166),
+		MTK_FUNCTION(0, "GPIO18"),
+		MTK_FUNCTION(1, "PCM_CLK0"),
+		MTK_FUNCTION(6, "AP_PCM_CLKO")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(19, "PCM_SYNC"),
+		"D19", "mt7623",
+		MTK_EINT_FUNCTION(0, 167),
+		MTK_FUNCTION(0, "GPIO19"),
+		MTK_FUNCTION(1, "PCM_SYNC"),
+		MTK_FUNCTION(6, "AP_PCM_SYNC")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(20, "PCM_RX"),
+		"D18", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO20"),
+		MTK_FUNCTION(1, "PCM_RX"),
+		MTK_FUNCTION(4, "PCM_TX"),
+		MTK_FUNCTION(6, "AP_PCM_RX")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(21, "PCM_TX"),
+		"C18", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO21"),
+		MTK_FUNCTION(1, "PCM_TX"),
+		MTK_FUNCTION(4, "PCM_RX"),
+		MTK_FUNCTION(6, "AP_PCM_TX")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(22, "EINT0"),
+		"H15", "mt7623",
+		MTK_EINT_FUNCTION(0, 0),
+		MTK_FUNCTION(0, "GPIO22"),
+		MTK_FUNCTION(1, "UCTS0"),
+		MTK_FUNCTION(2, "PCIE0_PERST_N")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(23, "EINT1"),
+		"J16", "mt7623",
+		MTK_EINT_FUNCTION(0, 1),
+		MTK_FUNCTION(0, "GPIO23"),
+		MTK_FUNCTION(1, "URTS0"),
+		MTK_FUNCTION(2, "PCIE1_PERST_N")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(24, "EINT2"),
+		"H16", "mt7623",
+		MTK_EINT_FUNCTION(0, 2),
+		MTK_FUNCTION(0, "GPIO24"),
+		MTK_FUNCTION(1, "UCTS1"),
+		MTK_FUNCTION(2, "PCIE2_PERST_N")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(25, "EINT3"),
+		"K15", "mt7623",
+		MTK_EINT_FUNCTION(0, 3),
+		MTK_FUNCTION(0, "GPIO25"),
+		MTK_FUNCTION(1, "URTS1")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(26, "EINT4"),
+		"G15", "mt7623",
+		MTK_EINT_FUNCTION(0, 4),
+		MTK_FUNCTION(0, "GPIO26"),
+		MTK_FUNCTION(1, "UCTS3"),
+		MTK_FUNCTION(6, "PCIE2_WAKE_N")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(27, "EINT5"),
+		"F15", "mt7623",
+		MTK_EINT_FUNCTION(0, 5),
+		MTK_FUNCTION(0, "GPIO27"),
+		MTK_FUNCTION(1, "URTS3"),
+		MTK_FUNCTION(6, "PCIE1_WAKE_N")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(28, "EINT6"),
+		"J15", "mt7623",
+		MTK_EINT_FUNCTION(0, 6),
+		MTK_FUNCTION(0, "GPIO28"),
+		MTK_FUNCTION(1, "DRV_VBUS"),
+		MTK_FUNCTION(6, "PCIE0_WAKE_N")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(29, "EINT7"),
+		"E15", "mt7623",
+		MTK_EINT_FUNCTION(0, 7),
+		MTK_FUNCTION(0, "GPIO29"),
+		MTK_FUNCTION(1, "IDDIG"),
+		MTK_FUNCTION(2, "MSDC1_WP"),
+		MTK_FUNCTION(6, "PCIE2_PERST_N")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(30, "GPIO30"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO30")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(31, "GPIO31"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO31")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(32, "GPIO32"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO32")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(33, "I2S1_DATA"),
+		"Y18", "mt7623",
+		MTK_EINT_FUNCTION(0, 15),
+		MTK_FUNCTION(0, "GPIO33"),
+		MTK_FUNCTION(1, "I2S1_DATA"),
+		MTK_FUNCTION(3, "PCM_TX"),
+		MTK_FUNCTION(6, "AP_PCM_TX")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(34, "I2S1_DATA_IN"),
+		"Y17", "mt7623",
+		MTK_EINT_FUNCTION(0, 16),
+		MTK_FUNCTION(0, "GPIO34"),
+		MTK_FUNCTION(1, "I2S1_DATA_IN"),
+		MTK_FUNCTION(3, "PCM_RX"),
+		MTK_FUNCTION(6, "AP_PCM_RX")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(35, "I2S1_BCK"),
+		"V17", "mt7623",
+		MTK_EINT_FUNCTION(0, 17),
+		MTK_FUNCTION(0, "GPIO35"),
+		MTK_FUNCTION(1, "I2S1_BCK"),
+		MTK_FUNCTION(3, "PCM_CLK0"),
+		MTK_FUNCTION(6, "AP_PCM_CLKO")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(36, "I2S1_LRCK"),
+		"W17", "mt7623",
+		MTK_EINT_FUNCTION(0, 18),
+		MTK_FUNCTION(0, "GPIO36"),
+		MTK_FUNCTION(1, "I2S1_LRCK"),
+		MTK_FUNCTION(3, "PCM_SYNC"),
+		MTK_FUNCTION(6, "AP_PCM_SYNC")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(37, "I2S1_MCLK"),
+		"AA18", "mt7623",
+		MTK_EINT_FUNCTION(0, 19),
+		MTK_FUNCTION(0, "GPIO37"),
+		MTK_FUNCTION(1, "I2S1_MCLK")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(38, "GPIO38"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO38")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(39, "JTMS"),
+		"G21", "mt7623",
+		MTK_EINT_FUNCTION(0, 21),
+		MTK_FUNCTION(0, "GPIO39"),
+		MTK_FUNCTION(1, "JTMS")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(40, "GPIO40"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO40")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(41, "JTDI"),
+		"H22", "mt7623",
+		MTK_EINT_FUNCTION(0, 23),
+		MTK_FUNCTION(0, "GPIO41"),
+		MTK_FUNCTION(1, "JTDI")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(42, "JTDO"),
+		"H21", "mt7623",
+		MTK_EINT_FUNCTION(0, 24),
+		MTK_FUNCTION(0, "GPIO42"),
+		MTK_FUNCTION(1, "JTDO")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(43, "NCLE"),
+		"C7", "mt7623",
+		MTK_EINT_FUNCTION(0, 25),
+		MTK_FUNCTION(0, "GPIO43"),
+		MTK_FUNCTION(1, "NCLE"),
+		MTK_FUNCTION(2, "EXT_XCS2")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(44, "NCEB1"),
+		"C6", "mt7623",
+		MTK_EINT_FUNCTION(0, 26),
+		MTK_FUNCTION(0, "GPIO44"),
+		MTK_FUNCTION(1, "NCEB1"),
+		MTK_FUNCTION(2, "IDDIG")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(45, "NCEB0"),
+		"D7", "mt7623",
+		MTK_EINT_FUNCTION(0, 27),
+		MTK_FUNCTION(0, "GPIO45"),
+		MTK_FUNCTION(1, "NCEB0"),
+		MTK_FUNCTION(2, "DRV_VBUS")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(46, "IR"),
+		"D15", "mt7623",
+		MTK_EINT_FUNCTION(0, 28),
+		MTK_FUNCTION(0, "GPIO46"),
+		MTK_FUNCTION(1, "IR")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(47, "NREB"),
+		"A6", "mt7623",
+		MTK_EINT_FUNCTION(0, 29),
+		MTK_FUNCTION(0, "GPIO47"),
+		MTK_FUNCTION(1, "NREB")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(48, "NRNB"),
+		"B6", "mt7623",
+		MTK_EINT_FUNCTION(0, 30),
+		MTK_FUNCTION(0, "GPIO48"),
+		MTK_FUNCTION(1, "NRNB")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(49, "I2S0_DATA"),
+		"AB18", "mt7623",
+		MTK_EINT_FUNCTION(0, 31),
+		MTK_FUNCTION(0, "GPIO49"),
+		MTK_FUNCTION(1, "I2S0_DATA"),
+		MTK_FUNCTION(3, "PCM_TX"),
+		MTK_FUNCTION(6, "AP_I2S_DO")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(50, "GPIO50"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO50")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(51, "GPIO51"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO51")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(52, "GPIO52"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO52")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(53, "SPI0_CSN"),
+		"E7", "mt7623",
+		MTK_EINT_FUNCTION(0, 35),
+		MTK_FUNCTION(0, "GPIO53"),
+		MTK_FUNCTION(1, "SPI0_CS"),
+		MTK_FUNCTION(5, "PWM1")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(54, "SPI0_CK"),
+		"F7", "mt7623",
+		MTK_EINT_FUNCTION(0, 36),
+		MTK_FUNCTION(0, "GPIO54"),
+		MTK_FUNCTION(1, "SPI0_CK")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(55, "SPI0_MI"),
+		"E6", "mt7623",
+		MTK_EINT_FUNCTION(0, 37),
+		MTK_FUNCTION(0, "GPIO55"),
+		MTK_FUNCTION(1, "SPI0_MI"),
+		MTK_FUNCTION(2, "SPI0_MO"),
+		MTK_FUNCTION(3, "MSDC1_WP"),
+		MTK_FUNCTION(5, "PWM2")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(56, "SPI0_MO"),
+		"G7", "mt7623",
+		MTK_EINT_FUNCTION(0, 38),
+		MTK_FUNCTION(0, "GPIO56"),
+		MTK_FUNCTION(1, "SPI0_MO"),
+		MTK_FUNCTION(2, "SPI0_MI")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(57, "GPIO57"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO57")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(58, "GPIO58"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO58")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(59, "GPIO59"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO59")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(60, "WB_RSTB"),
+		"Y21", "mt7623",
+		MTK_EINT_FUNCTION(0, 41),
+		MTK_FUNCTION(0, "GPIO60"),
+		MTK_FUNCTION(1, "WB_RSTB")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(61, "GPIO61"),
+		"AA21", "mt7623",
+		MTK_EINT_FUNCTION(0, 42),
+		MTK_FUNCTION(0, "GPIO61"),
+		MTK_FUNCTION(1, "TEST_FD")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(62, "GPIO62"),
+		"AB22", "mt7623",
+		MTK_EINT_FUNCTION(0, 43),
+		MTK_FUNCTION(0, "GPIO62"),
+		MTK_FUNCTION(1, "TEST_FC")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(63, "WB_SCLK"),
+		"AC23", "mt7623",
+		MTK_EINT_FUNCTION(0, 44),
+		MTK_FUNCTION(0, "GPIO63"),
+		MTK_FUNCTION(1, "WB_SCLK")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(64, "WB_SDATA"),
+		"AB21", "mt7623",
+		MTK_EINT_FUNCTION(0, 45),
+		MTK_FUNCTION(0, "GPIO64"),
+		MTK_FUNCTION(1, "WB_SDATA")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(65, "WB_SEN"),
+		"AB24", "mt7623",
+		MTK_EINT_FUNCTION(0, 46),
+		MTK_FUNCTION(0, "GPIO65"),
+		MTK_FUNCTION(1, "WB_SEN")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(66, "WB_CRTL0"),
+		"AB20", "mt7623",
+		MTK_EINT_FUNCTION(0, 47),
+		MTK_FUNCTION(0, "GPIO66"),
+		MTK_FUNCTION(1, "WB_CRTL0")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(67, "WB_CRTL1"),
+		"AC20", "mt7623",
+		MTK_EINT_FUNCTION(0, 48),
+		MTK_FUNCTION(0, "GPIO67"),
+		MTK_FUNCTION(1, "WB_CRTL1")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(68, "WB_CRTL2"),
+		"AB19", "mt7623",
+		MTK_EINT_FUNCTION(0, 49),
+		MTK_FUNCTION(0, "GPIO68"),
+		MTK_FUNCTION(1, "WB_CRTL2")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(69, "WB_CRTL3"),
+		"AC19", "mt7623",
+		MTK_EINT_FUNCTION(0, 50),
+		MTK_FUNCTION(0, "GPIO69"),
+		MTK_FUNCTION(1, "WB_CRTL3")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(70, "WB_CRTL4"),
+		"AD19", "mt7623",
+		MTK_EINT_FUNCTION(0, 51),
+		MTK_FUNCTION(0, "GPIO70"),
+		MTK_FUNCTION(1, "WB_CRTL4")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(71, "WB_CRTL5"),
+		"AE19", "mt7623",
+		MTK_EINT_FUNCTION(0, 52),
+		MTK_FUNCTION(0, "GPIO71"),
+		MTK_FUNCTION(1, "WB_CRTL5")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(72, "I2S0_DATA_IN"),
+		"AA20", "mt7623",
+		MTK_EINT_FUNCTION(0, 53),
+		MTK_FUNCTION(0, "GPIO72"),
+		MTK_FUNCTION(1, "I2S0_DATA_IN"),
+		MTK_FUNCTION(3, "PCM_RX"),
+		MTK_FUNCTION(4, "PWM0"),
+		MTK_FUNCTION(5, "DISP_PWM"),
+		MTK_FUNCTION(6, "AP_I2S_DI")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(73, "I2S0_LRCK"),
+		"Y20", "mt7623",
+		MTK_EINT_FUNCTION(0, 54),
+		MTK_FUNCTION(0, "GPIO73"),
+		MTK_FUNCTION(1, "I2S0_LRCK"),
+		MTK_FUNCTION(3, "PCM_SYNC"),
+		MTK_FUNCTION(6, "AP_I2S_LRCK")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(74, "I2S0_BCK"),
+		"Y19", "mt7623",
+		MTK_EINT_FUNCTION(0, 55),
+		MTK_FUNCTION(0, "GPIO74"),
+		MTK_FUNCTION(1, "I2S0_BCK"),
+		MTK_FUNCTION(3, "PCM_CLK0"),
+		MTK_FUNCTION(6, "AP_I2S_BCK")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(75, "SDA0"),
+		"K19", "mt7623",
+		MTK_EINT_FUNCTION(0, 56),
+		MTK_FUNCTION(0, "GPIO75"),
+		MTK_FUNCTION(1, "SDA0")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(76, "SCL0"),
+		"K20", "mt7623",
+		MTK_EINT_FUNCTION(0, 57),
+		MTK_FUNCTION(0, "GPIO76"),
+		MTK_FUNCTION(1, "SCL0")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(77, "GPIO77"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO77")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(78, "GPIO78"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO78")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(79, "GPIO79"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO79")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(80, "GPIO80"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO80")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(81, "GPIO81"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO81")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(82, "GPIO82"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO82")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(83, "LCM_RST"),
+		"V16", "mt7623",
+		MTK_EINT_FUNCTION(0, 64),
+		MTK_FUNCTION(0, "GPIO83"),
+		MTK_FUNCTION(1, "LCM_RST")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(84, "DSI_TE"),
+		"V14", "mt7623",
+		MTK_EINT_FUNCTION(0, 65),
+		MTK_FUNCTION(0, "GPIO84"),
+		MTK_FUNCTION(1, "DSI_TE")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(85, "GPIO85"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO85")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(86, "GPIO86"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO86")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(87, "GPIO87"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO87")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(88, "GPIO88"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO88")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(89, "GPIO89"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO89")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(90, "GPIO90"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO90")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(91, "GPIO91"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO91")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(92, "GPIO92"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO92")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(93, "GPIO93"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO93")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(94, "GPIO94"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO94")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(95, "MIPI_TCN"),
+		"AB14", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO95"),
+		MTK_FUNCTION(1, "TCN")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(96, "MIPI_TCP"),
+		"AC14", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO96"),
+		MTK_FUNCTION(1, "TCP")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(97, "MIPI_TDN1"),
+		"AE15", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO97"),
+		MTK_FUNCTION(1, "TDN1")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(98, "MIPI_TDP1"),
+		"AD15", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO98"),
+		MTK_FUNCTION(1, "TDP1")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(99, "MIPI_TDN0"),
+		"AB15", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO99"),
+		MTK_FUNCTION(1, "TDN0")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(100, "MIPI_TDP0"),
+		"AC15", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO100"),
+		MTK_FUNCTION(1, "TDP0")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(101, "GPIO101"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO101")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(102, "GPIO102"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO102")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(103, "GPIO103"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO103")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(104, "GPIO104"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO104")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(105, "MSDC1_CMD"),
+		"AD2", "mt7623",
+		MTK_EINT_FUNCTION(0, 78),
+		MTK_FUNCTION(0, "GPIO105"),
+		MTK_FUNCTION(1, "MSDC1_CMD"),
+		MTK_FUNCTION(3, "SDA1"),
+		MTK_FUNCTION(6, "I2SOUT_BCK")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(106, "MSDC1_CLK"),
+		"AD3", "mt7623",
+		MTK_EINT_FUNCTION(0, 79),
+		MTK_FUNCTION(0, "GPIO106"),
+		MTK_FUNCTION(1, "MSDC1_CLK"),
+		MTK_FUNCTION(3, "SCL1"),
+		MTK_FUNCTION(6, "I2SOUT_LRCK")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(107, "MSDC1_DAT0"),
+		"AE2", "mt7623",
+		MTK_EINT_FUNCTION(0, 80),
+		MTK_FUNCTION(0, "GPIO107"),
+		MTK_FUNCTION(1, "MSDC1_DAT0"),
+		MTK_FUNCTION(5, "UTXD0"),
+		MTK_FUNCTION(6, "I2SOUT_DATA_OUT")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(108, "MSDC1_DAT1"),
+		"AC1", "mt7623",
+		MTK_EINT_FUNCTION(0, 81),
+		MTK_FUNCTION(0, "GPIO108"),
+		MTK_FUNCTION(1, "MSDC1_DAT1"),
+		MTK_FUNCTION(3, "PWM0"),
+		MTK_FUNCTION(5, "URXD0"),
+		MTK_FUNCTION(6, "PWM1")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(109, "MSDC1_DAT2"),
+		"AC3", "mt7623",
+		MTK_EINT_FUNCTION(0, 82),
+		MTK_FUNCTION(0, "GPIO109"),
+		MTK_FUNCTION(1, "MSDC1_DAT2"),
+		MTK_FUNCTION(3, "SDA2"),
+		MTK_FUNCTION(5, "UTXD1"),
+		MTK_FUNCTION(6, "PWM2")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(110, "MSDC1_DAT3"),
+		"AC4", "mt7623",
+		MTK_EINT_FUNCTION(0, 83),
+		MTK_FUNCTION(0, "GPIO110"),
+		MTK_FUNCTION(1, "MSDC1_DAT3"),
+		MTK_FUNCTION(3, "SCL2"),
+		MTK_FUNCTION(5, "URXD1"),
+		MTK_FUNCTION(6, "PWM3")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(111, "MSDC0_DAT7"),
+		"A2", "mt7623",
+		MTK_EINT_FUNCTION(0, 84),
+		MTK_FUNCTION(0, "GPIO111"),
+		MTK_FUNCTION(1, "MSDC0_DAT7"),
+		MTK_FUNCTION(4, "NLD7")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(112, "MSDC0_DAT6"),
+		"B3", "mt7623",
+		MTK_EINT_FUNCTION(0, 85),
+		MTK_FUNCTION(0, "GPIO112"),
+		MTK_FUNCTION(1, "MSDC0_DAT6"),
+		MTK_FUNCTION(4, "NLD6")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(113, "MSDC0_DAT5"),
+		"C4", "mt7623",
+		MTK_EINT_FUNCTION(0, 86),
+		MTK_FUNCTION(0, "GPIO113"),
+		MTK_FUNCTION(1, "MSDC0_DAT5"),
+		MTK_FUNCTION(4, "NLD5")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(114, "MSDC0_DAT4"),
+		"A4", "mt7623",
+		MTK_EINT_FUNCTION(0, 87),
+		MTK_FUNCTION(0, "GPIO114"),
+		MTK_FUNCTION(1, "MSDC0_DAT4"),
+		MTK_FUNCTION(4, "NLD4")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(115, "MSDC0_RSTB"),
+		"C5", "mt7623",
+		MTK_EINT_FUNCTION(0, 88),
+		MTK_FUNCTION(0, "GPIO115"),
+		MTK_FUNCTION(1, "MSDC0_RSTB"),
+		MTK_FUNCTION(4, "NLD8")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(116, "MSDC0_CMD"),
+		"D5", "mt7623",
+		MTK_EINT_FUNCTION(0, 89),
+		MTK_FUNCTION(0, "GPIO116"),
+		MTK_FUNCTION(1, "MSDC0_CMD"),
+		MTK_FUNCTION(4, "NALE")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(117, "MSDC0_CLK"),
+		"B1", "mt7623",
+		MTK_EINT_FUNCTION(0, 90),
+		MTK_FUNCTION(0, "GPIO117"),
+		MTK_FUNCTION(1, "MSDC0_CLK"),
+		MTK_FUNCTION(4, "NWEB")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(118, "MSDC0_DAT3"),
+		"D6", "mt7623",
+		MTK_EINT_FUNCTION(0, 91),
+		MTK_FUNCTION(0, "GPIO118"),
+		MTK_FUNCTION(1, "MSDC0_DAT3"),
+		MTK_FUNCTION(4, "NLD3")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(119, "MSDC0_DAT2"),
+		"B2", "mt7623",
+		MTK_EINT_FUNCTION(0, 92),
+		MTK_FUNCTION(0, "GPIO119"),
+		MTK_FUNCTION(1, "MSDC0_DAT2"),
+		MTK_FUNCTION(4, "NLD2")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(120, "MSDC0_DAT1"),
+		"A3", "mt7623",
+		MTK_EINT_FUNCTION(0, 93),
+		MTK_FUNCTION(0, "GPIO120"),
+		MTK_FUNCTION(1, "MSDC0_DAT1"),
+		MTK_FUNCTION(4, "NLD1")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(121, "MSDC0_DAT0"),
+		"B4", "mt7623",
+		MTK_EINT_FUNCTION(0, 94),
+		MTK_FUNCTION(0, "GPIO121"),
+		MTK_FUNCTION(1, "MSDC0_DAT0"),
+		MTK_FUNCTION(4, "NLD0"),
+		MTK_FUNCTION(5, "WATCHDOG")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(122, "GPIO122"),
+		"H17", "mt7623",
+		MTK_EINT_FUNCTION(0, 95),
+		MTK_FUNCTION(0, "GPIO122"),
+		MTK_FUNCTION(1, "TEST"),
+		MTK_FUNCTION(4, "SDA2"),
+		MTK_FUNCTION(5, "URXD0")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(123, "GPIO123"),
+		"F17", "mt7623",
+		MTK_EINT_FUNCTION(0, 96),
+		MTK_FUNCTION(0, "GPIO123"),
+		MTK_FUNCTION(1, "TEST"),
+		MTK_FUNCTION(4, "SCL2"),
+		MTK_FUNCTION(5, "UTXD0")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(124, "GPIO124"),
+		"H18", "mt7623",
+		MTK_EINT_FUNCTION(0, 97),
+		MTK_FUNCTION(0, "GPIO124"),
+		MTK_FUNCTION(1, "TEST"),
+		MTK_FUNCTION(4, "SDA1"),
+		MTK_FUNCTION(5, "PWM3")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(125, "GPIO125"),
+		"G17", "mt7623",
+		MTK_EINT_FUNCTION(0, 98),
+		MTK_FUNCTION(0, "GPIO125"),
+		MTK_FUNCTION(1, "TEST"),
+		MTK_FUNCTION(4, "SCL1"),
+		MTK_FUNCTION(5, "PWM4")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(126, "I2S0_MCLK"),
+		"AA19", "mt7623",
+		MTK_EINT_FUNCTION(0, 99),
+		MTK_FUNCTION(0, "GPIO126"),
+		MTK_FUNCTION(1, "I2S0_MCLK"),
+		MTK_FUNCTION(6, "AP_I2S_MCLK")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(127, "GPIO127"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO127")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(128, "GPIO128"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO128")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(129, "GPIO129"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO129")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(130, "GPIO130"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO130")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(131, "GPIO131"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO131")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(132, "GPIO132"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO132")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(133, "GPIO133"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO133")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(134, "GPIO134"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO134")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(135, "GPIO135"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO135")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(136, "GPIO136"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO136")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(137, "GPIO137"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO137")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(138, "GPIO138"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO138")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(139, "GPIO139"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO139")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(140, "GPIO140"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO140")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(141, "GPIO141"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO141")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(142, "GPIO142"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO142")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(143, "GPIO143"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO143")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(144, "GPIO144"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO144")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(145, "GPIO145"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO145")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(146, "GPIO146"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO146")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(147, "GPIO147"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO147")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(148, "GPIO148"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO148")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(149, "GPIO149"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO149")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(150, "GPIO150"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO150")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(151, "GPIO151"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO151")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(152, "GPIO152"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO152")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(153, "GPIO153"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO153")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(154, "GPIO154"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO154")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(155, "GPIO155"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO155")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(156, "GPIO156"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO156")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(157, "GPIO157"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO157")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(158, "GPIO158"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO158")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(159, "GPIO159"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO159")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(160, "GPIO160"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO160")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(161, "GPIO161"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO161")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(162, "GPIO162"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO162")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(163, "GPIO163"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO163")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(164, "GPIO164"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO164")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(165, "GPIO165"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO165")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(166, "GPIO166"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO166")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(167, "GPIO167"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO167")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(168, "GPIO168"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO168")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(169, "GPIO169"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO169")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(170, "GPIO170"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO170")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(171, "GPIO171"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO171")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(172, "GPIO172"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO172")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(173, "GPIO173"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO173")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(174, "GPIO174"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO174")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(175, "GPIO175"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO175")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(176, "GPIO176"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO176")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(177, "GPIO177"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO177")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(178, "GPIO178"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO178")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(179, "GPIO179"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO179")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(180, "GPIO180"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO180")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(181, "GPIO181"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO181")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(182, "GPIO182"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO182")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(183, "GPIO183"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO183")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(184, "GPIO184"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO184")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(185, "GPIO185"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO185")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(186, "GPIO186"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO186")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(187, "GPIO187"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO187")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(188, "GPIO188"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO188")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(189, "GPIO189"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO189")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(190, "GPIO190"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO190")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(191, "GPIO191"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO191")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(192, "GPIO192"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO192")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(193, "GPIO193"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO193")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(194, "GPIO194"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO194")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(195, "GPIO195"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO195")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(196, "GPIO196"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO196")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(197, "GPIO197"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO197")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(198, "GPIO198"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO198")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(199, "SPI1_CK"),
+		"E19", "mt7623",
+		MTK_EINT_FUNCTION(0, 111),
+		MTK_FUNCTION(0, "GPIO199"),
+		MTK_FUNCTION(1, "SPI1_CK")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(200, "URXD2"),
+		"K18", "mt7623",
+		MTK_EINT_FUNCTION(0, 112),
+		MTK_FUNCTION(0, "GPIO200"),
+		MTK_FUNCTION(6, "URXD2")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(201, "UTXD2"),
+		"L18", "mt7623",
+		MTK_EINT_FUNCTION(0, 113),
+		MTK_FUNCTION(0, "GPIO201"),
+		MTK_FUNCTION(6, "UTXD2")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(202, "GPIO202"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO202")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(203, "PWM0"),
+		"AA16", "mt7623",
+		MTK_EINT_FUNCTION(0, 115),
+		MTK_FUNCTION(0, "GPIO203"),
+		MTK_FUNCTION(1, "PWM0"),
+		MTK_FUNCTION(2, "DISP_PWM")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(204, "PWM1"),
+		"Y16", "mt7623",
+		MTK_EINT_FUNCTION(0, 116),
+		MTK_FUNCTION(0, "GPIO204"),
+		MTK_FUNCTION(1, "PWM1")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(205, "PWM2"),
+		"AA15", "mt7623",
+		MTK_EINT_FUNCTION(0, 117),
+		MTK_FUNCTION(0, "GPIO205"),
+		MTK_FUNCTION(1, "PWM2")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(206, "PWM3"),
+		"AA17", "mt7623",
+		MTK_EINT_FUNCTION(0, 118),
+		MTK_FUNCTION(0, "GPIO206"),
+		MTK_FUNCTION(1, "PWM3")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(207, "PWM4"),
+		"Y15", "mt7623",
+		MTK_EINT_FUNCTION(0, 119),
+		MTK_FUNCTION(0, "GPIO207"),
+		MTK_FUNCTION(1, "PWM4")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(208, "AUD_EXT_CK1"),
+		"W14", "mt7623",
+		MTK_EINT_FUNCTION(0, 120),
+		MTK_FUNCTION(0, "GPIO208"),
+		MTK_FUNCTION(1, "AUD_EXT_CK1"),
+		MTK_FUNCTION(2, "PWM0"),
+		MTK_FUNCTION(3, "PCIE0_PERST_N"),
+		MTK_FUNCTION(5, "DISP_PWM")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(209, "AUD_EXT_CK2"),
+		"V15", "mt7623",
+		MTK_EINT_FUNCTION(0, 121),
+		MTK_FUNCTION(0, "GPIO209"),
+		MTK_FUNCTION(1, "AUD_EXT_CK2"),
+		MTK_FUNCTION(2, "MSDC1_WP"),
+		MTK_FUNCTION(3, "PCIE1_PERST_N"),
+		MTK_FUNCTION(5, "PWM1")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(210, "GPIO210"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO210")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(211, "GPIO211"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO211")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(212, "GPIO212"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO212")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(213, "GPIO213"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO213")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(214, "GPIO214"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO214")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(215, "GPIO215"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO215")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(216, "GPIO216"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO216")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(217, "GPIO217"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO217")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(218, "GPIO218"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO218")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(219, "GPIO219"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO219")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(220, "GPIO220"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO220")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(221, "GPIO221"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO221")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(222, "GPIO222"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO222")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(223, "GPIO223"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO223")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(224, "GPIO224"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO224")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(225, "GPIO225"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO225")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(226, "GPIO226"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO226")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(227, "GPIO227"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO227")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(228, "GPIO228"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO228")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(229, "GPIO229"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO229")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(230, "GPIO230"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO230")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(231, "GPIO231"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO231")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(232, "GPIO232"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO232")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(233, "GPIO233"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO233")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(234, "GPIO234"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO234")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(235, "GPIO235"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO235")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(236, "EXT_SDIO3"),
+		"A8", "mt7623",
+		MTK_EINT_FUNCTION(0, 122),
+		MTK_FUNCTION(0, "GPIO236"),
+		MTK_FUNCTION(1, "EXT_SDIO3"),
+		MTK_FUNCTION(2, "IDDIG")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(237, "EXT_SDIO2"),
+		"D8", "mt7623",
+		MTK_EINT_FUNCTION(0, 123),
+		MTK_FUNCTION(0, "GPIO237"),
+		MTK_FUNCTION(1, "EXT_SDIO2"),
+		MTK_FUNCTION(2, "DRV_VBUS")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(238, "EXT_SDIO1"),
+		"D9", "mt7623",
+		MTK_EINT_FUNCTION(0, 124),
+		MTK_FUNCTION(0, "GPIO238"),
+		MTK_FUNCTION(1, "EXT_SDIO1")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(239, "EXT_SDIO0"),
+		"B8", "mt7623",
+		MTK_EINT_FUNCTION(0, 125),
+		MTK_FUNCTION(0, "GPIO239"),
+		MTK_FUNCTION(1, "EXT_SDIO0")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(240, "EXT_XCS"),
+		"C9", "mt7623",
+		MTK_EINT_FUNCTION(0, 126),
+		MTK_FUNCTION(0, "GPIO240"),
+		MTK_FUNCTION(1, "EXT_XCS")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(241, "EXT_SCK"),
+		"C8", "mt7623",
+		MTK_EINT_FUNCTION(0, 127),
+		MTK_FUNCTION(0, "GPIO241"),
+		MTK_FUNCTION(1, "EXT_SCK")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(242, "URTS2"),
+		"G18", "mt7623",
+		MTK_EINT_FUNCTION(0, 128),
+		MTK_FUNCTION(0, "GPIO242"),
+		MTK_FUNCTION(1, "URTS2"),
+		MTK_FUNCTION(2, "UTXD3"),
+		MTK_FUNCTION(3, "URXD3"),
+		MTK_FUNCTION(4, "SCL1")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(243, "UCTS2"),
+		"H19", "mt7623",
+		MTK_EINT_FUNCTION(0, 129),
+		MTK_FUNCTION(0, "GPIO243"),
+		MTK_FUNCTION(1, "UCTS2"),
+		MTK_FUNCTION(2, "URXD3"),
+		MTK_FUNCTION(3, "UTXD3"),
+		MTK_FUNCTION(4, "SDA1")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(244, "GPIO244"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO244")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(245, "GPIO245"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO245")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(246, "GPIO246"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO246")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(247, "GPIO247"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO247")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(248, "GPIO248"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO248")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(249, "GPIO249"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO249")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(250, "GPIO250"),
+		"A15", "mt7623",
+		MTK_EINT_FUNCTION(0, 135),
+		MTK_FUNCTION(0, "GPIO250"),
+		MTK_FUNCTION(1, "TEST_MD7"),
+		MTK_FUNCTION(6, "PCIE0_CLKREQ_N")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(251, "GPIO251"),
+		"B15", "mt7623",
+		MTK_EINT_FUNCTION(0, 136),
+		MTK_FUNCTION(0, "GPIO251"),
+		MTK_FUNCTION(1, "TEST_MD6"),
+		MTK_FUNCTION(6, "PCIE0_WAKE_N")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(252, "GPIO252"),
+		"C16", "mt7623",
+		MTK_EINT_FUNCTION(0, 137),
+		MTK_FUNCTION(0, "GPIO252"),
+		MTK_FUNCTION(1, "TEST_MD5"),
+		MTK_FUNCTION(6, "PCIE1_CLKREQ_N")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(253, "GPIO253"),
+		"D17", "mt7623",
+		MTK_EINT_FUNCTION(0, 138),
+		MTK_FUNCTION(0, "GPIO253"),
+		MTK_FUNCTION(1, "TEST_MD4"),
+		MTK_FUNCTION(6, "PCIE1_WAKE_N")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(254, "GPIO254"),
+		"D16", "mt7623",
+		MTK_EINT_FUNCTION(0, 139),
+		MTK_FUNCTION(0, "GPIO254"),
+		MTK_FUNCTION(1, "TEST_MD3"),
+		MTK_FUNCTION(6, "PCIE2_CLKREQ_N")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(255, "GPIO255"),
+		"C17", "mt7623",
+		MTK_EINT_FUNCTION(0, 140),
+		MTK_FUNCTION(0, "GPIO255"),
+		MTK_FUNCTION(1, "TEST_MD2"),
+		MTK_FUNCTION(6, "PCIE2_WAKE_N")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(256, "GPIO256"),
+		"B17", "mt7623",
+		MTK_EINT_FUNCTION(0, 141),
+		MTK_FUNCTION(0, "GPIO256"),
+		MTK_FUNCTION(1, "TEST_MD1")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(257, "GPIO257"),
+		"C15", "mt7623",
+		MTK_EINT_FUNCTION(0, 142),
+		MTK_FUNCTION(0, "GPIO257"),
+		MTK_FUNCTION(1, "TEST_MD0")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(258, "GPIO258"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO258")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(259, "GPIO259"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO259")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(260, "GPIO260"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO260")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(261, "MSDC1_INS"),
+		"AD1", "mt7623",
+		MTK_EINT_FUNCTION(0, 146),
+		MTK_FUNCTION(0, "GPIO261"),
+		MTK_FUNCTION(1, "MSDC1_INS")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(262, "G2_TXEN"),
+		"A23", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO262"),
+		MTK_FUNCTION(1, "G2_TXEN")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(263, "G2_TXD3"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO263"),
+		MTK_FUNCTION(1, "G2_TXD3")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(264, "G2_TXD2"),
+		"C24", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO264"),
+		MTK_FUNCTION(1, "G2_TXD2")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(265, "G2_TXD1"),
+		"B25", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO265"),
+		MTK_FUNCTION(1, "G2_TXD1")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(266, "G2_TXD0"),
+		"A24", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO266"),
+		MTK_FUNCTION(1, "G2_TXD0")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(267, "G2_TXCLK"),
+		"C23", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO267"),
+		MTK_FUNCTION(1, "G2_TXC")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(268, "G2_RXCLK"),
+		"B23", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO268"),
+		MTK_FUNCTION(1, "G2_RXC")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(269, "G2_RXD0"),
+		"D21", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO269"),
+		MTK_FUNCTION(1, "G2_RXD0")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(270, "G2_RXD1"),
+		"B22", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO270"),
+		MTK_FUNCTION(1, "G2_RXD1")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(271, "G2_RXD2"),
+		"A22", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO271"),
+		MTK_FUNCTION(1, "G2_RXD2")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(272, "G2_RXD3"),
+		"C22", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO272"),
+		MTK_FUNCTION(1, "G2_RXD3")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(273, "GPIO273"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO273")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(274, "G2_RXDV"),
+		"C21", "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO274"),
+		MTK_FUNCTION(1, "G2_RXDV")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(275, "G2_MDC"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO275"),
+		MTK_FUNCTION(1, "MDC")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(276, "G2_MDIO"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO276"),
+		MTK_FUNCTION(1, "MDIO")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(277, "GPIO277"),
+		NULL, "mt7623",
+		MTK_EINT_FUNCTION(NO_EINT_SUPPORT, NO_EINT_SUPPORT),
+		MTK_FUNCTION(0, "GPIO277")
+	),
+	MTK_PIN(
+		PINCTRL_PIN(278, "JTAG_RESET"),
+		"H20", "mt7623",
+		MTK_EINT_FUNCTION(0, 147),
+		MTK_FUNCTION(0, "GPIO278"),
+		MTK_FUNCTION(1, "JTAG_RESET")
+	),
+};
+
+#endif /* __PINCTRL_MTK_MT7623_H */
-- 
1.7.10.4



From s.hauer at pengutronix.de  Thu Feb 18 23:20:00 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 19 Feb 2016 08:20:00 +0100
Subject: [PATCH 3/3] ARM64: dts: mt8173: Add thermal/auxadc device nodes
In-Reply-To: <56C5EEE9.4020407@gmail.com>
References: <1448883753-19068-1-git-send-email-s.hauer@pengutronix.de>
 <1448883753-19068-4-git-send-email-s.hauer@pengutronix.de>
 <56C5EEE9.4020407@gmail.com>
Message-ID: <20160219071959.GL3939@pengutronix.de>

Hi Matthias,

On Thu, Feb 18, 2016 at 05:18:49PM +0100, Matthias Brugger wrote:
> Hi Sascha,
> 
> On 30/11/15 12:42, Sascha Hauer wrote:
> >This adds the thermal controller and auxadc nodes to the Mediatek MT8173
> >dtsi file.
> >
> >Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
> >Reviewed-by: Daniel Kurtz <djkurtz at chromium.org>
> >---
> >  arch/arm64/boot/dts/mediatek/mt8173.dtsi | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> >
> >diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >index 06a1564..e2ddd03 100644
> >--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >@@ -277,6 +277,11 @@
> >  				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> >  		};
> >
> >+		auxadc: auxadc at 11001000 {
> >+			compatible = "mediatek,mt8173-auxadc";
> 
> Can you please write a small Documentation about the binding.
> I suppose it will be mediatek,auxadc and mediatek,mt8173-auxadc.

Just did that.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From s.hauer at pengutronix.de  Thu Feb 18 23:21:32 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 19 Feb 2016 08:21:32 +0100
Subject: [PATCH 2/3] thermal: Add Mediatek thermal controller support
In-Reply-To: <20160218151552.GA1852@localhost.localdomain>
References: <1448883753-19068-3-git-send-email-s.hauer@pengutronix.de>
 <20151217193332.GB7999@localhost.localdomain>
 <20160104141940.GI13058@pengutronix.de>
 <20160119072917.GA13237@pengutronix.de>
 <1454295246.22151.6.camel@mtksdaap41>
 <CAGS+omD9U8tKmb02d_gMMAGX18MJZhz0RrugpBK2EuqgZrBy6g@mail.gmail.com>
 <CAGS+omArr0_-ziBXWjEcKS0bqnruNzZc2aq2s3zkghUC7_HfGw@mail.gmail.com>
 <56C4A875.6080908@gmail.com> <20160218105603.GE3939@pengutronix.de>
 <20160218151552.GA1852@localhost.localdomain>
Message-ID: <20160219072132.GM3939@pengutronix.de>

On Thu, Feb 18, 2016 at 07:15:54AM -0800, Eduardo Valentin wrote:
> Folks,
> 
> > > I think the problem is, that Eduardo wants to see the hierachical thermal
> > > zones being used. But there is still a discussion ongoing [1].
> > 
> > It seems the original Author lost interest in the hierarchical thermal
> > zones. I am not convinced that we need hierarchical thermal zones for
> > the Mediatek driver since from the five sensors we only need the maximum
> > temperature (If this ever changes we could still rework it).
> > 
> > Given the current speed of communication I am not willing to add
> > another, possibly controversal, dependency to an otherwise simple
> > driver. I am even less willing when concerns like these come after *v12*
> > of this series.
> > 
> > Eduardo, it would really help to get a word from you.
> 
> Apologize for the long delays here. In fact I want the hierarchical
> support on this driver. But given that it is not really a strong
> dependency and the hierarchical support is still an ongoing development,
> I don't see why we should not merge this driver.
> 
> I also have had the chance to try it out in a board, and seams to work
> for me. I am adding to my tree.

Thanks for applying :)

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From paul at pwsan.com  Thu Feb 18 23:21:36 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Fri, 19 Feb 2016 07:21:36 +0000 (UTC)
Subject: [PATCH v2 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod
In-Reply-To: <1455856735-11515-3-git-send-email-j-keerthy@ti.com>
References: <1455856735-11515-1-git-send-email-j-keerthy@ti.com>
 <1455856735-11515-3-git-send-email-j-keerthy@ti.com>
Message-ID: <alpine.DEB.2.02.1602190720490.27696@utopia.booyaka.com>

On Fri, 19 Feb 2016, Keerthy wrote:

> The patch adds rtc hwmod. RTC module The RTC module is physically
> present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently
> disabled. A secure RTC is used instead on these devices, where needed.
> . Hence adding it selectively using a seprate list to get RTC Module
> functional on the other am43x SoCs used on am437x-gp-evm and
> am437x-sk-evm.
> 
> Signed-off-by: Keerthy <j-keerthy at ti.com>
> ---
> 
> Changes in v2:
> 
> Inverted the checking logic to accommodate registering for all
> the SoCs compatible to am4372 and removed the negating am438x logic
> to register rtc hwmods as suggested by Paul.
> 
>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)

OK thanks; I've queued the following patch for v4.6 or if I get unlucky, 
v4.7.

- Paul

From: Keerthy <j-keerthy at ti.com>
Date: Fri, 19 Feb 2016 10:08:55 +0530
Subject: [PATCH] ARM: AM43XX: hwmod: Add rtc hwmod

The patch registers the rtc hwmod on AM437x chips.  The RTC module is
physically present on the AM438x SoC used on AM43X-EPOS-EVM, but it is
permanently disabled. A secure RTC is used instead on these devices,
where needed. Hence adding it selectively using a separate list to get
RTC Module functional on the other am43x SoCs used on am437x-gp-evm
and am437x-sk-evm.

Signed-off-by: Keerthy <j-keerthy at ti.com>
[paul at pwsan.com: cleaned up patch description]
Signed-off-by: Paul Walmsley <paul at pwsan.com>
---
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index e97a894b5f88..97fd399202dc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -1020,9 +1020,21 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
 	NULL,
 };
 
+static struct omap_hwmod_ocp_if *am43xx_rtc_hwmod_ocp_ifs[] __initdata = {
+	&am33xx_l4_wkup__rtc,
+	NULL,
+};
+
 int __init am43xx_hwmod_init(void)
 {
+	int ret;
+
 	omap_hwmod_am43xx_reg();
 	omap_hwmod_init();
-	return omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+	ret = omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+
+	if (!ret && of_machine_is_compatible("ti,am4372"))
+		ret = omap_hwmod_register_links(am43xx_rtc_hwmod_ocp_ifs);
+
+	return ret;
 }
-- 
2.7.0



From wei at redhat.com  Thu Feb 18 23:24:08 2016
From: wei at redhat.com (Wei Huang)
Date: Fri, 19 Feb 2016 01:24:08 -0600
Subject: [PATCH v2 1/6] KVM: arm/arm64: arch_timer: Gather KVM specific
 information in a structure
In-Reply-To: <1455204804-31830-2-git-send-email-julien.grall@arm.com>
References: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
 <1455204804-31830-2-git-send-email-julien.grall@arm.com>
Message-ID: <56C6C318.3000205@redhat.com>



On 02/11/2016 09:33 AM, Julien Grall wrote:
> Introduce a structure which are filled up by the arch timer driver and
> used by the virtual timer in KVM.
> 
> The first member of this structure will be the timecounter. More members
> will be added later.
> 
> This is also dropping arch_timer_get_timecounter as it was only used by
> the KVM code. Furthermore, a stub for the new helper hasn't been
> introduced because KVM is requiring the arch timer for both ARM64 and
> ARM32.
> 
> Signed-off-by: Julien Grall <julien.grall at arm.com>
> 
> ---
> Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Christoffer Dall <christoffer.dall at linaro.org>
> Cc: Marc Zyngier <marc.zyngier at arm.com>
> Cc: Gleb Natapov <gleb at kernel.org>
> Cc: Paolo Bonzini <pbonzini at redhat.com>
> ---
>  drivers/clocksource/arm_arch_timer.c |  9 +++++----
>  include/clocksource/arm_arch_timer.h | 12 ++++++------
>  virt/kvm/arm/arch_timer.c            |  6 +++---
>  3 files changed, 14 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index c64d543..6eb2c5d 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -447,11 +447,11 @@ static struct cyclecounter cyclecounter = {
>  	.mask	= CLOCKSOURCE_MASK(56),
>  };
>  
> -static struct timecounter timecounter;
> +static struct arch_timer_kvm_info arch_timer_kvm_info;
>  
> -struct timecounter *arch_timer_get_timecounter(void)
> +struct arch_timer_kvm_info *arch_timer_get_kvm_info(void)
>  {
> -	return &timecounter;
> +	return &arch_timer_kvm_info;
>  }
>  
>  static void __init arch_counter_register(unsigned type)
> @@ -479,7 +479,8 @@ static void __init arch_counter_register(unsigned type)
>  	clocksource_register_hz(&clocksource_counter, arch_timer_rate);
>  	cyclecounter.mult = clocksource_counter.mult;
>  	cyclecounter.shift = clocksource_counter.shift;
> -	timecounter_init(&timecounter, &cyclecounter, start_count);
> +	timecounter_init(&arch_timer_kvm_info.timecounter,
> +			 &cyclecounter, start_count);
>  
>  	/* 56 bits minimum, so we assume worst case rollover */
>  	sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate);
> diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
> index 25d0914..4d487f8 100644
> --- a/include/clocksource/arm_arch_timer.h
> +++ b/include/clocksource/arm_arch_timer.h
> @@ -49,11 +49,16 @@ enum arch_timer_reg {
>  
>  #define ARCH_TIMER_EVT_STREAM_FREQ	10000	/* 100us */
>  
> +struct arch_timer_kvm_info {
> +	struct timecounter timecounter;
> +};
> +
>  #ifdef CONFIG_ARM_ARCH_TIMER
>  
>  extern u32 arch_timer_get_rate(void);
>  extern u64 (*arch_timer_read_counter)(void);
> -extern struct timecounter *arch_timer_get_timecounter(void);
> +
> +extern struct arch_timer_kvm_info *arch_timer_get_kvm_info(void);
>  
>  #else
>  
> @@ -67,11 +72,6 @@ static inline u64 arch_timer_read_counter(void)
>  	return 0;
>  }
>  
> -static inline struct timecounter *arch_timer_get_timecounter(void)
> -{
> -	return NULL;
> -}
> -

Most parts are OK. Regarding removing this function from the #else area,
is there a possibility to have CONFIG_ARM_ARCH_TIMER=n and CONFIG_KVM=y.
If so, will the compilation fails here?

-Wei

>  #endif
>  
>  #endif
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 69bca18..a669c6a 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -385,11 +385,11 @@ int kvm_timer_hyp_init(void)
>  {
>  	struct device_node *np;
>  	unsigned int ppi;
> +	struct arch_timer_kvm_info *info;
>  	int err;
>  
> -	timecounter = arch_timer_get_timecounter();
> -	if (!timecounter)
> -		return -ENODEV;
> +	info = arch_timer_get_kvm_info();
> +	timecounter = &info->timecounter;
>  
>  	np = of_find_matching_node(NULL, arch_timer_of_match);
>  	if (!np) {
> 


From s.hauer at pengutronix.de  Thu Feb 18 23:43:01 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 19 Feb 2016 08:43:01 +0100
Subject: [PATCH 01/12] spi: imx: allow only WML aligned transfers to use DMA
In-Reply-To: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
References: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455867792-26389-2-git-send-email-s.hauer@pengutronix.de>

From: Anton Bondarenko <anton.bondarenko.sama at gmail.com>

RX DMA tail data handling doesn't work correctly in many cases with current
implementation. It happens because SPI core was setup to generates both RX
and RX TAIL events. And RX TAIL event does not work correctly.
This can be easily verified by sending SPI transaction with size modulus
WML(32 in our case) not equal 0.

Also this removes the change introduced in f6ee9b582 (spi: imx: Fix small
DMA transfers) since this only fixes usecases with transfer size from 33 to
128 bytes and doesn't fix 129 bytes and bigger.

This is output from transaction with len 138 bytes in loopback mode at 10Mhz:
TX0000: a3 97 a2 55 53 be f1 fc f9 79 6b 52 14 13 e9 e2
TX0010: 2d 51 8e 1f 56 08 57 27 a7 05 d4 d0 52 82 77 75
TX0020: 1b 99 4a ed 58 3d 6a 52 36 d5 24 4a 68 8e ad 95
TX0030: 5f 3c 35 b5 c4 8c dd 6c 11 32 3d e2 b4 b4 59 cf
TX0040: ce 23 3d 27 df a7 f9 96 fc 1e e0 66 2c 0e 7b 8c
TX0050: ca 30 42 8f bc 9f 7b ce d1 b8 b1 87 ec 8a d6 bb
TX0060: 2e 15 63 0e 3c dc a4 3a 7a 06 20 a7 93 1b 34 dd
TX0070: 4c f5 ec 88 96 68 d6 68 a0 09 6f 8e 93 47 c9 41
TX0080: db ac cf 97 89 f3 51 05 79 71

RX0000: a3 97 a2 55 53 be f1 fc f9 79 6b 52 14 13 e9 e2
RX0010: 2d 51 8e 1f 56 08 57 27 a7 05 d4 d0 52 82 77 75
RX0020: 1b 99 4a ed 58 3d 6a 52 36 d5 24 4a 68 8e ad 95
RX0030: 5f 3c 35 00 00 b5 00 00 00 c4 00 00 8c 00 00 dd
RX0040: 6c 11 32 3d e2 b4 b4 59 cf ce 23 3d 27 df a7 f9
RX0050: 96 fc 1e e0 66 2c 0e 7b 8c ca 30 42 8f 1f 1f bc
RX0060: 9f 7b ce d1 b8 b1 87 ec 8a d6 bb 2e 15 63 0e ed
RX0070: ed 3c 58 58 58 dc 3d 3d a4 6a 6a 3a 52 52 7a 36
RX0080: 06 20 a7 93 1b 34 dd 4c f5 ec

Zeros at offset 33 and 34 caused by reading empty RX FIFO which not possible
if DMA RX read was triggered by RX event. This mean DMA was triggered
by RX TAIL event.

Signed-off-by: Anton Bondarenko <anton.bondarenko.sama at gmail.com>
Signed-off--by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 17 ++---------------
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index d98c33c..08492d6 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -204,8 +204,8 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
 
-	if (spi_imx->dma_is_inited &&
-	    transfer->len > spi_imx->wml * sizeof(u32))
+	if (spi_imx->dma_is_inited && transfer->len >= spi_imx->wml &&
+	    (transfer->len % spi_imx->wml) == 0)
 		return true;
 	return false;
 }
@@ -919,8 +919,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
 	int ret;
 	unsigned long timeout;
-	u32 dma;
-	int left;
 	struct spi_master *master = spi_imx->bitbang.master;
 	struct sg_table *tx = &transfer->tx_sg, *rx = &transfer->rx_sg;
 
@@ -954,13 +952,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	/* Trigger the cspi module. */
 	spi_imx->dma_finished = 0;
 
-	dma = readl(spi_imx->base + MX51_ECSPI_DMA);
-	dma = dma & (~MX51_ECSPI_DMA_RXT_WML_MASK);
-	/* Change RX_DMA_LENGTH trigger dma fetch tail data */
-	left = transfer->len % spi_imx->wml;
-	if (left)
-		writel(dma | (left << MX51_ECSPI_DMA_RXT_WML_OFFSET),
-				spi_imx->base + MX51_ECSPI_DMA);
 	/*
 	 * Set these order to avoid potential RX overflow. The overflow may
 	 * happen if we enable SPI HW before starting RX DMA due to rescheduling
@@ -992,10 +983,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 			spi_imx->devtype_data->reset(spi_imx);
 			dmaengine_terminate_all(master->dma_rx);
 		}
-		dma &= ~MX51_ECSPI_DMA_RXT_WML_MASK;
-		writel(dma |
-		       spi_imx->wml << MX51_ECSPI_DMA_RXT_WML_OFFSET,
-		       spi_imx->base + MX51_ECSPI_DMA);
 	}
 
 	spi_imx->dma_finished = 1;
-- 
2.7.0



From s.hauer at pengutronix.de  Thu Feb 18 23:43:02 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 19 Feb 2016 08:43:02 +0100
Subject: [PATCH 02/12] spi: imx: use proper dev_* functions for driver messages
In-Reply-To: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
References: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455867792-26389-3-git-send-email-s.hauer@pengutronix.de>

Add a struct device * member to the private driver data and use
it to print messages using dev_* functions rather than pr_*.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 27 ++++++++++++---------------
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 08492d6..7904d45 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -86,6 +86,7 @@ struct spi_imx_devtype_data {
 
 struct spi_imx_data {
 	struct spi_bitbang bitbang;
+	struct device *dev;
 
 	struct completion xfer_done;
 	void __iomem *base;
@@ -250,14 +251,15 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 #define MX51_ECSPI_TESTREG_LBC	BIT(31)
 
 /* MX51 eCSPI */
-static unsigned int mx51_ecspi_clkdiv(unsigned int fin, unsigned int fspi,
-				      unsigned int *fres)
+static unsigned int mx51_ecspi_clkdiv(struct spi_imx_data *spi_imx,
+				      unsigned int fspi, unsigned int *fres)
 {
 	/*
 	 * there are two 4-bit dividers, the pre-divider divides by
 	 * $pre, the post-divider by 2^$post
 	 */
 	unsigned int pre, post;
+	unsigned int fin = spi_imx->spi_clk;
 
 	if (unlikely(fspi > fin))
 		return 0;
@@ -270,14 +272,14 @@ static unsigned int mx51_ecspi_clkdiv(unsigned int fin, unsigned int fspi,
 
 	post = max(4U, post) - 4;
 	if (unlikely(post > 0xf)) {
-		pr_err("%s: cannot set clock freq: %u (base freq: %u)\n",
-				__func__, fspi, fin);
+		dev_err(spi_imx->dev, "cannot set clock freq: %u (base freq: %u)\n",
+				fspi, fin);
 		return 0xff;
 	}
 
 	pre = DIV_ROUND_UP(fin, fspi << post) - 1;
 
-	pr_debug("%s: fin: %u, fspi: %u, post: %u, pre: %u\n",
+	dev_dbg(spi_imx->dev, "%s: fin: %u, fspi: %u, post: %u, pre: %u\n",
 			__func__, fin, fspi, post, pre);
 
 	/* Resulting frequency for the SCLK line. */
@@ -330,7 +332,7 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 	ctrl |= MX51_ECSPI_CTRL_MODE_MASK;
 
 	/* set clock speed */
-	ctrl |= mx51_ecspi_clkdiv(spi_imx->spi_clk, config->speed_hz, &clk);
+	ctrl |= mx51_ecspi_clkdiv(spi_imx, config->speed_hz, &clk);
 
 	/* set chip select to use */
 	ctrl |= MX51_ECSPI_CTRL_CS(config->cs);
@@ -968,18 +970,14 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	timeout = wait_for_completion_timeout(&spi_imx->dma_tx_completion,
 						IMX_DMA_TIMEOUT);
 	if (!timeout) {
-		pr_warn("%s %s: I/O Error in DMA TX\n",
-			dev_driver_string(&master->dev),
-			dev_name(&master->dev));
+		dev_err(spi_imx->dev, "I/O Error in DMA TX\n");
 		dmaengine_terminate_all(master->dma_tx);
 		dmaengine_terminate_all(master->dma_rx);
 	} else {
 		timeout = wait_for_completion_timeout(
 				&spi_imx->dma_rx_completion, IMX_DMA_TIMEOUT);
 		if (!timeout) {
-			pr_warn("%s %s: I/O Error in DMA RX\n",
-				dev_driver_string(&master->dev),
-				dev_name(&master->dev));
+			dev_err(spi_imx->dev, "I/O Error in DMA RX\n");
 			spi_imx->devtype_data->reset(spi_imx);
 			dmaengine_terminate_all(master->dma_rx);
 		}
@@ -996,9 +994,7 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	return ret;
 
 no_dma:
-	pr_warn_once("%s %s: DMA not available, falling back to PIO\n",
-		     dev_driver_string(&master->dev),
-		     dev_name(&master->dev));
+	dev_warn_once(spi_imx->dev, "DMA not available, falling back to PIO\n");
 	return -EAGAIN;
 }
 
@@ -1128,6 +1124,7 @@ static int spi_imx_probe(struct platform_device *pdev)
 
 	spi_imx = spi_master_get_devdata(master);
 	spi_imx->bitbang.master = master;
+	spi_imx->dev = &pdev->dev;
 
 	spi_imx->devtype_data = of_id ? of_id->data :
 		(struct spi_imx_devtype_data *)pdev->id_entry->driver_data;
-- 
2.7.0



From s.hauer at pengutronix.de  Thu Feb 18 23:43:09 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 19 Feb 2016 08:43:09 +0100
Subject: [PATCH 09/12] spi: imx: remove unnecessary bit clearing in
 mx51_ecspi_config
In-Reply-To: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
References: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455867792-26389-10-git-send-email-s.hauer@pengutronix.de>

This reverts patch 1476253cef (spi: imx: fix ecspi mode setup)
The patch tried to fix something by clearing bits in the cfg variable,
but cfg is initialized to zero on function entry. There are no bits to
clear.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 6a0e004..2476de7 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -366,20 +366,13 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 
 	if (config->mode & SPI_CPHA)
 		cfg |= MX51_ECSPI_CONFIG_SCLKPHA(config->cs);
-	else
-		cfg &= ~MX51_ECSPI_CONFIG_SCLKPHA(config->cs);
 
 	if (config->mode & SPI_CPOL) {
 		cfg |= MX51_ECSPI_CONFIG_SCLKPOL(config->cs);
 		cfg |= MX51_ECSPI_CONFIG_SCLKCTL(config->cs);
-	} else {
-		cfg &= ~MX51_ECSPI_CONFIG_SCLKPOL(config->cs);
-		cfg &= ~MX51_ECSPI_CONFIG_SCLKCTL(config->cs);
 	}
 	if (config->mode & SPI_CS_HIGH)
 		cfg |= MX51_ECSPI_CONFIG_SSBPOL(config->cs);
-	else
-		cfg &= ~MX51_ECSPI_CONFIG_SSBPOL(config->cs);
 
 	/* CTRL register always go first to bring out controller from reset */
 	writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
-- 
2.7.0



From s.hauer at pengutronix.de  Thu Feb 18 23:43:00 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 19 Feb 2016 08:43:00 +0100
Subject: [PATCH v2] i.MX SPI DMA cleanup
Message-ID: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>

Second round for the i.MX SPI DMA patches. No changes to code, only
updated commit messages.

Mark, you already applied patch 1/12 and 2/12. I'm resending them here
anyway because I updated the commit message as you requested. Feel free
to ignore 1/12 and 2/12 or replace them with this updated version.

Changes since v1:

- Add missing Signed-off-by to Patch 3
- Drop device tree change as it's already applied by Shawn
- Add patch subject when referring to commits

----------------------------------------------------------------
Anton Bondarenko (3):
      spi: imx: allow only WML aligned transfers to use DMA
      spi: imx: replace fixed timeout with calculated
      spi: imx: add support for all SPI word width for DMA

Sascha Hauer (9):
      spi: imx: use proper dev_* functions for driver messages
      spi: imx: drop fallback to PIO
      spi: imx: initialize usedma earlier
      spi: imx: drop unnecessary read/modify/write
      spi: imx: drop unncessary dma_is_inited variable
      spi: imx: remove unnecessary bit clearing in mx51_ecspi_config
      spi: imx: make some register defines simpler
      spi: imx: set MX51_ECSPI_CTRL_SMC bit in setup function
      spi: imx: drop bogus tests for rx/tx bufs in DMA transfer

 drivers/spi/spi-imx.c | 350 ++++++++++++++++++++++++++------------------------
 1 file changed, 181 insertions(+), 169 deletions(-)


From s.hauer at pengutronix.de  Thu Feb 18 23:43:06 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 19 Feb 2016 08:43:06 +0100
Subject: [PATCH 06/12] spi: imx: drop unnecessary read/modify/write
In-Reply-To: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
References: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455867792-26389-7-git-send-email-s.hauer@pengutronix.de>

When the MX51_ECSPI_DMA is configured we control every single bit
of the register, so there's no need to read/modify/write it. Instead
just write the value we want to have in the register. Also, drop
unnecessary check if we are actually doing DMA. The values written
to the register have no effect in PIO mode and value written there
during the last DMA transfer is still in the register, so we can
equally well always write a value.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 31 ++++++++++---------------------
 1 file changed, 10 insertions(+), 21 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 7047453..073a134 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -240,9 +240,9 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 #define MX51_ECSPI_DMA_RXT_WML_OFFSET	24
 #define MX51_ECSPI_DMA_RXT_WML_MASK	(0x3F << 24)
 
-#define MX51_ECSPI_DMA_TEDEN_OFFSET	7
-#define MX51_ECSPI_DMA_RXDEN_OFFSET	23
-#define MX51_ECSPI_DMA_RXTDEN_OFFSET	31
+#define MX51_ECSPI_DMA_TEDEN		(1 << 7)
+#define MX51_ECSPI_DMA_RXDEN		(1 << 23)
+#define MX51_ECSPI_DMA_RXTDEN		(1 << 31)
 
 #define MX51_ECSPI_STAT		0x18
 #define MX51_ECSPI_STAT_RR		(1 <<  3)
@@ -318,8 +318,7 @@ static void __maybe_unused mx51_ecspi_trigger(struct spi_imx_data *spi_imx)
 static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 		struct spi_imx_config *config)
 {
-	u32 ctrl = MX51_ECSPI_CTRL_ENABLE, cfg = 0, dma = 0;
-	u32 tx_wml_cfg, rx_wml_cfg, rxt_wml_cfg;
+	u32 ctrl = MX51_ECSPI_CTRL_ENABLE, cfg = 0;
 	u32 clk = config->speed_hz, delay, reg;
 
 	/*
@@ -392,22 +391,12 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 	 * Configure the DMA register: setup the watermark
 	 * and enable DMA request.
 	 */
-	if (spi_imx->dma_is_inited) {
-		dma = readl(spi_imx->base + MX51_ECSPI_DMA);
-
-		rx_wml_cfg = spi_imx->wml << MX51_ECSPI_DMA_RX_WML_OFFSET;
-		tx_wml_cfg = spi_imx->wml << MX51_ECSPI_DMA_TX_WML_OFFSET;
-		rxt_wml_cfg = spi_imx->wml << MX51_ECSPI_DMA_RXT_WML_OFFSET;
-		dma = (dma & ~MX51_ECSPI_DMA_TX_WML_MASK
-			   & ~MX51_ECSPI_DMA_RX_WML_MASK
-			   & ~MX51_ECSPI_DMA_RXT_WML_MASK)
-			   | rx_wml_cfg | tx_wml_cfg | rxt_wml_cfg
-			   |(1 << MX51_ECSPI_DMA_TEDEN_OFFSET)
-			   |(1 << MX51_ECSPI_DMA_RXDEN_OFFSET)
-			   |(1 << MX51_ECSPI_DMA_RXTDEN_OFFSET);
-
-		writel(dma, spi_imx->base + MX51_ECSPI_DMA);
-	}
+
+	writel(spi_imx->wml << MX51_ECSPI_DMA_RX_WML_OFFSET |
+		spi_imx->wml << MX51_ECSPI_DMA_TX_WML_OFFSET |
+		spi_imx->wml << MX51_ECSPI_DMA_RXT_WML_OFFSET |
+		MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
+		MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
 
 	return 0;
 }
-- 
2.7.0



From s.hauer at pengutronix.de  Thu Feb 18 23:43:10 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 19 Feb 2016 08:43:10 +0100
Subject: [PATCH 10/12] spi: imx: make some register defines simpler
In-Reply-To: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
References: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455867792-26389-11-git-send-email-s.hauer@pengutronix.de>

The watermark levels in the DMA register are write only, the driver
should never have to read them back from the hardware. Replace the
current _MASK and _OFFSET defines with defines taking the watermark
level directly.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 2476de7..dee5e28 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -256,12 +256,9 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 #define MX51_ECSPI_INT_RREN		(1 <<  3)
 
 #define MX51_ECSPI_DMA      0x14
-#define MX51_ECSPI_DMA_TX_WML_OFFSET	0
-#define MX51_ECSPI_DMA_TX_WML_MASK	0x3F
-#define MX51_ECSPI_DMA_RX_WML_OFFSET	16
-#define MX51_ECSPI_DMA_RX_WML_MASK	(0x3F << 16)
-#define MX51_ECSPI_DMA_RXT_WML_OFFSET	24
-#define MX51_ECSPI_DMA_RXT_WML_MASK	(0x3F << 24)
+#define MX51_ECSPI_DMA_TX_WML(wml)	((wml) & 0x3f)
+#define MX51_ECSPI_DMA_RX_WML(wml)	(((wml) & 0x3f) << 16)
+#define MX51_ECSPI_DMA_RXT_WML(wml)	(((wml) & 0x3f) << 24)
 
 #define MX51_ECSPI_DMA_TEDEN		(1 << 7)
 #define MX51_ECSPI_DMA_RXDEN		(1 << 23)
@@ -408,9 +405,9 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 	 * and enable DMA request.
 	 */
 
-	writel(spi_imx->wml << MX51_ECSPI_DMA_RX_WML_OFFSET |
-		spi_imx->wml << MX51_ECSPI_DMA_TX_WML_OFFSET |
-		spi_imx->wml << MX51_ECSPI_DMA_RXT_WML_OFFSET |
+	writel(MX51_ECSPI_DMA_RX_WML(spi_imx->wml) |
+		MX51_ECSPI_DMA_TX_WML(spi_imx->wml) |
+		MX51_ECSPI_DMA_RXT_WML(spi_imx->wml) |
 		MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
 		MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
 
-- 
2.7.0



From s.hauer at pengutronix.de  Thu Feb 18 23:43:11 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 19 Feb 2016 08:43:11 +0100
Subject: [PATCH 11/12] spi: imx: set MX51_ECSPI_CTRL_SMC bit in setup function
In-Reply-To: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
References: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455867792-26389-12-git-send-email-s.hauer@pengutronix.de>

Now that the config function knows whether we are doing DMA or not we
can do the necessary register setup in the config function and no longer
have to do this in the trigger function. With this the trigger function
becomes a no-op for DMA, so instead of testing if we are doing DMA or
not in the trigger function we simply no longer call it in the DMA case.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 21 ++++++---------------
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index dee5e28..3512c2f 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -106,7 +106,6 @@ struct spi_imx_data {
 	unsigned int txfifo; /* number of words pushed in tx FIFO */
 
 	/* DMA */
-	unsigned int dma_finished;
 	bool usedma;
 	u32 wml;
 	struct completion dma_rx_completion;
@@ -324,14 +323,10 @@ static void __maybe_unused mx51_ecspi_intctrl(struct spi_imx_data *spi_imx, int
 
 static void __maybe_unused mx51_ecspi_trigger(struct spi_imx_data *spi_imx)
 {
-	u32 reg = readl(spi_imx->base + MX51_ECSPI_CTRL);
+	u32 reg;
 
-	if (!spi_imx->usedma)
-		reg |= MX51_ECSPI_CTRL_XCH;
-	else if (!spi_imx->dma_finished)
-		reg |= MX51_ECSPI_CTRL_SMC;
-	else
-		reg &= ~MX51_ECSPI_CTRL_SMC;
+	reg = readl(spi_imx->base + MX51_ECSPI_CTRL);
+	reg |= MX51_ECSPI_CTRL_XCH;
 	writel(reg, spi_imx->base + MX51_ECSPI_CTRL);
 }
 
@@ -371,6 +366,9 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 	if (config->mode & SPI_CS_HIGH)
 		cfg |= MX51_ECSPI_CONFIG_SSBPOL(config->cs);
 
+	if (spi_imx->usedma)
+		ctrl |= MX51_ECSPI_CTRL_SMC;
+
 	/* CTRL register always go first to bring out controller from reset */
 	writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
 
@@ -1010,9 +1008,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	reinit_completion(&spi_imx->dma_rx_completion);
 	reinit_completion(&spi_imx->dma_tx_completion);
 
-	/* Trigger the cspi module. */
-	spi_imx->dma_finished = 0;
-
 	/*
 	 * Set these order to avoid potential RX overflow. The overflow may
 	 * happen if we enable SPI HW before starting RX DMA due to rescheduling
@@ -1023,7 +1018,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	 */
 	dma_async_issue_pending(master->dma_rx);
 	dma_async_issue_pending(master->dma_tx);
-	spi_imx->devtype_data->trigger(spi_imx);
 
 	transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len);
 
@@ -1044,9 +1038,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 		}
 	}
 
-	spi_imx->dma_finished = 1;
-	spi_imx->devtype_data->trigger(spi_imx);
-
 	if (!timeout)
 		ret = -ETIMEDOUT;
 	else
-- 
2.7.0



From s.hauer at pengutronix.de  Thu Feb 18 23:43:07 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 19 Feb 2016 08:43:07 +0100
Subject: [PATCH 07/12] spi: imx: drop unncessary dma_is_inited variable
In-Reply-To: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
References: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455867792-26389-8-git-send-email-s.hauer@pengutronix.de>

There's no need for an extra dma_is_inited variable when we can
equally well check for the existence of a DMA channel.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 073a134..57b7af8 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -102,7 +102,6 @@ struct spi_imx_data {
 	unsigned int txfifo; /* number of words pushed in tx FIFO */
 
 	/* DMA */
-	unsigned int dma_is_inited;
 	unsigned int dma_finished;
 	bool usedma;
 	u32 wml;
@@ -205,7 +204,7 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
 
-	if (spi_imx->dma_is_inited && transfer->len >= spi_imx->wml &&
+	if (master->dma_rx && transfer->len >= spi_imx->wml &&
 	    (transfer->len % spi_imx->wml) == 0)
 		return true;
 	return false;
@@ -827,8 +826,6 @@ static void spi_imx_sdma_exit(struct spi_imx_data *spi_imx)
 		dma_release_channel(master->dma_tx);
 		master->dma_tx = NULL;
 	}
-
-	spi_imx->dma_is_inited = 0;
 }
 
 static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
@@ -888,7 +885,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 	master->max_dma_len = MAX_SDMA_BD_BYTES;
 	spi_imx->bitbang.master->flags = SPI_MASTER_MUST_RX |
 					 SPI_MASTER_MUST_TX;
-	spi_imx->dma_is_inited = 1;
 
 	return 0;
 err:
-- 
2.7.0



From s.hauer at pengutronix.de  Thu Feb 18 23:43:03 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 19 Feb 2016 08:43:03 +0100
Subject: [PATCH 03/12] spi: imx: replace fixed timeout with calculated
In-Reply-To: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
References: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455867792-26389-4-git-send-email-s.hauer@pengutronix.de>

From: Anton Bondarenko <anton.bondarenko.sama at gmail.com>

Fixed timeout value can fire while transaction is ongoing. This may happen
because there are no strict requirements on SPI transaction duration.
Dynamic timeout value is generated based on SCLK and transaction size.

There is also 4 * SCLK delay between TX bursts related to HW internal CS change.

Signed-off-by: Anton Bondarenko <anton.bondarenko.sama at gmail.com>
Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 24 +++++++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 7904d45..b277375 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -56,7 +56,6 @@
 
 /* The maximum  bytes that a sdma BD can transfer.*/
 #define MAX_SDMA_BD_BYTES  (1 << 15)
-#define IMX_DMA_TIMEOUT (msecs_to_jiffies(3000))
 struct spi_imx_config {
 	unsigned int speed_hz;
 	unsigned int bpw;
@@ -93,6 +92,7 @@ struct spi_imx_data {
 	struct clk *clk_per;
 	struct clk *clk_ipg;
 	unsigned long spi_clk;
+	unsigned int spi_bus_clk;
 
 	unsigned int count;
 	void (*tx)(struct spi_imx_data *);
@@ -333,6 +333,7 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 
 	/* set clock speed */
 	ctrl |= mx51_ecspi_clkdiv(spi_imx, config->speed_hz, &clk);
+	spi_imx->spi_bus_clk = clk;
 
 	/* set chip select to use */
 	ctrl |= MX51_ECSPI_CTRL_CS(config->cs);
@@ -915,11 +916,26 @@ static void spi_imx_dma_tx_callback(void *cookie)
 	complete(&spi_imx->dma_tx_completion);
 }
 
+static int spi_imx_calculate_timeout(struct spi_imx_data *spi_imx, int size)
+{
+	unsigned long timeout = 0;
+
+	/* Time with actual data transfer and CS change delay related to HW */
+	timeout = (8 + 4) * size / spi_imx->spi_bus_clk;
+
+	/* Add extra second for scheduler related activities */
+	timeout += 1;
+
+	/* Double calculated timeout */
+	return msecs_to_jiffies(2 * timeout * MSEC_PER_SEC);
+}
+
 static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 				struct spi_transfer *transfer)
 {
 	struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
 	int ret;
+	unsigned long transfer_timeout;
 	unsigned long timeout;
 	struct spi_master *master = spi_imx->bitbang.master;
 	struct sg_table *tx = &transfer->tx_sg, *rx = &transfer->rx_sg;
@@ -966,16 +982,18 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	dma_async_issue_pending(master->dma_tx);
 	spi_imx->devtype_data->trigger(spi_imx);
 
+	transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len);
+
 	/* Wait SDMA to finish the data transfer.*/
 	timeout = wait_for_completion_timeout(&spi_imx->dma_tx_completion,
-						IMX_DMA_TIMEOUT);
+						transfer_timeout);
 	if (!timeout) {
 		dev_err(spi_imx->dev, "I/O Error in DMA TX\n");
 		dmaengine_terminate_all(master->dma_tx);
 		dmaengine_terminate_all(master->dma_rx);
 	} else {
 		timeout = wait_for_completion_timeout(
-				&spi_imx->dma_rx_completion, IMX_DMA_TIMEOUT);
+				&spi_imx->dma_rx_completion, transfer_timeout);
 		if (!timeout) {
 			dev_err(spi_imx->dev, "I/O Error in DMA RX\n");
 			spi_imx->devtype_data->reset(spi_imx);
-- 
2.7.0



From s.hauer at pengutronix.de  Thu Feb 18 23:43:08 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 19 Feb 2016 08:43:08 +0100
Subject: [PATCH 08/12] spi: imx: add support for all SPI word width for DMA
In-Reply-To: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
References: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455867792-26389-9-git-send-email-s.hauer@pengutronix.de>

From: Anton Bondarenko <anton.bondarenko.sama at gmail.com>

DMA transfer for SPI was limited to up to 8 bits word size until now.
Sync in SPI burst size and DMA bus width is necessary to correctly
support 16 and 32 BPW.

Signed-off-by: Anton Bondarenko <anton.bondarenko.sama at gmail.com>
Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 118 ++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 91 insertions(+), 27 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 57b7af8..6a0e004 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -89,11 +89,15 @@ struct spi_imx_data {
 
 	struct completion xfer_done;
 	void __iomem *base;
+	unsigned long base_phys;
+
 	struct clk *clk_per;
 	struct clk *clk_ipg;
 	unsigned long spi_clk;
 	unsigned int spi_bus_clk;
 
+	unsigned int bytes_per_word;
+
 	unsigned int count;
 	void (*tx)(struct spi_imx_data *);
 	void (*rx)(struct spi_imx_data *);
@@ -199,15 +203,35 @@ static unsigned int spi_imx_clkdiv_2(unsigned int fin,
 	return 7;
 }
 
+static int spi_imx_bytes_per_word(const int bpw)
+{
+	return DIV_ROUND_UP(bpw, BITS_PER_BYTE);
+}
+
 static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 			 struct spi_transfer *transfer)
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+	unsigned int bpw = transfer->bits_per_word;
+
+	if (!master->dma_rx)
+		return false;
+
+	if (!bpw)
+		bpw = spi->bits_per_word;
+
+	bpw = spi_imx_bytes_per_word(bpw);
+
+	if (bpw != 1 && bpw != 2 && bpw != 4)
+		return false;
+
+	if (transfer->len < spi_imx->wml * bpw)
+		return false;
+
+	if (transfer->len % (spi_imx->wml * bpw))
+		return false;
 
-	if (master->dma_rx && transfer->len >= spi_imx->wml &&
-	    (transfer->len % spi_imx->wml) == 0)
-		return true;
-	return false;
+	return true;
 }
 
 #define MX51_ECSPI_CTRL		0x08
@@ -775,11 +799,63 @@ static irqreturn_t spi_imx_isr(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static int spi_imx_dma_configure(struct spi_master *master,
+				 int bytes_per_word)
+{
+	int ret;
+	enum dma_slave_buswidth buswidth;
+	struct dma_slave_config rx = {}, tx = {};
+	struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+
+	if (bytes_per_word == spi_imx->bytes_per_word)
+		/* Same as last time */
+		return 0;
+
+	switch (bytes_per_word) {
+	case 4:
+		buswidth = DMA_SLAVE_BUSWIDTH_4_BYTES;
+		break;
+	case 2:
+		buswidth = DMA_SLAVE_BUSWIDTH_2_BYTES;
+		break;
+	case 1:
+		buswidth = DMA_SLAVE_BUSWIDTH_1_BYTE;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	tx.direction = DMA_MEM_TO_DEV;
+	tx.dst_addr = spi_imx->base_phys + MXC_CSPITXDATA;
+	tx.dst_addr_width = buswidth;
+	tx.dst_maxburst = spi_imx->wml;
+	ret = dmaengine_slave_config(master->dma_tx, &tx);
+	if (ret) {
+		dev_err(spi_imx->dev, "TX dma configuration failed with %d\n", ret);
+		return ret;
+	}
+
+	rx.direction = DMA_DEV_TO_MEM;
+	rx.src_addr = spi_imx->base_phys + MXC_CSPIRXDATA;
+	rx.src_addr_width = buswidth;
+	rx.src_maxburst = spi_imx->wml;
+	ret = dmaengine_slave_config(master->dma_rx, &rx);
+	if (ret) {
+		dev_err(spi_imx->dev, "RX dma configuration failed with %d\n", ret);
+		return ret;
+	}
+
+	spi_imx->bytes_per_word = bytes_per_word;
+
+	return 0;
+}
+
 static int spi_imx_setupxfer(struct spi_device *spi,
 				 struct spi_transfer *t)
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
 	struct spi_imx_config config;
+	int ret;
 
 	config.bpw = t ? t->bits_per_word : spi->bits_per_word;
 	config.speed_hz  = t ? t->speed_hz : spi->max_speed_hz;
@@ -808,6 +884,13 @@ static int spi_imx_setupxfer(struct spi_device *spi,
 	else
 		spi_imx->usedma = 0;
 
+	if (spi_imx->usedma) {
+		ret = spi_imx_dma_configure(spi->master,
+					    spi_imx_bytes_per_word(config.bpw));
+		if (ret)
+			return ret;
+	}
+
 	spi_imx->devtype_data->config(spi_imx, &config);
 
 	return 0;
@@ -829,10 +912,8 @@ static void spi_imx_sdma_exit(struct spi_imx_data *spi_imx)
 }
 
 static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
-			     struct spi_master *master,
-			     const struct resource *res)
+			     struct spi_master *master)
 {
-	struct dma_slave_config slave_config = {};
 	int ret;
 
 	/* use pio mode for i.mx6dl chip TKT238285 */
@@ -850,16 +931,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 		goto err;
 	}
 
-	slave_config.direction = DMA_MEM_TO_DEV;
-	slave_config.dst_addr = res->start + MXC_CSPITXDATA;
-	slave_config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
-	slave_config.dst_maxburst = spi_imx->wml;
-	ret = dmaengine_slave_config(master->dma_tx, &slave_config);
-	if (ret) {
-		dev_err(dev, "error in TX dma configuration.\n");
-		goto err;
-	}
-
 	/* Prepare for RX : */
 	master->dma_rx = dma_request_slave_channel_reason(dev, "rx");
 	if (IS_ERR(master->dma_rx)) {
@@ -869,15 +940,7 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 		goto err;
 	}
 
-	slave_config.direction = DMA_DEV_TO_MEM;
-	slave_config.src_addr = res->start + MXC_CSPIRXDATA;
-	slave_config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
-	slave_config.src_maxburst = spi_imx->wml;
-	ret = dmaengine_slave_config(master->dma_rx, &slave_config);
-	if (ret) {
-		dev_err(dev, "error in RX dma configuration.\n");
-		goto err;
-	}
+	spi_imx_dma_configure(master, 1);
 
 	init_completion(&spi_imx->dma_rx_completion);
 	init_completion(&spi_imx->dma_tx_completion);
@@ -1162,6 +1225,7 @@ static int spi_imx_probe(struct platform_device *pdev)
 		ret = PTR_ERR(spi_imx->base);
 		goto out_master_put;
 	}
+	spi_imx->base_phys = res->start;
 
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
@@ -1202,7 +1266,7 @@ static int spi_imx_probe(struct platform_device *pdev)
 	 * other chips.
 	 */
 	if (is_imx51_ecspi(spi_imx)) {
-		ret = spi_imx_sdma_init(&pdev->dev, spi_imx, master, res);
+		ret = spi_imx_sdma_init(&pdev->dev, spi_imx, master);
 		if (ret == -EPROBE_DEFER)
 			goto out_clk_put;
 
-- 
2.7.0



From s.hauer at pengutronix.de  Thu Feb 18 23:43:05 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 19 Feb 2016 08:43:05 +0100
Subject: [PATCH 05/12] spi: imx: initialize usedma earlier
In-Reply-To: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
References: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455867792-26389-6-git-send-email-s.hauer@pengutronix.de>

So that the SoC specific config function can know if we will do
DMA or not. Will be needed in following patches.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 5a48d07..7047453 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -815,6 +815,11 @@ static int spi_imx_setupxfer(struct spi_device *spi,
 		spi_imx->tx = spi_imx_buf_tx_u32;
 	}
 
+	if (spi_imx_can_dma(spi_imx->bitbang.master, spi, t))
+		spi_imx->usedma = 1;
+	else
+		spi_imx->usedma = 0;
+
 	spi_imx->devtype_data->config(spi_imx, &config);
 
 	return 0;
@@ -1038,14 +1043,10 @@ static int spi_imx_transfer(struct spi_device *spi,
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
 
-	if (spi_imx->bitbang.master->can_dma &&
-	    spi_imx_can_dma(spi_imx->bitbang.master, spi, transfer)) {
-		spi_imx->usedma = true;
+	if (spi_imx->usedma)
 		return spi_imx_dma_transfer(spi_imx, transfer);
-	}
-	spi_imx->usedma = false;
-
-	return spi_imx_pio_transfer(spi, transfer);
+	else
+		return spi_imx_pio_transfer(spi, transfer);
 }
 
 static int spi_imx_setup(struct spi_device *spi)
-- 
2.7.0



From s.hauer at pengutronix.de  Thu Feb 18 23:43:04 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 19 Feb 2016 08:43:04 +0100
Subject: [PATCH 04/12] spi: imx: drop fallback to PIO
In-Reply-To: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
References: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455867792-26389-5-git-send-email-s.hauer@pengutronix.de>

At the moment the driver decides to fallback to PIO mode the buffers
are already mapped for DMA. It's a bug to access them with the CPU
afterwards, so we cannot just fallback to PIO mode.
It should not be necessary anyway, since we only use DMA when we
verified that it's possible in the fist place, so when prep_slave_sg
fails it's a bug, either in the SDMA driver or in the can_dma
implementation.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index b277375..5a48d07 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -945,7 +945,7 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 					tx->sgl, tx->nents, DMA_MEM_TO_DEV,
 					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
 		if (!desc_tx)
-			goto no_dma;
+			return -EINVAL;
 
 		desc_tx->callback = spi_imx_dma_tx_callback;
 		desc_tx->callback_param = (void *)spi_imx;
@@ -957,7 +957,7 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 					rx->sgl, rx->nents, DMA_DEV_TO_MEM,
 					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
 		if (!desc_rx)
-			goto no_dma;
+			return -EINVAL;
 
 		desc_rx->callback = spi_imx_dma_rx_callback;
 		desc_rx->callback_param = (void *)spi_imx;
@@ -1010,10 +1010,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 		ret = transfer->len;
 
 	return ret;
-
-no_dma:
-	dev_warn_once(spi_imx->dev, "DMA not available, falling back to PIO\n");
-	return -EAGAIN;
 }
 
 static int spi_imx_pio_transfer(struct spi_device *spi,
@@ -1040,15 +1036,12 @@ static int spi_imx_pio_transfer(struct spi_device *spi,
 static int spi_imx_transfer(struct spi_device *spi,
 				struct spi_transfer *transfer)
 {
-	int ret;
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
 
 	if (spi_imx->bitbang.master->can_dma &&
 	    spi_imx_can_dma(spi_imx->bitbang.master, spi, transfer)) {
 		spi_imx->usedma = true;
-		ret = spi_imx_dma_transfer(spi_imx, transfer);
-		if (ret != -EAGAIN)
-			return ret;
+		return spi_imx_dma_transfer(spi_imx, transfer);
 	}
 	spi_imx->usedma = false;
 
-- 
2.7.0



From s.hauer at pengutronix.de  Thu Feb 18 23:43:12 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Fri, 19 Feb 2016 08:43:12 +0100
Subject: [PATCH 12/12] spi: imx: drop bogus tests for rx/tx bufs in DMA
 transfer
In-Reply-To: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
References: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1455867792-26389-13-git-send-email-s.hauer@pengutronix.de>

The driver tries to be clever by only setting up DMA channels when
the corresponding sg tables are non NULL. The sg tables are embedded
structs in struct spi_transfer, so they are guaranteed to be non NULL
which makes the if(tx)/if(rx) tests completely bogus. The driver even
sets the SPI_MASTER_MUST_RX / SPI_MASTER_MUST_TX flags which makes sure
the sg tables are not only present but also non empty.
Drop the tests and make the DMA path easier to follow.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 78 +++++++++++++++++++++------------------------------
 1 file changed, 32 insertions(+), 46 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 3512c2f..9fc1de0 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -975,48 +975,37 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 				struct spi_transfer *transfer)
 {
 	struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
-	int ret;
 	unsigned long transfer_timeout;
 	unsigned long timeout;
 	struct spi_master *master = spi_imx->bitbang.master;
 	struct sg_table *tx = &transfer->tx_sg, *rx = &transfer->rx_sg;
 
-	if (tx) {
-		desc_tx = dmaengine_prep_slave_sg(master->dma_tx,
-					tx->sgl, tx->nents, DMA_MEM_TO_DEV,
-					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
-		if (!desc_tx)
-			return -EINVAL;
-
-		desc_tx->callback = spi_imx_dma_tx_callback;
-		desc_tx->callback_param = (void *)spi_imx;
-		dmaengine_submit(desc_tx);
-	}
+	/*
+	 * The TX DMA setup starts the transfer, so make sure RX is configured
+	 * before TX.
+	 */
+	desc_rx = dmaengine_prep_slave_sg(master->dma_rx,
+				rx->sgl, rx->nents, DMA_DEV_TO_MEM,
+				DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	if (!desc_rx)
+		return -EINVAL;
 
-	if (rx) {
-		desc_rx = dmaengine_prep_slave_sg(master->dma_rx,
-					rx->sgl, rx->nents, DMA_DEV_TO_MEM,
-					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
-		if (!desc_rx)
-			return -EINVAL;
+	desc_rx->callback = spi_imx_dma_rx_callback;
+	desc_rx->callback_param = (void *)spi_imx;
+	dmaengine_submit(desc_rx);
+	reinit_completion(&spi_imx->dma_rx_completion);
+	dma_async_issue_pending(master->dma_rx);
 
-		desc_rx->callback = spi_imx_dma_rx_callback;
-		desc_rx->callback_param = (void *)spi_imx;
-		dmaengine_submit(desc_rx);
-	}
+	desc_tx = dmaengine_prep_slave_sg(master->dma_tx,
+				tx->sgl, tx->nents, DMA_MEM_TO_DEV,
+				DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	if (!desc_tx)
+		return -EINVAL;
 
-	reinit_completion(&spi_imx->dma_rx_completion);
+	desc_tx->callback = spi_imx_dma_tx_callback;
+	desc_tx->callback_param = (void *)spi_imx;
+	dmaengine_submit(desc_tx);
 	reinit_completion(&spi_imx->dma_tx_completion);
-
-	/*
-	 * Set these order to avoid potential RX overflow. The overflow may
-	 * happen if we enable SPI HW before starting RX DMA due to rescheduling
-	 * for another task and/or interrupt.
-	 * So RX DMA enabled first to make sure data would be read out from FIFO
-	 * ASAP. TX DMA enabled next to start filling TX FIFO with new data.
-	 * And finaly SPI HW enabled to start actual data transfer.
-	 */
-	dma_async_issue_pending(master->dma_rx);
 	dma_async_issue_pending(master->dma_tx);
 
 	transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len);
@@ -1028,22 +1017,19 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 		dev_err(spi_imx->dev, "I/O Error in DMA TX\n");
 		dmaengine_terminate_all(master->dma_tx);
 		dmaengine_terminate_all(master->dma_rx);
-	} else {
-		timeout = wait_for_completion_timeout(
-				&spi_imx->dma_rx_completion, transfer_timeout);
-		if (!timeout) {
-			dev_err(spi_imx->dev, "I/O Error in DMA RX\n");
-			spi_imx->devtype_data->reset(spi_imx);
-			dmaengine_terminate_all(master->dma_rx);
-		}
+		return -ETIMEDOUT;
 	}
 
-	if (!timeout)
-		ret = -ETIMEDOUT;
-	else
-		ret = transfer->len;
+	timeout = wait_for_completion_timeout(&spi_imx->dma_rx_completion,
+					      transfer_timeout);
+	if (!timeout) {
+		dev_err(&master->dev, "I/O Error in DMA RX\n");
+		spi_imx->devtype_data->reset(spi_imx);
+		dmaengine_terminate_all(master->dma_rx);
+		return -ETIMEDOUT;
+	}
 
-	return ret;
+	return transfer->len;
 }
 
 static int spi_imx_pio_transfer(struct spi_device *spi,
-- 
2.7.0



From a0393675 at ti.com  Thu Feb 18 23:59:23 2016
From: a0393675 at ti.com (Keerthy)
Date: Fri, 19 Feb 2016 13:29:23 +0530
Subject: [PATCH v2 2/2] ARM: AM43XX: HWMOD: Add rtc hwmod
In-Reply-To: <alpine.DEB.2.02.1602190720490.27696@utopia.booyaka.com>
References: <1455856735-11515-1-git-send-email-j-keerthy@ti.com>
 <1455856735-11515-3-git-send-email-j-keerthy@ti.com>
 <alpine.DEB.2.02.1602190720490.27696@utopia.booyaka.com>
Message-ID: <56C6CB5B.20804@ti.com>



On Friday 19 February 2016 12:51 PM, Paul Walmsley wrote:
> On Fri, 19 Feb 2016, Keerthy wrote:
>
>> The patch adds rtc hwmod. RTC module The RTC module is physically
>> present on the AM438x SoC used on AM43X-EPOS-EVM, but it is permanently
>> disabled. A secure RTC is used instead on these devices, where needed.
>> . Hence adding it selectively using a seprate list to get RTC Module
>> functional on the other am43x SoCs used on am437x-gp-evm and
>> am437x-sk-evm.
>>
>> Signed-off-by: Keerthy <j-keerthy at ti.com>
>> ---
>>
>> Changes in v2:
>>
>> Inverted the checking logic to accommodate registering for all
>> the SoCs compatible to am4372 and removed the negating am438x logic
>> to register rtc hwmods as suggested by Paul.
>>
>>   arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +++++++++++++-
>>   1 file changed, 13 insertions(+), 1 deletion(-)
>
> OK thanks; I've queued the following patch for v4.6 or if I get unlucky,
> v4.7.

Thanks Paul!

>
> - Paul
>
> From: Keerthy <j-keerthy at ti.com>
> Date: Fri, 19 Feb 2016 10:08:55 +0530
> Subject: [PATCH] ARM: AM43XX: hwmod: Add rtc hwmod
>
> The patch registers the rtc hwmod on AM437x chips.  The RTC module is
> physically present on the AM438x SoC used on AM43X-EPOS-EVM, but it is
> permanently disabled. A secure RTC is used instead on these devices,
> where needed. Hence adding it selectively using a separate list to get
> RTC Module functional on the other am43x SoCs used on am437x-gp-evm
> and am437x-sk-evm.
>
> Signed-off-by: Keerthy <j-keerthy at ti.com>
> [paul at pwsan.com: cleaned up patch description]
> Signed-off-by: Paul Walmsley <paul at pwsan.com>
> ---
>   arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 14 +++++++++++++-
>   1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> index e97a894b5f88..97fd399202dc 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> @@ -1020,9 +1020,21 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
>   	NULL,
>   };
>
> +static struct omap_hwmod_ocp_if *am43xx_rtc_hwmod_ocp_ifs[] __initdata = {
> +	&am33xx_l4_wkup__rtc,
> +	NULL,
> +};
> +
>   int __init am43xx_hwmod_init(void)
>   {
> +	int ret;
> +
>   	omap_hwmod_am43xx_reg();
>   	omap_hwmod_init();
> -	return omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
> +	ret = omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
> +
> +	if (!ret && of_machine_is_compatible("ti,am4372"))
> +		ret = omap_hwmod_register_links(am43xx_rtc_hwmod_ocp_ifs);
> +
> +	return ret;
>   }
>


From ard.biesheuvel at linaro.org  Fri Feb 19 00:05:25 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 19 Feb 2016 09:05:25 +0100
Subject: [PATCH v6sub1 00/11] arm64: split linear and kernel mappings
In-Reply-To: <CAKv+Gu_25mz37gdgVx5Yz7DJ+QbOMNa4rYBymFL1nL7nGOzBVQ@mail.gmail.com>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160218182509.GG2538@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_UqoYB5QAWOU9_iZDoRO=rqHu8o87JboSAqNqOhoOCXw@mail.gmail.com>
 <CAKv+Gu_25mz37gdgVx5Yz7DJ+QbOMNa4rYBymFL1nL7nGOzBVQ@mail.gmail.com>
Message-ID: <CAKv+Gu8aKDtev2LdGMy9a485Z8S7TYgsbXky6wR6e3F+j2nkUQ@mail.gmail.com>

On 18 February 2016 at 20:38, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 18 February 2016 at 19:27, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>> On 18 February 2016 at 19:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
>>> On Tue, Feb 16, 2016 at 01:52:31PM +0100, Ard Biesheuvel wrote:
>>>> Ard Biesheuvel (11):
>>>>   of/fdt: make memblock minimum physical address arch configurable
>>>>   of/fdt: factor out assignment of initrd_start/initrd_end
>>>>   arm64: prevent potential circular header dependencies in asm/bug.h
>>>>   arm64: add support for ioremap() block mappings
>>>>   arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
>>>>   arm64: pgtable: implement static [pte|pmd|pud]_offset variants
>>>>   arm64: decouple early fixmap init from linear mapping
>>>>   arm64: kvm: deal with kernel symbols outside of linear mapping
>>>>   arm64: move kernel image to base of vmalloc area
>>>>   arm64: defer __va translation of initrd_start and initrd_end
>>>>   arm64: allow kernel Image to be loaded anywhere in physical memory
>>>
>>> I queued this patches (again) for 4.6. I'll wait a few days with the
>>> rest of KASLR until these get a bit more coverage in -next.
>>>
>
> I rebased the remaining patches onto for-next/core, and pushed it here:
> https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-kaslr-v6
>
> I need to check if everything still works, and if it does, I will send
> them out as v6sub2
> Note that I have included the arm64 extable patch plus its generic
> dependency, and the kallsyms patches as well. We can decide later how
> to proceed with those, but for now, I included them for completeness.

OK, as it turns out, my arm64/extable patch conflicts with the UAO
patches that are now in for-next/core, not textually, but those
patches add additional absolute extable entries that need to be
updated to relative as well.

So it appears that akpm will need to drop that patch anyway, as he
won't be able to carry an updated version since he does not have the
UAO patches. That means it probably makes even more sense to take
those through the arm64 tree as well (minus the x86 one, which has a
conflict now as well). In fact, perhaps it makes sense to only take
the base patch and the arm64 patch, and I can send the remaining ones
to the various maintainers (or akpm) for v4.7


From LW at KARO-electronics.de  Fri Feb 19 00:08:46 2016
From: LW at KARO-electronics.de (Lothar =?UTF-8?B?V2HDn21hbm4=?=)
Date: Fri, 19 Feb 2016 09:08:46 +0100
Subject: [PATCH 05/12] spi: imx: initialize usedma earlier
In-Reply-To: <1455867792-26389-6-git-send-email-s.hauer@pengutronix.de>
References: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
 <1455867792-26389-6-git-send-email-s.hauer@pengutronix.de>
Message-ID: <20160219090846.3004de9d@ipc1.ka-ro>

Hi,

On Fri, 19 Feb 2016 08:43:05 +0100 Sascha Hauer wrote:
> So that the SoC specific config function can know if we will do
>
It's not quite obvious that this partial sentence is a continuation of
the subject header, even more since it starts with a capital letter...


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________


From ilya at compulab.co.il  Fri Feb 19 00:11:34 2016
From: ilya at compulab.co.il (Ilya Ledvich)
Date: Fri, 19 Feb 2016 10:11:34 +0200
Subject: iMX7d cpu1 issue
In-Reply-To: <AMSPR04MB26334EB884FA8A4B565278188AF0@AMSPR04MB263.eurprd04.prod.outlook.com>
References: <56C2D63F.1030408@compulab.co.il> <20160218140913.GY6756@tiger>
 <AMSPR04MB263D00A3F8D9A8D9D3A536D88AF0@AMSPR04MB263.eurprd04.prod.outlook.com>
 <56C5F4D7.1070704@compulab.co.il>
 <AMSPR04MB26334EB884FA8A4B565278188AF0@AMSPR04MB263.eurprd04.prod.outlook.com>
Message-ID: <56C6CE36.6040503@compulab.co.il>

Hi Frank,
Thank you for so brilliant suggestion!!!

> #define CONFIG_MX7_SEC

Seems it works!
The  CPU1 is brought up, and kernel can successfully boot!
Thanks a lot, guys!!!
Your help is much appreciated!
Kind regards,
Ilya.


From rabin.vincent at axis.com  Fri Feb 19 00:12:03 2016
From: rabin.vincent at axis.com (Rabin Vincent)
Date: Fri, 19 Feb 2016 09:12:03 +0100
Subject: [PATCH 1/2] mm: cma: split out in_cma check to separate function
Message-ID: <1455869524-13874-1-git-send-email-rabin.vincent@axis.com>

Split out the logic in cma_release() which checks if the page is in the
contiguous area to a new function which can be called separately.  ARM
will use this.

Signed-off-by: Rabin Vincent <rabin.vincent at axis.com>
---
 include/linux/cma.h | 12 ++++++++++++
 mm/cma.c            | 27 +++++++++++++++++++--------
 2 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/include/linux/cma.h b/include/linux/cma.h
index 29f9e77..6e7fd2d 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -27,5 +27,17 @@ extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
 					unsigned int order_per_bit,
 					struct cma **res_cma);
 extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align);
+
 extern bool cma_release(struct cma *cma, const struct page *pages, unsigned int count);
+#ifdef CONFIG_CMA
+extern bool in_cma(struct cma *cma, const struct page *pages,
+		   unsigned int count);
+#else
+static inline bool in_cma(struct cma *cma, const struct page *pages,
+			  unsigned int count)
+{
+	return false;
+}
+#endif
+
 #endif
diff --git a/mm/cma.c b/mm/cma.c
index ea506eb..55cda16 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -426,6 +426,23 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
 	return page;
 }
 
+bool in_cma(struct cma *cma, const struct page *pages, unsigned int count)
+{
+	unsigned long pfn;
+
+	if (!cma || !pages)
+		return false;
+
+	pfn = page_to_pfn(pages);
+
+	if (pfn < cma->base_pfn || pfn >= cma->base_pfn + cma->count)
+		return false;
+
+	VM_BUG_ON(pfn + count > cma->base_pfn + cma->count);
+
+	return true;
+}
+
 /**
  * cma_release() - release allocated pages
  * @cma:   Contiguous memory region for which the allocation is performed.
@@ -440,18 +457,12 @@ bool cma_release(struct cma *cma, const struct page *pages, unsigned int count)
 {
 	unsigned long pfn;
 
-	if (!cma || !pages)
-		return false;
-
 	pr_debug("%s(page %p)\n", __func__, (void *)pages);
 
-	pfn = page_to_pfn(pages);
-
-	if (pfn < cma->base_pfn || pfn >= cma->base_pfn + cma->count)
+	if (!in_cma(cma, pages, count))
 		return false;
 
-	VM_BUG_ON(pfn + count > cma->base_pfn + cma->count);
-
+	pfn = page_to_pfn(pages);
 	free_contig_range(pfn, count);
 	cma_clear_bitmap(cma, pfn, count);
 	trace_cma_release(pfn, pages, count);
-- 
2.7.0



From rabin.vincent at axis.com  Fri Feb 19 00:12:04 2016
From: rabin.vincent at axis.com (Rabin Vincent)
Date: Fri, 19 Feb 2016 09:12:04 +0100
Subject: [PATCH 2/2] ARM: dma-mapping: fix alloc/free for coherent + CMA +
 gfp=0
In-Reply-To: <1455869524-13874-1-git-send-email-rabin.vincent@axis.com>
References: <1455869524-13874-1-git-send-email-rabin.vincent@axis.com>
Message-ID: <1455869524-13874-2-git-send-email-rabin.vincent@axis.com>

Given a device which uses arm_coherent_dma_ops and on which
dev_get_cma_area(dev) returns non-NULL, the following usage of the DMA
API with gfp=0 results in a memory leak and memory corruption.

 p = dma_alloc_coherent(dev, sz, &dma, 0);
 if (p)
 	dma_free_coherent(dev, sz, p, dma);

The memory leak is because the alloc allocates using
__alloc_simple_buffer() but the free attempts
dma_release_from_contiguous(), which does not do free anything since the
page is not in the CMA area.

The memory corruption is because the free calls __dma_remap() on a page
which is backed by only first level page tables.  The
apply_to_page_range() + __dma_update_pte() loop ends up interpreting the
section mapping as the address to a second level page table and writing
the new PTE to memory which is not used by page tables.

We don't have access to the GFP flags used for allocation in the free
function, so fix it by using the new in_cma() function to determine if a
buffer was allocated with CMA, similar to how we check for
__in_atomic_pool().

Fixes: 21caf3a7 ("ARM: 8398/1: arm DMA: Fix allocation from CMA for coherent DMA")
Signed-off-by: Rabin Vincent <rabin.vincent at axis.com>
---
 arch/arm/mm/dma-mapping.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 0eca381..a4592c7 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -749,16 +749,16 @@ static void __arm_dma_free(struct device *dev, size_t size, void *cpu_addr,
 		__dma_free_buffer(page, size);
 	} else if (!is_coherent && __free_from_pool(cpu_addr, size)) {
 		return;
-	} else if (!dev_get_cma_area(dev)) {
-		if (want_vaddr && !is_coherent)
-			__dma_free_remap(cpu_addr, size);
-		__dma_free_buffer(page, size);
-	} else {
+	} else if (in_cma(dev_get_cma_area(dev), page, size >> PAGE_SHIFT)) {
 		/*
 		 * Non-atomic allocations cannot be freed with IRQs disabled
 		 */
 		WARN_ON(irqs_disabled());
 		__free_from_contiguous(dev, page, cpu_addr, size, want_vaddr);
+	} else {
+		if (want_vaddr && !is_coherent)
+			__dma_free_remap(cpu_addr, size);
+		__dma_free_buffer(page, size);
 	}
 }
 
-- 
2.7.0



From Alexey.Brodkin at synopsys.com  Fri Feb 19 00:15:01 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Fri, 19 Feb 2016 11:15:01 +0300
Subject: [PATCH] drm: ARM HDLCD - get rid of devm_clk_put()
Message-ID: <1455869701-23437-1-git-send-email-abrodkin@synopsys.com>

Clock is acquired with devm_clk_get() which already manages
corresponding resource.

I.e. in case of driver removal or failure on installaiton
clock resources will be automatically released and explicit
call of devm_clk_put() is not required.

Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
Cc: Liviu Dudau <Liviu.Dudau at arm.com>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
Cc: David Airlie <airlied at linux.ie>
Cc: Robin Murphy <robin.murphy at arm.com>
---
 drivers/gpu/drm/arm/hdlcd_drv.c | 15 +++------------
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index 56b829f..734849f 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -55,16 +55,14 @@ static int hdlcd_load(struct drm_device *drm, unsigned long flags)
 	hdlcd->mmio = devm_ioremap_resource(drm->dev, res);
 	if (IS_ERR(hdlcd->mmio)) {
 		DRM_ERROR("failed to map control registers area\n");
-		ret = PTR_ERR(hdlcd->mmio);
 		hdlcd->mmio = NULL;
-		goto fail;
+		return PTR_ERR(hdlcd->mmio);
 	}
 
 	version = hdlcd_read(hdlcd, HDLCD_REG_VERSION);
 	if ((version & HDLCD_PRODUCT_MASK) != HDLCD_PRODUCT_ID) {
 		DRM_ERROR("unknown product id: 0x%x\n", version);
-		ret = -EINVAL;
-		goto fail;
+		return -EINVAL;
 	}
 	DRM_INFO("found ARM HDLCD version r%dp%d\n",
 		(version & HDLCD_VERSION_MAJOR_MASK) >> 8,
@@ -73,7 +71,7 @@ static int hdlcd_load(struct drm_device *drm, unsigned long flags)
 	/* Get the optional framebuffer memory resource */
 	ret = of_reserved_mem_device_init(drm->dev);
 	if (ret && ret != -ENODEV)
-		goto fail;
+		return ret;
 
 	ret = dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32));
 	if (ret)
@@ -101,8 +99,6 @@ irq_fail:
 	drm_crtc_cleanup(&hdlcd->crtc);
 setup_fail:
 	of_reserved_mem_device_release(drm->dev);
-fail:
-	devm_clk_put(drm->dev, hdlcd->clk);
 
 	return ret;
 }
@@ -412,7 +408,6 @@ err_unload:
 	pm_runtime_put_sync(drm->dev);
 	pm_runtime_disable(drm->dev);
 	of_reserved_mem_device_release(drm->dev);
-	devm_clk_put(dev, hdlcd->clk);
 err_free:
 	drm_dev_unref(drm);
 
@@ -436,10 +431,6 @@ static void hdlcd_drm_unbind(struct device *dev)
 	pm_runtime_put_sync(drm->dev);
 	pm_runtime_disable(drm->dev);
 	of_reserved_mem_device_release(drm->dev);
-	if (!IS_ERR(hdlcd->clk)) {
-		devm_clk_put(drm->dev, hdlcd->clk);
-		hdlcd->clk = NULL;
-	}
 	drm_mode_config_cleanup(drm);
 	drm_dev_unregister(drm);
 	drm_dev_unref(drm);
-- 
2.5.0



From m.szyprowski at samsung.com  Fri Feb 19 00:22:41 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Fri, 19 Feb 2016 09:22:41 +0100
Subject: [RFC 0/3] Unify IOMMU-based DMA-mapping code for ARM and ARM64
Message-ID: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com>

Dear All,

This is an initial RFC on the unification of IOMMU-based DMA-mapping
code for ARM and ARM64 architectures.

Right now ARM architecture still use my old code for IOMMU-based
DMA-mapping glue, initially merged in commit
4ce63fcd919c32d22528e54dcd89506962933719 ("ARM: dma-mapping: add support
for IOMMU mapper"). In meantime ARM64 got a new, slightly improved
implementation provided by Robin Murphy in commit
13b8629f651164d71f4d38b821925f93ba4236c8 ("arm64: Add IOMMU dma_ops").

Both implementations are very similar thus their unification is desired
to avoid duplicating future works and simplify code, which uses this
layer on both architectures. In this patchset I've selected the new
implementation (from ARM64 architecture) as a base. This means that
ARM-specific, old interface (arm_iommu_* functions) for configuring
IOMMU domains will be no longer available and its users have to be
converted to new API.

Besides lack of old interface, the second difference is additional
requirements for IOMMU drivers. New code relies on the support for
IOMMU_DOMAIN_DMA and default IOMMU domain, which is automatically
attached by the IOMMU core.

The new code also assumes that the IOMMU-based DMA-mapping ops are
mainly configured from arch_setup_dma_ops() function, which means that
the IOMMU driver should provide needed of_xlate callbacks and initialize
IOMMU ops for device nodes. However it should be also possible to
initialize IOMMU-based DMA-mapping ops for client devices directly from
IOMMU drivers by calling common_iommu_setup_dma_ops() (some drivers used
such approach).

IOMMU drivers should be also aware of the fact that the
default domain is attached via device_attach and then device_attach
callback can be called once again with different domain without previous
detach from default domain. For more information on this issue, see the
following thread:
https://lists.linaro.org/pipermail/linaro-mm-sig/2016-February/004625.html

Currently there are 4 users of the old arm_iommu_* interface:
1. Exynos DRM driver
2. Rockchip DRM driver
3. OMAP3 ISP camera driver
4. Renesas VMSA-compatible IPMMU driver

In this patchset I've converted Exynos DRM driver for the new API (patch
1). This required some changes in the memory management model inside the
driver and removal of some hacks, which were used to setup IOMMU-based
DMA-mapping ops on the 'exynos-drm' virtual device and common IOMMU
domain for all Exynos DRM sub-devices, those changes have been posted
separately here: http://www.spinics.net/lists/dri-devel/msg100861.html 
Rockchip DRM driver requires similar conversion.

Converting OMAP3 ISP camera driver to new API requires adding support
for IOMMU groups to OMAP IOMMU driver, because the new DMA/IOMMU code
used IOMMU_DOMAIN_DMA type domains and default groups.

Renesas IPMMU driver needs also to be extended with IOMMU_DOMAIN_DMA domain
type support. It can also be prepared for IOMMU_OF_DECLARE and of_xlate
callback-based initialization to let core to automatically setup of
IOMMU-based DMA mapping implementation.

Patch 2 moves existing code from arch/arm64 to drivers/iommu and
introduces some minor changes in function names - mainly adding arch_
prefix to some dma-mapping internal functions, which stay in arch/arm64/
(functions of similar names are present in arch/arm). Patch 3 adapts ARM
architecture for the common code.

I would like to get your comments on the proposed approach. There is
still some work that need to be done to convert remaining users of the
old API and updating IOMMU drivers to the new API requirements. This
change need to be tested on the all affected ARM sub-architectures.

Right now patches were tested on only Exynos based boards: ARM 32bit:
Exynos4412 and Exynos5422 boards and ARM 64 bit Exnyos 5433 (with some
out-of-tree DTS).

To ease testing I've prepared a branch with all the patches needed
(there are all needed patches for Exynos subarch, which have been posted
as separate patchsets):
https://git.linaro.org/people/marek.szyprowski/linux-srpol.git v4.5-dma-iommu-unification

Patches are based on Linux v4.5-rc4 vanilla tree.

Best regards
Marek Szyprowski
Samsung R&D Institute Poland


Patch summary:

Marek Szyprowski (3):
  drm/exynos: rewrite IOMMU support code
  iommu: dma-iommu: move IOMMU/DMA-mapping code from ARM64 arch to drivers
  iommu: dma-iommu: use common implementation also on ARM architecture

 arch/arm/Kconfig                          |   22 +-
 arch/arm/include/asm/device.h             |    9 -
 arch/arm/include/asm/dma-iommu.h          |   37 -
 arch/arm/include/asm/dma-mapping.h        |   59 +-
 arch/arm/mm/dma-mapping.c                 | 1158 +----------------------------
 arch/arm64/include/asm/dma-mapping.h      |   39 +-
 arch/arm64/mm/dma-mapping.c               |  491 +-----------
 drivers/gpu/drm/exynos/Kconfig            |    2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |    7 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |    2 +-
 drivers/gpu/drm/exynos/exynos_drm_iommu.c |   91 ++-
 drivers/gpu/drm/exynos/exynos_drm_iommu.h |    2 +-
 drivers/gpu/drm/rockchip/Kconfig          |    1 +
 drivers/iommu/Kconfig                     |    1 +
 drivers/iommu/Makefile                    |    2 +-
 drivers/iommu/dma-iommu-ops.c             |  471 ++++++++++++
 drivers/media/platform/Kconfig            |    1 +
 include/linux/dma-iommu.h                 |   14 +
 18 files changed, 679 insertions(+), 1730 deletions(-)
 delete mode 100644 arch/arm/include/asm/dma-iommu.h
 create mode 100644 drivers/iommu/dma-iommu-ops.c

-- 
1.9.2



From m.szyprowski at samsung.com  Fri Feb 19 00:22:42 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Fri, 19 Feb 2016 09:22:42 +0100
Subject: [RFC 1/3] drm/exynos: rewrite IOMMU support code
In-Reply-To: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com>
References: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455870164-25337-2-git-send-email-m.szyprowski@samsung.com>

This patch replaces usage of ARM-specific IOMMU/DMA-mapping related calls
with new generic code for managing DMA-IOMMU integration layer. It also
removes all the hacks, which were needed to configure common DMA/IO address
space on the virtual exynos-drm device. Since moving Exynos GEM code to use
on of real devices for DMA-mapping operations, such hacks are no longer
needed. The only requirement is to have all the devices, which build
Exynos DRM, attached to the same IOMMU domain (to share IO address space).

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 drivers/gpu/drm/exynos/Kconfig            |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |  7 +--
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_iommu.c | 91 +++++++++++++++++++------------
 drivers/gpu/drm/exynos/exynos_drm_iommu.h |  2 +-
 5 files changed, 59 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 83efca941388..b0d0aaa7fea5 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -15,7 +15,7 @@ if DRM_EXYNOS
 
 config DRM_EXYNOS_IOMMU
 	bool
-	depends on EXYNOS_IOMMU && ARM_DMA_USE_IOMMU
+	depends on EXYNOS_IOMMU && IOMMU_DMA
 	default y
 
 comment "CRTCs"
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index c7fce7ffeef5..45aa480f1890 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -159,12 +159,7 @@ static int exynos_drm_load(struct drm_device *dev, unsigned long flags)
 	DRM_INFO("Exynos DRM: using %s device for DMA mapping operations\n",
 		 dev_name(private->dma_dev));
 
-	/*
-	 * create mapping to manage iommu table and set a pointer to iommu
-	 * mapping structure to iommu_mapping of private data.
-	 * also this iommu_mapping can be used to check if iommu is supported
-	 * or not.
-	 */
+	/* create common IOMMU mapping for all devices attached to Exynos DRM */
 	ret = drm_create_iommu_mapping(dev);
 	if (ret < 0) {
 		DRM_ERROR("failed to create iommu mapping.\n");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 303056311c0c..b107f77d0897 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -222,7 +222,7 @@ struct exynos_drm_private {
 	struct device *dma_dev;
 	unsigned long da_start;
 	unsigned long da_space_size;
-	void *mapping;
+	struct iommu_domain *domain;
 
 	unsigned int pipe;
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
index 146ac88078ae..89e51ed6499d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
@@ -14,13 +14,28 @@
 
 #include <linux/dma-mapping.h>
 #include <linux/iommu.h>
-#include <linux/kref.h>
-
-#include <asm/dma-iommu.h>
+#include <linux/dma-iommu.h>
 
 #include "exynos_drm_drv.h"
 #include "exynos_drm_iommu.h"
 
+static inline int configure_dma_max_seg_size(struct device *dev)
+{
+	if (!dev->dma_parms)
+		dev->dma_parms = kzalloc(sizeof(*dev->dma_parms), GFP_KERNEL);
+	if (!dev->dma_parms)
+		return -ENOMEM;
+
+	dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
+	return 0;
+}
+
+static inline void clear_dma_max_seg_size(struct device *dev)
+{
+	kfree(dev->dma_parms);
+	dev->dma_parms = NULL;
+}
+
 /*
  * drm_create_iommu_mapping - create a mapping structure
  *
@@ -28,38 +43,48 @@
  */
 int drm_create_iommu_mapping(struct drm_device *drm_dev)
 {
-	struct dma_iommu_mapping *mapping = NULL;
 	struct exynos_drm_private *priv = drm_dev->dev_private;
+	struct device *dev = to_dma_dev(drm_dev);
+	int ret;
 
 	if (!priv->da_start)
 		priv->da_start = EXYNOS_DEV_ADDR_START;
 	if (!priv->da_space_size)
 		priv->da_space_size = EXYNOS_DEV_ADDR_SIZE;
 
-	mapping = arm_iommu_create_mapping(&platform_bus_type, priv->da_start,
-						priv->da_space_size);
+	priv->domain = iommu_domain_alloc(dev->bus);
+	if (!priv->domain)
+		return -ENOMEM;
 
-	if (IS_ERR(mapping))
-		return PTR_ERR(mapping);
+	ret = iommu_get_dma_cookie(priv->domain);
+	if (ret)
+		goto free_domain;
 
-	priv->mapping = mapping;
+	ret = iommu_dma_init_domain(priv->domain, priv->da_start,
+				    priv->da_space_size);
+	if (ret)
+		goto put_cookie;
 
 	return 0;
+
+put_cookie:
+	iommu_put_dma_cookie(priv->domain);
+free_domain:
+	iommu_domain_free(priv->domain);
+	return ret;
 }
 
 /*
  * drm_release_iommu_mapping - release iommu mapping structure
  *
  * @drm_dev: DRM device
- *
- * if mapping->kref becomes 0 then all things related to iommu mapping
- * will be released
  */
 void drm_release_iommu_mapping(struct drm_device *drm_dev)
 {
 	struct exynos_drm_private *priv = drm_dev->dev_private;
 
-	arm_iommu_release_mapping(priv->mapping);
+	iommu_put_dma_cookie(priv->domain);
+	iommu_domain_free(priv->domain);
 }
 
 /*
@@ -75,29 +100,25 @@ int drm_iommu_attach_device(struct drm_device *drm_dev,
 				struct device *subdrv_dev)
 {
 	struct exynos_drm_private *priv = drm_dev->dev_private;
+	struct device *dev = to_dma_dev(drm_dev);
+	struct iommu_domain *domain = priv->domain;
 	int ret;
 
-	if (!priv->mapping)
-		return 0;
-
-	subdrv_dev->dma_parms = devm_kzalloc(subdrv_dev,
-					sizeof(*subdrv_dev->dma_parms),
-					GFP_KERNEL);
-	if (!subdrv_dev->dma_parms)
-		return -ENOMEM;
-
-	dma_set_max_seg_size(subdrv_dev, 0xffffffffu);
-
-	if (subdrv_dev->archdata.mapping)
-		arm_iommu_detach_device(subdrv_dev);
+	if (get_dma_ops(dev) != get_dma_ops(subdrv_dev)) {
+		DRM_ERROR("Device %s lacks support for IOMMU\n",
+			  dev_name(subdrv_dev));
+		return -EINVAL;
+	}
 
-	ret = arm_iommu_attach_device(subdrv_dev, priv->mapping);
-	if (ret < 0) {
-		DRM_DEBUG_KMS("failed iommu attach.\n");
+	ret = configure_dma_max_seg_size(subdrv_dev);
+	if (ret)
 		return ret;
-	}
 
-	return 0;
+	ret = iommu_attach_device(domain, subdrv_dev);
+	if (ret != 0)
+		clear_dma_max_seg_size(subdrv_dev);
+
+	return ret;
 }
 
 /*
@@ -113,10 +134,8 @@ void drm_iommu_detach_device(struct drm_device *drm_dev,
 				struct device *subdrv_dev)
 {
 	struct exynos_drm_private *priv = drm_dev->dev_private;
-	struct dma_iommu_mapping *mapping = priv->mapping;
-
-	if (!mapping || !mapping->domain)
-		return;
+	struct iommu_domain *domain = priv->domain;
 
-	arm_iommu_detach_device(subdrv_dev);
+	iommu_detach_device(domain, subdrv_dev);
+	clear_dma_max_seg_size(subdrv_dev);
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.h b/drivers/gpu/drm/exynos/exynos_drm_iommu.h
index c1584f24d23d..8318ebe2de6d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_iommu.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.h
@@ -30,7 +30,7 @@ void drm_iommu_detach_device(struct drm_device *dev_dev,
 static inline bool is_drm_iommu_supported(struct drm_device *drm_dev)
 {
 	struct exynos_drm_private *priv = drm_dev->dev_private;
-	return priv->mapping ? true : false;
+	return priv->domain ? true : false;
 }
 
 #else
-- 
1.9.2



From m.szyprowski at samsung.com  Fri Feb 19 00:22:43 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Fri, 19 Feb 2016 09:22:43 +0100
Subject: [RFC 2/3] iommu: dma-iommu: move IOMMU/DMA-mapping code from ARM64
 arch to drivers
In-Reply-To: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com>
References: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455870164-25337-3-git-send-email-m.szyprowski@samsung.com>

This patch moves all the IOMMU-based DMA-mapping code from arch/arm64/mm
to drivers/iommu/dma-iommu-ops.c. This way it can be easily shared with
ARM architecture, which will also use them.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 arch/arm64/include/asm/dma-mapping.h |  39 ++-
 arch/arm64/mm/dma-mapping.c          | 491 ++---------------------------------
 drivers/iommu/Makefile               |   2 +-
 drivers/iommu/dma-iommu-ops.c        | 471 +++++++++++++++++++++++++++++++++
 include/linux/dma-iommu.h            |  14 +
 5 files changed, 538 insertions(+), 479 deletions(-)
 create mode 100644 drivers/iommu/dma-iommu-ops.c

diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index ba437f090a74..3a582d820717 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -22,6 +22,7 @@
 #include <linux/vmalloc.h>
 
 #include <xen/xen.h>
+#include <asm/cacheflush.h>
 #include <asm/xen/hypervisor.h>
 
 #define DMA_ERROR_CODE	(~(dma_addr_t)0)
@@ -47,14 +48,17 @@ static inline struct dma_map_ops *get_dma_ops(struct device *dev)
 		return __generic_dma_ops(dev);
 }
 
+static inline void arch_set_dma_ops(struct device *dev, struct dma_map_ops *ops)
+{
+	dev->archdata.dma_ops = ops;
+}
+
 void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
 			struct iommu_ops *iommu, bool coherent);
 #define arch_setup_dma_ops	arch_setup_dma_ops
 
-#ifdef CONFIG_IOMMU_DMA
 void arch_teardown_dma_ops(struct device *dev);
 #define arch_teardown_dma_ops	arch_teardown_dma_ops
-#endif
 
 /* do not use this function in a driver */
 static inline bool is_device_dma_coherent(struct device *dev)
@@ -86,5 +90,36 @@ static inline void dma_mark_clean(void *addr, size_t size)
 {
 }
 
+static inline void arch_flush_page(struct device *dev, const void *virt,
+				   phys_addr_t phys)
+{
+	__dma_flush_range(virt, virt + PAGE_SIZE);
+}
+
+static inline void arch_dma_map_area(phys_addr_t phys, size_t size,
+				     enum dma_data_direction dir)
+{
+	__dma_map_area(phys_to_virt(phys), size, dir);
+}
+
+static inline void arch_dma_unmap_area(phys_addr_t phys, size_t size,
+				       enum dma_data_direction dir)
+{
+	__dma_unmap_area(phys_to_virt(phys), size, dir);
+}
+
+static inline pgprot_t arch_get_dma_pgprot(struct dma_attrs *attrs,
+					pgprot_t prot, bool coherent)
+{
+	if (!coherent || dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs))
+		return pgprot_writecombine(prot);
+	return prot;
+}
+
+extern void *arch_alloc_from_atomic_pool(size_t size, struct page **ret_page,
+					 gfp_t flags);
+extern bool arch_in_atomic_pool(void *start, size_t size);
+extern int arch_free_from_atomic_pool(void *start, size_t size);
+
 #endif	/* __KERNEL__ */
 #endif	/* __ASM_DMA_MAPPING_H */
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index a6e757cbab77..d8cb8552bbff 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -24,19 +24,12 @@
 #include <linux/genalloc.h>
 #include <linux/dma-mapping.h>
 #include <linux/dma-contiguous.h>
+#include <linux/dma-iommu.h>
 #include <linux/vmalloc.h>
 #include <linux/swiotlb.h>
 
 #include <asm/cacheflush.h>
 
-static pgprot_t __get_dma_pgprot(struct dma_attrs *attrs, pgprot_t prot,
-				 bool coherent)
-{
-	if (!coherent || dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs))
-		return pgprot_writecombine(prot);
-	return prot;
-}
-
 static struct gen_pool *atomic_pool;
 
 #define DEFAULT_DMA_COHERENT_POOL_SIZE  SZ_256K
@@ -49,7 +42,7 @@ static int __init early_coherent_pool(char *p)
 }
 early_param("coherent_pool", early_coherent_pool);
 
-static void *__alloc_from_pool(size_t size, struct page **ret_page, gfp_t flags)
+void *arch_alloc_from_atomic_pool(size_t size, struct page **ret_page, gfp_t flags)
 {
 	unsigned long val;
 	void *ptr = NULL;
@@ -71,14 +64,14 @@ static void *__alloc_from_pool(size_t size, struct page **ret_page, gfp_t flags)
 	return ptr;
 }
 
-static bool __in_atomic_pool(void *start, size_t size)
+bool arch_in_atomic_pool(void *start, size_t size)
 {
 	return addr_in_gen_pool(atomic_pool, (unsigned long)start, size);
 }
 
-static int __free_from_pool(void *start, size_t size)
+int arch_free_from_atomic_pool(void *start, size_t size)
 {
-	if (!__in_atomic_pool(start, size))
+	if (!arch_in_atomic_pool(start, size))
 		return 0;
 
 	gen_pool_free(atomic_pool, (unsigned long)start, size);
@@ -142,13 +135,13 @@ static void *__dma_alloc(struct device *dev, size_t size,
 	struct page *page;
 	void *ptr, *coherent_ptr;
 	bool coherent = is_device_dma_coherent(dev);
-	pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL, false);
+	pgprot_t prot = arch_get_dma_pgprot(attrs, PAGE_KERNEL, false);
 
 	size = PAGE_ALIGN(size);
 
 	if (!coherent && !gfpflags_allow_blocking(flags)) {
 		struct page *page = NULL;
-		void *addr = __alloc_from_pool(size, &page, flags);
+		void *addr = arch_alloc_from_atomic_pool(size, &page, flags);
 
 		if (addr)
 			*dma_handle = phys_to_dma(dev, page_to_phys(page));
@@ -192,7 +185,7 @@ static void __dma_free(struct device *dev, size_t size,
 	size = PAGE_ALIGN(size);
 
 	if (!is_device_dma_coherent(dev)) {
-		if (__free_from_pool(vaddr, size))
+		if (arch_free_from_atomic_pool(vaddr, size))
 			return;
 		vunmap(vaddr);
 	}
@@ -312,7 +305,7 @@ static int __swiotlb_mmap(struct device *dev,
 	unsigned long pfn = dma_to_phys(dev, dma_addr) >> PAGE_SHIFT;
 	unsigned long off = vma->vm_pgoff;
 
-	vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot,
+	vma->vm_page_prot = arch_get_dma_pgprot(attrs, vma->vm_page_prot,
 					     is_device_dma_coherent(dev));
 
 	if (dma_mmap_from_coherent(dev, vma, cpu_addr, size, &ret))
@@ -526,470 +519,16 @@ static int __init dma_debug_do_init(void)
 }
 fs_initcall(dma_debug_do_init);
 
-
-#ifdef CONFIG_IOMMU_DMA
-#include <linux/dma-iommu.h>
-#include <linux/platform_device.h>
-#include <linux/amba/bus.h>
-
-/* Thankfully, all cache ops are by VA so we can ignore phys here */
-static void flush_page(struct device *dev, const void *virt, phys_addr_t phys)
-{
-	__dma_flush_range(virt, virt + PAGE_SIZE);
-}
-
-static void *__iommu_alloc_attrs(struct device *dev, size_t size,
-				 dma_addr_t *handle, gfp_t gfp,
-				 struct dma_attrs *attrs)
-{
-	bool coherent = is_device_dma_coherent(dev);
-	int ioprot = dma_direction_to_prot(DMA_BIDIRECTIONAL, coherent);
-	size_t iosize = size;
-	void *addr;
-
-	if (WARN(!dev, "cannot create IOMMU mapping for unknown device\n"))
-		return NULL;
-
-	size = PAGE_ALIGN(size);
-
-	/*
-	 * Some drivers rely on this, and we probably don't want the
-	 * possibility of stale kernel data being read by devices anyway.
-	 */
-	gfp |= __GFP_ZERO;
-
-	if (gfpflags_allow_blocking(gfp)) {
-		struct page **pages;
-		pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL, coherent);
-
-		pages = iommu_dma_alloc(dev, iosize, gfp, ioprot, handle,
-					flush_page);
-		if (!pages)
-			return NULL;
-
-		addr = dma_common_pages_remap(pages, size, VM_USERMAP, prot,
-					      __builtin_return_address(0));
-		if (!addr)
-			iommu_dma_free(dev, pages, iosize, handle);
-	} else {
-		struct page *page;
-		/*
-		 * In atomic context we can't remap anything, so we'll only
-		 * get the virtually contiguous buffer we need by way of a
-		 * physically contiguous allocation.
-		 */
-		if (coherent) {
-			page = alloc_pages(gfp, get_order(size));
-			addr = page ? page_address(page) : NULL;
-		} else {
-			addr = __alloc_from_pool(size, &page, gfp);
-		}
-		if (!addr)
-			return NULL;
-
-		*handle = iommu_dma_map_page(dev, page, 0, iosize, ioprot);
-		if (iommu_dma_mapping_error(dev, *handle)) {
-			if (coherent)
-				__free_pages(page, get_order(size));
-			else
-				__free_from_pool(addr, size);
-			addr = NULL;
-		}
-	}
-	return addr;
-}
-
-static void __iommu_free_attrs(struct device *dev, size_t size, void *cpu_addr,
-			       dma_addr_t handle, struct dma_attrs *attrs)
-{
-	size_t iosize = size;
-
-	size = PAGE_ALIGN(size);
-	/*
-	 * @cpu_addr will be one of 3 things depending on how it was allocated:
-	 * - A remapped array of pages from iommu_dma_alloc(), for all
-	 *   non-atomic allocations.
-	 * - A non-cacheable alias from the atomic pool, for atomic
-	 *   allocations by non-coherent devices.
-	 * - A normal lowmem address, for atomic allocations by
-	 *   coherent devices.
-	 * Hence how dodgy the below logic looks...
-	 */
-	if (__in_atomic_pool(cpu_addr, size)) {
-		iommu_dma_unmap_page(dev, handle, iosize, 0, NULL);
-		__free_from_pool(cpu_addr, size);
-	} else if (is_vmalloc_addr(cpu_addr)){
-		struct vm_struct *area = find_vm_area(cpu_addr);
-
-		if (WARN_ON(!area || !area->pages))
-			return;
-		iommu_dma_free(dev, area->pages, iosize, &handle);
-		dma_common_free_remap(cpu_addr, size, VM_USERMAP);
-	} else {
-		iommu_dma_unmap_page(dev, handle, iosize, 0, NULL);
-		__free_pages(virt_to_page(cpu_addr), get_order(size));
-	}
-}
-
-static int __iommu_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
-			      void *cpu_addr, dma_addr_t dma_addr, size_t size,
-			      struct dma_attrs *attrs)
-{
-	struct vm_struct *area;
-	int ret;
-
-	vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot,
-					     is_device_dma_coherent(dev));
-
-	if (dma_mmap_from_coherent(dev, vma, cpu_addr, size, &ret))
-		return ret;
-
-	area = find_vm_area(cpu_addr);
-	if (WARN_ON(!area || !area->pages))
-		return -ENXIO;
-
-	return iommu_dma_mmap(area->pages, size, vma);
-}
-
-static int __iommu_get_sgtable(struct device *dev, struct sg_table *sgt,
-			       void *cpu_addr, dma_addr_t dma_addr,
-			       size_t size, struct dma_attrs *attrs)
-{
-	unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
-	struct vm_struct *area = find_vm_area(cpu_addr);
-
-	if (WARN_ON(!area || !area->pages))
-		return -ENXIO;
-
-	return sg_alloc_table_from_pages(sgt, area->pages, count, 0, size,
-					 GFP_KERNEL);
-}
-
-static void __iommu_sync_single_for_cpu(struct device *dev,
-					dma_addr_t dev_addr, size_t size,
-					enum dma_data_direction dir)
-{
-	phys_addr_t phys;
-
-	if (is_device_dma_coherent(dev))
-		return;
-
-	phys = iommu_iova_to_phys(iommu_get_domain_for_dev(dev), dev_addr);
-	__dma_unmap_area(phys_to_virt(phys), size, dir);
-}
-
-static void __iommu_sync_single_for_device(struct device *dev,
-					   dma_addr_t dev_addr, size_t size,
-					   enum dma_data_direction dir)
-{
-	phys_addr_t phys;
-
-	if (is_device_dma_coherent(dev))
-		return;
-
-	phys = iommu_iova_to_phys(iommu_get_domain_for_dev(dev), dev_addr);
-	__dma_map_area(phys_to_virt(phys), size, dir);
-}
-
-static dma_addr_t __iommu_map_page(struct device *dev, struct page *page,
-				   unsigned long offset, size_t size,
-				   enum dma_data_direction dir,
-				   struct dma_attrs *attrs)
-{
-	bool coherent = is_device_dma_coherent(dev);
-	int prot = dma_direction_to_prot(dir, coherent);
-	dma_addr_t dev_addr = iommu_dma_map_page(dev, page, offset, size, prot);
-
-	if (!iommu_dma_mapping_error(dev, dev_addr) &&
-	    !dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-		__iommu_sync_single_for_device(dev, dev_addr, size, dir);
-
-	return dev_addr;
-}
-
-static void __iommu_unmap_page(struct device *dev, dma_addr_t dev_addr,
-			       size_t size, enum dma_data_direction dir,
-			       struct dma_attrs *attrs)
-{
-	if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-		__iommu_sync_single_for_cpu(dev, dev_addr, size, dir);
-
-	iommu_dma_unmap_page(dev, dev_addr, size, dir, attrs);
-}
-
-static void __iommu_sync_sg_for_cpu(struct device *dev,
-				    struct scatterlist *sgl, int nelems,
-				    enum dma_data_direction dir)
-{
-	struct scatterlist *sg;
-	int i;
-
-	if (is_device_dma_coherent(dev))
-		return;
-
-	for_each_sg(sgl, sg, nelems, i)
-		__dma_unmap_area(sg_virt(sg), sg->length, dir);
-}
-
-static void __iommu_sync_sg_for_device(struct device *dev,
-				       struct scatterlist *sgl, int nelems,
-				       enum dma_data_direction dir)
-{
-	struct scatterlist *sg;
-	int i;
-
-	if (is_device_dma_coherent(dev))
-		return;
-
-	for_each_sg(sgl, sg, nelems, i)
-		__dma_map_area(sg_virt(sg), sg->length, dir);
-}
-
-static int __iommu_map_sg_attrs(struct device *dev, struct scatterlist *sgl,
-				int nelems, enum dma_data_direction dir,
-				struct dma_attrs *attrs)
-{
-	bool coherent = is_device_dma_coherent(dev);
-
-	if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-		__iommu_sync_sg_for_device(dev, sgl, nelems, dir);
-
-	return iommu_dma_map_sg(dev, sgl, nelems,
-			dma_direction_to_prot(dir, coherent));
-}
-
-static void __iommu_unmap_sg_attrs(struct device *dev,
-				   struct scatterlist *sgl, int nelems,
-				   enum dma_data_direction dir,
-				   struct dma_attrs *attrs)
-{
-	if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-		__iommu_sync_sg_for_cpu(dev, sgl, nelems, dir);
-
-	iommu_dma_unmap_sg(dev, sgl, nelems, dir, attrs);
-}
-
-static struct dma_map_ops iommu_dma_ops = {
-	.alloc = __iommu_alloc_attrs,
-	.free = __iommu_free_attrs,
-	.mmap = __iommu_mmap_attrs,
-	.get_sgtable = __iommu_get_sgtable,
-	.map_page = __iommu_map_page,
-	.unmap_page = __iommu_unmap_page,
-	.map_sg = __iommu_map_sg_attrs,
-	.unmap_sg = __iommu_unmap_sg_attrs,
-	.sync_single_for_cpu = __iommu_sync_single_for_cpu,
-	.sync_single_for_device = __iommu_sync_single_for_device,
-	.sync_sg_for_cpu = __iommu_sync_sg_for_cpu,
-	.sync_sg_for_device = __iommu_sync_sg_for_device,
-	.dma_supported = iommu_dma_supported,
-	.mapping_error = iommu_dma_mapping_error,
-};
-
-/*
- * TODO: Right now __iommu_setup_dma_ops() gets called too early to do
- * everything it needs to - the device is only partially created and the
- * IOMMU driver hasn't seen it yet, so it can't have a group. Thus we
- * need this delayed attachment dance. Once IOMMU probe ordering is sorted
- * to move the arch_setup_dma_ops() call later, all the notifier bits below
- * become unnecessary, and will go away.
- */
-struct iommu_dma_notifier_data {
-	struct list_head list;
-	struct device *dev;
-	const struct iommu_ops *ops;
-	u64 dma_base;
-	u64 size;
-};
-static LIST_HEAD(iommu_dma_masters);
-static DEFINE_MUTEX(iommu_dma_notifier_lock);
-
-/*
- * Temporarily "borrow" a domain feature flag to to tell if we had to resort
- * to creating our own domain here, in case we need to clean it up again.
- */
-#define __IOMMU_DOMAIN_FAKE_DEFAULT		(1U << 31)
-
-static bool do_iommu_attach(struct device *dev, const struct iommu_ops *ops,
-			   u64 dma_base, u64 size)
-{
-	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
-
-	/*
-	 * Best case: The device is either part of a group which was
-	 * already attached to a domain in a previous call, or it's
-	 * been put in a default DMA domain by the IOMMU core.
-	 */
-	if (!domain) {
-		/*
-		 * Urgh. The IOMMU core isn't going to do default domains
-		 * for non-PCI devices anyway, until it has some means of
-		 * abstracting the entirely implementation-specific
-		 * sideband data/SoC topology/unicorn dust that may or
-		 * may not differentiate upstream masters.
-		 * So until then, HORRIBLE HACKS!
-		 */
-		domain = ops->domain_alloc(IOMMU_DOMAIN_DMA);
-		if (!domain)
-			goto out_no_domain;
-
-		domain->ops = ops;
-		domain->type = IOMMU_DOMAIN_DMA | __IOMMU_DOMAIN_FAKE_DEFAULT;
-
-		if (iommu_attach_device(domain, dev))
-			goto out_put_domain;
-	}
-
-	if (iommu_dma_init_domain(domain, dma_base, size))
-		goto out_detach;
-
-	dev->archdata.dma_ops = &iommu_dma_ops;
-	return true;
-
-out_detach:
-	iommu_detach_device(domain, dev);
-out_put_domain:
-	if (domain->type & __IOMMU_DOMAIN_FAKE_DEFAULT)
-		iommu_domain_free(domain);
-out_no_domain:
-	pr_warn("Failed to set up IOMMU for device %s; retaining platform DMA ops\n",
-		dev_name(dev));
-	return false;
-}
-
-static void queue_iommu_attach(struct device *dev, const struct iommu_ops *ops,
-			      u64 dma_base, u64 size)
-{
-	struct iommu_dma_notifier_data *iommudata;
-
-	iommudata = kzalloc(sizeof(*iommudata), GFP_KERNEL);
-	if (!iommudata)
-		return;
-
-	iommudata->dev = dev;
-	iommudata->ops = ops;
-	iommudata->dma_base = dma_base;
-	iommudata->size = size;
-
-	mutex_lock(&iommu_dma_notifier_lock);
-	list_add(&iommudata->list, &iommu_dma_masters);
-	mutex_unlock(&iommu_dma_notifier_lock);
-}
-
-static int __iommu_attach_notifier(struct notifier_block *nb,
-				   unsigned long action, void *data)
-{
-	struct iommu_dma_notifier_data *master, *tmp;
-
-	if (action != BUS_NOTIFY_ADD_DEVICE)
-		return 0;
-
-	mutex_lock(&iommu_dma_notifier_lock);
-	list_for_each_entry_safe(master, tmp, &iommu_dma_masters, list) {
-		if (do_iommu_attach(master->dev, master->ops,
-				master->dma_base, master->size)) {
-			list_del(&master->list);
-			kfree(master);
-		}
-	}
-	mutex_unlock(&iommu_dma_notifier_lock);
-	return 0;
-}
-
-static int __init register_iommu_dma_ops_notifier(struct bus_type *bus)
-{
-	struct notifier_block *nb = kzalloc(sizeof(*nb), GFP_KERNEL);
-	int ret;
-
-	if (!nb)
-		return -ENOMEM;
-	/*
-	 * The device must be attached to a domain before the driver probe
-	 * routine gets a chance to start allocating DMA buffers. However,
-	 * the IOMMU driver also needs a chance to configure the iommu_group
-	 * via its add_device callback first, so we need to make the attach
-	 * happen between those two points. Since the IOMMU core uses a bus
-	 * notifier with default priority for add_device, do the same but
-	 * with a lower priority to ensure the appropriate ordering.
-	 */
-	nb->notifier_call = __iommu_attach_notifier;
-	nb->priority = -100;
-
-	ret = bus_register_notifier(bus, nb);
-	if (ret) {
-		pr_warn("Failed to register DMA domain notifier; IOMMU DMA ops unavailable on bus '%s'\n",
-			bus->name);
-		kfree(nb);
-	}
-	return ret;
-}
-
-static int __init __iommu_dma_init(void)
-{
-	int ret;
-
-	ret = iommu_dma_init();
-	if (!ret)
-		ret = register_iommu_dma_ops_notifier(&platform_bus_type);
-	if (!ret)
-		ret = register_iommu_dma_ops_notifier(&amba_bustype);
-
-	/* handle devices queued before this arch_initcall */
-	if (!ret)
-		__iommu_attach_notifier(NULL, BUS_NOTIFY_ADD_DEVICE, NULL);
-	return ret;
-}
-arch_initcall(__iommu_dma_init);
-
-static void __iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
-				  const struct iommu_ops *ops)
+void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
+			struct iommu_ops *iommu, bool coherent)
 {
-	struct iommu_group *group;
+	dev->archdata.dma_coherent = coherent;
 
-	if (!ops)
-		return;
-	/*
-	 * TODO: As a concession to the future, we're ready to handle being
-	 * called both early and late (i.e. after bus_add_device). Once all
-	 * the platform bus code is reworked to call us late and the notifier
-	 * junk above goes away, move the body of do_iommu_attach here.
-	 */
-	group = iommu_group_get(dev);
-	if (group) {
-		do_iommu_attach(dev, ops, dma_base, size);
-		iommu_group_put(group);
-	} else {
-		queue_iommu_attach(dev, ops, dma_base, size);
-	}
+	if (!common_iommu_setup_dma_ops(dev, dma_base, size, iommu))
+		arch_set_dma_ops(dev, &swiotlb_dma_ops);
 }
 
 void arch_teardown_dma_ops(struct device *dev)
 {
-	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
-
-	if (domain) {
-		iommu_detach_device(domain, dev);
-		if (domain->type & __IOMMU_DOMAIN_FAKE_DEFAULT)
-			iommu_domain_free(domain);
-	}
-
-	dev->archdata.dma_ops = NULL;
-}
-
-#else
-
-static void __iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
-				  struct iommu_ops *iommu)
-{ }
-
-#endif  /* CONFIG_IOMMU_DMA */
-
-void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
-			struct iommu_ops *iommu, bool coherent)
-{
-	if (!dev->archdata.dma_ops)
-		dev->archdata.dma_ops = &swiotlb_dma_ops;
-
-	dev->archdata.dma_coherent = coherent;
-	__iommu_setup_dma_ops(dev, dma_base, size, iommu);
+	common_iommu_teardown_dma_ops(dev);
 }
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 42fc0c25cf1a..c0dbf765bf45 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -1,7 +1,7 @@
 obj-$(CONFIG_IOMMU_API) += iommu.o
 obj-$(CONFIG_IOMMU_API) += iommu-traces.o
 obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o
-obj-$(CONFIG_IOMMU_DMA) += dma-iommu.o
+obj-$(CONFIG_IOMMU_DMA) += dma-iommu.o dma-iommu-ops.o
 obj-$(CONFIG_IOMMU_IO_PGTABLE) += io-pgtable.o
 obj-$(CONFIG_IOMMU_IO_PGTABLE_LPAE) += io-pgtable-arm.o
 obj-$(CONFIG_IOMMU_IOVA) += iova.o
diff --git a/drivers/iommu/dma-iommu-ops.c b/drivers/iommu/dma-iommu-ops.c
new file mode 100644
index 000000000000..047c47e3c0ab
--- /dev/null
+++ b/drivers/iommu/dma-iommu-ops.c
@@ -0,0 +1,471 @@
+/*
+ * A common IOMMU based DMA-API implementation for ARM and ARM64 architecutes.
+ *
+ * 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/device.h>
+#include <linux/dma-iommu.h>
+#include <linux/gfp.h>
+#include <linux/huge_mm.h>
+#include <linux/iommu.h>
+#include <linux/iova.h>
+#include <linux/mm.h>
+#include <linux/scatterlist.h>
+#include <linux/vmalloc.h>
+
+#include <linux/platform_device.h>
+#include <linux/amba/bus.h>
+
+#include <asm/dma-mapping.h>
+
+static void *__iommu_alloc_attrs(struct device *dev, size_t size,
+				 dma_addr_t *handle, gfp_t gfp,
+				 struct dma_attrs *attrs)
+{
+	bool coherent = is_device_dma_coherent(dev);
+	int ioprot = dma_direction_to_prot(DMA_BIDIRECTIONAL, coherent);
+	size_t iosize = size;
+	void *addr;
+
+	if (WARN(!dev, "cannot create IOMMU mapping for unknown device\n"))
+		return NULL;
+
+	size = PAGE_ALIGN(size);
+
+	/*
+	 * Some drivers rely on this, and we probably don't want the
+	 * possibility of stale kernel data being read by devices anyway.
+	 */
+	gfp |= __GFP_ZERO;
+
+	if (gfpflags_allow_blocking(gfp)) {
+		struct page **pages;
+		pgprot_t prot = arch_get_dma_pgprot(attrs, PAGE_KERNEL,
+						    coherent);
+
+		pages = iommu_dma_alloc(dev, iosize, gfp, ioprot, handle,
+					arch_flush_page);
+		if (!pages)
+			return NULL;
+
+		addr = dma_common_pages_remap(pages, size, VM_USERMAP, prot,
+					      __builtin_return_address(0));
+		if (!addr)
+			iommu_dma_free(dev, pages, iosize, handle);
+	} else {
+		struct page *page;
+		/*
+		 * In atomic context we can't remap anything, so we'll only
+		 * get the virtually contiguous buffer we need by way of a
+		 * physically contiguous allocation.
+		 */
+		if (coherent) {
+			page = alloc_pages(gfp, get_order(size));
+			addr = page ? page_address(page) : NULL;
+		} else {
+			addr = arch_alloc_from_atomic_pool(size, &page, gfp);
+		}
+		if (!addr)
+			return NULL;
+
+		*handle = iommu_dma_map_page(dev, page, 0, iosize, ioprot);
+		if (iommu_dma_mapping_error(dev, *handle)) {
+			if (coherent)
+				__free_pages(page, get_order(size));
+			else
+				arch_free_from_atomic_pool(addr, size);
+			addr = NULL;
+		}
+	}
+	return addr;
+}
+
+static void __iommu_free_attrs(struct device *dev, size_t size, void *cpu_addr,
+			       dma_addr_t handle, struct dma_attrs *attrs)
+{
+	size_t iosize = size;
+
+	size = PAGE_ALIGN(size);
+	/*
+	 * @cpu_addr will be one of 3 things depending on how it was allocated:
+	 * - A remapped array of pages from iommu_dma_alloc(), for all
+	 *   non-atomic allocations.
+	 * - A non-cacheable alias from the atomic pool, for atomic
+	 *   allocations by non-coherent devices.
+	 * - A normal lowmem address, for atomic allocations by
+	 *   coherent devices.
+	 * Hence how dodgy the below logic looks...
+	 */
+	if (arch_in_atomic_pool(cpu_addr, size)) {
+		iommu_dma_unmap_page(dev, handle, iosize, 0, NULL);
+		arch_free_from_atomic_pool(cpu_addr, size);
+	} else if (is_vmalloc_addr(cpu_addr)){
+		struct vm_struct *area = find_vm_area(cpu_addr);
+
+		if (WARN_ON(!area || !area->pages))
+			return;
+		iommu_dma_free(dev, area->pages, iosize, &handle);
+		dma_common_free_remap(cpu_addr, size, VM_USERMAP);
+	} else {
+		iommu_dma_unmap_page(dev, handle, iosize, 0, NULL);
+		__free_pages(virt_to_page(cpu_addr), get_order(size));
+	}
+}
+
+static int __iommu_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
+			      void *cpu_addr, dma_addr_t dma_addr, size_t size,
+			      struct dma_attrs *attrs)
+{
+	struct vm_struct *area;
+	int ret;
+
+	vma->vm_page_prot = arch_get_dma_pgprot(attrs, vma->vm_page_prot,
+					        is_device_dma_coherent(dev));
+
+	if (dma_mmap_from_coherent(dev, vma, cpu_addr, size, &ret))
+		return ret;
+
+	area = find_vm_area(cpu_addr);
+	if (WARN_ON(!area || !area->pages))
+		return -ENXIO;
+
+	return iommu_dma_mmap(area->pages, size, vma);
+}
+
+static int __iommu_get_sgtable(struct device *dev, struct sg_table *sgt,
+			       void *cpu_addr, dma_addr_t dma_addr,
+			       size_t size, struct dma_attrs *attrs)
+{
+	unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
+	struct vm_struct *area = find_vm_area(cpu_addr);
+
+	if (WARN_ON(!area || !area->pages))
+		return -ENXIO;
+
+	return sg_alloc_table_from_pages(sgt, area->pages, count, 0, size,
+					 GFP_KERNEL);
+}
+
+static void __iommu_sync_single_for_cpu(struct device *dev,
+					dma_addr_t dev_addr, size_t size,
+					enum dma_data_direction dir)
+{
+	phys_addr_t phys;
+
+	if (is_device_dma_coherent(dev))
+		return;
+
+	phys = iommu_iova_to_phys(iommu_get_domain_for_dev(dev), dev_addr);
+	arch_dma_unmap_area(phys, size, dir);
+}
+
+static void __iommu_sync_single_for_device(struct device *dev,
+					   dma_addr_t dev_addr, size_t size,
+					   enum dma_data_direction dir)
+{
+	phys_addr_t phys;
+
+	if (is_device_dma_coherent(dev))
+		return;
+
+	phys = iommu_iova_to_phys(iommu_get_domain_for_dev(dev), dev_addr);
+	arch_dma_map_area(phys, size, dir);
+}
+
+static dma_addr_t __iommu_map_page(struct device *dev, struct page *page,
+				   unsigned long offset, size_t size,
+				   enum dma_data_direction dir,
+				   struct dma_attrs *attrs)
+{
+	bool coherent = is_device_dma_coherent(dev);
+	int prot = dma_direction_to_prot(dir, coherent);
+	dma_addr_t dev_addr = iommu_dma_map_page(dev, page, offset, size, prot);
+
+	if (!iommu_dma_mapping_error(dev, dev_addr) &&
+	    !dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		__iommu_sync_single_for_device(dev, dev_addr, size, dir);
+
+	return dev_addr;
+}
+
+static void __iommu_unmap_page(struct device *dev, dma_addr_t dev_addr,
+			       size_t size, enum dma_data_direction dir,
+			       struct dma_attrs *attrs)
+{
+	if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		__iommu_sync_single_for_cpu(dev, dev_addr, size, dir);
+
+	iommu_dma_unmap_page(dev, dev_addr, size, dir, attrs);
+}
+
+static void __iommu_sync_sg_for_cpu(struct device *dev,
+				    struct scatterlist *sgl, int nelems,
+				    enum dma_data_direction dir)
+{
+	struct scatterlist *sg;
+	int i;
+
+	if (is_device_dma_coherent(dev))
+		return;
+
+	for_each_sg(sgl, sg, nelems, i)
+		arch_dma_unmap_area(sg_phys(sg), sg->length, dir);
+}
+
+static void __iommu_sync_sg_for_device(struct device *dev,
+				       struct scatterlist *sgl, int nelems,
+				       enum dma_data_direction dir)
+{
+	struct scatterlist *sg;
+	int i;
+
+	if (is_device_dma_coherent(dev))
+		return;
+
+	for_each_sg(sgl, sg, nelems, i)
+		arch_dma_map_area(sg_phys(sg), sg->length, dir);
+}
+
+static int __iommu_map_sg_attrs(struct device *dev, struct scatterlist *sgl,
+				int nelems, enum dma_data_direction dir,
+				struct dma_attrs *attrs)
+{
+	bool coherent = is_device_dma_coherent(dev);
+
+	if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		__iommu_sync_sg_for_device(dev, sgl, nelems, dir);
+
+	return iommu_dma_map_sg(dev, sgl, nelems,
+			dma_direction_to_prot(dir, coherent));
+}
+
+static void __iommu_unmap_sg_attrs(struct device *dev,
+				   struct scatterlist *sgl, int nelems,
+				   enum dma_data_direction dir,
+				   struct dma_attrs *attrs)
+{
+	if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
+		__iommu_sync_sg_for_cpu(dev, sgl, nelems, dir);
+
+	iommu_dma_unmap_sg(dev, sgl, nelems, dir, attrs);
+}
+
+static struct dma_map_ops iommu_dma_ops = {
+	.alloc = __iommu_alloc_attrs,
+	.free = __iommu_free_attrs,
+	.mmap = __iommu_mmap_attrs,
+	.get_sgtable = __iommu_get_sgtable,
+	.map_page = __iommu_map_page,
+	.unmap_page = __iommu_unmap_page,
+	.map_sg = __iommu_map_sg_attrs,
+	.unmap_sg = __iommu_unmap_sg_attrs,
+	.sync_single_for_cpu = __iommu_sync_single_for_cpu,
+	.sync_single_for_device = __iommu_sync_single_for_device,
+	.sync_sg_for_cpu = __iommu_sync_sg_for_cpu,
+	.sync_sg_for_device = __iommu_sync_sg_for_device,
+	.dma_supported = iommu_dma_supported,
+	.mapping_error = iommu_dma_mapping_error,
+};
+
+/*
+ * TODO: Right now __iommu_setup_dma_ops() gets called too early to do
+ * everything it needs to - the device is only partially created and the
+ * IOMMU driver hasn't seen it yet, so it can't have a group. Thus we
+ * need this delayed attachment dance. Once IOMMU probe ordering is sorted
+ * to move the arch_setup_dma_ops() call later, all the notifier bits below
+ * become unnecessary, and will go away.
+ */
+struct iommu_dma_notifier_data {
+	struct list_head list;
+	struct device *dev;
+	const struct iommu_ops *ops;
+	u64 dma_base;
+	u64 size;
+};
+static LIST_HEAD(iommu_dma_masters);
+static DEFINE_MUTEX(iommu_dma_notifier_lock);
+
+/*
+ * Temporarily "borrow" a domain feature flag to to tell if we had to resort
+ * to creating our own domain here, in case we need to clean it up again.
+ */
+#define __IOMMU_DOMAIN_FAKE_DEFAULT		(1U << 31)
+
+static bool do_iommu_attach(struct device *dev, const struct iommu_ops *ops,
+			   u64 dma_base, u64 size)
+{
+	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
+
+	/*
+	 * Best case: The device is either part of a group which was
+	 * already attached to a domain in a previous call, or it's
+	 * been put in a default DMA domain by the IOMMU core.
+	 */
+	if (!domain) {
+		/*
+		 * Urgh. The IOMMU core isn't going to do default domains
+		 * for non-PCI devices anyway, until it has some means of
+		 * abstracting the entirely implementation-specific
+		 * sideband data/SoC topology/unicorn dust that may or
+		 * may not differentiate upstream masters.
+		 * So until then, HORRIBLE HACKS!
+		 */
+		domain = ops->domain_alloc(IOMMU_DOMAIN_DMA);
+		if (!domain)
+			goto out_no_domain;
+
+		domain->ops = ops;
+		domain->type = IOMMU_DOMAIN_DMA | __IOMMU_DOMAIN_FAKE_DEFAULT;
+
+		if (iommu_attach_device(domain, dev))
+			goto out_put_domain;
+	}
+
+	if (iommu_dma_init_domain(domain, dma_base, size))
+		goto out_detach;
+
+	arch_set_dma_ops(dev, &iommu_dma_ops);
+	return true;
+
+out_detach:
+	iommu_detach_device(domain, dev);
+out_put_domain:
+	if (domain->type & __IOMMU_DOMAIN_FAKE_DEFAULT)
+		iommu_domain_free(domain);
+out_no_domain:
+	pr_warn("Failed to set up IOMMU for device %s; retaining platform DMA ops\n",
+		dev_name(dev));
+	return false;
+}
+
+static void queue_iommu_attach(struct device *dev, const struct iommu_ops *ops,
+			      u64 dma_base, u64 size)
+{
+	struct iommu_dma_notifier_data *iommudata;
+
+	iommudata = kzalloc(sizeof(*iommudata), GFP_KERNEL);
+	if (!iommudata)
+		return;
+
+	iommudata->dev = dev;
+	iommudata->ops = ops;
+	iommudata->dma_base = dma_base;
+	iommudata->size = size;
+
+	mutex_lock(&iommu_dma_notifier_lock);
+	list_add(&iommudata->list, &iommu_dma_masters);
+	mutex_unlock(&iommu_dma_notifier_lock);
+}
+
+static int __iommu_attach_notifier(struct notifier_block *nb,
+				   unsigned long action, void *data)
+{
+	struct iommu_dma_notifier_data *master, *tmp;
+
+	if (action != BUS_NOTIFY_ADD_DEVICE)
+		return 0;
+
+	mutex_lock(&iommu_dma_notifier_lock);
+	list_for_each_entry_safe(master, tmp, &iommu_dma_masters, list) {
+		if (do_iommu_attach(master->dev, master->ops,
+				master->dma_base, master->size)) {
+			list_del(&master->list);
+			kfree(master);
+		}
+	}
+	mutex_unlock(&iommu_dma_notifier_lock);
+	return 0;
+}
+
+static int __init register_iommu_dma_ops_notifier(struct bus_type *bus)
+{
+	struct notifier_block *nb = kzalloc(sizeof(*nb), GFP_KERNEL);
+	int ret;
+
+	if (!nb)
+		return -ENOMEM;
+	/*
+	 * The device must be attached to a domain before the driver probe
+	 * routine gets a chance to start allocating DMA buffers. However,
+	 * the IOMMU driver also needs a chance to configure the iommu_group
+	 * via its add_device callback first, so we need to make the attach
+	 * happen between those two points. Since the IOMMU core uses a bus
+	 * notifier with default priority for add_device, do the same but
+	 * with a lower priority to ensure the appropriate ordering.
+	 */
+	nb->notifier_call = __iommu_attach_notifier;
+	nb->priority = -100;
+
+	ret = bus_register_notifier(bus, nb);
+	if (ret) {
+		pr_warn("Failed to register DMA domain notifier; IOMMU DMA ops unavailable on bus '%s'\n",
+			bus->name);
+		kfree(nb);
+	}
+	return ret;
+}
+
+static int __init __iommu_dma_init(void)
+{
+	int ret;
+
+	ret = iommu_dma_init();
+	if (!ret)
+		ret = register_iommu_dma_ops_notifier(&platform_bus_type);
+	if (!ret)
+		ret = register_iommu_dma_ops_notifier(&amba_bustype);
+
+	/* handle devices queued before this arch_initcall */
+	if (!ret)
+		__iommu_attach_notifier(NULL, BUS_NOTIFY_ADD_DEVICE, NULL);
+	return ret;
+}
+arch_initcall(__iommu_dma_init);
+
+bool common_iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
+				  const struct iommu_ops *ops)
+{
+	struct iommu_group *group;
+
+	if (!ops)
+		return false;
+	/*
+	 * TODO: As a concession to the future, we're ready to handle being
+	 * called both early and late (i.e. after bus_add_device). Once all
+	 * the platform bus code is reworked to call us late and the notifier
+	 * junk above goes away, move the body of do_iommu_attach here.
+	 */
+	group = iommu_group_get(dev);
+	if (group) {
+		do_iommu_attach(dev, ops, dma_base, size);
+		iommu_group_put(group);
+	} else {
+		queue_iommu_attach(dev, ops, dma_base, size);
+	}
+
+	return true;
+}
+
+void common_iommu_teardown_dma_ops(struct device *dev)
+{
+	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
+
+	if (domain) {
+		iommu_detach_device(domain, dev);
+		if (domain->type & __IOMMU_DOMAIN_FAKE_DEFAULT)
+			iommu_domain_free(domain);
+	}
+
+	arch_set_dma_ops(dev, NULL);
+}
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index fc481037478a..01a836c43dc3 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -62,6 +62,10 @@ void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
 int iommu_dma_supported(struct device *dev, u64 mask);
 int iommu_dma_mapping_error(struct device *dev, dma_addr_t dma_addr);
 
+bool common_iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
+				  const struct iommu_ops *ops);
+void common_iommu_teardown_dma_ops(struct device *dev);
+
 #else
 
 struct iommu_domain;
@@ -80,6 +84,16 @@ static inline void iommu_put_dma_cookie(struct iommu_domain *domain)
 {
 }
 
+static inline bool common_iommu_setup_dma_ops(struct device *dev, u64 dma_base,
+					u64 size, const struct iommu_ops *ops)
+{
+	return false;
+}
+
+static inline void common_iommu_teardown_dma_ops(struct device *dev)
+{
+}
+
 #endif	/* CONFIG_IOMMU_DMA */
 #endif	/* __KERNEL__ */
 #endif	/* __DMA_IOMMU_H */
-- 
1.9.2



From m.szyprowski at samsung.com  Fri Feb 19 00:22:44 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Fri, 19 Feb 2016 09:22:44 +0100
Subject: [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM
 architecture
In-Reply-To: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com>
References: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <1455870164-25337-4-git-send-email-m.szyprowski@samsung.com>

This patch replaces ARM-specific IOMMU-based DMA-mapping implementation
with generic IOMMU DMA-mapping code shared with ARM64 architecture. The
side-effect of this change is a switch from bitmap-based IO address space
management to tree-based code. There should be no functional changes
for drivers, which rely on initialization from generic arch_setup_dna_ops()
interface. Code, which used old arm_iommu_* functions must be updated to
new interface.

Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
---
 arch/arm/Kconfig                   |   22 +-
 arch/arm/include/asm/device.h      |    9 -
 arch/arm/include/asm/dma-iommu.h   |   37 --
 arch/arm/include/asm/dma-mapping.h |   59 +-
 arch/arm/mm/dma-mapping.c          | 1158 +-----------------------------------
 drivers/gpu/drm/rockchip/Kconfig   |    1 +
 drivers/iommu/Kconfig              |    1 +
 drivers/media/platform/Kconfig     |    1 +
 8 files changed, 82 insertions(+), 1206 deletions(-)
 delete mode 100644 arch/arm/include/asm/dma-iommu.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4f799e567fc8..ed45f0d63cee 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -107,27 +107,7 @@ config ARM_DMA_USE_IOMMU
 	bool
 	select ARM_HAS_SG_CHAIN
 	select NEED_SG_DMA_LENGTH
-
-if ARM_DMA_USE_IOMMU
-
-config ARM_DMA_IOMMU_ALIGNMENT
-	int "Maximum PAGE_SIZE order of alignment for DMA IOMMU buffers"
-	range 4 9
-	default 8
-	help
-	  DMA mapping framework by default aligns all buffers to the smallest
-	  PAGE_SIZE order which is greater than or equal to the requested buffer
-	  size. This works well for buffers up to a few hundreds kilobytes, but
-	  for larger buffers it just a waste of address space. Drivers which has
-	  relatively small addressing window (like 64Mib) might run out of
-	  virtual space with just a few allocations.
-
-	  With this parameter you can specify the maximum PAGE_SIZE order for
-	  DMA IOMMU buffers. Larger buffers will be aligned only to this
-	  specified order. The order is expressed as a power of two multiplied
-	  by the PAGE_SIZE.
-
-endif
+	select IOMMU_DMA
 
 config MIGHT_HAVE_PCI
 	bool
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index 4111592f0130..6ea939c39cd4 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -14,9 +14,6 @@ struct dev_archdata {
 #ifdef CONFIG_IOMMU_API
 	void *iommu; /* private IOMMU data */
 #endif
-#ifdef CONFIG_ARM_DMA_USE_IOMMU
-	struct dma_iommu_mapping	*mapping;
-#endif
 	bool dma_coherent;
 };
 
@@ -28,10 +25,4 @@ struct pdev_archdata {
 #endif
 };
 
-#ifdef CONFIG_ARM_DMA_USE_IOMMU
-#define to_dma_iommu_mapping(dev) ((dev)->archdata.mapping)
-#else
-#define to_dma_iommu_mapping(dev) NULL
-#endif
-
 #endif
diff --git a/arch/arm/include/asm/dma-iommu.h b/arch/arm/include/asm/dma-iommu.h
deleted file mode 100644
index 2ef282f96651..000000000000
--- a/arch/arm/include/asm/dma-iommu.h
+++ /dev/null
@@ -1,37 +0,0 @@
-#ifndef ASMARM_DMA_IOMMU_H
-#define ASMARM_DMA_IOMMU_H
-
-#ifdef __KERNEL__
-
-#include <linux/mm_types.h>
-#include <linux/scatterlist.h>
-#include <linux/dma-debug.h>
-#include <linux/kmemcheck.h>
-#include <linux/kref.h>
-
-struct dma_iommu_mapping {
-	/* iommu specific data */
-	struct iommu_domain	*domain;
-
-	unsigned long		**bitmaps;	/* array of bitmaps */
-	unsigned int		nr_bitmaps;	/* nr of elements in array */
-	unsigned int		extensions;
-	size_t			bitmap_size;	/* size of a single bitmap */
-	size_t			bits;		/* per bitmap */
-	dma_addr_t		base;
-
-	spinlock_t		lock;
-	struct kref		kref;
-};
-
-struct dma_iommu_mapping *
-arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, u64 size);
-
-void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping);
-
-int arm_iommu_attach_device(struct device *dev,
-					struct dma_iommu_mapping *mapping);
-void arm_iommu_detach_device(struct device *dev);
-
-#endif /* __KERNEL__ */
-#endif
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 6ad1ceda62a5..08bedb0c02c6 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -8,6 +8,7 @@
 #include <linux/dma-attrs.h>
 #include <linux/dma-debug.h>
 
+#include <asm/cacheflush.h>
 #include <asm/memory.h>
 
 #include <xen/xen.h>
@@ -32,7 +33,7 @@ static inline struct dma_map_ops *get_dma_ops(struct device *dev)
 		return __generic_dma_ops(dev);
 }
 
-static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
+static inline void arch_set_dma_ops(struct device *dev, struct dma_map_ops *ops)
 {
 	BUG_ON(!dev);
 	dev->archdata.dma_ops = ops;
@@ -275,5 +276,61 @@ extern int arm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
 		void *cpu_addr, dma_addr_t dma_addr, size_t size,
 		struct dma_attrs *attrs);
 
+/*
+ * The DMA API is built upon the notion of "buffer ownership".  A buffer
+ * is either exclusively owned by the CPU (and therefore may be accessed
+ * by it) or exclusively owned by the DMA device.  These helper functions
+ * represent the transitions between these two ownership states.
+ *
+ * Note, however, that on later ARMs, this notion does not work due to
+ * speculative prefetches.  We model our approach on the assumption that
+ * the CPU does do speculative prefetches, which means we clean caches
+ * before transfers and delay cache invalidation until transfer completion.
+ *
+ */
+extern void __dma_page_cpu_to_dev(struct page *, unsigned long, size_t,
+				  enum dma_data_direction);
+extern void __dma_page_dev_to_cpu(struct page *, unsigned long, size_t,
+				  enum dma_data_direction);
+
+static inline void arch_flush_page(struct device *dev, const void *virt,
+			    phys_addr_t phys)
+{
+	dmac_flush_range(virt, virt + PAGE_SIZE);
+	outer_flush_range(phys, phys + PAGE_SIZE);
+}
+
+static inline void arch_dma_map_area(phys_addr_t phys, size_t size,
+				     enum dma_data_direction dir)
+{
+	unsigned int offset = phys & ~PAGE_MASK;
+	__dma_page_cpu_to_dev(phys_to_page(phys & PAGE_MASK), offset, size, dir);
+}
+
+static inline void arch_dma_unmap_area(phys_addr_t phys, size_t size,
+				       enum dma_data_direction dir)
+{
+	unsigned int offset = phys & ~PAGE_MASK;
+	__dma_page_dev_to_cpu(phys_to_page(phys & PAGE_MASK), offset, size, dir);
+}
+
+static inline pgprot_t arch_get_dma_pgprot(struct dma_attrs *attrs,
+					pgprot_t prot, bool coherent)
+{
+	if (coherent)
+		return prot;
+
+	prot = dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs) ?
+			    pgprot_writecombine(prot) :
+			    pgprot_dmacoherent(prot);
+	return prot;
+}
+
+extern void *arch_alloc_from_atomic_pool(size_t size, struct page **ret_page,
+					 gfp_t flags);
+extern bool arch_in_atomic_pool(void *start, size_t size);
+extern int arch_free_from_atomic_pool(void *start, size_t size);
+
+
 #endif /* __KERNEL__ */
 #endif
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 0eca3812527e..5d497f3c5924 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -20,6 +20,7 @@
 #include <linux/device.h>
 #include <linux/dma-mapping.h>
 #include <linux/dma-contiguous.h>
+#include <linux/dma-iommu.h>
 #include <linux/highmem.h>
 #include <linux/memblock.h>
 #include <linux/slab.h>
@@ -34,7 +35,6 @@
 #include <asm/cacheflush.h>
 #include <asm/tlbflush.h>
 #include <asm/mach/arch.h>
-#include <asm/dma-iommu.h>
 #include <asm/mach/map.h>
 #include <asm/system_info.h>
 #include <asm/dma-contiguous.h>
@@ -42,23 +42,6 @@
 #include "dma.h"
 #include "mm.h"
 
-/*
- * The DMA API is built upon the notion of "buffer ownership".  A buffer
- * is either exclusively owned by the CPU (and therefore may be accessed
- * by it) or exclusively owned by the DMA device.  These helper functions
- * represent the transitions between these two ownership states.
- *
- * Note, however, that on later ARMs, this notion does not work due to
- * speculative prefetches.  We model our approach on the assumption that
- * the CPU does do speculative prefetches, which means we clean caches
- * before transfers and delay cache invalidation until transfer completion.
- *
- */
-static void __dma_page_cpu_to_dev(struct page *, unsigned long,
-		size_t, enum dma_data_direction);
-static void __dma_page_dev_to_cpu(struct page *, unsigned long,
-		size_t, enum dma_data_direction);
-
 /**
  * arm_dma_map_page - map a portion of a page for streaming DMA
  * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
@@ -492,7 +475,7 @@ static void *__alloc_remap_buffer(struct device *dev, size_t size, gfp_t gfp,
 	return ptr;
 }
 
-static void *__alloc_from_pool(size_t size, struct page **ret_page)
+void *arch_alloc_from_atomic_pool(size_t size, struct page **ret_page, gfp_t gfp)
 {
 	unsigned long val;
 	void *ptr = NULL;
@@ -513,14 +496,14 @@ static void *__alloc_from_pool(size_t size, struct page **ret_page)
 	return ptr;
 }
 
-static bool __in_atomic_pool(void *start, size_t size)
+bool arch_in_atomic_pool(void *start, size_t size)
 {
 	return addr_in_gen_pool(atomic_pool, (unsigned long)start, size);
 }
 
-static int __free_from_pool(void *start, size_t size)
+int arch_free_from_atomic_pool(void *start, size_t size)
 {
-	if (!__in_atomic_pool(start, size))
+	if (!arch_in_atomic_pool(start, size))
 		return 0;
 
 	gen_pool_free(atomic_pool, (unsigned long)start, size);
@@ -574,25 +557,21 @@ static void __free_from_contiguous(struct device *dev, struct page *page,
 	dma_release_from_contiguous(dev, page, size >> PAGE_SHIFT);
 }
 
-static inline pgprot_t __get_dma_pgprot(struct dma_attrs *attrs, pgprot_t prot)
-{
-	prot = dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs) ?
-			    pgprot_writecombine(prot) :
-			    pgprot_dmacoherent(prot);
-	return prot;
-}
-
 #define nommu() 0
 
+#define __alloc_from_pool(size, ret, gfp) arch_alloc_from_atomic_pool(size, ret, gfp)
+#define __free_from_pool(addr, size) arch_free_from_atomic_pool(addr, size)
+#define __get_dma_pgprot(attrs, prot, coherent) arch_get_dma_pgprot(attrs, prot, coherent)
+
 #else	/* !CONFIG_MMU */
 
 #define nommu() 1
 
-#define __get_dma_pgprot(attrs, prot)				__pgprot(0)
+#define __get_dma_pgprot(attrs, prot, coherent)				__pgprot(0)
 #define __alloc_remap_buffer(dev, size, gfp, prot, ret, c, wv)	NULL
-#define __alloc_from_pool(size, ret_page)			NULL
+#define __alloc_from_pool(size, ret_page, gfp)			NULL
 #define __alloc_from_contiguous(dev, size, prot, ret, c, wv)	NULL
-#define __free_from_pool(cpu_addr, size)			0
+#define __free_from_atomic_pool(cpu_addr, size)			0
 #define __free_from_contiguous(dev, page, cpu_addr, size, wv)	do { } while (0)
 #define __dma_free_remap(cpu_addr, size)			do { } while (0)
 
@@ -657,7 +636,7 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
 	else if (is_coherent)
 		addr = __alloc_simple_buffer(dev, size, gfp, &page);
 	else if (!gfpflags_allow_blocking(gfp))
-		addr = __alloc_from_pool(size, &page);
+		addr = __alloc_from_pool(size, &page, gfp);
 	else
 		addr = __alloc_remap_buffer(dev, size, gfp, prot, &page,
 					    caller, want_vaddr);
@@ -675,7 +654,7 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
 void *arm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
 		    gfp_t gfp, struct dma_attrs *attrs)
 {
-	pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL);
+	pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL, false);
 
 	return __dma_alloc(dev, size, handle, gfp, prot, false,
 			   attrs, __builtin_return_address(0));
@@ -728,7 +707,7 @@ int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
 		 struct dma_attrs *attrs)
 {
 #ifdef CONFIG_MMU
-	vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot);
+	vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot, false);
 #endif	/* CONFIG_MMU */
 	return __arm_dma_mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
 }
@@ -842,7 +821,7 @@ static void dma_cache_maint_page(struct page *page, unsigned long offset,
  * platforms with CONFIG_DMABOUNCE.
  * Use the driver DMA support - see dma-mapping.h (dma_sync_*)
  */
-static void __dma_page_cpu_to_dev(struct page *page, unsigned long off,
+void __dma_page_cpu_to_dev(struct page *page, unsigned long off,
 	size_t size, enum dma_data_direction dir)
 {
 	phys_addr_t paddr;
@@ -858,7 +837,7 @@ static void __dma_page_cpu_to_dev(struct page *page, unsigned long off,
 	/* FIXME: non-speculating: flush on bidirectional mappings? */
 }
 
-static void __dma_page_dev_to_cpu(struct page *page, unsigned long off,
+void __dma_page_dev_to_cpu(struct page *page, unsigned long off,
 	size_t size, enum dma_data_direction dir)
 {
 	phys_addr_t paddr = page_to_phys(page) + off;
@@ -1023,1098 +1002,6 @@ static int __init dma_debug_do_init(void)
 }
 fs_initcall(dma_debug_do_init);
 
-#ifdef CONFIG_ARM_DMA_USE_IOMMU
-
-/* IOMMU */
-
-static int extend_iommu_mapping(struct dma_iommu_mapping *mapping);
-
-static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping,
-				      size_t size)
-{
-	unsigned int order = get_order(size);
-	unsigned int align = 0;
-	unsigned int count, start;
-	size_t mapping_size = mapping->bits << PAGE_SHIFT;
-	unsigned long flags;
-	dma_addr_t iova;
-	int i;
-
-	if (order > CONFIG_ARM_DMA_IOMMU_ALIGNMENT)
-		order = CONFIG_ARM_DMA_IOMMU_ALIGNMENT;
-
-	count = PAGE_ALIGN(size) >> PAGE_SHIFT;
-	align = (1 << order) - 1;
-
-	spin_lock_irqsave(&mapping->lock, flags);
-	for (i = 0; i < mapping->nr_bitmaps; i++) {
-		start = bitmap_find_next_zero_area(mapping->bitmaps[i],
-				mapping->bits, 0, count, align);
-
-		if (start > mapping->bits)
-			continue;
-
-		bitmap_set(mapping->bitmaps[i], start, count);
-		break;
-	}
-
-	/*
-	 * No unused range found. Try to extend the existing mapping
-	 * and perform a second attempt to reserve an IO virtual
-	 * address range of size bytes.
-	 */
-	if (i == mapping->nr_bitmaps) {
-		if (extend_iommu_mapping(mapping)) {
-			spin_unlock_irqrestore(&mapping->lock, flags);
-			return DMA_ERROR_CODE;
-		}
-
-		start = bitmap_find_next_zero_area(mapping->bitmaps[i],
-				mapping->bits, 0, count, align);
-
-		if (start > mapping->bits) {
-			spin_unlock_irqrestore(&mapping->lock, flags);
-			return DMA_ERROR_CODE;
-		}
-
-		bitmap_set(mapping->bitmaps[i], start, count);
-	}
-	spin_unlock_irqrestore(&mapping->lock, flags);
-
-	iova = mapping->base + (mapping_size * i);
-	iova += start << PAGE_SHIFT;
-
-	return iova;
-}
-
-static inline void __free_iova(struct dma_iommu_mapping *mapping,
-			       dma_addr_t addr, size_t size)
-{
-	unsigned int start, count;
-	size_t mapping_size = mapping->bits << PAGE_SHIFT;
-	unsigned long flags;
-	dma_addr_t bitmap_base;
-	u32 bitmap_index;
-
-	if (!size)
-		return;
-
-	bitmap_index = (u32) (addr - mapping->base) / (u32) mapping_size;
-	BUG_ON(addr < mapping->base || bitmap_index > mapping->extensions);
-
-	bitmap_base = mapping->base + mapping_size * bitmap_index;
-
-	start = (addr - bitmap_base) >>	PAGE_SHIFT;
-
-	if (addr + size > bitmap_base + mapping_size) {
-		/*
-		 * The address range to be freed reaches into the iova
-		 * range of the next bitmap. This should not happen as
-		 * we don't allow this in __alloc_iova (at the
-		 * moment).
-		 */
-		BUG();
-	} else
-		count = size >> PAGE_SHIFT;
-
-	spin_lock_irqsave(&mapping->lock, flags);
-	bitmap_clear(mapping->bitmaps[bitmap_index], start, count);
-	spin_unlock_irqrestore(&mapping->lock, flags);
-}
-
-static struct page **__iommu_alloc_buffer(struct device *dev, size_t size,
-					  gfp_t gfp, struct dma_attrs *attrs)
-{
-	struct page **pages;
-	int count = size >> PAGE_SHIFT;
-	int array_size = count * sizeof(struct page *);
-	int i = 0;
-
-	if (array_size <= PAGE_SIZE)
-		pages = kzalloc(array_size, GFP_KERNEL);
-	else
-		pages = vzalloc(array_size);
-	if (!pages)
-		return NULL;
-
-	if (dma_get_attr(DMA_ATTR_FORCE_CONTIGUOUS, attrs))
-	{
-		unsigned long order = get_order(size);
-		struct page *page;
-
-		page = dma_alloc_from_contiguous(dev, count, order);
-		if (!page)
-			goto error;
-
-		__dma_clear_buffer(page, size);
-
-		for (i = 0; i < count; i++)
-			pages[i] = page + i;
-
-		return pages;
-	}
-
-	/*
-	 * IOMMU can map any pages, so himem can also be used here
-	 */
-	gfp |= __GFP_NOWARN | __GFP_HIGHMEM;
-
-	while (count) {
-		int j, order;
-
-		for (order = __fls(count); order > 0; --order) {
-			/*
-			 * We do not want OOM killer to be invoked as long
-			 * as we can fall back to single pages, so we force
-			 * __GFP_NORETRY for orders higher than zero.
-			 */
-			pages[i] = alloc_pages(gfp | __GFP_NORETRY, order);
-			if (pages[i])
-				break;
-		}
-
-		if (!pages[i]) {
-			/*
-			 * Fall back to single page allocation.
-			 * Might invoke OOM killer as last resort.
-			 */
-			pages[i] = alloc_pages(gfp, 0);
-			if (!pages[i])
-				goto error;
-		}
-
-		if (order) {
-			split_page(pages[i], order);
-			j = 1 << order;
-			while (--j)
-				pages[i + j] = pages[i] + j;
-		}
-
-		__dma_clear_buffer(pages[i], PAGE_SIZE << order);
-		i += 1 << order;
-		count -= 1 << order;
-	}
-
-	return pages;
-error:
-	while (i--)
-		if (pages[i])
-			__free_pages(pages[i], 0);
-	kvfree(pages);
-	return NULL;
-}
-
-static int __iommu_free_buffer(struct device *dev, struct page **pages,
-			       size_t size, struct dma_attrs *attrs)
-{
-	int count = size >> PAGE_SHIFT;
-	int i;
-
-	if (dma_get_attr(DMA_ATTR_FORCE_CONTIGUOUS, attrs)) {
-		dma_release_from_contiguous(dev, pages[0], count);
-	} else {
-		for (i = 0; i < count; i++)
-			if (pages[i])
-				__free_pages(pages[i], 0);
-	}
-
-	kvfree(pages);
-	return 0;
-}
-
-/*
- * Create a CPU mapping for a specified pages
- */
-static void *
-__iommu_alloc_remap(struct page **pages, size_t size, gfp_t gfp, pgprot_t prot,
-		    const void *caller)
-{
-	return dma_common_pages_remap(pages, size,
-			VM_ARM_DMA_CONSISTENT | VM_USERMAP, prot, caller);
-}
-
-/*
- * Create a mapping in device IO address space for specified pages
- */
-static dma_addr_t
-__iommu_create_mapping(struct device *dev, struct page **pages, size_t size)
-{
-	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-	unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
-	dma_addr_t dma_addr, iova;
-	int i;
-
-	dma_addr = __alloc_iova(mapping, size);
-	if (dma_addr == DMA_ERROR_CODE)
-		return dma_addr;
-
-	iova = dma_addr;
-	for (i = 0; i < count; ) {
-		int ret;
-
-		unsigned int next_pfn = page_to_pfn(pages[i]) + 1;
-		phys_addr_t phys = page_to_phys(pages[i]);
-		unsigned int len, j;
-
-		for (j = i + 1; j < count; j++, next_pfn++)
-			if (page_to_pfn(pages[j]) != next_pfn)
-				break;
-
-		len = (j - i) << PAGE_SHIFT;
-		ret = iommu_map(mapping->domain, iova, phys, len,
-				IOMMU_READ|IOMMU_WRITE);
-		if (ret < 0)
-			goto fail;
-		iova += len;
-		i = j;
-	}
-	return dma_addr;
-fail:
-	iommu_unmap(mapping->domain, dma_addr, iova-dma_addr);
-	__free_iova(mapping, dma_addr, size);
-	return DMA_ERROR_CODE;
-}
-
-static int __iommu_remove_mapping(struct device *dev, dma_addr_t iova, size_t size)
-{
-	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-
-	/*
-	 * add optional in-page offset from iova to size and align
-	 * result to page size
-	 */
-	size = PAGE_ALIGN((iova & ~PAGE_MASK) + size);
-	iova &= PAGE_MASK;
-
-	iommu_unmap(mapping->domain, iova, size);
-	__free_iova(mapping, iova, size);
-	return 0;
-}
-
-static struct page **__atomic_get_pages(void *addr)
-{
-	struct page *page;
-	phys_addr_t phys;
-
-	phys = gen_pool_virt_to_phys(atomic_pool, (unsigned long)addr);
-	page = phys_to_page(phys);
-
-	return (struct page **)page;
-}
-
-static struct page **__iommu_get_pages(void *cpu_addr, struct dma_attrs *attrs)
-{
-	struct vm_struct *area;
-
-	if (__in_atomic_pool(cpu_addr, PAGE_SIZE))
-		return __atomic_get_pages(cpu_addr);
-
-	if (dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs))
-		return cpu_addr;
-
-	area = find_vm_area(cpu_addr);
-	if (area && (area->flags & VM_ARM_DMA_CONSISTENT))
-		return area->pages;
-	return NULL;
-}
-
-static void *__iommu_alloc_atomic(struct device *dev, size_t size,
-				  dma_addr_t *handle)
-{
-	struct page *page;
-	void *addr;
-
-	addr = __alloc_from_pool(size, &page);
-	if (!addr)
-		return NULL;
-
-	*handle = __iommu_create_mapping(dev, &page, size);
-	if (*handle == DMA_ERROR_CODE)
-		goto err_mapping;
-
-	return addr;
-
-err_mapping:
-	__free_from_pool(addr, size);
-	return NULL;
-}
-
-static void __iommu_free_atomic(struct device *dev, void *cpu_addr,
-				dma_addr_t handle, size_t size)
-{
-	__iommu_remove_mapping(dev, handle, size);
-	__free_from_pool(cpu_addr, size);
-}
-
-static void *arm_iommu_alloc_attrs(struct device *dev, size_t size,
-	    dma_addr_t *handle, gfp_t gfp, struct dma_attrs *attrs)
-{
-	pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL);
-	struct page **pages;
-	void *addr = NULL;
-
-	*handle = DMA_ERROR_CODE;
-	size = PAGE_ALIGN(size);
-
-	if (!gfpflags_allow_blocking(gfp))
-		return __iommu_alloc_atomic(dev, size, handle);
-
-	/*
-	 * Following is a work-around (a.k.a. hack) to prevent pages
-	 * with __GFP_COMP being passed to split_page() which cannot
-	 * handle them.  The real problem is that this flag probably
-	 * should be 0 on ARM as it is not supported on this
-	 * platform; see CONFIG_HUGETLBFS.
-	 */
-	gfp &= ~(__GFP_COMP);
-
-	pages = __iommu_alloc_buffer(dev, size, gfp, attrs);
-	if (!pages)
-		return NULL;
-
-	*handle = __iommu_create_mapping(dev, pages, size);
-	if (*handle == DMA_ERROR_CODE)
-		goto err_buffer;
-
-	if (dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs))
-		return pages;
-
-	addr = __iommu_alloc_remap(pages, size, gfp, prot,
-				   __builtin_return_address(0));
-	if (!addr)
-		goto err_mapping;
-
-	return addr;
-
-err_mapping:
-	__iommu_remove_mapping(dev, *handle, size);
-err_buffer:
-	__iommu_free_buffer(dev, pages, size, attrs);
-	return NULL;
-}
-
-static int arm_iommu_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
-		    void *cpu_addr, dma_addr_t dma_addr, size_t size,
-		    struct dma_attrs *attrs)
-{
-	unsigned long uaddr = vma->vm_start;
-	unsigned long usize = vma->vm_end - vma->vm_start;
-	struct page **pages = __iommu_get_pages(cpu_addr, attrs);
-	unsigned long nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
-	unsigned long off = vma->vm_pgoff;
-
-	vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot);
-
-	if (!pages)
-		return -ENXIO;
-
-	if (off >= nr_pages || (usize >> PAGE_SHIFT) > nr_pages - off)
-		return -ENXIO;
-
-	pages += off;
-
-	do {
-		int ret = vm_insert_page(vma, uaddr, *pages++);
-		if (ret) {
-			pr_err("Remapping memory failed: %d\n", ret);
-			return ret;
-		}
-		uaddr += PAGE_SIZE;
-		usize -= PAGE_SIZE;
-	} while (usize > 0);
-
-	return 0;
-}
-
-/*
- * free a page as defined by the above mapping.
- * Must not be called with IRQs disabled.
- */
-void arm_iommu_free_attrs(struct device *dev, size_t size, void *cpu_addr,
-			  dma_addr_t handle, struct dma_attrs *attrs)
-{
-	struct page **pages;
-	size = PAGE_ALIGN(size);
-
-	if (__in_atomic_pool(cpu_addr, size)) {
-		__iommu_free_atomic(dev, cpu_addr, handle, size);
-		return;
-	}
-
-	pages = __iommu_get_pages(cpu_addr, attrs);
-	if (!pages) {
-		WARN(1, "trying to free invalid coherent area: %p\n", cpu_addr);
-		return;
-	}
-
-	if (!dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs)) {
-		dma_common_free_remap(cpu_addr, size,
-			VM_ARM_DMA_CONSISTENT | VM_USERMAP);
-	}
-
-	__iommu_remove_mapping(dev, handle, size);
-	__iommu_free_buffer(dev, pages, size, attrs);
-}
-
-static int arm_iommu_get_sgtable(struct device *dev, struct sg_table *sgt,
-				 void *cpu_addr, dma_addr_t dma_addr,
-				 size_t size, struct dma_attrs *attrs)
-{
-	unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
-	struct page **pages = __iommu_get_pages(cpu_addr, attrs);
-
-	if (!pages)
-		return -ENXIO;
-
-	return sg_alloc_table_from_pages(sgt, pages, count, 0, size,
-					 GFP_KERNEL);
-}
-
-static int __dma_direction_to_prot(enum dma_data_direction dir)
-{
-	int prot;
-
-	switch (dir) {
-	case DMA_BIDIRECTIONAL:
-		prot = IOMMU_READ | IOMMU_WRITE;
-		break;
-	case DMA_TO_DEVICE:
-		prot = IOMMU_READ;
-		break;
-	case DMA_FROM_DEVICE:
-		prot = IOMMU_WRITE;
-		break;
-	default:
-		prot = 0;
-	}
-
-	return prot;
-}
-
-/*
- * Map a part of the scatter-gather list into contiguous io address space
- */
-static int __map_sg_chunk(struct device *dev, struct scatterlist *sg,
-			  size_t size, dma_addr_t *handle,
-			  enum dma_data_direction dir, struct dma_attrs *attrs,
-			  bool is_coherent)
-{
-	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-	dma_addr_t iova, iova_base;
-	int ret = 0;
-	unsigned int count;
-	struct scatterlist *s;
-	int prot;
-
-	size = PAGE_ALIGN(size);
-	*handle = DMA_ERROR_CODE;
-
-	iova_base = iova = __alloc_iova(mapping, size);
-	if (iova == DMA_ERROR_CODE)
-		return -ENOMEM;
-
-	for (count = 0, s = sg; count < (size >> PAGE_SHIFT); s = sg_next(s)) {
-		phys_addr_t phys = page_to_phys(sg_page(s));
-		unsigned int len = PAGE_ALIGN(s->offset + s->length);
-
-		if (!is_coherent &&
-			!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-			__dma_page_cpu_to_dev(sg_page(s), s->offset, s->length, dir);
-
-		prot = __dma_direction_to_prot(dir);
-
-		ret = iommu_map(mapping->domain, iova, phys, len, prot);
-		if (ret < 0)
-			goto fail;
-		count += len >> PAGE_SHIFT;
-		iova += len;
-	}
-	*handle = iova_base;
-
-	return 0;
-fail:
-	iommu_unmap(mapping->domain, iova_base, count * PAGE_SIZE);
-	__free_iova(mapping, iova_base, size);
-	return ret;
-}
-
-static int __iommu_map_sg(struct device *dev, struct scatterlist *sg, int nents,
-		     enum dma_data_direction dir, struct dma_attrs *attrs,
-		     bool is_coherent)
-{
-	struct scatterlist *s = sg, *dma = sg, *start = sg;
-	int i, count = 0;
-	unsigned int offset = s->offset;
-	unsigned int size = s->offset + s->length;
-	unsigned int max = dma_get_max_seg_size(dev);
-
-	for (i = 1; i < nents; i++) {
-		s = sg_next(s);
-
-		s->dma_address = DMA_ERROR_CODE;
-		s->dma_length = 0;
-
-		if (s->offset || (size & ~PAGE_MASK) || size + s->length > max) {
-			if (__map_sg_chunk(dev, start, size, &dma->dma_address,
-			    dir, attrs, is_coherent) < 0)
-				goto bad_mapping;
-
-			dma->dma_address += offset;
-			dma->dma_length = size - offset;
-
-			size = offset = s->offset;
-			start = s;
-			dma = sg_next(dma);
-			count += 1;
-		}
-		size += s->length;
-	}
-	if (__map_sg_chunk(dev, start, size, &dma->dma_address, dir, attrs,
-		is_coherent) < 0)
-		goto bad_mapping;
-
-	dma->dma_address += offset;
-	dma->dma_length = size - offset;
-
-	return count+1;
-
-bad_mapping:
-	for_each_sg(sg, s, count, i)
-		__iommu_remove_mapping(dev, sg_dma_address(s), sg_dma_len(s));
-	return 0;
-}
-
-/**
- * arm_coherent_iommu_map_sg - map a set of SG buffers for streaming mode DMA
- * @dev: valid struct device pointer
- * @sg: list of buffers
- * @nents: number of buffers to map
- * @dir: DMA transfer direction
- *
- * Map a set of i/o coherent buffers described by scatterlist in streaming
- * mode for DMA. The scatter gather list elements are merged together (if
- * possible) and tagged with the appropriate dma address and length. They are
- * obtained via sg_dma_{address,length}.
- */
-int arm_coherent_iommu_map_sg(struct device *dev, struct scatterlist *sg,
-		int nents, enum dma_data_direction dir, struct dma_attrs *attrs)
-{
-	return __iommu_map_sg(dev, sg, nents, dir, attrs, true);
-}
-
-/**
- * arm_iommu_map_sg - map a set of SG buffers for streaming mode DMA
- * @dev: valid struct device pointer
- * @sg: list of buffers
- * @nents: number of buffers to map
- * @dir: DMA transfer direction
- *
- * Map a set of buffers described by scatterlist in streaming mode for DMA.
- * The scatter gather list elements are merged together (if possible) and
- * tagged with the appropriate dma address and length. They are obtained via
- * sg_dma_{address,length}.
- */
-int arm_iommu_map_sg(struct device *dev, struct scatterlist *sg,
-		int nents, enum dma_data_direction dir, struct dma_attrs *attrs)
-{
-	return __iommu_map_sg(dev, sg, nents, dir, attrs, false);
-}
-
-static void __iommu_unmap_sg(struct device *dev, struct scatterlist *sg,
-		int nents, enum dma_data_direction dir, struct dma_attrs *attrs,
-		bool is_coherent)
-{
-	struct scatterlist *s;
-	int i;
-
-	for_each_sg(sg, s, nents, i) {
-		if (sg_dma_len(s))
-			__iommu_remove_mapping(dev, sg_dma_address(s),
-					       sg_dma_len(s));
-		if (!is_coherent &&
-		    !dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-			__dma_page_dev_to_cpu(sg_page(s), s->offset,
-					      s->length, dir);
-	}
-}
-
-/**
- * arm_coherent_iommu_unmap_sg - unmap a set of SG buffers mapped by dma_map_sg
- * @dev: valid struct device pointer
- * @sg: list of buffers
- * @nents: number of buffers to unmap (same as was passed to dma_map_sg)
- * @dir: DMA transfer direction (same as was passed to dma_map_sg)
- *
- * Unmap a set of streaming mode DMA translations.  Again, CPU access
- * rules concerning calls here are the same as for dma_unmap_single().
- */
-void arm_coherent_iommu_unmap_sg(struct device *dev, struct scatterlist *sg,
-		int nents, enum dma_data_direction dir, struct dma_attrs *attrs)
-{
-	__iommu_unmap_sg(dev, sg, nents, dir, attrs, true);
-}
-
-/**
- * arm_iommu_unmap_sg - unmap a set of SG buffers mapped by dma_map_sg
- * @dev: valid struct device pointer
- * @sg: list of buffers
- * @nents: number of buffers to unmap (same as was passed to dma_map_sg)
- * @dir: DMA transfer direction (same as was passed to dma_map_sg)
- *
- * Unmap a set of streaming mode DMA translations.  Again, CPU access
- * rules concerning calls here are the same as for dma_unmap_single().
- */
-void arm_iommu_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
-			enum dma_data_direction dir, struct dma_attrs *attrs)
-{
-	__iommu_unmap_sg(dev, sg, nents, dir, attrs, false);
-}
-
-/**
- * arm_iommu_sync_sg_for_cpu
- * @dev: valid struct device pointer
- * @sg: list of buffers
- * @nents: number of buffers to map (returned from dma_map_sg)
- * @dir: DMA transfer direction (same as was passed to dma_map_sg)
- */
-void arm_iommu_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg,
-			int nents, enum dma_data_direction dir)
-{
-	struct scatterlist *s;
-	int i;
-
-	for_each_sg(sg, s, nents, i)
-		__dma_page_dev_to_cpu(sg_page(s), s->offset, s->length, dir);
-
-}
-
-/**
- * arm_iommu_sync_sg_for_device
- * @dev: valid struct device pointer
- * @sg: list of buffers
- * @nents: number of buffers to map (returned from dma_map_sg)
- * @dir: DMA transfer direction (same as was passed to dma_map_sg)
- */
-void arm_iommu_sync_sg_for_device(struct device *dev, struct scatterlist *sg,
-			int nents, enum dma_data_direction dir)
-{
-	struct scatterlist *s;
-	int i;
-
-	for_each_sg(sg, s, nents, i)
-		__dma_page_cpu_to_dev(sg_page(s), s->offset, s->length, dir);
-}
-
-
-/**
- * arm_coherent_iommu_map_page
- * @dev: valid struct device pointer
- * @page: page that buffer resides in
- * @offset: offset into page for start of buffer
- * @size: size of buffer to map
- * @dir: DMA transfer direction
- *
- * Coherent IOMMU aware version of arm_dma_map_page()
- */
-static dma_addr_t arm_coherent_iommu_map_page(struct device *dev, struct page *page,
-	     unsigned long offset, size_t size, enum dma_data_direction dir,
-	     struct dma_attrs *attrs)
-{
-	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-	dma_addr_t dma_addr;
-	int ret, prot, len = PAGE_ALIGN(size + offset);
-
-	dma_addr = __alloc_iova(mapping, len);
-	if (dma_addr == DMA_ERROR_CODE)
-		return dma_addr;
-
-	prot = __dma_direction_to_prot(dir);
-
-	ret = iommu_map(mapping->domain, dma_addr, page_to_phys(page), len, prot);
-	if (ret < 0)
-		goto fail;
-
-	return dma_addr + offset;
-fail:
-	__free_iova(mapping, dma_addr, len);
-	return DMA_ERROR_CODE;
-}
-
-/**
- * arm_iommu_map_page
- * @dev: valid struct device pointer
- * @page: page that buffer resides in
- * @offset: offset into page for start of buffer
- * @size: size of buffer to map
- * @dir: DMA transfer direction
- *
- * IOMMU aware version of arm_dma_map_page()
- */
-static dma_addr_t arm_iommu_map_page(struct device *dev, struct page *page,
-	     unsigned long offset, size_t size, enum dma_data_direction dir,
-	     struct dma_attrs *attrs)
-{
-	if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-		__dma_page_cpu_to_dev(page, offset, size, dir);
-
-	return arm_coherent_iommu_map_page(dev, page, offset, size, dir, attrs);
-}
-
-/**
- * arm_coherent_iommu_unmap_page
- * @dev: valid struct device pointer
- * @handle: DMA address of buffer
- * @size: size of buffer (same as passed to dma_map_page)
- * @dir: DMA transfer direction (same as passed to dma_map_page)
- *
- * Coherent IOMMU aware version of arm_dma_unmap_page()
- */
-static void arm_coherent_iommu_unmap_page(struct device *dev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir,
-		struct dma_attrs *attrs)
-{
-	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-	dma_addr_t iova = handle & PAGE_MASK;
-	int offset = handle & ~PAGE_MASK;
-	int len = PAGE_ALIGN(size + offset);
-
-	if (!iova)
-		return;
-
-	iommu_unmap(mapping->domain, iova, len);
-	__free_iova(mapping, iova, len);
-}
-
-/**
- * arm_iommu_unmap_page
- * @dev: valid struct device pointer
- * @handle: DMA address of buffer
- * @size: size of buffer (same as passed to dma_map_page)
- * @dir: DMA transfer direction (same as passed to dma_map_page)
- *
- * IOMMU aware version of arm_dma_unmap_page()
- */
-static void arm_iommu_unmap_page(struct device *dev, dma_addr_t handle,
-		size_t size, enum dma_data_direction dir,
-		struct dma_attrs *attrs)
-{
-	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-	dma_addr_t iova = handle & PAGE_MASK;
-	struct page *page = phys_to_page(iommu_iova_to_phys(mapping->domain, iova));
-	int offset = handle & ~PAGE_MASK;
-	int len = PAGE_ALIGN(size + offset);
-
-	if (!iova)
-		return;
-
-	if (!dma_get_attr(DMA_ATTR_SKIP_CPU_SYNC, attrs))
-		__dma_page_dev_to_cpu(page, offset, size, dir);
-
-	iommu_unmap(mapping->domain, iova, len);
-	__free_iova(mapping, iova, len);
-}
-
-static void arm_iommu_sync_single_for_cpu(struct device *dev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-	dma_addr_t iova = handle & PAGE_MASK;
-	struct page *page = phys_to_page(iommu_iova_to_phys(mapping->domain, iova));
-	unsigned int offset = handle & ~PAGE_MASK;
-
-	if (!iova)
-		return;
-
-	__dma_page_dev_to_cpu(page, offset, size, dir);
-}
-
-static void arm_iommu_sync_single_for_device(struct device *dev,
-		dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-	dma_addr_t iova = handle & PAGE_MASK;
-	struct page *page = phys_to_page(iommu_iova_to_phys(mapping->domain, iova));
-	unsigned int offset = handle & ~PAGE_MASK;
-
-	if (!iova)
-		return;
-
-	__dma_page_cpu_to_dev(page, offset, size, dir);
-}
-
-struct dma_map_ops iommu_ops = {
-	.alloc		= arm_iommu_alloc_attrs,
-	.free		= arm_iommu_free_attrs,
-	.mmap		= arm_iommu_mmap_attrs,
-	.get_sgtable	= arm_iommu_get_sgtable,
-
-	.map_page		= arm_iommu_map_page,
-	.unmap_page		= arm_iommu_unmap_page,
-	.sync_single_for_cpu	= arm_iommu_sync_single_for_cpu,
-	.sync_single_for_device	= arm_iommu_sync_single_for_device,
-
-	.map_sg			= arm_iommu_map_sg,
-	.unmap_sg		= arm_iommu_unmap_sg,
-	.sync_sg_for_cpu	= arm_iommu_sync_sg_for_cpu,
-	.sync_sg_for_device	= arm_iommu_sync_sg_for_device,
-
-	.set_dma_mask		= arm_dma_set_mask,
-};
-
-struct dma_map_ops iommu_coherent_ops = {
-	.alloc		= arm_iommu_alloc_attrs,
-	.free		= arm_iommu_free_attrs,
-	.mmap		= arm_iommu_mmap_attrs,
-	.get_sgtable	= arm_iommu_get_sgtable,
-
-	.map_page	= arm_coherent_iommu_map_page,
-	.unmap_page	= arm_coherent_iommu_unmap_page,
-
-	.map_sg		= arm_coherent_iommu_map_sg,
-	.unmap_sg	= arm_coherent_iommu_unmap_sg,
-
-	.set_dma_mask	= arm_dma_set_mask,
-};
-
-/**
- * arm_iommu_create_mapping
- * @bus: pointer to the bus holding the client device (for IOMMU calls)
- * @base: start address of the valid IO address space
- * @size: maximum size of the valid IO address space
- *
- * Creates a mapping structure which holds information about used/unused
- * IO address ranges, which is required to perform memory allocation and
- * mapping with IOMMU aware functions.
- *
- * The client device need to be attached to the mapping with
- * arm_iommu_attach_device function.
- */
-struct dma_iommu_mapping *
-arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, u64 size)
-{
-	unsigned int bits = size >> PAGE_SHIFT;
-	unsigned int bitmap_size = BITS_TO_LONGS(bits) * sizeof(long);
-	struct dma_iommu_mapping *mapping;
-	int extensions = 1;
-	int err = -ENOMEM;
-
-	/* currently only 32-bit DMA address space is supported */
-	if (size > DMA_BIT_MASK(32) + 1)
-		return ERR_PTR(-ERANGE);
-
-	if (!bitmap_size)
-		return ERR_PTR(-EINVAL);
-
-	if (bitmap_size > PAGE_SIZE) {
-		extensions = bitmap_size / PAGE_SIZE;
-		bitmap_size = PAGE_SIZE;
-	}
-
-	mapping = kzalloc(sizeof(struct dma_iommu_mapping), GFP_KERNEL);
-	if (!mapping)
-		goto err;
-
-	mapping->bitmap_size = bitmap_size;
-	mapping->bitmaps = kzalloc(extensions * sizeof(unsigned long *),
-				GFP_KERNEL);
-	if (!mapping->bitmaps)
-		goto err2;
-
-	mapping->bitmaps[0] = kzalloc(bitmap_size, GFP_KERNEL);
-	if (!mapping->bitmaps[0])
-		goto err3;
-
-	mapping->nr_bitmaps = 1;
-	mapping->extensions = extensions;
-	mapping->base = base;
-	mapping->bits = BITS_PER_BYTE * bitmap_size;
-
-	spin_lock_init(&mapping->lock);
-
-	mapping->domain = iommu_domain_alloc(bus);
-	if (!mapping->domain)
-		goto err4;
-
-	kref_init(&mapping->kref);
-	return mapping;
-err4:
-	kfree(mapping->bitmaps[0]);
-err3:
-	kfree(mapping->bitmaps);
-err2:
-	kfree(mapping);
-err:
-	return ERR_PTR(err);
-}
-EXPORT_SYMBOL_GPL(arm_iommu_create_mapping);
-
-static void release_iommu_mapping(struct kref *kref)
-{
-	int i;
-	struct dma_iommu_mapping *mapping =
-		container_of(kref, struct dma_iommu_mapping, kref);
-
-	iommu_domain_free(mapping->domain);
-	for (i = 0; i < mapping->nr_bitmaps; i++)
-		kfree(mapping->bitmaps[i]);
-	kfree(mapping->bitmaps);
-	kfree(mapping);
-}
-
-static int extend_iommu_mapping(struct dma_iommu_mapping *mapping)
-{
-	int next_bitmap;
-
-	if (mapping->nr_bitmaps >= mapping->extensions)
-		return -EINVAL;
-
-	next_bitmap = mapping->nr_bitmaps;
-	mapping->bitmaps[next_bitmap] = kzalloc(mapping->bitmap_size,
-						GFP_ATOMIC);
-	if (!mapping->bitmaps[next_bitmap])
-		return -ENOMEM;
-
-	mapping->nr_bitmaps++;
-
-	return 0;
-}
-
-void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping)
-{
-	if (mapping)
-		kref_put(&mapping->kref, release_iommu_mapping);
-}
-EXPORT_SYMBOL_GPL(arm_iommu_release_mapping);
-
-static int __arm_iommu_attach_device(struct device *dev,
-				     struct dma_iommu_mapping *mapping)
-{
-	int err;
-
-	err = iommu_attach_device(mapping->domain, dev);
-	if (err)
-		return err;
-
-	kref_get(&mapping->kref);
-	to_dma_iommu_mapping(dev) = mapping;
-
-	pr_debug("Attached IOMMU controller to %s device.\n", dev_name(dev));
-	return 0;
-}
-
-/**
- * arm_iommu_attach_device
- * @dev: valid struct device pointer
- * @mapping: io address space mapping structure (returned from
- *	arm_iommu_create_mapping)
- *
- * Attaches specified io address space mapping to the provided device.
- * This replaces the dma operations (dma_map_ops pointer) with the
- * IOMMU aware version.
- *
- * More than one client might be attached to the same io address space
- * mapping.
- */
-int arm_iommu_attach_device(struct device *dev,
-			    struct dma_iommu_mapping *mapping)
-{
-	int err;
-
-	err = __arm_iommu_attach_device(dev, mapping);
-	if (err)
-		return err;
-
-	set_dma_ops(dev, &iommu_ops);
-	return 0;
-}
-EXPORT_SYMBOL_GPL(arm_iommu_attach_device);
-
-static void __arm_iommu_detach_device(struct device *dev)
-{
-	struct dma_iommu_mapping *mapping;
-
-	mapping = to_dma_iommu_mapping(dev);
-	if (!mapping) {
-		dev_warn(dev, "Not attached\n");
-		return;
-	}
-
-	iommu_detach_device(mapping->domain, dev);
-	kref_put(&mapping->kref, release_iommu_mapping);
-	to_dma_iommu_mapping(dev) = NULL;
-
-	pr_debug("Detached IOMMU controller from %s device.\n", dev_name(dev));
-}
-
-/**
- * arm_iommu_detach_device
- * @dev: valid struct device pointer
- *
- * Detaches the provided device from a previously attached map.
- * This voids the dma operations (dma_map_ops pointer)
- */
-void arm_iommu_detach_device(struct device *dev)
-{
-	__arm_iommu_detach_device(dev);
-	set_dma_ops(dev, NULL);
-}
-EXPORT_SYMBOL_GPL(arm_iommu_detach_device);
-
-static struct dma_map_ops *arm_get_iommu_dma_map_ops(bool coherent)
-{
-	return coherent ? &iommu_coherent_ops : &iommu_ops;
-}
-
-static bool arm_setup_iommu_dma_ops(struct device *dev, u64 dma_base, u64 size,
-				    struct iommu_ops *iommu)
-{
-	struct dma_iommu_mapping *mapping;
-
-	if (!iommu)
-		return false;
-
-	mapping = arm_iommu_create_mapping(dev->bus, dma_base, size);
-	if (IS_ERR(mapping)) {
-		pr_warn("Failed to create %llu-byte IOMMU mapping for device %s\n",
-				size, dev_name(dev));
-		return false;
-	}
-
-	if (__arm_iommu_attach_device(dev, mapping)) {
-		pr_warn("Failed to attached device %s to IOMMU_mapping\n",
-				dev_name(dev));
-		arm_iommu_release_mapping(mapping);
-		return false;
-	}
-
-	return true;
-}
-
-static void arm_teardown_iommu_dma_ops(struct device *dev)
-{
-	struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-
-	if (!mapping)
-		return;
-
-	__arm_iommu_detach_device(dev);
-	arm_iommu_release_mapping(mapping);
-}
-
-#else
-
-static bool arm_setup_iommu_dma_ops(struct device *dev, u64 dma_base, u64 size,
-				    struct iommu_ops *iommu)
-{
-	return false;
-}
-
-static void arm_teardown_iommu_dma_ops(struct device *dev) { }
-
-#define arm_get_iommu_dma_map_ops arm_get_dma_map_ops
-
-#endif	/* CONFIG_ARM_DMA_USE_IOMMU */
-
 static struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
 {
 	return coherent ? &arm_coherent_dma_ops : &arm_dma_ops;
@@ -2123,18 +1010,13 @@ static struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
 void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
 			struct iommu_ops *iommu, bool coherent)
 {
-	struct dma_map_ops *dma_ops;
-
 	dev->archdata.dma_coherent = coherent;
-	if (arm_setup_iommu_dma_ops(dev, dma_base, size, iommu))
-		dma_ops = arm_get_iommu_dma_map_ops(coherent);
-	else
-		dma_ops = arm_get_dma_map_ops(coherent);
 
-	set_dma_ops(dev, dma_ops);
+	if (!common_iommu_setup_dma_ops(dev, dma_base, size, iommu))
+		arch_set_dma_ops(dev, arm_get_dma_map_ops(coherent));
 }
 
 void arch_teardown_dma_ops(struct device *dev)
 {
-	arm_teardown_iommu_dma_ops(dev);
+	common_iommu_teardown_dma_ops(dev);
 }
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 85739859dffc..7bdb5cf64ba3 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -1,5 +1,6 @@
 config DRM_ROCKCHIP
 	tristate "DRM Support for Rockchip"
+	depends on BROKEN
 	depends on DRM && ROCKCHIP_IOMMU
 	depends on RESET_CONTROLLER
 	select DRM_KMS_HELPER
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 1674de1cfed0..8a99210f1cbc 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -265,6 +265,7 @@ config EXYNOS_IOMMU_DEBUG
 
 config IPMMU_VMSA
 	bool "Renesas VMSA-compatible IPMMU"
+	depends on BROKEN
 	depends on ARM_LPAE
 	depends on ARCH_SHMOBILE || COMPILE_TEST
 	select IOMMU_API
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 8b89ebe16d94..fb8bb372e489 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -88,6 +88,7 @@ config VIDEO_OMAP3
 	depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
 	depends on HAS_DMA && OF
 	depends on OMAP_IOMMU
+	depends on BROKEN
 	select ARM_DMA_USE_IOMMU
 	select VIDEOBUF2_DMA_CONTIG
 	select MFD_SYSCON
-- 
1.9.2



From arnd at arndb.de  Fri Feb 19 00:23:35 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 09:23:35 +0100
Subject: [RFC5 PATCH v6 00/21] ILP32 for ARM64
In-Reply-To: <20160218223506.GA7816@yury-N73SV>
References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com>
 <56AC38F1.2030608@huawei.com> <20160218223506.GA7816@yury-N73SV>
Message-ID: <208897488.c0hkBy2G1S@wuerfel>

On Friday 19 February 2016 01:35:06 Yury Norov wrote:
> 
> Hi Bamvor, everybody,
> 
> I have new glibc that follows new ABI:
> https://github.com/norov/glibc/tree/new-api

Ah, very good!

> It's very draft and dirty, but you can try it with RFC5.
> My fail list for ltplite looks like this:
> pipeio_4                       FAIL       11   
> abort01                        FAIL       2    
> clone02                        FAIL       4    
> kill10                         FAIL       2    
> kill11                         FAIL       2    
> lstat01A                       FAIL       1    
> lstat02                        FAIL       1    
> mmap16                         FAIL       6    
> nanosleep03                    FAIL       1    
> nftw01                         FAIL       1    
> nftw6401                       FAIL       1    
> open12                         FAIL       2    
> pathconf01                     FAIL       1    
> pipe07                         FAIL       2    
> profil01                       FAIL       11   
> readdir01                      FAIL       1    
> readlink01A                    FAIL       1    
> rename11                       FAIL       2    
> rmdir02                        FAIL       2    
> sigaltstack01                  FAIL       1    
> sigaltstack02                  FAIL       1    
> stat03                         FAIL       1    
> stat04                         FAIL       1    
> stat06                         FAIL       1    
> umount2_01                     FAIL       2    
> umount2_02                     FAIL       2    
> umount2_03                     FAIL       2    
> utime06                        FAIL       2    
> writev01                       FAIL       1    
> mtest06                        FAIL       11   
> rwtest01                       FAIL       2    
> rwtest02                       FAIL       2    
> rwtest03                       FAIL       2    
> rwtest04                       FAIL       2    
> rwtest05                       FAIL       2

I have no idea whether this is good news or bad news ;-)

In https://github.com/norov/glibc/commit/351b8728fdb365bd4852ac113601ddf38153fdfc
I see that you are passing __IPC_64, I thought we had already resolved
that in the kernel. We might need to go back to this.

In https://github.com/norov/glibc/commit/5d4290435e428267171ece871539b76e1d079d11
you are defining a struct __kernel_stat64 in the glibc. Is this the expected
way to do it? I would have thought you'd get the definition from the kernel
headers.
 
	Arnd


From jitao.shi at mediatek.com  Fri Feb 19 00:31:17 2016
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Fri, 19 Feb 2016 16:31:17 +0800
Subject: [PATCH v10 1/2] Documentation: bridge: Add documentation for ps8640
 DT properties
Message-ID: <1455870678-13959-1-git-send-email-jitao.shi@mediatek.com>

Add documentation for DT properties supported by
ps8640 DSI-eDP converter.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
Acked-by: Rob Herring <robh at kernel.org>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
---
Changes since v9:
 - No change
---
 .../devicetree/bindings/display/bridge/ps8640.txt  |   43 ++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.txt b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
new file mode 100644
index 0000000..a3e0971
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
@@ -0,0 +1,43 @@
+ps8640-bridge bindings
+
+Required properties:
+	- compatible: "parade,ps8640"
+	- reg: first page address of the bridge.
+	- sleep-gpios: OF device-tree gpio specification for PD_ pin.
+	- reset-gpios: OF device-tree gpio specification for reset pin.
+	- mode-sel-gpios: OF device-tree gpio specification for mode-sel pin.
+	- vdd12-supply: OF device-tree regulator specification for 1.2V power.
+	- vdd33-supply: OF device-tree regulator specification for 3.3V power.
+	- ports: The device node can contain video interface port nodes per
+		 the video-interfaces bind[1]. For port at 0,set the reg = <0> as
+		 ps8640 dsi in and port at 1,set the reg = <1> as ps8640 eDP out.
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+	edp-bridge at 18 {
+		compatible = "parade,ps8640";
+		reg = <0x18>;
+		sleep-gpios = <&pio 116 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&pio 115 GPIO_ACTIVE_HIGH>;
+		mode-sel-gpios = <&pio 92 GPIO_ACTIVE_HIGH>;
+		vdd12-supply = <&ps8640_fixed_1v2>;
+		vdd33-supply = <&mt6397_vgp2_reg>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			port at 0 {
+				reg = <0>;
+				ps8640_in: endpoint {
+					remote-endpoint = <&dsi0_out>;
+				};
+			};
+			port at 1 {
+				reg = <1>;
+				ps8640_out: endpoint {
+					remote-endpoint = <&panel_in>;
+				};
+			};
+		};
+	};
-- 
1.7.9.5



From jitao.shi at mediatek.com  Fri Feb 19 00:31:18 2016
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Fri, 19 Feb 2016 16:31:18 +0800
Subject: [PATCH v10 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
In-Reply-To: <1455870678-13959-1-git-send-email-jitao.shi@mediatek.com>
References: <1455870678-13959-1-git-send-email-jitao.shi@mediatek.com>
Message-ID: <1455870678-13959-2-git-send-email-jitao.shi@mediatek.com>

This patch adds drm_bridge driver for parade DSI to eDP bridge chip.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
---
Changes since v9:
 - replace dev_kmalloc with devm_kmalloc in ps8640_get_modes
 - remove ps_bridge->dsi = devm_kzalloc(dev, sizeof(struct mipi_dsi_device),
					GFP_KERNEL);
 - fix wrong condition in ps8640_validate_firmware()

The following patches are needed to support dsi host through none dsi bus:

https://patchwork.kernel.org/patch/8289181/ ("drm/dsi: check for CONFIG_OF when defining")
https://patchwork.kernel.org/patch/8289051/ ("drm/dsi: Use mipi_dsi_device_register_full for DSI device")
https://patchwork.kernel.org/patch/8289081/ ("drm/dsi: Try to match non-DT DSI devices")
https://patchwork.kernel.org/patch/8289121/ ("drm/dsi: Add routine to unregister a DSI device")
https://patchwork.kernel.org/patch/8289091/ ("drm/dsi: Get DSI host by DT device node")
---
 drivers/gpu/drm/bridge/Kconfig         |   11 +
 drivers/gpu/drm/bridge/Makefile        |    1 +
 drivers/gpu/drm/bridge/parade-ps8640.c | 1057 ++++++++++++++++++++++++++++++++
 3 files changed, 1069 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 27e2022..b4edd8c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,4 +40,15 @@ config DRM_PARADE_PS8622
 	---help---
 	  Parade eDP-LVDS bridge chip driver.
 
+config DRM_PARADE_PS8640
+	tristate "Parade PS8640 MIPI DSI to eDP Converter"
+	depends on OF && I2C
+	select DRM_KMS_HELPER
+	select DRM_MIPI_DSI
+	select DRM_PANEL
+	---help---
+	  Choose this option if you have PS8640 for display
+	  The PS8640 is a high-performance and low-power
+	  MIPI DSI to eDP converter
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f13c33d..fbe38dc 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c
new file mode 100644
index 0000000..5f27548
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -0,0 +1,1057 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/firmware.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/of_graph.h>
+#include <linux/regulator/consumer.h>
+#include <asm/unaligned.h>
+#include <drm/drm_panel.h>
+
+#include <drmP.h>
+#include <drm_atomic_helper.h>
+#include <drm_crtc_helper.h>
+#include <drm_crtc.h>
+#include <drm_edid.h>
+#include <drm_mipi_dsi.h>
+
+#define PAGE2_SPI_CFG3		0x82
+#define I2C_TO_SPI_RESET	0x20
+#define PAGE2_ROMADD_BYTE1	0x8e
+#define PAGE2_ROMADD_BYTE2	0x8f
+#define PAGE2_SWSPI_WDATA	0x90
+#define PAGE2_SWSPI_RDATA	0x91
+#define PAGE2_SWSPI_LEN		0x92
+#define PAGE2_SWSPI_CTL		0x93
+#define TRIGGER_NO_READBACK	0x05
+#define TRIGGER_READBACK	0x01
+#define PAGE2_SPI_STATUS	0x9e
+#define PAGE2_GPIO_L		0xa6
+#define PAGE2_GPIO_H		0xa7
+#define PS_GPIO9		BIT(1)
+#define PAGE2_IROM_CTRL		0xb0
+#define IROM_ENABLE		0xc0
+#define IROM_DISABLE		0x80
+#define PAGE2_SW_REST		0xbc
+#define SPI_SW_RESET		BIT(7)
+#define MPU_SW_RESET		BIT(6)
+#define PAGE2_ENCTLSPI_WR	0xda
+#define PAGE2_I2C_BYPASS	0xea
+#define I2C_BYPASS_EN		0xd0
+#define PAGE3_SET_ADD		0xfe
+#define PAGE3_SET_VAL		0xff
+#define VDO_CTL_ADD		0x13
+#define VDO_DIS			0x18
+#define VDO_EN			0x1c
+#define PAGE4_REV_L		0xf0
+#define PAGE4_REV_H		0xf1
+#define PAGE4_CHIP_L		0xf2
+#define PAGE4_CHIP_H		0xf3
+
+/* Firmware */
+#define SPI_MAX_RETRY_CNT	8
+#define PS_FW_NAME		"ps864x_fw.bin"
+
+#define FW_CHIP_ID_OFFSET	0
+#define FW_VERSION_OFFSET	2
+#define EDID_I2C_ADDR		0x50
+
+#define WRITE_STATUS_REG_CMD	0x01
+#define READ_STATUS_REG_CMD	0x05
+#define CLEAR_ALL_PROTECT	0x00
+#define BLK_PROTECT_BITS	0x0c
+#define STATUS_REG_PROTECT	BIT(7)
+#define WRITE_ENABLE_CMD	0x06
+#define CHIP_ERASE_CMD		0xc7
+
+#define bridge_to_ps8640(e)	container_of(e, struct ps8640, bridge)
+#define connector_to_ps8640(e)	container_of(e, struct ps8640, connector)
+
+struct ps8640_info {
+	u8 family_id;
+	u8 variant_id;
+	u16 version;
+};
+
+struct ps8640 {
+	struct drm_connector connector;
+	struct drm_bridge bridge;
+	struct edid *edid;
+	struct mipi_dsi_device dsi;
+	struct i2c_client *page[8];
+	struct i2c_client *ddc_i2c;
+	struct regulator_bulk_data supplies[2];
+	struct drm_panel *panel;
+	struct gpio_desc *gpio_rst_n;
+	struct gpio_desc *gpio_slp_n;
+	struct gpio_desc *gpio_mode_sel_n;
+	bool enabled;
+
+	/* firmware file info */
+	bool in_fw_update;
+	struct ps8640_info info;
+};
+
+static const u8 enc_ctrl_code[6] = {0xaa, 0x55, 0x50, 0x41, 0x52, 0x44};
+
+static int ps8640_read(struct i2c_client *client, u8 reg, u8 *data,
+		       u16 data_len)
+{
+	int ret;
+	struct i2c_msg msgs[] = {
+		{
+		 .addr = client->addr,
+		 .flags = 0,
+		 .len = 1,
+		 .buf = &reg,
+		 },
+		{
+		 .addr = client->addr,
+		 .flags = I2C_M_RD,
+		 .len = data_len,
+		 .buf = data,
+		 }
+	};
+
+	ret = i2c_transfer(client->adapter, msgs, 2);
+
+	if (ret == 2)
+		return 0;
+	if (ret < 0)
+		return ret;
+	else
+		return -EIO;
+}
+
+static int ps8640_write_bytes(struct i2c_client *client, u8 *data,
+			      u16 data_len)
+{
+	int ret;
+	struct i2c_msg msg;
+
+	msg.addr = client->addr;
+	msg.flags = 0;
+	msg.len = data_len;
+	msg.buf = data;
+
+	ret = i2c_transfer(client->adapter, &msg, 1);
+	if (ret == 1)
+		return 0;
+	if (ret < 0)
+		return ret;
+	else
+		return -EIO;
+}
+
+static int ps8640_write_byte(struct i2c_client *client, u8 reg,  u8 data)
+{
+	int ret;
+	struct i2c_msg msg;
+	u8 buf[] = {reg, data};
+
+	msg.addr = client->addr;
+	msg.flags = 0;
+	msg.len = sizeof(buf);
+	msg.buf = buf;
+
+	ret = i2c_transfer(client->adapter, &msg, 1);
+	if (ret == 1)
+		return 0;
+	if (ret < 0)
+		return ret;
+	else
+		return -EIO;
+}
+
+static void ps8640_get_mcu_fw_version(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[5];
+	u8 fw_ver[2];
+
+	ps8640_read(client, 0x4, fw_ver, 2);
+	ps_bridge->info.version = (fw_ver[0] << 8) | fw_ver[1];
+
+	DRM_INFO_ONCE("ps8640 rom fw version %d.%d\n", fw_ver[0], fw_ver[1]);
+}
+
+static int ps8640_bridge_enable(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[3];
+	u8 vdo_ctrl_buf[3] = {PAGE3_SET_ADD, VDO_CTL_ADD, VDO_EN};
+
+	return ps8640_write_bytes(client, vdo_ctrl_buf, 3);
+}
+
+static int ps8640_bridge_disable(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[3];
+	u8 vdo_ctrl_buf[3] = {PAGE3_SET_ADD, VDO_CTL_ADD, VDO_DIS};
+
+	return ps8640_write_bytes(client, vdo_ctrl_buf, 3);
+}
+
+static void ps8640_pre_enable(struct drm_bridge *bridge)
+{
+	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+	struct i2c_client *client = ps_bridge->page[2];
+	int err, retry_cnt = 0;
+	u8 set_vdo_done;
+
+	if (ps_bridge->in_fw_update)
+		return;
+
+	if (ps_bridge->enabled)
+		return;
+
+	err = drm_panel_prepare(ps_bridge->panel);
+	if (err < 0) {
+		DRM_ERROR("failed to prepare panel: %d\n", err);
+		return;
+	}
+
+	gpiod_set_value(ps_bridge->gpio_slp_n, 1);
+	gpiod_set_value(ps_bridge->gpio_rst_n, 0);
+
+	err = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
+				    ps_bridge->supplies);
+	if (err < 0) {
+		DRM_ERROR("cannot enable regulators %d\n", err);
+		goto err_panel_unprepare;
+	}
+
+	usleep_range(500, 700);
+	gpiod_set_value(ps_bridge->gpio_rst_n, 1);
+
+	/*
+	 * Wait for the ps8640 embed mcu ready
+	 * First wait 200ms and then check the mcu ready flag every 20ms
+	 */
+	msleep(200);
+	do {
+		err = ps8640_read(client, PAGE2_GPIO_H, &set_vdo_done, 1);
+		if (err < 0) {
+			DRM_ERROR("failed read PAGE2_GPIO_H: %d\n", err);
+			goto err_regulators_disable;
+		}
+		msleep(20);
+	} while ((retry_cnt++ < 10) && ((set_vdo_done & PS_GPIO9) != PS_GPIO9));
+
+	if (ps_bridge->info.version == 0)
+		ps8640_get_mcu_fw_version(ps_bridge);
+	/* Switch access edp panel's edid through i2c */
+	ps8640_write_byte(client, PAGE2_I2C_BYPASS, I2C_BYPASS_EN);
+	ps_bridge->enabled = true;
+
+	return;
+
+err_regulators_disable:
+	regulator_bulk_disable(ARRAY_SIZE(ps_bridge->supplies),
+			       ps_bridge->supplies);
+err_panel_unprepare:
+	drm_panel_unprepare(ps_bridge->panel);
+}
+
+static void ps8640_enable(struct drm_bridge *bridge)
+{
+	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+	int err;
+
+	err = ps8640_bridge_enable(ps_bridge);
+	if (err)
+		DRM_ERROR("failed to enable unmutevideo: %d\n", err);
+
+	err = drm_panel_enable(ps_bridge->panel);
+	if (err < 0)
+		DRM_ERROR("failed to enable panel: %d\n", err);
+}
+
+static void ps8640_disable(struct drm_bridge *bridge)
+{
+	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+	int err;
+
+	err = drm_panel_disable(ps_bridge->panel);
+	if (err < 0)
+		DRM_ERROR("failed to disable panel: %d\n", err);
+
+	err = ps8640_bridge_disable(ps_bridge);
+	if (err < 0)
+		DRM_ERROR("failed to disable bridge: %d\n", err);
+}
+
+static void ps8640_post_disable(struct drm_bridge *bridge)
+{
+	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+	int err;
+
+	if (ps_bridge->in_fw_update)
+		return;
+
+	if (!ps_bridge->enabled)
+		return;
+
+	ps_bridge->enabled = false;
+
+	gpiod_set_value(ps_bridge->gpio_rst_n, 0);
+	gpiod_set_value(ps_bridge->gpio_slp_n, 0);
+	err = regulator_bulk_disable(ARRAY_SIZE(ps_bridge->supplies),
+				     ps_bridge->supplies);
+	if (err < 0)
+		DRM_ERROR("cannot disable regulators %d\n", err);
+
+	err = drm_panel_unprepare(ps_bridge->panel);
+	if (err)
+		DRM_ERROR("failed to unprepare panel: %d\n", err);
+}
+
+static int ps8640_get_modes(struct drm_connector *connector)
+{
+	struct ps8640 *ps_bridge = connector_to_ps8640(connector);
+	struct device *dev = &ps_bridge->page[0]->dev;
+	u8 *edid;
+	int ret, num_modes = 0;
+	bool power_off;
+
+	if (ps_bridge->edid)
+		return drm_add_edid_modes(connector, ps_bridge->edid);
+
+	power_off = !ps_bridge->enabled;
+	ps8640_pre_enable(&ps_bridge->bridge);
+
+	edid = devm_kmalloc(dev, EDID_LENGTH, GFP_KERNEL);
+	if (!edid) {
+		DRM_ERROR("Failed to allocate EDID\n");
+		return 0;
+	}
+
+	ret = ps8640_read(ps_bridge->ddc_i2c, 0, edid, EDID_LENGTH);
+	if (ret)
+		goto out;
+
+	ps_bridge->edid = (struct edid *)edid;
+	drm_mode_connector_update_edid_property(connector, ps_bridge->edid);
+
+	num_modes = drm_add_edid_modes(connector, ps_bridge->edid);
+
+out:
+	if (power_off)
+		ps8640_post_disable(&ps_bridge->bridge);
+
+	return num_modes;
+}
+
+static struct drm_encoder *ps8640_best_encoder(struct drm_connector *connector)
+{
+	struct ps8640 *ps_bridge;
+
+	ps_bridge = connector_to_ps8640(connector);
+	return ps_bridge->bridge.encoder;
+}
+
+static const struct drm_connector_helper_funcs ps8640_connector_helper_funcs = {
+	.get_modes = ps8640_get_modes,
+	.best_encoder = ps8640_best_encoder,
+};
+
+static enum drm_connector_status ps8640_detect(struct drm_connector *connector,
+					       bool force)
+{
+	return connector_status_connected;
+}
+
+static void ps8640_connector_destroy(struct drm_connector *connector)
+{
+	drm_connector_unregister(connector);
+	drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs ps8640_connector_funcs = {
+	.dpms = drm_atomic_helper_connector_dpms,
+	.fill_modes = drm_helper_probe_single_connector_modes,
+	.detect = ps8640_detect,
+	.destroy = ps8640_connector_destroy,
+	.reset = drm_atomic_helper_connector_reset,
+	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+int ps8640_bridge_attach(struct drm_bridge *bridge)
+{
+	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+	struct device *dev = &ps_bridge->page[0]->dev;
+	struct device_node *np = dev->of_node;
+	struct device_node *port, *in_ep;
+	struct device_node *dsi_node = NULL;
+	struct mipi_dsi_host *host = ps_bridge->dsi.host;
+	int ret;
+
+	ret = drm_connector_init(bridge->dev, &ps_bridge->connector,
+				 &ps8640_connector_funcs,
+				 DRM_MODE_CONNECTOR_eDP);
+
+	if (ret) {
+		DRM_ERROR("Failed to initialize connector with drm: %d\n", ret);
+		return ret;
+	}
+
+	drm_connector_helper_add(&ps_bridge->connector,
+				 &ps8640_connector_helper_funcs);
+	drm_connector_register(&ps_bridge->connector);
+
+	ps_bridge->connector.dpms = DRM_MODE_DPMS_ON;
+	drm_mode_connector_attach_encoder(&ps_bridge->connector,
+					  bridge->encoder);
+
+	if (ps_bridge->panel)
+		drm_panel_attach(ps_bridge->panel, &ps_bridge->connector);
+
+	/* port at 0 is ps8640 dsi input port */
+	port = of_graph_get_port_by_id(np, 0);
+	if (port) {
+		in_ep = of_get_child_by_name(port, "endpoint");
+		of_node_put(port);
+		if (in_ep) {
+			dsi_node = of_graph_get_remote_port_parent(in_ep);
+			of_node_put(in_ep);
+		}
+	}
+	if (dsi_node) {
+		host = of_find_mipi_dsi_host_by_node(dsi_node);
+		of_node_put(dsi_node);
+		if (!host)
+			return -ENODEV;
+	}
+
+	ps_bridge->dsi.host = host;
+	ps_bridge->dsi.mode_flags = MIPI_DSI_MODE_VIDEO |
+				     MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
+	ps_bridge->dsi.format = MIPI_DSI_FMT_RGB888;
+	ps_bridge->dsi.lanes = 4;
+	ret = mipi_dsi_attach(&ps_bridge->dsi);
+	if (ret) {
+		drm_panel_detach(ps_bridge->panel);
+		return ret;
+	}
+
+	return ret;
+}
+
+static const struct drm_bridge_funcs ps8640_bridge_funcs = {
+	.attach = ps8640_bridge_attach,
+	.disable = ps8640_disable,
+	.post_disable = ps8640_post_disable,
+	.pre_enable = ps8640_pre_enable,
+	.enable = ps8640_enable,
+};
+
+/* Firmware Version is returned as Major.Minor.Build */
+static ssize_t ps8640_fw_version_show(struct device *dev,
+				      struct device_attribute *attr, char *buf)
+{
+	struct ps8640 *ps_bridge = dev_get_drvdata(dev);
+	struct ps8640_info *info = &ps_bridge->info;
+
+	return scnprintf(buf, PAGE_SIZE, "%u.%u\n", info->version >> 8,
+			 info->version & 0xff);
+}
+
+/* Hardware Version is returned as FamilyID.VariantID */
+static ssize_t ps8640_hw_version_show(struct device *dev,
+				      struct device_attribute *attr, char *buf)
+{
+	struct ps8640 *ps_bridge = dev_get_drvdata(dev);
+	struct ps8640_info *info = &ps_bridge->info;
+
+	return scnprintf(buf, PAGE_SIZE, "ps%u.%u\n", info->family_id,
+			 info->variant_id);
+}
+
+static int ps8640_spi_send_cmd(struct ps8640 *ps_bridge, u8 *cmd, u8 cmd_len)
+{
+	struct i2c_client *client = ps_bridge->page[2];
+	u8 i, buf[3];
+	int ret;
+
+	ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_ENABLE);
+	if (ret)
+		goto err;
+
+	/* write command in write port */
+	for (i = 0; i < cmd_len; i++) {
+		ret = ps8640_write_byte(client, PAGE2_SWSPI_WDATA, cmd[i]);
+		if (ret)
+			goto err;
+	}
+
+	buf[0] = PAGE2_SWSPI_LEN;
+	buf[1] = cmd_len - 1;
+	buf[2] = TRIGGER_NO_READBACK;
+	ret = ps8640_write_bytes(client, buf, 3);
+	if (ret)
+		goto err;
+
+	ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
+	if (ret)
+		goto err;
+
+	return 0;
+
+err:
+	dev_err(&client->dev, "send command err: %d\n", ret);
+	return ret;
+}
+
+static int ps8640_wait_spi_ready(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[2];
+	u8 spi_rdy_st, retry_cnt = 0;
+
+	do {
+		ps8640_read(client, PAGE2_SPI_STATUS, &spi_rdy_st, 1);
+		msleep(20);
+		if ((retry_cnt == SPI_MAX_RETRY_CNT) &&
+		    ((spi_rdy_st & 0x0c) != 0x0c)) {
+			dev_err(&client->dev, "wait spi ready timeout\n");
+			return -EBUSY;
+		}
+	} while ((retry_cnt++ < SPI_MAX_RETRY_CNT) &&
+		 (spi_rdy_st & 0x0c) == 0x0c);
+
+	return 0;
+}
+
+static int ps8640_wait_spi_nobusy(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[2];
+	u8 spi_status, buf[3], retry_cnt = 0;
+	int ret;
+
+	do {
+		/* 0x05 RDSR; Read-Status-Register */
+		ret = ps8640_write_byte(client, PAGE2_SWSPI_WDATA,
+					READ_STATUS_REG_CMD);
+		if (ret)
+			goto err_send_cmd_exit;
+
+		buf[0] = PAGE2_SWSPI_LEN;
+		buf[1] = 0;
+		buf[2] = TRIGGER_READBACK;
+		ret = ps8640_write_bytes(client, buf, 3);
+		if (ret)
+			goto err_send_cmd_exit;
+
+		/* delay for cmd send */
+		usleep_range(100, 300);
+		/* wait for SPI ROM until not busy */
+		ret = ps8640_read(client, PAGE2_SWSPI_RDATA, &spi_status, 1);
+		if (ret)
+			goto err_send_cmd_exit;
+	} while ((retry_cnt++ < SPI_MAX_RETRY_CNT) &&
+		 (spi_status & BLK_PROTECT_BITS) == BLK_PROTECT_BITS);
+
+	if ((retry_cnt > SPI_MAX_RETRY_CNT) &&
+	    (spi_status & BLK_PROTECT_BITS) != BLK_PROTECT_BITS) {
+		ret = -EBUSY;
+		dev_err(&client->dev, "wait spi no busy timeout: %d\n", ret);
+		goto err_timeout;
+	}
+
+	return 0;
+
+err_send_cmd_exit:
+	dev_err(&client->dev, "send command err: %d\n", ret);
+
+err_timeout:
+	return ret;
+}
+
+static int ps8640_wait_rom_idle(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[0];
+	int ret;
+
+	ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_ENABLE);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_wait_spi_ready(ps_bridge);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_wait_spi_nobusy(ps_bridge);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
+	if (ret)
+		goto exit;
+
+exit:
+	if (ret)
+		dev_err(&client->dev, "wait ps8640 rom idle fail: %d\n", ret);
+
+	return ret;
+}
+
+static int ps8640_spi_dl_mode(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[2];
+	int ret;
+
+	/* switch ps8640 mode to spi dl mode */
+	gpiod_set_value(ps_bridge->gpio_mode_sel_n, 0);
+
+	/* reset spi interface */
+	ret = ps8640_write_byte(client, PAGE2_SW_REST,
+				SPI_SW_RESET | MPU_SW_RESET);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_write_byte(client, PAGE2_SW_REST, MPU_SW_RESET);
+	if (ret)
+		goto exit;
+
+exit:
+	if (ret)
+		dev_err(&client->dev, "fail reset spi interface: %d\n", ret);
+
+	return ret;
+}
+
+static int ps8640_rom_prepare(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[2];
+	struct device *dev = &client->dev;
+	u8 i, cmd[2];
+	int ret;
+
+	cmd[0] = WRITE_ENABLE_CMD;
+	ret = ps8640_spi_send_cmd(ps_bridge, cmd, 1);
+	if (ret) {
+		dev_err(dev, "failed enable-write-status-register: %d\n", ret);
+		return ret;
+	}
+
+	cmd[0] = WRITE_STATUS_REG_CMD;
+	cmd[1] = CLEAR_ALL_PROTECT;
+	ret = ps8640_spi_send_cmd(ps_bridge, cmd, 2);
+	if (ret) {
+		dev_err(dev, "fail disable all protection: %d\n", ret);
+		return ret;
+	}
+
+	/* wait for SPI module ready */
+	ret = ps8640_wait_rom_idle(ps_bridge);
+	if (ret) {
+		dev_err(dev, "fail wait rom idle: %d\n", ret);
+		return ret;
+	}
+
+	ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_ENABLE);
+	for (i = 0; i < 6; i++)
+		ps8640_write_byte(client, PAGE2_ENCTLSPI_WR, enc_ctrl_code[i]);
+	ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
+
+	/* Enable-Write-Status-Register */
+	cmd[0] = WRITE_ENABLE_CMD;
+	ret = ps8640_spi_send_cmd(ps_bridge, cmd, 1);
+	if (ret) {
+		dev_err(dev, "fail enable-write-status-register: %d\n", ret);
+		return ret;
+	}
+
+	/* chip erase command */
+	cmd[0] = CHIP_ERASE_CMD;
+	ret = ps8640_spi_send_cmd(ps_bridge, cmd, 1);
+	if (ret) {
+		dev_err(dev, "fail disable all protection: %d\n", ret);
+		return ret;
+	}
+
+	ret = ps8640_wait_rom_idle(ps_bridge);
+	if (ret) {
+		dev_err(dev, "fail wait rom idle: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int ps8640_validate_firmware(struct ps8640 *ps_bridge,
+				    const struct firmware *fw)
+{
+	struct i2c_client *client = ps_bridge->page[0];
+	struct ps8640_info *info = &ps_bridge->info;
+	u16 fw_chip_id, fw_version_id;
+
+	/*
+	 * Get the chip_id from the firmware. Make sure that it is the
+	 * right controller to do the firmware and config update.
+	 */
+	fw_chip_id = get_unaligned_le16(fw->data + FW_CHIP_ID_OFFSET);
+
+	if (fw_chip_id != 0x8640) {
+		dev_err(&client->dev,
+			"chip id mismatch: fw 0x%x vs. chip 0x8640\n",
+			fw_chip_id);
+		return -ENODEV;
+	}
+
+	fw_version_id = get_unaligned_le16(fw->data + FW_VERSION_OFFSET);
+
+	if (fw_version_id == info->version) {
+		dev_err(&client->dev,
+			"no need update fw version same: fw %d.%d vs. chip %d.%d\n",
+			fw_version_id >> 8, fw_version_id & 0xff,
+			info->version >> 8, info->version & 0xff);
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+static int ps8640_write_rom(struct ps8640 *ps_bridge, const struct firmware *fw)
+{
+	struct i2c_client *client = ps_bridge->page[0];
+	struct device *dev = &client->dev;
+	struct i2c_client *client2 = ps_bridge->page[2];
+	struct i2c_client *client7 = ps_bridge->page[7];
+	unsigned int pos = 0;
+	u8 buf[257], rom_page_id_buf[3];
+	int ret;
+	u16 cpy_len;
+
+	ps8640_write_byte(client2, PAGE2_SPI_CFG3, I2C_TO_SPI_RESET);
+	msleep(100);
+	ps8640_write_byte(client2, PAGE2_SPI_CFG3, 0x00);
+
+	while (pos < fw->size) {
+		rom_page_id_buf[0] = PAGE2_ROMADD_BYTE1;
+		rom_page_id_buf[1] = (pos >> 8) & 0xff;
+		rom_page_id_buf[2] = (pos >> 16) & 0xff;
+		ret = ps8640_write_bytes(client2, rom_page_id_buf, 3);
+		if (ret)
+			goto error;
+		cpy_len = fw->size >= 256 + pos ? 256 : fw->size - pos;
+		buf[0] = 0;
+		memcpy(buf + 1, fw->data + pos, cpy_len);
+		ret = ps8640_write_bytes(client7, buf, cpy_len + 1);
+		if (ret)
+			goto error;
+
+		pos += cpy_len;
+
+		dev_dbg(dev, "fw update completed %u / %zu bytes\n", pos,
+			fw->size);
+	}
+	return 0;
+
+error:
+	dev_err(dev, "failed write extenal flash, %d\n", ret);
+	return ret;
+}
+
+static int ps8640_spi_normal_mode(struct ps8640 *ps_bridge)
+{
+	u8 cmd[2];
+	struct i2c_client *client = ps_bridge->page[2];
+
+	/* Enable-Write-Status-Register */
+	cmd[0] = WRITE_ENABLE_CMD;
+	ps8640_spi_send_cmd(ps_bridge, cmd, 1);
+
+	/* protect BPL/BP0/BP1 */
+	cmd[0] = WRITE_STATUS_REG_CMD;
+	cmd[1] = BLK_PROTECT_BITS | STATUS_REG_PROTECT;
+	ps8640_spi_send_cmd(ps_bridge, cmd, 2);
+
+	/* wait for SPI rom ready */
+	ps8640_wait_rom_idle(ps_bridge);
+
+	/* disable PS8640 mapping function */
+	ps8640_write_byte(client, PAGE2_ENCTLSPI_WR, 0x00);
+
+	gpiod_set_value(ps_bridge->gpio_mode_sel_n, 1);
+	return 0;
+}
+
+static int ps8640_enter_bl(struct ps8640 *ps_bridge)
+{
+	ps_bridge->in_fw_update = true;
+	return ps8640_spi_dl_mode(ps_bridge);
+}
+
+static void ps8640_exit_bl(struct ps8640 *ps_bridge, const struct firmware *fw)
+{
+	ps8640_spi_normal_mode(ps_bridge);
+	ps_bridge->in_fw_update = false;
+}
+
+static int ps8640_load_fw(struct ps8640 *ps_bridge, const struct firmware *fw)
+{
+	struct i2c_client *client = ps_bridge->page[0];
+	struct device *dev = &client->dev;
+	int ret;
+	bool ps8640_status_backup = ps_bridge->enabled;
+
+	if (!ps_bridge->in_fw_update) {
+		if (!ps8640_status_backup)
+			ps8640_pre_enable(&ps_bridge->bridge);
+
+		ret = ps8640_enter_bl(ps_bridge);
+		if (ret)
+			goto exit;
+	}
+
+	ret = ps8640_validate_firmware(ps_bridge, fw);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_rom_prepare(ps_bridge);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_write_rom(ps_bridge, fw);
+
+exit:
+	if (ret)
+		dev_err(dev, "Failed to load firmware, %d\n", ret);
+
+	ps8640_exit_bl(ps_bridge, fw);
+	if (!ps8640_status_backup)
+		ps8640_post_disable(&ps_bridge->bridge);
+	return ret;
+}
+
+static ssize_t ps8640_update_fw_store(struct device *dev,
+				      struct device_attribute *attr,
+				      const char *buf, size_t count)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct ps8640 *ps_bridge = i2c_get_clientdata(client);
+	const struct firmware *fw;
+	int error;
+
+	error = request_firmware(&fw, PS_FW_NAME, dev);
+	if (error) {
+		dev_err(dev, "Unable to open firmware %s: %d\n",
+			PS_FW_NAME, error);
+		return error;
+	}
+
+	error = ps8640_load_fw(ps_bridge, fw);
+	if (error)
+		dev_err(dev, "The firmware update failed(%d)\n", error);
+	else
+		dev_info(dev, "The firmware update succeeded\n");
+
+	release_firmware(fw);
+	return error ? error : count;
+}
+
+static DEVICE_ATTR(fw_version, S_IRUGO, ps8640_fw_version_show, NULL);
+static DEVICE_ATTR(hw_version, S_IRUGO, ps8640_hw_version_show, NULL);
+static DEVICE_ATTR(update_fw, S_IWUSR, NULL, ps8640_update_fw_store);
+
+static struct attribute *ps8640_attrs[] = {
+	&dev_attr_fw_version.attr,
+	&dev_attr_hw_version.attr,
+	&dev_attr_update_fw.attr,
+	NULL
+};
+
+static const struct attribute_group ps8640_attr_group = {
+	.attrs = ps8640_attrs,
+};
+
+static void ps8640_remove_sysfs_group(void *data)
+{
+	struct ps8640 *ps_bridge = data;
+
+	sysfs_remove_group(&ps_bridge->page[0]->dev.kobj, &ps8640_attr_group);
+}
+
+static int ps8640_probe(struct i2c_client *client,
+			const struct i2c_device_id *id)
+{
+	struct device *dev = &client->dev;
+	struct ps8640 *ps_bridge;
+	struct device_node *np = dev->of_node;
+	struct device_node *port, *out_ep;
+	struct device_node *panel_node = NULL;
+	int i, ret;
+
+	ps_bridge = devm_kzalloc(dev, sizeof(*ps_bridge), GFP_KERNEL);
+	if (!ps_bridge)
+		return -ENOMEM;
+
+	/* port at 1 is ps8640 output port */
+	port = of_graph_get_port_by_id(np, 1);
+	if (port) {
+		out_ep = of_get_child_by_name(port, "endpoint");
+		of_node_put(port);
+		if (out_ep) {
+			panel_node = of_graph_get_remote_port_parent(out_ep);
+			of_node_put(out_ep);
+		}
+	}
+	if (panel_node) {
+		ps_bridge->panel = of_drm_find_panel(panel_node);
+		of_node_put(panel_node);
+		if (!ps_bridge->panel)
+			return -EPROBE_DEFER;
+	}
+
+	ps_bridge->supplies[0].supply = "vdd33";
+	ps_bridge->supplies[1].supply = "vdd12";
+	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ps_bridge->supplies),
+				      ps_bridge->supplies);
+	if (ret) {
+		dev_info(dev, "failed to get regulators: %d\n", ret);
+		return -EPROBE_DEFER;
+	}
+
+	ps_bridge->gpio_mode_sel_n = devm_gpiod_get(&client->dev, "mode-sel",
+						    GPIOD_OUT_HIGH);
+	if (IS_ERR(ps_bridge->gpio_mode_sel_n)) {
+		ret = PTR_ERR(ps_bridge->gpio_mode_sel_n);
+		dev_err(dev, "cannot get mode-sel %d\n", ret);
+		return ret;
+	}
+
+	ps_bridge->gpio_slp_n = devm_gpiod_get(&client->dev, "sleep",
+					       GPIOD_OUT_HIGH);
+	if (IS_ERR(ps_bridge->gpio_slp_n)) {
+		ret = PTR_ERR(ps_bridge->gpio_slp_n);
+		dev_err(dev, "cannot get sleep: %d\n", ret);
+		return ret;
+	}
+
+	ps_bridge->gpio_rst_n = devm_gpiod_get(&client->dev, "reset",
+					       GPIOD_OUT_HIGH);
+	if (IS_ERR(ps_bridge->gpio_rst_n)) {
+		ret = PTR_ERR(ps_bridge->gpio_rst_n);
+		dev_err(dev, "cannot get reset: %d\n", ret);
+		return ret;
+	}
+
+	ps_bridge->bridge.funcs = &ps8640_bridge_funcs;
+	ps_bridge->bridge.of_node = dev->of_node;
+	ret = drm_bridge_add(&ps_bridge->bridge);
+	if (ret) {
+		dev_err(dev, "Failed to add bridge: %d\n", ret);
+		return ret;
+	}
+
+	ps_bridge->page[0] = client;
+	ps_bridge->ddc_i2c = i2c_new_dummy(client->adapter, EDID_I2C_ADDR);
+	if (!ps_bridge->ddc_i2c) {
+		dev_err(dev, "failed ddc_i2c dummy device, address%02x\n",
+			EDID_I2C_ADDR);
+		ret = -EBUSY;
+		goto exit_ddc_i2c_dummy;
+	}
+	/*
+	 * ps8640 uses multiple addresses, use dummy devices for them
+	 * page[0]: for DP control
+	 * page[1]: for VIDEO Bridge
+	 * page[2]: for control top
+	 * page[3]: for DSI Link Control1
+	 * page[4]: for MIPI Phy
+	 * page[5]: for VPLL
+	 * page[6]: for DSI Link Control2
+	 * page[7]: for spi rom mapping
+	 */
+	for (i = 1; i < 8; i++) {
+		ps_bridge->page[i] = i2c_new_dummy(client->adapter,
+						   client->addr + i);
+		if (!ps_bridge->page[i]) {
+			dev_err(dev, "failed i2c dummy device, address%02x\n",
+				client->addr + i);
+			ret = -EBUSY;
+			goto exit_dummy;
+		}
+	}
+	i2c_set_clientdata(client, ps_bridge);
+
+	ret = sysfs_create_group(&client->dev.kobj, &ps8640_attr_group);
+	if (ret) {
+		dev_err(dev, "failed to create sysfs entries: %d\n", ret);
+		goto exit_dummy;
+	}
+
+	ret = devm_add_action(dev, ps8640_remove_sysfs_group, ps_bridge);
+	if (ret) {
+		dev_err(dev, "failed to add sysfs cleanup action: %d\n", ret);
+		goto exit_remove_sysfs;
+	}
+	return 0;
+
+exit_remove_sysfs:
+	sysfs_remove_group(&ps_bridge->page[0]->dev.kobj, &ps8640_attr_group);
+exit_dummy:
+	for (i = 1; i < 8; i++)
+		if (ps_bridge->page[i])
+			i2c_unregister_device(ps_bridge->page[i]);
+exit_ddc_i2c_dummy:
+	drm_bridge_remove(&ps_bridge->bridge);
+	return ret;
+}
+
+static int ps8640_remove(struct i2c_client *client)
+{
+	struct ps8640 *ps_bridge = i2c_get_clientdata(client);
+	int i;
+
+	for (i = 1; i < 8; i++)
+		i2c_unregister_device(ps_bridge->page[i]);
+
+	drm_bridge_remove(&ps_bridge->bridge);
+
+	return 0;
+}
+
+static const struct i2c_device_id ps8640_i2c_table[] = {
+	{"parade,ps8640", 0},
+	{},
+};
+MODULE_DEVICE_TABLE(i2c, ps8640_i2c_table);
+
+static const struct of_device_id ps8640_match[] = {
+	{ .compatible = "parade,ps8640" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, ps8640_match);
+
+static struct i2c_driver ps8640_driver = {
+	.id_table = ps8640_i2c_table,
+	.probe = ps8640_probe,
+	.remove = ps8640_remove,
+	.driver = {
+		.name = "parade,ps8640",
+		.of_match_table = ps8640_match,
+	},
+};
+module_i2c_driver(ps8640_driver);
+
+MODULE_AUTHOR("Jitao Shi <jitao.shi at mediatek.com>");
+MODULE_AUTHOR("CK Hu <ck.hu at mediatek.com>");
+MODULE_DESCRIPTION("PARADE ps8640 DSI-eDP converter driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5



From arnd at arndb.de  Fri Feb 19 00:33:39 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 09:33:39 +0100
Subject: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values
In-Reply-To: <alpine.LFD.2.20.1602181100410.13632@knanqh.ubzr>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-5-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602181100410.13632@knanqh.ubzr>
Message-ID: <3974581.yknKb3tq7o@wuerfel>

On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote:
> 
> Acked-by: Nicolas Pitre <nico at linaro.org>
> 
> Is there a way to provide a default for defaults?

We could have something like

config PHYS_OFFSET_0
	bool

config PHYS_OFFSET_1
	bool

config PHYS_OFFSET_2
	bool

... (we need 8 of the 16 possible addresses)


config PHYS_OFFSET
	hex "Physical address of main memory" if MMU
	default DRAM_BASE if !MMU
	default 0x00000000 if PHYS_OFFSET_0
	default 0x10000000 if PHYS_OFFSET_1
	default 0x20000000 if PHYS_OFFSET_2
	default 0x30000000 if PHYS_OFFSET_3
	default 0x70000000 if PHYS_OFFSET_7
	default 0x80000000 if PHYS_OFFSET_8
	default 0xa0000000 if PHYS_OFFSET_A
	default 0xc0000000 if PHYS_OFFSET_C


and then select one of the bool symbols from each platform.
Would that address your question?

FWIW, that would also let us do:

config XIP_KERNEL
	bool "Kernel Execute-In-Place from ROM"
	depends on PHYS_OFFSET_0 || PHYS_OFFSET_1 || PHYS_OFFSET_2 ||
		   PHYS_OFFSET_3 || PHYS_OFFSET_7 || PHYS_OFFSET_8 ||
		   PHYS_OFFSET_A || PHYS_OFFSET_C

We can probably come up with a more elaborate way to prevent configurations
that have more than one of these set.

	Arnd


From blogic at openwrt.org  Fri Feb 19 00:44:05 2016
From: blogic at openwrt.org (John Crispin)
Date: Fri, 19 Feb 2016 09:44:05 +0100
Subject: [PATCH V6 01/11] dt-bindings: ARM: Mediatek: add MT2701/7623 string
 to the PMIC wrapper doc
In-Reply-To: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
References: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
Message-ID: <1455871455-21212-2-git-send-email-blogic@openwrt.org>

Signed-off-by: John Crispin <blogic at openwrt.org>
Acked-by: Rob Herring <robh at kernel.org>
Cc: devicetree at vger.kernel.org
---
 Documentation/devicetree/bindings/soc/mediatek/pwrap.txt |    1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
index ddeb5b6..107700d 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
@@ -18,6 +18,7 @@ IP Pairing
 
 Required properties in pwrap device node.
 - compatible:
+	"mediatek,mt2701-pwrap" for MT2701/7623 SoCs
 	"mediatek,mt8135-pwrap" for MT8135 SoCs
 	"mediatek,mt8173-pwrap" for MT8173 SoCs
 - interrupts: IRQ for pwrap in SOC
-- 
1.7.10.4


From blogic at openwrt.org  Fri Feb 19 00:44:04 2016
From: blogic at openwrt.org (John Crispin)
Date: Fri, 19 Feb 2016 09:44:04 +0100
Subject: [PATCH V6 00/11] soc: mediatek: PMIC wrap: add MT6323/2701/7623
 support
Message-ID: <1455871455-21212-1-git-send-email-blogic@openwrt.org>

This series adds support for the MT6323 PMIC and the MT2701/7623 SoC.
MT6323 is slightly different to the already supported PMIC. This series
makes a few changes to the code to allow easy addition of the new PMIC
and SoCs.

Changes in V6
* 4/11 - make description verbose and rename init_special
* 6/11 - make description verbose
* 7/11 - make description verbose
* 8/11 - make description verbose
* 9/11 - put mt6397 specific dew registers in their own paragraph


John Crispin (11):
  dt-bindings: ARM: Mediatek: add MT2701/7623 string to the PMIC
    wrapper doc
  soc: mediatek: PMIC wrap: don't duplicate the wrapper data
  soc: mediatek: PMIC wrap: add wrapper callbacks for init_reg_clock
  soc: mediatek: PMIC wrap: split SoC specific init into callback
  soc: mediatek: PMIC wrap: WRAP_INT_EN needs a different bitmask for
    MT2701/7623
  soc: mediatek: PMIC wrap: SPI_WRITE needs a different bitmask for
    MT2701/7623
  soc: mediatek: PMIC wrap: move wdt_src into the pmic_wrapper_type
    struct
  soc: mediatek: PMIC wrap: remove pwrap_is_mt8135() and
    pwrap_is_mt8173()
  soc: mediatek: PMIC wrap: add a slave specific struct
  soc: mediatek: PMIC wrap: add mt6323 slave support
  soc: mediatek: PMIC wrap: add MT2701/7623 support

 .../devicetree/bindings/soc/mediatek/pwrap.txt     |    1 +
 drivers/soc/mediatek/mtk-pmic-wrap.c               |  544 +++++++++++++++-----
 2 files changed, 414 insertions(+), 131 deletions(-)

-- 
1.7.10.4


From blogic at openwrt.org  Fri Feb 19 00:44:06 2016
From: blogic at openwrt.org (John Crispin)
Date: Fri, 19 Feb 2016 09:44:06 +0100
Subject: [PATCH V6 02/11] soc: mediatek: PMIC wrap: don't duplicate the
 wrapper data
In-Reply-To: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
References: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
Message-ID: <1455871455-21212-3-git-send-email-blogic@openwrt.org>

As we add support for more devices struct pmic_wrapper_type will grow and
we do not really want to start duplicating all the elements in
struct pmic_wrapper.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
 drivers/soc/mediatek/mtk-pmic-wrap.c |   22 ++++++++--------------
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 0d9b19a..340c4b5 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -376,9 +376,7 @@ struct pmic_wrapper {
 	struct device *dev;
 	void __iomem *base;
 	struct regmap *regmap;
-	int *regs;
-	enum pwrap_type type;
-	u32 arb_en_all;
+	const struct pmic_wrapper_type *master;
 	struct clk *clk_spi;
 	struct clk *clk_wrap;
 	struct reset_control *rstc;
@@ -389,22 +387,22 @@ struct pmic_wrapper {
 
 static inline int pwrap_is_mt8135(struct pmic_wrapper *wrp)
 {
-	return wrp->type == PWRAP_MT8135;
+	return wrp->master->type == PWRAP_MT8135;
 }
 
 static inline int pwrap_is_mt8173(struct pmic_wrapper *wrp)
 {
-	return wrp->type == PWRAP_MT8173;
+	return wrp->master->type == PWRAP_MT8173;
 }
 
 static u32 pwrap_readl(struct pmic_wrapper *wrp, enum pwrap_regs reg)
 {
-	return readl(wrp->base + wrp->regs[reg]);
+	return readl(wrp->base + wrp->master->regs[reg]);
 }
 
 static void pwrap_writel(struct pmic_wrapper *wrp, u32 val, enum pwrap_regs reg)
 {
-	writel(val, wrp->base + wrp->regs[reg]);
+	writel(val, wrp->base + wrp->master->regs[reg]);
 }
 
 static bool pwrap_is_fsm_idle(struct pmic_wrapper *wrp)
@@ -697,7 +695,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 
 	pwrap_writel(wrp, 1, PWRAP_WRAP_EN);
 
-	pwrap_writel(wrp, wrp->arb_en_all, PWRAP_HIPRIO_ARB_EN);
+	pwrap_writel(wrp, wrp->master->arb_en_all, PWRAP_HIPRIO_ARB_EN);
 
 	pwrap_writel(wrp, 1, PWRAP_WACS2_EN);
 
@@ -742,7 +740,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, 0x1, PWRAP_CRC_EN);
 	pwrap_writel(wrp, 0x0, PWRAP_SIG_MODE);
 	pwrap_writel(wrp, PWRAP_DEW_CRC_VAL, PWRAP_SIG_ADR);
-	pwrap_writel(wrp, wrp->arb_en_all, PWRAP_HIPRIO_ARB_EN);
+	pwrap_writel(wrp, wrp->master->arb_en_all, PWRAP_HIPRIO_ARB_EN);
 
 	if (pwrap_is_mt8135(wrp))
 		pwrap_writel(wrp, 0x7, PWRAP_RRARB_EN);
@@ -836,7 +834,6 @@ static int pwrap_probe(struct platform_device *pdev)
 	struct device_node *np = pdev->dev.of_node;
 	const struct of_device_id *of_id =
 		of_match_device(of_pwrap_match_tbl, &pdev->dev);
-	const struct pmic_wrapper_type *type;
 	struct resource *res;
 
 	wrp = devm_kzalloc(&pdev->dev, sizeof(*wrp), GFP_KERNEL);
@@ -845,10 +842,7 @@ static int pwrap_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, wrp);
 
-	type = of_id->data;
-	wrp->regs = type->regs;
-	wrp->type = type->type;
-	wrp->arb_en_all = type->arb_en_all;
+	wrp->master = of_id->data;
 	wrp->dev = &pdev->dev;
 
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pwrap");
-- 
1.7.10.4


From blogic at openwrt.org  Fri Feb 19 00:44:07 2016
From: blogic at openwrt.org (John Crispin)
Date: Fri, 19 Feb 2016 09:44:07 +0100
Subject: [PATCH V6 03/11] soc: mediatek: PMIC wrap: add wrapper callbacks for
 init_reg_clock
In-Reply-To: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
References: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
Message-ID: <1455871455-21212-4-git-send-email-blogic@openwrt.org>

Split init_reg_clock up into SoC specific callbacks. The patch also
reorders the code to avoid the need for callback function prototypes.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
 drivers/soc/mediatek/mtk-pmic-wrap.c |   70 ++++++++++++++++++----------------
 1 file changed, 38 insertions(+), 32 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 340c4b5..b22b664 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -354,24 +354,6 @@ enum pwrap_type {
 	PWRAP_MT8173,
 };
 
-struct pmic_wrapper_type {
-	int *regs;
-	enum pwrap_type type;
-	u32 arb_en_all;
-};
-
-static struct pmic_wrapper_type pwrap_mt8135 = {
-	.regs = mt8135_regs,
-	.type = PWRAP_MT8135,
-	.arb_en_all = 0x1ff,
-};
-
-static struct pmic_wrapper_type pwrap_mt8173 = {
-	.regs = mt8173_regs,
-	.type = PWRAP_MT8173,
-	.arb_en_all = 0x3f,
-};
-
 struct pmic_wrapper {
 	struct device *dev;
 	void __iomem *base;
@@ -385,6 +367,13 @@ struct pmic_wrapper {
 	void __iomem *bridge_base;
 };
 
+struct pmic_wrapper_type {
+	int *regs;
+	enum pwrap_type type;
+	u32 arb_en_all;
+	int (*init_reg_clock)(struct pmic_wrapper *wrp);
+};
+
 static inline int pwrap_is_mt8135(struct pmic_wrapper *wrp)
 {
 	return wrp->master->type == PWRAP_MT8135;
@@ -578,20 +567,23 @@ static int pwrap_init_sidly(struct pmic_wrapper *wrp)
 	return 0;
 }
 
-static int pwrap_init_reg_clock(struct pmic_wrapper *wrp)
+static int pwrap_mt8135_init_reg_clock(struct pmic_wrapper *wrp)
 {
-	if (pwrap_is_mt8135(wrp)) {
-		pwrap_writel(wrp, 0x4, PWRAP_CSHEXT);
-		pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_WRITE);
-		pwrap_writel(wrp, 0x4, PWRAP_CSHEXT_READ);
-		pwrap_writel(wrp, 0x0, PWRAP_CSLEXT_START);
-		pwrap_writel(wrp, 0x0, PWRAP_CSLEXT_END);
-	} else {
-		pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_WRITE);
-		pwrap_writel(wrp, 0x4, PWRAP_CSHEXT_READ);
-		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_START);
-		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_END);
-	}
+	pwrap_writel(wrp, 0x4, PWRAP_CSHEXT);
+	pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_WRITE);
+	pwrap_writel(wrp, 0x4, PWRAP_CSHEXT_READ);
+	pwrap_writel(wrp, 0x0, PWRAP_CSLEXT_START);
+	pwrap_writel(wrp, 0x0, PWRAP_CSLEXT_END);
+
+	return 0;
+}
+
+static int pwrap_mt8173_init_reg_clock(struct pmic_wrapper *wrp)
+{
+	pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_WRITE);
+	pwrap_writel(wrp, 0x4, PWRAP_CSHEXT_READ);
+	pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_START);
+	pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_END);
 
 	return 0;
 }
@@ -699,7 +691,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 
 	pwrap_writel(wrp, 1, PWRAP_WACS2_EN);
 
-	ret = pwrap_init_reg_clock(wrp);
+	ret = wrp->master->init_reg_clock(wrp);
 	if (ret)
 		return ret;
 
@@ -814,6 +806,20 @@ static const struct regmap_config pwrap_regmap_config = {
 	.max_register = 0xffff,
 };
 
+static struct pmic_wrapper_type pwrap_mt8135 = {
+	.regs = mt8135_regs,
+	.type = PWRAP_MT8135,
+	.arb_en_all = 0x1ff,
+	.init_reg_clock = pwrap_mt8135_init_reg_clock,
+};
+
+static struct pmic_wrapper_type pwrap_mt8173 = {
+	.regs = mt8173_regs,
+	.type = PWRAP_MT8173,
+	.arb_en_all = 0x3f,
+	.init_reg_clock = pwrap_mt8173_init_reg_clock,
+};
+
 static struct of_device_id of_pwrap_match_tbl[] = {
 	{
 		.compatible = "mediatek,mt8135-pwrap",
-- 
1.7.10.4


From blogic at openwrt.org  Fri Feb 19 00:44:08 2016
From: blogic at openwrt.org (John Crispin)
Date: Fri, 19 Feb 2016 09:44:08 +0100
Subject: [PATCH V6 04/11] soc: mediatek: PMIC wrap: split SoC specific init
 into callback
In-Reply-To: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
References: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
Message-ID: <1455871455-21212-5-git-send-email-blogic@openwrt.org>

This patch moves the SoC specific wrapper init code into separate callback
to avoid pwrap_init() getting too large. This is done by adding a new
element called init_special to pmic_wrapper_type. Each currently supported
SoC gets its own version of the callback and we copy the code that was
previously inside pwrap_init() to these new callbacks. Finally we point the
2 instances of pmic_wrapper_type at the 2 new functions.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
Changes in V6
* make the description verbose
* rename init_special to init_soc_specifc

Changes in V5
* only check the return code of init_special() if the function is
  actually called

 drivers/soc/mediatek/mtk-pmic-wrap.c |   67 +++++++++++++++++++++-------------
 1 file changed, 42 insertions(+), 25 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index b22b664..22c89e9 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -372,6 +372,7 @@ struct pmic_wrapper_type {
 	enum pwrap_type type;
 	u32 arb_en_all;
 	int (*init_reg_clock)(struct pmic_wrapper *wrp);
+	int (*init_soc_specific)(struct pmic_wrapper *wrp);
 };
 
 static inline int pwrap_is_mt8135(struct pmic_wrapper *wrp)
@@ -665,6 +666,41 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
 	return 0;
 }
 
+static int pwrap_mt8135_init_soc_specific(struct pmic_wrapper *wrp)
+{
+	/* enable pwrap events and pwrap bridge in AP side */
+	pwrap_writel(wrp, 0x1, PWRAP_EVENT_IN_EN);
+	pwrap_writel(wrp, 0xffff, PWRAP_EVENT_DST_EN);
+	writel(0x7f, wrp->bridge_base + PWRAP_MT8135_BRIDGE_IORD_ARB_EN);
+	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS3_EN);
+	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS4_EN);
+	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_UNIT);
+	writel(0xffff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_SRC_EN);
+	writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_TIMER_EN);
+	writel(0x7ff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INT_EN);
+
+	/* enable PMIC event out and sources */
+	if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
+		pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
+		dev_err(wrp->dev, "enable dewrap fail\n");
+		return -EFAULT;
+	}
+
+	return 0;
+}
+
+static int pwrap_mt8173_init_soc_specific(struct pmic_wrapper *wrp)
+{
+	/* PMIC_DEWRAP enables */
+	if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
+		pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
+		dev_err(wrp->dev, "enable dewrap fail\n");
+		return -EFAULT;
+	}
+
+	return 0;
+}
+
 static int pwrap_init(struct pmic_wrapper *wrp)
 {
 	int ret;
@@ -743,31 +779,10 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, 0x5, PWRAP_STAUPD_PRD);
 	pwrap_writel(wrp, 0xff, PWRAP_STAUPD_GRPEN);
 
-	if (pwrap_is_mt8135(wrp)) {
-		/* enable pwrap events and pwrap bridge in AP side */
-		pwrap_writel(wrp, 0x1, PWRAP_EVENT_IN_EN);
-		pwrap_writel(wrp, 0xffff, PWRAP_EVENT_DST_EN);
-		writel(0x7f, wrp->bridge_base + PWRAP_MT8135_BRIDGE_IORD_ARB_EN);
-		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS3_EN);
-		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WACS4_EN);
-		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_UNIT);
-		writel(0xffff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_WDT_SRC_EN);
-		writel(0x1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_TIMER_EN);
-		writel(0x7ff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INT_EN);
-
-		/* enable PMIC event out and sources */
-		if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
-				pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
-			dev_err(wrp->dev, "enable dewrap fail\n");
-			return -EFAULT;
-		}
-	} else {
-		/* PMIC_DEWRAP enables */
-		if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
-				pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
-			dev_err(wrp->dev, "enable dewrap fail\n");
-			return -EFAULT;
-		}
+	if (wrp->master->init_soc_specific) {
+		ret = wrp->master->init_soc_specific(wrp);
+		if (ret)
+			return ret;
 	}
 
 	/* Setup the init done registers */
@@ -811,6 +826,7 @@ static struct pmic_wrapper_type pwrap_mt8135 = {
 	.type = PWRAP_MT8135,
 	.arb_en_all = 0x1ff,
 	.init_reg_clock = pwrap_mt8135_init_reg_clock,
+	.init_soc_specific = pwrap_mt8135_init_soc_specific,
 };
 
 static struct pmic_wrapper_type pwrap_mt8173 = {
@@ -818,6 +834,7 @@ static struct pmic_wrapper_type pwrap_mt8173 = {
 	.type = PWRAP_MT8173,
 	.arb_en_all = 0x3f,
 	.init_reg_clock = pwrap_mt8173_init_reg_clock,
+	.init_soc_specific = pwrap_mt8173_init_soc_specific,
 };
 
 static struct of_device_id of_pwrap_match_tbl[] = {
-- 
1.7.10.4


From blogic at openwrt.org  Fri Feb 19 00:44:10 2016
From: blogic at openwrt.org (John Crispin)
Date: Fri, 19 Feb 2016 09:44:10 +0100
Subject: [PATCH V6 06/11] soc: mediatek: PMIC wrap: SPI_WRITE needs a
 different bitmask for MT2701/7623
In-Reply-To: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
References: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
Message-ID: <1455871455-21212-7-git-send-email-blogic@openwrt.org>

Different SoCs will use different bitmask for the SPI_WRITE command. This
patch defines the bitmask in the pmic_wrapper_type struct. This allows us
to support new SoCs with a different bitmask to the one currently used.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
Changes in V6
* make the description verbose

Changes in V4
* fix typo in the subject

 drivers/soc/mediatek/mtk-pmic-wrap.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 9df1135..8ce1bad 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -372,6 +372,7 @@ struct pmic_wrapper_type {
 	enum pwrap_type type;
 	u32 arb_en_all;
 	u32 int_en_all;
+	u32 spi_w;
 	int (*init_reg_clock)(struct pmic_wrapper *wrp);
 	int (*init_soc_specific)(struct pmic_wrapper *wrp);
 };
@@ -511,15 +512,15 @@ static int pwrap_reset_spislave(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, 1, PWRAP_MAN_EN);
 	pwrap_writel(wrp, 0, PWRAP_DIO_EN);
 
-	pwrap_writel(wrp, PWRAP_MAN_CMD_SPI_WRITE | PWRAP_MAN_CMD_OP_CSL,
+	pwrap_writel(wrp, wrp->master->spi_w | PWRAP_MAN_CMD_OP_CSL,
 			PWRAP_MAN_CMD);
-	pwrap_writel(wrp, PWRAP_MAN_CMD_SPI_WRITE | PWRAP_MAN_CMD_OP_OUTS,
+	pwrap_writel(wrp, wrp->master->spi_w | PWRAP_MAN_CMD_OP_OUTS,
 			PWRAP_MAN_CMD);
-	pwrap_writel(wrp, PWRAP_MAN_CMD_SPI_WRITE | PWRAP_MAN_CMD_OP_CSH,
+	pwrap_writel(wrp, wrp->master->spi_w | PWRAP_MAN_CMD_OP_CSH,
 			PWRAP_MAN_CMD);
 
 	for (i = 0; i < 4; i++)
-		pwrap_writel(wrp, PWRAP_MAN_CMD_SPI_WRITE | PWRAP_MAN_CMD_OP_OUTS,
+		pwrap_writel(wrp, wrp->master->spi_w | PWRAP_MAN_CMD_OP_OUTS,
 				PWRAP_MAN_CMD);
 
 	ret = pwrap_wait_for_state(wrp, pwrap_is_sync_idle);
@@ -827,6 +828,7 @@ static struct pmic_wrapper_type pwrap_mt8135 = {
 	.type = PWRAP_MT8135,
 	.arb_en_all = 0x1ff,
 	.int_en_all = ~(BIT(31) | BIT(1)),
+	.spi_w = PWRAP_MAN_CMD_SPI_WRITE,
 	.init_reg_clock = pwrap_mt8135_init_reg_clock,
 	.init_soc_specific = pwrap_mt8135_init_soc_specific,
 };
@@ -836,6 +838,7 @@ static struct pmic_wrapper_type pwrap_mt8173 = {
 	.type = PWRAP_MT8173,
 	.arb_en_all = 0x3f,
 	.int_en_all = ~(BIT(31) | BIT(1)),
+	.spi_w = PWRAP_MAN_CMD_SPI_WRITE,
 	.init_reg_clock = pwrap_mt8173_init_reg_clock,
 	.init_soc_specific = pwrap_mt8173_init_soc_specific,
 };
-- 
1.7.10.4


From blogic at openwrt.org  Fri Feb 19 00:44:11 2016
From: blogic at openwrt.org (John Crispin)
Date: Fri, 19 Feb 2016 09:44:11 +0100
Subject: [PATCH V6 07/11] soc: mediatek: PMIC wrap: move wdt_src into the
 pmic_wrapper_type struct
In-Reply-To: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
References: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
Message-ID: <1455871455-21212-8-git-send-email-blogic@openwrt.org>

Different SoCs will use different bitmask for the wdt_src. This patch
defines the bitmask in the pmic_wrapper_type struct. This allows us to
support new SoCs with a different bitmask to the one currently used.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
Changes in V6
* make the description verbose

 drivers/soc/mediatek/mtk-pmic-wrap.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 8ce1bad..aa54df3 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -373,6 +373,7 @@ struct pmic_wrapper_type {
 	u32 arb_en_all;
 	u32 int_en_all;
 	u32 spi_w;
+	u32 wdt_src;
 	int (*init_reg_clock)(struct pmic_wrapper *wrp);
 	int (*init_soc_specific)(struct pmic_wrapper *wrp);
 };
@@ -829,6 +830,7 @@ static struct pmic_wrapper_type pwrap_mt8135 = {
 	.arb_en_all = 0x1ff,
 	.int_en_all = ~(BIT(31) | BIT(1)),
 	.spi_w = PWRAP_MAN_CMD_SPI_WRITE,
+	.wdt_src = PWRAP_WDT_SRC_MASK_ALL,
 	.init_reg_clock = pwrap_mt8135_init_reg_clock,
 	.init_soc_specific = pwrap_mt8135_init_soc_specific,
 };
@@ -839,6 +841,7 @@ static struct pmic_wrapper_type pwrap_mt8173 = {
 	.arb_en_all = 0x3f,
 	.int_en_all = ~(BIT(31) | BIT(1)),
 	.spi_w = PWRAP_MAN_CMD_SPI_WRITE,
+	.wdt_src = PWRAP_WDT_SRC_MASK_NO_STAUPD,
 	.init_reg_clock = pwrap_mt8173_init_reg_clock,
 	.init_soc_specific = pwrap_mt8173_init_soc_specific,
 };
@@ -858,7 +861,7 @@ MODULE_DEVICE_TABLE(of, of_pwrap_match_tbl);
 
 static int pwrap_probe(struct platform_device *pdev)
 {
-	int ret, irq, wdt_src;
+	int ret, irq;
 	struct pmic_wrapper *wrp;
 	struct device_node *np = pdev->dev.of_node;
 	const struct of_device_id *of_id =
@@ -948,9 +951,7 @@ static int pwrap_probe(struct platform_device *pdev)
 	 * Since STAUPD was not used on mt8173 platform,
 	 * so STAUPD of WDT_SRC which should be turned off
 	 */
-	wdt_src = pwrap_is_mt8173(wrp) ?
-			PWRAP_WDT_SRC_MASK_NO_STAUPD : PWRAP_WDT_SRC_MASK_ALL;
-	pwrap_writel(wrp, wdt_src, PWRAP_WDT_SRC_EN);
+	pwrap_writel(wrp, wrp->master->wdt_src, PWRAP_WDT_SRC_EN);
 	pwrap_writel(wrp, 0x1, PWRAP_TIMER_EN);
 	pwrap_writel(wrp, wrp->master->int_en_all, PWRAP_INT_EN);
 
-- 
1.7.10.4


From blogic at openwrt.org  Fri Feb 19 00:44:09 2016
From: blogic at openwrt.org (John Crispin)
Date: Fri, 19 Feb 2016 09:44:09 +0100
Subject: [PATCH V6 05/11] soc: mediatek: PMIC wrap: WRAP_INT_EN needs a
 different bitmask for MT2701/7623
In-Reply-To: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
References: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
Message-ID: <1455871455-21212-6-git-send-email-blogic@openwrt.org>

MT2701 and MT7623 use a different bitmask for PWRAP_INT_EN.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
Changes in V5
* move the logic invert from call to declaration

 drivers/soc/mediatek/mtk-pmic-wrap.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 22c89e9..9df1135 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -371,6 +371,7 @@ struct pmic_wrapper_type {
 	int *regs;
 	enum pwrap_type type;
 	u32 arb_en_all;
+	u32 int_en_all;
 	int (*init_reg_clock)(struct pmic_wrapper *wrp);
 	int (*init_soc_specific)(struct pmic_wrapper *wrp);
 };
@@ -825,6 +826,7 @@ static struct pmic_wrapper_type pwrap_mt8135 = {
 	.regs = mt8135_regs,
 	.type = PWRAP_MT8135,
 	.arb_en_all = 0x1ff,
+	.int_en_all = ~(BIT(31) | BIT(1)),
 	.init_reg_clock = pwrap_mt8135_init_reg_clock,
 	.init_soc_specific = pwrap_mt8135_init_soc_specific,
 };
@@ -833,6 +835,7 @@ static struct pmic_wrapper_type pwrap_mt8173 = {
 	.regs = mt8173_regs,
 	.type = PWRAP_MT8173,
 	.arb_en_all = 0x3f,
+	.int_en_all = ~(BIT(31) | BIT(1)),
 	.init_reg_clock = pwrap_mt8173_init_reg_clock,
 	.init_soc_specific = pwrap_mt8173_init_soc_specific,
 };
@@ -946,7 +949,7 @@ static int pwrap_probe(struct platform_device *pdev)
 			PWRAP_WDT_SRC_MASK_NO_STAUPD : PWRAP_WDT_SRC_MASK_ALL;
 	pwrap_writel(wrp, wdt_src, PWRAP_WDT_SRC_EN);
 	pwrap_writel(wrp, 0x1, PWRAP_TIMER_EN);
-	pwrap_writel(wrp, ~((1 << 31) | (1 << 1)), PWRAP_INT_EN);
+	pwrap_writel(wrp, wrp->master->int_en_all, PWRAP_INT_EN);
 
 	irq = platform_get_irq(pdev, 0);
 	ret = devm_request_irq(wrp->dev, irq, pwrap_interrupt, IRQF_TRIGGER_HIGH,
-- 
1.7.10.4


From blogic at openwrt.org  Fri Feb 19 00:44:12 2016
From: blogic at openwrt.org (John Crispin)
Date: Fri, 19 Feb 2016 09:44:12 +0100
Subject: [PATCH V6 08/11] soc: mediatek: PMIC wrap: remove pwrap_is_mt8135()
 and pwrap_is_mt8173()
In-Reply-To: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
References: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
Message-ID: <1455871455-21212-9-git-send-email-blogic@openwrt.org>

With more SoCs being added the list of helper functions like these would
grow. To mitigate this problem we remove the existing helpers and change
the code to test against the pmic type stored inside the pmic specific
datastructure that our context structure points at. There is one usage of
pwrap_is_mt8135() that is ambiguous as the test should not be dependent on
mt8135, but rather on the existence of a bridge. Add a new element to
pmic_wrapper_type to indicate if a bridge is present and use this where
appropriate.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
Changes in V6
* make the description verbose

Changed in V4
* fix 2 typos in the description
* used a bitfiled for the new has_bridge flag

 drivers/soc/mediatek/mtk-pmic-wrap.c |   28 ++++++++++++----------------
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index aa54df3..a2bacda 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -374,20 +374,11 @@ struct pmic_wrapper_type {
 	u32 int_en_all;
 	u32 spi_w;
 	u32 wdt_src;
+	int has_bridge:1;
 	int (*init_reg_clock)(struct pmic_wrapper *wrp);
 	int (*init_soc_specific)(struct pmic_wrapper *wrp);
 };
 
-static inline int pwrap_is_mt8135(struct pmic_wrapper *wrp)
-{
-	return wrp->master->type == PWRAP_MT8135;
-}
-
-static inline int pwrap_is_mt8173(struct pmic_wrapper *wrp)
-{
-	return wrp->master->type == PWRAP_MT8173;
-}
-
 static u32 pwrap_readl(struct pmic_wrapper *wrp, enum pwrap_regs reg)
 {
 	return readl(wrp->base + wrp->master->regs[reg]);
@@ -619,11 +610,14 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, 0x1, PWRAP_CIPHER_KEY_SEL);
 	pwrap_writel(wrp, 0x2, PWRAP_CIPHER_IV_SEL);
 
-	if (pwrap_is_mt8135(wrp)) {
+	switch (wrp->master->type) {
+	case PWRAP_MT8135:
 		pwrap_writel(wrp, 1, PWRAP_CIPHER_LOAD);
 		pwrap_writel(wrp, 1, PWRAP_CIPHER_START);
-	} else {
+		break;
+	case PWRAP_MT8173:
 		pwrap_writel(wrp, 1, PWRAP_CIPHER_EN);
+		break;
 	}
 
 	/* Config cipher mode @PMIC */
@@ -713,7 +707,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 	if (wrp->rstc_bridge)
 		reset_control_reset(wrp->rstc_bridge);
 
-	if (pwrap_is_mt8173(wrp)) {
+	if (wrp->master->type == PWRAP_MT8173) {
 		/* Enable DCM */
 		pwrap_writel(wrp, 3, PWRAP_DCM_EN);
 		pwrap_writel(wrp, 0, PWRAP_DCM_DBC_PRD);
@@ -773,7 +767,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, PWRAP_DEW_CRC_VAL, PWRAP_SIG_ADR);
 	pwrap_writel(wrp, wrp->master->arb_en_all, PWRAP_HIPRIO_ARB_EN);
 
-	if (pwrap_is_mt8135(wrp))
+	if (wrp->master->type == PWRAP_MT8135)
 		pwrap_writel(wrp, 0x7, PWRAP_RRARB_EN);
 
 	pwrap_writel(wrp, 0x1, PWRAP_WACS0_EN);
@@ -793,7 +787,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, 1, PWRAP_INIT_DONE0);
 	pwrap_writel(wrp, 1, PWRAP_INIT_DONE1);
 
-	if (pwrap_is_mt8135(wrp)) {
+	if (wrp->master->has_bridge) {
 		writel(1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INIT_DONE3);
 		writel(1, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INIT_DONE4);
 	}
@@ -831,6 +825,7 @@ static struct pmic_wrapper_type pwrap_mt8135 = {
 	.int_en_all = ~(BIT(31) | BIT(1)),
 	.spi_w = PWRAP_MAN_CMD_SPI_WRITE,
 	.wdt_src = PWRAP_WDT_SRC_MASK_ALL,
+	.has_bridge = 1,
 	.init_reg_clock = pwrap_mt8135_init_reg_clock,
 	.init_soc_specific = pwrap_mt8135_init_soc_specific,
 };
@@ -842,6 +837,7 @@ static struct pmic_wrapper_type pwrap_mt8173 = {
 	.int_en_all = ~(BIT(31) | BIT(1)),
 	.spi_w = PWRAP_MAN_CMD_SPI_WRITE,
 	.wdt_src = PWRAP_WDT_SRC_MASK_NO_STAUPD,
+	.has_bridge = 0,
 	.init_reg_clock = pwrap_mt8173_init_reg_clock,
 	.init_soc_specific = pwrap_mt8173_init_soc_specific,
 };
@@ -889,7 +885,7 @@ static int pwrap_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	if (pwrap_is_mt8135(wrp)) {
+	if (wrp->master->has_bridge) {
 		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
 				"pwrap-bridge");
 		wrp->bridge_base = devm_ioremap_resource(wrp->dev, res);
-- 
1.7.10.4


From blogic at openwrt.org  Fri Feb 19 00:44:13 2016
From: blogic at openwrt.org (John Crispin)
Date: Fri, 19 Feb 2016 09:44:13 +0100
Subject: [PATCH V6 09/11] soc: mediatek: PMIC wrap: add a slave specific struct
In-Reply-To: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
References: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
Message-ID: <1455871455-21212-10-git-send-email-blogic@openwrt.org>

This patch adds a new struct pwrap_slv_type that we use to store the slave
specific data. The patch adds 2 new helper functions to access the dew
registers. The slave type is looked up via the wrappers child node.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
Changes in V6
* put mt6397 specific dew registers in their own paragraph

Changes in V5
* drop the dew i/o wrappers

Changed in V4
* drop unused MT8173 specifc variable declarations

 drivers/soc/mediatek/mtk-pmic-wrap.c |  159 ++++++++++++++++++++++++----------
 1 file changed, 112 insertions(+), 47 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index a2bacda..bcc841e 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -69,33 +69,54 @@
 					  PWRAP_WDT_SRC_EN_HARB_STAUPD_DLE | \
 					  PWRAP_WDT_SRC_EN_HARB_STAUPD_ALE)
 
-/* macro for slave device wrapper registers */
-#define PWRAP_DEW_BASE			0xbc00
-#define PWRAP_DEW_EVENT_OUT_EN		(PWRAP_DEW_BASE + 0x0)
-#define PWRAP_DEW_DIO_EN		(PWRAP_DEW_BASE + 0x2)
-#define PWRAP_DEW_EVENT_SRC_EN		(PWRAP_DEW_BASE + 0x4)
-#define PWRAP_DEW_EVENT_SRC		(PWRAP_DEW_BASE + 0x6)
-#define PWRAP_DEW_EVENT_FLAG		(PWRAP_DEW_BASE + 0x8)
-#define PWRAP_DEW_READ_TEST		(PWRAP_DEW_BASE + 0xa)
-#define PWRAP_DEW_WRITE_TEST		(PWRAP_DEW_BASE + 0xc)
-#define PWRAP_DEW_CRC_EN		(PWRAP_DEW_BASE + 0xe)
-#define PWRAP_DEW_CRC_VAL		(PWRAP_DEW_BASE + 0x10)
-#define PWRAP_DEW_MON_GRP_SEL		(PWRAP_DEW_BASE + 0x12)
-#define PWRAP_DEW_MON_FLAG_SEL		(PWRAP_DEW_BASE + 0x14)
-#define PWRAP_DEW_EVENT_TEST		(PWRAP_DEW_BASE + 0x16)
-#define PWRAP_DEW_CIPHER_KEY_SEL	(PWRAP_DEW_BASE + 0x18)
-#define PWRAP_DEW_CIPHER_IV_SEL		(PWRAP_DEW_BASE + 0x1a)
-#define PWRAP_DEW_CIPHER_LOAD		(PWRAP_DEW_BASE + 0x1c)
-#define PWRAP_DEW_CIPHER_START		(PWRAP_DEW_BASE + 0x1e)
-#define PWRAP_DEW_CIPHER_RDY		(PWRAP_DEW_BASE + 0x20)
-#define PWRAP_DEW_CIPHER_MODE		(PWRAP_DEW_BASE + 0x22)
-#define PWRAP_DEW_CIPHER_SWRST		(PWRAP_DEW_BASE + 0x24)
-#define PWRAP_MT8173_DEW_CIPHER_IV0	(PWRAP_DEW_BASE + 0x26)
-#define PWRAP_MT8173_DEW_CIPHER_IV1	(PWRAP_DEW_BASE + 0x28)
-#define PWRAP_MT8173_DEW_CIPHER_IV2	(PWRAP_DEW_BASE + 0x2a)
-#define PWRAP_MT8173_DEW_CIPHER_IV3	(PWRAP_DEW_BASE + 0x2c)
-#define PWRAP_MT8173_DEW_CIPHER_IV4	(PWRAP_DEW_BASE + 0x2e)
-#define PWRAP_MT8173_DEW_CIPHER_IV5	(PWRAP_DEW_BASE + 0x30)
+/* defines for slave device wrapper registers */
+enum dew_regs {
+	PWRAP_DEW_BASE,
+	PWRAP_DEW_DIO_EN,
+	PWRAP_DEW_READ_TEST,
+	PWRAP_DEW_WRITE_TEST,
+	PWRAP_DEW_CRC_EN,
+	PWRAP_DEW_CRC_VAL,
+	PWRAP_DEW_MON_GRP_SEL,
+	PWRAP_DEW_CIPHER_KEY_SEL,
+	PWRAP_DEW_CIPHER_IV_SEL,
+	PWRAP_DEW_CIPHER_RDY,
+	PWRAP_DEW_CIPHER_MODE,
+	PWRAP_DEW_CIPHER_SWRST,
+
+	/* MT6397 only regs */
+	PWRAP_DEW_EVENT_OUT_EN,
+	PWRAP_DEW_EVENT_SRC_EN,
+	PWRAP_DEW_EVENT_SRC,
+	PWRAP_DEW_EVENT_FLAG,
+	PWRAP_DEW_MON_FLAG_SEL,
+	PWRAP_DEW_EVENT_TEST,
+	PWRAP_DEW_CIPHER_LOAD,
+	PWRAP_DEW_CIPHER_START,
+};
+
+static const u32 mt6397_regs[] = {
+	[PWRAP_DEW_BASE] =		0xbc00,
+	[PWRAP_DEW_EVENT_OUT_EN] =	0xbc00,
+	[PWRAP_DEW_DIO_EN] =		0xbc02,
+	[PWRAP_DEW_EVENT_SRC_EN] =	0xbc04,
+	[PWRAP_DEW_EVENT_SRC] =		0xbc06,
+	[PWRAP_DEW_EVENT_FLAG] =	0xbc08,
+	[PWRAP_DEW_READ_TEST] =		0xbc0a,
+	[PWRAP_DEW_WRITE_TEST] =	0xbc0c,
+	[PWRAP_DEW_CRC_EN] =		0xbc0e,
+	[PWRAP_DEW_CRC_VAL] =		0xbc10,
+	[PWRAP_DEW_MON_GRP_SEL] =	0xbc12,
+	[PWRAP_DEW_MON_FLAG_SEL] =	0xbc14,
+	[PWRAP_DEW_EVENT_TEST] =	0xbc16,
+	[PWRAP_DEW_CIPHER_KEY_SEL] =	0xbc18,
+	[PWRAP_DEW_CIPHER_IV_SEL] =	0xbc1a,
+	[PWRAP_DEW_CIPHER_LOAD] =	0xbc1c,
+	[PWRAP_DEW_CIPHER_START] =	0xbc1e,
+	[PWRAP_DEW_CIPHER_RDY] =	0xbc20,
+	[PWRAP_DEW_CIPHER_MODE] =	0xbc22,
+	[PWRAP_DEW_CIPHER_SWRST] =	0xbc24,
+};
 
 enum pwrap_regs {
 	PWRAP_MUX_SEL,
@@ -349,16 +370,26 @@ static int mt8135_regs[] = {
 	[PWRAP_DCM_DBC_PRD] =		0x160,
 };
 
+enum pmic_type {
+	PMIC_MT6397,
+};
+
 enum pwrap_type {
 	PWRAP_MT8135,
 	PWRAP_MT8173,
 };
 
+struct pwrap_slv_type {
+	const u32 *dew_regs;
+	enum pmic_type type;
+};
+
 struct pmic_wrapper {
 	struct device *dev;
 	void __iomem *base;
 	struct regmap *regmap;
 	const struct pmic_wrapper_type *master;
+	const struct pwrap_slv_type *slave;
 	struct clk *clk_spi;
 	struct clk *clk_wrap;
 	struct reset_control *rstc;
@@ -544,7 +575,8 @@ static int pwrap_init_sidly(struct pmic_wrapper *wrp)
 
 	for (i = 0; i < 4; i++) {
 		pwrap_writel(wrp, i, PWRAP_SIDLY);
-		pwrap_read(wrp, PWRAP_DEW_READ_TEST, &rdata);
+		pwrap_read(wrp, wrp->slave->dew_regs[PWRAP_DEW_READ_TEST],
+			   &rdata);
 		if (rdata == PWRAP_DEW_READ_TEST_VAL) {
 			dev_dbg(wrp->dev, "[Read Test] pass, SIDLY=%x\n", i);
 			pass |= 1 << i;
@@ -593,7 +625,8 @@ static bool pwrap_is_pmic_cipher_ready(struct pmic_wrapper *wrp)
 	u32 rdata;
 	int ret;
 
-	ret = pwrap_read(wrp, PWRAP_DEW_CIPHER_RDY, &rdata);
+	ret = pwrap_read(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_RDY],
+			 &rdata);
 	if (ret)
 		return 0;
 
@@ -621,12 +654,12 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
 	}
 
 	/* Config cipher mode @PMIC */
-	pwrap_write(wrp, PWRAP_DEW_CIPHER_SWRST, 0x1);
-	pwrap_write(wrp, PWRAP_DEW_CIPHER_SWRST, 0x0);
-	pwrap_write(wrp, PWRAP_DEW_CIPHER_KEY_SEL, 0x1);
-	pwrap_write(wrp, PWRAP_DEW_CIPHER_IV_SEL, 0x2);
-	pwrap_write(wrp, PWRAP_DEW_CIPHER_LOAD, 0x1);
-	pwrap_write(wrp, PWRAP_DEW_CIPHER_START, 0x1);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_SWRST], 0x1);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_SWRST], 0x0);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_KEY_SEL], 0x1);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_IV_SEL], 0x2);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_LOAD], 0x1);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_START], 0x1);
 
 	/* wait for cipher data ready at AP */
 	ret = pwrap_wait_for_state(wrp, pwrap_is_cipher_ready);
@@ -643,7 +676,7 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
 	}
 
 	/* wait for cipher mode idle */
-	pwrap_write(wrp, PWRAP_DEW_CIPHER_MODE, 0x1);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_MODE], 0x1);
 	ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle_and_sync_idle);
 	if (ret) {
 		dev_err(wrp->dev, "cipher mode idle fail, ret=%d\n", ret);
@@ -653,9 +686,11 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, 1, PWRAP_CIPHER_MODE);
 
 	/* Write Test */
-	if (pwrap_write(wrp, PWRAP_DEW_WRITE_TEST, PWRAP_DEW_WRITE_TEST_VAL) ||
-	    pwrap_read(wrp, PWRAP_DEW_WRITE_TEST, &rdata) ||
-			(rdata != PWRAP_DEW_WRITE_TEST_VAL)) {
+	if (pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_WRITE_TEST],
+			PWRAP_DEW_WRITE_TEST_VAL) ||
+	    pwrap_read(wrp, wrp->slave->dew_regs[PWRAP_DEW_WRITE_TEST],
+		       &rdata) ||
+	    (rdata != PWRAP_DEW_WRITE_TEST_VAL)) {
 		dev_err(wrp->dev, "rdata=0x%04X\n", rdata);
 		return -EFAULT;
 	}
@@ -677,8 +712,10 @@ static int pwrap_mt8135_init_soc_specific(struct pmic_wrapper *wrp)
 	writel(0x7ff, wrp->bridge_base + PWRAP_MT8135_BRIDGE_INT_EN);
 
 	/* enable PMIC event out and sources */
-	if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
-		pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
+	if (pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_EVENT_OUT_EN],
+			0x1) ||
+	    pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_EVENT_SRC_EN],
+			0xffff)) {
 		dev_err(wrp->dev, "enable dewrap fail\n");
 		return -EFAULT;
 	}
@@ -689,8 +726,10 @@ static int pwrap_mt8135_init_soc_specific(struct pmic_wrapper *wrp)
 static int pwrap_mt8173_init_soc_specific(struct pmic_wrapper *wrp)
 {
 	/* PMIC_DEWRAP enables */
-	if (pwrap_write(wrp, PWRAP_DEW_EVENT_OUT_EN, 0x1) ||
-		pwrap_write(wrp, PWRAP_DEW_EVENT_SRC_EN, 0xffff)) {
+	if (pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_EVENT_OUT_EN],
+			0x1) ||
+	    pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_EVENT_SRC_EN],
+			0xffff)) {
 		dev_err(wrp->dev, "enable dewrap fail\n");
 		return -EFAULT;
 	}
@@ -734,7 +773,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 		return ret;
 
 	/* Enable dual IO mode */
-	pwrap_write(wrp, PWRAP_DEW_DIO_EN, 1);
+	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_DIO_EN], 1);
 
 	/* Check IDLE & INIT_DONE in advance */
 	ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle_and_sync_idle);
@@ -746,7 +785,7 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 	pwrap_writel(wrp, 1, PWRAP_DIO_EN);
 
 	/* Read Test */
-	pwrap_read(wrp, PWRAP_DEW_READ_TEST, &rdata);
+	pwrap_read(wrp, wrp->slave->dew_regs[PWRAP_DEW_READ_TEST], &rdata);
 	if (rdata != PWRAP_DEW_READ_TEST_VAL) {
 		dev_err(wrp->dev, "Read test failed after switch to DIO mode: 0x%04x != 0x%04x\n",
 				PWRAP_DEW_READ_TEST_VAL, rdata);
@@ -759,12 +798,13 @@ static int pwrap_init(struct pmic_wrapper *wrp)
 		return ret;
 
 	/* Signature checking - using CRC */
-	if (pwrap_write(wrp, PWRAP_DEW_CRC_EN, 0x1))
+	if (pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CRC_EN], 0x1))
 		return -EFAULT;
 
 	pwrap_writel(wrp, 0x1, PWRAP_CRC_EN);
 	pwrap_writel(wrp, 0x0, PWRAP_SIG_MODE);
-	pwrap_writel(wrp, PWRAP_DEW_CRC_VAL, PWRAP_SIG_ADR);
+	pwrap_writel(wrp, wrp->slave->dew_regs[PWRAP_DEW_CRC_VAL],
+		     PWRAP_SIG_ADR);
 	pwrap_writel(wrp, wrp->master->arb_en_all, PWRAP_HIPRIO_ARB_EN);
 
 	if (wrp->master->type == PWRAP_MT8135)
@@ -818,6 +858,21 @@ static const struct regmap_config pwrap_regmap_config = {
 	.max_register = 0xffff,
 };
 
+static const struct pwrap_slv_type pmic_mt6397 = {
+	.dew_regs = mt6397_regs,
+	.type = PMIC_MT6397,
+};
+
+static const struct of_device_id of_slave_match_tbl[] = {
+	{
+		.compatible = "mediatek,mt6397",
+		.data = &pmic_mt6397,
+	}, {
+		/* sentinel */
+	}
+};
+MODULE_DEVICE_TABLE(of, of_slave_match_tbl);
+
 static struct pmic_wrapper_type pwrap_mt8135 = {
 	.regs = mt8135_regs,
 	.type = PWRAP_MT8135,
@@ -862,8 +917,17 @@ static int pwrap_probe(struct platform_device *pdev)
 	struct device_node *np = pdev->dev.of_node;
 	const struct of_device_id *of_id =
 		of_match_device(of_pwrap_match_tbl, &pdev->dev);
+	const struct of_device_id *of_slave_id = NULL;
 	struct resource *res;
 
+	if (pdev->dev.of_node->child)
+		of_slave_id = of_match_node(of_slave_match_tbl,
+					    pdev->dev.of_node->child);
+	if (!of_slave_id) {
+		dev_dbg(&pdev->dev, "slave pmic should be defined in dts\n");
+		return -EINVAL;
+	}
+
 	wrp = devm_kzalloc(&pdev->dev, sizeof(*wrp), GFP_KERNEL);
 	if (!wrp)
 		return -ENOMEM;
@@ -871,6 +935,7 @@ static int pwrap_probe(struct platform_device *pdev)
 	platform_set_drvdata(pdev, wrp);
 
 	wrp->master = of_id->data;
+	wrp->slave = of_slave_id->data;
 	wrp->dev = &pdev->dev;
 
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pwrap");
-- 
1.7.10.4


From blogic at openwrt.org  Fri Feb 19 00:44:14 2016
From: blogic at openwrt.org (John Crispin)
Date: Fri, 19 Feb 2016 09:44:14 +0100
Subject: [PATCH V6 10/11] soc: mediatek: PMIC wrap: add mt6323 slave support
In-Reply-To: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
References: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
Message-ID: <1455871455-21212-11-git-send-email-blogic@openwrt.org>

Add support for MT6323 slaves. This PMIC can be found on MT2701 and MT7623
EVB. The only function that we need to touch is pwrap_init_cipher().

Signed-off-by: John Crispin <blogic at openwrt.org>
---
 drivers/soc/mediatek/mtk-pmic-wrap.c |   43 ++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index bcc841e..0e4ebb8 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -93,6 +93,27 @@ enum dew_regs {
 	PWRAP_DEW_EVENT_TEST,
 	PWRAP_DEW_CIPHER_LOAD,
 	PWRAP_DEW_CIPHER_START,
+
+	/* MT6323 only regs */
+	PWRAP_DEW_CIPHER_EN,
+	PWRAP_DEW_RDDMY_NO,
+};
+
+static const u32 mt6323_regs[] = {
+	[PWRAP_DEW_BASE] =		0x0000,
+	[PWRAP_DEW_DIO_EN] =		0x018a,
+	[PWRAP_DEW_READ_TEST] =		0x018c,
+	[PWRAP_DEW_WRITE_TEST] =	0x018e,
+	[PWRAP_DEW_CRC_EN] =		0x0192,
+	[PWRAP_DEW_CRC_VAL] =		0x0194,
+	[PWRAP_DEW_MON_GRP_SEL] =	0x0196,
+	[PWRAP_DEW_CIPHER_KEY_SEL] =	0x0198,
+	[PWRAP_DEW_CIPHER_IV_SEL] =	0x019a,
+	[PWRAP_DEW_CIPHER_EN] =		0x019c,
+	[PWRAP_DEW_CIPHER_RDY] =	0x019e,
+	[PWRAP_DEW_CIPHER_MODE] =	0x01a0,
+	[PWRAP_DEW_CIPHER_SWRST] =	0x01a2,
+	[PWRAP_DEW_RDDMY_NO] =		0x01a4,
 };
 
 static const u32 mt6397_regs[] = {
@@ -371,6 +392,7 @@ static int mt8135_regs[] = {
 };
 
 enum pmic_type {
+	PMIC_MT6323,
 	PMIC_MT6397,
 };
 
@@ -661,6 +683,19 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
 	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_LOAD], 0x1);
 	pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_START], 0x1);
 
+	switch (wrp->slave->type) {
+	case PMIC_MT6397:
+		pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_LOAD],
+			    0x1);
+		pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_START],
+			    0x1);
+		break;
+	case PMIC_MT6323:
+		pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_CIPHER_EN],
+			    0x1);
+		break;
+	}
+
 	/* wait for cipher data ready at AP */
 	ret = pwrap_wait_for_state(wrp, pwrap_is_cipher_ready);
 	if (ret) {
@@ -858,6 +893,11 @@ static const struct regmap_config pwrap_regmap_config = {
 	.max_register = 0xffff,
 };
 
+static const struct pwrap_slv_type pmic_mt6323 = {
+	.dew_regs = mt6323_regs,
+	.type = PMIC_MT6323,
+};
+
 static const struct pwrap_slv_type pmic_mt6397 = {
 	.dew_regs = mt6397_regs,
 	.type = PMIC_MT6397,
@@ -865,6 +905,9 @@ static const struct pwrap_slv_type pmic_mt6397 = {
 
 static const struct of_device_id of_slave_match_tbl[] = {
 	{
+		.compatible = "mediatek,mt6323",
+		.data = &pmic_mt6323,
+	}, {
 		.compatible = "mediatek,mt6397",
 		.data = &pmic_mt6397,
 	}, {
-- 
1.7.10.4


From blogic at openwrt.org  Fri Feb 19 00:44:15 2016
From: blogic at openwrt.org (John Crispin)
Date: Fri, 19 Feb 2016 09:44:15 +0100
Subject: [PATCH V6 11/11] soc: mediatek: PMIC wrap: add MT2701/7623 support
In-Reply-To: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
References: <1455871455-21212-1-git-send-email-blogic@openwrt.org>
Message-ID: <1455871455-21212-12-git-send-email-blogic@openwrt.org>

Add the registers, callbacks and data structures required to make the
wrapper work on MT2701 and MT7623.

Signed-off-by: John Crispin <blogic at openwrt.org>
---
 drivers/soc/mediatek/mtk-pmic-wrap.c |  154 ++++++++++++++++++++++++++++++++++
 1 file changed, 154 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 0e4ebb8..3c3e56d 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -52,6 +52,7 @@
 #define PWRAP_DEW_WRITE_TEST_VAL	0xa55a
 
 /* macro for manual command */
+#define PWRAP_MAN_CMD_SPI_WRITE_NEW	(1 << 14)
 #define PWRAP_MAN_CMD_SPI_WRITE		(1 << 13)
 #define PWRAP_MAN_CMD_OP_CSH		(0x0 << 8)
 #define PWRAP_MAN_CMD_OP_CSL		(0x1 << 8)
@@ -200,6 +201,13 @@ enum pwrap_regs {
 	PWRAP_DCM_EN,
 	PWRAP_DCM_DBC_PRD,
 
+	/* MT2701 only regs */
+	PWRAP_ADC_CMD_ADDR,
+	PWRAP_PWRAP_ADC_CMD,
+	PWRAP_ADC_RDY_ADDR,
+	PWRAP_ADC_RDATA_ADDR1,
+	PWRAP_ADC_RDATA_ADDR2,
+
 	/* MT8135 only regs */
 	PWRAP_CSHEXT,
 	PWRAP_EVENT_IN_EN,
@@ -236,6 +244,92 @@ enum pwrap_regs {
 	PWRAP_CIPHER_EN,
 };
 
+static int mt2701_regs[] = {
+	[PWRAP_MUX_SEL] =		0x0,
+	[PWRAP_WRAP_EN] =		0x4,
+	[PWRAP_DIO_EN] =		0x8,
+	[PWRAP_SIDLY] =			0xc,
+	[PWRAP_RDDMY] =			0x18,
+	[PWRAP_SI_CK_CON] =		0x1c,
+	[PWRAP_CSHEXT_WRITE] =		0x20,
+	[PWRAP_CSHEXT_READ] =		0x24,
+	[PWRAP_CSLEXT_START] =		0x28,
+	[PWRAP_CSLEXT_END] =		0x2c,
+	[PWRAP_STAUPD_PRD] =		0x30,
+	[PWRAP_STAUPD_GRPEN] =		0x34,
+	[PWRAP_STAUPD_MAN_TRIG] =	0x38,
+	[PWRAP_STAUPD_STA] =		0x3c,
+	[PWRAP_WRAP_STA] =		0x44,
+	[PWRAP_HARB_INIT] =		0x48,
+	[PWRAP_HARB_HPRIO] =		0x4c,
+	[PWRAP_HIPRIO_ARB_EN] =		0x50,
+	[PWRAP_HARB_STA0] =		0x54,
+	[PWRAP_HARB_STA1] =		0x58,
+	[PWRAP_MAN_EN] =		0x5c,
+	[PWRAP_MAN_CMD] =		0x60,
+	[PWRAP_MAN_RDATA] =		0x64,
+	[PWRAP_MAN_VLDCLR] =		0x68,
+	[PWRAP_WACS0_EN] =		0x6c,
+	[PWRAP_INIT_DONE0] =		0x70,
+	[PWRAP_WACS0_CMD] =		0x74,
+	[PWRAP_WACS0_RDATA] =		0x78,
+	[PWRAP_WACS0_VLDCLR] =		0x7c,
+	[PWRAP_WACS1_EN] =		0x80,
+	[PWRAP_INIT_DONE1] =		0x84,
+	[PWRAP_WACS1_CMD] =		0x88,
+	[PWRAP_WACS1_RDATA] =		0x8c,
+	[PWRAP_WACS1_VLDCLR] =		0x90,
+	[PWRAP_WACS2_EN] =		0x94,
+	[PWRAP_INIT_DONE2] =		0x98,
+	[PWRAP_WACS2_CMD] =		0x9c,
+	[PWRAP_WACS2_RDATA] =		0xa0,
+	[PWRAP_WACS2_VLDCLR] =		0xa4,
+	[PWRAP_INT_EN] =		0xa8,
+	[PWRAP_INT_FLG_RAW] =		0xac,
+	[PWRAP_INT_FLG] =		0xb0,
+	[PWRAP_INT_CLR] =		0xb4,
+	[PWRAP_SIG_ADR] =		0xb8,
+	[PWRAP_SIG_MODE] =		0xbc,
+	[PWRAP_SIG_VALUE] =		0xc0,
+	[PWRAP_SIG_ERRVAL] =		0xc4,
+	[PWRAP_CRC_EN] =		0xc8,
+	[PWRAP_TIMER_EN] =		0xcc,
+	[PWRAP_TIMER_STA] =		0xd0,
+	[PWRAP_WDT_UNIT] =		0xd4,
+	[PWRAP_WDT_SRC_EN] =		0xd8,
+	[PWRAP_WDT_FLG] =		0xdc,
+	[PWRAP_DEBUG_INT_SEL] =		0xe0,
+	[PWRAP_DVFS_ADR0] =		0xe4,
+	[PWRAP_DVFS_WDATA0] =		0xe8,
+	[PWRAP_DVFS_ADR1] =		0xec,
+	[PWRAP_DVFS_WDATA1] =		0xf0,
+	[PWRAP_DVFS_ADR2] =		0xf4,
+	[PWRAP_DVFS_WDATA2] =		0xf8,
+	[PWRAP_DVFS_ADR3] =		0xfc,
+	[PWRAP_DVFS_WDATA3] =		0x100,
+	[PWRAP_DVFS_ADR4] =		0x104,
+	[PWRAP_DVFS_WDATA4] =		0x108,
+	[PWRAP_DVFS_ADR5] =		0x10c,
+	[PWRAP_DVFS_WDATA5] =		0x110,
+	[PWRAP_DVFS_ADR6] =		0x114,
+	[PWRAP_DVFS_WDATA6] =		0x118,
+	[PWRAP_DVFS_ADR7] =		0x11c,
+	[PWRAP_DVFS_WDATA7] =		0x120,
+	[PWRAP_CIPHER_KEY_SEL] =	0x124,
+	[PWRAP_CIPHER_IV_SEL] =		0x128,
+	[PWRAP_CIPHER_EN] =		0x12c,
+	[PWRAP_CIPHER_RDY] =		0x130,
+	[PWRAP_CIPHER_MODE] =		0x134,
+	[PWRAP_CIPHER_SWRST] =		0x138,
+	[PWRAP_DCM_EN] =		0x13c,
+	[PWRAP_DCM_DBC_PRD] =		0x140,
+	[PWRAP_ADC_CMD_ADDR] =		0x144,
+	[PWRAP_PWRAP_ADC_CMD] =		0x148,
+	[PWRAP_ADC_RDY_ADDR] =		0x14c,
+	[PWRAP_ADC_RDATA_ADDR1] =	0x150,
+	[PWRAP_ADC_RDATA_ADDR2] =	0x154,
+};
+
 static int mt8173_regs[] = {
 	[PWRAP_MUX_SEL] =		0x0,
 	[PWRAP_WRAP_EN] =		0x4,
@@ -397,6 +491,7 @@ enum pmic_type {
 };
 
 enum pwrap_type {
+	PWRAP_MT2701,
 	PWRAP_MT8135,
 	PWRAP_MT8173,
 };
@@ -637,6 +732,31 @@ static int pwrap_mt8173_init_reg_clock(struct pmic_wrapper *wrp)
 	return 0;
 }
 
+static int pwrap_mt2701_init_reg_clock(struct pmic_wrapper *wrp)
+{
+	switch (wrp->slave->type) {
+	case PMIC_MT6397:
+		pwrap_writel(wrp, 0xc, PWRAP_RDDMY);
+		pwrap_writel(wrp, 0x4, PWRAP_CSHEXT_WRITE);
+		pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_READ);
+		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_START);
+		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_END);
+		break;
+
+	case PMIC_MT6323:
+		pwrap_writel(wrp, 0x8, PWRAP_RDDMY);
+		pwrap_write(wrp, wrp->slave->dew_regs[PWRAP_DEW_RDDMY_NO],
+			    0x8);
+		pwrap_writel(wrp, 0x5, PWRAP_CSHEXT_WRITE);
+		pwrap_writel(wrp, 0x0, PWRAP_CSHEXT_READ);
+		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_START);
+		pwrap_writel(wrp, 0x2, PWRAP_CSLEXT_END);
+		break;
+	}
+
+	return 0;
+}
+
 static bool pwrap_is_cipher_ready(struct pmic_wrapper *wrp)
 {
 	return pwrap_readl(wrp, PWRAP_CIPHER_RDY) & 1;
@@ -670,6 +790,7 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
 		pwrap_writel(wrp, 1, PWRAP_CIPHER_LOAD);
 		pwrap_writel(wrp, 1, PWRAP_CIPHER_START);
 		break;
+	case PWRAP_MT2701:
 	case PWRAP_MT8173:
 		pwrap_writel(wrp, 1, PWRAP_CIPHER_EN);
 		break;
@@ -772,6 +893,24 @@ static int pwrap_mt8173_init_soc_specific(struct pmic_wrapper *wrp)
 	return 0;
 }
 
+static int pwrap_mt2701_init_soc_specific(struct pmic_wrapper *wrp)
+{
+	/* GPS_INTF initialization */
+	switch (wrp->slave->type) {
+	case PMIC_MT6323:
+		pwrap_writel(wrp, 0x076c, PWRAP_ADC_CMD_ADDR);
+		pwrap_writel(wrp, 0x8000, PWRAP_PWRAP_ADC_CMD);
+		pwrap_writel(wrp, 0x072c, PWRAP_ADC_RDY_ADDR);
+		pwrap_writel(wrp, 0x072e, PWRAP_ADC_RDATA_ADDR1);
+		pwrap_writel(wrp, 0x0730, PWRAP_ADC_RDATA_ADDR2);
+		break;
+	default:
+		break;
+	}
+
+	return 0;
+}
+
 static int pwrap_init(struct pmic_wrapper *wrp)
 {
 	int ret;
@@ -916,6 +1055,18 @@ static const struct of_device_id of_slave_match_tbl[] = {
 };
 MODULE_DEVICE_TABLE(of, of_slave_match_tbl);
 
+static const struct pmic_wrapper_type pwrap_mt2701 = {
+	.regs = mt2701_regs,
+	.type = PWRAP_MT2701,
+	.arb_en_all = 0x3f,
+	.int_en_all = ~(BIT(31) | BIT(2)),
+	.spi_w = PWRAP_MAN_CMD_SPI_WRITE_NEW,
+	.wdt_src = PWRAP_WDT_SRC_MASK_ALL,
+	.has_bridge = 0,
+	.init_reg_clock = pwrap_mt2701_init_reg_clock,
+	.init_soc_specific = pwrap_mt2701_init_soc_specific,
+};
+
 static struct pmic_wrapper_type pwrap_mt8135 = {
 	.regs = mt8135_regs,
 	.type = PWRAP_MT8135,
@@ -942,6 +1093,9 @@ static struct pmic_wrapper_type pwrap_mt8173 = {
 
 static struct of_device_id of_pwrap_match_tbl[] = {
 	{
+		.compatible = "mediatek,mt2701-pwrap",
+		.data = &pwrap_mt2701,
+	}, {
 		.compatible = "mediatek,mt8135-pwrap",
 		.data = &pwrap_mt8135,
 	}, {
-- 
1.7.10.4


From linus.walleij at linaro.org  Fri Feb 19 00:46:27 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 19 Feb 2016 09:46:27 +0100
Subject: [02/11] video: ARM CLCD: support DT signal inversion flags
In-Reply-To: <0cebf93a-ee0a-3637-3242-8aed266df091@broadcom.com>
References: <1454594660-7532-3-git-send-email-linus.walleij@linaro.org>
 <0cebf93a-ee0a-3637-3242-8aed266df091@broadcom.com>
Message-ID: <CACRpkdbGCidu_3qbTYf7WSoAhafU4Z5W0jDs4CGtH5XwSf14aA@mail.gmail.com>

On Wed, Feb 17, 2016 at 7:10 PM, Ray Jui <ray.jui at broadcom.com> wrote:

> A somewhat related question, how do you see the CLKSEL bit in the TIM2
> register will be supported in the future? There are some cases where the
> CLKSEL bit needs to be set, and therefore the "CLCDCLK" instead of "HCLK"
> reference clock source is selected.

I think it's very simple:

The DT node usually looks like so:

display at 10120000 {
        compatible = "arm,pl110", "arm,primecell";
(...)
        clocks = <&oscclk4>, <&pclk>;
        clock-names = "clcd", "apb_pclk";

Just add a custom attribute pointing to the
reference clock in this array:

clcd-reference-clock = <0>;

If this is set to <1> "apb_pclk" (i.e. HCLK) is
the reference, and that bit in TIM2 gets set.

Do you have a system that needs this?

Yours,
Linus Walleij


From vladimir.murzin at arm.com  Fri Feb 19 00:47:47 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Fri, 19 Feb 2016 08:47:47 +0000
Subject: [PATCH 1/9] ARM: ARMv7-M uses BE-8, not BE-32
In-Reply-To: <2702301.CTWUiSsjZR@wuerfel>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-2-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602181102570.13632@knanqh.ubzr>
 <2702301.CTWUiSsjZR@wuerfel>
Message-ID: <56C6D6B3.60605@arm.com>

On 18/02/16 16:12, Arnd Bergmann wrote:
> On Thursday 18 February 2016 11:06:08 Nicolas Pitre wrote:
>> On Thu, 18 Feb 2016, Arnd Bergmann wrote:
>>
>>> When configuring the kernel for big-endian, we set either BE-8 or BE-32
>>> based on the CPU architecture level. Until linux-4.4, we did not have
>>> any ARMv7-M platform allowing big-endian builds, but now i.MX/Vybrid
>>> is in that category, adn we get a build error because of this:
>>>
>>> arch/arm/kernel/module-plts.c: In function 'get_module_plt':
>>> arch/arm/kernel/module-plts.c:60:46: error: implicit declaration of function '__opcode_to_mem_thumb32' [-Werror=implicit-function-declaration]
>>>
>>> This comes down to picking the wrong default, ARMv7-M uses BE8
>>> like ARMv7-A does. Changing the default gets the kernel to compile
>>> and presumably works.
>>
>> Was it tested without BE8 when it was submitted upstream? I don't think 
>> you can switch this freely on a given hardware platform and expect it to 
>> still work.
>>
>>
> 
> mach-imx contains a number of different SoCs, and one SoC was recently
> tested successfully after a number of endianess bugs got fixed. This was
> an i.mx6 using a Cortex-A9 core, but we are now also able to build
> vybrid vf610 big-endian based on that selection. This SoC supports
> Linux running either on its Cortex-A5 or its Cortex-M3 (or M4?) cores.
> 
> I am rather sure nobody has ever run Linux in big-endian mode on the
> Cortex-M platform, specifically because it was always wrong and could
> not be enabled in Kconfig.

Ah, it explains why my quick attempt to enable BE for MPS2 (M-class
platform) failed. With this patch applied I'm able to see Linux booting
on MPS2 FVP model in BE, not complete boot but it might be due to other
reasons. So this patch definitely improves things for me, if it helps

Tested-by: Vladimir Murzin <vladimir.murzin at arm.com>

Cheers
Vladimir

> 
> 	Arnd
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> 
> 



From p.zabel at pengutronix.de  Fri Feb 19 00:51:07 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 19 Feb 2016 09:51:07 +0100
Subject: [PATCH v5 1/1] USB: core: let USB device know device node
In-Reply-To: <1455612172-2081-1-git-send-email-peter.chen@nxp.com>
References: <1455612172-2081-1-git-send-email-peter.chen@nxp.com>
Message-ID: <1455871867.5745.3.camel@pengutronix.de>

Hi Peter,

Am Dienstag, den 16.02.2016, 16:42 +0800 schrieb Peter Chen:
> From: Peter Chen <peter.chen at freescale.com>
> 
> Although most of USB devices are hot-plug's, there are still some devices
> are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
> If these kinds of USB devices are multiple functions, and they can supply
> other interfaces like i2c, gpios for other devices, we may need to
> describe these at device tree.
> 
> In this commit, it uses "reg" in dts as physical port number to match
> the phyiscal port number decided by USB core, if they are the same,
> then the device node is for the device we are creating for USB core.
> 
> Signed-off-by: Peter Chen <peter.chen at freescale.com>
> ---
> Changes for v5:
> - Refine the code how to get the device node at usb_alloc_dev according
>   to Alan's comment.
> - Point out "usbVID,PID" is the recommented compatible, and others
>   compatibles at binding doc could also be used.
> 
> Changes for v4:
> - The range of "reg" should be 1-31, changing device node address
>   style as in lower case hexadecimal with leading zeroes suppressed
>   [binding doc, usb-device.txt]
> - Improve the example at binding doc, it describes node from the top
>   (the controller)
> - Delete the struct of_node * within struct usb_device
> - Using usb_hcd_find_raw_port_number to get raw port number under root
>   hub port
> 
> Changes for v3:
> - typo: s/descirbe/describe/
> 
> Changes for v2:
> - Fix build error reported by kbuild robot, lack of "static" for
>   inline usb_of_get_child_node
> - Fix typo, "devcie_node" -> "device_node"
> - Add kernel-doc for of_node at struct usb_device
> 
> Changes from RFC:
> - Fix the error address for binding doc, and add compatible for binding doc
> - Change get child node API from "usb_of_find_node" to
>   "usb_of_get_child_node"
> - Delete unecessary header files
> - One typo
> 
>  .../devicetree/bindings/usb/usb-device.txt         | 26 ++++++++++++
>  drivers/usb/core/Makefile                          |  2 +-
>  drivers/usb/core/of.c                              | 47 ++++++++++++++++++++++
>  drivers/usb/core/usb.c                             | 10 +++++
>  include/linux/usb/of.h                             |  7 ++++
>  5 files changed, 91 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/usb-device.txt
>  create mode 100644 drivers/usb/core/of.c
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt b/Documentation/devicetree/bindings/usb/usb-device.txt
> new file mode 100644
> index 0000000..a997a23
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/usb-device.txt
> @@ -0,0 +1,26 @@
> +Generic USB Device Properties
> +
> +Usually, we only use device tree for hard wired USB device.
> +The reference binding doc is from:
> +http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
> +
> +Required properties:
> +- compatible: usbVID,PID. The other compatible strings from the above
> +  standard binding could also be used, but a device adhering to this
> +  binding may leave out all except for usbVID,PID.

I asked to document the format of VID and PID ("lower case hexadecimal
with leading zeroes suppressed") here.

> +- reg: the port number which this device is connecting to, the range
> +  is 1-31.
> +
> +Example:
> +
> +&usb1 {
> +	status = "okay";
> +
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +
> +	hub: genesys at 1 {
> +		compatible = "usb05e3,0608";

This should be:
		compatible = "usb5e3,608";

After those two issues are fixed,
Acked-by: Philipp Zabel <p.zabel at pengutronix.de>

best regards
Philipp




From linus.walleij at linaro.org  Fri Feb 19 01:03:12 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 19 Feb 2016 10:03:12 +0100
Subject: [PATCH V2 1/2] pinctrl: mediatek: Modify pinctrl bindings for
 mt7623
In-Reply-To: <1455866238-6102-1-git-send-email-blogic@openwrt.org>
References: <1455866238-6102-1-git-send-email-blogic@openwrt.org>
Message-ID: <CACRpkdYiQop2qDNuh4N2YZy2DTy9mOEyERro8hT4YogCPc2LGw@mail.gmail.com>

On Fri, Feb 19, 2016 at 8:17 AM, John Crispin <blogic at openwrt.org> wrote:

> Signed-off-by: John Crispin <blogic at openwrt.org>
> Cc: devicetree at vger.kernel.org
> ---
> please apply to the devel-mt2701 branch
>
> Changes in V2
> * make mt7623-pinfunc.h part of patch 1/2
> * make sure the list stays sorted

Patch applied unless the Mediatek maintainers come with serious
remarks (I can always revert).

Only minor comments from Yingjoe on the previous version so I guess
it is finished.

MTK guys: do you even have this SoC? It appears MTK is churning out
a plethora of SoCs and then they land in the lap of the OpenWRT
developers before the MTK maintainers even start to look at it...

Yours,
Linus Walleij


From arnd at arndb.de  Fri Feb 19 01:03:51 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 10:03:51 +0100
Subject: [PATCH 8/9] ARM: do not use optimized do_div for ARMv3
In-Reply-To: <alpine.LFD.2.20.1602181215310.13632@knanqh.ubzr>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-9-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602181215310.13632@knanqh.ubzr>
Message-ID: <13253932.bg5yHHtIOq@wuerfel>

On Thursday 18 February 2016 12:20:51 Nicolas Pitre wrote:
> On Thu, 18 Feb 2016, Arnd Bergmann wrote:
> 
> > The gcc-4.9 optimization goes wrong while building target_core_iblock.c
> > for ARMv3 and leaves a bogus reference to __aeabi_uldivmod in the
> > output:
> > 
> > ERROR: "__aeabi_uldivmod" [drivers/target/target_core_iblock.ko] undefined!
> > 
> > I could not find anyone who is interested in fixing it in gcc,
> > so as a workaround this disables the do_div magic, just like
> > we do for old compilers and for OABI.
> > 
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> 
> I suppose this is good enough for the purpose of keeping RiscPC 
> buildable. Whether or not it is still used is another question.  If it 
> is then its user probably expects it to be slow already.
> 
> Acked-by: Nicolas Pitre <nico at linaro.org>

Thanks.

> Still unfortunate having to use a big hammer such as -march=armv3 just 
> to avoid halfword memory accesses.

I brought this up with the gcc developers before. They would really want
to deprecated ARMv3 support, but nobody seems interested in implementing
halfword memory access as a replacement.

FWIW, I am currently still allowing ARMv3 in randconfig builds, but
have run into 12 internal compiler errors with that, on gcc-4.9 or higher.
It's probably all the same bug, but I don't see this getting fixed
unless the RiscOS people update to a newer toolchain and run into the
same problem.

The patch below disables optimization so I am able to build this, but
I see no way to fix this upstream.

	Arnd

 arch/arm/boot/compressed/Makefile            |    3 +++
 drivers/block/aoe/Makefile                   |    3 +++
 drivers/block/paride/Makefile                |    3 +++
 drivers/net/Makefile                         |    7 +++++++
 drivers/net/ethernet/apm/xgene/Makefile      |    4 ++++
 drivers/staging/lustre/lustre/llite/Makefile |    4 ++++
 fs/fat/Makefile                              |    4 ++++
 kernel/Makefile                              |    3 +++
 lib/zlib_inflate/Makefile                    |    4 ++++
 net/decnet/Makefile                          |    4 ++++
 net/irda/Makefile                            |    4 ++++
 11 files changed, 43 insertions(+)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index b5db4c868640..f000efa55003 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -9,6 +9,9 @@ OBJS		=
 AFLAGS_head.o += -DTEXT_OFFSET=$(TEXT_OFFSET)
 HEAD	= head.o
 OBJS	+= misc.o decompress.o
+ifdef CONFIG_CPU_32v3
+CFLAGS_decompress.o += -O0
+endif
 ifeq ($(CONFIG_DEBUG_UNCOMPRESS),y)
 OBJS	+= debug.o
 endif
diff --git a/drivers/block/aoe/Makefile b/drivers/block/aoe/Makefile
index 06ea82cdf27d..7007fe7a14ce 100644
--- a/drivers/block/aoe/Makefile
+++ b/drivers/block/aoe/Makefile
@@ -4,3 +4,6 @@
 
 obj-$(CONFIG_ATA_OVER_ETH)	+= aoe.o
 aoe-y := aoeblk.o aoechr.o aoecmd.o aoedev.o aoemain.o aoenet.o
+ifdef CONFIG_CPU_32v3
+CFLAGS_aoechr.o += -O0
+endif
diff --git a/drivers/block/paride/Makefile b/drivers/block/paride/Makefile
index a539e004bb7a..26ac7c329e4b 100644
--- a/drivers/block/paride/Makefile
+++ b/drivers/block/paride/Makefile
@@ -11,6 +11,9 @@ obj-$(CONFIG_PARIDE_BPCK)	+= bpck.o
 obj-$(CONFIG_PARIDE_COMM)	+= comm.o
 obj-$(CONFIG_PARIDE_DSTR)	+= dstr.o
 obj-$(CONFIG_PARIDE_KBIC)	+= kbic.o
+ifdef CONFIG_CPU_32v3
+CFLAGS_kbic.o += -O0
+endif
 obj-$(CONFIG_PARIDE_EPAT)	+= epat.o
 obj-$(CONFIG_PARIDE_EPIA)	+= epia.o
 obj-$(CONFIG_PARIDE_FRPW)	+= frpw.o
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 900b0c5320bb..a249ae2a5c9b 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -12,6 +12,10 @@ obj-$(CONFIG_EQUALIZER) += eql.o
 obj-$(CONFIG_IFB) += ifb.o
 obj-$(CONFIG_MACVLAN) += macvlan.o
 obj-$(CONFIG_MACVTAP) += macvtap.o
+ifdef CONFIG_CPU_32v3
+CFLAGS_macvtap.o += -O1
+endif
+
 obj-$(CONFIG_MII) += mii.o
 obj-$(CONFIG_MDIO) += mdio.o
 obj-$(CONFIG_NET) += Space.o loopback.o
@@ -70,3 +74,6 @@ obj-$(CONFIG_HYPERV_NET) += hyperv/
 obj-$(CONFIG_NTB_NETDEV) += ntb_netdev.o
 
 obj-$(CONFIG_FUJITSU_ES) += fjes/
+ifdef CONFIG_CPU_32v3
+CFLAGS_tun.o += -O1
+endif
diff --git a/drivers/net/ethernet/apm/xgene/Makefile b/drivers/net/ethernet/apm/xgene/Makefile
index 700b5abe5de5..b357127e77ed 100644
--- a/drivers/net/ethernet/apm/xgene/Makefile
+++ b/drivers/net/ethernet/apm/xgene/Makefile
@@ -5,3 +5,7 @@
 xgene-enet-objs := xgene_enet_hw.o xgene_enet_sgmac.o xgene_enet_xgmac.o \
 		   xgene_enet_main.o xgene_enet_ring2.o xgene_enet_ethtool.o
 obj-$(CONFIG_NET_XGENE) += xgene-enet.o
+
+ifdef CONFIG_CPU_32v3
+CFLAGS_xgene_enet_main.o += -O1
+endif
diff --git a/drivers/staging/lustre/lustre/llite/Makefile b/drivers/staging/lustre/lustre/llite/Makefile
index 9ac29e718da3..7ebe6c751448 100644
--- a/drivers/staging/lustre/lustre/llite/Makefile
+++ b/drivers/staging/lustre/lustre/llite/Makefile
@@ -8,3 +8,7 @@ lustre-y := dcache.o dir.o file.o llite_close.o llite_lib.o llite_nfs.o \
 	    vvp_dev.o vvp_page.o vvp_lock.o vvp_io.o vvp_object.o lproc_llite.o
 
 llite_lloop-y := lloop.o
+
+ifdef CONFIG_CPU_32v3
+CFLAGS_file.o += -O1
+endif
diff --git a/fs/fat/Makefile b/fs/fat/Makefile
index 964b634f6667..b33feac5df36 100644
--- a/fs/fat/Makefile
+++ b/fs/fat/Makefile
@@ -9,3 +9,7 @@ obj-$(CONFIG_MSDOS_FS) += msdos.o
 fat-y := cache.o dir.o fatent.o file.o inode.o misc.o nfs.o
 vfat-y := namei_vfat.o
 msdos-y := namei_msdos.o
+
+ifdef CONFIG_CPU_32v3
+CFLAGS_dir.o += -O0
+endif
diff --git a/kernel/Makefile b/kernel/Makefile
index f0c40bf49d9f..d0c818182fd8 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -55,6 +55,9 @@ ifneq ($(CONFIG_SMP),y)
 obj-y += up.o
 endif
 obj-$(CONFIG_UID16) += uid16.o
+ifdef CONFIG_CPU_32v3
+CFLAGS_uid16.o += -O0
+endif
 obj-$(CONFIG_MODULES) += module.o
 obj-$(CONFIG_MODULE_SIG) += module_signing.o
 obj-$(CONFIG_KALLSYMS) += kallsyms.o
diff --git a/lib/zlib_inflate/Makefile b/lib/zlib_inflate/Makefile
index 49f8ce5774d2..d99fd57d0d34 100644
--- a/lib/zlib_inflate/Makefile
+++ b/lib/zlib_inflate/Makefile
@@ -17,3 +17,7 @@ obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate.o
 
 zlib_inflate-objs := inffast.o inflate.o infutil.o \
 		     inftrees.o inflate_syms.o
+
+ifdef CONFIG_CPU_32v3
+CFLAGS_inffast.o += -O0
+endif
diff --git a/net/decnet/Makefile b/net/decnet/Makefile
index e44003af71f6..a99608c9bd93 100644
--- a/net/decnet/Makefile
+++ b/net/decnet/Makefile
@@ -8,3 +8,7 @@ decnet-y += sysctl_net_decnet.o
 
 obj-$(CONFIG_NETFILTER) += netfilter/
 
+ifdef CONFIG_CPU_32v3
+CFLAGS_dn_table.o += -O1
+endif
+
diff --git a/net/irda/Makefile b/net/irda/Makefile
index 187f6c563a4b..d1801fda7865 100644
--- a/net/irda/Makefile
+++ b/net/irda/Makefile
@@ -13,3 +13,7 @@ irda-y := iriap.o iriap_event.o irlmp.o irlmp_event.o irlmp_frame.o \
 	  discovery.o parameters.o irnetlink.o irmod.o
 irda-$(CONFIG_PROC_FS) += irproc.o
 irda-$(CONFIG_SYSCTL) += irsysctl.o
+
+ifdef CONFIG_CPU_32v3
+CFLAGS_wrapper.o += -O0
+endif



From linus.walleij at linaro.org  Fri Feb 19 01:09:07 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 19 Feb 2016 10:09:07 +0100
Subject: [PATCH V2 2/2] pinctrl: mediatek: Add Pinctrl/GPIO/EINT driver
 for MT7623
In-Reply-To: <1455866238-6102-2-git-send-email-blogic@openwrt.org>
References: <1455866238-6102-1-git-send-email-blogic@openwrt.org>
 <1455866238-6102-2-git-send-email-blogic@openwrt.org>
Message-ID: <CACRpkdbK7vJDgVHFaQFcULtUmBKN_b_Z5usgYVk67jxH-cKwaA@mail.gmail.com>

On Fri, Feb 19, 2016 at 8:17 AM, John Crispin <blogic at openwrt.org> wrote:

> Add the driver and header files required to make pinctrl work on MediaTek
> MT7623.
>
> Signed-off-by: John Crispin <blogic at openwrt.org>
> ---
> please apply to the devel-mt2701 branch
>
> Changes in V2
> * fix typo in Kconfig
> * move mt7623-pinfunc.h into 1/2

Patch applied, thanks for your efforts to support this SoC.
I had to do some manual fixup for Makefile, I think it looks
allright now.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Fri Feb 19 01:11:29 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 19 Feb 2016 10:11:29 +0100
Subject: [PATCH v7 1/3] gpio: xgene: Enable X-Gene standby GPIO as
 interrupt controller
In-Reply-To: <1455714909-3027-2-git-send-email-qnguyen@apm.com>
References: <1455714909-3027-1-git-send-email-qnguyen@apm.com>
 <1455714909-3027-2-git-send-email-qnguyen@apm.com>
Message-ID: <CACRpkdaH7CLZDK9HP1nCYioPVbypQsZ76ZJcPMPLjVzV-DWqDQ@mail.gmail.com>

On Wed, Feb 17, 2016 at 2:15 PM, Quan Nguyen <qnguyen at apm.com> wrote:

> Enable X-Gene standby GPIO controller as interrupt controller to provide
> its own resources. This avoids ambiguity where GIC interrupt resource is
> use as X-Gene standby GPIO interrupt resource in user driver.
>
> Signed-off-by: Y Vo <yvo at apm.com>
> Signed-off-by: Quan Nguyen <qnguyen at apm.com>
> Acked-by: Marc Zyngier <marc.zyngier at arm.com>

Sweet! Patch applied.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Fri Feb 19 01:13:17 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 19 Feb 2016 10:13:17 +0100
Subject: [PATCH v7 2/3] Documentation: gpio: Update description for X-Gene
 standby GPIO controller DTS binding
In-Reply-To: <1455714909-3027-3-git-send-email-qnguyen@apm.com>
References: <1455714909-3027-1-git-send-email-qnguyen@apm.com>
 <1455714909-3027-3-git-send-email-qnguyen@apm.com>
Message-ID: <CACRpkdYRTrfjzVG28mJr3uFmaJw_siDjUtcVY-isb3JqJMTJTQ@mail.gmail.com>

On Wed, Feb 17, 2016 at 2:15 PM, Quan Nguyen <qnguyen at apm.com> wrote:

> Update description for X-Gene standby GPIO controller DTS binding to
> support GPIO line configuration as input, output or external IRQ pin.
>
> Signed-off-by: Y Vo <yvo at apm.com>
> Signed-off-by: Quan Nguyen <qnguyen at apm.com>

Patch applied. But I cut down the subject line a bit.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Fri Feb 19 01:14:01 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 19 Feb 2016 10:14:01 +0100
Subject: [PATCH v7 3/3] arm64: dts: Update X-Gene standby GPIO controller
 DTS entries
In-Reply-To: <1455714909-3027-4-git-send-email-qnguyen@apm.com>
References: <1455714909-3027-1-git-send-email-qnguyen@apm.com>
 <1455714909-3027-4-git-send-email-qnguyen@apm.com>
Message-ID: <CACRpkdav6UXn41UnWvWR4zjYN=QtkNJknihr+YnHu3rXbkPBBw@mail.gmail.com>

On Wed, Feb 17, 2016 at 2:15 PM, Quan Nguyen <qnguyen at apm.com> wrote:

> Update APM X-Gene standby GPIO controller DTS entries to enable it
> as interrupt controller.
>
> Signed-off-by: Y Vo <yvo at apm.com>
> Signed-off-by: Quan Nguyen <qnguyen at apm.com>

Reviewed-by: Linus Walleij <linus.walleij at linaro.org>

Please funnel this patch through the ARM SoC tree with all other
DTS files.

Yours,
Linus Walleij


From p.zabel at pengutronix.de  Fri Feb 19 01:12:25 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 19 Feb 2016 10:12:25 +0100
Subject: [PATCH v10 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
In-Reply-To: <1455870678-13959-2-git-send-email-jitao.shi@mediatek.com>
References: <1455870678-13959-1-git-send-email-jitao.shi@mediatek.com>
 <1455870678-13959-2-git-send-email-jitao.shi@mediatek.com>
Message-ID: <1455873145.5745.10.camel@pengutronix.de>

Am Freitag, den 19.02.2016, 16:31 +0800 schrieb Jitao Shi:
> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
> 
> Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> ---
> Changes since v9:
>  - replace dev_kmalloc with devm_kmalloc in ps8640_get_modes
>  - remove ps_bridge->dsi = devm_kzalloc(dev, sizeof(struct mipi_dsi_device),
> 					GFP_KERNEL);
>  - fix wrong condition in ps8640_validate_firmware()
> 
> The following patches are needed to support dsi host through none dsi bus:
> 
> https://patchwork.kernel.org/patch/8289181/ ("drm/dsi: check for CONFIG_OF when defining")
> https://patchwork.kernel.org/patch/8289051/ ("drm/dsi: Use mipi_dsi_device_register_full for DSI device")
> https://patchwork.kernel.org/patch/8289081/ ("drm/dsi: Try to match non-DT DSI devices")
> https://patchwork.kernel.org/patch/8289121/ ("drm/dsi: Add routine to unregister a DSI device")
> https://patchwork.kernel.org/patch/8289091/ ("drm/dsi: Get DSI host by DT device node")
> ---
>  drivers/gpu/drm/bridge/Kconfig         |   11 +
>  drivers/gpu/drm/bridge/Makefile        |    1 +
>  drivers/gpu/drm/bridge/parade-ps8640.c | 1057 ++++++++++++++++++++++++++++++++
>  3 files changed, 1069 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 27e2022..b4edd8c 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -40,4 +40,15 @@ config DRM_PARADE_PS8622
>  	---help---
>  	  Parade eDP-LVDS bridge chip driver.
>  
> +config DRM_PARADE_PS8640
> +	tristate "Parade PS8640 MIPI DSI to eDP Converter"
> +	depends on OF && I2C
> +	select DRM_KMS_HELPER
> +	select DRM_MIPI_DSI
> +	select DRM_PANEL
> +	---help---
> +	  Choose this option if you have PS8640 for display
> +	  The PS8640 is a high-performance and low-power
> +	  MIPI DSI to eDP converter
> +
>  endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index f13c33d..fbe38dc 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c
> new file mode 100644
> index 0000000..5f27548
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -0,0 +1,1057 @@
> +/*
> + * Copyright (c) 2014 MediaTek Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/firmware.h>
> +#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_gpio.h>
> +#include <linux/of_graph.h>
> +#include <linux/regulator/consumer.h>
> +#include <asm/unaligned.h>
> +#include <drm/drm_panel.h>
> +
> +#include <drmP.h>
> +#include <drm_atomic_helper.h>
> +#include <drm_crtc_helper.h>
> +#include <drm_crtc.h>
> +#include <drm_edid.h>
> +#include <drm_mipi_dsi.h>
> +
> +#define PAGE2_SPI_CFG3		0x82
> +#define I2C_TO_SPI_RESET	0x20
> +#define PAGE2_ROMADD_BYTE1	0x8e
> +#define PAGE2_ROMADD_BYTE2	0x8f
> +#define PAGE2_SWSPI_WDATA	0x90
> +#define PAGE2_SWSPI_RDATA	0x91
> +#define PAGE2_SWSPI_LEN		0x92
> +#define PAGE2_SWSPI_CTL		0x93
> +#define TRIGGER_NO_READBACK	0x05
> +#define TRIGGER_READBACK	0x01
> +#define PAGE2_SPI_STATUS	0x9e
> +#define PAGE2_GPIO_L		0xa6
> +#define PAGE2_GPIO_H		0xa7
> +#define PS_GPIO9		BIT(1)
> +#define PAGE2_IROM_CTRL		0xb0
> +#define IROM_ENABLE		0xc0
> +#define IROM_DISABLE		0x80
> +#define PAGE2_SW_REST		0xbc
> +#define SPI_SW_RESET		BIT(7)
> +#define MPU_SW_RESET		BIT(6)
> +#define PAGE2_ENCTLSPI_WR	0xda
> +#define PAGE2_I2C_BYPASS	0xea
> +#define I2C_BYPASS_EN		0xd0
> +#define PAGE3_SET_ADD		0xfe
> +#define PAGE3_SET_VAL		0xff
> +#define VDO_CTL_ADD		0x13
> +#define VDO_DIS			0x18
> +#define VDO_EN			0x1c
> +#define PAGE4_REV_L		0xf0
> +#define PAGE4_REV_H		0xf1
> +#define PAGE4_CHIP_L		0xf2
> +#define PAGE4_CHIP_H		0xf3
> +
> +/* Firmware */
> +#define SPI_MAX_RETRY_CNT	8
> +#define PS_FW_NAME		"ps864x_fw.bin"
> +
> +#define FW_CHIP_ID_OFFSET	0
> +#define FW_VERSION_OFFSET	2
> +#define EDID_I2C_ADDR		0x50
> +
> +#define WRITE_STATUS_REG_CMD	0x01
> +#define READ_STATUS_REG_CMD	0x05
> +#define CLEAR_ALL_PROTECT	0x00
> +#define BLK_PROTECT_BITS	0x0c
> +#define STATUS_REG_PROTECT	BIT(7)
> +#define WRITE_ENABLE_CMD	0x06
> +#define CHIP_ERASE_CMD		0xc7
> +
> +#define bridge_to_ps8640(e)	container_of(e, struct ps8640, bridge)
> +#define connector_to_ps8640(e)	container_of(e, struct ps8640, connector)
> +
> +struct ps8640_info {
> +	u8 family_id;
> +	u8 variant_id;
> +	u16 version;
> +};
> +
> +struct ps8640 {
> +	struct drm_connector connector;
> +	struct drm_bridge bridge;
> +	struct edid *edid;
> +	struct mipi_dsi_device dsi;
> +	struct i2c_client *page[8];
> +	struct i2c_client *ddc_i2c;
> +	struct regulator_bulk_data supplies[2];
> +	struct drm_panel *panel;
> +	struct gpio_desc *gpio_rst_n;
> +	struct gpio_desc *gpio_slp_n;
> +	struct gpio_desc *gpio_mode_sel_n;
> +	bool enabled;
> +
> +	/* firmware file info */
> +	bool in_fw_update;
> +	struct ps8640_info info;
> +};
> +
> +static const u8 enc_ctrl_code[6] = {0xaa, 0x55, 0x50, 0x41, 0x52, 0x44};
> +
> +static int ps8640_read(struct i2c_client *client, u8 reg, u8 *data,
> +		       u16 data_len)
> +{
> +	int ret;
> +	struct i2c_msg msgs[] = {
> +		{
> +		 .addr = client->addr,
> +		 .flags = 0,
> +		 .len = 1,
> +		 .buf = &reg,
> +		 },
> +		{
> +		 .addr = client->addr,
> +		 .flags = I2C_M_RD,
> +		 .len = data_len,
> +		 .buf = data,
> +		 }
> +	};
> +
> +	ret = i2c_transfer(client->adapter, msgs, 2);
> +
> +	if (ret == 2)
> +		return 0;
> +	if (ret < 0)
> +		return ret;
> +	else
> +		return -EIO;
> +}
> +
> +static int ps8640_write_bytes(struct i2c_client *client, u8 *data,
> +			      u16 data_len)
> +{
> +	int ret;
> +	struct i2c_msg msg;
> +
> +	msg.addr = client->addr;
> +	msg.flags = 0;
> +	msg.len = data_len;
> +	msg.buf = data;
> +
> +	ret = i2c_transfer(client->adapter, &msg, 1);
> +	if (ret == 1)
> +		return 0;
> +	if (ret < 0)
> +		return ret;
> +	else
> +		return -EIO;
> +}
> +
> +static int ps8640_write_byte(struct i2c_client *client, u8 reg,  u8 data)
> +{
> +	int ret;
> +	struct i2c_msg msg;
> +	u8 buf[] = {reg, data};
> +
> +	msg.addr = client->addr;
> +	msg.flags = 0;
> +	msg.len = sizeof(buf);
> +	msg.buf = buf;
> +
> +	ret = i2c_transfer(client->adapter, &msg, 1);
> +	if (ret == 1)
> +		return 0;
> +	if (ret < 0)
> +		return ret;
> +	else
> +		return -EIO;
> +}
> +
> +static void ps8640_get_mcu_fw_version(struct ps8640 *ps_bridge)
> +{
> +	struct i2c_client *client = ps_bridge->page[5];
> +	u8 fw_ver[2];
> +
> +	ps8640_read(client, 0x4, fw_ver, 2);
> +	ps_bridge->info.version = (fw_ver[0] << 8) | fw_ver[1];
> +
> +	DRM_INFO_ONCE("ps8640 rom fw version %d.%d\n", fw_ver[0], fw_ver[1]);
> +}
> +
> +static int ps8640_bridge_enable(struct ps8640 *ps_bridge)
> +{
> +	struct i2c_client *client = ps_bridge->page[3];
> +	u8 vdo_ctrl_buf[3] = {PAGE3_SET_ADD, VDO_CTL_ADD, VDO_EN};
> +
> +	return ps8640_write_bytes(client, vdo_ctrl_buf, 3);
> +}
> +
> +static int ps8640_bridge_disable(struct ps8640 *ps_bridge)
> +{
> +	struct i2c_client *client = ps_bridge->page[3];
> +	u8 vdo_ctrl_buf[3] = {PAGE3_SET_ADD, VDO_CTL_ADD, VDO_DIS};
> +
> +	return ps8640_write_bytes(client, vdo_ctrl_buf, 3);
> +}
> +
> +static void ps8640_pre_enable(struct drm_bridge *bridge)
> +{
> +	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> +	struct i2c_client *client = ps_bridge->page[2];
> +	int err, retry_cnt = 0;
> +	u8 set_vdo_done;
> +
> +	if (ps_bridge->in_fw_update)
> +		return;
> +
> +	if (ps_bridge->enabled)
> +		return;
> +
> +	err = drm_panel_prepare(ps_bridge->panel);
> +	if (err < 0) {
> +		DRM_ERROR("failed to prepare panel: %d\n", err);
> +		return;
> +	}
> +
> +	gpiod_set_value(ps_bridge->gpio_slp_n, 1);

Is this part:

> +	gpiod_set_value(ps_bridge->gpio_rst_n, 0);
> +
> +	err = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
> +				    ps_bridge->supplies);
> +	if (err < 0) {
> +		DRM_ERROR("cannot enable regulators %d\n", err);
> +		goto err_panel_unprepare;
> +	}
> +
> +	usleep_range(500, 700);
> +	gpiod_set_value(ps_bridge->gpio_rst_n, 1);

.. until here an assertion of the reset for 500 ?s plus whatever the
regulator delay is (if any)? It looks like the reset actually is active
low. If so, I think this code should rather be:

	gpiod_set_value(ps_bridge->gpio_rst_n, 1);
	regulator_bulk_enable();
	usleep_range();
	gpiod_set_value(ps_bridge->gpio_rst_n, 0);

And the device tree should contain a reset-gpios property with the
GPIO_ACTIVE_LOW flag set.

Same goes for sleep GPIO, if it is active low, too.

best regards
Philipp



From p.zabel at pengutronix.de  Fri Feb 19 01:13:30 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 19 Feb 2016 10:13:30 +0100
Subject: [PATCH v10 1/2] Documentation: bridge: Add documentation for
 ps8640 DT properties
In-Reply-To: <1455870678-13959-1-git-send-email-jitao.shi@mediatek.com>
References: <1455870678-13959-1-git-send-email-jitao.shi@mediatek.com>
Message-ID: <1455873210.13163.0.camel@pengutronix.de>

Am Freitag, den 19.02.2016, 16:31 +0800 schrieb Jitao Shi:
> Add documentation for DT properties supported by
> ps8640 DSI-eDP converter.
> 
> Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> Acked-by: Rob Herring <robh at kernel.org>
> Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
> ---
> Changes since v9:
>  - No change
> ---
>  .../devicetree/bindings/display/bridge/ps8640.txt  |   43 ++++++++++++++++++++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.txt b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
> new file mode 100644
> index 0000000..a3e0971
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
> @@ -0,0 +1,43 @@
> +ps8640-bridge bindings
> +
> +Required properties:
> +	- compatible: "parade,ps8640"
> +	- reg: first page address of the bridge.
> +	- sleep-gpios: OF device-tree gpio specification for PD_ pin.
> +	- reset-gpios: OF device-tree gpio specification for reset pin.
> +	- mode-sel-gpios: OF device-tree gpio specification for mode-sel pin.
> +	- vdd12-supply: OF device-tree regulator specification for 1.2V power.
> +	- vdd33-supply: OF device-tree regulator specification for 3.3V power.
> +	- ports: The device node can contain video interface port nodes per
> +		 the video-interfaces bind[1]. For port at 0,set the reg = <0> as
> +		 ps8640 dsi in and port at 1,set the reg = <1> as ps8640 eDP out.
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +	edp-bridge at 18 {
> +		compatible = "parade,ps8640";
> +		reg = <0x18>;
> +		sleep-gpios = <&pio 116 GPIO_ACTIVE_HIGH>;
> +		reset-gpios = <&pio 115 GPIO_ACTIVE_HIGH>;

Are these two really active high? See my comments on the driver patch.

regards
Philipp




From Sanjeev_Sharma at mentor.com  Fri Feb 19 01:18:29 2016
From: Sanjeev_Sharma at mentor.com (Sharma, Sanjeev)
Date: Fri, 19 Feb 2016 09:18:29 +0000
Subject: [PATCH] PCI: imx6:don't sleep in atomic context
In-Reply-To: <20160218150852.GA17588@localhost>
References: <1447066080-5859-1-git-send-email-sanjeev_sharma@mentor.com>
 <20160106220430.GC16231@localhost>
 <FDC088D3B5555644AE135ED28A7ABDE986504C90@EU-MBX-04.mgc.mentorg.com>
 <20160218150852.GA17588@localhost>
Message-ID: <FDC088D3B5555644AE135ED28A7ABDE986505224@EU-MBX-04.mgc.mentorg.com>

-----Original Message-----
From: Bjorn Helgaas [mailto:helgaas at kernel.org] 
Sent: Thursday, February 18, 2016 8:39 PM
To: Sharma, Sanjeev
Cc: Richard.Zhu at freescale.com; l.stach at pengutronix.de; bhelgaas at google.com; linux-pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; David Mueller
Subject: Re: [PATCH] PCI: imx6:don't sleep in atomic context

On Thu, Feb 18, 2016 at 07:17:41AM +0000, Sharma, Sanjeev wrote:
> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas at kernel.org]
> Sent: Thursday, January 07, 2016 3:35 AM
> To: Sharma, Sanjeev
> Cc: Richard.Zhu at freescale.com; l.stach at pengutronix.de; 
> bhelgaas at google.com; linux-pci at vger.kernel.org; 
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org; 
> David Mueller
> Subject: Re: [PATCH] PCI: imx6:don't sleep in atomic context
> 
> Hi Sanjeev,
> 
> On Mon, Nov 09, 2015 at 04:18:00PM +0530, Sanjeev Sharma wrote:
> > If additional PCIe switch get connected between the host and the 
> > NIC,the kernel crashes with "BUG:
> > scheduling while atomic". To handle this we need to call mdelay() 
> > instead of usleep_range().
> > 
> > For more detail please refer bugzilla.kernel.org, Bug
> > 100031
> > 
> > Signed-off-by: Sanjeev Sharma <sanjeev_sharma at mentor.com>
> > Signed-off-by: David Mueller <dave.mueller at gmx.ch>
> 
> I'm dropping this for now because we've been kicking around the same solution (with tweaks to the mdelay amount) since June, but no progress on the *real* issue, which is that imx6_pcie_link_up() should never wait; it should simply return the link status.
> 
> I'm pretty sure the amount of time I've spent looking into this would have been enough to make some progress on that underlying issue.
> 
> Bjorn
> 
> Ok ! please share the change you are planning to implement. 

I didn't mean I personally was going to do this.  But I think Lucas stepped up and did it:

https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/host-imx6&id=4d107d3b5a686b5834e533a00b73bf7b1cf59df7

Thanks Bjorn 

code look ok !

> > ---
> >  drivers/pci/host/pci-imx6.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pci/host/pci-imx6.c 
> > b/drivers/pci/host/pci-imx6.c index 233a196..9769b13 100644
> > --- a/drivers/pci/host/pci-imx6.c
> > +++ b/drivers/pci/host/pci-imx6.c
> > @@ -499,7 +499,7 @@ static int imx6_pcie_link_up(struct pcie_port *pp)
> >  		 * Wait a little bit, then re-check if the link finished
> >  		 * the training.
> >  		 */
> > -		usleep_range(1000, 2000);
> > +		mdelay(1000);
> >  	}
> >  	/*
> >  	 * From L0, initiate MAC entry to gen2 if EP/RC supports gen2.
> > --
> > 1.7.11.7
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" 
> > in the body of a message to majordomo at vger.kernel.org More majordomo 
> > info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" 
> in the body of a message to majordomo at vger.kernel.org More majordomo 
> info at  http://vger.kernel.org/majordomo-info.html


From blogic at openwrt.org  Fri Feb 19 01:23:47 2016
From: blogic at openwrt.org (John Crispin)
Date: Fri, 19 Feb 2016 10:23:47 +0100
Subject: [PATCH V2 1/2] pinctrl: mediatek: Modify pinctrl bindings for
 mt7623
In-Reply-To: <CACRpkdYiQop2qDNuh4N2YZy2DTy9mOEyERro8hT4YogCPc2LGw@mail.gmail.com>
References: <1455866238-6102-1-git-send-email-blogic@openwrt.org>
 <CACRpkdYiQop2qDNuh4N2YZy2DTy9mOEyERro8hT4YogCPc2LGw@mail.gmail.com>
Message-ID: <56C6DF23.3060202@openwrt.org>



On 19/02/2016 10:03, Linus Walleij wrote:
> On Fri, Feb 19, 2016 at 8:17 AM, John Crispin <blogic at openwrt.org> wrote:
> 
>> Signed-off-by: John Crispin <blogic at openwrt.org>
>> Cc: devicetree at vger.kernel.org
>> ---
>> please apply to the devel-mt2701 branch
>>
>> Changes in V2
>> * make mt7623-pinfunc.h part of patch 1/2
>> * make sure the list stays sorted
> 
> Patch applied unless the Mediatek maintainers come with serious
> remarks (I can always revert).
> 
> Only minor comments from Yingjoe on the previous version so I guess
> it is finished.
> 
> MTK guys: do you even have this SoC? It appears MTK is churning out
> a plethora of SoCs and then they land in the lap of the OpenWRT
> developers before the MTK maintainers even start to look at it...
> 
> Yours,
> Linus Walleij
> 

I am doing this work in close collaboration with MTK. It is contractual
work. MTK is huge and has many BUs, one of them is WCN, formerly known
as Ralink. I have supported their MIPS silicon for many years now so
asking me to also take care of the Wireless SoCs based on ARM was the
natural next step.

	John


From dyoung at redhat.com  Fri Feb 19 01:27:38 2016
From: dyoung at redhat.com (Dave Young)
Date: Fri, 19 Feb 2016 17:27:38 +0800
Subject: [PATCH v2 1/2] efi: esrt: use memremap not ioremap to access
 ESRT table in memory
In-Reply-To: <CAKv+Gu8RP21vw1Ht7UtkHsen2GMUNx8DikH-hLaezV+uZvWO-g@mail.gmail.com>
References: <1455535953-5056-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455535953-5056-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160218104407.GC2651@codeblueprint.co.uk>
 <CAKv+Gu_AW7PKJJOd2mbEu3LKJe+gNaPHnH=sgO=YXM_KWFyKxw@mail.gmail.com>
 <20160218132824.GE2651@codeblueprint.co.uk>
 <CAKv+Gu-s1pzYBzuDG-Z7s3gyo8dPOfeidZQ+rim-uAWZCBcKQQ@mail.gmail.com>
 <20160218134324.GG2651@codeblueprint.co.uk>
 <CAKv+Gu875r9RkDC723kNsG4XC0eSE9RPPmSFZrD0sx0QxS+V4g@mail.gmail.com>
 <20160218141544.GH2651@codeblueprint.co.uk>
 <CAKv+Gu8RP21vw1Ht7UtkHsen2GMUNx8DikH-hLaezV+uZvWO-g@mail.gmail.com>
Message-ID: <20160219092738.GA18240@dhcp-128-65.nay.redhat.com>

On 02/18/16 at 03:21pm, Ard Biesheuvel wrote:
> On 18 February 2016 at 15:15, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> > On Thu, 18 Feb, at 02:44:02PM, Ard Biesheuvel wrote:
> >> On 18 February 2016 at 14:43, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> >> > On Thu, 18 Feb, at 02:29:32PM, Ard Biesheuvel wrote:
> >> >> On 18 February 2016 at 14:28, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> >> >> > On Thu, 18 Feb, at 01:16:05PM, Ard Biesheuvel wrote:
> >> >> >> On 18 February 2016 at 11:44, Matt Fleming <matt at codeblueprint.co.uk> wrote:
> >> >> >> > On Mon, 15 Feb, at 12:32:32PM, Ard Biesheuvel wrote:
> >> >> >> >> On ARM and arm64, ioremap() and memremap() are not interchangeable like
> >> >> >> >> on x86, and the use of ioremap() on ordinary RAM is typically flagged
> >> >> >> >> as an error if the memory region being mapped is also covered by the
> >> >> >> >> linear mapping, since that would lead to aliases with conflicting
> >> >> >> >> cacheability attributes.
> >> >> >> >>
> >> >> >> >> Since what we are dealing with is not an I/O region with side effects,
> >> >> >> >> using ioremap() here is arguably incorrect anyway, so let's replace
> >> >> >> >> it with memremap instead. Also add a missing unmap on the success path,
> >> >> >> >> and drop a memblock_remove() call which does not belong here, this far
> >> >> >> >> into the boot sequence.
> >> >> >> >>
> >> >> >> >> Cc: Peter Jones <pjones at redhat.com>
> >> >> >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >> >> >> >> ---
> >> >> >> >>  drivers/firmware/efi/esrt.c | 16 ++++++++--------
> >> >> >> >>  1 file changed, 8 insertions(+), 8 deletions(-)
> >> >> >> >>
> >> >> >> >
> >> >> >> > [...]
> >> >> >> >
> >> >> >> >> @@ -432,8 +434,6 @@ static int __init esrt_sysfs_init(void)
> >> >> >> >>       if (error)
> >> >> >> >>               goto err_cleanup_list;
> >> >> >> >>
> >> >> >> >> -     memblock_remove(esrt_data, esrt_data_size);
> >> >> >> >> -
> >> >> >> >>       pr_debug("esrt-sysfs: loaded.\n");
> >> >> >> >>
> >> >> >> >>       return 0;
> >> >> >> >
> >> >> >> > Shouldn't we be replacing memblock_remove() with free_bootmem_late()?
> >> >> >> > The original ESRT region is still reserved at this point, so we should
> >> >> >> > do our best to release it to the page allocator.
> >> >> >>
> >> >> >> I'd rather we keep it reserved. That way, the config table entry still
> >> >> >> points to something valid, which could be useful for kexec(), I think?
> >> >> >> At least, that is how I intended to handle config tables on ARM ...
> >> >> >
> >> >> > If we're going to reserve it why do we need to copy the data out at
> >> >> > all in esrt_sysfs_init()?
> >> >>
> >> >> Excellent question. I don't think there is any point to doing that.
> >> >
> >> > ... Unless the data is contained in an EFI Boot Services region ;-)
> >> >
> >> > Peter?
> >>
> >> Yes, it usually is. Is that a problem?
> >
> > Yes, we free the Boot Services regions before hitting userspace on
> > x86, see efi_free_boot_services(). We do this map/copy/unmap trick in
> > the ACPI BGRT driver for that reason.
> >
> > The Boot Services regions can be many gigabytes in size, which makes
> > leaving them alone impractical.
> >
> > For kexec on x86 we simply discard the BGRT table, which isn't the end
> > of the world because who really needs access to the BGRT image on
> > kexec reboot? However, I can see the value of preserving the ESRT.
> >
> > I guess we've got two options, 1) copy out the chunks of Boot Services
> > regions we're interested in and rewrite the EFI tables to point at
> > these new allocations and free/discard all of the original Boot
> > Services regions or 2) only selectively free the Boot Services
> > regions.
> >
> > I've always stayed clear of 2) in case there exists cross-region
> > references in the data that isn't obvious. I'd like to think that
> > would never happen, but, you know, dragons lurk here, etc.
> >
> > Though actually, now I think about it, cross-region references can't
> > possibly exist because they'd cause issues with the current code.
> >
> > So maybe the best solution is actually 2), where we preserve the Boot
> > Services regions if any of the drivers (ESRT, BGRT) request them but
> > free all the others?

It is a good idea so that drivers can add their useful sections to
a list or an array, they can avoid another copy of the memory also.

> >
> > What are the lifetime rules for Boot Services regions on arm*?
> 
> We treat all Boot Services regions like Loader Code/Data or free
> regions: it is all recorded in memblock as usable memory, and only the
> regions that are explicitly reserved are protected from further
> general use.
> 
> I am currently looking into the memory attribute table, and the use
> case is very similar. It would be very useful from our pov to simply
> memblock_reserve() the region right after having called
> efi_config_parse_tables(), and actually consume its data when we get
> around to it later. The ESRT handling is already split down the middle
> in the same way.

A question is how can make a general way for both x86 and arm*.

Maybe change the efi_free_boot_mem to something like efi_clean_boot_mem?
It can first call efi_free_boot_mem, then reserve the ranges to be reserved
again, but it sounds odd though.

Thanks
Dave


From peter.chen at nxp.com  Fri Feb 19 01:26:15 2016
From: peter.chen at nxp.com (Peter Chen)
Date: Fri, 19 Feb 2016 17:26:15 +0800
Subject: [PATCH v6 1/1] USB: core: let USB device know device node
Message-ID: <1455873975-19531-1-git-send-email-peter.chen@nxp.com>

From: Peter Chen <peter.chen at freescale.com>

Although most of USB devices are hot-plug's, there are still some devices
are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
If these kinds of USB devices are multiple functions, and they can supply
other interfaces like i2c, gpios for other devices, we may need to
describe these at device tree.

In this commit, it uses "reg" in dts as physical port number to match
the phyiscal port number decided by USB core, if they are the same,
then the device node is for the device we are creating for USB core.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
Acked-by: Philipp Zabel <p.zabel at pengutronix.de>
Acked-by: Alan Stern <stern at rowland.harvard.edu>
Acked-by: Rob Herring <robh at kernel.org>
---

Changes for v6:
- Add textual representation for VID and PID in binding doc, and changing
  example accordingly.
- Add three Acks.

Changes for v5:
- Refine the code how to get the device node at usb_alloc_dev according
  to Alan's comment.
- Point out "usbVID,PID" is the recommented compatible, and others
  compatibles at binding doc could also be used.

Changes for v4:
- The range of "reg" should be 1-31, changing device node address
  style as in lower case hexadecimal with leading zeroes suppressed
  [binding doc, usb-device.txt]
- Improve the example at binding doc, it describes node from the top
  (the controller)
- Delete the struct of_node * within struct usb_device
- Using usb_hcd_find_raw_port_number to get raw port number under root
  hub port

Changes for v3:
- typo: s/descirbe/describe/

Changes for v2:
- Fix build error reported by kbuild robot, lack of "static" for
  inline usb_of_get_child_node
- Fix typo, "devcie_node" -> "device_node"
- Add kernel-doc for of_node at struct usb_device

Changes from RFC:
- Fix the error address for binding doc, and add compatible for binding doc
- Change get child node API from "usb_of_find_node" to
  "usb_of_get_child_node"
- Delete unecessary header files
- One typo

 .../devicetree/bindings/usb/usb-device.txt         | 28 +++++++++++++
 drivers/usb/core/Makefile                          |  2 +-
 drivers/usb/core/of.c                              | 47 ++++++++++++++++++++++
 drivers/usb/core/usb.c                             | 10 +++++
 include/linux/usb/of.h                             |  7 ++++
 5 files changed, 93 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/usb/usb-device.txt
 create mode 100644 drivers/usb/core/of.c

diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt b/Documentation/devicetree/bindings/usb/usb-device.txt
new file mode 100644
index 0000000..1c35e7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -0,0 +1,28 @@
+Generic USB Device Properties
+
+Usually, we only use device tree for hard wired USB device.
+The reference binding doc is from:
+http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
+
+Required properties:
+- compatible: usbVID,PID. The textual representation of VID, PID shall
+  be in lower case hexadecimal with leading zeroes suppressed. The
+  other compatible strings from the above standard binding could also
+  be used, but a device adhering to this binding may leave out all except
+  for usbVID,PID.
+- reg: the port number which this device is connecting to, the range
+  is 1-31.
+
+Example:
+
+&usb1 {
+	status = "okay";
+
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	hub: genesys at 1 {
+		compatible = "usb5e3,608";
+		reg = <1>;
+	};
+}
diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 2f6f932..9780877 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -5,7 +5,7 @@
 usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o
 usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o
 usbcore-y += devio.o notify.o generic.o quirks.o devices.o
-usbcore-y += port.o
+usbcore-y += port.o of.o
 
 usbcore-$(CONFIG_PCI)		+= hcd-pci.o
 usbcore-$(CONFIG_ACPI)		+= usb-acpi.o
diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
new file mode 100644
index 0000000..2289700
--- /dev/null
+++ b/drivers/usb/core/of.c
@@ -0,0 +1,47 @@
+/*
+ * of.c		The helpers for hcd device tree support
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen <peter.chen at freescale.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  of
+ * the License 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/of.h>
+
+/**
+ * usb_of_get_child_node - Find the device node match port number
+ * @parent: the parent device node
+ * @portnum: the port number which device is connecting
+ *
+ * Find the node from device tree according to its port number.
+ *
+ * Return: On success, a pointer to the device node, %NULL on failure.
+ */
+struct device_node *usb_of_get_child_node(struct device_node *parent,
+					int portnum)
+{
+	struct device_node *node;
+	u32 port;
+
+	for_each_child_of_node(parent, node) {
+		if (!of_property_read_u32(node, "reg", &port)) {
+			if (port == portnum)
+				return node;
+		}
+	}
+
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(usb_of_get_child_node);
+
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 524c982..ffa5cf1 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -36,6 +36,7 @@
 #include <linux/mutex.h>
 #include <linux/workqueue.h>
 #include <linux/debugfs.h>
+#include <linux/usb/of.h>
 
 #include <asm/io.h>
 #include <linux/scatterlist.h>
@@ -470,6 +471,7 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
 		dev->route = 0;
 
 		dev->dev.parent = bus->controller;
+		dev->dev.of_node = bus->controller->of_node;
 		dev_set_name(&dev->dev, "usb%d", bus->busnum);
 		root_hub = 1;
 	} else {
@@ -494,6 +496,14 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
 		dev->dev.parent = &parent->dev;
 		dev_set_name(&dev->dev, "%d-%s", bus->busnum, dev->devpath);
 
+		if (!parent->parent) {
+			/* device under root hub's port */
+			port1 = usb_hcd_find_raw_port_number(usb_hcd,
+				port1);
+		}
+		dev->dev.of_node = usb_of_get_child_node(parent->dev.of_node,
+				port1);
+
 		/* hub driver sets up TT records */
 	}
 
diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
index 974bce9..de3237f 100644
--- a/include/linux/usb/of.h
+++ b/include/linux/usb/of.h
@@ -16,6 +16,8 @@ enum usb_dr_mode of_usb_get_dr_mode_by_phy(struct device_node *phy_np);
 bool of_usb_host_tpl_support(struct device_node *np);
 int of_usb_update_otg_caps(struct device_node *np,
 			struct usb_otg_caps *otg_caps);
+struct device_node *usb_of_get_child_node(struct device_node *parent,
+			int portnum);
 #else
 static inline enum usb_dr_mode
 of_usb_get_dr_mode_by_phy(struct device_node *phy_np)
@@ -31,6 +33,11 @@ static inline int of_usb_update_otg_caps(struct device_node *np,
 {
 	return 0;
 }
+static inline struct device_node *usb_of_get_child_node
+		(struct device_node *parent, int portnum)
+{
+	return NULL;
+}
 #endif
 
 #if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_SUPPORT)
-- 
1.9.1



From tixy at linaro.org  Fri Feb 19 01:34:42 2016
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Fri, 19 Feb 2016 09:34:42 +0000
Subject: [PATCH 3/3] [RESEND] ARM: kprobes: use "I" constraint for
 inline assembly offsets
In-Reply-To: <56C61486.9070803@arm.com>
References: <1455815113-2562966-1-git-send-email-arnd@arndb.de>
 <1455815113-2562966-4-git-send-email-arnd@arndb.de>
 <1455819135.2958.6.camel@linaro.org> <56C61486.9070803@arm.com>
Message-ID: <1455874482.2864.29.camel@linaro.org>

On Thu, 2016-02-18 at 18:59 +0000, Robin Murphy wrote:
> On 18/02/16 18:12, Jon Medhurst (Tixy) wrote:
> > On Thu, 2016-02-18 at 18:05 +0100, Arnd Bergmann wrote:
> >> build-testing with clang showed that the "J" constraint does not take
> >> positive arguments on clang when building in for Thumb-2:
> >>
> >> core.c:540:3: error: invalid operand for inline asm constraint 'J'
> >>
> >> This has been reported as llvm bug https://llvm.org/bugs/show_bug.cgi?id=26061
> >>
> >> However, looking at the source code in depth, I found that the
> >> kernel is also wrong, and it should not use "J" at all, but should
> >> use "I" to pass an immediate argument to the inline assembly when that
> >> is used as an offset to an 'ldr' instruction rather than the 'sub'
> >> argument.
> >
> > This patch doesn't seem correct to me.
> >
> > The ARM ARM says the immediate offset to an ARM ldr instructions is "any
> > value in the range 0-4095" and offsets may be added or subtracted,
> > leading to values from ?4095 to 4095".
> >
> > And GCC machine constraints [1] says
> >
> > I
> >      Integer that is valid as an immediate operand in a data processing
> >      instruction. That is, an integer in the range 0 to 255 rotated by a
> >      multiple of 2
> > J
> >      Integer in the range ?4095 to 4095
> >
> > So the current use of 'J' seems correct to me.
> 
> Hmm, Arnd reports the failure when building for Thumb-2, and the code 
> under #ifdef CONFIG_THUMB2_KERNEL contains an ldrd, which takes a 
> different immediate of the form imm8 * 4. Maybe it's just operand %5 
> which needs fixing, although I don't see that a suitable constraint for 
> that actually exists...

Well, under Thumb-2 plain LDR is also different, the offset is up to
+/-255, except for pre-indexed without writeback mode (what the code
uses) which goes up to +4095. I saw this yesterday but also that there
aren't asm constraints for that.

Actually, there is constraint 'Uq' which is "A memory reference suitable
for the ARMv4 ldrsb instruction" and that is a value +/- 255.

In practice, for the code in question, which is getting offsets into
struct pt_regs, either 'I', 'J' or 'Uq' would work. 'Uq' is the one that
expresses the strictest restrictions, that if met, will work with all
assembler instructions used, but as it's documented as being for the
"ARMv4 ldrsb instruction", it would seem a bit confusing to use that to
me.

-- 
Tixy

> 
> Robin.
> 
> > [1] https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints
> >
> >
> >> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> >> ---
> >>   arch/arm/probes/kprobes/core.c | 8 ++++----
> >>   1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
> >> index a4ec240ee7ba..4b34b40ca917 100644
> >> --- a/arch/arm/probes/kprobes/core.c
> >> +++ b/arch/arm/probes/kprobes/core.c
> >> @@ -570,10 +570,10 @@ void __kprobes jprobe_return(void)
> >>   		:
> >>   		: "r" (kcb->jprobe_saved_regs.ARM_sp),
> >>   		  "I" (sizeof(struct pt_regs) * 2),
> >> -		  "J" (offsetof(struct pt_regs, ARM_sp)),
> >> -		  "J" (offsetof(struct pt_regs, ARM_pc)),
> >> -		  "J" (offsetof(struct pt_regs, ARM_cpsr)),
> >> -		  "J" (offsetof(struct pt_regs, ARM_lr))
> >> +		  "I" (offsetof(struct pt_regs, ARM_sp)),
> >> +		  "I" (offsetof(struct pt_regs, ARM_pc)),
> >> +		  "I" (offsetof(struct pt_regs, ARM_cpsr)),
> >> +		  "I" (offsetof(struct pt_regs, ARM_lr))
> >>   		: "memory", "cc");
> >>   }
> >>
> >
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> 




From thomas.petazzoni at free-electrons.com  Fri Feb 19 01:35:35 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 19 Feb 2016 10:35:35 +0100
Subject: [PATCH v2] irqchip: irq-mvebu-odmi: new driver for platform MSI
 on Marvell 7K/8K
In-Reply-To: <56C5F433.8010701@arm.com>
References: <1455811134-3679-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <56C5F433.8010701@arm.com>
Message-ID: <20160219103535.28062901@free-electrons.com>

Marc,

On Thu, 18 Feb 2016 16:41:23 +0000, Marc Zyngier wrote:

> It looks really nice, except for a couple of points, see below.

Thanks again for the review.

> > +/*
> > + * We don't support the group events, so we simply have 8 interrupts
> > + * per frame.
> > + */
> > +#define NODMIS_PER_FRAME 8
> > +#define NODMIS_SHIFT     3
> > +#define NODMIS_MASK      7
> 
> All these values are directly related, so it would be nice if they would
> be expressed in term of each other:
> 
> #define NODMIS_SHIFT	 3
> #define NODMIS_PER_FRAME (1 << NODMIS_SHIFT)
> #define NODMIS_MASK      (NODMIS_PER_FRAME - 1)

Good point, will do.

> > +	odmis_bm = kzalloc(odmis_count * NODMIS_PER_FRAME / BITS_PER_BYTE,
> > +			   GFP_KERNEL);
> 
> Blah. this will allocate the exact number of bytes, which you will then
> access as longs, touching memory that's not yours in the process (I've
> been recently bitten and publicly shamed...).

Aah, yes.

> Consider the following:
> 
> odmis_bm = kzalloc(BITS_TO_LONGS(odmis_count * NODMIS_PER_FRAME) *
> sizeof(long), GFP_KERNEL);

Will do.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From peter.chen at nxp.com  Fri Feb 19 01:35:03 2016
From: peter.chen at nxp.com (Peter Chen)
Date: Fri, 19 Feb 2016 17:35:03 +0800
Subject: [PATCH 1/2] ARM: dts: imx25.dtsi: change the clock information for usb
Message-ID: <1455874504-28993-1-git-send-email-peter.chen@nxp.com>

From: Peter Chen <peter.chen at freescale.com>

For imx25, it needs three clocks to let the controller work,
the old code is wrong, and usbmisc has not included clock
handling code any more.

Acked-by: Shawn Guo <shawnguo at kernel.org>
Tested-by: Fabio Estevam <fabio.estevam at freescale.com>
Signed-off-by: Peter Chen <peter.chen at freescale.com>
---
Shawn, the related changes for i.mx27 has already been in mainline.
Unlike the changes for i.mx27, it is not a bug fix for i.mx25 and i.mx35.

 arch/arm/boot/dts/imx25.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index cde329e..d82e8d8 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -497,7 +497,8 @@
 				compatible = "fsl,imx25-usb", "fsl,imx27-usb";
 				reg = <0x53ff4000 0x0200>;
 				interrupts = <37>;
-				clocks = <&clks 70>;
+				clocks = <&clks 9>, <&clks 70>, <&clks 8>;
+				clock-names = "ipg", "ahb", "per";
 				fsl,usbmisc = <&usbmisc 0>;
 				fsl,usbphy = <&usbphy0>;
 				status = "disabled";
@@ -507,7 +508,8 @@
 				compatible = "fsl,imx25-usb", "fsl,imx27-usb";
 				reg = <0x53ff4400 0x0200>;
 				interrupts = <35>;
-				clocks = <&clks 70>;
+				clocks = <&clks 9>, <&clks 70>, <&clks 8>;
+				clock-names = "ipg", "ahb", "per";
 				fsl,usbmisc = <&usbmisc 1>;
 				fsl,usbphy = <&usbphy1>;
 				status = "disabled";
@@ -516,8 +518,6 @@
 			usbmisc: usbmisc at 53ff4600 {
 				#index-cells = <1>;
 				compatible = "fsl,imx25-usbmisc";
-				clocks = <&clks 9>, <&clks 70>, <&clks 8>;
-				clock-names = "ipg", "ahb", "per";
 				reg = <0x53ff4600 0x00f>;
 			};
 
-- 
1.9.1



From peter.chen at nxp.com  Fri Feb 19 01:35:04 2016
From: peter.chen at nxp.com (Peter Chen)
Date: Fri, 19 Feb 2016 17:35:04 +0800
Subject: [PATCH 2/2] ARM: dts: imx35.dtsi: change the clock information for usb
In-Reply-To: <1455874504-28993-1-git-send-email-peter.chen@nxp.com>
References: <1455874504-28993-1-git-send-email-peter.chen@nxp.com>
Message-ID: <1455874504-28993-2-git-send-email-peter.chen@nxp.com>

From: Peter Chen <peter.chen at freescale.com>

For imx35, it needs three clocks to let the controller work,
the old code is wrong, and the usbmisc does not include
clock handling code any more.

Signed-off-by: Peter Chen <peter.chen at freescale.com>
Acked-by: Shawn Guo <shawnguo at kernel.org>
---
 arch/arm/boot/dts/imx35.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index ed3dc33..14e1320 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -305,7 +305,8 @@
 				compatible = "fsl,imx35-usb", "fsl,imx27-usb";
 				reg = <0x53ff4000 0x0200>;
 				interrupts = <37>;
-				clocks = <&clks 73>;
+				clocks = <&clks 9>, <&clks 73>, <&clks 28>;
+				clock-names = "ipg", "ahb", "per";
 				fsl,usbmisc = <&usbmisc 0>;
 				fsl,usbphy = <&usbphy0>;
 				status = "disabled";
@@ -315,7 +316,8 @@
 				compatible = "fsl,imx35-usb", "fsl,imx27-usb";
 				reg = <0x53ff4400 0x0200>;
 				interrupts = <35>;
-				clocks = <&clks 73>;
+				clocks = <&clks 9>, <&clks 73>, <&clks 28>;
+				clock-names = "ipg", "ahb", "per";
 				fsl,usbmisc = <&usbmisc 1>;
 				fsl,usbphy = <&usbphy1>;
 				dr_mode = "host";
@@ -325,8 +327,6 @@
 			usbmisc: usbmisc at 53ff4600 {
 				#index-cells = <1>;
 				compatible = "fsl,imx35-usbmisc";
-				clocks = <&clks 9>, <&clks 73>, <&clks 28>;
-				clock-names = "ipg", "ahb", "per";
 				reg = <0x53ff4600 0x00f>;
 			};
 		};
-- 
1.9.1



From p.zabel at pengutronix.de  Fri Feb 19 01:39:47 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 19 Feb 2016 10:39:47 +0100
Subject: [GIT PULL] Reset controller changes for v4.6
Message-ID: <1455874787.13163.7.camel@pengutronix.de>

Dear arm-soc maintainers,

this tag adds reset support for Pistachio, makes
struct reset_control_ops const, and moves the DT
cell size check into the core.

best regards
Philipp

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.pengutronix.de/git/pza/linux.git tags/reset-for-4.6

for you to fetch changes up to f673ed4d5fdc123b1552525de30741cd8dfde53f:

  reset: sti: Make reset_control_ops const (2016-02-10 10:53:38 +0100)

----------------------------------------------------------------
Reset controller changes for v4.6

- add support for the imgtec Pistachio SoC reset controller
- make struct reset_control_ops const
- move DT cell size check into the core to avoid code duplication
  in the drivers

----------------------------------------------------------------
Damien Horsley (2):
      reset: img: Add pistachio reset controller binding document
      reset: img: Add Pistachio reset controller driver

Masahiro Yamada (1):
      reset: hisilicon: check return value of reset_controller_register()

Maxime Ripard (2):
      reset: Make reset_control_ops const
      reset: Move DT cell size check to the core

Philipp Zabel (11):
      reset: remove unnecessary local variable initialization from of_reset_control_get_by_index
      reset: berlin: drop DT cell size check
      reset: berlin: Make reset_control_ops const
      reset: img: Make reset_control_ops const
      reset: sunxi: Make reset_control_ops const
      reset: lpc18xx: Make reset_control_ops const
      reset: ath79: Make reset_control_ops const
      reset: hi6220: Make reset_control_ops const
      reset: socfpga: Make reset_control_ops const
      reset: zynq: Make reset_control_ops const
      reset: sti: Make reset_control_ops const

 .../bindings/reset/img,pistachio-reset.txt         |  55 ++++++++
 drivers/reset/Makefile                             |   1 +
 drivers/reset/core.c                               |  10 +-
 drivers/reset/hisilicon/hi6220_reset.c             |   6 +-
 drivers/reset/reset-ath79.c                        |   2 +-
 drivers/reset/reset-berlin.c                       |   5 +-
 drivers/reset/reset-lpc18xx.c                      |   2 +-
 drivers/reset/reset-pistachio.c                    | 154 +++++++++++++++++++++
 drivers/reset/reset-socfpga.c                      |   2 +-
 drivers/reset/reset-sunxi.c                        |   2 +-
 drivers/reset/reset-zynq.c                         |   2 +-
 drivers/reset/sti/reset-syscfg.c                   |   2 +-
 include/dt-bindings/reset/pistachio-resets.h       |  36 +++++
 include/linux/reset-controller.h                   |   2 +-
 14 files changed, 262 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/reset/img,pistachio-reset.txt
 create mode 100644 drivers/reset/reset-pistachio.c
 create mode 100644 include/dt-bindings/reset/pistachio-resets.h



From linux at arm.linux.org.uk  Fri Feb 19 01:39:59 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Feb 2016 09:39:59 +0000
Subject: [PATCH] clk: fix clk-gpio.c with optional clock= DT property
In-Reply-To: <20160219030731.GS4847@codeaurora.org>
References: <E1aFJ0A-00086Z-0I@rmk-PC.arm.linux.org.uk>
 <20160217230529.GM19428@n2100.arm.linux.org.uk>
 <20160218000747.2278.46405@quark.deferred.io>
 <20160218005503.GO19428@n2100.arm.linux.org.uk>
 <20160219030731.GS4847@codeaurora.org>
Message-ID: <20160219093959.GV19428@n2100.arm.linux.org.uk>

On Thu, Feb 18, 2016 at 07:07:31PM -0800, Stephen Boyd wrote:
> On 02/18, Russell King - ARM Linux wrote:
> > This is even explained in the very first sentence of my commit
> > log:
> > 
> > | When the clock DT property is not given, of_clk_get_parent_count()
> >                                            ^^^^^^^^^^^^^^^^^^^^^^^^^
> > | returns -ENOENT, which then tries to allocate -2 x 4 bytes of memory,
> >   ^^^^^^^^^^^^^^^
> > 
> > -ENOENT is a negative number.  Now look at the patch which totally
> > rejects the clock if of_clk_get_parent_count() returns any negative
> > number...
> > 
> > I assume, therefore, that you did not *even* read my commit log...
> > 
> 
> Ok. So the simplest fix is to just do this? I'll write up some
> commit text and get this into the rc.

I'm sorry, I've had enough of this crappy maintainer behaviour over
this issue.  There's a simple solution:

(a) making a patch which undoes the broken commit and gives the result
    from my _tested_ patch which is _known_ to work, rather than coming
    up with yet another potentially broken solution.

(b) someone apologising for modifying a patch without mentioning in the
    commit log that it was modified, where the modification makes the
    patch no longer match the commit log, and effectively making the
    patch totally useless.

(a) is easy:

diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 19fed65587e8..05cca9298f44 100644
--- a/drivers/clk/clk-gpio.c
+++ b/drivers/clk/clk-gpio.c
@@ -287,15 +287,12 @@ static void __init of_gpio_clk_setup(struct device_node *node,
 	const char **parent_names;
 	int i, num_parents;
 
-	num_parents = of_clk_get_parent_count(node);
-	if (num_parents < 0)
-		return;
-
 	data = kzalloc(sizeof(*data), GFP_KERNEL);
 	if (!data)
 		return;
 
-	if (num_parents) {
+	num_parents = of_clk_get_parent_count(node);
+	if (num_parents > 0) {
 		parent_names = kcalloc(num_parents, sizeof(char *), GFP_KERNEL);
 		if (!parent_names) {
 			kfree(data);

Apply that with an apology and I'll be happy.  Do something else and
I'm not going to be happy, because it means more work for me.  And yes,
yet again, I've tested the above solution, and it works.  Of course it
works, it's my original solution, which was tested at the time.

The moral here is: do _not_ modify other peoples tested patches, or
if you do either _test_ them yourself or ask for them to be tested
before committing.  And if you modify a patch, _say so_ in the
commit text.

And yes, in this case, it's _easy_ for you to test.  You don't need
hardware other than a free gpio pin to come up with a DT fragment
to insert in a test platforms DT.

There is *no* excuse for this mess.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From vladimir.murzin at arm.com  Fri Feb 19 01:45:18 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Fri, 19 Feb 2016 09:45:18 +0000
Subject: [PATCH v3 05/10] serial: mps2-uart: add support for early console
In-Reply-To: <56C31F9F.10000@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>	<1455617295-23736-6-git-send-email-vladimir.murzin@arm.com>
 <CAHp75VdugAq0WnzLHmd9CJHCjBOdBwPqCmC3ARSaVF5XMYGoMw@mail.gmail.com>
 <56C31F9F.10000@arm.com>
Message-ID: <56C6E42E.5070601@arm.com>

On 16/02/16 13:09, Vladimir Murzin wrote:
>>> +EARLYCON_DECLARE(mps2, mps2_early_console_setup);
>>> >> +OF_EARLYCON_DECLARE(mps2, "arm,mps2-uart", mps2_early_console_setup);
>> > 
>> > IIRC Peter Hurley mentioned you don't need to put both anymore, OF_
>> > one is enough.
>> > 
> I've just tried with OF_ only and seems it works fine. Thanks for
> pointing at it!
> 

..and the reason for that was that I had stdout pointing at uart node.
Now, while testing v4 I end-up with configuration:

1) no EARLYCON_DECLARE in mps2-uart.c
2) stdout not set
3) cmdline has "earlycon=mps2,0x40004000 console=/dev/ttyMPS"

and I don't see bootconsole, but if I avoid 1) everything works fine.
So, I'd leave EARLYCON_DECLARE in this patch.

Cheers
Vladimir


From andy.shevchenko at gmail.com  Fri Feb 19 01:57:45 2016
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Fri, 19 Feb 2016 11:57:45 +0200
Subject: [PATCH v3 05/10] serial: mps2-uart: add support for early console
In-Reply-To: <56C6E42E.5070601@arm.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-6-git-send-email-vladimir.murzin@arm.com>
 <CAHp75VdugAq0WnzLHmd9CJHCjBOdBwPqCmC3ARSaVF5XMYGoMw@mail.gmail.com>
 <56C31F9F.10000@arm.com> <56C6E42E.5070601@arm.com>
Message-ID: <CAHp75VcosaVcz_aYbpfL-nUH0kBf72SshXU5k95s48Z3wnA5nQ@mail.gmail.com>

On Fri, Feb 19, 2016 at 11:45 AM, Vladimir Murzin
<vladimir.murzin at arm.com> wrote:
> On 16/02/16 13:09, Vladimir Murzin wrote:
>>>> +EARLYCON_DECLARE(mps2, mps2_early_console_setup);
>>>> >> +OF_EARLYCON_DECLARE(mps2, "arm,mps2-uart", mps2_early_console_setup);
>>> >
>>> > IIRC Peter Hurley mentioned you don't need to put both anymore, OF_
>>> > one is enough.
>>> >
>> I've just tried with OF_ only and seems it works fine. Thanks for
>> pointing at it!
>>
>
> ..and the reason for that was that I had stdout pointing at uart node.
> Now, while testing v4 I end-up with configuration:
>
> 1) no EARLYCON_DECLARE in mps2-uart.c
> 2) stdout not set
> 3) cmdline has "earlycon=mps2,0x40004000 console=/dev/ttyMPS"
>
> and I don't see bootconsole, but if I avoid 1) everything works fine.
> So, I'd leave EARLYCON_DECLARE in this patch.

Peter, what is your comment on this?


-- 
With Best Regards,
Andy Shevchenko


From dinguyen at kernel.org  Fri Feb 19 02:02:06 2016
From: dinguyen at kernel.org (Dinh Nguyen)
Date: Fri, 19 Feb 2016 04:02:06 -0600
Subject: [GIT PULL] SoCFPGA defconfig for v4.6
Message-ID: <1455876126-26635-1-git-send-email-dinguyen@kernel.org>

Hi Arnd, Kevin, and Olof:

Please consider pulling this defconfig update for v4.6.

Thanks,
Dinh

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git socfpga_defconfig_for_v4.6

for you to fetch changes up to 31d74b2bf0c921276a1e987ca5371e2f79a783c2:

  ARM: socfpga_defconfig: enable support for initramfs/initrd support (2016-02-19 03:48:20 -0600)

----------------------------------------------------------------
SoCFPGA defconfig update for v4.6
-Enable initrd/initramfs support

----------------------------------------------------------------
Dinh Nguyen (1):
      ARM: socfpga_defconfig: enable support for initramfs/initrd support

 arch/arm/configs/socfpga_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


From matthias.bgg at gmail.com  Fri Feb 19 02:05:39 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Fri, 19 Feb 2016 11:05:39 +0100
Subject: [PATCH] ARM64: dts: Mediatek: mt8173-evb: fix access MMC fail
 issue
In-Reply-To: <1455861643-24307-1-git-send-email-eddie.huang@mediatek.com>
References: <1455861643-24307-1-git-send-email-eddie.huang@mediatek.com>
Message-ID: <56C6E8F3.4020402@gmail.com>

Hi Eddie,

On 19/02/16 07:00, Eddie Huang wrote:
> MT8173 E1 chip has one bug that if turn off USB power domain, vcore
> power will also be off, thus cause modules using vcore power domain
> fail, like MMC. The E1 chip only found on MT8173-evb board and this
> board only has E1 chip, so implement this as a board specific
> workaround.
>
> Pwrapper use vcore power, so add pwrapper using USB power domain to
> keep USB power domain not to zero and disabled.
>
> Signed-off-by: Eddie Huang <eddie.huang at mediatek.com>
>
> ---
> Sascha sent similar patch before[0], but MMC support runtime-pm,
> vcore power domain still be disabled after MMC and USB suspend.
> This silicon bug already fix in MT8173 MP chip.
>
> [0]:http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/358065.html
> ---
>   arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> index e427f04..7453a47 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> @@ -214,6 +214,9 @@
>   };
>
>   &pwrap {
> +	/* Only MT8173 E1 needs USB power domain */
> +	power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
> +

Applied, thanks


From zhiqiang.hou at nxp.com  Fri Feb 19 02:10:04 2016
From: zhiqiang.hou at nxp.com (Zhiqiang Hou)
Date: Fri, 19 Feb 2016 10:10:04 +0000
Subject: [PATCH v2 2/2] ARM64: dts: add LS1043a-QDS board support
In-Reply-To: <20160219032830.GG6756@tiger>
References: <1450948298-33238-1-git-send-email-Zhiqiang.Hou@freescale.com>
 <1450948298-33238-2-git-send-email-Zhiqiang.Hou@freescale.com>
 <20160219032830.GG6756@tiger>
Message-ID: <HE1PR04MB0906707F686591B374AA364F84A00@HE1PR04MB0906.eurprd04.prod.outlook.com>

Hi Shawn,

Thanks for your comments!

> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo at kernel.org]
> Sent: 2016?2?19? 11:29
> To: Zhiqiang Hou <Zhiqiang.Hou at freescale.com>
> Cc: devicetree at vger.kernel.org; robh+dt at kernel.org; mark.rutland at arm.com;
> pawel.moll at arm.com; ijc+devicetree at hellion.org.uk; galak at codeaurora.org;
> linux-arm-kernel at lists.infradead.org; catalin.marinas at arm.com;
> will.deacon at arm.com; scottwood at freescale.com; Mingkai.Hu at freescale.com;
> Shaohui.Xie at freescale.com
> Subject: Re: [PATCH v2 2/2] ARM64: dts: add LS1043a-QDS board support
> 
> On Thu, Dec 24, 2015 at 05:11:38PM +0800, Zhiqiang Hou wrote:
> > From: Shaohui Xie <Shaohui.Xie at freescale.com>
> >
> 
> Empty commit log is generally not welcomed.  You can have something here to
> introduce the board briefly.
> 

Will add the introduce in v3. 

> We generally use lowercase for arm64 patch subject prefix, i.e.
> "arm64: dts: ...".  Yes, this is different from ARM.
 
Yes, will fix in v3.

> > Signed-off-by: Shaohui Xie <Shaohui.Xie at freescale.com>
> > Signed-off-by: Mingkai Hu <Mingkai.Hu at freescale.com>
> > Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou at freescale.com>
> > ---
> > v2:
> >  - add root node compatible property
> >
> >  arch/arm64/boot/dts/freescale/Makefile            |   1 +
> >  arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 168
> > ++++++++++++++++++++++
> >  2 files changed, 169 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> >
> > diff --git a/arch/arm64/boot/dts/freescale/Makefile
> > b/arch/arm64/boot/dts/freescale/Makefile
> > index f3c2516..1423fa4 100644
> > --- a/arch/arm64/boot/dts/freescale/Makefile
> > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > @@ -2,6 +2,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-qds.dtb
> >  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
> >  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
> >  dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1043a-rdb.dtb
> > +dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1043a-qds.dtb
> 
> The list should be sorted alphabetically.  But it's not your fault, as fsl-ls1043a-
> rdb.dtb is already wrong.
> 
> >
> >  always		:= $(dtb-y)
> >  subdir-y	:= $(dts-dirs)
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > new file mode 100644
> > index 0000000..d7aae69
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
> > @@ -0,0 +1,168 @@
> > +/*
> > + * Device Tree Include file for Freescale Layerscape-1043A family SoC.
> > + *
> > + * Copyright 2014-2015, Freescale Semiconductor
> > + *
> > + * Mingkai Hu <Mingkai.hu at freescale.com>
> > + *
> > + * This file is dual-licensed: you can use it either under the terms
> > + * of the GPLv2 or the X11 license, at your option. Note that this
> > +dual
> > + * licensing only applies to this file, and not this project as a
> > + * whole.
> > + *
> > + *  a) This library is free software; you can redistribute it and/or
> > + *     modify it under the terms of the GNU General Public License as
> > + *     published by the Free Software Foundation; either version 2 of the
> > + *     License, or (at your option) any later version.
> > + *
> > + *     This library is distributed in the hope that it will be useful,
> > + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + *     GNU General Public License for more details.
> > + *
> > + * Or, alternatively,
> > + *
> > + *  b) Permission is hereby granted, free of charge, to any person
> > + *     obtaining a copy of this software and associated documentation
> > + *     files (the "Software"), to deal in the Software without
> > + *     restriction, including without limitation the rights to use,
> > + *     copy, modify, merge, publish, distribute, sublicense, and/or
> > + *     sell copies of the Software, and to permit persons to whom the
> > + *     Software is furnished to do so, subject to the following
> > + *     conditions:
> > + *
> > + *     The above copyright notice and this permission notice shall be
> > + *     included in all copies or substantial portions of the Software.
> > + *
> > + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> > + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + *     OTHER DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +/dts-v1/;
> > +/include/ "fsl-ls1043a.dtsi"
> > +
> > +/ {
> > +	model = "LS1043A QDS Board";
> > +	compatible = "fsl,ls1043a-qds", "fsl,ls1043a";
> > +
> > +	aliases {
> > +		serial0 = &lpuart0;
> > +		serial1 = &lpuart1;
> > +		serial2 = &lpuart2;
> > +		serial3 = &lpuart3;
> > +		serial4 = &lpuart4;
> > +		serial5 = &lpuart5;
> > +
> 
> This new line is not really necessary.
> 
> > +		gpio0 = &gpio1;
> > +		gpio1 = &gpio2;
> > +		gpio2 = &gpio3;
> > +		gpio3 = &gpio4;
> 
> I suggest to sort all these aliases entries alphabetically.
> 

Yes, this will be arranged in v3.

> > +	};
> > +};
> > +
> > +&i2c0 {
> > +	status = "okay";
> 
> I suggest to have a new line between properties and sub-node.
> 

Yes, will add a new line here.
 
> > +	pca9547 at 77 {
> > +		compatible = "philips,pca9547";
> 
> I cannot find this compatible string in either binding docs or driver code.
> 

See the file below.
./drivers/i2c/muxes/i2c-mux-pca954x.c:115:	{ "pca9547", pca_9547 },
Perhaps the vender name should be updated to nxp.

> > +		reg = <0x77>;
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		i2c at 0 {
> > +			#address-cells = <1>;
> > +			#size-cells = <0>;
> > +			reg = <0x0>;
> > +
> > +			rtc at 68 {
> > +				compatible = "dallas,ds3232";
> > +				reg = <0x68>;
> > +				/* IRQ10_B */
> > +				interrupts = <0 150 0x4>;
> > +			};
> > +		};
> > +
> > +		i2c at 2 {
> > +			#address-cells = <1>;
> > +			#size-cells = <0>;
> > +			reg = <0x2>;
> > +
> > +			ina220 at 40 {
> > +				compatible = "ti,ina220";
> > +				reg = <0x40>;
> > +				shunt-resistor = <1000>;
> > +			};
> > +
> > +			ina220 at 41 {
> > +				compatible = "ti,ina220";
> > +				reg = <0x41>;
> > +				shunt-resistor = <1000>;
> > +			};
> > +		};
> > +
> > +		i2c at 3 {
> > +			#address-cells = <1>;
> > +			#size-cells = <0>;
> > +			reg = <0x3>;
> > +
> > +			eeprom at 56 {
> > +				compatible = "at24,24c512";
> 
> Unsupported/undocumented compatible?

Will change it to "atmel, 24c512".

> 
> > +				reg = <0x56>;
> > +			};
> > +
> > +			eeprom at 57 {
> > +				compatible = "at24,24c512";
> > +				reg = <0x57>;
> > +			};
> > +
> > +			adt7461a at 4c {
> 
> temp-sensor should be a better node name, if I understand the device correctly.
> 

I didn't find a reference in kernel, so what name should be better, do you have any advice?

> > +				compatible = "adt7461a";
> 
> It should be "adi,adt7461a" per
> Documentation/devicetree/bindings/hwmon/lm90.txt?
> 

Yes, will fix it in v3.

> > +				reg = <0x4c>;
> > +			};
> > +		};
> > +	};
> > +};
> > +
> > +&ifc {
> > +	status = "okay";
> 
> We generally put it at the bottom of the property list.
> 

Will fix it in v3.

> > +	#address-cells = <2>;
> > +	#size-cells = <1>;
> > +	/* NOR, NAND Flashes and FPGA on board */
> > +	ranges = <0x0 0x0 0x0 0x60000000 0x08000000
> > +		  0x1 0x0 0x0 0x7e800000 0x00010000
> > +		  0x2 0x0 0x0 0x7fb00000 0x00000100>;
> > +
> > +	nor at 0,0 {
> > +		compatible = "cfi-flash";
> > +		reg = <0x0 0x0 0x8000000>;
> > +		bank-width = <2>;
> > +		device-width = <1>;
> > +	};
> > +
> > +	nand at 1,0 {
> > +		compatible = "fsl,ifc-nand";
> > +		reg = <0x1 0x0 0x10000>;
> > +	};
> > +
> > +	fpga: board-control at 2,0 {
> > +		compatible = "fsl,ls1043aqds-fpga", "fsl,fpga-qixis";
> > +		reg = <0x2 0x0 0x0000100>;
> > +	};
> > +};
> > +
> > +&lpuart0 {
> > +	status = "okay";
> > +};
> > +
> > +&duart0 {
> > +	status = "okay";
> > +};
> > +
> > +&duart1 {
> > +	status = "okay";
> > +};
> 
> I suggest you sort these node alphabetically per label name.
> 

Yes, will resort these nodes in v3.

Thanks,
Zhiqiang

From arnd at arndb.de  Fri Feb 19 02:15:06 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 11:15:06 +0100
Subject: [PATCH v6 1/1] USB: core: let USB device know device node
In-Reply-To: <1455873975-19531-1-git-send-email-peter.chen@nxp.com>
References: <1455873975-19531-1-git-send-email-peter.chen@nxp.com>
Message-ID: <2952220.GB2TbsskTM@wuerfel>

On Friday 19 February 2016 17:26:15 Peter Chen wrote:
> From: Peter Chen <peter.chen at freescale.com>
> 
> Although most of USB devices are hot-plug's, there are still some devices
> are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
> If these kinds of USB devices are multiple functions, and they can supply
> other interfaces like i2c, gpios for other devices, we may need to
> describe these at device tree.
> 
> In this commit, it uses "reg" in dts as physical port number to match
> the phyiscal port number decided by USB core, if they are the same,
> then the device node is for the device we are creating for USB core.
> 
> Signed-off-by: Peter Chen <peter.chen at freescale.com>
> Acked-by: Philipp Zabel <p.zabel at pengutronix.de>
> Acked-by: Alan Stern <stern at rowland.harvard.edu>
> Acked-by: Rob Herring <robh at kernel.org>
> 

Acked-by: Arnd Bergmann <arnd at arndb.de>


From dan.carpenter at oracle.com  Fri Feb 19 02:15:05 2016
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Fri, 19 Feb 2016 13:15:05 +0300
Subject: [PATCH] staging: rtl8712: reduce stack usage
In-Reply-To: <1455698012-814399-1-git-send-email-arnd@arndb.de>
References: <1455698012-814399-1-git-send-email-arnd@arndb.de>
Message-ID: <20160219101505.GO32153@mwanda>

Of course, we still reach almost the same maximum stack usage as before
because we're going to put the function on stack in the end anyway.

regards,
dan carpenter



From ludovic.desroches at atmel.com  Fri Feb 19 02:18:14 2016
From: ludovic.desroches at atmel.com (Ludovic Desroches)
Date: Fri, 19 Feb 2016 11:18:14 +0100
Subject: [PATCH] dmaengine: at_xdmac: fix residue computation
Message-ID: <1455877102-14263-1-git-send-email-ludovic.desroches@atmel.com>

When computing the residue we need two pieces of information: the current
descriptor and the remaining data of the current descriptor. To get
that information, we need to read consecutively two registers but we
can't do it in an atomic way. For that reason, we have to check manually
that current descriptor has not changed.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
Suggested-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
Reported-by: David Engraf <david.engraf at sysgo.com>
Tested-by: David Engraf <david.engraf at sysgo.com>
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Cc: stable at vger.kernel.org #4.1 and later
---
 drivers/dma/at_xdmac.c | 42 +++++++++++++++++++++++++++++++++++++++---
 1 file changed, 39 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index 64f5d1b..8e304b1 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -176,6 +176,7 @@
 #define AT_XDMAC_MAX_CHAN	0x20
 #define AT_XDMAC_MAX_CSIZE	16	/* 16 data */
 #define AT_XDMAC_MAX_DWIDTH	8	/* 64 bits */
+#define AT_XDMAC_RESIDUE_MAX_RETRIES	5
 
 #define AT_XDMAC_DMA_BUSWIDTHS\
 	(BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED) |\
@@ -1395,8 +1396,8 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
 	struct at_xdmac_desc	*desc, *_desc;
 	struct list_head	*descs_list;
 	enum dma_status		ret;
-	int			residue;
-	u32			cur_nda, mask, value;
+	int			residue, retry;
+	u32			cur_nda, check_nda, cur_ubc, mask, value;
 	u8			dwidth = 0;
 	unsigned long		flags;
 
@@ -1433,7 +1434,42 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
 			cpu_relax();
 	}
 
+	/*
+	 * When processing the residue, we need to read two registers but we
+	 * can't do it in an atomic way. AT_XDMAC_CNDA is used to find where
+	 * we stand in the descriptor list and AT_XDMAC_CUBC is used
+	 * to know how many data are remaining for the current descriptor.
+	 * Since the dma channel is not paused to not loose data, between the
+	 * AT_XDMAC_CNDA and AT_XDMAC_CUBC read, we may have change of
+	 * descriptor.
+	 * For that reason, after reading AT_XDMAC_CUBC, we check if we are
+	 * still using the same descriptor by reading a second time
+	 * AT_XDMAC_CNDA. If AT_XDMAC_CNDA has changed, it means we have to
+	 * read again AT_XDMAC_CUBC.
+	 * Memory barriers are used to ensure the read order of the registers.
+	 * A max number of retries is set because unlikely it can never ends if
+	 * we are transferring a lot of data with small buffers.
+	 */
 	cur_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 0xfffffffc;
+	rmb();
+	cur_ubc = at_xdmac_chan_read(atchan, AT_XDMAC_CUBC);
+	for (retry = 0; retry < AT_XDMAC_RESIDUE_MAX_RETRIES; retry++) {
+		rmb();
+		check_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 0xfffffffc;
+
+		if (likely(cur_nda == check_nda))
+			break;
+
+		cur_nda = check_nda;
+		rmb();
+		cur_ubc = at_xdmac_chan_read(atchan, AT_XDMAC_CUBC);
+	}
+
+	if (unlikely(retry >= AT_XDMAC_RESIDUE_MAX_RETRIES)) {
+		ret = DMA_ERROR;
+		goto spin_unlock;
+	}
+
 	/*
 	 * Remove size of all microblocks already transferred and the current
 	 * one. Then add the remaining size to transfer of the current
@@ -1446,7 +1482,7 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
 		if ((desc->lld.mbr_nda & 0xfffffffc) == cur_nda)
 			break;
 	}
-	residue += at_xdmac_chan_read(atchan, AT_XDMAC_CUBC) << dwidth;
+	residue += cur_ubc << dwidth;
 
 	dma_set_residue(txstate, residue);
 
-- 
2.5.0



From arnd at arndb.de  Fri Feb 19 02:17:53 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 11:17:53 +0100
Subject: [PATCH 1/9] ARM: ARMv7-M uses BE-8, not BE-32
In-Reply-To: <56C6D6B3.60605@arm.com>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <2702301.CTWUiSsjZR@wuerfel> <56C6D6B3.60605@arm.com>
Message-ID: <4528627.ddzfcWQ79X@wuerfel>

On Friday 19 February 2016 08:47:47 Vladimir Murzin wrote:
> Ah, it explains why my quick attempt to enable BE for MPS2 (M-class
> platform) failed. With this patch applied I'm able to see Linux booting
> on MPS2 FVP model in BE, not complete boot but it might be due to other
> reasons. So this patch definitely improves things for me, if it helps
> 
> Tested-by: Vladimir Murzin <vladimir.murzin at arm.com>
> 

Awesome, thanks for testing!

	Arnd


From Jean-Philippe.Brucker at arm.com  Fri Feb 19 02:18:02 2016
From: Jean-Philippe.Brucker at arm.com (Jean-Philippe Brucker)
Date: Fri, 19 Feb 2016 10:18:02 +0000
Subject: [PATCH next] ARM: virt: fix build of hyp-stub
In-Reply-To: <1455838277-11083-1-git-send-email-vincent.stehle@laposte.net>
References: <1455838277-11083-1-git-send-email-vincent.stehle@laposte.net>
Message-ID: <20160219101802.GA4524@e106794-lin.cambridge.arm.com>

Hi Vincent,

On Fri, Feb 19, 2016 at 12:31:17AM +0100, Vincent Stehl? wrote:
> Compile hyp-stub explicitly for arm v7-a. This fixes the following build
> errors:
> 
>   arch/arm/kernel/hyp-stub.S: Assembler messages:
>   arch/arm/kernel/hyp-stub.S:168: Error: selected processor does not support `ubfx r7,r7,#28,#4' in ARM mode
>   arch/arm/kernel/hyp-stub.S:176: Error: selected processor does not support `isb' in ARM mode
> 
> Signed-off-by: Vincent Stehl? <vincent.stehle at laposte.net>
> Cc: Jean-Philippe Brucker <jean-philippe.brucker at arm.com>
> Cc: Marc Zyngier <marc.zyngier at arm.com>
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> ---
> 
> 
> Hi,
> 
> This can be seen with linux next-20160218 and arm e.g. allmodconfig.

Thanks for doing this. I just posted my fix to the patch system, before
seeing yours (it also requires change in boot/compressed/Makefile -
hyp-stub is built twice). See the previous discussion about this issue
here: http://thread.gmane.org/gmane.linux.ports.arm.kernel/479256

Thanks,
Jean-Philippe

> 
> Best regards,
> 
> V.
> 
> 
>  arch/arm/kernel/Makefile | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
> index 2c5f160..15684c5 100644
> --- a/arch/arm/kernel/Makefile
> +++ b/arch/arm/kernel/Makefile
> @@ -88,6 +88,8 @@ obj-$(CONFIG_DEBUG_LL)	+= debug.o
>  obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
>  
>  obj-$(CONFIG_ARM_VIRT_EXT)	+= hyp-stub.o
> +AFLAGS_hyp-stub.o		:=-Wa,-march=armv7-a
> +
>  ifeq ($(CONFIG_ARM_PSCI),y)
>  obj-$(CONFIG_SMP)		+= psci_smp.o
>  endif
> -- 
> 2.7.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From arnd at arndb.de  Fri Feb 19 02:30:55 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 11:30:55 +0100
Subject: [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM
 architecture
In-Reply-To: <1455870164-25337-4-git-send-email-m.szyprowski@samsung.com>
References: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com>
 <1455870164-25337-4-git-send-email-m.szyprowski@samsung.com>
Message-ID: <2724572.qtPjgumFDJ@wuerfel>

On Friday 19 February 2016 09:22:44 Marek Szyprowski wrote:
> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation
> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The
> side-effect of this change is a switch from bitmap-based IO address space
> management to tree-based code. There should be no functional changes
> for drivers, which rely on initialization from generic arch_setup_dna_ops()
> interface. Code, which used old arm_iommu_* functions must be updated to
> new interface.
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>

I like the overall idea. However, this interface from the iommu
subsystem into architecture specific code:

> +/*
> + * The DMA API is built upon the notion of "buffer ownership".  A buffer
> + * is either exclusively owned by the CPU (and therefore may be accessed
> + * by it) or exclusively owned by the DMA device.  These helper functions
> + * represent the transitions between these two ownership states.
> + *
> + * Note, however, that on later ARMs, this notion does not work due to
> + * speculative prefetches.  We model our approach on the assumption that
> + * the CPU does do speculative prefetches, which means we clean caches
> + * before transfers and delay cache invalidation until transfer completion.
> + *
> + */
> +extern void __dma_page_cpu_to_dev(struct page *, unsigned long, size_t,
> +				  enum dma_data_direction);
> +extern void __dma_page_dev_to_cpu(struct page *, unsigned long, size_t,
> +				  enum dma_data_direction);
> +
> +static inline void arch_flush_page(struct device *dev, const void *virt,
> +			    phys_addr_t phys)
> +{
> +	dmac_flush_range(virt, virt + PAGE_SIZE);
> +	outer_flush_range(phys, phys + PAGE_SIZE);
> +}
> +
> +static inline void arch_dma_map_area(phys_addr_t phys, size_t size,
> +				     enum dma_data_direction dir)
> +{
> +	unsigned int offset = phys & ~PAGE_MASK;
> +	__dma_page_cpu_to_dev(phys_to_page(phys & PAGE_MASK), offset, size, dir);
> +}
> +
> +static inline void arch_dma_unmap_area(phys_addr_t phys, size_t size,
> +				       enum dma_data_direction dir)
> +{
> +	unsigned int offset = phys & ~PAGE_MASK;
> +	__dma_page_dev_to_cpu(phys_to_page(phys & PAGE_MASK), offset, size, dir);
> +}
> +
> +static inline pgprot_t arch_get_dma_pgprot(struct dma_attrs *attrs,
> +					pgprot_t prot, bool coherent)
> +{
> +	if (coherent)
> +		return prot;
> +
> +	prot = dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs) ?
> +			    pgprot_writecombine(prot) :
> +			    pgprot_dmacoherent(prot);
> +	return prot;
> +}
> +
> +extern void *arch_alloc_from_atomic_pool(size_t size, struct page **ret_page,
> +					 gfp_t flags);
> +extern bool arch_in_atomic_pool(void *start, size_t size);
> +extern int arch_free_from_atomic_pool(void *start, size_t size);
> +
> +

doesn't feel completely right yet. In particular the arch_flush_page()
interface is probably still too specific to ARM/ARM64 and won't work
that way on other architectures.

I think it would be better to do this either more generic, or less generic:

a) leave the iommu_dma_map_ops definition in the architecture specific
   code, but make it call helper functions in the drivers/iommu to do all
   of the really generic parts.

b) clarify that this is only applicable to arch/arm and arch/arm64, and
   unify things further between these two, as they have very similar
   requirements in the CPU architecture.

	Arnd


From will.deacon at arm.com  Fri Feb 19 02:32:05 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 19 Feb 2016 10:32:05 +0000
Subject: [PATCH] arm64: add architecture specified current_pt_regs
In-Reply-To: <CAN1e=SF4iAVZzvs=+rJxmUX_z7KNSwegxWaor3gDfXD-=MAQ4Q@mail.gmail.com>
References: <1455796115-7844-1-git-send-email-zhizhou.zh@gmail.com>
 <20160218115824.GA2538@e104818-lin.cambridge.arm.com>
 <CAN1e=SF4iAVZzvs=+rJxmUX_z7KNSwegxWaor3gDfXD-=MAQ4Q@mail.gmail.com>
Message-ID: <20160219103205.GD27062@arm.com>

On Fri, Feb 19, 2016 at 10:30:09AM +0800, Zhi-zhou wrote:
> On Thu, Feb 18, 2016 at 7:58 PM, Catalin Marinas
> <catalin.marinas at arm.com> wrote:
> >
> > On Thu, Feb 18, 2016 at 07:48:35PM +0800, Zhi-zhou Zhang wrote:
> > > From: zhizhou <zhizhou.zh at gmail.com>
> > >
> > > This patch is based on the implementation of arm. The generic
> > > current_pt_regs is implemented with current->stack. It need to access
> > > memory that would be too expensive.
> >
> > Do you have any performance numbers?
> 
> I'm using QEMU, so no. Actually this macro isn't heavily used. I just
> think using the generic
> implementation is not very nice. It get task_struct from sp_el0, then
> get stack(which is
> equal to sp_el0) from task_struct. There are two unnecessary memory accesses.

I'd much rather use the generic implementation unless there's a compelling
reason not to. "I think it's not very nice" doesn't really cut it for me!

Will


From aleksey.makarov at linaro.org  Fri Feb 19 02:42:37 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Fri, 19 Feb 2016 13:42:37 +0300
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <56C63FB5.2030907@hurleysoftware.com>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
 <56C470C5.2080203@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>
 <56C63FB5.2030907@hurleysoftware.com>
Message-ID: <56C6F19D.7070206@linaro.org>

Hi Peter,

Thank you for review.

On 02/19/2016 01:03 AM, Peter Hurley wrote:
> On 02/17/2016 07:36 PM, Zheng, Lv wrote:
>> Hi,
>>
>>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>>> early_acpi_os_unmap_memory()
>>>
>>> Hi Lv,
>>>
>>> Thank you for review.
>>>
>>> On 02/17/2016 05:51 AM, Zheng, Lv wrote:
>>>
>>> [..]
>>>
>>>>>> early_acpi_os_unmap_memory() is marked as __init because it calls
>>>>>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is not
>>> set.
>>>>>>
>>>>>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>>> so it is safe to call early_acpi_os_unmap_memory() from anywhere
>>>>>>
>>>>>> We need this function to be non-__init because we need access to
>>>>>> some tables at unpredictable time--it may be before or after
>>>>>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port Console
>>>>>> Redirection) table is needed each time a new console is registered.
>>>>>> It can be quite early (console_initcall) or when a module is inserted.
>>>>>> When this table accessed before acpi_gbl_permanent_mmap is set,
>>>>>> the pointer should be unmapped.  This is exactly what this function
>>>>>> does.
>>>>> [Lv Zheng]
>>>>> Why don't you use another API instead of early_acpi_os_unmap_memory()
>>> in
>>>>> case you want to unmap things in any cases.
>>>>> acpi_os_unmap_memory() should be the one to match this purpose.
>>>>> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
>>>
>>> As far as I understand, there exist two steps in ACPI initialization:
>>>
>>> 1. Before acpi_gbl_permanent_mmap is set, tables received with
>>> acpi_get_table_with_size()
>>>    are mapped by early_memremap().  If a subsystem gets such a pointer it
>>> should be unmapped.
>>>
>>> 2  After acpi_gbl_permanent_mmap is set this pointer should not be unmapped
>>> at all.
>>>
>> [Lv Zheng] 
>> This statement is wrong, this should be:
>> As long as there is a __reference__ to the mapped table, the pointer should not be unmapped.
>> In fact, we have a series to introduce acpi_put_table() to achieve this.
>> So your argument is wrong from very first point.
>>
>>> That exactly what early_acpi_os_unmap_memory() does--it checks
>>> acpi_gbl_permanent_mmap.
>>> If I had used acpi_os_unmap_memory() after acpi_gbl_permanent_mmap had
>>> been set,
>>> it would have tried to free that pointer with an oops (actually, I checked that
>>> and got that oops).
>>>
>>> So using acpi_os_unmap_memory() is not an option here, but
>>> early_acpi_os_unmap_memory()
>>> match perfectly.
>> [Lv Zheng] 
>> I don't think so.
>> For definition block tables, we know for sure there will always be references, until "Unload" opcode is invoked by the AML interpreter.
>> But for the data tables, OSPMs should use them in this way:
>> 1. map the table
>> 2. parse the table and convert it to OS specific structures
>> 3. unmap the table
>> This helps to shrink virtual memory address space usages.
>>
>> So from this point of view, all data tables should be unmapped right after being parsed.
>> Why do you need the map to be persistent in the kernel address space?
>> You can always map a small table, but what if the table size is very big?
>>
>>>
>>>>> And in fact early_acpi_os_unmap_memory() should be removed.
>>>
>>> I don't think so -- I have explained why.  It does different thing.
>>> Probably it (and/or other functions in that api) should be renamed.
>>>
>> [Lv Zheng] 
>> Just let me ask one more question.
>> eary_acpi_os_unmap_memory() is not used inside of ACPICA.
>> How ACPICA can work with just acpi_os_unmap_memory()?
>> You can check drivers/acpi/tbxxx.c.
>> Especially: acpi_tb_release_temp_table() and the code invoking it.
>>
>>>> [Lv Zheng]
>>>> One more thing is:
>>>> If you can't switch your driver to use acpi_os_unmap_memory() instead of
>>> early_acpi_os_unmap_memory(),
>>>> then it implies that your driver does have a defect.
>>>
>>> I still don't understand what defect, sorry.
>> [Lv Zheng] 
>> If you can't ensure this sequence for using the data tables:
>> 1. map the table
>> 2. parse the table and convert it to OS specific structure
>> 3. unmap the table
>> It implies there is a bug in the driver or a bug in the ACPI subsystem core.
> 
> Exactly.
> 
> The central problem here is the way Aleksey is trying to hookup a console.
> 
> What should be happening in this series is:
> 1. early map SPCR
> 2. parse the SPCR table
> 3. call add_preferred_console() to add the SPCR console to the console table
> 4. unmap SPCR

This does not work.  

SPCR specifies address of the console, but add_preferred_console() accepts
name of console and its index.  There are no general method to translate address
to name at such an early stage.

There is another reason why I prefer to parse SPCR each time a console is registered.
Some consoles can be registered very early in the initialization process and
we have to be sure add_preferred_console() is called before that.

Of course, I could just parse it once and cache the results, but
this still requires accessing SPCR before acpi_gbl_permanent_mmap
is set *or* after that.

> This trivial and unobtrusive method would already have a 8250 console
> running via SPCR. I've already pointed this out in previous reviews.
> 
> Further, the above method *will be required anyway* for the DBG2 table to
> start an earlycon, which I've already pointed out in previous reviews.
> 
> Then to enable amba-pl011 console via ACPI, add a console match() method
> similar to the 8250 console match() method, univ8250_console_match().

So are you suggesting a separate method for each possible console?
This is not acceptable.

Do you suggest making up separate new name (like "uart" for 8250) for each type
of conosole SPCR can specify?

> FWIW, PCI earlycon + console support was already submitted once before but
> never picked up by GregKH. I think I'll just grab that and re-submit so
> you would know what to emit for console options in the add_preferred_console().

Please do.  Or just send a link to to that submission.

Do you mean the Leif Lindholm's patches:

https://lkml.kernel.org/g/1441716217-23786-1-git-send-email-leif.lindholm at linaro.org

He did same thing as I did in my v3 exept 1) he parses ACPI tree to match device
(I just match SPCR against data that struct uart_port already has)
2) As you are suggesting, he parses SPCR once at a predefined point in initialization.
And that's why his submission is RFC: he had troubles with the order of initialization.

Thank you
Aleksey Makarov

> Regards,
> Peter Hurley
> 
> 
>>>> There is an early bootup requirement in Linux.
>>>> Maps acquired during the early stage should be freed by the driver during the
>>> early stage.
>>>> And the driver should re-acquire the memory map after booting.
>>>
>>> Exactly.  That's why I use early_acpi_os_unmap_memory().  The point is that
>>> that code can be
>>> called *before* acpi_gbl_permanent_mmap is set (at early initialization of for
>>> example 8250 console)
>>> or *after* acpi_gbl_permanent_mmap is set (at insertion of a module that
>>> registers a console),
>>> We just can not tell if the received table pointer should or sould not be freed
>>> with early_memunmap()
>>> (actually __acpi_unmap_table() or whatever) without checking
>>> acpi_gbl_permanent_mmap,
>>> but that's all too low level.
>> [Lv Zheng] 
>> The driver should make sure that:
>> Map/unmap is paired during early stage.
>> For late stage, it should be another pair of map/unmap.
>>
>>>
>>> Another option, as you describe, is to get this pointer early, don't free it
>> [Lv Zheng] 
>> I mean you should free it early.
>>
>>> untill acpi_gbl_permanent_mmap is set, then free it (with
>>> early_acpi_os_unmap_memory(), that's
>>> ok because acpi_gbl_permanent_mmap is set in an init code), then get the
>>> persistent
>>> pointer to the table.  The problem with it is that we can not just watch
>>> acpi_gbl_permanent_mmap
>>> to catch this exact moment.  And also accessing acpi_gbl_permanent_mmap is
>>> not good as it probably is
>>> an implementation detail (i. e. too lowlevel) of the ACPI code.
>>> Or I probably miss what you are suggesting.
>>>
>> [Lv Zheng] 
>> I mean, you should:
>> During early stage:
>> acpi_os_map_memory()
>> Parse the table.
>> acpi_os_unmap_memory().
>>
>>>> This is because, during early bootup stage, there are only limited slots
>>> available for drivers to map memory.
>>>> So by changing __init to __ref here, you probably will hide many such defects.
>>>
>>> What defects?  This funcions checks acpi_gbl_permanent_mmap.
>>> BTW, exactly the same thing is done in the beginning of
>>> acpi_os_unmap_memory() and than's ok,
>>> that function is __ref.
>>>
>>>> And solving issues in this way doesn't seem to be an improvement.
>>>
>>> Could you please tell me where I am wrong?  I still don't understand your point.
>> [Lv Zheng] 
>> But anyway, the defect should be in ACPI subsystem core.
>> The cause should be the API itself - acpi_get_table().
>>
>> So I agree you can use early_acpi_os_unmap_memory() during the period the root causes are not cleaned up.
>> But the bottom line is: the driver need to ensure that early_acpi_os_unmap_memory() is always invoked.
>> As long as you can ensure this, I don't have objections for deploying early_acpi_os_unmap_memory()  for now.
>>
>> Thanks and best regards
>> -Lv
>>
>>>
>>> Thank you
>>> Aleksey Makarov
>>>
>>>>
>>>> Thanks and best regards
>>>> -Lv
>>>>
>>>>>
>>>>> Thanks and best regards
>>>>> -Lv
>>>>>
>>>>>>
>>>>>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
>>>>>> ---
>>>>>>  drivers/acpi/osl.c | 6 +++++-
>>>>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
>>>>>> index 67da6fb..8a552cd 100644
>>>>>> --- a/drivers/acpi/osl.c
>>>>>> +++ b/drivers/acpi/osl.c
>>>>>> @@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void *virt,
>>>>>> acpi_size size)
>>>>>>  }
>>>>>>  EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
>>>>>>
>>>>>> -void __init early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
>>>>> size)
>>>>>> +/*
>>>>>> + * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>>> + * so it is safe to call early_acpi_os_unmap_memory() from anywhere
>>>>>> + */
>>>>>> +void __ref early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
>>>>> size)
>>>>>>  {
>>>>>>  	if (!acpi_gbl_permanent_mmap)
>>>>>>  		__acpi_unmap_table(virt, size);
>>>>>> --
>>>>>> 2.7.1
>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>>>>>> the body of a message to majordomo at vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>>>>> the body of a message to majordomo at vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From aleksey.makarov at linaro.org  Fri Feb 19 02:47:54 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Fri, 19 Feb 2016 13:47:54 +0300
Subject: [PATCH v3 2/5] ACPI: parse SPCR and enable matching console
In-Reply-To: <56C64366.2070702@hurleysoftware.com>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-3-git-send-email-aleksey.makarov@linaro.org>
 <56C64366.2070702@hurleysoftware.com>
Message-ID: <56C6F2DA.3020002@linaro.org>

Hi Peter,

Thank you for review.

On 02/19/2016 01:19 AM, Peter Hurley wrote:
> On 02/15/2016 10:05 AM, Aleksey Makarov wrote:

[..]

>> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
>> index a126a60..459ab54 100644
>> --- a/drivers/tty/serial/serial_core.c
>> +++ b/drivers/tty/serial/serial_core.c
>> @@ -34,6 +34,7 @@
>>  #include <linux/serial_core.h>
>>  #include <linux/delay.h>
>>  #include <linux/mutex.h>
>> +#include <linux/acpi.h>
>>  
>>  #include <asm/irq.h>
>>  #include <asm/uaccess.h>
>> @@ -2654,8 +2655,17 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
>>  		spin_lock_init(&uport->lock);
>>  		lockdep_set_class(&uport->lock, &port_lock_key);
>>  	}
>> -	if (uport->cons && uport->dev)
>> -		of_console_check(uport->dev->of_node, uport->cons->name, uport->line);
>> +
>> +	/*
>> +	 * Support both open FW and ACPI access to console definitions.
>> +	 * Both of_console_check() and acpi_console_check() will call
>> +	 * add_preferred_console() if a console definition is found.
>> +	 */
>> +	if (uport->cons && uport->dev) {
>> +		if (!acpi_console_check(uport))
>> +			of_console_check(uport->dev->of_node, uport->cons->name,
>> +					 uport->line);
> 
> of_console_check() is not a good model for enabling a console.
> It's a hack with several shortcomings (and bugs) that is tolerated here
> because of its broad applicability to a wide range of platforms and drivers.

It's definitely not the best code I saw but there is no bugs.

> I specifically added console matching to enable exactly this kind of
> console-selection-via-firmware. Please use that facility.

I described why this does not work (except you insist on having 
new made up names for all types of SPCR consoles) in the reply to another your message.

Thank you
Aleksey Makarov

> Regards,
> Peter Hurley
> 
> 
>> +	}
>>  
>>  	uart_configure_port(drv, state, uport);
>>  
>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>> index 06ed7e5..ea0c297 100644
>> --- a/include/linux/acpi.h
>> +++ b/include/linux/acpi.h
>> @@ -1004,4 +1004,14 @@ static inline struct fwnode_handle *acpi_get_next_subnode(struct device *dev,
>>  #define acpi_probe_device_table(t)	({ int __r = 0; __r;})
>>  #endif
>>  
>> +struct uart_port;
>> +#ifdef CONFIG_ACPI_SPCR_TABLE
>> +bool acpi_console_check(struct uart_port *uport);
>> +#else
>> +static inline bool acpi_console_check(struct uart_port *uport)
>> +{
>> +	return FALSE;
>> +}
>> +#endif
>> +
>>  #endif	/*_LINUX_ACPI_H*/
>>
> 


From lorenzo.pieralisi at arm.com  Fri Feb 19 02:52:29 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 19 Feb 2016 10:52:29 +0000
Subject: [PATCH] arm64: kasan: clear stale stack poison
In-Reply-To: <20160218181356.GF2538@e104818-lin.cambridge.arm.com>
References: <1455816458-19485-1-git-send-email-mark.rutland@arm.com>
 <20160218175447.GD2538@e104818-lin.cambridge.arm.com>
 <20160218180353.GG16883@arm.com>
 <20160218181356.GF2538@e104818-lin.cambridge.arm.com>
Message-ID: <20160219105229.GA18597@red-moon>

On Thu, Feb 18, 2016 at 06:13:57PM +0000, Catalin Marinas wrote:
> On Thu, Feb 18, 2016 at 06:03:54PM +0000, Will Deacon wrote:
> > On Thu, Feb 18, 2016 at 05:54:47PM +0000, Catalin Marinas wrote:
> > > On Thu, Feb 18, 2016 at 05:27:38PM +0000, Mark Rutland wrote:
> > > > @@ -145,6 +146,7 @@ ENTRY(cpu_resume_mmu)
> > > >  ENDPROC(cpu_resume_mmu)
> > > >  	.popsection
> > > >  cpu_resume_after_mmu:
> > > > +	kasan_unpoison_stack 96
> > > 
> > > I don't think the 96 here is needed since we populate the stack in
> > > assembly (__cpu_suspend_enter) and unwind it again still in assembly
> > > (cpu_resume_after_mmu), so no KASAN shadow writes/reads.
> > > 
> > > Otherwise the patch looks fine.
> > 
> > I'd much rather it was written in C -- is there a reason we can't do
> > that if we use a separate compilation unit where the compiler will
> > honour the fno-sanitize flag?
> 
> A simple, non-sanitised C wrapper around __cpu_suspend_enter() would
> probably work. We need to make sure it is static inline when !KASAN to
> avoid an unnecessary function call. Or we just move cpu_suspend() to a
> different compilation unit, though that's a slightly larger function
> which we may want to track under KASAN.

Both options are ok with me. There is one more. We pass the "saved" sp
to __cpu_suspend_save (ie in cpu_suspend_ctx), you can stash it and
use it in the resume path (through logical cpu indexing) to carry
out the kasan clean-up, in C, with no wrapper needed.

With James' hibernate patches:

http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/408597.html

this is going to be even easier, since the struct above is on the
cpu_suspend stack upon cpu_resume, so you can use the sp in there
straight away.

We can put together a fix following Catalin's suggestion and when James'
patches land in mainline we will update the code.

Thanks,
Lorenzo


From julien.grall at arm.com  Fri Feb 19 02:53:49 2016
From: julien.grall at arm.com (Julien Grall)
Date: Fri, 19 Feb 2016 10:53:49 +0000
Subject: [PATCH v2 1/6] KVM: arm/arm64: arch_timer: Gather KVM specific
 information in a structure
In-Reply-To: <56C6C318.3000205@redhat.com>
References: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
 <1455204804-31830-2-git-send-email-julien.grall@arm.com>
 <56C6C318.3000205@redhat.com>
Message-ID: <56C6F43D.3010503@arm.com>

Hello Wei,

On 19/02/16 07:24, Wei Huang wrote:
> On 02/11/2016 09:33 AM, Julien Grall wrote:

[...]

>> This is also dropping arch_timer_get_timecounter as it was only used by
>> the KVM code. Furthermore, a stub for the new helper hasn't been
>> introduced because KVM is requiring the arch timer for both ARM64 and
>> ARM32.


[...]

>> -static inline struct timecounter *arch_timer_get_timecounter(void)
>> -{
>> -    return NULL;
>> -}
>> -
>
> Most parts are OK. Regarding removing this function from the #else area,
> is there a possibility to have CONFIG_ARM_ARCH_TIMER=n and CONFIG_KVM=y.
> If so, will the compilation fails here?

This patch is removing arch_timer_get_timecounter. So it's normal to
drop the stub in the #else area.

Furthermore, as mentioned in the commit message, I didn't add a stub for
the new function because KVM mandates the arch timer for both ARM64 and
ARM32.

Regards,

--
Julien Grall
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.



From aleksey.makarov at linaro.org  Fri Feb 19 03:02:56 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Fri, 19 Feb 2016 14:02:56 +0300
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E883BB4D5A0@SHSMSX101.ccr.corp.intel.com>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
 <56C470C5.2080203@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>
 <56C63FB5.2030907@hurleysoftware.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4D5A0@SHSMSX101.ccr.corp.intel.com>
Message-ID: <56C6F660.9020407@linaro.org>

Hi Lv,

On 02/19/2016 05:58 AM, Zheng, Lv wrote:
> Hi,
> 
>> From: Peter Hurley [mailto:peter at hurleysoftware.com]
>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>> early_acpi_os_unmap_memory()
>>
>> On 02/17/2016 07:36 PM, Zheng, Lv wrote:
>>> Hi,
>>>
>>>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
>>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>>>> early_acpi_os_unmap_memory()
>>>>
>>>> Hi Lv,
>>>>
>>>> Thank you for review.
>>>>
>>>> On 02/17/2016 05:51 AM, Zheng, Lv wrote:
>>>>
>>>> [..]
>>>>
>>>>>>> early_acpi_os_unmap_memory() is marked as __init because it calls
>>>>>>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is not
>>>> set.
>>>>>>>
>>>>>>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>>>> so it is safe to call early_acpi_os_unmap_memory() from anywhere
>>>>>>>
>>>>>>> We need this function to be non-__init because we need access to
>>>>>>> some tables at unpredictable time--it may be before or after
>>>>>>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port
>> Console
>>>>>>> Redirection) table is needed each time a new console is registered.
>>>>>>> It can be quite early (console_initcall) or when a module is inserted.
>>>>>>> When this table accessed before acpi_gbl_permanent_mmap is set,
>>>>>>> the pointer should be unmapped.  This is exactly what this function
>>>>>>> does.
>>>>>> [Lv Zheng]
>>>>>> Why don't you use another API instead of
>> early_acpi_os_unmap_memory()
>>>> in
>>>>>> case you want to unmap things in any cases.
>>>>>> acpi_os_unmap_memory() should be the one to match this purpose.
>>>>>> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
>>>>
>>>> As far as I understand, there exist two steps in ACPI initialization:
>>>>
>>>> 1. Before acpi_gbl_permanent_mmap is set, tables received with
>>>> acpi_get_table_with_size()
>>>>    are mapped by early_memremap().  If a subsystem gets such a pointer it
>>>> should be unmapped.
>>>>
>>>> 2  After acpi_gbl_permanent_mmap is set this pointer should not be
>> unmapped
>>>> at all.
>>>>
>>> [Lv Zheng]
>>> This statement is wrong, this should be:
>>> As long as there is a __reference__ to the mapped table, the pointer should
>> not be unmapped.
>>> In fact, we have a series to introduce acpi_put_table() to achieve this.
>>> So your argument is wrong from very first point.
>>>
>>>> That exactly what early_acpi_os_unmap_memory() does--it checks
>>>> acpi_gbl_permanent_mmap.
>>>> If I had used acpi_os_unmap_memory() after acpi_gbl_permanent_mmap
>> had
>>>> been set,
>>>> it would have tried to free that pointer with an oops (actually, I checked that
>>>> and got that oops).
>>>>
>>>> So using acpi_os_unmap_memory() is not an option here, but
>>>> early_acpi_os_unmap_memory()
>>>> match perfectly.
>>> [Lv Zheng]
>>> I don't think so.
>>> For definition block tables, we know for sure there will always be references,
>> until "Unload" opcode is invoked by the AML interpreter.
>>> But for the data tables, OSPMs should use them in this way:
>>> 1. map the table
>>> 2. parse the table and convert it to OS specific structures
>>> 3. unmap the table
>>> This helps to shrink virtual memory address space usages.
>>>
>>> So from this point of view, all data tables should be unmapped right after
>> being parsed.
>>> Why do you need the map to be persistent in the kernel address space?
>>> You can always map a small table, but what if the table size is very big?
>>>
>>>>
>>>>>> And in fact early_acpi_os_unmap_memory() should be removed.
>>>>
>>>> I don't think so -- I have explained why.  It does different thing.
>>>> Probably it (and/or other functions in that api) should be renamed.
>>>>
>>> [Lv Zheng]
>>> Just let me ask one more question.
>>> eary_acpi_os_unmap_memory() is not used inside of ACPICA.
>>> How ACPICA can work with just acpi_os_unmap_memory()?
>>> You can check drivers/acpi/tbxxx.c.
>>> Especially: acpi_tb_release_temp_table() and the code invoking it.
>>>
>>>>> [Lv Zheng]
>>>>> One more thing is:
>>>>> If you can't switch your driver to use acpi_os_unmap_memory() instead of
>>>> early_acpi_os_unmap_memory(),
>>>>> then it implies that your driver does have a defect.
>>>>
>>>> I still don't understand what defect, sorry.
>>> [Lv Zheng]
>>> If you can't ensure this sequence for using the data tables:
>>> 1. map the table
>>> 2. parse the table and convert it to OS specific structure
>>> 3. unmap the table
>>> It implies there is a bug in the driver or a bug in the ACPI subsystem core.
>>
>> Exactly.
> [Lv Zheng] 
> So it looks to me:
> Changing __init to __ref here is entirely not acceptable.
> This API should stay being invoked during early stage.
> Otherwise, it may leave us untrackable code that maps tables during early stage and leaks maps to the late stage.
> If Linux contains such kind of code, I'm afraid, it will become impossible to introduce acpi_put_table() to clean up the mappings.
> Because when acpi_put_table() is called during the late stage to free a map acquired during the early stage, it then obviously will end up with panic.

Can you please sugggest a common method to access ACPI tables that
works both before *and* after acpi_gbl_permanent_mmap is set and __init code
is removed?

> Thanks and best regards
> -Lv
> 
>> The central problem here is the way Aleksey is trying to hookup a console.
>>
>> What should be happening in this series is:
>> 1. early map SPCR
>> 2. parse the SPCR table
>> 3. call add_preferred_console() to add the SPCR console to the console table
>> 4. unmap SPCR
>>
>> This trivial and unobtrusive method would already have a 8250 console
>> running via SPCR. I've already pointed this out in previous reviews.
>>
>> Further, the above method *will be required anyway* for the DBG2 table to
>> start an earlycon, which I've already pointed out in previous reviews.
>>
>> Then to enable amba-pl011 console via ACPI, add a console match() method
>> similar to the 8250 console match() method, univ8250_console_match().
>>
>> FWIW, PCI earlycon + console support was already submitted once before but
>> never picked up by GregKH. I think I'll just grab that and re-submit so
>> you would know what to emit for console options in the
>> add_preferred_console().
>>
>>
>> Regards,
>> Peter Hurley
>>
>>
>>>>> There is an early bootup requirement in Linux.
>>>>> Maps acquired during the early stage should be freed by the driver during
>> the
>>>> early stage.
>>>>> And the driver should re-acquire the memory map after booting.
>>>>
>>>> Exactly.  That's why I use early_acpi_os_unmap_memory().  The point is that
>>>> that code can be
>>>> called *before* acpi_gbl_permanent_mmap is set (at early initialization of
>> for
>>>> example 8250 console)
>>>> or *after* acpi_gbl_permanent_mmap is set (at insertion of a module that
>>>> registers a console),
>>>> We just can not tell if the received table pointer should or sould not be freed
>>>> with early_memunmap()
>>>> (actually __acpi_unmap_table() or whatever) without checking
>>>> acpi_gbl_permanent_mmap,
>>>> but that's all too low level.
>>> [Lv Zheng]
>>> The driver should make sure that:
>>> Map/unmap is paired during early stage.
>>> For late stage, it should be another pair of map/unmap.
>>>
>>>>
>>>> Another option, as you describe, is to get this pointer early, don't free it
>>> [Lv Zheng]
>>> I mean you should free it early.
>>>
>>>> untill acpi_gbl_permanent_mmap is set, then free it (with
>>>> early_acpi_os_unmap_memory(), that's
>>>> ok because acpi_gbl_permanent_mmap is set in an init code), then get the
>>>> persistent
>>>> pointer to the table.  The problem with it is that we can not just watch
>>>> acpi_gbl_permanent_mmap
>>>> to catch this exact moment.  And also accessing acpi_gbl_permanent_mmap
>> is
>>>> not good as it probably is
>>>> an implementation detail (i. e. too lowlevel) of the ACPI code.
>>>> Or I probably miss what you are suggesting.
>>>>
>>> [Lv Zheng]
>>> I mean, you should:
>>> During early stage:
>>> acpi_os_map_memory()
>>> Parse the table.
>>> acpi_os_unmap_memory().
>>>
>>>>> This is because, during early bootup stage, there are only limited slots
>>>> available for drivers to map memory.
>>>>> So by changing __init to __ref here, you probably will hide many such
>> defects.
>>>>
>>>> What defects?  This funcions checks acpi_gbl_permanent_mmap.
>>>> BTW, exactly the same thing is done in the beginning of
>>>> acpi_os_unmap_memory() and than's ok,
>>>> that function is __ref.
>>>>
>>>>> And solving issues in this way doesn't seem to be an improvement.
>>>>
>>>> Could you please tell me where I am wrong?  I still don't understand your
>> point.
>>> [Lv Zheng]
>>> But anyway, the defect should be in ACPI subsystem core.
>>> The cause should be the API itself - acpi_get_table().
>>>
>>> So I agree you can use early_acpi_os_unmap_memory() during the period the
>> root causes are not cleaned up.
>>> But the bottom line is: the driver need to ensure that
>> early_acpi_os_unmap_memory() is always invoked.
>>> As long as you can ensure this, I don't have objections for deploying
>> early_acpi_os_unmap_memory()  for now.
>>>
>>> Thanks and best regards
>>> -Lv
>>>
>>>>
>>>> Thank you
>>>> Aleksey Makarov
>>>>
>>>>>
>>>>> Thanks and best regards
>>>>> -Lv
>>>>>
>>>>>>
>>>>>> Thanks and best regards
>>>>>> -Lv
>>>>>>
>>>>>>>
>>>>>>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
>>>>>>> ---
>>>>>>>  drivers/acpi/osl.c | 6 +++++-
>>>>>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
>>>>>>> index 67da6fb..8a552cd 100644
>>>>>>> --- a/drivers/acpi/osl.c
>>>>>>> +++ b/drivers/acpi/osl.c
>>>>>>> @@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void *virt,
>>>>>>> acpi_size size)
>>>>>>>  }
>>>>>>>  EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
>>>>>>>
>>>>>>> -void __init early_acpi_os_unmap_memory(void __iomem *virt,
>> acpi_size
>>>>>> size)
>>>>>>> +/*
>>>>>>> + * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>>>> + * so it is safe to call early_acpi_os_unmap_memory() from anywhere
>>>>>>> + */
>>>>>>> +void __ref early_acpi_os_unmap_memory(void __iomem *virt,
>> acpi_size
>>>>>> size)
>>>>>>>  {
>>>>>>>  	if (!acpi_gbl_permanent_mmap)
>>>>>>>  		__acpi_unmap_table(virt, size);
>>>>>>> --
>>>>>>> 2.7.1
>>>>>>>
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>>>>>>> the body of a message to majordomo at vger.kernel.org
>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>>>>>> the body of a message to majordomo at vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From arnd at arndb.de  Fri Feb 19 03:11:10 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 12:11:10 +0100
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <HK2PR06MB05617E2ED835CFE20F65E3D38AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
 <20160218223312.GT19428@n2100.arm.linux.org.uk>
 <HK2PR06MB05617E2ED835CFE20F65E3D38AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
Message-ID: <3461274.sjccN4r7lq@wuerfel>

On Friday 19 February 2016 03:39:38 Chris Brandt wrote:
> On Thu, 18 Feb 2016, Russell King - ARM Linux wrote:
> 
> > On Thu, Feb 18, 2016 at 07:42:20PM +0000, Chris Brandt wrote:
> > > On Thu, 18 Feb 2016, Nicolas Pitre wrote:
> > > 
> > > > > Is there some way you can do a PLATFORM_COUNTER++ for each device 
> > > > > that is selected, and then XIP_KERNEL would depend on 
> > > > > PLATFORM_COUNTER == 1 ?
> > > >
> > > > I don't know all the Kconfig possibilities.
> > > >
> > > > But would something like this work?
> > > >
> > > > config FOO
> > > >   depends on !(XIP && CHOICE_MADE)
> > > >   select CHOICE_MADE
> > > 
> > > I follow your logic and that might work: If you made multiple choices,
> > > it would just take the first one.
> > > 
> > > However...I just tried it and it crashes.
> > > 
> > > scripts/kconfig/mconf  Kconfig
> > > make[2]: *** [menuconfig] Segmentation fault (core dumped)
> > > make[1]: *** [menuconfig] Error 2
> > > 
> > > 
> > > It looks like you can't depend on something not being set that you are
> > > going to set yourself. Basically..."do as I say, not as I do"
> > 
> > It's missing a bool/tristate.  Every config option needs to be typed.
> 
> 
> Thank you! That makes things better.
> 
> Technically, it seems to work (you can only select 1), but the menu system is a little flakey when you try jumping back and forth between what device to select. Somehow when 2 get selected, I need to get kbuild to go back and do a full refresh or something.
> 
> 
> I'm going to play with it some more before I start shouting victory.

I think Kconfig interprets the above as a circular dependency (using depends
and select on the same symbol), it will print a warning and misbehave randomly.

In a different thread today, I was trying to come up with a way to
reliably pick a PHYS_OFFSET value, and I think it can be done but it
quickly gets ugly without extending the Kconfig language.

Also, the same problem exists in three areas:

a) PHYS_OFFSET / DRAM_BASE
b) XIP_PHYS_ADDR
c) DEBUG_UART_VIRT/DEBUG_UART_PHYS

The last one is already really ugly and by nature causes problems
whenever someone enables DEBUG_LL and tries to boot a compressed
kernel on a platform other than the one that was configured.

XIP_PHYS_ADDR is probably the worst here, because the number does
not just depend on the SoC family but the specific board configuration
and could even change when you rearrange the partitions on your NOR
flash (unless you enforce that the kernel has to start at the
beginning of the ROM or some other fixed location).

It would be nice to handle all three of the above in a similar manner,
and I'm definitely open to a range of solutions for this, like

- always allow turning XIP_KERNEL on for all configurations, and
  expect the user to know what they are doing (as your current
  patch)

- allow turning on XIP_KERNEL as long as Kconfig can figure out that
  this has a chance of working on at least one platform (easy enough
  to implement, and similar to how we handle DEBUG_LL).

- make XIP_KERNEL and DEBUG_LL depend on either CONFIG_EXPERT or
  a new "I know this breaks other platforms and I won't complain
  about that" flag.

- implement a Kconfig method to only allow XIP_KERNEL if exactly
  one platform is enable that supports it, or if all platforms
  use the exact same PHYS_OFFSET and XIP_PHYS_ADDR settings.
  Whether we want to enforce the same thing for DEBUG_LL is a
  separate matter once that infrastructure exists.

	Arnd


From arnd at arndb.de  Fri Feb 19 03:14:41 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 12:14:41 +0100
Subject: [PATCH 1/3] irqchip: gic/realview: support more RealView DCC
 variants
In-Reply-To: <CACRpkdZD_qg0p8spr9HnFBSzXidi59J_kR8XBo-s8z-tSqKs5g@mail.gmail.com>
References: <1455803172-22747-1-git-send-email-linus.walleij@linaro.org>
 <5028476.WAQS3ylXOd@wuerfel>
 <CACRpkdZD_qg0p8spr9HnFBSzXidi59J_kR8XBo-s8z-tSqKs5g@mail.gmail.com>
Message-ID: <3474694.oM65GZWKke@wuerfel>

On Thursday 18 February 2016 19:30:27 Linus Walleij wrote:
> On Thu, Feb 18, 2016 at 3:40 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Thursday 18 February 2016 14:19:48 Marc Zyngier wrote:
> >> On 18/02/16 13:46, Linus Walleij wrote:
> >> > In the add-on file for the GIC dealing with the RealView family
> >> > we currently only handle the PB11MPCore, let's extend this to
> >> > manage the RealView EB ARM11MPCore as well. The Revision B of the
> >> > ARM11MPCore core tile is a bit special and needs special handling
> >> > as it moves a system control register around at random.
> >>
> >> Ah, 11MPCore RevB. That thing. Tried to locate one in the magic
> >> cupboard, and failed. Oh well...
> >
> > What surprised me though is that it's enabled by default:
> 
> Looks like my fault according to git-blame...
> 
> I think this happened when making cover-all defconfigs for
> multiplatform. I think I just turned everything on... not realizing
> that turning on RevB disabled RevA+RevC.
> 
> However since it is the *only* version that works with QEMU
> it actually makes some kind of weird sense to have it enabled
> since the QEMU version is probably more common than
> RevA+RevC...

Do we have reason to believe that any RevA exists?

My understanding from reading the source was that RevB was everything
there was until support for RevC got added and RevB gained a
separate option, or possibly that RevA was the same as RevB but
it was never common enough to even get mentioned in the source.

	Arnd


From mark.rutland at arm.com  Fri Feb 19 03:35:57 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Fri, 19 Feb 2016 11:35:57 +0000
Subject: [PATCH] arm64: kasan: clear stale stack poison
In-Reply-To: <20160218181356.GF2538@e104818-lin.cambridge.arm.com>
References: <1455816458-19485-1-git-send-email-mark.rutland@arm.com>
 <20160218175447.GD2538@e104818-lin.cambridge.arm.com>
 <20160218180353.GG16883@arm.com>
 <20160218181356.GF2538@e104818-lin.cambridge.arm.com>
Message-ID: <20160219113556.GA7797@leverpostej>

On Thu, Feb 18, 2016 at 06:13:57PM +0000, Catalin Marinas wrote:
> On Thu, Feb 18, 2016 at 06:03:54PM +0000, Will Deacon wrote:
> > On Thu, Feb 18, 2016 at 05:54:47PM +0000, Catalin Marinas wrote:
> > > On Thu, Feb 18, 2016 at 05:27:38PM +0000, Mark Rutland wrote:
> > > > @@ -145,6 +146,7 @@ ENTRY(cpu_resume_mmu)
> > > >  ENDPROC(cpu_resume_mmu)
> > > >  	.popsection
> > > >  cpu_resume_after_mmu:
> > > > +	kasan_unpoison_stack 96
> > > 
> > > I don't think the 96 here is needed since we populate the stack in
> > > assembly (__cpu_suspend_enter) and unwind it again still in assembly
> > > (cpu_resume_after_mmu), so no KASAN shadow writes/reads.
> > > 
> > > Otherwise the patch looks fine.
> > 
> > I'd much rather it was written in C -- is there a reason we can't do
> > that if we use a separate compilation unit where the compiler will
> > honour the fno-sanitize flag?
> 
> A simple, non-sanitised C wrapper around __cpu_suspend_enter() would
> probably work. We need to make sure it is static inline when !KASAN to
> avoid an unnecessary function call.

I think this could work, but I don't see a way that we can get a safe
value of the SP. Using current_stack_pointer() only gives us a snapshot,
and the real SP value may move before/after. So that snaphot, even if
taken in cpu_suspend, is not guaranteed to be above all the shadow
poison.

> Or we just move cpu_suspend() to a different compilation unit, though
> that's a slightly larger function which we may want to track under
> KASAN.

If we're going to force something into another compilation unit, that
may as well be the functions on the critical path:
psci_suspend_finisher, psci_cpu_suspend, and invoke_psci_fn_*.

Then we don't need to bother with the clearing on the return path at
all, as there should never be any stale shadow to begin with.

Thanks,
Mark.


From julien.grall at arm.com  Fri Feb 19 03:41:33 2016
From: julien.grall at arm.com (Julien Grall)
Date: Fri, 19 Feb 2016 11:41:33 +0000
Subject: [PATCH v2 1/6] KVM: arm/arm64: arch_timer: Gather KVM specific
 information in a structure
In-Reply-To: <56C6F43D.3010503@arm.com>
References: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
 <1455204804-31830-2-git-send-email-julien.grall@arm.com>
 <56C6C318.3000205@redhat.com> <56C6F43D.3010503@arm.com>
Message-ID: <56C6FF6D.6080800@arm.com>



On 19/02/16 10:53, Julien Grall wrote:
> --
> Julien Grall
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy
> the information in any medium. Thank you.

Apologies, this footer shouldn't have been there.

-- 
Julien Grall


From marc.zyngier at arm.com  Fri Feb 19 03:49:43 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Feb 2016 11:49:43 +0000
Subject: A gic problem about eoi
In-Reply-To: <56C6B895.6070400@huawei.com>
References: <56C5500A.2060104@huawei.com> <20160218090033.289de1c3@arm.com>
 <56C6B895.6070400@huawei.com>
Message-ID: <56C70157.8010505@arm.com>

On 19/02/16 06:39, Yang Yingliang wrote:
> 
> 
> On 2016/2/18 17:00, Marc Zyngier wrote:
>> On Thu, 18 Feb 2016 13:00:58 +0800
>> Yang Yingliang <yangyingliang at huawei.com> wrote:
>>
>> Hi Yang,
>>
>>> Hi, Marc
>>>
>>> We found if hardware clear pending and active status is slower than
>>> software handling, the new sgi will be merged because of hardware
>>> status. The new sgi will be lost.
>>>
>>> If we add a dsb instruction after gic_write_eoir(), it can avoid this
>>> case happening.
>>>
>>> Is it a right way to add a dsb instruction after gic_write_eoir()
>>> in current gic driver code ?
>>
>> I suspect your problem is not so much the EOI, but that the read of
>> ICC_IAR1_EL1 doesn't propagate the Ack quickly enough, leading to the
>> transition from pending to active to still be in flux when the interrupt
>> is EOIed. This is where a DSB is required (and was missing until very
>> recently).
>>
>> Does 1a1ebd5 ("irqchip/gic-v3: Make sure read from ICC_IAR1_EL1 is
>> visible on redestributor") solve your problem?
> 
> I tested this patch, it can solve the problem.
> 
> Will this patch queue to stable ?

Yes - It may not directly apply to older versions, but it is pretty
trivial to backport.

Thanks for testing,

	M.
-- 
Jazz is not dead. It just smells funny...


From marc.zyngier at arm.com  Fri Feb 19 03:54:02 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Feb 2016 11:54:02 +0000
Subject: [PATCH v2 1/6] KVM: arm/arm64: arch_timer: Gather KVM specific
 information in a structure
In-Reply-To: <56C6C318.3000205@redhat.com>
References: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
 <1455204804-31830-2-git-send-email-julien.grall@arm.com>
 <56C6C318.3000205@redhat.com>
Message-ID: <56C7025A.8030307@arm.com>

On 19/02/16 07:24, Wei Huang wrote:
> 
> 
> On 02/11/2016 09:33 AM, Julien Grall wrote:
>> Introduce a structure which are filled up by the arch timer driver and
>> used by the virtual timer in KVM.
>>
>> The first member of this structure will be the timecounter. More members
>> will be added later.
>>
>> This is also dropping arch_timer_get_timecounter as it was only used by
>> the KVM code. Furthermore, a stub for the new helper hasn't been
>> introduced because KVM is requiring the arch timer for both ARM64 and
>> ARM32.
>>
>> Signed-off-by: Julien Grall <julien.grall at arm.com>
>>
>> ---
>> Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
>> Cc: Thomas Gleixner <tglx at linutronix.de>
>> Cc: Christoffer Dall <christoffer.dall at linaro.org>
>> Cc: Marc Zyngier <marc.zyngier at arm.com>
>> Cc: Gleb Natapov <gleb at kernel.org>
>> Cc: Paolo Bonzini <pbonzini at redhat.com>
>> ---
>>  drivers/clocksource/arm_arch_timer.c |  9 +++++----
>>  include/clocksource/arm_arch_timer.h | 12 ++++++------
>>  virt/kvm/arm/arch_timer.c            |  6 +++---
>>  3 files changed, 14 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>> index c64d543..6eb2c5d 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -447,11 +447,11 @@ static struct cyclecounter cyclecounter = {
>>  	.mask	= CLOCKSOURCE_MASK(56),
>>  };
>>  
>> -static struct timecounter timecounter;
>> +static struct arch_timer_kvm_info arch_timer_kvm_info;
>>  
>> -struct timecounter *arch_timer_get_timecounter(void)
>> +struct arch_timer_kvm_info *arch_timer_get_kvm_info(void)
>>  {
>> -	return &timecounter;
>> +	return &arch_timer_kvm_info;
>>  }
>>  
>>  static void __init arch_counter_register(unsigned type)
>> @@ -479,7 +479,8 @@ static void __init arch_counter_register(unsigned type)
>>  	clocksource_register_hz(&clocksource_counter, arch_timer_rate);
>>  	cyclecounter.mult = clocksource_counter.mult;
>>  	cyclecounter.shift = clocksource_counter.shift;
>> -	timecounter_init(&timecounter, &cyclecounter, start_count);
>> +	timecounter_init(&arch_timer_kvm_info.timecounter,
>> +			 &cyclecounter, start_count);
>>  
>>  	/* 56 bits minimum, so we assume worst case rollover */
>>  	sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate);
>> diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
>> index 25d0914..4d487f8 100644
>> --- a/include/clocksource/arm_arch_timer.h
>> +++ b/include/clocksource/arm_arch_timer.h
>> @@ -49,11 +49,16 @@ enum arch_timer_reg {
>>  
>>  #define ARCH_TIMER_EVT_STREAM_FREQ	10000	/* 100us */
>>  
>> +struct arch_timer_kvm_info {
>> +	struct timecounter timecounter;
>> +};
>> +
>>  #ifdef CONFIG_ARM_ARCH_TIMER
>>  
>>  extern u32 arch_timer_get_rate(void);
>>  extern u64 (*arch_timer_read_counter)(void);
>> -extern struct timecounter *arch_timer_get_timecounter(void);
>> +
>> +extern struct arch_timer_kvm_info *arch_timer_get_kvm_info(void);
>>  
>>  #else
>>  
>> @@ -67,11 +72,6 @@ static inline u64 arch_timer_read_counter(void)
>>  	return 0;
>>  }
>>  
>> -static inline struct timecounter *arch_timer_get_timecounter(void)
>> -{
>> -	return NULL;
>> -}
>> -
> 
> Most parts are OK. Regarding removing this function from the #else area,
> is there a possibility to have CONFIG_ARM_ARCH_TIMER=n and CONFIG_KVM=y.
> If so, will the compilation fails here?

On arm64, arch timers are not optional (see the "select ARM_ARCH_TIMER"
in arch/arm64/Kconfig). On 32bit, we have "depends on ARM_VIRT_EXT &&
ARM_LPAE && ARM_ARCH_TIMER", which nails it as well.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From arnd at arndb.de  Fri Feb 19 03:53:52 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 12:53:52 +0100
Subject: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
In-Reply-To: <CAD8Lp47LGUc3-MFpU+3iNjXJL0i4nLTY_49NUxFXeZ2SokDuaQ@mail.gmail.com>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <CAOQ7t2aqZj3STFsdTSQZMTK5U+8Oem8oFroxHKWkt=AeP+Zczg@mail.gmail.com>
 <CAD8Lp47LGUc3-MFpU+3iNjXJL0i4nLTY_49NUxFXeZ2SokDuaQ@mail.gmail.com>
Message-ID: <2394082.bSJ4DLLTEt@wuerfel>

On Thursday 18 February 2016 15:27:06 Daniel Drake wrote:
> On Thu, Feb 18, 2016 at 3:04 PM, Carlo Caione <carlo at caione.org> wrote:
> >> However, if some or all of the other devices actually are entirely
> >> made up of register ranges within cbus, that would indicate that
> >> cbus itself is not just a collection of random registers but something
> >> that could be considered a bus of itself in hardware, and then
> >> we could represent the other devices as children of this bus.
> >
> > I think that this is exactly the case. We are missing this cbus in the
> > DTS because (for lacking of proper documentation) we are not sure
> > about start / end / size.
> 
> Here's a hint from the vendor kernel
> https://github.com/endlessm/linux-meson/blob/master/arch/arm/mach-meson8b/iomapping.c#L87
> 
> Having a cbus bus node with child devices does sound like it would
> reflect this particular view of the hardware design. How would we then
> represent the hwrev registers under that?
> 
> I am also curious if this is the common practice. We were working with
> Exynos devices before, and even though many of the components are on
> the AXI bus there, there is no AXI bus representation in the DT. But
> now that I go digging, I see other SoCs that do have a DT bus
> representation very similar to what's being described, such as the apb
> and axi busses in mmp2.dtsi. Is one approach preferred over the other
> for new SoC support?

I would always prefer having the dts files describe the hardware as best
as they can.

	Arnd


From guodong.xu at linaro.org  Fri Feb 19 03:58:24 2016
From: guodong.xu at linaro.org (Guodong Xu)
Date: Fri, 19 Feb 2016 19:58:24 +0800
Subject: [PATCH V5 0/3] add gpio/pinctrl/spi DTS for hi6220 and hikey
Message-ID: <1455883107-8411-1-git-send-email-guodong.xu@linaro.org>

As of V4, this patchset has been ack'ed by Rob Herring.

V5, added pmx0 pmx1 pmx2 nodes description into hi6220.dtsi.

Zhong Kaihua (3):
  arm64: dts: Add Hi6220 gpio configuration nodes
  arm64: dts: add Hi6220 pinctrl configuration nodes
  arm64: dts: add Hi6220 spi configuration nodes

 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts   |   3 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi        | 351 +++++++++++
 arch/arm64/boot/dts/hisilicon/hikey-gpio.dtsi    | 607 +++++++++++++++++++
 arch/arm64/boot/dts/hisilicon/hikey-pinctrl.dtsi | 705 +++++++++++++++++++++++
 include/dt-bindings/pinctrl/hisi.h               |  59 ++
 5 files changed, 1725 insertions(+)
 create mode 100644 arch/arm64/boot/dts/hisilicon/hikey-gpio.dtsi
 create mode 100644 arch/arm64/boot/dts/hisilicon/hikey-pinctrl.dtsi
 create mode 100644 include/dt-bindings/pinctrl/hisi.h

-- 
1.9.1



From guodong.xu at linaro.org  Fri Feb 19 03:58:25 2016
From: guodong.xu at linaro.org (Guodong Xu)
Date: Fri, 19 Feb 2016 19:58:25 +0800
Subject: [PATCH V5 1/3] arm64: dts: Add Hi6220 gpio configuration nodes
In-Reply-To: <1455883107-8411-1-git-send-email-guodong.xu@linaro.org>
References: <1455883107-8411-1-git-send-email-guodong.xu@linaro.org>
Message-ID: <1455883107-8411-2-git-send-email-guodong.xu@linaro.org>

From: Zhong Kaihua <zhongkaihua at huawei.com>

Add Hi6220 gpio configuration nodes

Signed-off-by: Zhong Kaihua <zhongkaihua at huawei.com>
Signed-off-by: Kong Xinwei <kong.kongxinwei at hisilicon.com>

Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Wei Xu <xuwei5 at hisilicon.com>
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |   1 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi      | 259 +++++++++++
 arch/arm64/boot/dts/hisilicon/hikey-gpio.dtsi  | 607 +++++++++++++++++++++++++
 3 files changed, 867 insertions(+)
 create mode 100644 arch/arm64/boot/dts/hisilicon/hikey-gpio.dtsi

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 17bd793..f9b2d1e 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -8,6 +8,7 @@
 /dts-v1/;
 
 #include "hi6220.dtsi"
+#include "hikey-gpio.dtsi"
 
 / {
 	model = "HiKey Development Board";
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 2585236..ad7074d 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -249,5 +249,264 @@
 			clocks = <&ao_ctrl 27>;
 			clock-names = "apb_pclk";
 		};
+
+		gpio0: gpio at f8011000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf8011000 0x0 0x1000>;
+			interrupts = <0 52 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio1: gpio at f8012000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf8012000 0x0 0x1000>;
+			interrupts = <0 53 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio2: gpio at f8013000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf8013000 0x0 0x1000>;
+			interrupts = <0 54 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio3: gpio at f8014000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf8014000 0x0 0x1000>;
+			interrupts = <0 55 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio4: gpio at f7020000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf7020000 0x0 0x1000>;
+			interrupts = <0 56 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio5: gpio at f7021000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf7021000 0x0 0x1000>;
+			interrupts = <0 57 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio6: gpio at f7022000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf7022000 0x0 0x1000>;
+			interrupts = <0 58 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio7: gpio at f7023000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf7023000 0x0 0x1000>;
+			interrupts = <0 59 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio8: gpio at f7024000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf7024000 0x0 0x1000>;
+			interrupts = <0 60 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio9: gpio at f7025000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf7025000 0x0 0x1000>;
+			interrupts = <0 61 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio10: gpio at f7026000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf7026000 0x0 0x1000>;
+			interrupts = <0 62 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio11: gpio at f7027000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf7027000 0x0 0x1000>;
+			interrupts = <0 63 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio12: gpio at f7028000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf7028000 0x0 0x1000>;
+			interrupts = <0 64 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio13: gpio at f7029000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf7029000 0x0 0x1000>;
+			interrupts = <0 65 0x4>;
+			gpio-controller;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio14: gpio at f702a000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf702a000 0x0 0x1000>;
+			interrupts = <0 66 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio15: gpio at f702b000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf702b000 0x0 0x1000>;
+			interrupts = <0 67 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio16: gpio at f702c000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf702c000 0x0 0x1000>;
+			interrupts = <0 68 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio17: gpio at f702d000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf702d000 0x0 0x1000>;
+			interrupts = <0 69 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio18: gpio at f702e000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf702e000 0x0 0x1000>;
+			interrupts = <0 70 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
+
+		gpio19: gpio at f702f000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x0 0xf702f000 0x0 0x1000>;
+			interrupts = <0 71 0x4>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&ao_ctrl 2>;
+			clock-names = "apb_pclk";
+			status = "ok";
+		};
 	};
 };
diff --git a/arch/arm64/boot/dts/hisilicon/hikey-gpio.dtsi b/arch/arm64/boot/dts/hisilicon/hikey-gpio.dtsi
new file mode 100644
index 0000000..09242f0
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hikey-gpio.dtsi
@@ -0,0 +1,607 @@
+/ {
+	gpio_rstout_n:gpio_rstout_n {
+		gpios;
+	};
+	gpio_pmu_peri_en:gpio_pmu_peri_en {
+		gpios;
+	};
+	gpio_sysclk0_en:gpio_sysclk0_en {
+		gpios;
+	};
+	gpio_jtag_tdo:gpio_jtag_tdo {
+		gpios;
+	};
+	/* LCB: PWR_HOLD_GPIO0_0 */
+	gpio_pwr_hold:gpio_pwr_hold {
+		gpios = <&gpio0 0 0>;
+	};
+	/* LCB: DSI_SEL_GPIO0_1 */
+	gpio_dsi_sel:gpio_dsi_sel {
+		gpios = <&gpio0 1 0>;
+	};
+	/* LCB: USB_HUB_RESET_N_GPIO0_2 */
+	gpio_usb_hub_reset_n:gpio_usb_hub_reset_n {
+		gpios = <&gpio0 2 0>;
+	};
+	/* LCB: USB_SEL_GPIO0_3 */
+	gpio_usb_sel:gpio_usb_sel {
+		gpios = <&gpio0 3 0>;
+	};
+	/* LCB: HDMI_PD_GPIO0_4 */
+	gpio_hdmi_pd:gpio_hdmi_pd {
+		gpios = <&gpio0 4 0>;
+	};
+	/* LCB: WL_REG_ON_GPIO0_5 */
+	gpio_wl_en:gpio_wl_en {
+		gpios = <&gpio0 5 0>;
+	};
+	/* LCB: PWRON_DET_GPIO0_6 */
+	gpio_pwron_det:gpio_pwron_det {
+		gpios = <&gpio0 6 0>;
+	};
+	/* LCB: 5V_HUB_EN_GPIO0_7 */
+	gpio_usb_dev_det:gpio_usb_dev_det {
+		gpios = <&gpio0 7 0>;
+	};
+	/* LCB: SD_DET_GPIO1_0 */
+	gpio_sd_det:gpio_sd_det {
+		gpios = <&gpio1 0 0>;
+	};
+	/* LCB: HDMI_INT_GPIO1_1 */
+	gpio_hdmi_int:gpio_hdmi_int {
+		gpios = <&gpio1 1 0>;
+	};
+	/* LCB: PMU_IRQ_N_GPIO1_2 */
+	gpio_pmu_irq_n:gpio_pmu_irq_n {
+		gpios = <&gpio1 2 0>;
+	};
+	/* LCB: WL_HOST_WAKE_GPIO1_3 */
+	gpio_wl_host_wake:gpio_wl_host_wake {
+		gpios = <&gpio1 3 0>;
+	};
+	gpio_nfc_int:gpio_nfc_int {
+		gpios = <&gpio1 4 0>;
+	};
+	gpio_unused_001:gpio_unused_001 {
+		gpios = <&gpio1 5 0>;
+	};
+	/* LCB: BT_REG_ON_GPIO1_7 */
+	gpio_bt_reg_on:gpio_bt_reg_on {
+		gpios = <&gpio1 7 0>;
+	};
+	/* LCB: GPIO2_0, J2 */
+	gpio_j2_2_0:gpio_j2_2_0 {
+		gpios = <&gpio2 0 0>;
+	};
+	/* LCB: GPIO2_1, J2 */
+	gpio_j2_2_1:gpio_j2_2_1 {
+		gpios = <&gpio2 1 0>;
+	};
+	/* LCB: GPIO2_2, J2 */
+	gpio_j2_2_2:gpio_j2_2_2 {
+		gpios = <&gpio2 2 0>;
+	};
+	/* LCB: GPIO2_3, J2 */
+	gpio_j2_2_3:gpio_j2_2_3 {
+		gpios = <&gpio2 3 0>;
+	};
+	/* LCB: GPIO2_4, J2 */
+	gpio_j2_2_4:gpio_j2_2_4 {
+		gpios = <&gpio2 4 0>;
+	};
+	/* LCB: USB_ID_DET_GPIO2_5 */
+	gpio_usb_id_det:gpio_usb_id_det {
+		gpios = <&gpio2 5 0>;
+	};
+	/* LCB: USB_VBUS_DET_GPIO2_6 */
+	gpio_vbus_det:gpio_vbus_det {
+		gpios = <&gpio2 6 0>;
+	};
+	/* LCB: GPIO2_7, J2 */
+	gpio_j2_2_7:gpio_j2_2_7 {
+		gpios = <&gpio2 7 0>;
+	};
+	gpio_rf_reset0:gpio_rf_reset0 {
+		gpios;
+	};
+	gpio_rf_reset1:gpio_rf_reset1 {
+		gpios;
+	};
+	gpio_boot_sel:gpio_boot_sel {
+		gpios = <&gpio10 0 0>;
+	};
+	gpio_pmu_ssi:gpio_pmu_ssi {
+		gpios;
+	};
+	gpio_gps_ref_clk:gpio_gps_ref_clk {
+		gpios = <&gpio8 2 0>;
+	};
+	gpio_sd_clk:gpio_sd_clk {
+		gpios = <&gpio8 3 0>;
+	};
+	gpio_sd_cmd:gpio_sd_cmd {
+		gpios = <&gpio8 4 0>;
+	};
+	gpio_sd_data0:gpio_sd_data0 {
+		gpios = <&gpio8 5 0>;
+	};
+	gpio_sd_data1:gpio_sd_data1 {
+		gpios = <&gpio8 6 0>;
+	};
+	gpio_sd_data2:gpio_sd_data2 {
+		gpios = <&gpio8 7 0>;
+	};
+	gpio_sd_data3:gpio_sd_data3 {
+		gpios = <&gpio9 0 0>;
+	};
+	gpio_unused_002:gpio_unused_002 {
+		gpios;
+	};
+	gpio_mcam_pwdn:gpio_mcam_pwdn {
+		gpios = <&gpio9 1 0>;
+	};
+	gpio_vcm_pwdn:gpio_vcm_pwdn {
+		gpios = <&gpio9 2 0>;
+	};
+	gpio_scam_pwdn:gpio_scam_pwdn {
+		gpios = <&gpio9 3 0>;
+	};
+	gpio_cam_id0:gpio_cam_id0 {
+		gpios = <&gpio9 4 0>;
+	};
+	gpio_cam_id1:gpio_cam_id1 {
+		gpios = <&gpio9 5 0>;
+	};
+	gpio_flash_strobe:gpio_flash_strobe {
+		gpios = <&gpio9 6 0>;
+	};
+	gpio_mcam_mclk:gpio_mcam_mclk {
+		gpios = <&gpio9 7 0>;
+	};
+	gpio_scam_mclk:gpio_scam_mclk {
+		gpios = <&gpio10 1 0>;
+	};
+	gpio_cam_reset0:gpio_cam_reset0 {
+		gpios = <&gpio10 2 0>;
+	};
+	gpio_cam_reset1:gpio_cam_reset1 {
+		gpios = <&gpio10 3 0>;
+	};
+	gpio_tp_rst_n:gpio_tp_rst_n {
+		gpios = <&gpio10 4 0>;
+	};
+	gpio_unused_003:gpio_unused_003 {
+		gpios = <&gpio10 5 0>;
+	};
+	gpio_isp_sda0:gpio_isp_sda0 {
+		gpios = <&gpio10 6 0>;
+	};
+	gpio_isp_scl0:gpio_isp_scl0 {
+		gpios = <&gpio10 7 0>;
+	};
+	gpio_isp_sda1:gpio_isp_sda1 {
+		gpios = <&gpio11 0 0>;
+	};
+	gpio_isp_scl1:gpio_isp_scl1 {
+		gpios = <&gpio11 1 0>;
+	};
+	gpio_mdm_rst:gpio_mdm_rst {
+		gpios = <&gpio11 2 0>;
+	};
+	gpio_hkadc_ssi:gpio_hkadc_ssi {
+		gpios;
+	};
+	gpio_codec_clk:gpio_codec_clk {
+		gpios;
+	};
+	gpio_ap_wakeup_mdm:gpio_ap_wakeup_mdm {
+		gpios = <&gpio11 3 0>;
+	};
+	gpio_codec_sync:gpio_codec_sync {
+		gpios = <&gpio11 4 0>;
+	};
+	gpio_codec_datain:gpio_codec_datain {
+		gpios = <&gpio11 5 0>;
+	};
+	gpio_codec_dataout:gpio_codec_dataout {
+		gpios = <&gpio11 6 0>;
+	};
+	gpio_fm_xclk:gpio_fm_xclk {
+		gpios = <&gpio11 7 0>;
+	};
+	gpio_fm_xfs:gpio_fm_xfs {
+		gpios = <&gpio12 0 0>;
+	};
+	gpio_fm_di:gpio_fm_di {
+		gpios = <&gpio12 1 0>;
+	};
+	gpio_fm_do:gpio_fm_do {
+		gpios = <&gpio12 2 0>;
+	};
+	gpio_bt_xclk:gpio_bt_xclk {
+		gpios;
+	};
+	gpio_bt_xfs:gpio_bt_xfs {
+		gpios;
+	};
+	gpio_bt_di:gpio_bt_di {
+		gpios;
+	};
+	gpio_bt_do:gpio_bt_do {
+		gpios;
+	};
+	gpio_usim0_clk:gpio_usim0_clk {
+		gpios;
+	};
+	gpio_usim0_data:gpio_usim0_data {
+		gpios;
+	};
+	gpio_usim0_rst:gpio_usim0_rst {
+		gpios;
+	};
+	gpio_usim1_clk:gpio_usim1_clk {
+		gpios = <&gpio12 3 0>;
+	};
+	gpio_usim1_data:gpio_usim1_data {
+		gpios = <&gpio12 4 0>;
+	};
+	gpio_usim1_rst:gpio_usim1_rst {
+		gpios = <&gpio12 5 0>;
+	};
+	gpio_unused_004:gpio_unused_004 {
+		gpios = <&gpio12 6 0>;
+	};
+	gpio_unused_005:gpio_unused_005 {
+		gpios = <&gpio12 7 0>;
+	};
+	gpio_uart0_rxd:gpio_uart0_rxd {
+		gpios = <&gpio13 0 0>;
+	};
+	gpio_uart0_txd:gpio_uart0_txd {
+		gpios = <&gpio13 1 0>;
+	};
+	gpio_bt_uart_cts_n:gpio_bt_uart_cts_n {
+		gpios = <&gpio13 2 0>;
+	};
+	gpio_bt_uart_rts_n:gpio_bt_uart_rts_n {
+		gpios = <&gpio13 3 0>;
+	};
+	gpio_bt_uart_rxd:gpio_bt_uart_rxd {
+		gpios = <&gpio13 4 0>;
+	};
+	gpio_bt_uart_txd:gpio_bt_uart_txd {
+		gpios = <&gpio13 5 0>;
+	};
+	gpio_gps_uart_cts_n:gpio_gps_uart_cts_n {
+		gpios = <&gpio13 6 0>;
+	};
+	gpio_gps_uart_rts_n:gpio_gps_uart_rts_n {
+		gpios = <&gpio13 7 0>;
+	};
+	gpio_gps_uart_rxd:gpio_gps_uart_rxd {
+		gpios = <&gpio14 0 0>;
+	};
+	gpio_gps_uart_txd:gpio_gps_uart_txd {
+		gpios = <&gpio14 1 0>;
+	};
+	gpio_i2c0_scl:gpio_i2c0_scl {
+		gpios = <&gpio14 2 0>;
+	};
+	gpio_i2c0_sda:gpio_i2c0_sda {
+		gpios = <&gpio14 3 0>;
+	};
+	gpio_i2c1_scl:gpio_i2c1_scl {
+		gpios = <&gpio14 4 0>;
+	};
+	gpio_i2c1_sda:gpio_i2c1_sda {
+		gpios = <&gpio14 5 0>;
+	};
+	gpio_i2c2_scl:gpio_i2c2_scl {
+		gpios = <&gpio14 6 0>;
+	};
+	gpio_i2c2_sda:gpio_i2c2_sda {
+		gpios = <&gpio14 7 0>;
+	};
+	gpio_emmc_clk:gpio_emmc_clk {
+		gpios;
+	};
+	gpio_emmc_cmd:gpio_emmc_cmd {
+		gpios;
+	};
+	gpio_emmc_data0:gpio_emmc_data0 {
+		gpios;
+	};
+	gpio_emmc_data1:gpio_emmc_data1 {
+		gpios;
+	};
+	gpio_emmc_data2:gpio_emmc_data2 {
+		gpios;
+	};
+	gpio_emmc_data3:gpio_emmc_data3 {
+		gpios;
+	};
+	gpio_emmc_data4:gpio_emmc_data4 {
+		gpios;
+	};
+	gpio_emmc_data5:gpio_emmc_data5 {
+		gpios;
+	};
+	gpio_emmc_data6:gpio_emmc_data6 {
+		gpios;
+	};
+	gpio_emmc_data7:gpio_emmc_data7 {
+		gpios;
+	};
+	gpio_emmc_rst_n:gpio_emmc_rst_n {
+		gpios;
+	};
+	gpio_unused_006:gpio_unused_006 {
+		gpios;
+	};
+	gpio_sdio_clk:gpio_sdio_clk {
+		gpios = <&gpio15 0 0>;
+	};
+	gpio_sdio_cmd:gpio_sdio_cmd {
+		gpios = <&gpio15 1 0>;
+	};
+	gpio_sdio_data0:gpio_sdio_data0 {
+		gpios = <&gpio15 2 0>;
+	};
+	gpio_sdio_data1:gpio_sdio_data1 {
+		gpios = <&gpio15 3 0>;
+	};
+	gpio_sdio_data2:gpio_sdio_data2 {
+		gpios = <&gpio15 4 0>;
+	};
+	gpio_sdio_data3:gpio_sdio_data3 {
+		gpios = <&gpio15 5 0>;
+	};
+	gpio_unused_007:gpio_unused_007 {
+		gpios;
+	};
+	/* LCB: GPIO3_0, on J15, as general purpose input */
+	gpio_j15_3_0:gpio_j15_3_0 {
+		gpios = <&gpio3 0 0>;
+	};
+	gpio_jtag_sel0:gpio_jtag_sel0 {
+		gpios = <&gpio3 1 0>;
+	};
+	gpio_jtag_sel1:gpio_jtag_sel1 {
+		gpios = <&gpio3 2 0>;
+	};
+	gpio_lcd_rst_n:gpio_lcd_rst_n {
+		gpios = <&gpio3 3 0>;
+	};
+	gpio_aux_ssi0:gpio_aux_ssi0 {
+		gpios = <&gpio3 4 0>;
+	};
+	/* LCB: WLAN_ACTIVE_GPIO3_5, connects to led, as general purpose */
+	gpio_wlan_active_led:gpio_wlan_active_led {
+		gpios = <&gpio3 5 0>;
+	};
+	gpio_unused_008:gpio_unused_008 {
+		gpios = <&gpio3 6 0>;
+	};
+	gpio_ap_wakeup_bt:gpio_ap_wakeup_bt {
+		gpios = <&gpio3 7 0>;
+	};
+	/* LCB: USER_LED1_GPIO4_0 */
+	gpio_user_led_1:gpio_user_led_1 {
+		gpios = <&gpio4 0 0>;
+	};
+	/* LCB: USER_LED1_GPIO4_1 */
+	gpio_user_led_2:gpio_user_led_2 {
+		gpios = <&gpio4 1 0>;
+	};
+	/* LCB: USER_LED1_GPIO4_2 */
+	gpio_user_led_3:gpio_user_led_3 {
+		gpios = <&gpio4 2 0>;
+	};
+	/* LCB: USER_LED1_GPIO4_3 */
+	gpio_user_led_4:gpio_user_led_4 {
+		gpios = <&gpio4 3 0>;
+	};
+	gpio_i2c3_scl:gpio_i2c3_scl {
+		gpios = <&gpio4 4 0>;
+	};
+	gpio_i2c3_sda:gpio_i2c3_sda {
+		gpios = <&gpio4 5 0>;
+	};
+	gpio_wlan_bt_priority:gpio_wlan_bt_priority {
+		gpios = <&gpio4 6 0>;
+	};
+	/* LCB: BT_ACTIVE_GPIO4_7, connects to led, as general purpose */
+	gpio_bt_active_led:gpio_bt_active_led {
+		gpios = <&gpio4 7 0>;
+	};
+	gpio_uart3_cts_n:gpio_uart3_cts_n {
+		gpios = <&gpio5 0 0>;
+	};
+	gpio_uart3_rts_n:gpio_uart3_rts_n {
+		gpios = <&gpio5 1 0>;
+	};
+	gpio_uart3_rxd:gpio_uart3_rxd {
+		gpios = <&gpio5 2 0>;
+	};
+	gpio_uart3_txd:gpio_uart3_txd {
+		gpios = <&gpio5 3 0>;
+	};
+	gpio_aux_ssi1:gpio_aux_ssi1 {
+		gpios = <&gpio5 4 0>;
+	};
+	gpio_unused_009:gpio_unused_009 {
+		gpios = <&gpio5 5 0>;
+	};
+	gpio_modem_pcm_xclk:gpio_modem_pcm_xclk {
+		gpios = <&gpio5 6 0>;
+	};
+	gpio_modem_pcm_xfs:gpio_modem_pcm_xfs {
+		gpios = <&gpio5 7 0>;
+	};
+	gpio_spi0_di:gpio_spi0_di {
+		gpios = <&gpio6 0 0>;
+	};
+	gpio_spi0_do:gpio_spi0_do {
+		gpios = <&gpio6 1 0>;
+	};
+	gpio_spi0_cs_n:gpio_spi0_cs_n {
+		gpios = <&gpio6 2 0>;
+	};
+	gpio_spi0_clk:gpio_spi0_clk {
+		gpios = <&gpio6 3 0>;
+	};
+	gpio_lte_tx_active:gpio_lte_tx_active {
+		gpios = <&gpio6 4 0>;
+	};
+	gpio_lte_rx_active:gpio_lte_rx_active {
+		gpios = <&gpio6 5 0>;
+	};
+	gpio_lcd_id0:gpio_lcd_id0 {
+		gpios = <&gpio6 6 0>;
+	};
+	/* LCB: GPIO6_7_DSI_TE0 */
+	gpio_dsi_te0:gpio_dsi_te0 {
+		gpios = <&gpio6 7 0>;
+	};
+	gpio_lcd_id1:gpio_lcd_id1 {
+		gpios = <&gpio7 0 0>;
+	};
+	gpio_volume1_n:gpio_volume1_n {
+		gpios = <&gpio7 1 0>;
+	};
+	gpio_uart5_rxd:gpio_uart5_rxd {
+		gpios = <&gpio7 2 0>;
+	};
+	gpio_uart5_txd:gpio_uart5_txd {
+		gpios = <&gpio7 3 0>;
+	};
+	gpio_modem_pcm_di:gpio_modem_pcm_di {
+		gpios = <&gpio7 4 0>;
+	};
+	gpio_modem_pcm_do:gpio_modem_pcm_do {
+		gpios = <&gpio7 5 0>;
+	};
+	gpio_uart4_rxd:gpio_uart4_rxd {
+		gpios = <&gpio7 6 0>;
+	};
+	gpio_uart4_txd:gpio_uart4_txd {
+		gpios = <&gpio7 7 0>;
+	};
+	gpio_ap_wakeup_wl:gpio_ap_wakeup_wl {
+		gpios = <&gpio8 0 0>;
+	};
+	gpio_mdm_pwr_en:gpio_mdm_pwr_en {
+		gpios = <&gpio8 1 0>;
+	};
+	gpio_tcxo0_afc:gpio_tcxo0_afc {
+		gpios = <&gpio15 6 0>;
+	};
+	gpio_rf_ssi0:gpio_rf_ssi0 {
+		gpios;
+	};
+	gpio_rf_tcvr_on0:gpio_rf_tcvr_on0 {
+		gpios;
+	};
+	gpio_rf_mipi_clk0:gpio_rf_mipi_clk0 {
+		gpios;
+	};
+	gpio_rf_mipi_data0:gpio_rf_mipi_data0 {
+		gpios = <&gpio15 7 0>;
+	};
+	gpio_flash_mask:gpio_flash_mask {
+		gpios = <&gpio16 0 0>;
+	};
+	gpio_gps_blanking:gpio_gps_blanking {
+		gpios = <&gpio16 1 0>;
+	};
+	gpio_rf_gpio_2:gpio_rf_gpio_2 {
+		gpios = <&gpio16 2 0>;
+	};
+	gpio_rf_gpio_3:gpio_rf_gpio_3 {
+		gpios = <&gpio16 3 0>;
+	};
+	gpio_rf_gpio_4:gpio_rf_gpio_4 {
+		gpios = <&gpio16 4 0>;
+	};
+	gpio_rf_gpio_5:gpio_rf_gpio_5 {
+		gpios = <&gpio16 5 0>;
+	};
+	gpio_rf_gpio_6:gpio_rf_gpio_6 {
+		gpios = <&gpio16 6 0>;
+	};
+	gpio_rf_gpio_7:gpio_rf_gpio_7 {
+		gpios = <&gpio16 7 0>;
+	};
+	gpio_rf_gpio_8:gpio_rf_gpio_8 {
+		gpios = <&gpio17 0 0>;
+	};
+	gpio_rf_gpio_9:gpio_rf_gpio_9 {
+		gpios = <&gpio17 1 0>;
+	};
+	gpio_rf_gpio_10:gpio_rf_gpio_10 {
+		gpios = <&gpio17 2 0>;
+	};
+	gpio_rf_gpio_11:gpio_rf_gpio_11 {
+		gpios = <&gpio17 3 0>;
+	};
+	gpio_rf_gpio_12:gpio_rf_gpio_12 {
+		gpios = <&gpio17 4 0>;
+	};
+	gpio_rf_gpio_13:gpio_rf_gpio_13 {
+		gpios = <&gpio17 5 0>;
+	};
+	gpio_rf_gpio_14:gpio_rf_gpio_14 {
+		gpios = <&gpio17 6 0>;
+	};
+	gpio_rf_gpio_15:gpio_rf_gpio_15 {
+		gpios = <&gpio17 7 0>;
+	};
+	gpio_rf_gpio_16:gpio_rf_gpio_16 {
+		gpios = <&gpio18 0 0>;
+	};
+	gpio_rf_gpio_17:gpio_rf_gpio_17 {
+		gpios = <&gpio18 1 0>;
+	};
+	gpio_rf_gpio_18:gpio_rf_gpio_18 {
+		gpios = <&gpio18 2 0>;
+	};
+	gpio_rf_gpio_19:gpio_rf_gpio_19 {
+		gpios = <&gpio18 3 0>;
+	};
+	gpio_rf_gpio_20:gpio_rf_gpio_20 {
+		gpios = <&gpio18 4 0>;
+	};
+	gpio_rf_gpio_21:gpio_rf_gpio_21 {
+		gpios = <&gpio18 5 0>;
+	};
+	gpio_rf_gpio_22:gpio_rf_gpio_22 {
+		gpios = <&gpio18 6 0>;
+	};
+	gpio_rf_gpio_23:gpio_rf_gpio_23 {
+		gpios = <&gpio18 7 0>;
+	};
+	gpio_rf_gpio_24:gpio_rf_gpio_24 {
+		gpios = <&gpio19 0 0>;
+	};
+	gpio_rf_gpio_25:gpio_rf_gpio_25 {
+		gpios = <&gpio19 1 0>;
+	};
+	gpio_rf_gpio_26:gpio_rf_gpio_26 {
+		gpios = <&gpio19 2 0>;
+	};
+	gpio_rf_ssi1:gpio_rf_ssi1 {
+		gpios = <&gpio19 3 0>;
+	};
+	gpio_rf_tcvr_on1:gpio_rf_tcvr_on1 {
+		gpios = <&gpio19 4 0>;
+	};
+	gpio_rf_gpio_29:gpio_rf_gpio_29 {
+		gpios = <&gpio19 5 0>;
+	};
+	gpio_rf_gpio_30:gpio_rf_gpio_30 {
+		gpios = <&gpio19 6 0>;
+	};
+	gpio_apt_pdm0:gpio_apt_pdm0 {
+		gpios = <&gpio19 7 0>;
+	};
+};
-- 
1.9.1



From guodong.xu at linaro.org  Fri Feb 19 03:58:26 2016
From: guodong.xu at linaro.org (Guodong Xu)
Date: Fri, 19 Feb 2016 19:58:26 +0800
Subject: [PATCH V5 2/3] arm64: dts: add Hi6220 pinctrl configuration nodes
In-Reply-To: <1455883107-8411-1-git-send-email-guodong.xu@linaro.org>
References: <1455883107-8411-1-git-send-email-guodong.xu@linaro.org>
Message-ID: <1455883107-8411-3-git-send-email-guodong.xu@linaro.org>

From: Zhong Kaihua <zhongkaihua at huawei.com>

Add Hi6220 pinctrl configuration nodes

Signed-off-by: Zhong Kaihua <zhongkaihua at huawei.com>
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts   |   1 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi        |  77 +++
 arch/arm64/boot/dts/hisilicon/hikey-pinctrl.dtsi | 684 +++++++++++++++++++++++
 include/dt-bindings/pinctrl/hisi.h               |  59 ++
 4 files changed, 821 insertions(+)
 create mode 100644 arch/arm64/boot/dts/hisilicon/hikey-pinctrl.dtsi
 create mode 100644 include/dt-bindings/pinctrl/hisi.h

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index f9b2d1e..985a2ad 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -9,6 +9,7 @@
 
 #include "hi6220.dtsi"
 #include "hikey-gpio.dtsi"
+#include "hikey-pinctrl.dtsi"
 
 / {
 	model = "HiKey Development Board";
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index ad7074d..e96cc3c 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -6,6 +6,7 @@
 
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/hi6220-clock.h>
+#include <dt-bindings/pinctrl/hisi.h>
 
 / {
 	compatible = "hisilicon,hi6220";
@@ -250,6 +251,60 @@
 			clock-names = "apb_pclk";
 		};
 
+		pmx0: pinmux at f7010000 {
+			compatible = "pinctrl-single";
+			reg = <0x0 0xf7010000  0x0 0x27c>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			#gpio-range-cells = <3>;
+			pinctrl-single,register-width = <32>;
+			pinctrl-single,function-mask = <7>;
+			pinctrl-single,gpio-range = <
+				&range  80  8 MUX_M0 /* gpio  3: [0..7] */
+				&range  88  8 MUX_M0 /* gpio  4: [0..7] */
+				&range  96  8 MUX_M0 /* gpio  5: [0..7] */
+				&range 104  8 MUX_M0 /* gpio  6: [0..7] */
+				&range 112  8 MUX_M0 /* gpio  7: [0..7] */
+				&range 120  2 MUX_M0 /* gpio  8: [0..1] */
+				&range   2  6 MUX_M1 /* gpio  8: [2..7] */
+				&range   8  8 MUX_M1 /* gpio  9: [0..7] */
+				&range   0  1 MUX_M1 /* gpio 10: [0]    */
+				&range  16  7 MUX_M1 /* gpio 10: [1..7] */
+				&range  23  3 MUX_M1 /* gpio 11: [0..2] */
+				&range  28  5 MUX_M1 /* gpio 11: [3..7] */
+				&range  33  3 MUX_M1 /* gpio 12: [0..2] */
+				&range  43  5 MUX_M1 /* gpio 12: [3..7] */
+				&range  48  8 MUX_M1 /* gpio 13: [0..7] */
+				&range  56  8 MUX_M1 /* gpio 14: [0..7] */
+				&range  74  6 MUX_M1 /* gpio 15: [0..5] */
+				&range 122  1 MUX_M1 /* gpio 15: [6]    */
+				&range 126  1 MUX_M1 /* gpio 15: [7]    */
+				&range 127  8 MUX_M1 /* gpio 16: [0..7] */
+				&range 135  8 MUX_M1 /* gpio 17: [0..7] */
+				&range 143  8 MUX_M1 /* gpio 18: [0..7] */
+				&range 151  8 MUX_M1 /* gpio 19: [0..7] */
+			>;
+			range: gpio-range {
+				#pinctrl-single,gpio-range-cells = <3>;
+			};
+		};
+
+		pmx1: pinmux at f7010800 {
+			compatible = "pinconf-single";
+			reg = <0x0 0xf7010800 0x0 0x28c>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			pinctrl-single,register-width = <32>;
+		};
+
+		pmx2: pinmux at f8001800 {
+			compatible = "pinconf-single";
+			reg = <0x0 0xf8001800 0x0 0x78>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			pinctrl-single,register-width = <32>;
+		};
+
 		gpio0: gpio at f8011000 {
 			compatible = "arm,pl061", "arm,primecell";
 			reg = <0x0 0xf8011000 0x0 0x1000>;
@@ -295,6 +350,7 @@
 			interrupts = <0 55 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 80 8>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -308,6 +364,7 @@
 			interrupts = <0 56 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 88 8>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -321,6 +378,7 @@
 			interrupts = <0 57 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 96 8>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -334,6 +392,7 @@
 			interrupts = <0 58 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 104 8>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -347,6 +406,7 @@
 			interrupts = <0 59 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 112 8>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -360,6 +420,7 @@
 			interrupts = <0 60 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 120 2 &pmx0 2 2 6>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -373,6 +434,7 @@
 			interrupts = <0 61 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 8 8>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -386,6 +448,7 @@
 			interrupts = <0 62 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 0 1 &pmx0 1 16 7>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -399,6 +462,7 @@
 			interrupts = <0 63 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 23 3 &pmx0 3 28 5>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -412,6 +476,7 @@
 			interrupts = <0 64 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 33 3 &pmx0 3 43 5>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -424,6 +489,8 @@
 			reg = <0x0 0xf7029000 0x0 0x1000>;
 			interrupts = <0 65 0x4>;
 			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 48 8>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -437,6 +504,7 @@
 			interrupts = <0 66 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 56 8>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -450,6 +518,11 @@
 			interrupts = <0 67 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <
+				&pmx0 0 74 6
+				&pmx0 6 122 1
+				&pmx0 7 126 1
+			>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -463,6 +536,7 @@
 			interrupts = <0 68 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 127 8>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -476,6 +550,7 @@
 			interrupts = <0 69 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 135 8>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -489,6 +564,7 @@
 			interrupts = <0 70 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 143 8>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
@@ -502,6 +578,7 @@
 			interrupts = <0 71 0x4>;
 			gpio-controller;
 			#gpio-cells = <2>;
+			gpio-ranges = <&pmx0 0 151 8>;
 			interrupt-controller;
 			#interrupt-cells = <2>;
 			clocks = <&ao_ctrl 2>;
diff --git a/arch/arm64/boot/dts/hisilicon/hikey-pinctrl.dtsi b/arch/arm64/boot/dts/hisilicon/hikey-pinctrl.dtsi
new file mode 100644
index 0000000..28806df
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hikey-pinctrl.dtsi
@@ -0,0 +1,684 @@
+/*
+ * pinctrl dts fils for Hislicon HiKey development board
+ *
+ */
+#include <dt-bindings/pinctrl/hisi.h>
+
+/ {
+	soc {
+		pmx0: pinmux at f7010000 {
+			pinctrl-names = "default";
+			pinctrl-0 = <
+				&boot_sel_pmx_func
+				&hkadc_ssi_pmx_func
+				&codec_clk_pmx_func
+				&pwm_in_pmx_func
+				&bl_pwm_pmx_func
+				>;
+
+			boot_sel_pmx_func: boot_sel_pmx_func {
+				pinctrl-single,pins = <
+					0x0    MUX_M0	/* BOOT_SEL     (IOMG000) */
+				>;
+			};
+
+			emmc_pmx_func: emmc_pmx_func {
+				pinctrl-single,pins = <
+					0x100  MUX_M0	/* EMMC_CLK     (IOMG064) */
+					0x104  MUX_M0	/* EMMC_CMD     (IOMG065) */
+					0x108  MUX_M0	/* EMMC_DATA0   (IOMG066) */
+					0x10c  MUX_M0	/* EMMC_DATA1   (IOMG067) */
+					0x110  MUX_M0	/* EMMC_DATA2   (IOMG068) */
+					0x114  MUX_M0	/* EMMC_DATA3   (IOMG069) */
+					0x118  MUX_M0	/* EMMC_DATA4   (IOMG070) */
+					0x11c  MUX_M0	/* EMMC_DATA5   (IOMG071) */
+					0x120  MUX_M0	/* EMMC_DATA6   (IOMG072) */
+					0x124  MUX_M0	/* EMMC_DATA7   (IOMG073) */
+				>;
+			};
+
+			sd_pmx_func: sd_pmx_func {
+				pinctrl-single,pins = <
+					0xc    MUX_M0	/* SD_CLK       (IOMG003) */
+					0x10   MUX_M0	/* SD_CMD       (IOMG004) */
+					0x14   MUX_M0	/* SD_DATA0     (IOMG005) */
+					0x18   MUX_M0	/* SD_DATA1     (IOMG006) */
+					0x1c   MUX_M0	/* SD_DATA2     (IOMG007) */
+					0x20   MUX_M0	/* SD_DATA3     (IOMG008) */
+				>;
+			};
+			sd_pmx_idle: sd_pmx_idle {
+				pinctrl-single,pins = <
+					0xc    MUX_M1	/* SD_CLK       (IOMG003) */
+					0x10   MUX_M1	/* SD_CMD       (IOMG004) */
+					0x14   MUX_M1	/* SD_DATA0     (IOMG005) */
+					0x18   MUX_M1	/* SD_DATA1     (IOMG006) */
+					0x1c   MUX_M1	/* SD_DATA2     (IOMG007) */
+					0x20   MUX_M1	/* SD_DATA3     (IOMG008) */
+				>;
+			};
+
+			sdio_pmx_func: sdio_pmx_func {
+				pinctrl-single,pins = <
+					0x128  MUX_M0	/* SDIO_CLK     (IOMG074) */
+					0x12c  MUX_M0	/* SDIO_CMD     (IOMG075) */
+					0x130  MUX_M0	/* SDIO_DATA0   (IOMG076) */
+					0x134  MUX_M0	/* SDIO_DATA1   (IOMG077) */
+					0x138  MUX_M0	/* SDIO_DATA2   (IOMG078) */
+					0x13c  MUX_M0	/* SDIO_DATA3   (IOMG079) */
+				>;
+			};
+			sdio_pmx_idle: sdio_pmx_idle {
+				pinctrl-single,pins = <
+					0x128  MUX_M1	/* SDIO_CLK     (IOMG074) */
+					0x12c  MUX_M1	/* SDIO_CMD     (IOMG075) */
+					0x130  MUX_M1	/* SDIO_DATA0   (IOMG076) */
+					0x134  MUX_M1	/* SDIO_DATA1   (IOMG077) */
+					0x138  MUX_M1	/* SDIO_DATA2   (IOMG078) */
+					0x13c  MUX_M1	/* SDIO_DATA3   (IOMG079) */
+				>;
+			};
+
+			isp_pmx_func: isp_pmx_func {
+				pinctrl-single,pins = <
+					0x24   MUX_M0	/* ISP_PWDN0    (IOMG009) */
+					0x28   MUX_M0	/* ISP_PWDN1    (IOMG010) */
+					0x2c   MUX_M0	/* ISP_PWDN2    (IOMG011) */
+					0x30   MUX_M1	/* ISP_SHUTTER0 (IOMG012) */
+					0x34   MUX_M1	/* ISP_SHUTTER1 (IOMG013) */
+					0x38   MUX_M1	/* ISP_PWM      (IOMG014) */
+					0x3c   MUX_M0	/* ISP_CCLK0    (IOMG015) */
+					0x40   MUX_M0	/* ISP_CCLK1    (IOMG016) */
+					0x44   MUX_M0	/* ISP_RESETB0  (IOMG017) */
+					0x48   MUX_M0	/* ISP_RESETB1  (IOMG018) */
+					0x4c   MUX_M1	/* ISP_STROBE0  (IOMG019) */
+					0x50   MUX_M1	/* ISP_STROBE1  (IOMG020) */
+					0x54   MUX_M0	/* ISP_SDA0     (IOMG021) */
+					0x58   MUX_M0	/* ISP_SCL0     (IOMG022) */
+					0x5c   MUX_M0	/* ISP_SDA1     (IOMG023) */
+					0x60   MUX_M0	/* ISP_SCL1     (IOMG024) */
+				>;
+			};
+
+			hkadc_ssi_pmx_func: hkadc_ssi_pmx_func {
+				pinctrl-single,pins = <
+					0x68   MUX_M0	/* HKADC_SSI    (IOMG026) */
+				>;
+			};
+
+			codec_clk_pmx_func: codec_clk_pmx_func {
+				pinctrl-single,pins = <
+					0x6c   MUX_M0	/* CODEC_CLK    (IOMG027) */
+				>;
+			};
+
+			codec_pmx_func: codec_pmx_func {
+				pinctrl-single,pins = <
+					0x70   MUX_M1	/* DMIC_CLK     (IOMG028) */
+					0x74   MUX_M0	/* CODEC_SYNC   (IOMG029) */
+					0x78   MUX_M0	/* CODEC_DI     (IOMG030) */
+					0x7c   MUX_M0	/* CODEC_DO     (IOMG031) */
+				>;
+			};
+
+			fm_pmx_func: fm_pmx_func {
+				pinctrl-single,pins = <
+					0x80   MUX_M1	/* FM_XCLK      (IOMG032) */
+					0x84   MUX_M1	/* FM_XFS       (IOMG033) */
+					0x88   MUX_M1	/* FM_DI        (IOMG034) */
+					0x8c   MUX_M1	/* FM_DO        (IOMG035) */
+				>;
+			};
+
+			bt_pmx_func: bt_pmx_func {
+				pinctrl-single,pins = <
+					0x90   MUX_M0	/* BT_XCLK      (IOMG036) */
+					0x94   MUX_M0	/* BT_XFS       (IOMG037) */
+					0x98   MUX_M0	/* BT_DI        (IOMG038) */
+					0x9c   MUX_M0	/* BT_DO        (IOMG039) */
+				>;
+			};
+
+			pwm_in_pmx_func: pwm_in_pmx_func {
+				pinctrl-single,pins = <
+					0xb8   MUX_M1	/* PWM_IN       (IOMG046) */
+				>;
+			};
+
+			bl_pwm_pmx_func: bl_pwm_pmx_func {
+				pinctrl-single,pins = <
+					0xbc   MUX_M1	/* BL_PWM       (IOMG047) */
+				>;
+			};
+
+			uart0_pmx_func: uart0_pmx_func {
+				pinctrl-single,pins = <
+					0xc0   MUX_M0	/* UART0_RXD    (IOMG048) */
+					0xc4   MUX_M0	/* UART0_TXD    (IOMG049) */
+				>;
+			};
+
+			uart1_pmx_func: uart1_pmx_func {
+				pinctrl-single,pins = <
+					0xc8   MUX_M0	/* UART1_CTS_N  (IOMG050) */
+					0xcc   MUX_M0	/* UART1_RTS_N  (IOMG051) */
+					0xd0   MUX_M0	/* UART1_RXD    (IOMG052) */
+					0xd4   MUX_M0	/* UART1_TXD    (IOMG053) */
+				>;
+			};
+
+			uart2_pmx_func: uart2_pmx_func {
+				pinctrl-single,pins = <
+					0xd8   MUX_M0	/* UART2_CTS_N  (IOMG054) */
+					0xdc   MUX_M0	/* UART2_RTS_N  (IOMG055) */
+					0xe0   MUX_M0	/* UART2_RXD    (IOMG056) */
+					0xe4   MUX_M0	/* UART2_TXD    (IOMG057) */
+				>;
+			};
+
+			uart3_pmx_func: uart3_pmx_func {
+				pinctrl-single,pins = <
+					0x180  MUX_M1	/* UART3_CTS_N  (IOMG096) */
+					0x184  MUX_M1	/* UART3_RTS_N  (IOMG097) */
+					0x188  MUX_M1	/* UART3_RXD    (IOMG098) */
+					0x18c  MUX_M1	/* UART3_TXD    (IOMG099) */
+				>;
+			};
+
+			uart4_pmx_func: uart4_pmx_func {
+				pinctrl-single,pins = <
+					0x1d0  MUX_M1	/* UART4_CTS_N  (IOMG116) */
+					0x1d4  MUX_M1	/* UART4_RTS_N  (IOMG117) */
+					0x1d8  MUX_M1	/* UART4_RXD    (IOMG118) */
+					0x1dc  MUX_M1	/* UART4_TXD    (IOMG119) */
+				>;
+			};
+
+			uart5_pmx_func: uart5_pmx_func {
+				pinctrl-single,pins = <
+					0x1c8  MUX_M1	/* UART5_RXD    (IOMG114) */
+					0x1cc  MUX_M1	/* UART5_TXD    (IOMG115) */
+				>;
+			};
+
+			i2c0_pmx_func: i2c0_pmx_func {
+				pinctrl-single,pins = <
+					0xe8   MUX_M0	/* I2C0_SCL     (IOMG058) */
+					0xec   MUX_M0	/* I2C0_SDA     (IOMG059) */
+				>;
+			};
+
+			i2c1_pmx_func: i2c1_pmx_func {
+				pinctrl-single,pins = <
+					0xf0   MUX_M0	/* I2C1_SCL     (IOMG060) */
+					0xf4   MUX_M0	/* I2C1_SDA     (IOMG061) */
+				>;
+			};
+
+			i2c2_pmx_func: i2c2_pmx_func {
+				pinctrl-single,pins = <
+					0xf8   MUX_M0	/* I2C2_SCL     (IOMG062) */
+					0xfc   MUX_M0	/* I2C2_SDA     (IOMG063) */
+				>;
+			};
+		};
+
+		pmx1: pinmux at f7010800 {
+
+			pinctrl-names = "default";
+			pinctrl-0 = <
+				&boot_sel_cfg_func
+				&hkadc_ssi_cfg_func
+				&codec_clk_cfg_func
+				&pwm_in_cfg_func
+				&bl_pwm_cfg_func
+				>;
+
+			boot_sel_cfg_func: boot_sel_cfg_func {
+				pinctrl-single,pins = <
+					0x0    0x0	/* BOOT_SEL     (IOCFG000) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_UP   PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			hkadc_ssi_cfg_func: hkadc_ssi_cfg_func {
+				pinctrl-single,pins = <
+					0x6c   0x0	/* HKADC_SSI    (IOCFG027) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			emmc_clk_cfg_func: emmc_clk_cfg_func {
+				pinctrl-single,pins = <
+					0x104  0x0	/* EMMC_CLK     (IOCFG065) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_08MA DRIVE_MASK>;
+			};
+
+			emmc_cfg_func: emmc_cfg_func {
+				pinctrl-single,pins = <
+					0x108  0x0	/* EMMC_CMD     (IOCFG066) */
+					0x10c  0x0	/* EMMC_DATA0   (IOCFG067) */
+					0x110  0x0	/* EMMC_DATA1   (IOCFG068) */
+					0x114  0x0	/* EMMC_DATA2   (IOCFG069) */
+					0x118  0x0	/* EMMC_DATA3   (IOCFG070) */
+					0x11c  0x0	/* EMMC_DATA4   (IOCFG071) */
+					0x120  0x0	/* EMMC_DATA5   (IOCFG072) */
+					0x124  0x0	/* EMMC_DATA6   (IOCFG073) */
+					0x128  0x0	/* EMMC_DATA7   (IOCFG074) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_UP   PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_04MA DRIVE_MASK>;
+			};
+
+			emmc_rst_cfg_func: emmc_rst_cfg_func {
+				pinctrl-single,pins = <
+					0x12c  0x0	/* EMMC_RST_N   (IOCFG075) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_04MA DRIVE_MASK>;
+			};
+
+			sd_clk_cfg_func: sd_clk_cfg_func {
+				pinctrl-single,pins = <
+					0xc    0x0	/* SD_CLK       (IOCFG003) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_10MA DRIVE_MASK>;
+			};
+			sd_clk_cfg_idle: sd_clk_cfg_idle {
+				pinctrl-single,pins = <
+					0xc    0x0	/* SD_CLK       (IOCFG003) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DOWN PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			sd_cfg_func: sd_cfg_func {
+				pinctrl-single,pins = <
+					0x10   0x0	/* SD_CMD       (IOCFG004) */
+					0x14   0x0	/* SD_DATA0     (IOCFG005) */
+					0x18   0x0	/* SD_DATA1     (IOCFG006) */
+					0x1c   0x0	/* SD_DATA2     (IOCFG007) */
+					0x20   0x0	/* SD_DATA3     (IOCFG008) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_08MA DRIVE_MASK>;
+			};
+			sd_cfg_idle: sd_cfg_idle {
+				pinctrl-single,pins = <
+					0x10   0x0	/* SD_CMD       (IOCFG004) */
+					0x14   0x0	/* SD_DATA0     (IOCFG005) */
+					0x18   0x0	/* SD_DATA1     (IOCFG006) */
+					0x1c   0x0	/* SD_DATA2     (IOCFG007) */
+					0x20   0x0	/* SD_DATA3     (IOCFG008) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DOWN PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			sdio_clk_cfg_func: sdio_clk_cfg_func {
+				pinctrl-single,pins = <
+					0x134  0x0	/* SDIO_CLK     (IOCFG077) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_08MA DRIVE_MASK>;
+			};
+			sdio_clk_cfg_idle: sdio_clk_cfg_idle {
+				pinctrl-single,pins = <
+					0x134  0x0	/* SDIO_CLK     (IOCFG077) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DOWN PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			sdio_cfg_func: sdio_cfg_func {
+				pinctrl-single,pins = <
+					0x138  0x0	/* SDIO_CMD     (IOCFG078) */
+					0x13c  0x0	/* SDIO_DATA0   (IOCFG079) */
+					0x140  0x0	/* SDIO_DATA1   (IOCFG080) */
+					0x144  0x0	/* SDIO_DATA2   (IOCFG081) */
+					0x148  0x0	/* SDIO_DATA3   (IOCFG082) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_UP   PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_04MA DRIVE_MASK>;
+			};
+			sdio_cfg_idle: sdio_cfg_idle {
+				pinctrl-single,pins = <
+					0x138  0x0	/* SDIO_CMD     (IOCFG078) */
+					0x13c  0x0	/* SDIO_DATA0   (IOCFG079) */
+					0x140  0x0	/* SDIO_DATA1   (IOCFG080) */
+					0x144  0x0	/* SDIO_DATA2   (IOCFG081) */
+					0x148  0x0	/* SDIO_DATA3   (IOCFG082) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_UP   PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			isp_cfg_func1: isp_cfg_func1 {
+				pinctrl-single,pins = <
+					0x28   0x0	/* ISP_PWDN0    (IOCFG010) */
+					0x2c   0x0	/* ISP_PWDN1    (IOCFG011) */
+					0x30   0x0	/* ISP_PWDN2    (IOCFG012) */
+					0x34   0x0	/* ISP_SHUTTER0 (IOCFG013) */
+					0x38   0x0	/* ISP_SHUTTER1 (IOCFG014) */
+					0x3c   0x0	/* ISP_PWM      (IOCFG015) */
+					0x40   0x0	/* ISP_CCLK0    (IOCFG016) */
+					0x44   0x0	/* ISP_CCLK1    (IOCFG017) */
+					0x48   0x0	/* ISP_RESETB0  (IOCFG018) */
+					0x4c   0x0	/* ISP_RESETB1  (IOCFG019) */
+					0x50   0x0	/* ISP_STROBE0  (IOCFG020) */
+					0x58   0x0	/* ISP_SDA0     (IOCFG022) */
+					0x5c   0x0	/* ISP_SCL0     (IOCFG023) */
+					0x60   0x0	/* ISP_SDA1     (IOCFG024) */
+					0x64   0x0	/* ISP_SCL1     (IOCFG025) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+			isp_cfg_idle1: isp_cfg_idle1 {
+				pinctrl-single,pins = <
+					0x34   0x0	/* ISP_SHUTTER0 (IOCFG013) */
+					0x38   0x0	/* ISP_SHUTTER1 (IOCFG014) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DOWN PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			isp_cfg_func2: isp_cfg_func2 {
+				pinctrl-single,pins = <
+					0x54   0x0	/* ISP_STROBE1  (IOCFG021) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DOWN PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			codec_clk_cfg_func: codec_clk_cfg_func {
+				pinctrl-single,pins = <
+					0x70   0x0	/* CODEC_CLK    (IOCFG028) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_04MA DRIVE_MASK>;
+			};
+			codec_clk_cfg_idle: codec_clk_cfg_idle {
+				pinctrl-single,pins = <
+					0x70   0x0	/* CODEC_CLK    (IOCFG028) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			codec_cfg_func1: codec_cfg_func1 {
+				pinctrl-single,pins = <
+					0x74   0x0	/* DMIC_CLK     (IOCFG029) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DOWN PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			codec_cfg_func2: codec_cfg_func2 {
+				pinctrl-single,pins = <
+					0x78   0x0	/* CODEC_SYNC   (IOCFG030) */
+					0x7c   0x0	/* CODEC_DI     (IOCFG031) */
+					0x80   0x0	/* CODEC_DO     (IOCFG032) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_04MA DRIVE_MASK>;
+			};
+			codec_cfg_idle2: codec_cfg_idle2 {
+				pinctrl-single,pins = <
+					0x78   0x0	/* CODEC_SYNC   (IOCFG030) */
+					0x7c   0x0	/* CODEC_DI     (IOCFG031) */
+					0x80   0x0	/* CODEC_DO     (IOCFG032) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			fm_cfg_func: fm_cfg_func {
+				pinctrl-single,pins = <
+					0x84   0x0	/* FM_XCLK      (IOCFG033) */
+					0x88   0x0	/* FM_XFS       (IOCFG034) */
+					0x8c   0x0	/* FM_DI        (IOCFG035) */
+					0x90   0x0	/* FM_DO        (IOCFG036) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DOWN PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			bt_cfg_func: bt_cfg_func {
+				pinctrl-single,pins = <
+					0x94   0x0	/* BT_XCLK      (IOCFG037) */
+					0x98   0x0	/* BT_XFS       (IOCFG038) */
+					0x9c   0x0	/* BT_DI        (IOCFG039) */
+					0xa0   0x0	/* BT_DO        (IOCFG040) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+			bt_cfg_idle: bt_cfg_idle {
+				pinctrl-single,pins = <
+					0x94   0x0	/* BT_XCLK      (IOCFG037) */
+					0x98   0x0	/* BT_XFS       (IOCFG038) */
+					0x9c   0x0	/* BT_DI        (IOCFG039) */
+					0xa0   0x0	/* BT_DO        (IOCFG040) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DOWN PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			pwm_in_cfg_func: pwm_in_cfg_func {
+				pinctrl-single,pins = <
+					0xbc   0x0	/* PWM_IN       (IOCFG047) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DOWN PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			bl_pwm_cfg_func: bl_pwm_cfg_func {
+				pinctrl-single,pins = <
+					0xc0   0x0	/* BL_PWM       (IOCFG048) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DOWN PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			uart0_cfg_func1: uart0_cfg_func1 {
+				pinctrl-single,pins = <
+					0xc4   0x0	/* UART0_RXD    (IOCFG049) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_UP   PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			uart0_cfg_func2: uart0_cfg_func2 {
+				pinctrl-single,pins = <
+					0xc8   0x0	/* UART0_TXD    (IOCFG050) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_04MA DRIVE_MASK>;
+			};
+
+			uart1_cfg_func1: uart1_cfg_func1 {
+				pinctrl-single,pins = <
+					0xcc   0x0	/* UART1_CTS_N  (IOCFG051) */
+					0xd4   0x0	/* UART1_RXD    (IOCFG053) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_UP   PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			uart1_cfg_func2: uart1_cfg_func2 {
+				pinctrl-single,pins = <
+					0xd0   0x0	/* UART1_RTS_N  (IOCFG052) */
+					0xd8   0x0	/* UART1_TXD    (IOCFG054) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			uart2_cfg_func: uart2_cfg_func {
+				pinctrl-single,pins = <
+					0xdc   0x0	/* UART2_CTS_N  (IOCFG055) */
+					0xe0   0x0	/* UART2_RTS_N  (IOCFG056) */
+					0xe4   0x0	/* UART2_RXD    (IOCFG057) */
+					0xe8   0x0	/* UART2_TXD    (IOCFG058) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			uart3_cfg_func: uart3_cfg_func {
+				pinctrl-single,pins = <
+					0x190  0x0	/* UART3_CTS_N  (IOCFG100) */
+					0x194  0x0	/* UART3_RTS_N  (IOCFG101) */
+					0x198  0x0	/* UART3_RXD    (IOCFG102) */
+					0x19c  0x0	/* UART3_TXD    (IOCFG103) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DOWN PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			uart4_cfg_func: uart4_cfg_func {
+				pinctrl-single,pins = <
+					0x1e0  0x0	/* UART4_CTS_N  (IOCFG120) */
+					0x1e4  0x0	/* UART4_RTS_N  (IOCFG121) */
+					0x1e8  0x0	/* UART4_RXD    (IOCFG122) */
+					0x1ec  0x0	/* UART4_TXD    (IOCFG123) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DOWN PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			uart5_cfg_func: uart5_cfg_func {
+				pinctrl-single,pins = <
+					0x1d8  0x0	/* UART4_RXD    (IOCFG118) */
+					0x1dc  0x0	/* UART4_TXD    (IOCFG119) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DOWN PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			i2c0_cfg_func: i2c0_cfg_func {
+				pinctrl-single,pins = <
+					0xec   0x0	/* I2C0_SCL     (IOCFG059) */
+					0xf0   0x0	/* I2C0_SDA     (IOCFG060) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			i2c1_cfg_func: i2c1_cfg_func {
+				pinctrl-single,pins = <
+					0xf4   0x0	/* I2C1_SCL     (IOCFG061) */
+					0xf8   0x0	/* I2C1_SDA     (IOCFG062) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			i2c2_cfg_func: i2c2_cfg_func {
+				pinctrl-single,pins = <
+					0xfc   0x0	/* I2C2_SCL     (IOCFG063) */
+					0x100  0x0	/* I2C2_SDA     (IOCFG064) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+		};
+
+		pmx2: pinmux at f8001800 {
+
+			pinctrl-names = "default";
+			pinctrl-0 = <
+				&rstout_n_cfg_func
+				>;
+
+			rstout_n_cfg_func: rstout_n_cfg_func {
+				pinctrl-single,pins = <
+					0x0    0x0	/* RSTOUT_N     (IOCFG000) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			pmu_peri_en_cfg_func: pmu_peri_en_cfg_func {
+				pinctrl-single,pins = <
+					0x4    0x0	/* PMU_PERI_EN  (IOCFG001) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			sysclk0_en_cfg_func: sysclk0_en_cfg_func {
+				pinctrl-single,pins = <
+					0x8    0x0	/* SYSCLK0_EN   (IOCFG002) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+
+			jtag_tdo_cfg_func: jtag_tdo_cfg_func {
+				pinctrl-single,pins = <
+					0xc    0x0	/* JTAG_TDO     (IOCFG003) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_08MA DRIVE_MASK>;
+			};
+
+			rf_reset_cfg_func: rf_reset_cfg_func {
+				pinctrl-single,pins = <
+					0x70   0x0	/* RF_RESET0    (IOCFG028) */
+					0x74   0x0	/* RF_RESET1    (IOCFG029) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS  PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
+		};
+	};
+};
diff --git a/include/dt-bindings/pinctrl/hisi.h b/include/dt-bindings/pinctrl/hisi.h
new file mode 100644
index 0000000..38f1ea8
--- /dev/null
+++ b/include/dt-bindings/pinctrl/hisi.h
@@ -0,0 +1,59 @@
+/*
+ * This header provides constants for hisilicon pinctrl bindings.
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ * Copyright (c) 2015 Linaro Limited.
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_PINCTRL_HISI_H
+#define _DT_BINDINGS_PINCTRL_HISI_H
+
+/* iomg bit definition */
+#define MUX_M0		0
+#define MUX_M1		1
+#define MUX_M2		2
+#define MUX_M3		3
+#define MUX_M4		4
+#define MUX_M5		5
+#define MUX_M6		6
+#define MUX_M7		7
+
+/* iocg bit definition */
+#define PULL_MASK	(3)
+#define PULL_DIS	(0)
+#define PULL_UP		(1 << 0)
+#define PULL_DOWN	(1 << 1)
+
+/* drive strength definition */
+#define DRIVE_MASK	(7 << 4)
+#define DRIVE1_02MA	(0 << 4)
+#define DRIVE1_04MA	(1 << 4)
+#define DRIVE1_08MA	(2 << 4)
+#define DRIVE1_10MA	(3 << 4)
+#define DRIVE2_02MA	(0 << 4)
+#define DRIVE2_04MA	(1 << 4)
+#define DRIVE2_08MA	(2 << 4)
+#define DRIVE2_10MA	(3 << 4)
+#define DRIVE3_04MA	(0 << 4)
+#define DRIVE3_08MA	(1 << 4)
+#define DRIVE3_12MA	(2 << 4)
+#define DRIVE3_16MA	(3 << 4)
+#define DRIVE3_20MA	(4 << 4)
+#define DRIVE3_24MA	(5 << 4)
+#define DRIVE3_32MA	(6 << 4)
+#define DRIVE3_40MA	(7 << 4)
+#define DRIVE4_02MA	(0 << 4)
+#define DRIVE4_04MA	(2 << 4)
+#define DRIVE4_08MA	(4 << 4)
+#define DRIVE4_10MA	(6 << 4)
+
+#endif
-- 
1.9.1



From guodong.xu at linaro.org  Fri Feb 19 03:58:27 2016
From: guodong.xu at linaro.org (Guodong Xu)
Date: Fri, 19 Feb 2016 19:58:27 +0800
Subject: [PATCH V5 3/3] arm64: dts: add Hi6220 spi configuration nodes
In-Reply-To: <1455883107-8411-1-git-send-email-guodong.xu@linaro.org>
References: <1455883107-8411-1-git-send-email-guodong.xu@linaro.org>
Message-ID: <1455883107-8411-4-git-send-email-guodong.xu@linaro.org>

From: Zhong Kaihua <zhongkaihua at huawei.com>

Add Hi6220 spi configuration nodes

Signed-off-by: Zhong Kaihua <zhongkaihua at huawei.com>
Signed-off-by: Wei Xu <xuwei5 at hisilicon.com>
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts   |  1 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi        | 15 +++++++++++++++
 arch/arm64/boot/dts/hisilicon/hikey-pinctrl.dtsi | 21 +++++++++++++++++++++
 3 files changed, 37 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 985a2ad..5c9ee31 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -20,6 +20,7 @@
 		serial1 = &uart1; /* BT UART */
 		serial2 = &uart2; /* LS Expansion UART0 */
 		serial3 = &uart3; /* LS Expansion UART1 */
+		spi0 = &spi_0;
 	};
 
 	chosen {
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index e96cc3c..dcca83b 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -585,5 +585,20 @@
 			clock-names = "apb_pclk";
 			status = "ok";
 		};
+
+		spi_0: spi at f7106000 {
+			compatible = "arm,pl022", "arm,primecell";
+			reg = <0x0 0xf7106000 0x0 0x1000>;
+			interrupts = <0 50 4>;
+			bus-id = <0>;
+			enable-dma = <0>;
+			clocks = <&sys_ctrl HI6220_SPI_CLK>;
+			clock-names = "apb_pclk";
+			pinctrl-names = "default";
+			pinctrl-0 = <&spi0_pmx_func &spi0_cfg_func>;
+			num-cs = <1>;
+			cs-gpios = <&gpio6 2 0>;
+			status = "ok";
+		};
 	};
 };
diff --git a/arch/arm64/boot/dts/hisilicon/hikey-pinctrl.dtsi b/arch/arm64/boot/dts/hisilicon/hikey-pinctrl.dtsi
index 28806df..0916e84 100644
--- a/arch/arm64/boot/dts/hisilicon/hikey-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hikey-pinctrl.dtsi
@@ -221,6 +221,15 @@
 					0xfc   MUX_M0	/* I2C2_SDA     (IOMG063) */
 				>;
 			};
+
+			spi0_pmx_func: spi0_pmx_func {
+				pinctrl-single,pins = <
+					0x1a0  MUX_M1   /* SPI0_DI      (IOMG104) */
+					0x1a4  MUX_M1	/* SPI0_DO	(IOMG105) */
+					0x1a8  MUX_M1	/* SPI0_CS_N	(IOMG106) */
+					0x1ac  MUX_M1	/* SPI0_CLK	(IOMG107) */
+				>;
+			};
 		};
 
 		pmx1: pinmux at f7010800 {
@@ -625,6 +634,18 @@
 				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS  PULL_UP>;
 				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
 			};
+
+			spi0_cfg_func: spi0_cfg_func {
+				pinctrl-single,pins = <
+					0x1b0  0x0	/* SPI0_DI	(IOCFG108) */
+					0x1b4  0x0	/* SPI0_DO	(IOCFG109) */
+					0x1b8  0x0	/* SPI0_CS_N	(IOCFG110) */
+					0x1bc  0x0	/* SPI0_CLK	(IOCFG111) */
+				>;
+				pinctrl-single,bias-pulldown  = <PULL_DIS  PULL_DOWN PULL_DIS PULL_DOWN>;
+				pinctrl-single,bias-pullup    = <PULL_DIS  PULL_UP   PULL_DIS PULL_UP>;
+				pinctrl-single,drive-strength = <DRIVE1_02MA DRIVE_MASK>;
+			};
 		};
 
 		pmx2: pinmux at f8001800 {
-- 
1.9.1



From zhizhou.zh at gmail.com  Fri Feb 19 04:01:27 2016
From: zhizhou.zh at gmail.com (Zhizhou Zhang)
Date: Fri, 19 Feb 2016 20:01:27 +0800
Subject: [PATCH] arm64: add architecture specified current_pt_regs
In-Reply-To: <20160219103205.GD27062@arm.com>
References: <1455796115-7844-1-git-send-email-zhizhou.zh@gmail.com>
 <20160218115824.GA2538@e104818-lin.cambridge.arm.com>
 <CAN1e=SF4iAVZzvs=+rJxmUX_z7KNSwegxWaor3gDfXD-=MAQ4Q@mail.gmail.com>
 <20160219103205.GD27062@arm.com>
Message-ID: <CAN1e=SERqTUU_mLwyOQFonz2sVT1xUQAxUs7WOqCNWe_GxCj4w@mail.gmail.com>

On Fri, Feb 19, 2016 at 6:32 PM, Will Deacon <will.deacon at arm.com> wrote:
> On Fri, Feb 19, 2016 at 10:30:09AM +0800, Zhi-zhou wrote:
>> On Thu, Feb 18, 2016 at 7:58 PM, Catalin Marinas
>> <catalin.marinas at arm.com> wrote:
>> >
>> > On Thu, Feb 18, 2016 at 07:48:35PM +0800, Zhi-zhou Zhang wrote:
>> > > From: zhizhou <zhizhou.zh at gmail.com>
>> > >
>> > > This patch is based on the implementation of arm. The generic
>> > > current_pt_regs is implemented with current->stack. It need to access
>> > > memory that would be too expensive.
>> >
>> > Do you have any performance numbers?
>>
>> I'm using QEMU, so no. Actually this macro isn't heavily used. I just
>> think using the generic
>> implementation is not very nice. It get task_struct from sp_el0, then
>> get stack(which is
>> equal to sp_el0) from task_struct. There are two unnecessary memory accesses.
>
> I'd much rather use the generic implementation unless there's a compelling
> reason not to. "I think it's not very nice" doesn't really cut it for me!
Refer to memory twice may incur cache eviction. I'm really a newbie to
kernel. Anyway, I have a look at kernel and I'm very curious what's
the 'compelling reason' of 16 architectures implement their own
current_pt_regs?
>
> Will



-- 
Regards,
Zhizhou


From linus.walleij at linaro.org  Fri Feb 19 04:12:29 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 19 Feb 2016 13:12:29 +0100
Subject: [PATCH V2 1/2] pinctrl: mediatek: Modify pinctrl bindings for
 mt7623
In-Reply-To: <56C6DF23.3060202@openwrt.org>
References: <1455866238-6102-1-git-send-email-blogic@openwrt.org>
 <CACRpkdYiQop2qDNuh4N2YZy2DTy9mOEyERro8hT4YogCPc2LGw@mail.gmail.com>
 <56C6DF23.3060202@openwrt.org>
Message-ID: <CACRpkdbWad9iZV9LYkvEFRZn_BQDtPEAy3JE0uuR569UwMJkHQ@mail.gmail.com>

On Fri, Feb 19, 2016 at 10:23 AM, John Crispin <blogic at openwrt.org> wrote:
> On 19/02/2016 10:03, Linus Walleij wrote:
>> On Fri, Feb 19, 2016 at 8:17 AM, John Crispin <blogic at openwrt.org> wrote:
>>
>>> Signed-off-by: John Crispin <blogic at openwrt.org>
>>> Cc: devicetree at vger.kernel.org
>>> ---
>>> please apply to the devel-mt2701 branch
>>>
>>> Changes in V2
>>> * make mt7623-pinfunc.h part of patch 1/2
>>> * make sure the list stays sorted
>>
>> Patch applied unless the Mediatek maintainers come with serious
>> remarks (I can always revert).
>>
>> Only minor comments from Yingjoe on the previous version so I guess
>> it is finished.
>>
>> MTK guys: do you even have this SoC? It appears MTK is churning out
>> a plethora of SoCs and then they land in the lap of the OpenWRT
>> developers before the MTK maintainers even start to look at it...
>>
>> Yours,
>> Linus Walleij
>>
>
> I am doing this work in close collaboration with MTK. It is contractual
> work. MTK is huge and has many BUs, one of them is WCN, formerly known
> as Ralink. I have supported their MIPS silicon for many years now so
> asking me to also take care of the Wireless SoCs based on ARM was the
> natural next step.

Awesome!

Keep doing what you're doing :)

Yours,
Linus Walleij


From arnd at arndb.de  Fri Feb 19 04:54:59 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 13:54:59 +0100
Subject: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
In-Reply-To: <CAD8Lp47LGUc3-MFpU+3iNjXJL0i4nLTY_49NUxFXeZ2SokDuaQ@mail.gmail.com>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <CAOQ7t2aqZj3STFsdTSQZMTK5U+8Oem8oFroxHKWkt=AeP+Zczg@mail.gmail.com>
 <CAD8Lp47LGUc3-MFpU+3iNjXJL0i4nLTY_49NUxFXeZ2SokDuaQ@mail.gmail.com>
Message-ID: <3072897.5MMsyiojns@wuerfel>

On Thursday 18 February 2016 15:27:06 Daniel Drake wrote:
> 
> Having a cbus bus node with child devices does sound like it would
> reflect this particular view of the hardware design. How would we then
> represent the hwrev registers under that?
> 

The question is still how the CBUS is structured internally.

https://github.com/endlessm/linux-meson/blob/master/arch/arm/mach-meson8b/include/mach/register.h

seems to have a good list of registers, but it's a bit hard to
read, so I reformatted it slightly and put it up at http://pastebin.com/GrzYM7Ti

In many cases, the register name prefix gives a good idea of what things
are. In particular, it seems that all registers numbers are between 0x1000
and 0x2fff, which would be offsets 0x4000 through 0xbfff.

The revisison register is in a block called ASSIST, which is mixed with two
AC3 (audio?) regions, and the only other ASSIST register that is ever
used is the ASSIST_POR_CONFIG.

The METAL_REVISION is in the middle of some apparently all unrelated registers:

#define PREG_ETH_REG0 0x2050
#define PREG_ETH_REG1 0x2051
#define PROD_TEST_REG1 0x2067
#define PROD_TEST_REG0 0x2068
#define METAL_REVISION 0x206a
#define ADC_TOP_MISC 0x206b
#define DPLL_TOP_MISC 0x206c
#define ANALOG_TOP_MISC 0x206d
#define AM_ANALOG_TOP_REG0 0x206e
#define AM_ANALOG_TOP_REG1 0x206f
#define PREG_STICKY_REG0 0x207c
#define PREG_STICKY_REG1 0x207d

This still really sounds like a mixed bag to me, which should better get represented
as a syscon node, except that there are also some more structured areas in
CBUS.

Having just the registers between METAL_REVISION and HW_REV in a syscon
is clearly wrong, as that would include the pinctrl area that already has
a driver, but would not include some other parts that want the syscon.

Maybe the best way is to make it compatible with both syscon and
simple-bus and put the other nodes underneath. That is still rather
ugly, but at least it works and can be extended.

	Arnd


From ynorov at caviumnetworks.com  Fri Feb 19 04:59:59 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Fri, 19 Feb 2016 15:59:59 +0300
Subject: [RFC5 PATCH v6 00/21] ILP32 for ARM64
In-Reply-To: <208897488.c0hkBy2G1S@wuerfel>
References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com>
 <56AC38F1.2030608@huawei.com> <20160218223506.GA7816@yury-N73SV>
 <208897488.c0hkBy2G1S@wuerfel>
Message-ID: <20160219125959.GA8675@yury-N73SV>

On Fri, Feb 19, 2016 at 09:23:35AM +0100, Arnd Bergmann wrote:
> On Friday 19 February 2016 01:35:06 Yury Norov wrote:
> > 
> > Hi Bamvor, everybody,
> > 
> > I have new glibc that follows new ABI:
> > https://github.com/norov/glibc/tree/new-api
> 
> Ah, very good!
> 
> > It's very draft and dirty, but you can try it with RFC5.
> > My fail list for ltplite looks like this:
> > pipeio_4                       FAIL       11   
> > abort01                        FAIL       2    
> > clone02                        FAIL       4    
> > kill10                         FAIL       2    
> > kill11                         FAIL       2    
> > lstat01A                       FAIL       1    
> > lstat02                        FAIL       1    
> > mmap16                         FAIL       6    
> > nanosleep03                    FAIL       1    
> > nftw01                         FAIL       1    
> > nftw6401                       FAIL       1    
> > open12                         FAIL       2    
> > pathconf01                     FAIL       1    
> > pipe07                         FAIL       2    
> > profil01                       FAIL       11   
> > readdir01                      FAIL       1    
> > readlink01A                    FAIL       1    
> > rename11                       FAIL       2    
> > rmdir02                        FAIL       2    
> > sigaltstack01                  FAIL       1    
> > sigaltstack02                  FAIL       1    
> > stat03                         FAIL       1    
> > stat04                         FAIL       1    
> > stat06                         FAIL       1    
> > umount2_01                     FAIL       2    
> > umount2_02                     FAIL       2    
> > umount2_03                     FAIL       2    
> > utime06                        FAIL       2    
> > writev01                       FAIL       1    
> > mtest06                        FAIL       11   
> > rwtest01                       FAIL       2    
> > rwtest02                       FAIL       2    
> > rwtest03                       FAIL       2    
> > rwtest04                       FAIL       2    
> > rwtest05                       FAIL       2
> 
> I have no idea whether this is good news or bad news ;-)
> 
> In https://github.com/norov/glibc/commit/351b8728fdb365bd4852ac113601ddf38153fdfc
> I see that you are passing __IPC_64, I thought we had already resolved
> that in the kernel. We might need to go back to this.
> 

I'm still on 4.4 kernel. So I need it. I'll drop __IPC_64 if unneeded on
rebase. Usually I rebase on rc5 or rc6.

> In https://github.com/norov/glibc/commit/5d4290435e428267171ece871539b76e1d079d11
> you are defining a struct __kernel_stat64 in the glibc. Is this the expected
> way to do it? I would have thought you'd get the definition from the kernel
> headers.
>  
> 	Arnd
> 

Almost all ports define its own struct kernel_stat / kernel_stat64.
in "kernel_header.h" See mips, spark, alpha, i386... Some also define
function xstat_conv or similar. With all that defined, it's expected
that one of generic xstat wrappers will work properly. I tried all,
and noone got working, so I wrote this hack to make it work somehow. 


> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From marc.zyngier at arm.com  Fri Feb 19 05:08:51 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Feb 2016 13:08:51 +0000
Subject: [PULL] GICv3 changes for 4.5-rc5
Message-ID: <1455887331-29492-1-git-send-email-marc.zyngier@arm.com>

Hi Thomas,

Please find below a pull request for three GICv3 fixes that I've
collected over the past week. Hopefully, this will be the last batch
for 4.5.

Thanks,

	M.

The following changes since commit 1a1ebd5fb1e203ee8cc73508cc7a38ac4b804596:

  irqchip/gic-v3: Make sure read from ICC_IAR1_EL1 is visible on redestributor (2016-02-11 10:20:02 +0000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git tags/gic-fixes-4.5-rc5

for you to fetch changes up to 8f318526a292c5e7cebb82f3f766b83c22343293:

  irqchip/gic-v3: Add missing barrier to 32bit version of gic_read_iar() (2016-02-18 19:15:45 +0000)

----------------------------------------------------------------
GIC fixes for 4.5-rc5:

- EOI handling for LPIs when GICv3 is in EOImode==1
- Another fallout from changing page size while allocating ITS tables
- Missing memory barrier in the 32bit GICv3 code

----------------------------------------------------------------
Ashok Kumar (1):
      irqchip/gic-v3-its: Fix double ICC_EOIR write for LPI in EOImode==1

Marc Zyngier (1):
      irqchip/gic-v3: Add missing barrier to 32bit version of gic_read_iar()

Shanker Donthineni (1):
      irqchip/gicv3-its: Avoid cache flush beyond ITS_BASERn memory size

 arch/arm/include/asm/arch_gicv3.h |  1 +
 drivers/irqchip/irq-gic-v3-its.c  | 18 +++++++-----------
 2 files changed, 8 insertions(+), 11 deletions(-)


From gregory.clement at free-electrons.com  Fri Feb 19 05:12:13 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Fri, 19 Feb 2016 14:12:13 +0100
Subject: [PATCH v2 0/6] arm64: Initial support for Marvell Armada 7K/8K
In-Reply-To: <1455812430-4656-1-git-send-email-thomas.petazzoni@free-electrons.com>
 (Thomas Petazzoni's message of "Thu, 18 Feb 2016 17:20:24 +0100")
References: <1455812430-4656-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <87h9h4q1xu.fsf@free-electrons.com>

Hi Thomas,
 
 On jeu., f?vr. 18 2016, Thomas Petazzoni <thomas.petazzoni at free-electrons.com> wrote:

> Hello,
>
> This series adds initial support for the new Armada 7K and 8K Marvell
> 64 bits processors. Details about those processors based on the
> Cortex-A72 can be found at:
>
>   http://www.marvell.com/embedded-processors/armada-70xx/
>   http://www.marvell.com/embedded-processors/armada-80xx/
>
> One characteristic of those processors is that internally they are
> built from several components:
>
>  - One "AP", which contains the processor itself and a few core IP
>    blocks. The AP in 7K and 8K is called AP806, and is available on
>    two variants: dual Cortex-A72 and quad Cortex-A72.
>
>  - Or or two "CP", which contains most of the I/Os (SATA, PCIe,
>    etc.). The CP in 7K and 8K is called CP110. One CP110 is available
>    in the 7K family, while two CP110 are available in the 8K family,
>    doubling the number of I/O interfaces.
>
> The support added in this series only brings minimal support for the
> AP side (and not yet all IP blocks, obviously). Support for the CP
> part will come in the future.
>
> Since the series touches similar files as the Armada 3700 series from
> Gregory Clement, it is based on it (its 4th version).
>
> Changes since v1:
>
>  - Add initial patch from Arnd which updates the Marvell README, and
>    did a few adjustements to it.
>
>  - Use arm,gic-400 as the compatible string identifying the GIC, as
>    suggested by Jisheng.
>
>  - Rework the patch series on top of Gregory's latest patch series for
>    Armada 3700, since the patch series interact a little bit on a few
>    aspects (usage of the ARCH_MVEBU Kconfig option, for example).
>
>  - Fix the size of the register areas used for the GIC to be in line
>    with the datasheet. Follows some questions from Marc Zyngier.
>
> Best regards,
>
> Thomas
>
> Arnd Bergmann (1):
>   Documentation: arm: update Marvell product listing
>
> Thomas Petazzoni (5):
>   Documentation: arm: improve Armada 37xx description
>   Documentation: arm: add link to Armada 38x Functional Spec
>   Documentation: arm: add Marvell Armada 7K and 8K families
>   arm64: update ARCH_MVEBU for Marvell Armada 7K/8K support
>   arm64: marvell: add Device Tree files for Armada 7K/8K

I applied the 5 first patches to mvebu/arm64 and the last one to
mvebu/dt64.

Thanks,

Gregory

>
>  Documentation/arm/Marvell/README                   | 158 +++++++++++---
>  .../bindings/arm/marvell/armada-7k-8k.txt          |  24 +++
>  arch/arm64/Kconfig.platforms                       |  11 +-
>  arch/arm64/boot/dts/marvell/Makefile               |   1 +
>  arch/arm64/boot/dts/marvell/armada-7020.dtsi       |  54 +++++
>  arch/arm64/boot/dts/marvell/armada-7040-db.dts     |  92 ++++++++
>  arch/arm64/boot/dts/marvell/armada-7040.dtsi       |  54 +++++
>  arch/arm64/boot/dts/marvell/armada-8020.dtsi       |  54 +++++
>  arch/arm64/boot/dts/marvell/armada-8040.dtsi       |  54 +++++
>  arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi |  71 +++++++
>  arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi |  84 ++++++++
>  arch/arm64/boot/dts/marvell/armada-ap806.dtsi      | 234 +++++++++++++++++++++
>  12 files changed, 858 insertions(+), 33 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-7020.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-7040-db.dts
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-7040.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-8020.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-8040.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
>  create mode 100644 arch/arm64/boot/dts/marvell/armada-ap806.dtsi
>
> -- 
> 2.6.4
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From ludovic.desroches at atmel.com  Fri Feb 19 05:19:45 2016
From: ludovic.desroches at atmel.com (Ludovic Desroches)
Date: Fri, 19 Feb 2016 14:19:45 +0100
Subject: [PATCH] ARM: dts: at91: sama5d2 Xplained: Correct the macb irq
 pinctrl node
In-Reply-To: <1455790866-13301-1-git-send-email-romain.izard.pro@gmail.com>
References: <1455790866-13301-1-git-send-email-romain.izard.pro@gmail.com>
Message-ID: <20160219131945.GX2607@odux.rfo.atmel.com>

On Thu, Feb 18, 2016 at 11:21:06AM +0100, Romain Izard wrote:
> All pinctrl nodes for the Atmel pinctrl controller need to have their
> bias configuration explicitly defined. Otherwise, the pinctrl mapping
> is not valid.
> 
> It works for now as the pinctrl driver proceeds even with invalid
> mappings, but this can become an issue, if the pinctrl driver starts
> to require valid mappings. Additionally, the pin is not protected from
> being remapped later by an other driver.
> 
> There is an external 1k? pull-up to 3.3V, so no bias is required on
> the Ethernet PHY's interrupt line.
> 
> Signed-off-by: Romain Izard <romain.izard.pro at gmail.com>

Acked-by: Ludovic Desroches <ludovic.desroches at atmel.com>

Thanks

> ---
>  arch/arm/boot/dts/at91-sama5d2_xplained.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> index e683856c507c..75341eec2dfd 100644
> --- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> +++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
> @@ -308,6 +308,7 @@
>  
>  				pinctrl_macb0_phy_irq: macb0_phy_irq {
>  					pinmux = <PIN_PC9__GPIO>;
> +					bias-disable;
>  				};
>  
>  				pinctrl_pdmic_default: pdmic_default {
> -- 
> 2.5.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From carlo at endlessm.com  Fri Feb 19 05:25:20 2016
From: carlo at endlessm.com (Carlo Caione)
Date: Fri, 19 Feb 2016 14:25:20 +0100
Subject: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
In-Reply-To: <3072897.5MMsyiojns@wuerfel>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <CAOQ7t2aqZj3STFsdTSQZMTK5U+8Oem8oFroxHKWkt=AeP+Zczg@mail.gmail.com>
 <CAD8Lp47LGUc3-MFpU+3iNjXJL0i4nLTY_49NUxFXeZ2SokDuaQ@mail.gmail.com>
 <3072897.5MMsyiojns@wuerfel>
Message-ID: <CAL9uMOG2gnGnxv9RmmKuHjc72xyyyEu3AW6pTyM2oA=aM171eQ@mail.gmail.com>

On Fri, Feb 19, 2016 at 1:54 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 18 February 2016 15:27:06 Daniel Drake wrote:
>>
>> Having a cbus bus node with child devices does sound like it would
>> reflect this particular view of the hardware design. How would we then
>> represent the hwrev registers under that?
>>
>
> The question is still how the CBUS is structured internally.
>
> https://github.com/endlessm/linux-meson/blob/master/arch/arm/mach-meson8b/include/mach/register.h
>
> seems to have a good list of registers, but it's a bit hard to
> read, so I reformatted it slightly and put it up at http://pastebin.com/GrzYM7Ti
>
> In many cases, the register name prefix gives a good idea of what things
> are. In particular, it seems that all registers numbers are between 0x1000
> and 0x2fff, which would be offsets 0x4000 through 0xbfff.
>
> The revisison register is in a block called ASSIST, which is mixed with two
> AC3 (audio?) regions, and the only other ASSIST register that is ever
> used is the ASSIST_POR_CONFIG.
>
> The METAL_REVISION is in the middle of some apparently all unrelated registers:
>
> #define PREG_ETH_REG0 0x2050
> #define PREG_ETH_REG1 0x2051
> #define PROD_TEST_REG1 0x2067
> #define PROD_TEST_REG0 0x2068
> #define METAL_REVISION 0x206a
> #define ADC_TOP_MISC 0x206b
> #define DPLL_TOP_MISC 0x206c
> #define ANALOG_TOP_MISC 0x206d
> #define AM_ANALOG_TOP_REG0 0x206e
> #define AM_ANALOG_TOP_REG1 0x206f
> #define PREG_STICKY_REG0 0x207c
> #define PREG_STICKY_REG1 0x207d
>
> This still really sounds like a mixed bag to me, which should better get represented
> as a syscon node, except that there are also some more structured areas in
> CBUS.
>
> Having just the registers between METAL_REVISION and HW_REV in a syscon
> is clearly wrong, as that would include the pinctrl area that already has
> a driver, but would not include some other parts that want the syscon.

Agree

> Maybe the best way is to make it compatible with both syscon and
> simple-bus and put the other nodes underneath. That is still rather
> ugly, but at least it works and can be extended.

This is a good idea actually. I'll prepare a patch.
Thank you for having spent time on this.

Cheers,

-- 
Carlo Caione  |  +39.340.80.30.096  |  Endless


From thomas.petazzoni at free-electrons.com  Fri Feb 19 05:34:43 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 19 Feb 2016 14:34:43 +0100
Subject: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI on
 Marvell 7K/8K
Message-ID: <1455888883-5127-1-git-send-email-thomas.petazzoni@free-electrons.com>

This commits adds a new irqchip driver that handles the ODMI
controller found on Marvell 7K/8K processors. The ODMI controller
provide MSI interrupt functionality to on-board peripherals, much like
the GIC-v2m.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
Changes v2 -> v2:
 - Express NODMIS_SHIFT, NODMIS_PER_FRAME, NODMIS_MASK in term of each
   other. Suggested by Marc Zyngier.
 - Rework the global bitmask allocation to make sure we allocate a
   number of longs rather than a number of bytes, to avoid having the
   bitmap API (which operates on longs) access memory we haven't
   explicitly allocated. Reported by Marc Zyngier.

Changes v1 -> v2:
 - Better commit title, as suggested by Marc Zyngier.
 - Improve the DT binding documentation, as suggested by Marc Zingier:
   add a reference to the GIC documentation, be more specific about
   the marvell,spi-base values, and add the requirement of the
   interrupt-parent property.
 - As suggested by Marc Zyngier, use a single global bitmap to
   allocate all ODMIs, regardless of the frame they belong to. As part
   of this change, the hwirq used to identify the interrupt inside the
   ODMI irqdomain are 0-based (instead of being based on their
   corresponding SPI base value), which allows to significantly
   simplify the allocation/free logic.
---
 .../marvell,odmi-controller.txt                    |  41 ++++
 drivers/irqchip/Kconfig                            |   4 +
 drivers/irqchip/Makefile                           |   1 +
 drivers/irqchip/irq-mvebu-odmi.c                   | 248 +++++++++++++++++++++
 4 files changed, 294 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
 create mode 100644 drivers/irqchip/irq-mvebu-odmi.c

diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
new file mode 100644
index 0000000..252d5c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
@@ -0,0 +1,41 @@
+
+* Marvell ODMI for MSI support
+
+Some Marvell SoCs have an On-Die Message Interrupt (ODMI) controller
+which can be used by on-board peripheral for MSI interrupts.
+
+Required properties:
+
+- compatible           : The value here should contain "marvell,odmi-controller".
+
+- interrupt,controller : Identifies the node as an interrupt controller.
+
+- msi-controller       : Identifies the node as an MSI controller.
+
+- marvell,odmi-frames  : Number of ODMI frames available. Each frame
+                         provides a number of events.
+
+- reg                  : List of register definitions, one for each
+                         ODMI frame.
+
+- marvell,spi-base     : List of GIC base SPI interrupts, one for each
+                         ODMI frame. Those SPI interrupts are 0-based,
+                         i.e marvell,spi-base = <128> will use SPI #96.
+                         See Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
+                         for details about the GIC Device Tree binding.
+
+- interrupt-parent     : Reference to the parent interrupt controller.
+
+Example:
+
+	odmi: odmi at 300000 {
+		compatible = "marvell,odmi-controller";
+		interrupt-controller;
+		msi-controller;
+		marvell,odmi-frames = <4>;
+		reg = <0x300000 0x4000>,
+		      <0x304000 0x4000>,
+		      <0x308000 0x4000>,
+		      <0x30C000 0x4000>;
+		marvell,spi-base = <128>, <136>, <144>, <152>;
+	};
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 715923d..18bed3c 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -217,3 +217,7 @@ config IRQ_MXS
 	def_bool y if MACH_ASM9260 || ARCH_MXS
 	select IRQ_DOMAIN
 	select STMP_DEVICE
+
+config MVEBU_ODMI
+	bool
+	select GENERIC_MSI_IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 18caacb..29c388f 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -59,3 +59,4 @@ obj-$(CONFIG_ARCH_SA1100)		+= irq-sa11x0.o
 obj-$(CONFIG_INGENIC_IRQ)		+= irq-ingenic.o
 obj-$(CONFIG_IMX_GPCV2)			+= irq-imx-gpcv2.o
 obj-$(CONFIG_PIC32_EVIC)		+= irq-pic32-evic.o
+obj-$(CONFIG_MVEBU_ODMI)		+= irq-mvebu-odmi.o
diff --git a/drivers/irqchip/irq-mvebu-odmi.c b/drivers/irqchip/irq-mvebu-odmi.c
new file mode 100644
index 0000000..0ae98b2
--- /dev/null
+++ b/drivers/irqchip/irq-mvebu-odmi.c
@@ -0,0 +1,248 @@
+/*
+ * Copyright (C) 2016 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#define pr_fmt(fmt) "GIC-ODMI: " fmt
+
+#include <linux/irq.h>
+#include <linux/irqchip.h>
+#include <linux/irqdomain.h>
+#include <linux/kernel.h>
+#include <linux/msi.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+#define GICP_ODMIN_SET			0x40
+#define   GICP_ODMI_INT_NUM_SHIFT	12
+#define GICP_ODMIN_GM_EP_R0		0x110
+#define GICP_ODMIN_GM_EP_R1		0x114
+#define GICP_ODMIN_GM_EA_R0		0x108
+#define GICP_ODMIN_GM_EA_R1		0x118
+
+/*
+ * We don't support the group events, so we simply have 8 interrupts
+ * per frame.
+ */
+#define NODMIS_SHIFT		3
+#define NODMIS_PER_FRAME	(1 << NODMIS_SHIFT)
+#define NODMIS_MASK		(NODMIS_PER_FRAME - 1)
+
+struct odmi_data {
+	struct resource res;
+	void __iomem *base;
+	unsigned int spi_base;
+};
+
+static struct odmi_data *odmis;
+static unsigned long *odmis_bm;
+static unsigned int odmis_count;
+
+/* Protects odmis_bm */
+static DEFINE_SPINLOCK(odmis_bm_lock);
+
+static int odmi_set_affinity(struct irq_data *d,
+			     const struct cpumask *mask, bool force)
+{
+	int ret;
+
+	ret = irq_chip_set_affinity_parent(d, mask, force);
+	if (ret == IRQ_SET_MASK_OK)
+		ret = IRQ_SET_MASK_OK_DONE;
+
+	return ret;
+}
+
+static void odmi_compose_msi_msg(struct irq_data *d, struct msi_msg *msg)
+{
+	struct odmi_data *odmi;
+	phys_addr_t addr;
+	unsigned int odmin;
+
+	if (WARN_ON(d->hwirq >= odmis_count * NODMIS_PER_FRAME))
+		return;
+
+	odmi = &odmis[d->hwirq >> NODMIS_SHIFT];
+	odmin = d->hwirq & NODMIS_MASK;
+
+	addr = odmi->res.start + GICP_ODMIN_SET;
+
+	msg->address_hi = upper_32_bits(addr);
+	msg->address_lo = lower_32_bits(addr);
+	msg->data = odmin << GICP_ODMI_INT_NUM_SHIFT;
+}
+
+static struct irq_chip odmi_irq_chip = {
+	.name			= "ODMI",
+	.irq_mask		= irq_chip_mask_parent,
+	.irq_unmask		= irq_chip_unmask_parent,
+	.irq_eoi		= irq_chip_eoi_parent,
+	.irq_set_affinity	= odmi_set_affinity,
+	.irq_compose_msi_msg	= odmi_compose_msi_msg,
+};
+
+static int odmi_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+				 unsigned int nr_irqs, void *args)
+{
+	struct odmi_data *odmi = NULL;
+	struct irq_fwspec fwspec;
+	struct irq_data *d;
+	unsigned int hwirq, odmin;
+	int ret;
+
+	spin_lock(&odmis_bm_lock);
+	hwirq = find_first_zero_bit(odmis_bm, NODMIS_PER_FRAME * odmis_count);
+	if (hwirq >= NODMIS_PER_FRAME * odmis_count) {
+		spin_unlock(&odmis_bm_lock);
+		return -ENOSPC;
+	}
+
+	__set_bit(hwirq, odmis_bm);
+	spin_unlock(&odmis_bm_lock);
+
+	odmi = &odmis[hwirq >> NODMIS_SHIFT];
+	odmin = hwirq & NODMIS_MASK;
+
+	fwspec.fwnode = domain->parent->fwnode;
+	fwspec.param_count = 3;
+	fwspec.param[0] = GIC_SPI;
+	fwspec.param[1] = odmi->spi_base - 32 + odmin;
+	fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
+
+	ret = irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
+	if (ret) {
+		pr_err("Cannot allocate parent IRQ\n");
+		spin_lock(&odmis_bm_lock);
+		__clear_bit(odmin, odmis_bm);
+		spin_unlock(&odmis_bm_lock);
+		return ret;
+	}
+
+	/* Configure the interrupt line to be edge */
+	d = irq_domain_get_irq_data(domain->parent, virq);
+	d->chip->irq_set_type(d, IRQ_TYPE_EDGE_RISING);
+
+	irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
+				      &odmi_irq_chip, NULL);
+
+	return 0;
+}
+
+static void odmi_irq_domain_free(struct irq_domain *domain,
+				 unsigned int virq, unsigned int nr_irqs)
+{
+	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+
+	if (d->hwirq >= odmis_count * NODMIS_PER_FRAME) {
+		pr_err("Failed to teardown msi. Invalid hwirq %lu\n", d->hwirq);
+		return;
+	}
+
+	irq_domain_free_irqs_parent(domain, virq, nr_irqs);
+
+	/* Actually free the MSI */
+	spin_lock(&odmis_bm_lock);
+	__clear_bit(d->hwirq, odmis_bm);
+	spin_unlock(&odmis_bm_lock);
+}
+
+static const struct irq_domain_ops odmi_domain_ops = {
+	.alloc	= odmi_irq_domain_alloc,
+	.free	= odmi_irq_domain_free,
+};
+
+static struct irq_chip odmi_msi_irq_chip = {
+	.name	= "ODMI",
+};
+
+static struct msi_domain_ops odmi_msi_ops = {
+};
+
+static struct msi_domain_info odmi_msi_domain_info = {
+	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS),
+	.ops	= &odmi_msi_ops,
+	.chip	= &odmi_msi_irq_chip,
+};
+
+static int __init mvebu_odmi_init(struct device_node *node,
+				  struct device_node *parent)
+{
+	struct irq_domain *inner_domain, *plat_domain;
+	int ret, i;
+
+	if (of_property_read_u32(node, "marvell,odmi-frames", &odmis_count))
+		return -EINVAL;
+
+	odmis = kcalloc(odmis_count, sizeof(struct odmi_data), GFP_KERNEL);
+	if (!odmis)
+		return -ENOMEM;
+
+	odmis_bm = kcalloc(BITS_TO_LONGS(odmis_count * NODMIS_PER_FRAME),
+			   sizeof(long), GFP_KERNEL);
+	if (!odmis_bm) {
+		ret = -ENOMEM;
+		goto err_alloc;
+	}
+
+	for (i = 0; i < odmis_count; i++) {
+		struct odmi_data *odmi = &odmis[i];
+
+		ret = of_address_to_resource(node, i, &odmi->res);
+		if (ret)
+			goto err_unmap;
+
+		odmi->base = of_io_request_and_map(node, i, "odmi");
+		if (IS_ERR(odmi->base)) {
+			ret = PTR_ERR(odmi->base);
+			goto err_unmap;
+		}
+
+		if (of_property_read_u32_index(node, "marvell,spi-base",
+					       i, &odmi->spi_base)) {
+			ret = -EINVAL;
+			goto err_unmap;
+		}
+	}
+
+	inner_domain = irq_domain_create_linear(of_node_to_fwnode(node),
+						odmis_count * NODMIS_PER_FRAME,
+						&odmi_domain_ops, NULL);
+	if (!inner_domain) {
+		ret = -ENOMEM;
+		goto err_unmap;
+	}
+
+	inner_domain->parent = irq_find_host(parent);
+
+	plat_domain = platform_msi_create_irq_domain(of_node_to_fwnode(node),
+						     &odmi_msi_domain_info,
+						     inner_domain);
+	if (!plat_domain) {
+		ret = -ENOMEM;
+		goto err_remove_inner;
+	}
+
+	return 0;
+
+err_remove_inner:
+	irq_domain_remove(inner_domain);
+err_unmap:
+	for (i = 0; i < odmis_count; i++) {
+		struct odmi_data *odmi = &odmis[i];
+
+		if (odmi->base && !IS_ERR(odmi->base))
+			iounmap(odmis[i].base);
+	}
+	kfree(odmis_bm);
+err_alloc:
+	kfree(odmis);
+	return ret;
+}
+
+IRQCHIP_DECLARE(mvebu_odmi, "marvell,odmi-controller", mvebu_odmi_init);
-- 
2.6.4



From qnguyen at apm.com  Fri Feb 19 05:45:30 2016
From: qnguyen at apm.com (Quan Nguyen)
Date: Fri, 19 Feb 2016 20:45:30 +0700
Subject: [PATCH v7 1/3] gpio: xgene: Enable X-Gene standby GPIO as
 interrupt controller
In-Reply-To: <CACRpkdaH7CLZDK9HP1nCYioPVbypQsZ76ZJcPMPLjVzV-DWqDQ@mail.gmail.com>
References: <1455714909-3027-1-git-send-email-qnguyen@apm.com>
 <1455714909-3027-2-git-send-email-qnguyen@apm.com>
 <CACRpkdaH7CLZDK9HP1nCYioPVbypQsZ76ZJcPMPLjVzV-DWqDQ@mail.gmail.com>
Message-ID: <CAFopSPROXiFd+7cfMQi2bwMfUBAoYEH=6m8qcvTdZ9n-mjiP1w@mail.gmail.com>

Thanks Linus and Marc.

On Fri, Feb 19, 2016 at 4:11 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Wed, Feb 17, 2016 at 2:15 PM, Quan Nguyen <qnguyen at apm.com> wrote:
>
>> Enable X-Gene standby GPIO controller as interrupt controller to provide
>> its own resources. This avoids ambiguity where GIC interrupt resource is
>> use as X-Gene standby GPIO interrupt resource in user driver.
>>
>> Signed-off-by: Y Vo <yvo at apm.com>
>> Signed-off-by: Quan Nguyen <qnguyen at apm.com>
>> Acked-by: Marc Zyngier <marc.zyngier at arm.com>
>
> Sweet! Patch applied.
>
> Yours,
> Linus Walleij


From mina86 at mina86.com  Fri Feb 19 05:46:08 2016
From: mina86 at mina86.com (Michal Nazarewicz)
Date: Fri, 19 Feb 2016 14:46:08 +0100
Subject: [PATCH 1/2] mm: cma: split out in_cma check to separate function
In-Reply-To: <1455869524-13874-1-git-send-email-rabin.vincent@axis.com>
References: <1455869524-13874-1-git-send-email-rabin.vincent@axis.com>
Message-ID: <xa1tlh6gzucf.fsf@mina86.com>

On Fri, Feb 19 2016, Rabin Vincent wrote:
> Split out the logic in cma_release() which checks if the page is in the
> contiguous area to a new function which can be called separately.  ARM
> will use this.
>
> Signed-off-by: Rabin Vincent <rabin.vincent at axis.com>
> ---
>  include/linux/cma.h | 12 ++++++++++++
>  mm/cma.c            | 27 +++++++++++++++++++--------
>  2 files changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/cma.h b/include/linux/cma.h
> index 29f9e77..6e7fd2d 100644
> --- a/include/linux/cma.h
> +++ b/include/linux/cma.h
> @@ -27,5 +27,17 @@ extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
>  					unsigned int order_per_bit,
>  					struct cma **res_cma);
>  extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align);
> +
>  extern bool cma_release(struct cma *cma, const struct page *pages, unsigned int count);
> +#ifdef CONFIG_CMA
> +extern bool in_cma(struct cma *cma, const struct page *pages,
> +		   unsigned int count);
> +#else
> +static inline bool in_cma(struct cma *cma, const struct page *pages,
> +			  unsigned int count)
> +{
> +	return false;
> +}
> +#endif
> +
>  #endif
> diff --git a/mm/cma.c b/mm/cma.c
> index ea506eb..55cda16 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -426,6 +426,23 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
>  	return page;
>  }
>  
> +bool in_cma(struct cma *cma, const struct page *pages, unsigned int count)

Should it instead take pfn as an argument instead of a page?  IIRC
page_to_pfn may be expensive on some architectures and with this patch,
cma_release will call it twice.

Or maybe in_cma could return a pfn, something like (error checking
stripped):

unsigned long pfn in_cma(struct cma *cma, const struct page *page,
			 unsgined count)
{
	unsigned long pfn = page_to_pfn(page);
	if (pfn < cma->base_pfn || pfn >= cma->base_pfn + cma->count)
		return 0;
	VM_BUG_ON(pfn + count > cma->base_pfn + cma->count);
	return pfn;
}

Is pfn == 0 guaranteed to be invalid?

> +{
> +	unsigned long pfn;
> +
> +	if (!cma || !pages)
> +		return false;
> +
> +	pfn = page_to_pfn(pages);
> +
> +	if (pfn < cma->base_pfn || pfn >= cma->base_pfn + cma->count)
> +		return false;
> +
> +	VM_BUG_ON(pfn + count > cma->base_pfn + cma->count);
> +
> +	return true;
> +}
> +
>  /**
>   * cma_release() - release allocated pages
>   * @cma:   Contiguous memory region for which the allocation is performed.
> @@ -440,18 +457,12 @@ bool cma_release(struct cma *cma, const struct page *pages, unsigned int count)
>  {
>  	unsigned long pfn;
>  
> -	if (!cma || !pages)
> -		return false;
> -
>  	pr_debug("%s(page %p)\n", __func__, (void *)pages);
>  
> -	pfn = page_to_pfn(pages);
> -
> -	if (pfn < cma->base_pfn || pfn >= cma->base_pfn + cma->count)
> +	if (!in_cma(cma, pages, count))
>  		return false;
>  
> -	VM_BUG_ON(pfn + count > cma->base_pfn + cma->count);
> -
> +	pfn = page_to_pfn(pages);
>  	free_contig_range(pfn, count);
>  	cma_clear_bitmap(cma, pfn, count);
>  	trace_cma_release(pfn, pages, count);
> -- 
> 2.7.0
>

-- 
Best regards
Liege of Serenely Enlightened Majesty of Computer Science,
??? ?mina86? ??????  <mpn at google.com> <xmpp:mina86 at jabber.org>


From qnguyen at apm.com  Fri Feb 19 05:47:28 2016
From: qnguyen at apm.com (Quan Nguyen)
Date: Fri, 19 Feb 2016 20:47:28 +0700
Subject: [PATCH v7 3/3] arm64: dts: Update X-Gene standby GPIO controller
 DTS entries
In-Reply-To: <CACRpkdav6UXn41UnWvWR4zjYN=QtkNJknihr+YnHu3rXbkPBBw@mail.gmail.com>
References: <1455714909-3027-1-git-send-email-qnguyen@apm.com>
 <1455714909-3027-4-git-send-email-qnguyen@apm.com>
 <CACRpkdav6UXn41UnWvWR4zjYN=QtkNJknihr+YnHu3rXbkPBBw@mail.gmail.com>
Message-ID: <CAFopSPR133CT5t2ck2_F3Zzh8gWosLpXFpYi-5VBBhVScOkvjA@mail.gmail.com>

On Fri, Feb 19, 2016 at 4:14 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Wed, Feb 17, 2016 at 2:15 PM, Quan Nguyen <qnguyen at apm.com> wrote:
>
>> Update APM X-Gene standby GPIO controller DTS entries to enable it
>> as interrupt controller.
>>
>> Signed-off-by: Y Vo <yvo at apm.com>
>> Signed-off-by: Quan Nguyen <qnguyen at apm.com>
>
> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
>
> Please funnel this patch through the ARM SoC tree with all other
> DTS files.

Let me do it and resend.

Thanks,
-- Quan


From Chris.Brandt at renesas.com  Fri Feb 19 05:49:38 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Fri, 19 Feb 2016 13:49:38 +0000
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <3461274.sjccN4r7lq@wuerfel>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
 <20160218223312.GT19428@n2100.arm.linux.org.uk>
 <HK2PR06MB05617E2ED835CFE20F65E3D38AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
 <3461274.sjccN4r7lq@wuerfel>
Message-ID: <HK2PR06MB0561F8D4A17AAEFEBD774E478AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>


On 19 Feb 2016, Arnd Bergmann wrote:

> In a different thread today, I was trying to come up with a way to
> reliably pick a PHYS_OFFSET value, and I think it can be done but it
> quickly gets ugly without extending the Kconfig language.


OK, I see that now (no idea how you guy weed through so many reflector emails)


> Also, the same problem exists in three areas:
> 
> a) PHYS_OFFSET / DRAM_BASE
> b) XIP_PHYS_ADDR
> c) DEBUG_UART_VIRT/DEBUG_UART_PHYS
> 
> The last one is already really ugly and by nature causes problems
> whenever someone enables DEBUG_LL and tries to boot a compressed
> kernel on a platform other than the one that was configured.
> 
> XIP_PHYS_ADDR is probably the worst here, because the number does
> not just depend on the SoC family but the specific board configuration
> and could even change when you rearrange the partitions on your NOR
> flash (unless you enforce that the kernel has to start at the
> beginning of the ROM or some other fixed location).
> 
> It would be nice to handle all three of the above in a similar manner,
> and I'm definitely open to a range of solutions for this, like
> 
> - always allow turning XIP_KERNEL on for all configurations, and
>   expect the user to know what they are doing (as your current
>   patch)

This method is the quickest and easiest (from a kbuild perspective), and I was going with the assumption that the less I modify, less likely I was to break something else.


> - allow turning on XIP_KERNEL as long as Kconfig can figure out that
>   this has a chance of working on at least one platform (easy enough
>   to implement, and similar to how we handle DEBUG_LL).


In the patch I was working on, if ARCH_MULTIPLATFORM was selected (which is the problem I'm trying to solve), you can only select XIP_KERNEL if 'MULTIPLATFORM_XIP_CAPABLE' is selected. At least then we could restrict the multiplatform platforms to ones that stand a chance of XIP booting (or at least have been known to boot at one point or another)

 
> - make XIP_KERNEL and DEBUG_LL depend on either CONFIG_EXPERT or
>   a new "I know this breaks other platforms and I won't complain
>   about that" flag.

A plausible deniability clause. Funny.

 
> - implement a Kconfig method to only allow XIP_KERNEL if exactly
>   one platform is enable that supports it, or if all platforms
>   use the exact same PHYS_OFFSET and XIP_PHYS_ADDR settings.
>   Whether we want to enforce the same thing for DEBUG_LL is a
>   separate matter once that infrastructure exists.
> 
> 	Arnd

This last one would be my favorite.

It would be nice if you could turn a section of "config ARCH_xxx bool" options into "choice" single select with some magical dynamic #ifdef.

if XIP_KERNEL
choice
endif

config DEVICE_A
	bool "Device A"

config DEVICE_B
	bool "Device B"

config DEVICE_C
	bool "Device C"

if XIP_KERNEL
endchoice
endif


...but...this doesn't work:

  arch/arm/mach-shmobile/Kconfig:51: unexpected 'endif' within choice block
  arch/arm/mach-shmobile/Kconfig:131: unexpected 'endchoice' within if block


I need a:

__INLINE__ if XIP_KERNEL
choice
endif




Although...at some point I'd argue that you are trying to cater to a level of safety that is above and beyond XIP_KERNEL. There are probably multiple CONFIG options in the kernel that would break an XIP anyway.

A car with the best seat belts and airbags still won't help you if you drive it off a cliff.


Chris




From mina86 at mina86.com  Fri Feb 19 05:50:52 2016
From: mina86 at mina86.com (Michal Nazarewicz)
Date: Fri, 19 Feb 2016 14:50:52 +0100
Subject: [PATCH 2/2] ARM: dma-mapping: fix alloc/free for coherent + CMA +
 gfp=0
In-Reply-To: <1455869524-13874-2-git-send-email-rabin.vincent@axis.com>
References: <1455869524-13874-1-git-send-email-rabin.vincent@axis.com>
 <1455869524-13874-2-git-send-email-rabin.vincent@axis.com>
Message-ID: <xa1tio1kzu4j.fsf@mina86.com>

On Fri, Feb 19 2016, Rabin Vincent wrote:
> Given a device which uses arm_coherent_dma_ops and on which
> dev_get_cma_area(dev) returns non-NULL, the following usage of the DMA
> API with gfp=0 results in a memory leak and memory corruption.
>
>  p = dma_alloc_coherent(dev, sz, &dma, 0);
>  if (p)
>  	dma_free_coherent(dev, sz, p, dma);
>
> The memory leak is because the alloc allocates using
> __alloc_simple_buffer() but the free attempts
> dma_release_from_contiguous(), which does not do free anything since the
> page is not in the CMA area.
>
> The memory corruption is because the free calls __dma_remap() on a page
> which is backed by only first level page tables.  The
> apply_to_page_range() + __dma_update_pte() loop ends up interpreting the
> section mapping as the address to a second level page table and writing
> the new PTE to memory which is not used by page tables.
>
> We don't have access to the GFP flags used for allocation in the free
> function, so fix it by using the new in_cma() function to determine if a
> buffer was allocated with CMA, similar to how we check for
> __in_atomic_pool().
>
> Fixes: 21caf3a7 ("ARM: 8398/1: arm DMA: Fix allocation from CMA for coherent DMA")
> Signed-off-by: Rabin Vincent <rabin.vincent at axis.com>
> ---
>  arch/arm/mm/dma-mapping.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 0eca381..a4592c7 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -749,16 +749,16 @@ static void __arm_dma_free(struct device *dev, size_t size, void *cpu_addr,
>  		__dma_free_buffer(page, size);
>  	} else if (!is_coherent && __free_from_pool(cpu_addr, size)) {
>  		return;
> -	} else if (!dev_get_cma_area(dev)) {
> -		if (want_vaddr && !is_coherent)
> -			__dma_free_remap(cpu_addr, size);
> -		__dma_free_buffer(page, size);
> -	} else {
> +	} else if (in_cma(dev_get_cma_area(dev), page, size >> PAGE_SHIFT)) {
>  		/*
>  		 * Non-atomic allocations cannot be freed with IRQs disabled
>  		 */
>  		WARN_ON(irqs_disabled());
>  		__free_from_contiguous(dev, page, cpu_addr, size, want_vaddr);
> +	} else {
> +		if (want_vaddr && !is_coherent)
> +			__dma_free_remap(cpu_addr, size);
> +		__dma_free_buffer(page, size);
>  	}
>  }

I haven?t looked closely at the code, but why not:

	struct cma *cma = 
        if (!cma_release(dev_get_cma_area(dev), page, size >> PAGE_SHIFT)) {
		// ... do whatever other non-CMA free
	}

-- 
Best regards
Liege of Serenely Enlightened Majesty of Computer Science,
??? ?mina86? ??????  <mpn at google.com> <xmpp:mina86 at jabber.org>


From marc.zyngier at arm.com  Fri Feb 19 06:04:32 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Feb 2016 14:04:32 +0000
Subject: [PATCH 5/8] arm64: kprobes instruction simulation support
In-Reply-To: <1455839301-26464-6-git-send-email-dave.long@linaro.org>
References: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
 <1455839301-26464-6-git-send-email-dave.long@linaro.org>
Message-ID: <56C720F0.9080108@arm.com>

Hi David,

On 18/02/16 23:48, David Long wrote:
> From: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>
> 
> Kprobes needs simulation of instructions that cannot be stepped
> from different memory location, e.g.: those instructions
> that uses PC-relative addressing. In simulation, the behaviour
> of the instruction is implemented using a copy of pt_regs.
> 
> Following instruction catagories are simulated:
>  - All branching instructions(conditional, register, and immediate)
>  - Literal access instructions(load-literal, adr/adrp)
> 
> Conditional execution is limited to branching instructions in
> ARM v8. If conditions at PSTATE do not match the condition fields
> of opcode, the instruction is effectively NOP. Kprobes considers
> this case as 'miss'.
> 
> This code also replaces the use of arch/arm/opcodes.c for
> arm_check_condition().
> 
> Thanks to Will Cohen for assorted suggested changes.
> 
> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>
> Signed-off-by: William Cohen <wcohen at redhat.com>
> Signed-off-by: David A. Long <dave.long at linaro.org>
> ---
>  arch/arm64/include/asm/insn.h            |   3 +
>  arch/arm64/include/asm/probes.h          |   5 +-
>  arch/arm64/kernel/Makefile               |   6 +-
>  arch/arm64/kernel/insn.c                 | 111 ++++++++++++++++++
>  arch/arm64/kernel/kprobes-arm64.c        |  29 +++++
>  arch/arm64/kernel/kprobes.c              |  32 +++++-
>  arch/arm64/kernel/probes-simulate-insn.c | 187 +++++++++++++++++++++++++++++++
>  arch/arm64/kernel/probes-simulate-insn.h |  30 +++++
>  8 files changed, 395 insertions(+), 8 deletions(-)
>  create mode 100644 arch/arm64/kernel/probes-simulate-insn.c
>  create mode 100644 arch/arm64/kernel/probes-simulate-insn.h
> 
> diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
> index cf43773..2cac976 100644
> --- a/arch/arm64/include/asm/insn.h
> +++ b/arch/arm64/include/asm/insn.h
> @@ -407,6 +407,9 @@ u32 aarch64_insn_extract_system_reg(u32 insn);
>  u32 aarch32_insn_extract_reg_num(u32 insn, int offset);
>  u32 aarch32_insn_mcr_extract_opc2(u32 insn);
>  u32 aarch32_insn_mcr_extract_crm(u32 insn);
> +
> +typedef unsigned long (pstate_check_t)(unsigned long);
> +
>  #endif /* __ASSEMBLY__ */
>  
>  #endif	/* __ASM_INSN_H */
> diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
> index c5fcbe6..d524f7d 100644
> --- a/arch/arm64/include/asm/probes.h
> +++ b/arch/arm64/include/asm/probes.h
> @@ -15,11 +15,12 @@
>  #ifndef _ARM_PROBES_H
>  #define _ARM_PROBES_H
>  
> +#include <asm/opcodes.h>
> +
>  struct kprobe;
>  struct arch_specific_insn;
>  
>  typedef u32 kprobe_opcode_t;
> -typedef unsigned long (kprobes_pstate_check_t)(unsigned long);
>  typedef void (kprobes_handler_t) (u32 opcode, long addr, struct pt_regs *);
>  
>  enum pc_restore_type {
> @@ -35,7 +36,7 @@ struct kprobe_pc_restore {
>  /* architecture specific copy of original instruction */
>  struct arch_specific_insn {
>  	kprobe_opcode_t *insn;
> -	kprobes_pstate_check_t *pstate_cc;
> +	pstate_check_t *pstate_cc;
>  	kprobes_handler_t *handler;
>  	/* restore address after step xol */
>  	struct kprobe_pc_restore restore;
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index 5b0ee7d..08325e5 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -26,8 +26,7 @@ $(obj)/%.stub.o: $(obj)/%.o FORCE
>  	$(call if_changed,objcopy)
>  
>  arm64-obj-$(CONFIG_COMPAT)		+= sys32.o kuser32.o signal32.o 	\
> -					   sys_compat.o entry32.o		\
> -					   ../../arm/kernel/opcodes.o
> +					   sys_compat.o entry32.o
>  arm64-obj-$(CONFIG_FUNCTION_TRACER)	+= ftrace.o entry-ftrace.o
>  arm64-obj-$(CONFIG_MODULES)		+= arm64ksyms.o module.o
>  arm64-obj-$(CONFIG_PERF_EVENTS)		+= perf_regs.o perf_callchain.o
> @@ -37,7 +36,8 @@ arm64-obj-$(CONFIG_CPU_PM)		+= sleep.o suspend.o
>  arm64-obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
>  arm64-obj-$(CONFIG_JUMP_LABEL)		+= jump_label.o
>  arm64-obj-$(CONFIG_KGDB)		+= kgdb.o
> -arm64-obj-$(CONFIG_KPROBES)		+= kprobes.o kprobes-arm64.o
> +arm64-obj-$(CONFIG_KPROBES)		+= kprobes.o kprobes-arm64.o		\
> +					   probes-simulate-insn.o
>  arm64-obj-$(CONFIG_EFI)			+= efi.o efi-entry.stub.o
>  arm64-obj-$(CONFIG_PCI)			+= pci.o
>  arm64-obj-$(CONFIG_ARMV8_DEPRECATED)	+= armv8_deprecated.o
> diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
> index 60c1c71..74a08db 100644
> --- a/arch/arm64/kernel/insn.c
> +++ b/arch/arm64/kernel/insn.c
> @@ -30,6 +30,7 @@
>  #include <asm/cacheflush.h>
>  #include <asm/debug-monitors.h>
>  #include <asm/fixmap.h>
> +#include <asm/opcodes.h>
>  #include <asm/insn.h>
>  
>  #define AARCH64_INSN_SF_BIT	BIT(31)
> @@ -1234,3 +1235,113 @@ u32 aarch32_insn_mcr_extract_crm(u32 insn)
>  {
>  	return insn & CRM_MASK;
>  }
> +
> +#define	ARM_OPCODE_CONDITION_UNCOND	0xf
> +
> +static unsigned long __kprobes __check_eq(unsigned long pstate)
> +{
> +	return pstate & PSR_Z_BIT;
> +}
> +
> +static unsigned long __kprobes __check_ne(unsigned long pstate)
> +{
> +	return (~pstate) & PSR_Z_BIT;
> +}
> +
> +static unsigned long __kprobes __check_cs(unsigned long pstate)
> +{
> +	return pstate & PSR_C_BIT;
> +}
> +
> +static unsigned long __kprobes __check_cc(unsigned long pstate)
> +{
> +	return (~pstate) & PSR_C_BIT;
> +}
> +
> +static unsigned long __kprobes __check_mi(unsigned long pstate)
> +{
> +	return pstate & PSR_N_BIT;
> +}
> +
> +static unsigned long __kprobes __check_pl(unsigned long pstate)
> +{
> +	return (~pstate) & PSR_N_BIT;
> +}
> +
> +static unsigned long __kprobes __check_vs(unsigned long pstate)
> +{
> +	return pstate & PSR_V_BIT;
> +}
> +
> +static unsigned long __kprobes __check_vc(unsigned long pstate)
> +{
> +	return (~pstate) & PSR_V_BIT;
> +}
> +
> +static unsigned long __kprobes __check_hi(unsigned long pstate)
> +{
> +	pstate &= ~(pstate >> 1);	/* PSR_C_BIT &= ~PSR_Z_BIT */
> +	return pstate & PSR_C_BIT;
> +}
> +
> +static unsigned long __kprobes __check_ls(unsigned long pstate)
> +{
> +	pstate &= ~(pstate >> 1);	/* PSR_C_BIT &= ~PSR_Z_BIT */
> +	return (~pstate) & PSR_C_BIT;
> +}
> +
> +static unsigned long __kprobes __check_ge(unsigned long pstate)
> +{
> +	pstate ^= (pstate << 3);	/* PSR_N_BIT ^= PSR_V_BIT */
> +	return (~pstate) & PSR_N_BIT;
> +}
> +
> +static unsigned long __kprobes __check_lt(unsigned long pstate)
> +{
> +	pstate ^= (pstate << 3);	/* PSR_N_BIT ^= PSR_V_BIT */
> +	return pstate & PSR_N_BIT;
> +}
> +
> +static unsigned long __kprobes __check_gt(unsigned long pstate)
> +{
> +	/*PSR_N_BIT ^= PSR_V_BIT */
> +	unsigned long temp = pstate ^ (pstate << 3);
> +
> +	temp |= (pstate << 1);	/*PSR_N_BIT |= PSR_Z_BIT */
> +	return (~temp) & PSR_N_BIT;
> +}
> +
> +static unsigned long __kprobes __check_le(unsigned long pstate)
> +{
> +	/*PSR_N_BIT ^= PSR_V_BIT */
> +	unsigned long temp = pstate ^ (pstate << 3);
> +
> +	temp |= (pstate << 1);	/*PSR_N_BIT |= PSR_Z_BIT */
> +	return temp & PSR_N_BIT;
> +}
> +
> +static unsigned long __kprobes __check_al(unsigned long pstate)
> +{
> +	return true;
> +}

This is rather inconsistent. Either you're returning always returning a
boolean, or returning a long that has a meaningful bit position in it.
I'd vote for the first case, and the conversion of all __check_* functions.

> +
> +pstate_check_t * const opcode_condition_checks[16] = {
> +	&__check_eq, &__check_ne, &__check_cs, &__check_cc,
> +	&__check_mi, &__check_pl, &__check_vs, &__check_vc,
> +	&__check_hi, &__check_ls, &__check_ge, &__check_lt,
> +	&__check_gt, &__check_le, &__check_al, &__check_al

You can probably loose the '&'.

> +};
> +
> +asmlinkage unsigned int __kprobes arm_check_condition(u32 opcode, u32 psr)

Why asmlinkage? This function is never called from assembly code on arm64.

> +{
> +	u32 cc_bits  = opcode >> 28;
> +
> +	if (cc_bits != ARM_OPCODE_CONDITION_UNCOND) {
> +		if ((*opcode_condition_checks[cc_bits])(psr))
> +			return ARM_OPCODE_CONDTEST_PASS;
> +		else
> +			return ARM_OPCODE_CONDTEST_FAIL;
> +	}
> +	return ARM_OPCODE_CONDTEST_UNCOND;
> +}
> +EXPORT_SYMBOL_GPL(arm_check_condition);

Why do we need this to be exported at all? Also, it'd be better located
together with the deprecated instruction handling, possibly in a
separate patch (nothing uses this function in this patch).

> diff --git a/arch/arm64/kernel/kprobes-arm64.c b/arch/arm64/kernel/kprobes-arm64.c
> index e07727a..487238a 100644
> --- a/arch/arm64/kernel/kprobes-arm64.c
> +++ b/arch/arm64/kernel/kprobes-arm64.c
> @@ -21,6 +21,7 @@
>  #include <asm/sections.h>
>  
>  #include "kprobes-arm64.h"
> +#include "probes-simulate-insn.h"
>  
>  static bool __kprobes aarch64_insn_is_steppable(u32 insn)
>  {
> @@ -62,8 +63,36 @@ arm_probe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi)
>  	 */
>  	if (aarch64_insn_is_steppable(insn))
>  		return INSN_GOOD;
> +
> +	if (aarch64_insn_is_bcond(insn)) {
> +		asi->handler = simulate_b_cond;
> +	} else if (aarch64_insn_is_cbz(insn) ||
> +	    aarch64_insn_is_cbnz(insn)) {
> +		asi->handler = simulate_cbz_cbnz;
> +	} else if (aarch64_insn_is_tbz(insn) ||
> +	    aarch64_insn_is_tbnz(insn)) {
> +		asi->handler = simulate_tbz_tbnz;
> +	} else if (aarch64_insn_is_adr_adrp(insn))
> +		asi->handler = simulate_adr_adrp;
> +	else if (aarch64_insn_is_b(insn) ||
> +	    aarch64_insn_is_bl(insn))
> +		asi->handler = simulate_b_bl;
> +	else if (aarch64_insn_is_br(insn) ||
> +	    aarch64_insn_is_blr(insn) ||
> +	    aarch64_insn_is_ret(insn))
> +		asi->handler = simulate_br_blr_ret;
> +	else if (aarch64_insn_is_ldr_lit(insn))
> +		asi->handler = simulate_ldr_literal;
> +	else if (aarch64_insn_is_ldrsw_lit(insn))
> +		asi->handler = simulate_ldrsw_literal;
>  	else
> +		/*
> +		 * Instruction cannot be stepped out-of-line and we don't
> +		 * (yet) simulate it.
> +		 */
>  		return INSN_REJECTED;
> +
> +	return INSN_GOOD_NO_SLOT;
>  }
>  
>  static bool __kprobes
> diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
> index 8db71a4..52f6c3d 100644
> --- a/arch/arm64/kernel/kprobes.c
> +++ b/arch/arm64/kernel/kprobes.c
> @@ -40,6 +40,9 @@ void jprobe_return_break(void);
>  DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
>  DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
>  
> +static void __kprobes
> +post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
> +
>  static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
>  {
>  	/* prepare insn slot */
> @@ -57,6 +60,24 @@ static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
>  	p->ainsn.restore.type = RESTORE_PC;
>  }
>  
> +static void __kprobes arch_prepare_simulate(struct kprobe *p)
> +{
> +	/* This instructions is not executed xol. No need to adjust the PC */
> +	p->ainsn.restore.addr = 0;
> +	p->ainsn.restore.type = NO_RESTORE;
> +}
> +
> +static void __kprobes arch_simulate_insn(struct kprobe *p, struct pt_regs *regs)
> +{
> +	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> +
> +	if (p->ainsn.handler)
> +		p->ainsn.handler((u32)p->opcode, (long)p->addr, regs);
> +
> +	/* single step simulated, now go for post processing */
> +	post_kprobe_handler(kcb, regs);
> +}
> +
>  int __kprobes arch_prepare_kprobe(struct kprobe *p)
>  {
>  	unsigned long probe_addr = (unsigned long)p->addr;
> @@ -73,7 +94,8 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
>  		return -EINVAL;
>  
>  	case INSN_GOOD_NO_SLOT:	/* insn need simulation */
> -		return -EINVAL;
> +		p->ainsn.insn = NULL;
> +		break;
>  
>  	case INSN_GOOD:	/* instruction uses slot */
>  		p->ainsn.insn = get_insn_slot();
> @@ -83,7 +105,10 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
>  	};
>  
>  	/* prepare the instruction */
> -	arch_prepare_ss_slot(p);
> +	if (p->ainsn.insn)
> +		arch_prepare_ss_slot(p);
> +	else
> +		arch_prepare_simulate(p);
>  
>  	return 0;
>  }
> @@ -225,7 +250,8 @@ static void __kprobes setup_singlestep(struct kprobe *p,
>  		kernel_enable_single_step(regs);
>  		instruction_pointer(regs) = slot;
>  	} else	{
> -		BUG();
> +		/* insn simulation */
> +		arch_simulate_insn(p, regs);
>  	}
>  }
>  
> diff --git a/arch/arm64/kernel/probes-simulate-insn.c b/arch/arm64/kernel/probes-simulate-insn.c
> new file mode 100644
> index 0000000..dfcece9
> --- /dev/null
> +++ b/arch/arm64/kernel/probes-simulate-insn.c
> @@ -0,0 +1,187 @@
> +/*
> + * arch/arm64/kernel/probes-simulate-insn.c
> + *
> + * Copyright (C) 2013 Linaro Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/kprobes.h>
> +#include <linux/module.h>
> +
> +#include "probes-simulate-insn.h"
> +
> +#define sign_extend(x, signbit)		\
> +	((x) | (0 - ((x) & (1 << (signbit)))))
> +
> +#define bbl_displacement(insn)		\
> +	sign_extend(((insn) & 0x3ffffff) << 2, 27)
> +
> +#define bcond_displacement(insn)	\
> +	sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
> +
> +#define cbz_displacement(insn)	\
> +	sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
> +
> +#define tbz_displacement(insn)	\
> +	sign_extend(((insn >> 5) & 0x3fff) << 2, 15)
> +
> +#define ldr_displacement(insn)	\
> +	sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
> +
> +
> +static unsigned long __kprobes check_cbz(u32 opcode, struct pt_regs *regs)
> +{
> +	int xn = opcode & 0x1f;
> +
> +	return (opcode & (1 << 31)) ?
> +	    !(regs->regs[xn]) : !(regs->regs[xn] & 0xffffffff);
> +}
> +
> +static unsigned long __kprobes check_cbnz(u32 opcode, struct pt_regs *regs)
> +{
> +	int xn = opcode & 0x1f;
> +
> +	return (opcode & (1 << 31)) ?
> +	    (regs->regs[xn]) : (regs->regs[xn] & 0xffffffff);
> +}
> +
> +static unsigned long __kprobes check_tbz(u32 opcode, struct pt_regs *regs)
> +{
> +	int xn = opcode & 0x1f;
> +	int bit_pos = ((opcode & (1 << 31)) >> 26) | ((opcode >> 19) & 0x1f);
> +
> +	return !((regs->regs[xn] >> bit_pos) & 0x1);
> +}
> +
> +static unsigned long __kprobes check_tbnz(u32 opcode, struct pt_regs *regs)
> +{
> +	int xn = opcode & 0x1f;
> +	int bit_pos = ((opcode & (1 << 31)) >> 26) | ((opcode >> 19) & 0x1f);
> +
> +	return (regs->regs[xn] >> bit_pos) & 0x1;
> +}

Same remark as above: these should be returning a boolean value.

> +
> +/*
> + * instruction simulation functions
> + */
> +void __kprobes
> +simulate_adr_adrp(u32 opcode, long addr, struct pt_regs *regs)
> +{
> +	long imm, xn, val;
> +
> +	xn = opcode & 0x1f;
> +	imm = ((opcode >> 3) & 0x1ffffc) | ((opcode >> 29) & 0x3);
> +	imm = sign_extend(imm, 20);
> +	if (opcode & 0x80000000)
> +		val = (imm<<12) + (addr & 0xfffffffffffff000);
> +	else
> +		val = imm + addr;
> +
> +	regs->regs[xn] = val;
> +
> +	instruction_pointer(regs) += 4;
> +}
> +
> +void __kprobes
> +simulate_b_bl(u32 opcode, long addr, struct pt_regs *regs)
> +{
> +	int disp = bbl_displacement(opcode);
> +
> +	/* Link register is x30 */
> +	if (opcode & (1 << 31))
> +		regs->regs[30] = addr + 4;
> +
> +	instruction_pointer(regs) = addr + disp;
> +}
> +
> +void __kprobes
> +simulate_b_cond(u32 opcode, long addr, struct pt_regs *regs)
> +{
> +	int disp = 4;
> +
> +	if (opcode_condition_checks[opcode & 0xf](regs->pstate & 0xffffffff))
> +		disp = bcond_displacement(opcode);
> +
> +	instruction_pointer(regs) = addr + disp;
> +}
> +
> +void __kprobes
> +simulate_br_blr_ret(u32 opcode, long addr, struct pt_regs *regs)
> +{
> +	int xn = (opcode >> 5) & 0x1f;
> +
> +	/* Link register is x30 */
> +	if (((opcode >> 21) & 0x3) == 1)
> +		regs->regs[30] = addr + 4;
> +
> +	instruction_pointer(regs) = regs->regs[xn];
> +}
> +
> +void __kprobes
> +simulate_cbz_cbnz(u32 opcode, long addr, struct pt_regs *regs)
> +{
> +	int disp = 4;
> +
> +	if (opcode & (1 << 24)) {
> +		if (check_cbnz(opcode, regs))
> +			disp = cbz_displacement(opcode);
> +	} else {
> +		if (check_cbz(opcode, regs))
> +			disp = cbz_displacement(opcode);
> +	}
> +	instruction_pointer(regs) = addr + disp;
> +}
> +
> +void __kprobes
> +simulate_tbz_tbnz(u32 opcode, long addr, struct pt_regs *regs)
> +{
> +	int disp = 4;
> +
> +	if (opcode & (1 << 24)) {
> +		if (check_tbnz(opcode, regs))
> +			disp = tbz_displacement(opcode);
> +	} else {
> +		if (check_tbz(opcode, regs))
> +			disp = tbz_displacement(opcode);
> +	}
> +	instruction_pointer(regs) = addr + disp;
> +}
> +
> +void __kprobes
> +simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs)
> +{
> +	u64 *load_addr;
> +	int xn = opcode & 0x1f;
> +	int disp = ldr_displacement(opcode);
> +
> +	load_addr = (u64 *) (addr + disp);
> +
> +	if (opcode & (1 << 30))	/* x0-x31 */
> +		regs->regs[xn] = *load_addr;
> +	else			/* w0-w31 */
> +		*(u32 *) (&regs->regs[xn]) = (*(u32 *) (load_addr));
> +
> +	instruction_pointer(regs) += 4;
> +}
> +
> +void __kprobes
> +simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs)
> +{
> +	s32 *load_addr;
> +	int xn = opcode & 0x1f;
> +	int disp = ldr_displacement(opcode);
> +
> +	load_addr = (s32 *) (addr + disp);
> +	regs->regs[xn] = *load_addr;
> +
> +	instruction_pointer(regs) += 4;
> +}
> diff --git a/arch/arm64/kernel/probes-simulate-insn.h b/arch/arm64/kernel/probes-simulate-insn.h
> new file mode 100644
> index 0000000..337384e
> --- /dev/null
> +++ b/arch/arm64/kernel/probes-simulate-insn.h
> @@ -0,0 +1,30 @@
> +/*
> + * arch/arm64/kernel/probes-simulate-insn.h
> + *
> + * Copyright (C) 2013 Linaro Limited
> + *
> + * 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.
> + */
> +
> +#ifndef _ARM_KERNEL_PROBES_SIMULATE_INSN_H
> +#define _ARM_KERNEL_PROBES_SIMULATE_INSN_H
> +
> +extern pstate_check_t * const opcode_condition_checks[16];
> +
> +void simulate_adr_adrp(u32 opcode, long addr, struct pt_regs *regs);
> +void simulate_b_bl(u32 opcode, long addr, struct pt_regs *regs);
> +void simulate_b_cond(u32 opcode, long addr, struct pt_regs *regs);
> +void simulate_br_blr_ret(u32 opcode, long addr, struct pt_regs *regs);
> +void simulate_cbz_cbnz(u32 opcode, long addr, struct pt_regs *regs);
> +void simulate_tbz_tbnz(u32 opcode, long addr, struct pt_regs *regs);
> +void simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs);
> +void simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs);
> +
> +#endif /* _ARM_KERNEL_PROBES_SIMULATE_INSN_H */
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From arnd at arndb.de  Fri Feb 19 06:06:48 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 15:06:48 +0100
Subject: [RFC5 PATCH v6 00/21] ILP32 for ARM64
In-Reply-To: <20160219125959.GA8675@yury-N73SV>
References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com>
 <208897488.c0hkBy2G1S@wuerfel> <20160219125959.GA8675@yury-N73SV>
Message-ID: <91909204.T63Mn1YGy7@wuerfel>

On Friday 19 February 2016 15:59:59 Yury Norov wrote:
> On Fri, Feb 19, 2016 at 09:23:35AM +0100, Arnd Bergmann wrote:
> > On Friday 19 February 2016 01:35:06 Yury Norov wrote:

> > In https://github.com/norov/glibc/commit/5d4290435e428267171ece871539b76e1d079d11
> > you are defining a struct __kernel_stat64 in the glibc. Is this the expected
> > way to do it? I would have thought you'd get the definition from the kernel
> > headers.
> >  
> > 	Arnd
> > 
> 
> Almost all ports define its own struct kernel_stat / kernel_stat64.
> in "kernel_header.h" See mips, spark, alpha, i386... Some also define
> function xstat_conv or similar. With all that defined, it's expected
> that one of generic xstat wrappers will work properly. I tried all,
> and noone got working, so I wrote this hack to make it work somehow. 

I see. I grepped for __kernel_stat64 and couldn't find any other
with that name, as the others tend to us slightly different names.

I would still think there is something wrong if you need to define
your own copy of xstat_conv when the kernel 'struct stat64' is
meant to be usable by user space. Shouldn't this work like any
other 32-bit architecture now?

	Arnd


From linux at arm.linux.org.uk  Fri Feb 19 06:06:00 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Feb 2016 14:06:00 +0000
Subject: [PATCH 2/2] ARM: dma-mapping: fix alloc/free for coherent + CMA
 + gfp=0
In-Reply-To: <1455869524-13874-2-git-send-email-rabin.vincent@axis.com>
References: <1455869524-13874-1-git-send-email-rabin.vincent@axis.com>
 <1455869524-13874-2-git-send-email-rabin.vincent@axis.com>
Message-ID: <20160219140600.GW19428@n2100.arm.linux.org.uk>

On Fri, Feb 19, 2016 at 09:12:04AM +0100, Rabin Vincent wrote:
> Given a device which uses arm_coherent_dma_ops and on which
> dev_get_cma_area(dev) returns non-NULL, the following usage of the DMA
> API with gfp=0 results in a memory leak and memory corruption.
> 
>  p = dma_alloc_coherent(dev, sz, &dma, 0);
>  if (p)
>  	dma_free_coherent(dev, sz, p, dma);
> 
> The memory leak is because the alloc allocates using
> __alloc_simple_buffer() but the free attempts
> dma_release_from_contiguous(), which does not do free anything since the
> page is not in the CMA area.

I'd really like to see a better solution to this problem: over the course
of the years, I've seen a number of patches that rearrange the test order
at allocation time because of some problem or the other.

What we need is a better way to ensure that we use the correct release
functionality - having two independent set of tests where the order
matters is really not very good.

Maybe someone can put some thought into this...

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From peter.ujfalusi at ti.com  Fri Feb 19 06:12:19 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Fri, 19 Feb 2016 16:12:19 +0200
Subject: [PATCH] Revert "regulator: tps65217: remove tps65217.dtsi file"
Message-ID: <1455891139-6139-1-git-send-email-peter.ujfalusi@ti.com>

This reverts commit 8e6ebfaa9b384088002baa10f7534efa73a0794e.

Without the patch reverted regulators will not work. This prevents
MMC to be working for example so the boards can not boot to
MMC rootfs.

Tested it on beaglebone white and bisect also points to the
reverted commit.
The issue can be also fixed by adding "regulator-compatible =" to all board
dts file for the regulators.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
Hi,

I have noticed that bbw did not find the MMC with linux-next, but it turns out
that even 4.5-rc4 is behaving the same way.
I have run bisect and with this revert patch I can boot up fine.
To be honest I don't know why the tps65217.dtsi has been deleted in the first
place. 


 .../devicetree/bindings/regulator/tps65217.txt     | 10 ----
 arch/arm/boot/dts/am335x-bone-common.dtsi          | 14 ++----
 arch/arm/boot/dts/am335x-chilisom.dtsi             | 14 +-----
 arch/arm/boot/dts/am335x-nano.dts                  | 14 +-----
 arch/arm/boot/dts/am335x-pepper.dts                | 14 +-----
 arch/arm/boot/dts/am335x-sl50.dts                  | 13 +----
 arch/arm/boot/dts/tps65217.dtsi                    | 56 ++++++++++++++++++++++
 7 files changed, 67 insertions(+), 68 deletions(-)
 create mode 100644 arch/arm/boot/dts/tps65217.dtsi

diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt b/Documentation/devicetree/bindings/regulator/tps65217.txt
index d18109657da6..4f05d208c95c 100644
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65217.txt
@@ -26,11 +26,7 @@ Example:
 		ti,pmic-shutdown-controller;
 
 		regulators {
-			#address-cells = <1>;
-			#size-cells = <0>;
-
 			dcdc1_reg: dcdc1 {
-				reg = <0>;
 				regulator-min-microvolt = <900000>;
 				regulator-max-microvolt = <1800000>;
 				regulator-boot-on;
@@ -38,7 +34,6 @@ Example:
 			};
 
 			dcdc2_reg: dcdc2 {
-				reg = <1>;
 				regulator-min-microvolt = <900000>;
 				regulator-max-microvolt = <3300000>;
 				regulator-boot-on;
@@ -46,7 +41,6 @@ Example:
 			};
 
 			dcdc3_reg: dcc3 {
-				reg = <2>;
 				regulator-min-microvolt = <900000>;
 				regulator-max-microvolt = <1500000>;
 				regulator-boot-on;
@@ -54,7 +48,6 @@ Example:
 			};
 
 			ldo1_reg: ldo1 {
-				reg = <3>;
 				regulator-min-microvolt = <1000000>;
 				regulator-max-microvolt = <3300000>;
 				regulator-boot-on;
@@ -62,7 +55,6 @@ Example:
 			};
 
 			ldo2_reg: ldo2 {
-				reg = <4>;
 				regulator-min-microvolt = <900000>;
 				regulator-max-microvolt = <3300000>;
 				regulator-boot-on;
@@ -70,7 +62,6 @@ Example:
 			};
 
 			ldo3_reg: ldo3 {
-				reg = <5>;
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <3300000>;
 				regulator-boot-on;
@@ -78,7 +69,6 @@ Example:
 			};
 
 			ldo4_reg: ldo4 {
-				reg = <6>;
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <3300000>;
 				regulator-boot-on;
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index f3db13d2d90e..0cc150b87b86 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -285,8 +285,10 @@
 	};
 };
 
+
+/include/ "tps65217.dtsi"
+
 &tps {
-	compatible = "ti,tps65217";
 	/*
 	 * Configure pmic to enter OFF-state instead of SLEEP-state ("RTC-only
 	 * mode") at poweroff.  Most BeagleBone versions do not support RTC-only
@@ -307,17 +309,12 @@
 	ti,pmic-shutdown-controller;
 
 	regulators {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
 		dcdc1_reg: regulator at 0 {
-			reg = <0>;
 			regulator-name = "vdds_dpr";
 			regulator-always-on;
 		};
 
 		dcdc2_reg: regulator at 1 {
-			reg = <1>;
 			/* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
 			regulator-name = "vdd_mpu";
 			regulator-min-microvolt = <925000>;
@@ -327,7 +324,6 @@
 		};
 
 		dcdc3_reg: regulator at 2 {
-			reg = <2>;
 			/* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */
 			regulator-name = "vdd_core";
 			regulator-min-microvolt = <925000>;
@@ -337,25 +333,21 @@
 		};
 
 		ldo1_reg: regulator at 3 {
-			reg = <3>;
 			regulator-name = "vio,vrtc,vdds";
 			regulator-always-on;
 		};
 
 		ldo2_reg: regulator at 4 {
-			reg = <4>;
 			regulator-name = "vdd_3v3aux";
 			regulator-always-on;
 		};
 
 		ldo3_reg: regulator at 5 {
-			reg = <5>;
 			regulator-name = "vdd_1v8";
 			regulator-always-on;
 		};
 
 		ldo4_reg: regulator at 6 {
-			reg = <6>;
 			regulator-name = "vdd_3v3a";
 			regulator-always-on;
 		};
diff --git a/arch/arm/boot/dts/am335x-chilisom.dtsi b/arch/arm/boot/dts/am335x-chilisom.dtsi
index fda457b07e15..857d9894103a 100644
--- a/arch/arm/boot/dts/am335x-chilisom.dtsi
+++ b/arch/arm/boot/dts/am335x-chilisom.dtsi
@@ -128,21 +128,16 @@
 
 };
 
-&tps {
-	compatible = "ti,tps65217";
+/include/ "tps65217.dtsi"
 
+&tps {
 	regulators {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
 		dcdc1_reg: regulator at 0 {
-			reg = <0>;
 			regulator-name = "vdds_dpr";
 			regulator-always-on;
 		};
 
 		dcdc2_reg: regulator at 1 {
-			reg = <1>;
 			/* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
 			regulator-name = "vdd_mpu";
 			regulator-min-microvolt = <925000>;
@@ -152,7 +147,6 @@
 		};
 
 		dcdc3_reg: regulator at 2 {
-			reg = <2>;
 			/* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */
 			regulator-name = "vdd_core";
 			regulator-min-microvolt = <925000>;
@@ -162,28 +156,24 @@
 		};
 
 		ldo1_reg: regulator at 3 {
-			reg = <3>;
 			regulator-name = "vio,vrtc,vdds";
 			regulator-boot-on;
 			regulator-always-on;
 		};
 
 		ldo2_reg: regulator at 4 {
-			reg = <4>;
 			regulator-name = "vdd_3v3aux";
 			regulator-boot-on;
 			regulator-always-on;
 		};
 
 		ldo3_reg: regulator at 5 {
-			reg = <5>;
 			regulator-name = "vdd_1v8";
 			regulator-boot-on;
 			regulator-always-on;
 		};
 
 		ldo4_reg: regulator at 6 {
-			reg = <6>;
 			regulator-name = "vdd_3v3d";
 			regulator-boot-on;
 			regulator-always-on;
diff --git a/arch/arm/boot/dts/am335x-nano.dts b/arch/arm/boot/dts/am335x-nano.dts
index 77559a1ded60..f313999c503e 100644
--- a/arch/arm/boot/dts/am335x-nano.dts
+++ b/arch/arm/boot/dts/am335x-nano.dts
@@ -375,15 +375,11 @@
 	wp-gpios = <&gpio3 18 0>;
 };
 
-&tps {
-	compatible = "ti,tps65217";
+#include "tps65217.dtsi"
 
+&tps {
 	regulators {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
 		dcdc1_reg: regulator at 0 {
-			reg = <0>;
 			/* +1.5V voltage with ?4% tolerance */
 			regulator-min-microvolt = <1450000>;
 			regulator-max-microvolt = <1550000>;
@@ -392,7 +388,6 @@
 		};
 
 		dcdc2_reg: regulator at 1 {
-			reg = <1>;
 			/* VDD_MPU voltage limits 0.95V - 1.1V with ?4% tolerance */
 			regulator-name = "vdd_mpu";
 			regulator-min-microvolt = <915000>;
@@ -402,7 +397,6 @@
 		};
 
 		dcdc3_reg: regulator at 2 {
-			reg = <2>;
 			/* VDD_CORE voltage limits 0.95V - 1.1V with ?4% tolerance */
 			regulator-name = "vdd_core";
 			regulator-min-microvolt = <915000>;
@@ -412,7 +406,6 @@
 		};
 
 		ldo1_reg: regulator at 3 {
-			reg = <3>;
 			/* +1.8V voltage with ?4% tolerance */
 			regulator-min-microvolt = <1750000>;
 			regulator-max-microvolt = <1870000>;
@@ -421,7 +414,6 @@
 		};
 
 		ldo2_reg: regulator at 4 {
-			reg = <4>;
 			/* +3.3V voltage with ?4% tolerance */
 			regulator-min-microvolt = <3175000>;
 			regulator-max-microvolt = <3430000>;
@@ -430,7 +422,6 @@
 		};
 
 		ldo3_reg: regulator at 5 {
-			reg = <5>;
 			/* +1.8V voltage with ?4% tolerance */
 			regulator-min-microvolt = <1750000>;
 			regulator-max-microvolt = <1870000>;
@@ -439,7 +430,6 @@
 		};
 
 		ldo4_reg: regulator at 6 {
-			reg = <6>;
 			/* +3.3V voltage with ?4% tolerance */
 			regulator-min-microvolt = <3175000>;
 			regulator-max-microvolt = <3430000>;
diff --git a/arch/arm/boot/dts/am335x-pepper.dts b/arch/arm/boot/dts/am335x-pepper.dts
index 471a3a70ea1f..8867aaaec54d 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -420,9 +420,9 @@
 	vin-supply = <&vbat>;
 };
 
-&tps {
-	compatible = "ti,tps65217";
+/include/ "tps65217.dtsi"
 
+&tps {
 	backlight {
 		isel = <1>; /* ISET1 */
 		fdim = <200>; /* TPS65217_BL_FDIM_200HZ */
@@ -430,17 +430,12 @@
 	};
 
 	regulators {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
 		dcdc1_reg: regulator at 0 {
-			reg = <0>;
 			/* VDD_1V8 system supply */
 			regulator-always-on;
 		};
 
 		dcdc2_reg: regulator at 1 {
-			reg = <1>;
 			/* VDD_CORE voltage limits 0.95V - 1.26V with +/-4% tolerance */
 			regulator-name = "vdd_core";
 			regulator-min-microvolt = <925000>;
@@ -450,7 +445,6 @@
 		};
 
 		dcdc3_reg: regulator at 2 {
-			reg = <2>;
 			/* VDD_MPU voltage limits 0.95V - 1.1V with +/-4% tolerance */
 			regulator-name = "vdd_mpu";
 			regulator-min-microvolt = <925000>;
@@ -460,21 +454,18 @@
 		};
 
 		ldo1_reg: regulator at 3 {
-			reg = <3>;
 			/* VRTC 1.8V always-on supply */
 			regulator-name = "vrtc,vdds";
 			regulator-always-on;
 		};
 
 		ldo2_reg: regulator at 4 {
-			reg = <4>;
 			/* 3.3V rail */
 			regulator-name = "vdd_3v3aux";
 			regulator-always-on;
 		};
 
 		ldo3_reg: regulator at 5 {
-			reg = <5>;
 			/* VDD_3V3A 3.3V rail */
 			regulator-name = "vdd_3v3a";
 			regulator-min-microvolt = <3300000>;
@@ -482,7 +473,6 @@
 		};
 
 		ldo4_reg: regulator at 6 {
-			reg = <6>;
 			/* VDD_3V3B 3.3V rail */
 			regulator-name = "vdd_3v3b";
 			regulator-always-on;
diff --git a/arch/arm/boot/dts/am335x-sl50.dts b/arch/arm/boot/dts/am335x-sl50.dts
index a676869536bc..a6efbe6eda3b 100644
--- a/arch/arm/boot/dts/am335x-sl50.dts
+++ b/arch/arm/boot/dts/am335x-sl50.dts
@@ -395,19 +395,16 @@
 	pinctrl-0 = <&uart4_pins>;
 };
 
+#include "tps65217.dtsi"
+
 &tps {
-	compatible = "ti,tps65217";
 	ti,pmic-shutdown-controller;
 
 	interrupt-parent = <&intc>;
 	interrupts = <7>;	/* NNMI */
 
 	regulators {
-		#address-cells = <1>;
-		#size-cells = <0>;
-
 		dcdc1_reg: regulator at 0 {
-			reg = <0>;
 			/* VDDS_DDR */
 			regulator-min-microvolt = <1500000>;
 			regulator-max-microvolt = <1500000>;
@@ -415,7 +412,6 @@
 		};
 
 		dcdc2_reg: regulator at 1 {
-			reg = <1>;
 			/* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% tolerance */
 			regulator-name = "vdd_mpu";
 			regulator-min-microvolt = <925000>;
@@ -425,7 +421,6 @@
 		};
 
 		dcdc3_reg: regulator at 2 {
-			reg = <2>;
 			/* VDD_CORE voltage limits 0.95V - 1.1V with +/-4% tolerance */
 			regulator-name = "vdd_core";
 			regulator-min-microvolt = <925000>;
@@ -435,7 +430,6 @@
 		};
 
 		ldo1_reg: regulator at 3 {
-			reg = <3>;
 			/* VRTC / VIO / VDDS*/
 			regulator-always-on;
 			regulator-min-microvolt = <1800000>;
@@ -443,7 +437,6 @@
 		};
 
 		ldo2_reg: regulator at 4 {
-			reg = <4>;
 			/* VDD_3V3AUX */
 			regulator-always-on;
 			regulator-min-microvolt = <3300000>;
@@ -451,7 +444,6 @@
 		};
 
 		ldo3_reg: regulator at 5 {
-			reg = <5>;
 			/* VDD_1V8 */
 			regulator-min-microvolt = <1800000>;
 			regulator-max-microvolt = <1800000>;
@@ -459,7 +451,6 @@
 		};
 
 		ldo4_reg: regulator at 6 {
-			reg = <6>;
 			/* VDD_3V3A */
 			regulator-min-microvolt = <3300000>;
 			regulator-max-microvolt = <3300000>;
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
new file mode 100644
index 000000000000..a63272422d76
--- /dev/null
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -0,0 +1,56 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/tps65217.pdf
+ */
+
+&tps {
+	compatible = "ti,tps65217";
+
+	regulators {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		dcdc1_reg: regulator at 0 {
+			reg = <0>;
+			regulator-compatible = "dcdc1";
+		};
+
+		dcdc2_reg: regulator at 1 {
+			reg = <1>;
+			regulator-compatible = "dcdc2";
+		};
+
+		dcdc3_reg: regulator at 2 {
+			reg = <2>;
+			regulator-compatible = "dcdc3";
+		};
+
+		ldo1_reg: regulator at 3 {
+			reg = <3>;
+			regulator-compatible = "ldo1";
+		};
+
+		ldo2_reg: regulator at 4 {
+			reg = <4>;
+			regulator-compatible = "ldo2";
+		};
+
+		ldo3_reg: regulator at 5 {
+			reg = <5>;
+			regulator-compatible = "ldo3";
+		};
+
+		ldo4_reg: regulator at 6 {
+			reg = <6>;
+			regulator-compatible = "ldo4";
+		};
+	};
+};
-- 
2.7.1



From marc.zyngier at arm.com  Fri Feb 19 06:15:46 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Feb 2016 14:15:46 +0000
Subject: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI
 on Marvell 7K/8K
In-Reply-To: <1455888883-5127-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455888883-5127-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <56C72392.5010202@arm.com>

On 19/02/16 13:34, Thomas Petazzoni wrote:
> This commits adds a new irqchip driver that handles the ODMI
> controller found on Marvell 7K/8K processors. The ODMI controller
> provide MSI interrupt functionality to on-board peripherals, much like
> the GIC-v2m.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
> Changes v2 -> v2:
>  - Express NODMIS_SHIFT, NODMIS_PER_FRAME, NODMIS_MASK in term of each
>    other. Suggested by Marc Zyngier.
>  - Rework the global bitmask allocation to make sure we allocate a
>    number of longs rather than a number of bytes, to avoid having the
>    bitmap API (which operates on longs) access memory we haven't
>    explicitly allocated. Reported by Marc Zyngier.
> 
> Changes v1 -> v2:
>  - Better commit title, as suggested by Marc Zyngier.
>  - Improve the DT binding documentation, as suggested by Marc Zingier:
>    add a reference to the GIC documentation, be more specific about
>    the marvell,spi-base values, and add the requirement of the
>    interrupt-parent property.
>  - As suggested by Marc Zyngier, use a single global bitmap to
>    allocate all ODMIs, regardless of the frame they belong to. As part
>    of this change, the hwirq used to identify the interrupt inside the
>    ODMI irqdomain are 0-based (instead of being based on their
>    corresponding SPI base value), which allows to significantly
>    simplify the allocation/free logic.
> ---
>  .../marvell,odmi-controller.txt                    |  41 ++++
>  drivers/irqchip/Kconfig                            |   4 +
>  drivers/irqchip/Makefile                           |   1 +
>  drivers/irqchip/irq-mvebu-odmi.c                   | 248 +++++++++++++++++++++
>  4 files changed, 294 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
>  create mode 100644 drivers/irqchip/irq-mvebu-odmi.c

Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>

I'll queue that for 4.6.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From sebott at linux.vnet.ibm.com  Fri Feb 19 06:15:50 2016
From: sebott at linux.vnet.ibm.com (Sebastian Ott)
Date: Fri, 19 Feb 2016 15:15:50 +0100 (CET)
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160218170658.GC28184@node.shutemov.name>
References: <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name> <56BE00E7.1010303@de.ibm.com>
 <20160212181640.4eabb85f@thinkpad>
 <20160212231510.GB15142@node.shutemov.name>
 <alpine.LFD.2.20.1602131238260.1910@schleppi>
 <20160217201340.2dafad8d@thinkpad>
 <20160217235808.GA21696@node.shutemov.name>
 <20160218160037.627cc7ec@thinkpad>
 <20160218170658.GC28184@node.shutemov.name>
Message-ID: <alpine.LFD.2.20.1602191509270.1742@schleppi>


On Thu, 18 Feb 2016, Kirill A. Shutemov wrote:
> I worth minimizing kernel config on which you can see the bug. Things like
> CONFIG_DEBUG_PAGEALLOC used to interfere with THP before.

I disabled all debugging options (using
arch/s390/configs/performance_defconfig) - we still chrashed.

Sebastian



From thomas.petazzoni at free-electrons.com  Fri Feb 19 06:17:26 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 19 Feb 2016 15:17:26 +0100
Subject: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI
 on Marvell 7K/8K
In-Reply-To: <56C72392.5010202@arm.com>
References: <1455888883-5127-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <56C72392.5010202@arm.com>
Message-ID: <20160219151726.418ba46b@free-electrons.com>

Marc,

On Fri, 19 Feb 2016 14:15:46 +0000, Marc Zyngier wrote:

> >  .../marvell,odmi-controller.txt                    |  41 ++++
> >  drivers/irqchip/Kconfig                            |   4 +
> >  drivers/irqchip/Makefile                           |   1 +
> >  drivers/irqchip/irq-mvebu-odmi.c                   | 248 +++++++++++++++++++++
> >  4 files changed, 294 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
> >  create mode 100644 drivers/irqchip/irq-mvebu-odmi.c
> 
> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
> 
> I'll queue that for 4.6.

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From arnd at arndb.de  Fri Feb 19 06:21:11 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 15:21:11 +0100
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <HK2PR06MB0561F8D4A17AAEFEBD774E478AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
 <3461274.sjccN4r7lq@wuerfel>
 <HK2PR06MB0561F8D4A17AAEFEBD774E478AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
Message-ID: <2413859.DaWDFlIaaB@wuerfel>

On Friday 19 February 2016 13:49:38 Chris Brandt wrote:
> On 19 Feb 2016, Arnd Bergmann wrote:

> > - allow turning on XIP_KERNEL as long as Kconfig can figure out that
> >   this has a chance of working on at least one platform (easy enough
> >   to implement, and similar to how we handle DEBUG_LL).
> 
> 
> In the patch I was working on, if ARCH_MULTIPLATFORM was selected
>  (which is the problem I'm trying to solve), you can only select
> XIP_KERNEL if 'MULTIPLATFORM_XIP_CAPABLE' is selected. At least
> then we could restrict the multiplatform platforms to ones that
> stand a chance of XIP booting (or at least have been known to
> boot at one point or another)

Right, this seems fine to me, and we can combine that with
a Kconfig "choice" statement for picking one of the addresses
for RAM and ROM that are supported by the platforms (there should
ideally only be one of each, making the choice automatic).

> > - implement a Kconfig method to only allow XIP_KERNEL if exactly
> >   one platform is enable that supports it, or if all platforms
> >   use the exact same PHYS_OFFSET and XIP_PHYS_ADDR settings.
> >   Whether we want to enforce the same thing for DEBUG_LL is a
> >   separate matter once that infrastructure exists.
> > 
> > 	Arnd
> 
> This last one would be my favorite.
> 
> It would be nice if you could turn a section of "config ARCH_xxx
> bool" options into "choice" single select with some magical
> dynamic #ifdef.
> 
> if XIP_KERNEL
> choice
> endif
> 
> config DEVICE_A
> 	bool "Device A"
> 
> config DEVICE_B
> 	bool "Device B"
> 
> config DEVICE_C
> 	bool "Device C"
> 
> if XIP_KERNEL
> endchoice
> endif
> 
> 
> ...but...this doesn't work:

We can have 'tristate' inside of 'choice', which lets you pick one or
more the the inner options when they are all 'm', but only one if
one of them is 'y'. I don't think that solves the problem at
hand though, because that breaks the current per-platform submenus
that are not allowed inside of a 'choice'.

> I need a:
> 
> __INLINE__ if XIP_KERNEL
> choice
> endif

> Although...at some point I'd argue that you are trying to cater to a
> level of safety that is above and beyond XIP_KERNEL. There are
> probably multiple CONFIG options in the kernel that would break an
> XIP anyway.

We already turn them off today, mainly any dynamic patching is broken,
and so is the address randomization that Ard is working on, but those
are easy enough to handle.

> A car with the best seat belts and airbags still won't help you
> if you drive it off a cliff.

That was my point about DEBUG_LL: We already allow picking a DEBUG_LL
option that immediately breaks booting on any other platform, and
(worse) breaks even printing any useful output about that fact.

Even allowing XIP_KERNEL unconditionally doesn't make it much worse.

Other options that are able to ruin your day are CONFIG_CPU_BIG_ENDIAN
(which breaks all user space when changed) and CONFIG_ARM_LPAE (which
breaks booting on Cortex-A8/A9/A5 systems), or simply disabling essential
drivers like your console or the block device for your rootfs.

	Arnd


From arnd at arndb.de  Fri Feb 19 06:23:16 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 15:23:16 +0100
Subject: [PATCH 1/3] [RESEND] ARM: pass -march=armv7-a when building NEON
 files with clang
In-Reply-To: <alpine.LFD.2.20.1602181230440.13632@knanqh.ubzr>
References: <1455815113-2562966-1-git-send-email-arnd@arndb.de>
 <1455815113-2562966-2-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602181230440.13632@knanqh.ubzr>
Message-ID: <3205167.CfekeqRXnt@wuerfel>

On Thursday 18 February 2016 12:31:35 Nicolas Pitre wrote:
> On Thu, 18 Feb 2016, Arnd Bergmann wrote:
> 
> > clang ignores the -mfpu=neon flag when building with -march=armv6:
> > 
> > In file included from lib/raid6/neon1.c:27:
> > clang/3.8.0/include/arm_neon.h:28:2: error: "NEON support not enabled"
> > 
> > There is no real need to build the file with -march=armv6 in a
> > multi-CPU enabled kernel, as nothing in here will ever get called
> > on an ARMv6 CPU. Adding -march=armv7 doesn't hurt and can only
> > improve the code quality.
> 
> Is this enough to override a previous -mfpu for gcc?

I did not see any build failures on gcc with this, so I assume it
has no effect. I could move the -march=armv7-a in front of
-mfpu=neon if you think that would be safer though.

	Arnd


From catalin.marinas at arm.com  Fri Feb 19 06:25:52 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Feb 2016 14:25:52 +0000
Subject: [PATCH v6sub1 00/11] arm64: split linear and kernel mappings
In-Reply-To: <CAKv+Gu8aKDtev2LdGMy9a485Z8S7TYgsbXky6wR6e3F+j2nkUQ@mail.gmail.com>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160218182509.GG2538@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_UqoYB5QAWOU9_iZDoRO=rqHu8o87JboSAqNqOhoOCXw@mail.gmail.com>
 <CAKv+Gu_25mz37gdgVx5Yz7DJ+QbOMNa4rYBymFL1nL7nGOzBVQ@mail.gmail.com>
 <CAKv+Gu8aKDtev2LdGMy9a485Z8S7TYgsbXky6wR6e3F+j2nkUQ@mail.gmail.com>
Message-ID: <20160219142551.GA12864@e104818-lin.cambridge.arm.com>

On Fri, Feb 19, 2016 at 09:05:25AM +0100, Ard Biesheuvel wrote:
> On 18 February 2016 at 20:38, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> > On 18 February 2016 at 19:27, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> >> On 18 February 2016 at 19:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >>> On Tue, Feb 16, 2016 at 01:52:31PM +0100, Ard Biesheuvel wrote:
> >>>> Ard Biesheuvel (11):
> >>>>   of/fdt: make memblock minimum physical address arch configurable
> >>>>   of/fdt: factor out assignment of initrd_start/initrd_end
> >>>>   arm64: prevent potential circular header dependencies in asm/bug.h
> >>>>   arm64: add support for ioremap() block mappings
> >>>>   arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
> >>>>   arm64: pgtable: implement static [pte|pmd|pud]_offset variants
> >>>>   arm64: decouple early fixmap init from linear mapping
> >>>>   arm64: kvm: deal with kernel symbols outside of linear mapping
> >>>>   arm64: move kernel image to base of vmalloc area
> >>>>   arm64: defer __va translation of initrd_start and initrd_end
> >>>>   arm64: allow kernel Image to be loaded anywhere in physical memory
> >>>
> >>> I queued this patches (again) for 4.6. I'll wait a few days with the
> >>> rest of KASLR until these get a bit more coverage in -next.
> >>>
> >
> > I rebased the remaining patches onto for-next/core, and pushed it here:
> > https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-kaslr-v6
> >
> > I need to check if everything still works, and if it does, I will send
> > them out as v6sub2
> > Note that I have included the arm64 extable patch plus its generic
> > dependency, and the kallsyms patches as well. We can decide later how
> > to proceed with those, but for now, I included them for completeness.
> 
> OK, as it turns out, my arm64/extable patch conflicts with the UAO
> patches that are now in for-next/core, not textually, but those
> patches add additional absolute extable entries that need to be
> updated to relative as well.

I noticed this as well while testing KASLR.

> So it appears that akpm will need to drop that patch anyway, as he
> won't be able to carry an updated version since he does not have the
> UAO patches. That means it probably makes even more sense to take
> those through the arm64 tree as well (minus the x86 one, which has a
> conflict now as well). In fact, perhaps it makes sense to only take
> the base patch and the arm64 patch, and I can send the remaining ones
> to the various maintainers (or akpm) for v4.7

Or we make BUILDTIME_EXTABLE_SORT depend on !RANDOMIZE_BASE until we
sort out the extable patches.

-- 
Catalin


From ard.biesheuvel at linaro.org  Fri Feb 19 06:27:31 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 19 Feb 2016 15:27:31 +0100
Subject: [PATCH v6sub1 00/11] arm64: split linear and kernel mappings
In-Reply-To: <20160219142551.GA12864@e104818-lin.cambridge.arm.com>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160218182509.GG2538@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_UqoYB5QAWOU9_iZDoRO=rqHu8o87JboSAqNqOhoOCXw@mail.gmail.com>
 <CAKv+Gu_25mz37gdgVx5Yz7DJ+QbOMNa4rYBymFL1nL7nGOzBVQ@mail.gmail.com>
 <CAKv+Gu8aKDtev2LdGMy9a485Z8S7TYgsbXky6wR6e3F+j2nkUQ@mail.gmail.com>
 <20160219142551.GA12864@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu_44=2NMuon694T_YW6QUU-ixC+q_7WxbMtBuN3dRNP2Q@mail.gmail.com>

On 19 February 2016 at 15:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Fri, Feb 19, 2016 at 09:05:25AM +0100, Ard Biesheuvel wrote:
>> On 18 February 2016 at 20:38, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>> > On 18 February 2016 at 19:27, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>> >> On 18 February 2016 at 19:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> >>> On Tue, Feb 16, 2016 at 01:52:31PM +0100, Ard Biesheuvel wrote:
>> >>>> Ard Biesheuvel (11):
>> >>>>   of/fdt: make memblock minimum physical address arch configurable
>> >>>>   of/fdt: factor out assignment of initrd_start/initrd_end
>> >>>>   arm64: prevent potential circular header dependencies in asm/bug.h
>> >>>>   arm64: add support for ioremap() block mappings
>> >>>>   arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
>> >>>>   arm64: pgtable: implement static [pte|pmd|pud]_offset variants
>> >>>>   arm64: decouple early fixmap init from linear mapping
>> >>>>   arm64: kvm: deal with kernel symbols outside of linear mapping
>> >>>>   arm64: move kernel image to base of vmalloc area
>> >>>>   arm64: defer __va translation of initrd_start and initrd_end
>> >>>>   arm64: allow kernel Image to be loaded anywhere in physical memory
>> >>>
>> >>> I queued this patches (again) for 4.6. I'll wait a few days with the
>> >>> rest of KASLR until these get a bit more coverage in -next.
>> >>>
>> >
>> > I rebased the remaining patches onto for-next/core, and pushed it here:
>> > https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-kaslr-v6
>> >
>> > I need to check if everything still works, and if it does, I will send
>> > them out as v6sub2
>> > Note that I have included the arm64 extable patch plus its generic
>> > dependency, and the kallsyms patches as well. We can decide later how
>> > to proceed with those, but for now, I included them for completeness.
>>
>> OK, as it turns out, my arm64/extable patch conflicts with the UAO
>> patches that are now in for-next/core, not textually, but those
>> patches add additional absolute extable entries that need to be
>> updated to relative as well.
>
> I noticed this as well while testing KASLR.
>
>> So it appears that akpm will need to drop that patch anyway, as he
>> won't be able to carry an updated version since he does not have the
>> UAO patches. That means it probably makes even more sense to take
>> those through the arm64 tree as well (minus the x86 one, which has a
>> conflict now as well). In fact, perhaps it makes sense to only take
>> the base patch and the arm64 patch, and I can send the remaining ones
>> to the various maintainers (or akpm) for v4.7
>
> Or we make BUILDTIME_EXTABLE_SORT depend on !RANDOMIZE_BASE until we
> sort out the extable patches.
>

That would still result in breakage once the current version queued by
akpm hits mainline.


From jason at lakedaemon.net  Fri Feb 19 06:28:48 2016
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 19 Feb 2016 14:28:48 +0000
Subject: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI
 on Marvell 7K/8K
In-Reply-To: <56C72392.5010202@arm.com>
References: <1455888883-5127-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <56C72392.5010202@arm.com>
Message-ID: <20160219142848.GA958@io.lakedaemon.net>

On Fri, Feb 19, 2016 at 02:15:46PM +0000, Marc Zyngier wrote:
> On 19/02/16 13:34, Thomas Petazzoni wrote:
> > This commits adds a new irqchip driver that handles the ODMI
> > controller found on Marvell 7K/8K processors. The ODMI controller
> > provide MSI interrupt functionality to on-board peripherals, much like
> > the GIC-v2m.
> > 
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > ---
> > Changes v2 -> v2:
> >  - Express NODMIS_SHIFT, NODMIS_PER_FRAME, NODMIS_MASK in term of each
> >    other. Suggested by Marc Zyngier.
> >  - Rework the global bitmask allocation to make sure we allocate a
> >    number of longs rather than a number of bytes, to avoid having the
> >    bitmap API (which operates on longs) access memory we haven't
> >    explicitly allocated. Reported by Marc Zyngier.
> > 
> > Changes v1 -> v2:
> >  - Better commit title, as suggested by Marc Zyngier.
> >  - Improve the DT binding documentation, as suggested by Marc Zingier:
> >    add a reference to the GIC documentation, be more specific about
> >    the marvell,spi-base values, and add the requirement of the
> >    interrupt-parent property.
> >  - As suggested by Marc Zyngier, use a single global bitmap to
> >    allocate all ODMIs, regardless of the frame they belong to. As part
> >    of this change, the hwirq used to identify the interrupt inside the
> >    ODMI irqdomain are 0-based (instead of being based on their
> >    corresponding SPI base value), which allows to significantly
> >    simplify the allocation/free logic.
> > ---
> >  .../marvell,odmi-controller.txt                    |  41 ++++
> >  drivers/irqchip/Kconfig                            |   4 +
> >  drivers/irqchip/Makefile                           |   1 +
> >  drivers/irqchip/irq-mvebu-odmi.c                   | 248 +++++++++++++++++++++
> >  4 files changed, 294 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
> >  create mode 100644 drivers/irqchip/irq-mvebu-odmi.c
> 
> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
> 
> I'll queue that for 4.6.

I had it on my list to queue up, but you beat me to it.  :-)

thx,

Jason.


From Chris.Brandt at renesas.com  Fri Feb 19 06:29:00 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Fri, 19 Feb 2016 14:29:00 +0000
Subject: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values
In-Reply-To: <3974581.yknKb3tq7o@wuerfel>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-5-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602181100410.13632@knanqh.ubzr>
 <3974581.yknKb3tq7o@wuerfel>
Message-ID: <HK2PR06MB056137892B6F968A8A1008C58AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>

On 19 Feb 2016, Arnd Bergmann wrote:

> On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote:
> > 
> > Acked-by: Nicolas Pitre <nico at linaro.org>
> > 
> > Is there a way to provide a default for defaults?
> 
> We could have something like
> 
> config PHYS_OFFSET_0
> 	bool
> 
> config PHYS_OFFSET_1
> 	bool
> 
> config PHYS_OFFSET_2
> 	bool
> 
> ... (we need 8 of the 16 possible addresses)
> 
> 
> config PHYS_OFFSET
> 	hex "Physical address of main memory" if MMU
> 	default DRAM_BASE if !MMU
> 	default 0x00000000 if PHYS_OFFSET_0
> 	default 0x10000000 if PHYS_OFFSET_1
> 	default 0x20000000 if PHYS_OFFSET_2
> 	default 0x30000000 if PHYS_OFFSET_3
> 	default 0x70000000 if PHYS_OFFSET_7
> 	default 0x80000000 if PHYS_OFFSET_8
> 	default 0xa0000000 if PHYS_OFFSET_A
> 	default 0xc0000000 if PHYS_OFFSET_C
> 
> 
> and then select one of the bool symbols from each platform.
> Would that address your question?


Here's a question:

Can we just get rid of PHYS_OFFSET???

If it's only used at boot for XIP systems, we could:

A) pass it in via an unused register like atags and DT
 or
B) just assume that atags or DT is in RAM, so round down to the nearest section and assume that is the start of your RAM

If it is needed after initial boot, then on first boot we save what was passed in from the boot loader for later use.


Chris


From ard.biesheuvel at linaro.org  Fri Feb 19 06:29:13 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 19 Feb 2016 15:29:13 +0100
Subject: [PATCH v6sub1 00/11] arm64: split linear and kernel mappings
In-Reply-To: <CAKv+Gu_44=2NMuon694T_YW6QUU-ixC+q_7WxbMtBuN3dRNP2Q@mail.gmail.com>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160218182509.GG2538@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_UqoYB5QAWOU9_iZDoRO=rqHu8o87JboSAqNqOhoOCXw@mail.gmail.com>
 <CAKv+Gu_25mz37gdgVx5Yz7DJ+QbOMNa4rYBymFL1nL7nGOzBVQ@mail.gmail.com>
 <CAKv+Gu8aKDtev2LdGMy9a485Z8S7TYgsbXky6wR6e3F+j2nkUQ@mail.gmail.com>
 <20160219142551.GA12864@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_44=2NMuon694T_YW6QUU-ixC+q_7WxbMtBuN3dRNP2Q@mail.gmail.com>
Message-ID: <CAKv+Gu9WTVrYmc7GwxDeHppSHoRmSS4nK5iG3HZVMOPcPP1MOw@mail.gmail.com>

On 19 February 2016 at 15:27, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 19 February 2016 at 15:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> On Fri, Feb 19, 2016 at 09:05:25AM +0100, Ard Biesheuvel wrote:
>>> On 18 February 2016 at 20:38, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>>> > On 18 February 2016 at 19:27, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>>> >> On 18 February 2016 at 19:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
>>> >>> On Tue, Feb 16, 2016 at 01:52:31PM +0100, Ard Biesheuvel wrote:
>>> >>>> Ard Biesheuvel (11):
>>> >>>>   of/fdt: make memblock minimum physical address arch configurable
>>> >>>>   of/fdt: factor out assignment of initrd_start/initrd_end
>>> >>>>   arm64: prevent potential circular header dependencies in asm/bug.h
>>> >>>>   arm64: add support for ioremap() block mappings
>>> >>>>   arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
>>> >>>>   arm64: pgtable: implement static [pte|pmd|pud]_offset variants
>>> >>>>   arm64: decouple early fixmap init from linear mapping
>>> >>>>   arm64: kvm: deal with kernel symbols outside of linear mapping
>>> >>>>   arm64: move kernel image to base of vmalloc area
>>> >>>>   arm64: defer __va translation of initrd_start and initrd_end
>>> >>>>   arm64: allow kernel Image to be loaded anywhere in physical memory
>>> >>>
>>> >>> I queued this patches (again) for 4.6. I'll wait a few days with the
>>> >>> rest of KASLR until these get a bit more coverage in -next.
>>> >>>
>>> >
>>> > I rebased the remaining patches onto for-next/core, and pushed it here:
>>> > https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-kaslr-v6
>>> >
>>> > I need to check if everything still works, and if it does, I will send
>>> > them out as v6sub2
>>> > Note that I have included the arm64 extable patch plus its generic
>>> > dependency, and the kallsyms patches as well. We can decide later how
>>> > to proceed with those, but for now, I included them for completeness.
>>>
>>> OK, as it turns out, my arm64/extable patch conflicts with the UAO
>>> patches that are now in for-next/core, not textually, but those
>>> patches add additional absolute extable entries that need to be
>>> updated to relative as well.
>>
>> I noticed this as well while testing KASLR.
>>
>>> So it appears that akpm will need to drop that patch anyway, as he
>>> won't be able to carry an updated version since he does not have the
>>> UAO patches. That means it probably makes even more sense to take
>>> those through the arm64 tree as well (minus the x86 one, which has a
>>> conflict now as well). In fact, perhaps it makes sense to only take
>>> the base patch and the arm64 patch, and I can send the remaining ones
>>> to the various maintainers (or akpm) for v4.7
>>
>> Or we make BUILDTIME_EXTABLE_SORT depend on !RANDOMIZE_BASE until we
>> sort out the extable patches.
>>
>
> That would still result in breakage once the current version queued by
> akpm hits mainline.

... or in other words, the breakage is already in -next. This is
completely unrelated to the sorting, btw, but due to the difference
between relative/absolute


From will.deacon at arm.com  Fri Feb 19 06:30:31 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 19 Feb 2016 14:30:31 +0000
Subject: [PATCH v4.1] arm64: perf: Count EL2 events if the kernel is
 running in HYP
In-Reply-To: <1455731859-26690-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-22-git-send-email-marc.zyngier@arm.com>
 <1455731859-26690-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160219143031.GI27062@arm.com>

On Wed, Feb 17, 2016 at 05:57:39PM +0000, Marc Zyngier wrote:
> When the kernel is running in HYP (with VHE), it is necessary to
> include EL2 events if the user requests counting kernel or
> hypervisor events.
> 
> Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
> Acked-by: Catalin Marinas <catalin.marinas at arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kernel/perf_event.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Acked-by: Will Deacon <will.deacon at arm.com>

Will


From will.deacon at arm.com  Fri Feb 19 06:30:45 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 19 Feb 2016 14:30:45 +0000
Subject: [PATCH v4.1] arm64: hw_breakpoint: Allow EL2 breakpoints if
 running in HYP
In-Reply-To: <1455731923-26768-1-git-send-email-marc.zyngier@arm.com>
References: <1455216004-19499-23-git-send-email-marc.zyngier@arm.com>
 <1455731923-26768-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160219143045.GJ27062@arm.com>

On Wed, Feb 17, 2016 at 05:58:43PM +0000, Marc Zyngier wrote:
> With VHE, we place kernel {watch,break}-points at EL2 to get things
> like kgdb and "perf -e mem:..." working.
> 
> This requires a bit of repainting in the low-level encore/decode,
> but is otherwise pretty simple.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/hw_breakpoint.h | 18 +++++++++++++-----
>  1 file changed, 13 insertions(+), 5 deletions(-)

Acked-by: Will Deacon <will.deacon at arm.com>

Will


From catalin.marinas at arm.com  Fri Feb 19 06:37:01 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Feb 2016 14:37:01 +0000
Subject: [PATCH v6sub1 00/11] arm64: split linear and kernel mappings
In-Reply-To: <CAKv+Gu9WTVrYmc7GwxDeHppSHoRmSS4nK5iG3HZVMOPcPP1MOw@mail.gmail.com>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160218182509.GG2538@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_UqoYB5QAWOU9_iZDoRO=rqHu8o87JboSAqNqOhoOCXw@mail.gmail.com>
 <CAKv+Gu_25mz37gdgVx5Yz7DJ+QbOMNa4rYBymFL1nL7nGOzBVQ@mail.gmail.com>
 <CAKv+Gu8aKDtev2LdGMy9a485Z8S7TYgsbXky6wR6e3F+j2nkUQ@mail.gmail.com>
 <20160219142551.GA12864@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_44=2NMuon694T_YW6QUU-ixC+q_7WxbMtBuN3dRNP2Q@mail.gmail.com>
 <CAKv+Gu9WTVrYmc7GwxDeHppSHoRmSS4nK5iG3HZVMOPcPP1MOw@mail.gmail.com>
Message-ID: <20160219143701.GB12864@e104818-lin.cambridge.arm.com>

On Fri, Feb 19, 2016 at 03:29:13PM +0100, Ard Biesheuvel wrote:
> On 19 February 2016 at 15:27, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> > On 19 February 2016 at 15:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> On Fri, Feb 19, 2016 at 09:05:25AM +0100, Ard Biesheuvel wrote:
> >>> So it appears that akpm will need to drop that patch anyway, as he
> >>> won't be able to carry an updated version since he does not have the
> >>> UAO patches. That means it probably makes even more sense to take
> >>> those through the arm64 tree as well (minus the x86 one, which has a
> >>> conflict now as well). In fact, perhaps it makes sense to only take
> >>> the base patch and the arm64 patch, and I can send the remaining ones
> >>> to the various maintainers (or akpm) for v4.7
> >>
> >> Or we make BUILDTIME_EXTABLE_SORT depend on !RANDOMIZE_BASE until we
> >> sort out the extable patches.
> >
> > That would still result in breakage once the current version queued by
> > akpm hits mainline.
> 
> ... or in other words, the breakage is already in -next. This is
> completely unrelated to the sorting, btw, but due to the difference
> between relative/absolute

Ah, I now realised that it was only working fine for me before merging
the EFI patches to actually do the base randomisation. Once we fully
randomise the load address, we must have relative extable.

Is your branch updated with the patches needed for arm64 (against
for-next/core)?

-- 
Catalin


From ard.biesheuvel at linaro.org  Fri Feb 19 06:40:32 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 19 Feb 2016 15:40:32 +0100
Subject: [PATCH v6sub1 00/11] arm64: split linear and kernel mappings
In-Reply-To: <20160219143701.GB12864@e104818-lin.cambridge.arm.com>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160218182509.GG2538@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_UqoYB5QAWOU9_iZDoRO=rqHu8o87JboSAqNqOhoOCXw@mail.gmail.com>
 <CAKv+Gu_25mz37gdgVx5Yz7DJ+QbOMNa4rYBymFL1nL7nGOzBVQ@mail.gmail.com>
 <CAKv+Gu8aKDtev2LdGMy9a485Z8S7TYgsbXky6wR6e3F+j2nkUQ@mail.gmail.com>
 <20160219142551.GA12864@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_44=2NMuon694T_YW6QUU-ixC+q_7WxbMtBuN3dRNP2Q@mail.gmail.com>
 <CAKv+Gu9WTVrYmc7GwxDeHppSHoRmSS4nK5iG3HZVMOPcPP1MOw@mail.gmail.com>
 <20160219143701.GB12864@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu-3y9LoxM9swbwZuXXxuMppnWzd=PmyALa+P0NhvR7mtw@mail.gmail.com>

On 19 February 2016 at 15:37, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Fri, Feb 19, 2016 at 03:29:13PM +0100, Ard Biesheuvel wrote:
>> On 19 February 2016 at 15:27, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>> > On 19 February 2016 at 15:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> >> On Fri, Feb 19, 2016 at 09:05:25AM +0100, Ard Biesheuvel wrote:
>> >>> So it appears that akpm will need to drop that patch anyway, as he
>> >>> won't be able to carry an updated version since he does not have the
>> >>> UAO patches. That means it probably makes even more sense to take
>> >>> those through the arm64 tree as well (minus the x86 one, which has a
>> >>> conflict now as well). In fact, perhaps it makes sense to only take
>> >>> the base patch and the arm64 patch, and I can send the remaining ones
>> >>> to the various maintainers (or akpm) for v4.7
>> >>
>> >> Or we make BUILDTIME_EXTABLE_SORT depend on !RANDOMIZE_BASE until we
>> >> sort out the extable patches.
>> >
>> > That would still result in breakage once the current version queued by
>> > akpm hits mainline.
>>
>> ... or in other words, the breakage is already in -next. This is
>> completely unrelated to the sorting, btw, but due to the difference
>> between relative/absolute
>
> Ah, I now realised that it was only working fine for me before merging
> the EFI patches to actually do the base randomisation. Once we fully
> randomise the load address, we must have relative extable.
>
> Is your branch updated with the patches needed for arm64 (against
> for-next/core)?
>

Yes. I dropped the kallsyms patches, and included only the base and
arm64 extable patches, with the UAO issue fixed.

https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-kaslr-v6
git://git.linaro.org/people/ard.biesheuvel/linux-arm.git arm64-kaslr-v6


From Chris.Brandt at renesas.com  Fri Feb 19 06:46:36 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Fri, 19 Feb 2016 14:46:36 +0000
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <2413859.DaWDFlIaaB@wuerfel>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
 <3461274.sjccN4r7lq@wuerfel>
 <HK2PR06MB0561F8D4A17AAEFEBD774E478AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
 <2413859.DaWDFlIaaB@wuerfel>
Message-ID: <HK2PR06MB05613CF6C996BF8BD459842E8AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>

On 19 Feb 2016, Arnd Bergmann wrote:

> > A car with the best seat belts and airbags still won't help you
> > if you drive it off a cliff.
> 
> That was my point about DEBUG_LL: We already allow picking a DEBUG_LL
> option that immediately breaks booting on any other platform, and
> (worse) breaks even printing any useful output about that fact.

Ya, the DEBUG_LL issue seems like it could be an endless hole of options all throughout the Kconfigs.

DT was supposed to allow everything to be configured at boot time, but it looks like we still need an early-Device-Tree for settings before DT is available. That would solve your DEBUG_LL and PHYS_OFFSET issue.


> Even allowing XIP_KERNEL unconditionally doesn't make it much worse.
> 
> Other options that are able to ruin your day are CONFIG_CPU_BIG_ENDIAN
> (which breaks all user space when changed) and CONFIG_ARM_LPAE (which
> breaks booting on Cortex-A8/A9/A5 systems), or simply disabling essential
> drivers like your console or the block device for your rootfs.
> 
> 	Arnd
>

Yup. As I said...car...vroom vroom...cliff.

(to be humble, I've driven off that cliff before and spent hours trying to figure out what happened)



Chris



From marc.zyngier at arm.com  Fri Feb 19 06:47:29 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Feb 2016 14:47:29 +0000
Subject: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI
 on Marvell 7K/8K
In-Reply-To: <20160219142848.GA958@io.lakedaemon.net>
References: <1455888883-5127-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <56C72392.5010202@arm.com> <20160219142848.GA958@io.lakedaemon.net>
Message-ID: <56C72B01.4060005@arm.com>

On 19/02/16 14:28, Jason Cooper wrote:
> On Fri, Feb 19, 2016 at 02:15:46PM +0000, Marc Zyngier wrote:
>> On 19/02/16 13:34, Thomas Petazzoni wrote:
>>> This commits adds a new irqchip driver that handles the ODMI
>>> controller found on Marvell 7K/8K processors. The ODMI controller
>>> provide MSI interrupt functionality to on-board peripherals, much like
>>> the GIC-v2m.
>>>
>>> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
>>> ---
>>> Changes v2 -> v2:
>>>  - Express NODMIS_SHIFT, NODMIS_PER_FRAME, NODMIS_MASK in term of each
>>>    other. Suggested by Marc Zyngier.
>>>  - Rework the global bitmask allocation to make sure we allocate a
>>>    number of longs rather than a number of bytes, to avoid having the
>>>    bitmap API (which operates on longs) access memory we haven't
>>>    explicitly allocated. Reported by Marc Zyngier.
>>>
>>> Changes v1 -> v2:
>>>  - Better commit title, as suggested by Marc Zyngier.
>>>  - Improve the DT binding documentation, as suggested by Marc Zingier:
>>>    add a reference to the GIC documentation, be more specific about
>>>    the marvell,spi-base values, and add the requirement of the
>>>    interrupt-parent property.
>>>  - As suggested by Marc Zyngier, use a single global bitmap to
>>>    allocate all ODMIs, regardless of the frame they belong to. As part
>>>    of this change, the hwirq used to identify the interrupt inside the
>>>    ODMI irqdomain are 0-based (instead of being based on their
>>>    corresponding SPI base value), which allows to significantly
>>>    simplify the allocation/free logic.
>>> ---
>>>  .../marvell,odmi-controller.txt                    |  41 ++++
>>>  drivers/irqchip/Kconfig                            |   4 +
>>>  drivers/irqchip/Makefile                           |   1 +
>>>  drivers/irqchip/irq-mvebu-odmi.c                   | 248 +++++++++++++++++++++
>>>  4 files changed, 294 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
>>>  create mode 100644 drivers/irqchip/irq-mvebu-odmi.c
>>
>> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
>>
>> I'll queue that for 4.6.
> 
> I had it on my list to queue up, but you beat me to it.  :-)

Ah, sorry! The reason I was eager to queue it is because I have some
related changes in the GIC/GICv2m department, simplifying a few things
there:

http://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/gic-4.6&id=9b29f74f6b4b56aa4bb5cc91474aa2451de5c628

I'll post this on the list later today.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From ludovic.desroches at atmel.com  Fri Feb 19 06:48:15 2016
From: ludovic.desroches at atmel.com (Ludovic Desroches)
Date: Fri, 19 Feb 2016 15:48:15 +0100
Subject: [PATCH] ARM: at91/dt: fix typo in sama5d2 pinmux descriptions
Message-ID: <1455893301-1760-1-git-send-email-ludovic.desroches@atmel.com>

PIN_PA15 macro has the same value as PIN_PA14 so we were overriding PA14
mux/configuration.

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
Reported-by: Cyrille Pitchen <cyrille.pitchen at atmel.com>
Fixes: 7f16cb676c00 ("ARM: at91/dt: add sama5d2 pinmux")
Cc: stable at vger.kernel.org #4.4 and later
---
 arch/arm/boot/dts/sama5d2-pinfunc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sama5d2-pinfunc.h b/arch/arm/boot/dts/sama5d2-pinfunc.h
index 1afe246..b0c912fe 100644
--- a/arch/arm/boot/dts/sama5d2-pinfunc.h
+++ b/arch/arm/boot/dts/sama5d2-pinfunc.h
@@ -90,7 +90,7 @@
 #define PIN_PA14__I2SC1_MCK		PINMUX_PIN(PIN_PA14, 4, 2)
 #define PIN_PA14__FLEXCOM3_IO2		PINMUX_PIN(PIN_PA14, 5, 1)
 #define PIN_PA14__D9			PINMUX_PIN(PIN_PA14, 6, 2)
-#define PIN_PA15			14
+#define PIN_PA15			15
 #define PIN_PA15__GPIO			PINMUX_PIN(PIN_PA15, 0, 0)
 #define PIN_PA15__SPI0_MOSI		PINMUX_PIN(PIN_PA15, 1, 1)
 #define PIN_PA15__TF1			PINMUX_PIN(PIN_PA15, 2, 1)
-- 
2.5.0



From jason at lakedaemon.net  Fri Feb 19 06:50:26 2016
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 19 Feb 2016 14:50:26 +0000
Subject: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI
 on Marvell 7K/8K
In-Reply-To: <56C72B01.4060005@arm.com>
References: <1455888883-5127-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <56C72392.5010202@arm.com> <20160219142848.GA958@io.lakedaemon.net>
 <56C72B01.4060005@arm.com>
Message-ID: <20160219145026.GC958@io.lakedaemon.net>

On Fri, Feb 19, 2016 at 02:47:29PM +0000, Marc Zyngier wrote:
> On 19/02/16 14:28, Jason Cooper wrote:
> > On Fri, Feb 19, 2016 at 02:15:46PM +0000, Marc Zyngier wrote:
> >> On 19/02/16 13:34, Thomas Petazzoni wrote:
> >>> This commits adds a new irqchip driver that handles the ODMI
> >>> controller found on Marvell 7K/8K processors. The ODMI controller
> >>> provide MSI interrupt functionality to on-board peripherals, much like
> >>> the GIC-v2m.
> >>>
> >>> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> >>> ---
> >>> Changes v2 -> v2:
> >>>  - Express NODMIS_SHIFT, NODMIS_PER_FRAME, NODMIS_MASK in term of each
> >>>    other. Suggested by Marc Zyngier.
> >>>  - Rework the global bitmask allocation to make sure we allocate a
> >>>    number of longs rather than a number of bytes, to avoid having the
> >>>    bitmap API (which operates on longs) access memory we haven't
> >>>    explicitly allocated. Reported by Marc Zyngier.
> >>>
> >>> Changes v1 -> v2:
> >>>  - Better commit title, as suggested by Marc Zyngier.
> >>>  - Improve the DT binding documentation, as suggested by Marc Zingier:
> >>>    add a reference to the GIC documentation, be more specific about
> >>>    the marvell,spi-base values, and add the requirement of the
> >>>    interrupt-parent property.
> >>>  - As suggested by Marc Zyngier, use a single global bitmap to
> >>>    allocate all ODMIs, regardless of the frame they belong to. As part
> >>>    of this change, the hwirq used to identify the interrupt inside the
> >>>    ODMI irqdomain are 0-based (instead of being based on their
> >>>    corresponding SPI base value), which allows to significantly
> >>>    simplify the allocation/free logic.
> >>> ---
> >>>  .../marvell,odmi-controller.txt                    |  41 ++++
> >>>  drivers/irqchip/Kconfig                            |   4 +
> >>>  drivers/irqchip/Makefile                           |   1 +
> >>>  drivers/irqchip/irq-mvebu-odmi.c                   | 248 +++++++++++++++++++++
> >>>  4 files changed, 294 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
> >>>  create mode 100644 drivers/irqchip/irq-mvebu-odmi.c
> >>
> >> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
> >>
> >> I'll queue that for 4.6.
> > 
> > I had it on my list to queue up, but you beat me to it.  :-)
> 
> Ah, sorry! The reason I was eager to queue it is because I have some
> related changes in the GIC/GICv2m department, simplifying a few things
> there:
> 
> http://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/gic-4.6&id=9b29f74f6b4b56aa4bb5cc91474aa2451de5c628
> 
> I'll post this on the list later today.

ah, no problem.  Whichever is easiest for you.  Just let me know.

thx,

Jason.


From catalin.marinas at arm.com  Fri Feb 19 06:57:17 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Feb 2016 14:57:17 +0000
Subject: [PATCH v6sub1 00/11] arm64: split linear and kernel mappings
In-Reply-To: <CAKv+Gu-3y9LoxM9swbwZuXXxuMppnWzd=PmyALa+P0NhvR7mtw@mail.gmail.com>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160218182509.GG2538@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_UqoYB5QAWOU9_iZDoRO=rqHu8o87JboSAqNqOhoOCXw@mail.gmail.com>
 <CAKv+Gu_25mz37gdgVx5Yz7DJ+QbOMNa4rYBymFL1nL7nGOzBVQ@mail.gmail.com>
 <CAKv+Gu8aKDtev2LdGMy9a485Z8S7TYgsbXky6wR6e3F+j2nkUQ@mail.gmail.com>
 <20160219142551.GA12864@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_44=2NMuon694T_YW6QUU-ixC+q_7WxbMtBuN3dRNP2Q@mail.gmail.com>
 <CAKv+Gu9WTVrYmc7GwxDeHppSHoRmSS4nK5iG3HZVMOPcPP1MOw@mail.gmail.com>
 <20160219143701.GB12864@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-3y9LoxM9swbwZuXXxuMppnWzd=PmyALa+P0NhvR7mtw@mail.gmail.com>
Message-ID: <20160219145716.GC12864@e104818-lin.cambridge.arm.com>

On Fri, Feb 19, 2016 at 03:40:32PM +0100, Ard Biesheuvel wrote:
> On 19 February 2016 at 15:37, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Fri, Feb 19, 2016 at 03:29:13PM +0100, Ard Biesheuvel wrote:
> >> On 19 February 2016 at 15:27, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> >> > On 19 February 2016 at 15:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> >> On Fri, Feb 19, 2016 at 09:05:25AM +0100, Ard Biesheuvel wrote:
> >> >>> So it appears that akpm will need to drop that patch anyway, as he
> >> >>> won't be able to carry an updated version since he does not have the
> >> >>> UAO patches. That means it probably makes even more sense to take
> >> >>> those through the arm64 tree as well (minus the x86 one, which has a
> >> >>> conflict now as well). In fact, perhaps it makes sense to only take
> >> >>> the base patch and the arm64 patch, and I can send the remaining ones
> >> >>> to the various maintainers (or akpm) for v4.7
> >> >>
> >> >> Or we make BUILDTIME_EXTABLE_SORT depend on !RANDOMIZE_BASE until we
> >> >> sort out the extable patches.
> >> >
> >> > That would still result in breakage once the current version queued by
> >> > akpm hits mainline.
> >>
> >> ... or in other words, the breakage is already in -next. This is
> >> completely unrelated to the sorting, btw, but due to the difference
> >> between relative/absolute
> >
> > Ah, I now realised that it was only working fine for me before merging
> > the EFI patches to actually do the base randomisation. Once we fully
> > randomise the load address, we must have relative extable.
> >
> > Is your branch updated with the patches needed for arm64 (against
> > for-next/core)?
> 
> Yes. I dropped the kallsyms patches, and included only the base and
> arm64 extable patches, with the UAO issue fixed.
> 
> https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-kaslr-v6
> git://git.linaro.org/people/ard.biesheuvel/linux-arm.git arm64-kaslr-v6

Thanks, I'll give it a try.

-- 
Catalin


From marc.zyngier at arm.com  Fri Feb 19 07:00:29 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Fri, 19 Feb 2016 15:00:29 +0000
Subject: [PATCH] irqchip/gic: Return IRQ_SET_MASK_OK_DONE in the set_affinity
 method
Message-ID: <1455894029-17270-1-git-send-email-marc.zyngier@arm.com>

Moving an SPI around doesn't require any extra work from the rest
of the stack, and specially not for MSI-generated SPIs.

It is then worth returning IRQ_SET_MASK_OK_DONE instead of
IRQ_SET_MASK_OK, and simplify the other irqchips that rely on
this behaviour (GICv2m and Marvell's ODMI controller).

Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 drivers/irqchip/irq-gic-v2m.c    | 14 +-------------
 drivers/irqchip/irq-gic.c        |  2 +-
 drivers/irqchip/irq-mvebu-odmi.c | 14 +-------------
 3 files changed, 3 insertions(+), 27 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v2m.c b/drivers/irqchip/irq-gic-v2m.c
index c779f83..28f047c 100644
--- a/drivers/irqchip/irq-gic-v2m.c
+++ b/drivers/irqchip/irq-gic-v2m.c
@@ -92,18 +92,6 @@ static struct msi_domain_info gicv2m_msi_domain_info = {
 	.chip	= &gicv2m_msi_irq_chip,
 };
 
-static int gicv2m_set_affinity(struct irq_data *irq_data,
-			       const struct cpumask *mask, bool force)
-{
-	int ret;
-
-	ret = irq_chip_set_affinity_parent(irq_data, mask, force);
-	if (ret == IRQ_SET_MASK_OK)
-		ret = IRQ_SET_MASK_OK_DONE;
-
-	return ret;
-}
-
 static void gicv2m_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
 {
 	struct v2m_data *v2m = irq_data_get_irq_chip_data(data);
@@ -122,7 +110,7 @@ static struct irq_chip gicv2m_irq_chip = {
 	.irq_mask		= irq_chip_mask_parent,
 	.irq_unmask		= irq_chip_unmask_parent,
 	.irq_eoi		= irq_chip_eoi_parent,
-	.irq_set_affinity	= gicv2m_set_affinity,
+	.irq_set_affinity	= irq_chip_set_affinity_parent,
 	.irq_compose_msi_msg	= gicv2m_compose_msi_msg,
 };
 
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 8f9ebf7..282344b 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -319,7 +319,7 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
 	writel_relaxed(val | bit, reg);
 	raw_spin_unlock_irqrestore(&irq_controller_lock, flags);
 
-	return IRQ_SET_MASK_OK;
+	return IRQ_SET_MASK_OK_DONE;
 }
 #endif
 
diff --git a/drivers/irqchip/irq-mvebu-odmi.c b/drivers/irqchip/irq-mvebu-odmi.c
index 0ae98b2..b4d3678 100644
--- a/drivers/irqchip/irq-mvebu-odmi.c
+++ b/drivers/irqchip/irq-mvebu-odmi.c
@@ -47,18 +47,6 @@ static unsigned int odmis_count;
 /* Protects odmis_bm */
 static DEFINE_SPINLOCK(odmis_bm_lock);
 
-static int odmi_set_affinity(struct irq_data *d,
-			     const struct cpumask *mask, bool force)
-{
-	int ret;
-
-	ret = irq_chip_set_affinity_parent(d, mask, force);
-	if (ret == IRQ_SET_MASK_OK)
-		ret = IRQ_SET_MASK_OK_DONE;
-
-	return ret;
-}
-
 static void odmi_compose_msi_msg(struct irq_data *d, struct msi_msg *msg)
 {
 	struct odmi_data *odmi;
@@ -83,7 +71,7 @@ static struct irq_chip odmi_irq_chip = {
 	.irq_mask		= irq_chip_mask_parent,
 	.irq_unmask		= irq_chip_unmask_parent,
 	.irq_eoi		= irq_chip_eoi_parent,
-	.irq_set_affinity	= odmi_set_affinity,
+	.irq_set_affinity	= irq_chip_set_affinity_parent,
 	.irq_compose_msi_msg	= odmi_compose_msi_msg,
 };
 
-- 
2.1.4



From thomas.petazzoni at free-electrons.com  Fri Feb 19 07:06:32 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 19 Feb 2016 16:06:32 +0100
Subject: [PATCH] irqchip/gic: Return IRQ_SET_MASK_OK_DONE in the
 set_affinity method
In-Reply-To: <1455894029-17270-1-git-send-email-marc.zyngier@arm.com>
References: <1455894029-17270-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160219160632.1947d1a2@free-electrons.com>

Marc,

On Fri, 19 Feb 2016 15:00:29 +0000, Marc Zyngier wrote:
> Moving an SPI around doesn't require any extra work from the rest
> of the stack, and specially not for MSI-generated SPIs.
> 
> It is then worth returning IRQ_SET_MASK_OK_DONE instead of
> IRQ_SET_MASK_OK, and simplify the other irqchips that rely on
> this behaviour (GICv2m and Marvell's ODMI controller).
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  drivers/irqchip/irq-gic-v2m.c    | 14 +-------------
>  drivers/irqchip/irq-gic.c        |  2 +-
>  drivers/irqchip/irq-mvebu-odmi.c | 14 +-------------
>  3 files changed, 3 insertions(+), 27 deletions(-)

For the irq-mvebu-odmi part:

Acked-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From arnd at arndb.de  Fri Feb 19 07:06:40 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 16:06:40 +0100
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <HK2PR06MB05613CF6C996BF8BD459842E8AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
 <2413859.DaWDFlIaaB@wuerfel>
 <HK2PR06MB05613CF6C996BF8BD459842E8AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
Message-ID: <3699765.F7sfuMCyKT@wuerfel>

On Friday 19 February 2016 14:46:36 Chris Brandt wrote:
> On 19 Feb 2016, Arnd Bergmann wrote:
> 
> > > A car with the best seat belts and airbags still won't help you
> > > if you drive it off a cliff.
> > 
> > That was my point about DEBUG_LL: We already allow picking a DEBUG_LL
> > option that immediately breaks booting on any other platform, and
> > (worse) breaks even printing any useful output about that fact.
> 
> Ya, the DEBUG_LL issue seems like it could be an endless hole of options
> all throughout the Kconfigs.
> 
> DT was supposed to allow everything to be configured at boot time, but
> it looks like we still need an early-Device-Tree for settings before DT
> is available. That would solve your DEBUG_LL and PHYS_OFFSET issue.

Not really: for DEBUG_LL, it doesn't work because DEBUG_LL is literally
meant to work from the first instruction in the kernel, so there can't
be any code to configure it. If you don't need to go that low-level,
you should use "earlycon", which can parse the DT just fine.

For PHYS_OFFSET, parsing the DT doesn't help at all because we only
need it for XIP_KERNEL (more or less at least) which cannot patch
the kernel image at boot time, so knowing that the address is wrong
also doesn't help you.

	Arnd


From antoine.tenart at free-electrons.com  Fri Feb 19 07:22:42 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Fri, 19 Feb 2016 16:22:42 +0100
Subject: [PATCH v3 0/7] irqchip: introduce the Alpine MSIX driver
Message-ID: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>

Hi all,

This series introduce the Alpine MSIX driver, and enables it in both
the Alpine v1 and Alpine v2 device trees.

This series depends on "[PATCH v2 0/3] arm64: introduce the Alpine support":
https://lkml.org/lkml/2016/2/10/83

You can find the series at:
https://github.com/atenart/linux.git 4.5-rc1/alpinev2-msix

Antoine

Since v2:
  - Updated the documentation (added a reference to the GIC documentation).

Since v1:
  - Added an interrupt-parent property in the documentation example.
  - Updated to use bitmap_*() instead of *_bit().
  - Removed the static irq_set_affinity to use irq_chip_set_affinity_parent().
  - Updated the address field to use phys_addr_t.
  - Added a comment on why we're setting bit 16 in the address.
  - Patched the gic_set_affinity() function in irqchip/gic-v3.

Antoine Tenart (7):
  irqchip/gic-v3: always return IRQ_SET_MASK_OK_DONE in gic_set_affinity
  irqchip: add the Alpine MSIX interrupt controller
  Documentation: bindings: document the Alpine MSIX driver
  arm64: dts: alpine: add the MSIX node in the Alpine v2 dtsi
  ARM: dts: alpine: add the MSIX node
  arm64: alpine: select the Alpine MSI controller driver
  arm: alpine: select the Alpine MSI controller driver

 .../interrupt-controller/al,alpine-msix.txt        |  26 ++
 arch/arm/boot/dts/alpine.dtsi                      |  10 +
 arch/arm/mach-alpine/Kconfig                       |   1 +
 arch/arm64/Kconfig.platforms                       |   1 +
 arch/arm64/boot/dts/al/alpine-v2.dtsi              |  10 +
 drivers/irqchip/Kconfig                            |   6 +
 drivers/irqchip/Makefile                           |   1 +
 drivers/irqchip/irq-alpine-msi.c                   | 293 +++++++++++++++++++++
 drivers/irqchip/irq-gic-v3.c                       |   2 +-
 9 files changed, 349 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
 create mode 100644 drivers/irqchip/irq-alpine-msi.c

-- 
2.7.1



From antoine.tenart at free-electrons.com  Fri Feb 19 07:22:46 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Fri, 19 Feb 2016 16:22:46 +0100
Subject: [PATCH v3 4/7] arm64: dts: alpine: add the MSIX node in the Alpine v2
 dtsi
In-Reply-To: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455895369-13187-5-git-send-email-antoine.tenart@free-electrons.com>

Following the addition of the Alpine MSIX controller driver, add the
corresponding node in the Alpine v2 device tree.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 arch/arm64/boot/dts/al/alpine-v2.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/al/alpine-v2.dtsi b/arch/arm64/boot/dts/al/alpine-v2.dtsi
index c021e077343b..5b7bef684256 100644
--- a/arch/arm64/boot/dts/al/alpine-v2.dtsi
+++ b/arch/arm64/boot/dts/al/alpine-v2.dtsi
@@ -139,6 +139,16 @@
 			/* 32 bit non prefetchable memory space */
 			ranges = <0x2000000 0x0 0xfe000000 0x0 0xfe000000 0x0 0x1000000>;
 			bus-range = <0x00 0x00>;
+			msi-parent = <&msix>;
+		};
+
+		msix: msix at fbe00000 {
+			compatible = "al,alpine-msix";
+			reg = <0x0 0xfbe00000 0x0 0x100000>;
+			interrupt-controller;
+			msi-controller;
+			al,msi-base-spi = <160>;
+			al,msi-num-spis = <160>;
 		};
 
 		io-fabric {
-- 
2.7.1



From antoine.tenart at free-electrons.com  Fri Feb 19 07:22:45 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Fri, 19 Feb 2016 16:22:45 +0100
Subject: [PATCH v3 3/7] Documentation: bindings: document the Alpine MSIX
 driver
In-Reply-To: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455895369-13187-4-git-send-email-antoine.tenart@free-electrons.com>

Following the addition of the Alpine MSIX driver, this patch adds the
corresponding bindings documentation.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 .../interrupt-controller/al,alpine-msix.txt        | 26 ++++++++++++++++++++++
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt

diff --git a/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt b/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
new file mode 100644
index 000000000000..f6f1c14bf99b
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
@@ -0,0 +1,26 @@
+Alpine MSIX controller
+
+See arm,gic-v3.txt for SPI and MSI definitions.
+
+Required properties:
+
+- compatible: should be "al,alpine-msix"
+- reg: physical base address and size of the registers
+- interrupt-parent: specifies the parent interrupt controller.
+- interrupt-controller: identifies the node as an interrupt controller
+- msi-controller: identifies the node as an PCI Message Signaled Interrupt
+		  controller
+- al,msi-base-spi: SPI base of the MSI frame
+- al,msi-num-spis: number of SPIs assigned to the MSI frame, relative to SPI0
+
+Example:
+
+msix: msix {
+	compatible = "al,alpine-msix";
+	reg = <0x0 0xfbe00000 0x0 0x100000>;
+	interrupt-parent = <&gic>;
+	interrupt-controller;
+	msi-controller;
+	al,msi-base-spi = <160>;
+	al,msi-num-spis = <160>;
+};
-- 
2.7.1



From antoine.tenart at free-electrons.com  Fri Feb 19 07:22:43 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Fri, 19 Feb 2016 16:22:43 +0100
Subject: [PATCH v3 1/7] irqchip/gic-v3: always return IRQ_SET_MASK_OK_DONE in
 gic_set_affinity
In-Reply-To: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455895369-13187-2-git-send-email-antoine.tenart@free-electrons.com>

Always return IRQ_SET_MASK_OK_DONE instead of IRQ_SET_MASK_OK when the
affinity has been updated. When using stacked irqchips, returning
IRQ_SET_MASK_OK_DONE means skipping all descendant irqchips.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
---
 drivers/irqchip/irq-gic-v3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index d7be6ddc34f6..ca120a99bd5a 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -634,7 +634,7 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
 	else
 		gic_dist_wait_for_rwp();
 
-	return IRQ_SET_MASK_OK;
+	return IRQ_SET_MASK_OK_DONE;
 }
 #else
 #define gic_set_affinity	NULL
-- 
2.7.1



From antoine.tenart at free-electrons.com  Fri Feb 19 07:22:44 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Fri, 19 Feb 2016 16:22:44 +0100
Subject: [PATCH v3 2/7] irqchip: add the Alpine MSIX interrupt controller
In-Reply-To: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455895369-13187-3-git-send-email-antoine.tenart@free-electrons.com>

This patch adds the Alpine MSIX interrupt controller driver.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
---
 drivers/irqchip/Kconfig          |   6 +
 drivers/irqchip/Makefile         |   1 +
 drivers/irqchip/irq-alpine-msi.c | 293 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 300 insertions(+)
 create mode 100644 drivers/irqchip/irq-alpine-msi.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 715923d5236c..f20e5b28eb5f 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -60,6 +60,12 @@ config ARM_VIC_NR
 	  The maximum number of VICs available in the system, for
 	  power management.
 
+config ALPINE_MSI
+	bool
+	depends on PCI && PCI_MSI
+	select GENERIC_IRQ_CHIP
+	select PCI_MSI_IRQ_DOMAIN
+
 config ATMEL_AIC_IRQ
 	bool
 	select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 18caacb60d58..57f68e0eea74 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_IRQCHIP)			+= irqchip.o
 
+obj-$(CONFIG_ALPINE_MSI)		+= irq-alpine-msi.o
 obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2835.o
 obj-$(CONFIG_ARCH_BCM2835)		+= irq-bcm2836.o
 obj-$(CONFIG_ARCH_EXYNOS)		+= exynos-combiner.o
diff --git a/drivers/irqchip/irq-alpine-msi.c b/drivers/irqchip/irq-alpine-msi.c
new file mode 100644
index 000000000000..f8712722a606
--- /dev/null
+++ b/drivers/irqchip/irq-alpine-msi.c
@@ -0,0 +1,293 @@
+/*
+ * Annapurna Labs MSIX support services
+ *
+ * Copyright (C) 2016, Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ *
+ * Antoine Tenart <antoine.tenart at free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/irqchip.h>
+#include <linux/irqchip/arm-gic.h>
+#include <linux/msi.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_pci.h>
+#include <linux/pci.h>
+#include <linux/slab.h>
+
+#include <asm/irq.h>
+#include <asm-generic/msi.h>
+
+/* MSIX message address format: local GIC target */
+#define ALPINE_MSIX_SPI_TARGET_CLUSTER0		BIT(16)
+
+struct alpine_msix_data {
+	spinlock_t msi_map_lock;
+	phys_addr_t addr;
+	u32 spi_first;		/* The SGI number that MSIs start */
+	u32 num_spis;		/* The number of SGIs for MSIs */
+	unsigned long *msi_map;
+};
+
+static void alpine_msix_mask_msi_irq(struct irq_data *d)
+{
+	pci_msi_mask_irq(d);
+	irq_chip_mask_parent(d);
+}
+
+static void alpine_msix_unmask_msi_irq(struct irq_data *d)
+{
+	pci_msi_unmask_irq(d);
+	irq_chip_unmask_parent(d);
+}
+
+static struct irq_chip alpine_msix_irq_chip = {
+	.name			= "MSIx",
+	.irq_mask		= alpine_msix_mask_msi_irq,
+	.irq_unmask		= alpine_msix_unmask_msi_irq,
+	.irq_eoi		= irq_chip_eoi_parent,
+	.irq_set_affinity	= irq_chip_set_affinity_parent,
+};
+
+static int alpine_msix_allocate_sgi(struct alpine_msix_data *priv, int num_req)
+{
+	int first;
+
+	spin_lock(&priv->msi_map_lock);
+
+	first = bitmap_find_next_zero_area(priv->msi_map, priv->num_spis, 0,
+					   num_req, 0);
+	if (first >= priv->num_spis) {
+		spin_unlock(&priv->msi_map_lock);
+		return -ENOSPC;
+	}
+
+	bitmap_set(priv->msi_map, first, num_req);
+
+	spin_unlock(&priv->msi_map_lock);
+
+	return priv->spi_first + first;
+}
+
+static void alpine_msix_free_sgi(struct alpine_msix_data *priv, unsigned sgi,
+				 int num_req)
+{
+	int first = sgi - priv->spi_first;
+
+	spin_lock(&priv->msi_map_lock);
+
+	bitmap_clear(priv->msi_map, first, num_req);
+
+	spin_unlock(&priv->msi_map_lock);
+}
+
+static void alpine_msix_compose_msi_msg(struct irq_data *data,
+					struct msi_msg *msg)
+{
+	struct alpine_msix_data *priv = irq_data_get_irq_chip_data(data);
+	phys_addr_t msg_addr = priv->addr;
+
+	msg_addr |= (data->hwirq << 3);
+
+	msg->address_hi = upper_32_bits(msg_addr);
+	msg->address_lo = lower_32_bits(msg_addr);
+	msg->data = 0;
+}
+
+static struct msi_domain_info alpine_msix_domain_info = {
+	.flags	= MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+		  MSI_FLAG_PCI_MSIX,
+	.chip	= &alpine_msix_irq_chip,
+};
+
+static struct irq_chip middle_irq_chip = {
+	.name			= "alpine_msix_middle",
+	.irq_mask		= irq_chip_mask_parent,
+	.irq_unmask		= irq_chip_unmask_parent,
+	.irq_eoi		= irq_chip_eoi_parent,
+	.irq_set_affinity	= irq_chip_set_affinity_parent,
+	.irq_compose_msi_msg	= alpine_msix_compose_msi_msg,
+};
+
+static int alpine_msix_gic_domain_alloc(struct irq_domain *domain,
+					unsigned int virq, int sgi)
+{
+	struct irq_fwspec fwspec;
+	struct irq_data *d;
+	int ret;
+
+	if (!is_of_node(domain->parent->fwnode))
+		return -EINVAL;
+
+	fwspec.fwnode = domain->parent->fwnode;
+	fwspec.param_count = 3;
+	fwspec.param[0] = 0;
+	fwspec.param[1] = sgi;
+	fwspec.param[2] = IRQ_TYPE_EDGE_RISING;
+
+	ret = irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
+	if (ret)
+		return ret;
+
+	d = irq_domain_get_irq_data(domain->parent, virq);
+	d->chip->irq_set_type(d, IRQ_TYPE_EDGE_RISING);
+
+	return 0;
+}
+
+static int alpine_msix_middle_domain_alloc(struct irq_domain *domain,
+					   unsigned int virq,
+					   unsigned int nr_irqs, void *args)
+{
+	struct alpine_msix_data *priv = domain->host_data;
+	int sgi, err, i;
+
+	sgi = alpine_msix_allocate_sgi(priv, nr_irqs);
+	if (sgi < 0)
+		return sgi;
+
+	for (i = 0; i < nr_irqs; i++) {
+		err = alpine_msix_gic_domain_alloc(domain, virq + i, sgi + i);
+		if (err)
+			goto err_sgi;
+
+		irq_domain_set_hwirq_and_chip(domain, virq + i, sgi + i,
+					      &middle_irq_chip, priv);
+	}
+
+	return 0;
+
+err_sgi:
+	while (--i >= 0)
+		irq_domain_free_irqs_parent(domain, virq, i);
+	alpine_msix_free_sgi(priv, sgi, nr_irqs);
+	return err;
+}
+
+static void alpine_msix_middle_domain_free(struct irq_domain *domain,
+					   unsigned int virq,
+					   unsigned int nr_irqs)
+{
+	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+	struct alpine_msix_data *priv = irq_data_get_irq_chip_data(d);
+
+	irq_domain_free_irqs_parent(domain, virq, nr_irqs);
+	alpine_msix_free_sgi(priv, d->hwirq, nr_irqs);
+}
+
+static const struct irq_domain_ops alpine_msix_middle_domain_ops = {
+	.alloc	= alpine_msix_middle_domain_alloc,
+	.free	= alpine_msix_middle_domain_free,
+};
+
+static int alpine_msix_init_domains(struct alpine_msix_data *priv,
+				    struct device_node *node)
+{
+	struct irq_domain *middle_domain, *msi_domain, *gic_domain;
+	struct device_node *gic_node;
+
+	gic_node = of_irq_find_parent(node);
+	if (!gic_node) {
+		pr_err("Failed to find the GIC node\n");
+		return -ENODEV;
+	}
+
+	gic_domain = irq_find_host(gic_node);
+	if (!gic_domain) {
+		pr_err("Failed to find the GIC domain\n");
+		return -ENXIO;
+	}
+
+	middle_domain = irq_domain_add_tree(NULL,
+					    &alpine_msix_middle_domain_ops,
+					    priv);
+	if (!middle_domain) {
+		pr_err("Failed to create the MSIX middle domain\n");
+		return -ENOMEM;
+	}
+
+	middle_domain->parent = gic_domain;
+
+	msi_domain = pci_msi_create_irq_domain(of_node_to_fwnode(node),
+					       &alpine_msix_domain_info,
+					       middle_domain);
+	if (!msi_domain) {
+		pr_err("Failed to create MSI domain\n");
+		irq_domain_remove(msi_domain);
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+static int alpine_msix_init(struct device_node *node,
+			    struct device_node *parent)
+{
+	struct alpine_msix_data *priv;
+	struct resource res;
+	int ret;
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	spin_lock_init(&priv->msi_map_lock);
+
+	ret = of_address_to_resource(node, 0, &res);
+	if (ret) {
+		pr_err("Failed to allocate resource\n");
+		goto err_priv;
+	}
+
+	/*
+	 * The 20 least significant bits of addr provide direct information
+	 * regarding the interrupt destination.
+	 *
+	 * To select the primary GIC as the target GIC, bits [18:17] must be set
+	 * to 0x0. In this case, bit 16 (SPI_TARGET_CLUSTER0) must be set.
+	 */
+	priv->addr = res.start & GENMASK_ULL(63,20);
+	priv->addr |= ALPINE_MSIX_SPI_TARGET_CLUSTER0;
+
+	if (of_property_read_u32(node, "al,msi-base-spi", &priv->spi_first)) {
+		pr_err("Unable to parse MSI base\n");
+		ret = -EINVAL;
+		goto err_priv;
+	}
+
+	if (of_property_read_u32(node, "al,msi-num-spis", &priv->num_spis)) {
+		pr_err("Unable to parse MSI numbers\n");
+		ret = -EINVAL;
+		goto err_priv;
+	}
+
+	priv->msi_map = kzalloc(sizeof(*priv->msi_map) * BITS_TO_LONGS(priv->num_spis),
+				GFP_KERNEL);
+	if (!priv->msi_map) {
+		ret = -ENOMEM;
+		goto err_priv;
+	}
+
+	pr_debug("Registering %d msixs, starting at %d\n",
+		 priv->num_spis, priv->spi_first);
+
+	ret = alpine_msix_init_domains(priv, node);
+	if (ret)
+		goto err_map;
+
+	return 0;
+
+err_map:
+	kfree(priv->msi_map);
+err_priv:
+	kfree(priv);
+	return ret;
+}
+IRQCHIP_DECLARE(alpine_msix, "al,alpine-msix", alpine_msix_init);
-- 
2.7.1



From antoine.tenart at free-electrons.com  Fri Feb 19 07:22:49 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Fri, 19 Feb 2016 16:22:49 +0100
Subject: [PATCH v3 7/7] arm: alpine: select the Alpine MSI controller driver
In-Reply-To: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455895369-13187-8-git-send-email-antoine.tenart@free-electrons.com>

Select the Alpine MSI controller driver when using an Alpine platform.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 arch/arm/mach-alpine/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-alpine/Kconfig b/arch/arm/mach-alpine/Kconfig
index 5c2d54f59f53..b41838a58ae4 100644
--- a/arch/arm/mach-alpine/Kconfig
+++ b/arch/arm/mach-alpine/Kconfig
@@ -1,6 +1,7 @@
 config ARCH_ALPINE
 	bool "Annapurna Labs Alpine platform"
 	depends on ARCH_MULTI_V7
+	select ALPINE_MSI
 	select ARM_AMBA
 	select ARM_GIC
 	select GENERIC_IRQ_CHIP
-- 
2.7.1



From antoine.tenart at free-electrons.com  Fri Feb 19 07:22:48 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Fri, 19 Feb 2016 16:22:48 +0100
Subject: [PATCH v3 6/7] arm64: alpine: select the Alpine MSI controller driver
In-Reply-To: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455895369-13187-7-git-send-email-antoine.tenart@free-electrons.com>

Select the Alpine MSI controller driver when using an Alpine platform.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index bfbefa3e0dbe..6761e12e5e13 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -2,6 +2,7 @@ menu "Platform selection"
 
 config ARCH_ALPINE
 	bool "Annapurna Labs Alpine platform"
+	select ALPINE_MSI
 	help
 	  This enables support for the Annapurna Labs Alpine
 	  Soc family.
-- 
2.7.1



From antoine.tenart at free-electrons.com  Fri Feb 19 07:22:47 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Fri, 19 Feb 2016 16:22:47 +0100
Subject: [PATCH v3 5/7] ARM: dts: alpine: add the MSIX node
In-Reply-To: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1455895369-13187-6-git-send-email-antoine.tenart@free-electrons.com>

With the newly available MSIX driver for Alpine, add the corresponding
node in the Alpine device tree.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
---
 arch/arm/boot/dts/alpine.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/alpine.dtsi b/arch/arm/boot/dts/alpine.dtsi
index 9af2d60e9a7f..db8752fc480e 100644
--- a/arch/arm/boot/dts/alpine.dtsi
+++ b/arch/arm/boot/dts/alpine.dtsi
@@ -155,6 +155,16 @@
 			ranges = <0x02000000 0x0 0xfe000000 0x0 0xfe000000 0x0 0x1000000>;
 
 			bus-range = <0x00 0x00>;
+			msi-parent = <&msix>;
+		};
+
+		msix: msix at fbe00000 {
+			compatible = "al,alpine-msix";
+			reg = <0x0 0xfbe00000 0x0 0x100000>;
+			interrupt-controller;
+			msi-controller;
+			al,msi-base-spi = <96>;
+			al,msi-num-spis = <64>;
 		};
 	};
 };
-- 
2.7.1



From peter at hurleysoftware.com  Fri Feb 19 07:25:50 2016
From: peter at hurleysoftware.com (Peter Hurley)
Date: Fri, 19 Feb 2016 07:25:50 -0800
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <56C6F19D.7070206@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
 <56C470C5.2080203@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>
 <56C63FB5.2030907@hurleysoftware.com> <56C6F19D.7070206@linaro.org>
Message-ID: <56C733FE.8070308@hurleysoftware.com>

On 02/19/2016 02:42 AM, Aleksey Makarov wrote:
> Hi Peter,
> 
> Thank you for review.
> 
> On 02/19/2016 01:03 AM, Peter Hurley wrote:
>> On 02/17/2016 07:36 PM, Zheng, Lv wrote:
>>> Hi,
>>>
>>>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
>>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>>>> early_acpi_os_unmap_memory()
>>>>
>>>> Hi Lv,
>>>>
>>>> Thank you for review.
>>>>
>>>> On 02/17/2016 05:51 AM, Zheng, Lv wrote:
>>>>
>>>> [..]
>>>>
>>>>>>> early_acpi_os_unmap_memory() is marked as __init because it calls
>>>>>>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is not
>>>> set.
>>>>>>>
>>>>>>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>>>> so it is safe to call early_acpi_os_unmap_memory() from anywhere
>>>>>>>
>>>>>>> We need this function to be non-__init because we need access to
>>>>>>> some tables at unpredictable time--it may be before or after
>>>>>>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port Console
>>>>>>> Redirection) table is needed each time a new console is registered.
>>>>>>> It can be quite early (console_initcall) or when a module is inserted.
>>>>>>> When this table accessed before acpi_gbl_permanent_mmap is set,
>>>>>>> the pointer should be unmapped.  This is exactly what this function
>>>>>>> does.
>>>>>> [Lv Zheng]
>>>>>> Why don't you use another API instead of early_acpi_os_unmap_memory()
>>>> in
>>>>>> case you want to unmap things in any cases.
>>>>>> acpi_os_unmap_memory() should be the one to match this purpose.
>>>>>> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
>>>>
>>>> As far as I understand, there exist two steps in ACPI initialization:
>>>>
>>>> 1. Before acpi_gbl_permanent_mmap is set, tables received with
>>>> acpi_get_table_with_size()
>>>>    are mapped by early_memremap().  If a subsystem gets such a pointer it
>>>> should be unmapped.
>>>>
>>>> 2  After acpi_gbl_permanent_mmap is set this pointer should not be unmapped
>>>> at all.
>>>>
>>> [Lv Zheng] 
>>> This statement is wrong, this should be:
>>> As long as there is a __reference__ to the mapped table, the pointer should not be unmapped.
>>> In fact, we have a series to introduce acpi_put_table() to achieve this.
>>> So your argument is wrong from very first point.
>>>
>>>> That exactly what early_acpi_os_unmap_memory() does--it checks
>>>> acpi_gbl_permanent_mmap.
>>>> If I had used acpi_os_unmap_memory() after acpi_gbl_permanent_mmap had
>>>> been set,
>>>> it would have tried to free that pointer with an oops (actually, I checked that
>>>> and got that oops).
>>>>
>>>> So using acpi_os_unmap_memory() is not an option here, but
>>>> early_acpi_os_unmap_memory()
>>>> match perfectly.
>>> [Lv Zheng] 
>>> I don't think so.
>>> For definition block tables, we know for sure there will always be references, until "Unload" opcode is invoked by the AML interpreter.
>>> But for the data tables, OSPMs should use them in this way:
>>> 1. map the table
>>> 2. parse the table and convert it to OS specific structures
>>> 3. unmap the table
>>> This helps to shrink virtual memory address space usages.
>>>
>>> So from this point of view, all data tables should be unmapped right after being parsed.
>>> Why do you need the map to be persistent in the kernel address space?
>>> You can always map a small table, but what if the table size is very big?
>>>
>>>>
>>>>>> And in fact early_acpi_os_unmap_memory() should be removed.
>>>>
>>>> I don't think so -- I have explained why.  It does different thing.
>>>> Probably it (and/or other functions in that api) should be renamed.
>>>>
>>> [Lv Zheng] 
>>> Just let me ask one more question.
>>> eary_acpi_os_unmap_memory() is not used inside of ACPICA.
>>> How ACPICA can work with just acpi_os_unmap_memory()?
>>> You can check drivers/acpi/tbxxx.c.
>>> Especially: acpi_tb_release_temp_table() and the code invoking it.
>>>
>>>>> [Lv Zheng]
>>>>> One more thing is:
>>>>> If you can't switch your driver to use acpi_os_unmap_memory() instead of
>>>> early_acpi_os_unmap_memory(),
>>>>> then it implies that your driver does have a defect.
>>>>
>>>> I still don't understand what defect, sorry.
>>> [Lv Zheng] 
>>> If you can't ensure this sequence for using the data tables:
>>> 1. map the table
>>> 2. parse the table and convert it to OS specific structure
>>> 3. unmap the table
>>> It implies there is a bug in the driver or a bug in the ACPI subsystem core.
>>
>> Exactly.
>>
>> The central problem here is the way Aleksey is trying to hookup a console.
>>
>> What should be happening in this series is:
>> 1. early map SPCR
>> 2. parse the SPCR table
>> 3. call add_preferred_console() to add the SPCR console to the console table
>> 4. unmap SPCR
> 
> This does not work.  
> 
> SPCR specifies address of the console, but add_preferred_console() accepts
> name of console and its index.  There are no general method to translate address
> to name at such an early stage.


	add_preferred_console(uart, 0, "io,0x3f8,115200");

This will start a console with the 8250 driver. I've already pointed
this out to you in an earlier review. This is what existing firmware
already does.

This is also the method you will use to start an earlycon from the
DBG2 table, by additionally calling setup_earlycon().


> There is another reason why I prefer to parse SPCR each time a console is registered.
> Some consoles can be registered very early in the initialization process and
> we have to be sure add_preferred_console() is called before that.

However, since you're not adding a preferred console until uart driver
loads, there may already be a preferred console selected and running.

This leads to weird issues like duplicated output on the serial console
when an earlycon is disabled by the dummy VGA/FB console then the
serial console starts and reprints the entire boot log on the same
terminal the earlycon already printed.

Better just to parse both the DBG2 and SPCR tables before or at
early param, and add_preferred_consoles then.


> Of course, I could just parse it once and cache the results, but
> this still requires accessing SPCR before acpi_gbl_permanent_mmap
> is set *or* after that.
> 
>> This trivial and unobtrusive method would already have a 8250 console
>> running via SPCR. I've already pointed this out in previous reviews.
>>
>> Further, the above method *will be required anyway* for the DBG2 table to
>> start an earlycon, which I've already pointed out in previous reviews.
>>
>> Then to enable amba-pl011 console via ACPI, add a console match() method
>> similar to the 8250 console match() method, univ8250_console_match().
> 
> So are you suggesting a separate method for each possible console?
> This is not acceptable.

All 1 of them???

The 8250 driver already does this, so no work for you there.

That leaves you needing to write a trivial match() method for just
the amba-pl011 driver.


> Do you suggest making up separate new name (like "uart" for 8250) for each type
> of conosole SPCR can specify?

These are the documented names of the earlycons, which you'll be using
when you add the DGB2 table parsing.


>> FWIW, PCI earlycon + console support was already submitted once before but
>> never picked up by GregKH. I think I'll just grab that and re-submit so
>> you would know what to emit for console options in the add_preferred_console().
> 
> Please do.  Or just send a link to to that submission.

Ok, will dig through and find it.

> Do you mean the Leif Lindholm's patches:

No.

> https://lkml.kernel.org/g/1441716217-23786-1-git-send-email-leif.lindholm at linaro.org
> 
> He did same thing as I did in my v3 exept 1) he parses ACPI tree to match device
> (I just match SPCR against data that struct uart_port already has)
> 2) As you are suggesting, he parses SPCR once at a predefined point in initialization.
> And that's why his submission is RFC: he had troubles with the order of initialization.
> 
> Thank you
> Aleksey Makarov
> 
>> Regards,
>> Peter Hurley
>>
>>
>>>>> There is an early bootup requirement in Linux.
>>>>> Maps acquired during the early stage should be freed by the driver during the
>>>> early stage.
>>>>> And the driver should re-acquire the memory map after booting.
>>>>
>>>> Exactly.  That's why I use early_acpi_os_unmap_memory().  The point is that
>>>> that code can be
>>>> called *before* acpi_gbl_permanent_mmap is set (at early initialization of for
>>>> example 8250 console)
>>>> or *after* acpi_gbl_permanent_mmap is set (at insertion of a module that
>>>> registers a console),
>>>> We just can not tell if the received table pointer should or sould not be freed
>>>> with early_memunmap()
>>>> (actually __acpi_unmap_table() or whatever) without checking
>>>> acpi_gbl_permanent_mmap,
>>>> but that's all too low level.
>>> [Lv Zheng] 
>>> The driver should make sure that:
>>> Map/unmap is paired during early stage.
>>> For late stage, it should be another pair of map/unmap.
>>>
>>>>
>>>> Another option, as you describe, is to get this pointer early, don't free it
>>> [Lv Zheng] 
>>> I mean you should free it early.
>>>
>>>> untill acpi_gbl_permanent_mmap is set, then free it (with
>>>> early_acpi_os_unmap_memory(), that's
>>>> ok because acpi_gbl_permanent_mmap is set in an init code), then get the
>>>> persistent
>>>> pointer to the table.  The problem with it is that we can not just watch
>>>> acpi_gbl_permanent_mmap
>>>> to catch this exact moment.  And also accessing acpi_gbl_permanent_mmap is
>>>> not good as it probably is
>>>> an implementation detail (i. e. too lowlevel) of the ACPI code.
>>>> Or I probably miss what you are suggesting.
>>>>
>>> [Lv Zheng] 
>>> I mean, you should:
>>> During early stage:
>>> acpi_os_map_memory()
>>> Parse the table.
>>> acpi_os_unmap_memory().
>>>
>>>>> This is because, during early bootup stage, there are only limited slots
>>>> available for drivers to map memory.
>>>>> So by changing __init to __ref here, you probably will hide many such defects.
>>>>
>>>> What defects?  This funcions checks acpi_gbl_permanent_mmap.
>>>> BTW, exactly the same thing is done in the beginning of
>>>> acpi_os_unmap_memory() and than's ok,
>>>> that function is __ref.
>>>>
>>>>> And solving issues in this way doesn't seem to be an improvement.
>>>>
>>>> Could you please tell me where I am wrong?  I still don't understand your point.
>>> [Lv Zheng] 
>>> But anyway, the defect should be in ACPI subsystem core.
>>> The cause should be the API itself - acpi_get_table().
>>>
>>> So I agree you can use early_acpi_os_unmap_memory() during the period the root causes are not cleaned up.
>>> But the bottom line is: the driver need to ensure that early_acpi_os_unmap_memory() is always invoked.
>>> As long as you can ensure this, I don't have objections for deploying early_acpi_os_unmap_memory()  for now.
>>>
>>> Thanks and best regards
>>> -Lv
>>>
>>>>
>>>> Thank you
>>>> Aleksey Makarov
>>>>
>>>>>
>>>>> Thanks and best regards
>>>>> -Lv
>>>>>
>>>>>>
>>>>>> Thanks and best regards
>>>>>> -Lv
>>>>>>
>>>>>>>
>>>>>>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
>>>>>>> ---
>>>>>>>  drivers/acpi/osl.c | 6 +++++-
>>>>>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
>>>>>>> index 67da6fb..8a552cd 100644
>>>>>>> --- a/drivers/acpi/osl.c
>>>>>>> +++ b/drivers/acpi/osl.c
>>>>>>> @@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void *virt,
>>>>>>> acpi_size size)
>>>>>>>  }
>>>>>>>  EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
>>>>>>>
>>>>>>> -void __init early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
>>>>>> size)
>>>>>>> +/*
>>>>>>> + * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>>>> + * so it is safe to call early_acpi_os_unmap_memory() from anywhere
>>>>>>> + */
>>>>>>> +void __ref early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
>>>>>> size)
>>>>>>>  {
>>>>>>>  	if (!acpi_gbl_permanent_mmap)
>>>>>>>  		__acpi_unmap_table(virt, size);
>>>>>>> --
>>>>>>> 2.7.1




From arnd at arndb.de  Fri Feb 19 07:34:51 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 16:34:51 +0100
Subject: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values
In-Reply-To: <HK2PR06MB056137892B6F968A8A1008C58AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <3974581.yknKb3tq7o@wuerfel>
 <HK2PR06MB056137892B6F968A8A1008C58AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
Message-ID: <14272873.q312Ii8Axy@wuerfel>

On Friday 19 February 2016 14:29:00 Chris Brandt wrote:
> On 19 Feb 2016, Arnd Bergmann wrote:
> 
> > On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote:
> > > 
> > > Acked-by: Nicolas Pitre <nico at linaro.org>
> > > 
> > > Is there a way to provide a default for defaults?
> > 
> > We could have something like
> > 
> > config PHYS_OFFSET_0
> > 	bool
> > 
> > config PHYS_OFFSET_1
> > 	bool
> > 
> > config PHYS_OFFSET_2
> > 	bool
> > 
> > ... (we need 8 of the 16 possible addresses)
> > 
> > 
> > config PHYS_OFFSET
> > 	hex "Physical address of main memory" if MMU
> > 	default DRAM_BASE if !MMU
> > 	default 0x00000000 if PHYS_OFFSET_0
> > 	default 0x10000000 if PHYS_OFFSET_1
> > 	default 0x20000000 if PHYS_OFFSET_2
> > 	default 0x30000000 if PHYS_OFFSET_3
> > 	default 0x70000000 if PHYS_OFFSET_7
> > 	default 0x80000000 if PHYS_OFFSET_8
> > 	default 0xa0000000 if PHYS_OFFSET_A
> > 	default 0xc0000000 if PHYS_OFFSET_C
> > 
> > 
> > and then select one of the bool symbols from each platform.
> > Would that address your question?
> 
> 
> Here's a question:
> 
> Can we just get rid of PHYS_OFFSET???
> 
> If it's only used at boot for XIP systems, we could:
> 
> A) pass it in via an unused register like atags and DT
>  or
> B) just assume that atags or DT is in RAM, so round down to the nearest section and assume that is the start of your RAM
> 
> If it is needed after initial boot, then on first boot we save what was passed in from the boot loader for later use.

Hmm, you mean making phys_offset a runtime variable instead
of patching it at early boot time in the instructions?

I have no idea if that works, how much effort it would be,
or how much it would enlarge the kernel image size, but
you can definitely try.

Of course we must not break existing platforms using XIP_KERNEL
already, but the installed base among systems that are upgrading
to modern kernels is very small now, given how all modern platforms
don't support XIP_KERNEL today, or have no MMU to start with.

	Arnd


From Chris.Brandt at renesas.com  Fri Feb 19 07:36:23 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Fri, 19 Feb 2016 15:36:23 +0000
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <3699765.F7sfuMCyKT@wuerfel>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
 <2413859.DaWDFlIaaB@wuerfel>
 <HK2PR06MB05613CF6C996BF8BD459842E8AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
 <3699765.F7sfuMCyKT@wuerfel>
Message-ID: <HK2PR06MB05616AAF67B15C7A2BDC4F608AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>

On 19 Feb 2016, Arnd Bergmann wrote:

> For PHYS_OFFSET, parsing the DT doesn't help at all because we only
> need it for XIP_KERNEL (more or less at least) which cannot patch
> the kernel image at boot time, so knowing that the address is wrong
> also doesn't help you.
> 
> 	Arnd

OK, at first I was thinking that PHYS_OFFSET was only used early in boot as a pointer to valid RAM before the DT was read (in head.S and head-nommu.S). Hence, you could pass in the pointer in via another CPU register like the DT pointer is passed in.

But, now I see that PHYS_OFFSET is used all over the place as a hard coded #define, hence your comment "which cannot patch the kernel image at boot time"

So, I retract my thought...it has to be configured at build-time (unless of course you turn it into a global variable everywhere...which might be an even bigger mess)


Chris


From peter.maydell at linaro.org  Fri Feb 19 07:38:44 2016
From: peter.maydell at linaro.org (Peter Maydell)
Date: Fri, 19 Feb 2016 15:38:44 +0000
Subject: [PATCH v2 0/5] arm64: kernel: Add support for User Access Override
In-Reply-To: <20160218180313.GE2538@e104818-lin.cambridge.arm.com>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
 <20160218180313.GE2538@e104818-lin.cambridge.arm.com>
Message-ID: <CAFEAcA9SQjg3GpDpU-Tt8i+JiOcJWQKTNzwLLTC4imiBuiP6+w@mail.gmail.com>

On 18 February 2016 at 18:03, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Fri, Feb 05, 2016 at 02:58:45PM +0000, James Morse wrote:
>> James Morse (5):
>>   arm64: cpufeature: Change read_cpuid() to use sysreg's mrs_s macro
>>   arm64: add ARMv8.2 id_aa64mmfr2 boiler plate
>>   arm64: kernel: Add support for User Access Override
>>   arm64: cpufeature: Test 'matches' pointer to find the end of the list
>>   arm64: kernel: Don't toggle PAN on systems with UAO
>
> Patches applied with an additional fixup on top for removing
> get_thread_info().

Just to let you know, unfortunately this series breaks booting the
kernel on QEMU. We didn't implement the parts of the ID register
space that the ARM ARM documents as "reserved, RAZ", and so when
the kernel touches ID_AA64MMFR2 (new in v8.2) QEMU hands it an
UNDEF. This is obviously a bug in QEMU, and I just sent out a patch
for it: http://patchwork.ozlabs.org/patch/585237/ -- but of course
that doesn't do anything for all the buggy QEMUs already in the field.

This is more of a heads-up than a demand that you Do Something,
but perhaps somebody has a clever idea...

thanks
-- PMM


From peter at hurleysoftware.com  Fri Feb 19 07:46:57 2016
From: peter at hurleysoftware.com (Peter Hurley)
Date: Fri, 19 Feb 2016 07:46:57 -0800
Subject: [PATCH v3 05/10] serial: mps2-uart: add support for early console
In-Reply-To: <CAHp75VcosaVcz_aYbpfL-nUH0kBf72SshXU5k95s48Z3wnA5nQ@mail.gmail.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-6-git-send-email-vladimir.murzin@arm.com>
 <CAHp75VdugAq0WnzLHmd9CJHCjBOdBwPqCmC3ARSaVF5XMYGoMw@mail.gmail.com>
 <56C31F9F.10000@arm.com> <56C6E42E.5070601@arm.com>
 <CAHp75VcosaVcz_aYbpfL-nUH0kBf72SshXU5k95s48Z3wnA5nQ@mail.gmail.com>
Message-ID: <56C738F1.2070307@hurleysoftware.com>

On 02/19/2016 01:57 AM, Andy Shevchenko wrote:
> On Fri, Feb 19, 2016 at 11:45 AM, Vladimir Murzin
> <vladimir.murzin at arm.com> wrote:
>> On 16/02/16 13:09, Vladimir Murzin wrote:
>>>>> +EARLYCON_DECLARE(mps2, mps2_early_console_setup);
>>>>>>> +OF_EARLYCON_DECLARE(mps2, "arm,mps2-uart", mps2_early_console_setup);
>>>>>
>>>>> IIRC Peter Hurley mentioned you don't need to put both anymore, OF_
>>>>> one is enough.
>>>>>
>>> I've just tried with OF_ only and seems it works fine. Thanks for
>>> pointing at it!
>>>
>>
>> ..and the reason for that was that I had stdout pointing at uart node.
>> Now, while testing v4 I end-up with configuration:
>>
>> 1) no EARLYCON_DECLARE in mps2-uart.c
>> 2) stdout not set
>> 3) cmdline has "earlycon=mps2,0x40004000 console=/dev/ttyMPS"
>>
>> and I don't see bootconsole, but if I avoid 1) everything works fine.
>> So, I'd leave EARLYCON_DECLARE in this patch.
> 
> Peter, what is your comment on this?

That Vladimir is not testing with linux-next.

linux-next has common framework for both command line and OF-defined
earlycons.

Vladimir, if you pull in Greg's tty-next branch, then just

OF_EARLYCON_DECLARE(mps2, "arm,mps2-uart", mps2_early_console_setup);

should enable both command-line and OF-defined earlycons.

Regards,
Peter Hurley



From jason at lakedaemon.net  Fri Feb 19 07:57:28 2016
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 19 Feb 2016 15:57:28 +0000
Subject: [PATCH v3] irqchip: irq-mvebu-odmi: new driver for platform MSI
 on Marvell 7K/8K
In-Reply-To: <1455888883-5127-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455888883-5127-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20160219155728.GD958@io.lakedaemon.net>

On Fri, Feb 19, 2016 at 02:34:43PM +0100, Thomas Petazzoni wrote:
> This commits adds a new irqchip driver that handles the ODMI
> controller found on Marvell 7K/8K processors. The ODMI controller
> provide MSI interrupt functionality to on-board peripherals, much like
> the GIC-v2m.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
> Changes v2 -> v2:
>  - Express NODMIS_SHIFT, NODMIS_PER_FRAME, NODMIS_MASK in term of each
>    other. Suggested by Marc Zyngier.
>  - Rework the global bitmask allocation to make sure we allocate a
>    number of longs rather than a number of bytes, to avoid having the
>    bitmap API (which operates on longs) access memory we haven't
>    explicitly allocated. Reported by Marc Zyngier.
> 
> Changes v1 -> v2:
>  - Better commit title, as suggested by Marc Zyngier.
>  - Improve the DT binding documentation, as suggested by Marc Zingier:
>    add a reference to the GIC documentation, be more specific about
>    the marvell,spi-base values, and add the requirement of the
>    interrupt-parent property.
>  - As suggested by Marc Zyngier, use a single global bitmap to
>    allocate all ODMIs, regardless of the frame they belong to. As part
>    of this change, the hwirq used to identify the interrupt inside the
>    ODMI irqdomain are 0-based (instead of being based on their
>    corresponding SPI base value), which allows to significantly
>    simplify the allocation/free logic.
> ---
>  .../marvell,odmi-controller.txt                    |  41 ++++
>  drivers/irqchip/Kconfig                            |   4 +
>  drivers/irqchip/Makefile                           |   1 +
>  drivers/irqchip/irq-mvebu-odmi.c                   | 248 +++++++++++++++++++++
>  4 files changed, 294 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
>  create mode 100644 drivers/irqchip/irq-mvebu-odmi.c

Applied to irqchip/mvebu with Marc's Reviewed-by.

thx,

Jason.


From jason at lakedaemon.net  Fri Feb 19 07:59:41 2016
From: jason at lakedaemon.net (Jason Cooper)
Date: Fri, 19 Feb 2016 15:59:41 +0000
Subject: [PATCH] irqchip/gic: Return IRQ_SET_MASK_OK_DONE in the
 set_affinity method
In-Reply-To: <1455894029-17270-1-git-send-email-marc.zyngier@arm.com>
References: <1455894029-17270-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160219155941.GE958@io.lakedaemon.net>

On Fri, Feb 19, 2016 at 03:00:29PM +0000, Marc Zyngier wrote:
> Moving an SPI around doesn't require any extra work from the rest
> of the stack, and specially not for MSI-generated SPIs.
> 
> It is then worth returning IRQ_SET_MASK_OK_DONE instead of
> IRQ_SET_MASK_OK, and simplify the other irqchips that rely on
> this behaviour (GICv2m and Marvell's ODMI controller).
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  drivers/irqchip/irq-gic-v2m.c    | 14 +-------------
>  drivers/irqchip/irq-gic.c        |  2 +-
>  drivers/irqchip/irq-mvebu-odmi.c | 14 +-------------
>  3 files changed, 3 insertions(+), 27 deletions(-)

Applied to irchip/mvebu with Thomas' (P) Acked-by.

thx,

Jason.


From arnd at arndb.de  Fri Feb 19 07:59:43 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 16:59:43 +0100
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <HK2PR06MB05616AAF67B15C7A2BDC4F608AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
 <3699765.F7sfuMCyKT@wuerfel>
 <HK2PR06MB05616AAF67B15C7A2BDC4F608AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
Message-ID: <64215923.Y25jP5YYZ2@wuerfel>

On Friday 19 February 2016 15:36:23 Chris Brandt wrote:
> On 19 Feb 2016, Arnd Bergmann wrote:
> 
> > For PHYS_OFFSET, parsing the DT doesn't help at all because we only
> > need it for XIP_KERNEL (more or less at least) which cannot patch
> > the kernel image at boot time, so knowing that the address is wrong
> > also doesn't help you.
> > 
> > 	Arnd
> 
> OK, at first I was thinking that PHYS_OFFSET was only used early in boot as a pointer to valid RAM before the DT was read (in head.S and head-nommu.S). Hence, you could pass in the pointer in via another CPU register like the DT pointer is passed in.
> 
> But, now I see that PHYS_OFFSET is used all over the place as a hard coded #define, hence your comment "which cannot patch the kernel image at boot time"
> 
> So, I retract my thought...it has to be configured at build-time (unless of course you turn it into a global variable everywhere...which might be an even bigger mess)
> 

BTW, I've tried removing the patching in CONFIG_PHYS_VIRT and replaced it
with references to __pv_phys_pfn_offset, which surprisingly only grew
.text from 4901692 to 4904300 bytes, so the size overhead of doing this
would be close to zero.

	Arnd


From nicolas.pitre at linaro.org  Fri Feb 19 08:10:22 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 19 Feb 2016 11:10:22 -0500 (EST)
Subject: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values
In-Reply-To: <3974581.yknKb3tq7o@wuerfel>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-5-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602181100410.13632@knanqh.ubzr>
 <3974581.yknKb3tq7o@wuerfel>
Message-ID: <alpine.LFD.2.20.1602191106020.13632@knanqh.ubzr>

On Fri, 19 Feb 2016, Arnd Bergmann wrote:

> On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote:
> > 
> > Acked-by: Nicolas Pitre <nico at linaro.org>
> > 
> > Is there a way to provide a default for defaults?
> 
> We could have something like
> 
> config PHYS_OFFSET_0
> 	bool
> 
> config PHYS_OFFSET_1
> 	bool
> 
> config PHYS_OFFSET_2
> 	bool
> 
> ... (we need 8 of the 16 possible addresses)
> 
> 
> config PHYS_OFFSET
> 	hex "Physical address of main memory" if MMU
> 	default DRAM_BASE if !MMU
> 	default 0x00000000 if PHYS_OFFSET_0
> 	default 0x10000000 if PHYS_OFFSET_1
> 	default 0x20000000 if PHYS_OFFSET_2
> 	default 0x30000000 if PHYS_OFFSET_3
> 	default 0x70000000 if PHYS_OFFSET_7
> 	default 0x80000000 if PHYS_OFFSET_8
> 	default 0xa0000000 if PHYS_OFFSET_A
> 	default 0xc0000000 if PHYS_OFFSET_C
> 
> 
> and then select one of the bool symbols from each platform.
> Would that address your question?

Yes, but the ugliness factor isn't worth it IMHO.

I was wondering if something like this was possible:

config PHYS_OFFSET
        hex "Physical address of main memory" if MMU
        default DRAM_BASE if !MMU
        default 0x10000000 if FOO
        default 0x20000000 if BAR
        default 0x30000000 if BAZ
        default 0x00000000


Nicolas


From peter at hurleysoftware.com  Fri Feb 19 08:13:38 2016
From: peter at hurleysoftware.com (Peter Hurley)
Date: Fri, 19 Feb 2016 08:13:38 -0800
Subject: [PATCH v3 2/5] ACPI: parse SPCR and enable matching console
In-Reply-To: <56C6F2DA.3020002@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-3-git-send-email-aleksey.makarov@linaro.org>
 <56C64366.2070702@hurleysoftware.com> <56C6F2DA.3020002@linaro.org>
Message-ID: <56C73F32.6060701@hurleysoftware.com>

On 02/19/2016 02:47 AM, Aleksey Makarov wrote:
> Hi Peter,
> 
> Thank you for review.
> 
> On 02/19/2016 01:19 AM, Peter Hurley wrote:
>> On 02/15/2016 10:05 AM, Aleksey Makarov wrote:
> 
> [..]
> 
>>> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
>>> index a126a60..459ab54 100644
>>> --- a/drivers/tty/serial/serial_core.c
>>> +++ b/drivers/tty/serial/serial_core.c
>>> @@ -34,6 +34,7 @@
>>>  #include <linux/serial_core.h>
>>>  #include <linux/delay.h>
>>>  #include <linux/mutex.h>
>>> +#include <linux/acpi.h>
>>>  
>>>  #include <asm/irq.h>
>>>  #include <asm/uaccess.h>
>>> @@ -2654,8 +2655,17 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
>>>  		spin_lock_init(&uport->lock);
>>>  		lockdep_set_class(&uport->lock, &port_lock_key);
>>>  	}
>>> -	if (uport->cons && uport->dev)
>>> -		of_console_check(uport->dev->of_node, uport->cons->name, uport->line);
>>> +
>>> +	/*
>>> +	 * Support both open FW and ACPI access to console definitions.
>>> +	 * Both of_console_check() and acpi_console_check() will call
>>> +	 * add_preferred_console() if a console definition is found.
>>> +	 */
>>> +	if (uport->cons && uport->dev) {
>>> +		if (!acpi_console_check(uport))
>>> +			of_console_check(uport->dev->of_node, uport->cons->name,
>>> +					 uport->line);
>>
>> of_console_check() is not a good model for enabling a console.
>> It's a hack with several shortcomings (and bugs) that is tolerated here
>> because of its broad applicability to a wide range of platforms and drivers.
> 
> It's definitely not the best code I saw 

> but there is no bugs.

I pointed out just one of the problems with adding a preferred console
late in the boot cycle (eg, at uart driver load) in the other patch review.


>> I specifically added console matching to enable exactly this kind of
>> console-selection-via-firmware. Please use that facility.
> 
> I described why this does not work (except you insist on having 
> new made up names for all types of SPCR consoles) in the reply to another your message.

They're not "new made up names".

They're the documented names of earlycons, which you'd know if you
researched how you're going to start an earlycon with the DBG2 table
like I suggested in previous reviews.

And I explained in the other patch review exactly how it works.

Regards,
Peter Hurley


>>> +	}
>>>  
>>>  	uart_configure_port(drv, state, uport);
>>>  
>>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>>> index 06ed7e5..ea0c297 100644
>>> --- a/include/linux/acpi.h
>>> +++ b/include/linux/acpi.h
>>> @@ -1004,4 +1004,14 @@ static inline struct fwnode_handle *acpi_get_next_subnode(struct device *dev,
>>>  #define acpi_probe_device_table(t)	({ int __r = 0; __r;})
>>>  #endif
>>>  
>>> +struct uart_port;
>>> +#ifdef CONFIG_ACPI_SPCR_TABLE
>>> +bool acpi_console_check(struct uart_port *uport);
>>> +#else
>>> +static inline bool acpi_console_check(struct uart_port *uport)
>>> +{
>>> +	return FALSE;
>>> +}
>>> +#endif
>>> +
>>>  #endif	/*_LINUX_ACPI_H*/
>>>
>>



From mturquette at baylibre.com  Fri Feb 19 08:18:50 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Fri, 19 Feb 2016 08:18:50 -0800
Subject: [PATCH] clk: gpio: Really allow an optional clock= DT property
In-Reply-To: <1455851525-18972-1-git-send-email-sboyd@codeaurora.org>
References: <20160219030731.GS4847@codeaurora.org>
 <1455851525-18972-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <CAEG3pNAee6e7nnnCB334zecADV58yfcJ5azUjALHaDP40B_pLQ@mail.gmail.com>

On Thu, Feb 18, 2016 at 7:12 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
>
> We mis-merged the original patch from Russell here and so the
> patch went almost all the way, except that we still failed to
> probe when there wasn't a clocks property in the DT node. Allow
> that case by making a negative value from
> of_clk_get_parent_count() into "no parents", like the original
> patch did.
>
> Fixes: 7ed88aa2efa5 ("clk: fix clk-gpio.c with optional clock= DT property")
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> Cc: Michael Turquette <mturquette at baylibre.com>
> Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>

Ack.

Regards,
Mike

> ---
>  drivers/clk/clk-gpio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
> index 19fed65587e8..7b09a265d79f 100644
> --- a/drivers/clk/clk-gpio.c
> +++ b/drivers/clk/clk-gpio.c
> @@ -289,7 +289,7 @@ static void __init of_gpio_clk_setup(struct device_node *node,
>
>         num_parents = of_clk_get_parent_count(node);
>         if (num_parents < 0)
> -               return;
> +               num_parents = 0;
>
>         data = kzalloc(sizeof(*data), GFP_KERNEL);
>         if (!data)
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>



-- 
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/


From arnd at arndb.de  Fri Feb 19 08:19:35 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 17:19:35 +0100
Subject: [PATCH v2] [RFC] ARM: modify pgd_t definition for
 TRANSPARENT_HUGEPAGE_PUD
Message-ID: <1455898786-2720743-1-git-send-email-arnd@arndb.de>

I ran into build errors on ARM after Willy's newly added generic
TRANSPARENT_HUGEPAGE_PUD support. We don't support this feature
on ARM at all, but the patch causes a build error anyway:

In file included from ../kernel/memremap.c:17:0:
../include/linux/pfn_t.h:108:7: error: 'pud_mkdevmap' declared as function returning an array
 pud_t pud_mkdevmap(pud_t pud);

We don't use a PUD on ARM, so pud_t is defined as pmd_t, which
in turn is defined as

typedef unsigned long pgd_t[2];

on NOMMU and on 2-level MMU configurations. There is an (unused)
other definition using a struct around the array, which happens to
work fine here.

There is a comment in the file about the fact the other version
is "easier on the compiler", and I've traced that version back
to linux-2.1.80 when ARM support was first merged back in 1998.

It's probably a safe assumption that this is no longer necessary:
The same logic existed in asm-i386 at the time but was removed
a year later in 2.3.23pre3. The STRICT_MM_TYPECHECKS logic
also ended up getting copied into other architectures, which
use them in various ways:

* both defined, but using strict:
arch/alpha/include/asm/page.h:#define STRICT_MM_TYPECHECKS
arch/sparc/include/asm/page_64.h:#define STRICT_MM_TYPECHECKS
arch/ia64/include/asm/page.h:#  define STRICT_MM_TYPECHECKS
arch/parisc/include/asm/page.h:#define STRICT_MM_TYPECHECKS

* both defined, but using non-strict:
arch/arc/include/asm/page.h:#undef STRICT_MM_TYPECHECKS
arch/arm/include/asm/pgtable-2level-types.h:#undef STRICT_MM_TYPECHECKS
arch/arm/include/asm/pgtable-3level-types.h:#undef STRICT_MM_TYPECHECKS
arch/arm64/include/asm/pgtable-types.h:#undef STRICT_MM_TYPECHECKS
arch/sparc/include/asm/page_32.h:/* #define STRICT_MM_TYPECHECKS */
arch/unicore32/include/asm/page.h:#undef STRICT_MM_TYPECHECKS

* Kconfig option:
arch/powerpc/Kconfig.debug:config STRICT_MM_TYPECHECKS
			 	default n

Everthing else uses only the strict definitions.

For the moment, this only does the minimal change to fix things
on ARM in linux-next. At least in case of sparc32, passing structs
to functions is traditionally inefficient and the non-strict version
should be kept, whether we change any of the other architectures
depends on further testing.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: a27da20ed50e ("mm: add support for PUD-sized transparent hugepages")
Link: http://www.spinics.net/lists/linux-mm/msg101404.html
---
 arch/arm/include/asm/page-nommu.h           | 4 ++--
 arch/arm/include/asm/pgtable-2level-types.h | 7 +++----
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/page-nommu.h b/arch/arm/include/asm/page-nommu.h
index d1b162a18dcb..3db1ca22fecb 100644
--- a/arch/arm/include/asm/page-nommu.h
+++ b/arch/arm/include/asm/page-nommu.h
@@ -31,12 +31,12 @@
  */
 typedef unsigned long pte_t;
 typedef unsigned long pmd_t;
-typedef unsigned long pgd_t[2];
+typedef struct { unsigned long pgd[2]; } pgd_t;
 typedef unsigned long pgprot_t;
 
 #define pte_val(x)      (x)
 #define pmd_val(x)      (x)
-#define pgd_val(x)	((x)[0])
+#define pgd_val(x)	((x).pgd[0])
 #define pgprot_val(x)   (x)
 
 #define __pte(x)        (x)
diff --git a/arch/arm/include/asm/pgtable-2level-types.h b/arch/arm/include/asm/pgtable-2level-types.h
index 66cb5b0e89c5..9b9815d5ebd6 100644
--- a/arch/arm/include/asm/pgtable-2level-types.h
+++ b/arch/arm/include/asm/pgtable-2level-types.h
@@ -24,6 +24,9 @@
 typedef u32 pteval_t;
 typedef u32 pmdval_t;
 
+typedef struct { pmdval_t pgd[2]; } pgd_t;
+#define pgd_val(x)	((x).pgd[0])
+
 #undef STRICT_MM_TYPECHECKS
 
 #ifdef STRICT_MM_TYPECHECKS
@@ -32,12 +35,10 @@ typedef u32 pmdval_t;
  */
 typedef struct { pteval_t pte; } pte_t;
 typedef struct { pmdval_t pmd; } pmd_t;
-typedef struct { pmdval_t pgd[2]; } pgd_t;
 typedef struct { pteval_t pgprot; } pgprot_t;
 
 #define pte_val(x)      ((x).pte)
 #define pmd_val(x)      ((x).pmd)
-#define pgd_val(x)	((x).pgd[0])
 #define pgprot_val(x)   ((x).pgprot)
 
 #define __pte(x)        ((pte_t) { (x) } )
@@ -50,12 +51,10 @@ typedef struct { pteval_t pgprot; } pgprot_t;
  */
 typedef pteval_t pte_t;
 typedef pmdval_t pmd_t;
-typedef pmdval_t pgd_t[2];
 typedef pteval_t pgprot_t;
 
 #define pte_val(x)      (x)
 #define pmd_val(x)      (x)
-#define pgd_val(x)	((x)[0])
 #define pgprot_val(x)   (x)
 
 #define __pte(x)        (x)
-- 
2.7.0



From james.morse at arm.com  Fri Feb 19 08:20:50 2016
From: james.morse at arm.com (James Morse)
Date: Fri, 19 Feb 2016 16:20:50 +0000
Subject: [PATCH v5 07/15] arm64: Change cpu_resume() to enable mmu early
 then access sleep_sp by va
In-Reply-To: <20160218182602.GA17589@red-moon>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
 <1455637767-31561-8-git-send-email-james.morse@arm.com>
 <20160218182602.GA17589@red-moon>
Message-ID: <56C740E2.5000801@arm.com>

Hi Lorenzo,

On 18/02/16 18:26, Lorenzo Pieralisi wrote:
> On Tue, Feb 16, 2016 at 03:49:19PM +0000, James Morse wrote:
>> By enabling the MMU early in cpu_resume(), the sleep_save_sp and stack can
>> be accessed by VA, which avoids the need to convert-addresses and clean to
>> PoC on the suspend path.
>>
>> MMU setup is shared with the boot path, meaning the swapper_pg_dir is
>> restored directly: ttbr1_el1 is no longer saved/restored.
>>
>> struct sleep_save_sp is removed, replacing it with a single array of
>> pointers.
>>
>> cpu_do_{suspend,resume} could be further reduced to not restore: cpacr_el1,
>> mdscr_el1, tcr_el1, vbar_el1 and sctlr_el1, all of which are set by
>> __cpu_setup(). However these values all contain res0 bits that may be used
>> to enable future features.
>>
>> Signed-off-by: James Morse <james.morse at arm.com>
>> ---
> 
> [...]
> 
>> diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
>> index dca81612fe90..0e2b36f1fb44 100644
>> --- a/arch/arm64/kernel/sleep.S
>> +++ b/arch/arm64/kernel/sleep.S
>> @@ -73,8 +73,8 @@ ENTRY(__cpu_suspend_enter)
>>  	str	x2, [x0, #SLEEP_STACK_DATA_SYSTEM_REGS + CPU_CTX_SP]
>>  
>>  	/* find the mpidr_hash */
>> -	ldr	x1, =sleep_save_sp
>> -	ldr	x1, [x1, #SLEEP_SAVE_SP_VIRT]
>> +	ldr	x1, =sleep_save_stash
>> +	ldr	x1, [x1]
>>  	mrs	x7, mpidr_el1
>>  	ldr	x9, =mpidr_hash
>>  	ldr	x10, [x9, #MPIDR_HASH_MASK]
>> @@ -87,40 +87,26 @@ ENTRY(__cpu_suspend_enter)
>>  	compute_mpidr_hash x8, x3, x4, x5, x6, x7, x10
>>  	add	x1, x1, x8, lsl #3
>>  
>> +	str	x0, [x1]
>> +	add	x0, x0, #SLEEP_STACK_DATA_SYSTEM_REGS
> 
> Mmm...this instruction does not really belong in this patch,
> it should be part of patch 6, correct ? What I mean is, the new
> struct to stash system regs (struct sleep_stack_data) was added in
> patch 6, if the offset #SLEEP_STACK_DATA_SYSTEM_REGS (which is 0) had
> to be added it had to be added in patch 6 too, it does not belong
> in this patch, am I right ?

In the previous patch __cpu_suspend_save() was changed to take a struct
sleep_stack_data, this then passes system_regs to cpu_do_suspend(). The 'add	x0,
x0, #SLEEP_STACK_DATA_SYSTEM_REGS' is being done in C, (and hopefully optimised
out by the compiler).

In this patch, we removed __cpu_suspend_save() and call cpu_do_suspend()
directly, so need to account for system_regs's position in struct
sleep_stack_data ourselves.

I'm paranoid, but if you prefer I can remove the 'add 0', and dump a comment
next to the struct definition making it someone elses problem to fix it if they
ever change the layout of the struct...


> 
>>  	push	x29, lr
>> -	bl	__cpu_suspend_save
>> +	bl	cpu_do_suspend
>>  	pop	x29, lr
>>  	mov	x0, #1
>>  	ret
>>  ENDPROC(__cpu_suspend_enter)
>>  	.ltorg

[...2x Nits fixed...]

> With the last updates it seems fine by me, so:
> 
> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>


Thanks!


James




From arnd at arndb.de  Fri Feb 19 08:23:44 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 17:23:44 +0100
Subject: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values
In-Reply-To: <alpine.LFD.2.20.1602191106020.13632@knanqh.ubzr>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <3974581.yknKb3tq7o@wuerfel>
 <alpine.LFD.2.20.1602191106020.13632@knanqh.ubzr>
Message-ID: <38246773.SnToSslHuj@wuerfel>

On Friday 19 February 2016 11:10:22 Nicolas Pitre wrote:
> On Fri, 19 Feb 2016, Arnd Bergmann wrote:
> 
> > On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote:
> > > 
> > > Acked-by: Nicolas Pitre <nico at linaro.org>
> > > 
> > > Is there a way to provide a default for defaults?
...
> > and then select one of the bool symbols from each platform.
> > Would that address your question?
> 
> Yes, but the ugliness factor isn't worth it IMHO.
> 
> I was wondering if something like this was possible:
> 
> config PHYS_OFFSET
>         hex "Physical address of main memory" if MMU
>         default DRAM_BASE if !MMU
>         default 0x10000000 if FOO
>         default 0x20000000 if BAR
>         default 0x30000000 if BAZ
>         default 0x00000000
> 

Ah, that was my previous approach, but Russell didn't like
how it makes it easier to fall back to an incorrect address
instead of forcing a build error when the address is not
configured.

	Arnd


From vladimir.murzin at arm.com  Fri Feb 19 08:27:16 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Fri, 19 Feb 2016 16:27:16 +0000
Subject: [PATCH v3 05/10] serial: mps2-uart: add support for early console
In-Reply-To: <56C738F1.2070307@hurleysoftware.com>
References: <1455617295-23736-1-git-send-email-vladimir.murzin@arm.com>
 <1455617295-23736-6-git-send-email-vladimir.murzin@arm.com>
 <CAHp75VdugAq0WnzLHmd9CJHCjBOdBwPqCmC3ARSaVF5XMYGoMw@mail.gmail.com>
 <56C31F9F.10000@arm.com> <56C6E42E.5070601@arm.com>
 <CAHp75VcosaVcz_aYbpfL-nUH0kBf72SshXU5k95s48Z3wnA5nQ@mail.gmail.com>
 <56C738F1.2070307@hurleysoftware.com>
Message-ID: <56C74264.9070906@arm.com>

On 19/02/16 15:46, Peter Hurley wrote:
> On 02/19/2016 01:57 AM, Andy Shevchenko wrote:
>> On Fri, Feb 19, 2016 at 11:45 AM, Vladimir Murzin
>> <vladimir.murzin at arm.com> wrote:
>>> On 16/02/16 13:09, Vladimir Murzin wrote:
>>>>>> +EARLYCON_DECLARE(mps2, mps2_early_console_setup);
>>>>>>>> +OF_EARLYCON_DECLARE(mps2, "arm,mps2-uart", mps2_early_console_setup);
>>>>>>
>>>>>> IIRC Peter Hurley mentioned you don't need to put both anymore, OF_
>>>>>> one is enough.
>>>>>>
>>>> I've just tried with OF_ only and seems it works fine. Thanks for
>>>> pointing at it!
>>>>
>>>
>>> ..and the reason for that was that I had stdout pointing at uart node.
>>> Now, while testing v4 I end-up with configuration:
>>>
>>> 1) no EARLYCON_DECLARE in mps2-uart.c
>>> 2) stdout not set
>>> 3) cmdline has "earlycon=mps2,0x40004000 console=/dev/ttyMPS"
>>>
>>> and I don't see bootconsole, but if I avoid 1) everything works fine.
>>> So, I'd leave EARLYCON_DECLARE in this patch.
>>
>> Peter, what is your comment on this?
> 
> That Vladimir is not testing with linux-next.
> 
> linux-next has common framework for both command line and OF-defined
> earlycons.
> 
> Vladimir, if you pull in Greg's tty-next branch, then just
> 
> OF_EARLYCON_DECLARE(mps2, "arm,mps2-uart", mps2_early_console_setup);
> 
> should enable both command-line and OF-defined earlycons.

Confirmed! No doubt now EARLYCON_DECLARE can be dropped from this patch
safely.

Thanks!
Vladimir

> 
> Regards,
> Peter Hurley
> 
> 



From Chris.Brandt at renesas.com  Fri Feb 19 08:28:06 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Fri, 19 Feb 2016 16:28:06 +0000
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <64215923.Y25jP5YYZ2@wuerfel>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
 <3699765.F7sfuMCyKT@wuerfel>
 <HK2PR06MB05616AAF67B15C7A2BDC4F608AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
 <64215923.Y25jP5YYZ2@wuerfel>
Message-ID: <HK2PR06MB056181A22F655E6D4A11DEED8AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>

On 19 Feb 2016, Arnd Bergmann wrote:
> 
> > But, now I see that PHYS_OFFSET is used all over the place as a hard
> > coded #define, hence your comment "which cannot patch the kernel image
> > at boot time"
> > 
> > So, I retract my thought...it has to be configured at build-time
> > (unless of course you turn it into a global variable everywhere...which
> >  might be an even bigger mess)
> > 
> 
> BTW, I've tried removing the patching in CONFIG_PHYS_VIRT and replaced it
> with references to __pv_phys_pfn_offset, which surprisingly only grew
> .text from 4901692 to 4904300 bytes, so the size overhead of doing this
> would be close to zero.
> 
> 	Arnd

Cool. If you come up with a patch, I'll give it a try.


Overall, I'd rather side with "Let me enable stuff even though it might not work automatically" as opposed to "Don't let me do anything unless it's simple and safe" (which kind of reminds me of Apple products)


Chris



From will.deacon at arm.com  Fri Feb 19 08:29:29 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 19 Feb 2016 16:29:29 +0000
Subject: [GIT PULL] arm64: fixes for -rc5
Message-ID: <20160219162928.GM27062@arm.com>

Hi Linus,

Here are some more arm64 fixes for 4.5. This has mostly come from Yang
Shi, who saw some issues under -rt that also affect mainline. The rest
of it is pretty small, but still worth having.

We've got an old issue outstanding with valid_user_regs which will
likely wait until 4.6 (since it would really benefit from some time in
-next) and another issue with kasan and idle which should be fixed next
week.

Apart from that, pretty quiet here (and still no sign of the THP issue
reported on s390...)

Will

--->8

The following changes since commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95:

  Linux 4.5-rc3 (2016-02-07 15:38:30 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes

for you to fetch changes up to 52d7523d84d534c241ebac5ac89f5c0a6cb51e41:

  arm64: mm: allow the kernel to handle alignment faults on user accesses (2016-02-19 12:20:37 +0000)

----------------------------------------------------------------
arm64 fixes:

- Allow EFI stub to use strnlen(), which is required by recent libfdt

- Avoid smp_processor_id() in preempt context during unwinding

- Avoid false Kasan warnings during unwinding

- Ensure early devices are picked up by the IOMMU DMA ops

- Avoid rebuilding the kernel for the 'install' target

- Run fixup handlers for alignment faults on userspace access

----------------------------------------------------------------
EunTaik Lee (1):
      arm64: mm: allow the kernel to handle alignment faults on user accesses

Jeremy Linton (1):
      arm/arm64: crypto: assure that ECB modes don't require an IV

Marek Szyprowski (1):
      arm64: dma-mapping: fix handling of devices registered before arch_initcall

Masahiro Yamada (1):
      arm64: kbuild: make "make install" not depend on vmlinux

Thierry Reding (1):
      arm64/efi: Make strnlen() available to the EFI namespace

Will Deacon (1):
      arm64: debug: re-enable irqs before sending breakpoint SIGTRAP

Yang Shi (2):
      arm64: disable kasan when accessing frame->fp in unwind_frame
      arm64: make irq_stack_ptr more robust

 arch/arm/crypto/aes-ce-glue.c      |  4 ++--
 arch/arm64/Makefile                |  2 +-
 arch/arm64/boot/Makefile           |  4 ++--
 arch/arm64/boot/install.sh         | 14 +++++++++++
 arch/arm64/crypto/aes-glue.c       |  4 ++--
 arch/arm64/kernel/debug-monitors.c | 48 +++++++++++++++++---------------------
 arch/arm64/kernel/image.h          |  1 +
 arch/arm64/kernel/stacktrace.c     | 17 +++++++-------
 arch/arm64/kernel/traps.c          | 11 ++++++++-
 arch/arm64/lib/strnlen.S           |  2 +-
 arch/arm64/mm/dma-mapping.c        |  4 ++++
 arch/arm64/mm/fault.c              |  9 ++++++-
 12 files changed, 75 insertions(+), 45 deletions(-)


From arnd at arndb.de  Fri Feb 19 08:39:35 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 17:39:35 +0100
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <HK2PR06MB056181A22F655E6D4A11DEED8AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
 <64215923.Y25jP5YYZ2@wuerfel>
 <HK2PR06MB056181A22F655E6D4A11DEED8AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
Message-ID: <4255249.Z5tzmoAfvg@wuerfel>

On Friday 19 February 2016 16:28:06 Chris Brandt wrote:
> On 19 Feb 2016, Arnd Bergmann wrote:
> > 
> > > But, now I see that PHYS_OFFSET is used all over the place as a hard
> > > coded #define, hence your comment "which cannot patch the kernel image
> > > at boot time"
> > > 
> > > So, I retract my thought...it has to be configured at build-time
> > > (unless of course you turn it into a global variable everywhere...which
> > >  might be an even bigger mess)
> > > 
> > 
> > BTW, I've tried removing the patching in CONFIG_PHYS_VIRT and replaced it
> > with references to __pv_phys_pfn_offset, which surprisingly only grew
> > .text from 4901692 to 4904300 bytes, so the size overhead of doing this
> > would be close to zero.
> > 
> >       Arnd
> 
> Cool. If you come up with a patch, I'll give it a try.

It was really just a hack, deleting code that we normally need,  but
you can work on top of that. This is still not useful unless you
also find a way to guess the __pv_phys_pfn_offset value. Maybe
there is even a way to derive that from the stack pointer if we
can safely assume that it points into RAM ?

	Arnd

diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 9427fd632552..3f797bc5d73f 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -175,10 +175,11 @@
 #define __PV_BITS_7_0	0x81
 
 extern unsigned long __pv_phys_pfn_offset;
-extern u64 __pv_offset;
+extern phys_addr_t __pv_offset;
 extern void fixup_pv_table(const void *, unsigned long);
 extern const void *__pv_table_begin, *__pv_table_end;
 
+#define PAGE_SHIFT 12
 #define PHYS_OFFSET	((phys_addr_t)__pv_phys_pfn_offset << PAGE_SHIFT)
 #define PHYS_PFN_OFFSET	(__pv_phys_pfn_offset)
 
@@ -186,75 +187,14 @@ extern const void *__pv_table_begin, *__pv_table_end;
 	((((unsigned long)(kaddr) - PAGE_OFFSET) >> PAGE_SHIFT) + \
 	 PHYS_PFN_OFFSET)
 
-#define __pv_stub(from,to,instr,type)			\
-	__asm__("@ __pv_stub\n"				\
-	"1:	" instr "	%0, %1, %2\n"		\
-	"	.pushsection .pv_table,\"a\"\n"		\
-	"	.long	1b\n"				\
-	"	.popsection\n"				\
-	: "=r" (to)					\
-	: "r" (from), "I" (type))
-
-#define __pv_stub_mov_hi(t)				\
-	__asm__ volatile("@ __pv_stub_mov\n"		\
-	"1:	mov	%R0, %1\n"			\
-	"	.pushsection .pv_table,\"a\"\n"		\
-	"	.long	1b\n"				\
-	"	.popsection\n"				\
-	: "=r" (t)					\
-	: "I" (__PV_BITS_7_0))
-
-#define __pv_add_carry_stub(x, y)			\
-	__asm__ volatile("@ __pv_add_carry_stub\n"	\
-	"1:	adds	%Q0, %1, %2\n"			\
-	"	adc	%R0, %R0, #0\n"			\
-	"	.pushsection .pv_table,\"a\"\n"		\
-	"	.long	1b\n"				\
-	"	.popsection\n"				\
-	: "+r" (y)					\
-	: "r" (x), "I" (__PV_BITS_31_24)		\
-	: "cc")
-
-static inline phys_addr_t __virt_to_phys(unsigned long x)
-{
-	phys_addr_t t;
-
-	if (sizeof(phys_addr_t) == 4) {
-		__pv_stub(x, t, "add", __PV_BITS_31_24);
-	} else {
-		__pv_stub_mov_hi(t);
-		__pv_add_carry_stub(x, t);
-	}
-	return t;
-}
-
-static inline unsigned long __phys_to_virt(phys_addr_t x)
-{
-	unsigned long t;
-
-	/*
-	 * 'unsigned long' cast discard upper word when
-	 * phys_addr_t is 64 bit, and makes sure that inline
-	 * assembler expression receives 32 bit argument
-	 * in place where 'r' 32 bit operand is expected.
-	 */
-	__pv_stub((unsigned long) x, t, "sub", __PV_BITS_31_24);
-	return t;
-}
-
-#else
-
-#define PHYS_OFFSET	PLAT_PHYS_OFFSET
-#define PHYS_PFN_OFFSET	((unsigned long)(PHYS_OFFSET >> PAGE_SHIFT))
-
 static inline phys_addr_t __virt_to_phys(unsigned long x)
 {
-	return (phys_addr_t)x - PAGE_OFFSET + PHYS_OFFSET;
+	return (phys_addr_t)x - PAGE_OFFSET + __pv_offset;
 }
 
 static inline unsigned long __phys_to_virt(phys_addr_t x)
 {
-	return x - PHYS_OFFSET + PAGE_OFFSET;
+	return x - __pv_offset + PAGE_OFFSET;
 }
 
 #define virt_to_pfn(kaddr) \



From lorenzo.pieralisi at arm.com  Fri Feb 19 08:43:21 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Fri, 19 Feb 2016 16:43:21 +0000
Subject: [PATCH v5 07/15] arm64: Change cpu_resume() to enable mmu early
 then access sleep_sp by va
In-Reply-To: <56C740E2.5000801@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
 <1455637767-31561-8-git-send-email-james.morse@arm.com>
 <20160218182602.GA17589@red-moon> <56C740E2.5000801@arm.com>
Message-ID: <20160219164321.GA1195@red-moon>

On Fri, Feb 19, 2016 at 04:20:50PM +0000, James Morse wrote:

[...]

> >> diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
> >> index dca81612fe90..0e2b36f1fb44 100644
> >> --- a/arch/arm64/kernel/sleep.S
> >> +++ b/arch/arm64/kernel/sleep.S
> >> @@ -73,8 +73,8 @@ ENTRY(__cpu_suspend_enter)
> >>  	str	x2, [x0, #SLEEP_STACK_DATA_SYSTEM_REGS + CPU_CTX_SP]
> >>  
> >>  	/* find the mpidr_hash */
> >> -	ldr	x1, =sleep_save_sp
> >> -	ldr	x1, [x1, #SLEEP_SAVE_SP_VIRT]
> >> +	ldr	x1, =sleep_save_stash
> >> +	ldr	x1, [x1]
> >>  	mrs	x7, mpidr_el1
> >>  	ldr	x9, =mpidr_hash
> >>  	ldr	x10, [x9, #MPIDR_HASH_MASK]
> >> @@ -87,40 +87,26 @@ ENTRY(__cpu_suspend_enter)
> >>  	compute_mpidr_hash x8, x3, x4, x5, x6, x7, x10
> >>  	add	x1, x1, x8, lsl #3
> >>  
> >> +	str	x0, [x1]
> >> +	add	x0, x0, #SLEEP_STACK_DATA_SYSTEM_REGS
> > 
> > Mmm...this instruction does not really belong in this patch,
> > it should be part of patch 6, correct ? What I mean is, the new
> > struct to stash system regs (struct sleep_stack_data) was added in
> > patch 6, if the offset #SLEEP_STACK_DATA_SYSTEM_REGS (which is 0) had
> > to be added it had to be added in patch 6 too, it does not belong
> > in this patch, am I right ?
> 
> In the previous patch __cpu_suspend_save() was changed to take a
> struct sleep_stack_data, this then passes system_regs to
> cpu_do_suspend(). The 'add	x0, x0, #SLEEP_STACK_DATA_SYSTEM_REGS'
> is being done in C, (and hopefully optimised out by the compiler).
> 
> In this patch, we removed __cpu_suspend_save() and call cpu_do_suspend()
> directly, so need to account for system_regs's position in struct
> sleep_stack_data ourselves.

Yes, I missed that during the review, that explains, thanks.

> I'm paranoid, but if you prefer I can remove the 'add 0', and dump a
> comment next to the struct definition making it someone elses problem
> to fix it if they ever change the layout of the struct...

No, what you do is correct and should be kept as-is, I thought it
had to be added in patch 6 but I was wrong, see above, code is
correct as it is.

Thanks,
Lorenzo

> 
> 
> > 
> >>  	push	x29, lr
> >> -	bl	__cpu_suspend_save
> >> +	bl	cpu_do_suspend
> >>  	pop	x29, lr
> >>  	mov	x0, #1
> >>  	ret
> >>  ENDPROC(__cpu_suspend_enter)
> >>  	.ltorg
> 
> [...2x Nits fixed...]
> 
> > With the last updates it seems fine by me, so:
> > 
> > Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> 
> 
> Thanks!
> 
> 
> James
> 
> 


From linux at arm.linux.org.uk  Fri Feb 19 08:43:44 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Feb 2016 16:43:44 +0000
Subject: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values
In-Reply-To: <14272873.q312Ii8Axy@wuerfel>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <3974581.yknKb3tq7o@wuerfel>
 <HK2PR06MB056137892B6F968A8A1008C58AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
 <14272873.q312Ii8Axy@wuerfel>
Message-ID: <20160219164344.GY19428@n2100.arm.linux.org.uk>

On Fri, Feb 19, 2016 at 04:34:51PM +0100, Arnd Bergmann wrote:
> On Friday 19 February 2016 14:29:00 Chris Brandt wrote:
> > On 19 Feb 2016, Arnd Bergmann wrote:
> > 
> > > On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote:
> > > > 
> > > > Acked-by: Nicolas Pitre <nico at linaro.org>
> > > > 
> > > > Is there a way to provide a default for defaults?
> > > 
> > > We could have something like
> > > 
> > > config PHYS_OFFSET_0
> > > 	bool
> > > 
> > > config PHYS_OFFSET_1
> > > 	bool
> > > 
> > > config PHYS_OFFSET_2
> > > 	bool
> > > 
> > > ... (we need 8 of the 16 possible addresses)
> > > 
> > > 
> > > config PHYS_OFFSET
> > > 	hex "Physical address of main memory" if MMU
> > > 	default DRAM_BASE if !MMU
> > > 	default 0x00000000 if PHYS_OFFSET_0
> > > 	default 0x10000000 if PHYS_OFFSET_1
> > > 	default 0x20000000 if PHYS_OFFSET_2
> > > 	default 0x30000000 if PHYS_OFFSET_3
> > > 	default 0x70000000 if PHYS_OFFSET_7
> > > 	default 0x80000000 if PHYS_OFFSET_8
> > > 	default 0xa0000000 if PHYS_OFFSET_A
> > > 	default 0xc0000000 if PHYS_OFFSET_C
> > > 
> > > 
> > > and then select one of the bool symbols from each platform.
> > > Would that address your question?
> > 
> > 
> > Here's a question:
> > 
> > Can we just get rid of PHYS_OFFSET???
> > 
> > If it's only used at boot for XIP systems, we could:
> > 
> > A) pass it in via an unused register like atags and DT
> >  or
> > B) just assume that atags or DT is in RAM, so round down to the nearest section and assume that is the start of your RAM
> > 
> > If it is needed after initial boot, then on first boot we save what was passed in from the boot loader for later use.
> 
> Hmm, you mean making phys_offset a runtime variable instead
> of patching it at early boot time in the instructions?
> 
> I have no idea if that works, how much effort it would be,
> or how much it would enlarge the kernel image size, but
> you can definitely try.
> 
> Of course we must not break existing platforms using XIP_KERNEL
> already, but the installed base among systems that are upgrading
> to modern kernels is very small now, given how all modern platforms
> don't support XIP_KERNEL today, or have no MMU to start with.

You're all barking up the wrong tree, because you don't understand
why it exists.

ARM_PATCH_PHYS_VIRT exists to support an init-time decided phys offset,
and it supports this by modifying each location that the phys offset
is used.  It determines this by looking at the location that the early
init code is executing, and masking the PC with a value that has been
carefully crafted to fit 99% of the existing platforms.

One of the side effects of ARM_PATCH_PHYS_VIRT is that we hide the
translation from the compiler, so the compiler is unable to optimise
things like virt_to_phys(phys_to_virt(x)) to just 'x' (and yes, such
things do happen.)

PHYS_OFFSET exists to cater for the case where ARM_PATCH_PHYS_VIRT is
disabled, because either ARM_PATCH_PHYS_VIRT does not work for the
platform, or the platform has special requirements and/or requires
better performance.  It switches back to the pre-ARM_PATCH_PHYS_VIRT
situation where the PHYS_OFFSET is a compile time constant.

Obviously, making PHYS_OFFSET a runtime variable is basically what
ARM_PATCH_PHYS_VIRT is doing.  That does not help these cases though,
because the problem cases are not whether it's a runtime variable or
not, it's how to arrive at the value for it in the first place.

Using the DTB location on XIP platforms is a no-goer - the flattened
DTB information can be fixed, so on an XIP platform it makes sense
for this to also be in flash, not in RAM (the whole point of XIP is
to remove constant data from RAM after all, so why would you want to
copy the FDT to RAM?)

Passing it in a register to the kernel image is also not possible:
we've been out of spare registers for some time now for passing
additional information into the kernel.  It wouldn't be a problem
had folk not had this "eww, I don't like ATAGs, lets get rid of them
and use DT instead" attitude: had we kept ATAGs, then we'd have an
in-memory format to pass this kind of information to the kernel.
That would solve soo many problems today it's untrue: stuff like
where a debugging UART is located and the type of it...

When DT was being proposed, my opinion was that's how it should've
been done, but I assumed that the DT folk knew better, and Grant was
very much of the opinion that ATAGs should be completely dropped (I
did touch on it with Grant.)  I regret now not having a discussion
about it and pressing strongly for it.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From Liviu.Dudau at arm.com  Fri Feb 19 08:44:29 2016
From: Liviu.Dudau at arm.com (Liviu Dudau)
Date: Fri, 19 Feb 2016 16:44:29 +0000
Subject: [PATCH] drm: ARM HDLCD - get rid of devm_clk_put()
In-Reply-To: <1455869701-23437-1-git-send-email-abrodkin@synopsys.com>
References: <1455869701-23437-1-git-send-email-abrodkin@synopsys.com>
Message-ID: <20160219164429.GQ1123@e106497-lin.cambridge.arm.com>

On Fri, Feb 19, 2016 at 11:15:01AM +0300, Alexey Brodkin wrote:
> Clock is acquired with devm_clk_get() which already manages
> corresponding resource.
> 
> I.e. in case of driver removal or failure on installaiton
> clock resources will be automatically released and explicit
> call of devm_clk_put() is not required.
> 
> Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
> Cc: Liviu Dudau <Liviu.Dudau at arm.com>

Acked-by: Liviu Dudau <Liviu.Dudau at arm.com>

Thanks,
Liviu

> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> Cc: David Airlie <airlied at linux.ie>
> Cc: Robin Murphy <robin.murphy at arm.com>
> ---
>  drivers/gpu/drm/arm/hdlcd_drv.c | 15 +++------------
>  1 file changed, 3 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 56b829f..734849f 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -55,16 +55,14 @@ static int hdlcd_load(struct drm_device *drm, unsigned long flags)
>  	hdlcd->mmio = devm_ioremap_resource(drm->dev, res);
>  	if (IS_ERR(hdlcd->mmio)) {
>  		DRM_ERROR("failed to map control registers area\n");
> -		ret = PTR_ERR(hdlcd->mmio);
>  		hdlcd->mmio = NULL;
> -		goto fail;
> +		return PTR_ERR(hdlcd->mmio);
>  	}
>  
>  	version = hdlcd_read(hdlcd, HDLCD_REG_VERSION);
>  	if ((version & HDLCD_PRODUCT_MASK) != HDLCD_PRODUCT_ID) {
>  		DRM_ERROR("unknown product id: 0x%x\n", version);
> -		ret = -EINVAL;
> -		goto fail;
> +		return -EINVAL;
>  	}
>  	DRM_INFO("found ARM HDLCD version r%dp%d\n",
>  		(version & HDLCD_VERSION_MAJOR_MASK) >> 8,
> @@ -73,7 +71,7 @@ static int hdlcd_load(struct drm_device *drm, unsigned long flags)
>  	/* Get the optional framebuffer memory resource */
>  	ret = of_reserved_mem_device_init(drm->dev);
>  	if (ret && ret != -ENODEV)
> -		goto fail;
> +		return ret;
>  
>  	ret = dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32));
>  	if (ret)
> @@ -101,8 +99,6 @@ irq_fail:
>  	drm_crtc_cleanup(&hdlcd->crtc);
>  setup_fail:
>  	of_reserved_mem_device_release(drm->dev);
> -fail:
> -	devm_clk_put(drm->dev, hdlcd->clk);
>  
>  	return ret;
>  }
> @@ -412,7 +408,6 @@ err_unload:
>  	pm_runtime_put_sync(drm->dev);
>  	pm_runtime_disable(drm->dev);
>  	of_reserved_mem_device_release(drm->dev);
> -	devm_clk_put(dev, hdlcd->clk);
>  err_free:
>  	drm_dev_unref(drm);
>  
> @@ -436,10 +431,6 @@ static void hdlcd_drm_unbind(struct device *dev)
>  	pm_runtime_put_sync(drm->dev);
>  	pm_runtime_disable(drm->dev);
>  	of_reserved_mem_device_release(drm->dev);
> -	if (!IS_ERR(hdlcd->clk)) {
> -		devm_clk_put(drm->dev, hdlcd->clk);
> -		hdlcd->clk = NULL;
> -	}
>  	drm_mode_config_cleanup(drm);
>  	drm_dev_unregister(drm);
>  	drm_dev_unref(drm);
> -- 
> 2.5.0
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?


From catalin.marinas at arm.com  Fri Feb 19 08:46:06 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Feb 2016 16:46:06 +0000
Subject: [PATCH v2 0/5] arm64: kernel: Add support for User Access Override
In-Reply-To: <CAFEAcA9SQjg3GpDpU-Tt8i+JiOcJWQKTNzwLLTC4imiBuiP6+w@mail.gmail.com>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
 <20160218180313.GE2538@e104818-lin.cambridge.arm.com>
 <CAFEAcA9SQjg3GpDpU-Tt8i+JiOcJWQKTNzwLLTC4imiBuiP6+w@mail.gmail.com>
Message-ID: <20160219164606.GD12864@e104818-lin.cambridge.arm.com>

On Fri, Feb 19, 2016 at 03:38:44PM +0000, Peter Maydell wrote:
> On 18 February 2016 at 18:03, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Fri, Feb 05, 2016 at 02:58:45PM +0000, James Morse wrote:
> >> James Morse (5):
> >>   arm64: cpufeature: Change read_cpuid() to use sysreg's mrs_s macro
> >>   arm64: add ARMv8.2 id_aa64mmfr2 boiler plate
> >>   arm64: kernel: Add support for User Access Override
> >>   arm64: cpufeature: Test 'matches' pointer to find the end of the list
> >>   arm64: kernel: Don't toggle PAN on systems with UAO
> >
> > Patches applied with an additional fixup on top for removing
> > get_thread_info().
> 
> Just to let you know, unfortunately this series breaks booting the
> kernel on QEMU. We didn't implement the parts of the ID register
> space that the ARM ARM documents as "reserved, RAZ", and so when
> the kernel touches ID_AA64MMFR2 (new in v8.2) QEMU hands it an
> UNDEF. This is obviously a bug in QEMU, and I just sent out a patch
> for it: http://patchwork.ozlabs.org/patch/585237/ -- but of course
> that doesn't do anything for all the buggy QEMUs already in the field.
> 
> This is more of a heads-up than a demand that you Do Something,
> but perhaps somebody has a clever idea...

Only if Qemu had its own MIDR/REVIDR ;) (and patch the instruction like
other errata workarounds).

-- 
Catalin


From linux at arm.linux.org.uk  Fri Feb 19 08:47:42 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Feb 2016 16:47:42 +0000
Subject: [PATCH] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <64215923.Y25jP5YYZ2@wuerfel>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
 <3699765.F7sfuMCyKT@wuerfel>
 <HK2PR06MB05616AAF67B15C7A2BDC4F608AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
 <64215923.Y25jP5YYZ2@wuerfel>
Message-ID: <20160219164742.GZ19428@n2100.arm.linux.org.uk>

On Fri, Feb 19, 2016 at 04:59:43PM +0100, Arnd Bergmann wrote:
> On Friday 19 February 2016 15:36:23 Chris Brandt wrote:
> > On 19 Feb 2016, Arnd Bergmann wrote:
> > 
> > > For PHYS_OFFSET, parsing the DT doesn't help at all because we only
> > > need it for XIP_KERNEL (more or less at least) which cannot patch
> > > the kernel image at boot time, so knowing that the address is wrong
> > > also doesn't help you.
> > > 
> > > 	Arnd
> > 
> > OK, at first I was thinking that PHYS_OFFSET was only used early in boot as a pointer to valid RAM before the DT was read (in head.S and head-nommu.S). Hence, you could pass in the pointer in via another CPU register like the DT pointer is passed in.
> > 
> > But, now I see that PHYS_OFFSET is used all over the place as a hard coded #define, hence your comment "which cannot patch the kernel image at boot time"
> > 
> > So, I retract my thought...it has to be configured at build-time (unless of course you turn it into a global variable everywhere...which might be an even bigger mess)
> > 
> 
> BTW, I've tried removing the patching in CONFIG_PHYS_VIRT and replaced it
> with references to __pv_phys_pfn_offset, which surprisingly only grew
> .text from 4901692 to 4904300 bytes, so the size overhead of doing this
> would be close to zero.

The next job is to perf the resulting kernel - because you will have
the additional overhead of loading the offset.  Size is not everything,
contary to popular beliefs.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From linux at arm.linux.org.uk  Fri Feb 19 08:48:44 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Feb 2016 16:48:44 +0000
Subject: [PATCH] clk: gpio: Really allow an optional clock= DT property
In-Reply-To: <1455851525-18972-1-git-send-email-sboyd@codeaurora.org>
References: <20160219030731.GS4847@codeaurora.org>
 <1455851525-18972-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <20160219164844.GA19428@n2100.arm.linux.org.uk>

On Thu, Feb 18, 2016 at 07:12:05PM -0800, Stephen Boyd wrote:
> We mis-merged the original patch from Russell here and so the
> patch went almost all the way, except that we still failed to
> probe when there wasn't a clocks property in the DT node. Allow
> that case by making a negative value from
> of_clk_get_parent_count() into "no parents", like the original
> patch did.

NAK.  I'm not testing this patch, when I've already spent more than
enough time (a) developing the original patch and testing that, and
(b) re-diagnosing what's going wrong, and re-fixing the fuck up,
and testing that fix.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From peter.maydell at linaro.org  Fri Feb 19 08:54:17 2016
From: peter.maydell at linaro.org (Peter Maydell)
Date: Fri, 19 Feb 2016 16:54:17 +0000
Subject: [PATCH v2 0/5] arm64: kernel: Add support for User Access Override
In-Reply-To: <20160219164606.GD12864@e104818-lin.cambridge.arm.com>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
 <20160218180313.GE2538@e104818-lin.cambridge.arm.com>
 <CAFEAcA9SQjg3GpDpU-Tt8i+JiOcJWQKTNzwLLTC4imiBuiP6+w@mail.gmail.com>
 <20160219164606.GD12864@e104818-lin.cambridge.arm.com>
Message-ID: <CAFEAcA_uAG1hX2a3n8FSJpB704wzJeXzijHSETJ2B6OR0g=nJw@mail.gmail.com>

On 19 February 2016 at 16:46, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Fri, Feb 19, 2016 at 03:38:44PM +0000, Peter Maydell wrote:
>> This is more of a heads-up than a demand that you Do Something,
>> but perhaps somebody has a clever idea...
>
> Only if Qemu had its own MIDR/REVIDR ;) (and patch the instruction like
> other errata workarounds).

Smiley noted, but FWIW the relevant CPUs advertise themselves as
MIDR 0x411fd070 REVIDR 0 (A57) and MIDR 0x410fd034 REVIDR 0 (A53),
and it should be harmless to patch the ID_AA64MMFR2 read to always
return 0 on any A53 or A57 including h/w, because they'll read as
zero anyway...

So it comes down to how much we want to work around QEMU "errata".

thanks
-- PMM


From ard.biesheuvel at linaro.org  Fri Feb 19 08:57:17 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 19 Feb 2016 17:57:17 +0100
Subject: [PATCH v2 0/5] arm64: kernel: Add support for User Access Override
In-Reply-To: <CAFEAcA_uAG1hX2a3n8FSJpB704wzJeXzijHSETJ2B6OR0g=nJw@mail.gmail.com>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
 <20160218180313.GE2538@e104818-lin.cambridge.arm.com>
 <CAFEAcA9SQjg3GpDpU-Tt8i+JiOcJWQKTNzwLLTC4imiBuiP6+w@mail.gmail.com>
 <20160219164606.GD12864@e104818-lin.cambridge.arm.com>
 <CAFEAcA_uAG1hX2a3n8FSJpB704wzJeXzijHSETJ2B6OR0g=nJw@mail.gmail.com>
Message-ID: <CAKv+Gu9GDE5MVLGkvx9NGB=R_AS--32aGYQ++zT9gGFwBFgnpw@mail.gmail.com>

On 19 February 2016 at 17:54, Peter Maydell <peter.maydell at linaro.org> wrote:
> On 19 February 2016 at 16:46, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> On Fri, Feb 19, 2016 at 03:38:44PM +0000, Peter Maydell wrote:
>>> This is more of a heads-up than a demand that you Do Something,
>>> but perhaps somebody has a clever idea...
>>
>> Only if Qemu had its own MIDR/REVIDR ;) (and patch the instruction like
>> other errata workarounds).
>
> Smiley noted, but FWIW the relevant CPUs advertise themselves as
> MIDR 0x411fd070 REVIDR 0 (A57) and MIDR 0x410fd034 REVIDR 0 (A53),
> and it should be harmless to patch the ID_AA64MMFR2 read to always
> return 0 on any A53 or A57 including h/w, because they'll read as
> zero anyway...
>
> So it comes down to how much we want to work around QEMU "errata".
>

Doesn't this only affect TCG emulation, and not KVM?


From arnd at arndb.de  Fri Feb 19 08:58:46 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 17:58:46 +0100
Subject: [PATCH v2] ARM: atags_to_fdt: don't warn about stack size
In-Reply-To: <7301172.5fH67MHlU9@wuerfel>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602181112310.13632@knanqh.ubzr>
 <7301172.5fH67MHlU9@wuerfel>
Message-ID: <8232115.18ykgQ6J5T@wuerfel>

On Thursday 18 February 2016 17:26:56 Arnd Bergmann wrote:
> On Thursday 18 February 2016 11:13:52 Nicolas Pitre wrote:
> > What about setting the warning to 2048 instead?
> 
> Sure, actually 1280 is more than enough I think.
> 
It turns out that doesn't fix the problem though, as the new
argument gets prepended and the existing flag overrides it.

I have modified the patch now to do both:

CFLAGS_REMOVE_atags_to_fdt.o += -Wframe-larger-than=${CONFIG_FRAME_WARN}
CFLAGS_atags_to_fdt.o += -Wframe-larger-than=1280

	Arnd


From peter.maydell at linaro.org  Fri Feb 19 09:03:15 2016
From: peter.maydell at linaro.org (Peter Maydell)
Date: Fri, 19 Feb 2016 17:03:15 +0000
Subject: [PATCH v2 0/5] arm64: kernel: Add support for User Access Override
In-Reply-To: <CAKv+Gu9GDE5MVLGkvx9NGB=R_AS--32aGYQ++zT9gGFwBFgnpw@mail.gmail.com>
References: <1454684330-892-1-git-send-email-james.morse@arm.com>
 <20160218180313.GE2538@e104818-lin.cambridge.arm.com>
 <CAFEAcA9SQjg3GpDpU-Tt8i+JiOcJWQKTNzwLLTC4imiBuiP6+w@mail.gmail.com>
 <20160219164606.GD12864@e104818-lin.cambridge.arm.com>
 <CAFEAcA_uAG1hX2a3n8FSJpB704wzJeXzijHSETJ2B6OR0g=nJw@mail.gmail.com>
 <CAKv+Gu9GDE5MVLGkvx9NGB=R_AS--32aGYQ++zT9gGFwBFgnpw@mail.gmail.com>
Message-ID: <CAFEAcA8V+wnD2JBRvsj+KvkjxHrcfa8jbb9CH3nJe-gjsxhKoA@mail.gmail.com>

On 19 February 2016 at 16:57, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> Doesn't this only affect TCG emulation, and not KVM?

Correct, but that's still a fair userbase.

thanks
-- PMM


From tony at atomide.com  Fri Feb 19 09:04:05 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Feb 2016 09:04:05 -0800
Subject: [PATCH] Revert "regulator: tps65217: remove tps65217.dtsi file"
In-Reply-To: <1455891139-6139-1-git-send-email-peter.ujfalusi@ti.com>
References: <1455891139-6139-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <20160219170404.GH21202@atomide.com>

* Peter Ujfalusi <peter.ujfalusi at ti.com> [160219 06:14]:
> This reverts commit 8e6ebfaa9b384088002baa10f7534efa73a0794e.
> 
> Without the patch reverted regulators will not work. This prevents
> MMC to be working for example so the boards can not boot to
> MMC rootfs.
> 
> Tested it on beaglebone white and bisect also points to the
> reverted commit.
> The issue can be also fixed by adding "regulator-compatible =" to all board
> dts file for the regulators.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> ---
> Hi,
> 
> I have noticed that bbw did not find the MMC with linux-next, but it turns out
> that even 4.5-rc4 is behaving the same way.
> I have run bisect and with this revert patch I can boot up fine.
> To be honest I don't know why the tps65217.dtsi has been deleted in the first
> place. 

I think initially the only real issue was the naming. The
tps65217.dtsi file should be just renamed to tps65217-am335x.dtsi
to make it clear that this configuration is commonly used for
most am335x boards.

I'll apply this revert into omap-for-v4.5/fixes as it fixes a
regression.

Thanks,

Tony


From nicolas.pitre at linaro.org  Fri Feb 19 09:08:23 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 19 Feb 2016 12:08:23 -0500 (EST)
Subject: [PATCH 1/3] [RESEND] ARM: pass -march=armv7-a when building NEON
 files with clang
In-Reply-To: <3205167.CfekeqRXnt@wuerfel>
References: <1455815113-2562966-1-git-send-email-arnd@arndb.de>
 <1455815113-2562966-2-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602181230440.13632@knanqh.ubzr>
 <3205167.CfekeqRXnt@wuerfel>
Message-ID: <alpine.LFD.2.20.1602191205000.13632@knanqh.ubzr>

On Fri, 19 Feb 2016, Arnd Bergmann wrote:

> On Thursday 18 February 2016 12:31:35 Nicolas Pitre wrote:
> > On Thu, 18 Feb 2016, Arnd Bergmann wrote:
> > 
> > > clang ignores the -mfpu=neon flag when building with -march=armv6:
> > > 
> > > In file included from lib/raid6/neon1.c:27:
> > > clang/3.8.0/include/arm_neon.h:28:2: error: "NEON support not enabled"
> > > 
> > > There is no real need to build the file with -march=armv6 in a
> > > multi-CPU enabled kernel, as nothing in here will ever get called
> > > on an ARMv6 CPU. Adding -march=armv7 doesn't hurt and can only
> > > improve the code quality.
> > 
> > Is this enough to override a previous -mfpu for gcc?
> 
> I did not see any build failures on gcc with this, so I assume it
> has no effect. I could move the -march=armv7-a in front of
> -mfpu=neon if you think that would be safer though.

I don't know what's safer.  That's why I'm asking.  :-)


Nicolas


From will.deacon at arm.com  Fri Feb 19 09:13:30 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 19 Feb 2016 17:13:30 +0000
Subject: [PATCH] iommu/arm-smmu-v2: Add support for 16 bit VMID
In-Reply-To: <1455819817-8432-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1455819817-8432-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <20160219171329.GO27062@arm.com>

On Thu, Feb 18, 2016 at 10:23:37AM -0800, tchalamarla at caviumnetworks.com wrote:
> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> 
> ARM-SMMUv2 supports upto 16 bit VMID. This patch enables
> 16 bit VMID when requested from device-tree.
> 
> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> ---
>  .../devicetree/bindings/iommu/arm,smmu.txt          |  2 ++
>  drivers/iommu/arm-smmu.c                            | 21 ++++++++++++++++++++-
>  2 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index 7180745..bb7e569 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -55,6 +55,8 @@ conditions.
>                    aliases of secure registers have to be used during
>                    SMMU configuration.
>  
> +- smmu-enable-vmid16 : Enable 16 bit VMID, if allowed.

Why do we need a new property for this, given that we can detect it
from the ID registers? I can't think of a reason why we wouldn't use
16-bit VMIDs if they were available to us.

Will


From Chris.Brandt at renesas.com  Fri Feb 19 09:18:46 2016
From: Chris.Brandt at renesas.com (Chris Brandt)
Date: Fri, 19 Feb 2016 17:18:46 +0000
Subject: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values
In-Reply-To: <20160219164344.GY19428@n2100.arm.linux.org.uk>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <3974581.yknKb3tq7o@wuerfel>
 <HK2PR06MB056137892B6F968A8A1008C58AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
 <14272873.q312Ii8Axy@wuerfel> <20160219164344.GY19428@n2100.arm.linux.org.uk>
Message-ID: <HK2PR06MB0561C34E8FE1480224C2C6778AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>

On 19 Feb 2016, Russell King wrote:

> Using the DTB location on XIP platforms is a no-goer - the flattened
> DTB information can be fixed, so on an XIP platform it makes sense
> for this to also be in flash, not in RAM (the whole point of XIP is
> to remove constant data from RAM after all, so why would you want to
> copy the FDT to RAM?)

I was under the impression that the DTB had a limited life span, and once booted, it could be clobbered. Hence, RAM would not really be wasted (post boot that is).

For an XIP system (with MMU), if you have your DTB in ROM someplace, you run the risk of getting it cut off after the MMU setup is done because it would fall someplace after the _exiprom marker.


> Passing it in a register to the kernel image is also not possible:
> we've been out of spare registers for some time now for passing
> additional information into the kernel.  It wouldn't be a problem
> had folk not had this "eww, I don't like ATAGs, lets get rid of them
> and use DT instead" attitude: had we kept ATAGs, then we'd have an
> in-memory format to pass this kind of information to the kernel.
> That would solve soo many problems today it's untrue: stuff like
> where a debugging UART is located and the type of it...

Too bad we just couldn't have added an ATAG to point to a DTB. Sigh.


Chris



From cov at codeaurora.org  Fri Feb 19 09:20:37 2016
From: cov at codeaurora.org (Christopher Covington)
Date: Fri, 19 Feb 2016 12:20:37 -0500
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <56C733FE.8070308@hurleysoftware.com>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
 <56C470C5.2080203@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>
 <56C63FB5.2030907@hurleysoftware.com> <56C6F19D.7070206@linaro.org>
 <56C733FE.8070308@hurleysoftware.com>
Message-ID: <79D370BB-B7A3-4540-B7FB-81D5806853D6@codeaurora.org>



On February 19, 2016 10:25:50 AM EST, Peter Hurley <peter at hurleysoftware.com> wrote:
>On 02/19/2016 02:42 AM, Aleksey Makarov wrote:
>> Hi Peter,
>> 
>> Thank you for review.
>> 
>> On 02/19/2016 01:03 AM, Peter Hurley wrote:
>>> On 02/17/2016 07:36 PM, Zheng, Lv wrote:
>>>> Hi,
>>>>
>>>>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
>>>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>>>>> early_acpi_os_unmap_memory()
>>>>>
>>>>> Hi Lv,
>>>>>
>>>>> Thank you for review.
>>>>>
>>>>> On 02/17/2016 05:51 AM, Zheng, Lv wrote:
>>>>>
>>>>> [..]
>>>>>
>>>>>>>> early_acpi_os_unmap_memory() is marked as __init because it
>calls
>>>>>>>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is
>not
>>>>> set.
>>>>>>>>
>>>>>>>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>>>>> so it is safe to call early_acpi_os_unmap_memory() from
>anywhere
>>>>>>>>
>>>>>>>> We need this function to be non-__init because we need access
>to
>>>>>>>> some tables at unpredictable time--it may be before or after
>>>>>>>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port
>Console
>>>>>>>> Redirection) table is needed each time a new console is
>registered.
>>>>>>>> It can be quite early (console_initcall) or when a module is
>inserted.
>>>>>>>> When this table accessed before acpi_gbl_permanent_mmap is set,
>>>>>>>> the pointer should be unmapped.  This is exactly what this
>function
>>>>>>>> does.
>>>>>>> [Lv Zheng]
>>>>>>> Why don't you use another API instead of
>early_acpi_os_unmap_memory()
>>>>> in
>>>>>>> case you want to unmap things in any cases.
>>>>>>> acpi_os_unmap_memory() should be the one to match this purpose.
>>>>>>> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
>>>>>
>>>>> As far as I understand, there exist two steps in ACPI
>initialization:
>>>>>
>>>>> 1. Before acpi_gbl_permanent_mmap is set, tables received with
>>>>> acpi_get_table_with_size()
>>>>>    are mapped by early_memremap().  If a subsystem gets such a
>pointer it
>>>>> should be unmapped.
>>>>>
>>>>> 2  After acpi_gbl_permanent_mmap is set this pointer should not be
>unmapped
>>>>> at all.
>>>>>
>>>> [Lv Zheng] 
>>>> This statement is wrong, this should be:
>>>> As long as there is a __reference__ to the mapped table, the
>pointer should not be unmapped.
>>>> In fact, we have a series to introduce acpi_put_table() to achieve
>this.
>>>> So your argument is wrong from very first point.
>>>>
>>>>> That exactly what early_acpi_os_unmap_memory() does--it checks
>>>>> acpi_gbl_permanent_mmap.
>>>>> If I had used acpi_os_unmap_memory() after acpi_gbl_permanent_mmap
>had
>>>>> been set,
>>>>> it would have tried to free that pointer with an oops (actually, I
>checked that
>>>>> and got that oops).
>>>>>
>>>>> So using acpi_os_unmap_memory() is not an option here, but
>>>>> early_acpi_os_unmap_memory()
>>>>> match perfectly.
>>>> [Lv Zheng] 
>>>> I don't think so.
>>>> For definition block tables, we know for sure there will always be
>references, until "Unload" opcode is invoked by the AML interpreter.
>>>> But for the data tables, OSPMs should use them in this way:
>>>> 1. map the table
>>>> 2. parse the table and convert it to OS specific structures
>>>> 3. unmap the table
>>>> This helps to shrink virtual memory address space usages.
>>>>
>>>> So from this point of view, all data tables should be unmapped
>right after being parsed.
>>>> Why do you need the map to be persistent in the kernel address
>space?
>>>> You can always map a small table, but what if the table size is
>very big?
>>>>
>>>>>
>>>>>>> And in fact early_acpi_os_unmap_memory() should be removed.
>>>>>
>>>>> I don't think so -- I have explained why.  It does different
>thing.
>>>>> Probably it (and/or other functions in that api) should be
>renamed.
>>>>>
>>>> [Lv Zheng] 
>>>> Just let me ask one more question.
>>>> eary_acpi_os_unmap_memory() is not used inside of ACPICA.
>>>> How ACPICA can work with just acpi_os_unmap_memory()?
>>>> You can check drivers/acpi/tbxxx.c.
>>>> Especially: acpi_tb_release_temp_table() and the code invoking it.
>>>>
>>>>>> [Lv Zheng]
>>>>>> One more thing is:
>>>>>> If you can't switch your driver to use acpi_os_unmap_memory()
>instead of
>>>>> early_acpi_os_unmap_memory(),
>>>>>> then it implies that your driver does have a defect.
>>>>>
>>>>> I still don't understand what defect, sorry.
>>>> [Lv Zheng] 
>>>> If you can't ensure this sequence for using the data tables:
>>>> 1. map the table
>>>> 2. parse the table and convert it to OS specific structure
>>>> 3. unmap the table
>>>> It implies there is a bug in the driver or a bug in the ACPI
>subsystem core.
>>>
>>> Exactly.
>>>
>>> The central problem here is the way Aleksey is trying to hookup a
>console.
>>>
>>> What should be happening in this series is:
>>> 1. early map SPCR
>>> 2. parse the SPCR table
>>> 3. call add_preferred_console() to add the SPCR console to the
>console table
>>> 4. unmap SPCR
>> 
>> This does not work.  
>> 
>> SPCR specifies address of the console, but add_preferred_console()
>accepts
>> name of console and its index.  There are no general method to
>translate address
>> to name at such an early stage.
>
>
>	add_preferred_console(uart, 0, "io,0x3f8,115200");
>
>This will start a console with the 8250 driver. I've already pointed
>this out to you in an earlier review. This is what existing firmware
>already does.
>
>This is also the method you will use to start an earlycon from the
>DBG2 table, by additionally calling setup_earlycon().

Can the device specified in DBG2 be used for both earlycon and KGDB? If it can only be used for one, let's make sure the choice of earlycon vs KGDB is intentional rather than accidental.

Thanks,
Christopher Covington

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Sent from my Snapdragon powered Android device with K-9 Mail. Please excuse my brevity.


From yamada.masahiro at socionext.com  Fri Feb 19 09:29:54 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Sat, 20 Feb 2016 02:29:54 +0900
Subject: [PATCH] arm64, kbuild: make "make install" not depend on vmlinux
In-Reply-To: <1455861950-21832-1-git-send-email-yamada.masahiro@socionext.com>
References: <1455861950-21832-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <CAK7LNATs3Xkp05cYsUAhUtQuvrpo=dUe5R6+bQjcLdpPrG_S3w@mail.gmail.com>

Just for clarification:

This patch has been applied to arm64 tree.

Michal,
Just ignore this patch.



2016-02-19 15:05 GMT+09:00 Masahiro Yamada <yamada.masahiro at socionext.com>:
> For the same reason as commit 19514fc665ff (arm, kbuild: make "make
> install" not depend on vmlinux), the install targets should never
> trigger the rebuild of the kernel.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
> ---
>
>  arch/arm64/Makefile        |  2 +-
>  arch/arm64/boot/Makefile   |  4 ++--
>  arch/arm64/boot/install.sh | 14 ++++++++++++++
>  3 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 307237c..b5e3f6d 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -88,7 +88,7 @@ Image: vmlinux
>  Image.%: vmlinux
>         $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
>
> -zinstall install: vmlinux
> +zinstall install:
>         $(Q)$(MAKE) $(build)=$(boot) $@
>
>  %.dtb: scripts
> diff --git a/arch/arm64/boot/Makefile b/arch/arm64/boot/Makefile
> index abcbba2..305c552 100644
> --- a/arch/arm64/boot/Makefile
> +++ b/arch/arm64/boot/Makefile
> @@ -34,10 +34,10 @@ $(obj)/Image.lzma: $(obj)/Image FORCE
>  $(obj)/Image.lzo: $(obj)/Image FORCE
>         $(call if_changed,lzo)
>
> -install: $(obj)/Image
> +install:
>         $(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
>         $(obj)/Image System.map "$(INSTALL_PATH)"
>
> -zinstall: $(obj)/Image.gz
> +zinstall:
>         $(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
>         $(obj)/Image.gz System.map "$(INSTALL_PATH)"
> diff --git a/arch/arm64/boot/install.sh b/arch/arm64/boot/install.sh
> index 12ed78a..d91e1f0 100644
> --- a/arch/arm64/boot/install.sh
> +++ b/arch/arm64/boot/install.sh
> @@ -20,6 +20,20 @@
>  #   $4 - default install path (blank if root directory)
>  #
>
> +verify () {
> +       if [ ! -f "$1" ]; then
> +               echo ""                                                   1>&2
> +               echo " *** Missing file: $1"                              1>&2
> +               echo ' *** You need to run "make" before "make install".' 1>&2
> +               echo ""                                                   1>&2
> +               exit 1
> +       fi
> +}
> +
> +# Make sure the files actually exist
> +verify "$2"
> +verify "$3"
> +
>  # User may have a custom install script
>  if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi
>  if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} "$@"; fi
> --
> 1.9.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
Best Regards
Masahiro Yamada


From nicolas.pitre at linaro.org  Fri Feb 19 09:31:02 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 19 Feb 2016 12:31:02 -0500 (EST)
Subject: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values
In-Reply-To: <38246773.SnToSslHuj@wuerfel>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <3974581.yknKb3tq7o@wuerfel>
 <alpine.LFD.2.20.1602191106020.13632@knanqh.ubzr>
 <38246773.SnToSslHuj@wuerfel>
Message-ID: <alpine.LFD.2.20.1602191215140.13632@knanqh.ubzr>

On Fri, 19 Feb 2016, Arnd Bergmann wrote:

> On Friday 19 February 2016 11:10:22 Nicolas Pitre wrote:
> > On Fri, 19 Feb 2016, Arnd Bergmann wrote:
> > 
> > > On Thursday 18 February 2016 11:02:33 Nicolas Pitre wrote:
> > > > 
> > > > Acked-by: Nicolas Pitre <nico at linaro.org>
> > > > 
> > > > Is there a way to provide a default for defaults?
> ...
> > > and then select one of the bool symbols from each platform.
> > > Would that address your question?
> > 
> > Yes, but the ugliness factor isn't worth it IMHO.
> > 
> > I was wondering if something like this was possible:
> > 
> > config PHYS_OFFSET
> >         hex "Physical address of main memory" if MMU
> >         default DRAM_BASE if !MMU
> >         default 0x10000000 if FOO
> >         default 0x20000000 if BAR
> >         default 0x30000000 if BAZ
> >         default 0x00000000
> > 
> 
> Ah, that was my previous approach, but Russell didn't like
> how it makes it easier to fall back to an incorrect address
> instead of forcing a build error when the address is not
> configured.

Makes sense.

Yet, the only reason for a default here is to accommodate automatic 
build tests like randconfig, right?

If so then this should be "fixed" by having the config system provide 
built-in symbols that can be tested from kconfig files.  This way you 
could terminate the above list with:

	default 0x00000000 if RANDCONFIG || ALLYESCONFIG

or the like.


Nicolas


From catalin.marinas at arm.com  Fri Feb 19 09:34:11 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Feb 2016 17:34:11 +0000
Subject: [PATCH v6sub1 00/11] arm64: split linear and kernel mappings
In-Reply-To: <CAKv+Gu-3y9LoxM9swbwZuXXxuMppnWzd=PmyALa+P0NhvR7mtw@mail.gmail.com>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160218182509.GG2538@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_UqoYB5QAWOU9_iZDoRO=rqHu8o87JboSAqNqOhoOCXw@mail.gmail.com>
 <CAKv+Gu_25mz37gdgVx5Yz7DJ+QbOMNa4rYBymFL1nL7nGOzBVQ@mail.gmail.com>
 <CAKv+Gu8aKDtev2LdGMy9a485Z8S7TYgsbXky6wR6e3F+j2nkUQ@mail.gmail.com>
 <20160219142551.GA12864@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_44=2NMuon694T_YW6QUU-ixC+q_7WxbMtBuN3dRNP2Q@mail.gmail.com>
 <CAKv+Gu9WTVrYmc7GwxDeHppSHoRmSS4nK5iG3HZVMOPcPP1MOw@mail.gmail.com>
 <20160219143701.GB12864@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-3y9LoxM9swbwZuXXxuMppnWzd=PmyALa+P0NhvR7mtw@mail.gmail.com>
Message-ID: <20160219173411.GE12864@e104818-lin.cambridge.arm.com>

On Fri, Feb 19, 2016 at 03:40:32PM +0100, Ard Biesheuvel wrote:
> On 19 February 2016 at 15:37, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Fri, Feb 19, 2016 at 03:29:13PM +0100, Ard Biesheuvel wrote:
> >> On 19 February 2016 at 15:27, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> >> > On 19 February 2016 at 15:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> >> On Fri, Feb 19, 2016 at 09:05:25AM +0100, Ard Biesheuvel wrote:
> >> >>> So it appears that akpm will need to drop that patch anyway, as he
> >> >>> won't be able to carry an updated version since he does not have the
> >> >>> UAO patches. That means it probably makes even more sense to take
> >> >>> those through the arm64 tree as well (minus the x86 one, which has a
> >> >>> conflict now as well). In fact, perhaps it makes sense to only take
> >> >>> the base patch and the arm64 patch, and I can send the remaining ones
> >> >>> to the various maintainers (or akpm) for v4.7
> >> >>
> >> >> Or we make BUILDTIME_EXTABLE_SORT depend on !RANDOMIZE_BASE until we
> >> >> sort out the extable patches.
> >> >
> >> > That would still result in breakage once the current version queued by
> >> > akpm hits mainline.
> >>
> >> ... or in other words, the breakage is already in -next. This is
> >> completely unrelated to the sorting, btw, but due to the difference
> >> between relative/absolute
> >
> > Ah, I now realised that it was only working fine for me before merging
> > the EFI patches to actually do the base randomisation. Once we fully
> > randomise the load address, we must have relative extable.
> >
> > Is your branch updated with the patches needed for arm64 (against
> > for-next/core)?
> 
> Yes. I dropped the kallsyms patches, and included only the base and
> arm64 extable patches, with the UAO issue fixed.
> 
> https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-kaslr-v6
> git://git.linaro.org/people/ard.biesheuvel/linux-arm.git arm64-kaslr-v6

I pushed these patches to the arm64 for-next/kaslr for now, rebased
against the latest for-next/core branch. There was one commit
(e9ee71275034 arm64: add support for module PLTs) which inadvertently
got some extra information in the log but I found it useful, so I kept
it. If nothing else falls, I'll push them into -next on Monday.

I noticed that we still have MODULES_VADDR around and used in couple of
places (printing the kernel memory layout during init, debugfs
kernel_page_tables and KASAN). Shouldn't we use module_alloc_base
instead?

-- 
Catalin


From ard.biesheuvel at linaro.org  Fri Feb 19 09:38:19 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 19 Feb 2016 18:38:19 +0100
Subject: [PATCH v6sub1 00/11] arm64: split linear and kernel mappings
In-Reply-To: <20160219173411.GE12864@e104818-lin.cambridge.arm.com>
References: <1455627162-31600-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160218182509.GG2538@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_UqoYB5QAWOU9_iZDoRO=rqHu8o87JboSAqNqOhoOCXw@mail.gmail.com>
 <CAKv+Gu_25mz37gdgVx5Yz7DJ+QbOMNa4rYBymFL1nL7nGOzBVQ@mail.gmail.com>
 <CAKv+Gu8aKDtev2LdGMy9a485Z8S7TYgsbXky6wR6e3F+j2nkUQ@mail.gmail.com>
 <20160219142551.GA12864@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_44=2NMuon694T_YW6QUU-ixC+q_7WxbMtBuN3dRNP2Q@mail.gmail.com>
 <CAKv+Gu9WTVrYmc7GwxDeHppSHoRmSS4nK5iG3HZVMOPcPP1MOw@mail.gmail.com>
 <20160219143701.GB12864@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-3y9LoxM9swbwZuXXxuMppnWzd=PmyALa+P0NhvR7mtw@mail.gmail.com>
 <20160219173411.GE12864@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu9L4DZjnBPbTUY8bXBLZexCAJpqhV=YBm5EYaq868_mSg@mail.gmail.com>

On 19 February 2016 at 18:34, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Fri, Feb 19, 2016 at 03:40:32PM +0100, Ard Biesheuvel wrote:
>> On 19 February 2016 at 15:37, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > On Fri, Feb 19, 2016 at 03:29:13PM +0100, Ard Biesheuvel wrote:
>> >> On 19 February 2016 at 15:27, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>> >> > On 19 February 2016 at 15:25, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> >> >> On Fri, Feb 19, 2016 at 09:05:25AM +0100, Ard Biesheuvel wrote:
>> >> >>> So it appears that akpm will need to drop that patch anyway, as he
>> >> >>> won't be able to carry an updated version since he does not have the
>> >> >>> UAO patches. That means it probably makes even more sense to take
>> >> >>> those through the arm64 tree as well (minus the x86 one, which has a
>> >> >>> conflict now as well). In fact, perhaps it makes sense to only take
>> >> >>> the base patch and the arm64 patch, and I can send the remaining ones
>> >> >>> to the various maintainers (or akpm) for v4.7
>> >> >>
>> >> >> Or we make BUILDTIME_EXTABLE_SORT depend on !RANDOMIZE_BASE until we
>> >> >> sort out the extable patches.
>> >> >
>> >> > That would still result in breakage once the current version queued by
>> >> > akpm hits mainline.
>> >>
>> >> ... or in other words, the breakage is already in -next. This is
>> >> completely unrelated to the sorting, btw, but due to the difference
>> >> between relative/absolute
>> >
>> > Ah, I now realised that it was only working fine for me before merging
>> > the EFI patches to actually do the base randomisation. Once we fully
>> > randomise the load address, we must have relative extable.
>> >
>> > Is your branch updated with the patches needed for arm64 (against
>> > for-next/core)?
>>
>> Yes. I dropped the kallsyms patches, and included only the base and
>> arm64 extable patches, with the UAO issue fixed.
>>
>> https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-kaslr-v6
>> git://git.linaro.org/people/ard.biesheuvel/linux-arm.git arm64-kaslr-v6
>
> I pushed these patches to the arm64 for-next/kaslr for now, rebased
> against the latest for-next/core branch. There was one commit
> (e9ee71275034 arm64: add support for module PLTs) which inadvertently
> got some extra information in the log but I found it useful, so I kept
> it. If nothing else falls, I'll push them into -next on Monday.
>

OK

> I noticed that we still have MODULES_VADDR around and used in couple of
> places (printing the kernel memory layout during init, debugfs
> kernel_page_tables and KASAN). Shouldn't we use module_alloc_base
> instead?
>

For KASAN, I updated the patches so that the modules are always
allocated in the original module region, to prevent issues with the
zero shadow that backs the vmalloc region.

For the other purposes, it is really a matter of taste. The reserved
region still exists, KASLR or not, so if you omit it, you will have a
hole in the memory map. For the page table dumper, i did not add a
special section for the kernel either.

I'm happy to propose a patch that changes that, once we (you) decide
what you want to see.

-- 
Ard.


From catalin.marinas at arm.com  Fri Feb 19 09:43:49 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Feb 2016 17:43:49 +0000
Subject: [PATCH v6sub1 00/11] arm64: split linear and kernel mappings
In-Reply-To: <CAKv+Gu9L4DZjnBPbTUY8bXBLZexCAJpqhV=YBm5EYaq868_mSg@mail.gmail.com>
References: <CAKv+Gu_UqoYB5QAWOU9_iZDoRO=rqHu8o87JboSAqNqOhoOCXw@mail.gmail.com>
 <CAKv+Gu_25mz37gdgVx5Yz7DJ+QbOMNa4rYBymFL1nL7nGOzBVQ@mail.gmail.com>
 <CAKv+Gu8aKDtev2LdGMy9a485Z8S7TYgsbXky6wR6e3F+j2nkUQ@mail.gmail.com>
 <20160219142551.GA12864@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_44=2NMuon694T_YW6QUU-ixC+q_7WxbMtBuN3dRNP2Q@mail.gmail.com>
 <CAKv+Gu9WTVrYmc7GwxDeHppSHoRmSS4nK5iG3HZVMOPcPP1MOw@mail.gmail.com>
 <20160219143701.GB12864@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-3y9LoxM9swbwZuXXxuMppnWzd=PmyALa+P0NhvR7mtw@mail.gmail.com>
 <20160219173411.GE12864@e104818-lin.cambridge.arm.com>
 <CAKv+Gu9L4DZjnBPbTUY8bXBLZexCAJpqhV=YBm5EYaq868_mSg@mail.gmail.com>
Message-ID: <20160219174349.GF12864@e104818-lin.cambridge.arm.com>

On Fri, Feb 19, 2016 at 06:38:19PM +0100, Ard Biesheuvel wrote:
> > I noticed that we still have MODULES_VADDR around and used in couple of
> > places (printing the kernel memory layout during init, debugfs
> > kernel_page_tables and KASAN). Shouldn't we use module_alloc_base
> > instead?
> 
> For KASAN, I updated the patches so that the modules are always
> allocated in the original module region, to prevent issues with the
> zero shadow that backs the vmalloc region.

Ah, I forgot about this.

> For the other purposes, it is really a matter of taste. The reserved
> region still exists, KASLR or not, so if you omit it, you will have a
> hole in the memory map. For the page table dumper, i did not add a
> special section for the kernel either.
> 
> I'm happy to propose a patch that changes that, once we (you) decide
> what you want to see.

Leave it as it is for now.

-- 
Catalin


From lho at apm.com  Fri Feb 19 09:44:32 2016
From: lho at apm.com (Loc Ho)
Date: Fri, 19 Feb 2016 09:44:32 -0800
Subject: [PATCH v7 3/3] arm64: dts: Update X-Gene standby GPIO controller
 DTS entries
In-Reply-To: <CAFopSPR133CT5t2ck2_F3Zzh8gWosLpXFpYi-5VBBhVScOkvjA@mail.gmail.com>
References: <1455714909-3027-1-git-send-email-qnguyen@apm.com>
 <1455714909-3027-4-git-send-email-qnguyen@apm.com>
 <CACRpkdav6UXn41UnWvWR4zjYN=QtkNJknihr+YnHu3rXbkPBBw@mail.gmail.com>
 <CAFopSPR133CT5t2ck2_F3Zzh8gWosLpXFpYi-5VBBhVScOkvjA@mail.gmail.com>
Message-ID: <CAPw-ZTmAe64XbXZ4OWJOec7YMEQcgf7ZrfUsZWG6Yjc1ON0K+w@mail.gmail.com>

Hi Quan,

On Fri, Feb 19, 2016 at 5:47 AM, Quan Nguyen <qnguyen at apm.com> wrote:
> On Fri, Feb 19, 2016 at 4:14 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
>> On Wed, Feb 17, 2016 at 2:15 PM, Quan Nguyen <qnguyen at apm.com> wrote:
>>
>>> Update APM X-Gene standby GPIO controller DTS entries to enable it
>>> as interrupt controller.
>>>
>>> Signed-off-by: Y Vo <yvo at apm.com>
>>> Signed-off-by: Quan Nguyen <qnguyen at apm.com>
>>
>> Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
>>
>> Please funnel this patch through the ARM SoC tree with all other
>> DTS files.
>
> Let me do it and resend.

Duc will pull  this into xgene-next GIT for Olof to pull.

-Loc


From jeremy.linton at arm.com  Fri Feb 19 09:46:21 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Fri, 19 Feb 2016 11:46:21 -0600
Subject: [PATCH v3 0/2] flag contiguous PTEs in linear mapping
Message-ID: <1455903983-23910-1-git-send-email-jeremy.linton@arm.com>

This is a rebase of the previous contiguous ptes in linear map patches
on top of Mark Rutland's fixmap changes. Those changes appear to be sufficient
to allow this patch set to boot on JunoR2, Seattle and the xgene/m400. I've
also done basic testing with RODATA turned on. In all cases with ACPI systems.

This patch also adds the ability to align 64k kernels on the 2M CONT boundary
which helps to assure that a number of the sections are completely mapped with
CONT bits. There remain a number of holes due to smaller remapping operations
that don't really affect the page protection states. That can be worked around
in a number of cases if the code gets smart enough to detect that the break
doesn't result in an actual change in permissions. Some of these are visible
in the included example where its not initially obvious why a contiguous 2M
region isn't marked as such until digging into it.

Changed v1->v2:
    16k kernels now use CONT_SIZE rather than SECTION_SIZE for alignment.
Changed v2->v3:
    Updated commit log, and Kconfig description to explicitly state 2M alignment
    Added Ard's Reviewed by.

With 64k pages, and section alignment enabled the kernel looks like:
---[ Kernel Mapping ]---
0xfffffe0000000000-0xfffffe0000200000           2M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0000200000-0xfffffe0001200000          16M     ro x  SHD AF    CON     UXN MEM/NORMAL
0xfffffe0001200000-0xfffffe0001400000           2M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0001400000-0xfffffe0001600000           2M     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe0001600000-0xfffffe0002600000          16M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0002600000-0xfffffe0002800000           2M     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe0002800000-0xfffffe0020000000         472M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0020000000-0xfffffe0060000000           1G     RW NX SHD AF        BLK UXN MEM/NORMAL
0xfffffe00600f0000-0xfffffe0060200000        1088K     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe0060200000-0xfffffe0076400000         354M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0076400000-0xfffffe0076600000           2M     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe0076600000-0xfffffe0078e00000          40M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe00793b0000-0xfffffe0079400000         320K     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe0079400000-0xfffffe007e200000          78M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe007e200000-0xfffffe007e3d0000        1856K     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe007e420000-0xfffffe007e600000        1920K     RW NX SHD AF            UXN MEM/NORMAL
0xfffffe007e600000-0xfffffe007f000000          10M     RW NX SHD AF    CON     UXN MEM/NORMAL
0xfffffe0800000000-0xfffffe0980000000           6G     RW NX SHD AF        BLK UXN MEM/NORMAL

With 4k pages
---[ Kernel Mapping ]---
0xffffffc000000000-0xffffffc000200000           2M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc000200000-0xffffffc001200000          16M     ro x  SHD AF        BLK UXN MEM/NORMAL
0xffffffc001200000-0xffffffc001400000           2M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc001400000-0xffffffc0015c0000        1792K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc0015c0000-0xffffffc0015d0000          64K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc0015d0000-0xffffffc001600000         192K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc001600000-0xffffffc002600000          16M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc002600000-0xffffffc002620000         128K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc002620000-0xffffffc002630000          64K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc002630000-0xffffffc002800000        1856K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc002800000-0xffffffc060000000        1496M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc0600f0000-0xffffffc060200000        1088K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc060200000-0xffffffc076400000         354M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc076400000-0xffffffc076590000        1600K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc076590000-0xffffffc076595000          20K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc076596000-0xffffffc0765a0000          40K     RW NX SHD AF            UXN MEM/NORMAL
0xffffffc0765a0000-0xffffffc076600000         384K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc076600000-0xffffffc078e00000          40M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc0793b0000-0xffffffc079400000         320K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc079400000-0xffffffc07e200000          78M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc07e200000-0xffffffc07e3d0000        1856K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc07e420000-0xffffffc07e600000        1920K     RW NX SHD AF    CON     UXN MEM/NORMAL
0xffffffc07e600000-0xffffffc07f000000          10M     RW NX SHD AF        BLK UXN MEM/NORMAL
0xffffffc800000000-0xffffffc980000000           6G     RW NX SHD AF        BLK UXN MEM/NORMAL

Jeremy Linton (2):
  arm64: mm: Enable CONT_SIZE aligned sections for 64k page kernels.
  arm64: Mark kernel page ranges contiguous

 arch/arm64/Kconfig.debug        | 13 +++++----
 arch/arm64/kernel/vmlinux.lds.S | 11 +++----
 arch/arm64/mm/mmu.c             | 64 +++++++++++++++++++++++++++++++++++++----
 3 files changed, 71 insertions(+), 17 deletions(-)

-- 
2.4.3



From jeremy.linton at arm.com  Fri Feb 19 09:46:22 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Fri, 19 Feb 2016 11:46:22 -0600
Subject: [PATCH v3 1/2] arm64: mm: Enable CONT_SIZE aligned sections for 64k
 page kernels.
In-Reply-To: <1455903983-23910-1-git-send-email-jeremy.linton@arm.com>
References: <1455903983-23910-1-git-send-email-jeremy.linton@arm.com>
Message-ID: <1455903983-23910-2-git-send-email-jeremy.linton@arm.com>

This change allows ALIGN_RODATA for 64k and 16k kernels.
In the case of 64k/16k kernels it actually aligns to the CONT_SIZE (2M)
rather than the SECTION_SIZE (which is 512M/32M). This makes it generally
more useful, given contiguous hit enabled kernels.

Reviewed-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
---
 arch/arm64/Kconfig.debug        | 13 +++++++------
 arch/arm64/kernel/vmlinux.lds.S | 11 ++++++-----
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
index e13c4bf..9d33d5e 100644
--- a/arch/arm64/Kconfig.debug
+++ b/arch/arm64/Kconfig.debug
@@ -59,15 +59,16 @@ config DEBUG_RODATA
           If in doubt, say Y
 
 config DEBUG_ALIGN_RODATA
-	depends on DEBUG_RODATA && ARM64_4K_PAGES
+	depends on DEBUG_RODATA
 	bool "Align linker sections up to SECTION_SIZE"
 	help
 	  If this option is enabled, sections that may potentially be marked as
-	  read only or non-executable will be aligned up to the section size of
-	  the kernel. This prevents sections from being split into pages and
-	  avoids a potential TLB penalty. The downside is an increase in
-	  alignment and potentially wasted space. Turn on this option if
-	  performance is more important than memory pressure.
+	  read only or non-executable will be aligned up to the section size
+	  or contiguous hint size of the kernel (2 MiB). This prevents sections
+	  from being split into pages and avoids a potential TLB penalty. The
+	  downside is an increase in alignment and potentially wasted space.
+	  Turn on this option if performance is more important than memory
+	  pressure.
 
 	  If in doubt, say N
 
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index b78a3c7..8f4fc2c 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -63,13 +63,14 @@ PECOFF_FILE_ALIGNMENT = 0x200;
 #endif
 
 #if defined(CONFIG_DEBUG_ALIGN_RODATA)
-#define ALIGN_DEBUG_RO			. = ALIGN(1<<SECTION_SHIFT);
-#define ALIGN_DEBUG_RO_MIN(min)		ALIGN_DEBUG_RO
+#if defined(CONFIG_ARM64_4K_PAGES)
+#define ALIGN_DEBUG_RO_MIN(min)		. = ALIGN(SECTION_SIZE);
+#else
+#define ALIGN_DEBUG_RO_MIN(min)		. = ALIGN(CONT_SIZE);
+#endif
 #elif defined(CONFIG_DEBUG_RODATA)
-#define ALIGN_DEBUG_RO			. = ALIGN(1<<PAGE_SHIFT);
-#define ALIGN_DEBUG_RO_MIN(min)		ALIGN_DEBUG_RO
+#define ALIGN_DEBUG_RO_MIN(min)		. = ALIGN(PAGE_SIZE);
 #else
-#define ALIGN_DEBUG_RO
 #define ALIGN_DEBUG_RO_MIN(min)		. = ALIGN(min);
 #endif
 
-- 
2.4.3



From jeremy.linton at arm.com  Fri Feb 19 09:46:23 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Fri, 19 Feb 2016 11:46:23 -0600
Subject: [PATCH v3 2/2] arm64: Mark kernel page ranges contiguous
In-Reply-To: <1455903983-23910-1-git-send-email-jeremy.linton@arm.com>
References: <1455903983-23910-1-git-send-email-jeremy.linton@arm.com>
Message-ID: <1455903983-23910-3-git-send-email-jeremy.linton@arm.com>

With 64k pages, the next larger segment size is 512M. The linux
kernel also uses different protection flags to cover its code and data.
Because of these requirements, the vast majority of the kernel code and
data structures end up being mapped with 64k pages instead of the larger
pages common with a 4k page kernel.

Recent ARM processors support a contiguous bit in the
page tables which allows a TLB to cover a range larger than a
single PTE if that range is mapped into physically contiguous
RAM.

So, for the kernel its a good idea to set this flag. Some basic
micro benchmarks show it can significantly reduce the number of
L1 dTLB refills.

Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
---
 arch/arm64/mm/mmu.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 58 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 7711554..ab69a99 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1,3 +1,4 @@
+
 /*
  * Based on arch/arm/mm/mmu.c
  *
@@ -103,17 +104,49 @@ static void split_pmd(pmd_t *pmd, pte_t *pte)
 		 * Need to have the least restrictive permissions available
 		 * permissions will be fixed up later
 		 */
-		set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC));
+		set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC_CONT));
 		pfn++;
 	} while (pte++, i++, i < PTRS_PER_PTE);
 }
 
+static void clear_cont_pte_range(pte_t *pte, unsigned long addr)
+{
+	int i;
+
+	pte -= CONT_RANGE_OFFSET(addr);
+	for (i = 0; i < CONT_PTES; i++) {
+		if (pte_cont(*pte))
+			set_pte(pte, pte_mknoncont(*pte));
+		pte++;
+	}
+	flush_tlb_all();
+}
+
+/*
+ * Given a range of PTEs set the pfn and provided page protection flags
+ */
+static void __populate_init_pte(pte_t *pte, unsigned long addr,
+			       unsigned long end, phys_addr_t phys,
+			       pgprot_t prot)
+{
+	unsigned long pfn = __phys_to_pfn(phys);
+
+	do {
+		/* clear all the bits except the pfn, then apply the prot */
+		set_pte(pte, pfn_pte(pfn, prot));
+		pte++;
+		pfn++;
+		addr += PAGE_SIZE;
+	} while (addr != end);
+}
+
 static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
-				  unsigned long end, unsigned long pfn,
+				  unsigned long end, phys_addr_t phys,
 				  pgprot_t prot,
 				  phys_addr_t (*pgtable_alloc)(void))
 {
 	pte_t *pte;
+	unsigned long next;
 
 	if (pmd_none(*pmd) || pmd_sect(*pmd)) {
 		phys_addr_t pte_phys = pgtable_alloc();
@@ -127,10 +160,29 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
 	BUG_ON(pmd_bad(*pmd));
 
 	pte = pte_set_fixmap_offset(pmd, addr);
+
 	do {
-		set_pte(pte, pfn_pte(pfn, prot));
-		pfn++;
-	} while (pte++, addr += PAGE_SIZE, addr != end);
+		next = min(end, (addr + CONT_SIZE) & CONT_MASK);
+		if (((addr | next | phys) & ~CONT_MASK) == 0) {
+			/* a block of CONT_PTES	 */
+			__populate_init_pte(pte, addr, next, phys,
+					    prot | __pgprot(PTE_CONT));
+		} else {
+			/*
+			 * If the range being split is already inside of a
+			 * contiguous range but this PTE isn't going to be
+			 * contiguous, then we want to unmark the adjacent
+			 * ranges, then update the portion of the range we
+			 * are interrested in.
+			 */
+			clear_cont_pte_range(pte, addr);
+			__populate_init_pte(pte, addr, next, phys, prot);
+		}
+
+		pte += (next - addr) >> PAGE_SHIFT;
+		phys += next - addr;
+		addr = next;
+	} while (addr != end);
 
 	pte_clear_fixmap();
 }
@@ -194,7 +246,7 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
 				}
 			}
 		} else {
-			alloc_init_pte(pmd, addr, next, __phys_to_pfn(phys),
+			alloc_init_pte(pmd, addr, next, phys,
 				       prot, pgtable_alloc);
 		}
 		phys += next - addr;
-- 
2.4.3



From jeremy.linton at arm.com  Fri Feb 19 09:50:32 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Fri, 19 Feb 2016 11:50:32 -0600
Subject: [PATCH v3] arm64: mm: Mark .rodata as RO
Message-ID: <1455904232-24053-1-git-send-email-jeremy.linton@arm.com>

Currently the .rodata section is actually still executable when DEBUG_RODATA
is enabled. This changes that so the .rodata is actually read only, no execute.
It also adds the .rodata section to the mem_init banner.

Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
---
 arch/arm64/kernel/vmlinux.lds.S |  5 +++--
 arch/arm64/mm/init.c            |  4 +++-
 arch/arm64/mm/mmu.c             | 17 +++++++++++++----
 3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 8f4fc2c..9208f53 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -114,8 +114,9 @@ SECTIONS
 		*(.got)			/* Global offset table		*/
 	}
 
-	RO_DATA(PAGE_SIZE)
-	EXCEPTION_TABLE(8)
+	ALIGN_DEBUG_RO_MIN(0)
+	RO_DATA(PAGE_SIZE)		/* everything from this point to */
+	EXCEPTION_TABLE(8)		/* _etext will be marked RO NX   */
 	NOTES
 
 	ALIGN_DEBUG_RO_MIN(PAGE_SIZE)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5dd0831..41be7db 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -325,6 +325,7 @@ void __init mem_init(void)
 		  "    memory  : 0x%16lx - 0x%16lx   (%6ld MB)\n"
 		  "      .init : 0x%p" " - 0x%p" "   (%6ld KB)\n"
 		  "      .text : 0x%p" " - 0x%p" "   (%6ld KB)\n"
+		  "    .rodata : 0x%p" " - 0x%p" "   (%6ld KB)\n"
 		  "      .data : 0x%p" " - 0x%p" "   (%6ld KB)\n",
 #ifdef CONFIG_KASAN
 		  MLG(KASAN_SHADOW_START, KASAN_SHADOW_END),
@@ -341,7 +342,8 @@ void __init mem_init(void)
 		  MLM(MODULES_VADDR, MODULES_END),
 		  MLM(PAGE_OFFSET, (unsigned long)high_memory),
 		  MLK_ROUNDUP(__init_begin, __init_end),
-		  MLK_ROUNDUP(_text, _etext),
+		  MLK_ROUNDUP(_text, __start_rodata),
+		  MLK_ROUNDUP(__start_rodata, _etext),
 		  MLK_ROUNDUP(_sdata, _edata));
 
 #undef MLK
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index ab69a99..a18dfd0 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -453,10 +453,18 @@ static void __init map_mem(pgd_t *pgd)
 #ifdef CONFIG_DEBUG_RODATA
 void mark_rodata_ro(void)
 {
-	create_mapping_late(__pa(_stext), (unsigned long)_stext,
-				(unsigned long)_etext - (unsigned long)_stext,
-				PAGE_KERNEL_ROX);
+	unsigned long section_size;
 
+	section_size = (unsigned long)__start_rodata - (unsigned long)_stext;
+	create_mapping_late(__pa(_stext), (unsigned long)_stext,
+			    section_size, PAGE_KERNEL_ROX);
+	/*
+	 * mark .rodata as read only. Use _etext rather than __end_rodata to
+	 * cover NOTES and EXCEPTION_TABLE.
+	 */
+	section_size = (unsigned long)_etext - (unsigned long)__start_rodata;
+	create_mapping_late(__pa(__start_rodata), (unsigned long)__start_rodata,
+			    section_size, PAGE_KERNEL_RO);
 }
 #endif
 
@@ -486,7 +494,8 @@ static void __init map_kernel_chunk(pgd_t *pgd, void *va_start, void *va_end,
 static void __init map_kernel(pgd_t *pgd)
 {
 
-	map_kernel_chunk(pgd, _stext, _etext, PAGE_KERNEL_EXEC);
+	map_kernel_chunk(pgd, _stext, __start_rodata, PAGE_KERNEL_EXEC);
+	map_kernel_chunk(pgd, __start_rodata, _etext, PAGE_KERNEL);
 	map_kernel_chunk(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC);
 	map_kernel_chunk(pgd, _data, _end, PAGE_KERNEL);
 
-- 
2.4.3



From nicolas.pitre at linaro.org  Fri Feb 19 09:57:43 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 19 Feb 2016 12:57:43 -0500 (EST)
Subject: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values
In-Reply-To: <20160219164344.GY19428@n2100.arm.linux.org.uk>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <3974581.yknKb3tq7o@wuerfel>
 <HK2PR06MB056137892B6F968A8A1008C58AA00@HK2PR06MB0561.apcprd06.prod.outlook.com>
 <14272873.q312Ii8Axy@wuerfel> <20160219164344.GY19428@n2100.arm.linux.org.uk>
Message-ID: <alpine.LFD.2.20.1602191239020.13632@knanqh.ubzr>

On Fri, 19 Feb 2016, Russell King - ARM Linux wrote:

> ARM_PATCH_PHYS_VIRT exists to support an init-time decided phys offset,
> and it supports this by modifying each location that the phys offset
> is used.  It determines this by looking at the location that the early
> init code is executing, and masking the PC with a value that has been
> carefully crafted to fit 99% of the existing platforms.
> 
> One of the side effects of ARM_PATCH_PHYS_VIRT is that we hide the
> translation from the compiler, so the compiler is unable to optimise
> things like virt_to_phys(phys_to_virt(x)) to just 'x' (and yes, such
> things do happen.)
> 
> PHYS_OFFSET exists to cater for the case where ARM_PATCH_PHYS_VIRT is
> disabled, because either ARM_PATCH_PHYS_VIRT does not work for the
> platform, or the platform has special requirements and/or requires
> better performance.  It switches back to the pre-ARM_PATCH_PHYS_VIRT
> situation where the PHYS_OFFSET is a compile time constant.
> 
> Obviously, making PHYS_OFFSET a runtime variable is basically what
> ARM_PATCH_PHYS_VIRT is doing.  That does not help these cases though,
> because the problem cases are not whether it's a runtime variable or
> not, it's how to arrive at the value for it in the first place.

I think what Chris was suggesting is to have the same functionality as 
PATCH_PHYS_VIRT i.e. determining phys offset at run time while being 
XIP.  In theory that could mean that the kernel binary becomes 
independent of the physical location in flash where it executes from.

Arriving at the value for phys offset could be done based on sp instead 
of pc.  That's assuming the bootloader did not clobber sp before calling 
into the kernel.

But this is rather fragile. And normally if you are interested in XIP, 
you certainly have a highly customized kernel config already anyway. And 
having a build-time constant PHYS_OFFSET is of course what performs 
best.


Nicolas


From tony at atomide.com  Fri Feb 19 10:02:38 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Feb 2016 10:02:38 -0800
Subject: [PATCH] ARM: OMAP2+: allow DEBUG_UNCOMPRESS for OMAP2+
In-Reply-To: <1451362159-27910-1-git-send-email-sdliyong@gmail.com>
References: <1451362159-27910-1-git-send-email-sdliyong@gmail.com>
Message-ID: <20160219180237.GI21202@atomide.com>

Hi,

* Yong Li <sdliyong at gmail.com> [151228 20:12]:
> Based on the below
> commit ae3c99a26c60 ("ARM: 7806/1: allow DEBUG_UNCOMPRESS for Tegra"),
> change the .data section to .text section,
> to enable DEBUG_UNCOMPRESS for OMAP2+ platforms
> Tested okay using BeagleBone Black

Sorry for the delay, I just noticed this one while looking
through my inbox for pending patches.

I think we should first simplify things by moving things over
to use the generic DEBUG_UART_8250 code where the addresses
need to be specified in the .config. It's been on my list of
things to do for quite a while but I keep getting interrupted.

My guess is that if we do that, this patch is no longer
needed :) Yong, care to take a look at that?

Regards,

Tony

> Signed-off-by: Yong Li <sdliyong at gmail.com>
> ---
>  arch/arm/Kconfig.debug             |  2 +-
>  arch/arm/include/debug/omap2plus.S | 13 ++++++++++---
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 259c0ca..e5ae36a 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -1596,7 +1596,7 @@ config DEBUG_UART_8250_FLOW_CONTROL
>  config DEBUG_UNCOMPRESS
>  	bool
>  	depends on ARCH_MULTIPLATFORM || PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
> -	default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \
> +	default y if DEBUG_LL && (!DEBUG_OMAP2PLUS_UART || !ZBOOT_ROM) && \
>  		     (!DEBUG_TEGRA_UART || !ZBOOT_ROM)
>  	help
>  	  This option influences the normal decompressor output for
> diff --git a/arch/arm/include/debug/omap2plus.S b/arch/arm/include/debug/omap2plus.S
> index 6d867ae..12421f9 100644
> --- a/arch/arm/include/debug/omap2plus.S
> +++ b/arch/arm/include/debug/omap2plus.S
> @@ -58,11 +58,18 @@
>  
>  #define UART_OFFSET(addr)	((addr) & 0x00ffffff)
>  
> +#if defined(ZIMAGE)
> +	omap_uart_phys:	.word	0
> +	omap_uart_virt:	.word	0
> +	omap_uart_lsr:	.word	0
> +#else
> +
>  		.pushsection .data
> -omap_uart_phys:	.word	0
> -omap_uart_virt:	.word	0
> -omap_uart_lsr:	.word	0
> +	omap_uart_phys:	.word	0
> +	omap_uart_virt:	.word	0
> +	omap_uart_lsr:	.word	0
>  		.popsection
> +#endif
>  
>  		.macro	addruart, rp, rv, tmp
>  
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From tony at atomide.com  Fri Feb 19 10:07:12 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Feb 2016 10:07:12 -0800
Subject: [PATCH 1/2] ARM: OMAP1: DMA: Provide dma_slave_map to omap-dma
In-Reply-To: <1454423227-31830-2-git-send-email-peter.ujfalusi@ti.com>
References: <1454423227-31830-1-git-send-email-peter.ujfalusi@ti.com>
 <1454423227-31830-2-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <20160219180711.GJ21202@atomide.com>

* Peter Ujfalusi <peter.ujfalusi at ti.com> [160202 06:28]:
> OMAP1 can not boot in DT mode and to be able to clean up the driver
> regarding to the dmaengine API use (switching to the new API) the
> device/slave -> filter mapping needs to be provided to the omap-dma driver.

Aaro, care to ack this one?

Regards,

Tony

> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> ---
>  arch/arm/mach-omap1/dma.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
> 
> diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
> index 7b02ed218a42..f6ba589cd312 100644
> --- a/arch/arm/mach-omap1/dma.c
> +++ b/arch/arm/mach-omap1/dma.c
> @@ -25,6 +25,7 @@
>  #include <linux/device.h>
>  #include <linux/io.h>
>  #include <linux/dma-mapping.h>
> +#include <linux/dmaengine.h>
>  #include <linux/omap-dma.h>
>  #include <mach/tc.h>
>  
> @@ -265,6 +266,42 @@ static const struct platform_device_info omap_dma_dev_info = {
>  	.num_res = 1,
>  };
>  
> +/* OMAP730, OMAP850 */
> +static const struct dma_slave_map omap7xx_sdma_map[] = {
> +	{ "omap-mcbsp.1", "tx", SDMA_FILTER_PARAM(8) },
> +	{ "omap-mcbsp.1", "rx", SDMA_FILTER_PARAM(9) },
> +	{ "omap-mcbsp.2", "tx", SDMA_FILTER_PARAM(10) },
> +	{ "omap-mcbsp.2", "rx", SDMA_FILTER_PARAM(11) },
> +	{ "mmci-omap.0", "tx", SDMA_FILTER_PARAM(21) },
> +	{ "mmci-omap.0", "rx", SDMA_FILTER_PARAM(22) },
> +	{ "omap_udc", "rx0", SDMA_FILTER_PARAM(26) },
> +	{ "omap_udc", "rx1", SDMA_FILTER_PARAM(27) },
> +	{ "omap_udc", "rx2", SDMA_FILTER_PARAM(28) },
> +	{ "omap_udc", "tx0", SDMA_FILTER_PARAM(29) },
> +	{ "omap_udc", "tx1", SDMA_FILTER_PARAM(30) },
> +	{ "omap_udc", "tx2", SDMA_FILTER_PARAM(31) },
> +};
> +
> +/* OMAP1510, OMAP1610*/
> +static const struct dma_slave_map omap1xxx_sdma_map[] = {
> +	{ "omap-mcbsp.1", "tx", SDMA_FILTER_PARAM(8) },
> +	{ "omap-mcbsp.1", "rx", SDMA_FILTER_PARAM(9) },
> +	{ "omap-mcbsp.3", "tx", SDMA_FILTER_PARAM(10) },
> +	{ "omap-mcbsp.3", "rx", SDMA_FILTER_PARAM(11) },
> +	{ "omap-mcbsp.2", "tx", SDMA_FILTER_PARAM(16) },
> +	{ "omap-mcbsp.2", "rx", SDMA_FILTER_PARAM(17) },
> +	{ "mmci-omap.0", "tx", SDMA_FILTER_PARAM(21) },
> +	{ "mmci-omap.0", "rx", SDMA_FILTER_PARAM(22) },
> +	{ "omap_udc", "rx0", SDMA_FILTER_PARAM(26) },
> +	{ "omap_udc", "rx1", SDMA_FILTER_PARAM(27) },
> +	{ "omap_udc", "rx2", SDMA_FILTER_PARAM(28) },
> +	{ "omap_udc", "tx0", SDMA_FILTER_PARAM(29) },
> +	{ "omap_udc", "tx1", SDMA_FILTER_PARAM(30) },
> +	{ "omap_udc", "tx2", SDMA_FILTER_PARAM(31) },
> +	{ "mmci-omap.1", "tx", SDMA_FILTER_PARAM(54) },
> +	{ "mmci-omap.1", "rx", SDMA_FILTER_PARAM(55) },
> +};
> +
>  static struct omap_system_dma_plat_info dma_plat_info __initdata = {
>  	.reg_map	= reg_map,
>  	.channel_stride	= 0x40,
> @@ -342,6 +379,14 @@ static int __init omap1_system_dma_init(void)
>  	p.dma_attr = d;
>  	p.errata = configure_dma_errata();
>  
> +	if (cpu_is_omap7xx()) {
> +		p.slave_map = omap7xx_sdma_map;
> +		p.slavecnt = ARRAY_SIZE(omap7xx_sdma_map);
> +	} else {
> +		p.slave_map = omap1xxx_sdma_map;
> +		p.slavecnt = ARRAY_SIZE(omap1xxx_sdma_map);
> +	}
> +
>  	ret = platform_device_add_data(pdev, &p, sizeof(p));
>  	if (ret) {
>  		dev_err(&pdev->dev, "%s: Unable to add resources for %s%d\n",
> -- 
> 2.7.0
> 


From linux at arm.linux.org.uk  Fri Feb 19 10:07:25 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 19 Feb 2016 18:07:25 +0000
Subject: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values
In-Reply-To: <alpine.LFD.2.20.1602191215140.13632@knanqh.ubzr>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <3974581.yknKb3tq7o@wuerfel>
 <alpine.LFD.2.20.1602191106020.13632@knanqh.ubzr>
 <38246773.SnToSslHuj@wuerfel>
 <alpine.LFD.2.20.1602191215140.13632@knanqh.ubzr>
Message-ID: <20160219180725.GB19428@n2100.arm.linux.org.uk>

On Fri, Feb 19, 2016 at 12:31:02PM -0500, Nicolas Pitre wrote:
> Yet, the only reason for a default here is to accommodate automatic 
> build tests like randconfig, right?
> 
> If so then this should be "fixed" by having the config system provide 
> built-in symbols that can be tested from kconfig files.  This way you 
> could terminate the above list with:
> 
> 	default 0x00000000 if RANDCONFIG || ALLYESCONFIG
> 
> or the like.

I've suggested in the past that we have kconf read a seed file for
these configurations.  kconf already has most of the required support
for this, we just need to teach it where to read it from.  Maybe
something like this.

 arch/arm/allrandom.config |  1 +
 scripts/kconfig/conf.c    | 61 ++++++++++++++++++++++++++++++++++++++---------
 2 files changed, 51 insertions(+), 11 deletions(-)

diff --git a/arch/arm/allrandom.config b/arch/arm/allrandom.config
index e69de29bb2d1..5a70ef5926f5 100644
--- a/arch/arm/allrandom.config
+++ b/arch/arm/allrandom.config
@@ -0,0 +1 @@
+CONFIG_PHYS_OFFSET=0
diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index 866369f10ff8..5a4b2d8bbf9a 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -12,6 +12,7 @@
 #include <time.h>
 #include <unistd.h>
 #include <getopt.h>
+#include <sys/fcntl.h>
 #include <sys/stat.h>
 #include <sys/time.h>
 #include <errno.h>
@@ -489,10 +490,53 @@ static void conf_usage(const char *progname)
 	printf("  --randconfig            New config with random answer to all options\n");
 }
 
+static int try_allconfig(int try_arch, int input_mode)
+{
+	const char *name = NULL;
+	int fd = -1, ret;
+
+	if (try_arch) {
+		const char *srctree = getenv("srctree");
+		const char *arch = getenv("ARCH");
+		
+		fd = open(".", O_DIRECTORY);
+		if (fd == -1) {
+			perror("opening .");
+			return -1;
+		}
+		if (chdir(srctree) == -1 ||
+		    chdir("arch") == -1 ||
+		    chdir(arch) == -1) {
+			perror("chdir");
+			return -1;
+		}
+	}
+
+	switch (input_mode) {
+	case allnoconfig:	name = "allno.config"; break;
+	case allyesconfig:	name = "allyes.config"; break;
+	case allmodconfig:	name = "allmod.config"; break;
+	case alldefconfig:	name = "alldef.config"; break;
+	case randconfig:	name = "allrandom.config"; break;
+	default: break;
+	}
+
+	ret = name ? conf_read_simple(name, S_DEF_USER) : 1;
+	if (ret)
+		ret = conf_read_simple("all.config", S_DEF_USER);
+
+	if (fd >= 0) {
+		fchdir(fd);
+		close(fd);
+	}
+
+	return ret;
+}
+
 int main(int ac, char **av)
 {
 	const char *progname = av[0];
-	int opt;
+	int opt, ret;
 	const char *name, *defconfig_file = NULL /* gcc uninit */;
 	struct stat tmpstat;
 
@@ -601,6 +645,9 @@ int main(int ac, char **av)
 	case allmodconfig:
 	case alldefconfig:
 	case randconfig:
+		ret = try_allconfig(1, input_mode);
+		if (ret < 0)
+			exit(1);
 		name = getenv("KCONFIG_ALLCONFIG");
 		if (!name)
 			break;
@@ -613,16 +660,8 @@ int main(int ac, char **av)
 			}
 			break;
 		}
-		switch (input_mode) {
-		case allnoconfig:	name = "allno.config"; break;
-		case allyesconfig:	name = "allyes.config"; break;
-		case allmodconfig:	name = "allmod.config"; break;
-		case alldefconfig:	name = "alldef.config"; break;
-		case randconfig:	name = "allrandom.config"; break;
-		default: break;
-		}
-		if (conf_read_simple(name, S_DEF_USER) &&
-		    conf_read_simple("all.config", S_DEF_USER)) {
+		ret = try_allconfig(0, input_mode);
+		if (ret) {
 			fprintf(stderr,
 				_("*** KCONFIG_ALLCONFIG set, but no \"%s\" or \"all.config\" file found\n"),
 				name);

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From catalin.marinas at arm.com  Fri Feb 19 10:14:11 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Fri, 19 Feb 2016 18:14:11 +0000
Subject: [PATCH v2] arm64: add alignment fault hanling
In-Reply-To: <CA+55aFw-86k4gY46Et=e02HQQSxjUK2Jfz0SJz8tWtk5P8YZFA@mail.gmail.com>
References: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
 <20160216103104.GC14509@arm.com> <56C300AD.8070505@arm.com>
 <20160216122153.GD19413@e104818-lin.cambridge.arm.com>
 <20160216160055.GH14509@arm.com> <20160216170408.GL14509@arm.com>
 <CA+55aFw-86k4gY46Et=e02HQQSxjUK2Jfz0SJz8tWtk5P8YZFA@mail.gmail.com>
Message-ID: <20160219181410.GG12864@e104818-lin.cambridge.arm.com>

On Tue, Feb 16, 2016 at 10:50:02AM -0800, Linus Torvalds wrote:
> On Tue, Feb 16, 2016 at 9:04 AM, Will Deacon <will.deacon at arm.com> wrote:
> > [replying to self and adding some x86 people]
> >
> > Background: Euntaik reports a problem where userspace has ended up with
> > a memory page mapped adjacent to an MMIO page (e.g. from /dev/mem or a
> > PCI memory bar from someplace in /sys). strncpy_from_user happens with
> > the word-at-a-time implementation, and we end up reading into the MMIO
> > page.
> >
> > Question: Does x86 guarantee that this faults? (Arjan reckoned no, but
> > wasn't 100%).
> 
> x86 not only does *not* guarantee that that faults, but quite the
> reverse: I'm pretty sure it would be considered an architectural bug
> if it didn't silently "just work". IOW, the page-crossing unaligned
> access will be split up as two accesses, and done as a regular cached
> read for the normal RAM page part, and as an uncached IO read for the
> MMIO page.
> 
> So if somebody passes us a string adjacent to a MMIO mapping, we'll
> happily do the access on x86 and touch the MMIO space. No biggie, and
> nobody sane actually does that. If you have the rights to do device
> mappings, you should probably restrain from doing insane things. "With
> great power comes great responsibility".

Unless I misunderstand it, I don't think the user is even aware of this
potential problem. Let's say it mmap's a file (script etc.) which
contains a string (file name) towards the end of the last page. Such
pointer gets passed to sys_open() and it eventually ends up in
strncpy_from_user() with count == EMBEDDED_NAME_MAX (so well beyond the
end of the page).

The user also maps a device with mmap(NULL, ...) and there is a slight
chance that the kernel allocates this VA space without any gap from the
previous mmap().

With the above scenario, I don't see what the user could control here,
other than using MAP_FIXED and force a guard from user space.

> > Thinking more about this, we could spit out a guard page between every
> > VMA, but it's likely to hamper any VMA merging.
> 
> More importantly, it wouldn't work for the general case. People often
> pass in a specific virtual memory address to mmap because they *need*
> adjacent mappings. One example of that case is doing a circular buffer
> that is guaranteed to always be accessible linearly (and avoiding the
> split case where it hits the end of the circular buffer) by mapping
> the same buffer twice.
> 
> Of course, no actual real program will do that for mixing MMIO and
> non-MMIO, and so we might obviously add code to always add a guard
> page for the normal case when a specific address isn't asked for. So
> as a heuristic to make sure it doesn't happen by mistake it possibly
> makes sense.

I agree, a guard page for the general case (!MAP_FIXED) is the best
option and it would be better to have it in core code (maybe hidden
behind some Kconfig if it's not desirable for all architectures using
the generic implementation).

Alternatively, aligning the source pointer reads (but not the
destination) in strncpy_from_user() is another option, though I'm pretty
sure we would notice some performance penalty.

-- 
Catalin


From tony at atomide.com  Fri Feb 19 10:15:14 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Feb 2016 10:15:14 -0800
Subject: [PATCH] ARM: OMAP: DRA7: Make use of omap_revision information
 for soc_is* calls
In-Reply-To: <1455706123-26497-1-git-send-email-j-keerthy@ti.com>
References: <1455706123-26497-1-git-send-email-j-keerthy@ti.com>
Message-ID: <20160219181514.GK21202@atomide.com>

* Keerthy <j-keerthy at ti.com> [160217 02:49]:
> Currently of_machine_is_compatible is used to detect the soc which
> employs string comparison operations. We already have all the required
> information in the omap_revision. Hence make use of the same like
> the previous OMAPs and avoid costly string comparisons.

Looks good to me thanks. Applying into omap-for-v4.6/soc.

Tony


From mmarek at suse.cz  Fri Feb 19 10:22:38 2016
From: mmarek at suse.cz (Michal Marek)
Date: Fri, 19 Feb 2016 19:22:38 +0100
Subject: [PATCH] arm64, kbuild: make "make install" not depend on vmlinux
In-Reply-To: <CAK7LNATs3Xkp05cYsUAhUtQuvrpo=dUe5R6+bQjcLdpPrG_S3w@mail.gmail.com>
References: <1455861950-21832-1-git-send-email-yamada.masahiro@socionext.com>
 <CAK7LNATs3Xkp05cYsUAhUtQuvrpo=dUe5R6+bQjcLdpPrG_S3w@mail.gmail.com>
Message-ID: <56C75D6E.1020002@suse.cz>

Dne 19.2.2016 v 18:29 Masahiro Yamada napsal(a):
> Just for clarification:
> 
> This patch has been applied to arm64 tree.
> 
> Michal,
> Just ignore this patch.

Sure. I assumed that a patch touching solely arch/arm* will go through
the respective arm tree.

Michal


From tchalamarla at caviumnetworks.com  Fri Feb 19 10:33:33 2016
From: tchalamarla at caviumnetworks.com (tchalamarla at caviumnetworks.com)
Date: Fri, 19 Feb 2016 10:33:33 -0800
Subject: [PATCH V2] iommu/arm-smmu-v2: Add support for 16 bit VMID
Message-ID: <1455906813-9721-1-git-send-email-tchalamarla@caviumnetworks.com>

From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>

ARM-SMMUv2 supports upto 16 bit VMID. This patch enables
16 bit VMID when HW supports.

changes from V1:
	- Remove DT Property and enable 16 bit VMID if ID says.

Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
---
 drivers/iommu/arm-smmu.c | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 59ee4b8..92caab8 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -93,6 +93,7 @@
 #define sCR0_VMIDPNE			(1 << 11)
 #define sCR0_PTM			(1 << 12)
 #define sCR0_FB				(1 << 13)
+#define sCR0_VMID16EN			(1 << 31)
 #define sCR0_BSU_SHIFT			14
 #define sCR0_BSU_MASK			0x3
 
@@ -140,6 +141,7 @@
 #define ID2_PTFS_4K			(1 << 12)
 #define ID2_PTFS_16K			(1 << 13)
 #define ID2_PTFS_64K			(1 << 14)
+#define ID2_VMID16			(1 << 15)
 
 /* Global TLB invalidation */
 #define ARM_SMMU_GR0_TLBIVMID		0x64
@@ -189,6 +191,8 @@
 #define ARM_SMMU_GR1_CBA2R(n)		(0x800 + ((n) << 2))
 #define CBA2R_RW64_32BIT		(0 << 0)
 #define CBA2R_RW64_64BIT		(1 << 0)
+#define CBA2R_VMID_SHIFT		16
+#define CBA2R_VMID_MASK			0xffff
 
 /* Translation context bank */
 #define ARM_SMMU_CB_BASE(smmu)		((smmu)->base + ((smmu)->size >> 1))
@@ -297,6 +301,7 @@ struct arm_smmu_device {
 #define ARM_SMMU_FEAT_TRANS_S2		(1 << 3)
 #define ARM_SMMU_FEAT_TRANS_NESTED	(1 << 4)
 #define ARM_SMMU_FEAT_TRANS_OPS		(1 << 5)
+#define ARM_SMMU_FEAT_VMID16		(1 << 6)
 	u32				features;
 
 #define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
@@ -736,6 +741,10 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 #else
 		reg = CBA2R_RW64_32BIT;
 #endif
+		/* if 16bit VMID supported set VMID in CBA2R */
+		if (smmu->features & ARM_SMMU_FEAT_VMID16)
+			reg |= ARM_SMMU_CB_VMID(cfg) << CBA2R_VMID_SHIFT;
+
 		writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBA2R(cfg->cbndx));
 	}
 
@@ -751,7 +760,8 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 	if (stage1) {
 		reg |= (CBAR_S1_BPSHCFG_NSH << CBAR_S1_BPSHCFG_SHIFT) |
 			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
-	} else {
+	} else if (!(smmu->features & ARM_SMMU_FEAT_VMID16)) {
+		/*16 bit VMID is not supported set 8 bit VMID here */
 		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
 	}
 	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
@@ -1508,6 +1518,9 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
 	/* Don't upgrade barriers */
 	reg &= ~(sCR0_BSU_MASK << sCR0_BSU_SHIFT);
 
+	if (smmu->features & ARM_SMMU_FEAT_VMID16)
+		reg |= sCR0_VMID16EN;
+
 	/* Push the button */
 	__arm_smmu_tlb_sync(smmu);
 	writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
@@ -1658,6 +1671,10 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
 	size = arm_smmu_id_size_to_bits((id >> ID2_OAS_SHIFT) & ID2_OAS_MASK);
 	smmu->pa_size = size;
 
+	/* See if 16bit VMID is supported */
+	if (id & ID2_VMID16)
+		smmu->features = ARM_SMMU_FEAT_VMID16;
+
 	/*
 	 * What the page table walker can address actually depends on which
 	 * descriptor format is in use, but since a) we don't know that yet,
@@ -1696,6 +1713,11 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
 		dev_notice(smmu->dev, "\tStage-2: %lu-bit IPA -> %lu-bit PA\n",
 			   smmu->ipa_size, smmu->pa_size);
 
+	if (smmu->features & ARM_SMMU_FEAT_VMID16)
+		dev_notice(smmu->dev, "\t 16 bit VMID Supported.\n");
+	else
+		dev_notice(smmu->dev, "\t Only 8 bit VMID Supported.\n");
+
 	return 0;
 }
 
-- 
2.1.0



From tchalamarla at caviumnetworks.com  Fri Feb 19 10:36:15 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Fri, 19 Feb 2016 10:36:15 -0800
Subject: [PATCH] iommu/arm-smmu-v2: Add support for 16 bit VMID
In-Reply-To: <20160219171329.GO27062@arm.com>
References: <1455819817-8432-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160219171329.GO27062@arm.com>
Message-ID: <56C7609F.4030403@caviumnetworks.com>



On 02/19/2016 09:13 AM, Will Deacon wrote:
> On Thu, Feb 18, 2016 at 10:23:37AM -0800, tchalamarla at caviumnetworks.com wrote:
>> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>>
>> ARM-SMMUv2 supports upto 16 bit VMID. This patch enables
>> 16 bit VMID when requested from device-tree.
>>
>> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>> ---
>>   .../devicetree/bindings/iommu/arm,smmu.txt          |  2 ++
>>   drivers/iommu/arm-smmu.c                            | 21 ++++++++++++++++++++-
>>   2 files changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> index 7180745..bb7e569 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> @@ -55,6 +55,8 @@ conditions.
>>                     aliases of secure registers have to be used during
>>                     SMMU configuration.
>>
>> +- smmu-enable-vmid16 : Enable 16 bit VMID, if allowed.
>
> Why do we need a new property for this, given that we can detect it
> from the ID registers? I can't think of a reason why we wouldn't use
> 16-bit VMIDs if they were available to us.
Done.
>
> Will
>


From tony at atomide.com  Fri Feb 19 10:39:26 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Feb 2016 10:39:26 -0800
Subject: [GIT PULL] ARM: OMAP2+: first set of hwmod fixes and additions
 for v4.6
In-Reply-To: <alpine.DEB.2.02.1602171838420.11377@utopia.booyaka.com>
References: <alpine.DEB.2.02.1602171838420.11377@utopia.booyaka.com>
Message-ID: <20160219183925.GM21202@atomide.com>

* Paul Walmsley <paul at pwsan.com> [160217 10:41]:
> Hi Tony
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v4.6/omap-hwmod-a
> 
> for you to fetch changes up to 8fe097a3d99e22355fb8e3bcee59542bf3f46b2d:
> 
>   ARM: DRA7: hwmod: Add reset data for PCIe (2016-02-09 02:18:52 -0700)
> 
> ----------------------------------------------------------------
> ARM: OMAP2+: first set of hwmod fixes and additions for v4.6
> 
> A few fixes for OMAP hwmod data.  SSI hwmod data for the OMAP 3730,
> and some fixes for the DRA7xx hwmod data.  These shouldn't interfere
> or impact anything else.

Thanks pulling into omap-for-v4.6/fixes-not-urgent.

Tony


From nicolas.pitre at linaro.org  Fri Feb 19 10:44:34 2016
From: nicolas.pitre at linaro.org (Nicolas Pitre)
Date: Fri, 19 Feb 2016 13:44:34 -0500 (EST)
Subject: [PATCH 8/9] ARM: do not use optimized do_div for ARMv3
In-Reply-To: <13253932.bg5yHHtIOq@wuerfel>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <1455804123-2526139-9-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602181215310.13632@knanqh.ubzr>
 <13253932.bg5yHHtIOq@wuerfel>
Message-ID: <alpine.LFD.2.20.1602191307380.13632@knanqh.ubzr>

On Fri, 19 Feb 2016, Arnd Bergmann wrote:

> On Thursday 18 February 2016 12:20:51 Nicolas Pitre wrote:
> > On Thu, 18 Feb 2016, Arnd Bergmann wrote:
> > 
> > > The gcc-4.9 optimization goes wrong while building target_core_iblock.c
> > > for ARMv3 and leaves a bogus reference to __aeabi_uldivmod in the
> > > output:
> > > 
> > > ERROR: "__aeabi_uldivmod" [drivers/target/target_core_iblock.ko] undefined!
> > > 
> > > I could not find anyone who is interested in fixing it in gcc,
> > > so as a workaround this disables the do_div magic, just like
> > > we do for old compilers and for OABI.
> > > 
> > > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> > 
> > I suppose this is good enough for the purpose of keeping RiscPC 
> > buildable. Whether or not it is still used is another question.  If it 
> > is then its user probably expects it to be slow already.
> > 
> > Acked-by: Nicolas Pitre <nico at linaro.org>
> 
> Thanks.
> 
> > Still unfortunate having to use a big hammer such as -march=armv3 just 
> > to avoid halfword memory accesses.
> 
> I brought this up with the gcc developers before. They would really want
> to deprecated ARMv3 support, but nobody seems interested in implementing
> halfword memory access as a replacement.

Actually, the only thing needed as far as Linux on RiscPC is concerned 
is a compiler switch that prevents the use of STRH, LDRH and LDRSH 
instructions when -march=armv4 is used.

> FWIW, I am currently still allowing ARMv3 in randconfig builds, but
> have run into 12 internal compiler errors with that, on gcc-4.9 or higher.
> It's probably all the same bug, but I don't see this getting fixed
> unless the RiscOS people update to a newer toolchain and run into the
> same problem.

Hmmm I suppose the ability to use halfword accesses is assumed by new 
optimization patterns and that's why gcc fails when they're not 
available.

> The patch below disables optimization so I am able to build this, but
> I see no way to fix this upstream.

That begs the question again: is anyone using mainline Linux on RiscPC?
If I remember correctly, the ability to boot Linux on an i386 was 
removed a while ago and nobody complained.


Nicolas


From tony at atomide.com  Fri Feb 19 10:55:38 2016
From: tony at atomide.com (Tony Lindgren)
Date: Fri, 19 Feb 2016 10:55:38 -0800
Subject: [PATCH v2 1/2] ARM: dts: am43x-epos-evm: Add the am438
 compatible string
In-Reply-To: <1455856735-11515-2-git-send-email-j-keerthy@ti.com>
References: <1455856735-11515-1-git-send-email-j-keerthy@ti.com>
 <1455856735-11515-2-git-send-email-j-keerthy@ti.com>
Message-ID: <20160219185538.GO21202@atomide.com>

* Keerthy <j-keerthy at ti.com> [160218 20:39]:
> The SoCs on am43x-epos-evm are named am438x.
> Hence add the compatibility string and remove the am4372 string.

Applying into omap-for-v4.6/dt thanks.

Tony


From keescook at chromium.org  Fri Feb 19 11:05:17 2016
From: keescook at chromium.org (Kees Cook)
Date: Fri, 19 Feb 2016 11:05:17 -0800
Subject: [PATCH v3] arm64: mm: Mark .rodata as RO
In-Reply-To: <1455904232-24053-1-git-send-email-jeremy.linton@arm.com>
References: <1455904232-24053-1-git-send-email-jeremy.linton@arm.com>
Message-ID: <CAGXu5jJi9174OGM_xc2qriRrfajZ4UNgiTCODkhreRck_Q9NAQ@mail.gmail.com>

On Fri, Feb 19, 2016 at 9:50 AM, Jeremy Linton <jeremy.linton at arm.com> wrote:
> Currently the .rodata section is actually still executable when DEBUG_RODATA
> is enabled. This changes that so the .rodata is actually read only, no execute.
> It also adds the .rodata section to the mem_init banner.
>
> Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>

Reviewed-by: Kees Cook <keescook at chromium.org>

-Kees

> ---
>  arch/arm64/kernel/vmlinux.lds.S |  5 +++--
>  arch/arm64/mm/init.c            |  4 +++-
>  arch/arm64/mm/mmu.c             | 17 +++++++++++++----
>  3 files changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index 8f4fc2c..9208f53 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -114,8 +114,9 @@ SECTIONS
>                 *(.got)                 /* Global offset table          */
>         }
>
> -       RO_DATA(PAGE_SIZE)
> -       EXCEPTION_TABLE(8)
> +       ALIGN_DEBUG_RO_MIN(0)
> +       RO_DATA(PAGE_SIZE)              /* everything from this point to */
> +       EXCEPTION_TABLE(8)              /* _etext will be marked RO NX   */
>         NOTES
>
>         ALIGN_DEBUG_RO_MIN(PAGE_SIZE)
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 5dd0831..41be7db 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -325,6 +325,7 @@ void __init mem_init(void)
>                   "    memory  : 0x%16lx - 0x%16lx   (%6ld MB)\n"
>                   "      .init : 0x%p" " - 0x%p" "   (%6ld KB)\n"
>                   "      .text : 0x%p" " - 0x%p" "   (%6ld KB)\n"
> +                 "    .rodata : 0x%p" " - 0x%p" "   (%6ld KB)\n"
>                   "      .data : 0x%p" " - 0x%p" "   (%6ld KB)\n",
>  #ifdef CONFIG_KASAN
>                   MLG(KASAN_SHADOW_START, KASAN_SHADOW_END),
> @@ -341,7 +342,8 @@ void __init mem_init(void)
>                   MLM(MODULES_VADDR, MODULES_END),
>                   MLM(PAGE_OFFSET, (unsigned long)high_memory),
>                   MLK_ROUNDUP(__init_begin, __init_end),
> -                 MLK_ROUNDUP(_text, _etext),
> +                 MLK_ROUNDUP(_text, __start_rodata),
> +                 MLK_ROUNDUP(__start_rodata, _etext),
>                   MLK_ROUNDUP(_sdata, _edata));
>
>  #undef MLK
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index ab69a99..a18dfd0 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -453,10 +453,18 @@ static void __init map_mem(pgd_t *pgd)
>  #ifdef CONFIG_DEBUG_RODATA
>  void mark_rodata_ro(void)
>  {
> -       create_mapping_late(__pa(_stext), (unsigned long)_stext,
> -                               (unsigned long)_etext - (unsigned long)_stext,
> -                               PAGE_KERNEL_ROX);
> +       unsigned long section_size;
>
> +       section_size = (unsigned long)__start_rodata - (unsigned long)_stext;
> +       create_mapping_late(__pa(_stext), (unsigned long)_stext,
> +                           section_size, PAGE_KERNEL_ROX);
> +       /*
> +        * mark .rodata as read only. Use _etext rather than __end_rodata to
> +        * cover NOTES and EXCEPTION_TABLE.
> +        */
> +       section_size = (unsigned long)_etext - (unsigned long)__start_rodata;
> +       create_mapping_late(__pa(__start_rodata), (unsigned long)__start_rodata,
> +                           section_size, PAGE_KERNEL_RO);
>  }
>  #endif
>
> @@ -486,7 +494,8 @@ static void __init map_kernel_chunk(pgd_t *pgd, void *va_start, void *va_end,
>  static void __init map_kernel(pgd_t *pgd)
>  {
>
> -       map_kernel_chunk(pgd, _stext, _etext, PAGE_KERNEL_EXEC);
> +       map_kernel_chunk(pgd, _stext, __start_rodata, PAGE_KERNEL_EXEC);
> +       map_kernel_chunk(pgd, __start_rodata, _etext, PAGE_KERNEL);
>         map_kernel_chunk(pgd, __init_begin, __init_end, PAGE_KERNEL_EXEC);
>         map_kernel_chunk(pgd, _data, _end, PAGE_KERNEL);
>
> --
> 2.4.3
>



-- 
Kees Cook
Chrome OS & Brillo Security


From f.fainelli at gmail.com  Fri Feb 19 11:24:57 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Fri, 19 Feb 2016 11:24:57 -0800
Subject: [1/4] arm64: Broadcom Vulcan support
In-Reply-To: <0c75ddd6-d353-bb73-62e4-bae0ff95a3b0@broadcom.com>
References: <1455389195-31870-2-git-send-email-jchandra@broadcom.com>
 <0c75ddd6-d353-bb73-62e4-bae0ff95a3b0@broadcom.com>
Message-ID: <56C76C09.50800@gmail.com>

On 18/02/16 10:15, Ray Jui wrote:
> + bcm-kernel-feedback-list mailing list
> 
> On 2/13/2016 10:46 AM, Jayachandran C. wrote:
>> From: Zi Shen Lim <zlim at broadcom.com>
>>
>> Add a configuration option and a device tree for Broadcom's Vulcan
>> ARM64 processor. brcm-vulcan.dtsi has the on-chip blocks like the
>> PCIe controller, GICv3 with ITS, PMU, system timer and pl011 UART.
>> brcm-vulcan-eval.dts has definitions for a basic evaluation board.
>> The firmware supports PSCI 0.2 for cpu wakeup.
>>
>> Signed-off-by: Zi Shen Lim <zlim at broadcom.com>
>> [ updated and split dts - jchandra at broadcom.com ]
>> Signed-off-by: Jayachandran C <jchandra at broadcom.com>
>>
>> ---
>> arch/arm64/Kconfig.platforms                      |   5 +
>>  arch/arm64/boot/dts/broadcom/Makefile             |   1 +
>>  arch/arm64/boot/dts/broadcom/brcm-vulcan-eval.dts |  33 +++++
>>  arch/arm64/boot/dts/broadcom/brcm-vulcan.dtsi     | 146
>> ++++++++++++++++++++++
>>  4 files changed, 185 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/broadcom/brcm-vulcan-eval.dts
>>  create mode 100644 arch/arm64/boot/dts/broadcom/brcm-vulcan.dtsi
> 
> Could you please name the files "vulcan.dtsi" and "vulcan-eval.dts" so
> it's consistent with the rest of files in the same directory?

I would like to take these patches ASAP so I can include them in our
upcoming 4.6 pull requests, can you do a quick respin adressing Ray's
feedback and adding a MAINTAINERS file?

Thanks!
-- 
Florian


From dhdang at apm.com  Fri Feb 19 12:43:34 2016
From: dhdang at apm.com (Duc Dang)
Date: Fri, 19 Feb 2016 12:43:34 -0800
Subject: [PATCH v6 0/3] mailbox: Add APM X-Gene platform mailbox driver
In-Reply-To: <cover.1455333720.git.dhdang@apm.com>
References: <CANLsYkxPnFCuJLyKsHnXKdbvAwNurtgQgJ-WF+bD26+8EjkfJw@mail.gmail.com>
 <cover.1455333720.git.dhdang@apm.com>
Message-ID: <CADaLND=7W9YQwKjMA1BR-PuncYEnKOcQyR6xLbEvig2qgKryqQ@mail.gmail.com>

On Fri, Feb 12, 2016 at 7:39 PM, Duc Dang <dhdang at apm.com> wrote:
> APM X-Gene SoC has a mailbox controller that provides
> communication mechanism for X-Gene Arm64 cores to communicate
> with X-Gene SoC's Cortex M3 (SLIMpro) processor.
>
> X-Gene mailbox controller provides 8 mailbox channels, with
> each channel has a dedicated interrupt line.

Hi Jassi,

Are you fine with this version of the patch?

Regards,
Duc Dang.
>
> Changes since v5:
>         - Add more description into SlimPRO
>         mailbox data structure
>
> Changes since v4:
>         - Rebase over v4.5-rc1
>         - Fix section mismatch warning during compiling
>         - Correctly print channel number when there is
>         no IRQ for that channel
>         - Change node name to mailbox at 10540000
>         - Correct the number of IRQs in documentation
>
> Changes since v3:
>         - Rebase over v4.4
>         - Remove 'id' in slimpro_mbox_chan structure
>         - Remove functions that are only called once
>         and fold them into the other callers
>         - Remove void* pointer type cast
>         - Relax the number of mailbox IRQs condition
>         - Fix error and address comment in documentation
>         (xgene-slimpro-mailbox.txt)
>
> Changes since v2:
>         - Rebase Feng's patch set over v4.3-rc5
>         - Remove uneccessary 'inline' in function definition
>         - Use module_platform_driver instead of subsys_initcall
>         - Minor coding stype clean up
>
> Changes since v1:
>         - Add ACPI support
>         - Use defines for reg offset
>
> Duc Dang (3):
>   mailbox: Add support for APM X-Gene platform mailbox driver
>   Documentation: mailbox: Add APM X-Gene SLIMpro mailbox dts
>     documentation
>   arm64: dts: mailbox device tree node for APM X-Gene platform.
>
>  .../bindings/mailbox/xgene-slimpro-mailbox.txt     |  35 +++
>  arch/arm64/boot/dts/apm/apm-storm.dtsi             |  14 +
>  drivers/mailbox/Kconfig                            |   9 +
>  drivers/mailbox/Makefile                           |   2 +
>  drivers/mailbox/mailbox-xgene-slimpro.c            | 284 +++++++++++++++++++++
>  5 files changed, 344 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailbox.txt
>  create mode 100644 drivers/mailbox/mailbox-xgene-slimpro.c
>
> --
> 1.9.1
>


From julien.grossholtz at savoirfairelinux.com  Fri Feb 19 12:59:02 2016
From: julien.grossholtz at savoirfairelinux.com (Julien Grossholtz)
Date: Fri, 19 Feb 2016 15:59:02 -0500
Subject: [PATCH] ARM: dts: TS-4800: Add gpio driver
Message-ID: <1455915542-14467-1-git-send-email-julien.grossholtz@savoirfairelinux.com>

Add dts nodes for TS-4800 FPGA gpio chips.

Signed-off-by: Julien Grossholtz <julien.grossholtz at savoirfairelinux.com>
---
 arch/arm/boot/dts/imx51-ts4800.dts | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/imx51-ts4800.dts b/arch/arm/boot/dts/imx51-ts4800.dts
index 0ff76a1..c72c944 100644
--- a/arch/arm/boot/dts/imx51-ts4800.dts
+++ b/arch/arm/boot/dts/imx51-ts4800.dts
@@ -165,6 +165,35 @@
 			reg = <0x12000 0x1000>;
 			syscon = <&syscon 0x10 6>;
 		};
+
+		fpga_gpio0: fpga_gpio0 at b0010020 {
+			compatible = "technologic,ts4800-gpio";
+			reg = <0x10020 0x6>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
+		fpga_gpio1: fpga_gpio1 at b0010028 {
+			compatible = "technologic,ts4800-gpio";
+			reg = <0x10028 0x6>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
+		fpga_gpio2: fpga_gpio2 at b0010030 {
+			compatible = "technologic,ts4800-gpio";
+			reg = <0x10030 0x6>;
+			gpio-controller;
+			#gpio-cells = <2>;
+		};
+
+		fpga_gpio3: fpga_gpio3 at b0010038 {
+			compatible = "technologic,ts4800-gpio";
+			reg = <0x10038 0x6>;
+			gpio-controller;
+			ngpios = <8>;
+			#gpio-cells = <2>;
+		};
 	};
 };
 
-- 
2.5.0



From arnd at arndb.de  Fri Feb 19 13:14:57 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 22:14:57 +0100
Subject: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values
In-Reply-To: <20160219180725.GB19428@n2100.arm.linux.org.uk>
References: <1455804123-2526139-1-git-send-email-arnd@arndb.de>
 <alpine.LFD.2.20.1602191215140.13632@knanqh.ubzr>
 <20160219180725.GB19428@n2100.arm.linux.org.uk>
Message-ID: <3612170.sHbTTc5Sc9@wuerfel>

On Friday 19 February 2016 18:07:25 Russell King - ARM Linux wrote:
> On Fri, Feb 19, 2016 at 12:31:02PM -0500, Nicolas Pitre wrote:
> > Yet, the only reason for a default here is to accommodate automatic 
> > build tests like randconfig, right?
> > 
> > If so then this should be "fixed" by having the config system provide 
> > built-in symbols that can be tested from kconfig files.  This way you 
> > could terminate the above list with:
> > 
> > 	default 0x00000000 if RANDCONFIG || ALLYESCONFIG
> > 
> > or the like.
> 
> I've suggested in the past that we have kconf read a seed file for
> these configurations.  kconf already has most of the required support
> for this, we just need to teach it where to read it from.  Maybe
> something like this.
> 
>  arch/arm/allrandom.config |  1 +
>  scripts/kconfig/conf.c    | 61 ++++++++++++++++++++++++++++++++++++++---------
>  2 files changed, 51 insertions(+), 11 deletions(-)

Interesting, I had never noticed that we had the infrastructure to have
separate presets for allno/allmod/allyes/...config by file name,
aside from the ${KCONFIG_ALLCONFIG}, I think your extension to make
it architecture specific is a very good idea, and it can solve a
couple of other problems as well, such as new toolchains barfing
on -march=armv3 and OABI support.

There is a bit of overlap with the Kconfig fragments, which are
defined in a similar way:

> diff --git a/arch/arm/allrandom.config b/arch/arm/allrandom.config
> index e69de29bb2d1..5a70ef5926f5 100644
> --- a/arch/arm/allrandom.config
> +++ b/arch/arm/allrandom.config
> @@ -0,0 +1 @@
> +CONFIG_PHYS_OFFSET=0

With the recently added Kconfig fragments support, you could do
(almost) the same thing by specifying

make randconfig allrandom.config

"almost", because

- The fragments use a search path including kernel/config/*.config
  and arch/*/configs/*.config, rather than arch/*/*.config
  I would prefer using the search path we have for the fragments now.

- The current implementation does not start out with the symbols
  from the fragment but instead applies the fragments one by one
  after the initial config, so the example above is the same as

	make randconfig
	make allrandom.config

  which does not have the same results. For this, I think starting
  with the fragment makes more sense, but that unfortunately requires
  changing the command line interface if we want to generalize it.

	Arnd


From akpm at linux-foundation.org  Fri Feb 19 13:23:23 2016
From: akpm at linux-foundation.org (Andrew Morton)
Date: Fri, 19 Feb 2016 13:23:23 -0800
Subject: [PATCH 1/2] mm: cma: split out in_cma check to separate function
In-Reply-To: <1455869524-13874-1-git-send-email-rabin.vincent@axis.com>
References: <1455869524-13874-1-git-send-email-rabin.vincent@axis.com>
Message-ID: <20160219132323.d3c6bfb8cf1a420b4cb1b508@linux-foundation.org>

On Fri, 19 Feb 2016 09:12:03 +0100 Rabin Vincent <rabin.vincent at axis.com> wrote:

> Split out the logic in cma_release() which checks if the page is in the
> contiguous area to a new function which can be called separately.  ARM
> will use this.
> 
> ...
>
> --- a/include/linux/cma.h
> +++ b/include/linux/cma.h
> @@ -27,5 +27,17 @@ extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
>  					unsigned int order_per_bit,
>  					struct cma **res_cma);
>  extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align);
> +
>  extern bool cma_release(struct cma *cma, const struct page *pages, unsigned int count);
> +#ifdef CONFIG_CMA
> +extern bool in_cma(struct cma *cma, const struct page *pages,
> +		   unsigned int count);
> +#else
> +static inline bool in_cma(struct cma *cma, const struct page *pages,
> +			  unsigned int count)
> +{
> +	return false;
> +}
> +#endif

Calling it "pages" is weird.  I immediately read it as a `struct page **'. 
Drop the 's' please.  Or call it `start_page' if you wish to retain the
"we're dealing with more than one page here" info.

And `nr_pages' is a better name than `count'.  

And `in_cma' seems rather ...  brief.  And it breaks the convention that
interface identifiers start with the name of the subsystem.  Look at the rest
of cma.h: cma_get_base(), cma_get_size() cma_declare_contiguous(), etc -
let's not break that.

>  #endif
> diff --git a/mm/cma.c b/mm/cma.c
> index ea506eb..55cda16 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -426,6 +426,23 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
>  	return page;
>  }
>  
> +bool in_cma(struct cma *cma, const struct page *pages, unsigned int count)

A bit of documentation would be nice.

> +{
> +	unsigned long pfn;
> +
> +	if (!cma || !pages)
> +		return false;

Is this actually needed?  If there's no good reason for the test, let's leave
it out because it will just be hiding bugs in the caller.

> +	pfn = page_to_pfn(pages);
> +
> +	if (pfn < cma->base_pfn || pfn >= cma->base_pfn + cma->count)
> +		return false;
> +
> +	VM_BUG_ON(pfn + count > cma->base_pfn + cma->count);
> +
> +	return true;
> +}
> +
>  /**
>   * cma_release() - release allocated pages
>   * @cma:   Contiguous memory region for which the allocation is performed.

Apart from those cosmeticish things, no objections from me.


From arnd at arndb.de  Fri Feb 19 13:40:28 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 22:40:28 +0100
Subject: [PATCH] usb: move usb_calc_bus_time into common code
Message-ID: <1455918064-410571-1-git-send-email-arnd@arndb.de>

The dwc2 dual-role USB controller driver has started calling
usb_calc_bus_time, and does so regardless of whether it is
being built as a host controller or gadget. In case all
USB host support is disabled (CONFIG_USB=n), this now causes
a link error:

ERROR: "usb_calc_bus_time" [drivers/usb/dwc2/dwc2.ko] undefined!

Moving the function that is called from the USB HCD specific code
into the shared USB code avoids this problem.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: f889904b25df ("usb: dwc2: host: Properly set even/odd frame")
---
I have no idea if this is the correct solution for the problem,
it just seemed like the easiest way to avoid the build failure.

 drivers/usb/common/common.c | 51 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/usb/core/hcd.c      | 51 ---------------------------------------------
 2 files changed, 51 insertions(+), 51 deletions(-)

diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index e3d01619d6b3..654fd37f89d5 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -17,6 +17,7 @@
 #include <linux/usb/ch9.h>
 #include <linux/usb/of.h>
 #include <linux/usb/otg.h>
+#include <linux/usb/hcd.h>
 #include <linux/of_platform.h>
 
 const char *usb_otg_state_string(enum usb_otg_state state)
@@ -126,6 +127,56 @@ enum usb_dr_mode usb_get_dr_mode(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(usb_get_dr_mode);
 
+/*-------------------------------------------------------------------------*/
+
+/**
+ * usb_calc_bus_time - approximate periodic transaction time in nanoseconds
+ * @speed: from dev->speed; USB_SPEED_{LOW,FULL,HIGH}
+ * @is_input: true iff the transaction sends data to the host
+ * @isoc: true for isochronous transactions, false for interrupt ones
+ * @bytecount: how many bytes in the transaction.
+ *
+ * Return: Approximate bus time in nanoseconds for a periodic transaction.
+ *
+ * Note:
+ * See USB 2.0 spec section 5.11.3; only periodic transfers need to be
+ * scheduled in software, this function is only used for such scheduling.
+ */
+long usb_calc_bus_time (int speed, int is_input, int isoc, int bytecount)
+{
+	unsigned long	tmp;
+
+	switch (speed) {
+	case USB_SPEED_LOW: 	/* INTR only */
+		if (is_input) {
+			tmp = (67667L * (31L + 10L * BitTime (bytecount))) / 1000L;
+			return 64060L + (2 * BW_HUB_LS_SETUP) + BW_HOST_DELAY + tmp;
+		} else {
+			tmp = (66700L * (31L + 10L * BitTime (bytecount))) / 1000L;
+			return 64107L + (2 * BW_HUB_LS_SETUP) + BW_HOST_DELAY + tmp;
+		}
+	case USB_SPEED_FULL:	/* ISOC or INTR */
+		if (isoc) {
+			tmp = (8354L * (31L + 10L * BitTime (bytecount))) / 1000L;
+			return ((is_input) ? 7268L : 6265L) + BW_HOST_DELAY + tmp;
+		} else {
+			tmp = (8354L * (31L + 10L * BitTime (bytecount))) / 1000L;
+			return 9107L + BW_HOST_DELAY + tmp;
+		}
+	case USB_SPEED_HIGH:	/* ISOC or INTR */
+		/* FIXME adjust for input vs output */
+		if (isoc)
+			tmp = HS_NSECS_ISO (bytecount);
+		else
+			tmp = HS_NSECS (bytecount);
+		return tmp;
+	default:
+		pr_debug ("%s: bogus device speed!\n", __func__);
+		return -1;
+	}
+}
+EXPORT_SYMBOL_GPL(usb_calc_bus_time);
+
 #ifdef CONFIG_OF
 /**
  * of_usb_get_dr_mode_by_phy - Get dual role mode for the controller device
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 0b8a91004737..cbaa78043793 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1170,57 +1170,6 @@ EXPORT_SYMBOL_GPL(usb_hcd_end_port_resume);
 
 /*-------------------------------------------------------------------------*/
 
-/**
- * usb_calc_bus_time - approximate periodic transaction time in nanoseconds
- * @speed: from dev->speed; USB_SPEED_{LOW,FULL,HIGH}
- * @is_input: true iff the transaction sends data to the host
- * @isoc: true for isochronous transactions, false for interrupt ones
- * @bytecount: how many bytes in the transaction.
- *
- * Return: Approximate bus time in nanoseconds for a periodic transaction.
- *
- * Note:
- * See USB 2.0 spec section 5.11.3; only periodic transfers need to be
- * scheduled in software, this function is only used for such scheduling.
- */
-long usb_calc_bus_time (int speed, int is_input, int isoc, int bytecount)
-{
-	unsigned long	tmp;
-
-	switch (speed) {
-	case USB_SPEED_LOW: 	/* INTR only */
-		if (is_input) {
-			tmp = (67667L * (31L + 10L * BitTime (bytecount))) / 1000L;
-			return 64060L + (2 * BW_HUB_LS_SETUP) + BW_HOST_DELAY + tmp;
-		} else {
-			tmp = (66700L * (31L + 10L * BitTime (bytecount))) / 1000L;
-			return 64107L + (2 * BW_HUB_LS_SETUP) + BW_HOST_DELAY + tmp;
-		}
-	case USB_SPEED_FULL:	/* ISOC or INTR */
-		if (isoc) {
-			tmp = (8354L * (31L + 10L * BitTime (bytecount))) / 1000L;
-			return ((is_input) ? 7268L : 6265L) + BW_HOST_DELAY + tmp;
-		} else {
-			tmp = (8354L * (31L + 10L * BitTime (bytecount))) / 1000L;
-			return 9107L + BW_HOST_DELAY + tmp;
-		}
-	case USB_SPEED_HIGH:	/* ISOC or INTR */
-		/* FIXME adjust for input vs output */
-		if (isoc)
-			tmp = HS_NSECS_ISO (bytecount);
-		else
-			tmp = HS_NSECS (bytecount);
-		return tmp;
-	default:
-		pr_debug ("%s: bogus device speed!\n", usbcore_name);
-		return -1;
-	}
-}
-EXPORT_SYMBOL_GPL(usb_calc_bus_time);
-
-
-/*-------------------------------------------------------------------------*/
-
 /*
  * Generic HC operations.
  */
-- 
2.7.0



From aaro.koskinen at iki.fi  Fri Feb 19 13:44:26 2016
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Fri, 19 Feb 2016 23:44:26 +0200
Subject: [PATCH 1/2] ARM: OMAP1: DMA: Provide dma_slave_map to omap-dma
In-Reply-To: <1454423227-31830-2-git-send-email-peter.ujfalusi@ti.com>
References: <1454423227-31830-1-git-send-email-peter.ujfalusi@ti.com>
 <1454423227-31830-2-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <20160219214426.GK1640@darkstar.musicnaut.iki.fi>

On Tue, Feb 02, 2016 at 04:27:06PM +0200, Peter Ujfalusi wrote:
> OMAP1 can not boot in DT mode and to be able to clean up the driver
> regarding to the dmaengine API use (switching to the new API) the
> device/slave -> filter mapping needs to be provided to the omap-dma driver.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>

Acked-by: Aaro Koskinen <aaro.koskinen at iki.fi>

A.

> ---
>  arch/arm/mach-omap1/dma.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
> 
> diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
> index 7b02ed218a42..f6ba589cd312 100644
> --- a/arch/arm/mach-omap1/dma.c
> +++ b/arch/arm/mach-omap1/dma.c
> @@ -25,6 +25,7 @@
>  #include <linux/device.h>
>  #include <linux/io.h>
>  #include <linux/dma-mapping.h>
> +#include <linux/dmaengine.h>
>  #include <linux/omap-dma.h>
>  #include <mach/tc.h>
>  
> @@ -265,6 +266,42 @@ static const struct platform_device_info omap_dma_dev_info = {
>  	.num_res = 1,
>  };
>  
> +/* OMAP730, OMAP850 */
> +static const struct dma_slave_map omap7xx_sdma_map[] = {
> +	{ "omap-mcbsp.1", "tx", SDMA_FILTER_PARAM(8) },
> +	{ "omap-mcbsp.1", "rx", SDMA_FILTER_PARAM(9) },
> +	{ "omap-mcbsp.2", "tx", SDMA_FILTER_PARAM(10) },
> +	{ "omap-mcbsp.2", "rx", SDMA_FILTER_PARAM(11) },
> +	{ "mmci-omap.0", "tx", SDMA_FILTER_PARAM(21) },
> +	{ "mmci-omap.0", "rx", SDMA_FILTER_PARAM(22) },
> +	{ "omap_udc", "rx0", SDMA_FILTER_PARAM(26) },
> +	{ "omap_udc", "rx1", SDMA_FILTER_PARAM(27) },
> +	{ "omap_udc", "rx2", SDMA_FILTER_PARAM(28) },
> +	{ "omap_udc", "tx0", SDMA_FILTER_PARAM(29) },
> +	{ "omap_udc", "tx1", SDMA_FILTER_PARAM(30) },
> +	{ "omap_udc", "tx2", SDMA_FILTER_PARAM(31) },
> +};
> +
> +/* OMAP1510, OMAP1610*/
> +static const struct dma_slave_map omap1xxx_sdma_map[] = {
> +	{ "omap-mcbsp.1", "tx", SDMA_FILTER_PARAM(8) },
> +	{ "omap-mcbsp.1", "rx", SDMA_FILTER_PARAM(9) },
> +	{ "omap-mcbsp.3", "tx", SDMA_FILTER_PARAM(10) },
> +	{ "omap-mcbsp.3", "rx", SDMA_FILTER_PARAM(11) },
> +	{ "omap-mcbsp.2", "tx", SDMA_FILTER_PARAM(16) },
> +	{ "omap-mcbsp.2", "rx", SDMA_FILTER_PARAM(17) },
> +	{ "mmci-omap.0", "tx", SDMA_FILTER_PARAM(21) },
> +	{ "mmci-omap.0", "rx", SDMA_FILTER_PARAM(22) },
> +	{ "omap_udc", "rx0", SDMA_FILTER_PARAM(26) },
> +	{ "omap_udc", "rx1", SDMA_FILTER_PARAM(27) },
> +	{ "omap_udc", "rx2", SDMA_FILTER_PARAM(28) },
> +	{ "omap_udc", "tx0", SDMA_FILTER_PARAM(29) },
> +	{ "omap_udc", "tx1", SDMA_FILTER_PARAM(30) },
> +	{ "omap_udc", "tx2", SDMA_FILTER_PARAM(31) },
> +	{ "mmci-omap.1", "tx", SDMA_FILTER_PARAM(54) },
> +	{ "mmci-omap.1", "rx", SDMA_FILTER_PARAM(55) },
> +};
> +
>  static struct omap_system_dma_plat_info dma_plat_info __initdata = {
>  	.reg_map	= reg_map,
>  	.channel_stride	= 0x40,
> @@ -342,6 +379,14 @@ static int __init omap1_system_dma_init(void)
>  	p.dma_attr = d;
>  	p.errata = configure_dma_errata();
>  
> +	if (cpu_is_omap7xx()) {
> +		p.slave_map = omap7xx_sdma_map;
> +		p.slavecnt = ARRAY_SIZE(omap7xx_sdma_map);
> +	} else {
> +		p.slave_map = omap1xxx_sdma_map;
> +		p.slavecnt = ARRAY_SIZE(omap1xxx_sdma_map);
> +	}
> +
>  	ret = platform_device_add_data(pdev, &p, sizeof(p));
>  	if (ret) {
>  		dev_err(&pdev->dev, "%s: Unable to add resources for %s%d\n",
> -- 
> 2.7.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From stern at rowland.harvard.edu  Fri Feb 19 13:52:24 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Fri, 19 Feb 2016 16:52:24 -0500 (EST)
Subject: [PATCH] usb: move usb_calc_bus_time into common code
In-Reply-To: <1455918064-410571-1-git-send-email-arnd@arndb.de>
Message-ID: <Pine.LNX.4.44L0.1602191650570.1700-100000@iolanthe.rowland.org>

On Fri, 19 Feb 2016, Arnd Bergmann wrote:

> The dwc2 dual-role USB controller driver has started calling
> usb_calc_bus_time, and does so regardless of whether it is
> being built as a host controller or gadget. In case all

Out of curiosity...  Why does dwc2 need to calculate bus times when it
is in device mode?

Alan Stern



From torvalds at linux-foundation.org  Fri Feb 19 14:09:09 2016
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Fri, 19 Feb 2016 14:09:09 -0800
Subject: [PATCH v2] arm64: add alignment fault hanling
In-Reply-To: <20160219181410.GG12864@e104818-lin.cambridge.arm.com>
References: <329817481.954581455597874663.JavaMail.weblogic@epmlwas08c>
 <20160216103104.GC14509@arm.com> <56C300AD.8070505@arm.com>
 <20160216122153.GD19413@e104818-lin.cambridge.arm.com>
 <20160216160055.GH14509@arm.com> <20160216170408.GL14509@arm.com>
 <CA+55aFw-86k4gY46Et=e02HQQSxjUK2Jfz0SJz8tWtk5P8YZFA@mail.gmail.com>
 <20160219181410.GG12864@e104818-lin.cambridge.arm.com>
Message-ID: <CA+55aFyexYP2GLjFcmvyfwBGTyNy_HnBaBLFBgJzE6Le6Uzf0g@mail.gmail.com>

On Fri, Feb 19, 2016 at 10:14 AM, Catalin Marinas
<catalin.marinas at arm.com> wrote:
>
> Unless I misunderstand it, I don't think the user is even aware of this
> potential problem. Let's say it mmap's a file (script etc.) which
> contains a string (file name) towards the end of the last page. Such
> pointer gets passed to sys_open() and it eventually ends up in
> strncpy_from_user() with count == EMBEDDED_NAME_MAX (so well beyond the
> end of the page).
>
> The user also maps a device with mmap(NULL, ...) and there is a slight
> chance that the kernel allocates this VA space without any gap from the
> previous mmap().

Quite frankly, if the user mmap's MMIO - and particularly MMIO that
has side effects on speculative reads - the user had better be damn
sure they separate that MMIO well. Such a user should make sure they
have redzones around it on their own.

First off, it just doesn't happen. Basically zero applications map
MMIO to begin with, and the ones that do do it do it for frame buffers
etc that don't have side effects on reads.

I can't think of a single case of anybody actually having side effects
on reads on any sane hardware (except the obvious side effect of
"that's slow") any more, simply because it's horrible hardware design
and causes way worse problems than the whole page-crosser issue. Yeah,
I'm sure it exists somewhere, but I just wouldn't worry about it.

> Alternatively, aligning the source pointer reads (but not the
> destination) in strncpy_from_user() is another option, though I'm pretty
> sure we would notice some performance penalty.

It definitely is the destination pointer that needs alignment, simply
because that's the case that matters. There's a reason CPU's look
alike, and generally have patterns like "two read ports, one write
port" in their memory subsystem.

But more importantly, the kernel policy has always been to make the
cases that matter fast, and make sure we don't break anything.

If we can actually find a case where this matters and the dcache
access model actually breaks something, I'll care _deeply_, because it
will be the whole "no regressions" rule. But that "no regressions"
rule has always been about reality, not about theory.

We could make our strncpy try to be more careful about alignment. The
problem with that tends to be that keeping both source and destination
aligned is really complicated to do (a) efficiently and (b) portably.
There may well be things like vector extensions etc that are literally
*designed* for doing string copies and do the byte shifting in
hardware so that you can do things like this really well, but I'd like
to keep a (reasonably) simple generic strncpy_from_user() at least
until somebody actually sees it as a problem in real life.

          Linus


From arnd at arndb.de  Fri Feb 19 14:36:06 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Fri, 19 Feb 2016 23:36:06 +0100
Subject: [PATCH] thermal: mediatek: add missing dependencies
Message-ID: <1455921381-1881305-1-git-send-email-arnd@arndb.de>

The newly added mtk_thermal driver uses the generic reset
and nvmem infrastructure, but lacks a dependency that enforces
them from actually being present:

drivers/thermal/mtk_thermal.c: In function 'mtk_thermal_probe':
drivers/thermal/mtk_thermal.c:560:8: error: implicit declaration of function 'device_reset' [-Werror=implicit-function-declaration]
drivers/thermal/built-in.o: In function `mtk_thermal_probe':
mtk_thermal.c:(.text+0x7fb0): undefined reference to `nvmem_cell_get'
mtk_thermal.c:(.text+0x7fd8): undefined reference to `nvmem_cell_read'
mtk_thermal.c:(.text+0x7fe4): undefined reference to `nvmem_cell_put'

Without CONFIG_THERMAL, the driver cannot build, so this needs
to be a hard dependency.

For CONFIG_NVMEM, the header file allows building the driver even
when the subsystem is disabled, but we get the link error above
when nvmem is built as a module and the thermal driver is built-in,
so we can allow compile-testing when NVMEM is completely disabled,
but otherwise require the dependency.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/thermal/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 5e7c97a3f1d8..75d164341f0d 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -368,6 +368,8 @@ config INTEL_PCH_THERMAL
 config MTK_THERMAL
 	tristate "Temperature sensor driver for mediatek SoCs"
 	depends on ARCH_MEDIATEK || COMPILE_TEST
+	depends on NVMEM || (!NVMEM && COMPILE_TEST)
+	depends on RESET_CONTROLLER
 	default y
 	help
 	  Enable this option if you want to have support for thermal management
-- 
2.7.0



From f.fainelli at gmail.com  Fri Feb 19 14:37:59 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Fri, 19 Feb 2016 14:37:59 -0800
Subject: [GIT PULL 1/2] bcm2835 changes to defconfigs for 4.6
In-Reply-To: <56C625D0.3010504@gmail.com>
References: <1455764208-5679-1-git-send-email-eric@anholt.net>
 <56C625D0.3010504@gmail.com>
Message-ID: <56C79947.2050906@gmail.com>

On 18/02/16 12:13, Florian Fainelli wrote:
> On 17/02/16 18:56, Eric Anholt wrote:
>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>
>>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>
>> are available in the git repository at:
>>
>>   git at github.com:anholt/linux.git bcm2835-defconfig-next-2016-02-17
> 
> Same here, could not find this branch, should I pull from
> bcm2835-defconfig-next directly?

Eric, I would like to send the pull request soon, and this is one of the
gating items, please advise. Thanks!
-- 
Florian


From dianders at chromium.org  Fri Feb 19 14:48:50 2016
From: dianders at chromium.org (Doug Anderson)
Date: Fri, 19 Feb 2016 14:48:50 -0800
Subject: [PATCH] usb: move usb_calc_bus_time into common code
In-Reply-To: <Pine.LNX.4.44L0.1602191650570.1700-100000@iolanthe.rowland.org>
References: <1455918064-410571-1-git-send-email-arnd@arndb.de>
 <Pine.LNX.4.44L0.1602191650570.1700-100000@iolanthe.rowland.org>
Message-ID: <CAD=FV=VjgTUQR-Rw+LWXnNdZhruukaV-+LnXFqNRj-wpcvSJ4w@mail.gmail.com>

Hi,

On Fri, Feb 19, 2016 at 1:52 PM, Alan Stern <stern at rowland.harvard.edu> wrote:
> On Fri, 19 Feb 2016, Arnd Bergmann wrote:
>
>> The dwc2 dual-role USB controller driver has started calling
>> usb_calc_bus_time, and does so regardless of whether it is
>> being built as a host controller or gadget. In case all
>
> Out of curiosity...  Why does dwc2 need to calculate bus times when it
> is in device mode?

Hoo boy.  it doesn't.  Nor does it need to properly set the even/odd
frame in device mode.

Basically dwc2's "core.c" has a whole bunch of stuff in it that's host
only and isn't guarded with any #ifdef.  ...yet that file is included
in gadget-only builds.  It's a bit of a mess.  Take a gander at all of
the "dwc2_hc_xxx" functions sitting in "drivers/usb/dwc2/core.c".

Long term that needs to be cleaned up, but such a cleanup is going to
be a bit of churn so we'd need to schedule it for a time when not much
else is going on (and presumably it should be done by John or in close
coordination with him so it can get Acked / landed quickly to avoid
conflicts?).  To do this we'd have to figure out why some things are
in "core.c" and some in "hcd.c" and if it makes sense to move them all
to "hcd.c" or if we need a new "core_hc.c" or something...  All of
that design predates me.

In any case I guess we need a solution for right now, huh?

One terribly lame hack would be to just make a dummy no-op
"dwc2_hc_set_even_odd_frame()" if host mode is disabled.  That doesn't
really fix the root problem of lots of host mode code being compiled
in a gadget-only driver.  It also adds an ugly "#ifdef".  ...but it
does get around the current compile error.


What do folks think?

-Doug


From akshay.bhat at timesys.com  Fri Feb 19 15:35:24 2016
From: akshay.bhat at timesys.com (Akshay Bhat)
Date: Fri, 19 Feb 2016 18:35:24 -0500
Subject: [PATCH v8 0/7] ARM: dts: Add Advantech board support
Message-ID: <1455924931-13784-1-git-send-email-akshay.bhat@timesys.com>

This series aims to add Advantech BA-16 module (iMX6 based) and GE board support.

This series has been tested against linux-next tag next-20160216.

Modifications:
v7->v8:
Incorporate comments made by Shawn Guo
- BA16:
Remove invalid i2s-master property in ssi1 node
- Bx50v3:
Remove redundant address-cells/size-cells properties in clocks node
Update stgl5000 node name to codec to better match DT convention
Remove unused igb entries
Fix unit address for wlcore
Move status to last property in usdhc4 node

History:
--------
[v1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/381872.html
[v2]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/383276.html
[v3]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/384202.html
[v4]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390373.html
[v5]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390788.html
[v6]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/396131.html
[v7]: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/403429.html

Akshay Bhat (5):
  of: Add vendor prefix for Advantech Corporation
  of: Add vendor prefix for General Electric Company
  ARM: dts: imx: Add support for Advantech/GE B450v3
  ARM: dts: imx: Add support for Advantech/GE B650v3
  ARM: dts: imx: Add support for Advantech/GE B850v3

Justin Waters (2):
  ARM: dts: imx: Add Advantech BA-16 Qseven module
  ARM: dts: imx: Add support for Advantech/GE Bx50v3

 .../devicetree/bindings/vendor-prefixes.txt        |   2 +
 arch/arm/boot/dts/Makefile                         |   3 +
 arch/arm/boot/dts/imx6q-b450v3.dts                 |  88 +++
 arch/arm/boot/dts/imx6q-b650v3.dts                 |  88 +++
 arch/arm/boot/dts/imx6q-b850v3.dts                 | 157 +++++
 arch/arm/boot/dts/imx6q-ba16.dtsi                  | 632 +++++++++++++++++++++
 arch/arm/boot/dts/imx6q-bx50v3.dtsi                | 225 ++++++++
 7 files changed, 1195 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-b450v3.dts
 create mode 100644 arch/arm/boot/dts/imx6q-b650v3.dts
 create mode 100644 arch/arm/boot/dts/imx6q-b850v3.dts
 create mode 100644 arch/arm/boot/dts/imx6q-ba16.dtsi
 create mode 100644 arch/arm/boot/dts/imx6q-bx50v3.dtsi

-- 
2.7.1



From akshay.bhat at timesys.com  Fri Feb 19 15:35:25 2016
From: akshay.bhat at timesys.com (Akshay Bhat)
Date: Fri, 19 Feb 2016 18:35:25 -0500
Subject: [PATCH v8 1/7] of: Add vendor prefix for Advantech Corporation
In-Reply-To: <1455924931-13784-1-git-send-email-akshay.bhat@timesys.com>
References: <1455924931-13784-1-git-send-email-akshay.bhat@timesys.com>
Message-ID: <1455924931-13784-2-git-send-email-akshay.bhat@timesys.com>

This patch adds vendor prefix for Advantech Corporation.
Website: http://www.advantech.com/

Signed-off-by: Akshay Bhat <akshay.bhat at timesys.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index af1c7a6..0bade13 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -10,6 +10,7 @@ ad	Avionic Design GmbH
 adapteva	Adapteva, Inc.
 adh	AD Holdings Plc.
 adi	Analog Devices, Inc.
+advantech	Advantech Corporation
 aeroflexgaisler	Aeroflex Gaisler AB
 al	Annapurna Labs
 allwinner	Allwinner Technology Co., Ltd.
-- 
2.7.1



From akshay.bhat at timesys.com  Fri Feb 19 15:35:26 2016
From: akshay.bhat at timesys.com (Akshay Bhat)
Date: Fri, 19 Feb 2016 18:35:26 -0500
Subject: [PATCH v8 2/7] of: Add vendor prefix for General Electric Company
In-Reply-To: <1455924931-13784-1-git-send-email-akshay.bhat@timesys.com>
References: <1455924931-13784-1-git-send-email-akshay.bhat@timesys.com>
Message-ID: <1455924931-13784-3-git-send-email-akshay.bhat@timesys.com>

This patch adds vendor prefix for General Electric Company

Signed-off-by: Akshay Bhat <akshay.bhat at timesys.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 0bade13..83c2cb6 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -89,6 +89,7 @@ fcs	Fairchild Semiconductor
 firefly	Firefly
 focaltech	FocalTech Systems Co.,Ltd
 fsl	Freescale Semiconductor
+ge	General Electric Company
 GEFanuc	GE Fanuc Intelligent Platforms Embedded Systems, Inc.
 gef	GE Fanuc Intelligent Platforms Embedded Systems, Inc.
 geniatech	Geniatech, Inc.
-- 
2.7.1



From akshay.bhat at timesys.com  Fri Feb 19 15:35:27 2016
From: akshay.bhat at timesys.com (Akshay Bhat)
Date: Fri, 19 Feb 2016 18:35:27 -0500
Subject: [PATCH v8 3/7] ARM: dts: imx: Add Advantech BA-16 Qseven module
In-Reply-To: <1455924931-13784-1-git-send-email-akshay.bhat@timesys.com>
References: <1455924931-13784-1-git-send-email-akshay.bhat@timesys.com>
Message-ID: <1455924931-13784-4-git-send-email-akshay.bhat@timesys.com>

From: Justin Waters <justin.waters at timesys.com>

Add support for Advantech BA-16 module based on iMX6D processor

Basic information about the module:
 - Module manufacturer: Advantech
 - CPU: Freescale ARM Cortex-A9 i.MX6
 - SPECS:
     Up to 2GB Onboard DDR3 Memory;
     Up to 16GB Onboard eMMC NAND Flash
     Supports OpenGL ES 2.0 and OpenVG 1.1
     HDMI, 24-bit LVDS
     1x UART, 2x I2C, 8x GPIO,
     4x Host USB 2.0 port, 1x USB OTG port,
     1x micro SD (SDHC),1x SDIO, 1x SATA II,
     1x 10/100/1000 Mbps Ethernet, 1x PCIe X1 Gen2
 - Website: http://goo.gl/JED98U

Signed-off-by: Akshay Bhat <akshay.bhat at timesys.com>
Signed-off-by: Justin Waters <justin.waters at timesys.com>
---
 arch/arm/boot/dts/imx6q-ba16.dtsi | 632 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 632 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-ba16.dtsi

diff --git a/arch/arm/boot/dts/imx6q-ba16.dtsi b/arch/arm/boot/dts/imx6q-ba16.dtsi
new file mode 100644
index 0000000..8f6e603
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-ba16.dtsi
@@ -0,0 +1,632 @@
+/*
+ * Support for imx6 based Advantech DMS-BA16 Qseven module
+ *
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License
+ *     version 2 as published by the Free Software Foundation.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "imx6q.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+	memory {
+		reg = <0x10000000 0x40000000>;
+	};
+
+	backlight_lvds: backlight {
+		compatible = "pwm-backlight";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_display>;
+		pwms = <&pwm1 0 5000000>;
+		brightness-levels = <  0   1   2   3   4   5   6   7   8   9
+				      10  11  12  13  14  15  16  17  18  19
+				      20  21  22  23  24  25  26  27  28  29
+				      30  31  32  33  34  35  36  37  38  39
+				      40  41  42  43  44  45  46  47  48  49
+				      50  51  52  53  54  55  56  57  58  59
+				      60  61  62  63  64  65  66  67  68  69
+				      70  71  72  73  74  75  76  77  78  79
+				      80  81  82  83  84  85  86  87  88  89
+				      90  91  92  93  94  95  96  97  98  99
+				     100 101 102 103 104 105 106 107 108 109
+				     110 111 112 113 114 115 116 117 118 119
+				     120 121 122 123 124 125 126 127 128 129
+				     130 131 132 133 134 135 136 137 138 139
+				     140 141 142 143 144 145 146 147 148 149
+				     150 151 152 153 154 155 156 157 158 159
+				     160 161 162 163 164 165 166 167 168 169
+				     170 171 172 173 174 175 176 177 178 179
+				     180 181 182 183 184 185 186 187 188 189
+				     190 191 192 193 194 195 196 197 198 199
+				     200 201 202 203 204 205 206 207 208 209
+				     210 211 212 213 214 215 216 217 218 219
+				     220 221 222 223 224 225 226 227 228 229
+				     230 231 232 233 234 235 236 237 238 239
+				     240 241 242 243 244 245 246 247 248 249
+				     250 251 252 253 254 255>;
+		default-brightness-level = <255>;
+		enable-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>;
+	};
+
+	reg_1p8v: regulator-1p8v {
+		compatible = "regulator-fixed";
+		regulator-name = "1P8V";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-always-on;
+	};
+
+	reg_3p3v: regulator-3p3v {
+		compatible = "regulator-fixed";
+		regulator-name = "3P3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
+	reg_lvds: regulator-lvds {
+		compatible = "regulator-fixed";
+		regulator-name = "lvds_ppen";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+		gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	reg_usb_h1_vbus: regulator-usbh1vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_h1_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+	};
+
+	reg_usb_otg_vbus: regulator-usbotgvbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_otg_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+	};
+};
+
+&audmux {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_audmux>;
+	status = "okay";
+};
+
+&ecspi1 {
+	fsl,spi-num-chipselects = <1>;
+	cs-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi1>;
+	status = "okay";
+
+	flash: n25q032 at 0 {
+		compatible = "jedec,spi-nor";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		spi-max-frequency = <20000000>;
+		reg = <0>;
+
+		partition at 0 {
+			label = "U-Boot";
+			reg = <0x0 0xc0000>;
+		};
+
+		partition at c0000 {
+			label = "env";
+			reg = <0xc0000 0x10000>;
+		};
+
+		partition at d0000 {
+			label = "spare";
+			reg = <0xd0000 0x130000>;
+		};
+	};
+};
+
+&fec {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet>;
+	phy-mode = "rgmii";
+	status = "okay";
+};
+
+&hdmi {
+	ddc-i2c-bus = <&i2c2>;
+	status = "okay";
+};
+
+&i2c1 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1>;
+	status = "okay";
+};
+
+&i2c2 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	status = "okay";
+
+	pmic at 58 {
+		compatible = "dlg,da9063";
+		reg = <0x58>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pmic>;
+		interrupt-parent = <&gpio7>;
+		interrupts = <13 IRQ_TYPE_LEVEL_LOW>;
+
+		onkey {
+			compatible = "dlg,da9063-onkey";
+		};
+
+		regulators {
+			vdd_bcore1: bcore1 {
+				regulator-min-microvolt = <1420000>;
+				regulator-max-microvolt = <1420000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			vdd_bcore2: bcore2 {
+				regulator-min-microvolt = <1420000>;
+				regulator-max-microvolt = <1420000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			vdd_bpro: bpro {
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <1500000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			vdd_bmem: bmem {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			vdd_bio: bio {
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			vdd_bperi: bperi {
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			vdd_ldo1: ldo1 {
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <1860000>;
+			};
+
+			vdd_ldo2: ldo2 {
+				regulator-min-microvolt = <600000>;
+				regulator-max-microvolt = <1860000>;
+			};
+
+			vdd_ldo3: ldo3 {
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <3440000>;
+			};
+
+			vdd_ldo4: ldo4 {
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <3440000>;
+			};
+
+			vdd_ldo5: ldo5 {
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <3600000>;
+			};
+
+			vdd_ldo6: ldo6 {
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <3600000>;
+			};
+
+			vdd_ldo7: ldo7 {
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <3600000>;
+			};
+
+			vdd_ldo8: ldo8 {
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <3600000>;
+			};
+
+			vdd_ldo9: ldo9 {
+				regulator-min-microvolt = <950000>;
+				regulator-max-microvolt = <3600000>;
+			};
+
+			vdd_ldo10: ldo10 {
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <3600000>;
+			};
+
+			vdd_ldo11: ldo11 {
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <3600000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+		};
+	};
+
+	rtc at 32 {
+		compatible = "epson,rx8010";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_rtc>;
+		reg = <0x32>;
+		interrupt-parent = <&gpio4>;
+		interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
+	};
+};
+
+&pcie {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pcie>;
+	reset-gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+};
+
+&pwm1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pwm1>;
+	status = "okay";
+};
+
+&pwm2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pwm2>;
+	status = "okay";
+};
+
+&sata {
+	status = "okay";
+};
+
+&ssi1 {
+	status = "okay";
+};
+
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart3>;
+	fsl,uart-has-rtscts;
+	status = "okay";
+};
+
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart4>;
+	status = "okay";
+};
+
+&usbh1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbhub>;
+	vbus-supply = <&reg_usb_h1_vbus>;
+	reset-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+};
+
+&usbotg {
+	vbus-supply = <&reg_usb_otg_vbus>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usbotg>;
+	disable-over-current;
+	status = "okay";
+};
+
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2>;
+	cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
+	no-1-8-v;
+	keep-power-in-suspend;
+	wakeup-source;
+	status = "okay";
+};
+
+&usdhc3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc3 &pinctrl_usdhc3_reset>;
+	bus-width = <8>;
+	vmmc-supply = <&vdd_bperi>;
+	vqmmc-supply = <&vdd_bio>;
+	non-removable;
+	keep-power-in-suspend;
+	status = "okay";
+};
+
+&wdog1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdog>;
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_hog>;
+
+	pinctrl_audmux: audmuxgrp {
+		fsl,pins = <
+			MX6QDL_PAD_DISP0_DAT20__AUD4_TXC  0x130b0
+			MX6QDL_PAD_DISP0_DAT21__AUD4_TXD  0x130b0
+			MX6QDL_PAD_DISP0_DAT22__AUD4_TXFS 0x130b0
+			MX6QDL_PAD_DISP0_DAT23__AUD4_RXD  0x130b0
+		>;
+	};
+
+	pinctrl_display: dispgrp {
+		fsl,pins = <
+			/* BLEN_OUT */
+			MX6QDL_PAD_GPIO_0__GPIO1_IO00    0x1b0b0
+			/* LVDS_PPEN_OUT */
+			MX6QDL_PAD_EIM_D22__GPIO3_IO22   0x1b0b0
+		>;
+	};
+
+	pinctrl_ecspi1: ecspi1grp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_D17__ECSPI1_MISO	0x100b1
+			MX6QDL_PAD_EIM_D18__ECSPI1_MOSI	0x100b1
+			MX6QDL_PAD_EIM_D16__ECSPI1_SCLK	0x100b1
+			/* SPI1 CS */
+			MX6QDL_PAD_EIM_EB2__GPIO2_IO30	0x1b0b0
+		>;
+	};
+
+	pinctrl_ecspi5: ecspi5grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD1_DAT0__ECSPI5_MISO	0x1b0b0
+			MX6QDL_PAD_SD1_CMD__ECSPI5_MOSI		0x1b0b0
+			MX6QDL_PAD_SD1_CLK__ECSPI5_SCLK		0x1b0b0
+			MX6QDL_PAD_SD1_DAT1__GPIO1_IO17		0x1b0b0
+		>;
+	};
+
+	pinctrl_enet: enetgrp {
+		fsl,pins = <
+			MX6QDL_PAD_ENET_MDIO__ENET_MDIO       0x100b0
+			MX6QDL_PAD_ENET_MDC__ENET_MDC         0x100b0
+			MX6QDL_PAD_RGMII_TXC__RGMII_TXC       0x100b0
+			MX6QDL_PAD_RGMII_TD0__RGMII_TD0       0x100b0
+			MX6QDL_PAD_RGMII_TD1__RGMII_TD1       0x100b0
+			MX6QDL_PAD_RGMII_TD2__RGMII_TD2       0x100b0
+			MX6QDL_PAD_RGMII_TD3__RGMII_TD3       0x100b0
+			MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x100b0
+			MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK  0x100b0
+			MX6QDL_PAD_RGMII_RXC__RGMII_RXC       0x1b0b0
+			MX6QDL_PAD_RGMII_RD0__RGMII_RD0       0x1b0b0
+			MX6QDL_PAD_RGMII_RD1__RGMII_RD1       0x1b0b0
+			MX6QDL_PAD_RGMII_RD2__RGMII_RD2       0x1b0b0
+			MX6QDL_PAD_RGMII_RD3__RGMII_RD3       0x1b0b0
+			MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
+			/* FEC Reset */
+			MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28     0x1b0b0
+			/* AR8033 Interrupt */
+			MX6QDL_PAD_GPIO_19__GPIO4_IO05        0x1b0b0
+		>;
+	};
+
+	pinctrl_hog: hoggrp {
+		fsl,pins = <
+			/* GPIO 0-7 */
+			MX6QDL_PAD_NANDF_D0__GPIO2_IO00  0x1b0b0
+			MX6QDL_PAD_NANDF_D1__GPIO2_IO01  0x1b0b0
+			MX6QDL_PAD_NANDF_D2__GPIO2_IO02  0x1b0b0
+			MX6QDL_PAD_NANDF_D3__GPIO2_IO03  0x1b0b0
+			MX6QDL_PAD_NANDF_D4__GPIO2_IO04  0x1b0b0
+			MX6QDL_PAD_NANDF_D5__GPIO2_IO05  0x1b0b0
+			MX6QDL_PAD_NANDF_D6__GPIO2_IO06  0x1b0b0
+			MX6QDL_PAD_NANDF_D7__GPIO2_IO07  0x1b0b0
+			/* SUS_S3_OUT to CPLD */
+			MX6QDL_PAD_KEY_ROW2__GPIO4_IO11  0x1b0b0
+		>;
+	};
+
+	pinctrl_i2c1: i2c1grp {
+		fsl,pins = <
+			MX6QDL_PAD_CSI0_DAT8__I2C1_SDA	0x4001b8b1
+			MX6QDL_PAD_CSI0_DAT9__I2C1_SCL	0x4001b8b1
+		>;
+	};
+
+	pinctrl_i2c2: i2c2grp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL3__I2C2_SCL	0x4001b8b1
+			MX6QDL_PAD_KEY_ROW3__I2C2_SDA	0x4001b8b1
+		>;
+	};
+
+	pinctrl_i2c3: i2c3grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_3__I2C3_SCL	0x4001b8b1
+			MX6QDL_PAD_GPIO_6__I2C3_SDA	0x4001b8b1
+		>;
+	};
+
+	pinctrl_pcie: pciegrp {
+		fsl,pins = <
+			/* PCIe Reset */
+			MX6QDL_PAD_GPIO_17__GPIO7_IO12	0x1b0b0
+			/* PCIe Wake */
+			MX6QDL_PAD_GPIO_5__GPIO1_IO05	0x1b0b0
+		>;
+	};
+
+	pinctrl_pmic: pmicgrp {
+		fsl,pins = <
+			/* PMIC Interrupt */
+			MX6QDL_PAD_GPIO_18__GPIO7_IO13	0x1b0b0
+		>;
+	};
+
+	pinctrl_pwm1: pwm1grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD1_DAT3__PWM1_OUT	0x1b0b1
+		>;
+	};
+
+	pinctrl_pwm2: pwm2grp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_1__PWM2_OUT	0x1b0b1
+		>;
+	};
+
+	pinctrl_rtc: rtcgrp {
+		fsl,pins = <
+			/* RTC_INT */
+			MX6QDL_PAD_KEY_COL2__GPIO4_IO10	0x1b0b0
+		>;
+	};
+
+	pinctrl_uart3: uart3grp {
+		fsl,pins = <
+			MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
+			MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
+			MX6QDL_PAD_EIM_D23__UART3_CTS_B   0x1b0b1
+			MX6QDL_PAD_EIM_D31__UART3_RTS_B   0x1b0b1
+		>;
+	};
+
+	pinctrl_uart4: uart4grp {
+		fsl,pins = <
+			MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
+			MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
+		>;
+	};
+
+	pinctrl_usbhub: usbhubgrp {
+		fsl,pins = <
+			/* HUB_RESET */
+			MX6QDL_PAD_GPIO_16__GPIO7_IO11	0x1b0b0
+		>;
+	};
+
+	pinctrl_usbotg: usbotggrp {
+		fsl,pins = <
+			MX6QDL_PAD_ENET_RX_ER__USB_OTG_ID 0x17059
+		>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD2_CMD__SD2_CMD	0x17059
+			MX6QDL_PAD_SD2_CLK__SD2_CLK	0x10059
+			MX6QDL_PAD_SD2_DAT0__SD2_DATA0	0x17059
+			MX6QDL_PAD_SD2_DAT1__SD2_DATA1	0x17059
+			MX6QDL_PAD_SD2_DAT2__SD2_DATA2	0x17059
+			MX6QDL_PAD_SD2_DAT3__SD2_DATA3	0x17059
+			/* uSDHC2 CD */
+			MX6QDL_PAD_GPIO_4__GPIO1_IO04	0x1b0b0
+		>;
+	};
+
+	pinctrl_usdhc3: usdhc3grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD3_CMD__SD3_CMD	0x17059
+			MX6QDL_PAD_SD3_CLK__SD3_CLK	0x10059
+			MX6QDL_PAD_SD3_DAT0__SD3_DATA0	0x17059
+			MX6QDL_PAD_SD3_DAT1__SD3_DATA1	0x17059
+			MX6QDL_PAD_SD3_DAT2__SD3_DATA2	0x17059
+			MX6QDL_PAD_SD3_DAT3__SD3_DATA3	0x17059
+			MX6QDL_PAD_SD3_DAT4__SD3_DATA4	0x17059
+			MX6QDL_PAD_SD3_DAT5__SD3_DATA5	0x17059
+			MX6QDL_PAD_SD3_DAT6__SD3_DATA6	0x17059
+			MX6QDL_PAD_SD3_DAT7__SD3_DATA7	0x17059
+		>;
+	};
+
+	pinctrl_usdhc3_reset: usdhc3grp-reset {
+		fsl,pins = <
+			MX6QDL_PAD_SD3_RST__SD3_RESET   0x170F9
+		>;
+	};
+
+	pinctrl_usdhc4: usdhc4grp {
+		fsl,pins = <
+			MX6QDL_PAD_SD4_CMD__SD4_CMD	0x17059
+			MX6QDL_PAD_SD4_CLK__SD4_CLK	0x17059
+			MX6QDL_PAD_SD4_DAT0__SD4_DATA0	0x17059
+			MX6QDL_PAD_SD4_DAT1__SD4_DATA1	0x17059
+			MX6QDL_PAD_SD4_DAT2__SD4_DATA2	0x17059
+			MX6QDL_PAD_SD4_DAT3__SD4_DATA3	0x17059
+			MX6QDL_PAD_SD4_DAT4__SD4_DATA4	0x17059
+			MX6QDL_PAD_SD4_DAT5__SD4_DATA5	0x17059
+			MX6QDL_PAD_SD4_DAT6__SD4_DATA6	0x17059
+			MX6QDL_PAD_SD4_DAT7__SD4_DATA7	0x17059
+			/* uSDHC4 CD */
+			MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x1b0b0
+			/* uSDHC4 SDIO PWR */
+			MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x1b0b0
+			/* uSDHC4 SDIO WP */
+			MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x1b0b0
+			/* uSDHC4 SDIO LED */
+			MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x1b0b0
+		>;
+	};
+
+	pinctrl_wdog: wdoggrp {
+		fsl,pins = <
+			MX6QDL_PAD_GPIO_9__WDOG1_B	0x1b0b0
+		>;
+	};
+};
-- 
2.7.1



From akshay.bhat at timesys.com  Fri Feb 19 15:35:28 2016
From: akshay.bhat at timesys.com (Akshay Bhat)
Date: Fri, 19 Feb 2016 18:35:28 -0500
Subject: [PATCH v8 4/7] ARM: dts: imx: Add support for Advantech/GE Bx50v3
In-Reply-To: <1455924931-13784-1-git-send-email-akshay.bhat@timesys.com>
References: <1455924931-13784-1-git-send-email-akshay.bhat@timesys.com>
Message-ID: <1455924931-13784-5-git-send-email-akshay.bhat@timesys.com>

From: Justin Waters <justin.waters at timesys.com>

Advantech has 3 carrier boards (B450v3, B650v3, B850v3) which use
the Advantech BA-16 module (based on iMX6D). This file has the
devicetree entries that are common to all 3 boards.

Signed-off-by: Akshay Bhat <akshay.bhat at timesys.com>
Signed-off-by: Justin Waters <justin.waters at timesys.com>
---
 arch/arm/boot/dts/imx6q-bx50v3.dtsi | 225 ++++++++++++++++++++++++++++++++++++
 1 file changed, 225 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-bx50v3.dtsi

diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
new file mode 100644
index 0000000..bb66dfd
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
@@ -0,0 +1,225 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License
+ *     version 2 as published by the Free Software Foundation.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "imx6q-ba16.dtsi"
+
+/ {
+	clocks {
+		mclk: clock at 0 {
+			compatible = "fixed-clock";
+			reg = <0>;
+			#clock-cells = <0>;
+			clock-frequency = <22000000>;
+		};
+	};
+
+	reg_wl18xx_vmmc: regulator-wl18xx {
+		compatible = "regulator-fixed";
+		regulator-name = "vwl1807";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&pca9539 3 GPIO_ACTIVE_HIGH>;
+		startup-delay-us = <70000>;
+		enable-active-high;
+	};
+
+	reg_wlan: regulator-wlan {
+		compatible = "regulator-fixed";
+		regulator-name = "3P3V_wlan";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+		gpio = <&gpio6 14 GPIO_ACTIVE_HIGH>;
+	};
+
+	sound {
+		compatible = "fsl,imx6q-ba16-sgtl5000",
+			     "fsl,imx-audio-sgtl5000";
+		model = "imx6q-ba16-sgtl5000";
+		ssi-controller = <&ssi1>;
+		audio-codec = <&sgtl5000>;
+		audio-routing =
+			"MIC_IN", "Mic Jack",
+			"Mic Jack", "Mic Bias",
+			"LINE_IN", "Line In Jack",
+			"Headphone Jack", "HP_OUT";
+		mux-int-port = <1>;
+		mux-ext-port = <4>;
+	};
+};
+
+&ecspi5 {
+	fsl,spi-num-chipselects = <1>;
+	cs-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi5>;
+	status = "okay";
+
+	m25_eeprom: m25p80 at 0 {
+		compatible = "atmel,at25";
+		spi-max-frequency = <20000000>;
+		size = <0x8000>;
+		pagesize = <64>;
+		reg = <0>;
+		address-width = <16>;
+	};
+};
+
+&i2c1 {
+	pca9547: mux at 70 {
+		compatible = "nxp,pca9547";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		mux1_i2c1: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0>;
+
+			ads7830: ads7830 at 48 {
+				compatible = "ti,ads7830";
+				reg = <0x48>;
+			};
+
+			mma8453: mma8453 at 1c {
+				compatible = "fsl,mma8453";
+				reg = <0x1c>;
+			};
+		};
+
+		mux1_i2c2: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x1>;
+
+			eeprom: eeprom at 50 {
+				compatible = "atmel,24c08";
+				reg = <0x50>;
+			};
+
+			mpl3115: mpl3115 at 60 {
+				compatible = "fsl,mpl3115";
+				reg = <0x60>;
+			};
+		};
+
+		mux1_i2c3: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x2>;
+		};
+
+		mux1_i2c4: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x3>;
+
+			sgtl5000: codec at 0a {
+				compatible = "fsl,sgtl5000";
+				reg = <0x0a>;
+				clocks = <&mclk>;
+				VDDA-supply = <&reg_1p8v>;
+				VDDIO-supply = <&reg_3p3v>;
+			};
+		};
+
+		mux1_i2c5: i2c at 4 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x4>;
+
+			pca9539: pca9539 at 74 {
+				compatible = "nxp,pca9539";
+				reg = <0x74>;
+				gpio-controller;
+				#gpio-cells = <2>;
+				interrupt-controller;
+				interrupt-parent = <&gpio2>;
+				interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+			};
+		};
+
+		mux1_i2c6: i2c at 5 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x5>;
+		};
+
+		mux1_i2c7: i2c at 6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x6>;
+		};
+
+		mux1_i2c8: i2c at 7 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x7>;
+		};
+	};
+};
+
+&usdhc4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc4>;
+	bus-width = <4>;
+	vmmc-supply = <&reg_wl18xx_vmmc>;
+	no-1-8-v;
+	non-removable;
+	wakeup-source;
+	keep-power-in-suspend;
+	cap-power-off-card;
+	max-frequency = <25000000>;
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+
+	wlcore: wlcore at 2 {
+		compatible = "ti,wl1837";
+		reg = <2>;
+		interrupt-parent = <&gpio2>;
+		interrupts = <6 IRQ_TYPE_LEVEL_HIGH>;
+		tcxo-clock-frequency = <26000000>;
+	};
+};
-- 
2.7.1



From akshay.bhat at timesys.com  Fri Feb 19 15:35:29 2016
From: akshay.bhat at timesys.com (Akshay Bhat)
Date: Fri, 19 Feb 2016 18:35:29 -0500
Subject: [PATCH v8 5/7] ARM: dts: imx: Add support for Advantech/GE B450v3
In-Reply-To: <1455924931-13784-1-git-send-email-akshay.bhat@timesys.com>
References: <1455924931-13784-1-git-send-email-akshay.bhat@timesys.com>
Message-ID: <1455924931-13784-6-git-send-email-akshay.bhat@timesys.com>

Add support for Advantech/GE B450v3 board.

Signed-off-by: Akshay Bhat <akshay.bhat at timesys.com>
---
 arch/arm/boot/dts/Makefile         |  1 +
 arch/arm/boot/dts/imx6q-b450v3.dts | 88 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 89 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-b450v3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a1d4f12..106d324 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -325,6 +325,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
 	imx6q-apalis-ixora.dtb \
 	imx6q-apf6dev.dtb \
 	imx6q-arm2.dtb \
+	imx6q-b450v3.dtb \
 	imx6q-cm-fx6.dtb \
 	imx6q-cubox-i.dtb \
 	imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b450v3.dts b/arch/arm/boot/dts/imx6q-b450v3.dts
new file mode 100644
index 0000000..3101be5
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b450v3.dts
@@ -0,0 +1,88 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License
+ *     version 2 as published by the Free Software Foundation.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+	model = "General Electric B450v3";
+	compatible = "ge,imx6q-b450v3", "advantech,imx6q-ba16", "fsl,imx6q";
+
+	chosen {
+		stdout-path = &uart3;
+	};
+
+	panel-lvds0 {
+		compatible = "innolux,g121x1-l03";
+		backlight = <&backlight_lvds>;
+		power-supply = <&reg_lvds>;
+
+		port {
+			panel_in_lvds0: endpoint {
+				remote-endpoint = <&lvds0_out>;
+			};
+		};
+	};
+};
+
+&ldb {
+	assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+			  <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+	assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+				 <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+	status = "okay";
+
+	lvds0: lvds-channel at 0 {
+		fsl,data-mapping = "spwg";
+		fsl,data-width = <24>;
+		status = "okay";
+
+		port at 4 {
+			reg = <4>;
+
+			lvds0_out: endpoint {
+				remote-endpoint = <&panel_in_lvds0>;
+			};
+		};
+	};
+};
-- 
2.7.1



From akshay.bhat at timesys.com  Fri Feb 19 15:35:31 2016
From: akshay.bhat at timesys.com (Akshay Bhat)
Date: Fri, 19 Feb 2016 18:35:31 -0500
Subject: [PATCH v8 7/7] ARM: dts: imx: Add support for Advantech/GE B850v3
In-Reply-To: <1455924931-13784-1-git-send-email-akshay.bhat@timesys.com>
References: <1455924931-13784-1-git-send-email-akshay.bhat@timesys.com>
Message-ID: <1455924931-13784-8-git-send-email-akshay.bhat@timesys.com>

Add support for Advantech/GE B850v3 board.

Signed-off-by: Akshay Bhat <akshay.bhat at timesys.com>
---
 arch/arm/boot/dts/Makefile         |   1 +
 arch/arm/boot/dts/imx6q-b850v3.dts | 157 +++++++++++++++++++++++++++++++++++++
 2 files changed, 158 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-b850v3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9bdbff8..0387b5d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -327,6 +327,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
 	imx6q-arm2.dtb \
 	imx6q-b450v3.dtb \
 	imx6q-b650v3.dtb \
+	imx6q-b850v3.dtb \
 	imx6q-cm-fx6.dtb \
 	imx6q-cubox-i.dtb \
 	imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts b/arch/arm/boot/dts/imx6q-b850v3.dts
new file mode 100644
index 0000000..984d000
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b850v3.dts
@@ -0,0 +1,157 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License
+ *     version 2 as published by the Free Software Foundation.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+	model = "General Electric B850v3";
+	compatible = "ge,imx6q-b850v3", "advantech,imx6q-ba16", "fsl,imx6q";
+
+	chosen {
+		stdout-path = &uart3;
+	};
+
+	panel-lvds0 {
+		compatible = "auo,b133htn01";
+		backlight = <&backlight_lvds>;
+		ddc-i2c-bus = <&mux2_i2c2>;
+
+		port {
+			panel_in_lvds0: endpoint {
+				remote-endpoint = <&lvds0_out>;
+			};
+		};
+	};
+};
+
+&ldb {
+	assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+			  <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+	assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+				 <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+	fsl,dual-channel;
+	status = "okay";
+
+	lvds0: lvds-channel at 0 {
+		fsl,data-mapping = "spwg";
+		fsl,data-width = <24>;
+		status = "okay";
+
+		port at 4 {
+			reg = <4>;
+
+			lvds0_out: endpoint {
+				remote-endpoint = <&panel_in_lvds0>;
+			};
+		};
+	};
+};
+
+&i2c2 {
+	pca9547_ddc: mux at 70 {
+		compatible = "nxp,pca9547";
+		reg = <0x70>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		mux2_i2c1: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0>;
+		};
+
+		mux2_i2c2: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x1>;
+		};
+
+		mux2_i2c3: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x2>;
+		};
+
+		mux2_i2c4: i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x3>;
+		};
+
+		mux2_i2c5: i2c at 4 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x4>;
+		};
+
+		mux2_i2c6: i2c at 5 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x5>;
+		};
+
+		mux2_i2c7: i2c at 6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x6>;
+		};
+
+		mux2_i2c8: i2c at 7 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x7>;
+		};
+	};
+};
+
+&hdmi {
+	ddc-i2c-bus = <&mux2_i2c1>;
+};
+
+&mux1_i2c1 {
+	ads7830 at 4a {
+		compatible = "ti,ads7830";
+		reg = <0x4a>;
+	};
+};
-- 
2.7.1



From akshay.bhat at timesys.com  Fri Feb 19 15:35:30 2016
From: akshay.bhat at timesys.com (Akshay Bhat)
Date: Fri, 19 Feb 2016 18:35:30 -0500
Subject: [PATCH v8 6/7] ARM: dts: imx: Add support for Advantech/GE B650v3
In-Reply-To: <1455924931-13784-1-git-send-email-akshay.bhat@timesys.com>
References: <1455924931-13784-1-git-send-email-akshay.bhat@timesys.com>
Message-ID: <1455924931-13784-7-git-send-email-akshay.bhat@timesys.com>

Add support for Advantech/GE B650v3 board.

Signed-off-by: Akshay Bhat <akshay.bhat at timesys.com>
---
 arch/arm/boot/dts/Makefile         |  1 +
 arch/arm/boot/dts/imx6q-b650v3.dts | 88 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 89 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-b650v3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 106d324..9bdbff8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -326,6 +326,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
 	imx6q-apf6dev.dtb \
 	imx6q-arm2.dtb \
 	imx6q-b450v3.dtb \
+	imx6q-b650v3.dtb \
 	imx6q-cm-fx6.dtb \
 	imx6q-cubox-i.dtb \
 	imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b650v3.dts b/arch/arm/boot/dts/imx6q-b650v3.dts
new file mode 100644
index 0000000..823f55c
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b650v3.dts
@@ -0,0 +1,88 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 General Electric Company
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License
+ *     version 2 as published by the Free Software Foundation.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+	model = "General Electric B650v3";
+	compatible = "ge,imx6q-b650v3", "advantech,imx6q-ba16", "fsl,imx6q";
+
+	chosen {
+		stdout-path = &uart3;
+	};
+
+	panel-lvds0 {
+		compatible = "innolux,g121x1-l03";
+		backlight = <&backlight_lvds>;
+		power-supply = <&reg_lvds>;
+
+		port {
+			panel_in_lvds0: endpoint {
+				remote-endpoint = <&lvds0_out>;
+			};
+		};
+	};
+};
+
+&ldb {
+	assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+			  <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+	assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+				 <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+	status = "okay";
+
+	lvds0: lvds-channel at 0 {
+		fsl,data-mapping = "spwg";
+		fsl,data-width = <24>;
+		status = "okay";
+
+		port at 4 {
+			reg = <4>;
+
+			lvds0_out: endpoint {
+				remote-endpoint = <&panel_in_lvds0>;
+			};
+		};
+	};
+};
-- 
2.7.1



From al.stone at linaro.org  Fri Feb 19 15:54:01 2016
From: al.stone at linaro.org (al.stone at linaro.org)
Date: Fri, 19 Feb 2016 16:54:01 -0700
Subject: [PATCH] ARM64: ACPI: Update documentation for latest specification
 version
Message-ID: <1455926041-9579-1-git-send-email-al.stone@linaro.org>

From: Al Stone <al.stone at linaro.org>	

The ACPI 6.1 specification was recently released at the end of January 2016,
but the arm64 kernel documentation for the use of ACPI was written for the
5.1 version of the spec.  There were significant additions to the spec that
had not yet been mentioned -- for example, the 6.0 mechanisms added to make
it easier to define processors and low power idle states, as well as the
6.1 addition allowing regular interrupts (not just from GPIO) be used to
signal ACPI general purpose events.

This patch reflects going back through and examining the specs in detail
and updating content appropriately.  Whilst there, a few odds and ends of
typos were caught as well.  This brings the documentation up to date with
ACPI 6.1 for arm64.

Signed-off-by: Al Stone <al.stone at linaro.org>
---
 Documentation/arm64/acpi_object_usage.txt | 433 ++++++++++++++++++++++--------
 Documentation/arm64/arm-acpi.txt          |  28 +-
 2 files changed, 346 insertions(+), 115 deletions(-)

diff --git a/Documentation/arm64/acpi_object_usage.txt b/Documentation/arm64/acpi_object_usage.txt
index a6e1a18..e321235 100644
--- a/Documentation/arm64/acpi_object_usage.txt
+++ b/Documentation/arm64/acpi_object_usage.txt
@@ -13,13 +13,14 @@ For ACPI on arm64, tables also fall into the following categories:
 
        -- Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT
 
-       -- Recommended: BERT, EINJ, ERST, HEST, SSDT
+       -- Recommended: BERT, EINJ, ERST, HEST, IORT, PCCT, SSDT
 
-       -- Optional: BGRT, CPEP, CSRT, DRTM, ECDT, FACS, FPDT, MCHI, MPST,
-          MSCT, RASF, SBST, SLIT, SPMI, SRAT, TCPA, TPM2, UEFI
+       -- Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, MCHI,
+          MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT, STAO, TCPA,
+	  TPM2, UEFI, XENV
 
-       -- Not supported: BOOT, DBG2, DBGP, DMAR, ETDT, HPET, IBFT, IVRS,
-          LPIT, MSDM, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
+       -- Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IBFT, IVRS, LPIT, 
+          MSDM, OEMx, PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
 
 
 Table  Usage for ARMv8 Linux
@@ -50,7 +51,9 @@ CSRT   Signature Reserved (signature == "CSRT")
 
 DBG2   Signature Reserved (signature == "DBG2")
        == DeBuG port table 2 ==
-       Microsoft only table, will not be supported.
+       License has changed and should be usable.  Patches are available as of
+       this writing, but they have not been accepted into the kernel.  Optional
+       if used instead of earlycon=<device> on the command line.
 
 DBGP   Signature Reserved (signature == "DBGP")
        == DeBuG Port table ==
@@ -133,10 +136,11 @@ GTDT   Section 5.2.24 (signature == "GTDT")
 
 HEST   Section 18.3.2 (signature == "HEST")
        == Hardware Error Source Table ==
-       Until further error source types are defined, use only types 6 (AER
-       Root Port), 7 (AER Endpoint), 8 (AER Bridge), or 9 (Generic Hardware
-       Error Source).  Firmware first error handling is possible if and only
-       if Trusted Firmware is being used on arm64.
+       ARM-specific error sources have been defined; please use those or the
+       PCI types such as type 6 (AER Root Port), 7 (AER Endpoint), or 8 (AER 
+       Bridge), or use type 9 (Generic Hardware Error Source).  Firmware first
+       error handling is possible if and only if Trusted Firmware is being 
+       used on arm64.
 
        Must be supplied if RAS support is provided by the platform.  It
        is recommended this table be supplied.
@@ -149,20 +153,26 @@ IBFT   Signature Reserved (signature == "IBFT")
        == iSCSI Boot Firmware Table ==
        Microsoft defined table, support TBD.
 
+IORT   Signature Reserved (signature == "IORT")
+       == Input Output Remapping Table ==
+       arm64 only table, required in order to describe the SMMU and/or ITS 
+       when it is provided by the platform.
+
 IVRS   Signature Reserved (signature == "IVRS")
        == I/O Virtualization Reporting Structure ==
        x86_64 (AMD) only table, will not be supported.
 
 LPIT   Signature Reserved (signature == "LPIT")
        == Low Power Idle Table ==
-       x86 only table as of ACPI 5.1; future versions have been adapted for
-       use with ARM and will be recommended in order to support ACPI power
-       management.
+       x86 only table as of ACPI 5.1; starting with ACPI 6.0, processor
+       descriptions and power states on ARM platforms should use the DSDT
+       and define processor container devices (_HID ACPI0010, Section 8.4,
+       and more specifically 8.4.3 and and 8.4.4).
 
 MADT   Section 5.2.12 (signature == "APIC")
        == Multiple APIC Description Table ==
        Required for arm64.  Only the GIC interrupt controller structures
-       should be used (types 0xA - 0xE).
+       should be used (types 0xA - 0xF).
 
 MCFG   Signature Reserved (signature == "MCFG")
        == Memory-mapped ConFiGuration space ==
@@ -176,14 +186,38 @@ MPST   Section 5.2.21 (signature == "MPST")
        == Memory Power State Table ==
        Optional, not currently supported.
 
+MSCT   Section 5.2.19 (signature == "MSCT")
+       == Maximum System Characteristic Table ==
+       Optional, not currently supported.
+
 MSDM   Signature Reserved (signature == "MSDM")
        == Microsoft Data Management table ==
        Microsoft only table, will not be supported.
 
-MSCT   Section 5.2.19 (signature == "MSCT")
-       == Maximum System Characteristic Table ==
+NFIT   Section 5.2.25 (signature == "NFIT")
+       == NVDIMM Firmware Interface Table ==
        Optional, not currently supported.
 
+OEMx   Signature of "OEMx" only
+       == OEM Specific Tables ==
+       All tables starting with a signature of "OEM" are reserved for OEM
+       use.  Since these are not meant to be of general use but are limited
+       to very specific end users, they are not recommended for use and are
+       not supported by the kernel for arm64.
+
+PCCT   Section 14.1 (signature == "PCCT)
+       == Platform Communications Channel Table ==
+       Recommend for use on arm64, and required when using CPPC to control
+       power on the platform.
+
+PMTT   Section 5.2.21.12 (signature == "PMTT")
+       == Platform Memory Topology Table ==
+       Optional, but useful, but not currently supported.
+
+PSDT   Section 5.2.11.3 (signature == "PSDT")
+       == Persistent System Description Table ==
+       Obsolete table, will not be supported.
+
 RASF   Section 5.2.20 (signature == "RASF")
        == RAS Feature table ==
        Optional, not currently supported.
@@ -195,7 +229,7 @@ RSDP   Section 5.2.5 (signature == "RSD PTR")
 RSDT   Section 5.2.7 (signature == "RSDT")
        == Root System Description Table ==
        Since this table can only provide 32-bit addresses, it is deprecated
-       on arm64, and will not be used.
+       on arm64, and will not be used.  If provided, it will be ignored.
 
 SBST   Section 5.2.14 (signature == "SBST")
        == Smart Battery Subsystem Table ==
@@ -207,7 +241,7 @@ SLIC   Signature Reserved (signature == "SLIC")
 
 SLIT   Section 5.2.17 (signature == "SLIT")
        == System Locality distance Information Table ==
-       Optional in general, but required for NUMA systems.
+       Optional in general, but required for arm64 NUMA systems.
 
 SPCR   Signature Reserved (signature == "SPCR")
        == Serial Port Console Redirection table ==
@@ -220,7 +254,7 @@ SPMI   Signature Reserved (signature == "SPMI")
 SRAT   Section 5.2.16 (signature == "SRAT")
        == System Resource Affinity Table ==
        Optional, but if used, only the GICC Affinity structures are read.
-       To support NUMA, this table is required.
+       To support arm64 NUMA, this table is required.
 
 SSDT   Section 5.2.11.2 (signature == "SSDT")
        == Secondary System Description Table ==
@@ -235,6 +269,11 @@ SSDT   Section 5.2.11.2 (signature == "SSDT")
        These tables are optional, however.  ACPI tables should contain only
        one DSDT but can contain many SSDTs.
 
+STAO   Signature Reserved (signature == "STAO")
+       == _STA Override table ==
+       Optional, but only necessary in virtualized environments in order to
+       hide devices from guest OSs.
+
 TCPA   Signature Reserved (signature == "TCPA")
        == Trusted Computing Platform Alliance table ==
        Optional, not currently supported, and may need changes to fully
@@ -266,6 +305,10 @@ WPBT   Signature Reserved (signature == "WPBT")
        == Windows Platform Binary Table ==
        Microsoft only table, will not be supported.
 
+XENV   Signature Reserved (signature == "XENV")
+       == Xen project table ==
+       Optional, used only by Xen at present.
+
 XSDT   Section 5.2.8 (signature == "XSDT")
        == eXtended System Description Table ==
        Required for arm64.
@@ -273,31 +316,50 @@ XSDT   Section 5.2.8 (signature == "XSDT")
 
 ACPI Objects
 ------------
-The expectations on individual ACPI objects are discussed in the list that
-follows:
+The expectations on individual ACPI objects that are likely to be used are
+shown in the list that follows:
 
 Name   Section         Usage for ARMv8 Linux
 ----   ------------    -------------------------------------------------
+_ACx   11.4.1          Use as needed.
+
 _ADR   6.1.1           Use as needed.
 
+_ALx   11.4.2          Use as needed.
+
+_ART   11.4.3          Use as needed.
+
 _BBN   6.5.5           Use as needed; PCI-specific.
 
-_BDN   6.5.3           Optional; not likely to be used on arm64.
+_CCA   6.2.17          This method must be defined for all bus masters
+                       on arm64 -- there are no assumptions made about
+		       whether such devices are cache coherent or not.
+		       The _CCA value is inherited by all descendants of
+		       these devices so it does not need to be repeated.
+                       Without _CCA on arm64, the kernel does not know what
+		       to do about setting up DMA for the device.
+
+_CDM   6.2.1           Use as needed, to be used only for processor devices.
 
-_CCA   6.2.17          This method should be defined for all bus masters
-                       on arm64.  While cache coherency is assumed, making
-                       it explicit ensures the kernel will set up DMA as
-                       it should.
+_CID   6.1.2           Use as needed, see also _HID.
 
-_CDM   6.2.1           Optional, to be used only for processor devices.
+_CLS   6.1.3           Use as needed, see also _HID.
 
-_CID   6.1.2           Use as needed.
+_CPC   8.4.7.1         Use as needed; power management specific.  CPPC is
+                       recommended on arm64.
 
-_CLS   6.1.3           Use as needed.
+_CR3   11.4.5          Use as needed.
 
 _CRS   6.2.2           Required on arm64.
 
-_DCK   6.5.2           Optional; not likely to be used on arm64.
+_CRT   11.4.4          Use as needed.
+
+_CSD   8.4.2.2         Use as needed, used only in conjuction with _CST.
+
+_CST   8.4.2.1         Low power idle states (8.4.4) are recommended instead
+                       of C-states.
+
+_CWS   9.18.6          Use as needed.
 
 _DDN   6.1.4           This field can be used for a device name.  However,
                        it is meant for DOS device names (e.g., COM1), so be
@@ -305,11 +367,11 @@ _DDN   6.1.4           This field can be used for a device name.  However,
 
 _DEP   6.5.8           Use as needed.
 
-_DIS   6.2.3           Optional, for power management use.
+_DIS   6.2.3           Use as needed, for power management use.
 
-_DLM   5.7.5           Optional.
+_DLM   5.7.5           Use as needed.
 
-_DMA   6.2.4           Optional.
+_DMA   6.2.4           Use as needed.
 
 _DSD   6.2.5           To be used with caution.  If this object is used, try
                        to use it within the constraints already defined by the
@@ -325,19 +387,29 @@ _DSD   6.2.5           To be used with caution.  If this object is used, try
                        with the UEFI Forum; this may cause some iteration as
                        more than one OS will be registering entries.
 
-_DSM                   Do not use this method.  It is not standardized, the
+_DSM   9.1.1           Do not use this method.  It is not standardized, the
                        return values are not well documented, and it is
                        currently a frequent source of error.
 
-_DSW   7.2.1           Use as needed; power management specific.
+_DSW   7.3.1           Use as needed; power management specific.
 
-_EDL   6.3.1           Optional.
+_DTI   11.4.6          Use as needed.
 
-_EJD   6.3.2           Optional.
+_EDL   6.3.1           Use as needed.
 
-_EJx   6.3.3           Optional.
+_EJD   6.3.2           Use as needed.
 
-_FIX   6.2.7           x86 specific, not used on arm64.
+_EJx   6.3.3           Use as needed.
+
+_FIF   11.3.1.1        Use as needed.
+
+_FPS   11.3.1.2        Use as needed.
+
+_FSL   11.3.1.3        Use as needed.
+
+_FST   11.3.1.4        Use as needed.
+
+_GCP   9.18.2          Use as needed.
 
 \_GL   5.7.1           This object is not to be used in hardware reduced
                        mode, and therefore should not be used on arm64.
@@ -349,35 +421,56 @@ _GLK   6.5.7           This object requires a global lock be defined; there
 \_GPE  5.3.1           This namespace is for x86 use only.  Do not use it
                        on arm64.
 
-_GSB   6.2.7           Optional.
+_GRT   9.18.3          Use as needed.
+
+_GSB   6.2.7           Use as needed.
+
+_GTF   9.9.1.1         Use as needed.
+
+_GWS   9.18.5          Use as needed.
 
 _HID   6.1.5           Use as needed.  This is the primary object to use in
                        device probing, though _CID and _CLS may also be used.
 
-_HPP   6.2.8           Optional, PCI specific.
+_HOT   11.4.7          Use as needed.
+
+_HPP   6.2.8           Use as needed, PCI specific.
 
-_HPX   6.2.9           Optional, PCI specific.
+_HPX   6.2.9           Use as needed, PCI specific.
 
-_HRV   6.1.6           Optional, use as needed to clarify device behavior; in
+_HRV   6.1.6           Use as needed, use as needed to clarify device behavior; in
                        some cases, this may be easier to use than _DSD.
 
 _INI   6.5.1           Not required, but can be useful in setting up devices
                        when UEFI leaves them in a state that may not be what
                        the driver expects before it starts probing.
 
-_IRC   7.2.15          Use as needed; power management specific.
+_IRC   7.3.15          Use as needed; power management specific.
+
+_LCK   6.3.4           Use as needed.
+
+_LPI   8.4.4.3         Use as needed, but recommended for use with processor
+                       definitions (_HID ACPI0010) on arm64.
 
-_LCK   6.3.4           Optional.
+_MAT   6.2.10          Use as needed; see also the MADT.
 
-_MAT   6.2.10          Optional; see also the MADT.
+_MBM   9.13.2.1        Use as needed.
 
-_MLS   6.1.7           Optional, but highly recommended for use in
+_MLS   6.1.7           Use as needed, but highly recommended for use in
                        internationalization.
 
-_OFF   7.1.2           It is recommended to define this method for any device
+_MSG   9.2.2           Use as needed.
+
+_MSM   9.13.2.2        Use as needed.
+
+_MTL   11.4.8          Use as needed.
+
+_NTT   11.4.9          Use as needed.
+
+_OFF   7.2.2           It is recommended to define this method for any device
                        that can be turned on or off.
 
-_ON    7.1.3           It is recommended to define this method for any device
+_ON    7.2.3           It is recommended to define this method for any device
                        that can be turned on or off.
 
 \_OS   5.7.3           This method will return "Linux" by default (this is
@@ -405,115 +498,219 @@ _OSC   6.2.11          This method can be a global method in ACPI (i.e.,
                        being used or what functionality is provided.  The
                        _OSC method is to be used instead.
 
-_OST   6.3.5           Optional.
+_OST   6.3.5           Use as needed.
+
+_PCT   8.4.6.1         Use as needed; power management specific.
 
 _PDC   8.4.1           Deprecated, do not use on arm64.
 
+_PDL   8.4.6.2         Use as needed; power management specific.
+
 \_PIC  5.8.1           The method should not be used.  On arm64, the only
                        interrupt model available is GIC.
 
-_PLD   6.1.8           Optional.
+_PLD   6.1.8           Use as needed.
+
+_PPC   8.4.6.3         Use as needed; power management specific.
+
+_PPE   8.4.8           Use as needed.
 
 \_PR   5.3.1           This namespace is for x86 use only on legacy systems.
                        Do not use it on arm64.
 
-_PRS   6.2.12          Optional.
+_PRE   7.3.12          Use as needed; power management specific.
+
+_PRR   7.3.26          Use as needed; power management specific.
+
+_PRS   6.2.12          Use as needed.
 
 _PRT   6.2.13          Required as part of the definition of all PCI root
                        devices.
 
-_PRW   7.2.13          Use as needed; power management specific.
+_PRW   7.3.13          Use as needed; power management specific.
 
-_PRx   7.2.8-11        Use as needed; power management specific.  If _PR0 is
+_PRx   7.3.8-11        Use as needed; power management specific.  If _PR0 is
                        defined, _PR3 must also be defined.
 
-_PSC   7.2.6           Use as needed; power management specific.
+_PSC   7.3.6           Use as needed; power management specific.
+
+_PSD   8.4.6.5         Use as needed; power management specific.
 
-_PSE   7.2.7           Use as needed; power management specific.
+_PSE   7.3.7           Use as needed; power management specific.
 
-_PSW   7.2.14          Use as needed; power management specific.
+_PSL   11.4.10         Use as needed.
 
-_PSx   7.2.2-5         Use as needed; power management specific.  If _PS0 is
+_PSS   8.4.6.2         Use as needed; power management specific.
+
+_PSV   11.4.11         Use as needed.
+
+_PSW   7.3.14          Use as needed; power management specific.
+
+_PSx   7.3.2-5         Use as needed; power management specific.  If _PS0 is
                        defined, _PS3 must also be defined.  If clocks or
                        regulators need adjusting to be consistent with power
                        usage, change them in these methods.
 
-\_PTS  7.3.1           Use as needed; power management specific.
+_PTC   8.4.5.1         Use as needed; power management specific.
+
+\_PTS  7.4.1           Use as needed; power management specific.
+
+_PUR   8.5.1.1         Use as needed.
+
+_PXM   6.2.14          Use as needed.
 
-_PXM   6.2.14          Optional.
+_RDI   8.4.4.4         Use as needed, but recommended for use with processor
+                       definitions (_HID ACPI0010) on arm64.
 
 _REG   6.5.4           Use as needed.
 
 \_REV  5.7.4           Always returns the latest version of ACPI supported.
 
-_RMV   6.3.6           Optional.
+_RMV   6.3.6           Use as needed.
+
+_RST   7.3.25          Use as needed; power management specific.
+
+_RTV   11.4.12         Use as needed.
 
 \_SB   5.3.1           Required on arm64; all devices must be defined in this
                        namespace.
 
+_SCP   11.4.13         Use as needed.
+
+_SDD   9.9.3.3.1       Use as needed.
+
 _SEG   6.5.6           Use as needed; PCI-specific.
 
-\_SI   5.3.1,          Optional.
-       9.1
+\_SI   5.3.1,          Use as needed.
+       9.2
+
+_SLI   6.2.15          Use as needed; recommended when SLIT table is in use.
 
-_SLI   6.2.15          Optional; recommended when SLIT table is in use.
+_SRT   9.18.4          Use as needed.
 
 _STA   6.3.7,          It is recommended to define this method for any device
-       7.1.4           that can be turned on or off.
+       7.2.4           that can be turned on or off.  See also the STAO table
+       		       that provides overrides to hide devices in virtualized
+		       environments.
 
-_SRS   6.2.16          Optional; see also _PRS.
+_SRS   6.2.16          Use as needed; see also _PRS.
+
+_SST   9.2.1           Use as needed.
 
 _STR   6.1.10          Recommended for conveying device names to end users;
                        this is preferred over using _DDN.
 
+_SST   9.2.1           Use as needed.
+
+_STP   9.18.7          Use as needed.
+
+_STV   9.18.8          Use as needed.
+
 _SUB   6.1.9           Use as needed; _HID or _CID are preferred.
 
-_SUN   6.1.11          Optional.
+_SUN   6.1.11          Use as needed, but recommended.
 
-\_Sx   7.3.2           Use as needed; power management specific.
+\_Sx   7.4.2           Use as needed; power management specific.
 
-_SxD   7.2.16-19       Use as needed; power management specific.
+_SxD   7.3.16-19       Use as needed; power management specific.
 
-_SxW   7.2.20-24       Use as needed; power management specific.
+_SxW   7.3.20-24       Use as needed; power management specific.
 
-_SWS   7.3.3           Use as needed; power management specific; this may
+_SWS   7.4.3           Use as needed; power management specific; this may
                        require specification changes for use on arm64.
 
-\_TTS  7.3.4           Use as needed; power management specific.
+_TC1   11.4.14         Use as needed.
+
+_TC2   11.4.15         Use as needed.
+
+_TDL   8.4.5.5         Use as needed; power management specific.
+
+_TFP   11.4.16         Use as needed.
+
+_TIP   9.18.9          Use as needed.
+
+_TIV   9.18.10         Use as needed.
+
+_TMP   11.4.17         Use as needed.
+
+_TPC   8.4.5.3         Use as needed; power management specific.
 
-\_TZ   5.3.1           Optional.
+_TPT   11.4.18         Use as needed.
+
+_TRT   11.4.19         Use as needed.
+
+_TSD   8.4.5.4         Use as needed; power management specific.
+
+_TSN   11.4.20         Use as needed.
+
+_TSP   11.4.21         Use as needed.
+
+_TSS   8.4.5.2         Use as needed; power management specific.
+
+_TST   11.4.22         Use as needed.
+
+\_TTS  7.4.4           Use as needed; power management specific.
+
+\_TZ   5.3.1           Use as needed.
+
+_TZD   11.4.23         Use as needed.
+
+_TZM   11.4.24         Use as needed.
+
+_TZP   11.4.25         Use as needed.
 
 _UID   6.1.12          Recommended for distinguishing devices of the same
                        class; define it if at all possible.
 
-\_WAK  7.3.5           Use as needed; power management specific.
+_UPC   9.14            Use as needed.
+
+\_WAK  7.4.5           Use as needed; power management specific.
+
+
 
 
 ACPI Event Model
 ----------------
 Do not use GPE block devices; these are not supported in the hardware reduced
 profile used by arm64.  Since there are no GPE blocks defined for use on ARM
-platforms, GPIO-signaled interrupts should be used for creating system events.
+platforms, ACPI events must be signaled differently.
+
+There are two options: GPIO-signaled interrupts (Section 5.6.5), and 
+interrupt-signaled events (Section 5.6.9).  Interrupt-signaled events are a
+new feature in the ACPI 6.1 specification.  Either -- or both -- can be used
+on a given platform, and which to use may be dependent of limitations in any
+given SoC.  If possible, interrupt-signaled events are recommended.
 
 
 ACPI Processor Control
 ----------------------
-Section 8 of the ACPI specification is currently undergoing change that
-should be completed in the 6.0 version of the specification.  Processor
-performance control will be handled differently for arm64 at that point
-in time.  Processor aggregator devices (section 8.5) will not be used,
-for example, but another similar mechanism instead.
-
-While UEFI constrains what we can say until the release of 6.0, it is
-recommended that CPPC (8.4.5) be used as the primary model.  This will
-still be useful into the future.  C-states and P-states will still be
-provided, but most of the current design work appears to favor CPPC.
+Section 8 of the ACPI specification changed significantly in version 6.0.
+Processors should now be defined as Device objects with _HID ACPI0007; do
+not use the deprecated Processor statement in ASL.  All multiprocessor systems
+should also define a hierarchy of processors, done with Processor Container
+Devices (see Section 8.4.3.1, _HID ACPI0010); do not use processor aggregator
+devices (Section 8.5) to describe processor topology.  Section 8.4 of the
+specification describes the semantics of these object definitions and how 
+they interrelate.
+
+Most importantly, the processor hierarchy defined also defines the low power
+idle states that are available to the platform, along with the rules for
+determining which processors can be turned on or off and the circumstances
+that control that.  Without this information, the processors will run in
+whatever power state they were left in by UEFI.
+
+Note too, that the processor Device objects defined and the entries in the
+MADT for GICs are expected to be in sychronization.  The _UID of the Device
+object must correspond to processor IDs used in the MADT.
+
+It is recommended that CPPC (8.4.5) be used as the primary model for processor
+performance control on arm64.  C-states and P-states may become available at
+some point in the future, but most current design work appears to favor CPPC.
 
 Further, it is essential that the ARMv8 SoC provide a fully functional
 implementation of PSCI; this will be the only mechanism supported by ACPI
-to control CPU power state (including secondary CPU booting).
-
-More details will be provided on the release of the ACPI 6.0 specification.
+to control CPU power state.  Booting of secondary CPUs may be possible using
+parking protocol, but only PSCI is to be used for ARM servers.
 
 
 ACPI System Address Map Interfaces
@@ -535,21 +732,25 @@ used to indicate fatal errors that cannot be corrected, and require immediate
 attention.
 
 Since there is no direct equivalent of the x86 SCI or NMI, arm64 handles
-these slightly differently.  The SCI is handled as a normal GPIO-signaled
-interrupt; given that these are corrected (or correctable) errors being
-reported, this is sufficient.  The NMI is emulated as the highest priority
-GPIO-signaled interrupt possible.  This implies some caution must be used
-since there could be interrupts at higher privilege levels or even interrupts
-at the same priority as the emulated NMI.  In Linux, this should not be the
-case but one should be aware it could happen.
+these slightly differently.  The SCI is handled as a high priority interrupt;
+given that these are corrected (or correctable) errors being reported, this
+is sufficient.  The NMI is emulated as the highest priority interrupt 
+possible.  This implies some caution must be used since there could be 
+interrupts at higher privilege levels or even interrupts at the same priority
+as the emulated NMI.  In Linux, this should not be the case but one should 
+be aware it could happen.
 
 
 ACPI Objects Not Supported on ARM64
 -----------------------------------
 While this may change in the future, there are several classes of objects
 that can be defined, but are not currently of general interest to ARM servers.
+Some of these objects have x86 equivalents, and may actually make sense in ARM
+servers.  However, there is either no hardware available at present, or there
+may not even be a non-ARM implementation yet.  Hence, they are not currently
+supported.
 
-These are not supported:
+The following classes of objects are not supported:
 
        -- Section 9.2: ambient light sensor devices
 
@@ -571,16 +772,6 @@ These are not supported:
 
        -- Section 9.18: time and alarm devices (see 9.15)
 
-
-ACPI Objects Not Yet Implemented
---------------------------------
-While these objects have x86 equivalents, and they do make some sense in ARM
-servers, there is either no hardware available at present, or in some cases
-there may not yet be a non-ARM implementation.  Hence, they are currently not
-implemented though that may change in the future.
-
-Not yet implemented are:
-
        -- Section 10: power source and power meter devices
 
        -- Section 11: thermal management
@@ -589,5 +780,31 @@ Not yet implemented are:
 
        -- Section 13: SMBus interfaces
 
-       -- Section 17: NUMA support (prototypes have been submitted for
-          review)
+
+This also mean that there is no support for the following objects:
+
+Name   Section                     Name   Section
+----   ------------                ----   ------------
+_ALC   9.3.4                       _FDM   9.10.3
+_ALI   9.3.2                       _FIX   6.2.7
+_ALP   9.3.6                       _GAI   10.4.5
+_ALR   9.3.5                       _GHL   10.4.7
+_ALT   9.3.3                       _GTM   9.9.2.1.1
+_BCT   10.2.2.10                   _LID   9.5.1
+_BDN   6.5.3                       _PAI   10.4.4
+_BIF   10.2.2.1                    _PCL   10.3.2
+_BIX   10.2.2.1                    _PIF   10.3.3
+_BLT   9.2.3                       _PMC   10.4.1
+_BMA   10.2.2.4                    _PMD   10.4.8
+_BMC   10.2.2.12                   _PMM   10.4.3
+_BMD   10.2.2.11                   _PRL   10.3.4
+_BMS   10.2.2.5                    _PSR   10.3.1
+_BST   10.2.2.6                    _PTP   10.4.2
+_BTH   10.2.2.7                    _SBS   10.1.3
+_BTM   10.2.2.9                    _SHL   10.4.6
+_BTP   10.2.2.8                    _STM   9.9.2.1.1
+_DCK   6.5.2                       _UPD   9.16.1
+_EC    12.12                       _UPP   9.16.2
+_FDE   9.10.1                      _WPC   10.5.2
+_FDI   9.10.2                      _WPP   10.5.3
+
diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
index 570a4f8..12381c1 100644
--- a/Documentation/arm64/arm-acpi.txt
+++ b/Documentation/arm64/arm-acpi.txt
@@ -57,11 +57,11 @@ The short form of the rationale for ACPI on ARM is:
 
 -- The new ACPI governance process works well and Linux is now at the same
    table as hardware vendors and other OS vendors.  In fact, there is no
-   longer any reason to feel that ACPI is only belongs to Windows or that
+   longer any reason to feel that ACPI only belongs to Windows or that
    Linux is in any way secondary to Microsoft in this arena.  The move of
    ACPI governance into the UEFI forum has significantly opened up the
    specification development process, and currently, a large portion of the
-   changes being made to ACPI is being driven by Linux.
+   changes being made to ACPI are being driven by Linux.
 
 Key to the use of ACPI is the support model.  For servers in general, the
 responsibility for hardware behaviour cannot solely be the domain of the
@@ -159,7 +159,7 @@ Further, the ACPI core will only use the 64-bit address fields in the FADT
 (Fixed ACPI Description Table).  Any 32-bit address fields in the FADT will
 be ignored on arm64.
 
-Hardware reduced mode (see Section 4.1 of the ACPI 5.1 specification) will
+Hardware reduced mode (see Section 4.1 of the ACPI 6.1 specification) will
 be enforced by the ACPI core on arm64.  Doing so allows the ACPI core to
 run less complex code since it no longer has to provide support for legacy
 hardware from other architectures.  Any fields that are not to be used for
@@ -167,7 +167,7 @@ hardware reduced mode must be set to zero.
 
 For the ACPI core to operate properly, and in turn provide the information
 the kernel needs to configure devices, it expects to find the following
-tables (all section numbers refer to the ACPI 5.1 specfication):
+tables (all section numbers refer to the ACPI 6.1 specfication):
 
     -- RSDP (Root System Description Pointer), section 5.2.5
 
@@ -185,9 +185,22 @@ tables (all section numbers refer to the ACPI 5.1 specfication):
     -- If PCI is supported, the MCFG (Memory mapped ConFiGuration
        Table), section 5.2.6, specifically Table 5-31.
 
+    -- If booting without a console=<device> kernel parameter is
+       supported, the SPCR (Serial Port Console Redirection table),
+       section 5.2.6, specifically Table 5-31.
+
+    -- If virtualization is supported, the IORT (Input Output Remapping
+       Table, section 5.2.6, specifically Table 5-31.
+
+    -- If NUMA is supported, the SRAT (System Resource Affinity Table)
+       and SLIT (System Locality distance Information Table), sections
+       5.2.16 and 5.2.17, respectively.
+
 If the above tables are not all present, the kernel may or may not be
 able to boot properly since it may not be able to configure all of the
-devices available.
+devices available.  This list of tables is not meant to be all inclusive;
+in some environments other tables may be needed (e.g., any of the APEI
+tables from section 18) to support specific functionality.
 
 
 ACPI Detection
@@ -233,7 +246,7 @@ that looks like this: Name(KEY0, "value0").  An ACPI device driver would
 then retrieve the value of the property by evaluating the KEY0 object.
 However, using Name() this way has multiple problems: (1) ACPI limits
 names ("KEY0") to four characters unlike DT; (2) there is no industry
-wide registry that maintains a list of names, minimzing re-use; (3)
+wide registry that maintains a list of names, minimizing re-use; (3)
 there is also no registry for the definition of property values ("value0"),
 again making re-use difficult; and (4) how does one maintain backward
 compatibility as new hardware comes out?  The _DSD method was created
@@ -434,7 +447,8 @@ The ACPI specification changes regularly.  During the year 2014, for instance,
 version 5.1 was released and version 6.0 substantially completed, with most of
 the changes being driven by ARM-specific requirements.  Proposed changes are
 presented and discussed in the ASWG (ACPI Specification Working Group) which
-is a part of the UEFI Forum.
+is a part of the UEFI Forum.  The current version of the ACPI specification
+is 6.1 release in January 2016.
 
 Participation in this group is open to all UEFI members.  Please see
 http://www.uefi.org/workinggroup for details on group membership.
-- 
2.5.0



From yang.shi at linaro.org  Fri Feb 19 16:07:02 2016
From: yang.shi at linaro.org (Shi, Yang)
Date: Fri, 19 Feb 2016 16:07:02 -0800
Subject: [PATCH] arm64: remove redundant preempt.h
In-Reply-To: <1455299803-317-1-git-send-email-yang.shi@linaro.org>
References: <1455299803-317-1-git-send-email-yang.shi@linaro.org>
Message-ID: <56C7AE26.1060407@linaro.org>

Hi Will & Catalin,

Any comment on this one?

Thanks,
Yang

On 2/12/2016 9:56 AM, Yang Shi wrote:
> preempt.h has been included by sched.h, so it is not necessary to include
> both, just keep sched.h.
>
> Signed-off-by: Yang Shi <yang.shi at linaro.org>
> ---
> Happened to find this when checking preempt.h include for another patch review.
> Build test is passed with and without CONFIG_PREEMPT enabled.
>
>   arch/arm64/kernel/cpuinfo.c | 1 -
>   1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> index 212ae63..e2b37ff 100644
> --- a/arch/arm64/kernel/cpuinfo.c
> +++ b/arch/arm64/kernel/cpuinfo.c
> @@ -25,7 +25,6 @@
>   #include <linux/init.h>
>   #include <linux/kernel.h>
>   #include <linux/personality.h>
> -#include <linux/preempt.h>
>   #include <linux/printk.h>
>   #include <linux/seq_file.h>
>   #include <linux/sched.h>
>



From nm at ti.com  Fri Feb 19 16:09:51 2016
From: nm at ti.com (Nishanth Menon)
Date: Fri, 19 Feb 2016 18:09:51 -0600
Subject: [PATCH] hwmon: (gpio-fan) Remove un-necessary speed_index lookup for
 thermal hook
Message-ID: <1455926991-15189-1-git-send-email-nm@ti.com>

Thermal hook gpio_fan_get_cur_state is only interested in knowing
the current speed index that was setup in the system, this is
already available as part of fan_data->speed_index which is always
set by set_fan_speed. Using get_fan_speed_index is useful when we
have no idea about the fan speed configuration (for example during
fan_ctrl_init).

When thermal framework invokes
gpio_fan_get_cur_state=>get_fan_speed_index via gpio_fan_get_cur_state
especially in a polled configuration for thermal governor, we
basically hog the i2c interface to the extent that other functions
fail to get any traffic out :(.

Instead, just provide the last state set in the driver - since the gpio
fan driver is responsible for the fan state immaterial of override, the
fan_data->speed_index should accurately reflect the state.

Fixes: b5cf88e46bad ("(gpio-fan): Add thermal control hooks")

Reported-by: Tony Lindgren <tony at atomide.com>
Cc: Guenter Roeck <linux at roeck-us.net>
Cc: Eduardo Valentin <edubezval at gmail.com>
Signed-off-by: Nishanth Menon <nm at ti.com>
---
Test logs from linus master  v4.5-rc4-137-g23300f657594 
Without fix: http://paste.ubuntu.org.cn/3948618
With Fix: http://paste.ubuntu.org.cn/3948617

 drivers/hwmon/gpio-fan.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/hwmon/gpio-fan.c b/drivers/hwmon/gpio-fan.c
index 82de3deeb18a..685568b1236d 100644
--- a/drivers/hwmon/gpio-fan.c
+++ b/drivers/hwmon/gpio-fan.c
@@ -406,16 +406,11 @@ static int gpio_fan_get_cur_state(struct thermal_cooling_device *cdev,
 				  unsigned long *state)
 {
 	struct gpio_fan_data *fan_data = cdev->devdata;
-	int r;
 
 	if (!fan_data)
 		return -EINVAL;
 
-	r = get_fan_speed_index(fan_data);
-	if (r < 0)
-		return r;
-
-	*state = r;
+	*state = fan_data->speed_index;
 	return 0;
 }
 
-- 
2.7.0



From ddaney.cavm at gmail.com  Fri Feb 19 17:13:09 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri, 19 Feb 2016 17:13:09 -0800
Subject: [PATCH v11 00/10] arm64, numa: Add numa support for arm64 platforms
Message-ID: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>

From: David Daney <david.daney at cavium.com>

v11:
	- Dropped cleanup patches for other architectures, they will be
          submitted as a separate set after more testing.

	- Added patch set from Ard Biesheuvel that are needed to make
          the whole thing actually work.  Previously this was a
          separate set.

	- Kconfig and other fixes and simplifications as suggested by Rob Herring.

	- Rearranged, refactored and reordered so that we don't patch
          new files multiple times.

	- Summary:

		o 6 patches from Ard Biesheuvel to allow use of
		  "memory" nodes with efi stub.

		o 2 patches to document and add of_numa.c

		o 1 patch to add arm64 NUMA support.

		o 1 patch to add NUMA balancing support for arm64.

v10:
	- Incorporated review comments from Rob Herring.
	- Moved numa binding and implementation to devicetree core.
	- Added cleanup patch to remove redundant NODE_DATA macro from asm header files
	- Include numa balancing support for arm64 patch in this series.
	- Fix tile build issue reported by the kbuild robot(patch 7)

v9:	- Added cleanup patch to reuse and avoid redefinition of cpumask_of_pcibus
	  as suggested from Will Deacon and Bjorn Helgaas.
	  - Including patch to Make pci-host-generic driver numa aware.
	  - Incorporated comment from Shannon Zhao.

v8:
	- Incorporated review comments of Mark Rutland and Will Deacon.
	- Added pci helper function and macro for numa.

v7:
	- managing numa memory mapping using memblock.
	- Incorporated review comments of Mark Rutland.

v6:
	- defined and implemented the numa dt binding using
	node property proximity and device node distance-map.
	- renamed dt_numa to of_numa

v5:
        - created base verion of numa.c which creates dummy numa without using dt
          on single socket platforms. Then added patches for dt support.
        - Incorporated review comments from Hanjun Guo.

v4:
done changes as per Arnd review comments.

v3:
Added changes to support numa on arm64 based platforms.
Tested these patches on cavium's multinode(2 node topology) platform.
In this patchset, defined and implemented dt bindings for numa mapping
for core and memory using device node property arm,associativity.

v2:
Defined and implemented numa map for memory, cores to node and
proximity distance matrix of nodes.

v1:
Initial patchset to support numa on arm64 platforms.

Note: 1. This patchset is tested for NUMA and without NUMA with dt
        (both with and without NUMA bindings) on thunderx single
        socket and dual socket boards.


Ard Biesheuvel (6):
  of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
  arm64: override generic version of early_init_dt_add_memory_arch()
  efi: move FDT handling to separate object file
  arm64/efi: move EFI /chosen node parsing before early FDT processing
  arm64/efi: ignore DT memory nodes instead of removing them
  arm64/efi: ignore DT memreserve entries instead of removing them

Ganapatrao Kulkarni (4):
  Documentation, dt, numa: dt bindings for NUMA.
  dt, numa: Add NUMA dt binding implementation.
  arm64, numa: Add NUMA support for arm64 platforms.
  arm64, mm, numa: Add NUMA balancing support for arm64.

 Documentation/devicetree/bindings/numa.txt | 272 +++++++++++++++++++
 arch/arm64/Kconfig                         |  27 ++
 arch/arm64/include/asm/efi.h               |   2 +
 arch/arm64/include/asm/mmzone.h            |  12 +
 arch/arm64/include/asm/numa.h              |  45 ++++
 arch/arm64/include/asm/pgtable.h           |  15 ++
 arch/arm64/include/asm/topology.h          |  10 +
 arch/arm64/kernel/pci.c                    |  10 +
 arch/arm64/kernel/setup.c                  |   7 +
 arch/arm64/kernel/smp.c                    |   4 +
 arch/arm64/mm/Makefile                     |   1 +
 arch/arm64/mm/init.c                       |  46 +++-
 arch/arm64/mm/mmu.c                        |   1 +
 arch/arm64/mm/numa.c                       | 403 +++++++++++++++++++++++++++++
 drivers/firmware/efi/Makefile              |   1 +
 drivers/firmware/efi/arm-init.c            |  36 ++-
 drivers/firmware/efi/efi-fdt.c             |  73 ++++++
 drivers/firmware/efi/efi.c                 |  84 ------
 drivers/firmware/efi/libstub/fdt.c         |  33 +--
 drivers/of/Kconfig                         |   3 +
 drivers/of/Makefile                        |   1 +
 drivers/of/fdt.c                           |   7 +-
 drivers/of/of_numa.c                       | 211 +++++++++++++++
 include/linux/efi.h                        |   2 +-
 include/linux/of.h                         |   9 +
 include/linux/of_fdt.h                     |   1 +
 26 files changed, 1178 insertions(+), 138 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/numa.txt
 create mode 100644 arch/arm64/include/asm/mmzone.h
 create mode 100644 arch/arm64/include/asm/numa.h
 create mode 100644 arch/arm64/mm/numa.c
 create mode 100644 drivers/firmware/efi/efi-fdt.c
 create mode 100644 drivers/of/of_numa.c

-- 
1.8.3.1



From ddaney.cavm at gmail.com  Fri Feb 19 17:13:10 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri, 19 Feb 2016 17:13:10 -0800
Subject: [PATCH v11 01/10] of/fdt: make generic
 early_init_dt_add_memory_arch() a weak alias
In-Reply-To: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1455930799-5371-2-git-send-email-ddaney.cavm@gmail.com>

From: Ard Biesheuvel <ard.biesheuvel at linaro.org>

The function early_init_dt_add_memory_arch() is defined as __weak
so that archs can override it. However, in this override implementation,
it may still be useful to invoke the generic implementation, so instead,
rename the generic version to early_init_dt_add_memory() and turn the
original definition into a weak alias. This way, the generic version can
still be called even in the presence of an arch specific override.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Signed-off-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 drivers/of/fdt.c       | 7 +++++--
 include/linux/of_fdt.h | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79d..cba8281 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -980,7 +980,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
 #define MAX_MEMBLOCK_ADDR	((phys_addr_t)~0)
 #endif
 
-void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
+void __init early_init_dt_add_memory(u64 base, u64 size)
 {
 	const u64 phys_offset = __pa(PAGE_OFFSET);
 
@@ -1038,7 +1038,7 @@ void * __init __weak early_init_dt_alloc_memory_arch(u64 size, u64 align)
 	return __va(memblock_alloc(size, align));
 }
 #else
-void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
+void __init early_init_dt_add_memory(u64 base, u64 size)
 {
 	WARN_ON(1);
 }
@@ -1058,6 +1058,9 @@ void * __init __weak early_init_dt_alloc_memory_arch(u64 size, u64 align)
 }
 #endif
 
+__weak __alias(early_init_dt_add_memory)
+void early_init_dt_add_memory_arch(u64 base, u64 size);
+
 bool __init early_init_dt_verify(void *params)
 {
 	if (!params)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef38..463a06b 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -65,6 +65,7 @@ extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
 				     int depth, void *data);
 extern void early_init_fdt_scan_reserved_mem(void);
 extern void early_init_fdt_reserve_self(void);
+extern void early_init_dt_add_memory(u64 base, u64 size);
 extern void early_init_dt_add_memory_arch(u64 base, u64 size);
 extern int early_init_dt_reserve_memory_arch(phys_addr_t base, phys_addr_t size,
 					     bool no_map);
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Fri Feb 19 17:13:12 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri, 19 Feb 2016 17:13:12 -0800
Subject: [PATCH v11 03/10] efi: move FDT handling to separate object file
In-Reply-To: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1455930799-5371-4-git-send-email-ddaney.cavm@gmail.com>

From: Ard Biesheuvel <ard.biesheuvel at linaro.org>

The EFI specific FDT handling is compiled conditionally, and is
logically independent of the rest of efi.o. So move it to a separate
file before making changes to it in subsequent patches.

Acked-by: Matt Fleming <matt.fleming at intel.com>
Acked-by: Leif Lindholm <leif.lindholm at linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
[ rric: Ported to v4.5-rc1 ]
Signed-off-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 drivers/firmware/efi/Makefile  |  1 +
 drivers/firmware/efi/efi-fdt.c | 91 ++++++++++++++++++++++++++++++++++++++++++
 drivers/firmware/efi/efi.c     | 84 --------------------------------------
 3 files changed, 92 insertions(+), 84 deletions(-)
 create mode 100644 drivers/firmware/efi/efi-fdt.c

diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 62e654f..bb7ec2f 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_EFI_RUNTIME_MAP)		+= runtime-map.o
 obj-$(CONFIG_EFI_RUNTIME_WRAPPERS)	+= runtime-wrappers.o
 obj-$(CONFIG_EFI_STUB)			+= libstub/
 obj-$(CONFIG_EFI_FAKE_MEMMAP)		+= fake_mem.o
+obj-$(CONFIG_EFI_PARAMS_FROM_FDT)	+= efi-fdt.o
 
 arm-obj-$(CONFIG_EFI)			:= arm-init.o arm-runtime.o
 obj-$(CONFIG_ARM)			+= $(arm-obj-y)
diff --git a/drivers/firmware/efi/efi-fdt.c b/drivers/firmware/efi/efi-fdt.c
new file mode 100644
index 0000000..8f3ce66
--- /dev/null
+++ b/drivers/firmware/efi/efi-fdt.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright (C) 2013 - 2015 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/efi.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+
+#define UEFI_PARAM(name, prop, field)			   \
+	{						   \
+		{ name },				   \
+		{ prop },				   \
+		offsetof(struct efi_fdt_params, field),    \
+		FIELD_SIZEOF(struct efi_fdt_params, field) \
+	}
+
+static __initdata struct {
+	const char name[32];
+	const char propname[32];
+	int offset;
+	int size;
+} dt_params[] = {
+	UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
+	UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
+	UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
+	UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
+	UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
+};
+
+struct param_info {
+	int found;
+	void *params;
+};
+
+static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
+				       int depth, void *data)
+{
+	struct param_info *info = data;
+	const void *prop;
+	void *dest;
+	u64 val;
+	int i, len;
+
+	if (depth != 1 || strcmp(uname, "chosen") != 0)
+		return 0;
+
+	for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+		prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
+		if (!prop)
+			return 0;
+		dest = info->params + dt_params[i].offset;
+		info->found++;
+
+		val = of_read_number(prop, len / sizeof(u32));
+
+		if (dt_params[i].size == sizeof(u32))
+			*(u32 *)dest = val;
+		else
+			*(u64 *)dest = val;
+
+		if (efi_enabled(EFI_DBG))
+			pr_info("  %s: 0x%0*llx\n", dt_params[i].name,
+				dt_params[i].size * 2, val);
+	}
+	return 1;
+}
+
+int __init efi_get_fdt_params(struct efi_fdt_params *params)
+{
+	struct param_info info;
+	int ret;
+
+	pr_info("Getting EFI parameters from FDT:\n");
+
+	info.found = 0;
+	info.params = params;
+
+	ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
+	if (!info.found)
+		pr_info("UEFI not found.\n");
+	else if (!ret)
+		pr_err("Can't find '%s' in device tree!\n",
+		       dt_params[info.found].name);
+
+	return ret;
+}
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2cd37da..7c41c428 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -20,8 +20,6 @@
 #include <linux/init.h>
 #include <linux/device.h>
 #include <linux/efi.h>
-#include <linux/of.h>
-#include <linux/of_fdt.h>
 #include <linux/io.h>
 #include <linux/platform_device.h>
 
@@ -490,88 +488,6 @@ static int __init efi_load_efivars(void)
 device_initcall(efi_load_efivars);
 #endif
 
-#ifdef CONFIG_EFI_PARAMS_FROM_FDT
-
-#define UEFI_PARAM(name, prop, field)			   \
-	{						   \
-		{ name },				   \
-		{ prop },				   \
-		offsetof(struct efi_fdt_params, field),    \
-		FIELD_SIZEOF(struct efi_fdt_params, field) \
-	}
-
-static __initdata struct {
-	const char name[32];
-	const char propname[32];
-	int offset;
-	int size;
-} dt_params[] = {
-	UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
-	UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
-	UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
-	UEFI_PARAM("MemMap Desc. Size", "linux,uefi-mmap-desc-size", desc_size),
-	UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
-};
-
-struct param_info {
-	int found;
-	void *params;
-};
-
-static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
-				       int depth, void *data)
-{
-	struct param_info *info = data;
-	const void *prop;
-	void *dest;
-	u64 val;
-	int i, len;
-
-	if (depth != 1 || strcmp(uname, "chosen") != 0)
-		return 0;
-
-	for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
-		prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
-		if (!prop)
-			return 0;
-		dest = info->params + dt_params[i].offset;
-		info->found++;
-
-		val = of_read_number(prop, len / sizeof(u32));
-
-		if (dt_params[i].size == sizeof(u32))
-			*(u32 *)dest = val;
-		else
-			*(u64 *)dest = val;
-
-		if (efi_enabled(EFI_DBG))
-			pr_info("  %s: 0x%0*llx\n", dt_params[i].name,
-				dt_params[i].size * 2, val);
-	}
-	return 1;
-}
-
-int __init efi_get_fdt_params(struct efi_fdt_params *params)
-{
-	struct param_info info;
-	int ret;
-
-	pr_info("Getting EFI parameters from FDT:\n");
-
-	info.found = 0;
-	info.params = params;
-
-	ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
-	if (!info.found)
-		pr_info("UEFI not found.\n");
-	else if (!ret)
-		pr_err("Can't find '%s' in device tree!\n",
-		       dt_params[info.found].name);
-
-	return ret;
-}
-#endif /* CONFIG_EFI_PARAMS_FROM_FDT */
-
 static __initdata char memory_type_name[][20] = {
 	"Reserved",
 	"Loader Code",
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Fri Feb 19 17:13:13 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri, 19 Feb 2016 17:13:13 -0800
Subject: [PATCH v11 04/10] arm64/efi: move EFI /chosen node parsing before
 early FDT processing
In-Reply-To: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1455930799-5371-5-git-send-email-ddaney.cavm@gmail.com>

From: Ard Biesheuvel <ard.biesheuvel at linaro.org>

The early FDT processing is responsible for enumerating the
DT memory nodes and installing them as memblocks. This should
only be done if we are not booting via EFI, but at this point,
we don't know yet if that is the case or not.

So move part of the EFI init to before the early FDT processing. This
involves making some changes to the way EFI discovers the locations of
the EFI system table and the memory map, since those values are retrieved
from the FDT as well. Instead the of_scan infrastructure, it now uses
libfdt directly to access the /chosen node.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
[ rric: Ported to v4.5-rc1 ]
Signed-off-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 arch/arm64/include/asm/efi.h    |  2 ++
 arch/arm64/kernel/setup.c       |  3 ++
 drivers/firmware/efi/arm-init.c | 34 ++++++++++++-------
 drivers/firmware/efi/efi-fdt.c  | 72 ++++++++++++++++-------------------------
 include/linux/efi.h             |  2 +-
 5 files changed, 55 insertions(+), 58 deletions(-)

diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index 8e88a69..acc7f65 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -8,8 +8,10 @@
 
 #ifdef CONFIG_EFI
 extern void efi_init(void);
+extern void efi_parse_fdt(void *fdt);
 #else
 #define efi_init()
+#define efi_parse_fdt(x)
 #endif
 
 int efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md);
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479..3f57233 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -181,6 +181,9 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
 {
 	void *dt_virt = fixmap_remap_fdt(dt_phys);
 
+	if (dt_virt)
+		efi_parse_fdt(dt_virt);
+
 	if (!dt_virt || !early_init_dt_scan(dt_virt)) {
 		pr_crit("\n"
 			"Error: invalid device tree blob at physical address %pa (virtual address 0x%p)\n"
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9e15d57..9fe0464 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -170,22 +170,35 @@ static __init void reserve_regions(void)
 		if (efi_enabled(EFI_DBG))
 			pr_cont("\n");
 	}
-
-	set_bit(EFI_MEMMAP, &efi.flags);
 }
 
-void __init efi_init(void)
+void __init efi_parse_fdt(void *fdt)
 {
 	struct efi_fdt_params params;
 
 	/* Grab UEFI information placed in FDT by stub */
-	if (!efi_get_fdt_params(&params))
+	if (!efi_get_fdt_params(fdt, &params))
 		return;
 
 	efi_system_table = params.system_table;
 
 	memmap.phys_map = params.mmap;
-	memmap.map = early_memremap(params.mmap, params.mmap_size);
+	memmap.desc_size = params.desc_size;
+	memmap.desc_version = params.desc_ver;
+	memmap.nr_map = params.mmap_size / params.desc_size;
+
+	set_bit(EFI_MEMMAP, &efi.flags);
+}
+
+void __init efi_init(void)
+{
+	int mmap_size = memmap.nr_map * memmap.desc_size;
+	u64 phys_map  = memmap.phys_map;
+
+	if (!efi_enabled(EFI_MEMMAP))
+		return;
+
+	memmap.map = early_memremap(phys_map, mmap_size);
 	if (memmap.map == NULL) {
 		/*
 		* If we are booting via UEFI, the UEFI memory map is the only
@@ -194,16 +207,13 @@ void __init efi_init(void)
 		*/
 		panic("Unable to map EFI memory map.\n");
 	}
-	memmap.map_end = memmap.map + params.mmap_size;
-	memmap.desc_size = params.desc_size;
-	memmap.desc_version = params.desc_ver;
+	memmap.map_end = memmap.map + mmap_size;
 
 	if (uefi_init() < 0)
 		return;
 
 	reserve_regions();
-	early_memunmap(memmap.map, params.mmap_size);
-	memblock_mark_nomap(params.mmap & PAGE_MASK,
-			    PAGE_ALIGN(params.mmap_size +
-				       (params.mmap & ~PAGE_MASK)));
+	early_memunmap(memmap.map, mmap_size);
+	memblock_mark_nomap(phys_map & PAGE_MASK,
+			    PAGE_ALIGN(mmap_size + (phys_map & ~PAGE_MASK)));
 }
diff --git a/drivers/firmware/efi/efi-fdt.c b/drivers/firmware/efi/efi-fdt.c
index 8f3ce66..e6622d3 100644
--- a/drivers/firmware/efi/efi-fdt.c
+++ b/drivers/firmware/efi/efi-fdt.c
@@ -8,8 +8,7 @@
 
 #include <linux/init.h>
 #include <linux/efi.h>
-#include <linux/of.h>
-#include <linux/of_fdt.h>
+#include <linux/libfdt.h>
 
 #define UEFI_PARAM(name, prop, field)			   \
 	{						   \
@@ -32,60 +31,43 @@ static __initdata struct {
 	UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
 };
 
-struct param_info {
-	int found;
-	void *params;
-};
-
-static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
-				       int depth, void *data)
+int __init efi_get_fdt_params(void *fdt, struct efi_fdt_params *params)
 {
-	struct param_info *info = data;
 	const void *prop;
-	void *dest;
-	u64 val;
-	int i, len;
+	int node, i;
+
+	pr_info("Getting EFI parameters from FDT:\n");
 
-	if (depth != 1 || strcmp(uname, "chosen") != 0)
-		return 0;
+	node = fdt_path_offset(fdt, "/chosen");
+	if (node < 0) {
+		pr_err("/chosen node not found!\n");
+		return false;
+	}
 
 	for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
-		prop = of_get_flat_dt_prop(node, dt_params[i].propname, &len);
-		if (!prop)
-			return 0;
-		dest = info->params + dt_params[i].offset;
-		info->found++;
+		void *dest;
+		int len;
+		u64 val;
 
-		val = of_read_number(prop, len / sizeof(u32));
+		prop = fdt_getprop(fdt, node, dt_params[i].propname, &len);
+		if (!prop || len != dt_params[i].size)
+			goto not_found;
+		dest = (void *)params + dt_params[i].offset;
 
 		if (dt_params[i].size == sizeof(u32))
-			*(u32 *)dest = val;
+			val = *(u32 *)dest = be32_to_cpup(prop);
 		else
-			*(u64 *)dest = val;
+			val = *(u64 *)dest = be64_to_cpup(prop);
 
-		if (efi_enabled(EFI_DBG))
-			pr_info("  %s: 0x%0*llx\n", dt_params[i].name,
-				dt_params[i].size * 2, val);
+		pr_info("  %s: 0x%0*llx\n", dt_params[i].name,
+			dt_params[i].size * 2, val);
 	}
-	return 1;
-}
+	return true;
 
-int __init efi_get_fdt_params(struct efi_fdt_params *params)
-{
-	struct param_info info;
-	int ret;
-
-	pr_info("Getting EFI parameters from FDT:\n");
-
-	info.found = 0;
-	info.params = params;
-
-	ret = of_scan_flat_dt(fdt_find_uefi_params, &info);
-	if (!info.found)
+not_found:
+	if (i == 0)
 		pr_info("UEFI not found.\n");
-	else if (!ret)
-		pr_err("Can't find '%s' in device tree!\n",
-		       dt_params[info.found].name);
-
-	return ret;
+	else
+		pr_err("Can't find '%s' in device tree!\n", dt_params[i].name);
+	return false;
 }
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 569b5a8..ede2c21 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -915,7 +915,7 @@ extern void efi_initialize_iomem_resources(struct resource *code_resource,
 		struct resource *data_resource, struct resource *bss_resource);
 extern void efi_get_time(struct timespec *now);
 extern void efi_reserve_boot_services(void);
-extern int efi_get_fdt_params(struct efi_fdt_params *params);
+extern int efi_get_fdt_params(void *fdt, struct efi_fdt_params *params);
 extern struct efi_memory_map memmap;
 extern struct kobject *efi_kobj;
 
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Fri Feb 19 17:13:14 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri, 19 Feb 2016 17:13:14 -0800
Subject: [PATCH v11 05/10] arm64/efi: ignore DT memory nodes instead of
 removing them
In-Reply-To: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1455930799-5371-6-git-send-email-ddaney.cavm@gmail.com>

From: Ard Biesheuvel <ard.biesheuvel at linaro.org>

There are two problems with the UEFI stub DT memory node removal
routine:
- it deletes nodes as it traverses the tree, which happens to work
  but is not supported, as deletion invalidates the node iterator;
- deleting memory nodes entirely may discard annotations in the form
  of additional properties on the nodes.

Now that the UEFI initialization has moved to an earlier stage, we can
actually just ignore any memblocks that are installed after we have
processed the UEFI memory map. This way, it is no longer necessary to
remove the nodes, so we can remove that logic from the stub as well.

Acked-by: Leif Lindholm <leif.lindholm at linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
[ rric: Ported to v4.5-rc1 ]
Signed-off-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 arch/arm64/mm/init.c               |  6 +++++-
 drivers/firmware/efi/arm-init.c    |  2 +-
 drivers/firmware/efi/libstub/fdt.c | 24 +-----------------------
 3 files changed, 7 insertions(+), 25 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 208c1d3..eda226e 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -383,5 +383,9 @@ __setup("keepinitrd", keepinitrd_setup);
 
 void __init early_init_dt_add_memory_arch(u64 base, u64 size)
 {
-	early_init_dt_add_memory(base, size);
+	/*
+	 * Ignore DT memory nodes if we are booting via UEFI.
+	 */
+	if (!efi_enabled(EFI_MEMMAP))
+		early_init_dt_add_memory(base, size);
 }
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9fe0464..ded8957 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -159,7 +159,7 @@ static __init void reserve_regions(void)
 		size = npages << PAGE_SHIFT;
 
 		if (is_normal_ram(md))
-			early_init_dt_add_memory_arch(paddr, size);
+			early_init_dt_add_memory(paddr, size);
 
 		if (is_reserve_region(md)) {
 			memblock_mark_nomap(paddr, size);
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index cf7b7d4..9df1560 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -24,7 +24,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
 			unsigned long map_size, unsigned long desc_size,
 			u32 desc_ver)
 {
-	int node, prev, num_rsv;
+	int node, num_rsv;
 	int status;
 	u32 fdt_val32;
 	u64 fdt_val64;
@@ -54,28 +54,6 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
 		goto fdt_set_fail;
 
 	/*
-	 * Delete any memory nodes present. We must delete nodes which
-	 * early_init_dt_scan_memory may try to use.
-	 */
-	prev = 0;
-	for (;;) {
-		const char *type;
-		int len;
-
-		node = fdt_next_node(fdt, prev, NULL);
-		if (node < 0)
-			break;
-
-		type = fdt_getprop(fdt, node, "device_type", &len);
-		if (type && strncmp(type, "memory", len) == 0) {
-			fdt_del_node(fdt, node);
-			continue;
-		}
-
-		prev = node;
-	}
-
-	/*
 	 * Delete all memory reserve map entries. When booting via UEFI,
 	 * kernel will use the UEFI memory map to find reserved regions.
 	 */
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Fri Feb 19 17:13:11 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri, 19 Feb 2016 17:13:11 -0800
Subject: [PATCH v11 02/10] arm64: override generic version of
 early_init_dt_add_memory_arch()
In-Reply-To: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1455930799-5371-3-git-send-email-ddaney.cavm@gmail.com>

From: Ard Biesheuvel <ard.biesheuvel at linaro.org>

Override the __weak early_init_dt_add_memory_arch() with our own
version. We need this in a subsequent patch to make the handling of
the memory nodes conditional on whether we are booting via UEFI or
not. Note that for now, all that our version does is invoke the generic
implementation.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Signed-off-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 arch/arm64/mm/init.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3b061e..208c1d3 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -380,3 +380,8 @@ static int __init keepinitrd_setup(char *__unused)
 
 __setup("keepinitrd", keepinitrd_setup);
 #endif
+
+void __init early_init_dt_add_memory_arch(u64 base, u64 size)
+{
+	early_init_dt_add_memory(base, size);
+}
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Fri Feb 19 17:13:19 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri, 19 Feb 2016 17:13:19 -0800
Subject: [PATCH v11 10/10] arm64, mm,
 numa: Add NUMA balancing support for arm64.
In-Reply-To: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1455930799-5371-11-git-send-email-ddaney.cavm@gmail.com>

From: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>

Enable NUMA balancing for arm64 platforms.
Add pte, pmd protnone helpers for use by automatic NUMA balancing.

Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 arch/arm64/Kconfig               |  1 +
 arch/arm64/include/asm/pgtable.h | 15 +++++++++++++++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9f0972a..6e22503 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -11,6 +11,7 @@ config ARM64
 	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
 	select ARCH_USE_CMPXCHG_LOCKREF
 	select ARCH_SUPPORTS_ATOMIC_RMW
+	select ARCH_SUPPORTS_NUMA_BALANCING
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
 	select ARCH_WANT_FRAME_POINTERS
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index bf464de..5af9db2 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -346,6 +346,21 @@ static inline pgprot_t mk_sect_prot(pgprot_t prot)
 	return __pgprot(pgprot_val(prot) & ~PTE_TABLE_BIT);
 }
 
+#ifdef CONFIG_NUMA_BALANCING
+/*
+ * See the comment in include/asm-generic/pgtable.h
+ */
+static inline int pte_protnone(pte_t pte)
+{
+	return (pte_val(pte) & (PTE_VALID | PTE_PROT_NONE)) == PTE_PROT_NONE;
+}
+
+static inline int pmd_protnone(pmd_t pmd)
+{
+	return pte_protnone(pmd_pte(pmd));
+}
+#endif
+
 /*
  * THP definitions.
  */
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Fri Feb 19 17:13:16 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri, 19 Feb 2016 17:13:16 -0800
Subject: [PATCH v11 07/10] Documentation, dt, numa: dt bindings for NUMA.
In-Reply-To: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1455930799-5371-8-git-send-email-ddaney.cavm@gmail.com>

From: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>

Add DT bindings for numa mapping of memory, CPUs and IOs.

Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 Documentation/devicetree/bindings/numa.txt | 272 +++++++++++++++++++++++++++++
 1 file changed, 272 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/numa.txt

diff --git a/Documentation/devicetree/bindings/numa.txt b/Documentation/devicetree/bindings/numa.txt
new file mode 100644
index 0000000..ec5ed7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/numa.txt
@@ -0,0 +1,272 @@
+==============================================================================
+NUMA binding description.
+==============================================================================
+
+==============================================================================
+1 - Introduction
+==============================================================================
+
+Systems employing a Non Uniform Memory Access (NUMA) architecture contain
+collections of hardware resources including processors, memory, and I/O buses,
+that comprise what is commonly known as a NUMA node.
+Processor accesses to memory within the local NUMA node is generally faster
+than processor accesses to memory outside of the local NUMA node.
+DT defines interfaces that allow the platform to convey NUMA node
+topology information to OS.
+
+==============================================================================
+2 - numa-node-id
+==============================================================================
+
+For the purpose of identification, each NUMA node is associated with a unique
+token known as a node id. For the purpose of this binding
+a node id is a 32-bit integer.
+
+A device node is associated with a NUMA node by the presence of a
+numa-node-id property which contains the node id of the device.
+
+Example:
+	/* numa node 0 */
+	numa-node-id = <0>;
+
+	/* numa node 1 */
+	numa-node-id = <1>;
+
+==============================================================================
+3 - distance-map
+==============================================================================
+
+The device tree node distance-map describes the relative
+distance (memory latency) between all numa nodes.
+
+- compatible : Should at least contain "numa-distance-map-v1".
+
+- distance-matrix
+  This property defines a matrix to describe the relative distances
+  between all numa nodes.
+  It is represented as a list of node pairs and their relative distance.
+
+  Note:
+	1. Each entry represents distance from first node to second node.
+	The distances are equal in either direction.
+	2. The distance from a node to self (local distance) is represented
+	with value 10 and all internode distance should be represented with
+	a value greater than 10.
+	3. distance-matrix should have entries in lexicographical ascending
+	order of nodes.
+	4. There must be only one device node distance-map which must reside in the root node.
+
+Example:
+	4 nodes connected in mesh/ring topology as below,
+
+		0_______20______1
+		|               |
+		|               |
+		20             20
+		|               |
+		|               |
+		|_______________|
+		3       20      2
+
+	if relative distance for each hop is 20,
+	then internode distance would be,
+	      0 -> 1 = 20
+	      1 -> 2 = 20
+	      2 -> 3 = 20
+	      3 -> 0 = 20
+	      0 -> 2 = 40
+	      1 -> 3 = 40
+
+     and dt presentation for this distance matrix is,
+
+		distance-map {
+			 compatible = "numa-distance-map-v1";
+			 distance-matrix = <0 0  10>,
+					   <0 1  20>,
+					   <0 2  40>,
+					   <0 3  20>,
+					   <1 0  20>,
+					   <1 1  10>,
+					   <1 2  20>,
+					   <1 3  40>,
+					   <2 0  40>,
+					   <2 1  20>,
+					   <2 2  10>,
+					   <2 3  20>,
+					   <3 0  20>,
+					   <3 1  40>,
+					   <3 2  20>,
+					   <3 3  10>;
+		};
+
+==============================================================================
+4 - Example dts
+==============================================================================
+
+Dual socket system consists of 2 boards connected through ccn bus and
+each board having one socket/soc of 8 cpus, memory and pci bus.
+
+	memory at c00000 {
+		device_type = "memory";
+		reg = <0x0 0xc00000 0x0 0x80000000>;
+		/* node 0 */
+		numa-node-id = <0>;
+	};
+
+	memory at 10000000000 {
+		device_type = "memory";
+		reg = <0x100 0x0 0x0 0x80000000>;
+		/* node 1 */
+		numa-node-id = <1>;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x0>;
+			enable-method = "psci";
+			/* node 0 */
+			numa-node-id = <0>;
+		};
+		cpu at 1 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x1>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 2 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x2>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 3 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x3>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 4 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x4>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 5 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x5>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 6 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x6>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 7 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x7>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 8 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x8>;
+			enable-method = "psci";
+			/* node 1 */
+			numa-node-id = <1>;
+		};
+		cpu at 9 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x9>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at a {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xa>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at b {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xb>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at c {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xc>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at d {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xd>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at e {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xe>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at f {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xf>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+	};
+
+	pcie0: pcie0 at 848000000000 {
+		compatible = "arm,armv8";
+		device_type = "pci";
+		bus-range = <0 255>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		reg = <0x8480 0x00000000 0 0x10000000>;  /* Configuration space */
+		ranges = <0x03000000 0x8010 0x00000000 0x8010 0x00000000 0x70 0x00000000>;
+		/* node 0 */
+		numa-node-id = <0>;
+        };
+
+	pcie1: pcie1 at 948000000000 {
+		compatible = "arm,armv8";
+		device_type = "pci";
+		bus-range = <0 255>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		reg = <0x9480 0x00000000 0 0x10000000>;  /* Configuration space */
+		ranges = <0x03000000 0x9010 0x00000000 0x9010 0x00000000 0x70 0x00000000>;
+		/* node 1 */
+		numa-node-id = <1>;
+        };
+
+	distance-map {
+		compatible = "numa-distance-map-v1";
+		distance-matrix = <0 0 10>,
+				  <0 1 20>,
+				  <1 1 10>;
+	};
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Fri Feb 19 17:13:15 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri, 19 Feb 2016 17:13:15 -0800
Subject: [PATCH v11 06/10] arm64/efi: ignore DT memreserve entries instead of
 removing them
In-Reply-To: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1455930799-5371-7-git-send-email-ddaney.cavm@gmail.com>

From: Ard Biesheuvel <ard.biesheuvel at linaro.org>

Now that the reservation of the FDT image itself is split off from
the processing of memory reservations described by the device tree,
we can make the DT scanning of memreserves conditional on whether
we booted via UEFI and have its memory map available. This allows
us to drop deletion of these memreserves in the stub. It also fixes
the issue where the /reserved-memory node (which offers another
way of reserving memory ranges) was not being ignored under UEFI.

Note that this reverts commit 0ceac9e094b0 ("efi/arm64: Fix
fdt-related memory reservation").

Acked-by: Leif Lindholm <leif.lindholm at linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Signed-off-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 arch/arm64/mm/init.c               |  3 ++-
 drivers/firmware/efi/libstub/fdt.c | 11 +----------
 2 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index eda226e..ee06165 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -171,7 +171,8 @@ void __init arm64_memblock_init(void)
 		memblock_reserve(__virt_to_phys(initrd_start), initrd_end - initrd_start);
 #endif
 
-	early_init_fdt_scan_reserved_mem();
+	if (!efi_enabled(EFI_MEMMAP))
+		early_init_fdt_scan_reserved_mem();
 
 	/* 4GB maximum for 32-bit only capable devices */
 	if (IS_ENABLED(CONFIG_ZONE_DMA))
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index 9df1560..12cb2a3 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -24,8 +24,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
 			unsigned long map_size, unsigned long desc_size,
 			u32 desc_ver)
 {
-	int node, num_rsv;
-	int status;
+	int node, status;
 	u32 fdt_val32;
 	u64 fdt_val64;
 
@@ -53,14 +52,6 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
 	if (status != 0)
 		goto fdt_set_fail;
 
-	/*
-	 * Delete all memory reserve map entries. When booting via UEFI,
-	 * kernel will use the UEFI memory map to find reserved regions.
-	 */
-	num_rsv = fdt_num_mem_rsv(fdt);
-	while (num_rsv-- > 0)
-		fdt_del_mem_rsv(fdt, num_rsv);
-
 	node = fdt_subnode_offset(fdt, 0, "chosen");
 	if (node < 0) {
 		node = fdt_add_subnode(fdt, 0, "chosen");
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Fri Feb 19 17:13:17 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri, 19 Feb 2016 17:13:17 -0800
Subject: [PATCH v11 08/10] dt, numa: Add NUMA dt binding implementation.
In-Reply-To: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1455930799-5371-9-git-send-email-ddaney.cavm@gmail.com>

From: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>

ADD device tree node parsing for NUMA topology using device
"numa-node-id" property distance-map.

Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 drivers/of/Kconfig   |   3 +
 drivers/of/Makefile  |   1 +
 drivers/of/of_numa.c | 211 +++++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of.h   |   9 +++
 4 files changed, 224 insertions(+)
 create mode 100644 drivers/of/of_numa.c

diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index e2a4841..b3bec3a 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -112,4 +112,7 @@ config OF_OVERLAY
 	  While this option is selected automatically when needed, you can
 	  enable it manually to improve device tree unit test coverage.
 
+config OF_NUMA
+	bool
+
 endif # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 156c072..bee3fa9 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -14,5 +14,6 @@ obj-$(CONFIG_OF_MTD)	+= of_mtd.o
 obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
 obj-$(CONFIG_OF_RESOLVE)  += resolver.o
 obj-$(CONFIG_OF_OVERLAY) += overlay.o
+obj-$(CONFIG_OF_NUMA) += of_numa.o
 
 obj-$(CONFIG_OF_UNITTEST) += unittest-data/
diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
new file mode 100644
index 0000000..a691d06
--- /dev/null
+++ b/drivers/of/of_numa.c
@@ -0,0 +1,211 @@
+/*
+ * OF NUMA Parsing support.
+ *
+ * Copyright (C) 2015 - 2016 Cavium Inc.
+ * Author: Ganapatrao Kulkarni <gkulkarni at 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/of.h>
+#include <linux/of_fdt.h>
+#include <linux/nodemask.h>
+
+#include <asm/numa.h>
+
+/* define default numa node to 0 */
+#define DEFAULT_NODE 0
+
+/* Returns nid in the range [0..MAX_NUMNODES-1],
+ * or NUMA_NO_NODE if no valid numa-node-id entry found
+ * or DEFAULT_NODE if no numa-node-id entry exists
+ */
+static int of_numa_prop_to_nid(const __be32 *of_numa_prop, int length)
+{
+	int nid;
+
+	if (!of_numa_prop)
+		return DEFAULT_NODE;
+
+	if (length != sizeof(*of_numa_prop)) {
+		pr_warn("NUMA: Invalid of_numa_prop length %d found.\n",
+				length);
+		return NUMA_NO_NODE;
+	}
+
+	nid = of_read_number(of_numa_prop, 1);
+	if (nid >= MAX_NUMNODES) {
+		pr_warn("NUMA: Invalid numa node %d found.\n", nid);
+		return NUMA_NO_NODE;
+	}
+
+	return nid;
+}
+
+static int __init early_init_of_node_to_nid(unsigned long node)
+{
+	int length;
+	const __be32 *of_numa_prop;
+
+	of_numa_prop = of_get_flat_dt_prop(node, "numa-node-id", &length);
+
+	return of_numa_prop_to_nid(of_numa_prop, length);
+}
+
+/*
+ * Even though we connect cpus to numa domains later in SMP
+ * init, we need to know the node ids now for all cpus.
+*/
+static int __init early_init_parse_cpu_node(unsigned long node)
+{
+	int nid;
+	const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
+
+	if (type == NULL)
+		return 0;
+
+	if (strcmp(type, "cpu") != 0)
+		return 0;
+
+	nid = early_init_of_node_to_nid(node);
+	if (nid == NUMA_NO_NODE)
+		return -EINVAL;
+
+	node_set(nid, numa_nodes_parsed);
+	return 0;
+}
+
+static int __init early_init_parse_memory_node(unsigned long node)
+{
+	const __be32 *reg, *endp;
+	int length;
+	int nid;
+	const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
+
+	if (type == NULL)
+		return 0;
+
+	if (strcmp(type, "memory") != 0)
+		return 0;
+
+	nid = early_init_of_node_to_nid(node);
+	if (nid == NUMA_NO_NODE)
+		return -EINVAL;
+
+	reg = of_get_flat_dt_prop(node, "reg", &length);
+	endp = reg + (length / sizeof(__be32));
+
+	while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
+		u64 base, size;
+
+		base = dt_mem_next_cell(dt_root_addr_cells, &reg);
+		size = dt_mem_next_cell(dt_root_size_cells, &reg);
+		pr_debug("NUMA:  base = %llx , node = %u\n",
+				base, nid);
+
+		if (numa_add_memblk(nid, base, size) < 0)
+			return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int __init early_init_parse_distance_map_v1(unsigned long node,
+		const char *uname)
+{
+	const __be32 *prop_dist_matrix;
+	int length = 0, i, matrix_count;
+	int nr_size_cells = OF_ROOT_NODE_SIZE_CELLS_DEFAULT;
+
+	pr_info("NUMA: parsing numa-distance-map-v1\n");
+
+	prop_dist_matrix =
+		of_get_flat_dt_prop(node, "distance-matrix", &length);
+
+	if (!length) {
+		pr_err("NUMA: failed to parse distance-matrix\n");
+		return -ENODEV;
+	}
+
+	matrix_count = ((length / sizeof(__be32)) / (3 * nr_size_cells));
+
+	if ((matrix_count * sizeof(__be32) * 3 * nr_size_cells) !=  length) {
+		pr_warn("NUMA: invalid distance-matrix length %d\n", length);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < matrix_count; i++) {
+		u32 nodea, nodeb, distance;
+
+		nodea = dt_mem_next_cell(nr_size_cells, &prop_dist_matrix);
+		nodeb = dt_mem_next_cell(nr_size_cells, &prop_dist_matrix);
+		distance = dt_mem_next_cell(nr_size_cells, &prop_dist_matrix);
+		numa_set_distance(nodea, nodeb, distance);
+		pr_debug("NUMA:  distance[node%d -> node%d] = %d\n",
+				nodea, nodeb, distance);
+
+		/* Set default distance of node B->A same as A->B */
+		if (nodeb > nodea)
+			numa_set_distance(nodeb, nodea, distance);
+	}
+
+	return 0;
+}
+
+static int __init early_init_parse_distance_map(unsigned long node,
+		const char *uname)
+{
+	if (strcmp(uname, "distance-map") != 0)
+		return 0;
+
+	if (of_flat_dt_is_compatible(node, "numa-distance-map-v1"))
+		return early_init_parse_distance_map_v1(node, uname);
+
+	pr_err("NUMA: invalid distance-map device node\n");
+	return -EINVAL;
+}
+
+static int __init early_init_of_scan_numa_map(unsigned long node,
+					      const char *uname,
+					      int depth, void *data)
+{
+	int ret;
+
+	ret = early_init_parse_cpu_node(node);
+	if (ret)
+		return ret;
+
+	ret = early_init_parse_memory_node(node);
+	if (ret)
+		return ret;
+
+	return early_init_parse_distance_map(node, uname);
+}
+
+int of_node_to_nid(struct device_node *device)
+{
+	const __be32 *of_numa_prop;
+	int length;
+
+	of_numa_prop = of_get_property(device, "numa-node-id", &length);
+	if (of_numa_prop)
+		return of_numa_prop_to_nid(of_numa_prop, length);
+
+	return NUMA_NO_NODE;
+}
+
+/* DT node mapping is done already early_init_of_scan_memory */
+int __init of_numa_init(void)
+{
+	return of_scan_flat_dt(early_init_of_scan_numa_map, NULL);
+}
diff --git a/include/linux/of.h b/include/linux/of.h
index dc6e396..fe67a4c 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -685,6 +685,15 @@ static inline int of_node_to_nid(struct device_node *device)
 }
 #endif
 
+#ifdef CONFIG_OF_NUMA
+extern int of_numa_init(void);
+#else
+static inline int of_numa_init(void)
+{
+	return -ENOSYS;
+}
+#endif
+
 static inline struct device_node *of_find_matching_node(
 	struct device_node *from,
 	const struct of_device_id *matches)
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Fri Feb 19 17:13:18 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Fri, 19 Feb 2016 17:13:18 -0800
Subject: [PATCH v11 09/10] arm64, numa: Add NUMA support for arm64 platforms.
In-Reply-To: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1455930799-5371-10-git-send-email-ddaney.cavm@gmail.com>

From: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>

Attempt to get the memory and CPU NUMA node via of_numa.  If that
fails, default the dummy NUMA node and map all memory and CPUs to node
0.

Tested-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 arch/arm64/Kconfig                |  26 +++
 arch/arm64/include/asm/mmzone.h   |  12 ++
 arch/arm64/include/asm/numa.h     |  45 +++++
 arch/arm64/include/asm/topology.h |  10 +
 arch/arm64/kernel/pci.c           |  10 +
 arch/arm64/kernel/setup.c         |   4 +
 arch/arm64/kernel/smp.c           |   4 +
 arch/arm64/mm/Makefile            |   1 +
 arch/arm64/mm/init.c              |  34 +++-
 arch/arm64/mm/mmu.c               |   1 +
 arch/arm64/mm/numa.c              | 403 ++++++++++++++++++++++++++++++++++++++
 11 files changed, 545 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm64/include/asm/mmzone.h
 create mode 100644 arch/arm64/include/asm/numa.h
 create mode 100644 arch/arm64/mm/numa.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a969970..9f0972a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -74,6 +74,7 @@ config ARM64
 	select HAVE_HW_BREAKPOINT if PERF_EVENTS
 	select HAVE_IRQ_TIME_ACCOUNTING
 	select HAVE_MEMBLOCK
+	select HAVE_MEMBLOCK_NODE_MAP if NUMA
 	select HAVE_PATA_PLATFORM
 	select HAVE_PERF_EVENTS
 	select HAVE_PERF_REGS
@@ -96,6 +97,7 @@ config ARM64
 	select SYSCTL_EXCEPTION_TRACE
 	select HAVE_CONTEXT_TRACKING
 	select HAVE_ARM_SMCCC
+	select OF_NUMA if NUMA && OF
 	help
 	  ARM 64-bit (AArch64) Linux support.
 
@@ -545,6 +547,30 @@ config HOTPLUG_CPU
 	  Say Y here to experiment with turning CPUs off and on.  CPUs
 	  can be controlled through /sys/devices/system/cpu.
 
+# Common NUMA Features
+config NUMA
+	bool "Numa Memory Allocation and Scheduler Support"
+	depends on SMP
+	help
+	  Enable NUMA (Non Uniform Memory Access) support.
+
+	  The kernel will try to allocate memory used by a CPU on the
+	  local memory of the CPU and add some more
+	  NUMA awareness to the kernel.
+
+config NODES_SHIFT
+	int "Maximum NUMA Nodes (as a power of 2)"
+	range 1 10
+	default "2"
+	depends on NEED_MULTIPLE_NODES
+	help
+	  Specify the maximum number of NUMA Nodes available on the target
+	  system.  Increases memory reserved to accommodate various tables.
+
+config USE_PERCPU_NUMA_NODE_ID
+	def_bool y
+	depends on NUMA
+
 source kernel/Kconfig.preempt
 source kernel/Kconfig.hz
 
diff --git a/arch/arm64/include/asm/mmzone.h b/arch/arm64/include/asm/mmzone.h
new file mode 100644
index 0000000..a0de9e6
--- /dev/null
+++ b/arch/arm64/include/asm/mmzone.h
@@ -0,0 +1,12 @@
+#ifndef __ASM_MMZONE_H
+#define __ASM_MMZONE_H
+
+#ifdef CONFIG_NUMA
+
+#include <asm/numa.h>
+
+extern struct pglist_data *node_data[];
+#define NODE_DATA(nid)		(node_data[(nid)])
+
+#endif /* CONFIG_NUMA */
+#endif /* __ASM_MMZONE_H */
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
new file mode 100644
index 0000000..e9b4f29
--- /dev/null
+++ b/arch/arm64/include/asm/numa.h
@@ -0,0 +1,45 @@
+#ifndef __ASM_NUMA_H
+#define __ASM_NUMA_H
+
+#include <asm/topology.h>
+
+#ifdef CONFIG_NUMA
+
+/* currently, arm64 implements flat NUMA topology */
+#define parent_node(node)	(node)
+
+int __node_distance(int from, int to);
+#define node_distance(a, b) __node_distance(a, b)
+
+extern nodemask_t numa_nodes_parsed __initdata;
+
+/* Mappings between node number and cpus on that node. */
+extern cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
+void numa_clear_node(unsigned int cpu);
+
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+const struct cpumask *cpumask_of_node(int node);
+#else
+/* Returns a pointer to the cpumask of CPUs on Node 'node'. */
+static inline const struct cpumask *cpumask_of_node(int node)
+{
+	return node_to_cpumask_map[node];
+}
+#endif
+
+void __init arm64_numa_init(void);
+int __init numa_add_memblk(int nodeid, u64 start, u64 end);
+void __init numa_set_distance(int from, int to, int distance);
+void __init numa_free_distance(void);
+void __init early_map_cpu_to_node(unsigned int cpu, int nid);
+void numa_store_cpu_info(unsigned int cpu);
+
+#else	/* CONFIG_NUMA */
+
+static inline void numa_store_cpu_info(unsigned int cpu) { }
+static inline void arm64_numa_init(void) { }
+static inline void early_map_cpu_to_node(unsigned int cpu, int nid) { }
+
+#endif	/* CONFIG_NUMA */
+
+#endif	/* __ASM_NUMA_H */
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index a3e9d6f..8b57339 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -22,6 +22,16 @@ void init_cpu_topology(void);
 void store_cpu_topology(unsigned int cpuid);
 const struct cpumask *cpu_coregroup_mask(int cpu);
 
+#ifdef CONFIG_NUMA
+
+struct pci_bus;
+int pcibus_to_node(struct pci_bus *bus);
+#define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ?		\
+				 cpu_all_mask :				\
+				 cpumask_of_node(pcibus_to_node(bus)))
+
+#endif /* CONFIG_NUMA */
+
 #include <asm-generic/topology.h>
 
 #endif /* _ASM_ARM_TOPOLOGY_H */
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index b3d098b..65e6b7d 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -76,6 +76,16 @@ int raw_pci_write(unsigned int domain, unsigned int bus,
 	return -ENXIO;
 }
 
+#ifdef CONFIG_NUMA
+
+int pcibus_to_node(struct pci_bus *bus)
+{
+	return dev_to_node(&bus->dev);
+}
+EXPORT_SYMBOL(pcibus_to_node);
+
+#endif
+
 #ifdef CONFIG_ACPI
 /* Root bridge scanning */
 struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 3f57233..a347a55 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -53,6 +53,7 @@
 #include <asm/cpufeature.h>
 #include <asm/cpu_ops.h>
 #include <asm/kasan.h>
+#include <asm/numa.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
 #include <asm/smp_plat.h>
@@ -375,6 +376,9 @@ static int __init topology_init(void)
 {
 	int i;
 
+	for_each_online_node(i)
+		register_one_node(i);
+
 	for_each_possible_cpu(i) {
 		struct cpu *cpu = &per_cpu(cpu_data.cpu, i);
 		cpu->hotpluggable = 1;
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index b1adc51..46c45c8 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -45,6 +45,7 @@
 #include <asm/cputype.h>
 #include <asm/cpu_ops.h>
 #include <asm/mmu_context.h>
+#include <asm/numa.h>
 #include <asm/pgtable.h>
 #include <asm/pgalloc.h>
 #include <asm/processor.h>
@@ -125,6 +126,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
 static void smp_store_cpu_info(unsigned int cpuid)
 {
 	store_cpu_topology(cpuid);
+	numa_store_cpu_info(cpuid);
 }
 
 /*
@@ -518,6 +520,8 @@ static void __init of_parse_and_init_cpus(void)
 
 		pr_debug("cpu logical map 0x%llx\n", hwid);
 		cpu_logical_map(cpu_count) = hwid;
+
+		early_map_cpu_to_node(cpu_count, of_node_to_nid(dn));
 next:
 		cpu_count++;
 	}
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index 57f57fd..54bb209 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -4,6 +4,7 @@ obj-y				:= dma-mapping.o extable.o fault.o init.o \
 				   context.o proc.o pageattr.o
 obj-$(CONFIG_HUGETLB_PAGE)	+= hugetlbpage.o
 obj-$(CONFIG_ARM64_PTDUMP)	+= dump.o
+obj-$(CONFIG_NUMA)		+= numa.o
 
 obj-$(CONFIG_KASAN)		+= kasan_init.o
 KASAN_SANITIZE_kasan_init.o	:= n
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index ee06165..5680c84 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -37,6 +37,7 @@
 
 #include <asm/fixmap.h>
 #include <asm/memory.h>
+#include <asm/numa.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
 #include <asm/sizes.h>
@@ -77,6 +78,21 @@ static phys_addr_t __init max_zone_dma_phys(void)
 	return min(offset + (1ULL << 32), memblock_end_of_DRAM());
 }
 
+#ifdef CONFIG_NUMA
+
+static void __init zone_sizes_init(unsigned long min, unsigned long max)
+{
+	unsigned long max_zone_pfns[MAX_NR_ZONES]  = {0};
+
+	if (IS_ENABLED(CONFIG_ZONE_DMA))
+		max_zone_pfns[ZONE_DMA] = PFN_DOWN(max_zone_dma_phys());
+	max_zone_pfns[ZONE_NORMAL] = max;
+
+	free_area_init_nodes(max_zone_pfns);
+}
+
+#else
+
 static void __init zone_sizes_init(unsigned long min, unsigned long max)
 {
 	struct memblock_region *reg;
@@ -117,6 +133,8 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
 	free_area_init_node(0, zone_size, min, zhole_size);
 }
 
+#endif /* CONFIG_NUMA */
+
 #ifdef CONFIG_HAVE_ARCH_PFN_VALID
 int pfn_valid(unsigned long pfn)
 {
@@ -133,10 +151,15 @@ static void __init arm64_memory_present(void)
 static void __init arm64_memory_present(void)
 {
 	struct memblock_region *reg;
+	int nid = 0;
 
-	for_each_memblock(memory, reg)
-		memory_present(0, memblock_region_memory_base_pfn(reg),
-			       memblock_region_memory_end_pfn(reg));
+	for_each_memblock(memory, reg) {
+#ifdef CONFIG_NUMA
+		nid = reg->nid;
+#endif
+		memory_present(nid, memblock_region_memory_base_pfn(reg),
+				memblock_region_memory_end_pfn(reg));
+	}
 }
 #endif
 
@@ -182,7 +205,6 @@ void __init arm64_memblock_init(void)
 	dma_contiguous_reserve(arm64_dma_phys_limit);
 
 	memblock_allow_resize();
-	memblock_dump_all();
 }
 
 void __init bootmem_init(void)
@@ -194,6 +216,9 @@ void __init bootmem_init(void)
 
 	early_memtest(min << PAGE_SHIFT, max << PAGE_SHIFT);
 
+	max_pfn = max_low_pfn = max;
+
+	arm64_numa_init();
 	/*
 	 * Sparsemem tries to allocate bootmem in memory_present(), so must be
 	 * done after the fixed reservations.
@@ -204,7 +229,6 @@ void __init bootmem_init(void)
 	zone_sizes_init(min, max);
 
 	high_memory = __va((max << PAGE_SHIFT) - 1) + 1;
-	max_pfn = max_low_pfn = max;
 }
 
 #ifndef CONFIG_SPARSEMEM_VMEMMAP
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 58faeaa..44e3854 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -463,6 +463,7 @@ void __init paging_init(void)
 	zero_page = early_alloc(PAGE_SIZE);
 
 	bootmem_init();
+	memblock_dump_all();
 
 	empty_zero_page = virt_to_page(zero_page);
 
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
new file mode 100644
index 0000000..604e886
--- /dev/null
+++ b/arch/arm64/mm/numa.c
@@ -0,0 +1,403 @@
+/*
+ * NUMA support, based on the x86 implementation.
+ *
+ * Copyright (C) 2015 Cavium Inc.
+ * Author: Ganapatrao Kulkarni <gkulkarni at 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/bootmem.h>
+#include <linux/memblock.h>
+#include <linux/module.h>
+#include <linux/of.h>
+
+struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
+EXPORT_SYMBOL(node_data);
+nodemask_t numa_nodes_parsed __initdata;
+static int cpu_to_node_map[NR_CPUS] = { [0 ... NR_CPUS-1] = NUMA_NO_NODE };
+
+static int numa_off;
+static int numa_distance_cnt;
+static u8 *numa_distance;
+
+static __init int numa_parse_early_param(char *opt)
+{
+	if (!opt)
+		return -EINVAL;
+	if (!strncmp(opt, "off", 3)) {
+		pr_info("%s\n", "NUMA turned off");
+		numa_off = 1;
+	}
+	return 0;
+}
+early_param("numa", numa_parse_early_param);
+
+cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
+EXPORT_SYMBOL(node_to_cpumask_map);
+
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+
+/*
+ * Returns a pointer to the bitmask of CPUs on Node 'node'.
+ */
+const struct cpumask *cpumask_of_node(int node)
+{
+	if (WARN_ON(node >= nr_node_ids))
+		return cpu_none_mask;
+
+	if (WARN_ON(node_to_cpumask_map[node] == NULL))
+		return cpu_online_mask;
+
+	return node_to_cpumask_map[node];
+}
+EXPORT_SYMBOL(cpumask_of_node);
+
+#endif
+
+static void map_cpu_to_node(unsigned int cpu, int nid)
+{
+	set_cpu_numa_node(cpu, nid);
+	if (nid >= 0)
+		cpumask_set_cpu(cpu, node_to_cpumask_map[nid]);
+}
+
+static void unmap_cpu_to_node(unsigned int cpu)
+{
+	int nid = cpu_to_node(cpu);
+
+	if (nid >= 0)
+		cpumask_clear_cpu(cpu, node_to_cpumask_map[nid]);
+	set_cpu_numa_node(cpu, NUMA_NO_NODE);
+}
+
+void numa_clear_node(unsigned int cpu)
+{
+	unmap_cpu_to_node(cpu);
+}
+
+/*
+ * Allocate node_to_cpumask_map based on number of available nodes
+ * Requires node_possible_map to be valid.
+ *
+ * Note: cpumask_of_node() is not valid until after this is done.
+ * (Use CONFIG_DEBUG_PER_CPU_MAPS to check this.)
+ */
+static void __init setup_node_to_cpumask_map(void)
+{
+	unsigned int cpu;
+	int node;
+
+	/* setup nr_node_ids if not done yet */
+	if (nr_node_ids == MAX_NUMNODES)
+		setup_nr_node_ids();
+
+	/* allocate and clear the mapping */
+	for (node = 0; node < nr_node_ids; node++) {
+		alloc_bootmem_cpumask_var(&node_to_cpumask_map[node]);
+		cpumask_clear(node_to_cpumask_map[node]);
+	}
+
+	for_each_possible_cpu(cpu)
+		set_cpu_numa_node(cpu, NUMA_NO_NODE);
+
+	/* cpumask_of_node() will now work */
+	pr_debug("NUMA: Node to cpumask map for %d nodes\n", nr_node_ids);
+}
+
+/*
+ *  Set the cpu to node and mem mapping
+ */
+void numa_store_cpu_info(unsigned int cpu)
+{
+	map_cpu_to_node(cpu, numa_off ? 0 : cpu_to_node_map[cpu]);
+}
+
+void __init early_map_cpu_to_node(unsigned int cpu, int nid)
+{
+	/* fallback to node 0 */
+	if (nid < 0 || nid >= MAX_NUMNODES)
+		nid = 0;
+
+	cpu_to_node_map[cpu] = nid;
+}
+
+/**
+ * numa_add_memblk - Set node id to memblk
+ * @nid: NUMA node ID of the new memblk
+ * @start: Start address of the new memblk
+ * @size:  Size of the new memblk
+ *
+ * RETURNS:
+ * 0 on success, -errno on failure.
+ */
+int __init numa_add_memblk(int nid, u64 start, u64 size)
+{
+	int ret;
+
+	ret = memblock_set_node(start, size, &memblock.memory, nid);
+	if (ret < 0) {
+		pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node %d\n",
+			start, (start + size - 1), nid);
+		return ret;
+	}
+
+	node_set(nid, numa_nodes_parsed);
+	pr_info("NUMA: Adding memblock [0x%llx - 0x%llx] on node %d\n",
+			start, (start + size - 1), nid);
+	return ret;
+}
+EXPORT_SYMBOL(numa_add_memblk);
+
+/**
+ * Initialize NODE_DATA for a node on the local memory
+ */
+static void __init setup_node_data(int nid, u64 start_pfn, u64 end_pfn)
+{
+	const size_t nd_size = roundup(sizeof(pg_data_t), SMP_CACHE_BYTES);
+	u64 nd_pa;
+	void *nd;
+	int tnid;
+
+	pr_info("NUMA: Initmem setup node %d [mem %#010Lx-%#010Lx]\n",
+			nid, start_pfn << PAGE_SHIFT,
+			(end_pfn << PAGE_SHIFT) - 1);
+
+	nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
+	nd = __va(nd_pa);
+
+	/* report and initialize */
+	pr_info("NUMA: NODE_DATA [mem %#010Lx-%#010Lx]\n",
+		nd_pa, nd_pa + nd_size - 1);
+	tnid = early_pfn_to_nid(nd_pa >> PAGE_SHIFT);
+	if (tnid != nid)
+		pr_info("NUMA: NODE_DATA(%d) on node %d\n", nid, tnid);
+
+	node_data[nid] = nd;
+	memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
+	NODE_DATA(nid)->node_id = nid;
+	NODE_DATA(nid)->node_start_pfn = start_pfn;
+	NODE_DATA(nid)->node_spanned_pages = end_pfn - start_pfn;
+}
+
+/**
+ * numa_free_distance
+ *
+ * The current table is freed.
+ */
+void __init numa_free_distance(void)
+{
+	size_t size;
+
+	if (!numa_distance)
+		return;
+
+	size = numa_distance_cnt * numa_distance_cnt *
+		sizeof(numa_distance[0]);
+
+	memblock_free(__pa(numa_distance), size);
+	numa_distance_cnt = 0;
+	numa_distance = NULL;
+}
+
+/**
+ *
+ * Create a new NUMA distance table.
+ *
+ */
+static int __init numa_alloc_distance(void)
+{
+	size_t size;
+	u64 phys;
+	int i, j;
+
+	size = nr_node_ids * nr_node_ids * sizeof(numa_distance[0]);
+	phys = memblock_find_in_range(0, PFN_PHYS(max_pfn),
+				      size, PAGE_SIZE);
+	if (WARN_ON(!phys))
+		return -ENOMEM;
+
+	memblock_reserve(phys, size);
+
+	numa_distance = __va(phys);
+	numa_distance_cnt = nr_node_ids;
+
+	/* fill with the default distances */
+	for (i = 0; i < numa_distance_cnt; i++)
+		for (j = 0; j < numa_distance_cnt; j++)
+			numa_distance[i * numa_distance_cnt + j] = i == j ?
+				LOCAL_DISTANCE : REMOTE_DISTANCE;
+
+	pr_debug("NUMA: Initialized distance table, cnt=%d\n",
+			numa_distance_cnt);
+
+	return 0;
+}
+
+/**
+ * numa_set_distance - Set inter node NUMA distance from node to node.
+ * @from: the 'from' node to set distance
+ * @to: the 'to'  node to set distance
+ * @distance: NUMA distance
+ *
+ * Set the distance from node @from to @to to @distance.
+ * If distance table doesn't exist, a warning is printed.
+ *
+ * If @from or @to is higher than the highest known node or lower than zero
+ * or @distance doesn't make sense, the call is ignored.
+ *
+ */
+void __init numa_set_distance(int from, int to, int distance)
+{
+	if (!numa_distance) {
+		pr_warn_once("NUMA: Warning: distance table not allocated yet\n");
+		return;
+	}
+
+	if (from >= numa_distance_cnt || to >= numa_distance_cnt ||
+			from < 0 || to < 0) {
+		pr_warn_once("NUMA: Warning: node ids are out of bound, from=%d to=%d distance=%d\n",
+			    from, to, distance);
+		return;
+	}
+
+	if ((u8)distance != distance ||
+	    (from == to && distance != LOCAL_DISTANCE)) {
+		pr_warn_once("NUMA: Warning: invalid distance parameter, from=%d to=%d distance=%d\n",
+			     from, to, distance);
+		return;
+	}
+
+	numa_distance[from * numa_distance_cnt + to] = distance;
+}
+EXPORT_SYMBOL(numa_set_distance);
+
+/**
+ * Return NUMA distance @from to @to
+ */
+int __node_distance(int from, int to)
+{
+	if (from >= numa_distance_cnt || to >= numa_distance_cnt)
+		return from == to ? LOCAL_DISTANCE : REMOTE_DISTANCE;
+	return numa_distance[from * numa_distance_cnt + to];
+}
+EXPORT_SYMBOL(__node_distance);
+
+static int __init numa_register_nodes(void)
+{
+	int nid;
+	struct memblock_region *mblk;
+
+	/* Check that valid nid is set to memblks */
+	for_each_memblock(memory, mblk)
+		if (mblk->nid == NUMA_NO_NODE || mblk->nid >= MAX_NUMNODES) {
+			pr_warn("NUMA: Warning: invalid memblk node %d [mem %#010Lx-%#010Lx]\n",
+				mblk->nid, mblk->base,
+				mblk->base + mblk->size - 1);
+			return -EINVAL;
+		}
+
+	/* Finally register nodes. */
+	for_each_node_mask(nid, numa_nodes_parsed) {
+		unsigned long start_pfn, end_pfn;
+
+		get_pfn_range_for_nid(nid, &start_pfn, &end_pfn);
+		setup_node_data(nid, start_pfn, end_pfn);
+		node_set_online(nid);
+	}
+
+	/* Setup online nodes to actual nodes*/
+	node_possible_map = numa_nodes_parsed;
+
+	return 0;
+}
+
+static int __init numa_init(int (*init_func)(void))
+{
+	int ret;
+
+	nodes_clear(numa_nodes_parsed);
+	nodes_clear(node_possible_map);
+	nodes_clear(node_online_map);
+	numa_free_distance();
+
+	ret = numa_alloc_distance();
+	if (ret < 0)
+		return ret;
+
+	ret = init_func();
+	if (ret < 0)
+		return ret;
+
+	if (nodes_empty(numa_nodes_parsed))
+		return -EINVAL;
+
+	ret = numa_register_nodes();
+	if (ret < 0)
+		return ret;
+
+	setup_node_to_cpumask_map();
+
+	/* init boot processor */
+	cpu_to_node_map[0] = 0;
+	map_cpu_to_node(0, 0);
+
+	return 0;
+}
+
+/**
+ * dummy_numa_init - Fallback dummy NUMA init
+ *
+ * Used if there's no underlying NUMA architecture, NUMA initialization
+ * fails, or NUMA is disabled on the command line.
+ *
+ * Must online at least one node (node 0) and add memory blocks that cover all
+ * allowed memory. It is unlikely that this function fails.
+ */
+static int __init dummy_numa_init(void)
+{
+	int ret;
+	struct memblock_region *mblk;
+
+	pr_info("%s\n", "No NUMA configuration found");
+	pr_info("NUMA: Faking a node at [mem %#018Lx-%#018Lx]\n",
+	       0LLU, PFN_PHYS(max_pfn) - 1);
+
+	for_each_memblock(memory, mblk) {
+		ret = numa_add_memblk(0, mblk->base, mblk->size);
+		if (!ret)
+			continue;
+
+		pr_err("NUMA init failed\n");
+		return ret;
+	}
+
+	numa_off = 1;
+	return 0;
+}
+
+/**
+ * arm64_numa_init - Initialize NUMA
+ *
+ * Try each configured NUMA initialization method until one succeeds.  The
+ * last fallback is dummy single node config encomapssing whole memory.
+ */
+void __init arm64_numa_init(void)
+{
+	if (!numa_off) {
+		if (!numa_init(of_numa_init))
+			return;
+	}
+
+	numa_init(dummy_numa_init);
+}
-- 
1.8.3.1



From linux at roeck-us.net  Fri Feb 19 17:15:20 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Fri, 19 Feb 2016 17:15:20 -0800
Subject: [PATCH] hwmon: (gpio-fan) Remove un-necessary speed_index lookup
 for thermal hook
In-Reply-To: <1455926991-15189-1-git-send-email-nm@ti.com>
References: <1455926991-15189-1-git-send-email-nm@ti.com>
Message-ID: <56C7BE28.2060606@roeck-us.net>

On 02/19/2016 04:09 PM, Nishanth Menon wrote:
> Thermal hook gpio_fan_get_cur_state is only interested in knowing
> the current speed index that was setup in the system, this is
> already available as part of fan_data->speed_index which is always
> set by set_fan_speed. Using get_fan_speed_index is useful when we
> have no idea about the fan speed configuration (for example during
> fan_ctrl_init).
>
> When thermal framework invokes
> gpio_fan_get_cur_state=>get_fan_speed_index via gpio_fan_get_cur_state
> especially in a polled configuration for thermal governor, we
> basically hog the i2c interface to the extent that other functions
> fail to get any traffic out :(.
>
> Instead, just provide the last state set in the driver - since the gpio
> fan driver is responsible for the fan state immaterial of override, the
> fan_data->speed_index should accurately reflect the state.
>
> Fixes: b5cf88e46bad ("(gpio-fan): Add thermal control hooks")
>
> Reported-by: Tony Lindgren <tony at atomide.com>
> Cc: Guenter Roeck <linux at roeck-us.net>
> Cc: Eduardo Valentin <edubezval at gmail.com>
> Signed-off-by: Nishanth Menon <nm at ti.com>
> ---

Applied.

Thanks,
Guenter

> Test logs from linus master  v4.5-rc4-137-g23300f657594
> Without fix: http://paste.ubuntu.org.cn/3948618
> With Fix: http://paste.ubuntu.org.cn/3948617
>
>   drivers/hwmon/gpio-fan.c | 7 +------
>   1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/hwmon/gpio-fan.c b/drivers/hwmon/gpio-fan.c
> index 82de3deeb18a..685568b1236d 100644
> --- a/drivers/hwmon/gpio-fan.c
> +++ b/drivers/hwmon/gpio-fan.c
> @@ -406,16 +406,11 @@ static int gpio_fan_get_cur_state(struct thermal_cooling_device *cdev,
>   				  unsigned long *state)
>   {
>   	struct gpio_fan_data *fan_data = cdev->devdata;
> -	int r;
>
>   	if (!fan_data)
>   		return -EINVAL;
>
> -	r = get_fan_speed_index(fan_data);
> -	if (r < 0)
> -		return r;
> -
> -	*state = r;
> +	*state = fan_data->speed_index;
>   	return 0;
>   }
>
>



From ray.jui at broadcom.com  Fri Feb 19 17:23:33 2016
From: ray.jui at broadcom.com (Ray Jui)
Date: Fri, 19 Feb 2016 17:23:33 -0800
Subject: [02/11] video: ARM CLCD: support DT signal inversion flags
In-Reply-To: <CACRpkdbGCidu_3qbTYf7WSoAhafU4Z5W0jDs4CGtH5XwSf14aA@mail.gmail.com>
References: <1454594660-7532-3-git-send-email-linus.walleij@linaro.org>
 <0cebf93a-ee0a-3637-3242-8aed266df091@broadcom.com>
 <CACRpkdbGCidu_3qbTYf7WSoAhafU4Z5W0jDs4CGtH5XwSf14aA@mail.gmail.com>
Message-ID: <ac0739e5-4339-7fc5-1179-73af722beb08@broadcom.com>

Hi Linus,

On 2/19/2016 12:46 AM, Linus Walleij wrote:
> On Wed, Feb 17, 2016 at 7:10 PM, Ray Jui <ray.jui at broadcom.com> wrote:
>
>> A somewhat related question, how do you see the CLKSEL bit in the TIM2
>> register will be supported in the future? There are some cases where the
>> CLKSEL bit needs to be set, and therefore the "CLCDCLK" instead of "HCLK"
>> reference clock source is selected.
>
> I think it's very simple:
>
> The DT node usually looks like so:
>
> display at 10120000 {
>         compatible = "arm,pl110", "arm,primecell";
> (...)
>         clocks = <&oscclk4>, <&pclk>;
>         clock-names = "clcd", "apb_pclk";
>
> Just add a custom attribute pointing to the
> reference clock in this array:
>
> clcd-reference-clock = <0>;
>
> If this is set to <1> "apb_pclk" (i.e. HCLK) is
> the reference, and that bit in TIM2 gets set.

This looks good!

>
> Do you have a system that needs this?
>

Yah, we have a system (Cygnus) that can either use the HCLK, or an 
external clock generated from a PLL. To get certain pixel clock 
frequencies (depending on the LCD panel we use), we need to use the 
external clock source with the PLL configured to a particular VCO frequency.

We have not enabled full LCD/video support on that platform in the 
mainline kernel, but we'll eventually get to it.

> Yours,
> Linus Walleij
>

Thanks,

Ray


From John.Youn at synopsys.com  Fri Feb 19 18:55:33 2016
From: John.Youn at synopsys.com (John Youn)
Date: Sat, 20 Feb 2016 02:55:33 +0000
Subject: [PATCH] usb: move usb_calc_bus_time into common code
References: <1455918064-410571-1-git-send-email-arnd@arndb.de>
 <Pine.LNX.4.44L0.1602191650570.1700-100000@iolanthe.rowland.org>
 <CAD=FV=VjgTUQR-Rw+LWXnNdZhruukaV-+LnXFqNRj-wpcvSJ4w@mail.gmail.com>
Message-ID: <2B3535C5ECE8B5419E3ECBE30077290901DC453B41@US01WEMBX2.internal.synopsys.com>

On 2/19/2016 2:48 PM, Doug Anderson wrote:
> Hi,
> 
> On Fri, Feb 19, 2016 at 1:52 PM, Alan Stern <stern at rowland.harvard.edu> wrote:
>> On Fri, 19 Feb 2016, Arnd Bergmann wrote:
>>
>>> The dwc2 dual-role USB controller driver has started calling
>>> usb_calc_bus_time, and does so regardless of whether it is
>>> being built as a host controller or gadget. In case all
>>
>> Out of curiosity...  Why does dwc2 need to calculate bus times when it
>> is in device mode?
> 
> Hoo boy.  it doesn't.  Nor does it need to properly set the even/odd
> frame in device mode.
> 
> Basically dwc2's "core.c" has a whole bunch of stuff in it that's host
> only and isn't guarded with any #ifdef.  ...yet that file is included
> in gadget-only builds.  It's a bit of a mess.  Take a gander at all of
> the "dwc2_hc_xxx" functions sitting in "drivers/usb/dwc2/core.c".
> 
> Long term that needs to be cleaned up, but such a cleanup is going to
> be a bit of churn so we'd need to schedule it for a time when not much
> else is going on (and presumably it should be done by John or in close
> coordination with him so it can get Acked / landed quickly to avoid
> conflicts?).  To do this we'd have to figure out why some things are
> in "core.c" and some in "hcd.c" and if it makes sense to move them all
> to "hcd.c" or if we need a new "core_hc.c" or something...  All of
> that design predates me.
> 

Yeah, that stuff has been bugging me for a while. I have a branch that
started a lot of clean-ups, but it's never been a great time to merge
it.

> In any case I guess we need a solution for right now, huh?
> 
> One terribly lame hack would be to just make a dummy no-op
> "dwc2_hc_set_even_odd_frame()" if host mode is disabled.  That doesn't
> really fix the root problem of lots of host mode code being compiled
> in a gadget-only driver.  It also adds an ugly "#ifdef".  ...but it
> does get around the current compile error.
> 
> 
> What do folks think?
> 

I think if we can fix it for -next in dwc2 by moving all host code out
of core then we should do it that way. I'll see if I can revive my
patches.

Regards,
John


From linux at roeck-us.net  Fri Feb 19 23:02:09 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Fri, 19 Feb 2016 23:02:09 -0800
Subject: [v9,4/5] iommu/mediatek: Add mt8173 IOMMU driver
In-Reply-To: <1455669974-1527-5-git-send-email-yong.wu@mediatek.com>
References: <1455669974-1527-5-git-send-email-yong.wu@mediatek.com>
Message-ID: <20160220070209.GA16577@roeck-us.net>

On Wed, Feb 17, 2016 at 08:46:13AM +0800, Yong Wu wrote:
> This patch adds support for mediatek m4u (MultiMedia Memory Management
> Unit).
> 
> Signed-off-by: Yong Wu <yong.wu at mediatek.com>
> Reviewed-by: Robin Murphy <robin.murphy at arm.com>
> 
> ---
> drivers/iommu/Kconfig     |  16 +
>  drivers/iommu/Makefile    |   1 +
>  drivers/iommu/mtk_iommu.c | 732 ++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 749 insertions(+)
>  create mode 100644 drivers/iommu/mtk_iommu.c
> 
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index a1e75cb..4922aa8 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -318,4 +318,20 @@ config S390_IOMMU
>  	help
>  	  Support for the IOMMU API for s390 PCI devices.
>  
> +config MTK_IOMMU
> +	bool "MTK IOMMU Support"
> +	depends on ARM || ARM64
> +	depends on ARCH_MEDIATEK || COMPILE_TEST
> +	select IOMMU_API
> +	select IOMMU_DMA
> +	select IOMMU_IO_PGTABLE_ARMV7S
> +	select MEMORY
> +	select MTK_SMI
> +	help
> +	  Support for the M4U on certain Mediatek SOCs. M4U is MultiMedia
> +	  Memory Management Unit. This option enables remapping of DMA memory
> +	  accesses for the multimedia subsystem.
> +
> +	  If unsure, say N here.
> +
>  endif # IOMMU_SUPPORT
> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> index 42fc0c2..44ae2e0 100644
> --- a/drivers/iommu/Makefile
> +++ b/drivers/iommu/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_INTEL_IOMMU) += intel-iommu.o
>  obj-$(CONFIG_INTEL_IOMMU_SVM) += intel-svm.o
>  obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
>  obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
> +obj-$(CONFIG_MTK_IOMMU) += mtk_iommu.o
>  obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
>  obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
>  obj-$(CONFIG_ROCKCHIP_IOMMU) += rockchip-iommu.o
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> new file mode 100644
> index 0000000..60fe97b
> --- /dev/null
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -0,0 +1,732 @@
> +/*
> + * Copyright (c) 2015-2016 MediaTek Inc.
> + * Author: Yong Wu <yong.wu at mediatek.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.
> + */
> +#include <linux/clk.h>
> +#include <linux/component.h>
> +#include <linux/dma-iommu.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/iommu.h>
> +#include <linux/iopoll.h>
> +#include <linux/list.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_iommu.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <soc/mediatek/smi.h>
> +#include <dt-bindings/memory/mt8173-larb-port.h>
> +

Some missing includes:

linux/bug.h
	for WARN_ON()
linux/device.h
	for dev_xxx() error messages, dev_get_drvdata(), etc.
linux/err.h
	for error functions (IS_ERR, error definitions)
linux/slab.h
	for kzalloc() etc.
linux/spinlock.h
	for spinlock functions
asm/barrier.h
	for wmb()

Guenter


From ard.biesheuvel at linaro.org  Sat Feb 20 00:20:05 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Sat, 20 Feb 2016 09:20:05 +0100
Subject: [PATCH v11 00/10] arm64,
 numa: Add numa support for arm64 platforms
In-Reply-To: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <CAKv+Gu8FRdif_WDZPqs7gHxXMu=6SqDd6A54dQc1KWuGwxpf0w@mail.gmail.com>

Hello David,

On 20 February 2016 at 02:13, David Daney <ddaney.cavm at gmail.com> wrote:
> From: David Daney <david.daney at cavium.com>
>
> v11:
>         - Dropped cleanup patches for other architectures, they will be
>           submitted as a separate set after more testing.
>
>         - Added patch set from Ard Biesheuvel that are needed to make
>           the whole thing actually work.  Previously this was a
>           separate set.
>

This series is out of date, unfortunately. The EFI init code is now
(as of v4.5-rc1) shared between ARM and arm64, which means that any
changes you make must be made on both sides. This applies to the split
between parsing the EFI dt nodes and performing the actual EFI init,
but also to the early_init_dt_add_memory_arch() changes. I am happy to
have a go at this, but first I need a clear statement from whoever
maintains that area that keeping memory nodes *just* for the
annotations (and otherwise ignore them) is the way forward (Rob?
Grant?)

Also, please drop the 6th patch. As i replied to Robert when he
reposted these patches, we need to honor the /reserved-memory node
rather than remove it. I will follow up with an updated
/reserved-memory node validation patch for the EFI stub once these
changes are in.


>         - Kconfig and other fixes and simplifications as suggested by Rob Herring.
>
>         - Rearranged, refactored and reordered so that we don't patch
>           new files multiple times.
>
>         - Summary:
>
>                 o 6 patches from Ard Biesheuvel to allow use of
>                   "memory" nodes with efi stub.
>
>                 o 2 patches to document and add of_numa.c
>
>                 o 1 patch to add arm64 NUMA support.
>
>                 o 1 patch to add NUMA balancing support for arm64.
>
> v10:
>         - Incorporated review comments from Rob Herring.
>         - Moved numa binding and implementation to devicetree core.
>         - Added cleanup patch to remove redundant NODE_DATA macro from asm header files
>         - Include numa balancing support for arm64 patch in this series.
>         - Fix tile build issue reported by the kbuild robot(patch 7)
>
> v9:     - Added cleanup patch to reuse and avoid redefinition of cpumask_of_pcibus
>           as suggested from Will Deacon and Bjorn Helgaas.
>           - Including patch to Make pci-host-generic driver numa aware.
>           - Incorporated comment from Shannon Zhao.
>
> v8:
>         - Incorporated review comments of Mark Rutland and Will Deacon.
>         - Added pci helper function and macro for numa.
>
> v7:
>         - managing numa memory mapping using memblock.
>         - Incorporated review comments of Mark Rutland.
>
> v6:
>         - defined and implemented the numa dt binding using
>         node property proximity and device node distance-map.
>         - renamed dt_numa to of_numa
>
> v5:
>         - created base verion of numa.c which creates dummy numa without using dt
>           on single socket platforms. Then added patches for dt support.
>         - Incorporated review comments from Hanjun Guo.
>
> v4:
> done changes as per Arnd review comments.
>
> v3:
> Added changes to support numa on arm64 based platforms.
> Tested these patches on cavium's multinode(2 node topology) platform.
> In this patchset, defined and implemented dt bindings for numa mapping
> for core and memory using device node property arm,associativity.
>
> v2:
> Defined and implemented numa map for memory, cores to node and
> proximity distance matrix of nodes.
>
> v1:
> Initial patchset to support numa on arm64 platforms.
>
> Note: 1. This patchset is tested for NUMA and without NUMA with dt
>         (both with and without NUMA bindings) on thunderx single
>         socket and dual socket boards.
>
>
> Ard Biesheuvel (6):
>   of/fdt: make generic early_init_dt_add_memory_arch() a weak alias
>   arm64: override generic version of early_init_dt_add_memory_arch()
>   efi: move FDT handling to separate object file
>   arm64/efi: move EFI /chosen node parsing before early FDT processing
>   arm64/efi: ignore DT memory nodes instead of removing them
>   arm64/efi: ignore DT memreserve entries instead of removing them
>
> Ganapatrao Kulkarni (4):
>   Documentation, dt, numa: dt bindings for NUMA.
>   dt, numa: Add NUMA dt binding implementation.
>   arm64, numa: Add NUMA support for arm64 platforms.
>   arm64, mm, numa: Add NUMA balancing support for arm64.
>
>  Documentation/devicetree/bindings/numa.txt | 272 +++++++++++++++++++
>  arch/arm64/Kconfig                         |  27 ++
>  arch/arm64/include/asm/efi.h               |   2 +
>  arch/arm64/include/asm/mmzone.h            |  12 +
>  arch/arm64/include/asm/numa.h              |  45 ++++
>  arch/arm64/include/asm/pgtable.h           |  15 ++
>  arch/arm64/include/asm/topology.h          |  10 +
>  arch/arm64/kernel/pci.c                    |  10 +
>  arch/arm64/kernel/setup.c                  |   7 +
>  arch/arm64/kernel/smp.c                    |   4 +
>  arch/arm64/mm/Makefile                     |   1 +
>  arch/arm64/mm/init.c                       |  46 +++-
>  arch/arm64/mm/mmu.c                        |   1 +
>  arch/arm64/mm/numa.c                       | 403 +++++++++++++++++++++++++++++
>  drivers/firmware/efi/Makefile              |   1 +
>  drivers/firmware/efi/arm-init.c            |  36 ++-
>  drivers/firmware/efi/efi-fdt.c             |  73 ++++++
>  drivers/firmware/efi/efi.c                 |  84 ------
>  drivers/firmware/efi/libstub/fdt.c         |  33 +--
>  drivers/of/Kconfig                         |   3 +
>  drivers/of/Makefile                        |   1 +
>  drivers/of/fdt.c                           |   7 +-
>  drivers/of/of_numa.c                       | 211 +++++++++++++++
>  include/linux/efi.h                        |   2 +-
>  include/linux/of.h                         |   9 +
>  include/linux/of_fdt.h                     |   1 +
>  26 files changed, 1178 insertions(+), 138 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/numa.txt
>  create mode 100644 arch/arm64/include/asm/mmzone.h
>  create mode 100644 arch/arm64/include/asm/numa.h
>  create mode 100644 arch/arm64/mm/numa.c
>  create mode 100644 drivers/firmware/efi/efi-fdt.c
>  create mode 100644 drivers/of/of_numa.c
>
> --
> 1.8.3.1
>


From ssantosh at kernel.org  Sat Feb 20 01:09:10 2016
From: ssantosh at kernel.org (Santosh Shilimkar)
Date: Sat, 20 Feb 2016 01:09:10 -0800
Subject: [GIT PULL] ARM: Keystone DTS for 4.6 
Message-ID: <1455959351-11524-1-git-send-email-ssantosh@kernel.org>

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone_dts_for_4.6

for you to fetch changes up to 5f67dae54262adeb0bfd98fa4c7a9b62548c9f25:

  ARM: dts: keystone: Add minimum support for K2G evm (2016-02-20 00:56:06 -0800)

----------------------------------------------------------------
ARM: DTS: Add new bindings for K2G and the K2G evm

K2G SoC family is the newest version of the Keystone family of processors.

The technical reference manual for K2G can be found here:
http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf

----------------------------------------------------------------
Nishanth Menon (1):
      ARM: keystone: Create new binding for K2G SoC

Vitaly Andrianov (2):
      ARM: dts: keystone: Add Initial DT support for TI K2G SoC family
      ARM: dts: keystone: Add minimum support for K2G evm

 .../devicetree/bindings/arm/keystone/keystone.txt  |  5 ++
 arch/arm/boot/dts/Makefile                         |  3 +-
 arch/arm/boot/dts/k2g-evm.dts                      | 32 ++++++++
 arch/arm/boot/dts/k2g.dtsi                         | 89 ++++++++++++++++++++++
 arch/arm/mach-keystone/keystone.c                  |  1 +
 5 files changed, 129 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/k2g-evm.dts
 create mode 100644 arch/arm/boot/dts/k2g.dtsi


From tiffany.lin at mediatek.com  Sat Feb 20 01:11:20 2016
From: tiffany.lin at mediatek.com (tiffany lin)
Date: Sat, 20 Feb 2016 17:11:20 +0800
Subject: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2
 Video Encoder Driver
In-Reply-To: <56C2D371.9090805@xs4all.nl>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
 <56C1B4AF.1030207@xs4all.nl> <1455604653.19396.68.camel@mtksdaap41>
 <56C2D371.9090805@xs4all.nl>
Message-ID: <1455959480.12533.11.camel@mtksdaap41>

Hi Hans,

On Tue, 2016-02-16 at 08:44 +0100, Hans Verkuil wrote:
> On 02/16/2016 07:37 AM, tiffany lin wrote:
> >>> +
> >>> +const struct v4l2_ioctl_ops mtk_venc_ioctl_ops = {
> >>> +	.vidioc_streamon		= v4l2_m2m_ioctl_streamon,
> >>> +	.vidioc_streamoff		= v4l2_m2m_ioctl_streamoff,
> >>> +
> >>> +	.vidioc_reqbufs			= v4l2_m2m_ioctl_reqbufs,
> >>> +	.vidioc_querybuf		= v4l2_m2m_ioctl_querybuf,
> >>> +	.vidioc_qbuf			= vidioc_venc_qbuf,
> >>> +	.vidioc_dqbuf			= vidioc_venc_dqbuf,
> >>> +
> >>> +	.vidioc_querycap		= vidioc_venc_querycap,
> >>> +	.vidioc_enum_fmt_vid_cap_mplane = vidioc_enum_fmt_vid_cap_mplane,
> >>> +	.vidioc_enum_fmt_vid_out_mplane = vidioc_enum_fmt_vid_out_mplane,
> >>> +	.vidioc_enum_framesizes		= vidioc_enum_framesizes,
> >>> +
> >>> +	.vidioc_try_fmt_vid_cap_mplane	= vidioc_try_fmt_vid_cap_mplane,
> >>> +	.vidioc_try_fmt_vid_out_mplane	= vidioc_try_fmt_vid_out_mplane,
> >>> +	.vidioc_expbuf			= v4l2_m2m_ioctl_expbuf,
> >>
> >> Please add vidioc_create_bufs and vidioc_prepare_buf as well.
> >>
> > 
> > Currently we do not support these use cases, do we need to add
> > vidioc_create_bufs and vidioc_prepare_buf now?
> 
> I would suggest you do. The vb2 framework gives it (almost) for free.
> prepare_buf is completely free (just add the helper) and create_bufs
> needs a few small changes in the queue_setup function, that's all.
> 
After try to add vidioc_create_bufs directly using
vb2_ioctl_create_bufs, it will have problem in 
	int res = vb2_verify_memory_type(vdev->queue, p->memory,
			p->format.type);
We do not init our video_device queue in device probe function.

Our vb2_queues for OUTPUT and CAPTURE are initialized in
v4l2_m2m_ctx_init when ctx instance open.
What is queue in video_device for?
If we should init vdev->queue in probe function, this queue format
should be CAPTURE queue or OUTPUT queue?

best regards,
Tiffany

> > 
> > 
> >>> +	.vidioc_subscribe_event		= v4l2_ctrl_subscribe_event,
> >>> +	.vidioc_unsubscribe_event	= v4l2_event_unsubscribe,
> >>> +
> >>> +	.vidioc_s_parm			= vidioc_venc_s_parm,
> >>> +
> >>> +	.vidioc_s_fmt_vid_cap_mplane	= vidioc_venc_s_fmt,
> >>> +	.vidioc_s_fmt_vid_out_mplane	= vidioc_venc_s_fmt,
> >>> +
> >>> +	.vidioc_g_fmt_vid_cap_mplane	= vidioc_venc_g_fmt,
> >>> +	.vidioc_g_fmt_vid_out_mplane	= vidioc_venc_g_fmt,
> >>> +
> >>> +	.vidioc_g_selection		= vidioc_venc_g_s_selection,
> >>> +	.vidioc_s_selection		= vidioc_venc_g_s_selection,
> >>> +};
> 
> <snip>
> 
> >>> +int mtk_vcodec_enc_queue_init(void *priv, struct vb2_queue *src_vq,
> >>> +			   struct vb2_queue *dst_vq)
> >>> +{
> >>> +	struct mtk_vcodec_ctx *ctx = priv;
> >>> +	int ret;
> >>> +
> >>> +	src_vq->type		= V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
> >>> +	src_vq->io_modes	= VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
> >>
> >> I recomment dropping VB2_USERPTR. That only makes sense for scatter-gather dma,
> >> and you use physically contiguous DMA.
> >>
> > Now our userspace app use VB2_USERPTR. I need to check if we could drop
> > VB2_USERPTR.
> > We use src_vq->mem_ops = &vb2_dma_contig_memops;
> > And there are
> > 	.get_userptr	= vb2_dc_get_userptr,
> > 	.put_userptr	= vb2_dc_put_userptr,
> > I was confused why it only make sense for scatter-gather.
> > Could you kindly explain more?
> 
> VB2_USERPTR indicates that the application can use malloc to allocate buffers
> and pass those to the driver. Since malloc uses virtual memory the physical
> memory is scattered all over. And the first page typically does not start at
> the beginning of the page but at a random offset.
> 
> To support that the DMA generally has to be able to do scatter-gather.
> 
> Now, where things get ugly is that a hack was added to the USERPTR support where
> apps could pass a pointer to physically contiguous memory as a user pointer. This
> was a hack for embedded systems that preallocated a pool of buffers and needed to
> pass those pointers around somehow. So the dma-contig USERPTR support is for that
> 'feature'. If you try to pass a malloc()ed buffer to a dma-contig driver it will
> reject it. One big problem is that this specific hack isn't signaled anywhere, so
> applications have no way of knowing if the USERPTR support is the proper version
> or the hack where physically contiguous memory is expected.
> 
> This hack has been replaced with DMABUF which is the proper way of passing buffers
> around.
> 
> New dma-contig drivers should not use that old hack anymore. Use dmabuf to pass
> external buffers around.
> 
> How do you use it in your app? With malloc()ed buffers? Or with 'special' pointers
> to physically contiguous buffers?
> 
> > 
> >>> +	src_vq->drv_priv	= ctx;
> >>> +	src_vq->buf_struct_size = sizeof(struct mtk_video_enc_buf);
> >>> +	src_vq->ops		= &mtk_venc_vb2_ops;
> >>> +	src_vq->mem_ops		= &vb2_dma_contig_memops;
> >>> +	src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
> >>> +	src_vq->lock = &ctx->dev->dev_mutex;
> >>> +
> >>> +	ret = vb2_queue_init(src_vq);
> >>> +	if (ret)
> >>> +		return ret;
> >>> +
> >>> +	dst_vq->type		= V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
> >>> +	dst_vq->io_modes	= VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
> >>> +	dst_vq->drv_priv	= ctx;
> >>> +	dst_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
> >>> +	dst_vq->ops		= &mtk_venc_vb2_ops;
> >>> +	dst_vq->mem_ops		= &vb2_dma_contig_memops;
> >>> +	dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
> >>> +	dst_vq->lock = &ctx->dev->dev_mutex;
> >>> +
> >>> +	return vb2_queue_init(dst_vq);
> >>> +}
> 
> Regards,
> 
> 	Hans
> 




From hverkuil at xs4all.nl  Sat Feb 20 01:18:24 2016
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Sat, 20 Feb 2016 10:18:24 +0100
Subject: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video
 Encoder Driver
In-Reply-To: <1455959480.12533.11.camel@mtksdaap41>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
 <56C1B4AF.1030207@xs4all.nl> <1455604653.19396.68.camel@mtksdaap41>
 <56C2D371.9090805@xs4all.nl> <1455959480.12533.11.camel@mtksdaap41>
Message-ID: <56C82F60.4060304@xs4all.nl>

On 02/20/2016 10:11 AM, tiffany lin wrote:
> Hi Hans,
> 
> On Tue, 2016-02-16 at 08:44 +0100, Hans Verkuil wrote:
>> On 02/16/2016 07:37 AM, tiffany lin wrote:
>>>>> +
>>>>> +const struct v4l2_ioctl_ops mtk_venc_ioctl_ops = {
>>>>> +	.vidioc_streamon		= v4l2_m2m_ioctl_streamon,
>>>>> +	.vidioc_streamoff		= v4l2_m2m_ioctl_streamoff,
>>>>> +
>>>>> +	.vidioc_reqbufs			= v4l2_m2m_ioctl_reqbufs,
>>>>> +	.vidioc_querybuf		= v4l2_m2m_ioctl_querybuf,
>>>>> +	.vidioc_qbuf			= vidioc_venc_qbuf,
>>>>> +	.vidioc_dqbuf			= vidioc_venc_dqbuf,
>>>>> +
>>>>> +	.vidioc_querycap		= vidioc_venc_querycap,
>>>>> +	.vidioc_enum_fmt_vid_cap_mplane = vidioc_enum_fmt_vid_cap_mplane,
>>>>> +	.vidioc_enum_fmt_vid_out_mplane = vidioc_enum_fmt_vid_out_mplane,
>>>>> +	.vidioc_enum_framesizes		= vidioc_enum_framesizes,
>>>>> +
>>>>> +	.vidioc_try_fmt_vid_cap_mplane	= vidioc_try_fmt_vid_cap_mplane,
>>>>> +	.vidioc_try_fmt_vid_out_mplane	= vidioc_try_fmt_vid_out_mplane,
>>>>> +	.vidioc_expbuf			= v4l2_m2m_ioctl_expbuf,
>>>>
>>>> Please add vidioc_create_bufs and vidioc_prepare_buf as well.
>>>>
>>>
>>> Currently we do not support these use cases, do we need to add
>>> vidioc_create_bufs and vidioc_prepare_buf now?
>>
>> I would suggest you do. The vb2 framework gives it (almost) for free.
>> prepare_buf is completely free (just add the helper) and create_bufs
>> needs a few small changes in the queue_setup function, that's all.
>>
> After try to add vidioc_create_bufs directly using
> vb2_ioctl_create_bufs, it will have problem in 

This is a m2m device, so you should use the m2m variant of this:
v4l2_m2m_ioctl_create_bufs

That should solve this problem.

Ditto for prepare_buf: you need to use v4l2_m2m_ioctl_prepare_buf.

Regards,

	Hans


From michael at amarulasolutions.com  Sat Feb 20 02:20:48 2016
From: michael at amarulasolutions.com (Michael Trimarchi)
Date: Sat, 20 Feb 2016 11:20:48 +0100
Subject: [PATCH 0/4] Add support for Engicam IMX6UL module
Message-ID: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>

Thi patch series add the support for Engicam IMXUL product

https://community.freescale.com/docs/DOC-328428

Based on Freescale? i.MX 6UltraLite processor, a high performance,
ultra-efficient processor family featuring an advanced implementation
of a single ARM? Cortex?-A7 core, which operates at speeds up to 528 MHz.

The new ENGICAM GEA M6UL module is suitable for cost effective HMI
applications requiring high performance CPU.

Michael Trimarchi (4):
  ARM: dts: imx6ul: Add flexcan1 and flexcan2 support
  ARM: dts: imx6ul: Add LCDIF support
  ARM: dts: imx6ul: Add GPMI nand controller support
  ARM: dts: imx6ul-geam: Add Engicam IMX6UL GEA M6UL initial support

 arch/arm/boot/dts/Makefile             |   3 +-
 arch/arm/boot/dts/imx6ul-geam-kit.dts  | 102 +++++++++
 arch/arm/boot/dts/imx6ul-geam.dtsi     | 371 +++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/imx6ul.dtsi          |  68 ++++++
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |  10 +
 drivers/mtd/nand/gpmi-nand/gpmi-nand.h |   6 +-
 6 files changed, 557 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6ul-geam-kit.dts
 create mode 100644 arch/arm/boot/dts/imx6ul-geam.dtsi

-- 
2.7.0



From michael at amarulasolutions.com  Sat Feb 20 02:20:49 2016
From: michael at amarulasolutions.com (Michael Trimarchi)
Date: Sat, 20 Feb 2016 11:20:49 +0100
Subject: [PATCH 1/4] ARM: dts: imx6ul: Add flexcan1 and flexcan2 support
In-Reply-To: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
Message-ID: <1455963652-24618-2-git-send-email-michael@amarulasolutions.com>

Add support for FLEXCAN1 and FLEXCAN2.

Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
---
 arch/arm/boot/dts/imx6ul.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 99b6465..cd32d1d 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -14,6 +14,8 @@
 
 / {
 	aliases {
+		can0 = &flexcan1;
+		can1 = &flexcan2;
 		ethernet0 = &fec1;
 		ethernet1 = &fec2;
 		gpio0 = &gpio1;
@@ -234,6 +236,28 @@
 					clock-names = "ipg", "per";
 					status = "disabled";
 				};
+
+				flexcan1: can at 02090000 {
+					compatible = "fsl,imx6ul-flexcan", "fsl,imx6q-flexcan";
+					reg = <0x02090000 0x4000>;
+					interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clks IMX6UL_CLK_CAN1_IPG>,
+						 <&clks IMX6UL_CLK_CAN1_SERIAL>;
+					clock-names = "ipg", "per";
+					stop-mode = <&gpr 0x10 1 0x10 17>;
+					status = "disabled";
+				};
+
+				flexcan2: can at 02094000 {
+					compatible = "fsl,imx6ul-flexcan", "fsl,imx6q-flexcan";
+					reg = <0x02094000 0x4000>;
+					interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clks IMX6UL_CLK_CAN2_IPG>,
+						 <&clks IMX6UL_CLK_CAN2_SERIAL>;
+					clock-names = "ipg", "per";
+					stop-mode = <&gpr 0x10 2 0x10 18>;
+					status = "disabled";
+				};
 			};
 
 			gpt1: gpt at 02098000 {
-- 
2.7.0



From michael at amarulasolutions.com  Sat Feb 20 02:20:51 2016
From: michael at amarulasolutions.com (Michael Trimarchi)
Date: Sat, 20 Feb 2016 11:20:51 +0100
Subject: [PATCH 3/4] ARM: dts: imx6ul: Add GPMI nand controller support
In-Reply-To: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
Message-ID: <1455963652-24618-4-git-send-email-michael@amarulasolutions.com>

Add support for GPMI nand controller.

Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
---
 arch/arm/boot/dts/imx6ul.dtsi          | 33 +++++++++++++++++++++++++++++++++
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 10 ++++++++++
 drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  6 ++++--
 3 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index f369fa4..42b0a29 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -142,6 +142,39 @@
 			reg = <0x00900000 0x20000>;
 		};
 
+		dma_apbh: dma-apbh at 01804000 {
+			compatible = "fsl,imx6ul-dma-apbh", "fsl,imx28-dma-apbh";
+			reg = <0x01804000 0x2000>;
+			interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "gpmi0", "gpmi1", "gpmi2", "gpmi3";
+			#dma-cells = <1>;
+			dma-channels = <4>;
+			clocks = <&clks IMX6UL_CLK_APBHDMA>;
+		};
+
+		gpmi: gpmi-nand at 01806000 {
+			compatible = "fsl,imx6ul-gpmi-nand";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0x01806000 0x2000>, <0x01808000 0x4000>;
+			reg-names = "gpmi-nand", "bch";
+			interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "bch";
+			clocks = <&clks IMX6UL_CLK_GPMI_IO>,
+				 <&clks IMX6UL_CLK_GPMI_APB>,
+				 <&clks IMX6UL_CLK_GPMI_BCH>,
+				 <&clks IMX6UL_CLK_GPMI_BCH_APB>,
+				 <&clks IMX6UL_CLK_PER_BCH>;
+			clock-names = "gpmi_io", "gpmi_apb", "gpmi_bch",
+				      "gpmi_bch_apb", "per1_bch";
+			dmas = <&dma_apbh 0>;
+			dma-names = "rx-tx";
+			status = "disabled";
+		};
+
 		aips1: aips-bus at 02000000 {
 			compatible = "fsl,aips-bus", "simple-bus";
 			#address-cells = <1>;
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 235ddcb..b7528a1 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -77,6 +77,12 @@ static const struct gpmi_devdata gpmi_devdata_imx6sx = {
 	.max_chain_delay = 12,
 };
 
+static const struct gpmi_devdata gpmi_devdata_imx6ul = {
+	.type = IS_MX6UL,
+	.bch_max_ecc_strength = 40,
+	.max_chain_delay = 12,
+};
+
 static irqreturn_t bch_irq(int irq, void *cookie)
 {
 	struct gpmi_nand_data *this = cookie;
@@ -1975,7 +1981,11 @@ static const struct of_device_id gpmi_nand_id_table[] = {
 	}, {
 		.compatible = "fsl,imx6sx-gpmi-nand",
 		.data = &gpmi_devdata_imx6sx,
+	}, {
+		.compatible = "fsl,imx6ul-gpmi-nand",
+		.data = &gpmi_devdata_imx6ul,
 	}, {}
+
 };
 MODULE_DEVICE_TABLE(of, gpmi_nand_id_table);
 
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
index 4e49a1f..c5fa52a 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
@@ -123,7 +123,8 @@ enum gpmi_type {
 	IS_MX23,
 	IS_MX28,
 	IS_MX6Q,
-	IS_MX6SX
+	IS_MX6SX,
+	IS_MX6UL,
 };
 
 struct gpmi_devdata {
@@ -305,6 +306,7 @@ void gpmi_copy_bits(u8 *dst, size_t dst_bit_off,
 #define GPMI_IS_MX28(x)		((x)->devdata->type == IS_MX28)
 #define GPMI_IS_MX6Q(x)		((x)->devdata->type == IS_MX6Q)
 #define GPMI_IS_MX6SX(x)	((x)->devdata->type == IS_MX6SX)
+#define GPMI_IS_MX6UL(x)	((x)->devdata->type == IS_MX6UL)
 
-#define GPMI_IS_MX6(x)		(GPMI_IS_MX6Q(x) || GPMI_IS_MX6SX(x))
+#define GPMI_IS_MX6(x)		(GPMI_IS_MX6Q(x) || GPMI_IS_MX6SX(x) || GPMI_IS_MX6UL(x))
 #endif
-- 
2.7.0



From michael at amarulasolutions.com  Sat Feb 20 02:20:50 2016
From: michael at amarulasolutions.com (Michael Trimarchi)
Date: Sat, 20 Feb 2016 11:20:50 +0100
Subject: [PATCH 2/4] ARM: dts: imx6ul: Add LCDIF support
In-Reply-To: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
Message-ID: <1455963652-24618-3-git-send-email-michael@amarulasolutions.com>

Add support for LCDIF.

Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
---
 arch/arm/boot/dts/imx6ul.dtsi | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index cd32d1d..f369fa4 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -696,6 +696,17 @@
 				reg = <0x021b0000 0x4000>;
 			};
 
+			lcdif: lcdif at 021c8000 {
+				compatible = "fsl,imx6ul-lcdif", "fsl,imx28-lcdif";
+				reg = <0x021c8000 0x4000>;
+				interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&clks IMX6UL_CLK_LCDIF_PIX>,
+					<&clks IMX6UL_CLK_LCDIF_APB>,
+					<&clks IMX6UL_CLK_DUMMY>;
+				clock-names = "pix", "axi", "disp_axi";
+				status = "disabled";
+			};
+
 			qspi: qspi at 021e0000 {
 				#address-cells = <1>;
 				#size-cells = <0>;
-- 
2.7.0



From michael at amarulasolutions.com  Sat Feb 20 02:20:52 2016
From: michael at amarulasolutions.com (Michael Trimarchi)
Date: Sat, 20 Feb 2016 11:20:52 +0100
Subject: [PATCH 4/4] ARM: dts: imx6ul-geam: Add Engicam IMX6UL GEA M6UL
 initial support
In-Reply-To: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
Message-ID: <1455963652-24618-5-git-send-email-michael@amarulasolutions.com>

http://www.engicam.com/prodotti/embedded/som/sodimm/gea-m6ul

Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
---
 arch/arm/boot/dts/Makefile            |   3 +-
 arch/arm/boot/dts/imx6ul-geam-kit.dts | 102 ++++++++++
 arch/arm/boot/dts/imx6ul-geam.dtsi    | 371 ++++++++++++++++++++++++++++++++++
 3 files changed, 475 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/imx6ul-geam-kit.dts
 create mode 100644 arch/arm/boot/dts/imx6ul-geam.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..4f6965a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -358,7 +358,8 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
 	imx6sx-sdb-reva.dtb \
 	imx6sx-sdb.dtb
 dtb-$(CONFIG_SOC_IMX6UL) += \
-	imx6ul-14x14-evk.dtb
+	imx6ul-14x14-evk.dtb \
+	imx6ul-geam-kit.dtb
 dtb-$(CONFIG_SOC_IMX7D) += \
 	imx7d-cl-som-imx7.dtb \
 	imx7d-sbc-imx7.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-geam-kit.dts b/arch/arm/boot/dts/imx6ul-geam-kit.dts
new file mode 100644
index 0000000..9ba4a66
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-geam-kit.dts
@@ -0,0 +1,102 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License
+ *     version 2 as published by the Free Software Foundation.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "imx6ul-geam.dtsi"
+
+/ {
+	model = "Engicam GEAM6UL";
+	compatible = "engicam,imx6ul-geam", "fsl,imx6ul";
+};
+
+&flexcan1 {
+	status = "okay";
+};
+
+&flexcan2 {
+	status = "okay";
+};
+
+&lcdif {
+	display = <&display0>;
+	status = "okay";
+
+	display0: display {
+		bits-per-pixel = <16>;
+		bus-width = <18>;
+
+		display-timings {
+			native-mode = <&timing0>;
+			timing0: timing0 {
+				clock-frequency = <28000000>;
+				hactive = <800>;
+				vactive = <480>;
+				hfront-porch = <30>;
+				hback-porch = <30>;
+				hsync-len = <64>;
+				vback-porch = <5>;
+				vfront-porch = <5>;
+				vsync-len = <20>;
+
+				hsync-active = <0>;
+				vsync-active = <0>;
+				de-active = <1>;
+				pixelclk-active = <0>;
+			};
+		};
+	};
+};
+
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	status = "okay";
+};
+
+&tsc {
+	measure_delay_time = <0x1ffff>;
+	pre_charge_time = <0x1fff>;
+	status = "okay";
+};
+
diff --git a/arch/arm/boot/dts/imx6ul-geam.dtsi b/arch/arm/boot/dts/imx6ul-geam.dtsi
new file mode 100644
index 0000000..738f420
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-geam.dtsi
@@ -0,0 +1,371 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License
+ *     version 2 as published by the Free Software Foundation.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "imx6ul.dtsi"
+
+/ {
+	memory {
+		reg = <0x80000000 0x20000000>;
+	};
+
+	chosen {
+		stdout-path = &uart1;
+	};
+
+	reg_1p8v: regulator-1p8v {
+		compatible = "regulator-fixed";
+		regulator-name = "1P8V";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
+
+	reg_3p3v: regulator-3p3v {
+		compatible = "regulator-fixed";
+		regulator-name = "3P3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
+};
+
+&flexcan1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan1>;
+	xceiver-supply = <&reg_3p3v>;
+};
+
+&flexcan2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan2>;
+	xceiver-supply = <&reg_3p3v>;
+};
+
+&fec1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet1>;
+	phy-mode = "rmii";
+	phy-handle = <&ethphy0>;
+	status = "okay";
+};
+
+&fec2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet2>;
+	phy-mode = "rmii";
+	phy-handle = <&ethphy1>;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ethphy0: ethernet-phy at 0 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <0>;
+		};
+
+		ethphy1: ethernet-phy at 1 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <1>;
+		};
+	};
+};
+
+&gpmi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_gpmi_nand>;
+	status = "okay";
+	nand-on-flash-bbt;
+};
+
+&lcdif {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lcdif_dat
+		     &pinctrl_lcdif_ctrl>;
+	display = <&display0>;
+};
+
+&tsc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_tsc>;
+	xnur-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>;
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2>;
+	status = "okay";
+};
+
+&usbotg1 {
+	dr_mode = "peripheral";
+	status = "okay";
+};
+
+&usbotg2 {
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usdhc1 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+	bus-width = <4>;
+	cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
+	no-1-8-v;
+	status = "okay";
+};
+
+&i2c1 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1>;
+	status = "okay";
+};
+
+&i2c2 {
+	clock_frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+};
+
+&iomuxc {
+
+	pinctrl_enet1: enet1grp {
+		fsl,pins = <
+			MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN	0x1b0b0
+			MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00	0x1b0b0
+			MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01	0x1b0b0
+			MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN	0x1b0b0
+			MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00	0x1b0b0
+			MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01	0x1b0b0
+			MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1	0x4001b031
+		>;
+	};
+
+	pinctrl_enet2: enet2grp {
+		fsl,pins = <
+			MX6UL_PAD_GPIO1_IO07__ENET2_MDC		0x1b0b0
+			MX6UL_PAD_GPIO1_IO06__ENET2_MDIO	0x1b0b0
+			MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN	0x1b0b0
+			MX6UL_PAD_ENET2_RX_ER__GPIO2_IO15	0x1b0b0		/* ENET_nRST */
+			MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00	0x1b0b0
+			MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01	0x1b0b0
+			MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN	0x1b0b0
+			MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00	0x1b0b0
+			MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01	0x1b0b0
+			MX6UL_PAD_GPIO1_IO05__ENET2_REF_CLK2	0x4001b031
+		>;
+	};
+
+	pinctrl_flexcan1: flexcan1grp {
+		fsl,pins = <
+			MX6UL_PAD_UART3_RTS_B__FLEXCAN1_RX	0x1b020
+			MX6UL_PAD_UART3_CTS_B__FLEXCAN1_TX	0x1b020
+		>;
+	};
+
+	pinctrl_flexcan2: flexcan2grp{
+		fsl,pins = <
+			MX6UL_PAD_UART2_RTS_B__FLEXCAN2_RX	0x1b020
+			MX6UL_PAD_UART2_CTS_B__FLEXCAN2_TX	0x1b020
+		>;
+	};
+
+	pinctrl_gpmi_nand: gpmi-nand {
+		fsl,pins = <
+			MX6UL_PAD_NAND_CLE__RAWNAND_CLE         0xb0b1
+			MX6UL_PAD_NAND_ALE__RAWNAND_ALE         0xb0b1
+			MX6UL_PAD_NAND_WP_B__RAWNAND_WP_B       0xb0b1
+			MX6UL_PAD_NAND_READY_B__RAWNAND_READY_B 0xb000
+			MX6UL_PAD_NAND_CE0_B__RAWNAND_CE0_B     0xb0b1
+			MX6UL_PAD_NAND_RE_B__RAWNAND_RE_B       0xb0b1
+			MX6UL_PAD_NAND_WE_B__RAWNAND_WE_B       0xb0b1
+			MX6UL_PAD_NAND_DATA00__RAWNAND_DATA00   0xb0b1
+			MX6UL_PAD_NAND_DATA01__RAWNAND_DATA01   0xb0b1
+			MX6UL_PAD_NAND_DATA02__RAWNAND_DATA02   0xb0b1
+			MX6UL_PAD_NAND_DATA03__RAWNAND_DATA03   0xb0b1
+			MX6UL_PAD_NAND_DATA04__RAWNAND_DATA04   0xb0b1
+			MX6UL_PAD_NAND_DATA05__RAWNAND_DATA05   0xb0b1
+			MX6UL_PAD_NAND_DATA06__RAWNAND_DATA06   0xb0b1
+			MX6UL_PAD_NAND_DATA07__RAWNAND_DATA07   0xb0b1
+		>;
+	};
+
+	pinctrl_i2c1: i2c1grp {
+		fsl,pins = <
+			MX6UL_PAD_UART4_TX_DATA__I2C1_SCL 0x4001b8b0
+			MX6UL_PAD_UART4_RX_DATA__I2C1_SDA 0x4001b8b0
+		>;
+	};
+
+	pinctrl_i2c2: i2c2grp {
+			fsl,pins = <
+			MX6UL_PAD_UART5_TX_DATA__I2C2_SCL 0x4001b8b0
+			MX6UL_PAD_UART5_RX_DATA__I2C2_SDA 0x4001b8b0
+		>;
+	};
+
+	pinctrl_lcdif_ctrl: lcdifctrlgrp {
+		fsl,pins = <
+			MX6UL_PAD_LCD_CLK__LCDIF_CLK	    0x79
+			MX6UL_PAD_LCD_ENABLE__LCDIF_ENABLE  0x79
+			MX6UL_PAD_LCD_HSYNC__LCDIF_HSYNC    0x79
+			MX6UL_PAD_LCD_VSYNC__LCDIF_VSYNC    0x79
+		>;
+	};
+
+	pinctrl_lcdif_dat: lcdifdatgrp {
+		fsl,pins = <
+			MX6UL_PAD_LCD_DATA00__LCDIF_DATA00  0x79
+			MX6UL_PAD_LCD_DATA01__LCDIF_DATA01  0x79
+			MX6UL_PAD_LCD_DATA02__LCDIF_DATA02  0x79
+			MX6UL_PAD_LCD_DATA03__LCDIF_DATA03  0x79
+			MX6UL_PAD_LCD_DATA04__LCDIF_DATA04  0x79
+			MX6UL_PAD_LCD_DATA05__LCDIF_DATA05  0x79
+			MX6UL_PAD_LCD_DATA06__LCDIF_DATA06  0x79
+			MX6UL_PAD_LCD_DATA07__LCDIF_DATA07  0x79
+			MX6UL_PAD_LCD_DATA08__LCDIF_DATA08  0x79
+			MX6UL_PAD_LCD_DATA09__LCDIF_DATA09  0x79
+			MX6UL_PAD_LCD_DATA10__LCDIF_DATA10  0x79
+			MX6UL_PAD_LCD_DATA11__LCDIF_DATA11  0x79
+			MX6UL_PAD_LCD_DATA12__LCDIF_DATA12  0x79
+			MX6UL_PAD_LCD_DATA13__LCDIF_DATA13  0x79
+			MX6UL_PAD_LCD_DATA14__LCDIF_DATA14  0x79
+			MX6UL_PAD_LCD_DATA15__LCDIF_DATA15  0x79
+			MX6UL_PAD_LCD_DATA16__LCDIF_DATA16  0x79
+			MX6UL_PAD_LCD_DATA17__LCDIF_DATA17  0x79
+		>;
+	};
+
+	pinctrl_uart1: uart1grp {
+		fsl,pins = <
+			MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+			MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+		>;
+	};
+
+	pinctrl_uart2: uart2grp {
+		fsl,pins = <
+			MX6UL_PAD_UART2_TX_DATA__UART2_DCE_TX	0x1b0b1
+			MX6UL_PAD_UART2_RX_DATA__UART2_DCE_RX	0x1b0b1
+			MX6UL_PAD_UART3_RX_DATA__UART2_DCE_RTS	0x1b0b1
+			MX6UL_PAD_UART3_TX_DATA__UART2_DCE_CTS	0x1b0b1
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			MX6UL_PAD_SD1_CMD__USDHC1_CMD     0x17059
+			MX6UL_PAD_SD1_CLK__USDHC1_CLK     0x10059
+			MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+			MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+			MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+			MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+		>;
+	};
+
+	pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+		fsl,pins = <
+			MX6UL_PAD_SD1_CMD__USDHC1_CMD     0x170b9
+			MX6UL_PAD_SD1_CLK__USDHC1_CLK     0x100b9
+			MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170b9
+			MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170b9
+			MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170b9
+			MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170b9
+		>;
+	};
+
+	pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+		fsl,pins = <
+			MX6UL_PAD_SD1_CMD__USDHC1_CMD     0x170f9
+			MX6UL_PAD_SD1_CLK__USDHC1_CLK     0x100f9
+			MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170f9
+			MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170f9
+			MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170f9
+			MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170f9
+		>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX6UL_PAD_CSI_VSYNC__USDHC2_CLK     0x17070
+			MX6UL_PAD_CSI_HSYNC__USDHC2_CMD     0x10070
+			MX6UL_PAD_CSI_DATA00__USDHC2_DATA0  0x17070
+			MX6UL_PAD_CSI_DATA01__USDHC2_DATA1  0x17070
+			MX6UL_PAD_CSI_DATA02__USDHC2_DATA2  0x17070
+			MX6UL_PAD_CSI_DATA03__USDHC2_DATA3  0x17070
+		>;
+	};
+
+	pinctrl_spi4: spi4grp {
+		fsl,pins = <
+			MX6UL_PAD_BOOT_MODE0__GPIO5_IO10	0x70a1
+			MX6UL_PAD_BOOT_MODE1__GPIO5_IO11	0x70a1
+			MX6UL_PAD_SNVS_TAMPER7__GPIO5_IO07	0x70a1
+			MX6UL_PAD_SNVS_TAMPER8__GPIO5_IO08	0x80000000
+		>;
+	};
+
+	pinctrl_tsc: tscgrp {
+		fsl,pin = <
+			MX6UL_PAD_GPIO1_IO01__GPIO1_IO01	0xb0
+			MX6UL_PAD_GPIO1_IO02__GPIO1_IO02	0xb0
+			MX6UL_PAD_GPIO1_IO03__GPIO1_IO03	0xb0
+			MX6UL_PAD_GPIO1_IO04__GPIO1_IO04	0xb0
+		>;
+	};
+};
-- 
2.7.0



From robert.richter at caviumnetworks.com  Sat Feb 20 02:39:59 2016
From: robert.richter at caviumnetworks.com (Robert Richter)
Date: Sat, 20 Feb 2016 11:39:59 +0100
Subject: [PATCH v11 00/10] arm64, numa: Add numa support for arm64
 platforms
In-Reply-To: <CAKv+Gu8FRdif_WDZPqs7gHxXMu=6SqDd6A54dQc1KWuGwxpf0w@mail.gmail.com>
References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
 <CAKv+Gu8FRdif_WDZPqs7gHxXMu=6SqDd6A54dQc1KWuGwxpf0w@mail.gmail.com>
Message-ID: <20160220103959.GC4914@rric.localdomain>

On 20.02.16 09:20:05, Ard Biesheuvel wrote:
> On 20 February 2016 at 02:13, David Daney <ddaney.cavm at gmail.com> wrote:
> > From: David Daney <david.daney at cavium.com>
> >
> > v11:
> >         - Dropped cleanup patches for other architectures, they will be
> >           submitted as a separate set after more testing.
> >
> >         - Added patch set from Ard Biesheuvel that are needed to make
> >           the whole thing actually work.  Previously this was a
> >           separate set.
> >
> 
> This series is out of date, unfortunately. The EFI init code is now
> (as of v4.5-rc1) shared between ARM and arm64, which means that any
> changes you make must be made on both sides. This applies to the split
> between parsing the EFI dt nodes and performing the actual EFI init,
> but also to the early_init_dt_add_memory_arch() changes. I am happy to
> have a go at this, but first I need a clear statement from whoever
> maintains that area that keeping memory nodes *just* for the
> annotations (and otherwise ignore them) is the way forward (Rob?
> Grant?)

Wasn't there the approach to check for consistency between efi tables
and devicetree? Thus, DT is actually not ignored but rather checked if
it is in sync with efi tables.

-Robert


From marc.zyngier at arm.com  Sat Feb 20 02:40:19 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Sat, 20 Feb 2016 10:40:19 +0000
Subject: [PATCH v3 0/7] irqchip: introduce the Alpine MSIX driver
In-Reply-To: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <20160220104019.21e425c6@arm.com>

On Fri, 19 Feb 2016 16:22:42 +0100
Antoine Tenart <antoine.tenart at free-electrons.com> wrote:

Hi Antoine,

> Hi all,
> 
> This series introduce the Alpine MSIX driver, and enables it in both
> the Alpine v1 and Alpine v2 device trees.
> 
> This series depends on "[PATCH v2 0/3] arm64: introduce the Alpine support":
> https://lkml.org/lkml/2016/2/10/83
> 
> You can find the series at:
> https://github.com/atenart/linux.git 4.5-rc1/alpinev2-msix
> 
> Antoine
> 
> Since v2:
>   - Updated the documentation (added a reference to the GIC documentation).
> 
> Since v1:
>   - Added an interrupt-parent property in the documentation example.
>   - Updated to use bitmap_*() instead of *_bit().
>   - Removed the static irq_set_affinity to use irq_chip_set_affinity_parent().
>   - Updated the address field to use phys_addr_t.
>   - Added a comment on why we're setting bit 16 in the address.
>   - Patched the gic_set_affinity() function in irqchip/gic-v3.
> 
> Antoine Tenart (7):
>   irqchip/gic-v3: always return IRQ_SET_MASK_OK_DONE in gic_set_affinity
>   irqchip: add the Alpine MSIX interrupt controller
>   Documentation: bindings: document the Alpine MSIX driver
>   arm64: dts: alpine: add the MSIX node in the Alpine v2 dtsi
>   ARM: dts: alpine: add the MSIX node
>   arm64: alpine: select the Alpine MSI controller driver
>   arm: alpine: select the Alpine MSI controller driver
> 
>  .../interrupt-controller/al,alpine-msix.txt        |  26 ++
>  arch/arm/boot/dts/alpine.dtsi                      |  10 +
>  arch/arm/mach-alpine/Kconfig                       |   1 +
>  arch/arm64/Kconfig.platforms                       |   1 +
>  arch/arm64/boot/dts/al/alpine-v2.dtsi              |  10 +
>  drivers/irqchip/Kconfig                            |   6 +
>  drivers/irqchip/Makefile                           |   1 +
>  drivers/irqchip/irq-alpine-msi.c                   | 293 +++++++++++++++++++++
>  drivers/irqchip/irq-gic-v3.c                       |   2 +-
>  9 files changed, 349 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
>  create mode 100644 drivers/irqchip/irq-alpine-msi.c
> 

I've queued the first three patches in my irq/gic-4.6 branch. I'd
expect the last 4 patches to be taken care off by armsoc once the code
has made it into Linus' tree.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.


From ard.biesheuvel at linaro.org  Sat Feb 20 02:44:22 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Sat, 20 Feb 2016 11:44:22 +0100
Subject: [PATCH v11 00/10] arm64,
 numa: Add numa support for arm64 platforms
In-Reply-To: <20160220103959.GC4914@rric.localdomain>
References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
 <CAKv+Gu8FRdif_WDZPqs7gHxXMu=6SqDd6A54dQc1KWuGwxpf0w@mail.gmail.com>
 <20160220103959.GC4914@rric.localdomain>
Message-ID: <CAKv+Gu_1gRa2VW-C54sXfGP6+azE8aCLxDr8=YZVAkz0QxURpA@mail.gmail.com>

On 20 February 2016 at 11:39, Robert Richter
<robert.richter at caviumnetworks.com> wrote:
> On 20.02.16 09:20:05, Ard Biesheuvel wrote:
>> On 20 February 2016 at 02:13, David Daney <ddaney.cavm at gmail.com> wrote:
>> > From: David Daney <david.daney at cavium.com>
>> >
>> > v11:
>> >         - Dropped cleanup patches for other architectures, they will be
>> >           submitted as a separate set after more testing.
>> >
>> >         - Added patch set from Ard Biesheuvel that are needed to make
>> >           the whole thing actually work.  Previously this was a
>> >           separate set.
>> >
>>
>> This series is out of date, unfortunately. The EFI init code is now
>> (as of v4.5-rc1) shared between ARM and arm64, which means that any
>> changes you make must be made on both sides. This applies to the split
>> between parsing the EFI dt nodes and performing the actual EFI init,
>> but also to the early_init_dt_add_memory_arch() changes. I am happy to
>> have a go at this, but first I need a clear statement from whoever
>> maintains that area that keeping memory nodes *just* for the
>> annotations (and otherwise ignore them) is the way forward (Rob?
>> Grant?)
>
> Wasn't there the approach to check for consistency between efi tables
> and devicetree? Thus, DT is actually not ignored but rather checked if
> it is in sync with efi tables.
>

I proposed such an approach for the /reserved-memory node, but not for
the memory nodes themselves.

But thinking about this a bit more, I think we can replace the whole 6
piece series with the following patch
(apologies for the mangled whitespace). The reason is that, if we
decide to keep the memory nodes, we might just as well parse them as
usual (and use generic code to spot any problems etc), and just
discard the regions it describes. This completely solves the ARM vs
arm64 problem.


---------8<--------------
Subject: [PATCH] efi: ARM/arm64: ignore DT memory nodes instead of removing
 them

There are two problems with the UEFI stub DT memory node removal
routine:
- it deletes nodes as it traverses the tree, which happens to work
  but is not supported, as deletion invalidates the node iterator;
- deleting memory nodes entirely may discard annotations in the form
  of additional properties on the nodes.

Since the discovery of DT memory nodes occurs strictly before the
UEFI init sequence, we can simply clear the memblock memory table
before parsing the UEFI memory map. This way, it is no longer
necessary to remove the nodes, so we can remove that logic from the
stub as well.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/firmware/efi/arm-init.c    |  8 +++++++
 drivers/firmware/efi/libstub/fdt.c | 24 +-------------------
 2 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9e15d571b53c..40c9d8596d69 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -143,6 +143,14 @@ static __init void reserve_regions(void)
  if (efi_enabled(EFI_DBG))
  pr_info("Processing EFI memory map:\n");

+ /*
+ * Discard memblocks discovered so far: if there are any at this
+ * point, they originate from memory nodes in the DT, and UEFI
+ * uses its own memory map instead.
+ */
+ memblock_dump_all();
+ memblock_remove(0, ULLONG_MAX);
+
  for_each_efi_memory_desc(&memmap, md) {
  paddr = md->phys_addr;
  npages = md->num_pages;
diff --git a/drivers/firmware/efi/libstub/fdt.c
b/drivers/firmware/efi/libstub/fdt.c
index 6dba78aef337..e58abfa953cc 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -24,7 +24,7 @@ efi_status_t update_fdt(efi_system_table_t
*sys_table, void *orig_fdt,
  unsigned long map_size, unsigned long desc_size,
  u32 desc_ver)
 {
- int node, prev, num_rsv;
+ int node, num_rsv;
  int status;
  u32 fdt_val32;
  u64 fdt_val64;
@@ -54,28 +54,6 @@
  goto fdt_set_fail;

  /*
- * Delete any memory nodes present. We must delete nodes which
- * early_init_dt_scan_memory may try to use.
- */
- prev = 0;
- for (;;) {
- const char *type;
- int len;
-
- node = fdt_next_node(fdt, prev, NULL);
- if (node < 0)
- break;
-
- type = fdt_getprop(fdt, node, "device_type", &len);
- if (type && strncmp(type, "memory", len) == 0) {
- fdt_del_node(fdt, node);
- continue;
- }
-
- prev = node;
- }
-
- /*
  * Delete all memory reserve map entries. When booting via UEFI,
  * kernel will use the UEFI memory map to find reserved regions.
  */
-- 
1.9.1


From t-kristo at ti.com  Sat Feb 20 02:59:38 2016
From: t-kristo at ti.com (Tero Kristo)
Date: Sat, 20 Feb 2016 12:59:38 +0200
Subject: GPIO regression in Linux next caused by syscon change
In-Reply-To: <20160215180635.GW19432@atomide.com>
References: <20160213002643.GQ19432@atomide.com>
 <20160213004935.GR19432@atomide.com>
 <CA+gwMccZeYimupmGsMX8YbNH9eEA6=Xi=rupciubBwzktfjvBA@mail.gmail.com>
 <20160215160115.GU19432@atomide.com>
 <1455552961.4899.37.camel@pengutronix.de>
 <20160215164757.GV19432@atomide.com> <20160215180635.GW19432@atomide.com>
Message-ID: <56C8471A.1040702@ti.com>

On 02/15/2016 08:06 PM, Tony Lindgren wrote:
> * Tony Lindgren <tony at atomide.com> [160215 08:49]:
>> * Philipp Zabel <p.zabel at pengutronix.de> [160215 08:17]:
>>> Am Montag, den 15.02.2016, 08:01 -0800 schrieb Tony Lindgren:
>>>> * Philipp Zabel <philipp.zabel at gmail.com> [160214 11:24]:
>>>>> I've just replaced the of_iomap() call with an open coded version,
>>>>> calling of_address_to_resource() and ioremap() directly. That was
>>>>> needed so I can use the struct resource returned by
>>>>> of_address_to_resource() to set the syscon_config.max_register. I
>>>>> don't see where this could cause resource overlap. Does just setting
>>>>> syscon_config.max_register to zero again make the problem disappear?
>>>>
>>>> Yes commenting out the syscon_config.max_register line in your patch
>>>> makes things work again.
>>>>
>>>> So what does that tell us about the problem?
>>>
>>> Maybe some out of bounds writes that previously worked are now catched
>>> by the max_register check in regmap_writable and regmap_write returns
>>> -EIO instead of the write being executed.
>>
>> Hmm weird that something like that would not produce errors?
>>
>>> Is there any omap_ctrl_write?() call with an offset > 0x32c into
>>> scm_conf?
>>
>> Indeed, that's where things go wrong. Adding Tero to Cc, something
>> is wrong there.
>
> Something like this might fix it? Needs to be tested to see if it
> happens on other omaps.
>
> Tero, got any better ideas?

The underlying problem is the fact that OMAP3 control module register 
map is split into multiple regions, which in certain cases have 
overlapping functionality, and need to be accessed over boundaries. And 
the fact that we decided to split it in such way in the first place, for 
example to have pinmux regions separate.

If you are going to bypass the usage of regmap, you could just drop it 
completely from the omap_ctrl_readl / writel APIs, and use the iomap 
directly. That simplifies the code and is slightly faster also.

Eventually this should probably be fixed in such way that any 
out-of-bounds accesses on the omap_ctrl region should use the actual 
driver APIs for that. The padconf accesses I have no clue how to fix (as 
pinctrl driver doesn't provide direct register read/write API), but for 
others we should introduce new regions under the DTS files and use a 
separate syscon mapping or something similar.

It looks like we have following accesses in kernel that should be converted:

under omap3_ctrl_init:
OMAP2_CONTROL_SYSCONFIG
OMAP3_PADCONF_SAD2D_MSTANDBY
OMAP3_PADCONF_SAD2D_IDLEACK

under omap3_core_save_context:

         omap_ctrl_writel(omap_ctrl_readl(OMAP343X_PADCONF_ETK_D14),
                 OMAP343X_CONTROL_MEM_WKUP + 0x2a0);


under omap3_control_save / restore:

OMAP2_CONTROL_SYSCONFIG
OMAP34XX_CONTROL_WKUP_CTRL
OMAP343X_CONTROL_PADCONF_SYSNIRQ

-Tero

>
> Regards,
>
> Tony
>
> 8< -------------------
> --- a/arch/arm/mach-omap2/control.c
> +++ b/arch/arm/mach-omap2/control.c
> @@ -167,15 +167,23 @@ u16 omap_ctrl_readw(u16 offset)
>   u32 omap_ctrl_readl(u16 offset)
>   {
>   	u32 val;
> +	int err;
>
>   	offset &= 0xfffc;
> -	if (!omap2_ctrl_syscon)
> -		val = readl_relaxed(omap2_ctrl_base + offset);
> -	else
> -		regmap_read(omap2_ctrl_syscon, omap2_ctrl_offset + offset,
> -			    &val);
> +	if (omap2_ctrl_syscon) {
> +		err = regmap_read(omap2_ctrl_syscon,
> +				  omap2_ctrl_offset + offset, &val);
> +		if (!err)
> +			return val;
> +	}
> +
> +	if (WARN(!omap2_ctrl_base,
> +		 "syscon out of range for offset 0x%x, no omap2_ctrl_base?\n",
> +		    offset)) {
> +		return 0;
> +	}
>
> -	return val;
> +	return readl_relaxed(omap2_ctrl_base + offset);
>   }
>
>   void omap_ctrl_writeb(u8 val, u16 offset)
> @@ -206,12 +214,23 @@ void omap_ctrl_writew(u16 val, u16 offset)
>
>   void omap_ctrl_writel(u32 val, u16 offset)
>   {
> +	int err;
> +
>   	offset &= 0xfffc;
> -	if (!omap2_ctrl_syscon)
> -		writel_relaxed(val, omap2_ctrl_base + offset);
> -	else
> -		regmap_write(omap2_ctrl_syscon, omap2_ctrl_offset + offset,
> -			     val);
> +	if (omap2_ctrl_syscon) {
> +		err = regmap_write(omap2_ctrl_syscon,
> +				   omap2_ctrl_offset + offset, val);
> +		if (!err)
> +			return;
> +	}
> +
> +	if (WARN(!omap2_ctrl_base,
> +		 "syscon out of range for offset 0x%x, no omap2_ctrl_base?\n",
> +		    offset)) {
> +		return;
> +	}
> +
> +	writel_relaxed(val, omap2_ctrl_base + offset);
>   }
>
>   #ifdef CONFIG_ARCH_OMAP3
> @@ -724,9 +743,6 @@ int __init omap_control_init(void)
>   				if (ret)
>   					return ret;
>   			}
> -
> -			iounmap(omap2_ctrl_base);
> -			omap2_ctrl_base = NULL;
>   		} else {
>   			/* No scm_conf found, direct access */
>   			ret = omap2_clk_provider_init(np, data->index, NULL,
>



From t-kristo at ti.com  Sat Feb 20 03:12:57 2016
From: t-kristo at ti.com (Tero Kristo)
Date: Sat, 20 Feb 2016 13:12:57 +0200
Subject: [PATCHv2] clk: ti: omap3+: dpll: use non-locking version of
 clk_get_rate
Message-ID: <1455966777-30576-1-git-send-email-t-kristo@ti.com>

As the code in this file is being executed within irq context in some
cases, we must avoid the clk_get_rate which uses mutex internally.
Switch the code to use clk_hw_get_rate instead which is non-locking.

This fixes an issue where PM runtime will hang the system if enabled
with a serial console before a suspend-resume cycle.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
v2: updated commit desc slightly. This patch is still needed as it
    should go in as an -rc fix

 drivers/clk/ti/dpll3xxx.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/ti/dpll3xxx.c b/drivers/clk/ti/dpll3xxx.c
index 1c30038..cc73929 100644
--- a/drivers/clk/ti/dpll3xxx.c
+++ b/drivers/clk/ti/dpll3xxx.c
@@ -460,7 +460,8 @@ int omap3_noncore_dpll_enable(struct clk_hw *hw)
 
 	parent = clk_hw_get_parent(hw);
 
-	if (clk_hw_get_rate(hw) == clk_get_rate(dd->clk_bypass)) {
+	if (clk_hw_get_rate(hw) ==
+	    clk_hw_get_rate(__clk_get_hw(dd->clk_bypass))) {
 		WARN_ON(parent != __clk_get_hw(dd->clk_bypass));
 		r = _omap3_noncore_dpll_bypass(clk);
 	} else {
-- 
1.7.9.5



From t-kristo at ti.com  Sat Feb 20 03:24:26 2016
From: t-kristo at ti.com (Tero Kristo)
Date: Sat, 20 Feb 2016 13:24:26 +0200
Subject: [PATCHv2] clk: ti: dpll: convert DPLL support code to use clk_hw
 instead of clk ptrs
Message-ID: <1455967466-3812-1-git-send-email-t-kristo@ti.com>

Convert DPLL support code to use clk_hw pointers for reference and bypass
clocks. This allows us to use clk_hw_* APIs for accessing any required
parameters for these clocks, avoiding some locking problems at least with
DPLL enable code; this used clk_get_rate which uses mutex but isn't
good under clk_enable / clk_disable.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
---
v2: rebased the patch on top of v2 of 'clk: ti: omap3+: dpll: use non-locking
    version of clk_get_rate', as that one is required already for -rc. This
    patch can follow in 4.6 merge window.

 drivers/clk/ti/apll.c      |   20 ++++++++++++++++----
 drivers/clk/ti/clkt_dpll.c |    6 +++---
 drivers/clk/ti/dpll.c      |   25 +++++++++++++++++++------
 drivers/clk/ti/dpll3xxx.c  |   17 ++++++++---------
 drivers/clk/ti/dpll44xx.c  |    8 ++++----
 include/linux/clk/ti.h     |    8 ++++----
 6 files changed, 54 insertions(+), 30 deletions(-)

diff --git a/drivers/clk/ti/apll.c b/drivers/clk/ti/apll.c
index b336a8c..6411e13 100644
--- a/drivers/clk/ti/apll.c
+++ b/drivers/clk/ti/apll.c
@@ -140,11 +140,21 @@ static void __init omap_clk_register_apll(struct clk_hw *hw,
 	struct dpll_data *ad = clk_hw->dpll_data;
 	struct clk *clk;
 
-	ad->clk_ref = of_clk_get(node, 0);
-	ad->clk_bypass = of_clk_get(node, 1);
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk)) {
+		pr_debug("clk-ref for %s not ready, retry\n",
+			 node->name);
+		if (!ti_clk_retry_init(node, hw, omap_clk_register_apll))
+			return;
+
+		goto cleanup;
+	}
 
-	if (IS_ERR(ad->clk_ref) || IS_ERR(ad->clk_bypass)) {
-		pr_debug("clk-ref or clk-bypass for %s not ready, retry\n",
+	ad->clk_ref = __clk_get_hw(clk);
+
+	clk = of_clk_get(node, 1);
+	if (IS_ERR(clk)) {
+		pr_debug("clk-bypass for %s not ready, retry\n",
 			 node->name);
 		if (!ti_clk_retry_init(node, hw, omap_clk_register_apll))
 			return;
@@ -152,6 +162,8 @@ static void __init omap_clk_register_apll(struct clk_hw *hw,
 		goto cleanup;
 	}
 
+	ad->clk_bypass = __clk_get_hw(clk);
+
 	clk = clk_register(NULL, &clk_hw->hw);
 	if (!IS_ERR(clk)) {
 		of_clk_add_provider(node, of_clk_src_simple_get, clk);
diff --git a/drivers/clk/ti/clkt_dpll.c b/drivers/clk/ti/clkt_dpll.c
index b5cc6f6..032c658 100644
--- a/drivers/clk/ti/clkt_dpll.c
+++ b/drivers/clk/ti/clkt_dpll.c
@@ -254,7 +254,7 @@ unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk)
 	v >>= __ffs(dd->enable_mask);
 
 	if (_omap2_dpll_is_in_bypass(v))
-		return clk_get_rate(dd->clk_bypass);
+		return clk_hw_get_rate(dd->clk_bypass);
 
 	v = ti_clk_ll_ops->clk_readl(dd->mult_div1_reg);
 	dpll_mult = v & dd->mult_mask;
@@ -262,7 +262,7 @@ unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk)
 	dpll_div = v & dd->div1_mask;
 	dpll_div >>= __ffs(dd->div1_mask);
 
-	dpll_clk = (u64)clk_get_rate(dd->clk_ref) * dpll_mult;
+	dpll_clk = (u64)clk_hw_get_rate(dd->clk_ref) * dpll_mult;
 	do_div(dpll_clk, dpll_div + 1);
 
 	return dpll_clk;
@@ -301,7 +301,7 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned long target_rate,
 
 	dd = clk->dpll_data;
 
-	ref_rate = clk_get_rate(dd->clk_ref);
+	ref_rate = clk_hw_get_rate(dd->clk_ref);
 	clk_name = clk_hw_get_name(hw);
 	pr_debug("clock: %s: starting DPLL round_rate, target rate %lu\n",
 		 clk_name, target_rate);
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 5519b38..f8306f1 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -147,11 +147,22 @@ static void __init _register_dpll(struct clk_hw *hw,
 	struct dpll_data *dd = clk_hw->dpll_data;
 	struct clk *clk;
 
-	dd->clk_ref = of_clk_get(node, 0);
-	dd->clk_bypass = of_clk_get(node, 1);
+	clk = of_clk_get(node, 0);
+	if (IS_ERR(clk)) {
+		pr_debug("clk-ref missing for %s, retry later\n",
+			 node->name);
+		if (!ti_clk_retry_init(node, hw, _register_dpll))
+			return;
 
-	if (IS_ERR(dd->clk_ref) || IS_ERR(dd->clk_bypass)) {
-		pr_debug("clk-ref or clk-bypass missing for %s, retry later\n",
+		goto cleanup;
+	}
+
+	dd->clk_ref = __clk_get_hw(clk);
+
+	clk = of_clk_get(node, 1);
+
+	if (IS_ERR(clk)) {
+		pr_debug("clk-bypass missing for %s, retry later\n",
 			 node->name);
 		if (!ti_clk_retry_init(node, hw, _register_dpll))
 			return;
@@ -159,6 +170,8 @@ static void __init _register_dpll(struct clk_hw *hw,
 		goto cleanup;
 	}
 
+	dd->clk_bypass = __clk_get_hw(clk);
+
 	/* register the clock */
 	clk = clk_register(NULL, &clk_hw->hw);
 
@@ -251,8 +264,8 @@ struct clk *ti_clk_register_dpll(struct ti_clk *setup)
 	dd->recal_en_bit = dpll->recal_en_bit;
 	dd->recal_st_bit = dpll->recal_st_bit;
 
-	dd->clk_ref = clk_ref;
-	dd->clk_bypass = clk_bypass;
+	dd->clk_ref = __clk_get_hw(clk_ref);
+	dd->clk_bypass = __clk_get_hw(clk_bypass);
 
 	if (dpll->flags & CLKF_CORE)
 		ops = &omap3_dpll_core_ck_ops;
diff --git a/drivers/clk/ti/dpll3xxx.c b/drivers/clk/ti/dpll3xxx.c
index cc73929..88f2ce8 100644
--- a/drivers/clk/ti/dpll3xxx.c
+++ b/drivers/clk/ti/dpll3xxx.c
@@ -98,7 +98,7 @@ static u16 _omap3_dpll_compute_freqsel(struct clk_hw_omap *clk, u8 n)
 	unsigned long fint;
 	u16 f = 0;
 
-	fint = clk_get_rate(clk->dpll_data->clk_ref) / n;
+	fint = clk_hw_get_rate(clk->dpll_data->clk_ref) / n;
 
 	pr_debug("clock: fint is %lu\n", fint);
 
@@ -460,12 +460,11 @@ int omap3_noncore_dpll_enable(struct clk_hw *hw)
 
 	parent = clk_hw_get_parent(hw);
 
-	if (clk_hw_get_rate(hw) ==
-	    clk_hw_get_rate(__clk_get_hw(dd->clk_bypass))) {
-		WARN_ON(parent != __clk_get_hw(dd->clk_bypass));
+	if (clk_hw_get_rate(hw) == clk_hw_get_rate(dd->clk_bypass)) {
+		WARN_ON(parent != dd->clk_bypass);
 		r = _omap3_noncore_dpll_bypass(clk);
 	} else {
-		WARN_ON(parent != __clk_get_hw(dd->clk_ref));
+		WARN_ON(parent != dd->clk_ref);
 		r = _omap3_noncore_dpll_lock(clk);
 	}
 
@@ -513,13 +512,13 @@ int omap3_noncore_dpll_determine_rate(struct clk_hw *hw,
 	if (!dd)
 		return -EINVAL;
 
-	if (clk_get_rate(dd->clk_bypass) == req->rate &&
+	if (clk_hw_get_rate(dd->clk_bypass) == req->rate &&
 	    (dd->modes & (1 << DPLL_LOW_POWER_BYPASS))) {
-		req->best_parent_hw = __clk_get_hw(dd->clk_bypass);
+		req->best_parent_hw = dd->clk_bypass;
 	} else {
 		req->rate = omap2_dpll_round_rate(hw, req->rate,
 					  &req->best_parent_rate);
-		req->best_parent_hw = __clk_get_hw(dd->clk_ref);
+		req->best_parent_hw = dd->clk_ref;
 	}
 
 	req->best_parent_rate = req->rate;
@@ -577,7 +576,7 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned long rate,
 	if (!dd)
 		return -EINVAL;
 
-	if (clk_hw_get_parent(hw) != __clk_get_hw(dd->clk_ref))
+	if (clk_hw_get_parent(hw) != dd->clk_ref)
 		return -EINVAL;
 
 	if (dd->last_rounded_rate == 0)
diff --git a/drivers/clk/ti/dpll44xx.c b/drivers/clk/ti/dpll44xx.c
index 660d743..82c05b5 100644
--- a/drivers/clk/ti/dpll44xx.c
+++ b/drivers/clk/ti/dpll44xx.c
@@ -94,7 +94,7 @@ static void omap4_dpll_lpmode_recalc(struct dpll_data *dd)
 {
 	long fint, fout;
 
-	fint = clk_get_rate(dd->clk_ref) / (dd->last_rounded_n + 1);
+	fint = clk_hw_get_rate(dd->clk_ref) / (dd->last_rounded_n + 1);
 	fout = fint * dd->last_rounded_m;
 
 	if ((fint < OMAP4_DPLL_LP_FINT_MAX) && (fout < OMAP4_DPLL_LP_FOUT_MAX))
@@ -212,13 +212,13 @@ int omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw,
 	if (!dd)
 		return -EINVAL;
 
-	if (clk_get_rate(dd->clk_bypass) == req->rate &&
+	if (clk_hw_get_rate(dd->clk_bypass) == req->rate &&
 	    (dd->modes & (1 << DPLL_LOW_POWER_BYPASS))) {
-		req->best_parent_hw = __clk_get_hw(dd->clk_bypass);
+		req->best_parent_hw = dd->clk_bypass;
 	} else {
 		req->rate = omap4_dpll_regm4xen_round_rate(hw, req->rate,
 						&req->best_parent_rate);
-		req->best_parent_hw = __clk_get_hw(dd->clk_ref);
+		req->best_parent_hw = dd->clk_ref;
 	}
 
 	req->best_parent_rate = req->rate;
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 9a63860..dc5164a 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -23,8 +23,8 @@
  * @mult_div1_reg: register containing the DPLL M and N bitfields
  * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg
  * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg
- * @clk_bypass: struct clk pointer to the clock's bypass clock input
- * @clk_ref: struct clk pointer to the clock's reference clock input
+ * @clk_bypass: struct clk_hw pointer to the clock's bypass clock input
+ * @clk_ref: struct clk_hw pointer to the clock's reference clock input
  * @control_reg: register containing the DPLL mode bitfield
  * @enable_mask: mask of the DPLL mode bitfield in @control_reg
  * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate()
@@ -69,8 +69,8 @@ struct dpll_data {
 	void __iomem		*mult_div1_reg;
 	u32			mult_mask;
 	u32			div1_mask;
-	struct clk		*clk_bypass;
-	struct clk		*clk_ref;
+	struct clk_hw		*clk_bypass;
+	struct clk_hw		*clk_ref;
 	void __iomem		*control_reg;
 	u32			enable_mask;
 	unsigned long		last_rounded_rate;
-- 
1.7.9.5



From linus.walleij at linaro.org  Sat Feb 20 03:46:35 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sat, 20 Feb 2016 12:46:35 +0100
Subject: [02/11] video: ARM CLCD: support DT signal inversion flags
In-Reply-To: <ac0739e5-4339-7fc5-1179-73af722beb08@broadcom.com>
References: <1454594660-7532-3-git-send-email-linus.walleij@linaro.org>
 <0cebf93a-ee0a-3637-3242-8aed266df091@broadcom.com>
 <CACRpkdbGCidu_3qbTYf7WSoAhafU4Z5W0jDs4CGtH5XwSf14aA@mail.gmail.com>
 <ac0739e5-4339-7fc5-1179-73af722beb08@broadcom.com>
Message-ID: <CACRpkdZjmP+XxZiM+o+AYaz4NMNJxzyQHD1no-fK4AG45CEuMQ@mail.gmail.com>

On Sat, Feb 20, 2016 at 2:23 AM, Ray Jui <ray.jui at broadcom.com> wrote:

>> Do you have a system that needs this?
>
> Yah, we have a system (Cygnus) that can either use the HCLK, or an external
> clock generated from a PLL. To get certain pixel clock frequencies
> (depending on the LCD panel we use), we need to use the external clock
> source with the PLL configured to a particular VCO frequency.
>
> We have not enabled full LCD/video support on that platform in the mainline
> kernel, but we'll eventually get to it.

OK I hope to finish these patches soon so you have some nice stuff
to build upon. I guess it will need the same per-vendor plug-in that
I supplied for the ARMs and the Nomadik.

Yours,
Linus Walleij


From festevam at gmail.com  Sat Feb 20 03:57:27 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Sat, 20 Feb 2016 09:57:27 -0200
Subject: [PATCH 3/4] ARM: dts: imx6ul: Add GPMI nand controller support
In-Reply-To: <1455963652-24618-4-git-send-email-michael@amarulasolutions.com>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
 <1455963652-24618-4-git-send-email-michael@amarulasolutions.com>
Message-ID: <CAOMZO5DTmG7Umt+H20r+tZi9zZhsK=eoPbHOBO3iwvM2GXXLgg@mail.gmail.com>

Hi Michael,

On Sat, Feb 20, 2016 at 8:20 AM, Michael Trimarchi
<michael at amarulasolutions.com> wrote:
> Add support for GPMI nand controller.
>
> Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
> ---
>  arch/arm/boot/dts/imx6ul.dtsi          | 33 +++++++++++++++++++++++++++++++++
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 10 ++++++++++
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  6 ++++--

It would be better to split the dts and mtd parts in two patches.


From shannon.zhao at linaro.org  Sat Feb 20 05:15:23 2016
From: shannon.zhao at linaro.org (Shannon Zhao)
Date: Sat, 20 Feb 2016 21:15:23 +0800
Subject: [PATCH v11 06/21] KVM: ARM64: Add access handler for PMCEID0
 and PMCEID1 register
In-Reply-To: <20160208120950.GC620@cbox>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
 <1454656456-11640-7-git-send-email-zhaoshenglong@huawei.com>
 <20160208120950.GC620@cbox>
Message-ID: <56C866EB.9060105@linaro.org>



On 2016/2/8 20:09, Christoffer Dall wrote:
> On Fri, Feb 05, 2016 at 03:14:01PM +0800, Shannon Zhao wrote:
>> >From: Shannon Zhao<shannon.zhao at linaro.org>
>> >
>> >Add access handler which gets host value of PMCEID0 or PMCEID1 when
>> >guest access these registers. Writing action to PMCEID0 or PMCEID1 is
>> >UNDEFINED.
>> >
>> >Signed-off-by: Shannon Zhao<shannon.zhao at linaro.org>
>> >---
>> >  arch/arm64/kvm/sys_regs.c | 29 +++++++++++++++++++++++++----
>> >  1 file changed, 25 insertions(+), 4 deletions(-)
>> >
>> >diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>> >index fc60041..06257e2 100644
>> >--- a/arch/arm64/kvm/sys_regs.c
>> >+++ b/arch/arm64/kvm/sys_regs.c
>> >@@ -492,6 +492,27 @@ static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >  	return true;
>> >  }
>> >
>> >+static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >+			  const struct sys_reg_desc *r)
>> >+{
>> >+	u64 pmceid;
>> >+
>> >+	if (!kvm_arm_pmu_v3_ready(vcpu))
>> >+		return trap_raz_wi(vcpu, p, r);
>> >+
>> >+	if (p->is_write)
>> >+		return false;
> Isn't it really a BUG_ON(p->is_write) ?
>
> Presumably a guest write to these registers will raise an undefined
> exception in EL0/1 and we don't get here by any other path than the trap
> handler, do we?
Yeah, for EL1, it shouldn't get here. But for EL0, to support the 
function of PMUSERENR, we firstly trap the access to EL2, then according 
to the real value of PMUSERENR to decide whether inject an UND to EL1.


Thanks,
-- 
Shannon


From peter.maydell at linaro.org  Sat Feb 20 05:30:33 2016
From: peter.maydell at linaro.org (Peter Maydell)
Date: Sat, 20 Feb 2016 13:30:33 +0000
Subject: [PATCH v11 06/21] KVM: ARM64: Add access handler for PMCEID0 and
 PMCEID1 register
In-Reply-To: <56C866EB.9060105@linaro.org>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
 <1454656456-11640-7-git-send-email-zhaoshenglong@huawei.com>
 <20160208120950.GC620@cbox> <56C866EB.9060105@linaro.org>
Message-ID: <CAFEAcA8=iRkAMLStMzu0wAPWfXZ9vYu_YzEKrEyVrWHP4=VS2w@mail.gmail.com>

On 20 February 2016 at 13:15, Shannon Zhao <shannon.zhao at linaro.org> wrote:
>
>
> On 2016/2/8 20:09, Christoffer Dall wrote:
>> Isn't it really a BUG_ON(p->is_write) ?
>>
>> Presumably a guest write to these registers will raise an undefined
>> exception in EL0/1 and we don't get here by any other path than the trap
>> handler, do we?
>
> Yeah, for EL1, it shouldn't get here. But for EL0, to support the function
> of PMUSERENR, we firstly trap the access to EL2, then according to the real
> value of PMUSERENR to decide whether inject an UND to EL1.

I thought the PMUSERENR check took priority over trap-to-EL2 checks
in the architecture; so if this is an EL0 access and you get to EL2
at all then you know that PMUSERENR is set to permit EL0 reads.

Similarly, UNDEF because of write-to-always-RO register has
priority over trap-to-EL2, so I think Christoffer is right
and you should never be able to get here for a write.
(This should be easy to write a test program for if you're unsure.)

thanks
-- PMM


From shannon.zhao at linaro.org  Sat Feb 20 05:32:05 2016
From: shannon.zhao at linaro.org (Shannon Zhao)
Date: Sat, 20 Feb 2016 21:32:05 +0800
Subject: [PATCH v11 16/21] KVM: ARM64: Add PMU overflow interrupt routing
In-Reply-To: <20160208122643.GD620@cbox>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
 <1454656456-11640-17-git-send-email-zhaoshenglong@huawei.com>
 <20160208122643.GD620@cbox>
Message-ID: <56C86AD5.5080702@linaro.org>



On 2016/2/8 20:26, Christoffer Dall wrote:
> On Fri, Feb 05, 2016 at 03:14:11PM +0800, Shannon Zhao wrote:
>> >From: Shannon Zhao<shannon.zhao at linaro.org>
>> >
>> >When calling perf_event_create_kernel_counter to create perf_event,
>> >assign a overflow handler. Then when the perf event overflows, set the
>> >corresponding bit of guest PMOVSSET register. If this counter is enabled
>> >and its interrupt is enabled as well, kick the vcpu to sync the
>> >interrupt.
>> >
>> >On VM entry, if there is counter overflowed, inject the interrupt with
>> >the level set to 1. Otherwise, inject the interrupt with the level set
>> >to 0.
>> >
>> >Signed-off-by: Shannon Zhao<shannon.zhao at linaro.org>
>> >Reviewed-by: Marc Zyngier<marc.zyngier at arm.com>
>> >Reviewed-by: Andrew Jones<drjones at redhat.com>
>> >---
>> >  arch/arm/kvm/arm.c    |  2 ++
>> >  include/kvm/arm_pmu.h |  2 ++
>> >  virt/kvm/arm/pmu.c    | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
>> >  3 files changed, 53 insertions(+), 1 deletion(-)
>> >
>> >diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> >index dda1959..f54264c 100644
>> >--- a/arch/arm/kvm/arm.c
>> >+++ b/arch/arm/kvm/arm.c
>> >@@ -28,6 +28,7 @@
>> >  #include <linux/sched.h>
>> >  #include <linux/kvm.h>
>> >  #include <trace/events/kvm.h>
>> >+#include <kvm/arm_pmu.h>
>> >
>> >  #define CREATE_TRACE_POINTS
>> >  #include "trace.h"
>> >@@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> >  		 * non-preemptible context.
>> >  		 */
>> >  		preempt_disable();
>> >+		kvm_pmu_flush_hwstate(vcpu);
>> >  		kvm_timer_flush_hwstate(vcpu);
>> >  		kvm_vgic_flush_hwstate(vcpu);
>> >
>> >diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
>> >index 1f4bfa2..44a3c75 100644
>> >--- a/include/kvm/arm_pmu.h
>> >+++ b/include/kvm/arm_pmu.h
>> >@@ -44,6 +44,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
>> >  void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
>> >  void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
>> >  void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
>> >+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
>> >  void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
>> >  void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
>> >  void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>> >@@ -67,6 +68,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
>> >  static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>> >  static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>> >  static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
>> >+static inline void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
>> >  static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
>> >  static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
>> >  static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
>> >diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
>> >index c8ea825..5f983cb 100644
>> >--- a/virt/kvm/arm/pmu.c
>> >+++ b/virt/kvm/arm/pmu.c
>> >@@ -21,6 +21,7 @@
>> >  #include <linux/perf_event.h>
>> >  #include <asm/kvm_emulate.h>
>> >  #include <kvm/arm_pmu.h>
>> >+#include <kvm/arm_vgic.h>
>> >
>> >  /**
>> >   * kvm_pmu_get_counter_value - get PMU counter value
>> >@@ -180,6 +181,52 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
>> >  }
>> >
>> >  /**
>> >+ * kvm_pmu_flush_hwstate - flush pmu state to cpu
>> >+ * @vcpu: The vcpu pointer
>> >+ *
>> >+ * Inject virtual PMU IRQ if IRQ is pending for this cpu.
>> >+ */
>> >+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
>> >+{
>> >+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
>> >+	u64 overflow;
>> >+
>> >+	if (!kvm_arm_pmu_v3_ready(vcpu))
>> >+		return;
>> >+
>> >+	if (!(vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E))
>> >+		return;
> are we modeling the PMU interrupt as level-triggered?
>
Yes.
> In that case, shouldn't we lower the interrupt line on flush when
> PMCR_EL0.E == 0 ?
We inject the interrupt only based on the value of PMOVSSET. There might 
be a case that PMCR_EL0.E is 0 and PMOVSSET is not zero. In this case it 
should pull up the interrupt line.

-- 
Shannon


From shannon.zhao at linaro.org  Sat Feb 20 05:34:52 2016
From: shannon.zhao at linaro.org (Shannon Zhao)
Date: Sat, 20 Feb 2016 21:34:52 +0800
Subject: [PATCH v11 06/21] KVM: ARM64: Add access handler for PMCEID0
 and PMCEID1 register
In-Reply-To: <CAFEAcA8=iRkAMLStMzu0wAPWfXZ9vYu_YzEKrEyVrWHP4=VS2w@mail.gmail.com>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
 <1454656456-11640-7-git-send-email-zhaoshenglong@huawei.com>
 <20160208120950.GC620@cbox> <56C866EB.9060105@linaro.org>
 <CAFEAcA8=iRkAMLStMzu0wAPWfXZ9vYu_YzEKrEyVrWHP4=VS2w@mail.gmail.com>
Message-ID: <56C86B7C.9020906@linaro.org>



On 2016/2/20 21:30, Peter Maydell wrote:
> On 20 February 2016 at 13:15, Shannon Zhao<shannon.zhao at linaro.org>  wrote:
>> >
>> >
>> >On 2016/2/8 20:09, Christoffer Dall wrote:
>>> >>Isn't it really a BUG_ON(p->is_write) ?
>>> >>
>>> >>Presumably a guest write to these registers will raise an undefined
>>> >>exception in EL0/1 and we don't get here by any other path than the trap
>>> >>handler, do we?
>> >
>> >Yeah, for EL1, it shouldn't get here. But for EL0, to support the function
>> >of PMUSERENR, we firstly trap the access to EL2, then according to the real
>> >value of PMUSERENR to decide whether inject an UND to EL1.
> I thought the PMUSERENR check took priority over trap-to-EL2 checks
> in the architecture; so if this is an EL0 access and you get to EL2
> at all then you know that PMUSERENR is set to permit EL0 reads.
>
> Similarly, UNDEF because of write-to-always-RO register has
> priority over trap-to-EL2, so I think Christoffer is right
> and you should never be able to get here for a write.
> (This should be easy to write a test program for if you're unsure.)
Thanks, I'll check this.

-- 
Shannon


From shannon.zhao at linaro.org  Sat Feb 20 05:38:16 2016
From: shannon.zhao at linaro.org (Shannon Zhao)
Date: Sat, 20 Feb 2016 21:38:16 +0800
Subject: [PATCH v11 20/21] KVM: ARM: Introduce per-vcpu kvm device controls
In-Reply-To: <20160208124059.GF620@cbox>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
 <1454656456-11640-21-git-send-email-zhaoshenglong@huawei.com>
 <20160208124059.GF620@cbox>
Message-ID: <56C86C48.2060702@linaro.org>



On 2016/2/8 20:40, Christoffer Dall wrote:
>> +	case KVM_SET_DEVICE_ATTR: {
>> >+		if (copy_from_user(&attr, argp, sizeof(attr)))
>> >+			return -EFAULT;
>> >+		return kvm_arm_vcpu_set_attr(vcpu, &attr);
>> >+	}
>> >+	case KVM_GET_DEVICE_ATTR: {
>> >+		if (copy_from_user(&attr, argp, sizeof(attr)))
>> >+			return -EFAULT;
>> >+		return kvm_arm_vcpu_get_attr(vcpu, &attr);
>> >+	}
>> >+	case KVM_HAS_DEVICE_ATTR: {
>> >+		if (copy_from_user(&attr, argp, sizeof(attr)))
>> >+			return -EFAULT;
>> >+		return kvm_arm_vcpu_has_attr(vcpu, &attr);
>> >+	}
> do we share the ioctl number space across device, VM, and VCPU file
> descriptors?
Yeah, they're shared across device, VM, and VCPU.

Thanks,
-- 
Shannon


From plaes at plaes.org  Sat Feb 20 05:45:41 2016
From: plaes at plaes.org (Priit Laes)
Date: Sat, 20 Feb 2016 15:45:41 +0200
Subject: [linux-sunxi] [PATCH v2 00/26] drm: Add Allwinner A10 display
 engine support
In-Reply-To: <1452785109-6172-1-git-send-email-maxime.ripard@free-electrons.com>
References: <1452785109-6172-1-git-send-email-maxime.ripard@free-electrons.com>
Message-ID: <1455975941.10551.3.camel@plaes.org>

On Thu, 2016-01-14 at 16:24 +0100, Maxime Ripard wrote:
> Hi everyone,
> 
> The Allwinner SoCs (except for the very latest ones) all share the
> same set of controllers, loosely coupled together to form the display
> pipeline.
> 
> Depending on the SoC, the number of instances of the controller will
> change (2 instances of each in the A10, only one in the A13, for
> example), and the output availables will change too (HDMI, composite,
> VGA on the A20, none of them on the A13).
> 
> On most featured SoCs, it looks like that:
> 
> ?+--------------------------------------------+
> ?|????????????????????RAM?????????????????????|
> ?+--------------------------------------------+
> ???????|????????????|??????|????????????|
> ???????v????????????|??????|????????????v
> ?+----------------+ |??????| +----------------+
> ?|????Frontend????| |??????| |????Frontend????|
> ?+----------------+ |??????| +----------------+
> ?????????|??????????|??????|?????????|
> ?????????v??????????|??????|?????????v
> ?+----------------+ |??????| +----------------+
> ?|????Backend?????|<+??????+>|????Backend?????|
> ?+----------------+??????????+----------------+
> ?????????|???????????????????????????|
> ?????????v???????????????????????????v
> ?+----------------+??????????+----------------+---> LVDS
> ?|??????TCON??????|??????????|??????TCON??????|---> RGB
> ?+----------------+??????????+----------------+
> ???????|???????+---+???????+---+??????????|
> ???????|???????????|???????|??????????????|
> ???????v???????????v???????v??????????????v
> ?+------------+??+------------+??+------------+---> VGA
> ?| TV Encoder |??|????HDMI????|??| TV Encoder |---> Composite
> ?+------------+??+------------+??+------------+
> 
> The current code only assumes that there is a single instance of all
> the controllers. It also supports only the RGB and Composite
> interfaces.

I found some time to play with it (with intention to get it running
also on sun7i and sun4i) and ran into this when trying to build
sun4i_drm as module:

ERROR: "sun4i_tcon1_mode_set" [drivers/gpu/drm/sun4i/sun4i_tv.ko] undefined!
ERROR: "sun4i_backend_apply_color_correction" [drivers/gpu/drm/sun4i/sun4i_tv.ko] undefined!
ERROR: "sun4i_tcon_channel_disable" [drivers/gpu/drm/sun4i/sun4i_tv.ko] undefined!
ERROR: "sun4i_tcon_channel_enable" [drivers/gpu/drm/sun4i/sun4i_tv.ko] undefined!
ERROR: "clk_unregister_composite" [drivers/gpu/drm/sun4i/sun4i_tcon.ko] undefined!
ERROR: "sun4i_rgb_init" [drivers/gpu/drm/sun4i/sun4i_tcon.ko] undefined!
ERROR: "clk_register_composite" [drivers/gpu/drm/sun4i/sun4i_tcon.ko] undefined!
ERROR: "sun4i_backend_update_layer_coord" [drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
ERROR: "sun4i_backend_update_layer_formats" [drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
ERROR: "sun4i_tcon_channel_disable" [drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
ERROR: "sun4i_tcon_enable_vblank" [drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
ERROR: "sun4i_backend_update_layer_buffer" [drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
ERROR: "sun4i_backend_layer_enable" [drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
ERROR: "sun4i_tcon_channel_enable" [drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
ERROR: "sun4i_tcon_enable" [drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
ERROR: "sun4i_tcon_disable" [drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
ERROR: "sun4i_tcon0_mode_set" [drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
ERROR: "sun4i_backend_commit" [drivers/gpu/drm/sun4i/sun4i-drm.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed



> 
> Let me know what you think,
> Maxime
> 
> Changes from v1:
> ? - Rebased on top of 4.4
> 
> ? - Merged the clock drivers for the display and TCON channel 0
> clocks
> ? - Replaced the container_of calls in the display reset clocks to an
> ????inline function
> ? - Checked the return code of of_clk_parent_fill in the clocks
> ????drivers
> ? - Checked the return code of of_clk_add_provider in the tcon-ch1
> and
> ????PLL3 clocks
> ? - Added missing clocks headers
> ? - Created a composite clock unregister function
> 
> ? - Moved the binding documentation to
> ????Documentation/devicetree/bindings/display
> ? - Added the clocks binding documentation
> ? - Added the Olimex vendor to the list of DT vendors
> ? - Moved to the OF graph representation and the component framework
> 
> ? - Moved the reset cells count check into the reset framework to
> ????avoid duplicating the code in every xlate implementation.
> ? - Made the reset_ops const
> 
> ? - Reworked the DRM cmdline mode parsing code to allow named mode
> ? - Fixed the TV mode lookup when the mode name is not present (for
> ????example because it was given by the userspace)
> 
> ? - Made the driver outputs optional (to avoid crashing when a board
> ????doesn't have either a panel or a composite output enabled)
> ? - Added multiple plane support with transparency
> ? - Moved the backend registers writes commit in the CRTC
> atomic_flush
> ????callback
> ? - Removed the load / unload functions
> ? - Removed the enabled booleans in my private structure and removed
> ????the implicit call to disable_unused_functions in the DRM core to
> ????push it in the drivers.
> ? - Fixed a few bitmasks on some bitfields definition
> ? - Fixed the RGB connector mode validation that was not testing the
> ????right values
> 
> Matthias Brugger (1):
> ? clk: Add regmap support
> 
> Maxime Ripard (25):
> ? reset: Move DT cell size check to the core
> ? reset: Make reset_control_ops const
> ? clk: composite: Add unregister function
> ? clk: sunxi: Add display and TCON0 clocks driver
> ? clk: sunxi: Add PLL3 clock
> ? clk: sunxi: Add TCON channel1 clock
> ? clk: sun5i: add DRAM gates
> ? ARM: sun5i: dt: Add pll3 and pll7 clocks
> ? ARM: sun5i: a13: Add display and TCON clocks
> ? ARM: sun5i: Add DRAM gates
> ? ARM: sun5i: Add TV encoder gate to the DTSI
> ? drm/fb_cma_helper: Remove implicit call to disable_unused_functions
> ? drm/modes: Rewrite the command line parser
> ? drm/modes: Support modes names on the command line
> ? drm: Add Allwinner A10 Display Engine support
> ? drm: sun4i: Add DT bindings documentation
> ? drm: sun4i: Add RGB output
> ? drm: sun4i: Add composite output
> ? drm: sun4i: tv: Add PAL output standard
> ? drm: sun4i: tv: Add NTSC output standard
> ? ARM: sun5i: r8: Add display blocks to the DTSI
> ? ARM: sun5i: chip: Enable the TV Encoder
> ? devicetree: Add olimex vendor prefix
> ? drm/panel: simple: Add timings for the Olimex LCD-OLinuXino-4.3TS
> ? DO NOT MERGE: ARM: sun5i: chip: Enable the LCD panel
> 
> ?Documentation/devicetree/bindings/clock/sunxi.txt??|???5 +
> ?.../display/panel/olimex,lcd-olinuxino-43-ts.txt???|???7 +
> ?.../bindings/display/sunxi/sun4i-drm.txt???????????| 228 +++++++
> ?.../devicetree/bindings/vendor-prefixes.txt????????|???1 +
> ?arch/arm/boot/dts/sun5i-a10s.dtsi??????????????????|???7 +-
> ?arch/arm/boot/dts/sun5i-a13.dtsi???????????????????|??46 +-
> ?arch/arm/boot/dts/sun5i-r8-chip.dts????????????????|??17 +
> ?arch/arm/boot/dts/sun5i-r8.dtsi????????????????????| 139 ++++-
> ?arch/arm/boot/dts/sun5i.dtsi???????????????????????|??62 ++
> ?drivers/clk/Makefile???????????????????????????????|???1 +
> ?drivers/clk/clk-composite.c????????????????????????|??15 +
> ?drivers/clk/clk-divider.c??????????????????????????|??68 ++-
> ?drivers/clk/clk-gate.c?????????????????????????????|??54 +-
> ?drivers/clk/clk-io.c???????????????????????????????|??48 ++
> ?drivers/clk/clk-io.h???????????????????????????????|??22 +
> ?drivers/clk/clk-mux.c??????????????????????????????|??94 ++-
> ?drivers/clk/sunxi/Makefile?????????????????????????|???3 +
> ?drivers/clk/sunxi/clk-simple-gates.c???????????????|???2 +
> ?drivers/clk/sunxi/clk-sun4i-display.c??????????????| 241 ++++++++
> ?drivers/clk/sunxi/clk-sun4i-pll3.c?????????????????|??90 +++
> ?drivers/clk/sunxi/clk-sun4i-tcon-ch1.c?????????????| 154 +++++
> ?drivers/gpu/drm/Kconfig????????????????????????????|???2 +
> ?drivers/gpu/drm/Makefile???????????????????????????|???3 +-
> ?drivers/gpu/drm/drm_crtc.c?????????????????????????|???3 +-
> ?drivers/gpu/drm/drm_fb_cma_helper.c????????????????|???3 -
> ?drivers/gpu/drm/drm_fb_helper.c????????????????????|???4 +
> ?drivers/gpu/drm/drm_modes.c????????????????????????| 327 ++++++----
> ?drivers/gpu/drm/imx/imx-drm-core.c?????????????????|???1 +
> ?drivers/gpu/drm/panel/panel-simple.c???????????????|??26 +
> ?drivers/gpu/drm/sti/sti_drv.c??????????????????????|???1 +
> ?drivers/gpu/drm/sun4i/Kconfig??????????????????????|??14 +
> ?drivers/gpu/drm/sun4i/Makefile?????????????????????|??12 +
> ?drivers/gpu/drm/sun4i/sun4i_backend.c??????????????| 321 ++++++++++
> ?drivers/gpu/drm/sun4i/sun4i_backend.h??????????????| 160 +++++
> ?drivers/gpu/drm/sun4i/sun4i_crtc.c?????????????????| 120 ++++
> ?drivers/gpu/drm/sun4i/sun4i_crtc.h?????????????????|??30 +
> ?drivers/gpu/drm/sun4i/sun4i_drv.c??????????????????| 325 ++++++++++
> ?drivers/gpu/drm/sun4i/sun4i_drv.h??????????????????|??30 +
> ?drivers/gpu/drm/sun4i/sun4i_framebuffer.c??????????|??54 ++
> ?drivers/gpu/drm/sun4i/sun4i_framebuffer.h??????????|??19 +
> ?drivers/gpu/drm/sun4i/sun4i_layer.c????????????????| 160 +++++
> ?drivers/gpu/drm/sun4i/sun4i_layer.h????????????????|??30 +
> ?drivers/gpu/drm/sun4i/sun4i_rgb.c??????????????????| 229 +++++++
> ?drivers/gpu/drm/sun4i/sun4i_rgb.h??????????????????|??18 +
> ?drivers/gpu/drm/sun4i/sun4i_tcon.c?????????????????| 521
> ++++++++++++++++
> ?drivers/gpu/drm/sun4i/sun4i_tcon.h?????????????????| 177 ++++++
> ?drivers/gpu/drm/sun4i/sun4i_tv.c???????????????????| 675
> +++++++++++++++++++++
> ?drivers/gpu/drm/tilcdc/tilcdc_drv.c????????????????|???1 +
> ?drivers/reset/core.c???????????????????????????????|???6 +-
> ?include/drm/drm_modes.h????????????????????????????|???1 +
> ?include/linux/clk-provider.h???????????????????????|??55 +-
> ?include/linux/reset-controller.h???????????????????|???2 +-
> ?52 files changed, 4455 insertions(+), 179 deletions(-)
> ?create mode 100644
> Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino-
> 43-ts.txt
> ?create mode 100644
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> ?create mode 100644 drivers/clk/clk-io.c
> ?create mode 100644 drivers/clk/clk-io.h
> ?create mode 100644 drivers/clk/sunxi/clk-sun4i-display.c
> ?create mode 100644 drivers/clk/sunxi/clk-sun4i-pll3.c
> ?create mode 100644 drivers/clk/sunxi/clk-sun4i-tcon-ch1.c
> ?create mode 100644 drivers/gpu/drm/sun4i/Kconfig
> ?create mode 100644 drivers/gpu/drm/sun4i/Makefile
> ?create mode 100644 drivers/gpu/drm/sun4i/sun4i_backend.c
> ?create mode 100644 drivers/gpu/drm/sun4i/sun4i_backend.h
> ?create mode 100644 drivers/gpu/drm/sun4i/sun4i_crtc.c
> ?create mode 100644 drivers/gpu/drm/sun4i/sun4i_crtc.h
> ?create mode 100644 drivers/gpu/drm/sun4i/sun4i_drv.c
> ?create mode 100644 drivers/gpu/drm/sun4i/sun4i_drv.h
> ?create mode 100644 drivers/gpu/drm/sun4i/sun4i_framebuffer.c
> ?create mode 100644 drivers/gpu/drm/sun4i/sun4i_framebuffer.h
> ?create mode 100644 drivers/gpu/drm/sun4i/sun4i_layer.c
> ?create mode 100644 drivers/gpu/drm/sun4i/sun4i_layer.h
> ?create mode 100644 drivers/gpu/drm/sun4i/sun4i_rgb.c
> ?create mode 100644 drivers/gpu/drm/sun4i/sun4i_rgb.h
> ?create mode 100644 drivers/gpu/drm/sun4i/sun4i_tcon.c
> ?create mode 100644 drivers/gpu/drm/sun4i/sun4i_tcon.h
> ?create mode 100644 drivers/gpu/drm/sun4i/sun4i_tv.c
> 
> --?
> 2.6.4
> 


From festevam at gmail.com  Sat Feb 20 06:02:51 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Sat, 20 Feb 2016 12:02:51 -0200
Subject: [PATCH 1/4] ARM: dts: imx6ul: Add flexcan1 and flexcan2 support
In-Reply-To: <1455963652-24618-2-git-send-email-michael@amarulasolutions.com>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
 <1455963652-24618-2-git-send-email-michael@amarulasolutions.com>
Message-ID: <CAOMZO5Bk_ZMhYzFLRFNK2TQvK4KHuj62AM_6uF-m-P1kJupTHQ@mail.gmail.com>

On Sat, Feb 20, 2016 at 8:20 AM, Michael Trimarchi
<michael at amarulasolutions.com> wrote:

> +
> +                               flexcan1: can at 02090000 {
> +                                       compatible = "fsl,imx6ul-flexcan", "fsl,imx6q-flexcan";
> +                                       reg = <0x02090000 0x4000>;
> +                                       interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
> +                                       clocks = <&clks IMX6UL_CLK_CAN1_IPG>,
> +                                                <&clks IMX6UL_CLK_CAN1_SERIAL>;
> +                                       clock-names = "ipg", "per";
> +                                       stop-mode = <&gpr 0x10 1 0x10 17>;

This 'stop-mode' property is not handled in mainline, only in NXP
kernel, so I suggest to drop this.


From festevam at gmail.com  Sat Feb 20 06:11:14 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Sat, 20 Feb 2016 12:11:14 -0200
Subject: [PATCH 4/4] ARM: dts: imx6ul-geam: Add Engicam IMX6UL GEA M6UL
 initial support
In-Reply-To: <1455963652-24618-5-git-send-email-michael@amarulasolutions.com>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
 <1455963652-24618-5-git-send-email-michael@amarulasolutions.com>
Message-ID: <CAOMZO5AmePs3aE2zRSXcSS8iKQ0m2kvTAezsfHS13e-Zv1HCrA@mail.gmail.com>

On Sat, Feb 20, 2016 at 8:20 AM, Michael Trimarchi
<michael at amarulasolutions.com> wrote:

> +       reg_1p8v: regulator-1p8v {
> +               compatible = "regulator-fixed";
> +               regulator-name = "1P8V";
> +               regulator-min-microvolt = <1800000>;
> +               regulator-max-microvolt = <1800000>;
> +               regulator-boot-on;
> +               regulator-always-on;

These last two properties can be removed.

> +       };
> +
> +       reg_3p3v: regulator-3p3v {
> +               compatible = "regulator-fixed";
> +               regulator-name = "3P3V";
> +               regulator-min-microvolt = <3300000>;
> +               regulator-max-microvolt = <3300000>;
> +               regulator-boot-on;
> +               regulator-always-on;

Ditto.

> +       pinctrl_spi4: spi4grp {
> +               fsl,pins = <
> +                       MX6UL_PAD_BOOT_MODE0__GPIO5_IO10        0x70a1
> +                       MX6UL_PAD_BOOT_MODE1__GPIO5_IO11        0x70a1
> +                       MX6UL_PAD_SNVS_TAMPER7__GPIO5_IO07      0x70a1
> +                       MX6UL_PAD_SNVS_TAMPER8__GPIO5_IO08      0x80000000
> +               >;
> +       };

pinctrl_spi4 seems to be unused.


From jchandra at broadcom.com  Sat Feb 20 06:19:19 2016
From: jchandra at broadcom.com (Jayachandran C)
Date: Sat, 20 Feb 2016 19:49:19 +0530
Subject: [PATCH v2 0/5] Support for Broadcom Vulcan ARM64 processor
Message-ID: <1455977964-8099-1-git-send-email-jchandra@broadcom.com>

This patchset adds support for Broadcom's Vulcan ARM64 processor.
The changes are to add the device tree files, documentation for the
device tree, cpu ID and the maintainers entry.

This is v2 of the patchset, changelog below:

v1->v2 :
 - dts: remove memreserve, use brcm,vulcan-soc for board
   (to address comments from Mark Rutland)
 - Fixup copyright (Broadcomp corp -> Broadcom)
   (suggested by Florian Fainelli)
 - Rename dts from brcm-vulcan* to vulcan*
   (suggested by Ray Jui)
 - Add maintainers entry
   (suggested by Florian Fainelli)
 - Updated the device tree doc and fixed a couple of commit
   comments

Jayachandran C (4):
  dt-bindings: Add documentation for Broadcom Vulcan
  arm64: defconfig: Add Broadcom Vulcan to defconfig
  arm64: cputype info for Broadcom Vulcan
  MAINTAINERS: Add entry for Broadcom Vulcan SoC

Zi Shen Lim (1):
  arm64: Broadcom Vulcan support

 .../bindings/arm/bcm/brcm,vulcan-soc.txt           |  10 ++
 Documentation/devicetree/bindings/arm/cpus.txt     |   1 +
 MAINTAINERS                                        |   7 +
 arch/arm64/Kconfig.platforms                       |   5 +
 arch/arm64/boot/dts/broadcom/Makefile              |   1 +
 arch/arm64/boot/dts/broadcom/vulcan-eval.dts       |  33 +++++
 arch/arm64/boot/dts/broadcom/vulcan.dtsi           | 144 +++++++++++++++++++++
 arch/arm64/configs/defconfig                       |   1 +
 arch/arm64/include/asm/cputype.h                   |   3 +
 9 files changed, 205 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.txt
 create mode 100644 arch/arm64/boot/dts/broadcom/vulcan-eval.dts
 create mode 100644 arch/arm64/boot/dts/broadcom/vulcan.dtsi

-- 
1.9.1



From jchandra at broadcom.com  Sat Feb 20 06:19:22 2016
From: jchandra at broadcom.com (Jayachandran C)
Date: Sat, 20 Feb 2016 19:49:22 +0530
Subject: [PATCH v2 3/5] arm64: defconfig: Add Broadcom Vulcan to defconfig
In-Reply-To: <1455977964-8099-1-git-send-email-jchandra@broadcom.com>
References: <1455977964-8099-1-git-send-email-jchandra@broadcom.com>
Message-ID: <1455977964-8099-4-git-send-email-jchandra@broadcom.com>

Enable Broadcom Vulcan support in arm64 default configuration. This will
build the device tree needed to boot on a Broadcom Vulcan board.

Signed-off-by: Jayachandran C <jchandra at broadcom.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 86581f7..6c1b3a6 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -47,6 +47,7 @@ CONFIG_ARCH_SPRD=y
 CONFIG_ARCH_THUNDER=y
 CONFIG_ARCH_UNIPHIER=y
 CONFIG_ARCH_VEXPRESS=y
+CONFIG_ARCH_VULCAN=y
 CONFIG_ARCH_XGENE=y
 CONFIG_ARCH_ZYNQMP=y
 CONFIG_PCI=y
-- 
1.9.1



From jchandra at broadcom.com  Sat Feb 20 06:19:21 2016
From: jchandra at broadcom.com (Jayachandran C)
Date: Sat, 20 Feb 2016 19:49:21 +0530
Subject: [PATCH v2 2/5] dt-bindings: Add documentation for Broadcom Vulcan
In-Reply-To: <1455977964-8099-1-git-send-email-jchandra@broadcom.com>
References: <1455977964-8099-1-git-send-email-jchandra@broadcom.com>
Message-ID: <1455977964-8099-3-git-send-email-jchandra@broadcom.com>

Update arm/cpus.txt to add "brcm,vulcan" CPU. Add documentation
for Broadcom Vulcan boards in arm/bcm/brcm,vulcan-soc.txt

Signed-off-by: Jayachandran C <jchandra at broadcom.com>
---
 Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.txt | 10 ++++++++++
 Documentation/devicetree/bindings/arm/cpus.txt                |  1 +
 2 files changed, 11 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.txt
new file mode 100644
index 0000000..223ed34
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.txt
@@ -0,0 +1,10 @@
+Broadcom Vulcan device tree bindings
+------------------------------------
+
+Boards with Broadcom Vulcan shall have the following root property:
+
+Broadcom Vulcan Evaluation Board:
+  compatible = "brcm,vulcan-eval", "brcm,vulcan-soc";
+
+Generic Vulcan board:
+  compatible = "brcm,vulcan-soc";
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index ae9be07..bc43ad7 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -167,6 +167,7 @@ nodes to be present and contain the properties described below.
 			    "arm,cortex-r5"
 			    "arm,cortex-r7"
 			    "brcm,brahma-b15"
+			    "brcm,vulcan"
 			    "cavium,thunder"
 			    "faraday,fa526"
 			    "intel,sa110"
-- 
1.9.1



From jchandra at broadcom.com  Sat Feb 20 06:19:20 2016
From: jchandra at broadcom.com (Jayachandran C)
Date: Sat, 20 Feb 2016 19:49:20 +0530
Subject: [PATCH v2 1/5] arm64: Broadcom Vulcan support
In-Reply-To: <1455977964-8099-1-git-send-email-jchandra@broadcom.com>
References: <1455977964-8099-1-git-send-email-jchandra@broadcom.com>
Message-ID: <1455977964-8099-2-git-send-email-jchandra@broadcom.com>

From: Zi Shen Lim <zlim at broadcom.com>

Add a configuration option and a device tree for Broadcom's Vulcan
ARM64 processor. vulcan.dtsi has the on-chip blocks like the PCIe
controller, GICv3 with ITS, PMU, system timer and the pl011 UART.
vulcan-eval.dts has definitions for a basic evaluation board.

Vulcan's processor cores support the ARMv8.1 instruction set and
will use "brcm,vulcan" as the compatible property. The firmware
has PSCI 0.2 support for cpu wakeup.

Signed-off-by: Zi Shen Lim <zlim at broadcom.com>
[ updated and split dts - jchandra at broadcom.com ]
Signed-off-by: Jayachandran C <jchandra at broadcom.com>
---
 arch/arm64/Kconfig.platforms                 |   5 +
 arch/arm64/boot/dts/broadcom/Makefile        |   1 +
 arch/arm64/boot/dts/broadcom/vulcan-eval.dts |  33 ++++++
 arch/arm64/boot/dts/broadcom/vulcan.dtsi     | 144 +++++++++++++++++++++++++++
 4 files changed, 183 insertions(+)
 create mode 100644 arch/arm64/boot/dts/broadcom/vulcan-eval.dts
 create mode 100644 arch/arm64/boot/dts/broadcom/vulcan.dtsi

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f6..75e1bfe 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -131,6 +131,11 @@ config ARCH_VEXPRESS
 	  This enables support for the ARMv8 software model (Versatile
 	  Express).
 
+config ARCH_VULCAN
+	bool "Broadcom Vulcan SOC Family"
+	help
+	  This enables support for Broadcom Vulcan SoC Family
+
 config ARCH_XGENE
 	bool "AppliedMicro X-Gene SOC Family"
 	help
diff --git a/arch/arm64/boot/dts/broadcom/Makefile b/arch/arm64/boot/dts/broadcom/Makefile
index e21fe66..bec1f8b 100644
--- a/arch/arm64/boot/dts/broadcom/Makefile
+++ b/arch/arm64/boot/dts/broadcom/Makefile
@@ -1,4 +1,5 @@
 dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb
+dtb-$(CONFIG_ARCH_VULCAN) += vulcan-eval.dtb
 
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
diff --git a/arch/arm64/boot/dts/broadcom/vulcan-eval.dts b/arch/arm64/boot/dts/broadcom/vulcan-eval.dts
new file mode 100644
index 0000000..9ee8d3d
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/vulcan-eval.dts
@@ -0,0 +1,33 @@
+/*
+ * dts file for Broadcom (BRCM) Vulcan Evaluation Platform
+ *
+ * Copyright (c) 2013-2016 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+/dts-v1/;
+
+#include "vulcan.dtsi"
+
+/ {
+	model = "Broadcom Vulcan Eval Platform";
+	compatible = "brcm,vulcan-eval", "brcm,vulcan-soc";
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x80000000 0x0 0x80000000>,  /* 2G @ 2G  */
+		      <0x00000008 0x80000000 0x0 0x80000000>;  /* 2G @ 34G */
+	};
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
diff --git a/arch/arm64/boot/dts/broadcom/vulcan.dtsi b/arch/arm64/boot/dts/broadcom/vulcan.dtsi
new file mode 100644
index 0000000..c49b5a8
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/vulcan.dtsi
@@ -0,0 +1,144 @@
+/*
+ * dtsi file for Broadcom (BRCM) Vulcan processor
+ *
+ * Copyright (c) 2013-2016 Broadcom
+ * Author: Zi Shen Lim <zlim at broadcom.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	model = "Broadcom Vulcan";
+	compatible = "brcm,vulcan-soc";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	/* just 4 cpus now, 128 needed in full config */
+	cpus {
+		#address-cells = <0x2>;
+		#size-cells = <0x0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "brcm,vulcan", "arm,armv8";
+			reg = <0x0 0x0>;
+			enable-method = "psci";
+		};
+
+		cpu at 1 {
+			device_type = "cpu";
+			compatible = "brcm,vulcan", "arm,armv8";
+			reg = <0x0 0x1>;
+			enable-method = "psci";
+		};
+
+		cpu at 2 {
+			device_type = "cpu";
+			compatible = "brcm,vulcan", "arm,armv8";
+			reg = <0x0 0x2>;
+			enable-method = "psci";
+		};
+
+		cpu at 3 {
+			device_type = "cpu";
+			compatible = "brcm,vulcan", "arm,armv8";
+			reg = <0x0 0x3>;
+			enable-method = "psci";
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	gic: interrupt-controller at 400080000 {
+		compatible = "arm,gic-v3";
+		#interrupt-cells = <3>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		interrupt-controller;
+		#redistributor-regions = <1>;
+		reg = <0x04 0x00080000 0x0 0x20000>,	/* GICD */
+		      <0x04 0x01000000 0x0 0x1000000>;	/* GICR */
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+
+		gicits: gic-its at 40010000 {
+			compatible = "arm,gic-v3-its";
+			msi-controller;
+			reg = <0x04 0x00100000 0x0 0x20000>;	/* GIC ITS */
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	pmu {
+		compatible = "arm,armv8-pmuv3";
+		interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>; /* PMU overflow */
+	};
+
+	clk125mhz: uart_clk125mhz {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <125000000>;
+		clock-output-names = "clk125mhz";
+	};
+
+	pci {
+		compatible = "pci-host-ecam-generic";
+		device_type = "pci";
+		#interrupt-cells = <1>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+
+		/* ECAM at 0x3000_0000 - 0x4000_0000 */
+		reg = <0x0 0x30000000  0x0 0x10000000>;
+		reg-names = "PCI ECAM";
+
+			  /* IO 0x4000_0000 - 0x4001_0000 */
+		ranges = <0x01000000 0 0x40000000 0 0x40000000 0 0x00010000
+			  /* MEM 0x4800_0000 - 0x5000_0000 */
+			  0x02000000 0 0x48000000 0 0x48000000 0 0x08000000
+			  /* MEM64 pref 0x6_0000_0000 - 0x7_0000_0000 */
+			  0x43000000 6 0x00000000 6 0x00000000 1 0x00000000>;
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map =
+		      /* addr  pin  ic   icaddr  icintr */
+			<0 0 0  1  &gic   0 0    GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH
+			 0 0 0  2  &gic   0 0    GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH
+			 0 0 0  3  &gic   0 0    GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH
+			 0 0 0  4  &gic   0 0    GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+		msi-parent = <&gicits>;
+		dma-coherent;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		uart0: serial at 402020000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x04 0x02020000 0x0 0x1000>;
+			interrupt-parent = <&gic>;
+			interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&clk125mhz>;
+			clock-names = "apb_pclk";
+		};
+	};
+
+};
-- 
1.9.1



From jchandra at broadcom.com  Sat Feb 20 06:19:23 2016
From: jchandra at broadcom.com (Jayachandran C)
Date: Sat, 20 Feb 2016 19:49:23 +0530
Subject: [PATCH v2 4/5] arm64: cputype info for Broadcom Vulcan
In-Reply-To: <1455977964-8099-1-git-send-email-jchandra@broadcom.com>
References: <1455977964-8099-1-git-send-email-jchandra@broadcom.com>
Message-ID: <1455977964-8099-5-git-send-email-jchandra@broadcom.com>

Add Broadcom Vulcan implementor ID and part ID in cputype.h. This is
to document the values.

Signed-off-by: Jayachandran C <jchandra at broadcom.com>
Acked-by: Will Deacon <will.deacon at arm.com>
Acked-by: Catalin Marinas <catalin.marinas at arm.com>
---
 arch/arm64/include/asm/cputype.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 1a59493..3dcecdf 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -65,6 +65,7 @@
 #define ARM_CPU_IMP_ARM			0x41
 #define ARM_CPU_IMP_APM			0x50
 #define ARM_CPU_IMP_CAVIUM		0x43
+#define ARM_CPU_IMP_BRCM		0x42
 
 #define ARM_CPU_PART_AEM_V8		0xD0F
 #define ARM_CPU_PART_FOUNDATION		0xD00
@@ -75,6 +76,8 @@
 
 #define CAVIUM_CPU_PART_THUNDERX	0x0A1
 
+#define BRCM_CPU_PART_VULCAN		0x516
+
 #ifndef __ASSEMBLY__
 
 /*
-- 
1.9.1



From jchandra at broadcom.com  Sat Feb 20 06:19:24 2016
From: jchandra at broadcom.com (Jayachandran C)
Date: Sat, 20 Feb 2016 19:49:24 +0530
Subject: [PATCH v2 5/5] MAINTAINERS: Add entry for Broadcom Vulcan SoC
In-Reply-To: <1455977964-8099-1-git-send-email-jchandra@broadcom.com>
References: <1455977964-8099-1-git-send-email-jchandra@broadcom.com>
Message-ID: <1455977964-8099-6-git-send-email-jchandra@broadcom.com>

Add maintainer information for Broadcom's Vulcan arm64 SoC.

Signed-off-by: Jayachandran C <jchandra at broadcom.com>
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index cc2f753..eac98eb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2512,6 +2512,13 @@ L:	netdev at vger.kernel.org
 S:	Supported
 F:	drivers/net/ethernet/broadcom/bcmsysport.*
 
+BROADCOM VULCAN ARM64 SOC
+M:	Jayachandran C. <jchandra at broadcom.com>
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+L:	bcm-kernel-feedback-list at broadcom.com
+S:	Maintained
+F:	arch/arm64/boot/dts/broadcom/vulcan*
+
 BROCADE BFA FC SCSI DRIVER
 M:	Anil Gurumurthy <anil.gurumurthy at qlogic.com>
 M:	Sudarsana Kalluru <sudarsana.kalluru at qlogic.com>
-- 
1.9.1



From robert.jarzmik at free.fr  Sat Feb 20 06:37:57 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat, 20 Feb 2016 15:37:57 +0100
Subject: [PATCH 2/4] ASoC: wm9713: add device tree support
In-Reply-To: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
References: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
Message-ID: <1455979079-9030-2-git-send-email-robert.jarzmik@free.fr>

Add the code to be able to use this codec in a devicetree platform.
This is tested with the zylonite pxa310 board.

Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
 sound/soc/codecs/wm9713.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/sound/soc/codecs/wm9713.c b/sound/soc/codecs/wm9713.c
index 79e143625ac3..4e522302bb8a 100644
--- a/sound/soc/codecs/wm9713.c
+++ b/sound/soc/codecs/wm9713.c
@@ -1272,9 +1272,19 @@ static int wm9713_remove(struct platform_device *pdev)
 	return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id wm9713_dt_ids[] = {
+	{ .compatible = "wlf,wm9713", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, wm9713_dt_ids);
+
+#endif
+
 static struct platform_driver wm9713_codec_driver = {
 	.driver = {
 			.name = "wm9713-codec",
+			.of_match_table = of_match_ptr(wm9713_dt_ids),
 	},
 
 	.probe = wm9713_probe,
-- 
2.1.4



From robert.jarzmik at free.fr  Sat Feb 20 06:37:59 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat, 20 Feb 2016 15:37:59 +0100
Subject: [PATCH 4/4] ASoC: pxa: add pxa2xx-ac97 devicetree support
In-Reply-To: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
References: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
Message-ID: <1455979079-9030-4-git-send-email-robert.jarzmik@free.fr>

Add the devicetree support, so that the driver can be used in a
devicetree platform.

Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
 sound/arm/pxa2xx-ac97-lib.c | 11 +++++++++++
 sound/soc/pxa/pxa2xx-ac97.c | 10 ++++++++++
 2 files changed, 21 insertions(+)

diff --git a/sound/arm/pxa2xx-ac97-lib.c b/sound/arm/pxa2xx-ac97-lib.c
index 39c3969ac1c7..37fe7e0cbcf1 100644
--- a/sound/arm/pxa2xx-ac97-lib.c
+++ b/sound/arm/pxa2xx-ac97-lib.c
@@ -19,6 +19,7 @@
 #include <linux/module.h>
 #include <linux/io.h>
 #include <linux/gpio.h>
+#include <linux/of_gpio.h>
 
 #include <sound/ac97_codec.h>
 #include <sound/pxa2xx-lib.h>
@@ -332,6 +333,16 @@ int pxa2xx_ac97_hw_probe(struct platform_device *dev)
 			dev_err(&dev->dev, "Invalid reset GPIO %d\n",
 				pdata->reset_gpio);
 		}
+	} else if (!pdata && dev->dev.of_node) {
+		pdata = devm_kzalloc(&dev->dev, sizeof(*pdata), GFP_KERNEL);
+		if (!pdata)
+			return -ENOMEM;
+		pdata->reset_gpio = of_get_named_gpio(dev->dev.of_node,
+						      "reset-gpio", 0);
+		if (pdata->reset_gpio == -ENOENT)
+			pdata->reset_gpio = -1;
+		else if (pdata->reset_gpio < 0)
+			return pdata->reset_gpio;
 	} else {
 		if (cpu_is_pxa27x())
 			reset_gpio = 113;
diff --git a/sound/soc/pxa/pxa2xx-ac97.c b/sound/soc/pxa/pxa2xx-ac97.c
index f3de615aacd7..13e3ab9224b9 100644
--- a/sound/soc/pxa/pxa2xx-ac97.c
+++ b/sound/soc/pxa/pxa2xx-ac97.c
@@ -221,6 +221,15 @@ static const struct snd_soc_component_driver pxa_ac97_component = {
 	.name		= "pxa-ac97",
 };
 
+#ifdef CONFIG_OF
+static const struct of_device_id pxa2xx_ac97_dt_ids[] = {
+	{ .compatible = "marvell,pxa2xx-ac97", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, pxa2xx_ac97_dt_ids);
+
+#endif
+
 static int pxa2xx_ac97_dev_probe(struct platform_device *pdev)
 {
 	int ret;
@@ -279,6 +288,7 @@ static struct platform_driver pxa2xx_ac97_driver = {
 #ifdef CONFIG_PM_SLEEP
 		.pm	= &pxa2xx_ac97_pm_ops,
 #endif
+		.of_match_table = of_match_ptr(pxa2xx_ac97_dt_ids),
 	},
 };
 
-- 
2.1.4



From robert.jarzmik at free.fr  Sat Feb 20 06:37:56 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat, 20 Feb 2016 15:37:56 +0100
Subject: [PATCH 1/4] ASoC: wm9713: add binding for WM9713 codec
Message-ID: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>

This adds a binding for the Wolfson WM9713 audio codec.

Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
 Documentation/devicetree/bindings/sound/wm9713.txt | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/wm9713.txt

diff --git a/Documentation/devicetree/bindings/sound/wm9713.txt b/Documentation/devicetree/bindings/sound/wm9713.txt
new file mode 100644
index 000000000000..761001bc3201
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/wm9713.txt
@@ -0,0 +1,14 @@
+WM9713 audio CODEC
+
+This devices supports I2C.
+
+Required properties:
+  - compatible :
+	"wlf,wm9713"
+
+Example:
+	wm9713: wm9713 at 0 {
+		compatible = "wlf,wm9713";
+		#sound-dai-cells = <1>;
+		status = "okay";
+	};
-- 
2.1.4



From robert.jarzmik at free.fr  Sat Feb 20 06:37:58 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat, 20 Feb 2016 15:37:58 +0100
Subject: [PATCH 3/4] ASoC: pxa: add binding for pxa2xx-ac97 audio complex
In-Reply-To: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
References: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
Message-ID: <1455979079-9030-3-git-send-email-robert.jarzmik@free.fr>

This adds a binding for the Marvell PXA audio complex, available in
pxa2xx and pxa3xx variants.

Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
 .../bindings/sound/marvell,pxa2xx-ac97.txt         | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt

diff --git a/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt b/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
new file mode 100644
index 000000000000..b3f2882d9c7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
@@ -0,0 +1,25 @@
+Marvell PXA2xx audio complex
+
+This descriptions matches the AC97 controller found in pxa2xx and pxa3xx series.
+
+Required properties:
+  - compatible: "marvell,pxa2xx-ac97"
+  - reg: device MMIO address space
+  - interrupts: single interrupt generated by AC97 IP
+  - clocks: input clock of the AC97 IP, refer to clock-bindings.txt
+
+Optional properties:
+  - pinctrl-names, pinctrl-0: refer to pinctrl-bindings.txt
+  - reset-gpio: gpio used for AC97 reset, refer to gpio.txt
+
+Example:
+	ac97: sound at 40500000 {
+	      	compatible = "marvell,pxa2xx-ac97";
+		reg = < 0x40500000 0x1000 >;
+		interrupts = <14>;
+		reset-gpio = <&gpio 113 GPIO_ACTIVE_HIGH>;
+		#sound-dai-cells = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = < &pmux_ac97_default >;
+		status = "okay";
+	};
-- 
2.1.4



From leo.yan at linaro.org  Sat Feb 20 07:52:06 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 20 Feb 2016 23:52:06 +0800
Subject: [PATCH 0/3] thermal: hisilicon: enable power allocator for Hi6220
Message-ID: <1455983529-9559-1-git-send-email-leo.yan@linaro.org>

Hi6220 has octa-core so it has quite high power consumption when run
benchmark and introduces high temperature for SoC. So need enable
thermal gover to control temperature and also cannot hurt much for
performance after impose cooling operations on CPU.

This patch series is to enable power allocator for Hi6220. The power
allocator just uses only one sensor, so patch 1 is to fix sensor driver
so let it can initialize driver successfully with only enabling one
sensor.

After profiling on Hikey, the power model has been simplized with only
dynamic coefficent, and now it's convienence to pass it from CPU node.
So patch 2 and 3 bind sensor and pass power model parameters.

This patch series have been tested on 96boards Hikey.


Leo Yan (3):
  thermal: hisilicon: support to use any sensor
  arm64: dts: register Hi6220's thermal sensor
  arm64: dts: register Hi6220's thermal zone for power allocator

 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 45 +++++++++++++++++++++++++++++++
 drivers/thermal/hisi_thermal.c            | 33 ++++++++++++++---------
 2 files changed, 65 insertions(+), 13 deletions(-)

-- 
1.9.1



From leo.yan at linaro.org  Sat Feb 20 07:52:07 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 20 Feb 2016 23:52:07 +0800
Subject: [PATCH 1/3] thermal: hisilicon: support to use any sensor
In-Reply-To: <1455983529-9559-1-git-send-email-leo.yan@linaro.org>
References: <1455983529-9559-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1455983529-9559-2-git-send-email-leo.yan@linaro.org>

In current code sensor driver registers all 4 sensors together and if
any of them has not bound to thermal zone successfully then driver will
return failure for driver's initialization. As a result, if DT binds
thermal zone with only one sensor, then the thermal driver will not work
well anymore.

So this patch is to fix this issue. It allows the thermal sensor driver
can register any number sensors at initialization phase, and fix up code
for other related code to skip related sensor's accessing if the sensor
has not been enabled in initialization phase.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 drivers/thermal/hisi_thermal.c | 33 ++++++++++++++++++++-------------
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 5e820b5..7a3e5d8 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -160,7 +160,7 @@ static int hisi_thermal_get_temp(void *_sensor, int *temp)
 	struct hisi_thermal_sensor *sensor = _sensor;
 	struct hisi_thermal_data *data = sensor->thermal;
 
-	int sensor_id = 0, i;
+	int sensor_id = -1, i;
 	long max_temp = 0;
 
 	*temp = hisi_thermal_get_sensor_temp(data, sensor);
@@ -168,12 +168,19 @@ static int hisi_thermal_get_temp(void *_sensor, int *temp)
 	sensor->sensor_temp = *temp;
 
 	for (i = 0; i < HISI_MAX_SENSORS; i++) {
+		if (!data->sensors[i].tzd)
+			continue;
+
 		if (data->sensors[i].sensor_temp >= max_temp) {
 			max_temp = data->sensors[i].sensor_temp;
 			sensor_id = i;
 		}
 	}
 
+	/* If no sensor has been enabled, then skip to enable irq */
+	if (sensor_id == -1)
+		return 0;
+
 	mutex_lock(&data->thermal_lock);
 	data->irq_bind_sensor = sensor_id;
 	mutex_unlock(&data->thermal_lock);
@@ -226,8 +233,12 @@ static irqreturn_t hisi_thermal_alarm_irq_thread(int irq, void *dev)
 		 sensor->thres_temp / 1000);
 	mutex_unlock(&data->thermal_lock);
 
-	for (i = 0; i < HISI_MAX_SENSORS; i++)
+	for (i = 0; i < HISI_MAX_SENSORS; i++) {
+		if (!data->sensors[i].tzd)
+			continue;
+
 		thermal_zone_device_update(data->sensors[i].tzd);
+	}
 
 	return IRQ_HANDLED;
 }
@@ -247,6 +258,7 @@ static int hisi_thermal_register_sensor(struct platform_device *pdev,
 				sensor, &hisi_of_thermal_ops);
 	if (IS_ERR(sensor->tzd)) {
 		ret = PTR_ERR(sensor->tzd);
+		sensor->tzd = NULL;
 		dev_err(&pdev->dev, "failed to register sensor id %d: %d\n",
 			sensor->id, ret);
 		return ret;
@@ -334,25 +346,17 @@ static int hisi_thermal_probe(struct platform_device *pdev)
 	for (i = 0; i < HISI_MAX_SENSORS; ++i) {
 		ret = hisi_thermal_register_sensor(pdev, data,
 						   &data->sensors[i], i);
-		if (ret) {
+		if (ret)
 			dev_err(&pdev->dev,
 				"failed to register thermal sensor: %d\n", ret);
-			goto err_get_sensor_data;
-		}
+		else
+			hisi_thermal_toggle_sensor(&data->sensors[i], true);
 	}
 
 	hisi_thermal_enable_bind_irq_sensor(data);
 	data->irq_enabled = true;
 
-	for (i = 0; i < HISI_MAX_SENSORS; i++)
-		hisi_thermal_toggle_sensor(&data->sensors[i], true);
-
 	return 0;
-
-err_get_sensor_data:
-	clk_disable_unprepare(data->clk);
-
-	return ret;
 }
 
 static int hisi_thermal_remove(struct platform_device *pdev)
@@ -363,6 +367,9 @@ static int hisi_thermal_remove(struct platform_device *pdev)
 	for (i = 0; i < HISI_MAX_SENSORS; i++) {
 		struct hisi_thermal_sensor *sensor = &data->sensors[i];
 
+		if (!sensor->tzd)
+			continue;
+
 		hisi_thermal_toggle_sensor(sensor, false);
 		thermal_zone_of_sensor_unregister(&pdev->dev, sensor->tzd);
 	}
-- 
1.9.1



From leo.yan at linaro.org  Sat Feb 20 07:52:08 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 20 Feb 2016 23:52:08 +0800
Subject: [PATCH 2/3] arm64: dts: register Hi6220's thermal sensor
In-Reply-To: <1455983529-9559-1-git-send-email-leo.yan@linaro.org>
References: <1455983529-9559-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1455983529-9559-3-git-send-email-leo.yan@linaro.org>

Bind thermal sensor driver for Hi6220.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index f588be9..50ba1b0 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -313,5 +313,14 @@
 			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
 			#mbox-cells = <3>;
 		};
+
+		tsensor: tsensor at 0,f7030700 {
+			compatible = "hisilicon,tsensor";
+			reg = <0x0 0xf7030700 0x0 0x1000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&sys_ctrl 22>;
+			clock-names = "thermal_clk";
+			#thermal-sensor-cells = <1>;
+		};
 	};
 };
-- 
1.9.1



From leo.yan at linaro.org  Sat Feb 20 07:52:09 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Sat, 20 Feb 2016 23:52:09 +0800
Subject: [PATCH 3/3] arm64: dts: register Hi6220's thermal zone for power
 allocator
In-Reply-To: <1455983529-9559-1-git-send-email-leo.yan@linaro.org>
References: <1455983529-9559-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1455983529-9559-4-git-send-email-leo.yan@linaro.org>

With profiling Hi6220's power modeling so get dynamic coefficient and
sustainable power. So pass these parameters from DT.

Now enable power allocator wit only one actor for CPU part, so directly
use cluster0's thermal sensor for monitoring temperature.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 36 +++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 50ba1b0..3608a3e 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -6,6 +6,7 @@
 
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/hi6220-clock.h>
+#include <dt-bindings/thermal/thermal.h>
 
 / {
 	compatible = "hisilicon,hi6220";
@@ -87,6 +88,7 @@
 			cooling-max-level = <0>;
 			#cooling-cells = <2>; /* min followed by max */
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
+			dynamic-power-coefficient = <311>;
 		};
 
 		cpu1: cpu at 1 {
@@ -322,5 +324,39 @@
 			clock-names = "thermal_clk";
 			#thermal-sensor-cells = <1>;
 		};
+
+		thermal-zones {
+
+			cls0: cls0 {
+				polling-delay = <1000>;
+				polling-delay-passive = <100>;
+				sustainable-power = <3326>;
+
+				/* sensor ID */
+				thermal-sensors = <&tsensor 2>;
+
+				trips {
+					threshold: trip-point at 0 {
+						temperature = <65000>;
+						hysteresis = <1000>;
+						type = "passive";
+					};
+
+					target: trip-point at 1 {
+						temperature = <75000>;
+						hysteresis = <1000>;
+						type = "passive";
+					};
+				};
+
+				cooling-maps {
+					map0 {
+						trip = <&target>;
+						contribution = <1024>;
+						cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+					};
+				};
+			};
+		};
 	};
 };
-- 
1.9.1



From broonie at kernel.org  Sat Feb 20 09:14:59 2016
From: broonie at kernel.org (Mark Brown)
Date: Sun, 21 Feb 2016 02:14:59 +0900
Subject: [PATCH 1/4] ASoC: wm9713: add binding for WM9713 codec
In-Reply-To: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
References: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
Message-ID: <20160220171459.GA18327@sirena.org.uk>

On Sat, Feb 20, 2016 at 03:37:56PM +0100, Robert Jarzmik wrote:

> +WM9713 audio CODEC
> +
> +This devices supports I2C.

No, it clearly doesn't...  The problem with doing this is that since
AC'97 is an enumerable bus we really shouldn't need to list AC'97 CODECs
in the device tree.  Instead we should be probing at runtime (as the
non-ASoC AC'97 code does) or something similar.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160221/8be5e8ff/attachment.sig>

From michael at amarulasolutions.com  Sat Feb 20 09:18:23 2016
From: michael at amarulasolutions.com (Michael Trimarchi)
Date: Sat, 20 Feb 2016 18:18:23 +0100
Subject: [PATCH 1/4] ARM: dts: imx6ul: Add flexcan1 and flexcan2 support
In-Reply-To: <CAOMZO5Bk_ZMhYzFLRFNK2TQvK4KHuj62AM_6uF-m-P1kJupTHQ@mail.gmail.com>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
 <1455963652-24618-2-git-send-email-michael@amarulasolutions.com>
 <CAOMZO5Bk_ZMhYzFLRFNK2TQvK4KHuj62AM_6uF-m-P1kJupTHQ@mail.gmail.com>
Message-ID: <20160220171816.GA24064@panicking>

Hi Fabio

On Sat, Feb 20, 2016 at 12:02:51PM -0200, Fabio Estevam wrote:
> On Sat, Feb 20, 2016 at 8:20 AM, Michael Trimarchi
> <michael at amarulasolutions.com> wrote:
> 
> > +
> > +                               flexcan1: can at 02090000 {
> > +                                       compatible = "fsl,imx6ul-flexcan", "fsl,imx6q-flexcan";
> > +                                       reg = <0x02090000 0x4000>;
> > +                                       interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
> > +                                       clocks = <&clks IMX6UL_CLK_CAN1_IPG>,
> > +                                                <&clks IMX6UL_CLK_CAN1_SERIAL>;
> > +                                       clock-names = "ipg", "per";
> > +                                       stop-mode = <&gpr 0x10 1 0x10 17>;
> 
> This 'stop-mode' property is not handled in mainline, only in NXP
> kernel, so I suggest to drop this.

ok. Can you point me out to a driver in freescale source that use it?

Michael

-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |


From michael at amarulasolutions.com  Sat Feb 20 09:19:28 2016
From: michael at amarulasolutions.com (Michael Trimarchi)
Date: Sat, 20 Feb 2016 18:19:28 +0100
Subject: [PATCH 4/4] ARM: dts: imx6ul-geam: Add Engicam IMX6UL GEA M6UL
 initial support
In-Reply-To: <CAOMZO5AmePs3aE2zRSXcSS8iKQ0m2kvTAezsfHS13e-Zv1HCrA@mail.gmail.com>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
 <1455963652-24618-5-git-send-email-michael@amarulasolutions.com>
 <CAOMZO5AmePs3aE2zRSXcSS8iKQ0m2kvTAezsfHS13e-Zv1HCrA@mail.gmail.com>
Message-ID: <20160220171921.GB24064@panicking>

Hi Fabio

On Sat, Feb 20, 2016 at 12:11:14PM -0200, Fabio Estevam wrote:
> On Sat, Feb 20, 2016 at 8:20 AM, Michael Trimarchi
> <michael at amarulasolutions.com> wrote:
> 
> > +       reg_1p8v: regulator-1p8v {
> > +               compatible = "regulator-fixed";
> > +               regulator-name = "1P8V";
> > +               regulator-min-microvolt = <1800000>;
> > +               regulator-max-microvolt = <1800000>;
> > +               regulator-boot-on;
> > +               regulator-always-on;
> 
> These last two properties can be removed.
> 

This map the phy connection. Regulator are really always on and they
are always on

Michael

> > +       };
> > +
> > +       reg_3p3v: regulator-3p3v {
> > +               compatible = "regulator-fixed";
> > +               regulator-name = "3P3V";
> > +               regulator-min-microvolt = <3300000>;
> > +               regulator-max-microvolt = <3300000>;
> > +               regulator-boot-on;
> > +               regulator-always-on;
> 
> Ditto.
> 
> > +       pinctrl_spi4: spi4grp {
> > +               fsl,pins = <
> > +                       MX6UL_PAD_BOOT_MODE0__GPIO5_IO10        0x70a1
> > +                       MX6UL_PAD_BOOT_MODE1__GPIO5_IO11        0x70a1
> > +                       MX6UL_PAD_SNVS_TAMPER7__GPIO5_IO07      0x70a1
> > +                       MX6UL_PAD_SNVS_TAMPER8__GPIO5_IO08      0x80000000
> > +               >;
> > +       };
> 
> pinctrl_spi4 seems to be unused.

-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |


From michael at amarulasolutions.com  Sat Feb 20 09:21:33 2016
From: michael at amarulasolutions.com (Michael Trimarchi)
Date: Sat, 20 Feb 2016 18:21:33 +0100
Subject: [PATCH 3/4] ARM: dts: imx6ul: Add GPMI nand controller support
In-Reply-To: <CAOMZO5DTmG7Umt+H20r+tZi9zZhsK=eoPbHOBO3iwvM2GXXLgg@mail.gmail.com>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
 <1455963652-24618-4-git-send-email-michael@amarulasolutions.com>
 <CAOMZO5DTmG7Umt+H20r+tZi9zZhsK=eoPbHOBO3iwvM2GXXLgg@mail.gmail.com>
Message-ID: <20160220172127.GC24064@panicking>

Hi

On Sat, Feb 20, 2016 at 09:57:27AM -0200, Fabio Estevam wrote:
> Hi Michael,
> 
> On Sat, Feb 20, 2016 at 8:20 AM, Michael Trimarchi
> <michael at amarulasolutions.com> wrote:
> > Add support for GPMI nand controller.
> >
> > Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
> > ---
> >  arch/arm/boot/dts/imx6ul.dtsi          | 33 +++++++++++++++++++++++++++++++++
> >  drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 10 ++++++++++
> >  drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  6 ++++--
> 
> It would be better to split the dts and mtd parts in two patches.

I'm thinking even to drop the IS_TYPE for the IMX6QUL. Does it make sense
to have or let compatible to the one that is already defined?

Michael

-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |


From broonie at kernel.org  Fri Feb 19 08:21:35 2016
From: broonie at kernel.org (Mark Brown)
Date: Sat, 20 Feb 2016 01:21:35 +0900
Subject: [PATCH v6 1/2] dt-bindings: sunxi :add sun4i SPDIF transceiver
In-Reply-To: <1454951361-10625-2-git-send-email-codekipper@gmail.com>
References: <1454951361-10625-1-git-send-email-codekipper@gmail.com>
 <1454951361-10625-2-git-send-email-codekipper@gmail.com>
Message-ID: <20160219162135.GZ18327@sirena.org.uk>

On Mon, Feb 08, 2016 at 06:09:20PM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
> 
> Add devicetree bindings for the SPDIF transceiver found on
> found on Allwinners A10 and A20 SoCs.

Please use subject lines matching the style for the subsystem.  This
makes it easier for people to identify relevant patches.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160220/92041e51/attachment-0001.sig>

From broonie at kernel.org  Fri Feb 19 07:37:44 2016
From: broonie at kernel.org (Mark Brown)
Date: Sat, 20 Feb 2016 00:37:44 +0900
Subject: [PATCH] ASoC: mediatek: Add machine driver for ALC5650 codec
In-Reply-To: <1455849359-14581-1-git-send-email-pc.liao@mediatek.com>
References: <1455849359-14581-1-git-send-email-pc.liao@mediatek.com>
Message-ID: <20160219153744.GP18327@sirena.org.uk>

On Fri, Feb 19, 2016 at 10:35:59AM +0800, PC Liao wrote:

> @@ -3,3 +3,4 @@ obj-$(CONFIG_SND_SOC_MEDIATEK) += mtk-afe-pcm.o
>  # Machine support
>  obj-$(CONFIG_SND_SOC_MT8173_MAX98090) += mt8173-max98090.o
>  obj-$(CONFIG_SND_SOC_MT8173_RT5650_RT5676) += mt8173-rt5650-rt5676.o
> +obj-$(CONFIG_SND_SOC_MT8173_RT5650) += mt8173-rt5650.o

Why is this not covered by (or coverable by) the existinng RT5650-RT5657
driver?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160220/c90df662/attachment.sig>

From festevam at gmail.com  Sat Feb 20 09:29:44 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Sat, 20 Feb 2016 15:29:44 -0200
Subject: [PATCH 1/4] ARM: dts: imx6ul: Add flexcan1 and flexcan2 support
In-Reply-To: <20160220171816.GA24064@panicking>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
 <1455963652-24618-2-git-send-email-michael@amarulasolutions.com>
 <CAOMZO5Bk_ZMhYzFLRFNK2TQvK4KHuj62AM_6uF-m-P1kJupTHQ@mail.gmail.com>
 <20160220171816.GA24064@panicking>
Message-ID: <CAOMZO5DfKi5KymQ6p9yF4ntqEJ7O=EEE7CKFmS-0N2XL8=ET7A@mail.gmail.com>

On Sat, Feb 20, 2016 at 3:18 PM, Michael Trimarchi
<michael at amarulasolutions.com> wrote:

> ok. Can you point me out to a driver in freescale source that use it?

http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/net/can/flexcan.c?h=imx_3.14.52_1.1.0_ga#n1146


From broonie at kernel.org  Fri Feb 19 08:17:49 2016
From: broonie at kernel.org (Mark Brown)
Date: Sat, 20 Feb 2016 01:17:49 +0900
Subject: [PATCH] regulator: qcom-saw: avoid uninitialized variable warning
In-Reply-To: <1455183497-299798-1-git-send-email-arnd@arndb.de>
References: <1455183497-299798-1-git-send-email-arnd@arndb.de>
Message-ID: <20160219161749.GX18327@sirena.org.uk>

On Thu, Feb 11, 2016 at 10:38:08AM +0100, Arnd Bergmann wrote:
> gcc cannot know that a for_each_possible_cpu() loop always executes
> at least once, so it warns about the use of the "found" variable
> in qcom_saw_regulator_probe:

I'm going to drop this driver so this won't be needed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160220/fb3c8d40/attachment.sig>

From broonie at kernel.org  Fri Feb 19 07:51:03 2016
From: broonie at kernel.org (Mark Brown)
Date: Sat, 20 Feb 2016 00:51:03 +0900
Subject: [PATCH 04/12] spi: imx: drop fallback to PIO
In-Reply-To: <1455867792-26389-5-git-send-email-s.hauer@pengutronix.de>
References: <1455867792-26389-1-git-send-email-s.hauer@pengutronix.de>
 <1455867792-26389-5-git-send-email-s.hauer@pengutronix.de>
Message-ID: <20160219155103.GS18327@sirena.org.uk>

On Fri, Feb 19, 2016 at 08:43:04AM +0100, Sascha Hauer wrote:
> At the moment the driver decides to fallback to PIO mode the buffers
> are already mapped for DMA. It's a bug to access them with the CPU
> afterwards, so we cannot just fallback to PIO mode.

This doesn't apply against current code, please check and resend.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160220/a63b0592/attachment.sig>

From festevam at gmail.com  Sat Feb 20 09:30:58 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Sat, 20 Feb 2016 15:30:58 -0200
Subject: [PATCH 4/4] ARM: dts: imx6ul-geam: Add Engicam IMX6UL GEA M6UL
 initial support
In-Reply-To: <20160220171921.GB24064@panicking>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
 <1455963652-24618-5-git-send-email-michael@amarulasolutions.com>
 <CAOMZO5AmePs3aE2zRSXcSS8iKQ0m2kvTAezsfHS13e-Zv1HCrA@mail.gmail.com>
 <20160220171921.GB24064@panicking>
Message-ID: <CAOMZO5CaBaNYAZDOhW2mXDe4OtBmZK7bDRfoQXcKio_tr3ZUBQ@mail.gmail.com>

On Sat, Feb 20, 2016 at 3:19 PM, Michael Trimarchi
<michael at amarulasolutions.com> wrote:

> This map the phy connection. Regulator are really always on and they
> are always on

but they are pointless with this type of regulator.


From alexander.sverdlin at gmail.com  Sat Feb 20 09:59:37 2016
From: alexander.sverdlin at gmail.com (Alexander Sverdlin)
Date: Sat, 20 Feb 2016 18:59:37 +0100
Subject: [PATCH v2 0/5] iio: ADC driver for EP93xx SoC
Message-ID: <56C8A989.9030801@gmail.com>

This series prepares the necessary infrastructure for ADC platform device on
Cirrus Logic EP93xx family of SoCs and adds the driver for ADC device using
IIO subsystem.

Changelog
v2:
  Added Documentation/iio/ep93xx_adc.txt
  Removed extend_name
  Added timeout to the status polling loop
  Used iio_device_register() instead of devm_iio_device_register()

Alexander Sverdlin (5):
  clk: ep93xx: Implement clk_get_parent()
  clk: ep93xx: Add ADC clock
  ep93xx: Add ADC platform device support to core
  edb93xx: Add ADC platform device
  iio: adc: New driver for Cirrus Logic EP93xx ADC

 Documentation/iio/ep93xx_adc.txt             |  29 +++
 arch/arm/mach-ep93xx/clock.c                 |  14 ++
 arch/arm/mach-ep93xx/core.c                  |  24 +++
 arch/arm/mach-ep93xx/edb93xx.c               |   1 +
 arch/arm/mach-ep93xx/include/mach/platform.h |   1 +
 arch/arm/mach-ep93xx/soc.h                   |   1 +
 drivers/iio/adc/Kconfig                      |  11 ++
 drivers/iio/adc/Makefile                     |   1 +
 drivers/iio/adc/ep93xx_adc.c                 | 261 +++++++++++++++++++++++++++
 9 files changed, 343 insertions(+)
 create mode 100644 Documentation/iio/ep93xx_adc.txt
 create mode 100644 drivers/iio/adc/ep93xx_adc.c


From alexander.sverdlin at gmail.com  Sat Feb 20 09:59:45 2016
From: alexander.sverdlin at gmail.com (Alexander Sverdlin)
Date: Sat, 20 Feb 2016 18:59:45 +0100
Subject: [PATCH v2 1/5] clk: ep93xx: Implement clk_get_parent()
In-Reply-To: <56C88EDD.3040007@gmail.com>
References: <56C88EDD.3040007@gmail.com>
Message-ID: <56C8A991.6000506@gmail.com>

Trivial implementation of clk_get_parent(), but necessary for some drivers,
such as ADC.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin at gmail.com>
---
 arch/arm/mach-ep93xx/clock.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-ep93xx/clock.c b/arch/arm/mach-ep93xx/clock.c
index 39ef3b6..b9cd9d7 100644
--- a/arch/arm/mach-ep93xx/clock.c
+++ b/arch/arm/mach-ep93xx/clock.c
@@ -475,6 +475,12 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
 }
 EXPORT_SYMBOL(clk_set_rate);

+struct clk *clk_get_parent(struct clk *clk)
+{
+	return clk->parent;
+}
+EXPORT_SYMBOL(clk_get_parent);
+

 static char fclk_divisors[] = { 1, 2, 4, 8, 16, 1, 1, 1 };
 static char hclk_divisors[] = { 1, 2, 4, 5, 6, 8, 16, 32 };



From alexander.sverdlin at gmail.com  Sat Feb 20 09:59:50 2016
From: alexander.sverdlin at gmail.com (Alexander Sverdlin)
Date: Sat, 20 Feb 2016 18:59:50 +0100
Subject: [PATCH v2 2/5] clk: ep93xx: Add ADC clock
In-Reply-To: <56C88FCB.30008@gmail.com>
References: <56C88EDD.3040007@gmail.com> <56C88FCB.30008@gmail.com>
Message-ID: <56C8A996.8040107@gmail.com>

ADC and keypad controller clocks share the same control register, so use the
existing infrastructure to add ADC clock support for Cirrus Logic EP93xx SoCs.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin at gmail.com>
---
 arch/arm/mach-ep93xx/clock.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-ep93xx/clock.c b/arch/arm/mach-ep93xx/clock.c
index b9cd9d7..4253426 100644
--- a/arch/arm/mach-ep93xx/clock.c
+++ b/arch/arm/mach-ep93xx/clock.c
@@ -98,6 +98,13 @@ static struct clk clk_keypad = {
 	.enable_mask	= EP93XX_SYSCON_KEYTCHCLKDIV_KEN,
 	.set_rate	= set_keytchclk_rate,
 };
+static struct clk clk_adc = {
+	.parent		= &clk_xtali,
+	.sw_locked	= 1,
+	.enable_reg	= EP93XX_SYSCON_KEYTCHCLKDIV,
+	.enable_mask	= EP93XX_SYSCON_KEYTCHCLKDIV_TSEN,
+	.set_rate	= set_keytchclk_rate,
+};
 static struct clk clk_spi = {
 	.parent		= &clk_xtali,
 	.rate		= EP93XX_EXT_CLK_RATE,
@@ -214,6 +221,7 @@ static struct clk_lookup clocks[] = {
 	INIT_CK(NULL,			"pll2",		&clk_pll2),
 	INIT_CK("ohci-platform",	NULL,		&clk_usb_host),
 	INIT_CK("ep93xx-keypad",	NULL,		&clk_keypad),
+	INIT_CK("ep93xx-adc",		NULL,		&clk_adc),
 	INIT_CK("ep93xx-fb",		NULL,		&clk_video),
 	INIT_CK("ep93xx-spi.0",		NULL,		&clk_spi),
 	INIT_CK("ep93xx-i2s",		"mclk",		&clk_i2s_mclk),



From alexander.sverdlin at gmail.com  Sat Feb 20 09:59:56 2016
From: alexander.sverdlin at gmail.com (Alexander Sverdlin)
Date: Sat, 20 Feb 2016 18:59:56 +0100
Subject: [PATCH v2 3/5] ep93xx: Add ADC platform device support to core
In-Reply-To: <56C88FFD.9050504@gmail.com>
References: <56C88EDD.3040007@gmail.com> <56C88FCB.30008@gmail.com>
 <56C88FFD.9050504@gmail.com>
Message-ID: <56C8A99C.7080201@gmail.com>

Newly provided ep93xx_register_adc() could be used by machine-specific code
to create ADC platform device on Cirrus Logic EP93xx SoC-based machines.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin at gmail.com>
---
 arch/arm/mach-ep93xx/core.c                  | 24 ++++++++++++++++++++++++
 arch/arm/mach-ep93xx/include/mach/platform.h |  1 +
 arch/arm/mach-ep93xx/soc.h                   |  1 +
 3 files changed, 26 insertions(+)

diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index c393b1b..f53c618 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -821,6 +821,30 @@ void ep93xx_ide_release_gpio(struct platform_device *pdev)
 EXPORT_SYMBOL(ep93xx_ide_release_gpio);

 /*************************************************************************
+ * EP93xx ADC
+ *************************************************************************/
+static struct resource ep93xx_adc_resources[] = {
+	DEFINE_RES_MEM(EP93XX_ADC_PHYS_BASE, 0x28),
+	DEFINE_RES_IRQ(IRQ_EP93XX_TOUCH),
+};
+
+static struct platform_device ep93xx_adc_device = {
+	.name		= "ep93xx-adc",
+	.id		= -1,
+	.num_resources	= ARRAY_SIZE(ep93xx_adc_resources),
+	.resource	= ep93xx_adc_resources,
+};
+
+void __init ep93xx_register_adc(void)
+{
+	/* Power up ADC, deactivate Touch Screen Controller */
+	ep93xx_devcfg_set_clear(EP93XX_SYSCON_DEVCFG_TIN,
+				EP93XX_SYSCON_DEVCFG_ADCPD);
+
+	platform_device_register(&ep93xx_adc_device);
+}
+
+/*************************************************************************
  * EP93xx Security peripheral
  *************************************************************************/

diff --git a/arch/arm/mach-ep93xx/include/mach/platform.h b/arch/arm/mach-ep93xx/include/mach/platform.h
index 4c0bbd9..db08396 100644
--- a/arch/arm/mach-ep93xx/include/mach/platform.h
+++ b/arch/arm/mach-ep93xx/include/mach/platform.h
@@ -52,6 +52,7 @@ int ep93xx_i2s_acquire(void);
 void ep93xx_i2s_release(void);
 void ep93xx_register_ac97(void);
 void ep93xx_register_ide(void);
+void ep93xx_register_adc(void);
 int ep93xx_ide_acquire_gpio(struct platform_device *pdev);
 void ep93xx_ide_release_gpio(struct platform_device *pdev);

diff --git a/arch/arm/mach-ep93xx/soc.h b/arch/arm/mach-ep93xx/soc.h
index 7bf7ff8..d20e631 100644
--- a/arch/arm/mach-ep93xx/soc.h
+++ b/arch/arm/mach-ep93xx/soc.h
@@ -95,6 +95,7 @@
 #define EP93XX_KEY_MATRIX_PHYS_BASE	EP93XX_APB_PHYS(0x000f0000)
 #define EP93XX_KEY_MATRIX_BASE		EP93XX_APB_IOMEM(0x000f0000)

+#define EP93XX_ADC_PHYS_BASE		EP93XX_APB_PHYS(0x00100000)
 #define EP93XX_ADC_BASE			EP93XX_APB_IOMEM(0x00100000)
 #define EP93XX_TOUCHSCREEN_BASE		EP93XX_APB_IOMEM(0x00100000)




From alexander.sverdlin at gmail.com  Sat Feb 20 10:00:05 2016
From: alexander.sverdlin at gmail.com (Alexander Sverdlin)
Date: Sat, 20 Feb 2016 19:00:05 +0100
Subject: [PATCH v2 4/5] edb93xx: Add ADC platform device
In-Reply-To: <56C89024.3060802@gmail.com>
References: <56C88EDD.3040007@gmail.com> <56C88FCB.30008@gmail.com>
 <56C88FFD.9050504@gmail.com> <56C89024.3060802@gmail.com>
Message-ID: <56C8A9A5.5050908@gmail.com>

This enables the creation of ADC platform device on EDB93xx series of Cirrus
Logic evaluation boards. The driver for this device must be enabled separately,
either as built-in, or a module.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin at gmail.com>
---
 arch/arm/mach-ep93xx/edb93xx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-ep93xx/edb93xx.c b/arch/arm/mach-ep93xx/edb93xx.c
index ad92d9f..8da0127 100644
--- a/arch/arm/mach-ep93xx/edb93xx.c
+++ b/arch/arm/mach-ep93xx/edb93xx.c
@@ -264,6 +264,7 @@ static void __init edb93xx_init_machine(void)
 	edb93xx_register_pwm();
 	edb93xx_register_fb();
 	edb93xx_register_ide();
+	ep93xx_register_adc();
 }





From alexander.sverdlin at gmail.com  Sat Feb 20 10:00:11 2016
From: alexander.sverdlin at gmail.com (Alexander Sverdlin)
Date: Sat, 20 Feb 2016 19:00:11 +0100
Subject: [PATCH v2 5/5] iio: adc: New driver for Cirrus Logic EP93xx ADC
In-Reply-To: <56C89056.7070903@gmail.com>
References: <56C88EDD.3040007@gmail.com> <56C88FCB.30008@gmail.com>
 <56C88FFD.9050504@gmail.com> <56C89024.3060802@gmail.com>
 <56C89056.7070903@gmail.com>
Message-ID: <56C8A9AB.7040506@gmail.com>

New driver adding support for ADC found on Cirrus Logic EP93xx series of SoCs.
Board specific code must take care to create plaform device with all necessary
resources.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin at gmail.com>
---
 Documentation/iio/ep93xx_adc.txt |  29 +++++
 drivers/iio/adc/Kconfig          |  11 ++
 drivers/iio/adc/Makefile         |   1 +
 drivers/iio/adc/ep93xx_adc.c     | 261 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 302 insertions(+)
 create mode 100644 Documentation/iio/ep93xx_adc.txt
 create mode 100644 drivers/iio/adc/ep93xx_adc.c

diff --git a/Documentation/iio/ep93xx_adc.txt b/Documentation/iio/ep93xx_adc.txt
new file mode 100644
index 0000000..321e59f
--- /dev/null
+++ b/Documentation/iio/ep93xx_adc.txt
@@ -0,0 +1,29 @@
+Cirrus Logic EP93xx ADC driver.
+
+1. Overview
+
+The driver is intended to work on both low-end (EP9301, EP9302) devices with
+5-channel ADC and high-end (EP9307, EP9312, EP9315) devices with 10-channel
+touchscreen/ADC module.
+
+2. Channel numbering
+
+Numbering scheme for channels 0..4 is defined in EP9301 and EP9302 datasheets.
+EP9307, EP9312 and EP9312 have 3 channels more (total 8), but the numbering is
+not defined. So the last three are numbered randomly, let's say.
+
+Assuming ep93xx_adc is IIO device0, you'd find following entries under
+/sys/bus/iio/devices/iio:device0/:
+
+  +-----------------+---------------+
+  | sysfs entry     | ball/pin name |
+  +-----------------+---------------+
+  | in_voltage0_raw | YM            |
+  | in_voltage1_raw | SXP           |
+  | in_voltage2_raw | SXM           |
+  | in_voltage3_raw | SYP           |
+  | in_voltage4_raw | SYM           |
+  | in_voltage5_raw | XP            |
+  | in_voltage6_raw | XM            |
+  | in_voltage7_raw | YP            |
+  +-----------------+---------------+
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 283ded7..0482f29 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -172,6 +172,17 @@ config DA9150_GPADC
 	  To compile this driver as a module, choose M here: the module will be
 	  called berlin2-adc.

+config EP93XX_ADC
+	tristate "Cirrus Logic EP93XX ADC driver"
+	depends on ARCH_EP93XX
+	help
+	  Driver for the ADC module on the EP93XX series of SoC from Cirrus Logic.
+	  It's recommended to switch on CONFIG_HIGH_RES_TIMERS option, in this
+	  case driver will reduce its CPU usage by 90% in some use cases.
+
+	  To compile this driver as a module, choose M here: the module will be
+	  called ep93xx_adc.
+
 config EXYNOS_ADC
 	tristate "Exynos ADC driver support"
 	depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || (OF && COMPILE_TEST)
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 6435780..cd7d33e 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
 obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
 obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
 obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
+obj-$(CONFIG_EP93XX_ADC) += ep93xx_adc.o
 obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
 obj-$(CONFIG_HI8435) += hi8435.o
 obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
diff --git a/drivers/iio/adc/ep93xx_adc.c b/drivers/iio/adc/ep93xx_adc.c
new file mode 100644
index 0000000..3728591
--- /dev/null
+++ b/drivers/iio/adc/ep93xx_adc.c
@@ -0,0 +1,261 @@
+/*
+ * Driver for ADC module on the Cirrus Logic EP93xx series of SoCs
+ *
+ * Copyright (C) 2015 Alexander Sverdlin
+ *
+ * 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.
+ *
+ * The driver uses polling to get the conversion status. According to EP93xx
+ * datasheets, reading ADCResult register starts the conversion, but user is also
+ * responsible for ensuring that delay between adjacent conversion triggers is
+ * long enough so that maximum allowed conversion rate is not exceeded. This
+ * basically renders IRQ mode unusable.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/iio/iio.h>
+#include <linux/io.h>
+#include <linux/irqflags.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+
+#define EP93XX_NUM_CHANNELS 8
+
+/*
+ * This code could benefit from real HR Timers, but jiffy granularity would
+ * lower ADC conversion rate down to CONFIG_HZ, so we fallback to busy wait
+ * in such case.
+ *
+ * HR Timers-based version loads CPU only up to 10% during back to back ADC
+ * conversion, while busy wait-based version consumes whole CPU power.
+ */
+#ifdef CONFIG_HIGH_RES_TIMERS
+#define ep93xx_adc_delay(usmin, usmax) usleep_range(usmin, usmax)
+#else
+#define ep93xx_adc_delay(usmin, usmax) udelay(usmin)
+#endif
+
+#define EP93XX_ADC_RESULT	0x08
+#define   EP93XX_ADC_SDR	BIT(31)
+#define EP93XX_ADC_SWITCH	0x18
+#define EP93XX_ADC_SW_LOCK	0x20
+#define EP93XX_ADC_INT_EN	0x24
+#define   EP93XX_ADC_RINTEN	BIT(11)
+
+struct ep93xx_adc_priv {
+	struct clk *clk;
+	void __iomem *base;
+	int lastch;
+	struct mutex lock;
+};
+
+#define EP93XX_ADC_CH(index, dname, swcfg) {			\
+	.type = IIO_VOLTAGE,					\
+	.indexed = 1,						\
+	.channel = index,					\
+	.address = swcfg,					\
+	.datasheet_name = dname,				\
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),		\
+	.info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE) |	\
+				   BIT(IIO_CHAN_INFO_OFFSET),	\
+}
+
+/*
+ * Numbering scheme for channels 0..4 is defined in EP9301 and EP9302 datasheets.
+ * EP9307, EP9312 and EP9312 have 3 channels more (total 8), but the numbering is
+ * not defined. So the last three are numbered randomly, let's say.
+ */
+static const struct iio_chan_spec ep93xx_adc_channels[EP93XX_NUM_CHANNELS] = {
+	EP93XX_ADC_CH(0, "YM",	0x608),
+	EP93XX_ADC_CH(1, "SXP",	0x680),
+	EP93XX_ADC_CH(2, "SXM",	0x640),
+	EP93XX_ADC_CH(3, "SYP",	0x620),
+	EP93XX_ADC_CH(4, "SYM",	0x610),
+	EP93XX_ADC_CH(5, "XP",	0x601),
+	EP93XX_ADC_CH(6, "XM",	0x602),
+	EP93XX_ADC_CH(7, "YP",	0x604),
+};
+
+static int ep93xx_read_raw(struct iio_dev *iiodev,
+			   struct iio_chan_spec const *channel, int *value,
+			   int *shift, long mask)
+{
+	struct ep93xx_adc_priv *priv = iio_priv(iiodev);
+	unsigned long timeout;
+	int ret;
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		mutex_lock(&priv->lock);
+		if (priv->lastch != channel->channel) {
+			priv->lastch = channel->channel;
+			/*
+			 * Switch register is software-locked, unlocking must be
+			 * immediately followed by write
+			 */
+			local_irq_disable();
+			writel_relaxed(0xAA, priv->base + EP93XX_ADC_SW_LOCK);
+			writel_relaxed(channel->address,
+				       priv->base + EP93XX_ADC_SWITCH);
+			local_irq_enable();
+			/*
+			 * Settling delay depends on module clock and could be
+			 * 2ms or 500us
+			 */
+			ep93xx_adc_delay(2000, 2000);
+		}
+		/* Start the conversion, eventually discarding old result */
+		readl_relaxed(priv->base + EP93XX_ADC_RESULT);
+		/* Ensure maximun conversion rate is not exceeded */
+		ep93xx_adc_delay(DIV_ROUND_UP(1000000, 925),
+				 DIV_ROUND_UP(1000000, 925));
+		/* At this point conversion must be completed, but anyway... */
+		ret = IIO_VAL_INT;
+		timeout = jiffies + msecs_to_jiffies(1) + 1;
+		while (1) {
+			u32 t;
+
+			t = readl_relaxed(priv->base + EP93XX_ADC_RESULT);
+			if (t & EP93XX_ADC_SDR) {
+				/* Sign extend lower 16 bits */
+				*value = (s16)t;
+				break;
+			}
+
+			if (time_after(jiffies, timeout)) {
+				dev_err(&iiodev->dev, "Conversion timeout\n");
+				ret = -ETIMEDOUT;
+				break;
+			}
+
+			cpu_relax();
+		}
+		mutex_unlock(&priv->lock);
+		return ret;
+
+	case IIO_CHAN_INFO_OFFSET:
+		/* According to datasheet, range is -25000..25000 */
+		*value = 25000;
+		return IIO_VAL_INT;
+
+	case IIO_CHAN_INFO_SCALE:
+		/* Typical supply voltage is 3.3v */
+		*value = (1ULL << 32) * 3300 / 50000;
+		*shift = 32;
+		return IIO_VAL_FRACTIONAL_LOG2;
+	}
+
+	return -EINVAL;
+}
+
+static const struct iio_info ep93xx_adc_info = {
+	.driver_module = THIS_MODULE,
+	.read_raw = ep93xx_read_raw,
+};
+
+static int ep93xx_adc_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct iio_dev *iiodev;
+	struct ep93xx_adc_priv *priv;
+	struct clk *pclk;
+	struct resource *res;
+
+	iiodev = devm_iio_device_alloc(&pdev->dev,
+				       sizeof(struct ep93xx_adc_priv));
+	if (!iiodev)
+		return -ENOMEM;
+	priv = iio_priv(iiodev);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(&pdev->dev, "Cannot obtain memory resource\n");
+		return -ENXIO;
+	}
+	priv->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(priv->base)) {
+		dev_err(&pdev->dev, "Cannot map memory resource\n");
+		return PTR_ERR(priv->base);
+	}
+
+	iiodev->dev.parent = &pdev->dev;
+	iiodev->name = dev_name(&pdev->dev);
+	iiodev->modes = INDIO_DIRECT_MODE;
+	iiodev->info = &ep93xx_adc_info;
+	iiodev->num_channels = ARRAY_SIZE(ep93xx_adc_channels);
+	iiodev->channels = ep93xx_adc_channels;
+
+	priv->lastch = -1;
+	mutex_init(&priv->lock);
+
+	platform_set_drvdata(pdev, iiodev);
+
+	priv->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(priv->clk)) {
+		dev_err(&pdev->dev, "Cannot obtain clock\n");
+		return PTR_ERR(priv->clk);
+	}
+
+	pclk = clk_get_parent(priv->clk);
+	if (!pclk) {
+		dev_warn(&pdev->dev, "Cannot obtain parent clock\n");
+	} else {
+		/*
+		 * This is actually a place for improvement:
+		 * EP93xx ADC supports two clock divisors -- 4 and 16,
+		 * resulting in conversion rates 3750 and 925 samples per second
+		 * respectively with 500uS or 2ms settling time respectively.
+		 * One might find this interesting enough to be configurable.
+		 */
+		ret = clk_set_rate(priv->clk, clk_get_rate(pclk) / 16);
+		if (ret)
+			dev_warn(&pdev->dev, "Cannot set clock rate\n");
+		/*
+		 * We can tolerate rate setting failure because the module should
+		 * work in any case.
+		 */
+	}
+
+	ret = clk_enable(priv->clk);
+	if (ret) {
+		dev_err(&pdev->dev, "Cannot enable clock\n");
+		return ret;
+	}
+
+	ret = iio_device_register(iiodev);
+	if (ret)
+		clk_disable(priv->clk);
+
+	return ret;
+}
+
+static int ep93xx_adc_remove(struct platform_device *pdev)
+{
+	struct iio_dev *iiodev = platform_get_drvdata(pdev);
+	struct ep93xx_adc_priv *priv = iio_priv(iiodev);
+
+	iio_device_unregister(iiodev);
+	clk_disable(priv->clk);
+
+	return 0;
+}
+
+static struct platform_driver ep93xx_adc_driver = {
+	.driver = {
+		.name = "ep93xx-adc",
+	},
+	.probe = ep93xx_adc_probe,
+	.remove = ep93xx_adc_remove,
+};
+module_platform_driver(ep93xx_adc_driver);
+
+MODULE_AUTHOR("Alexander Sverdlin <alexander.sverdlin at gmail.com>");
+MODULE_DESCRIPTION("Cirrus Logic EP93XX ADC driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:ep93xx-adc");



From robert.jarzmik at free.fr  Sat Feb 20 10:22:04 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat, 20 Feb 2016 19:22:04 +0100
Subject: [PATCH 1/4] ASoC: wm9713: add binding for WM9713 codec
In-Reply-To: <20160220171459.GA18327@sirena.org.uk> (Mark Brown's message of
 "Sun, 21 Feb 2016 02:14:59 +0900")
References: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
 <20160220171459.GA18327@sirena.org.uk>
Message-ID: <871t87z1gz.fsf@belgarion.home>

Mark Brown <broonie at kernel.org> writes:

> On Sat, Feb 20, 2016 at 03:37:56PM +0100, Robert Jarzmik wrote:
>
>> +WM9713 audio CODEC
>> +
>> +This devices supports I2C.
>
> No, it clearly doesn't...
Right, it supports AC97.

> The problem with doing this is that since AC'97 is an enumerable bus we really
> shouldn't need to list AC'97 CODECs in the device tree.
Ok, I understand that.

> Instead we should be probing at runtime (as the non-ASoC AC'97 code does) or
> something similar.
When you say "non-ASoC AC'97 code", which file are you referring to ? Is it
sound/pci/ac97/ac97_codec.c ?

If so is there already a table of tuples (AC97_VENDOR_ID1, AC97_VENDOR_ID2) ->
(platform device, platform device data) and a matching mechanism already
available to the ASoC drivers ?

Cheers.

-- 
Robert


From manabian at gmail.com  Sat Feb 20 11:06:49 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Sat, 20 Feb 2016 20:06:49 +0100
Subject: [PATCH] reset: lpc18xx: get rid of global variables for restart
 notifier
Message-ID: <1455995209-5213-1-git-send-email-manabian@gmail.com>

Moving the notifier_block into the drivers priv struct allows us
to retrive the priv struct with container_of and remove the
global variables.

Signed-off-by: Joachim Eastwood <manabian at gmail.com>
---
Hi Philipp,

Just a simple clean up patch for lpc18xx reset controller.

 drivers/reset/reset-lpc18xx.c | 22 ++++++++++------------
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/reset/reset-lpc18xx.c b/drivers/reset/reset-lpc18xx.c
index 3b8a4f5a1ff6..54cca0055171 100644
--- a/drivers/reset/reset-lpc18xx.c
+++ b/drivers/reset/reset-lpc18xx.c
@@ -35,6 +35,7 @@
 
 struct lpc18xx_rgu_data {
 	struct reset_controller_dev rcdev;
+	struct notifier_block restart_nb;
 	struct clk *clk_delay;
 	struct clk *clk_reg;
 	void __iomem *base;
@@ -44,12 +45,13 @@ struct lpc18xx_rgu_data {
 
 #define to_rgu_data(p) container_of(p, struct lpc18xx_rgu_data, rcdev)
 
-static void __iomem *rgu_base;
-
-static int lpc18xx_rgu_restart(struct notifier_block *this, unsigned long mode,
+static int lpc18xx_rgu_restart(struct notifier_block *nb, unsigned long mode,
 			       void *cmd)
 {
-	writel(BIT(LPC18XX_RGU_CORE_RST), rgu_base + LPC18XX_RGU_CTRL0);
+	struct lpc18xx_rgu_data *rc = container_of(nb, struct lpc18xx_rgu_data,
+						   restart_nb);
+
+	writel(BIT(LPC18XX_RGU_CORE_RST), rc->base + LPC18XX_RGU_CTRL0);
 	mdelay(2000);
 
 	pr_emerg("%s: unable to restart system\n", __func__);
@@ -57,11 +59,6 @@ static int lpc18xx_rgu_restart(struct notifier_block *this, unsigned long mode,
 	return NOTIFY_DONE;
 }
 
-static struct notifier_block lpc18xx_rgu_restart_nb = {
-	.notifier_call = lpc18xx_rgu_restart,
-	.priority = 192,
-};
-
 /*
  * The LPC18xx RGU has mostly self-deasserting resets except for the
  * two reset lines going to the internal Cortex-M0 cores.
@@ -205,8 +202,9 @@ static int lpc18xx_rgu_probe(struct platform_device *pdev)
 		goto dis_clks;
 	}
 
-	rgu_base = rc->base;
-	ret = register_restart_handler(&lpc18xx_rgu_restart_nb);
+	rc->restart_nb.priority = 192,
+	rc->restart_nb.notifier_call = lpc18xx_rgu_restart,
+	ret = register_restart_handler(&rc->restart_nb);
 	if (ret)
 		dev_warn(&pdev->dev, "failed to register restart handler\n");
 
@@ -225,7 +223,7 @@ static int lpc18xx_rgu_remove(struct platform_device *pdev)
 	struct lpc18xx_rgu_data *rc = platform_get_drvdata(pdev);
 	int ret;
 
-	ret = unregister_restart_handler(&lpc18xx_rgu_restart_nb);
+	ret = unregister_restart_handler(&rc->restart_nb);
 	if (ret)
 		dev_warn(&pdev->dev, "failed to unregister restart handler\n");
 
-- 
1.8.0



From f.fainelli at gmail.com  Sat Feb 20 11:07:00 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Sat, 20 Feb 2016 11:07:00 -0800
Subject: [GIT PULL 2/2] bcm2835 changes to DT for 4.6
In-Reply-To: <1455764208-5679-2-git-send-email-eric@anholt.net>
References: <1455764208-5679-1-git-send-email-eric@anholt.net>
 <1455764208-5679-2-git-send-email-eric@anholt.net>
Message-ID: <56C8B954.5000409@gmail.com>

Le 17/02/2016 18:56, Eric Anholt a ?crit :
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git at github.com:anholt/linux.git bcm2835-dt-next-2016-02-17
> 
> for you to fetch changes up to 1305141d1a7254b53b35303ee84f4c4948007bd0:
> 
>   ARM: bcm2835: add bcm2835-aux-uart support to DT (2016-02-17 11:01:00 -0800)
> 
> ----------------------------------------------------------------
> This pull request covers mostly DT changes that didn't make it into
> 4.5 because required header files went through other trees, plus the
> AUX uart support this time around.
> 
> ----------------------------------------------------------------

Merged, thanks!
-- 
Florian


From yu.c.chen at intel.com  Sat Feb 20 11:16:59 2016
From: yu.c.chen at intel.com (Chen, Yu C)
Date: Sat, 20 Feb 2016 19:16:59 +0000
Subject: [PATCH v5 15/15] arm64: hibernate: Prevent resume from a
 different kernel version
In-Reply-To: <56C5B240.40400@arm.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
 <1455637767-31561-16-git-send-email-james.morse@arm.com>
 <20160216201557.GA6526@amd>
 <36DF59CE26D8EE47B0655C516E9CE640286C4F3C@shsmsx102.ccr.corp.intel.com>
 <56C5B240.40400@arm.com>
Message-ID: <36DF59CE26D8EE47B0655C516E9CE640286C628C@shsmsx102.ccr.corp.intel.com>


> -----Original Message-----
> From: James Morse [mailto:james.morse at arm.com]
> Sent: Thursday, February 18, 2016 8:00 PM
> To: Chen, Yu C
> Cc: Pavel Machek; linux-arm-kernel at lists.infradead.org; Will Deacon; Sudeep
> Holla; Geoff Levand; Catalin Marinas; Lorenzo Pieralisi; Mark Rutland; AKASHI
> Takahiro; Marc Zyngier; Rafael J . Wysocki; linux-pm at vger.kernel.org
> Subject: Re: [PATCH v5 15/15] arm64: hibernate: Prevent resume from a
> different kernel version
> 
> On 17/02/16 02:20, Chen, Yu C wrote:
> >> On Tue 2016-02-16 15:49:27, James Morse wrote:
> > This reminds me a similar problem I once encountered on x86 : - ) The
> > efi memory layout should be strictly the same before/after hibernation,
> right?
> 
> The kernel hopes it is the same, as the page-tables it uses for runtime
> services calls are restored along with the rest of memory, but there is the risk
> that these don't match the EFI memory map any more.
> 
> Even if the amount of memory is the same, the layout might be different.
> (Core hibernate code already has a counter of the number of physical pages.)
I've encountered this situation before.
> 
> I'm still digging through the efi code (and spec), but it is fairly easy to cause
> the memory map to change before entry to linux. This doesn't seem to be a
> problem, as linux happily overwrites most of the allocated areas, so it may
> not be as fragile as I thought.
If I did some peripherals plug/unplug after suspend to hibernation,
then the next time it boots up there would likely be a slightly different efi memory map.
The efi provides a callback of get_memory_map to Linux for retrieving the initial map,
which depends on the bios/bootloader probing/enumeration IMO. The difference of efi
map might lead to kernel panic during resume sometimes.

thanks,
yu


From f.fainelli at gmail.com  Sat Feb 20 11:31:17 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Sat, 20 Feb 2016 11:31:17 -0800
Subject: [GIT PULL 1/2] bcm2835 changes to defconfigs for 4.6
In-Reply-To: <1455764208-5679-1-git-send-email-eric@anholt.net>
References: <1455764208-5679-1-git-send-email-eric@anholt.net>
Message-ID: <56C8BF05.3000200@gmail.com>

Le 17/02/2016 18:56, Eric Anholt a ?crit :
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git at github.com:anholt/linux.git bcm2835-defconfig-next-2016-02-17
> 
> for you to fetch changes up to 0a05d3b71ada526ef93019fb3fbd6a95561a8a5f:
> 
>   ARM: multi_v7_defconfig: Enable BCM283x (2016-02-17 11:18:05 -0800)
> 
> ----------------------------------------------------------------
> This pull request brings in defconfig changes to enable bcm2836 in the
> 2835 and multi_v7 defconfigs.
> 
> ----------------------------------------------------------------

And also merged, thanks!
-- 
Florian


From f.fainelli at gmail.com  Sat Feb 20 11:46:20 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Sat, 20 Feb 2016 11:46:20 -0800
Subject: [GIT PULL 1/8] Broadcom soc changes for 4.6
Message-ID: <1455997587-17564-1-git-send-email-f.fainelli@gmail.com>

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.6/soc

for you to fetch changes up to 6580566e10016c1ec00aa5e0e62af3c4b3498019:

  ARM: BCM63xx: Remove unused pmb_dn variable (2016-02-02 10:47:08 -0800)

----------------------------------------------------------------
This pull request contains Broadcom ARM-based SoC/platform changes:

- Masahiro updates the Broadcom Northstar Plus SMP operations to be annotated
  with const and __initconst

- Florian removes an unused variable in the Broadcom BCM63XX SMP code

----------------------------------------------------------------
Florian Fainelli (1):
      ARM: BCM63xx: Remove unused pmb_dn variable

Masahiro Yamada (1):
      ARM: bcm: use const and __initconst for smp_operations

 arch/arm/mach-bcm/bcm63xx_pmb.c | 2 --
 arch/arm/mach-bcm/platsmp.c     | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)


From f.fainelli at gmail.com  Sat Feb 20 11:46:21 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Sat, 20 Feb 2016 11:46:21 -0800
Subject: [GIT PULL 2/8] Broadcom soc-arm64 changes for 4.6
In-Reply-To: <1455997587-17564-1-git-send-email-f.fainelli@gmail.com>
References: <1455997587-17564-1-git-send-email-f.fainelli@gmail.com>
Message-ID: <1455997587-17564-2-git-send-email-f.fainelli@gmail.com>

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.6/soc-arm64

for you to fetch changes up to 9eb8a2cdf65ce47c3aa68f1297c84d8bcf5a7b3a:

  arm64: cputype info for Broadcom Vulcan (2016-02-20 10:42:38 -0800)

----------------------------------------------------------------
This pull request contains Broadcom ARM64-based SoC/platform changes:

- Anup, Ray and Dhanajay enable COMMON_CLK_IPROC, PINCTRL and GPIOLIB for iProc
  SoCs to get the corresponding iProc-based drivers to be available and work

- Zi adds support for Broadcom's Vulcan processor by adding a reference
  board Device Tree file along with a config ARCH_VULCAN symbol

- Jayachandran C. adds the Broadcom implementor ID and part ID for the Vulcan
  processors

----------------------------------------------------------------
Anup Patel (1):
      arm64: Select COMMON_CLK_IPROC, PINCTRL and GPIOLIB for iProc SoCs

Jayachandran C (1):
      arm64: cputype info for Broadcom Vulcan

Zi Shen Lim (1):
      arm64: Broadcom Vulcan support

 arch/arm64/Kconfig.platforms                 |   8 ++
 arch/arm64/boot/dts/broadcom/Makefile        |   1 +
 arch/arm64/boot/dts/broadcom/vulcan-eval.dts |  33 ++++++
 arch/arm64/boot/dts/broadcom/vulcan.dtsi     | 144 +++++++++++++++++++++++++++
 arch/arm64/include/asm/cputype.h             |   3 +
 5 files changed, 189 insertions(+)
 create mode 100644 arch/arm64/boot/dts/broadcom/vulcan-eval.dts
 create mode 100644 arch/arm64/boot/dts/broadcom/vulcan.dtsi


From f.fainelli at gmail.com  Sat Feb 20 11:46:22 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Sat, 20 Feb 2016 11:46:22 -0800
Subject: [GIT PULL 3/8] Broadcom devicetree changes for 4.6
In-Reply-To: <1455997587-17564-1-git-send-email-f.fainelli@gmail.com>
References: <1455997587-17564-1-git-send-email-f.fainelli@gmail.com>
Message-ID: <1455997587-17564-3-git-send-email-f.fainelli@gmail.com>

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.6/devicetree

for you to fetch changes up to ac07c41c9ad827950795b33f3ca9264288f3b1e4:

  Merge tag 'bcm2835-dt-next-2016-02-17' into devicetree/next (2016-02-20 11:05:55 -0800)

----------------------------------------------------------------
This pull request contains Broadcom ARM-based SoCs Device Tree changes:

- Rafal adds a Device Tree for the D-Link DIR-885L router which is based on the
  BCM47094 SoC similar to the BCM4709

- Simran adds proper audio clock Device Tree nodes to the Cygnus platforms

- Martin adds the auxiliary SPI controllers, makes the UART naming convention
  more standard, and finally adds the auxiliary UART found in the BCM2835 to the
  BCM2835 Device Tree

- Remi adds PWM clock support to the BCM2835 Device Tree

- Lubomir adds a Device Tree for the Raspberry Pi Model A

- Alexander adds Device Tree information for the Raspberry Pi USB power domain

- Dhananjay enables the GPIO-A controller for the Northstar Plus SoCs

- Jon fixes the PCIE Device Tree nodes by pulling them out of the bus-level node,
  removes duplicate CPU definitions, adds PMU nodes, SP804 timers, and SP805 watchdog
  to the Northstar Plus SoCs

----------------------------------------------------------------
Alexander Aring (1):
      ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.

Florian Fainelli (1):
      Merge tag 'bcm2835-dt-next-2016-02-17' into devicetree/next

Jon Mason (5):
      ARM: dts: NSP: Fix PCIE DT issue
      ARM: dts: NSP: Fix CPU DT issue
      ARM: dts: NSP: Add PMU Support to DT
      ARM: dts: NSP: Add SP804 Support to DT
      ARM: dts: NSP: Add SP805 Support to DT

Lubomir Rintel (1):
      ARM: bcm2835: dt: Add Raspberry Pi Model A

Martin Sperl (3):
      ARM: bcm2835: add the auxiliary spi1 and spi2 to the device tree
      ARM: bcm2835: follow dt uart node-naming convention
      ARM: bcm2835: add bcm2835-aux-uart support to DT

Rafa? Mi?ecki (1):
      ARM: BCM5301X: Add DT for D-Link DIR-885L

Remi Pommarel (1):
      ARM: bcm2835: Add PWM clock support to the device tree

Simran Rai (1):
      ARM: dts: Add audio clock to the existing Broadcom Cygnus clock DT

Yendapally Reddy Dhananjaya Reddy (1):
      ARM: dts: enable GPIO-a for Broadcom NSP

 arch/arm/boot/dts/Makefile                    |   2 +
 arch/arm/boot/dts/bcm-cygnus-clock.dtsi       |   9 ++
 arch/arm/boot/dts/bcm-nsp.dtsi                | 205 +++++++++++++++-----------
 arch/arm/boot/dts/bcm2835-rpi-a.dts           |  24 +++
 arch/arm/boot/dts/bcm2835-rpi.dtsi            |  16 ++
 arch/arm/boot/dts/bcm283x.dtsi                |  43 +++++-
 arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 111 ++++++++++++++
 7 files changed, 322 insertions(+), 88 deletions(-)
 create mode 100644 arch/arm/boot/dts/bcm2835-rpi-a.dts
 create mode 100644 arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts


From f.fainelli at gmail.com  Sat Feb 20 11:46:23 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Sat, 20 Feb 2016 11:46:23 -0800
Subject: [GIT PULL 4/8] Broadcom devicetree-arm64 changes for 4.6
In-Reply-To: <1455997587-17564-1-git-send-email-f.fainelli@gmail.com>
References: <1455997587-17564-1-git-send-email-f.fainelli@gmail.com>
Message-ID: <1455997587-17564-4-git-send-email-f.fainelli@gmail.com>

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.6/devicetree-arm64

for you to fetch changes up to f008decc4797979bc1d3b8efd18bd5df1e53e9f0:

  dt-bindings: Add documentation for Broadcom Vulcan (2016-02-20 10:42:51 -0800)

----------------------------------------------------------------
This pull request contains Broadcom ARM64-based SoCs device tree changes:

- Anup adds additional nodes to the Broadcom Northstart 2 Device Trees: SDHCI
  (iProc-compatible), ARM SP804 timers, ARM SP805 watchdog

- Anup also adds a binding documentation for the ARM SP805 watchdog since there
  was not one in tree before

- Ray adds PCIE root complex nodes to the Northstar 2 Device Tree nodes, using
  the iProc-compatible binding

- Jayachandran C. adds binding documentation for the Broadcom Vulcan processors and
  reference platforms

----------------------------------------------------------------
Anup Patel (4):
      arm64: dts: Add SDHCI DT node for NS2
      arm64: dts: Add ARM SP804 timer DT nodes for NS2
      dt-bindings: watchdog: Add ARM SP805 DT bindings
      arm64: dts: Add ARM SP805 watchdog DT node for NS2

Jayachandran C (1):
      dt-bindings: Add documentation for Broadcom Vulcan

Ray Jui (1):
      arm64: dts: Add PCIe0 and PCIe4 DT nodes for NS2

 .../bindings/arm/bcm/brcm,vulcan-soc.txt           |  10 ++
 Documentation/devicetree/bindings/arm/cpus.txt     |   1 +
 .../devicetree/bindings/watchdog/arm,sp805.txt     |  17 +++
 arch/arm64/boot/dts/broadcom/ns2-svk.dts           |  12 ++
 arch/arm64/boot/dts/broadcom/ns2.dtsi              | 140 +++++++++++++++++++++
 5 files changed, 180 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.txt
 create mode 100644 Documentation/devicetree/bindings/watchdog/arm,sp805.txt


From f.fainelli at gmail.com  Sat Feb 20 11:46:24 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Sat, 20 Feb 2016 11:46:24 -0800
Subject: [GIT PULL 5/8] Broadcom maintainers changes for 4.6
In-Reply-To: <1455997587-17564-1-git-send-email-f.fainelli@gmail.com>
References: <1455997587-17564-1-git-send-email-f.fainelli@gmail.com>
Message-ID: <1455997587-17564-5-git-send-email-f.fainelli@gmail.com>

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.6/maintainers

for you to fetch changes up to 20de823e8b38119d8106aa85e0bd8b47eb295889:

  MAINTAINERS: ARM: BCM63xx: Update git and mailing-lists (2016-02-02 10:47:47 -0800)

----------------------------------------------------------------
This pull request contains MAINTAINERS file updates for Broadcom ARM-based SoCs:

- Florian updates the Broadcom BCM63xx ARM-based DSL SoCs to use the same mailing-list
  and development tree as all the other Broadcom SoCS

----------------------------------------------------------------
Florian Fainelli (1):
      MAINTAINERS: ARM: BCM63xx: Update git and mailing-lists

 MAINTAINERS | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)


From f.fainelli at gmail.com  Sat Feb 20 11:46:25 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Sat, 20 Feb 2016 11:46:25 -0800
Subject: [GIT PULL 6/8] Broadcom maintainers-arm64 changes for 4.6
In-Reply-To: <1455997587-17564-1-git-send-email-f.fainelli@gmail.com>
References: <1455997587-17564-1-git-send-email-f.fainelli@gmail.com>
Message-ID: <1455997587-17564-6-git-send-email-f.fainelli@gmail.com>

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.6/maintainers-arm64

for you to fetch changes up to 42515e61d414abff6cdded90ef0f607347e0ceb7:

  MAINTAINERS: Add entry for Broadcom Vulcan SoC (2016-02-20 11:08:18 -0800)

----------------------------------------------------------------
This pull request contains MAINTAINERS file updates for Broadcom ARM64-based SoCs:

- Jayachandran C. adds an entry for the newly added Broadcom Vulcan Device Trees

----------------------------------------------------------------
Jayachandran C (1):
      MAINTAINERS: Add entry for Broadcom Vulcan SoC

 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)


From f.fainelli at gmail.com  Sat Feb 20 11:46:26 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Sat, 20 Feb 2016 11:46:26 -0800
Subject: [GIT PULL 7/8] Broadcom defconfig changes for 4.6
In-Reply-To: <1455997587-17564-1-git-send-email-f.fainelli@gmail.com>
References: <1455997587-17564-1-git-send-email-f.fainelli@gmail.com>
Message-ID: <1455997587-17564-7-git-send-email-f.fainelli@gmail.com>

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.6/defconfig

for you to fetch changes up to 9eefbe52737f2ae6c2d3556339ef851201516c26:

  Merge tag 'bcm2835-defconfig-next-2016-02-17' into defconfig/next (2016-02-20 11:07:10 -0800)

----------------------------------------------------------------
This pull request contains defconfig changes for Broadcom ARM-based SoCs:

- Daniel enables all that is required to get the BCM283x (Raspberry Pi and
  Raspberry Pi 2) SoCs to boot with multi_v7_defconfig

- Stefan enables the Raspberry Pi firmware driver and power domain drivers
  in bcm2835_defconfig

- Stephen refreshes the bcm2835_defconfig, disables DEBUG_LL, and turns on
  ARMv7 support which is needed for BCM2836 (Raspberry Pi 2)

----------------------------------------------------------------
Daniel Stone (1):
      ARM: multi_v7_defconfig: Enable BCM283x

Florian Fainelli (1):
      Merge tag 'bcm2835-defconfig-next-2016-02-17' into defconfig/next

Stefan Wahren (2):
      ARM: bcm2835_defconfig: Enable RPi firmware driver
      ARM: bcm2835_defconfig: Enable RPi power domain driver

Stephen Warren (3):
      ARM: bcm2835_defconfig: rebuild on next-20160205
      ARM: bcm2835_defconfig: disable DEBUG_LL
      ARM: bcm2835_defconfig: enable ARMv7 support

 arch/arm/configs/bcm2835_defconfig  | 11 +++++------
 arch/arm/configs/multi_v7_defconfig | 12 ++++++++++++
 2 files changed, 17 insertions(+), 6 deletions(-)


From f.fainelli at gmail.com  Sat Feb 20 11:46:27 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Sat, 20 Feb 2016 11:46:27 -0800
Subject: [GIT PULL 8/8] Broadcom defconfig-arm64 changes for 4.6
In-Reply-To: <1455997587-17564-1-git-send-email-f.fainelli@gmail.com>
References: <1455997587-17564-1-git-send-email-f.fainelli@gmail.com>
Message-ID: <1455997587-17564-8-git-send-email-f.fainelli@gmail.com>

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  http://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.6/defconfig-arm64

for you to fetch changes up to 4cf430ee0c2ba1da97cab10b904291eb6fc5f170:

  arm64: defconfig: Add Broadcom Vulcan to defconfig (2016-02-20 10:42:08 -0800)

----------------------------------------------------------------
This pull request contains ARM64 defconfig changes for Broadcom SoCs:

- Jayachandran C enables the newly introduced Broadcom Vulcan SoC to the ARM64
  defconfig

----------------------------------------------------------------
Jayachandran C (1):
      arm64: defconfig: Add Broadcom Vulcan to defconfig

 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)


From dhdang at apm.com  Sat Feb 20 11:47:12 2016
From: dhdang at apm.com (Duc Dang)
Date: Sat, 20 Feb 2016 11:47:12 -0800
Subject: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot
 for X-Gene v1
In-Reply-To: <1455069384-22323-1-git-send-email-dhdang@apm.com>
References: <1455069384-22323-1-git-send-email-dhdang@apm.com>
Message-ID: <CADaLNDmsW+5-EEvTMGOyCGmKWYS-trx74pQ87czkrSWqNgrHWw@mail.gmail.com>

On Tue, Feb 9, 2016 at 5:56 PM, Duc Dang <dhdang at apm.com> wrote:
> This patch makes pci-xgene-msi driver ACPI-aware and provides
> MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode.

Hi Bjorn,

Are you planning to take this patch into your tree?

Regards,
Duc Dang.
>
> Signed-off-by: Duc Dang <dhdang at apm.com>
> ---
>  drivers/pci/host/pci-xgene-msi.c | 35 ++++++++++++++++++++++++++++++++---
>  1 file changed, 32 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
> index a6456b5..466aa93 100644
> --- a/drivers/pci/host/pci-xgene-msi.c
> +++ b/drivers/pci/host/pci-xgene-msi.c
> @@ -24,6 +24,7 @@
>  #include <linux/pci.h>
>  #include <linux/platform_device.h>
>  #include <linux/of_pci.h>
> +#include <linux/acpi.h>
>
>  #define MSI_IR0                        0x000000
>  #define MSI_INT0               0x800000
> @@ -39,7 +40,7 @@ struct xgene_msi_group {
>  };
>
>  struct xgene_msi {
> -       struct device_node      *node;
> +       struct fwnode_handle    *fwnode;
>         struct irq_domain       *inner_domain;
>         struct irq_domain       *msi_domain;
>         u64                     msi_addr;
> @@ -249,6 +250,13 @@ static const struct irq_domain_ops msi_domain_ops = {
>         .free   = xgene_irq_domain_free,
>  };
>
> +#ifdef CONFIG_ACPI
> +static struct fwnode_handle *xgene_msi_get_fwnode(struct device *dev)
> +{
> +       return xgene_msi_ctrl.fwnode;
> +}
> +#endif
> +
>  static int xgene_allocate_domains(struct xgene_msi *msi)
>  {
>         msi->inner_domain = irq_domain_add_linear(NULL, NR_MSI_VEC,
> @@ -256,7 +264,7 @@ static int xgene_allocate_domains(struct xgene_msi *msi)
>         if (!msi->inner_domain)
>                 return -ENOMEM;
>
> -       msi->msi_domain = pci_msi_create_irq_domain(of_node_to_fwnode(msi->node),
> +       msi->msi_domain = pci_msi_create_irq_domain(msi->fwnode,
>                                                     &xgene_msi_domain_info,
>                                                     msi->inner_domain);
>
> @@ -265,6 +273,9 @@ static int xgene_allocate_domains(struct xgene_msi *msi)
>                 return -ENOMEM;
>         }
>
> +#ifdef CONFIG_ACPI
> +       pci_msi_register_fwnode_provider(&xgene_msi_get_fwnode);
> +#endif
>         return 0;
>  }
>
> @@ -473,6 +484,13 @@ static const struct of_device_id xgene_msi_match_table[] = {
>         {},
>  };
>
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id xgene_msi_acpi_ids[] = {
> +       {"APMC0D0E", 0},
> +       { },
> +};
> +#endif
> +
>  static int xgene_msi_probe(struct platform_device *pdev)
>  {
>         struct resource *res;
> @@ -494,7 +512,17 @@ static int xgene_msi_probe(struct platform_device *pdev)
>                 goto error;
>         }
>         xgene_msi->msi_addr = res->start;
> -       xgene_msi->node = pdev->dev.of_node;
> +
> +       xgene_msi->fwnode = of_node_to_fwnode(pdev->dev.of_node);
> +       if (!xgene_msi->fwnode) {
> +               xgene_msi->fwnode = irq_domain_alloc_fwnode(NULL);
> +               if (!xgene_msi->fwnode) {
> +                       dev_err(&pdev->dev, "Failed to create fwnode\n");
> +                       rc = ENOMEM;
> +                       goto error;
> +               }
> +       }
> +
>         xgene_msi->num_cpus = num_possible_cpus();
>
>         rc = xgene_msi_init_allocator(xgene_msi);
> @@ -571,6 +599,7 @@ static struct platform_driver xgene_msi_driver = {
>         .driver = {
>                 .name = "xgene-msi",
>                 .of_match_table = xgene_msi_match_table,
> +               .acpi_match_table = ACPI_PTR(xgene_msi_acpi_ids),
>         },
>         .probe = xgene_msi_probe,
>         .remove = xgene_msi_remove,
> --
> 1.9.1
>


From f.fainelli at gmail.com  Sat Feb 20 11:50:38 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Sat, 20 Feb 2016 11:50:38 -0800
Subject: [PATCH v2 0/5] Support for Broadcom Vulcan ARM64 processor
In-Reply-To: <1455977964-8099-1-git-send-email-jchandra@broadcom.com>
References: <1455977964-8099-1-git-send-email-jchandra@broadcom.com>
Message-ID: <56C8C38E.50007@gmail.com>

Le 20/02/2016 06:19, Jayachandran C a ?crit :
> This patchset adds support for Broadcom's Vulcan ARM64 processor.
> The changes are to add the device tree files, documentation for the
> device tree, cpu ID and the maintainers entry.
> 
> This is v2 of the patchset, changelog below:
> 
> v1->v2 :
>  - dts: remove memreserve, use brcm,vulcan-soc for board
>    (to address comments from Mark Rutland)
>  - Fixup copyright (Broadcomp corp -> Broadcom)
>    (suggested by Florian Fainelli)
>  - Rename dts from brcm-vulcan* to vulcan*
>    (suggested by Ray Jui)
>  - Add maintainers entry
>    (suggested by Florian Fainelli)
>  - Updated the device tree doc and fixed a couple of commit
>    comments
> 
> Jayachandran C (4):
>   dt-bindings: Add documentation for Broadcom Vulcan
>   arm64: defconfig: Add Broadcom Vulcan to defconfig
>   arm64: cputype info for Broadcom Vulcan
>   MAINTAINERS: Add entry for Broadcom Vulcan SoC
> 
> Zi Shen Lim (1):
>   arm64: Broadcom Vulcan support

All applied and submitted for 4.6 thanks!
-- 
Florian


From pavel at ucw.cz  Sat Feb 20 11:57:02 2016
From: pavel at ucw.cz (Pavel Machek)
Date: Sat, 20 Feb 2016 20:57:02 +0100
Subject: [PATCH v5 15/15] arm64: hibernate: Prevent resume from a
 different kernel version
In-Reply-To: <36DF59CE26D8EE47B0655C516E9CE640286C628C@shsmsx102.ccr.corp.intel.com>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
 <1455637767-31561-16-git-send-email-james.morse@arm.com>
 <20160216201557.GA6526@amd>
 <36DF59CE26D8EE47B0655C516E9CE640286C4F3C@shsmsx102.ccr.corp.intel.com>
 <56C5B240.40400@arm.com>
 <36DF59CE26D8EE47B0655C516E9CE640286C628C@shsmsx102.ccr.corp.intel.com>
Message-ID: <20160220195702.GA22120@amd>

On Sat 2016-02-20 19:16:59, Chen, Yu C wrote:
> 
> > -----Original Message-----
> > From: James Morse [mailto:james.morse at arm.com]
> > Sent: Thursday, February 18, 2016 8:00 PM
> > To: Chen, Yu C
> > Cc: Pavel Machek; linux-arm-kernel at lists.infradead.org; Will Deacon; Sudeep
> > Holla; Geoff Levand; Catalin Marinas; Lorenzo Pieralisi; Mark Rutland; AKASHI
> > Takahiro; Marc Zyngier; Rafael J . Wysocki; linux-pm at vger.kernel.org
> > Subject: Re: [PATCH v5 15/15] arm64: hibernate: Prevent resume from a
> > different kernel version
> > 
> > On 17/02/16 02:20, Chen, Yu C wrote:
> > >> On Tue 2016-02-16 15:49:27, James Morse wrote:
> > > This reminds me a similar problem I once encountered on x86 : - ) The
> > > efi memory layout should be strictly the same before/after hibernation,
> > right?
> > 
> > The kernel hopes it is the same, as the page-tables it uses for runtime
> > services calls are restored along with the rest of memory, but there is the risk
> > that these don't match the EFI memory map any more.
> > 
> > Even if the amount of memory is the same, the layout might be different.
> > (Core hibernate code already has a counter of the number of physical pages.)
> I've encountered this situation before.
> > 
> > I'm still digging through the efi code (and spec), but it is fairly easy to cause
> > the memory map to change before entry to linux. This doesn't seem to be a
> > problem, as linux happily overwrites most of the allocated areas, so it may
> > not be as fragile as I thought.
> If I did some peripherals plug/unplug after suspend to hibernation,
> then the next time it boots up there would likely be a slightly different efi memory map.
> The efi provides a callback of get_memory_map to Linux for retrieving the initial map,
> which depends on the bios/bootloader probing/enumeration IMO. The difference of efi
> map might lead to kernel panic during resume sometimes.

md5hash of the efi map, and complain to bios vendors if it happens?
Because iirc it is not supposed to.

									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


From broonie at kernel.org  Sat Feb 20 11:59:25 2016
From: broonie at kernel.org (Mark Brown)
Date: Sun, 21 Feb 2016 04:59:25 +0900
Subject: [PATCH 1/4] ASoC: wm9713: add binding for WM9713 codec
In-Reply-To: <871t87z1gz.fsf@belgarion.home>
References: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
 <20160220171459.GA18327@sirena.org.uk>
 <871t87z1gz.fsf@belgarion.home>
Message-ID: <20160220195925.GF18327@sirena.org.uk>

On Sat, Feb 20, 2016 at 07:22:04PM +0100, Robert Jarzmik wrote:
> Mark Brown <broonie at kernel.org> writes:

> > Instead we should be probing at runtime (as the non-ASoC AC'97 code does) or
> > something similar.

> When you say "non-ASoC AC'97 code", which file are you referring to ? Is it
> sound/pci/ac97/ac97_codec.c ?

Yes.

> If so is there already a table of tuples (AC97_VENDOR_ID1, AC97_VENDOR_ID2) ->
> (platform device, platform device data) and a matching mechanism already
> available to the ASoC drivers ?

ASoC doesn't really support the enumeration very well, you can use
ac97.c as the CODEC but that's about it.  There is a generic AC'97 PXA
driver in sound/arm, if your system can use that that'd be a better
route to DT integration for it I think.  Did you try that, if there are
problems with that perhaps we can improve that driver, it should  be
simpler.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160221/70f3d21d/attachment.sig>

From robert.jarzmik at free.fr  Sat Feb 20 12:32:58 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat, 20 Feb 2016 21:32:58 +0100
Subject: [PATCH 1/4] ASoC: wm9713: add binding for WM9713 codec
In-Reply-To: <20160220195925.GF18327@sirena.org.uk> (Mark Brown's message of
 "Sun, 21 Feb 2016 04:59:25 +0900")
References: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
 <20160220171459.GA18327@sirena.org.uk> <871t87z1gz.fsf@belgarion.home>
 <20160220195925.GF18327@sirena.org.uk>
Message-ID: <87twl3xgud.fsf@belgarion.home>

Mark Brown <broonie at kernel.org> writes:

> On Sat, Feb 20, 2016 at 07:22:04PM +0100, Robert Jarzmik wrote:
>> Mark Brown <broonie at kernel.org> writes:
Removed DT people from this conversation.

>> > Instead we should be probing at runtime (as the non-ASoC AC'97 code does) or
>> > something similar.
>
>> When you say "non-ASoC AC'97 code", which file are you referring to ? Is it
>> sound/pci/ac97/ac97_codec.c ?
>
> Yes.
>
>> If so is there already a table of tuples (AC97_VENDOR_ID1, AC97_VENDOR_ID2) ->
>> (platform device, platform device data) and a matching mechanism already
>> available to the ASoC drivers ?
>
> ASoC doesn't really support the enumeration very well, you can use
> ac97.c as the CODEC but that's about it.

> There is a generic AC'97 PXA driver in sound/arm, if your system can use that
> that'd be a better route to DT integration for it I think.
I'm open on the topic.

Historically, I use sound/soc/pxa/pxa2xx-ac97.c since 2008. I know it works, but
if you think I should examine sound/arm/pxa2xx-ac97.c, let's do that.

> Did you try that, if there are problems with that perhaps we can improve that
> driver, it should be simpler.
I will. By now I fail to see how this will help in the wm9713 probing and
detection ...

Until I make the try, here is what I have as a device-tree extract in [1], which
is my candidate for sound/soc/pxa/zylonite.c replacement.. If we conclude that
wm9713 shouldn't be in device-tree, then I'm curious how the DAI bindings
(simple-audio-card,dai-link*) should be handled.

Cheers.

-- 
Robert

[1] Zylonite DT extract
	ssp3: ssp at 41900000 {
		compatible = "mrvl,pxa3xx-ssp";
		reg = <0x41900000 0x40>;
		interrupts = <0>;
		clocks = < &clks CLK_SSP3 >;
		dmas = <&pdma 66 3
			&pdma 67 3>;
		dma-names = "rx", "tx";
		pinctrl-names = "default";
		pinctrl-0 = < &pmux_ssp3_low_default
			      &pmux_ssp3_float_default >;
		status = "okay";
	};

	ssp_dai0: ssp_dai at 0 {
		compatible = "mrvl,pxa-ssp-dai";
		port = <&ssp3>;
		#sound-dai-cells = <0>;
	};
	ac97: sound at 40500000 {
	      	compatible = "marvell,pxa2xx-ac97";
		reg = < 0x40500000 0x1000 >;
		interrupts = <14>;
		reset-gpio = <&gpio 113 GPIO_ACTIVE_HIGH>;
		#sound-dai-cells = <1>;
		pinctrl-names = "default";
		pinctrl-0 = < &pmux_ac97_default >;
		status = "okay";
	};

	pxa_pcm_audio: snd_soc_pxa_audio {
		compatible = "mrvl,pxa-pcm-audio";
		#sound-dai-cells = <1>;
	};
	pxa_ssp_dai: snd_soc_pxa_audio {
		compatible = "mrvl,pxa-pcm-audio";
		#sound-dai-cells = <1>;
	};

	wm9713: wm9713 at 0 {
		compatible = "wlf,wm9713";
		#sound-dai-cells = <1>;
		pinctrl-names = "default";
		pinctrl-0 = < &pmux_wm9713_default >;
		status = "okay";
	};

	sound {
		compatible = "simple-audio-card";
		simple-audio-card,name = "Zylonite-Sound-Card";
		simple-audio-card,format = "ac97";
		simple-audio-card,widgets =
			"Headphone", "Headphone",
			"Microphone", "Headset Microphone",
			"Microphone", "Handset Microphone",
			"Speaker", "Multiactor",
			"Speaker", "Headset Earpiece";
		simple-audio-card,routing =
			"Headphone", "HPL",		/* Headphone output */
			"Headphone", "HPR",		/* connected to HPL/HPR */
			"Headset Earpiece", "OUT3",	/* On-board earpiece */
			"MIC2A", "Mic Bias",			/* Headphone mic */
			"Mic Bias", "Headset Microphone",	/* Headphone mic */
			"MIC1", "Mic Bias",			/* On-board mic */
			"Mic Bias", "Handset Microphone",	/* On-board mic */
			"Multiactor", "SPKL",		/* Multiactor differentially */
			"Multiactor", "SPKR";		/* connected over SPKL/SPKR */
	
		simple-audio-card,dai-link at 0 {		/* AC97 */
			format = "ac97";
			cpu {
				sound-dai = <&ac97 0>;
			};
			codec {
				sound-dai = <&wm9713 0>;
			};
			plat {
				sound-dai = <&pxa_pcm_audio 0>;
			};
		};
		simple-audio-card,dai-link at 1 {		/* AC97 Aux */
			format = "ac97";
			cpu {
				sound-dai = <&ac97 1>;
			};
			codec {
				sound-dai = <&wm9713 1>;
			};
			plat {
				sound-dai = <&pxa_pcm_audio 0>;
			};
		};
		simple-audio-card,dai-link at 2 {		/* AC97 Voice */
			format = "i2s";
			cpu {
				sound-dai = <&ssp_dai0>;
			};
			codec {
				sound-dai = <&wm9713 2>;
			};
			plat {
				sound-dai = <&pxa_pcm_audio 0>;
			};
		};
	};


From harba at codeaurora.org  Sat Feb 20 12:47:32 2016
From: harba at codeaurora.org (Abdulhamid, Harb)
Date: Sat, 20 Feb 2016 15:47:32 -0500
Subject: [PATCH] ARM64: ACPI: Update documentation for latest
 specification version
In-Reply-To: <1455926041-9579-1-git-send-email-al.stone@linaro.org>
References: <1455926041-9579-1-git-send-email-al.stone@linaro.org>
Message-ID: <56C8D0E4.1090106@codeaurora.org>

On 2/19/2016 6:54 PM, al.stone at linaro.org wrote:
> From: Al Stone <al.stone at linaro.org>	
> 
> The ACPI 6.1 specification was recently released at the end of January 2016,
> but the arm64 kernel documentation for the use of ACPI was written for the
> 5.1 version of the spec.  There were significant additions to the spec that
> had not yet been mentioned -- for example, the 6.0 mechanisms added to make
> it easier to define processors and low power idle states, as well as the
> 6.1 addition allowing regular interrupts (not just from GPIO) be used to
> signal ACPI general purpose events.
> 
> This patch reflects going back through and examining the specs in detail
> and updating content appropriately.  Whilst there, a few odds and ends of
> typos were caught as well.  This brings the documentation up to date with
> ACPI 6.1 for arm64.
> 
> Signed-off-by: Al Stone <al.stone at linaro.org>
> ---
>  Documentation/arm64/acpi_object_usage.txt | 433 ++++++++++++++++++++++--------
>  Documentation/arm64/arm-acpi.txt          |  28 +-
>  2 files changed, 346 insertions(+), 115 deletions(-)
> 
> diff --git a/Documentation/arm64/acpi_object_usage.txt b/Documentation/arm64/acpi_object_usage.txt
> index a6e1a18..e321235 100644
> --- a/Documentation/arm64/acpi_object_usage.txt
> +++ b/Documentation/arm64/acpi_object_usage.txt
> @@ -13,13 +13,14 @@ For ACPI on arm64, tables also fall into the following categories:
>  
>         -- Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT
>  
> -       -- Recommended: BERT, EINJ, ERST, HEST, SSDT
> +       -- Recommended: BERT, EINJ, ERST, HEST, IORT, PCCT, SSDT
>  
> -       -- Optional: BGRT, CPEP, CSRT, DRTM, ECDT, FACS, FPDT, MCHI, MPST,
> -          MSCT, RASF, SBST, SLIT, SPMI, SRAT, TCPA, TPM2, UEFI
> +       -- Optional: BGRT, CPEP, CSRT, DBG2, DRTM, ECDT, FACS, FPDT, MCHI,
> +          MPST, MSCT, NFIT, PMTT, RASF, SBST, SLIT, SPMI, SRAT, STAO, TCPA,
> +	  TPM2, UEFI, XENV

Unintended tabs? Alignment is off in my viewer.

>  
> -       -- Not supported: BOOT, DBG2, DBGP, DMAR, ETDT, HPET, IBFT, IVRS,
> -          LPIT, MSDM, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
> +       -- Not supported: BOOT, DBGP, DMAR, ETDT, HPET, IBFT, IVRS, LPIT, 
> +          MSDM, OEMx, PSDT, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
>  
>  
>  Table  Usage for ARMv8 Linux
> @@ -50,7 +51,9 @@ CSRT   Signature Reserved (signature == "CSRT")
>  
>  DBG2   Signature Reserved (signature == "DBG2")
>         == DeBuG port table 2 ==
> -       Microsoft only table, will not be supported.
> +       License has changed and should be usable.  Patches are available as of
> +       this writing, but they have not been accepted into the kernel.  Optional
> +       if used instead of earlycon=<device> on the command line.
>  
>  DBGP   Signature Reserved (signature == "DBGP")
>         == DeBuG Port table ==
> @@ -133,10 +136,11 @@ GTDT   Section 5.2.24 (signature == "GTDT")
>  
>  HEST   Section 18.3.2 (signature == "HEST")
>         == Hardware Error Source Table ==
> -       Until further error source types are defined, use only types 6 (AER
> -       Root Port), 7 (AER Endpoint), 8 (AER Bridge), or 9 (Generic Hardware
> -       Error Source).  Firmware first error handling is possible if and only
> -       if Trusted Firmware is being used on arm64.
> +       ARM-specific error sources have been defined; please use those or the
> +       PCI types such as type 6 (AER Root Port), 7 (AER Endpoint), or 8 (AER 
> +       Bridge), or use type 9 (Generic Hardware Error Source).  Firmware first
> +       error handling is possible if and only if Trusted Firmware is being 
> +       used on arm64.
>  
>         Must be supplied if RAS support is provided by the platform.  It
>         is recommended this table be supplied.
> @@ -149,20 +153,26 @@ IBFT   Signature Reserved (signature == "IBFT")
>         == iSCSI Boot Firmware Table ==
>         Microsoft defined table, support TBD.
>  
> +IORT   Signature Reserved (signature == "IORT")
> +       == Input Output Remapping Table ==
> +       arm64 only table, required in order to describe the SMMU and/or ITS 
> +       when it is provided by the platform.
> +
>  IVRS   Signature Reserved (signature == "IVRS")
>         == I/O Virtualization Reporting Structure ==
>         x86_64 (AMD) only table, will not be supported.
>  
>  LPIT   Signature Reserved (signature == "LPIT")
>         == Low Power Idle Table ==
> -       x86 only table as of ACPI 5.1; future versions have been adapted for
> -       use with ARM and will be recommended in order to support ACPI power
> -       management.
> +       x86 only table as of ACPI 5.1; starting with ACPI 6.0, processor
> +       descriptions and power states on ARM platforms should use the DSDT
> +       and define processor container devices (_HID ACPI0010, Section 8.4,
> +       and more specifically 8.4.3 and and 8.4.4).
>  
>  MADT   Section 5.2.12 (signature == "APIC")
>         == Multiple APIC Description Table ==
>         Required for arm64.  Only the GIC interrupt controller structures
> -       should be used (types 0xA - 0xE).
> +       should be used (types 0xA - 0xF).
>  
>  MCFG   Signature Reserved (signature == "MCFG")
>         == Memory-mapped ConFiGuration space ==
> @@ -176,14 +186,38 @@ MPST   Section 5.2.21 (signature == "MPST")
>         == Memory Power State Table ==
>         Optional, not currently supported.
>  
> +MSCT   Section 5.2.19 (signature == "MSCT")
> +       == Maximum System Characteristic Table ==
> +       Optional, not currently supported.
> +
>  MSDM   Signature Reserved (signature == "MSDM")
>         == Microsoft Data Management table ==
>         Microsoft only table, will not be supported.
>  
> -MSCT   Section 5.2.19 (signature == "MSCT")
> -       == Maximum System Characteristic Table ==
> +NFIT   Section 5.2.25 (signature == "NFIT")
> +       == NVDIMM Firmware Interface Table ==
>         Optional, not currently supported.
>  
> +OEMx   Signature of "OEMx" only
> +       == OEM Specific Tables ==
> +       All tables starting with a signature of "OEM" are reserved for OEM
> +       use.  Since these are not meant to be of general use but are limited
> +       to very specific end users, they are not recommended for use and are
> +       not supported by the kernel for arm64.
> +
> +PCCT   Section 14.1 (signature == "PCCT)
> +       == Platform Communications Channel Table ==
> +       Recommend for use on arm64, and required when using CPPC to control
> +       power on the platform.
> +
> +PMTT   Section 5.2.21.12 (signature == "PMTT")
> +       == Platform Memory Topology Table ==
> +       Optional, but useful, but not currently supported.
> +
> +PSDT   Section 5.2.11.3 (signature == "PSDT")
> +       == Persistent System Description Table ==
> +       Obsolete table, will not be supported.
> +
>  RASF   Section 5.2.20 (signature == "RASF")
>         == RAS Feature table ==
>         Optional, not currently supported.
> @@ -195,7 +229,7 @@ RSDP   Section 5.2.5 (signature == "RSD PTR")
>  RSDT   Section 5.2.7 (signature == "RSDT")
>         == Root System Description Table ==
>         Since this table can only provide 32-bit addresses, it is deprecated
> -       on arm64, and will not be used.
> +       on arm64, and will not be used.  If provided, it will be ignored.
>  
>  SBST   Section 5.2.14 (signature == "SBST")
>         == Smart Battery Subsystem Table ==
> @@ -207,7 +241,7 @@ SLIC   Signature Reserved (signature == "SLIC")
>  
>  SLIT   Section 5.2.17 (signature == "SLIT")
>         == System Locality distance Information Table ==
> -       Optional in general, but required for NUMA systems.
> +       Optional in general, but required for arm64 NUMA systems.
>  
>  SPCR   Signature Reserved (signature == "SPCR")
>         == Serial Port Console Redirection table ==
> @@ -220,7 +254,7 @@ SPMI   Signature Reserved (signature == "SPMI")
>  SRAT   Section 5.2.16 (signature == "SRAT")
>         == System Resource Affinity Table ==
>         Optional, but if used, only the GICC Affinity structures are read.
> -       To support NUMA, this table is required.
> +       To support arm64 NUMA, this table is required.
>  
>  SSDT   Section 5.2.11.2 (signature == "SSDT")
>         == Secondary System Description Table ==
> @@ -235,6 +269,11 @@ SSDT   Section 5.2.11.2 (signature == "SSDT")
>         These tables are optional, however.  ACPI tables should contain only
>         one DSDT but can contain many SSDTs.
>  
> +STAO   Signature Reserved (signature == "STAO")
> +       == _STA Override table ==
> +       Optional, but only necessary in virtualized environments in order to
> +       hide devices from guest OSs.
> +
>  TCPA   Signature Reserved (signature == "TCPA")
>         == Trusted Computing Platform Alliance table ==
>         Optional, not currently supported, and may need changes to fully
> @@ -266,6 +305,10 @@ WPBT   Signature Reserved (signature == "WPBT")
>         == Windows Platform Binary Table ==
>         Microsoft only table, will not be supported.
>  
> +XENV   Signature Reserved (signature == "XENV")
> +       == Xen project table ==
> +       Optional, used only by Xen at present.
> +
>  XSDT   Section 5.2.8 (signature == "XSDT")
>         == eXtended System Description Table ==
>         Required for arm64.
> @@ -273,31 +316,50 @@ XSDT   Section 5.2.8 (signature == "XSDT")
>  
>  ACPI Objects
>  ------------
> -The expectations on individual ACPI objects are discussed in the list that
> -follows:
> +The expectations on individual ACPI objects that are likely to be used are
> +shown in the list that follows:
>  
>  Name   Section         Usage for ARMv8 Linux
>  ----   ------------    -------------------------------------------------
> +_ACx   11.4.1          Use as needed.
> +
>  _ADR   6.1.1           Use as needed.
>  
> +_ALx   11.4.2          Use as needed.
> +
> +_ART   11.4.3          Use as needed.
> +
>  _BBN   6.5.5           Use as needed; PCI-specific.
>  
> -_BDN   6.5.3           Optional; not likely to be used on arm64.
> +_CCA   6.2.17          This method must be defined for all bus masters
> +                       on arm64 -- there are no assumptions made about
> +		       whether such devices are cache coherent or not.
> +		       The _CCA value is inherited by all descendants of
> +		       these devices so it does not need to be repeated.
> +                       Without _CCA on arm64, the kernel does not know what
> +		       to do about setting up DMA for the device.
> +
Alignment issue again.

I would also add the following clarification to this (maybe not as verbose):
Note that CCA provides the default cache coherent attributes, however
the presence of an SMMU could potentially be used to modify bus
attributes.  For example, if a master defaults to non-coherent, it could
be made coherent with the appropriate SMMU configuration.  Please refer
to Table 17 of the IORT specification (Document Number: ARM DEN 0049B)
for more information.

> +_CDM   6.2.1           Use as needed, to be used only for processor devices.
>  
> -_CCA   6.2.17          This method should be defined for all bus masters
> -                       on arm64.  While cache coherency is assumed, making
> -                       it explicit ensures the kernel will set up DMA as
> -                       it should.
> +_CID   6.1.2           Use as needed, see also _HID.
>  
> -_CDM   6.2.1           Optional, to be used only for processor devices.
> +_CLS   6.1.3           Use as needed, see also _HID.
>  
> -_CID   6.1.2           Use as needed.
> +_CPC   8.4.7.1         Use as needed; power management specific.  CPPC is
> +                       recommended on arm64.
>  
> -_CLS   6.1.3           Use as needed.
> +_CR3   11.4.5          Use as needed.
>  
>  _CRS   6.2.2           Required on arm64.
>  
> -_DCK   6.5.2           Optional; not likely to be used on arm64.
> +_CRT   11.4.4          Use as needed.
> +
> +_CSD   8.4.2.2         Use as needed, used only in conjuction with _CST.
> +
> +_CST   8.4.2.1         Low power idle states (8.4.4) are recommended instead
> +                       of C-states.
> +
> +_CWS   9.18.6          Use as needed.
>  
>  _DDN   6.1.4           This field can be used for a device name.  However,
>                         it is meant for DOS device names (e.g., COM1), so be
> @@ -305,11 +367,11 @@ _DDN   6.1.4           This field can be used for a device name.  However,
>  
>  _DEP   6.5.8           Use as needed.
>  
> -_DIS   6.2.3           Optional, for power management use.
> +_DIS   6.2.3           Use as needed, for power management use.
>  
> -_DLM   5.7.5           Optional.
> +_DLM   5.7.5           Use as needed.
>  
> -_DMA   6.2.4           Optional.
> +_DMA   6.2.4           Use as needed.
>  
>  _DSD   6.2.5           To be used with caution.  If this object is used, try
>                         to use it within the constraints already defined by the
> @@ -325,19 +387,29 @@ _DSD   6.2.5           To be used with caution.  If this object is used, try
>                         with the UEFI Forum; this may cause some iteration as
>                         more than one OS will be registering entries.
>  
> -_DSM                   Do not use this method.  It is not standardized, the
> +_DSM   9.1.1           Do not use this method.  It is not standardized, the
>                         return values are not well documented, and it is
>                         currently a frequent source of error.
>  
> -_DSW   7.2.1           Use as needed; power management specific.
> +_DSW   7.3.1           Use as needed; power management specific.
>  
> -_EDL   6.3.1           Optional.
> +_DTI   11.4.6          Use as needed.
>  
> -_EJD   6.3.2           Optional.
> +_EDL   6.3.1           Use as needed.
>  
> -_EJx   6.3.3           Optional.
> +_EJD   6.3.2           Use as needed.
>  
> -_FIX   6.2.7           x86 specific, not used on arm64.
> +_EJx   6.3.3           Use as needed.
> +
> +_FIF   11.3.1.1        Use as needed.
> +
> +_FPS   11.3.1.2        Use as needed.
> +
> +_FSL   11.3.1.3        Use as needed.
> +
> +_FST   11.3.1.4        Use as needed.
> +
> +_GCP   9.18.2          Use as needed.
>  
>  \_GL   5.7.1           This object is not to be used in hardware reduced
>                         mode, and therefore should not be used on arm64.
> @@ -349,35 +421,56 @@ _GLK   6.5.7           This object requires a global lock be defined; there
>  \_GPE  5.3.1           This namespace is for x86 use only.  Do not use it
>                         on arm64.
>  
> -_GSB   6.2.7           Optional.
> +_GRT   9.18.3          Use as needed.
> +
> +_GSB   6.2.7           Use as needed.
> +
> +_GTF   9.9.1.1         Use as needed.
> +
> +_GWS   9.18.5          Use as needed.
>  
>  _HID   6.1.5           Use as needed.  This is the primary object to use in
>                         device probing, though _CID and _CLS may also be used.
>  
> -_HPP   6.2.8           Optional, PCI specific.
> +_HOT   11.4.7          Use as needed.
> +
> +_HPP   6.2.8           Use as needed, PCI specific.
>  
> -_HPX   6.2.9           Optional, PCI specific.
> +_HPX   6.2.9           Use as needed, PCI specific.
>  
> -_HRV   6.1.6           Optional, use as needed to clarify device behavior; in
> +_HRV   6.1.6           Use as needed, use as needed to clarify device behavior; in
>                         some cases, this may be easier to use than _DSD.
>  
>  _INI   6.5.1           Not required, but can be useful in setting up devices
>                         when UEFI leaves them in a state that may not be what
>                         the driver expects before it starts probing.
>  
> -_IRC   7.2.15          Use as needed; power management specific.
> +_IRC   7.3.15          Use as needed; power management specific.
> +
> +_LCK   6.3.4           Use as needed.
> +
> +_LPI   8.4.4.3         Use as needed, but recommended for use with processor
> +                       definitions (_HID ACPI0010) on arm64.
>  
> -_LCK   6.3.4           Optional.
> +_MAT   6.2.10          Use as needed; see also the MADT.
>  
> -_MAT   6.2.10          Optional; see also the MADT.
> +_MBM   9.13.2.1        Use as needed.
>  
> -_MLS   6.1.7           Optional, but highly recommended for use in
> +_MLS   6.1.7           Use as needed, but highly recommended for use in
>                         internationalization.
>  
> -_OFF   7.1.2           It is recommended to define this method for any device
> +_MSG   9.2.2           Use as needed.
> +
> +_MSM   9.13.2.2        Use as needed.
> +
> +_MTL   11.4.8          Use as needed.
> +
> +_NTT   11.4.9          Use as needed.
> +
> +_OFF   7.2.2           It is recommended to define this method for any device
>                         that can be turned on or off.
>  
> -_ON    7.1.3           It is recommended to define this method for any device
> +_ON    7.2.3           It is recommended to define this method for any device
>                         that can be turned on or off.
>  
>  \_OS   5.7.3           This method will return "Linux" by default (this is
> @@ -405,115 +498,219 @@ _OSC   6.2.11          This method can be a global method in ACPI (i.e.,
>                         being used or what functionality is provided.  The
>                         _OSC method is to be used instead.
>  
> -_OST   6.3.5           Optional.
> +_OST   6.3.5           Use as needed.
> +
> +_PCT   8.4.6.1         Use as needed; power management specific.
>  
>  _PDC   8.4.1           Deprecated, do not use on arm64.
>  
> +_PDL   8.4.6.2         Use as needed; power management specific.
> +
>  \_PIC  5.8.1           The method should not be used.  On arm64, the only
>                         interrupt model available is GIC.
>  
> -_PLD   6.1.8           Optional.
> +_PLD   6.1.8           Use as needed.
> +
> +_PPC   8.4.6.3         Use as needed; power management specific.
> +
> +_PPE   8.4.8           Use as needed.
>  
>  \_PR   5.3.1           This namespace is for x86 use only on legacy systems.
>                         Do not use it on arm64.
>  
> -_PRS   6.2.12          Optional.
> +_PRE   7.3.12          Use as needed; power management specific.
> +
> +_PRR   7.3.26          Use as needed; power management specific.
> +
> +_PRS   6.2.12          Use as needed.
>  
>  _PRT   6.2.13          Required as part of the definition of all PCI root
>                         devices.
>  
> -_PRW   7.2.13          Use as needed; power management specific.
> +_PRW   7.3.13          Use as needed; power management specific.
>  
> -_PRx   7.2.8-11        Use as needed; power management specific.  If _PR0 is
> +_PRx   7.3.8-11        Use as needed; power management specific.  If _PR0 is
>                         defined, _PR3 must also be defined.
>  
> -_PSC   7.2.6           Use as needed; power management specific.
> +_PSC   7.3.6           Use as needed; power management specific.
> +
> +_PSD   8.4.6.5         Use as needed; power management specific.
>  
> -_PSE   7.2.7           Use as needed; power management specific.
> +_PSE   7.3.7           Use as needed; power management specific.
>  
> -_PSW   7.2.14          Use as needed; power management specific.
> +_PSL   11.4.10         Use as needed.
>  
> -_PSx   7.2.2-5         Use as needed; power management specific.  If _PS0 is
> +_PSS   8.4.6.2         Use as needed; power management specific.
> +
> +_PSV   11.4.11         Use as needed.
> +
> +_PSW   7.3.14          Use as needed; power management specific.
> +
> +_PSx   7.3.2-5         Use as needed; power management specific.  If _PS0 is
>                         defined, _PS3 must also be defined.  If clocks or
>                         regulators need adjusting to be consistent with power
>                         usage, change them in these methods.
>  
> -\_PTS  7.3.1           Use as needed; power management specific.
> +_PTC   8.4.5.1         Use as needed; power management specific.
> +
> +\_PTS  7.4.1           Use as needed; power management specific.
> +
> +_PUR   8.5.1.1         Use as needed.
> +
> +_PXM   6.2.14          Use as needed.
>  
> -_PXM   6.2.14          Optional.
> +_RDI   8.4.4.4         Use as needed, but recommended for use with processor
> +                       definitions (_HID ACPI0010) on arm64.
>  
>  _REG   6.5.4           Use as needed.
>  
>  \_REV  5.7.4           Always returns the latest version of ACPI supported.
>  
> -_RMV   6.3.6           Optional.
> +_RMV   6.3.6           Use as needed.
> +
> +_RST   7.3.25          Use as needed; power management specific.
> +
> +_RTV   11.4.12         Use as needed.
>  
>  \_SB   5.3.1           Required on arm64; all devices must be defined in this
>                         namespace.
>  
> +_SCP   11.4.13         Use as needed.
> +
> +_SDD   9.9.3.3.1       Use as needed.
> +
>  _SEG   6.5.6           Use as needed; PCI-specific.
>  
> -\_SI   5.3.1,          Optional.
> -       9.1
> +\_SI   5.3.1,          Use as needed.
> +       9.2
> +
> +_SLI   6.2.15          Use as needed; recommended when SLIT table is in use.
>  
> -_SLI   6.2.15          Optional; recommended when SLIT table is in use.
> +_SRT   9.18.4          Use as needed.
>  
>  _STA   6.3.7,          It is recommended to define this method for any device
> -       7.1.4           that can be turned on or off.
> +       7.2.4           that can be turned on or off.  See also the STAO table
> +       		       that provides overrides to hide devices in virtualized
> +		       environments.
Alignment issue again.

>  
> -_SRS   6.2.16          Optional; see also _PRS.
> +_SRS   6.2.16          Use as needed; see also _PRS.
> +
> +_SST   9.2.1           Use as needed.
>  
>  _STR   6.1.10          Recommended for conveying device names to end users;
>                         this is preferred over using _DDN.
>  
> +_SST   9.2.1           Use as needed.
> +
> +_STP   9.18.7          Use as needed.
> +
> +_STV   9.18.8          Use as needed.
> +
>  _SUB   6.1.9           Use as needed; _HID or _CID are preferred.
>  
> -_SUN   6.1.11          Optional.
> +_SUN   6.1.11          Use as needed, but recommended.
>  
> -\_Sx   7.3.2           Use as needed; power management specific.
> +\_Sx   7.4.2           Use as needed; power management specific.
>  
> -_SxD   7.2.16-19       Use as needed; power management specific.
> +_SxD   7.3.16-19       Use as needed; power management specific.
>  
> -_SxW   7.2.20-24       Use as needed; power management specific.
> +_SxW   7.3.20-24       Use as needed; power management specific.
>  
> -_SWS   7.3.3           Use as needed; power management specific; this may
> +_SWS   7.4.3           Use as needed; power management specific; this may
>                         require specification changes for use on arm64.
>  
> -\_TTS  7.3.4           Use as needed; power management specific.
> +_TC1   11.4.14         Use as needed.
> +
> +_TC2   11.4.15         Use as needed.
> +
> +_TDL   8.4.5.5         Use as needed; power management specific.
> +
> +_TFP   11.4.16         Use as needed.
> +
> +_TIP   9.18.9          Use as needed.
> +
> +_TIV   9.18.10         Use as needed.
> +
> +_TMP   11.4.17         Use as needed.
> +
> +_TPC   8.4.5.3         Use as needed; power management specific.
>  
> -\_TZ   5.3.1           Optional.
> +_TPT   11.4.18         Use as needed.
> +
> +_TRT   11.4.19         Use as needed.
> +
> +_TSD   8.4.5.4         Use as needed; power management specific.
> +
> +_TSN   11.4.20         Use as needed.
> +
> +_TSP   11.4.21         Use as needed.
> +
> +_TSS   8.4.5.2         Use as needed; power management specific.
> +
> +_TST   11.4.22         Use as needed.
> +
> +\_TTS  7.4.4           Use as needed; power management specific.
> +
> +\_TZ   5.3.1           Use as needed.
> +
> +_TZD   11.4.23         Use as needed.
> +
> +_TZM   11.4.24         Use as needed.
> +
> +_TZP   11.4.25         Use as needed.
>  
>  _UID   6.1.12          Recommended for distinguishing devices of the same
>                         class; define it if at all possible.
>  
> -\_WAK  7.3.5           Use as needed; power management specific.
> +_UPC   9.14            Use as needed.
> +
> +\_WAK  7.4.5           Use as needed; power management specific.
> +
> +
>  
>  
>  ACPI Event Model
>  ----------------
>  Do not use GPE block devices; these are not supported in the hardware reduced
>  profile used by arm64.  Since there are no GPE blocks defined for use on ARM
> -platforms, GPIO-signaled interrupts should be used for creating system events.
> +platforms, ACPI events must be signaled differently.
> +
> +There are two options: GPIO-signaled interrupts (Section 5.6.5), and 
> +interrupt-signaled events (Section 5.6.9).  Interrupt-signaled events are a
> +new feature in the ACPI 6.1 specification.  Either -- or both -- can be used
> +on a given platform, and which to use may be dependent of limitations in any
> +given SoC.  If possible, interrupt-signaled events are recommended.
>  
>  
>  ACPI Processor Control
>  ----------------------
> -Section 8 of the ACPI specification is currently undergoing change that
> -should be completed in the 6.0 version of the specification.  Processor
> -performance control will be handled differently for arm64 at that point
> -in time.  Processor aggregator devices (section 8.5) will not be used,
> -for example, but another similar mechanism instead.
> -
> -While UEFI constrains what we can say until the release of 6.0, it is
> -recommended that CPPC (8.4.5) be used as the primary model.  This will
> -still be useful into the future.  C-states and P-states will still be
> -provided, but most of the current design work appears to favor CPPC.
> +Section 8 of the ACPI specification changed significantly in version 6.0.
> +Processors should now be defined as Device objects with _HID ACPI0007; do
> +not use the deprecated Processor statement in ASL.  All multiprocessor systems
> +should also define a hierarchy of processors, done with Processor Container
> +Devices (see Section 8.4.3.1, _HID ACPI0010); do not use processor aggregator
> +devices (Section 8.5) to describe processor topology.  Section 8.4 of the
> +specification describes the semantics of these object definitions and how 
> +they interrelate.
> +
> +Most importantly, the processor hierarchy defined also defines the low power
> +idle states that are available to the platform, along with the rules for
> +determining which processors can be turned on or off and the circumstances
> +that control that.  Without this information, the processors will run in
> +whatever power state they were left in by UEFI.
> +
> +Note too, that the processor Device objects defined and the entries in the
> +MADT for GICs are expected to be in sychronization.  The _UID of the Device
> +object must correspond to processor IDs used in the MADT.
> +
> +It is recommended that CPPC (8.4.5) be used as the primary model for processor
> +performance control on arm64.  C-states and P-states may become available at
> +some point in the future, but most current design work appears to favor CPPC.
>  
>  Further, it is essential that the ARMv8 SoC provide a fully functional
>  implementation of PSCI; this will be the only mechanism supported by ACPI
> -to control CPU power state (including secondary CPU booting).
> -
> -More details will be provided on the release of the ACPI 6.0 specification.
> +to control CPU power state.  Booting of secondary CPUs may be possible using
> +parking protocol, but only PSCI is to be used for ARM servers.
>  
>  
>  ACPI System Address Map Interfaces
> @@ -535,21 +732,25 @@ used to indicate fatal errors that cannot be corrected, and require immediate
>  attention.
>  
>  Since there is no direct equivalent of the x86 SCI or NMI, arm64 handles
> -these slightly differently.  The SCI is handled as a normal GPIO-signaled
> -interrupt; given that these are corrected (or correctable) errors being
> -reported, this is sufficient.  The NMI is emulated as the highest priority
> -GPIO-signaled interrupt possible.  This implies some caution must be used
> -since there could be interrupts at higher privilege levels or even interrupts
> -at the same priority as the emulated NMI.  In Linux, this should not be the
> -case but one should be aware it could happen.
> +these slightly differently.  The SCI is handled as a high priority interrupt;
> +given that these are corrected (or correctable) errors being reported, this
> +is sufficient.  The NMI is emulated as the highest priority interrupt 
> +possible.  This implies some caution must be used since there could be 
> +interrupts at higher privilege levels or even interrupts at the same priority
> +as the emulated NMI.  In Linux, this should not be the case but one should 
> +be aware it could happen.
>  
>  
>  ACPI Objects Not Supported on ARM64
>  -----------------------------------
>  While this may change in the future, there are several classes of objects
>  that can be defined, but are not currently of general interest to ARM servers.
> +Some of these objects have x86 equivalents, and may actually make sense in ARM
> +servers.  However, there is either no hardware available at present, or there
> +may not even be a non-ARM implementation yet.  Hence, they are not currently
> +supported.
>  
> -These are not supported:
> +The following classes of objects are not supported:
>  
>         -- Section 9.2: ambient light sensor devices
>  
> @@ -571,16 +772,6 @@ These are not supported:
>  
>         -- Section 9.18: time and alarm devices (see 9.15)
>  
> -
> -ACPI Objects Not Yet Implemented
> ---------------------------------
> -While these objects have x86 equivalents, and they do make some sense in ARM
> -servers, there is either no hardware available at present, or in some cases
> -there may not yet be a non-ARM implementation.  Hence, they are currently not
> -implemented though that may change in the future.
> -
> -Not yet implemented are:
> -
>         -- Section 10: power source and power meter devices
>  
>         -- Section 11: thermal management
> @@ -589,5 +780,31 @@ Not yet implemented are:
>  
>         -- Section 13: SMBus interfaces
>  
> -       -- Section 17: NUMA support (prototypes have been submitted for
> -          review)
> +
> +This also mean that there is no support for the following objects:
> +
> +Name   Section                     Name   Section
> +----   ------------                ----   ------------
> +_ALC   9.3.4                       _FDM   9.10.3
> +_ALI   9.3.2                       _FIX   6.2.7
> +_ALP   9.3.6                       _GAI   10.4.5
> +_ALR   9.3.5                       _GHL   10.4.7
> +_ALT   9.3.3                       _GTM   9.9.2.1.1
> +_BCT   10.2.2.10                   _LID   9.5.1
> +_BDN   6.5.3                       _PAI   10.4.4
> +_BIF   10.2.2.1                    _PCL   10.3.2
> +_BIX   10.2.2.1                    _PIF   10.3.3
> +_BLT   9.2.3                       _PMC   10.4.1
> +_BMA   10.2.2.4                    _PMD   10.4.8
> +_BMC   10.2.2.12                   _PMM   10.4.3
> +_BMD   10.2.2.11                   _PRL   10.3.4
> +_BMS   10.2.2.5                    _PSR   10.3.1
> +_BST   10.2.2.6                    _PTP   10.4.2
> +_BTH   10.2.2.7                    _SBS   10.1.3
> +_BTM   10.2.2.9                    _SHL   10.4.6
> +_BTP   10.2.2.8                    _STM   9.9.2.1.1
> +_DCK   6.5.2                       _UPD   9.16.1
> +_EC    12.12                       _UPP   9.16.2
> +_FDE   9.10.1                      _WPC   10.5.2
> +_FDI   9.10.2                      _WPP   10.5.3
> +
> diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> index 570a4f8..12381c1 100644
> --- a/Documentation/arm64/arm-acpi.txt
> +++ b/Documentation/arm64/arm-acpi.txt
> @@ -57,11 +57,11 @@ The short form of the rationale for ACPI on ARM is:
>  
>  -- The new ACPI governance process works well and Linux is now at the same
>     table as hardware vendors and other OS vendors.  In fact, there is no
> -   longer any reason to feel that ACPI is only belongs to Windows or that
> +   longer any reason to feel that ACPI only belongs to Windows or that
>     Linux is in any way secondary to Microsoft in this arena.  The move of
>     ACPI governance into the UEFI forum has significantly opened up the
>     specification development process, and currently, a large portion of the
> -   changes being made to ACPI is being driven by Linux.
> +   changes being made to ACPI are being driven by Linux.
>  
>  Key to the use of ACPI is the support model.  For servers in general, the
>  responsibility for hardware behaviour cannot solely be the domain of the
> @@ -159,7 +159,7 @@ Further, the ACPI core will only use the 64-bit address fields in the FADT
>  (Fixed ACPI Description Table).  Any 32-bit address fields in the FADT will
>  be ignored on arm64.
>  
> -Hardware reduced mode (see Section 4.1 of the ACPI 5.1 specification) will
> +Hardware reduced mode (see Section 4.1 of the ACPI 6.1 specification) will
>  be enforced by the ACPI core on arm64.  Doing so allows the ACPI core to
>  run less complex code since it no longer has to provide support for legacy
>  hardware from other architectures.  Any fields that are not to be used for
> @@ -167,7 +167,7 @@ hardware reduced mode must be set to zero.
>  
>  For the ACPI core to operate properly, and in turn provide the information
>  the kernel needs to configure devices, it expects to find the following
> -tables (all section numbers refer to the ACPI 5.1 specfication):
> +tables (all section numbers refer to the ACPI 6.1 specfication):
>  
>      -- RSDP (Root System Description Pointer), section 5.2.5
>  
> @@ -185,9 +185,22 @@ tables (all section numbers refer to the ACPI 5.1 specfication):
>      -- If PCI is supported, the MCFG (Memory mapped ConFiGuration
>         Table), section 5.2.6, specifically Table 5-31.
>  
> +    -- If booting without a console=<device> kernel parameter is
> +       supported, the SPCR (Serial Port Console Redirection table),
> +       section 5.2.6, specifically Table 5-31.
> +
> +    -- If virtualization is supported, the IORT (Input Output Remapping
> +       Table, section 5.2.6, specifically Table 5-31.
> +
> +    -- If NUMA is supported, the SRAT (System Resource Affinity Table)
> +       and SLIT (System Locality distance Information Table), sections
> +       5.2.16 and 5.2.17, respectively.
> +
>  If the above tables are not all present, the kernel may or may not be
>  able to boot properly since it may not be able to configure all of the
> -devices available.
> +devices available.  This list of tables is not meant to be all inclusive;
> +in some environments other tables may be needed (e.g., any of the APEI
> +tables from section 18) to support specific functionality.
>  
>  
>  ACPI Detection
> @@ -233,7 +246,7 @@ that looks like this: Name(KEY0, "value0").  An ACPI device driver would
>  then retrieve the value of the property by evaluating the KEY0 object.
>  However, using Name() this way has multiple problems: (1) ACPI limits
>  names ("KEY0") to four characters unlike DT; (2) there is no industry
> -wide registry that maintains a list of names, minimzing re-use; (3)
> +wide registry that maintains a list of names, minimizing re-use; (3)
>  there is also no registry for the definition of property values ("value0"),
>  again making re-use difficult; and (4) how does one maintain backward
>  compatibility as new hardware comes out?  The _DSD method was created
> @@ -434,7 +447,8 @@ The ACPI specification changes regularly.  During the year 2014, for instance,
>  version 5.1 was released and version 6.0 substantially completed, with most of
>  the changes being driven by ARM-specific requirements.  Proposed changes are
>  presented and discussed in the ASWG (ACPI Specification Working Group) which
> -is a part of the UEFI Forum.
> +is a part of the UEFI Forum.  The current version of the ACPI specification
> +is 6.1 release in January 2016.
>  
>  Participation in this group is open to all UEFI members.  Please see
>  http://www.uefi.org/workinggroup for details on group membership.
> 

The rest looks good.

Thanks,
Harb
-- 
Qualcomm Technologies, Inc.
on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From robert.jarzmik at free.fr  Sat Feb 20 12:54:17 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat, 20 Feb 2016 21:54:17 +0100
Subject: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
In-Reply-To: <3062977.Ya2ztQYFaM@wuerfel> (Arnd Bergmann's message of "Tue, 16
 Feb 2016 14:55:43 +0100")
References: <1453997722-3489596-1-git-send-email-arnd@arndb.de>
 <2702068.KRp0Bplb5Q@wuerfel> <m34md8rdol.fsf@t19.piap.pl>
 <3062977.Ya2ztQYFaM@wuerfel>
Message-ID: <87povrxfuu.fsf@belgarion.home>

Arnd Bergmann <arnd at arndb.de> writes:

> Coming back to the specific pxa25x_udc case: using __raw_* accessors
> in the driver would possibly end up breaking the PXA25x machines in
> the (very unlikely) case that someone wants to make it work with
> big-endian kernels, assuming it does not have the same hardware
> byteswap logic as ixp4xx.

As far as I know, pxa25x machine implies the kernel is little endian. From an
hardware perspective, pxa25x doesn't support big endian (old ARM platform).

So I don't think considering BE for pxa25x is ... necessary.

Cheers.

-- 
Robert


From robert.jarzmik at free.fr  Sat Feb 20 13:03:41 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat, 20 Feb 2016 22:03:41 +0100
Subject: [PATCH] ARM: pxa: pxa3xx device-tree support cleanup
In-Reply-To: <1454795315-11294-1-git-send-email-robert.jarzmik@free.fr>
 (Robert Jarzmik's message of "Sat, 6 Feb 2016 22:48:35 +0100")
References: <1454795315-11294-1-git-send-email-robert.jarzmik@free.fr>
Message-ID: <87lh6fxff6.fsf@belgarion.home>

Robert Jarzmik <robert.jarzmik at free.fr> writes:

> Clocks, timer and several other drivers have well defined and working
> device-tree bindings. Clean-up the code to leave only the strict
> minimum. The final goal will be to remove the lookup array.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
Queued to pxa/for-next, thanks.

--
Robert


From broonie at kernel.org  Sat Feb 20 13:16:59 2016
From: broonie at kernel.org (Mark Brown)
Date: Sun, 21 Feb 2016 06:16:59 +0900
Subject: [PATCH 1/4] ASoC: wm9713: add binding for WM9713 codec
In-Reply-To: <87twl3xgud.fsf@belgarion.home>
References: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
 <20160220171459.GA18327@sirena.org.uk>
 <871t87z1gz.fsf@belgarion.home>
 <20160220195925.GF18327@sirena.org.uk>
 <87twl3xgud.fsf@belgarion.home>
Message-ID: <20160220211659.GG18327@sirena.org.uk>

On Sat, Feb 20, 2016 at 09:32:58PM +0100, Robert Jarzmik wrote:
> Mark Brown <broonie at kernel.org> writes:
> > On Sat, Feb 20, 2016 at 07:22:04PM +0100, Robert Jarzmik wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> > There is a generic AC'97 PXA driver in sound/arm, if your system can use that
> > that'd be a better route to DT integration for it I think.
> I'm open on the topic.

> Historically, I use sound/soc/pxa/pxa2xx-ac97.c since 2008. I know it works, but
> if you think I should examine sound/arm/pxa2xx-ac97.c, let's do that.
> 
> > Did you try that, if there are problems with that perhaps we can improve that
> > driver, it should be simpler.

> I will. By now I fail to see how this will help in the wm9713 probing and
> detection ...

It will eumerate the AC'97 bus by itself and does not need the CODEC to
be described.

> Until I make the try, here is what I have as a device-tree extract in [1], which
> is my candidate for sound/soc/pxa/zylonite.c replacement.. If we conclude that
> wm9713 shouldn't be in device-tree, then I'm curious how the DAI bindings
> (simple-audio-card,dai-link*) should be handled.

They should be created as a function of enumerating the CODEC.  If you
use the genric AC'97 stuff it doesn't use ASoC at all and this happens
as a side effect.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160221/44d75648/attachment.sig>

From draakje197 at gmail.com  Sat Feb 20 13:28:25 2016
From: draakje197 at gmail.com (hp197)
Date: Sat, 20 Feb 2016 22:28:25 +0100
Subject: [PATCH] Fix sun7i pin assignment for IRQ's
Message-ID: <1456003710-14807-1-git-send-email-henry@nitronetworks.nl>

IRQ pins are now according this page: http://linux-sunxi.org/A20/PIO

Signed-off-by: hp197 <henry at nitronetworks.nl>
---
 drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
index cf1ce0c..4db5e19 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
@@ -344,25 +344,21 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE4 */
 		  SUNXI_FUNCTION(0x3, "spi2"),		/* CS0 */
-		  SUNXI_FUNCTION_IRQ(0x6, 12)),		/* EINT12 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 20),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE5 */
 		  SUNXI_FUNCTION(0x3, "spi2"),		/* CLK */
-		  SUNXI_FUNCTION_IRQ(0x6, 13)),		/* EINT13 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 21),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE6 */
 		  SUNXI_FUNCTION(0x3, "spi2"),		/* MOSI */
-		  SUNXI_FUNCTION_IRQ(0x6, 14)),		/* EINT14 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 22),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE7 */
 		  SUNXI_FUNCTION(0x3, "spi2"),		/* MISO */
-		  SUNXI_FUNCTION_IRQ(0x6, 15)),		/* EINT15 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 23),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
@@ -960,65 +956,55 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS0 */
 		  SUNXI_FUNCTION(0x3, "uart5"),		/* TX */
-		  SUNXI_FUNCTION_IRQ(0x5, 22)),		/* EINT22 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 11),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CLK */
 		  SUNXI_FUNCTION(0x3, "uart5"),		/* RX */
-		  SUNXI_FUNCTION_IRQ(0x5, 23)),		/* EINT23 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 12),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* MOSI */
 		  SUNXI_FUNCTION(0x3, "uart6"),		/* TX */
 		  SUNXI_FUNCTION(0x4, "clk_out_a"),	/* CLK_OUT_A */
-		  SUNXI_FUNCTION_IRQ(0x5, 24)),		/* EINT24 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 13),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* MISO */
 		  SUNXI_FUNCTION(0x3, "uart6"),		/* RX */
 		  SUNXI_FUNCTION(0x4, "clk_out_b"),	/* CLK_OUT_B */
-		  SUNXI_FUNCTION_IRQ(0x5, 25)),		/* EINT25 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 14),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS1 */
 		  SUNXI_FUNCTION(0x3, "ps2"),		/* SCK1 */
 		  SUNXI_FUNCTION(0x4, "timer4"),	/* TCLKIN0 */
-		  SUNXI_FUNCTION_IRQ(0x5, 26)),		/* EINT26 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 15),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS1 */
 		  SUNXI_FUNCTION(0x3, "ps2"),		/* SDA1 */
 		  SUNXI_FUNCTION(0x4, "timer5"),	/* TCLKIN1 */
-		  SUNXI_FUNCTION_IRQ(0x5, 27)),		/* EINT27 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 16),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS0 */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* RTS */
-		  SUNXI_FUNCTION_IRQ(0x5, 28)),		/* EINT28 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 17),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CLK */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* CTS */
-		  SUNXI_FUNCTION_IRQ(0x5, 29)),		/* EINT29 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 18),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* MOSI */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* TX */
-		  SUNXI_FUNCTION_IRQ(0x5, 30)),		/* EINT30 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 19),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* MISO */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* RX */
-		  SUNXI_FUNCTION_IRQ(0x5, 31)),		/* EINT31 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 20),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
-- 
2.5.0



From robert.jarzmik at free.fr  Sat Feb 20 13:39:15 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat, 20 Feb 2016 22:39:15 +0100
Subject: [PATCH v2 4/4] dmaengine: pxa_dma: fix the maximum requestor line
In-Reply-To: <1455569868-25017-4-git-send-email-robert.jarzmik@free.fr>
 (Robert Jarzmik's message of "Mon, 15 Feb 2016 21:57:48 +0100")
References: <1455569868-25017-1-git-send-email-robert.jarzmik@free.fr>
 <1455569868-25017-4-git-send-email-robert.jarzmik@free.fr>
Message-ID: <87d1rrxdrw.fsf@belgarion.home>

Robert Jarzmik <robert.jarzmik at free.fr> writes:

> The current number of requestor lines is limited to 31. This was an
> error of a previous commit, as this number is platform dependent, and is
> actually :
>  - for pxa25x: 40 requestor lines
>  - for pxa27x: 75 requestor lines
>  - for pxa3xx: 100 requestor lines
>
> The previous testing did not reveal the faulty constant as on pxa[23]xx
> platforms, only camera, MSL and USB are above requestor 32, and in these
> only the camera has a driver using dma.
>
> Fixes: e87ffbdf0697 ("dmaengine: pxa_dma: fix the no-requestor case")
> Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
> ---
> Since v1: change to #dma-requests the of property name
>       	  default to 32 requestors and warn as suggested by Vinod

Hi Vinod,

Are you happy with this version ?
If so could you provide me your Acked-by please ?

Cheers.

--
Robert


From manabian at gmail.com  Sat Feb 20 14:19:36 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Sat, 20 Feb 2016 23:19:36 +0100
Subject: [PATCH 0/2] arm: lpc32xx: restart: add support for soft reset
In-Reply-To: <002701d16b5b$f78c7b70$e6a57250$@gmail.com>
References: <002701d16b5b$f78c7b70$e6a57250$@gmail.com>
Message-ID: <CAGhQ9Vwr6H0YjRfaiBNaUrm8rHEVjh-NQbPZMdOZh2cJnMXmBA@mail.gmail.com>

On 19 February 2016 at 22:24, Sylvain Lemieux <slemieux.tyco at gmail.com> wrote:
> Hi Joachim,
>
>> From: Joachim Eastwood [mailto:manabian at gmail.com]
>> Sent: 18-Feb-16 5:08 PM
>> To: slemieux.tyco at gmail.com
>>
>> Hi Sylvain,
>>
>> On 18 February 2016 at 22:35,  <slemieux.tyco at gmail.com> wrote:
>> > From: Sylvain Lemieux <slemieux at tycoint.com>
>> >
>> > The LPC32xx provide the capability to perform a soft or hard reset;
>> > a soft reset will no reset the external peripheral
>> > (i.e. RESOUT_N output not asserted).
>> >
>> > The default behavior (i.e. hard reset) remain unchanged.
>> >
>> > Sylvain Lemieux (2):
>> >   arm: lpc32xx: restart: add support for soft reset
>> >   arm: lpc32xx: restart: support "cmd" from userspace
>> >
>> >  arch/arm/mach-lpc32xx/common.c | 26 +++++++++++++++++++++++---
>> >  1 file changed, 23 insertions(+), 3 deletions(-)
>>
>> Instead of adding more code to mach-lpc32xx could this code be moved
>> to the watchdog driver (pnx4008_wdt.c) ?
>> See register_restart_handler() and how it's used in other watchdog drivers.
>>
>> Then maybe the restart hook in phy3250.c could be removed all together.
>
> Thanks for the feedback;
>
> It is possible to remove the "lpc23xx_restart" function from "mach-lpc32xx"
> and add the functionality to the pnx4008 watchdog driver.
> The restart hook in phy3250.c can be remove.
>
> I will submit a new revision of the patch on Monday.
>
>>
> I need to add a new functionality to the pnx4008 driver to
> keep the driver disable and only provide the restart hook.

Why do you need to disable the driver?
The watchdog is not enabled unless you don't explicitly do so, ie
opening it and starting it.


> I am planning to add the functionality using a module parameter;
> this is the way the pnx833x & s3c2410 driver are doing it.

You should normally try to avoid module parameters if you can.


> Do you have any feedback before a submit a patch for this change.

Take a look at:
2165bf524da5f5e496d - "watchdog: core: add restart handler support"

Note that this will not give you the reboot_mode parameter. But maybe
that could be added to the restart-callback function.


regards,
Joachim Eastwood


From robert.jarzmik at free.fr  Sat Feb 20 14:24:02 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Sat, 20 Feb 2016 23:24:02 +0100
Subject: [PATCH 1/4] ASoC: wm9713: add binding for WM9713 codec
In-Reply-To: <20160220211659.GG18327@sirena.org.uk> (Mark Brown's message of
 "Sun, 21 Feb 2016 06:16:59 +0900")
References: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
 <20160220171459.GA18327@sirena.org.uk> <871t87z1gz.fsf@belgarion.home>
 <20160220195925.GF18327@sirena.org.uk> <87twl3xgud.fsf@belgarion.home>
 <20160220211659.GG18327@sirena.org.uk>
Message-ID: <878u2fxbp9.fsf@belgarion.home>

Mark Brown <broonie at kernel.org> writes:

> On Sat, Feb 20, 2016 at 09:32:58PM +0100, Robert Jarzmik wrote:
>> Mark Brown <broonie at kernel.org> writes:
>> > On Sat, Feb 20, 2016 at 07:22:04PM +0100, Robert Jarzmik wrote:
>> I will. By now I fail to see how this will help in the wm9713 probing and
>> detection ...
>
> It will eumerate the AC'97 bus by itself and does not need the CODEC to
> be described.
I think I still don't get it.

So let's rephrase it another way : how will the function wm9713_probe() be
called, ie. what is the possible function backtrace leading to that call ?

>> Until I make the try, here is what I have as a device-tree extract in [1],
>> which is my candidate for sound/soc/pxa/zylonite.c replacement.. If we
>> conclude that wm9713 shouldn't be in device-tree, then I'm curious how the
>> DAI bindings (simple-audio-card,dai-link*) should be handled.
>
> They should be created as a function of enumerating the CODEC.  If you
> use the genric AC'97 stuff it doesn't use ASoC at all and this happens
> as a side effect.
I don't get that either. For me sound/soc/pci/ac97/ac97_codec.c is PCI specific,
not generic, so what is "generic AC'97 stuff" ? I will never be able to use it
as on my platforms CONFIG_PCI=n.

Do you have a devicetree example somewhere, with (ac97 host, audio codec) pair I
can have a look at to understand ?

Cheers.

-- 
Robert


From heiko at sntech.de  Sat Feb 20 16:03:47 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Sun, 21 Feb 2016 01:03:47 +0100
Subject: [PATCH v5 1/8] ARM: dts: rockchip: add hdmi/vop device node for
 rk3036
In-Reply-To: <1454384453-7127-1-git-send-email-wxt@rock-chips.com>
References: <1454384032-6794-1-git-send-email-wxt@rock-chips.com>
 <1454384453-7127-1-git-send-email-wxt@rock-chips.com>
Message-ID: <6774166.XfKvalhQ7F@phil>

Am Dienstag, 2. Februar 2016, 11:40:50 schrieb Caesar Wang:
> This patch adds the needed display info for rk3036 SOCs.
> 
> The rk3036 support two overlay plane and one hwc plane,
> it supports IOMMU, and its IOMMU same as rk3288's.
> Meanwhile, add the inno hdmi for HDMI display.
> 
> Signed-off-by: Caesar Wang <wxt at rock-chips.com>

I've split this into 3 patches (vop, hdmi, kylin enablement) and applied 
this to my dts32 branch.


Heiko


From broonie at kernel.org  Sat Feb 20 16:38:59 2016
From: broonie at kernel.org (Mark Brown)
Date: Sun, 21 Feb 2016 09:38:59 +0900
Subject: [PATCH V6 1/2] regulator: Add document for MT6323 regulator
In-Reply-To: <1455709056-50510-1-git-send-email-blogic@openwrt.org>
References: <1455709056-50510-1-git-send-email-blogic@openwrt.org>
Message-ID: <20160221003859.GI18327@sirena.org.uk>

On Wed, Feb 17, 2016 at 12:37:35PM +0100, John Crispin wrote:
> Signed-off-by: John Crispin <blogic at openwrt.org>
> Cc: devicetree at vger.kernel.org

...and dropped due to the dependency on MFD changes that you didn't
mention :/  I can't apply this without a pull request from Lee with the
MFD changes for the chip that I can depend on, there's no separate
Kconfig symbol and the MFD is already merged causing build failures
(you've had mail from 0day about that).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160221/81493bbd/attachment.sig>

From broonie at kernel.org  Sat Feb 20 17:49:20 2016
From: broonie at kernel.org (Mark Brown)
Date: Sun, 21 Feb 2016 10:49:20 +0900
Subject: [PATCH 1/4] ASoC: wm9713: add binding for WM9713 codec
In-Reply-To: <878u2fxbp9.fsf@belgarion.home>
References: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
 <20160220171459.GA18327@sirena.org.uk>
 <871t87z1gz.fsf@belgarion.home>
 <20160220195925.GF18327@sirena.org.uk>
 <87twl3xgud.fsf@belgarion.home>
 <20160220211659.GG18327@sirena.org.uk>
 <878u2fxbp9.fsf@belgarion.home>
Message-ID: <20160221014920.GK18327@sirena.org.uk>

On Sat, Feb 20, 2016 at 11:24:02PM +0100, Robert Jarzmik wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> Mark Brown <broonie at kernel.org> writes:
> > On Sat, Feb 20, 2016 at 09:32:58PM +0100, Robert Jarzmik wrote:

> > It will eumerate the AC'97 bus by itself and does not need the CODEC to
> > be described.

> I think I still don't get it.

> So let's rephrase it another way : how will the function wm9713_probe() be
> called, ie. what is the possible function backtrace leading to that call ?

It will not be called, the generic AC'97 code will be used.

> > They should be created as a function of enumerating the CODEC.  If you
> > use the genric AC'97 stuff it doesn't use ASoC at all and this happens
> > as a side effect.

> I don't get that either. For me sound/soc/pci/ac97/ac97_codec.c is PCI specific,
> not generic, so what is "generic AC'97 stuff" ? I will never be able to use it
> as on my platforms CONFIG_PCI=n.

That is the generic code, there is no PCI dependency.

> Do you have a devicetree example somewhere, with (ac97 host, audio codec) pair I
> can have a look at to understand ?

Some Atmel boards do this IIRC, as does the AACI driver (via AMBA but
same effect).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160221/eebc1cc3/attachment.sig>

From draakje197 at gmail.com  Sat Feb 20 17:54:42 2016
From: draakje197 at gmail.com (hp197)
Date: Sun, 21 Feb 2016 02:54:42 +0100
Subject: [PATCH v2] Fix sun7i pin assignment for IRQ's
Message-ID: <1456019688-19116-1-git-send-email-henry@nitronetworks.nl>

After testing IRQ pins we found some bugs in the pinctrl declaration.

Signed-off-by: hp197 <henry at nitronetworks.nl>
---

Changes in v2:
    After some more testing we found irq on PI pins.
    they where on mux6 so this is included in my patch.

    Also included is a warning for PI17, this pin was not working
    on apritzel his bPI and he thinks it might be correlated to
    GIC and IRQ 29.
---
 drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c | 25 +++++++++++--------------
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
index cf1ce0c..0fe173e 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
@@ -344,25 +344,21 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE4 */
 		  SUNXI_FUNCTION(0x3, "spi2"),		/* CS0 */
-		  SUNXI_FUNCTION_IRQ(0x6, 12)),		/* EINT12 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 20),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE5 */
 		  SUNXI_FUNCTION(0x3, "spi2"),		/* CLK */
-		  SUNXI_FUNCTION_IRQ(0x6, 13)),		/* EINT13 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 21),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE6 */
 		  SUNXI_FUNCTION(0x3, "spi2"),		/* MOSI */
-		  SUNXI_FUNCTION_IRQ(0x6, 14)),		/* EINT14 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 22),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE7 */
 		  SUNXI_FUNCTION(0x3, "spi2"),		/* MISO */
-		  SUNXI_FUNCTION_IRQ(0x6, 15)),		/* EINT15 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 23),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
@@ -960,65 +956,66 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS0 */
 		  SUNXI_FUNCTION(0x3, "uart5"),		/* TX */
-		  SUNXI_FUNCTION_IRQ(0x5, 22)),		/* EINT22 */
+		  SUNXI_FUNCTION_IRQ(0x6, 22)),		/* EINT22 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 11),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CLK */
 		  SUNXI_FUNCTION(0x3, "uart5"),		/* RX */
-		  SUNXI_FUNCTION_IRQ(0x5, 23)),		/* EINT23 */
+		  SUNXI_FUNCTION_IRQ(0x6, 23)),		/* EINT23 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 12),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* MOSI */
 		  SUNXI_FUNCTION(0x3, "uart6"),		/* TX */
 		  SUNXI_FUNCTION(0x4, "clk_out_a"),	/* CLK_OUT_A */
-		  SUNXI_FUNCTION_IRQ(0x5, 24)),		/* EINT24 */
+		  SUNXI_FUNCTION_IRQ(0x6, 24)),		/* EINT24 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 13),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* MISO */
 		  SUNXI_FUNCTION(0x3, "uart6"),		/* RX */
 		  SUNXI_FUNCTION(0x4, "clk_out_b"),	/* CLK_OUT_B */
-		  SUNXI_FUNCTION_IRQ(0x5, 25)),		/* EINT25 */
+		  SUNXI_FUNCTION_IRQ(0x6, 25)),		/* EINT25 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 14),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS1 */
 		  SUNXI_FUNCTION(0x3, "ps2"),		/* SCK1 */
 		  SUNXI_FUNCTION(0x4, "timer4"),	/* TCLKIN0 */
-		  SUNXI_FUNCTION_IRQ(0x5, 26)),		/* EINT26 */
+		  SUNXI_FUNCTION_IRQ(0x6, 26)),		/* EINT26 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 15),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS1 */
 		  SUNXI_FUNCTION(0x3, "ps2"),		/* SDA1 */
 		  SUNXI_FUNCTION(0x4, "timer5"),	/* TCLKIN1 */
-		  SUNXI_FUNCTION_IRQ(0x5, 27)),		/* EINT27 */
+		  SUNXI_FUNCTION_IRQ(0x6, 27)),		/* EINT27 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 16),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS0 */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* RTS */
-		  SUNXI_FUNCTION_IRQ(0x5, 28)),		/* EINT28 */
+		  SUNXI_FUNCTION_IRQ(0x6, 28)),		/* EINT28 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 17),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CLK */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* CTS */
-		  SUNXI_FUNCTION_IRQ(0x5, 29)),		/* EINT29 */
+		  SUNXI_FUNCTION_IRQ(0x6, 29)),		/* EINT29 */
+		  /* EINT29 might not work - more testing needed */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 18),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* MOSI */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* TX */
-		  SUNXI_FUNCTION_IRQ(0x5, 30)),		/* EINT30 */
+		  SUNXI_FUNCTION_IRQ(0x6, 30)),		/* EINT30 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 19),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* MISO */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* RX */
-		  SUNXI_FUNCTION_IRQ(0x5, 31)),		/* EINT31 */
+		  SUNXI_FUNCTION_IRQ(0x6, 31)),		/* EINT31 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 20),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
-- 
2.5.0



From caesar.upstream at gmail.com  Sat Feb 20 18:18:41 2016
From: caesar.upstream at gmail.com (Caesar Wang)
Date: Sun, 21 Feb 2016 10:18:41 +0800
Subject: [PATCH v5 1/8] ARM: dts: rockchip: add hdmi/vop device node for
 rk3036
In-Reply-To: <6774166.XfKvalhQ7F@phil>
References: <1454384032-6794-1-git-send-email-wxt@rock-chips.com>
 <1454384453-7127-1-git-send-email-wxt@rock-chips.com>
 <6774166.XfKvalhQ7F@phil>
Message-ID: <56C91E81.2090803@gmail.com>



? 2016?02?21? 08:03, Heiko Stuebner ??:
> Am Dienstag, 2. Februar 2016, 11:40:50 schrieb Caesar Wang:
>> This patch adds the needed display info for rk3036 SOCs.
>>
>> The rk3036 support two overlay plane and one hwc plane,
>> it supports IOMMU, and its IOMMU same as rk3288's.
>> Meanwhile, add the inno hdmi for HDMI display.
>>
>> Signed-off-by: Caesar Wang <wxt at rock-chips.com>
> I've split this into 3 patches (vop, hdmi, kylin enablement) and applied
> this to my dts32 branch.

That's great, thanks.


>
> Heiko
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip


-- 
Thanks,
Caesar



From paul at pwsan.com  Sat Feb 20 20:46:29 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Sun, 21 Feb 2016 04:46:29 +0000 (UTC)
Subject: OMAP baseline test results for v4.5-rc5
Message-ID: <alpine.DEB.2.02.1602210445470.3418@utopia.booyaka.com>


Here are some basic OMAP test results for Linux v4.5-rc5.
Logs and other details at:

    http://www.pwsan.com/omap/testlogs/test_v4.5-rc5/20160220201503/


Test summary
------------

Build: uImage:
    Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only,
		  omap1_defconfig_5912osk_only

Build: uImage+dtb:
    Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone,
		  omap2plus_defconfig/omap4-panda,
		  omap2plus_defconfig/omap4-panda-es,
		  omap2plus_defconfig/omap4-var-stk-om44,
		  omap2plus_defconfig/omap3-evm-37xx,
		  omap2plus_defconfig_n800_only_a/omap2420-n800,
		  omap2plus_defconfig/omap2430-sdp,
		  omap2plus_defconfig/am3517-evm,
		  omap2plus_defconfig/omap3-beagle,
		  omap2plus_defconfig/omap3-beagle-xm,
		  omap2plus_defconfig/omap3-sbc-t3517,
		  omap2plus_defconfig/omap5-uevm,
		  omap2plus_defconfig/omap5-sbc-t54

Build: zImage:
    Pass (18/18): omap2plus_defconfig, omap2plus_defconfig_am33xx_only,
		  omap2plus_defconfig_n800_only_a,
		  omap2plus_defconfig_n800_multi_omap2xxx,
		  omap2plus_defconfig_2430sdp_only,
		  omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
		  omap2plus_defconfig_omap2_4_only,
		  omap2plus_defconfig_omap3_4_only,
		  omap2plus_defconfig_omap5_only,
		  omap2plus_defconfig_dra7xx_only,
		  omap2plus_defconfig_am43xx_only,
		  omap2plus_defconfig_ti81xx_only,
		  rmk_omap3430_ldp_oldconfig,
		  rmk_omap3430_ldp_allnoconfig,
		  rmk_omap4430_sdp_oldconfig,
		  rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig

Build warnings from toolchain: uImage:
    (none)

Build warnings from toolchain: uImage+dtb:
    (none)

Build warnings from toolchain: zImage:
    FAIL ( 1/18): multi_v7_defconfig

Boot to userspace:
    FAIL ( 1/18): 2430sdp
    skip ( 3/18): 5912osk, 3517evm, 5430es2sbct54
    Pass (14/18): am335xbonelt, am437xsk, am335xbone, 4430es2panda,
		  4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle,
		  3530es31beagle, 3730beaglexm, 3730es12beaglexm,
		  cmt3517, 5430es2uevm, 2420n800

Kernel warnings during boot to userspace:
    FAIL ( 1/18): cmt3517

PM: chip retention via suspend:
    FAIL ( 7/11): am335xbonelt, 4430es2panda, 4460pandaes,
		  4460varsomom, 37xxevm, 2430sdp, 5430es2uevm
    Pass ( 4/11): 3530es3beagle, 3530es31beagle, 3730beaglexm,
		  3730es12beaglexm

PM: chip retention via dynamic idle:
    FAIL ( 9/11): am335xbonelt, 4430es2panda, 4460pandaes,
		  4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle,
		  2430sdp, 5430es2uevm
    Pass ( 2/11): 3730beaglexm, 3730es12beaglexm

PM: chip off (except CORE, due to errata) via suspend:
    Pass ( 1/ 1): 3730beaglexm

PM: chip off (except CORE, due to errata) via dynamic idle:
    Pass ( 1/ 1): 3730beaglexm

PM: chip off via suspend:
    FAIL ( 2/ 4): 37xxevm, 3530es3beagle
    Pass ( 2/ 4): 3530es31beagle, 3730es12beaglexm

PM: chip off via dynamic idle:
    FAIL ( 3/ 4): 37xxevm, 3530es3beagle, 3530es31beagle
    Pass ( 1/ 4): 3730es12beaglexm

Kernel warnings during PM test:
    (none)

Obsolete Kconfig symbols:
    FAIL ( 3/21): omap1_defconfig, omap2plus_defconfig,
		  multi_v7_defconfig


vmlinux object size
(delta in bytes from test_v4.5-rc4 (18558cae0272f8fd9647e69d3fec1565a7949865)):
   text     data      bss    total  kernel
   +896      +64        0     +960  omap1_defconfig
   +896      +64        0     +960  omap1_defconfig_1510innovator_only
   +888      +96        0     +984  omap1_defconfig_5912osk_only
  +1588     +256        0    +1844  multi_v7_defconfig
 +38696     +224        0   +38920  omap2plus_defconfig
  +1100     +192        0    +1292  omap2plus_defconfig_2430sdp_only
 +38632     +224        0   +38856  omap2plus_defconfig_am33xx_only
 +38696     +224        0   +38920  omap2plus_defconfig_am43xx_only
 +38696     +224        0   +38920  omap2plus_defconfig_cpupm
 +38632     +224        0   +38856  omap2plus_defconfig_dra7xx_only
   +988     +160        0    +1148  omap2plus_defconfig_n800_multi_omap2xxx
   +860     +160        0    +1020  omap2plus_defconfig_n800_only_a
 +35952     +224        0   +36176  omap2plus_defconfig_no_pm
 +38632     +192        0   +38824  omap2plus_defconfig_omap2_4_only
 +42728     +192        0   +42920  omap2plus_defconfig_omap3_4_only
 +38632     +192        0   +38824  omap2plus_defconfig_omap5_only
 +38440     +224        0   +38664  omap2plus_defconfig_ti81xx_only
   +464      +64      -92     +436  rmk_omap3430_ldp_allnoconfig
   +740     +160        0     +900  rmk_omap3430_ldp_oldconfig
   +448      +64     -108     +404  rmk_omap4430_sdp_allnoconfig
   +764     +136        0     +900  rmk_omap4430_sdp_oldconfig

Boot-time memory difference
(delta in bytes from test_v4.5-rc4 (18558cae0272f8fd9647e69d3fec1565a7949865))
  avail  rsrvd   high  freed  board          kconfig
  (no differences)



From wens at csie.org  Sun Feb 21 00:14:53 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Sun, 21 Feb 2016 00:14:53 -0800
Subject: [PATCH v2] Fix sun7i pin assignment for IRQ's
In-Reply-To: <1456019688-19116-1-git-send-email-henry@nitronetworks.nl>
References: <1456019688-19116-1-git-send-email-henry@nitronetworks.nl>
Message-ID: <CAGb2v64=DRPRzU5WFYRxEC=_fjz6YFRsEFEe4JrF=NBOVQ4Vjw@mail.gmail.com>

On Sun, Feb 21, 2016 at 9:54 AM, hp197 <draakje197 at gmail.com> wrote:
> After testing IRQ pins we found some bugs in the pinctrl declaration.
>
> Signed-off-by: hp197 <henry at nitronetworks.nl>

Please resend with your full name on the commit and the SoB.
The patch itself looks good.

ChenYu


From yu.c.chen at intel.com  Sun Feb 21 01:04:39 2016
From: yu.c.chen at intel.com (Chen, Yu C)
Date: Sun, 21 Feb 2016 09:04:39 +0000
Subject: [PATCH v5 15/15] arm64: hibernate: Prevent resume from a
 different kernel version
In-Reply-To: <20160220195702.GA22120@amd>
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
 <1455637767-31561-16-git-send-email-james.morse@arm.com>
 <20160216201557.GA6526@amd>
 <36DF59CE26D8EE47B0655C516E9CE640286C4F3C@shsmsx102.ccr.corp.intel.com>
 <56C5B240.40400@arm.com>
 <36DF59CE26D8EE47B0655C516E9CE640286C628C@shsmsx102.ccr.corp.intel.com>
 <20160220195702.GA22120@amd>
Message-ID: <36DF59CE26D8EE47B0655C516E9CE640286C632E@shsmsx102.ccr.corp.intel.com>

> -----Original Message-----
> From: Pavel Machek [mailto:pavel at ucw.cz]
> Sent: Sunday, February 21, 2016 3:57 AM
> To: Chen, Yu C
> Cc: James Morse; linux-arm-kernel at lists.infradead.org; Will Deacon; Sudeep
> Holla; Geoff Levand; Catalin Marinas; Lorenzo Pieralisi; Mark Rutland; AKASHI
> Takahiro; Marc Zyngier; Rafael J . Wysocki; linux-pm at vger.kernel.org
> Subject: Re: [PATCH v5 15/15] arm64: hibernate: Prevent resume from a
> different kernel version
> 
> On Sat 2016-02-20 19:16:59, Chen, Yu C wrote:
> >
> > > -----Original Message-----
> > > From: James Morse [mailto:james.morse at arm.com]
> > > Sent: Thursday, February 18, 2016 8:00 PM
> > > To: Chen, Yu C
> > > Cc: Pavel Machek; linux-arm-kernel at lists.infradead.org; Will Deacon;
> > > Sudeep Holla; Geoff Levand; Catalin Marinas; Lorenzo Pieralisi; Mark
> > > Rutland; AKASHI Takahiro; Marc Zyngier; Rafael J . Wysocki;
> > > linux-pm at vger.kernel.org
> > > Subject: Re: [PATCH v5 15/15] arm64: hibernate: Prevent resume from
> > > a different kernel version
> > >
> > > On 17/02/16 02:20, Chen, Yu C wrote:
> > > >> On Tue 2016-02-16 15:49:27, James Morse wrote:
> > > > This reminds me a similar problem I once encountered on x86 : - )
> > > > The efi memory layout should be strictly the same before/after
> > > > hibernation,
> > > right?
> > >
> > > The kernel hopes it is the same, as the page-tables it uses for
> > > runtime services calls are restored along with the rest of memory,
> > > but there is the risk that these don't match the EFI memory map any
> more.
> > >
> > > Even if the amount of memory is the same, the layout might be different.
> > > (Core hibernate code already has a counter of the number of physical
> > > pages.)
> > I've encountered this situation before.
> > >
> > > I'm still digging through the efi code (and spec), but it is fairly
> > > easy to cause the memory map to change before entry to linux. This
> > > doesn't seem to be a problem, as linux happily overwrites most of
> > > the allocated areas, so it may not be as fragile as I thought.
> > If I did some peripherals plug/unplug after suspend to hibernation,
> > then the next time it boots up there would likely be a slightly different efi
> memory map.
> > The efi provides a callback of get_memory_map to Linux for retrieving
> > the initial map, which depends on the bios/bootloader
> > probing/enumeration IMO. The difference of efi map might lead to kernel
> panic during resume sometimes.
> 
> md5hash of the efi map, and complain to bios vendors if it happens?
> Because iirc it is not supposed to.
Yes, it should not happen, at least for ACPI S4,
however after communicating with some people from bios team, it is said
BIOSen  are designed to  dynamically allocate address space for
resources.  Maybe we can register a panic notifier to check the consistence
of efi map md5hash.



From hs at denx.de  Sun Feb 21 01:27:49 2016
From: hs at denx.de (Heiko Schocher)
Date: Sun, 21 Feb 2016 10:27:49 +0100
Subject: [PATCH] Revert "regulator: tps65217: remove tps65217.dtsi file"
In-Reply-To: <20160219170404.GH21202@atomide.com>
References: <1455891139-6139-1-git-send-email-peter.ujfalusi@ti.com>
 <20160219170404.GH21202@atomide.com>
Message-ID: <56C98315.1000707@denx.de>

Hello Tony, Peter,

Am 19.02.2016 um 18:04 schrieb Tony Lindgren:
> * Peter Ujfalusi <peter.ujfalusi at ti.com> [160219 06:14]:
>> This reverts commit 8e6ebfaa9b384088002baa10f7534efa73a0794e.
>>
>> Without the patch reverted regulators will not work. This prevents
>> MMC to be working for example so the boards can not boot to
>> MMC rootfs.
>>
>> Tested it on beaglebone white and bisect also points to the
>> reverted commit.
>> The issue can be also fixed by adding "regulator-compatible =" to all board
>> dts file for the regulators.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
>> ---
>> Hi,
>>
>> I have noticed that bbw did not find the MMC with linux-next, but it turns out
>> that even 4.5-rc4 is behaving the same way.
>> I have run bisect and with this revert patch I can boot up fine.
>> To be honest I don't know why the tps65217.dtsi has been deleted in the first
>> place.
>
> I think initially the only real issue was the naming. The
> tps65217.dtsi file should be just renamed to tps65217-am335x.dtsi
> to make it clear that this configuration is commonly used for
> most am335x boards.
>
> I'll apply this revert into omap-for-v4.5/fixes as it fixes a
> regression.

Sorry for breaking ... but I have no bbw hw for testing ...
(This is maybe a reason for having something like an automated
  testsystem, see an example/proposal here:

https://github.com/hsdenx/tbot

see a demo for automated tests (running on a raspberry pi at my home
in hungary, boards are in munich/germany)
http://xeidos.ddns.net/buildbot/tgrid
)

But I removed this file as Mark Brown suggested it, see:

https://lkml.org/lkml/2015/10/21/581

So please introduce a "tps65217-am335x.dtsi" file ... Mark?

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


From ynorov at caviumnetworks.com  Sun Feb 21 01:42:20 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Sun, 21 Feb 2016 12:42:20 +0300
Subject: [PATCH v3 2/5] ACPI: parse SPCR and enable matching console
In-Reply-To: <1455559532-8305-3-git-send-email-aleksey.makarov@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-3-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <20160221094220.GA3181@yury-N73SV>

On Mon, Feb 15, 2016 at 09:05:26PM +0300, Aleksey Makarov wrote:
> 'ARM Server Base Boot Requiremets' [1] mentions SPCR (Serial Port
> Console Redirection Table) [2] as a mandatory ACPI table that
> specifies the configuration of serial console.
> 
> Parse this table and check if any registered console match the
> description.  If it does, enable that console.
> 
> Introduce a new function acpi_console_check().  At the uart port
> registration, this function checks if the ACPI SPCR table specifies
> its argument of type struct uart_port to be a console
> and if so calls add_preferred_console().
> 
> [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
> [2] http://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
> 
> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> ---
>  drivers/acpi/Kconfig             |  3 ++
>  drivers/acpi/Makefile            |  1 +
>  drivers/acpi/spcr.c              | 97 ++++++++++++++++++++++++++++++++++++++++
>  drivers/tty/serial/serial_core.c | 14 +++++-
>  include/linux/acpi.h             | 10 +++++
>  5 files changed, 123 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/acpi/spcr.c
> 
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 65fb483..5611eb6 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -77,6 +77,9 @@ config ACPI_DEBUGGER_USER
>  
>  endif
>  
> +config ACPI_SPCR_TABLE
> +	bool
> +
>  config ACPI_SLEEP
>  	bool
>  	depends on SUSPEND || HIBERNATION
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 346101c..708b143 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -81,6 +81,7 @@ obj-$(CONFIG_ACPI_EC_DEBUGFS)	+= ec_sys.o
>  obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
>  obj-$(CONFIG_ACPI_BGRT)		+= bgrt.o
>  obj-$(CONFIG_ACPI_CPPC_LIB)	+= cppc_acpi.o
> +obj-$(CONFIG_ACPI_SPCR_TABLE)	+= spcr.o
>  obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
>  
>  # processor has its own "processor." module_param namespace
> diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
> new file mode 100644
> index 0000000..a1eca91
> --- /dev/null
> +++ b/drivers/acpi/spcr.c
> @@ -0,0 +1,97 @@
> +/*
> + * Copyright (c) 2012, Intel Corporation
> + * Copyright (c) 2015, Red Hat, Inc.
> + * Copyright (c) 2015, 2016 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#define pr_fmt(fmt) "ACPI: SPCR: " fmt
> +
> +#include <linux/acpi.h>
> +#include <linux/console.h>
> +#include <linux/kernel.h>
> +#include <linux/serial_core.h>
> +
> +static int acpi_table_parse_spcr(int (*handler)(struct acpi_table_spcr *table,
> +						void *data), void *data)
> +{
> +	struct acpi_table_spcr *table = NULL;
Hi Alexey,

Few minor comments...

Are you sure you need thin initialization?

> +	acpi_size table_size;
> +	acpi_status status;
> +	int err;
> +
> +	status = acpi_get_table_with_size(ACPI_SIG_SPCR, 0,
> +					  (struct acpi_table_header **)&table,
> +					  &table_size);
> +
> +	if (ACPI_FAILURE(status))
> +		return -ENODEV;
> +
> +	err = handler(table, data);
> +
> +	early_acpi_os_unmap_memory(table, table_size);
> +
> +	return err;
> +}
> +
> +static int spcr_table_handler_check(struct acpi_table_spcr *table, void *data)

The name of function is not clear for me.
You're not only checking here, but also
adding console. 

> +{
> +	struct uart_port *uport = data;
> +	char *options;
> +
> +	if (table->header.revision < 2)
> +		return -EOPNOTSUPP;
> +
> +	switch (table->baud_rate) {

You don't need 'options' if your big condition returns false,
so you can evaluate it inside conditional block.

> +	case 3:
> +		options = "9600";
> +		break;
> +	case 4:
> +		options = "19200";
> +		break;
> +	case 6:
> +		options = "57600";
> +		break;
> +	case 7:
> +		options = "115200";
> +		break;
> +	default:
> +		options = "";
> +		break;

'break' isnot needed here

> +	}
> +
> +	if ((table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY &&

Nitpick: just for better readability, I'd split it onto a set of
separated checks:

        foo() {
                if (!cond1)
                        return 0;

                if (!cond2)
                        return 0;
                ...

                switch () {
                case 1:
                        ...
                case 2:
                        ...
                case 3:
                        ...
                default:
                        ...
                }
                
                return 1;
        }

> +	     table->serial_port.address == (u64)uport->mapbase) ||
> +	    (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_IO &&
> +	     table->serial_port.address == (u64)uport->iobase)) {
> +		pr_info("adding preferred console [%s%d]\n", uport->cons->name,
> +			uport->line);
> +		add_preferred_console(uport->cons->name, uport->line, options);
> +		return 1;
> +
> +	}
> +
> +	return 0;
> +}
> +
> +/**
> + * acpi_console_check - Check if uart matches the console specified by SPCR.
> + *
> + * @uport:	uart port to check
> + *
> + * This function checks if the ACPI SPCR table specifies @uport to be a console
> + * and if so calls add_preferred_console()
> + *
> + * Return: a non-error value if the console matches.
> + */
> +bool acpi_console_check(struct uart_port *uport)
> +{
> +	if (acpi_disabled || console_set_on_cmdline)
> +		return false;
> +
> +	return acpi_table_parse_spcr(spcr_table_handler_check, uport) > 0;
> +}
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index a126a60..459ab54 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -34,6 +34,7 @@
>  #include <linux/serial_core.h>
>  #include <linux/delay.h>
>  #include <linux/mutex.h>
> +#include <linux/acpi.h>
>  
>  #include <asm/irq.h>
>  #include <asm/uaccess.h>
> @@ -2654,8 +2655,17 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
>  		spin_lock_init(&uport->lock);
>  		lockdep_set_class(&uport->lock, &port_lock_key);
>  	}
> -	if (uport->cons && uport->dev)
> -		of_console_check(uport->dev->of_node, uport->cons->name, uport->line);
> +
> +	/*
> +	 * Support both open FW and ACPI access to console definitions.
> +	 * Both of_console_check() and acpi_console_check() will call
> +	 * add_preferred_console() if a console definition is found.
> +	 */
> +	if (uport->cons && uport->dev) {
> +		if (!acpi_console_check(uport))
> +			of_console_check(uport->dev->of_node, uport->cons->name,
> +					 uport->line);
> +	}
>  
>  	uart_configure_port(drv, state, uport);
>  
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 06ed7e5..ea0c297 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -1004,4 +1004,14 @@ static inline struct fwnode_handle *acpi_get_next_subnode(struct device *dev,
>  #define acpi_probe_device_table(t)	({ int __r = 0; __r;})
>  #endif
>  
> +struct uart_port;
> +#ifdef CONFIG_ACPI_SPCR_TABLE
> +bool acpi_console_check(struct uart_port *uport);
> +#else
> +static inline bool acpi_console_check(struct uart_port *uport)
> +{
> +	return FALSE;
> +}
> +#endif
> +
>  #endif	/*_LINUX_ACPI_H*/
> -- 
> 2.7.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From gregory.clement at free-electrons.com  Sun Feb 21 02:09:17 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Sun, 21 Feb 2016 11:09:17 +0100
Subject: [GIT PULL] ARM: mvebu: fixes for v4.5 (#2)
In-Reply-To: <874mdfxkjx.fsf@free-electrons.com> (Gregory CLEMENT's message of
 "Thu, 11 Feb 2016 17:45:38 +0100")
References: <874mdfxkjx.fsf@free-electrons.com>
Message-ID: <874md2pe7m.fsf@free-electrons.com>

Hi,
 
 On jeu., f?vr. 11 2016, Gregory CLEMENT <gregory.clement at free-electrons.com> wrote:

> Hi,
>
> Here is the second pull request for fixes for mvebu for v4.5.
>

I didn't see these 2 commits in v4.5-rc4 or v4.5-rc5. So I wanted to
check that you didn't miss this PR.

Thanks,

Gregory


>
> The following changes since commit ff61ee84e7aa5842d9e33c0b442f0b43a6a44eaf:
>
>   ARM: dts: orion5x: gpio pin fixes for linkstation lswtgl (2016-01-25 16:22:59 +0100)
>
> are available in the git repository at:
>
>   git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-4.5-2
>
> for you to fetch changes up to 44361a2cc13493fc41216d33bb9a562ec3a9cc4e:
>
>   ARM: dts: orion5x: fix the missing mtd flash on linkstation lswtgl (2016-02-09 11:17:53 +0100)
>
> ----------------------------------------------------------------
> mvebu fixes for 4.5 (part 2)
>
> - Fix the missing mtd flash on linkstation lswtgl
> - Use unique machine name for the kirkwood ds112 (for Debian flash-kernel tool)
>
> ----------------------------------------------------------------
> Heinrich Schuchardt (1):
>       ARM: dts: kirkwood: use unique machine name for ds112
>
> Roger Shimizu (1):
>       ARM: dts: orion5x: fix the missing mtd flash on linkstation lswtgl
>
>  arch/arm/boot/dts/kirkwood-ds112.dts             |  2 +-
>  arch/arm/boot/dts/orion5x-linkstation-lswtgl.dts | 31 ++++++++++++++++++++++++
>  2 files changed, 32 insertions(+), 1 deletion(-)
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From codekipper at gmail.com  Sun Feb 21 03:13:36 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Sun, 21 Feb 2016 12:13:36 +0100
Subject: [PATCH v7 0/2] ASoC: Add SPDIF support for Allwinner SoCs
Message-ID: <1456053218-16325-1-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

For now just the SPDIF transmitter has been tested on a Mele A2000(A10)
and a Itead Ibox(A20).

In order for this patch set to be functional we require an audio clock patch
which will be delivered separately. For those that are interested I've pushed
the patches here with all the required changes to get SPDIF audio out of the
device.

https://github.com/codekipper/linux-sunxi/commits/spdif_delivery

Thanks in advance,
CK

---
Changes since v6:
- removed legacy dapm components that are no longer needed.
- changed dt-bindings patch subject styling to match that of the sound subsystem

Changes since v5:
- fixed warning that had sneaked in.

Changes since v4:
- corrected indentation issues
- removed old macros
- removed unnecessary enabling of apb clock

Changes since v3:
- removed code required for spdif capture
- added disable/enable of apb clk to suspend/resume.
- removed unnecessary dt checks in probe
- fixed error conditions in probe/resume
- modified pm_runtime functionality and confirmed that driver worked when PM was disabled.
- removed .owner from platform driver
- renamed bindings file

Changes since v2:
- removed sunxi-machine-spdif and replaced with simple audio card
- removed untested compatibilities from device tree documentation
- added pm_runtime and remove shutdown
- removed pll2 as it's the parent of the spdif clock
- rename clk to spdif_clk
- removed enabling of mclk output
- removed interrupts status being cleared as it's not being used
- use default fifo settings for now
- fixed alignments for wrapped lines

Changes since v1:
- Moved sunxi-machine-spdif.c to separate patch
- replaced sunxi in naming scheme with sun4i in the sun4i-spdif driver.
- split tx controller into separate enable/disable functions
- moved setclk and setfmt functionality into hw params
- added support for mono signals.
- cleaned up probe clock set up.
- removed all writes to transmit status registers.
- removed of_id
- removed power management code.
- Added support for more rates.

Marcus Cooper (2):
  ASoC: sunxi :add sun4i SPDIF dt bindings
  ASoC: sunxi: Add support for the SPDIF block

 .../bindings/sound/sunxi,sun4i-spdif.txt           |  39 ++
 sound/soc/sunxi/Kconfig                            |   8 +
 sound/soc/sunxi/Makefile                           |   1 +
 sound/soc/sunxi/sun4i-spdif.c                      | 542 +++++++++++++++++++++
 4 files changed, 590 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
 create mode 100644 sound/soc/sunxi/sun4i-spdif.c

-- 
2.7.1



From codekipper at gmail.com  Sun Feb 21 03:13:37 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Sun, 21 Feb 2016 12:13:37 +0100
Subject: [PATCH v7 1/2] ASoC: sunxi :add sun4i SPDIF dt bindings
In-Reply-To: <1456053218-16325-1-git-send-email-codekipper@gmail.com>
References: <1456053218-16325-1-git-send-email-codekipper@gmail.com>
Message-ID: <1456053218-16325-2-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

Add devicetree bindings for the SPDIF transceiver found on
found on Allwinners A10 and A20 SoCs.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
 .../bindings/sound/sunxi,sun4i-spdif.txt           | 39 ++++++++++++++++++++++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt

diff --git a/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
new file mode 100644
index 0000000..13503aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
@@ -0,0 +1,39 @@
+Allwinner Sony/Philips Digital Interface Format (S/PDIF) Controller
+
+The Allwinner S/PDIF audio block is a transceiver that allows the
+processor to receive and transmit digital audio via an coaxial cable or
+a fibre cable.
+For now only playback is supported.
+
+Required properties:
+
+  - compatible		: should be one of the following:
+    - "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC
+
+  - reg			: Offset and length of the register set for the device.
+
+  - interrupts		: Contains the spdif interrupt.
+
+  - dmas		: Generic dma devicetree binding as described in
+			  Documentation/devicetree/bindings/dma/dma.txt.
+
+  - dma-names		: Two dmas have to be defined, "tx" and "rx".
+
+  - clocks		: Contains an entry for each entry in clock-names.
+
+  - clock-names		: Includes the following entries:
+	"apb"		  clock for the spdif bus.
+	"spdif"		  clock for spdif controller.
+
+Example:
+
+spdif: spdif at 01c21000 {
+	compatible = "allwinner,sun4i-a10-spdif";
+	reg = <0x01c21000 0x40>;
+	interrupts = <13>;
+	clocks = <&apb0_gates 1>, <&spdif_clk>;
+	clock-names = "apb", "spdif";
+	dmas = <&dma 0 2>, <&dma 0 2>;
+	dma-names = "rx", "tx";
+	status = "okay";
+};
-- 
2.7.1



From codekipper at gmail.com  Sun Feb 21 03:13:38 2016
From: codekipper at gmail.com (codekipper at gmail.com)
Date: Sun, 21 Feb 2016 12:13:38 +0100
Subject: [PATCH v7 2/2] ASoC: sunxi: Add support for the SPDIF block
In-Reply-To: <1456053218-16325-1-git-send-email-codekipper@gmail.com>
References: <1456053218-16325-1-git-send-email-codekipper@gmail.com>
Message-ID: <1456053218-16325-3-git-send-email-codekipper@gmail.com>

From: Marcus Cooper <codekipper at gmail.com>

The sun4i, sun5i and sun7i SoC families have an SPDIF
block which is capable of playback and capture.

This patch enables the playback of this block for
the sun4i families.

Signed-off-by: Marcus Cooper <codekipper at gmail.com>
---
 sound/soc/sunxi/Kconfig       |   8 +
 sound/soc/sunxi/Makefile      |   1 +
 sound/soc/sunxi/sun4i-spdif.c | 542 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 551 insertions(+)
 create mode 100644 sound/soc/sunxi/sun4i-spdif.c

diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
index 84c72ec..ae42294 100644
--- a/sound/soc/sunxi/Kconfig
+++ b/sound/soc/sunxi/Kconfig
@@ -8,4 +8,12 @@ config SND_SUN4I_CODEC
 	  Select Y or M to add support for the Codec embedded in the Allwinner
 	  A10 and affiliated SoCs.
 
+config SND_SUN4I_SPDIF
+	tristate "Allwinner A10 SPDIF Support"
+	depends on OF
+	select SND_SOC_GENERIC_DMAENGINE_PCM
+	select REGMAP_MMIO
+	help
+	  Say Y or M to add support for the S/PDIF audio block in the Allwinner
+	  A10 and affiliated SoCs.
 endmenu
diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
index ea8a08c..8f5e889 100644
--- a/sound/soc/sunxi/Makefile
+++ b/sound/soc/sunxi/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
 
+obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o
diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
new file mode 100644
index 0000000..baa2696
--- /dev/null
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -0,0 +1,542 @@
+/*
+ * ALSA SoC SPDIF Audio Layer
+ *
+ * Copyright 2015 Andrea Venturi <be17068 at iperbole.bo.it>
+ * Copyright 2015 Marcus Cooper <codekipper at gmail.com>
+ *
+ * Based on the Allwinner SDK driver, released under the GPL.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/regmap.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/ioport.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <sound/dmaengine_pcm.h>
+#include <sound/pcm_params.h>
+#include <sound/soc.h>
+
+#define	SUN4I_SPDIF_CTL		(0x00)
+	#define SUN4I_SPDIF_CTL_MCLKDIV(v)		((v) << 4) /* v even */
+	#define SUN4I_SPDIF_CTL_MCLKOUTEN		BIT(2)
+	#define SUN4I_SPDIF_CTL_GEN			BIT(1)
+	#define SUN4I_SPDIF_CTL_RESET			BIT(0)
+
+#define SUN4I_SPDIF_TXCFG	(0x04)
+	#define SUN4I_SPDIF_TXCFG_SINGLEMOD		BIT(31)
+	#define SUN4I_SPDIF_TXCFG_ASS			BIT(17)
+	#define SUN4I_SPDIF_TXCFG_NONAUDIO		BIT(16)
+	#define SUN4I_SPDIF_TXCFG_TXRATIO(v)		((v) << 4)
+	#define SUN4I_SPDIF_TXCFG_TXRATIO_MASK		GENMASK(8, 4)
+	#define SUN4I_SPDIF_TXCFG_FMTRVD		GENMASK(3, 2)
+	#define SUN4I_SPDIF_TXCFG_FMT16BIT		(0 << 2)
+	#define SUN4I_SPDIF_TXCFG_FMT20BIT		(1 << 2)
+	#define SUN4I_SPDIF_TXCFG_FMT24BIT		(2 << 2)
+	#define SUN4I_SPDIF_TXCFG_CHSTMODE		BIT(1)
+	#define SUN4I_SPDIF_TXCFG_TXEN			BIT(0)
+
+#define SUN4I_SPDIF_RXCFG	(0x08)
+	#define SUN4I_SPDIF_RXCFG_LOCKFLAG		BIT(4)
+	#define SUN4I_SPDIF_RXCFG_CHSTSRC		BIT(3)
+	#define SUN4I_SPDIF_RXCFG_CHSTCP		BIT(1)
+	#define SUN4I_SPDIF_RXCFG_RXEN			BIT(0)
+
+#define SUN4I_SPDIF_TXFIFO	(0x0C)
+
+#define SUN4I_SPDIF_RXFIFO	(0x10)
+
+#define SUN4I_SPDIF_FCTL	(0x14)
+	#define SUN4I_SPDIF_FCTL_FIFOSRC		BIT(31)
+	#define SUN4I_SPDIF_FCTL_FTX			BIT(17)
+	#define SUN4I_SPDIF_FCTL_FRX			BIT(16)
+	#define SUN4I_SPDIF_FCTL_TXTL(v)		((v) << 8)
+	#define SUN4I_SPDIF_FCTL_TXTL_MASK		GENMASK(12, 8)
+	#define SUN4I_SPDIF_FCTL_RXTL(v)		((v) << 3)
+	#define SUN4I_SPDIF_FCTL_RXTL_MASK		GENMASK(7, 3)
+	#define SUN4I_SPDIF_FCTL_TXIM			BIT(2)
+	#define SUN4I_SPDIF_FCTL_RXOM(v)		((v) << 0)
+	#define SUN4I_SPDIF_FCTL_RXOM_MASK		GENMASK(1, 0)
+
+#define SUN4I_SPDIF_FSTA	(0x18)
+	#define SUN4I_SPDIF_FSTA_TXE			BIT(14)
+	#define SUN4I_SPDIF_FSTA_TXECNTSHT		(8)
+	#define SUN4I_SPDIF_FSTA_RXA			BIT(6)
+	#define SUN4I_SPDIF_FSTA_RXACNTSHT		(0)
+
+#define SUN4I_SPDIF_INT		(0x1C)
+	#define SUN4I_SPDIF_INT_RXLOCKEN		BIT(18)
+	#define SUN4I_SPDIF_INT_RXUNLOCKEN		BIT(17)
+	#define SUN4I_SPDIF_INT_RXPARERREN		BIT(16)
+	#define SUN4I_SPDIF_INT_TXDRQEN			BIT(7)
+	#define SUN4I_SPDIF_INT_TXUIEN			BIT(6)
+	#define SUN4I_SPDIF_INT_TXOIEN			BIT(5)
+	#define SUN4I_SPDIF_INT_TXEIEN			BIT(4)
+	#define SUN4I_SPDIF_INT_RXDRQEN			BIT(2)
+	#define SUN4I_SPDIF_INT_RXOIEN			BIT(1)
+	#define SUN4I_SPDIF_INT_RXAIEN			BIT(0)
+
+#define SUN4I_SPDIF_ISTA	(0x20)
+	#define SUN4I_SPDIF_ISTA_RXLOCKSTA		BIT(18)
+	#define SUN4I_SPDIF_ISTA_RXUNLOCKSTA		BIT(17)
+	#define SUN4I_SPDIF_ISTA_RXPARERRSTA		BIT(16)
+	#define SUN4I_SPDIF_ISTA_TXUSTA			BIT(6)
+	#define SUN4I_SPDIF_ISTA_TXOSTA			BIT(5)
+	#define SUN4I_SPDIF_ISTA_TXESTA			BIT(4)
+	#define SUN4I_SPDIF_ISTA_RXOSTA			BIT(1)
+	#define SUN4I_SPDIF_ISTA_RXASTA			BIT(0)
+
+#define SUN4I_SPDIF_TXCNT	(0x24)
+
+#define SUN4I_SPDIF_RXCNT	(0x28)
+
+#define SUN4I_SPDIF_TXCHSTA0	(0x2C)
+	#define SUN4I_SPDIF_TXCHSTA0_CLK(v)		((v) << 28)
+	#define SUN4I_SPDIF_TXCHSTA0_SAMFREQ(v)		((v) << 24)
+	#define SUN4I_SPDIF_TXCHSTA0_SAMFREQ_MASK	GENMASK(27, 24)
+	#define SUN4I_SPDIF_TXCHSTA0_CHNUM(v)		((v) << 20)
+	#define SUN4I_SPDIF_TXCHSTA0_CHNUM_MASK		GENMASK(23, 20)
+	#define SUN4I_SPDIF_TXCHSTA0_SRCNUM(v)		((v) << 16)
+	#define SUN4I_SPDIF_TXCHSTA0_CATACOD(v)		((v) << 8)
+	#define SUN4I_SPDIF_TXCHSTA0_MODE(v)		((v) << 6)
+	#define SUN4I_SPDIF_TXCHSTA0_EMPHASIS(v)	((v) << 3)
+	#define SUN4I_SPDIF_TXCHSTA0_CP			BIT(2)
+	#define SUN4I_SPDIF_TXCHSTA0_AUDIO		BIT(1)
+	#define SUN4I_SPDIF_TXCHSTA0_PRO		BIT(0)
+
+#define SUN4I_SPDIF_TXCHSTA1	(0x30)
+	#define SUN4I_SPDIF_TXCHSTA1_CGMSA(v)		((v) << 8)
+	#define SUN4I_SPDIF_TXCHSTA1_ORISAMFREQ(v)	((v) << 4)
+	#define SUN4I_SPDIF_TXCHSTA1_ORISAMFREQ_MASK	GENMASK(7, 4)
+	#define SUN4I_SPDIF_TXCHSTA1_SAMWORDLEN(v)	((v) << 1)
+	#define SUN4I_SPDIF_TXCHSTA1_MAXWORDLEN		BIT(0)
+
+#define SUN4I_SPDIF_RXCHSTA0	(0x34)
+	#define SUN4I_SPDIF_RXCHSTA0_CLK(v)		((v) << 28)
+	#define SUN4I_SPDIF_RXCHSTA0_SAMFREQ(v)		((v) << 24)
+	#define SUN4I_SPDIF_RXCHSTA0_CHNUM(v)		((v) << 20)
+	#define SUN4I_SPDIF_RXCHSTA0_SRCNUM(v)		((v) << 16)
+	#define SUN4I_SPDIF_RXCHSTA0_CATACOD(v)		((v) << 8)
+	#define SUN4I_SPDIF_RXCHSTA0_MODE(v)		((v) << 6)
+	#define SUN4I_SPDIF_RXCHSTA0_EMPHASIS(v)	((v) << 3)
+	#define SUN4I_SPDIF_RXCHSTA0_CP			BIT(2)
+	#define SUN4I_SPDIF_RXCHSTA0_AUDIO		BIT(1)
+	#define SUN4I_SPDIF_RXCHSTA0_PRO		BIT(0)
+
+#define SUN4I_SPDIF_RXCHSTA1	(0x38)
+	#define SUN4I_SPDIF_RXCHSTA1_CGMSA(v)		((v) << 8)
+	#define SUN4I_SPDIF_RXCHSTA1_ORISAMFREQ(v)	((v) << 4)
+	#define SUN4I_SPDIF_RXCHSTA1_SAMWORDLEN(v)	((v) << 1)
+	#define SUN4I_SPDIF_RXCHSTA1_MAXWORDLEN		BIT(0)
+
+/* Defines for Sampling Frequency */
+#define SUN4I_SPDIF_SAMFREQ_44_1KHZ		0x0
+#define SUN4I_SPDIF_SAMFREQ_NOT_INDICATED	0x1
+#define SUN4I_SPDIF_SAMFREQ_48KHZ		0x2
+#define SUN4I_SPDIF_SAMFREQ_32KHZ		0x3
+#define SUN4I_SPDIF_SAMFREQ_22_05KHZ		0x4
+#define SUN4I_SPDIF_SAMFREQ_24KHZ		0x6
+#define SUN4I_SPDIF_SAMFREQ_88_2KHZ		0x8
+#define SUN4I_SPDIF_SAMFREQ_76_8KHZ		0x9
+#define SUN4I_SPDIF_SAMFREQ_96KHZ		0xa
+#define SUN4I_SPDIF_SAMFREQ_176_4KHZ		0xc
+#define SUN4I_SPDIF_SAMFREQ_192KHZ		0xe
+
+struct sun4i_spdif_dev {
+	struct platform_device *pdev;
+	struct clk *spdif_clk;
+	struct clk *apb_clk;
+	struct snd_soc_dai_driver cpu_dai_drv;
+	struct regmap *regmap;
+	struct snd_dmaengine_dai_dma_data dma_params_tx;
+};
+
+static void sun4i_spdif_configure(struct sun4i_spdif_dev *host)
+{
+	/* soft reset SPDIF */
+	regmap_write(host->regmap, SUN4I_SPDIF_CTL, SUN4I_SPDIF_CTL_RESET);
+
+	/* flush TX FIFO */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_FCTL,
+			   SUN4I_SPDIF_FCTL_FTX, SUN4I_SPDIF_FCTL_FTX);
+
+	/* clear TX counter */
+	regmap_write(host->regmap, SUN4I_SPDIF_TXCNT, 0);
+}
+
+static void sun4i_snd_txctrl_on(struct snd_pcm_substream *substream,
+				struct sun4i_spdif_dev *host)
+{
+	if (substream->runtime->channels == 1)
+		regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+				   SUN4I_SPDIF_TXCFG_SINGLEMOD,
+				   SUN4I_SPDIF_TXCFG_SINGLEMOD);
+
+	/* SPDIF TX ENABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+			   SUN4I_SPDIF_TXCFG_TXEN, SUN4I_SPDIF_TXCFG_TXEN);
+
+	/* DRQ ENABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_INT,
+			   SUN4I_SPDIF_INT_TXDRQEN, SUN4I_SPDIF_INT_TXDRQEN);
+
+	/* Global enable */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_CTL,
+			   SUN4I_SPDIF_CTL_GEN, SUN4I_SPDIF_CTL_GEN);
+}
+
+static void sun4i_snd_txctrl_off(struct snd_pcm_substream *substream,
+				 struct sun4i_spdif_dev *host)
+{
+	/* SPDIF TX DISABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_TXCFG,
+			   SUN4I_SPDIF_TXCFG_TXEN, 0);
+
+	/* DRQ DISABLE */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_INT,
+			   SUN4I_SPDIF_INT_TXDRQEN, 0);
+
+	/* Global disable */
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_CTL,
+			   SUN4I_SPDIF_CTL_GEN, 0);
+}
+
+static int sun4i_spdif_startup(struct snd_pcm_substream *substream,
+			       struct snd_soc_dai *cpu_dai)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(rtd->cpu_dai);
+
+	if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK)
+		return -EINVAL;
+
+	sun4i_spdif_configure(host);
+
+	return 0;
+}
+
+static int sun4i_spdif_hw_params(struct snd_pcm_substream *substream,
+				 struct snd_pcm_hw_params *params,
+				 struct snd_soc_dai *cpu_dai)
+{
+	int ret = 0;
+	int fmt;
+	unsigned long rate = params_rate(params);
+	u32 mclk_div = 0;
+	unsigned int mclk = 0;
+	u32 reg_val;
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
+	struct platform_device *pdev = host->pdev;
+
+	/* Add the PCM and raw data select interface */
+	switch (params_channels(params)) {
+	case 1: /* PCM mode */
+	case 2:
+		fmt = 0;
+		break;
+	case 4: /* raw data mode */
+		fmt = SUN4I_SPDIF_TXCFG_NONAUDIO;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	switch (params_format(params)) {
+	case SNDRV_PCM_FORMAT_S16_LE:
+		fmt |= SUN4I_SPDIF_TXCFG_FMT16BIT;
+		break;
+	case SNDRV_PCM_FORMAT_S20_3LE:
+		fmt |= SUN4I_SPDIF_TXCFG_FMT20BIT;
+		break;
+	case SNDRV_PCM_FORMAT_S24_LE:
+		fmt |= SUN4I_SPDIF_TXCFG_FMT24BIT;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	switch (rate) {
+	case 22050:
+	case 44100:
+	case 88200:
+	case 176400:
+		mclk = 22579200;
+		break;
+	case 24000:
+	case 32000:
+	case 48000:
+	case 96000:
+	case 192000:
+		mclk = 24576000;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	ret = clk_set_rate(host->spdif_clk, mclk);
+	if (ret < 0) {
+		dev_err(&pdev->dev,
+			"Setting SPDIF clock rate for %d Hz failed!\n", mclk);
+		return ret;
+	}
+
+	regmap_update_bits(host->regmap, SUN4I_SPDIF_FCTL,
+			   SUN4I_SPDIF_FCTL_TXIM, SUN4I_SPDIF_FCTL_TXIM);
+
+	switch (rate) {
+	case 22050:
+	case 24000:
+		mclk_div = 8;
+		break;
+	case 32000:
+		mclk_div = 6;
+		break;
+	case 44100:
+	case 48000:
+		mclk_div = 4;
+		break;
+	case 88200:
+	case 96000:
+		mclk_div = 2;
+		break;
+	case 176400:
+	case 192000:
+		mclk_div = 1;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	reg_val = 0;
+	reg_val |= SUN4I_SPDIF_TXCFG_ASS;
+	reg_val |= fmt; /* set non audio and bit depth */
+	reg_val |= SUN4I_SPDIF_TXCFG_CHSTMODE;
+	reg_val |= SUN4I_SPDIF_TXCFG_TXRATIO(mclk_div - 1);
+	regmap_write(host->regmap, SUN4I_SPDIF_TXCFG, reg_val);
+
+	return 0;
+}
+
+static int sun4i_spdif_trigger(struct snd_pcm_substream *substream, int cmd,
+			       struct snd_soc_dai *dai)
+{
+	int ret = 0;
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(dai);
+
+	if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK)
+		return -EINVAL;
+
+	switch (cmd) {
+	case SNDRV_PCM_TRIGGER_START:
+	case SNDRV_PCM_TRIGGER_RESUME:
+	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+		sun4i_snd_txctrl_on(substream, host);
+		break;
+
+	case SNDRV_PCM_TRIGGER_STOP:
+	case SNDRV_PCM_TRIGGER_SUSPEND:
+	case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+		sun4i_snd_txctrl_off(substream, host);
+		break;
+
+	default:
+		ret = -EINVAL;
+		break;
+	}
+	return ret;
+}
+
+static int sun4i_spdif_soc_dai_probe(struct snd_soc_dai *dai)
+{
+	struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(dai);
+
+	snd_soc_dai_init_dma_data(dai, &host->dma_params_tx, NULL);
+	return 0;
+}
+
+static const struct snd_soc_dai_ops sun4i_spdif_dai_ops = {
+	.startup	= sun4i_spdif_startup,
+	.trigger	= sun4i_spdif_trigger,
+	.hw_params	= sun4i_spdif_hw_params,
+};
+
+static const struct regmap_config sun4i_spdif_regmap_config = {
+	.reg_bits = 32,
+	.reg_stride = 4,
+	.val_bits = 32,
+	.max_register = SUN4I_SPDIF_RXCHSTA1,
+};
+
+#define SUN4I_RATES	SNDRV_PCM_RATE_8000_192000
+
+#define SUN4I_FORMATS	(SNDRV_PCM_FORMAT_S16_LE | \
+				SNDRV_PCM_FORMAT_S20_3LE | \
+				SNDRV_PCM_FORMAT_S24_LE)
+
+static struct snd_soc_dai_driver sun4i_spdif_dai = {
+	.playback = {
+		.channels_min = 1,
+		.channels_max = 2,
+		.rates = SUN4I_RATES,
+		.formats = SUN4I_FORMATS,
+	},
+	.probe = sun4i_spdif_soc_dai_probe,
+	.ops = &sun4i_spdif_dai_ops,
+	.name = "spdif",
+};
+
+static const struct of_device_id sun4i_spdif_of_match[] = {
+	{ .compatible = "allwinner,sun4i-a10-spdif", },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sun4i_spdif_of_match);
+
+static const struct snd_soc_component_driver sun4i_spdif_component = {
+	.name		= "sun4i-spdif",
+};
+
+static int sun4i_spdif_runtime_suspend(struct device *dev)
+{
+	struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
+
+	clk_disable_unprepare(host->spdif_clk);
+	clk_disable_unprepare(host->apb_clk);
+
+	return 0;
+}
+
+static int sun4i_spdif_runtime_resume(struct device *dev)
+{
+	struct sun4i_spdif_dev *host  = dev_get_drvdata(dev);
+
+	clk_prepare_enable(host->spdif_clk);
+	clk_prepare_enable(host->apb_clk);
+
+	return 0;
+}
+
+static int sun4i_spdif_probe(struct platform_device *pdev)
+{
+	struct sun4i_spdif_dev *host;
+	struct resource *res;
+	int ret;
+	void __iomem *base;
+
+	dev_dbg(&pdev->dev, "Entered %s\n", __func__);
+
+	host = devm_kzalloc(&pdev->dev, sizeof(*host), GFP_KERNEL);
+	if (!host)
+		return -ENOMEM;
+
+	host->pdev = pdev;
+
+	/* Initialize this copy of the CPU DAI driver structure */
+	memcpy(&host->cpu_dai_drv, &sun4i_spdif_dai, sizeof(sun4i_spdif_dai));
+	host->cpu_dai_drv.name = dev_name(&pdev->dev);
+
+	/* Get the addresses */
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	host->regmap = devm_regmap_init_mmio(&pdev->dev, base,
+						&sun4i_spdif_regmap_config);
+
+	/* Clocks */
+	host->apb_clk = devm_clk_get(&pdev->dev, "apb");
+	if (IS_ERR(host->apb_clk)) {
+		dev_err(&pdev->dev, "failed to get a apb clock.\n");
+		return PTR_ERR(host->apb_clk);
+	}
+
+	host->spdif_clk = devm_clk_get(&pdev->dev, "spdif");
+	if (IS_ERR(host->spdif_clk)) {
+		dev_err(&pdev->dev, "failed to get a spdif clock.\n");
+		ret = PTR_ERR(host->spdif_clk);
+		goto err_disable_apb_clk;
+	}
+
+	host->dma_params_tx.addr = res->start + SUN4I_SPDIF_TXFIFO;
+	host->dma_params_tx.maxburst = 4;
+	host->dma_params_tx.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
+
+	platform_set_drvdata(pdev, host);
+
+	ret = devm_snd_soc_register_component(&pdev->dev,
+				&sun4i_spdif_component, &sun4i_spdif_dai, 1);
+	if (ret)
+		goto err_disable_apb_clk;
+
+	pm_runtime_enable(&pdev->dev);
+	if (!pm_runtime_enabled(&pdev->dev)) {
+		ret = sun4i_spdif_runtime_resume(&pdev->dev);
+		if (ret)
+			goto err_unregister;
+	}
+
+	ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
+	if (ret)
+		goto err_suspend;
+	return 0;
+err_suspend:
+	if (!pm_runtime_status_suspended(&pdev->dev))
+		sun4i_spdif_runtime_suspend(&pdev->dev);
+err_unregister:
+	pm_runtime_disable(&pdev->dev);
+	snd_soc_unregister_component(&pdev->dev);
+err_disable_apb_clk:
+	clk_disable_unprepare(host->apb_clk);
+	return ret;
+}
+
+static int sun4i_spdif_remove(struct platform_device *pdev)
+{
+	pm_runtime_disable(&pdev->dev);
+	if (!pm_runtime_status_suspended(&pdev->dev))
+		sun4i_spdif_runtime_suspend(&pdev->dev);
+
+	snd_soc_unregister_platform(&pdev->dev);
+	snd_soc_unregister_component(&pdev->dev);
+
+	return 0;
+}
+
+static const struct dev_pm_ops sun4i_spdif_pm = {
+	SET_RUNTIME_PM_OPS(sun4i_spdif_runtime_suspend,
+			   sun4i_spdif_runtime_resume, NULL)
+};
+
+static struct platform_driver sun4i_spdif_driver = {
+	.driver		= {
+		.name	= "sun4i-spdif",
+		.of_match_table = of_match_ptr(sun4i_spdif_of_match),
+		.pm	= &sun4i_spdif_pm,
+	},
+	.probe		= sun4i_spdif_probe,
+	.remove		= sun4i_spdif_remove,
+};
+
+module_platform_driver(sun4i_spdif_driver);
+
+MODULE_AUTHOR("Marcus Cooper <codekipper at gmail.com>");
+MODULE_AUTHOR("Andrea Venturi <be17068 at iperbole.bo.it>");
+MODULE_DESCRIPTION("Allwinner sun4i SPDIF SoC Interface");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:sun4i-spdif");
-- 
2.7.1



From michael at amarulasolutions.com  Sun Feb 21 03:18:03 2016
From: michael at amarulasolutions.com (Michael Trimarchi)
Date: Sun, 21 Feb 2016 12:18:03 +0100
Subject: [PATCH V2 1/4] ARM: dts: imx6ul: Add flexcan1 and flexcan2 support
In-Reply-To: <CAOMZO5DfKi5KymQ6p9yF4ntqEJ7O=EEE7CKFmS-0N2XL8=ET7A@mail.gmail.com>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
 <1455963652-24618-2-git-send-email-michael@amarulasolutions.com>
 <CAOMZO5Bk_ZMhYzFLRFNK2TQvK4KHuj62AM_6uF-m-P1kJupTHQ@mail.gmail.com>
 <20160220171816.GA24064@panicking>
 <CAOMZO5DfKi5KymQ6p9yF4ntqEJ7O=EEE7CKFmS-0N2XL8=ET7A@mail.gmail.com>
Message-ID: <20160221111759.GA5387@panicking>

Add support for FLEXCAN1 and FLEXCAN2.

Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
---
Changes in V2:
	- remove stop-mode property because is not handle in
	  mainline

 arch/arm/boot/dts/imx6ul.dtsi | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 99b6465..f7b852e 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -14,6 +14,8 @@
 
 / {
 	aliases {
+		can0 = &flexcan1;
+		can1 = &flexcan2;
 		ethernet0 = &fec1;
 		ethernet1 = &fec2;
 		gpio0 = &gpio1;
@@ -234,6 +236,26 @@
 					clock-names = "ipg", "per";
 					status = "disabled";
 				};
+
+				flexcan1: can at 02090000 {
+					compatible = "fsl,imx6ul-flexcan", "fsl,imx6q-flexcan";
+					reg = <0x02090000 0x4000>;
+					interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clks IMX6UL_CLK_CAN1_IPG>,
+						 <&clks IMX6UL_CLK_CAN1_SERIAL>;
+					clock-names = "ipg", "per";
+					status = "disabled";
+				};
+
+				flexcan2: can at 02094000 {
+					compatible = "fsl,imx6ul-flexcan", "fsl,imx6q-flexcan";
+					reg = <0x02094000 0x4000>;
+					interrupts = <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+					clocks = <&clks IMX6UL_CLK_CAN2_IPG>,
+						 <&clks IMX6UL_CLK_CAN2_SERIAL>;
+					clock-names = "ipg", "per";
+					status = "disabled";
+				};
 			};
 
 			gpt1: gpt at 02098000 {
-- 
2.7.0

-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |


From michael at amarulasolutions.com  Sun Feb 21 03:29:53 2016
From: michael at amarulasolutions.com (Michael Trimarchi)
Date: Sun, 21 Feb 2016 12:29:53 +0100
Subject: [PATCH V2 3/4] ARM: dts: imx6ul: Add GPMI nand controller support
In-Reply-To: <20160220172127.GC24064@panicking>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
 <1455963652-24618-4-git-send-email-michael@amarulasolutions.com>
 <CAOMZO5DTmG7Umt+H20r+tZi9zZhsK=eoPbHOBO3iwvM2GXXLgg@mail.gmail.com>
 <20160220172127.GC24064@panicking>
Message-ID: <20160221112949.GB5387@panicking>

Add support for GPMI nand controller.

Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
---
Changes V2:
	- drop special IMXUL type because seems that is compatible
	  with IMX6Q

 arch/arm/boot/dts/imx6ul.dtsi | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index f4daf97..1a486ac 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -142,6 +142,39 @@
 			reg = <0x00900000 0x20000>;
 		};
 
+		dma_apbh: dma-apbh at 01804000 {
+			compatible = "fsl,imx6ul-dma-apbh", "fsl,imx28-dma-apbh";
+			reg = <0x01804000 0x2000>;
+			interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "gpmi0", "gpmi1", "gpmi2", "gpmi3";
+			#dma-cells = <1>;
+			dma-channels = <4>;
+			clocks = <&clks IMX6UL_CLK_APBHDMA>;
+		};
+
+		gpmi: gpmi-nand at 01806000 {
+			compatible = "fsl,imx6q-gpmi-nand";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0x01806000 0x2000>, <0x01808000 0x4000>;
+			reg-names = "gpmi-nand", "bch";
+			interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "bch";
+			clocks = <&clks IMX6UL_CLK_GPMI_IO>,
+				 <&clks IMX6UL_CLK_GPMI_APB>,
+				 <&clks IMX6UL_CLK_GPMI_BCH>,
+				 <&clks IMX6UL_CLK_GPMI_BCH_APB>,
+				 <&clks IMX6UL_CLK_PER_BCH>;
+			clock-names = "gpmi_io", "gpmi_apb", "gpmi_bch",
+				      "gpmi_bch_apb", "per1_bch";
+			dmas = <&dma_apbh 0>;
+			dma-names = "rx-tx";
+			status = "disabled";
+		};
+
 		aips1: aips-bus at 02000000 {
 			compatible = "fsl,aips-bus", "simple-bus";
 			#address-cells = <1>;
-- 
2.7.0

-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |


From sdliyong at gmail.com  Sun Feb 21 04:19:57 2016
From: sdliyong at gmail.com (LIYONG)
Date: Sun, 21 Feb 2016 20:19:57 +0800
Subject: [PATCH] ARM: OMAP2+: allow DEBUG_UNCOMPRESS for OMAP2+
In-Reply-To: <20160219180237.GI21202@atomide.com>
References: <1451362159-27910-1-git-send-email-sdliyong@gmail.com>
 <20160219180237.GI21202@atomide.com>
Message-ID: <BLU402-EAS3654C3D896BB35B714D68BD6A20@phx.gbl>

no problem, let me submit another patch

> ? 2016?2?20??02:02?Tony Lindgren <tony at atomide.com> ???
> 
> Hi,
> 
> * Yong Li <sdliyong at gmail.com> [151228 20:12]:
>> Based on the below
>> commit ae3c99a26c60 ("ARM: 7806/1: allow DEBUG_UNCOMPRESS for Tegra"),
>> change the .data section to .text section,
>> to enable DEBUG_UNCOMPRESS for OMAP2+ platforms
>> Tested okay using BeagleBone Black
> 
> Sorry for the delay, I just noticed this one while looking
> through my inbox for pending patches.
> 
> I think we should first simplify things by moving things over
> to use the generic DEBUG_UART_8250 code where the addresses
> need to be specified in the .config. It's been on my list of
> things to do for quite a while but I keep getting interrupted.
> 
> My guess is that if we do that, this patch is no longer
> needed :) Yong, care to take a look at that?
> 
> Regards,
> 
> Tony
> 
>> Signed-off-by: Yong Li <sdliyong at gmail.com>
>> ---
>> arch/arm/Kconfig.debug             |  2 +-
>> arch/arm/include/debug/omap2plus.S | 13 ++++++++++---
>> 2 files changed, 11 insertions(+), 4 deletions(-)
>> 
>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>> index 259c0ca..e5ae36a 100644
>> --- a/arch/arm/Kconfig.debug
>> +++ b/arch/arm/Kconfig.debug
>> @@ -1596,7 +1596,7 @@ config DEBUG_UART_8250_FLOW_CONTROL
>> config DEBUG_UNCOMPRESS
>>    bool
>>    depends on ARCH_MULTIPLATFORM || PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
>> -    default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \
>> +    default y if DEBUG_LL && (!DEBUG_OMAP2PLUS_UART || !ZBOOT_ROM) && \
>>             (!DEBUG_TEGRA_UART || !ZBOOT_ROM)
>>    help
>>      This option influences the normal decompressor output for
>> diff --git a/arch/arm/include/debug/omap2plus.S b/arch/arm/include/debug/omap2plus.S
>> index 6d867ae..12421f9 100644
>> --- a/arch/arm/include/debug/omap2plus.S
>> +++ b/arch/arm/include/debug/omap2plus.S
>> @@ -58,11 +58,18 @@
>> 
>> #define UART_OFFSET(addr)    ((addr) & 0x00ffffff)
>> 
>> +#if defined(ZIMAGE)
>> +    omap_uart_phys:    .word    0
>> +    omap_uart_virt:    .word    0
>> +    omap_uart_lsr:    .word    0
>> +#else
>> +
>>        .pushsection .data
>> -omap_uart_phys:    .word    0
>> -omap_uart_virt:    .word    0
>> -omap_uart_lsr:    .word    0
>> +    omap_uart_phys:    .word    0
>> +    omap_uart_virt:    .word    0
>> +    omap_uart_lsr:    .word    0
>>        .popsection
>> +#endif
>> 
>>        .macro    addruart, rp, rv, tmp
>> 
>> -- 
>> 2.1.4
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 

From mpa at pengutronix.de  Sun Feb 21 04:52:06 2016
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 21 Feb 2016 13:52:06 +0100
Subject: [PATCH RESEND] gpmi-nand: Handle ECC Errors in erased pages
Message-ID: <1456059126-25469-1-git-send-email-mpa@pengutronix.de>

ECC is only calculated for written pages. As erased pages are not
actively written the ECC is always invalid. For this purpose the
Hardware BCH unit is able to check for erased pages and does not raise
an ECC error in this case. This behaviour can be influenced using the
BCH_MODE register which sets the number of allowed bitflips in an erased
page. Unfortunately the unit is not capable of fixing the bitflips in
memory.

To avoid complete software checks for erased pages, we can simply check
buffers with uncorrectable ECC errors because we know that any erased
page with errors is uncorrectable by the BCH unit.

This patch adds the generic nand_check_erased_ecc_chunk() to gpmi-nand
to correct erased pages. To have the valid data in the buffer before
using them, this patch moves the read_page_swap_end() call before the
ECC status checking for-loop.

Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 49 ++++++++++++++++++++++++++++++----
 1 file changed, 44 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 235ddcb58f39..ce5a21252102 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1035,14 +1035,58 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd, struct nand_chip *chip,
 	/* Loop over status bytes, accumulating ECC status. */
 	status = auxiliary_virt + nfc_geo->auxiliary_status_offset;
 
+	read_page_swap_end(this, buf, nfc_geo->payload_size,
+			   this->payload_virt, this->payload_phys,
+			   nfc_geo->payload_size,
+			   payload_virt, payload_phys);
+
 	for (i = 0; i < nfc_geo->ecc_chunk_count; i++, status++) {
 		if ((*status == STATUS_GOOD) || (*status == STATUS_ERASED))
 			continue;
 
 		if (*status == STATUS_UNCORRECTABLE) {
+			int flips;
+
+			/*
+			 * The ECC hardware has an uncorrectable ECC status
+			 * code in case we have bitflips in an erased page. As
+			 * nothing was written into this subpage the ECC is
+			 * obviously wrong and we can not trust it. We assume
+			 * at this point that we are reading an erased page and
+			 * try to correct the bitflips in buffer up to
+			 * ecc_strength bitflips. If this is a page with random
+			 * data, we exceed this number of bitflips and have a
+			 * ECC failure. Otherwise we use the corrected buffer.
+			 */
+			if (i == 0) {
+				/* The first block includes metadata */
+				flips = nand_check_erased_ecc_chunk(
+						buf + i * nfc_geo->ecc_chunk_size,
+						nfc_geo->ecc_chunk_size,
+						NULL, 0,
+						auxiliary_virt,
+						nfc_geo->metadata_size,
+						nfc_geo->ecc_strength);
+			} else {
+				flips = nand_check_erased_ecc_chunk(
+						buf + i * nfc_geo->ecc_chunk_size,
+						nfc_geo->ecc_chunk_size,
+						NULL, 0,
+						NULL, 0,
+						nfc_geo->ecc_strength);
+			}
+
+			if (flips > 0) {
+				max_bitflips = max_t(unsigned int, max_bitflips,
+						     flips);
+				mtd->ecc_stats.corrected += flips;
+				continue;
+			}
+
 			mtd->ecc_stats.failed++;
 			continue;
 		}
+
 		mtd->ecc_stats.corrected += *status;
 		max_bitflips = max_t(unsigned int, max_bitflips, *status);
 	}
@@ -1062,11 +1106,6 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd, struct nand_chip *chip,
 		chip->oob_poi[0] = ((uint8_t *) auxiliary_virt)[0];
 	}
 
-	read_page_swap_end(this, buf, nfc_geo->payload_size,
-			this->payload_virt, this->payload_phys,
-			nfc_geo->payload_size,
-			payload_virt, payload_phys);
-
 	return max_bitflips;
 }
 
-- 
2.7.0



From mpa at pengutronix.de  Sun Feb 21 05:07:15 2016
From: mpa at pengutronix.de (Markus Pargmann)
Date: Sun, 21 Feb 2016 14:07:15 +0100
Subject: [PATCH] mfd: fsl-imx25-tsadc: select IRQ_DOMAIN
In-Reply-To: <1455634467-2013548-1-git-send-email-arnd@arndb.de>
References: <1455634467-2013548-1-git-send-email-arnd@arndb.de>
Message-ID: <1544245.mjq7iKKDQ3@galactica>

On Tuesday 16 February 2016 15:54:24 Arnd Bergmann wrote:
> The newly added tsadc code use irq domains, but it can be enabled
> when they are disabled in Kconfig:
> 
> drivers/mfd/fsl-imx25-tsadc.c:41:22: error: implicit declaration of function 'irq_find_mapping' [-Werror=implicit-function-declaration]
>    generic_handle_irq(irq_find_mapping(tsadc->domain, 1));
> drivers/mfd/fsl-imx25-tsadc.c: In function 'mx25_tsadc_setup_irq':
> drivers/mfd/fsl-imx25-tsadc.c:80:18: error: implicit declaration of function 'irq_domain_add_simple' [-Werror=implicit-function-declaration]
> 
> This adds a 'select IRQ_DOMAIN' code, like we have it in all other
> drivers with this requirement.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: e2fccf5c1515 ("mfd: fsl-imx25-tsadc: Register touchscreen ADC driver")

Thanks,

Reviewed-by: Markus Pargmann <mpa at pengutronix.de>

Best Regards,

Markus

> ---
>  drivers/mfd/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index aa21dc55eb15..8cab3ecca8fc 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -300,6 +300,7 @@ config MFD_MC13XXX_I2C
>  config MFD_MX25_TSADC
>  	tristate "Freescale i.MX25 integrated Touchscreen and ADC unit"
>  	select REGMAP_MMIO
> +	select IRQ_DOMAIN
>  	depends on (SOC_IMX25 && OF) || COMPILE_TEST
>  	help
>  	  Enable support for the integrated Touchscreen and ADC unit of the
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160221/ef514e0f/attachment-0001.sig>

From draakje197 at gmail.com  Sun Feb 21 05:20:41 2016
From: draakje197 at gmail.com (Henry Paulissen)
Date: Sun, 21 Feb 2016 14:20:41 +0100
Subject: [PATCH v3] Fix sun7i pin assignment for IRQ's
Message-ID: <1456060845-20692-1-git-send-email-henry@nitronetworks.nl>

After testing IRQ pins we found some bugs in the pinctrl declaration.

Signed-off-by: Henry Paulissen <henry at nitronetworks.nl>
---

Changes in v2:
    After some more testing we found irq on PI pins.
    they where on mux6 so this is included in my patch.

    Also included is a warning for PI17, this pin was not working
    on apritzel his bPI and he thinks it might be correlated to
    GIC and IRQ 29.

Changes in v3:
    Changed name from nickname to realname in email and SoB.
---
 drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c | 25 +++++++++++--------------
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
index cf1ce0c..0fe173e 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
@@ -344,25 +344,21 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE4 */
 		  SUNXI_FUNCTION(0x3, "spi2"),		/* CS0 */
-		  SUNXI_FUNCTION_IRQ(0x6, 12)),		/* EINT12 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 20),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE5 */
 		  SUNXI_FUNCTION(0x3, "spi2"),		/* CLK */
-		  SUNXI_FUNCTION_IRQ(0x6, 13)),		/* EINT13 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 21),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE6 */
 		  SUNXI_FUNCTION(0x3, "spi2"),		/* MOSI */
-		  SUNXI_FUNCTION_IRQ(0x6, 14)),		/* EINT14 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 22),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE7 */
 		  SUNXI_FUNCTION(0x3, "spi2"),		/* MISO */
-		  SUNXI_FUNCTION_IRQ(0x6, 15)),		/* EINT15 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 23),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
@@ -960,65 +956,66 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS0 */
 		  SUNXI_FUNCTION(0x3, "uart5"),		/* TX */
-		  SUNXI_FUNCTION_IRQ(0x5, 22)),		/* EINT22 */
+		  SUNXI_FUNCTION_IRQ(0x6, 22)),		/* EINT22 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 11),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CLK */
 		  SUNXI_FUNCTION(0x3, "uart5"),		/* RX */
-		  SUNXI_FUNCTION_IRQ(0x5, 23)),		/* EINT23 */
+		  SUNXI_FUNCTION_IRQ(0x6, 23)),		/* EINT23 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 12),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* MOSI */
 		  SUNXI_FUNCTION(0x3, "uart6"),		/* TX */
 		  SUNXI_FUNCTION(0x4, "clk_out_a"),	/* CLK_OUT_A */
-		  SUNXI_FUNCTION_IRQ(0x5, 24)),		/* EINT24 */
+		  SUNXI_FUNCTION_IRQ(0x6, 24)),		/* EINT24 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 13),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* MISO */
 		  SUNXI_FUNCTION(0x3, "uart6"),		/* RX */
 		  SUNXI_FUNCTION(0x4, "clk_out_b"),	/* CLK_OUT_B */
-		  SUNXI_FUNCTION_IRQ(0x5, 25)),		/* EINT25 */
+		  SUNXI_FUNCTION_IRQ(0x6, 25)),		/* EINT25 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 14),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS1 */
 		  SUNXI_FUNCTION(0x3, "ps2"),		/* SCK1 */
 		  SUNXI_FUNCTION(0x4, "timer4"),	/* TCLKIN0 */
-		  SUNXI_FUNCTION_IRQ(0x5, 26)),		/* EINT26 */
+		  SUNXI_FUNCTION_IRQ(0x6, 26)),		/* EINT26 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 15),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS1 */
 		  SUNXI_FUNCTION(0x3, "ps2"),		/* SDA1 */
 		  SUNXI_FUNCTION(0x4, "timer5"),	/* TCLKIN1 */
-		  SUNXI_FUNCTION_IRQ(0x5, 27)),		/* EINT27 */
+		  SUNXI_FUNCTION_IRQ(0x6, 27)),		/* EINT27 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 16),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS0 */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* RTS */
-		  SUNXI_FUNCTION_IRQ(0x5, 28)),		/* EINT28 */
+		  SUNXI_FUNCTION_IRQ(0x6, 28)),		/* EINT28 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 17),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CLK */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* CTS */
-		  SUNXI_FUNCTION_IRQ(0x5, 29)),		/* EINT29 */
+		  SUNXI_FUNCTION_IRQ(0x6, 29)),		/* EINT29 */
+		  /* EINT29 might not work - more testing needed */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 18),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* MOSI */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* TX */
-		  SUNXI_FUNCTION_IRQ(0x5, 30)),		/* EINT30 */
+		  SUNXI_FUNCTION_IRQ(0x6, 30)),		/* EINT30 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 19),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* MISO */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* RX */
-		  SUNXI_FUNCTION_IRQ(0x5, 31)),		/* EINT31 */
+		  SUNXI_FUNCTION_IRQ(0x6, 31)),		/* EINT31 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 20),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
-- 
2.5.0



From wsa at the-dreams.de  Sun Feb 21 06:16:48 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Sun, 21 Feb 2016 15:16:48 +0100
Subject: [PATCH] i2c: brcmstb: allocate correct amount of memory for regmap
Message-ID: <1456064238-6294-1-git-send-email-wsa@the-dreams.de>

We want the size of the struct, not of a pointer to it. To be future
proof, just dereference the pointer to get the desired type.

Signed-off-by: Wolfram Sang <wsa at the-dreams.de>
---
 drivers/i2c/busses/i2c-brcmstb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-brcmstb.c b/drivers/i2c/busses/i2c-brcmstb.c
index 3711df1d452622..4a45408dd82060 100644
--- a/drivers/i2c/busses/i2c-brcmstb.c
+++ b/drivers/i2c/busses/i2c-brcmstb.c
@@ -586,8 +586,7 @@ static int brcmstb_i2c_probe(struct platform_device *pdev)
 	if (!dev)
 		return -ENOMEM;
 
-	dev->bsc_regmap = devm_kzalloc(&pdev->dev, sizeof(struct bsc_regs *),
-				       GFP_KERNEL);
+	dev->bsc_regmap = devm_kzalloc(&pdev->dev, sizeof(*dev->bsc_regmap), GFP_KERNEL);
 	if (!dev->bsc_regmap)
 		return -ENOMEM;
 
-- 
2.7.0



From festevam at gmail.com  Sun Feb 21 07:22:34 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Sun, 21 Feb 2016 12:22:34 -0300
Subject: iMX7d cpu1 issue
In-Reply-To: <56C6CE36.6040503@compulab.co.il>
References: <56C2D63F.1030408@compulab.co.il> <20160218140913.GY6756@tiger>
 <AMSPR04MB263D00A3F8D9A8D9D3A536D88AF0@AMSPR04MB263.eurprd04.prod.outlook.com>
 <56C5F4D7.1070704@compulab.co.il>
 <AMSPR04MB26334EB884FA8A4B565278188AF0@AMSPR04MB263.eurprd04.prod.outlook.com>
 <56C6CE36.6040503@compulab.co.il>
Message-ID: <CAOMZO5Aa+veHWQCrKGz4rsvmjKWiitd81D8ncGnX8Fdk0aYe7Q@mail.gmail.com>

Hi Ilya/Frank,

On Fri, Feb 19, 2016 at 6:11 AM, Ilya Ledvich <ilya at compulab.co.il> wrote:
> Hi Frank,
> Thank you for so brilliant suggestion!!!
>
>> #define CONFIG_MX7_SEC
>
>
> Seems it works!
> The  CPU1 is brought up, and kernel can successfully boot!

I changed U-boot as suggested:

--- a/include/configs/mx7_common.h
+++ b/include/configs/mx7_common.h
@@ -94,10 +94,7 @@
 #define CONFIG_CMD_FUSE
 #define CONFIG_MXC_OCOTP

-/*
- * Default boot linux kernel in no secure mode.
- * If want to boot kernel in secure mode, please define CONFIG_MX7_SEC
- */
+#define CONFIG_MX7_SEC
 #ifndef CONFIG_MX7_SEC
 #define CONFIG_ARMV7_NONSEC
 #define CONFIG_ARMV7_PSCI


but still see only one core brought up in the kernel:

[    0.003051] /cpus/cpu at 0 missing clock-frequency property
[    0.003076] /cpus/cpu at 1 missing clock-frequency property
[    0.003092] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.003157] Setting up static identity map for 0x80008280 - 0x800082f0
[    0.005152] Brought up 1 CPUs
[    0.005169] SMP: Total of 1 processors activated (48.00 BogoMIPS).

I am booting 4.5-rc5 on a imx7d-sdb board.

Any ideas on how to bring up the second core?


From michael at amarulasolutions.com  Sun Feb 21 07:32:02 2016
From: michael at amarulasolutions.com (Michael Trimarchi)
Date: Sun, 21 Feb 2016 16:32:02 +0100
Subject: [PATCH V2 4/4] ARM: dts: imx6ul-geam: Add Engicam IMX6UL GEA M6UL
 initial support
In-Reply-To: <CAOMZO5CaBaNYAZDOhW2mXDe4OtBmZK7bDRfoQXcKio_tr3ZUBQ@mail.gmail.com>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
 <1455963652-24618-5-git-send-email-michael@amarulasolutions.com>
 <CAOMZO5AmePs3aE2zRSXcSS8iKQ0m2kvTAezsfHS13e-Zv1HCrA@mail.gmail.com>
 <20160220171921.GB24064@panicking>
 <CAOMZO5CaBaNYAZDOhW2mXDe4OtBmZK7bDRfoQXcKio_tr3ZUBQ@mail.gmail.com>
Message-ID: <20160221153155.GA5033@panicking>

http://www.engicam.com/prodotti/embedded/som/sodimm/gea-m6ul

Signed-off-by: Matteo Lisi <matteo.lisi at engicam.com>
Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
---
Changes V2:
	- remove not used muxed
	- sort better regulator but not remove "silly" one propertes for now
	- small issue on code style
	- add Matteo from Engicam that help me to test and verify the board,
	  provide hw support

 arch/arm/boot/dts/Makefile            |   3 +-
 arch/arm/boot/dts/imx6ul-geam-kit.dts | 102 ++++++++++
 arch/arm/boot/dts/imx6ul-geam.dtsi    | 362 ++++++++++++++++++++++++++++++++++
 3 files changed, 466 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/imx6ul-geam-kit.dts
 create mode 100644 arch/arm/boot/dts/imx6ul-geam.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..4f6965a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -358,7 +358,8 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
 	imx6sx-sdb-reva.dtb \
 	imx6sx-sdb.dtb
 dtb-$(CONFIG_SOC_IMX6UL) += \
-	imx6ul-14x14-evk.dtb
+	imx6ul-14x14-evk.dtb \
+	imx6ul-geam-kit.dtb
 dtb-$(CONFIG_SOC_IMX7D) += \
 	imx7d-cl-som-imx7.dtb \
 	imx7d-sbc-imx7.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-geam-kit.dts b/arch/arm/boot/dts/imx6ul-geam-kit.dts
new file mode 100644
index 0000000..9ba4a66
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-geam-kit.dts
@@ -0,0 +1,102 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License
+ *     version 2 as published by the Free Software Foundation.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "imx6ul-geam.dtsi"
+
+/ {
+	model = "Engicam GEAM6UL";
+	compatible = "engicam,imx6ul-geam", "fsl,imx6ul";
+};
+
+&flexcan1 {
+	status = "okay";
+};
+
+&flexcan2 {
+	status = "okay";
+};
+
+&lcdif {
+	display = <&display0>;
+	status = "okay";
+
+	display0: display {
+		bits-per-pixel = <16>;
+		bus-width = <18>;
+
+		display-timings {
+			native-mode = <&timing0>;
+			timing0: timing0 {
+				clock-frequency = <28000000>;
+				hactive = <800>;
+				vactive = <480>;
+				hfront-porch = <30>;
+				hback-porch = <30>;
+				hsync-len = <64>;
+				vback-porch = <5>;
+				vfront-porch = <5>;
+				vsync-len = <20>;
+
+				hsync-active = <0>;
+				vsync-active = <0>;
+				de-active = <1>;
+				pixelclk-active = <0>;
+			};
+		};
+	};
+};
+
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	status = "okay";
+};
+
+&tsc {
+	measure_delay_time = <0x1ffff>;
+	pre_charge_time = <0x1fff>;
+	status = "okay";
+};
+
diff --git a/arch/arm/boot/dts/imx6ul-geam.dtsi b/arch/arm/boot/dts/imx6ul-geam.dtsi
new file mode 100644
index 0000000..914c0b1
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-geam.dtsi
@@ -0,0 +1,362 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License
+ *     version 2 as published by the Free Software Foundation.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "imx6ul.dtsi"
+
+/ {
+	memory {
+		reg = <0x80000000 0x20000000>;
+	};
+
+	chosen {
+		stdout-path = &uart1;
+	};
+
+	reg_1p8v: regulator-1p8v {
+		compatible = "regulator-fixed";
+		regulator-name = "1P8V";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	reg_3p3v: regulator-3p3v {
+		compatible = "regulator-fixed";
+		regulator-name = "3P3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+};
+
+&flexcan1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan1>;
+	xceiver-supply = <&reg_3p3v>;
+};
+
+&flexcan2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_flexcan2>;
+	xceiver-supply = <&reg_3p3v>;
+};
+
+&fec1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet1>;
+	phy-mode = "rmii";
+	phy-handle = <&ethphy0>;
+	status = "okay";
+};
+
+&fec2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_enet2>;
+	phy-mode = "rmii";
+	phy-handle = <&ethphy1>;
+	status = "okay";
+
+	mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ethphy0: ethernet-phy at 0 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <0>;
+		};
+
+		ethphy1: ethernet-phy at 1 {
+			compatible = "ethernet-phy-ieee802.3-c22";
+			reg = <1>;
+		};
+	};
+};
+
+&gpmi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_gpmi_nand>;
+	status = "okay";
+	nand-on-flash-bbt;
+};
+
+&lcdif {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lcdif_dat
+		     &pinctrl_lcdif_ctrl>;
+	display = <&display0>;
+};
+
+&tsc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_tsc>;
+	xnur-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>;
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2>;
+	status = "okay";
+};
+
+&usbotg1 {
+	dr_mode = "peripheral";
+	status = "okay";
+};
+
+&usbotg2 {
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usdhc1 {
+	pinctrl-names = "default", "state_100mhz", "state_200mhz";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+	pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+	bus-width = <4>;
+	cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
+	no-1-8-v;
+	status = "okay";
+};
+
+&i2c1 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1>;
+	status = "okay";
+};
+
+&i2c2 {
+	clock_frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+};
+
+&iomuxc {
+
+	pinctrl_enet1: enet1grp {
+		fsl,pins = <
+			MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN	0x1b0b0
+			MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00	0x1b0b0
+			MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01	0x1b0b0
+			MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN	0x1b0b0
+			MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00	0x1b0b0
+			MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01	0x1b0b0
+			MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1	0x4001b031
+		>;
+	};
+
+	pinctrl_enet2: enet2grp {
+		fsl,pins = <
+			MX6UL_PAD_GPIO1_IO07__ENET2_MDC		0x1b0b0
+			MX6UL_PAD_GPIO1_IO06__ENET2_MDIO	0x1b0b0
+			MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN	0x1b0b0
+			MX6UL_PAD_ENET2_RX_ER__GPIO2_IO15	0x1b0b0		/* ENET_nRST */
+			MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00	0x1b0b0
+			MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01	0x1b0b0
+			MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN	0x1b0b0
+			MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00	0x1b0b0
+			MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01	0x1b0b0
+			MX6UL_PAD_GPIO1_IO05__ENET2_REF_CLK2	0x4001b031
+		>;
+	};
+
+	pinctrl_flexcan1: flexcan1grp {
+		fsl,pins = <
+			MX6UL_PAD_UART3_RTS_B__FLEXCAN1_RX	0x1b020
+			MX6UL_PAD_UART3_CTS_B__FLEXCAN1_TX	0x1b020
+		>;
+	};
+
+	pinctrl_flexcan2: flexcan2grp {
+		fsl,pins = <
+			MX6UL_PAD_UART2_RTS_B__FLEXCAN2_RX	0x1b020
+			MX6UL_PAD_UART2_CTS_B__FLEXCAN2_TX	0x1b020
+		>;
+	};
+
+	pinctrl_gpmi_nand: gpmi-nand {
+		fsl,pins = <
+			MX6UL_PAD_NAND_CLE__RAWNAND_CLE         0xb0b1
+			MX6UL_PAD_NAND_ALE__RAWNAND_ALE         0xb0b1
+			MX6UL_PAD_NAND_WP_B__RAWNAND_WP_B       0xb0b1
+			MX6UL_PAD_NAND_READY_B__RAWNAND_READY_B 0xb000
+			MX6UL_PAD_NAND_CE0_B__RAWNAND_CE0_B     0xb0b1
+			MX6UL_PAD_NAND_RE_B__RAWNAND_RE_B       0xb0b1
+			MX6UL_PAD_NAND_WE_B__RAWNAND_WE_B       0xb0b1
+			MX6UL_PAD_NAND_DATA00__RAWNAND_DATA00   0xb0b1
+			MX6UL_PAD_NAND_DATA01__RAWNAND_DATA01   0xb0b1
+			MX6UL_PAD_NAND_DATA02__RAWNAND_DATA02   0xb0b1
+			MX6UL_PAD_NAND_DATA03__RAWNAND_DATA03   0xb0b1
+			MX6UL_PAD_NAND_DATA04__RAWNAND_DATA04   0xb0b1
+			MX6UL_PAD_NAND_DATA05__RAWNAND_DATA05   0xb0b1
+			MX6UL_PAD_NAND_DATA06__RAWNAND_DATA06   0xb0b1
+			MX6UL_PAD_NAND_DATA07__RAWNAND_DATA07   0xb0b1
+		>;
+	};
+
+	pinctrl_i2c1: i2c1grp {
+		fsl,pins = <
+			MX6UL_PAD_UART4_TX_DATA__I2C1_SCL 0x4001b8b0
+			MX6UL_PAD_UART4_RX_DATA__I2C1_SDA 0x4001b8b0
+		>;
+	};
+
+	pinctrl_i2c2: i2c2grp {
+			fsl,pins = <
+			MX6UL_PAD_UART5_TX_DATA__I2C2_SCL 0x4001b8b0
+			MX6UL_PAD_UART5_RX_DATA__I2C2_SDA 0x4001b8b0
+		>;
+	};
+
+	pinctrl_lcdif_ctrl: lcdifctrlgrp {
+		fsl,pins = <
+			MX6UL_PAD_LCD_CLK__LCDIF_CLK	    0x79
+			MX6UL_PAD_LCD_ENABLE__LCDIF_ENABLE  0x79
+			MX6UL_PAD_LCD_HSYNC__LCDIF_HSYNC    0x79
+			MX6UL_PAD_LCD_VSYNC__LCDIF_VSYNC    0x79
+		>;
+	};
+
+	pinctrl_lcdif_dat: lcdifdatgrp {
+		fsl,pins = <
+			MX6UL_PAD_LCD_DATA00__LCDIF_DATA00  0x79
+			MX6UL_PAD_LCD_DATA01__LCDIF_DATA01  0x79
+			MX6UL_PAD_LCD_DATA02__LCDIF_DATA02  0x79
+			MX6UL_PAD_LCD_DATA03__LCDIF_DATA03  0x79
+			MX6UL_PAD_LCD_DATA04__LCDIF_DATA04  0x79
+			MX6UL_PAD_LCD_DATA05__LCDIF_DATA05  0x79
+			MX6UL_PAD_LCD_DATA06__LCDIF_DATA06  0x79
+			MX6UL_PAD_LCD_DATA07__LCDIF_DATA07  0x79
+			MX6UL_PAD_LCD_DATA08__LCDIF_DATA08  0x79
+			MX6UL_PAD_LCD_DATA09__LCDIF_DATA09  0x79
+			MX6UL_PAD_LCD_DATA10__LCDIF_DATA10  0x79
+			MX6UL_PAD_LCD_DATA11__LCDIF_DATA11  0x79
+			MX6UL_PAD_LCD_DATA12__LCDIF_DATA12  0x79
+			MX6UL_PAD_LCD_DATA13__LCDIF_DATA13  0x79
+			MX6UL_PAD_LCD_DATA14__LCDIF_DATA14  0x79
+			MX6UL_PAD_LCD_DATA15__LCDIF_DATA15  0x79
+			MX6UL_PAD_LCD_DATA16__LCDIF_DATA16  0x79
+			MX6UL_PAD_LCD_DATA17__LCDIF_DATA17  0x79
+		>;
+	};
+
+	pinctrl_uart1: uart1grp {
+		fsl,pins = <
+			MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+			MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+		>;
+	};
+
+	pinctrl_uart2: uart2grp {
+		fsl,pins = <
+			MX6UL_PAD_UART2_TX_DATA__UART2_DCE_TX	0x1b0b1
+			MX6UL_PAD_UART2_RX_DATA__UART2_DCE_RX	0x1b0b1
+			MX6UL_PAD_UART3_RX_DATA__UART2_DCE_RTS	0x1b0b1
+			MX6UL_PAD_UART3_TX_DATA__UART2_DCE_CTS	0x1b0b1
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			MX6UL_PAD_SD1_CMD__USDHC1_CMD     0x17059
+			MX6UL_PAD_SD1_CLK__USDHC1_CLK     0x10059
+			MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+			MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+			MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+			MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+		>;
+	};
+
+	pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+		fsl,pins = <
+			MX6UL_PAD_SD1_CMD__USDHC1_CMD     0x170b9
+			MX6UL_PAD_SD1_CLK__USDHC1_CLK     0x100b9
+			MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170b9
+			MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170b9
+			MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170b9
+			MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170b9
+		>;
+	};
+
+	pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+		fsl,pins = <
+			MX6UL_PAD_SD1_CMD__USDHC1_CMD     0x170f9
+			MX6UL_PAD_SD1_CLK__USDHC1_CLK     0x100f9
+			MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x170f9
+			MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x170f9
+			MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x170f9
+			MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x170f9
+		>;
+	};
+
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX6UL_PAD_CSI_VSYNC__USDHC2_CLK     0x17070
+			MX6UL_PAD_CSI_HSYNC__USDHC2_CMD     0x10070
+			MX6UL_PAD_CSI_DATA00__USDHC2_DATA0  0x17070
+			MX6UL_PAD_CSI_DATA01__USDHC2_DATA1  0x17070
+			MX6UL_PAD_CSI_DATA02__USDHC2_DATA2  0x17070
+			MX6UL_PAD_CSI_DATA03__USDHC2_DATA3  0x17070
+		>;
+	};
+
+	pinctrl_tsc: tscgrp {
+		fsl,pin = <
+			MX6UL_PAD_GPIO1_IO01__GPIO1_IO01	0xb0
+			MX6UL_PAD_GPIO1_IO02__GPIO1_IO02	0xb0
+			MX6UL_PAD_GPIO1_IO03__GPIO1_IO03	0xb0
+			MX6UL_PAD_GPIO1_IO04__GPIO1_IO04	0xb0
+		>;
+	};
+};
-- 
2.7.0

-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |


From tony at atomide.com  Sun Feb 21 07:34:50 2016
From: tony at atomide.com (Tony Lindgren)
Date: Sun, 21 Feb 2016 07:34:50 -0800
Subject: [PATCH] ARM: OMAP2+: allow DEBUG_UNCOMPRESS for OMAP2+
In-Reply-To: <BLU402-EAS3654C3D896BB35B714D68BD6A20@phx.gbl>
References: <1451362159-27910-1-git-send-email-sdliyong@gmail.com>
 <20160219180237.GI21202@atomide.com>
 <BLU402-EAS3654C3D896BB35B714D68BD6A20@phx.gbl>
Message-ID: <20160221153449.GA13417@atomide.com>

* LIYONG <sdliyong at gmail.com> [160221 04:20]:
> no problem, let me submit another patch

OK thanks!

Tony


From fu.wei at linaro.org  Sun Feb 21 08:35:46 2016
From: fu.wei at linaro.org (Fu Wei)
Date: Mon, 22 Feb 2016 00:35:46 +0800
Subject: [PATCH v3 6/6] kvm: arm64: Add ACPI support for virt arch timer
In-Reply-To: <56B8CBE8.7020305@arm.com>
References: <1454358418-5157-1-git-send-email-fu.wei@linaro.org>
 <1454358418-5157-7-git-send-email-fu.wei@linaro.org>
 <56B8CBE8.7020305@arm.com>
Message-ID: <CADyBb7uPxV0DUwsqpq5fBeZSU6JXRzh6kNeHy-vmpq+f0+q1FQ@mail.gmail.com>

Hi Marc

On 9 February 2016 at 01:10, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 01/02/16 20:26, fu.wei at linaro.org wrote:
>> From: Fu Wei <fu.wei at linaro.org>
>>
>> This patch adds ACPI/GTDT support for virt arch timer
>> using the API in GTDT driver.
>>
>> Signed-off-by: Fu Wei <fu.wei at linaro.org>
>> ---
>>  virt/kvm/arm/arch_timer.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>> index 0a279d3..4077347 100644
>> --- a/virt/kvm/arm/arch_timer.c
>> +++ b/virt/kvm/arm/arch_timer.c
>> @@ -385,6 +385,9 @@ static int kvm_timer_get_ppi(unsigned int *ppi)
>>  {
>>       struct device_node *np;
>>       int ret = -EINVAL;
>> +#ifdef CONFIG_ACPI_GTDT
>> +     struct arch_timer_data data;
>> +#endif
>>
>>       np = of_find_matching_node(NULL, arch_timer_of_match);
>>       if (!np) {
>> @@ -397,6 +400,11 @@ static int kvm_timer_get_ppi(unsigned int *ppi)
>>       of_node_put(np);
>>
>>  skip_of:
>> +#ifdef CONFIG_ACPI_GTDT
>> +     if (!*ppi && !gtdt_arch_timer_data_init(NULL, &data))
>> +             *ppi = data.virt_ppi;
>> +#endif
>> +
>>       if (*ppi)
>>               return 0;
>>
>>
>
> As I already pointed out in another thread hacking some KVM ACPI stuff,
> this is the wrong approach.
>
> We should have a *common* accessor in the timer code that exports the
> relevant information, whatever the firmware "du jour" is.
>
> See Julien's series, which seems to address the issue in a much more
> convincing way:
>
> https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018531.html
>

Thanks for your info, I have read through Julien's patchset in mailing list.
This patch is a improvement from Wei Huang's patch using my GTDT driver,
because his approach is getting info from DTB or ACPI directly.

But It seems Wei Huang is helping Julien on his patchset and trying to
provide Tested-by,
So I will delete these two patches(about kvm), and test Julien's patch also.

> Thanks,
>
>         M.
> --
> Jazz is not dead. It just smells funny...



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021


From jic23 at kernel.org  Sun Feb 21 08:48:20 2016
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sun, 21 Feb 2016 16:48:20 +0000
Subject: [PATCH v2 2/2] iio: dac: vf610_dac: Add IIO DAC driver for Vybrid
 SoC
In-Reply-To: <597b39da08c4c1416984cf7e873f56e19975b80e.1455516083.git.maitysanchayan@gmail.com>
References: <cover.1455516083.git.maitysanchayan@gmail.com><cover.1455516083.git.maitysanchayan@gmail.com>
 <597b39da08c4c1416984cf7e873f56e19975b80e.1455516083.git.maitysanchayan@gmail.com>
Message-ID: <02B1DDEF-6BE7-4C4C-AAD0-4EB496734316@kernel.org>



On 15 February 2016 06:42:33 GMT+00:00, Sanchayan Maity <maitysanchayan at gmail.com> wrote:
>Add driver support for DAC peripheral on Vybrid SoC.
>
>Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
>Acked-by: Rob Herring <robh at kernel.org>
Ordering is wrong in remove. I may well fix this up and apply later today. 
 Otherwise looks good to me.
>---
> Documentation/ABI/testing/sysfs-bus-iio-vf610      |   9 +
> .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
> drivers/iio/dac/Kconfig                            |   8 +
> drivers/iio/dac/Makefile                           |   1 +
>drivers/iio/dac/vf610_dac.c                        | 298
>+++++++++++++++++++++
> 5 files changed, 336 insertions(+)
>create mode 100644
>Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
> create mode 100644 drivers/iio/dac/vf610_dac.c
>
>diff --git a/Documentation/ABI/testing/sysfs-bus-iio-vf610
>b/Documentation/ABI/testing/sysfs-bus-iio-vf610
>index ecbc1f4..5ea809c 100644
>--- a/Documentation/ABI/testing/sysfs-bus-iio-vf610
>+++ b/Documentation/ABI/testing/sysfs-bus-iio-vf610
>@@ -5,3 +5,12 @@ Description:
> 		Specifies the hardware conversion mode used. The three
> 		available modes are "normal", "high-speed" and "low-power",
> 		where the last is the default mode.
>+
>+
>+What:		/sys/bus/iio/devices/iio:deviceX/out_conversion_mode
>+KernelVersion:	4.6
>+Contact:	linux-iio at vger.kernel.org
>+Description:
>+		Specifies the hardware conversion mode used within DAC.
>+		The two available modes are "high-power" and "low-power",
>+		where "low-power" mode is the default mode.
>\ No newline at end of file
>diff --git a/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>new file mode 100644
>index 0000000..20c6c7a
>--- /dev/null
>+++ b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>@@ -0,0 +1,20 @@
>+Freescale vf610 Digital to Analog Converter bindings
>+
>+The devicetree bindings are for the new DAC driver written for
>+vf610 SoCs from Freescale.
>+
>+Required properties:
>+- compatible: Should contain "fsl,vf610-dac"
>+- reg: Offset and length of the register set for the device
>+- interrupts: Should contain the interrupt for the device
>+- clocks: The clock is needed by the DAC controller
>+- clock-names: Must contain "dac" matching entry in the clocks
>property.
>+
>+Example:
>+dac0: dac at 400cc000 {
>+	compatible = "fsl,vf610-dac";
>+	reg = <0x400cc000 0x1000>;
>+	interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
>+	clock-names = "dac";
>+	clocks = <&clks VF610_CLK_DAC0>;
>+};
>diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
>index e701e28..8eb0502 100644
>--- a/drivers/iio/dac/Kconfig
>+++ b/drivers/iio/dac/Kconfig
>@@ -196,4 +196,12 @@ config MCP4922
> 	  To compile this driver as a module, choose M here: the module
> 	  will be called mcp4922.
> 
>+config VF610_DAC
>+	tristate "Vybrid vf610 DAC driver"
>+	help
>+	  Say yes here to support Vybrid board digital-to-analog converter.
>+
>+	  This driver can also be built as a module. If so, the module will
>+	  be called vf610_dac.
>+
> endmenu
>diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
>index 63ae056..93feb27 100644
>--- a/drivers/iio/dac/Makefile
>+++ b/drivers/iio/dac/Makefile
>@@ -21,3 +21,4 @@ obj-$(CONFIG_MAX517) += max517.o
> obj-$(CONFIG_MAX5821) += max5821.o
> obj-$(CONFIG_MCP4725) += mcp4725.o
> obj-$(CONFIG_MCP4922) += mcp4922.o
>+obj-$(CONFIG_VF610_DAC) += vf610_dac.o
>diff --git a/drivers/iio/dac/vf610_dac.c b/drivers/iio/dac/vf610_dac.c
>new file mode 100644
>index 0000000..3f70f96
>--- /dev/null
>+++ b/drivers/iio/dac/vf610_dac.c
>@@ -0,0 +1,298 @@
>+/*
>+ * Freescale Vybrid vf610 DAC driver
>+ *
>+ * Copyright 2016 Toradex AG
>+ *
>+ * This program is free software; you can redistribute it and/or
>modify
>+ * it under the terms of the GNU General Public License as published
>by
>+ * the Free Software Foundation; either version 2 of the License, or
>+ * (at your option) any later version.
>+ *
>+ * This program is distributed in the hope that it will be useful,
>+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
>+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>+ * GNU General Public License for more details.
>+ */
>+
>+#include <linux/clk.h>
>+#include <linux/err.h>
>+#include <linux/interrupt.h>
>+#include <linux/io.h>
>+#include <linux/kernel.h>
>+#include <linux/module.h>
>+#include <linux/platform_device.h>
>+#include <linux/regulator/consumer.h>
>+#include <linux/slab.h>
>+
>+#include <linux/iio/iio.h>
>+#include <linux/iio/sysfs.h>
>+
>+#define VF610_DACx_STATCTRL		0x20
>+
>+#define VF610_DAC_DACEN			BIT(15)
>+#define VF610_DAC_DACRFS		BIT(14)
>+#define VF610_DAC_LPEN			BIT(11)
>+
>+#define VF610_DAC_DAT0(x)		((x) & 0xFFF)
>+
>+enum vf610_conversion_mode_sel {
>+	VF610_DAC_CONV_HIGH_POWER,
>+	VF610_DAC_CONV_LOW_POWER,
>+};
>+
>+struct vf610_dac {
>+	struct clk *clk;
>+	struct device *dev;
>+	enum vf610_conversion_mode_sel conv_mode;
>+	void __iomem *regs;
>+};
>+
>+static void vf610_dac_init(struct vf610_dac *info)
>+{
>+	int val;
>+
>+	info->conv_mode = VF610_DAC_CONV_LOW_POWER;
>+	val = VF610_DAC_DACEN | VF610_DAC_DACRFS |
>+		VF610_DAC_LPEN;
>+	writel(val, info->regs + VF610_DACx_STATCTRL);
>+}
>+
>+static void vf610_dac_exit(struct vf610_dac *info)
>+{
>+	int val;
>+
>+	val = readl(info->regs + VF610_DACx_STATCTRL);
>+	val &= ~VF610_DAC_DACEN;
>+	writel(val, info->regs + VF610_DACx_STATCTRL);
>+}
>+
>+static int vf610_set_conversion_mode(struct iio_dev *indio_dev,
>+				const struct iio_chan_spec *chan,
>+				unsigned int mode)
>+{
>+	struct vf610_dac *info = iio_priv(indio_dev);
>+	int val;
>+
>+	mutex_lock(&indio_dev->mlock);
>+	info->conv_mode = mode;
>+	val = readl(info->regs + VF610_DACx_STATCTRL);
>+	if (mode)
>+		val |= VF610_DAC_LPEN;
>+	else
>+		val &= ~VF610_DAC_LPEN;
>+	writel(val, info->regs + VF610_DACx_STATCTRL);
>+	mutex_unlock(&indio_dev->mlock);
>+
>+	return 0;
>+}
>+
>+static int vf610_get_conversion_mode(struct iio_dev *indio_dev,
>+				const struct iio_chan_spec *chan)
>+{
>+	struct vf610_dac *info = iio_priv(indio_dev);
>+
>+	return info->conv_mode;
>+}
>+
>+static const char * const vf610_conv_modes[] = { "high-power",
>"low-power" };
>+
>+static const struct iio_enum vf610_conversion_mode = {
>+	.items = vf610_conv_modes,
>+	.num_items = ARRAY_SIZE(vf610_conv_modes),
>+	.get = vf610_get_conversion_mode,
>+	.set = vf610_set_conversion_mode,
>+};
>+
>+static const struct iio_chan_spec_ext_info vf610_ext_info[] = {
>+	IIO_ENUM("conversion_mode", IIO_SHARED_BY_DIR,
>+		&vf610_conversion_mode),
>+	{},
>+};
>+
>+#define VF610_DAC_CHAN(_chan_type) { \
>+	.type = (_chan_type), \
>+	.output = 1, \
>+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
>+	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
>+	.ext_info = vf610_ext_info, \
>+}
>+
>+static const struct iio_chan_spec vf610_dac_iio_channels[] = {
>+	VF610_DAC_CHAN(IIO_VOLTAGE),
>+};
>+
>+static int vf610_read_raw(struct iio_dev *indio_dev,
>+			struct iio_chan_spec const *chan,
>+			int *val, int *val2,
>+			long mask)
>+{
>+	struct vf610_dac *info = iio_priv(indio_dev);
>+
>+	switch (mask) {
>+	case IIO_CHAN_INFO_RAW:
>+		*val = VF610_DAC_DAT0(readl(info->regs));
>+		return IIO_VAL_INT;
>+	case IIO_CHAN_INFO_SCALE:
>+		/*
>+		 * DACRFS is always 1 for valid reference and typical
>+		 * reference voltage as per Vybrid datasheet is 3.3V
>+		 * from section 9.1.2.1 of Vybrid datasheet
>+		 */
>+		*val = 3300 /* mV */;
>+		*val2 = 12;
>+		return IIO_VAL_FRACTIONAL_LOG2;
>+
>+	default:
>+		return -EINVAL;
>+	}
>+}
>+
>+static int vf610_write_raw(struct iio_dev *indio_dev,
>+			struct iio_chan_spec const *chan,
>+			int val, int val2,
>+			long mask)
>+{
>+	struct vf610_dac *info = iio_priv(indio_dev);
>+
>+	switch (mask) {
>+	case IIO_CHAN_INFO_RAW:
>+		mutex_lock(&indio_dev->mlock);
>+		writel(VF610_DAC_DAT0(val), info->regs);
>+		mutex_unlock(&indio_dev->mlock);
>+		return 0;
>+
>+	default:
>+		return -EINVAL;
>+	}
>+}
>+
>+static const struct iio_info vf610_dac_iio_info = {
>+	.driver_module = THIS_MODULE,
>+	.read_raw = &vf610_read_raw,
>+	.write_raw = &vf610_write_raw,
>+};
>+
>+static const struct of_device_id vf610_dac_match[] = {
>+	{ .compatible = "fsl,vf610-dac", },
>+	{ /* sentinel */ }
>+};
>+MODULE_DEVICE_TABLE(of, vf610_dac_match);
>+
>+static int vf610_dac_probe(struct platform_device *pdev)
>+{
>+	struct iio_dev *indio_dev;
>+	struct vf610_dac *info;
>+	struct resource *mem;
>+	int ret;
>+
>+	indio_dev = devm_iio_device_alloc(&pdev->dev,
>+					sizeof(struct vf610_dac));
>+	if (!indio_dev) {
>+		dev_err(&pdev->dev, "Failed allocating iio device\n");
>+		return -ENOMEM;
>+	}
>+
>+	info = iio_priv(indio_dev);
>+	info->dev = &pdev->dev;
>+
>+	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>+	info->regs = devm_ioremap_resource(&pdev->dev, mem);
>+	if (IS_ERR(info->regs))
>+		return PTR_ERR(info->regs);
>+
>+	info->clk = devm_clk_get(&pdev->dev, "dac");
>+	if (IS_ERR(info->clk)) {
>+		dev_err(&pdev->dev, "Failed getting clock, err = %ld\n",
>+			PTR_ERR(info->clk));
>+		return PTR_ERR(info->clk);
>+	}
>+
>+	platform_set_drvdata(pdev, indio_dev);
>+
>+	indio_dev->name = dev_name(&pdev->dev);
>+	indio_dev->dev.parent = &pdev->dev;
>+	indio_dev->dev.of_node = pdev->dev.of_node;
>+	indio_dev->info = &vf610_dac_iio_info;
>+	indio_dev->modes = INDIO_DIRECT_MODE;
>+	indio_dev->channels = vf610_dac_iio_channels;
>+	indio_dev->num_channels = ARRAY_SIZE(vf610_dac_iio_channels);
>+
>+	ret = clk_prepare_enable(info->clk);
>+	if (ret) {
>+		dev_err(&pdev->dev,
>+			"Could not prepare or enable the clock\n");
>+		return ret;
>+	}
>+
>+	vf610_dac_init(info);
>+
>+	ret = iio_device_register(indio_dev);
>+	if (ret) {
>+		dev_err(&pdev->dev, "Couldn't register the device\n");
>+		goto error_iio_device_register;
>+	}
>+
>+	return 0;
>+
>+error_iio_device_register:
>+	clk_disable_unprepare(info->clk);
>+
>+	return ret;
>+}
>+
>+static int vf610_dac_remove(struct platform_device *pdev)
>+{
>+	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>+	struct vf610_dac *info = iio_priv(indio_dev);
>+
>+	vf610_dac_exit(info);
Should be reverse order of probe so exit after the unregister below.
Right now you are disabling the hardware before removing the userspace interfaces.
>+	iio_device_unregister(indio_dev);
>+	clk_disable_unprepare(info->clk);
>+
>+	return 0;
>+}
>+
>+#ifdef CONFIG_PM_SLEEP
>+static int vf610_dac_suspend(struct device *dev)
>+{
>+	struct iio_dev *indio_dev = dev_get_drvdata(dev);
>+	struct vf610_dac *info = iio_priv(indio_dev);
>+
>+	vf610_dac_exit(info);
>+	clk_disable_unprepare(info->clk);
>+
>+	return 0;
>+}
>+
>+static int vf610_dac_resume(struct device *dev)
>+{
>+	struct iio_dev *indio_dev = dev_get_drvdata(dev);
>+	struct vf610_dac *info = iio_priv(indio_dev);
>+	int ret;
>+
>+	ret = clk_prepare_enable(info->clk);
>+	if (ret)
>+		return ret;
>+
>+	vf610_dac_init(info);
>+
>+	return 0;
>+}
>+#endif
>+
>+static SIMPLE_DEV_PM_OPS(vf610_dac_pm_ops, vf610_dac_suspend,
>vf610_dac_resume);
>+
>+static struct platform_driver vf610_dac_driver = {
>+	.probe          = vf610_dac_probe,
>+	.remove         = vf610_dac_remove,
>+	.driver         = {
>+		.name   = "vf610-dac",
>+		.of_match_table = vf610_dac_match,
>+		.pm     = &vf610_dac_pm_ops,
>+	},
>+};
>+module_platform_driver(vf610_dac_driver);
>+
>+MODULE_AUTHOR("Sanchayan Maity <sanchayan.maity at toradex.com");
>+MODULE_DESCRIPTION("Freescale VF610 DAC driver");
>+MODULE_LICENSE("GPL v2");

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


From maxime.ripard at free-electrons.com  Sun Feb 21 09:18:30 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sun, 21 Feb 2016 09:18:30 -0800
Subject: [PATCH v3] Fix sun7i pin assignment for IRQ's
In-Reply-To: <1456060845-20692-1-git-send-email-henry@nitronetworks.nl>
References: <1456060845-20692-1-git-send-email-henry@nitronetworks.nl>
Message-ID: <20160221171830.GD19169@lukather>

Hi,

On Sun, Feb 21, 2016 at 02:20:41PM +0100, Henry Paulissen wrote:
> After testing IRQ pins we found some bugs in the pinctrl declaration.

Your commit log is going to need some work. Which bugs? What tests did
you make? Why are you making these changes while the datasheet says
otherwise?

> Signed-off-by: Henry Paulissen <henry at nitronetworks.nl>
> ---
> 
> Changes in v2:
>     After some more testing we found irq on PI pins.
>     they where on mux6 so this is included in my patch.
> 
>     Also included is a warning for PI17, this pin was not working
>     on apritzel his bPI and he thinks it might be correlated to
>     GIC and IRQ 29.
> 
> Changes in v3:
>     Changed name from nickname to realname in email and SoB.
> ---
>  drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c | 25 +++++++++++--------------
>  1 file changed, 11 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
> index cf1ce0c..0fe173e 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
> @@ -344,25 +344,21 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE4 */
>  		  SUNXI_FUNCTION(0x3, "spi2"),		/* CS0 */
> -		  SUNXI_FUNCTION_IRQ(0x6, 12)),		/* EINT12 */

Have you tried to compile it?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160221/485c87f8/attachment.sig>

From ivo.g.dimitrov.75 at gmail.com  Sun Feb 21 09:49:30 2016
From: ivo.g.dimitrov.75 at gmail.com (Ivaylo Dimitrov)
Date: Sun, 21 Feb 2016 19:49:30 +0200
Subject: [PATCH] ARM: dts: omap3-n900: Allow gpio keys to be disabled
In-Reply-To: <20160212215326.GD19432@atomide.com>
References: <1452447990-22775-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
 <20160212215326.GD19432@atomide.com>
Message-ID: <56C9F8AA.9080503@gmail.com>



On 12.02.2016 23:53, Tony Lindgren wrote:
>
> Looks like this no longer applies because of linux,can-disable
> to wakeup-source changes. Can you please update against v4.5-rc
> series and repost?

Could you elaborate on that? As I don't really understand what needs to 
be updated and what are "wakeup-source changes".

Thanks,
Ivo


From ivo.g.dimitrov.75 at gmail.com  Sun Feb 21 10:13:55 2016
From: ivo.g.dimitrov.75 at gmail.com (Ivaylo Dimitrov)
Date: Sun, 21 Feb 2016 20:13:55 +0200
Subject: [PATCH] ARM: OMAP2+: Fix onenand initialization to avoid
 filesystem corruption
In-Reply-To: <20160211001220.GM19432@atomide.com>
References: <linux-kernel@vger.kernel.org>
 <1454683028-4193-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
 <20160208193644.GU19432@atomide.com>
 <20160210211226.GB1640@darkstar.musicnaut.iki.fi>
 <20160211001220.GM19432@atomide.com>
Message-ID: <56C9FE63.3070602@gmail.com>

Hi,

On 11.02.2016 02:12, Tony Lindgren wrote:
>
> Also.. There's a chance somebody has created a onenand file system
> with recent mainline kernels that did the reset and disabled ECC.
> So with Ivaylo's patch fixing that, those may not mount properly
> any longer. Most likely people just keep their maemo rootfs there
> though with the MMC being available.

I guess this is possible, but what worries me more is that the longer 
the patch is not pushed, the higher the chance somebody to end-up with 
broken rootfs. Wouldn't it be better to push it, thus preventing that 
happening?

BTW the differences for N9/50 come from ONENAND_SYS_CFG1_HF bit and 
ONENAND_SYS_CFG1_BRL_6 vs ONENAND_SYS_CFG1_BRL_4. Both are changed 
(later in the code) anyway, so I guess it is safe to reset them to 
default values.

Or, maybe the correct fix is to issue RESET command to onenand 
controller after GPMC reset? RESET command is supposed to put all the 
bits to their default values.

Ivo.


From wens at csie.org  Sun Feb 21 10:29:54 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Sun, 21 Feb 2016 10:29:54 -0800
Subject: [PATCH] pinctrl: sunxi: Add missing H3 R_PIO binding documentation
In-Reply-To: <20160218194931.GA16393@box2.japko.eu>
References: <CACRpkdbfNeh7_=3ReQtJc7OxkkQEn+BUhZ0O0SKnFsRD=WZiUQ@mail.gmail.com>
 <20160218194931.GA16393@box2.japko.eu>
Message-ID: <CAGb2v67Lj1y+c7-NZ_rp=hribjDFxPTBmHoC_o_87OFbCZkaUg@mail.gmail.com>

On Thu, Feb 18, 2016 at 11:49 AM, Krzysztof Adamski <k at japko.eu> wrote:
> allwinner,sun8i-h3-r-pinctrl was added by
> commit ba83a11104ae ("pinctrl: sunxi: Add H3 R_PIO controller support")
> but the patch was missing proper binding documentation. This patch fixes
> this issue.
>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

Acked-by: Chen-Yu Tsai <wens at csie.org>


From aaro.koskinen at iki.fi  Sun Feb 21 10:44:12 2016
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Sun, 21 Feb 2016 20:44:12 +0200
Subject: [PATCH] ARM: OMAP2+: Fix onenand initialization to avoid
 filesystem corruption
In-Reply-To: <1454683028-4193-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
References: <linux-kernel@vger.kernel.org>
 <1454683028-4193-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
Message-ID: <20160221184412.GR1640@darkstar.musicnaut.iki.fi>

Hi,

On Fri, Feb 05, 2016 at 04:37:08PM +0200, Ivaylo Dimitrov wrote:
> Commit <e7b11dc7b77bfce0a351230a5feeadc1d0bba997> ("ARM: OMAP2+: Fix
> onenand rate detection to avoid filesystem corruption") partially fixed
> onenand configuration when GPMC module is reset. Finish the job by also
> providing the correct values in ONENAND_REG_SYS_CFG1 register.
> 
> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com>

I tested this on N950 by creating ubifs file system with stock kernel,
then reading & writing to it with mainline kernel, and then again
verifying the fs is good with the stock kernel. Note that onenand does
not work properly on N950 at the moment unless ONENAND_HAS_CACHE_PROGRAM
is disabled by patching, but that's an issue unrelated to this patch.

Tested-by: Aaro Koskinen <aaro.koskinen at iki.fi>

A.

> ---
>  arch/arm/mach-omap2/gpmc-onenand.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
> index 7b76ce0..8633c70 100644
> --- a/arch/arm/mach-omap2/gpmc-onenand.c
> +++ b/arch/arm/mach-omap2/gpmc-onenand.c
> @@ -101,10 +101,8 @@ static void omap2_onenand_set_async_mode(void __iomem *onenand_base)
>  
>  static void set_onenand_cfg(void __iomem *onenand_base)
>  {
> -	u32 reg;
> +	u32 reg = ONENAND_SYS_CFG1_RDY | ONENAND_SYS_CFG1_INT;
>  
> -	reg = readw(onenand_base + ONENAND_REG_SYS_CFG1);
> -	reg &= ~((0x7 << ONENAND_SYS_CFG1_BRL_SHIFT) | (0x7 << 9));
>  	reg |=	(latency << ONENAND_SYS_CFG1_BRL_SHIFT) |
>  		ONENAND_SYS_CFG1_BL_16;
>  	if (onenand_flags & ONENAND_FLAG_SYNCREAD)
> @@ -123,6 +121,7 @@ static void set_onenand_cfg(void __iomem *onenand_base)
>  		reg |= ONENAND_SYS_CFG1_VHF;
>  	else
>  		reg &= ~ONENAND_SYS_CFG1_VHF;
> +
>  	writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
>  }
>  
> @@ -289,6 +288,7 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base)
>  		}
>  	}
>  
> +	onenand_async.sync_write = true;
>  	omap2_onenand_calc_async_timings(&t);
>  
>  	ret = gpmc_cs_program_settings(gpmc_onenand_data->cs, &onenand_async);
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From sre at kernel.org  Sun Feb 21 11:18:18 2016
From: sre at kernel.org (Sebastian Reichel)
Date: Sun, 21 Feb 2016 20:18:18 +0100
Subject: [PATCH] ARM: dts: omap3-n900: Allow gpio keys to be disabled
In-Reply-To: <56C9F8AA.9080503@gmail.com>
References: <1452447990-22775-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
 <20160212215326.GD19432@atomide.com> <56C9F8AA.9080503@gmail.com>
Message-ID: <20160221191818.GB15242@earth>

Hi Ivo,

On Sun, Feb 21, 2016 at 07:49:30PM +0200, Ivaylo Dimitrov wrote:
> On 12.02.2016 23:53, Tony Lindgren wrote:
> >Looks like this no longer applies because of linux,can-disable
> >to wakeup-source changes. Can you please update against v4.5-rc
> >series and repost?
> 
> Could you elaborate on that? As I don't really understand what needs to be
> updated and what are "wakeup-source changes".

Due to changes in the kernel source  (each gpio key in omap3-n900.dts
gained a "wakeup-source" property) the patch can no longer be applied
using "git am". Just rebase your patch to current 4.5-rc and resend it.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160221/c2614b30/attachment.sig>

From jic23 at kernel.org  Sun Feb 21 11:37:16 2016
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sun, 21 Feb 2016 19:37:16 +0000
Subject: [PATCH v2 2/2] iio: dac: vf610_dac: Add IIO DAC driver for Vybrid
 SoC
In-Reply-To: <02B1DDEF-6BE7-4C4C-AAD0-4EB496734316@kernel.org>
References: <cover.1455516083.git.maitysanchayan@gmail.com>
 <cover.1455516083.git.maitysanchayan@gmail.com>
 <597b39da08c4c1416984cf7e873f56e19975b80e.1455516083.git.maitysanchayan@gmail.com>
 <02B1DDEF-6BE7-4C4C-AAD0-4EB496734316@kernel.org>
Message-ID: <56CA11EC.9030309@kernel.org>

On 21/02/16 16:48, Jonathan Cameron wrote:
> 
> 
> On 15 February 2016 06:42:33 GMT+00:00, Sanchayan Maity <maitysanchayan at gmail.com> wrote:
>> Add driver support for DAC peripheral on Vybrid SoC.
>>
>> Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
>> Acked-by: Rob Herring <robh at kernel.org>
> Ordering is wrong in remove. I may well fix this up and apply later today. 
I also note that the Kconfig dependencies are rather sparse.  Presumably needs
depends on HAS_IOMEM at the very least.  Anyhow, changes are getting less
trivial so I'm  not going to apply this without another revision.

Jonathan
>  Otherwise looks good to me.
>> ---
>> Documentation/ABI/testing/sysfs-bus-iio-vf610      |   9 +
>> .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
>> drivers/iio/dac/Kconfig                            |   8 +
>> drivers/iio/dac/Makefile                           |   1 +
>> drivers/iio/dac/vf610_dac.c                        | 298
>> +++++++++++++++++++++
>> 5 files changed, 336 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>> create mode 100644 drivers/iio/dac/vf610_dac.c
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-vf610
>> b/Documentation/ABI/testing/sysfs-bus-iio-vf610
>> index ecbc1f4..5ea809c 100644
>> --- a/Documentation/ABI/testing/sysfs-bus-iio-vf610
>> +++ b/Documentation/ABI/testing/sysfs-bus-iio-vf610
>> @@ -5,3 +5,12 @@ Description:
>> 		Specifies the hardware conversion mode used. The three
>> 		available modes are "normal", "high-speed" and "low-power",
>> 		where the last is the default mode.
>> +
>> +
>> +What:		/sys/bus/iio/devices/iio:deviceX/out_conversion_mode
>> +KernelVersion:	4.6
>> +Contact:	linux-iio at vger.kernel.org
>> +Description:
>> +		Specifies the hardware conversion mode used within DAC.
>> +		The two available modes are "high-power" and "low-power",
>> +		where "low-power" mode is the default mode.
>> \ No newline at end of file
>> diff --git a/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>> b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>> new file mode 100644
>> index 0000000..20c6c7a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>> @@ -0,0 +1,20 @@
>> +Freescale vf610 Digital to Analog Converter bindings
>> +
>> +The devicetree bindings are for the new DAC driver written for
>> +vf610 SoCs from Freescale.
>> +
>> +Required properties:
>> +- compatible: Should contain "fsl,vf610-dac"
>> +- reg: Offset and length of the register set for the device
>> +- interrupts: Should contain the interrupt for the device
>> +- clocks: The clock is needed by the DAC controller
>> +- clock-names: Must contain "dac" matching entry in the clocks
>> property.
>> +
>> +Example:
>> +dac0: dac at 400cc000 {
>> +	compatible = "fsl,vf610-dac";
>> +	reg = <0x400cc000 0x1000>;
>> +	interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
>> +	clock-names = "dac";
>> +	clocks = <&clks VF610_CLK_DAC0>;
>> +};
>> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
>> index e701e28..8eb0502 100644
>> --- a/drivers/iio/dac/Kconfig
>> +++ b/drivers/iio/dac/Kconfig
>> @@ -196,4 +196,12 @@ config MCP4922
>> 	  To compile this driver as a module, choose M here: the module
>> 	  will be called mcp4922.
>>
>> +config VF610_DAC
>> +	tristate "Vybrid vf610 DAC driver"
>> +	help
>> +	  Say yes here to support Vybrid board digital-to-analog converter.
>> +
>> +	  This driver can also be built as a module. If so, the module will
>> +	  be called vf610_dac.
>> +
>> endmenu
>> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
>> index 63ae056..93feb27 100644
>> --- a/drivers/iio/dac/Makefile
>> +++ b/drivers/iio/dac/Makefile
>> @@ -21,3 +21,4 @@ obj-$(CONFIG_MAX517) += max517.o
>> obj-$(CONFIG_MAX5821) += max5821.o
>> obj-$(CONFIG_MCP4725) += mcp4725.o
>> obj-$(CONFIG_MCP4922) += mcp4922.o
>> +obj-$(CONFIG_VF610_DAC) += vf610_dac.o
>> diff --git a/drivers/iio/dac/vf610_dac.c b/drivers/iio/dac/vf610_dac.c
>> new file mode 100644
>> index 0000000..3f70f96
>> --- /dev/null
>> +++ b/drivers/iio/dac/vf610_dac.c
>> @@ -0,0 +1,298 @@
>> +/*
>> + * Freescale Vybrid vf610 DAC driver
>> + *
>> + * Copyright 2016 Toradex AG
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify
>> + * it under the terms of the GNU General Public License as published
>> by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/err.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/regulator/consumer.h>
>> +#include <linux/slab.h>
>> +
>> +#include <linux/iio/iio.h>
>> +#include <linux/iio/sysfs.h>
>> +
>> +#define VF610_DACx_STATCTRL		0x20
>> +
>> +#define VF610_DAC_DACEN			BIT(15)
>> +#define VF610_DAC_DACRFS		BIT(14)
>> +#define VF610_DAC_LPEN			BIT(11)
>> +
>> +#define VF610_DAC_DAT0(x)		((x) & 0xFFF)
>> +
>> +enum vf610_conversion_mode_sel {
>> +	VF610_DAC_CONV_HIGH_POWER,
>> +	VF610_DAC_CONV_LOW_POWER,
>> +};
>> +
>> +struct vf610_dac {
>> +	struct clk *clk;
>> +	struct device *dev;
>> +	enum vf610_conversion_mode_sel conv_mode;
>> +	void __iomem *regs;
>> +};
>> +
>> +static void vf610_dac_init(struct vf610_dac *info)
>> +{
>> +	int val;
>> +
>> +	info->conv_mode = VF610_DAC_CONV_LOW_POWER;
>> +	val = VF610_DAC_DACEN | VF610_DAC_DACRFS |
>> +		VF610_DAC_LPEN;
>> +	writel(val, info->regs + VF610_DACx_STATCTRL);
>> +}
>> +
>> +static void vf610_dac_exit(struct vf610_dac *info)
>> +{
>> +	int val;
>> +
>> +	val = readl(info->regs + VF610_DACx_STATCTRL);
>> +	val &= ~VF610_DAC_DACEN;
>> +	writel(val, info->regs + VF610_DACx_STATCTRL);
>> +}
>> +
>> +static int vf610_set_conversion_mode(struct iio_dev *indio_dev,
>> +				const struct iio_chan_spec *chan,
>> +				unsigned int mode)
>> +{
>> +	struct vf610_dac *info = iio_priv(indio_dev);
>> +	int val;
>> +
>> +	mutex_lock(&indio_dev->mlock);
>> +	info->conv_mode = mode;
>> +	val = readl(info->regs + VF610_DACx_STATCTRL);
>> +	if (mode)
>> +		val |= VF610_DAC_LPEN;
>> +	else
>> +		val &= ~VF610_DAC_LPEN;
>> +	writel(val, info->regs + VF610_DACx_STATCTRL);
>> +	mutex_unlock(&indio_dev->mlock);
>> +
>> +	return 0;
>> +}
>> +
>> +static int vf610_get_conversion_mode(struct iio_dev *indio_dev,
>> +				const struct iio_chan_spec *chan)
>> +{
>> +	struct vf610_dac *info = iio_priv(indio_dev);
>> +
>> +	return info->conv_mode;
>> +}
>> +
>> +static const char * const vf610_conv_modes[] = { "high-power",
>> "low-power" };
>> +
>> +static const struct iio_enum vf610_conversion_mode = {
>> +	.items = vf610_conv_modes,
>> +	.num_items = ARRAY_SIZE(vf610_conv_modes),
>> +	.get = vf610_get_conversion_mode,
>> +	.set = vf610_set_conversion_mode,
>> +};
>> +
>> +static const struct iio_chan_spec_ext_info vf610_ext_info[] = {
>> +	IIO_ENUM("conversion_mode", IIO_SHARED_BY_DIR,
>> +		&vf610_conversion_mode),
>> +	{},
>> +};
>> +
>> +#define VF610_DAC_CHAN(_chan_type) { \
>> +	.type = (_chan_type), \
>> +	.output = 1, \
>> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
>> +	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
>> +	.ext_info = vf610_ext_info, \
>> +}
>> +
>> +static const struct iio_chan_spec vf610_dac_iio_channels[] = {
>> +	VF610_DAC_CHAN(IIO_VOLTAGE),
>> +};
>> +
>> +static int vf610_read_raw(struct iio_dev *indio_dev,
>> +			struct iio_chan_spec const *chan,
>> +			int *val, int *val2,
>> +			long mask)
>> +{
>> +	struct vf610_dac *info = iio_priv(indio_dev);
>> +
>> +	switch (mask) {
>> +	case IIO_CHAN_INFO_RAW:
>> +		*val = VF610_DAC_DAT0(readl(info->regs));
>> +		return IIO_VAL_INT;
>> +	case IIO_CHAN_INFO_SCALE:
>> +		/*
>> +		 * DACRFS is always 1 for valid reference and typical
>> +		 * reference voltage as per Vybrid datasheet is 3.3V
>> +		 * from section 9.1.2.1 of Vybrid datasheet
>> +		 */
>> +		*val = 3300 /* mV */;
>> +		*val2 = 12;
>> +		return IIO_VAL_FRACTIONAL_LOG2;
>> +
>> +	default:
>> +		return -EINVAL;
>> +	}
>> +}
>> +
>> +static int vf610_write_raw(struct iio_dev *indio_dev,
>> +			struct iio_chan_spec const *chan,
>> +			int val, int val2,
>> +			long mask)
>> +{
>> +	struct vf610_dac *info = iio_priv(indio_dev);
>> +
>> +	switch (mask) {
>> +	case IIO_CHAN_INFO_RAW:
>> +		mutex_lock(&indio_dev->mlock);
>> +		writel(VF610_DAC_DAT0(val), info->regs);
>> +		mutex_unlock(&indio_dev->mlock);
>> +		return 0;
>> +
>> +	default:
>> +		return -EINVAL;
>> +	}
>> +}
>> +
>> +static const struct iio_info vf610_dac_iio_info = {
>> +	.driver_module = THIS_MODULE,
>> +	.read_raw = &vf610_read_raw,
>> +	.write_raw = &vf610_write_raw,
>> +};
>> +
>> +static const struct of_device_id vf610_dac_match[] = {
>> +	{ .compatible = "fsl,vf610-dac", },
>> +	{ /* sentinel */ }
>> +};
>> +MODULE_DEVICE_TABLE(of, vf610_dac_match);
>> +
>> +static int vf610_dac_probe(struct platform_device *pdev)
>> +{
>> +	struct iio_dev *indio_dev;
>> +	struct vf610_dac *info;
>> +	struct resource *mem;
>> +	int ret;
>> +
>> +	indio_dev = devm_iio_device_alloc(&pdev->dev,
>> +					sizeof(struct vf610_dac));
>> +	if (!indio_dev) {
>> +		dev_err(&pdev->dev, "Failed allocating iio device\n");
>> +		return -ENOMEM;
>> +	}
>> +
>> +	info = iio_priv(indio_dev);
>> +	info->dev = &pdev->dev;
>> +
>> +	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +	info->regs = devm_ioremap_resource(&pdev->dev, mem);
>> +	if (IS_ERR(info->regs))
>> +		return PTR_ERR(info->regs);
>> +
>> +	info->clk = devm_clk_get(&pdev->dev, "dac");
>> +	if (IS_ERR(info->clk)) {
>> +		dev_err(&pdev->dev, "Failed getting clock, err = %ld\n",
>> +			PTR_ERR(info->clk));
>> +		return PTR_ERR(info->clk);
>> +	}
>> +
>> +	platform_set_drvdata(pdev, indio_dev);
>> +
>> +	indio_dev->name = dev_name(&pdev->dev);
>> +	indio_dev->dev.parent = &pdev->dev;
>> +	indio_dev->dev.of_node = pdev->dev.of_node;
>> +	indio_dev->info = &vf610_dac_iio_info;
>> +	indio_dev->modes = INDIO_DIRECT_MODE;
>> +	indio_dev->channels = vf610_dac_iio_channels;
>> +	indio_dev->num_channels = ARRAY_SIZE(vf610_dac_iio_channels);
>> +
>> +	ret = clk_prepare_enable(info->clk);
>> +	if (ret) {
>> +		dev_err(&pdev->dev,
>> +			"Could not prepare or enable the clock\n");
>> +		return ret;
>> +	}
>> +
>> +	vf610_dac_init(info);
>> +
>> +	ret = iio_device_register(indio_dev);
>> +	if (ret) {
>> +		dev_err(&pdev->dev, "Couldn't register the device\n");
>> +		goto error_iio_device_register;
>> +	}
>> +
>> +	return 0;
>> +
>> +error_iio_device_register:
>> +	clk_disable_unprepare(info->clk);
>> +
>> +	return ret;
>> +}
>> +
>> +static int vf610_dac_remove(struct platform_device *pdev)
>> +{
>> +	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>> +	struct vf610_dac *info = iio_priv(indio_dev);
>> +
>> +	vf610_dac_exit(info);
> Should be reverse order of probe so exit after the unregister below.
> Right now you are disabling the hardware before removing the userspace interfaces.
>> +	iio_device_unregister(indio_dev);
>> +	clk_disable_unprepare(info->clk);
>> +
>> +	return 0;
>> +}
>> +
>> +#ifdef CONFIG_PM_SLEEP
>> +static int vf610_dac_suspend(struct device *dev)
>> +{
>> +	struct iio_dev *indio_dev = dev_get_drvdata(dev);
>> +	struct vf610_dac *info = iio_priv(indio_dev);
>> +
>> +	vf610_dac_exit(info);
>> +	clk_disable_unprepare(info->clk);
>> +
>> +	return 0;
>> +}
>> +
>> +static int vf610_dac_resume(struct device *dev)
>> +{
>> +	struct iio_dev *indio_dev = dev_get_drvdata(dev);
>> +	struct vf610_dac *info = iio_priv(indio_dev);
>> +	int ret;
>> +
>> +	ret = clk_prepare_enable(info->clk);
>> +	if (ret)
>> +		return ret;
>> +
>> +	vf610_dac_init(info);
>> +
>> +	return 0;
>> +}
>> +#endif
>> +
>> +static SIMPLE_DEV_PM_OPS(vf610_dac_pm_ops, vf610_dac_suspend,
>> vf610_dac_resume);
>> +
>> +static struct platform_driver vf610_dac_driver = {
>> +	.probe          = vf610_dac_probe,
>> +	.remove         = vf610_dac_remove,
>> +	.driver         = {
>> +		.name   = "vf610-dac",
>> +		.of_match_table = vf610_dac_match,
>> +		.pm     = &vf610_dac_pm_ops,
>> +	},
>> +};
>> +module_platform_driver(vf610_dac_driver);
>> +
>> +MODULE_AUTHOR("Sanchayan Maity <sanchayan.maity at toradex.com");
>> +MODULE_DESCRIPTION("Freescale VF610 DAC driver");
>> +MODULE_LICENSE("GPL v2");
> 



From jic23 at kernel.org  Sun Feb 21 11:47:53 2016
From: jic23 at kernel.org (Jonathan Cameron)
Date: Sun, 21 Feb 2016 19:47:53 +0000
Subject: [PATCH v2 5/5] iio: adc: New driver for Cirrus Logic EP93xx ADC
In-Reply-To: <56C8A9AB.7040506@gmail.com>
References: <56C88EDD.3040007@gmail.com> <56C88FCB.30008@gmail.com>
 <56C88FFD.9050504@gmail.com> <56C89024.3060802@gmail.com>
 <56C89056.7070903@gmail.com> <56C8A9AB.7040506@gmail.com>
Message-ID: <56CA1469.70806@kernel.org>

On 20/02/16 18:00, Alexander Sverdlin wrote:
> New driver adding support for ADC found on Cirrus Logic EP93xx series of SoCs.
> Board specific code must take care to create plaform device with all necessary
> resources.
> 
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin at gmail.com>
Looks basically good to me.  A few things that might by convention in IIO
have been slightly different framed, but nothing that matters.

Given the need for the earlier arch related patches, this either needs to
got through the relevant arm-soc trees, or I need an Ack to apply those
through IIO.  I don't mind either way.  One aside though - is there anything
preventing us have this build with COMPILE_TEST as an alternative to the arch
dependency?  If not then adding that would be good to improve build test
coverage.  Note that you will probably need to check dependencies on one or
two things if you do that (HAS_IOMEM I would think for starters) which are
implicitly brought in otherwise by the ARCH dependency.

Should it go through the relevant arch trees then feel free to add.

Acked-by: Jonathan Cameron <jic23 at kernel.org>

Thanks,

Jonathan
> ---
>  Documentation/iio/ep93xx_adc.txt |  29 +++++
>  drivers/iio/adc/Kconfig          |  11 ++
>  drivers/iio/adc/Makefile         |   1 +
>  drivers/iio/adc/ep93xx_adc.c     | 261 +++++++++++++++++++++++++++++++++++++++
>  4 files changed, 302 insertions(+)
>  create mode 100644 Documentation/iio/ep93xx_adc.txt
>  create mode 100644 drivers/iio/adc/ep93xx_adc.c
> 
> diff --git a/Documentation/iio/ep93xx_adc.txt b/Documentation/iio/ep93xx_adc.txt
> new file mode 100644
> index 0000000..321e59f
> --- /dev/null
> +++ b/Documentation/iio/ep93xx_adc.txt
> @@ -0,0 +1,29 @@
> +Cirrus Logic EP93xx ADC driver.
> +
> +1. Overview
> +
> +The driver is intended to work on both low-end (EP9301, EP9302) devices with
> +5-channel ADC and high-end (EP9307, EP9312, EP9315) devices with 10-channel
> +touchscreen/ADC module.
> +
> +2. Channel numbering
> +
> +Numbering scheme for channels 0..4 is defined in EP9301 and EP9302 datasheets.
> +EP9307, EP9312 and EP9312 have 3 channels more (total 8), but the numbering is
> +not defined. So the last three are numbered randomly, let's say.
> +
> +Assuming ep93xx_adc is IIO device0, you'd find following entries under
> +/sys/bus/iio/devices/iio:device0/:
> +
> +  +-----------------+---------------+
> +  | sysfs entry     | ball/pin name |
> +  +-----------------+---------------+
> +  | in_voltage0_raw | YM            |
> +  | in_voltage1_raw | SXP           |
> +  | in_voltage2_raw | SXM           |
> +  | in_voltage3_raw | SYP           |
> +  | in_voltage4_raw | SYM           |
> +  | in_voltage5_raw | XP            |
> +  | in_voltage6_raw | XM            |
> +  | in_voltage7_raw | YP            |
> +  +-----------------+---------------+
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 283ded7..0482f29 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -172,6 +172,17 @@ config DA9150_GPADC
>  	  To compile this driver as a module, choose M here: the module will be
>  	  called berlin2-adc.
> 
> +config EP93XX_ADC
> +	tristate "Cirrus Logic EP93XX ADC driver"
> +	depends on ARCH_EP93XX
> +	help
> +	  Driver for the ADC module on the EP93XX series of SoC from Cirrus Logic.
> +	  It's recommended to switch on CONFIG_HIGH_RES_TIMERS option, in this
> +	  case driver will reduce its CPU usage by 90% in some use cases.
> +
> +	  To compile this driver as a module, choose M here: the module will be
> +	  called ep93xx_adc.
> +
>  config EXYNOS_ADC
>  	tristate "Exynos ADC driver support"
>  	depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || (OF && COMPILE_TEST)
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 6435780..cd7d33e 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
>  obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
>  obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
> +obj-$(CONFIG_EP93XX_ADC) += ep93xx_adc.o
>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>  obj-$(CONFIG_HI8435) += hi8435.o
>  obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
> diff --git a/drivers/iio/adc/ep93xx_adc.c b/drivers/iio/adc/ep93xx_adc.c
> new file mode 100644
> index 0000000..3728591
> --- /dev/null
> +++ b/drivers/iio/adc/ep93xx_adc.c
> @@ -0,0 +1,261 @@
> +/*
> + * Driver for ADC module on the Cirrus Logic EP93xx series of SoCs
> + *
> + * Copyright (C) 2015 Alexander Sverdlin
> + *
> + * 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.
> + *
> + * The driver uses polling to get the conversion status. According to EP93xx
> + * datasheets, reading ADCResult register starts the conversion, but user is also
> + * responsible for ensuring that delay between adjacent conversion triggers is
> + * long enough so that maximum allowed conversion rate is not exceeded. This
> + * basically renders IRQ mode unusable.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/iio/iio.h>
> +#include <linux/io.h>
> +#include <linux/irqflags.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/platform_device.h>
> +
> +#define EP93XX_NUM_CHANNELS 8
> +
> +/*
> + * This code could benefit from real HR Timers, but jiffy granularity would
> + * lower ADC conversion rate down to CONFIG_HZ, so we fallback to busy wait
> + * in such case.
> + *
> + * HR Timers-based version loads CPU only up to 10% during back to back ADC
> + * conversion, while busy wait-based version consumes whole CPU power.
> + */
> +#ifdef CONFIG_HIGH_RES_TIMERS
> +#define ep93xx_adc_delay(usmin, usmax) usleep_range(usmin, usmax)
> +#else
> +#define ep93xx_adc_delay(usmin, usmax) udelay(usmin)
> +#endif
> +
> +#define EP93XX_ADC_RESULT	0x08
> +#define   EP93XX_ADC_SDR	BIT(31)
> +#define EP93XX_ADC_SWITCH	0x18
> +#define EP93XX_ADC_SW_LOCK	0x20
> +#define EP93XX_ADC_INT_EN	0x24
> +#define   EP93XX_ADC_RINTEN	BIT(11)
> +
> +struct ep93xx_adc_priv {
> +	struct clk *clk;
> +	void __iomem *base;
> +	int lastch;
> +	struct mutex lock;
> +};
> +
> +#define EP93XX_ADC_CH(index, dname, swcfg) {			\
> +	.type = IIO_VOLTAGE,					\
> +	.indexed = 1,						\
> +	.channel = index,					\
> +	.address = swcfg,					\
> +	.datasheet_name = dname,				\
> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),		\
> +	.info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE) |	\
> +				   BIT(IIO_CHAN_INFO_OFFSET),	\
> +}
> +
> +/*
> + * Numbering scheme for channels 0..4 is defined in EP9301 and EP9302 datasheets.
> + * EP9307, EP9312 and EP9312 have 3 channels more (total 8), but the numbering is
> + * not defined. So the last three are numbered randomly, let's say.
> + */
> +static const struct iio_chan_spec ep93xx_adc_channels[EP93XX_NUM_CHANNELS] = {
> +	EP93XX_ADC_CH(0, "YM",	0x608),
> +	EP93XX_ADC_CH(1, "SXP",	0x680),
> +	EP93XX_ADC_CH(2, "SXM",	0x640),
> +	EP93XX_ADC_CH(3, "SYP",	0x620),
> +	EP93XX_ADC_CH(4, "SYM",	0x610),
> +	EP93XX_ADC_CH(5, "XP",	0x601),
> +	EP93XX_ADC_CH(6, "XM",	0x602),
> +	EP93XX_ADC_CH(7, "YP",	0x604),
> +};
> +
> +static int ep93xx_read_raw(struct iio_dev *iiodev,
> +			   struct iio_chan_spec const *channel, int *value,
> +			   int *shift, long mask)
> +{
> +	struct ep93xx_adc_priv *priv = iio_priv(iiodev);
> +	unsigned long timeout;
> +	int ret;
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_RAW:
> +		mutex_lock(&priv->lock);
> +		if (priv->lastch != channel->channel) {
> +			priv->lastch = channel->channel;
> +			/*
> +			 * Switch register is software-locked, unlocking must be
> +			 * immediately followed by write
> +			 */
> +			local_irq_disable();
> +			writel_relaxed(0xAA, priv->base + EP93XX_ADC_SW_LOCK);
> +			writel_relaxed(channel->address,
> +				       priv->base + EP93XX_ADC_SWITCH);
> +			local_irq_enable();
> +			/*
> +			 * Settling delay depends on module clock and could be
> +			 * 2ms or 500us
> +			 */
> +			ep93xx_adc_delay(2000, 2000);
> +		}
> +		/* Start the conversion, eventually discarding old result */
> +		readl_relaxed(priv->base + EP93XX_ADC_RESULT);
> +		/* Ensure maximun conversion rate is not exceeded */
> +		ep93xx_adc_delay(DIV_ROUND_UP(1000000, 925),
> +				 DIV_ROUND_UP(1000000, 925));
> +		/* At this point conversion must be completed, but anyway... */
> +		ret = IIO_VAL_INT;
> +		timeout = jiffies + msecs_to_jiffies(1) + 1;
> +		while (1) {
> +			u32 t;
> +
> +			t = readl_relaxed(priv->base + EP93XX_ADC_RESULT);
> +			if (t & EP93XX_ADC_SDR) {
> +				/* Sign extend lower 16 bits */
> +				*value = (s16)t;
> +				break;
> +			}
> +
> +			if (time_after(jiffies, timeout)) {
> +				dev_err(&iiodev->dev, "Conversion timeout\n");
> +				ret = -ETIMEDOUT;
> +				break;
> +			}
> +
> +			cpu_relax();
> +		}
> +		mutex_unlock(&priv->lock);
> +		return ret;
> +
> +	case IIO_CHAN_INFO_OFFSET:
> +		/* According to datasheet, range is -25000..25000 */
> +		*value = 25000;
> +		return IIO_VAL_INT;
> +
> +	case IIO_CHAN_INFO_SCALE:
> +		/* Typical supply voltage is 3.3v */
> +		*value = (1ULL << 32) * 3300 / 50000;
> +		*shift = 32;
> +		return IIO_VAL_FRACTIONAL_LOG2;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static const struct iio_info ep93xx_adc_info = {
> +	.driver_module = THIS_MODULE,
> +	.read_raw = ep93xx_read_raw,
> +};
> +
> +static int ep93xx_adc_probe(struct platform_device *pdev)
> +{
> +	int ret;
> +	struct iio_dev *iiodev;
> +	struct ep93xx_adc_priv *priv;
> +	struct clk *pclk;
> +	struct resource *res;
> +
> +	iiodev = devm_iio_device_alloc(&pdev->dev,
> +				       sizeof(struct ep93xx_adc_priv));
slight preference for sizeof(*priv)
> +	if (!iiodev)
> +		return -ENOMEM;
> +	priv = iio_priv(iiodev);
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res) {
> +		dev_err(&pdev->dev, "Cannot obtain memory resource\n");
> +		return -ENXIO;
> +	}
> +	priv->base = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(priv->base)) {
> +		dev_err(&pdev->dev, "Cannot map memory resource\n");
> +		return PTR_ERR(priv->base);
> +	}
> +
> +	iiodev->dev.parent = &pdev->dev;
> +	iiodev->name = dev_name(&pdev->dev);
> +	iiodev->modes = INDIO_DIRECT_MODE;
> +	iiodev->info = &ep93xx_adc_info;
> +	iiodev->num_channels = ARRAY_SIZE(ep93xx_adc_channels);
> +	iiodev->channels = ep93xx_adc_channels;
> +
> +	priv->lastch = -1;
> +	mutex_init(&priv->lock);
> +
> +	platform_set_drvdata(pdev, iiodev);
> +
> +	priv->clk = devm_clk_get(&pdev->dev, NULL);
> +	if (IS_ERR(priv->clk)) {
> +		dev_err(&pdev->dev, "Cannot obtain clock\n");
> +		return PTR_ERR(priv->clk);
> +	}
> +
> +	pclk = clk_get_parent(priv->clk);
> +	if (!pclk) {
> +		dev_warn(&pdev->dev, "Cannot obtain parent clock\n");
> +	} else {
> +		/*
> +		 * This is actually a place for improvement:
> +		 * EP93xx ADC supports two clock divisors -- 4 and 16,
> +		 * resulting in conversion rates 3750 and 925 samples per second
> +		 * respectively with 500uS or 2ms settling time respectively.
> +		 * One might find this interesting enough to be configurable.
> +		 */
> +		ret = clk_set_rate(priv->clk, clk_get_rate(pclk) / 16);
> +		if (ret)
> +			dev_warn(&pdev->dev, "Cannot set clock rate\n");
> +		/*
> +		 * We can tolerate rate setting failure because the module should
> +		 * work in any case.
> +		 */
> +	}
> +
> +	ret = clk_enable(priv->clk);
> +	if (ret) {
> +		dev_err(&pdev->dev, "Cannot enable clock\n");
> +		return ret;
> +	}
> +
> +	ret = iio_device_register(iiodev);
> +	if (ret)
> +		clk_disable(priv->clk);
> +
> +	return ret;
> +}
> +
> +static int ep93xx_adc_remove(struct platform_device *pdev)
> +{
> +	struct iio_dev *iiodev = platform_get_drvdata(pdev);
> +	struct ep93xx_adc_priv *priv = iio_priv(iiodev);
> +
> +	iio_device_unregister(iiodev);
> +	clk_disable(priv->clk);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver ep93xx_adc_driver = {
> +	.driver = {
> +		.name = "ep93xx-adc",
> +	},
> +	.probe = ep93xx_adc_probe,
> +	.remove = ep93xx_adc_remove,
> +};
> +module_platform_driver(ep93xx_adc_driver);
> +
> +MODULE_AUTHOR("Alexander Sverdlin <alexander.sverdlin at gmail.com>");
> +MODULE_DESCRIPTION("Cirrus Logic EP93XX ADC driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:ep93xx-adc");
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



From andrew at lunn.ch  Sun Feb 21 11:51:54 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Sun, 21 Feb 2016 20:51:54 +0100
Subject: [PATCH] ARM: dts: vf610-zii-dev: Add ZII development board.
Message-ID: <1456084314-9871-1-git-send-email-andrew@lunn.ch>

From: Cory Tusar <cory.tusar at pid1solutions.com>

This commit adds support for Rev. B of a Zodiac Inflight Innovations
development board, mainly intended for DSA and ARINC 429 development
work.

Signed-off-by: Cory Tusar <cory.tusar at pid1solutions.com>
Signed-off-by: Andrew Lunn <andrew at lunn.ch>
---
 arch/arm/boot/dts/Makefile                |   3 +-
 arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 683 ++++++++++++++++++++++++++++++
 2 files changed, 685 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/vf610-zii-dev-rev-b.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70e8b26..47c4c2ff41de 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -372,7 +372,8 @@ dtb-$(CONFIG_SOC_VF610) += \
 	vf610m4-colibri.dtb \
 	vf610-cosmic.dtb \
 	vf610m4-cosmic.dtb \
-	vf610-twr.dtb
+	vf610-twr.dtb \
+	vf610-zii-dev-rev-b.dtb
 dtb-$(CONFIG_ARCH_MXS) += \
 	imx23-evk.dtb \
 	imx23-olinuxino.dtb \
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
new file mode 100644
index 000000000000..fafe0039ebce
--- /dev/null
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -0,0 +1,683 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+/dts-v1/;
+#include "vf610.dtsi"
+
+/ {
+	model = "ZII VF610 Development Board, Rev B";
+	compatible = "zii,vf610dev-b", "zii,vf610dev", "fsl,vf610";
+
+	chosen {
+		bootargs = "console=ttyLP0,115200n8";
+		stdout-path = &uart0;
+	};
+
+	memory {
+		reg = <0x80000000 0x8000000>;
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+		pinctrl-0 = <&pinctrl_leds_debug>;
+		pinctrl-names = "default";
+
+		debug_1 {
+			label = "zii:green:debug1";
+			gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	mdio-mux {
+		compatible = "mdio-mux-gpio";
+		pinctrl-0 = <&pinctrl_mdio_mux>;
+		pinctrl-names = "default";
+		gpios = <&gpio0 8  GPIO_ACTIVE_HIGH
+			 &gpio0 9  GPIO_ACTIVE_HIGH
+			 &gpio0 24 GPIO_ACTIVE_HIGH
+			 &gpio0 25 GPIO_ACTIVE_HIGH>;
+		mdio-parent-bus = <&mdio1>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		mdio_mux_1: mdio at 1 {
+			reg = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mdio_mux_2: mdio at 2 {
+			reg = <2>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mdio_mux_4: mdio at 4 {
+			reg = <4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mdio_mux_8: mdio at 8 {
+			reg = <8>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
+	dsa at 0 {
+		compatible = "marvell,dsa";
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		dsa,ethernet = <&fec1>;
+		dsa,mii-bus = <&mdio_mux_1>;
+
+		/* 6352 - Primary - 7 ports */
+		switch0: switch at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x00 0>;
+			eeprom-length = <512>;
+
+			port at 0 {
+				reg = <0>;
+				label = "lan0";
+			};
+
+			port at 1 {
+				reg = <1>;
+				label = "lan1";
+			};
+
+			port at 2 {
+				reg = <2>;
+				label = "lan2";
+			};
+
+			switch0port5: port at 5 {
+				reg = <5>;
+				label = "dsa";
+				phy-mode = "rgmii-txid";
+				link = <&switch1port6
+					&switch2port9>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+
+			port at 6 {
+				reg = <6>;
+				label = "cpu";
+				fixed-link {
+					speed = <100>;
+					full-duplex;
+				};
+			};
+
+		};
+
+		/* 6352 - Secondary - 7 ports */
+		switch1: switch at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x00 1>;
+			eeprom-length = <512>;
+			mii-bus = <&mdio_mux_2>;
+
+			port at 0 {
+				reg = <0>;
+				label = "lan3";
+			};
+
+			port at 1 {
+				reg = <1>;
+				label = "lan4";
+			};
+
+			port at 2 {
+				reg = <2>;
+				label = "lan5";
+			};
+
+			switch1port5: port at 5 {
+				reg = <5>;
+				label = "dsa";
+				link = <&switch2port9>;
+				phy-mode = "rgmii-txid";
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+
+			switch1port6: port at 6 {
+				reg = <6>;
+				label = "dsa";
+				phy-mode = "rgmii-txid";
+				link = <&switch0port5>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+
+		/* 6185 - 10 ports */
+		switch2: switch at 6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x00 2>;
+			mii-bus = <&mdio_mux_4>;
+
+			port at 0 {
+				reg = <0>;
+				label = "lan6";
+			};
+
+			port at 1 {
+				reg = <1>;
+				label = "lan7";
+			};
+
+			port at 2 {
+				reg = <2>;
+				label = "lan8";
+			};
+
+			port at 3 {
+				reg = <3>;
+				label = "optical3";
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+					link-gpios = <&gpio6 2
+						      GPIO_ACTIVE_HIGH>;
+				};
+			};
+
+			port at 4 {
+				reg = <4>;
+				label = "optical4";
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+					link-gpios = <&gpio6 3
+						      GPIO_ACTIVE_HIGH>;
+				};
+			};
+
+			switch2port9: port at 9 {
+				reg = <9>;
+				label = "dsa";
+				phy-mode = "rgmii-txid";
+				link = <&switch1port5
+					&switch0port5>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+	};
+
+	audio_ext: mclk-osc {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24576000>;
+	};
+
+	enet_ext: eth-osc {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <50000000>;
+	};
+
+	reg_3p3v: regulator at 0 {
+		compatible = "regulator-fixed";
+		regulator-name = "3P3V";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+	};
+
+	reg_vcc_3v3_mcu: regulator at 1 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_3v3_mcu";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
+
+	usb0_vbus: regulator at 2 {
+		compatible = "regulator-fixed";
+		pinctrl-0 = <&pinctrl_usb_vbus>;
+		regulator-name = "usb_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		regulator-always-on;
+		regulator-boot-on;
+		gpio = <&gpio0 6 0>;
+	};
+};
+
+&fec0 {
+	phy-mode = "rmii";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec0>;
+	status = "okay";
+};
+
+&fec1 {
+	phy-mode = "rmii";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec1>;
+	status = "okay";
+
+	fixed-link {
+		   speed = <100>;
+		   full-duplex;
+	};
+
+	mdio1: mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "okay";
+	};
+};
+
+&adc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_adc0_ad5>;
+	vref-supply = <&reg_vcc_3v3_mcu>;
+	status = "okay";
+};
+
+&edma0 {
+	status = "okay";
+};
+
+&esdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_esdhc1>;
+	bus-width = <4>;
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c0>;
+	status = "okay";
+
+	gpio5: pca9505 at 20 {
+		compatible = "nxp,pca9554";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+
+	};
+
+	gpio6: pca9505 at 22 {
+		compatible = "nxp,pca9554";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pca9554_opt>;
+		reg = <0x22>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+	};
+
+	lm75 at 48 {
+		compatible = "national,lm75";
+		reg = <0x48>;
+	};
+
+	at24c04 at 50 {
+		compatible = "atmel,24c04";
+		reg = <0x50>;
+	};
+
+	at24c04 at 52 {
+		compatible = "atmel,24c04";
+		reg = <0x52>;
+	};
+
+	ds1682 at 6b {
+		compatible = "dallas,ds1682";
+		reg = <0x6b>;
+	};
+};
+
+&i2c1 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1>;
+	status = "okay";
+};
+
+&i2c2 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+
+	tca9548 at 70 {
+		compatible = "nxp,pca9548";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+		reset-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
+
+		i2c2_0: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+
+			sfp1: at24c04 at 50 {
+				compatible = "atmel,24c02";
+				reg = <0x50>;
+			};
+		};
+
+		i2c2_1: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+
+			sfp2: at24c04 at 50 {
+				compatible = "atmel,24c02";
+				reg = <0x50>;
+			};
+		};
+
+		i2c2_2: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+
+			sfp3: at24c04 at 50 {
+				compatible = "atmel,24c02";
+				reg = <0x50>;
+			};
+		};
+
+		i2c2_3:	 i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+
+			sfp4: at24c04 at 50 {
+				compatible = "atmel,24c02";
+				reg = <0x50>;
+			};
+
+		};
+
+		i2c2_4: i2c at 4 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <4>;
+		};
+	};
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c_mux_reset>;
+
+	vf610-zii {
+		pinctrl_usb_vbus: pinctrl-usb-vbus {
+			fsl,pins = <
+				VF610_PAD_PTA16__GPIO_6	0x31c2
+			>;
+		};
+
+		pinctrl_i2c_mux_reset: pinctrl-i2c-mux-reset {
+			fsl,pins = <
+				 VF610_PAD_PTE14__GPIO_119	0x31c2
+				 >;
+		};
+
+		pinctrl_adc0_ad5: adc0ad5grp {
+			fsl,pins = <
+				VF610_PAD_PTC30__ADC0_SE5	0x00a1
+			>;
+		};
+
+		pinctrl_esdhc1: esdhc1grp {
+			fsl,pins = <
+				VF610_PAD_PTA24__ESDHC1_CLK	0x31ef
+				VF610_PAD_PTA25__ESDHC1_CMD	0x31ef
+				VF610_PAD_PTA26__ESDHC1_DAT0	0x31ef
+				VF610_PAD_PTA27__ESDHC1_DAT1	0x31ef
+				VF610_PAD_PTA28__ESDHC1_DATA2	0x31ef
+				VF610_PAD_PTA29__ESDHC1_DAT3	0x31ef
+				VF610_PAD_PTA7__GPIO_134	0x219d
+			>;
+		};
+
+		pinctrl_fec1: fec1grp {
+			fsl,pins = <
+				VF610_PAD_PTA6__RMII_CLKIN		0x30d1
+				VF610_PAD_PTC9__ENET_RMII1_MDC		0x30d2
+				VF610_PAD_PTC10__ENET_RMII1_MDIO	0x30d3
+				VF610_PAD_PTC11__ENET_RMII1_CRS		0x30d1
+				VF610_PAD_PTC12__ENET_RMII1_RXD1	0x30d1
+				VF610_PAD_PTC13__ENET_RMII1_RXD0	0x30d1
+				VF610_PAD_PTC14__ENET_RMII1_RXER	0x30d1
+				VF610_PAD_PTC15__ENET_RMII1_TXD1	0x30d2
+				VF610_PAD_PTC16__ENET_RMII1_TXD0	0x30d2
+				VF610_PAD_PTC17__ENET_RMII1_TXEN	0x30d2
+			>;
+		};
+
+		pinctrl_i2c0: i2c0grp {
+			fsl,pins = <
+				VF610_PAD_PTB14__I2C0_SCL	0x37ff
+				VF610_PAD_PTB15__I2C0_SDA	0x37ff
+			>;
+		};
+
+		pinctrl_i2c1: i2c1grp {
+			fsl,pins = <
+				VF610_PAD_PTB16__I2C1_SCL	0x37ff
+				VF610_PAD_PTB17__I2C1_SDA	0x37ff
+			>;
+		};
+
+		pinctrl_i2c2: i2c2grp {
+			fsl,pins = <
+				VF610_PAD_PTA22__I2C2_SCL	0x37ff
+				VF610_PAD_PTA23__I2C2_SDA	0x37ff
+			>;
+		};
+
+		pinctrl_i2c3: i2c3grp {
+			fsl,pins = <
+				VF610_PAD_PTA30__I2C3_SCL	0x37ff
+				VF610_PAD_PTA31__I2C3_SDA	0x37ff
+			>;
+		};
+
+		pinctrl_pwm0: pwm0grp {
+			fsl,pins = <
+				VF610_PAD_PTB0__FTM0_CH0	0x1582
+				VF610_PAD_PTB1__FTM0_CH1	0x1582
+				VF610_PAD_PTB2__FTM0_CH2	0x1582
+				VF610_PAD_PTB3__FTM0_CH3	0x1582
+			>;
+		};
+
+		pinctrl_uart0: uart0grp {
+			fsl,pins = <
+				VF610_PAD_PTB10__UART0_TX	0x21a2
+				VF610_PAD_PTB11__UART0_RX	0x21a1
+			>;
+		};
+
+		pinctrl_uart1: uart1grp {
+			fsl,pins = <
+				VF610_PAD_PTB23__UART1_TX	0x21a2
+				VF610_PAD_PTB24__UART1_RX	0x21a1
+			>;
+		};
+
+		pinctrl_uart2: uart2grp {
+			fsl,pins = <
+				VF610_PAD_PTD0__UART2_TX	0x21a2
+				VF610_PAD_PTD1__UART2_RX	0x21a1
+			>;
+		};
+
+		pinctrl_qspi0: qspi0grp {
+			fsl,pins = <
+				VF610_PAD_PTD7__QSPI0_B_QSCK	0x31c3
+				VF610_PAD_PTD8__QSPI0_B_CS0	0x31ff
+				VF610_PAD_PTD9__QSPI0_B_DATA3	0x31c3
+				VF610_PAD_PTD10__QSPI0_B_DATA2	0x31c3
+				VF610_PAD_PTD11__QSPI0_B_DATA1	0x31c3
+				VF610_PAD_PTD12__QSPI0_B_DATA0	0x31c3
+			>;
+		};
+
+		pinctrl_usb0_host: usb0-host-grp {
+			fsl,pins = <
+				VF610_PAD_PTD6__GPIO_85		0x0062
+			>;
+		};
+		pinctrl_mdio_mux: pinctrl-mdio-mux {
+			fsl,pins = <
+				VF610_PAD_PTA18__GPIO_8		0x31c2
+				VF610_PAD_PTA19__GPIO_9		0x31c2
+				VF610_PAD_PTB2__GPIO_24		0x31c2
+				VF610_PAD_PTB3__GPIO_25		0x31c2
+			>;
+		};
+		pinctrl_fec0: fec0grp {
+			fsl,pins = <
+				VF610_PAD_PTC0__ENET_RMII0_MDC	0x30d2
+				VF610_PAD_PTC1__ENET_RMII0_MDIO	0x30d3
+				VF610_PAD_PTC2__ENET_RMII0_CRS	0x30d1
+				VF610_PAD_PTC3__ENET_RMII0_RXD1	0x30d1
+				VF610_PAD_PTC4__ENET_RMII0_RXD0	0x30d1
+				VF610_PAD_PTC5__ENET_RMII0_RXER	0x30d1
+				VF610_PAD_PTC6__ENET_RMII0_TXD1	0x30d2
+				VF610_PAD_PTC7__ENET_RMII0_TXD0	0x30d2
+				VF610_PAD_PTC8__ENET_RMII0_TXEN	0x30d2
+			>;
+		};
+
+		pinctrl_leds_debug: pinctrl-leds-debug {
+			fsl,pins = <
+				 VF610_PAD_PTD20__GPIO_74	0x31c2
+				 >;
+		};
+
+		pinctrl_pca9554_opt: pinctrl-pca95540-opt {
+			fsl,pins = <
+				VF610_PAD_PTB18__GPIO_40	0x219d
+			>;
+		};
+	};
+};
+
+&L2 {
+	arm,data-latency = <2 1 2>;
+	arm,tag-latency = <3 2 3>;
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart0>;
+	status = "okay";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2>;
+	status = "okay";
+};
+
+&usbdev0 {
+	disable-over-current;
+	status = "okay";
+	vbus-supply = <&usb0_vbus>;
+	dr_mode = "host";
+};
+
+&usbh1 {
+	disable-over-current;
+	status = "okay";
+};
+
+&usbmisc0 {
+	status = "okay";
+};
+
+&usbmisc1 {
+	status = "okay";
+};
+
+&usbphy0 {
+	status = "okay";
+};
+
+&usbphy1 {
+	status = "okay";
+};
+
+&qspi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_qspi0>;
+	fsl,nor-size = <0x10000000>;
+	fsl,spi-num-chipselects = <2>;
+	status = "okay";
+
+	flash0: mt25ql02gc at 0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "micron,mt25ql02gc";
+		spi-max-frequency = <66000000>;
+		reg = <0>;
+
+		partition at 0 {
+			label = "mt25ql02gc-0-uboot";
+			reg = <0x0 0x0100000>;
+		};
+
+		partition2 at 100000 {
+			label = "mt25ql02gc-0-dtb";
+			reg = <0x0100000 0x0100000>;
+		};
+
+		partition3 at 200000 {
+			label = "mt25ql02gc-0-kernel";
+			reg = <0x0200000 0x0500000>;
+		};
+
+		partition4 at 700000 {
+			label = "mt25ql02gc-0-rfs";
+			reg = <0x0600000 0x8000000>;
+		};
+	};
+};
-- 
2.7.0



From ezequiel at vanguardiasur.com.ar  Sun Feb 21 12:17:17 2016
From: ezequiel at vanguardiasur.com.ar (Ezequiel Garcia)
Date: Sun, 21 Feb 2016 17:17:17 -0300
Subject: LPC18xx doesn't boot on linux-next
Message-ID: <CAAEAJfB4_JbRMC5Y5siqPR__Tr8V6x15DSuvEdANxVNjiB-v3w@mail.gmail.com>

Hey Joachim,

I've noticed that my Hitex LPC4350 doesn't boot with latest next.
Here's the bootlog,
with lpc18xx_defconfig.

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version
4.5.0-rc4-next-20160219-00003-ge153f1589736 (zeta at laptop) (gcc version
4.8.2 (OSELAS.Toolchain-2013.12.2) ) #208 PREEMPT Sun Feb 21 17:05:51
ART 2016
[    0.000000] CPU: ARMv7-M [410fc241] revision 1 (ARMv7M), cr=00000000
[    0.000000] CPU: unknown data cache, unknown instruction cache
[    0.000000] Machine model: Hitex LPC4350 Evaluation Board
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Built 1 zonelists in Zone order, mobility grouping off.
Total pages: 2032
[    0.000000] Kernel command line: console=ttyS0,115200 earlyprintk
ethaddr=C0:B1:3C:88:88:90
[    0.000000] PID hash table entries: 32 (order: -5, 128 bytes)
[    0.000000] Dentry cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Memory: 5080K/8192K available (1883K kernel code, 119K
rwdata, 652K rodata, 84K init, 185K bss, 3112K reserved, 0K
cma-reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0x00000000 - 0x00001000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0x00000000 - 0xffffffff   (4095 MB)
[    0.000000]     lowmem  : 0x28000000 - 0x28800000   (   8 MB)
[    0.000000]       .text : 0x28008000 - 0x2828205c   (2537 kB)
[    0.000000]       .init : 0x28283000 - 0x28298000   (  84 kB)
[    0.000000]       .data : 0x28298000 - 0x282b5fe0   ( 120 kB)
[    0.000000]        .bss : 0x282b5fe0 - 0x282e47ac   ( 186 kB)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] Build-time adjustment of leaf fanout to 32.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] __clk_core_init: pll1 would create circular parent
[    0.000000] lpc18xx_cgu_register_source_clks: failed to register pll (2)
[    0.000000] __clk_core_init: idiva would create circular parent
[    0.000000] lpc18xx_cgu_register_source_clks: failed to register div 0
[    0.000000] __clk_core_init: idivb would create circular parent
[    0.000000] lpc18xx_cgu_register_source_clks: failed to register div 1
[    0.000000] __clk_core_init: idivc would create circular parent
[    0.000000] lpc18xx_cgu_register_source_clks: failed to register div 2
[    0.000000] __clk_core_init: idivd would create circular parent
[    0.000000] lpc18xx_cgu_register_source_clks: failed to register div 3
[    0.000000] __clk_core_init: idive would create circular parent
[    0.000000] lpc18xx_cgu_register_source_clks: failed to register div 4
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
4.5.0-rc4-next-20160219-00003-ge153f1589736 #208
[    0.000000] Hardware name: NXP LPC18xx/43xx (Device Tree)
[    0.000000] [<2800be59>] (unwind_backtrace) from [<2800b20b>]
(show_stack+0xb/0xc)
[    0.000000] [<2800b20b>] (show_stack) from [<280ac3cf>] (Ldiv0_64+0x9/0x1a)
[    0.000000] [<280ac3cf>] (Ldiv0_64) from [<28036787>]
(clocks_calc_max_nsecs+0x19/0x4e)
[    0.000000] [<28036787>] (clocks_calc_max_nsecs) from [<280368b3>]
(__clocksource_update_freq_scale+0xf7/0x12c)
[    0.000000] [<280368b3>] (__clocksource_update_freq_scale) from
[<280368f1>] (__clocksource_register_scale+0x9/0x34)
[    0.000000] [<280368f1>] (__clocksource_register_scale) from
[<2828dea9>] (lpc32xx_timer_init+0x125/0x228)
[    0.000000] [<2828dea9>] (lpc32xx_timer_init) from [<2828dcd5>]
(clocksource_probe+0x25/0x50)
[    0.000000] [<2828dcd5>] (clocksource_probe) from [<28283579>]
(start_kernel+0x19d/0x2b4)
[    0.000000] [<28283579>] (start_kernel) from [<28008025>] (0x28008025)
[    0.000000] clocksource: lpc3220 timer: mask: 0xffffffff
max_cycles: 0x0, max_idle_ns: 0 ns
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
4.5.0-rc4-next-20160219-00003-ge153f1589736 #208
[    0.000000] Hardware name: NXP LPC18xx/43xx (Device Tree)
[    0.000000] [<2800be59>] (unwind_backtrace) from [<2800b20b>]
(show_stack+0xb/0xc)
[    0.000000] [<2800b20b>] (show_stack) from [<280ac3cf>] (Ldiv0_64+0x9/0x1a)
[    0.000000] [<280ac3cf>] (Ldiv0_64) from [<280366f7>]
(clocks_calc_mult_shift+0x77/0x9c)
[    0.000000] [<280366f7>] (clocks_calc_mult_shift) from [<2828aaf9>]
(register_current_timer_delay+0x19/0xbc)
[    0.000000] [<2828aaf9>] (register_current_timer_delay) from
[<2828dddb>] (lpc32xx_timer_init+0x57/0x228)
[    0.000000] [<2828dddb>] (lpc32xx_timer_init) from [<2828dcd5>]
(clocksource_probe+0x25/0x50)
[    0.000000] [<2828dcd5>] (clocksource_probe) from [<28283579>]
(start_kernel+0x19d/0x2b4)
[    0.000000] [<28283579>] (start_kernel) from [<28008025>] (0x28008025)
[    0.000000] Switching to timer-based delay loop, resolution 0ns
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
4.5.0-rc4-next-20160219-00003-ge153f1589736 #208
[    0.000000] Hardware name: NXP LPC18xx/43xx (Device Tree)
[    0.000000] [<2800be59>] (unwind_backtrace) from [<2800b20b>]
(show_stack+0xb/0xc)
[    0.000000] [<2800b20b>] (show_stack) from [<280ac3cf>] (Ldiv0_64+0x9/0x1a)
[    0.000000] [<280ac3cf>] (Ldiv0_64) from [<280366f7>]
(clocks_calc_mult_shift+0x77/0x9c)
[    0.000000] [<280366f7>] (clocks_calc_mult_shift) from [<28287bfb>]
(sched_clock_register+0x3b/0x164)
[    0.000000] [<28287bfb>] (sched_clock_register) from [<2828dde5>]
(lpc32xx_timer_init+0x61/0x228)
[    0.000000] [<2828dde5>] (lpc32xx_timer_init) from [<2828dcd5>]
(clocksource_probe+0x25/0x50)
[    0.000000] [<2828dcd5>] (clocksource_probe) from [<28283579>]
(start_kernel+0x19d/0x2b4)
[    0.000000] [<28283579>] (start_kernel) from [<28008025>] (0x28008025)
[    0.000000] Division by zero in kernel.
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
4.5.0-rc4-next-20160219-00003-ge153f1589736 #208
[    0.000000] Hardware name: NXP LPC18xx/43xx (Device Tree)
[    0.000000] [<2800be59>] (unwind_backtrace) from [<2800b20b>]
(show_stack+0xb/0xc)
[    0.000000] [<2800b20b>] (show_stack) from [<280ac3cf>] (Ldiv0_64+0x9/0x1a)
[    0.000000] [<280ac3cf>] (Ldiv0_64) from [<28036787>]
(clocks_calc_max_nsecs+0x19/0x4e)
[    0.000000] [<28036787>] (clocks_calc_max_nsecs) from [<28287c31>]
(sched_clock_register+0x71/0x164)
[    0.000000] [<28287c31>] (sched_clock_register) from [<2828dde5>]
(lpc32xx_timer_init+0x61/0x228)
[    0.000000] [<2828dde5>] (lpc32xx_timer_init) from [<2828dcd5>]
(clocksource_probe+0x25/0x50)
[    0.000000] [<2828dcd5>] (clocksource_probe) from [<28283579>]
(start_kernel+0x19d/0x2b4)
[    0.000000] [<28283579>] (start_kernel) from [<28008025>] (0x28008025)
[    0.000000] sched_clock: 32 bits at 0 Hz, resolution 0ns, wraps every 0ns
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at
/home/zeta/fast/linux/ezequielg/kernel/time/clockevents.c:44
cev_delta2ns+0x2d/0xc8()
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
4.5.0-rc4-next-20160219-00003-ge153f1589736 #208
[    0.000000] Hardware name: NXP LPC18xx/43xx (Device Tree)
[    0.000000] [<2800be59>] (unwind_backtrace) from [<2800b20b>]
(show_stack+0xb/0xc)
[    0.000000] [<2800b20b>] (show_stack) from [<2800e42d>]
(warn_slowpath_common+0x51/0x74)
[    0.000000] [<2800e42d>] (warn_slowpath_common) from [<2800e4c7>]
(warn_slowpath_null+0xf/0x14)
[    0.000000] [<2800e4c7>] (warn_slowpath_null) from [<2803847d>]
(cev_delta2ns+0x2d/0xc8)
[    0.000000] [<2803847d>] (cev_delta2ns) from [<28038a0d>]
(clockevents_config+0x35/0x50)
[    0.000000] [<28038a0d>] (clockevents_config) from [<28038a35>]
(clockevents_config_and_register+0xd/0x16)
[    0.000000] [<28038a35>] (clockevents_config_and_register) from
[<2828df31>] (lpc32xx_timer_init+0x1ad/0x228)
[    0.000000] [<2828df31>] (lpc32xx_timer_init) from [<2828dcd5>]
(clocksource_probe+0x25/0x50)
[    0.000000] [<2828dcd5>] (clocksource_probe) from [<28283579>]
(start_kernel+0x19d/0x2b4)
[    0.000000] [<28283579>] (start_kernel) from [<28008025>] (0x28008025)
[    0.000000] ---[ end trace cb88537fdc8fa200 ]---


-- 
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar


From manabian at gmail.com  Sun Feb 21 13:14:05 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Sun, 21 Feb 2016 22:14:05 +0100
Subject: LPC18xx doesn't boot on linux-next
In-Reply-To: <CAAEAJfB4_JbRMC5Y5siqPR__Tr8V6x15DSuvEdANxVNjiB-v3w@mail.gmail.com>
References: <CAAEAJfB4_JbRMC5Y5siqPR__Tr8V6x15DSuvEdANxVNjiB-v3w@mail.gmail.com>
Message-ID: <CAGhQ9VyyhCKy4qCFAe-WQ45OjLCSa8AmExL8YkWnSdYNE2v_2w@mail.gmail.com>

Hi Ezequiel,

On 21 February 2016 at 21:17, Ezequiel Garcia
<ezequiel at vanguardiasur.com.ar> wrote:
> Hey Joachim,
>
> I've noticed that my Hitex LPC4350 doesn't boot with latest next.
> Here's the bootlog,
> with lpc18xx_defconfig.

Thanks for reporting.

The 'would create circular parent' message doesn't seem to exist in
v4.5rc and seem to have been added by 858d58815 'clk: avoid circular
clock topology'.

Does it help to revert that commit? if not could you bisected it?


regards,
Joachim Eastwood


> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version
> 4.5.0-rc4-next-20160219-00003-ge153f1589736 (zeta at laptop) (gcc version
> 4.8.2 (OSELAS.Toolchain-2013.12.2) ) #208 PREEMPT Sun Feb 21 17:05:51
> ART 2016
> [    0.000000] CPU: ARMv7-M [410fc241] revision 1 (ARMv7M), cr=00000000
> [    0.000000] CPU: unknown data cache, unknown instruction cache
> [    0.000000] Machine model: Hitex LPC4350 Evaluation Board
> [    0.000000] bootconsole [earlycon0] enabled
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping off.
> Total pages: 2032
> [    0.000000] Kernel command line: console=ttyS0,115200 earlyprintk
> ethaddr=C0:B1:3C:88:88:90
> [    0.000000] PID hash table entries: 32 (order: -5, 128 bytes)
> [    0.000000] Dentry cache hash table entries: 1024 (order: 0, 4096 bytes)
> [    0.000000] Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
> [    0.000000] Memory: 5080K/8192K available (1883K kernel code, 119K
> rwdata, 652K rodata, 84K init, 185K bss, 3112K reserved, 0K
> cma-reserved)
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0x00000000 - 0x00001000   (   4 kB)
> [    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
> [    0.000000]     vmalloc : 0x00000000 - 0xffffffff   (4095 MB)
> [    0.000000]     lowmem  : 0x28000000 - 0x28800000   (   8 MB)
> [    0.000000]       .text : 0x28008000 - 0x2828205c   (2537 kB)
> [    0.000000]       .init : 0x28283000 - 0x28298000   (  84 kB)
> [    0.000000]       .data : 0x28298000 - 0x282b5fe0   ( 120 kB)
> [    0.000000]        .bss : 0x282b5fe0 - 0x282e47ac   ( 186 kB)
> [    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> [    0.000000] Preemptible hierarchical RCU implementation.
> [    0.000000] Build-time adjustment of leaf fanout to 32.
> [    0.000000] NR_IRQS:16 nr_irqs:16 16
> [    0.000000] __clk_core_init: pll1 would create circular parent
> [    0.000000] lpc18xx_cgu_register_source_clks: failed to register pll (2)
> [    0.000000] __clk_core_init: idiva would create circular parent
> [    0.000000] lpc18xx_cgu_register_source_clks: failed to register div 0
> [    0.000000] __clk_core_init: idivb would create circular parent
> [    0.000000] lpc18xx_cgu_register_source_clks: failed to register div 1
> [    0.000000] __clk_core_init: idivc would create circular parent
> [    0.000000] lpc18xx_cgu_register_source_clks: failed to register div 2
> [    0.000000] __clk_core_init: idivd would create circular parent
> [    0.000000] lpc18xx_cgu_register_source_clks: failed to register div 3
> [    0.000000] __clk_core_init: idive would create circular parent
> [    0.000000] lpc18xx_cgu_register_source_clks: failed to register div 4
> [    0.000000] Division by zero in kernel.
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.5.0-rc4-next-20160219-00003-ge153f1589736 #208
> [    0.000000] Hardware name: NXP LPC18xx/43xx (Device Tree)
> [    0.000000] [<2800be59>] (unwind_backtrace) from [<2800b20b>]
> (show_stack+0xb/0xc)
> [    0.000000] [<2800b20b>] (show_stack) from [<280ac3cf>] (Ldiv0_64+0x9/0x1a)
> [    0.000000] [<280ac3cf>] (Ldiv0_64) from [<28036787>]
> (clocks_calc_max_nsecs+0x19/0x4e)
> [    0.000000] [<28036787>] (clocks_calc_max_nsecs) from [<280368b3>]
> (__clocksource_update_freq_scale+0xf7/0x12c)
> [    0.000000] [<280368b3>] (__clocksource_update_freq_scale) from
> [<280368f1>] (__clocksource_register_scale+0x9/0x34)
> [    0.000000] [<280368f1>] (__clocksource_register_scale) from
> [<2828dea9>] (lpc32xx_timer_init+0x125/0x228)
> [    0.000000] [<2828dea9>] (lpc32xx_timer_init) from [<2828dcd5>]
> (clocksource_probe+0x25/0x50)
> [    0.000000] [<2828dcd5>] (clocksource_probe) from [<28283579>]
> (start_kernel+0x19d/0x2b4)
> [    0.000000] [<28283579>] (start_kernel) from [<28008025>] (0x28008025)
> [    0.000000] clocksource: lpc3220 timer: mask: 0xffffffff
> max_cycles: 0x0, max_idle_ns: 0 ns
> [    0.000000] Division by zero in kernel.
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.5.0-rc4-next-20160219-00003-ge153f1589736 #208
> [    0.000000] Hardware name: NXP LPC18xx/43xx (Device Tree)
> [    0.000000] [<2800be59>] (unwind_backtrace) from [<2800b20b>]
> (show_stack+0xb/0xc)
> [    0.000000] [<2800b20b>] (show_stack) from [<280ac3cf>] (Ldiv0_64+0x9/0x1a)
> [    0.000000] [<280ac3cf>] (Ldiv0_64) from [<280366f7>]
> (clocks_calc_mult_shift+0x77/0x9c)
> [    0.000000] [<280366f7>] (clocks_calc_mult_shift) from [<2828aaf9>]
> (register_current_timer_delay+0x19/0xbc)
> [    0.000000] [<2828aaf9>] (register_current_timer_delay) from
> [<2828dddb>] (lpc32xx_timer_init+0x57/0x228)
> [    0.000000] [<2828dddb>] (lpc32xx_timer_init) from [<2828dcd5>]
> (clocksource_probe+0x25/0x50)
> [    0.000000] [<2828dcd5>] (clocksource_probe) from [<28283579>]
> (start_kernel+0x19d/0x2b4)
> [    0.000000] [<28283579>] (start_kernel) from [<28008025>] (0x28008025)
> [    0.000000] Switching to timer-based delay loop, resolution 0ns
> [    0.000000] Division by zero in kernel.
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.5.0-rc4-next-20160219-00003-ge153f1589736 #208
> [    0.000000] Hardware name: NXP LPC18xx/43xx (Device Tree)
> [    0.000000] [<2800be59>] (unwind_backtrace) from [<2800b20b>]
> (show_stack+0xb/0xc)
> [    0.000000] [<2800b20b>] (show_stack) from [<280ac3cf>] (Ldiv0_64+0x9/0x1a)
> [    0.000000] [<280ac3cf>] (Ldiv0_64) from [<280366f7>]
> (clocks_calc_mult_shift+0x77/0x9c)
> [    0.000000] [<280366f7>] (clocks_calc_mult_shift) from [<28287bfb>]
> (sched_clock_register+0x3b/0x164)
> [    0.000000] [<28287bfb>] (sched_clock_register) from [<2828dde5>]
> (lpc32xx_timer_init+0x61/0x228)
> [    0.000000] [<2828dde5>] (lpc32xx_timer_init) from [<2828dcd5>]
> (clocksource_probe+0x25/0x50)
> [    0.000000] [<2828dcd5>] (clocksource_probe) from [<28283579>]
> (start_kernel+0x19d/0x2b4)
> [    0.000000] [<28283579>] (start_kernel) from [<28008025>] (0x28008025)
> [    0.000000] Division by zero in kernel.
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.5.0-rc4-next-20160219-00003-ge153f1589736 #208
> [    0.000000] Hardware name: NXP LPC18xx/43xx (Device Tree)
> [    0.000000] [<2800be59>] (unwind_backtrace) from [<2800b20b>]
> (show_stack+0xb/0xc)
> [    0.000000] [<2800b20b>] (show_stack) from [<280ac3cf>] (Ldiv0_64+0x9/0x1a)
> [    0.000000] [<280ac3cf>] (Ldiv0_64) from [<28036787>]
> (clocks_calc_max_nsecs+0x19/0x4e)
> [    0.000000] [<28036787>] (clocks_calc_max_nsecs) from [<28287c31>]
> (sched_clock_register+0x71/0x164)
> [    0.000000] [<28287c31>] (sched_clock_register) from [<2828dde5>]
> (lpc32xx_timer_init+0x61/0x228)
> [    0.000000] [<2828dde5>] (lpc32xx_timer_init) from [<2828dcd5>]
> (clocksource_probe+0x25/0x50)
> [    0.000000] [<2828dcd5>] (clocksource_probe) from [<28283579>]
> (start_kernel+0x19d/0x2b4)
> [    0.000000] [<28283579>] (start_kernel) from [<28008025>] (0x28008025)
> [    0.000000] sched_clock: 32 bits at 0 Hz, resolution 0ns, wraps every 0ns
> [    0.000000] ------------[ cut here ]------------
> [    0.000000] WARNING: CPU: 0 PID: 0 at
> /home/zeta/fast/linux/ezequielg/kernel/time/clockevents.c:44
> cev_delta2ns+0x2d/0xc8()
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
> 4.5.0-rc4-next-20160219-00003-ge153f1589736 #208
> [    0.000000] Hardware name: NXP LPC18xx/43xx (Device Tree)
> [    0.000000] [<2800be59>] (unwind_backtrace) from [<2800b20b>]
> (show_stack+0xb/0xc)
> [    0.000000] [<2800b20b>] (show_stack) from [<2800e42d>]
> (warn_slowpath_common+0x51/0x74)
> [    0.000000] [<2800e42d>] (warn_slowpath_common) from [<2800e4c7>]
> (warn_slowpath_null+0xf/0x14)
> [    0.000000] [<2800e4c7>] (warn_slowpath_null) from [<2803847d>]
> (cev_delta2ns+0x2d/0xc8)
> [    0.000000] [<2803847d>] (cev_delta2ns) from [<28038a0d>]
> (clockevents_config+0x35/0x50)
> [    0.000000] [<28038a0d>] (clockevents_config) from [<28038a35>]
> (clockevents_config_and_register+0xd/0x16)
> [    0.000000] [<28038a35>] (clockevents_config_and_register) from
> [<2828df31>] (lpc32xx_timer_init+0x1ad/0x228)
> [    0.000000] [<2828df31>] (lpc32xx_timer_init) from [<2828dcd5>]
> (clocksource_probe+0x25/0x50)
> [    0.000000] [<2828dcd5>] (clocksource_probe) from [<28283579>]
> (start_kernel+0x19d/0x2b4)
> [    0.000000] [<28283579>] (start_kernel) from [<28008025>] (0x28008025)
> [    0.000000] ---[ end trace cb88537fdc8fa200 ]---
>
>
> --
> Ezequiel Garc?a, VanguardiaSur
> www.vanguardiasur.com.ar


From ezequiel at vanguardiasur.com.ar  Sun Feb 21 13:25:28 2016
From: ezequiel at vanguardiasur.com.ar (Ezequiel Garcia)
Date: Sun, 21 Feb 2016 18:25:28 -0300
Subject: LPC18xx doesn't boot on linux-next
In-Reply-To: <CAGhQ9VyyhCKy4qCFAe-WQ45OjLCSa8AmExL8YkWnSdYNE2v_2w@mail.gmail.com>
References: <CAAEAJfB4_JbRMC5Y5siqPR__Tr8V6x15DSuvEdANxVNjiB-v3w@mail.gmail.com>
 <CAGhQ9VyyhCKy4qCFAe-WQ45OjLCSa8AmExL8YkWnSdYNE2v_2w@mail.gmail.com>
Message-ID: <CAAEAJfCB6REQe6TiCR1z3m4LnsCfp0O2zD5=fLhSGADJzF5qPA@mail.gmail.com>

On 21 February 2016 at 18:14, Joachim  Eastwood <manabian at gmail.com> wrote:
> Hi Ezequiel,
>
> On 21 February 2016 at 21:17, Ezequiel Garcia
> <ezequiel at vanguardiasur.com.ar> wrote:
>> Hey Joachim,
>>
>> I've noticed that my Hitex LPC4350 doesn't boot with latest next.
>> Here's the bootlog,
>> with lpc18xx_defconfig.
>
> Thanks for reporting.
>
> The 'would create circular parent' message doesn't seem to exist in
> v4.5rc and seem to have been added by 858d58815 'clk: avoid circular
> clock topology'.
>
> Does it help to revert that commit? if not could you bisected it?
>

Indeed, reverting 858d58815 works, and allows to boot the board.

(BTW: forgot to mention that you need to apply
"ARM: fix __start_rodata_section_aligned on XIP" as !MMU build seems
broken on linux-next without it).
-- 
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar


From manabian at gmail.com  Sun Feb 21 13:44:28 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Sun, 21 Feb 2016 22:44:28 +0100
Subject: LPC18xx doesn't boot on linux-next
In-Reply-To: <CAAEAJfCB6REQe6TiCR1z3m4LnsCfp0O2zD5=fLhSGADJzF5qPA@mail.gmail.com>
References: <CAAEAJfB4_JbRMC5Y5siqPR__Tr8V6x15DSuvEdANxVNjiB-v3w@mail.gmail.com>
 <CAGhQ9VyyhCKy4qCFAe-WQ45OjLCSa8AmExL8YkWnSdYNE2v_2w@mail.gmail.com>
 <CAAEAJfCB6REQe6TiCR1z3m4LnsCfp0O2zD5=fLhSGADJzF5qPA@mail.gmail.com>
Message-ID: <CAGhQ9VxcktYKb26MLLmio_H2AnvPTpt55pCs+R+iru3x1a_b=w@mail.gmail.com>

On 21 February 2016 at 22:25, Ezequiel Garcia
<ezequiel at vanguardiasur.com.ar> wrote:
> On 21 February 2016 at 18:14, Joachim  Eastwood <manabian at gmail.com> wrote:
>> Hi Ezequiel,
>>
>> On 21 February 2016 at 21:17, Ezequiel Garcia
>> <ezequiel at vanguardiasur.com.ar> wrote:
>>> Hey Joachim,
>>>
>>> I've noticed that my Hitex LPC4350 doesn't boot with latest next.
>>> Here's the bootlog,
>>> with lpc18xx_defconfig.
>>
>> Thanks for reporting.
>>
>> The 'would create circular parent' message doesn't seem to exist in
>> v4.5rc and seem to have been added by 858d58815 'clk: avoid circular
>> clock topology'.
>>
>> Does it help to revert that commit? if not could you bisected it?
>>
>
> Indeed, reverting 858d58815 works, and allows to boot the board.

Thanks for testing.

I have now replied on the clk patch which broke lpc18xx with you on
cc, so we'll take it from there.


> (BTW: forgot to mention that you need to apply
> "ARM: fix __start_rodata_section_aligned on XIP" as !MMU build seems
> broken on linux-next without it).

Ok, I see. It is been while since I have tried booting next.


regards,
Joachim Eastwood


From julian.calaby at gmail.com  Sun Feb 21 13:55:09 2016
From: julian.calaby at gmail.com (Julian Calaby)
Date: Mon, 22 Feb 2016 08:55:09 +1100
Subject: [linux-sunxi] Re: [PATCH v3] Fix sun7i pin assignment for IRQ's
In-Reply-To: <4cf9dbe3-faa6-4729-87fd-0e7d9ce463b0@googlegroups.com>
References: <1456060845-20692-1-git-send-email-henry@nitronetworks.nl>
 <20160221171830.GD19169@lukather>
 <4cf9dbe3-faa6-4729-87fd-0e7d9ce463b0@googlegroups.com>
Message-ID: <CAGRGNgUHQM6GtOK5OV7ppS=zOVP1UmuKnxna=qTUF172fi6hjw@mail.gmail.com>

Hi Henry,

On Mon, Feb 22, 2016 at 6:27 AM, Henry Paulissen <henry at nitronetworks.nl> wrote:
>
> Op zondag 21 februari 2016 18:18:37 UTC+1 schreef Maxime Ripard:
>>
>>
>> Your commit log is going to need some work. Which bugs? What tests did
>> you make? Why are you making these changes while the datasheet says
>> otherwise?
>
>
> Its a fix for a not yet existing bug. I was fiddling around with IRQ's and
> couldn't get them to work.
> I took a dumpster dive into it and found a shitload of contradicting manuals
> and datasheets.
>
>
> Take for example the A20 user manual:
> http://dl.linux-sunxi.org/A20/A20%20user%20manual%20v1.3%2020141010.pdf
>
> (pin PI14)
> Page 237: EINT26 is on mux *5* in the pin overview.
> Page 288: EINT26 is on mux *6* in the registers.
>
> Page 233: EINT12 is on pin PC19 mux6 in the pin overview.
> Page 236: EINT12 is on pin PH12 mux6 in the pin overview.
> Page 253: EINT12 is *not* on pin PC19 on the registers.
> Page 281: EINT12 is on pin PH12 mux6 in the registers.
>
> So manual may say otherwise, but I hope I have proven that the manual isn't
> to be trusted.
>
> My patch is based onto testing from both me and Andre (apritzel).
> He with a Banana PI M1 and me with a Cubietruck (both A20 soc).
>
> We did a basic test by connecting a pulsing signal to a port and configure
> kernel to use irq.
>
> e.g.
> echo pin# > /sys/class/gpio/export
> echo in > /sys/class/gpio/gpio#/direction
> echo rising > /sys/class/gpio/gpio#/edge
>
> and check on /proc/interrupts to see if a irq was attached and if it was
> receiving.
>
> Im not sure what andre his pulse source was, but mine was a 1pps coming from
> a gps.
>
>
>>
>> Have you tried to compile it?
>>
>
> Yes, otherwise we could have never confirmed that the irq's where on mux6
> for the PI ports.

I think Maxime is referring to the fact that your patch removes two
closing parenthesis when one would expect that you'd only remove one.

You have compiled the kernel with this patch applied and no other
modifications, right?

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


From linus.walleij at linaro.org  Sun Feb 21 14:39:24 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 21 Feb 2016 23:39:24 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56C5B080.9090007@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <56C438DA.5040109@ti.com>
 <CACRpkdZ+G17hmVP8AejL7NTqg7k0SBC5kgF55ASjD+kfuGFJhQ@mail.gmail.com>
 <20160217213250.GK19428@n2100.arm.linux.org.uk>
 <56C5B080.9090007@ti.com>
Message-ID: <CACRpkdaXFUCR5=5mS28_4Dx_LfzqV13zwT=vVeJwuOzm_rGRBQ@mail.gmail.com>

On Thu, Feb 18, 2016 at 12:52 PM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:

> For panels we need DT fragments. The question is where these fragments
> are and, possibly, who who loads them.

I hacked something up that augments the device tree from the kernel,
given you have a node with all the props you want to augment, tell me
what you think of this and whether I should continue in this direction...
also the DT people need to be involved:

#include "../../drivers/of/of_private.h"
/* Obviously make the property duplication function public instead,
it's a test */

struct versatile_panel {
    u32 id;
    char *compatible;
    u32 clock_frequency;
    u32 pixelclk_active;
    u32 hsync_active;
    u32 vsync_active;
    u32 de_active;
    u32 hactive;
    u32 hback_porch;
    u32 hfront_porch;
    u32 hsync_len;
    u32 vactive;
    u32 vback_porch;
    u32 vfront_porch;
    u32 vsync_len;
    bool ib2;
};

static const struct versatile_panel versatile_panels[] = {
    {
        .id = SYS_CLCD_ID_VGA,
        .compatible = "VGA",
        .clock_frequency = 25175000,
        .pixelclk_active = 0,
        .hsync_active = 1,
        .vsync_active = 1,
        .de_active = 1,
        .hactive = 640,
        .hback_porch = 48,
        .hfront_porch = 16,
        .hsync_len = 96,
        .vactive = 480,
        .vback_porch = 33,
        .vfront_porch = 10,
        .vsync_len = 2,
    },
    {
        .id = SYS_CLCD_ID_SANYO_3_8,
        .compatible = "sanyo,tm38qv67a02a",
        .clock_frequency = 10000000,
        .pixelclk_active = 1,
        .hsync_active = 1,
        .vsync_active = 1,
        .de_active = 1,
        .hactive = 320,
        .hback_porch = 6,
        .hfront_porch = 6,
        .hsync_len = 6,
        .vactive = 240,
        .vback_porch = 6,
        .vfront_porch = 6,
        .vsync_len = 0,
    },
    {
        .id = SYS_CLCD_ID_SHARP_8_4,
        .compatible = "sharp,lq084v1dg21",
        .clock_frequency = 25175000,
        .pixelclk_active = 0,
        .hsync_active = 1,
        .vsync_active = 1,
        .de_active = 1,
        .hactive = 640,
        .hback_porch = 48,
        .hfront_porch = 16,
        .hsync_len = 96,
        .vactive = 480,
        .vback_porch = 33,
        .vfront_porch = 10,
        .vsync_len = 2,
    },
    {
        .id = SYS_CLCD_ID_EPSON_2_2,
        .compatible = "epson,l2f50113t00",
        .clock_frequency = 16000000,
        .pixelclk_active = 0,
        .hsync_active = 1,
        .vsync_active = 1,
        .de_active = 1,
        .hactive = 176,
        .hback_porch = 3,
        .hfront_porch = 2,
        .hsync_len = 3,
        .vactive = 220,
        .vback_porch = 1,
        .vfront_porch = 0,
        .vsync_len = 2,
    },
    {
        .id = SYS_CLCD_ID_SANYO_2_5,
        .compatible = "sanyo,alr252rgt",
        .ib2 = true,
        .clock_frequency = 5440000,
        .pixelclk_active = 0,
        .hsync_active = 0,
        .vsync_active = 0,
        .de_active = 1,
        .hactive = 240,
        .hback_porch = 20,
        .hfront_porch = 10,
        .hsync_len = 10,
        .vactive = 320,
        .vback_porch = 2,
        .vfront_porch = 2,
        .vsync_len = 2,
    },
};

static void update_timings_prop(struct device *dev,
                struct of_changeset *cset,
                struct device_node *timings,
                const char *propname,
                u32 val)
{
    struct property *prop, *new;
    __be32 *dt_val;

    prop = of_find_property(timings, propname, NULL);
    if (!prop) {
        dev_err(dev, "could not find property \"%s\" - skipping\n",
            propname);
        return;
    }
    new = __of_prop_dup(prop, GFP_KERNEL);
    if (!new) {
        dev_err(dev, "could not copy property \"%s\" - skipping\n",
            propname);
        return;
    }

    dt_val = new->value;
    *dt_val = cpu_to_be32(val);

    of_changeset_update_property(cset, timings, new);
}

static int versatile_overwrite_of_panel(struct device *dev,
                    struct device_node *panel,
                    const struct versatile_panel *vpanel)
{
    struct of_changeset cset;
    struct device_node *timings;
    int ret;

    dev_info(dev, "CLCD: overwriting device tree\n");

    of_changeset_init(&cset);
    /* Find the timings node */
    timings = of_get_child_by_name(panel, "panel-timing");
    if (!timings) {
        dev_err(dev, "could not find panel timing node\n");
        goto err_destroy_cs;
    }
    update_timings_prop(dev, &cset, timings, "clock-frequency",
                vpanel->clock_frequency);
    update_timings_prop(dev, &cset, timings, "pixelclk-active",
                vpanel->pixelclk_active);
    update_timings_prop(dev, &cset, timings, "hsync-active",
                vpanel->hsync_active);
    update_timings_prop(dev, &cset, timings, "vsync-active",
                vpanel->vsync_active);
    update_timings_prop(dev, &cset, timings, "de-active",
                vpanel->de_active);
    update_timings_prop(dev, &cset, timings, "hactive",
                vpanel->hactive);
    update_timings_prop(dev, &cset, timings, "hback-porch",
                vpanel->hback_porch);
    update_timings_prop(dev, &cset, timings, "hsync-len",
                vpanel->hsync_len);
    update_timings_prop(dev, &cset, timings, "vactive",
                vpanel->vactive);
    update_timings_prop(dev, &cset, timings, "vback-porch",
                vpanel->vback_porch);
    update_timings_prop(dev, &cset, timings, "vfront-porch",
                vpanel->vfront_porch);
    update_timings_prop(dev, &cset, timings, "vsync-len",
                vpanel->hsync_len);

    ret = of_changeset_apply(&cset);
    if (ret) {
        dev_err(dev, "could not apply device tree changeset\n");
        goto err_destroy_cs;
    }
    return ret;

err_destroy_cs:
    of_changeset_destroy(&cset);
    return ret;
}

static void versatile_panel_probe(struct device *dev,
                  struct device_node *endpoint)
{
    struct versatile_panel const *vpanel = NULL;
    struct device_node *panel = NULL;
    u32 val;
    int ret;
    int i;

    /*
     * The Versatile CLCD has a panel auto-detection mechanism.
     * We use this and look for the compatible panel in the
     * device tree.
     */
    ret = regmap_read(versatile_syscon_map, SYS_CLCD, &val);
    if (ret) {
        dev_err(dev, "cannot read CLCD syscon register\n");
        return;
    }
    val &= SYS_CLCD_CLCDID_MASK;
    dev_info(dev, "SYS_CLCD=%08x\n", val);

    /* First find corresponding panel information */
    for (i = 0; i < ARRAY_SIZE(versatile_panels); i++) {
        vpanel = &versatile_panels[i];

        if (val == vpanel->id) {
            dev_err(dev, "autodetected panel \"%s\"\n",
                vpanel->compatible);
            break;
        }
    }
    if (i == ARRAY_SIZE(versatile_panels)) {
        dev_err(dev, "could not auto-detect panel\n");
        return;
    }

    /* This is the default panel node in the device tree */
    panel = of_graph_get_remote_port_parent(endpoint);
    if (!panel) {
        dev_err(dev, "could not locate remote port for panel\n");
        return;
    }

    /*
     * So now we dynamically update the display properties of the
     * panel in accordance to what was detected..
     */
    ret = versatile_overwrite_of_panel(dev, panel, vpanel);
    if (ret) {
        dev_err(dev, "cannot overwrite devicetree panel\n");
        return;
    }

    /*
     * If we have a Sanyo 2.5" port
     * that we're running on an IB2 and proceed to look for the
     * IB2 syscon regmap.
     */
    if (!vpanel->ib2)
        return;

    versatile_ib2_map = syscon_regmap_lookup_by_compatible(
        "arm,versatile-ib2-syscon");
    if (IS_ERR(versatile_ib2_map)) {
        dev_err(dev, "could not locate IB2 control register\n");
        versatile_ib2_map = NULL;
        return;
    }
}


This actually works. But would need some public device tree
property augmentation API instead of the hacks. Should I pursue
it?

Yours,
Linus Walleij


From draakje197 at gmail.com  Sun Feb 21 15:17:14 2016
From: draakje197 at gmail.com (Henry Paulissen)
Date: Mon, 22 Feb 2016 00:17:14 +0100
Subject: [PATCH v4] Fix sun7i pin assignment for IRQ's
Message-ID: <1456096638-21961-1-git-send-email-henry@nitronetworks.nl>

After testing IRQ pins we found some bugs in the pinctrl declaration.

Signed-off-by: Henry Paulissen <henry at nitronetworks.nl>
---

Changes in v2:
    After some more testing we found irq on PI pins.
    they where on mux6 so this is included in my patch.

    Also included is a warning for PI17, this pin was not working
    on apritzel his bPI and he thinks it might be correlated to
    GIC and IRQ 29.

Changes in v3:
    Changed name from nickname to realname in email and SoB.

Changes in v4:
    Added closing parenthesis for the C pins 

---
 drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c | 33 ++++++++++++++-----------------
 1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
index cf1ce0c..ca7b9a3 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
@@ -343,26 +343,22 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE4 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* CS0 */
-		  SUNXI_FUNCTION_IRQ(0x6, 12)),		/* EINT12 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* CS0 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 20),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE5 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* CLK */
-		  SUNXI_FUNCTION_IRQ(0x6, 13)),		/* EINT13 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* CLK */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 21),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE6 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* MOSI */
-		  SUNXI_FUNCTION_IRQ(0x6, 14)),		/* EINT14 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* MOSI */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 22),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE7 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* MISO */
-		  SUNXI_FUNCTION_IRQ(0x6, 15)),		/* EINT15 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* MISO */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 23),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
@@ -960,65 +956,66 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS0 */
 		  SUNXI_FUNCTION(0x3, "uart5"),		/* TX */
-		  SUNXI_FUNCTION_IRQ(0x5, 22)),		/* EINT22 */
+		  SUNXI_FUNCTION_IRQ(0x6, 22)),		/* EINT22 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 11),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CLK */
 		  SUNXI_FUNCTION(0x3, "uart5"),		/* RX */
-		  SUNXI_FUNCTION_IRQ(0x5, 23)),		/* EINT23 */
+		  SUNXI_FUNCTION_IRQ(0x6, 23)),		/* EINT23 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 12),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* MOSI */
 		  SUNXI_FUNCTION(0x3, "uart6"),		/* TX */
 		  SUNXI_FUNCTION(0x4, "clk_out_a"),	/* CLK_OUT_A */
-		  SUNXI_FUNCTION_IRQ(0x5, 24)),		/* EINT24 */
+		  SUNXI_FUNCTION_IRQ(0x6, 24)),		/* EINT24 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 13),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* MISO */
 		  SUNXI_FUNCTION(0x3, "uart6"),		/* RX */
 		  SUNXI_FUNCTION(0x4, "clk_out_b"),	/* CLK_OUT_B */
-		  SUNXI_FUNCTION_IRQ(0x5, 25)),		/* EINT25 */
+		  SUNXI_FUNCTION_IRQ(0x6, 25)),		/* EINT25 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 14),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS1 */
 		  SUNXI_FUNCTION(0x3, "ps2"),		/* SCK1 */
 		  SUNXI_FUNCTION(0x4, "timer4"),	/* TCLKIN0 */
-		  SUNXI_FUNCTION_IRQ(0x5, 26)),		/* EINT26 */
+		  SUNXI_FUNCTION_IRQ(0x6, 26)),		/* EINT26 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 15),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS1 */
 		  SUNXI_FUNCTION(0x3, "ps2"),		/* SDA1 */
 		  SUNXI_FUNCTION(0x4, "timer5"),	/* TCLKIN1 */
-		  SUNXI_FUNCTION_IRQ(0x5, 27)),		/* EINT27 */
+		  SUNXI_FUNCTION_IRQ(0x6, 27)),		/* EINT27 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 16),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS0 */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* RTS */
-		  SUNXI_FUNCTION_IRQ(0x5, 28)),		/* EINT28 */
+		  SUNXI_FUNCTION_IRQ(0x6, 28)),		/* EINT28 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 17),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CLK */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* CTS */
-		  SUNXI_FUNCTION_IRQ(0x5, 29)),		/* EINT29 */
+		  SUNXI_FUNCTION_IRQ(0x6, 29)),		/* EINT29 */
+		  /* EINT29 might not work - more testing needed */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 18),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* MOSI */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* TX */
-		  SUNXI_FUNCTION_IRQ(0x5, 30)),		/* EINT30 */
+		  SUNXI_FUNCTION_IRQ(0x6, 30)),		/* EINT30 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 19),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* MISO */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* RX */
-		  SUNXI_FUNCTION_IRQ(0x5, 31)),		/* EINT31 */
+		  SUNXI_FUNCTION_IRQ(0x6, 31)),		/* EINT31 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 20),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
-- 
2.5.0



From wens at csie.org  Sun Feb 21 15:46:13 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Sun, 21 Feb 2016 15:46:13 -0800
Subject: [PATCH v4] Fix sun7i pin assignment for IRQ's
In-Reply-To: <1456096638-21961-1-git-send-email-henry@nitronetworks.nl>
References: <1456096638-21961-1-git-send-email-henry@nitronetworks.nl>
Message-ID: <CAGb2v64gBVPcZun6snrQccW6MQk3n+bCX_kg7VF_Lrb+ZyT39A@mail.gmail.com>

On Sun, Feb 21, 2016 at 3:17 PM, Henry Paulissen <draakje197 at gmail.com> wrote:
> After testing IRQ pins we found some bugs in the pinctrl declaration.
>
> Signed-off-by: Henry Paulissen <henry at nitronetworks.nl>

Acked-by: Chen-Yu Tsai <wens at csie.org>


From paul.gortmaker at windriver.com  Sun Feb 21 16:06:03 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Sun, 21 Feb 2016 19:06:03 -0500
Subject: [PATCH v2 0/5] xen: avoid module usage in non-modular code
Message-ID: <1456099568-5154-1-git-send-email-paul.gortmaker@windriver.com>

This series of commits is a part of a larger project to ensure
people don't reference modular support functions in non-modular
code.  Overall there was roughly 5k lines of dead code in the
kernel due to this.  So far we've fixed several areas, like tty,
x86, net, ... and we continue to work on other areas.

There are several reasons to not use module support for code that
can never be built as a module, but the big ones are:

 (1) it is easy to accidentally write unused module_exit and remove code
 (2) it can be misleading when reading the source, thinking it can be
      modular when the Makefile and/or Kconfig prohibit it
 (3) it requires the include of the module.h header file which in turn
     includes nearly everything else.
 (4) it gets copied/replicated into other code and spreads like weeds.

For the xen subsystem, there are just five commits:

First, we get rid of "include <linux/module.h>" instances that are
completely unnecessary.

Then #2 and #3 and #5 are basically trivial remapping to the
appropriate non-modular counterparts, meaning that there is no
runtime change here either.

The fourth hypervisor commit is similar, but also has removal of
some dead code associated with the module_exit function that will
never be called.  So the runtime should be the same, but the object
file will be different (reduced in size).

Patches created on linux-next and build tested for x86-64 and ARM64
allmodconfig.

---

[v2: manually inline one-liners in #4; update probe vs init fcn names
 in #5 ; both suggestions by Stefano ; add Reviewed tags to #1, #2, #3.
 Redid build testing on x86-64 and ARM64 to test for typos etc.  ]

Cc: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Cc: David Vrabel <david.vrabel at citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: xen-devel at lists.xenproject.org

Paul Gortmaker (5):
  xen: audit usages of module.h ; remove unnecessary instances
  drivers/xen: make [xen-]ballon explicitly non-modular
  drivers/xen: make xenbus_dev_[front/back]end explicitly non-modular
  drivers/xen: make sys-hypervisor.c explicitly non-modular
  drivers/xen: make platform-pci.c explicitly non-modular

 arch/arm/include/asm/xen/hypercall.h     |  2 ++
 drivers/xen/balloon.c                    |  4 ----
 drivers/xen/events/events_2l.c           |  1 -
 drivers/xen/events/events_base.c         |  2 +-
 drivers/xen/events/events_fifo.c         |  1 -
 drivers/xen/features.c                   |  2 +-
 drivers/xen/grant-table.c                |  1 -
 drivers/xen/platform-pci.c               | 16 ++++++----------
 drivers/xen/sys-hypervisor.c             | 31 ++++---------------------------
 drivers/xen/xen-balloon.c                | 14 +++-----------
 drivers/xen/xen-pciback/conf_space.c     |  2 +-
 drivers/xen/xen-pciback/pciback_ops.c    |  2 +-
 drivers/xen/xen-pciback/xenbus.c         |  2 +-
 drivers/xen/xen-selfballoon.c            |  1 -
 drivers/xen/xenbus/xenbus_dev_backend.c  | 13 ++-----------
 drivers/xen/xenbus/xenbus_dev_frontend.c | 13 ++-----------
 drivers/xen/xenbus/xenbus_xs.c           |  1 -
 drivers/xen/xenfs/xensyms.c              |  1 -
 18 files changed, 24 insertions(+), 85 deletions(-)

-- 
2.6.1
Paul Gortmaker (5):
  xen: audit usages of module.h ; remove unnecessary instances
  drivers/xen: make [xen-]ballon explicitly non-modular
  drivers/xen: make xenbus_dev_[front/back]end explicitly non-modular
  drivers/xen: make sys-hypervisor.c explicitly non-modular
  drivers/xen: make platform-pci.c explicitly non-modular

 arch/arm/include/asm/xen/hypercall.h     |  2 ++
 drivers/xen/balloon.c                    |  4 ---
 drivers/xen/events/events_2l.c           |  1 -
 drivers/xen/events/events_base.c         |  2 +-
 drivers/xen/events/events_fifo.c         |  1 -
 drivers/xen/features.c                   |  2 +-
 drivers/xen/grant-table.c                |  1 -
 drivers/xen/platform-pci.c               | 22 +++++-------
 drivers/xen/sys-hypervisor.c             | 59 +++++---------------------------
 drivers/xen/xen-balloon.c                | 14 ++------
 drivers/xen/xen-pciback/conf_space.c     |  2 +-
 drivers/xen/xen-pciback/pciback_ops.c    |  2 +-
 drivers/xen/xen-pciback/xenbus.c         |  2 +-
 drivers/xen/xen-selfballoon.c            |  1 -
 drivers/xen/xenbus/xenbus_dev_backend.c  | 13 ++-----
 drivers/xen/xenbus/xenbus_dev_frontend.c | 13 ++-----
 drivers/xen/xenbus/xenbus_xs.c           |  1 -
 drivers/xen/xenfs/xensyms.c              |  1 -
 18 files changed, 31 insertions(+), 112 deletions(-)

-- 
2.6.1



From paul.gortmaker at windriver.com  Sun Feb 21 16:06:04 2016
From: paul.gortmaker at windriver.com (Paul Gortmaker)
Date: Sun, 21 Feb 2016 19:06:04 -0500
Subject: [PATCH v2 1/5] xen: audit usages of module.h ;
 remove unnecessary instances
In-Reply-To: <1456099568-5154-1-git-send-email-paul.gortmaker@windriver.com>
References: <1456099568-5154-1-git-send-email-paul.gortmaker@windriver.com>
Message-ID: <1456099568-5154-2-git-send-email-paul.gortmaker@windriver.com>

Code that uses no modular facilities whatsoever should not be
sourcing module.h at all, since that header drags in a bunch
of other headers with it.

Similarly, code that is not explicitly using modular facilities
like module_init() but only is declaring module_param setup
variables should be using moduleparam.h and not the larger
module.h file for that.

In making this change, we also uncover an implicit use of BUG()
in inline fcns within arch/arm/include/asm/xen/hypercall.h so
we explicitly source <linux/bug.h> for that file now.

Cc: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini at eu.citrix.com>
Cc: Russell King <linux at arm.linux.org.uk>
Cc: Konrad Rzeszutek Wilk <konrad.wilk at oracle.com>
Cc: Boris Ostrovsky <boris.ostrovsky at oracle.com>
Cc: David Vrabel <david.vrabel at citrix.com>
Cc: xen-devel at lists.xenproject.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
---
 arch/arm/include/asm/xen/hypercall.h  | 2 ++
 drivers/xen/events/events_2l.c        | 1 -
 drivers/xen/events/events_base.c      | 2 +-
 drivers/xen/events/events_fifo.c      | 1 -
 drivers/xen/features.c                | 2 +-
 drivers/xen/grant-table.c             | 1 -
 drivers/xen/xen-pciback/conf_space.c  | 2 +-
 drivers/xen/xen-pciback/pciback_ops.c | 2 +-
 drivers/xen/xen-pciback/xenbus.c      | 2 +-
 drivers/xen/xen-selfballoon.c         | 1 -
 drivers/xen/xenbus/xenbus_xs.c        | 1 -
 drivers/xen/xenfs/xensyms.c           | 1 -
 12 files changed, 7 insertions(+), 11 deletions(-)

diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h
index d769972db8cb..b6b962d70db9 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -33,6 +33,8 @@
 #ifndef _ASM_ARM_XEN_HYPERCALL_H
 #define _ASM_ARM_XEN_HYPERCALL_H
 
+#include <linux/bug.h>
+
 #include <xen/interface/xen.h>
 #include <xen/interface/sched.h>
 #include <xen/interface/platform.h>
diff --git a/drivers/xen/events/events_2l.c b/drivers/xen/events/events_2l.c
index 7dd46312c180..51b488f5bfe9 100644
--- a/drivers/xen/events/events_2l.c
+++ b/drivers/xen/events/events_2l.c
@@ -9,7 +9,6 @@
 #include <linux/linkage.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
-#include <linux/module.h>
 
 #include <asm/sync_bitops.h>
 #include <asm/xen/hypercall.h>
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 524c22146429..488017a0806a 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -26,7 +26,7 @@
 #include <linux/linkage.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
-#include <linux/module.h>
+#include <linux/moduleparam.h>
 #include <linux/string.h>
 #include <linux/bootmem.h>
 #include <linux/slab.h>
diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
index eff2b88003d9..9289a17712e2 100644
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -36,7 +36,6 @@
 #include <linux/linkage.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
-#include <linux/module.h>
 #include <linux/smp.h>
 #include <linux/percpu.h>
 #include <linux/cpu.h>
diff --git a/drivers/xen/features.c b/drivers/xen/features.c
index 99eda169c779..d7d34fdfc993 100644
--- a/drivers/xen/features.c
+++ b/drivers/xen/features.c
@@ -7,7 +7,7 @@
  */
 #include <linux/types.h>
 #include <linux/cache.h>
-#include <linux/module.h>
+#include <linux/export.h>
 
 #include <asm/xen/hypercall.h>
 
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index effbaf91791f..bb36b1e1dbcc 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -33,7 +33,6 @@
 
 #define pr_fmt(fmt) "xen:" KBUILD_MODNAME ": " fmt
 
-#include <linux/module.h>
 #include <linux/sched.h>
 #include <linux/mm.h>
 #include <linux/slab.h>
diff --git a/drivers/xen/xen-pciback/conf_space.c b/drivers/xen/xen-pciback/conf_space.c
index 9c234209d8b5..8e67336f8ddd 100644
--- a/drivers/xen/xen-pciback/conf_space.c
+++ b/drivers/xen/xen-pciback/conf_space.c
@@ -10,7 +10,7 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/module.h>
+#include <linux/moduleparam.h>
 #include <linux/pci.h>
 #include "pciback.h"
 #include "conf_space.h"
diff --git a/drivers/xen/xen-pciback/pciback_ops.c b/drivers/xen/xen-pciback/pciback_ops.c
index 73dafdc494aa..5ad01f9c24fc 100644
--- a/drivers/xen/xen-pciback/pciback_ops.c
+++ b/drivers/xen/xen-pciback/pciback_ops.c
@@ -6,7 +6,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
-#include <linux/module.h>
+#include <linux/moduleparam.h>
 #include <linux/wait.h>
 #include <linux/bitops.h>
 #include <xen/events.h>
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 4843741e703a..c252eb3f0176 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -6,7 +6,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
-#include <linux/module.h>
+#include <linux/moduleparam.h>
 #include <linux/init.h>
 #include <linux/list.h>
 #include <linux/vmalloc.h>
diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c
index 3b2bffde534f..53a085fca00c 100644
--- a/drivers/xen/xen-selfballoon.c
+++ b/drivers/xen/xen-selfballoon.c
@@ -71,7 +71,6 @@
 #include <linux/swap.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
-#include <linux/module.h>
 #include <linux/workqueue.h>
 #include <linux/device.h>
 #include <xen/balloon.h>
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index ba804f3d8278..374b12af8812 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -44,7 +44,6 @@
 #include <linux/fcntl.h>
 #include <linux/kthread.h>
 #include <linux/rwsem.h>
-#include <linux/module.h>
 #include <linux/mutex.h>
 #include <asm/xen/hypervisor.h>
 #include <xen/xenbus.h>
diff --git a/drivers/xen/xenfs/xensyms.c b/drivers/xen/xenfs/xensyms.c
index a03f261b12d8..c6e2b4a542ea 100644
--- a/drivers/xen/xenfs/xensyms.c
+++ b/drivers/xen/xenfs/xensyms.c
@@ -1,4 +1,3 @@
-#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/seq_file.h>
 #include <linux/fs.h>
-- 
2.6.1



From emilio at elopez.com.ar  Sun Feb 21 17:26:34 2016
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Sun, 21 Feb 2016 22:26:34 -0300
Subject: [PATCH 1/3] [media] rc: sunxi-cir: support module autoloading
Message-ID: <1456104396-13282-1-git-send-email-emilio@elopez.com.ar>

From: Emilio L?pez <emilio.lopez at collabora.co.uk>

MODULE_DEVICE_TABLE() is missing, so the module isn't auto-loading on
systems supporting infrared. This commit adds the missing line so it
works out of the box when built as a module and running on a sunxi
system with an infrared receiver.

Signed-off-by: Emilio L?pez <emilio.lopez at collabora.co.uk>
---
 drivers/media/rc/sunxi-cir.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 40f7768..eaadc08 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -326,6 +326,7 @@ static const struct of_device_id sunxi_ir_match[] = {
 	{ .compatible = "allwinner,sun5i-a13-ir", },
 	{},
 };
+MODULE_DEVICE_TABLE(of, sunxi_ir_match);
 
 static struct platform_driver sunxi_ir_driver = {
 	.probe          = sunxi_ir_probe,
-- 
2.7.1



From emilio at elopez.com.ar  Sun Feb 21 17:26:35 2016
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Sun, 21 Feb 2016 22:26:35 -0300
Subject: [PATCH 2/3] dmaengine: sun4i: support module autoloading
In-Reply-To: <1456104396-13282-1-git-send-email-emilio@elopez.com.ar>
References: <1456104396-13282-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1456104396-13282-2-git-send-email-emilio@elopez.com.ar>

From: Emilio L?pez <emilio.lopez at collabora.co.uk>

MODULE_DEVICE_TABLE() is missing, so the module isn't auto-loading on
supported systems. This commit adds the missing line so it loads
automatically when building it as a module and running on a system
with the early sunxi DMA engine.

Signed-off-by: Emilio L?pez <emilio.lopez at collabora.co.uk>
---
 drivers/dma/sun4i-dma.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/sun4i-dma.c b/drivers/dma/sun4i-dma.c
index 1661d518..e0df233 100644
--- a/drivers/dma/sun4i-dma.c
+++ b/drivers/dma/sun4i-dma.c
@@ -1271,6 +1271,7 @@ static const struct of_device_id sun4i_dma_match[] = {
 	{ .compatible = "allwinner,sun4i-a10-dma" },
 	{ /* sentinel */ },
 };
+MODULE_DEVICE_TABLE(of, sun4i_dma_match);
 
 static struct platform_driver sun4i_dma_driver = {
 	.probe	= sun4i_dma_probe,
-- 
2.7.1



From emilio at elopez.com.ar  Sun Feb 21 17:26:36 2016
From: emilio at elopez.com.ar (=?UTF-8?q?Emilio=20L=C3=B3pez?=)
Date: Sun, 21 Feb 2016 22:26:36 -0300
Subject: [PATCH 3/3] usb: musb: sunxi: support module autoloading
In-Reply-To: <1456104396-13282-1-git-send-email-emilio@elopez.com.ar>
References: <1456104396-13282-1-git-send-email-emilio@elopez.com.ar>
Message-ID: <1456104396-13282-3-git-send-email-emilio@elopez.com.ar>

From: Emilio L?pez <emilio.lopez at collabora.co.uk>

MODULE_DEVICE_TABLE() is missing, so the module isn't auto-loading on
sunxi systems using the OTG controller. This commit adds the missing
line so it loads automatically when building it as a module and running
on a system with an USB OTG port.

Signed-off-by: Emilio L?pez <emilio.lopez at collabora.co.uk>
---
 drivers/usb/musb/sunxi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index d9b0dc4..fdab423 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -752,6 +752,7 @@ static const struct of_device_id sunxi_musb_match[] = {
 	{ .compatible = "allwinner,sun8i-a33-musb", },
 	{}
 };
+MODULE_DEVICE_TABLE(of, sunxi_musb_match);
 
 static struct platform_driver sunxi_musb_driver = {
 	.probe = sunxi_musb_probe,
-- 
2.7.1



From andre.przywara at arm.com  Sun Feb 21 17:39:58 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 22 Feb 2016 01:39:58 +0000
Subject: [PATCH] clk: sunxi: allow PLL6 clock to be reused
Message-ID: <1456105198-25295-1-git-send-email-andre.przywara@arm.com>

Currently we hard-code the base name for the PLL6 clock for both the
sun4i and sun6i variants in the driver (pll6 and pll6x2, respectively).
This unfortunately denies reusing this clock for the H3 and A64 PLL8
clock, which is the same otherwise.
Remove the hard-coded name in the source code and replace it with an
appropriate index into the clock-output-names array in the DT.
This is compatible with all current device trees, since they all carry
the hard-coded base name in there.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
Salut Maxime,

does that patch make sense?
It fixes the re-usability problem while still keeping compatibility
with existing DTs and also is pretty small.
If you agree with this, I'll send out a v3 of the A64 series including
this patch and the H3 PLL8 enablement later.
I tested this on my BananaPi, the clk_summary output was identical
with and without this patch.

Cheers,
Andre.

 drivers/clk/sunxi/clk-factors.c | 3 ++-
 drivers/clk/sunxi/clk-factors.h | 1 +
 drivers/clk/sunxi/clk-sunxi.c   | 4 ++--
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi/clk-factors.c b/drivers/clk/sunxi/clk-factors.c
index ddefe96..7daf01d 100644
--- a/drivers/clk/sunxi/clk-factors.c
+++ b/drivers/clk/sunxi/clk-factors.c
@@ -202,7 +202,8 @@ struct clk *sunxi_factors_register(struct device_node *node,
 	if (data->name)
 		clk_name = data->name;
 	else
-		of_property_read_string(node, "clock-output-names", &clk_name);
+		of_property_read_string_index(node, "clock-output-names",
+					      data->name_idx, &clk_name);
 
 	factors = kzalloc(sizeof(struct clk_factors), GFP_KERNEL);
 	if (!factors)
diff --git a/drivers/clk/sunxi/clk-factors.h b/drivers/clk/sunxi/clk-factors.h
index 1e63c5b..3a7da86 100644
--- a/drivers/clk/sunxi/clk-factors.h
+++ b/drivers/clk/sunxi/clk-factors.h
@@ -36,6 +36,7 @@ struct factors_data {
 	void (*getter)(struct factors_request *req);
 	void (*recalc)(struct factors_request *req);
 	const char *name;
+	int name_idx;
 };
 
 struct clk_factors {
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 99f60ef..53f5927 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -530,14 +530,14 @@ static const struct factors_data sun4i_pll6_data __initconst = {
 	.enable = 31,
 	.table = &sun4i_pll5_config,
 	.getter = sun4i_get_pll5_factors,
-	.name = "pll6",
+	.name_idx = 2,
 };
 
 static const struct factors_data sun6i_a31_pll6_data __initconst = {
 	.enable = 31,
 	.table = &sun6i_a31_pll6_config,
 	.getter = sun6i_a31_get_pll6_factors,
-	.name = "pll6x2",
+	.name_idx = 1,
 };
 
 static const struct factors_data sun5i_a13_ahb_data __initconst = {
-- 
1.8.4



From jitao.shi at mediatek.com  Sun Feb 21 18:12:23 2016
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Mon, 22 Feb 2016 10:12:23 +0800
Subject: [PATCH 2/2] drm/panel: Add support for LG lp120up1 panel
In-Reply-To: <20160218151244.GB5571@ulmo.nvidia.com>
References: <1455691839-2410-1-git-send-email-jitao.shi@mediatek.com>
 <1455691839-2410-2-git-send-email-jitao.shi@mediatek.com>
 <20160218151244.GB5571@ulmo.nvidia.com>
Message-ID: <1456107143.6025.0.camel@mszsdhlt06>

On Thu, 2016-02-18 at 16:12 +0100, Thierry Reding wrote:
> On Wed, Feb 17, 2016 at 02:50:39PM +0800, Jitao Shi wrote:
> > The LG lp120up1 panel is a 12.0" 1920x1280 panel,
> > which can be supported by the simple panel driver
> 
> It'd be nice to mention the type of interface of the panel here. While
> at it, please rewrite the commit message to make use of what width you
> have (i.e. any line after the subject can be 72 characters wide).
> 
> Thierry

Thanks for your review.
I'll fix it next patchset.



From jitao.shi at mediatek.com  Sun Feb 21 18:13:03 2016
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Mon, 22 Feb 2016 10:13:03 +0800
Subject: [PATCH 1/2] dt-bindings: Add LG lp120up1 panel bindings
In-Reply-To: <20160218143633.GJ9654@rob-hp-laptop>
References: <1455691839-2410-1-git-send-email-jitao.shi@mediatek.com>
 <20160218143633.GJ9654@rob-hp-laptop>
Message-ID: <1456107183.6025.1.camel@mszsdhlt06>

On Thu, 2016-02-18 at 08:36 -0600, Rob Herring wrote:
> On Wed, Feb 17, 2016 at 02:50:38PM +0800, Jitao Shi wrote:
> > Add documentation for lp120up1 panel
> > 
> > Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> > ---
> >  .../bindings/display/panel/lg,lp120up1.txt         |    7 +++++++
> >  1 file changed, 7 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt
> 
> Acked-by: Rob Herring <robh at kernel.org>

Thanks for your "acked"



From lv.zheng at intel.com  Sun Feb 21 18:24:23 2016
From: lv.zheng at intel.com (Zheng, Lv)
Date: Mon, 22 Feb 2016 02:24:23 +0000
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <56C6F660.9020407@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
 <56C470C5.2080203@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>
 <56C63FB5.2030907@hurleysoftware.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4D5A0@SHSMSX101.ccr.corp.intel.com>
 <56C6F660.9020407@linaro.org>
Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB4D949@SHSMSX101.ccr.corp.intel.com>

Hi,

> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
> early_acpi_os_unmap_memory()
> 
> Hi Lv,
> 
> On 02/19/2016 05:58 AM, Zheng, Lv wrote:
> > Hi,
> >
> >> From: Peter Hurley [mailto:peter at hurleysoftware.com]
> >> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
> >> early_acpi_os_unmap_memory()
> >>
> >> On 02/17/2016 07:36 PM, Zheng, Lv wrote:
> >>> Hi,
> >>>
> >>>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
> >>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
> >>>> early_acpi_os_unmap_memory()
> >>>>
> >>>> Hi Lv,
> >>>>
> >>>> Thank you for review.
> >>>>
> >>>> On 02/17/2016 05:51 AM, Zheng, Lv wrote:
> >>>>
> >>>> [..]
> >>>>
> >>>>>>> early_acpi_os_unmap_memory() is marked as __init because it calls
> >>>>>>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is
> not
> >>>> set.
> >>>>>>>
> >>>>>>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
> >>>>>>> so it is safe to call early_acpi_os_unmap_memory() from anywhere
> >>>>>>>
> >>>>>>> We need this function to be non-__init because we need access to
> >>>>>>> some tables at unpredictable time--it may be before or after
> >>>>>>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port
> >> Console
> >>>>>>> Redirection) table is needed each time a new console is registered.
> >>>>>>> It can be quite early (console_initcall) or when a module is inserted.
> >>>>>>> When this table accessed before acpi_gbl_permanent_mmap is set,
> >>>>>>> the pointer should be unmapped.  This is exactly what this function
> >>>>>>> does.
> >>>>>> [Lv Zheng]
> >>>>>> Why don't you use another API instead of
> >> early_acpi_os_unmap_memory()
> >>>> in
> >>>>>> case you want to unmap things in any cases.
> >>>>>> acpi_os_unmap_memory() should be the one to match this purpose.
> >>>>>> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
> >>>>
> >>>> As far as I understand, there exist two steps in ACPI initialization:
> >>>>
> >>>> 1. Before acpi_gbl_permanent_mmap is set, tables received with
> >>>> acpi_get_table_with_size()
> >>>>    are mapped by early_memremap().  If a subsystem gets such a pointer it
> >>>> should be unmapped.
> >>>>
> >>>> 2  After acpi_gbl_permanent_mmap is set this pointer should not be
> >> unmapped
> >>>> at all.
> >>>>
> >>> [Lv Zheng]
> >>> This statement is wrong, this should be:
> >>> As long as there is a __reference__ to the mapped table, the pointer should
> >> not be unmapped.
> >>> In fact, we have a series to introduce acpi_put_table() to achieve this.
> >>> So your argument is wrong from very first point.
> >>>
> >>>> That exactly what early_acpi_os_unmap_memory() does--it checks
> >>>> acpi_gbl_permanent_mmap.
> >>>> If I had used acpi_os_unmap_memory() after acpi_gbl_permanent_mmap
> >> had
> >>>> been set,
> >>>> it would have tried to free that pointer with an oops (actually, I checked
> that
> >>>> and got that oops).
> >>>>
> >>>> So using acpi_os_unmap_memory() is not an option here, but
> >>>> early_acpi_os_unmap_memory()
> >>>> match perfectly.
> >>> [Lv Zheng]
> >>> I don't think so.
> >>> For definition block tables, we know for sure there will always be
> references,
> >> until "Unload" opcode is invoked by the AML interpreter.
> >>> But for the data tables, OSPMs should use them in this way:
> >>> 1. map the table
> >>> 2. parse the table and convert it to OS specific structures
> >>> 3. unmap the table
> >>> This helps to shrink virtual memory address space usages.
> >>>
> >>> So from this point of view, all data tables should be unmapped right after
> >> being parsed.
> >>> Why do you need the map to be persistent in the kernel address space?
> >>> You can always map a small table, but what if the table size is very big?
> >>>
> >>>>
> >>>>>> And in fact early_acpi_os_unmap_memory() should be removed.
> >>>>
> >>>> I don't think so -- I have explained why.  It does different thing.
> >>>> Probably it (and/or other functions in that api) should be renamed.
> >>>>
> >>> [Lv Zheng]
> >>> Just let me ask one more question.
> >>> eary_acpi_os_unmap_memory() is not used inside of ACPICA.
> >>> How ACPICA can work with just acpi_os_unmap_memory()?
> >>> You can check drivers/acpi/tbxxx.c.
> >>> Especially: acpi_tb_release_temp_table() and the code invoking it.
> >>>
> >>>>> [Lv Zheng]
> >>>>> One more thing is:
> >>>>> If you can't switch your driver to use acpi_os_unmap_memory() instead
> of
> >>>> early_acpi_os_unmap_memory(),
> >>>>> then it implies that your driver does have a defect.
> >>>>
> >>>> I still don't understand what defect, sorry.
> >>> [Lv Zheng]
> >>> If you can't ensure this sequence for using the data tables:
> >>> 1. map the table
> >>> 2. parse the table and convert it to OS specific structure
> >>> 3. unmap the table
> >>> It implies there is a bug in the driver or a bug in the ACPI subsystem core.
> >>
> >> Exactly.
> > [Lv Zheng]
> > So it looks to me:
> > Changing __init to __ref here is entirely not acceptable.
> > This API should stay being invoked during early stage.
> > Otherwise, it may leave us untrackable code that maps tables during early
> stage and leaks maps to the late stage.
> > If Linux contains such kind of code, I'm afraid, it will become impossible to
> introduce acpi_put_table() to clean up the mappings.
> > Because when acpi_put_table() is called during the late stage to free a map
> acquired during the early stage, it then obviously will end up with panic.
> 
> Can you please sugggest a common method to access ACPI tables that
> works both before *and* after acpi_gbl_permanent_mmap is set and __init
> code
> is removed?
[Lv Zheng] 
Do not change __init for now.

Currently you should:
1. before acpi_gbl_permanent_mmap is set:
acpi_get_table_with_size()
parse the table
early_acpi_os_unmap_memory()
Do your driver early stuff here

2. after acpi_gbl_permanent_mmap is set:
acpi_get_table()
Parse the table
Do your driver late stuff here
<- note there is no API now being an inverse of acpi_get_table().

Besides, I'm about to insert error messages between 1 and 2.
If an early map is not release, error message will be prompted to the developers.

And if you don't follow the above rules, it mean you are trying to lay a mine, waiting for me to step on it.
That's why this change is entirely not acceptable.

I'm about to send out the cleanup series in 1 week, and will Cc you.
You can rebase your code on top of the cleanup series.

Thanks and best regards
-Lv

> 
> > Thanks and best regards
> > -Lv
> >
> >> The central problem here is the way Aleksey is trying to hookup a console.
> >>
> >> What should be happening in this series is:
> >> 1. early map SPCR
> >> 2. parse the SPCR table
> >> 3. call add_preferred_console() to add the SPCR console to the console
> table
> >> 4. unmap SPCR
> >>
> >> This trivial and unobtrusive method would already have a 8250 console
> >> running via SPCR. I've already pointed this out in previous reviews.
> >>
> >> Further, the above method *will be required anyway* for the DBG2 table to
> >> start an earlycon, which I've already pointed out in previous reviews.
> >>
> >> Then to enable amba-pl011 console via ACPI, add a console match() method
> >> similar to the 8250 console match() method, univ8250_console_match().
> >>
> >> FWIW, PCI earlycon + console support was already submitted once before
> but
> >> never picked up by GregKH. I think I'll just grab that and re-submit so
> >> you would know what to emit for console options in the
> >> add_preferred_console().
> >>
> >>
> >> Regards,
> >> Peter Hurley
> >>
> >>
> >>>>> There is an early bootup requirement in Linux.
> >>>>> Maps acquired during the early stage should be freed by the driver during
> >> the
> >>>> early stage.
> >>>>> And the driver should re-acquire the memory map after booting.
> >>>>
> >>>> Exactly.  That's why I use early_acpi_os_unmap_memory().  The point is
> that
> >>>> that code can be
> >>>> called *before* acpi_gbl_permanent_mmap is set (at early initialization
> of
> >> for
> >>>> example 8250 console)
> >>>> or *after* acpi_gbl_permanent_mmap is set (at insertion of a module
> that
> >>>> registers a console),
> >>>> We just can not tell if the received table pointer should or sould not be
> freed
> >>>> with early_memunmap()
> >>>> (actually __acpi_unmap_table() or whatever) without checking
> >>>> acpi_gbl_permanent_mmap,
> >>>> but that's all too low level.
> >>> [Lv Zheng]
> >>> The driver should make sure that:
> >>> Map/unmap is paired during early stage.
> >>> For late stage, it should be another pair of map/unmap.
> >>>
> >>>>
> >>>> Another option, as you describe, is to get this pointer early, don't free it
> >>> [Lv Zheng]
> >>> I mean you should free it early.
> >>>
> >>>> untill acpi_gbl_permanent_mmap is set, then free it (with
> >>>> early_acpi_os_unmap_memory(), that's
> >>>> ok because acpi_gbl_permanent_mmap is set in an init code), then get
> the
> >>>> persistent
> >>>> pointer to the table.  The problem with it is that we can not just watch
> >>>> acpi_gbl_permanent_mmap
> >>>> to catch this exact moment.  And also accessing
> acpi_gbl_permanent_mmap
> >> is
> >>>> not good as it probably is
> >>>> an implementation detail (i. e. too lowlevel) of the ACPI code.
> >>>> Or I probably miss what you are suggesting.
> >>>>
> >>> [Lv Zheng]
> >>> I mean, you should:
> >>> During early stage:
> >>> acpi_os_map_memory()
> >>> Parse the table.
> >>> acpi_os_unmap_memory().
> >>>
> >>>>> This is because, during early bootup stage, there are only limited slots
> >>>> available for drivers to map memory.
> >>>>> So by changing __init to __ref here, you probably will hide many such
> >> defects.
> >>>>
> >>>> What defects?  This funcions checks acpi_gbl_permanent_mmap.
> >>>> BTW, exactly the same thing is done in the beginning of
> >>>> acpi_os_unmap_memory() and than's ok,
> >>>> that function is __ref.
> >>>>
> >>>>> And solving issues in this way doesn't seem to be an improvement.
> >>>>
> >>>> Could you please tell me where I am wrong?  I still don't understand your
> >> point.
> >>> [Lv Zheng]
> >>> But anyway, the defect should be in ACPI subsystem core.
> >>> The cause should be the API itself - acpi_get_table().
> >>>
> >>> So I agree you can use early_acpi_os_unmap_memory() during the period
> the
> >> root causes are not cleaned up.
> >>> But the bottom line is: the driver need to ensure that
> >> early_acpi_os_unmap_memory() is always invoked.
> >>> As long as you can ensure this, I don't have objections for deploying
> >> early_acpi_os_unmap_memory()  for now.
> >>>
> >>> Thanks and best regards
> >>> -Lv
> >>>
> >>>>
> >>>> Thank you
> >>>> Aleksey Makarov
> >>>>
> >>>>>
> >>>>> Thanks and best regards
> >>>>> -Lv
> >>>>>
> >>>>>>
> >>>>>> Thanks and best regards
> >>>>>> -Lv
> >>>>>>
> >>>>>>>
> >>>>>>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> >>>>>>> ---
> >>>>>>>  drivers/acpi/osl.c | 6 +++++-
> >>>>>>>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> >>>>>>> index 67da6fb..8a552cd 100644
> >>>>>>> --- a/drivers/acpi/osl.c
> >>>>>>> +++ b/drivers/acpi/osl.c
> >>>>>>> @@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void
> *virt,
> >>>>>>> acpi_size size)
> >>>>>>>  }
> >>>>>>>  EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
> >>>>>>>
> >>>>>>> -void __init early_acpi_os_unmap_memory(void __iomem *virt,
> >> acpi_size
> >>>>>> size)
> >>>>>>> +/*
> >>>>>>> + * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
> >>>>>>> + * so it is safe to call early_acpi_os_unmap_memory() from
> anywhere
> >>>>>>> + */
> >>>>>>> +void __ref early_acpi_os_unmap_memory(void __iomem *virt,
> >> acpi_size
> >>>>>> size)
> >>>>>>>  {
> >>>>>>>  	if (!acpi_gbl_permanent_mmap)
> >>>>>>>  		__acpi_unmap_table(virt, size);
> >>>>>>> --
> >>>>>>> 2.7.1
> >>>>>>>
> >>>>>>> --
> >>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> >>>>>>> the body of a message to majordomo at vger.kernel.org
> >>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-
> info.html
> >>>>>> --
> >>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> >>>>>> the body of a message to majordomo at vger.kernel.org
> >>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >

From yong.wu at mediatek.com  Sun Feb 21 10:43:09 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Mon, 22 Feb 2016 02:43:09 +0800
Subject: [v9,4/5] iommu/mediatek: Add mt8173 IOMMU driver
In-Reply-To: <20160220070209.GA16577@roeck-us.net>
References: <1455669974-1527-5-git-send-email-yong.wu@mediatek.com>
 <20160220070209.GA16577@roeck-us.net>
Message-ID: <1456080189.25237.4.camel@mhfsdcap03>

On Fri, 2016-02-19 at 23:02 -0800, Guenter Roeck wrote:
> On Wed, Feb 17, 2016 at 08:46:13AM +0800, Yong Wu wrote:
> > This patch adds support for mediatek m4u (MultiMedia Memory Management
> > Unit).
[...]
> > +#include <linux/clk.h>
> > +#include <linux/component.h>
> > +#include <linux/dma-iommu.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/io.h>
> > +#include <linux/iommu.h>
> > +#include <linux/iopoll.h>
> > +#include <linux/list.h>
> > +#include <linux/module.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_iommu.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/platform_device.h>
> > +#include <soc/mediatek/smi.h>
> > +#include <dt-bindings/memory/mt8173-larb-port.h>
> > +
> 
> Some missing includes:
> 
> linux/bug.h
> 	for WARN_ON()
> linux/device.h
> 	for dev_xxx() error messages, dev_get_drvdata(), etc.
> linux/err.h
> 	for error functions (IS_ERR, error definitions)
> linux/slab.h
> 	for kzalloc() etc.
> linux/spinlock.h
> 	for spinlock functions
> asm/barrier.h
> 	for wmb()
> 
> Guenter

Hi Guenter,
    Thanks for this suggestion. I'm sorry that I didn't get any build
warning or error here. Anyway I will add them and send a quick v10.




From vinod.koul at intel.com  Sun Feb 21 18:50:49 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Feb 2016 08:20:49 +0530
Subject: [PATCH v2] dmaengine: omap-dma: Implement device_synchronize
 callback
In-Reply-To: <1455181714-32057-1-git-send-email-peter.ujfalusi@ti.com>
References: <1455181714-32057-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <20160222025049.GQ19598@localhost>

On Thu, Feb 11, 2016 at 11:08:34AM +0200, Peter Ujfalusi wrote:
> We need the callback to support the dmaengine_terminate_sync().

Applied, thanks

-- 
~Vinod


From vinod.koul at intel.com  Sun Feb 21 18:51:10 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Feb 2016 08:21:10 +0530
Subject: [PATCH v2] dmaengine: edma: Implement device_synchronize callback
In-Reply-To: <1455181722-32099-1-git-send-email-peter.ujfalusi@ti.com>
References: <1455181722-32099-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <20160222025110.GR19598@localhost>

On Thu, Feb 11, 2016 at 11:08:42AM +0200, Peter Ujfalusi wrote:
> We need the callback to support the dmaengine_terminate_sync().

Applied, thanks

-- 
~Vinod


From vinod.koul at intel.com  Sun Feb 21 18:51:37 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Feb 2016 08:21:37 +0530
Subject: [PATCH] dmaengine: edma: Fetch echan->edesc while holding lock
 in edma_comletion_handler
In-Reply-To: <1455196668-9327-1-git-send-email-peter.ujfalusi@ti.com>
References: <1455196668-9327-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <20160222025136.GS19598@localhost>

On Thu, Feb 11, 2016 at 03:17:48PM +0200, Peter Ujfalusi wrote:
> In order to avoid possible race condition when client drivers are using
> dmaengine_terminate_sync() call to disable the channel.

Applied, thanks

-- 
~Vinod


From broonie at kernel.org  Sun Feb 21 18:53:03 2016
From: broonie at kernel.org (Mark Brown)
Date: Mon, 22 Feb 2016 11:53:03 +0900
Subject: [PATCH] Revert "regulator: tps65217: remove tps65217.dtsi file"
In-Reply-To: <56C98315.1000707@denx.de>
References: <1455891139-6139-1-git-send-email-peter.ujfalusi@ti.com>
 <20160219170404.GH21202@atomide.com> <56C98315.1000707@denx.de>
Message-ID: <20160222025303.GL18327@sirena.org.uk>

On Sun, Feb 21, 2016 at 10:27:49AM +0100, Heiko Schocher wrote:
> Am 19.02.2016 um 18:04 schrieb Tony Lindgren:
> >* Peter Ujfalusi <peter.ujfalusi at ti.com> [160219 06:14]:

> >I'll apply this revert into omap-for-v4.5/fixes as it fixes a
> >regression.

> Sorry for breaking ... but I have no bbw hw for testing ...
> (This is maybe a reason for having something like an automated
>  testsystem, see an example/proposal here:

Or sending boards to kernelci.org for that matter.

> But I removed this file as Mark Brown suggested it, see:

> https://lkml.org/lkml/2015/10/21/581

> So please introduce a "tps65217-am335x.dtsi" file ... Mark?

This is an OMAP DTS file, it needs the OMAP people to work on it - DT
updates don't go through the driver trees usually.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160222/6fc13fec/attachment.sig>

From robh at kernel.org  Sun Feb 21 18:53:37 2016
From: robh at kernel.org (Rob Herring)
Date: Sun, 21 Feb 2016 20:53:37 -0600
Subject: [PATCH v3 2/3] ARM: dts: Change iio_hwmon nodes to use hypen in
 node names
In-Reply-To: <c47b13603fe72737ef67ed8b90fc61516cfa2a20.1455597464.git.maitysanchayan@gmail.com>
References: <cover.1455597464.git.maitysanchayan@gmail.com>
 <c47b13603fe72737ef67ed8b90fc61516cfa2a20.1455597464.git.maitysanchayan@gmail.com>
Message-ID: <20160222025337.GA15973@rob-hp-laptop>

On Tue, Feb 16, 2016 at 10:30:54AM +0530, Sanchayan Maity wrote:
> Change iio_hwmon nodes to use hypen in node names instead of
> underscore.
> 
> Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
> ---
>  Documentation/devicetree/bindings/iio/iio-bindings.txt | 2 +-
>  arch/arm/boot/dts/imx23.dtsi                           | 2 +-
>  arch/arm/boot/dts/imx28.dtsi                           | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

No real objection here though I don't think this is really necessary. 
While we prefer '-' to '_' it's not really strong enough to change. It 
bothers me more that the node name leaks to userspace.

Rob


From robh at kernel.org  Sun Feb 21 18:53:49 2016
From: robh at kernel.org (Rob Herring)
Date: Sun, 21 Feb 2016 20:53:49 -0600
Subject: [PATCH] dma: mv_xor_v2: new driver
In-Reply-To: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20160222025349.GC15973@rob-hp-laptop>

On Mon, Feb 15, 2016 at 08:58:03AM +0100, Thomas Petazzoni wrote:
> The new mv_xor_v2 driver supports the XOR engines found in the 64-bits
> ARM from Marvell of the Armada 7K and Armada 8K family. This XOR
> engine is a completely new hardware block, entirely different from the
> one used on previous Marvell Armada platforms, which use the existing
> mv_xor driver.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  .../devicetree/bindings/dma/mv-xor-v2.txt          |  19 +
>  drivers/dma/Kconfig                                |  13 +
>  drivers/dma/Makefile                               |   1 +
>  drivers/dma/mv_xor_v2.c                            | 880 +++++++++++++++++++++
>  4 files changed, 913 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/mv-xor-v2.txt
>  create mode 100644 drivers/dma/mv_xor_v2.c
> 
> diff --git a/Documentation/devicetree/bindings/dma/mv-xor-v2.txt b/Documentation/devicetree/bindings/dma/mv-xor-v2.txt
> new file mode 100644
> index 0000000..0a03dcf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mv-xor-v2.txt
> @@ -0,0 +1,19 @@
> +* Marvell XOR v2 engines
> +
> +Required properties:
> +- compatible: Should be "marvell,mv-xor-v2"

and an SoC specific compatible please.

"marvell,mv" is a bit redundant.

> +- reg: Should contain registers location and length (two sets)
> +    the first set is the DMA registers
> +    the second set is the global registers
> +- msi-parent: Phandle to the MSI-capable interrupt controller used for
> +  interrupts.
> +
> +Example:
> +
> +	xor0 at 400000 {
> +		compatible = "marvell,mv-xor-v2";
> +		reg = <0x400000 0x1000>,
> +		      <0x410000 0x1000>;
> +		msi-parent = <&gic_v2m0>;
> +		dma-coherent;
> +	};



From robh at kernel.org  Sun Feb 21 18:53:57 2016
From: robh at kernel.org (Rob Herring)
Date: Sun, 21 Feb 2016 20:53:57 -0600
Subject: [PATCH 2/3] clk: mvebu: add AP806 core clock driver
In-Reply-To: <1455521698-7905-3-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455521698-7905-3-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20160222025357.GE15973@rob-hp-laptop>

On Mon, Feb 15, 2016 at 08:34:57AM +0100, Thomas Petazzoni wrote:
> This commit adds a new driver to handle the core clocks found in the
> AP806 HW block, which is the core block of all Armada 7K and 8K
> Marvell 64-bits processors. This core clock driver reads the
> Sample-At-Reset register to determine the frequencies of several core
> clocks: DDR, Ring and CPU clocks.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  .../clock/mvebu-armada-ap806-core-clock.txt        |  33 ++++++
>  drivers/clk/mvebu/Kconfig                          |   3 +
>  drivers/clk/mvebu/Makefile                         |   2 +-
>  drivers/clk/mvebu/ap806-core.c                     | 112 +++++++++++++++++++++
>  4 files changed, 149 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt
>  create mode 100644 drivers/clk/mvebu/ap806-core.c
> 
> diff --git a/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt
> new file mode 100644
> index 0000000..b2131bb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt
> @@ -0,0 +1,33 @@
> +* Clock bindings for Marvell MVEBU AP806 Core clocks
> +
> +The Marvell MVEBU Armada 7K/8K SoCs contain a block called AP806,
> +hosting the CPU and other core components of the CPU. This Device Tree
> +binding allows to describe the core clocks of the AP806, whose
> +frequencies are determined by reading the Sample-At-Reset (SAR)
> +register.

What else is in the AP806?

> +
> +Clock consumers must specify the desired clock by having the clock ID
> +in its "clocks" phandle cell.
> +
> +The following is a list of provided IDs and clock names for the core
> +Armada AP806 clocks:
> +
> + 0 = DDR
> + 1 = Ring
> + 2 = CPU
> +
> +Required properties:
> +- compatible: must be be one of the following:
> +	"marvell,armada-ap806-core-clock"

I'd expect this to be a sub-node of a syscon block or just a single 
clock provider for the full block. Hard to tell reviewing this without 
context of what the full clock tree looks like. 

> +- reg: must be the register address of the Sample-At-Reset (SAR) register
> +- #clock-cells: from common clock binding; shall be set to 1
> +- clock-output-names: name of the output clocks
> +
> +Example:
> +
> +	coreclk: clk at 0x6F8204 {

Drop 0x and lowercase hex.

> +		compatible = "marvell,armada-ap806-core-clock";
> +		reg = <0x6F8204 0x04>;

lowercase hex.

> +		#clock-cells = <1>;
> +		clock-output-names = "ddr", "ring", "cpu";
> +	};


From robh at kernel.org  Sun Feb 21 18:53:53 2016
From: robh at kernel.org (Rob Herring)
Date: Sun, 21 Feb 2016 20:53:53 -0600
Subject: [PATCH] irqchip: irq-mvebu-odmi: new driver
In-Reply-To: <1455522162-16425-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455522162-16425-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20160222025353.GD15973@rob-hp-laptop>

On Mon, Feb 15, 2016 at 08:42:42AM +0100, Thomas Petazzoni wrote:
> This commits adds a new irqchip driver that handles the ODMI
> controller found on Marvell 7K/8K processors. The ODMI controller
> provide MSI interrupt functionality to on-board peripherals, much like
> the GIC-v2m.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  .../marvell,odmi-controller.txt                    |  36 +++
>  drivers/irqchip/Kconfig                            |   4 +
>  drivers/irqchip/Makefile                           |   1 +
>  drivers/irqchip/irq-mvebu-odmi.c                   | 270 +++++++++++++++++++++
>  4 files changed, 311 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
>  create mode 100644 drivers/irqchip/irq-mvebu-odmi.c
> 
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
> new file mode 100644
> index 0000000..a2470af
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
> @@ -0,0 +1,36 @@
> +
> +* Marvell ODMI for MSI support
> +
> +Some Marvell SoCs have an On-Die Message Interrupt (ODMI) controller
> +which can be used by on-board peripheral for MSI interrupts.
> +
> +Required properties:
> +
> +- compatible	       : The value here should contain "marvell,odmi-controller".

SoC specific compatible too please.

> +
> +- interrupt,controller : Identifies the node as an interrupt controller.
> +
> +- msi-controller       : Identifies the node as an MSI controller.
> +
> +- marvell,odmi-frames  : Number of ODMI frames available. Each frame
> +                         provides a number of events.
> +
> +- reg		       : List of register definitions, one for each
> +                         ODMI frame.
> +
> +- marvell,spi-base     : List of GIC base SPI interrupts, one for each
> +                         ODMI frame.

Why not "interrupts" property?

> +
> +Example:
> +
> +	odmi: odmi at 300000 {
> +		compatible = "marvell,odmi-controller";
> +		interrupt-controller;
> +		msi-controller;
> +		marvell,odmi-frames = <4>;
> +		reg = <0x300000 0x4000>,
> +		      <0x304000 0x4000>,
> +		      <0x308000 0x4000>,
> +		      <0x30C000 0x4000>;
> +		marvell,spi-base = <128>, <136>, <144>, <152>;
> +	};


From robh at kernel.org  Sun Feb 21 18:54:01 2016
From: robh at kernel.org (Rob Herring)
Date: Sun, 21 Feb 2016 20:54:01 -0600
Subject: [PATCH 3/3] clk: mvebu: add AP806 ring clock driver
In-Reply-To: <1455521698-7905-4-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455521698-7905-4-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20160222025401.GF15973@rob-hp-laptop>

On Mon, Feb 15, 2016 at 08:34:58AM +0100, Thomas Petazzoni wrote:
> This commit adds a new driver to handle the ring clocks found in the
> AP806 HW block, which is the core block of all Armada 7K and 8K
> Marvell 64-bits processors. Those ring clocks are derived from the
> core ring clock handled by the AP806 core clock driver. The ring
> clocks are used by various peripherals inside the AP806.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  .../clock/mvebu-armada-ap806-ring-clock.txt        | 32 +++++++++++

Combine this with the other patch. Similar comments as the other one.

>  drivers/clk/mvebu/Kconfig                          |  3 +
>  drivers/clk/mvebu/Makefile                         |  1 +
>  drivers/clk/mvebu/ap806-ring.c                     | 65 ++++++++++++++++++++++
>  4 files changed, 101 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt
>  create mode 100644 drivers/clk/mvebu/ap806-ring.c


From robh at kernel.org  Sun Feb 21 18:54:17 2016
From: robh at kernel.org (Rob Herring)
Date: Sun, 21 Feb 2016 20:54:17 -0600
Subject: [PATCH v3 4/4] Documentation: atmel-pmc: add DT bindings for
 fast startup
In-Reply-To: <1455507630-29592-5-git-send-email-wenyou.yang@atmel.com>
References: <1455507630-29592-1-git-send-email-wenyou.yang@atmel.com>
 <1455507630-29592-5-git-send-email-wenyou.yang@atmel.com>
Message-ID: <20160222025417.GH15973@rob-hp-laptop>

On Mon, Feb 15, 2016 at 11:40:30AM +0800, Wenyou Yang wrote:
> Add DT bindings to configurate the PMC_FSMR and PMC_FSPR registers
> to trigger a fast restart signal to PMC.
> 
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> Document: binding
> 
> ---
> 
> Changes in v3:
>  - update the property description.

This is not helpful. Assume I don't remember what I told you and you 
need to jog my memory what exactly changed so I don't have to go look it 
up.

> 
> Changes in v2:
>  - change the property name and property description.
> 
>  .../devicetree/bindings/arm/atmel-pmc.txt          |   63 ++++++++++++++++++++
>  1 file changed, 63 insertions(+)

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Sun Feb 21 18:54:42 2016
From: robh at kernel.org (Rob Herring)
Date: Sun, 21 Feb 2016 20:54:42 -0600
Subject: [PATCH 1/3] irqchip: gic/realview: support more RealView DCC
 variants
In-Reply-To: <1455803172-22747-1-git-send-email-linus.walleij@linaro.org>
References: <1455803172-22747-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <20160222025442.GM15973@rob-hp-laptop>

On Thu, Feb 18, 2016 at 02:46:12PM +0100, Linus Walleij wrote:
> In the add-on file for the GIC dealing with the RealView family
> we currently only handle the PB11MPCore, let's extend this to
> manage the RealView EB ARM11MPCore as well. The Revision B of the
> ARM11MPCore core tile is a bit special and needs special handling
> as it moves a system control register around at random.
> 
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Marc Zyngier <marc.zyngier at arm.com>
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> This can be applied in isolation from the other patches so Marc
> one you're happy with it, please take it into the IRQchip tree.
> 
> There are two compatible strings getting added to the device tree
> bindings so CC to the DT list. No biggie though, just figures out
> exactly what ARM custom GIC flavor it is.
> ---
>  .../bindings/interrupt-controller/arm,gic.txt      |  2 ++

Acked-by: Rob Herring <robh at kernel.org>

>  drivers/irqchip/irq-gic-realview.c                 | 35 ++++++++++++++++++----
>  2 files changed, 32 insertions(+), 5 deletions(-)


From robh at kernel.org  Sun Feb 21 18:54:54 2016
From: robh at kernel.org (Rob Herring)
Date: Sun, 21 Feb 2016 20:54:54 -0600
Subject: [PATCH 1/2] ARM: dts: am43x-epos-evm: Add the am438 compatible
 string
In-Reply-To: <1455773381-11839-2-git-send-email-j-keerthy@ti.com>
References: <1455773381-11839-1-git-send-email-j-keerthy@ti.com>
 <1455773381-11839-2-git-send-email-j-keerthy@ti.com>
Message-ID: <20160222025454.GP15973@rob-hp-laptop>

On Thu, Feb 18, 2016 at 10:59:40AM +0530, Keerthy wrote:
> The SoCs on am43x-epos-evm are named am438x.
> Hence add the compatibility string and remove the am4372 string.

Presumably nothing is using these strings ATM for matching.

> Signed-off-by: Keerthy <j-keerthy at ti.com>
> ---
>  Documentation/devicetree/bindings/arm/omap/omap.txt | 2 +-
>  arch/arm/boot/dts/am43x-epos-evm.dts                | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Sun Feb 21 18:55:04 2016
From: robh at kernel.org (Rob Herring)
Date: Sun, 21 Feb 2016 20:55:04 -0600
Subject: [PATCH 2/3] thermal: exynos: Document number of supported
 trip-points
In-Reply-To: <1455772460-20684-2-git-send-email-k.kozlowski@samsung.com>
References: <1455772460-20684-1-git-send-email-k.kozlowski@samsung.com>
 <1455772460-20684-2-git-send-email-k.kozlowski@samsung.com>
Message-ID: <20160222025504.GQ15973@rob-hp-laptop>

On Thu, Feb 18, 2016 at 02:14:19PM +0900, Krzysztof Kozlowski wrote:
> Document the number of configurable temperature thresholds (for
> trip-points in interrupt-driven mode).
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> ---
>  Documentation/devicetree/bindings/thermal/exynos-thermal.txt | 8 ++++++++
>  1 file changed, 8 insertions(+)

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Sun Feb 21 18:55:08 2016
From: robh at kernel.org (Rob Herring)
Date: Sun, 21 Feb 2016 20:55:08 -0600
Subject: [PATCH 1/3] thermal: exynos: Document compatible for Exynos5433
 TMU
In-Reply-To: <1455772460-20684-1-git-send-email-k.kozlowski@samsung.com>
References: <1455772460-20684-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <20160222025508.GR15973@rob-hp-laptop>

On Thu, Feb 18, 2016 at 02:14:18PM +0900, Krzysztof Kozlowski wrote:
> Commit 488c7455d74c ("thermal: exynos: Add the support for Exynos5433
> TMU") added new compatible but forgot to update documentation.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> ---
>  Documentation/devicetree/bindings/thermal/exynos-thermal.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <robh at kernel.org>


From Wenyou.Yang at atmel.com  Sun Feb 21 19:03:53 2016
From: Wenyou.Yang at atmel.com (Yang, Wenyou)
Date: Mon, 22 Feb 2016 03:03:53 +0000
Subject: [PATCH v3 4/4] Documentation: atmel-pmc: add DT bindings for
 fast startup
In-Reply-To: <20160222025417.GH15973@rob-hp-laptop>
References: <1455507630-29592-1-git-send-email-wenyou.yang@atmel.com>
 <1455507630-29592-5-git-send-email-wenyou.yang@atmel.com>
 <20160222025417.GH15973@rob-hp-laptop>
Message-ID: <B256D81BAE5131468A838E5D7A243641D642649E@penmbx01>

> -----Original Message-----
> From: Rob Herring [mailto:robh at kernel.org]
> Sent: 2016?2?22? 10:54
> To: Yang, Wenyou <Wenyou.Yang at atmel.com>
> Cc: Ferre, Nicolas <Nicolas.FERRE at atmel.com>; Alexandre Belloni
> <alexandre.belloni at free-electrons.com>; Jean-Christophe Plagniol-Villard
> <plagnioj at jcrosoft.com>; Russell King <linux at arm.linux.org.uk>; linux-
> clk at vger.kernel.org; Pawel Moll <pawel.moll at arm.com>; Mark Brown
> <broonie at kernel.org>; Ian Campbell <ijc+devicetree at hellion.org.uk>; Kumar
> Gala <galak at codeaurora.org>; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; devicetree at vger.kernel.org
> Subject: Re: [PATCH v3 4/4] Documentation: atmel-pmc: add DT bindings for fast
> startup
> 
> On Mon, Feb 15, 2016 at 11:40:30AM +0800, Wenyou Yang wrote:
> > Add DT bindings to configurate the PMC_FSMR and PMC_FSPR registers to
> > trigger a fast restart signal to PMC.
> >
> > Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> > Document: binding
> >
> > ---
> >
> > Changes in v3:
> >  - update the property description.
> 
> This is not helpful. Assume I don't remember what I told you and you need to jog
> my memory what exactly changed so I don't have to go look it up.

Thank you for your instruction, I will keep it in mind.

> 
> >
> > Changes in v2:
> >  - change the property name and property description.
> >
> >  .../devicetree/bindings/arm/atmel-pmc.txt          |   63
> ++++++++++++++++++++
> >  1 file changed, 63 insertions(+)
> 
> Acked-by: Rob Herring <robh at kernel.org>

Thank you for your Acked.


Best Regards,
Wenyou Yang

From pc.liao at mediatek.com  Sun Feb 21 19:05:50 2016
From: pc.liao at mediatek.com (PC Liao)
Date: Mon, 22 Feb 2016 11:05:50 +0800
Subject: [PATCH] ASoC: mediatek: Add machine driver for ALC5650 codec
In-Reply-To: <20160219153744.GP18327@sirena.org.uk>
References: <1455849359-14581-1-git-send-email-pc.liao@mediatek.com>
 <20160219153744.GP18327@sirena.org.uk>
Message-ID: <1456110350.7576.12.camel@mtksdaap41>

Hi Mark,

On Fri, 2016-02-19 at 23:37 +0800, Mark Brown wrote:
> On Fri, Feb 19, 2016 at 10:35:59AM +0800, PC Liao wrote:
> 
> > @@ -3,3 +3,4 @@ obj-$(CONFIG_SND_SOC_MEDIATEK) += mtk-afe-pcm.o
> >  # Machine support
> >  obj-$(CONFIG_SND_SOC_MT8173_MAX98090) += mt8173-max98090.o
> >  obj-$(CONFIG_SND_SOC_MT8173_RT5650_RT5676) += mt8173-rt5650-rt5676.o
> > +obj-$(CONFIG_SND_SOC_MT8173_RT5650) += mt8173-rt5650.o
> 
> Why is this not covered by (or coverable by) the existinng RT5650-RT5657
> driver?

Thanks for your review.

Because they are different boards and have some differences like HW
configuration and mixer control, we want to separate machine driver
clearly.

Otherwise, I think I will upload this change to new version for more
clearly.
diff --git a/sound/soc/mediatek/Makefile b/sound/soc/mediatek/Makefile
index bcdcb06..dcb1440 100644
--- a/sound/soc/mediatek/Makefile
+++ b/sound/soc/mediatek/Makefile
@@ -2,5 +2,5 @@
 obj-$(CONFIG_SND_SOC_MEDIATEK) += mtk-afe-pcm.o
 # Machine support
 obj-$(CONFIG_SND_SOC_MT8173_MAX98090) += mt8173-max98090.o
-obj-$(CONFIG_SND_SOC_MT8173_RT5650_RT5676) += mt8173-rt5650-rt5676.o
 obj-$(CONFIG_SND_SOC_MT8173_RT5650) += mt8173-rt5650.o
+obj-$(CONFIG_SND_SOC_MT8173_RT5650_RT5676) += mt8173-rt5650-rt5676.o



From broonie at kernel.org  Sun Feb 21 19:12:46 2016
From: broonie at kernel.org (Mark Brown)
Date: Mon, 22 Feb 2016 12:12:46 +0900
Subject: [PATCH v7 0/2] ASoC: Add SPDIF support for Allwinner SoCs
In-Reply-To: <1456053218-16325-1-git-send-email-codekipper@gmail.com>
References: <1456053218-16325-1-git-send-email-codekipper@gmail.com>
Message-ID: <20160222031246.GQ18327@sirena.org.uk>

On Sun, Feb 21, 2016 at 12:13:36PM +0100, codekipper at gmail.com wrote:
> From: Marcus Cooper <codekipper at gmail.com>
> 
> For now just the SPDIF transmitter has been tested on a Mele A2000(A10)
> and a Itead Ibox(A20).

This was already applied.  If any updates are required or you are
submitting further changes they should be sent as incremental updates
against current git, existing patches will not be replaced.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160222/9392c740/attachment.sig>

From vinod.koul at intel.com  Sun Feb 21 19:27:30 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Feb 2016 08:57:30 +0530
Subject: [PATCH] dma: mv_xor_v2: new driver
In-Reply-To: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20160222032730.GU19598@localhost>

On Mon, Feb 15, 2016 at 08:58:03AM +0100, Thomas Petazzoni wrote:
> diff --git a/Documentation/devicetree/bindings/dma/mv-xor-v2.txt b/Documentation/devicetree/bindings/dma/mv-xor-v2.txt
> new file mode 100644
> index 0000000..0a03dcf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mv-xor-v2.txt
> @@ -0,0 +1,19 @@
> +* Marvell XOR v2 engines
> +
> +Required properties:
> +- compatible: Should be "marvell,mv-xor-v2"
> +- reg: Should contain registers location and length (two sets)
> +    the first set is the DMA registers
> +    the second set is the global registers
> +- msi-parent: Phandle to the MSI-capable interrupt controller used for
> +  interrupts.
> +
> +Example:
> +
> +	xor0 at 400000 {
> +		compatible = "marvell,mv-xor-v2";
> +		reg = <0x400000 0x1000>,
> +		      <0x410000 0x1000>;
> +		msi-parent = <&gic_v2m0>;
> +		dma-coherent;
> +	};

This should be a separate patch :)

> +/* DMA Engine Registers */
> +#define DMA_DESQ_BALR_OFF	0x000
> +#define DMA_DESQ_BAHR_OFF	0x004
> +#define DMA_DESQ_SIZE_OFF	0x008
> +#define DMA_DESQ_DONE_OFF	0x00C
> +#define   DMA_DESQ_DONE_PENDING_MASK		0x7FFF
> +#define   DMA_DESQ_DONE_PENDING_SHIFT		0
> +#define   DMA_DESQ_DONE_READ_PTR_MASK		0x1FFF
> +#define   DMA_DESQ_DONE_READ_PTR_SHIFT		16
> +#define DMA_DESQ_ARATTR_OFF	0x010
> +#define   DMA_DESQ_ATTR_CACHE_MASK		0x3F3F
> +#define   DMA_DESQ_ATTR_OUTER_SHAREABLE		0x202
> +#define   DMA_DESQ_ATTR_CACHEABLE		0x3C3C
> +#define DMA_IMSG_CDAT_OFF	0x014
> +#define DMA_IMSG_THRD_OFF	0x018
> +#define   DMA_IMSG_THRD_MASK			0x7FFF
> +#define   DMA_IMSG_THRD_SHIFT			0x0
> +#define DMA_DESQ_AWATTR_OFF	0x01C
> +  /* Same flags as DMA_DESQ_ARATTR_OFF */
> +#define DMA_DESQ_ALLOC_OFF	0x04C
> +#define   DMA_DESQ_ALLOC_WRPTR_MASK		0xFFFF
> +#define   DMA_DESQ_ALLOC_WRPTR_SHIFT		16
> +#define DMA_IMSG_BALR_OFF	0x050
> +#define DMA_IMSG_BAHR_OFF	0x054
> +#define DMA_DESQ_CTRL_OFF	0x100
> +#define	  DMA_DESQ_CTRL_32B			1
> +#define   DMA_DESQ_CTRL_128B			7
> +#define DMA_DESQ_STOP_OFF	0x800
> +#define DMA_DESQ_DEALLOC_OFF	0x804
> +#define DMA_DESQ_ADD_OFF	0x808

Please namespace these and others. Something like MRVL_XOR_XXX or anyother
patter you like would be fine...

> +
> +/* XOR Global registers */
> +#define GLOB_BW_CTRL		0x4
> +#define   GLOB_BW_CTRL_NUM_OSTD_RD_SHIFT	0
> +#define   GLOB_BW_CTRL_NUM_OSTD_RD_VAL		64
> +#define   GLOB_BW_CTRL_NUM_OSTD_WR_SHIFT	8
> +#define   GLOB_BW_CTRL_NUM_OSTD_WR_VAL		8
> +#define   GLOB_BW_CTRL_RD_BURST_LEN_SHIFT	12
> +#define   GLOB_BW_CTRL_RD_BURST_LEN_VAL		4
> +#define   GLOB_BW_CTRL_WR_BURST_LEN_SHIFT	16
> +#define	  GLOB_BW_CTRL_WR_BURST_LEN_VAL		4
> +#define GLOB_PAUSE		0x014
> +#define   GLOB_PAUSE_AXI_TIME_DIS_VAL		0x8
> +#define GLOB_SYS_INT_CAUSE	0x200
> +#define GLOB_SYS_INT_MASK	0x204
> +#define GLOB_MEM_INT_CAUSE	0x220
> +#define GLOB_MEM_INT_MASK	0x224
> +
> +#define MV_XOR_V2_MIN_DESC_SIZE		32
> +#define MV_XOR_V2_EXT_DESC_SIZE		128
> +
> +#define MV_XOR_V2_DESC_RESERVED_SIZE	12
> +#define MV_XOR_V2_DESC_BUFF_D_ADDR_SIZE	12
> +
> +#define MV_XOR_V2_CMD_LINE_NUM_MAX_D_BUF 8

These do look fine!

> +
> +/* descriptors queue size */
> +#define MV_XOR_V2_MAX_DESC_NUM	1024

Is this hardware defined?


> +static void mv_xor_v2_set_data_buffers(struct mv_xor_v2_device *xor_dev,
> +					struct mv_xor_v2_descriptor *desc,
> +					dma_addr_t src, int index)
> +{
> +	int arr_index = ((index >> 1) * 3);
> +
> +	/*
> +	 * fill the buffer's addresses to the descriptor
> +	 * The format of the buffers address for 2 sequential buffers X and X+1:

space around + please.

> +	 *  First word: Buffer-DX-Address-Low[31:0]
> +	 *  Second word:Buffer-DX+1-Address-Low[31:0]
> +	 *  Third word: DX+1-Buffer-Address-High[47:32] [31:16]
> +	 *		DX-Buffer-Address-High[47:32] [15:0]
> +	 */
> +	if ((index & 0x1) == 0) {
> +		desc->data_buff_addr[arr_index] = lower_32_bits(src);
> +
> +		/* Clear lower 16-bits */
> +		desc->data_buff_addr[arr_index + 2] &= ~0xFFFF;
> +
> +		/* Set them if we have a 64 bits DMA address */
> +		if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT))
> +			desc->data_buff_addr[arr_index + 2] |=
> +				upper_32_bits(src) & 0xFFFF;

So why should it depend on how kernel is configured?

> +	} else {
> +		desc->data_buff_addr[arr_index + 1] =
> +			lower_32_bits(src);
> +
> +		/* Clear upper 16-bits */
> +		desc->data_buff_addr[arr_index + 2] &= ~0xFFFF0000;
> +
> +		/* Set them if we have a 64 bits DMA address */
> +		if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT))
> +			desc->data_buff_addr[arr_index + 2] |=
> +				(upper_32_bits(src) & 0xFFFF) << 16;
> +	}
> +}
> +
> +/*
> + * Return the next available index in the DESQ.
> + */
> +static inline int mv_xor_v2_get_desq_write_ptr(struct mv_xor_v2_device *xor_dev)

Pls wrap with 80 chars wherever it is reasonable

> +/*
> + * Allocate resources for a channel
> + */
> +static int mv_xor_v2_alloc_chan_resources(struct dma_chan *chan)
> +{
> +	/* nothing to be done here */
> +	return 0;
> +}

No need for empty alloc

> +
> +/*
> + * Free resources of a channel
> + */
> +void mv_xor_v2_free_chan_resources(struct dma_chan *chan)
> +{
> +	/* nothing to be done here */
> +}

and free as well :)


> +static irqreturn_t mv_xor_v2_interrupt_handler(int irq, void *data)
> +{
> +	struct mv_xor_v2_device *xor_dev = data;
> +
> +	/*
> +	 * Update IMSG threshold, to disable new IMSG interrupts until
> +	 * end of the tasklet
> +	 */
> +	mv_xor_v2_set_imsg_thrd(xor_dev, MV_XOR_V2_MAX_DESC_NUM);

You don't want to check the source of interrupt?

> +static dma_cookie_t
> +mv_xor_v2_tx_submit(struct dma_async_tx_descriptor *tx)
> +{
> +	int desq_ptr;
> +	void *dest_hw_desc;
> +	dma_cookie_t cookie;
> +	struct mv_xor_v2_sw_desc *sw_desc =
> +		container_of(tx, struct mv_xor_v2_sw_desc, async_tx);
> +	struct mv_xor_v2_device *xor_dev =
> +		container_of(tx->chan, struct mv_xor_v2_device, dmachan);
> +
> +	dev_dbg(xor_dev->dmadev.dev,
> +		"%s sw_desc %p: async_tx %p\n",
> +		__func__, sw_desc, &sw_desc->async_tx);
> +
> +	/* assign coookie */
> +	spin_lock_bh(&xor_dev->cookie_lock);
> +	cookie = dma_cookie_assign(tx);
> +	spin_unlock_bh(&xor_dev->cookie_lock);
> +
> +	/* lock enqueue DESCQ */
> +	spin_lock_bh(&xor_dev->push_lock);

Why not a generic channel lock which is used in submit, issue_pending and
tasklet. What is the reason for opting different locks?

> +
> +	/* get the next available slot in the DESQ */
> +	desq_ptr = mv_xor_v2_get_desq_write_ptr(xor_dev);
> +
> +	/* copy the HW descriptor from the SW descriptor to the DESQ */
> +	dest_hw_desc = ((void *)xor_dev->hw_desq_virt +

cast to and away from void are not required

> +			(xor_dev->desc_size * desq_ptr));
> +
> +	memcpy(dest_hw_desc, &sw_desc->hw_desc, xor_dev->desc_size);
> +
> +	/* update the DMA Engine with the new descriptor */
> +	mv_xor_v2_add_desc_to_desq(xor_dev, 1);
> +
> +	/* unlock enqueue DESCQ */
> +	spin_unlock_bh(&xor_dev->push_lock);

and if IIUC, you are pushing this to HW as well, that is not quite right if
thats the case. We need to do this in issue_pending

> +static struct dma_async_tx_descriptor *
> +mv_xor_v2_prep_dma_xor(struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
> +		       unsigned int src_cnt, size_t len, unsigned long flags)
> +{
> +	struct mv_xor_v2_sw_desc	*sw_desc;
> +	struct mv_xor_v2_descriptor	*hw_descriptor;
> +	struct mv_xor_v2_device		*xor_dev;
> +	int i;
> +
> +	BUG_ON(src_cnt > MV_XOR_V2_CMD_LINE_NUM_MAX_D_BUF || src_cnt < 1);

why BUG_ON, is the system unusable after this?

> +/*
> + * poll for a transaction completion
> + */
> +static enum dma_status mv_xor_v2_tx_status(struct dma_chan *chan,
> +		dma_cookie_t cookie, struct dma_tx_state *txstate)
> +{
> +	/* return the transaction status */
> +	return dma_cookie_status(chan, cookie, txstate);

why not assign this as you status callback?

> +static void mv_xor_v2_issue_pending(struct dma_chan *chan)
> +{
> +	struct mv_xor_v2_device *xor_dev =
> +		container_of(chan, struct mv_xor_v2_device, dmachan);
> +
> +	/* Activate the channel */
> +	writel(0, xor_dev->dma_base + DMA_DESQ_STOP_OFF);

what if channel is already running?


> +static void mv_xor_v2_tasklet(unsigned long data)
> +{
> +	struct mv_xor_v2_device *xor_dev = (struct mv_xor_v2_device *) data;
> +	int pending_ptr, num_of_pending, i;
> +	struct mv_xor_v2_descriptor *next_pending_hw_desc = NULL;
> +	struct mv_xor_v2_sw_desc *next_pending_sw_desc = NULL;
> +
> +	dev_dbg(xor_dev->dmadev.dev, "%s %d\n", __func__, __LINE__);
> +
> +	/* get thepending descriptors parameters */

space after the pls

> +static struct platform_driver mv_xor_v2_driver = {
> +	.probe		= mv_xor_v2_probe,
> +	.remove		= mv_xor_v2_remove,
> +	.driver		= {
> +		.owner	= THIS_MODULE,

I dont think we need this

-- 
~Vinod


From a0393675 at ti.com  Sun Feb 21 19:27:30 2016
From: a0393675 at ti.com (Keerthy)
Date: Mon, 22 Feb 2016 08:57:30 +0530
Subject: [PATCH] ARM: OMAP: DRA7: Make use of omap_revision information
 for soc_is* calls
In-Reply-To: <20160219181514.GK21202@atomide.com>
References: <1455706123-26497-1-git-send-email-j-keerthy@ti.com>
 <20160219181514.GK21202@atomide.com>
Message-ID: <56CA8022.6010206@ti.com>



On Friday 19 February 2016 11:45 PM, Tony Lindgren wrote:
> * Keerthy <j-keerthy at ti.com> [160217 02:49]:
>> Currently of_machine_is_compatible is used to detect the soc which
>> employs string comparison operations. We already have all the required
>> information in the omap_revision. Hence make use of the same like
>> the previous OMAPs and avoid costly string comparisons.
>
> Looks good to me thanks. Applying into omap-for-v4.6/soc.

Thanks Tony.

>
> Tony
>


From maxime.ripard at free-electrons.com  Sun Feb 21 19:34:42 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sun, 21 Feb 2016 19:34:42 -0800
Subject: [PATCH] ARM: dts: sun4i: Enable USB DRC on Hyundai-a7hd
In-Reply-To: <1455656404-31191-1-git-send-email-peter@korsgaard.com>
References: <1455656404-31191-1-git-send-email-peter@korsgaard.com>
Message-ID: <20160222033442.GG19169@lukather>

Hi Peter,

On Tue, Feb 16, 2016 at 10:00:04PM +0100, Peter Korsgaard wrote:
> Enable the OTG USB controller on the A7HD.
> 
> Signed-off-by: Peter Korsgaard <peter at korsgaard.com>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160221/97797048/attachment-0001.sig>

From maxime.ripard at free-electrons.com  Sun Feb 21 19:45:17 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Sun, 21 Feb 2016 19:45:17 -0800
Subject: [PATCH v2 0/3] clk: sunxi: error checking on clock setup
In-Reply-To: <1455619568-1906-1-git-send-email-andre.przywara@arm.com>
References: <1455619568-1906-1-git-send-email-andre.przywara@arm.com>
Message-ID: <20160222034517.GH19169@lukather>

Hi,

On Tue, Feb 16, 2016 at 10:46:05AM +0000, Andre Przywara wrote:
> Setting up the clocks properly is quite critical to the system's
> operation, but currently our error handling is not very verbose.
> This series adds error handling and reporting to the sunxi clocks,
> so that any errors are correctly detected and reported. Also previous
> actions are rolled back in case something went wrong.
> This proves to be helpful in debugging clock tree issues,
> especially when adding support for new SoCs.
> I tested this on a BananaPi by deliberately misspelling
> "clock-output-names". The resulting kernel crash in
> sun4i_timer_interrupt is totally misleading, but now there is a line
> in the dmesg before saying:
> =======
> sunxi_divider_clk_setup: could not read clock-output-names for "apb0"
> =======
> 
> This applies on top of Maxime's sunxi/for-next branch.

Applied all three, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160221/2d339957/attachment.sig>

From vinod.koul at intel.com  Sun Feb 21 20:46:53 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Mon, 22 Feb 2016 10:16:53 +0530
Subject: [PATCH] dmaengine: xilinx_vdma: Fix issues with non-parking mode
In-Reply-To: <1455614946-26197-1-git-send-email-appanad@xilinx.com>
References: <1455614946-26197-1-git-send-email-appanad@xilinx.com>
Message-ID: <20160222044653.GY19598@localhost>

On Tue, Feb 16, 2016 at 02:59:06PM +0530, Kedareswara rao Appana wrote:
> This patch fixes issues with the Non-parking mode(Cirular mode).
> With the  existing driver in cirular mode if we submit frames less than h/w
> configured we simply end-up having misconfigured vdma h/w.
> This patch fixes this issue by
> ----> By queing multiple descripotrs.
> ----> By configuring the frame count register.

And quick look seems like too many changes in one patch.

> 
> Signed-off-by: Kedareswara rao Appana <appanad at xilinx.com>
> ---
>  drivers/dma/xilinx/xilinx_vdma.c | 193 ++++++++++++++++++---------------------
>  1 file changed, 91 insertions(+), 102 deletions(-)
> 
> diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
> index 6f4b501..a73c8e1 100644
> --- a/drivers/dma/xilinx/xilinx_vdma.c
> +++ b/drivers/dma/xilinx/xilinx_vdma.c
> @@ -190,8 +190,7 @@ struct xilinx_vdma_tx_descriptor {
>   * @desc_offset: TX descriptor registers offset
>   * @lock: Descriptor operation lock
>   * @pending_list: Descriptors waiting
> - * @active_desc: Active descriptor
> - * @allocated_desc: Allocated descriptor
> + * @active_list: Descriptors ready to submit

Which should probably be a separate patch describing why list management is
changed?

So can you please split up with right changelogs and resend

Thanks
-- 
~Vinod

>   * @done_list: Complete descriptors
>   * @common: DMA common channel
>   * @desc_pool: Descriptors pool
> @@ -203,9 +202,11 @@ struct xilinx_vdma_tx_descriptor {
>   * @has_sg: Support scatter transfers
>   * @genlock: Support genlock mode
>   * @err: Channel has errors
> + * @idle: Check for channel idle
>   * @tasklet: Cleanup work after irq
>   * @config: Device configuration info
>   * @flush_on_fsync: Flush on Frame sync
> + * @desc_pendingcount: Descriptor pending count
>   */
>  struct xilinx_vdma_chan {
>  	struct xilinx_vdma_device *xdev;
> @@ -213,8 +214,7 @@ struct xilinx_vdma_chan {
>  	u32 desc_offset;
>  	spinlock_t lock;
>  	struct list_head pending_list;
> -	struct xilinx_vdma_tx_descriptor *active_desc;
> -	struct xilinx_vdma_tx_descriptor *allocated_desc;
> +	struct list_head active_list;
>  	struct list_head done_list;
>  	struct dma_chan common;
>  	struct dma_pool *desc_pool;
> @@ -226,9 +226,11 @@ struct xilinx_vdma_chan {
>  	bool has_sg;
>  	bool genlock;
>  	bool err;
> +	bool idle;
>  	struct tasklet_struct tasklet;
>  	struct xilinx_vdma_config config;
>  	bool flush_on_fsync;
> +	u32 desc_pendingcount;
>  };
>  
>  /**
> @@ -342,19 +344,11 @@ static struct xilinx_vdma_tx_descriptor *
>  xilinx_vdma_alloc_tx_descriptor(struct xilinx_vdma_chan *chan)
>  {
>  	struct xilinx_vdma_tx_descriptor *desc;
> -	unsigned long flags;
> -
> -	if (chan->allocated_desc)
> -		return chan->allocated_desc;
>  
>  	desc = kzalloc(sizeof(*desc), GFP_KERNEL);
>  	if (!desc)
>  		return NULL;
>  
> -	spin_lock_irqsave(&chan->lock, flags);
> -	chan->allocated_desc = desc;
> -	spin_unlock_irqrestore(&chan->lock, flags);
> -
>  	INIT_LIST_HEAD(&desc->segments);
>  
>  	return desc;
> @@ -412,9 +406,7 @@ static void xilinx_vdma_free_descriptors(struct xilinx_vdma_chan *chan)
>  
>  	xilinx_vdma_free_desc_list(chan, &chan->pending_list);
>  	xilinx_vdma_free_desc_list(chan, &chan->done_list);
> -
> -	xilinx_vdma_free_tx_descriptor(chan, chan->active_desc);
> -	chan->active_desc = NULL;
> +	xilinx_vdma_free_desc_list(chan, &chan->active_list);
>  
>  	spin_unlock_irqrestore(&chan->lock, flags);
>  }
> @@ -529,32 +521,6 @@ static enum dma_status xilinx_vdma_tx_status(struct dma_chan *dchan,
>  }
>  
>  /**
> - * xilinx_vdma_is_running - Check if VDMA channel is running
> - * @chan: Driver specific VDMA channel
> - *
> - * Return: '1' if running, '0' if not.
> - */
> -static bool xilinx_vdma_is_running(struct xilinx_vdma_chan *chan)
> -{
> -	return !(vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
> -		 XILINX_VDMA_DMASR_HALTED) &&
> -		(vdma_ctrl_read(chan, XILINX_VDMA_REG_DMACR) &
> -		 XILINX_VDMA_DMACR_RUNSTOP);
> -}
> -
> -/**
> - * xilinx_vdma_is_idle - Check if VDMA channel is idle
> - * @chan: Driver specific VDMA channel
> - *
> - * Return: '1' if idle, '0' if not.
> - */
> -static bool xilinx_vdma_is_idle(struct xilinx_vdma_chan *chan)
> -{
> -	return vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
> -		XILINX_VDMA_DMASR_IDLE;
> -}
> -
> -/**
>   * xilinx_vdma_halt - Halt VDMA channel
>   * @chan: Driver specific VDMA channel
>   */
> @@ -614,45 +580,34 @@ static void xilinx_vdma_start(struct xilinx_vdma_chan *chan)
>  static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
>  {
>  	struct xilinx_vdma_config *config = &chan->config;
> -	struct xilinx_vdma_tx_descriptor *desc;
> -	unsigned long flags;
> +	struct xilinx_vdma_tx_descriptor *desc, *tail_desc;
>  	u32 reg;
> -	struct xilinx_vdma_tx_segment *head, *tail = NULL;
> +	struct xilinx_vdma_tx_segment *tail_segment;
>  
>  	if (chan->err)
>  		return;
>  
> -	spin_lock_irqsave(&chan->lock, flags);
> -
> -	/* There's already an active descriptor, bail out. */
> -	if (chan->active_desc)
> -		goto out_unlock;
> -
>  	if (list_empty(&chan->pending_list))
> -		goto out_unlock;
> +		return;
> +
> +	if (!chan->idle)
> +		return;
>  
>  	desc = list_first_entry(&chan->pending_list,
>  				struct xilinx_vdma_tx_descriptor, node);
> +	tail_desc = list_last_entry(&chan->pending_list,
> +				    struct xilinx_vdma_tx_descriptor, node);
>  
> -	/* If it is SG mode and hardware is busy, cannot submit */
> -	if (chan->has_sg && xilinx_vdma_is_running(chan) &&
> -	    !xilinx_vdma_is_idle(chan)) {
> -		dev_dbg(chan->dev, "DMA controller still busy\n");
> -		goto out_unlock;
> -	}
> +	tail_segment = list_last_entry(&tail_desc->segments,
> +				       struct xilinx_vdma_tx_segment, node);
>  
>  	/*
>  	 * If hardware is idle, then all descriptors on the running lists are
>  	 * done, start new transfers
>  	 */
> -	if (chan->has_sg) {
> -		head = list_first_entry(&desc->segments,
> -					struct xilinx_vdma_tx_segment, node);
> -		tail = list_entry(desc->segments.prev,
> -				  struct xilinx_vdma_tx_segment, node);
> -
> -		vdma_ctrl_write(chan, XILINX_VDMA_REG_CURDESC, head->phys);
> -	}
> +	if (chan->has_sg)
> +		vdma_ctrl_write(chan, XILINX_VDMA_REG_CURDESC,
> +				desc->async_tx.phys);
>  
>  	/* Configure the hardware using info in the config structure */
>  	reg = vdma_ctrl_read(chan, XILINX_VDMA_REG_DMACR);
> @@ -662,6 +617,9 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
>  	else
>  		reg &= ~XILINX_VDMA_DMACR_FRAMECNT_EN;
>  
> +	vdma_ctrl_write(chan, XILINX_VDMA_REG_FRMSTORE,
> +			chan->desc_pendingcount);
> +
>  	/*
>  	 * With SG, start with circular mode, so that BDs can be fetched.
>  	 * In direct register mode, if not parking, enable circular mode
> @@ -690,16 +648,19 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
>  	xilinx_vdma_start(chan);
>  
>  	if (chan->err)
> -		goto out_unlock;
> +		return;
>  
>  	/* Start the transfer */
>  	if (chan->has_sg) {
> -		vdma_ctrl_write(chan, XILINX_VDMA_REG_TAILDESC, tail->phys);
> +		vdma_ctrl_write(chan, XILINX_VDMA_REG_TAILDESC,
> +				tail_segment->phys);
>  	} else {
>  		struct xilinx_vdma_tx_segment *segment, *last = NULL;
>  		int i = 0;
>  
> -		list_for_each_entry(segment, &desc->segments, node) {
> +		list_for_each_entry(desc, &chan->pending_list, node) {
> +			segment = list_first_entry(&desc->segments,
> +					   struct xilinx_vdma_tx_segment, node);
>  			vdma_desc_write(chan,
>  					XILINX_VDMA_REG_START_ADDRESS(i++),
>  					segment->hw.buf_addr);
> @@ -707,7 +668,7 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
>  		}
>  
>  		if (!last)
> -			goto out_unlock;
> +			return;
>  
>  		/* HW expects these parameters to be same for one transaction */
>  		vdma_desc_write(chan, XILINX_VDMA_REG_HSIZE, last->hw.hsize);
> @@ -716,11 +677,9 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
>  		vdma_desc_write(chan, XILINX_VDMA_REG_VSIZE, last->hw.vsize);
>  	}
>  
> -	list_del(&desc->node);
> -	chan->active_desc = desc;
> -
> -out_unlock:
> -	spin_unlock_irqrestore(&chan->lock, flags);
> +	list_splice_tail_init(&chan->pending_list, &chan->active_list);
> +	chan->desc_pendingcount = 0;
> +	chan->idle = false;
>  }
>  
>  /**
> @@ -730,8 +689,11 @@ out_unlock:
>  static void xilinx_vdma_issue_pending(struct dma_chan *dchan)
>  {
>  	struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
> +	unsigned long flags;
>  
> +	spin_lock_irqsave(&chan->lock, flags);
>  	xilinx_vdma_start_transfer(chan);
> +	spin_unlock_irqrestore(&chan->lock, flags);
>  }
>  
>  /**
> @@ -742,24 +704,16 @@ static void xilinx_vdma_issue_pending(struct dma_chan *dchan)
>   */
>  static void xilinx_vdma_complete_descriptor(struct xilinx_vdma_chan *chan)
>  {
> -	struct xilinx_vdma_tx_descriptor *desc;
> -	unsigned long flags;
> +	struct xilinx_vdma_tx_descriptor *desc, *next;
>  
> -	spin_lock_irqsave(&chan->lock, flags);
> +	if (list_empty(&chan->active_list))
> +		return;
>  
> -	desc = chan->active_desc;
> -	if (!desc) {
> -		dev_dbg(chan->dev, "no running descriptors\n");
> -		goto out_unlock;
> +	list_for_each_entry_safe(desc, next, &chan->active_list, node) {
> +		list_del(&desc->node);
> +		dma_cookie_complete(&desc->async_tx);
> +		list_add_tail(&desc->node, &chan->done_list);
>  	}
> -
> -	dma_cookie_complete(&desc->async_tx);
> -	list_add_tail(&desc->node, &chan->done_list);
> -
> -	chan->active_desc = NULL;
> -
> -out_unlock:
> -	spin_unlock_irqrestore(&chan->lock, flags);
>  }
>  
>  /**
> @@ -870,8 +824,11 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq, void *data)
>  	}
>  
>  	if (status & XILINX_VDMA_DMASR_FRM_CNT_IRQ) {
> +		spin_lock(&chan->lock);
>  		xilinx_vdma_complete_descriptor(chan);
> +		chan->idle = true;
>  		xilinx_vdma_start_transfer(chan);
> +		spin_unlock(&chan->lock);
>  	}
>  
>  	tasklet_schedule(&chan->tasklet);
> @@ -879,6 +836,45 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq, void *data)
>  }
>  
>  /**
> + * append_desc_queue - Queuing descriptor
> + * @chan: Driver specific dma channel
> + * @desc: dma transaction descriptor
> + */
> +static void append_desc_queue(struct xilinx_vdma_chan *chan,
> +			      struct xilinx_vdma_tx_descriptor *desc)
> +{
> +	struct xilinx_vdma_tx_segment *tail_segment;
> +	struct xilinx_vdma_tx_descriptor *tail_desc;
> +
> +	if (list_empty(&chan->pending_list))
> +		goto append;
> +
> +	/*
> +	 * Add the hardware descriptor to the chain of hardware descriptors
> +	 * that already exists in memory.
> +	 */
> +	tail_desc = list_last_entry(&chan->pending_list,
> +				    struct xilinx_vdma_tx_descriptor, node);
> +	tail_segment = list_last_entry(&tail_desc->segments,
> +				       struct xilinx_vdma_tx_segment, node);
> +	tail_segment->hw.next_desc = (u32)desc->async_tx.phys;
> +
> +	/*
> +	 * Add the software descriptor and all children to the list
> +	 * of pending transactions
> +	 */
> +append:
> +	list_add_tail(&desc->node, &chan->pending_list);
> +	chan->desc_pendingcount++;
> +
> +	if (unlikely(chan->desc_pendingcount > chan->num_frms)) {
> +		dev_dbg(chan->dev, "desc pendingcount is too high\n");
> +		chan->desc_pendingcount = chan->num_frms;
> +		BUG();
> +	}
> +}
> +
> +/**
>   * xilinx_vdma_tx_submit - Submit DMA transaction
>   * @tx: Async transaction descriptor
>   *
> @@ -906,11 +902,8 @@ static dma_cookie_t xilinx_vdma_tx_submit(struct dma_async_tx_descriptor *tx)
>  
>  	cookie = dma_cookie_assign(tx);
>  
> -	/* Append the transaction to the pending transactions queue. */
> -	list_add_tail(&desc->node, &chan->pending_list);
> -
> -	/* Free the allocated desc */
> -	chan->allocated_desc = NULL;
> +	/* Put this transaction onto the tail of the pending queue */
> +	append_desc_queue(chan, desc);
>  
>  	spin_unlock_irqrestore(&chan->lock, flags);
>  
> @@ -973,13 +966,6 @@ xilinx_vdma_dma_prep_interleaved(struct dma_chan *dchan,
>  	else
>  		hw->buf_addr = xt->src_start;
>  
> -	/* Link the previous next descriptor to current */
> -	if (!list_empty(&desc->segments)) {
> -		prev = list_last_entry(&desc->segments,
> -				       struct xilinx_vdma_tx_segment, node);
> -		prev->hw.next_desc = segment->phys;
> -	}
> -
>  	/* Insert the segment into the descriptor segments list. */
>  	list_add_tail(&segment->node, &desc->segments);
>  
> @@ -988,7 +974,7 @@ xilinx_vdma_dma_prep_interleaved(struct dma_chan *dchan,
>  	/* Link the last hardware descriptor with the first. */
>  	segment = list_first_entry(&desc->segments,
>  				   struct xilinx_vdma_tx_segment, node);
> -	prev->hw.next_desc = segment->phys;
> +	desc->async_tx.phys = segment->phys;
>  
>  	return &desc->async_tx;
>  
> @@ -1127,10 +1113,12 @@ static int xilinx_vdma_chan_probe(struct xilinx_vdma_device *xdev,
>  	chan->dev = xdev->dev;
>  	chan->xdev = xdev;
>  	chan->has_sg = xdev->has_sg;
> +	chan->desc_pendingcount = 0x0;
>  
>  	spin_lock_init(&chan->lock);
>  	INIT_LIST_HEAD(&chan->pending_list);
>  	INIT_LIST_HEAD(&chan->done_list);
> +	INIT_LIST_HEAD(&chan->active_list);
>  
>  	/* Retrieve the channel properties from the device tree */
>  	has_dre = of_property_read_bool(node, "xlnx,include-dre");
> @@ -1198,6 +1186,7 @@ static int xilinx_vdma_chan_probe(struct xilinx_vdma_device *xdev,
>  
>  	list_add_tail(&chan->common.device_node, &xdev->common.channels);
>  	xdev->chan[chan->id] = chan;
> +	chan->idle = true;
>  
>  	/* Reset the channel */
>  	err = xilinx_vdma_chan_reset(chan);
> -- 
> 2.1.2
> 



From appana.durga.rao at xilinx.com  Sun Feb 21 20:45:30 2016
From: appana.durga.rao at xilinx.com (Appana Durga Kedareswara Rao)
Date: Mon, 22 Feb 2016 04:45:30 +0000
Subject: [PATCH] dmaengine: xilinx_vdma: Fix issues with non-parking mode
In-Reply-To: <20160222044653.GY19598@localhost>
References: <1455614946-26197-1-git-send-email-appanad@xilinx.com>
 <20160222044653.GY19598@localhost>
Message-ID: <C246CAC1457055469EF09E3A7AC4E11A4A5615D5@XAP-PVEXMBX01.xlnx.xilinx.com>

Hi Vinod,

> -----Original Message-----
> From: Vinod Koul [mailto:vinod.koul at intel.com]
> Sent: Monday, February 22, 2016 10:17 AM
> To: Appana Durga Kedareswara Rao
> Cc: dan.j.williams at intel.com; Michal Simek; Soren Brinkmann; Appana Durga
> Kedareswara Rao; moritz.fischer at ettus.com;
> laurent.pinchart at ideasonboard.com; luis at debethencourt.com; Anirudha
> Sarangi; dmaengine at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org
> Subject: Re: [PATCH] dmaengine: xilinx_vdma: Fix issues with non-parking mode
> 
> On Tue, Feb 16, 2016 at 02:59:06PM +0530, Kedareswara rao Appana wrote:
> > This patch fixes issues with the Non-parking mode(Cirular mode).
> > With the  existing driver in cirular mode if we submit frames less
> > than h/w configured we simply end-up having misconfigured vdma h/w.
> > This patch fixes this issue by
> > ----> By queing multiple descripotrs.
> > ----> By configuring the frame count register.
> 
> And quick look seems like too many changes in one patch.

Ok will split into multiple patches.

> 
> >
> > Signed-off-by: Kedareswara rao Appana <appanad at xilinx.com>
> > ---
> >  drivers/dma/xilinx/xilinx_vdma.c | 193
> > ++++++++++++++++++---------------------
> >  1 file changed, 91 insertions(+), 102 deletions(-)
> >
> > diff --git a/drivers/dma/xilinx/xilinx_vdma.c
> > b/drivers/dma/xilinx/xilinx_vdma.c
> > index 6f4b501..a73c8e1 100644
> > --- a/drivers/dma/xilinx/xilinx_vdma.c
> > +++ b/drivers/dma/xilinx/xilinx_vdma.c
> > @@ -190,8 +190,7 @@ struct xilinx_vdma_tx_descriptor {
> >   * @desc_offset: TX descriptor registers offset
> >   * @lock: Descriptor operation lock
> >   * @pending_list: Descriptors waiting
> > - * @active_desc: Active descriptor
> > - * @allocated_desc: Allocated descriptor
> > + * @active_list: Descriptors ready to submit
> 
> Which should probably be a separate patch describing why list management is
> changed?

Sure.

> 
> So can you please split up with right changelogs and resend

Ok will split into multiple patches and will resend.

Thanks,
Kedar.

> 
> Thanks
> --
> ~Vinod
> 
> >   * @done_list: Complete descriptors
> >   * @common: DMA common channel
> >   * @desc_pool: Descriptors pool
> > @@ -203,9 +202,11 @@ struct xilinx_vdma_tx_descriptor {
> >   * @has_sg: Support scatter transfers
> >   * @genlock: Support genlock mode
> >   * @err: Channel has errors
> > + * @idle: Check for channel idle
> >   * @tasklet: Cleanup work after irq
> >   * @config: Device configuration info
> >   * @flush_on_fsync: Flush on Frame sync
> > + * @desc_pendingcount: Descriptor pending count
> >   */
> >  struct xilinx_vdma_chan {
> >  	struct xilinx_vdma_device *xdev;
> > @@ -213,8 +214,7 @@ struct xilinx_vdma_chan {
> >  	u32 desc_offset;
> >  	spinlock_t lock;
> >  	struct list_head pending_list;
> > -	struct xilinx_vdma_tx_descriptor *active_desc;
> > -	struct xilinx_vdma_tx_descriptor *allocated_desc;
> > +	struct list_head active_list;
> >  	struct list_head done_list;
> >  	struct dma_chan common;
> >  	struct dma_pool *desc_pool;
> > @@ -226,9 +226,11 @@ struct xilinx_vdma_chan {
> >  	bool has_sg;
> >  	bool genlock;
> >  	bool err;
> > +	bool idle;
> >  	struct tasklet_struct tasklet;
> >  	struct xilinx_vdma_config config;
> >  	bool flush_on_fsync;
> > +	u32 desc_pendingcount;
> >  };
> >
> >  /**
> > @@ -342,19 +344,11 @@ static struct xilinx_vdma_tx_descriptor *
> > xilinx_vdma_alloc_tx_descriptor(struct xilinx_vdma_chan *chan)  {
> >  	struct xilinx_vdma_tx_descriptor *desc;
> > -	unsigned long flags;
> > -
> > -	if (chan->allocated_desc)
> > -		return chan->allocated_desc;
> >
> >  	desc = kzalloc(sizeof(*desc), GFP_KERNEL);
> >  	if (!desc)
> >  		return NULL;
> >
> > -	spin_lock_irqsave(&chan->lock, flags);
> > -	chan->allocated_desc = desc;
> > -	spin_unlock_irqrestore(&chan->lock, flags);
> > -
> >  	INIT_LIST_HEAD(&desc->segments);
> >
> >  	return desc;
> > @@ -412,9 +406,7 @@ static void xilinx_vdma_free_descriptors(struct
> > xilinx_vdma_chan *chan)
> >
> >  	xilinx_vdma_free_desc_list(chan, &chan->pending_list);
> >  	xilinx_vdma_free_desc_list(chan, &chan->done_list);
> > -
> > -	xilinx_vdma_free_tx_descriptor(chan, chan->active_desc);
> > -	chan->active_desc = NULL;
> > +	xilinx_vdma_free_desc_list(chan, &chan->active_list);
> >
> >  	spin_unlock_irqrestore(&chan->lock, flags);  } @@ -529,32 +521,6 @@
> > static enum dma_status xilinx_vdma_tx_status(struct dma_chan *dchan,
> > }
> >
> >  /**
> > - * xilinx_vdma_is_running - Check if VDMA channel is running
> > - * @chan: Driver specific VDMA channel
> > - *
> > - * Return: '1' if running, '0' if not.
> > - */
> > -static bool xilinx_vdma_is_running(struct xilinx_vdma_chan *chan) -{
> > -	return !(vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
> > -		 XILINX_VDMA_DMASR_HALTED) &&
> > -		(vdma_ctrl_read(chan, XILINX_VDMA_REG_DMACR) &
> > -		 XILINX_VDMA_DMACR_RUNSTOP);
> > -}
> > -
> > -/**
> > - * xilinx_vdma_is_idle - Check if VDMA channel is idle
> > - * @chan: Driver specific VDMA channel
> > - *
> > - * Return: '1' if idle, '0' if not.
> > - */
> > -static bool xilinx_vdma_is_idle(struct xilinx_vdma_chan *chan) -{
> > -	return vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
> > -		XILINX_VDMA_DMASR_IDLE;
> > -}
> > -
> > -/**
> >   * xilinx_vdma_halt - Halt VDMA channel
> >   * @chan: Driver specific VDMA channel
> >   */
> > @@ -614,45 +580,34 @@ static void xilinx_vdma_start(struct
> > xilinx_vdma_chan *chan)  static void xilinx_vdma_start_transfer(struct
> > xilinx_vdma_chan *chan)  {
> >  	struct xilinx_vdma_config *config = &chan->config;
> > -	struct xilinx_vdma_tx_descriptor *desc;
> > -	unsigned long flags;
> > +	struct xilinx_vdma_tx_descriptor *desc, *tail_desc;
> >  	u32 reg;
> > -	struct xilinx_vdma_tx_segment *head, *tail = NULL;
> > +	struct xilinx_vdma_tx_segment *tail_segment;
> >
> >  	if (chan->err)
> >  		return;
> >
> > -	spin_lock_irqsave(&chan->lock, flags);
> > -
> > -	/* There's already an active descriptor, bail out. */
> > -	if (chan->active_desc)
> > -		goto out_unlock;
> > -
> >  	if (list_empty(&chan->pending_list))
> > -		goto out_unlock;
> > +		return;
> > +
> > +	if (!chan->idle)
> > +		return;
> >
> >  	desc = list_first_entry(&chan->pending_list,
> >  				struct xilinx_vdma_tx_descriptor, node);
> > +	tail_desc = list_last_entry(&chan->pending_list,
> > +				    struct xilinx_vdma_tx_descriptor, node);
> >
> > -	/* If it is SG mode and hardware is busy, cannot submit */
> > -	if (chan->has_sg && xilinx_vdma_is_running(chan) &&
> > -	    !xilinx_vdma_is_idle(chan)) {
> > -		dev_dbg(chan->dev, "DMA controller still busy\n");
> > -		goto out_unlock;
> > -	}
> > +	tail_segment = list_last_entry(&tail_desc->segments,
> > +				       struct xilinx_vdma_tx_segment, node);
> >
> >  	/*
> >  	 * If hardware is idle, then all descriptors on the running lists are
> >  	 * done, start new transfers
> >  	 */
> > -	if (chan->has_sg) {
> > -		head = list_first_entry(&desc->segments,
> > -					struct xilinx_vdma_tx_segment, node);
> > -		tail = list_entry(desc->segments.prev,
> > -				  struct xilinx_vdma_tx_segment, node);
> > -
> > -		vdma_ctrl_write(chan, XILINX_VDMA_REG_CURDESC, head-
> >phys);
> > -	}
> > +	if (chan->has_sg)
> > +		vdma_ctrl_write(chan, XILINX_VDMA_REG_CURDESC,
> > +				desc->async_tx.phys);
> >
> >  	/* Configure the hardware using info in the config structure */
> >  	reg = vdma_ctrl_read(chan, XILINX_VDMA_REG_DMACR); @@ -662,6
> +617,9
> > @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
> >  	else
> >  		reg &= ~XILINX_VDMA_DMACR_FRAMECNT_EN;
> >
> > +	vdma_ctrl_write(chan, XILINX_VDMA_REG_FRMSTORE,
> > +			chan->desc_pendingcount);
> > +
> >  	/*
> >  	 * With SG, start with circular mode, so that BDs can be fetched.
> >  	 * In direct register mode, if not parking, enable circular mode @@
> > -690,16 +648,19 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> >  	xilinx_vdma_start(chan);
> >
> >  	if (chan->err)
> > -		goto out_unlock;
> > +		return;
> >
> >  	/* Start the transfer */
> >  	if (chan->has_sg) {
> > -		vdma_ctrl_write(chan, XILINX_VDMA_REG_TAILDESC, tail-
> >phys);
> > +		vdma_ctrl_write(chan, XILINX_VDMA_REG_TAILDESC,
> > +				tail_segment->phys);
> >  	} else {
> >  		struct xilinx_vdma_tx_segment *segment, *last = NULL;
> >  		int i = 0;
> >
> > -		list_for_each_entry(segment, &desc->segments, node) {
> > +		list_for_each_entry(desc, &chan->pending_list, node) {
> > +			segment = list_first_entry(&desc->segments,
> > +					   struct xilinx_vdma_tx_segment,
> node);
> >  			vdma_desc_write(chan,
> >
> 	XILINX_VDMA_REG_START_ADDRESS(i++),
> >  					segment->hw.buf_addr);
> > @@ -707,7 +668,7 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> >  		}
> >
> >  		if (!last)
> > -			goto out_unlock;
> > +			return;
> >
> >  		/* HW expects these parameters to be same for one
> transaction */
> >  		vdma_desc_write(chan, XILINX_VDMA_REG_HSIZE, last-
> >hw.hsize); @@
> > -716,11 +677,9 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> >  		vdma_desc_write(chan, XILINX_VDMA_REG_VSIZE, last-
> >hw.vsize);
> >  	}
> >
> > -	list_del(&desc->node);
> > -	chan->active_desc = desc;
> > -
> > -out_unlock:
> > -	spin_unlock_irqrestore(&chan->lock, flags);
> > +	list_splice_tail_init(&chan->pending_list, &chan->active_list);
> > +	chan->desc_pendingcount = 0;
> > +	chan->idle = false;
> >  }
> >
> >  /**
> > @@ -730,8 +689,11 @@ out_unlock:
> >  static void xilinx_vdma_issue_pending(struct dma_chan *dchan)  {
> >  	struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
> > +	unsigned long flags;
> >
> > +	spin_lock_irqsave(&chan->lock, flags);
> >  	xilinx_vdma_start_transfer(chan);
> > +	spin_unlock_irqrestore(&chan->lock, flags);
> >  }
> >
> >  /**
> > @@ -742,24 +704,16 @@ static void xilinx_vdma_issue_pending(struct
> dma_chan *dchan)
> >   */
> >  static void xilinx_vdma_complete_descriptor(struct xilinx_vdma_chan
> > *chan)  {
> > -	struct xilinx_vdma_tx_descriptor *desc;
> > -	unsigned long flags;
> > +	struct xilinx_vdma_tx_descriptor *desc, *next;
> >
> > -	spin_lock_irqsave(&chan->lock, flags);
> > +	if (list_empty(&chan->active_list))
> > +		return;
> >
> > -	desc = chan->active_desc;
> > -	if (!desc) {
> > -		dev_dbg(chan->dev, "no running descriptors\n");
> > -		goto out_unlock;
> > +	list_for_each_entry_safe(desc, next, &chan->active_list, node) {
> > +		list_del(&desc->node);
> > +		dma_cookie_complete(&desc->async_tx);
> > +		list_add_tail(&desc->node, &chan->done_list);
> >  	}
> > -
> > -	dma_cookie_complete(&desc->async_tx);
> > -	list_add_tail(&desc->node, &chan->done_list);
> > -
> > -	chan->active_desc = NULL;
> > -
> > -out_unlock:
> > -	spin_unlock_irqrestore(&chan->lock, flags);
> >  }
> >
> >  /**
> > @@ -870,8 +824,11 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq,
> void *data)
> >  	}
> >
> >  	if (status & XILINX_VDMA_DMASR_FRM_CNT_IRQ) {
> > +		spin_lock(&chan->lock);
> >  		xilinx_vdma_complete_descriptor(chan);
> > +		chan->idle = true;
> >  		xilinx_vdma_start_transfer(chan);
> > +		spin_unlock(&chan->lock);
> >  	}
> >
> >  	tasklet_schedule(&chan->tasklet);
> > @@ -879,6 +836,45 @@ static irqreturn_t xilinx_vdma_irq_handler(int
> > irq, void *data)  }
> >
> >  /**
> > + * append_desc_queue - Queuing descriptor
> > + * @chan: Driver specific dma channel
> > + * @desc: dma transaction descriptor
> > + */
> > +static void append_desc_queue(struct xilinx_vdma_chan *chan,
> > +			      struct xilinx_vdma_tx_descriptor *desc) {
> > +	struct xilinx_vdma_tx_segment *tail_segment;
> > +	struct xilinx_vdma_tx_descriptor *tail_desc;
> > +
> > +	if (list_empty(&chan->pending_list))
> > +		goto append;
> > +
> > +	/*
> > +	 * Add the hardware descriptor to the chain of hardware descriptors
> > +	 * that already exists in memory.
> > +	 */
> > +	tail_desc = list_last_entry(&chan->pending_list,
> > +				    struct xilinx_vdma_tx_descriptor, node);
> > +	tail_segment = list_last_entry(&tail_desc->segments,
> > +				       struct xilinx_vdma_tx_segment, node);
> > +	tail_segment->hw.next_desc = (u32)desc->async_tx.phys;
> > +
> > +	/*
> > +	 * Add the software descriptor and all children to the list
> > +	 * of pending transactions
> > +	 */
> > +append:
> > +	list_add_tail(&desc->node, &chan->pending_list);
> > +	chan->desc_pendingcount++;
> > +
> > +	if (unlikely(chan->desc_pendingcount > chan->num_frms)) {
> > +		dev_dbg(chan->dev, "desc pendingcount is too high\n");
> > +		chan->desc_pendingcount = chan->num_frms;
> > +		BUG();
> > +	}
> > +}
> > +
> > +/**
> >   * xilinx_vdma_tx_submit - Submit DMA transaction
> >   * @tx: Async transaction descriptor
> >   *
> > @@ -906,11 +902,8 @@ static dma_cookie_t xilinx_vdma_tx_submit(struct
> > dma_async_tx_descriptor *tx)
> >
> >  	cookie = dma_cookie_assign(tx);
> >
> > -	/* Append the transaction to the pending transactions queue. */
> > -	list_add_tail(&desc->node, &chan->pending_list);
> > -
> > -	/* Free the allocated desc */
> > -	chan->allocated_desc = NULL;
> > +	/* Put this transaction onto the tail of the pending queue */
> > +	append_desc_queue(chan, desc);
> >
> >  	spin_unlock_irqrestore(&chan->lock, flags);
> >
> > @@ -973,13 +966,6 @@ xilinx_vdma_dma_prep_interleaved(struct dma_chan
> *dchan,
> >  	else
> >  		hw->buf_addr = xt->src_start;
> >
> > -	/* Link the previous next descriptor to current */
> > -	if (!list_empty(&desc->segments)) {
> > -		prev = list_last_entry(&desc->segments,
> > -				       struct xilinx_vdma_tx_segment, node);
> > -		prev->hw.next_desc = segment->phys;
> > -	}
> > -
> >  	/* Insert the segment into the descriptor segments list. */
> >  	list_add_tail(&segment->node, &desc->segments);
> >
> > @@ -988,7 +974,7 @@ xilinx_vdma_dma_prep_interleaved(struct dma_chan
> *dchan,
> >  	/* Link the last hardware descriptor with the first. */
> >  	segment = list_first_entry(&desc->segments,
> >  				   struct xilinx_vdma_tx_segment, node);
> > -	prev->hw.next_desc = segment->phys;
> > +	desc->async_tx.phys = segment->phys;
> >
> >  	return &desc->async_tx;
> >
> > @@ -1127,10 +1113,12 @@ static int xilinx_vdma_chan_probe(struct
> xilinx_vdma_device *xdev,
> >  	chan->dev = xdev->dev;
> >  	chan->xdev = xdev;
> >  	chan->has_sg = xdev->has_sg;
> > +	chan->desc_pendingcount = 0x0;
> >
> >  	spin_lock_init(&chan->lock);
> >  	INIT_LIST_HEAD(&chan->pending_list);
> >  	INIT_LIST_HEAD(&chan->done_list);
> > +	INIT_LIST_HEAD(&chan->active_list);
> >
> >  	/* Retrieve the channel properties from the device tree */
> >  	has_dre = of_property_read_bool(node, "xlnx,include-dre"); @@
> > -1198,6 +1186,7 @@ static int xilinx_vdma_chan_probe(struct
> > xilinx_vdma_device *xdev,
> >
> >  	list_add_tail(&chan->common.device_node, &xdev-
> >common.channels);
> >  	xdev->chan[chan->id] = chan;
> > +	chan->idle = true;
> >
> >  	/* Reset the channel */
> >  	err = xilinx_vdma_chan_reset(chan);
> > --
> > 2.1.2
> >



From peter at hurleysoftware.com  Sun Feb 21 21:37:39 2016
From: peter at hurleysoftware.com (Peter Hurley)
Date: Sun, 21 Feb 2016 21:37:39 -0800
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <79D370BB-B7A3-4540-B7FB-81D5806853D6@codeaurora.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
 <56C470C5.2080203@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>
 <56C63FB5.2030907@hurleysoftware.com> <56C6F19D.7070206@linaro.org>
 <56C733FE.8070308@hurleysoftware.com>
 <79D370BB-B7A3-4540-B7FB-81D5806853D6@codeaurora.org>
Message-ID: <56CA9EA3.9020000@hurleysoftware.com>

On 02/19/2016 09:20 AM, Christopher Covington wrote:
> 
> 
> On February 19, 2016 10:25:50 AM EST, Peter Hurley <peter at hurleysoftware.com> wrote:
>> On 02/19/2016 02:42 AM, Aleksey Makarov wrote:
>>> Hi Peter,
>>>
>>> Thank you for review.
>>>
>>> On 02/19/2016 01:03 AM, Peter Hurley wrote:
>>>> On 02/17/2016 07:36 PM, Zheng, Lv wrote:
>>>>> Hi,
>>>>>
>>>>>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
>>>>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>>>>>> early_acpi_os_unmap_memory()
>>>>>>
>>>>>> Hi Lv,
>>>>>>
>>>>>> Thank you for review.
>>>>>>
>>>>>> On 02/17/2016 05:51 AM, Zheng, Lv wrote:
>>>>>>
>>>>>> [..]
>>>>>>
>>>>>>>>> early_acpi_os_unmap_memory() is marked as __init because it
>> calls
>>>>>>>>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is
>> not
>>>>>> set.
>>>>>>>>>
>>>>>>>>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>>>>>> so it is safe to call early_acpi_os_unmap_memory() from
>> anywhere
>>>>>>>>>
>>>>>>>>> We need this function to be non-__init because we need access
>> to
>>>>>>>>> some tables at unpredictable time--it may be before or after
>>>>>>>>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port
>> Console
>>>>>>>>> Redirection) table is needed each time a new console is
>> registered.
>>>>>>>>> It can be quite early (console_initcall) or when a module is
>> inserted.
>>>>>>>>> When this table accessed before acpi_gbl_permanent_mmap is set,
>>>>>>>>> the pointer should be unmapped.  This is exactly what this
>> function
>>>>>>>>> does.
>>>>>>>> [Lv Zheng]
>>>>>>>> Why don't you use another API instead of
>> early_acpi_os_unmap_memory()
>>>>>> in
>>>>>>>> case you want to unmap things in any cases.
>>>>>>>> acpi_os_unmap_memory() should be the one to match this purpose.
>>>>>>>> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
>>>>>>
>>>>>> As far as I understand, there exist two steps in ACPI
>> initialization:
>>>>>>
>>>>>> 1. Before acpi_gbl_permanent_mmap is set, tables received with
>>>>>> acpi_get_table_with_size()
>>>>>>    are mapped by early_memremap().  If a subsystem gets such a
>> pointer it
>>>>>> should be unmapped.
>>>>>>
>>>>>> 2  After acpi_gbl_permanent_mmap is set this pointer should not be
>> unmapped
>>>>>> at all.
>>>>>>
>>>>> [Lv Zheng] 
>>>>> This statement is wrong, this should be:
>>>>> As long as there is a __reference__ to the mapped table, the
>> pointer should not be unmapped.
>>>>> In fact, we have a series to introduce acpi_put_table() to achieve
>> this.
>>>>> So your argument is wrong from very first point.
>>>>>
>>>>>> That exactly what early_acpi_os_unmap_memory() does--it checks
>>>>>> acpi_gbl_permanent_mmap.
>>>>>> If I had used acpi_os_unmap_memory() after acpi_gbl_permanent_mmap
>> had
>>>>>> been set,
>>>>>> it would have tried to free that pointer with an oops (actually, I
>> checked that
>>>>>> and got that oops).
>>>>>>
>>>>>> So using acpi_os_unmap_memory() is not an option here, but
>>>>>> early_acpi_os_unmap_memory()
>>>>>> match perfectly.
>>>>> [Lv Zheng] 
>>>>> I don't think so.
>>>>> For definition block tables, we know for sure there will always be
>> references, until "Unload" opcode is invoked by the AML interpreter.
>>>>> But for the data tables, OSPMs should use them in this way:
>>>>> 1. map the table
>>>>> 2. parse the table and convert it to OS specific structures
>>>>> 3. unmap the table
>>>>> This helps to shrink virtual memory address space usages.
>>>>>
>>>>> So from this point of view, all data tables should be unmapped
>> right after being parsed.
>>>>> Why do you need the map to be persistent in the kernel address
>> space?
>>>>> You can always map a small table, but what if the table size is
>> very big?
>>>>>
>>>>>>
>>>>>>>> And in fact early_acpi_os_unmap_memory() should be removed.
>>>>>>
>>>>>> I don't think so -- I have explained why.  It does different
>> thing.
>>>>>> Probably it (and/or other functions in that api) should be
>> renamed.
>>>>>>
>>>>> [Lv Zheng] 
>>>>> Just let me ask one more question.
>>>>> eary_acpi_os_unmap_memory() is not used inside of ACPICA.
>>>>> How ACPICA can work with just acpi_os_unmap_memory()?
>>>>> You can check drivers/acpi/tbxxx.c.
>>>>> Especially: acpi_tb_release_temp_table() and the code invoking it.
>>>>>
>>>>>>> [Lv Zheng]
>>>>>>> One more thing is:
>>>>>>> If you can't switch your driver to use acpi_os_unmap_memory()
>> instead of
>>>>>> early_acpi_os_unmap_memory(),
>>>>>>> then it implies that your driver does have a defect.
>>>>>>
>>>>>> I still don't understand what defect, sorry.
>>>>> [Lv Zheng] 
>>>>> If you can't ensure this sequence for using the data tables:
>>>>> 1. map the table
>>>>> 2. parse the table and convert it to OS specific structure
>>>>> 3. unmap the table
>>>>> It implies there is a bug in the driver or a bug in the ACPI
>> subsystem core.
>>>>
>>>> Exactly.
>>>>
>>>> The central problem here is the way Aleksey is trying to hookup a
>> console.
>>>>
>>>> What should be happening in this series is:
>>>> 1. early map SPCR
>>>> 2. parse the SPCR table
>>>> 3. call add_preferred_console() to add the SPCR console to the
>> console table
>>>> 4. unmap SPCR
>>>
>>> This does not work.  
>>>
>>> SPCR specifies address of the console, but add_preferred_console()
>> accepts
>>> name of console and its index.  There are no general method to
>> translate address
>>> to name at such an early stage.
>>
>>
>> 	add_preferred_console(uart, 0, "io,0x3f8,115200");
>>
>> This will start a console with the 8250 driver. I've already pointed
>> this out to you in an earlier review. This is what existing firmware
>> already does.
>>
>> This is also the method you will use to start an earlycon from the
>> DBG2 table, by additionally calling setup_earlycon().
> 
> Can the device specified in DBG2 be used for both earlycon and KGDB?

I don't see why not. Since earlycon is a bootconsole, it's disabled when
the first regular console starts. I use earlycon + KGDB now on the same
device (ttyS0 == uart0 @ mmio 0x44e09000):

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.5.0-rc2+ (peter at thor) (gcc version 5.1.1 20150608 (Linaro GCC 5.1-2015.08) ) #60 PREE
MPT Sun Feb 21 20:17:16 PST 2016
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine model: TI AM335x BeagleBone Black
[    0.000000] earlycon: omap8250 at MMIO 0x44e09000 (options '')
[    0.000000] bootconsole [omap8250] enabled

....

[    3.086800] Serial: 8250/16550 driver, 32 ports, IRQ sharing disabled
[    3.099818] console [ttyS0] disabled
[    3.112402] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158, base_baud = 3000000) is a 8250
[    3.121575] console [ttyS0] enabled
[    3.121575] console [ttyS0] enabled
[    3.128678] bootconsole [omap8250] disabled
[    3.128678] bootconsole [omap8250] disabled
[    3.152397] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 159, base_baud = 3000000) is a 8250
[    3.176393] 481aa000.serial: ttyS5 at MMIO 0x481aa000 (irq = 160, base_baud = 3000000) is a 8250
[    3.185998] KGDB: Registered I/O driver kgdboc
[    3.200374] KGDB: Waiting for connection from remote gdb...


> If it can only be used for one, let's make sure the choice of
> earlycon vs KGDB is intentional rather than accidental.

If anything, a future feature would be to run KGDB over earlycon.

Regards,
Peter Hurley


From bjorn.andersson at linaro.org  Sun Feb 21 21:51:24 2016
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Sun, 21 Feb 2016 21:51:24 -0800
Subject: [PATCH v2 2/8] arm64: dts: qcom: apq8016-sbc: add usb support
In-Reply-To: <1455104202-10560-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
 <1455104202-10560-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <20160222055124.GG21240@tuxbot>

On Wed 10 Feb 03:36 PST 2016, Srinivas Kandagatla wrote:

> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
> ---
>  arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi | 15 ++++++++++
>  arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi          | 35 ++++++++++++++++++++++
>  2 files changed, 50 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
> index cbeee0b..4a79dd9 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
> @@ -10,4 +10,19 @@
>  			output-low;
>  		};
>  	};
> +
> +	usb_id_default: usb_id_default {

Labels are built with _, node names with -.

> +		pinmux {
> +			function = "gpio";
> +			pins = "gpio121";
> +		};

You don't need a separate node to specify function...

> +
> +		pinconf {
> +			pins = "gpio121";
> +			function = "gpio";

...but if you really want it, then you shouldn't specify the function
here.

> +			drive-strength = <8>;
> +			input-enable;
> +			bias-pull-up;
> +		};
> +	};
>  };
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
[..]
> +
> +	usb_id: usb-id {
> +		interrupt-parent = <&msmgpio>;

interrupt-parent is part of specifying an interrupt. You're not doing
that here, so no need to specify a parent.

> +		compatible = "linux,extcon-usb-gpio";
> +		id-gpio = <&msmgpio 121 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&usb_id_default>;
>  	};
>  };

Apart from these two nits

Acked-by: Bjorn Andersson <bjorn.andersson at linaro.org>

Regards,
Bjorn


From appana.durga.rao at xilinx.com  Sun Feb 21 21:54:36 2016
From: appana.durga.rao at xilinx.com (Kedareswara rao Appana)
Date: Mon, 22 Feb 2016 11:24:36 +0530
Subject: [PATCH v2 3/4] dmaengine: xilinx_vdma: Fix issues with non-parking
 mode
In-Reply-To: <1456120477-32134-1-git-send-email-appanad@xilinx.com>
References: <1456120477-32134-1-git-send-email-appanad@xilinx.com>
Message-ID: <1456120477-32134-3-git-send-email-appanad@xilinx.com>

This patch fixes issues with the Non-parking mode(Cirular mode).
With the  existing driver in cirular mode if we submit frames less than h/w
configured we simply end-up having misconfigured vdma h/w.
This patch fixes this issue by configuring the frame count register.

Signed-off-by: Kedareswara rao Appana <appanad at xilinx.com>
---
Changes for v2:
---> splitted the changes into multiple patches.

 drivers/dma/xilinx/xilinx_vdma.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index d646218..8db07f7 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -645,6 +645,10 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 	else
 		reg &= ~XILINX_VDMA_DMACR_FRAMECNT_EN;
 
+	/* Configure channel to allow number frame buffers */
+	vdma_ctrl_write(chan, XILINX_VDMA_REG_FRMSTORE,
+			chan->desc_pendingcount);
+
 	/*
 	 * With SG, start with circular mode, so that BDs can be fetched.
 	 * In direct register mode, if not parking, enable circular mode
-- 
2.1.2



From appana.durga.rao at xilinx.com  Sun Feb 21 21:54:35 2016
From: appana.durga.rao at xilinx.com (Kedareswara rao Appana)
Date: Mon, 22 Feb 2016 11:24:35 +0530
Subject: [PATCH v2 2/4] dmaengine: xilinx_vdma: Simplify spin lock handling
In-Reply-To: <1456120477-32134-1-git-send-email-appanad@xilinx.com>
References: <1456120477-32134-1-git-send-email-appanad@xilinx.com>
Message-ID: <1456120477-32134-2-git-send-email-appanad@xilinx.com>

This patch simplifies the spin lock handling in the driver.

Signed-off-by: Kedareswara rao Appana <appanad at xilinx.com>
---
Changes for v2:
---> splitted the changes into multiple patches.

 drivers/dma/xilinx/xilinx_vdma.c | 27 ++++++++++-----------------
 1 file changed, 10 insertions(+), 17 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 06bffec..d646218 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -605,17 +605,14 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 {
 	struct xilinx_vdma_config *config = &chan->config;
 	struct xilinx_vdma_tx_descriptor *desc, *tail_desc;
-	unsigned long flags;
 	u32 reg;
 	struct xilinx_vdma_tx_segment *tail_segment;
 
 	if (chan->err)
 		return;
 
-	spin_lock_irqsave(&chan->lock, flags);
-
 	if (list_empty(&chan->pending_list))
-		goto out_unlock;
+		return;
 
 	desc = list_first_entry(&chan->pending_list,
 				struct xilinx_vdma_tx_descriptor, node);
@@ -629,7 +626,7 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 	if (chan->has_sg && xilinx_vdma_is_running(chan) &&
 	    !xilinx_vdma_is_idle(chan)) {
 		dev_dbg(chan->dev, "DMA controller still busy\n");
-		goto out_unlock;
+		return;
 	}
 
 	/*
@@ -676,7 +673,7 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 	xilinx_vdma_start(chan);
 
 	if (chan->err)
-		goto out_unlock;
+		return;
 
 	/* Start the transfer */
 	if (chan->has_sg) {
@@ -696,7 +693,7 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 		}
 
 		if (!last)
-			goto out_unlock;
+			return;
 
 		/* HW expects these parameters to be same for one transaction */
 		vdma_desc_write(chan, XILINX_VDMA_REG_HSIZE, last->hw.hsize);
@@ -707,9 +704,6 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 
 	list_splice_tail_init(&chan->pending_list, &chan->active_list);
 	chan->desc_pendingcount = 0;
-
-out_unlock:
-	spin_unlock_irqrestore(&chan->lock, flags);
 }
 
 /**
@@ -719,8 +713,11 @@ out_unlock:
 static void xilinx_vdma_issue_pending(struct dma_chan *dchan)
 {
 	struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
+	unsigned long flags;
 
+	spin_lock_irqsave(&chan->lock, flags);
 	xilinx_vdma_start_transfer(chan);
+	spin_unlock_irqrestore(&chan->lock, flags);
 }
 
 /**
@@ -732,21 +729,15 @@ static void xilinx_vdma_issue_pending(struct dma_chan *dchan)
 static void xilinx_vdma_complete_descriptor(struct xilinx_vdma_chan *chan)
 {
 	struct xilinx_vdma_tx_descriptor *desc, *next;
-	unsigned long flags;
-
-	spin_lock_irqsave(&chan->lock, flags);
 
 	if (list_empty(&chan->active_list))
-		goto out_unlock;
+		return;
 
 	list_for_each_entry_safe(desc, next, &chan->active_list, node) {
 		list_del(&desc->node);
 		dma_cookie_complete(&desc->async_tx);
 		list_add_tail(&desc->node, &chan->done_list);
 	}
-
-out_unlock:
-	spin_unlock_irqrestore(&chan->lock, flags);
 }
 
 /**
@@ -857,8 +848,10 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq, void *data)
 	}
 
 	if (status & XILINX_VDMA_DMASR_FRM_CNT_IRQ) {
+		spin_lock(&chan->lock);
 		xilinx_vdma_complete_descriptor(chan);
 		xilinx_vdma_start_transfer(chan);
+		spin_unlock(&chan->lock);
 	}
 
 	tasklet_schedule(&chan->tasklet);
-- 
2.1.2



From appana.durga.rao at xilinx.com  Sun Feb 21 21:54:34 2016
From: appana.durga.rao at xilinx.com (Kedareswara rao Appana)
Date: Mon, 22 Feb 2016 11:24:34 +0530
Subject: [PATCH v2 1/4] dmaengine: xilinx_vdma: Improve SG engine handling
Message-ID: <1456120477-32134-1-git-send-email-appanad@xilinx.com>

The current driver allows user to queue up multiple segments
on to a single transaction descriptor. User will submit this single desc
and in the issue_pending() we decode multiple segments and submit to SG HW engine.
We free up the allocated_desc when it is submitted to the HW.

Existing code prevents the user to prepare multiple trasactions at same time as
we are overwrite with the allocated_desc.

The best utilization of HW SG engine would happen if we collate the pending
list when we start dma this patch updates the same.

Signed-off-by: Kedareswara rao Appana <appanad at xilinx.com>
---
Changes for v2:
---> splitted the changes into multiple patches.

 drivers/dma/xilinx/xilinx_vdma.c | 127 ++++++++++++++++++++++-----------------
 1 file changed, 72 insertions(+), 55 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 6f4b501..06bffec 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -190,8 +190,7 @@ struct xilinx_vdma_tx_descriptor {
  * @desc_offset: TX descriptor registers offset
  * @lock: Descriptor operation lock
  * @pending_list: Descriptors waiting
- * @active_desc: Active descriptor
- * @allocated_desc: Allocated descriptor
+ * @active_list: Descriptors ready to submit
  * @done_list: Complete descriptors
  * @common: DMA common channel
  * @desc_pool: Descriptors pool
@@ -206,6 +205,7 @@ struct xilinx_vdma_tx_descriptor {
  * @tasklet: Cleanup work after irq
  * @config: Device configuration info
  * @flush_on_fsync: Flush on Frame sync
+ * @desc_pendingcount: Descriptor pending count
  */
 struct xilinx_vdma_chan {
 	struct xilinx_vdma_device *xdev;
@@ -213,8 +213,7 @@ struct xilinx_vdma_chan {
 	u32 desc_offset;
 	spinlock_t lock;
 	struct list_head pending_list;
-	struct xilinx_vdma_tx_descriptor *active_desc;
-	struct xilinx_vdma_tx_descriptor *allocated_desc;
+	struct list_head active_list;
 	struct list_head done_list;
 	struct dma_chan common;
 	struct dma_pool *desc_pool;
@@ -229,6 +228,7 @@ struct xilinx_vdma_chan {
 	struct tasklet_struct tasklet;
 	struct xilinx_vdma_config config;
 	bool flush_on_fsync;
+	u32 desc_pendingcount;
 };
 
 /**
@@ -342,19 +342,11 @@ static struct xilinx_vdma_tx_descriptor *
 xilinx_vdma_alloc_tx_descriptor(struct xilinx_vdma_chan *chan)
 {
 	struct xilinx_vdma_tx_descriptor *desc;
-	unsigned long flags;
-
-	if (chan->allocated_desc)
-		return chan->allocated_desc;
 
 	desc = kzalloc(sizeof(*desc), GFP_KERNEL);
 	if (!desc)
 		return NULL;
 
-	spin_lock_irqsave(&chan->lock, flags);
-	chan->allocated_desc = desc;
-	spin_unlock_irqrestore(&chan->lock, flags);
-
 	INIT_LIST_HEAD(&desc->segments);
 
 	return desc;
@@ -412,9 +404,7 @@ static void xilinx_vdma_free_descriptors(struct xilinx_vdma_chan *chan)
 
 	xilinx_vdma_free_desc_list(chan, &chan->pending_list);
 	xilinx_vdma_free_desc_list(chan, &chan->done_list);
-
-	xilinx_vdma_free_tx_descriptor(chan, chan->active_desc);
-	chan->active_desc = NULL;
+	xilinx_vdma_free_desc_list(chan, &chan->active_list);
 
 	spin_unlock_irqrestore(&chan->lock, flags);
 }
@@ -614,25 +604,26 @@ static void xilinx_vdma_start(struct xilinx_vdma_chan *chan)
 static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 {
 	struct xilinx_vdma_config *config = &chan->config;
-	struct xilinx_vdma_tx_descriptor *desc;
+	struct xilinx_vdma_tx_descriptor *desc, *tail_desc;
 	unsigned long flags;
 	u32 reg;
-	struct xilinx_vdma_tx_segment *head, *tail = NULL;
+	struct xilinx_vdma_tx_segment *tail_segment;
 
 	if (chan->err)
 		return;
 
 	spin_lock_irqsave(&chan->lock, flags);
 
-	/* There's already an active descriptor, bail out. */
-	if (chan->active_desc)
-		goto out_unlock;
-
 	if (list_empty(&chan->pending_list))
 		goto out_unlock;
 
 	desc = list_first_entry(&chan->pending_list,
 				struct xilinx_vdma_tx_descriptor, node);
+	tail_desc = list_last_entry(&chan->pending_list,
+				    struct xilinx_vdma_tx_descriptor, node);
+
+	tail_segment = list_last_entry(&tail_desc->segments,
+				       struct xilinx_vdma_tx_segment, node);
 
 	/* If it is SG mode and hardware is busy, cannot submit */
 	if (chan->has_sg && xilinx_vdma_is_running(chan) &&
@@ -645,14 +636,9 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 	 * If hardware is idle, then all descriptors on the running lists are
 	 * done, start new transfers
 	 */
-	if (chan->has_sg) {
-		head = list_first_entry(&desc->segments,
-					struct xilinx_vdma_tx_segment, node);
-		tail = list_entry(desc->segments.prev,
-				  struct xilinx_vdma_tx_segment, node);
-
-		vdma_ctrl_write(chan, XILINX_VDMA_REG_CURDESC, head->phys);
-	}
+	if (chan->has_sg)
+		vdma_ctrl_write(chan, XILINX_VDMA_REG_CURDESC,
+				desc->async_tx.phys);
 
 	/* Configure the hardware using info in the config structure */
 	reg = vdma_ctrl_read(chan, XILINX_VDMA_REG_DMACR);
@@ -694,12 +680,15 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 
 	/* Start the transfer */
 	if (chan->has_sg) {
-		vdma_ctrl_write(chan, XILINX_VDMA_REG_TAILDESC, tail->phys);
+		vdma_ctrl_write(chan, XILINX_VDMA_REG_TAILDESC,
+				tail_segment->phys);
 	} else {
 		struct xilinx_vdma_tx_segment *segment, *last = NULL;
 		int i = 0;
 
-		list_for_each_entry(segment, &desc->segments, node) {
+		list_for_each_entry(desc, &chan->pending_list, node) {
+			segment = list_first_entry(&desc->segments,
+					   struct xilinx_vdma_tx_segment, node);
 			vdma_desc_write(chan,
 					XILINX_VDMA_REG_START_ADDRESS(i++),
 					segment->hw.buf_addr);
@@ -716,8 +705,8 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 		vdma_desc_write(chan, XILINX_VDMA_REG_VSIZE, last->hw.vsize);
 	}
 
-	list_del(&desc->node);
-	chan->active_desc = desc;
+	list_splice_tail_init(&chan->pending_list, &chan->active_list);
+	chan->desc_pendingcount = 0;
 
 out_unlock:
 	spin_unlock_irqrestore(&chan->lock, flags);
@@ -742,21 +731,19 @@ static void xilinx_vdma_issue_pending(struct dma_chan *dchan)
  */
 static void xilinx_vdma_complete_descriptor(struct xilinx_vdma_chan *chan)
 {
-	struct xilinx_vdma_tx_descriptor *desc;
+	struct xilinx_vdma_tx_descriptor *desc, *next;
 	unsigned long flags;
 
 	spin_lock_irqsave(&chan->lock, flags);
 
-	desc = chan->active_desc;
-	if (!desc) {
-		dev_dbg(chan->dev, "no running descriptors\n");
+	if (list_empty(&chan->active_list))
 		goto out_unlock;
-	}
-
-	dma_cookie_complete(&desc->async_tx);
-	list_add_tail(&desc->node, &chan->done_list);
 
-	chan->active_desc = NULL;
+	list_for_each_entry_safe(desc, next, &chan->active_list, node) {
+		list_del(&desc->node);
+		dma_cookie_complete(&desc->async_tx);
+		list_add_tail(&desc->node, &chan->done_list);
+	}
 
 out_unlock:
 	spin_unlock_irqrestore(&chan->lock, flags);
@@ -879,6 +866,44 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq, void *data)
 }
 
 /**
+ * append_desc_queue - Queuing descriptor
+ * @chan: Driver specific dma channel
+ * @desc: dma transaction descriptor
+ */
+static void append_desc_queue(struct xilinx_vdma_chan *chan,
+			      struct xilinx_vdma_tx_descriptor *desc)
+{
+	struct xilinx_vdma_tx_segment *tail_segment;
+	struct xilinx_vdma_tx_descriptor *tail_desc;
+
+	if (list_empty(&chan->pending_list))
+		goto append;
+
+	/*
+	 * Add the hardware descriptor to the chain of hardware descriptors
+	 * that already exists in memory.
+	 */
+	tail_desc = list_last_entry(&chan->pending_list,
+				    struct xilinx_vdma_tx_descriptor, node);
+	tail_segment = list_last_entry(&tail_desc->segments,
+				       struct xilinx_vdma_tx_segment, node);
+	tail_segment->hw.next_desc = (u32)desc->async_tx.phys;
+
+	/*
+	 * Add the software descriptor and all children to the list
+	 * of pending transactions
+	 */
+append:
+	list_add_tail(&desc->node, &chan->pending_list);
+	chan->desc_pendingcount++;
+
+	if (unlikely(chan->desc_pendingcount > chan->num_frms)) {
+		dev_dbg(chan->dev, "desc pendingcount is too high\n");
+		chan->desc_pendingcount = chan->num_frms;
+	}
+}
+
+/**
  * xilinx_vdma_tx_submit - Submit DMA transaction
  * @tx: Async transaction descriptor
  *
@@ -906,11 +931,8 @@ static dma_cookie_t xilinx_vdma_tx_submit(struct dma_async_tx_descriptor *tx)
 
 	cookie = dma_cookie_assign(tx);
 
-	/* Append the transaction to the pending transactions queue. */
-	list_add_tail(&desc->node, &chan->pending_list);
-
-	/* Free the allocated desc */
-	chan->allocated_desc = NULL;
+	/* Put this transaction onto the tail of the pending queue */
+	append_desc_queue(chan, desc);
 
 	spin_unlock_irqrestore(&chan->lock, flags);
 
@@ -973,13 +995,6 @@ xilinx_vdma_dma_prep_interleaved(struct dma_chan *dchan,
 	else
 		hw->buf_addr = xt->src_start;
 
-	/* Link the previous next descriptor to current */
-	if (!list_empty(&desc->segments)) {
-		prev = list_last_entry(&desc->segments,
-				       struct xilinx_vdma_tx_segment, node);
-		prev->hw.next_desc = segment->phys;
-	}
-
 	/* Insert the segment into the descriptor segments list. */
 	list_add_tail(&segment->node, &desc->segments);
 
@@ -988,7 +1003,7 @@ xilinx_vdma_dma_prep_interleaved(struct dma_chan *dchan,
 	/* Link the last hardware descriptor with the first. */
 	segment = list_first_entry(&desc->segments,
 				   struct xilinx_vdma_tx_segment, node);
-	prev->hw.next_desc = segment->phys;
+	desc->async_tx.phys = segment->phys;
 
 	return &desc->async_tx;
 
@@ -1127,10 +1142,12 @@ static int xilinx_vdma_chan_probe(struct xilinx_vdma_device *xdev,
 	chan->dev = xdev->dev;
 	chan->xdev = xdev;
 	chan->has_sg = xdev->has_sg;
+	chan->desc_pendingcount = 0x0;
 
 	spin_lock_init(&chan->lock);
 	INIT_LIST_HEAD(&chan->pending_list);
 	INIT_LIST_HEAD(&chan->done_list);
+	INIT_LIST_HEAD(&chan->active_list);
 
 	/* Retrieve the channel properties from the device tree */
 	has_dre = of_property_read_bool(node, "xlnx,include-dre");
-- 
2.1.2



From appana.durga.rao at xilinx.com  Sun Feb 21 21:54:37 2016
From: appana.durga.rao at xilinx.com (Kedareswara rao Appana)
Date: Mon, 22 Feb 2016 11:24:37 +0530
Subject: [PATCH v2 4/4] dmaengine: xilinx_vdma: Improve channel idle checking
In-Reply-To: <1456120477-32134-1-git-send-email-appanad@xilinx.com>
References: <1456120477-32134-1-git-send-email-appanad@xilinx.com>
Message-ID: <1456120477-32134-4-git-send-email-appanad@xilinx.com>

This patch improves the channel idle cheking by introduing
a new varibale in chan private structure.

Signed-off-by: Kedareswara rao Appana <appanad at xilinx.com>
---
Changes for v2:
---> splitted the changes into multiple patches.

 drivers/dma/xilinx/xilinx_vdma.c | 41 ++++++++--------------------------------
 1 file changed, 8 insertions(+), 33 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 8db07f7..51686d1 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -202,6 +202,7 @@ struct xilinx_vdma_tx_descriptor {
  * @has_sg: Support scatter transfers
  * @genlock: Support genlock mode
  * @err: Channel has errors
+ * @idle: Check for channel idle
  * @tasklet: Cleanup work after irq
  * @config: Device configuration info
  * @flush_on_fsync: Flush on Frame sync
@@ -225,6 +226,7 @@ struct xilinx_vdma_chan {
 	bool has_sg;
 	bool genlock;
 	bool err;
+	bool idle;
 	struct tasklet_struct tasklet;
 	struct xilinx_vdma_config config;
 	bool flush_on_fsync;
@@ -519,32 +521,6 @@ static enum dma_status xilinx_vdma_tx_status(struct dma_chan *dchan,
 }
 
 /**
- * xilinx_vdma_is_running - Check if VDMA channel is running
- * @chan: Driver specific VDMA channel
- *
- * Return: '1' if running, '0' if not.
- */
-static bool xilinx_vdma_is_running(struct xilinx_vdma_chan *chan)
-{
-	return !(vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
-		 XILINX_VDMA_DMASR_HALTED) &&
-		(vdma_ctrl_read(chan, XILINX_VDMA_REG_DMACR) &
-		 XILINX_VDMA_DMACR_RUNSTOP);
-}
-
-/**
- * xilinx_vdma_is_idle - Check if VDMA channel is idle
- * @chan: Driver specific VDMA channel
- *
- * Return: '1' if idle, '0' if not.
- */
-static bool xilinx_vdma_is_idle(struct xilinx_vdma_chan *chan)
-{
-	return vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
-		XILINX_VDMA_DMASR_IDLE;
-}
-
-/**
  * xilinx_vdma_halt - Halt VDMA channel
  * @chan: Driver specific VDMA channel
  */
@@ -614,6 +590,9 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 	if (list_empty(&chan->pending_list))
 		return;
 
+	if (!chan->idle)
+		return;
+
 	desc = list_first_entry(&chan->pending_list,
 				struct xilinx_vdma_tx_descriptor, node);
 	tail_desc = list_last_entry(&chan->pending_list,
@@ -622,13 +601,6 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 	tail_segment = list_last_entry(&tail_desc->segments,
 				       struct xilinx_vdma_tx_segment, node);
 
-	/* If it is SG mode and hardware is busy, cannot submit */
-	if (chan->has_sg && xilinx_vdma_is_running(chan) &&
-	    !xilinx_vdma_is_idle(chan)) {
-		dev_dbg(chan->dev, "DMA controller still busy\n");
-		return;
-	}
-
 	/*
 	 * If hardware is idle, then all descriptors on the running lists are
 	 * done, start new transfers
@@ -708,6 +680,7 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
 
 	list_splice_tail_init(&chan->pending_list, &chan->active_list);
 	chan->desc_pendingcount = 0;
+	chan->idle = false;
 }
 
 /**
@@ -854,6 +827,7 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq, void *data)
 	if (status & XILINX_VDMA_DMASR_FRM_CNT_IRQ) {
 		spin_lock(&chan->lock);
 		xilinx_vdma_complete_descriptor(chan);
+		chan->idle = true;
 		xilinx_vdma_start_transfer(chan);
 		spin_unlock(&chan->lock);
 	}
@@ -1212,6 +1186,7 @@ static int xilinx_vdma_chan_probe(struct xilinx_vdma_device *xdev,
 
 	list_add_tail(&chan->common.device_node, &xdev->common.channels);
 	xdev->chan[chan->id] = chan;
+	chan->idle = true;
 
 	/* Reset the channel */
 	err = xilinx_vdma_chan_reset(chan);
-- 
2.1.2



From codekipper at gmail.com  Sun Feb 21 22:10:08 2016
From: codekipper at gmail.com (Code Kipper)
Date: Mon, 22 Feb 2016 07:10:08 +0100
Subject: [linux-sunxi] Re: [PATCH v7 0/2] ASoC: Add SPDIF support for
 Allwinner SoCs
In-Reply-To: <20160222031246.GQ18327@sirena.org.uk>
References: <1456053218-16325-1-git-send-email-codekipper@gmail.com>
 <20160222031246.GQ18327@sirena.org.uk>
Message-ID: <CAEKpxBmrRYNghn40qjTO-=DEG-uyargBgE5E24RdjA2AKZ34FA@mail.gmail.com>

On 22 February 2016 at 04:12, Mark Brown <broonie at kernel.org> wrote:
> On Sun, Feb 21, 2016 at 12:13:36PM +0100, codekipper at gmail.com wrote:
>> From: Marcus Cooper <codekipper at gmail.com>
>>
>> For now just the SPDIF transmitter has been tested on a Mele A2000(A10)
>> and a Itead Ibox(A20).
>
> This was already applied.  If any updates are required or you are
> submitting further changes they should be sent as incremental updates
> against current git, existing patches will not be replaced.

No worries...I saw the ACK from Maxime and then your comment so I
thought I needed to do another revision. I can push an incremental
update later,
thanks,
CK
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


From kishon at ti.com  Sun Feb 21 22:18:21 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 22 Feb 2016 11:48:21 +0530
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <56C5D377.50901@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com> <56BACCDB.2070507@ti.com>
 <alpine.DEB.2.02.1602111921090.20757@utopia.booyaka.com>
 <56BD8091.4090007@ti.com> <56BE1454.3030002@ti.com> <56C5D377.50901@ti.com>
Message-ID: <56CAA82D.6000507@ti.com>

Sekhar,

On Thursday 18 February 2016 07:51 PM, Sekhar Nori wrote:
> On Friday 12 February 2016 10:50 PM, Suman Anna wrote:
>> Sekhar,
>> Will you be following up with above suggestion since Kishon is gonna be out?
> 
> Alright, noticed this action for me :) Went through the thread, and 
> looks like this is what we want to see?
> 
> Thanks,
> Sekhar
> 
> ---8<---
> From e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19 Mon Sep 17 00:00:00 2001
> Message-Id: <e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19.1455803758.git.nsekhar at ti.com>
> From: Sekhar Nori <nsekhar at ti.com>
> Date: Thu, 18 Feb 2016 16:49:56 +0530
> Subject: [PATCH 1/1] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS
> 
> Add a custom reset handler for DRA7x PCIeSS. This
> handler is required to deassert PCIe hardreset lines
> after they have been asserted.
> 
> This enables the PCIe driver to access registers after
> PCIeSS has been runtime enabled without having to
> deassert hardreset lines itself.
> 
> With this patch applied, used lspci to make sure
> connected PCIe device enumerates on DRA74x and DRA72x
> EVMs.
> 
> Signed-off-by: Sekhar Nori <nsekhar at ti.com>
> ---
> Applies to tag for-v4.6/omap-hwmod-a of Paul W's tree.
> 
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index b61355e2a771..252b74633e31 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1526,8 +1526,31 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
>   *
>   */
>  
> +/*
> + * As noted in documentation for _reset() in omap_hwmod.c, the stock reset
> + * functionality of OMAP HWMOD layer does not deassert the hardreset lines
> + * associated with an IP automatically leaving the driver to handle that
> + * by itself. This does not work for PCIeSS which needs the reset lines
> + * deasserted for the driver to start accessing registers.
> + *
> + * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset
> + * lines after asserting them.
> + */
> +static int dra7xx_pciess_reset(struct omap_hwmod *oh)
> +{
> +	int i;
> +
> +	for (i = 0; i < oh->rst_lines_cnt; i++) {
> +		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);
> +		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);
> +	}
> +
> +	return 0;
> +}
> +
>  static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {
>  	.name	= "pcie",
> +	.reset	= dra7xx_pciess_reset,
>  };

Thanks for the patch.

-Kishon


From zajec5 at gmail.com  Sun Feb 21 22:20:37 2016
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Mon, 22 Feb 2016 07:20:37 +0100
Subject: [PATCH] ARM: tegra: add "jedec,spi-nor" flash compatible binding
In-Reply-To: <1439705605-9127-1-git-send-email-zajec5@gmail.com>
References: <1439705605-9127-1-git-send-email-zajec5@gmail.com>
Message-ID: <CACna6rzi2NJW2JL0X4eLJOXDsLyvcsj+piBEbP6LWOUvOfctRw@mail.gmail.com>

On 16 August 2015 at 08:13, Rafa? Mi?ecki <zajec5 at gmail.com> wrote:
> Starting with commit 8947e396a829 ("Documentation: dt: mtd: replace
> "nor-jedec" binding with "jedec, spi-nor"") we have "jedec,spi-nor"
> binding indicating support for JEDEC identification.
>
> Use it for all flashes that are supposed to support READ ID op according
> to the datasheets.

Hi, for some reason it seems this patch wasn't applied. I didn't get
any comment and it was sent to all e-mails listed in MAINTAINERS in
TEGRA ARCHITECTURE SUPPORT
which I hope it enough.

Could someone pick it, please? FWIW you can find it in the patchwork:
http://patchwork.ozlabs.org/patch/507676/


From maitysanchayan at gmail.com  Sun Feb 21 22:18:35 2016
From: maitysanchayan at gmail.com (Sanchayan Maity)
Date: Mon, 22 Feb 2016 11:48:35 +0530
Subject: [PATCH v3 0/2] Add DAC driver support for Vybrid SoC
Message-ID: <cover.1456121233.git.maitysanchayan@gmail.com>

Hello,

This patchset adds support for the DAC peripheral on Vybrid SoC.
Patchset is based on top of shawn's for-next branch and has been
tested on a Toradex Colibri VF50 module.

@Jonathan
I kept the IIO_SHARED_BY_DIR instead of using IIO_SHARED_BY_ALL
since this gives "out_conversion_mode" allowing me to distinguish
this in the ABI documentation, that this is explicitly for the DAC.

Since 4.5-rc4 was released recently and assuming this makes it with
this or next version, I assumed the target kernel version would be
4.6 and used that in ABI documentation.

Feedbacks and comments most welcome.

Changes since v2:
1. Add dependencies on OF and HAS_IOMEM in Kconfig
2. Fix ordering of disabling DAC and calling iio unregister

Changes since v1:
1. Fix return type of vf610_dac_init function
2. Document conversion modes in sysfs-bus-iio-vf610
3. Remove "indexed" specification from iio_chan_spec
4. Use "return" directly from default case in switch
5. Remove DRIVER_NAME
6. Call vf610_dac_init before iio device registration
7. Define and use vf610_dac_exit function in remove and suspend

v2 of the patchset
http://www.spinics.net/lists/arm-kernel/msg482839.html

v1 of the patchset:
http://www.spinics.net/lists/arm-kernel/msg481190.html

Thanks & Regards,
Sanchayan Maity.

Sanchayan Maity (2):
  ARM: dts: vfxxx: Add DAC node for Vybrid SoC
  iio: dac: vf610_dac: Add IIO DAC driver for Vybrid SoC

 Documentation/ABI/testing/sysfs-bus-iio-vf610      |   9 +
 .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
 arch/arm/boot/dts/vfxxx.dtsi                       |  18 ++
 drivers/iio/dac/Kconfig                            |  10 +
 drivers/iio/dac/Makefile                           |   1 +
 drivers/iio/dac/vf610_dac.c                        | 298 +++++++++++++++++++++
 6 files changed, 356 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
 create mode 100644 drivers/iio/dac/vf610_dac.c

-- 
2.7.1



From maitysanchayan at gmail.com  Sun Feb 21 22:18:36 2016
From: maitysanchayan at gmail.com (Sanchayan Maity)
Date: Mon, 22 Feb 2016 11:48:36 +0530
Subject: [PATCH v3 1/2] ARM: dts: vfxxx: Add DAC node for Vybrid SoC
In-Reply-To: <cover.1456121233.git.maitysanchayan@gmail.com>
References: <cover.1456121233.git.maitysanchayan@gmail.com>
Message-ID: <cb23ab53250603e96eb4725c266d01e5376f8a68.1456121233.git.maitysanchayan@gmail.com>

Add a device tree node entry for DAC peripheral on Vybrid SoC.

Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
---
 arch/arm/boot/dts/vfxxx.dtsi | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index a5f07e3..8238069 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -602,6 +602,24 @@
 				status = "disabled";
 			};
 
+			dac0: dac at 400cc000 {
+				compatible = "fsl,vf610-dac";
+				reg = <0x400cc000 1000>;
+				interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
+				clock-names = "dac";
+				clocks = <&clks VF610_CLK_DAC0>;
+				status = "disabled";
+			};
+
+			dac1: dac at 400cd000 {
+				compatible = "fsl,vf610-dac";
+				reg = <0x400cd000 1000>;
+				interrupts = <56 IRQ_TYPE_LEVEL_HIGH>;
+				clock-names = "dac";
+				clocks = <&clks VF610_CLK_DAC1>;
+				status = "disabled";
+			};
+
 			fec0: ethernet at 400d0000 {
 				compatible = "fsl,mvf600-fec";
 				reg = <0x400d0000 0x1000>;
-- 
2.7.1



From maitysanchayan at gmail.com  Sun Feb 21 22:18:37 2016
From: maitysanchayan at gmail.com (Sanchayan Maity)
Date: Mon, 22 Feb 2016 11:48:37 +0530
Subject: [PATCH v3 2/2] iio: dac: vf610_dac: Add IIO DAC driver for Vybrid SoC
In-Reply-To: <cover.1456121233.git.maitysanchayan@gmail.com>
References: <cover.1456121233.git.maitysanchayan@gmail.com>
Message-ID: <1a70acdd3ffae273bbfe2f80c5e3952d152921df.1456121233.git.maitysanchayan@gmail.com>

Add driver support for DAC peripheral on Vybrid SoC.

Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
---
 Documentation/ABI/testing/sysfs-bus-iio-vf610      |   9 +
 .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
 drivers/iio/dac/Kconfig                            |  10 +
 drivers/iio/dac/Makefile                           |   1 +
 drivers/iio/dac/vf610_dac.c                        | 298 +++++++++++++++++++++
 5 files changed, 338 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
 create mode 100644 drivers/iio/dac/vf610_dac.c

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-vf610 b/Documentation/ABI/testing/sysfs-bus-iio-vf610
index ecbc1f4..308a675 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio-vf610
+++ b/Documentation/ABI/testing/sysfs-bus-iio-vf610
@@ -5,3 +5,12 @@ Description:
 		Specifies the hardware conversion mode used. The three
 		available modes are "normal", "high-speed" and "low-power",
 		where the last is the default mode.
+
+
+What:		/sys/bus/iio/devices/iio:deviceX/out_conversion_mode
+KernelVersion:	4.6
+Contact:	linux-iio at vger.kernel.org
+Description:
+		Specifies the hardware conversion mode used within DAC.
+		The two available modes are "high-power" and "low-power",
+		where "low-power" mode is the default mode.
diff --git a/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
new file mode 100644
index 0000000..20c6c7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
@@ -0,0 +1,20 @@
+Freescale vf610 Digital to Analog Converter bindings
+
+The devicetree bindings are for the new DAC driver written for
+vf610 SoCs from Freescale.
+
+Required properties:
+- compatible: Should contain "fsl,vf610-dac"
+- reg: Offset and length of the register set for the device
+- interrupts: Should contain the interrupt for the device
+- clocks: The clock is needed by the DAC controller
+- clock-names: Must contain "dac" matching entry in the clocks property.
+
+Example:
+dac0: dac at 400cc000 {
+	compatible = "fsl,vf610-dac";
+	reg = <0x400cc000 0x1000>;
+	interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
+	clock-names = "dac";
+	clocks = <&clks VF610_CLK_DAC0>;
+};
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index e701e28..75e9708 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -196,4 +196,14 @@ config MCP4922
 	  To compile this driver as a module, choose M here: the module
 	  will be called mcp4922.
 
+config VF610_DAC
+	tristate "Vybrid vf610 DAC driver"
+	depends on OF
+	depends on HAS_IOMEM
+	help
+	  Say yes here to support Vybrid board digital-to-analog converter.
+
+	  This driver can also be built as a module. If so, the module will
+	  be called vf610_dac.
+
 endmenu
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index 63ae056..93feb27 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_MAX517) += max517.o
 obj-$(CONFIG_MAX5821) += max5821.o
 obj-$(CONFIG_MCP4725) += mcp4725.o
 obj-$(CONFIG_MCP4922) += mcp4922.o
+obj-$(CONFIG_VF610_DAC) += vf610_dac.o
diff --git a/drivers/iio/dac/vf610_dac.c b/drivers/iio/dac/vf610_dac.c
new file mode 100644
index 0000000..c4ec777
--- /dev/null
+++ b/drivers/iio/dac/vf610_dac.c
@@ -0,0 +1,298 @@
+/*
+ * Freescale Vybrid vf610 DAC driver
+ *
+ * Copyright 2016 Toradex AG
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+#define VF610_DACx_STATCTRL		0x20
+
+#define VF610_DAC_DACEN			BIT(15)
+#define VF610_DAC_DACRFS		BIT(14)
+#define VF610_DAC_LPEN			BIT(11)
+
+#define VF610_DAC_DAT0(x)		((x) & 0xFFF)
+
+enum vf610_conversion_mode_sel {
+	VF610_DAC_CONV_HIGH_POWER,
+	VF610_DAC_CONV_LOW_POWER,
+};
+
+struct vf610_dac {
+	struct clk *clk;
+	struct device *dev;
+	enum vf610_conversion_mode_sel conv_mode;
+	void __iomem *regs;
+};
+
+static void vf610_dac_init(struct vf610_dac *info)
+{
+	int val;
+
+	info->conv_mode = VF610_DAC_CONV_LOW_POWER;
+	val = VF610_DAC_DACEN | VF610_DAC_DACRFS |
+		VF610_DAC_LPEN;
+	writel(val, info->regs + VF610_DACx_STATCTRL);
+}
+
+static void vf610_dac_exit(struct vf610_dac *info)
+{
+	int val;
+
+	val = readl(info->regs + VF610_DACx_STATCTRL);
+	val &= ~VF610_DAC_DACEN;
+	writel(val, info->regs + VF610_DACx_STATCTRL);
+}
+
+static int vf610_set_conversion_mode(struct iio_dev *indio_dev,
+				const struct iio_chan_spec *chan,
+				unsigned int mode)
+{
+	struct vf610_dac *info = iio_priv(indio_dev);
+	int val;
+
+	mutex_lock(&indio_dev->mlock);
+	info->conv_mode = mode;
+	val = readl(info->regs + VF610_DACx_STATCTRL);
+	if (mode)
+		val |= VF610_DAC_LPEN;
+	else
+		val &= ~VF610_DAC_LPEN;
+	writel(val, info->regs + VF610_DACx_STATCTRL);
+	mutex_unlock(&indio_dev->mlock);
+
+	return 0;
+}
+
+static int vf610_get_conversion_mode(struct iio_dev *indio_dev,
+				const struct iio_chan_spec *chan)
+{
+	struct vf610_dac *info = iio_priv(indio_dev);
+
+	return info->conv_mode;
+}
+
+static const char * const vf610_conv_modes[] = { "high-power", "low-power" };
+
+static const struct iio_enum vf610_conversion_mode = {
+	.items = vf610_conv_modes,
+	.num_items = ARRAY_SIZE(vf610_conv_modes),
+	.get = vf610_get_conversion_mode,
+	.set = vf610_set_conversion_mode,
+};
+
+static const struct iio_chan_spec_ext_info vf610_ext_info[] = {
+	IIO_ENUM("conversion_mode", IIO_SHARED_BY_DIR,
+		&vf610_conversion_mode),
+	{},
+};
+
+#define VF610_DAC_CHAN(_chan_type) { \
+	.type = (_chan_type), \
+	.output = 1, \
+	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+	.ext_info = vf610_ext_info, \
+}
+
+static const struct iio_chan_spec vf610_dac_iio_channels[] = {
+	VF610_DAC_CHAN(IIO_VOLTAGE),
+};
+
+static int vf610_read_raw(struct iio_dev *indio_dev,
+			struct iio_chan_spec const *chan,
+			int *val, int *val2,
+			long mask)
+{
+	struct vf610_dac *info = iio_priv(indio_dev);
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		*val = VF610_DAC_DAT0(readl(info->regs));
+		return IIO_VAL_INT;
+	case IIO_CHAN_INFO_SCALE:
+		/*
+		 * DACRFS is always 1 for valid reference and typical
+		 * reference voltage as per Vybrid datasheet is 3.3V
+		 * from section 9.1.2.1 of Vybrid datasheet
+		 */
+		*val = 3300 /* mV */;
+		*val2 = 12;
+		return IIO_VAL_FRACTIONAL_LOG2;
+
+	default:
+		return -EINVAL;
+	}
+}
+
+static int vf610_write_raw(struct iio_dev *indio_dev,
+			struct iio_chan_spec const *chan,
+			int val, int val2,
+			long mask)
+{
+	struct vf610_dac *info = iio_priv(indio_dev);
+
+	switch (mask) {
+	case IIO_CHAN_INFO_RAW:
+		mutex_lock(&indio_dev->mlock);
+		writel(VF610_DAC_DAT0(val), info->regs);
+		mutex_unlock(&indio_dev->mlock);
+		return 0;
+
+	default:
+		return -EINVAL;
+	}
+}
+
+static const struct iio_info vf610_dac_iio_info = {
+	.driver_module = THIS_MODULE,
+	.read_raw = &vf610_read_raw,
+	.write_raw = &vf610_write_raw,
+};
+
+static const struct of_device_id vf610_dac_match[] = {
+	{ .compatible = "fsl,vf610-dac", },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, vf610_dac_match);
+
+static int vf610_dac_probe(struct platform_device *pdev)
+{
+	struct iio_dev *indio_dev;
+	struct vf610_dac *info;
+	struct resource *mem;
+	int ret;
+
+	indio_dev = devm_iio_device_alloc(&pdev->dev,
+					sizeof(struct vf610_dac));
+	if (!indio_dev) {
+		dev_err(&pdev->dev, "Failed allocating iio device\n");
+		return -ENOMEM;
+	}
+
+	info = iio_priv(indio_dev);
+	info->dev = &pdev->dev;
+
+	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	info->regs = devm_ioremap_resource(&pdev->dev, mem);
+	if (IS_ERR(info->regs))
+		return PTR_ERR(info->regs);
+
+	info->clk = devm_clk_get(&pdev->dev, "dac");
+	if (IS_ERR(info->clk)) {
+		dev_err(&pdev->dev, "Failed getting clock, err = %ld\n",
+			PTR_ERR(info->clk));
+		return PTR_ERR(info->clk);
+	}
+
+	platform_set_drvdata(pdev, indio_dev);
+
+	indio_dev->name = dev_name(&pdev->dev);
+	indio_dev->dev.parent = &pdev->dev;
+	indio_dev->dev.of_node = pdev->dev.of_node;
+	indio_dev->info = &vf610_dac_iio_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+	indio_dev->channels = vf610_dac_iio_channels;
+	indio_dev->num_channels = ARRAY_SIZE(vf610_dac_iio_channels);
+
+	ret = clk_prepare_enable(info->clk);
+	if (ret) {
+		dev_err(&pdev->dev,
+			"Could not prepare or enable the clock\n");
+		return ret;
+	}
+
+	vf610_dac_init(info);
+
+	ret = iio_device_register(indio_dev);
+	if (ret) {
+		dev_err(&pdev->dev, "Couldn't register the device\n");
+		goto error_iio_device_register;
+	}
+
+	return 0;
+
+error_iio_device_register:
+	clk_disable_unprepare(info->clk);
+
+	return ret;
+}
+
+static int vf610_dac_remove(struct platform_device *pdev)
+{
+	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+	struct vf610_dac *info = iio_priv(indio_dev);
+
+	iio_device_unregister(indio_dev);
+	vf610_dac_exit(info);
+	clk_disable_unprepare(info->clk);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int vf610_dac_suspend(struct device *dev)
+{
+	struct iio_dev *indio_dev = dev_get_drvdata(dev);
+	struct vf610_dac *info = iio_priv(indio_dev);
+
+	vf610_dac_exit(info);
+	clk_disable_unprepare(info->clk);
+
+	return 0;
+}
+
+static int vf610_dac_resume(struct device *dev)
+{
+	struct iio_dev *indio_dev = dev_get_drvdata(dev);
+	struct vf610_dac *info = iio_priv(indio_dev);
+	int ret;
+
+	ret = clk_prepare_enable(info->clk);
+	if (ret)
+		return ret;
+
+	vf610_dac_init(info);
+
+	return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(vf610_dac_pm_ops, vf610_dac_suspend, vf610_dac_resume);
+
+static struct platform_driver vf610_dac_driver = {
+	.probe          = vf610_dac_probe,
+	.remove         = vf610_dac_remove,
+	.driver         = {
+		.name   = "vf610-dac",
+		.of_match_table = vf610_dac_match,
+		.pm     = &vf610_dac_pm_ops,
+	},
+};
+module_platform_driver(vf610_dac_driver);
+
+MODULE_AUTHOR("Sanchayan Maity <sanchayan.maity at toradex.com>");
+MODULE_DESCRIPTION("Freescale VF610 DAC driver");
+MODULE_LICENSE("GPL v2");
-- 
2.7.1



From paul at pwsan.com  Sun Feb 21 22:31:56 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Mon, 22 Feb 2016 06:31:56 +0000 (UTC)
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <56CAA82D.6000507@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com> <56BACCDB.2070507@ti.com>
 <alpine.DEB.2.02.1602111921090.20757@utopia.booyaka.com>
 <56BD8091.4090007@ti.com> <56BE1454.3030002@ti.com> <56C5D377.50901@ti.com>
 <56CAA82D.6000507@ti.com>
Message-ID: <alpine.DEB.2.02.1602220631300.3418@utopia.booyaka.com>

Kishon,

On Mon, 22 Feb 2016, Kishon Vijay Abraham I wrote:

> Sekhar,
> 
> On Thursday 18 February 2016 07:51 PM, Sekhar Nori wrote:
> > On Friday 12 February 2016 10:50 PM, Suman Anna wrote:
> >> Sekhar,
> >> Will you be following up with above suggestion since Kishon is gonna be out?
> > 
> > Alright, noticed this action for me :) Went through the thread, and 
> > looks like this is what we want to see?
> > 
> > Thanks,
> > Sekhar
> > 
> > ---8<---
> > From e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19 Mon Sep 17 00:00:00 2001
> > Message-Id: <e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19.1455803758.git.nsekhar at ti.com>
> > From: Sekhar Nori <nsekhar at ti.com>
> > Date: Thu, 18 Feb 2016 16:49:56 +0530
> > Subject: [PATCH 1/1] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS
> > 
> > Add a custom reset handler for DRA7x PCIeSS. This
> > handler is required to deassert PCIe hardreset lines
> > after they have been asserted.
> > 
> > This enables the PCIe driver to access registers after
> > PCIeSS has been runtime enabled without having to
> > deassert hardreset lines itself.
> > 
> > With this patch applied, used lspci to make sure
> > connected PCIe device enumerates on DRA74x and DRA72x
> > EVMs.
> > 
> > Signed-off-by: Sekhar Nori <nsekhar at ti.com>
> > ---
> > Applies to tag for-v4.6/omap-hwmod-a of Paul W's tree.
> > 
> >  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++
> >  1 file changed, 23 insertions(+)
> > 
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> > index b61355e2a771..252b74633e31 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> > @@ -1526,8 +1526,31 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
> >   *
> >   */
> >  
> > +/*
> > + * As noted in documentation for _reset() in omap_hwmod.c, the stock reset
> > + * functionality of OMAP HWMOD layer does not deassert the hardreset lines
> > + * associated with an IP automatically leaving the driver to handle that
> > + * by itself. This does not work for PCIeSS which needs the reset lines
> > + * deasserted for the driver to start accessing registers.
> > + *
> > + * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset
> > + * lines after asserting them.
> > + */
> > +static int dra7xx_pciess_reset(struct omap_hwmod *oh)
> > +{
> > +	int i;
> > +
> > +	for (i = 0; i < oh->rst_lines_cnt; i++) {
> > +		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);
> > +		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> >  static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {
> >  	.name	= "pcie",
> > +	.reset	= dra7xx_pciess_reset,
> >  };
> 
> Thanks for the patch.

Could you please test the bind/unbind functionality just to make sure it 
works?

thanks

- Paul


From gregory.0xf0 at gmail.com  Sun Feb 21 22:33:14 2016
From: gregory.0xf0 at gmail.com (Gregory Fong)
Date: Sun, 21 Feb 2016 22:33:14 -0800
Subject: [PATCH] i2c: brcmstb: allocate correct amount of memory for regmap
In-Reply-To: <1456064238-6294-1-git-send-email-wsa@the-dreams.de>
References: <1456064238-6294-1-git-send-email-wsa@the-dreams.de>
Message-ID: <CADtm3G7ZHfVyoEcAcFGC4oPX=XHyedSWDMvg6nKPLQ5_is=ZiQ@mail.gmail.com>

On Sun, Feb 21, 2016 at 6:16 AM, Wolfram Sang <wsa at the-dreams.de> wrote:
> We want the size of the struct, not of a pointer to it. To be future
> proof, just dereference the pointer to get the desired type.

This looks like it fixes like a fairly serious issue: before this
change, the driver may modify memory that wasn't allocated for this
struct.  Shouldn't this also have Cc: stable?

>
> Signed-off-by: Wolfram Sang <wsa at the-dreams.de>

Acked-by: Gregory Fong <gregory.0xf0 at gmail.com>


From peter.ujfalusi at ti.com  Sun Feb 21 23:19:18 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Mon, 22 Feb 2016 09:19:18 +0200
Subject: [PATCH 1/2] ARM: OMAP1: DMA: Provide dma_slave_map to omap-dma
In-Reply-To: <20160219214426.GK1640@darkstar.musicnaut.iki.fi>
References: <1454423227-31830-1-git-send-email-peter.ujfalusi@ti.com>
 <1454423227-31830-2-git-send-email-peter.ujfalusi@ti.com>
 <20160219214426.GK1640@darkstar.musicnaut.iki.fi>
Message-ID: <56CAB676.6080309@ti.com>

On 2016-02-19 23:44, Aaro Koskinen wrote:
> On Tue, Feb 02, 2016 at 04:27:06PM +0200, Peter Ujfalusi wrote:
>> OMAP1 can not boot in DT mode and to be able to clean up the driver
>> regarding to the dmaengine API use (switching to the new API) the
>> device/slave -> filter mapping needs to be provided to the omap-dma driver.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> 
> Acked-by: Aaro Koskinen <aaro.koskinen at iki.fi>

Thanks Aaro,

I believe the map covers all drivers using DMA, but in case I missed any we -
you ;) will notice it as they will fail to get the DMA channels. This only
going to be visible after I send the driver changes for 4.7. In such a case we
will need to add the given device to the list.

-- 
P?ter

> 
> A.
> 
>> ---
>>  arch/arm/mach-omap1/dma.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 45 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
>> index 7b02ed218a42..f6ba589cd312 100644
>> --- a/arch/arm/mach-omap1/dma.c
>> +++ b/arch/arm/mach-omap1/dma.c
>> @@ -25,6 +25,7 @@
>>  #include <linux/device.h>
>>  #include <linux/io.h>
>>  #include <linux/dma-mapping.h>
>> +#include <linux/dmaengine.h>
>>  #include <linux/omap-dma.h>
>>  #include <mach/tc.h>
>>  
>> @@ -265,6 +266,42 @@ static const struct platform_device_info omap_dma_dev_info = {
>>  	.num_res = 1,
>>  };
>>  
>> +/* OMAP730, OMAP850 */
>> +static const struct dma_slave_map omap7xx_sdma_map[] = {
>> +	{ "omap-mcbsp.1", "tx", SDMA_FILTER_PARAM(8) },
>> +	{ "omap-mcbsp.1", "rx", SDMA_FILTER_PARAM(9) },
>> +	{ "omap-mcbsp.2", "tx", SDMA_FILTER_PARAM(10) },
>> +	{ "omap-mcbsp.2", "rx", SDMA_FILTER_PARAM(11) },
>> +	{ "mmci-omap.0", "tx", SDMA_FILTER_PARAM(21) },
>> +	{ "mmci-omap.0", "rx", SDMA_FILTER_PARAM(22) },
>> +	{ "omap_udc", "rx0", SDMA_FILTER_PARAM(26) },
>> +	{ "omap_udc", "rx1", SDMA_FILTER_PARAM(27) },
>> +	{ "omap_udc", "rx2", SDMA_FILTER_PARAM(28) },
>> +	{ "omap_udc", "tx0", SDMA_FILTER_PARAM(29) },
>> +	{ "omap_udc", "tx1", SDMA_FILTER_PARAM(30) },
>> +	{ "omap_udc", "tx2", SDMA_FILTER_PARAM(31) },
>> +};
>> +
>> +/* OMAP1510, OMAP1610*/
>> +static const struct dma_slave_map omap1xxx_sdma_map[] = {
>> +	{ "omap-mcbsp.1", "tx", SDMA_FILTER_PARAM(8) },
>> +	{ "omap-mcbsp.1", "rx", SDMA_FILTER_PARAM(9) },
>> +	{ "omap-mcbsp.3", "tx", SDMA_FILTER_PARAM(10) },
>> +	{ "omap-mcbsp.3", "rx", SDMA_FILTER_PARAM(11) },
>> +	{ "omap-mcbsp.2", "tx", SDMA_FILTER_PARAM(16) },
>> +	{ "omap-mcbsp.2", "rx", SDMA_FILTER_PARAM(17) },
>> +	{ "mmci-omap.0", "tx", SDMA_FILTER_PARAM(21) },
>> +	{ "mmci-omap.0", "rx", SDMA_FILTER_PARAM(22) },
>> +	{ "omap_udc", "rx0", SDMA_FILTER_PARAM(26) },
>> +	{ "omap_udc", "rx1", SDMA_FILTER_PARAM(27) },
>> +	{ "omap_udc", "rx2", SDMA_FILTER_PARAM(28) },
>> +	{ "omap_udc", "tx0", SDMA_FILTER_PARAM(29) },
>> +	{ "omap_udc", "tx1", SDMA_FILTER_PARAM(30) },
>> +	{ "omap_udc", "tx2", SDMA_FILTER_PARAM(31) },
>> +	{ "mmci-omap.1", "tx", SDMA_FILTER_PARAM(54) },
>> +	{ "mmci-omap.1", "rx", SDMA_FILTER_PARAM(55) },
>> +};
>> +
>>  static struct omap_system_dma_plat_info dma_plat_info __initdata = {
>>  	.reg_map	= reg_map,
>>  	.channel_stride	= 0x40,
>> @@ -342,6 +379,14 @@ static int __init omap1_system_dma_init(void)
>>  	p.dma_attr = d;
>>  	p.errata = configure_dma_errata();
>>  
>> +	if (cpu_is_omap7xx()) {
>> +		p.slave_map = omap7xx_sdma_map;
>> +		p.slavecnt = ARRAY_SIZE(omap7xx_sdma_map);
>> +	} else {
>> +		p.slave_map = omap1xxx_sdma_map;
>> +		p.slavecnt = ARRAY_SIZE(omap1xxx_sdma_map);
>> +	}
>> +
>>  	ret = platform_device_add_data(pdev, &p, sizeof(p));
>>  	if (ret) {
>>  		dev_err(&pdev->dev, "%s: Unable to add resources for %s%d\n",
>> -- 
>> 2.7.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



From thomas.petazzoni at free-electrons.com  Sun Feb 21 23:21:30 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 22 Feb 2016 08:21:30 +0100
Subject: [PATCH] dma: mv_xor_v2: new driver
In-Reply-To: <20160222025349.GC15973@rob-hp-laptop>
References: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160222025349.GC15973@rob-hp-laptop>
Message-ID: <20160222082130.75e9c540@free-electrons.com>

Rob,

On Sun, 21 Feb 2016 20:53:49 -0600, Rob Herring wrote:

> > +Required properties:
> > +- compatible: Should be "marvell,mv-xor-v2"
> 
> and an SoC specific compatible please.

So you mean *both* marvell,mv-xor-v2 and a SoC specific compatible?

> "marvell,mv" is a bit redundant.

True. I guess marvell,xor-v2 will do.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From yamada.masahiro at socionext.com  Sun Feb 21 23:31:16 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon, 22 Feb 2016 16:31:16 +0900
Subject: [PATCH 5/6] ARM: decompressor: merge piggy.*.S and simplify Makefile
In-Reply-To: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456126277-14633-6-git-send-email-yamada.masahiro@socionext.com>

The files piggy.$(suffix).S are similar enough to be merged into a
single file.  This also allows clean up of the Makefile.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/compressed/.gitignore                |  6 +-----
 arch/arm/boot/compressed/Makefile                  | 14 ++++++--------
 arch/arm/boot/compressed/{piggy.gzip.S => piggy.S} |  2 +-
 arch/arm/boot/compressed/piggy.lz4.S               |  6 ------
 arch/arm/boot/compressed/piggy.lzma.S              |  6 ------
 arch/arm/boot/compressed/piggy.lzo.S               |  6 ------
 arch/arm/boot/compressed/piggy.xzkern.S            |  6 ------
 7 files changed, 8 insertions(+), 38 deletions(-)
 rename arch/arm/boot/compressed/{piggy.gzip.S => piggy.S} (67%)
 delete mode 100644 arch/arm/boot/compressed/piggy.lz4.S
 delete mode 100644 arch/arm/boot/compressed/piggy.lzma.S
 delete mode 100644 arch/arm/boot/compressed/piggy.lzo.S
 delete mode 100644 arch/arm/boot/compressed/piggy.xzkern.S

diff --git a/arch/arm/boot/compressed/.gitignore b/arch/arm/boot/compressed/.gitignore
index 0714e03..86b2f5d 100644
--- a/arch/arm/boot/compressed/.gitignore
+++ b/arch/arm/boot/compressed/.gitignore
@@ -3,11 +3,7 @@ bswapsdi2.S
 font.c
 lib1funcs.S
 hyp-stub.S
-piggy.gzip
-piggy.lzo
-piggy.lzma
-piggy.xzkern
-piggy.lz4
+piggy_data
 vmlinux
 vmlinux.lds
 
diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 903b953..3243f09 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -89,14 +89,12 @@ ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
 OBJS	+= $(libfdt_objs) atags_to_fdt.o
 endif
 
-targets       := vmlinux vmlinux.lds \
-		 piggy.$(suffix_y) piggy.$(suffix_y).o \
+targets       := vmlinux vmlinux.lds piggy_data piggy.o \
 		 lib1funcs.o ashldi3.o bswapsdi2.o \
 		 head.o $(OBJS)
 
-clean-files += piggy.gzip piggy.lzo piggy.lzma piggy.xzkern piggy.lz4 \
-		 lib1funcs.S ashldi3.S bswapsdi2.S $(libfdt) $(libfdt_hdrs) \
-		 hyp-stub.S
+clean-files += piggy_data lib1funcs.S ashldi3.S bswapsdi2.S \
+		$(libfdt) $(libfdt_hdrs) hyp-stub.S
 
 KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING
 
@@ -177,17 +175,17 @@ fi
 
 efi-obj-$(CONFIG_EFI_STUB) := $(objtree)/drivers/firmware/efi/libstub/lib.a
 
-$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.$(suffix_y).o \
+$(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o \
 		$(addprefix $(obj)/, $(OBJS)) $(lib1funcs) $(ashldi3) \
 		$(bswapsdi2) $(efi-obj-y) FORCE
 	@$(check_for_multiple_zreladdr)
 	$(call if_changed,ld)
 	@$(check_for_bad_syms)
 
-$(obj)/piggy.$(suffix_y): $(obj)/../Image FORCE
+$(obj)/piggy_data: $(obj)/../Image FORCE
 	$(call if_changed,$(suffix_y))
 
-$(obj)/piggy.$(suffix_y).o:  $(obj)/piggy.$(suffix_y)
+$(obj)/piggy.o: $(obj)/piggy_data
 
 CFLAGS_font.o := -Dstatic=
 
diff --git a/arch/arm/boot/compressed/piggy.gzip.S b/arch/arm/boot/compressed/piggy.S
similarity index 67%
rename from arch/arm/boot/compressed/piggy.gzip.S
rename to arch/arm/boot/compressed/piggy.S
index a68adf9..f720884 100644
--- a/arch/arm/boot/compressed/piggy.gzip.S
+++ b/arch/arm/boot/compressed/piggy.S
@@ -1,6 +1,6 @@
 	.section .piggydata,#alloc
 	.globl	input_data
 input_data:
-	.incbin	"arch/arm/boot/compressed/piggy.gzip"
+	.incbin	"arch/arm/boot/compressed/piggy_data"
 	.globl	input_data_end
 input_data_end:
diff --git a/arch/arm/boot/compressed/piggy.lz4.S b/arch/arm/boot/compressed/piggy.lz4.S
deleted file mode 100644
index 3d9a575..0000000
--- a/arch/arm/boot/compressed/piggy.lz4.S
+++ /dev/null
@@ -1,6 +0,0 @@
-	.section .piggydata,#alloc
-	.globl	input_data
-input_data:
-	.incbin	"arch/arm/boot/compressed/piggy.lz4"
-	.globl	input_data_end
-input_data_end:
diff --git a/arch/arm/boot/compressed/piggy.lzma.S b/arch/arm/boot/compressed/piggy.lzma.S
deleted file mode 100644
index d7e69cf..0000000
--- a/arch/arm/boot/compressed/piggy.lzma.S
+++ /dev/null
@@ -1,6 +0,0 @@
-	.section .piggydata,#alloc
-	.globl	input_data
-input_data:
-	.incbin	"arch/arm/boot/compressed/piggy.lzma"
-	.globl	input_data_end
-input_data_end:
diff --git a/arch/arm/boot/compressed/piggy.lzo.S b/arch/arm/boot/compressed/piggy.lzo.S
deleted file mode 100644
index a425ad9..0000000
--- a/arch/arm/boot/compressed/piggy.lzo.S
+++ /dev/null
@@ -1,6 +0,0 @@
-	.section .piggydata,#alloc
-	.globl	input_data
-input_data:
-	.incbin	"arch/arm/boot/compressed/piggy.lzo"
-	.globl	input_data_end
-input_data_end:
diff --git a/arch/arm/boot/compressed/piggy.xzkern.S b/arch/arm/boot/compressed/piggy.xzkern.S
deleted file mode 100644
index 5703f30..0000000
--- a/arch/arm/boot/compressed/piggy.xzkern.S
+++ /dev/null
@@ -1,6 +0,0 @@
-	.section .piggydata,#alloc
-	.globl	input_data
-input_data:
-	.incbin	"arch/arm/boot/compressed/piggy.xzkern"
-	.globl	input_data_end
-input_data_end:
-- 
1.9.1



From yamada.masahiro at socionext.com  Sun Feb 21 23:31:13 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon, 22 Feb 2016 16:31:13 +0900
Subject: [PATCH 2/6] ARM: decompressor: drop more unneeded assignments to
 "targets"
In-Reply-To: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456126277-14633-3-git-send-email-yamada.masahiro@socionext.com>

The objects "font.o" and "misc.o" are contained in $(OBJS), and it
is already added to the "targets".

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/compressed/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 7090ad3..476ef00 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -92,7 +92,7 @@ endif
 targets       := vmlinux vmlinux.lds \
 		 piggy.$(suffix_y) piggy.$(suffix_y).o \
 		 lib1funcs.o ashldi3.o bswapsdi2.o \
-		 font.o head.o misc.o $(OBJS)
+		 head.o $(OBJS)
 
 # Make sure files are removed during clean
 extra-y       += piggy.gzip piggy.lzo piggy.lzma piggy.xzkern piggy.lz4 \
-- 
1.9.1



From yamada.masahiro at socionext.com  Sun Feb 21 23:31:15 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon, 22 Feb 2016 16:31:15 +0900
Subject: [PATCH 4/6] ARM: decompressor: drop redundant FORCE in Makefile
In-Reply-To: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456126277-14633-5-git-send-email-yamada.masahiro@socionext.com>

The object "piggy.$(suffix_y).o" is created from "piggy.$(suffix).S"
by the following pattern rule defined in scripts/Makefile.build:

  $(obj)/%.o: $(src)/%.S FORCE
          $(call if_changed_dep,as_o_S)

FORCE is already added to the prerequisite of the object there.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/compressed/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index f9e8e68..903b953 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -187,7 +187,7 @@ $(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.$(suffix_y).o \
 $(obj)/piggy.$(suffix_y): $(obj)/../Image FORCE
 	$(call if_changed,$(suffix_y))
 
-$(obj)/piggy.$(suffix_y).o:  $(obj)/piggy.$(suffix_y) FORCE
+$(obj)/piggy.$(suffix_y).o:  $(obj)/piggy.$(suffix_y)
 
 CFLAGS_font.o := -Dstatic=
 
-- 
1.9.1



From yamada.masahiro at socionext.com  Sun Feb 21 23:31:11 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon, 22 Feb 2016 16:31:11 +0900
Subject: [PATCH 0/6] ARM: decompressor: several cleanups
Message-ID: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>




Masahiro Yamada (6):
  ARM: decompressor: drop unneeded assignments to "targets"
  ARM: decompressor: drop more unneeded assignments to "targets"
  ARM: decompressor: use clean-files instead of extra-y to clean files
  ARM: decompressor: drop redundant FORCE in Makefile
  ARM: decompressor: merge piggy.*.S and simplify Makefile
  ARM: decompressor: rename suffix_y to compress-y

 arch/arm/boot/compressed/.gitignore                |  6 +----
 arch/arm/boot/compressed/Makefile                  | 31 ++++++++++------------
 arch/arm/boot/compressed/{piggy.gzip.S => piggy.S} |  2 +-
 arch/arm/boot/compressed/piggy.lz4.S               |  6 -----
 arch/arm/boot/compressed/piggy.lzma.S              |  6 -----
 arch/arm/boot/compressed/piggy.lzo.S               |  6 -----
 arch/arm/boot/compressed/piggy.xzkern.S            |  6 -----
 7 files changed, 16 insertions(+), 47 deletions(-)
 rename arch/arm/boot/compressed/{piggy.gzip.S => piggy.S} (67%)
 delete mode 100644 arch/arm/boot/compressed/piggy.lz4.S
 delete mode 100644 arch/arm/boot/compressed/piggy.lzma.S
 delete mode 100644 arch/arm/boot/compressed/piggy.lzo.S
 delete mode 100644 arch/arm/boot/compressed/piggy.xzkern.S

-- 
1.9.1



From yamada.masahiro at socionext.com  Sun Feb 21 23:31:12 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon, 22 Feb 2016 16:31:12 +0900
Subject: [PATCH 1/6] ARM: decompressor: drop unneeded assignments to "targets"
In-Reply-To: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456126277-14633-2-git-send-email-yamada.masahiro@socionext.com>

The "targets" exists to specify which files need the corresponding
".*_cmd" files to be included during the build.  In other words, it
is used for files that need to detect the change of the command line
by if_changed, if_changed_dep, and if_changed_rule.  While, these
files are just copied by "$(call cmd,shipped)".  Adding them to the
"targets" is meaningless because $(call cmd,...) never creates
".*_cmd" files.  Such files as ".lib1funcs.S.cmd", ".ashldi3.S.cmd"
do not exist in the first place.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/compressed/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 7a6a58e..7090ad3 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -91,8 +91,8 @@ endif
 
 targets       := vmlinux vmlinux.lds \
 		 piggy.$(suffix_y) piggy.$(suffix_y).o \
-		 lib1funcs.o lib1funcs.S ashldi3.o ashldi3.S bswapsdi2.o \
-		 bswapsdi2.S font.o font.c head.o misc.o $(OBJS)
+		 lib1funcs.o ashldi3.o bswapsdi2.o \
+		 font.o head.o misc.o $(OBJS)
 
 # Make sure files are removed during clean
 extra-y       += piggy.gzip piggy.lzo piggy.lzma piggy.xzkern piggy.lz4 \
-- 
1.9.1



From yamada.masahiro at socionext.com  Sun Feb 21 23:31:17 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon, 22 Feb 2016 16:31:17 +0900
Subject: [PATCH 6/6] ARM: decompressor: rename suffix_y to compress-y
In-Reply-To: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456126277-14633-7-git-send-email-yamada.masahiro@socionext.com>

The "$(suffix_y)" no longer appears in the file names, but it just
specifies the method of the file compression.  The "compress-y" sounds
more suitable.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/compressed/Makefile | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 3243f09..5018bfa 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -66,11 +66,11 @@ endif
 
 CPPFLAGS_vmlinux.lds := -DTEXT_START="$(ZTEXTADDR)" -DBSS_START="$(ZBSSADDR)"
 
-suffix_$(CONFIG_KERNEL_GZIP) = gzip
-suffix_$(CONFIG_KERNEL_LZO)  = lzo
-suffix_$(CONFIG_KERNEL_LZMA) = lzma
-suffix_$(CONFIG_KERNEL_XZ)   = xzkern
-suffix_$(CONFIG_KERNEL_LZ4)  = lz4
+compress-$(CONFIG_KERNEL_GZIP) = gzip
+compress-$(CONFIG_KERNEL_LZO)  = lzo
+compress-$(CONFIG_KERNEL_LZMA) = lzma
+compress-$(CONFIG_KERNEL_XZ)   = xzkern
+compress-$(CONFIG_KERNEL_LZ4)  = lz4
 
 # Borrowed libfdt files for the ATAG compatibility mode
 
@@ -183,7 +183,7 @@ $(obj)/vmlinux: $(obj)/vmlinux.lds $(obj)/$(HEAD) $(obj)/piggy.o \
 	@$(check_for_bad_syms)
 
 $(obj)/piggy_data: $(obj)/../Image FORCE
-	$(call if_changed,$(suffix_y))
+	$(call if_changed,$(compress-y))
 
 $(obj)/piggy.o: $(obj)/piggy_data
 
-- 
1.9.1



From yamada.masahiro at socionext.com  Sun Feb 21 23:31:14 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon, 22 Feb 2016 16:31:14 +0900
Subject: [PATCH 3/6] ARM: decompressor: use clean-files instead of extra-y to
 clean files
In-Reply-To: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456126277-14633-4-git-send-email-yamada.masahiro@socionext.com>

This code works fine here, but it is tricky to use "extra-y" for
specifying files to be removed during "make clean".  Kbuild provides
"clean-files" for this purpose.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/compressed/Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
index 476ef00..f9e8e68 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -94,8 +94,7 @@ targets       := vmlinux vmlinux.lds \
 		 lib1funcs.o ashldi3.o bswapsdi2.o \
 		 head.o $(OBJS)
 
-# Make sure files are removed during clean
-extra-y       += piggy.gzip piggy.lzo piggy.lzma piggy.xzkern piggy.lz4 \
+clean-files += piggy.gzip piggy.lzo piggy.lzma piggy.xzkern piggy.lz4 \
 		 lib1funcs.S ashldi3.S bswapsdi2.S $(libfdt) $(libfdt_hdrs) \
 		 hyp-stub.S
 
-- 
1.9.1



From zhaoshenglong at huawei.com  Sun Feb 21 23:45:25 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 15:45:25 +0800
Subject: [PATCH v11 21/21] KVM: ARM64: Add a new vcpu device control group
 for PMUv3
In-Reply-To: <20160208125247.GG620@cbox>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
 <1454656456-11640-22-git-send-email-zhaoshenglong@huawei.com>
 <20160208125247.GG620@cbox>
Message-ID: <56CABC95.90700@huawei.com>



On 2016/2/8 20:52, Christoffer Dall wrote:
> On Fri, Feb 05, 2016 at 03:14:16PM +0800, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao at linaro.org>
>>
>> To configure the virtual PMUv3 overflow interrupt number, we use the
>> vcpu kvm_device ioctl, encapsulating the KVM_ARM_VCPU_PMU_V3_IRQ
>> attribute within the KVM_ARM_VCPU_PMU_V3_CTRL group.
>>
>> After configuring the PMUv3, call the vcpu ioctl with attribute
>> KVM_ARM_VCPU_PMU_V3_INIT to initialize the PMUv3.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
>> Acked-by: Peter Maydell <peter.maydell at linaro.org>
>> Reviewed-by: Andrew Jones <drjones at redhat.com>
>> ---
>> CC: Peter Maydell <peter.maydell at linaro.org>
>> ---
>>  Documentation/virtual/kvm/devices/vcpu.txt |  24 ++++++
>>  arch/arm/include/asm/kvm_host.h            |  15 ++++
>>  arch/arm/kvm/arm.c                         |   3 +
>>  arch/arm64/include/asm/kvm_host.h          |   6 ++
>>  arch/arm64/include/uapi/asm/kvm.h          |   5 ++
>>  arch/arm64/kvm/guest.c                     |  51 ++++++++++++
>>  include/kvm/arm_pmu.h                      |  23 ++++++
>>  virt/kvm/arm/pmu.c                         | 128 +++++++++++++++++++++++++++++
>>  8 files changed, 255 insertions(+)
>>
>> diff --git a/Documentation/virtual/kvm/devices/vcpu.txt b/Documentation/virtual/kvm/devices/vcpu.txt
>> index 3cc59c5..d626237 100644
>> --- a/Documentation/virtual/kvm/devices/vcpu.txt
>> +++ b/Documentation/virtual/kvm/devices/vcpu.txt
>> @@ -6,3 +6,27 @@ KVM_GET_DEVICE_ATTR, and KVM_HAS_DEVICE_ATTR. The interface uses the same struct
>>  kvm_device_attr as other devices, but targets VCPU-wide settings and controls.
>>  
>>  The groups and attributes per virtual cpu, if any, are architecture specific.
>> +
>> +1. GROUP: KVM_ARM_VCPU_PMU_V3_CTRL
>> +Architectures: ARM64
>> +
>> +1.1. ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_IRQ
>> +Parameters: in kvm_device_attr.addr the address for PMU overflow interrupt
> 
> so kvm_device_attr.addr is a pointer to an unsigned long or an int, or?
> 
int

>> +Returns: -EBUSY: The PMU overflow interrupt is already set
>> +         -ENXIO: The overflow interrupt not set when attempting to get it
>> +         -ENODEV: PMUv3 not supported
>> +         -EINVAL: Invalid PMU overflow interrupt number supplied
>> +
>> +A value describing the PMUv3 (Performance Monitor Unit v3) overflow interrupt
>> +number for this vcpu. This interrupt could be a PPI or SPI, but the interrupt
>> +type must be same for each vcpu. As a PPI, the interrupt number is same for all
> 
> nit: s/is same/is the same/
> 
>> +vcpus, while as an SPI it must be different for each vcpu.
> 
> nit: s/it must be different for each vcpu/
>        it must be a separate number per vcpu/
> 
>> +
>> +1.2 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_INIT
>> +Parameters: no additional parameter in kvm_device_attr.addr
>> +Returns: -ENODEV: PMUv3 not supported
>> +         -ENXIO: PMUv3 not properly configured as required prior to calling this
>> +                 attribute
>> +         -EBUSY: PMUv3 already initialized
>> +
>> +Request the initialization of the PMUv3.
>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>> index f9f2779..6dd0992 100644
>> --- a/arch/arm/include/asm/kvm_host.h
>> +++ b/arch/arm/include/asm/kvm_host.h
>> @@ -242,5 +242,20 @@ static inline void kvm_arm_init_debug(void) {}
>>  static inline void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) {}
>>  static inline void kvm_arm_clear_debug(struct kvm_vcpu *vcpu) {}
>>  static inline void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu) {}
>> +static inline int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
>> +					     struct kvm_device_attr *attr)
>> +{
>> +	return -ENXIO;
>> +}
>> +static inline int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
>> +					     struct kvm_device_attr *attr)
>> +{
>> +	return -ENXIO;
>> +}
>> +static inline int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
>> +					     struct kvm_device_attr *attr)
>> +{
>> +	return -ENXIO;
>> +}
>>  
>>  #endif /* __ARM_KVM_HOST_H__ */
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index 34d7395..dc8644f 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -833,6 +833,7 @@ static int kvm_arm_vcpu_set_attr(struct kvm_vcpu *vcpu,
>>  
>>  	switch (attr->group) {
>>  	default:
>> +		ret = kvm_arm_vcpu_arch_set_attr(vcpu, attr);
>>  		break;
>>  	}
>>  
>> @@ -846,6 +847,7 @@ static int kvm_arm_vcpu_get_attr(struct kvm_vcpu *vcpu,
>>  
>>  	switch (attr->group) {
>>  	default:
>> +		ret = kvm_arm_vcpu_arch_get_attr(vcpu, attr);
>>  		break;
>>  	}
>>  
>> @@ -859,6 +861,7 @@ static int kvm_arm_vcpu_has_attr(struct kvm_vcpu *vcpu,
>>  
>>  	switch (attr->group) {
>>  	default:
>> +		ret = kvm_arm_vcpu_arch_has_attr(vcpu, attr);
>>  		break;
>>  	}
>>  
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index cb220b7..a855a30 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -359,5 +359,11 @@ void kvm_arm_init_debug(void);
>>  void kvm_arm_setup_debug(struct kvm_vcpu *vcpu);
>>  void kvm_arm_clear_debug(struct kvm_vcpu *vcpu);
>>  void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu);
>> +int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
>> +			       struct kvm_device_attr *attr);
>> +int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
>> +			       struct kvm_device_attr *attr);
>> +int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
>> +			       struct kvm_device_attr *attr);
>>  
>>  #endif /* __ARM64_KVM_HOST_H__ */
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index 6aedbe3..f209ea1 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -205,6 +205,11 @@ struct kvm_arch_memory_slot {
>>  #define KVM_DEV_ARM_VGIC_GRP_CTRL	4
>>  #define   KVM_DEV_ARM_VGIC_CTRL_INIT	0
>>  
>> +/* Device Control API on vcpu fd */
>> +#define KVM_ARM_VCPU_PMU_V3_CTRL	0
>> +#define   KVM_ARM_VCPU_PMU_V3_IRQ	0
>> +#define   KVM_ARM_VCPU_PMU_V3_INIT	1
>> +
>>  /* KVM_IRQ_LINE irq field index values */
>>  #define KVM_ARM_IRQ_TYPE_SHIFT		24
>>  #define KVM_ARM_IRQ_TYPE_MASK		0xff
>> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
>> index fcb7788..dbe45c3 100644
>> --- a/arch/arm64/kvm/guest.c
>> +++ b/arch/arm64/kvm/guest.c
>> @@ -380,3 +380,54 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
>>  	}
>>  	return 0;
>>  }
>> +
>> +int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
>> +			       struct kvm_device_attr *attr)
>> +{
>> +	int ret;
>> +
>> +	switch (attr->group) {
>> +	case KVM_ARM_VCPU_PMU_V3_CTRL:
>> +		ret = kvm_arm_pmu_v3_set_attr(vcpu, attr);
>> +		break;
>> +	default:
>> +		ret = -ENXIO;
>> +		break;
>> +	}
>> +
>> +	return ret;
>> +}
>> +
>> +int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
>> +			       struct kvm_device_attr *attr)
>> +{
>> +	int ret;
>> +
>> +	switch (attr->group) {
>> +	case KVM_ARM_VCPU_PMU_V3_CTRL:
>> +		ret = kvm_arm_pmu_v3_get_attr(vcpu, attr);
>> +		break;
>> +	default:
>> +		ret = -ENXIO;
>> +		break;
>> +	}
>> +
>> +	return ret;
>> +}
>> +
>> +int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
>> +			       struct kvm_device_attr *attr)
>> +{
>> +	int ret;
>> +
>> +	switch (attr->group) {
>> +	case KVM_ARM_VCPU_PMU_V3_CTRL:
>> +		ret = kvm_arm_pmu_v3_has_attr(vcpu, attr);
>> +		break;
>> +	default:
>> +		ret = -ENXIO;
>> +		break;
>> +	}
>> +
>> +	return ret;
>> +}
>> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
>> index 5f86e1d..f09abf6 100644
>> --- a/include/kvm/arm_pmu.h
>> +++ b/include/kvm/arm_pmu.h
>> @@ -38,6 +38,7 @@ struct kvm_pmu {
>>  };
>>  
>>  #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
>> +#define kvm_arm_pmu_irq_initialized(v)	((v)->arch.pmu.irq_num >= VGIC_NR_SGIS)
>>  u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
>>  void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
>>  u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
>> @@ -52,11 +53,18 @@ void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
>>  void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>>  				    u64 select_idx);
>>  bool kvm_arm_support_pmu_v3(void);
>> +int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu,
>> +			    struct kvm_device_attr *attr);
>> +int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu,
>> +			    struct kvm_device_attr *attr);
>> +int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu,
>> +			    struct kvm_device_attr *attr);
>>  #else
>>  struct kvm_pmu {
>>  };
>>  
>>  #define kvm_arm_pmu_v3_ready(v)		(false)
>> +#define kvm_arm_pmu_irq_initialized(v)	(false)
>>  static inline u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu,
>>  					    u64 select_idx)
>>  {
>> @@ -79,6 +87,21 @@ static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
>>  static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
>>  						  u64 data, u64 select_idx) {}
>>  static inline bool kvm_arm_support_pmu_v3(void) { return false; }
>> +static inline int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu,
>> +					  struct kvm_device_attr *attr)
>> +{
>> +	return -ENXIO;
>> +}
>> +static inline int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu,
>> +					  struct kvm_device_attr *attr)
>> +{
>> +	return -ENXIO;
>> +}
>> +static inline int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu,
>> +					  struct kvm_device_attr *attr)
>> +{
>> +	return -ENXIO;
>> +}
>>  #endif
>>  
>>  #endif
>> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
>> index 2467d62..06b7cb3 100644
>> --- a/virt/kvm/arm/pmu.c
>> +++ b/virt/kvm/arm/pmu.c
>> @@ -19,6 +19,7 @@
>>  #include <linux/kvm.h>
>>  #include <linux/kvm_host.h>
>>  #include <linux/perf_event.h>
>> +#include <linux/uaccess.h>
>>  #include <asm/kvm_emulate.h>
>>  #include <kvm/arm_pmu.h>
>>  #include <kvm/arm_vgic.h>
>> @@ -393,3 +394,130 @@ bool kvm_arm_support_pmu_v3(void)
>>  	 */
>>  	return (perf_num_counters() > 0);
>>  }
>> +
>> +static int kvm_arm_pmu_v3_init(struct kvm_vcpu *vcpu)
>> +{
>> +	if (!kvm_arm_support_pmu_v3())
>> +		return -ENODEV;
>> +
>> +	if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features) ||
>> +	    !kvm_arm_pmu_irq_initialized(vcpu))
>> +		return -ENXIO;
>> +
>> +	if (kvm_arm_pmu_v3_ready(vcpu))
>> +		return -EBUSY;
>> +
>> +	kvm_pmu_vcpu_reset(vcpu);
>> +	vcpu->arch.pmu.ready = true;
>> +
>> +	return 0;
>> +}
>> +
>> +static int kvm_arm_pmu_irq_access(struct kvm_vcpu *vcpu,
>> +				  struct kvm_device_attr *attr,
>> +				  int *irq, bool is_set)
>> +{
>> +	if (!is_set) {
>> +		if (!kvm_arm_pmu_irq_initialized(vcpu))
>> +			return -ENXIO;
>> +
>> +		*irq = vcpu->arch.pmu.irq_num;
>> +	} else {
>> +		if (kvm_arm_pmu_irq_initialized(vcpu))
>> +			return -EBUSY;
>> +
>> +		kvm_debug("Set kvm ARM PMU irq: %d\n", *irq);
>> +		vcpu->arch.pmu.irq_num = *irq;
>> +	}
>> +
>> +	return 0;
>> +}
> 
> are you going to be reusing this function in later patches?  If not, I
> don't see the benefit of having this indirection over simply including
> it directly in the callers below.
> 
Oh, right. Will drop this function.

>> +
>> +static bool irq_is_valid(struct kvm *kvm, int irq, bool is_ppi)
>> +{
>> +	int i;
>> +	struct kvm_vcpu *vcpu;
>> +
>> +	kvm_for_each_vcpu(i, vcpu, kvm) {
>> +		if (!kvm_arm_pmu_irq_initialized(vcpu))
>> +			continue;
>> +
>> +		if (is_ppi) {
>> +			if (vcpu->arch.pmu.irq_num != irq)
>> +				return false;
>> +		} else {
>> +			if (vcpu->arch.pmu.irq_num == irq)
>> +				return false;
>> +		}
>> +	}
>> +
>> +	return true;
>> +}
>> +
>> +
>> +int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
>> +{
>> +	switch (attr->attr) {
>> +	case KVM_ARM_VCPU_PMU_V3_IRQ: {
>> +		int __user *uaddr = (int __user *)(long)attr->addr;
>> +		int reg;
>> +
>> +		if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
>> +			return -ENODEV;
>> +
>> +		if (get_user(reg, uaddr))
>> +			return -EFAULT;
>> +
>> +		/*
>> +		 * The PMU overflow interrupt could be a PPI or SPI, but for one
>> +		 * VM the interrupt type must be same for each vcpu. As a PPI,
>> +		 * the interrupt number is same for all vcpus, while as an SPI
>> +		 * it must be different for each vcpu.
>> +		 */
>> +		if (reg < VGIC_NR_SGIS || reg >= vcpu->kvm->arch.vgic.nr_irqs ||
>> +		    !irq_is_valid(vcpu->kvm, reg, reg < VGIC_NR_PRIVATE_IRQS))
>> +			return -EINVAL;
>> +
>> +		return kvm_arm_pmu_irq_access(vcpu, attr, &reg, true);
>> +	}
>> +	case KVM_ARM_VCPU_PMU_V3_INIT:
>> +		return kvm_arm_pmu_v3_init(vcpu);
>> +	}
>> +
>> +	return -ENXIO;
>> +}
>> +
>> +int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
>> +{
>> +	int ret;
>> +
>> +	switch (attr->attr) {
>> +	case KVM_ARM_VCPU_PMU_V3_IRQ: {
>> +		int __user *uaddr = (int __user *)(long)attr->addr;
>> +		int reg = -1;
>> +
>> +		if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
>> +			return -ENODEV;
>> +
>> +		ret = kvm_arm_pmu_irq_access(vcpu, attr, &reg, false);
>> +		if (ret)
>> +			return ret;
>> +		return put_user(reg, uaddr);
>> +	}
>> +	}
>> +
>> +	return -ENXIO;
>> +}
>> +
>> +int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
>> +{
>> +	switch (attr->attr) {
>> +	case KVM_ARM_VCPU_PMU_V3_IRQ:
>> +	case KVM_ARM_VCPU_PMU_V3_INIT:
>> +		if (kvm_arm_support_pmu_v3() &&
>> +		    test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
>> +			return 0;
>> +	}
>> +
>> +	return -ENXIO;
>> +}
>> -- 
>> 2.0.4
>>
>>
> 
> Besides the style and wording comments:
> 
> Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
> 
Thanks!

-- 
Shannon



From raveendra.padasalagi at broadcom.com  Sun Feb 21 23:49:36 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Mon, 22 Feb 2016 13:19:36 +0530
Subject: [PATCH v3 0/3] Syscon support for iProc touchscreen driver
Message-ID: <1456127379-25866-1-git-send-email-raveendra.padasalagi@broadcom.com>

This patchset is based on v4.5-rc3 tag and its tested on
Broadcom Cygnus SoC.

The patches can be fetched from iproc-tsc-v3 branch of
https://github.com/Broadcom/arm64-linux.git

Changes since v2:
 - Omitted '0x' in "tsc node" definition in dt documentation file
 - Omitted '0x' in "ts_adc_syscon" definition in dt documentation file
 - Added "brcm,iproc-ts-adc-syscon" compatible string in "ts_adc_syscon"
   node. Updated dt documentation file to reflect this change.

Raveendra Padasalagi (3):
  input: cygnus-update touchscreen dt node document
  input: syscon support in bcm_iproc_tsc driver
  ARM: dts: use syscon in cygnus touchscreen dt node

 .../input/touchscreen/brcm,iproc-touchscreen.txt   |  59 +++++++-
 arch/arm/boot/dts/bcm-cygnus.dtsi                  |  11 +-
 drivers/input/touchscreen/bcm_iproc_tsc.c          | 152 +++++++++++++++------
 3 files changed, 173 insertions(+), 49 deletions(-)

-- 
1.9.1



From raveendra.padasalagi at broadcom.com  Sun Feb 21 23:49:37 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Mon, 22 Feb 2016 13:19:37 +0530
Subject: [PATCH v3 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <1456127379-25866-1-git-send-email-raveendra.padasalagi@broadcom.com>
References: <1456127379-25866-1-git-send-email-raveendra.padasalagi@broadcom.com>
Message-ID: <1456127379-25866-2-git-send-email-raveendra.padasalagi@broadcom.com>

In Cygnus SOC touch screen controller registers are shared
with ADC and flex timer. Using readl/writel could lead to
race condition. So touch screen driver is enhanced to support

1. If touchscreen register's are not shared. Register access
is handled through readl/writel if "brcm,iproc-touchscreen"
compatible is provided in touchscreen dt node. This will help
for future SOC's if comes with dedicated touchscreen IP register's.

2. If touchscreen register's are shared with other IP's, register
access is handled through syscon framework API's to take care of
mutually exclusive access. This feature can be enabled by selecting
"brcm,iproc-touchscreen-syscon" compatible string in the touchscreen
dt node.

Hence touchscreen dt node bindings document is updated to take care
of above changes in the touchscreen driver.

Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi at broadcom.com>
Reviewed-by: Ray Jui <ray.jui at broadcom.com>
Reviewed-by: Scott Branden <scott.branden at broadcom.com>
---
 .../input/touchscreen/brcm,iproc-touchscreen.txt   | 59 +++++++++++++++++++---
 1 file changed, 52 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
index 34e3382..c186162 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
@@ -1,12 +1,30 @@
 * Broadcom's IPROC Touchscreen Controller
 
 Required properties:
-- compatible: must be "brcm,iproc-touchscreen"
-- reg: physical base address of the controller and length of memory mapped
-  region.
+- compatible: should be one of
+        "brcm,iproc-touchscreen"
+        "brcm,iproc-touchscreen-syscon"
+- ts_syscon: if "brcm,iproc-touchscreen-syscon" compatible string
+  is selected then "ts_syscon" is mandatory or else not required.
+  The "ts_syscon" is handler of syscon node defining physical base
+  address of the controller and length of memory mapped region.
+  If this property is selected please make sure MFD_SYSCON config
+  is enabled in the defconfig file.
+- reg: if "brcm,iproc-touchscreen" compatible string is selected
+  then "reg" property is mandatory or else not required.
+  The "reg" should be physical base address of the controller and
+  length of memory mapped region.
 - clocks:  The clock provided by the SOC to driver the tsc
 - clock-name:  name for the clock
 - interrupts: The touchscreen controller's interrupt
+- address-cells: Specify the number of u32 entries needed in child nodes.
+                 Should set to 1. This property is mandatory when
+                 "brcm,iproc-touchscreen-syscon" compatible string is selected
+                 or else not required.
+- size-cells: Specify number of u32 entries needed to specify child nodes size
+              in reg property. Should set to 1.This property is mandatory when
+              "brcm,iproc-touchscreen-syscon" compatible string is selected or
+              else not required.
 
 Optional properties:
 - scanning_period: Time between scans. Each step is 1024 us.  Valid 1-256.
@@ -53,13 +71,40 @@ Optional properties:
 - touchscreen-inverted-x: X axis is inverted (boolean)
 - touchscreen-inverted-y: Y axis is inverted (boolean)
 
-Example:
+Example 1: An example of touchscreen node with "brcm,iproc-touchscreen-syscon"
+           compatible string.
 
-	touchscreen: tsc at 0x180A6000 {
-		compatible = "brcm,iproc-touchscreen";
+	ts_adc_syscon: ts_adc_syscon at 180a6000 {
+		compatible = "brcm,iproc-ts-adc-syscon","syscon";
+		reg = <0x180a6000 0xc30>;
+	};
+
+	touchscreen: tsc at 180A6000 {
+		compatible = "brcm,iproc-touchscreen-syscon";
 		#address-cells = <1>;
 		#size-cells = <1>;
-		reg = <0x180A6000 0x40>;
+		ts_syscon = <&ts_adc_syscon>;
+		clocks = <&adc_clk>;
+		clock-names = "tsc_clk";
+		interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
+
+		scanning_period = <5>;
+		debounce_timeout = <40>;
+		settling_timeout = <7>;
+		touch_timeout = <10>;
+		average_data = <5>;
+		fifo_threshold = <1>;
+		/* Touchscreen is rotated 180 degrees. */
+		touchscreen-inverted-x;
+		touchscreen-inverted-y;
+	};
+
+Example 2: An example of touchscreen node with "brcm,iproc-touchscreen"
+          compatible string.
+
+	touchscreen: tsc at 180A6000 {
+		compatible = "brcm,iproc-touchscreen";
+		reg = <0x180a6000 0x40>;
 		clocks = <&adc_clk>;
 		clock-names = "tsc_clk";
 		interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
-- 
1.9.1



From raveendra.padasalagi at broadcom.com  Sun Feb 21 23:49:38 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Mon, 22 Feb 2016 13:19:38 +0530
Subject: [PATCH v3 2/3] input: syscon support in bcm_iproc_tsc driver
In-Reply-To: <1456127379-25866-1-git-send-email-raveendra.padasalagi@broadcom.com>
References: <1456127379-25866-1-git-send-email-raveendra.padasalagi@broadcom.com>
Message-ID: <1456127379-25866-3-git-send-email-raveendra.padasalagi@broadcom.com>

In Cygnus SOC touch screen controller registers are shared
with ADC and flex timer. Using readl/writel could lead to
race condition. So touch screen driver is enhanced to support

1. If touchscreen register's are not shared. Register access
is handled through readl/writel if "brcm,iproc-touchscreen"
compatible is provided in touchscreen dt node. This will help
for future SOC's if comes with dedicated touchscreen IP register's.

2. If touchscreen register's are shared with other IP's, register
access is handled through syscon framework API's to take care of
mutually exclusive access. This feature can be enabled by selecting
"brcm,iproc-touchscreen-syscon" compatible string in the touchscreen
dt node.

Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi at broadcom.com>
Reviewed-by: Ray Jui <ray.jui at broadcom.com>
Reviewed-by: Scott Branden <scott.branden at broadcom.com>
---
 drivers/input/touchscreen/bcm_iproc_tsc.c | 152 ++++++++++++++++++++++--------
 1 file changed, 112 insertions(+), 40 deletions(-)

diff --git a/drivers/input/touchscreen/bcm_iproc_tsc.c b/drivers/input/touchscreen/bcm_iproc_tsc.c
index ae460a5c..3ef80c6 100644
--- a/drivers/input/touchscreen/bcm_iproc_tsc.c
+++ b/drivers/input/touchscreen/bcm_iproc_tsc.c
@@ -23,6 +23,8 @@
 #include <linux/io.h>
 #include <linux/clk.h>
 #include <linux/serio.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
 
 #define IPROC_TS_NAME "iproc-ts"
 
@@ -88,7 +90,7 @@
 #define TS_WIRE_MODE_BIT        BIT(1)
 
 #define dbg_reg(dev, priv, reg) \
-	dev_dbg(dev, "%20s= 0x%08x\n", #reg, readl((priv)->regs + reg))
+	dev_dbg(dev, "%20s= 0x%08x\n", #reg, iproc_reg_read(priv, reg))
 
 struct tsc_param {
 	/* Each step is 1024 us.  Valid 1-256 */
@@ -142,12 +144,18 @@ struct iproc_ts_priv {
 	struct input_dev *idev;
 
 	void __iomem *regs;
+	struct regmap *regmap;
 	struct clk *tsc_clk;
 
 	int  pen_status;
 	struct tsc_param cfg_params;
 };
 
+enum iproc_ts_reg_type {
+	IPROC_TS_REG,
+	IPROC_TS_SYSCON,
+};
+
 /*
  * Set default values the same as hardware reset values
  * except for fifo_threshold with is set to 1.
@@ -163,6 +171,41 @@ static const struct tsc_param iproc_default_config = {
 	.max_y            = Y_MAX,
 };
 
+static int iproc_reg_update_bits(struct iproc_ts_priv *priv, u32 reg,
+			   u32 mask, u32 val)
+{
+	int ret = 0;
+	u32 tmp, orig;
+
+	if (priv->regs) {
+		orig = readl(priv->regs);
+		tmp = orig & ~mask;
+		tmp |= val & mask;
+		writel(tmp, priv->regs + reg);
+	} else
+		ret = regmap_update_bits(priv->regmap, reg, mask, val);
+	return ret;
+}
+
+static void iproc_reg_write(struct iproc_ts_priv *priv, u32 reg, u32 val)
+{
+	if (priv->regs)
+		writel(val, priv->regs + reg);
+	else
+		regmap_write(priv->regmap, reg, val);
+}
+
+static u32 iproc_reg_read(struct iproc_ts_priv *priv, u32 reg)
+{
+	u32 val;
+
+	if (priv->regs)
+		val = readl(priv->regs + reg);
+	else
+		regmap_read(priv->regmap, reg, &val);
+	return val;
+}
+
 static void ts_reg_dump(struct iproc_ts_priv *priv)
 {
 	struct device *dev = &priv->pdev->dev;
@@ -196,22 +239,22 @@ static irqreturn_t iproc_touchscreen_interrupt(int irq, void *data)
 	int i;
 	bool needs_sync = false;
 
-	intr_status = readl(priv->regs + INTERRUPT_STATUS);
-	intr_status &= TS_PEN_INTR_MASK | TS_FIFO_INTR_MASK;
+	intr_status = iproc_reg_read(priv, INTERRUPT_STATUS);
+	intr_status &= (TS_PEN_INTR_MASK | TS_FIFO_INTR_MASK);
 	if (intr_status == 0)
 		return IRQ_NONE;
 
 	/* Clear all interrupt status bits, write-1-clear */
-	writel(intr_status, priv->regs + INTERRUPT_STATUS);
-
+	iproc_reg_write(priv, INTERRUPT_STATUS, intr_status);
 	/* Pen up/down */
 	if (intr_status & TS_PEN_INTR_MASK) {
-		if (readl(priv->regs + CONTROLLER_STATUS) & TS_PEN_DOWN)
+		priv->pen_status = iproc_reg_read(priv, CONTROLLER_STATUS);
+		if (priv->pen_status & TS_PEN_DOWN)
 			priv->pen_status = PEN_DOWN_STATUS;
 		else
 			priv->pen_status = PEN_UP_STATUS;
 
-		input_report_key(priv->idev, BTN_TOUCH, priv->pen_status);
+		input_report_key(priv->idev, BTN_TOUCH,	priv->pen_status);
 		needs_sync = true;
 
 		dev_dbg(&priv->pdev->dev,
@@ -221,7 +264,7 @@ static irqreturn_t iproc_touchscreen_interrupt(int irq, void *data)
 	/* coordinates in FIFO exceed the theshold */
 	if (intr_status & TS_FIFO_INTR_MASK) {
 		for (i = 0; i < priv->cfg_params.fifo_threshold; i++) {
-			raw_coordinate = readl(priv->regs + FIFO_DATA);
+			raw_coordinate = iproc_reg_read(priv, FIFO_DATA);
 			if (raw_coordinate == INVALID_COORD)
 				continue;
 
@@ -239,7 +282,7 @@ static irqreturn_t iproc_touchscreen_interrupt(int irq, void *data)
 			x = (x >> 4) & 0x0FFF;
 			y = (y >> 4) & 0x0FFF;
 
-			/* adjust x y according to lcd tsc mount angle */
+			/* Adjust x y according to LCD tsc mount angle. */
 			if (priv->cfg_params.invert_x)
 				x = priv->cfg_params.max_x - x;
 
@@ -262,9 +305,10 @@ static irqreturn_t iproc_touchscreen_interrupt(int irq, void *data)
 
 static int iproc_ts_start(struct input_dev *idev)
 {
-	struct iproc_ts_priv *priv = input_get_drvdata(idev);
 	u32 val;
+	u32 mask;
 	int error;
+	struct iproc_ts_priv *priv = input_get_drvdata(idev);
 
 	/* Enable clock */
 	error = clk_prepare_enable(priv->tsc_clk);
@@ -279,9 +323,10 @@ static int iproc_ts_start(struct input_dev *idev)
 	 *  FIFO reaches the int_th value, and pen event(up/down)
 	 */
 	val = TS_PEN_INTR_MASK | TS_FIFO_INTR_MASK;
-	writel(val, priv->regs + INTERRUPT_MASK);
+	iproc_reg_update_bits(priv, INTERRUPT_MASK, val, val);
 
-	writel(priv->cfg_params.fifo_threshold, priv->regs + INTERRUPT_THRES);
+	val = priv->cfg_params.fifo_threshold;
+	iproc_reg_write(priv, INTERRUPT_THRES, val);
 
 	/* Initialize control reg1 */
 	val = 0;
@@ -289,26 +334,23 @@ static int iproc_ts_start(struct input_dev *idev)
 	val |= priv->cfg_params.debounce_timeout << DEBOUNCE_TIMEOUT_SHIFT;
 	val |= priv->cfg_params.settling_timeout << SETTLING_TIMEOUT_SHIFT;
 	val |= priv->cfg_params.touch_timeout << TOUCH_TIMEOUT_SHIFT;
-	writel(val, priv->regs + REGCTL1);
+	iproc_reg_write(priv, REGCTL1, val);
 
 	/* Try to clear all interrupt status */
-	val = readl(priv->regs + INTERRUPT_STATUS);
-	val |= TS_FIFO_INTR_MASK | TS_PEN_INTR_MASK;
-	writel(val, priv->regs + INTERRUPT_STATUS);
+	val = TS_FIFO_INTR_MASK | TS_PEN_INTR_MASK;
+	iproc_reg_update_bits(priv, INTERRUPT_STATUS, val, val);
 
 	/* Initialize control reg2 */
-	val = readl(priv->regs + REGCTL2);
-	val |= TS_CONTROLLER_EN_BIT | TS_WIRE_MODE_BIT;
-
-	val &= ~TS_CONTROLLER_AVGDATA_MASK;
+	val = TS_CONTROLLER_EN_BIT | TS_WIRE_MODE_BIT;
 	val |= priv->cfg_params.average_data << TS_CONTROLLER_AVGDATA_SHIFT;
 
-	val &= ~(TS_CONTROLLER_PWR_LDO |	/* PWR up LDO */
+	mask = (TS_CONTROLLER_AVGDATA_MASK);
+	mask |= (TS_CONTROLLER_PWR_LDO |	/* PWR up LDO */
 		   TS_CONTROLLER_PWR_ADC |	/* PWR up ADC */
 		   TS_CONTROLLER_PWR_BGP |	/* PWR up BGP */
 		   TS_CONTROLLER_PWR_TS);	/* PWR up TS */
-
-	writel(val, priv->regs + REGCTL2);
+	mask |= val;
+	iproc_reg_update_bits(priv, REGCTL2, mask, val);
 
 	ts_reg_dump(priv);
 
@@ -320,12 +362,17 @@ static void iproc_ts_stop(struct input_dev *dev)
 	u32 val;
 	struct iproc_ts_priv *priv = input_get_drvdata(dev);
 
-	writel(0, priv->regs + INTERRUPT_MASK); /* Disable all interrupts */
+	/*
+	 * Disable FIFO int_th and pen event(up/down)Interrupts only
+	 * as the interrupt mask register is shared between ADC, TS and
+	 * flextimer.
+	 */
+	val = TS_PEN_INTR_MASK | TS_FIFO_INTR_MASK;
+	iproc_reg_update_bits(priv, INTERRUPT_MASK, val, 0);
 
 	/* Only power down touch screen controller */
-	val = readl(priv->regs + REGCTL2);
-	val |= TS_CONTROLLER_PWR_TS;
-	writel(val, priv->regs + REGCTL2);
+	val = TS_CONTROLLER_PWR_TS;
+	iproc_reg_update_bits(priv, REGCTL2, val, val);
 
 	clk_disable(priv->tsc_clk);
 }
@@ -410,25 +457,56 @@ static int iproc_get_tsc_config(struct device *dev, struct iproc_ts_priv *priv)
 	return 0;
 }
 
+static const struct of_device_id iproc_ts_of_match[] = {
+	{.compatible = "brcm,iproc-touchscreen",
+	 .data = (void *) IPROC_TS_REG },
+	{.compatible = "brcm,iproc-touchscreen-syscon",
+	 .data = (void *) IPROC_TS_SYSCON },
+	{},
+};
+MODULE_DEVICE_TABLE(of, iproc_ts_of_match);
+
 static int iproc_ts_probe(struct platform_device *pdev)
 {
 	struct iproc_ts_priv *priv;
 	struct input_dev *idev;
 	struct resource *res;
+	const struct of_device_id *of_id;
 	int irq;
 	int error;
+	enum iproc_ts_reg_type reg_access;
 
 	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
 	if (!priv)
 		return -ENOMEM;
 
-	/* touchscreen controller memory mapped regs */
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	priv->regs = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(priv->regs)) {
-		error = PTR_ERR(priv->regs);
-		dev_err(&pdev->dev, "unable to map I/O memory: %d\n", error);
-		return error;
+	of_id = of_match_node(iproc_ts_of_match, pdev->dev.of_node);
+	if (of_id)
+		reg_access = (enum iproc_ts_reg_type)of_id->data;
+	else
+		return -ENODEV;
+
+	if (reg_access == IPROC_TS_SYSCON) {
+		/* touchscreen controller memory mapped regs via syscon */
+		priv->regmap = syscon_regmap_lookup_by_phandle(
+						pdev->dev.of_node,
+						"ts_syscon");
+		if (IS_ERR(priv->regmap)) {
+			error = PTR_ERR(priv->regs);
+			dev_err(&pdev->dev, "unable to map I/O memory:%d\n",
+				error);
+			return error;
+		}
+	} else {
+		/* touchscreen controller memory mapped regs */
+		res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+		priv->regs = devm_ioremap_resource(&pdev->dev, res);
+		if (IS_ERR(priv->regs)) {
+			error = PTR_ERR(priv->regs);
+			dev_err(&pdev->dev, "unable to map I/O memory:%d\n",
+				error);
+			return error;
+		}
 	}
 
 	priv->tsc_clk = devm_clk_get(&pdev->dev, "tsc_clk");
@@ -501,12 +579,6 @@ static int iproc_ts_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static const struct of_device_id iproc_ts_of_match[] = {
-	{.compatible = "brcm,iproc-touchscreen", },
-	{ },
-};
-MODULE_DEVICE_TABLE(of, iproc_ts_of_match);
-
 static struct platform_driver iproc_ts_driver = {
 	.probe = iproc_ts_probe,
 	.driver = {
-- 
1.9.1



From raveendra.padasalagi at broadcom.com  Sun Feb 21 23:49:39 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Mon, 22 Feb 2016 13:19:39 +0530
Subject: [PATCH v3 3/3] ARM: dts: use syscon in cygnus touchscreen dt node
In-Reply-To: <1456127379-25866-1-git-send-email-raveendra.padasalagi@broadcom.com>
References: <1456127379-25866-1-git-send-email-raveendra.padasalagi@broadcom.com>
Message-ID: <1456127379-25866-4-git-send-email-raveendra.padasalagi@broadcom.com>

In Cygnus SOC touch screen controller registers are shared
with ADC and flex timer. Using readl/writel could lead to
race condition. So in such case register access is handled
through syscon framework API's in the touch screen driver.
This feature is enabled if "brcm,iproc-touchscreen-syscon"
compatible string is selected in touchscreen dt node.

So this patch enables syscon support in touchscreen driver
by adding necessary properties in touchscreen dt node.

Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi at broadcom.com>
Reviewed-by: Ray Jui <ray.jui at broadcom.com>
Reviewed-by: Scott Branden <scott.branden at broadcom.com>
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 3878793..1704dc0 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -351,9 +351,16 @@
 					<&pinctrl 142 10 1>;
 		};
 
+		ts_adc_syscon: ts_adc_syscon at 180a6000 {
+			compatible = "brcm,iproc-ts-adc-syscon","syscon";
+			reg = <0x180a6000 0xc30>;
+		};
+
 		touchscreen: tsc at 180a6000 {
-			compatible = "brcm,iproc-touchscreen";
-			reg = <0x180a6000 0x40>;
+			compatible = "brcm,iproc-touchscreen-syscon";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ts_syscon = <&ts_adc_syscon>;
 			clocks = <&asiu_clks BCM_CYGNUS_ASIU_ADC_CLK>;
 			clock-names = "tsc_clk";
 			interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
-- 
1.9.1



From zhaoshenglong at huawei.com  Sun Feb 21 23:43:56 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 15:43:56 +0800
Subject: [PATCH v11 19/21] KVM: ARM64: Add a new feature bit for PMUv3
In-Reply-To: <20160208122957.GE620@cbox>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
 <1454656456-11640-20-git-send-email-zhaoshenglong@huawei.com>
 <20160208122957.GE620@cbox>
Message-ID: <56CABC3C.8000304@huawei.com>



On 2016/2/8 20:29, Christoffer Dall wrote:
>> +bool kvm_arm_support_pmu_v3(void)
>> > +{
>> > +	/* Check if HW_PERF_EVENTS are supported by checking the number of
>> > +	 * hardware performance counters. This could ensure physical PMU and
>> > +	 * PERF_EVENT driver existing.
>> > +	 */
> nit: coding style, opening comment block should be on its own line
> 
> I don't understand the last sentence.  Do you mean: "This ensures the
> presence of a physical PMU and that CONFIG_PERF_EVENT is selected." ?
Right.

-- 
Shannon



From zhaoshenglong at huawei.com  Sun Feb 21 23:35:25 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 15:35:25 +0800
Subject: [PATCH v11 16/21] KVM: ARM64: Add PMU overflow interrupt routing
In-Reply-To: <20160208122643.GD620@cbox>
References: <1454656456-11640-1-git-send-email-zhaoshenglong@huawei.com>
 <1454656456-11640-17-git-send-email-zhaoshenglong@huawei.com>
 <20160208122643.GD620@cbox>
Message-ID: <56CABA3D.3090600@huawei.com>



On 2016/2/8 20:26, Christoffer Dall wrote:
> On Fri, Feb 05, 2016 at 03:14:11PM +0800, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao at linaro.org>
>>
>> When calling perf_event_create_kernel_counter to create perf_event,
>> assign a overflow handler. Then when the perf event overflows, set the
>> corresponding bit of guest PMOVSSET register. If this counter is enabled
>> and its interrupt is enabled as well, kick the vcpu to sync the
>> interrupt.
>>
>> On VM entry, if there is counter overflowed, inject the interrupt with
>> the level set to 1. Otherwise, inject the interrupt with the level set
>> to 0.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
>> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
>> Reviewed-by: Andrew Jones <drjones at redhat.com>
>> ---
>>  arch/arm/kvm/arm.c    |  2 ++
>>  include/kvm/arm_pmu.h |  2 ++
>>  virt/kvm/arm/pmu.c    | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
>>  3 files changed, 53 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index dda1959..f54264c 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -28,6 +28,7 @@
>>  #include <linux/sched.h>
>>  #include <linux/kvm.h>
>>  #include <trace/events/kvm.h>
>> +#include <kvm/arm_pmu.h>
>>  
>>  #define CREATE_TRACE_POINTS
>>  #include "trace.h"
>> @@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>  		 * non-preemptible context.
>>  		 */
>>  		preempt_disable();
>> +		kvm_pmu_flush_hwstate(vcpu);
>>  		kvm_timer_flush_hwstate(vcpu);
>>  		kvm_vgic_flush_hwstate(vcpu);
>>  
>> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
>> index 1f4bfa2..44a3c75 100644
>> --- a/include/kvm/arm_pmu.h
>> +++ b/include/kvm/arm_pmu.h
>> @@ -44,6 +44,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
>>  void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
>>  void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
>>  void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
>> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
>>  void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
>>  void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
>>  void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>> @@ -67,6 +68,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
>>  static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>>  static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>>  static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
>> +static inline void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
>>  static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
>>  static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
>>  static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
>> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
>> index c8ea825..5f983cb 100644
>> --- a/virt/kvm/arm/pmu.c
>> +++ b/virt/kvm/arm/pmu.c
>> @@ -21,6 +21,7 @@
>>  #include <linux/perf_event.h>
>>  #include <asm/kvm_emulate.h>
>>  #include <kvm/arm_pmu.h>
>> +#include <kvm/arm_vgic.h>
>>  
>>  /**
>>   * kvm_pmu_get_counter_value - get PMU counter value
>> @@ -180,6 +181,52 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
>>  }
>>  
>>  /**
>> + * kvm_pmu_flush_hwstate - flush pmu state to cpu
>> + * @vcpu: The vcpu pointer
>> + *
>> + * Inject virtual PMU IRQ if IRQ is pending for this cpu.
>> + */
>> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
>> +{
>> +	struct kvm_pmu *pmu = &vcpu->arch.pmu;
>> +	u64 overflow;
>> +
>> +	if (!kvm_arm_pmu_v3_ready(vcpu))
>> +		return;
>> +
>> +	if (!(vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMCR_E))
>> +		return;
> 
> are we modeling the PMU interrupt as level-triggered?
> 
> In that case, shouldn't we lower the interrupt line on flush when
> PMCR_EL0.E == 0 ?
> 
Rethink about this, I think you're right. :)

Thanks,
-- 
Shannon



From xuejiancheng at huawei.com  Sun Feb 21 23:47:54 2016
From: xuejiancheng at huawei.com (Jiancheng Xue)
Date: Mon, 22 Feb 2016 15:47:54 +0800
Subject: [PATCH v9 0/6] ARM: hisi: Add initial support including clock driver
 for Hi3519 soc.
Message-ID: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>

Hello,

Hi3519 soc is mainly used for ip camera and sport DV solutions. This patchset adds initial support
for Hi3519 soc. It includes clock driver, arch configuration, debug uart configuration and device tree.
It has been tested on hi3519 reference board.

Any comments will be appreciated!

Thanks!

Change Log
----------
v9:
--Fixed issues pointed by Michael Turquette.

v8:
--Made hi3519 clock driver can be compiled as a module
--Fixed an issue in arch/arm/Kconfig.debug

v7:
--Rebased to v4.5-rc1

v6:
-Changed clock driver to a real platform driver

v5:
-Adjusted clock and reset controller driver code

v4:
-Rebased to v4.4-rc7
-Divided patches according to Rob's comments
-Added spi nodes in hi3519-demb.dts

v3:
-Rebased to v4.4-rc4
-Adjusted according to Arnd's comments
-Removed ARCH_HI3519, using ARCH_HISI directly

v2:
-Rebased to v4.4-rc3
-Put dt-binding doc and header file in a separate patch.
-Deleted unused clocks definitions.
-Adjusted the ARCH_xxx order in Kconfig file
-Renamed ARCH_HI3xxx to ARCH_36xx

Jiancheng Xue (6):
  clk: hisilicon: export some hisilicon APIs to modules
  clk: hisilicon: add CRG driver for hi3519 soc
  ARM: hisi: add compatible string for Hi3519 soc
  ARM: debug: add hi3519 debug uart
  ARM: dt-bindings: add device tree bindings for Hi3519 sysctrl
  ARM: dts: add dts files for Hi3519

 .../bindings/arm/hisilicon/hi3519-sysctrl.txt      |  14 ++
 .../devicetree/bindings/clock/hi3519-crg.txt       |  46 +++++
 arch/arm/Kconfig.debug                             |  10 ++
 arch/arm/boot/dts/Makefile                         |   2 +
 arch/arm/boot/dts/hi3519-demb.dts                  |  42 +++++
 arch/arm/boot/dts/hi3519.dtsi                      | 187 +++++++++++++++++++++
 arch/arm/mach-hisi/hisilicon.c                     |  23 +--
 drivers/clk/hisilicon/Kconfig                      |  15 ++
 drivers/clk/hisilicon/Makefile                     |   2 +
 drivers/clk/hisilicon/clk-hi3519.c                 | 129 ++++++++++++++
 drivers/clk/hisilicon/clk.c                        |  23 ++-
 drivers/clk/hisilicon/clk.h                        |  14 +-
 drivers/clk/hisilicon/reset.c                      | 124 ++++++++++++++
 drivers/clk/hisilicon/reset.h                      |  32 ++++
 include/dt-bindings/clock/hi3519-clock.h           |  40 +++++
 15 files changed, 669 insertions(+), 34 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt
 create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
 create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
 create mode 100644 arch/arm/boot/dts/hi3519.dtsi
 create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
 create mode 100644 drivers/clk/hisilicon/reset.c
 create mode 100644 drivers/clk/hisilicon/reset.h
 create mode 100644 include/dt-bindings/clock/hi3519-clock.h

-- 
1.9.1



From xuejiancheng at huawei.com  Sun Feb 21 23:47:58 2016
From: xuejiancheng at huawei.com (Jiancheng Xue)
Date: Mon, 22 Feb 2016 15:47:58 +0800
Subject: [PATCH v9 4/6] ARM: debug: add hi3519 debug uart
In-Reply-To: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
References: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
Message-ID: <1456127280-23275-5-git-send-email-xuejiancheng@huawei.com>

add hi3519 debug uart

Signed-off-by: Jiancheng Xue <xuejiancheng at huawei.com>
---
 arch/arm/Kconfig.debug | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index c6b6175..edd3fbe 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -260,6 +260,14 @@ choice
 		  Say Y here if you want kernel low-level debugging support
 		  on Cortina Gemini based platforms.
 
+	config DEBUG_HI3519_UART
+		bool "Hisilicon HI3519 Debug UART"
+		depends on ARCH_HISI
+		select DEBUG_UART_PL01X
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on HI3519 UART.
+
 	config DEBUG_HI3620_UART
 		bool "Hisilicon HI3620 Debug UART"
 		depends on ARCH_HI3xxx
@@ -1451,6 +1459,7 @@ config DEBUG_UART_PHYS
 	default 0x11002000 if DEBUG_MT8127_UART0
 	default 0x11006000 if DEBUG_MT6589_UART0
 	default 0x11009000 if DEBUG_MT8135_UART3
+	default 0x12100000 if DEBUG_HI3519_UART
 	default 0x16000000 if DEBUG_INTEGRATOR
 	default 0x18000300 if DEBUG_BCM_5301X
 	default 0x18010000 if DEBUG_SIRFATLAS7_UART0
@@ -1619,6 +1628,7 @@ config DEBUG_UART_VIRT
 	default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART
 	default 0xfee82340 if ARCH_IOP13XX
 	default 0xfef00000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
+	default 0xfef00000 if DEBUG_HI3519_UART
 	default 0xfef00003 if ARCH_IXP4XX && CPU_BIG_ENDIAN
 	default 0xfef36000 if DEBUG_HIGHBANK_UART
 	default 0xfefb0000 if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
-- 
1.9.1



From xuejiancheng at huawei.com  Sun Feb 21 23:47:56 2016
From: xuejiancheng at huawei.com (Jiancheng Xue)
Date: Mon, 22 Feb 2016 15:47:56 +0800
Subject: [PATCH v9 2/6] clk: hisilicon: add CRG driver for hi3519 soc
In-Reply-To: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
References: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
Message-ID: <1456127280-23275-3-git-send-email-xuejiancheng@huawei.com>

The CRG(Clock and Reset Generator) block provides clock
and reset signals for other modules in hi3519 soc.

Signed-off-by: Jiancheng Xue <xuejiancheng at huawei.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/clock/hi3519-crg.txt       |  46 ++++++++
This file has been acked by Rob Herring.
 drivers/clk/hisilicon/Kconfig                      |  15 +++
 drivers/clk/hisilicon/Makefile                     |   2 +
 drivers/clk/hisilicon/clk-hi3519.c                 | 129 +++++++++++++++++++++
 drivers/clk/hisilicon/reset.c                      | 124 ++++++++++++++++++++
 drivers/clk/hisilicon/reset.h                      |  32 +++++
 include/dt-bindings/clock/hi3519-clock.h           |  40 +++++++
 7 files changed, 388 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
 create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
 create mode 100644 drivers/clk/hisilicon/reset.c
 create mode 100644 drivers/clk/hisilicon/reset.h
 create mode 100644 include/dt-bindings/clock/hi3519-clock.h

diff --git a/Documentation/devicetree/bindings/clock/hi3519-crg.txt b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
new file mode 100644
index 0000000..2d23950
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
@@ -0,0 +1,46 @@
+* Hisilicon Hi3519 Clock and Reset Generator(CRG)
+
+The Hi3519 CRG module provides clock and reset signals to various
+controllers within the SoC.
+
+This binding uses the following bindings:
+    Documentation/devicetree/bindings/clock/clock-bindings.txt
+    Documentation/devicetree/bindings/reset/reset.txt
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "hisilicon,hi3519-crg" - controller compatible with Hi3519 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in <dt-bindings/clock/hi3519-clock.h>.
+
+- #reset-cells: should be 2.
+
+A reset signal can be controlled by writing a bit register in the CRG module.
+The reset specifier consists of two cells. The first cell represents the
+register offset relative to the base address. The second cell represents the
+bit index in the register.
+
+Example: CRG nodes
+CRG: clock-reset-controller at 12010000 {
+	compatible = "hisilicon,hi3519-crg";
+        reg = <0x12010000 0x10000>;
+        #clock-cells = <1>;
+        #reset-cells = <2>;
+};
+
+Example: consumer nodes
+i2c0: i2c at 12110000 {
+	compatible = "hisilicon,hi3519-i2c";
+        reg = <0x12110000 0x1000>;
+        clocks = <&CRG HI3519_I2C0_RST>;*/
+        resets = <&CRG 0xe4 0>;
+};
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
index e434854..296371f 100644
--- a/drivers/clk/hisilicon/Kconfig
+++ b/drivers/clk/hisilicon/Kconfig
@@ -1,3 +1,11 @@
+config COMMON_CLK_HI3519
+	tristate "Hi3519 Clock Driver"
+	depends on ARCH_HISI || COMPILE_TEST
+	select RESET_HISI
+	default y
+	help
+	  Build the clock driver for hi3519.
+
 config COMMON_CLK_HI6220
 	bool "Hi6220 Clock Driver"
 	depends on ARCH_HISI || COMPILE_TEST
@@ -5,6 +13,13 @@ config COMMON_CLK_HI6220
 	help
 	  Build the Hisilicon Hi6220 clock driver based on the common clock framework.
 
+config RESET_HISI
+	bool "HiSilicon Reset Controller Driver"
+	depends on ARCH_HISI
+	select RESET_CONTROLLER
+	help
+	  Build reset controller driver for HiSilicon device chipsets.
+
 config STUB_CLK_HI6220
 	bool "Hi6220 Stub Clock Driver"
 	depends on COMMON_CLK_HI6220 && MAILBOX
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
index 74dba31..e169ec7 100644
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -7,5 +7,7 @@ obj-y	+= clk.o clkgate-separated.o clkdivider-hi6220.o
 obj-$(CONFIG_ARCH_HI3xxx)	+= clk-hi3620.o
 obj-$(CONFIG_ARCH_HIP04)	+= clk-hip04.o
 obj-$(CONFIG_ARCH_HIX5HD2)	+= clk-hix5hd2.o
+obj-$(CONFIG_COMMON_CLK_HI3519)	+= clk-hi3519.o
 obj-$(CONFIG_COMMON_CLK_HI6220)	+= clk-hi6220.o
+obj-$(CONFIG_RESET_HISI)	+= reset.o
 obj-$(CONFIG_STUB_CLK_HI6220)	+= clk-hi6220-stub.o
diff --git a/drivers/clk/hisilicon/clk-hi3519.c b/drivers/clk/hisilicon/clk-hi3519.c
new file mode 100644
index 0000000..ee9df82
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi3519.c
@@ -0,0 +1,129 @@
+/*
+ * Hi3519 Clock Driver
+ *
+ * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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 <dt-bindings/clock/hi3519-clock.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include "clk.h"
+#include "reset.h"
+
+#define HI3519_INNER_CLK_OFFSET	64
+#define HI3519_FIXED_24M	65
+#define HI3519_FIXED_50M	66
+#define HI3519_FIXED_75M	67
+#define HI3519_FIXED_125M	68
+#define HI3519_FIXED_150M	69
+#define HI3519_FIXED_200M	70
+#define HI3519_FIXED_250M	71
+#define HI3519_FIXED_300M	72
+#define HI3519_FIXED_400M	73
+#define HI3519_FMC_MUX		74
+
+#define HI3519_NR_CLKS		128
+
+static const struct hisi_fixed_rate_clock hi3519_fixed_rate_clks[] = {
+	{ HI3519_FIXED_24M, "24m", NULL, CLK_IS_ROOT, 24000000, },
+	{ HI3519_FIXED_50M, "50m", NULL, CLK_IS_ROOT, 50000000, },
+	{ HI3519_FIXED_75M, "75m", NULL, CLK_IS_ROOT, 75000000, },
+	{ HI3519_FIXED_125M, "125m", NULL, CLK_IS_ROOT, 125000000, },
+	{ HI3519_FIXED_150M, "150m", NULL, CLK_IS_ROOT, 150000000, },
+	{ HI3519_FIXED_200M, "200m", NULL, CLK_IS_ROOT, 200000000, },
+	{ HI3519_FIXED_250M, "250m", NULL, CLK_IS_ROOT, 250000000, },
+	{ HI3519_FIXED_300M, "300m", NULL, CLK_IS_ROOT, 300000000, },
+	{ HI3519_FIXED_400M, "400m", NULL, CLK_IS_ROOT, 400000000, },
+};
+
+static const char *const fmc_mux_p[] = {
+		"24m", "75m", "125m", "150m", "200m", "250m", "300m", "400m", };
+static u32 fmc_mux_table[] = {0, 1, 2, 3, 4, 5, 6, 7};
+
+static const struct hisi_mux_clock hi3519_mux_clks[] = {
+	{ HI3519_FMC_MUX, "fmc_mux", fmc_mux_p, ARRAY_SIZE(fmc_mux_p),
+		CLK_SET_RATE_PARENT, 0xc0, 2, 3, 0, fmc_mux_table, },
+};
+
+static const struct hisi_gate_clock hi3519_gate_clks[] = {
+	{ HI3519_FMC_CLK, "clk_fmc", "fmc_mux",
+		CLK_SET_RATE_PARENT, 0xc0, 1, 0, },
+	{ HI3519_UART0_CLK, "clk_uart0", "24m",
+		CLK_SET_RATE_PARENT, 0xe4, 20, 0, },
+	{ HI3519_UART1_CLK, "clk_uart1", "24m",
+		CLK_SET_RATE_PARENT, 0xe4, 21, 0, },
+	{ HI3519_UART2_CLK, "clk_uart2", "24m",
+		CLK_SET_RATE_PARENT, 0xe4, 22, 0, },
+	{ HI3519_UART3_CLK, "clk_uart3", "24m",
+		CLK_SET_RATE_PARENT, 0xe4, 23, 0, },
+	{ HI3519_UART4_CLK, "clk_uart4", "24m",
+		CLK_SET_RATE_PARENT, 0xe4, 24, 0, },
+	{ HI3519_SPI0_CLK, "clk_spi0", "50m",
+		CLK_SET_RATE_PARENT, 0xe4, 16, 0, },
+	{ HI3519_SPI1_CLK, "clk_spi1", "50m",
+		CLK_SET_RATE_PARENT, 0xe4, 17, 0, },
+	{ HI3519_SPI2_CLK, "clk_spi2", "50m",
+		CLK_SET_RATE_PARENT, 0xe4, 18, 0, },
+};
+
+static int hi3519_clk_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct hisi_clock_data *clk_data;
+
+	clk_data = hisi_clk_init(np, HI3519_NR_CLKS);
+	if (!clk_data)
+		return -ENODEV;
+
+	hisi_clk_register_fixed_rate(hi3519_fixed_rate_clks,
+				     ARRAY_SIZE(hi3519_fixed_rate_clks),
+				     clk_data);
+	hisi_clk_register_mux(hi3519_mux_clks, ARRAY_SIZE(hi3519_mux_clks),
+					clk_data);
+	hisi_clk_register_gate(hi3519_gate_clks,
+			ARRAY_SIZE(hi3519_gate_clks), clk_data);
+
+	return hisi_reset_init(np);
+}
+
+static const struct of_device_id hi3519_clk_match_table[] = {
+	{ .compatible = "hisilicon,hi3519-crg" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, hi3519_clk_match_table);
+
+static struct platform_driver hi3519_clk_driver = {
+	.probe          = hi3519_clk_probe,
+	.driver         = {
+		.name   = "hi3519-clk",
+		.of_match_table = hi3519_clk_match_table,
+	},
+};
+
+static int __init hi3519_clk_init(void)
+{
+	return platform_driver_register(&hi3519_clk_driver);
+}
+core_initcall(hi3519_clk_init);
+
+static void __exit hi3519_clk_exit(void)
+{
+	platform_driver_unregister(&hi3519_clk_driver);
+}
+module_exit(hi3519_clk_exit);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("HiSilicon Hi3519 Clock Driver");
diff --git a/drivers/clk/hisilicon/reset.c b/drivers/clk/hisilicon/reset.c
new file mode 100644
index 0000000..50e00e7
--- /dev/null
+++ b/drivers/clk/hisilicon/reset.c
@@ -0,0 +1,124 @@
+/*
+ * Hisilicon Reset Controller Driver
+ *
+ * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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/io.h>
+#include <linux/of_address.h>
+#include <linux/reset-controller.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+
+#define	HISI_RESET_BIT_MASK	0x1f
+#define	HISI_RESET_OFFSET_SHIFT	8
+#define	HISI_RESET_OFFSET_MASK	0xffff00
+
+struct hisi_reset_controller {
+	spinlock_t	lock;
+	void __iomem	*membase;
+	struct reset_controller_dev	rcdev;
+};
+
+
+#define to_hisi_reset_controller(rcdev)  \
+	container_of(rcdev, struct hisi_reset_controller, rcdev)
+
+static int hisi_reset_of_xlate(struct reset_controller_dev *rcdev,
+			const struct of_phandle_args *reset_spec)
+{
+	u32 offset;
+	u8 bit;
+
+	if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
+		return -EINVAL;
+
+	offset = (reset_spec->args[0] << HISI_RESET_OFFSET_SHIFT)
+		& HISI_RESET_OFFSET_MASK;
+	bit = reset_spec->args[1] & HISI_RESET_BIT_MASK;
+	return (offset | bit);
+}
+
+static int hisi_reset_assert(struct reset_controller_dev *rcdev,
+			      unsigned long id)
+{
+	struct hisi_reset_controller *rstc = to_hisi_reset_controller(rcdev);
+	unsigned long flags;
+	u32 offset, reg;
+	u8 bit;
+
+	offset = (id & HISI_RESET_OFFSET_MASK) >> HISI_RESET_OFFSET_SHIFT;
+	bit = id & HISI_RESET_BIT_MASK;
+
+	spin_lock_irqsave(&rstc->lock, flags);
+
+	reg = readl(rstc->membase + offset);
+	writel(reg | BIT(bit), rstc->membase + offset);
+
+	spin_unlock_irqrestore(&rstc->lock, flags);
+
+	return 0;
+}
+
+static int hisi_reset_deassert(struct reset_controller_dev *rcdev,
+				unsigned long id)
+{
+	struct hisi_reset_controller *rstc = to_hisi_reset_controller(rcdev);
+	unsigned long flags;
+	u32 offset, reg;
+	u8 bit;
+
+	offset = (id & HISI_RESET_OFFSET_MASK) >> HISI_RESET_OFFSET_SHIFT;
+	bit = id & HISI_RESET_BIT_MASK;
+
+	spin_lock_irqsave(&rstc->lock, flags);
+
+	reg = readl(rstc->membase + offset);
+	writel(reg & ~BIT(bit), rstc->membase + offset);
+
+	spin_unlock_irqrestore(&rstc->lock, flags);
+
+	return 0;
+}
+
+static struct reset_control_ops hisi_reset_ops = {
+	.assert		= hisi_reset_assert,
+	.deassert	= hisi_reset_deassert,
+};
+
+int hisi_reset_init(struct device_node *np)
+{
+	struct hisi_reset_controller *rstc;
+
+	rstc = kzalloc(sizeof(*rstc), GFP_KERNEL);
+	if (!rstc)
+		return -ENOMEM;
+
+	rstc->membase = of_iomap(np, 0);
+	if (!rstc->membase)
+		return -EINVAL;
+
+	spin_lock_init(&rstc->lock);
+
+	rstc->rcdev.owner = THIS_MODULE;
+	rstc->rcdev.ops = &hisi_reset_ops;
+	rstc->rcdev.of_node = np;
+	rstc->rcdev.of_reset_n_cells = 2;
+	rstc->rcdev.of_xlate = hisi_reset_of_xlate;
+
+	return reset_controller_register(&rstc->rcdev);
+}
+EXPORT_SYMBOL(hisi_reset_init);
diff --git a/drivers/clk/hisilicon/reset.h b/drivers/clk/hisilicon/reset.h
new file mode 100644
index 0000000..ffad4d7
--- /dev/null
+++ b/drivers/clk/hisilicon/reset.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef	__HISI_RESET_H
+#define	__HISI_RESET_H
+
+struct device_node;
+
+#ifdef CONFIG_RESET_CONTROLLER
+int hisi_reset_init(struct device_node *np);
+#else
+static inline int hisi_reset_init(struct device_node *np)
+{
+	return 0;
+}
+#endif
+
+#endif	/* __HISI_RESET_H */
diff --git a/include/dt-bindings/clock/hi3519-clock.h b/include/dt-bindings/clock/hi3519-clock.h
new file mode 100644
index 0000000..4989c80
--- /dev/null
+++ b/include/dt-bindings/clock/hi3519-clock.h
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __DTS_HI3519_CLOCK_H
+#define __DTS_HI3519_CLOCK_H
+
+#define HI3519_FMC_CLK			1
+#define HI3519_USB2_BUS_CLK		2
+#define HI3519_USB2_PORT_CLK		3
+#define HI3519_USB3_CLK			4
+#define HI3519_ETH_PHY_CLK		5
+#define HI3519_ETH_MAC_CLK		6
+#define HI3519_ETH_MACIF_CLK		7
+#define HI3519_PWM_CLK			8
+#define HI3519_DMA_CLK			9
+#define HI3519_SPI0_CLK			10
+#define HI3519_SPI1_CLK			11
+#define HI3519_SPI2_CLK			12
+#define HI3519_IR_CLK			13
+#define HI3519_UART0_CLK		14
+#define HI3519_UART1_CLK		15
+#define HI3519_UART2_CLK		16
+#define HI3519_UART3_CLK		17
+#define HI3519_UART4_CLK		18
+
+#endif	/* __DTS_HI3519_CLOCK_H */
-- 
1.9.1



From xuejiancheng at huawei.com  Sun Feb 21 23:47:59 2016
From: xuejiancheng at huawei.com (Jiancheng Xue)
Date: Mon, 22 Feb 2016 15:47:59 +0800
Subject: [PATCH v9 5/6] ARM: dt-bindings: add device tree bindings for Hi3519
 sysctrl
In-Reply-To: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
References: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
Message-ID: <1456127280-23275-6-git-send-email-xuejiancheng@huawei.com>

Add device tree bindings for Hi3519 system controller.

Signed-off-by: Jiancheng Xue <xuejiancheng at huawei.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt   | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt b/Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt
new file mode 100644
index 0000000..115c5be
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt
@@ -0,0 +1,14 @@
+* Hisilicon Hi3519 System Controller Block
+
+This bindings use the following binding:
+Documentation/devicetree/bindings/mfd/syscon.txt
+
+Required properties:
+- compatible: "hisilicon,hi3519-sysctrl".
+- reg: the register region of this block
+
+Examples:
+sysctrl: system-controller at 12010000 {
+	compatible = "hisilicon,hi3519-sysctrl", "syscon";
+	reg = <0x12010000 0x1000>;
+};
-- 
1.9.1



From k at japko.eu  Mon Feb 22 00:00:42 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Mon, 22 Feb 2016 09:00:42 +0100
Subject: [linux-sunxi] Re: [PATCH v3] Fix sun7i pin assignment for IRQ's
In-Reply-To: <4cf9dbe3-faa6-4729-87fd-0e7d9ce463b0@googlegroups.com>
References: <1456060845-20692-1-git-send-email-henry@nitronetworks.nl>
 <20160221171830.GD19169@lukather>
 <4cf9dbe3-faa6-4729-87fd-0e7d9ce463b0@googlegroups.com>
Message-ID: <20160222080041.GF18745@box2.japko.eu>

On Sun, Feb 21, 2016 at 11:27:46AM -0800, Henry Paulissen wrote:
>
>Op zondag 21 februari 2016 18:18:37 UTC+1 schreef Maxime Ripard:
>
>>
>> Your commit log is going to need some work. Which bugs? What tests did
>> you make? Why are you making these changes while the datasheet says
>> otherwise?
>>
>
>Its a fix for a not yet existing bug. I was fiddling around with IRQ's and
>couldn't get them to work.
>I took a dumpster dive into it and found a shitload of contradicting
>manuals and datasheets.
>
>
>Take for example the A20 user manual:
>http://dl.linux-sunxi.org/A20/A20%20user%20manual%20v1.3%2020141010.pdf
>
>(pin PI14)
>Page 237: EINT26 is on mux *5* in the pin overview.
>Page 288: EINT26 is on mux *6* in the registers.
>
>Page 233: EINT12 is on pin PC19 mux6 in the pin overview.
>Page 236: EINT12 is on pin PH12 mux6 in the pin overview.
>Page 253: EINT12 is *not* on pin PC19 on the registers.
>Page 281: EINT12 is on pin PH12 mux6 in the registers.
>
>So manual may say otherwise, but I hope I have proven that the manual isn't
>to be trusted.
>
>My patch is based onto testing from both me and Andre (apritzel).
>He with a Banana PI M1 and me with a Cubietruck (both A20 soc).
>
>We did a basic test by connecting a pulsing signal to a port and configure
>kernel to use irq.
>
>e.g.
>echo pin# > /sys/class/gpio/export
>echo in > /sys/class/gpio/gpio#/direction
>echo rising > /sys/class/gpio/gpio#/edge
>
>and check on /proc/interrupts to see if a irq was attached and if it was
>receiving.
>
>Im not sure what andre his pulse source was, but mine was a 1pps coming
>from a gps.

That's quite clear to anybody reading this mailinglist but it won't be 
to anyone reading just commit message (and there will be many of them).  
You should try to put some of this into the commit message.


From xuejiancheng at huawei.com  Sun Feb 21 23:47:57 2016
From: xuejiancheng at huawei.com (Jiancheng Xue)
Date: Mon, 22 Feb 2016 15:47:57 +0800
Subject: [PATCH v9 3/6] ARM: hisi: add compatible string for Hi3519 soc
In-Reply-To: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
References: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
Message-ID: <1456127280-23275-4-git-send-email-xuejiancheng@huawei.com>

add compatible string for Hi3519 soc.

Signed-off-by: Jiancheng Xue <xuejiancheng at huawei.com>
---
 arch/arm/mach-hisi/hisilicon.c | 23 ++++-------------------
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c
index 8cc6215..00dae89 100644
--- a/arch/arm/mach-hisi/hisilicon.c
+++ b/arch/arm/mach-hisi/hisilicon.c
@@ -54,30 +54,15 @@ DT_MACHINE_START(HI3620, "Hisilicon Hi3620 (Flattened Device Tree)")
 	.dt_compat	= hi3xxx_compat,
 MACHINE_END
 
-static const char *const hix5hd2_compat[] __initconst = {
+static const char *const hisilicon_compat[] __initconst = {
 	"hisilicon,hix5hd2",
-	NULL,
-};
-
-DT_MACHINE_START(HIX5HD2_DT, "Hisilicon HIX5HD2 (Flattened Device Tree)")
-	.dt_compat	= hix5hd2_compat,
-MACHINE_END
-
-static const char *const hip04_compat[] __initconst = {
 	"hisilicon,hip04-d01",
-	NULL,
-};
-
-DT_MACHINE_START(HIP04, "Hisilicon HiP04 (Flattened Device Tree)")
-	.dt_compat	= hip04_compat,
-MACHINE_END
-
-static const char *const hip01_compat[] __initconst = {
 	"hisilicon,hip01",
 	"hisilicon,hip01-ca9x2",
+	"hisilicon,hi3519",
 	NULL,
 };
 
-DT_MACHINE_START(HIP01, "Hisilicon HIP01 (Flattened Device Tree)")
-	.dt_compat      = hip01_compat,
+DT_MACHINE_START(HISILICON_DT, "HiSilicon Soc")
+	.dt_compat	= hisilicon_compat,
 MACHINE_END
-- 
1.9.1



From xuejiancheng at huawei.com  Sun Feb 21 23:47:55 2016
From: xuejiancheng at huawei.com (Jiancheng Xue)
Date: Mon, 22 Feb 2016 15:47:55 +0800
Subject: [PATCH v9 1/6] clk: hisilicon: export some hisilicon APIs to modules
In-Reply-To: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
References: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
Message-ID: <1456127280-23275-2-git-send-email-xuejiancheng@huawei.com>

Change some arguments to constant type.
Export some hisilicon APIs to modules.

Signed-off-by: Jiancheng Xue <xuejiancheng at huawei.com>
---
 drivers/clk/hisilicon/clk.c | 23 +++++++++++++++--------
 drivers/clk/hisilicon/clk.h | 14 +++++++-------
 2 files changed, 22 insertions(+), 15 deletions(-)

diff --git a/drivers/clk/hisilicon/clk.c b/drivers/clk/hisilicon/clk.c
index 9f8e766..06ec3fe 100644
--- a/drivers/clk/hisilicon/clk.c
+++ b/drivers/clk/hisilicon/clk.c
@@ -37,7 +37,7 @@
 
 static DEFINE_SPINLOCK(hisi_clk_lock);
 
-struct hisi_clock_data __init *hisi_clk_init(struct device_node *np,
+struct hisi_clock_data *hisi_clk_init(struct device_node *np,
 					     int nr_clks)
 {
 	struct hisi_clock_data *clk_data;
@@ -71,8 +71,9 @@ err_data:
 err:
 	return NULL;
 }
+EXPORT_SYMBOL(hisi_clk_init);
 
-void __init hisi_clk_register_fixed_rate(struct hisi_fixed_rate_clock *clks,
+void hisi_clk_register_fixed_rate(const struct hisi_fixed_rate_clock *clks,
 					 int nums, struct hisi_clock_data *data)
 {
 	struct clk *clk;
@@ -91,8 +92,9 @@ void __init hisi_clk_register_fixed_rate(struct hisi_fixed_rate_clock *clks,
 		data->clk_data.clks[clks[i].id] = clk;
 	}
 }
+EXPORT_SYMBOL(hisi_clk_register_fixed_rate);
 
-void __init hisi_clk_register_fixed_factor(struct hisi_fixed_factor_clock *clks,
+void hisi_clk_register_fixed_factor(const struct hisi_fixed_factor_clock *clks,
 					   int nums,
 					   struct hisi_clock_data *data)
 {
@@ -112,8 +114,9 @@ void __init hisi_clk_register_fixed_factor(struct hisi_fixed_factor_clock *clks,
 		data->clk_data.clks[clks[i].id] = clk;
 	}
 }
+EXPORT_SYMBOL(hisi_clk_register_fixed_factor);
 
-void __init hisi_clk_register_mux(struct hisi_mux_clock *clks,
+void hisi_clk_register_mux(const struct hisi_mux_clock *clks,
 				  int nums, struct hisi_clock_data *data)
 {
 	struct clk *clk;
@@ -141,8 +144,9 @@ void __init hisi_clk_register_mux(struct hisi_mux_clock *clks,
 		data->clk_data.clks[clks[i].id] = clk;
 	}
 }
+EXPORT_SYMBOL(hisi_clk_register_mux);
 
-void __init hisi_clk_register_divider(struct hisi_divider_clock *clks,
+void hisi_clk_register_divider(const struct hisi_divider_clock *clks,
 				      int nums, struct hisi_clock_data *data)
 {
 	struct clk *clk;
@@ -170,8 +174,9 @@ void __init hisi_clk_register_divider(struct hisi_divider_clock *clks,
 		data->clk_data.clks[clks[i].id] = clk;
 	}
 }
+EXPORT_SYMBOL(hisi_clk_register_divider);
 
-void __init hisi_clk_register_gate(struct hisi_gate_clock *clks,
+void hisi_clk_register_gate(const struct hisi_gate_clock *clks,
 				       int nums, struct hisi_clock_data *data)
 {
 	struct clk *clk;
@@ -198,8 +203,9 @@ void __init hisi_clk_register_gate(struct hisi_gate_clock *clks,
 		data->clk_data.clks[clks[i].id] = clk;
 	}
 }
+EXPORT_SYMBOL(hisi_clk_register_gate);
 
-void __init hisi_clk_register_gate_sep(struct hisi_gate_clock *clks,
+void hisi_clk_register_gate_sep(const struct hisi_gate_clock *clks,
 				       int nums, struct hisi_clock_data *data)
 {
 	struct clk *clk;
@@ -226,8 +232,9 @@ void __init hisi_clk_register_gate_sep(struct hisi_gate_clock *clks,
 		data->clk_data.clks[clks[i].id] = clk;
 	}
 }
+EXPORT_SYMBOL(hisi_clk_register_gate_sep);
 
-void __init hi6220_clk_register_divider(struct hi6220_divider_clock *clks,
+void __init hi6220_clk_register_divider(const struct hi6220_divider_clock *clks,
 					int nums, struct hisi_clock_data *data)
 {
 	struct clk *clk;
diff --git a/drivers/clk/hisilicon/clk.h b/drivers/clk/hisilicon/clk.h
index b56fbc1..20d64af 100644
--- a/drivers/clk/hisilicon/clk.h
+++ b/drivers/clk/hisilicon/clk.h
@@ -111,18 +111,18 @@ struct clk *hi6220_register_clkdiv(struct device *dev, const char *name,
 	u8 shift, u8 width, u32 mask_bit, spinlock_t *lock);
 
 struct hisi_clock_data *hisi_clk_init(struct device_node *, int);
-void hisi_clk_register_fixed_rate(struct hisi_fixed_rate_clock *,
+void hisi_clk_register_fixed_rate(const struct hisi_fixed_rate_clock *,
 				int, struct hisi_clock_data *);
-void hisi_clk_register_fixed_factor(struct hisi_fixed_factor_clock *,
+void hisi_clk_register_fixed_factor(const struct hisi_fixed_factor_clock *,
 				int, struct hisi_clock_data *);
-void hisi_clk_register_mux(struct hisi_mux_clock *, int,
+void hisi_clk_register_mux(const struct hisi_mux_clock *, int,
 				struct hisi_clock_data *);
-void hisi_clk_register_divider(struct hisi_divider_clock *,
+void hisi_clk_register_divider(const struct hisi_divider_clock *,
 				int, struct hisi_clock_data *);
-void hisi_clk_register_gate(struct hisi_gate_clock *,
+void hisi_clk_register_gate(const struct hisi_gate_clock *,
 				int, struct hisi_clock_data *);
-void hisi_clk_register_gate_sep(struct hisi_gate_clock *,
+void hisi_clk_register_gate_sep(const struct hisi_gate_clock *,
 				int, struct hisi_clock_data *);
-void hi6220_clk_register_divider(struct hi6220_divider_clock *,
+void hi6220_clk_register_divider(const struct hi6220_divider_clock *,
 				int, struct hisi_clock_data *);
 #endif	/* __HISI_CLK_H */
-- 
1.9.1



From sugar.zhang at rock-chips.com  Sun Feb 21 23:56:53 2016
From: sugar.zhang at rock-chips.com (Sugar Zhang)
Date: Mon, 22 Feb 2016 15:56:53 +0800
Subject: [PATCH v1 0/2] patches to add support for rockchip rt5640 card
Message-ID: <1456127815-68575-1-git-send-email-sugar.zhang@rock-chips.com>

add default values for i2s registers from TRM.
rt5640: add master clock handing.


Sugar Zhang (2):
  ASoC: rockchip: i2s: add default values for registers
  ASoC: rt5640: add master clock handling for rt5640

 Documentation/devicetree/bindings/sound/rt5640.txt |  3 +++
 sound/soc/codecs/rt5640.c                          | 31 ++++++++++++++++++++++
 sound/soc/codecs/rt5640.h                          |  2 ++
 sound/soc/rockchip/rockchip_i2s.c                  | 10 +++++++
 4 files changed, 46 insertions(+)

-- 
1.9.1




From xuejiancheng at huawei.com  Sun Feb 21 23:48:00 2016
From: xuejiancheng at huawei.com (Jiancheng Xue)
Date: Mon, 22 Feb 2016 15:48:00 +0800
Subject: [PATCH v9 6/6] ARM: dts: add dts files for Hi3519
In-Reply-To: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
References: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
Message-ID: <1456127280-23275-7-git-send-email-xuejiancheng@huawei.com>

add dts files for Hi3519

Signed-off-by: Jiancheng Xue <xuejiancheng at huawei.com>
---
 arch/arm/boot/dts/Makefile        |   2 +
 arch/arm/boot/dts/hi3519-demb.dts |  42 +++++++++
 arch/arm/boot/dts/hi3519.dtsi     | 187 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 231 insertions(+)
 create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
 create mode 100644 arch/arm/boot/dts/hi3519.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..3ce36ff 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -141,6 +141,8 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
 	exynos5800-peach-pi.dtb
 dtb-$(CONFIG_ARCH_HI3xxx) += \
 	hi3620-hi4511.dtb
+dtb-$(CONFIG_ARCH_HISI) += \
+	hi3519-demb.dtb
 dtb-$(CONFIG_ARCH_HIX5HD2) += \
 	hisi-x5hd2-dkb.dtb
 dtb-$(CONFIG_ARCH_HIGHBANK) += \
diff --git a/arch/arm/boot/dts/hi3519-demb.dts b/arch/arm/boot/dts/hi3519-demb.dts
new file mode 100644
index 0000000..6991ab6
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519-demb.dts
@@ -0,0 +1,42 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ *
+ */
+
+/dts-v1/;
+#include "hi3519.dtsi"
+
+/ {
+	model = "HiSilicon HI3519 DEMO Board";
+	compatible = "hisilicon,hi3519";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x40000000>;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&dual_timer0 {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/hi3519.dtsi b/arch/arm/boot/dts/hi3519.dtsi
new file mode 100644
index 0000000..5729ecf
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519.dtsi
@@ -0,0 +1,187 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * 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 <dt-bindings/clock/hi3519-clock.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+/ {
+	#address-cells = <1>;
+	#size-cells = <1>;
+	chosen { };
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a7";
+			reg = <0>;
+		};
+	};
+
+	gic: interrupt-controller at 10300000 {
+		compatible = "arm,cortex-a7-gic";
+		#interrupt-cells = <3>;
+		interrupt-controller;
+		reg = <0x10301000 0x1000>, <0x10302000 0x1000>;
+	};
+
+	clk_3m: clk_3m {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <3000000>;
+	};
+
+	crg: clock-reset-controller at 12010000 {
+		compatible = "hisilicon,hi3519-crg";
+		#clock-cells = <1>;
+		#reset-cells = <2>;
+		reg = <0x12010000 0x10000>;
+	};
+
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		interrupt-parent = <&gic>;
+		ranges;
+
+		uart0: serial at 12100000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x12100000 0x1000>;
+			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_UART0_CLK>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		uart1: serial at 12101000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x12101000 0x1000>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_UART1_CLK>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		uart2: serial at 12102000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x12102000 0x1000>;
+			interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_UART2_CLK>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		uart3: serial at 12103000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x12103000 0x1000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_UART3_CLK>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		uart4: serial at 12104000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x12104000 0x1000>;
+			interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_UART4_CLK>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		dual_timer0: timer at 12000000 {
+			compatible = "arm,sp804", "arm,primecell";
+			interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
+			reg = <0x12000000 0x1000>;
+			clocks = <&clk_3m>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		dual_timer1: timer at 12001000 {
+			compatible = "arm,sp804", "arm,primecell";
+			interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
+			reg = <0x12001000 0x1000>;
+			clocks = <&clk_3m>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		dual_timer2: timer at 12002000 {
+			compatible = "arm,sp804", "arm,primecell";
+			interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
+			reg = <0x12002000 0x1000>;
+			clocks = <&clk_3m>;
+			clock-names = "apb_pclk";
+			status = "disable";
+		};
+
+		spi_bus0: spi at 12120000 {
+			compatible = "arm,pl022", "arm,primecell";
+			reg = <0x12120000 0x1000>;
+			interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_SPI0_CLK>;
+			clock-names = "apb_pclk";
+			num-cs = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disable";
+		};
+
+		spi_bus1: spi at 12121000 {
+			compatible = "arm,pl022", "arm,primecell";
+			reg = <0x12121000 0x1000>;
+			interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_SPI1_CLK>;
+			clock-names = "apb_pclk";
+			num-cs = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disable";
+		};
+
+		spi_bus2: spi at 12122000 {
+			compatible = "arm,pl022", "arm,primecell";
+			reg = <0x12122000 0x1000>;
+			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&crg HI3519_SPI2_CLK>;
+			clock-names = "apb_pclk";
+			num-cs = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			status = "disable";
+		};
+
+		sysctrl: system-controller at 12020000 {
+			compatible = "hisilicon,hi3519-sysctrl", "syscon";
+			reg = <0x12020000 0x1000>;
+		};
+
+		reboot {
+			compatible = "syscon-reboot";
+			regmap = <&sysctrl>;
+			offset = <0x4>;
+			mask = <0xdeadbeef>;
+		};
+	};
+};
-- 
1.9.1



From sugar.zhang at rock-chips.com  Sun Feb 21 23:56:54 2016
From: sugar.zhang at rock-chips.com (Sugar Zhang)
Date: Mon, 22 Feb 2016 15:56:54 +0800
Subject: [PATCH v1 1/2] ASoC: rockchip: i2s: add default values for registers
In-Reply-To: <1456127815-68575-1-git-send-email-sugar.zhang@rock-chips.com>
References: <1456127815-68575-1-git-send-email-sugar.zhang@rock-chips.com>
Message-ID: <1456127815-68575-2-git-send-email-sugar.zhang@rock-chips.com>

this patch add default values for registers according description from TRM.

Signed-off-by: Sugar Zhang <sugar.zhang at rock-chips.com>
---

 sound/soc/rockchip/rockchip_i2s.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/sound/soc/rockchip/rockchip_i2s.c b/sound/soc/rockchip/rockchip_i2s.c
index 6561c4c..a0b0942 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -440,11 +440,21 @@ static bool rockchip_i2s_precious_reg(struct device *dev, unsigned int reg)
 	}
 }
 
+static const struct reg_default rockchip_i2s_reg_defaults[] = {
+	{0x00, 0x0000000f},
+	{0x04, 0x0000000f},
+	{0x08, 0x00071f1f},
+	{0x10, 0x001f0000},
+	{0x14, 0x01f00000},
+};
+
 static const struct regmap_config rockchip_i2s_regmap_config = {
 	.reg_bits = 32,
 	.reg_stride = 4,
 	.val_bits = 32,
 	.max_register = I2S_RXDR,
+	.reg_defaults = rockchip_i2s_reg_defaults,
+	.num_reg_defaults = ARRAY_SIZE(rockchip_i2s_reg_defaults),
 	.writeable_reg = rockchip_i2s_wr_reg,
 	.readable_reg = rockchip_i2s_rd_reg,
 	.volatile_reg = rockchip_i2s_volatile_reg,
-- 
1.9.1




From wsa at the-dreams.de  Mon Feb 22 00:05:22 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Mon, 22 Feb 2016 09:05:22 +0100
Subject: [PATCH] i2c: brcmstb: allocate correct amount of memory for regmap
In-Reply-To: <CADtm3G7ZHfVyoEcAcFGC4oPX=XHyedSWDMvg6nKPLQ5_is=ZiQ@mail.gmail.com>
References: <1456064238-6294-1-git-send-email-wsa@the-dreams.de>
 <CADtm3G7ZHfVyoEcAcFGC4oPX=XHyedSWDMvg6nKPLQ5_is=ZiQ@mail.gmail.com>
Message-ID: <20160222080522.GB1389@katana>

On Sun, Feb 21, 2016 at 10:33:14PM -0800, Gregory Fong wrote:
> On Sun, Feb 21, 2016 at 6:16 AM, Wolfram Sang <wsa at the-dreams.de> wrote:
> > We want the size of the struct, not of a pointer to it. To be future
> > proof, just dereference the pointer to get the desired type.
> 
> This looks like it fixes like a fairly serious issue: before this
> change, the driver may modify memory that wasn't allocated for this
> struct.  Shouldn't this also have Cc: stable?

Surely. I usually add the tag when committing, not when sending out.

> > Signed-off-by: Wolfram Sang <wsa at the-dreams.de>
> Acked-by: Gregory Fong <gregory.0xf0 at gmail.com>

Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160222/544259df/attachment.sig>

From wens at csie.org  Mon Feb 22 00:08:10 2016
From: wens at csie.org (Chen-Yu Tsai)
Date: Mon, 22 Feb 2016 00:08:10 -0800
Subject: [PATCH] clk: sunxi: allow PLL6 clock to be reused
In-Reply-To: <1456105198-25295-1-git-send-email-andre.przywara@arm.com>
References: <1456105198-25295-1-git-send-email-andre.przywara@arm.com>
Message-ID: <CAGb2v66Fkvpqay+pNYjN1KP_KSUmv-du+PVSsyeuK+Y7bzEt+g@mail.gmail.com>

On Sun, Feb 21, 2016 at 5:39 PM, Andre Przywara <andre.przywara at arm.com> wrote:
> Currently we hard-code the base name for the PLL6 clock for both the
> sun4i and sun6i variants in the driver (pll6 and pll6x2, respectively).
> This unfortunately denies reusing this clock for the H3 and A64 PLL8
> clock, which is the same otherwise.
> Remove the hard-coded name in the source code and replace it with an
> appropriate index into the clock-output-names array in the DT.
> This is compatible with all current device trees, since they all carry
> the hard-coded base name in there.
>
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> ---
> Salut Maxime,
>
> does that patch make sense?
> It fixes the re-usability problem while still keeping compatibility
> with existing DTs and also is pretty small.
> If you agree with this, I'll send out a v3 of the A64 series including
> this patch and the H3 PLL8 enablement later.
> I tested this on my BananaPi, the clk_summary output was identical
> with and without this patch.

This look OK to me, except one minor detail below.

> Cheers,
> Andre.
>
>  drivers/clk/sunxi/clk-factors.c | 3 ++-
>  drivers/clk/sunxi/clk-factors.h | 1 +
>  drivers/clk/sunxi/clk-sunxi.c   | 4 ++--
>  3 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/sunxi/clk-factors.c b/drivers/clk/sunxi/clk-factors.c
> index ddefe96..7daf01d 100644
> --- a/drivers/clk/sunxi/clk-factors.c
> +++ b/drivers/clk/sunxi/clk-factors.c
> @@ -202,7 +202,8 @@ struct clk *sunxi_factors_register(struct device_node *node,
>         if (data->name)
>                 clk_name = data->name;
>         else
> -               of_property_read_string(node, "clock-output-names", &clk_name);
> +               of_property_read_string_index(node, "clock-output-names",
> +                                             data->name_idx, &clk_name);
>
>         factors = kzalloc(sizeof(struct clk_factors), GFP_KERNEL);
>         if (!factors)
> diff --git a/drivers/clk/sunxi/clk-factors.h b/drivers/clk/sunxi/clk-factors.h
> index 1e63c5b..3a7da86 100644
> --- a/drivers/clk/sunxi/clk-factors.h
> +++ b/drivers/clk/sunxi/clk-factors.h
> @@ -36,6 +36,7 @@ struct factors_data {
>         void (*getter)(struct factors_request *req);
>         void (*recalc)(struct factors_request *req);
>         const char *name;
> +       int name_idx;

I would drop the .name field. It was a bad workaround
due to limitations of the factors clk code at the time
by me. We really shouldn't hard-code the name if we want
to reuse the driver.

Thanks
ChenYu

>  };
>
>  struct clk_factors {
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 99f60ef..53f5927 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -530,14 +530,14 @@ static const struct factors_data sun4i_pll6_data __initconst = {
>         .enable = 31,
>         .table = &sun4i_pll5_config,
>         .getter = sun4i_get_pll5_factors,
> -       .name = "pll6",
> +       .name_idx = 2,
>  };
>
>  static const struct factors_data sun6i_a31_pll6_data __initconst = {
>         .enable = 31,
>         .table = &sun6i_a31_pll6_config,
>         .getter = sun6i_a31_get_pll6_factors,
> -       .name = "pll6x2",
> +       .name_idx = 1,
>  };
>
>  static const struct factors_data sun5i_a13_ahb_data __initconst = {
> --
> 1.8.4
>


From raveendra.padasalagi at broadcom.com  Mon Feb 22 00:10:05 2016
From: raveendra.padasalagi at broadcom.com (Raveendra Padasalagi)
Date: Mon, 22 Feb 2016 13:40:05 +0530
Subject: [PATCH v3 3/3] ARM: dts: use syscon in cygnus touchscreen dt node
In-Reply-To: <1456127379-25866-4-git-send-email-raveendra.padasalagi@broadcom.com>
References: <1456127379-25866-1-git-send-email-raveendra.padasalagi@broadcom.com>
 <1456127379-25866-4-git-send-email-raveendra.padasalagi@broadcom.com>
Message-ID: <CAAFb_vocadoQ1Egt4PgOX4pW2Tz5aifqWZQxQKOhvNeq0frsYQ@mail.gmail.com>

On Mon, Feb 22, 2016 at 1:19 PM, Raveendra Padasalagi
<raveendra.padasalagi at broadcom.com> wrote:
> In Cygnus SOC touch screen controller registers are shared
> with ADC and flex timer. Using readl/writel could lead to
> race condition. So in such case register access is handled
> through syscon framework API's in the touch screen driver.
> This feature is enabled if "brcm,iproc-touchscreen-syscon"
> compatible string is selected in touchscreen dt node.
>
> So this patch enables syscon support in touchscreen driver
> by adding necessary properties in touchscreen dt node.
>
> Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi at broadcom.com>
> Reviewed-by: Ray Jui <ray.jui at broadcom.com>
> Reviewed-by: Scott Branden <scott.branden at broadcom.com>
> ---
>  arch/arm/boot/dts/bcm-cygnus.dtsi | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 3878793..1704dc0 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -351,9 +351,16 @@
>                                         <&pinctrl 142 10 1>;
>                 };
>
> +               ts_adc_syscon: ts_adc_syscon at 180a6000 {
> +                       compatible = "brcm,iproc-ts-adc-syscon","syscon";
> +                       reg = <0x180a6000 0xc30>;
> +               };
> +
>                 touchscreen: tsc at 180a6000 {
> -                       compatible = "brcm,iproc-touchscreen";
> -                       reg = <0x180a6000 0x40>;
> +                       compatible = "brcm,iproc-touchscreen-syscon";

Hi Rob,
In patchset V2 you had a comment as to have only "syscon" support,
Since having "syscon" only support breaks the dt backward compatibility
as the existing driver has support for "reg".  So in patchset V3 I have
not addressed this comment yet. Waiting for your opinion on whether
to proceed with "syscon" only support.

-Raveendra
> +                       #address-cells = <1>;
> +                       #size-cells = <1>;
> +                       ts_syscon = <&ts_adc_syscon>;
>                         clocks = <&asiu_clks BCM_CYGNUS_ASIU_ADC_CLK>;
>                         clock-names = "tsc_clk";
>                         interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
> --
> 1.9.1
>


From thomas.petazzoni at free-electrons.com  Mon Feb 22 00:10:55 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 22 Feb 2016 09:10:55 +0100
Subject: [PATCH] irqchip: irq-mvebu-odmi: new driver
In-Reply-To: <20160222025353.GD15973@rob-hp-laptop>
References: <1455522162-16425-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160222025353.GD15973@rob-hp-laptop>
Message-ID: <20160222091055.524c60a9@free-electrons.com>

Hello,

FWIW, you're replying to the v1 of this patch, while v2 and v3 have
already been posted, and v3 has already been merged by the irqchip
maintainers:

  http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=c27f29bbbf02168c9b1e8ba0fe7a8cb917e5a50f

On Sun, 21 Feb 2016 20:53:53 -0600, Rob Herring wrote:

> > +- compatible	       : The value here should contain "marvell,odmi-controller".
> 
> SoC specific compatible too please.

I can add that in a follow-up patch.

> > +- marvell,spi-base     : List of GIC base SPI interrupts, one for each
> > +                         ODMI frame.
> 
> Why not "interrupts" property?

This has already been discussed with Arnd in a more recent iteration of
the patch:

  http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409411.html
  http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409415.html
  http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409430.html

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From thomas.petazzoni at free-electrons.com  Mon Feb 22 00:14:23 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 22 Feb 2016 09:14:23 +0100
Subject: [PATCH 2/3] clk: mvebu: add AP806 core clock driver
In-Reply-To: <20160222025357.GE15973@rob-hp-laptop>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455521698-7905-3-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160222025357.GE15973@rob-hp-laptop>
Message-ID: <20160222091423.4756a579@free-electrons.com>

Dear Rob Herring,

On Sun, 21 Feb 2016 20:53:57 -0600, Rob Herring wrote:

> > +The Marvell MVEBU Armada 7K/8K SoCs contain a block called AP806,
> > +hosting the CPU and other core components of the CPU. This Device Tree
> > +binding allows to describe the core clocks of the AP806, whose
> > +frequencies are determined by reading the Sample-At-Reset (SAR)
> > +register.
> 
> What else is in the AP806?

Lots of things: CPU core, caches, GIC, XOR engines, UART, I2C
controller, etc.

> > +Clock consumers must specify the desired clock by having the clock ID
> > +in its "clocks" phandle cell.
> > +
> > +The following is a list of provided IDs and clock names for the core
> > +Armada AP806 clocks:
> > +
> > + 0 = DDR
> > + 1 = Ring
> > + 2 = CPU
> > +
> > +Required properties:
> > +- compatible: must be be one of the following:
> > +	"marvell,armada-ap806-core-clock"
> 
> I'd expect this to be a sub-node of a syscon block or just a single 
> clock provider for the full block. Hard to tell reviewing this without 
> context of what the full clock tree looks like. 

I indeed wondered about adding a syscon block. However, I don't have at
this point a full datasheet for the AP806, so it is hard to get a good
view of what the register set looks like to create a proper syscon. And
I don't have better informations about the full clock tree.

Such information will come later, and we can rework the drivers and DT
bindings accordingly. Those DT bindings cannot be stable, as the
platform is under heavy development and we'll probably discover some
issues down the road.

Right now, the only information I have about the AP806 clock tree are
about those core clocks and ring clocks.

> > +- reg: must be the register address of the Sample-At-Reset (SAR) register
> > +- #clock-cells: from common clock binding; shall be set to 1
> > +- clock-output-names: name of the output clocks
> > +
> > +Example:
> > +
> > +	coreclk: clk at 0x6F8204 {
> 
> Drop 0x and lowercase hex.
> 
> > +		compatible = "marvell,armada-ap806-core-clock";
> > +		reg = <0x6F8204 0x04>;
> 
> lowercase hex.

Sure, will fix.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From thomas.petazzoni at free-electrons.com  Mon Feb 22 00:15:23 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 22 Feb 2016 09:15:23 +0100
Subject: [PATCH 3/3] clk: mvebu: add AP806 ring clock driver
In-Reply-To: <20160222025401.GF15973@rob-hp-laptop>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455521698-7905-4-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160222025401.GF15973@rob-hp-laptop>
Message-ID: <20160222091523.59570303@free-electrons.com>

Dear Rob Herring,

On Sun, 21 Feb 2016 20:54:01 -0600, Rob Herring wrote:
> On Mon, Feb 15, 2016 at 08:34:58AM +0100, Thomas Petazzoni wrote:
> > This commit adds a new driver to handle the ring clocks found in the
> > AP806 HW block, which is the core block of all Armada 7K and 8K
> > Marvell 64-bits processors. Those ring clocks are derived from the
> > core ring clock handled by the AP806 core clock driver. The ring
> > clocks are used by various peripherals inside the AP806.
> > 
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> > ---
> >  .../clock/mvebu-armada-ap806-ring-clock.txt        | 32 +++++++++++
> 
> Combine this with the other patch. Similar comments as the other one.

What do you mean by "combine"? It certainly doesn't make sense to merge
the two patches: there is one patch per driver, so the DT binding
documentation comes together with the driver it corresponds to.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From draakje197 at gmail.com  Mon Feb 22 00:20:02 2016
From: draakje197 at gmail.com (Henry Paulissen)
Date: Mon, 22 Feb 2016 09:20:02 +0100
Subject: [PATCH v5] Fix sun7i pin assignment for IRQ's
Message-ID: <1456129208-11490-1-git-send-email-henry@nitronetworks.nl>

After testing IRQ pins we found some bugs in the pinctrl declaration.
Both PI* and PC* pins didn't work. PI* pins seemed to be connected
to the wrong mux and PC* pins waren't working at all.

Please note that the A20 soc manual is contradicting between version
and even within the same document for both the PI and PC pins.

Patch is based on testing with the hardware itself.

Signed-off-by: Henry Paulissen <henry at nitronetworks.nl>

---

Changes in v2:
    After some more testing we found irq on PI pins.
    they where on mux6 so this is included in my patch.

    Also included is a warning for PI17, this pin was not working
    on apritzel his bPI and he thinks it might be correlated to
    GIC and IRQ 29.

Changes in v3:
    Changed name from nickname to realname in email and SoB.

Changes in v4:
    Added closing parenthesis for the C pins.

Changes in v5:
    Added a more detailed description.
---
 drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c | 33 ++++++++++++++-----------------
 1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
index cf1ce0c..ca7b9a3 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
@@ -343,26 +343,22 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE4 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* CS0 */
-		  SUNXI_FUNCTION_IRQ(0x6, 12)),		/* EINT12 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* CS0 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 20),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE5 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* CLK */
-		  SUNXI_FUNCTION_IRQ(0x6, 13)),		/* EINT13 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* CLK */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 21),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE6 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* MOSI */
-		  SUNXI_FUNCTION_IRQ(0x6, 14)),		/* EINT14 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* MOSI */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 22),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE7 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* MISO */
-		  SUNXI_FUNCTION_IRQ(0x6, 15)),		/* EINT15 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* MISO */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 23),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
@@ -960,65 +956,66 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS0 */
 		  SUNXI_FUNCTION(0x3, "uart5"),		/* TX */
-		  SUNXI_FUNCTION_IRQ(0x5, 22)),		/* EINT22 */
+		  SUNXI_FUNCTION_IRQ(0x6, 22)),		/* EINT22 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 11),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CLK */
 		  SUNXI_FUNCTION(0x3, "uart5"),		/* RX */
-		  SUNXI_FUNCTION_IRQ(0x5, 23)),		/* EINT23 */
+		  SUNXI_FUNCTION_IRQ(0x6, 23)),		/* EINT23 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 12),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* MOSI */
 		  SUNXI_FUNCTION(0x3, "uart6"),		/* TX */
 		  SUNXI_FUNCTION(0x4, "clk_out_a"),	/* CLK_OUT_A */
-		  SUNXI_FUNCTION_IRQ(0x5, 24)),		/* EINT24 */
+		  SUNXI_FUNCTION_IRQ(0x6, 24)),		/* EINT24 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 13),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* MISO */
 		  SUNXI_FUNCTION(0x3, "uart6"),		/* RX */
 		  SUNXI_FUNCTION(0x4, "clk_out_b"),	/* CLK_OUT_B */
-		  SUNXI_FUNCTION_IRQ(0x5, 25)),		/* EINT25 */
+		  SUNXI_FUNCTION_IRQ(0x6, 25)),		/* EINT25 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 14),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS1 */
 		  SUNXI_FUNCTION(0x3, "ps2"),		/* SCK1 */
 		  SUNXI_FUNCTION(0x4, "timer4"),	/* TCLKIN0 */
-		  SUNXI_FUNCTION_IRQ(0x5, 26)),		/* EINT26 */
+		  SUNXI_FUNCTION_IRQ(0x6, 26)),		/* EINT26 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 15),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS1 */
 		  SUNXI_FUNCTION(0x3, "ps2"),		/* SDA1 */
 		  SUNXI_FUNCTION(0x4, "timer5"),	/* TCLKIN1 */
-		  SUNXI_FUNCTION_IRQ(0x5, 27)),		/* EINT27 */
+		  SUNXI_FUNCTION_IRQ(0x6, 27)),		/* EINT27 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 16),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS0 */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* RTS */
-		  SUNXI_FUNCTION_IRQ(0x5, 28)),		/* EINT28 */
+		  SUNXI_FUNCTION_IRQ(0x6, 28)),		/* EINT28 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 17),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CLK */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* CTS */
-		  SUNXI_FUNCTION_IRQ(0x5, 29)),		/* EINT29 */
+		  SUNXI_FUNCTION_IRQ(0x6, 29)),		/* EINT29 */
+		  /* EINT29 might not work - more testing needed */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 18),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* MOSI */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* TX */
-		  SUNXI_FUNCTION_IRQ(0x5, 30)),		/* EINT30 */
+		  SUNXI_FUNCTION_IRQ(0x6, 30)),		/* EINT30 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 19),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* MISO */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* RX */
-		  SUNXI_FUNCTION_IRQ(0x5, 31)),		/* EINT31 */
+		  SUNXI_FUNCTION_IRQ(0x6, 31)),		/* EINT31 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 20),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
-- 
2.5.0



From LW at KARO-electronics.de  Mon Feb 22 00:26:13 2016
From: LW at KARO-electronics.de (Lothar =?UTF-8?B?V2HDn21hbm4=?=)
Date: Mon, 22 Feb 2016 09:26:13 +0100
Subject: [PATCH V2 3/4] ARM: dts: imx6ul: Add GPMI nand controller support
In-Reply-To: <20160221112949.GB5387@panicking>
References: <1455963652-24618-1-git-send-email-michael@amarulasolutions.com>
 <1455963652-24618-4-git-send-email-michael@amarulasolutions.com>
 <CAOMZO5DTmG7Umt+H20r+tZi9zZhsK=eoPbHOBO3iwvM2GXXLgg@mail.gmail.com>
 <20160220172127.GC24064@panicking>
 <20160221112949.GB5387@panicking>
Message-ID: <20160222092613.3c32a4a0@ipc1.ka-ro>

Hi,

On Sun, 21 Feb 2016 12:29:53 +0100 Michael Trimarchi wrote:
> Add support for GPMI nand controller.
> 
> Signed-off-by: Michael Trimarchi <michael at amarulasolutions.com>
> ---
> Changes V2:
> 	- drop special IMXUL type because seems that is compatible
> 	  with IMX6Q
> 
>  arch/arm/boot/dts/imx6ul.dtsi | 33 +++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
> index f4daf97..1a486ac 100644
> --- a/arch/arm/boot/dts/imx6ul.dtsi
> +++ b/arch/arm/boot/dts/imx6ul.dtsi
> @@ -142,6 +142,39 @@
>  			reg = <0x00900000 0x20000>;
>  		};
>  
> +		dma_apbh: dma-apbh at 01804000 {
> +			compatible = "fsl,imx6ul-dma-apbh", "fsl,imx28-dma-apbh";
> +			reg = <0x01804000 0x2000>;
> +			interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> +			interrupt-names = "gpmi0", "gpmi1", "gpmi2", "gpmi3";
> +			#dma-cells = <1>;
> +			dma-channels = <4>;
> +			clocks = <&clks IMX6UL_CLK_APBHDMA>;
> +		};
> +
> +		gpmi: gpmi-nand at 01806000 {
> +			compatible = "fsl,imx6q-gpmi-nand";
>
You should still add an imx6ul specific compatible (likewise to the
dma_apbh).



Lothar Wa?mann


From linus.walleij at linaro.org  Mon Feb 22 00:31:02 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Feb 2016 09:31:02 +0100
Subject: [PATCH] ARM: ux500: fix ureachable iounmap()
Message-ID: <1456129862-3918-1-git-send-email-linus.walleij@linaro.org>

The code was executing a return with a pointer before reaching
iounmap().

Reported-by: David Binderman <dcb314 at hotmail.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ARM SoC folks: I have no other Ux500 patches queued, so can
you please apply this patch directly for-next somewhere,
thanks.
---
 arch/arm/mach-ux500/cpu-db8500.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
index a0ffaad1fb61..a557955472ea 100644
--- a/arch/arm/mach-ux500/cpu-db8500.c
+++ b/arch/arm/mach-ux500/cpu-db8500.c
@@ -76,17 +76,19 @@ static struct arm_pmu_platdata db8500_pmu_platdata = {
 static const char *db8500_read_soc_id(void)
 {
 	void __iomem *uid;
+	const char *retstr;
 
 	uid = ioremap(U8500_BB_UID_BASE, 0x20);
 	if (!uid)
 		return NULL;
 	/* Throw these device-specific numbers into the entropy pool */
 	add_device_randomness(uid, 0x14);
-	return kasprintf(GFP_KERNEL, "%08x%08x%08x%08x%08x",
+	retstr = kasprintf(GFP_KERNEL, "%08x%08x%08x%08x%08x",
 			 readl((u32 *)uid+0),
 			 readl((u32 *)uid+1), readl((u32 *)uid+2),
 			 readl((u32 *)uid+3), readl((u32 *)uid+4));
 	iounmap(uid);
+	return retstr;
 }
 
 static struct device * __init db8500_soc_device_init(void)
-- 
2.4.3



From linus.walleij at linaro.org  Mon Feb 22 00:33:26 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Feb 2016 09:33:26 +0100
Subject: [PATCH] ARM: Ux500: add synaptics RMI4 for Ux500 TVK DT
Message-ID: <1456130006-4169-1-git-send-email-linus.walleij@linaro.org>

This adds the Synaptics RMI4 touchscreen to the Ux500 TVK
user interface board. Tested on the U8500 HREFv60plus with
the TVK UIB.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ARM SoC maintainers: please apply this patch directly for-next
on some DT branch, I have no other Ux500 DT patches. These bindings
are ACKed by Rob Herring in another thread so I think it's pointless
to keep it out of tree.
---
 arch/arm/boot/dts/ste-href-tvk1281618.dtsi | 37 +++++++++++++++++++++++++++++-
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/ste-href-tvk1281618.dtsi b/arch/arm/boot/dts/ste-href-tvk1281618.dtsi
index b7b4211c5353..55f9d0cc90f3 100644
--- a/arch/arm/boot/dts/ste-href-tvk1281618.dtsi
+++ b/arch/arm/boot/dts/ste-href-tvk1281618.dtsi
@@ -37,7 +37,6 @@
 	};
 
 	soc {
-		/* Add Synaptics touch screen, TC35893 keypad etc here */
 		i2c at 80004000 {
 			tc35893 at 44 {
 				compatible = "toshiba,tc35893";
@@ -159,6 +158,33 @@
 				vddio-supply = <&db8500_vsmps2_reg>;
 			};
 		};
+
+		i2c at 80110000 {
+			synaptics at 4b {
+				/* Synaptics RMI4 TM1217 touchscreen */
+				compatible = "syna,rmi4-i2c";
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <0x4b>;
+				vdd-supply = <&ab8500_ldo_aux1_reg>;
+				vddio-supply = <&db8500_vsmps2_reg>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&synaptics_tvk_mode>;
+				interrupt-parent = <&gpio2>;
+				interrupts = <20 IRQ_TYPE_EDGE_FALLING>;
+
+				rmi-f01 at 1 {
+					reg = <0x1>;
+					syna,nosleep = <1>;
+				};
+				rmi-f11 at 11 {
+					reg = <0x11>;
+					touchscreen-inverted-x;
+					syna,sensor-type = <1>;
+				};
+			};
+		};
+
 		pinctrl {
 			/* Pull up this GPIO pin */
 			tc35893 {
@@ -212,6 +238,15 @@
 					};
 				};
 			};
+			synaptics {
+				synaptics_tvk_mode: synaptics_tvk {
+					/* Touchscreen uses GPIO 84 */
+					tvk_cfg1 {
+						pins = "GPIO84_C2";
+						ste,config = <&gpio_in_pu>;
+					};
+				};
+			};
 		};
 	};
 };
-- 
2.4.3



From thomas.petazzoni at free-electrons.com  Mon Feb 22 01:16:21 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Mon, 22 Feb 2016 10:16:21 +0100
Subject: [PATCH] dma: mv_xor_v2: new driver
In-Reply-To: <20160222032730.GU19598@localhost>
References: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160222032730.GU19598@localhost>
Message-ID: <20160222101621.4f03ef8b@free-electrons.com>

Hello Vinod,

On Mon, 22 Feb 2016 08:57:30 +0530, Vinod Koul wrote:
> On Mon, Feb 15, 2016 at 08:58:03AM +0100, Thomas Petazzoni wrote:
> > diff --git a/Documentation/devicetree/bindings/dma/mv-xor-v2.txt b/Documentation/devicetree/bindings/dma/mv-xor-v2.txt
> > new file mode 100644
> > index 0000000..0a03dcf
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/dma/mv-xor-v2.txt
> > @@ -0,0 +1,19 @@
> > +* Marvell XOR v2 engines
> > +
> > +Required properties:
> > +- compatible: Should be "marvell,mv-xor-v2"
> > +- reg: Should contain registers location and length (two sets)
> > +    the first set is the DMA registers
> > +    the second set is the global registers
> > +- msi-parent: Phandle to the MSI-capable interrupt controller used for
> > +  interrupts.
> > +
> > +Example:
> > +
> > +	xor0 at 400000 {
> > +		compatible = "marvell,mv-xor-v2";
> > +		reg = <0x400000 0x1000>,
> > +		      <0x410000 0x1000>;
> > +		msi-parent = <&gic_v2m0>;
> > +		dma-coherent;
> > +	};
> 
> This should be a separate patch :)

This is really a personal preference, and different maintainers have
different opinions on the matter. However, if your preference is to
have the DT binding documentation as a separate patch, then I'll split
it, no problem :)

> 
> > +/* DMA Engine Registers */
> > +#define DMA_DESQ_BALR_OFF	0x000
> > +#define DMA_DESQ_BAHR_OFF	0x004
> > +#define DMA_DESQ_SIZE_OFF	0x008
> > +#define DMA_DESQ_DONE_OFF	0x00C
> > +#define   DMA_DESQ_DONE_PENDING_MASK		0x7FFF
> > +#define   DMA_DESQ_DONE_PENDING_SHIFT		0
> > +#define   DMA_DESQ_DONE_READ_PTR_MASK		0x1FFF
> > +#define   DMA_DESQ_DONE_READ_PTR_SHIFT		16
> > +#define DMA_DESQ_ARATTR_OFF	0x010
> > +#define   DMA_DESQ_ATTR_CACHE_MASK		0x3F3F
> > +#define   DMA_DESQ_ATTR_OUTER_SHAREABLE		0x202
> > +#define   DMA_DESQ_ATTR_CACHEABLE		0x3C3C
> > +#define DMA_IMSG_CDAT_OFF	0x014
> > +#define DMA_IMSG_THRD_OFF	0x018
> > +#define   DMA_IMSG_THRD_MASK			0x7FFF
> > +#define   DMA_IMSG_THRD_SHIFT			0x0
> > +#define DMA_DESQ_AWATTR_OFF	0x01C
> > +  /* Same flags as DMA_DESQ_ARATTR_OFF */
> > +#define DMA_DESQ_ALLOC_OFF	0x04C
> > +#define   DMA_DESQ_ALLOC_WRPTR_MASK		0xFFFF
> > +#define   DMA_DESQ_ALLOC_WRPTR_SHIFT		16
> > +#define DMA_IMSG_BALR_OFF	0x050
> > +#define DMA_IMSG_BAHR_OFF	0x054
> > +#define DMA_DESQ_CTRL_OFF	0x100
> > +#define	  DMA_DESQ_CTRL_32B			1
> > +#define   DMA_DESQ_CTRL_128B			7
> > +#define DMA_DESQ_STOP_OFF	0x800
> > +#define DMA_DESQ_DEALLOC_OFF	0x804
> > +#define DMA_DESQ_ADD_OFF	0x808
> 
> Please namespace these and others. Something like MRVL_XOR_XXX or anyother
> patter you like would be fine...

The issue is that with such name-spacing, the names get really long,
and it's hard to stay with the 80 characters limit. But OK, I'll try to
see what I can do.

> > +/* descriptors queue size */
> > +#define MV_XOR_V2_MAX_DESC_NUM	1024
> 
> Is this hardware defined?

No, it is a software choice. The hardware supports up to 2^14
descriptors, i.e 16384, at least from my understanding of the datasheet.

> > +static void mv_xor_v2_set_data_buffers(struct mv_xor_v2_device *xor_dev,
> > +					struct mv_xor_v2_descriptor *desc,
> > +					dma_addr_t src, int index)
> > +{
> > +	int arr_index = ((index >> 1) * 3);
> > +
> > +	/*
> > +	 * fill the buffer's addresses to the descriptor
> > +	 * The format of the buffers address for 2 sequential buffers X and X+1:
> 
> space around + please.

ACK.

> > +	 *  First word: Buffer-DX-Address-Low[31:0]
> > +	 *  Second word:Buffer-DX+1-Address-Low[31:0]
> > +	 *  Third word: DX+1-Buffer-Address-High[47:32] [31:16]
> > +	 *		DX-Buffer-Address-High[47:32] [15:0]
> > +	 */
> > +	if ((index & 0x1) == 0) {
> > +		desc->data_buff_addr[arr_index] = lower_32_bits(src);
> > +
> > +		/* Clear lower 16-bits */
> > +		desc->data_buff_addr[arr_index + 2] &= ~0xFFFF;
> > +
> > +		/* Set them if we have a 64 bits DMA address */
> > +		if (IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT))
> > +			desc->data_buff_addr[arr_index + 2] |=
> > +				upper_32_bits(src) & 0xFFFF;
> 
> So why should it depend on how kernel is configured?

Because using upper_32_bits() on a 32-bits type seems wrong? You can do
a git grep for CONFIG_ARCH_DMA_ADDR_T_64BIT, and see that it is already
used in drivers/dma/sh/rcar-dmac.c, drivers/gpu/drm/tegra/dc.c or
drivers/iommu/tegra-smmu.c.

drivers/dma/sh/rcar-dmac.c uses it for exactly the same reason as me:
they need to know if dma_addr_t is 32 bits or 64 bits, and if it's 64
bits, then they need to take the upper 32 bits and feed them to some
register.

> > +/*
> > + * Return the next available index in the DESQ.
> > + */
> > +static inline int mv_xor_v2_get_desq_write_ptr(struct mv_xor_v2_device *xor_dev)
> 
> Pls wrap with 80 chars wherever it is reasonable

Sure.

> > +/*
> > + * Allocate resources for a channel
> > + */
> > +static int mv_xor_v2_alloc_chan_resources(struct dma_chan *chan)
> > +{
> > +	/* nothing to be done here */
> > +	return 0;
> > +}
> 
> No need for empty alloc
> 
> > +
> > +/*
> > + * Free resources of a channel
> > + */
> > +void mv_xor_v2_free_chan_resources(struct dma_chan *chan)
> > +{
> > +	/* nothing to be done here */
> > +}
> 
> and free as well :)

Ah, cool, less useless code, I like that! Will fix.

> > +static irqreturn_t mv_xor_v2_interrupt_handler(int irq, void *data)
> > +{
> > +	struct mv_xor_v2_device *xor_dev = data;
> > +
> > +	/*
> > +	 * Update IMSG threshold, to disable new IMSG interrupts until
> > +	 * end of the tasklet
> > +	 */
> > +	mv_xor_v2_set_imsg_thrd(xor_dev, MV_XOR_V2_MAX_DESC_NUM);
> 
> You don't want to check the source of interrupt?

To protect against what? An improper MSI message that ends up firing
this interrupt for now reason? But only kernel space stuff (or
privileged code in user-space) can write to the MSI triggering
registers, so we should be able to trust that such an improper MSI
message will not arrive.

That being said, I can add a read of the pending descriptors number,
and if it's 0, then bail out with IRQ_NONE. Is that what you were
thinking about?

> > +static dma_cookie_t
> > +mv_xor_v2_tx_submit(struct dma_async_tx_descriptor *tx)
> > +{
> > +	int desq_ptr;
> > +	void *dest_hw_desc;
> > +	dma_cookie_t cookie;
> > +	struct mv_xor_v2_sw_desc *sw_desc =
> > +		container_of(tx, struct mv_xor_v2_sw_desc, async_tx);
> > +	struct mv_xor_v2_device *xor_dev =
> > +		container_of(tx->chan, struct mv_xor_v2_device, dmachan);
> > +
> > +	dev_dbg(xor_dev->dmadev.dev,
> > +		"%s sw_desc %p: async_tx %p\n",
> > +		__func__, sw_desc, &sw_desc->async_tx);
> > +
> > +	/* assign coookie */
> > +	spin_lock_bh(&xor_dev->cookie_lock);
> > +	cookie = dma_cookie_assign(tx);
> > +	spin_unlock_bh(&xor_dev->cookie_lock);
> > +
> > +	/* lock enqueue DESCQ */
> > +	spin_lock_bh(&xor_dev->push_lock);
> 
> Why not a generic channel lock which is used in submit, issue_pending and
> tasklet. What is the reason for opting different locks?

Yeah, agreed. Until I get real performance data, it's probably overkill
to use multiple spinlocks here. I'll rework with one spinlock only.

> > +	/* get the next available slot in the DESQ */
> > +	desq_ptr = mv_xor_v2_get_desq_write_ptr(xor_dev);
> > +
> > +	/* copy the HW descriptor from the SW descriptor to the DESQ */
> > +	dest_hw_desc = ((void *)xor_dev->hw_desq_virt +
> 
> cast to and away from void are not required

Well in this case, it is actually needed, because xor_dev->hw_desq_virt
is a pointer to a struct mv_xor_v2_descriptor, but we want to do
byte-based arithmetic, and not sizeof(struct mv_xor_v2_descriptor)
based arithmetic. Though I admit it's a bit ugly, I'll try to see if we
can't simply use normal sizeof(struct mv_xor_v2_descriptor)
based arithmetic.

> 
> > +			(xor_dev->desc_size * desq_ptr));
> > +
> > +	memcpy(dest_hw_desc, &sw_desc->hw_desc, xor_dev->desc_size);
> > +
> > +	/* update the DMA Engine with the new descriptor */
> > +	mv_xor_v2_add_desc_to_desq(xor_dev, 1);
> > +
> > +	/* unlock enqueue DESCQ */
> > +	spin_unlock_bh(&xor_dev->push_lock);
> 
> and if IIUC, you are pushing this to HW as well, that is not quite right if
> thats the case. We need to do this in issue_pending

issue_pending is already starting the DMA engine, which will process
the descriptors that have been queued in ->tx_submit.

Of course, if the DMA engine is already running, then the descriptors
might be processed right after they are added in the queue in
->tx_submit().

We are using the same scheme in mv_xor.c (not to say that mv_xor.c
doesn't need to be fixed, but it explains why we're using this logic in
mv_xor_v2.c).

> > +static struct dma_async_tx_descriptor *
> > +mv_xor_v2_prep_dma_xor(struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
> > +		       unsigned int src_cnt, size_t len, unsigned long flags)
> > +{
> > +	struct mv_xor_v2_sw_desc	*sw_desc;
> > +	struct mv_xor_v2_descriptor	*hw_descriptor;
> > +	struct mv_xor_v2_device		*xor_dev;
> > +	int i;
> > +
> > +	BUG_ON(src_cnt > MV_XOR_V2_CMD_LINE_NUM_MAX_D_BUF || src_cnt < 1);
> 
> why BUG_ON, is the system unusable after this?

Well, the XOR engine cannot do XOR with 0 source buffers, or with more
than MV_XOR_V2_CMD_LINE_NUM_MAX_D_BUF.

But I see that I'm already setting max_xor in struct dma_device, so one
can assume that ->prep_dma_xor() will not be called with src_cnt == or
src_cnt > max_xor, so this BUG_ON can be removed.

> > +/*
> > + * poll for a transaction completion
> > + */
> > +static enum dma_status mv_xor_v2_tx_status(struct dma_chan *chan,
> > +		dma_cookie_t cookie, struct dma_tx_state *txstate)
> > +{
> > +	/* return the transaction status */
> > +	return dma_cookie_status(chan, cookie, txstate);
> 
> why not assign this as you status callback?

Right, will do.

> > +static void mv_xor_v2_issue_pending(struct dma_chan *chan)
> > +{
> > +	struct mv_xor_v2_device *xor_dev =
> > +		container_of(chan, struct mv_xor_v2_device, dmachan);
> > +
> > +	/* Activate the channel */
> > +	writel(0, xor_dev->dma_base + DMA_DESQ_STOP_OFF);
> 
> what if channel is already running?

It will continue to run. Datasheet says: "Reset this bit to enable the
XOR unit (DESQ). Set this bit to disable (or Stop) the XOR unit." So as
long as we write 0, the engine will continue processing descriptors.

> > +static void mv_xor_v2_tasklet(unsigned long data)
> > +{
> > +	struct mv_xor_v2_device *xor_dev = (struct mv_xor_v2_device *) data;
> > +	int pending_ptr, num_of_pending, i;
> > +	struct mv_xor_v2_descriptor *next_pending_hw_desc = NULL;
> > +	struct mv_xor_v2_sw_desc *next_pending_sw_desc = NULL;
> > +
> > +	dev_dbg(xor_dev->dmadev.dev, "%s %d\n", __func__, __LINE__);
> > +
> > +	/* get thepending descriptors parameters */
> 
> space after the pls

Absolutely.

> > +static struct platform_driver mv_xor_v2_driver = {
> > +	.probe		= mv_xor_v2_probe,
> > +	.remove		= mv_xor_v2_remove,
> > +	.driver		= {
> > +		.owner	= THIS_MODULE,
> 
> I dont think we need this

This was already fixed in v2:

  http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409404.html

Thanks for the review! There are a few questions from you in the above
discussion, I'll wait for your feedback to submit a v3 that includes
your suggested fixes.

Thanks again!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From nsekhar at ti.com  Mon Feb 22 01:36:55 2016
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 22 Feb 2016 15:06:55 +0530
Subject: [PATCH 1/5] ARM: davinci: devices-da8xx: Add dma_slave_map to edma
In-Reply-To: <1454416997-14230-2-git-send-email-peter.ujfalusi@ti.com>
References: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>
 <1454416997-14230-2-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <56CAD6B7.2030706@ti.com>

On Tuesday 02 February 2016 06:13 PM, Peter Ujfalusi wrote:

> +static const struct dma_slave_map da850_edma1_map[] = {
> +	{ "da830-mmc.1", "rx", EDMA_FILTER_PARAM(0, 28) },
> +	{ "da830-mmc.1", "tx", EDMA_FILTER_PARAM(0, 29) },

This should be EDMA_FILTER_PARAM(1, 29) (and similar for rx). No need to
resend though, I will fix while applying.

Regards,
Sekhar


From andre.przywara at arm.com  Mon Feb 22 01:38:53 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 22 Feb 2016 09:38:53 +0000
Subject: [PATCH] clk: sunxi: allow PLL6 clock to be reused
In-Reply-To: <CAGb2v66Fkvpqay+pNYjN1KP_KSUmv-du+PVSsyeuK+Y7bzEt+g@mail.gmail.com>
References: <1456105198-25295-1-git-send-email-andre.przywara@arm.com>
 <CAGb2v66Fkvpqay+pNYjN1KP_KSUmv-du+PVSsyeuK+Y7bzEt+g@mail.gmail.com>
Message-ID: <56CAD72D.7050102@arm.com>

Hi Chen-Yu,

On 22/02/16 08:08, Chen-Yu Tsai wrote:
> On Sun, Feb 21, 2016 at 5:39 PM, Andre Przywara <andre.przywara at arm.com> wrote:
>> Currently we hard-code the base name for the PLL6 clock for both the
>> sun4i and sun6i variants in the driver (pll6 and pll6x2, respectively).
>> This unfortunately denies reusing this clock for the H3 and A64 PLL8
>> clock, which is the same otherwise.
>> Remove the hard-coded name in the source code and replace it with an
>> appropriate index into the clock-output-names array in the DT.
>> This is compatible with all current device trees, since they all carry
>> the hard-coded base name in there.
>>
>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>> ---
>> Salut Maxime,
>>
>> does that patch make sense?
>> It fixes the re-usability problem while still keeping compatibility
>> with existing DTs and also is pretty small.
>> If you agree with this, I'll send out a v3 of the A64 series including
>> this patch and the H3 PLL8 enablement later.
>> I tested this on my BananaPi, the clk_summary output was identical
>> with and without this patch.
> 
> This look OK to me, except one minor detail below.
> 
>> Cheers,
>> Andre.
>>
>>  drivers/clk/sunxi/clk-factors.c | 3 ++-
>>  drivers/clk/sunxi/clk-factors.h | 1 +
>>  drivers/clk/sunxi/clk-sunxi.c   | 4 ++--
>>  3 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/clk/sunxi/clk-factors.c b/drivers/clk/sunxi/clk-factors.c
>> index ddefe96..7daf01d 100644
>> --- a/drivers/clk/sunxi/clk-factors.c
>> +++ b/drivers/clk/sunxi/clk-factors.c
>> @@ -202,7 +202,8 @@ struct clk *sunxi_factors_register(struct device_node *node,
>>         if (data->name)
>>                 clk_name = data->name;
>>         else
>> -               of_property_read_string(node, "clock-output-names", &clk_name);
>> +               of_property_read_string_index(node, "clock-output-names",
>> +                                             data->name_idx, &clk_name);
>>
>>         factors = kzalloc(sizeof(struct clk_factors), GFP_KERNEL);
>>         if (!factors)
>> diff --git a/drivers/clk/sunxi/clk-factors.h b/drivers/clk/sunxi/clk-factors.h
>> index 1e63c5b..3a7da86 100644
>> --- a/drivers/clk/sunxi/clk-factors.h
>> +++ b/drivers/clk/sunxi/clk-factors.h
>> @@ -36,6 +36,7 @@ struct factors_data {
>>         void (*getter)(struct factors_request *req);
>>         void (*recalc)(struct factors_request *req);
>>         const char *name;
>> +       int name_idx;
> 
> I would drop the .name field. It was a bad workaround
> due to limitations of the factors clk code at the time
> by me. We really shouldn't hard-code the name if we want
> to reuse the driver.

I know what you mean (my first thought, too) and I totally agree, but we
need it still for PLL5, which does not carry the original name in the DT
output names.
So at least this workaround here does not work, I guess we have to come
up with something different - which would be a different patch.
I can take a look into this later.

Thanks,
Andre.

>>  };
>>
>>  struct clk_factors {
>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>> index 99f60ef..53f5927 100644
>> --- a/drivers/clk/sunxi/clk-sunxi.c
>> +++ b/drivers/clk/sunxi/clk-sunxi.c
>> @@ -530,14 +530,14 @@ static const struct factors_data sun4i_pll6_data __initconst = {
>>         .enable = 31,
>>         .table = &sun4i_pll5_config,
>>         .getter = sun4i_get_pll5_factors,
>> -       .name = "pll6",
>> +       .name_idx = 2,
>>  };
>>
>>  static const struct factors_data sun6i_a31_pll6_data __initconst = {
>>         .enable = 31,
>>         .table = &sun6i_a31_pll6_config,
>>         .getter = sun6i_a31_get_pll6_factors,
>> -       .name = "pll6x2",
>> +       .name_idx = 1,
>>  };
>>
>>  static const struct factors_data sun5i_a13_ahb_data __initconst = {
>> --
>> 1.8.4
>>
> 


From zhaoshenglong at huawei.com  Mon Feb 22 01:37:50 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:50 +0800
Subject: [PATCH v12 14/21] KVM: ARM64: Add helper to handle PMCR register bits
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-15-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

According to ARMv8 spec, when writing 1 to PMCR.E, all counters are
enabled by PMCNTENSET, while writing 0 to PMCR.E, all counters are
disabled. When writing 1 to PMCR.P, reset all event counters, not
including PMCCNTR, to zero. When writing 1 to PMCR.C, reset PMCCNTR to
zero.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/sys_regs.c |  1 +
 include/kvm/arm_pmu.h     |  2 ++
 virt/kvm/arm/pmu.c        | 34 ++++++++++++++++++++++++++++++++++
 3 files changed, 37 insertions(+)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index f31023b..f1866c3 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -467,6 +467,7 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 		val &= ~ARMV8_PMU_PMCR_MASK;
 		val |= p->regval & ARMV8_PMU_PMCR_MASK;
 		vcpu_sys_reg(vcpu, PMCR_EL0) = val;
+		kvm_pmu_handle_pmcr(vcpu, val);
 	} else {
 		/* PMCR.P & PMCR.C are RAZ */
 		val = vcpu_sys_reg(vcpu, PMCR_EL0)
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 348c4c9..8bc92d1 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -45,6 +45,7 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 #else
@@ -67,6 +68,7 @@ static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 9fc775e..cda869c 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -210,6 +210,40 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
 	}
 }
 
+/**
+ * kvm_pmu_handle_pmcr - handle PMCR register
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCR register
+ */
+void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val)
+{
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_pmc *pmc;
+	u64 mask;
+	int i;
+
+	mask = kvm_pmu_valid_counter_mask(vcpu);
+	if (val & ARMV8_PMU_PMCR_E) {
+		kvm_pmu_enable_counter(vcpu,
+				vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & mask);
+	} else {
+		kvm_pmu_disable_counter(vcpu, mask);
+	}
+
+	if (val & ARMV8_PMU_PMCR_C)
+		kvm_pmu_set_counter_value(vcpu, ARMV8_PMU_CYCLE_IDX, 0);
+
+	if (val & ARMV8_PMU_PMCR_P) {
+		for (i = 0; i < ARMV8_PMU_CYCLE_IDX; i++)
+			kvm_pmu_set_counter_value(vcpu, i, 0);
+	}
+
+	if (val & ARMV8_PMU_PMCR_LC) {
+		pmc = &pmu->pmc[ARMV8_PMU_CYCLE_IDX];
+		pmc->bitmask = 0xffffffffffffffffUL;
+	}
+}
+
 static bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu, u64 select_idx)
 {
 	return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E) &&
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:39 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:39 +0800
Subject: [PATCH v12 03/21] KVM: ARM64: Add offset defines for PMU registers
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-4-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

We are about to trap and emulate accesses to each PMU register
individually. This adds the context offsets for the AArch64 PMU
registers.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/kvm_host.h | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 6f0241f..6bab7fb 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -115,6 +115,21 @@ enum vcpu_sysreg {
 	MDSCR_EL1,	/* Monitor Debug System Control Register */
 	MDCCINT_EL1,	/* Monitor Debug Comms Channel Interrupt Enable Reg */
 
+	/* Performance Monitors Registers */
+	PMCR_EL0,	/* Control Register */
+	PMOVSSET_EL0,	/* Overflow Flag Status Set Register */
+	PMSELR_EL0,	/* Event Counter Selection Register */
+	PMEVCNTR0_EL0,	/* Event Counter Register (0-30) */
+	PMEVCNTR30_EL0 = PMEVCNTR0_EL0 + 30,
+	PMCCNTR_EL0,	/* Cycle Counter Register */
+	PMEVTYPER0_EL0,	/* Event Type Register (0-30) */
+	PMEVTYPER30_EL0 = PMEVTYPER0_EL0 + 30,
+	PMCCFILTR_EL0,	/* Cycle Count Filter Register */
+	PMCNTENSET_EL0,	/* Count Enable Set Register */
+	PMINTENSET_EL1,	/* Interrupt Enable Set Register */
+	PMUSERENR_EL0,	/* User Enable Register */
+	PMSWINC_EL0,	/* Software Increment Register */
+
 	/* 32bit specific registers. Keep them at the end of the range */
 	DACR32_EL2,	/* Domain Access Control Register */
 	IFSR32_EL2,	/* Instruction Fault Status Register */
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:55 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:55 +0800
Subject: [PATCH v12 19/21] KVM: ARM64: Add a new feature bit for PMUv3
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-20-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

To support guest PMUv3, use one bit of the VCPU INIT feature array.
Initialize the PMU when initialzing the vcpu with that bit and PMU
overflow interrupt set.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Peter Maydell <peter.maydell at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 Documentation/virtual/kvm/api.txt |  2 ++
 arch/arm64/include/asm/kvm_host.h |  2 +-
 arch/arm64/include/uapi/asm/kvm.h |  1 +
 arch/arm64/kvm/reset.c            |  3 +++
 include/kvm/arm_pmu.h             |  2 ++
 include/uapi/linux/kvm.h          |  1 +
 virt/kvm/arm/pmu.c                | 10 ++++++++++
 7 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 07e4cdf..9684f8d 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2577,6 +2577,8 @@ Possible features:
 	  Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
 	- KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 for the CPU.
 	  Depends on KVM_CAP_ARM_PSCI_0_2.
+	- KVM_ARM_VCPU_PMU_V3: Emulate PMUv3 for the CPU.
+	  Depends on KVM_CAP_ARM_PMU_V3.
 
 
 4.83 KVM_ARM_PREFERRED_TARGET
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 6bab7fb..cb220b7 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -40,7 +40,7 @@
 
 #define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
 
-#define KVM_VCPU_MAX_FEATURES 3
+#define KVM_VCPU_MAX_FEATURES 4
 
 int __attribute_const__ kvm_target_cpu(void);
 int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 2d4ca4b..6aedbe3 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -94,6 +94,7 @@ struct kvm_regs {
 #define KVM_ARM_VCPU_POWER_OFF		0 /* CPU is started in OFF state */
 #define KVM_ARM_VCPU_EL1_32BIT		1 /* CPU running a 32bit VM */
 #define KVM_ARM_VCPU_PSCI_0_2		2 /* CPU uses PSCI v0.2 */
+#define KVM_ARM_VCPU_PMU_V3		3 /* Support guest PMUv3 */
 
 struct kvm_vcpu_init {
 	__u32 target;
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index dfbce78..cf4f28a 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
 	case KVM_CAP_GUEST_DEBUG_HW_WPS:
 		r = get_num_wrps();
 		break;
+	case KVM_CAP_ARM_PMU_V3:
+		r = kvm_arm_support_pmu_v3();
+		break;
 	case KVM_CAP_SET_GUEST_DEBUG:
 		r = 1;
 		break;
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 9cebf03..c7595d6 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -51,6 +51,7 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
+bool kvm_arm_support_pmu_v3(void);
 #else
 struct kvm_pmu {
 };
@@ -77,6 +78,7 @@ static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
+static inline bool kvm_arm_support_pmu_v3(void) { return false; }
 #endif
 
 #endif
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 9da9051..dc16d30 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -850,6 +850,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_IOEVENTFD_ANY_LENGTH 122
 #define KVM_CAP_HYPERV_SYNIC 123
 #define KVM_CAP_S390_RI 124
+#define KVM_CAP_ARM_PMU_V3 125
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 0427af8..d5b6eb4 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -383,3 +383,13 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 
 	pmc->perf_event = event;
 }
+
+bool kvm_arm_support_pmu_v3(void)
+{
+	/*
+	 * Check if HW_PERF_EVENTS are supported by checking the number of
+	 * hardware performance counters. This could ensure the presence of
+	 * a physical PMU and CONFIG_PERF_EVENT is selected.
+	 */
+	return (perf_num_counters() > 0);
+}
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:47 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:47 +0800
Subject: [PATCH v12 11/21] KVM: ARM64: Add access handler for PMINTENSET and
 PMINTENCLR register
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-12-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Since the reset value of PMINTENSET and PMINTENCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMINTENSET or PMINTENCLR register.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/kvm/sys_regs.c | 32 ++++++++++++++++++++++++++++----
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index d7c7ed4a..4778275 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -626,6 +626,30 @@ static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			   const struct sys_reg_desc *r)
+{
+	u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write) {
+		u64 val = p->regval & mask;
+
+		if (r->Op2 & 0x1)
+			/* accessing PMINTENSET_EL1 */
+			vcpu_sys_reg(vcpu, PMINTENSET_EL1) |= val;
+		else
+			/* accessing PMINTENCLR_EL1 */
+			vcpu_sys_reg(vcpu, PMINTENSET_EL1) &= ~val;
+	} else {
+		p->regval = vcpu_sys_reg(vcpu, PMINTENSET_EL1) & mask;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -784,10 +808,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 
 	/* PMINTENSET_EL1 */
 	{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b001),
-	  trap_raz_wi },
+	  access_pminten, reset_unknown, PMINTENSET_EL1 },
 	/* PMINTENCLR_EL1 */
 	{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b010),
-	  trap_raz_wi },
+	  access_pminten, NULL, PMINTENSET_EL1 },
 
 	/* MAIR_EL1 */
 	{ Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0010), Op2(0b000),
@@ -1182,8 +1206,8 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
+	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
 
 	{ Op1( 0), CRn(10), CRm( 2), Op2( 0), access_vm_reg, NULL, c10_PRRR },
 	{ Op1( 0), CRn(10), CRm( 2), Op2( 1), access_vm_reg, NULL, c10_NMRR },
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:56 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:56 +0800
Subject: [PATCH v12 20/21] KVM: ARM: Introduce per-vcpu kvm device controls
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-21-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

In some cases it needs to get/set attributes specific to a vcpu and so
needs something else than ONE_REG.

Let's copy the KVM_DEVICE approach, and define the respective ioctls
for the vcpu file descriptor.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
Acked-by: Peter Maydell <peter.maydell at linaro.org>
---
 Documentation/virtual/kvm/api.txt          | 10 +++---
 Documentation/virtual/kvm/devices/vcpu.txt |  8 +++++
 arch/arm/kvm/arm.c                         | 55 ++++++++++++++++++++++++++++++
 arch/arm64/kvm/reset.c                     |  1 +
 include/uapi/linux/kvm.h                   |  1 +
 5 files changed, 71 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/virtual/kvm/devices/vcpu.txt

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 9684f8d..cb2ef0b 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2507,8 +2507,9 @@ struct kvm_create_device {
 
 4.80 KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR
 
-Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device
-Type: device ioctl, vm ioctl
+Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device,
+  KVM_CAP_VCPU_ATTRIBUTES for vcpu device
+Type: device ioctl, vm ioctl, vcpu ioctl
 Parameters: struct kvm_device_attr
 Returns: 0 on success, -1 on error
 Errors:
@@ -2533,8 +2534,9 @@ struct kvm_device_attr {
 
 4.81 KVM_HAS_DEVICE_ATTR
 
-Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device
-Type: device ioctl, vm ioctl
+Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device,
+  KVM_CAP_VCPU_ATTRIBUTES for vcpu device
+Type: device ioctl, vm ioctl, vcpu ioctl
 Parameters: struct kvm_device_attr
 Returns: 0 on success, -1 on error
 Errors:
diff --git a/Documentation/virtual/kvm/devices/vcpu.txt b/Documentation/virtual/kvm/devices/vcpu.txt
new file mode 100644
index 0000000..3cc59c5
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/vcpu.txt
@@ -0,0 +1,8 @@
+Generic vcpu interface
+====================================
+
+The virtual cpu "device" also accepts the ioctls KVM_SET_DEVICE_ATTR,
+KVM_GET_DEVICE_ATTR, and KVM_HAS_DEVICE_ATTR. The interface uses the same struct
+kvm_device_attr as other devices, but targets VCPU-wide settings and controls.
+
+The groups and attributes per virtual cpu, if any, are architecture specific.
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index d2c2cc3..34d7395 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -826,11 +826,51 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu,
 	return 0;
 }
 
+static int kvm_arm_vcpu_set_attr(struct kvm_vcpu *vcpu,
+				 struct kvm_device_attr *attr)
+{
+	int ret = -ENXIO;
+
+	switch (attr->group) {
+	default:
+		break;
+	}
+
+	return ret;
+}
+
+static int kvm_arm_vcpu_get_attr(struct kvm_vcpu *vcpu,
+				 struct kvm_device_attr *attr)
+{
+	int ret = -ENXIO;
+
+	switch (attr->group) {
+	default:
+		break;
+	}
+
+	return ret;
+}
+
+static int kvm_arm_vcpu_has_attr(struct kvm_vcpu *vcpu,
+				 struct kvm_device_attr *attr)
+{
+	int ret = -ENXIO;
+
+	switch (attr->group) {
+	default:
+		break;
+	}
+
+	return ret;
+}
+
 long kvm_arch_vcpu_ioctl(struct file *filp,
 			 unsigned int ioctl, unsigned long arg)
 {
 	struct kvm_vcpu *vcpu = filp->private_data;
 	void __user *argp = (void __user *)arg;
+	struct kvm_device_attr attr;
 
 	switch (ioctl) {
 	case KVM_ARM_VCPU_INIT: {
@@ -873,6 +913,21 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
 			return -E2BIG;
 		return kvm_arm_copy_reg_indices(vcpu, user_list->reg);
 	}
+	case KVM_SET_DEVICE_ATTR: {
+		if (copy_from_user(&attr, argp, sizeof(attr)))
+			return -EFAULT;
+		return kvm_arm_vcpu_set_attr(vcpu, &attr);
+	}
+	case KVM_GET_DEVICE_ATTR: {
+		if (copy_from_user(&attr, argp, sizeof(attr)))
+			return -EFAULT;
+		return kvm_arm_vcpu_get_attr(vcpu, &attr);
+	}
+	case KVM_HAS_DEVICE_ATTR: {
+		if (copy_from_user(&attr, argp, sizeof(attr)))
+			return -EFAULT;
+		return kvm_arm_vcpu_has_attr(vcpu, &attr);
+	}
 	default:
 		return -EINVAL;
 	}
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index cf4f28a..9677bf0 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -81,6 +81,7 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
 		r = kvm_arm_support_pmu_v3();
 		break;
 	case KVM_CAP_SET_GUEST_DEBUG:
+	case KVM_CAP_VCPU_ATTRIBUTES:
 		r = 1;
 		break;
 	default:
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index dc16d30..50f44a2 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -851,6 +851,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_HYPERV_SYNIC 123
 #define KVM_CAP_S390_RI 124
 #define KVM_CAP_ARM_PMU_V3 125
+#define KVM_CAP_VCPU_ATTRIBUTES 126
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:40 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:40 +0800
Subject: [PATCH v12 04/21] KVM: ARM64: Add access handler for PMCR register
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-5-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Add reset handler which gets host value of PMCR_EL0 and make writable
bits architecturally UNKNOWN except PMCR.E which is zero. Add an access
handler for PMCR.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/kvm/sys_regs.c | 42 ++++++++++++++++++++++++++++++++++++++++--
 include/kvm/arm_pmu.h     |  4 ++++
 2 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index eec3598..7ee4d5e 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -34,6 +34,7 @@
 #include <asm/kvm_emulate.h>
 #include <asm/kvm_host.h>
 #include <asm/kvm_mmu.h>
+#include <asm/perf_event.h>
 
 #include <trace/events/kvm.h>
 
@@ -439,6 +440,43 @@ static void reset_mpidr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
 	vcpu_sys_reg(vcpu, MPIDR_EL1) = (1ULL << 31) | mpidr;
 }
 
+static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
+{
+	u64 pmcr, val;
+
+	asm volatile("mrs %0, pmcr_el0\n" : "=r" (pmcr));
+	/* Writable bits of PMCR_EL0 (ARMV8_PMU_PMCR_MASK) is reset to UNKNOWN
+	 * except PMCR.E resetting to zero.
+	 */
+	val = ((pmcr & ~ARMV8_PMU_PMCR_MASK)
+	       | (ARMV8_PMU_PMCR_MASK & 0xdecafbad)) & (~ARMV8_PMU_PMCR_E);
+	vcpu_sys_reg(vcpu, PMCR_EL0) = val;
+}
+
+static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			const struct sys_reg_desc *r)
+{
+	u64 val;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write) {
+		/* Only update writeable bits of PMCR */
+		val = vcpu_sys_reg(vcpu, PMCR_EL0);
+		val &= ~ARMV8_PMU_PMCR_MASK;
+		val |= p->regval & ARMV8_PMU_PMCR_MASK;
+		vcpu_sys_reg(vcpu, PMCR_EL0) = val;
+	} else {
+		/* PMCR.P & PMCR.C are RAZ */
+		val = vcpu_sys_reg(vcpu, PMCR_EL0)
+		      & ~(ARMV8_PMU_PMCR_P | ARMV8_PMU_PMCR_C);
+		p->regval = val;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -623,7 +661,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 
 	/* PMCR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b000),
-	  trap_raz_wi },
+	  access_pmcr, reset_pmcr, },
 	/* PMCNTENSET_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
 	  trap_raz_wi },
@@ -885,7 +923,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 7), CRm(14), Op2( 2), access_dcsw },
 
 	/* PMU */
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 0), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 3c2fd56..8157fe5 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -34,9 +34,13 @@ struct kvm_pmu {
 	struct kvm_pmc pmc[ARMV8_PMU_MAX_COUNTERS];
 	bool ready;
 };
+
+#define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
 #else
 struct kvm_pmu {
 };
+
+#define kvm_arm_pmu_v3_ready(v)		(false)
 #endif
 
 #endif
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:49 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:49 +0800
Subject: [PATCH v12 13/21] KVM: ARM64: Add access handler for PMSWINC register
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-14-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Add access handler which emulates writing and reading PMSWINC
register and add support for creating software increment event.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/perf_event.h |  2 ++
 arch/arm64/kvm/sys_regs.c           | 20 +++++++++++++++++++-
 include/kvm/arm_pmu.h               |  2 ++
 virt/kvm/arm/pmu.c                  | 34 ++++++++++++++++++++++++++++++++++
 4 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
index 867140d..c3f5937 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -47,6 +47,8 @@
 #define	ARMV8_PMU_EVTYPE_MASK	0xc80003ff	/* Mask for writable bits */
 #define	ARMV8_PMU_EVTYPE_EVENT	0x3ff		/* Mask for EVENT bits */
 
+#define ARMV8_PMU_EVTYPE_EVENT_SW_INCR	0	/* Software increment event */
+
 /*
  * Event filters for PMUv3
  */
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 7769b19..f31023b 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -672,6 +672,23 @@ static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			   const struct sys_reg_desc *r)
+{
+	u64 mask;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write) {
+		mask = kvm_pmu_valid_counter_mask(vcpu);
+		kvm_pmu_software_increment(vcpu, p->regval & mask);
+		return true;
+	}
+
+	return false;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -882,7 +899,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmovs, NULL, PMOVSSET_EL0 },
 	/* PMSWINC_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
-	  trap_raz_wi },
+	  access_pmswinc, reset_unknown, PMSWINC_EL0 },
 	/* PMSELR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
 	  access_pmselr, reset_unknown, PMSELR_EL0 },
@@ -1221,6 +1238,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 4), access_pmswinc },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 60061da..348c4c9 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -44,6 +44,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 #else
@@ -65,6 +66,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 0232861..9fc775e 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -180,6 +180,36 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
 		kvm_vcpu_kick(vcpu);
 }
 
+/**
+ * kvm_pmu_software_increment - do software increment
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMSWINC register
+ */
+void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
+{
+	int i;
+	u64 type, enable, reg;
+
+	if (val == 0)
+		return;
+
+	enable = vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
+	for (i = 0; i < ARMV8_PMU_CYCLE_IDX; i++) {
+		if (!(val & BIT(i)))
+			continue;
+		type = vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i)
+		       & ARMV8_PMU_EVTYPE_EVENT;
+		if ((type == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
+		    && (enable & BIT(i))) {
+			reg = vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
+			reg = lower_32_bits(reg);
+			vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = reg;
+			if (!reg)
+				kvm_pmu_overflow_set(vcpu, BIT(i));
+		}
+	}
+}
+
 static bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu, u64 select_idx)
 {
 	return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E) &&
@@ -208,6 +238,10 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 	kvm_pmu_stop_counter(vcpu, pmc);
 	eventsel = data & ARMV8_PMU_EVTYPE_EVENT;
 
+	/* Software increment event does't need to be backed by a perf event */
+	if (eventsel == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
+		return;
+
 	memset(&attr, 0, sizeof(struct perf_event_attr));
 	attr.type = PERF_TYPE_RAW;
 	attr.size = sizeof(attr);
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:48 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:48 +0800
Subject: [PATCH v12 12/21] KVM: ARM64: Add access handler for PMOVSSET and
 PMOVSCLR register
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-13-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Since the reset value of PMOVSSET and PMOVSCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMOVSSET or PMOVSCLR register.

When writing non-zero value to PMOVSSET, the counter and its interrupt
is enabled, kick this vcpu to sync PMU interrupt.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/kvm/sys_regs.c | 29 ++++++++++++++++++++++++++---
 include/kvm/arm_pmu.h     |  2 ++
 virt/kvm/arm/pmu.c        | 31 +++++++++++++++++++++++++++++++
 3 files changed, 59 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 4778275..7769b19 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -650,6 +650,28 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			 const struct sys_reg_desc *r)
+{
+	u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write) {
+		if (r->CRm & 0x2)
+			/* accessing PMOVSSET_EL0 */
+			kvm_pmu_overflow_set(vcpu, p->regval & mask);
+		else
+			/* accessing PMOVSCLR_EL0 */
+			vcpu_sys_reg(vcpu, PMOVSSET_EL0) &= ~(p->regval & mask);
+	} else {
+		p->regval = vcpu_sys_reg(vcpu, PMOVSSET_EL0) & mask;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -857,7 +879,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmcnten, NULL, PMCNTENSET_EL0 },
 	/* PMOVSCLR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
-	  trap_raz_wi },
+	  access_pmovs, NULL, PMOVSSET_EL0 },
 	/* PMSWINC_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
 	  trap_raz_wi },
@@ -884,7 +906,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  trap_raz_wi },
 	/* PMOVSSET_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
-	  trap_raz_wi },
+	  access_pmovs, reset_unknown, PMOVSSET_EL0 },
 
 	/* TPIDR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b010),
@@ -1198,7 +1220,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
@@ -1208,6 +1230,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
+	{ Op1( 0), CRn( 9), CRm(14), Op2( 3), access_pmovs },
 
 	{ Op1( 0), CRn(10), CRm( 2), Op2( 0), access_vm_reg, NULL, c10_PRRR },
 	{ Op1( 0), CRn(10), CRm( 2), Op2( 1), access_vm_reg, NULL, c10_NMRR },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index c5737797..60061da 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -43,6 +43,7 @@ void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 #else
@@ -63,6 +64,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 }
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 591a11d..0232861 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -149,6 +149,37 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
 	}
 }
 
+static u64 kvm_pmu_overflow_status(struct kvm_vcpu *vcpu)
+{
+	u64 reg = 0;
+
+	if ((vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E))
+		reg = vcpu_sys_reg(vcpu, PMOVSSET_EL0);
+		reg &= vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
+		reg &= vcpu_sys_reg(vcpu, PMINTENSET_EL1);
+		reg &= kvm_pmu_valid_counter_mask(vcpu);
+
+	return reg;
+}
+
+/**
+ * kvm_pmu_overflow_set - set PMU overflow interrupt
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMOVSSET register
+ */
+void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
+{
+	u64 reg;
+
+	if (val == 0)
+		return;
+
+	vcpu_sys_reg(vcpu, PMOVSSET_EL0) |= val;
+	reg = kvm_pmu_overflow_status(vcpu);
+	if (reg != 0)
+		kvm_vcpu_kick(vcpu);
+}
+
 static bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu, u64 select_idx)
 {
 	return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E) &&
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:53 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:53 +0800
Subject: [PATCH v12 17/21] KVM: ARM64: Reset PMU state when resetting vcpu
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-18-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When resetting vcpu, it needs to reset the PMU state to initial status.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/kvm/reset.c |  3 +++
 include/kvm/arm_pmu.h  |  2 ++
 virt/kvm/arm/pmu.c     | 17 +++++++++++++++++
 3 files changed, 22 insertions(+)

diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index f34745c..dfbce78 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -120,6 +120,9 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 	/* Reset system registers */
 	kvm_reset_sys_regs(vcpu);
 
+	/* Reset PMU */
+	kvm_pmu_vcpu_reset(vcpu);
+
 	/* Reset timer */
 	return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
 }
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index cf68f9a..46b773e 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -41,6 +41,7 @@ struct kvm_pmu {
 u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
 void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
+void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
@@ -65,6 +66,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 {
 	return 0;
 }
+static inline void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu) {}
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 6ac52ce..92fff9a 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -84,6 +84,23 @@ static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
 	}
 }
 
+/**
+ * kvm_pmu_vcpu_reset - reset pmu state for cpu
+ * @vcpu: The vcpu pointer
+ *
+ */
+void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu)
+{
+	int i;
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+	for (i = 0; i < ARMV8_PMU_MAX_COUNTERS; i++) {
+		kvm_pmu_stop_counter(vcpu, &pmu->pmc[i]);
+		pmu->pmc[i].idx = i;
+		pmu->pmc[i].bitmask = 0xffffffffUL;
+	}
+}
+
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 {
 	u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMU_PMCR_N_SHIFT;
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:36 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:36 +0800
Subject: [PATCH v12 00/21] KVM: ARM64: Add guest PMU support
Message-ID: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

This patchset adds guest PMU support for KVM on ARM64. It takes
trap-and-emulate approach. When guest wants to monitor one event, it
will be trapped by KVM and KVM will call perf_event API to create a perf
event and call relevant perf_event APIs to get the count value of event.

Use perf to test this patchset in guest. When using "perf list", it
shows the list of the hardware events and hardware cache events perf
supports. Then use "perf stat -e EVENT" to monitor some event. For
example, use "perf stat -e cycles" to count cpu cycles and
"perf stat -e cache-misses" to count cache misses.

Below are the outputs of "perf stat -r 5 sleep 5" when running in host
and guest.

Host:
 Performance counter stats for 'sleep 5' (5 runs):

          0.529248      task-clock (msec)         #    0.000 CPUs utilized            ( +-  1.65% )
                 1      context-switches          #    0.002 M/sec
                 0      cpu-migrations            #    0.000 K/sec
                49      page-faults               #    0.092 M/sec                    ( +-  1.05% )
           1104279      cycles                    #    2.087 GHz                      ( +-  1.65% )
   <not supported>      stalled-cycles-frontend
   <not supported>      stalled-cycles-backend
            528112      instructions              #    0.48  insns per cycle          ( +-  1.12% )
   <not supported>      branches
              9579      branch-misses             #   18.099 M/sec                    ( +-  2.40% )

       5.000851904 seconds time elapsed                                          ( +-  0.00% )

Guest:
 Performance counter stats for 'sleep 5' (5 runs):

          0.695412      task-clock (msec)         #    0.000 CPUs utilized            ( +-  1.26% )
                 1      context-switches          #    0.001 M/sec
                 0      cpu-migrations            #    0.000 K/sec
                49      page-faults               #    0.070 M/sec                    ( +-  1.29% )
           1430471      cycles                    #    2.057 GHz                      ( +-  1.25% )
   <not supported>      stalled-cycles-frontend
   <not supported>      stalled-cycles-backend
            659173      instructions              #    0.46  insns per cycle          ( +-  2.64% )
   <not supported>      branches
             10893      branch-misses             #   15.664 M/sec                    ( +-  1.23% )

       5.001277044 seconds time elapsed                                          ( +-  0.00% )

Have a cycle counter read test like below in guest and host:

static void test(void)
{
	unsigned long count, count1, count2;
	count1 = read_cycles();
	count++;
	count2 = read_cycles();
}

Host:
count1: 3046505444
count2: 3046505575
delta: 131

Guest:
count1: 5932773531
count2: 5932773668
delta: 137

The gap between guest and host is very small. One reason for this I
think is that it doesn't count the cycles in EL2 and host since we add
exclude_hv = 1. So the cycles spent to store/restore registers which
happens at EL2 are not included.

This patchset can be fetched from [1] and the relevant QEMU version for
test can be fetched from [2].

The results of 'perf test' can be found from [3][4].
The results of perf_event_tests test suite can be found from [5][6].

Also, I have tested "perf top" in two VMs and host at the same time. It
works well.

Thanks,
Shannon

[1] https://git.linaro.org/people/shannon.zhao/linux-mainline.git  KVM_ARM64_PMU_v12
[2] https://git.linaro.org/people/shannon.zhao/qemu.git  PMU
[3] http://people.linaro.org/~shannon.zhao/PMU/perf-test-host.txt
[4] http://people.linaro.org/~shannon.zhao/PMU/perf-test-guest.txt
[5] http://people.linaro.org/~shannon.zhao/PMU/perf_event_tests-host.txt
[6] http://people.linaro.org/~shannon.zhao/PMU/perf_event_tests-guest.txt

Changes since v11:
* Move PMU register related defines to asm/perf_event.h and rename them
  with prefix ARMV8_PMU_*
* BUG_ON when writing to PMCEID0/1 register
* Lower the PMU interrupt line when PMCR_EL0.E == 0
* Fix come coding styles
* Drop kvm_arm_pmu_irq_access

Changes since v10:
* Check if PMCR.N is zero before using GENMASK
* Fix attr.disabled
* use same way to reset counter's value in PATCH 14

Changes since v9:
* Change kvm_arm_support_pmu_v3 to a bool function [PATCH 19/21]
* Fix several typoes, change checking logic of kvm_arm_pmu_v3_init and
  change irq_is_invalid to irq_is_valid [PATCH 21/21]
* Add Acks and Rb from Peter and Andrew, thanks a lot

Changes since v8:
* Fix the wrong use of r->reg in register accessors for 32bit part
* Rewrite the handle of PMUSERENR based on the new inject UND patch
* Drop the inline attribute
* Introduce SET/GET/HAS_DEVICE_ATTR for vcpu iotcl and set the PMU
  overflow interrupt via this API
* Use one feature bit for PMUv3

Changes since v7:
* Rebase on kvm-arm next
* Fix the handler of PMUSERENR and add a helper to forward trap to guest
  EL1
* Fix some small bugs found by Marc

Changes since v6:
* Rebase on v4.4-rc5
* Drop access_pmu_cp15_regs() so that it could use same handler for both
  arch64 and arch32. And it could drop the definitions of CP15 register
  offsets, also avoid same codes added twice
* Use vcpu_sys_reg() when accessing PMU registers to avoid endian things
* Add handler for PMUSERENR and some checkers for other registers
* Add kvm_arm_pmu_get_attr()

Changes since v5:
* Rebase on new linux kernel mainline
* Remove state duplications and drop PMOVSCLR, PMCNTENCLR, PMINTENCLR,
  PMXEVCNTR, PMXEVTYPER
* Add a helper to check if vPMU is already initialized
* remove kvm_vcpu from kvm_pmc

Changes since v4:
* Rebase on new linux kernel mainline 
* Drop the reset handler of CP15 registers
* Fix a compile failure on arch ARM due to lack of asm/pmu.h
* Refactor the interrupt injecting flow according to Marc's suggestion
* Check the value of PMSELR register
* Calculate the attr.disabled according to PMCR.E and PMCNTENSET/CLR
* Fix some coding style
* Document the vPMU irq range

Changes since v3:
* Rebase on new linux kernel mainline 
* Use ARMV8_MAX_COUNTERS instead of 32
* Reset PMCR.E to zero.
* Trigger overflow for software increment.
* Optimize PMU interrupt inject logic.
* Add handler for E,C,P bits of PMCR
* Fix the overflow bug found by perf_event_tests
* Run 'perf test', 'perf top' and perf_event_tests test suite
* Add exclude_hv = 1 configuration to not count in EL2

Changes since v2:
* Directly use perf raw event type to create perf_event in KVM
* Add a helper vcpu_sysreg_write
* remove unrelated header file

Changes since v1:
* Use switch...case for registers access handler instead of adding
  alone handler for each register
* Try to use the sys_regs to store the register value instead of adding
  new variables in struct kvm_pmc
* Fix the handle of cp15 regs
* Create a new kvm device vPMU, then userspace could choose whether to
  create PMU
* Fix the handle of PMU overflow interrupt

Shannon Zhao (21):
  ARM64: Move PMU register related defines to asm/perf_event.h
  KVM: ARM64: Define PMU data structure for each vcpu
  KVM: ARM64: Add offset defines for PMU registers
  KVM: ARM64: Add access handler for PMCR register
  KVM: ARM64: Add access handler for PMSELR register
  KVM: ARM64: Add access handler for PMCEID0 and PMCEID1 register
  KVM: ARM64: PMU: Add perf event map and introduce perf event creating
    function
  KVM: ARM64: Add access handler for event type register
  KVM: ARM64: Add access handler for event counter register
  KVM: ARM64: Add access handler for PMCNTENSET and PMCNTENCLR register
  KVM: ARM64: Add access handler for PMINTENSET and PMINTENCLR register
  KVM: ARM64: Add access handler for PMOVSSET and PMOVSCLR register
  KVM: ARM64: Add access handler for PMSWINC register
  KVM: ARM64: Add helper to handle PMCR register bits
  KVM: ARM64: Add access handler for PMUSERENR register
  KVM: ARM64: Add PMU overflow interrupt routing
  KVM: ARM64: Reset PMU state when resetting vcpu
  KVM: ARM64: Free perf event of PMU when destroying vcpu
  KVM: ARM64: Add a new feature bit for PMUv3
  KVM: ARM: Introduce per-vcpu kvm device controls
  KVM: ARM64: Add a new vcpu device control group for PMUv3

 Documentation/virtual/kvm/api.txt          |  12 +-
 Documentation/virtual/kvm/devices/vcpu.txt |  33 ++
 arch/arm/include/asm/kvm_host.h            |  15 +
 arch/arm/kvm/arm.c                         |  61 ++++
 arch/arm64/include/asm/kvm_host.h          |  25 +-
 arch/arm64/include/asm/perf_event.h        |  48 +++
 arch/arm64/include/uapi/asm/kvm.h          |   6 +
 arch/arm64/kernel/perf_event.c             |  68 +---
 arch/arm64/kvm/Kconfig                     |   7 +
 arch/arm64/kvm/Makefile                    |   1 +
 arch/arm64/kvm/guest.c                     |  51 +++
 arch/arm64/kvm/hyp/hyp.h                   |   1 +
 arch/arm64/kvm/hyp/switch.c                |   3 +
 arch/arm64/kvm/reset.c                     |   7 +
 arch/arm64/kvm/sys_regs.c                  | 569 +++++++++++++++++++++++++++--
 include/kvm/arm_pmu.h                      | 107 ++++++
 include/uapi/linux/kvm.h                   |   2 +
 virt/kvm/arm/pmu.c                         | 507 +++++++++++++++++++++++++
 18 files changed, 1438 insertions(+), 85 deletions(-)
 create mode 100644 Documentation/virtual/kvm/devices/vcpu.txt
 create mode 100644 include/kvm/arm_pmu.h
 create mode 100644 virt/kvm/arm/pmu.c

-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:44 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:44 +0800
Subject: [PATCH v12 08/21] KVM: ARM64: Add access handler for event type
 register
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-9-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
which is mapped to PMEVTYPERn or PMCCFILTR.

The access handler translates all aarch32 register offsets to aarch64
ones and uses vcpu_sys_reg() to access their values to avoid taking care
of big endian.

When writing to these registers, create a perf_event for the selected
event type.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/kvm/sys_regs.c | 140 +++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 138 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 27afa0b..7c6212a 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -513,6 +513,54 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
+{
+	u64 pmcr, val;
+
+	pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
+	val = (pmcr >> ARMV8_PMU_PMCR_N_SHIFT) & ARMV8_PMU_PMCR_N_MASK;
+	if (idx >= val && idx != ARMV8_PMU_CYCLE_IDX)
+		return false;
+
+	return true;
+}
+
+static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			       const struct sys_reg_desc *r)
+{
+	u64 idx, reg;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (r->CRn == 9 && r->CRm == 13 && r->Op2 == 1) {
+		/* PMXEVTYPER_EL0 */
+		idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_PMU_COUNTER_MASK;
+		reg = PMEVTYPER0_EL0 + idx;
+	} else if (r->CRn == 14 && (r->CRm & 12) == 12) {
+		idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+		if (idx == ARMV8_PMU_CYCLE_IDX)
+			reg = PMCCFILTR_EL0;
+		else
+			/* PMEVTYPERn_EL0 */
+			reg = PMEVTYPER0_EL0 + idx;
+	} else {
+		BUG();
+	}
+
+	if (!pmu_counter_idx_valid(vcpu, idx))
+		return false;
+
+	if (p->is_write) {
+		kvm_pmu_set_counter_event_type(vcpu, p->regval, idx);
+		vcpu_sys_reg(vcpu, reg) = p->regval & ARMV8_PMU_EVTYPE_MASK;
+	} else {
+		p->regval = vcpu_sys_reg(vcpu, reg) & ARMV8_PMU_EVTYPE_MASK;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -528,6 +576,13 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	{ Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111),	\
 	  trap_wcr, reset_wcr, n, 0,  get_wcr, set_wcr }
 
+/* Macro to expand the PMEVTYPERn_EL0 register */
+#define PMU_PMEVTYPER_EL0(n)						\
+	/* PMEVTYPERn_EL0 */						\
+	{ Op0(0b11), Op1(0b011), CRn(0b1110),				\
+	  CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)),		\
+	  access_pmu_evtyper, reset_unknown, (PMEVTYPER0_EL0 + n), }
+
 /*
  * Architected system registers.
  * Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
@@ -724,7 +779,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  trap_raz_wi },
 	/* PMXEVTYPER_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
-	  trap_raz_wi },
+	  access_pmu_evtyper },
 	/* PMXEVCNTR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
 	  trap_raz_wi },
@@ -742,6 +797,45 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
 	  NULL, reset_unknown, TPIDRRO_EL0 },
 
+	/* PMEVTYPERn_EL0 */
+	PMU_PMEVTYPER_EL0(0),
+	PMU_PMEVTYPER_EL0(1),
+	PMU_PMEVTYPER_EL0(2),
+	PMU_PMEVTYPER_EL0(3),
+	PMU_PMEVTYPER_EL0(4),
+	PMU_PMEVTYPER_EL0(5),
+	PMU_PMEVTYPER_EL0(6),
+	PMU_PMEVTYPER_EL0(7),
+	PMU_PMEVTYPER_EL0(8),
+	PMU_PMEVTYPER_EL0(9),
+	PMU_PMEVTYPER_EL0(10),
+	PMU_PMEVTYPER_EL0(11),
+	PMU_PMEVTYPER_EL0(12),
+	PMU_PMEVTYPER_EL0(13),
+	PMU_PMEVTYPER_EL0(14),
+	PMU_PMEVTYPER_EL0(15),
+	PMU_PMEVTYPER_EL0(16),
+	PMU_PMEVTYPER_EL0(17),
+	PMU_PMEVTYPER_EL0(18),
+	PMU_PMEVTYPER_EL0(19),
+	PMU_PMEVTYPER_EL0(20),
+	PMU_PMEVTYPER_EL0(21),
+	PMU_PMEVTYPER_EL0(22),
+	PMU_PMEVTYPER_EL0(23),
+	PMU_PMEVTYPER_EL0(24),
+	PMU_PMEVTYPER_EL0(25),
+	PMU_PMEVTYPER_EL0(26),
+	PMU_PMEVTYPER_EL0(27),
+	PMU_PMEVTYPER_EL0(28),
+	PMU_PMEVTYPER_EL0(29),
+	PMU_PMEVTYPER_EL0(30),
+	/* PMCCFILTR_EL0
+	 * This register resets as unknown in 64bit mode while it resets as zero
+	 * in 32bit mode. Here we choose to reset it as zero for consistency.
+	 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1110), CRm(0b1111), Op2(0b111),
+	  access_pmu_evtyper, reset_val, PMCCFILTR_EL0, 0 },
+
 	/* DACR32_EL2 */
 	{ Op0(0b11), Op1(0b100), CRn(0b0011), CRm(0b0000), Op2(0b000),
 	  NULL, reset_unknown, DACR32_EL2 },
@@ -931,6 +1025,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
 	{ Op1( 0), CRm( 2), .access = trap_raz_wi },
 };
 
+/* Macro to expand the PMEVTYPERn register */
+#define PMU_PMEVTYPER(n)						\
+	/* PMEVTYPERn */						\
+	{ Op1(0), CRn(0b1110),						\
+	  CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)),		\
+	  access_pmu_evtyper }
+
 /*
  * Trapped cp15 registers. TTBR0/TTBR1 get a double encoding,
  * depending on the way they are accessed (as a 32bit or a 64bit
@@ -967,7 +1068,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
@@ -982,6 +1083,41 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn(12), CRm(12), Op2( 5), trap_raz_wi },
 
 	{ Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
+
+	/* PMEVTYPERn */
+	PMU_PMEVTYPER(0),
+	PMU_PMEVTYPER(1),
+	PMU_PMEVTYPER(2),
+	PMU_PMEVTYPER(3),
+	PMU_PMEVTYPER(4),
+	PMU_PMEVTYPER(5),
+	PMU_PMEVTYPER(6),
+	PMU_PMEVTYPER(7),
+	PMU_PMEVTYPER(8),
+	PMU_PMEVTYPER(9),
+	PMU_PMEVTYPER(10),
+	PMU_PMEVTYPER(11),
+	PMU_PMEVTYPER(12),
+	PMU_PMEVTYPER(13),
+	PMU_PMEVTYPER(14),
+	PMU_PMEVTYPER(15),
+	PMU_PMEVTYPER(16),
+	PMU_PMEVTYPER(17),
+	PMU_PMEVTYPER(18),
+	PMU_PMEVTYPER(19),
+	PMU_PMEVTYPER(20),
+	PMU_PMEVTYPER(21),
+	PMU_PMEVTYPER(22),
+	PMU_PMEVTYPER(23),
+	PMU_PMEVTYPER(24),
+	PMU_PMEVTYPER(25),
+	PMU_PMEVTYPER(26),
+	PMU_PMEVTYPER(27),
+	PMU_PMEVTYPER(28),
+	PMU_PMEVTYPER(29),
+	PMU_PMEVTYPER(30),
+	/* PMCCFILTR */
+	{ Op1(0), CRn(14), CRm(15), Op2(7), access_pmu_evtyper },
 };
 
 static const struct sys_reg_desc cp15_64_regs[] = {
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:41 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:41 +0800
Subject: [PATCH v12 05/21] KVM: ARM64: Add access handler for PMSELR register
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-6-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Since the reset value of PMSELR_EL0 is UNKNOWN, use reset_unknown for
its reset handler. When reading PMSELR, return the PMSELR.SEL field to
guest.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/kvm/sys_regs.c | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 7ee4d5e..65f5f00 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -477,6 +477,22 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			  const struct sys_reg_desc *r)
+{
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write)
+		vcpu_sys_reg(vcpu, PMSELR_EL0) = p->regval;
+	else
+		/* return PMSELR.SEL field */
+		p->regval = vcpu_sys_reg(vcpu, PMSELR_EL0)
+			    & ARMV8_PMU_COUNTER_MASK;
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -676,7 +692,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  trap_raz_wi },
 	/* PMSELR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
-	  trap_raz_wi },
+	  access_pmselr, reset_unknown, PMSELR_EL0 },
 	/* PMCEID0_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
 	  trap_raz_wi },
@@ -927,7 +943,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:54 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:54 +0800
Subject: [PATCH v12 18/21] KVM: ARM64: Free perf event of PMU when destroying
 vcpu
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-19-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When KVM frees VCPU, it needs to free the perf_event of PMU.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm/kvm/arm.c    |  1 +
 include/kvm/arm_pmu.h |  2 ++
 virt/kvm/arm/pmu.c    | 21 +++++++++++++++++++++
 3 files changed, 24 insertions(+)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index f54264c..d2c2cc3 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -266,6 +266,7 @@ void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
 	kvm_mmu_free_memory_caches(vcpu);
 	kvm_timer_vcpu_terminate(vcpu);
 	kvm_vgic_vcpu_destroy(vcpu);
+	kvm_pmu_vcpu_destroy(vcpu);
 	kmem_cache_free(kvm_vcpu_cache, vcpu);
 }
 
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 46b773e..9cebf03 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -42,6 +42,7 @@ u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
 void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
 void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu);
+void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
@@ -67,6 +68,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 	return 0;
 }
 static inline void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu) {}
+static inline void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu) {}
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 92fff9a..0427af8 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -101,6 +101,27 @@ void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu)
 	}
 }
 
+/**
+ * kvm_pmu_vcpu_destroy - free perf event of PMU for cpu
+ * @vcpu: The vcpu pointer
+ *
+ */
+void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu)
+{
+	int i;
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+	for (i = 0; i < ARMV8_PMU_MAX_COUNTERS; i++) {
+		struct kvm_pmc *pmc = &pmu->pmc[i];
+
+		if (pmc->perf_event) {
+			perf_event_disable(pmc->perf_event);
+			perf_event_release_kernel(pmc->perf_event);
+			pmc->perf_event = NULL;
+		}
+	}
+}
+
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 {
 	u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMU_PMCR_N_SHIFT;
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:42 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:42 +0800
Subject: [PATCH v12 06/21] KVM: ARM64: Add access handler for PMCEID0 and
 PMCEID1 register
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-7-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Add access handler which gets host value of PMCEID0 or PMCEID1 when
guest access these registers. Writing action to PMCEID0 or PMCEID1 is
UNDEFINED.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
---
 arch/arm64/kvm/sys_regs.c | 28 ++++++++++++++++++++++++----
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 65f5f00..27afa0b 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -493,6 +493,26 @@ static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			  const struct sys_reg_desc *r)
+{
+	u64 pmceid;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	BUG_ON(p->is_write);
+
+	if (!(p->Op2 & 1))
+		asm volatile("mrs %0, pmceid0_el0\n" : "=r" (pmceid));
+	else
+		asm volatile("mrs %0, pmceid1_el0\n" : "=r" (pmceid));
+
+	p->regval = pmceid;
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -695,10 +715,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmselr, reset_unknown, PMSELR_EL0 },
 	/* PMCEID0_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
-	  trap_raz_wi },
+	  access_pmceid },
 	/* PMCEID1_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b111),
-	  trap_raz_wi },
+	  access_pmceid },
 	/* PMCCNTR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
 	  trap_raz_wi },
@@ -944,8 +964,8 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:46 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:46 +0800
Subject: [PATCH v12 10/21] KVM: ARM64: Add access handler for PMCNTENSET and
 PMCNTENCLR register
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-11-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Since the reset value of PMCNTENSET and PMCNTENCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMCNTENSET or PMCNTENCLR register.

When writing to PMCNTENSET, call perf_event_enable to enable the perf
event. When writing to PMCNTENCLR, call perf_event_disable to disable
the perf event.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
---
 arch/arm64/kvm/sys_regs.c | 35 ++++++++++++++++++++++---
 include/kvm/arm_pmu.h     |  9 +++++++
 virt/kvm/arm/pmu.c        | 66 +++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 106 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 70a47a9..d7c7ed4a 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -599,6 +599,33 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
 	return true;
 }
 
+static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			   const struct sys_reg_desc *r)
+{
+	u64 val, mask;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	mask = kvm_pmu_valid_counter_mask(vcpu);
+	if (p->is_write) {
+		val = p->regval & mask;
+		if (r->Op2 & 0x1) {
+			/* accessing PMCNTENSET_EL0 */
+			vcpu_sys_reg(vcpu, PMCNTENSET_EL0) |= val;
+			kvm_pmu_enable_counter(vcpu, val);
+		} else {
+			/* accessing PMCNTENCLR_EL0 */
+			vcpu_sys_reg(vcpu, PMCNTENSET_EL0) &= ~val;
+			kvm_pmu_disable_counter(vcpu, val);
+		}
+	} else {
+		p->regval = vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & mask;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -800,10 +827,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmcr, reset_pmcr, },
 	/* PMCNTENSET_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
-	  trap_raz_wi },
+	  access_pmcnten, reset_unknown, PMCNTENSET_EL0 },
 	/* PMCNTENCLR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b010),
-	  trap_raz_wi },
+	  access_pmcnten, NULL, PMCNTENSET_EL0 },
 	/* PMOVSCLR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
 	  trap_raz_wi },
@@ -1145,8 +1172,8 @@ static const struct sys_reg_desc cp15_regs[] = {
 
 	/* PMU */
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 7404424..c5737797 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -40,6 +40,9 @@ struct kvm_pmu {
 #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
 u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
 void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
+u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
+void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 #else
@@ -54,6 +57,12 @@ static inline u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu,
 }
 static inline void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu,
 					     u64 select_idx, u64 val) {}
+static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
+{
+	return 0;
+}
+static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 96c8ffc..591a11d 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -83,6 +83,72 @@ static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
 	}
 }
 
+u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
+{
+	u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMU_PMCR_N_SHIFT;
+
+	val &= ARMV8_PMU_PMCR_N_MASK;
+	if (val == 0)
+		return BIT(ARMV8_PMU_CYCLE_IDX);
+	else
+		return GENMASK(val - 1, 0) | BIT(ARMV8_PMU_CYCLE_IDX);
+}
+
+/**
+ * kvm_pmu_enable_counter - enable selected PMU counter
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCNTENSET register
+ *
+ * Call perf_event_enable to start counting the perf event
+ */
+void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val)
+{
+	int i;
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_pmc *pmc;
+
+	if (!(vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E) || !val)
+		return;
+
+	for (i = 0; i < ARMV8_PMU_MAX_COUNTERS; i++) {
+		if (!(val & BIT(i)))
+			continue;
+
+		pmc = &pmu->pmc[i];
+		if (pmc->perf_event) {
+			perf_event_enable(pmc->perf_event);
+			if (pmc->perf_event->state != PERF_EVENT_STATE_ACTIVE)
+				kvm_debug("fail to enable perf event\n");
+		}
+	}
+}
+
+/**
+ * kvm_pmu_disable_counter - disable selected PMU counter
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCNTENCLR register
+ *
+ * Call perf_event_disable to stop counting the perf event
+ */
+void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
+{
+	int i;
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_pmc *pmc;
+
+	if (!val)
+		return;
+
+	for (i = 0; i < ARMV8_PMU_MAX_COUNTERS; i++) {
+		if (!(val & BIT(i)))
+			continue;
+
+		pmc = &pmu->pmc[i];
+		if (pmc->perf_event)
+			perf_event_disable(pmc->perf_event);
+	}
+}
+
 static bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu, u64 select_idx)
 {
 	return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E) &&
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:45 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:45 +0800
Subject: [PATCH v12 09/21] KVM: ARM64: Add access handler for event counter
 register
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-10-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

These kind of registers include PMEVCNTRn, PMCCNTR and PMXEVCNTR which
is mapped to PMEVCNTRn.

The access handler translates all aarch32 register offsets to aarch64
ones and uses vcpu_sys_reg() to access their values to avoid taking care
of big endian.

When reading these registers, return the sum of register value and the
value perf event counts.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/kvm/sys_regs.c | 125 ++++++++++++++++++++++++++++++++++++++++++++--
 include/kvm/arm_pmu.h     |   3 ++
 virt/kvm/arm/pmu.c        |  15 ++++++
 3 files changed, 139 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 7c6212a..70a47a9 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -561,6 +561,44 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
+			      struct sys_reg_params *p,
+			      const struct sys_reg_desc *r)
+{
+	u64 idx;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (r->CRn == 9 && r->CRm == 13) {
+		if (r->Op2 == 2) {
+			/* PMXEVCNTR_EL0 */
+			idx = vcpu_sys_reg(vcpu, PMSELR_EL0)
+			      & ARMV8_PMU_COUNTER_MASK;
+		} else if (r->Op2 == 0) {
+			/* PMCCNTR_EL0 */
+			idx = ARMV8_PMU_CYCLE_IDX;
+		} else {
+			BUG();
+		}
+	} else if (r->CRn == 14 && (r->CRm & 12) == 8) {
+		/* PMEVCNTRn_EL0 */
+		idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+	} else {
+		BUG();
+	}
+
+	if (!pmu_counter_idx_valid(vcpu, idx))
+		return false;
+
+	if (p->is_write)
+		kvm_pmu_set_counter_value(vcpu, idx, p->regval);
+	else
+		p->regval = kvm_pmu_get_counter_value(vcpu, idx);
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -576,6 +614,13 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	{ Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111),	\
 	  trap_wcr, reset_wcr, n, 0,  get_wcr, set_wcr }
 
+/* Macro to expand the PMEVCNTRn_EL0 register */
+#define PMU_PMEVCNTR_EL0(n)						\
+	/* PMEVCNTRn_EL0 */						\
+	{ Op0(0b11), Op1(0b011), CRn(0b1110),				\
+	  CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)),		\
+	  access_pmu_evcntr, reset_unknown, (PMEVCNTR0_EL0 + n), }
+
 /* Macro to expand the PMEVTYPERn_EL0 register */
 #define PMU_PMEVTYPER_EL0(n)						\
 	/* PMEVTYPERn_EL0 */						\
@@ -776,13 +821,13 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmceid },
 	/* PMCCNTR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
-	  trap_raz_wi },
+	  access_pmu_evcntr, reset_unknown, PMCCNTR_EL0 },
 	/* PMXEVTYPER_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
 	  access_pmu_evtyper },
 	/* PMXEVCNTR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
-	  trap_raz_wi },
+	  access_pmu_evcntr },
 	/* PMUSERENR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
 	  trap_raz_wi },
@@ -797,6 +842,38 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
 	  NULL, reset_unknown, TPIDRRO_EL0 },
 
+	/* PMEVCNTRn_EL0 */
+	PMU_PMEVCNTR_EL0(0),
+	PMU_PMEVCNTR_EL0(1),
+	PMU_PMEVCNTR_EL0(2),
+	PMU_PMEVCNTR_EL0(3),
+	PMU_PMEVCNTR_EL0(4),
+	PMU_PMEVCNTR_EL0(5),
+	PMU_PMEVCNTR_EL0(6),
+	PMU_PMEVCNTR_EL0(7),
+	PMU_PMEVCNTR_EL0(8),
+	PMU_PMEVCNTR_EL0(9),
+	PMU_PMEVCNTR_EL0(10),
+	PMU_PMEVCNTR_EL0(11),
+	PMU_PMEVCNTR_EL0(12),
+	PMU_PMEVCNTR_EL0(13),
+	PMU_PMEVCNTR_EL0(14),
+	PMU_PMEVCNTR_EL0(15),
+	PMU_PMEVCNTR_EL0(16),
+	PMU_PMEVCNTR_EL0(17),
+	PMU_PMEVCNTR_EL0(18),
+	PMU_PMEVCNTR_EL0(19),
+	PMU_PMEVCNTR_EL0(20),
+	PMU_PMEVCNTR_EL0(21),
+	PMU_PMEVCNTR_EL0(22),
+	PMU_PMEVCNTR_EL0(23),
+	PMU_PMEVCNTR_EL0(24),
+	PMU_PMEVCNTR_EL0(25),
+	PMU_PMEVCNTR_EL0(26),
+	PMU_PMEVCNTR_EL0(27),
+	PMU_PMEVCNTR_EL0(28),
+	PMU_PMEVCNTR_EL0(29),
+	PMU_PMEVCNTR_EL0(30),
 	/* PMEVTYPERn_EL0 */
 	PMU_PMEVTYPER_EL0(0),
 	PMU_PMEVTYPER_EL0(1),
@@ -1025,6 +1102,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
 	{ Op1( 0), CRm( 2), .access = trap_raz_wi },
 };
 
+/* Macro to expand the PMEVCNTRn register */
+#define PMU_PMEVCNTR(n)							\
+	/* PMEVCNTRn */							\
+	{ Op1(0), CRn(0b1110),						\
+	  CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)),		\
+	  access_pmu_evcntr }
+
 /* Macro to expand the PMEVTYPERn register */
 #define PMU_PMEVTYPER(n)						\
 	/* PMEVTYPERn */						\
@@ -1067,9 +1151,9 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
-	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), access_pmu_evcntr },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
-	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), trap_raz_wi },
@@ -1084,6 +1168,38 @@ static const struct sys_reg_desc cp15_regs[] = {
 
 	{ Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
 
+	/* PMEVCNTRn */
+	PMU_PMEVCNTR(0),
+	PMU_PMEVCNTR(1),
+	PMU_PMEVCNTR(2),
+	PMU_PMEVCNTR(3),
+	PMU_PMEVCNTR(4),
+	PMU_PMEVCNTR(5),
+	PMU_PMEVCNTR(6),
+	PMU_PMEVCNTR(7),
+	PMU_PMEVCNTR(8),
+	PMU_PMEVCNTR(9),
+	PMU_PMEVCNTR(10),
+	PMU_PMEVCNTR(11),
+	PMU_PMEVCNTR(12),
+	PMU_PMEVCNTR(13),
+	PMU_PMEVCNTR(14),
+	PMU_PMEVCNTR(15),
+	PMU_PMEVCNTR(16),
+	PMU_PMEVCNTR(17),
+	PMU_PMEVCNTR(18),
+	PMU_PMEVCNTR(19),
+	PMU_PMEVCNTR(20),
+	PMU_PMEVCNTR(21),
+	PMU_PMEVCNTR(22),
+	PMU_PMEVCNTR(23),
+	PMU_PMEVCNTR(24),
+	PMU_PMEVCNTR(25),
+	PMU_PMEVCNTR(26),
+	PMU_PMEVCNTR(27),
+	PMU_PMEVCNTR(28),
+	PMU_PMEVCNTR(29),
+	PMU_PMEVCNTR(30),
 	/* PMEVTYPERn */
 	PMU_PMEVTYPER(0),
 	PMU_PMEVTYPER(1),
@@ -1122,6 +1238,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 
 static const struct sys_reg_desc cp15_64_regs[] = {
 	{ Op1( 0), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR0 },
+	{ Op1( 0), CRn( 0), CRm( 9), Op2( 0), access_pmu_evcntr },
 	{ Op1( 0), CRn( 0), CRm(12), Op2( 0), access_gic_sgi },
 	{ Op1( 1), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR1 },
 };
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 9536a24..7404424 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -39,6 +39,7 @@ struct kvm_pmu {
 
 #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
 u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
+void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 #else
@@ -51,6 +52,8 @@ static inline u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu,
 {
 	return 0;
 }
+static inline void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu,
+					     u64 select_idx, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 648c30e..96c8ffc 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -48,6 +48,21 @@ u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
 }
 
 /**
+ * kvm_pmu_set_counter_value - set PMU counter value
+ * @vcpu: The vcpu pointer
+ * @select_idx: The counter index
+ * @val: The counter value
+ */
+void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val)
+{
+	u64 reg;
+
+	reg = (select_idx == ARMV8_PMU_CYCLE_IDX)
+	      ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + select_idx;
+	vcpu_sys_reg(vcpu, reg) += (s64)val - kvm_pmu_get_counter_value(vcpu, select_idx);
+}
+
+/**
  * kvm_pmu_stop_counter - stop PMU counter
  * @pmc: The PMU counter pointer
  *
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:38 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:38 +0800
Subject: [PATCH v12 02/21] KVM: ARM64: Define PMU data structure for each vcpu
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-3-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Here we plan to support virtual PMU for guest by full software
emulation, so define some basic structs and functions preparing for
futher steps. Define struct kvm_pmc for performance monitor counter and
struct kvm_pmu for performance monitor unit for each vcpu. According to
ARMv8 spec, the PMU contains at most 32(ARMV8_PMU_MAX_COUNTERS)
counters.

Since this only supports ARM64 (or PMUv3), add a separate config symbol
for it.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/kvm_host.h |  2 ++
 arch/arm64/kvm/Kconfig            |  7 +++++++
 include/kvm/arm_pmu.h             | 42 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 51 insertions(+)
 create mode 100644 include/kvm/arm_pmu.h

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 689d4c9..6f0241f 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -36,6 +36,7 @@
 
 #include <kvm/arm_vgic.h>
 #include <kvm/arm_arch_timer.h>
+#include <kvm/arm_pmu.h>
 
 #define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
 
@@ -211,6 +212,7 @@ struct kvm_vcpu_arch {
 	/* VGIC state */
 	struct vgic_cpu vgic_cpu;
 	struct arch_timer_cpu timer_cpu;
+	struct kvm_pmu pmu;
 
 	/*
 	 * Anything that is not used directly from assembly code goes
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index a5272c0..de7450d 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -36,6 +36,7 @@ config KVM
 	select HAVE_KVM_EVENTFD
 	select HAVE_KVM_IRQFD
 	select KVM_ARM_VGIC_V3
+	select KVM_ARM_PMU if HW_PERF_EVENTS
 	---help---
 	  Support hosting virtualized guest machines.
 	  We don't support KVM with 16K page tables yet, due to the multiple
@@ -48,6 +49,12 @@ config KVM_ARM_HOST
 	---help---
 	  Provides host support for ARM processors.
 
+config KVM_ARM_PMU
+	bool
+	---help---
+	  Adds support for a virtual Performance Monitoring Unit (PMU) in
+	  virtual machines.
+
 source drivers/vhost/Kconfig
 
 endif # VIRTUALIZATION
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
new file mode 100644
index 0000000..3c2fd56
--- /dev/null
+++ b/include/kvm/arm_pmu.h
@@ -0,0 +1,42 @@
+/*
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Shannon Zhao <shannon.zhao at linaro.org>
+ *
+ * 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/>.
+ */
+
+#ifndef __ASM_ARM_KVM_PMU_H
+#define __ASM_ARM_KVM_PMU_H
+
+#ifdef CONFIG_KVM_ARM_PMU
+
+#include <linux/perf_event.h>
+#include <asm/perf_event.h>
+
+struct kvm_pmc {
+	u8 idx;	/* index into the pmu->pmc array */
+	struct perf_event *perf_event;
+	u64 bitmask;
+};
+
+struct kvm_pmu {
+	int irq_num;
+	struct kvm_pmc pmc[ARMV8_PMU_MAX_COUNTERS];
+	bool ready;
+};
+#else
+struct kvm_pmu {
+};
+#endif
+
+#endif
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:51 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:51 +0800
Subject: [PATCH v12 15/21] KVM: ARM64: Add access handler for PMUSERENR
 register
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-16-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

This register resets as unknown in 64bit mode while it resets as zero
in 32bit mode. Here we choose to reset it as zero for consistency.

PMUSERENR_EL0 holds some bits which decide whether PMU registers can be
accessed from EL0. Add some check helpers to handle the access from EL0.

When these bits are zero, only reading PMUSERENR will trap to EL2 and
writing PMUSERENR or reading/writing other PMU registers will trap to
EL1 other than EL2 when HCR.TGE==0. To current KVM configuration
(HCR.TGE==0) there is no way to get these traps. Here we write 0xf to
physical PMUSERENR register on VM entry, so that it will trap PMU access
from EL0 to EL2. Within the register access handler we check the real
value of guest PMUSERENR register to decide whether this access is
allowed. If not allowed, return false to inject UND to guest.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
---
 arch/arm64/include/asm/perf_event.h |   9 ++++
 arch/arm64/kvm/hyp/hyp.h            |   1 +
 arch/arm64/kvm/hyp/switch.c         |   3 ++
 arch/arm64/kvm/sys_regs.c           | 101 ++++++++++++++++++++++++++++++++++--
 4 files changed, 109 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
index c3f5937..76e1931 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -56,6 +56,15 @@
 #define	ARMV8_PMU_EXCLUDE_EL0	(1 << 30)
 #define	ARMV8_PMU_INCLUDE_EL2	(1 << 27)
 
+/*
+ * PMUSERENR: user enable reg
+ */
+#define ARMV8_PMU_USERENR_MASK	0xf		/* Mask for writable bits */
+#define ARMV8_PMU_USERENR_EN	(1 << 0) /* PMU regs can be accessed at EL0 */
+#define ARMV8_PMU_USERENR_SW	(1 << 1) /* PMSWINC can be written at EL0 */
+#define ARMV8_PMU_USERENR_CR	(1 << 2) /* Cycle counter can be read at EL0 */
+#define ARMV8_PMU_USERENR_ER	(1 << 3) /* Event counter can be read at EL0 */
+
 #ifdef CONFIG_PERF_EVENTS
 struct pt_regs;
 extern unsigned long perf_instruction_pointer(struct pt_regs *regs);
diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
index fb27517..c65f8c9 100644
--- a/arch/arm64/kvm/hyp/hyp.h
+++ b/arch/arm64/kvm/hyp/hyp.h
@@ -22,6 +22,7 @@
 #include <linux/kvm_host.h>
 #include <asm/kvm_mmu.h>
 #include <asm/sysreg.h>
+#include <asm/perf_event.h>
 
 #define __hyp_text __section(.hyp.text) notrace
 
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index ca8f5a5..d087724 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -37,6 +37,8 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
 	/* Trap on AArch32 cp15 c15 accesses (EL1 or EL0) */
 	write_sysreg(1 << 15, hstr_el2);
 	write_sysreg(CPTR_EL2_TTA | CPTR_EL2_TFP, cptr_el2);
+	/* Make sure we trap PMU access from EL0 to EL2 */
+	write_sysreg(ARMV8_PMU_USERENR_MASK, pmuserenr_el0);
 	write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
 }
 
@@ -45,6 +47,7 @@ static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
 	write_sysreg(HCR_RW, hcr_el2);
 	write_sysreg(0, hstr_el2);
 	write_sysreg(read_sysreg(mdcr_el2) & MDCR_EL2_HPMN_MASK, mdcr_el2);
+	write_sysreg(0, pmuserenr_el0);
 	write_sysreg(0, cptr_el2);
 }
 
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index f1866c3..c2d9fb9 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -453,6 +453,37 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
 	vcpu_sys_reg(vcpu, PMCR_EL0) = val;
 }
 
+static bool pmu_access_el0_disabled(struct kvm_vcpu *vcpu)
+{
+	u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+	return !((reg & ARMV8_PMU_USERENR_EN) || vcpu_mode_priv(vcpu));
+}
+
+static bool pmu_write_swinc_el0_disabled(struct kvm_vcpu *vcpu)
+{
+	u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+	return !((reg & (ARMV8_PMU_USERENR_SW | ARMV8_PMU_USERENR_EN))
+		 || vcpu_mode_priv(vcpu));
+}
+
+static bool pmu_access_cycle_counter_el0_disabled(struct kvm_vcpu *vcpu)
+{
+	u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+	return !((reg & (ARMV8_PMU_USERENR_CR | ARMV8_PMU_USERENR_EN))
+		 || vcpu_mode_priv(vcpu));
+}
+
+static bool pmu_access_event_counter_el0_disabled(struct kvm_vcpu *vcpu)
+{
+	u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+	return !((reg & (ARMV8_PMU_USERENR_ER | ARMV8_PMU_USERENR_EN))
+		 || vcpu_mode_priv(vcpu));
+}
+
 static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 			const struct sys_reg_desc *r)
 {
@@ -461,6 +492,9 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_access_el0_disabled(vcpu))
+		return false;
+
 	if (p->is_write) {
 		/* Only update writeable bits of PMCR */
 		val = vcpu_sys_reg(vcpu, PMCR_EL0);
@@ -484,6 +518,9 @@ static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_access_event_counter_el0_disabled(vcpu))
+		return false;
+
 	if (p->is_write)
 		vcpu_sys_reg(vcpu, PMSELR_EL0) = p->regval;
 	else
@@ -504,6 +541,9 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 
 	BUG_ON(p->is_write);
 
+	if (pmu_access_el0_disabled(vcpu))
+		return false;
+
 	if (!(p->Op2 & 1))
 		asm volatile("mrs %0, pmceid0_el0\n" : "=r" (pmceid));
 	else
@@ -534,6 +574,9 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_access_el0_disabled(vcpu))
+		return false;
+
 	if (r->CRn == 9 && r->CRm == 13 && r->Op2 == 1) {
 		/* PMXEVTYPER_EL0 */
 		idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_PMU_COUNTER_MASK;
@@ -574,16 +617,25 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
 	if (r->CRn == 9 && r->CRm == 13) {
 		if (r->Op2 == 2) {
 			/* PMXEVCNTR_EL0 */
+			if (pmu_access_event_counter_el0_disabled(vcpu))
+				return false;
+
 			idx = vcpu_sys_reg(vcpu, PMSELR_EL0)
 			      & ARMV8_PMU_COUNTER_MASK;
 		} else if (r->Op2 == 0) {
 			/* PMCCNTR_EL0 */
+			if (pmu_access_cycle_counter_el0_disabled(vcpu))
+				return false;
+
 			idx = ARMV8_PMU_CYCLE_IDX;
 		} else {
 			BUG();
 		}
 	} else if (r->CRn == 14 && (r->CRm & 12) == 8) {
 		/* PMEVCNTRn_EL0 */
+		if (pmu_access_event_counter_el0_disabled(vcpu))
+			return false;
+
 		idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
 	} else {
 		BUG();
@@ -592,10 +644,14 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
 	if (!pmu_counter_idx_valid(vcpu, idx))
 		return false;
 
-	if (p->is_write)
+	if (p->is_write) {
+		if (pmu_access_el0_disabled(vcpu))
+			return false;
+
 		kvm_pmu_set_counter_value(vcpu, idx, p->regval);
-	else
+	} else {
 		p->regval = kvm_pmu_get_counter_value(vcpu, idx);
+	}
 
 	return true;
 }
@@ -608,6 +664,9 @@ static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_access_el0_disabled(vcpu))
+		return false;
+
 	mask = kvm_pmu_valid_counter_mask(vcpu);
 	if (p->is_write) {
 		val = p->regval & mask;
@@ -635,6 +694,9 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (!vcpu_mode_priv(vcpu))
+		return false;
+
 	if (p->is_write) {
 		u64 val = p->regval & mask;
 
@@ -659,6 +721,9 @@ static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_access_el0_disabled(vcpu))
+		return false;
+
 	if (p->is_write) {
 		if (r->CRm & 0x2)
 			/* accessing PMOVSSET_EL0 */
@@ -681,6 +746,9 @@ static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_write_swinc_el0_disabled(vcpu))
+		return false;
+
 	if (p->is_write) {
 		mask = kvm_pmu_valid_counter_mask(vcpu);
 		kvm_pmu_software_increment(vcpu, p->regval & mask);
@@ -690,6 +758,26 @@ static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return false;
 }
 
+static bool access_pmuserenr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			     const struct sys_reg_desc *r)
+{
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write) {
+		if (!vcpu_mode_priv(vcpu))
+			return false;
+
+		vcpu_sys_reg(vcpu, PMUSERENR_EL0) = p->regval
+						    & ARMV8_PMU_USERENR_MASK;
+	} else {
+		p->regval = vcpu_sys_reg(vcpu, PMUSERENR_EL0)
+			    & ARMV8_PMU_USERENR_MASK;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -919,9 +1007,12 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	/* PMXEVCNTR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
 	  access_pmu_evcntr },
-	/* PMUSERENR_EL0 */
+	/* PMUSERENR_EL0
+	 * This register resets as unknown in 64bit mode while it resets as zero
+	 * in 32bit mode. Here we choose to reset it as zero for consistency.
+	 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
-	  trap_raz_wi },
+	  access_pmuserenr, reset_val, PMUSERENR_EL0, 0 },
 	/* PMOVSSET_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
 	  access_pmovs, reset_unknown, PMOVSSET_EL0 },
@@ -1246,7 +1337,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), access_pmu_evcntr },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
-	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), access_pmuserenr },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 3), access_pmovs },
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:52 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:52 +0800
Subject: [PATCH v12 16/21] KVM: ARM64: Add PMU overflow interrupt routing
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-17-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When calling perf_event_create_kernel_counter to create perf_event,
assign a overflow handler. Then when the perf event overflows, set the
corresponding bit of guest PMOVSSET register. If this counter is enabled
and its interrupt is enabled as well, kick the vcpu to sync the
interrupt.

On VM entry, if there is counter overflowed, inject the interrupt with
the level set to 1. Otherwise, inject the interrupt with the level set
to 0.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm/kvm/arm.c    |  2 ++
 include/kvm/arm_pmu.h |  2 ++
 virt/kvm/arm/pmu.c    | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dda1959..f54264c 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -28,6 +28,7 @@
 #include <linux/sched.h>
 #include <linux/kvm.h>
 #include <trace/events/kvm.h>
+#include <kvm/arm_pmu.h>
 
 #define CREATE_TRACE_POINTS
 #include "trace.h"
@@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
 		 * non-preemptible context.
 		 */
 		preempt_disable();
+		kvm_pmu_flush_hwstate(vcpu);
 		kvm_timer_flush_hwstate(vcpu);
 		kvm_vgic_flush_hwstate(vcpu);
 
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 8bc92d1..cf68f9a 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -44,6 +44,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
 void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
@@ -67,6 +68,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
 static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index cda869c..6ac52ce 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -21,6 +21,7 @@
 #include <linux/perf_event.h>
 #include <asm/kvm_emulate.h>
 #include <kvm/arm_pmu.h>
+#include <kvm/arm_vgic.h>
 
 /**
  * kvm_pmu_get_counter_value - get PMU counter value
@@ -181,6 +182,49 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
 }
 
 /**
+ * kvm_pmu_flush_hwstate - flush pmu state to cpu
+ * @vcpu: The vcpu pointer
+ *
+ * Inject virtual PMU IRQ if IRQ is pending for this cpu.
+ */
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
+{
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	u64 overflow;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return;
+
+	overflow = kvm_pmu_overflow_status(vcpu);
+	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id, pmu->irq_num, !!overflow);
+}
+
+static inline struct kvm_vcpu *kvm_pmc_to_vcpu(struct kvm_pmc *pmc)
+{
+	struct kvm_pmu *pmu;
+	struct kvm_vcpu_arch *vcpu_arch;
+
+	pmc -= pmc->idx;
+	pmu = container_of(pmc, struct kvm_pmu, pmc[0]);
+	vcpu_arch = container_of(pmu, struct kvm_vcpu_arch, pmu);
+	return container_of(vcpu_arch, struct kvm_vcpu, arch);
+}
+
+/**
+ * When perf event overflows, call kvm_pmu_overflow_set to set overflow status.
+ */
+static void kvm_pmu_perf_overflow(struct perf_event *perf_event,
+				  struct perf_sample_data *data,
+				  struct pt_regs *regs)
+{
+	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+	struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
+	int idx = pmc->idx;
+
+	kvm_pmu_overflow_set(vcpu, BIT(idx));
+}
+
+/**
  * kvm_pmu_software_increment - do software increment
  * @vcpu: The vcpu pointer
  * @val: the value guest writes to PMSWINC register
@@ -291,7 +335,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 	/* The initial sample period (overflow count) of an event. */
 	attr.sample_period = (-counter) & pmc->bitmask;
 
-	event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
+	event = perf_event_create_kernel_counter(&attr, -1, current,
+						 kvm_pmu_perf_overflow, pmc);
 	if (IS_ERR(event)) {
 		pr_err_once("kvm: pmu event creation failed %ld\n",
 			    PTR_ERR(event));
-- 
2.0.4




From zhaoshenglong at huawei.com  Mon Feb 22 01:37:37 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:37 +0800
Subject: [PATCH v12 01/21] ARM64: Move PMU register related defines to
 asm/perf_event.h
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-2-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

To use the ARMv8 PMU related register defines from the KVM code, we move
the relevant definitions to asm/perf_event.h header file and rename them
with prefix ARMV8_PMU_.

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/perf_event.h | 35 +++++++++++++++++++
 arch/arm64/kernel/perf_event.c      | 68 ++++++++++---------------------------
 2 files changed, 52 insertions(+), 51 deletions(-)

diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
index 7bd3cdb..5c77ef8 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -17,6 +17,41 @@
 #ifndef __ASM_PERF_EVENT_H
 #define __ASM_PERF_EVENT_H
 
+#define	ARMV8_PMU_MAX_COUNTERS	32
+#define	ARMV8_PMU_COUNTER_MASK	(ARMV8_PMU_MAX_COUNTERS - 1)
+
+/*
+ * Per-CPU PMCR: config reg
+ */
+#define ARMV8_PMU_PMCR_E	(1 << 0) /* Enable all counters */
+#define ARMV8_PMU_PMCR_P	(1 << 1) /* Reset all counters */
+#define ARMV8_PMU_PMCR_C	(1 << 2) /* Cycle counter reset */
+#define ARMV8_PMU_PMCR_D	(1 << 3) /* CCNT counts every 64th cpu cycle */
+#define ARMV8_PMU_PMCR_X	(1 << 4) /* Export to ETM */
+#define ARMV8_PMU_PMCR_DP	(1 << 5) /* Disable CCNT if non-invasive debug*/
+#define	ARMV8_PMU_PMCR_N_SHIFT	11	 /* Number of counters supported */
+#define	ARMV8_PMU_PMCR_N_MASK	0x1f
+#define	ARMV8_PMU_PMCR_MASK	0x3f	 /* Mask for writable bits */
+
+/*
+ * PMOVSR: counters overflow flag status reg
+ */
+#define	ARMV8_PMU_OVSR_MASK		0xffffffff	/* Mask for writable bits */
+#define	ARMV8_PMU_OVERFLOWED_MASK	ARMV8_PMU_OVSR_MASK
+
+/*
+ * PMXEVTYPER: Event selection reg
+ */
+#define	ARMV8_PMU_EVTYPE_MASK	0xc80003ff	/* Mask for writable bits */
+#define	ARMV8_PMU_EVTYPE_EVENT	0x3ff		/* Mask for EVENT bits */
+
+/*
+ * Event filters for PMUv3
+ */
+#define	ARMV8_PMU_EXCLUDE_EL1	(1 << 31)
+#define	ARMV8_PMU_EXCLUDE_EL0	(1 << 30)
+#define	ARMV8_PMU_INCLUDE_EL2	(1 << 27)
+
 #ifdef CONFIG_PERF_EVENTS
 struct pt_regs;
 extern unsigned long perf_instruction_pointer(struct pt_regs *regs);
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index f7ab14c..212c9fc4 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -24,6 +24,7 @@
 #include <linux/of.h>
 #include <linux/perf/arm_pmu.h>
 #include <linux/platform_device.h>
+#include <asm/perf_event.h>
 
 /*
  * ARMv8 PMUv3 Performance Events handling code.
@@ -333,9 +334,6 @@ static const struct attribute_group *armv8_pmuv3_attr_groups[] = {
 #define	ARMV8_IDX_COUNTER_LAST(cpu_pmu) \
 	(ARMV8_IDX_CYCLE_COUNTER + cpu_pmu->num_events - 1)
 
-#define	ARMV8_MAX_COUNTERS	32
-#define	ARMV8_COUNTER_MASK	(ARMV8_MAX_COUNTERS - 1)
-
 /*
  * ARMv8 low level PMU access
  */
@@ -344,39 +342,7 @@ static const struct attribute_group *armv8_pmuv3_attr_groups[] = {
  * Perf Event to low level counters mapping
  */
 #define	ARMV8_IDX_TO_COUNTER(x)	\
-	(((x) - ARMV8_IDX_COUNTER0) & ARMV8_COUNTER_MASK)
-
-/*
- * Per-CPU PMCR: config reg
- */
-#define ARMV8_PMCR_E		(1 << 0) /* Enable all counters */
-#define ARMV8_PMCR_P		(1 << 1) /* Reset all counters */
-#define ARMV8_PMCR_C		(1 << 2) /* Cycle counter reset */
-#define ARMV8_PMCR_D		(1 << 3) /* CCNT counts every 64th cpu cycle */
-#define ARMV8_PMCR_X		(1 << 4) /* Export to ETM */
-#define ARMV8_PMCR_DP		(1 << 5) /* Disable CCNT if non-invasive debug*/
-#define	ARMV8_PMCR_N_SHIFT	11	 /* Number of counters supported */
-#define	ARMV8_PMCR_N_MASK	0x1f
-#define	ARMV8_PMCR_MASK		0x3f	 /* Mask for writable bits */
-
-/*
- * PMOVSR: counters overflow flag status reg
- */
-#define	ARMV8_OVSR_MASK		0xffffffff	/* Mask for writable bits */
-#define	ARMV8_OVERFLOWED_MASK	ARMV8_OVSR_MASK
-
-/*
- * PMXEVTYPER: Event selection reg
- */
-#define	ARMV8_EVTYPE_MASK	0xc80003ff	/* Mask for writable bits */
-#define	ARMV8_EVTYPE_EVENT	0x3ff		/* Mask for EVENT bits */
-
-/*
- * Event filters for PMUv3
- */
-#define	ARMV8_EXCLUDE_EL1	(1 << 31)
-#define	ARMV8_EXCLUDE_EL0	(1 << 30)
-#define	ARMV8_INCLUDE_EL2	(1 << 27)
+	(((x) - ARMV8_IDX_COUNTER0) & ARMV8_PMU_COUNTER_MASK)
 
 static inline u32 armv8pmu_pmcr_read(void)
 {
@@ -387,14 +353,14 @@ static inline u32 armv8pmu_pmcr_read(void)
 
 static inline void armv8pmu_pmcr_write(u32 val)
 {
-	val &= ARMV8_PMCR_MASK;
+	val &= ARMV8_PMU_PMCR_MASK;
 	isb();
 	asm volatile("msr pmcr_el0, %0" :: "r" (val));
 }
 
 static inline int armv8pmu_has_overflowed(u32 pmovsr)
 {
-	return pmovsr & ARMV8_OVERFLOWED_MASK;
+	return pmovsr & ARMV8_PMU_OVERFLOWED_MASK;
 }
 
 static inline int armv8pmu_counter_valid(struct arm_pmu *cpu_pmu, int idx)
@@ -453,7 +419,7 @@ static inline void armv8pmu_write_counter(struct perf_event *event, u32 value)
 static inline void armv8pmu_write_evtype(int idx, u32 val)
 {
 	if (armv8pmu_select_counter(idx) == idx) {
-		val &= ARMV8_EVTYPE_MASK;
+		val &= ARMV8_PMU_EVTYPE_MASK;
 		asm volatile("msr pmxevtyper_el0, %0" :: "r" (val));
 	}
 }
@@ -499,7 +465,7 @@ static inline u32 armv8pmu_getreset_flags(void)
 	asm volatile("mrs %0, pmovsclr_el0" : "=r" (value));
 
 	/* Write to clear flags */
-	value &= ARMV8_OVSR_MASK;
+	value &= ARMV8_PMU_OVSR_MASK;
 	asm volatile("msr pmovsclr_el0, %0" :: "r" (value));
 
 	return value;
@@ -637,7 +603,7 @@ static void armv8pmu_start(struct arm_pmu *cpu_pmu)
 
 	raw_spin_lock_irqsave(&events->pmu_lock, flags);
 	/* Enable all counters */
-	armv8pmu_pmcr_write(armv8pmu_pmcr_read() | ARMV8_PMCR_E);
+	armv8pmu_pmcr_write(armv8pmu_pmcr_read() | ARMV8_PMU_PMCR_E);
 	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
 }
 
@@ -648,7 +614,7 @@ static void armv8pmu_stop(struct arm_pmu *cpu_pmu)
 
 	raw_spin_lock_irqsave(&events->pmu_lock, flags);
 	/* Disable all counters */
-	armv8pmu_pmcr_write(armv8pmu_pmcr_read() & ~ARMV8_PMCR_E);
+	armv8pmu_pmcr_write(armv8pmu_pmcr_read() & ~ARMV8_PMU_PMCR_E);
 	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
 }
 
@@ -658,7 +624,7 @@ static int armv8pmu_get_event_idx(struct pmu_hw_events *cpuc,
 	int idx;
 	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
-	unsigned long evtype = hwc->config_base & ARMV8_EVTYPE_EVENT;
+	unsigned long evtype = hwc->config_base & ARMV8_PMU_EVTYPE_EVENT;
 
 	/* Always place a cycle counter into the cycle counter. */
 	if (evtype == ARMV8_PMUV3_PERFCTR_CLOCK_CYCLES) {
@@ -692,11 +658,11 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
 	if (attr->exclude_idle)
 		return -EPERM;
 	if (attr->exclude_user)
-		config_base |= ARMV8_EXCLUDE_EL0;
+		config_base |= ARMV8_PMU_EXCLUDE_EL0;
 	if (attr->exclude_kernel)
-		config_base |= ARMV8_EXCLUDE_EL1;
+		config_base |= ARMV8_PMU_EXCLUDE_EL1;
 	if (!attr->exclude_hv)
-		config_base |= ARMV8_INCLUDE_EL2;
+		config_base |= ARMV8_PMU_INCLUDE_EL2;
 
 	/*
 	 * Install the filter into config_base as this is used to
@@ -719,28 +685,28 @@ static void armv8pmu_reset(void *info)
 	}
 
 	/* Initialize & Reset PMNC: C and P bits. */
-	armv8pmu_pmcr_write(ARMV8_PMCR_P | ARMV8_PMCR_C);
+	armv8pmu_pmcr_write(ARMV8_PMU_PMCR_P | ARMV8_PMU_PMCR_C);
 }
 
 static int armv8_pmuv3_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv8_pmuv3_perf_map,
 				&armv8_pmuv3_perf_cache_map,
-				ARMV8_EVTYPE_EVENT);
+				ARMV8_PMU_EVTYPE_EVENT);
 }
 
 static int armv8_a53_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv8_a53_perf_map,
 				&armv8_a53_perf_cache_map,
-				ARMV8_EVTYPE_EVENT);
+				ARMV8_PMU_EVTYPE_EVENT);
 }
 
 static int armv8_a57_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv8_a57_perf_map,
 				&armv8_a57_perf_cache_map,
-				ARMV8_EVTYPE_EVENT);
+				ARMV8_PMU_EVTYPE_EVENT);
 }
 
 static void armv8pmu_read_num_pmnc_events(void *info)
@@ -748,7 +714,7 @@ static void armv8pmu_read_num_pmnc_events(void *info)
 	int *nb_cnt = info;
 
 	/* Read the nb of CNTx counters supported from PMNC */
-	*nb_cnt = (armv8pmu_pmcr_read() >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
+	*nb_cnt = (armv8pmu_pmcr_read() >> ARMV8_PMU_PMCR_N_SHIFT) & ARMV8_PMU_PMCR_N_MASK;
 
 	/* Add the CPU cycles counter */
 	*nb_cnt += 1;
-- 
2.0.4




From will.deacon at arm.com  Mon Feb 22 01:52:05 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 22 Feb 2016 09:52:05 +0000
Subject: [PATCH] arm64: remove redundant preempt.h
In-Reply-To: <56C7AE26.1060407@linaro.org>
References: <1455299803-317-1-git-send-email-yang.shi@linaro.org>
 <56C7AE26.1060407@linaro.org>
Message-ID: <20160222095205.GA31168@arm.com>

On Fri, Feb 19, 2016 at 04:07:02PM -0800, Shi, Yang wrote:
> Any comment on this one?

I don't really see the point in it, to be honest. Relying on implicit
#includes is usually a bad idea, there are other files in the kernel
including both of these headers and there's not actually a problem to
fix as far as I can tell.

Will

> On 2/12/2016 9:56 AM, Yang Shi wrote:
> >preempt.h has been included by sched.h, so it is not necessary to include
> >both, just keep sched.h.
> >
> >Signed-off-by: Yang Shi <yang.shi at linaro.org>
> >---
> >Happened to find this when checking preempt.h include for another patch review.
> >Build test is passed with and without CONFIG_PREEMPT enabled.
> >
> >  arch/arm64/kernel/cpuinfo.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> >diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> >index 212ae63..e2b37ff 100644
> >--- a/arch/arm64/kernel/cpuinfo.c
> >+++ b/arch/arm64/kernel/cpuinfo.c
> >@@ -25,7 +25,6 @@
> >  #include <linux/init.h>
> >  #include <linux/kernel.h>
> >  #include <linux/personality.h>
> >-#include <linux/preempt.h>
> >  #include <linux/printk.h>
> >  #include <linux/seq_file.h>
> >  #include <linux/sched.h>
> >
> 


From zhaoshenglong at huawei.com  Mon Feb 22 01:37:57 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:57 +0800
Subject: [PATCH v12 21/21] KVM: ARM64: Add a new vcpu device control group for
 PMUv3
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-22-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

To configure the virtual PMUv3 overflow interrupt number, we use the
vcpu kvm_device ioctl, encapsulating the KVM_ARM_VCPU_PMU_V3_IRQ
attribute within the KVM_ARM_VCPU_PMU_V3_CTRL group.

After configuring the PMUv3, call the vcpu ioctl with attribute
KVM_ARM_VCPU_PMU_V3_INIT to initialize the PMUv3.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Peter Maydell <peter.maydell at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
---
 Documentation/virtual/kvm/devices/vcpu.txt |  25 +++++++
 arch/arm/include/asm/kvm_host.h            |  15 ++++
 arch/arm/kvm/arm.c                         |   3 +
 arch/arm64/include/asm/kvm_host.h          |   6 ++
 arch/arm64/include/uapi/asm/kvm.h          |   5 ++
 arch/arm64/kvm/guest.c                     |  51 +++++++++++++
 include/kvm/arm_pmu.h                      |  23 ++++++
 virt/kvm/arm/pmu.c                         | 112 +++++++++++++++++++++++++++++
 8 files changed, 240 insertions(+)

diff --git a/Documentation/virtual/kvm/devices/vcpu.txt b/Documentation/virtual/kvm/devices/vcpu.txt
index 3cc59c5..c041658 100644
--- a/Documentation/virtual/kvm/devices/vcpu.txt
+++ b/Documentation/virtual/kvm/devices/vcpu.txt
@@ -6,3 +6,28 @@ KVM_GET_DEVICE_ATTR, and KVM_HAS_DEVICE_ATTR. The interface uses the same struct
 kvm_device_attr as other devices, but targets VCPU-wide settings and controls.
 
 The groups and attributes per virtual cpu, if any, are architecture specific.
+
+1. GROUP: KVM_ARM_VCPU_PMU_V3_CTRL
+Architectures: ARM64
+
+1.1. ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_IRQ
+Parameters: in kvm_device_attr.addr the address for PMU overflow interrupt is a
+            pointer to an int
+Returns: -EBUSY: The PMU overflow interrupt is already set
+         -ENXIO: The overflow interrupt not set when attempting to get it
+         -ENODEV: PMUv3 not supported
+         -EINVAL: Invalid PMU overflow interrupt number supplied
+
+A value describing the PMUv3 (Performance Monitor Unit v3) overflow interrupt
+number for this vcpu. This interrupt could be a PPI or SPI, but the interrupt
+type must be same for each vcpu. As a PPI, the interrupt number is the same for
+all vcpus, while as an SPI it must be a separate number per vcpu.
+
+1.2 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_INIT
+Parameters: no additional parameter in kvm_device_attr.addr
+Returns: -ENODEV: PMUv3 not supported
+         -ENXIO: PMUv3 not properly configured as required prior to calling this
+                 attribute
+         -EBUSY: PMUv3 already initialized
+
+Request the initialization of the PMUv3.
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index f9f2779..6dd0992 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -242,5 +242,20 @@ static inline void kvm_arm_init_debug(void) {}
 static inline void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) {}
 static inline void kvm_arm_clear_debug(struct kvm_vcpu *vcpu) {}
 static inline void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu) {}
+static inline int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
+					     struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
+static inline int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
+					     struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
+static inline int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
+					     struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
 
 #endif /* __ARM_KVM_HOST_H__ */
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 34d7395..dc8644f 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -833,6 +833,7 @@ static int kvm_arm_vcpu_set_attr(struct kvm_vcpu *vcpu,
 
 	switch (attr->group) {
 	default:
+		ret = kvm_arm_vcpu_arch_set_attr(vcpu, attr);
 		break;
 	}
 
@@ -846,6 +847,7 @@ static int kvm_arm_vcpu_get_attr(struct kvm_vcpu *vcpu,
 
 	switch (attr->group) {
 	default:
+		ret = kvm_arm_vcpu_arch_get_attr(vcpu, attr);
 		break;
 	}
 
@@ -859,6 +861,7 @@ static int kvm_arm_vcpu_has_attr(struct kvm_vcpu *vcpu,
 
 	switch (attr->group) {
 	default:
+		ret = kvm_arm_vcpu_arch_has_attr(vcpu, attr);
 		break;
 	}
 
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index cb220b7..a855a30 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -359,5 +359,11 @@ void kvm_arm_init_debug(void);
 void kvm_arm_setup_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_clear_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu);
+int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr);
+int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr);
+int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr);
 
 #endif /* __ARM64_KVM_HOST_H__ */
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 6aedbe3..f209ea1 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -205,6 +205,11 @@ struct kvm_arch_memory_slot {
 #define KVM_DEV_ARM_VGIC_GRP_CTRL	4
 #define   KVM_DEV_ARM_VGIC_CTRL_INIT	0
 
+/* Device Control API on vcpu fd */
+#define KVM_ARM_VCPU_PMU_V3_CTRL	0
+#define   KVM_ARM_VCPU_PMU_V3_IRQ	0
+#define   KVM_ARM_VCPU_PMU_V3_INIT	1
+
 /* KVM_IRQ_LINE irq field index values */
 #define KVM_ARM_IRQ_TYPE_SHIFT		24
 #define KVM_ARM_IRQ_TYPE_MASK		0xff
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index fcb7788..dbe45c3 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -380,3 +380,54 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
 	}
 	return 0;
 }
+
+int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr)
+{
+	int ret;
+
+	switch (attr->group) {
+	case KVM_ARM_VCPU_PMU_V3_CTRL:
+		ret = kvm_arm_pmu_v3_set_attr(vcpu, attr);
+		break;
+	default:
+		ret = -ENXIO;
+		break;
+	}
+
+	return ret;
+}
+
+int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr)
+{
+	int ret;
+
+	switch (attr->group) {
+	case KVM_ARM_VCPU_PMU_V3_CTRL:
+		ret = kvm_arm_pmu_v3_get_attr(vcpu, attr);
+		break;
+	default:
+		ret = -ENXIO;
+		break;
+	}
+
+	return ret;
+}
+
+int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr)
+{
+	int ret;
+
+	switch (attr->group) {
+	case KVM_ARM_VCPU_PMU_V3_CTRL:
+		ret = kvm_arm_pmu_v3_has_attr(vcpu, attr);
+		break;
+	default:
+		ret = -ENXIO;
+		break;
+	}
+
+	return ret;
+}
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index c7595d6..176913f 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -38,6 +38,7 @@ struct kvm_pmu {
 };
 
 #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
+#define kvm_arm_pmu_irq_initialized(v)	((v)->arch.pmu.irq_num >= VGIC_NR_SGIS)
 u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
 void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
@@ -52,11 +53,18 @@ void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 bool kvm_arm_support_pmu_v3(void);
+int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu,
+			    struct kvm_device_attr *attr);
+int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu,
+			    struct kvm_device_attr *attr);
+int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu,
+			    struct kvm_device_attr *attr);
 #else
 struct kvm_pmu {
 };
 
 #define kvm_arm_pmu_v3_ready(v)		(false)
+#define kvm_arm_pmu_irq_initialized(v)	(false)
 static inline u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu,
 					    u64 select_idx)
 {
@@ -79,6 +87,21 @@ static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 static inline bool kvm_arm_support_pmu_v3(void) { return false; }
+static inline int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu,
+					  struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
+static inline int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu,
+					  struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
+static inline int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu,
+					  struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
 #endif
 
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index d5b6eb4..904617e 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -19,6 +19,7 @@
 #include <linux/kvm.h>
 #include <linux/kvm_host.h>
 #include <linux/perf_event.h>
+#include <linux/uaccess.h>
 #include <asm/kvm_emulate.h>
 #include <kvm/arm_pmu.h>
 #include <kvm/arm_vgic.h>
@@ -393,3 +394,114 @@ bool kvm_arm_support_pmu_v3(void)
 	 */
 	return (perf_num_counters() > 0);
 }
+
+static int kvm_arm_pmu_v3_init(struct kvm_vcpu *vcpu)
+{
+	if (!kvm_arm_support_pmu_v3())
+		return -ENODEV;
+
+	if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features) ||
+	    !kvm_arm_pmu_irq_initialized(vcpu))
+		return -ENXIO;
+
+	if (kvm_arm_pmu_v3_ready(vcpu))
+		return -EBUSY;
+
+	kvm_pmu_vcpu_reset(vcpu);
+	vcpu->arch.pmu.ready = true;
+
+	return 0;
+}
+
+static bool irq_is_valid(struct kvm *kvm, int irq, bool is_ppi)
+{
+	int i;
+	struct kvm_vcpu *vcpu;
+
+	kvm_for_each_vcpu(i, vcpu, kvm) {
+		if (!kvm_arm_pmu_irq_initialized(vcpu))
+			continue;
+
+		if (is_ppi) {
+			if (vcpu->arch.pmu.irq_num != irq)
+				return false;
+		} else {
+			if (vcpu->arch.pmu.irq_num == irq)
+				return false;
+		}
+	}
+
+	return true;
+}
+
+
+int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
+{
+	switch (attr->attr) {
+	case KVM_ARM_VCPU_PMU_V3_IRQ: {
+		int __user *uaddr = (int __user *)(long)attr->addr;
+		int irq;
+
+		if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
+			return -ENODEV;
+
+		if (get_user(irq, uaddr))
+			return -EFAULT;
+
+		/*
+		 * The PMU overflow interrupt could be a PPI or SPI, but for one
+		 * VM the interrupt type must be same for each vcpu. As a PPI,
+		 * the interrupt number is the same for all vcpus, while as an
+		 * SPI it must be a separate number per vcpu.
+		 */
+		if (irq < VGIC_NR_SGIS || irq >= vcpu->kvm->arch.vgic.nr_irqs ||
+		    !irq_is_valid(vcpu->kvm, irq, irq < VGIC_NR_PRIVATE_IRQS))
+			return -EINVAL;
+
+		if (kvm_arm_pmu_irq_initialized(vcpu))
+			return -EBUSY;
+
+		kvm_debug("Set kvm ARM PMU irq: %d\n", irq);
+		vcpu->arch.pmu.irq_num = irq;
+		return 0;
+	}
+	case KVM_ARM_VCPU_PMU_V3_INIT:
+		return kvm_arm_pmu_v3_init(vcpu);
+	}
+
+	return -ENXIO;
+}
+
+int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
+{
+	switch (attr->attr) {
+	case KVM_ARM_VCPU_PMU_V3_IRQ: {
+		int __user *uaddr = (int __user *)(long)attr->addr;
+		int irq;
+
+		if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
+			return -ENODEV;
+
+		if (!kvm_arm_pmu_irq_initialized(vcpu))
+			return -ENXIO;
+
+		irq = vcpu->arch.pmu.irq_num;
+		return put_user(irq, uaddr);
+	}
+	}
+
+	return -ENXIO;
+}
+
+int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
+{
+	switch (attr->attr) {
+	case KVM_ARM_VCPU_PMU_V3_IRQ:
+	case KVM_ARM_VCPU_PMU_V3_INIT:
+		if (kvm_arm_support_pmu_v3() &&
+		    test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
+			return 0;
+	}
+
+	return -ENXIO;
+}
-- 
2.0.4




From kishon at ti.com  Mon Feb 22 01:55:47 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 22 Feb 2016 15:25:47 +0530
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <alpine.DEB.2.02.1602220631300.3418@utopia.booyaka.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com> <56BACCDB.2070507@ti.com>
 <alpine.DEB.2.02.1602111921090.20757@utopia.booyaka.com>
 <56BD8091.4090007@ti.com> <56BE1454.3030002@ti.com> <56C5D377.50901@ti.com>
 <56CAA82D.6000507@ti.com>
 <alpine.DEB.2.02.1602220631300.3418@utopia.booyaka.com>
Message-ID: <56CADB23.8020202@ti.com>

Hi Paul,

On Monday 22 February 2016 12:01 PM, Paul Walmsley wrote:
> Kishon,
> 
> On Mon, 22 Feb 2016, Kishon Vijay Abraham I wrote:
> 
>> Sekhar,
>>
>> On Thursday 18 February 2016 07:51 PM, Sekhar Nori wrote:
>>> On Friday 12 February 2016 10:50 PM, Suman Anna wrote:
>>>> Sekhar,
>>>> Will you be following up with above suggestion since Kishon is gonna be out?
>>>
>>> Alright, noticed this action for me :) Went through the thread, and 
>>> looks like this is what we want to see?
>>>
>>> Thanks,
>>> Sekhar
>>>
>>> ---8<---
>>> From e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19 Mon Sep 17 00:00:00 2001
>>> Message-Id: <e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19.1455803758.git.nsekhar at ti.com>
>>> From: Sekhar Nori <nsekhar at ti.com>
>>> Date: Thu, 18 Feb 2016 16:49:56 +0530
>>> Subject: [PATCH 1/1] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS
>>>
>>> Add a custom reset handler for DRA7x PCIeSS. This
>>> handler is required to deassert PCIe hardreset lines
>>> after they have been asserted.
>>>
>>> This enables the PCIe driver to access registers after
>>> PCIeSS has been runtime enabled without having to
>>> deassert hardreset lines itself.
>>>
>>> With this patch applied, used lspci to make sure
>>> connected PCIe device enumerates on DRA74x and DRA72x
>>> EVMs.
>>>
>>> Signed-off-by: Sekhar Nori <nsekhar at ti.com>
>>> ---
>>> Applies to tag for-v4.6/omap-hwmod-a of Paul W's tree.
>>>
>>>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++
>>>  1 file changed, 23 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> index b61355e2a771..252b74633e31 100644
>>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> @@ -1526,8 +1526,31 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
>>>   *
>>>   */
>>>  
>>> +/*
>>> + * As noted in documentation for _reset() in omap_hwmod.c, the stock reset
>>> + * functionality of OMAP HWMOD layer does not deassert the hardreset lines
>>> + * associated with an IP automatically leaving the driver to handle that
>>> + * by itself. This does not work for PCIeSS which needs the reset lines
>>> + * deasserted for the driver to start accessing registers.
>>> + *
>>> + * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset
>>> + * lines after asserting them.
>>> + */
>>> +static int dra7xx_pciess_reset(struct omap_hwmod *oh)
>>> +{
>>> +	int i;
>>> +
>>> +	for (i = 0; i < oh->rst_lines_cnt; i++) {
>>> +		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);
>>> +		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);
>>> +	}
>>> +
>>> +	return 0;
>>> +}
>>> +
>>>  static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {
>>>  	.name	= "pcie",
>>> +	.reset	= dra7xx_pciess_reset,
>>>  };
>>
>> Thanks for the patch.
> 
> Could you please test the bind/unbind functionality just to make sure it 
> works?

The pci-dra7xx driver neither expose the bind/unbind sysfs entry nor can be
built as module.

However I hacked the pci-dra7xx driver to be built as module [and reverted
Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe error
and driver unbind")] and I don't see an abort when the PCI registers are
accessed after rmmod/modprobe cycle (that was the issue that Sekhar's patch
tried to solve). However PCI as such doesn't work after rmmod/modprobe cycle
[1], but this is a different issue most likely in PCIe core and has to debugged.

In summary, there are other issues in PCI across rmmod/modprobe cycle but the
reset of pci-dra7xx happens fine with this patch.

Thanks
Kishon

[1] -> http://pastebin.ubuntu.com/15169387/


From zhaoshenglong at huawei.com  Mon Feb 22 01:37:43 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Mon, 22 Feb 2016 17:37:43 +0800
Subject: [PATCH v12 07/21] KVM: ARM64: PMU: Add perf event map and introduce
 perf event creating function
In-Reply-To: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456133877-9584-8-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When we use tools like perf on host, perf passes the event type and the
id of this event type category to kernel, then kernel will map them to
hardware event number and write this number to PMU PMEVTYPER<n>_EL0
register. When getting the event number in KVM, directly use raw event
type to create a perf_event for it.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/perf_event.h |   2 +
 arch/arm64/kvm/Makefile             |   1 +
 include/kvm/arm_pmu.h               |  12 ++++
 virt/kvm/arm/pmu.c                  | 122 ++++++++++++++++++++++++++++++++++++
 4 files changed, 137 insertions(+)
 create mode 100644 virt/kvm/arm/pmu.c

diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
index 5c77ef8..867140d 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -29,6 +29,8 @@
 #define ARMV8_PMU_PMCR_D	(1 << 3) /* CCNT counts every 64th cpu cycle */
 #define ARMV8_PMU_PMCR_X	(1 << 4) /* Export to ETM */
 #define ARMV8_PMU_PMCR_DP	(1 << 5) /* Disable CCNT if non-invasive debug*/
+/* Determines which bit of PMCCNTR_EL0 generates an overflow */
+#define ARMV8_PMU_PMCR_LC	(1 << 6)
 #define	ARMV8_PMU_PMCR_N_SHIFT	11	 /* Number of counters supported */
 #define	ARMV8_PMU_PMCR_N_MASK	0x1f
 #define	ARMV8_PMU_PMCR_MASK	0x3f	 /* Mask for writable bits */
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index caee9ee..122cff4 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -26,3 +26,4 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v2-emul.o
 kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3.o
 kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3-emul.o
 kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
+kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 8157fe5..9536a24 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -23,6 +23,8 @@
 #include <linux/perf_event.h>
 #include <asm/perf_event.h>
 
+#define ARMV8_PMU_CYCLE_IDX		(ARMV8_PMU_MAX_COUNTERS - 1)
+
 struct kvm_pmc {
 	u8 idx;	/* index into the pmu->pmc array */
 	struct perf_event *perf_event;
@@ -36,11 +38,21 @@ struct kvm_pmu {
 };
 
 #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
+u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
+void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
+				    u64 select_idx);
 #else
 struct kvm_pmu {
 };
 
 #define kvm_arm_pmu_v3_ready(v)		(false)
+static inline u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu,
+					    u64 select_idx)
+{
+	return 0;
+}
+static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
+						  u64 data, u64 select_idx) {}
 #endif
 
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
new file mode 100644
index 0000000..648c30e
--- /dev/null
+++ b/virt/kvm/arm/pmu.c
@@ -0,0 +1,122 @@
+/*
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Shannon Zhao <shannon.zhao at linaro.org>
+ *
+ * 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/cpu.h>
+#include <linux/kvm.h>
+#include <linux/kvm_host.h>
+#include <linux/perf_event.h>
+#include <asm/kvm_emulate.h>
+#include <kvm/arm_pmu.h>
+
+/**
+ * kvm_pmu_get_counter_value - get PMU counter value
+ * @vcpu: The vcpu pointer
+ * @select_idx: The counter index
+ */
+u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
+{
+	u64 counter, reg, enabled, running;
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_pmc *pmc = &pmu->pmc[select_idx];
+
+	reg = (select_idx == ARMV8_PMU_CYCLE_IDX)
+	      ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + select_idx;
+	counter = vcpu_sys_reg(vcpu, reg);
+
+	/* The real counter value is equal to the value of counter register plus
+	 * the value perf event counts.
+	 */
+	if (pmc->perf_event)
+		counter += perf_event_read_value(pmc->perf_event, &enabled,
+						 &running);
+
+	return counter & pmc->bitmask;
+}
+
+/**
+ * kvm_pmu_stop_counter - stop PMU counter
+ * @pmc: The PMU counter pointer
+ *
+ * If this counter has been configured to monitor some event, release it here.
+ */
+static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
+{
+	u64 counter, reg;
+
+	if (pmc->perf_event) {
+		counter = kvm_pmu_get_counter_value(vcpu, pmc->idx);
+		reg = (pmc->idx == ARMV8_PMU_CYCLE_IDX)
+		       ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + pmc->idx;
+		vcpu_sys_reg(vcpu, reg) = counter;
+		perf_event_disable(pmc->perf_event);
+		perf_event_release_kernel(pmc->perf_event);
+		pmc->perf_event = NULL;
+	}
+}
+
+static bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu, u64 select_idx)
+{
+	return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E) &&
+	       (vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & BIT(select_idx));
+}
+
+/**
+ * kvm_pmu_set_counter_event_type - set selected counter to monitor some event
+ * @vcpu: The vcpu pointer
+ * @data: The data guest writes to PMXEVTYPER_EL0
+ * @select_idx: The number of selected counter
+ *
+ * When OS accesses PMXEVTYPER_EL0, that means it wants to set a PMC to count an
+ * event with given hardware event number. Here we call perf_event API to
+ * emulate this action and create a kernel perf event for it.
+ */
+void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
+				    u64 select_idx)
+{
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_pmc *pmc = &pmu->pmc[select_idx];
+	struct perf_event *event;
+	struct perf_event_attr attr;
+	u64 eventsel, counter;
+
+	kvm_pmu_stop_counter(vcpu, pmc);
+	eventsel = data & ARMV8_PMU_EVTYPE_EVENT;
+
+	memset(&attr, 0, sizeof(struct perf_event_attr));
+	attr.type = PERF_TYPE_RAW;
+	attr.size = sizeof(attr);
+	attr.pinned = 1;
+	attr.disabled = !kvm_pmu_counter_is_enabled(vcpu, select_idx);
+	attr.exclude_user = data & ARMV8_PMU_EXCLUDE_EL0 ? 1 : 0;
+	attr.exclude_kernel = data & ARMV8_PMU_EXCLUDE_EL1 ? 1 : 0;
+	attr.exclude_hv = 1; /* Don't count EL2 events */
+	attr.exclude_host = 1; /* Don't count host events */
+	attr.config = eventsel;
+
+	counter = kvm_pmu_get_counter_value(vcpu, select_idx);
+	/* The initial sample period (overflow count) of an event. */
+	attr.sample_period = (-counter) & pmc->bitmask;
+
+	event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
+	if (IS_ERR(event)) {
+		pr_err_once("kvm: pmu event creation failed %ld\n",
+			    PTR_ERR(event));
+		return;
+	}
+
+	pmc->perf_event = event;
+}
-- 
2.0.4




From nsekhar at ti.com  Mon Feb 22 01:58:09 2016
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 22 Feb 2016 15:28:09 +0530
Subject: [PATCH 3/5] ARM: davinci: dm365: Add dma_slave_map to edma
In-Reply-To: <1454416997-14230-4-git-send-email-peter.ujfalusi@ti.com>
References: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>
 <1454416997-14230-4-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <56CADBB1.9040908@ti.com>

On Tuesday 02 February 2016 06:13 PM, Peter Ujfalusi wrote:
> Provide the dma_slave_map to edma which will allow us to move the drivers
> to the new, simpler dmaengine API and we can remove the DMA resources also
> for the devices.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>

> FIX: dm365

dropped this "note to self" :)

> ---
>  arch/arm/mach-davinci/dm365.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
> index 01843fbcc9ea..d26dc2b4339a 100644
> --- a/arch/arm/mach-davinci/dm365.c
> +++ b/arch/arm/mach-davinci/dm365.c
> @@ -17,6 +17,7 @@
>  #include <linux/serial_8250.h>
>  #include <linux/platform_device.h>
>  #include <linux/dma-mapping.h>
> +#include <linux/dmaengine.h>
>  #include <linux/spi/spi.h>
>  #include <linux/platform_data/edma.h>
>  #include <linux/platform_data/gpio-davinci.h>
> @@ -862,9 +863,30 @@ static s8 dm365_queue_priority_mapping[][2] = {
>  	{-1, -1},
>  };
>  
> +static const struct dma_slave_map da365_edma_map[] = {

This should be "dm365_edma_map".

Fixed both locally while applying.

Regards,
Sekhar


From ard.biesheuvel at linaro.org  Mon Feb 22 02:00:36 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 11:00:36 +0100
Subject: [PATCH 0/3] arm64 pt dumper changes
Message-ID: <1456135239-3607-1-git-send-email-ard.biesheuvel@linaro.org>

This series updates the kernel page table dumper to:
- not initialize the vmemmap region markers dynamically
- show region boundaries for the kasan shadow region
- include the UEFI runtime services mappings

Ard Biesheuvel (3):
  arm64: ptdump: use static initializers for vmemmap region boundaries
  arm64: ptdump: add region marker for kasan shadow region
  arm64: ptdump: include UEFI runtime service mappings

 arch/arm64/mm/dump.c               | 58 ++++++++------------
 drivers/firmware/efi/arm-runtime.c |  2 +-
 2 files changed, 24 insertions(+), 36 deletions(-)

-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 02:00:37 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 11:00:37 +0100
Subject: [PATCH 1/3] arm64: ptdump: use static initializers for vmemmap region
 boundaries
In-Reply-To: <1456135239-3607-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456135239-3607-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456135239-3607-2-git-send-email-ard.biesheuvel@linaro.org>

There is no need to initialize the vmemmap region boundaries dynamically,
since they are compile time constants. So just add these constants to the
global struct initializer, and drop the dynamic assignment and related code.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/mm/dump.c | 47 +++++---------------
 1 file changed, 12 insertions(+), 35 deletions(-)

diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index 6be918478f85..eadcb70e733c 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -34,37 +34,21 @@ struct addr_marker {
 	const char *name;
 };
 
-enum address_markers_idx {
-	MODULES_START_NR = 0,
-	MODULES_END_NR,
-	VMALLOC_START_NR,
-	VMALLOC_END_NR,
-#ifdef CONFIG_SPARSEMEM_VMEMMAP
-	VMEMMAP_START_NR,
-	VMEMMAP_END_NR,
-#endif
-	FIXADDR_START_NR,
-	FIXADDR_END_NR,
-	PCI_START_NR,
-	PCI_END_NR,
-	KERNEL_SPACE_NR,
-};
-
 static struct addr_marker address_markers[] = {
-	{ MODULES_VADDR,	"Modules start" },
-	{ MODULES_END,		"Modules end" },
-	{ VMALLOC_START,	"vmalloc() Area" },
-	{ VMALLOC_END,		"vmalloc() End" },
+	{ MODULES_VADDR,		"Modules start" },
+	{ MODULES_END,			"Modules end" },
+	{ VMALLOC_START,		"vmalloc() Area" },
+	{ VMALLOC_END,			"vmalloc() End" },
 #ifdef CONFIG_SPARSEMEM_VMEMMAP
-	{ 0,			"vmemmap start" },
-	{ 0,			"vmemmap end" },
+	{ (u64)vmemmap,			"vmemmap start" },
+	{ (u64)vmemmap + VMEMMAP_SIZE,	"vmemmap end" },
 #endif
-	{ FIXADDR_START,	"Fixmap start" },
-	{ FIXADDR_TOP,		"Fixmap end" },
-	{ PCI_IO_START,		"PCI I/O start" },
-	{ PCI_IO_END,		"PCI I/O end" },
-	{ PAGE_OFFSET,		"Linear Mapping" },
-	{ -1,			NULL },
+	{ FIXADDR_START,		"Fixmap start" },
+	{ FIXADDR_TOP,			"Fixmap end" },
+	{ PCI_IO_START,			"PCI I/O start" },
+	{ PCI_IO_END,			"PCI I/O end" },
+	{ PAGE_OFFSET,			"Linear Mapping" },
+	{ -1,				NULL },
 };
 
 /*
@@ -349,13 +333,6 @@ static int ptdump_init(void)
 			for (j = 0; j < pg_level[i].num; j++)
 				pg_level[i].mask |= pg_level[i].bits[j].mask;
 
-#ifdef CONFIG_SPARSEMEM_VMEMMAP
-	address_markers[VMEMMAP_START_NR].start_address =
-				(unsigned long)virt_to_page(PAGE_OFFSET);
-	address_markers[VMEMMAP_END_NR].start_address =
-				(unsigned long)virt_to_page(high_memory);
-#endif
-
 	pe = debugfs_create_file("kernel_page_tables", 0400, NULL, NULL,
 				 &ptdump_fops);
 	return pe ? 0 : -ENOMEM;
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 02:00:38 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 11:00:38 +0100
Subject: [PATCH 2/3] arm64: ptdump: add region marker for kasan shadow region
In-Reply-To: <1456135239-3607-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456135239-3607-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456135239-3607-3-git-send-email-ard.biesheuvel@linaro.org>

Annotate the KASAN shadow region with boundary markers, so that its
mappings stand out in the page table dumper output.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/mm/dump.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index eadcb70e733c..12e4b1732303 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -23,6 +23,7 @@
 #include <linux/seq_file.h>
 
 #include <asm/fixmap.h>
+#include <asm/kasan.h>
 #include <asm/memory.h>
 #include <asm/pgtable.h>
 #include <asm/pgtable-hwdef.h>
@@ -35,6 +36,10 @@ struct addr_marker {
 };
 
 static struct addr_marker address_markers[] = {
+#ifdef CONFIG_KASAN
+	{ KASAN_SHADOW_START,		"Kasan shadow start" },
+	{ KASAN_SHADOW_END,		"Kasan shadow end" },
+#endif
 	{ MODULES_VADDR,		"Modules start" },
 	{ MODULES_END,			"Modules end" },
 	{ VMALLOC_START,		"vmalloc() Area" },
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 02:00:39 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 11:00:39 +0100
Subject: [PATCH 3/3] arm64: ptdump: include UEFI runtime service mappings
In-Reply-To: <1456135239-3607-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456135239-3607-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456135239-3607-4-git-send-email-ard.biesheuvel@linaro.org>

This adds the UEFI runtime services page table mappings to the output
of the kernel page table dumper. These tables are only live during the
time UEFI runtime services are being invoked, but we can include them
for informational purposes nonetheless.

Cc: Matt Fleming <matt at codeblueprint.co.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/mm/dump.c               | 8 ++++++++
 drivers/firmware/efi/arm-runtime.c | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index 12e4b1732303..e7b937c9ad52 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -36,6 +36,10 @@ struct addr_marker {
 };
 
 static struct addr_marker address_markers[] = {
+#ifdef CONFIG_EFI
+	{ 0,				"UEFI runtime start" },
+	{ TASK_SIZE_64,			"UEFI runtime end" },
+#endif
 #ifdef CONFIG_KASAN
 	{ KASAN_SHADOW_START,		"Kasan shadow start" },
 	{ KASAN_SHADOW_END,		"Kasan shadow end" },
@@ -310,6 +314,10 @@ static int ptdump_show(struct seq_file *m, void *v)
 		.marker = address_markers,
 	};
 
+	if (IS_ENABLED(CONFIG_EFI)) {
+		extern struct mm_struct efi_mm;
+		walk_pgd(&st, &efi_mm, 0);
+	}
 	walk_pgd(&st, &init_mm, LOWEST_ADDR);
 
 	note_page(&st, 0, 0, 0);
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 6ae21e41a429..3a3911641049 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -30,7 +30,7 @@
 
 extern u64 efi_system_table;
 
-static struct mm_struct efi_mm = {
+struct mm_struct efi_mm = {
 	.mm_rb			= RB_ROOT,
 	.mm_users		= ATOMIC_INIT(2),
 	.mm_count		= ATOMIC_INIT(1),
-- 
2.5.0



From pankaj.dubey at samsung.com  Mon Feb 22 02:03:14 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Mon, 22 Feb 2016 15:33:14 +0530
Subject: [PATCH 1/3] ARM: EXYNOS: correct header comment in Kconfig file
In-Reply-To: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
References: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <1456135396-17767-2-git-send-email-pankaj.dubey@samsung.com>

This patch corrects header comment of Kconfig file by changing EXYNOS4 to
EXYNOS.

Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
---
 arch/arm/mach-exynos/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index eb26986..71ef48f 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -5,7 +5,7 @@
 #
 # Licensed under GPLv2
 
-# Configuration options for the EXYNOS4
+# Configuration options for the EXYNOS
 
 menuconfig ARCH_EXYNOS
 	bool "Samsung EXYNOS"
-- 
2.4.5



From pankaj.dubey at samsung.com  Mon Feb 22 02:03:16 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Mon, 22 Feb 2016 15:33:16 +0530
Subject: [PATCH 3/3] ARM: EXYNOS: cleanup header files inclusion
In-Reply-To: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
References: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <1456135396-17767-4-git-send-email-pankaj.dubey@samsung.com>

This includes trivial cleanup in exynos files such as
    - remove unused header files inclusion from exynos.c, s5p-dev-mfc.c,
      firmware.c, pm.c.
    - move inclusion of of.h from common.h to pm.c where it is really
      required

Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
---
 arch/arm/mach-exynos/common.h      | 1 -
 arch/arm/mach-exynos/exynos.c      | 5 -----
 arch/arm/mach-exynos/firmware.c    | 2 --
 arch/arm/mach-exynos/platsmp.c     | 1 -
 arch/arm/mach-exynos/pm.c          | 4 +---
 arch/arm/mach-exynos/s5p-dev-mfc.c | 1 -
 6 files changed, 1 insertion(+), 13 deletions(-)

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index e349a03..5365bf1 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -12,7 +12,6 @@
 #ifndef __ARCH_ARM_MACH_EXYNOS_COMMON_H
 #define __ARCH_ARM_MACH_EXYNOS_COMMON_H
 
-#include <linux/of.h>
 #include <linux/platform_data/cpuidle-exynos.h>
 
 #define EXYNOS3250_SOC_ID	0xE3472000
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 99947ad..54262a1 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -11,14 +11,10 @@
 
 #include <linux/init.h>
 #include <linux/io.h>
-#include <linux/kernel.h>
-#include <linux/serial_s3c.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_fdt.h>
 #include <linux/of_platform.h>
-#include <linux/platform_device.h>
-#include <linux/pm_domain.h>
 #include <linux/irqchip.h>
 #include <linux/soc/samsung/exynos-regs-pmu.h>
 
@@ -26,7 +22,6 @@
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
-#include <asm/memory.h>
 
 #include <mach/map.h>
 
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 111cfbf..1bfd1b0 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -20,8 +20,6 @@
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/suspend.h>
 
-#include <mach/map.h>
-
 #include "common.h"
 #include "smc.h"
 
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index da46c63..85c3be6 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -15,7 +15,6 @@
 #include <linux/init.h>
 #include <linux/errno.h>
 #include <linux/delay.h>
-#include <linux/device.h>
 #include <linux/jiffies.h>
 #include <linux/smp.h>
 #include <linux/io.h>
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index b9b9186..c43b776 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -17,7 +17,7 @@
 #include <linux/suspend.h>
 #include <linux/cpu_pm.h>
 #include <linux/io.h>
-#include <linux/err.h>
+#include <linux/of.h>
 #include <linux/soc/samsung/exynos-regs-pmu.h>
 #include <linux/soc/samsung/exynos-pmu.h>
 
@@ -28,8 +28,6 @@
 
 #include <mach/map.h>
 
-#include <plat/pm-common.h>
-
 #include "common.h"
 
 static inline void __iomem *exynos_boot_vector_addr(void)
diff --git a/arch/arm/mach-exynos/s5p-dev-mfc.c b/arch/arm/mach-exynos/s5p-dev-mfc.c
index 0b04b6b..8ef1f3e 100644
--- a/arch/arm/mach-exynos/s5p-dev-mfc.c
+++ b/arch/arm/mach-exynos/s5p-dev-mfc.c
@@ -9,7 +9,6 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/interrupt.h>
 #include <linux/platform_device.h>
 #include <linux/dma-mapping.h>
 #include <linux/memblock.h>
-- 
2.4.5



From lkp at intel.com  Mon Feb 22 02:01:43 2016
From: lkp at intel.com (kbuild test robot)
Date: Mon, 22 Feb 2016 18:01:43 +0800
Subject: [PATCH v9 2/6] clk: hisilicon: add CRG driver for hi3519 soc
In-Reply-To: <1456127280-23275-3-git-send-email-xuejiancheng@huawei.com>
Message-ID: <201602221742.MKAlpbcd%fengguang.wu@intel.com>

Hi Jiancheng,

[auto build test WARNING on clk/clk-next]
[also build test WARNING on v4.5-rc5 next-20160222]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Jiancheng-Xue/ARM-hisi-Add-initial-support-including-clock-driver-for-Hi3519-soc/20160222-160736
base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: xtensa-allyesconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

warning: (COMMON_CLK_HI3519) selects RESET_HISI which has unmet direct dependencies (COMMON_CLK && ARCH_HISI)

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 44077 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160222/e99643f5/attachment-0001.obj>

From pankaj.dubey at samsung.com  Mon Feb 22 02:03:13 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Mon, 22 Feb 2016 15:33:13 +0530
Subject: [PATCH 0/3] ARM: EXYNOS: Trivial cleanup in mach-exynos
Message-ID: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>

This patch series cleans up mach-exynos files with resepct to unused header file inclusion,
leftover redundant register offset definition. Also corrects comment section at few places.

Pankaj Dubey (3):
  ARM: EXYNOS: correct header comment in Kconfig file
  ARM: EXYNOS: remove unused register offset definition
  ARM: EXYNOS: cleanup header files inclusion

 arch/arm/mach-exynos/Kconfig            | 2 +-
 arch/arm/mach-exynos/common.h           | 1 -
 arch/arm/mach-exynos/exynos.c           | 5 -----
 arch/arm/mach-exynos/firmware.c         | 2 --
 arch/arm/mach-exynos/include/mach/map.h | 9 +--------
 arch/arm/mach-exynos/platsmp.c          | 1 -
 arch/arm/mach-exynos/pm.c               | 4 +---
 arch/arm/mach-exynos/s5p-dev-mfc.c      | 1 -
 8 files changed, 3 insertions(+), 22 deletions(-)

-- 
2.4.5



From pankaj.dubey at samsung.com  Mon Feb 22 02:03:15 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Mon, 22 Feb 2016 15:33:15 +0530
Subject: [PATCH 2/3] ARM: EXYNOS: remove unused register offset definition
In-Reply-To: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
References: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <1456135396-17767-3-git-send-email-pankaj.dubey@samsung.com>

This patch cleans up map.h by removing unused register offset
and changing EXYNOS4 to EXYNOS in header comment section.

Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
---
 arch/arm/mach-exynos/include/mach/map.h | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
index 351e839..c48ba4f 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -2,7 +2,7 @@
  * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
  *		http://www.samsung.com/
  *
- * EXYNOS4 - Memory map definitions
+ * EXYNOS - Memory map definitions
  *
  * 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
@@ -14,12 +14,6 @@
 
 #include <plat/map-base.h>
 
-/*
- * EXYNOS4 UART offset is 0x10000 but the older S5P SoCs are 0x400.
- * So need to define it, and here is to avoid redefinition warning.
- */
-#define S3C_UART_OFFSET			(0x10000)
-
 #include <plat/map-s5p.h>
 
 #define EXYNOS_PA_CHIPID		0x10000000
@@ -30,6 +24,5 @@
 #define EXYNOS4_PA_DMC1			0x10410000
 
 #define EXYNOS4_PA_COREPERI		0x10500000
-#define EXYNOS4_PA_L2CC			0x10502000
 
 #endif /* __ASM_ARCH_MAP_H */
-- 
2.4.5



From nsekhar at ti.com  Mon Feb 22 02:07:22 2016
From: nsekhar at ti.com (Sekhar Nori)
Date: Mon, 22 Feb 2016 15:37:22 +0530
Subject: [PATCH 3/5] ARM: davinci: dm365: Add dma_slave_map to edma
In-Reply-To: <56CADBB1.9040908@ti.com>
References: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>
 <1454416997-14230-4-git-send-email-peter.ujfalusi@ti.com>
 <56CADBB1.9040908@ti.com>
Message-ID: <56CADDDA.5070402@ti.com>

On Monday 22 February 2016 03:28 PM, Sekhar Nori wrote:
> On Tuesday 02 February 2016 06:13 PM, Peter Ujfalusi wrote:
>> Provide the dma_slave_map to edma which will allow us to move the drivers
>> to the new, simpler dmaengine API and we can remove the DMA resources also
>> for the devices.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> 
>> FIX: dm365
> 
> dropped this "note to self" :)
> 
>> ---
>>  arch/arm/mach-davinci/dm365.c | 22 ++++++++++++++++++++++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
>> index 01843fbcc9ea..d26dc2b4339a 100644
>> --- a/arch/arm/mach-davinci/dm365.c
>> +++ b/arch/arm/mach-davinci/dm365.c
>> @@ -17,6 +17,7 @@
>>  #include <linux/serial_8250.h>
>>  #include <linux/platform_device.h>
>>  #include <linux/dma-mapping.h>
>> +#include <linux/dmaengine.h>
>>  #include <linux/spi/spi.h>
>>  #include <linux/platform_data/edma.h>
>>  #include <linux/platform_data/gpio-davinci.h>
>> @@ -862,9 +863,30 @@ static s8 dm365_queue_priority_mapping[][2] = {
>>  	{-1, -1},
>>  };
>>  
>> +static const struct dma_slave_map da365_edma_map[] = {
> 
> This should be "dm365_edma_map".
> 
> Fixed both locally while applying.

Similar fixes needed on patches 2,4,5 as well. Made those too.

Thanks,
Sekhar


From broonie at kernel.org  Mon Feb 22 02:08:32 2016
From: broonie at kernel.org (Mark Brown)
Date: Mon, 22 Feb 2016 19:08:32 +0900
Subject: next-20160222 build: 5 failures 9 warnings (next-20160222)
In-Reply-To: <E1aXlz4-000486-Pb@optimist>
References: <E1aXlz4-000486-Pb@optimist>
Message-ID: <20160222100832.GX18327@sirena.org.uk>

On Mon, Feb 22, 2016 at 08:36:46AM +0000, Build bot for Mark Brown wrote:

Today's -next fails to build on arm64 due to:

> 	arm64-allnoconfig
> ../arch/arm64/include/asm/kvm_host.h:338:2: error: implicit declaration of function 'kvm_call_hyp' [-Werror=implicit-function-declaration]
> 
> 	arm64-allmodconfig
> ../arch/arm64/include/asm/kvm_host.h:338:2: error: implicit declaration of function 'kvm_call_hyp' [-Werror=implicit-function-declaration]

> 	arm64-defconfig
> ../arch/arm64/include/asm/kvm_host.h:338:2: error: implicit declaration of function 'kvm_call_hyp' [-Werror=implicit-function-declaration]

triggered by the merge of the kvm-arm tree with -next today, it looks
like changes in that tree and arm64 aren't playing nicely with each
other (bisect came down to the merge and visual inspection of the
changes didn't immediately show anything else though the issue is
obvious in the code).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160222/c72925ef/attachment.sig>

From jonathanh at nvidia.com  Mon Feb 22 02:16:06 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Mon, 22 Feb 2016 10:16:06 +0000
Subject: Tegra baseline test results for v4.5-rc4
Message-ID: <56CADFE6.8040605@nvidia.com>

Here are some basic Tegra test results for Linux v4.5-rc4.
Logs and other details at:

    https://nvtb.github.io//linux/test_v4.5-rc4/20160214133102/


Test summary
------------

Build: zImage:
    Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig

Build: Image:
    Pass: ( 1/ 1): defconfig

Boot to userspace: defconfig:
    Pass: ( 3/ 3): qemu-vexpress64, tegra132-norrin,
		   tegra210-p2371-0000

Boot to userspace: multi_v7_defconfig:
    Pass: ( 4/ 4): tegra114-dalmore-a04, tegra124-jetson-tk1,
		   tegra20-trimslice, tegra30-beaver

Boot to userspace: tegra_defconfig:
    Pass: ( 4/ 4): tegra114-dalmore-a04, tegra124-jetson-tk1,
		   tegra20-trimslice, tegra30-beaver

PM: System suspend: multi_v7_defconfig:
    FAIL: ( 1/ 4): tegra114-dalmore-a04
    Pass: ( 3/ 4): tegra124-jetson-tk1, tegra20-trimslice,
		   tegra30-beaver

PM: System suspend: tegra_defconfig:
    FAIL: ( 1/ 4): tegra114-dalmore-a04
    Pass: ( 3/ 4): tegra124-jetson-tk1, tegra20-trimslice,
		   tegra30-beaver


vmlinux object size
(delta in bytes from test_v4.5-rc3 (388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95)):
   text     data      bss    total  kernel
  +4113    -4064     +128     +177  defconfig
  +5326     +128      +64    +5518  multi_v7_defconfig
  +1224     +184        0    +1408  tegra_defconfig


Boot-time memory difference
(delta in bytes from test_v4.5-rc3 (388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95))
    avail    rsrvd     high    freed                board              kconfig                  dtb
        .        .        .        .      qemu-vexpress64            defconfig           __internal
        .        .        .      -4k tegra114-dalmore-a04   multi_v7_defconfig     tegra114-dalmore
        .        .        .        . tegra114-dalmore-a04      tegra_defconfig     tegra114-dalmore
        .        .        .      -4k  tegra124-jetson-tk1   multi_v7_defconfig  tegra124-jetson-tk1
        .        .        .        .  tegra124-jetson-tk1      tegra_defconfig  tegra124-jetson-tk1
        .        .        .        .      tegra132-norrin            defconfig      tegra132-norrin
        .        .        .      -4k    tegra20-trimslice   multi_v7_defconfig    tegra20-trimslice
        .        .        .        .    tegra20-trimslice      tegra_defconfig    tegra20-trimslice
        .        .        .        .  tegra210-p2371-0000            defconfig  tegra210-p2371-0000
        .        .        .      -4k       tegra30-beaver   multi_v7_defconfig       tegra30-beaver
        .        .        .        .       tegra30-beaver      tegra_defconfig       tegra30-beaver


From broonie at kernel.org  Mon Feb 22 02:19:18 2016
From: broonie at kernel.org (Mark Brown)
Date: Mon, 22 Feb 2016 19:19:18 +0900
Subject: next-20160222 build: 5 failures 9 warnings (next-20160222)
In-Reply-To: <E1aXlz4-000486-Pb@optimist>
References: <E1aXlz4-000486-Pb@optimist>
Message-ID: <20160222101918.GY18327@sirena.org.uk>

On Mon, Feb 22, 2016 at 08:36:46AM +0000, Build bot for Mark Brown wrote:

Today's -next fails to build an arm allmodconfig due to:

> 	arm-allmodconfig
> ../drivers/net/ethernet/ti/netcp_core.c:1846:31: error: invalid type argument of '->' (have 'struct tc_to_netdev')
> ../drivers/net/ethernet/ti/netcp_core.c:1851:35: error: invalid type argument of '->' (have 'struct tc_to_netdev')
> ../drivers/net/ethernet/ti/netcp_core.c:1855:8: error: invalid type argument of '->' (have 'struct tc_to_netdev')
> ../drivers/net/ethernet/ti/netcp_core.c:1856:28: error: invalid type argument of '->' (have 'struct tc_to_netdev')
> ../drivers/net/ethernet/ti/netcp_core.c:1857:21: error: invalid type argument of '->' (have 'struct tc_to_netdev')

caused by commit 16e5cc647173a (net: rework setup_tc ndo op to consume
general tc operand) in the net-next tree which looks to have a missing *
in the rewrite of the function arguments for that driver.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160222/87ece996/attachment-0001.sig>

From srinivas.kandagatla at linaro.org  Mon Feb 22 02:20:13 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Mon, 22 Feb 2016 10:20:13 +0000
Subject: [PATCH v2 2/8] arm64: dts: qcom: apq8016-sbc: add usb support
In-Reply-To: <20160222055124.GG21240@tuxbot>
References: <1455104164-29356-1-git-send-email-srinivas.kandagatla@linaro.org>
 <1455104202-10560-1-git-send-email-srinivas.kandagatla@linaro.org>
 <20160222055124.GG21240@tuxbot>
Message-ID: <56CAE0DD.304@linaro.org>

Thanks for the review,

On 22/02/16 05:51, Bjorn Andersson wrote:
> On Wed 10 Feb 03:36 PST 2016, Srinivas Kandagatla wrote:
>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
>> ---
>>   arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi | 15 ++++++++++
>>   arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi          | 35 ++++++++++++++++++++++
>>   2 files changed, 50 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
>> index cbeee0b..4a79dd9 100644
>> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
>> @@ -10,4 +10,19 @@
>>   			output-low;
>>   		};
>>   	};
>> +
>> +	usb_id_default: usb_id_default {
>
> Labels are built with _, node names with -.
>
>> +		pinmux {
>> +			function = "gpio";
>> +			pins = "gpio121";
>> +		};
>
> You don't need a separate node to specify function...
>
>> +
>> +		pinconf {
>> +			pins = "gpio121";
>> +			function = "gpio";
>
> ...but if you really want it, then you shouldn't specify the function
> here.
Oops, Will remove this and resend the patch.
>
>> +			drive-strength = <8>;
>> +			input-enable;
>> +			bias-pull-up;
>> +		};
>> +	};
>>   };
>> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> [..]
>> +
>> +	usb_id: usb-id {
>> +		interrupt-parent = <&msmgpio>;
>
> interrupt-parent is part of specifying an interrupt. You're not doing
> that here, so no need to specify a parent.
Yep, will clean this up in next version.
>
>> +		compatible = "linux,extcon-usb-gpio";
>> +		id-gpio = <&msmgpio 121 GPIO_ACTIVE_HIGH>;
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&usb_id_default>;
>>   	};
>>   };
>
> Apart from these two nits
>
> Acked-by: Bjorn Andersson <bjorn.andersson at linaro.org>

Thanks,
srini
>
> Regards,
> Bjorn
>


From jonathanh at nvidia.com  Mon Feb 22 02:23:46 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Mon, 22 Feb 2016 10:23:46 +0000
Subject: Tegra baseline test results for v4.5-rc4
In-Reply-To: <56CADFE6.8040605@nvidia.com>
References: <56CADFE6.8040605@nvidia.com>
Message-ID: <56CAE1B2.20402@nvidia.com>


On 22/02/16 10:16, Jon Hunter wrote:
> Here are some basic Tegra test results for Linux v4.5-rc4.
> Logs and other details at:
> 
>     https://nvtb.github.io//linux/test_v4.5-rc4/20160214133102/
> 
> 
> Test summary
> ------------
> 
> Build: zImage:
>     Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig
> 
> Build: Image:
>     Pass: ( 1/ 1): defconfig
> 
> Boot to userspace: defconfig:
>     Pass: ( 3/ 3): qemu-vexpress64, tegra132-norrin,
> 		   tegra210-p2371-0000
> 
> Boot to userspace: multi_v7_defconfig:
>     Pass: ( 4/ 4): tegra114-dalmore-a04, tegra124-jetson-tk1,
> 		   tegra20-trimslice, tegra30-beaver
> 
> Boot to userspace: tegra_defconfig:
>     Pass: ( 4/ 4): tegra114-dalmore-a04, tegra124-jetson-tk1,
> 		   tegra20-trimslice, tegra30-beaver
> 
> PM: System suspend: multi_v7_defconfig:
>     FAIL: ( 1/ 4): tegra114-dalmore-a04
>     Pass: ( 3/ 4): tegra124-jetson-tk1, tegra20-trimslice,
> 		   tegra30-beaver
> 
> PM: System suspend: tegra_defconfig:
>     FAIL: ( 1/ 4): tegra114-dalmore-a04
>     Pass: ( 3/ 4): tegra124-jetson-tk1, tegra20-trimslice,
> 		   tegra30-beaver

Between 4.5-rc3 and 4.5-rc4 a SD card has been inserted into the
Tegra114-dalmore and with the SD card present, system suspend is now
failing. After performing more testing, it appears that system suspend
on the Tegra114-dalmore (with an SD card present) has been broken
between v4.4 and v4.5-rc1 following some changes to enable UHS-I modes
for Tegra. A patch is in the works to disable these modes for Tegra114
[0] and allows suspend to work again.

Jon

[0] http://marc.info/?l=linux-tegra&m=145580693311178&w=2


From jonathanh at nvidia.com  Mon Feb 22 02:23:58 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Mon, 22 Feb 2016 10:23:58 +0000
Subject: Tegra baseline test results for v4.5-rc5
Message-ID: <56CAE1BE.6000602@nvidia.com>

Here are some basic Tegra test results for Linux v4.5-rc5.
Logs and other details at:

    https://nvtb.github.io//linux/test_v4.5-rc5/20160220140102/


Test summary
------------

Build: zImage:
    Pass: ( 2/ 2): multi_v7_defconfig, tegra_defconfig

Build: Image:
    Pass: ( 1/ 1): defconfig

Boot to userspace: defconfig:
    Pass: ( 3/ 3): qemu-vexpress64, tegra132-norrin,
		   tegra210-p2371-0000

Boot to userspace: multi_v7_defconfig:
    Pass: ( 4/ 4): tegra114-dalmore-a04, tegra124-jetson-tk1,
		   tegra20-trimslice, tegra30-beaver

Boot to userspace: tegra_defconfig:
    Pass: ( 4/ 4): tegra114-dalmore-a04, tegra124-jetson-tk1,
		   tegra20-trimslice, tegra30-beaver

PM: System suspend: multi_v7_defconfig:
    FAIL: ( 1/ 4): tegra114-dalmore-a04
    Pass: ( 3/ 4): tegra124-jetson-tk1, tegra20-trimslice,
		   tegra30-beaver

PM: System suspend: tegra_defconfig:
    FAIL: ( 1/ 4): tegra114-dalmore-a04
    Pass: ( 3/ 4): tegra124-jetson-tk1, tegra20-trimslice,
		   tegra30-beaver


vmlinux object size
(delta in bytes from test_v4.5-rc4 (18558cae0272f8fd9647e69d3fec1565a7949865)):
   text     data      bss    total  kernel
    +60     +512     +128     +700  defconfig
  +1596     +224        0    +1820  multi_v7_defconfig
  +1320     +232        0    +1552  tegra_defconfig


Boot-time memory difference
(delta in bytes from test_v4.5-rc4 (18558cae0272f8fd9647e69d3fec1565a7949865))
    avail    rsrvd     high    freed                board              kconfig                  dtb
        .        .        .        .      qemu-vexpress64            defconfig           __internal
      -8k       8k        .       4k tegra114-dalmore-a04   multi_v7_defconfig     tegra114-dalmore
        .        .        .        . tegra114-dalmore-a04      tegra_defconfig     tegra114-dalmore
      -8k       8k        .       4k  tegra124-jetson-tk1   multi_v7_defconfig  tegra124-jetson-tk1
        .        .        .        .  tegra124-jetson-tk1      tegra_defconfig  tegra124-jetson-tk1
        .        .        .        .      tegra132-norrin            defconfig      tegra132-norrin
      -8k       8k        .       4k    tegra20-trimslice   multi_v7_defconfig    tegra20-trimslice
        .        .        .        .    tegra20-trimslice      tegra_defconfig    tegra20-trimslice
        .        .        .        .  tegra210-p2371-0000            defconfig  tegra210-p2371-0000
      -8k       8k        .       4k       tegra30-beaver   multi_v7_defconfig       tegra30-beaver
        .        .        .        .       tegra30-beaver      tegra_defconfig       tegra30-beaver


From broonie at kernel.org  Mon Feb 22 02:25:42 2016
From: broonie at kernel.org (Mark Brown)
Date: Mon, 22 Feb 2016 19:25:42 +0900
Subject: next-20160222 build: 5 failures 9 warnings (next-20160222)
In-Reply-To: <E1aXlz4-000486-Pb@optimist>
References: <E1aXlz4-000486-Pb@optimist>
Message-ID: <20160222102542.GZ18327@sirena.org.uk>

On Mon, Feb 22, 2016 at 08:36:46AM +0000, Build bot for Mark Brown wrote:

For the past few days -next has been failing to build an arm
allmodconfig due to:

> 	arm-allmodconfig
> ../arch/arm/kernel/hyp-stub.S:168: Error: selected processor does not support ARM mode `ubfx r7,r7,#28,#4'
> ../arch/arm/kernel/hyp-stub.S:176: Error: selected processor does not support ARM mode `isb'

caused by e59941b9b3817c (ARM: 8527/1: virt: enable GICv3 system
registers) in the ARM tree.  My hot take is that it looks like
CONFIG_ARM_GIC_V3 needs tighter dependencies so it can't get enabled for
a v6 system but I could be wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160222/9736c9c3/attachment.sig>

From p.zabel at pengutronix.de  Mon Feb 22 02:27:56 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Mon, 22 Feb 2016 11:27:56 +0100
Subject: [PATCH] reset: lpc18xx: get rid of global variables for restart
 notifier
In-Reply-To: <1455995209-5213-1-git-send-email-manabian@gmail.com>
References: <1455995209-5213-1-git-send-email-manabian@gmail.com>
Message-ID: <1456136876.5148.25.camel@pengutronix.de>

Hi Joachim,

Am Samstag, den 20.02.2016, 20:06 +0100 schrieb Joachim Eastwood:
> Moving the notifier_block into the drivers priv struct allows us
> to retrive the priv struct with container_of and remove the
> global variables.
> 
> Signed-off-by: Joachim Eastwood <manabian at gmail.com>
> ---
> Hi Philipp,
> 
> Just a simple clean up patch for lpc18xx reset controller.

Thanks, applied to reset/next.

regards
Philipp



From ard.biesheuvel at linaro.org  Mon Feb 22 02:28:55 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 11:28:55 +0100
Subject: [PATCH v3 2/2] arm64: Mark kernel page ranges contiguous
In-Reply-To: <1455903983-23910-3-git-send-email-jeremy.linton@arm.com>
References: <1455903983-23910-1-git-send-email-jeremy.linton@arm.com>
 <1455903983-23910-3-git-send-email-jeremy.linton@arm.com>
Message-ID: <CAKv+Gu8YYuE78QAzgFFZgPOz4o_4L70Ko-vO-GKwSFeYdNv+vA@mail.gmail.com>

On 19 February 2016 at 18:46, Jeremy Linton <jeremy.linton at arm.com> wrote:
> With 64k pages, the next larger segment size is 512M. The linux
> kernel also uses different protection flags to cover its code and data.
> Because of these requirements, the vast majority of the kernel code and
> data structures end up being mapped with 64k pages instead of the larger
> pages common with a 4k page kernel.
>
> Recent ARM processors support a contiguous bit in the
> page tables which allows a TLB to cover a range larger than a
> single PTE if that range is mapped into physically contiguous
> RAM.
>
> So, for the kernel its a good idea to set this flag. Some basic
> micro benchmarks show it can significantly reduce the number of
> L1 dTLB refills.
>
> Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>

Tested on 4k/3 levels, and the page tables look correct to me

Tested-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

You didn't answer my question though, regarding implementing this at
the PMD level for 16k pages kernels, so that we can use 1 GB chunks
for mapping system RAM. Would that just be a matter of doing the exact
same thing at the PMD level? Or is it more complicated than that?

-- 
Ard.

> ---
>  arch/arm64/mm/mmu.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 58 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 7711554..ab69a99 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1,3 +1,4 @@
> +
>  /*
>   * Based on arch/arm/mm/mmu.c
>   *
> @@ -103,17 +104,49 @@ static void split_pmd(pmd_t *pmd, pte_t *pte)
>                  * Need to have the least restrictive permissions available
>                  * permissions will be fixed up later
>                  */
> -               set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC));
> +               set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC_CONT));
>                 pfn++;
>         } while (pte++, i++, i < PTRS_PER_PTE);
>  }
>
> +static void clear_cont_pte_range(pte_t *pte, unsigned long addr)
> +{
> +       int i;
> +
> +       pte -= CONT_RANGE_OFFSET(addr);
> +       for (i = 0; i < CONT_PTES; i++) {
> +               if (pte_cont(*pte))
> +                       set_pte(pte, pte_mknoncont(*pte));
> +               pte++;
> +       }
> +       flush_tlb_all();
> +}
> +
> +/*
> + * Given a range of PTEs set the pfn and provided page protection flags
> + */
> +static void __populate_init_pte(pte_t *pte, unsigned long addr,
> +                              unsigned long end, phys_addr_t phys,
> +                              pgprot_t prot)
> +{
> +       unsigned long pfn = __phys_to_pfn(phys);
> +
> +       do {
> +               /* clear all the bits except the pfn, then apply the prot */
> +               set_pte(pte, pfn_pte(pfn, prot));
> +               pte++;
> +               pfn++;
> +               addr += PAGE_SIZE;
> +       } while (addr != end);
> +}
> +
>  static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
> -                                 unsigned long end, unsigned long pfn,
> +                                 unsigned long end, phys_addr_t phys,
>                                   pgprot_t prot,
>                                   phys_addr_t (*pgtable_alloc)(void))
>  {
>         pte_t *pte;
> +       unsigned long next;
>
>         if (pmd_none(*pmd) || pmd_sect(*pmd)) {
>                 phys_addr_t pte_phys = pgtable_alloc();
> @@ -127,10 +160,29 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
>         BUG_ON(pmd_bad(*pmd));
>
>         pte = pte_set_fixmap_offset(pmd, addr);
> +
>         do {
> -               set_pte(pte, pfn_pte(pfn, prot));
> -               pfn++;
> -       } while (pte++, addr += PAGE_SIZE, addr != end);
> +               next = min(end, (addr + CONT_SIZE) & CONT_MASK);
> +               if (((addr | next | phys) & ~CONT_MASK) == 0) {
> +                       /* a block of CONT_PTES  */
> +                       __populate_init_pte(pte, addr, next, phys,
> +                                           prot | __pgprot(PTE_CONT));
> +               } else {
> +                       /*
> +                        * If the range being split is already inside of a
> +                        * contiguous range but this PTE isn't going to be
> +                        * contiguous, then we want to unmark the adjacent
> +                        * ranges, then update the portion of the range we
> +                        * are interrested in.
> +                        */
> +                       clear_cont_pte_range(pte, addr);
> +                       __populate_init_pte(pte, addr, next, phys, prot);
> +               }
> +
> +               pte += (next - addr) >> PAGE_SHIFT;
> +               phys += next - addr;
> +               addr = next;
> +       } while (addr != end);
>
>         pte_clear_fixmap();
>  }
> @@ -194,7 +246,7 @@ static void alloc_init_pmd(pud_t *pud, unsigned long addr, unsigned long end,
>                                 }
>                         }
>                 } else {
> -                       alloc_init_pte(pmd, addr, next, __phys_to_pfn(phys),
> +                       alloc_init_pte(pmd, addr, next, phys,
>                                        prot, pgtable_alloc);
>                 }
>                 phys += next - addr;
> --
> 2.4.3
>


From Jean-Philippe.Brucker at arm.com  Mon Feb 22 02:37:26 2016
From: Jean-Philippe.Brucker at arm.com (Jean-Philippe Brucker)
Date: Mon, 22 Feb 2016 10:37:26 +0000
Subject: next-20160222 build: 5 failures 9 warnings (next-20160222)
In-Reply-To: <20160222102542.GZ18327@sirena.org.uk>
References: <E1aXlz4-000486-Pb@optimist> <20160222102542.GZ18327@sirena.org.uk>
Message-ID: <20160222103725.GA5163@e106794-lin.cambridge.arm.com>

Mark,

On Mon, Feb 22, 2016 at 07:25:42PM +0900, Mark Brown wrote:
> On Mon, Feb 22, 2016 at 08:36:46AM +0000, Build bot for Mark Brown wrote:
> 
> For the past few days -next has been failing to build an arm
> allmodconfig due to:
> 
> > 	arm-allmodconfig
> > ../arch/arm/kernel/hyp-stub.S:168: Error: selected processor does not support ARM mode `ubfx r7,r7,#28,#4'
> > ../arch/arm/kernel/hyp-stub.S:176: Error: selected processor does not support ARM mode `isb'
> 
> caused by e59941b9b3817c (ARM: 8527/1: virt: enable GICv3 system
> registers) in the ARM tree.  My hot take is that it looks like
> CONFIG_ARM_GIC_V3 needs tighter dependencies so it can't get enabled for
> a v6 system but I could be wrong.

Thanks for the report. A fix is already in Russell's patch system [1],
and should be applied shortly.

Thanks,
Jean-Philippe

[1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8534/1


From marc.zyngier at arm.com  Mon Feb 22 02:41:42 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 22 Feb 2016 10:41:42 +0000
Subject: next-20160222 build: 5 failures 9 warnings (next-20160222)
In-Reply-To: <20160222100832.GX18327@sirena.org.uk>
References: <E1aXlz4-000486-Pb@optimist> <20160222100832.GX18327@sirena.org.uk>
Message-ID: <56CAE5E6.7030707@arm.com>

On 22/02/16 10:08, Mark Brown wrote:
> On Mon, Feb 22, 2016 at 08:36:46AM +0000, Build bot for Mark Brown wrote:
> 
> Today's -next fails to build on arm64 due to:
> 
>> 	arm64-allnoconfig
>> ../arch/arm64/include/asm/kvm_host.h:338:2: error: implicit declaration of function 'kvm_call_hyp' [-Werror=implicit-function-declaration]
>>
>> 	arm64-allmodconfig
>> ../arch/arm64/include/asm/kvm_host.h:338:2: error: implicit declaration of function 'kvm_call_hyp' [-Werror=implicit-function-declaration]
> 
>> 	arm64-defconfig
>> ../arch/arm64/include/asm/kvm_host.h:338:2: error: implicit declaration of function 'kvm_call_hyp' [-Werror=implicit-function-declaration]
> 
> triggered by the merge of the kvm-arm tree with -next today, it looks
> like changes in that tree and arm64 aren't playing nicely with each
> other (bisect came down to the merge and visual inspection of the
> changes didn't immediately show anything else though the issue is
> obvious in the code).

I'm about to push the following patch on top of the KVM tree:

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 43688d9..31fe7d6 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -333,11 +333,6 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
 		     hyp_stack_ptr, vector_ptr);
 }
 
-static inline void __cpu_init_stage2(void)
-{
-	kvm_call_hyp(__init_stage2_translation);
-}
-
 static inline void kvm_arch_hardware_disable(void) {}
 static inline void kvm_arch_hardware_unsetup(void) {}
 static inline void kvm_arch_sync_events(struct kvm *kvm) {}
@@ -349,4 +344,11 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_clear_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu);
 
+/* #define kvm_call_hyp(f, ...) __kvm_call_hyp(kvm_ksym_ref(f), ##__VA_ARGS__) */
+
+static inline void __cpu_init_stage2(void)
+{
+	kvm_call_hyp(__init_stage2_translation);
+}
+
 #endif /* __ARM64_KVM_HOST_H__ */

This will create a new conflict, but will make the resolution 100% clear.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From ilya at compulab.co.il  Mon Feb 22 02:53:14 2016
From: ilya at compulab.co.il (Ilya Ledvich)
Date: Mon, 22 Feb 2016 12:53:14 +0200
Subject: iMX7d cpu1 issue
In-Reply-To: <CAOMZO5Aa+veHWQCrKGz4rsvmjKWiitd81D8ncGnX8Fdk0aYe7Q@mail.gmail.com>
References: <56C2D63F.1030408@compulab.co.il> <20160218140913.GY6756@tiger>
 <AMSPR04MB263D00A3F8D9A8D9D3A536D88AF0@AMSPR04MB263.eurprd04.prod.outlook.com>
 <56C5F4D7.1070704@compulab.co.il>
 <AMSPR04MB26334EB884FA8A4B565278188AF0@AMSPR04MB263.eurprd04.prod.outlook.com>
 <56C6CE36.6040503@compulab.co.il>
 <CAOMZO5Aa+veHWQCrKGz4rsvmjKWiitd81D8ncGnX8Fdk0aYe7Q@mail.gmail.com>
Message-ID: <56CAE89A.9070100@compulab.co.il>

Hi Fabio,
To the best of my understanding imx7d SMP support is missing in the 
mainline kernel.
I currently use Freescale git repo 
git://git.freescale.com/imx/linux-2.6-imx.git, branch imx_3.14.52_1.1.0_ga.
Kind regards,
Ilya.

On 02/21/2016 05:22 PM, Fabio Estevam wrote:
> Hi Ilya/Frank,
>
> On Fri, Feb 19, 2016 at 6:11 AM, Ilya Ledvich <ilya at compulab.co.il> wrote:
>> Hi Frank,
>> Thank you for so brilliant suggestion!!!
>>
>>> #define CONFIG_MX7_SEC
>>
>>
>> Seems it works!
>> The  CPU1 is brought up, and kernel can successfully boot!
>
> I changed U-boot as suggested:
>
> --- a/include/configs/mx7_common.h
> +++ b/include/configs/mx7_common.h
> @@ -94,10 +94,7 @@
>   #define CONFIG_CMD_FUSE
>   #define CONFIG_MXC_OCOTP
>
> -/*
> - * Default boot linux kernel in no secure mode.
> - * If want to boot kernel in secure mode, please define CONFIG_MX7_SEC
> - */
> +#define CONFIG_MX7_SEC
>   #ifndef CONFIG_MX7_SEC
>   #define CONFIG_ARMV7_NONSEC
>   #define CONFIG_ARMV7_PSCI
>
>
> but still see only one core brought up in the kernel:
>
> [    0.003051] /cpus/cpu at 0 missing clock-frequency property
> [    0.003076] /cpus/cpu at 1 missing clock-frequency property
> [    0.003092] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> [    0.003157] Setting up static identity map for 0x80008280 - 0x800082f0
> [    0.005152] Brought up 1 CPUs
> [    0.005169] SMP: Total of 1 processors activated (48.00 BogoMIPS).
>
> I am booting 4.5-rc5 on a imx7d-sdb board.
>
> Any ideas on how to bring up the second core?
>


From jitao.shi at mediatek.com  Mon Feb 22 03:01:43 2016
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Mon, 22 Feb 2016 19:01:43 +0800
Subject: [PATCH v2 1/2] dt-bindings: Add LG lp120up1 panel bindings
Message-ID: <1456138904-15258-1-git-send-email-jitao.shi@mediatek.com>

Add documentation for lp120up1 panel

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
Acked-by: Rob Herring <robh at kernel.org>
---
Changes since v1:
 - add Acked-by: Rob Herring <robh at kernel.org>
---
 .../bindings/display/panel/lg,lp120up1.txt         |    7 +++++++
 1 file changed, 7 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt

diff --git a/Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt b/Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt
new file mode 100644
index 0000000..8c5de69
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt
@@ -0,0 +1,7 @@
+LG 12.0" (1920x1280 pixels) TFT LCD panel
+
+Required properties:
+- compatible: should be "lg,lp120up1"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
1.7.9.5



From jitao.shi at mediatek.com  Mon Feb 22 03:01:44 2016
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Mon, 22 Feb 2016 19:01:44 +0800
Subject: [PATCH v2 2/2] drm/panel: Support for LG lp120up1 panel with eDP input
In-Reply-To: <1456138904-15258-1-git-send-email-jitao.shi@mediatek.com>
References: <1456138904-15258-1-git-send-email-jitao.shi@mediatek.com>
Message-ID: <1456138904-15258-2-git-send-email-jitao.shi@mediatek.com>

The LG lp120up1 TFT LCD panel with eDP interface is a 12.0" 1920x1280
panel, which can be supported by the simple panel driver

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
---
Changes since v1:
 - Add eDP panel type in comment msg
 - Fixed comment msg with 72 characters width
---
 drivers/gpu/drm/panel/panel-simple.c |   26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index f88a631..2030c37 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -982,6 +982,29 @@ static const struct panel_desc lg_lb070wv8 = {
 	.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
 };
 
+static const struct drm_display_mode lg_lp120up1_mode = {
+	.clock = 162300,
+	.hdisplay = 1920,
+	.hsync_start = 1920 + 40,
+	.hsync_end = 1920 + 40 + 40,
+	.htotal = 1920 + 40 + 40+ 80,
+	.vdisplay = 1280,
+	.vsync_start = 1280 + 4,
+	.vsync_end = 1280 + 4 + 4,
+	.vtotal = 1280 + 4 + 4 + 12,
+	.vrefresh = 60,
+};
+
+static const struct panel_desc lg_lp120up1 = {
+	.modes = &lg_lp120up1_mode,
+	.num_modes = 1,
+	.bpc = 8,
+	.size = {
+		.width = 267,
+		.height = 183,
+	},
+};
+
 static const struct drm_display_mode lg_lp129qe_mode = {
 	.clock = 285250,
 	.hdisplay = 2560,
@@ -1256,6 +1279,9 @@ static const struct of_device_id platform_of_match[] = {
 		.compatible = "lg,lb070wv8",
 		.data = &lg_lb070wv8,
 	}, {
+		.compatible = "lg,lp120up1",
+		.data = &lg_lp120up1,
+	}, {
 		.compatible = "lg,lp129qe",
 		.data = &lg_lp129qe,
 	}, {
-- 
1.7.9.5



From majun258 at huawei.com  Mon Feb 22 03:00:10 2016
From: majun258 at huawei.com (MaJun)
Date: Mon, 22 Feb 2016 19:00:10 +0800
Subject: [PATCH] Irq/mbigen:Promote the mbigen driver register timing
Message-ID: <1456138810-24008-1-git-send-email-majun258@huawei.com>

From: Ma Jun <majun258 at huawei.com>

Using module_platform_driver() to register mbigen driver is
too late for some driver to apply irq, because the mbigen irq
domain is not created yet. 

Signed-off-by: Ma Jun <majun258 at huawei.com>
---
 drivers/irqchip/irq-mbigen.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 4dd3eb8..4df359c 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -289,7 +289,14 @@ static struct platform_driver mbigen_platform_driver = {
 	.probe			= mbigen_device_probe,
 };
 
-module_platform_driver(mbigen_platform_driver);
+static __init int mbigen_init(void)
+
+{
+	return platform_driver_register(&mbigen_platform_driver);
+
+}
+
+arch_initcall(mbigen_init);
 
 MODULE_AUTHOR("Jun Ma <majun258 at huawei.com>");
 MODULE_AUTHOR("Yun Wu <wuyun.wu at huawei.com>");
-- 
1.7.1




From David.Laight at ACULAB.COM  Mon Feb 22 03:00:02 2016
From: David.Laight at ACULAB.COM (David Laight)
Date: Mon, 22 Feb 2016 11:00:02 +0000
Subject: [PATCH 2/2] net, thunderx: Use bool in structs where possible
In-Reply-To: <1455799149-19590-3-git-send-email-rrichter@caviumnetworks.com>
References: <1455799149-19590-1-git-send-email-rrichter@caviumnetworks.com>
 <1455799149-19590-3-git-send-email-rrichter@caviumnetworks.com>
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CCE6A71@AcuExch.aculab.com>

From: Robert Richter
> Sent: 18 February 2016 12:39
> From: Robert Richter <rrichter at cavium.com>
> 
> Looks like the :1 notation was accidentally introduced (this still
> uses 1 byte per flag). Using bool instead, which is the common use.
> 
> Signed-off-by: Robert Richter <rrichter at cavium.com>
> ---
>  drivers/net/ethernet/cavium/thunder/nic.h | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/ethernet/cavium/thunder/nic.h b/drivers/net/ethernet/cavium/thunder/nic.h
> index 688828865c48..fa5b1d2d8e23 100644
> --- a/drivers/net/ethernet/cavium/thunder/nic.h
> +++ b/drivers/net/ethernet/cavium/thunder/nic.h
> @@ -262,9 +262,9 @@ struct nicvf {
>  	struct pci_dev		*pdev;
>  	u8			vf_id;
>  	u8			node;
> -	u8			tns_mode:1;
> -	u8			sqs_mode:1;
> -	u8			loopback_supported:1;
> +	bool			tns_mode;
> +	bool                    sqs_mode;
> +	bool			loopback_supported;
>  	bool			hw_tso;
>  	u16			mtu;
>  	struct queue_set	*qs;

If the size of the structure matters, you've just made it two bytes larger.
(Although it looks like there is some padding).

	David



From broonie at kernel.org  Mon Feb 22 03:04:16 2016
From: broonie at kernel.org (Mark Brown)
Date: Mon, 22 Feb 2016 20:04:16 +0900
Subject: [PATCH v1 0/2] patches to add support for rockchip rt5640 card
In-Reply-To: <1456127815-68575-1-git-send-email-sugar.zhang@rock-chips.com>
References: <1456127815-68575-1-git-send-email-sugar.zhang@rock-chips.com>
Message-ID: <20160222110416.GC18327@sirena.org.uk>

On Mon, Feb 22, 2016 at 03:56:53PM +0800, Sugar Zhang wrote:

> Sugar Zhang (2):
>   ASoC: rockchip: i2s: add default values for registers
>   ASoC: rt5640: add master clock handling for rt5640

These appear to be commpletly unrelated patches so should each be sent
individually rather than as a series - that way there is no confusion
about them possibly depending on each other and they are easier to
review and apply.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160222/40b71dfd/attachment.sig>

From ynvich at gmail.com  Mon Feb 22 03:08:17 2016
From: ynvich at gmail.com (Sergei Ianovich)
Date: Mon, 22 Feb 2016 14:08:17 +0300
Subject: [PATCH v1] arm: pxa: fix DT node name for PXA27X usb
Message-ID: <1456139297-5854-1-git-send-email-ynvich@gmail.com>

Without this patch I am getting an error:
---8<---
[   15.709742] ohci-pxa27x: OHCI PXA27x/PXA3x driver
[   15.737150] pxa27x-ohci: probe of 4c000000.ohci failed with error -2
---8<---

The error is generated in drivers/usb/host/ohci-pxa27x.c at line 441:
---8<---
441:	usb_clk = devm_clk_get(&pdev->dev, NULL);
442:	if (IS_ERR(usb_clk))
443:		return PTR_ERR(usb_clk);
---8<---

The error is caused by different names for the same DT node in pxa2xx.dtsi
and pxa27x.dtsi.

Signed-off-by: Sergei Ianovich <ynvich at gmail.com>
CC: Robert Jarzmik <robert.jarzmik at free.fr>
---
 arch/arm/boot/dts/pxa27x.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index 7f68a1e..3016a73 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -26,7 +26,7 @@
 			clocks = <&clks CLK_NONE>;
 		};
 
-		pxa27x_ohci: usb at 4c000000 {
+		usb0: ohci at 4c000000 {
 			compatible = "marvell,pxa-ohci";
 			reg = <0x4c000000 0x10000>;
 			interrupts = <3>;
-- 
2.6.3



From kishon at ti.com  Mon Feb 22 03:15:10 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 22 Feb 2016 16:45:10 +0530
Subject: [PATCH 0/2] Add Rockchip display port phy driver support
In-Reply-To: <1455534071-31230-1-git-send-email-ykk@rock-chips.com>
References: <1455534071-31230-1-git-send-email-ykk@rock-chips.com>
Message-ID: <56CAEDBE.2050808@ti.com>

Hi,

On Monday 15 February 2016 04:31 PM, Yakir Yang wrote:
> 
> Hi Kison,
> 
> This series is splited from Analogix DP DRM thread [0], and Heiko suggest this
> should be an independent thread which may be easy for you to apply.

Indeed. Merged now thanks. (Changed the year to 2016 in the file header before
merging)

Thanks
Kishon

> 
> Best regards,
> Yakir
> 
> [0]: https://patchwork.kernel.org/patch/8086571/
> 
> 
> Changes in v12:
> - Re-order the include headers file alphabetically in phy-rockchip-dp.c (Jingoo)
> 
> Changes in v11:
> - Correct the title of this rockchip dp phy document(Rob)
> - Add the ack from Rob Herring
> 
> Changes in v10:
> - Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
>     BIT(4) -> BIT(20)
> 
> Changes in v9:
> - Removed the unused the variable "res" in probe function. (Heiko)
> - Removed the unused head file.
> 
> Changes in v8:
> - Fix the mixed spacers on macro definitions. (Heiko)
> - Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
> - Remove the specific address in the example node name. (Heiko)
> 
> Changes in v7:
> - Simply the commit message. (Kishon)
> - Symmetrical enable/disbale the phy clock and power. (Kishon)
> - Simplify the commit message. (Kishon)
> 
> Changes in v5:
> - Remove "reg" DT property, cause driver could poweron/poweroff phy via
>   the exist "grf" syscon already. And rename the example DT node from
>   "edp_phy: phy at ff770274" to "edp_phy: edp-phy" directly. (Heiko)
> - Add deivce_node at the front of driver, update phy_ops type from "static
>   struct" to "static const struct". And correct the input paramters of
>   devm_phy_create() interfaces. (Heiko)
> - Split binding doc's from driver changes. (Rob)
> - Update the rockchip,grf explain in document, and correct the clock required
>   elemets in document. (Rob & Heiko)
> 
> Changes in v4:
> - Add commit message, and remove the redundant rockchip_dp_phy_init()
>   function, move those code to probe() method. And remove driver .owner
>   number. (Kishon)
> 
> Changes in v3:
> - Suggest, add rockchip dp phy driver, collect the phy clocks and
>   power control. (Heiko)
> 
> Yakir Yang (2):
>   phy: Add driver for rockchip Display Port PHY
>   dt-bindings: add document for rockchip dp phy
> 
>  .../devicetree/bindings/phy/rockchip-dp-phy.txt    |  22 +++
>  drivers/phy/Kconfig                                |   7 +
>  drivers/phy/Makefile                               |   1 +
>  drivers/phy/phy-rockchip-dp.c                      | 151 +++++++++++++++++++++
>  4 files changed, 181 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>  create mode 100644 drivers/phy/phy-rockchip-dp.c
> 


From punit.agrawal at arm.com  Mon Feb 22 03:21:37 2016
From: punit.agrawal at arm.com (Punit Agrawal)
Date: Mon, 22 Feb 2016 11:21:37 +0000
Subject: [PATCH v2 1/3] ARM: dts: Add cooling levels for CPUs on exynos5420
In-Reply-To: <56C69154.40608@samsung.com> (Krzysztof Kozlowski's message of
 "Fri, 19 Feb 2016 12:51:48 +0900")
References: <1455772383-20598-1-git-send-email-k.kozlowski@samsung.com>
 <87h9h599zi.fsf@e105922-lin.cambridge.arm.com>
 <56C69154.40608@samsung.com>
Message-ID: <871t857zy6.fsf@e105922-lin.cambridge.arm.com>

Krzysztof Kozlowski <k.kozlowski at samsung.com> writes:

> On 19.02.2016 02:58, Punit Agrawal wrote:
>> Hi Krzysztof,
>> 
>> Krzysztof Kozlowski <k.kozlowski at samsung.com> writes:
>> 
>>> On Exynos5420 we support 8 cpufreq steps (600-1300 MHz) for LITTLE and
>>> 12 steps for big core (700-1800 MHz). Add respective cooling cells.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
>>>
>>> ---
>>>
>>> Changes since v1:
>>> 1. Add cooling properties to all CPUs (suggested by Viresh).
>>> ---
>>>  arch/arm/boot/dts/exynos5420-cpus.dtsi | 24 ++++++++++++++++++++++++
>>>  1 file changed, 24 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>>> index 261d25173f61..5c052d7ff554 100644
>>> --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>>> @@ -33,6 +33,9 @@
>>>  			clock-frequency = <1800000000>;
>>>  			cci-control-port = <&cci_control1>;
>>>  			operating-points-v2 = <&cluster_a15_opp_table>;
>>> +			cooling-min-level = <0>;
>>> +			cooling-max-level = <11>;
>> 
>> Although the above two properties are defined they aren't parsed in the
>> kernel.
>> 
>> Setting min / max extents for cooling devices via cooling maps does work
>> though.
>
> It is described as optional property in
> Documentation/devicetree/bindings/thermal/thermal.txt ... but indeed it
> is totally ignored.
>
> So what is the recommendation? Get rid of it from DTS and documentation
> or leave it because it will be implemented someday?

As long as you are not expecting any particular behaviour arising from
that property today I think it should be fine to leave it in.

Eduardo, do you agree?

>
> Thanks for feedback!
>
> Best regards,
> Krzysztof
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From srinivas.kandagatla at linaro.org  Mon Feb 22 03:22:41 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Mon, 22 Feb 2016 11:22:41 +0000
Subject: [PATCH 0/3] nvmem: fixes for v4.6
Message-ID: <1456140161-6851-1-git-send-email-srinivas.kandagatla@linaro.org>

Hi Greg,

Here are couple of nvmem fixes on the mailing list which are good to go in
v4.6. Could you please take them thru the char-misc tree.

Thanks,
srini

Andrew-CT Chen (1):
  nvmem: mediatek: Fix later provider initialization

Axel Lin (1):
  nvmem: imx-ocotp: Fix return value of imx_ocotp_read

Richard Weinberger (1):
  nvmem: Fix dependencies for !HAS_IOMEM archs

 drivers/nvmem/Kconfig     |  4 ++++
 drivers/nvmem/imx-ocotp.c |  2 +-
 drivers/nvmem/mtk-efuse.c | 23 ++++++++++++++++++++++-
 3 files changed, 27 insertions(+), 2 deletions(-)

-- 
1.9.1



From srinivas.kandagatla at linaro.org  Mon Feb 22 03:23:44 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Mon, 22 Feb 2016 11:23:44 +0000
Subject: [PATCH 1/3] nvmem: Fix dependencies for !HAS_IOMEM archs
In-Reply-To: <1456140161-6851-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456140161-6851-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456140224-6895-1-git-send-email-srinivas.kandagatla@linaro.org>

From: Richard Weinberger <richard at nod.at>

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger <richard at nod.at>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 drivers/nvmem/Kconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 5bd18cc..ca52952 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -37,6 +37,7 @@ config NVMEM_LPC18XX_EEPROM
 config NVMEM_MXS_OCOTP
 	tristate "Freescale MXS On-Chip OTP Memory Support"
 	depends on ARCH_MXS || COMPILE_TEST
+	depends on HAS_IOMEM
 	help
 	  If you say Y here, you will get readonly access to the
 	  One Time Programmable memory pages that are stored
@@ -59,6 +60,7 @@ config MTK_EFUSE
 config QCOM_QFPROM
 	tristate "QCOM QFPROM Support"
 	depends on ARCH_QCOM || COMPILE_TEST
+	depends on HAS_IOMEM
 	select REGMAP_MMIO
 	help
 	  Say y here to enable QFPROM support. The QFPROM provides access
@@ -70,6 +72,7 @@ config QCOM_QFPROM
 config ROCKCHIP_EFUSE
 	tristate "Rockchip eFuse Support"
 	depends on ARCH_ROCKCHIP || COMPILE_TEST
+	depends on HAS_IOMEM
 	help
 	  This is a simple drive to dump specified values of Rockchip SoC
 	  from eFuse, such as cpu-leakage.
@@ -91,6 +94,7 @@ config NVMEM_SUNXI_SID
 config NVMEM_VF610_OCOTP
 	tristate "VF610 SoC OCOTP support"
 	depends on SOC_VF610 || COMPILE_TEST
+	depends on HAS_IOMEM
 	help
 	  This is a driver for the 'OCOTP' peripheral available on Vybrid
 	  devices like VF5xx and VF6xx.
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Mon Feb 22 03:23:52 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Mon, 22 Feb 2016 11:23:52 +0000
Subject: [PATCH 2/3] nvmem: imx-ocotp: Fix return value of imx_ocotp_read
In-Reply-To: <1456140161-6851-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456140161-6851-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456140232-6938-1-git-send-email-srinivas.kandagatla@linaro.org>

From: Axel Lin <axel.lin at ingics.com>

imx_ocotp_read() should return 0 on success.

Signed-off-by: Axel Lin <axel.lin at ingics.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 drivers/nvmem/imx-ocotp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index b7971d4..d7796eb 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -51,7 +51,7 @@ static int imx_ocotp_read(void *context, const void *reg, size_t reg_size,
 		val += 4;
 	}
 
-	return (i - index) * 4;
+	return 0;
 }
 
 static int imx_ocotp_write(void *context, const void *data, size_t count)
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Mon Feb 22 03:24:05 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Mon, 22 Feb 2016 11:24:05 +0000
Subject: [PATCH 3/3] nvmem: mediatek: Fix later provider initialization
In-Reply-To: <1456140161-6851-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456140161-6851-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456140245-6982-1-git-send-email-srinivas.kandagatla@linaro.org>

From: Andrew-CT Chen <andrew-ct.chen at mediatek.com>

Possibly, provider driver initialization is later than
consumer driver. Use function subsys_initcall to initialize
NVMEM provider early to ensure NVMEM consumer doesn't need
to -EPROBE_DEFER.

Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 drivers/nvmem/mtk-efuse.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
index 7b35f5b..9c49369 100644
--- a/drivers/nvmem/mtk-efuse.c
+++ b/drivers/nvmem/mtk-efuse.c
@@ -83,7 +83,28 @@ static struct platform_driver mtk_efuse_driver = {
 		.of_match_table = mtk_efuse_of_match,
 	},
 };
-module_platform_driver(mtk_efuse_driver);
+
+static int __init mtk_efuse_init(void)
+{
+	int ret;
+
+	ret = platform_driver_register(&mtk_efuse_driver);
+	if (ret) {
+		pr_err("Failed to register efuse driver\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+static void __exit mtk_efuse_exit(void)
+{
+	return platform_driver_unregister(&mtk_efuse_driver);
+}
+
+subsys_initcall(mtk_efuse_init);
+module_exit(mtk_efuse_exit);
+
 MODULE_AUTHOR("Andrew-CT Chen <andrew-ct.chen at mediatek.com>");
 MODULE_DESCRIPTION("Mediatek EFUSE driver");
 MODULE_LICENSE("GPL v2");
-- 
1.9.1



From marc.zyngier at arm.com  Mon Feb 22 03:24:03 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 22 Feb 2016 11:24:03 +0000
Subject: [PATCH] Irq/mbigen:Promote the mbigen driver register timing
In-Reply-To: <1456138810-24008-1-git-send-email-majun258@huawei.com>
References: <1456138810-24008-1-git-send-email-majun258@huawei.com>
Message-ID: <56CAEFD3.2060700@arm.com>

On 22/02/16 11:00, MaJun wrote:
> From: Ma Jun <majun258 at huawei.com>
> 
> Using module_platform_driver() to register mbigen driver is
> too late for some driver to apply irq, because the mbigen irq
> domain is not created yet. 
> 
> Signed-off-by: Ma Jun <majun258 at huawei.com>
> ---
>  drivers/irqchip/irq-mbigen.c |    9 ++++++++-
>  1 files changed, 8 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index 4dd3eb8..4df359c 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -289,7 +289,14 @@ static struct platform_driver mbigen_platform_driver = {
>  	.probe			= mbigen_device_probe,
>  };
>  
> -module_platform_driver(mbigen_platform_driver);
> +static __init int mbigen_init(void)
> +
> +{
> +	return platform_driver_register(&mbigen_platform_driver);
> +
> +}
> +
> +arch_initcall(mbigen_init);
>  
>  MODULE_AUTHOR("Jun Ma <majun258 at huawei.com>");
>  MODULE_AUTHOR("Yun Wu <wuyun.wu at huawei.com>");
> 

I don't believe this is a proper fix, and already said so when reviewing
this code:

http://www.spinics.net/lists/linux-pci/msg46534.html

Short of actually solving the dependencies, it is likely that you will
only move the problem somewhere else.

I suggest you engage will people that are working on a proper solution,
and/or fix the drivers to gracefully defer their probing if their IRQs
are not available.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From mark.rutland at arm.com  Mon Feb 22 03:29:02 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Feb 2016 11:29:02 +0000
Subject: [PATCH 3/3] arm64: ptdump: include UEFI runtime service mappings
In-Reply-To: <1456135239-3607-4-git-send-email-ard.biesheuvel@linaro.org>
References: <1456135239-3607-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456135239-3607-4-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160222112901.GA3435@leverpostej>

Hi,

On Mon, Feb 22, 2016 at 11:00:39AM +0100, Ard Biesheuvel wrote:
> This adds the UEFI runtime services page table mappings to the output
> of the kernel page table dumper. These tables are only live during the
> time UEFI runtime services are being invoked, but we can include them
> for informational purposes nonetheless.

I would prefer that we had a separate file for the EFI runtime services
page tables. As you mention, they are distinct from the kernel and not
always live (which is also the case for the idmap, for example).

I have some local patches atop of v4.3 that librify the dumping code and
add a separate file for EFI [1]. I spotted a couple other things in
doing that (e.g. that we need to pad addresses more).

Is it worth cleaning that up?

Thanks,
Mark.

[1] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/ptdump/librify

> 
> Cc: Matt Fleming <matt at codeblueprint.co.uk>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
>  arch/arm64/mm/dump.c               | 8 ++++++++
>  drivers/firmware/efi/arm-runtime.c | 2 +-
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index 12e4b1732303..e7b937c9ad52 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -36,6 +36,10 @@ struct addr_marker {
>  };
>  
>  static struct addr_marker address_markers[] = {
> +#ifdef CONFIG_EFI
> +	{ 0,				"UEFI runtime start" },
> +	{ TASK_SIZE_64,			"UEFI runtime end" },
> +#endif
>  #ifdef CONFIG_KASAN
>  	{ KASAN_SHADOW_START,		"Kasan shadow start" },
>  	{ KASAN_SHADOW_END,		"Kasan shadow end" },
> @@ -310,6 +314,10 @@ static int ptdump_show(struct seq_file *m, void *v)
>  		.marker = address_markers,
>  	};
>  
> +	if (IS_ENABLED(CONFIG_EFI)) {
> +		extern struct mm_struct efi_mm;
> +		walk_pgd(&st, &efi_mm, 0);
> +	}
>  	walk_pgd(&st, &init_mm, LOWEST_ADDR);
>  
>  	note_page(&st, 0, 0, 0);
> diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
> index 6ae21e41a429..3a3911641049 100644
> --- a/drivers/firmware/efi/arm-runtime.c
> +++ b/drivers/firmware/efi/arm-runtime.c
> @@ -30,7 +30,7 @@
>  
>  extern u64 efi_system_table;
>  
> -static struct mm_struct efi_mm = {
> +struct mm_struct efi_mm = {
>  	.mm_rb			= RB_ROOT,
>  	.mm_users		= ATOMIC_INIT(2),
>  	.mm_count		= ATOMIC_INIT(1),
> -- 
> 2.5.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From mark.rutland at arm.com  Mon Feb 22 03:33:10 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Feb 2016 11:33:10 +0000
Subject: [PATCH 1/3] arm64: ptdump: use static initializers for vmemmap
 region boundaries
In-Reply-To: <1456135239-3607-2-git-send-email-ard.biesheuvel@linaro.org>
References: <1456135239-3607-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456135239-3607-2-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160222113310.GB3435@leverpostej>

Hi,

On Mon, Feb 22, 2016 at 11:00:37AM +0100, Ard Biesheuvel wrote:
> There is no need to initialize the vmemmap region boundaries dynamically,
> since they are compile time constants. So just add these constants to the
> global struct initializer, and drop the dynamic assignment and related code.

This does look nicer.

I believe the intention here was to mark the end of the _populated_
vmemmap region rather than the static VA carveout, so this is a slight
change in behaviour.

However, I don't think we gained much by only handling the populated
region, and we didn't do the same for the linear map. So FWIW:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Mark.

> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
>  arch/arm64/mm/dump.c | 47 +++++---------------
>  1 file changed, 12 insertions(+), 35 deletions(-)
> 
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index 6be918478f85..eadcb70e733c 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -34,37 +34,21 @@ struct addr_marker {
>  	const char *name;
>  };
>  
> -enum address_markers_idx {
> -	MODULES_START_NR = 0,
> -	MODULES_END_NR,
> -	VMALLOC_START_NR,
> -	VMALLOC_END_NR,
> -#ifdef CONFIG_SPARSEMEM_VMEMMAP
> -	VMEMMAP_START_NR,
> -	VMEMMAP_END_NR,
> -#endif
> -	FIXADDR_START_NR,
> -	FIXADDR_END_NR,
> -	PCI_START_NR,
> -	PCI_END_NR,
> -	KERNEL_SPACE_NR,
> -};
> -
>  static struct addr_marker address_markers[] = {
> -	{ MODULES_VADDR,	"Modules start" },
> -	{ MODULES_END,		"Modules end" },
> -	{ VMALLOC_START,	"vmalloc() Area" },
> -	{ VMALLOC_END,		"vmalloc() End" },
> +	{ MODULES_VADDR,		"Modules start" },
> +	{ MODULES_END,			"Modules end" },
> +	{ VMALLOC_START,		"vmalloc() Area" },
> +	{ VMALLOC_END,			"vmalloc() End" },
>  #ifdef CONFIG_SPARSEMEM_VMEMMAP
> -	{ 0,			"vmemmap start" },
> -	{ 0,			"vmemmap end" },
> +	{ (u64)vmemmap,			"vmemmap start" },
> +	{ (u64)vmemmap + VMEMMAP_SIZE,	"vmemmap end" },
>  #endif
> -	{ FIXADDR_START,	"Fixmap start" },
> -	{ FIXADDR_TOP,		"Fixmap end" },
> -	{ PCI_IO_START,		"PCI I/O start" },
> -	{ PCI_IO_END,		"PCI I/O end" },
> -	{ PAGE_OFFSET,		"Linear Mapping" },
> -	{ -1,			NULL },
> +	{ FIXADDR_START,		"Fixmap start" },
> +	{ FIXADDR_TOP,			"Fixmap end" },
> +	{ PCI_IO_START,			"PCI I/O start" },
> +	{ PCI_IO_END,			"PCI I/O end" },
> +	{ PAGE_OFFSET,			"Linear Mapping" },
> +	{ -1,				NULL },
>  };
>  
>  /*
> @@ -349,13 +333,6 @@ static int ptdump_init(void)
>  			for (j = 0; j < pg_level[i].num; j++)
>  				pg_level[i].mask |= pg_level[i].bits[j].mask;
>  
> -#ifdef CONFIG_SPARSEMEM_VMEMMAP
> -	address_markers[VMEMMAP_START_NR].start_address =
> -				(unsigned long)virt_to_page(PAGE_OFFSET);
> -	address_markers[VMEMMAP_END_NR].start_address =
> -				(unsigned long)virt_to_page(high_memory);
> -#endif
> -
>  	pe = debugfs_create_file("kernel_page_tables", 0400, NULL, NULL,
>  				 &ptdump_fops);
>  	return pe ? 0 : -ENOMEM;
> -- 
> 2.5.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From mark.rutland at arm.com  Mon Feb 22 03:33:51 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Feb 2016 11:33:51 +0000
Subject: [PATCH 2/3] arm64: ptdump: add region marker for kasan shadow
 region
In-Reply-To: <1456135239-3607-3-git-send-email-ard.biesheuvel@linaro.org>
References: <1456135239-3607-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456135239-3607-3-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160222113350.GC3435@leverpostej>

On Mon, Feb 22, 2016 at 11:00:38AM +0100, Ard Biesheuvel wrote:
> Annotate the KASAN shadow region with boundary markers, so that its
> mappings stand out in the page table dumper output.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

Acked-by: Mark Rutland <mark.rutland at arm.com>

Mark.

> ---
>  arch/arm64/mm/dump.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index eadcb70e733c..12e4b1732303 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -23,6 +23,7 @@
>  #include <linux/seq_file.h>
>  
>  #include <asm/fixmap.h>
> +#include <asm/kasan.h>
>  #include <asm/memory.h>
>  #include <asm/pgtable.h>
>  #include <asm/pgtable-hwdef.h>
> @@ -35,6 +36,10 @@ struct addr_marker {
>  };
>  
>  static struct addr_marker address_markers[] = {
> +#ifdef CONFIG_KASAN
> +	{ KASAN_SHADOW_START,		"Kasan shadow start" },
> +	{ KASAN_SHADOW_END,		"Kasan shadow end" },
> +#endif
>  	{ MODULES_VADDR,		"Modules start" },
>  	{ MODULES_END,			"Modules end" },
>  	{ VMALLOC_START,		"vmalloc() Area" },
> -- 
> 2.5.0
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From linux at arm.linux.org.uk  Mon Feb 22 03:36:25 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Feb 2016 11:36:25 +0000
Subject: [PATCH 0/6] ARM: decompressor: several cleanups
In-Reply-To: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <20160222113625.GC19428@n2100.arm.linux.org.uk>

On Mon, Feb 22, 2016 at 04:31:11PM +0900, Masahiro Yamada wrote:
> Masahiro Yamada (6):
>   ARM: decompressor: drop unneeded assignments to "targets"
>   ARM: decompressor: drop more unneeded assignments to "targets"
>   ARM: decompressor: use clean-files instead of extra-y to clean files
>   ARM: decompressor: drop redundant FORCE in Makefile
>   ARM: decompressor: merge piggy.*.S and simplify Makefile
>   ARM: decompressor: rename suffix_y to compress-y

Most of this looks fine to me, but I've a question about how thoroughly
patch 5 has been tested: iow, do we get correct behaviour if only the
compression method is changed?

Thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From Suzuki.Poulose at arm.com  Mon Feb 22 03:37:42 2016
From: Suzuki.Poulose at arm.com (Suzuki K. Poulose)
Date: Mon, 22 Feb 2016 11:37:42 +0000
Subject: [PATCH 6/6] arm64: compat: Check for AArch32 state
In-Reply-To: <20160209173606.GX22874@arm.com>
References: <1453980737-6126-1-git-send-email-suzuki.poulose@arm.com>
 <1453980737-6126-7-git-send-email-suzuki.poulose@arm.com>
 <20160209173606.GX22874@arm.com>
Message-ID: <56CAF306.1060102@arm.com>

On 09/02/16 17:36, Will Deacon wrote:
> On Thu, Jan 28, 2016 at 11:32:17AM +0000, Suzuki K Poulose wrote:
>> Make sure we have AArch32 state available for running COMPAT binaries.


>>   		 */
>>   		seq_puts(m, "Features\t:");
>> -		if (personality(current->personality) == PER_LINUX32) {
>> +		if (system_supports_32bit_el0() &&
>> +			personality(current->personality) == PER_LINUX32) {
>
> Wouldn't it be better to prevent tasks changing to the PER_LINUX32
> personality on systems that don't support AArch32 at EL0?

Yes, thats the ideal solution. I took a look at it  and it requires us to
hook in arm64 wrapper for the personality syscall. I will take a look.

Thanks
Suzuki


From heiko at sntech.de  Mon Feb 22 03:41:05 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 22 Feb 2016 12:41:05 +0100
Subject: [PATCH v5.1] phy: rockchip-usb: add handler for usb-uart functionality
Message-ID: <1670829.9XWsDys3pl@phil>

Most newer Rockchip SoCs provide the possibility to use a usb-phy
as passthrough for the debug uart (uart2), making it possible to
for example get console output without needing to open the device.

This patch adds an early_initcall to enable this functionality
conditionally via the commandline and also disables the corresponding
usb controller in the devicetree.

Currently only data for the rk3288 is provided, but at least the
rk3188 and arm64 rk3368 also provide this functionality and will be
enabled later.

On a spliced usb cable the signals are tx on white wire(D+) and
rx on green wire(D-).

The one caveat is that currently the reconfiguration of the phy
happens as early_initcall, as the code depends on the unflattened
devicetree being available. Everything is fine if only a regular
console is active as the console-replay will happen after the
reconfiguation. But with earlycon active output up to smp-init
currently will get lost.

The phy is an optional property for the connected dwc2 controller,
so we still provide the phy device but fail all phy-ops with -EBUSY
to make sure the dwc2 does not try to transmit anything on the
repurposed phy.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
changes in v5.1:
- fix corruptions that happened when sending v5
changes in v5:
- only compile debug uart functionality if the phy is compiled in
  fixes initcall conflict and debug functionality also is only really
  usable if it's available early
changes in v4:
- drop the rest of the phy-series, as the patches have gotten applied

So far, this hasn't gotten eyeballs yet, so citing discussion-parts from
the v3 coverletter:

The patch, while not associated with the new pll handling, also builds
on the groundwork introduced there and adds support for the function
repurposing one of the phys as passthrough for uart-data. This enables
attaching a ttl converter to the D+ and D- pins of an usb cable to
receive uart data this way, when it is not really possible to attach
a regular serial console to a board.

One point of critique in my first iteration [0] of this was, that
due to when the reconfiguration happens we may miss parts of the logs
when earlycon is enabled. So far early_initcall gets used as the
unflattened devicetree is necessary to set this up. Doing this for
example in the early_param directly would require parsing the flattened
devicetree to get needed nodes and properties.

I still maintain that if you're working on anything before smp-bringup
you should use a real dev-board instead or try to solder uart cables
on hopefully available test-points  .


 Documentation/kernel-parameters.txt |   6 +
 drivers/phy/phy-rockchip-usb.c      | 233 ++++++++++++++++++++++++++++++------
 2 files changed, 203 insertions(+), 36 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 87d40a7..d91417b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3486,6 +3486,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
 	ro		[KNL] Mount root device read-only on boot
 
+	rockchip.usb_uart
+			Enable the uart passthrough on the designated usb port
+			on Rockchip SoCs. When active, the signals of the
+			debug-uart get routed to the D+ and D- pins of the usb
+			port and the regular usb controller gets disabled.
+
 	root=		[KNL] Root filesystem
 			See name_to_dev_t comment in init/do_mounts.c.
 
diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
index 33a80eb..f62d899 100644
--- a/drivers/phy/phy-rockchip-usb.c
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -30,21 +30,23 @@
 #include <linux/regmap.h>
 #include <linux/mfd/syscon.h>
 
-/*
- * The higher 16-bit of this register is used for write protection
- * only if BIT(13 + 16) set to 1 the BIT(13) can be written.
- */
-#define SIDDQ_WRITE_ENA	BIT(29)
-#define SIDDQ_ON		BIT(13)
-#define SIDDQ_OFF		(0 << 13)
+static int enable_usb_uart;
+
+#define HIWORD_UPDATE(val, mask) \
+		((val) | (mask) << 16)
+
+#define UOC_CON0_SIDDQ BIT(13)
 
 struct rockchip_usb_phys {
 	int reg;
 	const char *pll_name;
 };
 
+struct rockchip_usb_phy_base;
 struct rockchip_usb_phy_pdata {
 	struct rockchip_usb_phys *phys;
+	int (*init_usb_uart)(struct regmap *grf);
+	int usb_uart_phy;
 };
 
 struct rockchip_usb_phy_base {
@@ -61,13 +63,15 @@ struct rockchip_usb_phy {
 	struct clk      *clk480m;
 	struct clk_hw	clk480m_hw;
 	struct phy	*phy;
+	bool		uart_enabled;
 };
 
 static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
 					   bool siddq)
 {
-	return regmap_write(phy->base->reg_base, phy->reg_offset,
-			    SIDDQ_WRITE_ENA | (siddq ? SIDDQ_ON : SIDDQ_OFF));
+	u32 val = HIWORD_UPDATE(siddq ? UOC_CON0_SIDDQ : 0, UOC_CON0_SIDDQ);
+
+	return regmap_write(phy->base->reg_base, phy->reg_offset, val);
 }
 
 static unsigned long rockchip_usb_phy480m_recalc_rate(struct clk_hw *hw,
@@ -108,7 +112,7 @@ static int rockchip_usb_phy480m_is_enabled(struct clk_hw *hw)
 	if (ret < 0)
 		return ret;
 
-	return (val & SIDDQ_ON) ? 0 : 1;
+	return (val & UOC_CON0_SIDDQ) ? 0 : 1;
 }
 
 static const struct clk_ops rockchip_usb_phy480m_ops = {
@@ -122,6 +126,9 @@ static int rockchip_usb_phy_power_off(struct phy *_phy)
 {
 	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
 
+	if (phy->uart_enabled)
+		return -EBUSY;
+
 	clk_disable_unprepare(phy->clk480m);
 
 	return 0;
@@ -131,6 +138,9 @@ static int rockchip_usb_phy_power_on(struct phy *_phy)
 {
 	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
 
+	if (phy->uart_enabled)
+		return -EBUSY;
+
 	return clk_prepare_enable(phy->clk480m);
 }
 
@@ -144,8 +154,10 @@ static void rockchip_usb_phy_action(void *data)
 {
 	struct rockchip_usb_phy *rk_phy = data;
 
-	of_clk_del_provider(rk_phy->np);
-	clk_unregister(rk_phy->clk480m);
+	if (!rk_phy->uart_enabled) {
+		of_clk_del_provider(rk_phy->np);
+		clk_unregister(rk_phy->clk480m);
+	}
 
 	if (rk_phy->clk)
 		clk_put(rk_phy->clk);
@@ -194,30 +206,35 @@ static int rockchip_usb_phy_init(struct rockchip_usb_phy_base *base,
 		return -EINVAL;
 	}
 
-	if (rk_phy->clk) {
-		clk_name = __clk_get_name(rk_phy->clk);
-		init.flags = 0;
-		init.parent_names = &clk_name;
-		init.num_parents = 1;
+	if (enable_usb_uart && base->pdata->usb_uart_phy == i) {
+		dev_dbg(base->dev, "phy%d used as uart output\n", i);
+		rk_phy->uart_enabled = true;
 	} else {
-		init.flags = CLK_IS_ROOT;
-		init.parent_names = NULL;
-		init.num_parents = 0;
-	}
+		if (rk_phy->clk) {
+			clk_name = __clk_get_name(rk_phy->clk);
+			init.flags = 0;
+			init.parent_names = &clk_name;
+			init.num_parents = 1;
+		} else {
+			init.flags = CLK_IS_ROOT;
+			init.parent_names = NULL;
+			init.num_parents = 0;
+		}
 
-	init.ops = &rockchip_usb_phy480m_ops;
-	rk_phy->clk480m_hw.init = &init;
+		init.ops = &rockchip_usb_phy480m_ops;
+		rk_phy->clk480m_hw.init = &init;
 
-	rk_phy->clk480m = clk_register(base->dev, &rk_phy->clk480m_hw);
-	if (IS_ERR(rk_phy->clk480m)) {
-		err = PTR_ERR(rk_phy->clk480m);
-		goto err_clk;
-	}
+		rk_phy->clk480m = clk_register(base->dev, &rk_phy->clk480m_hw);
+		if (IS_ERR(rk_phy->clk480m)) {
+			err = PTR_ERR(rk_phy->clk480m);
+			goto err_clk;
+		}
 
-	err = of_clk_add_provider(child, of_clk_src_simple_get,
-				  rk_phy->clk480m);
-	if (err < 0)
-		goto err_clk_prov;
+		err = of_clk_add_provider(child, of_clk_src_simple_get,
+					rk_phy->clk480m);
+		if (err < 0)
+			goto err_clk_prov;
+	}
 
 	err = devm_add_action(base->dev, rockchip_usb_phy_action, rk_phy);
 	if (err)
@@ -230,13 +247,21 @@ static int rockchip_usb_phy_init(struct rockchip_usb_phy_base *base,
 	}
 	phy_set_drvdata(rk_phy->phy, rk_phy);
 
-	/* only power up usb phy when it use, so disable it when init*/
-	return rockchip_usb_phy_power(rk_phy, 1);
+	/*
+	 * When acting as uart-pipe, just keep clock on otherwise
+	 * only power up usb phy when it use, so disable it when init
+	 */
+	if (rk_phy->uart_enabled)
+		return clk_prepare_enable(rk_phy->clk);
+	else
+		return rockchip_usb_phy_power(rk_phy, 1);
 
 err_devm_action:
-	of_clk_del_provider(child);
+	if (!rk_phy->uart_enabled)
+		of_clk_del_provider(child);
 err_clk_prov:
-	clk_unregister(rk_phy->clk480m);
+	if (!rk_phy->uart_enabled)
+		clk_unregister(rk_phy->clk480m);
 err_clk:
 	if (rk_phy->clk)
 		clk_put(rk_phy->clk);
@@ -259,6 +284,86 @@ static const struct rockchip_usb_phy_pdata rk3188_pdata = {
 	},
 };
 
+#define RK3288_UOC0_CON0				0x320
+#define RK3288_UOC0_CON0_COMMON_ON_N			BIT(0)
+#define RK3288_UOC0_CON0_DISABLE			BIT(4)
+
+#define RK3288_UOC0_CON2				0x328
+#define RK3288_UOC0_CON2_SOFT_CON_SEL			BIT(2)
+
+#define RK3288_UOC0_CON3				0x32c
+#define RK3288_UOC0_CON3_UTMI_SUSPENDN			BIT(0)
+#define RK3288_UOC0_CON3_UTMI_OPMODE_NODRIVING		(1 << 1)
+#define RK3288_UOC0_CON3_UTMI_OPMODE_MASK		(3 << 1)
+#define RK3288_UOC0_CON3_UTMI_XCVRSEELCT_FSTRANSC	(1 << 3)
+#define RK3288_UOC0_CON3_UTMI_XCVRSEELCT_MASK		(3 << 3)
+#define RK3288_UOC0_CON3_UTMI_TERMSEL_FULLSPEED		BIT(5)
+#define RK3288_UOC0_CON3_BYPASSDMEN			BIT(6)
+#define RK3288_UOC0_CON3_BYPASSSEL			BIT(7)
+
+/*
+ * Enable the bypass of uart2 data through the otg usb phy.
+ * Original description in the TRM.
+ * 1. Disable the OTG block by setting OTGDISABLE0 to 1?b1.
+ * 2. Disable the pull-up resistance on the D+ line by setting
+ *    OPMODE0[1:0] to 2?b01.
+ * 3. To ensure that the XO, Bias, and PLL blocks are powered down in Suspend
+ *    mode, set COMMONONN to 1?b1.
+ * 4. Place the USB PHY in Suspend mode by setting SUSPENDM0 to 1?b0.
+ * 5. Set BYPASSSEL0 to 1?b1.
+ * 6. To transmit data, controls BYPASSDMEN0, and BYPASSDMDATA0.
+ * To receive data, monitor FSVPLUS0.
+ *
+ * The actual code in the vendor kernel does some things differently.
+ */
+static int __init rk3288_init_usb_uart(struct regmap *grf)
+{
+	u32 val;
+	int ret;
+
+	/*
+	 * COMMON_ON and DISABLE settings are described in the TRM,
+	 * but were not present in the original code.
+	 * Also disable the analog phy components to save power.
+	 */
+	val = HIWORD_UPDATE(RK3288_UOC0_CON0_COMMON_ON_N
+				| RK3288_UOC0_CON0_DISABLE
+				| UOC_CON0_SIDDQ,
+			    RK3288_UOC0_CON0_COMMON_ON_N
+				| RK3288_UOC0_CON0_DISABLE
+				| UOC_CON0_SIDDQ);
+	ret = regmap_write(grf, RK3288_UOC0_CON0, val);
+	if (ret)
+		return ret;
+
+	val = HIWORD_UPDATE(RK3288_UOC0_CON2_SOFT_CON_SEL,
+			    RK3288_UOC0_CON2_SOFT_CON_SEL);
+	ret = regmap_write(grf, RK3288_UOC0_CON2, val);
+	if (ret)
+		return ret;
+
+	val = HIWORD_UPDATE(RK3288_UOC0_CON3_UTMI_OPMODE_NODRIVING
+				| RK3288_UOC0_CON3_UTMI_XCVRSEELCT_FSTRANSC
+				| RK3288_UOC0_CON3_UTMI_TERMSEL_FULLSPEED,
+			    RK3288_UOC0_CON3_UTMI_SUSPENDN
+				| RK3288_UOC0_CON3_UTMI_OPMODE_MASK
+				| RK3288_UOC0_CON3_UTMI_XCVRSEELCT_MASK
+				| RK3288_UOC0_CON3_UTMI_TERMSEL_FULLSPEED);
+	ret = regmap_write(grf, RK3288_UOC0_CON3, val);
+	if (ret)
+		return ret;
+
+	val = HIWORD_UPDATE(RK3288_UOC0_CON3_BYPASSSEL
+				| RK3288_UOC0_CON3_BYPASSDMEN,
+			    RK3288_UOC0_CON3_BYPASSSEL
+				| RK3288_UOC0_CON3_BYPASSDMEN);
+	ret = regmap_write(grf, RK3288_UOC0_CON3, val);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
 static const struct rockchip_usb_phy_pdata rk3288_pdata = {
 	.phys = (struct rockchip_usb_phys[]){
 		{ .reg = 0x320, .pll_name = "sclk_otgphy0_480m" },
@@ -266,6 +371,8 @@ static const struct rockchip_usb_phy_pdata rk3288_pdata = {
 		{ .reg = 0x348, .pll_name = "sclk_otgphy2_480m" },
 		{ /* sentinel */ }
 	},
+	.init_usb_uart = rk3288_init_usb_uart,
+	.usb_uart_phy = 0,
 };
 
 static int rockchip_usb_phy_probe(struct platform_device *pdev)
@@ -328,6 +435,60 @@ static struct platform_driver rockchip_usb_driver = {
 
 module_platform_driver(rockchip_usb_driver);
 
+#ifndef MODULE
+static int __init rockchip_init_usb_uart(void)
+{
+	const struct of_device_id *match;
+	const struct rockchip_usb_phy_pdata *data;
+	struct device_node *np;
+	struct regmap *grf;
+	int ret;
+
+	if (!enable_usb_uart)
+		return 0;
+
+	np = of_find_matching_node_and_match(NULL, rockchip_usb_phy_dt_ids,
+					     &match);
+	if (!np) {
+		pr_err("%s: failed to find usbphy node\n", __func__);
+		return -ENOTSUPP;
+	}
+
+	pr_debug("%s: using settings for %s\n", __func__, match->compatible);
+	data = match->data;
+
+	if (!data->init_usb_uart) {
+		pr_err("%s: usb-uart not available on %s\n",
+		       __func__, match->compatible);
+		return -ENOTSUPP;
+	}
+
+	grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+	if (IS_ERR(grf)) {
+		pr_err("%s: Missing rockchip,grf property, %lu\n",
+		       __func__, PTR_ERR(grf));
+		return PTR_ERR(grf);
+	}
+
+	ret = data->init_usb_uart(grf);
+	if (ret) {
+		pr_err("%s: could not init usb_uart, %d\n", __func__, ret);
+		enable_usb_uart = 0;
+		return ret;
+	}
+
+	return 0;
+}
+early_initcall(rockchip_init_usb_uart);
+
+static int __init rockchip_usb_uart(char *buf)
+{
+	enable_usb_uart = true;
+	return 0;
+}
+early_param("rockchip.usb_uart", rockchip_usb_uart);
+#endif
+
 MODULE_AUTHOR("Yunzhi Li <lyz at rock-chips.com>");
 MODULE_DESCRIPTION("Rockchip USB 2.0 PHY driver");
 MODULE_LICENSE("GPL v2");
-- 
2.6.4




From thierry.reding at gmail.com  Mon Feb 22 03:43:08 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 22 Feb 2016 12:43:08 +0100
Subject: [PATCH v2 2/2] drm/panel: Support for LG lp120up1 panel with eDP
 input
In-Reply-To: <CAGUYZuSsrneg8zQ0Ro8z5C469A2D-TOKpONECxWdoM6T+xNAeg@mail.gmail.com>
References: <1456138904-15258-1-git-send-email-jitao.shi@mediatek.com>
 <1456138904-15258-2-git-send-email-jitao.shi@mediatek.com>
 <CAGUYZuSsrneg8zQ0Ro8z5C469A2D-TOKpONECxWdoM6T+xNAeg@mail.gmail.com>
Message-ID: <20160222114308.GA22505@ulmo>

On Mon, Feb 22, 2016 at 04:42:54PM +0530, sanjeev sharma wrote:
> Hello Jitao,
> 
> Can't we add this panel information in device tree file instead inside the
> device driver ?

We could, but that would be redundant. Panels need to be represented by
a specific compatible string anyway, and that compatible string implies
the video timings, bits-per-color, width and height.

Also there's more to panels than just the timings or dimensions. Power
up and power down sequences are also implied by the compatible stirng.
Describing all of that in the device tree was at some point attempted,
but in the end it turned out too complicated and we ended up with what
we have now.

Thierry

> On Mon, Feb 22, 2016 at 4:31 PM, Jitao Shi <jitao.shi at mediatek.com> wrote:
> 
> > The LG lp120up1 TFT LCD panel with eDP interface is a 12.0" 1920x1280
> > panel, which can be supported by the simple panel driver
> >
> > Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> > ---
> > Changes since v1:
> >  - Add eDP panel type in comment msg
> >  - Fixed comment msg with 72 characters width
> > ---
> >  drivers/gpu/drm/panel/panel-simple.c |   26 ++++++++++++++++++++++++++
> >  1 file changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index f88a631..2030c37 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -982,6 +982,29 @@ static const struct panel_desc lg_lb070wv8 = {
> >         .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> >  };
> >
> > +static const struct drm_display_mode lg_lp120up1_mode = {
> > +       .clock = 162300,
> > +       .hdisplay = 1920,
> > +       .hsync_start = 1920 + 40,
> > +       .hsync_end = 1920 + 40 + 40,
> > +       .htotal = 1920 + 40 + 40+ 80,
> > +       .vdisplay = 1280,
> > +       .vsync_start = 1280 + 4,
> > +       .vsync_end = 1280 + 4 + 4,
> > +       .vtotal = 1280 + 4 + 4 + 12,
> > +       .vrefresh = 60,
> > +};
> > +
> > +static const struct panel_desc lg_lp120up1 = {
> > +       .modes = &lg_lp120up1_mode,
> > +       .num_modes = 1,
> > +       .bpc = 8,
> > +       .size = {
> > +               .width = 267,
> > +               .height = 183,
> > +       },
> > +};
> > +
> >  static const struct drm_display_mode lg_lp129qe_mode = {
> >         .clock = 285250,
> >         .hdisplay = 2560,
> > @@ -1256,6 +1279,9 @@ static const struct of_device_id platform_of_match[]
> > = {
> >                 .compatible = "lg,lb070wv8",
> >                 .data = &lg_lb070wv8,
> >         }, {
> > +               .compatible = "lg,lp120up1",
> > +               .data = &lg_lp120up1,
> > +       }, {
> >                 .compatible = "lg,lp129qe",
> >                 .data = &lg_lp129qe,
> >         }, {
> > --
> > 1.7.9.5
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160222/036840e4/attachment.sig>

From kishon at ti.com  Mon Feb 22 03:45:34 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Mon, 22 Feb 2016 17:15:34 +0530
Subject: [PATCH v5.1] phy: rockchip-usb: add handler for usb-uart
 functionality
In-Reply-To: <1670829.9XWsDys3pl@phil>
References: <1670829.9XWsDys3pl@phil>
Message-ID: <56CAF4DE.2060708@ti.com>

Hi,

On Monday 22 February 2016 05:11 PM, Heiko Stuebner wrote:
> Most newer Rockchip SoCs provide the possibility to use a usb-phy
> as passthrough for the debug uart (uart2), making it possible to
> for example get console output without needing to open the device.
> 
> This patch adds an early_initcall to enable this functionality
> conditionally via the commandline and also disables the corresponding
> usb controller in the devicetree.
> 
> Currently only data for the rk3288 is provided, but at least the
> rk3188 and arm64 rk3368 also provide this functionality and will be
> enabled later.
> 
> On a spliced usb cable the signals are tx on white wire(D+) and
> rx on green wire(D-).
> 
> The one caveat is that currently the reconfiguration of the phy
> happens as early_initcall, as the code depends on the unflattened
> devicetree being available. Everything is fine if only a regular
> console is active as the console-replay will happen after the
> reconfiguation. But with earlycon active output up to smp-init
> currently will get lost.
> 
> The phy is an optional property for the connected dwc2 controller,
> so we still provide the phy device but fail all phy-ops with -EBUSY
> to make sure the dwc2 does not try to transmit anything on the
> repurposed phy.
> 
> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> ---
> changes in v5.1:
> - fix corruptions that happened when sending v5

I still see the corruption.

This is how I see the patch after downloading (from both mutt and thunderbird)
@@ -3486,6 +3486,12 @@ bytes respectively. Such letter suffixes can also be=
 entirely omitted.
=20
        ro              [KNL] Mount root device read-only on boot
=20
+       rockchip.usb_uart
+                       Enable the uart passthrough on the designated usb port
+                       on Rockchip SoCs. When active, the signals of the
+                       debug-uart get routed to the D+ and D- pins of the usb
+                       port and the regular usb controller gets disabled.
+
        root=3D         [KNL] Root filesystem
                        See name_to_dev_t comment in init/do_mounts.c.
=20
diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.=
c
index 33a80eb..f62d899 100644
--- a/drivers/phy/phy-rockchip-usb.c
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -30,21 +30,23 @@
 #include <linux/regmap.h>
 #include <linux/mfd/syscon.h>
=20
-/*
- * The higher 16-bit of this register is used for write protection
- * only if BIT(13 + 16) set to 1 the BIT(13) can be written.
- */
-#define SIDDQ_WRITE_ENA        BIT(29)
-#define SIDDQ_ON               BIT(13)
-#define SIDDQ_OFF              (0 << 13)
+static int enable_usb_uart;
+
+#define HIWORD_UPDATE(val, mask) \
+               ((val) | (mask) << 16)
+
+#define UOC_CON0_SIDDQ BIT(13)
=20
 struct rockchip_usb_phys {
        int reg;
        const char *pll_name;
 };
=20
<snip>
.
.

I didn't see this problem with the other patches I applied today.

Thanks
Kishon

> changes in v5:
> - only compile debug uart functionality if the phy is compiled in
>   fixes initcall conflict and debug functionality also is only really
>   usable if it's available early
> changes in v4:
> - drop the rest of the phy-series, as the patches have gotten applied
> 
> So far, this hasn't gotten eyeballs yet, so citing discussion-parts from
> the v3 coverletter:
> 
> The patch, while not associated with the new pll handling, also builds
> on the groundwork introduced there and adds support for the function
> repurposing one of the phys as passthrough for uart-data. This enables
> attaching a ttl converter to the D+ and D- pins of an usb cable to
> receive uart data this way, when it is not really possible to attach
> a regular serial console to a board.
> 
> One point of critique in my first iteration [0] of this was, that
> due to when the reconfiguration happens we may miss parts of the logs
> when earlycon is enabled. So far early_initcall gets used as the
> unflattened devicetree is necessary to set this up. Doing this for
> example in the early_param directly would require parsing the flattened
> devicetree to get needed nodes and properties.
> 
> I still maintain that if you're working on anything before smp-bringup
> you should use a real dev-board instead or try to solder uart cables
> on hopefully available test-points  .
> 
> 
>  Documentation/kernel-parameters.txt |   6 +
>  drivers/phy/phy-rockchip-usb.c      | 233 ++++++++++++++++++++++++++++++------
>  2 files changed, 203 insertions(+), 36 deletions(-)
> 
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 87d40a7..d91417b 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -3486,6 +3486,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>  
>  	ro		[KNL] Mount root device read-only on boot
>  
> +	rockchip.usb_uart
> +			Enable the uart passthrough on the designated usb port
> +			on Rockchip SoCs. When active, the signals of the
> +			debug-uart get routed to the D+ and D- pins of the usb
> +			port and the regular usb controller gets disabled.
> +
>  	root=		[KNL] Root filesystem
>  			See name_to_dev_t comment in init/do_mounts.c.
>  
> diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
> index 33a80eb..f62d899 100644
> --- a/drivers/phy/phy-rockchip-usb.c
> +++ b/drivers/phy/phy-rockchip-usb.c
> @@ -30,21 +30,23 @@
>  #include <linux/regmap.h>
>  #include <linux/mfd/syscon.h>
>  
> -/*
> - * The higher 16-bit of this register is used for write protection
> - * only if BIT(13 + 16) set to 1 the BIT(13) can be written.
> - */
> -#define SIDDQ_WRITE_ENA	BIT(29)
> -#define SIDDQ_ON		BIT(13)
> -#define SIDDQ_OFF		(0 << 13)
> +static int enable_usb_uart;
> +
> +#define HIWORD_UPDATE(val, mask) \
> +		((val) | (mask) << 16)
> +
> +#define UOC_CON0_SIDDQ BIT(13)
>  
>  struct rockchip_usb_phys {
>  	int reg;
>  	const char *pll_name;
>  };
>  
> +struct rockchip_usb_phy_base;
>  struct rockchip_usb_phy_pdata {
>  	struct rockchip_usb_phys *phys;
> +	int (*init_usb_uart)(struct regmap *grf);
> +	int usb_uart_phy;
>  };
>  
>  struct rockchip_usb_phy_base {
> @@ -61,13 +63,15 @@ struct rockchip_usb_phy {
>  	struct clk      *clk480m;
>  	struct clk_hw	clk480m_hw;
>  	struct phy	*phy;
> +	bool		uart_enabled;
>  };
>  
>  static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
>  					   bool siddq)
>  {
> -	return regmap_write(phy->base->reg_base, phy->reg_offset,
> -			    SIDDQ_WRITE_ENA | (siddq ? SIDDQ_ON : SIDDQ_OFF));
> +	u32 val = HIWORD_UPDATE(siddq ? UOC_CON0_SIDDQ : 0, UOC_CON0_SIDDQ);
> +
> +	return regmap_write(phy->base->reg_base, phy->reg_offset, val);
>  }
>  
>  static unsigned long rockchip_usb_phy480m_recalc_rate(struct clk_hw *hw,
> @@ -108,7 +112,7 @@ static int rockchip_usb_phy480m_is_enabled(struct clk_hw *hw)
>  	if (ret < 0)
>  		return ret;
>  
> -	return (val & SIDDQ_ON) ? 0 : 1;
> +	return (val & UOC_CON0_SIDDQ) ? 0 : 1;
>  }
>  
>  static const struct clk_ops rockchip_usb_phy480m_ops = {
> @@ -122,6 +126,9 @@ static int rockchip_usb_phy_power_off(struct phy *_phy)
>  {
>  	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
>  
> +	if (phy->uart_enabled)
> +		return -EBUSY;
> +
>  	clk_disable_unprepare(phy->clk480m);
>  
>  	return 0;
> @@ -131,6 +138,9 @@ static int rockchip_usb_phy_power_on(struct phy *_phy)
>  {
>  	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
>  
> +	if (phy->uart_enabled)
> +		return -EBUSY;
> +
>  	return clk_prepare_enable(phy->clk480m);
>  }
>  
> @@ -144,8 +154,10 @@ static void rockchip_usb_phy_action(void *data)
>  {
>  	struct rockchip_usb_phy *rk_phy = data;
>  
> -	of_clk_del_provider(rk_phy->np);
> -	clk_unregister(rk_phy->clk480m);
> +	if (!rk_phy->uart_enabled) {
> +		of_clk_del_provider(rk_phy->np);
> +		clk_unregister(rk_phy->clk480m);
> +	}
>  
>  	if (rk_phy->clk)
>  		clk_put(rk_phy->clk);
> @@ -194,30 +206,35 @@ static int rockchip_usb_phy_init(struct rockchip_usb_phy_base *base,
>  		return -EINVAL;
>  	}
>  
> -	if (rk_phy->clk) {
> -		clk_name = __clk_get_name(rk_phy->clk);
> -		init.flags = 0;
> -		init.parent_names = &clk_name;
> -		init.num_parents = 1;
> +	if (enable_usb_uart && base->pdata->usb_uart_phy == i) {
> +		dev_dbg(base->dev, "phy%d used as uart output\n", i);
> +		rk_phy->uart_enabled = true;
>  	} else {
> -		init.flags = CLK_IS_ROOT;
> -		init.parent_names = NULL;
> -		init.num_parents = 0;
> -	}
> +		if (rk_phy->clk) {
> +			clk_name = __clk_get_name(rk_phy->clk);
> +			init.flags = 0;
> +			init.parent_names = &clk_name;
> +			init.num_parents = 1;
> +		} else {
> +			init.flags = CLK_IS_ROOT;
> +			init.parent_names = NULL;
> +			init.num_parents = 0;
> +		}
>  
> -	init.ops = &rockchip_usb_phy480m_ops;
> -	rk_phy->clk480m_hw.init = &init;
> +		init.ops = &rockchip_usb_phy480m_ops;
> +		rk_phy->clk480m_hw.init = &init;
>  
> -	rk_phy->clk480m = clk_register(base->dev, &rk_phy->clk480m_hw);
> -	if (IS_ERR(rk_phy->clk480m)) {
> -		err = PTR_ERR(rk_phy->clk480m);
> -		goto err_clk;
> -	}
> +		rk_phy->clk480m = clk_register(base->dev, &rk_phy->clk480m_hw);
> +		if (IS_ERR(rk_phy->clk480m)) {
> +			err = PTR_ERR(rk_phy->clk480m);
> +			goto err_clk;
> +		}
>  
> -	err = of_clk_add_provider(child, of_clk_src_simple_get,
> -				  rk_phy->clk480m);
> -	if (err < 0)
> -		goto err_clk_prov;
> +		err = of_clk_add_provider(child, of_clk_src_simple_get,
> +					rk_phy->clk480m);
> +		if (err < 0)
> +			goto err_clk_prov;
> +	}
>  
>  	err = devm_add_action(base->dev, rockchip_usb_phy_action, rk_phy);
>  	if (err)
> @@ -230,13 +247,21 @@ static int rockchip_usb_phy_init(struct rockchip_usb_phy_base *base,
>  	}
>  	phy_set_drvdata(rk_phy->phy, rk_phy);
>  
> -	/* only power up usb phy when it use, so disable it when init*/
> -	return rockchip_usb_phy_power(rk_phy, 1);
> +	/*
> +	 * When acting as uart-pipe, just keep clock on otherwise
> +	 * only power up usb phy when it use, so disable it when init
> +	 */
> +	if (rk_phy->uart_enabled)
> +		return clk_prepare_enable(rk_phy->clk);
> +	else
> +		return rockchip_usb_phy_power(rk_phy, 1);
>  
>  err_devm_action:
> -	of_clk_del_provider(child);
> +	if (!rk_phy->uart_enabled)
> +		of_clk_del_provider(child);
>  err_clk_prov:
> -	clk_unregister(rk_phy->clk480m);
> +	if (!rk_phy->uart_enabled)
> +		clk_unregister(rk_phy->clk480m);
>  err_clk:
>  	if (rk_phy->clk)
>  		clk_put(rk_phy->clk);
> @@ -259,6 +284,86 @@ static const struct rockchip_usb_phy_pdata rk3188_pdata = {
>  	},
>  };
>  
> +#define RK3288_UOC0_CON0				0x320
> +#define RK3288_UOC0_CON0_COMMON_ON_N			BIT(0)
> +#define RK3288_UOC0_CON0_DISABLE			BIT(4)
> +
> +#define RK3288_UOC0_CON2				0x328
> +#define RK3288_UOC0_CON2_SOFT_CON_SEL			BIT(2)
> +
> +#define RK3288_UOC0_CON3				0x32c
> +#define RK3288_UOC0_CON3_UTMI_SUSPENDN			BIT(0)
> +#define RK3288_UOC0_CON3_UTMI_OPMODE_NODRIVING		(1 << 1)
> +#define RK3288_UOC0_CON3_UTMI_OPMODE_MASK		(3 << 1)
> +#define RK3288_UOC0_CON3_UTMI_XCVRSEELCT_FSTRANSC	(1 << 3)
> +#define RK3288_UOC0_CON3_UTMI_XCVRSEELCT_MASK		(3 << 3)
> +#define RK3288_UOC0_CON3_UTMI_TERMSEL_FULLSPEED		BIT(5)
> +#define RK3288_UOC0_CON3_BYPASSDMEN			BIT(6)
> +#define RK3288_UOC0_CON3_BYPASSSEL			BIT(7)
> +
> +/*
> + * Enable the bypass of uart2 data through the otg usb phy.
> + * Original description in the TRM.
> + * 1. Disable the OTG block by setting OTGDISABLE0 to 1?b1.
> + * 2. Disable the pull-up resistance on the D+ line by setting
> + *    OPMODE0[1:0] to 2?b01.
> + * 3. To ensure that the XO, Bias, and PLL blocks are powered down in Suspend
> + *    mode, set COMMONONN to 1?b1.
> + * 4. Place the USB PHY in Suspend mode by setting SUSPENDM0 to 1?b0.
> + * 5. Set BYPASSSEL0 to 1?b1.
> + * 6. To transmit data, controls BYPASSDMEN0, and BYPASSDMDATA0.
> + * To receive data, monitor FSVPLUS0.
> + *
> + * The actual code in the vendor kernel does some things differently.
> + */
> +static int __init rk3288_init_usb_uart(struct regmap *grf)
> +{
> +	u32 val;
> +	int ret;
> +
> +	/*
> +	 * COMMON_ON and DISABLE settings are described in the TRM,
> +	 * but were not present in the original code.
> +	 * Also disable the analog phy components to save power.
> +	 */
> +	val = HIWORD_UPDATE(RK3288_UOC0_CON0_COMMON_ON_N
> +				| RK3288_UOC0_CON0_DISABLE
> +				| UOC_CON0_SIDDQ,
> +			    RK3288_UOC0_CON0_COMMON_ON_N
> +				| RK3288_UOC0_CON0_DISABLE
> +				| UOC_CON0_SIDDQ);
> +	ret = regmap_write(grf, RK3288_UOC0_CON0, val);
> +	if (ret)
> +		return ret;
> +
> +	val = HIWORD_UPDATE(RK3288_UOC0_CON2_SOFT_CON_SEL,
> +			    RK3288_UOC0_CON2_SOFT_CON_SEL);
> +	ret = regmap_write(grf, RK3288_UOC0_CON2, val);
> +	if (ret)
> +		return ret;
> +
> +	val = HIWORD_UPDATE(RK3288_UOC0_CON3_UTMI_OPMODE_NODRIVING
> +				| RK3288_UOC0_CON3_UTMI_XCVRSEELCT_FSTRANSC
> +				| RK3288_UOC0_CON3_UTMI_TERMSEL_FULLSPEED,
> +			    RK3288_UOC0_CON3_UTMI_SUSPENDN
> +				| RK3288_UOC0_CON3_UTMI_OPMODE_MASK
> +				| RK3288_UOC0_CON3_UTMI_XCVRSEELCT_MASK
> +				| RK3288_UOC0_CON3_UTMI_TERMSEL_FULLSPEED);
> +	ret = regmap_write(grf, RK3288_UOC0_CON3, val);
> +	if (ret)
> +		return ret;
> +
> +	val = HIWORD_UPDATE(RK3288_UOC0_CON3_BYPASSSEL
> +				| RK3288_UOC0_CON3_BYPASSDMEN,
> +			    RK3288_UOC0_CON3_BYPASSSEL
> +				| RK3288_UOC0_CON3_BYPASSDMEN);
> +	ret = regmap_write(grf, RK3288_UOC0_CON3, val);
> +	if (ret)
> +		return ret;
> +
> +	return 0;
> +}
> +
>  static const struct rockchip_usb_phy_pdata rk3288_pdata = {
>  	.phys = (struct rockchip_usb_phys[]){
>  		{ .reg = 0x320, .pll_name = "sclk_otgphy0_480m" },
> @@ -266,6 +371,8 @@ static const struct rockchip_usb_phy_pdata rk3288_pdata = {
>  		{ .reg = 0x348, .pll_name = "sclk_otgphy2_480m" },
>  		{ /* sentinel */ }
>  	},
> +	.init_usb_uart = rk3288_init_usb_uart,
> +	.usb_uart_phy = 0,
>  };
>  
>  static int rockchip_usb_phy_probe(struct platform_device *pdev)
> @@ -328,6 +435,60 @@ static struct platform_driver rockchip_usb_driver = {
>  
>  module_platform_driver(rockchip_usb_driver);
>  
> +#ifndef MODULE
> +static int __init rockchip_init_usb_uart(void)
> +{
> +	const struct of_device_id *match;
> +	const struct rockchip_usb_phy_pdata *data;
> +	struct device_node *np;
> +	struct regmap *grf;
> +	int ret;
> +
> +	if (!enable_usb_uart)
> +		return 0;
> +
> +	np = of_find_matching_node_and_match(NULL, rockchip_usb_phy_dt_ids,
> +					     &match);
> +	if (!np) {
> +		pr_err("%s: failed to find usbphy node\n", __func__);
> +		return -ENOTSUPP;
> +	}
> +
> +	pr_debug("%s: using settings for %s\n", __func__, match->compatible);
> +	data = match->data;
> +
> +	if (!data->init_usb_uart) {
> +		pr_err("%s: usb-uart not available on %s\n",
> +		       __func__, match->compatible);
> +		return -ENOTSUPP;
> +	}
> +
> +	grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
> +	if (IS_ERR(grf)) {
> +		pr_err("%s: Missing rockchip,grf property, %lu\n",
> +		       __func__, PTR_ERR(grf));
> +		return PTR_ERR(grf);
> +	}
> +
> +	ret = data->init_usb_uart(grf);
> +	if (ret) {
> +		pr_err("%s: could not init usb_uart, %d\n", __func__, ret);
> +		enable_usb_uart = 0;
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +early_initcall(rockchip_init_usb_uart);
> +
> +static int __init rockchip_usb_uart(char *buf)
> +{
> +	enable_usb_uart = true;
> +	return 0;
> +}
> +early_param("rockchip.usb_uart", rockchip_usb_uart);
> +#endif
> +
>  MODULE_AUTHOR("Yunzhi Li <lyz at rock-chips.com>");
>  MODULE_DESCRIPTION("Rockchip USB 2.0 PHY driver");
>  MODULE_LICENSE("GPL v2");
> 


From ard.biesheuvel at linaro.org  Mon Feb 22 03:51:09 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 12:51:09 +0100
Subject: [PATCH 3/3] arm64: ptdump: include UEFI runtime service mappings
In-Reply-To: <20160222112901.GA3435@leverpostej>
References: <1456135239-3607-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456135239-3607-4-git-send-email-ard.biesheuvel@linaro.org>
 <20160222112901.GA3435@leverpostej>
Message-ID: <CAKv+Gu8RCrZJ4F8CA+FWTBe+WaF11BTJiM0cRiHJH_b0snk-yA@mail.gmail.com>

On 22 February 2016 at 12:29, Mark Rutland <mark.rutland at arm.com> wrote:
> Hi,
>
> On Mon, Feb 22, 2016 at 11:00:39AM +0100, Ard Biesheuvel wrote:
>> This adds the UEFI runtime services page table mappings to the output
>> of the kernel page table dumper. These tables are only live during the
>> time UEFI runtime services are being invoked, but we can include them
>> for informational purposes nonetheless.
>
> I would prefer that we had a separate file for the EFI runtime services
> page tables. As you mention, they are distinct from the kernel and not
> always live (which is also the case for the idmap, for example).
>
> I have some local patches atop of v4.3 that librify the dumping code and
> add a separate file for EFI [1]. I spotted a couple other things in
> doing that (e.g. that we need to pad addresses more).
>
> Is it worth cleaning that up?
>

I think so. It would be especially nice if we could share the
registration API between ARM and arm64, since the ptdump code is very
similar, and the UEFI range is identical between them


>>
>> Cc: Matt Fleming <matt at codeblueprint.co.uk>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> ---
>>  arch/arm64/mm/dump.c               | 8 ++++++++
>>  drivers/firmware/efi/arm-runtime.c | 2 +-
>>  2 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
>> index 12e4b1732303..e7b937c9ad52 100644
>> --- a/arch/arm64/mm/dump.c
>> +++ b/arch/arm64/mm/dump.c
>> @@ -36,6 +36,10 @@ struct addr_marker {
>>  };
>>
>>  static struct addr_marker address_markers[] = {
>> +#ifdef CONFIG_EFI
>> +     { 0,                            "UEFI runtime start" },
>> +     { TASK_SIZE_64,                 "UEFI runtime end" },
>> +#endif
>>  #ifdef CONFIG_KASAN
>>       { KASAN_SHADOW_START,           "Kasan shadow start" },
>>       { KASAN_SHADOW_END,             "Kasan shadow end" },
>> @@ -310,6 +314,10 @@ static int ptdump_show(struct seq_file *m, void *v)
>>               .marker = address_markers,
>>       };
>>
>> +     if (IS_ENABLED(CONFIG_EFI)) {
>> +             extern struct mm_struct efi_mm;
>> +             walk_pgd(&st, &efi_mm, 0);
>> +     }
>>       walk_pgd(&st, &init_mm, LOWEST_ADDR);
>>
>>       note_page(&st, 0, 0, 0);
>> diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
>> index 6ae21e41a429..3a3911641049 100644
>> --- a/drivers/firmware/efi/arm-runtime.c
>> +++ b/drivers/firmware/efi/arm-runtime.c
>> @@ -30,7 +30,7 @@
>>
>>  extern u64 efi_system_table;
>>
>> -static struct mm_struct efi_mm = {
>> +struct mm_struct efi_mm = {
>>       .mm_rb                  = RB_ROOT,
>>       .mm_users               = ATOMIC_INIT(2),
>>       .mm_count               = ATOMIC_INIT(1),
>> --
>> 2.5.0
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>


From Liviu.Dudau at arm.com  Mon Feb 22 03:51:47 2016
From: Liviu.Dudau at arm.com (Liviu Dudau)
Date: Mon, 22 Feb 2016 11:51:47 +0000
Subject: [PATCH v2 1/2] drm: Improve drm_of_component_probe() to
 correctly handle ports and remote ports.
In-Reply-To: <1448029325-14602-2-git-send-email-Liviu.Dudau@arm.com>
References: <1448029325-14602-1-git-send-email-Liviu.Dudau@arm.com>
 <1448029325-14602-2-git-send-email-Liviu.Dudau@arm.com>
Message-ID: <20160222115147.GR1123@e106497-lin.cambridge.arm.com>

On Fri, Nov 20, 2015 at 02:22:04PM +0000, Liviu Dudau wrote:
> Rockchip DRM driver cannot use the same compare_of() function to
> match ports and remote ports (aka encoders) as their OF sub-trees
> look different. Add a second compare function to be used when encoders
> are added to the component framework and patch the existing users of
> the function accordingly.
> 
> Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>

Russell,

Resurecting this old patch from around Christmas time (bad time for patch review).

Are you happy enough with this version to re-issue the Ack or do you think I still
need to work on it?

Best regards,
Liviu

> ---
>  drivers/gpu/drm/armada/armada_drv.c |  3 ++-
>  drivers/gpu/drm/drm_of.c            | 19 ++++++++++++++-----
>  drivers/gpu/drm/imx/imx-drm-core.c  |  3 ++-
>  include/drm/drm_of.h                |  6 ++++--
>  4 files changed, 22 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
> index 77ab93d..3a2a929 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -274,7 +274,8 @@ static int armada_drm_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	int ret;
>  
> -	ret = drm_of_component_probe(dev, compare_dev_name, &armada_master_ops);
> +	ret = drm_of_component_probe(dev, compare_dev_name, compare_dev_name,
> +				     &armada_master_ops);
>  	if (ret != -EINVAL)
>  		return ret;
>  
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index 493c05c..34589d3 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -77,7 +77,8 @@ EXPORT_SYMBOL(drm_of_find_possible_crtcs);
>   * Returns zero if successful, or one of the standard error codes if it fails.
>   */
>  int drm_of_component_probe(struct device *dev,
> -			   int (*compare_of)(struct device *, void *),
> +			   int (*compare_port)(struct device *, void *),
> +			   int (*compare_encoder)(struct device *, void *),
>  			   const struct component_master_ops *m_ops)
>  {
>  	struct device_node *ep, *port, *remote;
> @@ -101,8 +102,12 @@ int drm_of_component_probe(struct device *dev,
>  			continue;
>  		}
>  
> -		component_match_add(dev, &match, compare_of, port);
> -		of_node_put(port);
> +		component_match_add(dev, &match, compare_port, port);
> +		/*
> +		 * component_match_add keeps a reference to the port
> +		 * variable, so we need to keep the reference count
> +		 * increment from of_parse_phandle()
> +		 */
>  	}
>  
>  	if (i == 0) {
> @@ -140,8 +145,12 @@ int drm_of_component_probe(struct device *dev,
>  				continue;
>  			}
>  
> -			component_match_add(dev, &match, compare_of, remote);
> -			of_node_put(remote);
> +			component_match_add(dev, &match, compare_encoder, remote);
> +			/*
> +			 * component_match_add keeps a reference to the port
> +			 * variable, so we need to keep the reference count
> +			 * increment from of_graph_get_remote_port_parent()
> +			 */
>  		}
>  		of_node_put(port);
>  	}
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c
> index 64f16ea..0d36410 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -531,7 +531,8 @@ static const struct component_master_ops imx_drm_ops = {
>  
>  static int imx_drm_platform_probe(struct platform_device *pdev)
>  {
> -	int ret = drm_of_component_probe(&pdev->dev, compare_of, &imx_drm_ops);
> +	int ret = drm_of_component_probe(&pdev->dev, compare_of, compare_of,
> +					 &imx_drm_ops);
>  
>  	if (!ret)
>  		ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> index 8544665..1c29e42 100644
> --- a/include/drm/drm_of.h
> +++ b/include/drm/drm_of.h
> @@ -10,7 +10,8 @@ struct device_node;
>  extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>  					   struct device_node *port);
>  extern int drm_of_component_probe(struct device *dev,
> -				  int (*compare_of)(struct device *, void *),
> +				  int (*compare_port)(struct device *, void *),
> +				  int (*compare_encoder)(struct device *, void *),
>  				  const struct component_master_ops *m_ops);
>  #else
>  static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> @@ -21,7 +22,8 @@ static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>  
>  static inline int
>  drm_of_component_probe(struct device *dev,
> -		       int (*compare_of)(struct device *, void *),
> +		       int (*compare_port)(struct device *, void *),
> +		       int (*compare_encoder)(struct device *, void *),
>  		       const struct component_master_ops *m_ops)
>  {
>  	return -EINVAL;
> -- 
> 2.6.2
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?


From brian.starkey at arm.com  Mon Feb 22 03:52:43 2016
From: brian.starkey at arm.com (Brian Starkey)
Date: Mon, 22 Feb 2016 11:52:43 +0000
Subject: next-20160222 build: 5 failures 9 warnings (next-20160222)
In-Reply-To: <56CAE5E6.7030707@arm.com>
References: <E1aXlz4-000486-Pb@optimist> <20160222100832.GX18327@sirena.org.uk>
 <56CAE5E6.7030707@arm.com>
Message-ID: <20160222115243.GA5779@e106950-lin.cambridge.arm.com>

Hi Mark,

On Mon, Feb 22, 2016 at 10:41:42AM +0000, Marc Zyngier wrote:
>I'm about to push the following patch on top of the KVM tree:
>
>diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>index 43688d9..31fe7d6 100644
>--- a/arch/arm64/include/asm/kvm_host.h
>+++ b/arch/arm64/include/asm/kvm_host.h
>@@ -333,11 +333,6 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
> 		     hyp_stack_ptr, vector_ptr);
> }
>
>-static inline void __cpu_init_stage2(void)
>-{
>-	kvm_call_hyp(__init_stage2_translation);
>-}
>-
> static inline void kvm_arch_hardware_disable(void) {}
> static inline void kvm_arch_hardware_unsetup(void) {}
> static inline void kvm_arch_sync_events(struct kvm *kvm) {}
>@@ -349,4 +344,11 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu);
> void kvm_arm_clear_debug(struct kvm_vcpu *vcpu);
> void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu);
>
>+/* #define kvm_call_hyp(f, ...) __kvm_call_hyp(kvm_ksym_ref(f), ##__VA_ARGS__) */
>+
>+static inline void __cpu_init_stage2(void)
>+{
>+	kvm_call_hyp(__init_stage2_translation);
>+}
>+
> #endif /* __ARM64_KVM_HOST_H__ */
>
>This will create a new conflict, but will make the resolution 100% clear.

I applied this, but arm64 defconfig wouldn't build until I uncommented
the '#define kvm_call_hyp(...' line.

Is that right?

Thanks,
Brian

>
>Thanks,
>
>	M.
>-- 
>Jazz is not dead. It just smells funny...
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>


From heiko at sntech.de  Mon Feb 22 03:53:21 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 22 Feb 2016 12:53:21 +0100
Subject: [PATCH v5.1] phy: rockchip-usb: add handler for usb-uart
 functionality
In-Reply-To: <56CAF4DE.2060708@ti.com>
References: <1670829.9XWsDys3pl@phil> <56CAF4DE.2060708@ti.com>
Message-ID: <2151229.sTi0mmqIUM@phil>

Am Montag, 22. Februar 2016, 17:15:34 schrieb Kishon Vijay Abraham I:
> > changes in v5.1:
> > - fix corruptions that happened when sending v5
> 
> I still see the corruption.
> 
> This is how I see the patch after downloading (from both mutt and
> thunderbird)

interesting ... I see this now too, but "git am" was happy with the encoding 
it seems, I did a
	git am foo.mbox
	git format-patch -1
	diff -u new.patch orig.patch

and the result did match (minus the comment section).
Anyway, I'll go with git send-email now ;-)


Sorry about that
Heiko

> @@ -3486,6 +3486,12 @@ bytes respectively. Such letter
> suffixes can also be= entirely omitted.
> =20
>         ro              [KNL] Mount root device read-only on boot
> =20
> +       rockchip.usb_uart
> +                       Enable the uart passthrough on the designated usb
> port +                       on Rockchip SoCs. When active, the signals
> of the +                       debug-uart get routed to the D+ and D-
> pins of the usb +                       port and the regular usb
> controller gets disabled. +
>         root=3D         [KNL] Root filesystem
>                         See name_to_dev_t comment in init/do_mounts.c.
> =20
> diff --git a/drivers/phy/phy-rockchip-usb.c
> b/drivers/phy/phy-rockchip-usb.= c
> index 33a80eb..f62d899 100644
> --- a/drivers/phy/phy-rockchip-usb.c
> +++ b/drivers/phy/phy-rockchip-usb.c
> @@ -30,21 +30,23 @@
>  #include <linux/regmap.h>
>  #include <linux/mfd/syscon.h>
> =20
> -/*
> - * The higher 16-bit of this register is used for write protection
> - * only if BIT(13 + 16) set to 1 the BIT(13) can be written.
> - */
> -#define SIDDQ_WRITE_ENA        BIT(29)
> -#define SIDDQ_ON               BIT(13)
> -#define SIDDQ_OFF              (0 << 13)
> +static int enable_usb_uart;
> +
> +#define HIWORD_UPDATE(val, mask) \
> +               ((val) | (mask) << 16)
> +
> +#define UOC_CON0_SIDDQ BIT(13)
> =20
>  struct rockchip_usb_phys {
>         int reg;
>         const char *pll_name;
>  };
> =20
> <snip>
> .
> .
> 
> I didn't see this problem with the other patches I applied today.
> 
> Thanks
> Kishon
> 
> > changes in v5:
> > - only compile debug uart functionality if the phy is compiled in
> > 
> >   fixes initcall conflict and debug functionality also is only really
> >   usable if it's available early
> > 
> > changes in v4:
> > - drop the rest of the phy-series, as the patches have gotten applied
> > 
> > So far, this hasn't gotten eyeballs yet, so citing discussion-parts from
> > the v3 coverletter:
> > 
> > The patch, while not associated with the new pll handling, also builds
> > on the groundwork introduced there and adds support for the function
> > repurposing one of the phys as passthrough for uart-data. This enables
> > attaching a ttl converter to the D+ and D- pins of an usb cable to
> > receive uart data this way, when it is not really possible to attach
> > a regular serial console to a board.
> > 
> > One point of critique in my first iteration [0] of this was, that
> > due to when the reconfiguration happens we may miss parts of the logs
> > when earlycon is enabled. So far early_initcall gets used as the
> > unflattened devicetree is necessary to set this up. Doing this for
> > example in the early_param directly would require parsing the flattened
> > devicetree to get needed nodes and properties.
> > 
> > I still maintain that if you're working on anything before smp-bringup
> > you should use a real dev-board instead or try to solder uart cables
> > on hopefully available test-points  .
> > 
> >  Documentation/kernel-parameters.txt |   6 +
> >  drivers/phy/phy-rockchip-usb.c      | 233
> >  ++++++++++++++++++++++++++++++------ 2 files changed, 203
> >  insertions(+), 36 deletions(-)
> > 
> > diff --git a/Documentation/kernel-parameters.txt
> > b/Documentation/kernel-parameters.txt index 87d40a7..d91417b 100644
> > --- a/Documentation/kernel-parameters.txt
> > +++ b/Documentation/kernel-parameters.txt
> > @@ -3486,6 +3486,12 @@ bytes respectively. Such letter suffixes can also
> > be entirely omitted.> 
> >  	ro		[KNL] Mount root device read-only on boot
> > 
> > +	rockchip.usb_uart
> > +			Enable the uart passthrough on the designated usb port
> > +			on Rockchip SoCs. When active, the signals of the
> > +			debug-uart get routed to the D+ and D- pins of the usb
> > +			port and the regular usb controller gets disabled.
> > +
> > 
> >  	root=		[KNL] Root filesystem
> >  	
> >  			See name_to_dev_t comment in init/do_mounts.c.
> > 
> > diff --git a/drivers/phy/phy-rockchip-usb.c
> > b/drivers/phy/phy-rockchip-usb.c index 33a80eb..f62d899 100644
> > --- a/drivers/phy/phy-rockchip-usb.c
> > +++ b/drivers/phy/phy-rockchip-usb.c
> > @@ -30,21 +30,23 @@
> > 
> >  #include <linux/regmap.h>
> >  #include <linux/mfd/syscon.h>
> > 
> > -/*
> > - * The higher 16-bit of this register is used for write protection
> > - * only if BIT(13 + 16) set to 1 the BIT(13) can be written.
> > - */
> > -#define SIDDQ_WRITE_ENA	BIT(29)
> > -#define SIDDQ_ON		BIT(13)
> > -#define SIDDQ_OFF		(0 << 13)
> > +static int enable_usb_uart;
> > +
> > +#define HIWORD_UPDATE(val, mask) \
> > +		((val) | (mask) << 16)
> > +
> > +#define UOC_CON0_SIDDQ BIT(13)
> > 
> >  struct rockchip_usb_phys {
> >  
> >  	int reg;
> >  	const char *pll_name;
> >  
> >  };
> > 
> > +struct rockchip_usb_phy_base;
> > 
> >  struct rockchip_usb_phy_pdata {
> >  
> >  	struct rockchip_usb_phys *phys;
> > 
> > +	int (*init_usb_uart)(struct regmap *grf);
> > +	int usb_uart_phy;
> > 
> >  };
> >  
> >  struct rockchip_usb_phy_base {
> > 
> > @@ -61,13 +63,15 @@ struct rockchip_usb_phy {
> > 
> >  	struct clk      *clk480m;
> >  	struct clk_hw	clk480m_hw;
> >  	struct phy	*phy;
> > 
> > +	bool		uart_enabled;
> > 
> >  };
> >  
> >  static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
> >  
> >  					   bool siddq)
> >  
> >  {
> > 
> > -	return regmap_write(phy->base->reg_base, phy->reg_offset,
> > -			    SIDDQ_WRITE_ENA | (siddq ? SIDDQ_ON : SIDDQ_OFF));
> > +	u32 val = HIWORD_UPDATE(siddq ? UOC_CON0_SIDDQ : 0, 
UOC_CON0_SIDDQ);
> > +
> > +	return regmap_write(phy->base->reg_base, phy->reg_offset, val);
> > 
> >  }
> >  
> >  static unsigned long rockchip_usb_phy480m_recalc_rate(struct clk_hw
> >  *hw,
> > 
> > @@ -108,7 +112,7 @@ static int rockchip_usb_phy480m_is_enabled(struct
> > clk_hw *hw)> 
> >  	if (ret < 0)
> >  	
> >  		return ret;
> > 
> > -	return (val & SIDDQ_ON) ? 0 : 1;
> > +	return (val & UOC_CON0_SIDDQ) ? 0 : 1;
> > 
> >  }
> >  
> >  static const struct clk_ops rockchip_usb_phy480m_ops = {
> > 
> > @@ -122,6 +126,9 @@ static int rockchip_usb_phy_power_off(struct phy
> > *_phy)> 
> >  {
> >  
> >  	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
> > 
> > +	if (phy->uart_enabled)
> > +		return -EBUSY;
> > +
> > 
> >  	clk_disable_unprepare(phy->clk480m);
> >  	
> >  	return 0;
> > 
> > @@ -131,6 +138,9 @@ static int rockchip_usb_phy_power_on(struct phy
> > *_phy)> 
> >  {
> >  
> >  	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
> > 
> > +	if (phy->uart_enabled)
> > +		return -EBUSY;
> > +
> > 
> >  	return clk_prepare_enable(phy->clk480m);
> >  
> >  }
> > 
> > @@ -144,8 +154,10 @@ static void rockchip_usb_phy_action(void *data)
> > 
> >  {
> >  
> >  	struct rockchip_usb_phy *rk_phy = data;
> > 
> > -	of_clk_del_provider(rk_phy->np);
> > -	clk_unregister(rk_phy->clk480m);
> > +	if (!rk_phy->uart_enabled) {
> > +		of_clk_del_provider(rk_phy->np);
> > +		clk_unregister(rk_phy->clk480m);
> > +	}
> > 
> >  	if (rk_phy->clk)
> >  	
> >  		clk_put(rk_phy->clk);
> > 
> > @@ -194,30 +206,35 @@ static int rockchip_usb_phy_init(struct
> > rockchip_usb_phy_base *base,> 
> >  		return -EINVAL;
> >  	
> >  	}
> > 
> > -	if (rk_phy->clk) {
> > -		clk_name = __clk_get_name(rk_phy->clk);
> > -		init.flags = 0;
> > -		init.parent_names = &clk_name;
> > -		init.num_parents = 1;
> > +	if (enable_usb_uart && base->pdata->usb_uart_phy == i) {
> > +		dev_dbg(base->dev, "phy%d used as uart output\n", i);
> > +		rk_phy->uart_enabled = true;
> > 
> >  	} else {
> > 
> > -		init.flags = CLK_IS_ROOT;
> > -		init.parent_names = NULL;
> > -		init.num_parents = 0;
> > -	}
> > +		if (rk_phy->clk) {
> > +			clk_name = __clk_get_name(rk_phy->clk);
> > +			init.flags = 0;
> > +			init.parent_names = &clk_name;
> > +			init.num_parents = 1;
> > +		} else {
> > +			init.flags = CLK_IS_ROOT;
> > +			init.parent_names = NULL;
> > +			init.num_parents = 0;
> > +		}
> > 
> > -	init.ops = &rockchip_usb_phy480m_ops;
> > -	rk_phy->clk480m_hw.init = &init;
> > +		init.ops = &rockchip_usb_phy480m_ops;
> > +		rk_phy->clk480m_hw.init = &init;
> > 
> > -	rk_phy->clk480m = clk_register(base->dev, &rk_phy->clk480m_hw);
> > -	if (IS_ERR(rk_phy->clk480m)) {
> > -		err = PTR_ERR(rk_phy->clk480m);
> > -		goto err_clk;
> > -	}
> > +		rk_phy->clk480m = clk_register(base->dev, &rk_phy->clk480m_hw);
> > +		if (IS_ERR(rk_phy->clk480m)) {
> > +			err = PTR_ERR(rk_phy->clk480m);
> > +			goto err_clk;
> > +		}
> > 
> > -	err = of_clk_add_provider(child, of_clk_src_simple_get,
> > -				  rk_phy->clk480m);
> > -	if (err < 0)
> > -		goto err_clk_prov;
> > +		err = of_clk_add_provider(child, of_clk_src_simple_get,
> > +					rk_phy->clk480m);
> > +		if (err < 0)
> > +			goto err_clk_prov;
> > +	}
> > 
> >  	err = devm_add_action(base->dev, rockchip_usb_phy_action, rk_phy);
> >  	if (err)
> > 
> > @@ -230,13 +247,21 @@ static int rockchip_usb_phy_init(struct
> > rockchip_usb_phy_base *base,> 
> >  	}
> >  	phy_set_drvdata(rk_phy->phy, rk_phy);
> > 
> > -	/* only power up usb phy when it use, so disable it when init*/
> > -	return rockchip_usb_phy_power(rk_phy, 1);
> > +	/*
> > +	 * When acting as uart-pipe, just keep clock on otherwise
> > +	 * only power up usb phy when it use, so disable it when init
> > +	 */
> > +	if (rk_phy->uart_enabled)
> > +		return clk_prepare_enable(rk_phy->clk);
> > +	else
> > +		return rockchip_usb_phy_power(rk_phy, 1);
> > 
> >  err_devm_action:
> > -	of_clk_del_provider(child);
> > +	if (!rk_phy->uart_enabled)
> > +		of_clk_del_provider(child);
> > 
> >  err_clk_prov:
> > -	clk_unregister(rk_phy->clk480m);
> > +	if (!rk_phy->uart_enabled)
> > +		clk_unregister(rk_phy->clk480m);
> > 
> >  err_clk:
> >  	if (rk_phy->clk)
> >  	
> >  		clk_put(rk_phy->clk);
> > 
> > @@ -259,6 +284,86 @@ static const struct rockchip_usb_phy_pdata
> > rk3188_pdata = {> 
> >  	},
> >  
> >  };
> > 
> > +#define RK3288_UOC0_CON0				0x320
> > +#define RK3288_UOC0_CON0_COMMON_ON_N			BIT(0)
> > +#define RK3288_UOC0_CON0_DISABLE			BIT(4)
> > +
> > +#define RK3288_UOC0_CON2				0x328
> > +#define RK3288_UOC0_CON2_SOFT_CON_SEL			BIT(2)
> > +
> > +#define RK3288_UOC0_CON3				0x32c
> > +#define RK3288_UOC0_CON3_UTMI_SUSPENDN			BIT(0)
> > +#define RK3288_UOC0_CON3_UTMI_OPMODE_NODRIVING		(1 << 1)
> > +#define RK3288_UOC0_CON3_UTMI_OPMODE_MASK		(3 << 1)
> > +#define RK3288_UOC0_CON3_UTMI_XCVRSEELCT_FSTRANSC	(1 << 3)
> > +#define RK3288_UOC0_CON3_UTMI_XCVRSEELCT_MASK		(3 << 3)
> > +#define RK3288_UOC0_CON3_UTMI_TERMSEL_FULLSPEED		BIT(5)
> > +#define RK3288_UOC0_CON3_BYPASSDMEN			BIT(6)
> > +#define RK3288_UOC0_CON3_BYPASSSEL			BIT(7)
> > +
> > +/*
> > + * Enable the bypass of uart2 data through the otg usb phy.
> > + * Original description in the TRM.
> > + * 1. Disable the OTG block by setting OTGDISABLE0 to 1?b1.
> > + * 2. Disable the pull-up resistance on the D+ line by setting
> > + *    OPMODE0[1:0] to 2?b01.
> > + * 3. To ensure that the XO, Bias, and PLL blocks are powered down in
> > Suspend + *    mode, set COMMONONN to 1?b1.
> > + * 4. Place the USB PHY in Suspend mode by setting SUSPENDM0 to 1?b0.
> > + * 5. Set BYPASSSEL0 to 1?b1.
> > + * 6. To transmit data, controls BYPASSDMEN0, and BYPASSDMDATA0.
> > + * To receive data, monitor FSVPLUS0.
> > + *
> > + * The actual code in the vendor kernel does some things differently.
> > + */
> > +static int __init rk3288_init_usb_uart(struct regmap *grf)
> > +{
> > +	u32 val;
> > +	int ret;
> > +
> > +	/*
> > +	 * COMMON_ON and DISABLE settings are described in the TRM,
> > +	 * but were not present in the original code.
> > +	 * Also disable the analog phy components to save power.
> > +	 */
> > +	val = HIWORD_UPDATE(RK3288_UOC0_CON0_COMMON_ON_N
> > +				| RK3288_UOC0_CON0_DISABLE
> > +				| UOC_CON0_SIDDQ,
> > +			    RK3288_UOC0_CON0_COMMON_ON_N
> > +				| RK3288_UOC0_CON0_DISABLE
> > +				| UOC_CON0_SIDDQ);
> > +	ret = regmap_write(grf, RK3288_UOC0_CON0, val);
> > +	if (ret)
> > +		return ret;
> > +
> > +	val = HIWORD_UPDATE(RK3288_UOC0_CON2_SOFT_CON_SEL,
> > +			    RK3288_UOC0_CON2_SOFT_CON_SEL);
> > +	ret = regmap_write(grf, RK3288_UOC0_CON2, val);
> > +	if (ret)
> > +		return ret;
> > +
> > +	val = HIWORD_UPDATE(RK3288_UOC0_CON3_UTMI_OPMODE_NODRIVING
> > +				| RK3288_UOC0_CON3_UTMI_XCVRSEELCT_FSTRANSC
> > +				| RK3288_UOC0_CON3_UTMI_TERMSEL_FULLSPEED,
> > +			    RK3288_UOC0_CON3_UTMI_SUSPENDN
> > +				| RK3288_UOC0_CON3_UTMI_OPMODE_MASK
> > +				| RK3288_UOC0_CON3_UTMI_XCVRSEELCT_MASK
> > +				| RK3288_UOC0_CON3_UTMI_TERMSEL_FULLSPEED);
> > +	ret = regmap_write(grf, RK3288_UOC0_CON3, val);
> > +	if (ret)
> > +		return ret;
> > +
> > +	val = HIWORD_UPDATE(RK3288_UOC0_CON3_BYPASSSEL
> > +				| RK3288_UOC0_CON3_BYPASSDMEN,
> > +			    RK3288_UOC0_CON3_BYPASSSEL
> > +				| RK3288_UOC0_CON3_BYPASSDMEN);
> > +	ret = regmap_write(grf, RK3288_UOC0_CON3, val);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return 0;
> > +}
> > +
> > 
> >  static const struct rockchip_usb_phy_pdata rk3288_pdata = {
> >  
> >  	.phys = (struct rockchip_usb_phys[]){
> >  	
> >  		{ .reg = 0x320, .pll_name = "sclk_otgphy0_480m" },
> > 
> > @@ -266,6 +371,8 @@ static const struct rockchip_usb_phy_pdata
> > rk3288_pdata = {> 
> >  		{ .reg = 0x348, .pll_name = "sclk_otgphy2_480m" },
> >  		{ /* sentinel */ }
> >  	
> >  	},
> > 
> > +	.init_usb_uart = rk3288_init_usb_uart,
> > +	.usb_uart_phy = 0,
> > 
> >  };
> >  
> >  static int rockchip_usb_phy_probe(struct platform_device *pdev)
> > 
> > @@ -328,6 +435,60 @@ static struct platform_driver rockchip_usb_driver =
> > {> 
> >  module_platform_driver(rockchip_usb_driver);
> > 
> > +#ifndef MODULE
> > +static int __init rockchip_init_usb_uart(void)
> > +{
> > +	const struct of_device_id *match;
> > +	const struct rockchip_usb_phy_pdata *data;
> > +	struct device_node *np;
> > +	struct regmap *grf;
> > +	int ret;
> > +
> > +	if (!enable_usb_uart)
> > +		return 0;
> > +
> > +	np = of_find_matching_node_and_match(NULL, rockchip_usb_phy_dt_ids,
> > +					     &match);
> > +	if (!np) {
> > +		pr_err("%s: failed to find usbphy node\n", __func__);
> > +		return -ENOTSUPP;
> > +	}
> > +
> > +	pr_debug("%s: using settings for %s\n", __func__, match-
>compatible);
> > +	data = match->data;
> > +
> > +	if (!data->init_usb_uart) {
> > +		pr_err("%s: usb-uart not available on %s\n",
> > +		       __func__, match->compatible);
> > +		return -ENOTSUPP;
> > +	}
> > +
> > +	grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
> > +	if (IS_ERR(grf)) {
> > +		pr_err("%s: Missing rockchip,grf property, %lu\n",
> > +		       __func__, PTR_ERR(grf));
> > +		return PTR_ERR(grf);
> > +	}
> > +
> > +	ret = data->init_usb_uart(grf);
> > +	if (ret) {
> > +		pr_err("%s: could not init usb_uart, %d\n", __func__, ret);
> > +		enable_usb_uart = 0;
> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +early_initcall(rockchip_init_usb_uart);
> > +
> > +static int __init rockchip_usb_uart(char *buf)
> > +{
> > +	enable_usb_uart = true;
> > +	return 0;
> > +}
> > +early_param("rockchip.usb_uart", rockchip_usb_uart);
> > +#endif
> > +
> > 
> >  MODULE_AUTHOR("Yunzhi Li <lyz at rock-chips.com>");
> >  MODULE_DESCRIPTION("Rockchip USB 2.0 PHY driver");
> >  MODULE_LICENSE("GPL v2");



From heiko at sntech.de  Mon Feb 22 03:55:01 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Mon, 22 Feb 2016 12:55:01 +0100
Subject: [PATCH v5.2] phy: rockchip-usb: add handler for usb-uart functionality
Message-ID: <1456142101-20733-1-git-send-email-heiko@sntech.de>

Most newer Rockchip SoCs provide the possibility to use a usb-phy
as passthrough for the debug uart (uart2), making it possible to
for example get console output without needing to open the device.

This patch adds an early_initcall to enable this functionality
conditionally via the commandline and also disables the corresponding
usb controller in the devicetree.

Currently only data for the rk3288 is provided, but at least the
rk3188 and arm64 rk3368 also provide this functionality and will be
enabled later.

On a spliced usb cable the signals are tx on white wire(D+) and
rx on green wire(D-).

The one caveat is that currently the reconfiguration of the phy
happens as early_initcall, as the code depends on the unflattened
devicetree being available. Everything is fine if only a regular
console is active as the console-replay will happen after the
reconfiguation. But with earlycon active output up to smp-init
currently will get lost.

The phy is an optional property for the connected dwc2 controller,
so we still provide the phy device but fail all phy-ops with -EBUSY
to make sure the dwc2 does not try to transmit anything on the
repurposed phy.

Signed-off-by: Heiko Stuebner <heiko at sntech.de>
---
changes in v5.2:
- pristine git send-email now to fix strange encoding effects
changes in v5.1:
- fix corruptions that happened when sending v5
changes in v5:
- only compile debug uart functionality if the phy is compiled in
  fixes initcall conflict and debug functionality also is only really
  usable if it's available early
changes in v4:
- drop the rest of the phy-series, as the patches have gotten applied

So far, this hasn't gotten eyeballs yet, so citing discussion-parts from
the v3 coverletter:

The patch, while not associated with the new pll handling, also builds
on the groundwork introduced there and adds support for the function
repurposing one of the phys as passthrough for uart-data. This enables
attaching a ttl converter to the D+ and D- pins of an usb cable to
receive uart data this way, when it is not really possible to attach
a regular serial console to a board.

One point of critique in my first iteration [0] of this was, that
due to when the reconfiguration happens we may miss parts of the logs
when earlycon is enabled. So far early_initcall gets used as the
unflattened devicetree is necessary to set this up. Doing this for
example in the early_param directly would require parsing the flattened
devicetree to get needed nodes and properties.

I still maintain that if you're working on anything before smp-bringup
you should use a real dev-board instead or try to solder uart cables
on hopefully available test-points  .


 Documentation/kernel-parameters.txt |   6 +
 drivers/phy/phy-rockchip-usb.c      | 233 ++++++++++++++++++++++++++++++------
 2 files changed, 203 insertions(+), 36 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 87d40a7..d91417b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3486,6 +3486,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
 	ro		[KNL] Mount root device read-only on boot
 
+	rockchip.usb_uart
+			Enable the uart passthrough on the designated usb port
+			on Rockchip SoCs. When active, the signals of the
+			debug-uart get routed to the D+ and D- pins of the usb
+			port and the regular usb controller gets disabled.
+
 	root=		[KNL] Root filesystem
 			See name_to_dev_t comment in init/do_mounts.c.
 
diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
index 33a80eb..f62d899 100644
--- a/drivers/phy/phy-rockchip-usb.c
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -30,21 +30,23 @@
 #include <linux/regmap.h>
 #include <linux/mfd/syscon.h>
 
-/*
- * The higher 16-bit of this register is used for write protection
- * only if BIT(13 + 16) set to 1 the BIT(13) can be written.
- */
-#define SIDDQ_WRITE_ENA	BIT(29)
-#define SIDDQ_ON		BIT(13)
-#define SIDDQ_OFF		(0 << 13)
+static int enable_usb_uart;
+
+#define HIWORD_UPDATE(val, mask) \
+		((val) | (mask) << 16)
+
+#define UOC_CON0_SIDDQ BIT(13)
 
 struct rockchip_usb_phys {
 	int reg;
 	const char *pll_name;
 };
 
+struct rockchip_usb_phy_base;
 struct rockchip_usb_phy_pdata {
 	struct rockchip_usb_phys *phys;
+	int (*init_usb_uart)(struct regmap *grf);
+	int usb_uart_phy;
 };
 
 struct rockchip_usb_phy_base {
@@ -61,13 +63,15 @@ struct rockchip_usb_phy {
 	struct clk      *clk480m;
 	struct clk_hw	clk480m_hw;
 	struct phy	*phy;
+	bool		uart_enabled;
 };
 
 static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
 					   bool siddq)
 {
-	return regmap_write(phy->base->reg_base, phy->reg_offset,
-			    SIDDQ_WRITE_ENA | (siddq ? SIDDQ_ON : SIDDQ_OFF));
+	u32 val = HIWORD_UPDATE(siddq ? UOC_CON0_SIDDQ : 0, UOC_CON0_SIDDQ);
+
+	return regmap_write(phy->base->reg_base, phy->reg_offset, val);
 }
 
 static unsigned long rockchip_usb_phy480m_recalc_rate(struct clk_hw *hw,
@@ -108,7 +112,7 @@ static int rockchip_usb_phy480m_is_enabled(struct clk_hw *hw)
 	if (ret < 0)
 		return ret;
 
-	return (val & SIDDQ_ON) ? 0 : 1;
+	return (val & UOC_CON0_SIDDQ) ? 0 : 1;
 }
 
 static const struct clk_ops rockchip_usb_phy480m_ops = {
@@ -122,6 +126,9 @@ static int rockchip_usb_phy_power_off(struct phy *_phy)
 {
 	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
 
+	if (phy->uart_enabled)
+		return -EBUSY;
+
 	clk_disable_unprepare(phy->clk480m);
 
 	return 0;
@@ -131,6 +138,9 @@ static int rockchip_usb_phy_power_on(struct phy *_phy)
 {
 	struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
 
+	if (phy->uart_enabled)
+		return -EBUSY;
+
 	return clk_prepare_enable(phy->clk480m);
 }
 
@@ -144,8 +154,10 @@ static void rockchip_usb_phy_action(void *data)
 {
 	struct rockchip_usb_phy *rk_phy = data;
 
-	of_clk_del_provider(rk_phy->np);
-	clk_unregister(rk_phy->clk480m);
+	if (!rk_phy->uart_enabled) {
+		of_clk_del_provider(rk_phy->np);
+		clk_unregister(rk_phy->clk480m);
+	}
 
 	if (rk_phy->clk)
 		clk_put(rk_phy->clk);
@@ -194,30 +206,35 @@ static int rockchip_usb_phy_init(struct rockchip_usb_phy_base *base,
 		return -EINVAL;
 	}
 
-	if (rk_phy->clk) {
-		clk_name = __clk_get_name(rk_phy->clk);
-		init.flags = 0;
-		init.parent_names = &clk_name;
-		init.num_parents = 1;
+	if (enable_usb_uart && base->pdata->usb_uart_phy == i) {
+		dev_dbg(base->dev, "phy%d used as uart output\n", i);
+		rk_phy->uart_enabled = true;
 	} else {
-		init.flags = CLK_IS_ROOT;
-		init.parent_names = NULL;
-		init.num_parents = 0;
-	}
+		if (rk_phy->clk) {
+			clk_name = __clk_get_name(rk_phy->clk);
+			init.flags = 0;
+			init.parent_names = &clk_name;
+			init.num_parents = 1;
+		} else {
+			init.flags = CLK_IS_ROOT;
+			init.parent_names = NULL;
+			init.num_parents = 0;
+		}
 
-	init.ops = &rockchip_usb_phy480m_ops;
-	rk_phy->clk480m_hw.init = &init;
+		init.ops = &rockchip_usb_phy480m_ops;
+		rk_phy->clk480m_hw.init = &init;
 
-	rk_phy->clk480m = clk_register(base->dev, &rk_phy->clk480m_hw);
-	if (IS_ERR(rk_phy->clk480m)) {
-		err = PTR_ERR(rk_phy->clk480m);
-		goto err_clk;
-	}
+		rk_phy->clk480m = clk_register(base->dev, &rk_phy->clk480m_hw);
+		if (IS_ERR(rk_phy->clk480m)) {
+			err = PTR_ERR(rk_phy->clk480m);
+			goto err_clk;
+		}
 
-	err = of_clk_add_provider(child, of_clk_src_simple_get,
-				  rk_phy->clk480m);
-	if (err < 0)
-		goto err_clk_prov;
+		err = of_clk_add_provider(child, of_clk_src_simple_get,
+					rk_phy->clk480m);
+		if (err < 0)
+			goto err_clk_prov;
+	}
 
 	err = devm_add_action(base->dev, rockchip_usb_phy_action, rk_phy);
 	if (err)
@@ -230,13 +247,21 @@ static int rockchip_usb_phy_init(struct rockchip_usb_phy_base *base,
 	}
 	phy_set_drvdata(rk_phy->phy, rk_phy);
 
-	/* only power up usb phy when it use, so disable it when init*/
-	return rockchip_usb_phy_power(rk_phy, 1);
+	/*
+	 * When acting as uart-pipe, just keep clock on otherwise
+	 * only power up usb phy when it use, so disable it when init
+	 */
+	if (rk_phy->uart_enabled)
+		return clk_prepare_enable(rk_phy->clk);
+	else
+		return rockchip_usb_phy_power(rk_phy, 1);
 
 err_devm_action:
-	of_clk_del_provider(child);
+	if (!rk_phy->uart_enabled)
+		of_clk_del_provider(child);
 err_clk_prov:
-	clk_unregister(rk_phy->clk480m);
+	if (!rk_phy->uart_enabled)
+		clk_unregister(rk_phy->clk480m);
 err_clk:
 	if (rk_phy->clk)
 		clk_put(rk_phy->clk);
@@ -259,6 +284,86 @@ static const struct rockchip_usb_phy_pdata rk3188_pdata = {
 	},
 };
 
+#define RK3288_UOC0_CON0				0x320
+#define RK3288_UOC0_CON0_COMMON_ON_N			BIT(0)
+#define RK3288_UOC0_CON0_DISABLE			BIT(4)
+
+#define RK3288_UOC0_CON2				0x328
+#define RK3288_UOC0_CON2_SOFT_CON_SEL			BIT(2)
+
+#define RK3288_UOC0_CON3				0x32c
+#define RK3288_UOC0_CON3_UTMI_SUSPENDN			BIT(0)
+#define RK3288_UOC0_CON3_UTMI_OPMODE_NODRIVING		(1 << 1)
+#define RK3288_UOC0_CON3_UTMI_OPMODE_MASK		(3 << 1)
+#define RK3288_UOC0_CON3_UTMI_XCVRSEELCT_FSTRANSC	(1 << 3)
+#define RK3288_UOC0_CON3_UTMI_XCVRSEELCT_MASK		(3 << 3)
+#define RK3288_UOC0_CON3_UTMI_TERMSEL_FULLSPEED		BIT(5)
+#define RK3288_UOC0_CON3_BYPASSDMEN			BIT(6)
+#define RK3288_UOC0_CON3_BYPASSSEL			BIT(7)
+
+/*
+ * Enable the bypass of uart2 data through the otg usb phy.
+ * Original description in the TRM.
+ * 1. Disable the OTG block by setting OTGDISABLE0 to 1?b1.
+ * 2. Disable the pull-up resistance on the D+ line by setting
+ *    OPMODE0[1:0] to 2?b01.
+ * 3. To ensure that the XO, Bias, and PLL blocks are powered down in Suspend
+ *    mode, set COMMONONN to 1?b1.
+ * 4. Place the USB PHY in Suspend mode by setting SUSPENDM0 to 1?b0.
+ * 5. Set BYPASSSEL0 to 1?b1.
+ * 6. To transmit data, controls BYPASSDMEN0, and BYPASSDMDATA0.
+ * To receive data, monitor FSVPLUS0.
+ *
+ * The actual code in the vendor kernel does some things differently.
+ */
+static int __init rk3288_init_usb_uart(struct regmap *grf)
+{
+	u32 val;
+	int ret;
+
+	/*
+	 * COMMON_ON and DISABLE settings are described in the TRM,
+	 * but were not present in the original code.
+	 * Also disable the analog phy components to save power.
+	 */
+	val = HIWORD_UPDATE(RK3288_UOC0_CON0_COMMON_ON_N
+				| RK3288_UOC0_CON0_DISABLE
+				| UOC_CON0_SIDDQ,
+			    RK3288_UOC0_CON0_COMMON_ON_N
+				| RK3288_UOC0_CON0_DISABLE
+				| UOC_CON0_SIDDQ);
+	ret = regmap_write(grf, RK3288_UOC0_CON0, val);
+	if (ret)
+		return ret;
+
+	val = HIWORD_UPDATE(RK3288_UOC0_CON2_SOFT_CON_SEL,
+			    RK3288_UOC0_CON2_SOFT_CON_SEL);
+	ret = regmap_write(grf, RK3288_UOC0_CON2, val);
+	if (ret)
+		return ret;
+
+	val = HIWORD_UPDATE(RK3288_UOC0_CON3_UTMI_OPMODE_NODRIVING
+				| RK3288_UOC0_CON3_UTMI_XCVRSEELCT_FSTRANSC
+				| RK3288_UOC0_CON3_UTMI_TERMSEL_FULLSPEED,
+			    RK3288_UOC0_CON3_UTMI_SUSPENDN
+				| RK3288_UOC0_CON3_UTMI_OPMODE_MASK
+				| RK3288_UOC0_CON3_UTMI_XCVRSEELCT_MASK
+				| RK3288_UOC0_CON3_UTMI_TERMSEL_FULLSPEED);
+	ret = regmap_write(grf, RK3288_UOC0_CON3, val);
+	if (ret)
+		return ret;
+
+	val = HIWORD_UPDATE(RK3288_UOC0_CON3_BYPASSSEL
+				| RK3288_UOC0_CON3_BYPASSDMEN,
+			    RK3288_UOC0_CON3_BYPASSSEL
+				| RK3288_UOC0_CON3_BYPASSDMEN);
+	ret = regmap_write(grf, RK3288_UOC0_CON3, val);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
 static const struct rockchip_usb_phy_pdata rk3288_pdata = {
 	.phys = (struct rockchip_usb_phys[]){
 		{ .reg = 0x320, .pll_name = "sclk_otgphy0_480m" },
@@ -266,6 +371,8 @@ static const struct rockchip_usb_phy_pdata rk3288_pdata = {
 		{ .reg = 0x348, .pll_name = "sclk_otgphy2_480m" },
 		{ /* sentinel */ }
 	},
+	.init_usb_uart = rk3288_init_usb_uart,
+	.usb_uart_phy = 0,
 };
 
 static int rockchip_usb_phy_probe(struct platform_device *pdev)
@@ -328,6 +435,60 @@ static struct platform_driver rockchip_usb_driver = {
 
 module_platform_driver(rockchip_usb_driver);
 
+#ifndef MODULE
+static int __init rockchip_init_usb_uart(void)
+{
+	const struct of_device_id *match;
+	const struct rockchip_usb_phy_pdata *data;
+	struct device_node *np;
+	struct regmap *grf;
+	int ret;
+
+	if (!enable_usb_uart)
+		return 0;
+
+	np = of_find_matching_node_and_match(NULL, rockchip_usb_phy_dt_ids,
+					     &match);
+	if (!np) {
+		pr_err("%s: failed to find usbphy node\n", __func__);
+		return -ENOTSUPP;
+	}
+
+	pr_debug("%s: using settings for %s\n", __func__, match->compatible);
+	data = match->data;
+
+	if (!data->init_usb_uart) {
+		pr_err("%s: usb-uart not available on %s\n",
+		       __func__, match->compatible);
+		return -ENOTSUPP;
+	}
+
+	grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+	if (IS_ERR(grf)) {
+		pr_err("%s: Missing rockchip,grf property, %lu\n",
+		       __func__, PTR_ERR(grf));
+		return PTR_ERR(grf);
+	}
+
+	ret = data->init_usb_uart(grf);
+	if (ret) {
+		pr_err("%s: could not init usb_uart, %d\n", __func__, ret);
+		enable_usb_uart = 0;
+		return ret;
+	}
+
+	return 0;
+}
+early_initcall(rockchip_init_usb_uart);
+
+static int __init rockchip_usb_uart(char *buf)
+{
+	enable_usb_uart = true;
+	return 0;
+}
+early_param("rockchip.usb_uart", rockchip_usb_uart);
+#endif
+
 MODULE_AUTHOR("Yunzhi Li <lyz at rock-chips.com>");
 MODULE_DESCRIPTION("Rockchip USB 2.0 PHY driver");
 MODULE_LICENSE("GPL v2");
-- 
2.6.4



From marc.zyngier at arm.com  Mon Feb 22 04:00:40 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 22 Feb 2016 12:00:40 +0000
Subject: next-20160222 build: 5 failures 9 warnings (next-20160222)
In-Reply-To: <20160222115243.GA5779@e106950-lin.cambridge.arm.com>
References: <E1aXlz4-000486-Pb@optimist>
 <20160222100832.GX18327@sirena.org.uk> <56CAE5E6.7030707@arm.com>
 <20160222115243.GA5779@e106950-lin.cambridge.arm.com>
Message-ID: <56CAF868.5020406@arm.com>

On 22/02/16 11:52, Brian Starkey wrote:
> Hi Mark,
> 
> On Mon, Feb 22, 2016 at 10:41:42AM +0000, Marc Zyngier wrote:
>> I'm about to push the following patch on top of the KVM tree:
>>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 43688d9..31fe7d6 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -333,11 +333,6 @@ static inline void __cpu_init_hyp_mode(phys_addr_t boot_pgd_ptr,
>> 		     hyp_stack_ptr, vector_ptr);
>> }
>>
>> -static inline void __cpu_init_stage2(void)
>> -{
>> -	kvm_call_hyp(__init_stage2_translation);
>> -}
>> -
>> static inline void kvm_arch_hardware_disable(void) {}
>> static inline void kvm_arch_hardware_unsetup(void) {}
>> static inline void kvm_arch_sync_events(struct kvm *kvm) {}
>> @@ -349,4 +344,11 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu);
>> void kvm_arm_clear_debug(struct kvm_vcpu *vcpu);
>> void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu);
>>
>> +/* #define kvm_call_hyp(f, ...) __kvm_call_hyp(kvm_ksym_ref(f), ##__VA_ARGS__) */
>> +
>> +static inline void __cpu_init_stage2(void)
>> +{
>> +	kvm_call_hyp(__init_stage2_translation);
>> +}
>> +
>> #endif /* __ARM64_KVM_HOST_H__ */
>>
>> This will create a new conflict, but will make the resolution 100% clear.
> 
> I applied this, but arm64 defconfig wouldn't build until I uncommented
> the '#define kvm_call_hyp(...' line.
> 
> Is that right?

This patch is intended as a merge indication so that when you do the
merge with the arm64 tree, it conflicts and you can resolve it by going
the right thing (merging the non-comment version of this line).

So yes, uncommenting it is the right thing to do.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From festevam at gmail.com  Mon Feb 22 04:01:53 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 22 Feb 2016 09:01:53 -0300
Subject: [PATCH] bus: imx-weim: Take the 'status' property value into account 
Message-ID: <1456142513-12876-1-git-send-email-festevam@gmail.com>

From: Fabio Estevam <fabio.estevam at nxp.com>

Currently we have an incorrect behaviour when multiple devices
are present under the weim node. For example:

&weim {
	...
	status = "okay";
	
	sram at 0,0 {
		...
        	status = "okay";
	};

	mram at 0,0 {
		...
        	status = "disabled";
    	};
};

In this case only the 'sram' device should be probed and not 'mram'.

However what happens currently is that the status variable is ignored,
causing the 'sram' device to be disabled and 'mram' to be enabled.  

Change the weim_parse_dt() function to use
for_each_available_child_of_node()so that the devices marked with
'status = disabled' are not probed.

Cc: <stable at vger.kernel.org>
Suggested-by: Wolfgang Netbal <wolfgang.netbal at sigmatek.at>
Signed-off-by: Fabio Estevam <fabio.estevam at nxp.com>
---
 drivers/bus/imx-weim.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
index e98d15e..1827fc4 100644
--- a/drivers/bus/imx-weim.c
+++ b/drivers/bus/imx-weim.c
@@ -150,7 +150,7 @@ static int __init weim_parse_dt(struct platform_device *pdev,
 			return ret;
 	}
 
-	for_each_child_of_node(pdev->dev.of_node, child) {
+	for_each_available_child_of_node(pdev->dev.of_node, child) {
 		if (!child->name)
 			continue;
 
-- 
1.9.1



From brian.starkey at arm.com  Mon Feb 22 04:07:31 2016
From: brian.starkey at arm.com (Brian Starkey)
Date: Mon, 22 Feb 2016 12:07:31 +0000
Subject: next-20160222 build: 5 failures 9 warnings (next-20160222)
In-Reply-To: <56CAF868.5020406@arm.com>
References: <E1aXlz4-000486-Pb@optimist> <20160222100832.GX18327@sirena.org.uk>
 <56CAE5E6.7030707@arm.com>
 <20160222115243.GA5779@e106950-lin.cambridge.arm.com>
 <56CAF868.5020406@arm.com>
Message-ID: <20160222120730.GB5779@e106950-lin.cambridge.arm.com>

On Mon, Feb 22, 2016 at 12:00:40PM +0000, Marc Zyngier wrote:
>On 22/02/16 11:52, Brian Starkey wrote:
>>> This will create a new conflict, but will make the resolution 100% 
>>> clear.
>>
>> I applied this, but arm64 defconfig wouldn't build until I uncommented
>> the '#define kvm_call_hyp(...' line.
>>
>> Is that right?
>
>This patch is intended as a merge indication so that when you do the
>merge with the arm64 tree, it conflicts and you can resolve it by going
>the right thing (merging the non-comment version of this line).

Right, now I understand "make the resolution 100% clear" - I guess 100%
clear isn't clear enough for me :-(

I've not seen that used as notation before, thanks for explaining.

-Brian

>
>So yes, uncommenting it is the right thing to do.
>
>Thanks,
>
>	M.
>-- 
>Jazz is not dead. It just smells funny...
>


From yamada.masahiro at socionext.com  Mon Feb 22 04:08:05 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon, 22 Feb 2016 21:08:05 +0900
Subject: [PATCH 0/6] ARM: decompressor: several cleanups
In-Reply-To: <20160222113625.GC19428@n2100.arm.linux.org.uk>
References: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
 <20160222113625.GC19428@n2100.arm.linux.org.uk>
Message-ID: <CAK7LNAQEwm=2bHX+kTxFVJTh-sFX+3MBgwuEmmNM-XoyvdbWRA@mail.gmail.com>

Hi Russell,


2016-02-22 20:36 GMT+09:00 Russell King - ARM Linux <linux at arm.linux.org.uk>:
> On Mon, Feb 22, 2016 at 04:31:11PM +0900, Masahiro Yamada wrote:
>> Masahiro Yamada (6):
>>   ARM: decompressor: drop unneeded assignments to "targets"
>>   ARM: decompressor: drop more unneeded assignments to "targets"
>>   ARM: decompressor: use clean-files instead of extra-y to clean files
>>   ARM: decompressor: drop redundant FORCE in Makefile
>>   ARM: decompressor: merge piggy.*.S and simplify Makefile
>>   ARM: decompressor: rename suffix_y to compress-y
>
> Most of this looks fine to me, but I've a question about how thoroughly
> patch 5 has been tested: iow, do we get correct behaviour if only the
> compression method is changed?
>
> Thanks.


I did build-test, changing the configuration
CONFIG_KERNEL_GZIP -> CONFIG_KERNEL_LZMA -> CONFIG_KERNEL_XZ -> ...

I confirmed zImage was created from the expected piggy.

For run-test, it worked fine too.



-- 
Best Regards
Masahiro Yamada


From sricharan at codeaurora.org  Mon Feb 22 04:08:15 2016
From: sricharan at codeaurora.org (Sricharan R)
Date: Mon, 22 Feb 2016 17:38:15 +0530
Subject: [RESEND PATCH V7 4/6] i2c: qup: Add bam dma capabilities
Message-ID: <1456142895-32646-1-git-send-email-sricharan@codeaurora.org>

QUP cores can be attached to a BAM module, which acts as
a dma engine for the QUP core. When DMA with BAM is enabled,
the BAM consumer pipe transmitted data is written to the
output FIFO and the BAM producer pipe received data is read
from the input FIFO.

With BAM capabilities, qup-i2c core can transfer more than
256 bytes, without a 'stop' which is not possible otherwise.

Signed-off-by: Sricharan R <sricharan at codeaurora.org>
Reviewed-by: Andy Gross <andy.gross at linaro.org>
Tested-by: Archit Taneja <architt at codeaurora.org>
Tested-by: Telkar Nagender <ntelkar at codeaurora.org>
---
 Fixed Sparse/Static warnings.

 drivers/i2c/busses/i2c-qup.c | 473 +++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 459 insertions(+), 14 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index f9009d6..30f3a2b 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -14,8 +14,12 @@
  *
  */
 
+#include <linux/atomic.h>
 #include <linux/clk.h>
 #include <linux/delay.h>
+#include <linux/dmaengine.h>
+#include <linux/dmapool.h>
+#include <linux/dma-mapping.h>
 #include <linux/err.h>
 #include <linux/i2c.h>
 #include <linux/interrupt.h>
@@ -24,6 +28,7 @@
 #include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
+#include <linux/scatterlist.h>
 
 /* QUP Registers */
 #define QUP_CONFIG		0x000
@@ -33,6 +38,7 @@
 #define QUP_OPERATIONAL		0x018
 #define QUP_ERROR_FLAGS		0x01c
 #define QUP_ERROR_FLAGS_EN	0x020
+#define QUP_OPERATIONAL_MASK	0x028
 #define QUP_HW_VERSION		0x030
 #define QUP_MX_OUTPUT_CNT	0x100
 #define QUP_OUT_FIFO_BASE	0x110
@@ -52,6 +58,7 @@
 
 #define QUP_STATE_VALID		BIT(2)
 #define QUP_I2C_MAST_GEN	BIT(4)
+#define QUP_I2C_FLUSH		BIT(6)
 
 #define QUP_OPERATIONAL_RESET	0x000ff0
 #define QUP_I2C_STATUS_RESET	0xfffffc
@@ -77,7 +84,10 @@
 
 /* Packing/Unpacking words in FIFOs, and IO modes */
 #define QUP_OUTPUT_BLK_MODE	(1 << 10)
+#define QUP_OUTPUT_BAM_MODE	(3 << 10)
 #define QUP_INPUT_BLK_MODE	(1 << 12)
+#define QUP_INPUT_BAM_MODE	(3 << 12)
+#define QUP_BAM_MODE		(QUP_OUTPUT_BAM_MODE | QUP_INPUT_BAM_MODE)
 #define QUP_UNPACK_EN		BIT(14)
 #define QUP_PACK_EN		BIT(15)
 
@@ -94,6 +104,8 @@
 #define QUP_TAG_DATA		(2 << 8)
 #define QUP_TAG_STOP		(3 << 8)
 #define QUP_TAG_REC		(4 << 8)
+#define QUP_BAM_INPUT_EOT		0x93
+#define QUP_BAM_FLUSH_STOP		0x96
 
 /* QUP v2 tags */
 #define QUP_TAG_V2_START               0x81
@@ -114,6 +126,12 @@
 #define ONE_BYTE			0x1
 #define QUP_I2C_MX_CONFIG_DURING_RUN   BIT(31)
 
+#define MX_TX_RX_LEN			SZ_64K
+#define MX_BLOCKS			(MX_TX_RX_LEN / QUP_READ_LIMIT)
+
+/* Max timeout in ms for 32k bytes */
+#define TOUT_MAX			300
+
 struct qup_i2c_block {
 	int	count;
 	int	pos;
@@ -123,6 +141,17 @@ struct qup_i2c_block {
 	u8	tags[6];
 };
 
+struct qup_i2c_tag {
+	u8 *start;
+	dma_addr_t addr;
+};
+
+struct qup_i2c_bam {
+	struct	qup_i2c_tag tag;
+	struct	dma_chan *dma;
+	struct	scatterlist *sg;
+};
+
 struct qup_i2c_dev {
 	struct device		*dev;
 	void __iomem		*base;
@@ -154,6 +183,13 @@ struct qup_i2c_dev {
 	/* To configure when bus is in run state */
 	int			config_run;
 
+	/* dma parameters */
+	bool			is_dma;
+	struct			dma_pool *dpool;
+	struct			qup_i2c_tag start_tag;
+	struct			qup_i2c_bam brx;
+	struct			qup_i2c_bam btx;
+
 	struct completion	xfer;
 };
 
@@ -230,6 +266,14 @@ static int qup_i2c_poll_state(struct qup_i2c_dev *qup, u32 req_state)
 	return qup_i2c_poll_state_mask(qup, req_state, QUP_STATE_MASK);
 }
 
+static void qup_i2c_flush(struct qup_i2c_dev *qup)
+{
+	u32 val = readl(qup->base + QUP_STATE);
+
+	val |= QUP_I2C_FLUSH;
+	writel(val, qup->base + QUP_STATE);
+}
+
 static int qup_i2c_poll_state_valid(struct qup_i2c_dev *qup)
 {
 	return qup_i2c_poll_state_mask(qup, 0, 0);
@@ -437,12 +481,14 @@ static int qup_i2c_get_data_len(struct qup_i2c_dev *qup)
 }
 
 static int qup_i2c_set_tags(u8 *tags, struct qup_i2c_dev *qup,
-			    struct i2c_msg *msg)
+			    struct i2c_msg *msg,  int is_dma)
 {
 	u16 addr = (msg->addr << 1) | ((msg->flags & I2C_M_RD) == I2C_M_RD);
 	int len = 0;
 	int data_len;
 
+	int last = (qup->blk.pos == (qup->blk.count - 1)) && (qup->is_last);
+
 	if (qup->blk.pos == 0) {
 		tags[len++] = QUP_TAG_V2_START;
 		tags[len++] = addr & 0xff;
@@ -452,7 +498,7 @@ static int qup_i2c_set_tags(u8 *tags, struct qup_i2c_dev *qup,
 	}
 
 	/* Send _STOP commands for the last block */
-	if ((qup->blk.pos == (qup->blk.count - 1)) && qup->is_last) {
+	if (last) {
 		if (msg->flags & I2C_M_RD)
 			tags[len++] = QUP_TAG_V2_DATARD_STOP;
 		else
@@ -472,6 +518,11 @@ static int qup_i2c_set_tags(u8 *tags, struct qup_i2c_dev *qup,
 	else
 		tags[len++] = data_len;
 
+	if ((msg->flags & I2C_M_RD) && last && is_dma) {
+		tags[len++] = QUP_BAM_INPUT_EOT;
+		tags[len++] = QUP_BAM_FLUSH_STOP;
+	}
+
 	return len;
 }
 
@@ -480,7 +531,7 @@ static int qup_i2c_issue_xfer_v2(struct qup_i2c_dev *qup, struct i2c_msg *msg)
 	int data_len = 0, tag_len, index;
 	int ret;
 
-	tag_len = qup_i2c_set_tags(qup->blk.tags, qup, msg);
+	tag_len = qup_i2c_set_tags(qup->blk.tags, qup, msg, 0);
 	index = msg->len - qup->blk.data_len;
 
 	/* only tags are written for read */
@@ -494,6 +545,306 @@ static int qup_i2c_issue_xfer_v2(struct qup_i2c_dev *qup, struct i2c_msg *msg)
 	return ret;
 }
 
+static void qup_i2c_bam_cb(void *data)
+{
+	struct qup_i2c_dev *qup = data;
+
+	complete(&qup->xfer);
+}
+
+static int qup_sg_set_buf(struct scatterlist *sg, void *buf,
+			  struct qup_i2c_tag *tg, unsigned int buflen,
+			  struct qup_i2c_dev *qup, int map, int dir)
+{
+	int ret;
+
+	sg_set_buf(sg, buf, buflen);
+	ret = dma_map_sg(qup->dev, sg, 1, dir);
+	if (!ret)
+		return -EINVAL;
+
+	if (!map)
+		sg_dma_address(sg) = tg->addr + ((u8 *)buf - tg->start);
+
+	return 0;
+}
+
+static void qup_i2c_rel_dma(struct qup_i2c_dev *qup)
+{
+	if (qup->btx.dma)
+		dma_release_channel(qup->btx.dma);
+	if (qup->brx.dma)
+		dma_release_channel(qup->brx.dma);
+	qup->btx.dma = NULL;
+	qup->brx.dma = NULL;
+}
+
+static int qup_i2c_req_dma(struct qup_i2c_dev *qup)
+{
+	int err;
+
+	if (!qup->btx.dma) {
+		qup->btx.dma = dma_request_slave_channel_reason(qup->dev, "tx");
+		if (IS_ERR(qup->btx.dma)) {
+			err = PTR_ERR(qup->btx.dma);
+			qup->btx.dma = NULL;
+			dev_err(qup->dev, "\n tx channel not available");
+			return err;
+		}
+	}
+
+	if (!qup->brx.dma) {
+		qup->brx.dma = dma_request_slave_channel_reason(qup->dev, "rx");
+		if (IS_ERR(qup->brx.dma)) {
+			dev_err(qup->dev, "\n rx channel not available");
+			err = PTR_ERR(qup->brx.dma);
+			qup->brx.dma = NULL;
+			qup_i2c_rel_dma(qup);
+			return err;
+		}
+	}
+	return 0;
+}
+
+static int qup_i2c_bam_do_xfer(struct qup_i2c_dev *qup, struct i2c_msg *msg,
+			       int num)
+{
+	struct dma_async_tx_descriptor *txd, *rxd = NULL;
+	int ret = 0, idx = 0, limit = QUP_READ_LIMIT;
+	dma_cookie_t cookie_rx, cookie_tx;
+	u32 rx_nents = 0, tx_nents = 0, len, blocks, rem;
+	u32 i, tlen, tx_len, tx_buf = 0, rx_buf = 0, off = 0;
+	u8 *tags;
+
+	while (idx < num) {
+		blocks = (msg->len + limit) / limit;
+		rem = msg->len % limit;
+		tx_len = 0, len = 0, i = 0;
+
+		qup->is_last = (idx == (num - 1));
+
+		qup_i2c_set_blk_data(qup, msg);
+
+		if (msg->flags & I2C_M_RD) {
+			rx_nents += (blocks * 2) + 1;
+			tx_nents += 1;
+
+			while (qup->blk.pos < blocks) {
+				/* length set to '0' implies 256 bytes */
+				tlen = (i == (blocks - 1)) ? rem : 0;
+				tags = &qup->start_tag.start[off + len];
+				len += qup_i2c_set_tags(tags, qup, msg, 1);
+
+				/* scratch buf to read the start and len tags */
+				ret = qup_sg_set_buf(&qup->brx.sg[rx_buf++],
+						     &qup->brx.tag.start[0],
+						     &qup->brx.tag,
+						     2, qup, 0, 0);
+
+				if (ret)
+					return ret;
+
+				ret = qup_sg_set_buf(&qup->brx.sg[rx_buf++],
+						     &msg->buf[limit * i],
+						     NULL, tlen, qup,
+						     1, DMA_FROM_DEVICE);
+				if (ret)
+					return ret;
+
+				i++;
+				qup->blk.pos = i;
+			}
+			ret = qup_sg_set_buf(&qup->btx.sg[tx_buf++],
+					     &qup->start_tag.start[off],
+					     &qup->start_tag, len, qup, 0, 0);
+			if (ret)
+				return ret;
+
+			off += len;
+			/* scratch buf to read the BAM EOT and FLUSH tags */
+			ret = qup_sg_set_buf(&qup->brx.sg[rx_buf++],
+					     &qup->brx.tag.start[0],
+					     &qup->brx.tag, 2,
+					     qup, 0, 0);
+			if (ret)
+				return ret;
+		} else {
+			tx_nents += (blocks * 2);
+
+			while (qup->blk.pos < blocks) {
+				tlen = (i == (blocks - 1)) ? rem : 0;
+				tags = &qup->start_tag.start[off + tx_len];
+				len = qup_i2c_set_tags(tags, qup, msg, 1);
+
+				ret = qup_sg_set_buf(&qup->btx.sg[tx_buf++],
+						     tags,
+						     &qup->start_tag, len,
+						     qup, 0, 0);
+				if (ret)
+					return ret;
+
+				tx_len += len;
+				ret = qup_sg_set_buf(&qup->btx.sg[tx_buf++],
+						     &msg->buf[limit * i],
+						     NULL, tlen, qup, 1,
+						     DMA_TO_DEVICE);
+				if (ret)
+					return ret;
+				i++;
+				qup->blk.pos = i;
+			}
+			off += tx_len;
+
+			if (idx == (num - 1)) {
+				len = 1;
+				if (rx_nents) {
+					qup->btx.tag.start[0] =
+							QUP_BAM_INPUT_EOT;
+					len++;
+				}
+				qup->btx.tag.start[len - 1] =
+							QUP_BAM_FLUSH_STOP;
+				ret = qup_sg_set_buf(&qup->btx.sg[tx_buf++],
+						     &qup->btx.tag.start[0],
+						     &qup->btx.tag, len,
+						     qup, 0, 0);
+				if (ret)
+					return ret;
+				tx_nents += 1;
+			}
+		}
+		idx++;
+		msg++;
+	}
+
+	txd = dmaengine_prep_slave_sg(qup->btx.dma, qup->btx.sg, tx_nents,
+				      DMA_MEM_TO_DEV,
+				      DMA_PREP_INTERRUPT | DMA_PREP_FENCE);
+	if (!txd) {
+		dev_err(qup->dev, "failed to get tx desc\n");
+		ret = -EINVAL;
+		goto desc_err;
+	}
+
+	if (!rx_nents) {
+		txd->callback = qup_i2c_bam_cb;
+		txd->callback_param = qup;
+	}
+
+	cookie_tx = dmaengine_submit(txd);
+	if (dma_submit_error(cookie_tx)) {
+		ret = -EINVAL;
+		goto desc_err;
+	}
+
+	dma_async_issue_pending(qup->btx.dma);
+
+	if (rx_nents) {
+		rxd = dmaengine_prep_slave_sg(qup->brx.dma, qup->brx.sg,
+					      rx_nents, DMA_DEV_TO_MEM,
+					      DMA_PREP_INTERRUPT);
+		if (!rxd) {
+			dev_err(qup->dev, "failed to get rx desc\n");
+			ret = -EINVAL;
+
+			/* abort TX descriptors */
+			dmaengine_terminate_all(qup->btx.dma);
+			goto desc_err;
+		}
+
+		rxd->callback = qup_i2c_bam_cb;
+		rxd->callback_param = qup;
+		cookie_rx = dmaengine_submit(rxd);
+		if (dma_submit_error(cookie_rx)) {
+			ret = -EINVAL;
+			goto desc_err;
+		}
+
+		dma_async_issue_pending(qup->brx.dma);
+	}
+
+	if (!wait_for_completion_timeout(&qup->xfer, TOUT_MAX * HZ)) {
+		dev_err(qup->dev, "normal trans timed out\n");
+		ret = -ETIMEDOUT;
+	}
+
+	if (ret || qup->bus_err || qup->qup_err) {
+		if (qup->bus_err & QUP_I2C_NACK_FLAG) {
+			msg--;
+			dev_err(qup->dev, "NACK from %x\n", msg->addr);
+			ret = -EIO;
+
+			if (qup_i2c_change_state(qup, QUP_RUN_STATE)) {
+				dev_err(qup->dev, "change to run state timed out");
+				return ret;
+			}
+
+			if (rx_nents)
+				writel(QUP_BAM_INPUT_EOT,
+				       qup->base + QUP_OUT_FIFO_BASE);
+
+			writel(QUP_BAM_FLUSH_STOP,
+			       qup->base + QUP_OUT_FIFO_BASE);
+
+			qup_i2c_flush(qup);
+
+			/* wait for remaining interrupts to occur */
+			if (!wait_for_completion_timeout(&qup->xfer, HZ))
+				dev_err(qup->dev, "flush timed out\n");
+
+			qup_i2c_rel_dma(qup);
+		}
+	}
+
+	dma_unmap_sg(qup->dev, qup->btx.sg, tx_nents, DMA_TO_DEVICE);
+
+	if (rx_nents)
+		dma_unmap_sg(qup->dev, qup->brx.sg, rx_nents,
+			     DMA_FROM_DEVICE);
+desc_err:
+	return ret;
+}
+
+static int qup_i2c_bam_xfer(struct i2c_adapter *adap, struct i2c_msg *msg,
+			    int num)
+{
+	struct qup_i2c_dev *qup = i2c_get_adapdata(adap);
+	int ret = 0;
+
+	enable_irq(qup->irq);
+	ret = qup_i2c_req_dma(qup);
+
+	if (ret)
+		goto out;
+
+	qup->bus_err = 0;
+	qup->qup_err = 0;
+
+	writel(0, qup->base + QUP_MX_INPUT_CNT);
+	writel(0, qup->base + QUP_MX_OUTPUT_CNT);
+
+	/* set BAM mode */
+	writel(QUP_REPACK_EN | QUP_BAM_MODE, qup->base + QUP_IO_MODE);
+
+	/* mask fifo irqs */
+	writel((0x3 << 8), qup->base + QUP_OPERATIONAL_MASK);
+
+	/* set RUN STATE */
+	ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
+	if (ret)
+		goto out;
+
+	writel(qup->clk_ctl, qup->base + QUP_I2C_CLK_CTL);
+
+	qup->msg = msg;
+	ret = qup_i2c_bam_do_xfer(qup, qup->msg, num);
+out:
+	disable_irq(qup->irq);
+
+	qup->msg = NULL;
+	return ret;
+}
+
 static int qup_i2c_wait_for_complete(struct qup_i2c_dev *qup,
 				     struct i2c_msg *msg)
 {
@@ -850,7 +1201,7 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap,
 			   int num)
 {
 	struct qup_i2c_dev *qup = i2c_get_adapdata(adap);
-	int ret, idx;
+	int ret, len, idx = 0, use_dma = 0;
 
 	ret = pm_runtime_get_sync(qup->dev);
 	if (ret < 0)
@@ -865,7 +1216,27 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap,
 	writel(I2C_MINI_CORE | I2C_N_VAL_V2, qup->base + QUP_CONFIG);
 	writel(QUP_V2_TAGS_EN, qup->base + QUP_I2C_MASTER_GEN);
 
-	for (idx = 0; idx < num; idx++) {
+	if ((qup->is_dma)) {
+		/* All i2c_msgs should be transferred using either dma or cpu */
+		for (idx = 0; idx < num; idx++) {
+			if (msgs[idx].len == 0) {
+				ret = -EINVAL;
+				goto out;
+			}
+
+			len = (msgs[idx].len > qup->out_fifo_sz) ||
+			      (msgs[idx].len > qup->in_fifo_sz);
+
+			if ((!is_vmalloc_addr(msgs[idx].buf)) && len) {
+				use_dma = 1;
+			 } else {
+				use_dma = 0;
+				break;
+			}
+		}
+	}
+
+	do {
 		if (msgs[idx].len == 0) {
 			ret = -EINVAL;
 			goto out;
@@ -884,14 +1255,15 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap,
 
 		reinit_completion(&qup->xfer);
 
-		if (msgs[idx].flags & I2C_M_RD)
-			ret = qup_i2c_read_one_v2(qup, &msgs[idx]);
-		else
-			ret = qup_i2c_write_one_v2(qup, &msgs[idx]);
-
-		if (ret)
-			break;
-	}
+		if (use_dma) {
+			ret = qup_i2c_bam_xfer(adap, &msgs[idx], num);
+		} else {
+			if (msgs[idx].flags & I2C_M_RD)
+				ret = qup_i2c_read_one_v2(qup, &msgs[idx]);
+			else
+				ret = qup_i2c_write_one_v2(qup, &msgs[idx]);
+		}
+	} while ((idx++ < (num - 1)) && !use_dma && !ret);
 
 	if (!ret)
 		ret = qup_i2c_change_state(qup, QUP_RESET_STATE);
@@ -958,6 +1330,7 @@ static int qup_i2c_probe(struct platform_device *pdev)
 	int ret, fs_div, hs_div;
 	int src_clk_freq;
 	u32 clk_freq = 100000;
+	int blocks;
 
 	qup = devm_kzalloc(&pdev->dev, sizeof(*qup), GFP_KERNEL);
 	if (!qup)
@@ -974,8 +1347,63 @@ static int qup_i2c_probe(struct platform_device *pdev)
 		qup->adap.quirks = &qup_i2c_quirks;
 	} else {
 		qup->adap.algo = &qup_i2c_algo_v2;
+		ret = qup_i2c_req_dma(qup);
+
+		if (ret == -EPROBE_DEFER)
+			goto fail_dma;
+		else if (ret != 0)
+			goto nodma;
+
+		blocks = (MX_BLOCKS << 1) + 1;
+		qup->btx.sg = devm_kzalloc(&pdev->dev,
+					   sizeof(*qup->btx.sg) * blocks,
+					   GFP_KERNEL);
+		if (!qup->btx.sg) {
+			ret = -ENOMEM;
+			goto fail_dma;
+		}
+		sg_init_table(qup->btx.sg, blocks);
+
+		qup->brx.sg = devm_kzalloc(&pdev->dev,
+					   sizeof(*qup->brx.sg) * blocks,
+					   GFP_KERNEL);
+		if (!qup->brx.sg) {
+			ret = -ENOMEM;
+			goto fail_dma;
+		}
+		sg_init_table(qup->brx.sg, blocks);
+
+		/* 2 tag bytes for each block + 5 for start, stop tags */
+		size = blocks * 2 + 5;
+		qup->dpool = dma_pool_create("qup_i2c-dma-pool", &pdev->dev,
+					     size, 4, 0);
+
+		qup->start_tag.start = dma_pool_alloc(qup->dpool, GFP_KERNEL,
+						      &qup->start_tag.addr);
+		if (!qup->start_tag.start) {
+			ret = -ENOMEM;
+			goto fail_dma;
+		}
+
+		qup->brx.tag.start = dma_pool_alloc(qup->dpool,
+						    GFP_KERNEL,
+						    &qup->brx.tag.addr);
+		if (!qup->brx.tag.start) {
+			ret = -ENOMEM;
+			goto fail_dma;
+		}
+
+		qup->btx.tag.start = dma_pool_alloc(qup->dpool,
+						    GFP_KERNEL,
+						    &qup->btx.tag.addr);
+		if (!qup->btx.tag.start) {
+			ret = -ENOMEM;
+			goto fail_dma;
+		}
+		qup->is_dma = true;
 	}
 
+nodma:
 	/* We support frequencies up to FAST Mode (400KHz) */
 	if (!clk_freq || clk_freq > 400000) {
 		dev_err(qup->dev, "clock frequency not supported %d\n",
@@ -1073,7 +1501,7 @@ static int qup_i2c_probe(struct platform_device *pdev)
 	i2c_set_adapdata(&qup->adap, qup);
 	qup->adap.dev.parent = qup->dev;
 	qup->adap.dev.of_node = pdev->dev.of_node;
-	qup->is_last = 1;
+	qup->is_last = true;
 
 	strlcpy(qup->adap.name, "QUP I2C adapter", sizeof(qup->adap.name));
 
@@ -1093,6 +1521,11 @@ fail_runtime:
 	pm_runtime_set_suspended(qup->dev);
 fail:
 	qup_i2c_disable_clocks(qup);
+fail_dma:
+	if (qup->btx.dma)
+		dma_release_channel(qup->btx.dma);
+	if (qup->brx.dma)
+		dma_release_channel(qup->brx.dma);
 	return ret;
 }
 
@@ -1100,6 +1533,18 @@ static int qup_i2c_remove(struct platform_device *pdev)
 {
 	struct qup_i2c_dev *qup = platform_get_drvdata(pdev);
 
+	if (qup->is_dma) {
+		dma_pool_free(qup->dpool, qup->start_tag.start,
+			      qup->start_tag.addr);
+		dma_pool_free(qup->dpool, qup->brx.tag.start,
+			      qup->brx.tag.addr);
+		dma_pool_free(qup->dpool, qup->btx.tag.start,
+			      qup->btx.tag.addr);
+		dma_pool_destroy(qup->dpool);
+		dma_release_channel(qup->btx.dma);
+		dma_release_channel(qup->brx.dma);
+	}
+
 	disable_irq(qup->irq);
 	qup_i2c_disable_clocks(qup);
 	i2c_del_adapter(&qup->adap);
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation



From linux at arm.linux.org.uk  Mon Feb 22 04:18:05 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Feb 2016 12:18:05 +0000
Subject: [PATCH 0/6] ARM: decompressor: several cleanups
In-Reply-To: <CAK7LNAQEwm=2bHX+kTxFVJTh-sFX+3MBgwuEmmNM-XoyvdbWRA@mail.gmail.com>
References: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
 <20160222113625.GC19428@n2100.arm.linux.org.uk>
 <CAK7LNAQEwm=2bHX+kTxFVJTh-sFX+3MBgwuEmmNM-XoyvdbWRA@mail.gmail.com>
Message-ID: <20160222121805.GD19428@n2100.arm.linux.org.uk>

On Mon, Feb 22, 2016 at 09:08:05PM +0900, Masahiro Yamada wrote:
> I did build-test, changing the configuration
> CONFIG_KERNEL_GZIP -> CONFIG_KERNEL_LZMA -> CONFIG_KERNEL_XZ -> ...
> 
> I confirmed zImage was created from the expected piggy.
> 
> For run-test, it worked fine too.

Okay, please drop them into the patch system, thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From john at metanate.com  Mon Feb 22 04:22:59 2016
From: john at metanate.com (John Keeping)
Date: Mon, 22 Feb 2016 12:22:59 +0000
Subject: [PATCH] drm/rockchip: vop: fix crtc size in plane check
Message-ID: <1456143779-16208-1-git-send-email-john@metanate.com>

If the geometry of a crtc is changing in an atomic update then we much
validate the plane size against the new state of the crtc and not the
current size, otherwise if the crtc size is increasing the plane will be
cropped at the previous size and will not fill the screen.

Signed-off-by: John Keeping <john at metanate.com>
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fd37054..82d55bd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -549,6 +549,7 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
 			   struct drm_plane_state *state)
 {
 	struct drm_crtc *crtc = state->crtc;
+	struct drm_crtc_state *crtc_state;
 	struct drm_framebuffer *fb = state->fb;
 	struct vop_win *vop_win = to_vop_win(plane);
 	struct vop_plane_state *vop_plane_state = to_vop_plane_state(state);
@@ -563,12 +564,13 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
 	int max_scale = win->phy->scl ? FRAC_16_16(8, 1) :
 					DRM_PLANE_HELPER_NO_SCALING;
 
-	crtc = crtc ? crtc : plane->state->crtc;
-	/*
-	 * Both crtc or plane->state->crtc can be null.
-	 */
 	if (!crtc || !fb)
 		goto out_disable;
+
+	crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
+	if (WARN_ON(!crtc_state))
+		return -EINVAL;
+
 	src->x1 = state->src_x;
 	src->y1 = state->src_y;
 	src->x2 = state->src_x + state->src_w;
@@ -580,8 +582,8 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
 
 	clip.x1 = 0;
 	clip.y1 = 0;
-	clip.x2 = crtc->mode.hdisplay;
-	clip.y2 = crtc->mode.vdisplay;
+	clip.x2 = crtc_state->adjusted_mode.hdisplay;
+	clip.y2 = crtc_state->adjusted_mode.vdisplay;
 
 	ret = drm_plane_helper_check_update(plane, crtc, state->fb,
 					    src, dest, &clip,
-- 
2.7.0.226.gfe986fe



From sricharan at codeaurora.org  Mon Feb 22 04:24:57 2016
From: sricharan at codeaurora.org (Sricharan)
Date: Mon, 22 Feb 2016 17:54:57 +0530
Subject: [PATCH V7 4/6] i2c: qup: Add bam dma capabilities
References: <1453197766-18976-1-git-send-email-sricharan@codeaurora.org>
 <1453197766-18976-5-git-send-email-sricharan@codeaurora.org>
 <20160212183737.GA1520@katana> 
Message-ID: <002a01d16d6c$0f790520$2e6b0f60$@codeaurora.org>

Hi Wolfram,

> -----Original Message-----
> From: Sricharan [mailto:sricharan at codeaurora.org]
> Sent: Saturday, February 13, 2016 12:29 PM
> To: 'Wolfram Sang'
> Cc: 'devicetree at vger.kernel.org'; 'linux-arm-msm at vger.kernel.org';
> 'agross at codeaurora.org'; 'linux-kernel at vger.kernel.org'; 'linux-
> i2c at vger.kernel.org'; 'iivanov at mm-sol.com'; 'galak at codeaurora.org';
> 'dmaengine at vger.kernel.org'; 'linux-arm-kernel at lists.infradead.org';
> 'andy.gross at linaro.org'; 'ntelkar at codeaurora.org';
'architt at codeaurora.org'
> Subject: RE: [PATCH V7 4/6] i2c: qup: Add bam dma capabilities
> 
> Hi Wolfram,
> 
> > -----Original Message-----
> > From: Wolfram Sang [mailto:wsa at the-dreams.de]
> > Sent: Saturday, February 13, 2016 12:08 AM
> > To: Sricharan R
> > Cc: devicetree at vger.kernel.org; linux-arm-msm at vger.kernel.org;
> > agross at codeaurora.org; linux-kernel at vger.kernel.org; linux-
> > i2c at vger.kernel.org; iivanov at mm-sol.com; galak at codeaurora.org;
> > dmaengine at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> > andy.gross at linaro.org; ntelkar at codeaurora.org; architt at codeaurora.org
> > Subject: Re: [PATCH V7 4/6] i2c: qup: Add bam dma capabilities
> >
> > On Tue, Jan 19, 2016 at 03:32:44PM +0530, Sricharan R wrote:
> > > QUP cores can be attached to a BAM module, which acts as a dma
> > > engine for the QUP core. When DMA with BAM is enabled, the BAM
> > > consumer
> > pipe
> > > transmitted data is written to the output FIFO and the BAM producer
> > > pipe received data is read from the input FIFO.
> > >
> > > With BAM capabilities, qup-i2c core can transfer more than
> > > 256 bytes, without a 'stop' which is not possible otherwise.
> > >
> > > Signed-off-by: Sricharan R <sricharan at codeaurora.org>
> > > Reviewed-by: Andy Gross <andy.gross at linaro.org>
> > > Tested-by: Archit Taneja <architt at codeaurora.org>
> > > Tested-by: Telkar Nagender <ntelkar at codeaurora.org>
> >
> > My code checkers found some issues:
> >
> >     SPARSE
> > drivers/i2c/busses/i2c-qup.c:555:6: warning: symbol 'qup_sg_set_buf'
> > was not declared. Should it be static?
> > drivers/i2c/busses/i2c-qup.c:1243:50: warning: dubious: !x & !y
> >     SMATCH
> > drivers/i2c/busses/i2c-qup.c:165 qup_sg_set_buf warn: unused return: s
> > =
> > sg_next()
> > drivers/i2c/busses/i2c-qup.c:165 qup_sg_set_buf warn: unused return: s
> > =
> > sg_next()
> > drivers/i2c/busses/i2c-qup.c:1243 qup_i2c_xfer_v2() warn: add some
> > parenthesis here?
> >     CPPCHECK
> > drivers/i2c/busses/i2c-qup.c:1243: style: Boolean result is used in
> > bitwise operation. Clarify expression with parentheses.
> >     SPATCH
> > drivers/i2c/busses/i2c-qup.c:1380:2-13: WARNING: Assignment of bool to
> > 0/1
> > drivers/i2c/busses/i2c-qup.c:1481:1-13: WARNING: Assignment of bool to
> 0/1
> >   CC      drivers/i2c/busses/i2c-qup.o
> > drivers/i2c/busses/i2c-qup.c:555:6: warning: no previous prototype for
> > 'qup_sg_set_buf' [-Wmissing-prototypes]  void qup_sg_set_buf(struct
> > scatterlist *sg, void *buf, struct qup_i2c_tag *tg,
> >
> > Can you fix them and resend??
> 
  Really sorry for the delay ,  sent it here [1]

  Also, while testing this series in one of a new platform, found that an
additional 
  Regression and a fix is required on top of this series. So can I send a
separate fix on top of this series ?


[1]   https://patchwork.ozlabs.org/patch/586125/

Regards,
 Sricharan



From wsa at the-dreams.de  Mon Feb 22 04:32:26 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Mon, 22 Feb 2016 13:32:26 +0100
Subject: [PATCH V7 4/6] i2c: qup: Add bam dma capabilities
In-Reply-To: <002a01d16d6c$0f790520$2e6b0f60$@codeaurora.org>
References: <1453197766-18976-1-git-send-email-sricharan@codeaurora.org>
 <1453197766-18976-5-git-send-email-sricharan@codeaurora.org>
 <20160212183737.GA1520@katana>
 <002a01d16d6c$0f790520$2e6b0f60$@codeaurora.org>
Message-ID: <20160222123225.GC1392@katana>


>   Regression and a fix is required on top of this series. So can I send a
> separate fix on top of this series ?

Yes, do it like this. And please quote only relevant parts of a mail.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160222/273e376b/attachment.sig>

From yamada.masahiro at socionext.com  Mon Feb 22 04:33:38 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Mon, 22 Feb 2016 21:33:38 +0900
Subject: [PATCH 0/6] ARM: decompressor: several cleanups
In-Reply-To: <20160222121805.GD19428@n2100.arm.linux.org.uk>
References: <1456126277-14633-1-git-send-email-yamada.masahiro@socionext.com>
 <20160222113625.GC19428@n2100.arm.linux.org.uk>
 <CAK7LNAQEwm=2bHX+kTxFVJTh-sFX+3MBgwuEmmNM-XoyvdbWRA@mail.gmail.com>
 <20160222121805.GD19428@n2100.arm.linux.org.uk>
Message-ID: <CAK7LNAS0UVWezhH+KCrvUFeWvJkDzyDEV=-Ng5e9f2G1jJDwWA@mail.gmail.com>

Hi Russell,

2016-02-22 21:18 GMT+09:00 Russell King - ARM Linux <linux at arm.linux.org.uk>:
> On Mon, Feb 22, 2016 at 09:08:05PM +0900, Masahiro Yamada wrote:
>> I did build-test, changing the configuration
>> CONFIG_KERNEL_GZIP -> CONFIG_KERNEL_LZMA -> CONFIG_KERNEL_XZ -> ...
>>
>> I confirmed zImage was created from the expected piggy.
>>
>> For run-test, it worked fine too.
>
> Okay, please drop them into the patch system, thanks.

I did so.  Thanks.



-- 
Best Regards
Masahiro Yamada


From jan.glauber at caviumnetworks.com  Mon Feb 22 04:40:34 2016
From: jan.glauber at caviumnetworks.com (Jan Glauber)
Date: Mon, 22 Feb 2016 13:40:34 +0100
Subject: [PATCH v4 3/5] arm64: dts: Add Cavium ThunderX specific PMU
In-Reply-To: <20160218173248.GD16883@arm.com>
References: <20160218173248.GD16883@arm.com>
Message-ID: <20160222124034.GA766@hardcore>

On Thu, Feb 18, 2016 at 05:32:48PM +0000, Will Deacon wrote:
> On Thu, Feb 18, 2016 at 05:50:12PM +0100, Jan Glauber wrote:
> > Add a compatible string for the Cavium ThunderX PMU.
> 
> Stupid question, but is "thunder" the name of the CPU or the SoC or ...?
> 
> Whatever we use to describe the PMU, should probably also identify the
> CPU uniquely.

The CPU is currently:

compatible = "cavium,thunder", "arm,armv8";

We clearly need better names in case of a subsequent CPU, but for now
I think we should stick to the existing name.

Jan

> Will
> 
> > Signed-off-by: Jan Glauber <jglauber at cavium.com>
> > ---
> >  Documentation/devicetree/bindings/arm/pmu.txt | 1 +
> >  arch/arm64/boot/dts/cavium/thunder-88xx.dtsi  | 5 +++++
> >  2 files changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt
> > index 5651883..d3999a1 100644
> > --- a/Documentation/devicetree/bindings/arm/pmu.txt
> > +++ b/Documentation/devicetree/bindings/arm/pmu.txt
> > @@ -25,6 +25,7 @@ Required properties:
> >  	"qcom,scorpion-pmu"
> >  	"qcom,scorpion-mp-pmu"
> >  	"qcom,krait-pmu"
> > +	"cavium,thunder-pmu"
> >  - interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu
> >                 interrupt (PPI) then 1 interrupt should be specified.
> >  
> > diff --git a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
> > index 9cb7cf9..2eb9b22 100644
> > --- a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
> > +++ b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
> > @@ -360,6 +360,11 @@
> >  		             <1 10 0xff01>;
> >  	};
> >  
> > +	pmu {
> > +		compatible = "cavium,thunder-pmu", "arm,armv8-pmuv3";
> > +		interrupts = <1 7 4>;
> > +	};
> > +
> >  	soc {
> >  		compatible = "simple-bus";
> >  		#address-cells = <2>;
> > -- 
> > 1.9.1
> > 


From matthias.bgg at gmail.com  Mon Feb 22 04:40:51 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 22 Feb 2016 13:40:51 +0100
Subject: [GIT PULL] ARM: mediatek: soc updates for v4.5
Message-ID: <CABuKBeLEf+jyE5gzWEVzfRZ7DwRgnLrdWLREwqqfYGBb2g+exQ@mail.gmail.com>

Hi Arnd and Olof,

Please pull the following patches.
As you can see from the description, this pull request includes some
fixes. Only a few developer have access to a Mediatek HW at the
moment. Therefor I didn't send the fixes to stable.

If you want me to send the fixes for older kernel versions, please let me know.

Thanks,
Matthias

---

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

https://github.com/mbgg/linux-mediatek.git tags/v4.5-next-soc

for you to fetch changes up to cc8ed76938b5cf6a54ab3d60edabaf808dc960d1:

soc: mediatek: SCPSYS: Fix double enabling of regulators (2016-02-01
11:28:07 +0100)

----------------------------------------------------------------
Fix state machine implemenation of PMIC wrapper.
Add SMP support for mt7623.
Disable watchdog of STAUPD in PMIC wrapper for mt8173.
Add SMP support for mt2701.
Use builtin_platform_driver for scpsys. Driver can't be build as module.
Fix regulator enablement in scpsys.

----------------------------------------------------------------
Henry Chen (2):
soc: mediatek: PMIC wrap: Clear the vldclr if state machine stay on
FSM_VLDCLR state.
soc: mediatek: PMIC wrap: clear the STAUPD_TRIG bit of WDT_SRC_EN

John Crispin (1):
ARM: mediatek: add MT7623 smp bringup code

Louis Yu (1):
ARM: mediatek: add mt2701 smp bringup code

Matthias Brugger (1):
soc: mediatek: SCPSYS: use builtin_platform_driver

Sascha Hauer (1):
soc: mediatek: SCPSYS: Fix double enabling of regulators

arch/arm/mach-mediatek/platsmp.c | 8 +++++
drivers/soc/mediatek/mtk-pmic-wrap.c | 41 +++++++++++++++++++++---
drivers/soc/mediatek/mtk-scpsys.c | 60 ++++++++++++++++--------------------
3 files changed, 71 insertions(+), 38 deletions(-)


From matthias.bgg at gmail.com  Mon Feb 22 04:43:15 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 22 Feb 2016 13:43:15 +0100
Subject: [GIT PULL] ARM: mediatek: dts updates for v4.6
Message-ID: <CABuKBeK+zT85Z695dBGO-0tU26w5LBJqS53aecdZYGZ6V0GPhA@mail.gmail.com>

Hi Arnd and Olof,

Please pull the following patches.
As you can see from the description, this pull request includes some
fixes. Only a few developer have access to a Mediatek HW at the
moment. Therefore I didn't send the fixes to stable.

If you want me to send the fixes for older kernel versions, please let me know.

Thanks,
Matthias

---

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  https://github.com/mbgg/linux-mediatek.git tags/v4.5-next-dts64

for you to fetch changes up to 3ea064b1e5adc263893ffdc3a11891c6d00d5e49:

  ARM64: dts: Mediatek: mt8173-evb: fix access MMC fail issue
(2016-02-19 11:05:09 +0100)

----------------------------------------------------------------
Add nor-flash to mt8173 SoC.
Add efuse device to mt1873 SoC.
Fix power-domain issue mt8173-evb which uses older chip revision.

----------------------------------------------------------------
Bayi Cheng (1):
      arm64: dts: mt8173: Add nor flash node

Eddie Huang (1):
      ARM64: dts: Mediatek: mt8173-evb: fix access MMC fail issue

andrew-ct.chen at mediatek.com (1):
      dts: arm64: Add EFUSE device node

 arch/arm64/boot/dts/mediatek/mt8173-evb.dts |  3 +++
 arch/arm64/boot/dts/mediatek/mt8173.dtsi    | 16 ++++++++++++++++
 2 files changed, 19 insertions(+)


From nicolas.ferre at atmel.com  Mon Feb 22 04:43:39 2016
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 22 Feb 2016 13:43:39 +0100
Subject: [PATCH v2 01/15] arm: use of_platform_default_populate() to
 populate default bus
In-Reply-To: <1453881180-12296-1-git-send-email-wangkefeng.wang@huawei.com>
References: <1453868872-26300-2-git-send-email-wangkefeng.wang@huawei.com>
 <1453881180-12296-1-git-send-email-wangkefeng.wang@huawei.com>
Message-ID: <56CB027B.6000703@atmel.com>

Le 27/01/2016 08:53, Kefeng Wang a ?crit :
> diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
> index c1a7c6c..1904bc7 100644
> --- a/arch/arm/mach-at91/at91rm9200.c
> +++ b/arch/arm/mach-at91/at91rm9200.c
> @@ -31,7 +31,7 @@ static void __init at91rm9200_dt_device_init(void)
>  	if (soc != NULL)
>  		soc_dev = soc_device_to_device(soc);
>  
> -	of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
> +	of_platform_default_populate(NULL, NULL, soc_dev);
>  
>  	arm_pm_idle = at91rm9200_idle;
>  	at91rm9200_pm_init();
> diff --git a/arch/arm/mach-at91/at91sam9.c b/arch/arm/mach-at91/at91sam9.c
> index 7eb64f7..d495620 100644
> --- a/arch/arm/mach-at91/at91sam9.c
> +++ b/arch/arm/mach-at91/at91sam9.c
> @@ -61,7 +61,7 @@ static void __init at91sam9_common_init(void)
>  	if (soc != NULL)
>  		soc_dev = soc_device_to_device(soc);
>  
> -	of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
> +	of_platform_default_populate(NULL, NULL, soc_dev);
>  
>  	arm_pm_idle = at91sam9_idle;
>  }
> diff --git a/arch/arm/mach-at91/sama5.c b/arch/arm/mach-at91/sama5.c
> index d9cf679..6db395e 100644
> --- a/arch/arm/mach-at91/sama5.c
> +++ b/arch/arm/mach-at91/sama5.c
> @@ -50,7 +50,7 @@ static void __init sama5_dt_device_init(void)
>  	if (soc != NULL)
>  		soc_dev = soc_device_to_device(soc);
>  
> -	of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
> +	of_platform_default_populate(NULL, NULL, soc_dev);
>  	at91sam9x5_pm_init();
>  }

For AT91:
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

Thanks, bye.
-- 
Nicolas Ferre


From matthias.bgg at gmail.com  Mon Feb 22 04:44:00 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 22 Feb 2016 13:44:00 +0100
Subject: [GIT PULL] ARM: mediatek: soc updates for v4.5
In-Reply-To: <CABuKBeLEf+jyE5gzWEVzfRZ7DwRgnLrdWLREwqqfYGBb2g+exQ@mail.gmail.com>
References: <CABuKBeLEf+jyE5gzWEVzfRZ7DwRgnLrdWLREwqqfYGBb2g+exQ@mail.gmail.com>
Message-ID: <CABuKBeKf4dB7Y6A9WN530Zfmk55TXYserHv9OL-8Atfg65tTjA@mail.gmail.com>

Hi,

These updates are of course for v4.6, sorry for the confusion.

Matthias

2016-02-22 13:40 GMT+01:00 Matthias Brugger <matthias.bgg at gmail.com>:
> Hi Arnd and Olof,
>
> Please pull the following patches.
> As you can see from the description, this pull request includes some
> fixes. Only a few developer have access to a Mediatek HW at the
> moment. Therefor I didn't send the fixes to stable.
>
> If you want me to send the fixes for older kernel versions, please let me know.
>
> Thanks,
> Matthias
>
> ---
>
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>
> Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>
> are available in the git repository at:
>
> https://github.com/mbgg/linux-mediatek.git tags/v4.5-next-soc
>
> for you to fetch changes up to cc8ed76938b5cf6a54ab3d60edabaf808dc960d1:
>
> soc: mediatek: SCPSYS: Fix double enabling of regulators (2016-02-01
> 11:28:07 +0100)
>
> ----------------------------------------------------------------
> Fix state machine implemenation of PMIC wrapper.
> Add SMP support for mt7623.
> Disable watchdog of STAUPD in PMIC wrapper for mt8173.
> Add SMP support for mt2701.
> Use builtin_platform_driver for scpsys. Driver can't be build as module.
> Fix regulator enablement in scpsys.
>
> ----------------------------------------------------------------
> Henry Chen (2):
> soc: mediatek: PMIC wrap: Clear the vldclr if state machine stay on
> FSM_VLDCLR state.
> soc: mediatek: PMIC wrap: clear the STAUPD_TRIG bit of WDT_SRC_EN
>
> John Crispin (1):
> ARM: mediatek: add MT7623 smp bringup code
>
> Louis Yu (1):
> ARM: mediatek: add mt2701 smp bringup code
>
> Matthias Brugger (1):
> soc: mediatek: SCPSYS: use builtin_platform_driver
>
> Sascha Hauer (1):
> soc: mediatek: SCPSYS: Fix double enabling of regulators
>
> arch/arm/mach-mediatek/platsmp.c | 8 +++++
> drivers/soc/mediatek/mtk-pmic-wrap.c | 41 +++++++++++++++++++++---
> drivers/soc/mediatek/mtk-scpsys.c | 60 ++++++++++++++++--------------------
> 3 files changed, 71 insertions(+), 38 deletions(-)



-- 
motzblog.wordpress.com


From marc.zyngier at arm.com  Mon Feb 22 04:44:15 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 22 Feb 2016 12:44:15 +0000
Subject: next-20160222 build: 5 failures 9 warnings (next-20160222)
In-Reply-To: <20160222120730.GB5779@e106950-lin.cambridge.arm.com>
References: <E1aXlz4-000486-Pb@optimist>
 <20160222100832.GX18327@sirena.org.uk> <56CAE5E6.7030707@arm.com>
 <20160222115243.GA5779@e106950-lin.cambridge.arm.com>
 <56CAF868.5020406@arm.com>
 <20160222120730.GB5779@e106950-lin.cambridge.arm.com>
Message-ID: <56CB029F.2060409@arm.com>

On 22/02/16 12:07, Brian Starkey wrote:
> On Mon, Feb 22, 2016 at 12:00:40PM +0000, Marc Zyngier wrote:
>> On 22/02/16 11:52, Brian Starkey wrote:
>>>> This will create a new conflict, but will make the resolution 100% 
>>>> clear.
>>>
>>> I applied this, but arm64 defconfig wouldn't build until I uncommented
>>> the '#define kvm_call_hyp(...' line.
>>>
>>> Is that right?
>>
>> This patch is intended as a merge indication so that when you do the
>> merge with the arm64 tree, it conflicts and you can resolve it by going
>> the right thing (merging the non-comment version of this line).
> 
> Right, now I understand "make the resolution 100% clear" - I guess 100%
> clear isn't clear enough for me :-(

It is not meant to be clear to you, but to whoever is actually performing the merge:

$ git checkout arm64/for-next/core
Note: checking out 'arm64/for-next/core'.
$ git merge kvmarm-master/next
Auto-merging virt/kvm/arm/hyp/vgic-v2-sr.c
Auto-merging virt/kvm/arm/hyp/timer-sr.c
Auto-merging arch/arm64/mm/fault.c
Removing arch/arm64/kvm/hyp/hyp.h
Auto-merging arch/arm64/kvm/hyp/debug-sr.c
Auto-merging arch/arm64/kvm/hyp.S
CONFLICT (content): Merge conflict in arch/arm64/kvm/hyp.S
Auto-merging arch/arm64/kernel/image.h
Auto-merging arch/arm64/kernel/head.S
Auto-merging arch/arm64/kernel/debug-monitors.c
Auto-merging arch/arm64/kernel/cpufeature.c
CONFLICT (content): Merge conflict in arch/arm64/kernel/cpufeature.c
Auto-merging arch/arm64/include/asm/kvm_host.h
CONFLICT (content): Merge conflict in arch/arm64/include/asm/kvm_host.h
Auto-merging arch/arm64/include/asm/kvm_asm.h
Auto-merging arch/arm64/include/asm/cpufeature.h
CONFLICT (content): Merge conflict in arch/arm64/include/asm/cpufeature.h
Auto-merging arch/arm64/Kconfig
Removing arch/arm/kvm/interrupts_head.S
Auto-merging arch/arm/kvm/arm.c
CONFLICT (content): Merge conflict in arch/arm/kvm/arm.c
Auto-merging arch/arm/include/asm/kvm_asm.h
Automatic merge failed; fix conflicts and then commit the result.
maz at approximate:~/Work/arm-platforms$ git diff arch/arm64/include/asm/kvm_host.h
diff --cc arch/arm64/include/asm/kvm_host.h
index e3d67ff,31fe7d6..0000000
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@@ -343,6 -344,11 +344,15 @@@ void kvm_arm_setup_debug(struct kvm_vcp
  void kvm_arm_clear_debug(struct kvm_vcpu *vcpu);
  void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu);
  
++<<<<<<< HEAD
 +#define kvm_call_hyp(f, ...) __kvm_call_hyp(kvm_ksym_ref(f), ##__VA_ARGS__)
++=======
+ /* #define kvm_call_hyp(f, ...) __kvm_call_hyp(kvm_ksym_ref(f), ##__VA_ARGS__) */
+ 
+ static inline void __cpu_init_stage2(void)
+ {
+       kvm_call_hyp(__init_stage2_translation);
+ }
++>>>>>>> kvmarm-master/next
  
  #endif /* __ARM64_KVM_HOST_H__ */

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From jan.glauber at caviumnetworks.com  Mon Feb 22 04:45:14 2016
From: jan.glauber at caviumnetworks.com (Jan Glauber)
Date: Mon, 22 Feb 2016 13:45:14 +0100
Subject: [PATCH v4 4/5] arm64/perf: Enable PMCR long cycle counter bit
In-Reply-To: <20160218173428.GE16883@arm.com>
References: <cover.1455810755.git.jglauber@cavium.com>
 <467597048eda3004bd69f1fbe3981aab111e00dd.1455810755.git.jglauber@cavium.com>
 <20160218173428.GE16883@arm.com>
Message-ID: <20160222124514.GB766@hardcore>

On Thu, Feb 18, 2016 at 05:34:28PM +0000, Will Deacon wrote:
> On Thu, Feb 18, 2016 at 05:50:13PM +0100, Jan Glauber wrote:
> > With the long cycle counter bit (LC) disabled the cycle counter is not
> > working on ThunderX SOC (ThunderX only implements Aarch64).
> > Also, according to documentation LC == 0 is deprecated.
> > 
> > To keep the code simple the patch does not introduce 64 bit wide counter
> > functions. Instead writing the cycle counter always sets the upper
> > 32 bits so overflow interrupts are generated as before.
> > 
> > Original patch from Andrew Pinksi <Andrew.Pinksi at caviumnetworks.com>
> 
> What does this mean? Do we need Andrew's S-o-B, or is this a fresh patch?

Hi Will,

Please let me know if I should repost or not, FWIW I got Andrew's S-o-B on the
patch.

Thanks, Jan

> Will


From matthias.bgg at gmail.com  Mon Feb 22 04:47:24 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 22 Feb 2016 13:47:24 +0100
Subject: [GIT PULL] ARM: mediatek: dts updates for v4.6
Message-ID: <CABuKBe+vk0E6-8ni5bHtyn6X3EbLoOxfjw0zqPRE_tLdp0AAXQ@mail.gmail.com>

Hi Arnd and Olof,

Please pull the following patches.

Thanks,
Matthias

---

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  https://github.com/mbgg/linux-mediatek.git tags/v4.5-next-dts

for you to fetch changes up to 8ba671efdbe5be3e5d691a8b7f77b0d68459b874:

  arm: dts: Add pinctrl/GPIO/EINT node for mt2701 (2016-02-11 11:39:56 +0100)

----------------------------------------------------------------
Add support for mt7623 SoC.
Enable SMP support for mt7623.
Enable SMP support for mt2701
Add pinctrl for mt2701

----------------------------------------------------------------
Biao Huang (1):
      arm: dts: Add pinctrl/GPIO/EINT node for mt2701

John Crispin (3):
      Document: DT: Add bindings for mediatek MT7623 SoC Platform
      ARM: dts: mediatek: add MT7623 basic support
      ARM: dts: mt7623: enable SMP bringup

Louis Yu (1):
      ARM: dts: mt2701: enable basic SMP bringup for mt2701

 Documentation/devicetree/bindings/arm/mediatek.txt |   4 +
 .../devicetree/bindings/serial/mtk-uart.txt        |   1 +
 .../bindings/timer/mediatek,mtk-timer.txt          |   1 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/mt2701.dtsi                      |  31 +++++
 arch/arm/boot/dts/mt7623-evb.dts                   |  33 +++++
 arch/arm/boot/dts/mt7623.dtsi                      | 147 +++++++++++++++++++++
 arch/arm/mach-mediatek/Kconfig                     |   4 +
 arch/arm/mach-mediatek/mediatek.c                  |   1 +
 9 files changed, 223 insertions(+)
 create mode 100644 arch/arm/boot/dts/mt7623-evb.dts
 create mode 100644 arch/arm/boot/dts/mt7623.dtsi


From matthias.bgg at gmail.com  Mon Feb 22 04:48:57 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 22 Feb 2016 13:48:57 +0100
Subject: [GIT PULL] ARM: mediatek: dts updates for v4.6
In-Reply-To: <CABuKBeK+zT85Z695dBGO-0tU26w5LBJqS53aecdZYGZ6V0GPhA@mail.gmail.com>
References: <CABuKBeK+zT85Z695dBGO-0tU26w5LBJqS53aecdZYGZ6V0GPhA@mail.gmail.com>
Message-ID: <CABuKBe+8TkdnYX1pKLHkhRbYyAmhX9-QP=6oTOt73oQCR5NA7g@mail.gmail.com>

Hi,

2016-02-22 13:43 GMT+01:00 Matthias Brugger <matthias.bgg at gmail.com>:
> Hi Arnd and Olof,
>
> Please pull the following patches.
> As you can see from the description, this pull request includes some
> fixes. Only a few developer have access to a Mediatek HW at the
> moment. Therefore I didn't send the fixes to stable.
>
> If you want me to send the fixes for older kernel versions, please let me know.
>
> Thanks,
> Matthias
>
> ---
>
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>
> are available in the git repository at:
>
>   https://github.com/mbgg/linux-mediatek.git tags/v4.5-next-dts64

As the tag name says, these pull request is for dts64 instead of dts,
as written in the subject.
I screwed it up, sorry.

Regards,
Matthias

>
> for you to fetch changes up to 3ea064b1e5adc263893ffdc3a11891c6d00d5e49:
>
>   ARM64: dts: Mediatek: mt8173-evb: fix access MMC fail issue
> (2016-02-19 11:05:09 +0100)
>
> ----------------------------------------------------------------
> Add nor-flash to mt8173 SoC.
> Add efuse device to mt1873 SoC.
> Fix power-domain issue mt8173-evb which uses older chip revision.
>
> ----------------------------------------------------------------
> Bayi Cheng (1):
>       arm64: dts: mt8173: Add nor flash node
>
> Eddie Huang (1):
>       ARM64: dts: Mediatek: mt8173-evb: fix access MMC fail issue
>
> andrew-ct.chen at mediatek.com (1):
>       dts: arm64: Add EFUSE device node
>
>  arch/arm64/boot/dts/mediatek/mt8173-evb.dts |  3 +++
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi    | 16 ++++++++++++++++
>  2 files changed, 19 insertions(+)



-- 
motzblog.wordpress.com


From nicolas.ferre at atmel.com  Mon Feb 22 04:57:10 2016
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 22 Feb 2016 13:57:10 +0100
Subject: [PATCH] mtd: atmel_nand: move the hsmc_clk from nfc node to nand
 node
In-Reply-To: <1455687624-9488-1-git-send-email-wenyou.yang@atmel.com>
References: <1455687624-9488-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <56CB05A6.100@atmel.com>

Le 17/02/2016 06:40, Wenyou Yang a ?crit :
> From: Josh Wu <josh.wu at atmel.com>
> 
> For sama5d3, sama5d4 chip, the pmecc becomes a part of HSMC, they
> need the HSMC clock to be enabled to work.
> The NFC is a sub feature for current nand driver, it can be disabled.
> But if HSMC clock is controlled by NFC, so disable NFC will also
> disable the HSMC clock. then, it will make the PMECC fail to work.
> 
> So the solution is to move the HSMC clock out of NFC to nand node.
> When nand driver probed, it will check whether the chip has HSMC,
> if yes then it will require a HSMC clock.
> 
> Signed-off-by: Josh Wu <josh.wu at atmel.com>
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> ---
> 
>  .../devicetree/bindings/mtd/atmel-nand.txt         |    4 +-
>  drivers/mtd/nand/atmel_nand.c                      |   43 +++++++++-----------
>  2 files changed, 22 insertions(+), 25 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> index d53aba9..29bee7c 100644
> --- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> @@ -15,6 +15,7 @@ Required properties:
>  - atmel,nand-cmd-offset : offset for the command latch.
>  - #address-cells, #size-cells : Must be present if the device has sub-nodes
>    representing partitions.
> +- clocks: phandle to the peripheral clock
>  
>  - gpios : specifies the gpio pins to control the NAND device. detect is an
>    optional gpio and may be set to 0 if not present.
> @@ -43,7 +44,6 @@ Required properties:
>  - reg : should specify the address and size used for NFC command registers,
>          NFC registers and NFC SRAM. NFC SRAM address and size can be absent
>          if don't want to use it.
> -- clocks: phandle to the peripheral clock
>  Optional properties:
>  - atmel,write-by-sram: boolean to enable NFC write by SRAM.
>  
> @@ -100,13 +100,13 @@ nand0: nand at 40000000 {
>  	compatible = "atmel,at91rm9200-nand";
>  	#address-cells = <1>;
>  	#size-cells = <1>;
> +	clocks = <&hsmc_clk>
>  	ranges;
>          ...
>          nfc at 70000000 {
>  		compatible = "atmel,sama5d3-nfc";
>  		#address-cells = <1>;
>  		#size-cells = <1>;
> -		clocks = <&hsmc_clk>
>  		reg = <
>  			0x70000000 0x10000000	/* NFC Command Registers */
>  			0xffffc000 0x00000070	/* NFC HSMC regs */
> diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
> index 20cbaab..a1f4ad2 100644
> --- a/drivers/mtd/nand/atmel_nand.c
> +++ b/drivers/mtd/nand/atmel_nand.c
> @@ -66,6 +66,7 @@ module_param(on_flash_bbt, int, 0);
>  struct atmel_nand_caps {
>  	bool pmecc_correct_erase_page;
>  	uint8_t pmecc_max_correction;
> +	bool has_hsmc_clk;
>  };
>  
>  struct atmel_nand_nfc_caps {
> @@ -106,8 +107,6 @@ struct atmel_nfc {
>  	bool			use_nfc_sram;
>  	bool			write_by_sram;
>  
> -	struct clk		*clk;
> -
>  	bool			is_initialized;
>  	struct completion	comp_ready;
>  	struct completion	comp_cmd_done;
> @@ -132,6 +131,7 @@ struct atmel_nand_host {
>  	struct dma_chan		*dma_chan;
>  
>  	struct atmel_nfc	*nfc;
> +	struct clk		*clk;
>  
>  	const struct atmel_nand_caps	*caps;
>  	bool			has_pmecc;
> @@ -2157,6 +2157,19 @@ static int atmel_nand_probe(struct platform_device *pdev)
>  	nand_chip->IO_ADDR_R = host->io_base;
>  	nand_chip->IO_ADDR_W = host->io_base;
>  
> +	if (host->caps->has_hsmc_clk) {
> +		host->clk = devm_clk_get(&pdev->dev, NULL);
> +		if (IS_ERR(host->clk)) {
> +			dev_err(&pdev->dev, "HSMC clock is missing, update your Device Tree");
> +			res = PTR_ERR(host->clk);
> +			goto err_nand_ioremap;
> +		}
> +
> +		res = clk_prepare_enable(host->clk);
> +		if (res)
> +			goto err_nand_ioremap;
> +	}
> +
>  	if (nand_nfc.is_initialized) {
>  		/* NFC driver is probed and initialized */
>  		host->nfc = &nand_nfc;
> @@ -2321,6 +2334,9 @@ static int atmel_nand_remove(struct platform_device *pdev)
>  	if (host->dma_chan)
>  		dma_release_channel(host->dma_chan);
>  
> +	if (!IS_ERR(host->clk))
> +		clk_disable_unprepare(host->clk);
> +
>  	platform_driver_unregister(&atmel_nand_nfc_driver);
>  
>  	return 0;
> @@ -2334,11 +2350,13 @@ static int atmel_nand_remove(struct platform_device *pdev)
>  static const struct atmel_nand_caps at91rm9200_caps = {
>  	.pmecc_correct_erase_page = false,
>  	.pmecc_max_correction = 24,
> +	.has_hsmc_clk = false,
>  };
>  
>  static const struct atmel_nand_caps sama5d4_caps = {
>  	.pmecc_correct_erase_page = true,
>  	.pmecc_max_correction = 24,
> +	.has_hsmc_clk = true,

As this capability is not shared with SAMA5D3, I didn't see how you
could make the hsmc clock probed on SAMA5D3: remember, its controller
compatibility string is "atmel,at91rm9200-nand" with the description
just above.

Bye,


>  };
>  
>  /*
> @@ -2363,7 +2381,6 @@ static int atmel_nand_nfc_probe(struct platform_device *pdev)
>  {
>  	struct atmel_nfc *nfc = &nand_nfc;
>  	struct resource *nfc_cmd_regs, *nfc_hsmc_regs, *nfc_sram;
> -	int ret;
>  
>  	nfc_cmd_regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	nfc->base_cmd_regs = devm_ioremap_resource(&pdev->dev, nfc_cmd_regs);
> @@ -2401,31 +2418,12 @@ static int atmel_nand_nfc_probe(struct platform_device *pdev)
>  	nfc_writel(nfc->hsmc_regs, IDR, 0xffffffff);
>  	nfc_readl(nfc->hsmc_regs, SR);	/* clear the NFC_SR */
>  
> -	nfc->clk = devm_clk_get(&pdev->dev, NULL);
> -	if (!IS_ERR(nfc->clk)) {
> -		ret = clk_prepare_enable(nfc->clk);
> -		if (ret)
> -			return ret;
> -	} else {
> -		dev_warn(&pdev->dev, "NFC clock missing, update your Device Tree");
> -	}
> -
>  	nfc->is_initialized = true;
>  	dev_info(&pdev->dev, "NFC is probed.\n");
>  
>  	return 0;
>  }
>  
> -static int atmel_nand_nfc_remove(struct platform_device *pdev)
> -{
> -	struct atmel_nfc *nfc = &nand_nfc;
> -
> -	if (!IS_ERR(nfc->clk))
> -		clk_disable_unprepare(nfc->clk);
> -
> -	return 0;
> -}
> -
>  static const struct atmel_nand_nfc_caps sama5d3_nfc_caps = {
>  	.rb_mask = NFC_SR_RB_EDGE0,
>  };
> @@ -2447,7 +2445,6 @@ static struct platform_driver atmel_nand_nfc_driver = {
>  		.of_match_table = of_match_ptr(atmel_nand_nfc_match),
>  	},
>  	.probe = atmel_nand_nfc_probe,
> -	.remove = atmel_nand_nfc_remove,
>  };
>  
>  static struct platform_driver atmel_nand_driver = {
> 


-- 
Nicolas Ferre


From nicolas.ferre at atmel.com  Mon Feb 22 04:58:23 2016
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Mon, 22 Feb 2016 13:58:23 +0100
Subject: [PATCH] ARM: at91: sama5/dts: move hsmc_clk out of nfc node
In-Reply-To: <1455687741-9625-1-git-send-email-wenyou.yang@atmel.com>
References: <1455687741-9625-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <56CB05EF.9020105@atmel.com>

Le 17/02/2016 06:42, Wenyou Yang a ?crit :
> From: Josh Wu <josh.wu at atmel.com>
> 
> In sama5d3, sama5d4 chips, pmecc will use the hsmc clock. As pmecc is
> part of HSMC. So move out hsmc_clk from nfc node to nand node.
> 
> Signed-off-by: Josh Wu <rainyfeeling at outlook.com>
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>

I'm not against this change, but beware, it must be applied in
synchronization with the patch just posted "[PATCH] mtd: atmel_nand:
move the hsmc_clk from nfc node to nand node"

Bye,


> ---
> 
>  arch/arm/boot/dts/sama5d3.dtsi |    2 +-
>  arch/arm/boot/dts/sama5d4.dtsi |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
> index a532791..a242d27 100644
> --- a/arch/arm/boot/dts/sama5d3.dtsi
> +++ b/arch/arm/boot/dts/sama5d3.dtsi
> @@ -1474,6 +1474,7 @@
>  			atmel,nand-has-dma;
>  			pinctrl-names = "default";
>  			pinctrl-0 = <&pinctrl_nand0_ale_cle>;
> +			clocks = <&hsmc_clk>;
>  			atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
>  			status = "disabled";
>  
> @@ -1486,7 +1487,6 @@
>  					0xffffc000 0x00000070	/* NFC HSMC regs */
>  					0x00200000 0x00100000	/* NFC SRAM banks */
>  					>;
> -				clocks = <&hsmc_clk>;
>  			};
>  		};
>  	};
> diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
> index b8032bc..1499b33 100644
> --- a/arch/arm/boot/dts/sama5d4.dtsi
> +++ b/arch/arm/boot/dts/sama5d4.dtsi
> @@ -295,6 +295,7 @@
>  			atmel,nand-has-dma;
>  			pinctrl-names = "default";
>  			pinctrl-0 = <&pinctrl_nand>;
> +			clocks = <&hsmc_clk>;
>  			status = "disabled";
>  
>  			nfc at 90000000 {
> @@ -306,7 +307,6 @@
>  					0xfc05c000 0x00000070	/* NFC HSMC regs */
>  					0x00100000 0x00100000	/* NFC SRAM banks */
>                                           >;
> -				clocks = <&hsmc_clk>;
>  				atmel,write-by-sram;
>  			};
>  		};
> 


-- 
Nicolas Ferre


From k at japko.eu  Mon Feb 22 05:03:27 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Mon, 22 Feb 2016 14:03:27 +0100
Subject: [PATCH v5 3/4] ARM: dts: sun8i-h3: Add R_PIO controller node to the
 dtsi
In-Reply-To: <1456146208-13890-1-git-send-email-k@japko.eu>
References: <1456146208-13890-1-git-send-email-k@japko.eu>
Message-ID: <1456146208-13890-4-git-send-email-k@japko.eu>

Add the corresponding device node for R_PIO on H3 to the dtsi. Support
for the controller was added in earlier commit.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 1348b69..c3b73d7 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -518,5 +518,17 @@
 			compatible = "allwinner,sun6i-a31-clock-reset";
 			#reset-cells = <1>;
 		};
+
+		r_pio: pinctrl at 01f02c00 {
+			compatible = "allwinner,sun8i-h3-r-pinctrl";
+			reg = <0x01f02c00 0x400>;
+			interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&apb0_gates 0>;
+			resets = <&apb0_reset 0>;
+			gpio-controller;
+			#gpio-cells = <3>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+		};
 	};
 };
-- 
2.1.4



From k at japko.eu  Mon Feb 22 05:03:26 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Mon, 22 Feb 2016 14:03:26 +0100
Subject: [PATCH v5 2/4] dts: sun8i-h3: Add APB0 related clocks and resets
In-Reply-To: <1456146208-13890-1-git-send-email-k@japko.eu>
References: <1456146208-13890-1-git-send-email-k@japko.eu>
Message-ID: <1456146208-13890-3-git-send-email-k@japko.eu>

APB0 is bearly mentioned in H3 User Manual and it is only setup in the
Allwinners kernel dump for CIR. I have verified experimentally that the
gate for R_PIO exists and works, though. There are probably other gates
there but I don't know their order right now and I don't have access to
their peripherals on my board to test them.

After some experiments and reviewing how this is organized on other
sunxi SoCs, I couldn't actually find any way to disable clocks for R_PIO
and they are working properly without doing anything so I assume they
are connected straight to the 24Mhz oscillator for now.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 3ba65c2..1348b69 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -276,6 +276,25 @@
 			clocks = <&osc24M>, <&pll6 1>, <&pll5>;
 			clock-output-names = "mbus";
 		};
+
+		apb0: apb0_clk {
+			compatible = "fixed-factor-clock";
+			#clock-cells = <0>;
+			clock-div = <1>;
+			clock-mult = <1>;
+			clocks = <&osc24M>;
+			clock-output-names = "apb0";
+		};
+
+		apb0_gates: clk at 01f01428 {
+			compatible = "allwinner,sun8i-h3-apb0-gates-clk",
+				     "allwinner,sun4i-a10-gates-clk";
+			reg = <0x01f01428 0x4>;
+			#clock-cells = <1>;
+			clocks = <&apb0>;
+			clock-indices = <0>, <1>;
+			clock-output-names = "apb0_pio", "apb0_ir";
+		};
 	};
 
 	soc {
@@ -493,5 +512,11 @@
 			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
 		};
+
+		apb0_reset: reset at 01f014b0 {
+			reg = <0x01f014b0 0x4>;
+			compatible = "allwinner,sun6i-a31-clock-reset";
+			#reset-cells = <1>;
+		};
 	};
 };
-- 
2.1.4



From k at japko.eu  Mon Feb 22 05:03:28 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Mon, 22 Feb 2016 14:03:28 +0100
Subject: [PATCH v5 4/4] ARM: dts: sun8i: Add leds and switch on Orangepi Plus
 boards
In-Reply-To: <1456146208-13890-1-git-send-email-k@japko.eu>
References: <1456146208-13890-1-git-send-email-k@japko.eu>
Message-ID: <1456146208-13890-5-git-send-email-k@japko.eu>

OrangePi Plus board has two leds - green ("pwr") and red ("status")
and a switch ("sw4"). This patch describes them in a devicetree.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 63 ++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
index e67df59..5f159d0 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
@@ -45,6 +45,7 @@
 #include "sunxi-common-regulators.dtsi"
 
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
 #include <dt-bindings/pinctrl/sun4i-a10.h>
 
 / {
@@ -58,6 +59,68 @@
 	chosen {
 		stdout-path = "serial0:115200n8";
 	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&leds_opc>;
+
+		status_led {
+			label = "status:red:user";
+			gpios = <&pio 0 15 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	r_leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&leds_r_opc>;
+
+		tx {
+			label = "pwr:green:user";
+			gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+			default-state = "on";
+		};
+	};
+
+	r_gpio_keys {
+		compatible = "gpio-keys";
+		input-name = "sw4";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&sw_r_opc>;
+
+		sw4 at 0 {
+			label = "sw4";
+			linux,code = <BTN_0>;
+			gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
+		};
+	};
+};
+
+&pio {
+	leds_opc: led_pins at 0 {
+		allwinner,pins = "PA15";
+		allwinner,function = "gpio_out";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+};
+
+&r_pio {
+	leds_r_opc: led_pins at 0 {
+		allwinner,pins = "PL10";
+		allwinner,function = "gpio_out";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+
+	sw_r_opc: key_pins at 0 {
+		allwinner,pins = "PL03";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
 };
 
 &mmc0 {
-- 
2.1.4



From k at japko.eu  Mon Feb 22 05:03:24 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Mon, 22 Feb 2016 14:03:24 +0100
Subject: [PATCH v5 0/4] pinctrl: sunxi: Add H3 R_PIO controller support
Message-ID: <1456146208-13890-1-git-send-email-k@japko.eu>

This patch series is extension of my original single patch with the same
subject. It adds support for R_PIO so that GPIO port L can be used in H3
based devices. It was tested on OrangePi PC and OrangePi Plus where PL
is connected amount others to an onboard led, a switch, an IR receiver
and some VCC controllers.

Patchset is based on next-20160222.

--- 

Changes since v4:
- remove patches that are alredy merged
- add patch describing leds and switch in DT

Changes since v3:
- collect some acked-bys
- fix r_pios #interrupt-cells

Changes since v2:
- fixed apb0 parrent clocks list
- moved binding documentation change to the proper patch
- simplified sunxi_pinctrl_gpio_get according to ChenYu suggestions
- fixed ordering in sunxi binding documentation

Changes since v1:
- splited patch to two separate - dtsi and c files
- added APB0 clocks a parent for R_PIO
- added fix in sunxi_pinctrl_gpio_get for getting pin value when in irq
  mode and on 2nd pinctrl
- fixed a "pwn" > "pwm" typo
- fixed order in allwinner,sunxi-pinctrl.txt


Krzysztof Adamski (4):
  clk: sunxi: Add apb0 gates for H3
  dts: sun8i-h3: Add APB0 related clocks and resets
  ARM: dts: sun8i-h3: Add R_PIO controller node to the dtsi
  ARM: dts: sun8i: Add leds and switch on Orangepi Plus boards

Krzysztof Adamski (4):
  clk: sunxi: Add apb0 gates for H3
  dts: sun8i-h3: Add APB0 related clocks and resets
  ARM: dts: sun8i-h3: Add R_PIO controller node to the dtsi
  ARM: dts: sun8i: Add leds and switch on Orangepi Plus boards

 Documentation/devicetree/bindings/clock/sunxi.txt |  2 +
 arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts      | 63 +++++++++++++++++++++++
 arch/arm/boot/dts/sun8i-h3.dtsi                   | 37 +++++++++++++
 drivers/clk/sunxi/clk-simple-gates.c              |  4 ++
 4 files changed, 106 insertions(+)

-- 
2.1.4



From k at japko.eu  Mon Feb 22 05:03:25 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Mon, 22 Feb 2016 14:03:25 +0100
Subject: [PATCH v5 1/4] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <1456146208-13890-1-git-send-email-k@japko.eu>
References: <1456146208-13890-1-git-send-email-k@japko.eu>
Message-ID: <1456146208-13890-2-git-send-email-k@japko.eu>

This patch adds support for APB0 in H3. It seems to be compatible with
earlier SOCs. apb0 gates controls R_ block peripherals (R_PIO, R_IR,
etc).

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---
 Documentation/devicetree/bindings/clock/sunxi.txt | 2 ++
 drivers/clk/sunxi/clk-simple-gates.c              | 4 ++++
 2 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index c09f59b..834436f 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -18,6 +18,7 @@ Required properties:
 	"allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock
 	"allwinner,sun4i-a10-axi-clk" - for the AXI clock
 	"allwinner,sun8i-a23-axi-clk" - for the AXI clock on A23
+	"allwinner,sun4i-a10-gates-clk" - for generic gates on all compatible SoCs
 	"allwinner,sun4i-a10-axi-gates-clk" - for the AXI gates
 	"allwinner,sun4i-a10-ahb-clk" - for the AHB clock
 	"allwinner,sun5i-a13-ahb-clk" - for the AHB clock on A13
@@ -46,6 +47,7 @@ Required properties:
 	"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
 	"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
 	"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
+	"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
 	"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
 	"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
 	"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
diff --git a/drivers/clk/sunxi/clk-simple-gates.c b/drivers/clk/sunxi/clk-simple-gates.c
index 2cfc5a8..d7ec2dc 100644
--- a/drivers/clk/sunxi/clk-simple-gates.c
+++ b/drivers/clk/sunxi/clk-simple-gates.c
@@ -98,6 +98,8 @@ static void __init sunxi_simple_gates_init(struct device_node *node)
 	sunxi_simple_gates_setup(node, NULL, 0);
 }
 
+CLK_OF_DECLARE(sun4i_a10_gates, "allwinner,sun4i-a10-gates-clk",
+	       sunxi_simple_gates_init);
 CLK_OF_DECLARE(sun4i_a10_apb0, "allwinner,sun4i-a10-apb0-gates-clk",
 	       sunxi_simple_gates_init);
 CLK_OF_DECLARE(sun4i_a10_apb1, "allwinner,sun4i-a10-apb1-gates-clk",
@@ -132,6 +134,8 @@ CLK_OF_DECLARE(sun8i_a33_ahb1, "allwinner,sun8i-a33-ahb1-gates-clk",
 	       sunxi_simple_gates_init);
 CLK_OF_DECLARE(sun8i_a83t_apb0, "allwinner,sun8i-a83t-apb0-gates-clk",
 	       sunxi_simple_gates_init);
+CLK_OF_DECLARE(sun8i_h3_apb0, "allwinner,sun8i-h3-apb0-gates-clk",
+	       sunxi_simple_gates_init);
 CLK_OF_DECLARE(sun9i_a80_ahb0, "allwinner,sun9i-a80-ahb0-gates-clk",
 	       sunxi_simple_gates_init);
 CLK_OF_DECLARE(sun9i_a80_ahb1, "allwinner,sun9i-a80-ahb1-gates-clk",
-- 
2.1.4



From linus.walleij at linaro.org  Mon Feb 22 05:09:45 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Feb 2016 14:09:45 +0100
Subject: [PATCH 2/6] mtd: physmap_of: add a hook for Versatile write
 protection
In-Reply-To: <CACRpkdY4fNfQWaKAZcak0yzJ2B17hbrqdU=Q4=NiwiWRNv_0yQ@mail.gmail.com>
References: <1453806725-4880-1-git-send-email-linus.walleij@linaro.org>
 <1453806725-4880-3-git-send-email-linus.walleij@linaro.org>
 <CACRpkdY4fNfQWaKAZcak0yzJ2B17hbrqdU=Q4=NiwiWRNv_0yQ@mail.gmail.com>
Message-ID: <CACRpkdZusueSh99D2JQj5=JQqHAeedTS=X2vm48U58PLbhamcQ@mail.gmail.com>

On Sat, Feb 13, 2016 at 2:19 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Tue, Jan 26, 2016 at 12:12 PM, Linus Walleij
> <linus.walleij at linaro.org> wrote:
>
>> In order to support device tree probing of Versatile NOR flash
>> chips, there must be a way to add the VPP (write protection)
>> enable/disable callback. The register in question is in the
>> system controllers of these machines. Apart from this quirk,
>> the ARM flash chips are standard CFI flash chips from various
>> vendors.
>>
>> Additionally, the Integrator/AP require you to set up the external
>> bus interface (EBI) to allow writes to the chip select where the
>> flash memory is connected.
>>
>> Solve this by looking for the arm,versatile-flash compatible
>> string in the flash device tree node. In the driver,
>> add a special hook to check for the various Versatile syscons and
>> register a callback for .set_vpp() if this compatible is present.
>>
>> Provide a special Kconfig entry for the addon hook so it will
>> not be compiled in if the Versatile boards are not supported.
>> Stubs in the header file make sure the impact will be zero on
>> other platforms. (Compilers optimze this out.)
>>
>> With this patch, a large slew of ARM board file code can be
>> removed.
>>
>> Cc: Grant Likely <grant.likely at linaro.org>
>> Cc: Rob Herring <robh at kernel.org>
>> Cc: Arnd Bergmann <arnd at arndb.de>
>> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
>
> Do you think my reply to this about reference counting and
> subsequent (accepted) patch to update the documentation
> to reflect 876fe76d793d03077
> "mtd: maps: physmap: Add reference counter to set_vpp()"
> is enough to warrant merging of this?
>
> If you want the code developed in any special direction
> just tell me.

Ping.

Yours,
Linus Walleij


From sfr at canb.auug.org.au  Mon Feb 22 05:19:04 2016
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Tue, 23 Feb 2016 00:19:04 +1100
Subject: next-20160222 build: 5 failures 9 warnings (next-20160222)
In-Reply-To: <56CB029F.2060409@arm.com>
References: <E1aXlz4-000486-Pb@optimist> <20160222100832.GX18327@sirena.org.uk>
 <56CAE5E6.7030707@arm.com>
 <20160222115243.GA5779@e106950-lin.cambridge.arm.com>
 <56CAF868.5020406@arm.com>
 <20160222120730.GB5779@e106950-lin.cambridge.arm.com>
 <56CB029F.2060409@arm.com>
Message-ID: <20160223001904.3ed3e402@canb.auug.org.au>

Hi Marc,

On Mon, 22 Feb 2016 12:44:15 +0000 Marc Zyngier <marc.zyngier at arm.com> wrote:
>
> On 22/02/16 12:07, Brian Starkey wrote:
> > On Mon, Feb 22, 2016 at 12:00:40PM +0000, Marc Zyngier wrote:  
> >> On 22/02/16 11:52, Brian Starkey wrote:  
> >>>> This will create a new conflict, but will make the resolution 100% 
> >>>> clear.  
> >>>
> >>> I applied this, but arm64 defconfig wouldn't build until I uncommented
> >>> the '#define kvm_call_hyp(...' line.
> >>>
> >>> Is that right?  
> >>
> >> This patch is intended as a merge indication so that when you do the
> >> merge with the arm64 tree, it conflicts and you can resolve it by going
> >> the right thing (merging the non-comment version of this line).  
> > 
> > Right, now I understand "make the resolution 100% clear" - I guess 100%
> > clear isn't clear enough for me :-(  
> 
> It is not meant to be clear to you, but to whoever is actually performing the merge:

Excellent, thanks for that - hopefully I will get it right tomorrow.

-- 
Cheers,
Stephen Rothwell


From antoine.tenart at free-electrons.com  Mon Feb 22 05:22:30 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Mon, 22 Feb 2016 14:22:30 +0100
Subject: [PATCH] MAINTAINERS: alpine: add a new maintainer and update the entry
Message-ID: <1456147350-7236-1-git-send-email-antoine.tenart@free-electrons.com>

Add myself as a co-maintainer for the Alpine support. Also update the
entry to take in account Alpine ARM64 boards, Alpine ARM device trees
and Alpine-specific drivers.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
---
 MAINTAINERS | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 30aca4aa5467..53c07990e0f2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -938,8 +938,12 @@ N:	meson[x68]
 
 ARM/Annapurna Labs ALPINE ARCHITECTURE
 M:	Tsahee Zidenberg <tsahee at annapurnalabs.com>
+M:	Antoine Tenart <antoine.tenart at free-electrons.com>
 S:	Maintained
 F:	arch/arm/mach-alpine/
+F:	arch/arm/boot/dts/alpine*
+F:	arch/arm64/boot/dts/al/
+F:	drivers/*/*alpine*
 
 ARM/ATMEL AT91RM9200, AT91SAM9 AND SAMA5 SOC SUPPORT
 M:	Nicolas Ferre <nicolas.ferre at atmel.com>
-- 
2.7.1



From tsahee at annapurnalabs.com  Mon Feb 22 05:24:22 2016
From: tsahee at annapurnalabs.com (Tsahee Zidenberg)
Date: Mon, 22 Feb 2016 15:24:22 +0200
Subject: [PATCH] MAINTAINERS: alpine: add a new maintainer and update the
 entry
In-Reply-To: <1456147350-7236-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1456147350-7236-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <CABM=7knwGCMJsc5WP0NQaVr5vbUNC4XNMxnXDu6ep_rJd8VQnw@mail.gmail.com>

Acked -by: Tsahee Zidenberg <tsahee at annapurnalabs.com>


On 22 February 2016 at 15:22, Antoine Tenart
<antoine.tenart at free-electrons.com> wrote:
> Add myself as a co-maintainer for the Alpine support. Also update the
> entry to take in account Alpine ARM64 boards, Alpine ARM device trees
> and Alpine-specific drivers.
>
> Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
> ---
>  MAINTAINERS | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 30aca4aa5467..53c07990e0f2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -938,8 +938,12 @@ N: meson[x68]
>
>  ARM/Annapurna Labs ALPINE ARCHITECTURE
>  M:     Tsahee Zidenberg <tsahee at annapurnalabs.com>
> +M:     Antoine Tenart <antoine.tenart at free-electrons.com>
>  S:     Maintained
>  F:     arch/arm/mach-alpine/
> +F:     arch/arm/boot/dts/alpine*
> +F:     arch/arm64/boot/dts/al/
> +F:     drivers/*/*alpine*
>
>  ARM/ATMEL AT91RM9200, AT91SAM9 AND SAMA5 SOC SUPPORT
>  M:     Nicolas Ferre <nicolas.ferre at atmel.com>
> --
> 2.7.1
>


From will.deacon at arm.com  Mon Feb 22 05:41:05 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 22 Feb 2016 13:41:05 +0000
Subject: [PATCH v4 4/5] arm64/perf: Enable PMCR long cycle counter bit
In-Reply-To: <20160222124514.GB766@hardcore>
References: <cover.1455810755.git.jglauber@cavium.com>
 <467597048eda3004bd69f1fbe3981aab111e00dd.1455810755.git.jglauber@cavium.com>
 <20160218173428.GE16883@arm.com> <20160222124514.GB766@hardcore>
Message-ID: <20160222134105.GD31168@arm.com>

On Mon, Feb 22, 2016 at 01:45:14PM +0100, Jan Glauber wrote:
> On Thu, Feb 18, 2016 at 05:34:28PM +0000, Will Deacon wrote:
> > On Thu, Feb 18, 2016 at 05:50:13PM +0100, Jan Glauber wrote:
> > > With the long cycle counter bit (LC) disabled the cycle counter is not
> > > working on ThunderX SOC (ThunderX only implements Aarch64).
> > > Also, according to documentation LC == 0 is deprecated.
> > > 
> > > To keep the code simple the patch does not introduce 64 bit wide counter
> > > functions. Instead writing the cycle counter always sets the upper
> > > 32 bits so overflow interrupts are generated as before.
> > > 
> > > Original patch from Andrew Pinksi <Andrew.Pinksi at caviumnetworks.com>
> > 
> > What does this mean? Do we need Andrew's S-o-B, or is this a fresh patch?
> 
> Please let me know if I should repost or not, FWIW I got Andrew's S-o-B on the
> patch.

I think it's fine. This should all be in -next as of last Friday anyhow.

Will


From sricharan at codeaurora.org  Mon Feb 22 05:41:08 2016
From: sricharan at codeaurora.org (Sricharan)
Date: Mon, 22 Feb 2016 19:11:08 +0530
Subject: [PATCH V7 4/6] i2c: qup: Add bam dma capabilities
In-Reply-To: <20160222123225.GC1392@katana>
References: <1453197766-18976-1-git-send-email-sricharan@codeaurora.org>
 <1453197766-18976-5-git-send-email-sricharan@codeaurora.org>
 <20160212183737.GA1520@katana>
 <002a01d16d6c$0f790520$2e6b0f60$@codeaurora.org>
 <20160222123225.GC1392@katana>
Message-ID: <001c01d16d76$b43d2690$1cb773b0$@codeaurora.org>

Hi Wolfram,

> >   Regression and a fix is required on top of this series. So can I
> > send a separate fix on top of this series ?
> 
> Yes, do it like this. And please quote only relevant parts of a mail.
   Ok, will send a fix separately.   Sorry for the noisy reply previously ..


Regards,
 Sricharan



From vinmenon at codeaurora.org  Mon Feb 22 05:45:44 2016
From: vinmenon at codeaurora.org (Vinayak Menon)
Date: Mon, 22 Feb 2016 19:15:44 +0530
Subject: [PATCH] of: alloc anywhere from memblock if range not specified
Message-ID: <1456148744-7583-1-git-send-email-vinmenon@codeaurora.org>

early_init_dt_alloc_reserved_memory_arch passes end as 0 to
__memblock_alloc_base, when limits are not specified. But
__memblock_alloc_base takes end value of 0 as MEMBLOCK_ALLOC_ACCESSIBLE
and limits the end to memblock.current_limit. This results in regions
never being placed in HIGHMEM area, for e.g. CMA.
Let __memblock_alloc_base allocate from anywhere in memory if limits are
not specified.

Acked-by: Marek Szyprowski <m.szyprowski at samsung.com>
Signed-off-by: Vinayak Menon <vinmenon at codeaurora.org>
---
 drivers/of/of_reserved_mem.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1a3556a..ed01c01 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -32,11 +32,13 @@ int __init __weak early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
 	phys_addr_t align, phys_addr_t start, phys_addr_t end, bool nomap,
 	phys_addr_t *res_base)
 {
+	phys_addr_t base;
 	/*
 	 * We use __memblock_alloc_base() because memblock_alloc_base()
 	 * panic()s on allocation failure.
 	 */
-	phys_addr_t base = __memblock_alloc_base(size, align, end);
+	end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end;
+	base = __memblock_alloc_base(size, align, end);
 	if (!base)
 		return -ENOMEM;
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation



From aleksey.makarov at linaro.org  Mon Feb 22 05:46:48 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 22 Feb 2016 16:46:48 +0300
Subject: [PATCH 0/8] ACPI: parse the DBG2 table
Message-ID: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>

ARM Server Base Boot Requiremets' [1] mentions DBG2 (Microsoft Debug
Port Table 2) [2] as a mandatory ACPI table that specifies debug ports.

- Move acpi/dt decision earlier in boot process on ARM64
- Move earlycon early_param handling to serial to parse earlycon option once
- Add definition of DBG2 subtypes.  It's the same patch as in the SPCR series [3]
- Refactor ACPI linker tables code to enable iterating over subtables other than
  subtables having acpi_subtype header (such as DBG2)
- Implement macros

	ACPI_DBG2_DECLARE(name, type, subtype, setup_fn, data_ptr)

  that defines a handler for the port of the given type and subtype.
- For each port defined by that macros that is also described in the ACPI DBG2
  table call provided callback.
- Implement a helper macros that can be used to define early serial console
- Enable DBG2 on ARM64
- Define early console for pl011 serial

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
[2] http://go.microsoft.com/fwlink/p/?LinkId=234837
[3] https://lkml.kernel.org/g/455559532-8305-1-git-send-email-aleksey.makarov at linaro.org

Aleksey Makarov (6):
  ACPI: add definitions of DBG2 subtypes
  ACPI: genaralize iterating over subtables in ACPI_PROBE_TABLE()
  ACPI: parse DBG2 table
  ACPI: serial: implement earlycon on ACPI DBG2 port
  ACPI: enable ACPI_DBG2_TABLE on ARM64
  serial: pl011: add ACPI DBG2 serial port

Leif Lindholm (2):
  arm64: move acpi/dt decision earlier in boot process
  of/serial: move earlycon early_param handling to serial

 Documentation/kernel-parameters.txt  |   3 +
 arch/arm64/Kconfig                   |   1 +
 arch/arm64/kernel/acpi.c             |  56 ++++++++++---------
 drivers/acpi/Kconfig                 |   3 +
 drivers/acpi/Makefile                |   1 +
 drivers/acpi/dbg2.c                  |  85 ++++++++++++++++++++++++++++
 drivers/acpi/scan.c                  |  44 ++++++++++-----
 drivers/clocksource/arm_arch_timer.c |   3 +-
 drivers/irqchip/irq-gic.c            |   4 +-
 drivers/of/fdt.c                     |  11 +---
 drivers/tty/serial/amba-pl011.c      |   3 +
 drivers/tty/serial/earlycon.c        |  57 +++++++++++++++++++
 include/acpi/actbl2.h                |   5 ++
 include/asm-generic/vmlinux.lds.h    |   1 +
 include/linux/acpi.h                 | 104 ++++++++++++++++++++++++-----------
 include/linux/acpi_dbg2.h            |  68 +++++++++++++++++++++++
 include/linux/clocksource.h          |   2 +-
 include/linux/irqchip.h              |   5 +-
 include/linux/of_fdt.h               |   2 +
 19 files changed, 370 insertions(+), 88 deletions(-)
 create mode 100644 drivers/acpi/dbg2.c
 create mode 100644 include/linux/acpi_dbg2.h

-- 
2.7.1



From aleksey.makarov at linaro.org  Mon Feb 22 05:46:49 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 22 Feb 2016 16:46:49 +0300
Subject: [PATCH 1/8] arm64: move acpi/dt decision earlier in boot process
In-Reply-To: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456148818-26257-2-git-send-email-aleksey.makarov@linaro.org>

From: Leif Lindholm <leif.lindholm at linaro.org>

In order to support selecting earlycon via either ACPI or DT, move
the decision on whether to attempt ACPI configuration into the
early_param handling. Then make acpi_boot_table_init() bail out if
acpi_disabled.

Signed-off-by: Leif Lindholm <leif.lindholm at linaro.org>
---
 arch/arm64/kernel/acpi.c | 54 ++++++++++++++++++++++++++----------------------
 1 file changed, 29 insertions(+), 25 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2..7a944f7 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -44,6 +44,19 @@ EXPORT_SYMBOL(acpi_pci_disabled);
 static bool param_acpi_off __initdata;
 static bool param_acpi_force __initdata;
 
+static int __init dt_scan_depth1_nodes(unsigned long node,
+				       const char *uname, int depth,
+				       void *data)
+{
+	/*
+	 * Return 1 as soon as we encounter a node at depth 1 that is
+	 * not the /chosen node.
+	 */
+	if (depth == 1 && (strcmp(uname, "chosen") != 0))
+		return 1;
+	return 0;
+}
+
 static int __init parse_acpi(char *arg)
 {
 	if (!arg)
@@ -57,23 +70,27 @@ static int __init parse_acpi(char *arg)
 	else
 		return -EINVAL;	/* Core will print when we return error */
 
-	return 0;
-}
-early_param("acpi", parse_acpi);
+	/*
+	 * Enable ACPI instead of device tree unless
+	 * - ACPI has been disabled explicitly (acpi=off), or
+	 * - the device tree is not empty (it has more than just a /chosen node)
+	 *   and ACPI has not been force enabled (acpi=force)
+	 */
+	if (param_acpi_off ||
+	    (!param_acpi_force && of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
+		return 0;
 
-static int __init dt_scan_depth1_nodes(unsigned long node,
-				       const char *uname, int depth,
-				       void *data)
-{
 	/*
-	 * Return 1 as soon as we encounter a node at depth 1 that is
-	 * not the /chosen node.
+	 * ACPI is disabled at this point. Enable it in order to parse
+	 * the ACPI tables and carry out sanity checks
 	 */
-	if (depth == 1 && (strcmp(uname, "chosen") != 0))
-		return 1;
+	enable_acpi();
+
 	return 0;
 }
 
+early_param("acpi", parse_acpi);
+
 /*
  * __acpi_map_table() will be called before page_init(), so early_ioremap()
  * or early_memremap() should be called here to for ACPI table mapping.
@@ -181,23 +198,10 @@ out:
  */
 void __init acpi_boot_table_init(void)
 {
-	/*
-	 * Enable ACPI instead of device tree unless
-	 * - ACPI has been disabled explicitly (acpi=off), or
-	 * - the device tree is not empty (it has more than just a /chosen node)
-	 *   and ACPI has not been force enabled (acpi=force)
-	 */
-	if (param_acpi_off ||
-	    (!param_acpi_force && of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
+	if (acpi_disabled)
 		return;
 
 	/*
-	 * ACPI is disabled at this point. Enable it in order to parse
-	 * the ACPI tables and carry out sanity checks
-	 */
-	enable_acpi();
-
-	/*
 	 * If ACPI tables are initialized and FADT sanity checks passed,
 	 * leave ACPI enabled and carry on booting; otherwise disable ACPI
 	 * on initialization error.
-- 
2.7.1



From aleksey.makarov at linaro.org  Mon Feb 22 05:46:50 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 22 Feb 2016 16:46:50 +0300
Subject: [PATCH 2/8] of/serial: move earlycon early_param handling to serial
In-Reply-To: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456148818-26257-3-git-send-email-aleksey.makarov@linaro.org>

From: Leif Lindholm <leif.lindholm at linaro.org>

We have multiple "earlycon" early_param handlers - merge the DT one into
the main earlycon one. This means the earlycon early_param handler does
not just return success if no options are specified.

Signed-off-by: Leif Lindholm <leif.lindholm at linaro.org>
---
 drivers/of/fdt.c              | 11 +----------
 drivers/tty/serial/earlycon.c |  3 ++-
 include/linux/of_fdt.h        |  2 ++
 3 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 655f79d..6b4ab4f 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -798,7 +798,7 @@ static inline void early_init_dt_check_for_initrd(unsigned long node)
 #ifdef CONFIG_SERIAL_EARLYCON
 extern struct of_device_id __earlycon_of_table[];
 
-static int __init early_init_dt_scan_chosen_serial(void)
+int __init early_init_dt_scan_chosen_serial(void)
 {
 	int offset;
 	const char *p;
@@ -843,15 +843,6 @@ static int __init early_init_dt_scan_chosen_serial(void)
 	}
 	return -ENODEV;
 }
-
-static int __init setup_of_earlycon(char *buf)
-{
-	if (buf)
-		return 0;
-
-	return early_init_dt_scan_chosen_serial();
-}
-early_param("earlycon", setup_of_earlycon);
 #endif
 
 /**
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 3f24236..05f9e4b 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -17,6 +17,7 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/io.h>
+#include <linux/of_fdt.h>
 #include <linux/serial_core.h>
 #include <linux/sizes.h>
 #include <linux/mod_devicetable.h>
@@ -195,7 +196,7 @@ static int __init param_setup_earlycon(char *buf)
 	 * don't generate a warning from parse_early_params() in that case
 	 */
 	if (!buf || !buf[0])
-		return 0;
+		return early_init_dt_scan_chosen_serial();
 
 	err = setup_earlycon(buf);
 	if (err == -ENOENT || err == -EALREADY)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index df9ef38..4d783aa8 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -63,6 +63,7 @@ extern int early_init_dt_scan_chosen(unsigned long node, const char *uname,
 				     int depth, void *data);
 extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
 				     int depth, void *data);
+extern int early_init_dt_scan_chosen_serial(void);
 extern void early_init_fdt_scan_reserved_mem(void);
 extern void early_init_fdt_reserve_self(void);
 extern void early_init_dt_add_memory_arch(u64 base, u64 size);
@@ -91,6 +92,7 @@ extern void early_get_first_memblock_info(void *, phys_addr_t *);
 extern u64 fdt_translate_address(const void *blob, int node_offset);
 extern void of_fdt_limit_memory(int limit);
 #else /* CONFIG_OF_FLATTREE */
+static inline int early_init_dt_scan_chosen_serial(void) { return -ENODEV; }
 static inline void early_init_fdt_scan_reserved_mem(void) {}
 static inline void early_init_fdt_reserve_self(void) {}
 static inline const char *of_flat_dt_get_machine_name(void) { return NULL; }
-- 
2.7.1



From aleksey.makarov at linaro.org  Mon Feb 22 05:46:51 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 22 Feb 2016 16:46:51 +0300
Subject: [PATCH 3/8] ACPI: add definitions of DBG2 subtypes
In-Reply-To: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456148818-26257-4-git-send-email-aleksey.makarov@linaro.org>

The recent version of Microsoft Debug Port Table 2 (DBG2) [1]
specifies additional serial debug port subtypes.  These constants
are also referred by Serial Port Console Redirection Table (SPCR) [2]

Add these constants.

[1] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
[2] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 include/acpi/actbl2.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index a4ef625..652f747 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -371,6 +371,11 @@ struct acpi_dbg2_device {
 
 #define ACPI_DBG2_16550_COMPATIBLE  0x0000
 #define ACPI_DBG2_16550_SUBSET      0x0001
+#define ACPI_DBG2_ARM_PL011         0x0003
+#define ACPI_DBG2_ARM_SBSA_32BIT    0x000D
+#define ACPI_DBG2_ARM_SBSA_GENERIC  0x000E
+#define ACPI_DBG2_ARM_DCC           0x000F
+#define ACPI_DBG2_BCM2835           0x0010
 
 #define ACPI_DBG2_1394_STANDARD     0x0000
 
-- 
2.7.1



From aleksey.makarov at linaro.org  Mon Feb 22 05:46:52 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 22 Feb 2016 16:46:52 +0300
Subject: [PATCH 4/8] ACPI: genaralize iterating over subtables in
 ACPI_PROBE_TABLE()
In-Reply-To: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456148818-26257-5-git-send-email-aleksey.makarov@linaro.org>

Refactor ACPI_PROBE_TABLE() so that it is possible to iterate
over subtables that do not have acpi_subtype header (for example
over subtables of DBG2 table)

To do so:

- Add void * data pointer argument for callback.  It will allow to
  parse the table and iterate over subtables calling the subtable
  callbacks that are provided via this data pointer.
- Save only ACPI table id, callback and callback data in the linker
  tables.  This makes tables more terse and simplifies the semantics
  of the fields of it's elements.
  The additional data that required for subtable parsing are saved
  in static namespace without increasing the size of linker tables.
- Introduce two macros with clear meaning of arguments, instead one.
  The old ACPI_DECLARE_PROBE_ENTRY() macros has arguments that have
  different meaning if the entry is for table or for subtable.  The
  arguments of the new macroses ACPI_DECLARE_PROBE_ENTRY() and
  ACPI_DECLARE_PROBE_SUBTYPE_ENTRY() have unambiguous meaning.
- Document arguments of those macroses instead of the fields of linker
  table data.
- Fix the issue that prevents using this macros for parsing subtables
  other than MADT.  In the original code, MADT-specific function
  was used to iterate over subtables, while the name was common.
  Introduce a new parameter to macors that specifies the size of
  the table to do it in common way.
- Don't expose the internals of the tables to the drivers passing
  a pointer to struct acpi_probe_entry to the subtable callback validator.
  Instead, pass the sideband data specified by the driver.
- Fix the driver's callback signatures: a. Add an unused pointer to void
  for table matchers (currently only clocksource callback) b. Change
  the type of sideband data to kernel_ulong_t.

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 drivers/acpi/scan.c                  |  44 ++++++++++-----
 drivers/clocksource/arm_arch_timer.c |   3 +-
 drivers/irqchip/irq-gic.c            |   4 +-
 include/linux/acpi.h                 | 104 ++++++++++++++++++++++++-----------
 include/linux/clocksource.h          |   2 +-
 include/linux/irqchip.h              |   5 +-
 6 files changed, 109 insertions(+), 53 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 407a376..a258594 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1968,16 +1968,38 @@ static struct acpi_probe_entry *ape;
 static int acpi_probe_count;
 static DEFINE_SPINLOCK(acpi_probe_lock);
 
-static int __init acpi_match_madt(struct acpi_subtable_header *header,
-				  const unsigned long end)
+static int __init acpi_match_and_setup(struct acpi_subtable_header *header,
+				       const unsigned long end)
 {
-	if (!ape->subtable_valid || ape->subtable_valid(header, ape))
-		if (!ape->probe_subtbl(header, end))
+	const struct acpi_probe_subtype_data *data = ape->data;
+
+	if (data->valid(header, data->data))
+		if (!data->setup(header, end))
 			acpi_probe_count++;
 
 	return 0;
 }
 
+int __init acpi_probe_subtype_setup(struct acpi_table_header *table,
+				    const void *data)
+{
+	const struct acpi_probe_subtype_data *data_subtype = data;
+
+	return acpi_parse_entries(ape->id, data_subtype->size,
+				  acpi_match_and_setup, table,
+				  data_subtype->subtype, 0);
+}
+
+static int __init acpi_probe_table_handler(struct acpi_table_header *table)
+{
+	int err = ape->setup(table, ape->data);
+
+	if (ape->setup != acpi_probe_subtype_setup && err >= 0)
+		acpi_probe_count++;
+
+	return err;
+}
+
 int __init __acpi_probe_device_table(struct acpi_probe_entry *ap_head, int nr)
 {
 	int count = 0;
@@ -1987,16 +2009,10 @@ int __init __acpi_probe_device_table(struct acpi_probe_entry *ap_head, int nr)
 
 	spin_lock(&acpi_probe_lock);
 	for (ape = ap_head; nr; ape++, nr--) {
-		if (ACPI_COMPARE_NAME(ACPI_SIG_MADT, ape->id)) {
-			acpi_probe_count = 0;
-			acpi_table_parse_madt(ape->type, acpi_match_madt, 0);
-			count += acpi_probe_count;
-		} else {
-			int res;
-			res = acpi_table_parse(ape->id, ape->probe_table);
-			if (!res)
-				count++;
-		}
+		acpi_probe_count = 0;
+		if (acpi_table_parse(ape->id, acpi_probe_table_handler) < 0)
+			continue;
+		count += acpi_probe_count;
 	}
 	spin_unlock(&acpi_probe_lock);
 
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index c64d543..95c4922e 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -826,7 +826,8 @@ static int __init map_generic_timer_interrupt(u32 interrupt, u32 flags)
 }
 
 /* Initialize per-processor generic timer */
-static int __init arch_timer_acpi_init(struct acpi_table_header *table)
+static int __init arch_timer_acpi_init(struct acpi_table_header *table,
+				       const void *data)
 {
 	struct acpi_table_gtdt *gtdt;
 
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 8f9ebf7..37a5eed 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -1287,12 +1287,12 @@ static bool __init acpi_gic_redist_is_present(void)
 }
 
 static bool __init gic_validate_dist(struct acpi_subtable_header *header,
-				     struct acpi_probe_entry *ape)
+				     kernel_ulong_t driver_data)
 {
 	struct acpi_madt_generic_distributor *dist;
 	dist = (struct acpi_madt_generic_distributor *)header;
 
-	return (dist->version == ape->driver_data &&
+	return (dist->version == driver_data &&
 		(dist->version != ACPI_MADT_GIC_VERSION_NONE ||
 		 !acpi_gic_redist_is_present()));
 }
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 06ed7e5..9636c32 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -879,47 +879,76 @@ int acpi_dev_prop_read(struct acpi_device *adev, const char *propname,
 struct fwnode_handle *acpi_get_next_subnode(struct device *dev,
 					    struct fwnode_handle *subnode);
 
-struct acpi_probe_entry;
 typedef bool (*acpi_probe_entry_validate_subtbl)(struct acpi_subtable_header *,
-						 struct acpi_probe_entry *);
+						 kernel_ulong_t);
+
+typedef int (*acpi_probe_entry_setup)(struct acpi_table_header *, const void *);
 
 #define ACPI_TABLE_ID_LEN	5
 
-/**
- * struct acpi_probe_entry - boot-time probing entry
- * @id:			ACPI table name
- * @type:		Optional subtable type to match
- *			(if @id contains subtables)
- * @subtable_valid:	Optional callback to check the validity of
- *			the subtable
- * @probe_table:	Callback to the driver being probed when table
- *			match is successful
- * @probe_subtbl:	Callback to the driver being probed when table and
- *			subtable match (and optional callback is successful)
- * @driver_data:	Sideband data provided back to the driver
- */
 struct acpi_probe_entry {
 	__u8 id[ACPI_TABLE_ID_LEN];
-	__u8 type;
-	acpi_probe_entry_validate_subtbl subtable_valid;
-	union {
-		acpi_tbl_table_handler probe_table;
-		acpi_tbl_entry_handler probe_subtbl;
-	};
-	kernel_ulong_t driver_data;
+	acpi_probe_entry_setup setup;
+	const void *data;
 };
 
-#define ACPI_DECLARE_PROBE_ENTRY(table, name, table_id, subtable, valid, data, fn)	\
+/**
+ * ACPI_DECLARE_PROBE_ENTRY() - declare boot-time probing entry
+ * @table:		Name of subsystem to match
+ * @name:               Identifier to compose name of table data
+ * @table_id:		ACPI table name
+ * @setup_fn:		Callback to the driver being probed when table
+ *			matches (of type acpi_probe_entry_setup)
+ * @data_ptr:		Sideband data provided back to the driver
+ */
+#define ACPI_DECLARE_PROBE_ENTRY(table, name, table_id, setup_fn, data_ptr) \
 	static const struct acpi_probe_entry __acpi_probe_##name	\
 		__used __section(__##table##_acpi_probe_table)		\
 		 = {							\
 			.id = table_id,					\
-			.type = subtable,				\
-			.subtable_valid = valid,			\
-			.probe_table = (acpi_tbl_table_handler)fn,	\
-			.driver_data = data, 				\
+			.setup = setup_fn,				\
+			.data = data_ptr,				\
 		   }
 
+struct acpi_probe_subtype_data {
+	u8 subtype;
+	unsigned long size;
+	acpi_probe_entry_validate_subtbl valid;
+	acpi_tbl_entry_handler setup;
+	kernel_ulong_t data;
+};
+
+int acpi_probe_subtype_setup(struct acpi_table_header *table, const void *data);
+
+/**
+ * ACPI_DECLARE_PROBE_SUBTYPE_ENTRY() - declare boot-time probing entry that
+ *				      matches subtables
+ * @table:		Name of subsystem to match
+ * @name:               Identifier to compose name of table data
+ * @table_id:		ACPI table name
+ * @table_size:		Size of the table (without subtables) of type table_id
+ * @subtable:		Subtable type to match
+ * @valid_fn:		Callback to check the validity of the subtable
+ *			(of type acpi_probe_entry_validate_subtbl)
+ * @data_int:		Sideband data provided back to the driver
+ *			(of type kernel_ulong_t)
+ * @setup_fn:		Callback to the driver being probed when table and
+ *			subtable match and valid_fn callback is successful
+ *			(of type acpi_tbl_entry_handler)
+ */
+#define ACPI_DECLARE_PROBE_SUBTYPE_ENTRY(table, name, table_id, table_size, \
+				subtable, valid_fn, data_int, setup_fn)     \
+	static const struct acpi_probe_subtype_data			    \
+	__acpi_probe_subtype_##name __used = {				    \
+			.subtype = subtable,				    \
+			.size = table_size,				    \
+			.valid = valid_fn,				    \
+			.setup = setup_fn,				    \
+			.data = data_int,				    \
+		   };							    \
+	ACPI_DECLARE_PROBE_ENTRY(table, name, table_id,			    \
+		acpi_probe_subtype_setup, &__acpi_probe_subtype_##name)
+
 #define ACPI_PROBE_TABLE(name)		__##name##_acpi_probe_table
 #define ACPI_PROBE_TABLE_END(name)	__##name##_acpi_probe_table_end
 
@@ -992,14 +1021,23 @@ static inline struct fwnode_handle *acpi_get_next_subnode(struct device *dev,
 	return NULL;
 }
 
-#define ACPI_DECLARE_PROBE_ENTRY(table, name, table_id, subtable, validate, data, fn) \
+#define ACPI_DECLARE_PROBE_ENTRY(table, name, table_id, match, data)	\
 	static const void * __acpi_table_##name[]			\
 		__attribute__((unused))					\
-		 = { (void *) table_id,					\
-		     (void *) subtable,					\
-		     (void *) valid,					\
-		     (void *) fn,					\
-		     (void *) data }
+		 = { (void *)table_id,					\
+		     (void *)match,					\
+		     (void *)data }
+
+#define ACPI_DECLARE_PROBE_SUBTYPE_ENTRY(table, name, table_id, table_size, \
+				subtable, valid_fn, data_int, setup_fn)	    \
+	static const void *__acpi_table_##name[]			\
+		__attribute__((unused))					\
+		 = { (void *)table_id,					\
+		     (void *)table_size,				\
+		     (void *)subtable,					\
+		     (void *)valid_fn,					\
+		     (void *)data_int,					\
+		     (void *)setup_fn }
 
 #define acpi_probe_device_table(t)	({ int __r = 0; __r;})
 #endif
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 6013021..2bb5d51 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -259,6 +259,6 @@ static inline void clocksource_probe(void) {}
 #endif
 
 #define CLOCKSOURCE_ACPI_DECLARE(name, table_id, fn)		\
-	ACPI_DECLARE_PROBE_ENTRY(clksrc, name, table_id, 0, NULL, 0, fn)
+	ACPI_DECLARE_PROBE_ENTRY(clksrc, name, table_id, fn, NULL)
 
 #endif /* _LINUX_CLOCKSOURCE_H */
diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h
index 89c34b2..cc4c455 100644
--- a/include/linux/irqchip.h
+++ b/include/linux/irqchip.h
@@ -39,8 +39,9 @@
  * @fn: initialization function
  */
 #define IRQCHIP_ACPI_DECLARE(name, subtable, validate, data, fn)	\
-	ACPI_DECLARE_PROBE_ENTRY(irqchip, name, ACPI_SIG_MADT, 		\
-				 subtable, validate, data, fn)
+	ACPI_DECLARE_PROBE_SUBTYPE_ENTRY(irqchip, name, ACPI_SIG_MADT,	\
+					 sizeof(struct acpi_table_madt),\
+					 subtable, validate, data, fn)
 
 #ifdef CONFIG_IRQCHIP
 void irqchip_init(void);
-- 
2.7.1



From aleksey.makarov at linaro.org  Mon Feb 22 05:46:53 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 22 Feb 2016 16:46:53 +0300
Subject: [PATCH 5/8] ACPI: parse DBG2 table
In-Reply-To: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456148818-26257-6-git-send-email-aleksey.makarov@linaro.org>

'ARM Server Base Boot Requiremets' [1] mentions DBG2 (Microsoft Debug
Port Table 2) [2] as a mandatory ACPI table that specifies debug ports.

- Implement macros

	ACPI_DBG2_DECLARE(name, type, subtype, setup_fn, data_ptr)

  that defines a handler for the port of given type and subtype.

- For each declared port that is also described in the ACPI DBG2 table
  call the provided callback.

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
[2] http://go.microsoft.com/fwlink/p/?LinkId=234837

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 drivers/acpi/Kconfig              |  3 ++
 drivers/acpi/Makefile             |  1 +
 drivers/acpi/dbg2.c               | 85 +++++++++++++++++++++++++++++++++++++++
 include/asm-generic/vmlinux.lds.h |  1 +
 include/linux/acpi_dbg2.h         | 48 ++++++++++++++++++++++
 5 files changed, 138 insertions(+)
 create mode 100644 drivers/acpi/dbg2.c
 create mode 100644 include/linux/acpi_dbg2.h

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 65fb483..660666e 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -57,6 +57,9 @@ config ACPI_SYSTEM_POWER_STATES_SUPPORT
 config ACPI_CCA_REQUIRED
 	bool
 
+config ACPI_DBG2_TABLE
+	bool
+
 config ACPI_DEBUGGER
 	bool "AML debugger interface"
 	select ACPI_DEBUG
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 346101c..ff5e4f0 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
 obj-$(CONFIG_ACPI_BGRT)		+= bgrt.o
 obj-$(CONFIG_ACPI_CPPC_LIB)	+= cppc_acpi.o
 obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
+obj-$(CONFIG_ACPI_DBG2_TABLE)	+= dbg2.o
 
 # processor has its own "processor." module_param namespace
 processor-y			:= processor_driver.o
diff --git a/drivers/acpi/dbg2.c b/drivers/acpi/dbg2.c
new file mode 100644
index 0000000..8a79117
--- /dev/null
+++ b/drivers/acpi/dbg2.c
@@ -0,0 +1,85 @@
+/*
+ * Copyright (c) 2012, Intel Corporation
+ * Copyright (c) 2015, 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#define pr_fmt(fmt) "ACPI: DBG2: " fmt
+
+#include <linux/acpi_dbg2.h>
+#include <linux/acpi.h>
+#include <linux/kernel.h>
+
+static const char * __init type2string(u16 type)
+{
+	switch (type) {
+	case ACPI_DBG2_SERIAL_PORT:
+		return "SERIAL";
+	case ACPI_DBG2_1394_PORT:
+		return "1394";
+	case ACPI_DBG2_USB_PORT:
+		return "USB";
+	case ACPI_DBG2_NET_PORT:
+		return "NET";
+	default:
+		return "?";
+	}
+}
+
+static const char * __init subtype2string(u16 subtype)
+{
+	switch (subtype) {
+	case ACPI_DBG2_16550_COMPATIBLE:
+		return "16550_COMPATIBLE";
+	case ACPI_DBG2_16550_SUBSET:
+		return "16550_SUBSET";
+	case ACPI_DBG2_ARM_PL011:
+		return "ARM_PL011";
+	case ACPI_DBG2_ARM_SBSA_32BIT:
+		return "ARM_SBSA_32BIT";
+	case ACPI_DBG2_ARM_SBSA_GENERIC:
+		return "ARM_SBSA_GENERIC";
+	case ACPI_DBG2_ARM_DCC:
+		return "ARM_DCC";
+	case ACPI_DBG2_BCM2835:
+		return "BCM2835";
+	default:
+		return "?";
+	}
+}
+
+int __init acpi_dbg2_setup(struct acpi_table_header *table, const void *data)
+{
+	struct acpi_table_dbg2 *dbg2 = (struct acpi_table_dbg2 *)table;
+	struct acpi_dbg2_data *dbg2_data = (struct acpi_dbg2_data *)data;
+	struct acpi_dbg2_device *dbg2_device, *dbg2_end;
+	int i;
+
+	dbg2_device = ACPI_ADD_PTR(struct acpi_dbg2_device, dbg2,
+				   dbg2->info_offset);
+	dbg2_end = ACPI_ADD_PTR(struct acpi_dbg2_device, dbg2, table->length);
+
+	for (i = 0; i < dbg2->info_count; i++) {
+		if (dbg2_device + 1 > dbg2_end) {
+			pr_err("device pointer overflows, bad table\n");
+			return 0;
+		}
+
+		if (dbg2_device->port_type == dbg2_data->port_type &&
+		    dbg2_device->port_subtype == dbg2_data->port_subtype) {
+			pr_info("debug port type: %s subtype: %s\n",
+				type2string(dbg2_device->port_type),
+				subtype2string(dbg2_device->port_subtype));
+			dbg2_data->setup(dbg2_device, dbg2_data->data);
+		}
+
+		dbg2_device = ACPI_ADD_PTR(struct acpi_dbg2_device, dbg2_device,
+					   dbg2_device->length);
+	}
+
+	return 0;
+}
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index c4bd0e2..ad9752c 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -526,6 +526,7 @@
 	IRQCHIP_OF_MATCH_TABLE()					\
 	ACPI_PROBE_TABLE(irqchip)					\
 	ACPI_PROBE_TABLE(clksrc)					\
+	ACPI_PROBE_TABLE(dbg2)						\
 	EARLYCON_TABLE()						\
 	EARLYCON_OF_TABLES()
 
diff --git a/include/linux/acpi_dbg2.h b/include/linux/acpi_dbg2.h
new file mode 100644
index 0000000..465afcb
--- /dev/null
+++ b/include/linux/acpi_dbg2.h
@@ -0,0 +1,48 @@
+#ifndef _ACPI_DBG2_H_
+#define _ACPI_DBG2_H_
+
+#ifdef CONFIG_ACPI_DBG2_TABLE
+
+#include <linux/kernel.h>
+
+struct acpi_dbg2_device;
+struct acpi_table_header;
+
+struct acpi_dbg2_data {
+	u16 port_type;
+	u16 port_subtype;
+	int (*setup)(struct acpi_dbg2_device *, void *);
+	void *data;
+};
+
+int acpi_dbg2_setup(struct acpi_table_header *header, const void *data);
+
+/*
+ * ACPI_DBG2_DECLARE() - Define handler for ACPI DBG2 port
+ * @name:	Identifier to compose name of table data
+ * @type:	Type of the port
+ * @subtype:	Subtype of the port
+ * @setup_fn:	Function to be called to setup the port
+ *		(of type int (*)(struct acpi_dbg2_device *, void *);)
+ * @data_ptr:	Sideband data provided back to the driver
+ */
+#define ACPI_DBG2_DECLARE(name, type, subtype, setup_fn, data_ptr)	\
+	static const struct acpi_dbg2_data				\
+		__acpi_dbg2_data_##name __used = {			\
+			.port_type = type,				\
+			.port_subtype = subtype,			\
+			.setup = setup_fn,				\
+			.data = data_ptr,				\
+		   };							\
+	ACPI_DECLARE_PROBE_ENTRY(dbg2, name, ACPI_SIG_DBG2,		\
+				 acpi_dbg2_setup, &__acpi_dbg2_data_##name)
+
+#else
+
+#define ACPI_DBG2_DECLARE(name, type, subtype, setup_fn, data_ptr)	\
+	static const void *__acpi_dbg_data_##name[]			\
+		__used __initdata = { (void *)setup_fn,	(void *)data_ptr }
+
+#endif
+
+#endif
-- 
2.7.1



From aleksey.makarov at linaro.org  Mon Feb 22 05:46:54 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 22 Feb 2016 16:46:54 +0300
Subject: [PATCH 6/8] ACPI: serial: implement earlycon on ACPI DBG2 port
In-Reply-To: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456148818-26257-7-git-send-email-aleksey.makarov@linaro.org>

Add ACPI_DBG2_EARLYCON_DECLARE() macros that declares
an earlycon on the serial port specified in the DBG2 ACPI table.

Pass the string "earlycon=acpi_dbg2" to the kernel to activate it.

Callbacks for EARLYCON_DECLARE() and OF_EARLYCON_DECLARE()
can also be used for this macros.

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 Documentation/kernel-parameters.txt |  3 ++
 drivers/tty/serial/earlycon.c       | 56 +++++++++++++++++++++++++++++++++++++
 include/linux/acpi_dbg2.h           | 20 +++++++++++++
 3 files changed, 79 insertions(+)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 9a53c92..4949ebb 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1058,6 +1058,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			A valid base address must be provided, and the serial
 			port must already be setup and configured.
 
+		acpi_dbg2
+			Use serial port specified by the DBG2 ACPI table.
+
 	earlyprintk=	[X86,SH,BLACKFIN,ARM,M68k]
 			earlyprintk=vga
 			earlyprintk=efi
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 05f9e4b..3d11248 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -21,6 +21,7 @@
 #include <linux/serial_core.h>
 #include <linux/sizes.h>
 #include <linux/mod_devicetable.h>
+#include <linux/acpi.h>
 
 #ifdef CONFIG_FIX_EARLYCON_MEM
 #include <asm/fixmap.h>
@@ -186,6 +187,8 @@ int __init setup_earlycon(char *buf)
 	return -ENOENT;
 }
 
+static bool setup_dbg2_earlycon;
+
 /* early_param wrapper for setup_earlycon() */
 static int __init param_setup_earlycon(char *buf)
 {
@@ -198,6 +201,11 @@ static int __init param_setup_earlycon(char *buf)
 	if (!buf || !buf[0])
 		return early_init_dt_scan_chosen_serial();
 
+	if (!strcmp(buf, "acpi_dbg2")) {
+		setup_dbg2_earlycon = true;
+		return 0;
+	}
+
 	err = setup_earlycon(buf);
 	if (err == -ENOENT || err == -EALREADY)
 		return 0;
@@ -228,3 +236,51 @@ int __init of_setup_earlycon(unsigned long addr,
 	register_console(early_console_dev.con);
 	return 0;
 }
+
+int __init acpi_setup_earlycon(struct acpi_dbg2_device *device, void *d)
+{
+	int err;
+	struct uart_port *port = &early_console_dev.port;
+	int (*setup)(struct earlycon_device *, const char *) = d;
+	struct acpi_generic_address *reg;
+
+	if (!setup_dbg2_earlycon)
+		return -ENODEV;
+
+	if (device->register_count < 1)
+		return -ENODEV;
+
+	if (device->base_address_offset >= device->length)
+		return -EINVAL;
+
+	reg = (void *)device + device->base_address_offset;
+
+	if (reg->space_id != ACPI_ADR_SPACE_SYSTEM_MEMORY &&
+	    reg->space_id != ACPI_ADR_SPACE_SYSTEM_IO)
+		return -EINVAL;
+
+	spin_lock_init(&port->lock);
+	port->uartclk = BASE_BAUD * 16;
+
+	if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
+		if (device->port_type == ACPI_DBG2_ARM_SBSA_32BIT)
+			port->iotype = UPIO_MEM32;
+		else
+			port->iotype = UPIO_MEM;
+		port->mapbase = reg->address;
+		port->membase = earlycon_map(reg->address, SZ_4K);
+	} else {
+		port->iotype = UPIO_PORT;
+		port->iobase = reg->address;
+	}
+
+	early_console_dev.con->data = &early_console_dev;
+	err = setup(&early_console_dev, NULL);
+	if (err < 0)
+		return err;
+	if (!early_console_dev.con->write)
+		return -ENODEV;
+
+	register_console(early_console_dev.con);
+	return 0;
+}
diff --git a/include/linux/acpi_dbg2.h b/include/linux/acpi_dbg2.h
index 465afcb..9b96de2 100644
--- a/include/linux/acpi_dbg2.h
+++ b/include/linux/acpi_dbg2.h
@@ -37,12 +37,32 @@ int acpi_dbg2_setup(struct acpi_table_header *header, const void *data);
 	ACPI_DECLARE_PROBE_ENTRY(dbg2, name, ACPI_SIG_DBG2,		\
 				 acpi_dbg2_setup, &__acpi_dbg2_data_##name)
 
+int __init acpi_setup_earlycon(struct acpi_dbg2_device *device, void *d);
+
+/*
+ * ACPI_DBG2_EARLYCON_DECLARE() - Define handler for ACPI GDB2 serial port
+ * @name:		Identifier to compose name of table data
+ * @subtype:		Subtype of the port
+ * @console_setup:	Function to be called to setup the port
+ *
+ * Type of the console_setup() callback is
+ * int (*setup)(struct earlycon_device *, const char *)
+ * It's the type of callback of of_setup_earlycon().
+ */
+#define ACPI_DBG2_EARLYCON_DECLARE(name, subtype, console_setup)	\
+	ACPI_DBG2_DECLARE(name, ACPI_DBG2_SERIAL_PORT, subtype,		\
+			  acpi_setup_earlycon, console_setup)
+
 #else
 
 #define ACPI_DBG2_DECLARE(name, type, subtype, setup_fn, data_ptr)	\
 	static const void *__acpi_dbg_data_##name[]			\
 		__used __initdata = { (void *)setup_fn,	(void *)data_ptr }
 
+#define ACPI_DBG2_EARLYCON_DECLARE(name, subtype, console_setup)	\
+	static const void *__acpi_dbg_data_serial_##name[]		\
+		__used __initdata = { (void *)console_setup }
+
 #endif
 
 #endif
-- 
2.7.1



From aleksey.makarov at linaro.org  Mon Feb 22 05:46:55 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 22 Feb 2016 16:46:55 +0300
Subject: [PATCH 7/8] ACPI: enable ACPI_DBG2_TABLE on ARM64
In-Reply-To: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456148818-26257-8-git-send-email-aleksey.makarov@linaro.org>

SBBR mentions DBG2 as a mandatory ACPI table.
So enable it for ARM64

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 arch/arm64/Kconfig       | 1 +
 arch/arm64/kernel/acpi.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6bb21d8..27cb5d7 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -3,6 +3,7 @@ config ARM64
 	select ACPI_CCA_REQUIRED if ACPI
 	select ACPI_GENERIC_GSI if ACPI
 	select ACPI_REDUCED_HARDWARE_ONLY if ACPI
+	select ACPI_DBG2_TABLE if ACPI
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_ELF_RANDOMIZE
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 7a944f7..890d36f 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -213,6 +213,8 @@ void __init acpi_boot_table_init(void)
 		if (!param_acpi_force)
 			disable_acpi();
 	}
+
+	acpi_probe_device_table(dbg2);
 }
 
 #ifdef CONFIG_ACPI_APEI
-- 
2.7.1



From aleksey.makarov at linaro.org  Mon Feb 22 05:46:56 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 22 Feb 2016 16:46:56 +0300
Subject: [PATCH 8/8] serial: pl011: add ACPI DBG2 serial port
In-Reply-To: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456148818-26257-9-git-send-email-aleksey.makarov@linaro.org>

Add a handler for ACPI DBG2 serial port of type ACPI_DBG2_ARM_PL011
that sets up an earlycon on it.

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 drivers/tty/serial/amba-pl011.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index c0da0cc..5633741 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -59,6 +59,7 @@
 #include <linux/sizes.h>
 #include <linux/io.h>
 #include <linux/acpi.h>
+#include <linux/acpi_dbg2.h>
 
 #include "amba-pl011.h"
 
@@ -2329,6 +2330,8 @@ static int __init pl011_early_console_setup(struct earlycon_device *device,
 }
 EARLYCON_DECLARE(pl011, pl011_early_console_setup);
 OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
+ACPI_DBG2_EARLYCON_DECLARE(pl011, ACPI_DBG2_ARM_PL011,
+			   pl011_early_console_setup);
 
 #else
 #define AMBA_CONSOLE	NULL
-- 
2.7.1



From linus.walleij at linaro.org  Mon Feb 22 06:01:01 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Feb 2016 15:01:01 +0100
Subject: [PATCH 1/3 v2] irqchip: gic/realview: support more RealView DCC
 variants
Message-ID: <1456149661-19118-1-git-send-email-linus.walleij@linaro.org>

In the add-on file for the GIC dealing with the RealView family
we currently only handle the PB11MPCore, let's extend this to
manage the RealView EB ARM11MPCore as well. The Revision B of the
ARM11MPCore core tile is a bit special and needs special handling
as it moves a system control register around at random.

Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: devicetree at vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Detect syscon register location based on the syscon compatible
  string instead of the GIC compatible string, just define one
  compatible string for the 11mp test chip GIC.
- Consistently return -ENODEV
This can be applied in isolation from the other patches so Marc
one you're happy with it, please take it into the IRQchip tree.
---
 .../bindings/interrupt-controller/arm,gic.txt      |  1 +
 drivers/irqchip/irq-gic-realview.c                 | 44 +++++++++++++++++++---
 2 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
index 5a1cb4bc3dfe..793c20ff8fcc 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
@@ -16,6 +16,7 @@ Main node required properties:
 	"arm,cortex-a15-gic"
 	"arm,cortex-a7-gic"
 	"arm,cortex-a9-gic"
+	"arm,eb11mp-gic"
 	"arm,gic-400"
 	"arm,pl390"
 	"arm,tc11mp-gic"
diff --git a/drivers/irqchip/irq-gic-realview.c b/drivers/irqchip/irq-gic-realview.c
index aa46eb280a7f..54c296401525 100644
--- a/drivers/irqchip/irq-gic-realview.c
+++ b/drivers/irqchip/irq-gic-realview.c
@@ -10,7 +10,8 @@
 #include <linux/irqchip/arm-gic.h>
 
 #define REALVIEW_SYS_LOCK_OFFSET	0x20
-#define REALVIEW_PB11MP_SYS_PLD_CTRL1	0x74
+#define REALVIEW_SYS_PLD_CTRL1		0x74
+#define REALVIEW_EB_REVB_SYS_PLD_CTRL1	0xD8
 #define VERSATILE_LOCK_VAL		0xA05F
 #define PLD_INTMODE_MASK		BIT(22)|BIT(23)|BIT(24)
 #define PLD_INTMODE_LEGACY		0x0
@@ -18,26 +19,57 @@
 #define PLD_INTMODE_NEW_NO_DCC		BIT(23)
 #define PLD_INTMODE_FIQ_ENABLE		BIT(24)
 
+/* For some reason RealView EB Rev B moved this register */
+static const struct of_device_id syscon_pldset_of_match[] = {
+	{
+		.compatible = "arm,realview-eb11mp-revb-syscon",
+		.data = (void *)REALVIEW_EB_REVB_SYS_PLD_CTRL1,
+	},
+	{
+		.compatible = "arm,realview-eb11mp-revc-syscon",
+		.data = (void *)REALVIEW_SYS_PLD_CTRL1,
+	},
+	{
+		.compatible = "arm,realview-eb-syscon",
+		.data = (void *)REALVIEW_SYS_PLD_CTRL1,
+	},
+	{
+		.compatible = "arm,realview-pb11mp-syscon",
+		.data = (void *)REALVIEW_SYS_PLD_CTRL1,
+	},
+	{},
+};
+
 static int __init
 realview_gic_of_init(struct device_node *node, struct device_node *parent)
 {
 	static struct regmap *map;
+	struct device_node *np;
+	const struct of_device_id *gic_id;
+	u32 pld1_ctrl;
+
+	np = of_find_matching_node_and_match(NULL, syscon_pldset_of_match,
+					     &gic_id);
+	if (!np)
+		return -ENODEV;
+	pld1_ctrl = (u32)gic_id->data;
 
 	/* The PB11MPCore GIC needs to be configured in the syscon */
-	map = syscon_regmap_lookup_by_compatible("arm,realview-pb11mp-syscon");
+	map = syscon_node_to_regmap(np);
 	if (!IS_ERR(map)) {
 		/* new irq mode with no DCC */
 		regmap_write(map, REALVIEW_SYS_LOCK_OFFSET,
 			     VERSATILE_LOCK_VAL);
-		regmap_update_bits(map, REALVIEW_PB11MP_SYS_PLD_CTRL1,
+		regmap_update_bits(map, pld1_ctrl,
 				   PLD_INTMODE_NEW_NO_DCC,
 				   PLD_INTMODE_MASK);
 		regmap_write(map, REALVIEW_SYS_LOCK_OFFSET, 0x0000);
-		pr_info("TC11MP GIC: set up interrupt controller to NEW mode, no DCC\n");
+		pr_info("RealView GIC: set up interrupt controller to NEW mode, no DCC\n");
 	} else {
-		pr_err("TC11MP GIC setup: could not find syscon\n");
-		return -ENXIO;
+		pr_err("RealView GIC setup: could not find syscon\n");
+		return -ENODEV;
 	}
 	return gic_of_init(node, parent);
 }
 IRQCHIP_DECLARE(armtc11mp_gic, "arm,tc11mp-gic", realview_gic_of_init);
+IRQCHIP_DECLARE(armeb11mp_gic, "arm,eb11mp-gic", realview_gic_of_init);
-- 
2.4.3



From ard.biesheuvel at linaro.org  Mon Feb 22 06:02:06 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 15:02:06 +0100
Subject: [RFC PATCH 0/2] fix memremap on ARM
Message-ID: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>

This is something I ran into while working on support for the UEFI
memory attributes and ESRT tables. In both cases, these tables are
passed to the kernel in memory which is guaranteed to be below 4 GB,
but may be outside of the kernel direct mapping. (UEFI typically
attempts to allocate from the top down, which means such tables are
highly likely to be in highmem for any system with more than 760 MB
of system RAM)

The recently introduced memremap() is a very useful abstraction for
accessing such tables, because it is generic, and already attempts to
do the right thing with respect to regions that may already have been
mapped directly. However, it falls back to ioremap_cache() for mapping
high memory, which is not allowed on ARM.

So instead, create an arch specific hook 'arch_memremap_wb(), and
implement it for ARM using the same memory attributes used for the
linear mapping.

Note that memremap will only call this hook for regions that are not
already mapped permanently.

Ard Biesheuvel (2):
  memremap: add arch specific hook for MEMREMAP_WB mappings
  ARM: memremap: implement arch_memremap_wb()

 arch/arm/include/asm/io.h |  3 +++
 arch/arm/mm/ioremap.c     | 11 +++++++++--
 kernel/memremap.c         | 11 ++++++++---
 3 files changed, 20 insertions(+), 5 deletions(-)

-- 
2.5.0



From linus.walleij at linaro.org  Mon Feb 22 06:02:01 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Feb 2016 15:02:01 +0100
Subject: [PATCH 3/3 v2] ARM: realview: support all the RealView EB board
 variants
Message-ID: <1456149721-19276-1-git-send-email-linus.walleij@linaro.org>

The ARM RealView Evaluation Baseboards are basically these:

- The original ARMv5 EB board with an ARM926EJ-S, ARM1136 or
  ARM1176 core tile here described in arm-realview-eb.dts
  no matter which of these core tiles is being used. This
  can be emulated by QEMU "realview-eb" machine, which by
  default will have the ARM926EJ-S core tile.

- The same board with one of three MPCore Core tiles:
  ARM11MPCore, not to be confused with the similar ARM
  PB11MPCore ARM11MPCore test system. This exist in
  two revisions:
  - Revision A modeled in arm-realview-eb-11mp.dts
  - Revision B modeled arm-realview-eb-11mp-revb.dts
    Revision B can be emulated by the QEMU
    "realview-eb-mpcore" machine, but to match the hardware
    also the argument -smp cpus=4 must be passed so that
    it has four CPU cores, like the hardware.

  There is also evidently from the code in the kernel a
  Cortex-A9 core tile for the EB, and this is modeled in
  arm-realview-eb-a9mp.dts based on the kernel boardfile.
  I have not found a user guide for this EB core tile on
  the ARM website and it seems uncommon. It is however
  included for completeness.

Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Peter Maydell <peter.maydell at linaro.org>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Switch to one compatible string for the eb11mp GIC variant.
- Switch the syscon compatible strings around for 11MP RevB
  vs RevC a.k.a. "plain EB".
- Switch to "arm,pl390" for the "ordinary" GIC rather than gic-400
---
 arch/arm/boot/dts/Makefile                      |   6 +-
 arch/arm/boot/dts/arm-realview-eb-11mp-revb.dts |  93 +++++
 arch/arm/boot/dts/arm-realview-eb-11mp.dts      |  74 ++++
 arch/arm/boot/dts/arm-realview-eb-a9mp.dts      |  70 ++++
 arch/arm/boot/dts/arm-realview-eb-mp.dtsi       | 225 ++++++++++++
 arch/arm/boot/dts/arm-realview-eb.dts           | 166 +++++++++
 arch/arm/boot/dts/arm-realview-eb.dtsi          | 453 ++++++++++++++++++++++++
 7 files changed, 1086 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/arm-realview-eb-11mp-revb.dts
 create mode 100644 arch/arm/boot/dts/arm-realview-eb-11mp.dts
 create mode 100644 arch/arm/boot/dts/arm-realview-eb-a9mp.dts
 create mode 100644 arch/arm/boot/dts/arm-realview-eb-mp.dtsi
 create mode 100644 arch/arm/boot/dts/arm-realview-eb.dts
 create mode 100644 arch/arm/boot/dts/arm-realview-eb.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 76baaa51080c..39deb1741465 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -533,7 +533,11 @@ dtb-$(CONFIG_ARCH_QCOM) += \
 	qcom-msm8974-sony-xperia-honami.dtb
 dtb-$(CONFIG_ARCH_REALVIEW) += \
 	arm-realview-pb1176.dtb \
-	arm-realview-pb11mp.dtb
+	arm-realview-pb11mp.dtb \
+	arm-realview-eb.dtb \
+	arm-realview-eb-11mp.dtb \
+	arm-realview-eb-11mp-revb.dtb \
+	arm-realview-eb-a9mp.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3036-evb.dtb \
 	rk3036-kylin.dtb \
diff --git a/arch/arm/boot/dts/arm-realview-eb-11mp-revb.dts b/arch/arm/boot/dts/arm-realview-eb-11mp-revb.dts
new file mode 100644
index 000000000000..3a1d72e261aa
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-eb-11mp-revb.dts
@@ -0,0 +1,93 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "arm-realview-eb-11mp.dts"
+
+/ {
+	model = "ARM RealView EB ARM11MPCore Revision B";
+};
+
+/*
+ * The revision B has a distinctly different layout of the syscon, so
+ * append a specific compatible-string.
+ */
+&syscon {
+	compatible = "arm,realview-eb11mp-revb-syscon", "arm,realview-eb-syscon", "syscon", "simple-mfd";
+};
+
+&intc {
+	reg = <0x10101000 0x1000>,
+	      <0x10100100 0x100>;
+};
+
+&L2 {
+	reg = <0x10102000 0x1000>;
+};
+
+&scu {
+	reg = <0x10100000 0x100>;
+};
+
+&twd_timer {
+	reg = <0x10100600 0x20>;
+};
+
+&twd_wdog {
+	reg = <0x10100620 0x20>;
+};
+
+/*
+ * On revision B, we cannot reach the secondary interrupt
+ * controller, as a result, some peripherals that are dependent
+ * on their IRQ cannot be reached, so disable them.
+ */
+&intc_second {
+	status = "disabled";
+};
+
+&gpio0 {
+	status = "disabled";
+};
+
+&gpio1 {
+	status = "disabled";
+};
+
+&gpio2 {
+	status = "disabled";
+};
+
+&serial2 {
+	status = "disabled";
+};
+
+&serial3 {
+	status = "disabled";
+};
+
+&ssp {
+	status = "disabled";
+};
+
+&wdog {
+	status = "disabled";
+};
diff --git a/arch/arm/boot/dts/arm-realview-eb-11mp.dts b/arch/arm/boot/dts/arm-realview-eb-11mp.dts
new file mode 100644
index 000000000000..f2a2ffede0b0
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-eb-11mp.dts
@@ -0,0 +1,74 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "arm-realview-eb-mp.dtsi"
+
+/ {
+	model = "ARM RealView EB ARM11MPCore";
+	arm,hbi = <0x146>;
+
+	/*
+	 * This is the ARM11 MPCore tile (HBI-0146) used with the RealView EB.
+	 * Reference: ARM DUI 0318F
+	 *
+	 * To run this machine with QEMU, specify the following:
+	 * qemu-system-arm -M realview-eb-mpcore -smp cpus=4
+	 */
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		enable-method = "arm,realview-smp";
+
+		MP11_0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,arm11mpcore";
+			reg = <0>;
+			next-level-cache = <&L2>;
+		};
+
+		MP11_1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,arm11mpcore";
+			reg = <1>;
+			next-level-cache = <&L2>;
+		};
+
+		MP11_2: cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,arm11mpcore";
+			reg = <2>;
+			next-level-cache = <&L2>;
+		};
+
+		MP11_3: cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,arm11mpcore";
+			reg = <3>;
+			next-level-cache = <&L2>;
+		};
+	};
+};
+
+&pmu {
+	interrupt-affinity = <&MP11_0>, <&MP11_1>, <&MP11_2>, <&MP11_3>;
+};
diff --git a/arch/arm/boot/dts/arm-realview-eb-a9mp.dts b/arch/arm/boot/dts/arm-realview-eb-a9mp.dts
new file mode 100644
index 000000000000..967684b3636c
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-eb-a9mp.dts
@@ -0,0 +1,70 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "arm-realview-eb-mp.dtsi"
+
+/ {
+	model = "ARM RealView EB Cortex A9 MPCore";
+
+	/*
+	 * This is the Cortex A9 MPCore tile used with the
+	 * RealView EB.
+	 */
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		enable-method = "arm,realview-smp";
+
+		A9_0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0>;
+			next-level-cache = <&L2>;
+		};
+
+		A9_1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <1>;
+			next-level-cache = <&L2>;
+		};
+
+		A9_2: cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <2>;
+			next-level-cache = <&L2>;
+		};
+
+		A9_3: cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <3>;
+			next-level-cache = <&L2>;
+		};
+	};
+};
+
+&pmu {
+	interrupt-affinity = <&A9_0>, <&A9_1>, <&A9_2>, <&A9_3>;
+};
diff --git a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
new file mode 100644
index 000000000000..7b8d90b7aeea
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
@@ -0,0 +1,225 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "arm-realview-eb.dtsi"
+
+/*
+ * This is the common include file for all MPCore variants of the
+ * Evaluation Baseboard, i.e. ARM11MPCore, ARM11MPCore Revision B
+ * and Cortex-A9 MPCore.
+ */
+/ {
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "arm,realview-eb-soc", "simple-bus";
+		regmap = <&syscon>;
+		ranges;
+
+		/* Primary interrupt controller in the test chip */
+		intc: interrupt-controller at 1f000100 {
+			compatible = "arm,eb11mp-gic";
+			#interrupt-cells = <3>;
+			#address-cells = <1>;
+			interrupt-controller;
+			reg = <0x1f001000 0x1000>,
+			      <0x1f000100 0x100>;
+		};
+
+		/* Secondary interrupt controller on the FPGA */
+		intc_second: interrupt-controller at 10040000 {
+			compatible = "arm,pl390";
+			#interrupt-cells = <3>;
+			#address-cells = <1>;
+			interrupt-controller;
+			reg = <0x10041000 0x1000>,
+			      <0x10040000 0x100>;
+			interrupt-parent = <&intc>;
+			interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		L2: l2-cache {
+			compatible = "arm,l220-cache";
+			reg = <0x1f002000 0x1000>;
+			interrupt-parent = <&intc>;
+			interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 30 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 31 IRQ_TYPE_LEVEL_HIGH>;
+			cache-unified;
+			cache-level = <2>;
+			/*
+			 * Override default cache size, sets and
+			 * associativity as these may be erroneously set
+			 * up by boot loader(s), probably for safety
+			 * since th outer sync operation can cause the
+			 * cache to hang unless disabled.
+			 */
+			cache-size = <1048576>; // 1MB
+			cache-sets = <4096>;
+			cache-line-size = <32>;
+			arm,shared-override;
+			arm,parity-enable;
+			arm,outer-sync-disable;
+		};
+
+		scu: scu at 1f000000 {
+			compatible = "arm,arm11mp-scu";
+			reg = <0x1f000000 0x100>;
+		};
+
+		twd_timer: timer at 1f000600 {
+			compatible = "arm,arm11mp-twd-timer";
+			reg = <0x1f000600 0x20>;
+			interrupt-parent = <&intc>;
+			interrupts = <1 13 0xf04>;
+		};
+
+		twd_wdog: watchdog at 1f000620 {
+			compatible = "arm,arm11mp-twd-wdt";
+			reg = <0x1f000620 0x20>;
+			interrupt-parent = <&intc>;
+			interrupts = <1 14 0xf04>;
+		};
+
+		/* PMU with one IRQ line per core */
+		pmu: pmu at 0 {
+			compatible = "arm,arm11mpcore-pmu";
+			interrupt-parent = <&intc>;
+			interrupts = <0 17 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 18 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 19 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 20 IRQ_TYPE_LEVEL_HIGH>;
+		};
+	};
+};
+
+/*
+ * This adapts all the peripherals to the interrupt routing
+ * to the GIC on the core tile.
+ */
+
+&ethernet {
+	interrupt-parent = <&intc>;
+	interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&usb {
+	interrupt-parent = <&intc>;
+	interrupts = <0 3 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&aaci {
+	interrupt-parent = <&intc>;
+	interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&mmc {
+	interrupt-parent = <&intc>;
+	interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>,
+			<0 15 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&kmi0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&kmi1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&charlcd {
+	interrupt-parent = <&intc>;
+	interrupts = <0  IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer01 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 1 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer23 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&rtc {
+	interrupt-parent = <&intc>;
+	interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+/*
+ * On revision A, these peripherals does not have their IRQ lines
+ * routed to the core tile, but they can be reached on the secondary
+ * GIC.
+ */
+&gpio0 {
+	interrupt-parent = <&intc_second>;
+	interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio1 {
+	interrupt-parent = <&intc_second>;
+	interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio2 {
+	interrupt-parent = <&intc_second>;
+	interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial2 {
+	interrupt-parent = <&intc_second>;
+	interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
+	status = "okay";
+};
+
+&serial3 {
+	interrupt-parent = <&intc_second>;
+	interrupts = <0 15 IRQ_TYPE_LEVEL_HIGH>;
+	status = "okay";
+};
+
+&ssp {
+	interrupt-parent = <&intc_second>;
+	interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+	status = "okay";
+};
+
+&wdog {
+	interrupt-parent = <&intc_second>;
+	interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>;
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/arm-realview-eb.dts b/arch/arm/boot/dts/arm-realview-eb.dts
new file mode 100644
index 000000000000..59cc032598b9
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-eb.dts
@@ -0,0 +1,166 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "arm-realview-eb.dtsi"
+
+/ {
+	model = "ARM RealView EB";
+	compatible = "arm,realview-eb";
+	arm,hbi = <0x140>;
+
+	/*
+	 * This is the core tile with the CPU and GIC etc for the
+	 * ARM926EJ-S, ARM1136, ARM1176 that does not have L2 cache
+	 * or PMU.
+	 *
+	 * To run this machine with QEMU, specify the following:
+	 * qemu-system-arm -M realview-eb
+	 * Unless specified, QEMU will emulate an ARM926EJ-S core tile.
+	 * Switches -cpu arm1136 or -cpu arm1176 emulates the other
+	 * core tiles.
+	 */
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "arm,realview-eb-soc", "simple-bus";
+		regmap = <&syscon>;
+		ranges;
+
+		intc: interrupt-controller at 10040000 {
+			compatible = "arm,pl390";
+			#interrupt-cells = <3>;
+			#address-cells = <1>;
+			interrupt-controller;
+			reg = <0x10041000 0x1000>,
+			      <0x10040000 0x100>;
+		};
+	};
+};
+
+/*
+ * This adapts all the peripherals to the interrupt routing
+ * to the GIC on the core tile.
+ */
+
+&ethernet {
+	interrupt-parent = <&intc>;
+	interrupts = <0 28 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&usb {
+	interrupt-parent = <&intc>;
+	interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&aaci {
+	interrupt-parent = <&intc>;
+	interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&mmc {
+	interrupt-parent = <&intc>;
+	interrupts = <0 17 IRQ_TYPE_LEVEL_HIGH>,
+			<0 18 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&kmi0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&kmi1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&charlcd {
+	interrupt-parent = <&intc>;
+	interrupts = <0 22 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 12 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 13 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial2 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial3 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 15 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&ssp {
+	interrupt-parent = <&intc>;
+	interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&wdog {
+	interrupt-parent = <&intc>;
+	interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer01 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer23 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio2 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&rtc {
+	interrupt-parent = <&intc>;
+	interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&clcd {
+	interrupt-parent = <&intc>;
+	interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
+};
diff --git a/arch/arm/boot/dts/arm-realview-eb.dtsi b/arch/arm/boot/dts/arm-realview-eb.dtsi
new file mode 100644
index 000000000000..1c6a040218e3
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-eb.dtsi
@@ -0,0 +1,453 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "skeleton.dtsi"
+
+/ {
+	compatible = "arm,realview-eb";
+
+	chosen { };
+
+	aliases {
+		serial0 = &serial0;
+		serial1 = &serial1;
+		serial2 = &serial2;
+		serial3 = &serial3;
+		i2c0 = &i2c;
+	};
+
+	memory {
+		/* 128 MiB memory @ 0x0 */
+		reg = <0x00000000 0x08000000>;
+	};
+
+	/* The voltage to the MMC card is hardwired at 3.3V */
+	vmmc: fixedregulator at 0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vmmc";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+        };
+
+	veth: fixedregulator at 0 {
+		compatible = "regulator-fixed";
+		regulator-name = "veth";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+	};
+
+	xtal24mhz: xtal24mhz at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <24000000>;
+	};
+
+	timclk: timclk at 1M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <24>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	mclk: mclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	kmiclk: kmiclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	sspclk: sspclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	uartclk: uartclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	wdogclk: wdogclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	/* FIXME: this actually hangs off the PLL clocks */
+	pclk: pclk at 0 {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <0>;
+	};
+
+	flash0 at 40000000 {
+		/* 2 * 32MiB NOR Flash memory */
+		compatible = "arm,versatile-flash", "cfi-flash";
+		reg = <0x40000000 0x04000000>;
+		bank-width = <4>;
+	};
+
+	flash1 at 44000000 {
+		/* 2 * 32MiB NOR Flash memory */
+		compatible = "arm,versatile-flash", "cfi-flash";
+		reg = <0x44000000 0x04000000>;
+		bank-width = <4>;
+	};
+
+	/* SMSC 9118 ethernet with PHY and EEPROM */
+	ethernet: ethernet at 4e000000 {
+		compatible = "smsc,lan9118", "smsc,lan9115";
+		reg = <0x4e000000 0x10000>;
+		phy-mode = "mii";
+		reg-io-width = <4>;
+		smsc,irq-active-high;
+		smsc,irq-push-pull;
+		vdd33a-supply = <&veth>;
+		vddvario-supply = <&veth>;
+	};
+
+	usb: usb at 4f000000 {
+		compatible = "nxp,usb-isp1761";
+		reg = <0x4f000000 0x20000>;
+		port1-otg;
+	};
+
+	/* These peripherals are inside the FPGA */
+	fpga {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		ranges;
+
+		syscon: syscon at 10000000 {
+			compatible = "arm,realview-eb-syscon", "syscon", "simple-mfd";
+			reg = <0x10000000 0x1000>;
+
+			led at 08.0 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x01>;
+				label = "versatile:0";
+				linux,default-trigger = "heartbeat";
+				default-state = "on";
+			};
+			led at 08.1 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x02>;
+				label = "versatile:1";
+				linux,default-trigger = "mmc0";
+				default-state = "off";
+			};
+			led at 08.2 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x04>;
+				label = "versatile:2";
+				linux,default-trigger = "cpu0";
+				default-state = "off";
+			};
+			led at 08.3 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x08>;
+				label = "versatile:3";
+				default-state = "off";
+			};
+			led at 08.4 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x10>;
+				label = "versatile:4";
+				default-state = "off";
+			};
+			led at 08.5 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x20>;
+				label = "versatile:5";
+				default-state = "off";
+			};
+			led at 08.6 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x40>;
+				label = "versatile:6";
+				default-state = "off";
+			};
+			led at 08.7 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x80>;
+				label = "versatile:7";
+				default-state = "off";
+			};
+			oscclk0: osc0 at 0c {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x0C>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk1: osc1 at 10 {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x10>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk2: osc2 at 14 {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x14>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk3: osc3 at 18 {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x18>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk4: osc4 at 1c {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x1c>;
+				clocks = <&xtal24mhz>;
+			};
+		};
+
+		i2c: i2c at 10002000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "arm,versatile-i2c";
+			reg = <0x10002000 0x1000>;
+
+			rtc at 68 {
+				compatible = "dallas,ds1338";
+				reg = <0x68>;
+			};
+		};
+
+		aaci: aaci at 10004000 {
+			compatible = "arm,pl041", "arm,primecell";
+			reg = <0x10004000 0x1000>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		mmc: mmcsd at 10005000 {
+			compatible = "arm,pl18x", "arm,primecell";
+			reg = <0x10005000 0x1000>;
+
+			/* Due to frequent FIFO overruns, use just 500 kHz */
+			max-frequency = <500000>;
+			bus-width = <4>;
+			cap-sd-highspeed;
+			cap-mmc-highspeed;
+			clocks = <&mclk>, <&pclk>;
+			clock-names = "mclk", "apb_pclk";
+			vmmc-supply = <&vmmc>;
+			cd-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
+			wp-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
+		};
+
+		kmi0: kmi at 10006000 {
+			compatible = "arm,pl050", "arm,primecell";
+			reg = <0x10006000 0x1000>;
+			clocks = <&kmiclk>, <&pclk>;
+			clock-names = "KMIREFCLK", "apb_pclk";
+		};
+
+		kmi1: kmi at 10007000 {
+			compatible = "arm,pl050", "arm,primecell";
+			reg = <0x10007000 0x1000>;
+			clocks = <&kmiclk>, <&pclk>;
+			clock-names = "KMIREFCLK", "apb_pclk";
+		};
+
+		charlcd: fpga_charlcd: charlcd at 10008000 {
+			compatible = "arm,versatile-lcd";
+			reg = <0x10008000 0x1000>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		serial0: serial at 10009000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x10009000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+		};
+
+		serial1: serial at 1000a000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x1000a000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+		};
+
+		serial2: serial at 1000b000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x1000b000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+		};
+
+		serial3: serial at 1000c000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x1000c000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+		};
+
+		ssp: ssp at 1000d000 {
+			compatible = "arm,pl022", "arm,primecell";
+			reg = <0x1000d000 0x1000>;
+			clocks = <&sspclk>, <&pclk>;
+			clock-names = "SSPCLK", "apb_pclk";
+		};
+
+		wdog: watchdog at 10010000 {
+			compatible = "arm,sp805", "arm,primecell";
+			reg = <0x10010000 0x1000>;
+			clocks = <&wdogclk>, <&pclk>;
+			clock-names = "wdogclk", "apb_pclk";
+			status = "disabled";
+		};
+
+		timer01: timer at 10011000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x10011000 0x1000>;
+			clocks = <&timclk>, <&timclk>, <&pclk>;
+			clock-names = "timer1", "timer2", "apb_pclk";
+		};
+
+		timer23: timer at 10012000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x10012000 0x1000>;
+			clocks = <&timclk>, <&timclk>, <&pclk>;
+			clock-names = "timer1", "timer2", "apb_pclk";
+		};
+
+		gpio0: gpio at 10013000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x10013000 0x1000>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio1: gpio at 10014000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x10014000 0x1000>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio2: gpio at 10015000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x10015000 0x1000>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		rtc: rtc at 10017000 {
+			compatible = "arm,pl031", "arm,primecell";
+			reg = <0x10017000 0x1000>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		clcd: clcd at 10020000 {
+			compatible = "arm,pl111", "arm,primecell";
+			reg = <0x10020000 0x1000>;
+			interrupt-names = "combined";
+			clocks = <&oscclk0>, <&pclk>;
+			clock-names = "clcdclk", "apb_pclk";
+
+			port {
+				clcd_pads: endpoint {
+					remote-endpoint = <&clcd_panel>;
+					arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+				};
+			};
+
+			panel {
+				compatible = "panel-dpi";
+
+				port {
+					clcd_panel: endpoint {
+						remote-endpoint = <&clcd_pads>;
+					};
+				};
+
+				/* Standard 640x480 VGA timings */
+				panel-timing {
+					clock-frequency = <25175000>;
+					hactive = <640>;
+					hback-porch = <48>;
+					hfront-porch = <16>;
+					hsync-len = <96>;
+					vactive = <480>;
+					vback-porch = <33>;
+					vfront-porch = <10>;
+					vsync-len = <2>;
+				};
+			};
+		};
+	};
+};
-- 
2.4.3



From ard.biesheuvel at linaro.org  Mon Feb 22 06:02:07 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 15:02:07 +0100
Subject: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB
 mappings
In-Reply-To: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456149728-16706-2-git-send-email-ard.biesheuvel@linaro.org>

Currently, the memremap code serves MEMREMAP_WB mappings directly from
the kernel direct mapping, unless the region is in high memory, in which
case it falls back to using ioremap_cache(). However, the semantics of
ioremap_cache() are not unambiguously defined, and on ARM, it will
actually result in a mapping type that differs from the attributes used
for the linear mapping, and for this reason, the ioremap_cache() call
fails if the region is part of the memory managed by the kernel.

So instead, implement an optional hook 'arch_memremap_wb' whose default
implementation calls ioremap_cache() as before, but which can be
overridden by the architecture to do what is appropriate for it.

Cc: Dan Williams <dan.j.williams at intel.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 kernel/memremap.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/kernel/memremap.c b/kernel/memremap.c
index 7a1b5c3ef14e..77c41648ba16 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -27,6 +27,13 @@ __weak void __iomem *ioremap_cache(resource_size_t offset, unsigned long size)
 }
 #endif
 
+#ifndef arch_memremap_wb
+static void *arch_memremap_wb(resource_size_t offset, unsigned long size)
+{
+	return (__force void *)ioremap_cache(offset, size);
+}
+#endif
+
 static void *try_ram_remap(resource_size_t offset, size_t size)
 {
 	struct page *page = pfn_to_page(offset >> PAGE_SHIFT);
@@ -34,7 +41,7 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
 	/* In the simple case just return the existing linear address */
 	if (!PageHighMem(page))
 		return __va(offset);
-	return NULL; /* fallback to ioremap_cache */
+	return arch_memremap_wb(offset, size);
 }
 
 /**
@@ -80,8 +87,6 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
 		 */
 		if (is_ram == REGION_INTERSECTS)
 			addr = try_ram_remap(offset, size);
-		if (!addr)
-			addr = ioremap_cache(offset, size);
 	}
 
 	/*
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 06:02:08 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 15:02:08 +0100
Subject: [RFC PATCH 2/2] ARM: memremap: implement arch_memremap_wb()
In-Reply-To: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456149728-16706-3-git-send-email-ard.biesheuvel@linaro.org>

The generic memremap() falls back to using ioremap_cache() to create
MEMREMAP_WB mappings if the requested region is not already covered
by the linear mapping, unless the architecture provides an implementation
of arch_memremap_wb().

Since ioremap_cache() is not appropriate on ARM to map memory with the
same attributes used for the linear mapping, implement arch_memremap_wb()
which does exactly that. Also, relax the WARN() check to allow MT_MEMORY_RW
mappings of pfn_valid() pages.

Cc: Russell King <rmk+kernel at arm.linux.org.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm/include/asm/io.h |  3 +++
 arch/arm/mm/ioremap.c     | 11 +++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 485982084fe9..7456638e6b3a 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -402,6 +402,9 @@ void __iomem *ioremap_wc(resource_size_t res_cookie, size_t size);
 void iounmap(volatile void __iomem *iomem_cookie);
 #define iounmap iounmap
 
+void *arch_memremap_wb(phys_addr_t phys_addr, size_t size);
+#define arch_memremap_wb arch_memremap_wb
+
 /*
  * io{read,write}{16,32}be() macros
  */
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index 66a978d05958..d3a2b028c614 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -297,9 +297,10 @@ static void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
 	}
 
 	/*
-	 * Don't allow RAM to be mapped - this causes problems with ARMv6+
+	 * Don't allow RAM to be mapped with mismatched attributes - this
+	 * causes problems with ARMv6+
 	 */
-	if (WARN_ON(pfn_valid(pfn)))
+	if (WARN_ON(pfn_valid(pfn) && mtype != MT_MEMORY_RW))
 		return NULL;
 
 	area = get_vm_area_caller(size, VM_IOREMAP, caller);
@@ -414,6 +415,12 @@ __arm_ioremap_exec(phys_addr_t phys_addr, size_t size, bool cached)
 			__builtin_return_address(0));
 }
 
+void *arch_memremap_wb(phys_addr_t phys_addr, size_t size)
+{
+	return __arm_ioremap_caller(phys_addr, size, MT_MEMORY_RW,
+			__builtin_return_address(0));
+}
+
 void __iounmap(volatile void __iomem *io_addr)
 {
 	void *addr = (void *)(PAGE_MASK & (unsigned long)io_addr);
-- 
2.5.0



From Suzuki.Poulose at arm.com  Mon Feb 22 06:03:12 2016
From: Suzuki.Poulose at arm.com (Suzuki K. Poulose)
Date: Mon, 22 Feb 2016 14:03:12 +0000
Subject: [PATCH 0/6] Support for systems without AArch32 state
In-Reply-To: <1453980737-6126-1-git-send-email-suzuki.poulose@arm.com>
References: <1453980737-6126-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <56CB1520.8020907@arm.com>

On 28/01/16 11:32, Suzuki K Poulose wrote:
> This series add checks to make sure that the AArch32 state is
> supported before we process the 32bit ID registers. Also
> checks the same for COMPAT binary execution.

Yuri,

Could you please give this series a spin on your hardware ?
I don't have access to system where I can test this.

Thanks
Suzuki



From andrew at lunn.ch  Mon Feb 22 06:16:17 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 22 Feb 2016 15:16:17 +0100
Subject: [PATCH 2/3] clk: mvebu: add AP806 core clock driver
In-Reply-To: <20160222091423.4756a579@free-electrons.com>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455521698-7905-3-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160222025357.GE15973@rob-hp-laptop>
 <20160222091423.4756a579@free-electrons.com>
Message-ID: <20160222141617.GA14970@lunn.ch>

> Such information will come later, and we can rework the drivers and DT
> bindings accordingly. Those DT bindings cannot be stable, as the
> platform is under heavy development and we'll probably discover some
> issues down the road.

Hi Thomas

Maybe add a big fat warning that the bindings are unstable, and the DT
blob must be kept in sync with the kernel?

     Andrew


From ludovic.desroches at atmel.com  Mon Feb 22 06:18:55 2016
From: ludovic.desroches at atmel.com (Ludovic Desroches)
Date: Mon, 22 Feb 2016 15:18:55 +0100
Subject: [PATCH] tty/serial: at91: fix bad offset for UART timeout register
Message-ID: <1456150735-11635-1-git-send-email-ludovic.desroches@atmel.com>

With SAMA5D2, the UART has hw timeout but the offset of the register to
define this value is not the same as the one for USART.
When using the new UART, the value of this register was 0 so we never
get timeout irqs. It involves that when using DMA, we were stuck until
the execution of the dma callback which happens when a buffer is full
(so after receiving 2048 bytes).

Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
---
 drivers/tty/serial/atmel_serial.c | 19 +++++++++++++------
 include/linux/atmel_serial.h      |  3 ++-
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index b30c93f..4b6f04a 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -159,6 +159,7 @@ struct atmel_uart_port {
 	u32			rts_high;
 	u32			rts_low;
 	bool			ms_irq_enabled;
+	u32			rtor;	/* address of receiver timeout register if it exists */
 	bool			has_hw_timer;
 	struct timer_list	uart_timer;
 
@@ -1718,12 +1719,16 @@ static void atmel_get_ip_name(struct uart_port *port)
 
 	atmel_port->has_hw_timer = false;
 
-	if (name == usart || name == new_uart) {
-		dev_dbg(port->dev, "Usart or uart with hw timer\n");
+	if (name == new_uart) {
+		dev_dbg(port->dev, "Uart with hw timer");
 		atmel_port->has_hw_timer = true;
+		atmel_port->rtor = ATMEL_UA_RTOR;
+	} else if (name == usart) {
+		dev_dbg(port->dev, "Usart\n");
+		atmel_port->has_hw_timer = true;
+		atmel_port->rtor = ATMEL_US_RTOR;
 	} else if (name == dbgu_uart) {
 		dev_dbg(port->dev, "Dbgu or uart without hw timer\n");
-		atmel_port->has_hw_timer = false;
 	} else {
 		/* fallback for older SoCs: use version field */
 		version = atmel_uart_readl(port, ATMEL_US_VERSION);
@@ -1732,11 +1737,11 @@ static void atmel_get_ip_name(struct uart_port *port)
 		case 0x10213:
 			dev_dbg(port->dev, "This version is usart\n");
 			atmel_port->has_hw_timer = true;
+			atmel_port->rtor = ATMEL_US_RTOR;
 			break;
 		case 0x203:
 		case 0x10202:
 			dev_dbg(port->dev, "This version is uart\n");
-			atmel_port->has_hw_timer = false;
 			break;
 		default:
 			dev_err(port->dev, "Not supported ip name nor version, set to uart\n");
@@ -1841,7 +1846,8 @@ static int atmel_startup(struct uart_port *port)
 					jiffies + uart_poll_timeout(port));
 		/* set USART timeout */
 		} else {
-			atmel_uart_writel(port, ATMEL_US_RTOR, PDC_RX_TIMEOUT);
+			atmel_uart_writel(port, atmel_port->rtor,
+					  PDC_RX_TIMEOUT);
 			atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_STTTO);
 
 			atmel_uart_writel(port, ATMEL_US_IER,
@@ -1856,7 +1862,8 @@ static int atmel_startup(struct uart_port *port)
 					jiffies + uart_poll_timeout(port));
 		/* set USART timeout */
 		} else {
-			atmel_uart_writel(port, ATMEL_US_RTOR, PDC_RX_TIMEOUT);
+			atmel_uart_writel(port, atmel_port->rtor,
+					  PDC_RX_TIMEOUT);
 			atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_STTTO);
 
 			atmel_uart_writel(port, ATMEL_US_IER,
diff --git a/include/linux/atmel_serial.h b/include/linux/atmel_serial.h
index ee696d7..5a4d664 100644
--- a/include/linux/atmel_serial.h
+++ b/include/linux/atmel_serial.h
@@ -119,7 +119,8 @@
 #define ATMEL_US_BRGR		0x20	/* Baud Rate Generator Register */
 #define	ATMEL_US_CD		GENMASK(15, 0)	/* Clock Divider */
 
-#define ATMEL_US_RTOR		0x24	/* Receiver Time-out Register */
+#define ATMEL_US_RTOR		0x24	/* Receiver Time-out Register for USART */
+#define ATMEL_UA_RTOR		0x28	/* Receiver Time-out Register for UART */
 #define	ATMEL_US_TO		GENMASK(15, 0)	/* Time-out Value */
 
 #define ATMEL_US_TTGR		0x28	/* Transmitter Timeguard Register */
-- 
2.5.0



From ldewangan at nvidia.com  Mon Feb 22 06:07:49 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:37:49 +0530
Subject: [PATCH 00/61] gpio: Add and use devm_gpiochip_add_data()
Message-ID: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>

Add resource management APIs for gpiochip_add_data() and
gpiochip_remove() and use these APIs from different HW drivers.


This is based on discussion on patch to use the new APIs.
	gpio: Add devm_ apis for gpio_chip_add and remove

Laxman Dewangan (61):
  gpio: Add devm_ apis for gpiochip_add_data and gpiochip_remove
  gpio: Add resource management devm_gpio_chip_{add_data,remove}
  gpio: Add missing devm_gpio_ wrapper in devres.txt
  gpio: 74xx-mmio: Use devm_gpiochip_add_data() for gpio registration
  gpio: adnp: Use devm_gpiochip_add_data() for gpio registration
  gpio: adp5520: Use devm_gpiochip_add_data() for gpio registration
  gpio: adp5588: Use devm_gpiochip_add_data() for gpio registration
  gpio: amdpt: Use devm_gpiochip_add_data() for gpio registration
  gpio: arizona: Use devm_gpiochip_add_data() for gpio registration
  gpio: ath79: Use devm_gpiochip_add_data() for gpio registration
  gpio: bcm-kona: Use devm_gpiochip_add_data() for gpio registration
  gpio: clps711x: Use devm_gpiochip_add_data() for gpio registration
  gpio: crystalcove: Use devm_gpiochip_add_data() for gpio registration
  gpio: cs5535: Use devm_gpiochip_add_data() for gpio registration
  gpio: da9052: Use devm_gpiochip_add_data() for gpio registration
  gpio: da9055: Use devm_gpiochip_add_data() for gpio registration
  gpio: dln2: Use devm_gpiochip_add_data() for gpio registration
  gpio: ep93xx: Use devm_gpiochip_add_data() for gpio registration
  gpio: f7188x: Use devm_gpiochip_add_data() for gpio registration
  gpio: ge: Use devm_gpiochip_add_data() for gpio registration
  gpio: generic: Use devm_gpiochip_add_data() for gpio registration
  gpio: iop: Use devm_gpiochip_add_data() for gpio registration
  gpio: janz-ttl: Use devm_gpiochip_add_data() for gpio registration
  gpio: kempld: Use devm_gpiochip_add_data() for gpio registration
  gpio: lp3943: Use devm_gpiochip_add_data() for gpio registration
  gpio: lpc32xx: Use devm_gpiochip_add_data() for gpio registration
  gpio: lynxpoint: Use devm_gpiochip_add_data() for gpio registration
  gpio: mc9s08dz60: Use devm_gpiochip_add_data() for gpio registration
  gpio: moxart: Use devm_gpiochip_add_data() for gpio registration
  gpio: mvebu: Use devm_gpiochip_add_data() for gpio registration
  gpio: mxc: Use devm_gpiochip_add_data() for gpio registration
  gpio: octeon: Use devm_gpiochip_add_data() for gpio registration
  gpio: pca953x: Use devm_gpiochip_add_data() for gpio registration
  gpio: pcf857x: Use devm_gpiochip_add_data() for gpio registration
  gpio: palmas: Use devm_gpiochip_add_data() for gpio registration
  gpio: rc5t583: Use devm_gpiochip_add_data() for gpio registration
  gpio: rdc321x: Use devm_gpiochip_add_data() for gpio registration
  gpio: sch: Use devm_gpiochip_add_data() for gpio registration
  gpio: spear-spics: Use devm_gpiochip_add_data() for gpio registration
  gpio: sta2x11: Use devm_gpiochip_add_data() for gpio registration
  gpio: stp-xway: Use devm_gpiochip_add_data() for gpio registration
  gpio: sx150x: Use devm_gpiochip_add_data() for gpio registration
  gpio: syscon: Use devm_gpiochip_add_data() for gpio registration
  gpio: tb10x: Use devm_gpiochip_add_data() for gpio registration
  gpio: tc3589x: Use devm_gpiochip_add_data() for gpio registration
  gpio: tegra: Use devm_gpiochip_add_data() for gpio registration
  gpio: timberdale Use devm_gpiochip_add_data() for gpio registration
  gpio: tps6586x: Use devm_gpiochip_add_data() for gpio registration
  gpio: tps65910: Use devm_gpiochip_add_data() for gpio registration
  gpio: tps65912: Use devm_gpiochip_add_data() for gpio registration
  gpio: ts4800: Use devm_gpiochip_add_data() for gpio registration
  gpio: ts5500: Use devm_gpiochip_add_data() for gpio registration
  gpio: twl6040: Use devm_gpiochip_add_data() for gpio registration
  gpio: ucb1400: Use devm_gpiochip_add_data() for gpio registration
  gpio: viperboard: Use devm_gpiochip_add_data() for gpio registration
  gpio: vx855: Use devm_gpiochip_add_data() for gpio registration
  gpio: wm8350: Use devm_gpiochip_add_data() for gpio registration
  gpio: wm8350: Use devm_gpiochip_add_data() for gpio registration
  gpio: wm8994: Use devm_gpiochip_add_data() for gpio registration
  gpio: xgene-sb: Use devm_gpiochip_add_data() for gpio registration
  gpio: xgene: Use devm_gpiochip_add_data() for gpio registration

 Documentation/driver-model/devres.txt |  5 +++
 drivers/gpio/gpio-74xx-mmio.c         | 11 +-----
 drivers/gpio/gpio-adnp.c              | 11 +-----
 drivers/gpio/gpio-adp5520.c           | 13 +-----
 drivers/gpio/gpio-adp5588.c           |  4 +-
 drivers/gpio/gpio-amdpt.c             | 12 +-----
 drivers/gpio/gpio-arizona.c           | 12 +-----
 drivers/gpio/gpio-ath79.c             |  2 +-
 drivers/gpio/gpio-bcm-kona.c          |  2 +-
 drivers/gpio/gpio-clps711x.c          | 11 +-----
 drivers/gpio/gpio-crystalcove.c       |  9 +----
 drivers/gpio/gpio-cs5535.c            | 20 +++-------
 drivers/gpio/gpio-da9052.c            | 11 +-----
 drivers/gpio/gpio-da9055.c            | 16 +-------
 drivers/gpio/gpio-dln2.c              | 16 ++------
 drivers/gpio/gpio-ep93xx.c            |  2 +-
 drivers/gpio/gpio-f7188x.c            | 26 +-----------
 drivers/gpio/gpio-ge.c                |  2 +-
 drivers/gpio/gpio-generic.c           | 11 +-----
 drivers/gpio/gpio-iop.c               |  2 +-
 drivers/gpio/gpio-janz-ttl.c          | 12 +-----
 drivers/gpio/gpio-kempld.c            | 11 +-----
 drivers/gpio/gpio-lp3943.c            | 12 +-----
 drivers/gpio/gpio-lpc32xx.c           |  2 +-
 drivers/gpio/gpio-lynxpoint.c         |  4 +-
 drivers/gpio/gpio-mc9s08dz60.c        | 13 +-----
 drivers/gpio/gpio-moxart.c            |  2 +-
 drivers/gpio/gpio-mvebu.c             | 11 ++----
 drivers/gpio/gpio-mxc.c               |  6 +--
 drivers/gpio/gpio-octeon.c            | 10 +----
 drivers/gpio/gpio-palmas.c            | 12 +-----
 drivers/gpio/gpio-pca953x.c           |  4 +-
 drivers/gpio/gpio-pcf857x.c           | 10 ++---
 drivers/gpio/gpio-rc5t583.c           | 12 +-----
 drivers/gpio/gpio-rdc321x.c           | 13 +-----
 drivers/gpio/gpio-sch.c               | 11 +-----
 drivers/gpio/gpio-spear-spics.c       |  2 +-
 drivers/gpio/gpio-sta2x11.c           |  2 +-
 drivers/gpio/gpio-stp-xway.c          |  2 +-
 drivers/gpio/gpio-sx150x.c            | 18 +--------
 drivers/gpio/gpio-syscon.c            | 11 +-----
 drivers/gpio/gpio-tb10x.c             | 22 +++--------
 drivers/gpio/gpio-tc3589x.c           | 13 +-----
 drivers/gpio/gpio-tegra.c             |  2 +-
 drivers/gpio/gpio-timberdale.c        |  4 +-
 drivers/gpio/gpio-tps6586x.c          | 12 +-----
 drivers/gpio/gpio-tps65910.c          | 12 +-----
 drivers/gpio/gpio-tps65912.c          | 12 +-----
 drivers/gpio/gpio-ts4800.c            | 12 +-----
 drivers/gpio/gpio-ts5500.c            |  9 ++---
 drivers/gpio/gpio-twl6040.c           |  9 +----
 drivers/gpio/gpio-ucb1400.c           |  3 +-
 drivers/gpio/gpio-viperboard.c        | 24 ++----------
 drivers/gpio/gpio-vx855.c             | 12 +-----
 drivers/gpio/gpio-wm831x.c            | 12 +-----
 drivers/gpio/gpio-wm8350.c            | 12 +-----
 drivers/gpio/gpio-wm8994.c            | 17 ++------
 drivers/gpio/gpio-xgene-sb.c          |  3 +-
 drivers/gpio/gpio-xgene.c             | 11 +-----
 drivers/gpio/gpiolib.c                | 74 +++++++++++++++++++++++++++++++++++
 include/linux/gpio/driver.h           |  4 ++
 61 files changed, 180 insertions(+), 477 deletions(-)

-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:07:50 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:37:50 +0530
Subject: [PATCH 01/61] gpio: Add devm_ apis for gpiochip_add_data and
 gpiochip_remove
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-2-git-send-email-ldewangan@nvidia.com>

Add device managed APIs devm_gpiochip_add_data() and
devm_gpiochip_remove() for the APIs gpiochip_add_data()
and gpiochip_remove().

This helps in reducing code in error path and sometimes
removal of .remove callback for driver unbind.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpiolib.c      | 74 +++++++++++++++++++++++++++++++++++++++++++++
 include/linux/gpio/driver.h |  4 +++
 2 files changed, 78 insertions(+)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 5c1ba87..d9a40bc 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -462,6 +462,80 @@ void gpiochip_remove(struct gpio_chip *chip)
 }
 EXPORT_SYMBOL_GPL(gpiochip_remove);
 
+static void devm_gpio_chip_release(struct device *dev, void *res)
+{
+	struct gpio_chip *chip = *(struct gpio_chip **)res;
+
+	gpiochip_remove(chip);
+}
+
+static int devm_gpio_chip_match(struct device *dev, void *res, void *data)
+
+{
+	struct gpio_chip **r = res;
+
+	if (!r || !*r) {
+		WARN_ON(!r || !*r);
+		return 0;
+	}
+
+	return *r == data;
+}
+
+/**
+ * devm_gpiochip_add_data() - Resource manager piochip_add_data()
+ * @dev: the device pointer on which irq_chip belongs to.
+ * @chip: the chip to register, with chip->base initialized
+ * Context: potentially before irqs will work
+ *
+ * Returns a negative errno if the chip can't be registered, such as
+ * because the chip->base is invalid or already associated with a
+ * different chip.  Otherwise it returns zero as a success code.
+ *
+ * The gpio chip automatically be released when the device is unbound.
+ */
+int devm_gpiochip_add_data(struct device *dev, struct gpio_chip *chip,
+			   void *data)
+{
+	struct gpio_chip **ptr;
+	int ret;
+
+	ptr = devres_alloc(devm_gpio_chip_release, sizeof(*ptr),
+			     GFP_KERNEL);
+	if (!ptr)
+		return -ENOMEM;
+
+	ret = gpiochip_add_data(chip, data);
+	if (ret < 0) {
+		devres_free(ptr);
+		return ret;
+	}
+
+	*ptr = chip;
+	devres_add(dev, ptr);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(devm_gpiochip_add_data);
+
+/**
+ * devm_gpiochip_remove() - Resource manager of gpiochip_remove()
+ * @dev: device for which which resource was allocated
+ * @chip: the chip to remove
+ *
+ * A gpio_chip with any GPIOs still requested may not be removed.
+ */
+void devm_gpiochip_remove(struct device *dev, struct gpio_chip *chip)
+{
+	int ret;
+
+	ret = devres_release(dev, devm_gpio_chip_release,
+			     devm_gpio_chip_match, chip);
+	if (!ret)
+		WARN_ON(ret);
+}
+EXPORT_SYMBOL_GPL(devm_gpiochip_remove);
+
 /**
  * gpiochip_find() - iterator for locating a specific gpio_chip
  * @data: data to pass to match function
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 82fda48..d5d19cc 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -205,6 +205,10 @@ static inline int gpiochip_add(struct gpio_chip *chip)
 	return gpiochip_add_data(chip, NULL);
 }
 extern void gpiochip_remove(struct gpio_chip *chip);
+extern int devm_gpiochip_add_data(struct device *dev, struct gpio_chip *chip,
+				  void *data);
+extern void devm_gpiochip_remove(struct device *dev, struct gpio_chip *chip);
+
 extern struct gpio_chip *gpiochip_find(void *data,
 			      int (*match)(struct gpio_chip *chip, void *data));
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:07:51 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:37:51 +0530
Subject: [PATCH 02/61] gpio: Add resource management devm_gpio_chip_{add_data,
 remove}
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-3-git-send-email-ldewangan@nvidia.com>

Add devm wrappers for the gpiochip_add_data() and gpiochip_remove().

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 Documentation/driver-model/devres.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 831a536..8d8f944 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -252,6 +252,8 @@ GPIO
   devm_gpiod_get_index_optional()
   devm_gpiod_get_optional()
   devm_gpiod_put()
+  devm_gpiochip_add_data()
+  devm_gpiochip_remove()
 
 IIO
   devm_iio_device_alloc()
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:07:52 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:37:52 +0530
Subject: [PATCH 03/61] gpio: Add missing devm_gpio_ wrapper in devres.txt
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-4-git-send-email-ldewangan@nvidia.com>

Add following missing devm wrappers in file devrs.txt under
list of managed interfaces.
  devm_gpio_request()
  devm_gpio_request_one()
  devm_gpio_free()

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 Documentation/driver-model/devres.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 8d8f944..73b98df 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -254,6 +254,9 @@ GPIO
   devm_gpiod_put()
   devm_gpiochip_add_data()
   devm_gpiochip_remove()
+  devm_gpio_request()
+  devm_gpio_request_one()
+  devm_gpio_free()
 
 IIO
   devm_iio_device_alloc()
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:07:57 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:37:57 +0530
Subject: [PATCH 08/61] gpio: amdpt: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-9-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-amdpt.c | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/gpio/gpio-amdpt.c b/drivers/gpio/gpio-amdpt.c
index c248404..857eec5 100644
--- a/drivers/gpio/gpio-amdpt.c
+++ b/drivers/gpio/gpio-amdpt.c
@@ -212,7 +212,7 @@ static int pt_gpio_probe(struct platform_device *pdev)
 #if defined(CONFIG_OF_GPIO)
 	pt_gpio->gc.of_node          = pdev->dev.of_node;
 #endif
-	ret = gpiochip_add_data(&pt_gpio->gc, pt_gpio);
+	ret = devm_gpiochip_add_data(&pdev->dev, &pt_gpio->gc, pt_gpio);
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to register GPIO lib\n");
 		return ret;
@@ -228,15 +228,6 @@ static int pt_gpio_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int pt_gpio_remove(struct platform_device *pdev)
-{
-	struct pt_gpio_chip *pt_gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&pt_gpio->gc);
-
-	return 0;
-}
-
 static const struct acpi_device_id pt_gpio_acpi_match[] = {
 	{ "AMDF030", 0 },
 	{ },
@@ -249,7 +240,6 @@ static struct platform_driver pt_gpio_driver = {
 		.acpi_match_table = ACPI_PTR(pt_gpio_acpi_match),
 	},
 	.probe = pt_gpio_probe,
-	.remove = pt_gpio_remove,
 };
 
 module_platform_driver(pt_gpio_driver);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:07:58 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:37:58 +0530
Subject: [PATCH 09/61] gpio: arizona: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-10-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: patches at opensource.wolfsonmicro.com
---
 drivers/gpio/gpio-arizona.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-arizona.c b/drivers/gpio/gpio-arizona.c
index e910c1f..9913704 100644
--- a/drivers/gpio/gpio-arizona.c
+++ b/drivers/gpio/gpio-arizona.c
@@ -132,7 +132,8 @@ static int arizona_gpio_probe(struct platform_device *pdev)
 	else
 		arizona_gpio->gpio_chip.base = -1;
 
-	ret = gpiochip_add_data(&arizona_gpio->gpio_chip, arizona_gpio);
+	ret = devm_gpiochip_add_data(&pdev->dev, &arizona_gpio->gpio_chip,
+				     arizona_gpio);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Could not register gpiochip, %d\n",
 			ret);
@@ -147,18 +148,9 @@ err:
 	return ret;
 }
 
-static int arizona_gpio_remove(struct platform_device *pdev)
-{
-	struct arizona_gpio *arizona_gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&arizona_gpio->gpio_chip);
-	return 0;
-}
-
 static struct platform_driver arizona_gpio_driver = {
 	.driver.name	= "arizona-gpio",
 	.probe		= arizona_gpio_probe,
-	.remove		= arizona_gpio_remove,
 };
 
 module_platform_driver(arizona_gpio_driver);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:04 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:04 +0530
Subject: [PATCH 15/61] gpio: da9052: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-16-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-da9052.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-da9052.c b/drivers/gpio/gpio-da9052.c
index f9b3247..e29553b 100644
--- a/drivers/gpio/gpio-da9052.c
+++ b/drivers/gpio/gpio-da9052.c
@@ -214,7 +214,7 @@ static int da9052_gpio_probe(struct platform_device *pdev)
 	if (pdata && pdata->gpio_base)
 		gpio->gp.base = pdata->gpio_base;
 
-	ret = gpiochip_add_data(&gpio->gp, gpio);
+	ret = devm_gpiochip_add_data(&pdev->dev, &gpio->gp, gpio);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Could not register gpiochip, %d\n", ret);
 		return ret;
@@ -225,17 +225,8 @@ static int da9052_gpio_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int da9052_gpio_remove(struct platform_device *pdev)
-{
-	struct da9052_gpio *gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&gpio->gp);
-	return 0;
-}
-
 static struct platform_driver da9052_gpio_driver = {
 	.probe = da9052_gpio_probe,
-	.remove = da9052_gpio_remove,
 	.driver = {
 		.name	= "da9052-gpio",
 	},
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:07:54 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:37:54 +0530
Subject: [PATCH 05/61] gpio: adnp: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-6-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
call for gpiochip_remove() from error path.

Also remove the need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Alexandre Courbot <gnurou at gmail.com>
---
 drivers/gpio/gpio-adnp.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-adnp.c b/drivers/gpio/gpio-adnp.c
index fb5b47b..8ff7b0d 100644
--- a/drivers/gpio/gpio-adnp.c
+++ b/drivers/gpio/gpio-adnp.c
@@ -265,7 +265,7 @@ static int adnp_gpio_setup(struct adnp *adnp, unsigned int num_gpios)
 	chip->of_node = chip->parent->of_node;
 	chip->owner = THIS_MODULE;
 
-	err = gpiochip_add_data(chip, adnp);
+	err = devm_gpiochip_add_data(&adnp->client->dev, chip, adnp);
 	if (err)
 		return err;
 
@@ -520,14 +520,6 @@ static int adnp_i2c_probe(struct i2c_client *client,
 	return 0;
 }
 
-static int adnp_i2c_remove(struct i2c_client *client)
-{
-	struct adnp *adnp = i2c_get_clientdata(client);
-
-	gpiochip_remove(&adnp->gpio);
-	return 0;
-}
-
 static const struct i2c_device_id adnp_i2c_id[] = {
 	{ "gpio-adnp" },
 	{ },
@@ -546,7 +538,6 @@ static struct i2c_driver adnp_i2c_driver = {
 		.of_match_table = adnp_of_match,
 	},
 	.probe = adnp_i2c_probe,
-	.remove = adnp_i2c_remove,
 	.id_table = adnp_i2c_id,
 };
 module_i2c_driver(adnp_i2c_driver);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:07:55 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:37:55 +0530
Subject: [PATCH 06/61] gpio: adp5520: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-7-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
call for gpiochip_remove() from error path.

Also remove the need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Michael Hennerich <michael.hennerich at analog.com>
---
 drivers/gpio/gpio-adp5520.c | 13 +------------
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpio/gpio-adp5520.c b/drivers/gpio/gpio-adp5520.c
index 4fa7ff1..abf1996 100644
--- a/drivers/gpio/gpio-adp5520.c
+++ b/drivers/gpio/gpio-adp5520.c
@@ -153,7 +153,7 @@ static int adp5520_gpio_probe(struct platform_device *pdev)
 		goto err;
 	}
 
-	ret = gpiochip_add_data(&dev->gpio_chip, dev);
+	ret = devm_gpiochip_add_data(&pdev->dev, &dev->gpio_chip, dev);
 	if (ret)
 		goto err;
 
@@ -164,22 +164,11 @@ err:
 	return ret;
 }
 
-static int adp5520_gpio_remove(struct platform_device *pdev)
-{
-	struct adp5520_gpio *dev;
-
-	dev = platform_get_drvdata(pdev);
-	gpiochip_remove(&dev->gpio_chip);
-
-	return 0;
-}
-
 static struct platform_driver adp5520_gpio_driver = {
 	.driver	= {
 		.name	= "adp5520-gpio",
 	},
 	.probe		= adp5520_gpio_probe,
-	.remove		= adp5520_gpio_remove,
 };
 
 module_platform_driver(adp5520_gpio_driver);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:07:56 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:37:56 +0530
Subject: [PATCH 07/61] gpio: adp5588: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-8-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
call for gpiochip_remove() from remove callback.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Michael Hennerich <michael.hennerich at analog.com>
---
 drivers/gpio/gpio-adp5588.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-adp5588.c b/drivers/gpio/gpio-adp5588.c
index 19a0eba..c0f718b 100644
--- a/drivers/gpio/gpio-adp5588.c
+++ b/drivers/gpio/gpio-adp5588.c
@@ -414,7 +414,7 @@ static int adp5588_gpio_probe(struct i2c_client *client,
 		}
 	}
 
-	ret = gpiochip_add_data(&dev->gpio_chip, dev);
+	ret = devm_gpiochip_add_data(&client->dev, &dev->gpio_chip, dev);
 	if (ret)
 		goto err_irq;
 
@@ -457,8 +457,6 @@ static int adp5588_gpio_remove(struct i2c_client *client)
 	if (dev->irq_base)
 		free_irq(dev->client->irq, dev);
 
-	gpiochip_remove(&dev->gpio_chip);
-
 	return 0;
 }
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:07:59 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:37:59 +0530
Subject: [PATCH 10/61] gpio: ath79: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-11-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Alban Bedel <albeu at free.fr>
---
 drivers/gpio/gpio-ath79.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-ath79.c b/drivers/gpio/gpio-ath79.c
index d13dd13..a6aad59 100644
--- a/drivers/gpio/gpio-ath79.c
+++ b/drivers/gpio/gpio-ath79.c
@@ -182,7 +182,7 @@ static int ath79_gpio_probe(struct platform_device *pdev)
 		ctrl->chip.direction_output = ar934x_gpio_direction_output;
 	}
 
-	err = gpiochip_add_data(&ctrl->chip, ctrl);
+	err = devm_gpiochip_add_data(&pdev->dev, &ctrl->chip, ctrl);
 	if (err) {
 		dev_err(&pdev->dev,
 			"cannot add AR71xx GPIO chip, error=%d", err);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:00 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:00 +0530
Subject: [PATCH 11/61] gpio: bcm-kona: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-12-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Ray Jui <rjui at broadcom.com>
---
 drivers/gpio/gpio-bcm-kona.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-bcm-kona.c b/drivers/gpio/gpio-bcm-kona.c
index b6c5abe..2fd38d5 100644
--- a/drivers/gpio/gpio-bcm-kona.c
+++ b/drivers/gpio/gpio-bcm-kona.c
@@ -630,7 +630,7 @@ static int bcm_kona_gpio_probe(struct platform_device *pdev)
 
 	bcm_kona_gpio_reset(kona_gpio);
 
-	ret = gpiochip_add_data(chip, kona_gpio);
+	ret = devm_gpiochip_add_data(dev, chip, kona_gpio);
 	if (ret < 0) {
 		dev_err(dev, "Couldn't add GPIO chip -- %d\n", ret);
 		goto err_irq_domain;
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:01 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:01 +0530
Subject: [PATCH 12/61] gpio: clps711x: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-13-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-clps711x.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-clps711x.c b/drivers/gpio/gpio-clps711x.c
index c84f955..5a69025 100644
--- a/drivers/gpio/gpio-clps711x.c
+++ b/drivers/gpio/gpio-clps711x.c
@@ -67,15 +67,7 @@ static int clps711x_gpio_probe(struct platform_device *pdev)
 	gc->owner = THIS_MODULE;
 	platform_set_drvdata(pdev, gc);
 
-	return gpiochip_add_data(gc, NULL);
-}
-
-static int clps711x_gpio_remove(struct platform_device *pdev)
-{
-	struct gpio_chip *gc = platform_get_drvdata(pdev);
-
-	gpiochip_remove(gc);
-	return 0;
+	return devm_gpiochip_add_data(&pdev->dev, gc, NULL);
 }
 
 static const struct of_device_id __maybe_unused clps711x_gpio_ids[] = {
@@ -90,7 +82,6 @@ static struct platform_driver clps711x_gpio_driver = {
 		.of_match_table	= of_match_ptr(clps711x_gpio_ids),
 	},
 	.probe	= clps711x_gpio_probe,
-	.remove	= clps711x_gpio_remove,
 };
 module_platform_driver(clps711x_gpio_driver);
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:02 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:02 +0530
Subject: [PATCH 13/61] gpio: crystalcove: Use devm_gpiochip_add_data() for
 gpio registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-14-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
call of gpiochip_remove() from error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-crystalcove.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c
index 7865ef0..7c446d1 100644
--- a/drivers/gpio/gpio-crystalcove.c
+++ b/drivers/gpio/gpio-crystalcove.c
@@ -345,7 +345,7 @@ static int crystalcove_gpio_probe(struct platform_device *pdev)
 	cg->chip.dbg_show = crystalcove_gpio_dbg_show;
 	cg->regmap = pmic->regmap;
 
-	retval = gpiochip_add_data(&cg->chip, cg);
+	retval = devm_gpiochip_add_data(&pdev->dev, &cg->chip, cg);
 	if (retval) {
 		dev_warn(&pdev->dev, "add gpio chip error: %d\n", retval);
 		return retval;
@@ -359,14 +359,10 @@ static int crystalcove_gpio_probe(struct platform_device *pdev)
 
 	if (retval) {
 		dev_warn(&pdev->dev, "request irq failed: %d\n", retval);
-		goto out_remove_gpio;
+		return retval;
 	}
 
 	return 0;
-
-out_remove_gpio:
-	gpiochip_remove(&cg->chip);
-	return retval;
 }
 
 static int crystalcove_gpio_remove(struct platform_device *pdev)
@@ -374,7 +370,6 @@ static int crystalcove_gpio_remove(struct platform_device *pdev)
 	struct crystalcove_gpio *cg = platform_get_drvdata(pdev);
 	int irq = platform_get_irq(pdev, 0);
 
-	gpiochip_remove(&cg->chip);
 	if (irq >= 0)
 		free_irq(irq, cg);
 	return 0;
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:03 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:03 +0530
Subject: [PATCH 14/61] gpio: cs5535: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-15-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-cs5535.c | 20 +++++---------------
 1 file changed, 5 insertions(+), 15 deletions(-)

diff --git a/drivers/gpio/gpio-cs5535.c b/drivers/gpio/gpio-cs5535.c
index eccb712..90278b1 100644
--- a/drivers/gpio/gpio-cs5535.c
+++ b/drivers/gpio/gpio-cs5535.c
@@ -320,13 +320,13 @@ static int cs5535_gpio_probe(struct platform_device *pdev)
 	res = platform_get_resource(pdev, IORESOURCE_IO, 0);
 	if (!res) {
 		dev_err(&pdev->dev, "can't fetch device resource info\n");
-		goto done;
+		return err;
 	}
 
 	if (!devm_request_region(&pdev->dev, res->start, resource_size(res),
 				 pdev->name)) {
 		dev_err(&pdev->dev, "can't request region\n");
-		goto done;
+		return err;
 	}
 
 	/* set up the driver-specific struct */
@@ -348,19 +348,10 @@ static int cs5535_gpio_probe(struct platform_device *pdev)
 				mask_orig, mask);
 
 	/* finally, register with the generic GPIO API */
-	err = gpiochip_add_data(&cs5535_gpio_chip.chip, &cs5535_gpio_chip);
+	err = devm_gpiochip_add_data(&pdev->dev, &cs5535_gpio_chip.chip,
+				     &cs5535_gpio_chip);
 	if (err)
-		goto done;
-
-	return 0;
-
-done:
-	return err;
-}
-
-static int cs5535_gpio_remove(struct platform_device *pdev)
-{
-	gpiochip_remove(&cs5535_gpio_chip.chip);
+		return err;
 
 	return 0;
 }
@@ -370,7 +361,6 @@ static struct platform_driver cs5535_gpio_driver = {
 		.name = DRV_NAME,
 	},
 	.probe = cs5535_gpio_probe,
-	.remove = cs5535_gpio_remove,
 };
 
 module_platform_driver(cs5535_gpio_driver);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:05 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:05 +0530
Subject: [PATCH 16/61] gpio: da9055: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-17-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Support Opensource <support.opensource at diasemi.com>
---
 drivers/gpio/gpio-da9055.c | 16 ++--------------
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/gpio/gpio-da9055.c b/drivers/gpio/gpio-da9055.c
index 18210fb..2c2c18d 100644
--- a/drivers/gpio/gpio-da9055.c
+++ b/drivers/gpio/gpio-da9055.c
@@ -151,31 +151,19 @@ static int da9055_gpio_probe(struct platform_device *pdev)
 	if (pdata && pdata->gpio_base)
 		gpio->gp.base = pdata->gpio_base;
 
-	ret = gpiochip_add_data(&gpio->gp, gpio);
+	ret = devm_gpiochip_add_data(&pdev->dev, &gpio->gp, gpio);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Could not register gpiochip, %d\n", ret);
-		goto err_mem;
+		return ret;
 	}
 
 	platform_set_drvdata(pdev, gpio);
 
 	return 0;
-
-err_mem:
-	return ret;
-}
-
-static int da9055_gpio_remove(struct platform_device *pdev)
-{
-	struct da9055_gpio *gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&gpio->gp);
-	return 0;
 }
 
 static struct platform_driver da9055_gpio_driver = {
 	.probe = da9055_gpio_probe,
-	.remove = da9055_gpio_remove,
 	.driver = {
 		.name	= "da9055-gpio",
 	},
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:06 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:06 +0530
Subject: [PATCH 17/61] gpio: dln2: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-18-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-dln2.c | 16 ++++------------
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/gpio/gpio-dln2.c b/drivers/gpio/gpio-dln2.c
index e11a7d1..f7a60a4 100644
--- a/drivers/gpio/gpio-dln2.c
+++ b/drivers/gpio/gpio-dln2.c
@@ -479,40 +479,32 @@ static int dln2_gpio_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, dln2);
 
-	ret = gpiochip_add_data(&dln2->gpio, dln2);
+	ret = devm_gpiochip_add_data(dev, &dln2->gpio, dln2);
 	if (ret < 0) {
 		dev_err(dev, "failed to add gpio chip: %d\n", ret);
-		goto out;
+		return ret;
 	}
 
 	ret = gpiochip_irqchip_add(&dln2->gpio, &dln2_gpio_irqchip, 0,
 				   handle_simple_irq, IRQ_TYPE_NONE);
 	if (ret < 0) {
 		dev_err(dev, "failed to add irq chip: %d\n", ret);
-		goto out_gpiochip_remove;
+		return ret;
 	}
 
 	ret = dln2_register_event_cb(pdev, DLN2_GPIO_CONDITION_MET_EV,
 				     dln2_gpio_event);
 	if (ret) {
 		dev_err(dev, "failed to register event cb: %d\n", ret);
-		goto out_gpiochip_remove;
+		return ret;
 	}
 
 	return 0;
-
-out_gpiochip_remove:
-	gpiochip_remove(&dln2->gpio);
-out:
-	return ret;
 }
 
 static int dln2_gpio_remove(struct platform_device *pdev)
 {
-	struct dln2_gpio *dln2 = platform_get_drvdata(pdev);
-
 	dln2_unregister_event_cb(pdev, DLN2_GPIO_CONDITION_MET_EV);
-	gpiochip_remove(&dln2->gpio);
 
 	return 0;
 }
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:08 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:08 +0530
Subject: [PATCH 19/61] gpio: f7188x: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-20-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-f7188x.c | 26 ++------------------------
 1 file changed, 2 insertions(+), 24 deletions(-)

diff --git a/drivers/gpio/gpio-f7188x.c b/drivers/gpio/gpio-f7188x.c
index 0417798..daac2d4 100644
--- a/drivers/gpio/gpio-f7188x.c
+++ b/drivers/gpio/gpio-f7188x.c
@@ -350,37 +350,16 @@ static int f7188x_gpio_probe(struct platform_device *pdev)
 		bank->chip.parent = &pdev->dev;
 		bank->data = data;
 
-		err = gpiochip_add_data(&bank->chip, bank);
+		err = devm_gpiochip_add_data(&pdev->dev, &bank->chip, bank);
 		if (err) {
 			dev_err(&pdev->dev,
 				"Failed to register gpiochip %d: %d\n",
 				i, err);
-			goto err_gpiochip;
+			return err;
 		}
 	}
 
 	return 0;
-
-err_gpiochip:
-	for (i = i - 1; i >= 0; i--) {
-		struct f7188x_gpio_bank *bank = &data->bank[i];
-		gpiochip_remove(&bank->chip);
-	}
-
-	return err;
-}
-
-static int f7188x_gpio_remove(struct platform_device *pdev)
-{
-	int i;
-	struct f7188x_gpio_data *data = platform_get_drvdata(pdev);
-
-	for (i = 0; i < data->nr_bank; i++) {
-		struct f7188x_gpio_bank *bank = &data->bank[i];
-		gpiochip_remove(&bank->chip);
-	}
-
-	return 0;
 }
 
 static int __init f7188x_find(int addr, struct f7188x_sio *sio)
@@ -476,7 +455,6 @@ static struct platform_driver f7188x_gpio_driver = {
 		.name	= DRVNAME,
 	},
 	.probe		= f7188x_gpio_probe,
-	.remove		= f7188x_gpio_remove,
 };
 
 static int __init f7188x_gpio_init(void)
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:07 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:07 +0530
Subject: [PATCH 18/61] gpio: ep93xx: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-19-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-ep93xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-ep93xx.c b/drivers/gpio/gpio-ep93xx.c
index ad27907..d054219 100644
--- a/drivers/gpio/gpio-ep93xx.c
+++ b/drivers/gpio/gpio-ep93xx.c
@@ -339,7 +339,7 @@ static int ep93xx_gpio_add_bank(struct gpio_chip *gc, struct device *dev,
 		gc->to_irq = ep93xx_gpio_to_irq;
 	}
 
-	return gpiochip_add_data(gc, NULL);
+	return devm_gpiochip_add_data(dev, gc, NULL);
 }
 
 static int ep93xx_gpio_probe(struct platform_device *pdev)
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:09 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:09 +0530
Subject: [PATCH 20/61] gpio: ge: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-21-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-ge.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-ge.c b/drivers/gpio/gpio-ge.c
index cbbec83..8650b29 100644
--- a/drivers/gpio/gpio-ge.c
+++ b/drivers/gpio/gpio-ge.c
@@ -89,7 +89,7 @@ static int __init gef_gpio_probe(struct platform_device *pdev)
 	gc->of_node = pdev->dev.of_node;
 
 	/* This function adds a memory mapped GPIO chip */
-	ret = gpiochip_add_data(gc, NULL);
+	ret = devm_gpiochip_add_data(&pdev->dev, gc, NULL);
 	if (ret)
 		goto err0;
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:10 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:10 +0530
Subject: [PATCH 21/61] gpio: generic: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-22-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-generic.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-generic.c b/drivers/gpio/gpio-generic.c
index 2a4f233..54cddfa 100644
--- a/drivers/gpio/gpio-generic.c
+++ b/drivers/gpio/gpio-generic.c
@@ -628,15 +628,7 @@ static int bgpio_pdev_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, gc);
 
-	return gpiochip_add_data(gc, NULL);
-}
-
-static int bgpio_pdev_remove(struct platform_device *pdev)
-{
-	struct gpio_chip *gc = platform_get_drvdata(pdev);
-
-	gpiochip_remove(gc);
-	return 0;
+	return devm_gpiochip_add_data(&pdev->dev, gc, NULL);
 }
 
 static const struct platform_device_id bgpio_id_table[] = {
@@ -657,7 +649,6 @@ static struct platform_driver bgpio_driver = {
 	},
 	.id_table = bgpio_id_table,
 	.probe = bgpio_pdev_probe,
-	.remove = bgpio_pdev_remove,
 };
 
 module_platform_driver(bgpio_driver);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:22 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:22 +0530
Subject: [PATCH 33/61] gpio: pca953x: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-34-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-pca953x.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 23196c5..b7fe5d5 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -754,7 +754,7 @@ static int pca953x_probe(struct i2c_client *client,
 	if (ret)
 		return ret;
 
-	ret = gpiochip_add_data(&chip->gpio_chip, chip);
+	ret = devm_gpiochip_add_data(&client->dev, &chip->gpio_chip, chip);
 	if (ret)
 		return ret;
 
@@ -789,8 +789,6 @@ static int pca953x_remove(struct i2c_client *client)
 		}
 	}
 
-	gpiochip_remove(&chip->gpio_chip);
-
 	return 0;
 }
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:12 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:12 +0530
Subject: [PATCH 23/61] gpio: janz-ttl: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-24-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-janz-ttl.c | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/gpio/gpio-janz-ttl.c b/drivers/gpio/gpio-janz-ttl.c
index 482aa03..a8d0a6b 100644
--- a/drivers/gpio/gpio-janz-ttl.c
+++ b/drivers/gpio/gpio-janz-ttl.c
@@ -182,7 +182,7 @@ static int ttl_probe(struct platform_device *pdev)
 	gpio->base = -1;
 	gpio->ngpio = 20;
 
-	ret = gpiochip_add_data(gpio, NULL);
+	ret = devm_gpiochip_add_data(dev, gpio, NULL);
 	if (ret) {
 		dev_err(dev, "unable to add GPIO chip\n");
 		return ret;
@@ -191,21 +191,11 @@ static int ttl_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int ttl_remove(struct platform_device *pdev)
-{
-	struct ttl_module *mod = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&mod->gpio);
-
-	return 0;
-}
-
 static struct platform_driver ttl_driver = {
 	.driver		= {
 		.name	= DRV_NAME,
 	},
 	.probe		= ttl_probe,
-	.remove		= ttl_remove,
 };
 
 module_platform_driver(ttl_driver);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:13 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:13 +0530
Subject: [PATCH 24/61] gpio: kempld: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-25-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-kempld.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-kempld.c b/drivers/gpio/gpio-kempld.c
index 0111774..701f151 100644
--- a/drivers/gpio/gpio-kempld.c
+++ b/drivers/gpio/gpio-kempld.c
@@ -178,7 +178,7 @@ static int kempld_gpio_probe(struct platform_device *pdev)
 		return -ENODEV;
 	}
 
-	ret = gpiochip_add_data(chip, gpio);
+	ret = devm_gpiochip_add_data(dev, chip, gpio);
 	if (ret) {
 		dev_err(dev, "Could not register GPIO chip\n");
 		return ret;
@@ -190,20 +190,11 @@ static int kempld_gpio_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int kempld_gpio_remove(struct platform_device *pdev)
-{
-	struct kempld_gpio_data *gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&gpio->chip);
-	return 0;
-}
-
 static struct platform_driver kempld_gpio_driver = {
 	.driver = {
 		.name = "kempld-gpio",
 	},
 	.probe		= kempld_gpio_probe,
-	.remove		= kempld_gpio_remove,
 };
 
 module_platform_driver(kempld_gpio_driver);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:14 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:14 +0530
Subject: [PATCH 25/61] gpio: lp3943: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-26-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-lp3943.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-lp3943.c b/drivers/gpio/gpio-lp3943.c
index 1c8e2ae..6dc6725 100644
--- a/drivers/gpio/gpio-lp3943.c
+++ b/drivers/gpio/gpio-lp3943.c
@@ -204,15 +204,8 @@ static int lp3943_gpio_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, lp3943_gpio);
 
-	return gpiochip_add_data(&lp3943_gpio->chip, lp3943_gpio);
-}
-
-static int lp3943_gpio_remove(struct platform_device *pdev)
-{
-	struct lp3943_gpio *lp3943_gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&lp3943_gpio->chip);
-	return 0;
+	return devm_gpiochip_add_data(&pdev->dev, &lp3943_gpio->chip,
+				      lp3943_gpio);
 }
 
 static const struct of_device_id lp3943_gpio_of_match[] = {
@@ -223,7 +216,6 @@ MODULE_DEVICE_TABLE(of, lp3943_gpio_of_match);
 
 static struct platform_driver lp3943_gpio_driver = {
 	.probe = lp3943_gpio_probe,
-	.remove = lp3943_gpio_remove,
 	.driver = {
 		.name = "lp3943-gpio",
 		.of_match_table = lp3943_gpio_of_match,
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:15 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:15 +0530
Subject: [PATCH 26/61] gpio: lpc32xx: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-27-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-lpc32xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-lpc32xx.c b/drivers/gpio/gpio-lpc32xx.c
index 4cecf4c..d39014d 100644
--- a/drivers/gpio/gpio-lpc32xx.c
+++ b/drivers/gpio/gpio-lpc32xx.c
@@ -547,7 +547,7 @@ static int lpc32xx_gpio_probe(struct platform_device *pdev)
 			lpc32xx_gpiochip[i].chip.of_gpio_n_cells = 3;
 			lpc32xx_gpiochip[i].chip.of_node = pdev->dev.of_node;
 		}
-		gpiochip_add_data(&lpc32xx_gpiochip[i].chip,
+		devm_gpiochip_add_data(&pdev->dev, &lpc32xx_gpiochip[i].chip,
 				  &lpc32xx_gpiochip[i]);
 	}
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:16 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:16 +0530
Subject: [PATCH 27/61] gpio: lynxpoint: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-28-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-lynxpoint.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-lynxpoint.c b/drivers/gpio/gpio-lynxpoint.c
index 1310777..9df015e 100644
--- a/drivers/gpio/gpio-lynxpoint.c
+++ b/drivers/gpio/gpio-lynxpoint.c
@@ -370,7 +370,7 @@ static int lp_gpio_probe(struct platform_device *pdev)
 	gc->can_sleep = false;
 	gc->parent = dev;
 
-	ret = gpiochip_add_data(gc, lg);
+	ret = devm_gpiochip_add_data(dev, gc, lg);
 	if (ret) {
 		dev_err(dev, "failed adding lp-gpio chip\n");
 		return ret;
@@ -439,9 +439,7 @@ MODULE_DEVICE_TABLE(acpi, lynxpoint_gpio_acpi_match);
 
 static int lp_gpio_remove(struct platform_device *pdev)
 {
-	struct lp_gpio *lg = platform_get_drvdata(pdev);
 	pm_runtime_disable(&pdev->dev);
-	gpiochip_remove(&lg->chip);
 	return 0;
 }
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:17 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:17 +0530
Subject: [PATCH 28/61] gpio: mc9s08dz60: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-29-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-mc9s08dz60.c | 13 +------------
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpio/gpio-mc9s08dz60.c b/drivers/gpio/gpio-mc9s08dz60.c
index ba22fb9..14f252f 100644
--- a/drivers/gpio/gpio-mc9s08dz60.c
+++ b/drivers/gpio/gpio-mc9s08dz60.c
@@ -103,17 +103,7 @@ static int mc9s08dz60_probe(struct i2c_client *client,
 	mc9s->client = client;
 	i2c_set_clientdata(client, mc9s);
 
-	return gpiochip_add_data(&mc9s->chip, mc9s);
-}
-
-static int mc9s08dz60_remove(struct i2c_client *client)
-{
-	struct mc9s08dz60 *mc9s;
-
-	mc9s = i2c_get_clientdata(client);
-
-	gpiochip_remove(&mc9s->chip);
-	return 0;
+	return devm_gpiochip_add_data(&client->dev, &mc9s->chip, mc9s);
 }
 
 static const struct i2c_device_id mc9s08dz60_id[] = {
@@ -128,7 +118,6 @@ static struct i2c_driver mc9s08dz60_i2c_driver = {
 		.name = "mc9s08dz60",
 	},
 	.probe = mc9s08dz60_probe,
-	.remove = mc9s08dz60_remove,
 	.id_table = mc9s08dz60_id,
 };
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:18 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:18 +0530
Subject: [PATCH 29/61] gpio: moxart: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-30-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-moxart.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-moxart.c b/drivers/gpio/gpio-moxart.c
index ca60453..869002b 100644
--- a/drivers/gpio/gpio-moxart.c
+++ b/drivers/gpio/gpio-moxart.c
@@ -63,7 +63,7 @@ static int moxart_gpio_probe(struct platform_device *pdev)
 	gc->parent = dev;
 	gc->owner = THIS_MODULE;
 
-	ret = gpiochip_add_data(gc, NULL);
+	ret = devm_gpiochip_add_data(dev, gc, NULL);
 	if (ret) {
 		dev_err(dev, "%s: gpiochip_add failed\n",
 			dev->of_node->full_name);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:19 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:19 +0530
Subject: [PATCH 30/61] gpio: mvebu: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-31-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and clean the
error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-mvebu.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index a5eacc1..11c6582 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -756,7 +756,7 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
 		BUG();
 	}
 
-	gpiochip_add_data(&mvchip->chip, mvchip);
+	devm_gpiochip_add_data(&pdev->dev, &mvchip->chip, mvchip);
 
 	/* Some gpio controllers do not provide irq support */
 	if (!of_irq_count(np))
@@ -777,16 +777,14 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
 	mvchip->irqbase = irq_alloc_descs(-1, 0, ngpios, -1);
 	if (mvchip->irqbase < 0) {
 		dev_err(&pdev->dev, "no irqs\n");
-		err = mvchip->irqbase;
-		goto err_gpiochip_add;
+		return mvchip->irqbase;
 	}
 
 	gc = irq_alloc_generic_chip("mvebu_gpio_irq", 2, mvchip->irqbase,
 				    mvchip->membase, handle_level_irq);
 	if (!gc) {
 		dev_err(&pdev->dev, "Cannot allocate generic irq_chip\n");
-		err = -ENOMEM;
-		goto err_gpiochip_add;
+		return -ENOMEM;
 	}
 
 	gc->private = mvchip;
@@ -828,9 +826,6 @@ err_generic_chip:
 				IRQ_LEVEL | IRQ_NOPROBE);
 	kfree(gc);
 
-err_gpiochip_add:
-	gpiochip_remove(&mvchip->chip);
-
 	return err;
 }
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:20 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:20 +0530
Subject: [PATCH 31/61] gpio: mxc: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-32-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and clean the
error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-mxc.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index 7fd21cb..1b342a3 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -462,14 +462,14 @@ static int mxc_gpio_probe(struct platform_device *pdev)
 	port->gc.base = (pdev->id < 0) ? of_alias_get_id(np, "gpio") * 32 :
 					     pdev->id * 32;
 
-	err = gpiochip_add_data(&port->gc, port);
+	err = devm_gpiochip_add_data(&pdev->dev, &port->gc, port);
 	if (err)
 		goto out_bgio;
 
 	irq_base = irq_alloc_descs(-1, 0, 32, numa_node_id());
 	if (irq_base < 0) {
 		err = irq_base;
-		goto out_gpiochip_remove;
+		goto out_bgio;
 	}
 
 	port->domain = irq_domain_add_legacy(np, 32, irq_base, 0,
@@ -492,8 +492,6 @@ out_irqdomain_remove:
 	irq_domain_remove(port->domain);
 out_irqdesc_free:
 	irq_free_descs(irq_base, 32);
-out_gpiochip_remove:
-	gpiochip_remove(&port->gc);
 out_bgio:
 	dev_info(&pdev->dev, "%s failed with errno %d\n", __func__, err);
 	return err;
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:42 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:42 +0530
Subject: [PATCH 53/61] gpio: twl6040: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-54-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-twl6040.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpio/gpio-twl6040.c b/drivers/gpio/gpio-twl6040.c
index 8e9e985..b780314 100644
--- a/drivers/gpio/gpio-twl6040.c
+++ b/drivers/gpio/gpio-twl6040.c
@@ -100,7 +100,7 @@ static int gpo_twl6040_probe(struct platform_device *pdev)
 	twl6040gpo_chip.of_node = twl6040_core_dev->of_node;
 #endif
 
-	ret = gpiochip_add_data(&twl6040gpo_chip, NULL);
+	ret = devm_gpiochip_add_data(&pdev->dev, &twl6040gpo_chip, NULL);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "could not register gpiochip, %d\n", ret);
 		twl6040gpo_chip.ngpio = 0;
@@ -109,12 +109,6 @@ static int gpo_twl6040_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int gpo_twl6040_remove(struct platform_device *pdev)
-{
-	gpiochip_remove(&twl6040gpo_chip);
-	return 0;
-}
-
 /* Note:  this hardware lives inside an I2C-based multi-function device. */
 MODULE_ALIAS("platform:twl6040-gpo");
 
@@ -123,7 +117,6 @@ static struct platform_driver gpo_twl6040_driver = {
 		.name	= "twl6040-gpo",
 	},
 	.probe		= gpo_twl6040_probe,
-	.remove		= gpo_twl6040_remove,
 };
 
 module_platform_driver(gpo_twl6040_driver);
-- 
2.1.4



From ard.biesheuvel at linaro.org  Mon Feb 22 06:25:54 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 15:25:54 +0100
Subject: [PATCH 1/5] ARM: efi: apply strict permissons for UEFI Runtime
 Services regions
In-Reply-To: <1456151158-25849-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456151158-25849-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456151158-25849-2-git-send-email-ard.biesheuvel@linaro.org>

Recent UEFI versions expose permission attributes for runtime services
memory regions, either in the UEFI memory map or in the separate memory
attributes table.  This allows the kernel to map these regions with
stricter permissions, rather than the RWX permissions that are used by
default. So wire this up in our mapping routine.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm/include/asm/efi.h |  1 +
 arch/arm/kernel/efi.c      | 41 ++++++++++++++++++++
 2 files changed, 42 insertions(+)

diff --git a/arch/arm/include/asm/efi.h b/arch/arm/include/asm/efi.h
index e0eea72deb87..b0c341d7ceee 100644
--- a/arch/arm/include/asm/efi.h
+++ b/arch/arm/include/asm/efi.h
@@ -22,6 +22,7 @@
 void efi_init(void);
 
 int efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md);
+int efi_set_mapping_permissions(struct mm_struct *mm, efi_memory_desc_t *md);
 
 #define efi_call_virt(f, ...)						\
 ({									\
diff --git a/arch/arm/kernel/efi.c b/arch/arm/kernel/efi.c
index ff8a9d8acfac..9f43ba012d10 100644
--- a/arch/arm/kernel/efi.c
+++ b/arch/arm/kernel/efi.c
@@ -11,6 +11,41 @@
 #include <asm/mach/map.h>
 #include <asm/mmu_context.h>
 
+static int __init set_permissions(pte_t *ptep, pgtable_t token,
+				  unsigned long addr, void *data)
+{
+	efi_memory_desc_t *md = data;
+	pte_t pte = *ptep;
+
+	if (md->attribute & EFI_MEMORY_RO)
+		pte = set_pte_bit(pte, __pgprot(L_PTE_RDONLY));
+	if (md->attribute & EFI_MEMORY_XP)
+		pte = set_pte_bit(pte, __pgprot(L_PTE_XN));
+	set_pte_ext(ptep, pte, PTE_EXT_NG);
+	return 0;
+}
+
+int __init efi_set_mapping_permissions(struct mm_struct *mm,
+				       efi_memory_desc_t *md)
+{
+	unsigned long base, size;
+
+	base = md->virt_addr;
+	size = md->num_pages << EFI_PAGE_SHIFT;
+
+	/*
+	 * We can only use apply_to_page_range() if we can guarantee that the
+	 * entire region was mapped using pages. This should be the case if the
+	 * region does not cover any naturally aligned SECTION_SIZE sized
+	 * blocks.
+	 */
+	if (round_down(base + size, SECTION_SIZE) <
+	    round_up(base, SECTION_SIZE) + SECTION_SIZE)
+		return apply_to_page_range(mm, base, size, set_permissions, md);
+
+	return 0;
+}
+
 int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md)
 {
 	struct map_desc desc = {
@@ -34,5 +69,11 @@ int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md)
 		desc.type = MT_DEVICE;
 
 	create_mapping_late(mm, &desc, true);
+
+	/*
+	 * If stricter permissions were specified, apply them now.
+	 */
+	if (md->attribute & (EFI_MEMORY_RO | EFI_MEMORY_XP))
+		return efi_set_mapping_permissions(mm, md);
 	return 0;
 }
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 06:25:55 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 15:25:55 +0100
Subject: [PATCH 2/5] arm64: efi: apply strict permissons for UEFI Runtime
 Services regions
In-Reply-To: <1456151158-25849-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456151158-25849-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456151158-25849-3-git-send-email-ard.biesheuvel@linaro.org>

Recent UEFI versions expose permission attributes for runtime services
memory regions, either in the UEFI memory map or in the separate memory
attributes table. This allows the kernel to map these regions with
stricter permissions, rather than the RWX permissions that are used by
default. So wire this up in our mapping routine.

Note that in the absence of permission attributes, we still only map
regions of type EFI_RUNTIME_SERVICE_CODE with the executable bit set.
Also, we base the mapping attributes of EFI_MEMORY_MAPPED_IO on the
type directly rather than on the absence of the EFI_MEMORY_WB attribute.
This is more correct, but is also required for compatibility with the
upcoming support for the Memory Attributes Table, which only carries
permission attributes, not memory type attributes.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/kernel/efi.c | 27 ++++++++++++++++----
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index b6abc852f2a1..3364408c154f 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -24,15 +24,32 @@ int __init efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md)
 	/*
 	 * Only regions of type EFI_RUNTIME_SERVICES_CODE need to be
 	 * executable, everything else can be mapped with the XN bits
-	 * set.
+	 * set. Also take the new (optional) RO/XP bits into account.
 	 */
-	if ((md->attribute & EFI_MEMORY_WB) == 0)
+	if (md->type == EFI_MEMORY_MAPPED_IO)
 		prot_val = PROT_DEVICE_nGnRE;
-	else if (md->type == EFI_RUNTIME_SERVICES_CODE ||
-		 !PAGE_ALIGNED(md->phys_addr))
+	else if (WARN_ONCE(!PAGE_ALIGNED(md->phys_addr),
+			   "UEFI Runtime regions are not aligned to 64 KB -- buggy firmware?"))
+		/*
+		 * If the region is not aligned to the page size of the OS, we
+		 * can not use strict permissions, since that would also affect
+		 * the mapping attributes of the adjacent regions.
+		 */
 		prot_val = pgprot_val(PAGE_KERNEL_EXEC);
-	else
+	else if ((md->attribute & (EFI_MEMORY_XP | EFI_MEMORY_RO)) ==
+		 (EFI_MEMORY_XP | EFI_MEMORY_RO))
+		/* R-- */
+		prot_val = pgprot_val(PAGE_KERNEL_RO);
+	else if (md->attribute & EFI_MEMORY_RO)
+		/* R-X */
+		prot_val = pgprot_val(PAGE_KERNEL_ROX);
+	else if (md->attribute & EFI_MEMORY_XP ||
+		 md->type != EFI_RUNTIME_SERVICES_CODE)
+		/* RW- */
 		prot_val = pgprot_val(PAGE_KERNEL);
+	else
+		/* RWX */
+		prot_val = pgprot_val(PAGE_KERNEL_EXEC);
 
 	create_pgd_mapping(mm, md->phys_addr, md->virt_addr,
 			   md->num_pages << EFI_PAGE_SHIFT,
-- 
2.5.0



From ldewangan at nvidia.com  Mon Feb 22 06:08:37 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:37 +0530
Subject: [PATCH 48/61] gpio: tps6586x: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-49-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-tps6586x.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-tps6586x.c b/drivers/gpio/gpio-tps6586x.c
index 87de548..c88bdc8 100644
--- a/drivers/gpio/gpio-tps6586x.c
+++ b/drivers/gpio/gpio-tps6586x.c
@@ -117,7 +117,8 @@ static int tps6586x_gpio_probe(struct platform_device *pdev)
 	else
 		tps6586x_gpio->gpio_chip.base = -1;
 
-	ret = gpiochip_add_data(&tps6586x_gpio->gpio_chip, tps6586x_gpio);
+	ret = devm_gpiochip_add_data(&pdev->dev, &tps6586x_gpio->gpio_chip,
+				     tps6586x_gpio);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Could not register gpiochip, %d\n", ret);
 		return ret;
@@ -128,19 +129,10 @@ static int tps6586x_gpio_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int tps6586x_gpio_remove(struct platform_device *pdev)
-{
-	struct tps6586x_gpio *tps6586x_gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&tps6586x_gpio->gpio_chip);
-	return 0;
-}
-
 static struct platform_driver tps6586x_gpio_driver = {
 	.driver.name	= "tps6586x-gpio",
 	.driver.owner	= THIS_MODULE,
 	.probe		= tps6586x_gpio_probe,
-	.remove		= tps6586x_gpio_remove,
 };
 
 static int __init tps6586x_gpio_init(void)
-- 
2.1.4



From ard.biesheuvel at linaro.org  Mon Feb 22 06:25:56 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 15:25:56 +0100
Subject: [PATCH 3/5] efi: add support for the EFI_MEMORY_ATTRIBUTES_TABLE
 config table
In-Reply-To: <1456151158-25849-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456151158-25849-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456151158-25849-4-git-send-email-ard.biesheuvel@linaro.org>

This declares the GUID and struct typedef for the new memory attributes
table which contains the permissions that can be used to apply stricter
permissions to UEFI Runtime Services memory regions.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/firmware/efi/efi.c |  2 ++
 include/linux/efi.h        | 13 +++++++++++++
 2 files changed, 15 insertions(+)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 3a69ed5ecfcb..5683865baa92 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -43,6 +43,7 @@ struct efi __read_mostly efi = {
 	.config_table		= EFI_INVALID_TABLE_ADDR,
 	.esrt			= EFI_INVALID_TABLE_ADDR,
 	.properties_table	= EFI_INVALID_TABLE_ADDR,
+	.mem_attr_table		= EFI_INVALID_TABLE_ADDR,
 };
 EXPORT_SYMBOL(efi);
 
@@ -338,6 +339,7 @@ static __initdata efi_config_table_type_t common_tables[] = {
 	{UGA_IO_PROTOCOL_GUID, "UGA", &efi.uga},
 	{EFI_SYSTEM_RESOURCE_TABLE_GUID, "ESRT", &efi.esrt},
 	{EFI_PROPERTIES_TABLE_GUID, "PROP", &efi.properties_table},
+	{EFI_MEMORY_ATTRIBUTES_TABLE_GUID, "MEMATTR", &efi.mem_attr_table},
 	{NULL_GUID, NULL, NULL},
 };
 
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 42be9c92fdf0..808d97299c70 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -619,6 +619,10 @@ void efi_native_runtime_setup(void);
 	EFI_GUID(0x880aaca3, 0x4adc, 0x4a04, \
 		 0x90, 0x79, 0xb7, 0x47, 0x34, 0x08, 0x25, 0xe5)
 
+#define EFI_MEMORY_ATTRIBUTES_TABLE_GUID \
+	EFI_GUID(0xdcfa911d, 0x26eb, 0x469f, \
+		 0xa2, 0x20, 0x38, 0xb7, 0xdc, 0x46, 0x12, 0x20)
+
 typedef struct {
 	efi_guid_t guid;
 	u64 table;
@@ -843,6 +847,14 @@ typedef struct {
 
 #define EFI_INVALID_TABLE_ADDR		(~0UL)
 
+typedef struct {
+	u32 version;
+	u32 num_entries;
+	u32 desc_size;
+	u32 reserved;
+	efi_memory_desc_t entry[0];
+} efi_memory_attributes_table_t;
+
 /*
  * All runtime access to EFI goes through this structure:
  */
@@ -864,6 +876,7 @@ extern struct efi {
 	unsigned long config_table;	/* config tables */
 	unsigned long esrt;		/* ESRT table */
 	unsigned long properties_table;	/* properties table */
+	unsigned long mem_attr_table;	/* memory attributes table */
 	efi_get_time_t *get_time;
 	efi_set_time_t *set_time;
 	efi_get_wakeup_time_t *get_wakeup_time;
-- 
2.5.0



From ldewangan at nvidia.com  Mon Feb 22 06:08:39 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:39 +0530
Subject: [PATCH 50/61] gpio: tps65912: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-51-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-tps65912.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c
index 4f2029c..e72302d 100644
--- a/drivers/gpio/gpio-tps65912.c
+++ b/drivers/gpio/gpio-tps65912.c
@@ -106,7 +106,8 @@ static int tps65912_gpio_probe(struct platform_device *pdev)
 	if (pdata && pdata->gpio_base)
 		tps65912_gpio->gpio_chip.base = pdata->gpio_base;
 
-	ret = gpiochip_add_data(&tps65912_gpio->gpio_chip, tps65912_gpio);
+	ret = devm_gpiochip_add_data(&pdev->dev, &tps65912_gpio->gpio_chip,
+				     tps65912_gpio);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Failed to register gpiochip, %d\n", ret);
 		return ret;
@@ -117,20 +118,11 @@ static int tps65912_gpio_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int tps65912_gpio_remove(struct platform_device *pdev)
-{
-	struct tps65912_gpio_data  *tps65912_gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&tps65912_gpio->gpio_chip);
-	return 0;
-}
-
 static struct platform_driver tps65912_gpio_driver = {
 	.driver = {
 		.name = "tps65912-gpio",
 	},
 	.probe = tps65912_gpio_probe,
-	.remove = tps65912_gpio_remove,
 };
 
 static int __init tps65912_gpio_init(void)
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:41 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:41 +0530
Subject: [PATCH 52/61] gpio: ts5500: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-53-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and clean the
error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-ts5500.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpio/gpio-ts5500.c b/drivers/gpio/gpio-ts5500.c
index 5f94508..6cfeba0 100644
--- a/drivers/gpio/gpio-ts5500.c
+++ b/drivers/gpio/gpio-ts5500.c
@@ -409,7 +409,7 @@ static int ts5500_dio_probe(struct platform_device *pdev)
 		break;
 	}
 
-	ret = gpiochip_add_data(&priv->gpio_chip, priv);
+	ret = devm_gpiochip_add_data(dev, &priv->gpio_chip, priv);
 	if (ret) {
 		dev_err(dev, "failed to register the gpio chip\n");
 		return ret;
@@ -418,13 +418,10 @@ static int ts5500_dio_probe(struct platform_device *pdev)
 	ret = ts5500_enable_irq(priv);
 	if (ret) {
 		dev_err(dev, "invalid interrupt %d\n", priv->hwirq);
-		goto cleanup;
+		return ret;
 	}
 
 	return 0;
-cleanup:
-	gpiochip_remove(&priv->gpio_chip);
-	return ret;
 }
 
 static int ts5500_dio_remove(struct platform_device *pdev)
@@ -432,7 +429,7 @@ static int ts5500_dio_remove(struct platform_device *pdev)
 	struct ts5500_priv *priv = platform_get_drvdata(pdev);
 
 	ts5500_disable_irq(priv);
-	gpiochip_remove(&priv->gpio_chip);
+
 	return 0;
 }
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:40 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:40 +0530
Subject: [PATCH 51/61] gpio: ts4800: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-52-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-ts4800.c | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/gpio/gpio-ts4800.c b/drivers/gpio/gpio-ts4800.c
index c4908a4..b8762d9 100644
--- a/drivers/gpio/gpio-ts4800.c
+++ b/drivers/gpio/gpio-ts4800.c
@@ -61,16 +61,7 @@ static int ts4800_gpio_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, chip);
 
-	return gpiochip_add_data(chip, NULL);
-}
-
-static int ts4800_gpio_remove(struct platform_device *pdev)
-{
-	struct gpio_chip *chip = platform_get_drvdata(pdev);
-
-	gpiochip_remove(chip);
-
-	return 0;
+	return devm_gpiochip_add_data(&pdev->dev, chip, NULL);
 }
 
 static const struct of_device_id ts4800_gpio_of_match[] = {
@@ -84,7 +75,6 @@ static struct platform_driver ts4800_gpio_driver = {
 		   .of_match_table = ts4800_gpio_of_match,
 		   },
 	.probe = ts4800_gpio_probe,
-	.remove = ts4800_gpio_remove,
 };
 
 module_platform_driver_probe(ts4800_gpio_driver, ts4800_gpio_probe);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:43 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:43 +0530
Subject: [PATCH 54/61] gpio: ucb1400: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-55-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-ucb1400.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-ucb1400.c b/drivers/gpio/gpio-ucb1400.c
index 2c5cd46..5dbe31b 100644
--- a/drivers/gpio/gpio-ucb1400.c
+++ b/drivers/gpio/gpio-ucb1400.c
@@ -67,7 +67,7 @@ static int ucb1400_gpio_probe(struct platform_device *dev)
 	ucb->gc.set = ucb1400_gpio_set;
 	ucb->gc.can_sleep = true;
 
-	err = gpiochip_add_data(&ucb->gc, ucb);
+	err = devm_gpiochip_add_data(&dev->dev, &ucb->gc, ucb);
 	if (err)
 		goto err;
 
@@ -90,7 +90,6 @@ static int ucb1400_gpio_remove(struct platform_device *dev)
 			return err;
 	}
 
-	gpiochip_remove(&ucb->gc);
 	return err;
 }
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:44 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:44 +0530
Subject: [PATCH 55/61] gpio: viperboard: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-56-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-viperboard.c | 24 ++++--------------------
 1 file changed, 4 insertions(+), 20 deletions(-)

diff --git a/drivers/gpio/gpio-viperboard.c b/drivers/gpio/gpio-viperboard.c
index 1170b03..dec47aa 100644
--- a/drivers/gpio/gpio-viperboard.c
+++ b/drivers/gpio/gpio-viperboard.c
@@ -410,10 +410,10 @@ static int vprbrd_gpio_probe(struct platform_device *pdev)
 	vb_gpio->gpioa.get = vprbrd_gpioa_get;
 	vb_gpio->gpioa.direction_input = vprbrd_gpioa_direction_input;
 	vb_gpio->gpioa.direction_output = vprbrd_gpioa_direction_output;
-	ret = gpiochip_add_data(&vb_gpio->gpioa, vb_gpio);
+	ret = devm_gpiochip_add_data(&pdev->dev, &vb_gpio->gpioa, vb_gpio);
 	if (ret < 0) {
 		dev_err(vb_gpio->gpioa.parent, "could not add gpio a");
-		goto err_gpioa;
+		return ret;
 	}
 
 	/* registering gpio b */
@@ -427,37 +427,21 @@ static int vprbrd_gpio_probe(struct platform_device *pdev)
 	vb_gpio->gpiob.get = vprbrd_gpiob_get;
 	vb_gpio->gpiob.direction_input = vprbrd_gpiob_direction_input;
 	vb_gpio->gpiob.direction_output = vprbrd_gpiob_direction_output;
-	ret = gpiochip_add_data(&vb_gpio->gpiob, vb_gpio);
+	ret = devm_gpiochip_add_data(&pdev->dev, &vb_gpio->gpiob, vb_gpio);
 	if (ret < 0) {
 		dev_err(vb_gpio->gpiob.parent, "could not add gpio b");
-		goto err_gpiob;
+		return ret;
 	}
 
 	platform_set_drvdata(pdev, vb_gpio);
 
 	return ret;
-
-err_gpiob:
-	gpiochip_remove(&vb_gpio->gpioa);
-
-err_gpioa:
-	return ret;
-}
-
-static int vprbrd_gpio_remove(struct platform_device *pdev)
-{
-	struct vprbrd_gpio *vb_gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&vb_gpio->gpiob);
-
-	return 0;
 }
 
 static struct platform_driver vprbrd_gpio_driver = {
 	.driver.name	= "viperboard-gpio",
 	.driver.owner	= THIS_MODULE,
 	.probe		= vprbrd_gpio_probe,
-	.remove		= vprbrd_gpio_remove,
 };
 
 static int __init vprbrd_gpio_init(void)
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:45 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:45 +0530
Subject: [PATCH 56/61] gpio: vx855: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-57-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-vx855.c | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/gpio/gpio-vx855.c b/drivers/gpio/gpio-vx855.c
index 764999c..8cdb9f7 100644
--- a/drivers/gpio/gpio-vx855.c
+++ b/drivers/gpio/gpio-vx855.c
@@ -259,16 +259,7 @@ static int vx855gpio_probe(struct platform_device *pdev)
 
 	vx855gpio_gpio_setup(vg);
 
-	return gpiochip_add_data(&vg->gpio, vg);
-}
-
-static int vx855gpio_remove(struct platform_device *pdev)
-{
-	struct vx855_gpio *vg = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&vg->gpio);
-
-	return 0;
+	return devm_gpiochip_add_data(&pdev->dev, &vg->gpio, vg);
 }
 
 static struct platform_driver vx855gpio_driver = {
@@ -276,7 +267,6 @@ static struct platform_driver vx855gpio_driver = {
 		.name	= MODULE_NAME,
 	},
 	.probe		= vx855gpio_probe,
-	.remove		= vx855gpio_remove,
 };
 
 module_platform_driver(vx855gpio_driver);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:46 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:46 +0530
Subject: [PATCH 57/61] gpio: wm8350: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-58-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: patches at opensource.wolfsonmicro.com
---
 drivers/gpio/gpio-wm831x.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-wm831x.c b/drivers/gpio/gpio-wm831x.c
index 9839007..18cb0f5 100644
--- a/drivers/gpio/gpio-wm831x.c
+++ b/drivers/gpio/gpio-wm831x.c
@@ -259,7 +259,8 @@ static int wm831x_gpio_probe(struct platform_device *pdev)
 	else
 		wm831x_gpio->gpio_chip.base = -1;
 
-	ret = gpiochip_add_data(&wm831x_gpio->gpio_chip, wm831x_gpio);
+	ret = devm_gpiochip_add_data(&pdev->dev, &wm831x_gpio->gpio_chip,
+				     wm831x_gpio);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Could not register gpiochip, %d\n", ret);
 		return ret;
@@ -270,19 +271,10 @@ static int wm831x_gpio_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int wm831x_gpio_remove(struct platform_device *pdev)
-{
-	struct wm831x_gpio *wm831x_gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&wm831x_gpio->gpio_chip);
-	return 0;
-}
-
 static struct platform_driver wm831x_gpio_driver = {
 	.driver.name	= "wm831x-gpio",
 	.driver.owner	= THIS_MODULE,
 	.probe		= wm831x_gpio_probe,
-	.remove		= wm831x_gpio_remove,
 };
 
 static int __init wm831x_gpio_init(void)
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:47 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:47 +0530
Subject: [PATCH 58/61] gpio: wm8350: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-59-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: patches at opensource.wolfsonmicro.com
---
 drivers/gpio/gpio-wm8350.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-wm8350.c b/drivers/gpio/gpio-wm8350.c
index 0a306b4..07d45a3 100644
--- a/drivers/gpio/gpio-wm8350.c
+++ b/drivers/gpio/gpio-wm8350.c
@@ -125,7 +125,8 @@ static int wm8350_gpio_probe(struct platform_device *pdev)
 	else
 		wm8350_gpio->gpio_chip.base = -1;
 
-	ret = gpiochip_add_data(&wm8350_gpio->gpio_chip, wm8350_gpio);
+	ret = devm_gpiochip_add_data(&pdev->dev, &wm8350_gpio->gpio_chip,
+				     wm8350_gpio);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Could not register gpiochip, %d\n", ret);
 		return ret;
@@ -136,19 +137,10 @@ static int wm8350_gpio_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int wm8350_gpio_remove(struct platform_device *pdev)
-{
-	struct wm8350_gpio_data *wm8350_gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&wm8350_gpio->gpio_chip);
-	return 0;
-}
-
 static struct platform_driver wm8350_gpio_driver = {
 	.driver.name	= "wm8350-gpio",
 	.driver.owner	= THIS_MODULE,
 	.probe		= wm8350_gpio_probe,
-	.remove		= wm8350_gpio_remove,
 };
 
 static int __init wm8350_gpio_init(void)
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:48 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:48 +0530
Subject: [PATCH 59/61] gpio: wm8994: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-60-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: patches at opensource.wolfsonmicro.com
---
 drivers/gpio/gpio-wm8994.c | 17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/gpio/gpio-wm8994.c b/drivers/gpio/gpio-wm8994.c
index 3ae4c15..b089df9 100644
--- a/drivers/gpio/gpio-wm8994.c
+++ b/drivers/gpio/gpio-wm8994.c
@@ -261,34 +261,23 @@ static int wm8994_gpio_probe(struct platform_device *pdev)
 	else
 		wm8994_gpio->gpio_chip.base = -1;
 
-	ret = gpiochip_add_data(&wm8994_gpio->gpio_chip, wm8994_gpio);
+	ret = devm_gpiochip_add_data(&pdev->dev, &wm8994_gpio->gpio_chip,
+				     wm8994_gpio);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Could not register gpiochip, %d\n",
 			ret);
-		goto err;
+		return ret;
 	}
 
 	platform_set_drvdata(pdev, wm8994_gpio);
 
 	return ret;
-
-err:
-	return ret;
-}
-
-static int wm8994_gpio_remove(struct platform_device *pdev)
-{
-	struct wm8994_gpio *wm8994_gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&wm8994_gpio->gpio_chip);
-	return 0;
 }
 
 static struct platform_driver wm8994_gpio_driver = {
 	.driver.name	= "wm8994-gpio",
 	.driver.owner	= THIS_MODULE,
 	.probe		= wm8994_gpio_probe,
-	.remove		= wm8994_gpio_remove,
 };
 
 static int __init wm8994_gpio_init(void)
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:07:53 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:37:53 +0530
Subject: [PATCH 04/61] gpio: 74xx-mmio: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-5-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
call for gpiochip_remove() from error path.

Also remove the need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Alexander Shiyan <shc_work at mail.ru>
---
 drivers/gpio/gpio-74xx-mmio.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-74xx-mmio.c b/drivers/gpio/gpio-74xx-mmio.c
index 372b0e0..0475e8e 100644
--- a/drivers/gpio/gpio-74xx-mmio.c
+++ b/drivers/gpio/gpio-74xx-mmio.c
@@ -140,15 +140,7 @@ static int mmio_74xx_gpio_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, priv);
 
-	return gpiochip_add_data(&priv->gc, priv);
-}
-
-static int mmio_74xx_gpio_remove(struct platform_device *pdev)
-{
-	struct mmio_74xx_gpio_priv *priv = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&priv->gc);
-	return 0;
+	return devm_gpiochip_add_data(&pdev->dev, &priv->gc, priv);
 }
 
 static struct platform_driver mmio_74xx_gpio_driver = {
@@ -157,7 +149,6 @@ static struct platform_driver mmio_74xx_gpio_driver = {
 		.of_match_table	= mmio_74xx_gpio_ids,
 	},
 	.probe	= mmio_74xx_gpio_probe,
-	.remove	= mmio_74xx_gpio_remove,
 };
 module_platform_driver(mmio_74xx_gpio_driver);
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:11 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:11 +0530
Subject: [PATCH 22/61] gpio: iop: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-23-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-iop.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-iop.c b/drivers/gpio/gpio-iop.c
index fb65e58..860c535 100644
--- a/drivers/gpio/gpio-iop.c
+++ b/drivers/gpio/gpio-iop.c
@@ -114,7 +114,7 @@ static int iop3xx_gpio_probe(struct platform_device *pdev)
 	if (IS_ERR(base))
 		return PTR_ERR(base);
 
-	return gpiochip_add_data(&iop3xx_chip, NULL);
+	return devm_gpiochip_add_data(&pdev->dev, &iop3xx_chip, NULL);
 }
 
 static struct platform_driver iop3xx_gpio_driver = {
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:21 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:21 +0530
Subject: [PATCH 32/61] gpio: octeon: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-33-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-octeon.c | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpio/gpio-octeon.c b/drivers/gpio/gpio-octeon.c
index 7665ebc..47aead1 100644
--- a/drivers/gpio/gpio-octeon.c
+++ b/drivers/gpio/gpio-octeon.c
@@ -117,7 +117,7 @@ static int octeon_gpio_probe(struct platform_device *pdev)
 	chip->get = octeon_gpio_get;
 	chip->direction_output = octeon_gpio_dir_out;
 	chip->set = octeon_gpio_set;
-	err = gpiochip_add_data(chip, gpio);
+	err = devm_gpiochip_add_data(&pdev->dev, chip, gpio);
 	if (err)
 		goto out;
 
@@ -126,13 +126,6 @@ out:
 	return err;
 }
 
-static int octeon_gpio_remove(struct platform_device *pdev)
-{
-	struct gpio_chip *chip = dev_get_platdata(&pdev->dev);
-	gpiochip_remove(chip);
-	return 0;
-}
-
 static struct of_device_id octeon_gpio_match[] = {
 	{
 		.compatible = "cavium,octeon-3860-gpio",
@@ -147,7 +140,6 @@ static struct platform_driver octeon_gpio_driver = {
 		.of_match_table = octeon_gpio_match,
 	},
 	.probe		= octeon_gpio_probe,
-	.remove		= octeon_gpio_remove,
 };
 
 module_platform_driver(octeon_gpio_driver);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:23 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:23 +0530
Subject: [PATCH 34/61] gpio: pcf857x: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-35-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and clean the
error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-pcf857x.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 709cd3f..169c09a 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -372,7 +372,7 @@ static int pcf857x_probe(struct i2c_client *client,
 	gpio->out = ~n_latch;
 	gpio->status = gpio->out;
 
-	status = gpiochip_add_data(&gpio->chip, gpio);
+	status = devm_gpiochip_add_data(&client->dev, &gpio->chip, gpio);
 	if (status < 0)
 		goto fail;
 
@@ -383,7 +383,7 @@ static int pcf857x_probe(struct i2c_client *client,
 					      IRQ_TYPE_NONE);
 		if (status) {
 			dev_err(&client->dev, "cannot add irqchip\n");
-			goto fail_irq;
+			goto fail;
 		}
 
 		status = devm_request_threaded_irq(&client->dev, client->irq,
@@ -391,7 +391,7 @@ static int pcf857x_probe(struct i2c_client *client,
 					IRQF_TRIGGER_FALLING | IRQF_SHARED,
 					dev_name(&client->dev), gpio);
 		if (status)
-			goto fail_irq;
+			goto fail;
 
 		gpiochip_set_chained_irqchip(&gpio->chip, &pcf857x_irq_chip,
 					     client->irq, NULL);
@@ -413,9 +413,6 @@ static int pcf857x_probe(struct i2c_client *client,
 
 	return 0;
 
-fail_irq:
-	gpiochip_remove(&gpio->chip);
-
 fail:
 	dev_dbg(&client->dev, "probe error %d for '%s'\n", status,
 		client->name);
@@ -440,7 +437,6 @@ static int pcf857x_remove(struct i2c_client *client)
 		}
 	}
 
-	gpiochip_remove(&gpio->chip);
 	return status;
 }
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:24 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:24 +0530
Subject: [PATCH 35/61] gpio: palmas: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-36-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-palmas.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-palmas.c b/drivers/gpio/gpio-palmas.c
index fdfb3b1..6f27b3d 100644
--- a/drivers/gpio/gpio-palmas.c
+++ b/drivers/gpio/gpio-palmas.c
@@ -195,7 +195,8 @@ static int palmas_gpio_probe(struct platform_device *pdev)
 	else
 		palmas_gpio->gpio_chip.base = -1;
 
-	ret = gpiochip_add_data(&palmas_gpio->gpio_chip, palmas_gpio);
+	ret = devm_gpiochip_add_data(&pdev->dev, &palmas_gpio->gpio_chip,
+				     palmas_gpio);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Could not register gpiochip, %d\n", ret);
 		return ret;
@@ -205,20 +206,11 @@ static int palmas_gpio_probe(struct platform_device *pdev)
 	return ret;
 }
 
-static int palmas_gpio_remove(struct platform_device *pdev)
-{
-	struct palmas_gpio *palmas_gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&palmas_gpio->gpio_chip);
-	return 0;
-}
-
 static struct platform_driver palmas_gpio_driver = {
 	.driver.name	= "palmas-gpio",
 	.driver.owner	= THIS_MODULE,
 	.driver.of_match_table = of_palmas_gpio_match,
 	.probe		= palmas_gpio_probe,
-	.remove		= palmas_gpio_remove,
 };
 
 static int __init palmas_gpio_init(void)
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:25 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:25 +0530
Subject: [PATCH 36/61] gpio: rc5t583: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-37-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-rc5t583.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-rc5t583.c b/drivers/gpio/gpio-rc5t583.c
index 1e2d210..1d6100f 100644
--- a/drivers/gpio/gpio-rc5t583.c
+++ b/drivers/gpio/gpio-rc5t583.c
@@ -136,15 +136,8 @@ static int rc5t583_gpio_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, rc5t583_gpio);
 
-	return gpiochip_add_data(&rc5t583_gpio->gpio_chip, rc5t583_gpio);
-}
-
-static int rc5t583_gpio_remove(struct platform_device *pdev)
-{
-	struct rc5t583_gpio *rc5t583_gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&rc5t583_gpio->gpio_chip);
-	return 0;
+	return devm_gpiochip_add_data(&pdev->dev, &rc5t583_gpio->gpio_chip,
+				      rc5t583_gpio);
 }
 
 static struct platform_driver rc5t583_gpio_driver = {
@@ -152,7 +145,6 @@ static struct platform_driver rc5t583_gpio_driver = {
 		.name    = "rc5t583-gpio",
 	},
 	.probe		= rc5t583_gpio_probe,
-	.remove		= rc5t583_gpio_remove,
 };
 
 static int __init rc5t583_gpio_init(void)
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:26 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:26 +0530
Subject: [PATCH 37/61] gpio: rdc321x: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-38-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-rdc321x.c | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/gpio/gpio-rdc321x.c b/drivers/gpio/gpio-rdc321x.c
index 96ddee3..ec945b9 100644
--- a/drivers/gpio/gpio-rdc321x.c
+++ b/drivers/gpio/gpio-rdc321x.c
@@ -194,23 +194,14 @@ static int rdc321x_gpio_probe(struct platform_device *pdev)
 
 	dev_info(&pdev->dev, "registering %d GPIOs\n",
 					rdc321x_gpio_dev->chip.ngpio);
-	return gpiochip_add_data(&rdc321x_gpio_dev->chip, rdc321x_gpio_dev);
-}
-
-static int rdc321x_gpio_remove(struct platform_device *pdev)
-{
-	struct rdc321x_gpio *rdc321x_gpio_dev = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&rdc321x_gpio_dev->chip);
-
-	return 0;
+	return devm_gpiochip_add_data(&pdev->dev, &rdc321x_gpio_dev->chip,
+				      rdc321x_gpio_dev);
 }
 
 static struct platform_driver rdc321x_gpio_driver = {
 	.driver.name	= "rdc321x-gpio",
 	.driver.owner	= THIS_MODULE,
 	.probe		= rdc321x_gpio_probe,
-	.remove		= rdc321x_gpio_remove,
 };
 
 module_platform_driver(rdc321x_gpio_driver);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:27 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:27 +0530
Subject: [PATCH 38/61] gpio: sch: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-39-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-sch.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
index 5314ee4..e85e753 100644
--- a/drivers/gpio/gpio-sch.c
+++ b/drivers/gpio/gpio-sch.c
@@ -215,15 +215,7 @@ static int sch_gpio_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, sch);
 
-	return gpiochip_add_data(&sch->chip, sch);
-}
-
-static int sch_gpio_remove(struct platform_device *pdev)
-{
-	struct sch_gpio *sch = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&sch->chip);
-	return 0;
+	return devm_gpiochip_add_data(&pdev->dev, &sch->chip, sch);
 }
 
 static struct platform_driver sch_gpio_driver = {
@@ -231,7 +223,6 @@ static struct platform_driver sch_gpio_driver = {
 		.name = "sch_gpio",
 	},
 	.probe		= sch_gpio_probe,
-	.remove		= sch_gpio_remove,
 };
 
 module_platform_driver(sch_gpio_driver);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:28 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:28 +0530
Subject: [PATCH 39/61] gpio: spear-spics: Use devm_gpiochip_add_data() for
 gpio registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-40-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-spear-spics.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-spear-spics.c b/drivers/gpio/gpio-spear-spics.c
index 50fb090..7ffd164 100644
--- a/drivers/gpio/gpio-spear-spics.c
+++ b/drivers/gpio/gpio-spear-spics.c
@@ -165,7 +165,7 @@ static int spics_gpio_probe(struct platform_device *pdev)
 	spics->chip.owner = THIS_MODULE;
 	spics->last_off = -1;
 
-	ret = gpiochip_add_data(&spics->chip, spics);
+	ret = devm_gpiochip_add_data(&pdev->dev, &spics->chip, spics);
 	if (ret) {
 		dev_err(&pdev->dev, "unable to add gpio chip\n");
 		return ret;
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:29 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:29 +0530
Subject: [PATCH 40/61] gpio: sta2x11: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-41-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-sta2x11.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-sta2x11.c b/drivers/gpio/gpio-sta2x11.c
index 83af1cb..0d5b8c5 100644
--- a/drivers/gpio/gpio-sta2x11.c
+++ b/drivers/gpio/gpio-sta2x11.c
@@ -409,7 +409,7 @@ static int gsta_probe(struct platform_device *dev)
 		goto err_free_descs;
 	}
 
-	err = gpiochip_add_data(&chip->gpio, chip);
+	err = devm_gpiochip_add_data(&dev->dev, &chip->gpio, chip);
 	if (err < 0) {
 		dev_err(&dev->dev, "sta2x11 gpio: Can't register (%i)\n",
 			-err);
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:30 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:30 +0530
Subject: [PATCH 41/61] gpio: stp-xway: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-42-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-stp-xway.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-stp-xway.c b/drivers/gpio/gpio-stp-xway.c
index d11dd48..19e654f 100644
--- a/drivers/gpio/gpio-stp-xway.c
+++ b/drivers/gpio/gpio-stp-xway.c
@@ -258,7 +258,7 @@ static int xway_stp_probe(struct platform_device *pdev)
 
 	ret = xway_stp_hw_init(chip);
 	if (!ret)
-		ret = gpiochip_add_data(&chip->gc, chip);
+		ret = devm_gpiochip_add_data(&pdev->dev, &chip->gc, chip);
 
 	if (!ret)
 		dev_info(&pdev->dev, "Init done\n");
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:31 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:31 +0530
Subject: [PATCH 42/61] gpio: sx150x: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-43-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-sx150x.c | 18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/drivers/gpio/gpio-sx150x.c b/drivers/gpio/gpio-sx150x.c
index e6cff1c..d387eb5 100644
--- a/drivers/gpio/gpio-sx150x.c
+++ b/drivers/gpio/gpio-sx150x.c
@@ -687,7 +687,7 @@ static int sx150x_probe(struct i2c_client *client,
 	if (rc < 0)
 		return rc;
 
-	rc = gpiochip_add_data(&chip->gpio_chip, chip);
+	rc = devm_gpiochip_add_data(&client->dev, &chip->gpio_chip, chip);
 	if (rc)
 		return rc;
 
@@ -696,25 +696,12 @@ static int sx150x_probe(struct i2c_client *client,
 					pdata->irq_summary,
 					pdata->irq_base);
 		if (rc < 0)
-			goto probe_fail_post_gpiochip_add;
+			return rc;
 	}
 
 	i2c_set_clientdata(client, chip);
 
 	return 0;
-probe_fail_post_gpiochip_add:
-	gpiochip_remove(&chip->gpio_chip);
-	return rc;
-}
-
-static int sx150x_remove(struct i2c_client *client)
-{
-	struct sx150x_chip *chip;
-
-	chip = i2c_get_clientdata(client);
-	gpiochip_remove(&chip->gpio_chip);
-
-	return 0;
 }
 
 static struct i2c_driver sx150x_driver = {
@@ -723,7 +710,6 @@ static struct i2c_driver sx150x_driver = {
 		.of_match_table = of_match_ptr(sx150x_of_match),
 	},
 	.probe    = sx150x_probe,
-	.remove   = sx150x_remove,
 	.id_table = sx150x_id,
 };
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:32 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:32 +0530
Subject: [PATCH 43/61] gpio: syscon: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-44-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-syscon.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-syscon.c b/drivers/gpio/gpio-syscon.c
index e5c5b62..24b6d64 100644
--- a/drivers/gpio/gpio-syscon.c
+++ b/drivers/gpio/gpio-syscon.c
@@ -238,15 +238,7 @@ static int syscon_gpio_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, priv);
 
-	return gpiochip_add_data(&priv->chip, priv);
-}
-
-static int syscon_gpio_remove(struct platform_device *pdev)
-{
-	struct syscon_gpio_priv *priv = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&priv->chip);
-	return 0;
+	return devm_gpiochip_add_data(&pdev->dev, &priv->chip, priv);
 }
 
 static struct platform_driver syscon_gpio_driver = {
@@ -255,7 +247,6 @@ static struct platform_driver syscon_gpio_driver = {
 		.of_match_table	= syscon_gpio_ids,
 	},
 	.probe	= syscon_gpio_probe,
-	.remove	= syscon_gpio_remove,
 };
 module_platform_driver(syscon_gpio_driver);
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:33 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:33 +0530
Subject: [PATCH 44/61] gpio: tb10x: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-45-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and clean the
error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-tb10x.c | 22 ++++++----------------
 1 file changed, 6 insertions(+), 16 deletions(-)

diff --git a/drivers/gpio/gpio-tb10x.c b/drivers/gpio/gpio-tb10x.c
index 5eaec20..80b6959a 100644
--- a/drivers/gpio/gpio-tb10x.c
+++ b/drivers/gpio/gpio-tb10x.c
@@ -205,10 +205,10 @@ static int tb10x_gpio_probe(struct platform_device *pdev)
 	tb10x_gpio->gc.can_sleep	= false;
 
 
-	ret = gpiochip_add_data(&tb10x_gpio->gc, tb10x_gpio);
+	ret = devm_gpiochip_add_data(&pdev->dev, &tb10x_gpio->gc, tb10x_gpio);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Could not add gpiochip.\n");
-		goto fail_gpiochip_registration;
+		return ret;
 	}
 
 	platform_set_drvdata(pdev, tb10x_gpio);
@@ -219,7 +219,7 @@ static int tb10x_gpio_probe(struct platform_device *pdev)
 		ret = platform_get_irq(pdev, 0);
 		if (ret < 0) {
 			dev_err(&pdev->dev, "No interrupt specified.\n");
-			goto fail_get_irq;
+			return ret;
 		}
 
 		tb10x_gpio->gc.to_irq	= tb10x_gpio_to_irq;
@@ -229,14 +229,13 @@ static int tb10x_gpio_probe(struct platform_device *pdev)
 				IRQF_TRIGGER_NONE | IRQF_SHARED,
 				dev_name(&pdev->dev), tb10x_gpio);
 		if (ret != 0)
-			goto fail_request_irq;
+			return ret;
 
 		tb10x_gpio->domain = irq_domain_add_linear(dn,
 						tb10x_gpio->gc.ngpio,
 						&irq_generic_chip_ops, NULL);
 		if (!tb10x_gpio->domain) {
-			ret = -ENOMEM;
-			goto fail_irq_domain;
+			return -ENOMEM;
 		}
 
 		ret = irq_alloc_domain_generic_chips(tb10x_gpio->domain,
@@ -244,7 +243,7 @@ static int tb10x_gpio_probe(struct platform_device *pdev)
 				handle_edge_irq, IRQ_NOREQUEST, IRQ_NOPROBE,
 				IRQ_GC_INIT_MASK_CACHE);
 		if (ret)
-			goto fail_irq_domain;
+			return ret;
 
 		gc = tb10x_gpio->domain->gc->gc[0];
 		gc->reg_base                         = tb10x_gpio->base;
@@ -258,14 +257,6 @@ static int tb10x_gpio_probe(struct platform_device *pdev)
 	}
 
 	return 0;
-
-fail_irq_domain:
-fail_request_irq:
-fail_get_irq:
-	gpiochip_remove(&tb10x_gpio->gc);
-fail_gpiochip_registration:
-fail_ioremap:
-	return ret;
 }
 
 static int tb10x_gpio_remove(struct platform_device *pdev)
@@ -278,7 +269,6 @@ static int tb10x_gpio_remove(struct platform_device *pdev)
 		kfree(tb10x_gpio->domain->gc);
 		irq_domain_remove(tb10x_gpio->domain);
 	}
-	gpiochip_remove(&tb10x_gpio->gc);
 
 	return 0;
 }
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:34 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:34 +0530
Subject: [PATCH 45/61] gpio: tc3589x: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-46-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-tc3589x.c | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/gpio/gpio-tc3589x.c b/drivers/gpio/gpio-tc3589x.c
index 05a27ec..4f566e6 100644
--- a/drivers/gpio/gpio-tc3589x.c
+++ b/drivers/gpio/gpio-tc3589x.c
@@ -272,7 +272,8 @@ static int tc3589x_gpio_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	ret = gpiochip_add_data(&tc3589x_gpio->chip, tc3589x_gpio);
+	ret = devm_gpiochip_add_data(&pdev->dev, &tc3589x_gpio->chip,
+				     tc3589x_gpio);
 	if (ret) {
 		dev_err(&pdev->dev, "unable to add gpiochip: %d\n", ret);
 		return ret;
@@ -299,20 +300,10 @@ static int tc3589x_gpio_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int tc3589x_gpio_remove(struct platform_device *pdev)
-{
-	struct tc3589x_gpio *tc3589x_gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&tc3589x_gpio->chip);
-
-	return 0;
-}
-
 static struct platform_driver tc3589x_gpio_driver = {
 	.driver.name	= "tc3589x-gpio",
 	.driver.owner	= THIS_MODULE,
 	.probe		= tc3589x_gpio_probe,
-	.remove		= tc3589x_gpio_remove,
 };
 
 static int __init tc3589x_gpio_init(void)
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:35 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:35 +0530
Subject: [PATCH 46/61] gpio: tegra: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-47-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Stephen Warren <swarren at wwwdotorg.org>
Cc: Thierry Reding <thierry.reding at gmail.com>
---
 drivers/gpio/gpio-tegra.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index 9a1a7e2..790bb11 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -545,7 +545,7 @@ static int tegra_gpio_probe(struct platform_device *pdev)
 
 	tegra_gpio_chip.of_node = pdev->dev.of_node;
 
-	ret = gpiochip_add_data(&tegra_gpio_chip, NULL);
+	ret = devm_gpiochip_add_data(&pdev->dev, &tegra_gpio_chip, NULL);
 	if (ret < 0) {
 		irq_domain_remove(irq_domain);
 		return ret;
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:38 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:38 +0530
Subject: [PATCH 49/61] gpio: tps65910: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-50-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-tps65910.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-tps65910.c b/drivers/gpio/gpio-tps65910.c
index e81eee7..cdbd7c7 100644
--- a/drivers/gpio/gpio-tps65910.c
+++ b/drivers/gpio/gpio-tps65910.c
@@ -170,7 +170,8 @@ static int tps65910_gpio_probe(struct platform_device *pdev)
 	}
 
 skip_init:
-	ret = gpiochip_add_data(&tps65910_gpio->gpio_chip, tps65910_gpio);
+	ret = devm_gpiochip_add_data(&pdev->dev, &tps65910_gpio->gpio_chip,
+				     tps65910_gpio);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Could not register gpiochip, %d\n", ret);
 		return ret;
@@ -181,19 +182,10 @@ skip_init:
 	return ret;
 }
 
-static int tps65910_gpio_remove(struct platform_device *pdev)
-{
-	struct tps65910_gpio *tps65910_gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&tps65910_gpio->gpio_chip);
-	return 0;
-}
-
 static struct platform_driver tps65910_gpio_driver = {
 	.driver.name    = "tps65910-gpio",
 	.driver.owner   = THIS_MODULE,
 	.probe		= tps65910_gpio_probe,
-	.remove		= tps65910_gpio_remove,
 };
 
 static int __init tps65910_gpio_init(void)
-- 
2.1.4



From ard.biesheuvel at linaro.org  Mon Feb 22 06:25:53 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 15:25:53 +0100
Subject: [PATCH 0/5] memory attribute table support
Message-ID: <1456151158-25849-1-git-send-email-ard.biesheuvel@linaro.org>

This implements ARM/arm64 support for dealing with the UEFI memory attribute
table, which allows the OS to map UEFI Runtime Services regions with stricter
permissions.

I have tried to implement the early discovery and validation of the table
as generically as possible. I think it should be reusable on x86 as well,
but I haven't tried myself. Note that this also depends on the way we
deal with the reservation of BootServicesData regions goind forward.

Note that for 32-bit ARM, this depends on [1], which addresses an issue
with memremap() on that architecture

Patches #1 and #2 implement support for the EFI_MEMORY_RO and EFI_MEMORY_XP
attributes, and as it turns out, this code supports both the (obsolete)
PropertiesTable and the new Memory Attributes table, so I moved them to the
beginning of the series.

Patch #3 adds the GUID and type definitions for the memory attributes table.

Patch #4 implements the generic handling of the table.

Patch #5 wires it up for ARM and arm64.

[1] http://thread.gmane.org/gmane.linux.kernel/2157907

Ard Biesheuvel (5):
  ARM: efi: apply strict permissons for UEFI Runtime Services regions
  arm64: efi: apply strict permissons for UEFI Runtime Services regions
  efi: add support for the EFI_MEMORY_ATTRIBUTES_TABLE config table
  efi: implement generic support for the Memory Attributes table
  arm*: efi: take the Memory Attributes table into account

 arch/arm/include/asm/efi.h         |   1 +
 arch/arm/kernel/efi.c              |  41 ++++++
 arch/arm64/include/asm/efi.h       |   2 +
 arch/arm64/kernel/efi.c            |  27 +++-
 drivers/firmware/efi/Makefile      |   2 +-
 drivers/firmware/efi/arm-init.c    |   1 +
 drivers/firmware/efi/arm-runtime.c |   3 +
 drivers/firmware/efi/efi.c         |   2 +
 drivers/firmware/efi/memattr.c     | 137 ++++++++++++++++++++
 include/linux/efi.h                |  19 +++
 10 files changed, 229 insertions(+), 6 deletions(-)
 create mode 100644 drivers/firmware/efi/memattr.c

-- 
2.5.0



From ldewangan at nvidia.com  Mon Feb 22 06:08:36 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:36 +0530
Subject: [PATCH 47/61] gpio: timberdale Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-48-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-timberdale.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-timberdale.c b/drivers/gpio/gpio-timberdale.c
index a6de10c..f0164ec 100644
--- a/drivers/gpio/gpio-timberdale.c
+++ b/drivers/gpio/gpio-timberdale.c
@@ -279,7 +279,7 @@ static int timbgpio_probe(struct platform_device *pdev)
 	gc->ngpio = pdata->nr_pins;
 	gc->can_sleep = false;
 
-	err = gpiochip_add_data(gc, tgpio);
+	err = devm_gpiochip_add_data(&pdev->dev, gc, tgpio);
 	if (err)
 		return err;
 
@@ -320,8 +320,6 @@ static int timbgpio_remove(struct platform_device *pdev)
 		irq_set_handler_data(irq, NULL);
 	}
 
-	gpiochip_remove(&tgpio->gpio);
-
 	return 0;
 }
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:49 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:49 +0530
Subject: [PATCH 60/61] gpio: xgene-sb: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-61-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-xgene-sb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-xgene-sb.c b/drivers/gpio/gpio-xgene-sb.c
index 282004d..e665770 100644
--- a/drivers/gpio/gpio-xgene-sb.c
+++ b/drivers/gpio/gpio-xgene-sb.c
@@ -116,7 +116,7 @@ static int xgene_gpio_sb_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, priv);
 
-	ret = gpiochip_add_data(&priv->gc, priv);
+	ret = devm_gpiochip_add_data(&pdev->dev, &priv->gc, priv);
 	if (ret)
 		dev_err(&pdev->dev, "failed to register X-Gene GPIO Standby driver\n");
 	else
@@ -138,7 +138,6 @@ static int xgene_gpio_sb_remove(struct platform_device *pdev)
 		acpi_gpiochip_free_interrupts(&priv->gc);
 	}
 
-	gpiochip_remove(&priv->gc);
 	return 0;
 }
 
-- 
2.1.4



From ldewangan at nvidia.com  Mon Feb 22 06:08:50 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Mon, 22 Feb 2016 19:38:50 +0530
Subject: [PATCH 61/61] gpio: xgene: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456150130-2668-62-git-send-email-ldewangan@nvidia.com>

Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/gpio/gpio-xgene.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-xgene.c b/drivers/gpio/gpio-xgene.c
index 592e9cd..c0aa387 100644
--- a/drivers/gpio/gpio-xgene.c
+++ b/drivers/gpio/gpio-xgene.c
@@ -193,7 +193,7 @@ static int xgene_gpio_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, gpio);
 
-	err = gpiochip_add_data(&gpio->chip, gpio);
+	err = devm_gpiochip_add_data(&pdev->dev, &gpio->chip, gpio);
 	if (err) {
 		dev_err(&pdev->dev,
 			"failed to register gpiochip.\n");
@@ -207,14 +207,6 @@ err:
 	return err;
 }
 
-static int xgene_gpio_remove(struct platform_device *pdev)
-{
-	struct xgene_gpio *gpio = platform_get_drvdata(pdev);
-
-	gpiochip_remove(&gpio->chip);
-	return 0;
-}
-
 static const struct of_device_id xgene_gpio_of_match[] = {
 	{ .compatible = "apm,xgene-gpio", },
 	{},
@@ -228,7 +220,6 @@ static struct platform_driver xgene_gpio_driver = {
 		.pm     = XGENE_GPIO_PM_OPS,
 	},
 	.probe = xgene_gpio_probe,
-	.remove = xgene_gpio_remove,
 };
 
 module_platform_driver(xgene_gpio_driver);
-- 
2.1.4



From ard.biesheuvel at linaro.org  Mon Feb 22 06:29:14 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 15:29:14 +0100
Subject: [PATCH 4/5] efi: implement generic support for the Memory Attributes
 table
In-Reply-To: <1456151158-25849-4-git-send-email-ard.biesheuvel@linaro.org>
References: <1456151158-25849-4-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456151355-25943-1-git-send-email-ard.biesheuvel@linaro.org>

This implements shared support for discovering the presence of the
Memory Attributes table, and for parsing and validating its contents.

The table is validated against the construction rules in the UEFI spec.
Since this is a new table, it makes sense to complain if we encounter
a table that does not follow those rules.

The parsing and validation routine takes a callback that can be specified
per architecture, that gets passed each unique validated region, with the
virtual address retrieved from the ordinary memory map.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 drivers/firmware/efi/Makefile  |   2 +-
 drivers/firmware/efi/memattr.c | 137 ++++++++++++++++++++
 include/linux/efi.h            |   6 +
 3 files changed, 144 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
index 62e654f255f4..d5be62399130 100644
--- a/drivers/firmware/efi/Makefile
+++ b/drivers/firmware/efi/Makefile
@@ -9,7 +9,7 @@
 #
 KASAN_SANITIZE_runtime-wrappers.o	:= n
 
-obj-$(CONFIG_EFI)			+= efi.o vars.o reboot.o
+obj-$(CONFIG_EFI)			+= efi.o vars.o reboot.o memattr.o
 obj-$(CONFIG_EFI_VARS)			+= efivars.o
 obj-$(CONFIG_EFI_ESRT)			+= esrt.o
 obj-$(CONFIG_EFI_VARS_PSTORE)		+= efi-pstore.o
diff --git a/drivers/firmware/efi/memattr.c b/drivers/firmware/efi/memattr.c
new file mode 100644
index 000000000000..059cf4522a7d
--- /dev/null
+++ b/drivers/firmware/efi/memattr.c
@@ -0,0 +1,137 @@
+/*
+ * Copyright (C) 2016 Linaro Ltd. <ard.biesheuvel at linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/efi.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/memblock.h>
+
+#include <asm/early_ioremap.h>
+
+static int __initdata tbl_size;
+
+/*
+ * Reserve the memory associated with the Memory Attributes configuration
+ * table, if it exists.
+ */
+int __init efi_memattr_init(void)
+{
+	efi_memory_attributes_table_t *tbl;
+
+	if (efi.mem_attr_table == EFI_INVALID_TABLE_ADDR)
+		return 0;
+
+	tbl = early_memremap(efi.mem_attr_table, sizeof(*tbl));
+	if (!tbl) {
+		pr_err("Failed to map EFI Memory Attribute table @ 0x%lx\n",
+		       efi.mem_attr_table);
+		return -ENOMEM;
+	}
+
+	tbl_size = sizeof(*tbl) + tbl->num_entries * tbl->desc_size;
+	memblock_reserve(efi.mem_attr_table, tbl_size);
+	early_memunmap(tbl, sizeof(*tbl));
+	return 0;
+}
+
+/*
+ * Returns a copy @out of the UEFI memory descriptor @in if it is covered
+ * entirely by a UEFI memory map entry with matching attributes. The virtual
+ * address of @out is set according to the matching entry that was found.
+ */
+static bool validate_entry(const efi_memory_desc_t *in, efi_memory_desc_t *out)
+{
+	u64 in_paddr = in->phys_addr;
+	u64 in_size = in->num_pages << EFI_PAGE_SHIFT;
+	efi_memory_desc_t *md;
+
+	if (in->type != EFI_RUNTIME_SERVICES_CODE &&
+	    in->type != EFI_RUNTIME_SERVICES_DATA) {
+		pr_warn("MEMATTR table entry type should be RuntimeServiceCode or RuntimeServicesData\n");
+		return false;
+	}
+	if (!(in->attribute & (EFI_MEMORY_RO | EFI_MEMORY_XP))) {
+		pr_warn("MEMATTR table entry attributes invalid: RO and XP bits both cleared\n");
+		return false;
+	}
+	if (PAGE_SIZE > EFI_PAGE_SIZE &&
+	    (!PAGE_ALIGNED(in->phys_addr) ||
+	     !PAGE_ALIGNED(in->num_pages << EFI_PAGE_SHIFT))) {
+		pr_warn("MEMATTR table entry misaligned\n");
+		return false;
+	}
+	for_each_efi_memory_desc(&memmap, md) {
+		u64 md_paddr = md->phys_addr;
+		u64 md_size = md->num_pages << EFI_PAGE_SHIFT;
+
+		if (!(md->attribute & EFI_MEMORY_RUNTIME))
+			continue;
+		if (md->virt_addr == 0)
+			/* no virtual mapping has been installed by the stub */
+			break;
+		if (md_paddr <= in_paddr && (in_paddr - md_paddr) < md_size) {
+			/*
+			 * This entry covers the start of @in, check whether
+			 * it covers the end as well.
+			 */
+			if (md_paddr + md_size < in_paddr + in_size) {
+				pr_warn("MEMATTR table entry covers multiple UEFI memory map regions\n");
+				return false;
+			}
+			if (md->type != in->type) {
+				pr_warn("MEMATTR table entry type deviates from UEFI memory map region type\n");
+				return false;
+			}
+			*out = *in;
+			out->virt_addr = in_paddr +
+					 (md->virt_addr - md->phys_addr);
+			return true;
+		}
+	}
+	return false;
+}
+
+int __init efi_memattr_apply_permissions(struct mm_struct *mm,
+					 efi_memattr_perm_setter fn)
+{
+	efi_memory_attributes_table_t *tbl;
+	int i, ret;
+
+	if (tbl_size <= sizeof(*tbl))
+		return 0;
+
+	tbl = memremap(efi.mem_attr_table, tbl_size, MEMREMAP_WB);
+	if (!tbl) {
+		pr_err("Failed to map EFI Memory Attribute table @ 0x%lx\n",
+		       efi.mem_attr_table);
+		return -ENOMEM;
+	}
+
+	if (efi_enabled(EFI_DBG))
+		pr_info("Processing UEFI Memory Attributes table:\n");
+
+	for (i = ret = 0; ret == 0 && i < tbl->num_entries; i++) {
+		efi_memory_desc_t md;
+		unsigned long size;
+		bool valid;
+		char buf[64];
+
+		valid = validate_entry((void *)tbl->entry + i * tbl->desc_size,
+				       &md);
+		size = md.num_pages << EFI_PAGE_SHIFT;
+		if (efi_enabled(EFI_DBG) || !valid)
+			pr_info("  0x%012llx-0x%012llx %s\n", md.phys_addr,
+				md.phys_addr + size - 1,
+				efi_md_typeattr_format(buf, sizeof(buf), &md));
+
+		if (valid)
+			ret = fn(mm, &md);
+	}
+	memunmap(tbl);
+	return ret;
+}
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 808d97299c70..94e41872e5e6 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -966,6 +966,12 @@ extern void __init efi_fake_memmap(void);
 static inline void efi_fake_memmap(void) { }
 #endif
 
+typedef int (*efi_memattr_perm_setter)(struct mm_struct *, efi_memory_desc_t *);
+
+extern int efi_memattr_init(void);
+extern int efi_memattr_apply_permissions(struct mm_struct *mm,
+					 efi_memattr_perm_setter fn);
+
 /* Iterate through an efi_memory_map */
 #define for_each_efi_memory_desc(m, md)					   \
 	for ((md) = (m)->map;						   \
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 06:29:15 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 15:29:15 +0100
Subject: [PATCH 5/5] arm*: efi: take the Memory Attributes table into account
In-Reply-To: <1456151355-25943-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456151158-25849-4-git-send-email-ard.biesheuvel@linaro.org>
 <1456151355-25943-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456151355-25943-2-git-send-email-ard.biesheuvel@linaro.org>

Call into the generic memory attributes table support code at the
appropriate times during the init sequence so that the UEFI Runtime
Services region are mapped according to the strict permissions it
specifies.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/efi.h       | 2 ++
 drivers/firmware/efi/arm-init.c    | 1 +
 drivers/firmware/efi/arm-runtime.c | 3 +++
 3 files changed, 6 insertions(+)

diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index 8e88a696c9cb..4dafc89f373a 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -14,6 +14,8 @@ extern void efi_init(void);
 
 int efi_create_mapping(struct mm_struct *mm, efi_memory_desc_t *md);
 
+#define efi_set_mapping_permissions	efi_create_mapping
+
 #define efi_call_virt(f, ...)						\
 ({									\
 	efi_##f##_t *__f;						\
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index aa1f743152a2..022f11157acd 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -202,6 +202,7 @@ void __init efi_init(void)
 		return;
 
 	reserve_regions();
+	efi_memattr_init();
 	early_memunmap(memmap.map, params.mmap_size);
 	memblock_mark_nomap(params.mmap & PAGE_MASK,
 			    PAGE_ALIGN(params.mmap_size +
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 3a3911641049..848ede1587dc 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -65,6 +65,9 @@ static bool __init efi_virtmap_init(void)
 			return false;
 		}
 	}
+
+	if (efi_memattr_apply_permissions(&efi_mm, efi_set_mapping_permissions))
+		return false;
 	return true;
 }
 
-- 
2.5.0



From andrew at lunn.ch  Mon Feb 22 06:32:31 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Mon, 22 Feb 2016 15:32:31 +0100
Subject: [PATCH 01/61] gpio: Add devm_ apis for gpiochip_add_data and
 gpiochip_remove
In-Reply-To: <1456150130-2668-2-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
 <1456150130-2668-2-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160222143231.GB14970@lunn.ch>

> +/**
> + * devm_gpiochip_add_data() - Resource manager piochip_add_data()

                                                  ^
missing g.

> + * @dev: the device pointer on which irq_chip belongs to.
> + * @chip: the chip to register, with chip->base initialized
> + * Context: potentially before irqs will work
> + *
> + * Returns a negative errno if the chip can't be registered, such as
> + * because the chip->base is invalid or already associated with a
> + * different chip.  Otherwise it returns zero as a success code.
> + *
> + * The gpio chip automatically be released when the device is unbound.
                   ^
                    will

    Andrew


From aleksey.makarov at linaro.org  Mon Feb 22 06:35:00 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 22 Feb 2016 17:35:00 +0300
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <56C733FE.8070308@hurleysoftware.com>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
 <56C470C5.2080203@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>
 <56C63FB5.2030907@hurleysoftware.com> <56C6F19D.7070206@linaro.org>
 <56C733FE.8070308@hurleysoftware.com>
Message-ID: <56CB1C94.1030107@linaro.org>

On 02/19/2016 06:25 PM, Peter Hurley wrote:
> On 02/19/2016 02:42 AM, Aleksey Makarov wrote:
>> Hi Peter,
>>
>> Thank you for review.
>>
>> On 02/19/2016 01:03 AM, Peter Hurley wrote:
>>> On 02/17/2016 07:36 PM, Zheng, Lv wrote:
>>>> Hi,
>>>>
>>>>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
>>>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>>>>> early_acpi_os_unmap_memory()
>>>>>
>>>>> Hi Lv,
>>>>>
>>>>> Thank you for review.
>>>>>
>>>>> On 02/17/2016 05:51 AM, Zheng, Lv wrote:
>>>>>
>>>>> [..]
>>>>>
>>>>>>>> early_acpi_os_unmap_memory() is marked as __init because it calls
>>>>>>>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is not
>>>>> set.
>>>>>>>>
>>>>>>>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>>>>> so it is safe to call early_acpi_os_unmap_memory() from anywhere
>>>>>>>>
>>>>>>>> We need this function to be non-__init because we need access to
>>>>>>>> some tables at unpredictable time--it may be before or after
>>>>>>>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port Console
>>>>>>>> Redirection) table is needed each time a new console is registered.
>>>>>>>> It can be quite early (console_initcall) or when a module is inserted.
>>>>>>>> When this table accessed before acpi_gbl_permanent_mmap is set,
>>>>>>>> the pointer should be unmapped.  This is exactly what this function
>>>>>>>> does.
>>>>>>> [Lv Zheng]
>>>>>>> Why don't you use another API instead of early_acpi_os_unmap_memory()
>>>>> in
>>>>>>> case you want to unmap things in any cases.
>>>>>>> acpi_os_unmap_memory() should be the one to match this purpose.
>>>>>>> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
>>>>>
>>>>> As far as I understand, there exist two steps in ACPI initialization:
>>>>>
>>>>> 1. Before acpi_gbl_permanent_mmap is set, tables received with
>>>>> acpi_get_table_with_size()
>>>>>    are mapped by early_memremap().  If a subsystem gets such a pointer it
>>>>> should be unmapped.
>>>>>
>>>>> 2  After acpi_gbl_permanent_mmap is set this pointer should not be unmapped
>>>>> at all.
>>>>>
>>>> [Lv Zheng] 
>>>> This statement is wrong, this should be:
>>>> As long as there is a __reference__ to the mapped table, the pointer should not be unmapped.
>>>> In fact, we have a series to introduce acpi_put_table() to achieve this.
>>>> So your argument is wrong from very first point.
>>>>
>>>>> That exactly what early_acpi_os_unmap_memory() does--it checks
>>>>> acpi_gbl_permanent_mmap.
>>>>> If I had used acpi_os_unmap_memory() after acpi_gbl_permanent_mmap had
>>>>> been set,
>>>>> it would have tried to free that pointer with an oops (actually, I checked that
>>>>> and got that oops).
>>>>>
>>>>> So using acpi_os_unmap_memory() is not an option here, but
>>>>> early_acpi_os_unmap_memory()
>>>>> match perfectly.
>>>> [Lv Zheng] 
>>>> I don't think so.
>>>> For definition block tables, we know for sure there will always be references, until "Unload" opcode is invoked by the AML interpreter.
>>>> But for the data tables, OSPMs should use them in this way:
>>>> 1. map the table
>>>> 2. parse the table and convert it to OS specific structures
>>>> 3. unmap the table
>>>> This helps to shrink virtual memory address space usages.
>>>>
>>>> So from this point of view, all data tables should be unmapped right after being parsed.
>>>> Why do you need the map to be persistent in the kernel address space?
>>>> You can always map a small table, but what if the table size is very big?
>>>>
>>>>>
>>>>>>> And in fact early_acpi_os_unmap_memory() should be removed.
>>>>>
>>>>> I don't think so -- I have explained why.  It does different thing.
>>>>> Probably it (and/or other functions in that api) should be renamed.
>>>>>
>>>> [Lv Zheng] 
>>>> Just let me ask one more question.
>>>> eary_acpi_os_unmap_memory() is not used inside of ACPICA.
>>>> How ACPICA can work with just acpi_os_unmap_memory()?
>>>> You can check drivers/acpi/tbxxx.c.
>>>> Especially: acpi_tb_release_temp_table() and the code invoking it.
>>>>
>>>>>> [Lv Zheng]
>>>>>> One more thing is:
>>>>>> If you can't switch your driver to use acpi_os_unmap_memory() instead of
>>>>> early_acpi_os_unmap_memory(),
>>>>>> then it implies that your driver does have a defect.
>>>>>
>>>>> I still don't understand what defect, sorry.
>>>> [Lv Zheng] 
>>>> If you can't ensure this sequence for using the data tables:
>>>> 1. map the table
>>>> 2. parse the table and convert it to OS specific structure
>>>> 3. unmap the table
>>>> It implies there is a bug in the driver or a bug in the ACPI subsystem core.
>>>
>>> Exactly.
>>>
>>> The central problem here is the way Aleksey is trying to hookup a console.
>>>
>>> What should be happening in this series is:
>>> 1. early map SPCR
>>> 2. parse the SPCR table
>>> 3. call add_preferred_console() to add the SPCR console to the console table
>>> 4. unmap SPCR
>>
>> This does not work.  
>>
>> SPCR specifies address of the console, but add_preferred_console() accepts
>> name of console and its index.  There are no general method to translate address
>> to name at such an early stage.
> 
> 
> 	add_preferred_console(uart, 0, "io,0x3f8,115200");

First argument here should be (char *), the name of the console.
We can not tell it just from the SPCR ACPI table without
introducing new made up names and writting which/case that should be 
supported all the linux lifetime.

I am also not quite shure I can tell the number of tty line (the 0 argument)
just from the address.

Did you mean "uart" here?  As far as I can see, this would match the *earlycon*,
not a regular console, that is not what this patch is about.
It is about selecting regular (non-boot) consoles.

I think translating address to string and then parsing it again is not
unaceptable, but definitely worse than the approach in my patch, where
I compare it directly.

> This will start a console with the 8250 driver. I've already pointed
> this out to you in an earlier review. This is what existing firmware
> already does.
> 
> This is also the method you will use to start an earlycon from the
> DBG2 table, by additionally calling setup_earlycon().
> 
> 
>> There is another reason why I prefer to parse SPCR each time a console is registered.
>> Some consoles can be registered very early in the initialization process and
>> we have to be sure add_preferred_console() is called before that.
> 
> However, since you're not adding a preferred console until uart driver
> loads, there may already be a preferred console selected and running.
> 
> This leads to weird issues like duplicated output on the serial console
> when an earlycon is disabled by the dummy VGA/FB console then the
> serial console starts and reprints the entire boot log on the same
> terminal the earlycon already printed.

Yes, misconfigured systems often misbehave.  In this case I would
question why there is an enabled console (we rely on ACPI to enable it).
And I probably do not understand the scenario, but 
- "earlycon is disabled by the dummy VGA/FB console"
and
- "earlycon already printed"
seem a bit contradictory.

> Better just to parse both the DBG2 and SPCR tables before or at
> early param, and add_preferred_consoles then.

I still don't see why it's better, but I think I explained why it's worse.

>> Of course, I could just parse it once and cache the results, but
>> this still requires accessing SPCR before acpi_gbl_permanent_mmap
>> is set *or* after that.
>>
>>> This trivial and unobtrusive method would already have a 8250 console
>>> running via SPCR. I've already pointed this out in previous reviews.
>>>
>>> Further, the above method *will be required anyway* for the DBG2 table to
>>> start an earlycon, which I've already pointed out in previous reviews.
>>>
>>> Then to enable amba-pl011 console via ACPI, add a console match() method
>>> similar to the 8250 console match() method, univ8250_console_match().
>>
>> So are you suggesting a separate method for each possible console?
>> This is not acceptable.
> 
> All 1 of them???

DBG2 specifies these subtypes of serial drivers:

- Fully 16550-compatible
- 16550 subset compatible with DBGP Revision 1
- ARM PL011 UART
- (deprecated) ARM SBSA (2.x only) Generic UART supporting only 32-bit accesses
- ARM SBSA Generic UART
- ARM DCC
- BCM2835

So it's at least 4 (or 3, I am not sure about ARM DCC) different types and
the list is open.  We would have to support it.

> The 8250 driver already does this, so no work for you there.

"uart" is for boot console, so it is not relevant.  Or did you refer to something else?

> That leaves you needing to write a trivial match() method for just
> the amba-pl011 driver.

Yes, that's probably OK, but in my series drivers should not be modified at all.
I believe that's better.

>> Do you suggest making up separate new name (like "uart" for 8250) for each type
>> of conosole SPCR can specify?
> 
> These are the documented names of the earlycons, which you'll be using
> when you add the DGB2 table parsing.

SPCR is not about earlycons.

Thank you
Aleksey Makarov

>>> FWIW, PCI earlycon + console support was already submitted once before but
>>> never picked up by GregKH. I think I'll just grab that and re-submit so
>>> you would know what to emit for console options in the add_preferred_console().
>>
>> Please do.  Or just send a link to to that submission.
> 
> Ok, will dig through and find it.
> 
>> Do you mean the Leif Lindholm's patches:
> 
> No.
> 
>> https://lkml.kernel.org/g/1441716217-23786-1-git-send-email-leif.lindholm at linaro.org
>>
>> He did same thing as I did in my v3 exept 1) he parses ACPI tree to match device
>> (I just match SPCR against data that struct uart_port already has)
>> 2) As you are suggesting, he parses SPCR once at a predefined point in initialization.
>> And that's why his submission is RFC: he had troubles with the order of initialization.
>>
>> Thank you
>> Aleksey Makarov
>>
>>> Regards,
>>> Peter Hurley
>>>
>>>
>>>>>> There is an early bootup requirement in Linux.
>>>>>> Maps acquired during the early stage should be freed by the driver during the
>>>>> early stage.
>>>>>> And the driver should re-acquire the memory map after booting.
>>>>>
>>>>> Exactly.  That's why I use early_acpi_os_unmap_memory().  The point is that
>>>>> that code can be
>>>>> called *before* acpi_gbl_permanent_mmap is set (at early initialization of for
>>>>> example 8250 console)
>>>>> or *after* acpi_gbl_permanent_mmap is set (at insertion of a module that
>>>>> registers a console),
>>>>> We just can not tell if the received table pointer should or sould not be freed
>>>>> with early_memunmap()
>>>>> (actually __acpi_unmap_table() or whatever) without checking
>>>>> acpi_gbl_permanent_mmap,
>>>>> but that's all too low level.
>>>> [Lv Zheng] 
>>>> The driver should make sure that:
>>>> Map/unmap is paired during early stage.
>>>> For late stage, it should be another pair of map/unmap.
>>>>
>>>>>
>>>>> Another option, as you describe, is to get this pointer early, don't free it
>>>> [Lv Zheng] 
>>>> I mean you should free it early.
>>>>
>>>>> untill acpi_gbl_permanent_mmap is set, then free it (with
>>>>> early_acpi_os_unmap_memory(), that's
>>>>> ok because acpi_gbl_permanent_mmap is set in an init code), then get the
>>>>> persistent
>>>>> pointer to the table.  The problem with it is that we can not just watch
>>>>> acpi_gbl_permanent_mmap
>>>>> to catch this exact moment.  And also accessing acpi_gbl_permanent_mmap is
>>>>> not good as it probably is
>>>>> an implementation detail (i. e. too lowlevel) of the ACPI code.
>>>>> Or I probably miss what you are suggesting.
>>>>>
>>>> [Lv Zheng] 
>>>> I mean, you should:
>>>> During early stage:
>>>> acpi_os_map_memory()
>>>> Parse the table.
>>>> acpi_os_unmap_memory().
>>>>
>>>>>> This is because, during early bootup stage, there are only limited slots
>>>>> available for drivers to map memory.
>>>>>> So by changing __init to __ref here, you probably will hide many such defects.
>>>>>
>>>>> What defects?  This funcions checks acpi_gbl_permanent_mmap.
>>>>> BTW, exactly the same thing is done in the beginning of
>>>>> acpi_os_unmap_memory() and than's ok,
>>>>> that function is __ref.
>>>>>
>>>>>> And solving issues in this way doesn't seem to be an improvement.
>>>>>
>>>>> Could you please tell me where I am wrong?  I still don't understand your point.
>>>> [Lv Zheng] 
>>>> But anyway, the defect should be in ACPI subsystem core.
>>>> The cause should be the API itself - acpi_get_table().
>>>>
>>>> So I agree you can use early_acpi_os_unmap_memory() during the period the root causes are not cleaned up.
>>>> But the bottom line is: the driver need to ensure that early_acpi_os_unmap_memory() is always invoked.
>>>> As long as you can ensure this, I don't have objections for deploying early_acpi_os_unmap_memory()  for now.
>>>>
>>>> Thanks and best regards
>>>> -Lv
>>>>
>>>>>
>>>>> Thank you
>>>>> Aleksey Makarov
>>>>>
>>>>>>
>>>>>> Thanks and best regards
>>>>>> -Lv
>>>>>>
>>>>>>>
>>>>>>> Thanks and best regards
>>>>>>> -Lv
>>>>>>>
>>>>>>>>
>>>>>>>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
>>>>>>>> ---
>>>>>>>>  drivers/acpi/osl.c | 6 +++++-
>>>>>>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
>>>>>>>> index 67da6fb..8a552cd 100644
>>>>>>>> --- a/drivers/acpi/osl.c
>>>>>>>> +++ b/drivers/acpi/osl.c
>>>>>>>> @@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void *virt,
>>>>>>>> acpi_size size)
>>>>>>>>  }
>>>>>>>>  EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
>>>>>>>>
>>>>>>>> -void __init early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
>>>>>>> size)
>>>>>>>> +/*
>>>>>>>> + * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>>>>> + * so it is safe to call early_acpi_os_unmap_memory() from anywhere
>>>>>>>> + */
>>>>>>>> +void __ref early_acpi_os_unmap_memory(void __iomem *virt, acpi_size
>>>>>>> size)
>>>>>>>>  {
>>>>>>>>  	if (!acpi_gbl_permanent_mmap)
>>>>>>>>  		__acpi_unmap_table(virt, size);
>>>>>>>> --
>>>>>>>> 2.7.1
> 
> 


From ynorov at caviumnetworks.com  Mon Feb 22 06:38:52 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Mon, 22 Feb 2016 17:38:52 +0300
Subject: [PATCH 0/6] Support for systems without AArch32 state
In-Reply-To: <56CB1520.8020907@arm.com>
References: <1453980737-6126-1-git-send-email-suzuki.poulose@arm.com>
 <56CB1520.8020907@arm.com>
Message-ID: <20160222143852.GA28180@yury-N73SV>

On Mon, Feb 22, 2016 at 02:03:12PM +0000, Suzuki K. Poulose wrote:
> On 28/01/16 11:32, Suzuki K Poulose wrote:
> >This series add checks to make sure that the AArch32 state is
> >supported before we process the 32bit ID registers. Also
> >checks the same for COMPAT binary execution.
> 
> Yuri,
> 
> Could you please give this series a spin on your hardware ?
> I don't have access to system where I can test this.
> 
> Thanks
> Suzuki

Hi Suzuki,

I can test it in 3-4 days.

Yury


From rabin.vincent at axis.com  Mon Feb 22 06:41:29 2016
From: rabin.vincent at axis.com (Rabin Vincent)
Date: Mon, 22 Feb 2016 15:41:29 +0100
Subject: [PATCHv2 1/2] ARM: dma-mapping: store buffer information
Message-ID: <1456152090-18630-1-git-send-email-rabin.vincent@axis.com>

Keep a list of allocated DMA buffers so that we can store metadata in
alloc() which we later need in free().

Signed-off-by: Rabin Vincent <rabin.vincent at axis.com>
---
 arch/arm/mm/dma-mapping.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 0eca381..d8c6efc 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -42,6 +42,31 @@
 #include "dma.h"
 #include "mm.h"
 
+struct arm_dma_buffer {
+	struct list_head list;
+	void *virt;
+};
+
+static LIST_HEAD(arm_dma_bufs);
+static DEFINE_SPINLOCK(arm_dma_bufs_lock);
+
+static struct arm_dma_buffer *arm_dma_buffer_find(void *virt)
+{
+	struct arm_dma_buffer *buf, *found = NULL;
+	unsigned long flags;
+
+	spin_lock_irqsave(&arm_dma_bufs_lock, flags);
+	list_for_each_entry(buf, &arm_dma_bufs, list) {
+		if (buf->virt == virt) {
+			list_del(&buf->list);
+			found = buf;
+			break;
+		}
+	}
+	spin_unlock_irqrestore(&arm_dma_bufs_lock, flags);
+	return found;
+}
+
 /*
  * The DMA API is built upon the notion of "buffer ownership".  A buffer
  * is either exclusively owned by the CPU (and therefore may be accessed
@@ -620,6 +645,7 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
 	struct page *page = NULL;
 	void *addr;
 	bool want_vaddr;
+	struct arm_dma_buffer *buf;
 
 #ifdef CONFIG_DMA_API_DEBUG
 	u64 limit = (mask + 1) & ~mask;
@@ -633,6 +659,10 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
 	if (!mask)
 		return NULL;
 
+	buf = kzalloc(sizeof(*buf), gfp);
+	if (!buf)
+		return NULL;
+
 	if (mask < 0xffffffffULL)
 		gfp |= GFP_DMA;
 
@@ -662,8 +692,18 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
 		addr = __alloc_remap_buffer(dev, size, gfp, prot, &page,
 					    caller, want_vaddr);
 
-	if (page)
+	if (page) {
+		unsigned long flags;
+
 		*handle = pfn_to_dma(dev, page_to_pfn(page));
+		buf->virt = want_vaddr ? addr : page;
+
+		spin_lock_irqsave(&arm_dma_bufs_lock, flags);
+		list_add(&buf->list, &arm_dma_bufs);
+		spin_unlock_irqrestore(&arm_dma_bufs_lock, flags);
+	} else {
+		kfree(buf);
+	}
 
 	return want_vaddr ? addr : page;
 }
@@ -742,6 +782,11 @@ static void __arm_dma_free(struct device *dev, size_t size, void *cpu_addr,
 {
 	struct page *page = pfn_to_page(dma_to_pfn(dev, handle));
 	bool want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs);
+	struct arm_dma_buffer *buf;
+
+	buf = arm_dma_buffer_find(cpu_addr);
+	if (WARN(!buf, "Freeing invalid buffer %p\n", cpu_addr))
+		return;
 
 	size = PAGE_ALIGN(size);
 
@@ -760,6 +805,8 @@ static void __arm_dma_free(struct device *dev, size_t size, void *cpu_addr,
 		WARN_ON(irqs_disabled());
 		__free_from_contiguous(dev, page, cpu_addr, size, want_vaddr);
 	}
+
+	kfree(buf);
 }
 
 void arm_dma_free(struct device *dev, size_t size, void *cpu_addr,
-- 
2.7.0



From ivo.g.dimitrov.75 at gmail.com  Mon Feb 22 06:42:59 2016
From: ivo.g.dimitrov.75 at gmail.com (Ivaylo Dimitrov)
Date: Mon, 22 Feb 2016 16:42:59 +0200
Subject: [PATCH] ARM: dts: omap3-n900: Allow gpio keys to be disabled
In-Reply-To: <20160212215326.GD19432@atomide.com>
References: <20160212215326.GD19432@atomide.com>
Message-ID: <1456152179-12558-1-git-send-email-ivo.g.dimitrov.75@gmail.com>

Add linux,can-disable; to all gpios exported from gpio-keys driver, so
userspace can disable them

Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com>
---
 arch/arm/boot/dts/omap3-n900.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 74d8f7eb..f01a151 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -68,6 +68,7 @@
 			linux,input-type = <5>; /* EV_SW */
 			linux,code = <0x09>; /* SW_CAMERA_LENS_COVER */
 			wakeup-source;
+			linux,can-disable;
 		};
 
 		camera_focus {
@@ -75,6 +76,7 @@
 			gpios = <&gpio3 4 GPIO_ACTIVE_LOW>; /* 68 */
 			linux,code = <0x210>; /* KEY_CAMERA_FOCUS */
 			wakeup-source;
+			linux,can-disable;
 		};
 
 		camera_capture {
@@ -82,6 +84,7 @@
 			gpios = <&gpio3 5 GPIO_ACTIVE_LOW>; /* 69 */
 			linux,code = <0xd4>; /* KEY_CAMERA */
 			wakeup-source;
+			linux,can-disable;
 		};
 
 		lock_button {
@@ -89,6 +92,7 @@
 			gpios = <&gpio4 17 GPIO_ACTIVE_LOW>; /* 113 */
 			linux,code = <0x98>; /* KEY_SCREENLOCK */
 			wakeup-source;
+			linux,can-disable;
 		};
 
 		keypad_slide {
@@ -97,6 +101,7 @@
 			linux,input-type = <5>; /* EV_SW */
 			linux,code = <0x0a>; /* SW_KEYPAD_SLIDE */
 			wakeup-source;
+			linux,can-disable;
 		};
 
 		proximity_sensor {
@@ -104,6 +109,7 @@
 			gpios = <&gpio3 25 GPIO_ACTIVE_HIGH>; /* 89 */
 			linux,input-type = <5>; /* EV_SW */
 			linux,code = <0x0b>; /* SW_FRONT_PROXIMITY */
+			linux,can-disable;
 		};
 	};
 
-- 
1.9.1



From aleksey.makarov at linaro.org  Mon Feb 22 06:43:18 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 22 Feb 2016 17:43:18 +0300
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <79D370BB-B7A3-4540-B7FB-81D5806853D6@codeaurora.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
 <56C470C5.2080203@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>
 <56C63FB5.2030907@hurleysoftware.com> <56C6F19D.7070206@linaro.org>
 <56C733FE.8070308@hurleysoftware.com>
 <79D370BB-B7A3-4540-B7FB-81D5806853D6@codeaurora.org>
Message-ID: <56CB1E86.60706@linaro.org>



On 02/19/2016 08:20 PM, Christopher Covington wrote:
> 
> 
> On February 19, 2016 10:25:50 AM EST, Peter Hurley <peter at hurleysoftware.com> wrote:
>> On 02/19/2016 02:42 AM, Aleksey Makarov wrote:
>>> Hi Peter,
>>>
>>> Thank you for review.
>>>
>>> On 02/19/2016 01:03 AM, Peter Hurley wrote:
>>>> On 02/17/2016 07:36 PM, Zheng, Lv wrote:
>>>>> Hi,
>>>>>
>>>>>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
>>>>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>>>>>> early_acpi_os_unmap_memory()
>>>>>>
>>>>>> Hi Lv,
>>>>>>
>>>>>> Thank you for review.
>>>>>>
>>>>>> On 02/17/2016 05:51 AM, Zheng, Lv wrote:
>>>>>>
>>>>>> [..]
>>>>>>
>>>>>>>>> early_acpi_os_unmap_memory() is marked as __init because it
>> calls
>>>>>>>>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is
>> not
>>>>>> set.
>>>>>>>>>
>>>>>>>>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>>>>>> so it is safe to call early_acpi_os_unmap_memory() from
>> anywhere
>>>>>>>>>
>>>>>>>>> We need this function to be non-__init because we need access
>> to
>>>>>>>>> some tables at unpredictable time--it may be before or after
>>>>>>>>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port
>> Console
>>>>>>>>> Redirection) table is needed each time a new console is
>> registered.
>>>>>>>>> It can be quite early (console_initcall) or when a module is
>> inserted.
>>>>>>>>> When this table accessed before acpi_gbl_permanent_mmap is set,
>>>>>>>>> the pointer should be unmapped.  This is exactly what this
>> function
>>>>>>>>> does.
>>>>>>>> [Lv Zheng]
>>>>>>>> Why don't you use another API instead of
>> early_acpi_os_unmap_memory()
>>>>>> in
>>>>>>>> case you want to unmap things in any cases.
>>>>>>>> acpi_os_unmap_memory() should be the one to match this purpose.
>>>>>>>> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
>>>>>>
>>>>>> As far as I understand, there exist two steps in ACPI
>> initialization:
>>>>>>
>>>>>> 1. Before acpi_gbl_permanent_mmap is set, tables received with
>>>>>> acpi_get_table_with_size()
>>>>>>    are mapped by early_memremap().  If a subsystem gets such a
>> pointer it
>>>>>> should be unmapped.
>>>>>>
>>>>>> 2  After acpi_gbl_permanent_mmap is set this pointer should not be
>> unmapped
>>>>>> at all.
>>>>>>
>>>>> [Lv Zheng] 
>>>>> This statement is wrong, this should be:
>>>>> As long as there is a __reference__ to the mapped table, the
>> pointer should not be unmapped.
>>>>> In fact, we have a series to introduce acpi_put_table() to achieve
>> this.
>>>>> So your argument is wrong from very first point.
>>>>>
>>>>>> That exactly what early_acpi_os_unmap_memory() does--it checks
>>>>>> acpi_gbl_permanent_mmap.
>>>>>> If I had used acpi_os_unmap_memory() after acpi_gbl_permanent_mmap
>> had
>>>>>> been set,
>>>>>> it would have tried to free that pointer with an oops (actually, I
>> checked that
>>>>>> and got that oops).
>>>>>>
>>>>>> So using acpi_os_unmap_memory() is not an option here, but
>>>>>> early_acpi_os_unmap_memory()
>>>>>> match perfectly.
>>>>> [Lv Zheng] 
>>>>> I don't think so.
>>>>> For definition block tables, we know for sure there will always be
>> references, until "Unload" opcode is invoked by the AML interpreter.
>>>>> But for the data tables, OSPMs should use them in this way:
>>>>> 1. map the table
>>>>> 2. parse the table and convert it to OS specific structures
>>>>> 3. unmap the table
>>>>> This helps to shrink virtual memory address space usages.
>>>>>
>>>>> So from this point of view, all data tables should be unmapped
>> right after being parsed.
>>>>> Why do you need the map to be persistent in the kernel address
>> space?
>>>>> You can always map a small table, but what if the table size is
>> very big?
>>>>>
>>>>>>
>>>>>>>> And in fact early_acpi_os_unmap_memory() should be removed.
>>>>>>
>>>>>> I don't think so -- I have explained why.  It does different
>> thing.
>>>>>> Probably it (and/or other functions in that api) should be
>> renamed.
>>>>>>
>>>>> [Lv Zheng] 
>>>>> Just let me ask one more question.
>>>>> eary_acpi_os_unmap_memory() is not used inside of ACPICA.
>>>>> How ACPICA can work with just acpi_os_unmap_memory()?
>>>>> You can check drivers/acpi/tbxxx.c.
>>>>> Especially: acpi_tb_release_temp_table() and the code invoking it.
>>>>>
>>>>>>> [Lv Zheng]
>>>>>>> One more thing is:
>>>>>>> If you can't switch your driver to use acpi_os_unmap_memory()
>> instead of
>>>>>> early_acpi_os_unmap_memory(),
>>>>>>> then it implies that your driver does have a defect.
>>>>>>
>>>>>> I still don't understand what defect, sorry.
>>>>> [Lv Zheng] 
>>>>> If you can't ensure this sequence for using the data tables:
>>>>> 1. map the table
>>>>> 2. parse the table and convert it to OS specific structure
>>>>> 3. unmap the table
>>>>> It implies there is a bug in the driver or a bug in the ACPI
>> subsystem core.
>>>>
>>>> Exactly.
>>>>
>>>> The central problem here is the way Aleksey is trying to hookup a
>> console.
>>>>
>>>> What should be happening in this series is:
>>>> 1. early map SPCR
>>>> 2. parse the SPCR table
>>>> 3. call add_preferred_console() to add the SPCR console to the
>> console table
>>>> 4. unmap SPCR
>>>
>>> This does not work.  
>>>
>>> SPCR specifies address of the console, but add_preferred_console()
>> accepts
>>> name of console and its index.  There are no general method to
>> translate address
>>> to name at such an early stage.
>>
>>
>> 	add_preferred_console(uart, 0, "io,0x3f8,115200");
>>
>> This will start a console with the 8250 driver. I've already pointed
>> this out to you in an earlier review. This is what existing firmware
>> already does.
>>
>> This is also the method you will use to start an earlycon from the
>> DBG2 table, by additionally calling setup_earlycon().
> 
> Can the device specified in DBG2 be used for both earlycon and KGDB? If it can only be used for one, let's make sure the choice of earlycon vs KGDB is intentional rather than accidental.

I just sent the DBG2 series.  It enables an earlycon on DBG2 port with
an "earlycon=acpi_dbg2" option (we can discuss particular name).
If you need KGDB on that port just support it for that port in the kernel
(i. e. add a new instance of ACPI_DBG2_DECLARE() macros for that port, see the patches)
and change the command line options.
I hope that is OK.  We could continue this discussion in the DBG2 thread.

Thank you
Aleksey Makarov

> 
> Thanks,
> Christopher Covington
> 


From linus.walleij at linaro.org  Mon Feb 22 06:44:44 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Feb 2016 15:44:44 +0100
Subject: [PATCH 00/61] gpio: Add and use devm_gpiochip_add_data()
In-Reply-To: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <CACRpkdbt+RiWMA74e40MNZVnDM0t0futtFnbyu9sRhv7p93-Tg@mail.gmail.com>

On Mon, Feb 22, 2016 at 3:07 PM, Laxman Dewangan <ldewangan at nvidia.com> wrote:

> Add resource management APIs for gpiochip_add_data() and
> gpiochip_remove() and use these APIs from different HW drivers.
>
> This is based on discussion on patch to use the new APIs.
>         gpio: Add devm_ apis for gpio_chip_add and remove

Awesome!

Do you have a git I can just pull these off so I don't have to apply
then all one-by-one?

Yours,
Linus Walleij


From rabin.vincent at axis.com  Mon Feb 22 06:41:30 2016
From: rabin.vincent at axis.com (Rabin Vincent)
Date: Mon, 22 Feb 2016 15:41:30 +0100
Subject: [PATCHv2 2/2] ARM: dma-mapping: refactor to fix coherent+cma+gfp=0
In-Reply-To: <1456152090-18630-1-git-send-email-rabin.vincent@axis.com>
References: <1456152090-18630-1-git-send-email-rabin.vincent@axis.com>
Message-ID: <1456152090-18630-2-git-send-email-rabin.vincent@axis.com>

Given a device which uses arm_coherent_dma_ops and on which
dev_get_cma_area(dev) returns non-NULL, the following usage of the DMA
API with gfp=0 results in memory corruption and a memory leak.

 p = dma_alloc_coherent(dev, sz, &dma, 0);
 if (p)
 	dma_free_coherent(dev, sz, p, dma);

The memory leak is because the alloc allocates using
__alloc_simple_buffer() but the free attempts
dma_release_from_contiguous() which does not do free anything since the
page is not in the CMA area.

The memory corruption is because the free calls __dma_remap() on a page
which is backed by only first level page tables.  The
apply_to_page_range() + __dma_update_pte() loop ends up interpreting the
section mapping as an addresses to a second level page table and writing
the new PTE to memory which is not used by page tables.

We don't have access to the GFP flags used for allocation in the free
function.  Fix this by adding allocator backends and using this
information in the free function so that we always use the correct
release routine.

Fixes: 21caf3a7 ("ARM: 8398/1: arm DMA: Fix allocation from CMA for coherent DMA")
Signed-off-by: Rabin Vincent <rabin.vincent at axis.com>
---
 arch/arm/mm/dma-mapping.c | 165 +++++++++++++++++++++++++++++++++++-----------
 1 file changed, 128 insertions(+), 37 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index d8c6efc..122c9f9 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -42,9 +42,33 @@
 #include "dma.h"
 #include "mm.h"
 
+struct arm_dma_alloc_args {
+	struct device *dev;
+	size_t size;
+	gfp_t gfp;
+	pgprot_t prot;
+	const void *caller;
+	bool want_vaddr;
+};
+
+struct arm_dma_free_args {
+	struct device *dev;
+	size_t size;
+	void *cpu_addr;
+	struct page *page;
+	bool want_vaddr;
+};
+
+struct arm_dma_allocator {
+	void *(*alloc)(struct arm_dma_alloc_args *args,
+		       struct page **ret_page);
+	void (*free)(struct arm_dma_free_args *args);
+};
+
 struct arm_dma_buffer {
 	struct list_head list;
 	void *virt;
+	struct arm_dma_allocator *allocator;
 };
 
 static LIST_HEAD(arm_dma_bufs);
@@ -617,7 +641,7 @@ static inline pgprot_t __get_dma_pgprot(struct dma_attrs *attrs, pgprot_t prot)
 #define __alloc_remap_buffer(dev, size, gfp, prot, ret, c, wv)	NULL
 #define __alloc_from_pool(size, ret_page)			NULL
 #define __alloc_from_contiguous(dev, size, prot, ret, c, wv)	NULL
-#define __free_from_pool(cpu_addr, size)			0
+#define __free_from_pool(cpu_addr, size)			do { } while (0)
 #define __free_from_contiguous(dev, page, cpu_addr, size, wv)	do { } while (0)
 #define __dma_free_remap(cpu_addr, size)			do { } while (0)
 
@@ -635,7 +659,78 @@ static void *__alloc_simple_buffer(struct device *dev, size_t size, gfp_t gfp,
 	return page_address(page);
 }
 
+static void *simple_allocator_alloc(struct arm_dma_alloc_args *args,
+				    struct page **ret_page)
+{
+	return __alloc_simple_buffer(args->dev, args->size, args->gfp,
+				     ret_page);
+}
+
+static void simple_allocator_free(struct arm_dma_free_args *args)
+{
+	__dma_free_buffer(args->page, args->size);
+}
+
+static struct arm_dma_allocator simple_allocator = {
+	.alloc = simple_allocator_alloc,
+	.free = simple_allocator_free,
+};
+
+static void *cma_allocator_alloc(struct arm_dma_alloc_args *args,
+				 struct page **ret_page)
+{
+	return __alloc_from_contiguous(args->dev, args->size, args->prot,
+				       ret_page, args->caller,
+				       args->want_vaddr);
+}
+
+static void cma_allocator_free(struct arm_dma_free_args *args)
+{
+	__free_from_contiguous(args->dev, args->page, args->cpu_addr,
+			       args->size, args->want_vaddr);
+}
+
+static struct arm_dma_allocator cma_allocator = {
+	.alloc = cma_allocator_alloc,
+	.free = cma_allocator_free,
+};
 
+static void *pool_allocator_alloc(struct arm_dma_alloc_args *args,
+				  struct page **ret_page)
+{
+	return __alloc_from_pool(args->size, ret_page);
+}
+
+static void pool_allocator_free(struct arm_dma_free_args *args)
+{
+	__free_from_pool(args->cpu_addr, args->size);
+}
+
+static struct arm_dma_allocator pool_allocator = {
+	.alloc = pool_allocator_alloc,
+	.free = pool_allocator_free,
+};
+
+static void *remap_allocator_alloc(struct arm_dma_alloc_args *args,
+				   struct page **ret_page)
+{
+	return __alloc_remap_buffer(args->dev, args->size, args->gfp,
+				    args->prot, ret_page, args->caller,
+				    args->want_vaddr);
+}
+
+static void remap_allocator_free(struct arm_dma_free_args *args)
+{
+	if (args->want_vaddr)
+		__dma_free_remap(args->cpu_addr, args->size);
+
+	__dma_free_buffer(args->page, args->size);
+}
+
+static struct arm_dma_allocator remap_allocator = {
+	.alloc = remap_allocator_alloc,
+	.free = remap_allocator_free,
+};
 
 static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
 			 gfp_t gfp, pgprot_t prot, bool is_coherent,
@@ -644,8 +739,16 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
 	u64 mask = get_coherent_dma_mask(dev);
 	struct page *page = NULL;
 	void *addr;
-	bool want_vaddr;
+	bool allowblock, cma;
 	struct arm_dma_buffer *buf;
+	struct arm_dma_alloc_args args = {
+		.dev = dev,
+		.size = PAGE_ALIGN(size),
+		.gfp = gfp,
+		.prot = prot,
+		.caller = caller,
+		.want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs),
+	};
 
 #ifdef CONFIG_DMA_API_DEBUG
 	u64 limit = (mask + 1) & ~mask;
@@ -674,29 +777,28 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
 	 * platform; see CONFIG_HUGETLBFS.
 	 */
 	gfp &= ~(__GFP_COMP);
+	args.gfp = gfp;
 
 	*handle = DMA_ERROR_CODE;
-	size = PAGE_ALIGN(size);
-	want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs);
-
-	if (nommu())
-		addr = __alloc_simple_buffer(dev, size, gfp, &page);
-	else if (dev_get_cma_area(dev) && (gfp & __GFP_DIRECT_RECLAIM))
-		addr = __alloc_from_contiguous(dev, size, prot, &page,
-					       caller, want_vaddr);
-	else if (is_coherent)
-		addr = __alloc_simple_buffer(dev, size, gfp, &page);
-	else if (!gfpflags_allow_blocking(gfp))
-		addr = __alloc_from_pool(size, &page);
+	allowblock = gfpflags_allow_blocking(gfp);
+	cma = allowblock ? dev_get_cma_area(dev) : false;
+
+	if (cma)
+		buf->allocator = &cma_allocator;
+	else if (nommu() || is_coherent)
+		buf->allocator = &simple_allocator;
+	else if (allowblock)
+		buf->allocator = &remap_allocator;
 	else
-		addr = __alloc_remap_buffer(dev, size, gfp, prot, &page,
-					    caller, want_vaddr);
+		buf->allocator = &pool_allocator;
+
+	addr = buf->allocator->alloc(&args, &page);
 
 	if (page) {
 		unsigned long flags;
 
 		*handle = pfn_to_dma(dev, page_to_pfn(page));
-		buf->virt = want_vaddr ? addr : page;
+		buf->virt = args.want_vaddr ? addr : page;
 
 		spin_lock_irqsave(&arm_dma_bufs_lock, flags);
 		list_add(&buf->list, &arm_dma_bufs);
@@ -705,7 +807,7 @@ static void *__dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
 		kfree(buf);
 	}
 
-	return want_vaddr ? addr : page;
+	return args.want_vaddr ? addr : page;
 }
 
 /*
@@ -781,31 +883,20 @@ static void __arm_dma_free(struct device *dev, size_t size, void *cpu_addr,
 			   bool is_coherent)
 {
 	struct page *page = pfn_to_page(dma_to_pfn(dev, handle));
-	bool want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs);
 	struct arm_dma_buffer *buf;
+	struct arm_dma_free_args args = {
+		.dev = dev,
+		.size = PAGE_ALIGN(size),
+		.cpu_addr = cpu_addr,
+		.page = page,
+		.want_vaddr = !dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs),
+	};
 
 	buf = arm_dma_buffer_find(cpu_addr);
 	if (WARN(!buf, "Freeing invalid buffer %p\n", cpu_addr))
 		return;
 
-	size = PAGE_ALIGN(size);
-
-	if (nommu()) {
-		__dma_free_buffer(page, size);
-	} else if (!is_coherent && __free_from_pool(cpu_addr, size)) {
-		return;
-	} else if (!dev_get_cma_area(dev)) {
-		if (want_vaddr && !is_coherent)
-			__dma_free_remap(cpu_addr, size);
-		__dma_free_buffer(page, size);
-	} else {
-		/*
-		 * Non-atomic allocations cannot be freed with IRQs disabled
-		 */
-		WARN_ON(irqs_disabled());
-		__free_from_contiguous(dev, page, cpu_addr, size, want_vaddr);
-	}
-
+	buf->allocator->free(&args);
 	kfree(buf);
 }
 
-- 
2.7.0



From slemieux.tyco at gmail.com  Mon Feb 22 06:49:54 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Mon, 22 Feb 2016 09:49:54 -0500
Subject: [PATCH 0/2] arm: lpc32xx: restart: add support for soft reset
In-Reply-To: <CAGhQ9Vwr6H0YjRfaiBNaUrm8rHEVjh-NQbPZMdOZh2cJnMXmBA@mail.gmail.com>
References: <002701d16b5b$f78c7b70$e6a57250$@gmail.com>
 <CAGhQ9Vwr6H0YjRfaiBNaUrm8rHEVjh-NQbPZMdOZh2cJnMXmBA@mail.gmail.com>
Message-ID: <1456152594.28296.3.camel@localhost>

On Sat, 2016-02-20 at 23:19 +0100, Joachim Eastwood wrote:
> On 19 February 2016 at 22:24, Sylvain Lemieux <slemieux.tyco at gmail.com> wrote:
> > Hi Joachim,
> >
> >> From: Joachim Eastwood [mailto:manabian at gmail.com]
> >> Sent: 18-Feb-16 5:08 PM
> >> To: slemieux.tyco at gmail.com
> >>
> >> Hi Sylvain,
> >>
> >> On 18 February 2016 at 22:35,  <slemieux.tyco at gmail.com> wrote:
> >> > From: Sylvain Lemieux <slemieux at tycoint.com>
> >> >
> >> > The LPC32xx provide the capability to perform a soft or hard reset;
> >> > a soft reset will no reset the external peripheral
> >> > (i.e. RESOUT_N output not asserted).
> >> >
> >> > The default behavior (i.e. hard reset) remain unchanged.
> >> >
> >> > Sylvain Lemieux (2):
> >> >   arm: lpc32xx: restart: add support for soft reset
> >> >   arm: lpc32xx: restart: support "cmd" from userspace
> >> >
> >> >  arch/arm/mach-lpc32xx/common.c | 26 +++++++++++++++++++++++---
> >> >  1 file changed, 23 insertions(+), 3 deletions(-)
> >>
> >> Instead of adding more code to mach-lpc32xx could this code be moved
> >> to the watchdog driver (pnx4008_wdt.c) ?
> >> See register_restart_handler() and how it's used in other watchdog drivers.
> >>
> >> Then maybe the restart hook in phy3250.c could be removed all together.
> >
> > Thanks for the feedback;
> >
> > It is possible to remove the "lpc23xx_restart" function from "mach-lpc32xx"
> > and add the functionality to the pnx4008 watchdog driver.
> > The restart hook in phy3250.c can be remove.
> >
> > I will submit a new revision of the patch on Monday.
> >
> >>
> > I need to add a new functionality to the pnx4008 driver to
> > keep the driver disable and only provide the restart hook.
> 
> Why do you need to disable the driver?
> The watchdog is not enabled unless you don't explicitly do so, ie
> opening it and starting it.
> 
On our custom lpc32xx board, we are using an external gpio watchdog.
Prior to this change the pnx4008 driver was disable in the
device tree for our board.

I was trying to only have the restart functionality selected in
the pnx4008 driver and not disable the register operation; this will
provide a single watchdog under "/dev", in our case, the gpio watchdog.

I will work with the "linux-watchdog" maintainer to find a standard
way to provide an option for using a watchdog driver for the
restart capability only (i.e. do not register the driver).

> > I am planning to add the functionality using a module parameter;
> > this is the way the pnx833x & s3c2410 driver are doing it.
> 
> You should normally try to avoid module parameters if you can.
> 
> 
> > Do you have any feedback before a submit a patch for this change.
> 
> Take a look at:
> 2165bf524da5f5e496d - "watchdog: core: add restart handler support"

Thanks for pointing this.

I will submit a new revision of the patch later today.
> 
> Note that this will not give you the reboot_mode parameter. But maybe
> that could be added to the restart-callback function.
> 
> 
> regards,
> Joachim Eastwood




From mark.rutland at arm.com  Mon Feb 22 06:49:54 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Feb 2016 14:49:54 +0000
Subject: [PATCH v6 02/12] arm-cci: Group writes to counter
In-Reply-To: <1453720877-24962-3-git-send-email-suzuki.poulose@arm.com>
References: <1453720877-24962-1-git-send-email-suzuki.poulose@arm.com>
 <1453720877-24962-3-git-send-email-suzuki.poulose@arm.com>
Message-ID: <20160222144954.GE3435@leverpostej>

On Mon, Jan 25, 2016 at 11:21:07AM +0000, Suzuki K. Poulose wrote:
> Add a helper to group the writes to PMU counter, this will be
> used to delay setting the event period to pmu::pmu_enable()
> 
> Cc: Mark Rutland <mark.rutland at arm.com>
> Cc: Punit Agrawal <punit.agrawal at arm.com>
> Signed-off-by: Suzuki K. Poulose <suzuki.poulose at arm.com>
> ---
> Changes since V5:
>   - Use the prev_count from event->hw for the counter value, than
>     using a single value for all the counters.
> ---
>  drivers/bus/arm-cci.c |   15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> index ee47e6b..936fa9b 100644
> --- a/drivers/bus/arm-cci.c
> +++ b/drivers/bus/arm-cci.c
> @@ -771,6 +771,21 @@ static void pmu_write_counter(struct perf_event *event, u32 value)
>  		pmu_write_register(cci_pmu, value, idx, CCI_PMU_CNTR);
>  }
>  
> +static void __maybe_unused
> +pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
> +{
> +	int i;
> +	struct cci_pmu_hw_events *cci_hw = &cci_pmu->hw_events;
> +
> +	for_each_set_bit(i, mask, cci_pmu->num_cntrs) {
> +		struct perf_event *event = cci_hw->events[i];
> +
> +		if (WARN_ON(!event))
> +			continue;
> +		pmu_write_counter(event, (u32)local64_read(&event->hw.prev_count));
> +	}
> +}

I think the cast can go here. The truncation will happen implicitly
anyway.

Mark.


> +
>  static u64 pmu_event_update(struct perf_event *event)
>  {
>  	struct hw_perf_event *hwc = &event->hw;
> -- 
> 1.7.9.5
> 


From alexandre.torgue at gmail.com  Mon Feb 22 06:50:46 2016
From: alexandre.torgue at gmail.com (Alexandre Torgue)
Date: Mon, 22 Feb 2016 15:50:46 +0100
Subject: [PATCH 1/4] net: ethernet: dwmac: add Ethernet glue logic for
 stm32 chip
In-Reply-To: <CAGhQ9VypZ5J0pQmrf1Mk-mNsv=XTXu7fhoLt_r2LHJ_Lsyj0yA@mail.gmail.com>
References: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
 <1454511275-9791-2-git-send-email-alexandre.torgue@gmail.com>
 <CAGhQ9VypZ5J0pQmrf1Mk-mNsv=XTXu7fhoLt_r2LHJ_Lsyj0yA@mail.gmail.com>
Message-ID: <CAJgp7zwOVEq=hnxfUt7eHZWSFUAwuK6MCVHdH591=xReRUsW8Q@mail.gmail.com>

2016-02-13 14:48 GMT+01:00 Joachim  Eastwood <manabian at gmail.com>:
> On 3 February 2016 at 15:54, Alexandre TORGUE
> <alexandre.torgue at gmail.com> wrote:
>> stm324xx family chips support Synopsys MAC 3.510 IP.
>> This patch adds settings for logical glue logic:
>> -clocks
>> -mode selection MII or RMII.
>>
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
>> index cec147d..a94dd15 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
>> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
>> @@ -114,6 +114,18 @@ config DWMAC_SUNXI
>>           This selects Allwinner SoC glue layer support for the
>>           stmmac device driver. This driver is used for A20/A31
>>           GMAC ethernet controller.
>> +
>> +config DWMAC_STM32
>> +       tristate "STM32 DWMAC support"
>> +       default ARCH_STM32
>> +       depends on OF
>> +       select MFD_SYSCON
>> +       ---help---
>> +         Support for ethernet controller on STM32 SOCs.
>> +
>> +         This selects STM32 SoC glue layer support for the stmmac
>> +         device driver. This driver is used on for the STM32 series
>> +         SOCs GMAC ethernet controller.
>>  endif
>>
>>  config STMMAC_PCI
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
>> index b390161..9fb2061 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
>> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
>> @@ -14,6 +14,7 @@ obj-$(CONFIG_DWMAC_SOCFPGA)   += dwmac-socfpga.o
>>  obj-$(CONFIG_DWMAC_STI)                += dwmac-sti.o
>>  obj-$(CONFIG_DWMAC_SUNXI)      += dwmac-sunxi.o
>>  obj-$(CONFIG_DWMAC_GENERIC)    += dwmac-generic.o
>> +obj-$(CONFIG_DWMAC_STM32)      += dwmac-stm32.o
>
> Keep these sorted. There also a comment in the Makefile that states
> that the generic should always be last.

ok
>
>
>>  stmmac-platform-objs:= stmmac_platform.o
>>
>>  obj-$(CONFIG_STMMAC_PCI) += stmmac-pci.o
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
>> new file mode 100644
>> index 0000000..56ccc20
>> --- /dev/null
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
>> @@ -0,0 +1,177 @@
>> +/*
>> + * dwmac-stm32.c - DWMAC Specific Glue layer for STM32 MCU
>> + *
>> + * Copyright (C) Alexandre Torgue 2015
>> + * Author:  Alexandre Torgue <alexandre.torgue at gmail.com>
>> + * License terms:  GNU General Public License (GPL), version 2
>> + *
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/slab.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/stmmac.h>
>> +#include <linux/phy.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/module.h>
>> +#include <linux/regmap.h>
>> +#include <linux/clk.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_net.h>
>
> Consider sorting the includes.

ok
>
>> +
>> +#include "stmmac_platform.h"
>> +
>> +#define MII_PHY_SEL_MASK       BIT(23)
>> +
>> +struct stm32_dwmac {
>> +       int interface;          /* MII interface */
>> +       struct clk *clk_tx;
>> +       struct clk *clk_rx;
>> +       u32 mode_reg;           /* MAC glue-logic mode register */
>> +       struct device *dev;
>
> dev doesn't seem to be used anywhere.

ok
>
>> +       struct regmap *regmap;
>> +       u32 speed;
>> +};
>> +
>> +static int stm32_dwmac_init(struct platform_device *pdev, void *priv)
>> +{
>> +       struct stm32_dwmac *dwmac = priv;
>> +       struct regmap *regmap = dwmac->regmap;
>> +       int ret, iface = dwmac->interface;
>> +       u32 reg = dwmac->mode_reg;
>> +       u32 val;
>> +
>> +       if (dwmac->clk_tx)
>> +               ret = clk_prepare_enable(dwmac->clk_tx);
>
> The clk API handles a NULL clk so you don't really need to check for it.

I agree
>
>
>> +               if (ret)
>> +                       goto out;
>> +
>> +       if (dwmac->clk_rx)
>> +               ret = clk_prepare_enable(dwmac->clk_rx);
>
> Same here.
I agree
>
>
>> +               if (ret)
>> +                       goto out_disable_clk_tx;
>> +
>> +       val = (iface == PHY_INTERFACE_MODE_MII) ? 0 : 1;
>> +       ret = regmap_update_bits(regmap, reg, MII_PHY_SEL_MASK, val);
>> +       if (ret)
>> +               goto out_disable_clk_tx_rx;
>> +
>> +       return 0;
>> +
>> +out_disable_clk_tx_rx:
>> +       clk_disable_unprepare(dwmac->clk_rx);
>> +out_disable_clk_tx:
>> +       clk_disable_unprepare(dwmac->clk_tx);
>> +out:
>> +       return ret;
>> +}
>> +
>> +static void stm32_dwmac_exit(struct platform_device *pdev, void *priv)
>> +{
>> +       struct stm32_dwmac *dwmac = priv;
>> +
>> +       if (dwmac->clk_tx)
>> +               clk_disable_unprepare(dwmac->clk_tx);
>> +       if (dwmac->clk_rx)
>> +               clk_disable_unprepare(dwmac->clk_rx);
>
> Same here.
I agree
>
>
>> +}
>> +
>> +static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
>> +                                 struct platform_device *pdev)
>> +{
>> +       struct device *dev = &pdev->dev;
>> +       struct device_node *np = dev->of_node;
>> +       struct regmap *regmap;
>> +       int err;
>> +
>> +       if (!np)
>> +               return -EINVAL;
>
> Can this ever happen?
> This is a DT only driver, right?
You're right. It is only DT.
>
>> +
>> +       /*  Get TX/RX clocks */
>> +       dwmac->clk_tx = devm_clk_get(dev, "tx-clk");
>> +       if (IS_ERR(dwmac->clk_tx)) {
>> +               dev_warn(dev, "No tx clock provided...\n");
>> +               dwmac->clk_tx = NULL;
>> +       }
>> +       dwmac->clk_rx = devm_clk_get(dev, "rx-clk");
>> +       if (IS_ERR(dwmac->clk_rx)) {
>> +               dev_warn(dev, "No rx clock provided...\n");
>> +               dwmac->clk_rx = NULL;
>> +       }
>> +
>> +       /* Get mode register */
>> +       regmap = syscon_regmap_lookup_by_phandle(np, "st,syscon");
>> +       if (IS_ERR(regmap))
>> +               return PTR_ERR(regmap);
>> +
>> +       err = of_property_read_u32_index(np, "st,syscon", 1, &dwmac->mode_reg);
>> +       if (err) {
>> +               dev_err(dev, "Can't get sysconfig mode offset (%d)\n", err);
>> +               return err;
>> +       }
>> +
>> +       dwmac->dev = dev;
>> +       dwmac->interface = of_get_phy_mode(np);
>> +       dwmac->regmap = regmap;
>> +
>> +       return 0;
>> +}
>> +
>> +static int stm32_dwmac_probe(struct platform_device *pdev)
>> +{
>> +       struct plat_stmmacenet_data *plat_dat;
>> +       struct stmmac_resources stmmac_res;
>> +       struct stm32_dwmac *dwmac;
>> +       int ret;
>> +
>> +       ret = stmmac_get_platform_resources(pdev, &stmmac_res);
>> +       if (ret)
>> +               return ret;
>> +
>> +       plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
>> +       if (IS_ERR(plat_dat))
>> +               return PTR_ERR(plat_dat);
>> +
>> +       dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
>> +       if (!dwmac)
>> +               return -ENOMEM;
>> +
>> +       ret = stm32_dwmac_parse_data(dwmac, pdev);
>> +       if (ret) {
>> +               dev_err(&pdev->dev, "Unable to parse OF data\n");
>> +               return ret;
>> +       }
>> +
>> +       plat_dat->bsp_priv = dwmac;
>> +       plat_dat->init = stm32_dwmac_init;
>> +       plat_dat->exit = stm32_dwmac_exit;
>
> Instead of using these callbacks could you rather implement the PM
> callbacks directly in this driver?
> I don't think it should add much code and it will make it look more
> like standard driver. This will also give you some more control and
> flexibility in your code.

I prefer to keep the code as it is. Glue layer is directly linked to
stmmac driver and I don't want to brake the link between the glue and
the stmmac driver.

>
>> +
>> +       ret = stm32_dwmac_init(pdev, plat_dat->bsp_priv);
>> +       if (ret)
>> +               return ret;
>> +
>> +       return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
>> +}
>> +
>> +static const struct of_device_id stm32_dwmac_match[] = {
>> +       { .compatible = "st,stm32-dwmac"},
>> +       { }
>> +};
>> +MODULE_DEVICE_TABLE(of, stm32_dwmac_match);
>> +
>> +static struct platform_driver stm32_dwmac_driver = {
>> +       .probe  = stm32_dwmac_probe,
>> +       .remove = stmmac_pltfr_remove,
>
> Could you implement the .remove callback in your driver instead of
> using stmmac_pltfr_remove?
> Same reasons as above.

As explain above, I prefere to keep the code as it is in order to not
remove glue layer before the stmmac driver.

>
>
>> +       .driver = {
>> +               .name           = "stm32-dwmac",
>> +               .pm             = &stmmac_pltfr_pm_ops,
>> +               .of_match_table = stm32_dwmac_match,
>> +       },
>> +};
>> +module_platform_driver(stm32_dwmac_driver);
>> +
>> +MODULE_AUTHOR("Alexandre Torgue <alexandre.torgue at gmail.com>");
>> +MODULE_DESCRIPTION("STMicroelectronics MCU DWMAC Specific Glue layer");
>> +MODULE_LICENSE("GPL");
>
> Since you state:
>> + * License terms:  GNU General Public License (GPL), version 2
>
> You might want to switch use: MODULE_LICENSE("GPL v2");
>
I agree.
>
> regards,
> Joachim Eastwood

Thanks Joachim for the review and remarks. Main will be corrected in
next patch version.

regards
Alexandre Torgue


From festevam at gmail.com  Mon Feb 22 06:55:06 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 22 Feb 2016 11:55:06 -0300
Subject: [PATCH V3 0/5] clk: support clocks which requires parent clock on
 during operation
In-Reply-To: <20150813101702.GB19166@shlinux1.ap.freescale.net>
References: <1438089585-30103-1-git-send-email-aisheng.dong@freescale.com>
 <20150728143824.GB16916@shlinux1.ap.freescale.net>
 <20150804094556.GE24870@shlinux1.ap.freescale.net>
 <20150813101702.GB19166@shlinux1.ap.freescale.net>
Message-ID: <CAOMZO5ATOkkw3wCaBeyr7NaVPekuyPNkhDu3c1G3Wv=VtcydjA@mail.gmail.com>

Hi Mike,

On Thu, Aug 13, 2015 at 7:17 AM, Dong Aisheng
<aisheng.dong at freescale.com> wrote:

> Hi Mike,
>
> It's been quite a long time.
> Can you help pick this?

Yes, we are still getting lots of clock warnings in mx7d in mainline
without Dong's series:

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:3382
lock_release+0x2f8/0x334()
[    0.000000] releasing a pinned lock
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.5.0-rc5-next-20160222 #256
[    0.000000] Hardware name: Freescale i.MX7 Dual (Device Tree)
[    0.000000] Backtrace:
[    0.000000] [<c010b6f4>] (dump_backtrace) from [<c010b890>]
(show_stack+0x18/0x1c)
[    0.000000]  r6:600000d3 r5:ffffffff r4:00000000 r3:00000000
[    0.000000] [<c010b878>] (show_stack) from [<c03dae8c>]
(dump_stack+0xb0/0xe8)
[    0.000000] [<c03daddc>] (dump_stack) from [<c012461c>]
(warn_slowpath_common+0x80/0xbc)
[    0.000000]  r8:c0ad86ec r7:00000009 r6:00000d36 r5:c0169e5c
r4:c0d01ba0 r3:c0d064c0
[    0.000000] [<c012459c>] (warn_slowpath_common) from [<c01246fc>]
(warn_slowpath_fmt+0x38/0x40)
[    0.000000]  r8:c0d06980 r7:00000002 r6:00000001 r5:c0d064c0 r4:ef7c2290
[    0.000000] [<c01246c8>] (warn_slowpath_fmt) from [<c0169e5c>]
(lock_release+0x2f8/0x334)
[    0.000000]  r3:00000026 r2:c0ad9698
[    0.000000] [<c0169b64>] (lock_release) from [<c08e31f8>]
(_raw_spin_unlock_irq+0x20/0x34)
[    0.000000]  r10:c0c75280 r9:ef7c2280 r8:00000000 r7:c0d02b10
r6:00000001 r5:ef7c2280
[    0.000000]  r4:ef7c2280
[    0.000000] [<c08e31d8>] (_raw_spin_unlock_irq) from [<c015219c>]
(dequeue_task_idle+0x14/0x30)
[    0.000000]  r4:ef7c2280 r3:c0152188
[    0.000000] [<c0152188>] (dequeue_task_idle) from [<c0149a50>]
(deactivate_task+0x64/0x68)
[    0.000000]  r4:c0d064c0 r3:c0152188
[    0.000000] [<c01499ec>] (deactivate_task) from [<c08ddd68>]
(__schedule+0x2cc/0x6d8)
[    0.000000]  r6:c0d06804 r5:ef7c2290 r4:c0d064c0 r3:00000002
[    0.000000] [<c08dda9c>] (__schedule) from [<c08de29c>] (schedule+0x3c/0xa0)
[    0.000000]  r10:c0d064c0 r9:c1560db8 r8:00000001 r7:00000000
r6:0006ddd0 r5:00000000
[    0.000000]  r4:0007a120
[    0.000000] [<c08de260>] (schedule) from [<c08e28b0>]
(schedule_hrtimeout_range_clock+0xd4/0x13c)
[    0.000000] [<c08e27dc>] (schedule_hrtimeout_range_clock) from
[<c08e293c>] (schedule_hrtimeout_range+0x24/0x2c)
[    0.000000]  r10:000006d8 r8:000000d8 r7:00000003 r6:ffff8ad1
r5:c0d02100 r4:ef00c040
[    0.000000] [<c08e2918>] (schedule_hrtimeout_range) from
[<c08e2360>] (usleep_range+0x54/0x5c)
[    0.000000] [<c08e230c>] (usleep_range) from [<c068b83c>]
(clk_pllv3_wait_lock+0x7c/0xb4)
[    0.000000] [<c068b7c0>] (clk_pllv3_wait_lock) from [<c068ba4c>]
(clk_pllv3_prepare+0x2c/0x30)
[    0.000000]  r6:c0d5c7f4 r5:00000000 r4:ef007680 r3:f08400f0
[    0.000000] [<c068ba20>] (clk_pllv3_prepare) from [<c0685e08>]
(clk_core_prepare+0xa0/0xcc)
[    0.000000] [<c0685d68>] (clk_core_prepare) from [<c0685e54>]
(clk_prepare+0x20/0x30)
[    0.000000]  r5:00000000 r4:ef00c100
[    0.000000] [<c0685e34>] (clk_prepare) from [<c0c4a700>]
(imx7d_clocks_init+0x6114/0x6198)
[    0.000000]  r4:ef00c100 r3:c0d064c0
[    0.000000] [<c0c445ec>] (imx7d_clocks_init) from [<c0c30c08>]
(of_clk_init+0x138/0x1e8)
[    0.000000]  r10:c0d01f70 r9:00000001 r8:c0d01f68 r7:00000000
r6:ef004340 r5:ef7e3d60
[    0.000000]  r4:00000003
[    0.000000] [<c0c30ad0>] (of_clk_init) from [<c0c049f0>]
(time_init+0x2c/0x38)
[    0.000000]  r10:00000001 r9:410fc075 r8:efffcb80 r7:c0c5ca48
r6:c0d76000 r5:ffffffff
[    0.000000]  r4:00000000
[    0.000000] [<c0c049c4>] (time_init) from [<c0c00bcc>]
(start_kernel+0x26c/0x400)
[    0.000000] [<c0c00960>] (start_kernel) from [<8000807c>] (0x8000807c)
[    0.000000]  r10:00000000 r8:8000406a r7:c0d07e4c r6:c0c5ca44
r5:c0d0296c r4:c0d76294
[    0.000000] ---[ end trace cb88537fdc8fa200 ]---
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2576
trace_hardirqs_on_caller+0x1ac/0x1f0()
[    0.000000] DEBUG_LOCKS_WARN_ON(unlikely(early_boot_irqs_disabled))
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
4.5.0-rc5-next-20160222 #256
[    0.000000] Hardware name: Freescale i.MX7 Dual (Device Tree)
[    0.000000] Backtrace:
[    0.000000] [<c010b6f4>] (dump_backtrace) from [<c010b890>]
(show_stack+0x18/0x1c)
[    0.000000]  r6:600000d3 r5:ffffffff r4:00000000 r3:00000000
[    0.000000] [<c010b878>] (show_stack) from [<c03dae8c>]
(dump_stack+0xb0/0xe8)
[    0.000000] [<c03daddc>] (dump_stack) from [<c012461c>]
(warn_slowpath_common+0x80/0xbc)
[    0.000000]  r8:c0ad86ec r7:00000009 r6:00000a10 r5:c016a948
r4:c0d01bc8 r3:c0d064c0
[    0.000000] [<c012459c>] (warn_slowpath_common) from [<c01246fc>]
(warn_slowpath_fmt+0x38/0x40)
[    0.000000]  r8:00000000 r7:c0d02b10 r6:00000001 r5:ef7c2280 r4:c08e3204
[    0.000000] [<c01246c8>] (warn_slowpath_fmt) from [<c016a948>]
(trace_hardirqs_on_caller+0x1ac/0x1f0)
[    0.000000]  r3:c0ad9700 r2:c0ad5cc8
[    0.000000] [<c016a79c>] (trace_hardirqs_on_caller) from
[<c016a9a0>] (trace_hardirqs_on+0x14/0x18)
[    0.000000]  r6:00000001 r5:ef7c2280 r4:ef7c2280 r3:600000d3
[    0.000000] [<c016a98c>] (trace_hardirqs_on) from [<c08e3204>]
(_raw_spin_unlock_irq+0x2c/0x34)
[    0.000000] [<c08e31d8>] (_raw_spin_unlock_irq) from [<c015219c>]
(dequeue_task_idle+0x14/0x30)
[    0.000000]  r4:ef7c2280 r3:c0152188
[    0.000000] [<c0152188>] (dequeue_task_idle) from [<c0149a50>]
(deactivate_task+0x64/0x68)
[    0.000000]  r4:c0d064c0 r3:c0152188
[    0.000000] [<c01499ec>] (deactivate_task) from [<c08ddd68>]
(__schedule+0x2cc/0x6d8)
[    0.000000]  r6:c0d06804 r5:ef7c2290 r4:c0d064c0 r3:00000002
[    0.000000] [<c08dda9c>] (__schedule) from [<c08de29c>] (schedule+0x3c/0xa0)
[    0.000000]  r10:c0d064c0 r9:c1560db8 r8:00000001 r7:00000000
r6:0006ddd0 r5:00000000
[    0.000000]  r4:0007a120
[    0.000000] [<c08de260>] (schedule) from [<c08e28b0>]
(schedule_hrtimeout_range_clock+0xd4/0x13c)
[    0.000000] [<c08e27dc>] (schedule_hrtimeout_range_clock) from
[<c08e293c>] (schedule_hrtimeout_range+0x24/0x2c)
[    0.000000]  r10:000006d8 r8:000000d8 r7:00000003 r6:ffff8ad1
r5:c0d02100 r4:ef00c040
[    0.000000] [<c08e2918>] (schedule_hrtimeout_range) from
[<c08e2360>] (usleep_range+0x54/0x5c)
[    0.000000] [<c08e230c>] (usleep_range) from [<c068b83c>]
(clk_pllv3_wait_lock+0x7c/0xb4)
[    0.000000] [<c068b7c0>] (clk_pllv3_wait_lock) from [<c068ba4c>]
(clk_pllv3_prepare+0x2c/0x30)
[    0.000000]  r6:c0d5c7f4 r5:00000000 r4:ef007680 r3:f08400f0
[    0.000000] [<c068ba20>] (clk_pllv3_prepare) from [<c0685e08>]
(clk_core_prepare+0xa0/0xcc)
[    0.000000] [<c0685d68>] (clk_core_prepare) from [<c0685e54>]
(clk_prepare+0x20/0x30)
[    0.000000]  r5:00000000 r4:ef00c100
[    0.000000] [<c0685e34>] (clk_prepare) from [<c0c4a700>]
(imx7d_clocks_init+0x6114/0x6198)
[    0.000000]  r4:ef00c100 r3:c0d064c0
[    0.000000] [<c0c445ec>] (imx7d_clocks_init) from [<c0c30c08>]
(of_clk_init+0x138/0x1e8)
[    0.000000]  r10:c0d01f70 r9:00000001 r8:c0d01f68 r7:00000000
r6:ef004340 r5:ef7e3d60
[    0.000000]  r4:00000003
[    0.000000] [<c0c30ad0>] (of_clk_init) from [<c0c049f0>]
(time_init+0x2c/0x38)
[    0.000000]  r10:00000001 r9:410fc075 r8:efffcb80 r7:c0c5ca48
r6:c0d76000 r5:ffffffff
[    0.000000]  r4:00000000
[    0.000000] [<c0c049c4>] (time_init) from [<c0c00bcc>]
(start_kernel+0x26c/0x400)
[    0.000000] [<c0c00960>] (start_kernel) from [<8000807c>] (0x8000807c)
[    0.000000]  r10:00000000 r8:8000406a r7:c0d07e4c r6:c0c5ca44
r5:c0d0296c r4:c0d76294
[    0.000000] ---[ end trace cb88537fdc8fa201 ]---
[    0.000000] bad: scheduling from the idle thread!
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
4.5.0-rc5-next-20160222 #256
[    0.000000] Hardware name: Freescale i.MX7 Dual (Device Tree)
[    0.000000] Backtrace:
[    0.000000] [<c010b6f4>] (dump_backtrace) from [<c010b890>]
(show_stack+0x18/0x1c)
[    0.000000]  r6:60000053 r5:ffffffff r4:00000000 r3:00000000
[    0.000000] [<c010b878>] (show_stack) from [<c03dae8c>]
(dump_stack+0xb0/0xe8)
[    0.000000] [<c03daddc>] (dump_stack) from [<c01521a8>]
(dequeue_task_idle+0x20/0x30)
[    0.000000]  r8:00000000 r7:c0d02b10 r6:00000001 r5:ef7c2280
r4:ef7c2280 r3:c0d064c0
[    0.000000] [<c0152188>] (dequeue_task_idle) from [<c0149a50>]
(deactivate_task+0x64/0x68)
[    0.000000]  r4:c0d064c0 r3:c0152188
[    0.000000] [<c01499ec>] (deactivate_task) from [<c08ddd68>]
(__schedule+0x2cc/0x6d8)
[    0.000000]  r6:c0d06804 r5:ef7c2290 r4:c0d064c0 r3:00000002
[    0.000000] [<c08dda9c>] (__schedule) from [<c08de29c>] (schedule+0x3c/0xa0)
[    0.000000]  r10:c0d064c0 r9:c1560db8 r8:00000001 r7:00000000
r6:0006ddd0 r5:00000000
[    0.000000]  r4:0007a120
[    0.000000] [<c08de260>] (schedule) from [<c08e28b0>]
(schedule_hrtimeout_range_clock+0xd4/0x13c)
[    0.000000] [<c08e27dc>] (schedule_hrtimeout_range_clock) from
[<c08e293c>] (schedule_hrtimeout_range+0x24/0x2c)
[    0.000000]  r10:000006d8 r8:000000d8 r7:00000003 r6:ffff8ad1
r5:c0d02100 r4:ef00c040
[    0.000000] [<c08e2918>] (schedule_hrtimeout_range) from
[<c08e2360>] (usleep_range+0x54/0x5c)
[    0.000000] [<c08e230c>] (usleep_range) from [<c068b83c>]
(clk_pllv3_wait_lock+0x7c/0xb4)
[    0.000000] [<c068b7c0>] (clk_pllv3_wait_lock) from [<c068ba4c>]
(clk_pllv3_prepare+0x2c/0x30)
[    0.000000]  r6:c0d5c7f4 r5:00000000 r4:ef007680 r3:f08400f0
[    0.000000] [<c068ba20>] (clk_pllv3_prepare) from [<c0685e08>]
(clk_core_prepare+0xa0/0xcc)
[    0.000000] [<c0685d68>] (clk_core_prepare) from [<c0685e54>]
(clk_prepare+0x20/0x30)
[    0.000000]  r5:00000000 r4:ef00c100
[    0.000000] [<c0685e34>] (clk_prepare) from [<c0c4a700>]
(imx7d_clocks_init+0x6114/0x6198)
[    0.000000]  r4:ef00c100 r3:c0d064c0
[    0.000000] [<c0c445ec>] (imx7d_clocks_init) from [<c0c30c08>]
(of_clk_init+0x138/0x1e8)
[    0.000000]  r10:c0d01f70 r9:00000001 r8:c0d01f68 r7:00000000
r6:ef004340 r5:ef7e3d60
[    0.000000]  r4:00000003
[    0.000000] [<c0c30ad0>] (of_clk_init) from [<c0c049f0>]
(time_init+0x2c/0x38)
[    0.000000]  r10:00000001 r9:410fc075 r8:efffcb80 r7:c0c5ca48
r6:c0d76000 r5:ffffffff
[    0.000000]  r4:00000000
[    0.000000] [<c0c049c4>] (time_init) from [<c0c00bcc>]
(start_kernel+0x26c/0x400)
[    0.000000] [<c0c00960>] (start_kernel) from [<8000807c>] (0x8000807c)
[    0.000000]  r10:00000000 r8:8000406a r7:c0d07e4c r6:c0c5ca44
r5:c0d0296c r4:c0d76294
[    0.000000] Architected cp15 timer(s) running at 8.00MHz (virt).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
max_cycles: 0x1d854df40, max_idle_ns: 440795202120 ns
[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: CPU: 0 PID: 0 at kernel/time/sched_clock.c:179
sched_clock_register+0x44/0x1f8()
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
4.5.0-rc5-next-20160222 #256
[    0.000000] Hardware name: Freescale i.MX7 Dual (Device Tree)
[    0.000000] Backtrace:
[    0.000000] [<c010b6f4>] (dump_backtrace) from [<c010b890>]
(show_stack+0x18/0x1c)
[    0.000000]  r6:60000053 r5:ffffffff r4:00000000 r3:00000000
[    0.000000] [<c010b878>] (show_stack) from [<c03dae8c>]
(dump_stack+0xb0/0xe8)
[    0.000000] [<c03daddc>] (dump_stack) from [<c012461c>]
(warn_slowpath_common+0x80/0xbc)
[    0.000000]  r8:c0add580 r7:00000009 r6:000000b3 r5:c0c13a40
r4:00000000 r3:c0d064c0
[    0.000000] [<c012459c>] (warn_slowpath_common) from [<c012467c>]
(warn_slowpath_null+0x24/0x2c)
[    0.000000]  r8:007a1200 r7:c155f688 r6:c0d5b2c0 r5:9ffdbd98 r4:a3aaa0c5
[    0.000000] [<c0124658>] (warn_slowpath_null) from [<c0c13a40>]
(sched_clock_register+0x44/0x1f8)
[    0.000000] [<c0c139fc>] (sched_clock_register) from [<c0c2de48>]
(arch_timer_common_init+0x1d4/0x234)
[    0.000000]  r10:c0b5a5b4 r9:00000008 r8:c0ae2f94 r7:c155f688
r6:c0d5b2c0 r5:9ffdbd98
[    0.000000]  r4:a3aaa0c5
[    0.000000] [<c0c2dc74>] (arch_timer_common_init) from [<c0c2e174>]
(arch_timer_of_init+0x2cc/0x30c)
[    0.000000]  r10:00000001 r9:410fc075 r8:efffcb80 r7:c0c5ca48
r6:00000001 r5:00000000
[    0.000000]  r4:00000012
[    0.000000] [<c0c2dea8>] (arch_timer_of_init) from [<c0c2db24>]
(clocksource_probe+0x50/0x94)
[    0.000000]  r6:00000001 r5:c0d01f84 r4:ef7dae9c r3:c0c2dea8
[    0.000000] [<c0c2dad4>] (clocksource_probe) from [<c0c049f4>]
(time_init+0x30/0x38)
[    0.000000]  r6:c0d76000 r5:ffffffff r4:00000000
[    0.000000] [<c0c049c4>] (time_init) from [<c0c00bcc>]
(start_kernel+0x26c/0x400)
[    0.000000] [<c0c00960>] (start_kernel) from [<8000807c>] (0x8000807c)
[    0.000000]  r10:00000000 r8:8000406a r7:c0d07e4c r6:c0c5ca44
r5:c0d0296c r4:c0d76294
[    0.000000] ---[ end trace cb88537fdc8fa202 ]---
[    0.000007] sched_clock: 56 bits at 8MHz, resolution 125ns, wraps
every 2199023255500ns
[    0.000023] Switching to timer-based delay loop, resolution 125ns
[    0.000603] Switching to timer-based delay loop, resolution 41ns
[    0.000614] ------------[ cut here ]------------
[    0.000632] WARNING: CPU: 0 PID: 0 at kernel/time/sched_clock.c:179
sched_clock_register+0x44/0x1f8()
[    0.000641] Modules linked in:
[    0.000658] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
4.5.0-rc5-next-20160222 #256
[    0.000668] Hardware name: Freescale i.MX7 Dual (Device Tree)
[    0.000676] Backtrace:
[    0.000700] [<c010b6f4>] (dump_backtrace) from [<c010b890>]
(show_stack+0x18/0x1c)
[    0.000710]  r6:60000053 r5:ffffffff r4:00000000 r3:00000000
[    0.000746] [<c010b878>] (show_stack) from [<c03dae8c>]
(dump_stack+0xb0/0xe8)
[    0.000763] [<c03daddc>] (dump_stack) from [<c012461c>]
(warn_slowpath_common+0x80/0xbc)
[    0.000773]  r8:c0add580 r7:00000009 r6:000000b3 r5:c0c13a40
r4:00000000 r3:c0d064c0
[    0.000813] [<c012459c>] (warn_slowpath_common) from [<c012467c>]
(warn_slowpath_null+0x24/0x2c)
[    0.000823]  r8:016e3600 r7:f0880024 r6:016e3600 r5:c155f6f0 r4:ef002400
[    0.000863] [<c0124658>] (warn_slowpath_null) from [<c0c13a40>]
(sched_clock_register+0x44/0x1f8)
[    0.000881] [<c0c139fc>] (sched_clock_register) from [<c0c2e8a4>]
(_mxc_timer_init+0x148/0x240)
[    0.000891]  r10:00000001 r9:410fc075 r8:c0b5a984 r7:f0880024
r6:016e3600 r5:c155f6f0
[    0.000926]  r4:ef002400
[    0.000945] [<c0c2e75c>] (_mxc_timer_init) from [<c0c2ea54>]
(mxc_timer_init_dt+0xb8/0xe8)
[    0.000955]  r8:efffcb80 r7:00000003 r6:00000000 r5:ef7e084c r4:ef002400
[    0.000996] [<c0c2e99c>] (mxc_timer_init_dt) from [<c0c2ea98>]
(imx6dl_timer_init_dt+0x14/0x18)
[    0.001006]  r7:c0c5ca48 r6:00000002 r5:c0d01f84 r4:ef7e084c
[    0.001041] [<c0c2ea84>] (imx6dl_timer_init_dt) from [<c0c2db24>]
(clocksource_probe+0x50/0x94)
[    0.001061] [<c0c2dad4>] (clocksource_probe) from [<c0c049f4>]
(time_init+0x30/0x38)
[    0.001071]  r6:c0d76000 r5:ffffffff r4:00000000
[    0.001102] [<c0c049c4>] (time_init) from [<c0c00bcc>]
(start_kernel+0x26c/0x400)
[    0.001119] [<c0c00960>] (start_kernel) from [<8000807c>] (0x8000807c)
[    0.001128]  r10:00000000 r8:8000406a r7:c0d07e4c r6:c0c5ca44
r5:c0d0296c r4:c0d76294
[    0.001164] ---[ end trace cb88537fdc8fa203 ]---
[    0.001183] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps
every 89478484971ns
[    0.001201] clocksource: mxc_timer1: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 79635851949 ns
[    0.002139] ------------[ cut here ]------------
[    0.002161] WARNING: CPU: 0 PID: 0 at init/main.c:593
start_kernel+0x298/0x400()
[    0.002170] Interrupts were enabled early
[    0.002179] Modules linked in:
[    0.002195] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
4.5.0-rc5-next-20160222 #256
[    0.002205] Hardware name: Freescale i.MX7 Dual (Device Tree)
[    0.002214] Backtrace:
[    0.002237] [<c010b6f4>] (dump_backtrace) from [<c010b890>]
(show_stack+0x18/0x1c)
[    0.002247]  r6:60000053 r5:ffffffff r4:00000000 r3:00000000
[    0.002283] [<c010b878>] (show_stack) from [<c03dae8c>]
(dump_stack+0xb0/0xe8)
[    0.002300] [<c03daddc>] (dump_stack) from [<c012461c>]
(warn_slowpath_common+0x80/0xbc)
[    0.002310]  r8:c0ace4a0 r7:00000009 r6:00000251 r5:c0c00bf8
r4:c0d01f98 r3:c0d064c0
[    0.002351] [<c012459c>] (warn_slowpath_common) from [<c01246fc>]
(warn_slowpath_fmt+0x38/0x40)
[    0.002361]  r8:efffcb80 r7:c0c5ca48 r6:c0d76000 r5:ffffffff r4:00000000
[    0.002402] [<c01246c8>] (warn_slowpath_fmt) from [<c0c00bf8>]
(start_kernel+0x298/0x400)
[    0.002413]  r3:60000053 r2:c0ace4e0
[    0.002436] [<c0c00960>] (start_kernel) from [<8000807c>] (0x8000807c)
[    0.002446]  r10:00000000 r8:8000406a r7:c0d07e4c r6:c0c5ca44
r5:c0d0296c r4:c0d76294
[    0.002482] ---[ end trace cb88537fdc8fa204 ]---
[    0.002594] Console: colour dummy device 80x30
[    0.002607] Lock dependency validator: Copyright (c) 2006 Red Hat,
Inc., Ingo Molnar
[    0.002616] ... MAX_LOCKDEP_SUBCLASSES:  8


From aleksey.makarov at linaro.org  Mon Feb 22 06:58:02 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 22 Feb 2016 17:58:02 +0300
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E883BB4D949@SHSMSX101.ccr.corp.intel.com>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
 <56C470C5.2080203@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>
 <56C63FB5.2030907@hurleysoftware.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4D5A0@SHSMSX101.ccr.corp.intel.com>
 <56C6F660.9020407@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D949@SHSMSX101.ccr.corp.intel.com>
Message-ID: <56CB21FA.1090302@linaro.org>

Hi, 

On 02/22/2016 05:24 AM, Zheng, Lv wrote:
> Hi,
> 
>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>> early_acpi_os_unmap_memory()
>>
>> Hi Lv,
>>
>> On 02/19/2016 05:58 AM, Zheng, Lv wrote:
>>> Hi,
>>>
>>>> From: Peter Hurley [mailto:peter at hurleysoftware.com]
>>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>>>> early_acpi_os_unmap_memory()
>>>>
>>>> On 02/17/2016 07:36 PM, Zheng, Lv wrote:
>>>>> Hi,
>>>>>
>>>>>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
>>>>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>>>>>> early_acpi_os_unmap_memory()
>>>>>>
>>>>>> Hi Lv,
>>>>>>
>>>>>> Thank you for review.
>>>>>>
>>>>>> On 02/17/2016 05:51 AM, Zheng, Lv wrote:
>>>>>>
>>>>>> [..]
>>>>>>
>>>>>>>>> early_acpi_os_unmap_memory() is marked as __init because it calls
>>>>>>>>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap is
>> not
>>>>>> set.
>>>>>>>>>
>>>>>>>>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>>>>>> so it is safe to call early_acpi_os_unmap_memory() from anywhere
>>>>>>>>>
>>>>>>>>> We need this function to be non-__init because we need access to
>>>>>>>>> some tables at unpredictable time--it may be before or after
>>>>>>>>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port
>>>> Console
>>>>>>>>> Redirection) table is needed each time a new console is registered.
>>>>>>>>> It can be quite early (console_initcall) or when a module is inserted.
>>>>>>>>> When this table accessed before acpi_gbl_permanent_mmap is set,
>>>>>>>>> the pointer should be unmapped.  This is exactly what this function
>>>>>>>>> does.
>>>>>>>> [Lv Zheng]
>>>>>>>> Why don't you use another API instead of
>>>> early_acpi_os_unmap_memory()
>>>>>> in
>>>>>>>> case you want to unmap things in any cases.
>>>>>>>> acpi_os_unmap_memory() should be the one to match this purpose.
>>>>>>>> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
>>>>>>
>>>>>> As far as I understand, there exist two steps in ACPI initialization:
>>>>>>
>>>>>> 1. Before acpi_gbl_permanent_mmap is set, tables received with
>>>>>> acpi_get_table_with_size()
>>>>>>    are mapped by early_memremap().  If a subsystem gets such a pointer it
>>>>>> should be unmapped.
>>>>>>
>>>>>> 2  After acpi_gbl_permanent_mmap is set this pointer should not be
>>>> unmapped
>>>>>> at all.
>>>>>>
>>>>> [Lv Zheng]
>>>>> This statement is wrong, this should be:
>>>>> As long as there is a __reference__ to the mapped table, the pointer should
>>>> not be unmapped.
>>>>> In fact, we have a series to introduce acpi_put_table() to achieve this.
>>>>> So your argument is wrong from very first point.
>>>>>
>>>>>> That exactly what early_acpi_os_unmap_memory() does--it checks
>>>>>> acpi_gbl_permanent_mmap.
>>>>>> If I had used acpi_os_unmap_memory() after acpi_gbl_permanent_mmap
>>>> had
>>>>>> been set,
>>>>>> it would have tried to free that pointer with an oops (actually, I checked
>> that
>>>>>> and got that oops).
>>>>>>
>>>>>> So using acpi_os_unmap_memory() is not an option here, but
>>>>>> early_acpi_os_unmap_memory()
>>>>>> match perfectly.
>>>>> [Lv Zheng]
>>>>> I don't think so.
>>>>> For definition block tables, we know for sure there will always be
>> references,
>>>> until "Unload" opcode is invoked by the AML interpreter.
>>>>> But for the data tables, OSPMs should use them in this way:
>>>>> 1. map the table
>>>>> 2. parse the table and convert it to OS specific structures
>>>>> 3. unmap the table
>>>>> This helps to shrink virtual memory address space usages.
>>>>>
>>>>> So from this point of view, all data tables should be unmapped right after
>>>> being parsed.
>>>>> Why do you need the map to be persistent in the kernel address space?
>>>>> You can always map a small table, but what if the table size is very big?
>>>>>
>>>>>>
>>>>>>>> And in fact early_acpi_os_unmap_memory() should be removed.
>>>>>>
>>>>>> I don't think so -- I have explained why.  It does different thing.
>>>>>> Probably it (and/or other functions in that api) should be renamed.
>>>>>>
>>>>> [Lv Zheng]
>>>>> Just let me ask one more question.
>>>>> eary_acpi_os_unmap_memory() is not used inside of ACPICA.
>>>>> How ACPICA can work with just acpi_os_unmap_memory()?
>>>>> You can check drivers/acpi/tbxxx.c.
>>>>> Especially: acpi_tb_release_temp_table() and the code invoking it.
>>>>>
>>>>>>> [Lv Zheng]
>>>>>>> One more thing is:
>>>>>>> If you can't switch your driver to use acpi_os_unmap_memory() instead
>> of
>>>>>> early_acpi_os_unmap_memory(),
>>>>>>> then it implies that your driver does have a defect.
>>>>>>
>>>>>> I still don't understand what defect, sorry.
>>>>> [Lv Zheng]
>>>>> If you can't ensure this sequence for using the data tables:
>>>>> 1. map the table
>>>>> 2. parse the table and convert it to OS specific structure
>>>>> 3. unmap the table
>>>>> It implies there is a bug in the driver or a bug in the ACPI subsystem core.
>>>>
>>>> Exactly.
>>> [Lv Zheng]
>>> So it looks to me:
>>> Changing __init to __ref here is entirely not acceptable.
>>> This API should stay being invoked during early stage.
>>> Otherwise, it may leave us untrackable code that maps tables during early
>> stage and leaks maps to the late stage.
>>> If Linux contains such kind of code, I'm afraid, it will become impossible to
>> introduce acpi_put_table() to clean up the mappings.
>>> Because when acpi_put_table() is called during the late stage to free a map
>> acquired during the early stage, it then obviously will end up with panic.
>>
>> Can you please sugggest a common method to access ACPI tables that
>> works both before *and* after acpi_gbl_permanent_mmap is set and __init
>> code
>> is removed?
> [Lv Zheng] 
> Do not change __init for now.
> 
> Currently you should:
> 1. before acpi_gbl_permanent_mmap is set:
> acpi_get_table_with_size()
> parse the table
> early_acpi_os_unmap_memory()
> Do your driver early stuff here
> 
> 2. after acpi_gbl_permanent_mmap is set:
> acpi_get_table()
> Parse the table
> Do your driver late stuff here
> <- note there is no API now being an inverse of acpi_get_table().

That's fine.  These are two different methods to access the table.
I need one that works in both cases.  Of course, they could be combined,
but I am not sure if I can access the acpi_gbl_permanent_mmap variable--it
seems to be an implementation detail of ACPI code.

Instead I am going to use the 1st method once and cache the result like this:


static int __init parse(void)
{
	static bool parsed;

	if (!parsed) {
		acpi_get_table_with_size()
		/* parse the table and cache the result */
		early_acpi_os_unmap_memory()
		parse = true;
	}
}

arch_initcal(parse());

int __ref the_handler_where_I_need_the_parse_results(void)
{
	parse();

	/* use the data */
}

I hope you are OK with it.

> Besides, I'm about to insert error messages between 1 and 2.
> If an early map is not release, error message will be prompted to the developers.

AFAICS, there is such an error message and I saw it.
Refer to check_early_ioremap_leak() at mm/early_ioremap.c

> And if you don't follow the above rules, it mean you are trying to lay a mine, waiting for me to step on it.
> That's why this change is entirely not acceptable.

Ok, I see.

> I'm about to send out the cleanup series in 1 week, and will Cc you.
> You can rebase your code on top of the cleanup series.

Thank you
Aleksey Makarov

> 
> Thanks and best regards
> -Lv
> 
>>
>>> Thanks and best regards
>>> -Lv
>>>
>>>> The central problem here is the way Aleksey is trying to hookup a console.
>>>>
>>>> What should be happening in this series is:
>>>> 1. early map SPCR
>>>> 2. parse the SPCR table
>>>> 3. call add_preferred_console() to add the SPCR console to the console
>> table
>>>> 4. unmap SPCR
>>>>
>>>> This trivial and unobtrusive method would already have a 8250 console
>>>> running via SPCR. I've already pointed this out in previous reviews.
>>>>
>>>> Further, the above method *will be required anyway* for the DBG2 table to
>>>> start an earlycon, which I've already pointed out in previous reviews.
>>>>
>>>> Then to enable amba-pl011 console via ACPI, add a console match() method
>>>> similar to the 8250 console match() method, univ8250_console_match().
>>>>
>>>> FWIW, PCI earlycon + console support was already submitted once before
>> but
>>>> never picked up by GregKH. I think I'll just grab that and re-submit so
>>>> you would know what to emit for console options in the
>>>> add_preferred_console().
>>>>
>>>>
>>>> Regards,
>>>> Peter Hurley
>>>>
>>>>
>>>>>>> There is an early bootup requirement in Linux.
>>>>>>> Maps acquired during the early stage should be freed by the driver during
>>>> the
>>>>>> early stage.
>>>>>>> And the driver should re-acquire the memory map after booting.
>>>>>>
>>>>>> Exactly.  That's why I use early_acpi_os_unmap_memory().  The point is
>> that
>>>>>> that code can be
>>>>>> called *before* acpi_gbl_permanent_mmap is set (at early initialization
>> of
>>>> for
>>>>>> example 8250 console)
>>>>>> or *after* acpi_gbl_permanent_mmap is set (at insertion of a module
>> that
>>>>>> registers a console),
>>>>>> We just can not tell if the received table pointer should or sould not be
>> freed
>>>>>> with early_memunmap()
>>>>>> (actually __acpi_unmap_table() or whatever) without checking
>>>>>> acpi_gbl_permanent_mmap,
>>>>>> but that's all too low level.
>>>>> [Lv Zheng]
>>>>> The driver should make sure that:
>>>>> Map/unmap is paired during early stage.
>>>>> For late stage, it should be another pair of map/unmap.
>>>>>
>>>>>>
>>>>>> Another option, as you describe, is to get this pointer early, don't free it
>>>>> [Lv Zheng]
>>>>> I mean you should free it early.
>>>>>
>>>>>> untill acpi_gbl_permanent_mmap is set, then free it (with
>>>>>> early_acpi_os_unmap_memory(), that's
>>>>>> ok because acpi_gbl_permanent_mmap is set in an init code), then get
>> the
>>>>>> persistent
>>>>>> pointer to the table.  The problem with it is that we can not just watch
>>>>>> acpi_gbl_permanent_mmap
>>>>>> to catch this exact moment.  And also accessing
>> acpi_gbl_permanent_mmap
>>>> is
>>>>>> not good as it probably is
>>>>>> an implementation detail (i. e. too lowlevel) of the ACPI code.
>>>>>> Or I probably miss what you are suggesting.
>>>>>>
>>>>> [Lv Zheng]
>>>>> I mean, you should:
>>>>> During early stage:
>>>>> acpi_os_map_memory()
>>>>> Parse the table.
>>>>> acpi_os_unmap_memory().
>>>>>
>>>>>>> This is because, during early bootup stage, there are only limited slots
>>>>>> available for drivers to map memory.
>>>>>>> So by changing __init to __ref here, you probably will hide many such
>>>> defects.
>>>>>>
>>>>>> What defects?  This funcions checks acpi_gbl_permanent_mmap.
>>>>>> BTW, exactly the same thing is done in the beginning of
>>>>>> acpi_os_unmap_memory() and than's ok,
>>>>>> that function is __ref.
>>>>>>
>>>>>>> And solving issues in this way doesn't seem to be an improvement.
>>>>>>
>>>>>> Could you please tell me where I am wrong?  I still don't understand your
>>>> point.
>>>>> [Lv Zheng]
>>>>> But anyway, the defect should be in ACPI subsystem core.
>>>>> The cause should be the API itself - acpi_get_table().
>>>>>
>>>>> So I agree you can use early_acpi_os_unmap_memory() during the period
>> the
>>>> root causes are not cleaned up.
>>>>> But the bottom line is: the driver need to ensure that
>>>> early_acpi_os_unmap_memory() is always invoked.
>>>>> As long as you can ensure this, I don't have objections for deploying
>>>> early_acpi_os_unmap_memory()  for now.
>>>>>
>>>>> Thanks and best regards
>>>>> -Lv
>>>>>
>>>>>>
>>>>>> Thank you
>>>>>> Aleksey Makarov
>>>>>>
>>>>>>>
>>>>>>> Thanks and best regards
>>>>>>> -Lv
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks and best regards
>>>>>>>> -Lv
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
>>>>>>>>> ---
>>>>>>>>>  drivers/acpi/osl.c | 6 +++++-
>>>>>>>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
>>>>>>>>> index 67da6fb..8a552cd 100644
>>>>>>>>> --- a/drivers/acpi/osl.c
>>>>>>>>> +++ b/drivers/acpi/osl.c
>>>>>>>>> @@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void
>> *virt,
>>>>>>>>> acpi_size size)
>>>>>>>>>  }
>>>>>>>>>  EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
>>>>>>>>>
>>>>>>>>> -void __init early_acpi_os_unmap_memory(void __iomem *virt,
>>>> acpi_size
>>>>>>>> size)
>>>>>>>>> +/*
>>>>>>>>> + * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>>>>>> + * so it is safe to call early_acpi_os_unmap_memory() from
>> anywhere
>>>>>>>>> + */
>>>>>>>>> +void __ref early_acpi_os_unmap_memory(void __iomem *virt,
>>>> acpi_size
>>>>>>>> size)
>>>>>>>>>  {
>>>>>>>>>  	if (!acpi_gbl_permanent_mmap)
>>>>>>>>>  		__acpi_unmap_table(virt, size);
>>>>>>>>> --
>>>>>>>>> 2.7.1
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>>>>>>>>> the body of a message to majordomo at vger.kernel.org
>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-
>> info.html
>>>>>>>> --
>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>>>>>>>> the body of a message to majordomo at vger.kernel.org
>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>


From ard.biesheuvel at linaro.org  Mon Feb 22 06:59:39 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 15:59:39 +0100
Subject: [PATCH] arm*: efi: drop permanent mapping of the UEFI System table
Message-ID: <1456153179-27214-1-git-send-email-ard.biesheuvel@linaro.org>

The permanent, writable mapping of the UEFI System table is only
referenced during invocations of UEFI Runtime Services, at which time
the UEFI virtual mapping is available, which also covers the system
table (since the runtime services themselves need access to it)

So instead of creating this permanent mapping, record the virtual
address of the system table inside the UEFI virtual mapping, and
use that instead. This protects the contents of the system table
from inadvertent (or deliberate) modification.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---

Something I spotted while working on the memory attribute table stuff.
Since this is low hanging fruit and otherwise completely unrelated to it,
I am posting it as a separate patch

 drivers/firmware/efi/arm-init.c    |  2 ++
 drivers/firmware/efi/arm-runtime.c | 24 ++++++++++----------
 2 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 022f11157acd..e995d61da747 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -85,6 +85,8 @@ static int __init uefi_init(void)
 			efi.systab->hdr.revision >> 16,
 			efi.systab->hdr.revision & 0xffff);
 
+	efi.runtime_version = efi.systab->hdr.revision;
+
 	/* Show what we know for posterity */
 	c16 = early_memremap_ro(efi_to_phys(efi.systab->fw_vendor),
 				sizeof(vendor) * sizeof(efi_char16_t));
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 848ede1587dc..6ce13d6b7122 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -64,6 +64,16 @@ static bool __init efi_virtmap_init(void)
 				&phys, ret);
 			return false;
 		}
+		/*
+		 * If this entry covers the address of the UEFI system table,
+		 * calculate and record its virtual address.
+		 */
+		if (efi_system_table >= phys &&
+		    efi_system_table < phys + (md->num_pages * EFI_PAGE_SIZE)) {
+			efi.systab = (void *)(efi_system_table - phys +
+					      md->virt_addr);
+			set_bit(EFI_SYSTEM_TABLES, &efi.flags);
+		}
 	}
 
 	if (efi_memattr_apply_permissions(&efi_mm, efi_set_mapping_permissions))
@@ -102,16 +112,8 @@ static int __init arm_enable_runtime_services(void)
 	memmap.map_end = memmap.map + mapsize;
 	efi.memmap = &memmap;
 
-	efi.systab = (__force void *)ioremap_cache(efi_system_table,
-						   sizeof(efi_system_table_t));
-	if (!efi.systab) {
-		pr_err("Failed to remap EFI System Table\n");
-		return -ENOMEM;
-	}
-	set_bit(EFI_SYSTEM_TABLES, &efi.flags);
-
-	if (!efi_virtmap_init()) {
-		pr_err("No UEFI virtual mapping was installed -- runtime services will not be available\n");
+	if (!efi_virtmap_init() || !efi_enabled(EFI_SYSTEM_TABLES)) {
+		pr_err("UEFI virtual mapping missing or invalid -- runtime services will not be available\n");
 		return -ENOMEM;
 	}
 
@@ -119,8 +121,6 @@ static int __init arm_enable_runtime_services(void)
 	efi_native_runtime_setup();
 	set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
 
-	efi.runtime_version = efi.systab->hdr.revision;
-
 	return 0;
 }
 early_initcall(arm_enable_runtime_services);
-- 
2.5.0



From mark.rutland at arm.com  Mon Feb 22 07:02:03 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Feb 2016 15:02:03 +0000
Subject: [PATCH v6 10/12] arm-cci: CCI-500: Work around PMU counter writes
In-Reply-To: <1453720877-24962-11-git-send-email-suzuki.poulose@arm.com>
References: <1453720877-24962-1-git-send-email-suzuki.poulose@arm.com>
 <1453720877-24962-11-git-send-email-suzuki.poulose@arm.com>
Message-ID: <20160222150203.GF3435@leverpostej>

On Mon, Jan 25, 2016 at 11:21:15AM +0000, Suzuki K. Poulose wrote:
> The CCI PMU driver sets the event counter to the half of the maximum
> value(2^31) it can count before we start the counters via
> pmu_event_set_period(). This is done to give us the best chance to
> handle the overflow interrupt, taking care of extreme interrupt latencies.
> 
> However, CCI-500 comes with advanced power saving schemes, which
> disables the clock to the event counters unless the counters are enabled to
> count (PMCR.CEN). This prevents the driver from writing the period to the
> counters before starting them.  Also, there is no way we can reset the
> individual event counter to 0 (PMCR.RST resets all the counters, losing
> their current readings). However the value of the counter is preserved and
> could be read back, when the counters are not enabled.
> 
> So we cannot reliably use the counters and compute the number of events
> generated during the sampling period since we don't have the value of the
> counter at start.
> 
> This patch works around this issue by changing writes to the counter
> with the following steps.
> 
>  1) Disable all the counters (remembering any counters which were enabled)
>  2) Enable the PMU, now that all the counters are disabled.
> 
>  For each counter to be programmed, repeat steps 3-7
>  3) Save the current event and program the target counter to count an
>     invalid event, which by spec is guaranteed to not-generate any events.
>  4) Enable the target counter.
>  5) Write to the target counter.
>  6) Disable the target counter
>  7) Restore the event back on the target counter.
> 
>  8) Disable the PMU
>  9) Restore the status of the all the counters

[...]

> + * For each counter to be programmed, repeat steps 3-7:
> + *
> + * 3) Write an invalid event code to the event control register for the
> +      counter, so that the counters are not modified.
> + * 4) Enable the counter control for the counter.
> + * 5) Set the counter value
> + * 6) Restore the event in the target counter
> + * 7) Disable the counter

Steps 6 and 7 are the wrong way around here. They are correct in the
commit message and the code.

[...]

> + * We choose an event code which has very little chances of getting
> + * assigned a valid code for step(2). We use the highest possible
> + * event code (0x1f) for the master interface 0.
> + */

Let's just say:

	We choose an event which for CCI-500 is guaranteed not to count.
	We use the highest possible event code (0x1f) for master
	interface 0.

Otherwise this looks fine.

Mark.


From aleksey.makarov at linaro.org  Mon Feb 22 07:03:19 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Mon, 22 Feb 2016 18:03:19 +0300
Subject: [PATCH v3 2/5] ACPI: parse SPCR and enable matching console
In-Reply-To: <20160221094220.GA3181@yury-N73SV>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-3-git-send-email-aleksey.makarov@linaro.org>
 <20160221094220.GA3181@yury-N73SV>
Message-ID: <56CB2337.6030709@linaro.org>

Hi Yury,

Thank you for review/suggestions.  I will address it all in the next version except for...

On 02/21/2016 12:42 PM, Yury Norov wrote:
> On Mon, Feb 15, 2016 at 09:05:26PM +0300, Aleksey Makarov wrote:
>> 'ARM Server Base Boot Requiremets' [1] mentions SPCR (Serial Port
>> Console Redirection Table) [2] as a mandatory ACPI table that
>> specifies the configuration of serial console.
>>
>> Parse this table and check if any registered console match the
>> description.  If it does, enable that console.
>>
>> Introduce a new function acpi_console_check().  At the uart port
>> registration, this function checks if the ACPI SPCR table specifies
>> its argument of type struct uart_port to be a console
>> and if so calls add_preferred_console().
>>
>> [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
>> [2] http://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
>>
>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
>> ---
>>  drivers/acpi/Kconfig             |  3 ++
>>  drivers/acpi/Makefile            |  1 +
>>  drivers/acpi/spcr.c              | 97 ++++++++++++++++++++++++++++++++++++++++
>>  drivers/tty/serial/serial_core.c | 14 +++++-
>>  include/linux/acpi.h             | 10 +++++
>>  5 files changed, 123 insertions(+), 2 deletions(-)
>>  create mode 100644 drivers/acpi/spcr.c
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 65fb483..5611eb6 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -77,6 +77,9 @@ config ACPI_DEBUGGER_USER
>>  
>>  endif
>>  
>> +config ACPI_SPCR_TABLE
>> +	bool
>> +
>>  config ACPI_SLEEP
>>  	bool
>>  	depends on SUSPEND || HIBERNATION
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 346101c..708b143 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -81,6 +81,7 @@ obj-$(CONFIG_ACPI_EC_DEBUGFS)	+= ec_sys.o
>>  obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
>>  obj-$(CONFIG_ACPI_BGRT)		+= bgrt.o
>>  obj-$(CONFIG_ACPI_CPPC_LIB)	+= cppc_acpi.o
>> +obj-$(CONFIG_ACPI_SPCR_TABLE)	+= spcr.o
>>  obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
>>  
>>  # processor has its own "processor." module_param namespace
>> diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
>> new file mode 100644
>> index 0000000..a1eca91
>> --- /dev/null
>> +++ b/drivers/acpi/spcr.c
>> @@ -0,0 +1,97 @@
>> +/*
>> + * Copyright (c) 2012, Intel Corporation
>> + * Copyright (c) 2015, Red Hat, Inc.
>> + * Copyright (c) 2015, 2016 Linaro Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + */
>> +
>> +#define pr_fmt(fmt) "ACPI: SPCR: " fmt
>> +
>> +#include <linux/acpi.h>
>> +#include <linux/console.h>
>> +#include <linux/kernel.h>
>> +#include <linux/serial_core.h>
>> +
>> +static int acpi_table_parse_spcr(int (*handler)(struct acpi_table_spcr *table,
>> +						void *data), void *data)
>> +{
>> +	struct acpi_table_spcr *table = NULL;
> Hi Alexey,
> 
> Few minor comments...
> 
> Are you sure you need thin initialization?
> 
>> +	acpi_size table_size;
>> +	acpi_status status;
>> +	int err;
>> +
>> +	status = acpi_get_table_with_size(ACPI_SIG_SPCR, 0,
>> +					  (struct acpi_table_header **)&table,
>> +					  &table_size);
>> +
>> +	if (ACPI_FAILURE(status))
>> +		return -ENODEV;
>> +
>> +	err = handler(table, data);
>> +
>> +	early_acpi_os_unmap_memory(table, table_size);
>> +
>> +	return err;
>> +}
>> +
>> +static int spcr_table_handler_check(struct acpi_table_spcr *table, void *data)
> 
> The name of function is not clear for me.
> You're not only checking here, but also
> adding console. 
> 
>> +{
>> +	struct uart_port *uport = data;
>> +	char *options;
>> +
>> +	if (table->header.revision < 2)
>> +		return -EOPNOTSUPP;
>> +
>> +	switch (table->baud_rate) {
> 
> You don't need 'options' if your big condition returns false,
> so you can evaluate it inside conditional block.
> 
>> +	case 3:
>> +		options = "9600";
>> +		break;
>> +	case 4:
>> +		options = "19200";
>> +		break;
>> +	case 6:
>> +		options = "57600";
>> +		break;
>> +	case 7:
>> +		options = "115200";
>> +		break;
>> +	default:
>> +		options = "";
>> +		break;
> 
> 'break' isnot needed here

... except for this.

No, it is not, but C language style guides tell us to have it here.
Also see the first example from Documentation/CodingStyle 
where they have it.

Thank you
Aleksey Makarov

> 
>> +	}
>> +
>> +	if ((table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY &&
> 
> Nitpick: just for better readability, I'd split it onto a set of
> separated checks:
> 
>         foo() {
>                 if (!cond1)
>                         return 0;
> 
>                 if (!cond2)
>                         return 0;
>                 ...
> 
>                 switch () {
>                 case 1:
>                         ...
>                 case 2:
>                         ...
>                 case 3:
>                         ...
>                 default:
>                         ...
>                 }
>                 
>                 return 1;
>         }
> 
>> +	     table->serial_port.address == (u64)uport->mapbase) ||
>> +	    (table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_IO &&
>> +	     table->serial_port.address == (u64)uport->iobase)) {
>> +		pr_info("adding preferred console [%s%d]\n", uport->cons->name,
>> +			uport->line);
>> +		add_preferred_console(uport->cons->name, uport->line, options);
>> +		return 1;
>> +
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +/**
>> + * acpi_console_check - Check if uart matches the console specified by SPCR.
>> + *
>> + * @uport:	uart port to check
>> + *
>> + * This function checks if the ACPI SPCR table specifies @uport to be a console
>> + * and if so calls add_preferred_console()
>> + *
>> + * Return: a non-error value if the console matches.
>> + */
>> +bool acpi_console_check(struct uart_port *uport)
>> +{
>> +	if (acpi_disabled || console_set_on_cmdline)
>> +		return false;
>> +
>> +	return acpi_table_parse_spcr(spcr_table_handler_check, uport) > 0;
>> +}
>> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
>> index a126a60..459ab54 100644
>> --- a/drivers/tty/serial/serial_core.c
>> +++ b/drivers/tty/serial/serial_core.c
>> @@ -34,6 +34,7 @@
>>  #include <linux/serial_core.h>
>>  #include <linux/delay.h>
>>  #include <linux/mutex.h>
>> +#include <linux/acpi.h>
>>  
>>  #include <asm/irq.h>
>>  #include <asm/uaccess.h>
>> @@ -2654,8 +2655,17 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
>>  		spin_lock_init(&uport->lock);
>>  		lockdep_set_class(&uport->lock, &port_lock_key);
>>  	}
>> -	if (uport->cons && uport->dev)
>> -		of_console_check(uport->dev->of_node, uport->cons->name, uport->line);
>> +
>> +	/*
>> +	 * Support both open FW and ACPI access to console definitions.
>> +	 * Both of_console_check() and acpi_console_check() will call
>> +	 * add_preferred_console() if a console definition is found.
>> +	 */
>> +	if (uport->cons && uport->dev) {
>> +		if (!acpi_console_check(uport))
>> +			of_console_check(uport->dev->of_node, uport->cons->name,
>> +					 uport->line);
>> +	}
>>  
>>  	uart_configure_port(drv, state, uport);
>>  
>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>> index 06ed7e5..ea0c297 100644
>> --- a/include/linux/acpi.h
>> +++ b/include/linux/acpi.h
>> @@ -1004,4 +1004,14 @@ static inline struct fwnode_handle *acpi_get_next_subnode(struct device *dev,
>>  #define acpi_probe_device_table(t)	({ int __r = 0; __r;})
>>  #endif
>>  
>> +struct uart_port;
>> +#ifdef CONFIG_ACPI_SPCR_TABLE
>> +bool acpi_console_check(struct uart_port *uport);
>> +#else
>> +static inline bool acpi_console_check(struct uart_port *uport)
>> +{
>> +	return FALSE;
>> +}
>> +#endif
>> +
>>  #endif	/*_LINUX_ACPI_H*/
>> -- 
>> 2.7.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From p.pisati at gmail.com  Mon Feb 22 07:09:11 2016
From: p.pisati at gmail.com (Paolo Pisati)
Date: Mon, 22 Feb 2016 16:09:11 +0100
Subject: arm: set_memory_xx fixes patch missing?
Message-ID: <20160222150911.GA25429@luxor.wired.org>

What's happened to the arm side of this patch:

http://lkml.iu.edu/hypermail/linux/kernel/1601.2/04934.html

the arm64 code is already in Linus's tree, while it seems like the arm part was
lost and forgotten, and i don't see it in rmk's patch queue.
-- 
bye,
p.


From lkp at intel.com  Mon Feb 22 07:09:19 2016
From: lkp at intel.com (kbuild test robot)
Date: Mon, 22 Feb 2016 23:09:19 +0800
Subject: [PATCH 2/8] of/serial: move earlycon early_param handling to
 serial
In-Reply-To: <1456148818-26257-3-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <201602222324.obRtWfaJ%fengguang.wu@intel.com>

Hi Leif,

[auto build test ERROR on pm/linux-next]
[also build test ERROR on v4.5-rc5 next-20160222]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Aleksey-Makarov/arm64-move-acpi-dt-decision-earlier-in-boot-process/20160222-215244
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
config: microblaze-allyesconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=microblaze 

All errors (new ones prefixed by >>):

>> arch/microblaze/kernel/prom.c:48:19: error: conflicting types for 'early_init_dt_scan_chosen_serial'
    static int __init early_init_dt_scan_chosen_serial(unsigned long node,
                      ^
   In file included from arch/microblaze/kernel/prom.c:33:0:
   include/linux/of_fdt.h:66:12: note: previous declaration of 'early_init_dt_scan_chosen_serial' was here
    extern int early_init_dt_scan_chosen_serial(void);
               ^

vim +/early_init_dt_scan_chosen_serial +48 arch/microblaze/kernel/prom.c

12e84142 Michal Simek 2009-03-27  42  #include <asm/sections.h>
12e84142 Michal Simek 2009-03-27  43  #include <asm/pci-bridge.h>
12e84142 Michal Simek 2009-03-27  44  
12e84142 Michal Simek 2009-03-27  45  #ifdef CONFIG_EARLY_PRINTK
9d0c4dfe Rob Herring  2014-04-01  46  static const char *stdout;
2aa8e375 Michal Simek 2011-04-14  47  
c0d997fb Michal Simek 2012-12-13 @48  static int __init early_init_dt_scan_chosen_serial(unsigned long node,
12e84142 Michal Simek 2009-03-27  49  				const char *uname, int depth, void *data)
12e84142 Michal Simek 2009-03-27  50  {
9d0c4dfe Rob Herring  2014-04-01  51  	int l;

:::::: The code at line 48 was first introduced by commit
:::::: c0d997fb4c4f202c55a4ed8ab9b714a81a16e5ac microblaze: Add static qualifiers

:::::: TO: Michal Simek <michal.simek at xilinx.com>
:::::: CC: Michal Simek <michal.simek at xilinx.com>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 43955 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160222/f4a58943/attachment-0001.obj>

From mark.rutland at arm.com  Mon Feb 22 07:14:46 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Feb 2016 15:14:46 +0000
Subject: [PATCH v6 08/12] __cci_pmu_enable: Make counter sync optional
In-Reply-To: <1453720877-24962-9-git-send-email-suzuki.poulose@arm.com>
References: <1453720877-24962-1-git-send-email-suzuki.poulose@arm.com>
 <1453720877-24962-9-git-send-email-suzuki.poulose@arm.com>
Message-ID: <20160222151446.GG3435@leverpostej>

On Mon, Jan 25, 2016 at 11:21:13AM +0000, Suzuki K. Poulose wrote:
> On CCI-500 writing to a counter requires turning the PMU on. So,
> syncing the counter state should not be performed for such special cases,
> while turning the PMU on. This patch makes the 'sync' operation based
> on an input parameter to allow reuse of the __cci_pmu_enable() function,
> rather than definig a new helper (and a corresponding helper for pmu_disable
> to match the new helper for the sake of readability).

I think it would be better to have _sync and _nosync function variants.
i.e. have:

__cci_pmu_enable_sync(struct cci_pmu *cci_pmu)
{	
	cci_pmu_sync_counters(cci_pmu);
	 __cci_pmu_enable_nosync(cci_pmu);
}

Mark.

> 
> Cc: Mark Rutland <mark.rutland at arm.com>
> Cc: Punit Agrawal <punit.agrawal at arm.com>
> Signed-off-by: Suzuki K. Poulose <suzuki.poulose at arm.com>
> ---
>  drivers/bus/arm-cci.c |   12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> index 997ad36..9d700e1 100644
> --- a/drivers/bus/arm-cci.c
> +++ b/drivers/bus/arm-cci.c
> @@ -88,6 +88,9 @@ static const struct of_device_id arm_cci_matches[] = {
>  #define CCI_PMU_MAX_HW_CNTRS(model) \
>  	((model)->num_hw_cntrs + (model)->fixed_hw_cntrs)
>  
> +#define CCI_CNTRS_SYNC		true
> +#define CCI_CNTRS_NOSYNC	false
> +
>  /* Types of interfaces that can generate events */
>  enum {
>  	CCI_IF_SLAVE,
> @@ -640,11 +643,12 @@ void cci_pmu_sync_counters(struct cci_pmu *cci_pmu)
>  }
>  
>  /* Should be called with cci_pmu->hw_events->pmu_lock held */
> -static void __cci_pmu_enable(struct cci_pmu *cci_pmu)
> +static void __cci_pmu_enable(struct cci_pmu *cci_pmu, bool sync)
>  {
>  	u32 val;
>  
> -	cci_pmu_sync_counters(cci_pmu);
> +	if (sync)
> +		cci_pmu_sync_counters(cci_pmu);
>  
>  	/* Enable all the PMU counters. */
>  	val = readl_relaxed(cci_ctrl_base + CCI_PMCR) | CCI_PMCR_CEN;
> @@ -960,7 +964,7 @@ static irqreturn_t pmu_handle_irq(int irq_num, void *dev)
>  	}
>  
>  	/* Enable the PMU and sync possibly overflowed counters */
> -	__cci_pmu_enable(cci_pmu);
> +	__cci_pmu_enable(cci_pmu, CCI_CNTRS_SYNC);
>  	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
>  
>  	return IRQ_RETVAL(handled);
> @@ -1004,7 +1008,7 @@ static void cci_pmu_enable(struct pmu *pmu)
>  		return;
>  
>  	raw_spin_lock_irqsave(&hw_events->pmu_lock, flags);
> -	__cci_pmu_enable(cci_pmu);
> +	__cci_pmu_enable(cci_pmu, CCI_CNTRS_SYNC);
>  	raw_spin_unlock_irqrestore(&hw_events->pmu_lock, flags);
>  
>  }
> -- 
> 1.7.9.5
> 


From mark.rutland at arm.com  Mon Feb 22 07:18:09 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Feb 2016 15:18:09 +0000
Subject: [PATCH v6 00/12] arm-cci: PMU driver updates
In-Reply-To: <1453720877-24962-1-git-send-email-suzuki.poulose@arm.com>
References: <1453720877-24962-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <20160222151808.GI3435@leverpostej>

On Mon, Jan 25, 2016 at 11:21:05AM +0000, Suzuki K. Poulose wrote:
> Suzuki K. Poulose (11):
>   arm-cci: Group writes to counter
>   arm-cci: Refactor CCI PMU enable/disable methods
>   arm-cci: Delay PMU counter writes to pmu::pmu_enable
>   arm-cci: write_counter: Remove redundant check
>   arm-cci: Get the status of a counter
>   arm-cci: Add routines to save/restore all counters
>   __cci_pmu_enable: Make counter sync optional
>   arm-cci: Provide hook for writing to PMU counters
>   arm-cci: CCI-500: Work around PMU counter writes
>   arm-cci500: Rearrange PMU driver for code sharing with CCI-550 PMU
>   arm-cci: CoreLink CCI-550 PMU driver

These generally look fine. If you can fix up for my other comments,
then for the series:

Acked-by: Mark Rutland <mark.rutland at arm.com>

Mark.


From tiffany.lin at mediatek.com  Mon Feb 22 07:19:24 2016
From: tiffany.lin at mediatek.com (tiffany lin)
Date: Mon, 22 Feb 2016 23:19:24 +0800
Subject: [PATCH v4 5/8] [Media] vcodec: mediatek: Add Mediatek V4L2
 Video Encoder Driver
In-Reply-To: <56C82F60.4060304@xs4all.nl>
References: <1454585703-42428-1-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-2-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-3-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-4-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-5-git-send-email-tiffany.lin@mediatek.com>
 <1454585703-42428-6-git-send-email-tiffany.lin@mediatek.com>
 <56C1B4AF.1030207@xs4all.nl> <1455604653.19396.68.camel@mtksdaap41>
 <56C2D371.9090805@xs4all.nl> <1455959480.12533.11.camel@mtksdaap41>
 <56C82F60.4060304@xs4all.nl>
Message-ID: <1456154364.1943.3.camel@mtksdaap41>

Hi Hans,

On Sat, 2016-02-20 at 10:18 +0100, Hans Verkuil wrote:
> On 02/20/2016 10:11 AM, tiffany lin wrote:
> > Hi Hans,
> > 
> > On Tue, 2016-02-16 at 08:44 +0100, Hans Verkuil wrote:
> >> On 02/16/2016 07:37 AM, tiffany lin wrote:
> >>>>> +
> >>>>> +const struct v4l2_ioctl_ops mtk_venc_ioctl_ops = {
> >>>>> +	.vidioc_streamon		= v4l2_m2m_ioctl_streamon,
> >>>>> +	.vidioc_streamoff		= v4l2_m2m_ioctl_streamoff,
> >>>>> +
> >>>>> +	.vidioc_reqbufs			= v4l2_m2m_ioctl_reqbufs,
> >>>>> +	.vidioc_querybuf		= v4l2_m2m_ioctl_querybuf,
> >>>>> +	.vidioc_qbuf			= vidioc_venc_qbuf,
> >>>>> +	.vidioc_dqbuf			= vidioc_venc_dqbuf,
> >>>>> +
> >>>>> +	.vidioc_querycap		= vidioc_venc_querycap,
> >>>>> +	.vidioc_enum_fmt_vid_cap_mplane = vidioc_enum_fmt_vid_cap_mplane,
> >>>>> +	.vidioc_enum_fmt_vid_out_mplane = vidioc_enum_fmt_vid_out_mplane,
> >>>>> +	.vidioc_enum_framesizes		= vidioc_enum_framesizes,
> >>>>> +
> >>>>> +	.vidioc_try_fmt_vid_cap_mplane	= vidioc_try_fmt_vid_cap_mplane,
> >>>>> +	.vidioc_try_fmt_vid_out_mplane	= vidioc_try_fmt_vid_out_mplane,
> >>>>> +	.vidioc_expbuf			= v4l2_m2m_ioctl_expbuf,
> >>>>
> >>>> Please add vidioc_create_bufs and vidioc_prepare_buf as well.
> >>>>
> >>>
> >>> Currently we do not support these use cases, do we need to add
> >>> vidioc_create_bufs and vidioc_prepare_buf now?
> >>
> >> I would suggest you do. The vb2 framework gives it (almost) for free.
> >> prepare_buf is completely free (just add the helper) and create_bufs
> >> needs a few small changes in the queue_setup function, that's all.
> >>
> > After try to add vidioc_create_bufs directly using
> > vb2_ioctl_create_bufs, it will have problem in 
> 
> This is a m2m device, so you should use the m2m variant of this:
> v4l2_m2m_ioctl_create_bufs
> 
> That should solve this problem.
> 
> Ditto for prepare_buf: you need to use v4l2_m2m_ioctl_prepare_buf.
> 
Got it. After using v4l2_m2m_ioctl_create_bufs, the problem was solved.
Thanks for your help.

> Regards,
> 
> 	Hans







From mark.rutland at arm.com  Mon Feb 22 07:16:24 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Feb 2016 15:16:24 +0000
Subject: [PATCH v6 10/12] arm-cci: CCI-500: Work around PMU counter writes
In-Reply-To: <1453720877-24962-11-git-send-email-suzuki.poulose@arm.com>
References: <1453720877-24962-1-git-send-email-suzuki.poulose@arm.com>
 <1453720877-24962-11-git-send-email-suzuki.poulose@arm.com>
Message-ID: <20160222151623.GH3435@leverpostej>

A couple more comments for things i just realised:

> +	/*
> +	 * Now that all the counters are disabled, we can safely turn the PMU on,
> +	 * without syncing the status of the counters
> +	 */
> +	__cci_pmu_enable(cci_pmu, CCI_CNTRS_NOSYNC);

As per my other comment, __cci_pmu_enable_nosync(cci_pmu) would be
preferable.

[...]

> +		pmu_write_counter(cci_pmu,
> +				  (u32)local64_read(&event->hw.prev_count), i);

That cast can go.

Mark.


From andre.przywara at arm.com  Mon Feb 22 07:26:25 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 22 Feb 2016 15:26:25 +0000
Subject: [linux-sunxi] [PATCH v5] Fix sun7i pin assignment for IRQ's
In-Reply-To: <1456129208-11490-1-git-send-email-henry@nitronetworks.nl>
References: <1456129208-11490-1-git-send-email-henry@nitronetworks.nl>
Message-ID: <56CB28A1.9040406@arm.com>

Hi Henry,

On 22/02/16 08:20, Henry Paulissen wrote:
> After testing IRQ pins we found some bugs in the pinctrl declaration.
> Both PI* and PC* pins didn't work. PI* pins seemed to be connected
> to the wrong mux and PC* pins waren't working at all.
> 
> Please note that the A20 soc manual is contradicting between version
> and even within the same document for both the PI and PC pins.
> 
> Patch is based on testing with the hardware itself.

So I tested this on the BananaPi M1:
None of the PIxx interrupts worked before, but now with this patch on
top of 4.5-rc5 all PI pins accessible on CON3 (expect PI3, which does
not provide an EINT) trigger interrupts as expected.
Also PH0, PH1, PH2, PH20 and PH21 trigger interrupts (as before).
I cannot say anything about the PC ports, because neither PC19-PC22 nor
PH12-PH15 are on a header on the BPi, but now the mapping:
PH0-PH21: EINT0-EINT21, PI10-PI19: EINT22-EINT31
looks reasonable enough to me.

Also PI17 now worked in my latest testing, so not sure if that was a
hiccup at my test setup or the different kernel base I used at the weekend.

So dear committer, feel free to drop the comment there.

> Signed-off-by: Henry Paulissen <henry at nitronetworks.nl>

Tested-by: Andre Przywara <andre.przywara at arm.com>
Reviewed-by: Andre Przywara <andre.przywara at arm.com>

Cheers,
Andre.

> 
> ---
> 
> Changes in v2:
>     After some more testing we found irq on PI pins.
>     they where on mux6 so this is included in my patch.
> 
>     Also included is a warning for PI17, this pin was not working
>     on apritzel his bPI and he thinks it might be correlated to
>     GIC and IRQ 29.
> 
> Changes in v3:
>     Changed name from nickname to realname in email and SoB.
> 
> Changes in v4:
>     Added closing parenthesis for the C pins.
> 
> Changes in v5:
>     Added a more detailed description.
> ---
>  drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c | 33 ++++++++++++++-----------------
>  1 file changed, 15 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
> index cf1ce0c..ca7b9a3 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
> @@ -343,26 +343,22 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE4 */
> -		  SUNXI_FUNCTION(0x3, "spi2"),		/* CS0 */
> -		  SUNXI_FUNCTION_IRQ(0x6, 12)),		/* EINT12 */
> +		  SUNXI_FUNCTION(0x3, "spi2")),		/* CS0 */
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 20),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE5 */
> -		  SUNXI_FUNCTION(0x3, "spi2"),		/* CLK */
> -		  SUNXI_FUNCTION_IRQ(0x6, 13)),		/* EINT13 */
> +		  SUNXI_FUNCTION(0x3, "spi2")),		/* CLK */
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 21),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE6 */
> -		  SUNXI_FUNCTION(0x3, "spi2"),		/* MOSI */
> -		  SUNXI_FUNCTION_IRQ(0x6, 14)),		/* EINT14 */
> +		  SUNXI_FUNCTION(0x3, "spi2")),		/* MOSI */
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 22),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE7 */
> -		  SUNXI_FUNCTION(0x3, "spi2"),		/* MISO */
> -		  SUNXI_FUNCTION_IRQ(0x6, 15)),		/* EINT15 */
> +		  SUNXI_FUNCTION(0x3, "spi2")),		/* MISO */
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 23),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
> @@ -960,65 +956,66 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS0 */
>  		  SUNXI_FUNCTION(0x3, "uart5"),		/* TX */
> -		  SUNXI_FUNCTION_IRQ(0x5, 22)),		/* EINT22 */
> +		  SUNXI_FUNCTION_IRQ(0x6, 22)),		/* EINT22 */
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 11),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "spi0"),		/* CLK */
>  		  SUNXI_FUNCTION(0x3, "uart5"),		/* RX */
> -		  SUNXI_FUNCTION_IRQ(0x5, 23)),		/* EINT23 */
> +		  SUNXI_FUNCTION_IRQ(0x6, 23)),		/* EINT23 */
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 12),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "spi0"),		/* MOSI */
>  		  SUNXI_FUNCTION(0x3, "uart6"),		/* TX */
>  		  SUNXI_FUNCTION(0x4, "clk_out_a"),	/* CLK_OUT_A */
> -		  SUNXI_FUNCTION_IRQ(0x5, 24)),		/* EINT24 */
> +		  SUNXI_FUNCTION_IRQ(0x6, 24)),		/* EINT24 */
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 13),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "spi0"),		/* MISO */
>  		  SUNXI_FUNCTION(0x3, "uart6"),		/* RX */
>  		  SUNXI_FUNCTION(0x4, "clk_out_b"),	/* CLK_OUT_B */
> -		  SUNXI_FUNCTION_IRQ(0x5, 25)),		/* EINT25 */
> +		  SUNXI_FUNCTION_IRQ(0x6, 25)),		/* EINT25 */
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 14),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS1 */
>  		  SUNXI_FUNCTION(0x3, "ps2"),		/* SCK1 */
>  		  SUNXI_FUNCTION(0x4, "timer4"),	/* TCLKIN0 */
> -		  SUNXI_FUNCTION_IRQ(0x5, 26)),		/* EINT26 */
> +		  SUNXI_FUNCTION_IRQ(0x6, 26)),		/* EINT26 */
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 15),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS1 */
>  		  SUNXI_FUNCTION(0x3, "ps2"),		/* SDA1 */
>  		  SUNXI_FUNCTION(0x4, "timer5"),	/* TCLKIN1 */
> -		  SUNXI_FUNCTION_IRQ(0x5, 27)),		/* EINT27 */
> +		  SUNXI_FUNCTION_IRQ(0x6, 27)),		/* EINT27 */
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 16),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS0 */
>  		  SUNXI_FUNCTION(0x3, "uart2"),		/* RTS */
> -		  SUNXI_FUNCTION_IRQ(0x5, 28)),		/* EINT28 */
> +		  SUNXI_FUNCTION_IRQ(0x6, 28)),		/* EINT28 */
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 17),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "spi1"),		/* CLK */
>  		  SUNXI_FUNCTION(0x3, "uart2"),		/* CTS */
> -		  SUNXI_FUNCTION_IRQ(0x5, 29)),		/* EINT29 */
> +		  SUNXI_FUNCTION_IRQ(0x6, 29)),		/* EINT29 */
> +		  /* EINT29 might not work - more testing needed */
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 18),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "spi1"),		/* MOSI */
>  		  SUNXI_FUNCTION(0x3, "uart2"),		/* TX */
> -		  SUNXI_FUNCTION_IRQ(0x5, 30)),		/* EINT30 */
> +		  SUNXI_FUNCTION_IRQ(0x6, 30)),		/* EINT30 */
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 19),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
>  		  SUNXI_FUNCTION(0x2, "spi1"),		/* MISO */
>  		  SUNXI_FUNCTION(0x3, "uart2"),		/* RX */
> -		  SUNXI_FUNCTION_IRQ(0x5, 31)),		/* EINT31 */
> +		  SUNXI_FUNCTION_IRQ(0x6, 31)),		/* EINT31 */
>  	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 20),
>  		  SUNXI_FUNCTION(0x0, "gpio_in"),
>  		  SUNXI_FUNCTION(0x1, "gpio_out"),
> 


From mika.penttila at nextfour.com  Mon Feb 22 07:34:07 2016
From: mika.penttila at nextfour.com (=?UTF-8?Q?Mika_Penttil=c3=a4?=)
Date: Mon, 22 Feb 2016 17:34:07 +0200
Subject: arm: set_memory_xx fixes patch missing?
In-Reply-To: <20160222150911.GA25429@luxor.wired.org>
References: <20160222150911.GA25429@luxor.wired.org>
Message-ID: <56CB2A6F.5060006@nextfour.com>

On 22.02.2016 17:09, Paolo Pisati wrote:
> What's happened to the arm side of this patch:
>
> http://lkml.iu.edu/hypermail/linux/kernel/1601.2/04934.html
>
> the arm64 code is already in Linus's tree, while it seems like the arm part was
> lost and forgotten, and i don't see it in rmk's patch queue.

Hi,

Yes, it for sure should go in, please apply:

----------------------------------------------------
From: Mika Penttil? <mika.penttila at nextfour.com>

Allow zero size updates. This makes set_memory_xx() consistent with x86, s390 and arm64.

Signed-off-by: Mika Penttil? mika.penttila at nextfour.com

---
 arch/arm/mm/pageattr.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mm/pageattr.c b/arch/arm/mm/pageattr.c
index be7fe4b..9edf6b0 100644
--- a/arch/arm/mm/pageattr.c
+++ b/arch/arm/mm/pageattr.c
@@ -49,6 +49,9 @@ static int change_memory_common(unsigned long addr, int numpages,
 		WARN_ON_ONCE(1);
 	}
 
+	if (!numpages)
+		return 0;
+
 	if (start < MODULES_VADDR || start >= MODULES_END)
 		return -EINVAL;
 
-- 1.9.1




From robert.jarzmik at free.fr  Mon Feb 22 07:35:17 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Mon, 22 Feb 2016 16:35:17 +0100
Subject: [PATCH v1] arm: pxa: fix DT node name for PXA27X usb
In-Reply-To: <1456139297-5854-1-git-send-email-ynvich@gmail.com> (Sergei
 Ianovich's message of "Mon, 22 Feb 2016 14:08:17 +0300")
References: <1456139297-5854-1-git-send-email-ynvich@gmail.com>
Message-ID: <87oab8wyfe.fsf@belgarion.home>

Sergei Ianovich <ynvich at gmail.com> writes:

> Without this patch I am getting an error:
> ---8<---
> [   15.709742] ohci-pxa27x: OHCI PXA27x/PXA3x driver
> [   15.737150] pxa27x-ohci: probe of 4c000000.ohci failed with error -2
> ---8<---
>
> The error is generated in drivers/usb/host/ohci-pxa27x.c at line 441:
> ---8<---
> 441:	usb_clk = devm_clk_get(&pdev->dev, NULL);
> 442:	if (IS_ERR(usb_clk))
> 443:		return PTR_ERR(usb_clk);
> ---8<---
>
> The error is caused by different names for the same DT node in pxa2xx.dtsi
> and pxa27x.dtsi.
>
> Signed-off-by: Sergei Ianovich <ynvich at gmail.com>
> CC: Robert Jarzmik <robert.jarzmik at free.fr>
Hi Sergei,

You're right, I haven't seen the pxa2xx.dtsi statement before.

As such, could you amend a bit your patch please to :
 - add:
Fixes: 0ec1939668e5 ("ARM: dts: pxa: add the usb host controller")
 - make the same change in pxa3xx.dtsi, as the same error is there
 - and more globally align pxa2xx.dtsi, pxa27x.dtsi and pxa3xx.dtsi
 - remove the compatible, reg, interrupts and status from both pxa27x.dtsi and
   pxa3xx.dtsi as they are redundant with the included pxa2xxx.dsti one

I'm even wondering if the proper change wouldn't be to scrap the ohci
declarations from pxa27x.dtsi and pxa3xx.dtsi, and only add the "clocks"
property to pxa2xx.dtsi ...

Cheers.

--
Robert


From tomi.valkeinen at ti.com  Mon Feb 22 07:41:37 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Mon, 22 Feb 2016 17:41:37 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CACRpkdaXFUCR5=5mS28_4Dx_LfzqV13zwT=vVeJwuOzm_rGRBQ@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <56C438DA.5040109@ti.com>
 <CACRpkdZ+G17hmVP8AejL7NTqg7k0SBC5kgF55ASjD+kfuGFJhQ@mail.gmail.com>
 <20160217213250.GK19428@n2100.arm.linux.org.uk> <56C5B080.9090007@ti.com>
 <CACRpkdaXFUCR5=5mS28_4Dx_LfzqV13zwT=vVeJwuOzm_rGRBQ@mail.gmail.com>
Message-ID: <56CB2C31.5040703@ti.com>

On 22/02/16 00:39, Linus Walleij wrote:
> On Thu, Feb 18, 2016 at 12:52 PM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> 
>> For panels we need DT fragments. The question is where these fragments
>> are and, possibly, who who loads them.
> 
> I hacked something up that augments the device tree from the kernel,
> given you have a node with all the props you want to augment, tell me
> what you think of this and whether I should continue in this direction...
> also the DT people need to be involved:

What you have there is almost like a legacy board file, isn't it? It's
just passing DT data forward, instead of device platform data. In fact,
if the driver in question supports platform data too, you could as well
generate platform data for it (but I'm not saying that's a better option).

After thinking this a bit and discussing it with Laurent P., generally
speaking I still think that the only sane option is that the bootloader
does any detection needed and provides the kernel a .dtb that contains
the HW that is connected. No board specific drivers are needed on the
kernel side.

In some cases userspace loaded DT overlays may be fine, if the userspace
can do the detection and the device in question is not somehow critical
to operation. But I think displays are critical, and afaik in Versatile
case the userspace can't even do the detection (?).

The third option is to have board specific display handling code and the
display HW data in the kernel, as you've done in the patches.

But, of course, which option should be used for which board is not
always clear...

What bootloader is used on Versatile? If it's some proprietary loader
which can't be changed, then the bootloader option is out, and I guess
it points to the third option, i.e. either the version in this patch or
the earlier version. If it's u-boot, I would suggest going for the
bootloader option.

Afaik u-boot doesn't support combining DT fragments yet. But (also
afaik) the u-boot maintainer is ok with the idea. And I know there are
others (for example TI) interested in the same functionality.

Now, adding that support might take some time, and in the meantime it'd
be good to get the HW working with kernel with a temporary solution. To
do that, my suggestion is basically "any solution which requires no
(temporary) changes to .dts".

While I don't like too much the solution in the patch here, it's all
inside kernel code and can be dropped easily, right? If we would merge
the the multi-endpoint solution you had in the earlier patch, you would
have to support that .dts in the future too.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160222/75449315/attachment.sig>

From mark.rutland at arm.com  Mon Feb 22 07:43:15 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Feb 2016 15:43:15 +0000
Subject: [PATCH] arm*: efi: drop permanent mapping of the UEFI System table
In-Reply-To: <1456153179-27214-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456153179-27214-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160222154314.GJ3435@leverpostej>

On Mon, Feb 22, 2016 at 03:59:39PM +0100, Ard Biesheuvel wrote:
> The permanent, writable mapping of the UEFI System table is only
> referenced during invocations of UEFI Runtime Services, at which time
> the UEFI virtual mapping is available, which also covers the system
> table (since the runtime services themselves need access to it)

I'm not sure it's strictly true that the runtime services themselves
need access to the system table. Why would that be necessary? Are
runtime services mandated to indirect calls via the system table?

I would expect that the EFI system table and EFI runtime services table
are not in EfiConventionalMemory, but I'm not sure that we have the
guarnatee that they're both in EfiRuntimeServices* memory..

>From the spec, I couldn't find a mandate that the system table (nor the
runtime services table) were in a region of EfiRuntimeServicesData
memory. I suspect I'm looking in the wrong place...

> So instead of creating this permanent mapping, record the virtual
> address of the system table inside the UEFI virtual mapping, and
> use that instead. This protects the contents of the system table
> from inadvertent (or deliberate) modification.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
> 
> Something I spotted while working on the memory attribute table stuff.
> Since this is low hanging fruit and otherwise completely unrelated to it,
> I am posting it as a separate patch
> 
>  drivers/firmware/efi/arm-init.c    |  2 ++
>  drivers/firmware/efi/arm-runtime.c | 24 ++++++++++----------
>  2 files changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
> index 022f11157acd..e995d61da747 100644
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@ -85,6 +85,8 @@ static int __init uefi_init(void)
>  			efi.systab->hdr.revision >> 16,
>  			efi.systab->hdr.revision & 0xffff);
>  
> +	efi.runtime_version = efi.systab->hdr.revision;
> +
>  	/* Show what we know for posterity */
>  	c16 = early_memremap_ro(efi_to_phys(efi.systab->fw_vendor),
>  				sizeof(vendor) * sizeof(efi_char16_t));
> diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
> index 848ede1587dc..6ce13d6b7122 100644
> --- a/drivers/firmware/efi/arm-runtime.c
> +++ b/drivers/firmware/efi/arm-runtime.c
> @@ -64,6 +64,16 @@ static bool __init efi_virtmap_init(void)
>  				&phys, ret);
>  			return false;
>  		}
> +		/*
> +		 * If this entry covers the address of the UEFI system table,
> +		 * calculate and record its virtual address.
> +		 */
> +		if (efi_system_table >= phys &&
> +		    efi_system_table < phys + (md->num_pages * EFI_PAGE_SIZE)) {
> +			efi.systab = (void *)(efi_system_table - phys +
> +					      md->virt_addr);
> +			set_bit(EFI_SYSTEM_TABLES, &efi.flags);
> +		}

It seems very odd to me to set this given it's currently unused, and we
don't have permanent access to the table. That sounds like we're just
setting ourselves up for future fragility as users appear.

Thanks,
Mark.



From matthias.bgg at gmail.com  Mon Feb 22 07:45:17 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Mon, 22 Feb 2016 16:45:17 +0100
Subject: [PATCH 1/8] arm64: move acpi/dt decision earlier in boot process
In-Reply-To: <1456148818-26257-2-git-send-email-aleksey.makarov@linaro.org>
References: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
 <1456148818-26257-2-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <56CB2D0D.3090408@gmail.com>



On 22/02/16 14:46, Aleksey Makarov wrote:
> From: Leif Lindholm <leif.lindholm at linaro.org>
>
> In order to support selecting earlycon via either ACPI or DT, move
> the decision on whether to attempt ACPI configuration into the
> early_param handling. Then make acpi_boot_table_init() bail out if
> acpi_disabled.
>
> Signed-off-by: Leif Lindholm <leif.lindholm at linaro.org>
> ---
>   arch/arm64/kernel/acpi.c | 54 ++++++++++++++++++++++++++----------------------
>   1 file changed, 29 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index d1ce8e2..7a944f7 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -44,6 +44,19 @@ EXPORT_SYMBOL(acpi_pci_disabled);
>   static bool param_acpi_off __initdata;
>   static bool param_acpi_force __initdata;
>
> +static int __init dt_scan_depth1_nodes(unsigned long node,
> +				       const char *uname, int depth,
> +				       void *data)
> +{
> +	/*
> +	 * Return 1 as soon as we encounter a node at depth 1 that is
> +	 * not the /chosen node.
> +	 */
> +	if (depth == 1 && (strcmp(uname, "chosen") != 0))
> +		return 1;
> +	return 0;
> +}
> +
>   static int __init parse_acpi(char *arg)
>   {
>   	if (!arg)
> @@ -57,23 +70,27 @@ static int __init parse_acpi(char *arg)
>   	else
>   		return -EINVAL;	/* Core will print when we return error */
>
> -	return 0;
> -}
> -early_param("acpi", parse_acpi);
> +	/*
> +	 * Enable ACPI instead of device tree unless
> +	 * - ACPI has been disabled explicitly (acpi=off), or
> +	 * - the device tree is not empty (it has more than just a /chosen node)
> +	 *   and ACPI has not been force enabled (acpi=force)
> +	 */
> +	if (param_acpi_off ||
> +	    (!param_acpi_force && of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
> +		return 0;
>
> -static int __init dt_scan_depth1_nodes(unsigned long node,
> -				       const char *uname, int depth,
> -				       void *data)
> -{
>   	/*
> -	 * Return 1 as soon as we encounter a node at depth 1 that is
> -	 * not the /chosen node.
> +	 * ACPI is disabled at this point. Enable it in order to parse
> +	 * the ACPI tables and carry out sanity checks
>   	 */
> -	if (depth == 1 && (strcmp(uname, "chosen") != 0))
> -		return 1;
> +	enable_acpi();
> +

So we only enable ACPI if we pass acpi=force as kernel parameter?
I'm not sure if this is what you wanted to do.

Regards,
Matthias


From linux at arm.linux.org.uk  Mon Feb 22 07:51:29 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Feb 2016 15:51:29 +0000
Subject: [PATCH v2 1/2] drm: Improve drm_of_component_probe() to
 correctly handle ports and remote ports.
In-Reply-To: <20160222115147.GR1123@e106497-lin.cambridge.arm.com>
References: <1448029325-14602-1-git-send-email-Liviu.Dudau@arm.com>
 <1448029325-14602-2-git-send-email-Liviu.Dudau@arm.com>
 <20160222115147.GR1123@e106497-lin.cambridge.arm.com>
Message-ID: <20160222155128.GE19428@n2100.arm.linux.org.uk>

On Mon, Feb 22, 2016 at 11:51:47AM +0000, Liviu Dudau wrote:
> On Fri, Nov 20, 2015 at 02:22:04PM +0000, Liviu Dudau wrote:
> > Rockchip DRM driver cannot use the same compare_of() function to
> > match ports and remote ports (aka encoders) as their OF sub-trees
> > look different. Add a second compare function to be used when encoders
> > are added to the component framework and patch the existing users of
> > the function accordingly.
> > 
> > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> 
> Russell,
> 
> Resurecting this old patch from around Christmas time (bad time for patch
> review).
> 
> Are you happy enough with this version to re-issue the Ack or do you think
> I still need to work on it?

What I'd like to see is the patch reworked, because:

> > +		component_match_add(dev, &match, compare_port, port);
> > +		/*
> > +		 * component_match_add keeps a reference to the port
> > +		 * variable, so we need to keep the reference count
> > +		 * increment from of_parse_phandle()
> > +		 */
...
> > +			component_match_add(dev, &match, compare_encoder, remote);
> > +			/*
> > +			 * component_match_add keeps a reference to the port
> > +			 * variable, so we need to keep the reference count
> > +			 * increment from of_graph_get_remote_port_parent()
> > +			 */

This problem no longer exists.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From linus.walleij at linaro.org  Mon Feb 22 07:54:15 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Mon, 22 Feb 2016 16:54:15 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56CB2C31.5040703@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <56C438DA.5040109@ti.com>
 <CACRpkdZ+G17hmVP8AejL7NTqg7k0SBC5kgF55ASjD+kfuGFJhQ@mail.gmail.com>
 <20160217213250.GK19428@n2100.arm.linux.org.uk>
 <56C5B080.9090007@ti.com>
 <CACRpkdaXFUCR5=5mS28_4Dx_LfzqV13zwT=vVeJwuOzm_rGRBQ@mail.gmail.com>
 <56CB2C31.5040703@ti.com>
Message-ID: <CACRpkdbO1+nWJOce8eC-G=tKrH3a2OEqQ-ro=LK88RhNrJ5cfQ@mail.gmail.com>

On Mon, Feb 22, 2016 at 4:41 PM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:

> After thinking this a bit and discussing it with Laurent P., generally
> speaking I still think that the only sane option is that the bootloader
> does any detection needed and provides the kernel a .dtb that contains
> the HW that is connected. No board specific drivers are needed on the
> kernel side.
>
> In some cases userspace loaded DT overlays may be fine, if the userspace
> can do the detection and the device in question is not somehow critical
> to operation. But I think displays are critical, and afaik in Versatile
> case the userspace can't even do the detection (?).
>
> The third option is to have board specific display handling code and the
> display HW data in the kernel, as you've done in the patches.

Yeah correct...

> But, of course, which option should be used for which board is not
> always clear...
>
> What bootloader is used on Versatile?

It's U-boot indeed. Not that I've tried to compile or use it, I got it
as binary from ARM.

> If it's some proprietary loader
> which can't be changed, then the bootloader option is out, and I guess
> it points to the third option, i.e. either the version in this patch or
> the earlier version. If it's u-boot, I would suggest going for the
> bootloader option.
>
> Afaik u-boot doesn't support combining DT fragments yet. But (also
> afaik) the u-boot maintainer is ok with the idea. And I know there are
> others (for example TI) interested in the same functionality.

Hm OK.... so the bootloader need to be better at augmenting device
trees than the kernel. Well... The problem is that there are a bunch
of deployed systems out there and they all need to have their boot loader
updated then, which may be OK since it's ARM development boards
but I don't know.

> Now, adding that support might take some time, and in the meantime it'd
> be good to get the HW working with kernel with a temporary solution. To
> do that, my suggestion is basically "any solution which requires no
> (temporary) changes to .dts".
>
> While I don't like too much the solution in the patch here, it's all
> inside kernel code and can be dropped easily, right? If we would merge
> the the multi-endpoint solution you had in the earlier patch, you would
> have to support that .dts in the future too.

To go with this solution I need to extend the drivers/of library to be
able to update properties properly instead of this hack, and that is
non-reversible if we start to use it.

It is not really an overlay because the DT stuff is dynamically
augmented by the kernel, not taken from somewhere else.

Yours,
Linus Walleij


From ard.biesheuvel at linaro.org  Mon Feb 22 07:56:57 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 16:56:57 +0100
Subject: [PATCH] arm*: efi: drop permanent mapping of the UEFI System table
In-Reply-To: <20160222154314.GJ3435@leverpostej>
References: <1456153179-27214-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160222154314.GJ3435@leverpostej>
Message-ID: <CAKv+Gu_pnjL557dE1xez_y2tESOjZj9_2XEbNtm_b4yAA-WdYg@mail.gmail.com>

On 22 February 2016 at 16:43, Mark Rutland <mark.rutland at arm.com> wrote:
> On Mon, Feb 22, 2016 at 03:59:39PM +0100, Ard Biesheuvel wrote:
>> The permanent, writable mapping of the UEFI System table is only
>> referenced during invocations of UEFI Runtime Services, at which time
>> the UEFI virtual mapping is available, which also covers the system
>> table (since the runtime services themselves need access to it)
>
> I'm not sure it's strictly true that the runtime services themselves
> need access to the system table. Why would that be necessary? Are
> runtime services mandated to indirect calls via the system table?
>

They don't need access per se, but they are allowed to reference it,
and so the memory remapping layer must make it accessible after
SetVirtualAddressMap(). The spec lists explicitly which fields are
still valid after ExitBootServices()

> I would expect that the EFI system table and EFI runtime services table
> are not in EfiConventionalMemory, but I'm not sure that we have the
> guarnatee that they're both in EfiRuntimeServices* memory..
>

SetVirtualAddressMap() is a runtime service, and one of the things it
does is update the pointers in the system table, hence it must be
located in RuntimeService memory, because anything else may be gone by
this time.

> From the spec, I couldn't find a mandate that the system table (nor the
> runtime services table) were in a region of EfiRuntimeServicesData
> memory. I suspect I'm looking in the wrong place...
>

We should clarify it if it is not clear (or if I turn out to be wrong)

>> So instead of creating this permanent mapping, record the virtual
>> address of the system table inside the UEFI virtual mapping, and
>> use that instead. This protects the contents of the system table
>> from inadvertent (or deliberate) modification.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> ---
>>
>> Something I spotted while working on the memory attribute table stuff.
>> Since this is low hanging fruit and otherwise completely unrelated to it,
>> I am posting it as a separate patch
>>
>>  drivers/firmware/efi/arm-init.c    |  2 ++
>>  drivers/firmware/efi/arm-runtime.c | 24 ++++++++++----------
>>  2 files changed, 14 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
>> index 022f11157acd..e995d61da747 100644
>> --- a/drivers/firmware/efi/arm-init.c
>> +++ b/drivers/firmware/efi/arm-init.c
>> @@ -85,6 +85,8 @@ static int __init uefi_init(void)
>>                       efi.systab->hdr.revision >> 16,
>>                       efi.systab->hdr.revision & 0xffff);
>>
>> +     efi.runtime_version = efi.systab->hdr.revision;
>> +
>>       /* Show what we know for posterity */
>>       c16 = early_memremap_ro(efi_to_phys(efi.systab->fw_vendor),
>>                               sizeof(vendor) * sizeof(efi_char16_t));
>> diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
>> index 848ede1587dc..6ce13d6b7122 100644
>> --- a/drivers/firmware/efi/arm-runtime.c
>> +++ b/drivers/firmware/efi/arm-runtime.c
>> @@ -64,6 +64,16 @@ static bool __init efi_virtmap_init(void)
>>                               &phys, ret);
>>                       return false;
>>               }
>> +             /*
>> +              * If this entry covers the address of the UEFI system table,
>> +              * calculate and record its virtual address.
>> +              */
>> +             if (efi_system_table >= phys &&
>> +                 efi_system_table < phys + (md->num_pages * EFI_PAGE_SIZE)) {
>> +                     efi.systab = (void *)(efi_system_table - phys +
>> +                                           md->virt_addr);
>> +                     set_bit(EFI_SYSTEM_TABLES, &efi.flags);
>> +             }
>
> It seems very odd to me to set this given it's currently unused, and we
> don't have permanent access to the table. That sounds like we're just
> setting ourselves up for future fragility as users appear.
>

I wondered about the purpose as well. It is only ever set, and never
tested (until this patch)

@Matt: any thoughts?


From Liviu.Dudau at arm.com  Mon Feb 22 07:57:40 2016
From: Liviu.Dudau at arm.com (Liviu Dudau)
Date: Mon, 22 Feb 2016 15:57:40 +0000
Subject: [PATCH v2 1/2] drm: Improve drm_of_component_probe() to
 correctly handle ports and remote ports.
In-Reply-To: <20160222155128.GE19428@n2100.arm.linux.org.uk>
References: <1448029325-14602-1-git-send-email-Liviu.Dudau@arm.com>
 <1448029325-14602-2-git-send-email-Liviu.Dudau@arm.com>
 <20160222115147.GR1123@e106497-lin.cambridge.arm.com>
 <20160222155128.GE19428@n2100.arm.linux.org.uk>
Message-ID: <20160222155740.GU1123@e106497-lin.cambridge.arm.com>

On Mon, Feb 22, 2016 at 03:51:29PM +0000, Russell King - ARM Linux wrote:
> On Mon, Feb 22, 2016 at 11:51:47AM +0000, Liviu Dudau wrote:
> > On Fri, Nov 20, 2015 at 02:22:04PM +0000, Liviu Dudau wrote:
> > > Rockchip DRM driver cannot use the same compare_of() function to
> > > match ports and remote ports (aka encoders) as their OF sub-trees
> > > look different. Add a second compare function to be used when encoders
> > > are added to the component framework and patch the existing users of
> > > the function accordingly.
> > > 
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau at arm.com>
> > 
> > Russell,
> > 
> > Resurecting this old patch from around Christmas time (bad time for patch
> > review).
> > 
> > Are you happy enough with this version to re-issue the Ack or do you think
> > I still need to work on it?
> 
> What I'd like to see is the patch reworked, because:
> 
> > > +		component_match_add(dev, &match, compare_port, port);
> > > +		/*
> > > +		 * component_match_add keeps a reference to the port
> > > +		 * variable, so we need to keep the reference count
> > > +		 * increment from of_parse_phandle()
> > > +		 */
> ...
> > > +			component_match_add(dev, &match, compare_encoder, remote);
> > > +			/*
> > > +			 * component_match_add keeps a reference to the port
> > > +			 * variable, so we need to keep the reference count
> > > +			 * increment from of_graph_get_remote_port_parent()
> > > +			 */
> 
> This problem no longer exists.

Fair enough, I will send a v3 version.

Thanks,
Liviu

> 
> -- 
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?


From bharat.kumar.gogada at xilinx.com  Mon Feb 22 08:01:15 2016
From: bharat.kumar.gogada at xilinx.com (Bharat Kumar Gogada)
Date: Mon, 22 Feb 2016 16:01:15 +0000
Subject: [PATCH V4 5/5] Microblaze: Modifying microblaze PCI subsytem to
 support  generic Xilinx  AXI PCIe Host Bridge IP driver
In-Reply-To: <1455208091-15556-6-git-send-email-bharatku@xilinx.com>
References: <1455208091-15556-1-git-send-email-bharatku@xilinx.com>
 <1455208091-15556-6-git-send-email-bharatku@xilinx.com>
Message-ID: <8520D5D51A55D047800579B09414719825884643@XAP-PVEXMBX01.xlnx.xilinx.com>

Ping

> Subject: [PATCH V4 5/5] Microblaze: Modifying microblaze PCI subsytem to
> support generic Xilinx AXI PCIe Host Bridge IP driver
> 
> This patch does required modifications to microblaze PCI subsystem, to work
> with generic driver (drivers/pci/host/pcie-xilinx.c) on Microblaze and Zynq.
> 
> Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
> ---
> Changes:
> Removed pcibios_get_phb_of_node in pci-common.c, using generic version
> instead.
> Modified pcibios_fixup_bus in pci-common.c, as per generic architecuture.
> Modified pcibios_align_resource in pci-common.c, as per generic
> architecuture, removed temporary variable.
> Removed pci_domain_nr in pci-common.c, instead using generic code.
> Added pcibios_add_device in pci-common.c, as per generic architecuture.
> Adding Kernel configuration in arch/microblaze as required for generic PCI
> domains.
> Added kernel configuration for driver to support Microblaze.
> ---
>  arch/microblaze/Kconfig          |  3 +++
>  arch/microblaze/pci/pci-common.c | 56 +++++++---------------------------------
>  drivers/pci/host/Kconfig         |  2 +-
>  3 files changed, 14 insertions(+), 47 deletions(-)
> 
> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig index
> 0bce820..c3702b9 100644
> --- a/arch/microblaze/Kconfig
> +++ b/arch/microblaze/Kconfig
> @@ -271,6 +271,9 @@ config PCI
>  config PCI_DOMAINS
>  	def_bool PCI
> 
> +config PCI_DOMAINS_GENERIC
> +	def_bool PCI_DOMAINS
> +
>  config PCI_SYSCALL
>  	def_bool PCI
> 
> diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-
> common.c
> index ae838ed..35654be 100644
> --- a/arch/microblaze/pci/pci-common.c
> +++ b/arch/microblaze/pci/pci-common.c
> @@ -123,17 +123,6 @@ unsigned long pci_address_to_pio(phys_addr_t
> address)  }  EXPORT_SYMBOL_GPL(pci_address_to_pio);
> 
> -/*
> - * Return the domain number for this bus.
> - */
> -int pci_domain_nr(struct pci_bus *bus)
> -{
> -	struct pci_controller *hose = pci_bus_to_host(bus);
> -
> -	return hose->global_number;
> -}
> -EXPORT_SYMBOL(pci_domain_nr);
> -
>  /* This routine is meant to be used early during boot, when the
>   * PCI bus numbers have not yet been assigned, and you need to
>   * issue PCI config cycles to an OF device.
> @@ -863,26 +852,10 @@ void pcibios_setup_bus_devices(struct pci_bus
> *bus)
> 
>  void pcibios_fixup_bus(struct pci_bus *bus)  {
> -	/* When called from the generic PCI probe, read PCI<->PCI bridge
> -	 * bases. This is -not- called when generating the PCI tree from
> -	 * the OF device-tree.
> -	 */
> -	if (bus->self != NULL)
> -		pci_read_bridge_bases(bus);
> -
> -	/* Now fixup the bus bus */
> -	pcibios_setup_bus_self(bus);
> -
> -	/* Now fixup devices on that bus */
> -	pcibios_setup_bus_devices(bus);
> +	/* nothing to do */
>  }
>  EXPORT_SYMBOL(pcibios_fixup_bus);
> 
> -static int skip_isa_ioresource_align(struct pci_dev *dev) -{
> -	return 0;
> -}
> -
>  /*
>   * We need to avoid collisions with `mirrored' VGA ports
>   * and other strange ISA hardware, so we always want the @@ -899,20
> +872,18 @@ static int skip_isa_ioresource_align(struct pci_dev *dev)
> resource_size_t pcibios_align_resource(void *data, const struct resource
> *res,
>  				resource_size_t size, resource_size_t align)  {
> -	struct pci_dev *dev = data;
> -	resource_size_t start = res->start;
> -
> -	if (res->flags & IORESOURCE_IO) {
> -		if (skip_isa_ioresource_align(dev))
> -			return start;
> -		if (start & 0x300)
> -			start = (start + 0x3ff) & ~0x3ff;
> -	}
> -
> -	return start;
> +	return res->start;
>  }
>  EXPORT_SYMBOL(pcibios_align_resource);
> 
> +int pcibios_add_device(struct pci_dev *dev) {
> +	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(pcibios_add_device);
> +
>  /*
>   * Reparent resource children of pr that conflict with res
>   * under res, and make res replace those children.
> @@ -1333,13 +1304,6 @@ static void pcibios_setup_phb_resources(struct
> pci_controller *hose,
>  		 (unsigned long)hose->io_base_virt - _IO_BASE);  }
> 
> -struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus) -{
> -	struct pci_controller *hose = bus->sysdata;
> -
> -	return of_node_get(hose->dn);
> -}
> -
>  static void pcibios_scan_phb(struct pci_controller *hose)  {
>  	LIST_HEAD(resources);
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index
> d5e58ba..7c56c2e 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -79,7 +79,7 @@ config PCI_KEYSTONE
> 
>  config PCIE_XILINX
>  	bool "Xilinx AXI PCIe host bridge support"
> -	depends on ARCH_ZYNQ
> +	depends on ARCH_ZYNQ || MICROBLAZE
>  	help
>  	  Say 'Y' here if you want kernel to support the Xilinx AXI PCIe
>  	  Host Bridge driver.
> --
> 2.1.1



From jeremy.linton at arm.com  Mon Feb 22 07:39:28 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Mon, 22 Feb 2016 09:39:28 -0600
Subject: [PATCH v3 2/2] arm64: Mark kernel page ranges contiguous
In-Reply-To: <CAKv+Gu8YYuE78QAzgFFZgPOz4o_4L70Ko-vO-GKwSFeYdNv+vA@mail.gmail.com>
References: <1455903983-23910-1-git-send-email-jeremy.linton@arm.com>
 <1455903983-23910-3-git-send-email-jeremy.linton@arm.com>
 <CAKv+Gu8YYuE78QAzgFFZgPOz4o_4L70Ko-vO-GKwSFeYdNv+vA@mail.gmail.com>
Message-ID: <56CB2BB0.8030409@arm.com>

On 02/22/2016 04:28 AM, Ard Biesheuvel wrote:
> On 19 February 2016 at 18:46, Jeremy Linton <jeremy.linton at arm.com> wrote:
>> With 64k pages, the next larger segment size is 512M. The linux
>> kernel also uses different protection flags to cover its code and data.
>> Because of these requirements, the vast majority of the kernel code and
>> data structures end up being mapped with 64k pages instead of the larger
>> pages common with a 4k page kernel.
>>
>> Recent ARM processors support a contiguous bit in the
>> page tables which allows a TLB to cover a range larger than a
>> single PTE if that range is mapped into physically contiguous
>> RAM.
>>
>> So, for the kernel its a good idea to set this flag. Some basic
>> micro benchmarks show it can significantly reduce the number of
>> L1 dTLB refills.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
>
> Tested on 4k/3 levels, and the page tables look correct to me
>
> Tested-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

Thanks,

>
> You didn't answer my question though, regarding implementing this at
> the PMD level for 16k pages kernels, so that we can use 1 GB chunks
> for mapping system RAM. Would that just be a matter of doing the exact
> same thing at the PMD level? Or is it more complicated than that?
>

AFAIK, yes. It should be similar with the PMD ranges being unmarked on 
permission change or PTE allocation.



From bhelgaas at google.com  Mon Feb 22 08:03:33 2016
From: bhelgaas at google.com (Bjorn Helgaas)
Date: Mon, 22 Feb 2016 10:03:33 -0600
Subject: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot
 for X-Gene v1
In-Reply-To: <CADaLNDmsW+5-EEvTMGOyCGmKWYS-trx74pQ87czkrSWqNgrHWw@mail.gmail.com>
References: <1455069384-22323-1-git-send-email-dhdang@apm.com>
 <CADaLNDmsW+5-EEvTMGOyCGmKWYS-trx74pQ87czkrSWqNgrHWw@mail.gmail.com>
Message-ID: <CAErSpo6nNKeg+v7SGLieBOi0f+5U_G03T6F7VtSw1N_VbjA2rg@mail.gmail.com>

On Sat, Feb 20, 2016 at 1:47 PM, Duc Dang <dhdang at apm.com> wrote:
> On Tue, Feb 9, 2016 at 5:56 PM, Duc Dang <dhdang at apm.com> wrote:
>> This patch makes pci-xgene-msi driver ACPI-aware and provides
>> MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode.
>
> Hi Bjorn,
>
> Are you planning to take this patch into your tree?

Sorry, I haven't had a chance to look at this yet.  I had a sick
daughter last week, so I'm even farther behind than usual.

When I get to it, I'll be asking questions like:

  - Does this correspond to some analogous x86 code?
  - Is there something unique about arm64 or X-Gene that means it
needs special code?

I don't really understand the arm64/ACPI strategy yet, so I'll be
looking first for generic solutions that work across x86/ia64/arm64,
and justifications for the inevitable exceptions.

>> Signed-off-by: Duc Dang <dhdang at apm.com>
>> ---
>>  drivers/pci/host/pci-xgene-msi.c | 35 ++++++++++++++++++++++++++++++++---
>>  1 file changed, 32 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
>> index a6456b5..466aa93 100644
>> --- a/drivers/pci/host/pci-xgene-msi.c
>> +++ b/drivers/pci/host/pci-xgene-msi.c
>> @@ -24,6 +24,7 @@
>>  #include <linux/pci.h>
>>  #include <linux/platform_device.h>
>>  #include <linux/of_pci.h>
>> +#include <linux/acpi.h>
>>
>>  #define MSI_IR0                        0x000000
>>  #define MSI_INT0               0x800000
>> @@ -39,7 +40,7 @@ struct xgene_msi_group {
>>  };
>>
>>  struct xgene_msi {
>> -       struct device_node      *node;
>> +       struct fwnode_handle    *fwnode;
>>         struct irq_domain       *inner_domain;
>>         struct irq_domain       *msi_domain;
>>         u64                     msi_addr;
>> @@ -249,6 +250,13 @@ static const struct irq_domain_ops msi_domain_ops = {
>>         .free   = xgene_irq_domain_free,
>>  };
>>
>> +#ifdef CONFIG_ACPI
>> +static struct fwnode_handle *xgene_msi_get_fwnode(struct device *dev)
>> +{
>> +       return xgene_msi_ctrl.fwnode;
>> +}
>> +#endif
>> +
>>  static int xgene_allocate_domains(struct xgene_msi *msi)
>>  {
>>         msi->inner_domain = irq_domain_add_linear(NULL, NR_MSI_VEC,
>> @@ -256,7 +264,7 @@ static int xgene_allocate_domains(struct xgene_msi *msi)
>>         if (!msi->inner_domain)
>>                 return -ENOMEM;
>>
>> -       msi->msi_domain = pci_msi_create_irq_domain(of_node_to_fwnode(msi->node),
>> +       msi->msi_domain = pci_msi_create_irq_domain(msi->fwnode,
>>                                                     &xgene_msi_domain_info,
>>                                                     msi->inner_domain);
>>
>> @@ -265,6 +273,9 @@ static int xgene_allocate_domains(struct xgene_msi *msi)
>>                 return -ENOMEM;
>>         }
>>
>> +#ifdef CONFIG_ACPI
>> +       pci_msi_register_fwnode_provider(&xgene_msi_get_fwnode);
>> +#endif
>>         return 0;
>>  }
>>
>> @@ -473,6 +484,13 @@ static const struct of_device_id xgene_msi_match_table[] = {
>>         {},
>>  };
>>
>> +#ifdef CONFIG_ACPI
>> +static const struct acpi_device_id xgene_msi_acpi_ids[] = {
>> +       {"APMC0D0E", 0},
>> +       { },
>> +};
>> +#endif
>> +
>>  static int xgene_msi_probe(struct platform_device *pdev)
>>  {
>>         struct resource *res;
>> @@ -494,7 +512,17 @@ static int xgene_msi_probe(struct platform_device *pdev)
>>                 goto error;
>>         }
>>         xgene_msi->msi_addr = res->start;
>> -       xgene_msi->node = pdev->dev.of_node;
>> +
>> +       xgene_msi->fwnode = of_node_to_fwnode(pdev->dev.of_node);
>> +       if (!xgene_msi->fwnode) {
>> +               xgene_msi->fwnode = irq_domain_alloc_fwnode(NULL);
>> +               if (!xgene_msi->fwnode) {
>> +                       dev_err(&pdev->dev, "Failed to create fwnode\n");
>> +                       rc = ENOMEM;
>> +                       goto error;
>> +               }
>> +       }
>> +
>>         xgene_msi->num_cpus = num_possible_cpus();
>>
>>         rc = xgene_msi_init_allocator(xgene_msi);
>> @@ -571,6 +599,7 @@ static struct platform_driver xgene_msi_driver = {
>>         .driver = {
>>                 .name = "xgene-msi",
>>                 .of_match_table = xgene_msi_match_table,
>> +               .acpi_match_table = ACPI_PTR(xgene_msi_acpi_ids),
>>         },
>>         .probe = xgene_msi_probe,
>>         .remove = xgene_msi_remove,
>> --
>> 1.9.1
>>


From mark.rutland at arm.com  Mon Feb 22 08:09:11 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Feb 2016 16:09:11 +0000
Subject: [PATCH] arm*: efi: drop permanent mapping of the UEFI System table
In-Reply-To: <CAKv+Gu_pnjL557dE1xez_y2tESOjZj9_2XEbNtm_b4yAA-WdYg@mail.gmail.com>
References: <1456153179-27214-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160222154314.GJ3435@leverpostej>
 <CAKv+Gu_pnjL557dE1xez_y2tESOjZj9_2XEbNtm_b4yAA-WdYg@mail.gmail.com>
Message-ID: <20160222160910.GK3435@leverpostej>

On Mon, Feb 22, 2016 at 04:56:57PM +0100, Ard Biesheuvel wrote:
> On 22 February 2016 at 16:43, Mark Rutland <mark.rutland at arm.com> wrote:
> > On Mon, Feb 22, 2016 at 03:59:39PM +0100, Ard Biesheuvel wrote:
> >> The permanent, writable mapping of the UEFI System table is only
> >> referenced during invocations of UEFI Runtime Services, at which time
> >> the UEFI virtual mapping is available, which also covers the system
> >> table (since the runtime services themselves need access to it)
> >
> > I'm not sure it's strictly true that the runtime services themselves
> > need access to the system table. Why would that be necessary? Are
> > runtime services mandated to indirect calls via the system table?
> >
> 
> They don't need access per se, but they are allowed to reference it,
> and so the memory remapping layer must make it accessible after
> SetVirtualAddressMap(). The spec lists explicitly which fields are
> still valid after ExitBootServices()

I was language-lawyering ;)

I appreciate that they _can_, I just didn't think it was true that they
_must_ (i.e. that they always "need to access it"). Per the below that's
likely moot.

> SetVirtualAddressMap() is a runtime service, and one of the things it
> does is update the pointers in the system table, hence it must be
> located in RuntimeService memory, because anything else may be gone by
> this time.

Good point. That does imply that it must be in EfiRuntimeServices*
memory.

> > From the spec, I couldn't find a mandate that the system table (nor the
> > runtime services table) were in a region of EfiRuntimeServicesData
> > memory. I suspect I'm looking in the wrong place...
> 
> We should clarify it if it is not clear (or if I turn out to be wrong)

I'm hoping that I've simply missed something. Perhaps the implication
above was intentional, albeit rather opaque.

Otherwise, I certainly agree a clarification would be a good thing!

Mark.


From tony at atomide.com  Mon Feb 22 08:09:56 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 08:09:56 -0800
Subject: [PATCH] ARM: OMAP2+: Fix onenand initialization to avoid
 filesystem corruption
In-Reply-To: <56C9FE63.3070602@gmail.com>
References: <linux-kernel@vger.kernel.org>
 <1454683028-4193-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
 <20160208193644.GU19432@atomide.com>
 <20160210211226.GB1640@darkstar.musicnaut.iki.fi>
 <20160211001220.GM19432@atomide.com> <56C9FE63.3070602@gmail.com>
Message-ID: <20160222160956.GB13417@atomide.com>

* Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com> [160221 10:14]:
> Hi,
> 
> On 11.02.2016 02:12, Tony Lindgren wrote:
> >
> >Also.. There's a chance somebody has created a onenand file system
> >with recent mainline kernels that did the reset and disabled ECC.
> >So with Ivaylo's patch fixing that, those may not mount properly
> >any longer. Most likely people just keep their maemo rootfs there
> >though with the MMC being available.
> 
> I guess this is possible, but what worries me more is that the longer the
> patch is not pushed, the higher the chance somebody to end-up with broken
> rootfs. Wouldn't it be better to push it, thus preventing that happening?

Will apply today into omap-for-v4.5/fixes with Aaro's ack. Note that
Aaro found also two other error causing issues with the onenand
driver, so it seems the onenand driver has been broken for years in
the mainline kernel..

> BTW the differences for N9/50 come from ONENAND_SYS_CFG1_HF bit and
> ONENAND_SYS_CFG1_BRL_6 vs ONENAND_SYS_CFG1_BRL_4. Both are changed (later in
> the code) anyway, so I guess it is safe to reset them to default values.

Yes I think we're better off having things fully configured by the
kernel in the long run.

> Or, maybe the correct fix is to issue RESET command to onenand controller
> after GPMC reset? RESET command is supposed to put all the bits to their
> default values.

Something like that could be added if needed.

Regards,

Tony



From mark.rutland at arm.com  Mon Feb 22 08:17:45 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Feb 2016 16:17:45 +0000
Subject: [PATCH V4 5/5] Microblaze: Modifying microblaze PCI subsytem to
 support  generic Xilinx  AXI PCIe Host Bridge IP driver
In-Reply-To: <8520D5D51A55D047800579B09414719825884643@XAP-PVEXMBX01.xlnx.xilinx.com>
References: <1455208091-15556-1-git-send-email-bharatku@xilinx.com>
 <1455208091-15556-6-git-send-email-bharatku@xilinx.com>
 <8520D5D51A55D047800579B09414719825884643@XAP-PVEXMBX01.xlnx.xilinx.com>
Message-ID: <20160222161745.GL3435@leverpostej>

On Mon, Feb 22, 2016 at 04:01:15PM +0000, Bharat Kumar Gogada wrote:
> Ping

Please trim your To line, and state who you're pinging, and specifically
what you are pinging for. You'll have much better luck with targetted
replies.

Given the number of people in the To line, no-one knows if they're being
poked, or if someone else is. Given the lack of any question/statement
with your ping, it's not clear what you're asking for.

The DT parts of this series already appear to have been reviewed, so
there's no reason to keep myself and other DT maintainers on the To
line for this patch.

Mark.

> 
> > Subject: [PATCH V4 5/5] Microblaze: Modifying microblaze PCI subsytem to
> > support generic Xilinx AXI PCIe Host Bridge IP driver
> > 
> > This patch does required modifications to microblaze PCI subsystem, to work
> > with generic driver (drivers/pci/host/pcie-xilinx.c) on Microblaze and Zynq.
> > 
> > Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> > Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
> > ---
> > Changes:
> > Removed pcibios_get_phb_of_node in pci-common.c, using generic version
> > instead.
> > Modified pcibios_fixup_bus in pci-common.c, as per generic architecuture.
> > Modified pcibios_align_resource in pci-common.c, as per generic
> > architecuture, removed temporary variable.
> > Removed pci_domain_nr in pci-common.c, instead using generic code.
> > Added pcibios_add_device in pci-common.c, as per generic architecuture.
> > Adding Kernel configuration in arch/microblaze as required for generic PCI
> > domains.
> > Added kernel configuration for driver to support Microblaze.
> > ---
> >  arch/microblaze/Kconfig          |  3 +++
> >  arch/microblaze/pci/pci-common.c | 56 +++++++---------------------------------
> >  drivers/pci/host/Kconfig         |  2 +-
> >  3 files changed, 14 insertions(+), 47 deletions(-)
> > 
> > diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig index
> > 0bce820..c3702b9 100644
> > --- a/arch/microblaze/Kconfig
> > +++ b/arch/microblaze/Kconfig
> > @@ -271,6 +271,9 @@ config PCI
> >  config PCI_DOMAINS
> >  	def_bool PCI
> > 
> > +config PCI_DOMAINS_GENERIC
> > +	def_bool PCI_DOMAINS
> > +
> >  config PCI_SYSCALL
> >  	def_bool PCI
> > 
> > diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-
> > common.c
> > index ae838ed..35654be 100644
> > --- a/arch/microblaze/pci/pci-common.c
> > +++ b/arch/microblaze/pci/pci-common.c
> > @@ -123,17 +123,6 @@ unsigned long pci_address_to_pio(phys_addr_t
> > address)  }  EXPORT_SYMBOL_GPL(pci_address_to_pio);
> > 
> > -/*
> > - * Return the domain number for this bus.
> > - */
> > -int pci_domain_nr(struct pci_bus *bus)
> > -{
> > -	struct pci_controller *hose = pci_bus_to_host(bus);
> > -
> > -	return hose->global_number;
> > -}
> > -EXPORT_SYMBOL(pci_domain_nr);
> > -
> >  /* This routine is meant to be used early during boot, when the
> >   * PCI bus numbers have not yet been assigned, and you need to
> >   * issue PCI config cycles to an OF device.
> > @@ -863,26 +852,10 @@ void pcibios_setup_bus_devices(struct pci_bus
> > *bus)
> > 
> >  void pcibios_fixup_bus(struct pci_bus *bus)  {
> > -	/* When called from the generic PCI probe, read PCI<->PCI bridge
> > -	 * bases. This is -not- called when generating the PCI tree from
> > -	 * the OF device-tree.
> > -	 */
> > -	if (bus->self != NULL)
> > -		pci_read_bridge_bases(bus);
> > -
> > -	/* Now fixup the bus bus */
> > -	pcibios_setup_bus_self(bus);
> > -
> > -	/* Now fixup devices on that bus */
> > -	pcibios_setup_bus_devices(bus);
> > +	/* nothing to do */
> >  }
> >  EXPORT_SYMBOL(pcibios_fixup_bus);
> > 
> > -static int skip_isa_ioresource_align(struct pci_dev *dev) -{
> > -	return 0;
> > -}
> > -
> >  /*
> >   * We need to avoid collisions with `mirrored' VGA ports
> >   * and other strange ISA hardware, so we always want the @@ -899,20
> > +872,18 @@ static int skip_isa_ioresource_align(struct pci_dev *dev)
> > resource_size_t pcibios_align_resource(void *data, const struct resource
> > *res,
> >  				resource_size_t size, resource_size_t align)  {
> > -	struct pci_dev *dev = data;
> > -	resource_size_t start = res->start;
> > -
> > -	if (res->flags & IORESOURCE_IO) {
> > -		if (skip_isa_ioresource_align(dev))
> > -			return start;
> > -		if (start & 0x300)
> > -			start = (start + 0x3ff) & ~0x3ff;
> > -	}
> > -
> > -	return start;
> > +	return res->start;
> >  }
> >  EXPORT_SYMBOL(pcibios_align_resource);
> > 
> > +int pcibios_add_device(struct pci_dev *dev) {
> > +	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL(pcibios_add_device);
> > +
> >  /*
> >   * Reparent resource children of pr that conflict with res
> >   * under res, and make res replace those children.
> > @@ -1333,13 +1304,6 @@ static void pcibios_setup_phb_resources(struct
> > pci_controller *hose,
> >  		 (unsigned long)hose->io_base_virt - _IO_BASE);  }
> > 
> > -struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus) -{
> > -	struct pci_controller *hose = bus->sysdata;
> > -
> > -	return of_node_get(hose->dn);
> > -}
> > -
> >  static void pcibios_scan_phb(struct pci_controller *hose)  {
> >  	LIST_HEAD(resources);
> > diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index
> > d5e58ba..7c56c2e 100644
> > --- a/drivers/pci/host/Kconfig
> > +++ b/drivers/pci/host/Kconfig
> > @@ -79,7 +79,7 @@ config PCI_KEYSTONE
> > 
> >  config PCIE_XILINX
> >  	bool "Xilinx AXI PCIe host bridge support"
> > -	depends on ARCH_ZYNQ
> > +	depends on ARCH_ZYNQ || MICROBLAZE
> >  	help
> >  	  Say 'Y' here if you want kernel to support the Xilinx AXI PCIe
> >  	  Host Bridge driver.
> > --
> > 2.1.1
> 


From dianders at chromium.org  Mon Feb 22 08:22:02 2016
From: dianders at chromium.org (Doug Anderson)
Date: Mon, 22 Feb 2016 08:22:02 -0800
Subject: [PATCH] usb: move usb_calc_bus_time into common code
In-Reply-To: <2B3535C5ECE8B5419E3ECBE30077290901DC453B41@US01WEMBX2.internal.synopsys.com>
References: <1455918064-410571-1-git-send-email-arnd@arndb.de>
 <Pine.LNX.4.44L0.1602191650570.1700-100000@iolanthe.rowland.org>
 <CAD=FV=VjgTUQR-Rw+LWXnNdZhruukaV-+LnXFqNRj-wpcvSJ4w@mail.gmail.com>
 <2B3535C5ECE8B5419E3ECBE30077290901DC453B41@US01WEMBX2.internal.synopsys.com>
Message-ID: <CAD=FV=Wa4CkgsbKeTT+D-46Dxr_ny=5MwbvnsyoDTtyDWyfm4Q@mail.gmail.com>

John,

On Fri, Feb 19, 2016 at 6:55 PM, John Youn <John.Youn at synopsys.com> wrote:
> On 2/19/2016 2:48 PM, Doug Anderson wrote:
>> Hi,
>>
>> On Fri, Feb 19, 2016 at 1:52 PM, Alan Stern <stern at rowland.harvard.edu> wrote:
>>> On Fri, 19 Feb 2016, Arnd Bergmann wrote:
>>>
>>>> The dwc2 dual-role USB controller driver has started calling
>>>> usb_calc_bus_time, and does so regardless of whether it is
>>>> being built as a host controller or gadget. In case all
>>>
>>> Out of curiosity...  Why does dwc2 need to calculate bus times when it
>>> is in device mode?
>>
>> Hoo boy.  it doesn't.  Nor does it need to properly set the even/odd
>> frame in device mode.
>>
>> Basically dwc2's "core.c" has a whole bunch of stuff in it that's host
>> only and isn't guarded with any #ifdef.  ...yet that file is included
>> in gadget-only builds.  It's a bit of a mess.  Take a gander at all of
>> the "dwc2_hc_xxx" functions sitting in "drivers/usb/dwc2/core.c".
>>
>> Long term that needs to be cleaned up, but such a cleanup is going to
>> be a bit of churn so we'd need to schedule it for a time when not much
>> else is going on (and presumably it should be done by John or in close
>> coordination with him so it can get Acked / landed quickly to avoid
>> conflicts?).  To do this we'd have to figure out why some things are
>> in "core.c" and some in "hcd.c" and if it makes sense to move them all
>> to "hcd.c" or if we need a new "core_hc.c" or something...  All of
>> that design predates me.
>>
>
> Yeah, that stuff has been bugging me for a while. I have a branch that
> started a lot of clean-ups, but it's never been a great time to merge
> it.
>
>> In any case I guess we need a solution for right now, huh?
>>
>> One terribly lame hack would be to just make a dummy no-op
>> "dwc2_hc_set_even_odd_frame()" if host mode is disabled.  That doesn't
>> really fix the root problem of lots of host mode code being compiled
>> in a gadget-only driver.  It also adds an ugly "#ifdef".  ...but it
>> does get around the current compile error.
>>
>>
>> What do folks think?
>>
>
> I think if we can fix it for -next in dwc2 by moving all host code out
> of core then we should do it that way. I'll see if I can revive my
> patches.

It looks like Felipe has dropped my series out of his testing/next to
avoid this issue (thanks Felipe!).  I'm interested in getting this
resolved as soon as possible to get things back in.  Is there anything
you'd like me to do to help?

-Doug


From ard.biesheuvel at linaro.org  Mon Feb 22 08:24:11 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 17:24:11 +0100
Subject: [PATCH] arm*: efi: drop permanent mapping of the UEFI System table
In-Reply-To: <20160222160910.GK3435@leverpostej>
References: <1456153179-27214-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160222154314.GJ3435@leverpostej>
 <CAKv+Gu_pnjL557dE1xez_y2tESOjZj9_2XEbNtm_b4yAA-WdYg@mail.gmail.com>
 <20160222160910.GK3435@leverpostej>
Message-ID: <CAKv+Gu-S1hMuLgE+bumnXVC1QpHYu7aWUzHtzbDy3HkUS_WS6w@mail.gmail.com>

On 22 February 2016 at 17:09, Mark Rutland <mark.rutland at arm.com> wrote:
> On Mon, Feb 22, 2016 at 04:56:57PM +0100, Ard Biesheuvel wrote:
>> On 22 February 2016 at 16:43, Mark Rutland <mark.rutland at arm.com> wrote:
>> > On Mon, Feb 22, 2016 at 03:59:39PM +0100, Ard Biesheuvel wrote:
>> >> The permanent, writable mapping of the UEFI System table is only
>> >> referenced during invocations of UEFI Runtime Services, at which time
>> >> the UEFI virtual mapping is available, which also covers the system
>> >> table (since the runtime services themselves need access to it)
>> >
>> > I'm not sure it's strictly true that the runtime services themselves
>> > need access to the system table. Why would that be necessary? Are
>> > runtime services mandated to indirect calls via the system table?
>> >
>>
>> They don't need access per se, but they are allowed to reference it,
>> and so the memory remapping layer must make it accessible after
>> SetVirtualAddressMap(). The spec lists explicitly which fields are
>> still valid after ExitBootServices()
>
> I was language-lawyering ;)
>
> I appreciate that they _can_, I just didn't think it was true that they
> _must_ (i.e. that they always "need to access it"). Per the below that's
> likely moot.
>

Runtime services drivers must call ConvertPointer() to translate the
pointer variables in their global state to their virtual equivalents.
So unless a Runtime driver does not have such state at all, it needs
access to the runtime services table, which is usually retrieved
through the system table. So yes, you're right. And yes, it's moot :-)

>> SetVirtualAddressMap() is a runtime service, and one of the things it
>> does is update the pointers in the system table, hence it must be
>> located in RuntimeService memory, because anything else may be gone by
>> this time.
>
> Good point. That does imply that it must be in EfiRuntimeServices*
> memory.
>
>> > From the spec, I couldn't find a mandate that the system table (nor the
>> > runtime services table) were in a region of EfiRuntimeServicesData
>> > memory. I suspect I'm looking in the wrong place...
>>
>> We should clarify it if it is not clear (or if I turn out to be wrong)
>
> I'm hoping that I've simply missed something. Perhaps the implication
> above was intentional, albeit rather opaque.
>
> Otherwise, I certainly agree a clarification would be a good thing!
>
> Mark.


From dianders at google.com  Mon Feb 22 08:27:37 2016
From: dianders at google.com (Doug Anderson)
Date: Mon, 22 Feb 2016 08:27:37 -0800
Subject: [PATCH v3 00/12] pwm: add support for atomic update
In-Reply-To: <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
References: <1442828009-6241-1-git-send-email-boris.brezillon@free-electrons.com>
 <2341981.a79ioYM9Es@diego> <20151110173416.GB21727@ulmo>
 <CAD=FV=WL3jYEgVe-m6QcAyQwfJgdX4J5OtKisKwyoKOrTSpEQA@mail.gmail.com>
 <20160125170855.GA10182@ulmo>
 <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
 <20160203145337.GD9650@ulmo>
 <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
Message-ID: <CAD=FV=UEfLa=rZuSAHJ8t6X=1RE_wd4b2fbrzavgbT3KnMLrBg@mail.gmail.com>

Thierry,

On Wed, Feb 3, 2016 at 11:04 AM, Doug Anderson <dianders at google.com> wrote:
> Thierry
>
> On Wed, Feb 3, 2016 at 6:53 AM, Thierry Reding <thierry.reding at gmail.com> wrote:
>>> A) The software state here is the period and flags (AKA "inverted),
>>> right?  It does seem possible that you could apply the period and
>>> flags while keeping the calculated bootup duty cycle percentage
>>> (presuming that the PWM was actually enabled at probe time and there
>>> was a bootup duty cycle at all).  That would basically say that
>>> whenever you set the period of a PWM then the duty cycle of the PWM
>>> should remain the same percentage.  That actually seems quite sane
>>> IMHO.  It seems much saner than trying to keep the duty cycle "ns"
>>> when the period changes or resetting the PWM to some default when the
>>> period changes.
>>
>> That really depends on the use-case. If you're interested in the output
>> power of the PWM then, yes, this is sane. But it might not be the right
>> answer in other cases.
>
> Ah, I see.  You're envisioning a device where active time in "ns" is
> more important than the percentage of active time.  Perhaps an LED
> where it's more important to have it on for no more than .1 seconds
> (so we don't drive it too long and burn it out?).  If we slowed down
> the duty cycle and adjusted the period to match, we could get into a
> bad state.
>
>
>>> B) Alternatively, I'd also say that setting a period without a duty
>>> cycle doesn't make a lot of sense.  ...so you could just apply the
>>> period at the same time that you apply the duty cycle the first time.
>>> Presumably you'd want to "lie" to the callers of the PWM subsystem and
>>> tell them that you already changed the period even though the change
>>> won't really take effect until they actually set the duty cycle.  If
>>> anyone cared to find out the true hardware period we could add a new
>>> pwm_get_hw_period().  ...or since the only reason you'd want to know
>>> the hardware period would be if you're trying to read the current duty
>>> cycle percentage, you could instead add "pwm_get_hw_state()" and have
>>> that return both the hardware period ns and duty cycle ns (which is
>>> the most accurate way to return the "percentage" without using fix or
>>> floating point math).
>>
>> But then you get into a situation where behaviour is dependent on the
>> PWM driver, whereas this is really very specific to one specific use-
>> case.
>
> This is because only some drivers would be able to read the hardware
> state?  I'm not sure how we can get away from that.  In all proposals
> we've talked about (including what you propose below, right?) the PWM
> regulator will need a PWM driver that can read hardware state.  Only
> PWM drivers that have been upgraded to support reading hardware state
> can use the PWM regulator (or at least only those drivers will be able
> to use the PWM regulator glitch-free).
>
> When we add a new feature then it's expected that only updated drivers
> will support that feature.
>
> We need to make sure that we don't regress / negatively change the
> behavior for anyone running non-updated drivers.  ...and we should
> strive to require as few changes to drivers as possible.  ...but if
> the best we can do requires changes to the PWM driver API then we will
> certainly have differences depending on the PWM driver.
>
>
>> In the end the PWM API is as low-level as it is because it needs to be
>> flexible enough to cope with other use-cases. In the general case the
>> simple truth is that it doesn't make sense to set a period without the
>> duty cycle and vice versa. That's why pwm_config() takes both as input
>> parameters. The atomic API is going to take that one step further in
>> that you need to specify the complete state of the PWM when applying.
>
> I guess this is still showing the strangeness of the device tree
> specifying a period without a duty cycle.  You just said it doesn't
> make sense, but that's exactly what the device tree has.
>
> I'd imagine that the only reason that the device tree specifies just
> the period is that it's intended to be there only for clients that
> don't care about the specific duty cycle in terms of seconds but
> _only_ care about the duty cycle in terms of percentage.  Anyone who
> cared about the duty cycle in terms of seconds would presumably also
> care about specifying the period (in terms of seconds) in the same
> place they specify the duty cycle.
>
>
>>> I think this is like my suggestion B), right?  AKA the PWM regulator
>>> would be the sole caller of pwm_get_hw_state() and it would use this
>>> to figure out the existing duty cycle percentage.  Then it would
>>> translate that into "ns" and would set the duty cycle.  Upon the first
>>> set of the duty cycle both the period and duty cycle would be applied
>>> at the same time.
>>
>> Yes and no. I think the PWM regulator would need to get the current
>> hardware state and derive the output power from duty cycle and period.
>> It would then need to rescale to whatever new period it wants to use
>> to ensure the same output power is used.
>
> Right.  We all agree that somehow this needs to happen, it's just a
> question of the implementation.
>
>
>>> > That doesn't really get us closer, though. There is still the issue of
>>> > the user having to deal with two states: the current hardware state and
>>> > the software state as configured in DT or board files.
>>>
>>> I think the only users that need to deal with this are one that need a
>>> seamless transition from bootup settings.  Adding a new API call to
>>> support a new feature like this doesn't seem insane, and anyone who
>>> doesn't want this new feature can just never call the new API.
>>>
>>> The only thing that would "change" from the point of view of old
>>> drivers is that the PWM period wouldn't change at bootup until the
>>> duty cycle was set.  IMHO this is probably a bug fix.  AKA, for a PWM
>>> backlight, imagine:
>>>
>>> 1. Firmware sets period to 20000 ns, duty cycle to 8000 ns (40%)
>>> 2. Linux boots up and sets period to 10000 ns.  Brightness of
>>> backlight instantly goes to 80%.
>>> 3. Eventually something decides to set the backlight duty cycle and it
>>> goes to the proper rate.
>>>
>>> Skipping #2 seems like the right move.  ...or did I misunderstand how
>>> something works?
>>
>> I'm not aware of any code in the PWM subsystem that would do this
>> automatically. If you don't call any of the pwm_*() functions the
>> hardware state should not be modified. The responsibility is with
>> the user drivers.
>
> Ah, OK.  I must have gotten confused.
>
> Oh, I see.  So pwm_get_period() is actually "lying" about the hardware
> today!  So what you're saying is that at boot time we grab the period
> out of the device tree but we _don't_ apply it to the hardware, right?
>  I was thinking it would get applied right away...
>
> That means that if you call pwm_get_period() right away at boot time
> you're not getting the current period of the hardware but the period
> that was specified in the device tree.
>
> So all we need is a new API call that lets you read the hardware
> values and make sure that the PWM regulator calls that before anyone
> calls pwm_config().  That's roughly B) above.
>
>
>> That is, it is up to the regulator or backlight driver to apply any new
>> configuration to a PWM channel on boot, or leave it as is. For
>> backlight it's probably fine to simply apply some default, since having
>> the brightness change on boot isn't going to be terribly irritating.
>>
>> With the atomic API it would be possible to avoid even this and have the
>> backlight driver simply read out the current hardware state and apply an
>> equivalent brightness even if the period changed.
>>
>> For the regulator case you'd need to read out the current state and then
>> recompute the values that will yield the same output power given data
>> specified in DT. I think that much is already implemented in Boris'
>> series, and it's really only the details that are being debated.
>>
>> The problematic issue is still that we might have a disparity between
>> the current hardware state and the state initially specified by DT. In
>> the general case the DT will specify the period and polarity of the PWM
>> signal and leave it up to the user driver to determine what a correct
>> duty cycle would be. With the atomic API we'll essentially have two
>> states: the current (hardware) state and the "initial" state, which is
>> what an OS will see as the state to apply. The problem now is that once
>> you have applied the initial state with a duty cycle you've determined,
>> there is no longer a need to keep it around. But there's also no way to
>> know when this is the case. So the controversial part about all this is
>> when to start using the current state rather that the initial state.
>>
>> The most straightforward way to solve this would be to apply the initial
>> configuration on driver probe. That is, when the pwm-regulator driver
>> gets probed it would retrieve the current and initial states, then
>> adjust the current state such that it matches the initial state but with
>> a duty cycle that yields the same output power as the current state, and
>> finally apply the new state. After that, every regulator_set_voltage()
>> call could simply operate on the current state and adjust the duty cycle
>> exclusively.
>>
>> Does that sound reasonable?
>
> Sure.  ...but you agree that somehow you need a new API call for this,
> right?  Somehow the PWM regulator needs to be able to say that it
> wants the hardware state, not the initial state as specified in the
> device tree.

I'm hoping we can get your latest thoughts on this topic so that Boris
can make forward progress.  It would be nice to get to some resolution
somehow.  The unfortunate part about having only one back-and-forth
exchange every few weeks is that I'm worried that we'll forget what we
already talked about and have the same discussions over and over
again.  :(

-Doug


From ckeepax at opensource.wolfsonmicro.com  Mon Feb 22 08:28:43 2016
From: ckeepax at opensource.wolfsonmicro.com (Charles Keepax)
Date: Mon, 22 Feb 2016 16:28:43 +0000
Subject: [PATCH 09/61] gpio: arizona: Use devm_gpiochip_add_data() for
 gpio registration
In-Reply-To: <1456150130-2668-10-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
 <1456150130-2668-10-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160222162843.GA1490@localhost.localdomain>

On Mon, Feb 22, 2016 at 07:37:58PM +0530, Laxman Dewangan wrote:
> Use devm_gpiochip_add_data() for GPIO registration and remove the
> need of driver callback .remove.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: patches at opensource.wolfsonmicro.com
> ---

Acked-by: Charles Keepax <ckeepax at opensource.wolfsonmicro.com>

Thanks,
Charles


From ckeepax at opensource.wolfsonmicro.com  Mon Feb 22 08:29:08 2016
From: ckeepax at opensource.wolfsonmicro.com (Charles Keepax)
Date: Mon, 22 Feb 2016 16:29:08 +0000
Subject: [PATCH 57/61] gpio: wm8350: Use devm_gpiochip_add_data() for
 gpio registration
In-Reply-To: <1456150130-2668-58-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
 <1456150130-2668-58-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160222162908.GB1490@localhost.localdomain>

On Mon, Feb 22, 2016 at 07:38:46PM +0530, Laxman Dewangan wrote:
> Use devm_gpiochip_add_data() for GPIO registration and remove the
> need of driver callback .remove.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: patches at opensource.wolfsonmicro.com
> ---

Acked-by: Charles Keepax <ckeepax at opensource.wolfsonmicro.com>

Thanks,
Charles


From ckeepax at opensource.wolfsonmicro.com  Mon Feb 22 08:29:21 2016
From: ckeepax at opensource.wolfsonmicro.com (Charles Keepax)
Date: Mon, 22 Feb 2016 16:29:21 +0000
Subject: [PATCH 58/61] gpio: wm8350: Use devm_gpiochip_add_data() for
 gpio registration
In-Reply-To: <1456150130-2668-59-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
 <1456150130-2668-59-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160222162921.GC1490@localhost.localdomain>

On Mon, Feb 22, 2016 at 07:38:47PM +0530, Laxman Dewangan wrote:
> Use devm_gpiochip_add_data() for GPIO registration and remove the
> need of driver callback .remove.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: patches at opensource.wolfsonmicro.com
> ---

Acked-by: Charles Keepax <ckeepax at opensource.wolfsonmicro.com>

Thanks,
Charles


From ckeepax at opensource.wolfsonmicro.com  Mon Feb 22 08:29:34 2016
From: ckeepax at opensource.wolfsonmicro.com (Charles Keepax)
Date: Mon, 22 Feb 2016 16:29:34 +0000
Subject: [PATCH 59/61] gpio: wm8994: Use devm_gpiochip_add_data() for
 gpio registration
In-Reply-To: <1456150130-2668-60-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
 <1456150130-2668-60-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160222162934.GD1490@localhost.localdomain>

On Mon, Feb 22, 2016 at 07:38:48PM +0530, Laxman Dewangan wrote:
> Use devm_gpiochip_add_data() for GPIO registration and remove the
> need of driver callback .remove.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: patches at opensource.wolfsonmicro.com
> ---

Acked-by: Charles Keepax <ckeepax at opensource.wolfsonmicro.com>

Thanks,
Charles


From tony at atomide.com  Mon Feb 22 08:35:20 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 08:35:20 -0800
Subject: GPIO regression in Linux next caused by syscon change
In-Reply-To: <56C8471A.1040702@ti.com>
References: <20160213002643.GQ19432@atomide.com>
 <20160213004935.GR19432@atomide.com>
 <CA+gwMccZeYimupmGsMX8YbNH9eEA6=Xi=rupciubBwzktfjvBA@mail.gmail.com>
 <20160215160115.GU19432@atomide.com>
 <1455552961.4899.37.camel@pengutronix.de>
 <20160215164757.GV19432@atomide.com>
 <20160215180635.GW19432@atomide.com> <56C8471A.1040702@ti.com>
Message-ID: <20160222163520.GC13417@atomide.com>

* Tero Kristo <t-kristo at ti.com> [160220 02:59]:
> On 02/15/2016 08:06 PM, Tony Lindgren wrote:
> >Tero, got any better ideas?
> 
> The underlying problem is the fact that OMAP3 control module register map is
> split into multiple regions, which in certain cases have overlapping
> functionality, and need to be accessed over boundaries. And the fact that we
> decided to split it in such way in the first place, for example to have
> pinmux regions separate.

Well we should only use regmap for the scm_conf area as that contains
tens of random registers that may need to be shared between various
device drivers.

For other SCM regions, we should just do standard Linux device drivers,
like we're doing with the pinmux regions.

> If you are going to bypass the usage of regmap, you could just drop it
> completely from the omap_ctrl_readl / writel APIs, and use the iomap
> directly. That simplifies the code and is slightly faster also.

OK that's a good idea. I'll update the patch to drop regmap for
omap_ctrl_read/write.

> Eventually this should probably be fixed in such way that any out-of-bounds
> accesses on the omap_ctrl region should use the actual driver APIs for that.
> The padconf accesses I have no clue how to fix (as pinctrl driver doesn't
> provide direct register read/write API), but for others we should introduce
> new regions under the DTS files and use a separate syscon mapping or
> something similar.

Best to keep regmap out of it for ranges that can be clearly ioremapped
for a dedicated device drivers.

Anyways, updated patch below, please take a look and ack if that
works for you and I'll apply it into omap-for-v4.6/fixes-not-urgent.

Regards,

Tony

8< ----------------------
From: Tony Lindgren <tony at atomide.com>
Date: Wed, 17 Feb 2016 10:36:31 -0800
Subject: [PATCH] ARM: OMAP2+: Fix out of range register access with
 syscon_config.max_register

If syscon_config.max_register is initialized like it should be, we have
omap_ctrl_read/write() fail with out of range register access at least
for omap3.

We have omap3.dtsi setting up a regmap range for scm_conf, but we now
have omap_ctrl_read/write() also attempt to use the regmap. However,
omap_ctrl_read/write() is also used for other register ranges in the
system control module (SCM).

Let's fix the issue by just removing the regmap_read/write() usage for
control module as suggested by Tero Kristo <t-kristo at ti.com>.

Signed-off-by: Tony Lindgren <tony at atomide.com>

--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -36,7 +36,6 @@
 
 static void __iomem *omap2_ctrl_base;
 static s16 omap2_ctrl_offset;
-static struct regmap *omap2_ctrl_syscon;
 
 #if defined(CONFIG_ARCH_OMAP3) && defined(CONFIG_PM)
 struct omap3_scratchpad {
@@ -166,16 +165,9 @@ u16 omap_ctrl_readw(u16 offset)
 
 u32 omap_ctrl_readl(u16 offset)
 {
-	u32 val;
-
 	offset &= 0xfffc;
-	if (!omap2_ctrl_syscon)
-		val = readl_relaxed(omap2_ctrl_base + offset);
-	else
-		regmap_read(omap2_ctrl_syscon, omap2_ctrl_offset + offset,
-			    &val);
 
-	return val;
+	return readl_relaxed(omap2_ctrl_base + offset);
 }
 
 void omap_ctrl_writeb(u8 val, u16 offset)
@@ -207,11 +199,7 @@ void omap_ctrl_writew(u16 val, u16 offset)
 void omap_ctrl_writel(u32 val, u16 offset)
 {
 	offset &= 0xfffc;
-	if (!omap2_ctrl_syscon)
-		writel_relaxed(val, omap2_ctrl_base + offset);
-	else
-		regmap_write(omap2_ctrl_syscon, omap2_ctrl_offset + offset,
-			     val);
+	writel_relaxed(val, omap2_ctrl_base + offset);
 }
 
 #ifdef CONFIG_ARCH_OMAP3
@@ -715,8 +703,6 @@ int __init omap_control_init(void)
 			if (IS_ERR(syscon))
 				return PTR_ERR(syscon);
 
-			omap2_ctrl_syscon = syscon;
-
 			if (of_get_child_by_name(scm_conf, "clocks")) {
 				ret = omap2_clk_provider_init(scm_conf,
 							      data->index,
@@ -724,9 +710,6 @@ int __init omap_control_init(void)
 				if (ret)
 					return ret;
 			}
-
-			iounmap(omap2_ctrl_base);
-			omap2_ctrl_base = NULL;
 		} else {
 			/* No scm_conf found, direct access */
 			ret = omap2_clk_provider_init(np, data->index, NULL,


From f.fainelli at gmail.com  Mon Feb 22 08:42:50 2016
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Mon, 22 Feb 2016 08:42:50 -0800
Subject: [PATCH] i2c: brcmstb: allocate correct amount of memory for regmap
In-Reply-To: <1456064238-6294-1-git-send-email-wsa@the-dreams.de>
References: <1456064238-6294-1-git-send-email-wsa@the-dreams.de>
Message-ID: <56CB3A8A.9040401@gmail.com>

Le 21/02/2016 06:16, Wolfram Sang a ?crit :
> We want the size of the struct, not of a pointer to it. To be future
> proof, just dereference the pointer to get the desired type.
> 
> Signed-off-by: Wolfram Sang <wsa at the-dreams.de>

Fixes: dd1aa2524bc5 ("i2c: brcmstb: Add Broadcom settop SoC i2c
controller driver")

Acked-by: Florian Fainelli <f.fainelli at gmail.com>

Thanks!
-- 
Florian


From will.deacon at arm.com  Mon Feb 22 08:49:58 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 22 Feb 2016 16:49:58 +0000
Subject: [PATCH v3 1/4] of/fdt: factor out assignment of
 initrd_start/initrd_end
In-Reply-To: <1455289046-21321-2-git-send-email-ard.biesheuvel@linaro.org>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455289046-21321-2-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160222164958.GJ31168@arm.com>

On Fri, Feb 12, 2016 at 03:57:23PM +0100, Ard Biesheuvel wrote:
> Since architectures may not yet have their linear mapping up and running
> when the initrd address is discovered from the DT, factor out the
> assignment of initrd_start and initrd_end, so that an architecture can
> override it and use the translation it needs.
> 
> Cc: Rob Herring <robh at kernel.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
>  drivers/of/fdt.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)

Mark, Rob, any comments on this?

Will

> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 1f98156f8996..3e90bce70545 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -760,6 +760,16 @@ const void * __init of_flat_dt_match_machine(const void *default_match,
>  }
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
> +#ifndef __early_init_dt_declare_initrd
> +static void __early_init_dt_declare_initrd(unsigned long start,
> +					   unsigned long end)
> +{
> +	initrd_start = (unsigned long)__va(start);
> +	initrd_end = (unsigned long)__va(end);
> +	initrd_below_start_ok = 1;
> +}
> +#endif
> +
>  /**
>   * early_init_dt_check_for_initrd - Decode initrd location from flat tree
>   * @node: reference to node containing initrd location ('chosen')
> @@ -782,9 +792,7 @@ static void __init early_init_dt_check_for_initrd(unsigned long node)
>  		return;
>  	end = of_read_number(prop, len/4);
>  
> -	initrd_start = (unsigned long)__va(start);
> -	initrd_end = (unsigned long)__va(end);
> -	initrd_below_start_ok = 1;
> +	__early_init_dt_declare_initrd(start, end);
>  
>  	pr_debug("initrd_start=0x%llx  initrd_end=0x%llx\n",
>  		 (unsigned long long)start, (unsigned long long)end);
> -- 
> 2.5.0
> 


From nm at ti.com  Mon Feb 22 08:51:08 2016
From: nm at ti.com (Nishanth Menon)
Date: Mon, 22 Feb 2016 10:51:08 -0600
Subject: [PATCH 2/2] ARM: omap2plus_defconfig: Enable AT24 eeprom
In-Reply-To: <1456159868-32416-1-git-send-email-nm@ti.com>
References: <1456159868-32416-1-git-send-email-nm@ti.com>
Message-ID: <1456159868-32416-3-git-send-email-nm@ti.com>

AT24 compatible eeproms are used in BB family and X15 boards.

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 arch/arm/configs/omap2plus_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index d18d6b42fcf5..fa82f4e25d0e 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -145,6 +145,7 @@ CONFIG_BLK_DEV_RAM_SIZE=16384
 CONFIG_SENSORS_TSL2550=m
 CONFIG_BMP085_I2C=m
 CONFIG_SRAM=y
+CONFIG_EEPROM_AT24=m
 CONFIG_SENSORS_LIS3_I2C=m
 CONFIG_BLK_DEV_SD=y
 CONFIG_SCSI_SCAN_ASYNC=y
-- 
2.7.0



From nm at ti.com  Mon Feb 22 08:51:06 2016
From: nm at ti.com (Nishanth Menon)
Date: Mon, 22 Feb 2016 10:51:06 -0600
Subject: [PATCH 0/2] ARM: OMAP: X15: Add support for eeprom
Message-ID: <1456159868-32416-1-git-send-email-nm@ti.com>


X15 and BB family of boards use AT24 compatible eeproms

Enable support for the same.

Nishanth Menon (2):
  ARM: dts: am57xx-beagle-x15: Add eeprom information
  ARM: omap2plus_defconfig: Enable AT24 eeprom

 arch/arm/boot/dts/am57xx-beagle-x15.dts | 5 +++++
 arch/arm/configs/omap2plus_defconfig    | 1 +
 2 files changed, 6 insertions(+)

-- 
2.7.0



From nm at ti.com  Mon Feb 22 08:51:07 2016
From: nm at ti.com (Nishanth Menon)
Date: Mon, 22 Feb 2016 10:51:07 -0600
Subject: [PATCH 1/2] ARM: dts: am57xx-beagle-x15: Add eeprom information
In-Reply-To: <1456159868-32416-1-git-send-email-nm@ti.com>
References: <1456159868-32416-1-git-send-email-nm@ti.com>
Message-ID: <1456159868-32416-2-git-send-email-nm@ti.com>

Add EEPROM at 0x50 that describes the board configuration.
This is useful for userspace programs that may need to check board
revision and other similar information.

Signed-off-by: Nishanth Menon <nm at ti.com>
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 36c0fa6c362a..50312f80b972 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -591,6 +591,11 @@
 		DRVDD-supply = <&vdd_3v3>;
 		DVDD-supply = <&aic_dvdd>;
 	};
+
+	eeprom: eeprom at 50 {
+		compatible = "at,24c32";
+		reg = <0x50>;
+	};
 };
 
 &i2c3 {
-- 
2.7.0



From will.deacon at arm.com  Mon Feb 22 08:52:09 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 22 Feb 2016 16:52:09 +0000
Subject: [PATCH v3 4/4] arm64: prevent __va() translations before
 memstart_addr is assigned
In-Reply-To: <1455289046-21321-5-git-send-email-ard.biesheuvel@linaro.org>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455289046-21321-5-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160222165209.GK31168@arm.com>

On Fri, Feb 12, 2016 at 03:57:26PM +0100, Ard Biesheuvel wrote:
> Since memstart_addr is assigned relatively late in the boot code,
> after generic code like DT parsing and memblock manipulation has
> already occurred, we need to ensure that no __va() translation occur
> until memstart_addr has been set to a meaningful value.
> 
> So initialize memstart_addr to a value that cannot represent a valid
> physical address, and BUG() if memstart_addr is referenced while it
> still holds this value. Note that the > comparison against LLONG_MAX
> (not ULLONG_MAX) resolves to a single tbnz instruction that performs
> a conditional jump to a brk instruction that is emitted out of line.

Even so, I'd imagine that having a measurable impact on system
performance. Did you have a go at benchmarking this?

Will


From tony at atomide.com  Mon Feb 22 08:52:53 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 08:52:53 -0800
Subject: [PATCHv2] clk: ti: omap3+: dpll: use non-locking version of
 clk_get_rate
In-Reply-To: <1455966777-30576-1-git-send-email-t-kristo@ti.com>
References: <1455966777-30576-1-git-send-email-t-kristo@ti.com>
Message-ID: <20160222165252.GF13417@atomide.com>

* Tero Kristo <t-kristo at ti.com> [160220 03:12]:
> As the code in this file is being executed within irq context in some
> cases, we must avoid the clk_get_rate which uses mutex internally.
> Switch the code to use clk_hw_get_rate instead which is non-locking.
> 
> This fixes an issue where PM runtime will hang the system if enabled
> with a serial console before a suspend-resume cycle.

Can you please add the "Fixes: " line here?

And when applying, please tag this one Cc stable.

Other than that, please feel free to add:

Tested-by: Tony Lindgren <tony at atomide.com>

Regards,

Tony


From slemieux.tyco at gmail.com  Mon Feb 22 08:55:40 2016
From: slemieux.tyco at gmail.com (slemieux.tyco at gmail.com)
Date: Mon, 22 Feb 2016 11:55:40 -0500
Subject: [PATCH v2 2/5] watchdog: pnx4008: add restart handler
In-Reply-To: <1456160143-26761-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456160143-26761-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456160143-26761-3-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Add restart handler capability to the driver;
the restart handler implementation was taken from
"mach-lpc32xx" ("lpc23xx_restart" function).

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Changes from v1 to v2:
- new patch in v2.

 drivers/watchdog/pnx4008_wdt.c | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
index 88264a2..4b01b2b 100644
--- a/drivers/watchdog/pnx4008_wdt.c
+++ b/drivers/watchdog/pnx4008_wdt.c
@@ -31,7 +31,10 @@
 #include <linux/slab.h>
 #include <linux/err.h>
 #include <linux/of.h>
+#include <linux/delay.h>
+#include <linux/reboot.h>
 #include <mach/hardware.h>
+#include <mach/platform.h>
 
 /* WatchDog Timer - Chapter 23 Page 207 */
 
@@ -77,6 +80,7 @@
 
 static bool nowayout = WATCHDOG_NOWAYOUT;
 static unsigned int heartbeat = DEFAULT_HEARTBEAT;
+static struct notifier_block restart_handler;
 
 static DEFINE_SPINLOCK(io_lock);
 static void __iomem	*wdt_base;
@@ -124,6 +128,27 @@ static int pnx4008_wdt_set_timeout(struct watchdog_device *wdd,
 	return 0;
 }
 
+static void pnx4008_wdt_sys_reset(enum reboot_mode mode, const char *cmd)
+{
+	/* Make sure WDT clocks are enabled */
+	writel(LPC32XX_CLKPWR_PWMCLK_WDOG_EN, LPC32XX_CLKPWR_TIMER_CLK_CTRL);
+
+	/* Instant assert of RESETOUT_N with pulse length 1mS */
+	writel(13000, WDTIM_PULSE(wdt_base));
+	writel(M_RES2 | RESFRC1 | RESFRC2, WDTIM_MCTRL(wdt_base));
+
+	/* Wait for watchdog to reset system */
+	mdelay(1000);
+}
+
+static int pnx4008_restart_handler(struct notifier_block *this,
+				   unsigned long mode, void *cmd)
+{
+	pnx4008_wdt_sys_reset((enum reboot_mode)mode, cmd);
+
+	return NOTIFY_DONE;
+}
+
 static const struct watchdog_info pnx4008_wdt_ident = {
 	.options = WDIOF_CARDRESET | WDIOF_MAGICCLOSE |
 	    WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
@@ -157,6 +182,11 @@ static int pnx4008_wdt_probe(struct platform_device *pdev)
 	if (IS_ERR(wdt_base))
 		return PTR_ERR(wdt_base);
 
+	/* Register restart handler. */
+	restart_handler.notifier_call = pnx4008_restart_handler;
+	restart_handler.priority = 128;
+	ret = register_restart_handler(&restart_handler);
+
 	wdt_clk = devm_clk_get(&pdev->dev, NULL);
 	if (IS_ERR(wdt_clk))
 		return PTR_ERR(wdt_clk);
-- 
1.8.3.1



From slemieux.tyco at gmail.com  Mon Feb 22 08:55:38 2016
From: slemieux.tyco at gmail.com (slemieux.tyco at gmail.com)
Date: Mon, 22 Feb 2016 11:55:38 -0500
Subject: [PATCH v2 0/5] watchdog: pnx4008: add restart handler
Message-ID: <1456160143-26761-1-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

The LPC32xx provide the capability to perform a soft or hard reset;
a soft reset will no reset the external peripheral
(i.e. RESOUT_N output not asserted).

This changeset migrate the restart code from the "mach-lpc32xx" to
the "pnx-4008" watchdog driver and add the soft reset capability.

The default behavior (i.e. hard reset) remain unchanged.

The core restart handler support added by this change:
2165bf524da5f5e496d - "watchdog: core: add restart handler support"
is not use in this changeset; it does not support the reboot mode.

---
Changes from v1 to v2:
* Rename patch title;
  was "arm: lpc32xx: restart: add support for soft reset"
* Update the patch as per the feedback received from:
  Joachim: http://permalink.gmane.org/gmane.linux.ports.arm.kernel/479791
  - migrate restart code from "mach-lpc32xx" to "pnx-4008" driver.
* Add soft reset support to "pnx-4008" driver instead of "mach-lpc32xx".
* Use define available in "pnx-4008" when writting to watchdog register.
* Remove restart handler from "mach-lpc32xx".
* Remove restart hook from "phy3250.c".
* Update driver logging during power-on. 

Sylvain Lemieux (5):
  watchdog: pnx4008: update logging during power-on
  watchdog: pnx4008: add restart handler
  watchdog: pnx4008: add support for soft reset
  watchdog: pnx4008: restart: support "cmd" from userspace
  arm: lpc32xx: remove restart handler

 arch/arm/mach-lpc32xx/common.c  | 15 ------------
 arch/arm/mach-lpc32xx/common.h  |  1 -
 arch/arm/mach-lpc32xx/phy3250.c |  1 -
 drivers/watchdog/pnx4008_wdt.c  | 53 +++++++++++++++++++++++++++++++++++++++--
 4 files changed, 51 insertions(+), 19 deletions(-)

-- 
1.8.3.1



From slemieux.tyco at gmail.com  Mon Feb 22 08:55:39 2016
From: slemieux.tyco at gmail.com (slemieux.tyco at gmail.com)
Date: Mon, 22 Feb 2016 11:55:39 -0500
Subject: [PATCH v2 1/5] watchdog: pnx4008: update logging during power-on
In-Reply-To: <1456160143-26761-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456160143-26761-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456160143-26761-2-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

There is no need add the driver name in the text to display
on the console during the power-on:
pnx4008-watchdog 4003c000.watchdog: PNX4008 Watchdog Timer: heartbeat 19 sec

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Changes from v1 to v2:
- new patch in v2.

 drivers/watchdog/pnx4008_wdt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
index 313cd1c..88264a2 100644
--- a/drivers/watchdog/pnx4008_wdt.c
+++ b/drivers/watchdog/pnx4008_wdt.c
@@ -178,8 +178,7 @@ static int pnx4008_wdt_probe(struct platform_device *pdev)
 		goto disable_clk;
 	}
 
-	dev_info(&pdev->dev, "PNX4008 Watchdog Timer: heartbeat %d sec\n",
-		 pnx4008_wdd.timeout);
+	dev_info(&pdev->dev, "heartbeat %d sec\n", pnx4008_wdd.timeout);
 
 	return 0;
 
-- 
1.8.3.1



From slemieux.tyco at gmail.com  Mon Feb 22 08:55:41 2016
From: slemieux.tyco at gmail.com (slemieux.tyco at gmail.com)
Date: Mon, 22 Feb 2016 11:55:41 -0500
Subject: [PATCH v2 3/5] watchdog: pnx4008: add support for soft reset
In-Reply-To: <1456160143-26761-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456160143-26761-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456160143-26761-4-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Add support for explicit soft reset using the reboot mode.

The default reboot mode behavior is unchanged;
you can overwrite the default reboot type in the board specific file
"DT_MACHINE_START" definition using the "reboot_mode" parameter.

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Changes from v1 to v2:
- Rename patch title;
  was "arm: lpc32xx: restart: add support for soft reset"
- Add change to "pnx-4008" driver instead of "mach-lpc32xx".
- Use define available in "pnx-4008" when writting to watchdog register.

 drivers/watchdog/pnx4008_wdt.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
index 4b01b2b..2275fd4 100644
--- a/drivers/watchdog/pnx4008_wdt.c
+++ b/drivers/watchdog/pnx4008_wdt.c
@@ -133,9 +133,16 @@ static void pnx4008_wdt_sys_reset(enum reboot_mode mode, const char *cmd)
 	/* Make sure WDT clocks are enabled */
 	writel(LPC32XX_CLKPWR_PWMCLK_WDOG_EN, LPC32XX_CLKPWR_TIMER_CLK_CTRL);
 
-	/* Instant assert of RESETOUT_N with pulse length 1mS */
-	writel(13000, WDTIM_PULSE(wdt_base));
-	writel(M_RES2 | RESFRC1 | RESFRC2, WDTIM_MCTRL(wdt_base));
+	if (mode == REBOOT_SOFT) {
+		/* Force match output active */
+		writel(EXT_MATCH0, WDTIM_EMR(wdt_base));
+		/* Internal reset on match output (RESOUT_N not asserted) */
+		writel(M_RES1, WDTIM_MCTRL(wdt_base));
+	} else {
+		/* Instant assert of RESETOUT_N with pulse length 1mS */
+		writel(13000, WDTIM_PULSE(wdt_base));
+		writel(M_RES2 | RESFRC1 | RESFRC2, WDTIM_MCTRL(wdt_base));
+	}
 
 	/* Wait for watchdog to reset system */
 	mdelay(1000);
-- 
1.8.3.1



From slemieux.tyco at gmail.com  Mon Feb 22 08:55:43 2016
From: slemieux.tyco at gmail.com (slemieux.tyco at gmail.com)
Date: Mon, 22 Feb 2016 11:55:43 -0500
Subject: [PATCH v2 5/5] arm: lpc32xx: remove restart handler
In-Reply-To: <1456160143-26761-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456160143-26761-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456160143-26761-6-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Remove the restart handler from "mach-lpc32xx";
this functionality is now available in the
pnx4008 watchdog driver.

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Changes from v1 to v2:
- new patch in v2.

 arch/arm/mach-lpc32xx/common.c  | 15 ---------------
 arch/arm/mach-lpc32xx/common.h  |  1 -
 arch/arm/mach-lpc32xx/phy3250.c |  1 -
 3 files changed, 17 deletions(-)

diff --git a/arch/arm/mach-lpc32xx/common.c b/arch/arm/mach-lpc32xx/common.c
index 716e83e..5b7a1e7 100644
--- a/arch/arm/mach-lpc32xx/common.c
+++ b/arch/arm/mach-lpc32xx/common.c
@@ -194,21 +194,6 @@ void __init lpc32xx_map_io(void)
 	iotable_init(lpc32xx_io_desc, ARRAY_SIZE(lpc32xx_io_desc));
 }
 
-void lpc23xx_restart(enum reboot_mode mode, const char *cmd)
-{
-	/* Make sure WDT clocks are enabled */
-	__raw_writel(LPC32XX_CLKPWR_PWMCLK_WDOG_EN,
-		LPC32XX_CLKPWR_TIMER_CLK_CTRL);
-
-	/* Instant assert of RESETOUT_N with pulse length 1mS */
-	__raw_writel(13000, io_p2v(LPC32XX_WDTIM_BASE + 0x18));
-	__raw_writel(0x70, io_p2v(LPC32XX_WDTIM_BASE + 0xC));
-
-	/* Wait for watchdog to reset system */
-	while (1)
-		;
-}
-
 static int __init lpc32xx_check_uid(void)
 {
 	u32 uid[4];
diff --git a/arch/arm/mach-lpc32xx/common.h b/arch/arm/mach-lpc32xx/common.h
index 1cd8853..2d90801 100644
--- a/arch/arm/mach-lpc32xx/common.h
+++ b/arch/arm/mach-lpc32xx/common.h
@@ -30,7 +30,6 @@ extern void lpc32xx_timer_init(void);
 extern void __init lpc32xx_init_irq(void);
 extern void __init lpc32xx_map_io(void);
 extern void __init lpc32xx_serial_init(void);
-extern void lpc23xx_restart(enum reboot_mode, const char *);
 
 
 /*
diff --git a/arch/arm/mach-lpc32xx/phy3250.c b/arch/arm/mach-lpc32xx/phy3250.c
index 77d6b1b..942bc3f 100644
--- a/arch/arm/mach-lpc32xx/phy3250.c
+++ b/arch/arm/mach-lpc32xx/phy3250.c
@@ -263,5 +263,4 @@ DT_MACHINE_START(LPC32XX_DT, "LPC32XX SoC (Flattened Device Tree)")
 	.init_time	= lpc32xx_timer_init,
 	.init_machine	= lpc3250_machine_init,
 	.dt_compat	= lpc32xx_dt_compat,
-	.restart	= lpc23xx_restart,
 MACHINE_END
-- 
1.8.3.1



From slemieux.tyco at gmail.com  Mon Feb 22 08:55:42 2016
From: slemieux.tyco at gmail.com (slemieux.tyco at gmail.com)
Date: Mon, 22 Feb 2016 11:55:42 -0500
Subject: [PATCH v2 4/5] watchdog: pnx4008: restart: support "cmd" from
 userspace
In-Reply-To: <1456160143-26761-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456160143-26761-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456160143-26761-5-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Added support to verify if a "cmd" is passed from the userspace program rebooting the system;
- if a valid "cmd" is available, handle it;
- If the received "cmd" is not supported, use the default reboot mode.

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Changes from v1 to v2:
- Rename patch title;
  was "arm: lpc32xx: restart: support "cmd" from userspace"
- Add change to "pnx-4008" driver instead of "mach-lpc32xx".

 drivers/watchdog/pnx4008_wdt.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
index 2275fd4..5f34299 100644
--- a/drivers/watchdog/pnx4008_wdt.c
+++ b/drivers/watchdog/pnx4008_wdt.c
@@ -133,6 +133,19 @@ static void pnx4008_wdt_sys_reset(enum reboot_mode mode, const char *cmd)
 	/* Make sure WDT clocks are enabled */
 	writel(LPC32XX_CLKPWR_PWMCLK_WDOG_EN, LPC32XX_CLKPWR_TIMER_CLK_CTRL);
 
+	/*
+	 * Verify if a "cmd" passed from the userspace program rebooting
+	 * the system; if available, and handle it.
+	 * - For details, see the 'reboot' syscall in kernel/reboot.c
+	 * - If the received "cmd" is not supported, use the default mode.
+	 */
+	if (cmd) {
+		if (cmd[0] == 'h')
+			mode = REBOOT_HARD;
+		else if (cmd[0] == 's')
+			mode = REBOOT_SOFT;
+	}
+
 	if (mode == REBOOT_SOFT) {
 		/* Force match output active */
 		writel(EXT_MATCH0, WDTIM_EMR(wdt_base));
-- 
1.8.3.1



From ard.biesheuvel at linaro.org  Mon Feb 22 08:56:40 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 17:56:40 +0100
Subject: [PATCH v3 1/4] of/fdt: factor out assignment of
 initrd_start/initrd_end
In-Reply-To: <20160222164958.GJ31168@arm.com>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455289046-21321-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160222164958.GJ31168@arm.com>
Message-ID: <CAKv+Gu_OGJG0i9T=ecFVQM-P8KRpasJ+h6L4onJgpaED07Q8Jg@mail.gmail.com>

On 22 February 2016 at 17:49, Will Deacon <will.deacon at arm.com> wrote:
> On Fri, Feb 12, 2016 at 03:57:23PM +0100, Ard Biesheuvel wrote:
>> Since architectures may not yet have their linear mapping up and running
>> when the initrd address is discovered from the DT, factor out the
>> assignment of initrd_start and initrd_end, so that an architecture can
>> override it and use the translation it needs.
>>
>> Cc: Rob Herring <robh at kernel.org>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> ---
>>  drivers/of/fdt.c | 14 +++++++++++---
>>  1 file changed, 11 insertions(+), 3 deletions(-)
>
> Mark, Rob, any comments on this?
>

Already acked by Rob, and pulled into -next by Catalin ...


From tony at atomide.com  Mon Feb 22 08:59:59 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 08:59:59 -0800
Subject: [PATCHv2] clk: ti: dpll: convert DPLL support code to use clk_hw
 instead of clk ptrs
In-Reply-To: <1455967466-3812-1-git-send-email-t-kristo@ti.com>
References: <1455967466-3812-1-git-send-email-t-kristo@ti.com>
Message-ID: <20160222165959.GG13417@atomide.com>

* Tero Kristo <t-kristo at ti.com> [160220 03:24]:
> Convert DPLL support code to use clk_hw pointers for reference and bypass
> clocks. This allows us to use clk_hw_* APIs for accessing any required
> parameters for these clocks, avoiding some locking problems at least with
> DPLL enable code; this used clk_get_rate which uses mutex but isn't
> good under clk_enable / clk_disable.
> 
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---
> v2: rebased the patch on top of v2 of 'clk: ti: omap3+: dpll: use non-locking
>     version of clk_get_rate', as that one is required already for -rc. This
>     patch can follow in 4.6 merge window.

Yeah seems this one can wait for v4.6 merge window no problem:

Acked-by: Tony Lindgren <tony at atomide.com>

Regards,

Tony


From mika.penttila at nextfour.com  Mon Feb 22 09:00:05 2016
From: mika.penttila at nextfour.com (=?UTF-8?Q?Mika_Penttil=c3=a4?=)
Date: Mon, 22 Feb 2016 19:00:05 +0200
Subject: arm: set_memory_xx fixes patch missing?
In-Reply-To: <20160222150911.GA25429@luxor.wired.org>
References: <20160222150911.GA25429@luxor.wired.org>
Message-ID: <56CB3E95.1000500@nextfour.com>

On 22.02.2016 17:09, Paolo Pisati wrote:
> What's happened to the arm side of this patch:
>
> http://lkml.iu.edu/hypermail/linux/kernel/1601.2/04934.html
>
> the arm64 code is already in Linus's tree, while it seems like the arm part was
> lost and forgotten, and i don't see it in rmk's patch queue.
Now added to queue :

http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8544/1




From mark.rutland at arm.com  Mon Feb 22 09:03:46 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Mon, 22 Feb 2016 17:03:46 +0000
Subject: [PATCH] arm64: remove redundant preempt.h
In-Reply-To: <20160222095205.GA31168@arm.com>
References: <1455299803-317-1-git-send-email-yang.shi@linaro.org>
 <56C7AE26.1060407@linaro.org> <20160222095205.GA31168@arm.com>
Message-ID: <20160222170346.GN3435@leverpostej>

On Mon, Feb 22, 2016 at 09:52:05AM +0000, Will Deacon wrote:
> On Fri, Feb 19, 2016 at 04:07:02PM -0800, Shi, Yang wrote:
> > Any comment on this one?
> 
> I don't really see the point in it, to be honest. Relying on implicit
> #includes is usually a bad idea,

FWIW, in this case we aren't relying on implicit includes. That's when
you explicitly use something but haven't included the relevant header
directly.

For everything we explicitly use, we have included the relevant headers.

Anything that uses preempt.h implicitly should've pulled in preempt.h
via its headers.

> there are other files in the kernel including both of these headers
> and there's not actually a problem to fix as far as I can tell.

Up to you.

The patch does appear correct in that the include is redundant, but its
presence is admittedly not harmful.

Mark.

> 
> Will
> 
> > On 2/12/2016 9:56 AM, Yang Shi wrote:
> > >preempt.h has been included by sched.h, so it is not necessary to include
> > >both, just keep sched.h.
> > >
> > >Signed-off-by: Yang Shi <yang.shi at linaro.org>
> > >---
> > >Happened to find this when checking preempt.h include for another patch review.
> > >Build test is passed with and without CONFIG_PREEMPT enabled.
> > >
> > >  arch/arm64/kernel/cpuinfo.c | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > >diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> > >index 212ae63..e2b37ff 100644
> > >--- a/arch/arm64/kernel/cpuinfo.c
> > >+++ b/arch/arm64/kernel/cpuinfo.c
> > >@@ -25,7 +25,6 @@
> > >  #include <linux/init.h>
> > >  #include <linux/kernel.h>
> > >  #include <linux/personality.h>
> > >-#include <linux/preempt.h>
> > >  #include <linux/printk.h>
> > >  #include <linux/seq_file.h>
> > >  #include <linux/sched.h>
> > >
> > 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From draakje197 at gmail.com  Mon Feb 22 09:07:48 2016
From: draakje197 at gmail.com (Henry Paulissen)
Date: Mon, 22 Feb 2016 18:07:48 +0100
Subject: [PATCH v6] Fix sun7i pin assignment for IRQ's
Message-ID: <1456160876-1894-1-git-send-email-henry@nitronetworks.nl>

After testing IRQ pins we found some bugs in the pinctrl declaration.
Both PI* and PC* pins didn't work. PI* pins seemed to be connected
to the wrong mux and PC* pins waren't working at all.

Please note that the A20 soc manual is contradicting between version
and even within the same document for both the PI and PC pins.

Patch is based on testing with the hardware itself.

Tested-by: Andre Przywara <andre.przywara at arm.com>
Reviewed-by: Andre Przywara <andre.przywara at arm.com>
Signed-off-by: Henry Paulissen <henry at nitronetworks.nl>

---

Changes in v2:
    After some more testing we found irq on PI pins.
    they where on mux6 so this is included in my patch.

    Also included is a warning for PI17, this pin was not working
    on apritzel his bPI and he thinks it might be correlated to
    GIC and IRQ 29.

Changes in v3:
    Changed name from nickname to realname in email and SoB.

Changes in v4:
    Added closing parenthesis for the C pins.

Changes in v5:
    Added a more detailed description.

Changes in v6:
    Removed extra comment about pin I17 (extra tests needed).
    Added tested and reviewed by tags.

---
 drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c | 33 ++++++++++++++-----------------
 1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
index cf1ce0c..ca7b9a3 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
@@ -343,26 +343,22 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE4 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* CS0 */
-		  SUNXI_FUNCTION_IRQ(0x6, 12)),		/* EINT12 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* CS0 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 20),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE5 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* CLK */
-		  SUNXI_FUNCTION_IRQ(0x6, 13)),		/* EINT13 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* CLK */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 21),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE6 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* MOSI */
-		  SUNXI_FUNCTION_IRQ(0x6, 14)),		/* EINT14 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* MOSI */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 22),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE7 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* MISO */
-		  SUNXI_FUNCTION_IRQ(0x6, 15)),		/* EINT15 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* MISO */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 23),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
@@ -960,65 +956,66 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS0 */
 		  SUNXI_FUNCTION(0x3, "uart5"),		/* TX */
-		  SUNXI_FUNCTION_IRQ(0x5, 22)),		/* EINT22 */
+		  SUNXI_FUNCTION_IRQ(0x6, 22)),		/* EINT22 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 11),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CLK */
 		  SUNXI_FUNCTION(0x3, "uart5"),		/* RX */
-		  SUNXI_FUNCTION_IRQ(0x5, 23)),		/* EINT23 */
+		  SUNXI_FUNCTION_IRQ(0x6, 23)),		/* EINT23 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 12),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* MOSI */
 		  SUNXI_FUNCTION(0x3, "uart6"),		/* TX */
 		  SUNXI_FUNCTION(0x4, "clk_out_a"),	/* CLK_OUT_A */
-		  SUNXI_FUNCTION_IRQ(0x5, 24)),		/* EINT24 */
+		  SUNXI_FUNCTION_IRQ(0x6, 24)),		/* EINT24 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 13),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* MISO */
 		  SUNXI_FUNCTION(0x3, "uart6"),		/* RX */
 		  SUNXI_FUNCTION(0x4, "clk_out_b"),	/* CLK_OUT_B */
-		  SUNXI_FUNCTION_IRQ(0x5, 25)),		/* EINT25 */
+		  SUNXI_FUNCTION_IRQ(0x6, 25)),		/* EINT25 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 14),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS1 */
 		  SUNXI_FUNCTION(0x3, "ps2"),		/* SCK1 */
 		  SUNXI_FUNCTION(0x4, "timer4"),	/* TCLKIN0 */
-		  SUNXI_FUNCTION_IRQ(0x5, 26)),		/* EINT26 */
+		  SUNXI_FUNCTION_IRQ(0x6, 26)),		/* EINT26 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 15),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS1 */
 		  SUNXI_FUNCTION(0x3, "ps2"),		/* SDA1 */
 		  SUNXI_FUNCTION(0x4, "timer5"),	/* TCLKIN1 */
-		  SUNXI_FUNCTION_IRQ(0x5, 27)),		/* EINT27 */
+		  SUNXI_FUNCTION_IRQ(0x6, 27)),		/* EINT27 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 16),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS0 */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* RTS */
-		  SUNXI_FUNCTION_IRQ(0x5, 28)),		/* EINT28 */
+		  SUNXI_FUNCTION_IRQ(0x6, 28)),		/* EINT28 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 17),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CLK */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* CTS */
-		  SUNXI_FUNCTION_IRQ(0x5, 29)),		/* EINT29 */
+		  SUNXI_FUNCTION_IRQ(0x6, 29)),		/* EINT29 */
+		  /* EINT29 might not work - more testing needed */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 18),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* MOSI */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* TX */
-		  SUNXI_FUNCTION_IRQ(0x5, 30)),		/* EINT30 */
+		  SUNXI_FUNCTION_IRQ(0x6, 30)),		/* EINT30 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 19),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* MISO */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* RX */
-		  SUNXI_FUNCTION_IRQ(0x5, 31)),		/* EINT31 */
+		  SUNXI_FUNCTION_IRQ(0x6, 31)),		/* EINT31 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 20),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
-- 
2.5.0



From will.deacon at arm.com  Mon Feb 22 09:09:52 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 22 Feb 2016 17:09:52 +0000
Subject: [PATCH v3 1/4] of/fdt: factor out assignment of
 initrd_start/initrd_end
In-Reply-To: <CAKv+Gu_OGJG0i9T=ecFVQM-P8KRpasJ+h6L4onJgpaED07Q8Jg@mail.gmail.com>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455289046-21321-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160222164958.GJ31168@arm.com>
 <CAKv+Gu_OGJG0i9T=ecFVQM-P8KRpasJ+h6L4onJgpaED07Q8Jg@mail.gmail.com>
Message-ID: <20160222170952.GM31168@arm.com>

On Mon, Feb 22, 2016 at 05:56:40PM +0100, Ard Biesheuvel wrote:
> On 22 February 2016 at 17:49, Will Deacon <will.deacon at arm.com> wrote:
> > On Fri, Feb 12, 2016 at 03:57:23PM +0100, Ard Biesheuvel wrote:
> >> Since architectures may not yet have their linear mapping up and running
> >> when the initrd address is discovered from the DT, factor out the
> >> assignment of initrd_start and initrd_end, so that an architecture can
> >> override it and use the translation it needs.
> >>
> >> Cc: Rob Herring <robh at kernel.org>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >> ---
> >>  drivers/of/fdt.c | 14 +++++++++++---
> >>  1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > Mark, Rob, any comments on this?
> >
> 
> Already acked by Rob, and pulled into -next by Catalin ...

Weird, I don't see that in my inbox or on the list archives. Where should
I be looking?

I'd certainly like to see some performance measurement of the BUG_ON
in PHYS_ADDR that is introduced later in the series too.

Will


From draakje197 at gmail.com  Mon Feb 22 09:14:07 2016
From: draakje197 at gmail.com (Henry Paulissen)
Date: Mon, 22 Feb 2016 18:14:07 +0100
Subject: [PATCH v6] Fix sun7i pin assignment for IRQ's
Message-ID: <1456161251-2303-1-git-send-email-henry@nitronetworks.nl>

After testing IRQ pins we found some bugs in the pinctrl declaration.
Both PI* and PC* pins didn't work. PI* pins seemed to be connected
to the wrong mux and PC* pins waren't working at all.

Please note that the A20 soc manual is contradicting between version
and even within the same document for both the PI and PC pins.

Patch is based on testing with the hardware itself.

Tested-by: Andre Przywara <andre.przywara at arm.com>
Reviewed-by: Andre Przywara <andre.przywara at arm.com>
Signed-off-by: Henry Paulissen <henry at nitronetworks.nl>

---

Changes in v2:
    After some more testing we found irq on PI pins.
    they where on mux6 so this is included in my patch.

    Also included is a warning for PI17, this pin was not working
    on apritzel his bPI and he thinks it might be correlated to
    GIC and IRQ 29.

Changes in v3:
    Changed name from nickname to realname in email and SoB.

Changes in v4:
    Added closing parenthesis for the C pins.

Changes in v5:
    Added a more detailed description.

Changes in v6:
    Removed extra comment about pin I17 (extra tests needed).
    Added tested and reviewed by tags.

---
 drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c | 32 ++++++++++++++-----------------
 1 file changed, 14 insertions(+), 18 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
index cf1ce0c..435ad30 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
@@ -343,26 +343,22 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE4 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* CS0 */
-		  SUNXI_FUNCTION_IRQ(0x6, 12)),		/* EINT12 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* CS0 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 20),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE5 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* CLK */
-		  SUNXI_FUNCTION_IRQ(0x6, 13)),		/* EINT13 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* CLK */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 21),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE6 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* MOSI */
-		  SUNXI_FUNCTION_IRQ(0x6, 14)),		/* EINT14 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* MOSI */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 22),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE7 */
-		  SUNXI_FUNCTION(0x3, "spi2"),		/* MISO */
-		  SUNXI_FUNCTION_IRQ(0x6, 15)),		/* EINT15 */
+		  SUNXI_FUNCTION(0x3, "spi2")),		/* MISO */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 23),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
@@ -960,65 +956,65 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS0 */
 		  SUNXI_FUNCTION(0x3, "uart5"),		/* TX */
-		  SUNXI_FUNCTION_IRQ(0x5, 22)),		/* EINT22 */
+		  SUNXI_FUNCTION_IRQ(0x6, 22)),		/* EINT22 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 11),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CLK */
 		  SUNXI_FUNCTION(0x3, "uart5"),		/* RX */
-		  SUNXI_FUNCTION_IRQ(0x5, 23)),		/* EINT23 */
+		  SUNXI_FUNCTION_IRQ(0x6, 23)),		/* EINT23 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 12),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* MOSI */
 		  SUNXI_FUNCTION(0x3, "uart6"),		/* TX */
 		  SUNXI_FUNCTION(0x4, "clk_out_a"),	/* CLK_OUT_A */
-		  SUNXI_FUNCTION_IRQ(0x5, 24)),		/* EINT24 */
+		  SUNXI_FUNCTION_IRQ(0x6, 24)),		/* EINT24 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 13),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* MISO */
 		  SUNXI_FUNCTION(0x3, "uart6"),		/* RX */
 		  SUNXI_FUNCTION(0x4, "clk_out_b"),	/* CLK_OUT_B */
-		  SUNXI_FUNCTION_IRQ(0x5, 25)),		/* EINT25 */
+		  SUNXI_FUNCTION_IRQ(0x6, 25)),		/* EINT25 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 14),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi0"),		/* CS1 */
 		  SUNXI_FUNCTION(0x3, "ps2"),		/* SCK1 */
 		  SUNXI_FUNCTION(0x4, "timer4"),	/* TCLKIN0 */
-		  SUNXI_FUNCTION_IRQ(0x5, 26)),		/* EINT26 */
+		  SUNXI_FUNCTION_IRQ(0x6, 26)),		/* EINT26 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 15),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS1 */
 		  SUNXI_FUNCTION(0x3, "ps2"),		/* SDA1 */
 		  SUNXI_FUNCTION(0x4, "timer5"),	/* TCLKIN1 */
-		  SUNXI_FUNCTION_IRQ(0x5, 27)),		/* EINT27 */
+		  SUNXI_FUNCTION_IRQ(0x6, 27)),		/* EINT27 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 16),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CS0 */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* RTS */
-		  SUNXI_FUNCTION_IRQ(0x5, 28)),		/* EINT28 */
+		  SUNXI_FUNCTION_IRQ(0x6, 28)),		/* EINT28 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 17),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* CLK */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* CTS */
-		  SUNXI_FUNCTION_IRQ(0x5, 29)),		/* EINT29 */
+		  SUNXI_FUNCTION_IRQ(0x6, 29)),		/* EINT29 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 18),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* MOSI */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* TX */
-		  SUNXI_FUNCTION_IRQ(0x5, 30)),		/* EINT30 */
+		  SUNXI_FUNCTION_IRQ(0x6, 30)),		/* EINT30 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 19),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
 		  SUNXI_FUNCTION(0x2, "spi1"),		/* MISO */
 		  SUNXI_FUNCTION(0x3, "uart2"),		/* RX */
-		  SUNXI_FUNCTION_IRQ(0x5, 31)),		/* EINT31 */
+		  SUNXI_FUNCTION_IRQ(0x6, 31)),		/* EINT31 */
 	SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 20),
 		  SUNXI_FUNCTION(0x0, "gpio_in"),
 		  SUNXI_FUNCTION(0x1, "gpio_out"),
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 09:16:16 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 18:16:16 +0100
Subject: [PATCH v3 1/4] of/fdt: factor out assignment of
 initrd_start/initrd_end
In-Reply-To: <20160222170952.GM31168@arm.com>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455289046-21321-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160222164958.GJ31168@arm.com>
 <CAKv+Gu_OGJG0i9T=ecFVQM-P8KRpasJ+h6L4onJgpaED07Q8Jg@mail.gmail.com>
 <20160222170952.GM31168@arm.com>
Message-ID: <CAKv+Gu8H3hQ6tPmw-s6G7u5qzTXBvLndxDEynKx36r5eW5SDjg@mail.gmail.com>

On 22 February 2016 at 18:09, Will Deacon <will.deacon at arm.com> wrote:
> On Mon, Feb 22, 2016 at 05:56:40PM +0100, Ard Biesheuvel wrote:
>> On 22 February 2016 at 17:49, Will Deacon <will.deacon at arm.com> wrote:
>> > On Fri, Feb 12, 2016 at 03:57:23PM +0100, Ard Biesheuvel wrote:
>> >> Since architectures may not yet have their linear mapping up and running
>> >> when the initrd address is discovered from the DT, factor out the
>> >> assignment of initrd_start and initrd_end, so that an architecture can
>> >> override it and use the translation it needs.
>> >>
>> >> Cc: Rob Herring <robh at kernel.org>
>> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> >> ---
>> >>  drivers/of/fdt.c | 14 +++++++++++---
>> >>  1 file changed, 11 insertions(+), 3 deletions(-)
>> >
>> > Mark, Rob, any comments on this?
>> >
>>
>> Already acked by Rob, and pulled into -next by Catalin ...
>
> Weird, I don't see that in my inbox or on the list archives. Where should
> I be looking?
>
> I'd certainly like to see some performance measurement of the BUG_ON
> in PHYS_ADDR that is introduced later in the series too.
>

Apologies, I removed you from cc unintentionally.

http://thread.gmane.org/gmane.linux.ports.arm.kernel/478714


From ray.jui at broadcom.com  Mon Feb 22 09:17:13 2016
From: ray.jui at broadcom.com (Ray Jui)
Date: Mon, 22 Feb 2016 09:17:13 -0800
Subject: [PATCH 11/61] gpio: bcm-kona: Use devm_gpiochip_add_data() for
 gpio registration
In-Reply-To: <1456150130-2668-12-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
 <1456150130-2668-12-git-send-email-ldewangan@nvidia.com>
Message-ID: <67faee9e-e234-fc60-5465-3193bed4a7c3@broadcom.com>



On 2/22/2016 6:08 AM, Laxman Dewangan wrote:
> Use devm_gpiochip_add_data() for GPIO registration.
>
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Ray Jui <rjui at broadcom.com>
> ---
>  drivers/gpio/gpio-bcm-kona.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-bcm-kona.c b/drivers/gpio/gpio-bcm-kona.c
> index b6c5abe..2fd38d5 100644
> --- a/drivers/gpio/gpio-bcm-kona.c
> +++ b/drivers/gpio/gpio-bcm-kona.c
> @@ -630,7 +630,7 @@ static int bcm_kona_gpio_probe(struct platform_device *pdev)
>
>  	bcm_kona_gpio_reset(kona_gpio);
>
> -	ret = gpiochip_add_data(chip, kona_gpio);
> +	ret = devm_gpiochip_add_data(dev, chip, kona_gpio);
>  	if (ret < 0) {
>  		dev_err(dev, "Couldn't add GPIO chip -- %d\n", ret);
>  		goto err_irq_domain;
>

Acked-by: Ray Jui <ray.jui at broadcom.com>

Thanks!


From ard.biesheuvel at linaro.org  Mon Feb 22 09:17:40 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 18:17:40 +0100
Subject: [PATCH v3 4/4] arm64: prevent __va() translations before
 memstart_addr is assigned
In-Reply-To: <20160222165209.GK31168@arm.com>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455289046-21321-5-git-send-email-ard.biesheuvel@linaro.org>
 <20160222165209.GK31168@arm.com>
Message-ID: <CAKv+Gu_BFK0cpSP1N7NC3brmfuHeXqTBxr-MGAkefLPfFSw6Gg@mail.gmail.com>

On 22 February 2016 at 17:52, Will Deacon <will.deacon at arm.com> wrote:
> On Fri, Feb 12, 2016 at 03:57:26PM +0100, Ard Biesheuvel wrote:
>> Since memstart_addr is assigned relatively late in the boot code,
>> after generic code like DT parsing and memblock manipulation has
>> already occurred, we need to ensure that no __va() translation occur
>> until memstart_addr has been set to a meaningful value.
>>
>> So initialize memstart_addr to a value that cannot represent a valid
>> physical address, and BUG() if memstart_addr is referenced while it
>> still holds this value. Note that the > comparison against LLONG_MAX
>> (not ULLONG_MAX) resolves to a single tbnz instruction that performs
>> a conditional jump to a brk instruction that is emitted out of line.
>
> Even so, I'd imagine that having a measurable impact on system
> performance. Did you have a go at benchmarking this?
>

So in what kind of workload would the __pa() translation be on a hot
path? If you're dealing with DMA or other things that involve physical
addresses, surely, the single predicted non-taken branch instruction
shouldn't hurt?


From catalin.marinas at arm.com  Mon Feb 22 09:26:26 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 22 Feb 2016 17:26:26 +0000
Subject: [PATCH v3 4/4] arm64: prevent __va() translations before
 memstart_addr is assigned
In-Reply-To: <20160222165209.GK31168@arm.com>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455289046-21321-5-git-send-email-ard.biesheuvel@linaro.org>
 <20160222165209.GK31168@arm.com>
Message-ID: <20160222172625.GA5018@localhost.localdomain>

On Mon, Feb 22, 2016 at 04:52:09PM +0000, Will Deacon wrote:
> On Fri, Feb 12, 2016 at 03:57:26PM +0100, Ard Biesheuvel wrote:
> > Since memstart_addr is assigned relatively late in the boot code,
> > after generic code like DT parsing and memblock manipulation has
> > already occurred, we need to ensure that no __va() translation occur
> > until memstart_addr has been set to a meaningful value.
> > 
> > So initialize memstart_addr to a value that cannot represent a valid
> > physical address, and BUG() if memstart_addr is referenced while it
> > still holds this value. Note that the > comparison against LLONG_MAX
> > (not ULLONG_MAX) resolves to a single tbnz instruction that performs
> > a conditional jump to a brk instruction that is emitted out of line.
> 
> Even so, I'd imagine that having a measurable impact on system
> performance. Did you have a go at benchmarking this?

Good point, I forgot about this discussion. We should revert this part
indeed or at least make it dependent on some config option like
DEBUG_VM.

-- 
Catalin


From ard.biesheuvel at linaro.org  Mon Feb 22 09:38:39 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 18:38:39 +0100
Subject: [PATCH v3 4/4] arm64: prevent __va() translations before
 memstart_addr is assigned
In-Reply-To: <20160222172625.GA5018@localhost.localdomain>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455289046-21321-5-git-send-email-ard.biesheuvel@linaro.org>
 <20160222165209.GK31168@arm.com>
 <20160222172625.GA5018@localhost.localdomain>
Message-ID: <CAKv+Gu-E31zvB5EuMdX5pq9PMWYkF+Z7dkwZbK_WEDF3JJ+Yhw@mail.gmail.com>

On 22 February 2016 at 18:26, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 22, 2016 at 04:52:09PM +0000, Will Deacon wrote:
>> On Fri, Feb 12, 2016 at 03:57:26PM +0100, Ard Biesheuvel wrote:
>> > Since memstart_addr is assigned relatively late in the boot code,
>> > after generic code like DT parsing and memblock manipulation has
>> > already occurred, we need to ensure that no __va() translation occur
>> > until memstart_addr has been set to a meaningful value.
>> >
>> > So initialize memstart_addr to a value that cannot represent a valid
>> > physical address, and BUG() if memstart_addr is referenced while it
>> > still holds this value. Note that the > comparison against LLONG_MAX
>> > (not ULLONG_MAX) resolves to a single tbnz instruction that performs
>> > a conditional jump to a brk instruction that is emitted out of line.
>>
>> Even so, I'd imagine that having a measurable impact on system
>> performance. Did you have a go at benchmarking this?
>
> Good point, I forgot about this discussion. We should revert this part
> indeed or at least make it dependent on some config option like
> DEBUG_VM.
>

OK, let me code that up


From catalin.marinas at arm.com  Mon Feb 22 09:41:24 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Mon, 22 Feb 2016 17:41:24 +0000
Subject: [PATCH v3 4/4] arm64: prevent __va() translations before
 memstart_addr is assigned
In-Reply-To: <CAKv+Gu_BFK0cpSP1N7NC3brmfuHeXqTBxr-MGAkefLPfFSw6Gg@mail.gmail.com>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455289046-21321-5-git-send-email-ard.biesheuvel@linaro.org>
 <20160222165209.GK31168@arm.com>
 <CAKv+Gu_BFK0cpSP1N7NC3brmfuHeXqTBxr-MGAkefLPfFSw6Gg@mail.gmail.com>
Message-ID: <20160222174124.GB5018@localhost.localdomain>

On Mon, Feb 22, 2016 at 06:17:40PM +0100, Ard Biesheuvel wrote:
> On 22 February 2016 at 17:52, Will Deacon <will.deacon at arm.com> wrote:
> > On Fri, Feb 12, 2016 at 03:57:26PM +0100, Ard Biesheuvel wrote:
> >> Since memstart_addr is assigned relatively late in the boot code,
> >> after generic code like DT parsing and memblock manipulation has
> >> already occurred, we need to ensure that no __va() translation occur
> >> until memstart_addr has been set to a meaningful value.
> >>
> >> So initialize memstart_addr to a value that cannot represent a valid
> >> physical address, and BUG() if memstart_addr is referenced while it
> >> still holds this value. Note that the > comparison against LLONG_MAX
> >> (not ULLONG_MAX) resolves to a single tbnz instruction that performs
> >> a conditional jump to a brk instruction that is emitted out of line.
> >
> > Even so, I'd imagine that having a measurable impact on system
> > performance. Did you have a go at benchmarking this?
> 
> So in what kind of workload would the __pa() translation be on a hot
> path? If you're dealing with DMA or other things that involve physical
> addresses, surely, the single predicted non-taken branch instruction
> shouldn't hurt?

I recall we looked at this in the early arm64 days and found a lot of
memory accesses to memstart_addr but we decided to keep it as the
alternatives would have been: (a) no more single Image or (b) always
4-levels page tables.

You could try perf to get some statistics but, for example, most of the
code that works on pages (e.g. block I/O) and needs to access a page
ends up doing a kmap(page) which in turns does a __va(). You also have
lots of virt_to_page() calls in sl*b, so we need to see what impact this
change has.

-- 
Catalin


From ard.biesheuvel at linaro.org  Mon Feb 22 09:46:03 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 18:46:03 +0100
Subject: [PATCH 1/2] arm64: mm: only perform memstart_addr sanity check if
 DEBUG_VM
Message-ID: <1456163164-23251-1-git-send-email-ard.biesheuvel@linaro.org>

Checking whether memstart_addr has been assigned every time it is
referenced adds a branch instruction that may hurt performance if
the reference in question occurs on a hot path. So only perform the
check if CONFIG_DEBUG_VM=y.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/memory.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 68e7d96b9ed3..771d0b506e4b 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -134,7 +134,11 @@
 
 extern phys_addr_t		memstart_addr;
 /* PHYS_OFFSET - the physical address of the start of memory. */
+#ifndef CONFIG_DEBUG_VM
+#define PHYS_OFFSET		({ memstart_addr; })
+#else
 #define PHYS_OFFSET		({ BUG_ON(memstart_addr & 1); memstart_addr; })
+#endif
 
 /* the virtual base of the kernel image (minus TEXT_OFFSET) */
 extern u64			kimage_vaddr;
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 09:46:04 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 18:46:04 +0100
Subject: [PATCH 2/2] arm64: mm: use bit ops rather than arithmetic in pa/va
 translations
In-Reply-To: <1456163164-23251-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456163164-23251-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456163164-23251-2-git-send-email-ard.biesheuvel@linaro.org>

Since PAGE_OFFSET is chosen such that it cuts the kernel VA space right
in half, and since the size of the kernel VA space itself is always a
power of 2, we can treat PAGE_OFFSET as a bitmask and replace the
additions/subtractions with 'or' and 'and-not' operations.

For the comparison against PAGE_OFFSET, a mov/cmp/branch sequence ends
up getting replaced with a single tbz instruction. For the additions and
subtractions, we save a mov instruction since the mask is folded into the
instruction's immediate field.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/memory.h | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 771d0b506e4b..2296b32130a1 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -88,10 +88,10 @@
  */
 #define __virt_to_phys(x) ({						\
 	phys_addr_t __x = (phys_addr_t)(x);				\
-	__x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :	\
-			     (__x - kimage_voffset); })
+	__x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET :	\
+				 (__x - kimage_voffset); })
 
-#define __phys_to_virt(x)	((unsigned long)((x) - PHYS_OFFSET + PAGE_OFFSET))
+#define __phys_to_virt(x)	((unsigned long)((x) - PHYS_OFFSET) | PAGE_OFFSET)
 #define __phys_to_kimg(x)	((unsigned long)((x) + kimage_voffset))
 
 /*
@@ -131,6 +131,7 @@
 #endif
 
 #ifndef __ASSEMBLY__
+#include <linux/bitops.h>
 
 extern phys_addr_t		memstart_addr;
 /* PHYS_OFFSET - the physical address of the start of memory. */
-- 
2.5.0



From marc.zyngier at arm.com  Mon Feb 22 09:51:20 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Mon, 22 Feb 2016 17:51:20 +0000
Subject: [PATCH v12 03/21] KVM: ARM64: Add offset defines for PMU registers
In-Reply-To: <1456133877-9584-4-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
 <1456133877-9584-4-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <56CB4A98.2020403@arm.com>

On 22/02/16 09:37, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
> 
> We are about to trap and emulate accesses to each PMU register
> individually. This adds the context offsets for the AArch64 PMU
> registers.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
> Reviewed-by: Andrew Jones <drjones at redhat.com>
> ---
>  arch/arm64/include/asm/kvm_host.h | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 6f0241f..6bab7fb 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -115,6 +115,21 @@ enum vcpu_sysreg {
>  	MDSCR_EL1,	/* Monitor Debug System Control Register */
>  	MDCCINT_EL1,	/* Monitor Debug Comms Channel Interrupt Enable Reg */
>  
> +	/* Performance Monitors Registers */
> +	PMCR_EL0,	/* Control Register */
> +	PMOVSSET_EL0,	/* Overflow Flag Status Set Register */
> +	PMSELR_EL0,	/* Event Counter Selection Register */
> +	PMEVCNTR0_EL0,	/* Event Counter Register (0-30) */
> +	PMEVCNTR30_EL0 = PMEVCNTR0_EL0 + 30,
> +	PMCCNTR_EL0,	/* Cycle Counter Register */
> +	PMEVTYPER0_EL0,	/* Event Type Register (0-30) */
> +	PMEVTYPER30_EL0 = PMEVTYPER0_EL0 + 30,
> +	PMCCFILTR_EL0,	/* Cycle Count Filter Register */
> +	PMCNTENSET_EL0,	/* Count Enable Set Register */
> +	PMINTENSET_EL1,	/* Interrupt Enable Set Register */
> +	PMUSERENR_EL0,	/* User Enable Register */
> +	PMSWINC_EL0,	/* Software Increment Register */
> +

I've just noticed a rather fundamental issue with this: this makes it
impossible to bisect the whole series.

I was trying to pinpoint a performance regression with this series, and
started bisecting. Unfortunately, declaring these registers in one go
means that we end-up with uninitialized registers after this patch (and
probably until PMUSERENR is dealt with). The consequence of that is
something like this:

Kernel panic - not syncing: Didn't reset vcpu_sys_reg(25)
CPU: 1 PID: 1994 Comm: lkvm Tainted: G        W       4.5.0-rc5+ #5563
Hardware name: Default string Default string/Default string, BIOS
ROD0084E 09/03/2015
Call trace:
[<ffffffc000089a20>] dump_backtrace+0x0/0x1a8
[<ffffffc000089bdc>] show_stack+0x14/0x20
[<ffffffc00033490c>] dump_stack+0x94/0xb8
[<ffffffc00014ddbc>] panic+0x10c/0x250
[<ffffffc0000a9c94>] kvm_reset_sys_regs+0xec/0xf0
[<ffffffc0000a7878>] kvm_reset_vcpu+0x58/0x80
[<ffffffc0000a2c44>] kvm_arch_vcpu_ioctl+0x294/0x310
[<ffffffc00009d6b4>] kvm_vcpu_ioctl+0xcc/0x698
[<ffffffc0001cb184>] do_vfs_ioctl+0xa4/0x750
[<ffffffc0001cb8bc>] SyS_ioctl+0x8c/0xa0
[<ffffffc000085d30>] el0_svc_naked+0x24/0x28

The obvious fix would be to introduce each register with the patch that
handles it. At least, we'll be able to bisect it...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From tony at atomide.com  Mon Feb 22 09:54:26 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 09:54:26 -0800
Subject: [PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred
 probe for pm_runtime_reinit
In-Reply-To: <CAPDyKFpwGcCW_Vwz07cgh8LxGmxu9=GVch0MVJEpNJ19zoLZ7g@mail.gmail.com>
References: <1455145370-20301-1-git-send-email-tony@atomide.com>
 <1455145370-20301-2-git-send-email-tony@atomide.com>
 <CAPDyKFpAcsfLgtu93P45fTEg11MjdGwREcyeGSS7vt6GWbNu_w@mail.gmail.com>
 <20160211150240.GR19432@atomide.com>
 <CAPDyKFo4Jyjwyvr3P5VHfDhQ87K9mnR01N-NtKz-yx2ycnfOLg@mail.gmail.com>
 <20160211172632.GT19432@atomide.com>
 <CAPDyKFpwGcCW_Vwz07cgh8LxGmxu9=GVch0MVJEpNJ19zoLZ7g@mail.gmail.com>
Message-ID: <20160222175426.GI13417@atomide.com>

* Ulf Hansson <ulf.hansson at linaro.org> [160212 05:00]:
> On 11 February 2016 at 18:26, Tony Lindgren <tony at atomide.com> wrote:
> > Subject: [PATCH] mmc: omap_hsmmc: Fix PM regression with deferred probe for
> >  pm_runtime_reinit
>
> Thanks, applied for fixes!

Ulf, any news on getting this into the mainline tree?

My PM tests have been now broken for six weeks or something
because of this!

Regards,

Tony


From ard.biesheuvel at linaro.org  Mon Feb 22 09:55:53 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 18:55:53 +0100
Subject: [PATCH v3 4/4] arm64: prevent __va() translations before
 memstart_addr is assigned
In-Reply-To: <20160222174124.GB5018@localhost.localdomain>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455289046-21321-5-git-send-email-ard.biesheuvel@linaro.org>
 <20160222165209.GK31168@arm.com>
 <CAKv+Gu_BFK0cpSP1N7NC3brmfuHeXqTBxr-MGAkefLPfFSw6Gg@mail.gmail.com>
 <20160222174124.GB5018@localhost.localdomain>
Message-ID: <CAKv+Gu__aTAud736rqHdRk7=aObnZr8yjVXMBBmmv_TR=mqm-A@mail.gmail.com>

On 22 February 2016 at 18:41, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 22, 2016 at 06:17:40PM +0100, Ard Biesheuvel wrote:
>> On 22 February 2016 at 17:52, Will Deacon <will.deacon at arm.com> wrote:
>> > On Fri, Feb 12, 2016 at 03:57:26PM +0100, Ard Biesheuvel wrote:
>> >> Since memstart_addr is assigned relatively late in the boot code,
>> >> after generic code like DT parsing and memblock manipulation has
>> >> already occurred, we need to ensure that no __va() translation occur
>> >> until memstart_addr has been set to a meaningful value.
>> >>
>> >> So initialize memstart_addr to a value that cannot represent a valid
>> >> physical address, and BUG() if memstart_addr is referenced while it
>> >> still holds this value. Note that the > comparison against LLONG_MAX
>> >> (not ULLONG_MAX) resolves to a single tbnz instruction that performs
>> >> a conditional jump to a brk instruction that is emitted out of line.
>> >
>> > Even so, I'd imagine that having a measurable impact on system
>> > performance. Did you have a go at benchmarking this?
>>
>> So in what kind of workload would the __pa() translation be on a hot
>> path? If you're dealing with DMA or other things that involve physical
>> addresses, surely, the single predicted non-taken branch instruction
>> shouldn't hurt?
>
> I recall we looked at this in the early arm64 days and found a lot of
> memory accesses to memstart_addr but we decided to keep it as the
> alternatives would have been: (a) no more single Image or (b) always
> 4-levels page tables.
>
> You could try perf to get some statistics but, for example, most of the
> code that works on pages (e.g. block I/O) and needs to access a page
> ends up doing a kmap(page) which in turns does a __va(). You also have
> lots of virt_to_page() calls in sl*b, so we need to see what impact this
> change has.
>

I guess virt_to_page() is only valid on linear addresses, so we could
reimplement it not to use the comparison with PAGE_OFFSET that I added
to __pa() for the kernmap stuff


From tony at atomide.com  Mon Feb 22 09:57:26 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 09:57:26 -0800
Subject: [PATCH] ARM: dts: omap3-n900: Allow gpio keys to be disabled
In-Reply-To: <1456152179-12558-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
References: <20160212215326.GD19432@atomide.com>
 <1456152179-12558-1-git-send-email-ivo.g.dimitrov.75@gmail.com>
Message-ID: <20160222175726.GJ13417@atomide.com>

* Ivaylo Dimitrov <ivo.g.dimitrov.75 at gmail.com> [160222 06:43]:
> Add linux,can-disable; to all gpios exported from gpio-keys driver, so
> userspace can disable them

Thanks applying into omap-for-v4.6/dt.

Tony


From thierry.reding at gmail.com  Mon Feb 22 09:59:29 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Mon, 22 Feb 2016 18:59:29 +0100
Subject: [PATCH v3 00/12] pwm: add support for atomic update
In-Reply-To: <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
References: <1442828009-6241-1-git-send-email-boris.brezillon@free-electrons.com>
 <2341981.a79ioYM9Es@diego> <20151110173416.GB21727@ulmo>
 <CAD=FV=WL3jYEgVe-m6QcAyQwfJgdX4J5OtKisKwyoKOrTSpEQA@mail.gmail.com>
 <20160125170855.GA10182@ulmo>
 <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
 <20160203145337.GD9650@ulmo>
 <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
Message-ID: <20160222175929.GA23899@ulmo>

On Wed, Feb 03, 2016 at 11:04:20AM -0800, Doug Anderson wrote:
> Thierry
> 
> On Wed, Feb 3, 2016 at 6:53 AM, Thierry Reding <thierry.reding at gmail.com> wrote:
> >> A) The software state here is the period and flags (AKA "inverted),
> >> right?  It does seem possible that you could apply the period and
> >> flags while keeping the calculated bootup duty cycle percentage
> >> (presuming that the PWM was actually enabled at probe time and there
> >> was a bootup duty cycle at all).  That would basically say that
> >> whenever you set the period of a PWM then the duty cycle of the PWM
> >> should remain the same percentage.  That actually seems quite sane
> >> IMHO.  It seems much saner than trying to keep the duty cycle "ns"
> >> when the period changes or resetting the PWM to some default when the
> >> period changes.
> >
> > That really depends on the use-case. If you're interested in the output
> > power of the PWM then, yes, this is sane. But it might not be the right
> > answer in other cases.
> 
> Ah, I see.  You're envisioning a device where active time in "ns" is
> more important than the percentage of active time.  Perhaps an LED
> where it's more important to have it on for no more than .1 seconds
> (so we don't drive it too long and burn it out?).  If we slowed down
> the duty cycle and adjusted the period to match, we could get into a
> bad state.

Yes. Granted, the vast majority of users is not in this category, but
it's something that has been brought to my attention in the past and it
works fine with the current API.

> >> B) Alternatively, I'd also say that setting a period without a duty
> >> cycle doesn't make a lot of sense.  ...so you could just apply the
> >> period at the same time that you apply the duty cycle the first time.
> >> Presumably you'd want to "lie" to the callers of the PWM subsystem and
> >> tell them that you already changed the period even though the change
> >> won't really take effect until they actually set the duty cycle.  If
> >> anyone cared to find out the true hardware period we could add a new
> >> pwm_get_hw_period().  ...or since the only reason you'd want to know
> >> the hardware period would be if you're trying to read the current duty
> >> cycle percentage, you could instead add "pwm_get_hw_state()" and have
> >> that return both the hardware period ns and duty cycle ns (which is
> >> the most accurate way to return the "percentage" without using fix or
> >> floating point math).
> >
> > But then you get into a situation where behaviour is dependent on the
> > PWM driver, whereas this is really very specific to one specific use-
> > case.
> 
> This is because only some drivers would be able to read the hardware
> state?  I'm not sure how we can get away from that.  In all proposals
> we've talked about (including what you propose below, right?) the PWM
> regulator will need a PWM driver that can read hardware state.  Only
> PWM drivers that have been upgraded to support reading hardware state
> can use the PWM regulator (or at least only those drivers will be able
> to use the PWM regulator glitch-free).

Yes, the key here is glitch-free. There's no reason whatsoever that the
rugaltor-pwm driver should be limited to usage with a hardware readout-
capable PWM driver. If you don't care about glitches, likely because no
critical components depend on the regulator, you can simply force what
state you choose on boot.

As a matter of fact, I think that's how regulators work already. If the
current output voltage doesn't match the specified constraints, then a
valid value will be forced by the regulator core. If the voltage lies
within the constraints the core won't touch the regulator. Is this not
going to "just work" with the PWM regulator?

The problem is somewhat simplified if that's the case. An implementation
could then fail the regulator_get_voltage() if hardware readout is not
supported and return the current voltage when readout is possible.

> When we add a new feature then it's expected that only updated drivers
> will support that feature.
> 
> We need to make sure that we don't regress / negatively change the
> behavior for anyone running non-updated drivers.  ...and we should
> strive to require as few changes to drivers as possible.  ...but if
> the best we can do requires changes to the PWM driver API then we will
> certainly have differences depending on the PWM driver.

How so? Drivers should behave consistently, irrespective of the API. Of
course if you need to change behaviour of the user driver depending on
the availability of a certain feature, that's perfectly fine.

Furthermore it's out of the question that changes to the API will be
required. That's precisely the reason why the atomic PWM proposal came
about. It's an attempt to solve the shortcomings of the current API for
cases such as Rockchip.

> > In the end the PWM API is as low-level as it is because it needs to be
> > flexible enough to cope with other use-cases. In the general case the
> > simple truth is that it doesn't make sense to set a period without the
> > duty cycle and vice versa. That's why pwm_config() takes both as input
> > parameters. The atomic API is going to take that one step further in
> > that you need to specify the complete state of the PWM when applying.
> 
> I guess this is still showing the strangeness of the device tree
> specifying a period without a duty cycle.  You just said it doesn't
> make sense, but that's exactly what the device tree has.

The device tree specifies the period because there is no way for the
driver (such as pwm-backlight) to "guess" the right one. Furthermore
there is a certain degree of board-specificity to that parameter and
therefore any heuristic trying to come up with a sensible value will
inevitably fail eventually.

> I'd imagine that the only reason that the device tree specifies just
> the period is that it's intended to be there only for clients that
> don't care about the specific duty cycle in terms of seconds but
> _only_ care about the duty cycle in terms of percentage.  Anyone who
> cared about the duty cycle in terms of seconds would presumably also
> care about specifying the period (in terms of seconds) in the same
> place they specify the duty cycle.

Yes, exactly.

> >> > That doesn't really get us closer, though. There is still the issue of
> >> > the user having to deal with two states: the current hardware state and
> >> > the software state as configured in DT or board files.
> >>
> >> I think the only users that need to deal with this are one that need a
> >> seamless transition from bootup settings.  Adding a new API call to
> >> support a new feature like this doesn't seem insane, and anyone who
> >> doesn't want this new feature can just never call the new API.
> >>
> >> The only thing that would "change" from the point of view of old
> >> drivers is that the PWM period wouldn't change at bootup until the
> >> duty cycle was set.  IMHO this is probably a bug fix.  AKA, for a PWM
> >> backlight, imagine:
> >>
> >> 1. Firmware sets period to 20000 ns, duty cycle to 8000 ns (40%)
> >> 2. Linux boots up and sets period to 10000 ns.  Brightness of
> >> backlight instantly goes to 80%.
> >> 3. Eventually something decides to set the backlight duty cycle and it
> >> goes to the proper rate.
> >>
> >> Skipping #2 seems like the right move.  ...or did I misunderstand how
> >> something works?
> >
> > I'm not aware of any code in the PWM subsystem that would do this
> > automatically. If you don't call any of the pwm_*() functions the
> > hardware state should not be modified. The responsibility is with
> > the user drivers.
> 
> Ah, OK.  I must have gotten confused.
> 
> Oh, I see.  So pwm_get_period() is actually "lying" about the hardware
> today!  So what you're saying is that at boot time we grab the period
> out of the device tree but we _don't_ apply it to the hardware, right?
>  I was thinking it would get applied right away...

That's correct. The value retrieved by pwm_get_period() is the one
specified in DT (or a PWM lookup table). It should match the hardware
value after the first call to pwm_config(), though.

> That means that if you call pwm_get_period() right away at boot time
> you're not getting the current period of the hardware but the period
> that was specified in the device tree.

Yes.

> So all we need is a new API call that lets you read the hardware
> values and make sure that the PWM regulator calls that before anyone
> calls pwm_config().  That's roughly B) above.

Yes. I'm thinking that we should have a pwm_get_state() which retrieves
the current state of the PWM. For drivers that support hardware readout
this state should match the hardware state. For other drivers it should
reflect whatever was specified in DT; essentially what pwm_get_period()
and friends return today.

That way if you want to get the current voltage in the regulator-pwm
driver you'd simply do a pwm_get_state() and compute the voltage from
the period and duty cycle. If the PWM driver that you happen to use
doesn't support hardware readout, you'll get an initial output voltage
of 0, which is as good as any, really.

> > That is, it is up to the regulator or backlight driver to apply any new
> > configuration to a PWM channel on boot, or leave it as is. For
> > backlight it's probably fine to simply apply some default, since having
> > the brightness change on boot isn't going to be terribly irritating.
> >
> > With the atomic API it would be possible to avoid even this and have the
> > backlight driver simply read out the current hardware state and apply an
> > equivalent brightness even if the period changed.
> >
> > For the regulator case you'd need to read out the current state and then
> > recompute the values that will yield the same output power given data
> > specified in DT. I think that much is already implemented in Boris'
> > series, and it's really only the details that are being debated.
> >
> > The problematic issue is still that we might have a disparity between
> > the current hardware state and the state initially specified by DT. In
> > the general case the DT will specify the period and polarity of the PWM
> > signal and leave it up to the user driver to determine what a correct
> > duty cycle would be. With the atomic API we'll essentially have two
> > states: the current (hardware) state and the "initial" state, which is
> > what an OS will see as the state to apply. The problem now is that once
> > you have applied the initial state with a duty cycle you've determined,
> > there is no longer a need to keep it around. But there's also no way to
> > know when this is the case. So the controversial part about all this is
> > when to start using the current state rather that the initial state.
> >
> > The most straightforward way to solve this would be to apply the initial
> > configuration on driver probe. That is, when the pwm-regulator driver
> > gets probed it would retrieve the current and initial states, then
> > adjust the current state such that it matches the initial state but with
> > a duty cycle that yields the same output power as the current state, and
> > finally apply the new state. After that, every regulator_set_voltage()
> > call could simply operate on the current state and adjust the duty cycle
> > exclusively.
> >
> > Does that sound reasonable?
> 
> Sure.  ...but you agree that somehow you need a new API call for this,
> right?  Somehow the PWM regulator needs to be able to say that it
> wants the hardware state, not the initial state as specified in the
> device tree.

The atomic PWM API is this new API. I'm not arguing that we don't need
new API. What's being discussed is what the API needs to look like to
support this new use-case and at the same time be maximally compatible
with existing users.

I think perhaps one question that needs answering to do that is whether
or not the regulator-pwm driver can guess the correct period. The issue
that was initially being discussed is what to do with hardware state vs
initial state (i.e. what's defined in DT). Mark commented in another
subthread that DT should simply leave out data that doesn't make sense
to be specified.

However I don't think there's any particularly reasonable period for the
regulator-pwm use-case, so specifying the period within DT would still
be necessary. What works for one board may not be the correct (or
optimal) value for another. Similarly one board may need to invert the
PWM signal to generate the proper voltage, or require other parameters
that we haven't even defined yet.

There's also the issue of a voltage table that you need to define in the
DT for the regulator-pwm device. Does that consist of only duty-cycle
values, or does it have corresponding period values as well. I'd guess
that it really only needs the duty cycle given any period. So something
like this is what I'd expect:

	regulator {
		compatible = "regulator-pwm";

		pwms = <&pwm0 5000>;

		voltages = <0 0>, <1000000 1000>, ..., <5000000 5000>;
	};

I think the pwm-regulator binding defines the duty cycle in percent. I
guess that would work equally well.

And now we've come full circle because, again, we need to differentiate
between the current hardware state and the initial state. Or, as was
also discussed previously, alternatively, ignore the period specified in
DT and just go with what hardware readout defined. In case hardware
readout isn't supported, the "hardware state" will simply be the
"initial state".

The objection to the latter alternative was that we shouldn't trust the
firmware to have set up the regulator correctly. But if it didn't, how
can we trust that the duty cycle to period ratio is correct? Or the
other way around: if we trust the duty cycle to period ratio to have
been setup correctly, why don't we trust the period?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160222/39845c13/attachment.sig>

From will.deacon at arm.com  Mon Feb 22 10:00:57 2016
From: will.deacon at arm.com (Will Deacon)
Date: Mon, 22 Feb 2016 18:00:57 +0000
Subject: [PATCH v3 3/4] arm64: prevent potential circular header
 dependencies in asm/bug.h
In-Reply-To: <1455289046-21321-4-git-send-email-ard.biesheuvel@linaro.org>
References: <1455289046-21321-1-git-send-email-ard.biesheuvel@linaro.org>
 <1455289046-21321-4-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160222180056.GN31168@arm.com>

On Fri, Feb 12, 2016 at 03:57:25PM +0100, Ard Biesheuvel wrote:
> Currently, using BUG_ON() in header files is cumbersome, due to the fact
> that asm/bug.h transitively includes a lot of other header files, resulting
> in the actual BUG_ON() invocation appearing before its definition in the
> preprocessor input. So let's reverse the #include dependency between
> asm/bug.h and asm/debug-monitors.h, by moving the definition of BUG_BRK_IMM
> from the latter to the former. Also fix up one user of asm/debug-monitors.h
> which relied on a transitive include.
> 
> Cc: Dave Martin <Dave.Martin at arm.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
>  arch/arm64/include/asm/bug.h            | 2 +-
>  arch/arm64/include/asm/debug-monitors.h | 2 +-
>  arch/arm64/kvm/hyp/debug-sr.c           | 1 +
>  3 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/bug.h b/arch/arm64/include/asm/bug.h
> index 4a748ce9ba1a..679d49221998 100644
> --- a/arch/arm64/include/asm/bug.h
> +++ b/arch/arm64/include/asm/bug.h
> @@ -18,7 +18,7 @@
>  #ifndef _ARCH_ARM64_ASM_BUG_H
>  #define _ARCH_ARM64_ASM_BUG_H
>  
> -#include <asm/debug-monitors.h>
> +#define BUG_BRK_IMM			0x800

I'd really like to keep all the BRK immediates together, otherwise it's
error-prone if/when we allocate new encodings. Maybe we could add a new
header file for them, if we really need to?

Alternatively, given that this is all behind DEBUG_VM, you could rewrite
the check as if (unlikely(...)) panic(...);

Will


From mathieu.poirier at linaro.org  Mon Feb 22 10:01:20 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Mon, 22 Feb 2016 11:01:20 -0700
Subject: [PATCH V2 3/6] stm class: provision for statically assigned
 masterIDs
In-Reply-To: <CANLsYkz1nNYdcTXrkZ+HAMHexNandm93EpM7auvYE4CY43hy6w@mail.gmail.com>
References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org>
 <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org>
 <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com>
 <CANLsYky2twQ98u241YyHD=atYRp1N56YVHUQNY2E2Ljsq0cseA@mail.gmail.com>
 <87twlj49k7.fsf@ashishki-desk.ger.corp.intel.com>
 <CANLsYkw=mG+ch8QzxmbwWs9o+mndVNo1MuqXcrPrNJYj_SQcHQ@mail.gmail.com>
 <87r3gh3nd7.fsf@ashishki-desk.ger.corp.intel.com>
 <CANLsYkz1nNYdcTXrkZ+HAMHexNandm93EpM7auvYE4CY43hy6w@mail.gmail.com>
Message-ID: <CANLsYkyaPv_F+TGdGyKMyszs+ocCC=FzfP+Rmqf+O1XT9Wib9w@mail.gmail.com>

On 12 February 2016 at 13:33, Mathieu Poirier
<mathieu.poirier at linaro.org> wrote:
> On 12 February 2016 at 09:27, Alexander Shishkin
> <alexander.shishkin at linux.intel.com> wrote:
>> Mathieu Poirier <mathieu.poirier at linaro.org> writes:
>>
>>> On 8 February 2016 at 06:26, Alexander Shishkin
>>> <alexander.shishkin at linux.intel.com> wrote:
>>>> This $end==$start situation itself may be ambiguous and can be
>>>> interpreted either as having just one *static* master ID fixed for all
>>>> SW writers (what I assumed from your commit message) or as having a
>>>> floating master ID, which changes of its own accord and is not
>>>> controllable by software.
>>>
>>> Some clarification here.
>>>
>>> On ARM from a SW point of view $end == $start and that doesn't change
>>> (with regards to masterIDs) .  The ambiguity comes from the fact that
>>> on other platforms where masterID configuration does change and is
>>> important, the condition $end == $start could also be valid.
>>
>> Yes, that's what I was saying. The thing is, on the system-under-tracing
>> side these two situations are not very different from one
>> another. Master IDs are really just numbers without any semantics
>> attached to them in the sense that they are not covered by the mipi spec
>> or any other standard (to my knowledge).
>
> We are definitely on the same page here, just using slightly different terms.
>
>>
>> The difference is in the way we map channels to masters. One way is to
>> allocate a distinct set of channels for each master (the way Intel Trace
>> Hub does it); another way is to share the same set of channels between
>> multiple masters.
>
> We are in total agreement.
>
>> So we can describe this as "hardware implements the
>> same set of channels across multiple masters" or something along those
>> lines.
>
> I suggest "Shared channels"?  In the end, that's really what it is...
>
> The outstanding issue is still how to represent these to different way
> of mapping things in the STM core.  I suggested a flag, called
> "mstatic" (but that can be changed), and a representation of '-1' in
> for masterIDs sysFS.  Whether we stick with that or not is irrelevant,
> I'd be fine with another mechanism.  What I am keen on is that from
> sysFS users can quickly tell which heuristic is enacted on that
> specific architecture.

Alex,

How do you want to proceed with the above?  Do you agree with my
current proposal or can you think of a better way?

Thanks,
Mathieu


>
>>
>> Actually, in the latter scheme of things you can also have multiple
>> masters, at least theoretically. Say, you have masters [0..15], each
>> with distinct set of channels, but depending on hardware state these
>> masters actually end up as $state*16+$masterID in the STP stream.
>>
>> So we might also think about differentiating between the hardware
>> masters (0 though 15 in the above example) and STP masters.
>
> I'm not sure I get what you mean here.  On ARM the masterIDs assigned
> in HW, which will depend on the state, will show up in the STP stream.
> But again, I might be missing your point.
>
> Thanks,
> Mathieu
>
>>
>> Regards,
>> --
>> Alex


From tony at atomide.com  Mon Feb 22 10:02:01 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 10:02:01 -0800
Subject: [PATCH 1/2] ARM: OMAP1: DMA: Provide dma_slave_map to omap-dma
In-Reply-To: <56CAB676.6080309@ti.com>
References: <1454423227-31830-1-git-send-email-peter.ujfalusi@ti.com>
 <1454423227-31830-2-git-send-email-peter.ujfalusi@ti.com>
 <20160219214426.GK1640@darkstar.musicnaut.iki.fi>
 <56CAB676.6080309@ti.com>
Message-ID: <20160222180201.GK13417@atomide.com>

* Peter Ujfalusi <peter.ujfalusi at ti.com> [160221 23:19]:
> On 2016-02-19 23:44, Aaro Koskinen wrote:
> > On Tue, Feb 02, 2016 at 04:27:06PM +0200, Peter Ujfalusi wrote:
> >> OMAP1 can not boot in DT mode and to be able to clean up the driver
> >> regarding to the dmaengine API use (switching to the new API) the
> >> device/slave -> filter mapping needs to be provided to the omap-dma driver.
> >>
> >> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> > 
> > Acked-by: Aaro Koskinen <aaro.koskinen at iki.fi>
> 
> Thanks Aaro,
> 
> I believe the map covers all drivers using DMA, but in case I missed any we -
> you ;) will notice it as they will fail to get the DMA channels. This only
> going to be visible after I send the driver changes for 4.7. In such a case we
> will need to add the given device to the list.

Yeah makes sense. Applying both into omap-for-v4.6/soc thanks.

Tony


From manabian at gmail.com  Mon Feb 22 10:03:02 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Mon, 22 Feb 2016 19:03:02 +0100
Subject: [PATCH v2 2/5] watchdog: pnx4008: add restart handler
In-Reply-To: <1456160143-26761-3-git-send-email-slemieux.tyco@gmail.com>
References: <1456160143-26761-1-git-send-email-slemieux.tyco@gmail.com>
 <1456160143-26761-3-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <CAGhQ9Vz-6seRXQzcrfR-jS2GdYYac3ERz6wAiMZENq+ECHFzSw@mail.gmail.com>

Hi Sylvain,

On 22 February 2016 at 17:55,  <slemieux.tyco at gmail.com> wrote:
> From: Sylvain Lemieux <slemieux at tycoint.com>
>
> Add restart handler capability to the driver;
> the restart handler implementation was taken from
> "mach-lpc32xx" ("lpc23xx_restart" function).

I think it would be better if you were to expand on "watchdog: core:
add restart handler support" to give you the parameters you need to
make the restart hook work for you. But that is up to watchdog
maintainers to decide.

> Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
> ---
> Changes from v1 to v2:
> - new patch in v2.
>
>  drivers/watchdog/pnx4008_wdt.c | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
>
> diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
> index 88264a2..4b01b2b 100644
> --- a/drivers/watchdog/pnx4008_wdt.c
> +++ b/drivers/watchdog/pnx4008_wdt.c
> @@ -31,7 +31,10 @@
>  #include <linux/slab.h>
>  #include <linux/err.h>
>  #include <linux/of.h>
> +#include <linux/delay.h>
> +#include <linux/reboot.h>
>  #include <mach/hardware.h>
> +#include <mach/platform.h>

What are you using from mach/platform.h?

>
>  /* WatchDog Timer - Chapter 23 Page 207 */
>
> @@ -77,6 +80,7 @@
>
>  static bool nowayout = WATCHDOG_NOWAYOUT;
>  static unsigned int heartbeat = DEFAULT_HEARTBEAT;
> +static struct notifier_block restart_handler;
>
>  static DEFINE_SPINLOCK(io_lock);
>  static void __iomem    *wdt_base;
> @@ -124,6 +128,27 @@ static int pnx4008_wdt_set_timeout(struct watchdog_device *wdd,
>         return 0;
>  }
>
> +static void pnx4008_wdt_sys_reset(enum reboot_mode mode, const char *cmd)
> +{
> +       /* Make sure WDT clocks are enabled */
> +       writel(LPC32XX_CLKPWR_PWMCLK_WDOG_EN, LPC32XX_CLKPWR_TIMER_CLK_CTRL);

Doesn't the watchdog driver already enable this clock in probe?
Either way doing a direct write to LPC32XX_CLKPWR_TIMER_CLK_CTRL from
here isn't very nice.


> +       /* Instant assert of RESETOUT_N with pulse length 1mS */
> +       writel(13000, WDTIM_PULSE(wdt_base));
> +       writel(M_RES2 | RESFRC1 | RESFRC2, WDTIM_MCTRL(wdt_base));
> +
> +       /* Wait for watchdog to reset system */
> +       mdelay(1000);
> +}
> +
> +static int pnx4008_restart_handler(struct notifier_block *this,
> +                                  unsigned long mode, void *cmd)
> +{
> +       pnx4008_wdt_sys_reset((enum reboot_mode)mode, cmd);

Why can you just the stuff from pnx4008_wdt_sys_reset() in this function?


> +
> +       return NOTIFY_DONE;
> +}
> +
>  static const struct watchdog_info pnx4008_wdt_ident = {
>         .options = WDIOF_CARDRESET | WDIOF_MAGICCLOSE |
>             WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
> @@ -157,6 +182,11 @@ static int pnx4008_wdt_probe(struct platform_device *pdev)
>         if (IS_ERR(wdt_base))
>                 return PTR_ERR(wdt_base);
>
> +       /* Register restart handler. */
> +       restart_handler.notifier_call = pnx4008_restart_handler;
> +       restart_handler.priority = 128;
> +       ret = register_restart_handler(&restart_handler);

Checking return value would be a nice thing to do.

You should also do a unregister_restart_handler() in driver remove hook.


regards,
Joachim Eastwood


From computersforpeace at gmail.com  Mon Feb 22 10:04:01 2016
From: computersforpeace at gmail.com (Brian Norris)
Date: Mon, 22 Feb 2016 10:04:01 -0800
Subject: [PATCH] ARM: tegra: add "jedec,spi-nor" flash compatible binding
In-Reply-To: <1439705605-9127-1-git-send-email-zajec5@gmail.com>
References: <1439705605-9127-1-git-send-email-zajec5@gmail.com>
Message-ID: <20160222180401.GA115735@google.com>

On Sun, Aug 16, 2015 at 08:13:25AM +0200, Rafa? Mi?ecki wrote:
> Starting with commit 8947e396a829 ("Documentation: dt: mtd: replace
> "nor-jedec" binding with "jedec, spi-nor"") we have "jedec,spi-nor"
> binding indicating support for JEDEC identification.
> 
> Use it for all flashes that are supposed to support READ ID op according
> to the datasheets.
> 
> Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
> ---
>  arch/arm/boot/dts/tegra114-dalmore.dts    | 2 +-
>  arch/arm/boot/dts/tegra124-jetson-tk1.dts | 2 +-
>  arch/arm/boot/dts/tegra124-nyan.dtsi      | 2 +-
>  arch/arm/boot/dts/tegra124-venice2.dts    | 2 +-
>  arch/arm/boot/dts/tegra20-trimslice.dts   | 2 +-
>  arch/arm/boot/dts/tegra30-beaver.dts      | 2 +-
>  arch/arm/boot/dts/tegra30-cardhu.dtsi     | 2 +-
>  7 files changed, 7 insertions(+), 7 deletions(-)

FWIW:

Acked-by: Brian Norris <computersforpeace at gmail.com>


From tony at atomide.com  Mon Feb 22 10:11:29 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 10:11:29 -0800
Subject: [PATCH 0/3] ARM: omap2plus_defconfig: Enable OMAP3 ISP and
 dependencies
In-Reply-To: <1454953983-8894-1-git-send-email-javier@osg.samsung.com>
References: <1454953983-8894-1-git-send-email-javier@osg.samsung.com>
Message-ID: <20160222181128.GM13417@atomide.com>

* Javier Martinez Canillas <javier at osg.samsung.com> [160208 09:54]:
> Hello,
> 
> This small series enables all the Kconfig symbols needed to test the
> OMAP3 ISP on the IGEPv2 board. I've enabled as much as possible as a
> module and only as built-in the options that are boolean.

Looks good to me thanks, applying into omap-for-v4.6/defconfig.

Tony


From tony at atomide.com  Mon Feb 22 10:13:54 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 10:13:54 -0800
Subject: [PATCH 2/2] ARM: omap2plus_defconfig: Enable AT24 eeprom
In-Reply-To: <1456159868-32416-3-git-send-email-nm@ti.com>
References: <1456159868-32416-1-git-send-email-nm@ti.com>
 <1456159868-32416-3-git-send-email-nm@ti.com>
Message-ID: <20160222181354.GN13417@atomide.com>

* Nishanth Menon <nm at ti.com> [160222 08:51]:
> AT24 compatible eeproms are used in BB family and X15 boards.
> 
> Signed-off-by: Nishanth Menon <nm at ti.com>
> ---
>  arch/arm/configs/omap2plus_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
> index d18d6b42fcf5..fa82f4e25d0e 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -145,6 +145,7 @@ CONFIG_BLK_DEV_RAM_SIZE=16384
>  CONFIG_SENSORS_TSL2550=m
>  CONFIG_BMP085_I2C=m
>  CONFIG_SRAM=y
> +CONFIG_EEPROM_AT24=m
>  CONFIG_SENSORS_LIS3_I2C=m
>  CONFIG_BLK_DEV_SD=y
>  CONFIG_SCSI_SCAN_ASYNC=y

Applying into omap-for-v4.6/defconfig.

Thanks,

Tony


From andre.przywara at arm.com  Mon Feb 22 10:20:47 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 22 Feb 2016 18:20:47 +0000
Subject: [PATCH v3 02/10] ARM: dts: sunxi: make PLL8 in the H3 a proper clock
In-Reply-To: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
References: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1456165255-31013-3-git-send-email-andre.przywara@arm.com>

Now that we can reuse the A31 PLL6 clock driver for clocks other then
PLL6 itself, describe the PLL8 clock properly.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 3ba65c2..d84ea9b 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -137,12 +137,12 @@
 			clock-output-names = "pll6d2";
 		};
 
-		/* dummy clock until pll6 can be reused */
-		pll8: pll8_clk {
-			#clock-cells = <0>;
-			compatible = "fixed-clock";
-			clock-frequency = <1>;
-			clock-output-names = "pll8";
+		pll8: clk at c01c20044 {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun6i-a31-pll6-clk";
+			reg = <0x01c20044 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll8", "pll8x2";
 		};
 
 		cpu: cpu_clk at 01c20050 {
@@ -243,7 +243,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20088 0x4>;
-			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
+			clocks = <&osc24M>, <&pll6 0>, <&pll8 0>;
 			clock-output-names = "mmc0",
 					     "mmc0_output",
 					     "mmc0_sample";
@@ -253,7 +253,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c2008c 0x4>;
-			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
+			clocks = <&osc24M>, <&pll6 0>, <&pll8 0>;
 			clock-output-names = "mmc1",
 					     "mmc1_output",
 					     "mmc1_sample";
@@ -263,7 +263,7 @@
 			#clock-cells = <1>;
 			compatible = "allwinner,sun4i-a10-mmc-clk";
 			reg = <0x01c20090 0x4>;
-			clocks = <&osc24M>, <&pll6 0>, <&pll8>;
+			clocks = <&osc24M>, <&pll6 0>, <&pll8 0>;
 			clock-output-names = "mmc2",
 					     "mmc2_output",
 					     "mmc2_sample";
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb 22 10:20:46 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 22 Feb 2016 18:20:46 +0000
Subject: [PATCH v3 00/10] arm64: Introduce Allwinner A64 and Pine64 support
In-Reply-To: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
References: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1456165255-31013-2-git-send-email-andre.przywara@arm.com>

Subject: [PATCH v3 01/10] clk: sunxi: allow PLL6 clock to be reused

Currently we hard-code the base name for the PLL6 clock for both the
sun4i and sun6i variants in the driver (pll6 and pll6x2, respectively).
This unfortunately denies reusing this clock for the H3 and A64 PLL8
clock, which is the same otherwise.
Remove the hard-coded name in the source code and replace it with an
appropriate index into the clock-output-names array in the DT.
This is compatible with all current device trees, since they all carry
the hard-coded base name in there.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 drivers/clk/sunxi/clk-factors.c | 3 ++-
 drivers/clk/sunxi/clk-factors.h | 1 +
 drivers/clk/sunxi/clk-sunxi.c   | 4 ++--
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi/clk-factors.c b/drivers/clk/sunxi/clk-factors.c
index ddefe96..7daf01d 100644
--- a/drivers/clk/sunxi/clk-factors.c
+++ b/drivers/clk/sunxi/clk-factors.c
@@ -202,7 +202,8 @@ struct clk *sunxi_factors_register(struct device_node *node,
 	if (data->name)
 		clk_name = data->name;
 	else
-		of_property_read_string(node, "clock-output-names", &clk_name);
+		of_property_read_string_index(node, "clock-output-names",
+					      data->name_idx, &clk_name);
 
 	factors = kzalloc(sizeof(struct clk_factors), GFP_KERNEL);
 	if (!factors)
diff --git a/drivers/clk/sunxi/clk-factors.h b/drivers/clk/sunxi/clk-factors.h
index 1e63c5b..3a7da86 100644
--- a/drivers/clk/sunxi/clk-factors.h
+++ b/drivers/clk/sunxi/clk-factors.h
@@ -36,6 +36,7 @@ struct factors_data {
 	void (*getter)(struct factors_request *req);
 	void (*recalc)(struct factors_request *req);
 	const char *name;
+	int name_idx;
 };
 
 struct clk_factors {
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 99f60ef..53f5927 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -530,14 +530,14 @@ static const struct factors_data sun4i_pll6_data __initconst = {
 	.enable = 31,
 	.table = &sun4i_pll5_config,
 	.getter = sun4i_get_pll5_factors,
-	.name = "pll6",
+	.name_idx = 2,
 };
 
 static const struct factors_data sun6i_a31_pll6_data __initconst = {
 	.enable = 31,
 	.table = &sun6i_a31_pll6_config,
 	.getter = sun6i_a31_get_pll6_factors,
-	.name = "pll6x2",
+	.name_idx = 1,
 };
 
 static const struct factors_data sun5i_a13_ahb_data __initconst = {
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb 22 10:20:45 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 22 Feb 2016 18:20:45 +0000
Subject: [PATCH v3 00/10] arm64: Introduce Allwinner A64 and Pine64 support
Message-ID: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>

Hi,

another update of the Allwinner A64 / Pine64 support series.
I added a solution for the PLL6 reuse issue (the same patch I posted
yesterday). Also I addressed the comments I got from Rob and Chen-Yu.
For a changelog see below.

This series provides initial support for the Allwinner A64 SoC,
which is based on four ARM Cortex-A53 cores implementing the ARMv8
64-bit architecture.
On top of this there is also initial support for the Pine64 board,
for which you can find more information and links in the linux-sunxi
Wiki [1].
The resulting kernel boots fine on my development samples I have
here, though the actual boot process is a bit involved at the moment.
You can find more information and a ready-to-flash image here [2].

Patch 1/10 removes the hardcoded "pll6" name for the PLL6 clock, so
it can be reused for the A64's PLL7, patch 2/10 uses that facility
for the Allwinner H3 SoC's PLL8.
Patch 3/10 enables the Allwinner/sunxi platform for the arm64
architecture, so one can select the required drivers during
configuration.
Patch 4/10 adds the pinctrl driver, which has been on the list before.
Patch 5 and 6 add a new generic driver for the bus clock gates which
relies on DT for providing the parent relationship. That makes adding
new SoCs much easier, since there should be no more kernel code
changes necessary.
Patch 7-9 add the new vendor name and the device tree files, the former
for the SoC itself, the latter for the Pine64 boards.
The final patch 10 updates defconfig, so that the generic arm64 kernel
supports the basic SoC drivers out of the box.

In the moment we support the basic peripherals like GIC, timer, clocks,
GPIOs, UARTs and (since v2) I2C.
The MMC IP block has changed a bit compared to previous SoCs, so the
existing driver is not 100% compatible. However the default delays seem
to work fine for the SD cards, so I included all the necessary bits in
here, since working MMC makes this series indefinitely more usable.
We can fix both the MMC driver and the DT in a compatible way later.

Please have a look and comment on the patches. We might want to split
the series if some patches seem too controversial for being merged
soonish, please let me know if this is the case and I am happy to
rearrange the series.

The patches are based on mripard/sunxi/for-next (since linux-next is
a bit messy atm). A working repo can be found over here[3].

Cheers,
Andre

Changelog v1 .. v2:
- Change the naming of DT nodes, identifiers and file names to include
  the wonderful Allwinner architecture prefix everywhere. You asked
  for it, you got it, enjoy!
- Drop SUNXI_MMC to be selected automatically, instead put it in the
  defconfig.
- Add a binding documentation for the new multi-bus-gates driver.
- Add a defconfig update patch.
- Lots of changes in the DTs, see the respective patches for details.

Changelog v2 .. v3:
- Reordered sunxi section in ARM64 platform config.
- Add PLL6 reuse patch and rework the .dtsi to use the existing binding.
- Drop unneeded module boilerplate for the pinctrl driver.
- Rename "owa" pin to "spdif".
- Rename pll8 to pll7 in the DT.
- Remove leading 0 in DT node address parts.
- Added Acks from Rob.

[1] http://linux-sunxi.org/Pine64
[2] https://github.com/apritzel/pine64
[3] https://github.com/apritzel/linux/commits/a64-v3

Andre Przywara (10):
  clk: sunxi: allow PLL6 clock to be reused
  ARM: dts: sunxi: make PLL8 in the H3 a proper clock
  arm64: Introduce Allwinner SoC config option
  drivers: pinctrl: add driver for Allwinner A64 SoC
  DT: clk: sunxi: add binding doc for the multi-bus-gates clock
  clk: sunxi: add generic multi-parent bus clock gates driver
  arm64: dts: add Allwinner A64 SoC .dtsi
  of: add vendor prefix for Pine64
  arm64: dts: add Pine64 support
  arm64: add defconfig options for Allwinner SoCs

 Documentation/devicetree/bindings/arm/sunxi.txt    |   1 +
 Documentation/devicetree/bindings/clock/sunxi.txt  |   7 +
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 .../devicetree/bindings/vendor-prefixes.txt        |   1 +
 arch/arm/boot/dts/sun8i-h3.dtsi                    |  18 +-
 arch/arm64/Kconfig.platforms                       |   6 +
 arch/arm64/boot/dts/Makefile                       |   1 +
 arch/arm64/boot/dts/allwinner/Makefile             |   5 +
 .../dts/allwinner/sun50i-a64-pine64-common.dtsi    |  80 +++
 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  |  59 ++
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |  58 ++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      | 624 +++++++++++++++++++++
 arch/arm64/configs/defconfig                       |   7 +
 drivers/clk/sunxi/Makefile                         |   1 +
 drivers/clk/sunxi/clk-factors.c                    |   3 +-
 drivers/clk/sunxi/clk-factors.h                    |   1 +
 drivers/clk/sunxi/clk-multi-gates.c                | 105 ++++
 drivers/clk/sunxi/clk-sunxi.c                      |   4 +-
 drivers/pinctrl/sunxi/Kconfig                      |   4 +
 drivers/pinctrl/sunxi/Makefile                     |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c         | 602 ++++++++++++++++++++
 21 files changed, 1577 insertions(+), 12 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
 create mode 100644 drivers/clk/sunxi/clk-multi-gates.c
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c

-- 
2.6.4



From andre.przywara at arm.com  Mon Feb 22 10:20:48 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 22 Feb 2016 18:20:48 +0000
Subject: [PATCH v3 03/10] arm64: Introduce Allwinner SoC config option
In-Reply-To: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
References: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1456165255-31013-4-git-send-email-andre.przywara@arm.com>

To prepare for the Allwinner A64 SoC support, introduce a config
option to allow compiling Allwinner (aka. sunxi) specific drivers
for the arm64 architecture as well.
This patch just defines the ARCH_SUNXI symbol to allow Allwinner
specific drivers to be selected during kernel configuration.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 arch/arm64/Kconfig.platforms | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f6..97f5690 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -72,6 +72,11 @@ config ARCH_SEATTLE
 config ARCH_SHMOBILE
 	bool
 
+config ARCH_SUNXI
+	bool "Allwinner sunxi 64-bit SoC Family"
+	help
+	  This enables support for Allwinner sunxi based SoCs like the A64.
+
 config ARCH_RENESAS
 	bool "Renesas SoC Platforms"
 	select ARCH_SHMOBILE
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb 22 10:20:49 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 22 Feb 2016 18:20:49 +0000
Subject: [PATCH v3 04/10] drivers: pinctrl: add driver for Allwinner A64 SoC
In-Reply-To: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
References: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1456165255-31013-5-git-send-email-andre.przywara@arm.com>

Based on the Allwinner A64 user manual and on the previous sunxi
pinctrl drivers this introduces the pin multiplex assignments for
the ARMv8 Allwinner A64 SoC.
Port A is apparently used for the fixed function DRAM controller, so
the ports start at B here (the manual mentions "n from 1 to 7", so
not starting at 0).

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
 arch/arm64/Kconfig.platforms                       |   1 +
 drivers/pinctrl/sunxi/Kconfig                      |   4 +
 drivers/pinctrl/sunxi/Makefile                     |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c         | 602 +++++++++++++++++++++
 5 files changed, 609 insertions(+)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c

diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index 9213b27..08b2361 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -21,6 +21,7 @@ Required properties:
   "allwinner,sun9i-a80-r-pinctrl"
   "allwinner,sun8i-a83t-pinctrl"
   "allwinner,sun8i-h3-pinctrl"
+  "allwinner,sun50i-a64-pinctrl"
 
 - reg: Should contain the register physical address and length for the
   pin controller.
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 97f5690..63a690d 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -74,6 +74,7 @@ config ARCH_SHMOBILE
 
 config ARCH_SUNXI
 	bool "Allwinner sunxi 64-bit SoC Family"
+	select PINCTRL_SUN50I_A64
 	help
 	  This enables support for Allwinner sunxi based SoCs like the A64.
 
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index f8dbc8b..c1f970f 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -64,4 +64,8 @@ config PINCTRL_SUN9I_A80_R
 	depends on RESET_CONTROLLER
 	select PINCTRL_SUNXI_COMMON
 
+config PINCTRL_SUN50I_A64
+	bool
+	select PINCTRL_SUNXI_COMMON
+
 endif
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index ef82f22..0ca7681 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_PINCTRL_SUN7I_A20)		+= pinctrl-sun7i-a20.o
 obj-$(CONFIG_PINCTRL_SUN8I_A23)		+= pinctrl-sun8i-a23.o
 obj-$(CONFIG_PINCTRL_SUN8I_A23_R)	+= pinctrl-sun8i-a23-r.o
 obj-$(CONFIG_PINCTRL_SUN8I_A33)		+= pinctrl-sun8i-a33.o
+obj-$(CONFIG_PINCTRL_SUN50I_A64)	+= pinctrl-sun50i-a64.o
 obj-$(CONFIG_PINCTRL_SUN8I_A83T)	+= pinctrl-sun8i-a83t.o
 obj-$(CONFIG_PINCTRL_SUN8I_H3)		+= pinctrl-sun8i-h3.o
 obj-$(CONFIG_PINCTRL_SUN9I_A80)		+= pinctrl-sun9i-a80.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c
new file mode 100644
index 0000000..a53cc23
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c
@@ -0,0 +1,602 @@
+/*
+ * Allwinner A64 SoCs pinctrl driver.
+ *
+ * Copyright (C) 2016 - ARM Ltd.
+ * Author: Andre Przywara <andre.przywara at arm.com>
+ *
+ * Based on pinctrl-sun7i-a20.c, which is:
+ * Copyright (C) 2014 Maxime Ripard <maxime.ripard at free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/pinctrl.h>
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin a64_pins[] = {
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* TX */
+		  SUNXI_FUNCTION(0x4, "jtag"),		/* MS0 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),	/* EINT0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* RX */
+		  SUNXI_FUNCTION(0x4, "jtag"),		/* CK0 */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* VCCEN */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),		/* EINT1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* RTS */
+		  SUNXI_FUNCTION(0x4, "jtag"),		/* DO0 */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* VPPEN */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),		/* EINT2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart2"),		/* CTS */
+		  SUNXI_FUNCTION(0x3, "i2s0"),		/* MCLK */
+		  SUNXI_FUNCTION(0x4, "jtag"),		/* DI0 */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* VPPPP */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),		/* EINT3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif2"),		/* SYNC */
+		  SUNXI_FUNCTION(0x3, "i2s0"),		/* SYNC */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* CLK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),		/* EINT4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif2"),		/* BCLK */
+		  SUNXI_FUNCTION(0x3, "i2s0"),		/* BCLK */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* DATA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),		/* EINT5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif2"),		/* DOUT */
+		  SUNXI_FUNCTION(0x3, "i2s0"),		/* DOUT */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* RST */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),		/* EINT6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif2"),		/* DIN */
+		  SUNXI_FUNCTION(0x3, "i2s0"),		/* DIN */
+		  SUNXI_FUNCTION(0x5, "sim"),		/* DET */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),		/* EINT7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x4, "uart0"),		/* TX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),		/* EINT8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x4, "uart0"),		/* RX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),		/* EINT9 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NWE */
+		  SUNXI_FUNCTION(0x4, "spi0")),		/* MOSI */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NALE */
+		  SUNXI_FUNCTION(0x3, "mmc2"),		/* DS */
+		  SUNXI_FUNCTION(0x4, "spi0")),		/* MISO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCLE */
+		  SUNXI_FUNCTION(0x4, "spi0")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NCE1 */
+		  SUNXI_FUNCTION(0x4, "spi0")),		/* CS */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NCE0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NRE# */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NRB0 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* CMD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0")),	/* NRB1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ0 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ1 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ2 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ3 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ4 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ5 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ6 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQ7 */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 16),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "nand0"),		/* NDQS */
+		  SUNXI_FUNCTION(0x3, "mmc2")),		/* RST */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D2 */
+		  SUNXI_FUNCTION(0x3, "uart3"),		/* TX */
+		  SUNXI_FUNCTION(0x4, "spi1"),		/* CS */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D3 */
+		  SUNXI_FUNCTION(0x3, "uart3"),		/* RX */
+		  SUNXI_FUNCTION(0x4, "spi1"),		/* CLK */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* DE */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D4 */
+		  SUNXI_FUNCTION(0x3, "uart4"),		/* TX */
+		  SUNXI_FUNCTION(0x4, "spi1"),		/* MOSI */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* HSYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D5 */
+		  SUNXI_FUNCTION(0x3, "uart4"),		/* RX */
+		  SUNXI_FUNCTION(0x4, "spi1"),		/* MISO */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* VSYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D6 */
+		  SUNXI_FUNCTION(0x3, "uart4"),		/* RTS */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D7 */
+		  SUNXI_FUNCTION(0x3, "uart4"),		/* CTS */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D10 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D11 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D12 */
+		  SUNXI_FUNCTION(0x4, "emac"),		/* ERXD3 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D13 */
+		  SUNXI_FUNCTION(0x4, "emac"),		/* ERXD2 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D14 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ERXD1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D15 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ERXD0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D18 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VP0 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ERXCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D19 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VN0 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ERXCTL */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 14),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D20 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VP1 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ENULL */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 15),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D21 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VN1 */
+		  SUNXI_FUNCTION(0x4, "emac"),		/* ETXD3 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 16),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D22 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VP2 */
+		  SUNXI_FUNCTION(0x4, "emac"),		/* ETXD2 */
+		  SUNXI_FUNCTION(0x5, "ccir")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 17),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* D23 */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VN2 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ETXD1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 18),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VPC */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ETXD0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 19),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* DE */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VNC */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ETXCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 20),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* HSYNC */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VP3 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ETXCTL */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 21),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "lcd0"),		/* VSYNC */
+		  SUNXI_FUNCTION(0x3, "lvds0"),		/* VN3 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* ECLKIN */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 22),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "pwm"),		/* PWM0 */
+		  SUNXI_FUNCTION(0x4, "emac")),		/* EMDC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 23),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x4, "emac")),		/* EMDIO */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 24),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* PCK */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* CLK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* CK */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* ERR */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* HSYNC */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* SYNC */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* VSYNC */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* DVLD */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D0 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D1 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D2 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D3 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D4 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D5 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D6 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0"),		/* D7 */
+		  SUNXI_FUNCTION(0x4, "ts0")),		/* D7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "csi0")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 14),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "pll"),		/* LOCK_DBG */
+		  SUNXI_FUNCTION(0x3, "i2c2")),		/* SCK */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 15),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x3, "i2c2")),		/* SDA */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 16),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 17),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D1 */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* MSI */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D0 */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* DI1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* CLK */
+		  SUNXI_FUNCTION(0x3, "uart0")),	/* TX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* CMD */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* DO1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D3 */
+		  SUNXI_FUNCTION(0x4, "uart0")),	/* RX */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc0"),		/* D2 */
+		  SUNXI_FUNCTION(0x3, "jtag")),		/* CK1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out")),
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* CLK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 0)),	/* EINT0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* CMD */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 1)),	/* EINT1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D0 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 2)),	/* EINT2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D1 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 3)),	/* EINT3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D2 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 4)),	/* EINT4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mmc1"),		/* D3 */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 5)),	/* EINT5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart1"),		/* TX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 6)),	/* EINT6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart1"),		/* RX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 7)),	/* EINT7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart1"),		/* RTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 8)),	/* EINT8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart1"),		/* CTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 9)),	/* EINT9 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif3"),		/* SYNC */
+		  SUNXI_FUNCTION(0x3, "i2s1"),		/* SYNC */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 10)),	/* EINT10 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif3"),		/* BCLK */
+		  SUNXI_FUNCTION(0x3, "i2s1"),		/* BCLK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 11)),	/* EINT11 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 12),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif3"),		/* DOUT */
+		  SUNXI_FUNCTION(0x3, "i2s1"),		/* DOUT */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 12)),	/* EINT12 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 13),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "aif3"),		/* DIN */
+		  SUNXI_FUNCTION(0x3, "i2s1"),		/* DIN */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 13)),	/* EINT13 */
+	/* Hole */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 0),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c0"),		/* SCK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 0)),	/* EINT0 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 1),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c0"),		/* SDA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 1)),	/* EINT1 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 2),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c1"),		/* SCK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 2)),	/* EINT2 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 3),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "i2c1"),		/* SDA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 3)),	/* EINT3 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 4),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart3"),		/* TX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 4)),	/* EINT4 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 5),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart3"),		/* RX */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 5)),	/* EINT5 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 6),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart3"),		/* RTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 6)),	/* EINT6 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 7),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "uart3"),		/* CTS */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 7)),	/* EINT7 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 8),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "spdif"),		/* OUT */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 8)),	/* EINT8 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 9),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 9)),	/* EINT9 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 10),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mic"),		/* CLK */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 10)),	/* EINT10 */
+	SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 11),
+		  SUNXI_FUNCTION(0x0, "gpio_in"),
+		  SUNXI_FUNCTION(0x1, "gpio_out"),
+		  SUNXI_FUNCTION(0x2, "mic"),		/* DATA */
+		  SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 11)),	/* EINT11 */
+};
+
+static const struct sunxi_pinctrl_desc a64_pinctrl_data = {
+	.pins = a64_pins,
+	.npins = ARRAY_SIZE(a64_pins),
+	.irq_banks = 3,
+};
+
+static int a64_pinctrl_probe(struct platform_device *pdev)
+{
+	return sunxi_pinctrl_init(pdev,
+				  &a64_pinctrl_data);
+}
+
+static const struct of_device_id a64_pinctrl_match[] = {
+	{ .compatible = "allwinner,sun50i-a64-pinctrl", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, a64_pinctrl_match);
+
+static struct platform_driver a64_pinctrl_driver = {
+	.probe	= a64_pinctrl_probe,
+	.driver	= {
+		.name		= "sun50i-a64-pinctrl",
+		.of_match_table	= a64_pinctrl_match,
+	},
+};
+builtin_platform_driver(a64_pinctrl_driver);
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb 22 10:20:53 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 22 Feb 2016 18:20:53 +0000
Subject: [PATCH v3 08/10] of: add vendor prefix for Pine64
In-Reply-To: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
References: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1456165255-31013-9-git-send-email-andre.przywara@arm.com>

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 72e2c5a..0c22fa9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -175,6 +175,7 @@ parade	Parade Technologies Inc.
 pericom	Pericom Technology Inc.
 phytec	PHYTEC Messtechnik GmbH
 picochip	Picochip Ltd
+pine64	Pine64
 plathome	Plat'Home Co., Ltd.
 plda	PLDA
 pixcir  PIXCIR MICROELECTRONICS Co., Ltd
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb 22 10:20:50 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 22 Feb 2016 18:20:50 +0000
Subject: [PATCH v3 05/10] DT: clk: sunxi: add binding doc for the
 multi-bus-gates clock
In-Reply-To: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
References: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1456165255-31013-6-git-send-email-andre.przywara@arm.com>

Recent Allwinner SoCs introduced a bus gates clock which can have
different parents for individual gates.
For the time being we encoded this relation in the driver.
This commit specifies a new binding which allows to encode this in
the DT by using a child node for each parent clock used. This allows
to specify any kind of relation efficiently and also keeps the very
same kernel driver for all SoCs at the same time.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 Documentation/devicetree/bindings/clock/sunxi.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index c09f59b..323af8e 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -79,6 +79,7 @@ Required properties:
 	"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
 	"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
 	"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
+	"allwinner,sunxi-multi-bus-gates-clk" - for the multi-parent bus gates
 
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
@@ -119,6 +120,11 @@ For "allwinner,sun6i-a31-pll6-clk", there are 2 outputs. The first output
 is the normal PLL6 output, or "pll6". The second output is rate doubled
 PLL6, or "pll6x2".
 
+The "allwinner,sunxi-multi-bus-gates-clk" holds the actual clocks in
+child nodes, where each one specifies the parent clock that the particular
+gates are depending from. The child nodes each follow the common clock
+binding as described in this document.
+
 The "allwinner,*-mmc-clk" clocks have three different outputs: the
 main clock, with the ID 0, and the output and sample clocks, with the
 IDs 1 and 2, respectively.
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb 22 10:20:55 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 22 Feb 2016 18:20:55 +0000
Subject: [PATCH v3 10/10] arm64: add defconfig options for Allwinner SoCs
In-Reply-To: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
References: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1456165255-31013-11-git-send-email-andre.przywara@arm.com>

With the Allwinner platform now supported, enable it in the defconfig
and add some options to give some decent out-of-the-box experience on
those SoCs.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 arch/arm64/configs/defconfig | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 18ca9fb..7acadce 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -31,6 +31,7 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_ARCH_SUNXI=y
 CONFIG_ARCH_BCM_IPROC=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_ARCH_EXYNOS7=y
@@ -135,12 +136,15 @@ CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
 CONFIG_VIRTIO_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
 CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_MV64XXX=y
 CONFIG_I2C_QUP=y
 CONFIG_I2C_RCAR=y
 CONFIG_SPI=y
 CONFIG_SPI_PL022=y
 CONFIG_SPI_QUP=y
 CONFIG_PINCTRL_MSM8916=y
+CONFIG_GPIO_SYSFS=y
 CONFIG_GPIO_PL061=y
 CONFIG_GPIO_RCAR=y
 CONFIG_GPIO_XGENE=y
@@ -175,10 +179,12 @@ CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_SDHCI_TEGRA=y
 CONFIG_MMC_SPI=y
+CONFIG_MMC_SUNXI=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_IDMAC=y
 CONFIG_MMC_DW_PLTFM=y
 CONFIG_MMC_DW_EXYNOS=y
+CONFIG_MMC_BLOCK_MINORS=16
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_SYSCON=y
@@ -187,6 +193,7 @@ CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_LEDS_TRIGGER_CPU=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_EFI=y
+CONFIG_RTC_DRV_SUN6I=y
 CONFIG_RTC_DRV_XGENE=y
 CONFIG_DMADEVICES=y
 CONFIG_RCAR_DMAC=y
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb 22 10:20:51 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 22 Feb 2016 18:20:51 +0000
Subject: [PATCH v3 06/10] clk: sunxi: add generic multi-parent bus clock gates
 driver
In-Reply-To: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
References: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1456165255-31013-7-git-send-email-andre.przywara@arm.com>

The Allwinner H3 SoC introduced bus clock gates with potentially
different parents per clock gate. The H3 driver chose to hardcode the
actual parent clock relation in the code.
Add a new driver (which has the potential to drive the H3 and also
the simple clock gates as well) which uses the power of DT to describe
this relationship in an elegant and flexible way.
Using one subnode for every parent clock we get away with a single
DT compatible match, which can be used as a fallback value in the
actual DTs without the need to add specific compatible strings to the
code.  This avoids adding a new driver or function for every new SoC.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
Acked-by: Jean-Francois Moine <moinejf at free.fr>
---
 drivers/clk/sunxi/Makefile          |   1 +
 drivers/clk/sunxi/clk-multi-gates.c | 105 ++++++++++++++++++++++++++++++++++++
 2 files changed, 106 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk-multi-gates.c

diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 3fd7901..3a9dc31 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -11,6 +11,7 @@ obj-y += clk-a10-ve.o
 obj-y += clk-a20-gmac.o
 obj-y += clk-mod0.o
 obj-y += clk-simple-gates.o
+obj-y += clk-multi-gates.o
 obj-y += clk-sun8i-bus-gates.o
 obj-y += clk-sun8i-mbus.o
 obj-y += clk-sun9i-core.o
diff --git a/drivers/clk/sunxi/clk-multi-gates.c b/drivers/clk/sunxi/clk-multi-gates.c
new file mode 100644
index 0000000..76e715a
--- /dev/null
+++ b/drivers/clk/sunxi/clk-multi-gates.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ *
+ * Based on clk-sun8i-bus-gates.c, which is:
+ *  Copyright (C) 2015 Jens Kuske <jenskuske at gmail.com>
+ * Based on clk-simple-gates.c, which is:
+ *  Copyright 2015 Maxime Ripard <maxime.ripard at free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+
+static DEFINE_SPINLOCK(gates_lock);
+
+static void __init sunxi_parse_parent(struct device_node *node,
+				      struct clk_onecell_data *clk_data,
+				      void __iomem *reg)
+{
+	const char *parent = of_clk_get_parent_name(node, 0);
+	const char *clk_name;
+	struct property *prop;
+	struct clk *clk;
+	const __be32 *p;
+	int index, i = 0;
+
+	of_property_for_each_u32(node, "clock-indices", prop, p, index) {
+		of_property_read_string_index(node, "clock-output-names",
+					      i, &clk_name);
+
+		clk = clk_register_gate(NULL, clk_name, parent, 0,
+					reg + 4 * (index / 32), index % 32,
+					0, &gates_lock);
+		i++;
+		if (IS_ERR(clk)) {
+			pr_warn("could not register gate clock \"%s\"\n",
+				clk_name);
+			continue;
+		}
+		if (clk_data->clks[index])
+			pr_warn("bus-gate clock %s: index #%d already registered as %s\n",
+				clk_name, index, "?");
+		else
+			clk_data->clks[index] = clk;
+	}
+}
+
+static void __init sunxi_multi_bus_gates_init(struct device_node *node)
+{
+	struct clk_onecell_data *clk_data;
+	struct device_node *child;
+	struct property *prop;
+	struct resource res;
+	void __iomem *reg;
+	const __be32 *p;
+	int number = 0;
+	int index;
+
+	reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+	if (IS_ERR(reg))
+		return;
+
+	clk_data = kmalloc(sizeof(struct clk_onecell_data), GFP_KERNEL);
+	if (!clk_data)
+		goto err_unmap;
+
+	for_each_child_of_node(node, child)
+		of_property_for_each_u32(child, "clock-indices", prop, p, index)
+			number = max(number, index);
+
+	clk_data->clks = kcalloc(number + 1, sizeof(struct clk *), GFP_KERNEL);
+	if (!clk_data->clks)
+		goto err_free_data;
+
+	for_each_child_of_node(node, child)
+		sunxi_parse_parent(child, clk_data, reg);
+
+	clk_data->clk_num = number + 1;
+	if (of_clk_add_provider(node, of_clk_src_onecell_get, clk_data))
+		pr_err("registering bus-gate clock %s failed\n", node->name);
+
+	return;
+
+err_free_data:
+	kfree(clk_data);
+err_unmap:
+	iounmap(reg);
+	of_address_to_resource(node, 0, &res);
+	release_mem_region(res.start, resource_size(&res));
+}
+
+CLK_OF_DECLARE(sunxi_multi_bus_gates, "allwinner,sunxi-multi-bus-gates-clk",
+	       sunxi_multi_bus_gates_init);
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb 22 10:20:54 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 22 Feb 2016 18:20:54 +0000
Subject: [PATCH v3 09/10] arm64: dts: add Pine64 support
In-Reply-To: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
References: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1456165255-31013-10-git-send-email-andre.przywara@arm.com>

The Pine64 is a cost-efficient development board based on the
Allwinner A64 SoC.
There are three models: the basic version with Fast Ethernet and
512 MB of DRAM (Pine64) and two Pine64+ versions, which both
feature Gigabit Ethernet and additional connectors for touchscreens
and a camera. Or as my son put it: "Those are smaller and these are
missing." ;-)
The two Pine64+ models just differ in the amount of DRAM
(1GB vs. 2GB). Since U-Boot will figure out the right size for us and
patches the DT accordingly we just need to provide one DT for the
Pine64+.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
Changelog v1 .. v2:
- move aliases node into the common board DT file
- move fixed MMC regulator into the common board DT file
- drop UARTs 1-4 nodes from the default DT
- add I2C node (pins seem to be dedicated to I2C)

 arch/arm64/boot/dts/Makefile                       |  1 +
 arch/arm64/boot/dts/allwinner/Makefile             |  5 ++
 .../dts/allwinner/sun50i-a64-pine64-common.dtsi    | 80 ++++++++++++++++++++++
 .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  | 59 ++++++++++++++++
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 58 ++++++++++++++++
 5 files changed, 203 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index f832b8a..3b7428a 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,3 +1,4 @@
+dts-dirs += allwinner
 dts-dirs += altera
 dts-dirs += amd
 dts-dirs += apm
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
new file mode 100644
index 0000000..1e29a5a
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
+
+always		:= $(dtb-y)
+subdir-y	:= $(dts-dirs)
+clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi
new file mode 100644
index 0000000..d5a7249
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi
@@ -0,0 +1,80 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun50i-a64.dtsi"
+
+/ {
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	soc {
+		reg_vcc3v3: vcc3v3 {
+			compatible = "regulator-fixed";
+			regulator-name = "vcc3v3";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+		};
+	};
+};
+
+&mmc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc0_pins>, <&mmc0_default_cd_pin>;
+	vmmc-supply = <&reg_vcc3v3>;
+	cd-gpios = <&pio 5 6 0>;
+	cd-inverted;
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins_a>;
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins>;
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
new file mode 100644
index 0000000..549dc15
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
@@ -0,0 +1,59 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64-pine64-common.dtsi"
+
+/ {
+	model = "Pine64+";
+	compatible = "pine64,pine64-plus", "allwinner,sun50i-a64";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	/* There is a model with 2GB of DRAM, but U-Boot fixes this for us. */
+	memory {
+		reg = <0x40000000 0x40000000>;
+	};
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
new file mode 100644
index 0000000..ebe029e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -0,0 +1,58 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64-pine64-common.dtsi"
+
+/ {
+	model = "Pine64";
+	compatible = "pine64,pine64", "allwinner,sun50i-a64";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory {
+		reg = <0x40000000 0x20000000>;
+	};
+};
-- 
2.6.4



From andre.przywara at arm.com  Mon Feb 22 10:20:52 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Mon, 22 Feb 2016 18:20:52 +0000
Subject: [PATCH v3 07/10] arm64: dts: add Allwinner A64 SoC .dtsi
In-Reply-To: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
References: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
Message-ID: <1456165255-31013-8-git-send-email-andre.przywara@arm.com>

The Allwinner A64 SoC is a low-cost chip with 4 ARM Cortex-A53 cores
and the typical tablet / TV box peripherals.
The SoC is based on the (32-bit) Allwinner H3 chip, sharing most of
the peripherals and the memory map.
Although the cores are proper 64-bit ones, the whole SoC is actually
limited to 4GB (including all the supported DRAM), so we use 32-bit
address and size cells. This has the nice feature of us being able to
reuse the DT for 32-bit kernels as well.
This .dtsi lists the hardware that we support so far.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
Acked-by: Rob Herring <robh at kernel.org>
---
Changelog v1 .. v2:
- remove compatible string from the .dtsi
- amend compatible names to include sun50i
- drop PSCI 0.1 compatibility
- use lowercase hex digits in the GIC node too
- make pll6x2 an explicit fixed-factor clock
- make pll8 and pll8x2 proper clocks
- amend MMC clocks to match the manual, they are now mod0 clocks
- adapt MMC nodes to new MMC clocks
- add separate 4-pin and 2-pin definitions for the UARTs
- add I2C pins and driver nodes
- switch ahb_rst node to use normal compatible name, not the special,
  early-registration one.
Changelog v2 .. v3:
- remove leading zeros from node names' address part
- adapt PLL6/7/8 to proper PLL6 binding
- rename PLL6 to PLL7

 Documentation/devicetree/bindings/arm/sunxi.txt   |   1 +
 Documentation/devicetree/bindings/clock/sunxi.txt |   1 +
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi     | 624 ++++++++++++++++++++++
 3 files changed, 626 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi

diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
index 7e79fcc..7e59d8b 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -14,3 +14,4 @@ using one of the following compatible strings:
   allwinner,sun8i-a83t
   allwinner,sun8i-h3
   allwinner,sun9i-a80
+  allwinner,sun50i-a64
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index 323af8e..b7bd40d 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -80,6 +80,7 @@ Required properties:
 	"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
 	"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
 	"allwinner,sunxi-multi-bus-gates-clk" - for the multi-parent bus gates
+	"allwinner,sun50i-a64-bus-gates-clk" - for the bus gates on A64
 
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
new file mode 100644
index 0000000..fb9c509
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -0,0 +1,624 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ * based on the Allwinner H3 dtsi:
+ *    Copyright (C) 2015 Jens Kuske <jenskuske at gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+	interrupt-parent = <&gic>;
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <0>;
+			enable-method = "psci";
+		};
+
+		cpu at 1 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <1>;
+			enable-method = "psci";
+		};
+
+		cpu at 2 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <2>;
+			enable-method = "psci";
+		};
+
+		cpu at 3 {
+			compatible = "arm,cortex-a53", "arm,armv8";
+			device_type = "cpu";
+			reg = <3>;
+			enable-method = "psci";
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x40000000 0>;
+	};
+
+	gic: interrupt-controller at 1c81000 {
+		compatible = "arm,gic-400";
+		interrupt-controller;
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+
+		reg = <0x01c81000 0x1000>,
+		      <0x01c82000 0x2000>,
+		      <0x01c84000 0x2000>,
+		      <0x01c86000 0x2000>;
+		interrupts = <GIC_PPI 9
+		      (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10
+			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		osc24M: osc24M_clk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <24000000>;
+			clock-output-names = "osc24M";
+		};
+
+		osc32k: osc32k_clk {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <32768>;
+			clock-output-names = "osc32k";
+		};
+
+		pll1: pll1_clk at 1c20000 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun8i-a23-pll1-clk";
+			reg = <0x01c20000 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll1";
+		};
+
+		pll6: pll6_clk at 1c20028 {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun6i-a31-pll6-clk";
+			reg = <0x01c20028 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll6", "pll6x2";
+		};
+
+		pll6d2: pll6d2_clk {
+			#clock-cells = <0>;
+			compatible = "fixed-factor-clock";
+			clock-div = <2>;
+			clock-mult = <1>;
+			clocks = <&pll6 0>;
+			clock-output-names = "pll6d2";
+		};
+
+		pll7: pll7_clk at 1c2002c {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun6i-a31-pll6-clk";
+			reg = <0x01c2002c 0x4>;
+			clocks = <&osc24M>;
+			clock-output-names = "pll7", "pll7x2";
+		};
+
+		cpu: cpu_clk at 1c20050 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-cpu-clk";
+			reg = <0x01c20050 0x4>;
+			clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
+			clock-output-names = "cpu";
+			critical-clocks = <0>;
+		};
+
+		axi: axi_clk at 1c20050 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-axi-clk";
+			reg = <0x01c20050 0x4>;
+			clocks = <&cpu>;
+			clock-output-names = "axi";
+		};
+
+		ahb1: ahb1_clk at 1c20054 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun6i-a31-ahb1-clk";
+			reg = <0x01c20054 0x4>;
+			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
+			clock-output-names = "ahb1";
+		};
+
+		ahb2: ahb2_clk at 1c2005c {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun8i-h3-ahb2-clk";
+			reg = <0x01c2005c 0x4>;
+			clocks = <&ahb1>, <&pll6d2>;
+			clock-output-names = "ahb2";
+		};
+
+		apb1: apb1_clk at 1c20054 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-apb0-clk";
+			reg = <0x01c20054 0x4>;
+			clocks = <&ahb1>;
+			clock-output-names = "apb1";
+		};
+
+		apb2: apb2_clk at 1c20058 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-apb1-clk";
+			reg = <0x01c20058 0x4>;
+			clocks = <&osc32k>, <&osc24M>, <&pll6 1>, <&pll6 1>;
+			clock-output-names = "apb2";
+		};
+
+		bus_gates: bus_gates_clk at 1c20060 {
+			#clock-cells = <1>;
+			compatible = "allwinner,sun50i-a64-bus-gates-clk",
+				     "allwinner,sunxi-multi-bus-gates-clk";
+			reg = <0x01c20060 0x14>;
+			ahb1_parent {
+				clocks = <&ahb1>;
+				clock-indices = <1>, <5>,
+						<6>, <8>,
+						<9>, <10>,
+						<13>, <14>,
+						<18>, <19>,
+						<20>, <21>,
+						<23>, <24>,
+						<25>, <28>,
+						<32>, <35>,
+						<36>, <37>,
+						<40>, <43>,
+						<44>, <52>,
+						<53>, <54>,
+						<135>;
+				clock-output-names = "bus_mipidsi", "bus_ce",
+						"bus_dma", "bus_mmc0",
+						"bus_mmc1", "bus_mmc2",
+						"bus_nand", "bus_sdram",
+						"bus_ts", "bus_hstimer",
+						"bus_spi0", "bus_spi1",
+						"bus_otg", "bus_otg_ehci0",
+						"bus_ehci0", "bus_otg_ohci0",
+						"bus_ve", "bus_lcd0",
+						"bus_lcd1", "bus_deint",
+						"bus_csi", "bus_hdmi",
+						"bus_de", "bus_gpu",
+						"bus_msgbox", "bus_spinlock",
+						"bus_dbg";
+			};
+			ahb2_parent {
+				clocks = <&ahb2>;
+				clock-indices = <17>, <29>;
+				clock-output-names = "bus_gmac", "bus_ohci0";
+			};
+			apb1_parent {
+				clocks = <&apb1>;
+				clock-indices = <64>, <65>,
+						<69>, <72>,
+						<76>, <77>,
+						<78>;
+				clock-output-names = "bus_codec", "bus_spdif",
+						"bus_pio", "bus_ths",
+						"bus_i2s0", "bus_i2s1",
+						"bus_i2s2";
+			};
+			abp2_parent {
+				clocks = <&apb2>;
+				clock-indices = <96>, <97>,
+						<98>, <101>,
+						<112>, <113>,
+						<114>, <115>,
+						<116>;
+				clock-output-names = "bus_i2c0", "bus_i2c1",
+						"bus_i2c2", "bus_scr",
+						"bus_uart0", "bus_uart1",
+						"bus_uart2", "bus_uart3",
+						"bus_uart4";
+			};
+		};
+
+		mmc0_clk: mmc0_clk at 1c20088 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-mod0-clk";
+			reg = <0x01c20088 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll7 1>;
+			clock-output-names = "mmc0";
+                };
+
+		mmc1_clk: mmc1_clk at 1c2008c {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-mod0-clk";
+			reg = <0x01c2008c 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll7 1>;
+			clock-output-names = "mmc1";
+		};
+
+		mmc2_clk: mmc2_clk at 1c20090 {
+			#clock-cells = <0>;
+			compatible = "allwinner,sun4i-a10-mod0-clk";
+			reg = <0x01c20090 0x4>;
+			clocks = <&osc24M>, <&pll6 1>, <&pll7 1>;
+			clock-output-names = "mmc2";
+		};
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		mmc0: mmc at 1c0f000 {
+			compatible = "allwinner,sun50i-a64-mmc",
+				     "allwinner,sun5i-a13-mmc";
+			reg = <0x01c0f000 0x1000>;
+			clocks = <&bus_gates 8>, <&mmc0_clk>,
+				 <&mmc0_clk>, <&mmc0_clk>;
+			clock-names = "ahb", "mmc",
+				      "output", "sample";
+			resets = <&ahb_rst 8>;
+			reset-names = "ahb";
+			interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mmc1: mmc at 1c10000 {
+			compatible = "allwinner,sun50i-a64-mmc",
+				     "allwinner,sun5i-a13-mmc";
+			reg = <0x01c10000 0x1000>;
+			clocks = <&bus_gates 9>, <&mmc1_clk>,
+				 <&mmc1_clk>, <&mmc1_clk>;
+			clock-names = "ahb", "mmc",
+				      "output", "sample";
+			resets = <&ahb_rst 9>;
+			reset-names = "ahb";
+			interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mmc2: mmc at 1c11000 {
+			compatible = "allwinner,sun50i-a64-mmc",
+				     "allwinner,sun5i-a13-mmc";
+			reg = <0x01c11000 0x1000>;
+			clocks = <&bus_gates 10>, <&mmc2_clk>,
+				 <&mmc2_clk>, <&mmc2_clk>;
+			clock-names = "ahb", "mmc",
+				      "output", "sample";
+			resets = <&ahb_rst 10>;
+			reset-names = "ahb";
+			interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		pio: pinctrl at 1c20800 {
+			compatible = "allwinner,sun50i-a64-pinctrl";
+			reg = <0x01c20800 0x400>;
+			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&bus_gates 69>;
+			gpio-controller;
+			#gpio-cells = <3>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+
+			uart0_pins_a: uart0 at 0 {
+				allwinner,pins = "PB8", "PB9";
+				allwinner,function = "uart0";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart0_pins_b: uart0 at 1 {
+				allwinner,pins = "PF2", "PF3";
+				allwinner,function = "uart0";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart1_2pins: uart1_2 at 0 {
+				allwinner,pins = "PG6", "PG7";
+				allwinner,function = "uart1";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart1_4pins: uart1_4 at 0 {
+				allwinner,pins = "PG6", "PG7", "PG8", "PG9";
+				allwinner,function = "uart1";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart2_2pins: uart2_2 at 0 {
+				allwinner,pins = "PB0", "PB1";
+				allwinner,function = "uart2";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart2_4pins: uart2_4 at 0 {
+				allwinner,pins = "PB0", "PB1", "PB2", "PB3";
+				allwinner,function = "uart2";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart3_pins_a: uart3 at 0 {
+				allwinner,pins = "PD0", "PD1";
+				allwinner,function = "uart3";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart3_2pins_b: uart3_2 at 1 {
+				allwinner,pins = "PH4", "PH5";
+				allwinner,function = "uart3";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart3_4pins_b: uart3_4 at 1 {
+				allwinner,pins = "PH4", "PH5", "PH6", "PH7";
+				allwinner,function = "uart3";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart4_2pins: uart4_2 at 0 {
+				allwinner,pins = "PD2", "PD3";
+				allwinner,function = "uart4";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			uart4_4pins: uart4_4 at 0 {
+				allwinner,pins = "PD2", "PD3", "PD4", "PD5";
+				allwinner,function = "uart4";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			mmc0_pins: mmc0 at 0 {
+				allwinner,pins = "PF0", "PF1", "PF2", "PF3",
+						 "PF4", "PF5";
+				allwinner,function = "mmc0";
+				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			mmc0_default_cd_pin: mmc0_cd_pin at 0 {
+				allwinner,pins = "PF6";
+				allwinner,function = "gpio_in";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+			};
+
+			mmc1_pins: mmc1 at 0 {
+				allwinner,pins = "PG0", "PG1", "PG2", "PG3",
+						 "PG4", "PG5";
+				allwinner,function = "mmc1";
+				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			mmc2_pins: mmc2 at 0 {
+				allwinner,pins = "PC1", "PC5", "PC6", "PC8",
+						 "PC9", "PC10";
+				allwinner,function = "mmc2";
+				allwinner,drive = <SUN4I_PINCTRL_30_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			i2c0_pins: i2c0_pins {
+				allwinner,pins = "PH0", "PH1";
+				allwinner,function = "i2c0";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			i2c1_pins: i2c1_pins {
+				allwinner,pins = "PH2", "PH3";
+				allwinner,function = "i2c1";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+
+			i2c2_pins: i2c2_pins {
+				allwinner,pins = "PE14", "PE15";
+				allwinner,function = "i2c2";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
+		};
+
+		ahb_rst: reset at 1c202c0 {
+			#reset-cells = <1>;
+			compatible = "allwinner,sun6i-a31-clock-reset";
+			reg = <0x01c202c0 0xc>;
+		};
+
+		apb1_rst: reset at 1c202d0 {
+			#reset-cells = <1>;
+			compatible = "allwinner,sun6i-a31-clock-reset";
+			reg = <0x01c202d0 0x4>;
+		};
+
+		apb2_rst: reset at 1c202d8 {
+			#reset-cells = <1>;
+			compatible = "allwinner,sun6i-a31-clock-reset";
+			reg = <0x01c202d8 0x4>;
+		};
+
+		uart0: serial at 1c28000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28000 0x400>;
+			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&bus_gates 112>;
+			resets = <&apb2_rst 16>;
+			status = "disabled";
+		};
+
+		uart1: serial at 1c28400 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28400 0x400>;
+			interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&bus_gates 113>;
+			resets = <&apb2_rst 17>;
+			status = "disabled";
+		};
+
+		uart2: serial at 1c28800 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28800 0x400>;
+			interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&bus_gates 114>;
+			resets = <&apb2_rst 18>;
+			status = "disabled";
+		};
+
+		uart3: serial at 1c28c00 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c28c00 0x400>;
+			interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&bus_gates 115>;
+			resets = <&apb2_rst 19>;
+			status = "disabled";
+		};
+
+		uart4: serial at 1c29000 {
+			compatible = "snps,dw-apb-uart";
+			reg = <0x01c29000 0x400>;
+			interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			clocks = <&bus_gates 116>;
+			resets = <&apb2_rst 20>;
+			status = "disabled";
+		};
+
+		rtc: rtc at 1f00000 {
+			compatible = "allwinner,sun6i-a31-rtc";
+			reg = <0x01f00000 0x54>;
+			interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		i2c0: i2c at 1c2ac00 {
+			compatible = "allwinner,sun6i-a31-i2c";
+			reg = <0x01c2ac00 0x400>;
+			interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&bus_gates 96>;
+			resets = <&apb2_rst 0>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c1: i2c at 1c2b000 {
+			compatible = "allwinner,sun6i-a31-i2c";
+			reg = <0x01c2b000 0x400>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&bus_gates 97>;
+			resets = <&apb2_rst 1>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		i2c2: i2c at 1c2b400 {
+			compatible = "allwinner,sun6i-a31-i2c";
+			reg = <0x01c2b400 0x400>;
+			interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&bus_gates 98>;
+			resets = <&apb2_rst 2>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+};
-- 
2.6.4



From slemieux.tyco at gmail.com  Mon Feb 22 10:25:26 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Mon, 22 Feb 2016 13:25:26 -0500
Subject: [PATCH v2 2/5] watchdog: pnx4008: add restart handler
In-Reply-To: <CAGhQ9Vz-6seRXQzcrfR-jS2GdYYac3ERz6wAiMZENq+ECHFzSw@mail.gmail.com>
References: <1456160143-26761-1-git-send-email-slemieux.tyco@gmail.com>
 <1456160143-26761-3-git-send-email-slemieux.tyco@gmail.com>
 <CAGhQ9Vz-6seRXQzcrfR-jS2GdYYac3ERz6wAiMZENq+ECHFzSw@mail.gmail.com>
Message-ID: <1456165526.28348.9.camel@localhost>

On Mon, 2016-02-22 at 19:03 +0100, Joachim Eastwood wrote:
> Hi Sylvain,
> 
> On 22 February 2016 at 17:55,  <slemieux.tyco at gmail.com> wrote:
> > From: Sylvain Lemieux <slemieux at tycoint.com>
> >
> > Add restart handler capability to the driver;
> > the restart handler implementation was taken from
> > "mach-lpc32xx" ("lpc23xx_restart" function).
> 
> I think it would be better if you were to expand on "watchdog: core:
> add restart handler support" to give you the parameters you need to
> make the restart hook work for you. But that is up to watchdog
> maintainers to decide.

I prefer to do this as a separate patchset;
I will wait for the watchdog maintainer feedback on this.

> 
> > Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
> > ---
> > Changes from v1 to v2:
> > - new patch in v2.
> >
> >  drivers/watchdog/pnx4008_wdt.c | 30 ++++++++++++++++++++++++++++++
> >  1 file changed, 30 insertions(+)
> >
> > diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
> > index 88264a2..4b01b2b 100644
> > --- a/drivers/watchdog/pnx4008_wdt.c
> > +++ b/drivers/watchdog/pnx4008_wdt.c
> > @@ -31,7 +31,10 @@
> >  #include <linux/slab.h>
> >  #include <linux/err.h>
> >  #include <linux/of.h>
> > +#include <linux/delay.h>
> > +#include <linux/reboot.h>
> >  #include <mach/hardware.h>
> > +#include <mach/platform.h>
> 
> What are you using from mach/platform.h?
This file is require for the define use to directly
access the clock register (see note below).
> 
> >
> >  /* WatchDog Timer - Chapter 23 Page 207 */
> >
> > @@ -77,6 +80,7 @@
> >
> >  static bool nowayout = WATCHDOG_NOWAYOUT;
> >  static unsigned int heartbeat = DEFAULT_HEARTBEAT;
> > +static struct notifier_block restart_handler;
> >
> >  static DEFINE_SPINLOCK(io_lock);
> >  static void __iomem    *wdt_base;
> > @@ -124,6 +128,27 @@ static int pnx4008_wdt_set_timeout(struct watchdog_device *wdd,
> >         return 0;
> >  }
> >
> > +static void pnx4008_wdt_sys_reset(enum reboot_mode mode, const char *cmd)
> > +{
> > +       /* Make sure WDT clocks are enabled */
> > +       writel(LPC32XX_CLKPWR_PWMCLK_WDOG_EN, LPC32XX_CLKPWR_TIMER_CLK_CTRL);
> 
> Doesn't the watchdog driver already enable this clock in probe?
> Either way doing a direct write to LPC32XX_CLKPWR_TIMER_CLK_CTRL from
> here isn't very nice.
> 
I keep this from the "mach-lpc32xx" implementation, in case the call to
the "devm_clk_get" fail in the probe; the restart will still work.

I can remove it, and the platform.h include.
> 
> > +       /* Instant assert of RESETOUT_N with pulse length 1mS */
> > +       writel(13000, WDTIM_PULSE(wdt_base));
> > +       writel(M_RES2 | RESFRC1 | RESFRC2, WDTIM_MCTRL(wdt_base));
> > +
> > +       /* Wait for watchdog to reset system */
> > +       mdelay(1000);
> > +}
> > +
> > +static int pnx4008_restart_handler(struct notifier_block *this,
> > +                                  unsigned long mode, void *cmd)
> > +{
> > +       pnx4008_wdt_sys_reset((enum reboot_mode)mode, cmd);
> 
> Why can you just the stuff from pnx4008_wdt_sys_reset() in this function?
> 
OK
> 
> > +
> > +       return NOTIFY_DONE;
> > +}
> > +
> >  static const struct watchdog_info pnx4008_wdt_ident = {
> >         .options = WDIOF_CARDRESET | WDIOF_MAGICCLOSE |
> >             WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
> > @@ -157,6 +182,11 @@ static int pnx4008_wdt_probe(struct platform_device *pdev)
> >         if (IS_ERR(wdt_base))
> >                 return PTR_ERR(wdt_base);
> >
> > +       /* Register restart handler. */
> > +       restart_handler.notifier_call = pnx4008_restart_handler;
> > +       restart_handler.priority = 128;
> > +       ret = register_restart_handler(&restart_handler);
> 
> Checking return value would be a nice thing to do.
OK
> 
> You should also do a unregister_restart_handler() in driver remove hook.
Thanks for catching it.

I will wait, in case there is other feedback, and submit a revision 3
of the patchset.
> 
> 
> regards,
> Joachim Eastwood




From mturquette at baylibre.com  Mon Feb 22 10:26:56 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Mon, 22 Feb 2016 10:26:56 -0800
Subject: [PATCH v5 2/3] clk: samsung: Don't build ARMv8 clock drivers on
 ARMv7
In-Reply-To: <56C44578.5010009@samsung.com>
References: <1455603632-11158-1-git-send-email-k.kozlowski@samsung.com>
 <1455603632-11158-3-git-send-email-k.kozlowski@samsung.com>
 <56C44578.5010009@samsung.com>
Message-ID: <20160222182656.2278.68402@quark.deferred.io>

Quoting Sylwester Nawrocki (2016-02-17 02:03:36)
> On 16/02/16 07:20, Krzysztof Kozlowski wrote:
> > Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS
> > so it is built also on ARMv7. This does not bring any kind of benefit.
> > There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like
> > multi_v7 for ARMv7).
> > 
> > Instead build clock drivers only for respective SoC's architecture.
> > 
> > Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> 
> Acked-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
> 

Thanks for the Ack.

I've rebased patches #1 and #2 against James's b9e65ebc654d and pushed
the clk-samsung branch to the clk tree. I have deleted the
clk-samsung-kconfig branch that was blowing up the kbuild robot.
clk-samsung will not be rebased and can be used as a dependency for
arm-soc. It has been merged into clk-next.

Regards,
Mike


From mturquette at baylibre.com  Mon Feb 22 10:32:03 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Mon, 22 Feb 2016 10:32:03 -0800
Subject: [PATCH 2/3] clk: mvebu: add AP806 core clock driver
In-Reply-To: <20160222141617.GA14970@lunn.ch>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455521698-7905-3-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160222025357.GE15973@rob-hp-laptop>
 <20160222091423.4756a579@free-electrons.com> <20160222141617.GA14970@lunn.ch>
Message-ID: <20160222183203.2278.60153@quark.deferred.io>

Quoting Andrew Lunn (2016-02-22 06:16:17)
> > Such information will come later, and we can rework the drivers and DT
> > bindings accordingly. Those DT bindings cannot be stable, as the
> > platform is under heavy development and we'll probably discover some
> > issues down the road.
> 
> Hi Thomas
> 
> Maybe add a big fat warning that the bindings are unstable, and the DT
> blob must be kept in sync with the kernel?

+1 and feel free to blame the lack of documentation.  No one can expect
bindings to be finalized when the chip topology is not fully understood.

Regards,
Mike

> 
>      Andrew


From keescook at chromium.org  Mon Feb 22 11:04:56 2016
From: keescook at chromium.org (Kees Cook)
Date: Mon, 22 Feb 2016 11:04:56 -0800
Subject: [PATCH 3/3] arm64: ptdump: include UEFI runtime service mappings
In-Reply-To: <CAKv+Gu8RCrZJ4F8CA+FWTBe+WaF11BTJiM0cRiHJH_b0snk-yA@mail.gmail.com>
References: <1456135239-3607-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456135239-3607-4-git-send-email-ard.biesheuvel@linaro.org>
 <20160222112901.GA3435@leverpostej>
 <CAKv+Gu8RCrZJ4F8CA+FWTBe+WaF11BTJiM0cRiHJH_b0snk-yA@mail.gmail.com>
Message-ID: <CAGXu5j+dyTxMn3ytZLaNeZsKWz2oeuYHysdS4hNBM7ewKX3gdA@mail.gmail.com>

On Mon, Feb 22, 2016 at 3:51 AM, Ard Biesheuvel
<ard.biesheuvel at linaro.org> wrote:
> On 22 February 2016 at 12:29, Mark Rutland <mark.rutland at arm.com> wrote:
>> Hi,
>>
>> On Mon, Feb 22, 2016 at 11:00:39AM +0100, Ard Biesheuvel wrote:
>>> This adds the UEFI runtime services page table mappings to the output
>>> of the kernel page table dumper. These tables are only live during the
>>> time UEFI runtime services are being invoked, but we can include them
>>> for informational purposes nonetheless.
>>
>> I would prefer that we had a separate file for the EFI runtime services
>> page tables. As you mention, they are distinct from the kernel and not
>> always live (which is also the case for the idmap, for example).
>>
>> I have some local patches atop of v4.3 that librify the dumping code and
>> add a separate file for EFI [1]. I spotted a couple other things in
>> doing that (e.g. that we need to pad addresses more).
>>
>> Is it worth cleaning that up?
>>
>
> I think so. It would be especially nice if we could share the
> registration API between ARM and arm64, since the ptdump code is very
> similar, and the UEFI range is identical between them

In a perfect world, we could unify the ptdump code between x86, arm,
and arm64. Doing this is on my TODO list, but way down the list. :P

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security


From dan.j.williams at intel.com  Mon Feb 22 11:05:51 2016
From: dan.j.williams at intel.com (Dan Williams)
Date: Mon, 22 Feb 2016 11:05:51 -0800
Subject: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB
 mappings
In-Reply-To: <1456149728-16706-2-git-send-email-ard.biesheuvel@linaro.org>
References: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456149728-16706-2-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <CAPcyv4ivN9c8PHBR77vd36ovB28OETJUr6VYf_8gNtXgqEmATw@mail.gmail.com>

On Mon, Feb 22, 2016 at 6:02 AM, Ard Biesheuvel
<ard.biesheuvel at linaro.org> wrote:
> Currently, the memremap code serves MEMREMAP_WB mappings directly from
> the kernel direct mapping, unless the region is in high memory, in which
> case it falls back to using ioremap_cache(). However, the semantics of
> ioremap_cache() are not unambiguously defined, and on ARM, it will
> actually result in a mapping type that differs from the attributes used
> for the linear mapping, and for this reason, the ioremap_cache() call
> fails if the region is part of the memory managed by the kernel.
>
> So instead, implement an optional hook 'arch_memremap_wb' whose default
> implementation calls ioremap_cache() as before, but which can be
> overridden by the architecture to do what is appropriate for it.
>

Acked-by: Dan Williams <dan.j.williams at intel.com>

I still have patches pending to delete ioremap_cache() from ARM and
require memremap() to be used for cacheable mappings.  Do you see any
use for ioremap_cache() on ARM after this change?


From dianders at google.com  Mon Feb 22 11:15:09 2016
From: dianders at google.com (Doug Anderson)
Date: Mon, 22 Feb 2016 11:15:09 -0800
Subject: [PATCH v3 00/12] pwm: add support for atomic update
In-Reply-To: <20160222175929.GA23899@ulmo>
References: <1442828009-6241-1-git-send-email-boris.brezillon@free-electrons.com>
 <2341981.a79ioYM9Es@diego> <20151110173416.GB21727@ulmo>
 <CAD=FV=WL3jYEgVe-m6QcAyQwfJgdX4J5OtKisKwyoKOrTSpEQA@mail.gmail.com>
 <20160125170855.GA10182@ulmo>
 <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
 <20160203145337.GD9650@ulmo>
 <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
 <20160222175929.GA23899@ulmo>
Message-ID: <CAD=FV=UCErW3EjYRtwt49_ztNR7cyY4U0o4R_dxdomer-Ac2Dg@mail.gmail.com>

Thierry,

On Mon, Feb 22, 2016 at 9:59 AM, Thierry Reding
<thierry.reding at gmail.com> wrote:
>> This is because only some drivers would be able to read the hardware
>> state?  I'm not sure how we can get away from that.  In all proposals
>> we've talked about (including what you propose below, right?) the PWM
>> regulator will need a PWM driver that can read hardware state.  Only
>> PWM drivers that have been upgraded to support reading hardware state
>> can use the PWM regulator (or at least only those drivers will be able
>> to use the PWM regulator glitch-free).
>
> Yes, the key here is glitch-free. There's no reason whatsoever that the
> rugaltor-pwm driver should be limited to usage with a hardware readout-
> capable PWM driver. If you don't care about glitches, likely because no
> critical components depend on the regulator, you can simply force what
> state you choose on boot.
>
> As a matter of fact, I think that's how regulators work already. If the
> current output voltage doesn't match the specified constraints, then a
> valid value will be forced by the regulator core. If the voltage lies
> within the constraints the core won't touch the regulator. Is this not
> going to "just work" with the PWM regulator?
>
> The problem is somewhat simplified if that's the case. An implementation
> could then fail the regulator_get_voltage() if hardware readout is not
> supported and return the current voltage when readout is possible.

Based on looking at the current code, I believe it just returns 0V
until you call regulator_set_voltage() today.  I don't think that was
always the case.  Back before it was made continuous I think it
returned the voltage that matched with 0% duty cycle.

I haven't dug into what the regulator framework does in the current
system nor what happens if regulator_get_voltage() returns an error.
Perhaps Boris can dig / comment?


>> When we add a new feature then it's expected that only updated drivers
>> will support that feature.
>>
>> We need to make sure that we don't regress / negatively change the
>> behavior for anyone running non-updated drivers.  ...and we should
>> strive to require as few changes to drivers as possible.  ...but if
>> the best we can do requires changes to the PWM driver API then we will
>> certainly have differences depending on the PWM driver.
>
> How so? Drivers should behave consistently, irrespective of the API. Of
> course if you need to change behaviour of the user driver depending on
> the availability of a certain feature, that's perfectly fine.
>
> Furthermore it's out of the question that changes to the API will be
> required. That's precisely the reason why the atomic PWM proposal came
> about. It's an attempt to solve the shortcomings of the current API for
> cases such as Rockchip.

I _think_ we're on the same page here.  If there are shortcomings with
the current API that make it impossible to implement a feature, we've
got to change and/or add to the existing API.  ...but we don't want to
break existing users / drivers.

Note that historically I remember that Linus Torvalds has stated that
there is no stable API within the Linux kernel and that forcing the
in-kernel API to never change was bad for software development.  I
tracked down my memory and found
<http://lwn.net/1999/0211/a/lt-binary.html>.  Linus is rabid about not
breaking userspace, but in general there's no strong requirement to
never change the driver API inside the kernel.  That being said,
changing the driver API causes a lot of churn, so presumably changing
it in a backward compatible way (like adding to the API instead of
changing it) will make things happier.


>> That means that if you call pwm_get_period() right away at boot time
>> you're not getting the current period of the hardware but the period
>> that was specified in the device tree.
>
> Yes.
>
>> So all we need is a new API call that lets you read the hardware
>> values and make sure that the PWM regulator calls that before anyone
>> calls pwm_config().  That's roughly B) above.
>
> Yes. I'm thinking that we should have a pwm_get_state() which retrieves
> the current state of the PWM. For drivers that support hardware readout
> this state should match the hardware state. For other drivers it should
> reflect whatever was specified in DT; essentially what pwm_get_period()
> and friends return today.

Excellent, so pwm_get_period() gets the period as specified in the
device tree (or other board config) and pwm_get_state() returns the
hardware state.  SGTM.


> That way if you want to get the current voltage in the regulator-pwm
> driver you'd simply do a pwm_get_state() and compute the voltage from
> the period and duty cycle. If the PWM driver that you happen to use
> doesn't support hardware readout, you'll get an initial output voltage
> of 0, which is as good as any, really.

Sounds fine to me.  PWM regulator is in charge of calling
pwm_get_state(), which can return 0 (or an error?) if driver (or
underlying hardware) doesn't support hardware readout.  PWM regulator
is in charge of using the resulting period / duty cycle to calculate a
percentage.


>> Sure.  ...but you agree that somehow you need a new API call for this,
>> right?  Somehow the PWM regulator needs to be able to say that it
>> wants the hardware state, not the initial state as specified in the
>> device tree.
>
> The atomic PWM API is this new API. I'm not arguing that we don't need
> new API. What's being discussed is what the API needs to look like to
> support this new use-case and at the same time be maximally compatible
> with existing users.
>
> I think perhaps one question that needs answering to do that is whether
> or not the regulator-pwm driver can guess the correct period. The issue
> that was initially being discussed is what to do with hardware state vs
> initial state (i.e. what's defined in DT). Mark commented in another
> subthread that DT should simply leave out data that doesn't make sense
> to be specified.
>
> However I don't think there's any particularly reasonable period for the
> regulator-pwm use-case, so specifying the period within DT would still
> be necessary. What works for one board may not be the correct (or
> optimal) value for another. Similarly one board may need to invert the
> PWM signal to generate the proper voltage, or require other parameters
> that we haven't even defined yet.
>
> There's also the issue of a voltage table that you need to define in the
> DT for the regulator-pwm device. Does that consist of only duty-cycle
> values, or does it have corresponding period values as well. I'd guess
> that it really only needs the duty cycle given any period. So something
> like this is what I'd expect:
>
>         regulator {
>                 compatible = "regulator-pwm";
>
>                 pwms = <&pwm0 5000>;
>
>                 voltages = <0 0>, <1000000 1000>, ..., <5000000 5000>;
>         };
>
> I think the pwm-regulator binding defines the duty cycle in percent. I
> guess that would work equally well.
>
> And now we've come full circle because, again, we need to differentiate
> between the current hardware state and the initial state. Or, as was
> also discussed previously, alternatively, ignore the period specified in
> DT and just go with what hardware readout defined. In case hardware
> readout isn't supported, the "hardware state" will simply be the
> "initial state".
>
> The objection to the latter alternative was that we shouldn't trust the
> firmware to have set up the regulator correctly. But if it didn't, how
> can we trust that the duty cycle to period ratio is correct? Or the
> other way around: if we trust the duty cycle to period ratio to have
> been setup correctly, why don't we trust the period?

To answer:

* No, PWM regulator can't guess the correct period.

* PWM regulator API is already fine as is.  Period specified in PWM
specifier and table is specified in percentages.

* Firmware may have voltage setup correctly but may not have the
"ideal" period.  Often firmware configures things in a way that works
but is sub-optimal.  Basically the kernel should be able to tell what
voltage the firmware set things up at (so we know not to go lower on
accident), but we shouldn't assume that the firmware values are
perfect.  Said another way: obviously the firmware made values that
were good enough to boot us to where we are (or we wouldn't be even
executing code), but we might want to configure things to reduce noise
on the lines (make HDMI work better?) or optimize power consumption.

--

I _think_ the end result of all this is just:

1. Introduce pwm_get_state() that gets hardware state.  Up for debate
if this returns 0 or ERROR if a driver doesn't implement this.

2. PWM regulator calls pwm_get_state at probe time to get hardware
state, calculates a percentage (and voltage) with this.

3. PWM regulator does nothing else until it is asked to set the
voltage, but uses the voltage calculated from #2 to satisfy any "get
voltage" calls.

4. When asked to set the voltage, PWM regulator uses pwm_get_period()
and calculates a duty cycle based on that, just like it does today.
This uses pwm_config() which includes a duty cycle and period and is
thus "atomic".


Said another way: the only action item from this point of view is just
that we introduce a new pwm_get_state().


Boris: I think that's everything you need, right?

--

Historically there was also a necessity that we were very careful with
the PWM clock because the clock would end up getting disabled
temporarily at bootup (after the PWM probe time but before the PWM
regulator finished probing).  Presumably that's either been solved
already or can be debated totally separately.


-Doug


From robh at kernel.org  Mon Feb 22 11:16:12 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 22 Feb 2016 13:16:12 -0600
Subject: [PATCH] irqchip: irq-mvebu-odmi: new driver
In-Reply-To: <20160222091055.524c60a9@free-electrons.com>
References: <1455522162-16425-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160222025353.GD15973@rob-hp-laptop>
 <20160222091055.524c60a9@free-electrons.com>
Message-ID: <CAL_JsqJGoUW0jZKShosF_WskaDOj6aQnG=RbN+BQvTzAYjmB_Q@mail.gmail.com>

On Mon, Feb 22, 2016 at 2:10 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Hello,
>
> FWIW, you're replying to the v1 of this patch, while v2 and v3 have
> already been posted, and v3 has already been merged by the irqchip
> maintainers:
>
>   http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=c27f29bbbf02168c9b1e8ba0fe7a8cb917e5a50f

Well, that's what you get when I'm working offline for a bit. :)

> On Sun, 21 Feb 2016 20:53:53 -0600, Rob Herring wrote:
>
>> > +- compatible              : The value here should contain "marvell,odmi-controller".
>>
>> SoC specific compatible too please.
>
> I can add that in a follow-up patch.

Please do.

>
>> > +- marvell,spi-base     : List of GIC base SPI interrupts, one for each
>> > +                         ODMI frame.
>>
>> Why not "interrupts" property?
>
> This has already been discussed with Arnd in a more recent iteration of
> the patch:
>
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409411.html
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409415.html
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/409430.html

Okay, it's fine.

Rob


From ard.biesheuvel at linaro.org  Mon Feb 22 11:17:11 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 20:17:11 +0100
Subject: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB
 mappings
In-Reply-To: <CAPcyv4ivN9c8PHBR77vd36ovB28OETJUr6VYf_8gNtXgqEmATw@mail.gmail.com>
References: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456149728-16706-2-git-send-email-ard.biesheuvel@linaro.org>
 <CAPcyv4ivN9c8PHBR77vd36ovB28OETJUr6VYf_8gNtXgqEmATw@mail.gmail.com>
Message-ID: <CAKv+Gu9OWVgo+Qm85jPjY7xJ1UELm-4LYORHKF8Yy+_HuzmtGw@mail.gmail.com>

On 22 February 2016 at 20:05, Dan Williams <dan.j.williams at intel.com> wrote:
> On Mon, Feb 22, 2016 at 6:02 AM, Ard Biesheuvel
> <ard.biesheuvel at linaro.org> wrote:
>> Currently, the memremap code serves MEMREMAP_WB mappings directly from
>> the kernel direct mapping, unless the region is in high memory, in which
>> case it falls back to using ioremap_cache(). However, the semantics of
>> ioremap_cache() are not unambiguously defined, and on ARM, it will
>> actually result in a mapping type that differs from the attributes used
>> for the linear mapping, and for this reason, the ioremap_cache() call
>> fails if the region is part of the memory managed by the kernel.
>>
>> So instead, implement an optional hook 'arch_memremap_wb' whose default
>> implementation calls ioremap_cache() as before, but which can be
>> overridden by the architecture to do what is appropriate for it.
>>
>
> Acked-by: Dan Williams <dan.j.williams at intel.com>
>
> I still have patches pending to delete ioremap_cache() from ARM and
> require memremap() to be used for cacheable mappings.  Do you see any
> use for ioremap_cache() on ARM after this change?

I am not exactly sure why ioremap_cache() does not use MT_MEMORY_RW
attributes, but the ARM architecture simply does not allow mismatched
attributes, so we cannot simply replace each instance of
ioremap_cache() with memremap()

Perhaps Russell can explain?


From tony at atomide.com  Mon Feb 22 11:19:01 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 11:19:01 -0800
Subject: [PATCH 1/2] ARM: dts: am57xx-beagle-x15: Add eeprom information
In-Reply-To: <1456159868-32416-2-git-send-email-nm@ti.com>
References: <1456159868-32416-1-git-send-email-nm@ti.com>
 <1456159868-32416-2-git-send-email-nm@ti.com>
Message-ID: <20160222191901.GT13417@atomide.com>

* Nishanth Menon <nm at ti.com> [160222 08:51]:
> Add EEPROM at 0x50 that describes the board configuration.
> This is useful for userspace programs that may need to check board
> revision and other similar information.
> 
> Signed-off-by: Nishanth Menon <nm at ti.com>
> ---
>  arch/arm/boot/dts/am57xx-beagle-x15.dts | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> index 36c0fa6c362a..50312f80b972 100644
> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> @@ -591,6 +591,11 @@
>  		DRVDD-supply = <&vdd_3v3>;
>  		DVDD-supply = <&aic_dvdd>;
>  	};
> +
> +	eeprom: eeprom at 50 {
> +		compatible = "at,24c32";
> +		reg = <0x50>;
> +	};
>  };
>  

Applying into omap-for-v4.6/dt thanks.

Tony


From mickamusset at gmail.com  Mon Feb 22 11:26:07 2016
From: mickamusset at gmail.com (Micka)
Date: Mon, 22 Feb 2016 20:26:07 +0100
Subject: max3107 & device tree
Message-ID: <CAF+MRtnjZfr5U482s+Hx8mU_LPO_j4fbgxm7vCe8D+s4R3Zqfg@mail.gmail.com>

Hi,

I have a max3107 on my board, I'm trying to configure the device tree,
but it looks like that I need a clock :

http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/serial/maxim,max310x.txt?v=4.1

clocks: phandle to the IC source clock. clock-names: Should be "xtal"
if clock is an external crystal or "osc" if an external clock source
is used.

And I don't know what to put for the clock.

I would like to use xtal because I've a an external clock (quartz)
that is driving the max3107 but I don't know what to put for the
clocks = ?? I don't have clk20m referenced in the file
am33xx-clocks.dtsi .....

the frequency of my quartz is 1.8432MHz

any idea what I should do ?


From dmitry.torokhov at gmail.com  Mon Feb 22 11:36:04 2016
From: dmitry.torokhov at gmail.com (Dmitry Torokhov)
Date: Mon, 22 Feb 2016 11:36:04 -0800
Subject: [PATCH v2 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <CAAFb_vq6_uQbcWvwV8TZqVqH_C-ueUd+gBRA=mXUQrWqxoz=ww@mail.gmail.com>
References: <1455702226-20599-1-git-send-email-raveendra.padasalagi@broadcom.com>
 <1455702226-20599-2-git-send-email-raveendra.padasalagi@broadcom.com>
 <20160218143617.GH9654@rob-hp-laptop>
 <CAAFb_vq6_uQbcWvwV8TZqVqH_C-ueUd+gBRA=mXUQrWqxoz=ww@mail.gmail.com>
Message-ID: <20160222193604.GA26177@dtor-ws>

On Fri, Feb 19, 2016 at 11:43:50AM +0530, Raveendra Padasalagi wrote:
> On Thu, Feb 18, 2016 at 8:06 PM, Rob Herring <robh at kernel.org> wrote:
> > On Wed, Feb 17, 2016 at 03:13:44PM +0530, Raveendra Padasalagi wrote:
> >> In Cygnus SOC touch screen controller registers are shared
> >> with ADC and flex timer. Using readl/writel could lead to
> >> race condition. So touch screen driver is enhanced to support
> >>
> >> 1. If touchscreen register's are not shared. Register access
> >> is handled through readl/writel if "brcm,iproc-touchscreen"
> >> compatible is provided in touchscreen dt node. This will help
> >> for future SOC's if comes with dedicated touchscreen IP register's.
> >>
> >> 2. If touchscreen register's are shared with other IP's, register
> >> access is handled through syscon framework API's to take care of
> >> mutually exclusive access. This feature can be enabled by selecting
> >> "brcm,iproc-touchscreen-syscon" compatible string in the touchscreen
> >> dt node.
> >>
> >> Hence touchscreen dt node bindings document is updated to take care
> >> of above changes in the touchscreen driver.
> >>
> >> Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi at broadcom.com>
> >> Reviewed-by: Ray Jui <ray.jui at broadcom.com>
> >> Reviewed-by: Scott Branden <scott.branden at broadcom.com>
> >> ---
> >>  .../input/touchscreen/brcm,iproc-touchscreen.txt   | 57 +++++++++++++++++++---
> >>  1 file changed, 51 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
> >> index 34e3382..f530c25 100644
> >> --- a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
> >> +++ b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
> >> @@ -1,12 +1,30 @@
> >>  * Broadcom's IPROC Touchscreen Controller
> >>
> >>  Required properties:
> >> -- compatible: must be "brcm,iproc-touchscreen"
> >> -- reg: physical base address of the controller and length of memory mapped
> >> -  region.
> >> +- compatible: should be one of
> >> +        "brcm,iproc-touchscreen"
> >> +        "brcm,iproc-touchscreen-syscon"
> >
> > More specific and this is not how you do syscon. Either the block is or
> > isn't. You can't have it both ways.
> 
> Existing driver has support for reg, if we modify now to support only syscon
> then this driver will not work if some one wishes to use previous
> kernel version's
> dt and vice versa. Basically this breaks dt compatibility. Is that ok ?

But the issue is that the driver does not actually work correctly with
direct register access on those systems, since the registers are
actually shared with other components. I am not quite sure if it is OK
to break DT binding in this case...

Thanks.

-- 
Dmitry


From labbott at redhat.com  Mon Feb 22 11:37:28 2016
From: labbott at redhat.com (Laura Abbott)
Date: Mon, 22 Feb 2016 11:37:28 -0800
Subject: [PATCH 1/3] arm64: ptdump: use static initializers for vmemmap
 region boundaries
In-Reply-To: <20160222113310.GB3435@leverpostej>
References: <1456135239-3607-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456135239-3607-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160222113310.GB3435@leverpostej>
Message-ID: <56CB6378.9090207@redhat.com>

On 02/22/2016 03:33 AM, Mark Rutland wrote:
> Hi,
>
> On Mon, Feb 22, 2016 at 11:00:37AM +0100, Ard Biesheuvel wrote:
>> There is no need to initialize the vmemmap region boundaries dynamically,
>> since they are compile time constants. So just add these constants to the
>> global struct initializer, and drop the dynamic assignment and related code.
>
> This does look nicer.
>
> I believe the intention here was to mark the end of the _populated_
> vmemmap region rather than the static VA carveout, so this is a slight
> change in behaviour.
>
> However, I don't think we gained much by only handling the populated
> region, and we didn't do the same for the linear map. So FWIW:
>
> Acked-by: Mark Rutland <mark.rutland at arm.com>
>

Yes, I implemented it off of the existing calculation for printing in
init.c which at the time was static. Going the full range does match
up better with the rest of the markers.

Acked-by: Laura Abbott <labbott at redhat.com>
  
> Mark.
>
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> ---
>>   arch/arm64/mm/dump.c | 47 +++++---------------
>>   1 file changed, 12 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
>> index 6be918478f85..eadcb70e733c 100644
>> --- a/arch/arm64/mm/dump.c
>> +++ b/arch/arm64/mm/dump.c
>> @@ -34,37 +34,21 @@ struct addr_marker {
>>   	const char *name;
>>   };
>>
>> -enum address_markers_idx {
>> -	MODULES_START_NR = 0,
>> -	MODULES_END_NR,
>> -	VMALLOC_START_NR,
>> -	VMALLOC_END_NR,
>> -#ifdef CONFIG_SPARSEMEM_VMEMMAP
>> -	VMEMMAP_START_NR,
>> -	VMEMMAP_END_NR,
>> -#endif
>> -	FIXADDR_START_NR,
>> -	FIXADDR_END_NR,
>> -	PCI_START_NR,
>> -	PCI_END_NR,
>> -	KERNEL_SPACE_NR,
>> -};
>> -
>>   static struct addr_marker address_markers[] = {
>> -	{ MODULES_VADDR,	"Modules start" },
>> -	{ MODULES_END,		"Modules end" },
>> -	{ VMALLOC_START,	"vmalloc() Area" },
>> -	{ VMALLOC_END,		"vmalloc() End" },
>> +	{ MODULES_VADDR,		"Modules start" },
>> +	{ MODULES_END,			"Modules end" },
>> +	{ VMALLOC_START,		"vmalloc() Area" },
>> +	{ VMALLOC_END,			"vmalloc() End" },
>>   #ifdef CONFIG_SPARSEMEM_VMEMMAP
>> -	{ 0,			"vmemmap start" },
>> -	{ 0,			"vmemmap end" },
>> +	{ (u64)vmemmap,			"vmemmap start" },
>> +	{ (u64)vmemmap + VMEMMAP_SIZE,	"vmemmap end" },
>>   #endif
>> -	{ FIXADDR_START,	"Fixmap start" },
>> -	{ FIXADDR_TOP,		"Fixmap end" },
>> -	{ PCI_IO_START,		"PCI I/O start" },
>> -	{ PCI_IO_END,		"PCI I/O end" },
>> -	{ PAGE_OFFSET,		"Linear Mapping" },
>> -	{ -1,			NULL },
>> +	{ FIXADDR_START,		"Fixmap start" },
>> +	{ FIXADDR_TOP,			"Fixmap end" },
>> +	{ PCI_IO_START,			"PCI I/O start" },
>> +	{ PCI_IO_END,			"PCI I/O end" },
>> +	{ PAGE_OFFSET,			"Linear Mapping" },
>> +	{ -1,				NULL },
>>   };
>>
>>   /*
>> @@ -349,13 +333,6 @@ static int ptdump_init(void)
>>   			for (j = 0; j < pg_level[i].num; j++)
>>   				pg_level[i].mask |= pg_level[i].bits[j].mask;
>>
>> -#ifdef CONFIG_SPARSEMEM_VMEMMAP
>> -	address_markers[VMEMMAP_START_NR].start_address =
>> -				(unsigned long)virt_to_page(PAGE_OFFSET);
>> -	address_markers[VMEMMAP_END_NR].start_address =
>> -				(unsigned long)virt_to_page(high_memory);
>> -#endif
>> -
>>   	pe = debugfs_create_file("kernel_page_tables", 0400, NULL, NULL,
>>   				 &ptdump_fops);
>>   	return pe ? 0 : -ENOMEM;
>> --
>> 2.5.0
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>



From scott.branden at broadcom.com  Mon Feb 22 11:41:37 2016
From: scott.branden at broadcom.com (Scott Branden)
Date: Mon, 22 Feb 2016 11:41:37 -0800
Subject: [PATCH v2 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <20160222193604.GA26177@dtor-ws>
References: <1455702226-20599-1-git-send-email-raveendra.padasalagi@broadcom.com>
 <1455702226-20599-2-git-send-email-raveendra.padasalagi@broadcom.com>
 <20160218143617.GH9654@rob-hp-laptop>
 <CAAFb_vq6_uQbcWvwV8TZqVqH_C-ueUd+gBRA=mXUQrWqxoz=ww@mail.gmail.com>
 <20160222193604.GA26177@dtor-ws>
Message-ID: <56CB6471.3020400@broadcom.com>

My comments below

On 16-02-22 11:36 AM, Dmitry Torokhov wrote:
> On Fri, Feb 19, 2016 at 11:43:50AM +0530, Raveendra Padasalagi wrote:
>> On Thu, Feb 18, 2016 at 8:06 PM, Rob Herring <robh at kernel.org> wrote:
>>> On Wed, Feb 17, 2016 at 03:13:44PM +0530, Raveendra Padasalagi wrote:
>>>> In Cygnus SOC touch screen controller registers are shared
>>>> with ADC and flex timer. Using readl/writel could lead to
>>>> race condition. So touch screen driver is enhanced to support
>>>>
>>>> 1. If touchscreen register's are not shared. Register access
>>>> is handled through readl/writel if "brcm,iproc-touchscreen"
>>>> compatible is provided in touchscreen dt node. This will help
>>>> for future SOC's if comes with dedicated touchscreen IP register's.
>>>>
>>>> 2. If touchscreen register's are shared with other IP's, register
>>>> access is handled through syscon framework API's to take care of
>>>> mutually exclusive access. This feature can be enabled by selecting
>>>> "brcm,iproc-touchscreen-syscon" compatible string in the touchscreen
>>>> dt node.
>>>>
>>>> Hence touchscreen dt node bindings document is updated to take care
>>>> of above changes in the touchscreen driver.
>>>>
>>>> Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi at broadcom.com>
>>>> Reviewed-by: Ray Jui <ray.jui at broadcom.com>
>>>> Reviewed-by: Scott Branden <scott.branden at broadcom.com>
>>>> ---
>>>>   .../input/touchscreen/brcm,iproc-touchscreen.txt   | 57 +++++++++++++++++++---
>>>>   1 file changed, 51 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>>>> index 34e3382..f530c25 100644
>>>> --- a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>>>> +++ b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>>>> @@ -1,12 +1,30 @@
>>>>   * Broadcom's IPROC Touchscreen Controller
>>>>
>>>>   Required properties:
>>>> -- compatible: must be "brcm,iproc-touchscreen"
>>>> -- reg: physical base address of the controller and length of memory mapped
>>>> -  region.
>>>> +- compatible: should be one of
>>>> +        "brcm,iproc-touchscreen"
>>>> +        "brcm,iproc-touchscreen-syscon"
>>>
>>> More specific and this is not how you do syscon. Either the block is or
>>> isn't. You can't have it both ways.
>>
>> Existing driver has support for reg, if we modify now to support only syscon
>> then this driver will not work if some one wishes to use previous
>> kernel version's
>> dt and vice versa. Basically this breaks dt compatibility. Is that ok ?
>
> But the issue is that the driver does not actually work correctly with
> direct register access on those systems, since the registers are
> actually shared with other components. I am not quite sure if it is OK
> to break DT binding in this case...

The driver does work correctly with direct register access on those 
systems because the other components using those registers are not 
active in those systems - so syscon is not needed in those cases.

I'm ok with not containing backwards compatibility though and always 
using syscon.  There are no deployed systems using older versions of the 
upstreamed kernel.
>
> Thanks.
>

Regards,
Scott


From robh at kernel.org  Mon Feb 22 11:42:49 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 22 Feb 2016 13:42:49 -0600
Subject: [PATCH 2/3] clk: mvebu: add AP806 core clock driver
In-Reply-To: <20160222183203.2278.60153@quark.deferred.io>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455521698-7905-3-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160222025357.GE15973@rob-hp-laptop>
 <20160222091423.4756a579@free-electrons.com>
 <20160222141617.GA14970@lunn.ch> <20160222183203.2278.60153@quark.deferred.io>
Message-ID: <CAL_Jsq+iiUBcTdnqzFWLJ+5jPvq0rmWgBboab4xyj1dQyDQE+Q@mail.gmail.com>

On Mon, Feb 22, 2016 at 12:32 PM, Michael Turquette
<mturquette at baylibre.com> wrote:
> Quoting Andrew Lunn (2016-02-22 06:16:17)
>> > Such information will come later, and we can rework the drivers and DT
>> > bindings accordingly. Those DT bindings cannot be stable, as the
>> > platform is under heavy development and we'll probably discover some
>> > issues down the road.
>>
>> Hi Thomas
>>
>> Maybe add a big fat warning that the bindings are unstable, and the DT
>> blob must be kept in sync with the kernel?
>
> +1 and feel free to blame the lack of documentation.  No one can expect
> bindings to be finalized when the chip topology is not fully understood.

I can understand not understanding the full clock tree. I have "full"
documentation of a Marvell chip and don't understand the clock tree
fully. But I can't believe you don't have some sense of how many
clocks you have to deal with. 10? 100? 1000? What I see is 2 nodes of
a single register each for clocks at roughly the same address. That
tells me your binding is too fine grained. If you really don't know
what is right, then err on the side of a single clock provider node
and don't put the clock details in DT.

Rob


From ray.jui at broadcom.com  Mon Feb 22 11:48:47 2016
From: ray.jui at broadcom.com (Ray Jui)
Date: Mon, 22 Feb 2016 11:48:47 -0800
Subject: [PATCH v2 1/3] input: cygnus-update touchscreen dt node document
In-Reply-To: <56CB6471.3020400@broadcom.com>
References: <1455702226-20599-1-git-send-email-raveendra.padasalagi@broadcom.com>
 <1455702226-20599-2-git-send-email-raveendra.padasalagi@broadcom.com>
 <20160218143617.GH9654@rob-hp-laptop>
 <CAAFb_vq6_uQbcWvwV8TZqVqH_C-ueUd+gBRA=mXUQrWqxoz=ww@mail.gmail.com>
 <20160222193604.GA26177@dtor-ws> <56CB6471.3020400@broadcom.com>
Message-ID: <47ef2a75-3f97-644f-a817-c93e6b3bc658@broadcom.com>



On 2/22/2016 11:41 AM, Scott Branden wrote:
> My comments below
>
> On 16-02-22 11:36 AM, Dmitry Torokhov wrote:
>> On Fri, Feb 19, 2016 at 11:43:50AM +0530, Raveendra Padasalagi wrote:
>>> On Thu, Feb 18, 2016 at 8:06 PM, Rob Herring <robh at kernel.org> wrote:
>>>> On Wed, Feb 17, 2016 at 03:13:44PM +0530, Raveendra Padasalagi wrote:
>>>>> In Cygnus SOC touch screen controller registers are shared
>>>>> with ADC and flex timer. Using readl/writel could lead to
>>>>> race condition. So touch screen driver is enhanced to support
>>>>>
>>>>> 1. If touchscreen register's are not shared. Register access
>>>>> is handled through readl/writel if "brcm,iproc-touchscreen"
>>>>> compatible is provided in touchscreen dt node. This will help
>>>>> for future SOC's if comes with dedicated touchscreen IP register's.
>>>>>
>>>>> 2. If touchscreen register's are shared with other IP's, register
>>>>> access is handled through syscon framework API's to take care of
>>>>> mutually exclusive access. This feature can be enabled by selecting
>>>>> "brcm,iproc-touchscreen-syscon" compatible string in the touchscreen
>>>>> dt node.
>>>>>
>>>>> Hence touchscreen dt node bindings document is updated to take care
>>>>> of above changes in the touchscreen driver.
>>>>>
>>>>> Signed-off-by: Raveendra Padasalagi
>>>>> <raveendra.padasalagi at broadcom.com>
>>>>> Reviewed-by: Ray Jui <ray.jui at broadcom.com>
>>>>> Reviewed-by: Scott Branden <scott.branden at broadcom.com>
>>>>> ---
>>>>>   .../input/touchscreen/brcm,iproc-touchscreen.txt   | 57
>>>>> +++++++++++++++++++---
>>>>>   1 file changed, 51 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>>>>> b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>>>>>
>>>>> index 34e3382..f530c25 100644
>>>>> ---
>>>>> a/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>>>>>
>>>>> +++
>>>>> b/Documentation/devicetree/bindings/input/touchscreen/brcm,iproc-touchscreen.txt
>>>>>
>>>>> @@ -1,12 +1,30 @@
>>>>>   * Broadcom's IPROC Touchscreen Controller
>>>>>
>>>>>   Required properties:
>>>>> -- compatible: must be "brcm,iproc-touchscreen"
>>>>> -- reg: physical base address of the controller and length of
>>>>> memory mapped
>>>>> -  region.
>>>>> +- compatible: should be one of
>>>>> +        "brcm,iproc-touchscreen"
>>>>> +        "brcm,iproc-touchscreen-syscon"
>>>>
>>>> More specific and this is not how you do syscon. Either the block is or
>>>> isn't. You can't have it both ways.
>>>
>>> Existing driver has support for reg, if we modify now to support only
>>> syscon
>>> then this driver will not work if some one wishes to use previous
>>> kernel version's
>>> dt and vice versa. Basically this breaks dt compatibility. Is that ok ?
>>
>> But the issue is that the driver does not actually work correctly with
>> direct register access on those systems, since the registers are
>> actually shared with other components. I am not quite sure if it is OK
>> to break DT binding in this case...
>
> The driver does work correctly with direct register access on those
> systems because the other components using those registers are not
> active in those systems - so syscon is not needed in those cases.
>
> I'm ok with not containing backwards compatibility though and always
> using syscon.  There are no deployed systems using older versions of the
> upstreamed kernel.
>>
>> Thanks.
>>
>
> Regards,
> Scott

The iproc touchscreen is currently activated in the "bcm9hmidc.dtsi" 
that represents the optional daughter card installed on reference boards 
bcm958300k and bcm958305k. While not maintaining backwards compatibility 
*might not* be a serious issue, it would be nice if we can at least make 
sure the driver change and DT are merged into the same kernel version so 
they stay in sync.

Going forward, if we are only going to support syscon based 
implementation, the existing compatible string "brcm,iproc-touchscreen" 
is preferred over "brcm,iproc-touchscreen-syscon".

Thanks,

Ray


From dan.j.williams at intel.com  Mon Feb 22 11:55:35 2016
From: dan.j.williams at intel.com (Dan Williams)
Date: Mon, 22 Feb 2016 11:55:35 -0800
Subject: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB
 mappings
In-Reply-To: <CAKv+Gu9OWVgo+Qm85jPjY7xJ1UELm-4LYORHKF8Yy+_HuzmtGw@mail.gmail.com>
References: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456149728-16706-2-git-send-email-ard.biesheuvel@linaro.org>
 <CAPcyv4ivN9c8PHBR77vd36ovB28OETJUr6VYf_8gNtXgqEmATw@mail.gmail.com>
 <CAKv+Gu9OWVgo+Qm85jPjY7xJ1UELm-4LYORHKF8Yy+_HuzmtGw@mail.gmail.com>
Message-ID: <CAPcyv4gtzzSBTUdd6_5P0C=bJBgbb1q035bQX9OcxUUT1ifJeA@mail.gmail.com>

On Mon, Feb 22, 2016 at 11:17 AM, Ard Biesheuvel
<ard.biesheuvel at linaro.org> wrote:
> On 22 February 2016 at 20:05, Dan Williams <dan.j.williams at intel.com> wrote:
>> On Mon, Feb 22, 2016 at 6:02 AM, Ard Biesheuvel
>> <ard.biesheuvel at linaro.org> wrote:
>>> Currently, the memremap code serves MEMREMAP_WB mappings directly from
>>> the kernel direct mapping, unless the region is in high memory, in which
>>> case it falls back to using ioremap_cache(). However, the semantics of
>>> ioremap_cache() are not unambiguously defined, and on ARM, it will
>>> actually result in a mapping type that differs from the attributes used
>>> for the linear mapping, and for this reason, the ioremap_cache() call
>>> fails if the region is part of the memory managed by the kernel.
>>>
>>> So instead, implement an optional hook 'arch_memremap_wb' whose default
>>> implementation calls ioremap_cache() as before, but which can be
>>> overridden by the architecture to do what is appropriate for it.
>>>
>>
>> Acked-by: Dan Williams <dan.j.williams at intel.com>
>>
>> I still have patches pending to delete ioremap_cache() from ARM and
>> require memremap() to be used for cacheable mappings.  Do you see any
>> use for ioremap_cache() on ARM after this change?
>
> I am not exactly sure why ioremap_cache() does not use MT_MEMORY_RW
> attributes, but the ARM architecture simply does not allow mismatched
> attributes, so we cannot simply replace each instance of
> ioremap_cache() with memremap()
>
> Perhaps Russell can explain?

>From the x86 perspective mismatched mappings are also disallowed.  The
goal of deprecating ioremap_cache() in favor of memremap() is simply
that the __iomem annotation is misplaced [1], and to clean up the
calling convention to be explicit without silent fallbacks to
different mapping types.

[1]: https://lwn.net/Articles/653585/


From robh+dt at kernel.org  Mon Feb 22 11:58:14 2016
From: robh+dt at kernel.org (Rob Herring)
Date: Mon, 22 Feb 2016 13:58:14 -0600
Subject: [PATCH] dma: mv_xor_v2: new driver
In-Reply-To: <20160222101621.4f03ef8b@free-electrons.com>
References: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160222032730.GU19598@localhost>
 <20160222101621.4f03ef8b@free-electrons.com>
Message-ID: <CAL_Jsq+bYmafQWasY1T2QG6Dujf7Ki6JSZKZoFzJXAphTAvnCA@mail.gmail.com>

On Mon, Feb 22, 2016 at 3:16 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Hello Vinod,
>
> On Mon, 22 Feb 2016 08:57:30 +0530, Vinod Koul wrote:
>> On Mon, Feb 15, 2016 at 08:58:03AM +0100, Thomas Petazzoni wrote:
>> > diff --git a/Documentation/devicetree/bindings/dma/mv-xor-v2.txt b/Documentation/devicetree/bindings/dma/mv-xor-v2.txt
>> > new file mode 100644
>> > index 0000000..0a03dcf
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/dma/mv-xor-v2.txt
>> > @@ -0,0 +1,19 @@
>> > +* Marvell XOR v2 engines
>> > +
>> > +Required properties:
>> > +- compatible: Should be "marvell,mv-xor-v2"
>> > +- reg: Should contain registers location and length (two sets)
>> > +    the first set is the DMA registers
>> > +    the second set is the global registers
>> > +- msi-parent: Phandle to the MSI-capable interrupt controller used for
>> > +  interrupts.
>> > +
>> > +Example:
>> > +
>> > +   xor0 at 400000 {
>> > +           compatible = "marvell,mv-xor-v2";
>> > +           reg = <0x400000 0x1000>,
>> > +                 <0x410000 0x1000>;
>> > +           msi-parent = <&gic_v2m0>;
>> > +           dma-coherent;
>> > +   };
>>
>> This should be a separate patch :)
>
> This is really a personal preference, and different maintainers have
> different opinions on the matter. However, if your preference is to
> have the DT binding documentation as a separate patch, then I'll split
> it, no problem :)

Read step 1 in Documentation/devicetree/bindings/submitting-patches.txt.

Rob


From linux at arm.linux.org.uk  Mon Feb 22 12:02:27 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Mon, 22 Feb 2016 20:02:27 +0000
Subject: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB
 mappings
In-Reply-To: <CAKv+Gu9OWVgo+Qm85jPjY7xJ1UELm-4LYORHKF8Yy+_HuzmtGw@mail.gmail.com>
References: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456149728-16706-2-git-send-email-ard.biesheuvel@linaro.org>
 <CAPcyv4ivN9c8PHBR77vd36ovB28OETJUr6VYf_8gNtXgqEmATw@mail.gmail.com>
 <CAKv+Gu9OWVgo+Qm85jPjY7xJ1UELm-4LYORHKF8Yy+_HuzmtGw@mail.gmail.com>
Message-ID: <20160222200227.GF19428@n2100.arm.linux.org.uk>

On Mon, Feb 22, 2016 at 08:17:11PM +0100, Ard Biesheuvel wrote:
> I am not exactly sure why ioremap_cache() does not use MT_MEMORY_RW
> attributes, but the ARM architecture simply does not allow mismatched
> attributes, so we cannot simply replace each instance of
> ioremap_cache() with memremap()
> 
> Perhaps Russell can explain?

ARM has had ioremap_cached() for a while - it was introduced in the
bitkeeper times of 2.6, so pre-git.  In those kernels, and into the
git era, pre-dating ARMv6 support, it was merely:

+#define ioremap_cached(cookie,size)    __arch_ioremap((cookie),(size),L_PTE_CACHEABLE)

which means that we got write-through cache behaviour for mappings
created by this, where supported, or if not, read-allocate writeback.
This was completely independent of the system memory mapping
attributes, which could be specified on the kernel command line.

This was originally used by pxa2xx-flash to provide faster flash
access on those systems - in other words, it's created to remap
devices with cacheable attributes.

When creating ARMv6 support, I ended up completely rewriting how
the memory attributes were handled, and so it then became this:

+#define ioremap_cached(cookie,size)    __arch_ioremap((cookie), (size), MT_DEVICE_CACHED)

which gives very similar behaviour, though we now default to RAWB
mappings, which fall back to WT on CPUs that don't support RAWB.
Again, independent of the system memory mapping.

Then, in 2013, with the advent of Xen, ioremap_cached() became
ioremap_cache() so that Xen would build on ARM, and to align it
with other architectures.  Whether ioremap_cached() actually was
suitable to become ioremap_cache(), I'm not sure, but that's
what happened.

Since it was just renamed, it preserves the original goal which is
to remap device memory with cacheable attributes, which may differ
from the cacheable attributes of the system RAM.  It has never
been intended for remapping system memory: none of the ioremap_*
family of functions on ARM were ever intended for that purpose.

However, some people did use it for that purpose on ARMv5 and
earlier architectures, where, due to the virtual cache architecture,
you could get away with remapping the same memory with differing
attributes without any problem.  With the advent of ARMv6
(pre-dating 2013), this was clearly stated as being illegal at
architecture level, but people were married to the idea - despite
me telling them not to.

So eventually, I had no other option than to add a code check to
ioremap*() which prevents any ioremap*() function from being used
on system memory - iow, memory that Linux maps itself either as
part of lowmem or via the kmap*() API - since an ioremap*()
mapping would conflict with those.

That's basically where we are today: ioremap*() does not permit
system memory to be remapped, even ioremap_cache().

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From robh at kernel.org  Mon Feb 22 12:02:37 2016
From: robh at kernel.org (Rob Herring)
Date: Mon, 22 Feb 2016 14:02:37 -0600
Subject: [PATCH] dma: mv_xor_v2: new driver
In-Reply-To: <20160222082130.75e9c540@free-electrons.com>
References: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160222025349.GC15973@rob-hp-laptop>
 <20160222082130.75e9c540@free-electrons.com>
Message-ID: <CAL_JsqLb_j+DjfggdDKf8OqheaAqzyDpt1EECQ7XrGqAHoTCnw@mail.gmail.com>

On Mon, Feb 22, 2016 at 1:21 AM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Rob,
>
> On Sun, 21 Feb 2016 20:53:49 -0600, Rob Herring wrote:
>
>> > +Required properties:
>> > +- compatible: Should be "marvell,mv-xor-v2"
>>
>> and an SoC specific compatible please.
>
> So you mean *both* marvell,mv-xor-v2 and a SoC specific compatible?

Yes. Well, really I'd like to see only SoC specific compatibles, but
everyone likes to have their generic ones for matching since it's
always "the same hardware".

Rob


From ps.report at gmx.net  Mon Feb 22 12:03:41 2016
From: ps.report at gmx.net (Peter Seiderer)
Date: Mon, 22 Feb 2016 21:03:41 +0100
Subject: [PATCH v1] ARM: dts: nitrogen6x: add USB host 1 support
Message-ID: <1456171421-10044-1-git-send-email-ps.report@gmx.net>

Regulator stuff and pin configuration copied from imx6qdl-nitrogen6_max.dtsi
and checked against Boundary Devices linux kernel tree ([1]).

[1] https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.14.28_1.0.0_ga/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi

Signed-off-by: Peter Seiderer <ps.report at gmx.net>
---
 arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 25 ++++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index c6c590d..81f8c5c 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -85,9 +85,21 @@
 			enable-active-high;
 		};
 
-		reg_can_xcvr: regulator at 3 {
+		reg_usb_h1_vbus: regulator at 3 {
 			compatible = "regulator-fixed";
 			reg = <3>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_usbh1>;
+			regulator-name = "usb_h1_vbus";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
+			enable-active-high;
+		};
+
+		reg_can_xcvr: regulator at 4 {
+			compatible = "regulator-fixed";
+			reg = <4>;
 			regulator-name = "CAN XCVR";
 			regulator-min-microvolt = <3300000>;
 			regulator-max-microvolt = <3300000>;
@@ -96,9 +108,9 @@
 			gpio = <&gpio1 2 GPIO_ACTIVE_LOW>;
 		};
 
-		reg_wlan_vmmc: regulator at 4 {
+		reg_wlan_vmmc: regulator at 5 {
 			compatible = "regulator-fixed";
-			reg = <4>;
+			reg = <5>;
 			pinctrl-names = "default";
 			pinctrl-0 = <&pinctrl_wlan_vmmc>;
 			regulator-name = "reg_wlan_vmmc";
@@ -515,6 +527,12 @@
 			>;
 		};
 
+		pinctrl_usbh1: usbh1grp {
+			fsl,pins = <
+				MX6QDL_PAD_GPIO_17__GPIO7_IO12          0x0b0b0
+			>;
+		};
+
 		pinctrl_usbotg: usbotggrp {
 			fsl,pins = <
 				MX6QDL_PAD_GPIO_1__USB_OTG_ID	0x17059
@@ -632,6 +650,7 @@
 };
 
 &usbh1 {
+	vbus-supply = <&reg_usb_h1_vbus>;
 	status = "okay";
 };
 
-- 
2.1.4



From albeu at free.fr  Mon Feb 22 12:13:23 2016
From: albeu at free.fr (Alban)
Date: Mon, 22 Feb 2016 21:13:23 +0100
Subject: [PATCH 10/61] gpio: ath79: Use devm_gpiochip_add_data() for
 gpio registration
In-Reply-To: <1456150130-2668-11-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
 <1456150130-2668-11-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160222211323.5c10533f@tock>

On Mon, 22 Feb 2016 19:37:59 +0530
Laxman Dewangan <ldewangan at nvidia.com> wrote:

> Use devm_gpiochip_add_data() for GPIO registration.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Alban Bedel <albeu at free.fr>
> ---
>  drivers/gpio/gpio-ath79.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpio-ath79.c b/drivers/gpio/gpio-ath79.c
> index d13dd13..a6aad59 100644
> --- a/drivers/gpio/gpio-ath79.c
> +++ b/drivers/gpio/gpio-ath79.c
> @@ -182,7 +182,7 @@ static int ath79_gpio_probe(struct platform_device *pdev)
>  		ctrl->chip.direction_output = ar934x_gpio_direction_output;
>  	}
>  
> -	err = gpiochip_add_data(&ctrl->chip, ctrl);
> +	err = devm_gpiochip_add_data(&pdev->dev, &ctrl->chip, ctrl);
>  	if (err) {
>  		dev_err(&pdev->dev,
>  			"cannot add AR71xx GPIO chip, error=%d", err);

With the patches already applied to the devel branch a few more changes
will be needed to remove the calls to gpiochip_remove() in the probe
error path and the remove callback.

Alban


From mturquette at baylibre.com  Mon Feb 22 12:23:20 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Mon, 22 Feb 2016 12:23:20 -0800
Subject: [PATCH 2/3] clk: mvebu: add AP806 core clock driver
In-Reply-To: <CAL_Jsq+iiUBcTdnqzFWLJ+5jPvq0rmWgBboab4xyj1dQyDQE+Q@mail.gmail.com>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455521698-7905-3-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160222025357.GE15973@rob-hp-laptop>
 <20160222091423.4756a579@free-electrons.com> <20160222141617.GA14970@lunn.ch>
 <20160222183203.2278.60153@quark.deferred.io>
 <CAL_Jsq+iiUBcTdnqzFWLJ+5jPvq0rmWgBboab4xyj1dQyDQE+Q@mail.gmail.com>
Message-ID: <20160222202320.2278.62793@quark.deferred.io>

Quoting Rob Herring (2016-02-22 11:42:49)
> On Mon, Feb 22, 2016 at 12:32 PM, Michael Turquette
> <mturquette at baylibre.com> wrote:
> > Quoting Andrew Lunn (2016-02-22 06:16:17)
> >> > Such information will come later, and we can rework the drivers and DT
> >> > bindings accordingly. Those DT bindings cannot be stable, as the
> >> > platform is under heavy development and we'll probably discover some
> >> > issues down the road.
> >>
> >> Hi Thomas
> >>
> >> Maybe add a big fat warning that the bindings are unstable, and the DT
> >> blob must be kept in sync with the kernel?
> >
> > +1 and feel free to blame the lack of documentation.  No one can expect
> > bindings to be finalized when the chip topology is not fully understood.
> 
> I can understand not understanding the full clock tree. I have "full"
> documentation of a Marvell chip and don't understand the clock tree
> fully. But I can't believe you don't have some sense of how many
> clocks you have to deal with. 10? 100? 1000? What I see is 2 nodes of
> a single register each for clocks at roughly the same address. That
> tells me your binding is too fine grained. If you really don't know
> what is right, then err on the side of a single clock provider node
> and don't put the clock details in DT.

I like the "err on the side of caution" part. I'll add that to
clock-bindings.txt.

Regards,
Mike

> 
> Rob


From ard.biesheuvel at linaro.org  Mon Feb 22 12:35:24 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 21:35:24 +0100
Subject: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB
 mappings
In-Reply-To: <20160222200227.GF19428@n2100.arm.linux.org.uk>
References: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456149728-16706-2-git-send-email-ard.biesheuvel@linaro.org>
 <CAPcyv4ivN9c8PHBR77vd36ovB28OETJUr6VYf_8gNtXgqEmATw@mail.gmail.com>
 <CAKv+Gu9OWVgo+Qm85jPjY7xJ1UELm-4LYORHKF8Yy+_HuzmtGw@mail.gmail.com>
 <20160222200227.GF19428@n2100.arm.linux.org.uk>
Message-ID: <CAKv+Gu9gwnuu7hnYpjv7ozuKYmC8ApMakSJmYvQMaevNEd5zvA@mail.gmail.com>

On 22 February 2016 at 21:02, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Mon, Feb 22, 2016 at 08:17:11PM +0100, Ard Biesheuvel wrote:
>> I am not exactly sure why ioremap_cache() does not use MT_MEMORY_RW
>> attributes, but the ARM architecture simply does not allow mismatched
>> attributes, so we cannot simply replace each instance of
>> ioremap_cache() with memremap()
>>
>> Perhaps Russell can explain?
>
> ARM has had ioremap_cached() for a while - it was introduced in the
> bitkeeper times of 2.6, so pre-git.  In those kernels, and into the
> git era, pre-dating ARMv6 support, it was merely:
>
> +#define ioremap_cached(cookie,size)    __arch_ioremap((cookie),(size),L_PTE_CACHEABLE)
>
> which means that we got write-through cache behaviour for mappings
> created by this, where supported, or if not, read-allocate writeback.
> This was completely independent of the system memory mapping
> attributes, which could be specified on the kernel command line.
>
> This was originally used by pxa2xx-flash to provide faster flash
> access on those systems - in other words, it's created to remap
> devices with cacheable attributes.
>
> When creating ARMv6 support, I ended up completely rewriting how
> the memory attributes were handled, and so it then became this:
>
> +#define ioremap_cached(cookie,size)    __arch_ioremap((cookie), (size), MT_DEVICE_CACHED)
>
> which gives very similar behaviour, though we now default to RAWB
> mappings, which fall back to WT on CPUs that don't support RAWB.
> Again, independent of the system memory mapping.
>
> Then, in 2013, with the advent of Xen, ioremap_cached() became
> ioremap_cache() so that Xen would build on ARM, and to align it
> with other architectures.  Whether ioremap_cached() actually was
> suitable to become ioremap_cache(), I'm not sure, but that's
> what happened.
>
> Since it was just renamed, it preserves the original goal which is
> to remap device memory with cacheable attributes, which may differ
> from the cacheable attributes of the system RAM.  It has never
> been intended for remapping system memory: none of the ioremap_*
> family of functions on ARM were ever intended for that purpose.
>
> However, some people did use it for that purpose on ARMv5 and
> earlier architectures, where, due to the virtual cache architecture,
> you could get away with remapping the same memory with differing
> attributes without any problem.  With the advent of ARMv6
> (pre-dating 2013), this was clearly stated as being illegal at
> architecture level, but people were married to the idea - despite
> me telling them not to.
>
> So eventually, I had no other option than to add a code check to
> ioremap*() which prevents any ioremap*() function from being used
> on system memory - iow, memory that Linux maps itself either as
> part of lowmem or via the kmap*() API - since an ioremap*()
> mapping would conflict with those.
>
> That's basically where we are today: ioremap*() does not permit
> system memory to be remapped, even ioremap_cache().
>

OK, thanks for the historical context.

So what is your opinion on this series, i.e., to wire up memremap() to
remap arbitrary memory regions into the vmalloc area with MT_MEMORY_RW
attributes, and at the same time lift the restriction that the region
must be disjoint from memory covered by lowmem or kmap?

It would make my life a lot easier, since we can more easily share
code between x86, arm64 and ARM to permanently map memory regions that
have been populated by the firmware. As I noted in the commit log,
memremap() already does the right thing wrt lowmem, i.e., it returns
the existing mapping rather than creating a new one. For highmem, I
don't think kmap() is the way to go considering the unknown size and
the potentially permanent nature of the mappings (which resemble
ioremap more than they resemble kmap)

-- 
Ard.


From frank.li at nxp.com  Mon Feb 22 12:48:19 2016
From: frank.li at nxp.com (Frank Li)
Date: Mon, 22 Feb 2016 20:48:19 +0000
Subject: iMX7d cpu1 issue
In-Reply-To: <CAOMZO5Aa+veHWQCrKGz4rsvmjKWiitd81D8ncGnX8Fdk0aYe7Q@mail.gmail.com>
References: <56C2D63F.1030408@compulab.co.il>	<20160218140913.GY6756@tiger>
 <AMSPR04MB263D00A3F8D9A8D9D3A536D88AF0@AMSPR04MB263.eurprd04.prod.outlook.com>
 <56C5F4D7.1070704@compulab.co.il>
 <AMSPR04MB26334EB884FA8A4B565278188AF0@AMSPR04MB263.eurprd04.prod.outlook.com>
 <56C6CE36.6040503@compulab.co.il>
 <CAOMZO5Aa+veHWQCrKGz4rsvmjKWiitd81D8ncGnX8Fdk0aYe7Q@mail.gmail.com>
Message-ID: <AMSPR04MB2634AA127C6397584AF6BA488A30@AMSPR04MB263.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Fabio Estevam [mailto:festevam at gmail.com]
> Sent: Sunday, February 21, 2016 9:23 AM
> To: Ilya Ledvich <ilya at compulab.co.il>
> Cc: Frank Li <frank.li at nxp.com>; Shawn Guo <shawnguo at kernel.org>;
> Yongcai Huang <anson.huang at nxp.com>; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: iMX7d cpu1 issue
> 
> Hi Ilya/Frank,
> 
> On Fri, Feb 19, 2016 at 6:11 AM, Ilya Ledvich <ilya at compulab.co.il> wrote:
> > Hi Frank,
> > Thank you for so brilliant suggestion!!!
> >
> >> #define CONFIG_MX7_SEC
> >
> >
> > Seems it works!
> > The  CPU1 is brought up, and kernel can successfully boot!
> 
> I changed U-boot as suggested:
> 
> --- a/include/configs/mx7_common.h
> +++ b/include/configs/mx7_common.h
> @@ -94,10 +94,7 @@
>  #define CONFIG_CMD_FUSE
>  #define CONFIG_MXC_OCOTP
> 
> -/*
> - * Default boot linux kernel in no secure mode.
> - * If want to boot kernel in secure mode, please define CONFIG_MX7_SEC
> - */
> +#define CONFIG_MX7_SEC

Upstream kernel use PSCI to enable second core.  You can't define CONFIG_MX7_SEC. 

NXP released kernel use legacy method, which require kernel run in security mode. So you have to define CONFIG_MX7_SEC.

Best regards
Frank Li

>  #ifndef CONFIG_MX7_SEC
>  #define CONFIG_ARMV7_NONSEC
>  #define CONFIG_ARMV7_PSCI
> 
> 
> but still see only one core brought up in the kernel:
> 
> [    0.003051] /cpus/cpu at 0 missing clock-frequency property
> [    0.003076] /cpus/cpu at 1 missing clock-frequency property
> [    0.003092] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> [    0.003157] Setting up static identity map for 0x80008280 - 0x800082f0
> [    0.005152] Brought up 1 CPUs
> [    0.005169] SMP: Total of 1 processors activated (48.00 BogoMIPS).
> 
> I am booting 4.5-rc5 on a imx7d-sdb board.
> 
> Any ideas on how to bring up the second core?

From troy.kisky at boundarydevices.com  Mon Feb 22 12:48:56 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Mon, 22 Feb 2016 13:48:56 -0700
Subject: [PATCH v1] ARM: dts: nitrogen6x: add USB host 1 support
In-Reply-To: <1456171421-10044-1-git-send-email-ps.report@gmx.net>
References: <1456171421-10044-1-git-send-email-ps.report@gmx.net>
Message-ID: <56CB7438.5030102@boundarydevices.com>

On 2/22/2016 1:03 PM, Peter Seiderer wrote:
> Regulator stuff and pin configuration copied from imx6qdl-nitrogen6_max.dtsi
> and checked against Boundary Devices linux kernel tree ([1]).
> 
> [1] https://github.com/boundarydevices/linux-imx6/blob/boundary-imx_3.14.28_1.0.0_ga/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> 
> Signed-off-by: Peter Seiderer <ps.report at gmx.net>
> ---
>  arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 25 ++++++++++++++++++++++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> index c6c590d..81f8c5c 100644
> --- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> @@ -85,9 +85,21 @@
>  			enable-active-high;
>  		};
>  
> -		reg_can_xcvr: regulator at 3 {
> +		reg_usb_h1_vbus: regulator at 3 {
>  			compatible = "regulator-fixed";
>  			reg = <3>;
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pinctrl_usbh1>;
> +			regulator-name = "usb_h1_vbus";
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3300000>;
> +			gpio = <&gpio7 12 GPIO_ACTIVE_HIGH>;
> +			enable-active-high;
> +		};
> +
> +		reg_can_xcvr: regulator at 4 {
> +			compatible = "regulator-fixed";
> +			reg = <4>;
>  			regulator-name = "CAN XCVR";
>  			regulator-min-microvolt = <3300000>;
>  			regulator-max-microvolt = <3300000>;
> @@ -96,9 +108,9 @@
>  			gpio = <&gpio1 2 GPIO_ACTIVE_LOW>;
>  		};
>  
> -		reg_wlan_vmmc: regulator at 4 {
> +		reg_wlan_vmmc: regulator at 5 {
>  			compatible = "regulator-fixed";
> -			reg = <4>;
> +			reg = <5>;
>  			pinctrl-names = "default";
>  			pinctrl-0 = <&pinctrl_wlan_vmmc>;
>  			regulator-name = "reg_wlan_vmmc";
> @@ -515,6 +527,12 @@
>  			>;
>  		};
>  
> +		pinctrl_usbh1: usbh1grp {
> +			fsl,pins = <
> +				MX6QDL_PAD_GPIO_17__GPIO7_IO12          0x0b0b0




I'm ok with this patch, but a more correct fix would be to add a
reset-gpios to usbh1 instead, as this is a reset pin for
a usb hub. So if nobody else has a problem,

Acked-by: Troy Kisky <troy.kisky at boundarydevices.com>


> +			>;
> +		};
> +
>  		pinctrl_usbotg: usbotggrp {
>  			fsl,pins = <
>  				MX6QDL_PAD_GPIO_1__USB_OTG_ID	0x17059
> @@ -632,6 +650,7 @@
>  };
>  
>  &usbh1 {
> +	vbus-supply = <&reg_usb_h1_vbus>;
>  	status = "okay";
>  };
>  
> 


From arnd at arndb.de  Mon Feb 22 12:50:39 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Feb 2016 21:50:39 +0100
Subject: [PATCH] netcp: fix typo in netcp_setup_tc
Message-ID: <1456174246-293822-1-git-send-email-arnd@arndb.de>

A change to the prototype of netcp_setup_tc() missed a '*'
character, which broke compilation of hte netcp driver:

drivers/net/ethernet/ti/netcp_core.c: In function 'netcp_setup_tc':
drivers/net/ethernet/ti/netcp_core.c:1839:31: error: invalid type argument of '->' (have 'struct tc_to_netdev')
drivers/net/ethernet/ti/netcp_core.c:1872:19: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 16e5cc647173 ("net: rework setup_tc ndo op to consume general tc operand")
---
 drivers/net/ethernet/ti/netcp_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/ti/netcp_core.c b/drivers/net/ethernet/ti/netcp_core.c
index 132caebb401a..e74e68eabd5f 100644
--- a/drivers/net/ethernet/ti/netcp_core.c
+++ b/drivers/net/ethernet/ti/netcp_core.c
@@ -1829,7 +1829,7 @@ static u16 netcp_select_queue(struct net_device *dev, struct sk_buff *skb,
 }
 
 static int netcp_setup_tc(struct net_device *dev, u32 handle, __be16 proto,
-			  struct tc_to_netdev tc)
+			  struct tc_to_netdev *tc)
 {
 	int i;
 
-- 
2.7.0



From davem at davemloft.net  Mon Feb 22 12:52:21 2016
From: davem at davemloft.net (David Miller)
Date: Mon, 22 Feb 2016 15:52:21 -0500 (EST)
Subject: [PATCH] netcp: fix typo in netcp_setup_tc
In-Reply-To: <1456174246-293822-1-git-send-email-arnd@arndb.de>
References: <1456174246-293822-1-git-send-email-arnd@arndb.de>
Message-ID: <20160222.155221.1930653393972032546.davem@davemloft.net>

From: Arnd Bergmann <arnd at arndb.de>
Date: Mon, 22 Feb 2016 21:50:39 +0100

> A change to the prototype of netcp_setup_tc() missed a '*'
> character, which broke compilation of hte netcp driver:
> 
> drivers/net/ethernet/ti/netcp_core.c: In function 'netcp_setup_tc':
> drivers/net/ethernet/ti/netcp_core.c:1839:31: error: invalid type argument of '->' (have 'struct tc_to_netdev')
> drivers/net/ethernet/ti/netcp_core.c:1872:19: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 16e5cc647173 ("net: rework setup_tc ndo op to consume general tc operand")

Should be fixed in my net-next tree already.

Thanks.


From festevam at gmail.com  Mon Feb 22 12:53:41 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 22 Feb 2016 17:53:41 -0300
Subject: [PATCH v1] ARM: dts: nitrogen6x: add USB host 1 support
In-Reply-To: <56CB7438.5030102@boundarydevices.com>
References: <1456171421-10044-1-git-send-email-ps.report@gmx.net>
 <56CB7438.5030102@boundarydevices.com>
Message-ID: <CAOMZO5BoPtUfL6PVzqLkZvwvn4=zNTTYgR1u4TOe4268cu+WLg@mail.gmail.com>

On Mon, Feb 22, 2016 at 5:48 PM, Troy Kisky
<troy.kisky at boundarydevices.com> wrote:

> I'm ok with this patch, but a more correct fix would be to add a
> reset-gpios to usbh1 instead, as this is a reset pin for
> a usb hub. So if nobody else has a problem,

The problem is that such solution does not exist today.

Peter Chen has been working on it lately.


From ard.biesheuvel at linaro.org  Mon Feb 22 12:54:22 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 21:54:22 +0100
Subject: [RFC PATCH 00/10] arm64: restrict __pa translation to linear virtual
 addresses
Message-ID: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>

As pointed out by Will, performing non-trivial arithmetic in the implementation
of __pa() may affect performance. So instead of allowing __pa() to deal with
addresses that are either covered by the kernel mappin in the vmalloc area, or
by the linear region, let's restrict ourselves to the latter.

This involves replacing some __pa() translations with a specific translation
for kernel symbols (__pa_symbol), but other than that it is fairly
straightforward (except KASAN is being a pain again, but for the purpose of this
discussion that should not matter too much)

Patch #1 is a fix for a bug that I spotted  while working on this.

Patch #2 introduces the new translations __kimg_to_phys and __pa_symbol. They
do exactly the same but the former matches the existing __phys_to_kimg, and the
latter already exists on x86 as well for translating 'symbols visible to C code'

Patch #3 - #9 replace various instances of __pa() translations involving virtual
addresses pointing into the kernel image.

Patch #10 finally removes the comparison against PAGE_OFFSET from the
implementation of __virt_to_phys(), so that it can only be used for addresses
that are known to be in the linear region.

git://git.linaro.org/people/ard.biesheuvel/linux-arm.git arm64-pa-linear-mapping

Ard Biesheuvel (10):
  arm64: mm: move assignment of 'high_memory' before its first use
  arm64: introduce __kimg_to_phys() and __pa_symbol()
  arm64: mm: avoid __pa translations in cpu_replace_ttbr1
  arm64: mm: avoid __pa translations on empty_zero_page
  arm64: mm: avoid __pa translations in early_fixmap_init
  arm64: mm: use __pa_symbol() not __pa() for section boundary symbols
  arm64: mm: avoid __pa translations for idmap_pg_dir and swapper_pg_dir
  arm64: vdso: avoid __pa translations
  arm64: insn: avoid __pa translations
  arm64: mm: restrict __pa() translations to linear virtual addresses

 arch/arm64/include/asm/memory.h      | 15 ++++++++----
 arch/arm64/include/asm/mmu_context.h | 10 ++++----
 arch/arm64/include/asm/pgalloc.h     |  2 --
 arch/arm64/include/asm/pgtable.h     |  2 +-
 arch/arm64/kernel/insn.c             |  2 +-
 arch/arm64/kernel/setup.c            |  8 +++----
 arch/arm64/kernel/vdso.c             |  5 ++--
 arch/arm64/mm/init.c                 | 13 +++++++----
 arch/arm64/mm/mmu.c                  | 24 ++++++++++----------
 9 files changed, 43 insertions(+), 38 deletions(-)

-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 12:54:24 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 21:54:24 +0100
Subject: [RFC PATCH 02/10] arm64: introduce __kimg_to_phys() and __pa_symbol()
In-Reply-To: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456174472-30028-3-git-send-email-ard.biesheuvel@linaro.org>

Before restricting the domain of __pa()'s argument to the linear mapping,
introduce alternatives __kimg_to_phys() and its alias __pa_symbol() [of
which the latter exists on x86 as well] that can be used to obtain the
physical address of a static object or function in the kernel text.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/memory.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 2296b32130a1..56d6739430f3 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -92,7 +92,10 @@
 				 (__x - kimage_voffset); })
 
 #define __phys_to_virt(x)	((unsigned long)((x) - PHYS_OFFSET) | PAGE_OFFSET)
+
+#define __kimg_to_phys(x)	((phys_addr_t)(x) - kimage_voffset)
 #define __phys_to_kimg(x)	((unsigned long)((x) + kimage_voffset))
+#define __pa_symbol(x)		__kimg_to_phys(x)
 
 /*
  * Convert a page to/from a physical address
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 12:54:25 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 21:54:25 +0100
Subject: [RFC PATCH 03/10] arm64: mm: avoid __pa translations in
 cpu_replace_ttbr1
In-Reply-To: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456174472-30028-4-git-send-email-ard.biesheuvel@linaro.org>

Avoid the use of generic __pa() translations in cpu_replace_ttbr1(),
by changing its argument to a physical pgd[] address, and using
__pa_symbol() on the reference to swapper_pg_dir.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/mmu_context.h | 6 ++----
 arch/arm64/mm/mmu.c                  | 4 ++--
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index a00f7cf35bbd..40fc56f3ed52 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -130,15 +130,13 @@ static inline void cpu_install_idmap(void)
  * Atomically replaces the active TTBR1_EL1 PGD with a new VA-compatible PGD,
  * avoiding the possibility of conflicting TLB entries being allocated.
  */
-static inline void cpu_replace_ttbr1(pgd_t *pgd)
+static inline void cpu_replace_ttbr1(phys_addr_t pgd_phys)
 {
 	typedef void (ttbr_replace_func)(phys_addr_t);
 	extern ttbr_replace_func idmap_cpu_replace_ttbr1;
 	ttbr_replace_func *replace_phys;
 
-	phys_addr_t pgd_phys = virt_to_phys(pgd);
-
-	replace_phys = (void *)virt_to_phys(idmap_cpu_replace_ttbr1);
+	replace_phys = (void *)__pa_symbol(idmap_cpu_replace_ttbr1);
 
 	cpu_install_idmap();
 	replace_phys(pgd_phys);
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 00d166465ff4..fbba941a6e87 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -546,9 +546,9 @@ void __init paging_init(void)
 	 *
 	 * To do this we need to go via a temporary pgd.
 	 */
-	cpu_replace_ttbr1(__va(pgd_phys));
+	cpu_replace_ttbr1(pgd_phys);
 	memcpy(swapper_pg_dir, pgd, PAGE_SIZE);
-	cpu_replace_ttbr1(swapper_pg_dir);
+	cpu_replace_ttbr1(__pa_symbol(swapper_pg_dir));
 
 	pgd_clear_fixmap();
 	memblock_free(pgd_phys, PAGE_SIZE);
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 12:54:26 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 21:54:26 +0100
Subject: [RFC PATCH 04/10] arm64: mm: avoid __pa translations on
 empty_zero_page
In-Reply-To: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456174472-30028-5-git-send-email-ard.biesheuvel@linaro.org>

The variable empty_zero_page is part of the static kernel text, so we
should use __pa_symbol() not __pa() to take its physical address.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/mmu_context.h | 2 +-
 arch/arm64/include/asm/pgtable.h     | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index 40fc56f3ed52..b03272fc501e 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -49,7 +49,7 @@ static inline void contextidr_thread_switch(struct task_struct *next)
  */
 static inline void cpu_set_reserved_ttbr0(void)
 {
-	unsigned long ttbr = virt_to_phys(empty_zero_page);
+	unsigned long ttbr = __pa_symbol(empty_zero_page);
 
 	asm(
 	"	msr	ttbr0_el1, %0			// set TTBR0\n"
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index a440f5a85d08..528482f53f12 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -117,7 +117,7 @@ extern void __pgd_error(const char *file, int line, unsigned long val);
  * for zero-mapped memory areas etc..
  */
 extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
-#define ZERO_PAGE(vaddr)	virt_to_page(empty_zero_page)
+#define ZERO_PAGE(vaddr)	phys_to_page(__pa_symbol(empty_zero_page))
 
 #define pte_ERROR(pte)		__pte_error(__FILE__, __LINE__, pte_val(pte))
 
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 12:54:23 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 21:54:23 +0100
Subject: [RFC PATCH 01/10] arm64: mm: move assignment of 'high_memory' before
 its first use
In-Reply-To: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456174472-30028-2-git-send-email-ard.biesheuvel@linaro.org>

The variable 'high_memory' ends up being referenced in the call to
dma_contiguous_reserve(). So move the assignment before that call.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/mm/init.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index e1f425fe5a81..017201982da3 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -235,6 +235,9 @@ void __init arm64_memblock_init(void)
 		arm64_dma_phys_limit = max_zone_dma_phys();
 	else
 		arm64_dma_phys_limit = PHYS_MASK + 1;
+
+	high_memory = __va((memblock_end_of_DRAM() & PAGE_MASK) - 1) + 1;
+
 	dma_contiguous_reserve(arm64_dma_phys_limit);
 
 	memblock_allow_resize();
@@ -259,7 +262,6 @@ void __init bootmem_init(void)
 	sparse_init();
 	zone_sizes_init(min, max);
 
-	high_memory = __va((max << PAGE_SHIFT) - 1) + 1;
 	max_pfn = max_low_pfn = max;
 }
 
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 12:54:27 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 21:54:27 +0100
Subject: [RFC PATCH 05/10] arm64: mm: avoid __pa translations in
 early_fixmap_init
In-Reply-To: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456174472-30028-6-git-send-email-ard.biesheuvel@linaro.org>

Avoid using __pa() translations while populating the fixmap page tables,
by using __pa_symbol to take the physical addresses of bm_pud, bm_pmd and
bm_pte, and move to __pgd_populate/__pmd_populate/__pte_populate, which
takes physical addresses directly. Since the former two are now called
unconditionally, remove the BUILD_BUG()'s that prevent their use in case
their page table level is folded away.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/pgalloc.h | 2 --
 arch/arm64/mm/mmu.c              | 8 ++++----
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index ff98585d085a..bc01d2b65225 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -54,7 +54,6 @@ static inline void pud_populate(struct mm_struct *mm, pud_t *pud, pmd_t *pmd)
 #else
 static inline void __pud_populate(pud_t *pud, phys_addr_t pmd, pudval_t prot)
 {
-	BUILD_BUG();
 }
 #endif	/* CONFIG_PGTABLE_LEVELS > 2 */
 
@@ -83,7 +82,6 @@ static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
 #else
 static inline void __pgd_populate(pgd_t *pgdp, phys_addr_t pud, pgdval_t prot)
 {
-	BUILD_BUG();
 }
 #endif	/* CONFIG_PGTABLE_LEVELS > 3 */
 
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index fbba941a6e87..e7340defa085 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -679,7 +679,7 @@ void __init early_fixmap_init(void)
 
 	pgd = pgd_offset_k(addr);
 	if (CONFIG_PGTABLE_LEVELS > 3 &&
-	    !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa(bm_pud))) {
+	    !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa_symbol(bm_pud))) {
 		/*
 		 * We only end up here if the kernel mapping and the fixmap
 		 * share the top level pgd entry, which should only happen on
@@ -688,12 +688,12 @@ void __init early_fixmap_init(void)
 		BUG_ON(!IS_ENABLED(CONFIG_ARM64_16K_PAGES));
 		pud = pud_offset_kimg(pgd, addr);
 	} else {
-		pgd_populate(&init_mm, pgd, bm_pud);
+		__pgd_populate(pgd, __pa_symbol(bm_pud), PUD_TYPE_TABLE);
 		pud = fixmap_pud(addr);
 	}
-	pud_populate(&init_mm, pud, bm_pmd);
+	__pud_populate(pud, __pa_symbol(bm_pmd), PUD_TYPE_TABLE);
 	pmd = fixmap_pmd(addr);
-	pmd_populate_kernel(&init_mm, pmd, bm_pte);
+	__pmd_populate(pmd, __pa_symbol(bm_pte), PMD_TYPE_TABLE);
 
 	/*
 	 * The boot-ioremap range spans multiple pmds, for which
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 12:54:30 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 21:54:30 +0100
Subject: [RFC PATCH 08/10] arm64: vdso: avoid __pa translations
In-Reply-To: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456174472-30028-9-git-send-email-ard.biesheuvel@linaro.org>

Use __pa_symbol() not __pa() when taking the physical address of the
VDSO symbols that are part of the kernel text.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/kernel/vdso.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 97bc68f4c689..065756b358b4 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -131,11 +131,12 @@ static int __init vdso_init(void)
 		return -ENOMEM;
 
 	/* Grab the vDSO data page. */
-	vdso_pagelist[0] = virt_to_page(vdso_data);
+	vdso_pagelist[0] = phys_to_page(__pa_symbol(vdso_data));
 
 	/* Grab the vDSO code pages. */
 	for (i = 0; i < vdso_pages; i++)
-		vdso_pagelist[i + 1] = virt_to_page(&vdso_start + i * PAGE_SIZE);
+		vdso_pagelist[i + 1] = phys_to_page(__pa_symbol(&vdso_start) +
+						    i * PAGE_SIZE);
 
 	/* Populate the special mapping structures */
 	vdso_spec[0] = (struct vm_special_mapping) {
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 12:54:32 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 21:54:32 +0100
Subject: [RFC PATCH 10/10] arm64: mm: restrict __pa() translations to linear
 virtual addresses
In-Reply-To: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456174472-30028-11-git-send-email-ard.biesheuvel@linaro.org>

Now that we have replaced all occurrences of __pa() translations
involving virtual addresses that are covered by the kernel text,
we can redefine __virt_to_phys and __pa() etc to only take virtual
address that are covered by the linear mapping. This means we can
remove the comparison with PAGE_OFFSET in the definition of
__virt_to_phys().

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/memory.h | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 56d6739430f3..3b5dc5b243ac 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -86,11 +86,14 @@
  * private definitions which should NOT be used outside memory.h
  * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
  */
-#define __virt_to_phys(x) ({						\
+#ifndef CONFIG_DEBUG_VM
+#define __virt_to_phys(x)	(((phys_addr_t)(x) & ~PAGE_OFFSET) + PHYS_OFFSET)
+#else
+#define __virt_to_phys(x)	({					\
 	phys_addr_t __x = (phys_addr_t)(x);				\
-	__x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET :	\
-				 (__x - kimage_voffset); })
-
+	BUG_ON(__x < PAGE_OFFSET);					\
+	(((phys_addr_t)__x & ~PAGE_OFFSET) + PHYS_OFFSET); })
+#endif
 #define __phys_to_virt(x)	((unsigned long)((x) - PHYS_OFFSET) | PAGE_OFFSET)
 
 #define __kimg_to_phys(x)	((phys_addr_t)(x) - kimage_voffset)
@@ -134,7 +137,6 @@
 #endif
 
 #ifndef __ASSEMBLY__
-#include <linux/bitops.h>
 
 extern phys_addr_t		memstart_addr;
 /* PHYS_OFFSET - the physical address of the start of memory. */
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 12:54:31 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 21:54:31 +0100
Subject: [RFC PATCH 09/10] arm64: insn: avoid __pa translations
In-Reply-To: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456174472-30028-10-git-send-email-ard.biesheuvel@linaro.org>

When taking the physical address of something that is known to be
covered by the kernel text, use __kimg_to_phys() not virt_to_phys()

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/kernel/insn.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 7371455160e5..bc91e3c2cdb1 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -96,7 +96,7 @@ static void __kprobes *patch_map(void *addr, int fixmap)
 	if (module && IS_ENABLED(CONFIG_DEBUG_SET_MODULE_RONX))
 		page = vmalloc_to_page(addr);
 	else if (!module && IS_ENABLED(CONFIG_DEBUG_RODATA))
-		page = virt_to_page(addr);
+		page = phys_to_page(__kimg_to_phys(addr));
 	else
 		return addr;
 
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 12:54:28 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 21:54:28 +0100
Subject: [RFC PATCH 06/10] arm64: mm: use __pa_symbol() not __pa() for section
 boundary symbols
In-Reply-To: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456174472-30028-7-git-send-email-ard.biesheuvel@linaro.org>

Boundaries exported by asm/sections.h are relative to the kernel text
and not covered by the linear mapping. So use __pa_symbol() instead of
__pa() (or use __kimg_to_phys() if the virtual address is taken first)

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/kernel/setup.c |  8 ++++----
 arch/arm64/mm/init.c      |  9 +++++----
 arch/arm64/mm/mmu.c       | 10 +++++-----
 3 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 42371f69def3..bb41ebabe017 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -201,10 +201,10 @@ static void __init request_standard_resources(void)
 	struct memblock_region *region;
 	struct resource *res;
 
-	kernel_code.start   = virt_to_phys(_text);
-	kernel_code.end     = virt_to_phys(_etext - 1);
-	kernel_data.start   = virt_to_phys(_sdata);
-	kernel_data.end     = virt_to_phys(_end - 1);
+	kernel_code.start   = __pa_symbol(_text);
+	kernel_code.end     = __pa_symbol(_etext - 1);
+	kernel_data.start   = __pa_symbol(_sdata);
+	kernel_data.end     = __pa_symbol(_end - 1);
 
 	for_each_memblock(memory, region) {
 		res = alloc_bootmem_low(sizeof(*res));
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 017201982da3..af98bf85ec8e 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -181,7 +181,7 @@ void __init arm64_memblock_init(void)
 	 * linear mapping. Take care not to clip the kernel which may be
 	 * high in memory.
 	 */
-	memblock_remove(max(memstart_addr + linear_region_size, __pa(_end)),
+	memblock_remove(max(memstart_addr + linear_region_size, __pa_symbol(_end)),
 			ULLONG_MAX);
 	if (memblock_end_of_DRAM() > linear_region_size)
 		memblock_remove(0, memblock_end_of_DRAM() - linear_region_size);
@@ -193,7 +193,7 @@ void __init arm64_memblock_init(void)
 	 */
 	if (memory_limit != (phys_addr_t)ULLONG_MAX) {
 		memblock_enforce_memory_limit(memory_limit);
-		memblock_add(__pa(_text), (u64)(_end - _text));
+		memblock_add(__pa_symbol(_text), (u64)(_end - _text));
 	}
 
 	if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
@@ -217,7 +217,7 @@ void __init arm64_memblock_init(void)
 	 * Register the kernel text, kernel data, initrd, and initial
 	 * pagetables with memblock.
 	 */
-	memblock_reserve(__pa(_text), _end - _text);
+	memblock_reserve(__pa_symbol(_text), _end - _text);
 #ifdef CONFIG_BLK_DEV_INITRD
 	if (initrd_start) {
 		memblock_reserve(initrd_start, initrd_end - initrd_start);
@@ -418,7 +418,8 @@ void __init mem_init(void)
 
 void free_initmem(void)
 {
-	free_initmem_default(0);
+	free_reserved_area(__va(__pa_symbol(__init_begin)),
+			   __va(__pa_symbol(__init_end)), 0, "unused kernel");
 	fixup_init();
 }
 
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index e7340defa085..13517699bea6 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -387,8 +387,8 @@ static void create_mapping_late(phys_addr_t phys, unsigned long virt,
 
 static void __init __map_memblock(pgd_t *pgd, phys_addr_t start, phys_addr_t end)
 {
-	unsigned long kernel_start = __pa(_stext);
-	unsigned long kernel_end = __pa(_etext);
+	unsigned long kernel_start = __pa_symbol(_stext);
+	unsigned long kernel_end = __pa_symbol(_etext);
 
 	/*
 	 * Take care not to create a writable alias for the
@@ -452,7 +452,7 @@ void mark_rodata_ro(void)
 	if (!IS_ENABLED(CONFIG_DEBUG_RODATA))
 		return;
 
-	create_mapping_late(__pa(_stext), (unsigned long)_stext,
+	create_mapping_late(__pa_symbol(_stext), (unsigned long)_stext,
 				(unsigned long)_etext - (unsigned long)_stext,
 				PAGE_KERNEL_ROX);
 }
@@ -470,7 +470,7 @@ void fixup_init(void)
 static void __init map_kernel_chunk(pgd_t *pgd, void *va_start, void *va_end,
 				    pgprot_t prot, struct vm_struct *vma)
 {
-	phys_addr_t pa_start = __pa(va_start);
+	phys_addr_t pa_start = __kimg_to_phys(va_start);
 	unsigned long size = va_end - va_start;
 
 	BUG_ON(!PAGE_ALIGNED(pa_start));
@@ -517,7 +517,7 @@ static void __init map_kernel(pgd_t *pgd)
 		 */
 		BUG_ON(!IS_ENABLED(CONFIG_ARM64_16K_PAGES));
 		set_pud(pud_set_fixmap_offset(pgd, FIXADDR_START),
-			__pud(__pa(bm_pmd) | PUD_TYPE_TABLE));
+			__pud(__pa_symbol(bm_pmd) | PUD_TYPE_TABLE));
 		pud_clear_fixmap();
 	} else {
 		BUG();
-- 
2.5.0



From ard.biesheuvel at linaro.org  Mon Feb 22 12:54:29 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Mon, 22 Feb 2016 21:54:29 +0100
Subject: [RFC PATCH 07/10] arm64: mm: avoid __pa translations for idmap_pg_dir
 and swapper_pg_dir
In-Reply-To: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456174472-30028-8-git-send-email-ard.biesheuvel@linaro.org>

When taking the physical address of idmap_pg_dir or swapper_pg_dir,
which are static kernel globals, use __pa_symbol() not __pa().

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/mmu_context.h | 2 +-
 arch/arm64/mm/mmu.c                  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index b03272fc501e..a8ba62955a62 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -123,7 +123,7 @@ static inline void cpu_install_idmap(void)
 	local_flush_tlb_all();
 	cpu_set_idmap_tcr_t0sz();
 
-	cpu_switch_mm(idmap_pg_dir, &init_mm);
+	cpu_do_switch_mm(__pa_symbol(idmap_pg_dir), &init_mm);
 }
 
 /*
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 13517699bea6..980dd9cbdc19 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -557,7 +557,7 @@ void __init paging_init(void)
 	 * We only reuse the PGD from the swapper_pg_dir, not the pud + pmd
 	 * allocated with it.
 	 */
-	memblock_free(__pa(swapper_pg_dir) + PAGE_SIZE,
+	memblock_free(__pa_symbol(swapper_pg_dir) + PAGE_SIZE,
 		      SWAPPER_DIR_SIZE - PAGE_SIZE);
 
 	bootmem_init();
-- 
2.5.0



From festevam at gmail.com  Mon Feb 22 12:59:50 2016
From: festevam at gmail.com (Fabio Estevam)
Date: Mon, 22 Feb 2016 17:59:50 -0300
Subject: iMX7d cpu1 issue
In-Reply-To: <AMSPR04MB2634AA127C6397584AF6BA488A30@AMSPR04MB263.eurprd04.prod.outlook.com>
References: <56C2D63F.1030408@compulab.co.il> <20160218140913.GY6756@tiger>
 <AMSPR04MB263D00A3F8D9A8D9D3A536D88AF0@AMSPR04MB263.eurprd04.prod.outlook.com>
 <56C5F4D7.1070704@compulab.co.il>
 <AMSPR04MB26334EB884FA8A4B565278188AF0@AMSPR04MB263.eurprd04.prod.outlook.com>
 <56C6CE36.6040503@compulab.co.il>
 <CAOMZO5Aa+veHWQCrKGz4rsvmjKWiitd81D8ncGnX8Fdk0aYe7Q@mail.gmail.com>
 <AMSPR04MB2634AA127C6397584AF6BA488A30@AMSPR04MB263.eurprd04.prod.outlook.com>
Message-ID: <CAOMZO5Dp-NCktEWrMuuot3T1dV386tkSoHU_DAtBYiJQbBm33A@mail.gmail.com>

Hi Frank,

On Mon, Feb 22, 2016 at 5:48 PM, Frank Li <frank.li at nxp.com> wrote:

> Upstream kernel use PSCI to enable second core.  You can't define CONFIG_MX7_SEC.
>
> NXP released kernel use legacy method, which require kernel run in security mode. So you have to define CONFIG_MX7_SEC.

Thanks for the clarification.

With linux-next I can see the two cores brought up:

[    0.005377] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.007734] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.007862] Brought up 2 CPU


From arnd at arndb.de  Mon Feb 22 13:08:34 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Feb 2016 22:08:34 +0100
Subject: [PATCH 0/8] drm: msm: module rework
Message-ID: <1456175331-714117-1-git-send-email-arnd@arndb.de>

I saw some regressions on today's Linux-next kernel after
the Makefiles got reworked and tried to come up with a quick
fix. This ended up taking much longer, but the new version should
be cleaner and I no longer get any build errors in this
driver.

The first two patches are just preparation to avoid the
namespace problems with global symbols and the module name.

The next five patches separate out each subdirectory that has
its own Makefile into a separate loadable module.

The final patch is just a nice addon, it should work in theory
but this needs to be tested well.

	Arnd




From arnd at arndb.de  Mon Feb 22 13:08:35 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Feb 2016 22:08:35 +0100
Subject: [PATCH 1/8] drm: msm: rename hdmi symbols
In-Reply-To: <1456175331-714117-1-git-send-email-arnd@arndb.de>
References: <1456175331-714117-1-git-send-email-arnd@arndb.de>
Message-ID: <1456175331-714117-2-git-send-email-arnd@arndb.de>

Global symbols in the kernel should be prefixed by the name
of the subsystem and/or driver to avoid conflicts when all
code is built-in.

In this case, function names like 'hdmi_register' or 'hdmi_set_mode'
are way too generic for an MSM specific DRM driver, so I'm renaming
them all to msm_hdmi_* here.

I also rename a lot of the 'static' symbols along with the global
names for consistency, even though those are relatively harmless;
they might only be slightly confusing when they show up in
backtraces.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/gpu/drm/msm/hdmi/hdmi.c           |  98 +++++++++---------
 drivers/gpu/drm/msm/hdmi/hdmi.h           |  60 +++++------
 drivers/gpu/drm/msm/hdmi/hdmi_audio.c     |  10 +-
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c    |  56 +++++-----
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c |  34 +++---
 drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c      | 166 +++++++++++++++---------------
 drivers/gpu/drm/msm/hdmi/hdmi_i2c.c       |  20 ++--
 drivers/gpu/drm/msm/hdmi/hdmi_phy.c       |  56 +++++-----
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c  |   2 +-
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c  |   4 +-
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c  |   2 +-
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c  |   2 +-
 drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.c  |   2 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |   2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |   2 +-
 drivers/gpu/drm/msm/msm_drv.c             |   4 +-
 drivers/gpu/drm/msm/msm_drv.h             |  12 +--
 17 files changed, 266 insertions(+), 266 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 6002988951b4..3bcfb1ded8b3 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -21,7 +21,7 @@
 
 #include "hdmi.h"
 
-void hdmi_set_mode(struct hdmi *hdmi, bool power_on)
+void msm_hdmi_set_mode(struct hdmi *hdmi, bool power_on)
 {
 	uint32_t ctrl = 0;
 	unsigned long flags;
@@ -46,26 +46,26 @@ void hdmi_set_mode(struct hdmi *hdmi, bool power_on)
 			power_on ? "Enable" : "Disable", ctrl);
 }
 
-static irqreturn_t hdmi_irq(int irq, void *dev_id)
+static irqreturn_t msm_hdmi_irq(int irq, void *dev_id)
 {
 	struct hdmi *hdmi = dev_id;
 
 	/* Process HPD: */
-	hdmi_connector_irq(hdmi->connector);
+	msm_hdmi_connector_irq(hdmi->connector);
 
 	/* Process DDC: */
-	hdmi_i2c_irq(hdmi->i2c);
+	msm_hdmi_i2c_irq(hdmi->i2c);
 
 	/* Process HDCP: */
 	if (hdmi->hdcp_ctrl)
-		hdmi_hdcp_irq(hdmi->hdcp_ctrl);
+		msm_hdmi_hdcp_irq(hdmi->hdcp_ctrl);
 
 	/* TODO audio.. */
 
 	return IRQ_HANDLED;
 }
 
-static void hdmi_destroy(struct hdmi *hdmi)
+static void msm_hdmi_destroy(struct hdmi *hdmi)
 {
 	/*
 	 * at this point, hpd has been disabled,
@@ -75,7 +75,7 @@ static void hdmi_destroy(struct hdmi *hdmi)
 		flush_workqueue(hdmi->workq);
 		destroy_workqueue(hdmi->workq);
 	}
-	hdmi_hdcp_destroy(hdmi);
+	msm_hdmi_hdcp_destroy(hdmi);
 
 	if (hdmi->phy_dev) {
 		put_device(hdmi->phy_dev);
@@ -84,12 +84,12 @@ static void hdmi_destroy(struct hdmi *hdmi)
 	}
 
 	if (hdmi->i2c)
-		hdmi_i2c_destroy(hdmi->i2c);
+		msm_hdmi_i2c_destroy(hdmi->i2c);
 
 	platform_set_drvdata(hdmi->pdev, NULL);
 }
 
-static int hdmi_get_phy(struct hdmi *hdmi)
+static int msm_hdmi_get_phy(struct hdmi *hdmi)
 {
 	struct platform_device *pdev = hdmi->pdev;
 	struct platform_device *phy_pdev;
@@ -121,7 +121,7 @@ static int hdmi_get_phy(struct hdmi *hdmi)
  * we are to EPROBE_DEFER we want to do it here, rather than later
  * at modeset_init() time
  */
-static struct hdmi *hdmi_init(struct platform_device *pdev)
+static struct hdmi *msm_hdmi_init(struct platform_device *pdev)
 {
 	struct hdmi_platform_config *config = pdev->dev.platform_data;
 	struct hdmi *hdmi = NULL;
@@ -240,7 +240,7 @@ static struct hdmi *hdmi_init(struct platform_device *pdev)
 
 	hdmi->workq = alloc_ordered_workqueue("msm_hdmi", 0);
 
-	hdmi->i2c = hdmi_i2c_init(hdmi);
+	hdmi->i2c = msm_hdmi_i2c_init(hdmi);
 	if (IS_ERR(hdmi->i2c)) {
 		ret = PTR_ERR(hdmi->i2c);
 		dev_err(&pdev->dev, "failed to get i2c: %d\n", ret);
@@ -248,13 +248,13 @@ static struct hdmi *hdmi_init(struct platform_device *pdev)
 		goto fail;
 	}
 
-	ret = hdmi_get_phy(hdmi);
+	ret = msm_hdmi_get_phy(hdmi);
 	if (ret) {
 		dev_err(&pdev->dev, "failed to get phy\n");
 		goto fail;
 	}
 
-	hdmi->hdcp_ctrl = hdmi_hdcp_init(hdmi);
+	hdmi->hdcp_ctrl = msm_hdmi_hdcp_init(hdmi);
 	if (IS_ERR(hdmi->hdcp_ctrl)) {
 		dev_warn(&pdev->dev, "failed to init hdcp: disabled\n");
 		hdmi->hdcp_ctrl = NULL;
@@ -264,7 +264,7 @@ static struct hdmi *hdmi_init(struct platform_device *pdev)
 
 fail:
 	if (hdmi)
-		hdmi_destroy(hdmi);
+		msm_hdmi_destroy(hdmi);
 
 	return ERR_PTR(ret);
 }
@@ -274,10 +274,10 @@ fail:
  * driver (not hdmi sub-device's probe/bind!)
  *
  * Any resource (regulator/clk/etc) which could be missing at boot
- * should be handled in hdmi_init() so that failure happens from
+ * should be handled in msm_hdmi_init() so that failure happens from
  * hdmi sub-device's probe.
  */
-int hdmi_modeset_init(struct hdmi *hdmi,
+int msm_hdmi_modeset_init(struct hdmi *hdmi,
 		struct drm_device *dev, struct drm_encoder *encoder)
 {
 	struct msm_drm_private *priv = dev->dev_private;
@@ -289,7 +289,7 @@ int hdmi_modeset_init(struct hdmi *hdmi,
 
 	hdmi_audio_infoframe_init(&hdmi->audio.infoframe);
 
-	hdmi->bridge = hdmi_bridge_init(hdmi);
+	hdmi->bridge = msm_hdmi_bridge_init(hdmi);
 	if (IS_ERR(hdmi->bridge)) {
 		ret = PTR_ERR(hdmi->bridge);
 		dev_err(dev->dev, "failed to create HDMI bridge: %d\n", ret);
@@ -297,7 +297,7 @@ int hdmi_modeset_init(struct hdmi *hdmi,
 		goto fail;
 	}
 
-	hdmi->connector = hdmi_connector_init(hdmi);
+	hdmi->connector = msm_hdmi_connector_init(hdmi);
 	if (IS_ERR(hdmi->connector)) {
 		ret = PTR_ERR(hdmi->connector);
 		dev_err(dev->dev, "failed to create HDMI connector: %d\n", ret);
@@ -313,7 +313,7 @@ int hdmi_modeset_init(struct hdmi *hdmi,
 	}
 
 	ret = devm_request_irq(&pdev->dev, hdmi->irq,
-			hdmi_irq, IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
+			msm_hdmi_irq, IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
 			"hdmi_isr", hdmi);
 	if (ret < 0) {
 		dev_err(dev->dev, "failed to request IRQ%u: %d\n",
@@ -333,7 +333,7 @@ int hdmi_modeset_init(struct hdmi *hdmi,
 fail:
 	/* bridge is normally destroyed by drm: */
 	if (hdmi->bridge) {
-		hdmi_bridge_destroy(hdmi->bridge);
+		msm_hdmi_bridge_destroy(hdmi->bridge);
 		hdmi->bridge = NULL;
 	}
 	if (hdmi->connector) {
@@ -410,7 +410,7 @@ static const struct {
 	const bool output;
 	const int value;
 	const char *label;
-} hdmi_gpio_pdata[] = {
+} msm_hdmi_gpio_pdata[] = {
 	{ "qcom,hdmi-tx-ddc-clk", true, 1, "HDMI_DDC_CLK" },
 	{ "qcom,hdmi-tx-ddc-data", true, 1, "HDMI_DDC_DATA" },
 	{ "qcom,hdmi-tx-hpd", false, 1, "HDMI_HPD" },
@@ -419,7 +419,7 @@ static const struct {
 	{ "qcom,hdmi-tx-mux-lpm", true, 1, "HDMI_MUX_LPM" },
 };
 
-static int get_gpio(struct device_node *of_node, const char *name)
+static int msm_hdmi_get_gpio(struct device_node *of_node, const char *name)
 {
 	int gpio = of_get_named_gpio(of_node, name, 0);
 	if (gpio < 0) {
@@ -434,7 +434,7 @@ static int get_gpio(struct device_node *of_node, const char *name)
 	return gpio;
 }
 
-static int hdmi_bind(struct device *dev, struct device *master, void *data)
+static int msm_hdmi_bind(struct device *dev, struct device *master, void *data)
 {
 	struct drm_device *drm = dev_get_drvdata(master);
 	struct msm_drm_private *priv = drm->dev_private;
@@ -454,16 +454,16 @@ static int hdmi_bind(struct device *dev, struct device *master, void *data)
 	hdmi_cfg->qfprom_mmio_name = "qfprom_physical";
 
 	for (i = 0; i < HDMI_MAX_NUM_GPIO; i++) {
-		hdmi_cfg->gpios[i].num = get_gpio(of_node,
-						hdmi_gpio_pdata[i].name);
-		hdmi_cfg->gpios[i].output = hdmi_gpio_pdata[i].output;
-		hdmi_cfg->gpios[i].value = hdmi_gpio_pdata[i].value;
-		hdmi_cfg->gpios[i].label = hdmi_gpio_pdata[i].label;
+		hdmi_cfg->gpios[i].num = msm_hdmi_get_gpio(of_node,
+						msm_hdmi_gpio_pdata[i].name);
+		hdmi_cfg->gpios[i].output = msm_hdmi_gpio_pdata[i].output;
+		hdmi_cfg->gpios[i].value = msm_hdmi_gpio_pdata[i].value;
+		hdmi_cfg->gpios[i].label = msm_hdmi_gpio_pdata[i].label;
 	}
 
 	dev->platform_data = hdmi_cfg;
 
-	hdmi = hdmi_init(to_platform_device(dev));
+	hdmi = msm_hdmi_init(to_platform_device(dev));
 	if (IS_ERR(hdmi))
 		return PTR_ERR(hdmi);
 	priv->hdmi = hdmi;
@@ -471,34 +471,34 @@ static int hdmi_bind(struct device *dev, struct device *master, void *data)
 	return 0;
 }
 
-static void hdmi_unbind(struct device *dev, struct device *master,
+static void msm_hdmi_unbind(struct device *dev, struct device *master,
 		void *data)
 {
 	struct drm_device *drm = dev_get_drvdata(master);
 	struct msm_drm_private *priv = drm->dev_private;
 	if (priv->hdmi) {
-		hdmi_destroy(priv->hdmi);
+		msm_hdmi_destroy(priv->hdmi);
 		priv->hdmi = NULL;
 	}
 }
 
-static const struct component_ops hdmi_ops = {
-		.bind   = hdmi_bind,
-		.unbind = hdmi_unbind,
+static const struct component_ops msm_hdmi_ops = {
+		.bind   = msm_hdmi_bind,
+		.unbind = msm_hdmi_unbind,
 };
 
-static int hdmi_dev_probe(struct platform_device *pdev)
+static int msm_hdmi_dev_probe(struct platform_device *pdev)
 {
-	return component_add(&pdev->dev, &hdmi_ops);
+	return component_add(&pdev->dev, &msm_hdmi_ops);
 }
 
-static int hdmi_dev_remove(struct platform_device *pdev)
+static int msm_hdmi_dev_remove(struct platform_device *pdev)
 {
-	component_del(&pdev->dev, &hdmi_ops);
+	component_del(&pdev->dev, &msm_hdmi_ops);
 	return 0;
 }
 
-static const struct of_device_id dt_match[] = {
+static const struct of_device_id msm_hdmi_dt_match[] = {
 	{ .compatible = "qcom,hdmi-tx-8996", .data = &hdmi_tx_8996_config },
 	{ .compatible = "qcom,hdmi-tx-8994", .data = &hdmi_tx_8994_config },
 	{ .compatible = "qcom,hdmi-tx-8084", .data = &hdmi_tx_8084_config },
@@ -508,23 +508,23 @@ static const struct of_device_id dt_match[] = {
 	{}
 };
 
-static struct platform_driver hdmi_driver = {
-	.probe = hdmi_dev_probe,
-	.remove = hdmi_dev_remove,
+static struct platform_driver msm_hdmi_driver = {
+	.probe = msm_hdmi_dev_probe,
+	.remove = msm_hdmi_dev_remove,
 	.driver = {
 		.name = "hdmi_msm",
-		.of_match_table = dt_match,
+		.of_match_table = msm_hdmi_dt_match,
 	},
 };
 
-void __init hdmi_register(void)
+void __init msm_hdmi_register(void)
 {
-	hdmi_phy_driver_register();
-	platform_driver_register(&hdmi_driver);
+	msm_hdmi_phy_driver_register();
+	platform_driver_register(&msm_hdmi_driver);
 }
 
-void __exit hdmi_unregister(void)
+void __exit msm_hdmi_unregister(void)
 {
-	platform_driver_unregister(&hdmi_driver);
-	hdmi_phy_driver_unregister();
+	platform_driver_unregister(&msm_hdmi_driver);
+	msm_hdmi_phy_driver_unregister();
 }
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 88557e59f750..b04a64664673 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -122,7 +122,7 @@ struct hdmi_platform_config {
 	struct hdmi_gpio_data gpios[HDMI_MAX_NUM_GPIO];
 };
 
-void hdmi_set_mode(struct hdmi *hdmi, bool power_on);
+void msm_hdmi_set_mode(struct hdmi *hdmi, bool power_on);
 
 static inline void hdmi_write(struct hdmi *hdmi, u32 reg, u32 data)
 {
@@ -161,10 +161,10 @@ struct hdmi_phy_cfg {
 	int num_clks;
 };
 
-extern const struct hdmi_phy_cfg hdmi_phy_8x60_cfg;
-extern const struct hdmi_phy_cfg hdmi_phy_8960_cfg;
-extern const struct hdmi_phy_cfg hdmi_phy_8x74_cfg;
-extern const struct hdmi_phy_cfg hdmi_phy_8996_cfg;
+extern const struct hdmi_phy_cfg msm_hdmi_phy_8x60_cfg;
+extern const struct hdmi_phy_cfg msm_hdmi_phy_8960_cfg;
+extern const struct hdmi_phy_cfg msm_hdmi_phy_8x74_cfg;
+extern const struct hdmi_phy_cfg msm_hdmi_phy_8996_cfg;
 
 struct hdmi_phy {
 	struct platform_device *pdev;
@@ -185,23 +185,23 @@ static inline u32 hdmi_phy_read(struct hdmi_phy *phy, u32 reg)
 	return msm_readl(phy->mmio + reg);
 }
 
-int hdmi_phy_resource_enable(struct hdmi_phy *phy);
-void hdmi_phy_resource_disable(struct hdmi_phy *phy);
-void hdmi_phy_powerup(struct hdmi_phy *phy, unsigned long int pixclock);
-void hdmi_phy_powerdown(struct hdmi_phy *phy);
-void __init hdmi_phy_driver_register(void);
-void __exit hdmi_phy_driver_unregister(void);
+int msm_hdmi_phy_resource_enable(struct hdmi_phy *phy);
+void msm_hdmi_phy_resource_disable(struct hdmi_phy *phy);
+void msm_hdmi_phy_powerup(struct hdmi_phy *phy, unsigned long int pixclock);
+void msm_hdmi_phy_powerdown(struct hdmi_phy *phy);
+void __init msm_hdmi_phy_driver_register(void);
+void __exit msm_hdmi_phy_driver_unregister(void);
 
 #ifdef CONFIG_COMMON_CLK
-int hdmi_pll_8960_init(struct platform_device *pdev);
-int hdmi_pll_8996_init(struct platform_device *pdev);
+int msm_hdmi_pll_8960_init(struct platform_device *pdev);
+int msm_hdmi_pll_8996_init(struct platform_device *pdev);
 #else
-int hdmi_pll_8960_init(struct platform_device *pdev);
+static inline int msm_hdmi_pll_8960_init(struct platform_device *pdev);
 {
 	return -ENODEV;
 }
 
-int hdmi_pll_8996_init(struct platform_device *pdev)
+static inline int msm_hdmi_pll_8996_init(struct platform_device *pdev)
 {
 	return -ENODEV;
 }
@@ -211,42 +211,42 @@ int hdmi_pll_8996_init(struct platform_device *pdev)
  * audio:
  */
 
-int hdmi_audio_update(struct hdmi *hdmi);
-int hdmi_audio_info_setup(struct hdmi *hdmi, bool enabled,
+int msm_hdmi_audio_update(struct hdmi *hdmi);
+int msm_hdmi_audio_info_setup(struct hdmi *hdmi, bool enabled,
 	uint32_t num_of_channels, uint32_t channel_allocation,
 	uint32_t level_shift, bool down_mix);
-void hdmi_audio_set_sample_rate(struct hdmi *hdmi, int rate);
+void msm_hdmi_audio_set_sample_rate(struct hdmi *hdmi, int rate);
 
 
 /*
  * hdmi bridge:
  */
 
-struct drm_bridge *hdmi_bridge_init(struct hdmi *hdmi);
-void hdmi_bridge_destroy(struct drm_bridge *bridge);
+struct drm_bridge *msm_hdmi_bridge_init(struct hdmi *hdmi);
+void msm_hdmi_bridge_destroy(struct drm_bridge *bridge);
 
 /*
  * hdmi connector:
  */
 
-void hdmi_connector_irq(struct drm_connector *connector);
-struct drm_connector *hdmi_connector_init(struct hdmi *hdmi);
+void msm_hdmi_connector_irq(struct drm_connector *connector);
+struct drm_connector *msm_hdmi_connector_init(struct hdmi *hdmi);
 
 /*
  * i2c adapter for ddc:
  */
 
-void hdmi_i2c_irq(struct i2c_adapter *i2c);
-void hdmi_i2c_destroy(struct i2c_adapter *i2c);
-struct i2c_adapter *hdmi_i2c_init(struct hdmi *hdmi);
+void msm_hdmi_i2c_irq(struct i2c_adapter *i2c);
+void msm_hdmi_i2c_destroy(struct i2c_adapter *i2c);
+struct i2c_adapter *msm_hdmi_i2c_init(struct hdmi *hdmi);
 
 /*
  * hdcp
  */
-struct hdmi_hdcp_ctrl *hdmi_hdcp_init(struct hdmi *hdmi);
-void hdmi_hdcp_destroy(struct hdmi *hdmi);
-void hdmi_hdcp_on(struct hdmi_hdcp_ctrl *hdcp_ctrl);
-void hdmi_hdcp_off(struct hdmi_hdcp_ctrl *hdcp_ctrl);
-void hdmi_hdcp_irq(struct hdmi_hdcp_ctrl *hdcp_ctrl);
+struct hdmi_hdcp_ctrl *msm_hdmi_hdcp_init(struct hdmi *hdmi);
+void msm_hdmi_hdcp_destroy(struct hdmi *hdmi);
+void msm_hdmi_hdcp_on(struct hdmi_hdcp_ctrl *hdcp_ctrl);
+void msm_hdmi_hdcp_off(struct hdmi_hdcp_ctrl *hdcp_ctrl);
+void msm_hdmi_hdcp_irq(struct hdmi_hdcp_ctrl *hdcp_ctrl);
 
 #endif /* __HDMI_CONNECTOR_H__ */
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_audio.c b/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
index df232e20c13e..a54d3bb5baad 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
@@ -89,7 +89,7 @@ static const struct hdmi_msm_audio_arcs *get_arcs(unsigned long int pixclock)
 	return NULL;
 }
 
-int hdmi_audio_update(struct hdmi *hdmi)
+int msm_hdmi_audio_update(struct hdmi *hdmi)
 {
 	struct hdmi_audio *audio = &hdmi->audio;
 	struct hdmi_audio_infoframe *info = &audio->infoframe;
@@ -232,7 +232,7 @@ int hdmi_audio_update(struct hdmi *hdmi)
 	return 0;
 }
 
-int hdmi_audio_info_setup(struct hdmi *hdmi, bool enabled,
+int msm_hdmi_audio_info_setup(struct hdmi *hdmi, bool enabled,
 	uint32_t num_of_channels, uint32_t channel_allocation,
 	uint32_t level_shift, bool down_mix)
 {
@@ -252,10 +252,10 @@ int hdmi_audio_info_setup(struct hdmi *hdmi, bool enabled,
 	audio->infoframe.level_shift_value = level_shift;
 	audio->infoframe.downmix_inhibit = down_mix;
 
-	return hdmi_audio_update(hdmi);
+	return msm_hdmi_audio_update(hdmi);
 }
 
-void hdmi_audio_set_sample_rate(struct hdmi *hdmi, int rate)
+void msm_hdmi_audio_set_sample_rate(struct hdmi *hdmi, int rate)
 {
 	struct hdmi_audio *audio;
 
@@ -268,5 +268,5 @@ void hdmi_audio_set_sample_rate(struct hdmi *hdmi, int rate)
 		return;
 
 	audio->rate = rate;
-	hdmi_audio_update(hdmi);
+	msm_hdmi_audio_update(hdmi);
 }
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index 310d92d06229..bacbd5d8df0e 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -23,11 +23,11 @@ struct hdmi_bridge {
 };
 #define to_hdmi_bridge(x) container_of(x, struct hdmi_bridge, base)
 
-void hdmi_bridge_destroy(struct drm_bridge *bridge)
+void msm_hdmi_bridge_destroy(struct drm_bridge *bridge)
 {
 }
 
-static void power_on(struct drm_bridge *bridge)
+static void msm_hdmi_power_on(struct drm_bridge *bridge)
 {
 	struct drm_device *dev = bridge->dev;
 	struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
@@ -86,7 +86,7 @@ static void power_off(struct drm_bridge *bridge)
 	}
 }
 
-static void hdmi_bridge_pre_enable(struct drm_bridge *bridge)
+static void msm_hdmi_bridge_pre_enable(struct drm_bridge *bridge)
 {
 	struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
 	struct hdmi *hdmi = hdmi_bridge->hdmi;
@@ -95,51 +95,51 @@ static void hdmi_bridge_pre_enable(struct drm_bridge *bridge)
 	DBG("power up");
 
 	if (!hdmi->power_on) {
-		hdmi_phy_resource_enable(phy);
-		power_on(bridge);
+		msm_hdmi_phy_resource_enable(phy);
+		msm_hdmi_power_on(bridge);
 		hdmi->power_on = true;
-		hdmi_audio_update(hdmi);
+		msm_hdmi_audio_update(hdmi);
 	}
 
-	hdmi_phy_powerup(phy, hdmi->pixclock);
+	msm_hdmi_phy_powerup(phy, hdmi->pixclock);
 
-	hdmi_set_mode(hdmi, true);
+	msm_hdmi_set_mode(hdmi, true);
 
 	if (hdmi->hdcp_ctrl)
-		hdmi_hdcp_on(hdmi->hdcp_ctrl);
+		msm_hdmi_hdcp_on(hdmi->hdcp_ctrl);
 }
 
-static void hdmi_bridge_enable(struct drm_bridge *bridge)
+static void msm_hdmi_bridge_enable(struct drm_bridge *bridge)
 {
 }
 
-static void hdmi_bridge_disable(struct drm_bridge *bridge)
+static void msm_hdmi_bridge_disable(struct drm_bridge *bridge)
 {
 }
 
-static void hdmi_bridge_post_disable(struct drm_bridge *bridge)
+static void msm_hdmi_bridge_post_disable(struct drm_bridge *bridge)
 {
 	struct hdmi_bridge *hdmi_bridge = to_hdmi_bridge(bridge);
 	struct hdmi *hdmi = hdmi_bridge->hdmi;
 	struct hdmi_phy *phy = hdmi->phy;
 
 	if (hdmi->hdcp_ctrl)
-		hdmi_hdcp_off(hdmi->hdcp_ctrl);
+		msm_hdmi_hdcp_off(hdmi->hdcp_ctrl);
 
 	DBG("power down");
-	hdmi_set_mode(hdmi, false);
+	msm_hdmi_set_mode(hdmi, false);
 
-	hdmi_phy_powerdown(phy);
+	msm_hdmi_phy_powerdown(phy);
 
 	if (hdmi->power_on) {
 		power_off(bridge);
 		hdmi->power_on = false;
-		hdmi_audio_update(hdmi);
-		hdmi_phy_resource_disable(phy);
+		msm_hdmi_audio_update(hdmi);
+		msm_hdmi_phy_resource_disable(phy);
 	}
 }
 
-static void hdmi_bridge_mode_set(struct drm_bridge *bridge,
+static void msm_hdmi_bridge_mode_set(struct drm_bridge *bridge,
 		 struct drm_display_mode *mode,
 		 struct drm_display_mode *adjusted_mode)
 {
@@ -196,20 +196,20 @@ static void hdmi_bridge_mode_set(struct drm_bridge *bridge,
 	DBG("frame_ctrl=%08x", frame_ctrl);
 	hdmi_write(hdmi, REG_HDMI_FRAME_CTRL, frame_ctrl);
 
-	hdmi_audio_update(hdmi);
+	msm_hdmi_audio_update(hdmi);
 }
 
-static const struct drm_bridge_funcs hdmi_bridge_funcs = {
-		.pre_enable = hdmi_bridge_pre_enable,
-		.enable = hdmi_bridge_enable,
-		.disable = hdmi_bridge_disable,
-		.post_disable = hdmi_bridge_post_disable,
-		.mode_set = hdmi_bridge_mode_set,
+static const struct drm_bridge_funcs msm_hdmi_bridge_funcs = {
+		.pre_enable = msm_hdmi_bridge_pre_enable,
+		.enable = msm_hdmi_bridge_enable,
+		.disable = msm_hdmi_bridge_disable,
+		.post_disable = msm_hdmi_bridge_post_disable,
+		.mode_set = msm_hdmi_bridge_mode_set,
 };
 
 
 /* initialize bridge */
-struct drm_bridge *hdmi_bridge_init(struct hdmi *hdmi)
+struct drm_bridge *msm_hdmi_bridge_init(struct hdmi *hdmi)
 {
 	struct drm_bridge *bridge = NULL;
 	struct hdmi_bridge *hdmi_bridge;
@@ -225,7 +225,7 @@ struct drm_bridge *hdmi_bridge_init(struct hdmi *hdmi)
 	hdmi_bridge->hdmi = hdmi;
 
 	bridge = &hdmi_bridge->base;
-	bridge->funcs = &hdmi_bridge_funcs;
+	bridge->funcs = &msm_hdmi_bridge_funcs;
 
 	ret = drm_bridge_attach(hdmi->dev, bridge);
 	if (ret)
@@ -235,7 +235,7 @@ struct drm_bridge *hdmi_bridge_init(struct hdmi *hdmi)
 
 fail:
 	if (bridge)
-		hdmi_bridge_destroy(bridge);
+		msm_hdmi_bridge_destroy(bridge);
 
 	return ERR_PTR(ret);
 }
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
index 3973d4644679..26129bff2dd6 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
@@ -28,7 +28,7 @@ struct hdmi_connector {
 };
 #define to_hdmi_connector(x) container_of(x, struct hdmi_connector, base)
 
-static void hdmi_phy_reset(struct hdmi *hdmi)
+static void msm_hdmi_phy_reset(struct hdmi *hdmi)
 {
 	unsigned int val;
 
@@ -179,9 +179,9 @@ static int hpd_enable(struct hdmi_connector *hdmi_connector)
 		}
 	}
 
-	hdmi_set_mode(hdmi, false);
-	hdmi_phy_reset(hdmi);
-	hdmi_set_mode(hdmi, true);
+	msm_hdmi_set_mode(hdmi, false);
+	msm_hdmi_phy_reset(hdmi);
+	msm_hdmi_set_mode(hdmi, true);
 
 	hdmi_write(hdmi, REG_HDMI_USEC_REFTIMER, 0x0001001b);
 
@@ -218,7 +218,7 @@ static void hdp_disable(struct hdmi_connector *hdmi_connector)
 	/* Disable HPD interrupt */
 	hdmi_write(hdmi, REG_HDMI_HPD_INT_CTRL, 0);
 
-	hdmi_set_mode(hdmi, false);
+	msm_hdmi_set_mode(hdmi, false);
 
 	for (i = 0; i < config->hpd_clk_cnt; i++)
 		clk_disable_unprepare(hdmi->hpd_clks[i]);
@@ -240,7 +240,7 @@ static void hdp_disable(struct hdmi_connector *hdmi_connector)
 }
 
 static void
-hotplug_work(struct work_struct *work)
+msm_hdmi_hotplug_work(struct work_struct *work)
 {
 	struct hdmi_connector *hdmi_connector =
 		container_of(work, struct hdmi_connector, hpd_work);
@@ -248,7 +248,7 @@ hotplug_work(struct work_struct *work)
 	drm_helper_hpd_irq_event(connector->dev);
 }
 
-void hdmi_connector_irq(struct drm_connector *connector)
+void msm_hdmi_connector_irq(struct drm_connector *connector)
 {
 	struct hdmi_connector *hdmi_connector = to_hdmi_connector(connector);
 	struct hdmi *hdmi = hdmi_connector->hdmi;
@@ -347,7 +347,7 @@ static void hdmi_connector_destroy(struct drm_connector *connector)
 	kfree(hdmi_connector);
 }
 
-static int hdmi_connector_get_modes(struct drm_connector *connector)
+static int msm_hdmi_connector_get_modes(struct drm_connector *connector)
 {
 	struct hdmi_connector *hdmi_connector = to_hdmi_connector(connector);
 	struct hdmi *hdmi = hdmi_connector->hdmi;
@@ -373,7 +373,7 @@ static int hdmi_connector_get_modes(struct drm_connector *connector)
 	return ret;
 }
 
-static int hdmi_connector_mode_valid(struct drm_connector *connector,
+static int msm_hdmi_connector_mode_valid(struct drm_connector *connector,
 				 struct drm_display_mode *mode)
 {
 	struct hdmi_connector *hdmi_connector = to_hdmi_connector(connector);
@@ -403,7 +403,7 @@ static int hdmi_connector_mode_valid(struct drm_connector *connector,
 }
 
 static struct drm_encoder *
-hdmi_connector_best_encoder(struct drm_connector *connector)
+msm_hdmi_connector_best_encoder(struct drm_connector *connector)
 {
 	struct hdmi_connector *hdmi_connector = to_hdmi_connector(connector);
 	return hdmi_connector->hdmi->encoder;
@@ -419,14 +419,14 @@ static const struct drm_connector_funcs hdmi_connector_funcs = {
 	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };
 
-static const struct drm_connector_helper_funcs hdmi_connector_helper_funcs = {
-	.get_modes = hdmi_connector_get_modes,
-	.mode_valid = hdmi_connector_mode_valid,
-	.best_encoder = hdmi_connector_best_encoder,
+static const struct drm_connector_helper_funcs msm_hdmi_connector_helper_funcs = {
+	.get_modes = msm_hdmi_connector_get_modes,
+	.mode_valid = msm_hdmi_connector_mode_valid,
+	.best_encoder = msm_hdmi_connector_best_encoder,
 };
 
 /* initialize connector */
-struct drm_connector *hdmi_connector_init(struct hdmi *hdmi)
+struct drm_connector *msm_hdmi_connector_init(struct hdmi *hdmi)
 {
 	struct drm_connector *connector = NULL;
 	struct hdmi_connector *hdmi_connector;
@@ -439,13 +439,13 @@ struct drm_connector *hdmi_connector_init(struct hdmi *hdmi)
 	}
 
 	hdmi_connector->hdmi = hdmi;
-	INIT_WORK(&hdmi_connector->hpd_work, hotplug_work);
+	INIT_WORK(&hdmi_connector->hpd_work, msm_hdmi_hotplug_work);
 
 	connector = &hdmi_connector->base;
 
 	drm_connector_init(hdmi->dev, connector, &hdmi_connector_funcs,
 			DRM_MODE_CONNECTOR_HDMIA);
-	drm_connector_helper_add(connector, &hdmi_connector_helper_funcs);
+	drm_connector_helper_add(connector, &msm_hdmi_connector_helper_funcs);
 
 	connector->polled = DRM_CONNECTOR_POLL_CONNECT |
 			DRM_CONNECTOR_POLL_DISCONNECT;
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c b/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
index 1dc9c34eb0df..0baaaaabd002 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c
@@ -84,7 +84,7 @@ struct hdmi_hdcp_ctrl {
 	bool max_dev_exceeded;
 };
 
-static int hdmi_ddc_read(struct hdmi *hdmi, u16 addr, u8 offset,
+static int msm_hdmi_ddc_read(struct hdmi *hdmi, u16 addr, u8 offset,
 	u8 *data, u16 data_len)
 {
 	int rc;
@@ -122,7 +122,7 @@ retry:
 
 #define HDCP_DDC_WRITE_MAX_BYTE_NUM 32
 
-static int hdmi_ddc_write(struct hdmi *hdmi, u16 addr, u8 offset,
+static int msm_hdmi_ddc_write(struct hdmi *hdmi, u16 addr, u8 offset,
 	u8 *data, u16 data_len)
 {
 	int rc;
@@ -162,7 +162,7 @@ retry:
 	return rc;
 }
 
-static int hdmi_hdcp_scm_wr(struct hdmi_hdcp_ctrl *hdcp_ctrl, u32 *preg,
+static int msm_hdmi_hdcp_scm_wr(struct hdmi_hdcp_ctrl *hdcp_ctrl, u32 *preg,
 	u32 *pdata, u32 count)
 {
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
@@ -202,7 +202,7 @@ static int hdmi_hdcp_scm_wr(struct hdmi_hdcp_ctrl *hdcp_ctrl, u32 *preg,
 	return ret;
 }
 
-void hdmi_hdcp_irq(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+void msm_hdmi_hdcp_irq(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
 	u32 reg_val, hdcp_int_status;
@@ -247,7 +247,7 @@ void hdmi_hdcp_irq(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	}
 }
 
-static int hdmi_hdcp_msleep(struct hdmi_hdcp_ctrl *hdcp_ctrl, u32 ms, u32 ev)
+static int msm_hdmi_hdcp_msleep(struct hdmi_hdcp_ctrl *hdcp_ctrl, u32 ms, u32 ev)
 {
 	int rc;
 
@@ -264,7 +264,7 @@ static int hdmi_hdcp_msleep(struct hdmi_hdcp_ctrl *hdcp_ctrl, u32 ms, u32 ev)
 	return 0;
 }
 
-static int hdmi_hdcp_read_validate_aksv(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_hdmi_hdcp_read_validate_aksv(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
 
@@ -287,7 +287,7 @@ static int hdmi_hdcp_read_validate_aksv(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	return 0;
 }
 
-static int reset_hdcp_ddc_failures(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_reset_hdcp_ddc_failures(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
 	u32 reg_val, failure, nack0;
@@ -337,7 +337,7 @@ static int reset_hdcp_ddc_failures(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 		reg_val |= HDMI_DDC_CTRL_SW_STATUS_RESET;
 		hdmi_write(hdmi, REG_HDMI_DDC_CTRL, reg_val);
 
-		rc = hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
+		rc = msm_hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
 
 		reg_val = hdmi_read(hdmi, REG_HDMI_DDC_CTRL);
 		reg_val &= ~HDMI_DDC_CTRL_SW_STATUS_RESET;
@@ -350,7 +350,7 @@ static int reset_hdcp_ddc_failures(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 
 		/* If previous msleep is aborted, skip this msleep */
 		if (!rc)
-			rc = hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
+			rc = msm_hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
 
 		reg_val = hdmi_read(hdmi, REG_HDMI_DDC_CTRL);
 		reg_val &= ~HDMI_DDC_CTRL_SOFT_RESET;
@@ -362,7 +362,7 @@ static int reset_hdcp_ddc_failures(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	return rc;
 }
 
-static int hdmi_hdcp_hw_ddc_clean(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_hdmi_hdcp_hw_ddc_clean(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	int rc;
 	u32 hdcp_ddc_status, ddc_hw_status;
@@ -394,7 +394,7 @@ static int hdmi_hdcp_hw_ddc_clean(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 			return -ETIMEDOUT;
 		}
 
-		rc = hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
+		rc = msm_hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
 		if (rc)
 			return rc;
 	} while (1);
@@ -402,7 +402,7 @@ static int hdmi_hdcp_hw_ddc_clean(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	return 0;
 }
 
-static void hdmi_hdcp_reauth_work(struct work_struct *work)
+static void msm_hdmi_hdcp_reauth_work(struct work_struct *work)
 {
 	struct hdmi_hdcp_ctrl *hdcp_ctrl = container_of(work,
 		struct hdmi_hdcp_ctrl, hdcp_reauth_work);
@@ -430,7 +430,7 @@ static void hdmi_hdcp_reauth_work(struct work_struct *work)
 		HDMI_HDCP_RESET_LINK0_DEAUTHENTICATE);
 
 	/* Wait to be clean on DDC HW engine */
-	if (hdmi_hdcp_hw_ddc_clean(hdcp_ctrl)) {
+	if (msm_hdmi_hdcp_hw_ddc_clean(hdcp_ctrl)) {
 		pr_info("%s: reauth work aborted\n", __func__);
 		return;
 	}
@@ -461,7 +461,7 @@ static void hdmi_hdcp_reauth_work(struct work_struct *work)
 	queue_work(hdmi->workq, &hdcp_ctrl->hdcp_auth_work);
 }
 
-static int hdmi_hdcp_auth_prepare(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_hdmi_hdcp_auth_prepare(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
 	u32 link0_status;
@@ -470,7 +470,7 @@ static int hdmi_hdcp_auth_prepare(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	int rc;
 
 	if (!hdcp_ctrl->aksv_valid) {
-		rc = hdmi_hdcp_read_validate_aksv(hdcp_ctrl);
+		rc = msm_hdmi_hdcp_read_validate_aksv(hdcp_ctrl);
 		if (rc) {
 			pr_err("%s: ASKV validation failed\n", __func__);
 			hdcp_ctrl->hdcp_state = HDCP_STATE_NO_AKSV;
@@ -538,12 +538,12 @@ static int hdmi_hdcp_auth_prepare(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 		DBG("An not ready after enabling HDCP");
 
 	/* Clear any DDC failures from previous tries before enable HDCP*/
-	rc = reset_hdcp_ddc_failures(hdcp_ctrl);
+	rc = msm_reset_hdcp_ddc_failures(hdcp_ctrl);
 
 	return rc;
 }
 
-static void hdmi_hdcp_auth_fail(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static void msm_hdmi_hdcp_auth_fail(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
 	u32 reg_val;
@@ -561,7 +561,7 @@ static void hdmi_hdcp_auth_fail(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	queue_work(hdmi->workq, &hdcp_ctrl->hdcp_reauth_work);
 }
 
-static void hdmi_hdcp_auth_done(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static void msm_hdmi_hdcp_auth_done(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
 	u32 reg_val;
@@ -596,7 +596,7 @@ static void hdmi_hdcp_auth_done(struct hdmi_hdcp_ctrl *hdcp_ctrl)
  * Write An and AKSV to sink
  * Read BKSV from sink and write into HDCP engine
  */
-static int hdmi_hdcp_wait_key_an_ready(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_hdmi_hdcp_wait_key_an_ready(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	int rc;
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
@@ -621,7 +621,7 @@ static int hdmi_hdcp_wait_key_an_ready(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 			return -ETIMEDOUT;
 		}
 
-		rc = hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
+		rc = msm_hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
 		if (rc)
 			return rc;
 	} while (1);
@@ -643,7 +643,7 @@ static int hdmi_hdcp_wait_key_an_ready(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 			return -ETIMEDOUT;
 		}
 
-		rc = hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
+		rc = msm_hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
 		if (rc)
 			return rc;
 	} while (1);
@@ -651,7 +651,7 @@ static int hdmi_hdcp_wait_key_an_ready(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	return 0;
 }
 
-static int hdmi_hdcp_send_aksv_an(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_hdmi_hdcp_send_aksv_an(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	int rc = 0;
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
@@ -676,7 +676,7 @@ static int hdmi_hdcp_send_aksv_an(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	aksv[4] =  link0_aksv_1        & 0xFF;
 
 	/* Write An to offset 0x18 */
-	rc = hdmi_ddc_write(hdmi, HDCP_PORT_ADDR, 0x18, (u8 *)link0_an,
+	rc = msm_hdmi_ddc_write(hdmi, HDCP_PORT_ADDR, 0x18, (u8 *)link0_an,
 		(u16)sizeof(link0_an));
 	if (rc) {
 		pr_err("%s:An write failed\n", __func__);
@@ -685,7 +685,7 @@ static int hdmi_hdcp_send_aksv_an(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	DBG("Link0-An=%08x%08x", link0_an[0], link0_an[1]);
 
 	/* Write AKSV to offset 0x10 */
-	rc = hdmi_ddc_write(hdmi, HDCP_PORT_ADDR, 0x10, aksv, 5);
+	rc = msm_hdmi_ddc_write(hdmi, HDCP_PORT_ADDR, 0x10, aksv, 5);
 	if (rc) {
 		pr_err("%s:AKSV write failed\n", __func__);
 		return rc;
@@ -695,7 +695,7 @@ static int hdmi_hdcp_send_aksv_an(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	return 0;
 }
 
-static int hdmi_hdcp_recv_bksv(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_hdmi_hdcp_recv_bksv(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	int rc = 0;
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
@@ -703,7 +703,7 @@ static int hdmi_hdcp_recv_bksv(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	u32 reg[2], data[2];
 
 	/* Read BKSV at offset 0x00 */
-	rc = hdmi_ddc_read(hdmi, HDCP_PORT_ADDR, 0x00, bksv, 5);
+	rc = msm_hdmi_ddc_read(hdmi, HDCP_PORT_ADDR, 0x00, bksv, 5);
 	if (rc) {
 		pr_err("%s:BKSV read failed\n", __func__);
 		return rc;
@@ -728,19 +728,19 @@ static int hdmi_hdcp_recv_bksv(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	data[0] = hdcp_ctrl->bksv_lsb;
 	reg[1] = REG_HDMI_HDCP_RCVPORT_DATA1;
 	data[1] = hdcp_ctrl->bksv_msb;
-	rc = hdmi_hdcp_scm_wr(hdcp_ctrl, reg, data, 2);
+	rc = msm_hdmi_hdcp_scm_wr(hdcp_ctrl, reg, data, 2);
 
 	return rc;
 }
 
-static int hdmi_hdcp_recv_bcaps(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_hdmi_hdcp_recv_bcaps(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	int rc = 0;
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
 	u32 reg, data;
 	u8 bcaps;
 
-	rc = hdmi_ddc_read(hdmi, HDCP_PORT_ADDR, 0x40, &bcaps, 1);
+	rc = msm_hdmi_ddc_read(hdmi, HDCP_PORT_ADDR, 0x40, &bcaps, 1);
 	if (rc) {
 		pr_err("%s:BCAPS read failed\n", __func__);
 		return rc;
@@ -753,26 +753,26 @@ static int hdmi_hdcp_recv_bcaps(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	/* Write BCAPS to the hardware */
 	reg = REG_HDMI_HDCP_RCVPORT_DATA12;
 	data = (u32)bcaps;
-	rc = hdmi_hdcp_scm_wr(hdcp_ctrl, &reg, &data, 1);
+	rc = msm_hdmi_hdcp_scm_wr(hdcp_ctrl, &reg, &data, 1);
 
 	return rc;
 }
 
-static int hdmi_hdcp_auth_part1_key_exchange(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_hdmi_hdcp_auth_part1_key_exchange(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
 	unsigned long flags;
 	int rc;
 
 	/* Wait for AKSV key and An ready */
-	rc = hdmi_hdcp_wait_key_an_ready(hdcp_ctrl);
+	rc = msm_hdmi_hdcp_wait_key_an_ready(hdcp_ctrl);
 	if (rc) {
 		pr_err("%s: wait key and an ready failed\n", __func__);
 		return rc;
 	};
 
 	/* Read BCAPS and send to HDCP engine */
-	rc = hdmi_hdcp_recv_bcaps(hdcp_ctrl);
+	rc = msm_hdmi_hdcp_recv_bcaps(hdcp_ctrl);
 	if (rc) {
 		pr_err("%s: read bcaps error, abort\n", __func__);
 		return rc;
@@ -785,14 +785,14 @@ static int hdmi_hdcp_auth_part1_key_exchange(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	hdmi_write(hdmi, REG_HDMI_HDCP_RCVPORT_DATA4, 0);
 
 	/* Send AKSV and An to sink */
-	rc = hdmi_hdcp_send_aksv_an(hdcp_ctrl);
+	rc = msm_hdmi_hdcp_send_aksv_an(hdcp_ctrl);
 	if (rc) {
 		pr_err("%s:An/Aksv write failed\n", __func__);
 		return rc;
 	}
 
 	/* Read BKSV and send to HDCP engine*/
-	rc = hdmi_hdcp_recv_bksv(hdcp_ctrl);
+	rc = msm_hdmi_hdcp_recv_bksv(hdcp_ctrl);
 	if (rc) {
 		pr_err("%s:BKSV Process failed\n", __func__);
 		return rc;
@@ -812,7 +812,7 @@ static int hdmi_hdcp_auth_part1_key_exchange(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 }
 
 /* read R0' from sink and pass it to HDCP engine */
-static int hdmi_hdcp_auth_part1_recv_r0(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_hdmi_hdcp_auth_part1_recv_r0(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
 	int rc = 0;
@@ -822,12 +822,12 @@ static int hdmi_hdcp_auth_part1_recv_r0(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	 * HDCP Compliance Test case 1A-01:
 	 * Wait here at least 100ms before reading R0'
 	 */
-	rc = hdmi_hdcp_msleep(hdcp_ctrl, 125, AUTH_ABORT_EV);
+	rc = msm_hdmi_hdcp_msleep(hdcp_ctrl, 125, AUTH_ABORT_EV);
 	if (rc)
 		return rc;
 
 	/* Read R0' at offset 0x08 */
-	rc = hdmi_ddc_read(hdmi, HDCP_PORT_ADDR, 0x08, buf, 2);
+	rc = msm_hdmi_ddc_read(hdmi, HDCP_PORT_ADDR, 0x08, buf, 2);
 	if (rc) {
 		pr_err("%s:R0' read failed\n", __func__);
 		return rc;
@@ -842,14 +842,14 @@ static int hdmi_hdcp_auth_part1_recv_r0(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 }
 
 /* Wait for authenticating result: R0/R0' are matched or not */
-static int hdmi_hdcp_auth_part1_verify_r0(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_hdmi_hdcp_auth_part1_verify_r0(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
 	u32 link0_status;
 	int rc;
 
 	/* wait for hdcp irq, 10 sec should be long enough */
-	rc = hdmi_hdcp_msleep(hdcp_ctrl, 10000, AUTH_RESULT_RDY_EV);
+	rc = msm_hdmi_hdcp_msleep(hdcp_ctrl, 10000, AUTH_RESULT_RDY_EV);
 	if (!rc) {
 		pr_err("%s: Wait Auth IRQ timeout\n", __func__);
 		return -ETIMEDOUT;
@@ -869,7 +869,7 @@ static int hdmi_hdcp_auth_part1_verify_r0(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	return 0;
 }
 
-static int hdmi_hdcp_recv_check_bstatus(struct hdmi_hdcp_ctrl *hdcp_ctrl,
+static int msm_hdmi_hdcp_recv_check_bstatus(struct hdmi_hdcp_ctrl *hdcp_ctrl,
 	u16 *pbstatus)
 {
 	int rc;
@@ -880,7 +880,7 @@ static int hdmi_hdcp_recv_check_bstatus(struct hdmi_hdcp_ctrl *hdcp_ctrl,
 	u8 buf[2];
 
 	/* Read BSTATUS at offset 0x41 */
-	rc = hdmi_ddc_read(hdmi, HDCP_PORT_ADDR, 0x41, buf, 2);
+	rc = msm_hdmi_ddc_read(hdmi, HDCP_PORT_ADDR, 0x41, buf, 2);
 	if (rc) {
 		pr_err("%s: BSTATUS read failed\n", __func__);
 		goto error;
@@ -936,7 +936,7 @@ error:
 	return rc;
 }
 
-static int hdmi_hdcp_auth_part2_wait_ksv_fifo_ready(
+static int msm_hdmi_hdcp_auth_part2_wait_ksv_fifo_ready(
 	struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	int rc;
@@ -953,7 +953,7 @@ static int hdmi_hdcp_auth_part2_wait_ksv_fifo_ready(
 	timeout_count = 100;
 	do {
 		/* Read BCAPS at offset 0x40 */
-		rc = hdmi_ddc_read(hdmi, HDCP_PORT_ADDR, 0x40, &bcaps, 1);
+		rc = msm_hdmi_ddc_read(hdmi, HDCP_PORT_ADDR, 0x40, &bcaps, 1);
 		if (rc) {
 			pr_err("%s: BCAPS read failed\n", __func__);
 			return rc;
@@ -968,12 +968,12 @@ static int hdmi_hdcp_auth_part2_wait_ksv_fifo_ready(
 			return -ETIMEDOUT;
 		}
 
-		rc = hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
+		rc = msm_hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
 		if (rc)
 			return rc;
 	} while (1);
 
-	rc = hdmi_hdcp_recv_check_bstatus(hdcp_ctrl, &bstatus);
+	rc = msm_hdmi_hdcp_recv_check_bstatus(hdcp_ctrl, &bstatus);
 	if (rc) {
 		pr_err("%s: bstatus error\n", __func__);
 		return rc;
@@ -982,7 +982,7 @@ static int hdmi_hdcp_auth_part2_wait_ksv_fifo_ready(
 	/* Write BSTATUS and BCAPS to HDCP registers */
 	reg = REG_HDMI_HDCP_RCVPORT_DATA12;
 	data = bcaps | (bstatus << 8);
-	rc = hdmi_hdcp_scm_wr(hdcp_ctrl, &reg, &data, 1);
+	rc = msm_hdmi_hdcp_scm_wr(hdcp_ctrl, &reg, &data, 1);
 	if (rc) {
 		pr_err("%s: BSTATUS write failed\n", __func__);
 		return rc;
@@ -997,7 +997,7 @@ static int hdmi_hdcp_auth_part2_wait_ksv_fifo_ready(
  * transfer V' from sink to HDCP engine
  * reset SHA engine
  */
-static int hdmi_hdcp_transfer_v_h(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_hdmi_hdcp_transfer_v_h(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
 	int rc = 0;
@@ -1016,7 +1016,7 @@ static int hdmi_hdcp_transfer_v_h(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 
 	for (i = 0; i < size; i++) {
 		rd = &reg_data[i];
-		rc = hdmi_ddc_read(hdmi, HDCP_PORT_ADDR,
+		rc = msm_hdmi_ddc_read(hdmi, HDCP_PORT_ADDR,
 			rd->off, (u8 *)&data[i], (u16)sizeof(data[i]));
 		if (rc) {
 			pr_err("%s: Read %s failed\n", __func__, rd->name);
@@ -1027,13 +1027,13 @@ static int hdmi_hdcp_transfer_v_h(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 		reg[i] = reg_data[i].reg_id;
 	}
 
-	rc = hdmi_hdcp_scm_wr(hdcp_ctrl, reg, data, size);
+	rc = msm_hdmi_hdcp_scm_wr(hdcp_ctrl, reg, data, size);
 
 error:
 	return rc;
 }
 
-static int hdmi_hdcp_recv_ksv_fifo(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_hdmi_hdcp_recv_ksv_fifo(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	int rc;
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
@@ -1041,7 +1041,7 @@ static int hdmi_hdcp_recv_ksv_fifo(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 
 	ksv_bytes = 5 * hdcp_ctrl->dev_count;
 
-	rc = hdmi_ddc_read(hdmi, HDCP_PORT_ADDR, 0x43,
+	rc = msm_hdmi_ddc_read(hdmi, HDCP_PORT_ADDR, 0x43,
 		hdcp_ctrl->ksv_list, ksv_bytes);
 	if (rc)
 		pr_err("%s: KSV FIFO read failed\n", __func__);
@@ -1049,7 +1049,7 @@ static int hdmi_hdcp_recv_ksv_fifo(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	return rc;
 }
 
-static int hdmi_hdcp_reset_sha_engine(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_hdmi_hdcp_reset_sha_engine(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	u32 reg[2], data[2];
 	u32 rc  = 0;
@@ -1059,12 +1059,12 @@ static int hdmi_hdcp_reset_sha_engine(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	reg[1] = REG_HDMI_HDCP_SHA_CTRL;
 	data[1] = HDCP_REG_DISABLE;
 
-	rc = hdmi_hdcp_scm_wr(hdcp_ctrl, reg, data, 2);
+	rc = msm_hdmi_hdcp_scm_wr(hdcp_ctrl, reg, data, 2);
 
 	return rc;
 }
 
-static int hdmi_hdcp_auth_part2_recv_ksv_fifo(
+static int msm_hdmi_hdcp_auth_part2_recv_ksv_fifo(
 	struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	int rc;
@@ -1081,7 +1081,7 @@ static int hdmi_hdcp_auth_part2_recv_ksv_fifo(
 	 */
 	timeout_count = 100;
 	do {
-		rc = hdmi_hdcp_recv_ksv_fifo(hdcp_ctrl);
+		rc = msm_hdmi_hdcp_recv_ksv_fifo(hdcp_ctrl);
 		if (!rc)
 			break;
 
@@ -1091,19 +1091,19 @@ static int hdmi_hdcp_auth_part2_recv_ksv_fifo(
 			return -ETIMEDOUT;
 		}
 
-		rc = hdmi_hdcp_msleep(hdcp_ctrl, 25, AUTH_ABORT_EV);
+		rc = msm_hdmi_hdcp_msleep(hdcp_ctrl, 25, AUTH_ABORT_EV);
 		if (rc)
 			return rc;
 	} while (1);
 
-	rc = hdmi_hdcp_transfer_v_h(hdcp_ctrl);
+	rc = msm_hdmi_hdcp_transfer_v_h(hdcp_ctrl);
 	if (rc) {
 		pr_err("%s: transfer V failed\n", __func__);
 		return rc;
 	}
 
 	/* reset SHA engine before write ksv fifo */
-	rc = hdmi_hdcp_reset_sha_engine(hdcp_ctrl);
+	rc = msm_hdmi_hdcp_reset_sha_engine(hdcp_ctrl);
 	if (rc) {
 		pr_err("%s: fail to reset sha engine\n", __func__);
 		return rc;
@@ -1120,7 +1120,7 @@ static int hdmi_hdcp_auth_part2_recv_ksv_fifo(
  * If the last byte is written, we need to poll for
  * HDCP_SHA_COMP_DONE to wait until HW finish
  */
-static int hdmi_hdcp_write_ksv_fifo(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_hdmi_hdcp_write_ksv_fifo(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	int i;
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
@@ -1169,7 +1169,7 @@ static int hdmi_hdcp_write_ksv_fifo(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 
 		reg = REG_HDMI_HDCP_SHA_DATA;
 		data = reg_val;
-		rc = hdmi_hdcp_scm_wr(hdcp_ctrl, &reg, &data, 1);
+		rc = msm_hdmi_hdcp_scm_wr(hdcp_ctrl, &reg, &data, 1);
 
 		if (rc)
 			return rc;
@@ -1184,7 +1184,7 @@ static int hdmi_hdcp_write_ksv_fifo(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 }
 
 /* write ksv fifo into HDCP engine */
-static int hdmi_hdcp_auth_part2_write_ksv_fifo(
+static int msm_hdmi_hdcp_auth_part2_write_ksv_fifo(
 	struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	int rc;
@@ -1193,7 +1193,7 @@ static int hdmi_hdcp_auth_part2_write_ksv_fifo(
 	hdcp_ctrl->ksv_fifo_w_index = 0;
 	timeout_count = 100;
 	do {
-		rc = hdmi_hdcp_write_ksv_fifo(hdcp_ctrl);
+		rc = msm_hdmi_hdcp_write_ksv_fifo(hdcp_ctrl);
 		if (!rc)
 			break;
 
@@ -1206,7 +1206,7 @@ static int hdmi_hdcp_auth_part2_write_ksv_fifo(
 			return -ETIMEDOUT;
 		}
 
-		rc = hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
+		rc = msm_hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
 		if (rc)
 			return rc;
 	} while (1);
@@ -1214,7 +1214,7 @@ static int hdmi_hdcp_auth_part2_write_ksv_fifo(
 	return 0;
 }
 
-static int hdmi_hdcp_auth_part2_check_v_match(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+static int msm_hdmi_hdcp_auth_part2_check_v_match(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	int rc = 0;
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
@@ -1232,7 +1232,7 @@ static int hdmi_hdcp_auth_part2_check_v_match(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 				return -ETIMEDOUT;
 		}
 
-		rc = hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
+		rc = msm_hdmi_hdcp_msleep(hdcp_ctrl, 20, AUTH_ABORT_EV);
 		if (rc)
 			return rc;
 	} while (1);
@@ -1240,32 +1240,32 @@ static int hdmi_hdcp_auth_part2_check_v_match(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	return 0;
 }
 
-static void hdmi_hdcp_auth_work(struct work_struct *work)
+static void msm_hdmi_hdcp_auth_work(struct work_struct *work)
 {
 	struct hdmi_hdcp_ctrl *hdcp_ctrl = container_of(work,
 		struct hdmi_hdcp_ctrl, hdcp_auth_work);
 	int rc;
 
-	rc = hdmi_hdcp_auth_prepare(hdcp_ctrl);
+	rc = msm_hdmi_hdcp_auth_prepare(hdcp_ctrl);
 	if (rc) {
 		pr_err("%s: auth prepare failed %d\n", __func__, rc);
 		goto end;
 	}
 
 	/* HDCP PartI */
-	rc = hdmi_hdcp_auth_part1_key_exchange(hdcp_ctrl);
+	rc = msm_hdmi_hdcp_auth_part1_key_exchange(hdcp_ctrl);
 	if (rc) {
 		pr_err("%s: key exchange failed %d\n", __func__, rc);
 		goto end;
 	}
 
-	rc = hdmi_hdcp_auth_part1_recv_r0(hdcp_ctrl);
+	rc = msm_hdmi_hdcp_auth_part1_recv_r0(hdcp_ctrl);
 	if (rc) {
 		pr_err("%s: receive r0 failed %d\n", __func__, rc);
 		goto end;
 	}
 
-	rc = hdmi_hdcp_auth_part1_verify_r0(hdcp_ctrl);
+	rc = msm_hdmi_hdcp_auth_part1_verify_r0(hdcp_ctrl);
 	if (rc) {
 		pr_err("%s: verify r0 failed %d\n", __func__, rc);
 		goto end;
@@ -1275,25 +1275,25 @@ static void hdmi_hdcp_auth_work(struct work_struct *work)
 		goto end;
 
 	/* HDCP PartII */
-	rc = hdmi_hdcp_auth_part2_wait_ksv_fifo_ready(hdcp_ctrl);
+	rc = msm_hdmi_hdcp_auth_part2_wait_ksv_fifo_ready(hdcp_ctrl);
 	if (rc) {
 		pr_err("%s: wait ksv fifo ready failed %d\n", __func__, rc);
 		goto end;
 	}
 
-	rc = hdmi_hdcp_auth_part2_recv_ksv_fifo(hdcp_ctrl);
+	rc = msm_hdmi_hdcp_auth_part2_recv_ksv_fifo(hdcp_ctrl);
 	if (rc) {
 		pr_err("%s: recv ksv fifo failed %d\n", __func__, rc);
 		goto end;
 	}
 
-	rc = hdmi_hdcp_auth_part2_write_ksv_fifo(hdcp_ctrl);
+	rc = msm_hdmi_hdcp_auth_part2_write_ksv_fifo(hdcp_ctrl);
 	if (rc) {
 		pr_err("%s: write ksv fifo failed %d\n", __func__, rc);
 		goto end;
 	}
 
-	rc = hdmi_hdcp_auth_part2_check_v_match(hdcp_ctrl);
+	rc = msm_hdmi_hdcp_auth_part2_check_v_match(hdcp_ctrl);
 	if (rc)
 		pr_err("%s: check v match failed %d\n", __func__, rc);
 
@@ -1304,13 +1304,13 @@ end:
 		pr_info("%s: hdcp is not supported\n", __func__);
 	} else if (rc) {
 		pr_err("%s: hdcp authentication failed\n", __func__);
-		hdmi_hdcp_auth_fail(hdcp_ctrl);
+		msm_hdmi_hdcp_auth_fail(hdcp_ctrl);
 	} else {
-		hdmi_hdcp_auth_done(hdcp_ctrl);
+		msm_hdmi_hdcp_auth_done(hdcp_ctrl);
 	}
 }
 
-void hdmi_hdcp_on(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+void msm_hdmi_hdcp_on(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
 	u32 reg_val;
@@ -1335,7 +1335,7 @@ void hdmi_hdcp_on(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	queue_work(hdmi->workq, &hdcp_ctrl->hdcp_auth_work);
 }
 
-void hdmi_hdcp_off(struct hdmi_hdcp_ctrl *hdcp_ctrl)
+void msm_hdmi_hdcp_off(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 {
 	struct hdmi *hdmi = hdcp_ctrl->hdmi;
 	unsigned long flags;
@@ -1399,7 +1399,7 @@ void hdmi_hdcp_off(struct hdmi_hdcp_ctrl *hdcp_ctrl)
 	DBG("HDCP: Off");
 }
 
-struct hdmi_hdcp_ctrl *hdmi_hdcp_init(struct hdmi *hdmi)
+struct hdmi_hdcp_ctrl *msm_hdmi_hdcp_init(struct hdmi *hdmi)
 {
 	struct hdmi_hdcp_ctrl *hdcp_ctrl = NULL;
 
@@ -1413,8 +1413,8 @@ struct hdmi_hdcp_ctrl *hdmi_hdcp_init(struct hdmi *hdmi)
 	if (!hdcp_ctrl)
 		return ERR_PTR(-ENOMEM);
 
-	INIT_WORK(&hdcp_ctrl->hdcp_auth_work, hdmi_hdcp_auth_work);
-	INIT_WORK(&hdcp_ctrl->hdcp_reauth_work, hdmi_hdcp_reauth_work);
+	INIT_WORK(&hdcp_ctrl->hdcp_auth_work, msm_hdmi_hdcp_auth_work);
+	INIT_WORK(&hdcp_ctrl->hdcp_reauth_work, msm_hdmi_hdcp_reauth_work);
 	init_waitqueue_head(&hdcp_ctrl->auth_event_queue);
 	hdcp_ctrl->hdmi = hdmi;
 	hdcp_ctrl->hdcp_state = HDCP_STATE_INACTIVE;
@@ -1428,7 +1428,7 @@ struct hdmi_hdcp_ctrl *hdmi_hdcp_init(struct hdmi *hdmi)
 	return hdcp_ctrl;
 }
 
-void hdmi_hdcp_destroy(struct hdmi *hdmi)
+void msm_hdmi_hdcp_destroy(struct hdmi *hdmi)
 {
 	if (hdmi && hdmi->hdcp_ctrl) {
 		kfree(hdmi->hdcp_ctrl);
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_i2c.c b/drivers/gpu/drm/msm/hdmi/hdmi_i2c.c
index f4ab7f70fed1..de9007e72f4e 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_i2c.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_i2c.c
@@ -97,7 +97,7 @@ static bool sw_done(struct hdmi_i2c_adapter *hdmi_i2c)
 	return hdmi_i2c->sw_done;
 }
 
-static int hdmi_i2c_xfer(struct i2c_adapter *i2c,
+static int msm_hdmi_i2c_xfer(struct i2c_adapter *i2c,
 		struct i2c_msg *msgs, int num)
 {
 	struct hdmi_i2c_adapter *hdmi_i2c = to_hdmi_i2c_adapter(i2c);
@@ -216,17 +216,17 @@ static int hdmi_i2c_xfer(struct i2c_adapter *i2c,
 	return i;
 }
 
-static u32 hdmi_i2c_func(struct i2c_adapter *adapter)
+static u32 msm_hdmi_i2c_func(struct i2c_adapter *adapter)
 {
 	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
 }
 
-static const struct i2c_algorithm hdmi_i2c_algorithm = {
-	.master_xfer	= hdmi_i2c_xfer,
-	.functionality	= hdmi_i2c_func,
+static const struct i2c_algorithm msm_hdmi_i2c_algorithm = {
+	.master_xfer	= msm_hdmi_i2c_xfer,
+	.functionality	= msm_hdmi_i2c_func,
 };
 
-void hdmi_i2c_irq(struct i2c_adapter *i2c)
+void msm_hdmi_i2c_irq(struct i2c_adapter *i2c)
 {
 	struct hdmi_i2c_adapter *hdmi_i2c = to_hdmi_i2c_adapter(i2c);
 
@@ -234,14 +234,14 @@ void hdmi_i2c_irq(struct i2c_adapter *i2c)
 		wake_up_all(&hdmi_i2c->ddc_event);
 }
 
-void hdmi_i2c_destroy(struct i2c_adapter *i2c)
+void msm_hdmi_i2c_destroy(struct i2c_adapter *i2c)
 {
 	struct hdmi_i2c_adapter *hdmi_i2c = to_hdmi_i2c_adapter(i2c);
 	i2c_del_adapter(i2c);
 	kfree(hdmi_i2c);
 }
 
-struct i2c_adapter *hdmi_i2c_init(struct hdmi *hdmi)
+struct i2c_adapter *msm_hdmi_i2c_init(struct hdmi *hdmi)
 {
 	struct drm_device *dev = hdmi->dev;
 	struct hdmi_i2c_adapter *hdmi_i2c;
@@ -264,7 +264,7 @@ struct i2c_adapter *hdmi_i2c_init(struct hdmi *hdmi)
 	i2c->class = I2C_CLASS_DDC;
 	snprintf(i2c->name, sizeof(i2c->name), "msm hdmi i2c");
 	i2c->dev.parent = &hdmi->pdev->dev;
-	i2c->algo = &hdmi_i2c_algorithm;
+	i2c->algo = &msm_hdmi_i2c_algorithm;
 
 	ret = i2c_add_adapter(i2c);
 	if (ret) {
@@ -276,6 +276,6 @@ struct i2c_adapter *hdmi_i2c_init(struct hdmi *hdmi)
 
 fail:
 	if (i2c)
-		hdmi_i2c_destroy(i2c);
+		msm_hdmi_i2c_destroy(i2c);
 	return ERR_PTR(ret);
 }
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
index ce981c11c3b5..5530631e2d49 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
@@ -15,7 +15,7 @@
 
 #include "hdmi.h"
 
-static int hdmi_phy_resource_init(struct hdmi_phy *phy)
+static int msm_hdmi_phy_resource_init(struct hdmi_phy *phy)
 {
 	struct hdmi_phy_cfg *cfg = phy->cfg;
 	struct device *dev = &phy->pdev->dev;
@@ -62,7 +62,7 @@ static int hdmi_phy_resource_init(struct hdmi_phy *phy)
 	return 0;
 }
 
-int hdmi_phy_resource_enable(struct hdmi_phy *phy)
+int msm_hdmi_phy_resource_enable(struct hdmi_phy *phy)
 {
 	struct hdmi_phy_cfg *cfg = phy->cfg;
 	struct device *dev = &phy->pdev->dev;
@@ -87,7 +87,7 @@ int hdmi_phy_resource_enable(struct hdmi_phy *phy)
 	return ret;
 }
 
-void hdmi_phy_resource_disable(struct hdmi_phy *phy)
+void msm_hdmi_phy_resource_disable(struct hdmi_phy *phy)
 {
 	struct hdmi_phy_cfg *cfg = phy->cfg;
 	struct device *dev = &phy->pdev->dev;
@@ -102,7 +102,7 @@ void hdmi_phy_resource_disable(struct hdmi_phy *phy)
 	pm_runtime_put_sync(dev);
 }
 
-void hdmi_phy_powerup(struct hdmi_phy *phy, unsigned long int pixclock)
+void msm_hdmi_phy_powerup(struct hdmi_phy *phy, unsigned long int pixclock)
 {
 	if (!phy || !phy->cfg->powerup)
 		return;
@@ -110,7 +110,7 @@ void hdmi_phy_powerup(struct hdmi_phy *phy, unsigned long int pixclock)
 	phy->cfg->powerup(phy, pixclock);
 }
 
-void hdmi_phy_powerdown(struct hdmi_phy *phy)
+void msm_hdmi_phy_powerdown(struct hdmi_phy *phy)
 {
 	if (!phy || !phy->cfg->powerdown)
 		return;
@@ -118,17 +118,17 @@ void hdmi_phy_powerdown(struct hdmi_phy *phy)
 	phy->cfg->powerdown(phy);
 }
 
-static int hdmi_phy_pll_init(struct platform_device *pdev,
+static int msm_hdmi_phy_pll_init(struct platform_device *pdev,
 			     enum hdmi_phy_type type)
 {
 	int ret;
 
 	switch (type) {
 	case MSM_HDMI_PHY_8960:
-		ret = hdmi_pll_8960_init(pdev);
+		ret = msm_hdmi_pll_8960_init(pdev);
 		break;
 	case MSM_HDMI_PHY_8996:
-		ret = hdmi_pll_8996_init(pdev);
+		ret = msm_hdmi_pll_8996_init(pdev);
 		break;
 	/*
 	 * we don't have PLL support for these, don't report an error for now
@@ -143,7 +143,7 @@ static int hdmi_phy_pll_init(struct platform_device *pdev,
 	return ret;
 }
 
-static int hdmi_phy_probe(struct platform_device *pdev)
+static int msm_hdmi_phy_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct hdmi_phy *phy;
@@ -165,64 +165,64 @@ static int hdmi_phy_probe(struct platform_device *pdev)
 
 	phy->pdev = pdev;
 
-	ret = hdmi_phy_resource_init(phy);
+	ret = msm_hdmi_phy_resource_init(phy);
 	if (ret)
 		return ret;
 
 	pm_runtime_enable(&pdev->dev);
 
-	ret = hdmi_phy_resource_enable(phy);
+	ret = msm_hdmi_phy_resource_enable(phy);
 	if (ret)
 		return ret;
 
-	ret = hdmi_phy_pll_init(pdev, phy->cfg->type);
+	ret = msm_hdmi_phy_pll_init(pdev, phy->cfg->type);
 	if (ret) {
 		dev_err(dev, "couldn't init PLL\n");
-		hdmi_phy_resource_disable(phy);
+		msm_hdmi_phy_resource_disable(phy);
 		return ret;
 	}
 
-	hdmi_phy_resource_disable(phy);
+	msm_hdmi_phy_resource_disable(phy);
 
 	platform_set_drvdata(pdev, phy);
 
 	return 0;
 }
 
-static int hdmi_phy_remove(struct platform_device *pdev)
+static int msm_hdmi_phy_remove(struct platform_device *pdev)
 {
 	pm_runtime_disable(&pdev->dev);
 
 	return 0;
 }
 
-static const struct of_device_id hdmi_phy_dt_match[] = {
+static const struct of_device_id msm_hdmi_phy_dt_match[] = {
 	{ .compatible = "qcom,hdmi-phy-8x60",
-	  .data = &hdmi_phy_8x60_cfg },
+	  .data = &msm_hdmi_phy_8x60_cfg },
 	{ .compatible = "qcom,hdmi-phy-8960",
-	  .data = &hdmi_phy_8960_cfg },
+	  .data = &msm_hdmi_phy_8960_cfg },
 	{ .compatible = "qcom,hdmi-phy-8x74",
-	  .data = &hdmi_phy_8x74_cfg },
+	  .data = &msm_hdmi_phy_8x74_cfg },
 	{ .compatible = "qcom,hdmi-phy-8996",
-	  .data = &hdmi_phy_8996_cfg },
+	  .data = &msm_hdmi_phy_8996_cfg },
 	{}
 };
 
-static struct platform_driver hdmi_phy_platform_driver = {
-	.probe      = hdmi_phy_probe,
-	.remove     = hdmi_phy_remove,
+static struct platform_driver msm_hdmi_phy_platform_driver = {
+	.probe      = msm_hdmi_phy_probe,
+	.remove     = msm_hdmi_phy_remove,
 	.driver     = {
 		.name   = "msm_hdmi_phy",
-		.of_match_table = hdmi_phy_dt_match,
+		.of_match_table = msm_hdmi_phy_dt_match,
 	},
 };
 
-void __init hdmi_phy_driver_register(void)
+void __init msm_hdmi_phy_driver_register(void)
 {
-	platform_driver_register(&hdmi_phy_platform_driver);
+	platform_driver_register(&msm_hdmi_phy_platform_driver);
 }
 
-void __exit hdmi_phy_driver_unregister(void)
+void __exit msm_hdmi_phy_driver_unregister(void)
 {
-	platform_driver_unregister(&hdmi_phy_platform_driver);
+	platform_driver_unregister(&msm_hdmi_phy_platform_driver);
 }
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c
index 46d449e84d71..e6ee6b745ab7 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c
@@ -51,7 +51,7 @@ static const char * const hdmi_phy_8960_clk_names[] = {
 	"slave_iface_clk",
 };
 
-const struct hdmi_phy_cfg hdmi_phy_8960_cfg = {
+const struct hdmi_phy_cfg msm_hdmi_phy_8960_cfg = {
 	.type = MSM_HDMI_PHY_8960,
 	.powerup = hdmi_phy_8960_powerup,
 	.powerdown = hdmi_phy_8960_powerdown,
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c
index ed38976e599a..aa94a553794f 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c
@@ -704,7 +704,7 @@ static struct clk_init_data pll_init = {
 	.num_parents = ARRAY_SIZE(hdmi_pll_parents),
 };
 
-int hdmi_pll_8996_init(struct platform_device *pdev)
+int msm_hdmi_pll_8996_init(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct hdmi_pll_8996 *pll;
@@ -757,7 +757,7 @@ static const char * const hdmi_phy_8996_clk_names[] = {
 	"ref_clk",
 };
 
-const struct hdmi_phy_cfg hdmi_phy_8996_cfg = {
+const struct hdmi_phy_cfg msm_hdmi_phy_8996_cfg = {
 	.type = MSM_HDMI_PHY_8996,
 	.reg_names = hdmi_phy_8996_reg_names,
 	.num_regs = ARRAY_SIZE(hdmi_phy_8996_reg_names),
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c
index 38022b3af8c1..a68eea4153fc 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c
@@ -131,7 +131,7 @@ static void hdmi_phy_8x60_powerdown(struct hdmi_phy *phy)
 		       HDMI_8x60_PHY_REG2_PD_DESER);
 }
 
-const struct hdmi_phy_cfg hdmi_phy_8x60_cfg = {
+const struct hdmi_phy_cfg msm_hdmi_phy_8x60_cfg = {
 	.type = MSM_HDMI_PHY_8x60,
 	.powerup = hdmi_phy_8x60_powerup,
 	.powerdown = hdmi_phy_8x60_powerdown,
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c
index 145e38eb17e2..c4a61e537851 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c
@@ -45,7 +45,7 @@ static const char * const hdmi_phy_8x74_clk_names[] = {
 	"alt_iface_clk"
 };
 
-const struct hdmi_phy_cfg hdmi_phy_8x74_cfg = {
+const struct hdmi_phy_cfg msm_hdmi_phy_8x74_cfg = {
 	.type = MSM_HDMI_PHY_8x74,
 	.powerup = hdmi_phy_8x74_powerup,
 	.powerdown = hdmi_phy_8x74_powerdown,
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.c b/drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.c
index 35830a9ab615..92da69aa6187 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.c
@@ -426,7 +426,7 @@ static struct clk_init_data pll_init = {
 	.num_parents = ARRAY_SIZE(hdmi_pll_parents),
 };
 
-int hdmi_pll_8960_init(struct platform_device *pdev)
+int msm_hdmi_pll_8960_init(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct hdmi_pll_8960 *pll;
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index 54b9d9b79bba..76e1dfb5d25e 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -326,7 +326,7 @@ static int mdp4_modeset_init_intf(struct mdp4_kms *mdp4_kms,
 
 		if (priv->hdmi) {
 			/* Construct bridge/connector for HDMI: */
-			ret = hdmi_modeset_init(priv->hdmi, dev, encoder);
+			ret = msm_hdmi_modeset_init(priv->hdmi, dev, encoder);
 			if (ret) {
 				dev_err(dev->dev, "failed to initialize HDMI: %d\n", ret);
 				return ret;
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 5e4d16b399c7..484b4d15e71d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -284,7 +284,7 @@ static int modeset_init_intf(struct mdp5_kms *mdp5_kms, int intf_num)
 			break;
 		}
 
-		ret = hdmi_modeset_init(priv->hdmi, dev, encoder);
+		ret = msm_hdmi_modeset_init(priv->hdmi, dev, encoder);
 		break;
 	case INTF_DSI:
 	{
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 280503e19bfd..d52910e2c26c 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1121,7 +1121,7 @@ static int __init msm_drm_register(void)
 	DBG("init");
 	msm_dsi_register();
 	msm_edp_register();
-	hdmi_register();
+	msm_hdmi_register();
 	adreno_register();
 	return platform_driver_register(&msm_platform_driver);
 }
@@ -1130,7 +1130,7 @@ static void __exit msm_drm_unregister(void)
 {
 	DBG("fini");
 	platform_driver_unregister(&msm_platform_driver);
-	hdmi_unregister();
+	msm_hdmi_unregister();
 	adreno_unregister();
 	msm_edp_unregister();
 	msm_dsi_unregister();
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 6980aa4510cb..a2755b4a0d86 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -244,22 +244,22 @@ void msm_fbdev_free(struct drm_device *dev);
 
 struct hdmi;
 #ifdef CONFIG_DRM_MSM_HDMI
-int hdmi_modeset_init(struct hdmi *hdmi, struct drm_device *dev,
+int msm_hdmi_modeset_init(struct hdmi *hdmi, struct drm_device *dev,
 		struct drm_encoder *encoder);
-void __init hdmi_register(void);
-void __exit hdmi_unregister(void);
+void __init msm_hdmi_register(void);
+void __exit msm_hdmi_unregister(void);
 #else
-static inline int hdmi_modeset_init(struct hdmi *hdmi, struct drm_device *dev,
+static inline int msm_hdmi_modeset_init(struct hdmi *hdmi, struct drm_device *dev,
 				    struct drm_encoder *encoder)
 {
 	return -EINVAL;
 }
 
-static inline void __init hdmi_register(void)
+static inline void __init msm_hdmi_register(void)
 {
 }
 
-static inline void __exit hdmi_unregister(void)
+static inline void __exit msm_hdmi_unregister(void)
 {
 }
 #endif
-- 
2.7.0



From arnd at arndb.de  Mon Feb 22 13:08:36 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Feb 2016 22:08:36 +0100
Subject: [PATCH 2/8] drm: msm: rename module
In-Reply-To: <1456175331-714117-1-git-send-email-arnd@arndb.de>
References: <1456175331-714117-1-git-send-email-arnd@arndb.de>
Message-ID: <1456175331-714117-3-git-send-email-arnd@arndb.de>

msm.ko is not an appropriate name for a module that drives a specific
device on the msm platform. This changes the name to drm_msm.ko
to have something that won't conflict with any other module name.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/gpu/drm/msm/Makefile | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 9386cfeb55b2..24f6fd2b9651 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -1,6 +1,6 @@
 ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/msm
 
-msm-y := \
+drm-msm-y := \
 	adreno/adreno_device.o \
 	adreno/adreno_gpu.o \
 	adreno/a3xx_gpu.o \
@@ -34,14 +34,14 @@ msm-y := \
 	msm_rd.o \
 	msm_ringbuffer.o
 
-msm-$(CONFIG_DRM_MSM_DSI) += mdp/mdp4/mdp4_dsi_encoder.o \
-			     mdp/mdp5/mdp5_cmd_encoder.o
+drm-msm-$(CONFIG_DRM_MSM_DSI) += mdp/mdp4/mdp4_dsi_encoder.o \
+				 mdp/mdp5/mdp5_cmd_encoder.o
 
-msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o
-msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
+drm-msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o
+drm-msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
 
 obj-$(CONFIG_DRM_MSM_DSI) += dsi/
 obj-$(CONFIG_DRM_MSM_HDMI) += hdmi/
 obj-$(CONFIG_DRM_MSM_EDP) += edp/
 
-obj-$(CONFIG_DRM_MSM)	+= msm.o
+obj-$(CONFIG_DRM_MSM)	+= drm-msm.o
-- 
2.7.0



From arnd at arndb.de  Mon Feb 22 13:08:37 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Feb 2016 22:08:37 +0100
Subject: [PATCH 3/8] drm: msm: split out fence and iotrace modules
In-Reply-To: <1456175331-714117-1-git-send-email-arnd@arndb.de>
References: <1456175331-714117-1-git-send-email-arnd@arndb.de>
Message-ID: <1456175331-714117-4-git-send-email-arnd@arndb.de>

This is a preparation for having edp, dsi and hdmi in separate
modules. Those three drivers depend on the iotrace code and,
and edp depends on gem, which in turn depends on the fence.

With this change, those two pieces of the main driver can be
loaded first, to resolve circular dependencies.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/gpu/drm/msm/Kconfig       |   2 +-
 drivers/gpu/drm/msm/Makefile      |   4 +-
 drivers/gpu/drm/msm/msm_drv.c     | 165 --------------------------------------
 drivers/gpu/drm/msm/msm_drv.h     |  12 +++
 drivers/gpu/drm/msm/msm_fence.c   | 115 ++++++++++++++++++++++++++
 drivers/gpu/drm/msm/msm_iotrace.c |  65 +++++++++++++++
 6 files changed, 196 insertions(+), 167 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/msm_fence.c
 create mode 100644 drivers/gpu/drm/msm/msm_iotrace.c

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index b8beb9bccd91..d987c584d817 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -21,7 +21,7 @@ config DRM_MSM_REGISTER_LOGGING
 	help
 	  Compile in support for logging register reads/writes in a format
 	  that can be parsed by envytools demsm tool.  If enabled, register
-	  logging can be switched on via msm.reglog=y module param.
+	  logging can be switched on via msm_iotrace.reglog=y module param.
 
 source "drivers/gpu/drm/msm/dsi/Kconfig"
 source "drivers/gpu/drm/msm/hdmi/Kconfig"
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 24f6fd2b9651..acc02aef1b42 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -44,4 +44,6 @@ obj-$(CONFIG_DRM_MSM_DSI) += dsi/
 obj-$(CONFIG_DRM_MSM_HDMI) += hdmi/
 obj-$(CONFIG_DRM_MSM_EDP) += edp/
 
-obj-$(CONFIG_DRM_MSM)	+= drm-msm.o
+obj-$(CONFIG_DRM_MSM)	+= drm-msm.o drm_msm_helper.o
+
+drm_msm_helper-y	+= msm_iotrace.o msm_fence.o
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index d52910e2c26c..5430ea7d2375 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -46,14 +46,6 @@ int msm_register_mmu(struct drm_device *dev, struct msm_mmu *mmu)
 	return idx;
 }
 
-#ifdef CONFIG_DRM_MSM_REGISTER_LOGGING
-static bool reglog = false;
-MODULE_PARM_DESC(reglog, "Enable register read/write logging");
-module_param(reglog, bool, 0600);
-#else
-#define reglog 0
-#endif
-
 #ifdef CONFIG_DRM_FBDEV_EMULATION
 static bool fbdev = true;
 MODULE_PARM_DESC(fbdev, "Enable fbdev compat layer");
@@ -64,56 +56,6 @@ static char *vram = "16m";
 MODULE_PARM_DESC(vram, "Configure VRAM size (for devices without IOMMU/GPUMMU)");
 module_param(vram, charp, 0);
 
-/*
- * Util/helpers:
- */
-
-void __iomem *msm_ioremap(struct platform_device *pdev, const char *name,
-		const char *dbgname)
-{
-	struct resource *res;
-	unsigned long size;
-	void __iomem *ptr;
-
-	if (name)
-		res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
-	else
-		res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
-	if (!res) {
-		dev_err(&pdev->dev, "failed to get memory resource: %s\n", name);
-		return ERR_PTR(-EINVAL);
-	}
-
-	size = resource_size(res);
-
-	ptr = devm_ioremap_nocache(&pdev->dev, res->start, size);
-	if (!ptr) {
-		dev_err(&pdev->dev, "failed to ioremap: %s\n", name);
-		return ERR_PTR(-ENOMEM);
-	}
-
-	if (reglog)
-		printk(KERN_DEBUG "IO:region %s %p %08lx\n", dbgname, ptr, size);
-
-	return ptr;
-}
-
-void msm_writel(u32 data, void __iomem *addr)
-{
-	if (reglog)
-		printk(KERN_DEBUG "IO:W %p %08x\n", addr, data);
-	writel(data, addr);
-}
-
-u32 msm_readl(const void __iomem *addr)
-{
-	u32 val = readl(addr);
-	if (reglog)
-		printk(KERN_ERR "IO:R %p %08x\n", addr, val);
-	return val;
-}
-
 struct vblank_event {
 	struct list_head node;
 	int crtc_id;
@@ -691,113 +633,6 @@ static void msm_debugfs_cleanup(struct drm_minor *minor)
 #endif
 
 /*
- * Fences:
- */
-
-int msm_wait_fence(struct drm_device *dev, uint32_t fence,
-		ktime_t *timeout , bool interruptible)
-{
-	struct msm_drm_private *priv = dev->dev_private;
-	int ret;
-
-	if (!priv->gpu)
-		return 0;
-
-	if (fence > priv->gpu->submitted_fence) {
-		DRM_ERROR("waiting on invalid fence: %u (of %u)\n",
-				fence, priv->gpu->submitted_fence);
-		return -EINVAL;
-	}
-
-	if (!timeout) {
-		/* no-wait: */
-		ret = fence_completed(dev, fence) ? 0 : -EBUSY;
-	} else {
-		ktime_t now = ktime_get();
-		unsigned long remaining_jiffies;
-
-		if (ktime_compare(*timeout, now) < 0) {
-			remaining_jiffies = 0;
-		} else {
-			ktime_t rem = ktime_sub(*timeout, now);
-			struct timespec ts = ktime_to_timespec(rem);
-			remaining_jiffies = timespec_to_jiffies(&ts);
-		}
-
-		if (interruptible)
-			ret = wait_event_interruptible_timeout(priv->fence_event,
-				fence_completed(dev, fence),
-				remaining_jiffies);
-		else
-			ret = wait_event_timeout(priv->fence_event,
-				fence_completed(dev, fence),
-				remaining_jiffies);
-
-		if (ret == 0) {
-			DBG("timeout waiting for fence: %u (completed: %u)",
-					fence, priv->completed_fence);
-			ret = -ETIMEDOUT;
-		} else if (ret != -ERESTARTSYS) {
-			ret = 0;
-		}
-	}
-
-	return ret;
-}
-
-int msm_queue_fence_cb(struct drm_device *dev,
-		struct msm_fence_cb *cb, uint32_t fence)
-{
-	struct msm_drm_private *priv = dev->dev_private;
-	int ret = 0;
-
-	mutex_lock(&dev->struct_mutex);
-	if (!list_empty(&cb->work.entry)) {
-		ret = -EINVAL;
-	} else if (fence > priv->completed_fence) {
-		cb->fence = fence;
-		list_add_tail(&cb->work.entry, &priv->fence_cbs);
-	} else {
-		queue_work(priv->wq, &cb->work);
-	}
-	mutex_unlock(&dev->struct_mutex);
-
-	return ret;
-}
-
-/* called from workqueue */
-void msm_update_fence(struct drm_device *dev, uint32_t fence)
-{
-	struct msm_drm_private *priv = dev->dev_private;
-
-	mutex_lock(&dev->struct_mutex);
-	priv->completed_fence = max(fence, priv->completed_fence);
-
-	while (!list_empty(&priv->fence_cbs)) {
-		struct msm_fence_cb *cb;
-
-		cb = list_first_entry(&priv->fence_cbs,
-				struct msm_fence_cb, work.entry);
-
-		if (cb->fence > priv->completed_fence)
-			break;
-
-		list_del_init(&cb->work.entry);
-		queue_work(priv->wq, &cb->work);
-	}
-
-	mutex_unlock(&dev->struct_mutex);
-
-	wake_up_all(&priv->fence_event);
-}
-
-void __msm_fence_worker(struct work_struct *work)
-{
-	struct msm_fence_cb *cb = container_of(work, struct msm_fence_cb, work);
-	cb->func(cb);
-}
-
-/*
  * DRM ioctls:
  */
 
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index a2755b4a0d86..b8bd88b66c9c 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -28,6 +28,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/slab.h>
 #include <linux/list.h>
+#include <linux/io.h>
 #include <linux/iommu.h>
 #include <linux/types.h>
 #include <linux/of_graph.h>
@@ -330,8 +331,19 @@ static inline void msm_rd_dump_submit(struct msm_gem_submit *submit) {}
 
 void __iomem *msm_ioremap(struct platform_device *pdev, const char *name,
 		const char *dbgname);
+#ifdef CONFIG_DRM_MSM_REGISTER_LOGGING
 void msm_writel(u32 data, void __iomem *addr);
 u32 msm_readl(const void __iomem *addr);
+#else
+static inline void msm_writel(u32 data, void __iomem *addr)
+{
+	writel(data, addr);
+}
+static inline u32 msm_readl(const void __iomem *addr)
+{
+	return readl(addr);
+}
+#endif
 
 #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
 #define VERB(fmt, ...) if (0) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
diff --git a/drivers/gpu/drm/msm/msm_fence.c b/drivers/gpu/drm/msm/msm_fence.c
new file mode 100644
index 000000000000..df66e04e01d8
--- /dev/null
+++ b/drivers/gpu/drm/msm/msm_fence.c
@@ -0,0 +1,115 @@
+#include <linux/ktime.h>
+#include <linux/module.h>
+#include <linux/types.h>
+
+#include <drm/drmP.h>
+
+#include "msm_drv.h"
+#include "msm_gpu.h"
+
+int msm_wait_fence(struct drm_device *dev, uint32_t fence,
+		ktime_t *timeout , bool interruptible)
+{
+	struct msm_drm_private *priv = dev->dev_private;
+	int ret;
+
+	if (!priv->gpu)
+		return 0;
+
+	if (fence > priv->gpu->submitted_fence) {
+		DRM_ERROR("waiting on invalid fence: %u (of %u)\n",
+				fence, priv->gpu->submitted_fence);
+		return -EINVAL;
+	}
+
+	if (!timeout) {
+		/* no-wait: */
+		ret = fence_completed(dev, fence) ? 0 : -EBUSY;
+	} else {
+		ktime_t now = ktime_get();
+		unsigned long remaining_jiffies;
+
+		if (ktime_compare(*timeout, now) < 0) {
+			remaining_jiffies = 0;
+		} else {
+			ktime_t rem = ktime_sub(*timeout, now);
+			struct timespec ts = ktime_to_timespec(rem);
+			remaining_jiffies = timespec_to_jiffies(&ts);
+		}
+
+		if (interruptible)
+			ret = wait_event_interruptible_timeout(priv->fence_event,
+				fence_completed(dev, fence),
+				remaining_jiffies);
+		else
+			ret = wait_event_timeout(priv->fence_event,
+				fence_completed(dev, fence),
+				remaining_jiffies);
+
+		if (ret == 0) {
+			DBG("timeout waiting for fence: %u (completed: %u)",
+					fence, priv->completed_fence);
+			ret = -ETIMEDOUT;
+		} else if (ret != -ERESTARTSYS) {
+			ret = 0;
+		}
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(msm_wait_fence);
+
+int msm_queue_fence_cb(struct drm_device *dev,
+		struct msm_fence_cb *cb, uint32_t fence)
+{
+	struct msm_drm_private *priv = dev->dev_private;
+	int ret = 0;
+
+	mutex_lock(&dev->struct_mutex);
+	if (!list_empty(&cb->work.entry)) {
+		ret = -EINVAL;
+	} else if (fence > priv->completed_fence) {
+		cb->fence = fence;
+		list_add_tail(&cb->work.entry, &priv->fence_cbs);
+	} else {
+		queue_work(priv->wq, &cb->work);
+	}
+	mutex_unlock(&dev->struct_mutex);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(msm_queue_fence_cb);
+
+/* called from workqueue */
+void msm_update_fence(struct drm_device *dev, uint32_t fence)
+{
+	struct msm_drm_private *priv = dev->dev_private;
+
+	mutex_lock(&dev->struct_mutex);
+	priv->completed_fence = max(fence, priv->completed_fence);
+
+	while (!list_empty(&priv->fence_cbs)) {
+		struct msm_fence_cb *cb;
+
+		cb = list_first_entry(&priv->fence_cbs,
+				struct msm_fence_cb, work.entry);
+
+		if (cb->fence > priv->completed_fence)
+			break;
+
+		list_del_init(&cb->work.entry);
+		queue_work(priv->wq, &cb->work);
+	}
+
+	mutex_unlock(&dev->struct_mutex);
+
+	wake_up_all(&priv->fence_event);
+}
+EXPORT_SYMBOL_GPL(msm_update_fence);
+
+void __msm_fence_worker(struct work_struct *work)
+{
+	struct msm_fence_cb *cb = container_of(work, struct msm_fence_cb, work);
+	cb->func(cb);
+}
+EXPORT_SYMBOL_GPL(__msm_fence_worker);
diff --git a/drivers/gpu/drm/msm/msm_iotrace.c b/drivers/gpu/drm/msm/msm_iotrace.c
new file mode 100644
index 000000000000..7761470eee26
--- /dev/null
+++ b/drivers/gpu/drm/msm/msm_iotrace.c
@@ -0,0 +1,65 @@
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/platform_device.h>
+#include <linux/printk.h>
+#include <linux/module.h>
+
+static bool reglog = false;
+
+#ifdef CONFIG_DRM_MSM_REGISTER_LOGGING
+MODULE_PARM_DESC(reglog, "Enable register read/write logging");
+module_param(reglog, bool, 0600);
+
+void msm_writel(u32 data, void __iomem *addr)
+{
+	if (reglog)
+		printk(KERN_DEBUG "IO:W %p %08x\n", addr, data);
+	writel(data, addr);
+}
+EXPORT_SYMBOL_GPL(msm_writel);
+
+u32 msm_readl(const void __iomem *addr)
+{
+	u32 val = readl(addr);
+	if (reglog)
+		printk(KERN_ERR "IO:R %p %08x\n", addr, val);
+	return val;
+}
+EXPORT_SYMBOL_GPL(msm_readl);
+#endif
+
+void __iomem *msm_ioremap(struct platform_device *pdev, const char *name,
+		const char *dbgname)
+{
+	struct resource *res;
+	unsigned long size;
+	void __iomem *ptr;
+
+	if (name)
+		res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
+	else
+		res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+	if (!res) {
+		dev_err(&pdev->dev, "failed to get memory resource: %s\n", name);
+		return ERR_PTR(-EINVAL);
+	}
+
+	size = resource_size(res);
+
+	ptr = devm_ioremap_nocache(&pdev->dev, res->start, size);
+	if (!ptr) {
+		dev_err(&pdev->dev, "failed to ioremap: %s\n", name);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	if (reglog)
+		printk(KERN_DEBUG "IO:region %s %p %08lx\n", dbgname, ptr, size);
+
+	return ptr;
+}
+EXPORT_SYMBOL_GPL(msm_ioremap);
+
+MODULE_AUTHOR("Rob Clark <robdclark at gmail.com");
+MODULE_DESCRIPTION("MSM DRM Driver support code");
+MODULE_LICENSE("GPL");
-- 
2.7.0



From arnd at arndb.de  Mon Feb 22 13:08:38 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Feb 2016 22:08:38 +0100
Subject: [PATCH 4/8] drm: msm: split out GEM code into helper module
In-Reply-To: <1456175331-714117-1-git-send-email-arnd@arndb.de>
References: <1456175331-714117-1-git-send-email-arnd@arndb.de>
Message-ID: <1456175331-714117-5-git-send-email-arnd@arndb.de>

The GEM code is used by dsi, so it can't be part of
the main module. This exports all functions that are called
by other code, and puts it into the helper module.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/gpu/drm/msm/Makefile  |  3 +--
 drivers/gpu/drm/msm/msm_gem.c | 29 +++++++++++++++++++++++++++++
 2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index acc02aef1b42..6817e9390153 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -25,7 +25,6 @@ drm-msm-y := \
 	msm_atomic.o \
 	msm_drv.o \
 	msm_fb.o \
-	msm_gem.o \
 	msm_gem_prime.o \
 	msm_gem_submit.o \
 	msm_gpu.o \
@@ -46,4 +45,4 @@ obj-$(CONFIG_DRM_MSM_EDP) += edp/
 
 obj-$(CONFIG_DRM_MSM)	+= drm-msm.o drm_msm_helper.o
 
-drm_msm_helper-y	+= msm_iotrace.o msm_fence.o
+drm_msm_helper-y	+= msm_iotrace.o msm_fence.o msm_gem.o
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 3cedb8d5c855..1d64febee274 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -143,11 +143,13 @@ struct page **msm_gem_get_pages(struct drm_gem_object *obj)
 	mutex_unlock(&dev->struct_mutex);
 	return p;
 }
+EXPORT_SYMBOL_GPL(msm_gem_get_pages);
 
 void msm_gem_put_pages(struct drm_gem_object *obj)
 {
 	/* when we start tracking the pin count, then do something here */
 }
+EXPORT_SYMBOL_GPL(msm_gem_put_pages);
 
 int msm_gem_mmap_obj(struct drm_gem_object *obj,
 		struct vm_area_struct *vma)
@@ -177,6 +179,7 @@ int msm_gem_mmap_obj(struct drm_gem_object *obj,
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(msm_gem_mmap_obj);
 
 int msm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
 {
@@ -190,6 +193,7 @@ int msm_gem_mmap(struct file *filp, struct vm_area_struct *vma)
 
 	return msm_gem_mmap_obj(vma->vm_private_data, vma);
 }
+EXPORT_SYMBOL_GPL(msm_gem_mmap);
 
 int msm_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
@@ -246,6 +250,7 @@ out:
 		return VM_FAULT_SIGBUS;
 	}
 }
+EXPORT_SYMBOL_GPL(msm_gem_fault);
 
 /** get mmap offset */
 static uint64_t mmap_offset(struct drm_gem_object *obj)
@@ -274,6 +279,7 @@ uint64_t msm_gem_mmap_offset(struct drm_gem_object *obj)
 	mutex_unlock(&obj->dev->struct_mutex);
 	return offset;
 }
+EXPORT_SYMBOL_GPL(msm_gem_mmap_offset);
 
 /* should be called under struct_mutex.. although it can be called
  * from atomic context without struct_mutex to acquire an extra
@@ -316,6 +322,7 @@ int msm_gem_get_iova_locked(struct drm_gem_object *obj, int id,
 
 	return ret;
 }
+EXPORT_SYMBOL_GPL(msm_gem_get_iova_locked);
 
 /* get iova, taking a reference.  Should have a matching put */
 int msm_gem_get_iova(struct drm_gem_object *obj, int id, uint32_t *iova)
@@ -336,6 +343,7 @@ int msm_gem_get_iova(struct drm_gem_object *obj, int id, uint32_t *iova)
 	mutex_unlock(&obj->dev->struct_mutex);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(msm_gem_get_iova);
 
 /* get iova without taking a reference, used in places where you have
  * already done a 'msm_gem_get_iova()'.
@@ -346,6 +354,7 @@ uint32_t msm_gem_iova(struct drm_gem_object *obj, int id)
 	WARN_ON(!msm_obj->domain[id].iova);
 	return msm_obj->domain[id].iova;
 }
+EXPORT_SYMBOL_GPL(msm_gem_iova);
 
 void msm_gem_put_iova(struct drm_gem_object *obj, int id)
 {
@@ -356,6 +365,7 @@ void msm_gem_put_iova(struct drm_gem_object *obj, int id)
 	// if another _get_iova_locked() fails we can start unmapping
 	// things that are no longer needed..
 }
+EXPORT_SYMBOL_GPL(msm_gem_put_iova);
 
 int msm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
 		struct drm_mode_create_dumb *args)
@@ -365,6 +375,7 @@ int msm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
 	return msm_gem_new_handle(dev, file, args->size,
 			MSM_BO_SCANOUT | MSM_BO_WC, &args->handle);
 }
+EXPORT_SYMBOL_GPL(msm_gem_dumb_create);
 
 int msm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
 		uint32_t handle, uint64_t *offset)
@@ -386,6 +397,7 @@ int msm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
 fail:
 	return ret;
 }
+EXPORT_SYMBOL_GPL(msm_gem_dumb_map_offset);
 
 void *msm_gem_vaddr_locked(struct drm_gem_object *obj)
 {
@@ -400,6 +412,7 @@ void *msm_gem_vaddr_locked(struct drm_gem_object *obj)
 	}
 	return msm_obj->vaddr;
 }
+EXPORT_SYMBOL_GPL(msm_gem_vaddr_locked);
 
 void *msm_gem_vaddr(struct drm_gem_object *obj)
 {
@@ -409,6 +422,7 @@ void *msm_gem_vaddr(struct drm_gem_object *obj)
 	mutex_unlock(&obj->dev->struct_mutex);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(msm_gem_vaddr);
 
 /* setup callback for when bo is no longer busy..
  * TODO probably want to differentiate read vs write..
@@ -421,6 +435,7 @@ int msm_gem_queue_inactive_cb(struct drm_gem_object *obj,
 			MSM_PREP_READ | MSM_PREP_WRITE);
 	return msm_queue_fence_cb(obj->dev, cb, fence);
 }
+EXPORT_SYMBOL_GPL(msm_gem_queue_inactive_cb);
 
 void msm_gem_move_to_active(struct drm_gem_object *obj,
 		struct msm_gpu *gpu, bool write, uint32_t fence)
@@ -434,6 +449,7 @@ void msm_gem_move_to_active(struct drm_gem_object *obj,
 	list_del_init(&msm_obj->mm_list);
 	list_add_tail(&msm_obj->mm_list, &gpu->active_list);
 }
+EXPORT_SYMBOL_GPL(msm_gem_move_to_active);
 
 void msm_gem_move_to_inactive(struct drm_gem_object *obj)
 {
@@ -449,6 +465,7 @@ void msm_gem_move_to_inactive(struct drm_gem_object *obj)
 	list_del_init(&msm_obj->mm_list);
 	list_add_tail(&msm_obj->mm_list, &priv->inactive_list);
 }
+EXPORT_SYMBOL_GPL(msm_gem_move_to_inactive);
 
 int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t *timeout)
 {
@@ -469,12 +486,14 @@ int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t *timeout)
 
 	return ret;
 }
+EXPORT_SYMBOL_GPL(msm_gem_cpu_prep);
 
 int msm_gem_cpu_fini(struct drm_gem_object *obj)
 {
 	/* TODO cache maintenance */
 	return 0;
 }
+EXPORT_SYMBOL_GPL(msm_gem_cpu_fini);
 
 #ifdef CONFIG_DEBUG_FS
 void msm_gem_describe(struct drm_gem_object *obj, struct seq_file *m)
@@ -490,6 +509,7 @@ void msm_gem_describe(struct drm_gem_object *obj, struct seq_file *m)
 			obj->name, obj->refcount.refcount.counter,
 			off, msm_obj->vaddr, obj->size);
 }
+EXPORT_SYMBOL_GPL(msm_gem_describe);
 
 void msm_gem_describe_objects(struct list_head *list, struct seq_file *m)
 {
@@ -507,6 +527,7 @@ void msm_gem_describe_objects(struct list_head *list, struct seq_file *m)
 
 	seq_printf(m, "Total %d objects, %zu bytes\n", count, size);
 }
+EXPORT_SYMBOL_GPL(msm_gem_describe_objects);
 #endif
 
 void msm_gem_free_object(struct drm_gem_object *obj)
@@ -554,6 +575,7 @@ void msm_gem_free_object(struct drm_gem_object *obj)
 
 	kfree(msm_obj);
 }
+EXPORT_SYMBOL_GPL(msm_gem_free_object);
 
 /* convenience method to construct a GEM buffer object, and userspace handle */
 int msm_gem_new_handle(struct drm_device *dev, struct drm_file *file,
@@ -580,6 +602,7 @@ int msm_gem_new_handle(struct drm_device *dev, struct drm_file *file,
 
 	return ret;
 }
+EXPORT_SYMBOL_GPL(msm_gem_new_handle);
 
 static int msm_gem_new_impl(struct drm_device *dev,
 		uint32_t size, uint32_t flags,
@@ -663,6 +686,7 @@ fail:
 
 	return ERR_PTR(ret);
 }
+EXPORT_SYMBOL_GPL(msm_gem_new);
 
 struct drm_gem_object *msm_gem_import(struct drm_device *dev,
 		uint32_t size, struct sg_table *sgt)
@@ -707,3 +731,8 @@ fail:
 
 	return ERR_PTR(ret);
 }
+EXPORT_SYMBOL_GPL(msm_gem_import);
+
+MODULE_AUTHOR("Rob Clark <robdclark at gmail.com");
+MODULE_DESCRIPTION("MSM DRM Driver GEM implementation");
+MODULE_LICENSE("GPL");
-- 
2.7.0



From arnd at arndb.de  Mon Feb 22 13:08:39 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Feb 2016 22:08:39 +0100
Subject: [PATCH 5/8] drm: msm: move DSI into separate module
In-Reply-To: <1456175331-714117-1-git-send-email-arnd@arndb.de>
References: <1456175331-714117-1-git-send-email-arnd@arndb.de>
Message-ID: <1456175331-714117-6-git-send-email-arnd@arndb.de>

Moving around the Makefile for DSI caused a link error with
the main driver referring to a builtin module that has no
exported symbols:

drivers/gpu/built-in.o: In function `msm_drm_register':
:(.init.text+0x654): undefined reference to `msm_dsi_register'

This changes the DSI symbol to a 'tristate' so we can build it
as a module, and exports the symbols as necessary.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/gpu/drm/msm/Makefile            |  4 ++--
 drivers/gpu/drm/msm/dsi/Kconfig         |  7 ++++++-
 drivers/gpu/drm/msm/dsi/Makefile        | 16 +++++++++-------
 drivers/gpu/drm/msm/dsi/dsi.c           |  6 ++++--
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |  2 +-
 drivers/gpu/drm/msm/msm_drv.h           |  2 +-
 7 files changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 6817e9390153..4b18a2c670b9 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -33,13 +33,13 @@ drm-msm-y := \
 	msm_rd.o \
 	msm_ringbuffer.o
 
-drm-msm-$(CONFIG_DRM_MSM_DSI) += mdp/mdp4/mdp4_dsi_encoder.o \
+drm-msm-$(CONFIG_DRM_MSM_DSI_MODULE) += mdp/mdp4/mdp4_dsi_encoder.o \
 				 mdp/mdp5/mdp5_cmd_encoder.o
 
 drm-msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o
 drm-msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
 
-obj-$(CONFIG_DRM_MSM_DSI) += dsi/
+obj-$(CONFIG_DRM_MSM_DSI_MODULE) += dsi/
 obj-$(CONFIG_DRM_MSM_HDMI) += hdmi/
 obj-$(CONFIG_DRM_MSM_EDP) += edp/
 
diff --git a/drivers/gpu/drm/msm/dsi/Kconfig b/drivers/gpu/drm/msm/dsi/Kconfig
index 91dcf21bfc03..9cddaf0229f7 100644
--- a/drivers/gpu/drm/msm/dsi/Kconfig
+++ b/drivers/gpu/drm/msm/dsi/Kconfig
@@ -1,5 +1,5 @@
 config DRM_MSM_DSI
-	bool "Enable DSI support in MSM DRM driver"
+	tristate "Enable DSI support in MSM DRM driver"
 	depends on DRM_MSM
 	select DRM_PANEL
 	select DRM_MIPI_DSI
@@ -8,6 +8,11 @@ config DRM_MSM_DSI
 	  Choose this option if you have a need for MIPI DSI connector
 	  support.
 
+config DRM_MSM_DSI_MODULE
+	tristate
+	default y if DRM_MSM=y && DRM_MSM_DSI=m
+	default DRM_MSM_DSI
+
 if DRM_MSM_DSI
 
 config DRM_MSM_DSI_PLL
diff --git a/drivers/gpu/drm/msm/dsi/Makefile b/drivers/gpu/drm/msm/dsi/Makefile
index 26c8fb689229..53d1cdc16748 100644
--- a/drivers/gpu/drm/msm/dsi/Makefile
+++ b/drivers/gpu/drm/msm/dsi/Makefile
@@ -1,13 +1,15 @@
 ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/msm -Idrivers/gpu/drm/msm/dsi
 
-obj-y := dsi.o dsi_cfg.o dsi_host.o dsi_manager.o phy/dsi_phy.o
+obj-$(CONFIG_DRM_MSM_DSI_MODULE) += drm-msm-dsi.o
 
-obj-$(CONFIG_DRM_MSM_DSI_28NM_PHY) += phy/dsi_phy_28nm.o
-obj-$(CONFIG_DRM_MSM_DSI_20NM_PHY) += phy/dsi_phy_20nm.o
-obj-$(CONFIG_DRM_MSM_DSI_28NM_8960_PHY) += phy/dsi_phy_28nm_8960.o
+drm-msm-dsi-y := dsi.o dsi_cfg.o dsi_host.o dsi_manager.o phy/dsi_phy.o
+
+drm-msm-dsi-$(CONFIG_DRM_MSM_DSI_28NM_PHY) += phy/dsi_phy_28nm.o
+drm-msm-dsi-$(CONFIG_DRM_MSM_DSI_20NM_PHY) += phy/dsi_phy_20nm.o
+drm-msm-dsi-$(CONFIG_DRM_MSM_DSI_28NM_8960_PHY) += phy/dsi_phy_28nm_8960.o
 
 ifeq ($(CONFIG_DRM_MSM_DSI_PLL),y)
-obj-y += pll/dsi_pll.o
-obj-$(CONFIG_DRM_MSM_DSI_28NM_PHY) += pll/dsi_pll_28nm.o
-obj-$(CONFIG_DRM_MSM_DSI_28NM_8960_PHY) += pll/dsi_pll_28nm_8960.o
+drm-msm-dsi-y += pll/dsi_pll.o
+drm-msm-dsi-$(CONFIG_DRM_MSM_DSI_28NM_PHY) += pll/dsi_pll_28nm.o
+drm-msm-dsi-$(CONFIG_DRM_MSM_DSI_28NM_8960_PHY) += pll/dsi_pll_28nm_8960.o
 endif
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 6edcd6f57e70..8523a7cdc419 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -10,7 +10,7 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  */
-
+#include <linux/module.h>
 #include "dsi.h"
 
 struct drm_encoder *msm_dsi_get_encoder(struct msm_dsi *msm_dsi)
@@ -178,6 +178,7 @@ void __init msm_dsi_register(void)
 	msm_dsi_phy_driver_register();
 	platform_driver_register(&dsi_driver);
 }
+EXPORT_SYMBOL_GPL(msm_dsi_register);
 
 void __exit msm_dsi_unregister(void)
 {
@@ -185,6 +186,7 @@ void __exit msm_dsi_unregister(void)
 	msm_dsi_phy_driver_unregister();
 	platform_driver_unregister(&dsi_driver);
 }
+EXPORT_SYMBOL_GPL(msm_dsi_unregister);
 
 int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct drm_device *dev,
 		struct drm_encoder *encoders[MSM_DSI_ENCODER_NUM])
@@ -262,4 +264,4 @@ fail:
 
 	return ret;
 }
-
+EXPORT_SYMBOL_GPL(msm_dsi_modeset_init);
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
index b2828717be2a..3a9e7879d535 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
@@ -217,7 +217,7 @@ struct drm_encoder *mdp4_lcdc_encoder_init(struct drm_device *dev,
 struct drm_connector *mdp4_lvds_connector_init(struct drm_device *dev,
 		struct device_node *panel_node, struct drm_encoder *encoder);
 
-#ifdef CONFIG_DRM_MSM_DSI
+#if IS_ENABLED(CONFIG_DRM_MSM_DSI)
 struct drm_encoder *mdp4_dsi_encoder_init(struct drm_device *dev);
 #else
 static inline struct drm_encoder *mdp4_dsi_encoder_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index 9a25898239d3..6a1325fd71aa 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -224,7 +224,7 @@ int mdp5_encoder_set_split_display(struct drm_encoder *encoder,
 int mdp5_encoder_get_linecount(struct drm_encoder *encoder);
 u32 mdp5_encoder_get_framecount(struct drm_encoder *encoder);
 
-#ifdef CONFIG_DRM_MSM_DSI
+#if IS_ENABLED(CONFIG_DRM_MSM_DSI)
 struct drm_encoder *mdp5_cmd_encoder_init(struct drm_device *dev,
 		struct mdp5_interface *intf, struct mdp5_ctl *ctl);
 int mdp5_cmd_encoder_set_split_display(struct drm_encoder *encoder,
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index b8bd88b66c9c..86df81b46eb0 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -294,7 +294,7 @@ enum msm_dsi_encoder_id {
 	MSM_DSI_CMD_ENCODER_ID = 1,
 	MSM_DSI_ENCODER_NUM = 2
 };
-#ifdef CONFIG_DRM_MSM_DSI
+#if IS_ENABLED(CONFIG_DRM_MSM_DSI)
 void __init msm_dsi_register(void);
 void __exit msm_dsi_unregister(void);
 int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct drm_device *dev,
-- 
2.7.0



From arnd at arndb.de  Mon Feb 22 13:08:40 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Feb 2016 22:08:40 +0100
Subject: [PATCH 6/8] drm: msm: move EDP into separate module
In-Reply-To: <1456175331-714117-1-git-send-email-arnd@arndb.de>
References: <1456175331-714117-1-git-send-email-arnd@arndb.de>
Message-ID: <1456175331-714117-7-git-send-email-arnd@arndb.de>

Moving around the Makefile for EDP caused a link error with
the main driver referring to a builtin module that has no
exported symbols:

drivers/gpu/built-in.o: In function `msm_drm_register':
:(.init.text+0x654): undefined reference to `msm_edp_register'

This changes the EDP symbol to a 'tristate' so we can build it
as a module, and exports the symbols as necessary.

Fixes: 75a5cfa5739f ("drm/msm/edp: Create separate Makefile/Kconfig")
---
 drivers/gpu/drm/msm/Makefile     | 2 +-
 drivers/gpu/drm/msm/edp/Kconfig  | 7 ++++++-
 drivers/gpu/drm/msm/edp/Makefile | 4 +++-
 drivers/gpu/drm/msm/edp/edp.c    | 4 ++++
 drivers/gpu/drm/msm/msm_drv.h    | 2 +-
 5 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 4b18a2c670b9..e67bdaa14635 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -41,7 +41,7 @@ drm-msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
 
 obj-$(CONFIG_DRM_MSM_DSI_MODULE) += dsi/
 obj-$(CONFIG_DRM_MSM_HDMI) += hdmi/
-obj-$(CONFIG_DRM_MSM_EDP) += edp/
+obj-$(CONFIG_DRM_MSM_EDP_MODULE) += edp/
 
 obj-$(CONFIG_DRM_MSM)	+= drm-msm.o drm_msm_helper.o
 
diff --git a/drivers/gpu/drm/msm/edp/Kconfig b/drivers/gpu/drm/msm/edp/Kconfig
index 576d8c2fd713..b4cecabebc1d 100644
--- a/drivers/gpu/drm/msm/edp/Kconfig
+++ b/drivers/gpu/drm/msm/edp/Kconfig
@@ -1,7 +1,12 @@
 config DRM_MSM_EDP
-	bool "Enable EDP support in MSM DRM driver"
+	tristate "Enable EDP support in MSM DRM driver"
 	depends on DRM_MSM
 	default y
 	help
 	  Choose this option if you have a need for Embedded Display
 	  Port encoder support.
+
+config DRM_MSM_EDP_MODULE
+	tristate
+	default y if DRM_MSM=y && DRM_MSM_EDP=m
+	default DRM_MSM_EDP
diff --git a/drivers/gpu/drm/msm/edp/Makefile b/drivers/gpu/drm/msm/edp/Makefile
index e623d59d1706..37c45037f76f 100644
--- a/drivers/gpu/drm/msm/edp/Makefile
+++ b/drivers/gpu/drm/msm/edp/Makefile
@@ -1,3 +1,5 @@
 ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/msm
 
-obj-y := edp.o edp_aux.o edp_bridge.o edp_connector.o edp_ctrl.o edp_phy.o
+obj-$(CONFIG_DRM_MSM_EDP_MODULE) := drm-msm-edp.o
+
+drm-msm-edp-y := edp.o edp_aux.o edp_bridge.o edp_connector.o edp_ctrl.o edp_phy.o
diff --git a/drivers/gpu/drm/msm/edp/edp.c b/drivers/gpu/drm/msm/edp/edp.c
index 0940e84b2821..48645d0d649a 100644
--- a/drivers/gpu/drm/msm/edp/edp.c
+++ b/drivers/gpu/drm/msm/edp/edp.c
@@ -11,6 +11,7 @@
  * GNU General Public License for more details.
  */
 
+#include <linux/module.h>
 #include <linux/of_irq.h>
 #include "edp.h"
 
@@ -136,12 +137,14 @@ void __init msm_edp_register(void)
 	DBG("");
 	platform_driver_register(&edp_driver);
 }
+EXPORT_SYMBOL_GPL(msm_edp_register);
 
 void __exit msm_edp_unregister(void)
 {
 	DBG("");
 	platform_driver_unregister(&edp_driver);
 }
+EXPORT_SYMBOL_GPL(msm_edp_unregister);
 
 /* Second part of initialization, the drm/kms level modeset_init */
 int msm_edp_modeset_init(struct msm_edp *edp, struct drm_device *dev,
@@ -206,3 +209,4 @@ fail:
 
 	return ret;
 }
+EXPORT_SYMBOL_GPL(msm_edp_modeset_init);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 86df81b46eb0..8786738a6832 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -266,7 +266,7 @@ static inline void __exit msm_hdmi_unregister(void)
 #endif
 
 struct msm_edp;
-#ifdef CONFIG_DRM_MSM_EDP
+#if IS_ENABLED(CONFIG_DRM_MSM_EDP)
 void __init msm_edp_register(void);
 void __exit msm_edp_unregister(void);
 int msm_edp_modeset_init(struct msm_edp *edp, struct drm_device *dev,
-- 
2.7.0



From arnd at arndb.de  Mon Feb 22 13:08:41 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Feb 2016 22:08:41 +0100
Subject: [PATCH 7/8] drm: msm: move HDMI into separate module
In-Reply-To: <1456175331-714117-1-git-send-email-arnd@arndb.de>
References: <1456175331-714117-1-git-send-email-arnd@arndb.de>
Message-ID: <1456175331-714117-8-git-send-email-arnd@arndb.de>

Moving around the Makefile for HDMI caused a link error with
the main driver referring to a builtin module that has no
exported symbols:

drivers/gpu/built-in.o: In function `msm_drm_register':
:(.init.text+0x654): undefined reference to `msm_hdmi_register'

This changes the EDP symbol to a 'tristate' so we can build it
as a module, and exports the symbols as necessary.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 883656affe4d ("drm/msm/hdmi: Create separate Makefile/Kconfig")
---
 drivers/gpu/drm/msm/Makefile      | 2 +-
 drivers/gpu/drm/msm/hdmi/Kconfig  | 7 ++++++-
 drivers/gpu/drm/msm/hdmi/Makefile | 6 ++++--
 drivers/gpu/drm/msm/hdmi/hdmi.c   | 3 +++
 drivers/gpu/drm/msm/msm_drv.h     | 2 +-
 5 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index e67bdaa14635..06fd13989476 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -40,7 +40,7 @@ drm-msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o
 drm-msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
 
 obj-$(CONFIG_DRM_MSM_DSI_MODULE) += dsi/
-obj-$(CONFIG_DRM_MSM_HDMI) += hdmi/
+obj-$(CONFIG_DRM_MSM_HDMI_MODULE) += hdmi/
 obj-$(CONFIG_DRM_MSM_EDP_MODULE) += edp/
 
 obj-$(CONFIG_DRM_MSM)	+= drm-msm.o drm_msm_helper.o
diff --git a/drivers/gpu/drm/msm/hdmi/Kconfig b/drivers/gpu/drm/msm/hdmi/Kconfig
index 4b24e1e4bac4..8e9abaeae758 100644
--- a/drivers/gpu/drm/msm/hdmi/Kconfig
+++ b/drivers/gpu/drm/msm/hdmi/Kconfig
@@ -1,7 +1,12 @@
 config DRM_MSM_HDMI
-	bool "Enable HDMI support in MSM DRM driver"
+	tristate "Enable HDMI support in MSM DRM driver"
 	depends on DRM_MSM
 	default y
 	help
 	  Choose this option if you have a need for HDMI connector
 	  support.
+
+config DRM_MSM_HDMI_MODULE
+	tristate
+	default y if DRM_MSM=y && DRM_MSM_HDMI=m
+	default DRM_MSM_HDMI
diff --git a/drivers/gpu/drm/msm/hdmi/Makefile b/drivers/gpu/drm/msm/hdmi/Makefile
index 799dbca89bd4..6cb4598f48d7 100644
--- a/drivers/gpu/drm/msm/hdmi/Makefile
+++ b/drivers/gpu/drm/msm/hdmi/Makefile
@@ -1,6 +1,8 @@
 ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/msm
 
-obj-y := hdmi.o hdmi_phy.o hdmi_audio.o hdmi_bridge.o hdmi_connector.o \
+obj-$(CONFIG_DRM_MSM_HDMI_MODULE) += drm-msm-hdmi.o
+
+drm-msm-hdmi-y := hdmi.o hdmi_phy.o hdmi_audio.o hdmi_bridge.o hdmi_connector.o \
 	 hdmi_hdcp.o hdmi_i2c.o hdmi_phy_8960.o hdmi_phy_8x60.o hdmi_phy_8x74.o
 
-obj-$(CONFIG_COMMON_CLK) += hdmi_pll_8960.o hdmi_phy_8996.o
+drm-msm-hdmi-$(CONFIG_COMMON_CLK) += hdmi_pll_8960.o hdmi_phy_8996.o
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 3bcfb1ded8b3..8e01d942d1c9 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -343,6 +343,7 @@ fail:
 
 	return ret;
 }
+EXPORT_SYMBOL_GPL(msm_hdmi_modeset_init);
 
 /*
  * The hdmi device:
@@ -522,9 +523,11 @@ void __init msm_hdmi_register(void)
 	msm_hdmi_phy_driver_register();
 	platform_driver_register(&msm_hdmi_driver);
 }
+EXPORT_SYMBOL_GPL(msm_hdmi_register);
 
 void __exit msm_hdmi_unregister(void)
 {
 	platform_driver_unregister(&msm_hdmi_driver);
 	msm_hdmi_phy_driver_unregister();
 }
+EXPORT_SYMBOL_GPL(msm_hdmi_unregister);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 8786738a6832..905c17e373e7 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -244,7 +244,7 @@ struct drm_fb_helper *msm_fbdev_init(struct drm_device *dev);
 void msm_fbdev_free(struct drm_device *dev);
 
 struct hdmi;
-#ifdef CONFIG_DRM_MSM_HDMI
+#if IS_ENABLED(CONFIG_DRM_MSM_HDMI)
 int msm_hdmi_modeset_init(struct hdmi *hdmi, struct drm_device *dev,
 		struct drm_encoder *encoder);
 void __init msm_hdmi_register(void);
-- 
2.7.0



From arnd at arndb.de  Mon Feb 22 13:08:42 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Feb 2016 22:08:42 +0100
Subject: [PATCH 8/8] drm: msm: separate out module driver registration
In-Reply-To: <1456175331-714117-1-git-send-email-arnd@arndb.de>
References: <1456175331-714117-1-git-send-email-arnd@arndb.de>
Message-ID: <1456175331-714117-9-git-send-email-arnd@arndb.de>

The msm driver currently has a single module_init() function but
consists of multiple modules that each register a platform driver.

This changes the msm_drm_register() function to not call the
other functions but instead rely on module load order and/or
link order to ensure that the other modules were probed earlier.

The patch is not tested but should not change behavior.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/gpu/drm/msm/dsi/dsi.c         | 17 ++++++++++++-----
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c |  2 +-
 drivers/gpu/drm/msm/edp/edp.c         | 15 +--------------
 drivers/gpu/drm/msm/hdmi/hdmi.c       | 16 +++++++++++-----
 drivers/gpu/drm/msm/hdmi/hdmi.h       |  2 +-
 drivers/gpu/drm/msm/hdmi/hdmi_phy.c   |  2 +-
 drivers/gpu/drm/msm/msm_drv.c         |  6 ------
 drivers/gpu/drm/msm/msm_drv.h         | 28 ----------------------------
 8 files changed, 27 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 8523a7cdc419..db260814dfff 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -172,21 +172,28 @@ static struct platform_driver dsi_driver = {
 	},
 };
 
-void __init msm_dsi_register(void)
+static int __init msm_dsi_register(void)
 {
+	int ret;
+
 	DBG("");
 	msm_dsi_phy_driver_register();
-	platform_driver_register(&dsi_driver);
+	ret = platform_driver_register(&dsi_driver);
+
+	if (ret)
+		msm_dsi_phy_driver_unregister();
+
+	return ret;
 }
-EXPORT_SYMBOL_GPL(msm_dsi_register);
+module_init(msm_dsi_register);
 
-void __exit msm_dsi_unregister(void)
+static void __exit msm_dsi_unregister(void)
 {
 	DBG("");
 	msm_dsi_phy_driver_unregister();
 	platform_driver_unregister(&dsi_driver);
 }
-EXPORT_SYMBOL_GPL(msm_dsi_unregister);
+module_exit(msm_dsi_unregister);
 
 int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct drm_device *dev,
 		struct drm_encoder *encoders[MSM_DSI_ENCODER_NUM])
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 91a95fb04a4a..ab7106c150da 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -393,7 +393,7 @@ void __init msm_dsi_phy_driver_register(void)
 	platform_driver_register(&dsi_phy_platform_driver);
 }
 
-void __exit msm_dsi_phy_driver_unregister(void)
+void msm_dsi_phy_driver_unregister(void)
 {
 	platform_driver_unregister(&dsi_phy_platform_driver);
 }
diff --git a/drivers/gpu/drm/msm/edp/edp.c b/drivers/gpu/drm/msm/edp/edp.c
index 48645d0d649a..fb952bb4e0e0 100644
--- a/drivers/gpu/drm/msm/edp/edp.c
+++ b/drivers/gpu/drm/msm/edp/edp.c
@@ -131,20 +131,7 @@ static struct platform_driver edp_driver = {
 		.of_match_table = dt_match,
 	},
 };
-
-void __init msm_edp_register(void)
-{
-	DBG("");
-	platform_driver_register(&edp_driver);
-}
-EXPORT_SYMBOL_GPL(msm_edp_register);
-
-void __exit msm_edp_unregister(void)
-{
-	DBG("");
-	platform_driver_unregister(&edp_driver);
-}
-EXPORT_SYMBOL_GPL(msm_edp_unregister);
+module_platform_driver(edp_driver);
 
 /* Second part of initialization, the drm/kms level modeset_init */
 int msm_edp_modeset_init(struct msm_edp *edp, struct drm_device *dev,
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 8e01d942d1c9..20c77d933556 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -518,16 +518,22 @@ static struct platform_driver msm_hdmi_driver = {
 	},
 };
 
-void __init msm_hdmi_register(void)
+static int __init msm_hdmi_register(void)
 {
+	int ret;
+
 	msm_hdmi_phy_driver_register();
-	platform_driver_register(&msm_hdmi_driver);
+	ret = platform_driver_register(&msm_hdmi_driver);
+	if (ret)
+		msm_hdmi_phy_driver_unregister();
+
+	return ret;
 }
-EXPORT_SYMBOL_GPL(msm_hdmi_register);
+module_init(msm_hdmi_register);
 
-void __exit msm_hdmi_unregister(void)
+static void __exit msm_hdmi_unregister(void)
 {
 	platform_driver_unregister(&msm_hdmi_driver);
 	msm_hdmi_phy_driver_unregister();
 }
-EXPORT_SYMBOL_GPL(msm_hdmi_unregister);
+module_exit(msm_hdmi_unregister);
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index b04a64664673..23702d0057e4 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -190,7 +190,7 @@ void msm_hdmi_phy_resource_disable(struct hdmi_phy *phy);
 void msm_hdmi_phy_powerup(struct hdmi_phy *phy, unsigned long int pixclock);
 void msm_hdmi_phy_powerdown(struct hdmi_phy *phy);
 void __init msm_hdmi_phy_driver_register(void);
-void __exit msm_hdmi_phy_driver_unregister(void);
+void msm_hdmi_phy_driver_unregister(void);
 
 #ifdef CONFIG_COMMON_CLK
 int msm_hdmi_pll_8960_init(struct platform_device *pdev);
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
index 5530631e2d49..05ca860add6d 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy.c
@@ -222,7 +222,7 @@ void __init msm_hdmi_phy_driver_register(void)
 	platform_driver_register(&msm_hdmi_phy_platform_driver);
 }
 
-void __exit msm_hdmi_phy_driver_unregister(void)
+void msm_hdmi_phy_driver_unregister(void)
 {
 	platform_driver_unregister(&msm_hdmi_phy_platform_driver);
 }
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 5430ea7d2375..3d04cd922cf0 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -954,9 +954,6 @@ static struct platform_driver msm_platform_driver = {
 static int __init msm_drm_register(void)
 {
 	DBG("init");
-	msm_dsi_register();
-	msm_edp_register();
-	msm_hdmi_register();
 	adreno_register();
 	return platform_driver_register(&msm_platform_driver);
 }
@@ -965,10 +962,7 @@ static void __exit msm_drm_unregister(void)
 {
 	DBG("fini");
 	platform_driver_unregister(&msm_platform_driver);
-	msm_hdmi_unregister();
 	adreno_unregister();
-	msm_edp_unregister();
-	msm_dsi_unregister();
 }
 
 module_init(msm_drm_register);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 905c17e373e7..abb15334bfa3 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -247,39 +247,19 @@ struct hdmi;
 #if IS_ENABLED(CONFIG_DRM_MSM_HDMI)
 int msm_hdmi_modeset_init(struct hdmi *hdmi, struct drm_device *dev,
 		struct drm_encoder *encoder);
-void __init msm_hdmi_register(void);
-void __exit msm_hdmi_unregister(void);
 #else
 static inline int msm_hdmi_modeset_init(struct hdmi *hdmi, struct drm_device *dev,
 				    struct drm_encoder *encoder)
 {
 	return -EINVAL;
 }
-
-static inline void __init msm_hdmi_register(void)
-{
-}
-
-static inline void __exit msm_hdmi_unregister(void)
-{
-}
 #endif
 
 struct msm_edp;
 #if IS_ENABLED(CONFIG_DRM_MSM_EDP)
-void __init msm_edp_register(void);
-void __exit msm_edp_unregister(void);
 int msm_edp_modeset_init(struct msm_edp *edp, struct drm_device *dev,
 		struct drm_encoder *encoder);
 #else
-static inline void __init msm_edp_register(void)
-{
-}
-
-static inline void __exit msm_edp_unregister(void)
-{
-}
-
 static inline int msm_edp_modeset_init(struct msm_edp *edp,
 				       struct drm_device *dev,
 				       struct drm_encoder *encoder)
@@ -295,17 +275,9 @@ enum msm_dsi_encoder_id {
 	MSM_DSI_ENCODER_NUM = 2
 };
 #if IS_ENABLED(CONFIG_DRM_MSM_DSI)
-void __init msm_dsi_register(void);
-void __exit msm_dsi_unregister(void);
 int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct drm_device *dev,
 		struct drm_encoder *encoders[MSM_DSI_ENCODER_NUM]);
 #else
-static inline void __init msm_dsi_register(void)
-{
-}
-static inline void __exit msm_dsi_unregister(void)
-{
-}
 static inline int msm_dsi_modeset_init(struct msm_dsi *msm_dsi,
 		struct drm_device *dev,
 		struct drm_encoder *encoders[MSM_DSI_ENCODER_NUM])
-- 
2.7.0



From broonie at kernel.org  Mon Feb 22 13:24:38 2016
From: broonie at kernel.org (Mark Brown)
Date: Tue, 23 Feb 2016 06:24:38 +0900
Subject: [PATCH v3 00/12] pwm: add support for atomic update
In-Reply-To: <CAD=FV=UCErW3EjYRtwt49_ztNR7cyY4U0o4R_dxdomer-Ac2Dg@mail.gmail.com>
References: <1442828009-6241-1-git-send-email-boris.brezillon@free-electrons.com>
 <2341981.a79ioYM9Es@diego> <20151110173416.GB21727@ulmo>
 <CAD=FV=WL3jYEgVe-m6QcAyQwfJgdX4J5OtKisKwyoKOrTSpEQA@mail.gmail.com>
 <20160125170855.GA10182@ulmo>
 <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
 <20160203145337.GD9650@ulmo>
 <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
 <20160222175929.GA23899@ulmo>
 <CAD=FV=UCErW3EjYRtwt49_ztNR7cyY4U0o4R_dxdomer-Ac2Dg@mail.gmail.com>
Message-ID: <20160222212438.GG18327@sirena.org.uk>

On Mon, Feb 22, 2016 at 11:15:09AM -0800, Doug Anderson wrote:

> Note that historically I remember that Linus Torvalds has stated that
> there is no stable API within the Linux kernel and that forcing the
> in-kernel API to never change was bad for software development.  I
> tracked down my memory and found
> <http://lwn.net/1999/0211/a/lt-binary.html>.  Linus is rabid about not
> breaking userspace, but in general there's no strong requirement to
> never change the driver API inside the kernel.  That being said,
> changing the driver API causes a lot of churn, so presumably changing
> it in a backward compatible way (like adding to the API instead of
> changing it) will make things happier.

You do need to fix the users though, change is fine but you can't cause
people's systems to break.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/67051580/attachment.sig>

From arnd at arndb.de  Mon Feb 22 13:33:31 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Feb 2016 22:33:31 +0100
Subject: [PATCH] drm/layerscape: reduce excessive stack usage
Message-ID: <1456176818-1207477-1-git-send-email-arnd@arndb.de>

The fsl-dcu driver copies a drm_mode_config object to its
stack but then only accesses a single member (dpms_property)
once. The data structure is large enough to trigger a warning
about the amount of kernel stack being used:

drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c: In function 'fsl_dcu_drm_connector_create':
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:182:1: error: the frame size of 1040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

This changes the fsl_dcu_drm_connector_create() function to
only access the drm_mode_config by reference, which is also
more efficient.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 109eee2f2a18 ("drm/layerscape: Add Freescale DCU DRM driver")
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index 8780deba5e8a..92149152db44 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -131,7 +131,7 @@ int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device *fsl_dev,
 				 struct drm_encoder *encoder)
 {
 	struct drm_connector *connector = &fsl_dev->connector.base;
-	struct drm_mode_config mode_config = fsl_dev->drm->mode_config;
+	struct drm_mode_config *mode_config = &fsl_dev->drm->mode_config;
 	struct device_node *panel_node;
 	int ret;
 
@@ -153,7 +153,7 @@ int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device *fsl_dev,
 		goto err_sysfs;
 
 	drm_object_property_set_value(&connector->base,
-				      mode_config.dpms_property,
+				      mode_config->dpms_property,
 				      DRM_MODE_DPMS_OFF);
 
 	panel_node = of_parse_phandle(fsl_dev->np, "fsl,panel", 0);
-- 
2.7.0



From tony at atomide.com  Mon Feb 22 13:34:28 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 13:34:28 -0800
Subject: [GIT PULL] omap fixes against v4.5-rc5, fixes more onenand corruption
Message-ID: <20160222213427.GU13417@atomide.com>

The following changes since commit cf26f1137333251f3515dea31f95775b99df0fd5:

  ARM: OMAP2+: Fix omap_device for module reload on PM runtime forbid (2016-02-12 08:56:52 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.5/fixes-rc5

for you to fetch changes up to 3f315c5b850fa7aff73f50de8e316b98f611a32b:

  ARM: OMAP2+: Fix onenand initialization to avoid filesystem corruption (2016-02-22 09:24:10 -0800)

----------------------------------------------------------------
Two omap fixes for omaps against v4.5-rc5:

- Yet another fix for n900 onenand to avoid corruption. This time to
  fix the issue of mounting onenand back and forth between the original
  maemo kernel and mainline Linux kernel. And it also seems there will
  be two more fixes coming via the MTD tree as issues were discovered
  also in the onenand driver during testing.

- Revert tps65217 regulator clean up as it breaks MMC for am335x
  variants. The proper way to clean this up is just to rename the
  tps65217.dtsi file into tps65217-am335x.dtsi as a similar setup
  is used on many am335x boards.

----------------------------------------------------------------
Ivaylo Dimitrov (1):
      ARM: OMAP2+: Fix onenand initialization to avoid filesystem corruption

Peter Ujfalusi (1):
      Revert "regulator: tps65217: remove tps65217.dtsi file"

 .../devicetree/bindings/regulator/tps65217.txt     | 10 ----
 arch/arm/boot/dts/am335x-bone-common.dtsi          | 14 ++----
 arch/arm/boot/dts/am335x-chilisom.dtsi             | 14 +-----
 arch/arm/boot/dts/am335x-nano.dts                  | 14 +-----
 arch/arm/boot/dts/am335x-pepper.dts                | 14 +-----
 arch/arm/boot/dts/am335x-sl50.dts                  | 13 +----
 arch/arm/boot/dts/tps65217.dtsi                    | 56 ++++++++++++++++++++++
 arch/arm/mach-omap2/gpmc-onenand.c                 |  6 +--
 8 files changed, 70 insertions(+), 71 deletions(-)
 create mode 100644 arch/arm/boot/dts/tps65217.dtsi


From arnd at arndb.de  Mon Feb 22 13:51:13 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Feb 2016 22:51:13 +0100
Subject: [PATCH] fs: crypto: add CONFIG_BLOCK dependency
Message-ID: <1456177885-1571303-1-git-send-email-arnd@arndb.de>

The newly added generic crypto abstraction for file systems operates
on 'struct bio' objects, which do not exist when CONFIG_BLOCK is
disabled:

fs/crypto/crypto.c: In function 'fscrypt_zeroout_range':
fs/crypto/crypto.c:308:9: error: implicit declaration of function 'bio_alloc' [-Werror=implicit-function-declaration]

This adds a Kconfig dependency that prevents FS_ENCRYPTION from being
enabled without BLOCK.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 846c506fadf7 ("fs crypto: add Makefile and Kconfig")
---
 fs/crypto/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/crypto/Kconfig b/fs/crypto/Kconfig
index fc5a4f94c87d..9bea124e274b 100644
--- a/fs/crypto/Kconfig
+++ b/fs/crypto/Kconfig
@@ -1,5 +1,6 @@
 config FS_ENCRYPTION
 	bool "FS Encryption (Per-file encryption)"
+	depends on BLOCK
 	select CRYPTO_AES
 	select CRYPTO_CBC
 	select CRYPTO_ECB
-- 
2.7.0



From manabian at gmail.com  Mon Feb 22 13:52:17 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Mon, 22 Feb 2016 22:52:17 +0100
Subject: [PATCH 1/4] net: ethernet: dwmac: add Ethernet glue logic for
 stm32 chip
In-Reply-To: <CAJgp7zwOVEq=hnxfUt7eHZWSFUAwuK6MCVHdH591=xReRUsW8Q@mail.gmail.com>
References: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
 <1454511275-9791-2-git-send-email-alexandre.torgue@gmail.com>
 <CAGhQ9VypZ5J0pQmrf1Mk-mNsv=XTXu7fhoLt_r2LHJ_Lsyj0yA@mail.gmail.com>
 <CAJgp7zwOVEq=hnxfUt7eHZWSFUAwuK6MCVHdH591=xReRUsW8Q@mail.gmail.com>
Message-ID: <CAGhQ9VzPTgRqqLi4zjHkP-++v5smZ7s52drev1z-AvgXaLuC7Q@mail.gmail.com>

On 22 February 2016 at 15:50, Alexandre Torgue
<alexandre.torgue at gmail.com> wrote:
> 2016-02-13 14:48 GMT+01:00 Joachim  Eastwood <manabian at gmail.com>:
>> On 3 February 2016 at 15:54, Alexandre TORGUE
>> <alexandre.torgue at gmail.com> wrote:
>>> +       plat_dat->bsp_priv = dwmac;
>>> +       plat_dat->init = stm32_dwmac_init;
>>> +       plat_dat->exit = stm32_dwmac_exit;
>>
>> Instead of using these callbacks could you rather implement the PM
>> callbacks directly in this driver?
>> I don't think it should add much code and it will make it look more
>> like standard driver. This will also give you some more control and
>> flexibility in your code.
>
> I prefer to keep the code as it is. Glue layer is directly linked to
> stmmac driver and I don't want to brake the link between the glue and
> the stmmac driver.

What do you mean by break the link?

There has been numerous of patch sets to make the stmmac "glue"
drivers into more standard platform drivers.
http://marc.info/?l=linux-netdev&m=143159850631093&w=2
http://marc.info/?l=linux-netdev&m=143708560009851&w=2
http://marc.info/?l=linux-netdev&m=143812136600541&w=2

Do you see any advantage by using the init and exit hooks in your
driver instead of using the standard driver PM callbacks and remove
function?
The only "cost" I see is slightly more boilerplate code. But since you
already have init/exit functions you could easily make them into PM
resume/suspend so I doubt there would be much increase in code size.

One other thing;
Do you need to have the PHY mode setup code in the init function which
is called each time on resume?
If you could move it to probe you could drop the interface priv data
member and use plat_dat->interface as stmmac_probe_config_dt() has
already done of_get_phy_mode().


regards,
Joachim Eastwood


From arnd at arndb.de  Mon Feb 22 13:53:20 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Feb 2016 22:53:20 +0100
Subject: [PATCH] btrfs: avoid uninitialized variable warning
Message-ID: <1456178006-1619105-1-git-send-email-arnd@arndb.de>

With CONFIG_SMP and CONFIG_PREEMPT both disabled, gcc decides
to partially inline the get_state_failrec() function but cannot
figure out that means the failrec pointer is always valid
if the function returns success, which causes a harmless
warning:

fs/btrfs/extent_io.c: In function 'clean_io_failure':
fs/btrfs/extent_io.c:2131:4: error: 'failrec' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This marks get_state_failrec() and set_state_failrec() both
as 'noinline', which avoids the warning in all cases for me,
and seems less ugly than adding a fake initialization.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 47dc196ae719 ("btrfs: use proper type for failrec in extent_state")
---
 fs/btrfs/extent_io.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 27577f1b10dc..76a0c8597d98 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -1842,7 +1842,7 @@ out:
  * set the private field for a given byte offset in the tree.  If there isn't
  * an extent_state there already, this does nothing.
  */
-static int set_state_failrec(struct extent_io_tree *tree, u64 start,
+static noinline int set_state_failrec(struct extent_io_tree *tree, u64 start,
 		struct io_failure_record *failrec)
 {
 	struct rb_node *node;
@@ -1870,7 +1870,7 @@ out:
 	return ret;
 }
 
-static int get_state_failrec(struct extent_io_tree *tree, u64 start,
+static noinline int get_state_failrec(struct extent_io_tree *tree, u64 start,
 		struct io_failure_record **failrec)
 {
 	struct rb_node *node;
-- 
2.7.0



From tony at atomide.com  Mon Feb 22 13:56:12 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 13:56:12 -0800
Subject: [GIT PULL] omap device tree changes for v4.6 merge window, part 1
Message-ID: <20160222215612.GV13417@atomide.com>

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.6/dt-pt1

for you to fetch changes up to b9d3ec1d98c658226606e66e55c940491447e617:

  ARM: dts: am57xx-beagle-x15: Add eeprom information (2016-02-22 11:18:40 -0800)

----------------------------------------------------------------
Device tree changes for omaps for v4.6 merge window. Mostly just
adding board specific devices and few new boards:

- N900 improvments for adp1653 and gpio keys

- Add missing bandgap data for omap3

- Add more devices for compulab cm-t335

- Add n950 WLAN support, enable modem, add pinctrl for SSI

- Correct dm814x and dra62x auxclk rate, add support for GPMC and NAND

- Add syscon node for PHY's on dra7

- Add support more devices on logicpd torpedo

- Add USB host support for igep and specify boot console

- Fix audio clock for am335x-sl50 and specify boot console

- Remove deprecated tx-fifo-resize for dwc3 that was only used on
  omap5 es1.0

- Add dra7 thermal data

- Update am43x-epos-evm compatible string to am438

- Add support for logicpd dm3730 som-lv

----------------------------------------------------------------
Adam Ford (8):
      ARM: dts: LogicPD Torpedo: Add MT9P031 Support
      ARM: dts: LogicPD Torpedo: Add AT24 EEPROM Support
      ARM: dts: LogicPD Torpedo: Fix Panel Sleep
      ARM: dts: LogicPD Torpedo: Add SPI EEPROM
      ARM: dts: LogicPD Torpedo: Set HSUSB0 Pin Mux
      ARM: dts: omap3logic: Add PWM-Backlight
      ARM: DTS: Add minimal Support for Logic PD DM3730 SOM-LV
      ARM: dts: Add HSUSB2 EHCI Support to Logic PD DM37xx SOM-LV

Enric Balletbo i Serra (3):
      ARM: dts: igep00x0: Specify the device to be used for boot console output.
      ARM: dts: am335x-sl50: Specify the device to be used for boot console output.
      ARM: dts: am335x-sl50: Fix audio codec setup.

Felipe Balbi (1):
      ARM: dts: remove deprecated property dwc3

Ivaylo Dimitrov (1):
      ARM: dts: omap3-n900: Allow gpio keys to be disabled

Keerthy (4):
      ARM: dts: DRA7: Add DSPEVE thermal data
      ARM: dts: DRA7: Add IVA thermal data
      ARM: dts: DRA7: Add missing IVA and DSPEVE thermal domain data
      ARM: dts: am43x-epos-evm: Add the am438 compatible string

Kishon Vijay Abraham I (4):
      ARM: dts: dra7: Add dt node for the sycon pcie
      ARM: dts: dra7: Use "syscon-phy-power" and "syscon-pcs" in PCIe PHY node
      ARM: dts: dra7: Use "ti,dra7x-usb2-phy2" compatible string for USB2 PHY2
      ARM: dts: am4372/dra7/omap5: Use "syscon-phy-power" instead of "ctrl-module"

Nishanth Menon (1):
      ARM: dts: am57xx-beagle-x15: Add eeprom information

Pali Roh?r (3):
      ARM: dts: n900: Include adp1653 device
      ARM: dts: omap3: Include missing bandgap data for ti-soc-thermal driver
      ARM: dts: n900: Use linux input defines instead hardcoded constants

Pau Pajuel (1):
      ARM: dts: omap3-igep0030-common: Add USB Host support

Sebastian Reichel (4):
      ARM: dts: N950: Add wlan support
      ARM: dts: OMAP3-N950-N9: Enable SSI module
      ARM: dts: OMAP3-N950-N9: Enable modem
      ARM: dts: OMAP3-N950-N9: Add ssi idle pinctrl state

Tony Lindgren (5):
      ARM: dts: The rate for auxclk is 22.59792 by default
      ARM: dts: Add support for GPMC for dm814x and dra62x
      ARM: dts: Add NAND support for j5-eco evm
      ARM: dts: Add NAND support for dm8148-evm
      Merge branch 'n900-keys' into omap-for-v4.6/dt

Uri Mashiach (4):
      ARM: dts: cm-t335: Add support for CAN bus
      ARM: dts: cm-t335: add touchscreen support
      ARM: dts: cm-t335: add audio support
      ARM: dts: add spi wifi support to cm-t335

 .../devicetree/bindings/arm/omap/omap.txt          |   2 +-
 arch/arm/boot/dts/am335x-cm-t335.dts               | 171 +++++++++++++
 arch/arm/boot/dts/am335x-sl50.dts                  |  24 +-
 arch/arm/boot/dts/am4372.dtsi                      |  16 +-
 arch/arm/boot/dts/am43x-epos-evm.dts               |   2 +-
 arch/arm/boot/dts/am57xx-beagle-x15.dts            |   5 +
 arch/arm/boot/dts/dm8148-evm.dts                   |  56 +++++
 arch/arm/boot/dts/dm814x-clocks.dtsi               |   4 +-
 arch/arm/boot/dts/dm814x.dtsi                      |  12 +
 arch/arm/boot/dts/dra62x-j5eco-evm.dts             |  56 +++++
 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi         |  27 +++
 arch/arm/boot/dts/dra7-iva-thermal.dtsi            |  27 +++
 arch/arm/boot/dts/dra7.dtsi                        |  80 ++----
 arch/arm/boot/dts/dra74x.dtsi                      |   1 -
 arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts   | 268 +++++++++++++++++++++
 arch/arm/boot/dts/logicpd-som-lv.dtsi              | 265 ++++++++++++++++++++
 arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts  | 163 ++++++++++---
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi         |  35 +++
 arch/arm/boot/dts/omap3-igep.dtsi                  |   4 +
 arch/arm/boot/dts/omap3-igep0030-common.dtsi       |  41 ++++
 arch/arm/boot/dts/omap3-n9.dts                     |   4 +
 arch/arm/boot/dts/omap3-n900.dts                   |  44 ++--
 arch/arm/boot/dts/omap3-n950-n9.dtsi               |  93 +++++++
 arch/arm/boot/dts/omap3-n950.dts                   |  33 +++
 arch/arm/boot/dts/omap34xx.dtsi                    |   6 +
 arch/arm/boot/dts/omap36xx.dtsi                    |   6 +
 arch/arm/boot/dts/omap5.dtsi                       |  27 +--
 27 files changed, 1324 insertions(+), 148 deletions(-)
 create mode 100644 arch/arm/boot/dts/dra7-dspeve-thermal.dtsi
 create mode 100644 arch/arm/boot/dts/dra7-iva-thermal.dtsi
 create mode 100644 arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts
 create mode 100644 arch/arm/boot/dts/logicpd-som-lv.dtsi


From arnd at arndb.de  Mon Feb 22 13:58:34 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Feb 2016 22:58:34 +0100
Subject: [PATCH] nvdimm: use 'u64' for pfn flags
Message-ID: <1456178322-1728962-1-git-send-email-arnd@arndb.de>

A recent bugfix changed pfn_t to always be 64-bit wide, but did not
change the code in pmem.c, which is now broken on 32-bit architectures
as reported by gcc:

In file included from ../drivers/nvdimm/pmem.c:28:0:
drivers/nvdimm/pmem.c: In function 'pmem_alloc':
include/linux/pfn_t.h:15:17: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
 #define PFN_DEV (1ULL << (BITS_PER_LONG_LONG - 3))

This changes the intermediate pfn_flags in struct pmem_device to
be 64 bit wide as well, so they can store the flags correctly.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: db78c22230d0 ("mm: fix pfn_t vs highmem")
---
 drivers/nvdimm/pmem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 7edf31671dab..8d0b54670184 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -41,7 +41,7 @@ struct pmem_device {
 	phys_addr_t		phys_addr;
 	/* when non-zero this device is hosting a 'pfn' instance */
 	phys_addr_t		data_offset;
-	unsigned long		pfn_flags;
+	u64			pfn_flags;
 	void __pmem		*virt_addr;
 	size_t			size;
 	struct badblocks	bb;
-- 
2.7.0



From sboyd at codeaurora.org  Mon Feb 22 14:05:14 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 22 Feb 2016 14:05:14 -0800
Subject: [PATCHv2] clk: ti: omap3+: dpll: use non-locking version of
 clk_get_rate
In-Reply-To: <20160222165252.GF13417@atomide.com>
References: <1455966777-30576-1-git-send-email-t-kristo@ti.com>
 <20160222165252.GF13417@atomide.com>
Message-ID: <20160222220514.GZ4847@codeaurora.org>

On 02/22, Tony Lindgren wrote:
> * Tero Kristo <t-kristo at ti.com> [160220 03:12]:
> > As the code in this file is being executed within irq context in some
> > cases, we must avoid the clk_get_rate which uses mutex internally.
> > Switch the code to use clk_hw_get_rate instead which is non-locking.
> > 
> > This fixes an issue where PM runtime will hang the system if enabled
> > with a serial console before a suspend-resume cycle.
> 
> Can you please add the "Fixes: " line here?
> 
> And when applying, please tag this one Cc stable.
> 
> Other than that, please feel free to add:
> 
> Tested-by: Tony Lindgren <tony at atomide.com>
> 

This is what I got. "Fixes" should take care of stable.

From: Tero Kristo <t-kristo at ti.com>
Subject: [PATCH] clk: ti: omap3+: dpll: use non-locking version of
 clk_get_rate

As the code in this file is being executed within irq context in some
cases, we must avoid the clk_get_rate which uses mutex internally.
Switch the code to use clk_hw_get_rate instead which is non-locking.

This fixes an issue where PM runtime will hang the system if enabled
with a serial console before a suspend-resume cycle.

Signed-off-by: Tero Kristo <t-kristo at ti.com>
Tested-by: Tony Lindgren <tony at atomide.com>
Fixes: a53ad8ef3dcc ("clk: ti: Convert to clk_hw based provider APIs")
Signed-off-by: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/clk/ti/dpll3xxx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/ti/dpll3xxx.c b/drivers/clk/ti/dpll3xxx.c
index 1c300388782b..cc739291a3ce 100644
--- a/drivers/clk/ti/dpll3xxx.c
+++ b/drivers/clk/ti/dpll3xxx.c
@@ -460,7 +460,8 @@ int omap3_noncore_dpll_enable(struct clk_hw *hw)
 
 	parent = clk_hw_get_parent(hw);
 
-	if (clk_hw_get_rate(hw) == clk_get_rate(dd->clk_bypass)) {
+	if (clk_hw_get_rate(hw) ==
+	    clk_hw_get_rate(__clk_get_hw(dd->clk_bypass))) {
 		WARN_ON(parent != __clk_get_hw(dd->clk_bypass));
 		r = _omap3_noncore_dpll_bypass(clk);
 	} else {
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From tony at atomide.com  Mon Feb 22 14:10:22 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 14:10:22 -0800
Subject: [PATCHv2] clk: ti: omap3+: dpll: use non-locking version of
 clk_get_rate
In-Reply-To: <20160222220514.GZ4847@codeaurora.org>
References: <1455966777-30576-1-git-send-email-t-kristo@ti.com>
 <20160222165252.GF13417@atomide.com>
 <20160222220514.GZ4847@codeaurora.org>
Message-ID: <20160222221021.GW13417@atomide.com>

* Stephen Boyd <sboyd at codeaurora.org> [160222 14:05]:
> On 02/22, Tony Lindgren wrote:
> > * Tero Kristo <t-kristo at ti.com> [160220 03:12]:
> > > As the code in this file is being executed within irq context in some
> > > cases, we must avoid the clk_get_rate which uses mutex internally.
> > > Switch the code to use clk_hw_get_rate instead which is non-locking.
> > > 
> > > This fixes an issue where PM runtime will hang the system if enabled
> > > with a serial console before a suspend-resume cycle.
> > 
> > Can you please add the "Fixes: " line here?
> > 
> > And when applying, please tag this one Cc stable.
> > 
> > Other than that, please feel free to add:
> > 
> > Tested-by: Tony Lindgren <tony at atomide.com>
> > 
> 
> This is what I got. "Fixes" should take care of stable.

OK thanks!

Tony


From dan.j.williams at intel.com  Mon Feb 22 14:19:14 2016
From: dan.j.williams at intel.com (Dan Williams)
Date: Mon, 22 Feb 2016 14:19:14 -0800
Subject: [PATCH] nvdimm: use 'u64' for pfn flags
In-Reply-To: <1456178322-1728962-1-git-send-email-arnd@arndb.de>
References: <1456178322-1728962-1-git-send-email-arnd@arndb.de>
Message-ID: <CAPcyv4j-ByA7u0jnnLHeiEYNZU78-twRzQUoeo2BkmtODCAGHg@mail.gmail.com>

On Mon, Feb 22, 2016 at 1:58 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> A recent bugfix changed pfn_t to always be 64-bit wide, but did not
> change the code in pmem.c, which is now broken on 32-bit architectures
> as reported by gcc:
>
> In file included from ../drivers/nvdimm/pmem.c:28:0:
> drivers/nvdimm/pmem.c: In function 'pmem_alloc':
> include/linux/pfn_t.h:15:17: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
>  #define PFN_DEV (1ULL << (BITS_PER_LONG_LONG - 3))
>
> This changes the intermediate pfn_flags in struct pmem_device to
> be 64 bit wide as well, so they can store the flags correctly.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: db78c22230d0 ("mm: fix pfn_t vs highmem")

Thanks Arnd, I'll roll this up.


From robdclark at gmail.com  Mon Feb 22 14:36:36 2016
From: robdclark at gmail.com (Rob Clark)
Date: Mon, 22 Feb 2016 17:36:36 -0500
Subject: [PATCH 0/8] drm: msm: module rework
In-Reply-To: <1456175331-714117-1-git-send-email-arnd@arndb.de>
References: <1456175331-714117-1-git-send-email-arnd@arndb.de>
Message-ID: <CAF6AEGuYQqsH9TEoc-_cgMRNRvB99SveTqW3gSwJJvsvhaqNmw@mail.gmail.com>

On Mon, Feb 22, 2016 at 4:08 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> I saw some regressions on today's Linux-next kernel after
> the Makefiles got reworked and tried to come up with a quick
> fix. This ended up taking much longer, but the new version should
> be cleaner and I no longer get any build errors in this
> driver.

fyi, for the time being, I've already kicked out the kconfig/makefile
splitup patches..

I'll go ahead and pull in the hdmi symbol rename patch, since that is
a sane thing to do.  I'm less sure about splitting things up into
separate .ko's.  And I think having the .ko name not match the drm
driver name (ie. what is passed in to drmOpen() in userspace) would
cause issues since libdrm could try to modprobe $drivername.ko.  (I
*think* that only matters in the non-udev case?  Which is at least not
a common case, but breaking userspace is breaking userspace...)

BR,
-R

> The first two patches are just preparation to avoid the
> namespace problems with global symbols and the module name.
>
> The next five patches separate out each subdirectory that has
> its own Makefile into a separate loadable module.
>
> The final patch is just a nice addon, it should work in theory
> but this needs to be tested well.


From robert.jarzmik at free.fr  Mon Feb 22 14:38:56 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Mon, 22 Feb 2016 23:38:56 +0100
Subject: [PATCH 9/9] ARM: mmp: mark usb_dma_mask as __maybe_unused
In-Reply-To: <1454076396-3563101-10-git-send-email-arnd@arndb.de> (Arnd
 Bergmann's message of "Fri, 29 Jan 2016 15:06:33 +0100")
References: <1454076396-3563101-1-git-send-email-arnd@arndb.de>
 <1454076396-3563101-10-git-send-email-arnd@arndb.de>
Message-ID: <87bn78wetb.fsf@belgarion.home>

Arnd Bergmann <arnd at arndb.de> writes:

> This variable may be used by some devices that each have their
> on Kconfig symbol, or by none of them, and that causes a build
> warning:
>
> arch/arm/mach-mmp/devices.c:241:12: error: 'usb_dma_mask' defined but not used [-Werror=unused-variable]
>
> Marking it __maybe_unused avoids the warning.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/mach-mmp/devices.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Hi Haojian,

I still didn't get an ack on this one, do you want to carry it through your
tree, or let Arnd carry it or let me carry it ?

Cheers.

--
Robert

[1] The patch
> diff --git a/arch/arm/mach-mmp/devices.c b/arch/arm/mach-mmp/devices.c
> index 3330ac7cfbef..671c7a09ab3d 100644
> --- a/arch/arm/mach-mmp/devices.c
> +++ b/arch/arm/mach-mmp/devices.c
> @@ -238,7 +238,7 @@ void pxa_usb_phy_deinit(void __iomem *phy_reg)
>  #endif
>  
>  #if IS_ENABLED(CONFIG_USB_SUPPORT)
> -static u64 usb_dma_mask = ~(u32)0;
> +static u64 __maybe_unused usb_dma_mask = ~(u32)0;
>  
>  #if IS_ENABLED(CONFIG_USB_MV_UDC)
>  struct resource pxa168_u2o_resources[] = {

-- 
Robert


From arnd at arndb.de  Mon Feb 22 14:44:09 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Mon, 22 Feb 2016 23:44:09 +0100
Subject: [PATCH 0/8] drm: msm: module rework
In-Reply-To: <CAF6AEGuYQqsH9TEoc-_cgMRNRvB99SveTqW3gSwJJvsvhaqNmw@mail.gmail.com>
References: <1456175331-714117-1-git-send-email-arnd@arndb.de>
 <CAF6AEGuYQqsH9TEoc-_cgMRNRvB99SveTqW3gSwJJvsvhaqNmw@mail.gmail.com>
Message-ID: <2809632.WiXCV6JuAB@wuerfel>

On Monday 22 February 2016 17:36:36 Rob Clark wrote:
> On Mon, Feb 22, 2016 at 4:08 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> > I saw some regressions on today's Linux-next kernel after
> > the Makefiles got reworked and tried to come up with a quick
> > fix. This ended up taking much longer, but the new version should
> > be cleaner and I no longer get any build errors in this
> > driver.
> 
> fyi, for the time being, I've already kicked out the kconfig/makefile
> splitup patches..
> 
> I'll go ahead and pull in the hdmi symbol rename patch, since that is
> a sane thing to do.

Ok, thanks

>  I'm less sure about splitting things up into separate .ko's.

I think it's generally a good idea to split it up like that, though
it could be taken a little further. Having one .ko file per
platform_driver seems to be a very sensible split here, the
main advantage being that you enforce a strict layering between
the subdrivers.

>  And I think having the .ko name not match the drm
> driver name (ie. what is passed in to drmOpen() in userspace) would
> cause issues since libdrm could try to modprobe $drivername.ko.  (I
> *think* that only matters in the non-udev case?  Which is at least not
> a common case, but breaking userspace is breaking userspace...)

Ah, I see. Yes, that is unfortunate, but patch 2 then definitely has
to be dropped even if you decide to take the others.

With udev, the autoloading purely depends on the MODULE_DEVICE_TABLE
in the top module, which should work fine, and without patch 2, all
the other drivers get loaded automatically when the main driver
gets probed.

	Arnd


From tony at atomide.com  Mon Feb 22 15:04:01 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 15:04:01 -0800
Subject: [PATCH 0/4] Fix l4_ls interface clock and enable RTC
Message-ID: <1456182245-1843-1-git-send-email-tony@atomide.com>

Hi all,

Here are few ti81xx related improvments for v4.6 merge window.

Regards,

Tony


Tony Lindgren (4):
  ARM: OMAP2+: Fix hwmod clock for l4_ls
  ARM: OMAP2+: Add rtc hwmod configuration for ti81xx
  ARM: dts: Add RTC entry for dm814x and dra62x
  ARM: dts: Add RTC entry for dm816x

 arch/arm/boot/dts/dm814x.dtsi              |  7 +++++
 arch/arm/boot/dts/dm816x.dtsi              |  7 +++++
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 47 ++++++++++++++++++++++++++++--
 3 files changed, 59 insertions(+), 2 deletions(-)

-- 
2.7.0



From tony at atomide.com  Mon Feb 22 15:04:04 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 15:04:04 -0800
Subject: [PATCH 3/4] ARM: dts: Add RTC entry for dm814x and dra62x
In-Reply-To: <1456182245-1843-1-git-send-email-tony@atomide.com>
References: <1456182245-1843-1-git-send-email-tony@atomide.com>
Message-ID: <1456182245-1843-4-git-send-email-tony@atomide.com>

Add RTC entry for dm814x and dra62x.

Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/boot/dts/dm814x.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index 3fe68b1..f752ac1 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -305,6 +305,13 @@
 				reg = <0x60000 0x1000>;
 			};
 
+			rtc: rtc at c0000 {
+				compatible = "ti,am3352-rtc", "ti,da830-rtc";
+				reg = <0xc0000 0x1000>;
+				interrupts = <75 76>;
+				ti,hwmods = "rtc";
+			};
+
 			mmc2: mmc at 1d8000 {
 				compatible = "ti,omap4-hsmmc";
 				ti,hwmods = "mmc2";
-- 
2.7.0



From tony at atomide.com  Mon Feb 22 15:04:05 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 15:04:05 -0800
Subject: [PATCH 4/4] ARM: dts: Add RTC entry for dm816x
In-Reply-To: <1456182245-1843-1-git-send-email-tony@atomide.com>
References: <1456182245-1843-1-git-send-email-tony@atomide.com>
Message-ID: <1456182245-1843-5-git-send-email-tony@atomide.com>

Add RTC entry for dm816x.

Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/boot/dts/dm816x.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index c3b8811..e850686 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -214,6 +214,13 @@
 			reg = <0x48200000 0x1000>;
 		};
 
+		rtc: rtc at 480c0000 {
+			compatible = "ti,am3352-rtc", "ti,da830-rtc";
+			reg = <0x480c0000 0x1000>;
+			interrupts = <75 76>;
+			ti,hwmods = "rtc";
+		};
+
 		mailbox: mailbox at 480c8000 {
 			compatible = "ti,omap4-mailbox";
 			reg = <0x480c8000 0x2000>;
-- 
2.7.0



From tony at atomide.com  Mon Feb 22 15:04:03 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 15:04:03 -0800
Subject: [PATCH 2/4] ARM: OMAP2+: Add rtc hwmod configuration for ti81xx
In-Reply-To: <1456182245-1843-1-git-send-email-tony@atomide.com>
References: <1456182245-1843-1-git-send-email-tony@atomide.com>
Message-ID: <1456182245-1843-3-git-send-email-tony@atomide.com>

This allows RTC to work properly with the related DTS
changes.

Cc: Paul Walmsley <paul at pwsan.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 38 ++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index f8cc400..39736ad 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -228,6 +228,42 @@ static struct omap_hwmod_ocp_if dm816x_mpu__alwon_l3_med = {
 	.user	= OCP_USER_MPU,
 };
 
+/* RTC */
+static struct omap_hwmod_class_sysconfig ti81xx_rtc_sysc = {
+	.rev_offs	= 0x74,
+	.sysc_offs	= 0x78,
+	.sysc_flags	= SYSC_HAS_SIDLEMODE,
+	.idlemodes	= SIDLE_FORCE | SIDLE_NO |
+			  SIDLE_SMART | SIDLE_SMART_WKUP,
+	.sysc_fields	= &omap_hwmod_sysc_type3,
+};
+
+static struct omap_hwmod_class ti81xx_rtc_hwmod_class = {
+	.name		= "rtc",
+	.sysc		= &ti81xx_rtc_sysc,
+};
+
+struct omap_hwmod ti81xx_rtc_hwmod = {
+	.name		= "rtc",
+	.class		= &ti81xx_rtc_hwmod_class,
+	.clkdm_name	= "alwon_l3s_clkdm",
+	.flags		= HWMOD_NO_IDLEST,
+	.main_clk	= "sysclk18_ck",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs = DM81XX_CM_ALWON_RTC_CLKCTRL,
+			.modulemode = MODULEMODE_SWCTRL,
+		},
+	},
+};
+
+static struct omap_hwmod_ocp_if ti81xx_l4_ls__rtc = {
+	.master		= &dm81xx_l4_ls_hwmod,
+	.slave		= &ti81xx_rtc_hwmod,
+	.clk		= "sysclk6_ck",
+	.user		= OCP_USER_MPU,
+};
+
 /* UART common */
 static struct omap_hwmod_class_sysconfig uart_sysc = {
 	.rev_offs	= 0x50,
@@ -1381,6 +1417,7 @@ static struct omap_hwmod_ocp_if *dm814x_hwmod_ocp_ifs[] __initdata = {
 	&dm81xx_l4_ls__mcspi1,
 	&dm814x_l4_ls__mmc1,
 	&dm814x_l4_ls__mmc2,
+	&ti81xx_l4_ls__rtc,
 	&dm81xx_alwon_l3_fast__tpcc,
 	&dm81xx_alwon_l3_fast__tptc0,
 	&dm81xx_alwon_l3_fast__tptc1,
@@ -1420,6 +1457,7 @@ static struct omap_hwmod_ocp_if *dm816x_hwmod_ocp_ifs[] __initdata = {
 	&dm81xx_l4_ls__gpio1,
 	&dm81xx_l4_ls__gpio2,
 	&dm81xx_l4_ls__elm,
+	&ti81xx_l4_ls__rtc,
 	&dm816x_l4_ls__mmc1,
 	&dm816x_l4_ls__timer1,
 	&dm816x_l4_ls__timer2,
-- 
2.7.0



From tony at atomide.com  Mon Feb 22 15:04:02 2016
From: tony at atomide.com (Tony Lindgren)
Date: Mon, 22 Feb 2016 15:04:02 -0800
Subject: [PATCH 1/4] ARM: OMAP2+: Fix hwmod clock for l4_ls
In-Reply-To: <1456182245-1843-1-git-send-email-tony@atomide.com>
References: <1456182245-1843-1-git-send-email-tony@atomide.com>
Message-ID: <1456182245-1843-2-git-send-email-tony@atomide.com>

Looks like we have few cases with wrong clock, and some
entries with missing clock. It should always be sysclk6
for the l4_ls instance.

Cc: Paul Walmsley <paul at pwsan.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>
---
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index e493ae3..f8cc400 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -429,6 +429,7 @@ static struct omap_hwmod dm81xx_elm_hwmod = {
 static struct omap_hwmod_ocp_if dm81xx_l4_ls__elm = {
 	.master		= &dm81xx_l4_ls_hwmod,
 	.slave		= &dm81xx_elm_hwmod,
+	.clk		= "sysclk6_ck",
 	.user		= OCP_USER_MPU,
 };
 
@@ -478,6 +479,7 @@ static struct omap_hwmod dm81xx_gpio1_hwmod = {
 static struct omap_hwmod_ocp_if dm81xx_l4_ls__gpio1 = {
 	.master		= &dm81xx_l4_ls_hwmod,
 	.slave		= &dm81xx_gpio1_hwmod,
+	.clk		= "sysclk6_ck",
 	.user		= OCP_USER_MPU,
 };
 
@@ -504,6 +506,7 @@ static struct omap_hwmod dm81xx_gpio2_hwmod = {
 static struct omap_hwmod_ocp_if dm81xx_l4_ls__gpio2 = {
 	.master		= &dm81xx_l4_ls_hwmod,
 	.slave		= &dm81xx_gpio2_hwmod,
+	.clk		= "sysclk6_ck",
 	.user		= OCP_USER_MPU,
 };
 
@@ -628,7 +631,7 @@ static struct omap_hwmod dm814x_timer1_hwmod = {
 static struct omap_hwmod_ocp_if dm814x_l4_ls__timer1 = {
 	.master		= &dm81xx_l4_ls_hwmod,
 	.slave		= &dm814x_timer1_hwmod,
-	.clk		= "timer1_fck",
+	.clk		= "sysclk6_ck",
 	.user		= OCP_USER_MPU,
 };
 
@@ -665,7 +668,7 @@ static struct omap_hwmod dm814x_timer2_hwmod = {
 static struct omap_hwmod_ocp_if dm814x_l4_ls__timer2 = {
 	.master		= &dm81xx_l4_ls_hwmod,
 	.slave		= &dm814x_timer2_hwmod,
-	.clk		= "timer2_fck",
+	.clk		= "sysclk6_ck",
 	.user		= OCP_USER_MPU,
 };
 
@@ -1123,6 +1126,7 @@ static struct omap_hwmod dm81xx_mailbox_hwmod = {
 static struct omap_hwmod_ocp_if dm81xx_l4_ls__mailbox = {
 	.master		= &dm81xx_l4_ls_hwmod,
 	.slave		= &dm81xx_mailbox_hwmod,
+	.clk		= "sysclk6_ck",
 	.user		= OCP_USER_MPU,
 };
 
@@ -1157,6 +1161,7 @@ static struct omap_hwmod dm81xx_spinbox_hwmod = {
 static struct omap_hwmod_ocp_if dm81xx_l4_ls__spinbox = {
 	.master		= &dm81xx_l4_ls_hwmod,
 	.slave		= &dm81xx_spinbox_hwmod,
+	.clk		= "sysclk6_ck",
 	.user		= OCP_USER_MPU,
 };
 
-- 
2.7.0



From k.kozlowski at samsung.com  Mon Feb 22 16:01:11 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 23 Feb 2016 09:01:11 +0900
Subject: [PATCH 1/3] ARM: EXYNOS: correct header comment in Kconfig file
In-Reply-To: <1456135396-17767-2-git-send-email-pankaj.dubey@samsung.com>
References: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
 <1456135396-17767-2-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <56CBA147.9000404@samsung.com>

On 22.02.2016 19:03, Pankaj Dubey wrote:
> This patch corrects header comment of Kconfig file by changing EXYNOS4 to
> EXYNOS.
> 
> Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
> ---
>  arch/arm/mach-exynos/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks, applied.

Krzysztof



From k.kozlowski at samsung.com  Mon Feb 22 16:03:08 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 23 Feb 2016 09:03:08 +0900
Subject: [PATCH 2/3] ARM: EXYNOS: remove unused register offset definition
In-Reply-To: <1456135396-17767-3-git-send-email-pankaj.dubey@samsung.com>
References: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
 <1456135396-17767-3-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <56CBA1BC.4050003@samsung.com>

On 22.02.2016 19:03, Pankaj Dubey wrote:
> This patch cleans up map.h by removing unused register offset
> and changing EXYNOS4 to EXYNOS in header comment section.
> 
> Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
> ---
>  arch/arm/mach-exynos/include/mach/map.h | 9 +--------
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
> index 351e839..c48ba4f 100644
> --- a/arch/arm/mach-exynos/include/mach/map.h
> +++ b/arch/arm/mach-exynos/include/mach/map.h
> @@ -2,7 +2,7 @@
>   * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
>   *		http://www.samsung.com/
>   *
> - * EXYNOS4 - Memory map definitions
> + * EXYNOS - Memory map definitions
>   *
>   * 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
> @@ -14,12 +14,6 @@
>  
>  #include <plat/map-base.h>
>  
> -/*
> - * EXYNOS4 UART offset is 0x10000 but the older S5P SoCs are 0x400.
> - * So need to define it, and here is to avoid redefinition warning.
> - */
> -#define S3C_UART_OFFSET			(0x10000)
> -
>  #include <plat/map-s5p.h>

This does not look good. The S3C_UART_OFFSET is used in plat/map-s5p.h.

Best regards,
Krzysztof


From k.kozlowski at samsung.com  Mon Feb 22 16:09:17 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 23 Feb 2016 09:09:17 +0900
Subject: [PATCH 3/3] ARM: EXYNOS: cleanup header files inclusion
In-Reply-To: <1456135396-17767-4-git-send-email-pankaj.dubey@samsung.com>
References: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
 <1456135396-17767-4-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <56CBA32D.4020905@samsung.com>

On 22.02.2016 19:03, Pankaj Dubey wrote:
> This includes trivial cleanup in exynos files such as
>     - remove unused header files inclusion from exynos.c, s5p-dev-mfc.c,
>       firmware.c, pm.c.
>     - move inclusion of of.h from common.h to pm.c where it is really
>       required
> 
> Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
> ---
>  arch/arm/mach-exynos/common.h      | 1 -
>  arch/arm/mach-exynos/exynos.c      | 5 -----
>  arch/arm/mach-exynos/firmware.c    | 2 --
>  arch/arm/mach-exynos/platsmp.c     | 1 -
>  arch/arm/mach-exynos/pm.c          | 4 +---
>  arch/arm/mach-exynos/s5p-dev-mfc.c | 1 -
>  6 files changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
> index e349a03..5365bf1 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -12,7 +12,6 @@
>  #ifndef __ARCH_ARM_MACH_EXYNOS_COMMON_H
>  #define __ARCH_ARM_MACH_EXYNOS_COMMON_H
>  
> -#include <linux/of.h>
>  #include <linux/platform_data/cpuidle-exynos.h>
>  
>  #define EXYNOS3250_SOC_ID	0xE3472000
> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> index 99947ad..54262a1 100644
> --- a/arch/arm/mach-exynos/exynos.c
> +++ b/arch/arm/mach-exynos/exynos.c
> @@ -11,14 +11,10 @@
>  
>  #include <linux/init.h>
>  #include <linux/io.h>
> -#include <linux/kernel.h>
> -#include <linux/serial_s3c.h>
>  #include <linux/of.h>
>  #include <linux/of_address.h>
>  #include <linux/of_fdt.h>
>  #include <linux/of_platform.h>
> -#include <linux/platform_device.h>

platform_device is actually used in that file. It looks unused because
it is pulled by of_platform, but it makes sense to include it here.

Rest looks good.

BR,
Krzysztof



From k.kozlowski at samsung.com  Mon Feb 22 16:14:22 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 23 Feb 2016 09:14:22 +0900
Subject: [PATCH v5 2/3] clk: samsung: Don't build ARMv8 clock drivers on
 ARMv7
In-Reply-To: <20160222182656.2278.68402@quark.deferred.io>
References: <1455603632-11158-1-git-send-email-k.kozlowski@samsung.com>
 <1455603632-11158-3-git-send-email-k.kozlowski@samsung.com>
 <56C44578.5010009@samsung.com> <20160222182656.2278.68402@quark.deferred.io>
Message-ID: <56CBA45E.9070105@samsung.com>

On 23.02.2016 03:26, Michael Turquette wrote:
> Quoting Sylwester Nawrocki (2016-02-17 02:03:36)
>> On 16/02/16 07:20, Krzysztof Kozlowski wrote:
>>> Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS
>>> so it is built also on ARMv7. This does not bring any kind of benefit.
>>> There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like
>>> multi_v7 for ARMv7).
>>>
>>> Instead build clock drivers only for respective SoC's architecture.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
>>
>> Acked-by: Sylwester Nawrocki <s.nawrocki at samsung.com>
>>
> 
> Thanks for the Ack.
> 
> I've rebased patches #1 and #2 against James's b9e65ebc654d and pushed
> the clk-samsung branch to the clk tree. I have deleted the
> clk-samsung-kconfig branch that was blowing up the kbuild robot.
> clk-samsung will not be rebased and can be used as a dependency for
> arm-soc. It has been merged into clk-next.

Thanks, pulled!

Best regards,
Krzysztof



From sboyd at codeaurora.org  Mon Feb 22 16:15:08 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Mon, 22 Feb 2016 16:15:08 -0800
Subject: [PATCHv2] clk: ti: dpll: convert DPLL support code to use clk_hw
 instead of clk ptrs
In-Reply-To: <1455967466-3812-1-git-send-email-t-kristo@ti.com>
References: <1455967466-3812-1-git-send-email-t-kristo@ti.com>
Message-ID: <20160223001507.GC4847@codeaurora.org>

On 02/20, Tero Kristo wrote:
> Convert DPLL support code to use clk_hw pointers for reference and bypass
> clocks. This allows us to use clk_hw_* APIs for accessing any required
> parameters for these clocks, avoiding some locking problems at least with
> DPLL enable code; this used clk_get_rate which uses mutex but isn't
> good under clk_enable / clk_disable.
> 
> Signed-off-by: Tero Kristo <t-kristo at ti.com>
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From k.kozlowski at samsung.com  Mon Feb 22 16:18:25 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 23 Feb 2016 09:18:25 +0900
Subject: [PATCH v2] ARM: dts: Move syscon reboot/poweroff to common dtsi
 for Exynos
In-Reply-To: <56C3D99C.3090403@osg.samsung.com>
References: <1455636348-14277-1-git-send-email-javier@osg.samsung.com>
 <56C3D745.7050904@samsung.com> <56C3D99C.3090403@osg.samsung.com>
Message-ID: <56CBA551.4030205@samsung.com>

On 17.02.2016 11:23, Javier Martinez Canillas wrote:
> Hello Krzysztof,
> 
> On 02/16/2016 11:13 PM, Krzysztof Kozlowski wrote:
> 
> [snip]
> 
>>> diff --git a/arch/arm/boot/dts/exynos-syscon-restart.dtsi
>>> b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
>>> new file mode 100644
>>> index 000000000000..09a2040054ed
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/exynos-syscon-restart.dtsi
>>> @@ -0,0 +1,27 @@
>>> +/*
>>> + * Samsung's Exynos SoC syscon reboot/poweroff nodes common definition.
>>> + *
>>> + * 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.
>>> + */
>>> +
>>> +/ {
>>> +    soc {
>>> +        compatible = "simple-bus";
>>
>> The exynos4 does not have soc node. I wonder whether we should provide
>> here also address and size:
>>                  #address-cells = <1>;
>>                  #size-cells = <1>;
>>         ranges;
>>
>> Without this it works fine but that does not look correct enough.
>>
>> A minor effect of this patch on Exynos4 is that syscon-poweroff/reboot
>> are now the only children of "soc" simple-bus (rest of platform devices
>> is not)... but this is not a problem.
>>
>> Works fine so only the question about cells/ranges remains. Any comments?
>>
> 
> I in fact had the #address-cells and #size-cells at the beginning but then
> realized that both the syscon-poweroff and syscon-reboot nodes didn't have
> a reg property so it felt strange to me to have those.
> 
> Also, I thought that maybe a SoC dtsi may need a different #address-cells
> and #size-cells for the other child nodes so having those in this dtsi
> could override the values in the SoC dtsi depending where is included.
> 
> So I thought it could do more harm than good but I've no strong opinion
> and can add those if you prefer.

No comments from other people so I guess there are no objections.
Applied for late v4.6.

Best regards,
Krzysztof



From lv.zheng at intel.com  Mon Feb 22 16:19:43 2016
From: lv.zheng at intel.com (Zheng, Lv)
Date: Tue, 23 Feb 2016 00:19:43 +0000
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <56CB21FA.1090302@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
 <56C470C5.2080203@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>
 <56C63FB5.2030907@hurleysoftware.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4D5A0@SHSMSX101.ccr.corp.intel.com>
 <56C6F660.9020407@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D949@SHSMSX101.ccr.corp.intel.com>
 <56CB21FA.1090302@linaro.org>
Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB4DC81@SHSMSX101.ccr.corp.intel.com>

Hi,

> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
> early_acpi_os_unmap_memory()
> 
> Hi,
> 
> On 02/22/2016 05:24 AM, Zheng, Lv wrote:
> > Hi,
> >
> >> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
> >> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
> >> early_acpi_os_unmap_memory()
> >>
> >> Hi Lv,
> >>
> >> On 02/19/2016 05:58 AM, Zheng, Lv wrote:
> >>> Hi,
> >>>
> >>>> From: Peter Hurley [mailto:peter at hurleysoftware.com]
> >>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
> >>>> early_acpi_os_unmap_memory()
> >>>>
> >>>> On 02/17/2016 07:36 PM, Zheng, Lv wrote:
> >>>>> Hi,
> >>>>>
> >>>>>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
> >>>>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
> >>>>>> early_acpi_os_unmap_memory()
> >>>>>>
> >>>>>> Hi Lv,
> >>>>>>
> >>>>>> Thank you for review.
> >>>>>>
> >>>>>> On 02/17/2016 05:51 AM, Zheng, Lv wrote:
> >>>>>>
> >>>>>> [..]
> >>>>>>
> >>>>>>>>> early_acpi_os_unmap_memory() is marked as __init because it calls
> >>>>>>>>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap
> is
> >> not
> >>>>>> set.
> >>>>>>>>>
> >>>>>>>>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
> >>>>>>>>> so it is safe to call early_acpi_os_unmap_memory() from anywhere
> >>>>>>>>>
> >>>>>>>>> We need this function to be non-__init because we need access to
> >>>>>>>>> some tables at unpredictable time--it may be before or after
> >>>>>>>>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port
> >>>> Console
> >>>>>>>>> Redirection) table is needed each time a new console is registered.
> >>>>>>>>> It can be quite early (console_initcall) or when a module is inserted.
> >>>>>>>>> When this table accessed before acpi_gbl_permanent_mmap is set,
> >>>>>>>>> the pointer should be unmapped.  This is exactly what this function
> >>>>>>>>> does.
> >>>>>>>> [Lv Zheng]
> >>>>>>>> Why don't you use another API instead of
> >>>> early_acpi_os_unmap_memory()
> >>>>>> in
> >>>>>>>> case you want to unmap things in any cases.
> >>>>>>>> acpi_os_unmap_memory() should be the one to match this purpose.
> >>>>>>>> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
> >>>>>>
> >>>>>> As far as I understand, there exist two steps in ACPI initialization:
> >>>>>>
> >>>>>> 1. Before acpi_gbl_permanent_mmap is set, tables received with
> >>>>>> acpi_get_table_with_size()
> >>>>>>    are mapped by early_memremap().  If a subsystem gets such a pointer
> it
> >>>>>> should be unmapped.
> >>>>>>
> >>>>>> 2  After acpi_gbl_permanent_mmap is set this pointer should not be
> >>>> unmapped
> >>>>>> at all.
> >>>>>>
> >>>>> [Lv Zheng]
> >>>>> This statement is wrong, this should be:
> >>>>> As long as there is a __reference__ to the mapped table, the pointer
> should
> >>>> not be unmapped.
> >>>>> In fact, we have a series to introduce acpi_put_table() to achieve this.
> >>>>> So your argument is wrong from very first point.
> >>>>>
> >>>>>> That exactly what early_acpi_os_unmap_memory() does--it checks
> >>>>>> acpi_gbl_permanent_mmap.
> >>>>>> If I had used acpi_os_unmap_memory() after
> acpi_gbl_permanent_mmap
> >>>> had
> >>>>>> been set,
> >>>>>> it would have tried to free that pointer with an oops (actually, I
> checked
> >> that
> >>>>>> and got that oops).
> >>>>>>
> >>>>>> So using acpi_os_unmap_memory() is not an option here, but
> >>>>>> early_acpi_os_unmap_memory()
> >>>>>> match perfectly.
> >>>>> [Lv Zheng]
> >>>>> I don't think so.
> >>>>> For definition block tables, we know for sure there will always be
> >> references,
> >>>> until "Unload" opcode is invoked by the AML interpreter.
> >>>>> But for the data tables, OSPMs should use them in this way:
> >>>>> 1. map the table
> >>>>> 2. parse the table and convert it to OS specific structures
> >>>>> 3. unmap the table
> >>>>> This helps to shrink virtual memory address space usages.
> >>>>>
> >>>>> So from this point of view, all data tables should be unmapped right
> after
> >>>> being parsed.
> >>>>> Why do you need the map to be persistent in the kernel address space?
> >>>>> You can always map a small table, but what if the table size is very big?
> >>>>>
> >>>>>>
> >>>>>>>> And in fact early_acpi_os_unmap_memory() should be removed.
> >>>>>>
> >>>>>> I don't think so -- I have explained why.  It does different thing.
> >>>>>> Probably it (and/or other functions in that api) should be renamed.
> >>>>>>
> >>>>> [Lv Zheng]
> >>>>> Just let me ask one more question.
> >>>>> eary_acpi_os_unmap_memory() is not used inside of ACPICA.
> >>>>> How ACPICA can work with just acpi_os_unmap_memory()?
> >>>>> You can check drivers/acpi/tbxxx.c.
> >>>>> Especially: acpi_tb_release_temp_table() and the code invoking it.
> >>>>>
> >>>>>>> [Lv Zheng]
> >>>>>>> One more thing is:
> >>>>>>> If you can't switch your driver to use acpi_os_unmap_memory()
> instead
> >> of
> >>>>>> early_acpi_os_unmap_memory(),
> >>>>>>> then it implies that your driver does have a defect.
> >>>>>>
> >>>>>> I still don't understand what defect, sorry.
> >>>>> [Lv Zheng]
> >>>>> If you can't ensure this sequence for using the data tables:
> >>>>> 1. map the table
> >>>>> 2. parse the table and convert it to OS specific structure
> >>>>> 3. unmap the table
> >>>>> It implies there is a bug in the driver or a bug in the ACPI subsystem core.
> >>>>
> >>>> Exactly.
> >>> [Lv Zheng]
> >>> So it looks to me:
> >>> Changing __init to __ref here is entirely not acceptable.
> >>> This API should stay being invoked during early stage.
> >>> Otherwise, it may leave us untrackable code that maps tables during early
> >> stage and leaks maps to the late stage.
> >>> If Linux contains such kind of code, I'm afraid, it will become impossible to
> >> introduce acpi_put_table() to clean up the mappings.
> >>> Because when acpi_put_table() is called during the late stage to free a map
> >> acquired during the early stage, it then obviously will end up with panic.
> >>
> >> Can you please sugggest a common method to access ACPI tables that
> >> works both before *and* after acpi_gbl_permanent_mmap is set and __init
> >> code
> >> is removed?
> > [Lv Zheng]
> > Do not change __init for now.
> >
> > Currently you should:
> > 1. before acpi_gbl_permanent_mmap is set:
> > acpi_get_table_with_size()
> > parse the table
> > early_acpi_os_unmap_memory()
> > Do your driver early stuff here
> >
> > 2. after acpi_gbl_permanent_mmap is set:
> > acpi_get_table()
> > Parse the table
> > Do your driver late stuff here
> > <- note there is no API now being an inverse of acpi_get_table().
> 
> That's fine.  These are two different methods to access the table.
> I need one that works in both cases.  Of course, they could be combined,
> but I am not sure if I can access the acpi_gbl_permanent_mmap variable--it
> seems to be an implementation detail of ACPI code.
[Lv Zheng] 
You should not access acpi_gbl_permanent_mmap.
The variable will be deleted after combining the 2 methods.
What we need to ensure is that during the period where the 2 different methods are not combined,
early_acpi_os_unmap_memory() should always be invoked.
And __init can help us to prevent developers submitting wrong code.

> 
> Instead I am going to use the 1st method once and cache the result like this:
> 
> 
> static int __init parse(void)
> {
> 	static bool parsed;
> 
> 	if (!parsed) {
> 		acpi_get_table_with_size()
> 		/* parse the table and cache the result */
> 		early_acpi_os_unmap_memory()
> 		parse = true;
> 	}
> }
> 
> arch_initcal(parse());
> 
> int __ref the_handler_where_I_need_the_parse_results(void)
> {
> 	parse();
> 
> 	/* use the data */
> }
> 
> I hope you are OK with it.
[Lv Zheng] 
I'm OK with the code flow in parse().
As long as there is no compiler complaining detected against the __init declarator of early_acpi_os_unmap_memory(), I'm OK with the rest.

> 
> > Besides, I'm about to insert error messages between 1 and 2.
> > If an early map is not release, error message will be prompted to the
> developers.
> 
> AFAICS, there is such an error message and I saw it.
> Refer to check_early_ioremap_leak() at mm/early_ioremap.c
[Lv Zheng] 
We also need ACPICA upstream to be aware of this, otherwise wrong changes could be merged from ACPICA upstream.

Thanks
-Lv

> 
> > And if you don't follow the above rules, it mean you are trying to lay a mine,
> waiting for me to step on it.
> > That's why this change is entirely not acceptable.
> 
> Ok, I see.
> 
> > I'm about to send out the cleanup series in 1 week, and will Cc you.
> > You can rebase your code on top of the cleanup series.
> 
> Thank you
> Aleksey Makarov
> 
> >
> > Thanks and best regards
> > -Lv
> >
> >>
> >>> Thanks and best regards
> >>> -Lv
> >>>
> >>>> The central problem here is the way Aleksey is trying to hookup a console.
> >>>>
> >>>> What should be happening in this series is:
> >>>> 1. early map SPCR
> >>>> 2. parse the SPCR table
> >>>> 3. call add_preferred_console() to add the SPCR console to the console
> >> table
> >>>> 4. unmap SPCR
> >>>>
> >>>> This trivial and unobtrusive method would already have a 8250 console
> >>>> running via SPCR. I've already pointed this out in previous reviews.
> >>>>
> >>>> Further, the above method *will be required anyway* for the DBG2 table
> to
> >>>> start an earlycon, which I've already pointed out in previous reviews.
> >>>>
> >>>> Then to enable amba-pl011 console via ACPI, add a console match()
> method
> >>>> similar to the 8250 console match() method, univ8250_console_match().
> >>>>
> >>>> FWIW, PCI earlycon + console support was already submitted once before
> >> but
> >>>> never picked up by GregKH. I think I'll just grab that and re-submit so
> >>>> you would know what to emit for console options in the
> >>>> add_preferred_console().
> >>>>
> >>>>
> >>>> Regards,
> >>>> Peter Hurley
> >>>>
> >>>>
> >>>>>>> There is an early bootup requirement in Linux.
> >>>>>>> Maps acquired during the early stage should be freed by the driver
> during
> >>>> the
> >>>>>> early stage.
> >>>>>>> And the driver should re-acquire the memory map after booting.
> >>>>>>
> >>>>>> Exactly.  That's why I use early_acpi_os_unmap_memory().  The point is
> >> that
> >>>>>> that code can be
> >>>>>> called *before* acpi_gbl_permanent_mmap is set (at early initialization
> >> of
> >>>> for
> >>>>>> example 8250 console)
> >>>>>> or *after* acpi_gbl_permanent_mmap is set (at insertion of a module
> >> that
> >>>>>> registers a console),
> >>>>>> We just can not tell if the received table pointer should or sould not be
> >> freed
> >>>>>> with early_memunmap()
> >>>>>> (actually __acpi_unmap_table() or whatever) without checking
> >>>>>> acpi_gbl_permanent_mmap,
> >>>>>> but that's all too low level.
> >>>>> [Lv Zheng]
> >>>>> The driver should make sure that:
> >>>>> Map/unmap is paired during early stage.
> >>>>> For late stage, it should be another pair of map/unmap.
> >>>>>
> >>>>>>
> >>>>>> Another option, as you describe, is to get this pointer early, don't free it
> >>>>> [Lv Zheng]
> >>>>> I mean you should free it early.
> >>>>>
> >>>>>> untill acpi_gbl_permanent_mmap is set, then free it (with
> >>>>>> early_acpi_os_unmap_memory(), that's
> >>>>>> ok because acpi_gbl_permanent_mmap is set in an init code), then get
> >> the
> >>>>>> persistent
> >>>>>> pointer to the table.  The problem with it is that we can not just watch
> >>>>>> acpi_gbl_permanent_mmap
> >>>>>> to catch this exact moment.  And also accessing
> >> acpi_gbl_permanent_mmap
> >>>> is
> >>>>>> not good as it probably is
> >>>>>> an implementation detail (i. e. too lowlevel) of the ACPI code.
> >>>>>> Or I probably miss what you are suggesting.
> >>>>>>
> >>>>> [Lv Zheng]
> >>>>> I mean, you should:
> >>>>> During early stage:
> >>>>> acpi_os_map_memory()
> >>>>> Parse the table.
> >>>>> acpi_os_unmap_memory().
> >>>>>
> >>>>>>> This is because, during early bootup stage, there are only limited slots
> >>>>>> available for drivers to map memory.
> >>>>>>> So by changing __init to __ref here, you probably will hide many such
> >>>> defects.
> >>>>>>
> >>>>>> What defects?  This funcions checks acpi_gbl_permanent_mmap.
> >>>>>> BTW, exactly the same thing is done in the beginning of
> >>>>>> acpi_os_unmap_memory() and than's ok,
> >>>>>> that function is __ref.
> >>>>>>
> >>>>>>> And solving issues in this way doesn't seem to be an improvement.
> >>>>>>
> >>>>>> Could you please tell me where I am wrong?  I still don't understand
> your
> >>>> point.
> >>>>> [Lv Zheng]
> >>>>> But anyway, the defect should be in ACPI subsystem core.
> >>>>> The cause should be the API itself - acpi_get_table().
> >>>>>
> >>>>> So I agree you can use early_acpi_os_unmap_memory() during the
> period
> >> the
> >>>> root causes are not cleaned up.
> >>>>> But the bottom line is: the driver need to ensure that
> >>>> early_acpi_os_unmap_memory() is always invoked.
> >>>>> As long as you can ensure this, I don't have objections for deploying
> >>>> early_acpi_os_unmap_memory()  for now.
> >>>>>
> >>>>> Thanks and best regards
> >>>>> -Lv
> >>>>>
> >>>>>>
> >>>>>> Thank you
> >>>>>> Aleksey Makarov
> >>>>>>
> >>>>>>>
> >>>>>>> Thanks and best regards
> >>>>>>> -Lv
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks and best regards
> >>>>>>>> -Lv
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> >>>>>>>>> ---
> >>>>>>>>>  drivers/acpi/osl.c | 6 +++++-
> >>>>>>>>>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>>>>>>>>
> >>>>>>>>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> >>>>>>>>> index 67da6fb..8a552cd 100644
> >>>>>>>>> --- a/drivers/acpi/osl.c
> >>>>>>>>> +++ b/drivers/acpi/osl.c
> >>>>>>>>> @@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void
> >> *virt,
> >>>>>>>>> acpi_size size)
> >>>>>>>>>  }
> >>>>>>>>>  EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
> >>>>>>>>>
> >>>>>>>>> -void __init early_acpi_os_unmap_memory(void __iomem *virt,
> >>>> acpi_size
> >>>>>>>> size)
> >>>>>>>>> +/*
> >>>>>>>>> + * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
> >>>>>>>>> + * so it is safe to call early_acpi_os_unmap_memory() from
> >> anywhere
> >>>>>>>>> + */
> >>>>>>>>> +void __ref early_acpi_os_unmap_memory(void __iomem *virt,
> >>>> acpi_size
> >>>>>>>> size)
> >>>>>>>>>  {
> >>>>>>>>>  	if (!acpi_gbl_permanent_mmap)
> >>>>>>>>>  		__acpi_unmap_table(virt, size);
> >>>>>>>>> --
> >>>>>>>>> 2.7.1
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> in
> >>>>>>>>> the body of a message to majordomo at vger.kernel.org
> >>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-
> >> info.html
> >>>>>>>> --
> >>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> >>>>>>>> the body of a message to majordomo at vger.kernel.org
> >>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-
> info.html
> >>>

From khilman at baylibre.com  Mon Feb 22 16:32:54 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Mon, 22 Feb 2016 16:32:54 -0800
Subject: [PATCH] ARM64: dts: Mediatek: mt8173-evb: fix access MMC fail
 issue
In-Reply-To: <1455861643-24307-1-git-send-email-eddie.huang@mediatek.com>
 (Eddie Huang's message of "Fri, 19 Feb 2016 14:00:43 +0800")
References: <1455861643-24307-1-git-send-email-eddie.huang@mediatek.com>
Message-ID: <7h37skw9jd.fsf@baylibre.com>

Eddie Huang <eddie.huang at mediatek.com> writes:

> MT8173 E1 chip has one bug that if turn off USB power domain, vcore
> power will also be off, thus cause modules using vcore power domain
> fail, like MMC. The E1 chip only found on MT8173-evb board and this
> board only has E1 chip, so implement this as a board specific
> workaround.
>
> Pwrapper use vcore power, so add pwrapper using USB power domain to
> keep USB power domain not to zero and disabled.
>
> Signed-off-by: Eddie Huang <eddie.huang at mediatek.com>

Tested-by: Kevin Hilman <khilman at baylibre.com>

I verified that this gets my mt8173-evb booting again when I enable MMC
support.

Thanks,

Kevin


From ykk at rock-chips.com  Mon Feb 22 16:48:01 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Tue, 23 Feb 2016 08:48:01 +0800
Subject: [PATCH 0/2] Add Rockchip display port phy driver support
In-Reply-To: <56CAEDBE.2050808@ti.com>
References: <1455534071-31230-1-git-send-email-ykk@rock-chips.com>
 <56CAEDBE.2050808@ti.com>
Message-ID: <56CBAC41.9000400@rock-chips.com>

Kishon,

On 02/22/2016 07:15 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Monday 15 February 2016 04:31 PM, Yakir Yang wrote:
>> Hi Kison,
>>
>> This series is splited from Analogix DP DRM thread [0], and Heiko suggest this
>> should be an independent thread which may be easy for you to apply.
> Indeed. Merged now thanks. (Changed the year to 2016 in the file header before
> merging)

Thanks a lot  ;)

Yakir
>
> Thanks
> Kishon
>
>> Best regards,
>> Yakir
>>
>> [0]: https://patchwork.kernel.org/patch/8086571/
>>
>>
>> Changes in v12:
>> - Re-order the include headers file alphabetically in phy-rockchip-dp.c (Jingoo)
>>
>> Changes in v11:
>> - Correct the title of this rockchip dp phy document(Rob)
>> - Add the ack from Rob Herring
>>
>> Changes in v10:
>> - Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
>>      BIT(4) -> BIT(20)
>>
>> Changes in v9:
>> - Removed the unused the variable "res" in probe function. (Heiko)
>> - Removed the unused head file.
>>
>> Changes in v8:
>> - Fix the mixed spacers on macro definitions. (Heiko)
>> - Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
>> - Remove the specific address in the example node name. (Heiko)
>>
>> Changes in v7:
>> - Simply the commit message. (Kishon)
>> - Symmetrical enable/disbale the phy clock and power. (Kishon)
>> - Simplify the commit message. (Kishon)
>>
>> Changes in v5:
>> - Remove "reg" DT property, cause driver could poweron/poweroff phy via
>>    the exist "grf" syscon already. And rename the example DT node from
>>    "edp_phy: phy at ff770274" to "edp_phy: edp-phy" directly. (Heiko)
>> - Add deivce_node at the front of driver, update phy_ops type from "static
>>    struct" to "static const struct". And correct the input paramters of
>>    devm_phy_create() interfaces. (Heiko)
>> - Split binding doc's from driver changes. (Rob)
>> - Update the rockchip,grf explain in document, and correct the clock required
>>    elemets in document. (Rob & Heiko)
>>
>> Changes in v4:
>> - Add commit message, and remove the redundant rockchip_dp_phy_init()
>>    function, move those code to probe() method. And remove driver .owner
>>    number. (Kishon)
>>
>> Changes in v3:
>> - Suggest, add rockchip dp phy driver, collect the phy clocks and
>>    power control. (Heiko)
>>
>> Yakir Yang (2):
>>    phy: Add driver for rockchip Display Port PHY
>>    dt-bindings: add document for rockchip dp phy
>>
>>   .../devicetree/bindings/phy/rockchip-dp-phy.txt    |  22 +++
>>   drivers/phy/Kconfig                                |   7 +
>>   drivers/phy/Makefile                               |   1 +
>>   drivers/phy/phy-rockchip-dp.c                      | 151 +++++++++++++++++++++
>>   4 files changed, 181 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>>   create mode 100644 drivers/phy/phy-rockchip-dp.c
>>
>
>




From sugar.zhang at rock-chips.com  Mon Feb 22 16:57:04 2016
From: sugar.zhang at rock-chips.com (sugar)
Date: Tue, 23 Feb 2016 08:57:04 +0800
Subject: [PATCH v1 0/2] patches to add support for rockchip rt5640 card
In-Reply-To: <20160222110416.GC18327@sirena.org.uk>
References: <1456127815-68575-1-git-send-email-sugar.zhang@rock-chips.com>
 <20160222110416.GC18327@sirena.org.uk>
Message-ID: <56CBAE60.6000806@rock-chips.com>



? 2/22/2016 19:04, Mark Brown ??:
> On Mon, Feb 22, 2016 at 03:56:53PM +0800, Sugar Zhang wrote:
>
>> Sugar Zhang (2):
>>    ASoC: rockchip: i2s: add default values for registers
>>    ASoC: rt5640: add master clock handling for rt5640
>
> These appear to be commpletly unrelated patches so should each be sent
> individually rather than as a series - that way there is no confusion
> about them possibly depending on each other and they are easier to
> review and apply.
>

Got it, thanks.



From horms+renesas at verge.net.au  Mon Feb 22 17:17:44 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 23 Feb 2016 10:17:44 +0900
Subject: [PATCH 0/2] ARM,
 arm64: dts: use fallback etheravb compatibility string
Message-ID: <1456190266-3781-1-git-send-email-horms+renesas@verge.net.au>

Use recently added fallback etheravb compatibility string in
device trees where it is not already used.

Based on renesas-devel-20160222-v4.5-rc5

Simon Horman (2):
  ARM: dts: r8a7790: use fallback etheravb compatibility string
  arm64: dts: r8a7795: use fallback etheravb compatibility string

 arch/arm/boot/dts/r8a7790.dtsi           | 2 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

-- 
2.1.4



From horms+renesas at verge.net.au  Mon Feb 22 17:17:45 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 23 Feb 2016 10:17:45 +0900
Subject: [PATCH 1/2] ARM: dts: r8a7790: use fallback etheravb compatibility
 string
In-Reply-To: <1456190266-3781-1-git-send-email-horms+renesas@verge.net.au>
References: <1456190266-3781-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1456190266-3781-2-git-send-email-horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7790 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index ba4c2530d79f..ec933f6ff5bf 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -773,7 +773,7 @@
 	};
 
 	avb: ethernet at e6800000 {
-		compatible = "renesas,etheravb-r8a7790";
+		compatible = "renesas,etheravb-r8a7790", "renesas,etheravb-rcar-gen2";
 		reg = <0 0xe6800000 0 0x800>, <0 0xee0e8000 0 0x4000>;
 		interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_ETHERAVB>;
-- 
2.1.4



From horms+renesas at verge.net.au  Mon Feb 22 17:17:46 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Tue, 23 Feb 2016 10:17:46 +0900
Subject: [PATCH 2/2] arm64: dts: r8a7795: use fallback etheravb compatibility
 string
In-Reply-To: <1456190266-3781-1-git-send-email-horms+renesas@verge.net.au>
References: <1456190266-3781-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1456190266-3781-3-git-send-email-horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7795 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index c2bffd160c18..39d6dc104206 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -473,7 +473,8 @@
 		};
 
 		avb: ethernet at e6800000 {
-			compatible = "renesas,etheravb-r8a7795";
+			compatible = "renesas,etheravb-r8a7795",
+				     "renesas,etheravb-rcar-gen3",
 			reg = <0 0xe6800000 0 0x800>, <0 0xe6a00000 0 0x10000>;
 			interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
-- 
2.1.4



From yong.wu at mediatek.com  Mon Feb 22 09:20:46 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 23 Feb 2016 01:20:46 +0800
Subject: [PATCH v10 0/5] MT8173 IOMMU SUPPORT
Message-ID: <1456161651-6136-1-git-send-email-yong.wu@mediatek.com>

  This patch set adds support for m4u(Multimedia Memory Management Unit),
Currently it only support the m4u with 2 levels of pagetable on mt8173.

  It's based on Robin Murphy's Short-descriptor v3[1].
 
  Please check the hardware block diagram of Mediatek IOMMU.
 
              m4u (Multimedia Memory Management Unit)
               |
           SMI Common(Smart Multimedia Interface Common)
               |
       +----------------+-------
       |                |
       |                |
   SMI larb0        SMI larb1   ... SoCs have several SMI local arbiter(larb).
   (display)         (vdec)
       |                |
       |                |
 +-----+-----+     +----+----+
 |     |     |     |    |    |
 |     |     |...  |    |    |  ... There are different ports in each larb.
 |     |     |     |    |    |
OVL0 RDMA0 WDMA0  MC   PP   VLD

  As above, The Multimedia HW will go through SMI and M4U while it
access EMI. SMI is a bridge between m4u and the Multimedia HW. It contain
smi local arbiter and smi common. It will control whether the Multimedia
HW should go though the m4u for translation or bypass it and talk
directly with EMI. And also SMI help control the power domain and clocks for
each local arbiter.
  Normally we specify a local arbiter(larb) for each multimedia HW
like display, video decode, and camera. And there are different ports
in each larb. Take a example, There are many ports like MC, PP, VLD in the
video decode local arbiter, all these ports are according to the video HW.

[1]: http://thread.gmane.org/gmane.linux.kernel.iommu/12007

v10:
 - Add some missing includes file following Guenter's suggestion.

v9: http://lists.linuxfoundation.org/pipermail/iommu/2016-February/015713.html
 - rebase onto Robin's Short-descriptor v3.
 - add the Acks and other tags for all the patchs.(No change the code.)

v8: http://thread.gmane.org/gmane.linux.kernel.iommu/11974
 - rebase onto v4.5-rc1.
 - add depends on (ARM || ARM64) for MTK_IOMMU in Kconfig to avoid build fail
   in other ARCHs.
 - delete COHERENCE_EN bit.
 - delete a *if* while config iommu information since the iommu is always
   enabled currently.

v7: http://lists.linuxfoundation.org/pipermail/iommu/2015-December/015214.html
- rebase onto Robin's short v2:
  http://lists.linuxfoundation.org/pipermail/iommu/2015-December/015210.html
- Adjust the iommu probe sequence to meet the expectant flow that the iommu
  core help create the domain.
- use component additional data instead of the interface mtk_smi_config_port.
- reconstruct the SMI help function.

v6: http://lists.linuxfoundation.org/pipermail/iommu/2015-December/015105.html
-rebase onto v4.4-rc1.
-Use Robin's reposting Short-decriptor.
 http://lists.linuxfoundation.org/pipermail/iommu/2015-December/015088.html
-Add component for m4u and smi since m4u should depend on smi-larb.
 The master device is the m4u device, and the client one is the smi-larb device. 
-Change mtk iommu-cells from 2 to 1 since the mapping between larb and port is
 fixed. Compare this with v2, we redefine MTK_M4U_ID following this register
 REG_MMU_INT_ID.
-About SMI: Add some help funcion and rename some function and struction for
 more readable. 
 These three above are according to Daniel Kurtz's suggestion.

v5: http://lists.linuxfoundation.org/pipermail/iommu/2015-October/014586.html
-rebase onto v4.3-rc1.
-About MTK iommu: don't return the same domain while domain_alloc, change the
 domain's flow according to the M4U HW.
-About Short-descriptor: Improve many error-handles, NO_PERMS quirk, and 
 add TLBI_MAP quirk following Will's Suggestion; Add io-pgtable don't use 
 dma_to_phys; Add a loop in arm_short_unmap since iommu_unmap don't care the 
 physical address align.
-About SMI driver: Add a help funcion for some similar code. Add PROPRE_DEFER
 for power-domain as MTK SCPSYS is module_init currently.

v4: http://lists.linuxfoundation.org/pipermail/iommu/2015-August/013903.html
-use only one iommu domain here based on the Robin's DMA-v5:
 http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013900.html
-remove flush_pgtable.
-change writel to writel_relaxed.
-about Short-descriptor: move dma_map_single into io-pgtable-arm-short.
 Improve the flow of free pgtable and add NO_XN+NO_PERMS quirk following
 Will's suggestion.
-Change two sytle issues in dtsi according to Daniel's suggestion.

v3: http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013632.html
-rebased onto v4.2-rc1
-improve iommu flow based on the Robin's DMA v3:
 http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013597.html
-change mtk iommu-cells from 1 to 2.
-about Short-descriptor: add split function; add self-test; add some other bits like nG,
 XN according to the spec; add SUPERSECTION and MTK quirk; move io_pgtable_ops_to_pgtable
 out from LPAE to the header file.
-about SMI: move from driver/soc/mediatek to driver/memory; change the clocks from
 clk[2] to clk_apb and clk_smi; add pm.
-add iommu suspend/resume to backup/restore register.

v2: http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013028.html
-add arm short descriptor support.
-seperate smi common from smi and change the clock-names according
 to smi HW.
-delete the hardcode of the port-names in mt8173.
 replace this with larb-portes-nr in dtsi.
-fix some coding style issues.

v1: http://lists.infradead.org/pipermail/linux-mediatek/2015-March/000058.html
-initial version.

Yong Wu (5):
  dt-bindings: iommu: Add binding for mediatek IOMMU
  dt-bindings: mediatek: Add smi dts binding
  memory: mediatek: Add SMI driver
  iommu/mediatek: Add mt8173 IOMMU driver
  dts: mt8173: Add iommu/smi nodes for mt8173

 .../devicetree/bindings/iommu/mediatek,iommu.txt   |  68 ++
 .../memory-controllers/mediatek,smi-common.txt     |  24 +
 .../memory-controllers/mediatek,smi-larb.txt       |  25 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi           |  81 +++
 drivers/iommu/Kconfig                              |  16 +
 drivers/iommu/Makefile                             |   1 +
 drivers/iommu/mtk_iommu.c                          | 737 +++++++++++++++++++++
 drivers/memory/Kconfig                             |   8 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/mtk-smi.c                           | 273 ++++++++
 include/dt-bindings/memory/mt8173-larb-port.h      | 111 ++++
 include/soc/mediatek/smi.h                         |  58 ++
 12 files changed, 1403 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
 create mode 100644 drivers/iommu/mtk_iommu.c
 create mode 100644 drivers/memory/mtk-smi.c
 create mode 100644 include/dt-bindings/memory/mt8173-larb-port.h
 create mode 100644 include/soc/mediatek/smi.h

-- 
1.8.1.1.dirty



From yong.wu at mediatek.com  Mon Feb 22 09:20:47 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 23 Feb 2016 01:20:47 +0800
Subject: [PATCH v10 1/5] dt-bindings: iommu: Add binding for mediatek IOMMU
In-Reply-To: <1456161651-6136-1-git-send-email-yong.wu@mediatek.com>
References: <1456161651-6136-1-git-send-email-yong.wu@mediatek.com>
Message-ID: <1456161651-6136-2-git-send-email-yong.wu@mediatek.com>

This patch add mediatek iommu dts binding document.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/iommu/mediatek,iommu.txt   | 68 ++++++++++++++++++++++
 1 file changed, 68 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt

diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
new file mode 100644
index 0000000..cd1b1cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
@@ -0,0 +1,68 @@
+* Mediatek IOMMU Architecture Implementation
+
+  Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U) which
+uses the ARM Short-Descriptor translation table format for address translation.
+
+  About the M4U Hardware Block Diagram, please check below:
+
+              EMI (External Memory Interface)
+               |
+              m4u (Multimedia Memory Management Unit)
+               |
+           SMI Common(Smart Multimedia Interface Common)
+               |
+       +----------------+-------
+       |                |
+       |                |
+   SMI larb0        SMI larb1   ... SoCs have several SMI local arbiter(larb).
+   (display)         (vdec)
+       |                |
+       |                |
+ +-----+-----+     +----+----+
+ |     |     |     |    |    |
+ |     |     |...  |    |    |  ... There are different ports in each larb.
+ |     |     |     |    |    |
+OVL0 RDMA0 WDMA0  MC   PP   VLD
+
+  As above, The Multimedia HW will go through SMI and M4U while it
+access EMI. SMI is a bridge between m4u and the Multimedia HW. It contain
+smi local arbiter and smi common. It will control whether the Multimedia
+HW should go though the m4u for translation or bypass it and talk
+directly with EMI. And also SMI help control the power domain and clocks for
+each local arbiter.
+  Normally we specify a local arbiter(larb) for each multimedia HW
+like display, video decode, and camera. And there are different ports
+in each larb. Take a example, There are many ports like MC, PP, VLD in the
+video decode local arbiter, all these ports are according to the video HW.
+
+Required properties:
+- compatible : must be "mediatek,mt8173-m4u".
+- reg : m4u register base and size.
+- interrupts : the interrupt of m4u.
+- clocks : must contain one entry for each clock-names.
+- clock-names : must be "bclk", It is the block clock of m4u.
+- mediatek,larbs : List of phandle to the local arbiters in the current Socs.
+	Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
+	according to the local arbiter index, like larb0, larb1, larb2...
+- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
+	Specifies the mtk_m4u_id as defined in
+	dt-binding/memory/mt8173-larb-port.h.
+
+Example:
+	iommu: iommu at 10205000 {
+		compatible = "mediatek,mt8173-m4u";
+		reg = <0 0x10205000 0 0x1000>;
+		interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>;
+		clocks = <&infracfg CLK_INFRA_M4U>;
+		clock-names = "bclk";
+		mediatek,larbs = <&larb0 &larb1 &larb2 &larb3 &larb4 &larb5>;
+		#iommu-cells = <1>;
+	};
+
+Example for a client device:
+	display {
+		compatible = "mediatek,mt8173-disp";
+		iommus = <&iommu M4U_PORT_DISP_OVL0>,
+			 <&iommu M4U_PORT_DISP_RDMA0>;
+		...
+	};
-- 
1.8.1.1.dirty



From yong.wu at mediatek.com  Mon Feb 22 09:20:48 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 23 Feb 2016 01:20:48 +0800
Subject: [PATCH v10 2/5] dt-bindings: mediatek: Add smi dts binding
In-Reply-To: <1456161651-6136-1-git-send-email-yong.wu@mediatek.com>
References: <1456161651-6136-1-git-send-email-yong.wu@mediatek.com>
Message-ID: <1456161651-6136-3-git-send-email-yong.wu@mediatek.com>

This patch add smi binding document and smi local arbiter header file.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../memory-controllers/mediatek,smi-common.txt     |  24 +++++
 .../memory-controllers/mediatek,smi-larb.txt       |  25 +++++
 include/dt-bindings/memory/mt8173-larb-port.h      | 111 +++++++++++++++++++++
 3 files changed, 160 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
 create mode 100644 include/dt-bindings/memory/mt8173-larb-port.h

diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
new file mode 100644
index 0000000..06a83ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
@@ -0,0 +1,24 @@
+SMI (Smart Multimedia Interface) Common
+
+The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
+
+Required properties:
+- compatible : must be "mediatek,mt8173-smi-common"
+- reg : the register and size of the SMI block.
+- power-domains : a phandle to the power domain of this local arbiter.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : must contain 2 entries, as follows:
+  - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
+	    the register.
+  - "smi" : It's the clock for transfer data and command.
+  They may be the same if both source clocks are the same.
+
+Example:
+	smi_common: smi at 14022000 {
+		compatible = "mediatek,mt8173-smi-common";
+		reg = <0 0x14022000 0 0x1000>;
+		power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+		clocks = <&mmsys CLK_MM_SMI_COMMON>,
+			 <&mmsys CLK_MM_SMI_COMMON>;
+		clock-names = "apb", "smi";
+	};
diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
new file mode 100644
index 0000000..55ff3b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
@@ -0,0 +1,25 @@
+SMI (Smart Multimedia Interface) Local Arbiter
+
+The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
+
+Required properties:
+- compatible : must be "mediatek,mt8173-smi-larb"
+- reg : the register and size of this local arbiter.
+- mediatek,smi : a phandle to the smi_common node.
+- power-domains : a phandle to the power domain of this local arbiter.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names: must contain 2 entries, as follows:
+  - "apb" : Advanced Peripheral Bus clock, It's the clock for setting
+	    the register.
+  - "smi" : It's the clock for transfer data and command.
+
+Example:
+	larb1: larb at 16010000 {
+		compatible = "mediatek,mt8173-smi-larb";
+		reg = <0 0x16010000 0 0x1000>;
+		mediatek,smi = <&smi_common>;
+		power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
+		clocks = <&vdecsys CLK_VDEC_CKEN>,
+			 <&vdecsys CLK_VDEC_LARB_CKEN>;
+		clock-names = "apb", "smi";
+	};
diff --git a/include/dt-bindings/memory/mt8173-larb-port.h b/include/dt-bindings/memory/mt8173-larb-port.h
new file mode 100644
index 0000000..5fef5d1
--- /dev/null
+++ b/include/dt-bindings/memory/mt8173-larb-port.h
@@ -0,0 +1,111 @@
+/*
+ * Copyright (c) 2015-2016 MediaTek Inc.
+ * Author: Yong Wu <yong.wu at mediatek.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.
+ */
+#ifndef __DTS_IOMMU_PORT_MT8173_H
+#define __DTS_IOMMU_PORT_MT8173_H
+
+#define MTK_M4U_ID(larb, port)		(((larb) << 5) | (port))
+/* Local arbiter ID */
+#define MTK_M4U_TO_LARB(id)		(((id) >> 5) & 0x7)
+/* PortID within the local arbiter */
+#define MTK_M4U_TO_PORT(id)		((id) & 0x1f)
+
+#define M4U_LARB0_ID			0
+#define M4U_LARB1_ID			1
+#define M4U_LARB2_ID			2
+#define M4U_LARB3_ID			3
+#define M4U_LARB4_ID			4
+#define M4U_LARB5_ID			5
+
+/* larb0 */
+#define M4U_PORT_DISP_OVL0		MTK_M4U_ID(M4U_LARB0_ID, 0)
+#define M4U_PORT_DISP_RDMA0		MTK_M4U_ID(M4U_LARB0_ID, 1)
+#define M4U_PORT_DISP_WDMA0		MTK_M4U_ID(M4U_LARB0_ID, 2)
+#define M4U_PORT_DISP_OD_R		MTK_M4U_ID(M4U_LARB0_ID, 3)
+#define M4U_PORT_DISP_OD_W		MTK_M4U_ID(M4U_LARB0_ID, 4)
+#define M4U_PORT_MDP_RDMA0		MTK_M4U_ID(M4U_LARB0_ID, 5)
+#define M4U_PORT_MDP_WDMA		MTK_M4U_ID(M4U_LARB0_ID, 6)
+#define M4U_PORT_MDP_WROT0		MTK_M4U_ID(M4U_LARB0_ID, 7)
+
+/* larb1 */
+#define M4U_PORT_HW_VDEC_MC_EXT		MTK_M4U_ID(M4U_LARB1_ID, 0)
+#define M4U_PORT_HW_VDEC_PP_EXT		MTK_M4U_ID(M4U_LARB1_ID, 1)
+#define M4U_PORT_HW_VDEC_UFO_EXT	MTK_M4U_ID(M4U_LARB1_ID, 2)
+#define M4U_PORT_HW_VDEC_VLD_EXT	MTK_M4U_ID(M4U_LARB1_ID, 3)
+#define M4U_PORT_HW_VDEC_VLD2_EXT	MTK_M4U_ID(M4U_LARB1_ID, 4)
+#define M4U_PORT_HW_VDEC_AVC_MV_EXT	MTK_M4U_ID(M4U_LARB1_ID, 5)
+#define M4U_PORT_HW_VDEC_PRED_RD_EXT	MTK_M4U_ID(M4U_LARB1_ID, 6)
+#define M4U_PORT_HW_VDEC_PRED_WR_EXT	MTK_M4U_ID(M4U_LARB1_ID, 7)
+#define M4U_PORT_HW_VDEC_PPWRAP_EXT	MTK_M4U_ID(M4U_LARB1_ID, 8)
+#define M4U_PORT_HW_VDEC_TILE		MTK_M4U_ID(M4U_LARB1_ID, 9)
+
+/* larb2 */
+#define M4U_PORT_IMGO			MTK_M4U_ID(M4U_LARB2_ID, 0)
+#define M4U_PORT_RRZO			MTK_M4U_ID(M4U_LARB2_ID, 1)
+#define M4U_PORT_AAO			MTK_M4U_ID(M4U_LARB2_ID, 2)
+#define M4U_PORT_LCSO			MTK_M4U_ID(M4U_LARB2_ID, 3)
+#define M4U_PORT_ESFKO			MTK_M4U_ID(M4U_LARB2_ID, 4)
+#define M4U_PORT_IMGO_D			MTK_M4U_ID(M4U_LARB2_ID, 5)
+#define M4U_PORT_LSCI			MTK_M4U_ID(M4U_LARB2_ID, 6)
+#define M4U_PORT_LSCI_D			MTK_M4U_ID(M4U_LARB2_ID, 7)
+#define M4U_PORT_BPCI			MTK_M4U_ID(M4U_LARB2_ID, 8)
+#define M4U_PORT_BPCI_D			MTK_M4U_ID(M4U_LARB2_ID, 9)
+#define M4U_PORT_UFDI			MTK_M4U_ID(M4U_LARB2_ID, 10)
+#define M4U_PORT_IMGI			MTK_M4U_ID(M4U_LARB2_ID, 11)
+#define M4U_PORT_IMG2O			MTK_M4U_ID(M4U_LARB2_ID, 12)
+#define M4U_PORT_IMG3O			MTK_M4U_ID(M4U_LARB2_ID, 13)
+#define M4U_PORT_VIPI			MTK_M4U_ID(M4U_LARB2_ID, 14)
+#define M4U_PORT_VIP2I			MTK_M4U_ID(M4U_LARB2_ID, 15)
+#define M4U_PORT_VIP3I			MTK_M4U_ID(M4U_LARB2_ID, 16)
+#define M4U_PORT_LCEI			MTK_M4U_ID(M4U_LARB2_ID, 17)
+#define M4U_PORT_RB			MTK_M4U_ID(M4U_LARB2_ID, 18)
+#define M4U_PORT_RP			MTK_M4U_ID(M4U_LARB2_ID, 19)
+#define M4U_PORT_WR			MTK_M4U_ID(M4U_LARB2_ID, 20)
+
+/* larb3 */
+#define M4U_PORT_VENC_RCPU		MTK_M4U_ID(M4U_LARB3_ID, 0)
+#define M4U_PORT_VENC_REC		MTK_M4U_ID(M4U_LARB3_ID, 1)
+#define M4U_PORT_VENC_BSDMA		MTK_M4U_ID(M4U_LARB3_ID, 2)
+#define M4U_PORT_VENC_SV_COMV		MTK_M4U_ID(M4U_LARB3_ID, 3)
+#define M4U_PORT_VENC_RD_COMV		MTK_M4U_ID(M4U_LARB3_ID, 4)
+#define M4U_PORT_JPGENC_RDMA		MTK_M4U_ID(M4U_LARB3_ID, 5)
+#define M4U_PORT_JPGENC_BSDMA		MTK_M4U_ID(M4U_LARB3_ID, 6)
+#define M4U_PORT_JPGDEC_WDMA		MTK_M4U_ID(M4U_LARB3_ID, 7)
+#define M4U_PORT_JPGDEC_BSDMA		MTK_M4U_ID(M4U_LARB3_ID, 8)
+#define M4U_PORT_VENC_CUR_LUMA		MTK_M4U_ID(M4U_LARB3_ID, 9)
+#define M4U_PORT_VENC_CUR_CHROMA	MTK_M4U_ID(M4U_LARB3_ID, 10)
+#define M4U_PORT_VENC_REF_LUMA		MTK_M4U_ID(M4U_LARB3_ID, 11)
+#define M4U_PORT_VENC_REF_CHROMA	MTK_M4U_ID(M4U_LARB3_ID, 12)
+#define M4U_PORT_VENC_NBM_RDMA		MTK_M4U_ID(M4U_LARB3_ID, 13)
+#define M4U_PORT_VENC_NBM_WDMA		MTK_M4U_ID(M4U_LARB3_ID, 14)
+
+/* larb4 */
+#define M4U_PORT_DISP_OVL1		MTK_M4U_ID(M4U_LARB4_ID, 0)
+#define M4U_PORT_DISP_RDMA1		MTK_M4U_ID(M4U_LARB4_ID, 1)
+#define M4U_PORT_DISP_RDMA2		MTK_M4U_ID(M4U_LARB4_ID, 2)
+#define M4U_PORT_DISP_WDMA1		MTK_M4U_ID(M4U_LARB4_ID, 3)
+#define M4U_PORT_MDP_RDMA1		MTK_M4U_ID(M4U_LARB4_ID, 4)
+#define M4U_PORT_MDP_WROT1		MTK_M4U_ID(M4U_LARB4_ID, 5)
+
+/* larb5 */
+#define M4U_PORT_VENC_RCPU_SET2		MTK_M4U_ID(M4U_LARB5_ID, 0)
+#define M4U_PORT_VENC_REC_FRM_SET2	MTK_M4U_ID(M4U_LARB5_ID, 1)
+#define M4U_PORT_VENC_REF_LUMA_SET2	MTK_M4U_ID(M4U_LARB5_ID, 2)
+#define M4U_PORT_VENC_REC_CHROMA_SET2	MTK_M4U_ID(M4U_LARB5_ID, 3)
+#define M4U_PORT_VENC_BSDMA_SET2	MTK_M4U_ID(M4U_LARB5_ID, 4)
+#define M4U_PORT_VENC_CUR_LUMA_SET2	MTK_M4U_ID(M4U_LARB5_ID, 5)
+#define M4U_PORT_VENC_CUR_CHROMA_SET2	MTK_M4U_ID(M4U_LARB5_ID, 6)
+#define M4U_PORT_VENC_RD_COMA_SET2	MTK_M4U_ID(M4U_LARB5_ID, 7)
+#define M4U_PORT_VENC_SV_COMA_SET2	MTK_M4U_ID(M4U_LARB5_ID, 8)
+
+#endif
-- 
1.8.1.1.dirty



From yong.wu at mediatek.com  Mon Feb 22 09:20:49 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 23 Feb 2016 01:20:49 +0800
Subject: [PATCH v10 3/5] memory: mediatek: Add SMI driver
In-Reply-To: <1456161651-6136-1-git-send-email-yong.wu@mediatek.com>
References: <1456161651-6136-1-git-send-email-yong.wu@mediatek.com>
Message-ID: <1456161651-6136-4-git-send-email-yong.wu@mediatek.com>

This patch add SMI(Smart Multimedia Interface) driver. This driver
is responsible to enable/disable iommu and control the power domain
and clocks of each local arbiter.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Tested-by: Philipp Zabel <p.zabel at pengutronix.de>
Reviewed-by: Daniel Kurtz <djkurtz at chromium.org>
Tested-by: Daniel Kurtz <djkurtz at chromium.org>
Signed-off-by: Matthias Brugger <matthias.bgg at gmail.com>
---
 drivers/memory/Kconfig     |   8 ++
 drivers/memory/Makefile    |   1 +
 drivers/memory/mtk-smi.c   | 273 +++++++++++++++++++++++++++++++++++++++++++++
 include/soc/mediatek/smi.h |  58 ++++++++++
 4 files changed, 340 insertions(+)
 create mode 100644 drivers/memory/mtk-smi.c
 create mode 100644 include/soc/mediatek/smi.h

diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 6f31546..51d5cd2 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -114,6 +114,14 @@ config JZ4780_NEMC
 	  the Ingenic JZ4780. This controller is used to handle external
 	  memory devices such as NAND and SRAM.
 
+config MTK_SMI
+	bool
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	help
+	  This driver is for the Memory Controller module in MediaTek SoCs,
+	  mainly help enable/disable iommu and control the power domain and
+	  clocks for each local arbiter.
+
 source "drivers/memory/tegra/Kconfig"
 
 endif
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 1c46af5..890bdf4 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -15,5 +15,6 @@ obj-$(CONFIG_FSL_IFC)		+= fsl_ifc.o
 obj-$(CONFIG_MVEBU_DEVBUS)	+= mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)	+= tegra20-mc.o
 obj-$(CONFIG_JZ4780_NEMC)	+= jz4780-nemc.o
+obj-$(CONFIG_MTK_SMI)		+= mtk-smi.o
 
 obj-$(CONFIG_TEGRA_MC)		+= tegra/
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
new file mode 100644
index 0000000..089091f
--- /dev/null
+++ b/drivers/memory/mtk-smi.c
@@ -0,0 +1,273 @@
+/*
+ * Copyright (c) 2015-2016 MediaTek Inc.
+ * Author: Yong Wu <yong.wu at mediatek.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.
+ */
+#include <linux/clk.h>
+#include <linux/component.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <soc/mediatek/smi.h>
+
+#define SMI_LARB_MMU_EN		0xf00
+
+struct mtk_smi {
+	struct device	*dev;
+	struct clk	*clk_apb, *clk_smi;
+};
+
+struct mtk_smi_larb { /* larb: local arbiter */
+	struct mtk_smi  smi;
+	void __iomem	*base;
+	struct device	*smi_common_dev;
+	u32		*mmu;
+};
+
+static int mtk_smi_enable(const struct mtk_smi *smi)
+{
+	int ret;
+
+	ret = pm_runtime_get_sync(smi->dev);
+	if (ret < 0)
+		return ret;
+
+	ret = clk_prepare_enable(smi->clk_apb);
+	if (ret)
+		goto err_put_pm;
+
+	ret = clk_prepare_enable(smi->clk_smi);
+	if (ret)
+		goto err_disable_apb;
+
+	return 0;
+
+err_disable_apb:
+	clk_disable_unprepare(smi->clk_apb);
+err_put_pm:
+	pm_runtime_put_sync(smi->dev);
+	return ret;
+}
+
+static void mtk_smi_disable(const struct mtk_smi *smi)
+{
+	clk_disable_unprepare(smi->clk_smi);
+	clk_disable_unprepare(smi->clk_apb);
+	pm_runtime_put_sync(smi->dev);
+}
+
+int mtk_smi_larb_get(struct device *larbdev)
+{
+	struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
+	struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
+	int ret;
+
+	/* Enable the smi-common's power and clocks */
+	ret = mtk_smi_enable(common);
+	if (ret)
+		return ret;
+
+	/* Enable the larb's power and clocks */
+	ret = mtk_smi_enable(&larb->smi);
+	if (ret) {
+		mtk_smi_disable(common);
+		return ret;
+	}
+
+	/* Configure the iommu info for this larb */
+	writel(*larb->mmu, larb->base + SMI_LARB_MMU_EN);
+
+	return 0;
+}
+
+void mtk_smi_larb_put(struct device *larbdev)
+{
+	struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
+	struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
+
+	/*
+	 * Don't de-configure the iommu info for this larb since there may be
+	 * several modules in this larb.
+	 * The iommu info will be reset after power off.
+	 */
+
+	mtk_smi_disable(&larb->smi);
+	mtk_smi_disable(common);
+}
+
+static int
+mtk_smi_larb_bind(struct device *dev, struct device *master, void *data)
+{
+	struct mtk_smi_larb *larb = dev_get_drvdata(dev);
+	struct mtk_smi_iommu *smi_iommu = data;
+	unsigned int         i;
+
+	for (i = 0; i < smi_iommu->larb_nr; i++) {
+		if (dev == smi_iommu->larb_imu[i].dev) {
+			/* The 'mmu' may be updated in iommu-attach/detach. */
+			larb->mmu = &smi_iommu->larb_imu[i].mmu;
+			return 0;
+		}
+	}
+	return -ENODEV;
+}
+
+static void
+mtk_smi_larb_unbind(struct device *dev, struct device *master, void *data)
+{
+	/* Do nothing as the iommu is always enabled. */
+}
+
+static const struct component_ops mtk_smi_larb_component_ops = {
+	.bind = mtk_smi_larb_bind,
+	.unbind = mtk_smi_larb_unbind,
+};
+
+static int mtk_smi_larb_probe(struct platform_device *pdev)
+{
+	struct mtk_smi_larb *larb;
+	struct resource *res;
+	struct device *dev = &pdev->dev;
+	struct device_node *smi_node;
+	struct platform_device *smi_pdev;
+
+	if (!dev->pm_domain)
+		return -EPROBE_DEFER;
+
+	larb = devm_kzalloc(dev, sizeof(*larb), GFP_KERNEL);
+	if (!larb)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	larb->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(larb->base))
+		return PTR_ERR(larb->base);
+
+	larb->smi.clk_apb = devm_clk_get(dev, "apb");
+	if (IS_ERR(larb->smi.clk_apb))
+		return PTR_ERR(larb->smi.clk_apb);
+
+	larb->smi.clk_smi = devm_clk_get(dev, "smi");
+	if (IS_ERR(larb->smi.clk_smi))
+		return PTR_ERR(larb->smi.clk_smi);
+	larb->smi.dev = dev;
+
+	smi_node = of_parse_phandle(dev->of_node, "mediatek,smi", 0);
+	if (!smi_node)
+		return -EINVAL;
+
+	smi_pdev = of_find_device_by_node(smi_node);
+	of_node_put(smi_node);
+	if (smi_pdev) {
+		larb->smi_common_dev = &smi_pdev->dev;
+	} else {
+		dev_err(dev, "Failed to get the smi_common device\n");
+		return -EINVAL;
+	}
+
+	pm_runtime_enable(dev);
+	platform_set_drvdata(pdev, larb);
+	return component_add(dev, &mtk_smi_larb_component_ops);
+}
+
+static int mtk_smi_larb_remove(struct platform_device *pdev)
+{
+	pm_runtime_disable(&pdev->dev);
+	component_del(&pdev->dev, &mtk_smi_larb_component_ops);
+	return 0;
+}
+
+static const struct of_device_id mtk_smi_larb_of_ids[] = {
+	{ .compatible = "mediatek,mt8173-smi-larb",},
+	{}
+};
+
+static struct platform_driver mtk_smi_larb_driver = {
+	.probe	= mtk_smi_larb_probe,
+	.remove = mtk_smi_larb_remove,
+	.driver	= {
+		.name = "mtk-smi-larb",
+		.of_match_table = mtk_smi_larb_of_ids,
+	}
+};
+
+static int mtk_smi_common_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct mtk_smi *common;
+
+	if (!dev->pm_domain)
+		return -EPROBE_DEFER;
+
+	common = devm_kzalloc(dev, sizeof(*common), GFP_KERNEL);
+	if (!common)
+		return -ENOMEM;
+	common->dev = dev;
+
+	common->clk_apb = devm_clk_get(dev, "apb");
+	if (IS_ERR(common->clk_apb))
+		return PTR_ERR(common->clk_apb);
+
+	common->clk_smi = devm_clk_get(dev, "smi");
+	if (IS_ERR(common->clk_smi))
+		return PTR_ERR(common->clk_smi);
+
+	pm_runtime_enable(dev);
+	platform_set_drvdata(pdev, common);
+	return 0;
+}
+
+static int mtk_smi_common_remove(struct platform_device *pdev)
+{
+	pm_runtime_disable(&pdev->dev);
+	return 0;
+}
+
+static const struct of_device_id mtk_smi_common_of_ids[] = {
+	{ .compatible = "mediatek,mt8173-smi-common", },
+	{}
+};
+
+static struct platform_driver mtk_smi_common_driver = {
+	.probe	= mtk_smi_common_probe,
+	.remove = mtk_smi_common_remove,
+	.driver	= {
+		.name = "mtk-smi-common",
+		.of_match_table = mtk_smi_common_of_ids,
+	}
+};
+
+static int __init mtk_smi_init(void)
+{
+	int ret;
+
+	ret = platform_driver_register(&mtk_smi_common_driver);
+	if (ret != 0) {
+		pr_err("Failed to register SMI driver\n");
+		return ret;
+	}
+
+	ret = platform_driver_register(&mtk_smi_larb_driver);
+	if (ret != 0) {
+		pr_err("Failed to register SMI-LARB driver\n");
+		goto err_unreg_smi;
+	}
+	return ret;
+
+err_unreg_smi:
+	platform_driver_unregister(&mtk_smi_common_driver);
+	return ret;
+}
+subsys_initcall(mtk_smi_init);
diff --git a/include/soc/mediatek/smi.h b/include/soc/mediatek/smi.h
new file mode 100644
index 0000000..8893c5e
--- /dev/null
+++ b/include/soc/mediatek/smi.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright (c) 2015-2016 MediaTek Inc.
+ * Author: Yong Wu <yong.wu at mediatek.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.
+ */
+#ifndef MTK_IOMMU_SMI_H
+#define MTK_IOMMU_SMI_H
+
+#include <linux/bitops.h>
+#include <linux/device.h>
+
+#ifdef CONFIG_MTK_SMI
+
+#define MTK_LARB_NR_MAX		8
+
+#define MTK_SMI_MMU_EN(port)	BIT(port)
+
+struct mtk_smi_larb_iommu {
+	struct device *dev;
+	unsigned int   mmu;
+};
+
+struct mtk_smi_iommu {
+	unsigned int larb_nr;
+	struct mtk_smi_larb_iommu larb_imu[MTK_LARB_NR_MAX];
+};
+
+/*
+ * mtk_smi_larb_get: Enable the power domain and clocks for this local arbiter.
+ *                   It also initialize some basic setting(like iommu).
+ * mtk_smi_larb_put: Disable the power domain and clocks for this local arbiter.
+ * Both should be called in non-atomic context.
+ *
+ * Returns 0 if successful, negative on failure.
+ */
+int mtk_smi_larb_get(struct device *larbdev);
+void mtk_smi_larb_put(struct device *larbdev);
+
+#else
+
+static inline int mtk_smi_larb_get(struct device *larbdev)
+{
+	return 0;
+}
+
+static inline void mtk_smi_larb_put(struct device *larbdev) { }
+
+#endif
+
+#endif
-- 
1.8.1.1.dirty



From yong.wu at mediatek.com  Mon Feb 22 09:20:50 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 23 Feb 2016 01:20:50 +0800
Subject: [PATCH v10 4/5] iommu/mediatek: Add mt8173 IOMMU driver
In-Reply-To: <1456161651-6136-1-git-send-email-yong.wu@mediatek.com>
References: <1456161651-6136-1-git-send-email-yong.wu@mediatek.com>
Message-ID: <1456161651-6136-5-git-send-email-yong.wu@mediatek.com>

This patch adds support for mediatek m4u (MultiMedia Memory Management
Unit).

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Reviewed-by: Robin Murphy <robin.murphy at arm.com>
---
 drivers/iommu/Kconfig     |  16 +
 drivers/iommu/Makefile    |   1 +
 drivers/iommu/mtk_iommu.c | 737 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 754 insertions(+)
 create mode 100644 drivers/iommu/mtk_iommu.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index a1e75cb..4922aa8 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -318,4 +318,20 @@ config S390_IOMMU
 	help
 	  Support for the IOMMU API for s390 PCI devices.
 
+config MTK_IOMMU
+	bool "MTK IOMMU Support"
+	depends on ARM || ARM64
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	select IOMMU_API
+	select IOMMU_DMA
+	select IOMMU_IO_PGTABLE_ARMV7S
+	select MEMORY
+	select MTK_SMI
+	help
+	  Support for the M4U on certain Mediatek SOCs. M4U is MultiMedia
+	  Memory Management Unit. This option enables remapping of DMA memory
+	  accesses for the multimedia subsystem.
+
+	  If unsure, say N here.
+
 endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 42fc0c2..44ae2e0 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_INTEL_IOMMU) += intel-iommu.o
 obj-$(CONFIG_INTEL_IOMMU_SVM) += intel-svm.o
 obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
 obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
+obj-$(CONFIG_MTK_IOMMU) += mtk_iommu.o
 obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
 obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
 obj-$(CONFIG_ROCKCHIP_IOMMU) += rockchip-iommu.o
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
new file mode 100644
index 0000000..721ffdb
--- /dev/null
+++ b/drivers/iommu/mtk_iommu.c
@@ -0,0 +1,737 @@
+/*
+ * Copyright (c) 2015-2016 MediaTek Inc.
+ * Author: Yong Wu <yong.wu at mediatek.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.
+ */
+#include <linux/bug.h>
+#include <linux/clk.h>
+#include <linux/component.h>
+#include <linux/device.h>
+#include <linux/dma-iommu.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iommu.h>
+#include <linux/iopoll.h>
+#include <linux/list.h>
+#include <linux/of_address.h>
+#include <linux/of_iommu.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <asm/barrier.h>
+#include <dt-bindings/memory/mt8173-larb-port.h>
+#include <soc/mediatek/smi.h>
+
+#include "io-pgtable.h"
+
+#define REG_MMU_PT_BASE_ADDR			0x000
+
+#define REG_MMU_INVALIDATE			0x020
+#define F_ALL_INVLD				0x2
+#define F_MMU_INV_RANGE				0x1
+
+#define REG_MMU_INVLD_START_A			0x024
+#define REG_MMU_INVLD_END_A			0x028
+
+#define REG_MMU_INV_SEL				0x038
+#define F_INVLD_EN0				BIT(0)
+#define F_INVLD_EN1				BIT(1)
+
+#define REG_MMU_STANDARD_AXI_MODE		0x048
+#define REG_MMU_DCM_DIS				0x050
+
+#define REG_MMU_CTRL_REG			0x110
+#define F_MMU_PREFETCH_RT_REPLACE_MOD		BIT(4)
+#define F_MMU_TF_PROTECT_SEL(prot)		(((prot) & 0x3) << 5)
+
+#define REG_MMU_IVRP_PADDR			0x114
+#define F_MMU_IVRP_PA_SET(pa)			((pa) >> 1)
+
+#define REG_MMU_INT_CONTROL0			0x120
+#define F_L2_MULIT_HIT_EN			BIT(0)
+#define F_TABLE_WALK_FAULT_INT_EN		BIT(1)
+#define F_PREETCH_FIFO_OVERFLOW_INT_EN		BIT(2)
+#define F_MISS_FIFO_OVERFLOW_INT_EN		BIT(3)
+#define F_PREFETCH_FIFO_ERR_INT_EN		BIT(5)
+#define F_MISS_FIFO_ERR_INT_EN			BIT(6)
+#define F_INT_CLR_BIT				BIT(12)
+
+#define REG_MMU_INT_MAIN_CONTROL		0x124
+#define F_INT_TRANSLATION_FAULT			BIT(0)
+#define F_INT_MAIN_MULTI_HIT_FAULT		BIT(1)
+#define F_INT_INVALID_PA_FAULT			BIT(2)
+#define F_INT_ENTRY_REPLACEMENT_FAULT		BIT(3)
+#define F_INT_TLB_MISS_FAULT			BIT(4)
+#define F_INT_MISS_TRANSACTION_FIFO_FAULT	BIT(5)
+#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT	BIT(6)
+
+#define REG_MMU_CPE_DONE			0x12C
+
+#define REG_MMU_FAULT_ST1			0x134
+
+#define REG_MMU_FAULT_VA			0x13c
+#define F_MMU_FAULT_VA_MSK			0xfffff000
+#define F_MMU_FAULT_VA_WRITE_BIT		BIT(1)
+#define F_MMU_FAULT_VA_LAYER_BIT		BIT(0)
+
+#define REG_MMU_INVLD_PA			0x140
+#define REG_MMU_INT_ID				0x150
+#define F_MMU0_INT_ID_LARB_ID(a)		(((a) >> 7) & 0x7)
+#define F_MMU0_INT_ID_PORT_ID(a)		(((a) >> 2) & 0x1f)
+
+#define MTK_PROTECT_PA_ALIGN			128
+
+struct mtk_iommu_suspend_reg {
+	u32				standard_axi_mode;
+	u32				dcm_dis;
+	u32				ctrl_reg;
+	u32				int_control0;
+	u32				int_main_control;
+};
+
+struct mtk_iommu_client_priv {
+	struct list_head		client;
+	unsigned int			mtk_m4u_id;
+	struct device			*m4udev;
+};
+
+struct mtk_iommu_domain {
+	spinlock_t			pgtlock; /* lock for page table */
+
+	struct io_pgtable_cfg		cfg;
+	struct io_pgtable_ops		*iop;
+
+	struct iommu_domain		domain;
+};
+
+struct mtk_iommu_data {
+	void __iomem			*base;
+	int				irq;
+	struct device			*dev;
+	struct clk			*bclk;
+	phys_addr_t			protect_base; /* protect memory base */
+	struct mtk_iommu_suspend_reg	reg;
+	struct mtk_iommu_domain		*m4u_dom;
+	struct iommu_group		*m4u_group;
+	struct mtk_smi_iommu		smi_imu;      /* SMI larb iommu info */
+};
+
+static struct iommu_ops mtk_iommu_ops;
+
+static struct mtk_iommu_domain *to_mtk_domain(struct iommu_domain *dom)
+{
+	return container_of(dom, struct mtk_iommu_domain, domain);
+}
+
+static void mtk_iommu_tlb_flush_all(void *cookie)
+{
+	struct mtk_iommu_data *data = cookie;
+
+	writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0, data->base + REG_MMU_INV_SEL);
+	writel_relaxed(F_ALL_INVLD, data->base + REG_MMU_INVALIDATE);
+	wmb(); /* Make sure the tlb flush all done */
+}
+
+static void mtk_iommu_tlb_add_flush_nosync(unsigned long iova, size_t size,
+					   size_t granule, bool leaf,
+					   void *cookie)
+{
+	struct mtk_iommu_data *data = cookie;
+
+	writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0, data->base + REG_MMU_INV_SEL);
+
+	writel_relaxed(iova, data->base + REG_MMU_INVLD_START_A);
+	writel_relaxed(iova + size - 1, data->base + REG_MMU_INVLD_END_A);
+	writel_relaxed(F_MMU_INV_RANGE, data->base + REG_MMU_INVALIDATE);
+}
+
+static void mtk_iommu_tlb_sync(void *cookie)
+{
+	struct mtk_iommu_data *data = cookie;
+	int ret;
+	u32 tmp;
+
+	ret = readl_poll_timeout_atomic(data->base + REG_MMU_CPE_DONE, tmp,
+					tmp != 0, 10, 100000);
+	if (ret) {
+		dev_warn(data->dev,
+			 "Partial TLB flush timed out, falling back to full flush\n");
+		mtk_iommu_tlb_flush_all(cookie);
+	}
+	/* Clear the CPE status */
+	writel_relaxed(0, data->base + REG_MMU_CPE_DONE);
+}
+
+static const struct iommu_gather_ops mtk_iommu_gather_ops = {
+	.tlb_flush_all = mtk_iommu_tlb_flush_all,
+	.tlb_add_flush = mtk_iommu_tlb_add_flush_nosync,
+	.tlb_sync = mtk_iommu_tlb_sync,
+};
+
+static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
+{
+	struct mtk_iommu_data *data = dev_id;
+	struct mtk_iommu_domain *dom = data->m4u_dom;
+	u32 int_state, regval, fault_iova, fault_pa;
+	unsigned int fault_larb, fault_port;
+	bool layer, write;
+
+	/* Read error info from registers */
+	int_state = readl_relaxed(data->base + REG_MMU_FAULT_ST1);
+	fault_iova = readl_relaxed(data->base + REG_MMU_FAULT_VA);
+	layer = fault_iova & F_MMU_FAULT_VA_LAYER_BIT;
+	write = fault_iova & F_MMU_FAULT_VA_WRITE_BIT;
+	fault_iova &= F_MMU_FAULT_VA_MSK;
+	fault_pa = readl_relaxed(data->base + REG_MMU_INVLD_PA);
+	regval = readl_relaxed(data->base + REG_MMU_INT_ID);
+	fault_larb = F_MMU0_INT_ID_LARB_ID(regval);
+	fault_port = F_MMU0_INT_ID_PORT_ID(regval);
+
+	if (report_iommu_fault(&dom->domain, data->dev, fault_iova,
+			       write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) {
+		dev_err_ratelimited(
+			data->dev,
+			"fault type=0x%x iova=0x%x pa=0x%x larb=%d port=%d layer=%d %s\n",
+			int_state, fault_iova, fault_pa, fault_larb, fault_port,
+			layer, write ? "write" : "read");
+	}
+
+	/* Interrupt clear */
+	regval = readl_relaxed(data->base + REG_MMU_INT_CONTROL0);
+	regval |= F_INT_CLR_BIT;
+	writel_relaxed(regval, data->base + REG_MMU_INT_CONTROL0);
+
+	mtk_iommu_tlb_flush_all(data);
+
+	return IRQ_HANDLED;
+}
+
+static void mtk_iommu_config(struct mtk_iommu_data *data,
+			     struct device *dev, bool enable)
+{
+	struct mtk_iommu_client_priv *head, *cur, *next;
+	struct mtk_smi_larb_iommu    *larb_mmu;
+	unsigned int                 larbid, portid;
+
+	head = dev->archdata.iommu;
+	list_for_each_entry_safe(cur, next, &head->client, client) {
+		larbid = MTK_M4U_TO_LARB(cur->mtk_m4u_id);
+		portid = MTK_M4U_TO_PORT(cur->mtk_m4u_id);
+		larb_mmu = &data->smi_imu.larb_imu[larbid];
+
+		dev_dbg(dev, "%s iommu port: %d\n",
+			enable ? "enable" : "disable", portid);
+
+		if (enable)
+			larb_mmu->mmu |= MTK_SMI_MMU_EN(portid);
+		else
+			larb_mmu->mmu &= ~MTK_SMI_MMU_EN(portid);
+	}
+}
+
+static int mtk_iommu_domain_finalise(struct mtk_iommu_data *data)
+{
+	struct mtk_iommu_domain *dom = data->m4u_dom;
+
+	spin_lock_init(&dom->pgtlock);
+
+	dom->cfg = (struct io_pgtable_cfg) {
+		.quirks = IO_PGTABLE_QUIRK_ARM_NS |
+			IO_PGTABLE_QUIRK_NO_PERMS |
+			IO_PGTABLE_QUIRK_TLBI_ON_MAP,
+		.pgsize_bitmap = mtk_iommu_ops.pgsize_bitmap,
+		.ias = 32,
+		.oas = 32,
+		.tlb = &mtk_iommu_gather_ops,
+		.iommu_dev = data->dev,
+	};
+
+	dom->iop = alloc_io_pgtable_ops(ARM_V7S, &dom->cfg, data);
+	if (!dom->iop) {
+		dev_err(data->dev, "Failed to alloc io pgtable\n");
+		return -EINVAL;
+	}
+
+	/* Update our support page sizes bitmap */
+	mtk_iommu_ops.pgsize_bitmap = dom->cfg.pgsize_bitmap;
+
+	writel(data->m4u_dom->cfg.arm_v7s_cfg.ttbr[0],
+	       data->base + REG_MMU_PT_BASE_ADDR);
+	return 0;
+}
+
+static struct iommu_domain *mtk_iommu_domain_alloc(unsigned type)
+{
+	struct mtk_iommu_domain *dom;
+
+	if (type != IOMMU_DOMAIN_DMA)
+		return NULL;
+
+	dom = kzalloc(sizeof(*dom), GFP_KERNEL);
+	if (!dom)
+		return NULL;
+
+	if (iommu_get_dma_cookie(&dom->domain)) {
+		kfree(dom);
+		return NULL;
+	}
+
+	dom->domain.geometry.aperture_start = 0;
+	dom->domain.geometry.aperture_end = DMA_BIT_MASK(32);
+	dom->domain.geometry.force_aperture = true;
+
+	return &dom->domain;
+}
+
+static void mtk_iommu_domain_free(struct iommu_domain *domain)
+{
+	iommu_put_dma_cookie(domain);
+	kfree(to_mtk_domain(domain));
+}
+
+static int mtk_iommu_attach_device(struct iommu_domain *domain,
+				   struct device *dev)
+{
+	struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+	struct mtk_iommu_client_priv *priv = dev->archdata.iommu;
+	struct mtk_iommu_data *data;
+	int ret;
+
+	if (!priv)
+		return -ENODEV;
+
+	data = dev_get_drvdata(priv->m4udev);
+	if (!data->m4u_dom) {
+		data->m4u_dom = dom;
+		ret = mtk_iommu_domain_finalise(data);
+		if (ret) {
+			data->m4u_dom = NULL;
+			return ret;
+		}
+	} else if (data->m4u_dom != dom) {
+		/* All the client devices should be in the same m4u domain */
+		dev_err(dev, "try to attach into the error iommu domain\n");
+		return -EPERM;
+	}
+
+	mtk_iommu_config(data, dev, true);
+	return 0;
+}
+
+static void mtk_iommu_detach_device(struct iommu_domain *domain,
+				    struct device *dev)
+{
+	struct mtk_iommu_client_priv *priv = dev->archdata.iommu;
+	struct mtk_iommu_data *data;
+
+	if (!priv)
+		return;
+
+	data = dev_get_drvdata(priv->m4udev);
+	mtk_iommu_config(data, dev, false);
+}
+
+static int mtk_iommu_map(struct iommu_domain *domain, unsigned long iova,
+			 phys_addr_t paddr, size_t size, int prot)
+{
+	struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+	unsigned long flags;
+	int ret;
+
+	spin_lock_irqsave(&dom->pgtlock, flags);
+	ret = dom->iop->map(dom->iop, iova, paddr, size, prot);
+	spin_unlock_irqrestore(&dom->pgtlock, flags);
+
+	return ret;
+}
+
+static size_t mtk_iommu_unmap(struct iommu_domain *domain,
+			      unsigned long iova, size_t size)
+{
+	struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+	unsigned long flags;
+	size_t unmapsz;
+
+	spin_lock_irqsave(&dom->pgtlock, flags);
+	unmapsz = dom->iop->unmap(dom->iop, iova, size);
+	spin_unlock_irqrestore(&dom->pgtlock, flags);
+
+	return unmapsz;
+}
+
+static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
+					  dma_addr_t iova)
+{
+	struct mtk_iommu_domain *dom = to_mtk_domain(domain);
+	unsigned long flags;
+	phys_addr_t pa;
+
+	spin_lock_irqsave(&dom->pgtlock, flags);
+	pa = dom->iop->iova_to_phys(dom->iop, iova);
+	spin_unlock_irqrestore(&dom->pgtlock, flags);
+
+	return pa;
+}
+
+static int mtk_iommu_add_device(struct device *dev)
+{
+	struct iommu_group *group;
+
+	if (!dev->archdata.iommu) /* Not a iommu client device */
+		return -ENODEV;
+
+	group = iommu_group_get_for_dev(dev);
+	if (IS_ERR(group))
+		return PTR_ERR(group);
+
+	iommu_group_put(group);
+	return 0;
+}
+
+static void mtk_iommu_remove_device(struct device *dev)
+{
+	struct mtk_iommu_client_priv *head, *cur, *next;
+
+	head = dev->archdata.iommu;
+	if (!head)
+		return;
+
+	list_for_each_entry_safe(cur, next, &head->client, client) {
+		list_del(&cur->client);
+		kfree(cur);
+	}
+	kfree(head);
+	dev->archdata.iommu = NULL;
+
+	iommu_group_remove_device(dev);
+}
+
+static struct iommu_group *mtk_iommu_device_group(struct device *dev)
+{
+	struct mtk_iommu_data *data;
+	struct mtk_iommu_client_priv *priv;
+
+	priv = dev->archdata.iommu;
+	if (!priv)
+		return ERR_PTR(-ENODEV);
+
+	/* All the client devices are in the same m4u iommu-group */
+	data = dev_get_drvdata(priv->m4udev);
+	if (!data->m4u_group) {
+		data->m4u_group = iommu_group_alloc();
+		if (IS_ERR(data->m4u_group))
+			dev_err(dev, "Failed to allocate M4U IOMMU group\n");
+	}
+	return data->m4u_group;
+}
+
+static int mtk_iommu_of_xlate(struct device *dev, struct of_phandle_args *args)
+{
+	struct mtk_iommu_client_priv *head, *priv, *next;
+	struct platform_device *m4updev;
+
+	if (args->args_count != 1) {
+		dev_err(dev, "invalid #iommu-cells(%d) property for IOMMU\n",
+			args->args_count);
+		return -EINVAL;
+	}
+
+	if (!dev->archdata.iommu) {
+		/* Get the m4u device */
+		m4updev = of_find_device_by_node(args->np);
+		of_node_put(args->np);
+		if (WARN_ON(!m4updev))
+			return -EINVAL;
+
+		head = kzalloc(sizeof(*head), GFP_KERNEL);
+		if (!head)
+			return -ENOMEM;
+
+		dev->archdata.iommu = head;
+		INIT_LIST_HEAD(&head->client);
+		head->m4udev = &m4updev->dev;
+	} else {
+		head = dev->archdata.iommu;
+	}
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		goto err_free_mem;
+
+	priv->mtk_m4u_id = args->args[0];
+	list_add_tail(&priv->client, &head->client);
+
+	return 0;
+
+err_free_mem:
+	list_for_each_entry_safe(priv, next, &head->client, client)
+		kfree(priv);
+	kfree(head);
+	dev->archdata.iommu = NULL;
+	return -ENOMEM;
+}
+
+static struct iommu_ops mtk_iommu_ops = {
+	.domain_alloc	= mtk_iommu_domain_alloc,
+	.domain_free	= mtk_iommu_domain_free,
+	.attach_dev	= mtk_iommu_attach_device,
+	.detach_dev	= mtk_iommu_detach_device,
+	.map		= mtk_iommu_map,
+	.unmap		= mtk_iommu_unmap,
+	.map_sg		= default_iommu_map_sg,
+	.iova_to_phys	= mtk_iommu_iova_to_phys,
+	.add_device	= mtk_iommu_add_device,
+	.remove_device	= mtk_iommu_remove_device,
+	.device_group	= mtk_iommu_device_group,
+	.of_xlate	= mtk_iommu_of_xlate,
+	.pgsize_bitmap	= SZ_4K | SZ_64K | SZ_1M | SZ_16M,
+};
+
+static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
+{
+	u32 regval;
+	int ret;
+
+	ret = clk_prepare_enable(data->bclk);
+	if (ret) {
+		dev_err(data->dev, "Failed to enable iommu bclk(%d)\n", ret);
+		return ret;
+	}
+
+	regval = F_MMU_PREFETCH_RT_REPLACE_MOD |
+		F_MMU_TF_PROTECT_SEL(2);
+	writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
+
+	regval = F_L2_MULIT_HIT_EN |
+		F_TABLE_WALK_FAULT_INT_EN |
+		F_PREETCH_FIFO_OVERFLOW_INT_EN |
+		F_MISS_FIFO_OVERFLOW_INT_EN |
+		F_PREFETCH_FIFO_ERR_INT_EN |
+		F_MISS_FIFO_ERR_INT_EN;
+	writel_relaxed(regval, data->base + REG_MMU_INT_CONTROL0);
+
+	regval = F_INT_TRANSLATION_FAULT |
+		F_INT_MAIN_MULTI_HIT_FAULT |
+		F_INT_INVALID_PA_FAULT |
+		F_INT_ENTRY_REPLACEMENT_FAULT |
+		F_INT_TLB_MISS_FAULT |
+		F_INT_MISS_TRANSACTION_FIFO_FAULT |
+		F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
+	writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
+
+	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base),
+		       data->base + REG_MMU_IVRP_PADDR);
+
+	writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
+	writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
+
+	if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
+			     dev_name(data->dev), (void *)data)) {
+		writel_relaxed(0, data->base + REG_MMU_PT_BASE_ADDR);
+		clk_disable_unprepare(data->bclk);
+		dev_err(data->dev, "Failed @ IRQ-%d Request\n", data->irq);
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+static int compare_of(struct device *dev, void *data)
+{
+	return dev->of_node == data;
+}
+
+static int mtk_iommu_bind(struct device *dev)
+{
+	struct mtk_iommu_data *data = dev_get_drvdata(dev);
+
+	return component_bind_all(dev, &data->smi_imu);
+}
+
+static void mtk_iommu_unbind(struct device *dev)
+{
+	struct mtk_iommu_data *data = dev_get_drvdata(dev);
+
+	component_unbind_all(dev, &data->smi_imu);
+}
+
+static const struct component_master_ops mtk_iommu_com_ops = {
+	.bind		= mtk_iommu_bind,
+	.unbind		= mtk_iommu_unbind,
+};
+
+static int mtk_iommu_probe(struct platform_device *pdev)
+{
+	struct mtk_iommu_data   *data;
+	struct device           *dev = &pdev->dev;
+	struct resource         *res;
+	struct component_match  *match = NULL;
+	void                    *protect;
+	unsigned int            i, larb_nr;
+	int                     ret;
+
+	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+	data->dev = dev;
+
+	/* Protect memory. HW will access here while translation fault.*/
+	protect = devm_kzalloc(dev, MTK_PROTECT_PA_ALIGN * 2, GFP_KERNEL);
+	if (!protect)
+		return -ENOMEM;
+	data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	data->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(data->base))
+		return PTR_ERR(data->base);
+
+	data->irq = platform_get_irq(pdev, 0);
+	if (data->irq < 0)
+		return data->irq;
+
+	data->bclk = devm_clk_get(dev, "bclk");
+	if (IS_ERR(data->bclk))
+		return PTR_ERR(data->bclk);
+
+	larb_nr = of_count_phandle_with_args(dev->of_node,
+					     "mediatek,larbs", NULL);
+	if (larb_nr < 0)
+		return larb_nr;
+	data->smi_imu.larb_nr = larb_nr;
+
+	for (i = 0; i < larb_nr; i++) {
+		struct device_node *larbnode;
+		struct platform_device *plarbdev;
+
+		larbnode = of_parse_phandle(dev->of_node, "mediatek,larbs", i);
+		if (!larbnode)
+			return -EINVAL;
+
+		if (!of_device_is_available(larbnode))
+			continue;
+
+		plarbdev = of_find_device_by_node(larbnode);
+		of_node_put(larbnode);
+		if (!plarbdev) {
+			plarbdev = of_platform_device_create(
+						larbnode, NULL,
+						platform_bus_type.dev_root);
+			if (IS_ERR(plarbdev))
+				return -EPROBE_DEFER;
+		}
+		data->smi_imu.larb_imu[i].dev = &plarbdev->dev;
+
+		component_match_add(dev, &match, compare_of, larbnode);
+	}
+
+	platform_set_drvdata(pdev, data);
+
+	ret = mtk_iommu_hw_init(data);
+	if (ret)
+		return ret;
+
+	if (!iommu_present(&platform_bus_type))
+		bus_set_iommu(&platform_bus_type, &mtk_iommu_ops);
+
+	return component_master_add_with_match(dev, &mtk_iommu_com_ops, match);
+}
+
+static int mtk_iommu_remove(struct platform_device *pdev)
+{
+	struct mtk_iommu_data *data = platform_get_drvdata(pdev);
+
+	if (iommu_present(&platform_bus_type))
+		bus_set_iommu(&platform_bus_type, NULL);
+
+	free_io_pgtable_ops(data->m4u_dom->iop);
+	clk_disable_unprepare(data->bclk);
+	devm_free_irq(&pdev->dev, data->irq, data);
+	component_master_del(&pdev->dev, &mtk_iommu_com_ops);
+	return 0;
+}
+
+static int mtk_iommu_suspend(struct device *dev)
+{
+	struct mtk_iommu_data *data = dev_get_drvdata(dev);
+	struct mtk_iommu_suspend_reg *reg = &data->reg;
+	void __iomem *base = data->base;
+
+	reg->standard_axi_mode = readl_relaxed(base +
+					       REG_MMU_STANDARD_AXI_MODE);
+	reg->dcm_dis = readl_relaxed(base + REG_MMU_DCM_DIS);
+	reg->ctrl_reg = readl_relaxed(base + REG_MMU_CTRL_REG);
+	reg->int_control0 = readl_relaxed(base + REG_MMU_INT_CONTROL0);
+	reg->int_main_control = readl_relaxed(base + REG_MMU_INT_MAIN_CONTROL);
+	return 0;
+}
+
+static int mtk_iommu_resume(struct device *dev)
+{
+	struct mtk_iommu_data *data = dev_get_drvdata(dev);
+	struct mtk_iommu_suspend_reg *reg = &data->reg;
+	void __iomem *base = data->base;
+
+	writel_relaxed(data->m4u_dom->cfg.arm_v7s_cfg.ttbr[0],
+		       base + REG_MMU_PT_BASE_ADDR);
+	writel_relaxed(reg->standard_axi_mode,
+		       base + REG_MMU_STANDARD_AXI_MODE);
+	writel_relaxed(reg->dcm_dis, base + REG_MMU_DCM_DIS);
+	writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
+	writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
+	writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
+	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base),
+		       base + REG_MMU_IVRP_PADDR);
+	return 0;
+}
+
+const struct dev_pm_ops mtk_iommu_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(mtk_iommu_suspend, mtk_iommu_resume)
+};
+
+static const struct of_device_id mtk_iommu_of_ids[] = {
+	{ .compatible = "mediatek,mt8173-m4u", },
+	{}
+};
+
+static struct platform_driver mtk_iommu_driver = {
+	.probe	= mtk_iommu_probe,
+	.remove	= mtk_iommu_remove,
+	.driver	= {
+		.name = "mtk-iommu",
+		.of_match_table = mtk_iommu_of_ids,
+		.pm = &mtk_iommu_pm_ops,
+	}
+};
+
+static int mtk_iommu_init_fn(struct device_node *np)
+{
+	int ret;
+	struct platform_device *pdev;
+
+	pdev = of_platform_device_create(np, NULL, platform_bus_type.dev_root);
+	if (IS_ERR(pdev))
+		return PTR_ERR(pdev);
+
+	ret = platform_driver_register(&mtk_iommu_driver);
+	if (ret) {
+		pr_err("%s: Failed to register driver\n", __func__);
+		return ret;
+	}
+
+	of_iommu_set_ops(np, &mtk_iommu_ops);
+	return 0;
+}
+
+IOMMU_OF_DECLARE(mtkm4u, "mediatek,mt8173-m4u", mtk_iommu_init_fn);
-- 
1.8.1.1.dirty



From yong.wu at mediatek.com  Mon Feb 22 09:20:51 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Tue, 23 Feb 2016 01:20:51 +0800
Subject: [PATCH v10 5/5] dts: mt8173: Add iommu/smi nodes for mt8173
In-Reply-To: <1456161651-6136-1-git-send-email-yong.wu@mediatek.com>
References: <1456161651-6136-1-git-send-email-yong.wu@mediatek.com>
Message-ID: <1456161651-6136-6-git-send-email-yong.wu@mediatek.com>

This patch add the iommu/larbs nodes for mt8173

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
Reviewed-by: Daniel Kurtz <djkurtz at chromium.org>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 81 ++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index ec135ea..8048811 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -14,6 +14,7 @@
 #include <dt-bindings/clock/mt8173-clk.h>
 #include <dt-bindings/interrupt-controller/irq.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/memory/mt8173-larb-port.h>
 #include <dt-bindings/phy/phy.h>
 #include <dt-bindings/power/mt8173-power.h>
 #include <dt-bindings/reset/mt8173-resets.h>
@@ -277,6 +278,17 @@
 			reg = <0 0x10200620 0 0x20>;
 		};
 
+		iommu: iommu at 10205000 {
+			compatible = "mediatek,mt8173-m4u";
+			reg = <0 0x10205000 0 0x1000>;
+			interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>;
+			clocks = <&infracfg CLK_INFRA_M4U>;
+			clock-names = "bclk";
+			mediatek,larbs = <&larb0 &larb1 &larb2
+					  &larb3 &larb4 &larb5>;
+			#iommu-cells = <1>;
+		};
+
 		apmixedsys: clock-controller at 10209000 {
 			compatible = "mediatek,mt8173-apmixedsys";
 			reg = <0 0x10209000 0 0x1000>;
@@ -589,29 +601,98 @@
 			status = "disabled";
 		};
 
+		larb0: larb at 14021000 {
+			compatible = "mediatek,mt8173-smi-larb";
+			reg = <0 0x14021000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_SMI_LARB0>,
+				 <&mmsys CLK_MM_SMI_LARB0>;
+			clock-names = "apb", "smi";
+		};
+
+		smi_common: smi at 14022000 {
+			compatible = "mediatek,mt8173-smi-common";
+			reg = <0 0x14022000 0 0x1000>;
+			power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_SMI_COMMON>,
+				 <&mmsys CLK_MM_SMI_COMMON>;
+			clock-names = "apb", "smi";
+		};
+
+		larb4: larb at 14027000 {
+			compatible = "mediatek,mt8173-smi-larb";
+			reg = <0 0x14027000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+			clocks = <&mmsys CLK_MM_SMI_LARB4>,
+				 <&mmsys CLK_MM_SMI_LARB4>;
+			clock-names = "apb", "smi";
+		};
+
 		imgsys: clock-controller at 15000000 {
 			compatible = "mediatek,mt8173-imgsys", "syscon";
 			reg = <0 0x15000000 0 0x1000>;
 			#clock-cells = <1>;
 		};
 
+		larb2: larb at 15001000 {
+			compatible = "mediatek,mt8173-smi-larb";
+			reg = <0 0x15001000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			power-domains = <&scpsys MT8173_POWER_DOMAIN_ISP>;
+			clocks = <&imgsys CLK_IMG_LARB2_SMI>,
+				 <&imgsys CLK_IMG_LARB2_SMI>;
+			clock-names = "apb", "smi";
+		};
+
 		vdecsys: clock-controller at 16000000 {
 			compatible = "mediatek,mt8173-vdecsys", "syscon";
 			reg = <0 0x16000000 0 0x1000>;
 			#clock-cells = <1>;
 		};
 
+		larb1: larb at 16010000 {
+			compatible = "mediatek,mt8173-smi-larb";
+			reg = <0 0x16010000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
+			clocks = <&vdecsys CLK_VDEC_CKEN>,
+				 <&vdecsys CLK_VDEC_LARB_CKEN>;
+			clock-names = "apb", "smi";
+		};
+
 		vencsys: clock-controller at 18000000 {
 			compatible = "mediatek,mt8173-vencsys", "syscon";
 			reg = <0 0x18000000 0 0x1000>;
 			#clock-cells = <1>;
 		};
 
+		larb3: larb at 18001000 {
+			compatible = "mediatek,mt8173-smi-larb";
+			reg = <0 0x18001000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			power-domains = <&scpsys MT8173_POWER_DOMAIN_VENC>;
+			clocks = <&vencsys CLK_VENC_CKE1>,
+				 <&vencsys CLK_VENC_CKE0>;
+			clock-names = "apb", "smi";
+		};
+
 		vencltsys: clock-controller at 19000000 {
 			compatible = "mediatek,mt8173-vencltsys", "syscon";
 			reg = <0 0x19000000 0 0x1000>;
 			#clock-cells = <1>;
 		};
+
+		larb5: larb at 19001000 {
+			compatible = "mediatek,mt8173-smi-larb";
+			reg = <0 0x19001000 0 0x1000>;
+			mediatek,smi = <&smi_common>;
+			power-domains = <&scpsys MT8173_POWER_DOMAIN_VENC_LT>;
+			clocks = <&vencltsys CLK_VENCLT_CKE1>,
+				 <&vencltsys CLK_VENCLT_CKE0>;
+			clock-names = "apb", "smi";
+		};
 	};
 };
 
-- 
1.8.1.1.dirty



From sugar.zhang at rock-chips.com  Mon Feb 22 17:19:22 2016
From: sugar.zhang at rock-chips.com (Sugar Zhang)
Date: Tue, 23 Feb 2016 09:19:22 +0800
Subject: [PATCH] ASoC: rockchip: i2s: add default values for registers
Message-ID: <1456190362-15653-1-git-send-email-sugar.zhang@rock-chips.com>

this patch add default values for registers according description from TRM.

Signed-off-by: Sugar Zhang <sugar.zhang at rock-chips.com>
---

 sound/soc/rockchip/rockchip_i2s.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/sound/soc/rockchip/rockchip_i2s.c b/sound/soc/rockchip/rockchip_i2s.c
index 6561c4c..a0b0942 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -440,11 +440,21 @@ static bool rockchip_i2s_precious_reg(struct device *dev, unsigned int reg)
 	}
 }
 
+static const struct reg_default rockchip_i2s_reg_defaults[] = {
+	{0x00, 0x0000000f},
+	{0x04, 0x0000000f},
+	{0x08, 0x00071f1f},
+	{0x10, 0x001f0000},
+	{0x14, 0x01f00000},
+};
+
 static const struct regmap_config rockchip_i2s_regmap_config = {
 	.reg_bits = 32,
 	.reg_stride = 4,
 	.val_bits = 32,
 	.max_register = I2S_RXDR,
+	.reg_defaults = rockchip_i2s_reg_defaults,
+	.num_reg_defaults = ARRAY_SIZE(rockchip_i2s_reg_defaults),
 	.writeable_reg = rockchip_i2s_wr_reg,
 	.readable_reg = rockchip_i2s_rd_reg,
 	.volatile_reg = rockchip_i2s_volatile_reg,
-- 
1.9.1




From xuejiancheng at huawei.com  Mon Feb 22 17:25:01 2016
From: xuejiancheng at huawei.com (xuejiancheng)
Date: Tue, 23 Feb 2016 09:25:01 +0800
Subject: [PATCH v9 2/6] clk: hisilicon: add CRG driver for hi3519 soc
In-Reply-To: <201602221742.MKAlpbcd%fengguang.wu@intel.com>
References: <201602221742.MKAlpbcd%fengguang.wu@intel.com>
Message-ID: <56CBB4ED.304@huawei.com>

Hi all,

I'll fix this warning in next version.

Other comments will be appreciated!

Thank you!

On 2016/2/22 18:01, kbuild test robot wrote:
> Hi Jiancheng,
> 
> [auto build test WARNING on clk/clk-next]
> [also build test WARNING on v4.5-rc5 next-20160222]
> [if your patch is applied to the wrong git tree, please drop us a note to help improving the system]
> 
> url:    https://github.com/0day-ci/linux/commits/Jiancheng-Xue/ARM-hisi-Add-initial-support-including-clock-driver-for-Hi3519-soc/20160222-160736
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
> config: xtensa-allyesconfig (attached as .config)
> reproduce:
>         wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         make.cross ARCH=xtensa 
> 
> All warnings (new ones prefixed by >>):
> 
> warning: (COMMON_CLK_HI3519) selects RESET_HISI which has unmet direct dependencies (COMMON_CLK && ARCH_HISI)
> 
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
> 



From zhaoshenglong at huawei.com  Mon Feb 22 17:46:46 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Tue, 23 Feb 2016 09:46:46 +0800
Subject: [PATCH v12 03/21] KVM: ARM64: Add offset defines for PMU registers
In-Reply-To: <56CB4A98.2020403@arm.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
 <1456133877-9584-4-git-send-email-zhaoshenglong@huawei.com>
 <56CB4A98.2020403@arm.com>
Message-ID: <56CBBA06.4040902@huawei.com>



On 2016/2/23 1:51, Marc Zyngier wrote:
> On 22/02/16 09:37, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao at linaro.org>
>>
>> We are about to trap and emulate accesses to each PMU register
>> individually. This adds the context offsets for the AArch64 PMU
>> registers.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
>> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
>> Reviewed-by: Andrew Jones <drjones at redhat.com>
>> ---
>>  arch/arm64/include/asm/kvm_host.h | 15 +++++++++++++++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 6f0241f..6bab7fb 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -115,6 +115,21 @@ enum vcpu_sysreg {
>>  	MDSCR_EL1,	/* Monitor Debug System Control Register */
>>  	MDCCINT_EL1,	/* Monitor Debug Comms Channel Interrupt Enable Reg */
>>  
>> +	/* Performance Monitors Registers */
>> +	PMCR_EL0,	/* Control Register */
>> +	PMOVSSET_EL0,	/* Overflow Flag Status Set Register */
>> +	PMSELR_EL0,	/* Event Counter Selection Register */
>> +	PMEVCNTR0_EL0,	/* Event Counter Register (0-30) */
>> +	PMEVCNTR30_EL0 = PMEVCNTR0_EL0 + 30,
>> +	PMCCNTR_EL0,	/* Cycle Counter Register */
>> +	PMEVTYPER0_EL0,	/* Event Type Register (0-30) */
>> +	PMEVTYPER30_EL0 = PMEVTYPER0_EL0 + 30,
>> +	PMCCFILTR_EL0,	/* Cycle Count Filter Register */
>> +	PMCNTENSET_EL0,	/* Count Enable Set Register */
>> +	PMINTENSET_EL1,	/* Interrupt Enable Set Register */
>> +	PMUSERENR_EL0,	/* User Enable Register */
>> +	PMSWINC_EL0,	/* Software Increment Register */
>> +
> 
> I've just noticed a rather fundamental issue with this: this makes it
> impossible to bisect the whole series.
> 
Ah, sorry. Will fix this.

> I was trying to pinpoint a performance regression with this series, and
> started bisecting.
You mean this series introduce a performance regression? Is there any
method to measure that? Then I can have a look too.

> Unfortunately, declaring these registers in one go
> means that we end-up with uninitialized registers after this patch (and
> probably until PMUSERENR is dealt with). The consequence of that is
> something like this:
> 
> Kernel panic - not syncing: Didn't reset vcpu_sys_reg(25)
> CPU: 1 PID: 1994 Comm: lkvm Tainted: G        W       4.5.0-rc5+ #5563
> Hardware name: Default string Default string/Default string, BIOS
> ROD0084E 09/03/2015
> Call trace:
> [<ffffffc000089a20>] dump_backtrace+0x0/0x1a8
> [<ffffffc000089bdc>] show_stack+0x14/0x20
> [<ffffffc00033490c>] dump_stack+0x94/0xb8
> [<ffffffc00014ddbc>] panic+0x10c/0x250
> [<ffffffc0000a9c94>] kvm_reset_sys_regs+0xec/0xf0
> [<ffffffc0000a7878>] kvm_reset_vcpu+0x58/0x80
> [<ffffffc0000a2c44>] kvm_arch_vcpu_ioctl+0x294/0x310
> [<ffffffc00009d6b4>] kvm_vcpu_ioctl+0xcc/0x698
> [<ffffffc0001cb184>] do_vfs_ioctl+0xa4/0x750
> [<ffffffc0001cb8bc>] SyS_ioctl+0x8c/0xa0
> [<ffffffc000085d30>] el0_svc_naked+0x24/0x28
> 
> The obvious fix would be to introduce each register with the patch that
> handles it. At least, we'll be able to bisect it...
> 
> Thanks,
> 
> 	M.
> 

Thanks,
-- 
Shannon



From ddaney.cavm at gmail.com  Mon Feb 22 17:58:18 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Mon, 22 Feb 2016 17:58:18 -0800
Subject: [PATCH v12 0/5] arm64, numa: Add numa support for arm64 platforms
Message-ID: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>

From: David Daney <david.daney at cavium.com>

v12:

	- Replaced 6 patches from Ard Biesheuvel with new simpler, and
          more correct, single patch, also from Ard.

v11:
	- Dropped cleanup patches for other architectures, they will be
          submitted as a separate set after more testing.

	- Added patch set from Ard Biesheuvel that are needed to make
          the whole thing actually work.  Previously this was a
          separate set.

	- Kconfig and other fixes and simplifications as suggested by Rob Herring.

	- Rearranged, refactored and reordered so that we don't patch
          new files multiple times.

	- Summary:

		o 6 patches from Ard Biesheuvel to allow use of
		  "memory" nodes with efi stub.

		o 2 patches to document and add of_numa.c

		o 1 patch to add arm64 NUMA support.

		o 1 patch to add NUMA balancing support for arm64.

v10:
	- Incorporated review comments from Rob Herring.
	- Moved numa binding and implementation to devicetree core.
	- Added cleanup patch to remove redundant NODE_DATA macro from asm header files
	- Include numa balancing support for arm64 patch in this series.
	- Fix tile build issue reported by the kbuild robot(patch 7)

v9:	- Added cleanup patch to reuse and avoid redefinition of cpumask_of_pcibus
	  as suggested from Will Deacon and Bjorn Helgaas.
	  - Including patch to Make pci-host-generic driver numa aware.
	  - Incorporated comment from Shannon Zhao.

v8:
	- Incorporated review comments of Mark Rutland and Will Deacon.
	- Added pci helper function and macro for numa.

v7:
	- managing numa memory mapping using memblock.
	- Incorporated review comments of Mark Rutland.

v6:
	- defined and implemented the numa dt binding using
	node property proximity and device node distance-map.
	- renamed dt_numa to of_numa

v5:
        - created base verion of numa.c which creates dummy numa without using dt
          on single socket platforms. Then added patches for dt support.
        - Incorporated review comments from Hanjun Guo.

v4:
done changes as per Arnd review comments.

v3:
Added changes to support numa on arm64 based platforms.
Tested these patches on cavium's multinode(2 node topology) platform.
In this patchset, defined and implemented dt bindings for numa mapping
for core and memory using device node property arm,associativity.

v2:
Defined and implemented numa map for memory, cores to node and
proximity distance matrix of nodes.

v1:
Initial patchset to support numa on arm64 platforms.

Note: 1. This patchset is tested for NUMA and without NUMA with dt
        (both with and without NUMA bindings) on thunderx single
        socket and dual socket boards.


Ard Biesheuvel (1):
  efi: ARM/arm64: ignore DT memory nodes instead of removing them

Ganapatrao Kulkarni (4):
  Documentation, dt, numa: dt bindings for NUMA.
  dt, numa: Add NUMA dt binding implementation.
  arm64, numa: Add NUMA support for arm64 platforms.
  arm64, mm, numa: Add NUMA balancing support for arm64.

 Documentation/devicetree/bindings/numa.txt | 272 +++++++++++++++++++
 arch/arm64/Kconfig                         |  27 ++
 arch/arm64/include/asm/mmzone.h            |  12 +
 arch/arm64/include/asm/numa.h              |  45 ++++
 arch/arm64/include/asm/pgtable.h           |  15 ++
 arch/arm64/include/asm/topology.h          |  10 +
 arch/arm64/kernel/pci.c                    |  10 +
 arch/arm64/kernel/setup.c                  |   4 +
 arch/arm64/kernel/smp.c                    |   4 +
 arch/arm64/mm/Makefile                     |   1 +
 arch/arm64/mm/init.c                       |  34 ++-
 arch/arm64/mm/mmu.c                        |   1 +
 arch/arm64/mm/numa.c                       | 403 +++++++++++++++++++++++++++++
 drivers/firmware/efi/arm-init.c            |   8 +
 drivers/firmware/efi/libstub/fdt.c         |  24 +-
 drivers/of/Kconfig                         |   3 +
 drivers/of/Makefile                        |   1 +
 drivers/of/of_numa.c                       | 211 +++++++++++++++
 include/linux/of.h                         |   9 +
 19 files changed, 1066 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/numa.txt
 create mode 100644 arch/arm64/include/asm/mmzone.h
 create mode 100644 arch/arm64/include/asm/numa.h
 create mode 100644 arch/arm64/mm/numa.c
 create mode 100644 drivers/of/of_numa.c

-- 
1.8.3.1



From ddaney.cavm at gmail.com  Mon Feb 22 17:58:19 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Mon, 22 Feb 2016 17:58:19 -0800
Subject: [PATCH v12 1/5] efi: ARM/arm64: ignore DT memory nodes instead of
 removing them
In-Reply-To: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1456192703-2274-2-git-send-email-ddaney.cavm@gmail.com>

From: Ard Biesheuvel <ard.biesheuvel at linaro.org>

There are two problems with the UEFI stub DT memory node removal
routine:
- it deletes nodes as it traverses the tree, which happens to work
  but is not supported, as deletion invalidates the node iterator;
- deleting memory nodes entirely may discard annotations in the form
  of additional properties on the nodes.

Since the discovery of DT memory nodes occurs strictly before the
UEFI init sequence, we can simply clear the memblock memory table
before parsing the UEFI memory map. This way, it is no longer
necessary to remove the nodes, so we can remove that logic from the
stub as well.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 drivers/firmware/efi/arm-init.c    |  8 ++++++++
 drivers/firmware/efi/libstub/fdt.c | 24 +-----------------------
 2 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 9e15d57..40c9d85 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -143,6 +143,14 @@ static __init void reserve_regions(void)
 	if (efi_enabled(EFI_DBG))
 		pr_info("Processing EFI memory map:\n");
 
+	/*
+	 * Discard memblocks discovered so far: if there are any at this
+	 * point, they originate from memory nodes in the DT, and UEFI
+	 * uses its own memory map instead.
+	 */
+	memblock_dump_all();
+	memblock_remove(0, ULLONG_MAX);
+
 	for_each_efi_memory_desc(&memmap, md) {
 		paddr = md->phys_addr;
 		npages = md->num_pages;
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index cf7b7d4..9df1560 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -24,7 +24,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
 			unsigned long map_size, unsigned long desc_size,
 			u32 desc_ver)
 {
-	int node, prev, num_rsv;
+	int node, num_rsv;
 	int status;
 	u32 fdt_val32;
 	u64 fdt_val64;
@@ -54,28 +54,6 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
 		goto fdt_set_fail;
 
 	/*
-	 * Delete any memory nodes present. We must delete nodes which
-	 * early_init_dt_scan_memory may try to use.
-	 */
-	prev = 0;
-	for (;;) {
-		const char *type;
-		int len;
-
-		node = fdt_next_node(fdt, prev, NULL);
-		if (node < 0)
-			break;
-
-		type = fdt_getprop(fdt, node, "device_type", &len);
-		if (type && strncmp(type, "memory", len) == 0) {
-			fdt_del_node(fdt, node);
-			continue;
-		}
-
-		prev = node;
-	}
-
-	/*
 	 * Delete all memory reserve map entries. When booting via UEFI,
 	 * kernel will use the UEFI memory map to find reserved regions.
 	 */
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Mon Feb 22 17:58:20 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Mon, 22 Feb 2016 17:58:20 -0800
Subject: [PATCH v12 2/5] Documentation, dt, numa: dt bindings for NUMA.
In-Reply-To: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1456192703-2274-3-git-send-email-ddaney.cavm@gmail.com>

From: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>

Add DT bindings for numa mapping of memory, CPUs and IOs.

Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 Documentation/devicetree/bindings/numa.txt | 272 +++++++++++++++++++++++++++++
 1 file changed, 272 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/numa.txt

diff --git a/Documentation/devicetree/bindings/numa.txt b/Documentation/devicetree/bindings/numa.txt
new file mode 100644
index 0000000..ec5ed7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/numa.txt
@@ -0,0 +1,272 @@
+==============================================================================
+NUMA binding description.
+==============================================================================
+
+==============================================================================
+1 - Introduction
+==============================================================================
+
+Systems employing a Non Uniform Memory Access (NUMA) architecture contain
+collections of hardware resources including processors, memory, and I/O buses,
+that comprise what is commonly known as a NUMA node.
+Processor accesses to memory within the local NUMA node is generally faster
+than processor accesses to memory outside of the local NUMA node.
+DT defines interfaces that allow the platform to convey NUMA node
+topology information to OS.
+
+==============================================================================
+2 - numa-node-id
+==============================================================================
+
+For the purpose of identification, each NUMA node is associated with a unique
+token known as a node id. For the purpose of this binding
+a node id is a 32-bit integer.
+
+A device node is associated with a NUMA node by the presence of a
+numa-node-id property which contains the node id of the device.
+
+Example:
+	/* numa node 0 */
+	numa-node-id = <0>;
+
+	/* numa node 1 */
+	numa-node-id = <1>;
+
+==============================================================================
+3 - distance-map
+==============================================================================
+
+The device tree node distance-map describes the relative
+distance (memory latency) between all numa nodes.
+
+- compatible : Should at least contain "numa-distance-map-v1".
+
+- distance-matrix
+  This property defines a matrix to describe the relative distances
+  between all numa nodes.
+  It is represented as a list of node pairs and their relative distance.
+
+  Note:
+	1. Each entry represents distance from first node to second node.
+	The distances are equal in either direction.
+	2. The distance from a node to self (local distance) is represented
+	with value 10 and all internode distance should be represented with
+	a value greater than 10.
+	3. distance-matrix should have entries in lexicographical ascending
+	order of nodes.
+	4. There must be only one device node distance-map which must reside in the root node.
+
+Example:
+	4 nodes connected in mesh/ring topology as below,
+
+		0_______20______1
+		|               |
+		|               |
+		20             20
+		|               |
+		|               |
+		|_______________|
+		3       20      2
+
+	if relative distance for each hop is 20,
+	then internode distance would be,
+	      0 -> 1 = 20
+	      1 -> 2 = 20
+	      2 -> 3 = 20
+	      3 -> 0 = 20
+	      0 -> 2 = 40
+	      1 -> 3 = 40
+
+     and dt presentation for this distance matrix is,
+
+		distance-map {
+			 compatible = "numa-distance-map-v1";
+			 distance-matrix = <0 0  10>,
+					   <0 1  20>,
+					   <0 2  40>,
+					   <0 3  20>,
+					   <1 0  20>,
+					   <1 1  10>,
+					   <1 2  20>,
+					   <1 3  40>,
+					   <2 0  40>,
+					   <2 1  20>,
+					   <2 2  10>,
+					   <2 3  20>,
+					   <3 0  20>,
+					   <3 1  40>,
+					   <3 2  20>,
+					   <3 3  10>;
+		};
+
+==============================================================================
+4 - Example dts
+==============================================================================
+
+Dual socket system consists of 2 boards connected through ccn bus and
+each board having one socket/soc of 8 cpus, memory and pci bus.
+
+	memory at c00000 {
+		device_type = "memory";
+		reg = <0x0 0xc00000 0x0 0x80000000>;
+		/* node 0 */
+		numa-node-id = <0>;
+	};
+
+	memory at 10000000000 {
+		device_type = "memory";
+		reg = <0x100 0x0 0x0 0x80000000>;
+		/* node 1 */
+		numa-node-id = <1>;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x0>;
+			enable-method = "psci";
+			/* node 0 */
+			numa-node-id = <0>;
+		};
+		cpu at 1 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x1>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 2 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x2>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 3 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x3>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 4 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x4>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 5 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x5>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 6 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x6>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 7 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x7>;
+			enable-method = "psci";
+			numa-node-id = <0>;
+		};
+		cpu at 8 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x8>;
+			enable-method = "psci";
+			/* node 1 */
+			numa-node-id = <1>;
+		};
+		cpu at 9 {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0x9>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at a {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xa>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at b {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xb>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at c {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xc>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at d {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xd>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at e {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xe>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+		cpu at f {
+			device_type = "cpu";
+			compatible =  "arm,armv8";
+			reg = <0x0 0xf>;
+			enable-method = "psci";
+			numa-node-id = <1>;
+		};
+	};
+
+	pcie0: pcie0 at 848000000000 {
+		compatible = "arm,armv8";
+		device_type = "pci";
+		bus-range = <0 255>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		reg = <0x8480 0x00000000 0 0x10000000>;  /* Configuration space */
+		ranges = <0x03000000 0x8010 0x00000000 0x8010 0x00000000 0x70 0x00000000>;
+		/* node 0 */
+		numa-node-id = <0>;
+        };
+
+	pcie1: pcie1 at 948000000000 {
+		compatible = "arm,armv8";
+		device_type = "pci";
+		bus-range = <0 255>;
+		#size-cells = <2>;
+		#address-cells = <3>;
+		reg = <0x9480 0x00000000 0 0x10000000>;  /* Configuration space */
+		ranges = <0x03000000 0x9010 0x00000000 0x9010 0x00000000 0x70 0x00000000>;
+		/* node 1 */
+		numa-node-id = <1>;
+        };
+
+	distance-map {
+		compatible = "numa-distance-map-v1";
+		distance-matrix = <0 0 10>,
+				  <0 1 20>,
+				  <1 1 10>;
+	};
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Mon Feb 22 17:58:21 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Mon, 22 Feb 2016 17:58:21 -0800
Subject: [PATCH v12 3/5] dt, numa: Add NUMA dt binding implementation.
In-Reply-To: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1456192703-2274-4-git-send-email-ddaney.cavm@gmail.com>

From: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>

ADD device tree node parsing for NUMA topology using device
"numa-node-id" property distance-map.

Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 drivers/of/Kconfig   |   3 +
 drivers/of/Makefile  |   1 +
 drivers/of/of_numa.c | 211 +++++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of.h   |   9 +++
 4 files changed, 224 insertions(+)
 create mode 100644 drivers/of/of_numa.c

diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index e2a4841..b3bec3a 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -112,4 +112,7 @@ config OF_OVERLAY
 	  While this option is selected automatically when needed, you can
 	  enable it manually to improve device tree unit test coverage.
 
+config OF_NUMA
+	bool
+
 endif # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 156c072..bee3fa9 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -14,5 +14,6 @@ obj-$(CONFIG_OF_MTD)	+= of_mtd.o
 obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
 obj-$(CONFIG_OF_RESOLVE)  += resolver.o
 obj-$(CONFIG_OF_OVERLAY) += overlay.o
+obj-$(CONFIG_OF_NUMA) += of_numa.o
 
 obj-$(CONFIG_OF_UNITTEST) += unittest-data/
diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
new file mode 100644
index 0000000..a691d06
--- /dev/null
+++ b/drivers/of/of_numa.c
@@ -0,0 +1,211 @@
+/*
+ * OF NUMA Parsing support.
+ *
+ * Copyright (C) 2015 - 2016 Cavium Inc.
+ * Author: Ganapatrao Kulkarni <gkulkarni at 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/of.h>
+#include <linux/of_fdt.h>
+#include <linux/nodemask.h>
+
+#include <asm/numa.h>
+
+/* define default numa node to 0 */
+#define DEFAULT_NODE 0
+
+/* Returns nid in the range [0..MAX_NUMNODES-1],
+ * or NUMA_NO_NODE if no valid numa-node-id entry found
+ * or DEFAULT_NODE if no numa-node-id entry exists
+ */
+static int of_numa_prop_to_nid(const __be32 *of_numa_prop, int length)
+{
+	int nid;
+
+	if (!of_numa_prop)
+		return DEFAULT_NODE;
+
+	if (length != sizeof(*of_numa_prop)) {
+		pr_warn("NUMA: Invalid of_numa_prop length %d found.\n",
+				length);
+		return NUMA_NO_NODE;
+	}
+
+	nid = of_read_number(of_numa_prop, 1);
+	if (nid >= MAX_NUMNODES) {
+		pr_warn("NUMA: Invalid numa node %d found.\n", nid);
+		return NUMA_NO_NODE;
+	}
+
+	return nid;
+}
+
+static int __init early_init_of_node_to_nid(unsigned long node)
+{
+	int length;
+	const __be32 *of_numa_prop;
+
+	of_numa_prop = of_get_flat_dt_prop(node, "numa-node-id", &length);
+
+	return of_numa_prop_to_nid(of_numa_prop, length);
+}
+
+/*
+ * Even though we connect cpus to numa domains later in SMP
+ * init, we need to know the node ids now for all cpus.
+*/
+static int __init early_init_parse_cpu_node(unsigned long node)
+{
+	int nid;
+	const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
+
+	if (type == NULL)
+		return 0;
+
+	if (strcmp(type, "cpu") != 0)
+		return 0;
+
+	nid = early_init_of_node_to_nid(node);
+	if (nid == NUMA_NO_NODE)
+		return -EINVAL;
+
+	node_set(nid, numa_nodes_parsed);
+	return 0;
+}
+
+static int __init early_init_parse_memory_node(unsigned long node)
+{
+	const __be32 *reg, *endp;
+	int length;
+	int nid;
+	const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
+
+	if (type == NULL)
+		return 0;
+
+	if (strcmp(type, "memory") != 0)
+		return 0;
+
+	nid = early_init_of_node_to_nid(node);
+	if (nid == NUMA_NO_NODE)
+		return -EINVAL;
+
+	reg = of_get_flat_dt_prop(node, "reg", &length);
+	endp = reg + (length / sizeof(__be32));
+
+	while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
+		u64 base, size;
+
+		base = dt_mem_next_cell(dt_root_addr_cells, &reg);
+		size = dt_mem_next_cell(dt_root_size_cells, &reg);
+		pr_debug("NUMA:  base = %llx , node = %u\n",
+				base, nid);
+
+		if (numa_add_memblk(nid, base, size) < 0)
+			return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int __init early_init_parse_distance_map_v1(unsigned long node,
+		const char *uname)
+{
+	const __be32 *prop_dist_matrix;
+	int length = 0, i, matrix_count;
+	int nr_size_cells = OF_ROOT_NODE_SIZE_CELLS_DEFAULT;
+
+	pr_info("NUMA: parsing numa-distance-map-v1\n");
+
+	prop_dist_matrix =
+		of_get_flat_dt_prop(node, "distance-matrix", &length);
+
+	if (!length) {
+		pr_err("NUMA: failed to parse distance-matrix\n");
+		return -ENODEV;
+	}
+
+	matrix_count = ((length / sizeof(__be32)) / (3 * nr_size_cells));
+
+	if ((matrix_count * sizeof(__be32) * 3 * nr_size_cells) !=  length) {
+		pr_warn("NUMA: invalid distance-matrix length %d\n", length);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < matrix_count; i++) {
+		u32 nodea, nodeb, distance;
+
+		nodea = dt_mem_next_cell(nr_size_cells, &prop_dist_matrix);
+		nodeb = dt_mem_next_cell(nr_size_cells, &prop_dist_matrix);
+		distance = dt_mem_next_cell(nr_size_cells, &prop_dist_matrix);
+		numa_set_distance(nodea, nodeb, distance);
+		pr_debug("NUMA:  distance[node%d -> node%d] = %d\n",
+				nodea, nodeb, distance);
+
+		/* Set default distance of node B->A same as A->B */
+		if (nodeb > nodea)
+			numa_set_distance(nodeb, nodea, distance);
+	}
+
+	return 0;
+}
+
+static int __init early_init_parse_distance_map(unsigned long node,
+		const char *uname)
+{
+	if (strcmp(uname, "distance-map") != 0)
+		return 0;
+
+	if (of_flat_dt_is_compatible(node, "numa-distance-map-v1"))
+		return early_init_parse_distance_map_v1(node, uname);
+
+	pr_err("NUMA: invalid distance-map device node\n");
+	return -EINVAL;
+}
+
+static int __init early_init_of_scan_numa_map(unsigned long node,
+					      const char *uname,
+					      int depth, void *data)
+{
+	int ret;
+
+	ret = early_init_parse_cpu_node(node);
+	if (ret)
+		return ret;
+
+	ret = early_init_parse_memory_node(node);
+	if (ret)
+		return ret;
+
+	return early_init_parse_distance_map(node, uname);
+}
+
+int of_node_to_nid(struct device_node *device)
+{
+	const __be32 *of_numa_prop;
+	int length;
+
+	of_numa_prop = of_get_property(device, "numa-node-id", &length);
+	if (of_numa_prop)
+		return of_numa_prop_to_nid(of_numa_prop, length);
+
+	return NUMA_NO_NODE;
+}
+
+/* DT node mapping is done already early_init_of_scan_memory */
+int __init of_numa_init(void)
+{
+	return of_scan_flat_dt(early_init_of_scan_numa_map, NULL);
+}
diff --git a/include/linux/of.h b/include/linux/of.h
index dc6e396..fe67a4c 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -685,6 +685,15 @@ static inline int of_node_to_nid(struct device_node *device)
 }
 #endif
 
+#ifdef CONFIG_OF_NUMA
+extern int of_numa_init(void);
+#else
+static inline int of_numa_init(void)
+{
+	return -ENOSYS;
+}
+#endif
+
 static inline struct device_node *of_find_matching_node(
 	struct device_node *from,
 	const struct of_device_id *matches)
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Mon Feb 22 17:58:23 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Mon, 22 Feb 2016 17:58:23 -0800
Subject: [PATCH v12 5/5] arm64, mm, numa: Add NUMA balancing support for arm64.
In-Reply-To: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1456192703-2274-6-git-send-email-ddaney.cavm@gmail.com>

From: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>

Enable NUMA balancing for arm64 platforms.
Add pte, pmd protnone helpers for use by automatic NUMA balancing.

Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 arch/arm64/Kconfig               |  1 +
 arch/arm64/include/asm/pgtable.h | 15 +++++++++++++++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9f0972a..6e22503 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -11,6 +11,7 @@ config ARM64
 	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
 	select ARCH_USE_CMPXCHG_LOCKREF
 	select ARCH_SUPPORTS_ATOMIC_RMW
+	select ARCH_SUPPORTS_NUMA_BALANCING
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
 	select ARCH_WANT_FRAME_POINTERS
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index bf464de..5af9db2 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -346,6 +346,21 @@ static inline pgprot_t mk_sect_prot(pgprot_t prot)
 	return __pgprot(pgprot_val(prot) & ~PTE_TABLE_BIT);
 }
 
+#ifdef CONFIG_NUMA_BALANCING
+/*
+ * See the comment in include/asm-generic/pgtable.h
+ */
+static inline int pte_protnone(pte_t pte)
+{
+	return (pte_val(pte) & (PTE_VALID | PTE_PROT_NONE)) == PTE_PROT_NONE;
+}
+
+static inline int pmd_protnone(pmd_t pmd)
+{
+	return pte_protnone(pmd_pte(pmd));
+}
+#endif
+
 /*
  * THP definitions.
  */
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Mon Feb 22 17:58:22 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Mon, 22 Feb 2016 17:58:22 -0800
Subject: [PATCH v12 4/5] arm64, numa: Add NUMA support for arm64 platforms.
In-Reply-To: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1456192703-2274-5-git-send-email-ddaney.cavm@gmail.com>

From: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>

Attempt to get the memory and CPU NUMA node via of_numa.  If that
fails, default the dummy NUMA node and map all memory and CPUs to node
0.

Tested-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 arch/arm64/Kconfig                |  26 +++
 arch/arm64/include/asm/mmzone.h   |  12 ++
 arch/arm64/include/asm/numa.h     |  45 +++++
 arch/arm64/include/asm/topology.h |  10 +
 arch/arm64/kernel/pci.c           |  10 +
 arch/arm64/kernel/setup.c         |   4 +
 arch/arm64/kernel/smp.c           |   4 +
 arch/arm64/mm/Makefile            |   1 +
 arch/arm64/mm/init.c              |  34 +++-
 arch/arm64/mm/mmu.c               |   1 +
 arch/arm64/mm/numa.c              | 403 ++++++++++++++++++++++++++++++++++++++
 11 files changed, 545 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm64/include/asm/mmzone.h
 create mode 100644 arch/arm64/include/asm/numa.h
 create mode 100644 arch/arm64/mm/numa.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a969970..9f0972a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -74,6 +74,7 @@ config ARM64
 	select HAVE_HW_BREAKPOINT if PERF_EVENTS
 	select HAVE_IRQ_TIME_ACCOUNTING
 	select HAVE_MEMBLOCK
+	select HAVE_MEMBLOCK_NODE_MAP if NUMA
 	select HAVE_PATA_PLATFORM
 	select HAVE_PERF_EVENTS
 	select HAVE_PERF_REGS
@@ -96,6 +97,7 @@ config ARM64
 	select SYSCTL_EXCEPTION_TRACE
 	select HAVE_CONTEXT_TRACKING
 	select HAVE_ARM_SMCCC
+	select OF_NUMA if NUMA && OF
 	help
 	  ARM 64-bit (AArch64) Linux support.
 
@@ -545,6 +547,30 @@ config HOTPLUG_CPU
 	  Say Y here to experiment with turning CPUs off and on.  CPUs
 	  can be controlled through /sys/devices/system/cpu.
 
+# Common NUMA Features
+config NUMA
+	bool "Numa Memory Allocation and Scheduler Support"
+	depends on SMP
+	help
+	  Enable NUMA (Non Uniform Memory Access) support.
+
+	  The kernel will try to allocate memory used by a CPU on the
+	  local memory of the CPU and add some more
+	  NUMA awareness to the kernel.
+
+config NODES_SHIFT
+	int "Maximum NUMA Nodes (as a power of 2)"
+	range 1 10
+	default "2"
+	depends on NEED_MULTIPLE_NODES
+	help
+	  Specify the maximum number of NUMA Nodes available on the target
+	  system.  Increases memory reserved to accommodate various tables.
+
+config USE_PERCPU_NUMA_NODE_ID
+	def_bool y
+	depends on NUMA
+
 source kernel/Kconfig.preempt
 source kernel/Kconfig.hz
 
diff --git a/arch/arm64/include/asm/mmzone.h b/arch/arm64/include/asm/mmzone.h
new file mode 100644
index 0000000..a0de9e6
--- /dev/null
+++ b/arch/arm64/include/asm/mmzone.h
@@ -0,0 +1,12 @@
+#ifndef __ASM_MMZONE_H
+#define __ASM_MMZONE_H
+
+#ifdef CONFIG_NUMA
+
+#include <asm/numa.h>
+
+extern struct pglist_data *node_data[];
+#define NODE_DATA(nid)		(node_data[(nid)])
+
+#endif /* CONFIG_NUMA */
+#endif /* __ASM_MMZONE_H */
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
new file mode 100644
index 0000000..e9b4f29
--- /dev/null
+++ b/arch/arm64/include/asm/numa.h
@@ -0,0 +1,45 @@
+#ifndef __ASM_NUMA_H
+#define __ASM_NUMA_H
+
+#include <asm/topology.h>
+
+#ifdef CONFIG_NUMA
+
+/* currently, arm64 implements flat NUMA topology */
+#define parent_node(node)	(node)
+
+int __node_distance(int from, int to);
+#define node_distance(a, b) __node_distance(a, b)
+
+extern nodemask_t numa_nodes_parsed __initdata;
+
+/* Mappings between node number and cpus on that node. */
+extern cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
+void numa_clear_node(unsigned int cpu);
+
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+const struct cpumask *cpumask_of_node(int node);
+#else
+/* Returns a pointer to the cpumask of CPUs on Node 'node'. */
+static inline const struct cpumask *cpumask_of_node(int node)
+{
+	return node_to_cpumask_map[node];
+}
+#endif
+
+void __init arm64_numa_init(void);
+int __init numa_add_memblk(int nodeid, u64 start, u64 end);
+void __init numa_set_distance(int from, int to, int distance);
+void __init numa_free_distance(void);
+void __init early_map_cpu_to_node(unsigned int cpu, int nid);
+void numa_store_cpu_info(unsigned int cpu);
+
+#else	/* CONFIG_NUMA */
+
+static inline void numa_store_cpu_info(unsigned int cpu) { }
+static inline void arm64_numa_init(void) { }
+static inline void early_map_cpu_to_node(unsigned int cpu, int nid) { }
+
+#endif	/* CONFIG_NUMA */
+
+#endif	/* __ASM_NUMA_H */
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index a3e9d6f..8b57339 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -22,6 +22,16 @@ void init_cpu_topology(void);
 void store_cpu_topology(unsigned int cpuid);
 const struct cpumask *cpu_coregroup_mask(int cpu);
 
+#ifdef CONFIG_NUMA
+
+struct pci_bus;
+int pcibus_to_node(struct pci_bus *bus);
+#define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ?		\
+				 cpu_all_mask :				\
+				 cpumask_of_node(pcibus_to_node(bus)))
+
+#endif /* CONFIG_NUMA */
+
 #include <asm-generic/topology.h>
 
 #endif /* _ASM_ARM_TOPOLOGY_H */
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index b3d098b..65e6b7d 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -76,6 +76,16 @@ int raw_pci_write(unsigned int domain, unsigned int bus,
 	return -ENXIO;
 }
 
+#ifdef CONFIG_NUMA
+
+int pcibus_to_node(struct pci_bus *bus)
+{
+	return dev_to_node(&bus->dev);
+}
+EXPORT_SYMBOL(pcibus_to_node);
+
+#endif
+
 #ifdef CONFIG_ACPI
 /* Root bridge scanning */
 struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 8119479..d9b9761 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -53,6 +53,7 @@
 #include <asm/cpufeature.h>
 #include <asm/cpu_ops.h>
 #include <asm/kasan.h>
+#include <asm/numa.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
 #include <asm/smp_plat.h>
@@ -372,6 +373,9 @@ static int __init topology_init(void)
 {
 	int i;
 
+	for_each_online_node(i)
+		register_one_node(i);
+
 	for_each_possible_cpu(i) {
 		struct cpu *cpu = &per_cpu(cpu_data.cpu, i);
 		cpu->hotpluggable = 1;
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index b1adc51..46c45c8 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -45,6 +45,7 @@
 #include <asm/cputype.h>
 #include <asm/cpu_ops.h>
 #include <asm/mmu_context.h>
+#include <asm/numa.h>
 #include <asm/pgtable.h>
 #include <asm/pgalloc.h>
 #include <asm/processor.h>
@@ -125,6 +126,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
 static void smp_store_cpu_info(unsigned int cpuid)
 {
 	store_cpu_topology(cpuid);
+	numa_store_cpu_info(cpuid);
 }
 
 /*
@@ -518,6 +520,8 @@ static void __init of_parse_and_init_cpus(void)
 
 		pr_debug("cpu logical map 0x%llx\n", hwid);
 		cpu_logical_map(cpu_count) = hwid;
+
+		early_map_cpu_to_node(cpu_count, of_node_to_nid(dn));
 next:
 		cpu_count++;
 	}
diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
index 57f57fd..54bb209 100644
--- a/arch/arm64/mm/Makefile
+++ b/arch/arm64/mm/Makefile
@@ -4,6 +4,7 @@ obj-y				:= dma-mapping.o extable.o fault.o init.o \
 				   context.o proc.o pageattr.o
 obj-$(CONFIG_HUGETLB_PAGE)	+= hugetlbpage.o
 obj-$(CONFIG_ARM64_PTDUMP)	+= dump.o
+obj-$(CONFIG_NUMA)		+= numa.o
 
 obj-$(CONFIG_KASAN)		+= kasan_init.o
 KASAN_SANITIZE_kasan_init.o	:= n
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3b061e..c39c670 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -37,6 +37,7 @@
 
 #include <asm/fixmap.h>
 #include <asm/memory.h>
+#include <asm/numa.h>
 #include <asm/sections.h>
 #include <asm/setup.h>
 #include <asm/sizes.h>
@@ -77,6 +78,21 @@ static phys_addr_t __init max_zone_dma_phys(void)
 	return min(offset + (1ULL << 32), memblock_end_of_DRAM());
 }
 
+#ifdef CONFIG_NUMA
+
+static void __init zone_sizes_init(unsigned long min, unsigned long max)
+{
+	unsigned long max_zone_pfns[MAX_NR_ZONES]  = {0};
+
+	if (IS_ENABLED(CONFIG_ZONE_DMA))
+		max_zone_pfns[ZONE_DMA] = PFN_DOWN(max_zone_dma_phys());
+	max_zone_pfns[ZONE_NORMAL] = max;
+
+	free_area_init_nodes(max_zone_pfns);
+}
+
+#else
+
 static void __init zone_sizes_init(unsigned long min, unsigned long max)
 {
 	struct memblock_region *reg;
@@ -117,6 +133,8 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
 	free_area_init_node(0, zone_size, min, zhole_size);
 }
 
+#endif /* CONFIG_NUMA */
+
 #ifdef CONFIG_HAVE_ARCH_PFN_VALID
 int pfn_valid(unsigned long pfn)
 {
@@ -133,10 +151,15 @@ static void __init arm64_memory_present(void)
 static void __init arm64_memory_present(void)
 {
 	struct memblock_region *reg;
+	int nid = 0;
 
-	for_each_memblock(memory, reg)
-		memory_present(0, memblock_region_memory_base_pfn(reg),
-			       memblock_region_memory_end_pfn(reg));
+	for_each_memblock(memory, reg) {
+#ifdef CONFIG_NUMA
+		nid = reg->nid;
+#endif
+		memory_present(nid, memblock_region_memory_base_pfn(reg),
+				memblock_region_memory_end_pfn(reg));
+	}
 }
 #endif
 
@@ -181,7 +204,6 @@ void __init arm64_memblock_init(void)
 	dma_contiguous_reserve(arm64_dma_phys_limit);
 
 	memblock_allow_resize();
-	memblock_dump_all();
 }
 
 void __init bootmem_init(void)
@@ -193,6 +215,9 @@ void __init bootmem_init(void)
 
 	early_memtest(min << PAGE_SHIFT, max << PAGE_SHIFT);
 
+	max_pfn = max_low_pfn = max;
+
+	arm64_numa_init();
 	/*
 	 * Sparsemem tries to allocate bootmem in memory_present(), so must be
 	 * done after the fixed reservations.
@@ -203,7 +228,6 @@ void __init bootmem_init(void)
 	zone_sizes_init(min, max);
 
 	high_memory = __va((max << PAGE_SHIFT) - 1) + 1;
-	max_pfn = max_low_pfn = max;
 }
 
 #ifndef CONFIG_SPARSEMEM_VMEMMAP
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 58faeaa..44e3854 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -463,6 +463,7 @@ void __init paging_init(void)
 	zero_page = early_alloc(PAGE_SIZE);
 
 	bootmem_init();
+	memblock_dump_all();
 
 	empty_zero_page = virt_to_page(zero_page);
 
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
new file mode 100644
index 0000000..604e886
--- /dev/null
+++ b/arch/arm64/mm/numa.c
@@ -0,0 +1,403 @@
+/*
+ * NUMA support, based on the x86 implementation.
+ *
+ * Copyright (C) 2015 Cavium Inc.
+ * Author: Ganapatrao Kulkarni <gkulkarni at 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/bootmem.h>
+#include <linux/memblock.h>
+#include <linux/module.h>
+#include <linux/of.h>
+
+struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
+EXPORT_SYMBOL(node_data);
+nodemask_t numa_nodes_parsed __initdata;
+static int cpu_to_node_map[NR_CPUS] = { [0 ... NR_CPUS-1] = NUMA_NO_NODE };
+
+static int numa_off;
+static int numa_distance_cnt;
+static u8 *numa_distance;
+
+static __init int numa_parse_early_param(char *opt)
+{
+	if (!opt)
+		return -EINVAL;
+	if (!strncmp(opt, "off", 3)) {
+		pr_info("%s\n", "NUMA turned off");
+		numa_off = 1;
+	}
+	return 0;
+}
+early_param("numa", numa_parse_early_param);
+
+cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
+EXPORT_SYMBOL(node_to_cpumask_map);
+
+#ifdef CONFIG_DEBUG_PER_CPU_MAPS
+
+/*
+ * Returns a pointer to the bitmask of CPUs on Node 'node'.
+ */
+const struct cpumask *cpumask_of_node(int node)
+{
+	if (WARN_ON(node >= nr_node_ids))
+		return cpu_none_mask;
+
+	if (WARN_ON(node_to_cpumask_map[node] == NULL))
+		return cpu_online_mask;
+
+	return node_to_cpumask_map[node];
+}
+EXPORT_SYMBOL(cpumask_of_node);
+
+#endif
+
+static void map_cpu_to_node(unsigned int cpu, int nid)
+{
+	set_cpu_numa_node(cpu, nid);
+	if (nid >= 0)
+		cpumask_set_cpu(cpu, node_to_cpumask_map[nid]);
+}
+
+static void unmap_cpu_to_node(unsigned int cpu)
+{
+	int nid = cpu_to_node(cpu);
+
+	if (nid >= 0)
+		cpumask_clear_cpu(cpu, node_to_cpumask_map[nid]);
+	set_cpu_numa_node(cpu, NUMA_NO_NODE);
+}
+
+void numa_clear_node(unsigned int cpu)
+{
+	unmap_cpu_to_node(cpu);
+}
+
+/*
+ * Allocate node_to_cpumask_map based on number of available nodes
+ * Requires node_possible_map to be valid.
+ *
+ * Note: cpumask_of_node() is not valid until after this is done.
+ * (Use CONFIG_DEBUG_PER_CPU_MAPS to check this.)
+ */
+static void __init setup_node_to_cpumask_map(void)
+{
+	unsigned int cpu;
+	int node;
+
+	/* setup nr_node_ids if not done yet */
+	if (nr_node_ids == MAX_NUMNODES)
+		setup_nr_node_ids();
+
+	/* allocate and clear the mapping */
+	for (node = 0; node < nr_node_ids; node++) {
+		alloc_bootmem_cpumask_var(&node_to_cpumask_map[node]);
+		cpumask_clear(node_to_cpumask_map[node]);
+	}
+
+	for_each_possible_cpu(cpu)
+		set_cpu_numa_node(cpu, NUMA_NO_NODE);
+
+	/* cpumask_of_node() will now work */
+	pr_debug("NUMA: Node to cpumask map for %d nodes\n", nr_node_ids);
+}
+
+/*
+ *  Set the cpu to node and mem mapping
+ */
+void numa_store_cpu_info(unsigned int cpu)
+{
+	map_cpu_to_node(cpu, numa_off ? 0 : cpu_to_node_map[cpu]);
+}
+
+void __init early_map_cpu_to_node(unsigned int cpu, int nid)
+{
+	/* fallback to node 0 */
+	if (nid < 0 || nid >= MAX_NUMNODES)
+		nid = 0;
+
+	cpu_to_node_map[cpu] = nid;
+}
+
+/**
+ * numa_add_memblk - Set node id to memblk
+ * @nid: NUMA node ID of the new memblk
+ * @start: Start address of the new memblk
+ * @size:  Size of the new memblk
+ *
+ * RETURNS:
+ * 0 on success, -errno on failure.
+ */
+int __init numa_add_memblk(int nid, u64 start, u64 size)
+{
+	int ret;
+
+	ret = memblock_set_node(start, size, &memblock.memory, nid);
+	if (ret < 0) {
+		pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node %d\n",
+			start, (start + size - 1), nid);
+		return ret;
+	}
+
+	node_set(nid, numa_nodes_parsed);
+	pr_info("NUMA: Adding memblock [0x%llx - 0x%llx] on node %d\n",
+			start, (start + size - 1), nid);
+	return ret;
+}
+EXPORT_SYMBOL(numa_add_memblk);
+
+/**
+ * Initialize NODE_DATA for a node on the local memory
+ */
+static void __init setup_node_data(int nid, u64 start_pfn, u64 end_pfn)
+{
+	const size_t nd_size = roundup(sizeof(pg_data_t), SMP_CACHE_BYTES);
+	u64 nd_pa;
+	void *nd;
+	int tnid;
+
+	pr_info("NUMA: Initmem setup node %d [mem %#010Lx-%#010Lx]\n",
+			nid, start_pfn << PAGE_SHIFT,
+			(end_pfn << PAGE_SHIFT) - 1);
+
+	nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
+	nd = __va(nd_pa);
+
+	/* report and initialize */
+	pr_info("NUMA: NODE_DATA [mem %#010Lx-%#010Lx]\n",
+		nd_pa, nd_pa + nd_size - 1);
+	tnid = early_pfn_to_nid(nd_pa >> PAGE_SHIFT);
+	if (tnid != nid)
+		pr_info("NUMA: NODE_DATA(%d) on node %d\n", nid, tnid);
+
+	node_data[nid] = nd;
+	memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
+	NODE_DATA(nid)->node_id = nid;
+	NODE_DATA(nid)->node_start_pfn = start_pfn;
+	NODE_DATA(nid)->node_spanned_pages = end_pfn - start_pfn;
+}
+
+/**
+ * numa_free_distance
+ *
+ * The current table is freed.
+ */
+void __init numa_free_distance(void)
+{
+	size_t size;
+
+	if (!numa_distance)
+		return;
+
+	size = numa_distance_cnt * numa_distance_cnt *
+		sizeof(numa_distance[0]);
+
+	memblock_free(__pa(numa_distance), size);
+	numa_distance_cnt = 0;
+	numa_distance = NULL;
+}
+
+/**
+ *
+ * Create a new NUMA distance table.
+ *
+ */
+static int __init numa_alloc_distance(void)
+{
+	size_t size;
+	u64 phys;
+	int i, j;
+
+	size = nr_node_ids * nr_node_ids * sizeof(numa_distance[0]);
+	phys = memblock_find_in_range(0, PFN_PHYS(max_pfn),
+				      size, PAGE_SIZE);
+	if (WARN_ON(!phys))
+		return -ENOMEM;
+
+	memblock_reserve(phys, size);
+
+	numa_distance = __va(phys);
+	numa_distance_cnt = nr_node_ids;
+
+	/* fill with the default distances */
+	for (i = 0; i < numa_distance_cnt; i++)
+		for (j = 0; j < numa_distance_cnt; j++)
+			numa_distance[i * numa_distance_cnt + j] = i == j ?
+				LOCAL_DISTANCE : REMOTE_DISTANCE;
+
+	pr_debug("NUMA: Initialized distance table, cnt=%d\n",
+			numa_distance_cnt);
+
+	return 0;
+}
+
+/**
+ * numa_set_distance - Set inter node NUMA distance from node to node.
+ * @from: the 'from' node to set distance
+ * @to: the 'to'  node to set distance
+ * @distance: NUMA distance
+ *
+ * Set the distance from node @from to @to to @distance.
+ * If distance table doesn't exist, a warning is printed.
+ *
+ * If @from or @to is higher than the highest known node or lower than zero
+ * or @distance doesn't make sense, the call is ignored.
+ *
+ */
+void __init numa_set_distance(int from, int to, int distance)
+{
+	if (!numa_distance) {
+		pr_warn_once("NUMA: Warning: distance table not allocated yet\n");
+		return;
+	}
+
+	if (from >= numa_distance_cnt || to >= numa_distance_cnt ||
+			from < 0 || to < 0) {
+		pr_warn_once("NUMA: Warning: node ids are out of bound, from=%d to=%d distance=%d\n",
+			    from, to, distance);
+		return;
+	}
+
+	if ((u8)distance != distance ||
+	    (from == to && distance != LOCAL_DISTANCE)) {
+		pr_warn_once("NUMA: Warning: invalid distance parameter, from=%d to=%d distance=%d\n",
+			     from, to, distance);
+		return;
+	}
+
+	numa_distance[from * numa_distance_cnt + to] = distance;
+}
+EXPORT_SYMBOL(numa_set_distance);
+
+/**
+ * Return NUMA distance @from to @to
+ */
+int __node_distance(int from, int to)
+{
+	if (from >= numa_distance_cnt || to >= numa_distance_cnt)
+		return from == to ? LOCAL_DISTANCE : REMOTE_DISTANCE;
+	return numa_distance[from * numa_distance_cnt + to];
+}
+EXPORT_SYMBOL(__node_distance);
+
+static int __init numa_register_nodes(void)
+{
+	int nid;
+	struct memblock_region *mblk;
+
+	/* Check that valid nid is set to memblks */
+	for_each_memblock(memory, mblk)
+		if (mblk->nid == NUMA_NO_NODE || mblk->nid >= MAX_NUMNODES) {
+			pr_warn("NUMA: Warning: invalid memblk node %d [mem %#010Lx-%#010Lx]\n",
+				mblk->nid, mblk->base,
+				mblk->base + mblk->size - 1);
+			return -EINVAL;
+		}
+
+	/* Finally register nodes. */
+	for_each_node_mask(nid, numa_nodes_parsed) {
+		unsigned long start_pfn, end_pfn;
+
+		get_pfn_range_for_nid(nid, &start_pfn, &end_pfn);
+		setup_node_data(nid, start_pfn, end_pfn);
+		node_set_online(nid);
+	}
+
+	/* Setup online nodes to actual nodes*/
+	node_possible_map = numa_nodes_parsed;
+
+	return 0;
+}
+
+static int __init numa_init(int (*init_func)(void))
+{
+	int ret;
+
+	nodes_clear(numa_nodes_parsed);
+	nodes_clear(node_possible_map);
+	nodes_clear(node_online_map);
+	numa_free_distance();
+
+	ret = numa_alloc_distance();
+	if (ret < 0)
+		return ret;
+
+	ret = init_func();
+	if (ret < 0)
+		return ret;
+
+	if (nodes_empty(numa_nodes_parsed))
+		return -EINVAL;
+
+	ret = numa_register_nodes();
+	if (ret < 0)
+		return ret;
+
+	setup_node_to_cpumask_map();
+
+	/* init boot processor */
+	cpu_to_node_map[0] = 0;
+	map_cpu_to_node(0, 0);
+
+	return 0;
+}
+
+/**
+ * dummy_numa_init - Fallback dummy NUMA init
+ *
+ * Used if there's no underlying NUMA architecture, NUMA initialization
+ * fails, or NUMA is disabled on the command line.
+ *
+ * Must online at least one node (node 0) and add memory blocks that cover all
+ * allowed memory. It is unlikely that this function fails.
+ */
+static int __init dummy_numa_init(void)
+{
+	int ret;
+	struct memblock_region *mblk;
+
+	pr_info("%s\n", "No NUMA configuration found");
+	pr_info("NUMA: Faking a node at [mem %#018Lx-%#018Lx]\n",
+	       0LLU, PFN_PHYS(max_pfn) - 1);
+
+	for_each_memblock(memory, mblk) {
+		ret = numa_add_memblk(0, mblk->base, mblk->size);
+		if (!ret)
+			continue;
+
+		pr_err("NUMA init failed\n");
+		return ret;
+	}
+
+	numa_off = 1;
+	return 0;
+}
+
+/**
+ * arm64_numa_init - Initialize NUMA
+ *
+ * Try each configured NUMA initialization method until one succeeds.  The
+ * last fallback is dummy single node config encomapssing whole memory.
+ */
+void __init arm64_numa_init(void)
+{
+	if (!numa_off) {
+		if (!numa_init(of_numa_init))
+			return;
+	}
+
+	numa_init(dummy_numa_init);
+}
-- 
1.8.3.1



From shijie.huang at arm.com  Mon Feb 22 18:31:57 2016
From: shijie.huang at arm.com (Huang Shijie)
Date: Tue, 23 Feb 2016 10:31:57 +0800
Subject: [PATCH v2 0/6] arm64: Add support of KVM with ACPI
In-Reply-To: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
References: <1455204804-31830-1-git-send-email-julien.grall@arm.com>
Message-ID: <20160223023156.GA11645@sha-win-210.asiapac.arm.com>

On Thu, Feb 11, 2016 at 03:33:18PM +0000, Julien Grall wrote:
> Hello,
>
> This small series allows an ARM64 ACPI based platform to use KVM.
>
> Currently the KVM code has to parse the firmware table to get the necessary
> information to setup the virtual timer and virtual GIC.
>
> However the parsing of those tables are already done in the GIC and arch
> timer drivers.
>
> This patch series introduces different helpers to retrieve the information
> from different drivers avoiding to duplicate the parsing code.
>
> Note there is patch series ([1] and [2]) adding support of KVM on ACPI,
> although the approach chosen is completely different. The code to parse
> the firmware tables are duplicated which I think make more complex to
> support new firmware tables.
>
> See the changes since v1 in the different patches.
>
> Regards,
>
> [1] https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018482.html
> [2] https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018355.html
>
> Julien Grall (6):
>   KVM: arm/arm64: arch_timer: Gather KVM specific information in a
>     structure
>   KVM: arm/arm64: arch_timer: Rely on the arch timer to parse the
>     firmware tables
>   irqchip/gic-v2: Gather ACPI specific data in a single structure
>   irqchip/gic-v2: Parse and export virtual GIC information
>   irqchip/gic-v3: Parse and export virtual GIC information
Beside this patch (I do not have the gic-v3 hardware now), I tested this patch set with my JUNo-r1 board
with kvmtool. It works fine.

Tested-by: Huang Shijie <shijie.huang at arm.com>



>   KVM: arm/arm64: vgic: Rely on the GIC driver to parse the firmware
>     tables
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.



From gabriele.paoloni at huawei.com  Mon Feb 22 18:47:22 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Tue, 23 Feb 2016 02:47:22 +0000
Subject: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
 HiSilicon SoCs Host Controllers
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1D30@lhreml503-mbs>
References: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
 <1455039260-6040-4-git-send-email-gabriele.paoloni@huawei.com>
 <20160209182429.GD4348@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1591@lhreml503-mbs>
 <20160210111234.GC2632@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1D30@lhreml503-mbs>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECC5F00@lhreml503-mbs>

Hi Mark

> -----Original Message-----
> From: Gabriele Paoloni
> Sent: 10 February 2016 22:45
> To: Mark Rutland
> Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C); Linuxarm;
> qiujiang; bhelgaas at google.com; arnd at arndb.de; Lorenzo.Pieralisi at arm.com;
> tn at semihalf.com; linux-pci at vger.kernel.org; linux-
> kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth); linux-arm-
> kernel at lists.infradead.org
> Subject: RE: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
> HiSilicon SoCs Host Controllers
> 
> > -----Original Message-----
> > From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> > owner at vger.kernel.org] On Behalf Of Mark Rutland
> > Sent: 10 February 2016 11:13
> > To: Gabriele Paoloni
> > Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C); Linuxarm;
> > qiujiang; bhelgaas at google.com; arnd at arndb.de;
> > Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-pci at vger.kernel.org;
> > linux-kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> > jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth); linux-arm-
> > kernel at lists.infradead.org
> > Subject: Re: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
> > HiSilicon SoCs Host Controllers
> >
> > On Wed, Feb 10, 2016 at 09:52:36AM +0000, Gabriele Paoloni wrote:
> > > Hi Mark
> > >
> > > > On Tue, Feb 09, 2016 at 05:34:20PM +0000, Gabriele Paoloni wrote:
> > > > > From: gabriele paoloni <gabriele.paoloni at huawei.com>
> > > > > +/*
> > > > > + * Retrieve rc_dbi base and size from _DSD
> > > > > + * Name (_DSD, Package () {
> > > > > + *	ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > > > > + *	Package () {
> > > > > + *	Package () {"rc-dbi", Package () { 0x0, 0xb0080000, 0x0,
> > 0x10000
> > > > }},
> > > > > + *	}
> > > > > + *	})
> > > > > + */
> > > >
> > > > As above, this does not look right. ACPI has standard mechanisms
> > for
> > > > describing addresses. Making something up like this is not a good
> > idea.
> > >
> > > I am quite new to ACPI, may I ask you to explain a bit?
> >
> > ACPI has standard mechanisms for describing certain resources, and
> > these
> > should not be described in _DSD. Memory or IO address regions are
> such
> > resources (in _CRS, IIRC), and should not be described in _DSD.
> 
> Hi Mark,
> 
> In my case I think in need to look into the MCFG object as the problem
> I have is RC using a different range than the rest of the hierarchy.
> 
> I'll investigate this and try to come with a solution in v4

I have looked into this and in our case we cannot use the
standard MCFG object to pass the RC config space addresses.

The reason is that in our HW we have the config base addresses of the 
root complex ports that are less than 0x100000 byte distant one from
the other as we only map the first 0x10000 bytes.

Now the MCFG acpi framework always fix the MCFG resource size to 0x100000
for each bus; therefore if we pass our RC addresses through MCFG we end
up with a resource conflict.

To give you a practical example we are in a situation where we have:

port0: [0x00000000b0080000 - 0x00000000b0080000 + 0x10000]
port1: [0x00000000b0090000 - 0x00000000b0090000 + 0x10000]
port2: [0x00000000b00A0000 - 0x00000000b00A0000 + 0x10000]
port3: [0x00000000b00B0000 - 0x00000000b00B0000 + 0x10000]
  
So if we pass the base addresses through MCFG the resources
will overlap as MCFG will consider 0x100000 size for each base
address of the root complex (only the RC bus uses that address)

So far I do not see many option other than using _DSD to pass
these RC config base addresses.

Thanks and Regards

Gab 

> 
> Many Thanks
> 
> Gab
> 
> >
> > Thanks,
> > Mark.


From vinod.koul at intel.com  Mon Feb 22 19:02:35 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 23 Feb 2016 08:32:35 +0530
Subject: [PATCH] dma: mv_xor_v2: new driver
In-Reply-To: <20160222101621.4f03ef8b@free-electrons.com>
References: <1455523083-25506-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160222032730.GU19598@localhost>
 <20160222101621.4f03ef8b@free-electrons.com>
Message-ID: <20160223030235.GG17690@localhost>

On Mon, Feb 22, 2016 at 10:16:21AM +0100, Thomas Petazzoni wrote:

> > So why should it depend on how kernel is configured?
> 
> Because using upper_32_bits() on a 32-bits type seems wrong? You can do
> a git grep for CONFIG_ARCH_DMA_ADDR_T_64BIT, and see that it is already
> used in drivers/dma/sh/rcar-dmac.c, drivers/gpu/drm/tegra/dc.c or
> drivers/iommu/tegra-smmu.c.
> 
> drivers/dma/sh/rcar-dmac.c uses it for exactly the same reason as me:
> they need to know if dma_addr_t is 32 bits or 64 bits, and if it's 64
> bits, then they need to take the upper 32 bits and feed them to some
> register.

So is the hardware capable of 32bit of 64bit?


> > You don't want to check the source of interrupt?
> 
> To protect against what? An improper MSI message that ends up firing
> this interrupt for now reason? But only kernel space stuff (or
> privileged code in user-space) can write to the MSI triggering
> registers, so we should be able to trust that such an improper MSI
> message will not arrive.

Your device might go bonkers or some erranious programming does cause
interrupts. Its better to be safe than sorry :)

> 
> That being said, I can add a read of the pending descriptors number,
> and if it's 0, then bail out with IRQ_NONE. Is that what you were
> thinking about?

Sounds good


> > why BUG_ON, is the system unusable after this?
> 
> Well, the XOR engine cannot do XOR with 0 source buffers, or with more
> than MV_XOR_V2_CMD_LINE_NUM_MAX_D_BUF.
> 
> But I see that I'm already setting max_xor in struct dma_device, so one
> can assume that ->prep_dma_xor() will not be called with src_cnt == or
> src_cnt > max_xor, so this BUG_ON can be removed.

Okay, you should return NULL to caller if that is the case

-- 
~Vinod


From xinliang.liu at linaro.org  Mon Feb 22 19:00:20 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Tue, 23 Feb 2016 11:00:20 +0800
Subject: [PATCH v5 00/11] Add DRM Driver for HiSilicon Kirin hi6220 SoC
Message-ID: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>

This patch set adds a new drm driver for HiSilicon Kirin hi6220 SoC.
Current testing and support board is Hikey board which is one of Linaro
96boards. It is an arm64 open source board. For more information about
this board, please access https://www.96boards.org.

Hardware Detail
---------------
  The display subsystem of Hi6220 SoC is shown as bellow:
 +-----+       +----------+     +-----+     +-------------+
 |     |       |          |     |     |     |             |             	
 | FB  |------>|   ADE    |---->| DSI |---->|   External  |
 |     |       |          |     |     |     |  HDMI/panel |
 +-----+       +----------+     +-----+     +-------------+

- ADE(Advanced Display Engine) is the display controller. It contains 7
channels, 3 overlay compositors and a LDI.
  - A channel looks like: DMA-->clip-->scale-->ctrans(or called csc).
  - Overlay compositor is response to compose planes which come from 7
  channels and pass composed image to LDI.
  - LDI is response to generate timings and RGB data stream.
- DSI converts the RGB data stream from ADE to DSI packets.
- External HDMI/panel module is connected with DSI bus. Now Hikey use a
  ADI's ADV7533 external HDMI chip.

Change History
-------------
Changes in v5:
- Remove endpoint unit address of dsi output port.
- Use syscon to access ADE media NOC QoS registers instread of directly
  writing registers.
- Use reset controller to reset ADE instead of directly writing registers.
Changes in v4:
- Describe more specific of clocks and ports of binding docs.
- Fix indentation of binding docs.

Changes in v3:
- Move and rename all the files to kirin sub-directory.
  So that we could separate different seires SoCs' driver.
- Make ade as the drm master node.
- Replace drm_platform_init, load, unload implementation.
- Use assigned-clocks to set clock rate.
- Use ports to connect display relavant nodes.
- Rename hisi_drm_dsi.c to dw_drm_dsi.c
- Make encoder type as DRM_MODE_ENCODER_DSI.
- A few cleanup on regs and code.

Changes in v2:
- Remove abtraction layer of plane/crtc/encoder/connector.
- Refactor atomic implementation according to Daniel Vetter's guides:
http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html
http://blog.ffwll.ch/2015/09/xdc-2015-atomic-modesetting-for-drivers.html
http://blog.ffwll.ch/2015/08/atomic-modesetting-design-overview.html
- Use bridge instead of slave encoder to connect external HDMI.
- Move dt binding docs to bindings/display/hisilicon directory. 

Xinliang Liu (11):
  drm/hisilicon: Add device tree binding for hi6220 display subsystem
  drm/hisilicon: Add hisilicon kirin drm master driver
  drm/hisilicon: Add crtc driver for ADE
  drm/hisilicon: Add plane driver for ADE
  drm/hisilicon: Add vblank driver for ADE
  drm/hisilicon: Add cma fbdev and hotplug
  drm/hisilicon: Add designware dsi encoder driver
  drm/hisilicon: Add designware dsi host driver
  drm/hisilicon: Add support for external bridge
  MAINTAINERS: Add maintainer for hisilicon DRM driver
  arm64: dts: hisilicon: Add display subsystem DT nodes for hi6220

 .../bindings/display/hisilicon/dw-dsi.txt          |   72 ++
 .../bindings/display/hisilicon/hisi-ade.txt        |   64 ++
 MAINTAINERS                                        |   10 +
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts     |   40 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi          |   55 +
 drivers/gpu/drm/Kconfig                            |    2 +
 drivers/gpu/drm/Makefile                           |    1 +
 drivers/gpu/drm/hisilicon/Kconfig                  |    5 +
 drivers/gpu/drm/hisilicon/Makefile                 |    5 +
 drivers/gpu/drm/hisilicon/kirin/Kconfig            |   10 +
 drivers/gpu/drm/hisilicon/kirin/Makefile           |    5 +
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c       |  845 ++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h       |   83 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h    |  290 ++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c    | 1047 ++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c    |  382 +++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h    |   31 +
 17 files changed, 2947 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
 create mode 100644 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h

-- 
1.9.1



From xinliang.liu at linaro.org  Mon Feb 22 19:00:21 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Tue, 23 Feb 2016 11:00:21 +0800
Subject: [PATCH v5 01/11] drm/hisilicon: Add device tree binding for hi6220
 display subsystem
In-Reply-To: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
References: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456196431-19923-2-git-send-email-xinliang.liu@linaro.org>

Add ADE display controller binding doc.
Add DesignWare DSI Host Controller v1.20a binding doc.

v5:
- Remove endpoint unit address of dsi output port.
- Add "hisilicon,noc-syscon" property for ADE NOC QoS syscon.
- Add "resets" property for ADE reset.
v4:
- Describe more specific of clocks and ports.
- Fix indentation.
v3:
- Make ade as the drm master node.
- Use assigned-clocks to set clock rate.
- Use ports to connect display relavant nodes.
v2:
- Move dt binding docs to bindings/display/hisilicon directory.

Signed-off-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 .../bindings/display/hisilicon/dw-dsi.txt          | 72 ++++++++++++++++++++++
 .../bindings/display/hisilicon/hisi-ade.txt        | 64 +++++++++++++++++++
 2 files changed, 136 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
 create mode 100644 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt

diff --git a/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
new file mode 100644
index 000000000000..0d234b5e19af
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
@@ -0,0 +1,72 @@
+Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
+
+A DSI Host Controller resides in the middle of display controller and external
+HDMI converter or panel.
+
+Required properties:
+- compatible: value should be "hisilicon,hi6220-dsi".
+- reg: physical base address and length of dsi controller's registers.
+- clocks: the clocks needed.
+- clock-names: the name of the clocks.
+- ports: contains DSI controller input and output sub port.
+  The input port connects to ADE output port with the reg value "0".
+  The output port with the reg value "1", it could connect to panel or
+  any other bridge endpoints.
+  See Documentation/devicetree/bindings/graph.txt for more device graph info.
+
+A example of HiKey board hi6220 SoC and board specific DT entry:
+Example:
+
+SoC specific:
+	dsi: dsi at f4107800 {
+		compatible = "hisilicon,hi6220-dsi";
+		reg = <0x0 0xf4107800 0x0 0x100>;
+		clocks = <&media_ctrl  HI6220_DSI_PCLK>;
+		clock-names = "pclk_dsi";
+		status = "disabled";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			/* 0 for input port */
+			port at 0 {
+				reg = <0>;
+				dsi_in: endpoint {
+					remote-endpoint = <&ade_out>;
+				};
+			};
+		};
+	};
+
+
+Board specific:
+	&dsi {
+		status = "ok";
+
+		ports {
+			/* 1 for output port */
+			port at 1 {
+				reg = <1>;
+
+				dsi_out0: endpoint at 0 {
+					remote-endpoint = <&adv7533_in>;
+				};
+			};
+		};
+	};
+
+	&i2c2 {
+		...
+
+		adv7533: adv7533 at 39 {
+			...
+
+			port {
+				adv7533_in: endpoint {
+					remote-endpoint = <&dsi_out0>;
+				};
+			};
+		};
+	};
+
diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
new file mode 100644
index 000000000000..c1844b3ff878
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
@@ -0,0 +1,64 @@
+Device-Tree bindings for hisilicon ADE display controller driver
+
+ADE (Advanced Display Engine) is the display controller which grab image
+data from memory, do composition, do post image processing, generate RGB
+timing stream and transfer to DSI.
+
+Required properties:
+- compatible: value should be "hisilicon,hi6220-ade".
+- reg: physical base address and length of the ADE controller's registers.
+  Value should be "<0x0 0xf4100000 0x0 0x7800>".
+- reg-names: name of physical base. Value should be "ade_base".
+- hisilicon,noc-syscon: ADE NOC QoS syscon. Value should be "<&medianoc_ade>"
+- resets: The ADE reset controller node. Value should be "<&media_ctrl
+  MEDIA_ADE>".
+- interrupt: the ldi vblank interrupt number used.
+- clocks: the clocks needed. Three clocks are used in ADE driver:
+  ADE core clock, value should be "<&media_ctrl HI6220_ADE_CORE>";
+  ADE pixel clok, value should be "<&media_ctrl HI6220_ADE_PIX_SRC>";
+  media NOC QoS clock, value should be "<&media_ctrl HI6220_CODEC_JPEG>".
+- clock-names: the name of the clocks. Values should be "clk_ade_core",
+  "clk_codec_jpeg" and "clk_ade_pix".
+- assigned-clocks: clocks to be assigned rate.
+- assigned-clock-rates: clock rates which are assigned to assigned-clocks.
+  The rate of <&media_ctrl HI6220_ADE_CORE> could be "360000000" or
+  "180000000";
+  The rate of <&media_ctrl HI6220_CODEC_JPEG> could be less than "1440000000".
+- port: the output port. This contains one endpoint subnode, with its
+  remote-endpoint set to the phandle of the connected DSI input endpoint.
+  See Documentation/devicetree/bindings/graph.txt for more device graph info.
+
+Optional properties:
+- dma-coherent: Present if dma operations are coherent.
+
+
+A example of HiKey board hi6220 SoC specific DT entry:
+Example:
+
+	ade: ade at f4100000 {
+		compatible = "hisilicon,hi6220-ade";
+		reg = <0x0 0xf4100000 0x0 0x7800>;
+		reg-names = "ade_base";
+		hisilicon,noc-syscon = <&medianoc_ade>;
+		resets = <&media_ctrl MEDIA_ADE>;
+		interrupts = <0 115 4>; /* ldi interrupt */
+
+		clocks = <&media_ctrl HI6220_ADE_CORE>,
+			 <&media_ctrl HI6220_CODEC_JPEG>,
+			 <&media_ctrl HI6220_ADE_PIX_SRC>;
+		/*clock name*/
+		clock-names  = "clk_ade_core",
+			       "clk_codec_jpeg",
+			       "clk_ade_pix";
+
+		assigned-clocks = <&media_ctrl HI6220_ADE_CORE>,
+			<&media_ctrl HI6220_CODEC_JPEG>;
+		assigned-clock-rates = <360000000>, <288000000>;
+		dma-coherent;
+
+		port {
+			ade_out: endpoint {
+				remote-endpoint = <&dsi_in>;
+			};
+		};
+	};
-- 
1.9.1



From xinliang.liu at linaro.org  Mon Feb 22 19:00:22 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Tue, 23 Feb 2016 11:00:22 +0800
Subject: [PATCH v5 02/11] drm/hisilicon: Add hisilicon kirin drm master driver
In-Reply-To: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
References: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456196431-19923-3-git-send-email-xinliang.liu@linaro.org>

Add kirin DRM master driver for hi6220 SoC which used in HiKey board.
Add dumb buffer feature.
Add prime dmabuf feature.

v5: None.
v4: None.
v3:
- Move and rename all the files to kirin sub-directory.
  So that we could separate different seires SoCs' driver.
- Replace drm_platform_init, load, unload implementation.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/Kconfig                         |   2 +
 drivers/gpu/drm/Makefile                        |   1 +
 drivers/gpu/drm/hisilicon/Kconfig               |   5 +
 drivers/gpu/drm/hisilicon/Makefile              |   5 +
 drivers/gpu/drm/hisilicon/kirin/Kconfig         |   9 +
 drivers/gpu/drm/hisilicon/kirin/Makefile        |   3 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 321 ++++++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  20 ++
 8 files changed, 366 insertions(+)
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b50ae60f5f50..f5c5656e2547 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -277,3 +277,5 @@ source "drivers/gpu/drm/imx/Kconfig"
 source "drivers/gpu/drm/vc4/Kconfig"
 
 source "drivers/gpu/drm/etnaviv/Kconfig"
+
+source "drivers/gpu/drm/hisilicon/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 61766dec6a8d..60554832079c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -74,3 +74,4 @@ obj-y			+= panel/
 obj-y			+= bridge/
 obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
+obj-y			+= hisilicon/
diff --git a/drivers/gpu/drm/hisilicon/Kconfig b/drivers/gpu/drm/hisilicon/Kconfig
new file mode 100644
index 000000000000..558c61b1b8e8
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/Kconfig
@@ -0,0 +1,5 @@
+#
+# hisilicon drm device configuration.
+# Please keep this list sorted alphabetically
+
+source "drivers/gpu/drm/hisilicon/kirin/Kconfig"
diff --git a/drivers/gpu/drm/hisilicon/Makefile b/drivers/gpu/drm/hisilicon/Makefile
new file mode 100644
index 000000000000..e3f6d493c996
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for hisilicon drm drivers.
+# Please keep this list sorted alphabetically
+
+obj-$(CONFIG_DRM_HISI_KIRIN) += kirin/
diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig b/drivers/gpu/drm/hisilicon/kirin/Kconfig
new file mode 100644
index 000000000000..3ac4b8edeac1
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
@@ -0,0 +1,9 @@
+config DRM_HISI_KIRIN
+	tristate "DRM Support for Hisilicon Kirin series SoCs Platform"
+	depends on DRM
+	select DRM_KMS_HELPER
+	select DRM_GEM_CMA_HELPER
+	select DRM_KMS_CMA_HELPER
+	help
+	  Choose this option if you have a hisilicon Kirin chipsets(hi6220).
+	  If M is selected the module will be called kirin-drm.
diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile b/drivers/gpu/drm/hisilicon/kirin/Makefile
new file mode 100644
index 000000000000..cb346de47d48
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -0,0 +1,3 @@
+kirin-drm-y := kirin_drm_drv.o
+
+obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
new file mode 100644
index 000000000000..789ebd1f5922
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -0,0 +1,321 @@
+/*
+ * Hisilicon Kirin SoCs drm master driver
+ *
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * Author:
+ *	Xinliang Liu <z.liuxinliang at hisilicon.com>
+ *	Xinliang Liu <xinliang.liu at linaro.org>
+ *	Xinwei Kong <kong.kongxinwei at hisilicon.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.
+ *
+ */
+
+#include <linux/of_platform.h>
+#include <linux/component.h>
+#include <linux/of_graph.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_gem_cma_helper.h>
+#include <drm/drm_fb_cma_helper.h>
+#include <drm/drm_atomic_helper.h>
+
+#include "kirin_drm_drv.h"
+
+static struct kirin_dc_ops *dc_ops;
+
+static int kirin_drm_kms_cleanup(struct drm_device *dev)
+{
+	dc_ops->cleanup(dev);
+	drm_mode_config_cleanup(dev);
+
+	return 0;
+}
+
+static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
+	.fb_create = drm_fb_cma_create,
+	.atomic_check = drm_atomic_helper_check,
+	.atomic_commit = drm_atomic_helper_commit,
+};
+
+static void kirin_drm_mode_config_init(struct drm_device *dev)
+{
+	dev->mode_config.min_width = 0;
+	dev->mode_config.min_height = 0;
+
+	dev->mode_config.max_width = 2048;
+	dev->mode_config.max_height = 2048;
+
+	dev->mode_config.funcs = &kirin_drm_mode_config_funcs;
+}
+
+static int kirin_drm_kms_init(struct drm_device *dev)
+{
+	int ret;
+
+	dev_set_drvdata(dev->dev, dev);
+
+	/* dev->mode_config initialization */
+	drm_mode_config_init(dev);
+	kirin_drm_mode_config_init(dev);
+
+	/* display controller init */
+	ret = dc_ops->init(dev);
+	if (ret)
+		goto err_mode_config_cleanup;
+
+	/* bind and init sub drivers */
+	ret = component_bind_all(dev->dev, dev);
+	if (ret) {
+		DRM_ERROR("failed to bind all component.\n");
+		goto err_dc_cleanup;
+	}
+
+	/* reset all the states of crtc/plane/encoder/connector */
+	drm_mode_config_reset(dev);
+
+	return 0;
+
+err_dc_cleanup:
+	dc_ops->cleanup(dev);
+err_mode_config_cleanup:
+	drm_mode_config_cleanup(dev);
+
+	return ret;
+}
+
+static const struct file_operations kirin_drm_fops = {
+	.owner		= THIS_MODULE,
+	.open		= drm_open,
+	.release	= drm_release,
+	.unlocked_ioctl	= drm_ioctl,
+#ifdef CONFIG_COMPAT
+	.compat_ioctl	= drm_compat_ioctl,
+#endif
+	.poll		= drm_poll,
+	.read		= drm_read,
+	.llseek		= no_llseek,
+	.mmap		= drm_gem_cma_mmap,
+};
+
+static int kirin_gem_cma_dumb_create(struct drm_file *file,
+				     struct drm_device *dev,
+				     struct drm_mode_create_dumb *args)
+{
+	return drm_gem_cma_dumb_create_internal(file, dev, args);
+}
+
+static struct drm_driver kirin_drm_driver = {
+	.driver_features	= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
+				  DRIVER_ATOMIC,
+	.fops			= &kirin_drm_fops,
+	.set_busid		= drm_platform_set_busid,
+
+	.gem_free_object	= drm_gem_cma_free_object,
+	.gem_vm_ops		= &drm_gem_cma_vm_ops,
+	.dumb_create		= kirin_gem_cma_dumb_create,
+	.dumb_map_offset	= drm_gem_cma_dumb_map_offset,
+	.dumb_destroy		= drm_gem_dumb_destroy,
+
+	.prime_handle_to_fd	= drm_gem_prime_handle_to_fd,
+	.prime_fd_to_handle	= drm_gem_prime_fd_to_handle,
+	.gem_prime_export	= drm_gem_prime_export,
+	.gem_prime_import	= drm_gem_prime_import,
+	.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
+	.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
+	.gem_prime_vmap		= drm_gem_cma_prime_vmap,
+	.gem_prime_vunmap	= drm_gem_cma_prime_vunmap,
+	.gem_prime_mmap		= drm_gem_cma_prime_mmap,
+
+	.name			= "kirin",
+	.desc			= "Hisilicon Kirin SoCs' DRM Driver",
+	.date			= "20150718",
+	.major			= 1,
+	.minor			= 0,
+};
+
+static int compare_of(struct device *dev, void *data)
+{
+	return dev->of_node == data;
+}
+
+static int kirin_drm_connectors_register(struct drm_device *dev)
+{
+	struct drm_connector *connector;
+	struct drm_connector *failed_connector;
+	int ret;
+
+	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+		ret = drm_connector_register(connector);
+		if (ret) {
+			failed_connector = connector;
+			goto err;
+		}
+	}
+
+	return 0;
+
+err:
+	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+		if (failed_connector == connector)
+			break;
+		drm_connector_unregister(connector);
+	}
+
+	return ret;
+}
+
+static int kirin_drm_bind(struct device *dev)
+{
+	struct drm_driver *driver = &kirin_drm_driver;
+	struct drm_device *drm_dev;
+	int ret;
+
+	drm_dev = drm_dev_alloc(driver, dev);
+	if (!drm_dev)
+		return -ENOMEM;
+
+	drm_dev->platformdev = to_platform_device(dev);
+
+	ret = kirin_drm_kms_init(drm_dev);
+	if (ret)
+		goto err_drm_dev_unref;
+
+	ret = drm_dev_register(drm_dev, 0);
+	if (ret)
+		goto err_kms_cleanup;
+
+	/* connectors should be registered after drm device register */
+	ret = kirin_drm_connectors_register(drm_dev);
+	if (ret)
+		goto err_drm_dev_unregister;
+
+	DRM_INFO("Initialized %s %d.%d.%d %s on minor %d\n",
+		 driver->name, driver->major, driver->minor, driver->patchlevel,
+		 driver->date, drm_dev->primary->index);
+
+	return 0;
+
+err_drm_dev_unregister:
+	drm_dev_unregister(drm_dev);
+err_kms_cleanup:
+	kirin_drm_kms_cleanup(drm_dev);
+err_drm_dev_unref:
+	drm_dev_unref(drm_dev);
+
+	return ret;
+}
+
+static void kirin_drm_unbind(struct device *dev)
+{
+	drm_put_dev(dev_get_drvdata(dev));
+}
+
+static const struct component_master_ops kirin_drm_ops = {
+	.bind = kirin_drm_bind,
+	.unbind = kirin_drm_unbind,
+};
+
+static const struct of_device_id kirin_drm_dt_ids[] = {
+	{ /* end node */ },
+};
+MODULE_DEVICE_TABLE(of, kirin_drm_dt_ids);
+
+static int kirin_get_dc_ops(struct device_node *np)
+{
+	const struct of_device_id *match_id;
+
+	match_id = of_match_node(kirin_drm_dt_ids, np);
+	if (!match_id) {
+		DRM_ERROR("failed to match dt id\n");
+		return -EINVAL;
+	}
+
+	dc_ops = (struct kirin_dc_ops *)match_id->data;
+	if (!dc_ops) {
+		DRM_ERROR("dt id data is null\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static struct device_node *kirin_get_remote_node(struct device_node *np)
+{
+	struct device_node *endpoint, *remote;
+
+	/* get the first endpoint, in our case only one remote node
+	 * is connected to display controller.
+	 */
+	endpoint = of_graph_get_next_endpoint(np, NULL);
+	if (!endpoint) {
+		DRM_ERROR("no valid endpoint node\n");
+		return ERR_PTR(-ENODEV);
+	}
+	of_node_put(endpoint);
+
+	remote = of_graph_get_remote_port_parent(endpoint);
+	if (!remote) {
+		DRM_ERROR("no valid remote node\n");
+		return ERR_PTR(-ENODEV);
+	}
+	of_node_put(remote);
+
+	if (!of_device_is_available(remote)) {
+		DRM_ERROR("not available for remote node\n");
+		return ERR_PTR(-ENODEV);
+	}
+
+	return remote;
+}
+
+static int kirin_drm_platform_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct component_match *match = NULL;
+	struct device_node *remote;
+	int ret;
+
+	ret = kirin_get_dc_ops(np);
+	if (ret)
+		return ret;
+
+	remote = kirin_get_remote_node(np);
+	if (IS_ERR(remote))
+		return PTR_ERR(remote);
+
+	component_match_add(dev, &match, compare_of, remote);
+
+	return component_master_add_with_match(dev, &kirin_drm_ops, match);
+
+	return 0;
+}
+
+static int kirin_drm_platform_remove(struct platform_device *pdev)
+{
+	component_master_del(&pdev->dev, &kirin_drm_ops);
+	dc_ops = NULL;
+	return 0;
+}
+
+static struct platform_driver kirin_drm_platform_driver = {
+	.probe = kirin_drm_platform_probe,
+	.remove = kirin_drm_platform_remove,
+	.driver = {
+		.name = "kirin-drm",
+		.of_match_table = kirin_drm_dt_ids,
+	},
+};
+
+module_platform_driver(kirin_drm_platform_driver);
+
+MODULE_AUTHOR("Xinliang Liu <xinliang.liu at linaro.org>");
+MODULE_AUTHOR("Xinliang Liu <z.liuxinliang at hisilicon.com>");
+MODULE_AUTHOR("Xinwei Kong <kong.kongxinwei at hisilicon.com>");
+MODULE_DESCRIPTION("hisilicon Kirin SoCs' DRM master driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
new file mode 100644
index 000000000000..75e9d82356d4
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -0,0 +1,20 @@
+/*
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __KIRIN_DRM_DRV_H__
+#define __KIRIN_DRM_DRV_H__
+
+/* display controller init/cleanup ops */
+struct kirin_dc_ops {
+	int (*init)(struct drm_device *dev);
+	void (*cleanup)(struct drm_device *dev);
+};
+
+#endif /* __KIRIN_DRM_DRV_H__ */
-- 
1.9.1



From xinliang.liu at linaro.org  Mon Feb 22 19:00:23 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Tue, 23 Feb 2016 11:00:23 +0800
Subject: [PATCH v5 03/11] drm/hisilicon: Add crtc driver for ADE
In-Reply-To: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
References: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456196431-19923-4-git-send-email-xinliang.liu@linaro.org>

Add crtc funcs and helper funcs for ADE.

v5:
- Use syscon to access ADE media NOC QoS registers instread of directly
  writing registers.
- Use reset controller to reset ADE instead of directly writing registers.
v4: None.
v3:
- Make ade as the master driver.
- Use port to connect with encoder.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/Makefile        |   3 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 290 +++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 452 ++++++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  15 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |   8 +
 5 files changed, 767 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c

diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile b/drivers/gpu/drm/hisilicon/kirin/Makefile
index cb346de47d48..2a61ab006ddb 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Makefile
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -1,3 +1,4 @@
-kirin-drm-y := kirin_drm_drv.o
+kirin-drm-y := kirin_drm_drv.o \
+	       kirin_drm_ade.o
 
 obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
new file mode 100644
index 000000000000..eb444b899c7b
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
@@ -0,0 +1,290 @@
+/*
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __KIRIN_ADE_REG_H__
+#define __KIRIN_ADE_REG_H__
+
+/*
+ * ADE Registers
+ */
+#define MASK(x)				(BIT(x) - 1)
+
+#define ADE_CTRL			0x0004
+#define FRM_END_START_OFST		0
+#define FRM_END_START_MASK		MASK(2)
+#define ADE_CTRL1			0x008C
+#define AUTO_CLK_GATE_EN_OFST		0
+#define AUTO_CLK_GATE_EN		BIT(0)
+#define ADE_ROT_SRC_CFG			0x0010
+#define ADE_DISP_SRC_CFG		0x0018
+#define ADE_WDMA2_SRC_CFG		0x001C
+#define ADE_SEC_OVLY_SRC_CFG		0x0020
+#define ADE_WDMA3_SRC_CFG		0x0024
+#define ADE_OVLY1_TRANS_CFG		0x002C
+#define ADE_EN				0x0100
+#define ADE_DISABLE			0
+#define ADE_ENABLE			1
+#define INTR_MASK_CPU(x)		(0x0C10 + (x) * 0x4)
+#define ADE_FRM_DISGARD_CTRL		0x00A4
+/* reset and reload regs */
+#define ADE_SOFT_RST_SEL(x)		(0x0078 + (x) * 0x4)
+#define ADE_RELOAD_DIS(x)		(0x00AC + (x) * 0x4)
+#define RDMA_OFST			0
+#define CLIP_OFST			15
+#define SCL_OFST			21
+#define CTRAN_OFST			24
+#define OVLY_OFST			37 /* 32+5 */
+/* channel regs */
+#define RD_CH_PE(x)			(0x1000 + (x) * 0x80)
+#define RD_CH_CTRL(x)			(0x1004 + (x) * 0x80)
+#define RD_CH_ADDR(x)			(0x1008 + (x) * 0x80)
+#define RD_CH_SIZE(x)			(0x100C + (x) * 0x80)
+#define RD_CH_STRIDE(x)			(0x1010 + (x) * 0x80)
+#define RD_CH_SPACE(x)			(0x1014 + (x) * 0x80)
+#define RD_CH_PARTIAL_SIZE(x)		(0x1018 + (x) * 0x80)
+#define RD_CH_PARTIAL_SPACE(x)		(0x101C + (x) * 0x80)
+#define RD_CH_EN(x)			(0x1020 + (x) * 0x80)
+#define RD_CH_STATUS(x)			(0x1024 + (x) * 0x80)
+#define RD_CH_DISP_CTRL			0x1404
+#define RD_CH_DISP_ADDR			0x1408
+#define RD_CH_DISP_SIZE			0x140C
+#define RD_CH_DISP_STRIDE		0x1410
+#define RD_CH_DISP_SPACE		0x1414
+#define RD_CH_DISP_EN			0x142C
+/* clip regs */
+#define ADE_CLIP_DISABLE(x)		(0x6800 + (x) * 0x100)
+#define ADE_CLIP_SIZE0(x)		(0x6804 + (x) * 0x100)
+#define ADE_CLIP_SIZE1(x)		(0x6808 + (x) * 0x100)
+#define ADE_CLIP_SIZE2(x)		(0x680C + (x) * 0x100)
+#define ADE_CLIP_CFG_OK(x)		(0x6810 + (x) * 0x100)
+/* scale regs */
+#define ADE_SCL1_MUX_CFG		0x000C
+#define ADE_SCL2_SRC_CFG		0x0014
+#define ADE_SCL3_MUX_CFG		0x0008
+#define ADE_SCL_CTRL(x)			(0x3000 + (x) * 0x800)
+#define ADE_SCL_HSP(x)			(0x3004 + (x) * 0x800)
+#define ADE_SCL_UV_HSP(x)		(0x3008 + (x) * 0x800)
+#define ADE_SCL_VSP(x)			(0x300C + (x) * 0x800)
+#define ADE_SCL_UV_VSP(x)		(0x3010 + (x) * 0x800)
+#define ADE_SCL_ORES(x)			(0x3014 + (x) * 0x800)
+#define ADE_SCL_IRES(x)			(0x3018 + (x) * 0x800)
+#define ADE_SCL_START(x)		(0x301C + (x) * 0x800)
+#define ADE_SCL_ERR(x)			(0x3020 + (x) * 0x800)
+#define ADE_SCL_PIX_OFST(x)		(0x3024 + (x) * 0x800)
+#define ADE_SCL_UV_PIX_OFST(x)		(0x3028 + (x) * 0x800)
+#define ADE_SCL_COEF_CLR(x)		(0x3030 + (x) * 0x800)
+#define ADE_SCL_HCOEF(x, m, n)		(0x3100 + (x) * 0x800 + \
+					12 * (m) + 4 * (n))
+#define ADE_SCL_VCOEF(x, i, j)		(0x340C + (x) * 0x800 + \
+					12 * (i) + 4 * (j))
+/* ctran regs */
+#define ADE_CTRAN5_TRANS_CFG		0x0040
+#define ADE_CTRAN_DIS(x)		(0x5004 + (x) * 0x100)
+#define CTRAN_BYPASS_ON			1
+#define CTRAN_BYPASS_OFF		0
+#define ADE_CTRAN_MODE_CHOOSE(x)	(0x5008 + (x) * 0x100)
+#define ADE_CTRAN_STAT(x)		(0x500C + (x) * 0x100)
+#define ADE_CTRAN_CHDC0(x)		(0x5010 + (x) * 0x100)
+#define ADE_CTRAN_CHDC1(x)		(0x5014 + (x) * 0x100)
+#define ADE_CTRAN_CHDC2(x)		(0x5018 + (x) * 0x100)
+#define ADE_CTRAN_CHDC3(x)		(0x501C + (x) * 0x100)
+#define ADE_CTRAN_CHDC4(x)		(0x5020 + (x) * 0x100)
+#define ADE_CTRAN_CHDC5(x)		(0x5024 + (x) * 0x100)
+#define ADE_CTRAN_CSC0(x)		(0x5028 + (x) * 0x100)
+#define ADE_CTRAN_CSC1(x)		(0x502C + (x) * 0x100)
+#define ADE_CTRAN_CSC2(x)		(0x5030 + (x) * 0x100)
+#define ADE_CTRAN_CSC3(x)		(0x5034 + (x) * 0x100)
+#define ADE_CTRAN_CSC4(x)		(0x5038 + (x) * 0x100)
+#define ADE_CTRAN_IMAGE_SIZE(x)		(0x503C + (x) * 0x100)
+#define ADE_CTRAN_CFG_OK(x)		(0x5040 + (x) * 0x100)
+/* overlay regs */
+#define ADE_OVLY_ALPHA_ST		0x2000
+#define ADE_OVLY_CH_XY0(x)		(0x2004 + (x) * 4)
+#define ADE_OVLY_CH_XY1(x)		(0x2024 + (x) * 4)
+#define ADE_OVLY_CH_CTL(x)		(0x204C + (x) * 4)
+#define ADE_OVLY_OUTPUT_SIZE(x)		(0x2070 + (x) * 8)
+#define OUTPUT_XSIZE_OFST		16
+#define ADE_OVLY_BASE_COLOR(x)		(0x2074 + (x) * 8)
+#define ADE_OVLYX_CTL(x)		(0x209C + (x) * 4)
+#define ADE_OVLY_CTL			0x0098
+#define CH_OVLY_SEL_OFST(x)		((x) * 4)
+#define CH_OVLY_SEL_MASK		MASK(2)
+#define CH_OVLY_SEL_VAL(x)		((x) + 1)
+#define CH_ALP_MODE_OFST		0
+#define CH_ALP_SEL_OFST			2
+#define CH_UNDER_ALP_SEL_OFST		4
+#define CH_EN_OFST			6
+#define CH_ALP_GBL_OFST			15
+#define CH_SEL_OFST			28
+
+/*
+ * LDI Registers
+ */
+#define LDI_HRZ_CTRL0			0x7400
+#define HBP_OFST			20
+#define LDI_HRZ_CTRL1			0x7404
+#define LDI_VRT_CTRL0			0x7408
+#define VBP_OFST			20
+#define LDI_VRT_CTRL1			0x740C
+#define LDI_PLR_CTRL			0x7410
+#define FLAG_NVSYNC			BIT(0)
+#define FLAG_NHSYNC			BIT(1)
+#define FLAG_NPIXCLK			BIT(2)
+#define FLAG_NDE			BIT(3)
+#define LDI_DSP_SIZE			0x7414
+#define VSIZE_OFST			20
+#define LDI_INT_EN			0x741C
+#define FRAME_END_INT_EN_OFST		1
+#define LDI_CTRL			0x7420
+#define BPP_OFST			3
+#define DATA_GATE_EN			BIT(2)
+#define LDI_EN				BIT(0)
+#define LDI_ORG_INT			0x7424
+#define LDI_MSK_INT			0x7428
+#define LDI_INT_CLR			0x742C
+#define LDI_WORK_MODE			0x7430
+#define LDI_DE_SPACE_LOW		0x7438
+#define LDI_MCU_INTS			0x7450
+#define LDI_MCU_INTE			0x7454
+#define LDI_MCU_INTC			0x7458
+#define LDI_HDMI_DSI_GT			0x7434
+
+/*
+ * ADE media bus service regs
+ */
+#define ADE0_QOSGENERATOR_MODE		0x010C
+#define QOSGENERATOR_MODE_MASK		MASK(2)
+#define ADE0_QOSGENERATOR_EXTCONTROL	0x0118
+#define SOCKET_QOS_EN			BIT(0)
+#define ADE1_QOSGENERATOR_MODE		0x020C
+#define ADE1_QOSGENERATOR_EXTCONTROL	0x0218
+
+/*
+ * ADE regs relevant enums
+ */
+enum frame_end_start {
+	/* regs take effective in every vsync */
+	REG_EFFECTIVE_IN_VSYNC = 0,
+	/* regs take effective in fist ade en and every frame end */
+	REG_EFFECTIVE_IN_ADEEN_FRMEND,
+	/* regs take effective in ade en immediately */
+	REG_EFFECTIVE_IN_ADEEN,
+	/* regs take effective in first vsync and every frame end */
+	REG_EFFECTIVE_IN_VSYNC_FRMEND
+};
+
+enum ade_fb_format {
+	ADE_RGB_565 = 0,
+	ADE_BGR_565,
+	ADE_XRGB_8888,
+	ADE_XBGR_8888,
+	ADE_ARGB_8888,
+	ADE_ABGR_8888,
+	ADE_RGBA_8888,
+	ADE_BGRA_8888,
+	ADE_RGB_888,
+	ADE_BGR_888 = 9,
+	ADE_FORMAT_NOT_SUPPORT = 800
+};
+
+enum ade_channel {
+	ADE_CH1 = 0,	/* channel 1 for primary plane */
+	ADE_CH_NUM
+};
+
+enum ade_scale {
+	ADE_SCL1 = 0,
+	ADE_SCL2,
+	ADE_SCL3,
+	ADE_SCL_NUM
+};
+
+enum ade_ctran {
+	ADE_CTRAN1 = 0,
+	ADE_CTRAN2,
+	ADE_CTRAN3,
+	ADE_CTRAN4,
+	ADE_CTRAN5,
+	ADE_CTRAN6,
+	ADE_CTRAN_NUM
+};
+
+enum ade_overlay {
+	ADE_OVLY1 = 0,
+	ADE_OVLY2,
+	ADE_OVLY3,
+	ADE_OVLY_NUM
+};
+
+enum ade_alpha_mode {
+	ADE_ALP_GLOBAL = 0,
+	ADE_ALP_PIXEL,
+	ADE_ALP_PIXEL_AND_GLB
+};
+
+enum ade_alpha_blending_mode {
+	ADE_ALP_MUL_COEFF_0 = 0,	/* alpha */
+	ADE_ALP_MUL_COEFF_1,		/* 1-alpha */
+	ADE_ALP_MUL_COEFF_2,		/* 0 */
+	ADE_ALP_MUL_COEFF_3		/* 1 */
+};
+
+/*
+ * LDI regs relevant enums
+ */
+enum dsi_pclk_en {
+	DSI_PCLK_ON = 0,
+	DSI_PCLK_OFF
+};
+
+enum ldi_output_format {
+	LDI_OUT_RGB_565 = 0,
+	LDI_OUT_RGB_666,
+	LDI_OUT_RGB_888
+};
+
+enum ldi_work_mode {
+	TEST_MODE = 0,
+	NORMAL_MODE
+};
+
+enum ldi_input_source {
+	DISP_SRC_NONE = 0,
+	DISP_SRC_OVLY2,
+	DISP_SRC_DISP,
+	DISP_SRC_ROT,
+	DISP_SRC_SCL2
+};
+
+/*
+ * ADE media bus service relevant enums
+ */
+enum qos_generator_mode {
+	FIXED_MODE = 0,
+	LIMITER_MODE,
+	BYPASS_MODE,
+	REGULATOR_MODE
+};
+
+/*
+ * Register Write/Read Helper functions
+ */
+static inline void ade_update_bits(void __iomem *addr, u32 bit_start,
+				   u32 mask, u32 val)
+{
+	u32 tmp, orig;
+
+	orig = readl(addr);
+	tmp = orig & ~(mask << bit_start);
+	tmp |= (val & mask) << bit_start;
+	writel(tmp, addr);
+}
+
+#endif
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
new file mode 100644
index 000000000000..dbdeb1fc33e3
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -0,0 +1,452 @@
+/*
+ * Hisilicon Hi6220 SoC ADE(Advanced Display Engine)'s crtc&plane driver
+ *
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * Author:
+ *	Xinliang Liu <z.liuxinliang at hisilicon.com>
+ *	Xinliang Liu <xinliang.liu at linaro.org>
+ *	Xinwei Kong <kong.kongxinwei at hisilicon.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.
+ *
+ */
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <video/display_timing.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_crtc.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_atomic.h>
+#include <drm/drm_atomic_helper.h>
+
+#include "kirin_drm_drv.h"
+#include "kirin_ade_reg.h"
+
+#define to_ade_crtc(crtc) \
+	container_of(crtc, struct ade_crtc, base)
+
+struct ade_hw_ctx {
+	void __iomem  *base;
+	struct regmap *noc_regmap;
+	struct clk *ade_core_clk;
+	struct clk *media_noc_clk;
+	struct clk *ade_pix_clk;
+	struct reset_control *reset;
+	bool power_on;
+	int irq;
+};
+
+struct ade_crtc {
+	struct drm_crtc base;
+	struct ade_hw_ctx *ctx;
+	bool enable;
+	u32 out_format;
+};
+
+struct ade_data {
+	struct ade_crtc acrtc;
+	struct ade_hw_ctx ctx;
+};
+
+static void ade_update_reload_bit(void __iomem *base, u32 bit_num, u32 val)
+{
+	u32 bit_ofst, reg_num;
+
+	bit_ofst = bit_num % 32;
+	reg_num = bit_num / 32;
+
+	ade_update_bits(base + ADE_RELOAD_DIS(reg_num), bit_ofst,
+			MASK(1), !!val);
+}
+
+static u32 ade_read_reload_bit(void __iomem *base, u32 bit_num)
+{
+	u32 tmp, bit_ofst, reg_num;
+
+	bit_ofst = bit_num % 32;
+	reg_num = bit_num / 32;
+
+	tmp = readl(base + ADE_RELOAD_DIS(reg_num));
+	return !!(BIT(bit_ofst) & tmp);
+}
+
+static void ade_init(struct ade_hw_ctx *ctx)
+{
+	void __iomem *base = ctx->base;
+
+	/* enable clk gate */
+	ade_update_bits(base + ADE_CTRL1, AUTO_CLK_GATE_EN_OFST,
+			AUTO_CLK_GATE_EN, ADE_ENABLE);
+	/* clear overlay */
+	writel(0, base + ADE_OVLY1_TRANS_CFG);
+	writel(0, base + ADE_OVLY_CTL);
+	writel(0, base + ADE_OVLYX_CTL(ADE_OVLY2));
+	/* clear reset and reload regs */
+	writel(MASK(32), base + ADE_SOFT_RST_SEL(0));
+	writel(MASK(32), base + ADE_SOFT_RST_SEL(1));
+	writel(MASK(32), base + ADE_RELOAD_DIS(0));
+	writel(MASK(32), base + ADE_RELOAD_DIS(1));
+	/* for video mode, that ade registers
+	 * became effective at frame end
+	 */
+	ade_update_bits(base + ADE_CTRL, FRM_END_START_OFST,
+			FRM_END_START_MASK, REG_EFFECTIVE_IN_ADEEN_FRMEND);
+}
+
+static void ade_ldi_set_mode(struct ade_crtc *acrtc,
+			     struct drm_display_mode *mode,
+			     struct drm_display_mode *adj_mode)
+{
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->base;
+	u32 width = mode->hdisplay;
+	u32 height = mode->vdisplay;
+	u32 hfp, hbp, hsw, vfp, vbp, vsw;
+	u32 plr_flags;
+	int ret;
+
+	plr_flags = (mode->flags & DRM_MODE_FLAG_NVSYNC) ? FLAG_NVSYNC : 0;
+	plr_flags |= (mode->flags & DRM_MODE_FLAG_NHSYNC) ? FLAG_NHSYNC : 0;
+	hfp = mode->hsync_start - mode->hdisplay;
+	hbp = mode->htotal - mode->hsync_end;
+	hsw = mode->hsync_end - mode->hsync_start;
+	vfp = mode->vsync_start - mode->vdisplay;
+	vbp = mode->vtotal - mode->vsync_end;
+	vsw = mode->vsync_end - mode->vsync_start;
+	if (vsw > 15) {
+		DRM_DEBUG_DRIVER("vsw exceeded 15\n");
+		vsw = 15;
+	}
+
+	writel((hbp << HBP_OFST) | hfp, base + LDI_HRZ_CTRL0);
+	 /* the configured value is actual value - 1 */
+	writel(hsw - 1, base + LDI_HRZ_CTRL1);
+	writel((vbp << VBP_OFST) | vfp, base + LDI_VRT_CTRL0);
+	 /* the configured value is actual value - 1 */
+	writel(vsw - 1, base + LDI_VRT_CTRL1);
+	 /* the configured value is actual value - 1 */
+	writel(((height - 1) << VSIZE_OFST) | (width - 1),
+	       base + LDI_DSP_SIZE);
+	writel(plr_flags, base + LDI_PLR_CTRL);
+
+	/* Success should be guaranteed in mode_valid call back,
+	 * so failer shouldn't happen here
+	 */
+	ret = clk_set_rate(ctx->ade_pix_clk, mode->clock * 1000);
+	if (ret)
+		DRM_ERROR("failed to set pixel clk %dHz (%d)\n",
+			  mode->clock * 1000, ret);
+	adj_mode->clock = clk_get_rate(ctx->ade_pix_clk) / 1000;
+
+	/* ctran6 setting */
+	writel(CTRAN_BYPASS_ON, base + ADE_CTRAN_DIS(ADE_CTRAN6));
+	 /* the configured value is actual value - 1 */
+	writel(width * height - 1, base + ADE_CTRAN_IMAGE_SIZE(ADE_CTRAN6));
+	ade_update_reload_bit(base, CTRAN_OFST + ADE_CTRAN6, 0);
+
+	DRM_DEBUG_DRIVER("set mode: %dx%d\n", width, height);
+}
+
+static int ade_power_up(struct ade_hw_ctx *ctx)
+{
+	int ret;
+
+	ret = clk_prepare_enable(ctx->media_noc_clk);
+	if (ret) {
+		DRM_ERROR("failed to enable media_noc_clk (%d)\n", ret);
+		return ret;
+	}
+
+	ret = reset_control_deassert(ctx->reset);
+	if (ret) {
+		DRM_ERROR("failed to deassert reset\n");
+		return ret;
+	}
+
+	ret = clk_prepare_enable(ctx->ade_core_clk);
+	if (ret) {
+		DRM_ERROR("failed to enable ade_core_clk (%d)\n", ret);
+		return ret;
+	}
+
+	ade_init(ctx);
+	ctx->power_on = true;
+	return 0;
+}
+
+static void ade_power_down(struct ade_hw_ctx *ctx)
+{
+	void __iomem *base = ctx->base;
+
+	writel(ADE_DISABLE, base + LDI_CTRL);
+	/* dsi pixel off */
+	writel(DSI_PCLK_OFF, base + LDI_HDMI_DSI_GT);
+
+	clk_disable_unprepare(ctx->ade_core_clk);
+	reset_control_assert(ctx->reset);
+	clk_disable_unprepare(ctx->media_noc_clk);
+	ctx->power_on = false;
+}
+
+static void ade_set_medianoc_qos(struct ade_crtc *acrtc)
+{
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	struct regmap *map = ctx->noc_regmap;
+
+	regmap_update_bits(map, ADE0_QOSGENERATOR_MODE,
+			   QOSGENERATOR_MODE_MASK, BYPASS_MODE);
+	regmap_update_bits(map, ADE0_QOSGENERATOR_EXTCONTROL,
+			   SOCKET_QOS_EN, SOCKET_QOS_EN);
+
+	regmap_update_bits(map, ADE1_QOSGENERATOR_MODE,
+			   QOSGENERATOR_MODE_MASK, BYPASS_MODE);
+	regmap_update_bits(map, ADE1_QOSGENERATOR_EXTCONTROL,
+			   SOCKET_QOS_EN, SOCKET_QOS_EN);
+}
+
+static void ade_display_enable(struct ade_crtc *acrtc)
+{
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->base;
+	u32 out_fmt = acrtc->out_format;
+
+	/* display source setting */
+	writel(DISP_SRC_OVLY2, base + ADE_DISP_SRC_CFG);
+
+	/* enable ade */
+	writel(ADE_ENABLE, base + ADE_EN);
+	/* enable ldi */
+	writel(NORMAL_MODE, base + LDI_WORK_MODE);
+	writel((out_fmt << BPP_OFST) | DATA_GATE_EN | LDI_EN,
+	       base + LDI_CTRL);
+	/* dsi pixel on */
+	writel(DSI_PCLK_ON, base + LDI_HDMI_DSI_GT);
+}
+
+static void ade_crtc_enable(struct drm_crtc *crtc)
+{
+	struct ade_crtc *acrtc = to_ade_crtc(crtc);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	int ret;
+
+	if (acrtc->enable)
+		return;
+
+	if (!ctx->power_on) {
+		ret = ade_power_up(ctx);
+		if (ret)
+			return;
+	}
+
+	ade_set_medianoc_qos(acrtc);
+	ade_display_enable(acrtc);
+	acrtc->enable = true;
+}
+
+static void ade_crtc_disable(struct drm_crtc *crtc)
+{
+	struct ade_crtc *acrtc = to_ade_crtc(crtc);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+
+	if (!acrtc->enable)
+		return;
+
+	ade_power_down(ctx);
+	acrtc->enable = false;
+}
+
+static int ade_crtc_atomic_check(struct drm_crtc *crtc,
+				 struct drm_crtc_state *state)
+{
+	/* do nothing */
+	return 0;
+}
+
+static void ade_crtc_mode_set_nofb(struct drm_crtc *crtc)
+{
+	struct ade_crtc *acrtc = to_ade_crtc(crtc);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	struct drm_display_mode *mode = &crtc->state->mode;
+	struct drm_display_mode *adj_mode = &crtc->state->adjusted_mode;
+
+	if (!ctx->power_on)
+		(void)ade_power_up(ctx);
+	ade_ldi_set_mode(acrtc, mode, adj_mode);
+}
+
+static void ade_crtc_atomic_begin(struct drm_crtc *crtc,
+				  struct drm_crtc_state *old_state)
+{
+	struct ade_crtc *acrtc = to_ade_crtc(crtc);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+
+	if (!ctx->power_on)
+		(void)ade_power_up(ctx);
+}
+
+static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
+				  struct drm_crtc_state *old_state)
+
+{
+	struct ade_crtc *acrtc = to_ade_crtc(crtc);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->base;
+
+	/* only crtc is eanbled regs take effect */
+	if (acrtc->enable) {
+		/* flush ade regitsters */
+		writel(ADE_ENABLE, base + ADE_EN);
+	}
+}
+
+static const struct drm_crtc_helper_funcs ade_crtc_helper_funcs = {
+	.enable		= ade_crtc_enable,
+	.disable	= ade_crtc_disable,
+	.atomic_check	= ade_crtc_atomic_check,
+	.mode_set_nofb	= ade_crtc_mode_set_nofb,
+	.atomic_begin	= ade_crtc_atomic_begin,
+	.atomic_flush	= ade_crtc_atomic_flush,
+};
+
+static const struct drm_crtc_funcs ade_crtc_funcs = {
+	.destroy	= drm_crtc_cleanup,
+	.set_config	= drm_atomic_helper_set_config,
+	.page_flip	= drm_atomic_helper_page_flip,
+	.reset		= drm_atomic_helper_crtc_reset,
+	.set_property = drm_atomic_helper_crtc_set_property,
+	.atomic_duplicate_state	= drm_atomic_helper_crtc_duplicate_state,
+	.atomic_destroy_state	= drm_atomic_helper_crtc_destroy_state,
+};
+
+static int ade_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
+			 struct drm_plane *plane)
+{
+	struct kirin_drm_private *priv = dev->dev_private;
+	struct device_node *port;
+	int ret;
+
+	/* set crtc port so that
+	 * drm_of_find_possible_crtcs call works
+	 */
+	port = of_get_child_by_name(dev->dev->of_node, "port");
+	if (!port) {
+		DRM_ERROR("no port node found in %s\n",
+			  dev->dev->of_node->full_name);
+		return -EINVAL;
+	}
+	of_node_put(port);
+	crtc->port = port;
+
+	ret = drm_crtc_init_with_planes(dev, crtc, plane, NULL,
+					&ade_crtc_funcs, NULL);
+	if (ret) {
+		DRM_ERROR("failed to init crtc.\n");
+		return ret;
+	}
+
+	drm_crtc_helper_add(crtc, &ade_crtc_helper_funcs);
+	priv->crtc[drm_crtc_index(crtc)] = crtc;
+
+	return 0;
+}
+
+static int ade_dts_parse(struct platform_device *pdev, struct ade_hw_ctx *ctx)
+{
+	struct resource *res;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = pdev->dev.of_node;
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ade_base");
+	ctx->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(ctx->base)) {
+		DRM_ERROR("failed to remap ade io base\n");
+		return  PTR_ERR(ctx->base);
+	}
+
+	ctx->reset = devm_reset_control_get(dev, NULL);
+	if (IS_ERR(ctx->reset))
+		return PTR_ERR(ctx->reset);
+
+	ctx->noc_regmap =
+		syscon_regmap_lookup_by_phandle(np, "hisilicon,noc-syscon");
+	if (IS_ERR(ctx->noc_regmap)) {
+		DRM_ERROR("failed to get noc regmap\n");
+		return PTR_ERR(ctx->noc_regmap);
+	}
+
+	ctx->irq = platform_get_irq(pdev, 0);
+	if (ctx->irq < 0) {
+		DRM_ERROR("failed to get irq\n");
+		return -ENODEV;
+	}
+
+	ctx->ade_core_clk = devm_clk_get(dev, "clk_ade_core");
+	if (!ctx->ade_core_clk) {
+		DRM_ERROR("failed to parse clk ADE_CORE\n");
+		return -ENODEV;
+	}
+
+	ctx->media_noc_clk = devm_clk_get(dev, "clk_codec_jpeg");
+	if (!ctx->media_noc_clk) {
+		DRM_ERROR("failed to parse clk CODEC_JPEG\n");
+	    return -ENODEV;
+	}
+
+	ctx->ade_pix_clk = devm_clk_get(dev, "clk_ade_pix");
+	if (!ctx->ade_pix_clk) {
+		DRM_ERROR("failed to parse clk ADE_PIX\n");
+	    return -ENODEV;
+	}
+
+	return 0;
+}
+
+int ade_drm_init(struct drm_device *dev)
+{
+	struct platform_device *pdev = dev->platformdev;
+	struct ade_data *ade;
+	struct ade_hw_ctx *ctx;
+	struct ade_crtc *acrtc;
+	int ret;
+
+	ade = devm_kzalloc(dev->dev, sizeof(*ade), GFP_KERNEL);
+	if (!ade) {
+		DRM_ERROR("failed to alloc ade_data\n");
+		return -ENOMEM;
+	}
+	platform_set_drvdata(pdev, ade);
+
+	ctx = &ade->ctx;
+	acrtc = &ade->acrtc;
+	acrtc->ctx = ctx;
+	acrtc->out_format = LDI_OUT_RGB_888;
+
+	ret = ade_dts_parse(pdev, ctx);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+void ade_drm_cleanup(struct drm_device *dev)
+{
+	struct platform_device *pdev = dev->platformdev;
+	struct ade_data *ade = platform_get_drvdata(pdev);
+	struct drm_crtc *crtc = &ade->acrtc.base;
+
+	drm_crtc_cleanup(crtc);
+}
+
+const struct kirin_dc_ops ade_dc_ops = {
+	.init = ade_drm_init,
+	.cleanup = ade_drm_cleanup
+};
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 789ebd1f5922..055729c1889c 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -30,8 +30,12 @@ static struct kirin_dc_ops *dc_ops;
 
 static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
+	struct kirin_drm_private *priv = dev->dev_private;
+
 	dc_ops->cleanup(dev);
 	drm_mode_config_cleanup(dev);
+	devm_kfree(dev->dev, priv);
+	dev->dev_private = NULL;
 
 	return 0;
 }
@@ -55,8 +59,14 @@ static void kirin_drm_mode_config_init(struct drm_device *dev)
 
 static int kirin_drm_kms_init(struct drm_device *dev)
 {
+	struct kirin_drm_private *priv;
 	int ret;
 
+	priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	dev->dev_private = priv;
 	dev_set_drvdata(dev->dev, dev);
 
 	/* dev->mode_config initialization */
@@ -84,6 +94,8 @@ err_dc_cleanup:
 	dc_ops->cleanup(dev);
 err_mode_config_cleanup:
 	drm_mode_config_cleanup(dev);
+	devm_kfree(dev->dev, priv);
+	dev->dev_private = NULL;
 
 	return ret;
 }
@@ -221,6 +233,9 @@ static const struct component_master_ops kirin_drm_ops = {
 };
 
 static const struct of_device_id kirin_drm_dt_ids[] = {
+	{ .compatible = "hisilicon,hi6220-ade",
+	  .data = &ade_dc_ops,
+	},
 	{ /* end node */ },
 };
 MODULE_DEVICE_TABLE(of, kirin_drm_dt_ids);
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 75e9d82356d4..5a05ad6a81db 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -11,10 +11,18 @@
 #ifndef __KIRIN_DRM_DRV_H__
 #define __KIRIN_DRM_DRV_H__
 
+#define MAX_CRTC	2
+
 /* display controller init/cleanup ops */
 struct kirin_dc_ops {
 	int (*init)(struct drm_device *dev);
 	void (*cleanup)(struct drm_device *dev);
 };
 
+struct kirin_drm_private {
+	struct drm_crtc *crtc[MAX_CRTC];
+};
+
+extern const struct kirin_dc_ops ade_dc_ops;
+
 #endif /* __KIRIN_DRM_DRV_H__ */
-- 
1.9.1



From xinliang.liu at linaro.org  Mon Feb 22 19:00:24 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Tue, 23 Feb 2016 11:00:24 +0800
Subject: [PATCH v5 04/11] drm/hisilicon: Add plane driver for ADE
In-Reply-To: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
References: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456196431-19923-5-git-send-email-xinliang.liu@linaro.org>

Add plane funcs and helper funcs for ADE.

v5: None.
v4: None.
v3:
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 535 +++++++++++++++++++++++-
 1 file changed, 534 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index dbdeb1fc33e3..fae5f0afadb8 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -27,13 +27,23 @@
 #include <drm/drm_crtc_helper.h>
 #include <drm/drm_atomic.h>
 #include <drm/drm_atomic_helper.h>
+#include <drm/drm_plane_helper.h>
+#include <drm/drm_gem_cma_helper.h>
+#include <drm/drm_fb_cma_helper.h>
 
 #include "kirin_drm_drv.h"
 #include "kirin_ade_reg.h"
 
+#define PRIMARY_CH	ADE_CH1 /* primary plane */
+#define OUT_OVLY	ADE_OVLY2 /* output overlay compositor */
+#define ADE_DEBUG	1
+
 #define to_ade_crtc(crtc) \
 	container_of(crtc, struct ade_crtc, base)
 
+#define to_ade_plane(plane) \
+	container_of(plane, struct ade_plane, base)
+
 struct ade_hw_ctx {
 	void __iomem  *base;
 	struct regmap *noc_regmap;
@@ -52,11 +62,76 @@ struct ade_crtc {
 	u32 out_format;
 };
 
+struct ade_plane {
+	struct drm_plane base;
+	void *ctx;
+	u8 ch; /* channel */
+};
+
 struct ade_data {
 	struct ade_crtc acrtc;
+	struct ade_plane aplane[ADE_CH_NUM];
 	struct ade_hw_ctx ctx;
 };
 
+/* ade-format info: */
+struct ade_format {
+	u32 pixel_format;
+	enum ade_fb_format ade_format;
+};
+
+static const struct ade_format ade_formats[] = {
+	/* 16bpp RGB: */
+	{ DRM_FORMAT_RGB565, ADE_RGB_565 },
+	{ DRM_FORMAT_BGR565, ADE_BGR_565 },
+	/* 24bpp RGB: */
+	{ DRM_FORMAT_RGB888, ADE_RGB_888 },
+	{ DRM_FORMAT_BGR888, ADE_BGR_888 },
+	/* 32bpp [A]RGB: */
+	{ DRM_FORMAT_XRGB8888, ADE_XRGB_8888 },
+	{ DRM_FORMAT_XBGR8888, ADE_XBGR_8888 },
+	{ DRM_FORMAT_RGBA8888, ADE_RGBA_8888 },
+	{ DRM_FORMAT_BGRA8888, ADE_BGRA_8888 },
+	{ DRM_FORMAT_ARGB8888, ADE_ARGB_8888 },
+	{ DRM_FORMAT_ABGR8888, ADE_ABGR_8888 },
+};
+
+static const u32 channel_formats1[] = {
+	/* channel 1,2,3,4 */
+	DRM_FORMAT_RGB565, DRM_FORMAT_BGR565, DRM_FORMAT_RGB888,
+	DRM_FORMAT_BGR888, DRM_FORMAT_XRGB8888, DRM_FORMAT_XBGR8888,
+	DRM_FORMAT_RGBA8888, DRM_FORMAT_BGRA8888, DRM_FORMAT_ARGB8888,
+	DRM_FORMAT_ABGR8888
+};
+
+u32 ade_get_channel_formats(u8 ch, const u32 **formats)
+{
+	switch (ch) {
+	case ADE_CH1:
+		*formats = channel_formats1;
+		return ARRAY_SIZE(channel_formats1);
+	default:
+		DRM_ERROR("no this channel %d\n", ch);
+		*formats = NULL;
+		return 0;
+	}
+}
+
+/* convert from fourcc format to ade format */
+static u32 ade_get_format(u32 pixel_format)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(ade_formats); i++)
+		if (ade_formats[i].pixel_format == pixel_format)
+			return ade_formats[i].ade_format;
+
+	/* not found */
+	DRM_ERROR("Not found pixel format!!fourcc_format= %d\n",
+		  pixel_format);
+	return ADE_FORMAT_NOT_SUPPORT;
+}
+
 static void ade_update_reload_bit(void __iomem *base, u32 bit_num, u32 val)
 {
 	u32 bit_ofst, reg_num;
@@ -89,7 +164,7 @@ static void ade_init(struct ade_hw_ctx *ctx)
 	/* clear overlay */
 	writel(0, base + ADE_OVLY1_TRANS_CFG);
 	writel(0, base + ADE_OVLY_CTL);
-	writel(0, base + ADE_OVLYX_CTL(ADE_OVLY2));
+	writel(0, base + ADE_OVLYX_CTL(OUT_OVLY));
 	/* clear reset and reload regs */
 	writel(MASK(32), base + ADE_SOFT_RST_SEL(0));
 	writel(MASK(32), base + ADE_SOFT_RST_SEL(1));
@@ -147,6 +222,10 @@ static void ade_ldi_set_mode(struct ade_crtc *acrtc,
 			  mode->clock * 1000, ret);
 	adj_mode->clock = clk_get_rate(ctx->ade_pix_clk) / 1000;
 
+	/* set overlay compositor output size */
+	writel(((width - 1) << OUTPUT_XSIZE_OFST) | (height - 1),
+	       base + ADE_OVLY_OUTPUT_SIZE(OUT_OVLY));
+
 	/* ctran6 setting */
 	writel(CTRAN_BYPASS_ON, base + ADE_CTRAN_DIS(ADE_CTRAN6));
 	 /* the configured value is actual value - 1 */
@@ -219,6 +298,10 @@ static void ade_display_enable(struct ade_crtc *acrtc)
 	void __iomem *base = ctx->base;
 	u32 out_fmt = acrtc->out_format;
 
+	/* enable output overlay compositor */
+	writel(ADE_ENABLE, base + ADE_OVLYX_CTL(OUT_OVLY));
+	ade_update_reload_bit(base, OVLY_OFST + OUT_OVLY, 0);
+
 	/* display source setting */
 	writel(DISP_SRC_OVLY2, base + ADE_DISP_SRC_CFG);
 
@@ -232,6 +315,97 @@ static void ade_display_enable(struct ade_crtc *acrtc)
 	writel(DSI_PCLK_ON, base + LDI_HDMI_DSI_GT);
 }
 
+#if ADE_DEBUG
+static void ade_rdma_dump_regs(void __iomem *base, u32 ch)
+{
+	u32 reg_ctrl, reg_addr, reg_size, reg_stride, reg_space, reg_en;
+	u32 val;
+
+	reg_ctrl = RD_CH_CTRL(ch);
+	reg_addr = RD_CH_ADDR(ch);
+	reg_size = RD_CH_SIZE(ch);
+	reg_stride = RD_CH_STRIDE(ch);
+	reg_space = RD_CH_SPACE(ch);
+	reg_en = RD_CH_EN(ch);
+
+	val = ade_read_reload_bit(base, RDMA_OFST + ch);
+	DRM_DEBUG_DRIVER("[rdma%d]: reload(%d)\n", ch + 1, val);
+	val = readl(base + reg_ctrl);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_ctrl(0x%08x)\n", ch + 1, val);
+	val = readl(base + reg_addr);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_addr(0x%08x)\n", ch + 1, val);
+	val = readl(base + reg_size);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_size(0x%08x)\n", ch + 1, val);
+	val = readl(base + reg_stride);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_stride(0x%08x)\n", ch + 1, val);
+	val = readl(base + reg_space);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_space(0x%08x)\n", ch + 1, val);
+	val = readl(base + reg_en);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_en(0x%08x)\n", ch + 1, val);
+}
+
+static void ade_clip_dump_regs(void __iomem *base, u32 ch)
+{
+	u32 val;
+
+	val = ade_read_reload_bit(base, CLIP_OFST + ch);
+	DRM_DEBUG_DRIVER("[clip%d]: reload(%d)\n", ch + 1, val);
+	val = readl(base + ADE_CLIP_DISABLE(ch));
+	DRM_DEBUG_DRIVER("[clip%d]: reg_clip_disable(0x%08x)\n", ch + 1, val);
+	val = readl(base + ADE_CLIP_SIZE0(ch));
+	DRM_DEBUG_DRIVER("[clip%d]: reg_clip_size0(0x%08x)\n", ch + 1, val);
+	val = readl(base + ADE_CLIP_SIZE1(ch));
+	DRM_DEBUG_DRIVER("[clip%d]: reg_clip_size1(0x%08x)\n", ch + 1, val);
+}
+
+static void ade_compositor_routing_dump_regs(void __iomem *base, u32 ch)
+{
+	u8 ovly_ch = 0; /* TODO: Only primary plane now */
+	u32 val;
+
+	val = readl(base + ADE_OVLY_CH_XY0(ovly_ch));
+	DRM_DEBUG_DRIVER("[overlay ch%d]: reg_ch_xy0(0x%08x)\n", ovly_ch, val);
+	val = readl(base + ADE_OVLY_CH_XY1(ovly_ch));
+	DRM_DEBUG_DRIVER("[overlay ch%d]: reg_ch_xy1(0x%08x)\n", ovly_ch, val);
+	val = readl(base + ADE_OVLY_CH_CTL(ovly_ch));
+	DRM_DEBUG_DRIVER("[overlay ch%d]: reg_ch_ctl(0x%08x)\n", ovly_ch, val);
+}
+
+static void ade_dump_overlay_compositor_regs(void __iomem *base, u32 comp)
+{
+	u32 val;
+
+	val = ade_read_reload_bit(base, OVLY_OFST + comp);
+	DRM_DEBUG_DRIVER("[overlay%d]: reload(%d)\n", comp + 1, val);
+	writel(ADE_ENABLE, base + ADE_OVLYX_CTL(comp));
+	DRM_DEBUG_DRIVER("[overlay%d]: reg_ctl(0x%08x)\n", comp + 1, val);
+	val = readl(base + ADE_OVLY_CTL);
+	DRM_DEBUG_DRIVER("ovly_ctl(0x%08x)\n", val);
+}
+
+static void ade_dump_regs(void __iomem *base)
+{
+	u32 i;
+
+	/* dump channel regs */
+	for (i = 0; i < ADE_CH_NUM; i++) {
+		/* dump rdma regs */
+		ade_rdma_dump_regs(base, i);
+
+		/* dump clip regs */
+		ade_clip_dump_regs(base, i);
+
+		/* dump compositor routing regs */
+		ade_compositor_routing_dump_regs(base, i);
+	}
+
+	/* dump overlay compositor regs */
+	ade_dump_overlay_compositor_regs(base, OUT_OVLY);
+}
+#else
+static void ade_dump_regs(void __iomem *base) { }
+#endif
+
 static void ade_crtc_enable(struct drm_crtc *crtc)
 {
 	struct ade_crtc *acrtc = to_ade_crtc(crtc);
@@ -249,6 +423,7 @@ static void ade_crtc_enable(struct drm_crtc *crtc)
 
 	ade_set_medianoc_qos(acrtc);
 	ade_display_enable(acrtc);
+	ade_dump_regs(ctx->base);
 	acrtc->enable = true;
 }
 
@@ -303,6 +478,7 @@ static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
 
 	/* only crtc is eanbled regs take effect */
 	if (acrtc->enable) {
+		ade_dump_regs(base);
 		/* flush ade regitsters */
 		writel(ADE_ENABLE, base + ADE_EN);
 	}
@@ -359,6 +535,338 @@ static int ade_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
 	return 0;
 }
 
+static void ade_rdma_set(void __iomem *base, struct drm_framebuffer *fb,
+			 u32 ch, u32 y, u32 in_h, u32 fmt)
+{
+	struct drm_gem_cma_object *obj = drm_fb_cma_get_gem_obj(fb, 0);
+	u32 reg_ctrl, reg_addr, reg_size, reg_stride, reg_space, reg_en;
+	u32 stride = fb->pitches[0];
+	u32 addr = (u32)obj->paddr + y * stride;
+
+	DRM_DEBUG_DRIVER("rdma%d: (y=%d, height=%d), stride=%d, paddr=0x%x\n",
+			 ch + 1, y, in_h, stride, (u32)obj->paddr);
+	DRM_DEBUG_DRIVER("addr=0x%x, fb:%dx%d, pixel_format=%d(%s)\n",
+			 addr, fb->width, fb->height, fmt,
+			 drm_get_format_name(fb->pixel_format));
+
+	/* get reg offset */
+	reg_ctrl = RD_CH_CTRL(ch);
+	reg_addr = RD_CH_ADDR(ch);
+	reg_size = RD_CH_SIZE(ch);
+	reg_stride = RD_CH_STRIDE(ch);
+	reg_space = RD_CH_SPACE(ch);
+	reg_en = RD_CH_EN(ch);
+
+	/*
+	 * TODO: set rotation
+	 */
+	writel((fmt << 16) & 0x1f0000, base + reg_ctrl);
+	writel(addr, base + reg_addr);
+	writel((in_h << 16) | stride, base + reg_size);
+	writel(stride, base + reg_stride);
+	writel(in_h * stride, base + reg_space);
+	writel(ADE_ENABLE, base + reg_en);
+	ade_update_reload_bit(base, RDMA_OFST + ch, 0);
+}
+
+static void ade_rdma_disable(void __iomem *base, u32 ch)
+{
+	u32 reg_en;
+
+	/* get reg offset */
+	reg_en = RD_CH_EN(ch);
+	writel(0, base + reg_en);
+	ade_update_reload_bit(base, RDMA_OFST + ch, 1);
+}
+
+static void ade_clip_set(void __iomem *base, u32 ch, u32 fb_w, u32 x,
+			 u32 in_w, u32 in_h)
+{
+	u32 disable_val;
+	u32 clip_left;
+	u32 clip_right;
+
+	/*
+	 * clip width, no need to clip height
+	 */
+	if (fb_w == in_w) { /* bypass */
+		disable_val = 1;
+		clip_left = 0;
+		clip_right = 0;
+	} else {
+		disable_val = 0;
+		clip_left = x;
+		clip_right = fb_w - (x + in_w) - 1;
+	}
+
+	DRM_DEBUG_DRIVER("clip%d: clip_left=%d, clip_right=%d\n",
+			 ch + 1, clip_left, clip_right);
+
+	writel(disable_val, base + ADE_CLIP_DISABLE(ch));
+	writel((fb_w - 1) << 16 | (in_h - 1), base + ADE_CLIP_SIZE0(ch));
+	writel(clip_left << 16 | clip_right, base + ADE_CLIP_SIZE1(ch));
+	ade_update_reload_bit(base, CLIP_OFST + ch, 0);
+}
+
+static void ade_clip_disable(void __iomem *base, u32 ch)
+{
+	writel(1, base + ADE_CLIP_DISABLE(ch));
+	ade_update_reload_bit(base, CLIP_OFST + ch, 1);
+}
+
+static bool has_Alpha_channel(int format)
+{
+	switch (format) {
+	case ADE_ARGB_8888:
+	case ADE_ABGR_8888:
+	case ADE_RGBA_8888:
+	case ADE_BGRA_8888:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static void ade_get_blending_params(u32 fmt, u8 glb_alpha, u8 *alp_mode,
+				    u8 *alp_sel, u8 *under_alp_sel)
+{
+	bool has_alpha = has_Alpha_channel(fmt);
+
+	/*
+	 * get alp_mode
+	 */
+	if (has_alpha && glb_alpha < 255)
+		*alp_mode = ADE_ALP_PIXEL_AND_GLB;
+	else if (has_alpha)
+		*alp_mode = ADE_ALP_PIXEL;
+	else
+		*alp_mode = ADE_ALP_GLOBAL;
+
+	/*
+	 * get alp sel
+	 */
+	*alp_sel = ADE_ALP_MUL_COEFF_3; /* 1 */
+	*under_alp_sel = ADE_ALP_MUL_COEFF_2; /* 0 */
+}
+
+static void ade_compositor_routing_set(void __iomem *base, u8 ch,
+				       u32 x0, u32 y0,
+				       u32 in_w, u32 in_h, u32 fmt)
+{
+	u8 ovly_ch = 0; /* TODO: This is the zpos, only one plane now */
+	u8 glb_alpha = 255;
+	u32 x1 = x0 + in_w - 1;
+	u32 y1 = y0 + in_h - 1;
+	u32 val;
+	u8 alp_sel;
+	u8 under_alp_sel;
+	u8 alp_mode;
+
+	ade_get_blending_params(fmt, glb_alpha, &alp_mode, &alp_sel,
+				&under_alp_sel);
+
+	/* overlay routing setting
+	 */
+	writel(x0 << 16 | y0, base + ADE_OVLY_CH_XY0(ovly_ch));
+	writel(x1 << 16 | y1, base + ADE_OVLY_CH_XY1(ovly_ch));
+	val = (ch + 1) << CH_SEL_OFST | BIT(CH_EN_OFST) |
+		alp_sel << CH_ALP_SEL_OFST |
+		under_alp_sel << CH_UNDER_ALP_SEL_OFST |
+		glb_alpha << CH_ALP_GBL_OFST |
+		alp_mode << CH_ALP_MODE_OFST;
+	writel(val, base + ADE_OVLY_CH_CTL(ovly_ch));
+	/* connect this plane/channel to overlay2 compositor */
+	ade_update_bits(base + ADE_OVLY_CTL, CH_OVLY_SEL_OFST(ovly_ch),
+			CH_OVLY_SEL_MASK, CH_OVLY_SEL_VAL(OUT_OVLY));
+}
+
+static void ade_compositor_routing_disable(void __iomem *base, u32 ch)
+{
+	u8 ovly_ch = 0; /* TODO: Only primary plane now */
+
+	/* disable this plane/channel */
+	ade_update_bits(base + ADE_OVLY_CH_CTL(ovly_ch), CH_EN_OFST,
+			MASK(1), 0);
+	/* dis-connect this plane/channel of overlay2 compositor */
+	ade_update_bits(base + ADE_OVLY_CTL, CH_OVLY_SEL_OFST(ovly_ch),
+			CH_OVLY_SEL_MASK, 0);
+}
+
+/*
+ * Typicaly, a channel looks like: DMA-->clip-->scale-->ctrans-->compositor
+ */
+static void ade_update_channel(struct ade_plane *aplane,
+			       struct drm_framebuffer *fb, int crtc_x,
+			       int crtc_y, unsigned int crtc_w,
+			       unsigned int crtc_h, u32 src_x,
+			       u32 src_y, u32 src_w, u32 src_h)
+{
+	struct ade_hw_ctx *ctx = aplane->ctx;
+	void __iomem *base = ctx->base;
+	u32 fmt = ade_get_format(fb->pixel_format);
+	u32 ch = aplane->ch;
+	u32 in_w;
+	u32 in_h;
+
+	DRM_DEBUG_DRIVER("channel%d: src:(%d, %d)-%dx%d, crtc:(%d, %d)-%dx%d",
+			 ch + 1, src_x, src_y, src_w, src_h,
+			 crtc_x, crtc_y, crtc_w, crtc_h);
+
+	/* 1) DMA setting */
+	in_w = src_w;
+	in_h = src_h;
+	ade_rdma_set(base, fb, ch, src_y, in_h, fmt);
+
+	/* 2) clip setting */
+	ade_clip_set(base, ch, fb->width, src_x, in_w, in_h);
+
+	/* 3) TODO: scale setting for overlay planes */
+
+	/* 4) TODO: ctran/csc setting for overlay planes */
+
+	/* 5) compositor routing setting */
+	ade_compositor_routing_set(base, ch, crtc_x, crtc_y, in_w, in_h, fmt);
+}
+
+static void ade_disable_channel(struct ade_plane *aplane)
+{
+	struct ade_hw_ctx *ctx = aplane->ctx;
+	void __iomem *base = ctx->base;
+	u32 ch = aplane->ch;
+
+	DRM_DEBUG_DRIVER("disable channel%d\n", ch + 1);
+
+	/* disable read DMA */
+	ade_rdma_disable(base, ch);
+
+	/* disable clip */
+	ade_clip_disable(base, ch);
+
+	/* disable compositor routing */
+	ade_compositor_routing_disable(base, ch);
+}
+
+static int ade_plane_prepare_fb(struct drm_plane *plane,
+				const struct drm_plane_state *new_state)
+{
+	/* do nothing */
+	return 0;
+}
+
+static void ade_plane_cleanup_fb(struct drm_plane *plane,
+				 const struct drm_plane_state *old_state)
+{
+	/* do nothing */
+}
+
+static int ade_plane_atomic_check(struct drm_plane *plane,
+				  struct drm_plane_state *state)
+{
+	struct drm_framebuffer *fb = state->fb;
+	struct drm_crtc *crtc = state->crtc;
+	struct drm_crtc_state *crtc_state;
+	u32 src_x = state->src_x >> 16;
+	u32 src_y = state->src_y >> 16;
+	u32 src_w = state->src_w >> 16;
+	u32 src_h = state->src_h >> 16;
+	int crtc_x = state->crtc_x;
+	int crtc_y = state->crtc_y;
+	u32 crtc_w = state->crtc_w;
+	u32 crtc_h = state->crtc_h;
+	u32 fmt;
+
+	if (!crtc || !fb)
+		return 0;
+
+	fmt = ade_get_format(fb->pixel_format);
+	if (fmt == ADE_FORMAT_NOT_SUPPORT)
+		return -EINVAL;
+
+	crtc_state = drm_atomic_get_crtc_state(state->state, crtc);
+	if (IS_ERR(crtc_state))
+		return PTR_ERR(crtc_state);
+
+	if (src_w != crtc_w || src_h != crtc_h) {
+		DRM_ERROR("Scale not support!!!\n");
+		return -EINVAL;
+	}
+
+	if (src_x + src_w > fb->width ||
+	    src_y + src_h > fb->height)
+		return -EINVAL;
+
+	if (crtc_x < 0 || crtc_y < 0)
+		return -EINVAL;
+
+	if (crtc_x + crtc_w > crtc_state->adjusted_mode.hdisplay ||
+	    crtc_y + crtc_h > crtc_state->adjusted_mode.vdisplay)
+		return -EINVAL;
+
+	return 0;
+}
+
+static void ade_plane_atomic_update(struct drm_plane *plane,
+				    struct drm_plane_state *old_state)
+{
+	struct drm_plane_state	*state	= plane->state;
+	struct ade_plane *aplane = to_ade_plane(plane);
+
+	ade_update_channel(aplane, state->fb, state->crtc_x, state->crtc_y,
+			   state->crtc_w, state->crtc_h,
+			   state->src_x >> 16, state->src_y >> 16,
+			   state->src_w >> 16, state->src_h >> 16);
+}
+
+static void ade_plane_atomic_disable(struct drm_plane *plane,
+				     struct drm_plane_state *old_state)
+{
+	struct ade_plane *aplane = to_ade_plane(plane);
+
+	ade_disable_channel(aplane);
+}
+
+static const struct drm_plane_helper_funcs ade_plane_helper_funcs = {
+	.prepare_fb = ade_plane_prepare_fb,
+	.cleanup_fb = ade_plane_cleanup_fb,
+	.atomic_check = ade_plane_atomic_check,
+	.atomic_update = ade_plane_atomic_update,
+	.atomic_disable = ade_plane_atomic_disable,
+};
+
+static struct drm_plane_funcs ade_plane_funcs = {
+	.update_plane	= drm_atomic_helper_update_plane,
+	.disable_plane	= drm_atomic_helper_disable_plane,
+	.set_property = drm_atomic_helper_plane_set_property,
+	.destroy = drm_plane_cleanup,
+	.reset = drm_atomic_helper_plane_reset,
+	.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
+};
+
+static int ade_plane_init(struct drm_device *dev, struct ade_plane *aplane,
+			  enum drm_plane_type type)
+{
+	const u32 *fmts;
+	u32 fmts_cnt;
+	int ret = 0;
+
+	/* get  properties */
+	fmts_cnt = ade_get_channel_formats(aplane->ch, &fmts);
+	if (ret)
+		return ret;
+
+	ret = drm_universal_plane_init(dev, &aplane->base, 1, &ade_plane_funcs,
+				       fmts, fmts_cnt, type, NULL);
+	if (ret) {
+		DRM_ERROR("fail to init plane, ch=%d\n", aplane->ch);
+		return ret;
+	}
+
+	drm_plane_helper_add(&aplane->base, &ade_plane_helper_funcs);
+
+	return 0;
+}
+
 static int ade_dts_parse(struct platform_device *pdev, struct ade_hw_ctx *ctx)
 {
 	struct resource *res;
@@ -416,7 +924,10 @@ int ade_drm_init(struct drm_device *dev)
 	struct ade_data *ade;
 	struct ade_hw_ctx *ctx;
 	struct ade_crtc *acrtc;
+	struct ade_plane *aplane;
+	enum drm_plane_type type;
 	int ret;
+	int i;
 
 	ade = devm_kzalloc(dev->dev, sizeof(*ade), GFP_KERNEL);
 	if (!ade) {
@@ -434,6 +945,28 @@ int ade_drm_init(struct drm_device *dev)
 	if (ret)
 		return ret;
 
+	/*
+	 * plane init
+	 * TODO: Now only support primary plane, overlay planes
+	 * need to do.
+	 */
+	for (i = 0; i < ADE_CH_NUM; i++) {
+		aplane = &ade->aplane[i];
+		aplane->ch = i;
+		aplane->ctx = ctx;
+		type = i == PRIMARY_CH ? DRM_PLANE_TYPE_PRIMARY :
+			DRM_PLANE_TYPE_OVERLAY;
+
+		ret = ade_plane_init(dev, aplane, type);
+		if (ret)
+			return ret;
+	}
+
+	/* crtc init */
+	ret = ade_crtc_init(dev, &acrtc->base, &ade->aplane[PRIMARY_CH].base);
+	if (ret)
+		return ret;
+
 	return 0;
 }
 
-- 
1.9.1



From xinliang.liu at linaro.org  Mon Feb 22 19:00:25 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Tue, 23 Feb 2016 11:00:25 +0800
Subject: [PATCH v5 05/11] drm/hisilicon: Add vblank driver for ADE
In-Reply-To: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
References: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456196431-19923-6-git-send-email-xinliang.liu@linaro.org>

Add vblank irq handle.

v5: None.
v4: None.
v3:
- Remove hisi_get_crtc_from_index func.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 62 +++++++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 14 +++++-
 2 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index fae5f0afadb8..918897fa4e9e 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -292,6 +292,59 @@ static void ade_set_medianoc_qos(struct ade_crtc *acrtc)
 			   SOCKET_QOS_EN, SOCKET_QOS_EN);
 }
 
+static int ade_enable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+	struct kirin_drm_private *priv = dev->dev_private;
+	struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->base;
+
+	if (!ctx->power_on)
+		(void)ade_power_up(ctx);
+
+	ade_update_bits(base + LDI_INT_EN, FRAME_END_INT_EN_OFST,
+			MASK(1), 1);
+
+	return 0;
+}
+
+static void ade_disable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+	struct kirin_drm_private *priv = dev->dev_private;
+	struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->base;
+
+	if (!ctx->power_on) {
+		DRM_ERROR("power is down! vblank disable fail\n");
+		return;
+	}
+
+	ade_update_bits(base + LDI_INT_EN, FRAME_END_INT_EN_OFST,
+			MASK(1), 0);
+}
+
+static irqreturn_t ade_irq_handler(int irq, void *data)
+{
+	struct ade_crtc *acrtc = data;
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	struct drm_crtc *crtc = &acrtc->base;
+	void __iomem *base = ctx->base;
+	u32 status;
+
+	status = readl(base + LDI_MSK_INT);
+	DRM_DEBUG_VBL("LDI IRQ: status=0x%X\n", status);
+
+	/* vblank irq */
+	if (status & BIT(FRAME_END_INT_EN_OFST)) {
+		ade_update_bits(base + LDI_INT_CLR, FRAME_END_INT_EN_OFST,
+				MASK(1), 1);
+		drm_crtc_handle_vblank(crtc);
+	}
+
+	return IRQ_HANDLED;
+}
+
 static void ade_display_enable(struct ade_crtc *acrtc)
 {
 	struct ade_hw_ctx *ctx = acrtc->ctx;
@@ -967,6 +1020,15 @@ int ade_drm_init(struct drm_device *dev)
 	if (ret)
 		return ret;
 
+	/* vblank irq init */
+	ret = devm_request_irq(dev->dev, ctx->irq, ade_irq_handler,
+			       DRIVER_IRQ_SHARED, dev->driver->name, acrtc);
+	if (ret)
+		return ret;
+	dev->driver->get_vblank_counter = drm_vblank_no_hw_counter;
+	dev->driver->enable_vblank = ade_enable_vblank;
+	dev->driver->disable_vblank = ade_disable_vblank;
+
 	return 0;
 }
 
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 055729c1889c..723888feb760 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -32,6 +32,7 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
 	struct kirin_drm_private *priv = dev->dev_private;
 
+	drm_vblank_cleanup(dev);
 	dc_ops->cleanup(dev);
 	drm_mode_config_cleanup(dev);
 	devm_kfree(dev->dev, priv);
@@ -85,11 +86,22 @@ static int kirin_drm_kms_init(struct drm_device *dev)
 		goto err_dc_cleanup;
 	}
 
+	/* vblank init */
+	ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
+	if (ret) {
+		DRM_ERROR("failed to initialize vblank.\n");
+		goto err_unbind_all;
+	}
+	/* with irq_enabled = true, we can use the vblank feature. */
+	dev->irq_enabled = true;
+
 	/* reset all the states of crtc/plane/encoder/connector */
 	drm_mode_config_reset(dev);
 
 	return 0;
 
+err_unbind_all:
+	component_unbind_all(dev->dev, dev);
 err_dc_cleanup:
 	dc_ops->cleanup(dev);
 err_mode_config_cleanup:
@@ -123,7 +135,7 @@ static int kirin_gem_cma_dumb_create(struct drm_file *file,
 
 static struct drm_driver kirin_drm_driver = {
 	.driver_features	= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
-				  DRIVER_ATOMIC,
+				  DRIVER_ATOMIC | DRIVER_HAVE_IRQ,
 	.fops			= &kirin_drm_fops,
 	.set_busid		= drm_platform_set_busid,
 
-- 
1.9.1



From xinliang.liu at linaro.org  Mon Feb 22 19:00:26 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Tue, 23 Feb 2016 11:00:26 +0800
Subject: [PATCH v5 06/11] drm/hisilicon: Add cma fbdev and hotplug
In-Reply-To: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
References: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456196431-19923-7-git-send-email-xinliang.liu@linaro.org>

Add cma Fbdev, Fbdev is legency and optional, you can enable/disable it by
configuring DRM_FBDEV_EMULATION.
Add hotplug.

v5: None.
v4: None.
v3: None.
v2:
- Use CONFIG_DRM_FBDEV_EMULATION instead of CONFIG_DRM_HISI_FBDEV.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 34 +++++++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  3 +++
 2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 723888feb760..d57b9fa0ce3e 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -23,6 +23,7 @@
 #include <drm/drm_gem_cma_helper.h>
 #include <drm/drm_fb_cma_helper.h>
 #include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc_helper.h>
 
 #include "kirin_drm_drv.h"
 
@@ -32,6 +33,13 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
 	struct kirin_drm_private *priv = dev->dev_private;
 
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+	if (priv->fbdev) {
+		drm_fbdev_cma_fini(priv->fbdev);
+		priv->fbdev = NULL;
+	}
+#endif
+	drm_kms_helper_poll_fini(dev);
 	drm_vblank_cleanup(dev);
 	dc_ops->cleanup(dev);
 	drm_mode_config_cleanup(dev);
@@ -41,8 +49,28 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 	return 0;
 }
 
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+static void kirin_fbdev_output_poll_changed(struct drm_device *dev)
+{
+	struct kirin_drm_private *priv = dev->dev_private;
+
+	if (priv->fbdev) {
+		drm_fbdev_cma_hotplug_event(priv->fbdev);
+	} else {
+		priv->fbdev = drm_fbdev_cma_init(dev, 32,
+				dev->mode_config.num_crtc,
+				dev->mode_config.num_connector);
+		if (IS_ERR(priv->fbdev))
+			priv->fbdev = NULL;
+	}
+}
+#endif
+
 static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
 	.fb_create = drm_fb_cma_create,
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+	.output_poll_changed = kirin_fbdev_output_poll_changed,
+#endif
 	.atomic_check = drm_atomic_helper_check,
 	.atomic_commit = drm_atomic_helper_commit,
 };
@@ -98,6 +126,12 @@ static int kirin_drm_kms_init(struct drm_device *dev)
 	/* reset all the states of crtc/plane/encoder/connector */
 	drm_mode_config_reset(dev);
 
+	/* init kms poll for handling hpd */
+	drm_kms_helper_poll_init(dev);
+
+	/* force detection after connectors init */
+	(void)drm_helper_hpd_irq_event(dev);
+
 	return 0;
 
 err_unbind_all:
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 5a05ad6a81db..1a07caf8e7f4 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -21,6 +21,9 @@ struct kirin_dc_ops {
 
 struct kirin_drm_private {
 	struct drm_crtc *crtc[MAX_CRTC];
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+	struct drm_fbdev_cma *fbdev;
+#endif
 };
 
 extern const struct kirin_dc_ops ade_dc_ops;
-- 
1.9.1



From xinliang.liu at linaro.org  Mon Feb 22 19:00:28 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Tue, 23 Feb 2016 11:00:28 +0800
Subject: [PATCH v5 08/11] drm/hisilicon: Add designware dsi host driver
In-Reply-To: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
References: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456196431-19923-9-git-send-email-xinliang.liu@linaro.org>

Add DesignWare dsi host driver for hi6220 SoC.

v5: None.
v4: None.
v3: None.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 50 ++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index 7c9423537b71..2837af01e935 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -79,6 +79,7 @@ struct dsi_hw_ctx {
 
 struct dw_dsi {
 	struct drm_encoder encoder;
+	struct mipi_dsi_host host;
 	struct drm_display_mode cur_mode;
 	struct dsi_hw_ctx *ctx;
 	struct mipi_phy_params phy;
@@ -642,6 +643,51 @@ static int dw_drm_encoder_init(struct device *dev,
 	return 0;
 }
 
+static int dsi_host_attach(struct mipi_dsi_host *host,
+			   struct mipi_dsi_device *mdsi)
+{
+	struct dw_dsi *dsi = host_to_dsi(host);
+
+	if (mdsi->lanes < 1 || mdsi->lanes > 4) {
+		DRM_ERROR("dsi device params invalid\n");
+		return -EINVAL;
+	}
+
+	dsi->lanes = mdsi->lanes;
+	dsi->format = mdsi->format;
+	dsi->mode_flags = mdsi->mode_flags;
+
+	return 0;
+}
+
+static int dsi_host_detach(struct mipi_dsi_host *host,
+			   struct mipi_dsi_device *mdsi)
+{
+	/* do nothing */
+	return 0;
+}
+
+static const struct mipi_dsi_host_ops dsi_host_ops = {
+	.attach = dsi_host_attach,
+	.detach = dsi_host_detach,
+};
+
+static int dsi_host_init(struct device *dev, struct dw_dsi *dsi)
+{
+	struct mipi_dsi_host *host = &dsi->host;
+	int ret;
+
+	host->dev = dev;
+	host->ops = &dsi_host_ops;
+	ret = mipi_dsi_host_register(host);
+	if (ret) {
+		DRM_ERROR("failed to register dsi host\n");
+		return ret;
+	}
+
+	return 0;
+}
+
 static int dsi_bind(struct device *dev, struct device *master, void *data)
 {
 	struct dsi_data *ddata = dev_get_drvdata(dev);
@@ -653,6 +699,10 @@ static int dsi_bind(struct device *dev, struct device *master, void *data)
 	if (ret)
 		return ret;
 
+	ret = dsi_host_init(dev, dsi);
+	if (ret)
+		return ret;
+
 	return 0;
 }
 
-- 
1.9.1



From dianders at google.com  Mon Feb 22 19:03:44 2016
From: dianders at google.com (Doug Anderson)
Date: Mon, 22 Feb 2016 19:03:44 -0800
Subject: [PATCH v3 00/12] pwm: add support for atomic update
In-Reply-To: <20160222212438.GG18327@sirena.org.uk>
References: <1442828009-6241-1-git-send-email-boris.brezillon@free-electrons.com>
 <2341981.a79ioYM9Es@diego> <20151110173416.GB21727@ulmo>
 <CAD=FV=WL3jYEgVe-m6QcAyQwfJgdX4J5OtKisKwyoKOrTSpEQA@mail.gmail.com>
 <20160125170855.GA10182@ulmo>
 <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
 <20160203145337.GD9650@ulmo>
 <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
 <20160222175929.GA23899@ulmo>
 <CAD=FV=UCErW3EjYRtwt49_ztNR7cyY4U0o4R_dxdomer-Ac2Dg@mail.gmail.com>
 <20160222212438.GG18327@sirena.org.uk>
Message-ID: <CAD=FV=WP+=vsKHj3aakdYwE4Xedwd=uya+ma22q-s+MsBTon7w@mail.gmail.com>

Mark,

On Mon, Feb 22, 2016 at 1:24 PM, Mark Brown <broonie at kernel.org> wrote:
> On Mon, Feb 22, 2016 at 11:15:09AM -0800, Doug Anderson wrote:
>
>> Note that historically I remember that Linus Torvalds has stated that
>> there is no stable API within the Linux kernel and that forcing the
>> in-kernel API to never change was bad for software development.  I
>> tracked down my memory and found
>> <http://lwn.net/1999/0211/a/lt-binary.html>.  Linus is rabid about not
>> breaking userspace, but in general there's no strong requirement to
>> never change the driver API inside the kernel.  That being said,
>> changing the driver API causes a lot of churn, so presumably changing
>> it in a backward compatible way (like adding to the API instead of
>> changing it) will make things happier.
>
> You do need to fix the users though, change is fine but you can't cause
> people's systems to break.

Yes, of course!  :)  Thanks for clarifying.

-Doug


From xinliang.liu at linaro.org  Mon Feb 22 19:00:29 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Tue, 23 Feb 2016 11:00:29 +0800
Subject: [PATCH v5 09/11] drm/hisilicon: Add support for external bridge
In-Reply-To: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
References: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456196431-19923-10-git-send-email-xinliang.liu@linaro.org>

Add support for external HDMI bridge.

v5: None.
v4: None.
v3:
- Fix a typo: s/exteranl/external.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 52 ++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index 2837af01e935..1342d84d7c68 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -79,6 +79,7 @@ struct dsi_hw_ctx {
 
 struct dw_dsi {
 	struct drm_encoder encoder;
+	struct drm_bridge *bridge;
 	struct mipi_dsi_host host;
 	struct drm_display_mode cur_mode;
 	struct dsi_hw_ctx *ctx;
@@ -688,6 +689,25 @@ static int dsi_host_init(struct device *dev, struct dw_dsi *dsi)
 	return 0;
 }
 
+static int dsi_bridge_init(struct drm_device *dev, struct dw_dsi *dsi)
+{
+	struct drm_encoder *encoder = &dsi->encoder;
+	struct drm_bridge *bridge = dsi->bridge;
+	int ret;
+
+	/* associate the bridge to dsi encoder */
+	encoder->bridge = bridge;
+	bridge->encoder = encoder;
+
+	ret = drm_bridge_attach(dev, bridge);
+	if (ret) {
+		DRM_ERROR("failed to attach external bridge\n");
+		return ret;
+	}
+
+	return 0;
+}
+
 static int dsi_bind(struct device *dev, struct device *master, void *data)
 {
 	struct dsi_data *ddata = dev_get_drvdata(dev);
@@ -703,6 +723,10 @@ static int dsi_bind(struct device *dev, struct device *master, void *data)
 	if (ret)
 		return ret;
 
+	ret = dsi_bridge_init(drm_dev, dsi);
+	if (ret)
+		return ret;
+
 	return 0;
 }
 
@@ -719,8 +743,36 @@ static const struct component_ops dsi_ops = {
 static int dsi_parse_dt(struct platform_device *pdev, struct dw_dsi *dsi)
 {
 	struct dsi_hw_ctx *ctx = dsi->ctx;
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *endpoint, *bridge_node;
+	struct drm_bridge *bridge;
 	struct resource *res;
 
+	/*
+	 * Get the endpoint node. In our case, dsi has one output port1
+	 * to which the external HDMI bridge is connected.
+	 */
+	endpoint = of_graph_get_endpoint_by_regs(np, 1, -1);
+	if (!endpoint) {
+		DRM_ERROR("no valid endpoint node\n");
+		return -ENODEV;
+	}
+	of_node_put(endpoint);
+
+	bridge_node = of_graph_get_remote_port_parent(endpoint);
+	if (!bridge_node) {
+		DRM_ERROR("no valid bridge node\n");
+		return -ENODEV;
+	}
+	of_node_put(bridge_node);
+
+	bridge = of_drm_find_bridge(bridge_node);
+	if (!bridge) {
+		DRM_INFO("wait for external HDMI bridge driver.\n");
+		return -EPROBE_DEFER;
+	}
+	dsi->bridge = bridge;
+
 	ctx->dsi_cfg_clk = devm_clk_get(&pdev->dev, "pclk_dsi");
 	if (IS_ERR(ctx->dsi_cfg_clk)) {
 		DRM_ERROR("failed to get dsi plck clock\n");
-- 
1.9.1



From xinliang.liu at linaro.org  Mon Feb 22 19:00:27 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Tue, 23 Feb 2016 11:00:27 +0800
Subject: [PATCH v5 07/11] drm/hisilicon: Add designware dsi encoder driver
In-Reply-To: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
References: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456196431-19923-8-git-send-email-xinliang.liu@linaro.org>

Add DesignWare MIPI DSI Host Controller v1.02 encoder driver
for hi6220 SoC.

v5: None.
v4: None.
v3:
- Rename file name to dw_drm_dsi.c
- Make encoder type as DRM_MODE_ENCODER_DSI.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
Signed-off-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
Signed-off-by: Andy Green <andy.green at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/Kconfig      |   1 +
 drivers/gpu/drm/hisilicon/kirin/Makefile     |   3 +-
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 743 +++++++++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h |  83 +++
 4 files changed, 829 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h

diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig b/drivers/gpu/drm/hisilicon/kirin/Kconfig
index 3ac4b8edeac1..de0d454c5c13 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Kconfig
+++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
@@ -4,6 +4,7 @@ config DRM_HISI_KIRIN
 	select DRM_KMS_HELPER
 	select DRM_GEM_CMA_HELPER
 	select DRM_KMS_CMA_HELPER
+	select DRM_MIPI_DSI
 	help
 	  Choose this option if you have a hisilicon Kirin chipsets(hi6220).
 	  If M is selected the module will be called kirin-drm.
diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile b/drivers/gpu/drm/hisilicon/kirin/Makefile
index 2a61ab006ddb..5dcd0d4328b6 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Makefile
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -1,4 +1,5 @@
 kirin-drm-y := kirin_drm_drv.o \
-	       kirin_drm_ade.o
+	       kirin_drm_ade.o \
+	       dw_drm_dsi.o
 
 obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
new file mode 100644
index 000000000000..7c9423537b71
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -0,0 +1,743 @@
+/*
+ * DesignWare MIPI DSI Host Controller v1.02 driver
+ *
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * Author:
+ *	Xinliang Liu <z.liuxinliang at hisilicon.com>
+ *	Xinliang Liu <xinliang.liu at linaro.org>
+ *	Xinwei Kong <kong.kongxinwei at hisilicon.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.
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/component.h>
+#include <linux/of_graph.h>
+
+#include <drm/drm_of.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_encoder_slave.h>
+#include <drm/drm_atomic_helper.h>
+
+#include "dw_dsi_reg.h"
+
+#define MAX_TX_ESC_CLK		   (10)
+#define ROUND(x, y) ((x) / (y) + ((x) % (y) * 10 / (y) >= 5 ? 1 : 0))
+#define PHY_REF_CLK_RATE   19200000
+#define PHY_REF_CLK_PERIOD_PS (1000000000 / (PHY_REF_CLK_RATE / 1000))
+
+#define encoder_to_dsi(encoder) \
+	container_of(encoder, struct dw_dsi, encoder)
+#define host_to_dsi(host) \
+	container_of(host, struct dw_dsi, host)
+
+struct mipi_phy_params {
+	u32 clk_t_lpx;
+	u32 clk_t_hs_prepare;
+	u32 clk_t_hs_zero;
+	u32 clk_t_hs_trial;
+	u32 clk_t_wakeup;
+	u32 data_t_lpx;
+	u32 data_t_hs_prepare;
+	u32 data_t_hs_zero;
+	u32 data_t_hs_trial;
+	u32 data_t_ta_go;
+	u32 data_t_ta_get;
+	u32 data_t_wakeup;
+	u32 hstx_ckg_sel;
+	u32 pll_fbd_div5f;
+	u32 pll_fbd_div1f;
+	u32 pll_fbd_2p;
+	u32 pll_enbwt;
+	u32 pll_fbd_p;
+	u32 pll_fbd_s;
+	u32 pll_pre_div1p;
+	u32 pll_pre_p;
+	u32 pll_vco_750M;
+	u32 pll_lpf_rs;
+	u32 pll_lpf_cs;
+	u32 clklp2hs_time;
+	u32 clkhs2lp_time;
+	u32 lp2hs_time;
+	u32 hs2lp_time;
+	u32 clk_to_data_delay;
+	u32 data_to_clk_delay;
+	u32 lane_byte_clk_kHz;
+	u32 clk_division;
+};
+
+struct dsi_hw_ctx {
+	void __iomem *base;
+	struct clk *dsi_cfg_clk;
+};
+
+struct dw_dsi {
+	struct drm_encoder encoder;
+	struct drm_display_mode cur_mode;
+	struct dsi_hw_ctx *ctx;
+	struct mipi_phy_params phy;
+
+	u32 lanes;
+	enum mipi_dsi_pixel_format format;
+	unsigned long mode_flags;
+	bool enable;
+};
+
+struct dsi_data {
+	struct dw_dsi dsi;
+	struct dsi_hw_ctx ctx;
+};
+
+struct dsi_phy_range {
+	u32 min_range_kHz;
+	u32 max_range_kHz;
+	u32 pll_vco_750M;
+	u32 hstx_ckg_sel;
+};
+
+static const struct dsi_phy_range dphy_range_info[] = {
+	{   46875,    62500,   1,    7 },
+	{   62500,    93750,   0,    7 },
+	{   93750,   125000,   1,    6 },
+	{  125000,   187500,   0,    6 },
+	{  187500,   250000,   1,    5 },
+	{  250000,   375000,   0,    5 },
+	{  375000,   500000,   1,    4 },
+	{  500000,   750000,   0,    4 },
+	{  750000,  1000000,   1,    0 },
+	{ 1000000,  1500000,   0,    0 }
+};
+
+static void dsi_get_phy_params(u32 phy_freq_kHz,
+			       struct mipi_phy_params *phy)
+{
+	u32 ui = 0;
+	u32 cfg_clk_ps = PHY_REF_CLK_PERIOD_PS;
+	u32 i = 0;
+	u32 q_pll = 1;
+	u32 m_pll = 0;
+	u32 n_pll = 0;
+	u32 r_pll = 1;
+	u32 m_n = 0;
+	u32 m_n_int = 0;
+	u64 f_kHz;
+	u64 temp;
+	u64 tmp_kHz = phy_freq_kHz;
+
+	do {
+		f_kHz = tmp_kHz;
+
+		/* Find the PLL clock range from the table */
+		for (i = 0; i < ARRAY_SIZE(dphy_range_info); i++)
+			if (f_kHz >= dphy_range_info[i].min_range_kHz &&
+			    f_kHz <= dphy_range_info[i].max_range_kHz)
+				break;
+
+		if (i == ARRAY_SIZE(dphy_range_info)) {
+			DRM_ERROR("%lldkHz out of range\n", f_kHz);
+			return;
+		}
+
+		phy->pll_vco_750M = dphy_range_info[i].pll_vco_750M;
+		phy->hstx_ckg_sel = dphy_range_info[i].hstx_ckg_sel;
+
+		if (phy->hstx_ckg_sel <= 7 &&
+		    phy->hstx_ckg_sel >= 4)
+			q_pll = 0x10 >> (7 - phy->hstx_ckg_sel);
+
+		temp = f_kHz * (u64)q_pll * (u64)cfg_clk_ps;
+		m_n_int = temp / (u64)1000000000;
+		m_n = (temp % (u64)1000000000) / (u64)100000000;
+
+		if (m_n_int % 2 == 0) {
+			if (m_n * 6 >= 50) {
+				n_pll = 2;
+				m_pll = (m_n_int + 1) * n_pll;
+			} else if (m_n * 6 >= 30) {
+				n_pll = 3;
+				m_pll = m_n_int * n_pll + 2;
+			} else {
+				n_pll = 1;
+				m_pll = m_n_int * n_pll;
+			}
+		} else {
+			if (m_n * 6 >= 50) {
+				n_pll = 1;
+				m_pll = (m_n_int + 1) * n_pll;
+			} else if (m_n * 6 >= 30) {
+				n_pll = 1;
+				m_pll = (m_n_int + 1) * n_pll;
+			} else if (m_n * 6 >= 10) {
+				n_pll = 3;
+				m_pll = m_n_int * n_pll + 1;
+			} else {
+				n_pll = 2;
+				m_pll = m_n_int * n_pll;
+			}
+		}
+
+		if (n_pll == 1) {
+			phy->pll_fbd_p = 0;
+			phy->pll_pre_div1p = 1;
+		} else {
+			phy->pll_fbd_p = n_pll;
+			phy->pll_pre_div1p = 0;
+		}
+
+		if (phy->pll_fbd_2p <= 7 && phy->pll_fbd_2p >= 4)
+			r_pll = 0x10 >> (7 - phy->pll_fbd_2p);
+
+		if (m_pll == 2) {
+			phy->pll_pre_p = 0;
+			phy->pll_fbd_s = 0;
+			phy->pll_fbd_div1f = 0;
+			phy->pll_fbd_div5f = 1;
+		} else if (m_pll >= 2 * 2 * r_pll && m_pll <= 2 * 4 * r_pll) {
+			phy->pll_pre_p = m_pll / (2 * r_pll);
+			phy->pll_fbd_s = 0;
+			phy->pll_fbd_div1f = 1;
+			phy->pll_fbd_div5f = 0;
+		} else if (m_pll >= 2 * 5 * r_pll && m_pll <= 2 * 150 * r_pll) {
+			if (((m_pll / (2 * r_pll)) % 2) == 0) {
+				phy->pll_pre_p =
+					(m_pll / (2 * r_pll)) / 2 - 1;
+				phy->pll_fbd_s =
+					(m_pll / (2 * r_pll)) % 2 + 2;
+			} else {
+				phy->pll_pre_p =
+					(m_pll / (2 * r_pll)) / 2;
+				phy->pll_fbd_s =
+					(m_pll / (2 * r_pll)) % 2;
+			}
+			phy->pll_fbd_div1f = 0;
+			phy->pll_fbd_div5f = 0;
+		} else {
+			phy->pll_pre_p = 0;
+			phy->pll_fbd_s = 0;
+			phy->pll_fbd_div1f = 0;
+			phy->pll_fbd_div5f = 1;
+		}
+
+		f_kHz = (u64)1000000000 * (u64)m_pll /
+			((u64)cfg_clk_ps * (u64)n_pll * (u64)q_pll);
+
+		if (f_kHz >= phy_freq_kHz)
+			break;
+
+		tmp_kHz += 10;
+
+	} while (1);
+
+	ui = 1000000 / f_kHz;
+
+	phy->clk_t_lpx = ROUND(50, 8 * ui);
+	phy->clk_t_hs_prepare = ROUND(133, 16 * ui) - 1;
+
+	phy->clk_t_hs_zero = ROUND(262, 8 * ui);
+	phy->clk_t_hs_trial = 2 * (ROUND(60, 8 * ui) - 1);
+	phy->clk_t_wakeup = ROUND(1000000, (cfg_clk_ps / 1000) - 1);
+	if (phy->clk_t_wakeup > 0xff)
+		phy->clk_t_wakeup = 0xff;
+	phy->data_t_wakeup = phy->clk_t_wakeup;
+	phy->data_t_lpx = phy->clk_t_lpx;
+	phy->data_t_hs_prepare = ROUND(125 + 10 * ui, 16 * ui) - 1;
+	phy->data_t_hs_zero = ROUND(105 + 6 * ui, 8 * ui);
+	phy->data_t_hs_trial = 2 * (ROUND(60 + 4 * ui, 8 * ui) - 1);
+	phy->data_t_ta_go = 3;
+	phy->data_t_ta_get = 4;
+
+	phy->pll_enbwt = 1;
+	phy->clklp2hs_time = ROUND(407, 8 * ui) + 12;
+	phy->clkhs2lp_time = ROUND(105 + 12 * ui, 8 * ui);
+	phy->lp2hs_time = ROUND(240 + 12 * ui, 8 * ui) + 1;
+	phy->hs2lp_time = phy->clkhs2lp_time;
+	phy->clk_to_data_delay = 1 + phy->clklp2hs_time;
+	phy->data_to_clk_delay = ROUND(60 + 52 * ui, 8 * ui) +
+				phy->clkhs2lp_time;
+
+	phy->lane_byte_clk_kHz = f_kHz / 8;
+	phy->clk_division = phy->lane_byte_clk_kHz / MAX_TX_ESC_CLK;
+	if (phy->lane_byte_clk_kHz % MAX_TX_ESC_CLK)
+		phy->clk_division++;
+}
+
+static u32 dsi_get_dpi_color_coding(enum mipi_dsi_pixel_format format)
+{
+	u32 val;
+
+	/* TODO: only support RGB888 now, to support more */
+	switch (format) {
+	case MIPI_DSI_FMT_RGB888:
+		val = DSI_24BITS_1;
+		break;
+	default:
+		val = DSI_24BITS_1;
+		break;
+	}
+
+	return val;
+}
+
+/*
+ * dsi phy reg write function
+ */
+static void dsi_phy_tst_set(void __iomem *base, u32 reg, u32 val)
+{
+	writel(reg, base + PHY_TST_CTRL1);
+	/* reg addr written at first */
+	wmb();
+	writel(0x02, base + PHY_TST_CTRL0);
+	/* cmd1 sent for write */
+	wmb();
+	writel(0x00, base + PHY_TST_CTRL0);
+	/* cmd2 sent for write */
+	wmb();
+	writel(val, base + PHY_TST_CTRL1);
+	/* Then write data */
+	wmb();
+	writel(0x02, base + PHY_TST_CTRL0);
+	/* cmd2 sent for write */
+	wmb();
+	writel(0x00, base + PHY_TST_CTRL0);
+}
+
+static void dsi_set_mipi_phy(void __iomem *base,
+			     struct mipi_phy_params *phy,
+			     u32 lanes)
+{
+	u32 delay_count;
+	u32 val;
+	u32 i;
+
+	/* set lanes value */
+	val = (lanes - 1) | (PHY_STOP_WAIT_TIME << 8);
+	writel(val, base + PHY_IF_CFG);
+
+	/* set phy clk division */
+	val = readl(base + CLKMGR_CFG) | phy->clk_division;
+	writel(val, base + CLKMGR_CFG);
+
+	/* clean up phy set param */
+	writel(0, base + PHY_RSTZ);
+	writel(0, base + PHY_TST_CTRL0);
+	writel(1, base + PHY_TST_CTRL0);
+	writel(0, base + PHY_TST_CTRL0);
+
+	/* clock lane Timing control - TLPX */
+	dsi_phy_tst_set(base, 0x10010, phy->clk_t_lpx);
+
+	/* clock lane Timing control - THS-PREPARE */
+	dsi_phy_tst_set(base, 0x10011, phy->clk_t_hs_prepare);
+
+	/* clock lane Timing control - THS-ZERO */
+	dsi_phy_tst_set(base, 0x10012, phy->clk_t_hs_zero);
+
+	/* clock lane Timing control - THS-TRAIL */
+	dsi_phy_tst_set(base, 0x10013, phy->clk_t_hs_trial);
+
+	/* clock lane Timing control - TWAKEUP */
+	dsi_phy_tst_set(base, 0x10014, phy->clk_t_wakeup);
+
+	/* data lane */
+	for (i = 0; i < lanes; i++) {
+		/* Timing control - TLPX */
+		dsi_phy_tst_set(base, 0x10020 + (i << 4), phy->data_t_lpx);
+
+		/* Timing control - THS-PREPARE */
+		dsi_phy_tst_set(base, 0x10021 + (i << 4),
+				phy->data_t_hs_prepare);
+
+		/* Timing control - THS-ZERO */
+		dsi_phy_tst_set(base, 0x10022 + (i << 4), phy->data_t_hs_zero);
+
+		/* Timing control - THS-TRAIL */
+		dsi_phy_tst_set(base, 0x10023 + (i << 4), phy->data_t_hs_trial);
+
+		/* Timing control - TTA-GO */
+		dsi_phy_tst_set(base, 0x10024 + (i << 4), phy->data_t_ta_go);
+
+		/* Timing control - TTA-GET */
+		dsi_phy_tst_set(base, 0x10025 + (i << 4), phy->data_t_ta_get);
+
+		/* Timing control - TWAKEUP */
+		dsi_phy_tst_set(base, 0x10026 + (i << 4), phy->data_t_wakeup);
+	}
+
+	/* physical configuration I */
+	dsi_phy_tst_set(base, 0x10060, phy->hstx_ckg_sel);
+
+	/* physical configuration pll II */
+	val = (phy->pll_fbd_div5f << 5) + (phy->pll_fbd_div1f << 4) +
+				(phy->pll_fbd_2p << 1) + phy->pll_enbwt;
+	dsi_phy_tst_set(base, 0x10063, val);
+
+	/* physical configuration pll II */
+	dsi_phy_tst_set(base, 0x10064, phy->pll_fbd_p);
+
+	/* physical configuration pll III */
+	dsi_phy_tst_set(base, 0x10065, phy->pll_fbd_s);
+
+	/* physical configuration pll IV */
+	val = (phy->pll_pre_div1p << 7) + phy->pll_pre_p;
+	dsi_phy_tst_set(base, 0x10066, val);
+
+	/* physical configuration pll V */
+	val = (phy->pll_vco_750M << 4) + (phy->pll_lpf_rs << 2) +
+					phy->pll_lpf_cs + BIT(5);
+	dsi_phy_tst_set(base, 0x10067, val);
+
+	writel(BIT(2), base + PHY_RSTZ);
+	udelay(1);
+	writel(BIT(2) | BIT(0), base + PHY_RSTZ);
+	udelay(1);
+	writel(BIT(2) | BIT(1) | BIT(0), base + PHY_RSTZ);
+	usleep_range(1000, 1500);
+
+	/* wait for phy's clock ready */
+	delay_count = 100;
+	while (delay_count--) {
+		val = readl(base +  PHY_STATUS);
+		if ((BIT(0) | BIT(2)) & val)
+			break;
+
+		udelay(1);
+	}
+
+	if (!delay_count)
+		DRM_INFO("phylock and phystopstateclklane is not ready.\n");
+
+	/* set lp and hs switching params
+	 */
+	dw_update_bits(base + PHY_TMR_CFG, 24, MASK(8), phy->hs2lp_time);
+	dw_update_bits(base + PHY_TMR_CFG, 16, MASK(8), phy->lp2hs_time);
+	dw_update_bits(base + PHY_TMR_LPCLK_CFG, 16, MASK(10),
+		       phy->clkhs2lp_time);
+	dw_update_bits(base + PHY_TMR_LPCLK_CFG, 0, MASK(10),
+		       phy->clklp2hs_time);
+	dw_update_bits(base + CLK_DATA_TMR_CFG, 8, MASK(8),
+		       phy->data_to_clk_delay);
+	dw_update_bits(base + CLK_DATA_TMR_CFG, 0, MASK(8),
+		       phy->clk_to_data_delay);
+}
+
+static void dsi_set_mode_timing(void __iomem *base,
+				u32 lane_byte_clk_kHz,
+				struct drm_display_mode *mode,
+				enum mipi_dsi_pixel_format format)
+{
+	u32 hfp, hbp, hsw, vfp, vbp, vsw;
+	u32 hline_time;
+	u32 hsa_time;
+	u32 hbp_time;
+	u32 pixel_clk_kHz;
+	int htot, vtot;
+	u32 val;
+	u64 tmp;
+
+	/* DSI color coding setting */
+	val = dsi_get_dpi_color_coding(format);
+	writel(val, base + DPI_COLOR_CODING);
+
+	/* DSI format and pol setting */
+	val = (mode->flags & DRM_MODE_FLAG_NHSYNC ? 1 : 0) << 2;
+	val |= (mode->flags & DRM_MODE_FLAG_NVSYNC ? 1 : 0) << 1;
+	writel(val, base +  DPI_CFG_POL);
+
+	/*
+	 * The DSI IP accepts vertical timing using lines as normal,
+	 * but horizontal timing is a mixture of pixel-clocks for the
+	 * active region and byte-lane clocks for the blanking-related
+	 * timings.  hfp is specified as the total hline_time in byte-
+	 * lane clocks minus hsa, hbp and active.
+	 */
+	pixel_clk_kHz = mode->clock;
+	htot = mode->htotal;
+	vtot = mode->vtotal;
+	hfp = mode->hsync_start - mode->hdisplay;
+	hbp = mode->htotal - mode->hsync_end;
+	hsw = mode->hsync_end - mode->hsync_start;
+	vfp = mode->vsync_start - mode->vdisplay;
+	vbp = mode->vtotal - mode->vsync_end;
+	vsw = mode->vsync_end - mode->vsync_start;
+	if (vsw > 15) {
+		DRM_DEBUG_DRIVER("vsw exceeded 15\n");
+		vsw = 15;
+	}
+
+	hsa_time = (hsw * lane_byte_clk_kHz) / pixel_clk_kHz;
+	hbp_time = (hbp * lane_byte_clk_kHz) / pixel_clk_kHz;
+	tmp = (u64)htot * (u64)lane_byte_clk_kHz;
+	hline_time = DIV_ROUND_UP(tmp, pixel_clk_kHz);
+
+	/* all specified in byte-lane clocks */
+	writel(hsa_time, base + VID_HSA_TIME);
+	writel(hbp_time, base + VID_HBP_TIME);
+	writel(hline_time, base + VID_HLINE_TIME);
+
+	writel(vsw, base + VID_VSA_LINES);
+	writel(vbp, base + VID_VBP_LINES);
+	writel(vfp, base + VID_VFP_LINES);
+	writel(mode->vdisplay, base + VID_VACTIVE_LINES);
+	writel(mode->hdisplay, base + VID_PKT_SIZE);
+
+	DRM_DEBUG_DRIVER("htot=%d, hfp=%d, hbp=%d, hsw=%d\n",
+			 htot, hfp, hbp, hsw);
+	DRM_DEBUG_DRIVER("vtol=%d, vfp=%d, vbp=%d, vsw=%d\n",
+			 vtot, vfp, vbp, vsw);
+	DRM_DEBUG_DRIVER("hsa_time=%d, hbp_time=%d, hline_time=%d\n",
+			 hsa_time, hbp_time, hline_time);
+}
+
+static void dsi_set_video_mode_type(void __iomem *base,
+				    unsigned long flags)
+{
+	u32 val;
+	u32 mode_mask = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+		MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
+	u32 non_burst_sync_pulse = MIPI_DSI_MODE_VIDEO |
+		MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
+	u32 non_burst_sync_event = MIPI_DSI_MODE_VIDEO;
+
+	/*
+	 * choose video type
+	 */
+	if ((flags & mode_mask) == non_burst_sync_pulse)
+		val = DSI_NON_BURST_SYNC_PULSES;
+	else if ((flags & mode_mask) == non_burst_sync_event)
+		val = DSI_NON_BURST_SYNC_EVENTS;
+	else
+		val = DSI_BURST_SYNC_PULSES_1;
+
+	writel(val, base + VID_MODE_CFG);
+}
+
+static void dsi_mipi_init(struct dw_dsi *dsi)
+{
+	struct dsi_hw_ctx *ctx = dsi->ctx;
+	struct mipi_phy_params *phy = &dsi->phy;
+	struct drm_display_mode *mode = &dsi->cur_mode;
+	u32 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
+	void __iomem *base = ctx->base;
+	u32 dphy_freq_kHz;
+
+	/* count phy params */
+	dphy_freq_kHz = mode->clock * bpp / dsi->lanes;
+	dsi_get_phy_params(dphy_freq_kHz, phy);
+
+	/* reset Core */
+	writel(0, base + PWR_UP);
+
+	/* set phy params */
+	dsi_set_mipi_phy(base, phy, dsi->lanes);
+
+	/* set dsi mode */
+	dsi_set_mode_timing(base, phy->lane_byte_clk_kHz, mode, dsi->format);
+
+	/* set video mode type and lp */
+	dsi_set_video_mode_type(base, dsi->mode_flags);
+
+	/* dsi wake up */
+	writel(DSI_VIDEO_MODE, base + MODE_CFG);
+	writel(BIT(0), base + LPCLK_CTRL);
+	writel(BIT(0), base + PWR_UP);
+
+	DRM_DEBUG_DRIVER("lanes=%d, pixel_clk=%d kHz, bytes_freq=%d kHz\n",
+			 dsi->lanes, mode->clock, phy->lane_byte_clk_kHz);
+}
+
+static void dsi_encoder_disable(struct drm_encoder *encoder)
+{
+	struct dw_dsi *dsi = encoder_to_dsi(encoder);
+	struct dsi_hw_ctx *ctx = dsi->ctx;
+	void __iomem *base = ctx->base;
+
+	if (!dsi->enable)
+		return;
+
+	writel(0, base + PWR_UP);
+	writel(0, base + LPCLK_CTRL);
+	writel(0, base + PHY_RSTZ);
+	clk_disable_unprepare(ctx->dsi_cfg_clk);
+
+	dsi->enable = false;
+}
+
+static void dsi_encoder_enable(struct drm_encoder *encoder)
+{
+	struct dw_dsi *dsi = encoder_to_dsi(encoder);
+	struct dsi_hw_ctx *ctx = dsi->ctx;
+	int ret;
+
+	if (dsi->enable)
+		return;
+
+	/* mipi dphy clock enable */
+	ret = clk_prepare_enable(ctx->dsi_cfg_clk);
+	if (ret) {
+		DRM_ERROR("fail to enable dsi_cfg_clk: %d\n", ret);
+		return;
+	}
+
+	dsi_mipi_init(dsi);
+
+	dsi->enable = true;
+}
+
+static void dsi_encoder_mode_set(struct drm_encoder *encoder,
+				 struct drm_display_mode *mode,
+				 struct drm_display_mode *adj_mode)
+{
+	struct dw_dsi *dsi = encoder_to_dsi(encoder);
+
+	drm_mode_copy(&dsi->cur_mode, adj_mode);
+}
+
+static int dsi_encoder_atomic_check(struct drm_encoder *encoder,
+				    struct drm_crtc_state *crtc_state,
+				    struct drm_connector_state *conn_state)
+{
+	/* do nothing */
+	return 0;
+}
+
+static const struct drm_encoder_helper_funcs dw_encoder_helper_funcs = {
+	.atomic_check	= dsi_encoder_atomic_check,
+	.mode_set	= dsi_encoder_mode_set,
+	.enable		= dsi_encoder_enable,
+	.disable	= dsi_encoder_disable
+};
+
+static const struct drm_encoder_funcs dw_encoder_funcs = {
+	.destroy = drm_encoder_cleanup,
+};
+
+static int dw_drm_encoder_init(struct device *dev,
+			       struct drm_device *drm_dev,
+			       struct drm_encoder *encoder)
+{
+	int ret;
+	u32 crtc_mask = drm_of_find_possible_crtcs(drm_dev, dev->of_node);
+
+	if (!crtc_mask) {
+		DRM_ERROR("failed to find crtc mask\n");
+		return -EINVAL;
+	}
+
+	encoder->possible_crtcs = crtc_mask;
+	ret = drm_encoder_init(drm_dev, encoder, &dw_encoder_funcs,
+			       DRM_MODE_ENCODER_DSI, NULL);
+	if (ret) {
+		DRM_ERROR("failed to init dsi encoder\n");
+		return ret;
+	}
+
+	drm_encoder_helper_add(encoder, &dw_encoder_helper_funcs);
+
+	return 0;
+}
+
+static int dsi_bind(struct device *dev, struct device *master, void *data)
+{
+	struct dsi_data *ddata = dev_get_drvdata(dev);
+	struct dw_dsi *dsi = &ddata->dsi;
+	struct drm_device *drm_dev = data;
+	int ret;
+
+	ret = dw_drm_encoder_init(dev, drm_dev, &dsi->encoder);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static void dsi_unbind(struct device *dev, struct device *master, void *data)
+{
+	/* do nothing */
+}
+
+static const struct component_ops dsi_ops = {
+	.bind	= dsi_bind,
+	.unbind	= dsi_unbind,
+};
+
+static int dsi_parse_dt(struct platform_device *pdev, struct dw_dsi *dsi)
+{
+	struct dsi_hw_ctx *ctx = dsi->ctx;
+	struct resource *res;
+
+	ctx->dsi_cfg_clk = devm_clk_get(&pdev->dev, "pclk_dsi");
+	if (IS_ERR(ctx->dsi_cfg_clk)) {
+		DRM_ERROR("failed to get dsi plck clock\n");
+		return PTR_ERR(ctx->dsi_cfg_clk);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	ctx->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(ctx->base)) {
+		DRM_ERROR("failed to remap dsi io region\n");
+		return PTR_ERR(ctx->base);
+	}
+
+	return 0;
+}
+
+static int dsi_probe(struct platform_device *pdev)
+{
+	struct dsi_data *data;
+	struct dw_dsi *dsi;
+	struct dsi_hw_ctx *ctx;
+	int ret;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		DRM_ERROR("failed to allocate dsi data.\n");
+		return -ENOMEM;
+	}
+	dsi = &data->dsi;
+	ctx = &data->ctx;
+	dsi->ctx = ctx;
+
+	ret = dsi_parse_dt(pdev, dsi);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, data);
+
+	return component_add(&pdev->dev, &dsi_ops);
+}
+
+static int dsi_remove(struct platform_device *pdev)
+{
+	component_del(&pdev->dev, &dsi_ops);
+
+	return 0;
+}
+
+static const struct of_device_id dsi_of_match[] = {
+	{.compatible = "hisilicon,hi6220-dsi"},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, dsi_of_match);
+
+static struct platform_driver dsi_driver = {
+	.probe = dsi_probe,
+	.remove = dsi_remove,
+	.driver = {
+		.name = "dw-dsi",
+		.of_match_table = dsi_of_match,
+	},
+};
+
+module_platform_driver(dsi_driver);
+
+MODULE_AUTHOR("Xinliang Liu <xinliang.liu at linaro.org>");
+MODULE_AUTHOR("Xinliang Liu <z.liuxinliang at hisilicon.com>");
+MODULE_AUTHOR("Xinwei Kong <kong.kongxinwei at hisilicon.com>");
+MODULE_DESCRIPTION("DesignWare MIPI DSI Host Controller v1.02 driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h b/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
new file mode 100644
index 000000000000..d3d44b7d2098
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
@@ -0,0 +1,83 @@
+/*
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __DW_DSI_REG_H__
+#define __DW_DSI_REG_H__
+
+#define MASK(x)				(BIT(x) - 1)
+
+/*
+ * regs
+ */
+#define  PWR_UP                  0x04  /* Core power-up */
+#define  PHY_IF_CFG              0xA4  /* D-PHY interface configuration */
+#define  CLKMGR_CFG              0x08  /* the internal clock dividers */
+#define  PHY_RSTZ                0xA0  /* D-PHY reset control */
+#define  PHY_TST_CTRL0           0xB4  /* D-PHY test interface control 0 */
+#define  PHY_TST_CTRL1           0xB8  /* D-PHY test interface control 1 */
+#define  DPI_VCID                0x0C  /* DPI virtual channel id */
+#define  DPI_COLOR_CODING        0x10  /* DPI color coding */
+#define  DPI_CFG_POL             0x14  /* DPI polarity configuration */
+#define  VID_HSA_TIME            0x48  /* Horizontal Sync Active time */
+#define  VID_HBP_TIME            0x4C  /* Horizontal Back Porch time */
+#define  VID_HLINE_TIME          0x50  /* Line time */
+#define  VID_VSA_LINES           0x54  /* Vertical Sync Active period */
+#define  VID_VBP_LINES           0x58  /* Vertical Back Porch period */
+#define  VID_VFP_LINES           0x5C  /* Vertical Front Porch period */
+#define  VID_VACTIVE_LINES       0x60  /* Vertical resolution */
+#define  VID_PKT_SIZE            0x3C  /* Video packet size */
+#define  VID_MODE_CFG            0x38  /* Video mode configuration */
+#define  DPI_LP_CMD_TIM          0x18  /* Low-power command timing config */
+#define  PHY_TMR_CFG             0x9C  /* Data lanes timing configuration */
+#define  BTA_TO_CNT              0x8C  /* Response timeout definition */
+#define  PHY_TMR_LPCLK_CFG       0x98  /* clock lane timing configuration */
+#define  CLK_DATA_TMR_CFG        0xCC
+#define  LPCLK_CTRL              0x94  /* Low-power in clock lane */
+#define  PCKHDL_CFG              0x2C  /* Packet handler configuration */
+#define  EDPI_CMD_SIZE           0x64  /* Size for eDPI packets */
+#define  MODE_CFG                0x34  /* Video or Command mode selection */
+#define  PHY_STATUS              0xB0  /* D-PHY PPI status interface */
+
+#define	PHY_STOP_WAIT_TIME       0x30
+
+/*
+ * regs relevant enum
+ */
+enum dpi_color_coding {
+	DSI_24BITS_1 = 5,
+};
+
+enum dsi_video_mode_type {
+	DSI_NON_BURST_SYNC_PULSES = 0,
+	DSI_NON_BURST_SYNC_EVENTS,
+	DSI_BURST_SYNC_PULSES_1,
+	DSI_BURST_SYNC_PULSES_2
+};
+
+enum dsi_work_mode {
+	DSI_VIDEO_MODE = 0,
+	DSI_COMMAND_MODE
+};
+
+/*
+ * Register Write/Read Helper functions
+ */
+static inline void dw_update_bits(void __iomem *addr, u32 bit_start,
+				  u32 mask, u32 val)
+{
+	u32 tmp, orig;
+
+	orig = readl(addr);
+	tmp = orig & ~(mask << bit_start);
+	tmp |= (val & mask) << bit_start;
+	writel(tmp, addr);
+}
+
+#endif /* __DW_DRM_DSI_H__ */
-- 
1.9.1



From xinliang.liu at linaro.org  Mon Feb 22 19:00:30 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Tue, 23 Feb 2016 11:00:30 +0800
Subject: [PATCH v5 10/11] MAINTAINERS: Add maintainer for hisilicon DRM driver
In-Reply-To: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
References: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456196431-19923-11-git-send-email-xinliang.liu@linaro.org>

Add maintainer and reviewer for hisilicon DRM driver.

v5: None.
v4:
- Add Chen Feng <puck.chen at hisilicon.com> as Designated reviewer.
v3: First version.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 MAINTAINERS | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4978dc19a4d2..b94ac713916a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3774,6 +3774,16 @@ S:	Maintained
 F:	drivers/gpu/drm/gma500
 F:	include/drm/gma500*
 
+DRM DRIVERS FOR HISILICON
+M:	Xinliang Liu <z.liuxinliang at hisilicon.com>
+R:	Xinwei Kong <kong.kongxinwei at hisilicon.com>
+R:	Chen Feng <puck.chen at hisilicon.com>
+L:	dri-devel at lists.freedesktop.org
+T:	git git://github.com/xin3liang/linux.git
+S:	Maintained
+F:	drivers/gpu/drm/hisilicon
+F:	Documentation/devicetree/bindings/display/hisilicon
+
 DRM DRIVERS FOR NVIDIA TEGRA
 M:	Thierry Reding <thierry.reding at gmail.com>
 M:	Terje Bergstr?m <tbergstrom at nvidia.com>
-- 
1.9.1



From xinliang.liu at linaro.org  Mon Feb 22 19:00:31 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Tue, 23 Feb 2016 11:00:31 +0800
Subject: [PATCH v5 11/11] arm64: dts: hisilicon: Add display subsystem DT
 nodes for hi6220
In-Reply-To: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
References: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456196431-19923-12-git-send-email-xinliang.liu@linaro.org>

Add ade, dsi and adv7533 DT nodes for hikey board.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 40 +++++++++++++++++++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi      | 55 ++++++++++++++++++++++++++
 2 files changed, 95 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 818525197508..40239fba0572 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -39,3 +39,43 @@
 &uart3 {
 	label = "LS-UART1";
 };
+
+&ade {
+	status = "okay";
+};
+
+&dsi {
+	status = "ok";
+
+	ports {
+		/* 1 for output port */
+		port at 1 {
+			reg = <1>;
+
+			dsi_out0: endpoint at 0 {
+				remote-endpoint = <&adv7533_in>;
+			};
+		};
+	};
+};
+
+&i2c2 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "ok";
+
+	adv7533: adv7533 at 39 {
+		compatible = "adi,adv7533";
+		reg = <0x39>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <1 2>;
+		pd-gpio = <&gpio0 4 0>;
+		adi,dsi-lanes = <4>;
+
+		port {
+			adv7533_in: endpoint {
+				remote-endpoint = <&dsi_out0>;
+			};
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index ad1f1ebcb05c..920ea68e791d 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -162,6 +162,11 @@
 			#clock-cells = <1>;
 		};
 
+		medianoc_ade: medianoc_ade at f4520000 {
+			compatible = "syscon";
+			reg = <0x0 0xf4520000 0x0 0x4000>;
+		};
+
 		uart0: uart at f8015000 {	/* console */
 			compatible = "arm,pl011", "arm,primecell";
 			reg = <0x0 0xf8015000 0x0 0x1000>;
@@ -209,5 +214,55 @@
 			clock-names = "uartclk", "apb_pclk";
 			status = "disabled";
 		};
+
+		ade: ade at f4100000 {
+			compatible = "hisilicon,hi6220-ade";
+			reg = <0x0 0xf4100000 0x0 0x7800>;
+			reg-names = "ade_base";
+			hisilicon,noc-syscon = <&medianoc_ade>;
+			resets = <&media_ctrl MEDIA_ADE>;
+			interrupts = <0 115 4>; /* ldi interrupt */
+
+			clocks = <&media_ctrl HI6220_ADE_CORE>,
+				 <&media_ctrl HI6220_CODEC_JPEG>,
+				 <&media_ctrl HI6220_ADE_PIX_SRC>;
+			/*clock name*/
+			clock-names  = "clk_ade_core",
+				       "clk_codec_jpeg",
+				       "clk_ade_pix";
+
+			assigned-clocks = <&media_ctrl HI6220_ADE_CORE>,
+				<&media_ctrl HI6220_CODEC_JPEG>;
+			assigned-clock-rates = <360000000>, <288000000>;
+			dma-coherent;
+			status = "disabled";
+
+			port {
+				ade_out: endpoint {
+					remote-endpoint = <&dsi_in>;
+				};
+			};
+		};
+
+		dsi: dsi at f4107800 {
+			compatible = "hisilicon,hi6220-dsi";
+			reg = <0x0 0xf4107800 0x0 0x100>;
+			clocks = <&media_ctrl  HI6220_DSI_PCLK>;
+			clock-names = "pclk_dsi";
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				/* 0 for input port */
+				port at 0 {
+					reg = <0>;
+					dsi_in: endpoint {
+						remote-endpoint = <&ade_out>;
+					};
+				};
+			};
+		};
 	};
 };
-- 
1.9.1



From vinod.koul at intel.com  Mon Feb 22 19:09:37 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 23 Feb 2016 08:39:37 +0530
Subject: [PATCH v2 2/4] dmaengine: xilinx_vdma: Simplify spin lock handling
In-Reply-To: <1456120477-32134-2-git-send-email-appanad@xilinx.com>
References: <1456120477-32134-1-git-send-email-appanad@xilinx.com>
 <1456120477-32134-2-git-send-email-appanad@xilinx.com>
Message-ID: <20160223030937.GH17690@localhost>

On Mon, Feb 22, 2016 at 11:24:35AM +0530, Kedareswara rao Appana wrote:
> This patch simplifies the spin lock handling in the driver.

But sadly doesn't describe how?

> 
> Signed-off-by: Kedareswara rao Appana <appanad at xilinx.com>
> ---
> Changes for v2:
> ---> splitted the changes into multiple patches.
> 
>  drivers/dma/xilinx/xilinx_vdma.c | 27 ++++++++++-----------------
>  1 file changed, 10 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
> index 06bffec..d646218 100644
> --- a/drivers/dma/xilinx/xilinx_vdma.c
> +++ b/drivers/dma/xilinx/xilinx_vdma.c
> @@ -605,17 +605,14 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
>  {
>  	struct xilinx_vdma_config *config = &chan->config;
>  	struct xilinx_vdma_tx_descriptor *desc, *tail_desc;
> -	unsigned long flags;
>  	u32 reg;
>  	struct xilinx_vdma_tx_segment *tail_segment;
>  
>  	if (chan->err)
>  		return;
>  
> -	spin_lock_irqsave(&chan->lock, flags);
> -

It would help if you add a comment to this function taht we need to invoke
this with lock held...

>  	if (list_empty(&chan->pending_list))
> -		goto out_unlock;
> +		return;
>  
>  	desc = list_first_entry(&chan->pending_list,
>  				struct xilinx_vdma_tx_descriptor, node);
> @@ -629,7 +626,7 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
>  	if (chan->has_sg && xilinx_vdma_is_running(chan) &&
>  	    !xilinx_vdma_is_idle(chan)) {
>  		dev_dbg(chan->dev, "DMA controller still busy\n");
> -		goto out_unlock;
> +		return;
>  	}
>  
>  	/*
> @@ -676,7 +673,7 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
>  	xilinx_vdma_start(chan);
>  
>  	if (chan->err)
> -		goto out_unlock;
> +		return;
>  
>  	/* Start the transfer */
>  	if (chan->has_sg) {
> @@ -696,7 +693,7 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
>  		}
>  
>  		if (!last)
> -			goto out_unlock;
> +			return;
>  
>  		/* HW expects these parameters to be same for one transaction */
>  		vdma_desc_write(chan, XILINX_VDMA_REG_HSIZE, last->hw.hsize);
> @@ -707,9 +704,6 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
>  
>  	list_splice_tail_init(&chan->pending_list, &chan->active_list);
>  	chan->desc_pendingcount = 0;
> -
> -out_unlock:
> -	spin_unlock_irqrestore(&chan->lock, flags);
>  }
>  
>  /**
> @@ -719,8 +713,11 @@ out_unlock:
>  static void xilinx_vdma_issue_pending(struct dma_chan *dchan)
>  {
>  	struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
> +	unsigned long flags;
>  
> +	spin_lock_irqsave(&chan->lock, flags);
>  	xilinx_vdma_start_transfer(chan);
> +	spin_unlock_irqrestore(&chan->lock, flags);
>  }
>  
>  /**
> @@ -732,21 +729,15 @@ static void xilinx_vdma_issue_pending(struct dma_chan *dchan)
>  static void xilinx_vdma_complete_descriptor(struct xilinx_vdma_chan *chan)
>  {
>  	struct xilinx_vdma_tx_descriptor *desc, *next;
> -	unsigned long flags;
> -
> -	spin_lock_irqsave(&chan->lock, flags);

this one as well

>  
>  	if (list_empty(&chan->active_list))
> -		goto out_unlock;
> +		return;
>  
>  	list_for_each_entry_safe(desc, next, &chan->active_list, node) {
>  		list_del(&desc->node);
>  		dma_cookie_complete(&desc->async_tx);
>  		list_add_tail(&desc->node, &chan->done_list);
>  	}
> -
> -out_unlock:
> -	spin_unlock_irqrestore(&chan->lock, flags);
>  }
>  
>  /**
> @@ -857,8 +848,10 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq, void *data)
>  	}
>  
>  	if (status & XILINX_VDMA_DMASR_FRM_CNT_IRQ) {
> +		spin_lock(&chan->lock);
>  		xilinx_vdma_complete_descriptor(chan);
>  		xilinx_vdma_start_transfer(chan);
> +		spin_unlock(&chan->lock);
>  	}
>  
>  	tasklet_schedule(&chan->tasklet);
> -- 
> 2.1.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
~Vinod


From vinod.koul at intel.com  Mon Feb 22 19:11:30 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 23 Feb 2016 08:41:30 +0530
Subject: [PATCH v2 4/4] dmaengine: xilinx_vdma: Improve channel idle
 checking
In-Reply-To: <1456120477-32134-4-git-send-email-appanad@xilinx.com>
References: <1456120477-32134-1-git-send-email-appanad@xilinx.com>
 <1456120477-32134-4-git-send-email-appanad@xilinx.com>
Message-ID: <20160223031130.GI17690@localhost>

On Mon, Feb 22, 2016 at 11:24:37AM +0530, Kedareswara rao Appana wrote:
> This patch improves the channel idle cheking by introduing
				      ^^^^^^^^^
typo

> a new varibale in chan private structure.
	^^^^^^^
here too :(

and there is no description how this improvement is achieved and why
> 
> Signed-off-by: Kedareswara rao Appana <appanad at xilinx.com>
> ---
> Changes for v2:
> ---> splitted the changes into multiple patches.
> 
>  drivers/dma/xilinx/xilinx_vdma.c | 41 ++++++++--------------------------------
>  1 file changed, 8 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
> index 8db07f7..51686d1 100644
> --- a/drivers/dma/xilinx/xilinx_vdma.c
> +++ b/drivers/dma/xilinx/xilinx_vdma.c
> @@ -202,6 +202,7 @@ struct xilinx_vdma_tx_descriptor {
>   * @has_sg: Support scatter transfers
>   * @genlock: Support genlock mode
>   * @err: Channel has errors
> + * @idle: Check for channel idle
>   * @tasklet: Cleanup work after irq
>   * @config: Device configuration info
>   * @flush_on_fsync: Flush on Frame sync
> @@ -225,6 +226,7 @@ struct xilinx_vdma_chan {
>  	bool has_sg;
>  	bool genlock;
>  	bool err;
> +	bool idle;
>  	struct tasklet_struct tasklet;
>  	struct xilinx_vdma_config config;
>  	bool flush_on_fsync;
> @@ -519,32 +521,6 @@ static enum dma_status xilinx_vdma_tx_status(struct dma_chan *dchan,
>  }
>  
>  /**
> - * xilinx_vdma_is_running - Check if VDMA channel is running
> - * @chan: Driver specific VDMA channel
> - *
> - * Return: '1' if running, '0' if not.
> - */
> -static bool xilinx_vdma_is_running(struct xilinx_vdma_chan *chan)
> -{
> -	return !(vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
> -		 XILINX_VDMA_DMASR_HALTED) &&
> -		(vdma_ctrl_read(chan, XILINX_VDMA_REG_DMACR) &
> -		 XILINX_VDMA_DMACR_RUNSTOP);
> -}
> -
> -/**
> - * xilinx_vdma_is_idle - Check if VDMA channel is idle
> - * @chan: Driver specific VDMA channel
> - *
> - * Return: '1' if idle, '0' if not.
> - */
> -static bool xilinx_vdma_is_idle(struct xilinx_vdma_chan *chan)
> -{
> -	return vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
> -		XILINX_VDMA_DMASR_IDLE;
> -}
> -
> -/**
>   * xilinx_vdma_halt - Halt VDMA channel
>   * @chan: Driver specific VDMA channel
>   */
> @@ -614,6 +590,9 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
>  	if (list_empty(&chan->pending_list))
>  		return;
>  
> +	if (!chan->idle)
> +		return;
> +
>  	desc = list_first_entry(&chan->pending_list,
>  				struct xilinx_vdma_tx_descriptor, node);
>  	tail_desc = list_last_entry(&chan->pending_list,
> @@ -622,13 +601,6 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
>  	tail_segment = list_last_entry(&tail_desc->segments,
>  				       struct xilinx_vdma_tx_segment, node);
>  
> -	/* If it is SG mode and hardware is busy, cannot submit */
> -	if (chan->has_sg && xilinx_vdma_is_running(chan) &&
> -	    !xilinx_vdma_is_idle(chan)) {
> -		dev_dbg(chan->dev, "DMA controller still busy\n");
> -		return;
> -	}
> -
>  	/*
>  	 * If hardware is idle, then all descriptors on the running lists are
>  	 * done, start new transfers
> @@ -708,6 +680,7 @@ static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
>  
>  	list_splice_tail_init(&chan->pending_list, &chan->active_list);
>  	chan->desc_pendingcount = 0;
> +	chan->idle = false;
>  }
>  
>  /**
> @@ -854,6 +827,7 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq, void *data)
>  	if (status & XILINX_VDMA_DMASR_FRM_CNT_IRQ) {
>  		spin_lock(&chan->lock);
>  		xilinx_vdma_complete_descriptor(chan);
> +		chan->idle = true;
>  		xilinx_vdma_start_transfer(chan);
>  		spin_unlock(&chan->lock);
>  	}
> @@ -1212,6 +1186,7 @@ static int xilinx_vdma_chan_probe(struct xilinx_vdma_device *xdev,
>  
>  	list_add_tail(&chan->common.device_node, &xdev->common.channels);
>  	xdev->chan[chan->id] = chan;
> +	chan->idle = true;
>  
>  	/* Reset the channel */
>  	err = xilinx_vdma_chan_reset(chan);
> -- 
> 2.1.2
> 

-- 
~Vinod


From vinod.koul at intel.com  Mon Feb 22 19:13:36 2016
From: vinod.koul at intel.com (Vinod Koul)
Date: Tue, 23 Feb 2016 08:43:36 +0530
Subject: [PATCH v2 4/4] dmaengine: pxa_dma: fix the maximum requestor line
In-Reply-To: <1455569868-25017-4-git-send-email-robert.jarzmik@free.fr>
References: <1455569868-25017-1-git-send-email-robert.jarzmik@free.fr>
 <1455569868-25017-4-git-send-email-robert.jarzmik@free.fr>
Message-ID: <20160223031335.GJ17690@localhost>

On Mon, Feb 15, 2016 at 09:57:48PM +0100, Robert Jarzmik wrote:
> The current number of requestor lines is limited to 31. This was an
> error of a previous commit, as this number is platform dependent, and is
> actually :
>  - for pxa25x: 40 requestor lines
>  - for pxa27x: 75 requestor lines
>  - for pxa3xx: 100 requestor lines
> 
> The previous testing did not reveal the faulty constant as on pxa[23]xx
> platforms, only camera, MSL and USB are above requestor 32, and in these
> only the camera has a driver using dma.
> 
> Fixes: e87ffbdf0697 ("dmaengine: pxa_dma: fix the no-requestor case")
> Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>

Acked-by: Vinod Koul <vinod.koul at intel.com>

Which tree is this targetted thru?

-- 
~Vinod


From xinliang.liu at linaro.org  Mon Feb 22 19:11:19 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Tue, 23 Feb 2016 11:11:19 +0800
Subject: [PATCH v2] drm: Clean up drm Makefile
In-Reply-To: <20160209095047.GK11240@phenom.ffwll.local>
References: <1454641830-19307-1-git-send-email-xinliang.liu@linaro.org>
 <20160209095047.GK11240@phenom.ffwll.local>
Message-ID: <CAGd==057Wsb1OX_JFKMfOajFUPFP1OBjb4fBRu8SME-wjPGYDA@mail.gmail.com>

On 9 February 2016 at 17:50, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Fri, Feb 05, 2016 at 11:10:30AM +0800, Xinliang Liu wrote:
>> This patch cleans up the Makefile of drm root directory.
>> Make core and device drivers configuration list sorted Alphabetically.
>>
>> Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
>> Reviewed-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
>> Reviewed-by: Yifan Liu <liu_fanyi at 163.com>
>> ---
>>  drivers/gpu/drm/Makefile | 102 ++++++++++++++++++++++++-----------------------
>>  1 file changed, 52 insertions(+), 50 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 61766dec6a8d..23e57948f68f 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -2,6 +2,9 @@
>>  # Makefile for the drm device driver.  This driver provides support for the
>>  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>>
>> +CFLAGS_drm_trace_points.o := -I$(src)
>> +
>> +# core. Please keep this list sorted alphabetically
>>  drm-y       :=       drm_auth.o drm_bufs.o drm_cache.o \
>>               drm_context.o drm_dma.o \
>>               drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
>> @@ -13,64 +16,63 @@ drm-y       :=    drm_auth.o drm_bufs.o drm_cache.o \
>>               drm_trace_points.o drm_global.o drm_prime.o \
>>               drm_rect.o drm_vma_manager.o drm_flip_work.o \
>>               drm_modeset_lock.o drm_atomic.o drm_bridge.o
>> -
>> -drm-$(CONFIG_COMPAT) += drm_ioc32.o
>> -drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
>>  drm-$(CONFIG_PCI) += ati_pcigart.o
>> -drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>> -drm-$(CONFIG_OF) += drm_of.o
>>  drm-$(CONFIG_AGP) += drm_agpsupport.o
>> +drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
>> +drm-$(CONFIG_COMPAT) += drm_ioc32.o
>> +drm-$(CONFIG_OF) += drm_of.o
>> +drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>> +obj-$(CONFIG_DRM)    += drm.o
>> +
>> +obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
>>
>>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
>>               drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
>>  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>> -drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
>>  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
>> -
>> +drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
>>  obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
>>
>> -CFLAGS_drm_trace_points.o := -I$(src)
>> +obj-$(CONFIG_DRM_TTM) += ttm/
>>
>> -obj-$(CONFIG_DRM)    += drm.o
>> -obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
>> -obj-$(CONFIG_DRM_TTM)        += ttm/
>> -obj-$(CONFIG_DRM_TDFX)       += tdfx/
>> -obj-$(CONFIG_DRM_R128)       += r128/
>> -obj-$(CONFIG_HSA_AMD) += amd/amdkfd/
>> -obj-$(CONFIG_DRM_RADEON)+= radeon/
>> -obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
>> -obj-$(CONFIG_DRM_MGA)        += mga/
>> -obj-$(CONFIG_DRM_I810)       += i810/
>> -obj-$(CONFIG_DRM_I915)  += i915/
>> -obj-$(CONFIG_DRM_MGAG200) += mgag200/
>> -obj-$(CONFIG_DRM_VC4)  += vc4/
>> -obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
>> -obj-$(CONFIG_DRM_SIS)   += sis/
>> -obj-$(CONFIG_DRM_SAVAGE)+= savage/
>> -obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
>> -obj-$(CONFIG_DRM_VIA)        +=via/
>> -obj-$(CONFIG_DRM_VGEM)       += vgem/
>> -obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
>> -obj-$(CONFIG_DRM_EXYNOS) +=exynos/
>> -obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
>> -obj-$(CONFIG_DRM_GMA500) += gma500/
>> -obj-$(CONFIG_DRM_UDL) += udl/
>> -obj-$(CONFIG_DRM_AST) += ast/
>> -obj-$(CONFIG_DRM_ARMADA) += armada/
>> +# device drivers. Please keep this list sorted alphabetically
>> +obj-$(CONFIG_HSA_AMD)                += amd/amdkfd/
>
> No mention of this exception (needs a comment), and no mention of what you
> changed in v2 of the patch. Please fix and resend.

will fix and resend.

Best,
-xinliang

> -Daniel
>
>> +obj-$(CONFIG_DRM_AMDGPU)     += amd/amdgpu/
>> +obj-$(CONFIG_DRM_ARMADA)     += armada/
>> +obj-$(CONFIG_DRM_AST)                += ast/
>>  obj-$(CONFIG_DRM_ATMEL_HLCDC)        += atmel-hlcdc/
>> -obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
>> -obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
>> -obj-y                        += omapdrm/
>> -obj-y                        += tilcdc/
>> -obj-$(CONFIG_DRM_QXL) += qxl/
>> -obj-$(CONFIG_DRM_BOCHS) += bochs/
>> -obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio/
>> -obj-$(CONFIG_DRM_MSM) += msm/
>> -obj-$(CONFIG_DRM_TEGRA) += tegra/
>> -obj-$(CONFIG_DRM_STI) += sti/
>> -obj-$(CONFIG_DRM_IMX) += imx/
>> -obj-y                        += i2c/
>> -obj-y                        += panel/
>> -obj-y                        += bridge/
>> -obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
>> -obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
>> +obj-$(CONFIG_DRM_BOCHS)              += bochs/
>> +obj-y                                += bridge/
>> +obj-$(CONFIG_DRM_CIRRUS_QEMU)        += cirrus/
>> +obj-$(CONFIG_DRM_ETNAVIV)    += etnaviv/
>> +obj-$(CONFIG_DRM_EXYNOS)     += exynos/
>> +obj-$(CONFIG_DRM_FSL_DCU)    += fsl-dcu/
>> +obj-$(CONFIG_DRM_GMA500)     += gma500/
>> +obj-y                                += i2c/
>> +obj-$(CONFIG_DRM_I810)               += i810/
>> +obj-$(CONFIG_DRM_I915)               += i915/
>> +obj-$(CONFIG_DRM_IMX)                += imx/
>> +obj-$(CONFIG_DRM_MGA)                += mga/
>> +obj-$(CONFIG_DRM_MGAG200)    += mgag200/
>> +obj-$(CONFIG_DRM_MSM)                += msm/
>> +obj-$(CONFIG_DRM_NOUVEAU)    += nouveau/
>> +obj-y                                += omapdrm/
>> +obj-y                                += panel/
>> +obj-$(CONFIG_DRM_QXL)                += qxl/
>> +obj-$(CONFIG_DRM_R128)               += r128/
>> +obj-$(CONFIG_DRM_RADEON)     += radeon/
>> +obj-$(CONFIG_DRM_RCAR_DU)    += rcar-du/
>> +obj-$(CONFIG_DRM_ROCKCHIP)   += rockchip/
>> +obj-$(CONFIG_DRM_SAVAGE)     += savage/
>> +obj-$(CONFIG_DRM_SHMOBILE)   += shmobile/
>> +obj-$(CONFIG_DRM_SIS)                += sis/
>> +obj-$(CONFIG_DRM_STI)                += sti/
>> +obj-$(CONFIG_DRM_TDFX)               += tdfx/
>> +obj-$(CONFIG_DRM_TEGRA)              += tegra/
>> +obj-y                                += tilcdc/
>> +obj-$(CONFIG_DRM_UDL)                += udl/
>> +obj-$(CONFIG_DRM_VC4)                += vc4/
>> +obj-$(CONFIG_DRM_VGEM)               += vgem/
>> +obj-$(CONFIG_DRM_VIA)                += via/
>> +obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio/
>> +obj-$(CONFIG_DRM_VMWGFX)     += vmwgfx/
>> --
>> 1.9.1
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch


From dongas86 at gmail.com  Mon Feb 22 19:45:28 2016
From: dongas86 at gmail.com (Dong Aisheng)
Date: Tue, 23 Feb 2016 11:45:28 +0800
Subject: [PATCH V3 0/5] clk: support clocks which requires parent clock on
 during operation
In-Reply-To: <CAOMZO5ATOkkw3wCaBeyr7NaVPekuyPNkhDu3c1G3Wv=VtcydjA@mail.gmail.com>
References: <1438089585-30103-1-git-send-email-aisheng.dong@freescale.com>
 <20150728143824.GB16916@shlinux1.ap.freescale.net>
 <20150804094556.GE24870@shlinux1.ap.freescale.net>
 <20150813101702.GB19166@shlinux1.ap.freescale.net>
 <CAOMZO5ATOkkw3wCaBeyr7NaVPekuyPNkhDu3c1G3Wv=VtcydjA@mail.gmail.com>
Message-ID: <CAA+hA=QLEk6mwciX4nLfmAMYahtenoL9+zR_YJ4veSkh-3uLEQ@mail.gmail.com>

On Mon, Feb 22, 2016 at 10:55 PM, Fabio Estevam <festevam at gmail.com> wrote:
> Hi Mike,
>
> On Thu, Aug 13, 2015 at 7:17 AM, Dong Aisheng
> <aisheng.dong at freescale.com> wrote:
>
>> Hi Mike,
>>
>> It's been quite a long time.
>> Can you help pick this?
>
> Yes, we are still getting lots of clock warnings in mx7d in mainline
> without Dong's series:
>

Hi Mike & Stephen,

It's been pending a long time.

What's your fix plan?
Can we merge this patch series first?
I believe there're also other platforms need this fix too.

Regards
Dong Aisheng


> [    0.000000] ------------[ cut here ]------------
> [    0.000000] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:3382
> lock_release+0x2f8/0x334()
> [    0.000000] releasing a pinned lock
> [    0.000000] Modules linked in:
> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 4.5.0-rc5-next-20160222 #256
> [    0.000000] Hardware name: Freescale i.MX7 Dual (Device Tree)
> [    0.000000] Backtrace:
> [    0.000000] [<c010b6f4>] (dump_backtrace) from [<c010b890>]
> (show_stack+0x18/0x1c)
> [    0.000000]  r6:600000d3 r5:ffffffff r4:00000000 r3:00000000
> [    0.000000] [<c010b878>] (show_stack) from [<c03dae8c>]
> (dump_stack+0xb0/0xe8)
> [    0.000000] [<c03daddc>] (dump_stack) from [<c012461c>]
> (warn_slowpath_common+0x80/0xbc)
> [    0.000000]  r8:c0ad86ec r7:00000009 r6:00000d36 r5:c0169e5c
> r4:c0d01ba0 r3:c0d064c0
> [    0.000000] [<c012459c>] (warn_slowpath_common) from [<c01246fc>]
> (warn_slowpath_fmt+0x38/0x40)
> [    0.000000]  r8:c0d06980 r7:00000002 r6:00000001 r5:c0d064c0 r4:ef7c2290
> [    0.000000] [<c01246c8>] (warn_slowpath_fmt) from [<c0169e5c>]
> (lock_release+0x2f8/0x334)
> [    0.000000]  r3:00000026 r2:c0ad9698
> [    0.000000] [<c0169b64>] (lock_release) from [<c08e31f8>]
> (_raw_spin_unlock_irq+0x20/0x34)
> [    0.000000]  r10:c0c75280 r9:ef7c2280 r8:00000000 r7:c0d02b10
> r6:00000001 r5:ef7c2280
> [    0.000000]  r4:ef7c2280
> [    0.000000] [<c08e31d8>] (_raw_spin_unlock_irq) from [<c015219c>]
> (dequeue_task_idle+0x14/0x30)
> [    0.000000]  r4:ef7c2280 r3:c0152188
> [    0.000000] [<c0152188>] (dequeue_task_idle) from [<c0149a50>]
> (deactivate_task+0x64/0x68)
> [    0.000000]  r4:c0d064c0 r3:c0152188
> [    0.000000] [<c01499ec>] (deactivate_task) from [<c08ddd68>]
> (__schedule+0x2cc/0x6d8)
> [    0.000000]  r6:c0d06804 r5:ef7c2290 r4:c0d064c0 r3:00000002
> [    0.000000] [<c08dda9c>] (__schedule) from [<c08de29c>] (schedule+0x3c/0xa0)
> [    0.000000]  r10:c0d064c0 r9:c1560db8 r8:00000001 r7:00000000
> r6:0006ddd0 r5:00000000
> [    0.000000]  r4:0007a120
> [    0.000000] [<c08de260>] (schedule) from [<c08e28b0>]
> (schedule_hrtimeout_range_clock+0xd4/0x13c)
> [    0.000000] [<c08e27dc>] (schedule_hrtimeout_range_clock) from
> [<c08e293c>] (schedule_hrtimeout_range+0x24/0x2c)
> [    0.000000]  r10:000006d8 r8:000000d8 r7:00000003 r6:ffff8ad1
> r5:c0d02100 r4:ef00c040
> [    0.000000] [<c08e2918>] (schedule_hrtimeout_range) from
> [<c08e2360>] (usleep_range+0x54/0x5c)
> [    0.000000] [<c08e230c>] (usleep_range) from [<c068b83c>]
> (clk_pllv3_wait_lock+0x7c/0xb4)
> [    0.000000] [<c068b7c0>] (clk_pllv3_wait_lock) from [<c068ba4c>]
> (clk_pllv3_prepare+0x2c/0x30)
> [    0.000000]  r6:c0d5c7f4 r5:00000000 r4:ef007680 r3:f08400f0
> [    0.000000] [<c068ba20>] (clk_pllv3_prepare) from [<c0685e08>]
> (clk_core_prepare+0xa0/0xcc)
> [    0.000000] [<c0685d68>] (clk_core_prepare) from [<c0685e54>]
> (clk_prepare+0x20/0x30)
> [    0.000000]  r5:00000000 r4:ef00c100
> [    0.000000] [<c0685e34>] (clk_prepare) from [<c0c4a700>]
> (imx7d_clocks_init+0x6114/0x6198)
> [    0.000000]  r4:ef00c100 r3:c0d064c0
> [    0.000000] [<c0c445ec>] (imx7d_clocks_init) from [<c0c30c08>]
> (of_clk_init+0x138/0x1e8)
> [    0.000000]  r10:c0d01f70 r9:00000001 r8:c0d01f68 r7:00000000
> r6:ef004340 r5:ef7e3d60
> [    0.000000]  r4:00000003
> [    0.000000] [<c0c30ad0>] (of_clk_init) from [<c0c049f0>]
> (time_init+0x2c/0x38)
> [    0.000000]  r10:00000001 r9:410fc075 r8:efffcb80 r7:c0c5ca48
> r6:c0d76000 r5:ffffffff
> [    0.000000]  r4:00000000
> [    0.000000] [<c0c049c4>] (time_init) from [<c0c00bcc>]
> (start_kernel+0x26c/0x400)
> [    0.000000] [<c0c00960>] (start_kernel) from [<8000807c>] (0x8000807c)
> [    0.000000]  r10:00000000 r8:8000406a r7:c0d07e4c r6:c0c5ca44
> r5:c0d0296c r4:c0d76294
> [    0.000000] ---[ end trace cb88537fdc8fa200 ]---
> [    0.000000] ------------[ cut here ]------------
> [    0.000000] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2576
> trace_hardirqs_on_caller+0x1ac/0x1f0()
> [    0.000000] DEBUG_LOCKS_WARN_ON(unlikely(early_boot_irqs_disabled))
> [    0.000000] Modules linked in:
> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
> 4.5.0-rc5-next-20160222 #256
> [    0.000000] Hardware name: Freescale i.MX7 Dual (Device Tree)
> [    0.000000] Backtrace:
> [    0.000000] [<c010b6f4>] (dump_backtrace) from [<c010b890>]
> (show_stack+0x18/0x1c)
> [    0.000000]  r6:600000d3 r5:ffffffff r4:00000000 r3:00000000
> [    0.000000] [<c010b878>] (show_stack) from [<c03dae8c>]
> (dump_stack+0xb0/0xe8)
> [    0.000000] [<c03daddc>] (dump_stack) from [<c012461c>]
> (warn_slowpath_common+0x80/0xbc)
> [    0.000000]  r8:c0ad86ec r7:00000009 r6:00000a10 r5:c016a948
> r4:c0d01bc8 r3:c0d064c0
> [    0.000000] [<c012459c>] (warn_slowpath_common) from [<c01246fc>]
> (warn_slowpath_fmt+0x38/0x40)
> [    0.000000]  r8:00000000 r7:c0d02b10 r6:00000001 r5:ef7c2280 r4:c08e3204
> [    0.000000] [<c01246c8>] (warn_slowpath_fmt) from [<c016a948>]
> (trace_hardirqs_on_caller+0x1ac/0x1f0)
> [    0.000000]  r3:c0ad9700 r2:c0ad5cc8
> [    0.000000] [<c016a79c>] (trace_hardirqs_on_caller) from
> [<c016a9a0>] (trace_hardirqs_on+0x14/0x18)
> [    0.000000]  r6:00000001 r5:ef7c2280 r4:ef7c2280 r3:600000d3
> [    0.000000] [<c016a98c>] (trace_hardirqs_on) from [<c08e3204>]
> (_raw_spin_unlock_irq+0x2c/0x34)
> [    0.000000] [<c08e31d8>] (_raw_spin_unlock_irq) from [<c015219c>]
> (dequeue_task_idle+0x14/0x30)
> [    0.000000]  r4:ef7c2280 r3:c0152188
> [    0.000000] [<c0152188>] (dequeue_task_idle) from [<c0149a50>]
> (deactivate_task+0x64/0x68)
> [    0.000000]  r4:c0d064c0 r3:c0152188
> [    0.000000] [<c01499ec>] (deactivate_task) from [<c08ddd68>]
> (__schedule+0x2cc/0x6d8)
> [    0.000000]  r6:c0d06804 r5:ef7c2290 r4:c0d064c0 r3:00000002
> [    0.000000] [<c08dda9c>] (__schedule) from [<c08de29c>] (schedule+0x3c/0xa0)
> [    0.000000]  r10:c0d064c0 r9:c1560db8 r8:00000001 r7:00000000
> r6:0006ddd0 r5:00000000
> [    0.000000]  r4:0007a120
> [    0.000000] [<c08de260>] (schedule) from [<c08e28b0>]
> (schedule_hrtimeout_range_clock+0xd4/0x13c)
> [    0.000000] [<c08e27dc>] (schedule_hrtimeout_range_clock) from
> [<c08e293c>] (schedule_hrtimeout_range+0x24/0x2c)
> [    0.000000]  r10:000006d8 r8:000000d8 r7:00000003 r6:ffff8ad1
> r5:c0d02100 r4:ef00c040
> [    0.000000] [<c08e2918>] (schedule_hrtimeout_range) from
> [<c08e2360>] (usleep_range+0x54/0x5c)
> [    0.000000] [<c08e230c>] (usleep_range) from [<c068b83c>]
> (clk_pllv3_wait_lock+0x7c/0xb4)
> [    0.000000] [<c068b7c0>] (clk_pllv3_wait_lock) from [<c068ba4c>]
> (clk_pllv3_prepare+0x2c/0x30)
> [    0.000000]  r6:c0d5c7f4 r5:00000000 r4:ef007680 r3:f08400f0
> [    0.000000] [<c068ba20>] (clk_pllv3_prepare) from [<c0685e08>]
> (clk_core_prepare+0xa0/0xcc)
> [    0.000000] [<c0685d68>] (clk_core_prepare) from [<c0685e54>]
> (clk_prepare+0x20/0x30)
> [    0.000000]  r5:00000000 r4:ef00c100
> [    0.000000] [<c0685e34>] (clk_prepare) from [<c0c4a700>]
> (imx7d_clocks_init+0x6114/0x6198)
> [    0.000000]  r4:ef00c100 r3:c0d064c0
> [    0.000000] [<c0c445ec>] (imx7d_clocks_init) from [<c0c30c08>]
> (of_clk_init+0x138/0x1e8)
> [    0.000000]  r10:c0d01f70 r9:00000001 r8:c0d01f68 r7:00000000
> r6:ef004340 r5:ef7e3d60
> [    0.000000]  r4:00000003
> [    0.000000] [<c0c30ad0>] (of_clk_init) from [<c0c049f0>]
> (time_init+0x2c/0x38)
> [    0.000000]  r10:00000001 r9:410fc075 r8:efffcb80 r7:c0c5ca48
> r6:c0d76000 r5:ffffffff
> [    0.000000]  r4:00000000
> [    0.000000] [<c0c049c4>] (time_init) from [<c0c00bcc>]
> (start_kernel+0x26c/0x400)
> [    0.000000] [<c0c00960>] (start_kernel) from [<8000807c>] (0x8000807c)
> [    0.000000]  r10:00000000 r8:8000406a r7:c0d07e4c r6:c0c5ca44
> r5:c0d0296c r4:c0d76294
> [    0.000000] ---[ end trace cb88537fdc8fa201 ]---
> [    0.000000] bad: scheduling from the idle thread!
> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
> 4.5.0-rc5-next-20160222 #256
> [    0.000000] Hardware name: Freescale i.MX7 Dual (Device Tree)
> [    0.000000] Backtrace:
> [    0.000000] [<c010b6f4>] (dump_backtrace) from [<c010b890>]
> (show_stack+0x18/0x1c)
> [    0.000000]  r6:60000053 r5:ffffffff r4:00000000 r3:00000000
> [    0.000000] [<c010b878>] (show_stack) from [<c03dae8c>]
> (dump_stack+0xb0/0xe8)
> [    0.000000] [<c03daddc>] (dump_stack) from [<c01521a8>]
> (dequeue_task_idle+0x20/0x30)
> [    0.000000]  r8:00000000 r7:c0d02b10 r6:00000001 r5:ef7c2280
> r4:ef7c2280 r3:c0d064c0
> [    0.000000] [<c0152188>] (dequeue_task_idle) from [<c0149a50>]
> (deactivate_task+0x64/0x68)
> [    0.000000]  r4:c0d064c0 r3:c0152188
> [    0.000000] [<c01499ec>] (deactivate_task) from [<c08ddd68>]
> (__schedule+0x2cc/0x6d8)
> [    0.000000]  r6:c0d06804 r5:ef7c2290 r4:c0d064c0 r3:00000002
> [    0.000000] [<c08dda9c>] (__schedule) from [<c08de29c>] (schedule+0x3c/0xa0)
> [    0.000000]  r10:c0d064c0 r9:c1560db8 r8:00000001 r7:00000000
> r6:0006ddd0 r5:00000000
> [    0.000000]  r4:0007a120
> [    0.000000] [<c08de260>] (schedule) from [<c08e28b0>]
> (schedule_hrtimeout_range_clock+0xd4/0x13c)
> [    0.000000] [<c08e27dc>] (schedule_hrtimeout_range_clock) from
> [<c08e293c>] (schedule_hrtimeout_range+0x24/0x2c)
> [    0.000000]  r10:000006d8 r8:000000d8 r7:00000003 r6:ffff8ad1
> r5:c0d02100 r4:ef00c040
> [    0.000000] [<c08e2918>] (schedule_hrtimeout_range) from
> [<c08e2360>] (usleep_range+0x54/0x5c)
> [    0.000000] [<c08e230c>] (usleep_range) from [<c068b83c>]
> (clk_pllv3_wait_lock+0x7c/0xb4)
> [    0.000000] [<c068b7c0>] (clk_pllv3_wait_lock) from [<c068ba4c>]
> (clk_pllv3_prepare+0x2c/0x30)
> [    0.000000]  r6:c0d5c7f4 r5:00000000 r4:ef007680 r3:f08400f0
> [    0.000000] [<c068ba20>] (clk_pllv3_prepare) from [<c0685e08>]
> (clk_core_prepare+0xa0/0xcc)
> [    0.000000] [<c0685d68>] (clk_core_prepare) from [<c0685e54>]
> (clk_prepare+0x20/0x30)
> [    0.000000]  r5:00000000 r4:ef00c100
> [    0.000000] [<c0685e34>] (clk_prepare) from [<c0c4a700>]
> (imx7d_clocks_init+0x6114/0x6198)
> [    0.000000]  r4:ef00c100 r3:c0d064c0
> [    0.000000] [<c0c445ec>] (imx7d_clocks_init) from [<c0c30c08>]
> (of_clk_init+0x138/0x1e8)
> [    0.000000]  r10:c0d01f70 r9:00000001 r8:c0d01f68 r7:00000000
> r6:ef004340 r5:ef7e3d60
> [    0.000000]  r4:00000003
> [    0.000000] [<c0c30ad0>] (of_clk_init) from [<c0c049f0>]
> (time_init+0x2c/0x38)
> [    0.000000]  r10:00000001 r9:410fc075 r8:efffcb80 r7:c0c5ca48
> r6:c0d76000 r5:ffffffff
> [    0.000000]  r4:00000000
> [    0.000000] [<c0c049c4>] (time_init) from [<c0c00bcc>]
> (start_kernel+0x26c/0x400)
> [    0.000000] [<c0c00960>] (start_kernel) from [<8000807c>] (0x8000807c)
> [    0.000000]  r10:00000000 r8:8000406a r7:c0d07e4c r6:c0c5ca44
> r5:c0d0296c r4:c0d76294
> [    0.000000] Architected cp15 timer(s) running at 8.00MHz (virt).
> [    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
> max_cycles: 0x1d854df40, max_idle_ns: 440795202120 ns
> [    0.000000] ------------[ cut here ]------------
> [    0.000000] WARNING: CPU: 0 PID: 0 at kernel/time/sched_clock.c:179
> sched_clock_register+0x44/0x1f8()
> [    0.000000] Modules linked in:
> [    0.000000] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
> 4.5.0-rc5-next-20160222 #256
> [    0.000000] Hardware name: Freescale i.MX7 Dual (Device Tree)
> [    0.000000] Backtrace:
> [    0.000000] [<c010b6f4>] (dump_backtrace) from [<c010b890>]
> (show_stack+0x18/0x1c)
> [    0.000000]  r6:60000053 r5:ffffffff r4:00000000 r3:00000000
> [    0.000000] [<c010b878>] (show_stack) from [<c03dae8c>]
> (dump_stack+0xb0/0xe8)
> [    0.000000] [<c03daddc>] (dump_stack) from [<c012461c>]
> (warn_slowpath_common+0x80/0xbc)
> [    0.000000]  r8:c0add580 r7:00000009 r6:000000b3 r5:c0c13a40
> r4:00000000 r3:c0d064c0
> [    0.000000] [<c012459c>] (warn_slowpath_common) from [<c012467c>]
> (warn_slowpath_null+0x24/0x2c)
> [    0.000000]  r8:007a1200 r7:c155f688 r6:c0d5b2c0 r5:9ffdbd98 r4:a3aaa0c5
> [    0.000000] [<c0124658>] (warn_slowpath_null) from [<c0c13a40>]
> (sched_clock_register+0x44/0x1f8)
> [    0.000000] [<c0c139fc>] (sched_clock_register) from [<c0c2de48>]
> (arch_timer_common_init+0x1d4/0x234)
> [    0.000000]  r10:c0b5a5b4 r9:00000008 r8:c0ae2f94 r7:c155f688
> r6:c0d5b2c0 r5:9ffdbd98
> [    0.000000]  r4:a3aaa0c5
> [    0.000000] [<c0c2dc74>] (arch_timer_common_init) from [<c0c2e174>]
> (arch_timer_of_init+0x2cc/0x30c)
> [    0.000000]  r10:00000001 r9:410fc075 r8:efffcb80 r7:c0c5ca48
> r6:00000001 r5:00000000
> [    0.000000]  r4:00000012
> [    0.000000] [<c0c2dea8>] (arch_timer_of_init) from [<c0c2db24>]
> (clocksource_probe+0x50/0x94)
> [    0.000000]  r6:00000001 r5:c0d01f84 r4:ef7dae9c r3:c0c2dea8
> [    0.000000] [<c0c2dad4>] (clocksource_probe) from [<c0c049f4>]
> (time_init+0x30/0x38)
> [    0.000000]  r6:c0d76000 r5:ffffffff r4:00000000
> [    0.000000] [<c0c049c4>] (time_init) from [<c0c00bcc>]
> (start_kernel+0x26c/0x400)
> [    0.000000] [<c0c00960>] (start_kernel) from [<8000807c>] (0x8000807c)
> [    0.000000]  r10:00000000 r8:8000406a r7:c0d07e4c r6:c0c5ca44
> r5:c0d0296c r4:c0d76294
> [    0.000000] ---[ end trace cb88537fdc8fa202 ]---
> [    0.000007] sched_clock: 56 bits at 8MHz, resolution 125ns, wraps
> every 2199023255500ns
> [    0.000023] Switching to timer-based delay loop, resolution 125ns
> [    0.000603] Switching to timer-based delay loop, resolution 41ns
> [    0.000614] ------------[ cut here ]------------
> [    0.000632] WARNING: CPU: 0 PID: 0 at kernel/time/sched_clock.c:179
> sched_clock_register+0x44/0x1f8()
> [    0.000641] Modules linked in:
> [    0.000658] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
> 4.5.0-rc5-next-20160222 #256
> [    0.000668] Hardware name: Freescale i.MX7 Dual (Device Tree)
> [    0.000676] Backtrace:
> [    0.000700] [<c010b6f4>] (dump_backtrace) from [<c010b890>]
> (show_stack+0x18/0x1c)
> [    0.000710]  r6:60000053 r5:ffffffff r4:00000000 r3:00000000
> [    0.000746] [<c010b878>] (show_stack) from [<c03dae8c>]
> (dump_stack+0xb0/0xe8)
> [    0.000763] [<c03daddc>] (dump_stack) from [<c012461c>]
> (warn_slowpath_common+0x80/0xbc)
> [    0.000773]  r8:c0add580 r7:00000009 r6:000000b3 r5:c0c13a40
> r4:00000000 r3:c0d064c0
> [    0.000813] [<c012459c>] (warn_slowpath_common) from [<c012467c>]
> (warn_slowpath_null+0x24/0x2c)
> [    0.000823]  r8:016e3600 r7:f0880024 r6:016e3600 r5:c155f6f0 r4:ef002400
> [    0.000863] [<c0124658>] (warn_slowpath_null) from [<c0c13a40>]
> (sched_clock_register+0x44/0x1f8)
> [    0.000881] [<c0c139fc>] (sched_clock_register) from [<c0c2e8a4>]
> (_mxc_timer_init+0x148/0x240)
> [    0.000891]  r10:00000001 r9:410fc075 r8:c0b5a984 r7:f0880024
> r6:016e3600 r5:c155f6f0
> [    0.000926]  r4:ef002400
> [    0.000945] [<c0c2e75c>] (_mxc_timer_init) from [<c0c2ea54>]
> (mxc_timer_init_dt+0xb8/0xe8)
> [    0.000955]  r8:efffcb80 r7:00000003 r6:00000000 r5:ef7e084c r4:ef002400
> [    0.000996] [<c0c2e99c>] (mxc_timer_init_dt) from [<c0c2ea98>]
> (imx6dl_timer_init_dt+0x14/0x18)
> [    0.001006]  r7:c0c5ca48 r6:00000002 r5:c0d01f84 r4:ef7e084c
> [    0.001041] [<c0c2ea84>] (imx6dl_timer_init_dt) from [<c0c2db24>]
> (clocksource_probe+0x50/0x94)
> [    0.001061] [<c0c2dad4>] (clocksource_probe) from [<c0c049f4>]
> (time_init+0x30/0x38)
> [    0.001071]  r6:c0d76000 r5:ffffffff r4:00000000
> [    0.001102] [<c0c049c4>] (time_init) from [<c0c00bcc>]
> (start_kernel+0x26c/0x400)
> [    0.001119] [<c0c00960>] (start_kernel) from [<8000807c>] (0x8000807c)
> [    0.001128]  r10:00000000 r8:8000406a r7:c0d07e4c r6:c0c5ca44
> r5:c0d0296c r4:c0d76294
> [    0.001164] ---[ end trace cb88537fdc8fa203 ]---
> [    0.001183] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps
> every 89478484971ns
> [    0.001201] clocksource: mxc_timer1: mask: 0xffffffff max_cycles:
> 0xffffffff, max_idle_ns: 79635851949 ns
> [    0.002139] ------------[ cut here ]------------
> [    0.002161] WARNING: CPU: 0 PID: 0 at init/main.c:593
> start_kernel+0x298/0x400()
> [    0.002170] Interrupts were enabled early
> [    0.002179] Modules linked in:
> [    0.002195] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
> 4.5.0-rc5-next-20160222 #256
> [    0.002205] Hardware name: Freescale i.MX7 Dual (Device Tree)
> [    0.002214] Backtrace:
> [    0.002237] [<c010b6f4>] (dump_backtrace) from [<c010b890>]
> (show_stack+0x18/0x1c)
> [    0.002247]  r6:60000053 r5:ffffffff r4:00000000 r3:00000000
> [    0.002283] [<c010b878>] (show_stack) from [<c03dae8c>]
> (dump_stack+0xb0/0xe8)
> [    0.002300] [<c03daddc>] (dump_stack) from [<c012461c>]
> (warn_slowpath_common+0x80/0xbc)
> [    0.002310]  r8:c0ace4a0 r7:00000009 r6:00000251 r5:c0c00bf8
> r4:c0d01f98 r3:c0d064c0
> [    0.002351] [<c012459c>] (warn_slowpath_common) from [<c01246fc>]
> (warn_slowpath_fmt+0x38/0x40)
> [    0.002361]  r8:efffcb80 r7:c0c5ca48 r6:c0d76000 r5:ffffffff r4:00000000
> [    0.002402] [<c01246c8>] (warn_slowpath_fmt) from [<c0c00bf8>]
> (start_kernel+0x298/0x400)
> [    0.002413]  r3:60000053 r2:c0ace4e0
> [    0.002436] [<c0c00960>] (start_kernel) from [<8000807c>] (0x8000807c)
> [    0.002446]  r10:00000000 r8:8000406a r7:c0d07e4c r6:c0c5ca44
> r5:c0d0296c r4:c0d76294
> [    0.002482] ---[ end trace cb88537fdc8fa204 ]---
> [    0.002594] Console: colour dummy device 80x30
> [    0.002607] Lock dependency validator: Copyright (c) 2006 Red Hat,
> Inc., Ingo Molnar
> [    0.002616] ... MAX_LOCKDEP_SUBCLASSES:  8
> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From shankerd at codeaurora.org  Mon Feb 22 19:57:48 2016
From: shankerd at codeaurora.org (Shanker Donthineni)
Date: Mon, 22 Feb 2016 21:57:48 -0600
Subject: [PATCH] irqchip/gicv3-its: Don't allow devices whose ID is outside
 range
Message-ID: <1456199868-9054-1-git-send-email-shankerd@codeaurora.org>

We are not checking whether the requested device identifier fits into
table or not. The ITS MAPD command fails if 'Device ID' is outside of
device table range.

Add a simple validation check to avoid MAPD failures since we are
not handling ITS command errors. This change also helps to return an
error -ENOMEM instead of success to caller.

Signed-off-by: Shanker Donthineni <shankerd at codeaurora.org>
---
This patch depends on https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/gic-4.5-fixes&id=2eca0d6ceea1f108b2d3ac81fb34698c4fd41006

 drivers/irqchip/irq-gic-v3-its.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index c0f227a..9bdcdf5 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -70,6 +70,7 @@ struct its_node {
 	struct {
 		void		*base;
 		u32		order;
+		u32		entry_size;
 	} tables[GITS_BASER_NR_REGS];
 	struct its_collection	*collections;
 	struct list_head	its_device_list;
@@ -880,6 +881,7 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
 					node_name, order);
 			}
 		}
+		its->tables[type].entry_size = entry_size;
 
 retry_alloc_baser:
 		alloc_pages = (PAGE_ORDER_TO_SIZE(order) / psz);
@@ -896,8 +898,8 @@ retry_alloc_baser:
 			goto out_free;
 		}
 
-		its->tables[i].base = base;
-		its->tables[i].order = order;
+		its->tables[type].base = base;
+		its->tables[type].order = order;
 
 retry_baser:
 		val = (virt_to_phys(base) 				 |
@@ -947,7 +949,7 @@ retry_baser:
 			 * something is horribly wrong...
 			 */
 			free_pages((unsigned long)base, order);
-			its->tables[i].base = NULL;
+			its->tables[type].base = NULL;
 
 			switch (psz) {
 			case SZ_16K:
@@ -1152,12 +1154,22 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id,
 	unsigned long *lpi_map;
 	unsigned long flags;
 	u16 *col_map = NULL;
+	u8 type = GITS_BASER_TYPE_DEVICE;
+	u32 entry_size;
+	u32 order;
 	void *itt;
 	int lpi_base;
 	int nr_lpis;
 	int nr_ites;
 	int sz;
 
+	entry_size = its->tables[type].entry_size;
+	order = its->tables[type].order;
+
+	/* Don't allow 'dev_id' that exceeds single, flat table limit */
+	if (dev_id >= (PAGE_ORDER_TO_SIZE(order) / entry_size))
+		return NULL;
+
 	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
 	/*
 	 * At least one bit of EventID is being used, hence a minimum
-- 
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
a Linux Foundation Collaborative Project



From appana.durga.rao at xilinx.com  Mon Feb 22 20:19:03 2016
From: appana.durga.rao at xilinx.com (Appana Durga Kedareswara Rao)
Date: Tue, 23 Feb 2016 04:19:03 +0000
Subject: [PATCH v2 2/4] dmaengine: xilinx_vdma: Simplify spin lock handling
In-Reply-To: <20160223030937.GH17690@localhost>
References: <1456120477-32134-1-git-send-email-appanad@xilinx.com>
 <1456120477-32134-2-git-send-email-appanad@xilinx.com>
 <20160223030937.GH17690@localhost>
Message-ID: <C246CAC1457055469EF09E3A7AC4E11A4A561D18@XAP-PVEXMBX01.xlnx.xilinx.com>

Hi Vinod,

> -----Original Message-----
> From: Vinod Koul [mailto:vinod.koul at intel.com]
> Sent: Tuesday, February 23, 2016 8:40 AM
> To: Appana Durga Kedareswara Rao
> Cc: dan.j.williams at intel.com; Michal Simek; Soren Brinkmann; Appana Durga
> Kedareswara Rao; moritz.fischer at ettus.com;
> laurent.pinchart at ideasonboard.com; luis at debethencourt.com; Anirudha
> Sarangi; dmaengine at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org
> Subject: Re: [PATCH v2 2/4] dmaengine: xilinx_vdma: Simplify spin lock handling
> 
> On Mon, Feb 22, 2016 at 11:24:35AM +0530, Kedareswara rao Appana wrote:
> > This patch simplifies the spin lock handling in the driver.
> 
> But sadly doesn't describe how?

Ok sure will improve commit message in the next version.

> 
> >
> > Signed-off-by: Kedareswara rao Appana <appanad at xilinx.com>
> > ---
> > Changes for v2:
> > ---> splitted the changes into multiple patches.
> >
> >  drivers/dma/xilinx/xilinx_vdma.c | 27 ++++++++++-----------------
> >  1 file changed, 10 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/dma/xilinx/xilinx_vdma.c
> > b/drivers/dma/xilinx/xilinx_vdma.c
> > index 06bffec..d646218 100644
> > --- a/drivers/dma/xilinx/xilinx_vdma.c
> > +++ b/drivers/dma/xilinx/xilinx_vdma.c
> > @@ -605,17 +605,14 @@ static void xilinx_vdma_start_transfer(struct
> > xilinx_vdma_chan *chan)  {
> >  	struct xilinx_vdma_config *config = &chan->config;
> >  	struct xilinx_vdma_tx_descriptor *desc, *tail_desc;
> > -	unsigned long flags;
> >  	u32 reg;
> >  	struct xilinx_vdma_tx_segment *tail_segment;
> >
> >  	if (chan->err)
> >  		return;
> >
> > -	spin_lock_irqsave(&chan->lock, flags);
> > -
> 
> It would help if you add a comment to this function taht we need to invoke this
> with lock held...

Ok sure will add comment..

> 
> >  	if (list_empty(&chan->pending_list))
> > -		goto out_unlock;
> > +		return;
> >
> >  	desc = list_first_entry(&chan->pending_list,
> >  				struct xilinx_vdma_tx_descriptor, node); @@ -
> 629,7 +626,7 @@
> > static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
> >  	if (chan->has_sg && xilinx_vdma_is_running(chan) &&
> >  	    !xilinx_vdma_is_idle(chan)) {
> >  		dev_dbg(chan->dev, "DMA controller still busy\n");
> > -		goto out_unlock;
> > +		return;
> >  	}
> >
> >  	/*
> > @@ -676,7 +673,7 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> >  	xilinx_vdma_start(chan);
> >
> >  	if (chan->err)
> > -		goto out_unlock;
> > +		return;
> >
> >  	/* Start the transfer */
> >  	if (chan->has_sg) {
> > @@ -696,7 +693,7 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> >  		}
> >
> >  		if (!last)
> > -			goto out_unlock;
> > +			return;
> >
> >  		/* HW expects these parameters to be same for one
> transaction */
> >  		vdma_desc_write(chan, XILINX_VDMA_REG_HSIZE, last-
> >hw.hsize); @@
> > -707,9 +704,6 @@ static void xilinx_vdma_start_transfer(struct
> > xilinx_vdma_chan *chan)
> >
> >  	list_splice_tail_init(&chan->pending_list, &chan->active_list);
> >  	chan->desc_pendingcount = 0;
> > -
> > -out_unlock:
> > -	spin_unlock_irqrestore(&chan->lock, flags);
> >  }
> >
> >  /**
> > @@ -719,8 +713,11 @@ out_unlock:
> >  static void xilinx_vdma_issue_pending(struct dma_chan *dchan)  {
> >  	struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
> > +	unsigned long flags;
> >
> > +	spin_lock_irqsave(&chan->lock, flags);
> >  	xilinx_vdma_start_transfer(chan);
> > +	spin_unlock_irqrestore(&chan->lock, flags);
> >  }
> >
> >  /**
> > @@ -732,21 +729,15 @@ static void xilinx_vdma_issue_pending(struct
> > dma_chan *dchan)  static void xilinx_vdma_complete_descriptor(struct
> > xilinx_vdma_chan *chan)  {
> >  	struct xilinx_vdma_tx_descriptor *desc, *next;
> > -	unsigned long flags;
> > -
> > -	spin_lock_irqsave(&chan->lock, flags);
> 
> this one as well

Ok sure will add comment..

Regards,
Kedar.

> 
> >
> >  	if (list_empty(&chan->active_list))
> > -		goto out_unlock;
> > +		return;
> >
> >  	list_for_each_entry_safe(desc, next, &chan->active_list, node) {
> >  		list_del(&desc->node);
> >  		dma_cookie_complete(&desc->async_tx);
> >  		list_add_tail(&desc->node, &chan->done_list);
> >  	}
> > -
> > -out_unlock:
> > -	spin_unlock_irqrestore(&chan->lock, flags);
> >  }
> >
> >  /**
> > @@ -857,8 +848,10 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq,
> void *data)
> >  	}
> >
> >  	if (status & XILINX_VDMA_DMASR_FRM_CNT_IRQ) {
> > +		spin_lock(&chan->lock);
> >  		xilinx_vdma_complete_descriptor(chan);
> >  		xilinx_vdma_start_transfer(chan);
> > +		spin_unlock(&chan->lock);
> >  	}
> >
> >  	tasklet_schedule(&chan->tasklet);
> > --
> > 2.1.2
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe dmaengine"
> > in the body of a message to majordomo at vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> ~Vinod


From appana.durga.rao at xilinx.com  Mon Feb 22 20:21:32 2016
From: appana.durga.rao at xilinx.com (Appana Durga Kedareswara Rao)
Date: Tue, 23 Feb 2016 04:21:32 +0000
Subject: [PATCH v2 4/4] dmaengine: xilinx_vdma: Improve channel idle
 checking
In-Reply-To: <20160223031130.GI17690@localhost>
References: <1456120477-32134-1-git-send-email-appanad@xilinx.com>
 <1456120477-32134-4-git-send-email-appanad@xilinx.com>
 <20160223031130.GI17690@localhost>
Message-ID: <C246CAC1457055469EF09E3A7AC4E11A4A561D2C@XAP-PVEXMBX01.xlnx.xilinx.com>

Hi Vinod,

> -----Original Message-----
> From: Vinod Koul [mailto:vinod.koul at intel.com]
> Sent: Tuesday, February 23, 2016 8:42 AM
> To: Appana Durga Kedareswara Rao
> Cc: dan.j.williams at intel.com; Michal Simek; Soren Brinkmann; Appana Durga
> Kedareswara Rao; moritz.fischer at ettus.com;
> laurent.pinchart at ideasonboard.com; luis at debethencourt.com; Anirudha
> Sarangi; dmaengine at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-kernel at vger.kernel.org
> Subject: Re: [PATCH v2 4/4] dmaengine: xilinx_vdma: Improve channel idle
> checking
> 
> On Mon, Feb 22, 2016 at 11:24:37AM +0530, Kedareswara rao Appana wrote:
> > This patch improves the channel idle cheking by introduing
> 				      ^^^^^^^^^
> typo

Ok will fix.

> 
> > a new varibale in chan private structure.
> 	^^^^^^^
> here too :(

Ok will fix.

> 
> and there is no description how this improvement is achieved and why

Ok will give detailed explanation in the next version of the patch.

Regards,
Kedar.

> >
> > Signed-off-by: Kedareswara rao Appana <appanad at xilinx.com>
> > ---
> > Changes for v2:
> > ---> splitted the changes into multiple patches.
> >
> >  drivers/dma/xilinx/xilinx_vdma.c | 41
> > ++++++++--------------------------------
> >  1 file changed, 8 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/dma/xilinx/xilinx_vdma.c
> > b/drivers/dma/xilinx/xilinx_vdma.c
> > index 8db07f7..51686d1 100644
> > --- a/drivers/dma/xilinx/xilinx_vdma.c
> > +++ b/drivers/dma/xilinx/xilinx_vdma.c
> > @@ -202,6 +202,7 @@ struct xilinx_vdma_tx_descriptor {
> >   * @has_sg: Support scatter transfers
> >   * @genlock: Support genlock mode
> >   * @err: Channel has errors
> > + * @idle: Check for channel idle
> >   * @tasklet: Cleanup work after irq
> >   * @config: Device configuration info
> >   * @flush_on_fsync: Flush on Frame sync @@ -225,6 +226,7 @@ struct
> > xilinx_vdma_chan {
> >  	bool has_sg;
> >  	bool genlock;
> >  	bool err;
> > +	bool idle;
> >  	struct tasklet_struct tasklet;
> >  	struct xilinx_vdma_config config;
> >  	bool flush_on_fsync;
> > @@ -519,32 +521,6 @@ static enum dma_status
> > xilinx_vdma_tx_status(struct dma_chan *dchan,  }
> >
> >  /**
> > - * xilinx_vdma_is_running - Check if VDMA channel is running
> > - * @chan: Driver specific VDMA channel
> > - *
> > - * Return: '1' if running, '0' if not.
> > - */
> > -static bool xilinx_vdma_is_running(struct xilinx_vdma_chan *chan) -{
> > -	return !(vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
> > -		 XILINX_VDMA_DMASR_HALTED) &&
> > -		(vdma_ctrl_read(chan, XILINX_VDMA_REG_DMACR) &
> > -		 XILINX_VDMA_DMACR_RUNSTOP);
> > -}
> > -
> > -/**
> > - * xilinx_vdma_is_idle - Check if VDMA channel is idle
> > - * @chan: Driver specific VDMA channel
> > - *
> > - * Return: '1' if idle, '0' if not.
> > - */
> > -static bool xilinx_vdma_is_idle(struct xilinx_vdma_chan *chan) -{
> > -	return vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
> > -		XILINX_VDMA_DMASR_IDLE;
> > -}
> > -
> > -/**
> >   * xilinx_vdma_halt - Halt VDMA channel
> >   * @chan: Driver specific VDMA channel
> >   */
> > @@ -614,6 +590,9 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> >  	if (list_empty(&chan->pending_list))
> >  		return;
> >
> > +	if (!chan->idle)
> > +		return;
> > +
> >  	desc = list_first_entry(&chan->pending_list,
> >  				struct xilinx_vdma_tx_descriptor, node);
> >  	tail_desc = list_last_entry(&chan->pending_list,
> > @@ -622,13 +601,6 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> >  	tail_segment = list_last_entry(&tail_desc->segments,
> >  				       struct xilinx_vdma_tx_segment, node);
> >
> > -	/* If it is SG mode and hardware is busy, cannot submit */
> > -	if (chan->has_sg && xilinx_vdma_is_running(chan) &&
> > -	    !xilinx_vdma_is_idle(chan)) {
> > -		dev_dbg(chan->dev, "DMA controller still busy\n");
> > -		return;
> > -	}
> > -
> >  	/*
> >  	 * If hardware is idle, then all descriptors on the running lists are
> >  	 * done, start new transfers
> > @@ -708,6 +680,7 @@ static void xilinx_vdma_start_transfer(struct
> > xilinx_vdma_chan *chan)
> >
> >  	list_splice_tail_init(&chan->pending_list, &chan->active_list);
> >  	chan->desc_pendingcount = 0;
> > +	chan->idle = false;
> >  }
> >
> >  /**
> > @@ -854,6 +827,7 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq, void
> *data)
> >  	if (status & XILINX_VDMA_DMASR_FRM_CNT_IRQ) {
> >  		spin_lock(&chan->lock);
> >  		xilinx_vdma_complete_descriptor(chan);
> > +		chan->idle = true;
> >  		xilinx_vdma_start_transfer(chan);
> >  		spin_unlock(&chan->lock);
> >  	}
> > @@ -1212,6 +1186,7 @@ static int xilinx_vdma_chan_probe(struct
> > xilinx_vdma_device *xdev,
> >
> >  	list_add_tail(&chan->common.device_node, &xdev-
> >common.channels);
> >  	xdev->chan[chan->id] = chan;
> > +	chan->idle = true;
> >
> >  	/* Reset the channel */
> >  	err = xilinx_vdma_chan_reset(chan);
> > --
> > 2.1.2
> >
> 
> --
> ~Vinod


From yamada.masahiro at socionext.com  Mon Feb 22 20:40:21 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Tue, 23 Feb 2016 13:40:21 +0900
Subject: [PATCH] arm64: dts: uniphier: rename PH1-LD10 to PH1-LD20
Message-ID: <1456202421-10857-1-git-send-email-yamada.masahiro@socionext.com>

Due to the company's awful projecting, this chip has been renamed to
PH1-LD20.  It has not been shipped yet, this change would not give
much impact on our customers.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

Olof, Arnd,

Please apply this patch along with my series
"[PATCH 0/9] ARM: uniphier: UniPhier updates for Linux 4.6-rc1".

If it goes to a different branch, it will cause a big merge conflict later.


 arch/arm64/boot/dts/socionext/Makefile                            | 2 +-
 .../{uniphier-ph1-ld10-ref.dts => uniphier-ph1-ld20-ref.dts}      | 8 ++++----
 .../socionext/{uniphier-ph1-ld10.dtsi => uniphier-ph1-ld20.dtsi}  | 6 +++---
 3 files changed, 8 insertions(+), 8 deletions(-)
 rename arch/arm64/boot/dts/socionext/{uniphier-ph1-ld10-ref.dts => uniphier-ph1-ld20-ref.dts} (92%)
 rename arch/arm64/boot/dts/socionext/{uniphier-ph1-ld10.dtsi => uniphier-ph1-ld20.dtsi} (98%)

diff --git a/arch/arm64/boot/dts/socionext/Makefile b/arch/arm64/boot/dts/socionext/Makefile
index 8d72771..299b67e 100644
--- a/arch/arm64/boot/dts/socionext/Makefile
+++ b/arch/arm64/boot/dts/socionext/Makefile
@@ -1,4 +1,4 @@
-dtb-$(CONFIG_ARCH_UNIPHIER) += uniphier-ph1-ld10-ref.dtb
+dtb-$(CONFIG_ARCH_UNIPHIER) += uniphier-ph1-ld20-ref.dtb
 
 always		:= $(dtb-y)
 clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts
similarity index 92%
rename from arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
rename to arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts
index e5c8a20..727ae5f 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts
@@ -1,5 +1,5 @@
 /*
- * Device Tree Source for UniPhier PH1-LD10 Reference Board
+ * Device Tree Source for UniPhier PH1-LD20 Reference Board
  *
  * Copyright (C) 2015 Masahiro Yamada <yamada.masahiro at socionext.com>
  *
@@ -43,12 +43,12 @@
  */
 
 /dts-v1/;
-/include/ "uniphier-ph1-ld10.dtsi"
+/include/ "uniphier-ph1-ld20.dtsi"
 /include/ "uniphier-support-card.dtsi"
 
 / {
-	model = "UniPhier PH1-LD10 Reference Board";
-	compatible = "socionext,ph1-ld10-ref", "socionext,ph1-ld10";
+	model = "UniPhier PH1-LD20 Reference Board";
+	compatible = "socionext,ph1-ld20-ref", "socionext,ph1-ld20";
 
 	memory {
 		device_type = "memory";
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
similarity index 98%
rename from arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
rename to arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
index 84637eb..65e9651 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
@@ -1,5 +1,5 @@
 /*
- * Device Tree Source for UniPhier PH1-LD10 SoC
+ * Device Tree Source for UniPhier PH1-LD20 SoC
  *
  * Copyright (C) 2015 Masahiro Yamada <yamada.masahiro at socionext.com>
  *
@@ -43,7 +43,7 @@
  */
 
 / {
-	compatible = "socionext,ph1-ld10";
+	compatible = "socionext,ph1-ld20";
 	#address-cells = <2>;
 	#size-cells = <2>;
 	interrupt-parent = <&gic>;
@@ -268,7 +268,7 @@
 		};
 
 		pinctrl: pinctrl at 5f801000 {
-			compatible = "socionext,ph1-ld10-pinctrl", "syscon";
+			compatible = "socionext,ph1-ld20-pinctrl", "syscon";
 			reg = <0x5f801000 0xe00>;
 		};
 
-- 
1.9.1



From Wenyou.Yang at atmel.com  Mon Feb 22 21:59:30 2016
From: Wenyou.Yang at atmel.com (Yang, Wenyou)
Date: Tue, 23 Feb 2016 05:59:30 +0000
Subject: [PATCH] mtd: atmel_nand: move the hsmc_clk from nfc node to
 nand node
In-Reply-To: <56CB05A6.100@atmel.com>
References: <1455687624-9488-1-git-send-email-wenyou.yang@atmel.com>
 <56CB05A6.100@atmel.com>
Message-ID: <B256D81BAE5131468A838E5D7A243641D6428357@penmbx01>



> -----Original Message-----
> From: Ferre, Nicolas
> Sent: 2016?2?22? 20:57
> To: Yang, Wenyou <Wenyou.Yang at atmel.com>; Brian Norris
> <computersforpeace at gmail.com>; David Woodhouse <dwmw2 at infradead.org>;
> Josh Wu <rainyfeeling at outlook.com>
> Cc: linux-mtd at lists.infradead.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; Wu, Josh <Josh.wu at atmel.com>
> Subject: Re: [PATCH] mtd: atmel_nand: move the hsmc_clk from nfc node to nand
> node
> 
> Le 17/02/2016 06:40, Wenyou Yang a ?crit :
> > From: Josh Wu <josh.wu at atmel.com>
> >
> > For sama5d3, sama5d4 chip, the pmecc becomes a part of HSMC, they need
> > the HSMC clock to be enabled to work.
> > The NFC is a sub feature for current nand driver, it can be disabled.
> > But if HSMC clock is controlled by NFC, so disable NFC will also
> > disable the HSMC clock. then, it will make the PMECC fail to work.
> >
> > So the solution is to move the HSMC clock out of NFC to nand node.
> > When nand driver probed, it will check whether the chip has HSMC, if
> > yes then it will require a HSMC clock.
> >
> > Signed-off-by: Josh Wu <josh.wu at atmel.com>
> > Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> > ---
> >
> >  .../devicetree/bindings/mtd/atmel-nand.txt         |    4 +-
> >  drivers/mtd/nand/atmel_nand.c                      |   43 +++++++++-----------
> >  2 files changed, 22 insertions(+), 25 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > index d53aba9..29bee7c 100644
> > --- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > +++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > @@ -15,6 +15,7 @@ Required properties:
> >  - atmel,nand-cmd-offset : offset for the command latch.
> >  - #address-cells, #size-cells : Must be present if the device has sub-nodes
> >    representing partitions.
> > +- clocks: phandle to the peripheral clock
> >
> >  - gpios : specifies the gpio pins to control the NAND device. detect is an
> >    optional gpio and may be set to 0 if not present.
> > @@ -43,7 +44,6 @@ Required properties:
> >  - reg : should specify the address and size used for NFC command registers,
> >          NFC registers and NFC SRAM. NFC SRAM address and size can be
> absent
> >          if don't want to use it.
> > -- clocks: phandle to the peripheral clock  Optional properties:
> >  - atmel,write-by-sram: boolean to enable NFC write by SRAM.
> >
> > @@ -100,13 +100,13 @@ nand0: nand at 40000000 {
> >  	compatible = "atmel,at91rm9200-nand";
> >  	#address-cells = <1>;
> >  	#size-cells = <1>;
> > +	clocks = <&hsmc_clk>
> >  	ranges;
> >          ...
> >          nfc at 70000000 {
> >  		compatible = "atmel,sama5d3-nfc";
> >  		#address-cells = <1>;
> >  		#size-cells = <1>;
> > -		clocks = <&hsmc_clk>
> >  		reg = <
> >  			0x70000000 0x10000000	/* NFC Command
> Registers */
> >  			0xffffc000 0x00000070	/* NFC HSMC regs */
> > diff --git a/drivers/mtd/nand/atmel_nand.c
> > b/drivers/mtd/nand/atmel_nand.c index 20cbaab..a1f4ad2 100644
> > --- a/drivers/mtd/nand/atmel_nand.c
> > +++ b/drivers/mtd/nand/atmel_nand.c
> > @@ -66,6 +66,7 @@ module_param(on_flash_bbt, int, 0);  struct
> > atmel_nand_caps {
> >  	bool pmecc_correct_erase_page;
> >  	uint8_t pmecc_max_correction;
> > +	bool has_hsmc_clk;
> >  };
> >
> >  struct atmel_nand_nfc_caps {
> > @@ -106,8 +107,6 @@ struct atmel_nfc {
> >  	bool			use_nfc_sram;
> >  	bool			write_by_sram;
> >
> > -	struct clk		*clk;
> > -
> >  	bool			is_initialized;
> >  	struct completion	comp_ready;
> >  	struct completion	comp_cmd_done;
> > @@ -132,6 +131,7 @@ struct atmel_nand_host {
> >  	struct dma_chan		*dma_chan;
> >
> >  	struct atmel_nfc	*nfc;
> > +	struct clk		*clk;
> >
> >  	const struct atmel_nand_caps	*caps;
> >  	bool			has_pmecc;
> > @@ -2157,6 +2157,19 @@ static int atmel_nand_probe(struct platform_device
> *pdev)
> >  	nand_chip->IO_ADDR_R = host->io_base;
> >  	nand_chip->IO_ADDR_W = host->io_base;
> >
> > +	if (host->caps->has_hsmc_clk) {
> > +		host->clk = devm_clk_get(&pdev->dev, NULL);
> > +		if (IS_ERR(host->clk)) {
> > +			dev_err(&pdev->dev, "HSMC clock is missing, update
> your Device Tree");
> > +			res = PTR_ERR(host->clk);
> > +			goto err_nand_ioremap;
> > +		}
> > +
> > +		res = clk_prepare_enable(host->clk);
> > +		if (res)
> > +			goto err_nand_ioremap;
> > +	}
> > +
> >  	if (nand_nfc.is_initialized) {
> >  		/* NFC driver is probed and initialized */
> >  		host->nfc = &nand_nfc;
> > @@ -2321,6 +2334,9 @@ static int atmel_nand_remove(struct platform_device
> *pdev)
> >  	if (host->dma_chan)
> >  		dma_release_channel(host->dma_chan);
> >
> > +	if (!IS_ERR(host->clk))
> > +		clk_disable_unprepare(host->clk);
> > +
> >  	platform_driver_unregister(&atmel_nand_nfc_driver);
> >
> >  	return 0;
> > @@ -2334,11 +2350,13 @@ static int atmel_nand_remove(struct
> > platform_device *pdev)  static const struct atmel_nand_caps at91rm9200_caps
> = {
> >  	.pmecc_correct_erase_page = false,
> >  	.pmecc_max_correction = 24,
> > +	.has_hsmc_clk = false,
> >  };
> >
> >  static const struct atmel_nand_caps sama5d4_caps = {
> >  	.pmecc_correct_erase_page = true,
> >  	.pmecc_max_correction = 24,
> > +	.has_hsmc_clk = true,
> 
> As this capability is not shared with SAMA5D3, I didn't see how you could make
> the hsmc clock probed on SAMA5D3: remember, its controller compatibility string
> is "atmel,at91rm9200-nand" with the description just above.

Sorry.
It is my carelessness, missing the " atmel,sama5d3-nand" compatible string part. I will add it.

> 
> Bye,
> 
> 
> >  };
> >
> >  /*
> > @@ -2363,7 +2381,6 @@ static int atmel_nand_nfc_probe(struct
> > platform_device *pdev)  {
> >  	struct atmel_nfc *nfc = &nand_nfc;
> >  	struct resource *nfc_cmd_regs, *nfc_hsmc_regs, *nfc_sram;
> > -	int ret;
> >
> >  	nfc_cmd_regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >  	nfc->base_cmd_regs = devm_ioremap_resource(&pdev->dev,
> > nfc_cmd_regs); @@ -2401,31 +2418,12 @@ static int
> atmel_nand_nfc_probe(struct platform_device *pdev)
> >  	nfc_writel(nfc->hsmc_regs, IDR, 0xffffffff);
> >  	nfc_readl(nfc->hsmc_regs, SR);	/* clear the NFC_SR */
> >
> > -	nfc->clk = devm_clk_get(&pdev->dev, NULL);
> > -	if (!IS_ERR(nfc->clk)) {
> > -		ret = clk_prepare_enable(nfc->clk);
> > -		if (ret)
> > -			return ret;
> > -	} else {
> > -		dev_warn(&pdev->dev, "NFC clock missing, update your Device
> Tree");
> > -	}
> > -
> >  	nfc->is_initialized = true;
> >  	dev_info(&pdev->dev, "NFC is probed.\n");
> >
> >  	return 0;
> >  }
> >
> > -static int atmel_nand_nfc_remove(struct platform_device *pdev) -{
> > -	struct atmel_nfc *nfc = &nand_nfc;
> > -
> > -	if (!IS_ERR(nfc->clk))
> > -		clk_disable_unprepare(nfc->clk);
> > -
> > -	return 0;
> > -}
> > -
> >  static const struct atmel_nand_nfc_caps sama5d3_nfc_caps = {
> >  	.rb_mask = NFC_SR_RB_EDGE0,
> >  };
> > @@ -2447,7 +2445,6 @@ static struct platform_driver atmel_nand_nfc_driver =
> {
> >  		.of_match_table = of_match_ptr(atmel_nand_nfc_match),
> >  	},
> >  	.probe = atmel_nand_nfc_probe,
> > -	.remove = atmel_nand_nfc_remove,
> >  };
> >
> >  static struct platform_driver atmel_nand_driver = {
> >
> 
> 
> --
> Nicolas Ferre


Best Regards,
Wenyou Yang

From Wenyou.Yang at atmel.com  Mon Feb 22 22:02:55 2016
From: Wenyou.Yang at atmel.com (Yang, Wenyou)
Date: Tue, 23 Feb 2016 06:02:55 +0000
Subject: [PATCH] ARM: at91: sama5/dts: move hsmc_clk out of nfc node
In-Reply-To: <56CB05EF.9020105@atmel.com>
References: <1455687741-9625-1-git-send-email-wenyou.yang@atmel.com>
 <56CB05EF.9020105@atmel.com>
Message-ID: <B256D81BAE5131468A838E5D7A243641D642838E@penmbx01>



> -----Original Message-----
> From: Ferre, Nicolas
> Sent: 2016?2?22? 20:58
> To: Yang, Wenyou <Wenyou.Yang at atmel.com>; Rob Herring
> <robh+dt at kernel.org>; Pawel Moll <pawel.moll at arm.com>; Mark Brown
> <broonie at kernel.org>; Ian Campbell <ijc+devicetree at hellion.org.uk>; Kumar
> Gala <galak at codeaurora.org>; Alexandre Belloni <alexandre.belloni at free-
> electrons.com>; Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>;
> Russell King <linux at arm.linux.org.uk>
> Cc: linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org; Wu, Josh <Josh.wu at atmel.com>; Josh Wu
> <rainyfeeling at outlook.com>; Alexandre Belloni <alexandre.belloni at free-
> electrons.com>
> Subject: Re: [PATCH] ARM: at91: sama5/dts: move hsmc_clk out of nfc node
> 
> Le 17/02/2016 06:42, Wenyou Yang a ?crit :
> > From: Josh Wu <josh.wu at atmel.com>
> >
> > In sama5d3, sama5d4 chips, pmecc will use the hsmc clock. As pmecc is
> > part of HSMC. So move out hsmc_clk from nfc node to nand node.
> >
> > Signed-off-by: Josh Wu <rainyfeeling at outlook.com>
> > Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> 
> I'm not against this change, but beware, it must be applied in synchronization with
> the patch just posted "[PATCH] mtd: atmel_nand:
> move the hsmc_clk from nfc node to nand node"

Okay, revert the mail address to the original one, keep it consistent.

And add this address to CC. 

> 
> Bye,
> 
> 
> > ---
> >
> >  arch/arm/boot/dts/sama5d3.dtsi |    2 +-
> >  arch/arm/boot/dts/sama5d4.dtsi |    2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sama5d3.dtsi
> > b/arch/arm/boot/dts/sama5d3.dtsi index a532791..a242d27 100644
> > --- a/arch/arm/boot/dts/sama5d3.dtsi
> > +++ b/arch/arm/boot/dts/sama5d3.dtsi
> > @@ -1474,6 +1474,7 @@
> >  			atmel,nand-has-dma;
> >  			pinctrl-names = "default";
> >  			pinctrl-0 = <&pinctrl_nand0_ale_cle>;
> > +			clocks = <&hsmc_clk>;
> >  			atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
> >  			status = "disabled";
> >
> > @@ -1486,7 +1487,6 @@
> >  					0xffffc000 0x00000070	/* NFC HSMC
> regs */
> >  					0x00200000 0x00100000	/* NFC
> SRAM banks */
> >  					>;
> > -				clocks = <&hsmc_clk>;
> >  			};
> >  		};
> >  	};
> > diff --git a/arch/arm/boot/dts/sama5d4.dtsi
> > b/arch/arm/boot/dts/sama5d4.dtsi index b8032bc..1499b33 100644
> > --- a/arch/arm/boot/dts/sama5d4.dtsi
> > +++ b/arch/arm/boot/dts/sama5d4.dtsi
> > @@ -295,6 +295,7 @@
> >  			atmel,nand-has-dma;
> >  			pinctrl-names = "default";
> >  			pinctrl-0 = <&pinctrl_nand>;
> > +			clocks = <&hsmc_clk>;
> >  			status = "disabled";
> >
> >  			nfc at 90000000 {
> > @@ -306,7 +307,6 @@
> >  					0xfc05c000 0x00000070	/* NFC
> HSMC regs */
> >  					0x00100000 0x00100000	/* NFC
> SRAM banks */
> >                                           >;
> > -				clocks = <&hsmc_clk>;
> >  				atmel,write-by-sram;
> >  			};
> >  		};
> >
> 
> 
> --
> Nicolas Ferre


Best Regards,
Wenyou Yang

From wenyou.yang at atmel.com  Mon Feb 22 22:00:20 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Tue, 23 Feb 2016 14:00:20 +0800
Subject: [PATCH v3] mtd: atmel_nand: move the hsmc_clk from nfc node to nand
 node
Message-ID: <1456207220-7757-1-git-send-email-wenyou.yang@atmel.com>

From: Josh Wu <josh.wu at atmel.com>

For SAMA5D3, SAMA5D4 SoC family, PMECC becomes a part of HSMC, they
need the HSMC clock enabled to work.
The NFC is a sub feature for current nand driver, it can be disabled.
But if HSMC clock is controlled by NFC, so disable NFC will also disable
the HSMC clock. then, it will make the PMECC fail to work.

So the solution is move the HSMC clock out of NFC to nand node. When
nand driver probed, it will check whether the chip has HSMC, if yes then
it will require a HSMC clock.

Add a new "atmel,sama5d3-nand" compatiable string for SAMA5D3's nand.

Signed-off-by: Josh Wu <josh.wu at atmel.com>
Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---

Changes in v3:
 - add "atmel,sama5d3-nand" compatiable string for SAMA5D3's nand.
 - revert the mail address of Josh's Signed-off to the original.

Changes in v2:
 - add missing .has_hsmc_clk assignment for sama5d2_caps.

 .../devicetree/bindings/mtd/atmel-nand.txt         |    4 +-
 drivers/mtd/nand/atmel_nand.c                      |   51 +++++++++++---------
 2 files changed, 30 insertions(+), 25 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index d53aba9..29bee7c 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -15,6 +15,7 @@ Required properties:
 - atmel,nand-cmd-offset : offset for the command latch.
 - #address-cells, #size-cells : Must be present if the device has sub-nodes
   representing partitions.
+- clocks: phandle to the peripheral clock
 
 - gpios : specifies the gpio pins to control the NAND device. detect is an
   optional gpio and may be set to 0 if not present.
@@ -43,7 +44,6 @@ Required properties:
 - reg : should specify the address and size used for NFC command registers,
         NFC registers and NFC SRAM. NFC SRAM address and size can be absent
         if don't want to use it.
-- clocks: phandle to the peripheral clock
 Optional properties:
 - atmel,write-by-sram: boolean to enable NFC write by SRAM.
 
@@ -100,13 +100,13 @@ nand0: nand at 40000000 {
 	compatible = "atmel,at91rm9200-nand";
 	#address-cells = <1>;
 	#size-cells = <1>;
+	clocks = <&hsmc_clk>
 	ranges;
         ...
         nfc at 70000000 {
 		compatible = "atmel,sama5d3-nfc";
 		#address-cells = <1>;
 		#size-cells = <1>;
-		clocks = <&hsmc_clk>
 		reg = <
 			0x70000000 0x10000000	/* NFC Command Registers */
 			0xffffc000 0x00000070	/* NFC HSMC regs */
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 20cbaab..482251c 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -66,6 +66,7 @@ module_param(on_flash_bbt, int, 0);
 struct atmel_nand_caps {
 	bool pmecc_correct_erase_page;
 	uint8_t pmecc_max_correction;
+	bool has_hsmc_clk;
 };
 
 struct atmel_nand_nfc_caps {
@@ -106,8 +107,6 @@ struct atmel_nfc {
 	bool			use_nfc_sram;
 	bool			write_by_sram;
 
-	struct clk		*clk;
-
 	bool			is_initialized;
 	struct completion	comp_ready;
 	struct completion	comp_cmd_done;
@@ -132,6 +131,7 @@ struct atmel_nand_host {
 	struct dma_chan		*dma_chan;
 
 	struct atmel_nfc	*nfc;
+	struct clk		*clk;
 
 	const struct atmel_nand_caps	*caps;
 	bool			has_pmecc;
@@ -2157,6 +2157,19 @@ static int atmel_nand_probe(struct platform_device *pdev)
 	nand_chip->IO_ADDR_R = host->io_base;
 	nand_chip->IO_ADDR_W = host->io_base;
 
+	if (host->caps->has_hsmc_clk) {
+		host->clk = devm_clk_get(&pdev->dev, NULL);
+		if (IS_ERR(host->clk)) {
+			dev_err(&pdev->dev, "HSMC clock is missing, update your Device Tree");
+			res = PTR_ERR(host->clk);
+			goto err_nand_ioremap;
+		}
+
+		res = clk_prepare_enable(host->clk);
+		if (res)
+			goto err_nand_ioremap;
+	}
+
 	if (nand_nfc.is_initialized) {
 		/* NFC driver is probed and initialized */
 		host->nfc = &nand_nfc;
@@ -2321,6 +2334,9 @@ static int atmel_nand_remove(struct platform_device *pdev)
 	if (host->dma_chan)
 		dma_release_channel(host->dma_chan);
 
+	if (!IS_ERR(host->clk))
+		clk_disable_unprepare(host->clk);
+
 	platform_driver_unregister(&atmel_nand_nfc_driver);
 
 	return 0;
@@ -2334,11 +2350,19 @@ static int atmel_nand_remove(struct platform_device *pdev)
 static const struct atmel_nand_caps at91rm9200_caps = {
 	.pmecc_correct_erase_page = false,
 	.pmecc_max_correction = 24,
+	.has_hsmc_clk = false,
+};
+
+static struct atmel_nand_caps sama5d3_caps = {
+	.pmecc_correct_erase_page = false,
+	.pmecc_max_correction = 24,
+	.has_hsmc_clk = true,
 };
 
 static const struct atmel_nand_caps sama5d4_caps = {
 	.pmecc_correct_erase_page = true,
 	.pmecc_max_correction = 24,
+	.has_hsmc_clk = true,
 };
 
 /*
@@ -2348,11 +2372,13 @@ static const struct atmel_nand_caps sama5d4_caps = {
 static const struct atmel_nand_caps sama5d2_caps = {
 	.pmecc_correct_erase_page = true,
 	.pmecc_max_correction = 32,
+	.has_hsmc_clk = true,
 };
 
 static const struct of_device_id atmel_nand_dt_ids[] = {
 	{ .compatible = "atmel,at91rm9200-nand", .data = &at91rm9200_caps },
 	{ .compatible = "atmel,sama5d4-nand", .data = &sama5d4_caps },
+	{ .compatible = "atmel,sama5d3-nand", .data = &sama5d3_caps },
 	{ .compatible = "atmel,sama5d2-nand", .data = &sama5d2_caps },
 	{ /* sentinel */ }
 };
@@ -2363,7 +2389,6 @@ static int atmel_nand_nfc_probe(struct platform_device *pdev)
 {
 	struct atmel_nfc *nfc = &nand_nfc;
 	struct resource *nfc_cmd_regs, *nfc_hsmc_regs, *nfc_sram;
-	int ret;
 
 	nfc_cmd_regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	nfc->base_cmd_regs = devm_ioremap_resource(&pdev->dev, nfc_cmd_regs);
@@ -2401,31 +2426,12 @@ static int atmel_nand_nfc_probe(struct platform_device *pdev)
 	nfc_writel(nfc->hsmc_regs, IDR, 0xffffffff);
 	nfc_readl(nfc->hsmc_regs, SR);	/* clear the NFC_SR */
 
-	nfc->clk = devm_clk_get(&pdev->dev, NULL);
-	if (!IS_ERR(nfc->clk)) {
-		ret = clk_prepare_enable(nfc->clk);
-		if (ret)
-			return ret;
-	} else {
-		dev_warn(&pdev->dev, "NFC clock missing, update your Device Tree");
-	}
-
 	nfc->is_initialized = true;
 	dev_info(&pdev->dev, "NFC is probed.\n");
 
 	return 0;
 }
 
-static int atmel_nand_nfc_remove(struct platform_device *pdev)
-{
-	struct atmel_nfc *nfc = &nand_nfc;
-
-	if (!IS_ERR(nfc->clk))
-		clk_disable_unprepare(nfc->clk);
-
-	return 0;
-}
-
 static const struct atmel_nand_nfc_caps sama5d3_nfc_caps = {
 	.rb_mask = NFC_SR_RB_EDGE0,
 };
@@ -2447,7 +2453,6 @@ static struct platform_driver atmel_nand_nfc_driver = {
 		.of_match_table = of_match_ptr(atmel_nand_nfc_match),
 	},
 	.probe = atmel_nand_nfc_probe,
-	.remove = atmel_nand_nfc_remove,
 };
 
 static struct platform_driver atmel_nand_driver = {
-- 
1.7.9.5



From wenyou.yang at atmel.com  Mon Feb 22 22:04:34 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Tue, 23 Feb 2016 14:04:34 +0800
Subject: [PATCH v2 0/2] ARM: at91: sama5/dts: move hsmc_clk out of nfc node
Message-ID: <1456207477-7946-1-git-send-email-wenyou.yang@atmel.com>

For SAMA5D3, SAMA5D4 SoC family, PMECC needs the HSMC clock,
so move out hsmc_clk from the nfc node to the nand node.

Also, change the SAMA5D3 nand node's compatible string to
"atmel,sama5d3-nand".

Changes in v2:
 - add a patch to change SAMA5D3 nand node's compatible string
   to "atmel,sama5d3-nand".
 - revert the mail address of Josh's Signed-off to the original.

Josh Wu (2):
  ARM: at91: sama5d3/dts: add compatiable string for nand
  ARM: at91: sama5/dts: move hsmc_clk out of nfc node

 arch/arm/boot/dts/sama5d3.dtsi |    4 ++--
 arch/arm/boot/dts/sama5d4.dtsi |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
1.7.9.5



From wenyou.yang at atmel.com  Mon Feb 22 22:04:35 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Tue, 23 Feb 2016 14:04:35 +0800
Subject: [PATCH v2 1/2] ARM: at91: sama5d3/dts: add compatiable string for nand
In-Reply-To: <1456207477-7946-1-git-send-email-wenyou.yang@atmel.com>
References: <1456207477-7946-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1456207477-7946-2-git-send-email-wenyou.yang@atmel.com>

From: Josh Wu <josh.wu at atmel.com>

As introducing a new "atmel,sama5d3-nand" compatible string for
SAMA5D3's nand node, apply it for SAMA5D3 SoC.

Signed-off-by: Josh Wu <josh.wu at atmel.com>
Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---

Changes in v2: None

 arch/arm/boot/dts/sama5d3.dtsi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index a532791..ee1b1a8 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -1459,7 +1459,7 @@
 		};
 
 		nand0: nand at 60000000 {
-			compatible = "atmel,at91rm9200-nand";
+			compatible = "atmel,sama5d3-nand", "atmel,at91rm9200-nand";
 			#address-cells = <1>;
 			#size-cells = <1>;
 			ranges;
-- 
1.7.9.5



From wenyou.yang at atmel.com  Mon Feb 22 22:04:36 2016
From: wenyou.yang at atmel.com (Wenyou Yang)
Date: Tue, 23 Feb 2016 14:04:36 +0800
Subject: [PATCH v2 2/2] ARM: at91: sama5/dts: move hsmc_clk out of nfc node
In-Reply-To: <1456207477-7946-1-git-send-email-wenyou.yang@atmel.com>
References: <1456207477-7946-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <1456207477-7946-3-git-send-email-wenyou.yang@atmel.com>

From: Josh Wu <josh.wu at atmel.com>

For SAMA5D3, SAMA5D4 SoC family, as PMECC is a part of HSMC, PMECC
needs the HSMC clock, so move out hsmc_clk from the nfc node to
the nand node.

Signed-off-by: Josh Wu <josh.wu at atmel.com>
Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
---

Changes in v2:
 - add a patch to change SAMA5D3 nand node's compatible string
   to "atmel,sama5d3-nand".
 - revert the mail address of Josh's Signed-off to the original.

 arch/arm/boot/dts/sama5d3.dtsi |    2 +-
 arch/arm/boot/dts/sama5d4.dtsi |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index ee1b1a8..d20a38b 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -1474,6 +1474,7 @@
 			atmel,nand-has-dma;
 			pinctrl-names = "default";
 			pinctrl-0 = <&pinctrl_nand0_ale_cle>;
+			clocks = <&hsmc_clk>;
 			atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
 			status = "disabled";
 
@@ -1486,7 +1487,6 @@
 					0xffffc000 0x00000070	/* NFC HSMC regs */
 					0x00200000 0x00100000	/* NFC SRAM banks */
 					>;
-				clocks = <&hsmc_clk>;
 			};
 		};
 	};
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index b8032bc..1499b33 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -295,6 +295,7 @@
 			atmel,nand-has-dma;
 			pinctrl-names = "default";
 			pinctrl-0 = <&pinctrl_nand>;
+			clocks = <&hsmc_clk>;
 			status = "disabled";
 
 			nfc at 90000000 {
@@ -306,7 +307,6 @@
 					0xfc05c000 0x00000070	/* NFC HSMC regs */
 					0x00100000 0x00100000	/* NFC SRAM banks */
                                          >;
-				clocks = <&hsmc_clk>;
 				atmel,write-by-sram;
 			};
 		};
-- 
1.7.9.5



From jay.xu at rock-chips.com  Mon Feb 22 23:01:01 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Tue, 23 Feb 2016 15:01:01 +0800
Subject: [PATCH 1/4] soc: rockchip: add bindings for Rockchip grf
In-Reply-To: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
References: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1456210864-29037-2-git-send-email-jay.xu@rock-chips.com>

From: Jianqun Xu <jay.xu at rock-chips.com>

Add devicetree bindings for Rockchip grf which found on
Rockchip SoCs.

Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v2:
- add grf.txt (Heiko)

 .../devicetree/bindings/soc/rockchip/grf.txt       | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt

diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
new file mode 100644
index 0000000..7fb0410
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
@@ -0,0 +1,35 @@
+* Rockchip General Register Files (GRF)
+
+The general register file will be used to do static set by software, which
+is composed of many registers for system control.
+
+From RK3368 SoCs, the GRF is divided into two sections,
+- GRF, used for general non-secure system,
+- PMUGRF, used for always on sysyem
+
+Required Properties:
+
+- compatible: GRF should be one of the followings
+   - "rockchip,rk3066-grf", "syscon": for rk3066
+   - "rockchip,rk3188-grf", "syscon": for rk3188
+   - "rockchip,rk3228-grf", "syscon": for rk3228
+   - "rockchip,rk3288-grf", "syscon": for rk3288
+   - "rockchip,rk3368-grf", "syscon": for rk3368
+   - "rockchip,rk3399-grf", "syscon": for rk3399
+- compatible: PMUGRF should be one of the followings
+   - "rockchip,rk3368-pmugrf", "syscon": for rk3368
+   - "rockchip,rk3399-pmugrf", "syscon": for rk3399
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+Example: GRF and PMUGRF of RK3399 SoCs
+
+	pmugrf: syscon at ff320000 {
+		compatible = "rockchip,rk3399-pmugrf", "syscon";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+	};
+
+	grf: syscon at ff770000 {
+		compatible = "rockchip,rk3399-grf", "syscon";
+		reg = <0x0 0xff770000 0x0 0x10000>;
+	};
-- 
1.9.1




From jay.xu at rock-chips.com  Mon Feb 22 23:01:02 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Tue, 23 Feb 2016 15:01:02 +0800
Subject: [PATCH 2/4] dt-bindings: add bindings for rk3399 clock controller
In-Reply-To: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
References: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1456210864-29037-3-git-send-email-jay.xu@rock-chips.com>

From: Xing Zheng <zhengxing at rock-chips.com>

Add devicetree bindings for Rockchip cru which found on
Rockchip SoCs.

Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
 .../bindings/clock/rockchip,rk3399-cru.txt         | 82 ++++++++++++++++++++++
 1 file changed, 82 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
new file mode 100644
index 0000000..07bcc6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
@@ -0,0 +1,82 @@
+* Rockchip RK3399 Clock and Reset Unit
+
+The RK3399 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: PMU for CRU should be "rockchip,rk3399-pmucru"
+- compatible: CRU should be "rockchip,rk3399-cru"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+  If missing, pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "xin32k" - rtc clock - optional,
+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_gmac" - external GMAC clock - optional
+ - "ext_hsadc" - external HSADC clock - optional,
+ - "ext_isp" - external ISP clock - optional,
+ - "ext_jtag" - external JTAG clock - optional
+ - "ext_vip" - external VIP clock - optional,
+ - "usbotg_out" - output clock of the pll in the otg phy
+
+Example: General Register Files
+
+	pmugrf: syscon at ff320000 {
+		compatible = "rockchip,rk3399-pmugrf", "syscon";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+	};
+
+	grf: syscon at ff770000 {
+		compatible = "rockchip,rk3399-grf", "syscon";
+		reg = <0x0 0xff770000 0x0 0x10000>;
+	};
+
+Example: Clock controller node:
+
+	pmucru: pmu-clock-controller at ff750000 {
+		compatible = "rockchip,rk3399-pmucru";
+		reg = <0x0 0xff750000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at ff760000 {
+		compatible = "rockchip,rk3399-cru";
+		reg = <0x0 0xff760000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller:
+
+	uart0: serial at ff1a0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff180000 0x0 0x100>;
+		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+	};
-- 
1.9.1




From jay.xu at rock-chips.com  Mon Feb 22 23:01:00 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Tue, 23 Feb 2016 15:01:00 +0800
Subject: [PATCH 0/4] Rockchip: rk3399: Add core dtsi for rk3399
Message-ID: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>

From: Jianqun Xu <jay.xu at rock-chips.com>

There is the new SoCs from Rockchip which named rk3399, the
patches are added to support them.

Jianqun Xu (2):
  soc: rockchip: add bindings for Rockchip grf
  ARM64: dts: rockchip: add core dtsi file for rk3399

Xing Zheng (2):
  dt-bindings: add bindings for rk3399 clock controller
  clk: rockchip: add dt-binding header for rk3399

 .../bindings/clock/rockchip,rk3399-cru.txt         |  82 ++
 .../devicetree/bindings/soc/rockchip/grf.txt       |  35 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           | 949 +++++++++++++++++++++
 include/dt-bindings/clock/rk3399-cru.h             | 714 ++++++++++++++++
 4 files changed, 1780 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
 create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
 create mode 100644 include/dt-bindings/clock/rk3399-cru.h

-- 
1.9.1




From jay.xu at rock-chips.com  Mon Feb 22 23:01:04 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Tue, 23 Feb 2016 15:01:04 +0800
Subject: [PATCH 4/4] ARM64: dts: rockchip: add core dtsi file for rk3399
In-Reply-To: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
References: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1456210864-29037-5-git-send-email-jay.xu@rock-chips.com>

From: Jianqun Xu <jay.xu at rock-chips.com>

This patch adds core dtsi file for rk3399 found on Rockchip new SoCs
rk3399, which integrates dual-core Cortex-A72 and quad-core Cortex-A53
with separately NEON coprocessor.

The dtsi file has been tested on rk3399 board with simple boot system,
the uart and spi IPs are same as from rk3288.

Separate pmu nodes should be added for the A72 and A53 PMUs, and more
nodes should be added later.

Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 949 +++++++++++++++++++++++++++++++
 1 file changed, 949 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 0000000..4c0c385
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,949 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+#include <dt-bindings/clock/rk3399-cru.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+
+/ {
+	compatible = "rockchip,rk3399";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu_l0>;
+				};
+				core1 {
+					cpu = <&cpu_l1>;
+				};
+				core2 {
+					cpu = <&cpu_l2>;
+				};
+				core3 {
+					cpu = <&cpu_l3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu_b0>;
+				};
+				core1 {
+					cpu = <&cpu_b1>;
+				};
+			};
+		};
+
+		cpu_l0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x0>;
+		};
+
+		cpu_l1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x1>;
+		};
+
+		cpu_l2: cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x2>;
+		};
+
+		cpu_l3: cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x3>;
+		};
+
+		cpu_b0: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x0 0x100>;
+		};
+
+		cpu_b1: cpu at 101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x0 0x101>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	xin24m: xin24m {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24000000>;
+		clock-output-names = "xin24m";
+	};
+
+	gic: interrupt-controller at fee00000 {
+		compatible = "arm,gic-v3";
+		#interrupt-cells = <3>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		interrupt-controller;
+
+		reg = <0x0 0xfee00000 0 0x10000>, /* GICD */
+		      <0x0 0xfef00000 0 0xc0000>, /* GICR */
+		      <0x0 0xfff00000 0 0x10000>, /* GICC */
+		      <0x0 0xfff10000 0 0x10000>, /* GICH */
+		      <0x0 0xfff20000 0 0x10000>; /* GICV */
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH)>;
+		its: interrupt-controller at fee20000 {
+			compatible = "arm,gic-v3-its";
+			msi-controller;
+			reg = <0x0 0xfee20000 0x0 0x20000>;
+		};
+	};
+
+	amba {
+		compatible = "arm,amba-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		dmac_bus: dma-controller at ff6d0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x0 0xff6d0000 0x0 0x4000>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			clocks = <&cru ACLK_DMAC0_PERILP>;
+			clock-names = "apb_pclk";
+		};
+
+		dmac_peri: dma-controller at ff6e0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x0 0xff6e0000 0x0 0x4000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			clocks = <&cru ACLK_DMAC1_PERILP>;
+			clock-names = "apb_pclk";
+		};
+	};
+
+	uart0: serial at ff180000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff180000 0x0 0x100>;
+		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart1: serial at ff190000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff190000 0x0 0x100>;
+		clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart2: serial at ff1a0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff1a0000 0x0 0x100>;
+		clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart3: serial at ff1b0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff1b0000 0x0 0x100>;
+		clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	spi0: spi at ff1c0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff110000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI0>, <&cru PCLK_SPI0>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi0_clk &spi0_tx &spi0_rx &spi0_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi1: spi at ff1d0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff120000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI1>, <&cru PCLK_SPI1>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi1_clk &spi1_tx &spi1_rx &spi1_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi2: spi at ff1e0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff130000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI2>, <&cru PCLK_SPI2>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi2_clk &spi2_tx &spi2_rx &spi2_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi4: spi at ff1f0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff120000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI4>, <&cru PCLK_SPI4>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi4_clk &spi4_tx &spi4_rx &spi4_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi5: spi at ff200000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff130000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI5>, <&cru PCLK_SPI5>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi5_clk &spi5_tx &spi5_rx &spi5_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	pmugrf: syscon at ff320000 {
+		compatible = "rockchip,rk3399-pmugrf", "syscon";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+	};
+
+	spi3: spi at ff350000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff110000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI3>, <&cru PCLK_SPI3>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi3_clk &spi3_tx &spi3_rx &spi3_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	uart4: serial at ff370000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff370000 0x0 0x100>;
+		clocks = <&cru SCLK_UART4_PMU>, <&cru PCLK_UART4_PMU>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	pmucru: pmu-clock-controller at ff750000 {
+		compatible = "rockchip,rk3399-pmucru";
+		reg = <0x0 0xff750000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at ff760000 {
+		compatible = "rockchip,rk3399-cru";
+		reg = <0x0 0xff760000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	grf: syscon at ff770000 {
+		compatible = "rockchip,rk3399-grf", "syscon";
+		reg = <0x0 0xff770000 0x0 0x10000>;
+	};
+
+	i2s0: i2s at ff880000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff880000 0x0 0x1000>;
+		interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 0>, <&dmac_bus 1>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S0_8CH>, <&cru SCLK_I2S0_8CH>;
+		status = "disabled";
+	};
+
+	i2s1: i2s at ff890000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff890000 0x0 0x1000>;
+		interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 2>, <&dmac_bus 3>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S1_8CH>, <&cru SCLK_I2S1_8CH>;
+		status = "disabled";
+	};
+
+	i2s2: i2s at ff8a0000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff8a0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 4>, <&dmac_bus 5>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S2_8CH>, <&cru SCLK_I2S2_8CH>;
+		status = "disabled";
+	};
+
+	pinctrl: pinctrl {
+		compatible = "rockchip,rk3399-pinctrl";
+		rockchip,grf = <&grf>;
+		rockchip,pmu = <&pmugrf>;
+		#address-cells = <0x2>;
+		#size-cells = <0x2>;
+		ranges;
+
+		gpio0: gpio0 at ff720000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff720000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio1: gpio1 at ff730000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff730000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio2: gpio2 at ff780000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff780000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio3: gpio3 at ff788000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff788000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio4: gpio4 at ff790000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff790000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		pcfg_pull_up: pcfg-pull-up {
+			bias-pull-up;
+		};
+
+		pcfg_pull_down: pcfg-pull-down {
+			bias-pull-down;
+		};
+
+		pcfg_pull_none: pcfg-pull-none {
+			bias-disable;
+		};
+
+		pcfg_pull_none_12ma: pcfg-pull-none-12ma {
+			bias-disable;
+			drive-strength = <12>;
+		};
+
+		pcfg_pull_up_8ma: pcfg-pull-up-8ma {
+			bias-pull-up;
+			drive-strength = <8>;
+		};
+
+		pcfg_pull_down_4ma: pcfg-pull-down-4ma {
+			bias-pull-down;
+			drive-strength = <4>;
+		};
+
+		pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+			bias-pull-up;
+			drive-strength = <2>;
+		};
+
+		pcfg_pull_down_12ma: pcfg-pull-down-12ma {
+			bias-pull-down;
+			drive-strength = <12>;
+		};
+
+		emmc {
+			emmc_pwr: emmc-pwr {
+				rockchip,pins =
+					<0 5 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		gmac {
+			rgmii_pins: rgmii-pins {
+				rockchip,pins =
+					<3 11 RK_FUNC_1 &pcfg_pull_none>,
+					<3 13 RK_FUNC_1 &pcfg_pull_none>,
+					<3 8 RK_FUNC_1 &pcfg_pull_none>,
+					<3 4 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 5 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 0 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 1 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 17 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 12 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 6 RK_FUNC_1 &pcfg_pull_none>,
+					<3 7 RK_FUNC_1 &pcfg_pull_none>,
+					<3 2 RK_FUNC_1 &pcfg_pull_none>,
+					<3 3 RK_FUNC_1 &pcfg_pull_none>,
+					<3 14 RK_FUNC_1 &pcfg_pull_none>,
+					<3 9 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			rmii_pins: rmii-pins {
+				rockchip,pins =
+					<3 11 RK_FUNC_1 &pcfg_pull_none>,
+					<3 13 RK_FUNC_1 &pcfg_pull_none>,
+					<3 8 RK_FUNC_1 &pcfg_pull_none>,
+					<3 4 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 5 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 12 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 6 RK_FUNC_1 &pcfg_pull_none>,
+					<3 7 RK_FUNC_1 &pcfg_pull_none>,
+					<3 9 RK_FUNC_1 &pcfg_pull_none>,
+					<3 10 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c0 {
+			i2c0_xfer: i2c0-xfer {
+				rockchip,pins =
+					<1 15 RK_FUNC_2 &pcfg_pull_none>,
+					<1 16 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c1 {
+			i2c1_xfer: i2c1-xfer {
+				rockchip,pins =
+					<4 2 RK_FUNC_1 &pcfg_pull_none>,
+					<4 1 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c2 {
+			i2c2_xfer: i2c2-xfer {
+				rockchip,pins =
+					<2 1 RK_FUNC_2 &pcfg_pull_none_12ma>,
+					<2 0 RK_FUNC_2 &pcfg_pull_none_12ma>;
+			};
+		};
+
+		i2c3 {
+			i2c3_xfer: i2c3-xfer {
+				rockchip,pins =
+					<4 17 RK_FUNC_1 &pcfg_pull_none>,
+					<4 16 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c4 {
+			i2c4_xfer: i2c4-xfer {
+				rockchip,pins =
+					<1 12 RK_FUNC_1 &pcfg_pull_none>,
+					<1 11 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c5 {
+			i2c5_xfer: i2c5-xfer {
+				rockchip,pins =
+					<3 11 RK_FUNC_2 &pcfg_pull_none>,
+					<3 10 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c6 {
+			i2c6_xfer: i2c6-xfer {
+				rockchip,pins =
+					<2 10 RK_FUNC_2 &pcfg_pull_none>,
+					<2 9 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c7 {
+			i2c7_xfer: i2c7-xfer {
+				rockchip,pins =
+					<2 8 RK_FUNC_2 &pcfg_pull_none>,
+					<2 7 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c8 {
+			i2c8_xfer: i2c8-xfer {
+				rockchip,pins =
+					<1 21 RK_FUNC_1 &pcfg_pull_none>,
+					<1 20 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2s0 {
+			i2s0_8ch_bus: i2s0-8ch-bus {
+				rockchip,pins =
+					<3 24 RK_FUNC_1 &pcfg_pull_none>,
+					<3 25 RK_FUNC_1 &pcfg_pull_none>,
+					<3 26 RK_FUNC_1 &pcfg_pull_none>,
+					<3 27 RK_FUNC_1 &pcfg_pull_none>,
+					<3 28 RK_FUNC_1 &pcfg_pull_none>,
+					<3 29 RK_FUNC_1 &pcfg_pull_none>,
+					<3 30 RK_FUNC_1 &pcfg_pull_none>,
+					<3 31 RK_FUNC_1 &pcfg_pull_none>,
+					<4 0 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2s1 {
+			i2s1_2ch_bus: i2s1-2ch-bus {
+				rockchip,pins =
+					<4 3 RK_FUNC_1 &pcfg_pull_none>,
+					<4 4 RK_FUNC_1 &pcfg_pull_none>,
+					<4 5 RK_FUNC_1 &pcfg_pull_none>,
+					<4 6 RK_FUNC_1 &pcfg_pull_none>,
+					<4 7 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		sdio0 {
+			sdio0_bus1: sdio0-bus1 {
+				rockchip,pins =
+					<2 20 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_bus4: sdio0-bus4 {
+				rockchip,pins =
+					<2 20 RK_FUNC_1 &pcfg_pull_up>,
+					<2 21 RK_FUNC_1 &pcfg_pull_up>,
+					<2 22 RK_FUNC_1 &pcfg_pull_up>,
+					<2 23 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_cmd: sdio0-cmd {
+				rockchip,pins =
+					<2 24 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_clk: sdio0-clk {
+				rockchip,pins =
+					<2 25 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			sdio0_cd: sdio0-cd {
+				rockchip,pins =
+					<2 26 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_pwr: sdio0-pwr {
+				rockchip,pins =
+					<2 27 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_bkpwr: sdio0-bkpwr {
+				rockchip,pins =
+					<2 28 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_wp: sdio0-wp {
+				rockchip,pins =
+					<0 3 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_int: sdio0-int {
+				rockchip,pins =
+					<0 4 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		sdmmc {
+			sdmmc_bus1: sdmmc-bus1 {
+				rockchip,pins =
+					<4 8 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_bus4: sdmmc-bus4 {
+				rockchip,pins =
+					<4 8 RK_FUNC_1 &pcfg_pull_up>,
+					<4 9 RK_FUNC_1 &pcfg_pull_up>,
+					<4 10 RK_FUNC_1 &pcfg_pull_up>,
+					<4 11 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_clk: sdmmc-clk {
+				rockchip,pins =
+					<4 12 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			sdmmc_cmd: sdmmc-cmd {
+				rockchip,pins =
+					<4 13 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_cd: sdmcc-cd {
+				rockchip,pins =
+					<0 7 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_wp: sdmmc-wp {
+				rockchip,pins =
+					<0 8 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi0 {
+			spi0_clk: spi0-clk {
+				rockchip,pins =
+					<3 6 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_cs0: spi0-cs0 {
+				rockchip,pins =
+					<3 7 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_cs1: spi0-cs1 {
+				rockchip,pins =
+					<3 8 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_tx: spi0-tx {
+				rockchip,pins =
+					<3 5 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_rx: spi0-rx {
+				rockchip,pins =
+					<3 4 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi1 {
+			spi1_clk: spi1-clk {
+				rockchip,pins =
+					<1 9 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_cs0: spi1-cs0 {
+				rockchip,pins =
+					<1 10 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_rx: spi1-rx {
+				rockchip,pins =
+					<1 7 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_tx: spi1-tx {
+				rockchip,pins =
+					<1 8 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi2 {
+			spi2_clk: spi2-clk {
+				rockchip,pins =
+					<2 11 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_cs0: spi2-cs0 {
+				rockchip,pins =
+					<2 12 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_rx: spi2-rx {
+				rockchip,pins =
+					<2 9 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_tx: spi2-tx {
+				rockchip,pins =
+					<2 10 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi3 {
+			spi3_clk: spi3-clk {
+				rockchip,pins =
+					<1 17 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_cs0: spi3-cs0 {
+				rockchip,pins =
+					<1 18 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_rx: spi3-rx {
+				rockchip,pins =
+					<1 15 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_tx: spi3-tx {
+				rockchip,pins =
+					<1 16 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi4 {
+			spi4_clk: spi4-clk {
+				rockchip,pins =
+					<3 2 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_cs0: spi4-cs0 {
+				rockchip,pins =
+					<3 3 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_rx: spi4-rx {
+				rockchip,pins =
+					<3 0 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_tx: spi4-tx {
+				rockchip,pins =
+					<3 1 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi5 {
+			spi5_clk: spi5-clk {
+				rockchip,pins =
+					<2 22 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_cs0: spi5-cs0 {
+				rockchip,pins =
+					<2 23 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_rx: spi5-rx {
+				rockchip,pins =
+					<2 20 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_tx: spi5-tx {
+				rockchip,pins =
+					<2 21 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		uart0 {
+			uart0_xfer: uart0-xfer {
+				rockchip,pins =
+					<2 16 RK_FUNC_1 &pcfg_pull_up>,
+					<2 17 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			uart0_cts: uart0-cts {
+				rockchip,pins =
+					<2 18 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			uart0_rts: uart0-rts {
+				rockchip,pins =
+					<2 19 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uart1 {
+			uart1_xfer: uart1-xfer {
+				rockchip,pins =
+					<3 12 RK_FUNC_2 &pcfg_pull_up>,
+					<3 13 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2a {
+			uart2a_xfer: uart2a-xfer {
+				rockchip,pins =
+					<4 8 RK_FUNC_2 &pcfg_pull_up>,
+					<4 9 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2b {
+			uart2b_xfer: uart2b-xfer {
+				rockchip,pins =
+					<4 16 RK_FUNC_2 &pcfg_pull_up>,
+					<4 17 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2c {
+			uart2c_xfer: uart2c-xfer {
+				rockchip,pins =
+					<4 19 RK_FUNC_1 &pcfg_pull_up>,
+					<4 20 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uart3 {
+			uart3_xfer: uart3-xfer {
+				rockchip,pins =
+					<3 14 RK_FUNC_2 &pcfg_pull_up>,
+					<3 15 RK_FUNC_2 &pcfg_pull_none>;
+			};
+
+			uart3_cts: uart3-cts {
+				rockchip,pins =
+					<3 18 RK_FUNC_2 &pcfg_pull_none>;
+			};
+
+			uart3_rts: uart3-rts {
+				rockchip,pins =
+					<3 19 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart4 {
+			uart4_xfer: uart4-xfer {
+				rockchip,pins =
+					<1 7 RK_FUNC_1 &pcfg_pull_up>,
+					<1 8 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uarthdcp {
+			uarthdcp_xfer: uarthdcp-xfer {
+				rockchip,pins =
+					<4 21 RK_FUNC_2 &pcfg_pull_up>,
+					<4 22 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		pwm0 {
+			pwm0_pin: pwm0-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			vop0_pwm_pin: vop0-pwm-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		pwm1 {
+			pwm1_pin: pwm1-pin {
+				rockchip,pins =
+					<4 22 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			vop1_pwm_pin: vop1-pwm-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_3 &pcfg_pull_none>;
+			};
+		};
+	};
+};
-- 
1.9.1




From jay.xu at rock-chips.com  Mon Feb 22 23:01:03 2016
From: jay.xu at rock-chips.com (jianqun.xu)
Date: Tue, 23 Feb 2016 15:01:03 +0800
Subject: [PATCH 3/4] clk: rockchip: add dt-binding header for rk3399
In-Reply-To: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
References: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1456210864-29037-4-git-send-email-jay.xu@rock-chips.com>

From: Xing Zheng <zhengxing at rock-chips.com>

Add the dt-bindings header for the rk3399, that gets shared between
the clock controller and the clock references in the dts.

Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
 include/dt-bindings/clock/rk3399-cru.h | 714 +++++++++++++++++++++++++++++++++
 1 file changed, 714 insertions(+)
 create mode 100644 include/dt-bindings/clock/rk3399-cru.h

diff --git a/include/dt-bindings/clock/rk3399-cru.h b/include/dt-bindings/clock/rk3399-cru.h
new file mode 100644
index 0000000..7791688
--- /dev/null
+++ b/include/dt-bindings/clock/rk3399-cru.h
@@ -0,0 +1,714 @@
+/*
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng <zhengxing at rock-chips.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H
+#define _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H
+
+/* core clocks */
+#define PLL_APLLL			1
+#define PLL_APLLB			2
+#define PLL_DPLL			3
+#define PLL_CPLL			4
+#define PLL_GPLL			5
+#define PLL_NPLL			6
+#define PLL_VPLL			7
+#define PLL_PPLL			8
+#define ARMCLKL				9
+#define ARMCLKB				10
+
+/* sclk gates (special clocks) */
+#define SCLK_I2C1			65
+#define SCLK_I2C2			66
+#define SCLK_I2C3			67
+#define SCLK_I2C5			68
+#define SCLK_I2C6			69
+#define SCLK_I2C7			70
+#define SCLK_SPI0			71
+#define SCLK_SPI1			72
+#define SCLK_SPI2			73
+#define SCLK_SPI4			74
+#define SCLK_SPI5			75
+#define SCLK_SDMMC			76
+#define SCLK_SDIO			77
+#define SCLK_EMMC			78
+#define SCLK_TSADC			79
+#define SCLK_SARADC			80
+#define SCLK_UART0			81
+#define SCLK_UART1			82
+#define SCLK_UART2			83
+#define SCLK_UART3			84
+#define SCLK_SPDIF_8CH			85
+#define SCLK_I2S0_8CH			86
+#define SCLK_I2S1_8CH			87
+#define SCLK_I2S2_8CH			88
+#define SCLK_I2S_8CH_OUT		89
+#define SCLK_TIMER00			90
+#define SCLK_TIMER01			91
+#define SCLK_TIMER02			92
+#define SCLK_TIMER03			93
+#define SCLK_TIMER04			94
+#define SCLK_TIMER05			95
+#define SCLK_TIMER06			96
+#define SCLK_TIMER07			97
+#define SCLK_TIMER08			98
+#define SCLK_TIMER09			99
+#define SCLK_TIMER10			100
+#define SCLK_TIMER11			101
+#define SCLK_MACREF			102
+#define SCLK_MAC_RX			103
+#define SCLK_MAC_TX			104
+#define SCLK_MAC			105
+#define SCLK_MACREF_OUT			106
+#define SCLK_VOP0_PWM			107
+#define SCLK_VOP1_PWM			108
+#define SCLK_RGA			109
+#define SCLK_ISP0			110
+#define SCLK_ISP1			111
+#define SCLK_HDMI_CEC			112
+#define SCLK_HDMI_SFR			113
+#define SCLK_DP_CORE_SRC		114
+#define SCLK_PVTM_CORE_L		115
+#define SCLK_PVTM_CORE_B		116
+#define SCLK_PVTM_GPU			117
+#define SCLK_PVTM_DDR			118
+#define SCLK_MIPIDPHY_REF		119
+#define SCLK_MIPIDPHY_CFG		120
+#define SCLK_HSICPHY			121
+#define SCLK_USBPHY480M			122
+#define SCLK_USB2PHY0_REF		123
+#define SCLK_USB2PHY1_REF		124
+#define SCLK_UPHY0_TCPDPHY_REF		125
+#define SCLK_UPHY0_TCPDCORE		126
+#define SCLK_UPHY1_TCPDPHY_REF		127
+#define SCLK_UPHY1_TCPDCORE		128
+#define SCLK_USB3OTG0_REF		129
+#define SCLK_USB3OTG1_REF		130
+#define SCLK_USB3OTG0_SUSPEND		131
+#define SCLK_USB3OTG1_SUSPEND		132
+#define SCLK_CRYPTO0			133
+#define SCLK_CRYPTO1			134
+#define SCLK_CCI_TRACE			135
+#define SCLK_CS				136
+#define SCLK_CIF_OUT			137
+#define SCLK_PCIEPHY_REF		138
+#define SCLK_PCIE_CORE			139
+#define SCLK_MO_PERILP			140
+#define SCLK_M0_PERILP_DEC		141
+#define SCLK_CM0S			142
+#define SCLK_DBG_NOC			143
+#define SCLK_DBG_PD_CORE_B		144
+#define SCLK_DBG_PD_CORE_L		145
+#define SCLK_DFIMON0_TIMER		146
+#define SCLK_DFIMON1_TIMER		147
+#define SCLK_INTMEM0			148
+#define SCLK_INTMEM1			149
+#define SCLK_INTMEM2			150
+#define SCLK_INTMEM3			151
+#define SCLK_INTMEM4			152
+#define SCLK_INTMEM5			153
+
+#define DCLK_VOP0			170
+#define DCLK_VOP1			171
+
+/* aclk gates */
+#define ACLK_PERIHP			192
+#define ACLK_PERIHP_NOC			193
+#define ACLK_PERILP0			194
+#define ACLK_PERILP0_NOC		195
+#define ACLK_PERF_PCIE			196
+#define ACLK_PCIE			197
+#define ACLK_INTMEM			198
+#define ACLK_TZMA			199
+#define ACLK_DCF			200
+#define ACLK_CCI			201
+#define ACLK_CCI_NOC0			202
+#define ACLK_CCI_NOC1			203
+#define ACLK_CCI_GRF			204
+#define ACLK_CENTER			205
+#define ACLK_CENTER_MAIN_NOC		206
+#define ACLK_CENTER_PERI_NOC		207
+#define ACLK_GPU			208
+#define ACLK_PERF_GPU			209
+#define ACLK_GPU_GRF			210
+#define ACLK_DMAC0_PERILP		211
+#define ACLK_DMAC1_PERILP		212
+#define ACLK_GMAC			213
+#define ACLK_GMAC_NOC			214
+#define ACLK_PERF_GMAC			215
+#define ACLK_VOP0_NOC			216
+#define ACLK_VOP0			217
+#define ACLK_VOP1_NOC			218
+#define ACLK_VOP1			219
+#define ACLK_RGA			220
+#define ACLK_RGA_NOC			221
+#define ACLK_HDCP			222
+#define ACLK_HDCP_NOC			223
+#define ACLK_HDCP22			224
+#define ACLK_IEP			225
+#define ACLK_IEP_NOC			226
+#define ACLK_VIO			227
+#define ACLK_VIO_NOC			228
+#define ACLK_ISP0			229
+#define ACLK_ISP1			230
+#define ACLK_ISP0_NOC			231
+#define ACLK_ISP1_NOC			232
+#define ACLK_ISP0_WRAPPER		233
+#define ACLK_ISP1_WRAPPER		234
+#define ACLK_VCODEC			235
+#define ACLK_VCODEC_NOC			236
+#define ACLK_VDU			237
+#define ACLK_VDU_NOC			238
+#define ACLK_PERI			239
+#define ACLK_EMMC			240
+#define ACLK_EMMC_CORE			241
+#define ACLK_EMMC_NOC			242
+#define ACLK_EMMC_GRF			243
+#define ACLK_USB3			244
+#define ACLK_USB3_NOC			245
+#define ACLK_USB3OTG0			246
+#define ACLK_USB3OTG1			247
+#define ACLK_USB3_RKSOC_AXI_PERF	248
+#define ACLK_USB3_GRF			249
+#define ACLK_GIC			250
+#define ACLK_GIC_NOC			251
+#define ACLK_GIC_ADB400_CORE_L_2_GIC	252
+#define ACLK_GIC_ADB400_CORE_B_2_GIC	253
+#define ACLK_GIC_ADB400_GIC_2_CORE_L	254
+#define ACLK_GIC_ADB400_GIC_2_CORE_B	255
+
+/* pclk gates */
+#define PCLK_PERIHP			320
+#define PCLK_PERIHP_NOC			321
+#define PCLK_PERILP0			322
+#define PCLK_PERILP1			323
+#define PCLK_PERILP1_NOC		324
+#define PCLK_PERILP_SGRF		325
+#define PCLK_PERIHP_GRF			326
+#define PCLK_PCIE			327
+#define PCLK_SGRF			328
+#define PCLK_INTR_ARB			329
+#define PCLK_CENTER_MAIN_NOC		330
+#define PCLK_CIC			331
+#define PCLK_COREDBG_B			332
+#define PCLK_COREDBG_L			333
+#define PCLK_DBG_CXCS_PD_CORE_B		334
+#define PCLK_DCF			335
+#define PCLK_GPIO2			336
+#define PCLK_GPIO3			337
+#define PCLK_GPIO4			338
+#define PCLK_GRF			339
+#define PCLK_HSICPHY			340
+#define PCLK_I2C1			341
+#define PCLK_I2C2			342
+#define PCLK_I2C3			343
+#define PCLK_I2C5			344
+#define PCLK_I2C6			345
+#define PCLK_I2C7			346
+#define PCLK_SPI0			347
+#define PCLK_SPI1			348
+#define PCLK_SPI2			349
+#define PCLK_SPI4			350
+#define PCLK_SPI5			351
+#define PCLK_UART0			352
+#define PCLK_UART1			353
+#define PCLK_UART2			354
+#define PCLK_UART3			355
+#define PCLK_TSADC			356
+#define PCLK_SARADC			357
+#define PCLK_GMAC			358
+#define PCLK_GMAC_NOC			359
+#define PCLK_TIMER0			360
+#define PCLK_TIMER1			361
+#define PCLK_EDP			362
+#define PCLK_EDP_NOC			363
+#define PCLK_EDP_CTRL			364
+#define PCLK_VIO			365
+#define PCLK_VIO_NOC			366
+#define PCLK_VIO_GRF			367
+#define PCLK_MIPI_DSI0			368
+#define PCLK_MIPI_DSI1			369
+#define PCLK_HDCP			370
+#define PCLK_HDCP_NOC			371
+#define PCLK_HDMI_CTRL			372
+#define PCLK_DP_CTRL			373
+#define PCLK_HDCP22			374
+#define PCLK_GASKET			375
+#define PCLK_DDR			376
+#define PCLK_DDR_MON			377
+#define PCLK_DDR_SGRF			378
+#define PCLK_ISP1_WRAPPER		379
+#define PCLK_WDT			380
+#define PCLK_EFUSE1024NS		381
+#define PCLK_EFUSE1024S			382
+#define PCLK_PMU_INTR_ARB		383
+#define PCLK_MAILBOX0			384
+
+/* hclk gates */
+#define HCLK_PERIHP			448
+#define HCLK_PERILP0			449
+#define HCLK_PERILP1			450
+#define HCLK_PERILP0_NOC		451
+#define HCLK_PERILP1_NOC		452
+#define HCLK_M0_PERILP			453
+#define HCLK_M0_PERILP_NOC		454
+#define HCLK_AHB1TOM			455
+#define HCLK_HOST0			456
+#define HCLK_HOST0_ARB			457
+#define HCLK_HOST1			458
+#define HCLK_HOST1_ARB			459
+#define HCLK_HSIC			460
+#define HCLK_SD				461
+#define HCLK_SDMMC			462
+#define HCLK_SDMMC_NOC			463
+#define HCLK_M_CRYPTO0			464
+#define HCLK_M_CRYPTO1			465
+#define HCLK_S_CRYPTO0			466
+#define HCLK_S_CRYPTO1			467
+#define HCLK_I2S0_8CH			468
+#define HCLK_I2S1_8CH			469
+#define HCLK_I2S2_8CH			470
+#define HCLK_SPDIF			471
+#define HCLK_VOP0_NOC			472
+#define HCLK_VOP0			473
+#define HCLK_VOP1_NOC			474
+#define HCLK_VOP1			475
+#define HCLK_ROM			476
+#define HCLK_IEP			477
+#define HCLK_IEP_NOC			478
+#define HCLK_ISP0			479
+#define HCLK_ISP1			480
+#define HCLK_ISP0_NOC			481
+#define HCLK_ISP1_NOC			482
+#define HCLK_ISP0_WRAPPER		483
+#define HCLK_ISP1_WRAPPER		484
+#define HCLK_RGA			485
+#define HCLK_RGA_NOC			486
+#define HCLK_HDCP			487
+#define HCLK_HDCP_NOC			488
+#define HCLK_HDCP22			489
+#define HCLK_VCODEC			490
+#define HCLK_VCODEC_NOC			491
+#define HCLK_VDU			492
+#define HCLK_VDU_NOC			493
+#define HCLK_SDIO			494
+#define HCLK_SDIO_NOC			495
+#define HCLK_SDIOAUDIO_NOC		496
+
+/* pmu-clocks indices */
+#define SCLK_32K_SUSPEND_PMU		521
+#define SCLK_SPI3_PMU			522
+#define SCLK_TIMER12_PMU		523
+#define SCLK_TIMER13_PMU		524
+#define SCLK_UART4_PMU			525
+#define SCLK_PVTM_PMU			526
+#define SCLK_WIFI_PMU			527
+#define SCLK_I2C0_PMU			528
+#define SCLK_I2C4_PMU			529
+#define SCLK_I2C8_PMU			530
+
+#define PCLK_PMU			540
+#define PCLK_PMUGRF_PMU			541
+#define PCLK_INTMEM1_PMU		542
+#define PCLK_GPIO0_PMU			543
+#define PCLK_GPIO1_PMU			544
+#define PCLK_SGRF_PMU			545
+#define PCLK_NOC_PMU			546
+#define PCLK_I2C0_PMU			547
+#define PCLK_I2C4_PMU			548
+#define PCLK_I2C8_PMU			549
+#define PCLK_RKPWM_PMU			550
+#define PCLK_SPI3_PMU			551
+#define PCLK_TIMER_PMU			552
+#define PCLK_MAILBOX_PMU		553
+#define PCLK_UART4_PMU			554
+#define PCLK_WDT_M0_PMU			555
+
+#define FCLK_CM0S_PMU			560
+#define SCLK_CM0S_PMU			561
+#define HCLK_CM0S_PMU			562
+#define DCLK_CM0S_PMU			563
+#define PCLK_INTR_ARB_PMU		564
+#define HCLK_NOC_PMU			565
+
+#define CLK_NR_CLKS		(HCLK_NOC_PMU + 1)
+
+/* soft-reset indices */
+
+/* cru_softrst_con0 */
+#define SRST_CORE_L0			0
+#define SRST_CORE_B0			1
+#define SRST_CORE_PO_L0			2
+#define SRST_CORE_PO_B0			3
+#define SRST_L2_L			4
+#define SRST_L2_B			5
+#define SRST_ADB_L			6
+#define SRST_ADB_B			7
+#define SRST_A_CCI			8
+#define SRST_A_CCIM0_NOC		9
+#define SRST_A_CCIM1_NOC		10
+#define SRST_DBG_NOC			11
+
+/* cru_softrst_con1 */
+#define SRST_CORE_L0_T			16
+#define SRST_CORE_L1			17
+#define SRST_CORE_L2			18
+#define SRST_CORE_L3			19
+#define SRST_CORE_PO_L0_T		20
+#define SRST_CORE_PO_L1			21
+#define SRST_CORE_PO_L2			22
+#define SRST_CORE_PO_L3			23
+#define SRST_A_ADB400_GIC2COREL		24
+#define SRST_A_ADB400_COREL2GIC		25
+#define SRST_P_DBG_L			26
+#define SRST_L2_L_T			28
+#define SRST_ADB_L_T			29
+#define SRST_A_RKPERF_L			30
+#define SRST_PVTM_CORE_L		31
+
+/* cru_softrst_con2 */
+#define SRST_CORE_B0_T			32
+#define SRST_CORE_B1			33
+#define SRST_CORE_PO_B0_T		36
+#define SRST_CORE_PO_B1			37
+#define SRST_A_ADB400_GIC2COREB		40
+#define SRST_A_ADB400_COREB2GIC		41
+#define SRST_P_DBG_B			42
+#define SRST_L2_B_T			43
+#define SRST_ADB_B_T			45
+#define SRST_A_RKPERF_B			46
+#define SRST_PVTM_CORE_B		47
+
+/* cru_softrst_con3 */
+#define SRST_A_CCI_T			50
+#define SRST_A_CCIM0_NOC_T		51
+#define SRST_A_CCIM1_NOC_T		52
+#define SRST_A_ADB400M_PD_CORE_B_T	53
+#define SRST_A_ADB400M_PD_CORE_L_T	54
+#define SRST_DBG_NOC_T			55
+#define SRST_DBG_CXCS			56
+#define SRST_CCI_TRACE			57
+#define SRST_P_CCI_GRF			58
+
+/* cru_softrst_con4 */
+#define SRST_A_CENTER_MAIN_NOC		64
+#define SRST_A_CENTER_PERI_NOC		65
+#define SRST_P_CENTER_MAIN		66
+#define SRST_P_DDRMON			67
+#define SRST_P_CIC			68
+#define SRST_P_CENTER_SGRF		69
+#define SRST_DDR0_MSCH			70
+#define SRST_DDRCFG0_MSCH		71
+#define SRST_DDR0			72
+#define SRST_DDRPHY0			73
+#define SRST_DDR1_MSCH			74
+#define SRST_DDRCFG1_MSCH		75
+#define SRST_DDR1			76
+#define SRST_DDRPHY1			77
+#define SRST_DDR_CIC			78
+#define SRST_PVTM_DDR			79
+
+/* cru_softrst_con5 */
+#define SRST_A_VCODEC_NOC		80
+#define SRST_A_VCODEC			81
+#define SRST_H_VCODEC_NOC		82
+#define SRST_H_VCODEC			83
+#define SRST_A_VDU_NOC			88
+#define SRST_A_VDU			89
+#define SRST_H_VDU_NOC			90
+#define SRST_H_VDU			91
+#define SRST_VDU_CORE			92
+#define SRST_VDU_CA			93
+
+/* cru_softrst_con6 */
+#define SRST_A_IEP_NOC			96
+#define SRST_A_VOP_IEP			97
+#define SRST_A_IEP			98
+#define SRST_H_IEP_NOC			99
+#define SRST_H_IEP			100
+#define SRST_A_RGA_NOC			102
+#define SRST_A_RGA			103
+#define SRST_H_RGA_NOC			104
+#define SRST_H_RGA			105
+#define SRST_RGA_CORE			106
+#define SRST_EMMC_NOC			108
+#define SRST_EMMC			109
+#define SRST_EMMC_GRF			110
+
+/* cru_softrst_con7 */
+#define SRST_A_PERIHP_NOC		112
+#define SRST_P_PERIHP_GRF		113
+#define SRST_H_PERIHP_NOC		114
+#define SRST_USBHOST0			115
+#define SRST_HOSTC0_AUX			116
+#define SRST_HOST0_ARB			117
+#define SRST_USBHOST1			118
+#define SRST_HOSTC1_AUX			119
+#define SRST_HOST1_ARB			120
+#define SRST_SDIO0			121
+#define SRST_SDMMC			122
+#define SRST_HSIC			123
+#define SRST_HSIC_AUX			124
+#define SRST_AHB1TOM			125
+#define SRST_P_PERIHP_NOC		126
+#define SRST_HSICPHY			127
+
+/* cru_softrst_con8 */
+#define SRST_A_PCIE			128
+#define SRST_P_PCIE			129
+#define SRST_PCIE_CORE			130
+#define SRST_PCIE_MGMT			131
+#define SRST_PCIE_MGMT_STICKY		132
+#define SRST_PCIE_PIPE			133
+#define SRST_PCIE_PM			134
+#define SRST_PCIEPHY			135
+#define SRST_A_GMAC_NOC			136
+#define SRST_A_GMAC			137
+#define SRST_P_GMAC_NOC			138
+#define SRST_P_GMAC_GRF			140
+#define SRST_HSICPHY_POR		142
+#define SRST_HSICPHY_UTMI		143
+
+/* cru_softrst_con9 */
+#define SRST_USB2PHY0_POR		144
+#define SRST_USB2PHY0_UTMI_PORT0	145
+#define SRST_USB2PHY0_UTMI_PORT1	146
+#define SRST_USB2PHY0_EHCIPHY		147
+#define SRST_UPHY0_PIPE_L00		148
+#define SRST_UPHY0			149
+#define SRST_UPHY0_TCPDPWRUP		150
+#define SRST_USB2PHY1_POR		152
+#define SRST_USB2PHY1_UTMI_PORT0	153
+#define SRST_USB2PHY1_UTMI_PORT1	154
+#define SRST_USB2PHY1_EHCIPHY		155
+#define SRST_UPHY1_PIPE_L00		156
+#define SRST_UPHY1			157
+#define SRST_UPHY1_TCPDPWRUP		158
+
+/* cru_softrst_con10 */
+#define SRST_A_PERILP0_NOC		160
+#define SRST_A_DCF			161
+#define SRST_GIC500			162
+#define SRST_DMAC0_PERILP0		163
+#define SRST_DMAC1_PERILP0		164
+#define SRST_TZMA			165
+#define SRST_INTMEM			166
+#define SRST_ADB400_MST0		167
+#define SRST_ADB400_MST1		168
+#define SRST_ADB400_SLV0		169
+#define SRST_ADB400_SLV1		170
+#define SRST_H_PERILP0			171
+#define SRST_H_PERILP0_NOC		172
+#define SRST_ROM			173
+#define SRST_CRYPTO_S			174
+#define SRST_CRYPTO_M			175
+
+/* cru_softrst_con11 */
+#define SRST_P_DCF			176
+#define SRST_CM0S_NOC			177
+#define SRST_CM0S			178
+#define SRST_CM0S_DBG			179
+#define SRST_CM0S_PO			180
+#define SRST_CRYPTO			181
+#define SRST_P_PERILP1_SGRF		182
+#define SRST_P_PERILP1_GRF		183
+#define SRST_CRYPTO1_S			184
+#define SRST_CRYPTO1_M			185
+#define SRST_CRYPTO1			186
+#define SRST_GIC_NOC			188
+#define SRST_SD_NOC			189
+#define SRST_SDIOAUDIO_BRG		190
+
+/* cru_softrst_con12 */
+#define SRST_H_PERILP1			192
+#define SRST_H_PERILP1_NOC		193
+#define SRST_H_I2S0_8CH			194
+#define SRST_H_I2S1_8CH			195
+#define SRST_H_I2S2_8CH			196
+#define SRST_H_SPDIF_8CH		197
+#define SRST_P_PERILP1_NOC		198
+#define SRST_P_EFUSE_1024		199
+#define SRST_P_EFUSE_1024S		200
+#define SRST_P_I2C0			201
+#define SRST_P_I2C1			202
+#define SRST_P_I2C2			203
+#define SRST_P_I2C3			204
+#define SRST_P_I2C4			205
+#define SRST_P_I2C5			206
+#define SRST_P_MAILBOX0			207
+
+/* cru_softrst_con13 */
+#define SRST_P_UART0			208
+#define SRST_P_UART1			209
+#define SRST_P_UART2			210
+#define SRST_P_UART3			211
+#define SRST_P_SARADC			212
+#define SRST_P_TSADC			213
+#define SRST_P_SPI0			214
+#define SRST_P_SPI1			215
+#define SRST_P_SPI2			216
+#define SRST_P_SPI3			217
+#define SRST_P_SPI4			218
+#define SRST_SPI0			219
+#define SRST_SPI1			220
+#define SRST_SPI2			221
+#define SRST_SPI3			222
+#define SRST_SPI4			223
+
+/* cru_softrst_con14 */
+#define SRST_I2S0_8CH			224
+#define SRST_I2S1_8CH			225
+#define SRST_I2S2_8CH			226
+#define SRST_SPDIF_8CH			227
+#define SRST_UART0			228
+#define SRST_UART1			229
+#define SRST_UART2			230
+#define SRST_UART3			231
+#define SRST_TSADC			232
+#define SRST_I2C0			233
+#define SRST_I2C1			234
+#define SRST_I2C2			235
+#define SRST_I2C3			236
+#define SRST_I2C4			237
+#define SRST_I2C5			238
+#define SRST_SDIOAUDIO_NOC		239
+
+/* cru_softrst_con15 */
+#define SRST_A_VIO_NOC			240
+#define SRST_A_HDCP_NOC			241
+#define SRST_A_HDCP			242
+#define SRST_H_HDCP_NOC			243
+#define SRST_H_HDCP			244
+#define SRST_P_HDCP_NOC			245
+#define SRST_P_HDCP			246
+#define SRST_P_HDMI_CTRL		247
+#define SRST_P_DP_CTRL			248
+#define SRST_S_DP_CTRL			249
+#define SRST_C_DP_CTRL			250
+#define SRST_P_MIPI_DSI0		251
+#define SRST_P_MIPI_DSI1		252
+#define SRST_DP_CORE			253
+#define SRST_DP_I2S			254
+
+/* cru_softrst_con16 */
+#define SRST_GASKET			256
+#define SRST_VIO_GRF			258
+#define SRST_DPTX_SPDIF_REC		259
+#define SRST_HDMI_CTRL			260
+#define SRST_HDCP_CTRL			261
+#define SRST_A_ISP0_NOC			262
+#define SRST_A_ISP1_NOC			263
+#define SRST_H_ISP0_NOC			266
+#define SRST_H_ISP1_NOC			267
+#define SRST_H_ISP0			268
+#define SRST_H_ISP1			269
+#define SRST_ISP0			270
+#define SRST_ISP1			271
+
+/* cru_softrst_con17 */
+#define SRST_A_VOP0_NOC			272
+#define SRST_A_VOP1_NOC			273
+#define SRST_A_VOP0			274
+#define SRST_A_VOP1			275
+#define SRST_H_VOP0_NOC			276
+#define SRST_H_VOP1_NOC			277
+#define SRST_H_VOP0			278
+#define SRST_H_VOP1			279
+#define SRST_D_VOP0			280
+#define SRST_D_VOP1			281
+#define SRST_VOP0_PWM			282
+#define SRST_VOP1_PWM			283
+#define SRST_P_EDP_NOC			284
+#define SRST_P_EDP_CTRL			285
+
+/* cru_softrst_con18 */
+#define SRST_A_GPU_NOC			289
+#define SRST_A_GPU_GRF			290
+#define SRST_PVTM_GPU			291
+#define SRST_A_USB3_NOC			292
+#define SRST_A_USB3_OTG0		293
+#define SRST_A_USB3_OTG1		294
+#define SRST_A_USB3_GRF			295
+#define SRST_PMU			296
+
+/* cru_softrst_con19 */
+#define SRST_P_TIMER0_5			304
+#define SRST_TIMER0			305
+#define SRST_TIMER1			306
+#define SRST_TIMER2			307
+#define SRST_TIMER3			308
+#define SRST_TIMER4			309
+#define SRST_TIMER5			310
+#define SRST_P_TIMER6_11		311
+#define SRST_TIMER6			312
+#define SRST_TIMER7			313
+#define SRST_TIMER8			314
+#define SRST_TIMER9			315
+#define SRST_TIMER10			316
+#define SRST_TIMER11			317
+#define SRST_P_INTR_ARB_PMU		318
+#define SRST_P_ALIVE_SGRF		319
+
+/* cru_softrst_con20 */
+#define SRST_P_GPIO2			320
+#define SRST_P_GPIO3			321
+#define SRST_P_GPIO4			322
+#define SRST_P_GRF			323
+#define SRST_P_ALIVE_NOC		324
+#define SRST_P_WDT0			325
+#define SRST_P_WDT1			326
+#define SRST_P_INTR_ARB			327
+#define SRST_P_UPHY0_DPTX		328
+#define SRST_P_UPHY0_APB		330
+#define SRST_P_UPHY0_TCPHY		332
+#define SRST_P_UPHY1_TCPHY		333
+#define SRST_P_UPHY0_TCPDCTRL		334
+#define SRST_P_UPHY1_TCPDCTRL		335
+
+/* pmu soft-reset indices */
+
+/* pmu_cru_softrst_con0 */
+#define SRST_P_NOC			0
+#define SRST_P_INTMEM			1
+#define SRST_H_CM0S			2
+#define SRST_H_CM0S_NOC			3
+#define SRST_DBG_CM0S			4
+#define SRST_PO_CM0S			5
+#define SRST_P_SPI6			6
+#define SRST_SPI6			7
+#define SRST_P_TIMER_0_1		8
+#define SRST_P_TIMER_0			9
+#define SRST_P_TIMER_1			10
+#define SRST_P_UART4			11
+#define SRST_UART4			12
+#define SRST_P_WDT			13
+
+/* pmu_cru_softrst_con1 */
+#define SRST_P_I2C6			16
+#define SRST_P_I2C7			17
+#define SRST_P_I2C8			18
+#define SRST_P_MAILBOX			19
+#define SRST_P_RKPWM			20
+#define SRST_P_PMUGRF			21
+#define SRST_P_SGRF			22
+#define SRST_P_GPIO0			23
+#define SRST_P_GPIO1			24
+#define SRST_P_CRU			25
+#define SRST_P_INTR			26
+#define SRST_PVTM			27
+#define SRST_I2C6			28
+#define SRST_I2C7			29
+#define SRST_I2C8			30
+
+#endif
-- 
1.9.1




From robert.jarzmik at free.fr  Mon Feb 22 23:13:57 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Tue, 23 Feb 2016 08:13:57 +0100
Subject: [PATCH v2 4/4] dmaengine: pxa_dma: fix the maximum requestor line
In-Reply-To: <20160223031335.GJ17690@localhost> (Vinod Koul's message of "Tue, 
 23 Feb 2016 08:43:36 +0530")
References: <1455569868-25017-1-git-send-email-robert.jarzmik@free.fr>
 <1455569868-25017-4-git-send-email-robert.jarzmik@free.fr>
 <20160223031335.GJ17690@localhost>
Message-ID: <877fhvx5je.fsf@belgarion.home>

Vinod Koul <vinod.koul at intel.com> writes:

> On Mon, Feb 15, 2016 at 09:57:48PM +0100, Robert Jarzmik wrote:
>> The current number of requestor lines is limited to 31. This was an
>> error of a previous commit, as this number is platform dependent, and is
>> actually :
>>  - for pxa25x: 40 requestor lines
>>  - for pxa27x: 75 requestor lines
>>  - for pxa3xx: 100 requestor lines
>> 
>> The previous testing did not reveal the faulty constant as on pxa[23]xx
>> platforms, only camera, MSL and USB are above requestor 32, and in these
>> only the camera has a driver using dma.
>> 
>> Fixes: e87ffbdf0697 ("dmaengine: pxa_dma: fix the no-requestor case")
>> Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
>
> Acked-by: Vinod Koul <vinod.koul at intel.com>
>
> Which tree is this targetted thru?
PXA for-next tree, my tree, once I gather the acks.

Cheers.

-- 
Robert


From jitao.shi at mediatek.com  Mon Feb 22 23:35:36 2016
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Tue, 23 Feb 2016 15:35:36 +0800
Subject: [PATCH v11 1/2] Documentation: bridge: Add documentation for ps8640
 DT properties
Message-ID: <1456212937-7635-1-git-send-email-jitao.shi@mediatek.com>

Add documentation for DT properties supported by
ps8640 DSI-eDP converter.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
Acked-by: Rob Herring <robh at kernel.org>
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>
---
Chnages since v10:
 - set sleep reset pin as GPIO_ACTIVE_LOW
---
 .../devicetree/bindings/display/bridge/ps8640.txt  |   43 ++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.txt b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
new file mode 100644
index 0000000..022b33f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
@@ -0,0 +1,43 @@
+ps8640-bridge bindings
+
+Required properties:
+	- compatible: "parade,ps8640"
+	- reg: first page address of the bridge.
+	- sleep-gpios: OF device-tree gpio specification for PD pin.
+	- reset-gpios: OF device-tree gpio specification for reset pin.
+	- mode-sel-gpios: OF device-tree gpio specification for mode-sel pin.
+	- vdd12-supply: OF device-tree regulator specification for 1.2V power.
+	- vdd33-supply: OF device-tree regulator specification for 3.3V power.
+	- ports: The device node can contain video interface port nodes per
+		 the video-interfaces bind[1]. For port at 0,set the reg = <0> as
+		 ps8640 dsi in and port at 1,set the reg = <1> as ps8640 eDP out.
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+	edp-bridge at 18 {
+		compatible = "parade,ps8640";
+		reg = <0x18>;
+		sleep-gpios = <&pio 116 GPIO_ACTIVE_LOW>;
+		reset-gpios = <&pio 115 GPIO_ACTIVE_LOW>;
+		mode-sel-gpios = <&pio 92 GPIO_ACTIVE_HIGH>;
+		vdd12-supply = <&ps8640_fixed_1v2>;
+		vdd33-supply = <&mt6397_vgp2_reg>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			port at 0 {
+				reg = <0>;
+				ps8640_in: endpoint {
+					remote-endpoint = <&dsi0_out>;
+				};
+			};
+			port at 1 {
+				reg = <1>;
+				ps8640_out: endpoint {
+					remote-endpoint = <&panel_in>;
+				};
+			};
+		};
+	};
-- 
1.7.9.5



From jitao.shi at mediatek.com  Mon Feb 22 23:35:37 2016
From: jitao.shi at mediatek.com (Jitao Shi)
Date: Tue, 23 Feb 2016 15:35:37 +0800
Subject: [PATCH v11 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
In-Reply-To: <1456212937-7635-1-git-send-email-jitao.shi@mediatek.com>
References: <1456212937-7635-1-git-send-email-jitao.shi@mediatek.com>
Message-ID: <1456212937-7635-2-git-send-email-jitao.shi@mediatek.com>

This patch adds drm_bridge driver for parade DSI to eDP bridge chip.

Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
---
 Changes since v10:
 - Tuning PS8640 reset sleep pins squence
 
The following patches are needed to support dsi host through none dsi bus:

https://patchwork.kernel.org/patch/8289181/ ("drm/dsi: check for CONFIG_OF when defining")
https://patchwork.kernel.org/patch/8289051/ ("drm/dsi: Use mipi_dsi_device_register_full for DSI device")
https://patchwork.kernel.org/patch/8289081/ ("drm/dsi: Try to match non-DT DSI devices")
https://patchwork.kernel.org/patch/8289121/ ("drm/dsi: Add routine to unregister a DSI device")
https://patchwork.kernel.org/patch/8289091/ ("drm/dsi: Get DSI host by DT device node")
---
 drivers/gpu/drm/bridge/Kconfig         |   11 +
 drivers/gpu/drm/bridge/Makefile        |    1 +
 drivers/gpu/drm/bridge/parade-ps8640.c | 1060 ++++++++++++++++++++++++++++++++
 3 files changed, 1072 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 27e2022..b4edd8c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,4 +40,15 @@ config DRM_PARADE_PS8622
 	---help---
 	  Parade eDP-LVDS bridge chip driver.
 
+config DRM_PARADE_PS8640
+	tristate "Parade PS8640 MIPI DSI to eDP Converter"
+	depends on OF && I2C
+	select DRM_KMS_HELPER
+	select DRM_MIPI_DSI
+	select DRM_PANEL
+	---help---
+	  Choose this option if you have PS8640 for display
+	  The PS8640 is a high-performance and low-power
+	  MIPI DSI to eDP converter
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f13c33d..fbe38dc 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c
new file mode 100644
index 0000000..d7410df
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -0,0 +1,1060 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/firmware.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/of_graph.h>
+#include <linux/regulator/consumer.h>
+#include <asm/unaligned.h>
+#include <drm/drm_panel.h>
+
+#include <drmP.h>
+#include <drm_atomic_helper.h>
+#include <drm_crtc_helper.h>
+#include <drm_crtc.h>
+#include <drm_edid.h>
+#include <drm_mipi_dsi.h>
+
+#define PAGE2_SPI_CFG3		0x82
+#define I2C_TO_SPI_RESET	0x20
+#define PAGE2_ROMADD_BYTE1	0x8e
+#define PAGE2_ROMADD_BYTE2	0x8f
+#define PAGE2_SWSPI_WDATA	0x90
+#define PAGE2_SWSPI_RDATA	0x91
+#define PAGE2_SWSPI_LEN		0x92
+#define PAGE2_SWSPI_CTL		0x93
+#define TRIGGER_NO_READBACK	0x05
+#define TRIGGER_READBACK	0x01
+#define PAGE2_SPI_STATUS	0x9e
+#define PAGE2_GPIO_L		0xa6
+#define PAGE2_GPIO_H		0xa7
+#define PS_GPIO9		BIT(1)
+#define PAGE2_IROM_CTRL		0xb0
+#define IROM_ENABLE		0xc0
+#define IROM_DISABLE		0x80
+#define PAGE2_SW_REST		0xbc
+#define SPI_SW_RESET		BIT(7)
+#define MPU_SW_RESET		BIT(6)
+#define PAGE2_ENCTLSPI_WR	0xda
+#define PAGE2_I2C_BYPASS	0xea
+#define I2C_BYPASS_EN		0xd0
+#define PAGE3_SET_ADD		0xfe
+#define PAGE3_SET_VAL		0xff
+#define VDO_CTL_ADD		0x13
+#define VDO_DIS			0x18
+#define VDO_EN			0x1c
+#define PAGE4_REV_L		0xf0
+#define PAGE4_REV_H		0xf1
+#define PAGE4_CHIP_L		0xf2
+#define PAGE4_CHIP_H		0xf3
+
+/* Firmware */
+#define SPI_MAX_RETRY_CNT	8
+#define PS_FW_NAME		"ps864x_fw.bin"
+
+#define FW_CHIP_ID_OFFSET	0
+#define FW_VERSION_OFFSET	2
+#define EDID_I2C_ADDR		0x50
+
+#define WRITE_STATUS_REG_CMD	0x01
+#define READ_STATUS_REG_CMD	0x05
+#define CLEAR_ALL_PROTECT	0x00
+#define BLK_PROTECT_BITS	0x0c
+#define STATUS_REG_PROTECT	BIT(7)
+#define WRITE_ENABLE_CMD	0x06
+#define CHIP_ERASE_CMD		0xc7
+
+#define bridge_to_ps8640(e)	container_of(e, struct ps8640, bridge)
+#define connector_to_ps8640(e)	container_of(e, struct ps8640, connector)
+
+struct ps8640_info {
+	u8 family_id;
+	u8 variant_id;
+	u16 version;
+};
+
+struct ps8640 {
+	struct drm_connector connector;
+	struct drm_bridge bridge;
+	struct edid *edid;
+	struct mipi_dsi_device dsi;
+	struct i2c_client *page[8];
+	struct i2c_client *ddc_i2c;
+	struct regulator_bulk_data supplies[2];
+	struct drm_panel *panel;
+	struct gpio_desc *gpio_rst_n;
+	struct gpio_desc *gpio_slp_n;
+	struct gpio_desc *gpio_mode_sel_n;
+	bool enabled;
+
+	/* firmware file info */
+	bool in_fw_update;
+	struct ps8640_info info;
+};
+
+static const u8 enc_ctrl_code[6] = {0xaa, 0x55, 0x50, 0x41, 0x52, 0x44};
+
+static int ps8640_read(struct i2c_client *client, u8 reg, u8 *data,
+		       u16 data_len)
+{
+	int ret;
+	struct i2c_msg msgs[] = {
+		{
+		 .addr = client->addr,
+		 .flags = 0,
+		 .len = 1,
+		 .buf = &reg,
+		 },
+		{
+		 .addr = client->addr,
+		 .flags = I2C_M_RD,
+		 .len = data_len,
+		 .buf = data,
+		 }
+	};
+
+	ret = i2c_transfer(client->adapter, msgs, 2);
+
+	if (ret == 2)
+		return 0;
+	if (ret < 0)
+		return ret;
+	else
+		return -EIO;
+}
+
+static int ps8640_write_bytes(struct i2c_client *client, u8 *data,
+			      u16 data_len)
+{
+	int ret;
+	struct i2c_msg msg;
+
+	msg.addr = client->addr;
+	msg.flags = 0;
+	msg.len = data_len;
+	msg.buf = data;
+
+	ret = i2c_transfer(client->adapter, &msg, 1);
+	if (ret == 1)
+		return 0;
+	if (ret < 0)
+		return ret;
+	else
+		return -EIO;
+}
+
+static int ps8640_write_byte(struct i2c_client *client, u8 reg,  u8 data)
+{
+	int ret;
+	struct i2c_msg msg;
+	u8 buf[] = {reg, data};
+
+	msg.addr = client->addr;
+	msg.flags = 0;
+	msg.len = sizeof(buf);
+	msg.buf = buf;
+
+	ret = i2c_transfer(client->adapter, &msg, 1);
+	if (ret == 1)
+		return 0;
+	if (ret < 0)
+		return ret;
+	else
+		return -EIO;
+}
+
+static void ps8640_get_mcu_fw_version(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[5];
+	u8 fw_ver[2];
+
+	ps8640_read(client, 0x4, fw_ver, 2);
+	ps_bridge->info.version = (fw_ver[0] << 8) | fw_ver[1];
+
+	DRM_INFO_ONCE("ps8640 rom fw version %d.%d\n", fw_ver[0], fw_ver[1]);
+}
+
+static int ps8640_bridge_enable(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[3];
+	u8 vdo_ctrl_buf[3] = {PAGE3_SET_ADD, VDO_CTL_ADD, VDO_EN};
+
+	return ps8640_write_bytes(client, vdo_ctrl_buf, 3);
+}
+
+static int ps8640_bridge_disable(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[3];
+	u8 vdo_ctrl_buf[3] = {PAGE3_SET_ADD, VDO_CTL_ADD, VDO_DIS};
+
+	return ps8640_write_bytes(client, vdo_ctrl_buf, 3);
+}
+
+static void ps8640_pre_enable(struct drm_bridge *bridge)
+{
+	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+	struct i2c_client *client = ps_bridge->page[2];
+	int err, retry_cnt = 0;
+	u8 set_vdo_done;
+
+	if (ps_bridge->in_fw_update)
+		return;
+
+	if (ps_bridge->enabled)
+		return;
+
+	err = drm_panel_prepare(ps_bridge->panel);
+	if (err < 0) {
+		DRM_ERROR("failed to prepare panel: %d\n", err);
+		return;
+	}
+
+	err = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
+				    ps_bridge->supplies);
+	if (err < 0) {
+		DRM_ERROR("cannot enable regulators %d\n", err);
+		goto err_panel_unprepare;
+	}
+
+	gpiod_set_value(ps_bridge->gpio_slp_n, 1);
+	gpiod_set_value(ps_bridge->gpio_rst_n, 0);
+	usleep_range(2000, 2500);
+	gpiod_set_value(ps_bridge->gpio_rst_n, 1);
+
+	/*
+	 * Wait for the ps8640 embed mcu ready
+	 * First wait 200ms and then check the mcu ready flag every 20ms
+	 */
+	msleep(200);
+	do {
+		err = ps8640_read(client, PAGE2_GPIO_H, &set_vdo_done, 1);
+		if (err < 0) {
+			DRM_ERROR("failed read PAGE2_GPIO_H: %d\n", err);
+			goto err_regulators_disable;
+		}
+		msleep(20);
+	} while ((retry_cnt++ < 10) && ((set_vdo_done & PS_GPIO9) != PS_GPIO9));
+
+	if (ps_bridge->info.version == 0)
+		ps8640_get_mcu_fw_version(ps_bridge);
+	/* Switch access edp panel's edid through i2c */
+	ps8640_write_byte(client, PAGE2_I2C_BYPASS, I2C_BYPASS_EN);
+	ps_bridge->enabled = true;
+
+	return;
+
+err_regulators_disable:
+	regulator_bulk_disable(ARRAY_SIZE(ps_bridge->supplies),
+			       ps_bridge->supplies);
+err_panel_unprepare:
+	drm_panel_unprepare(ps_bridge->panel);
+}
+
+static void ps8640_enable(struct drm_bridge *bridge)
+{
+	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+	int err;
+
+	err = ps8640_bridge_enable(ps_bridge);
+	if (err)
+		DRM_ERROR("failed to enable unmutevideo: %d\n", err);
+
+	err = drm_panel_enable(ps_bridge->panel);
+	if (err < 0)
+		DRM_ERROR("failed to enable panel: %d\n", err);
+}
+
+static void ps8640_disable(struct drm_bridge *bridge)
+{
+	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+	int err;
+
+	err = drm_panel_disable(ps_bridge->panel);
+	if (err < 0)
+		DRM_ERROR("failed to disable panel: %d\n", err);
+
+	err = ps8640_bridge_disable(ps_bridge);
+	if (err < 0)
+		DRM_ERROR("failed to disable bridge: %d\n", err);
+}
+
+static void ps8640_post_disable(struct drm_bridge *bridge)
+{
+	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+	int err;
+
+	if (ps_bridge->in_fw_update)
+		return;
+
+	if (!ps_bridge->enabled)
+		return;
+
+	ps_bridge->enabled = false;
+
+	gpiod_set_value(ps_bridge->gpio_rst_n, 0);
+	gpiod_set_value(ps_bridge->gpio_slp_n, 0);
+	err = regulator_bulk_disable(ARRAY_SIZE(ps_bridge->supplies),
+				     ps_bridge->supplies);
+	if (err < 0)
+		DRM_ERROR("cannot disable regulators %d\n", err);
+
+	err = drm_panel_unprepare(ps_bridge->panel);
+	if (err)
+		DRM_ERROR("failed to unprepare panel: %d\n", err);
+}
+
+static int ps8640_get_modes(struct drm_connector *connector)
+{
+	struct ps8640 *ps_bridge = connector_to_ps8640(connector);
+	struct device *dev = &ps_bridge->page[0]->dev;
+	u8 *edid;
+	int ret, num_modes = 0;
+	bool power_off;
+
+	if (ps_bridge->edid)
+		return drm_add_edid_modes(connector, ps_bridge->edid);
+
+	power_off = !ps_bridge->enabled;
+	ps8640_pre_enable(&ps_bridge->bridge);
+
+	edid = devm_kmalloc(dev, EDID_LENGTH, GFP_KERNEL);
+	if (!edid) {
+		DRM_ERROR("Failed to allocate EDID\n");
+		return 0;
+	}
+
+	ret = ps8640_read(ps_bridge->ddc_i2c, 0, edid, EDID_LENGTH);
+	if (ret)
+		goto out;
+
+	ps_bridge->edid = (struct edid *)edid;
+	drm_mode_connector_update_edid_property(connector, ps_bridge->edid);
+
+	num_modes = drm_add_edid_modes(connector, ps_bridge->edid);
+
+out:
+	if (power_off)
+		ps8640_post_disable(&ps_bridge->bridge);
+
+	return num_modes;
+}
+
+static struct drm_encoder *ps8640_best_encoder(struct drm_connector *connector)
+{
+	struct ps8640 *ps_bridge;
+
+	ps_bridge = connector_to_ps8640(connector);
+	return ps_bridge->bridge.encoder;
+}
+
+static const struct drm_connector_helper_funcs ps8640_connector_helper_funcs = {
+	.get_modes = ps8640_get_modes,
+	.best_encoder = ps8640_best_encoder,
+};
+
+static enum drm_connector_status ps8640_detect(struct drm_connector *connector,
+					       bool force)
+{
+	return connector_status_connected;
+}
+
+static void ps8640_connector_destroy(struct drm_connector *connector)
+{
+	drm_connector_unregister(connector);
+	drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs ps8640_connector_funcs = {
+	.dpms = drm_atomic_helper_connector_dpms,
+	.fill_modes = drm_helper_probe_single_connector_modes,
+	.detect = ps8640_detect,
+	.destroy = ps8640_connector_destroy,
+	.reset = drm_atomic_helper_connector_reset,
+	.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+int ps8640_bridge_attach(struct drm_bridge *bridge)
+{
+	struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+	struct device *dev = &ps_bridge->page[0]->dev;
+	struct device_node *np = dev->of_node;
+	struct device_node *port, *in_ep;
+	struct device_node *dsi_node = NULL;
+	struct mipi_dsi_host *host = ps_bridge->dsi.host;
+	int ret;
+
+	ret = drm_connector_init(bridge->dev, &ps_bridge->connector,
+				 &ps8640_connector_funcs,
+				 DRM_MODE_CONNECTOR_eDP);
+
+	if (ret) {
+		DRM_ERROR("Failed to initialize connector with drm: %d\n", ret);
+		return ret;
+	}
+
+	drm_connector_helper_add(&ps_bridge->connector,
+				 &ps8640_connector_helper_funcs);
+	drm_connector_register(&ps_bridge->connector);
+
+	ps_bridge->connector.dpms = DRM_MODE_DPMS_ON;
+	drm_mode_connector_attach_encoder(&ps_bridge->connector,
+					  bridge->encoder);
+
+	if (ps_bridge->panel)
+		drm_panel_attach(ps_bridge->panel, &ps_bridge->connector);
+
+	/* port at 0 is ps8640 dsi input port */
+	port = of_graph_get_port_by_id(np, 0);
+	if (port) {
+		in_ep = of_get_child_by_name(port, "endpoint");
+		of_node_put(port);
+		if (in_ep) {
+			dsi_node = of_graph_get_remote_port_parent(in_ep);
+			of_node_put(in_ep);
+		}
+	}
+	if (dsi_node) {
+		host = of_find_mipi_dsi_host_by_node(dsi_node);
+		of_node_put(dsi_node);
+		if (!host)
+			return -ENODEV;
+	}
+
+	ps_bridge->dsi.host = host;
+	ps_bridge->dsi.mode_flags = MIPI_DSI_MODE_VIDEO |
+				     MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
+	ps_bridge->dsi.format = MIPI_DSI_FMT_RGB888;
+	ps_bridge->dsi.lanes = 4;
+	ret = mipi_dsi_attach(&ps_bridge->dsi);
+	if (ret) {
+		drm_panel_detach(ps_bridge->panel);
+		return ret;
+	}
+
+	return ret;
+}
+
+static const struct drm_bridge_funcs ps8640_bridge_funcs = {
+	.attach = ps8640_bridge_attach,
+	.disable = ps8640_disable,
+	.post_disable = ps8640_post_disable,
+	.pre_enable = ps8640_pre_enable,
+	.enable = ps8640_enable,
+};
+
+/* Firmware Version is returned as Major.Minor.Build */
+static ssize_t ps8640_fw_version_show(struct device *dev,
+				      struct device_attribute *attr, char *buf)
+{
+	struct ps8640 *ps_bridge = dev_get_drvdata(dev);
+	struct ps8640_info *info = &ps_bridge->info;
+
+	return scnprintf(buf, PAGE_SIZE, "%u.%u\n", info->version >> 8,
+			 info->version & 0xff);
+}
+
+/* Hardware Version is returned as FamilyID.VariantID */
+static ssize_t ps8640_hw_version_show(struct device *dev,
+				      struct device_attribute *attr, char *buf)
+{
+	struct ps8640 *ps_bridge = dev_get_drvdata(dev);
+	struct ps8640_info *info = &ps_bridge->info;
+
+	return scnprintf(buf, PAGE_SIZE, "ps%u.%u\n", info->family_id,
+			 info->variant_id);
+}
+
+static int ps8640_spi_send_cmd(struct ps8640 *ps_bridge, u8 *cmd, u8 cmd_len)
+{
+	struct i2c_client *client = ps_bridge->page[2];
+	u8 i, buf[3];
+	int ret;
+
+	ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_ENABLE);
+	if (ret)
+		goto err;
+
+	/* write command in write port */
+	for (i = 0; i < cmd_len; i++) {
+		ret = ps8640_write_byte(client, PAGE2_SWSPI_WDATA, cmd[i]);
+		if (ret)
+			goto err;
+	}
+
+	buf[0] = PAGE2_SWSPI_LEN;
+	buf[1] = cmd_len - 1;
+	buf[2] = TRIGGER_NO_READBACK;
+	ret = ps8640_write_bytes(client, buf, 3);
+	if (ret)
+		goto err;
+
+	ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
+	if (ret)
+		goto err;
+
+	return 0;
+
+err:
+	dev_err(&client->dev, "send command err: %d\n", ret);
+	return ret;
+}
+
+static int ps8640_wait_spi_ready(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[2];
+	u8 spi_rdy_st, retry_cnt = 0;
+
+	do {
+		ps8640_read(client, PAGE2_SPI_STATUS, &spi_rdy_st, 1);
+		msleep(20);
+		if ((retry_cnt == SPI_MAX_RETRY_CNT) &&
+		    ((spi_rdy_st & 0x0c) != 0x0c)) {
+			dev_err(&client->dev, "wait spi ready timeout\n");
+			return -EBUSY;
+		}
+	} while ((retry_cnt++ < SPI_MAX_RETRY_CNT) &&
+		 (spi_rdy_st & 0x0c) == 0x0c);
+
+	return 0;
+}
+
+static int ps8640_wait_spi_nobusy(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[2];
+	u8 spi_status, buf[3], retry_cnt = 0;
+	int ret;
+
+	do {
+		/* 0x05 RDSR; Read-Status-Register */
+		ret = ps8640_write_byte(client, PAGE2_SWSPI_WDATA,
+					READ_STATUS_REG_CMD);
+		if (ret)
+			goto err_send_cmd_exit;
+
+		buf[0] = PAGE2_SWSPI_LEN;
+		buf[1] = 0;
+		buf[2] = TRIGGER_READBACK;
+		ret = ps8640_write_bytes(client, buf, 3);
+		if (ret)
+			goto err_send_cmd_exit;
+
+		/* delay for cmd send */
+		usleep_range(100, 300);
+		/* wait for SPI ROM until not busy */
+		ret = ps8640_read(client, PAGE2_SWSPI_RDATA, &spi_status, 1);
+		if (ret)
+			goto err_send_cmd_exit;
+	} while ((retry_cnt++ < SPI_MAX_RETRY_CNT) &&
+		 (spi_status & BLK_PROTECT_BITS) == BLK_PROTECT_BITS);
+
+	if ((retry_cnt > SPI_MAX_RETRY_CNT) &&
+	    (spi_status & BLK_PROTECT_BITS) != BLK_PROTECT_BITS) {
+		ret = -EBUSY;
+		dev_err(&client->dev, "wait spi no busy timeout: %d\n", ret);
+		goto err_timeout;
+	}
+
+	return 0;
+
+err_send_cmd_exit:
+	dev_err(&client->dev, "send command err: %d\n", ret);
+
+err_timeout:
+	return ret;
+}
+
+static int ps8640_wait_rom_idle(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[0];
+	int ret;
+
+	ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_ENABLE);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_wait_spi_ready(ps_bridge);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_wait_spi_nobusy(ps_bridge);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
+	if (ret)
+		goto exit;
+
+exit:
+	if (ret)
+		dev_err(&client->dev, "wait ps8640 rom idle fail: %d\n", ret);
+
+	return ret;
+}
+
+static int ps8640_spi_dl_mode(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[2];
+	int ret;
+
+	/* switch ps8640 mode to spi dl mode */
+	gpiod_set_value(ps_bridge->gpio_mode_sel_n, 0);
+
+	/* reset spi interface */
+	ret = ps8640_write_byte(client, PAGE2_SW_REST,
+				SPI_SW_RESET | MPU_SW_RESET);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_write_byte(client, PAGE2_SW_REST, MPU_SW_RESET);
+	if (ret)
+		goto exit;
+
+exit:
+	if (ret)
+		dev_err(&client->dev, "fail reset spi interface: %d\n", ret);
+
+	return ret;
+}
+
+static int ps8640_rom_prepare(struct ps8640 *ps_bridge)
+{
+	struct i2c_client *client = ps_bridge->page[2];
+	struct device *dev = &client->dev;
+	u8 i, cmd[2];
+	int ret;
+
+	cmd[0] = WRITE_ENABLE_CMD;
+	ret = ps8640_spi_send_cmd(ps_bridge, cmd, 1);
+	if (ret) {
+		dev_err(dev, "failed enable-write-status-register: %d\n", ret);
+		return ret;
+	}
+
+	cmd[0] = WRITE_STATUS_REG_CMD;
+	cmd[1] = CLEAR_ALL_PROTECT;
+	ret = ps8640_spi_send_cmd(ps_bridge, cmd, 2);
+	if (ret) {
+		dev_err(dev, "fail disable all protection: %d\n", ret);
+		return ret;
+	}
+
+	/* wait for SPI module ready */
+	ret = ps8640_wait_rom_idle(ps_bridge);
+	if (ret) {
+		dev_err(dev, "fail wait rom idle: %d\n", ret);
+		return ret;
+	}
+
+	ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_ENABLE);
+	for (i = 0; i < 6; i++)
+		ps8640_write_byte(client, PAGE2_ENCTLSPI_WR, enc_ctrl_code[i]);
+	ps8640_write_byte(client, PAGE2_IROM_CTRL, IROM_DISABLE);
+
+	/* Enable-Write-Status-Register */
+	cmd[0] = WRITE_ENABLE_CMD;
+	ret = ps8640_spi_send_cmd(ps_bridge, cmd, 1);
+	if (ret) {
+		dev_err(dev, "fail enable-write-status-register: %d\n", ret);
+		return ret;
+	}
+
+	/* chip erase command */
+	cmd[0] = CHIP_ERASE_CMD;
+	ret = ps8640_spi_send_cmd(ps_bridge, cmd, 1);
+	if (ret) {
+		dev_err(dev, "fail disable all protection: %d\n", ret);
+		return ret;
+	}
+
+	ret = ps8640_wait_rom_idle(ps_bridge);
+	if (ret) {
+		dev_err(dev, "fail wait rom idle: %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int ps8640_validate_firmware(struct ps8640 *ps_bridge,
+				    const struct firmware *fw)
+{
+	struct i2c_client *client = ps_bridge->page[0];
+	struct ps8640_info *info = &ps_bridge->info;
+	u16 fw_chip_id, fw_version_id;
+
+	/*
+	 * Get the chip_id from the firmware. Make sure that it is the
+	 * right controller to do the firmware and config update.
+	 */
+	fw_chip_id = get_unaligned_le16(fw->data + FW_CHIP_ID_OFFSET);
+
+	if (fw_chip_id != 0x8640) {
+		dev_err(&client->dev,
+			"chip id mismatch: fw 0x%x vs. chip 0x8640\n",
+			fw_chip_id);
+		return -ENODEV;
+	}
+
+	fw_version_id = get_unaligned_le16(fw->data + FW_VERSION_OFFSET);
+
+	if (fw_version_id == info->version) {
+		dev_err(&client->dev,
+			"no need update fw version same: fw %d.%d vs. chip %d.%d\n",
+			fw_version_id >> 8, fw_version_id & 0xff,
+			info->version >> 8, info->version & 0xff);
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+static int ps8640_write_rom(struct ps8640 *ps_bridge, const struct firmware *fw)
+{
+	struct i2c_client *client = ps_bridge->page[0];
+	struct device *dev = &client->dev;
+	struct i2c_client *client2 = ps_bridge->page[2];
+	struct i2c_client *client7 = ps_bridge->page[7];
+	unsigned int pos = 0;
+	u8 buf[257], rom_page_id_buf[3];
+	int ret;
+	u16 cpy_len;
+
+	ps8640_write_byte(client2, PAGE2_SPI_CFG3, I2C_TO_SPI_RESET);
+	msleep(100);
+	ps8640_write_byte(client2, PAGE2_SPI_CFG3, 0x00);
+
+	while (pos < fw->size) {
+		rom_page_id_buf[0] = PAGE2_ROMADD_BYTE1;
+		rom_page_id_buf[1] = (pos >> 8) & 0xff;
+		rom_page_id_buf[2] = (pos >> 16) & 0xff;
+		ret = ps8640_write_bytes(client2, rom_page_id_buf, 3);
+		if (ret)
+			goto error;
+		cpy_len = fw->size >= 256 + pos ? 256 : fw->size - pos;
+		buf[0] = 0;
+		memcpy(buf + 1, fw->data + pos, cpy_len);
+		ret = ps8640_write_bytes(client7, buf, cpy_len + 1);
+		if (ret)
+			goto error;
+
+		pos += cpy_len;
+
+		dev_dbg(dev, "fw update completed %u / %zu bytes\n", pos,
+			fw->size);
+	}
+	return 0;
+
+error:
+	dev_err(dev, "failed write extenal flash, %d\n", ret);
+	return ret;
+}
+
+static int ps8640_spi_normal_mode(struct ps8640 *ps_bridge)
+{
+	u8 cmd[2];
+	struct i2c_client *client = ps_bridge->page[2];
+
+	/* Enable-Write-Status-Register */
+	cmd[0] = WRITE_ENABLE_CMD;
+	ps8640_spi_send_cmd(ps_bridge, cmd, 1);
+
+	/* protect BPL/BP0/BP1 */
+	cmd[0] = WRITE_STATUS_REG_CMD;
+	cmd[1] = BLK_PROTECT_BITS | STATUS_REG_PROTECT;
+	ps8640_spi_send_cmd(ps_bridge, cmd, 2);
+
+	/* wait for SPI rom ready */
+	ps8640_wait_rom_idle(ps_bridge);
+
+	/* disable PS8640 mapping function */
+	ps8640_write_byte(client, PAGE2_ENCTLSPI_WR, 0x00);
+
+	gpiod_set_value(ps_bridge->gpio_mode_sel_n, 1);
+	return 0;
+}
+
+static int ps8640_enter_bl(struct ps8640 *ps_bridge)
+{
+	ps_bridge->in_fw_update = true;
+	return ps8640_spi_dl_mode(ps_bridge);
+}
+
+static void ps8640_exit_bl(struct ps8640 *ps_bridge, const struct firmware *fw)
+{
+	ps8640_spi_normal_mode(ps_bridge);
+	ps_bridge->in_fw_update = false;
+}
+
+static int ps8640_load_fw(struct ps8640 *ps_bridge, const struct firmware *fw)
+{
+	struct i2c_client *client = ps_bridge->page[0];
+	struct device *dev = &client->dev;
+	int ret;
+	bool ps8640_status_backup = ps_bridge->enabled;
+
+	if (!ps_bridge->in_fw_update) {
+		if (!ps8640_status_backup)
+			ps8640_pre_enable(&ps_bridge->bridge);
+
+		ret = ps8640_enter_bl(ps_bridge);
+		if (ret)
+			goto exit;
+	}
+
+	ret = ps8640_validate_firmware(ps_bridge, fw);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_rom_prepare(ps_bridge);
+	if (ret)
+		goto exit;
+
+	ret = ps8640_write_rom(ps_bridge, fw);
+
+exit:
+	if (ret)
+		dev_err(dev, "Failed to load firmware, %d\n", ret);
+
+	ps8640_exit_bl(ps_bridge, fw);
+	if (!ps8640_status_backup)
+		ps8640_post_disable(&ps_bridge->bridge);
+	return ret;
+}
+
+static ssize_t ps8640_update_fw_store(struct device *dev,
+				      struct device_attribute *attr,
+				      const char *buf, size_t count)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct ps8640 *ps_bridge = i2c_get_clientdata(client);
+	const struct firmware *fw;
+	int error;
+
+	error = request_firmware(&fw, PS_FW_NAME, dev);
+	if (error) {
+		dev_err(dev, "Unable to open firmware %s: %d\n",
+			PS_FW_NAME, error);
+		return error;
+	}
+
+	error = ps8640_load_fw(ps_bridge, fw);
+	if (error)
+		dev_err(dev, "The firmware update failed(%d)\n", error);
+	else
+		dev_info(dev, "The firmware update succeeded\n");
+
+	release_firmware(fw);
+	return error ? error : count;
+}
+
+static DEVICE_ATTR(fw_version, S_IRUGO, ps8640_fw_version_show, NULL);
+static DEVICE_ATTR(hw_version, S_IRUGO, ps8640_hw_version_show, NULL);
+static DEVICE_ATTR(update_fw, S_IWUSR, NULL, ps8640_update_fw_store);
+
+static struct attribute *ps8640_attrs[] = {
+	&dev_attr_fw_version.attr,
+	&dev_attr_hw_version.attr,
+	&dev_attr_update_fw.attr,
+	NULL
+};
+
+static const struct attribute_group ps8640_attr_group = {
+	.attrs = ps8640_attrs,
+};
+
+static void ps8640_remove_sysfs_group(void *data)
+{
+	struct ps8640 *ps_bridge = data;
+
+	sysfs_remove_group(&ps_bridge->page[0]->dev.kobj, &ps8640_attr_group);
+}
+
+static int ps8640_probe(struct i2c_client *client,
+			const struct i2c_device_id *id)
+{
+	struct device *dev = &client->dev;
+	struct ps8640 *ps_bridge;
+	struct device_node *np = dev->of_node;
+	struct device_node *port, *out_ep;
+	struct device_node *panel_node = NULL;
+	int i, ret;
+
+	ps_bridge = devm_kzalloc(dev, sizeof(*ps_bridge), GFP_KERNEL);
+	if (!ps_bridge)
+		return -ENOMEM;
+
+	/* port at 1 is ps8640 output port */
+	port = of_graph_get_port_by_id(np, 1);
+	if (port) {
+		out_ep = of_get_child_by_name(port, "endpoint");
+		of_node_put(port);
+		if (out_ep) {
+			panel_node = of_graph_get_remote_port_parent(out_ep);
+			of_node_put(out_ep);
+		}
+	}
+	if (panel_node) {
+		ps_bridge->panel = of_drm_find_panel(panel_node);
+		of_node_put(panel_node);
+		if (!ps_bridge->panel)
+			return -EPROBE_DEFER;
+	}
+
+	ps_bridge->supplies[0].supply = "vdd33";
+	ps_bridge->supplies[1].supply = "vdd12";
+	ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ps_bridge->supplies),
+				      ps_bridge->supplies);
+	if (ret) {
+		dev_info(dev, "failed to get regulators: %d\n", ret);
+		return -EPROBE_DEFER;
+	}
+
+	ps_bridge->gpio_mode_sel_n = devm_gpiod_get(&client->dev, "mode-sel",
+						    GPIOD_OUT_HIGH);
+	if (IS_ERR(ps_bridge->gpio_mode_sel_n)) {
+		ret = PTR_ERR(ps_bridge->gpio_mode_sel_n);
+		dev_err(dev, "cannot get mode-sel %d\n", ret);
+		return ret;
+	}
+
+	ps_bridge->gpio_slp_n = devm_gpiod_get(&client->dev, "sleep",
+					       GPIOD_OUT_LOW);
+	if (IS_ERR(ps_bridge->gpio_slp_n)) {
+		ret = PTR_ERR(ps_bridge->gpio_slp_n);
+		dev_err(dev, "cannot get sleep: %d\n", ret);
+		return ret;
+	}
+
+	/*
+	 * Request the reset pin low to avoid the bridge being
+	 * initialized prematurely
+	 */
+	ps_bridge->gpio_rst_n = devm_gpiod_get(&client->dev, "reset",
+					       GPIOD_OUT_LOW);
+	if (IS_ERR(ps_bridge->gpio_rst_n)) {
+		ret = PTR_ERR(ps_bridge->gpio_rst_n);
+		dev_err(dev, "cannot get reset: %d\n", ret);
+		return ret;
+	}
+
+	ps_bridge->bridge.funcs = &ps8640_bridge_funcs;
+	ps_bridge->bridge.of_node = dev->of_node;
+	ret = drm_bridge_add(&ps_bridge->bridge);
+	if (ret) {
+		dev_err(dev, "Failed to add bridge: %d\n", ret);
+		return ret;
+	}
+
+	ps_bridge->page[0] = client;
+	ps_bridge->ddc_i2c = i2c_new_dummy(client->adapter, EDID_I2C_ADDR);
+	if (!ps_bridge->ddc_i2c) {
+		dev_err(dev, "failed ddc_i2c dummy device, address%02x\n",
+			EDID_I2C_ADDR);
+		ret = -EBUSY;
+		goto exit_ddc_i2c_dummy;
+	}
+	/*
+	 * ps8640 uses multiple addresses, use dummy devices for them
+	 * page[0]: for DP control
+	 * page[1]: for VIDEO Bridge
+	 * page[2]: for control top
+	 * page[3]: for DSI Link Control1
+	 * page[4]: for MIPI Phy
+	 * page[5]: for VPLL
+	 * page[6]: for DSI Link Control2
+	 * page[7]: for spi rom mapping
+	 */
+	for (i = 1; i < 8; i++) {
+		ps_bridge->page[i] = i2c_new_dummy(client->adapter,
+						   client->addr + i);
+		if (!ps_bridge->page[i]) {
+			dev_err(dev, "failed i2c dummy device, address%02x\n",
+				client->addr + i);
+			ret = -EBUSY;
+			goto exit_dummy;
+		}
+	}
+	i2c_set_clientdata(client, ps_bridge);
+
+	ret = sysfs_create_group(&client->dev.kobj, &ps8640_attr_group);
+	if (ret) {
+		dev_err(dev, "failed to create sysfs entries: %d\n", ret);
+		goto exit_dummy;
+	}
+
+	ret = devm_add_action(dev, ps8640_remove_sysfs_group, ps_bridge);
+	if (ret) {
+		dev_err(dev, "failed to add sysfs cleanup action: %d\n", ret);
+		goto exit_remove_sysfs;
+	}
+	return 0;
+
+exit_remove_sysfs:
+	sysfs_remove_group(&ps_bridge->page[0]->dev.kobj, &ps8640_attr_group);
+exit_dummy:
+	for (i = 1; i < 8; i++)
+		if (ps_bridge->page[i])
+			i2c_unregister_device(ps_bridge->page[i]);
+exit_ddc_i2c_dummy:
+	drm_bridge_remove(&ps_bridge->bridge);
+	return ret;
+}
+
+static int ps8640_remove(struct i2c_client *client)
+{
+	struct ps8640 *ps_bridge = i2c_get_clientdata(client);
+	int i;
+
+	for (i = 1; i < 8; i++)
+		i2c_unregister_device(ps_bridge->page[i]);
+
+	drm_bridge_remove(&ps_bridge->bridge);
+
+	return 0;
+}
+
+static const struct i2c_device_id ps8640_i2c_table[] = {
+	{"parade,ps8640", 0},
+	{},
+};
+MODULE_DEVICE_TABLE(i2c, ps8640_i2c_table);
+
+static const struct of_device_id ps8640_match[] = {
+	{ .compatible = "parade,ps8640" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, ps8640_match);
+
+static struct i2c_driver ps8640_driver = {
+	.id_table = ps8640_i2c_table,
+	.probe = ps8640_probe,
+	.remove = ps8640_remove,
+	.driver = {
+		.name = "parade,ps8640",
+		.of_match_table = ps8640_match,
+	},
+};
+module_i2c_driver(ps8640_driver);
+
+MODULE_AUTHOR("Jitao Shi <jitao.shi at mediatek.com>");
+MODULE_AUTHOR("CK Hu <ck.hu at mediatek.com>");
+MODULE_DESCRIPTION("PARADE ps8640 DSI-eDP converter driver");
+MODULE_LICENSE("GPL v2");
-- 
1.7.9.5



From michael.hennerich at analog.com  Mon Feb 22 23:49:21 2016
From: michael.hennerich at analog.com (Michael Hennerich)
Date: Tue, 23 Feb 2016 08:49:21 +0100
Subject: [PATCH 07/61] gpio: adp5588: Use devm_gpiochip_add_data() for
 gpio registration
In-Reply-To: <1456150130-2668-8-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
 <1456150130-2668-8-git-send-email-ldewangan@nvidia.com>
Message-ID: <56CC0F01.1000006@analog.com>

On 02/22/2016 03:07 PM, Laxman Dewangan wrote:
> Use devm_gpiochip_add_data() for GPIO registration and remove the
> call for gpiochip_remove() from remove callback.
>
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>

Acked-by: Michael Hennerich <michael.hennerich at analog.com>

> Cc: Michael Hennerich <michael.hennerich at analog.com>
> ---
>   drivers/gpio/gpio-adp5588.c | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpio/gpio-adp5588.c b/drivers/gpio/gpio-adp5588.c
> index 19a0eba..c0f718b 100644
> --- a/drivers/gpio/gpio-adp5588.c
> +++ b/drivers/gpio/gpio-adp5588.c
> @@ -414,7 +414,7 @@ static int adp5588_gpio_probe(struct i2c_client *client,
>   		}
>   	}
>
> -	ret = gpiochip_add_data(&dev->gpio_chip, dev);
> +	ret = devm_gpiochip_add_data(&client->dev, &dev->gpio_chip, dev);
>   	if (ret)
>   		goto err_irq;
>
> @@ -457,8 +457,6 @@ static int adp5588_gpio_remove(struct i2c_client *client)
>   	if (dev->irq_base)
>   		free_irq(dev->client->irq, dev);
>
> -	gpiochip_remove(&dev->gpio_chip);
> -
>   	return 0;
>   }
>
>


-- 
Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif


From ard.biesheuvel at linaro.org  Mon Feb 22 23:56:45 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 23 Feb 2016 08:56:45 +0100
Subject: [PATCH] arm64: move brk immediate argument definitions to separate
 header
Message-ID: <1456214205-18743-1-git-send-email-ard.biesheuvel@linaro.org>

Instead of reversing the header dependency between asm/bug.h and
asm/debug-monitors.h, split off the brk instruction immediate value
defines into a new header asm/brk-imm.h, and include it from both.

This solves the circular dependency issue that prevents BUG() from
being used in some header files, and keeps the definitions together.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/brk-imm.h        | 25 +++++++++++++++++++++++++
 arch/arm64/include/asm/bug.h            |  2 +-
 arch/arm64/include/asm/debug-monitors.h | 14 +-------------
 3 files changed, 27 insertions(+), 14 deletions(-)
 create mode 100644 arch/arm64/include/asm/brk-imm.h

diff --git a/arch/arm64/include/asm/brk-imm.h b/arch/arm64/include/asm/brk-imm.h
new file mode 100644
index 000000000000..ed693c5bcec0
--- /dev/null
+++ b/arch/arm64/include/asm/brk-imm.h
@@ -0,0 +1,25 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_BRK_IMM_H
+#define __ASM_BRK_IMM_H
+
+/*
+ * #imm16 values used for BRK instruction generation
+ * Allowed values for kgdb are 0x400 - 0x7ff
+ * 0x100: for triggering a fault on purpose (reserved)
+ * 0x400: for dynamic BRK instruction
+ * 0x401: for compile time BRK instruction
+ * 0x800: kernel-mode BUG() and WARN() traps
+ */
+#define FAULT_BRK_IMM			0x100
+#define KGDB_DYN_DBG_BRK_IMM		0x400
+#define KGDB_COMPILED_DBG_BRK_IMM	0x401
+#define BUG_BRK_IMM			0x800
+
+#endif
diff --git a/arch/arm64/include/asm/bug.h b/arch/arm64/include/asm/bug.h
index 679d49221998..561190d15881 100644
--- a/arch/arm64/include/asm/bug.h
+++ b/arch/arm64/include/asm/bug.h
@@ -18,7 +18,7 @@
 #ifndef _ARCH_ARM64_ASM_BUG_H
 #define _ARCH_ARM64_ASM_BUG_H
 
-#define BUG_BRK_IMM			0x800
+#include <asm/brk-imm.h>
 
 #ifdef CONFIG_GENERIC_BUG
 #define HAVE_ARCH_BUG
diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
index e893a1fca9c2..2fcb9b7c876c 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -20,7 +20,7 @@
 
 #include <linux/errno.h>
 #include <linux/types.h>
-#include <asm/bug.h>
+#include <asm/brk-imm.h>
 #include <asm/esr.h>
 #include <asm/insn.h>
 #include <asm/ptrace.h>
@@ -48,18 +48,6 @@
 #define BREAK_INSTR_SIZE		AARCH64_INSN_SIZE
 
 /*
- * #imm16 values used for BRK instruction generation
- * Allowed values for kgbd are 0x400 - 0x7ff
- * 0x100: for triggering a fault on purpose (reserved)
- * 0x400: for dynamic BRK instruction
- * 0x401: for compile time BRK instruction
- * 0x800: kernel-mode BUG() and WARN() traps
- */
-#define FAULT_BRK_IMM			0x100
-#define KGDB_DYN_DBG_BRK_IMM		0x400
-#define KGDB_COMPILED_DBG_BRK_IMM	0x401
-
-/*
  * BRK instruction encoding
  * The #imm16 value should be placed at bits[20:5] within BRK ins
  */
-- 
2.5.0



From michael.hennerich at analog.com  Mon Feb 22 23:49:47 2016
From: michael.hennerich at analog.com (Michael Hennerich)
Date: Tue, 23 Feb 2016 08:49:47 +0100
Subject: [PATCH 06/61] gpio: adp5520: Use devm_gpiochip_add_data() for
 gpio registration
In-Reply-To: <1456150130-2668-7-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
 <1456150130-2668-7-git-send-email-ldewangan@nvidia.com>
Message-ID: <56CC0F1B.9040003@analog.com>

On 02/22/2016 03:07 PM, Laxman Dewangan wrote:
> Use devm_gpiochip_add_data() for GPIO registration and remove the
> call for gpiochip_remove() from error path.
>
> Also remove the need of driver callback .remove.
>
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>

Acked-by: Michael Hennerich <michael.hennerich at analog.com>

> Cc: Michael Hennerich <michael.hennerich at analog.com>
> ---
>   drivers/gpio/gpio-adp5520.c | 13 +------------
>   1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/gpio/gpio-adp5520.c b/drivers/gpio/gpio-adp5520.c
> index 4fa7ff1..abf1996 100644
> --- a/drivers/gpio/gpio-adp5520.c
> +++ b/drivers/gpio/gpio-adp5520.c
> @@ -153,7 +153,7 @@ static int adp5520_gpio_probe(struct platform_device *pdev)
>   		goto err;
>   	}
>
> -	ret = gpiochip_add_data(&dev->gpio_chip, dev);
> +	ret = devm_gpiochip_add_data(&pdev->dev, &dev->gpio_chip, dev);
>   	if (ret)
>   		goto err;
>
> @@ -164,22 +164,11 @@ err:
>   	return ret;
>   }
>
> -static int adp5520_gpio_remove(struct platform_device *pdev)
> -{
> -	struct adp5520_gpio *dev;
> -
> -	dev = platform_get_drvdata(pdev);
> -	gpiochip_remove(&dev->gpio_chip);
> -
> -	return 0;
> -}
> -
>   static struct platform_driver adp5520_gpio_driver = {
>   	.driver	= {
>   		.name	= "adp5520-gpio",
>   	},
>   	.probe		= adp5520_gpio_probe,
> -	.remove		= adp5520_gpio_remove,
>   };
>
>   module_platform_driver(adp5520_gpio_driver);
>


-- 
Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif


From zhangqing at rock-chips.com  Mon Feb 22 23:58:42 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Tue, 23 Feb 2016 15:58:42 +0800
Subject: [PATCH] clk: rockchip: rk3368: fix section mismatches with new
 child-clocks
Message-ID: <1456214322-20161-1-git-send-email-zhangqing@rock-chips.com>

To model the muxes downstream of fractional dividers we introduced the
child property, allowing to describe a direct child clock.
The first implementation seems to cause section warnings, as the core
clock-tree is marked as initdata while the data pointed to from the
child element is not.

While there may be some way to also set that missing property in the
inline notation I didn't find it, so to actually fix the issue for now
move the sub-definitions into separate declarations that can have
their own __initdata properties.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 drivers/clk/rockchip/clk-rk3368.c | 97 ++++++++++++++++++++++++---------------
 1 file changed, 60 insertions(+), 37 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3368.c b/drivers/clk/rockchip/clk-rk3368.c
index c2b0421..a2bb122 100644
--- a/drivers/clk/rockchip/clk-rk3368.c
+++ b/drivers/clk/rockchip/clk-rk3368.c
@@ -243,6 +243,34 @@ static struct rockchip_cpuclk_rate_table rk3368_cpuclkl_rates[] __initdata = {
 	RK3368_CPUCLKL_RATE( 312000000, 1, 1, 1),
 };
 
+static struct rockchip_clk_branch rk3368_i2s_8ch_fracmux __initdata =
+	MUX(0, "i2s_8ch_pre", mux_i2s_8ch_pre_p, CLK_SET_RATE_PARENT,
+	    RK3368_CLKSEL_CON(27), 8, 2, MFLAGS);
+
+static struct rockchip_clk_branch rk3368_spdif_8ch_fracmux __initdata =
+	MUX(0, "spdif_8ch_pre", mux_spdif_8ch_p, CLK_SET_RATE_PARENT,
+	    RK3368_CLKSEL_CON(31), 8, 2, MFLAGS);
+
+static struct rockchip_clk_branch rk3368_i2s_2ch_fracmux __initdata =
+	MUX(0, "i2s_2ch_pre", mux_i2s_2ch_p, CLK_SET_RATE_PARENT,
+	    RK3368_CLKSEL_CON(53), 8, 2, MFLAGS);
+
+static struct rockchip_clk_branch rk3368_uart0_fracmux __initdata =
+	MUX(SCLK_UART0, "sclk_uart0", mux_uart0_p, CLK_SET_RATE_PARENT,
+	    RK3368_CLKSEL_CON(33), 8, 2, MFLAGS);
+
+static struct rockchip_clk_branch rk3368_uart1_fracmux __initdata =
+	MUX(SCLK_UART1, "sclk_uart1", mux_uart1_p, CLK_SET_RATE_PARENT,
+	    RK3368_CLKSEL_CON(35), 8, 2, MFLAGS);
+
+static struct rockchip_clk_branch rk3368_uart3_fracmux __initdata =
+	MUX(SCLK_UART3, "sclk_uart3", mux_uart3_p, CLK_SET_RATE_PARENT,
+	    RK3368_CLKSEL_CON(39), 8, 2, MFLAGS);
+
+static struct rockchip_clk_branch rk3368_uart4_fracmux __initdata =
+	MUX(SCLK_UART4, "sclk_uart4", mux_uart4_p, CLK_SET_RATE_PARENT,
+	    RK3368_CLKSEL_CON(41), 8, 2, MFLAGS);
+
 static struct rockchip_clk_branch rk3368_clk_branches[] __initdata = {
 	/*
 	 * Clock-Architecture Diagram 2
@@ -339,11 +367,10 @@ static struct rockchip_clk_branch rk3368_clk_branches[] __initdata = {
 	COMPOSITE(0, "i2s_8ch_src", mux_pll_src_cpll_gpll_p, 0,
 			RK3368_CLKSEL_CON(27), 12, 1, MFLAGS, 0, 7, DFLAGS,
 			RK3368_CLKGATE_CON(6), 1, GFLAGS),
-	COMPOSITE_FRAC(0, "i2s_8ch_frac", "i2s_8ch_src", CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(28), 0,
-			RK3368_CLKGATE_CON(6), 2, GFLAGS),
-	MUX(0, "i2s_8ch_pre", mux_i2s_8ch_pre_p, CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(27), 8, 2, MFLAGS),
+	COMPOSITE_FRACMUX(0, "i2s_8ch_frac", "i2s_8ch_src", CLK_SET_RATE_PARENT,
+			  RK3368_CLKSEL_CON(28), 0,
+			  RK3368_CLKGATE_CON(6), 2, GFLAGS,
+			  &rk3368_i2s_8ch_fracmux),
 	COMPOSITE_NODIV(SCLK_I2S_8CH_OUT, "i2s_8ch_clkout", mux_i2s_8ch_clkout_p, 0,
 			RK3368_CLKSEL_CON(27), 15, 1, MFLAGS,
 			RK3368_CLKGATE_CON(6), 0, GFLAGS),
@@ -352,21 +379,21 @@ static struct rockchip_clk_branch rk3368_clk_branches[] __initdata = {
 	COMPOSITE(0, "spdif_8ch_src", mux_pll_src_cpll_gpll_p, 0,
 			RK3368_CLKSEL_CON(31), 12, 1, MFLAGS, 0, 7, DFLAGS,
 			RK3368_CLKGATE_CON(6), 4, GFLAGS),
-	COMPOSITE_FRAC(0, "spdif_8ch_frac", "spdif_8ch_src", CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(32), 0,
-			RK3368_CLKGATE_CON(6), 5, GFLAGS),
-	COMPOSITE_NODIV(SCLK_SPDIF_8CH, "sclk_spdif_8ch", mux_spdif_8ch_p, CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(31), 8, 2, MFLAGS,
-			RK3368_CLKGATE_CON(6), 6, GFLAGS),
+	COMPOSITE_FRACMUX(0, "spdif_8ch_frac", "spdif_8ch_src", CLK_SET_RATE_PARENT,
+			  RK3368_CLKSEL_CON(32), 0,
+			  RK3368_CLKGATE_CON(6), 5, GFLAGS,
+			  &rk3368_spdif_8ch_fracmux),
+	GATE(SCLK_SPDIF_8CH, "sclk_spdif_8ch", "spdif_8ch_pre", CLK_SET_RATE_PARENT,
+	     RK3368_CLKGATE_CON(6), 6, GFLAGS),
 	COMPOSITE(0, "i2s_2ch_src", mux_pll_src_cpll_gpll_p, 0,
 			RK3368_CLKSEL_CON(53), 12, 1, MFLAGS, 0, 7, DFLAGS,
 			RK3368_CLKGATE_CON(5), 13, GFLAGS),
-	COMPOSITE_FRAC(0, "i2s_2ch_frac", "i2s_2ch_src", CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(54), 0,
-			RK3368_CLKGATE_CON(5), 14, GFLAGS),
-	COMPOSITE_NODIV(SCLK_I2S_2CH, "sclk_i2s_2ch", mux_i2s_2ch_p, CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(53), 8, 2, MFLAGS,
-			RK3368_CLKGATE_CON(5), 15, GFLAGS),
+	COMPOSITE_FRACMUX(0, "i2s_2ch_frac", "i2s_2ch_src", CLK_SET_RATE_PARENT,
+			  RK3368_CLKSEL_CON(54), 0,
+			  RK3368_CLKGATE_CON(5), 14, GFLAGS,
+			  &rk3368_i2s_2ch_fracmux),
+	GATE(SCLK_I2S_2CH, "sclk_i2s_2ch", "i2s_2ch_pre", CLK_SET_RATE_PARENT,
+	     RK3368_CLKGATE_CON(5), 15, GFLAGS),
 
 	COMPOSITE(0, "sclk_tsp", mux_pll_src_cpll_gpll_npll_p, 0,
 			RK3368_CLKSEL_CON(46), 6, 2, MFLAGS, 0, 5, DFLAGS,
@@ -562,38 +589,34 @@ static struct rockchip_clk_branch rk3368_clk_branches[] __initdata = {
 	COMPOSITE(0, "uart0_src", mux_pll_src_cpll_gpll_usb_usb_p, 0,
 			RK3368_CLKSEL_CON(33), 12, 2, MFLAGS, 0, 7, DFLAGS,
 			RK3368_CLKGATE_CON(2), 0, GFLAGS),
-	COMPOSITE_FRAC(0, "uart0_frac", "uart0_src", CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(34), 0,
-			RK3368_CLKGATE_CON(2), 1, GFLAGS),
-	MUX(SCLK_UART0, "sclk_uart0", mux_uart0_p, CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(33), 8, 2, MFLAGS),
+	COMPOSITE_FRACMUX(0, "uart0_frac", "uart0_src", CLK_SET_RATE_PARENT,
+			  RK3368_CLKSEL_CON(34), 0,
+			  RK3368_CLKGATE_CON(2), 1, GFLAGS,
+			  &rk3368_uart0_fracmux),
 
 	COMPOSITE_NOMUX(0, "uart1_src", "uart_src", 0,
 			RK3368_CLKSEL_CON(35), 0, 7, DFLAGS,
 			RK3368_CLKGATE_CON(2), 2, GFLAGS),
-	COMPOSITE_FRAC(0, "uart1_frac", "uart1_src", CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(36), 0,
-			RK3368_CLKGATE_CON(2), 3, GFLAGS),
-	MUX(SCLK_UART1, "sclk_uart1", mux_uart1_p, CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(35), 8, 2, MFLAGS),
+	COMPOSITE_FRACMUX(0, "uart1_frac", "uart1_src", CLK_SET_RATE_PARENT,
+			  RK3368_CLKSEL_CON(36), 0,
+			  RK3368_CLKGATE_CON(2), 3, GFLAGS,
+			  &rk3368_uart1_fracmux),
 
 	COMPOSITE_NOMUX(0, "uart3_src", "uart_src", 0,
 			RK3368_CLKSEL_CON(39), 0, 7, DFLAGS,
 			RK3368_CLKGATE_CON(2), 6, GFLAGS),
-	COMPOSITE_FRAC(0, "uart3_frac", "uart3_src", CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(40), 0,
-			RK3368_CLKGATE_CON(2), 7, GFLAGS),
-	MUX(SCLK_UART3, "sclk_uart3", mux_uart3_p, CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(39), 8, 2, MFLAGS),
+	COMPOSITE_FRACMUX(0, "uart3_frac", "uart3_src", CLK_SET_RATE_PARENT,
+			  RK3368_CLKSEL_CON(40), 0,
+			  RK3368_CLKGATE_CON(2), 7, GFLAGS,
+			  &rk3368_uart3_fracmux),
 
 	COMPOSITE_NOMUX(0, "uart4_src", "uart_src", 0,
 			RK3368_CLKSEL_CON(41), 0, 7, DFLAGS,
 			RK3368_CLKGATE_CON(2), 8, GFLAGS),
-	COMPOSITE_FRAC(0, "uart4_frac", "uart4_src", CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(42), 0,
-			RK3368_CLKGATE_CON(2), 9, GFLAGS),
-	MUX(SCLK_UART4, "sclk_uart4", mux_uart4_p, CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(41), 8, 2, MFLAGS),
+	COMPOSITE_FRACMUX(0, "uart4_frac", "uart4_src", CLK_SET_RATE_PARENT,
+			  RK3368_CLKSEL_CON(42), 0,
+			  RK3368_CLKGATE_CON(2), 9, GFLAGS,
+			  &rk3368_uart4_fracmux),
 
 	COMPOSITE(0, "mac_pll_src", mux_pll_src_npll_cpll_gpll_p, 0,
 			RK3368_CLKSEL_CON(43), 6, 2, MFLAGS, 0, 5, DFLAGS,
-- 
1.9.1




From linux.amoon at gmail.com  Tue Feb 23 00:01:07 2016
From: linux.amoon at gmail.com (Anand Moon)
Date: Tue, 23 Feb 2016 08:01:07 +0000
Subject: [PATCH] ARM: dts: add support for gpio buttons for
 exynos5422-odroidxu3
Message-ID: <1456214467-3344-1-git-send-email-linux.amoon@gmail.com>

Add support for gpio-based button on Odroid-XU3 boards
for reboot/poweroff feature.

Signed-off-by: Anand Moon <linux.amoon at gmail.com>
---
changes rebase based on linux next-20160222.

Tested on Odroid-XU4

dmesg output.
[    3.286068] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio_keys/power_key[0]' - status (0)
[    3.286206] gpio-11 (power key): gpiod_set_debounce: missing set() or set_debounce() operations
[    3.286600] input: gpio_keys as /devices/platform/gpio_keys/input/input0
---
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 1bd507b..db9770b 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -11,6 +11,7 @@
 */
 
 #include <dt-bindings/clock/samsung,s2mps11.h>
+#include <dt-bindings/input/input.h>
 #include <dt-bindings/interrupt-controller/irq.h>
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/sound/samsung-i2s.h>
@@ -54,6 +55,22 @@
 		#cooling-cells = <2>;
 		cooling-levels = <0 130 170 230>;
 	};
+
+	gpio_keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&gpio_power_key>;
+
+		power_key {
+			interrupt-parent = <&gpx0>;
+			interrupts = <3 IRQ_TYPE_NONE>;
+			gpios = <&gpx0 3 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_POWER>;
+			label = "power key";
+			debounce-interval = <10>;
+			wakeup-source;
+		};
+	};
 };
 
 &clock_audss {
@@ -362,6 +379,11 @@
 };
 
 &pinctrl_0 {
+	gpio_power_key: power_key {
+		samsung,pins = "gpx0-3";
+		samsung,pin-pud = <0>;
+	};
+
 	hdmi_hpd_irq: hdmi-hpd-irq {
 		samsung,pins = "gpx3-7";
 		samsung,pin-function = <0>;
-- 
2.1.4



From tiffany.lin at mediatek.com  Tue Feb 23 00:11:21 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Tue, 23 Feb 2016 16:11:21 +0800
Subject: [PATCH v5 8/8] arm64: dts: mediatek: Add Video Encoder for MT8173
In-Reply-To: <1456215081-16858-8-git-send-email-tiffany.lin@mediatek.com>
References: <1456215081-16858-1-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-2-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-3-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-4-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-5-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-6-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-7-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-8-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <1456215081-16858-9-git-send-email-tiffany.lin@mediatek.com>

Add video encoder node for MT8173

Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   39 ++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 5b0b38a..26aeffe 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -1150,6 +1150,45 @@
 			clock-names = "apb", "smi";
 		};
 
+		vcodec_enc: vcodec at 18002000 {
+			compatible = "mediatek,mt8173-vcodec-enc";
+			reg = <0 0x18002000 0 0x1000>,	/* VENC_SYS */
+			      <0 0x19002000 0 0x1000>;	/* VENC_LT_SYS */
+			interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>,
+				     <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>;
+			mediatek,larb = <&larb3>,
+					<&larb5>;
+			iommus = <&iommu M4U_PORT_VENC_RCPU>,
+				 <&iommu M4U_PORT_VENC_REC>,
+				 <&iommu M4U_PORT_VENC_BSDMA>,
+				 <&iommu M4U_PORT_VENC_SV_COMV>,
+				 <&iommu M4U_PORT_VENC_RD_COMV>,
+				 <&iommu M4U_PORT_VENC_CUR_LUMA>,
+				 <&iommu M4U_PORT_VENC_CUR_CHROMA>,
+				 <&iommu M4U_PORT_VENC_REF_LUMA>,
+				 <&iommu M4U_PORT_VENC_REF_CHROMA>,
+				 <&iommu M4U_PORT_VENC_NBM_RDMA>,
+				 <&iommu M4U_PORT_VENC_NBM_WDMA>,
+				 <&iommu M4U_PORT_VENC_RCPU_SET2>,
+				 <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
+				 <&iommu M4U_PORT_VENC_BSDMA_SET2>,
+				 <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
+				 <&iommu M4U_PORT_VENC_RD_COMA_SET2>,
+				 <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
+				 <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
+				 <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
+				 <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
+			mediatek,vpu = <&vpu>;
+			clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
+				 <&topckgen CLK_TOP_VENC_SEL>,
+				 <&topckgen CLK_TOP_UNIVPLL1_D2>,
+				 <&topckgen CLK_TOP_VENC_LT_SEL>;
+			clock-names = "venc_sel_src",
+				      "venc_sel",
+				      "venc_lt_sel_src",
+				      "venc_lt_sel";
+		};
+
 		vencltsys: clock-controller at 19000000 {
 			compatible = "mediatek,mt8173-vencltsys", "syscon";
 			reg = <0 0x19000000 0 0x1000>;
-- 
1.7.9.5



From tiffany.lin at mediatek.com  Tue Feb 23 00:11:14 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Tue, 23 Feb 2016 16:11:14 +0800
Subject: [PATCH v5 1/8] dt-bindings: Add a binding for Mediatek Video Processor
In-Reply-To: <1456215081-16858-1-git-send-email-tiffany.lin@mediatek.com>
References: <1456215081-16858-1-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <1456215081-16858-2-git-send-email-tiffany.lin@mediatek.com>

From: Andrew-CT Chen <andrew-ct.chen at mediatek.com>

Add a DT binding documentation of Video Processor Unit for the
MT8173 SoC from Mediatek.

Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/media/mediatek-vpu.txt     |   31 ++++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-vpu.txt b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
new file mode 100644
index 0000000..2a5bac3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
@@ -0,0 +1,31 @@
+* Mediatek Video Processor Unit
+
+Video Processor Unit is a HW video controller. It controls HW Codec including
+H.264/VP8/VP9 Decode, H.264/VP8 Encode and Image Processor (scale/rotate/color convert).
+
+Required properties:
+  - compatible: "mediatek,mt8173-vpu"
+  - reg: Must contain an entry for each entry in reg-names.
+  - reg-names: Must include the following entries:
+    "tcm": tcm base
+    "cfg_reg": Main configuration registers base
+  - interrupts: interrupt number to the cpu.
+  - clocks : clock name from clock manager
+  - clock-names: must be main. It is the main clock of VPU
+
+Optional properties:
+  - memory-region: phandle to a node describing memory (see
+    Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
+    to be used for VPU extended memory; if not present, VPU may be located
+    anywhere in the memory
+
+Example:
+	vpu: vpu at 10020000 {
+		compatible = "mediatek,mt8173-vpu";
+		reg = <0 0x10020000 0 0x30000>,
+		      <0 0x10050000 0 0x100>;
+		reg-names = "tcm", "cfg_reg";
+		interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&topckgen TOP_SCP_SEL>;
+		clock-names = "main";
+	};
-- 
1.7.9.5



From tiffany.lin at mediatek.com  Tue Feb 23 00:11:16 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Tue, 23 Feb 2016 16:11:16 +0800
Subject: [PATCH v5 3/8] arm64: dts: mediatek: Add node for Mediatek Video
 Processor Unit
In-Reply-To: <1456215081-16858-3-git-send-email-tiffany.lin@mediatek.com>
References: <1456215081-16858-1-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-2-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-3-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <1456215081-16858-4-git-send-email-tiffany.lin@mediatek.com>

From: Andrew-CT Chen <andrew-ct.chen at mediatek.com>

Add VPU drivers for MT8173

Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 60a1284..5b0b38a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -200,6 +200,18 @@
 		clock-output-names = "cpum_ck";
 	};
 
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		vpu_dma_reserved: vpu_dma_mem_region {
+			compatible = "shared-dma-pool";
+			reg = <0 0xb7000000 0 0x500000>;
+			alignment = <0x1000>;
+			no-map;
+		};
+	};
+
 	thermal-zones {
 		cpu_thermal: cpu_thermal {
 			polling-delay-passive = <1000>; /* milliseconds */
@@ -422,6 +434,17 @@
 			clocks = <&infracfg CLK_INFRA_CEC>;
 		};
 
+		vpu: vpu at 10020000 {
+			compatible = "mediatek,mt8173-vpu";
+			reg = <0 0x10020000 0 0x30000>,
+			      <0 0x10050000 0 0x100>;
+			reg-names = "tcm", "cfg_reg";
+			interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&topckgen CLK_TOP_SCP_SEL>;
+			clock-names = "main";
+			memory-region = <&vpu_dma_reserved>;
+		};
+
 		sysirq: intpol-controller at 10200620 {
 			compatible = "mediatek,mt8173-sysirq",
 				     "mediatek,mt6577-sysirq";
-- 
1.7.9.5



From tiffany.lin at mediatek.com  Tue Feb 23 00:11:13 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Tue, 23 Feb 2016 16:11:13 +0800
Subject: [PATCH v5 0/8] Add MT8173 Video Encoder Driver and VPU Driver
Message-ID: <1456215081-16858-1-git-send-email-tiffany.lin@mediatek.com>

==============
 Introduction
==============

The purpose of this series is to add the driver for video codec hw embedded in the Mediatek's MT8173 SoCs.
Mediatek Video Codec is able to handle video encoding of in a range of formats.

This patch series also include VPU driver. Mediatek Video Codec driver rely on VPU driver to load,
communicate with VPU.

Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI.
MTK IOMMU[1] and MTK SMI[2] have not yet been merged, but we wanted to start discussion about the driver
earlier so it could be merged sooner.

[1]https://patchwork.kernel.org/patch/8335461/
[2]https://patchwork.kernel.org/patch/7596181/

==================
 Device interface
==================

In principle the driver bases on v4l2 memory-to-memory framework:
it provides a single video node and each opened file handle gets its own private context with separate
buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source buffers, i.e. raw video
frames) and CAPTURE (for destination buffers, i.e. encoded video frames).

==============================
 VPU (Video Processor Unit)
==============================
The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
It is able to handle video decoding/encoding in a range of formats.
The driver provides with VPU firmware download, memory management and the communication interface
between CPU and VPU.
For VPU initialization, it will create virtual memory for CPU access and physical address for VPU hw device
access. When a decode/encode instance opens a device node, vpu driver will download vpu firmware to the device.
A decode/encode instant will decode/encode a frame using VPU interface to interrupt vpu to handle
decoding/encoding jobs.

Please have a look at the code and comments will be very much appreciated.
Change in v5:
Vcodec Part
1. Pass checkpatch and v4l2-compliance test
2. Remove unused g/s_selection for now
3. add vidioc_g_parm support
4. add vidioc_create_bufs and vidioc_prepare_buf support
5. Remove instance limitation check in fops_vcodec_open
6. Fix comments for data structure and code
7. Refine venc, venc_lt clock source name in devicetree and binding document
8. Fix Author information and copyright information
9. Refine code according to review comments

VPU Part
1. Modify mtk-vpu driver description
2. Remove unavailable watchdog reset id
3. Modify VPU clock function for watchdog

H264/VP8 driver part
1.code refined about redundant and structrue comments
2.code refined about redundant and add structrue comments

v4l2-compliance test output:
localhost ~ # /usr/bin/v4l2-compliance -d /dev/video1
Driver Info:
        Driver name   : mtk-vcodec-enc
        Card type     : platform:mt8173
        Bus info      : platform:mt8173
        Driver version: 4.4.0
        Capabilities  : 0x84204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps   : 0x04204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format

Compliance test for device /dev/video1 (not using libv4l2):

Required ioctls:
        test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
        test second video open: OK
        test VIDIOC_QUERYCAP: OK
        test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
        test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
        test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
        test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
        test VIDIOC_ENUMAUDIO: OK (Not Supported)
        test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDIO: OK (Not Supported)
        Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
        test VIDIOC_G/S_MODULATOR: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_ENUMAUDOUT: OK (Not Supported)
        test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDOUT: OK (Not Supported)
        Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
        test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
        test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
        test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
        test VIDIOC_G/S_EDID: OK (Not Supported)

        Control ioctls:
                test VIDIOC_QUERYCTRL/MENU: OK
                test VIDIOC_G/S_CTRL: OK
                test VIDIOC_G/S/TRY_EXT_CTRLS: OK
                test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
                test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
                Standard Controls: 12 Private Controls: 0

        Format ioctls:
                test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
                test VIDIOC_G/S_PARM: OK
                test VIDIOC_G_FBUF: OK (Not Supported)
                test VIDIOC_G_FMT: OK
                test VIDIOC_TRY_FMT: OK
                test VIDIOC_S_FMT: OK
                test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)

        Codec ioctls:
                test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
                test VIDIOC_G_ENC_INDEX: OK (Not Supported)
                test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

        Buffer ioctls:
                test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
                test VIDIOC_EXPBUF: OK

Total: 38, Succeeded: 38, Failed: 0, Warnings: 0

Change in v4:
Vcodec Part
1. Remove MTK_ENCODE_PARAM_SKIP_FRAME support
2. Remove MTK_ENCODE_PARAM_FRAME_TYPE and change to use V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME[3]
3. Refine Encoder HW clock source
4. Refine debug log
5. Add watchdog support
6. With patch "media: v4l2-compat-ioctl32: fix missing length copy in put_v4l2_buffer32"[4],
v4l2-compliance test passed[5] in v4.4-rc5 

VPU Part
1. These two patches were Acked-by: Rob Herring <robh <at> kernel.org> in v3
   [PATCH v3 1/8] dt-bindings: Add a binding for Mediatek Video Processor
   [PATCH v3 3/8] arm64: dts: mediatek: Add node for Mediatek Video Processor Unit
   Because we were wrong about how the hardware works, there is no connection between VPU and IOMMU HW
   We remove VPU attaching to IOMMU
2. Support VPU running on 4GB DRAM system
3. Support VPU watchdog reset
4. Refine for coding style 

[3]https://patchwork.linuxtv.org/patch/32670/
[4] https://patchwork.linuxtv.org/patch/32631/
[5]localhost ~ # /usr/bin/v4l2-compliance -d /dev/video1
Driver Info:
        Driver name   : mtk-vcodec-en
        Card type     : platform:mt817
        Bus info      : platform:mt817
        Driver version: 4.4.0
        Capabilities  : 0x84204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps   : 0x04204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format

Compliance test for device /dev/video1 (not using libv4l2):

Required ioctls:
        test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
        test second video open: OK
        test VIDIOC_QUERYCAP: OK
        test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
        test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
        test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
        test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
        test VIDIOC_ENUMAUDIO: OK (Not Supported)
        test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDIO: OK (Not Supported)
        Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
        test VIDIOC_G/S_MODULATOR: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_ENUMAUDOUT: OK (Not Supported)
        test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDOUT: OK (Not Supported)
        Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
        test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
        test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
        test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
        test VIDIOC_G/S_EDID: OK (Not Supported)

        Control ioctls:
                test VIDIOC_QUERYCTRL/MENU: OK
                test VIDIOC_G/S_CTRL: OK
                test VIDIOC_G/S/TRY_EXT_CTRLS: OK
                test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
                test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
                Standard Controls: 12 Private Controls: 0

        Format ioctls:
                test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
                test VIDIOC_G/S_PARM: OK (Not Supported)
                test VIDIOC_G_FBUF: OK (Not Supported)
                test VIDIOC_G_FMT: OK
                test VIDIOC_TRY_FMT: OK
                test VIDIOC_S_FMT: OK
                test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)

        Codec ioctls:
                test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
                test VIDIOC_G_ENC_INDEX: OK (Not Supported)
                test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

        Buffer ioctls:
                warn: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(475):
VIDIOC_CREATE_BUFS not supported
                warn: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(475):
VIDIOC_CREATE_BUFS not supported
                test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
                test VIDIOC_EXPBUF: OK

Total: 38, Succeeded: 38, Failed: 0, Warnings: 2

Change in v3:
1.Refine code to pass v4l2-compliance test, now it still has 2 issues 2.Refine code according to latest MTK
IOMMU patches[1] 3.Remove MFC51 specific CIDs and add MTK specific CIDs for for keyframe and
  skip I-frame
4.Refine code according to review comments

Below is the v1.6 version v4l2-compliance report for the mt8173 encoder driver.
Now there are still 2 test fail in v1.6.
For VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF, we directly use v4l2_m2m_ioctl_* functions, but it still
fail. It pass in kernel 3.18 but fail in kernel 4.4.
We will try v1.8 in next version.
VIDIOC_EXPBUF is becuase we support all three memory types VB2_DMABUF, VB2_MMAP and VB2_USERPTR.
VIDIOC_EXPBUF only allowed when only VB2_MMAP supported.
localhost ~ # /usr/bin/v4l2-compliance -d /dev/video1 Driver Info:
        Driver name   : mtk-vcodec-en
        Card type     : platform:mt817
        Bus info      : platform:mt817
        Driver version: 4.4.0
        Capabilities  : 0x84204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format
                Device Capabilities
        Device Caps   : 0x04204000
                Video Memory-to-Memory Multiplanar
                Streaming
                Extended Pix Format

Compliance test for device /dev/video1 (not using libv4l2):

Required ioctls:
        test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
        test second video open: OK
        test VIDIOC_QUERYCAP: OK
        test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
        test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
        test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
        test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
        test VIDIOC_ENUMAUDIO: OK (Not Supported)
        test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDIO: OK (Not Supported)
        Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
        test VIDIOC_G/S_MODULATOR: OK (Not Supported)
        test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
        test VIDIOC_ENUMAUDOUT: OK (Not Supported)
        test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
        test VIDIOC_G/S_AUDOUT: OK (Not Supported)
        Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
        test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
        test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
        test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
        test VIDIOC_G/S_EDID: OK (Not Supported)

        Control ioctls:
                test VIDIOC_QUERYCTRL/MENU: OK
                test VIDIOC_G/S_CTRL: OK
                test VIDIOC_G/S/TRY_EXT_CTRLS: OK
                test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
                test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
                Standard Controls: 11 Private Controls: 2

        Format ioctls:
                test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
                test VIDIOC_G/S_PARM: OK (Not Supported)
                test VIDIOC_G_FBUF: OK (Not Supported)
                test VIDIOC_G_FMT: OK
                test VIDIOC_TRY_FMT: OK
                test VIDIOC_S_FMT: OK
                test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)

        Codec ioctls:
                test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
                test VIDIOC_G_ENC_INDEX: OK (Not Supported)
                test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

        Buffer ioctls:
                fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(266): vp->length
== 0
                fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(335):
buf.check(Unqueued, i)
                fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(420):
testQueryBuf(node, i, q.g_buffers())
                test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
                fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(500): q.has_expbuf(node)
                test VIDIOC_EXPBUF: FAIL
Total: 38, Succeeded: 36, Failed: 2, Warnings: 0

Change in v2:
Vcodec Part
1.Remove common and include directory in mtk-vcodec 2.Refine vb2ops_venc_start_streaming and
vb2ops_venc_stop_streaming and state machine 3.Remove venc_if_init and venc_if_deinit 4.Refine
debug message 5.Refine lab and vpu decription in mediatek-vcodec.txt

VPU Part
1. Modify VPU Kconfig
2. Move encoder header files to other patch sets 3. Remove marcos for extended virtual/iova address 4.
Change register and variable names 5. Add a reference counter for VPU watchdog 6. Remove one busy waiting
in function vpu_ipi_send 7. Operate VPU clock in VPU driver (not called by encoder drivers) 8. Refine
memory mapping, firmware download and extended memory allocation/free functions 9. Release more
allocated resources in driver remove function


Andrew-CT Chen (3):
  dt-bindings: Add a binding for Mediatek Video Processor
  [media] VPU: mediatek: support Mediatek VPU
  arm64: dts: mediatek: Add node for Mediatek Video Processor Unit

PoChun Lin (2):
  [media] vcodec: mediatek: Add Mediatek VP8 Video Encoder Driver
  [media] vcodec: mediatek: Add Mediatek H264 Video Encoder Driver

Tiffany Lin (3):
  dt-bindings: Add a binding for Mediatek Video Encoder
  [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver
  arm64: dts: mediatek: Add Video Encoder for MT8173

 .../devicetree/bindings/media/mediatek-vcodec.txt  |   59 +
 .../devicetree/bindings/media/mediatek-vpu.txt     |   31 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi           |   62 +
 drivers/media/platform/Kconfig                     |   23 +
 drivers/media/platform/Makefile                    |    4 +
 drivers/media/platform/mtk-vcodec/Makefile         |   11 +
 .../media/platform/mtk-vcodec/h264_enc/Makefile    |    6 +
 .../platform/mtk-vcodec/h264_enc/venc_h264_if.c    |  526 +++++++
 .../platform/mtk-vcodec/h264_enc/venc_h264_if.h    |  168 +++
 .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.c   |  309 +++++
 .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.h   |   30 +
 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |  352 +++++
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1430 ++++++++++++++++++++
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h |   47 +
 .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c |  476 +++++++
 .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c  |  132 ++
 .../media/platform/mtk-vcodec/mtk_vcodec_intr.c    |  102 ++
 .../media/platform/mtk-vcodec/mtk_vcodec_intr.h    |   29 +
 drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h  |   26 +
 .../media/platform/mtk-vcodec/mtk_vcodec_util.c    |  106 ++
 .../media/platform/mtk-vcodec/mtk_vcodec_util.h    |   85 ++
 drivers/media/platform/mtk-vcodec/venc_drv_base.h  |   63 +
 drivers/media/platform/mtk-vcodec/venc_drv_if.c    |  108 ++
 drivers/media/platform/mtk-vcodec/venc_drv_if.h    |  177 +++
 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h   |  227 ++++
 drivers/media/platform/mtk-vcodec/vp8_enc/Makefile |    6 +
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_if.c      |  419 ++++++
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_if.h      |  152 +++
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c     |  240 ++++
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h     |   28 +
 drivers/media/platform/mtk-vpu/Makefile            |    1 +
 drivers/media/platform/mtk-vpu/mtk_vpu.c           |  949 +++++++++++++
 drivers/media/platform/mtk-vpu/mtk_vpu.h           |  163 +++
 33 files changed, 6547 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt
 create mode 100644 drivers/media/platform/mtk-vcodec/Makefile
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/Makefile
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/Makefile
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.h
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h
 create mode 100644 drivers/media/platform/mtk-vpu/Makefile
 create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c
 create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h

-- 
1.7.9.5



From tiffany.lin at mediatek.com  Tue Feb 23 00:11:20 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Tue, 23 Feb 2016 16:11:20 +0800
Subject: [PATCH v5 7/8] [media] vcodec: mediatek: Add Mediatek H264 Video
 Encoder Driver
In-Reply-To: <1456215081-16858-7-git-send-email-tiffany.lin@mediatek.com>
References: <1456215081-16858-1-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-2-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-3-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-4-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-5-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-6-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-7-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <1456215081-16858-8-git-send-email-tiffany.lin@mediatek.com>

From: PoChun Lin <pochun.lin at mediatek.com>

Add h264 encoder driver for MT8173

Signed-off-by: pochun.lin <pochun.lin at mediatek.com>
Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
---
 drivers/media/platform/mtk-vcodec/Makefile         |    3 +-
 .../media/platform/mtk-vcodec/h264_enc/Makefile    |    6 +
 .../platform/mtk-vcodec/h264_enc/venc_h264_if.c    |  526 ++++++++++++++++++++
 .../platform/mtk-vcodec/h264_enc/venc_h264_if.h    |  168 +++++++
 .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.c   |  309 ++++++++++++
 .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.h   |   30 ++
 drivers/media/platform/mtk-vcodec/venc_drv_if.c    |    3 +
 7 files changed, 1044 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/Makefile
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
 create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h

diff --git a/drivers/media/platform/mtk-vcodec/Makefile b/drivers/media/platform/mtk-vcodec/Makefile
index f4ef502..f47dfc7 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk_vcodec_intr.o \
 				       mtk_vcodec_enc_pm.o \
 				       venc_drv_if.o
 
-obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += vp8_enc/
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += vp8_enc/ h264_enc/
 
 ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/Makefile b/drivers/media/platform/mtk-vcodec/h264_enc/Makefile
new file mode 100644
index 0000000..765b45f
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/h264_enc/Makefile
@@ -0,0 +1,6 @@
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += venc_h264_if.o venc_h264_vpu.o
+
+ccflags-y += \
+    -I$(srctree)/drivers/media/platform/mtk-vcodec/ \
+    -I$(srctree)/drivers/media/platform/mtk-vcodec/h264_enc \
+    -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
new file mode 100644
index 0000000..6a38576
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
@@ -0,0 +1,526 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
+ *         Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+
+#include "mtk_vcodec_drv.h"
+#include "mtk_vcodec_util.h"
+#include "mtk_vcodec_intr.h"
+#include "mtk_vcodec_enc.h"
+#include "mtk_vcodec_pm.h"
+#include "mtk_vpu.h"
+
+#include "venc_h264_if.h"
+#include "venc_h264_vpu.h"
+
+#define VENC_PIC_BITSTREAM_BYTE_CNT 0x0098
+
+enum venc_h264_irq_status {
+	H264_IRQ_STATUS_ENC_SPS_INT = (1 << 0),
+	H264_IRQ_STATUS_ENC_PPS_INT = (1 << 1),
+	H264_IRQ_STATUS_ENC_FRM_INT = (1 << 2),
+};
+
+static inline void h264_write_reg(struct venc_h264_inst *inst, u32 addr,
+				  u32 val)
+{
+	writel(val, inst->hw_base + addr);
+}
+
+static inline u32 h264_read_reg(struct venc_h264_inst *inst, u32 addr)
+{
+	return readl(inst->hw_base + addr);
+}
+
+static void h264_enc_free_work_buf(struct venc_h264_inst *inst)
+{
+	int i;
+
+	mtk_vcodec_debug_enter(inst);
+
+	/* Except the SKIP_FRAME buffers,
+	 * other buffers need to be freed by AP.
+	 */
+	for (i = 0; i < VENC_H264_VPU_WORK_BUF_MAX; i++) {
+		if (i != VENC_H264_VPU_WORK_BUF_SKIP_FRAME)
+			if (inst->work_bufs[i].va != NULL)
+				mtk_vcodec_mem_free(inst->ctx,
+						    &inst->work_bufs[i]);
+	}
+
+	if (inst->pps_buf.va != NULL)
+		mtk_vcodec_mem_free(inst->ctx, &inst->pps_buf);
+
+	mtk_vcodec_debug_leave(inst);
+}
+
+static int h264_enc_alloc_work_buf(struct venc_h264_inst *inst, void *param)
+{
+	int i;
+	int ret = 0;
+	struct venc_h264_vpu_buf *wb = inst->vpu_inst.drv->work_bufs;
+	struct venc_enc_prm *enc_param = param;
+
+	mtk_vcodec_debug_enter(inst);
+
+	for (i = 0; i < VENC_H264_VPU_WORK_BUF_MAX; i++) {
+		/*
+		 * This 'wb' structure is set by VPU side and shared to AP for
+		 * buffer allocation and IO virtual addr mapping. For most of
+		 * the buffers, AP will allocate the buffer according to 'size'
+		 * field and store the IO virtual addr in 'iova' field. There
+		 * are two exceptions:
+		 * (1) RC_CODE buffer, it's pre-allocated in the VPU side, and
+		 * save the VPU addr in the 'vpua' field. The AP will translate
+		 * the VPU addr to the corresponding IO virtual addr and store
+		 * in 'iova' field for reg setting in VPU side.
+		 * (2) SKIP_FRAME buffer, it's pre-allocated in the VPU side,
+		 * and save the VPU addr in the 'vpua' field. The AP will
+		 * translate the VPU addr to the corresponding AP side virtual
+		 * address and do some memcpy access to move to bitstream buffer
+		 * assigned by v4l2 layer.
+		 */
+		inst->work_bufs[i].size = wb[i].size;
+		if (i == VENC_H264_VPU_WORK_BUF_SKIP_FRAME) {
+			inst->work_bufs[i].va = vpu_mapping_dm_addr(
+				inst->dev, wb[i].vpua);
+			inst->work_bufs[i].dma_addr = 0;
+		} else if (i == VENC_H264_VPU_WORK_BUF_SRC_LUMA ||
+			   i == VENC_H264_VPU_WORK_BUF_SRC_CHROMA ||
+			   i == VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CB ||
+			   i == VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CR) {
+			inst->work_bufs[i].dma_addr = 0;
+			inst->work_bufs[i].va = NULL;
+		} else {
+			if (mtk_vcodec_mem_alloc(inst->ctx,
+						 &inst->work_bufs[i])) {
+				mtk_vcodec_err(inst,
+					       "cannot allocate buf %d", i);
+				ret = -ENOMEM;
+				goto err_alloc;
+			}
+			if (i == VENC_H264_VPU_WORK_BUF_RC_CODE) {
+				void *tmp_va;
+
+				tmp_va = vpu_mapping_dm_addr(inst->dev,
+							     wb[i].vpua);
+				memcpy(inst->work_bufs[i].va, tmp_va,
+				       wb[i].size);
+			}
+		}
+		wb[i].iova = inst->work_bufs[i].dma_addr;
+
+		mtk_vcodec_debug(inst,
+				 "work_buf[%d] va=0x%p iova=0x%p size=0x%lx",
+				 i, inst->work_bufs[i].va,
+				 (void *)inst->work_bufs[i].dma_addr,
+				 inst->work_bufs[i].size);
+	}
+
+	if (enc_param->input_fourcc == VENC_YUV_FORMAT_NV12 ||
+	    enc_param->input_fourcc == VENC_YUV_FORMAT_NV21) {
+		enc_param->sizeimage[0] =
+			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_LUMA].size;
+		enc_param->sizeimage[1] =
+			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_CHROMA].size;
+		enc_param->sizeimage[2] = 0;
+	} else {
+		enc_param->sizeimage[0] =
+			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_LUMA].size;
+		enc_param->sizeimage[1] =
+			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CB].size;
+		enc_param->sizeimage[2] =
+			inst->work_bufs[VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CR].size;
+	}
+
+	/* the pps_buf is used by AP side only */
+	inst->pps_buf.size = 128;
+	if (mtk_vcodec_mem_alloc(inst->ctx,
+				 &inst->pps_buf)) {
+		mtk_vcodec_err(inst, "cannot allocate pps_buf");
+		ret = -ENOMEM;
+		goto err_alloc;
+	}
+	mtk_vcodec_debug_leave(inst);
+
+	return ret;
+
+err_alloc:
+	h264_enc_free_work_buf(inst);
+
+	return ret;
+}
+
+static unsigned int h264_enc_wait_venc_done(struct venc_h264_inst *inst)
+{
+	unsigned int irq_status = 0;
+	struct mtk_vcodec_ctx *ctx = (struct mtk_vcodec_ctx *)inst->ctx;
+
+	mtk_vcodec_wait_for_done_ctx(ctx, MTK_INST_IRQ_RECEIVED,
+				     WAIT_INTR_TIMEOUT, true);
+	irq_status = ctx->irq_status;
+	mtk_vcodec_debug(inst, "irq_status %x <-", irq_status);
+
+	return irq_status;
+}
+
+static int h264_encode_sps(struct venc_h264_inst *inst,
+			   struct mtk_vcodec_mem *bs_buf,
+			   unsigned int *bs_size)
+{
+	int ret = 0;
+	unsigned int irq_status;
+
+	mtk_vcodec_debug_enter(inst);
+
+	ret = h264_enc_vpu_encode(inst, H264_BS_MODE_SPS, NULL,
+				  bs_buf, bs_size);
+	if (ret)
+		return ret;
+
+	irq_status = h264_enc_wait_venc_done(inst);
+	if (irq_status != H264_IRQ_STATUS_ENC_SPS_INT) {
+		mtk_vcodec_err(inst, "expect irq status %d",
+			       H264_IRQ_STATUS_ENC_SPS_INT);
+		return -EINVAL;
+	}
+
+	*bs_size = h264_read_reg(inst, VENC_PIC_BITSTREAM_BYTE_CNT);
+	mtk_vcodec_debug(inst, "bs size %d <-", *bs_size);
+
+	return ret;
+}
+
+static int h264_encode_pps(struct venc_h264_inst *inst,
+			   struct mtk_vcodec_mem *bs_buf,
+			   unsigned int *bs_size)
+{
+	int ret = 0;
+	unsigned int irq_status;
+
+	mtk_vcodec_debug_enter(inst);
+
+	ret = h264_enc_vpu_encode(inst, H264_BS_MODE_PPS, NULL,
+				  bs_buf, bs_size);
+	if (ret)
+		return ret;
+
+	irq_status = h264_enc_wait_venc_done(inst);
+	if (irq_status != H264_IRQ_STATUS_ENC_PPS_INT) {
+		mtk_vcodec_err(inst, "expect irq status %d",
+			       H264_IRQ_STATUS_ENC_PPS_INT);
+		return -EINVAL;
+	}
+
+	*bs_size = h264_read_reg(inst, VENC_PIC_BITSTREAM_BYTE_CNT);
+	mtk_vcodec_debug(inst, "bs size %d <-", *bs_size);
+
+	return ret;
+}
+
+static int h264_encode_frame(struct venc_h264_inst *inst,
+			     struct venc_frm_buf *frm_buf,
+			     struct mtk_vcodec_mem *bs_buf,
+			     unsigned int *bs_size)
+{
+	int ret = 0;
+	unsigned int irq_status;
+
+	mtk_vcodec_debug_enter(inst);
+
+	ret = h264_enc_vpu_encode(inst, H264_BS_MODE_FRAME, frm_buf,
+				  bs_buf, bs_size);
+	if (ret)
+		return ret;
+
+	/*
+	 * skip frame case: The skip frame buffer is composed by vpu side only,
+	 * it does not trigger the hw, so skip the wait interrupt operation.
+	 */
+	if (!inst->vpu_inst.wait_int) {
+		++inst->frm_cnt;
+		return ret;
+	}
+
+	irq_status = h264_enc_wait_venc_done(inst);
+	if (irq_status != H264_IRQ_STATUS_ENC_FRM_INT) {
+		mtk_vcodec_err(inst, "irq_status=%d failed", irq_status);
+		return -EINVAL;
+	}
+
+	*bs_size = h264_read_reg(inst,
+				 VENC_PIC_BITSTREAM_BYTE_CNT);
+	++inst->frm_cnt;
+	mtk_vcodec_debug(inst, "frm %d bs size %d key_frm %d <-",
+			 inst->frm_cnt,
+			 *bs_size, inst->is_key_frm);
+
+	return ret;
+}
+
+static void h264_encode_filler(struct venc_h264_inst *inst, void *buf,
+			       int size)
+{
+	unsigned char *p = buf;
+
+	*p++ = 0x0;
+	*p++ = 0x0;
+	*p++ = 0x0;
+	*p++ = 0x1;
+	*p++ = 0xc;
+	size -= 5;
+	while (size) {
+		*p++ = 0xff;
+		size -= 1;
+	}
+}
+
+static int h264_enc_init(struct mtk_vcodec_ctx *ctx, unsigned long *handle)
+{
+	int ret = 0;
+	struct venc_h264_inst *inst;
+
+	inst = kzalloc(sizeof(*inst), GFP_KERNEL);
+	if (!inst)
+		return -ENOMEM;
+
+	inst->ctx = ctx;
+	inst->dev = mtk_vcodec_get_plat_dev(ctx);
+	inst->hw_base = mtk_vcodec_get_reg_addr(inst->ctx, VENC_SYS);
+
+	mtk_vcodec_debug_enter(inst);
+	ret = h264_enc_vpu_init(inst);
+	if (ret)
+		kfree(inst);
+	else
+		(*handle) = (unsigned long)inst;
+
+	mtk_vcodec_debug_leave(inst);
+
+	return ret;
+}
+
+static int h264_enc_encode(unsigned long handle,
+			   enum venc_start_opt opt,
+			   struct venc_frm_buf *frm_buf,
+			   struct mtk_vcodec_mem *bs_buf,
+			   struct venc_done_result *result)
+{
+	int ret = 0;
+	struct venc_h264_inst *inst = (struct venc_h264_inst *)handle;
+	struct mtk_vcodec_ctx *ctx = inst->ctx;
+
+	mtk_vcodec_debug(inst, "opt %d ->", opt);
+
+	enable_irq(ctx->dev->enc_irq);
+
+	switch (opt) {
+	case VENC_START_OPT_ENCODE_SEQUENCE_HEADER: {
+		unsigned int bs_size_sps;
+		unsigned int bs_size_pps;
+
+		memset(bs_buf->va, 0x38, 20);
+		ret = h264_encode_sps(inst, bs_buf, &bs_size_sps);
+		if (ret)
+			goto encode_err;
+
+		memset(inst->pps_buf.va, 0x49, 20);
+		ret = h264_encode_pps(inst, &inst->pps_buf, &bs_size_pps);
+		if (ret)
+			goto encode_err;
+
+		memcpy(bs_buf->va + bs_size_sps,
+		       inst->pps_buf.va,
+		       bs_size_pps);
+		result->bs_size = bs_size_sps + bs_size_pps;
+		result->is_key_frm = false;
+		break;
+	}
+
+	case VENC_START_OPT_ENCODE_FRAME: {
+		int hdr_sz;
+		int hdr_sz_ext;
+		int bs_alignment = 128;
+		int filler_sz = 0;
+		struct mtk_vcodec_mem tmp_bs_buf;
+		unsigned int bs_size_sps;
+		unsigned int bs_size_pps;
+		unsigned int bs_size_frm;
+
+		if (!inst->prepend_hdr) {
+			ret = h264_encode_frame(inst, frm_buf, bs_buf,
+						&result->bs_size);
+			if (ret)
+				goto encode_err;
+			result->is_key_frm = inst->is_key_frm;
+			break;
+		}
+
+		mtk_vcodec_debug(inst, "h264_encode_frame prepend SPS/PPS");
+		ret = h264_encode_sps(inst, bs_buf, &bs_size_sps);
+		if (ret)
+			goto encode_err;
+
+		ret = h264_encode_pps(inst, &inst->pps_buf, &bs_size_pps);
+		if (ret)
+			goto encode_err;
+
+		memcpy(bs_buf->va + bs_size_sps, inst->pps_buf.va, bs_size_pps);
+
+		hdr_sz = bs_size_sps + bs_size_pps;
+		hdr_sz_ext = (hdr_sz & (bs_alignment - 1));
+		if (hdr_sz_ext) {
+			filler_sz = bs_alignment - hdr_sz_ext;
+			if (hdr_sz_ext + 5 > bs_alignment)
+				filler_sz += bs_alignment;
+			h264_encode_filler(inst, bs_buf->va + hdr_sz,
+					   filler_sz);
+		}
+
+		tmp_bs_buf.va = bs_buf->va + hdr_sz + filler_sz;
+		tmp_bs_buf.dma_addr = bs_buf->dma_addr + hdr_sz + filler_sz;
+		tmp_bs_buf.size = bs_buf->size - (hdr_sz + filler_sz);
+
+		ret = h264_encode_frame(inst, frm_buf, &tmp_bs_buf,
+					&bs_size_frm);
+		if (ret)
+			goto encode_err;
+
+		result->bs_size = hdr_sz + filler_sz + bs_size_frm;
+		mtk_vcodec_debug(inst, "hdr %d filler %d frame %d bs %d",
+				 hdr_sz, filler_sz, bs_size_frm,
+				 result->bs_size);
+
+		inst->prepend_hdr = 0;
+		result->is_key_frm = inst->is_key_frm;
+		break;
+	}
+
+	default:
+		mtk_vcodec_err(inst, "venc_start_opt %d not supported", opt);
+		ret = -EINVAL;
+		break;
+	}
+
+encode_err:
+	if (ret)
+		result->msg = VENC_MESSAGE_ERR;
+	else
+		result->msg = VENC_MESSAGE_OK;
+
+	disable_irq(ctx->dev->enc_irq);
+	mtk_vcodec_debug(inst, "opt %d <-", opt);
+
+	return ret;
+}
+
+static int h264_enc_set_param(unsigned long handle,
+			      enum venc_set_param_type type, void *in)
+{
+	int ret = 0;
+	struct venc_h264_inst *inst = (struct venc_h264_inst *)handle;
+	struct venc_enc_prm *enc_prm;
+
+	mtk_vcodec_debug(inst, "->type=%d", type);
+
+	switch (type) {
+	case VENC_SET_PARAM_ENC:
+		enc_prm = in;
+		ret = h264_enc_vpu_set_param(inst, type, enc_prm);
+		if (ret)
+			break;
+		if (inst->work_buf_allocated == 1) {
+			h264_enc_free_work_buf(inst);
+			inst->work_buf_allocated = 0;
+		}
+		if (inst->work_buf_allocated == 0) {
+			ret = h264_enc_alloc_work_buf(inst, enc_prm);
+			if (ret)
+				break;
+			inst->work_buf_allocated = 1;
+		}
+		break;
+
+	case VENC_SET_PARAM_FORCE_INTRA:
+		ret = h264_enc_vpu_set_param(inst, type, 0);
+		break;
+
+	case VENC_SET_PARAM_ADJUST_BITRATE:
+		enc_prm = in;
+		ret = h264_enc_vpu_set_param(inst, type, &enc_prm->bitrate);
+		break;
+
+	case VENC_SET_PARAM_ADJUST_FRAMERATE:
+		enc_prm = in;
+		ret = h264_enc_vpu_set_param(inst, type, &enc_prm->frm_rate);
+		break;
+
+	case VENC_SET_PARAM_I_FRAME_INTERVAL:
+		ret = h264_enc_vpu_set_param(inst, type, in);
+		break;
+
+	case VENC_SET_PARAM_SKIP_FRAME:
+		ret = h264_enc_vpu_set_param(inst, type, 0);
+		break;
+
+	case VENC_SET_PARAM_PREPEND_HEADER:
+		inst->prepend_hdr = 1;
+		mtk_vcodec_debug(inst, "set prepend header mode");
+		break;
+
+	default:
+		mtk_vcodec_err(inst, "type %d not supported", type);
+		ret = -EINVAL;
+		break;
+	}
+
+	mtk_vcodec_debug_leave(inst);
+
+	return ret;
+}
+
+static int h264_enc_deinit(unsigned long handle)
+{
+	int ret = 0;
+	struct venc_h264_inst *inst = (struct venc_h264_inst *)handle;
+
+	mtk_vcodec_debug_enter(inst);
+
+	ret = h264_enc_vpu_deinit(inst);
+
+	if (inst->work_buf_allocated)
+		h264_enc_free_work_buf(inst);
+
+	mtk_vcodec_debug_leave(inst);
+	kfree(inst);
+
+	return ret;
+}
+
+static struct venc_common_if venc_h264_if = {
+	h264_enc_init,
+	h264_enc_encode,
+	h264_enc_set_param,
+	h264_enc_deinit,
+};
+
+struct venc_common_if *get_h264_enc_comm_if(void)
+{
+	return &venc_h264_if;
+}
diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
new file mode 100644
index 0000000..533cf83
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
@@ -0,0 +1,168 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
+ *         Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#ifndef _VENC_H264_IF_H_
+#define _VENC_H264_IF_H_
+
+#include "venc_drv_base.h"
+
+/**
+ * enum venc_h264_vpu_work_buf - h264 encoder buffer index
+ */
+enum venc_h264_vpu_work_buf {
+	VENC_H264_VPU_WORK_BUF_RC_INFO,
+	VENC_H264_VPU_WORK_BUF_RC_CODE,
+	VENC_H264_VPU_WORK_BUF_REC_LUMA,
+	VENC_H264_VPU_WORK_BUF_REC_CHROMA,
+	VENC_H264_VPU_WORK_BUF_REF_LUMA,
+	VENC_H264_VPU_WORK_BUF_REF_CHROMA,
+	VENC_H264_VPU_WORK_BUF_MV_INFO_1,
+	VENC_H264_VPU_WORK_BUF_MV_INFO_2,
+	VENC_H264_VPU_WORK_BUF_SKIP_FRAME,
+	VENC_H264_VPU_WORK_BUF_SRC_LUMA,
+	VENC_H264_VPU_WORK_BUF_SRC_CHROMA,
+	VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CB,
+	VENC_H264_VPU_WORK_BUF_SRC_CHROMA_CR,
+	VENC_H264_VPU_WORK_BUF_MAX,
+};
+
+/**
+ * enum venc_h264_bs_mode - for bs_mode argument in h264_enc_vpu_encode
+ */
+enum venc_h264_bs_mode {
+	H264_BS_MODE_SPS,
+	H264_BS_MODE_PPS,
+	H264_BS_MODE_FRAME,
+};
+
+/*
+ * struct venc_h264_vpu_config - Structure for h264 encoder configuration
+ * @input_fourcc: input fourcc
+ * @bitrate: target bitrate (in bps)
+ * @pic_w: picture width. Picture size is visible stream resolution, in pixels,
+ *         to be used for display purposes; must be smaller or equal to buffer
+ *         size.
+ * @pic_h: picture height
+ * @buf_w: buffer width. Buffer size is stream resolution in pixels aligned to
+ *         hardware requirements.
+ * @buf_h: buffer height
+ * @intra_period: intra frame period
+ * @framerate: frame rate
+ * @profile: as specified in standard
+ * @level: as specified in standard
+ * @wfd: WFD mode 1:on, 0:off
+ */
+struct venc_h264_vpu_config {
+	u32 input_fourcc;
+	u32 bitrate;
+	u32 pic_w;
+	u32 pic_h;
+	u32 buf_w;
+	u32 buf_h;
+	u32 intra_period;
+	u32 framerate;
+	u32 profile;
+	u32 level;
+	u32 wfd;
+};
+
+/*
+ * struct venc_h264_vpu_buf - Structure for buffer information
+ * @align: buffer alignment (in bytes)
+ * @iova: IO virtual address
+ * @vpua: VPU side memory addr which is used by RC_CODE
+ * @size: buffer size (in bytes)
+ */
+struct venc_h264_vpu_buf {
+	u32 align;
+	u32 iova;
+	u32 vpua;
+	u32 size;
+};
+
+/*
+ * struct venc_h264_vpu_drv - Structure for VPU driver control and info share
+ * This structure is allocated in VPU side and shared to AP side.
+ * @config: h264 encoder configuration
+ * @work_bufs: working buffer information in VPU side
+ * The work_bufs here is for storing the 'size' info shared to AP side.
+ * The similar item in struct venc_h264_inst is for memory allocation
+ * in AP side. The AP driver will copy the 'size' from here to the one in
+ * struct mtk_vcodec_mem, then invoke mtk_vcodec_mem_alloc to allocate
+ * the buffer. After that, bypass the 'dma_addr' to the 'iova' field here for
+ * register setting in VPU side.
+ */
+struct venc_h264_vpu_drv {
+	struct venc_h264_vpu_config config;
+	struct venc_h264_vpu_buf work_bufs[VENC_H264_VPU_WORK_BUF_MAX];
+};
+
+/*
+ * struct venc_h264_vpu_inst - h264 encoder VPU driver instance
+ * @wq_hd: wait queue used for vpu cmd trigger then wait vpu interrupt done
+ * @signaled: flag used for checking vpu interrupt done
+ * @failure: flag to show vpu cmd succeeds or not
+ * @state: enum venc_ipi_msg_enc_state
+ * @bs_size: bitstream size for skip frame case usage
+ * @wait_int: flag to wait interrupt done (0: for skip frame case, 1: normal
+ *	      case)
+ * @id: VPU instance id
+ * @drv: driver structure allocated by VPU side and shared to AP side for
+ *	 control and info share
+ */
+struct venc_h264_vpu_inst {
+	wait_queue_head_t wq_hd;
+	int signaled;
+	int failure;
+	int state;
+	int bs_size;
+	int wait_int;
+	unsigned int id;
+	struct venc_h264_vpu_drv *drv;
+};
+
+/*
+ * struct venc_h264_inst - h264 encoder AP driver instance
+ * @hw_base: h264 encoder hardware register base
+ * @work_bufs: working buffer
+ * @pps_buf: buffer to store the pps bitstream
+ * @work_buf_allocated: working buffer allocated flag
+ * @frm_cnt: encoded frame count
+ * @prepend_hdr: when the v4l2 layer send VENC_SET_PARAM_PREPEND_HEADER cmd
+ *  through h264_enc_set_param interface, it will set this flag and prepend the
+ *  sps/pps in h264_enc_encode function.
+ * @is_key_frm: key frame flag
+ * @vpu_inst: VPU instance to exchange information between AP and VPU
+ * @ctx: context for v4l2 layer integration
+ * @dev: device for v4l2 layer integration
+ */
+struct venc_h264_inst {
+	void __iomem *hw_base;
+	struct mtk_vcodec_mem work_bufs[VENC_H264_VPU_WORK_BUF_MAX];
+	struct mtk_vcodec_mem pps_buf;
+	bool work_buf_allocated;
+	unsigned int frm_cnt;
+	unsigned int prepend_hdr;
+	unsigned int is_key_frm;
+	struct venc_h264_vpu_inst vpu_inst;
+	void *ctx;
+	struct platform_device *dev;
+};
+
+struct venc_common_if *get_h264_enc_comm_if(void);
+
+#endif
diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
new file mode 100644
index 0000000..e8464a3
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
@@ -0,0 +1,309 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
+ *         Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#include "mtk_vpu.h"
+
+#include "venc_h264_if.h"
+#include "venc_h264_vpu.h"
+#include "venc_ipi_msg.h"
+
+static unsigned int h264_get_profile(unsigned int profile)
+{
+	/* (Baseline=66, Main=77, High=100) */
+	switch (profile) {
+	case V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE:
+		return 66;
+	case V4L2_MPEG_VIDEO_H264_PROFILE_MAIN:
+		return 77;
+	case V4L2_MPEG_VIDEO_H264_PROFILE_HIGH:
+		return 100;
+	default:
+		return 100;
+	}
+}
+
+static unsigned int h264_get_level(unsigned int level)
+{
+	/* (UpTo4.1(HighProfile)) */
+	switch (level) {
+	case V4L2_MPEG_VIDEO_H264_LEVEL_1_0:
+		return 10;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_1_1:
+		return 11;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_1_2:
+		return 12;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_1_3:
+		return 13;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_2_0:
+		return 20;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_2_1:
+		return 21;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_2_2:
+		return 22;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_3_0:
+		return 30;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_3_1:
+		return 31;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_3_2:
+		return 32;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_4_0:
+		return 40;
+	case V4L2_MPEG_VIDEO_H264_LEVEL_4_1:
+		return 41;
+	default:
+		return 31;
+	}
+}
+
+static void handle_h264_enc_init_msg(struct venc_h264_inst *inst, void *data)
+{
+	struct venc_vpu_ipi_msg_init *msg = data;
+
+	inst->vpu_inst.id = msg->inst_id;
+	inst->vpu_inst.drv = (struct venc_h264_vpu_drv *)vpu_mapping_dm_addr(
+		inst->dev, msg->inst_id);
+}
+
+static void handle_h264_enc_encode_msg(struct venc_h264_inst *inst, void *data)
+{
+	struct venc_vpu_ipi_msg_enc *msg = data;
+
+	inst->vpu_inst.state = msg->state;
+	inst->vpu_inst.bs_size = msg->bs_size;
+	inst->is_key_frm = msg->key_frame;
+}
+
+static void h264_enc_vpu_ipi_handler(void *data, unsigned int len, void *priv)
+{
+	struct venc_vpu_ipi_msg_common *msg = data;
+	struct venc_h264_inst *inst = (struct venc_h264_inst *)msg->venc_inst;
+
+	mtk_vcodec_debug(inst, "msg_id %x inst %p status %d",
+			 msg->msg_id, inst, msg->status);
+
+	switch (msg->msg_id) {
+	case VPU_IPIMSG_H264_ENC_INIT_DONE:
+		handle_h264_enc_init_msg(inst, data);
+		break;
+	case VPU_IPIMSG_H264_ENC_SET_PARAM_DONE:
+		break;
+	case VPU_IPIMSG_H264_ENC_ENCODE_DONE:
+		handle_h264_enc_encode_msg(inst, data);
+		break;
+	case VPU_IPIMSG_H264_ENC_DEINIT_DONE:
+		break;
+	default:
+		mtk_vcodec_err(inst, "unknown msg id %x", msg->msg_id);
+		break;
+	}
+
+	inst->vpu_inst.signaled = 1;
+	inst->vpu_inst.failure = (msg->status != VENC_IPI_MSG_STATUS_OK);
+
+	mtk_vcodec_debug_leave(inst);
+}
+
+static int h264_enc_vpu_send_msg(struct venc_h264_inst *inst, void *msg,
+				 int len)
+{
+	int status;
+
+	mtk_vcodec_debug_enter(inst);
+	status = vpu_ipi_send(inst->dev, IPI_VENC_H264, msg, len);
+	if (status) {
+		mtk_vcodec_err(inst, "vpu_ipi_send msg %x len %d fail %d",
+			       *(unsigned int *)msg, len, status);
+		return -EINVAL;
+	}
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
+
+int h264_enc_vpu_init(struct venc_h264_inst *inst)
+{
+	int status;
+	struct venc_ap_ipi_msg_init out;
+
+	mtk_vcodec_debug_enter(inst);
+
+	init_waitqueue_head(&inst->vpu_inst.wq_hd);
+	inst->vpu_inst.signaled = 0;
+	inst->vpu_inst.failure = 0;
+
+	status = vpu_ipi_register(inst->dev, IPI_VENC_H264,
+				  h264_enc_vpu_ipi_handler,
+				  "h264_enc", NULL);
+	if (status) {
+		mtk_vcodec_err(inst, "vpu_ipi_register fail %d", status);
+		return -EINVAL;
+	}
+
+	out.msg_id = AP_IPIMSG_H264_ENC_INIT;
+	out.venc_inst = (unsigned long)inst;
+	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst, "AP_IPIMSG_H264_ENC_INIT fail");
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
+
+int h264_enc_vpu_set_param(struct venc_h264_inst *inst, unsigned int id,
+			   void *param)
+{
+	struct venc_ap_ipi_msg_set_param out;
+
+	mtk_vcodec_debug(inst, "id %d ->", id);
+
+	out.msg_id = AP_IPIMSG_H264_ENC_SET_PARAM;
+	out.inst_id = inst->vpu_inst.id;
+	out.param_id = id;
+	switch (id) {
+	case VENC_SET_PARAM_ENC: {
+		struct venc_enc_prm *enc_param = (struct venc_enc_prm *)param;
+
+		inst->vpu_inst.drv->config.input_fourcc =
+			enc_param->input_fourcc;
+		inst->vpu_inst.drv->config.bitrate = enc_param->bitrate;
+		inst->vpu_inst.drv->config.pic_w = enc_param->width;
+		inst->vpu_inst.drv->config.pic_h = enc_param->height;
+		inst->vpu_inst.drv->config.buf_w = enc_param->buf_width;
+		inst->vpu_inst.drv->config.buf_h = enc_param->buf_height;
+		inst->vpu_inst.drv->config.intra_period =
+			enc_param->intra_period;
+		inst->vpu_inst.drv->config.framerate = enc_param->frm_rate;
+		inst->vpu_inst.drv->config.profile =
+			h264_get_profile(enc_param->h264_profile);
+		inst->vpu_inst.drv->config.level =
+			h264_get_level(enc_param->h264_level);
+		inst->vpu_inst.drv->config.wfd = 0;
+		out.data_item = 0;
+		break;
+	}
+	case VENC_SET_PARAM_FORCE_INTRA:
+		out.data_item = 0;
+		break;
+	case VENC_SET_PARAM_ADJUST_BITRATE:
+		out.data_item = 1;
+		out.data[0] = *(unsigned int *)param;
+		break;
+	case VENC_SET_PARAM_ADJUST_FRAMERATE:
+		out.data_item = 1;
+		out.data[0] = *(unsigned int *)param;
+		break;
+	case VENC_SET_PARAM_I_FRAME_INTERVAL:
+		out.data_item = 1;
+		out.data[0] = *(unsigned int *)param;
+		break;
+	case VENC_SET_PARAM_SKIP_FRAME:
+		out.data_item = 0;
+		break;
+	}
+	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst,
+			       "AP_IPIMSG_H264_ENC_SET_PARAM %d fail", id);
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug(inst, "id %d <-", id);
+
+	return 0;
+}
+
+int h264_enc_vpu_encode(struct venc_h264_inst *inst, unsigned int bs_mode,
+			struct venc_frm_buf *frm_buf,
+			struct mtk_vcodec_mem *bs_buf,
+			unsigned int *bs_size)
+{
+	struct venc_ap_ipi_msg_enc out;
+
+	mtk_vcodec_debug(inst, "bs_mode %d ->", bs_mode);
+
+	out.msg_id = AP_IPIMSG_H264_ENC_ENCODE;
+	out.inst_id = inst->vpu_inst.id;
+	out.bs_mode = bs_mode;
+	if (frm_buf) {
+		if ((frm_buf->fb_addr.dma_addr % 16 == 0) &&
+		    (frm_buf->fb_addr1.dma_addr % 16 == 0) &&
+		    (frm_buf->fb_addr2.dma_addr % 16 == 0)) {
+			out.input_addr[0] = frm_buf->fb_addr.dma_addr;
+			out.input_addr[1] = frm_buf->fb_addr1.dma_addr;
+			out.input_addr[2] = frm_buf->fb_addr2.dma_addr;
+		} else {
+			mtk_vcodec_err(inst, "dma_addr not align to 16");
+			return -EINVAL;
+		}
+	} else {
+		out.input_addr[0] = 0;
+		out.input_addr[1] = 0;
+		out.input_addr[2] = 0;
+	}
+	if (bs_buf) {
+		out.bs_addr = bs_buf->dma_addr;
+		out.bs_size = bs_buf->size;
+	} else {
+		out.bs_addr = 0;
+		out.bs_size = 0;
+	}
+	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst, "AP_IPIMSG_H264_ENC_ENCODE %d fail",
+			       bs_mode);
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug(inst, "state %d size %d key_frm %d",
+			 inst->vpu_inst.state, inst->vpu_inst.bs_size,
+			 inst->is_key_frm);
+
+	inst->vpu_inst.wait_int = 1;
+	if (inst->vpu_inst.state == VEN_IPI_MSG_ENC_STATE_SKIP) {
+		*bs_size = inst->vpu_inst.bs_size;
+		memcpy(bs_buf->va,
+		       inst->work_bufs[VENC_H264_VPU_WORK_BUF_SKIP_FRAME].va,
+		       *bs_size);
+		inst->vpu_inst.wait_int = 0;
+	}
+
+	mtk_vcodec_debug(inst, "bs_mode %d <-", bs_mode);
+
+	return 0;
+}
+
+int h264_enc_vpu_deinit(struct venc_h264_inst *inst)
+{
+	struct venc_ap_ipi_msg_deinit out;
+
+	mtk_vcodec_debug_enter(inst);
+
+	out.msg_id = AP_IPIMSG_H264_ENC_DEINIT;
+	out.inst_id = inst->vpu_inst.id;
+	if (h264_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst, "AP_IPIMSG_H264_ENC_DEINIT fail");
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
new file mode 100644
index 0000000..6eb9599
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Jungchang Tsao <jungchang.tsao at mediatek.com>
+ *         Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#ifndef _VENC_H264_VPU_H_
+#define _VENC_H264_VPU_H_
+
+int h264_enc_vpu_init(struct venc_h264_inst *inst);
+int h264_enc_vpu_set_param(struct venc_h264_inst *inst, unsigned int id,
+			   void *param);
+int h264_enc_vpu_encode(struct venc_h264_inst *inst, unsigned int bs_mode,
+			struct venc_frm_buf *frm_buf,
+			struct mtk_vcodec_mem *bs_buf,
+			unsigned int *bs_size);
+int h264_enc_vpu_deinit(struct venc_h264_inst *inst);
+
+#endif
diff --git a/drivers/media/platform/mtk-vcodec/venc_drv_if.c b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
index f631f5d..8fa5aa0 100644
--- a/drivers/media/platform/mtk-vcodec/venc_drv_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
@@ -26,6 +26,7 @@
 
 #include "venc_drv_base.h"
 #include "vp8_enc/venc_vp8_if.h"
+#include "h264_enc/venc_h264_if.h"
 
 int venc_if_create(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
 {
@@ -39,6 +40,8 @@ int venc_if_create(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
 		ctx->enc_if = get_vp8_enc_comm_if();
 		break;
 	case V4L2_PIX_FMT_H264:
+		ctx->enc_if = get_h264_enc_comm_if();
+		break;
 	default:
 		return -EINVAL;
 	}
-- 
1.7.9.5



From tiffany.lin at mediatek.com  Tue Feb 23 00:11:17 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Tue, 23 Feb 2016 16:11:17 +0800
Subject: [PATCH v5 4/8] dt-bindings: Add a binding for Mediatek Video Encoder
In-Reply-To: <1456215081-16858-4-git-send-email-tiffany.lin@mediatek.com>
References: <1456215081-16858-1-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-2-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-3-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-4-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <1456215081-16858-5-git-send-email-tiffany.lin@mediatek.com>

Add a DT binding documentation of Video Encoder for the
MT8173 SoC from Mediatek.

Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/media/mediatek-vcodec.txt  |   59 ++++++++++++++++++++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
new file mode 100644
index 0000000..c2e8137
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -0,0 +1,59 @@
+Mediatek Video Codec
+
+Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
+supports high resolution encoding functionalities.
+
+Required properties:
+- compatible : "mediatek,mt8173-vcodec-enc" for encoder
+- reg : Physical base address of the video codec registers and length of
+  memory mapped region.
+- interrupts : interrupt number to the cpu.
+- mediatek,larb : must contain the local arbiters in the current Socs.
+- clocks : list of clock specifiers, corresponding to entries in
+  the clock-names property.
+- clock-names: encoder must contain "venc_sel_src", "venc_sel",
+  "venc_lt_sel_src", "venc_lt_sel".
+- iommus : should point to the respective IOMMU block with master port as
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  for details.
+- mediatek,vpu : the node of video processor unit
+
+Example:
+vcodec_enc: vcodec at 0x18002000 {
+    compatible = "mediatek,mt8173-vcodec-enc";
+    reg = <0 0x18002000 0 0x1000>,    /*VENC_SYS*/
+          <0 0x19002000 0 0x1000>;    /*VENC_LT_SYS*/
+    interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>,
+           <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>;
+    mediatek,larb = <&larb3>,
+		    <&larb5>;
+    iommus = <&iommu M4U_PORT_VENC_RCPU>,
+             <&iommu M4U_PORT_VENC_REC>,
+             <&iommu M4U_PORT_VENC_BSDMA>,
+             <&iommu M4U_PORT_VENC_SV_COMV>,
+             <&iommu M4U_PORT_VENC_RD_COMV>,
+             <&iommu M4U_PORT_VENC_CUR_LUMA>,
+             <&iommu M4U_PORT_VENC_CUR_CHROMA>,
+             <&iommu M4U_PORT_VENC_REF_LUMA>,
+             <&iommu M4U_PORT_VENC_REF_CHROMA>,
+             <&iommu M4U_PORT_VENC_NBM_RDMA>,
+             <&iommu M4U_PORT_VENC_NBM_WDMA>,
+             <&iommu M4U_PORT_VENC_RCPU_SET2>,
+             <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
+             <&iommu M4U_PORT_VENC_BSDMA_SET2>,
+             <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
+             <&iommu M4U_PORT_VENC_RD_COMA_SET2>,
+             <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
+             <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
+             <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
+             <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
+    mediatek,vpu = <&vpu>;
+    clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
+             <&topckgen CLK_TOP_VENC_SEL>,
+             <&topckgen CLK_TOP_UNIVPLL1_D2>,
+             <&topckgen CLK_TOP_VENC_LT_SEL>;
+    clock-names = "venc_sel_src",
+                  "venc_sel",
+                  "venc_lt_sel_src",
+                  "venc_lt_sel";
+  };
-- 
1.7.9.5



From tiffany.lin at mediatek.com  Tue Feb 23 00:11:19 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Tue, 23 Feb 2016 16:11:19 +0800
Subject: [PATCH v5 6/8] [media] vcodec: mediatek: Add Mediatek VP8 Video
 Encoder Driver
In-Reply-To: <1456215081-16858-6-git-send-email-tiffany.lin@mediatek.com>
References: <1456215081-16858-1-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-2-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-3-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-4-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-5-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-6-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <1456215081-16858-7-git-send-email-tiffany.lin@mediatek.com>

From: PoChun Lin <pochun.lin at mediatek.com>

Add vp8 encoder driver for MT8173

Signed-off-by: pochun.lin <pochun.lin at mediatek.com>
Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
---
 drivers/media/platform/mtk-vcodec/Makefile         |    2 +
 drivers/media/platform/mtk-vcodec/venc_drv_if.c    |    3 +
 drivers/media/platform/mtk-vcodec/vp8_enc/Makefile |    6 +
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_if.c      |  419 ++++++++++++++++++++
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_if.h      |  152 +++++++
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c     |  240 +++++++++++
 .../platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h     |   28 ++
 7 files changed, 850 insertions(+)
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/Makefile
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.h
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c
 create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h

diff --git a/drivers/media/platform/mtk-vcodec/Makefile b/drivers/media/platform/mtk-vcodec/Makefile
index ce38689..f4ef502 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -5,4 +5,6 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk_vcodec_intr.o \
 				       mtk_vcodec_enc_pm.o \
 				       venc_drv_if.o
 
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += vp8_enc/
+
 ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/venc_drv_if.c b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
index 1675b9e..f631f5d 100644
--- a/drivers/media/platform/mtk-vcodec/venc_drv_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
@@ -25,6 +25,7 @@
 #include "mtk_vpu.h"
 
 #include "venc_drv_base.h"
+#include "vp8_enc/venc_vp8_if.h"
 
 int venc_if_create(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
 {
@@ -35,6 +36,8 @@ int venc_if_create(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
 
 	switch (fourcc) {
 	case V4L2_PIX_FMT_VP8:
+		ctx->enc_if = get_vp8_enc_comm_if();
+		break;
 	case V4L2_PIX_FMT_H264:
 	default:
 		return -EINVAL;
diff --git a/drivers/media/platform/mtk-vcodec/vp8_enc/Makefile b/drivers/media/platform/mtk-vcodec/vp8_enc/Makefile
new file mode 100644
index 0000000..0f515c7
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vp8_enc/Makefile
@@ -0,0 +1,6 @@
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += venc_vp8_if.o venc_vp8_vpu.o
+
+ccflags-y += \
+    -I$(srctree)/drivers/media/platform/mtk-vcodec/ \
+    -I$(srctree)/drivers/media/platform/mtk-vcodec/vp8_enc \
+    -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c
new file mode 100644
index 0000000..b9dcf4d
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c
@@ -0,0 +1,419 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+
+#include "mtk_vcodec_drv.h"
+#include "mtk_vcodec_util.h"
+#include "mtk_vcodec_intr.h"
+#include "mtk_vcodec_enc.h"
+#include "mtk_vcodec_pm.h"
+#include "mtk_vpu.h"
+
+#include "venc_vp8_if.h"
+#include "venc_vp8_vpu.h"
+
+#define VENC_PIC_BITSTREAM_BYTE_CNT 0x0098
+#define VENC_PIC_BITSTREAM_BYTE_CNT1 0x00e8
+#define VENC_IRQ_STATUS_ENC_FRM_INT 0x04
+
+#define MAX_AC_TAG_SZ 10
+
+static inline void vp8_enc_write_reg(struct venc_vp8_inst *inst, u32 addr,
+				     u32 val)
+{
+	writel(val, inst->hw_base + addr);
+}
+
+static inline u32 vp8_enc_read_reg(struct venc_vp8_inst *inst, u32 addr)
+{
+	return readl(inst->hw_base + addr);
+}
+
+static void vp8_enc_free_work_buf(struct venc_vp8_inst *inst)
+{
+	int i;
+
+	mtk_vcodec_debug_enter(inst);
+
+	/* Buffers need to be freed by AP. */
+	for (i = 0; i < VENC_VP8_VPU_WORK_BUF_MAX; i++)
+		if (inst->work_bufs[i].va != NULL)
+			mtk_vcodec_mem_free(inst->ctx,
+					    &inst->work_bufs[i]);
+
+	mtk_vcodec_debug_leave(inst);
+}
+
+static int vp8_enc_alloc_work_buf(struct venc_vp8_inst *inst, void *param)
+{
+	int i;
+	int ret = 0;
+	struct venc_vp8_vpu_buf *wb = inst->vpu_inst.drv->work_bufs;
+	struct venc_enc_prm *enc_param = param;
+
+	mtk_vcodec_debug_enter(inst);
+
+	for (i = 0; i < VENC_VP8_VPU_WORK_BUF_MAX; i++) {
+		/*
+		 * Only temporal scalability mode will use RC_CODE2 & RC_CODE3
+		 * Each three temporal layer has its own rate control code.
+		 */
+		if ((i == VENC_VP8_VPU_WORK_BUF_RC_CODE2 ||
+		     i == VENC_VP8_VPU_WORK_BUF_RC_CODE3) && !inst->ts_mode)
+			continue;
+
+		/*
+		 * This 'wb' structure is set by VPU side and shared to AP for
+		 * buffer allocation and IO virtual addr mapping. For most of
+		 * the buffers, AP will allocate the buffer according to 'size'
+		 * field and store the IO virtual addr in 'iova' field. For the
+		 * RC_CODEx buffers, they are pre-allocated in the VPU side
+		 * because they are inside VPU SRAM, and save the VPU addr in
+		 * the 'vpua' field. The AP will translate the VPU addr to the
+		 * corresponding IO virtual addr and store in 'iova' field.
+		 */
+		inst->work_bufs[i].size = wb[i].size;
+		if (i < VENC_VP8_VPU_WORK_BUF_RC_CODE) {
+			ret = mtk_vcodec_mem_alloc(inst->ctx,
+						   &inst->work_bufs[i]);
+			if (ret) {
+				mtk_vcodec_err(inst,
+					       "cannot alloc work_bufs[%d]", i);
+				goto err_alloc;
+			}
+		} else if (i == VENC_VP8_VPU_WORK_BUF_SRC_LUMA ||
+			   i == VENC_VP8_VPU_WORK_BUF_SRC_CHROMA ||
+			   i == VENC_VP8_VPU_WORK_BUF_SRC_CHROMA_CB ||
+			   i == VENC_VP8_VPU_WORK_BUF_SRC_CHROMA_CR) {
+			inst->work_bufs[i].dma_addr = 0;
+			inst->work_bufs[i].va = NULL;
+		} else {
+			void *tmp_va;
+
+			tmp_va = vpu_mapping_dm_addr(inst->dev, wb[i].vpua);
+			ret = mtk_vcodec_mem_alloc(inst->ctx,
+						   &inst->work_bufs[i]);
+			if (ret) {
+				mtk_vcodec_err(inst,
+					       "cannot alloc work_bufs[%d]", i);
+				goto err_alloc;
+			}
+			memcpy(inst->work_bufs[i].va, tmp_va, wb[i].size);
+		}
+		wb[i].iova = inst->work_bufs[i].dma_addr;
+
+		mtk_vcodec_debug(inst,
+				 "work_bufs[%d] va=0x%p,iova=0x%p,size=0x%lx",
+				 i, inst->work_bufs[i].va,
+				 (void *)inst->work_bufs[i].dma_addr,
+				 inst->work_bufs[i].size);
+	}
+
+	if (enc_param->input_fourcc == VENC_YUV_FORMAT_NV12 ||
+	    enc_param->input_fourcc == VENC_YUV_FORMAT_NV21) {
+		enc_param->sizeimage[0] =
+			inst->work_bufs[VENC_VP8_VPU_WORK_BUF_SRC_LUMA].size;
+		enc_param->sizeimage[1] =
+			inst->work_bufs[VENC_VP8_VPU_WORK_BUF_SRC_CHROMA].size;
+		enc_param->sizeimage[2] = 0;
+	} else {
+		enc_param->sizeimage[0] =
+			inst->work_bufs[VENC_VP8_VPU_WORK_BUF_SRC_LUMA].size;
+		enc_param->sizeimage[1] =
+			inst->work_bufs[VENC_VP8_VPU_WORK_BUF_SRC_CHROMA_CB].size;
+		enc_param->sizeimage[2] =
+			inst->work_bufs[VENC_VP8_VPU_WORK_BUF_SRC_CHROMA_CR].size;
+	}
+	mtk_vcodec_debug_leave(inst);
+
+	return ret;
+
+err_alloc:
+	vp8_enc_free_work_buf(inst);
+
+	return ret;
+}
+
+static unsigned int vp8_enc_wait_venc_done(struct venc_vp8_inst *inst)
+{
+	unsigned int irq_status = 0;
+	struct mtk_vcodec_ctx *ctx = (struct mtk_vcodec_ctx *)inst->ctx;
+
+	mtk_vcodec_wait_for_done_ctx(ctx, MTK_INST_IRQ_RECEIVED,
+				     WAIT_INTR_TIMEOUT, true);
+	irq_status = ctx->irq_status;
+	mtk_vcodec_debug(inst, "isr return %x", irq_status);
+
+	return irq_status;
+}
+
+/*
+ * Compose ac_tag, bitstream header and bitstream payload into
+ * one bitstream buffer.
+ */
+static int vp8_enc_compose_one_frame(struct venc_vp8_inst *inst,
+				     struct mtk_vcodec_mem *bs_buf,
+				     unsigned int *bs_size)
+{
+	unsigned int is_key;
+	u32 bs_size_frm;
+	u32 bs_hdr_len;
+	unsigned int ac_tag_sz;
+	u8 ac_tag[MAX_AC_TAG_SZ];
+
+	bs_size_frm = vp8_enc_read_reg(inst,
+				       VENC_PIC_BITSTREAM_BYTE_CNT);
+	bs_hdr_len = vp8_enc_read_reg(inst,
+				      VENC_PIC_BITSTREAM_BYTE_CNT1);
+
+	/* if a frame is key frame, is_key is 0 */
+	is_key = !inst->is_key_frm;
+	*(u32 *)ac_tag = __cpu_to_le32((bs_hdr_len << 5) | 0x10 | is_key);
+	/* key frame */
+	if (is_key == 0) {
+		ac_tag[3] = 0x9d;
+		ac_tag[4] = 0x01;
+		ac_tag[5] = 0x2a;
+		ac_tag[6] = inst->vpu_inst.drv->config.pic_w;
+		ac_tag[7] = inst->vpu_inst.drv->config.pic_w >> 8;
+		ac_tag[8] = inst->vpu_inst.drv->config.pic_h;
+		ac_tag[9] = inst->vpu_inst.drv->config.pic_h >> 8;
+	}
+
+	if (is_key == 0)
+		ac_tag_sz = MAX_AC_TAG_SZ;
+	else
+		ac_tag_sz = 3;
+
+	if (bs_buf->size <= bs_hdr_len + bs_size_frm + ac_tag_sz) {
+		mtk_vcodec_err(inst, "bitstream buf size is too small(%ld)",
+			       bs_buf->size);
+		return -EINVAL;
+	}
+
+	/*
+	* (1) The vp8 bitstream header and body are generated by the HW vp8
+	* encoder separately at the same time. We cannot know the bitstream
+	* header length in advance.
+	* (2) From the vp8 spec, there is no stuffing byte allowed between the
+	* ac tag, bitstream header and bitstream body.
+	*/
+	memmove(bs_buf->va + bs_hdr_len + ac_tag_sz,
+		bs_buf->va, bs_size_frm);
+	memcpy(bs_buf->va + ac_tag_sz,
+	       inst->work_bufs[VENC_VP8_VPU_WORK_BUF_BS_HD].va,
+	       bs_hdr_len);
+	memcpy(bs_buf->va, ac_tag, ac_tag_sz);
+	*bs_size = bs_size_frm + bs_hdr_len + ac_tag_sz;
+
+	return 0;
+}
+
+static int vp8_enc_encode_frame(struct venc_vp8_inst *inst,
+				struct venc_frm_buf *frm_buf,
+				struct mtk_vcodec_mem *bs_buf,
+				unsigned int *bs_size)
+{
+	int ret = 0;
+	unsigned int irq_status;
+
+	mtk_vcodec_debug(inst, "->frm_cnt=%d", inst->frm_cnt);
+
+	ret = vp8_enc_vpu_encode(inst, frm_buf, bs_buf);
+	if (ret)
+		return ret;
+
+	irq_status = vp8_enc_wait_venc_done(inst);
+	if (irq_status != VENC_IRQ_STATUS_ENC_FRM_INT) {
+		mtk_vcodec_err(inst, "irq_status=%d failed", irq_status);
+		return -EINVAL;
+	}
+
+	if (vp8_enc_compose_one_frame(inst, bs_buf, bs_size)) {
+		mtk_vcodec_err(inst, "vp8_enc_compose_one_frame failed");
+		return -EINVAL;
+	}
+
+	inst->frm_cnt++;
+	mtk_vcodec_debug(inst, "<-size=%d key_frm=%d", *bs_size,
+			 inst->is_key_frm);
+
+	return ret;
+}
+
+static int vp8_enc_init(struct mtk_vcodec_ctx *ctx, unsigned long *handle)
+{
+	int ret = 0;
+	struct venc_vp8_inst *inst;
+
+	inst = kzalloc(sizeof(*inst), GFP_KERNEL);
+	if (!inst)
+		return -ENOMEM;
+
+	inst->ctx = ctx;
+	inst->dev = mtk_vcodec_get_plat_dev(ctx);
+	inst->hw_base = mtk_vcodec_get_reg_addr(inst->ctx, VENC_LT_SYS);
+
+	mtk_vcodec_debug_enter(inst);
+	ret = vp8_enc_vpu_init(inst);
+	if (ret)
+		kfree(inst);
+	else
+		(*handle) = (unsigned long)inst;
+
+	mtk_vcodec_debug_leave(inst);
+
+	return ret;
+}
+
+static int vp8_enc_encode(unsigned long handle,
+			  enum venc_start_opt opt,
+			  struct venc_frm_buf *frm_buf,
+			  struct mtk_vcodec_mem *bs_buf,
+			  struct venc_done_result *result)
+{
+	int ret = 0;
+	struct venc_vp8_inst *inst = (struct venc_vp8_inst *)handle;
+	struct mtk_vcodec_ctx *ctx = inst->ctx;
+
+	mtk_vcodec_debug_enter(inst);
+
+	enable_irq(ctx->dev->enc_lt_irq);
+
+	switch (opt) {
+	case VENC_START_OPT_ENCODE_FRAME:
+		ret = vp8_enc_encode_frame(inst, frm_buf, bs_buf,
+					   &result->bs_size);
+		if (ret)
+			goto encode_err;
+		result->is_key_frm = inst->is_key_frm;
+		break;
+
+	default:
+		mtk_vcodec_err(inst, "opt not support:%d", opt);
+		ret = -EINVAL;
+		break;
+	}
+
+encode_err:
+	if (ret)
+		result->msg = VENC_MESSAGE_ERR;
+	else
+		result->msg = VENC_MESSAGE_OK;
+
+	disable_irq(ctx->dev->enc_lt_irq);
+	mtk_vcodec_debug_leave(inst);
+
+	return ret;
+}
+
+static int vp8_enc_set_param(unsigned long handle,
+			     enum venc_set_param_type type, void *in)
+{
+	int ret = 0;
+	struct venc_vp8_inst *inst = (struct venc_vp8_inst *)handle;
+	struct venc_enc_prm *enc_prm;
+
+	mtk_vcodec_debug(inst, "->type=%d", type);
+
+	switch (type) {
+	case VENC_SET_PARAM_ENC:
+		enc_prm = in;
+		ret = vp8_enc_vpu_set_param(inst, type, enc_prm);
+		if (ret)
+			break;
+		if (inst->work_buf_allocated == 1) {
+			vp8_enc_free_work_buf(inst);
+			inst->work_buf_allocated = 0;
+		}
+		if (inst->work_buf_allocated == 0) {
+			ret = vp8_enc_alloc_work_buf(inst, enc_prm);
+			if (ret)
+				break;
+			inst->work_buf_allocated = 1;
+		}
+		break;
+
+	case VENC_SET_PARAM_FORCE_INTRA:
+		ret = vp8_enc_vpu_set_param(inst, type, 0);
+		break;
+
+	case VENC_SET_PARAM_ADJUST_BITRATE:
+		enc_prm = in;
+		ret = vp8_enc_vpu_set_param(inst, type, &enc_prm->bitrate);
+		break;
+
+	case VENC_SET_PARAM_ADJUST_FRAMERATE:
+		enc_prm = in;
+		ret = vp8_enc_vpu_set_param(inst, type, &enc_prm->frm_rate);
+		break;
+
+	case VENC_SET_PARAM_I_FRAME_INTERVAL:
+		ret = vp8_enc_vpu_set_param(inst, type, in);
+		break;
+
+	/*
+	 * VENC_SET_PARAM_TS_MODE must be called before
+	 * VENC_SET_PARAM_ENC
+	 */
+	case VENC_SET_PARAM_TS_MODE:
+		inst->ts_mode = 1;
+		mtk_vcodec_debug(inst, "set ts_mode");
+		break;
+
+	default:
+		mtk_vcodec_err(inst, "type not support:%d", type);
+		ret = -EINVAL;
+		break;
+	}
+
+	mtk_vcodec_debug_leave(inst);
+
+	return ret;
+}
+
+static int vp8_enc_deinit(unsigned long handle)
+{
+	int ret = 0;
+	struct venc_vp8_inst *inst = (struct venc_vp8_inst *)handle;
+
+	mtk_vcodec_debug_enter(inst);
+
+	ret = vp8_enc_vpu_deinit(inst);
+
+	if (inst->work_buf_allocated)
+		vp8_enc_free_work_buf(inst);
+
+	mtk_vcodec_debug_leave(inst);
+	kfree(inst);
+
+	return ret;
+}
+
+static struct venc_common_if venc_vp8_if = {
+	vp8_enc_init,
+	vp8_enc_encode,
+	vp8_enc_set_param,
+	vp8_enc_deinit,
+};
+
+struct venc_common_if *get_vp8_enc_comm_if(void)
+{
+	return &venc_vp8_if;
+}
diff --git a/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.h b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.h
new file mode 100644
index 0000000..61e73f5
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.h
@@ -0,0 +1,152 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#ifndef _VENC_VP8_IF_H_
+#define _VENC_VP8_IF_H_
+
+#include "venc_drv_base.h"
+
+/**
+ * enum venc_vp8_vpu_work_buf - vp8 encoder buffer index
+ */
+enum venc_vp8_vpu_work_buf {
+	VENC_VP8_VPU_WORK_BUF_LUMA,
+	VENC_VP8_VPU_WORK_BUF_LUMA2,
+	VENC_VP8_VPU_WORK_BUF_LUMA3,
+	VENC_VP8_VPU_WORK_BUF_CHROMA,
+	VENC_VP8_VPU_WORK_BUF_CHROMA2,
+	VENC_VP8_VPU_WORK_BUF_CHROMA3,
+	VENC_VP8_VPU_WORK_BUF_MV_INFO,
+	VENC_VP8_VPU_WORK_BUF_BS_HD,
+	VENC_VP8_VPU_WORK_BUF_PROB_BUF,
+	VENC_VP8_VPU_WORK_BUF_RC_INFO,
+	VENC_VP8_VPU_WORK_BUF_RC_CODE,
+	VENC_VP8_VPU_WORK_BUF_RC_CODE2,
+	VENC_VP8_VPU_WORK_BUF_RC_CODE3,
+	VENC_VP8_VPU_WORK_BUF_SRC_LUMA,
+	VENC_VP8_VPU_WORK_BUF_SRC_CHROMA,
+	VENC_VP8_VPU_WORK_BUF_SRC_CHROMA_CB,
+	VENC_VP8_VPU_WORK_BUF_SRC_CHROMA_CR,
+	VENC_VP8_VPU_WORK_BUF_MAX,
+};
+
+/*
+ * struct venc_vp8_vpu_config - Structure for vp8 encoder configuration
+ * @input_fourcc: input fourcc
+ * @bitrate: target bitrate (in bps)
+ * @pic_w: picture width. Picture size is visible stream resolution, in pixels,
+ *         to be used for display purposes; must be smaller or equal to buffer
+ *         size.
+ * @pic_h: picture height
+ * @buf_w: buffer width (with 16 alignment). Buffer size is stream resolution
+ *         in pixels aligned to hardware requirements.
+ * @buf_h: buffer height (with 16 alignment)
+ * @intra_period: intra frame period
+ * @framerate: frame rate
+ * @ts_mode: temporal scalability mode (0: disable, 1: enable)
+ *	     support three temporal layers - 0: 7.5fps 1: 7.5fps 2: 15fps.
+ */
+struct venc_vp8_vpu_config {
+	u32 input_fourcc;
+	u32 bitrate;
+	u32 pic_w;
+	u32 pic_h;
+	u32 buf_w;
+	u32 buf_h;
+	u32 intra_period;
+	u32 framerate;
+	u32 ts_mode;
+};
+
+/*
+ * struct venc_vp8_vpu_buf -Structure for buffer information
+ * @align: buffer alignment (in bytes)
+ * @iova: IO virtual address
+ * @vpua: VPU side memory addr which is used by RC_CODE
+ * @size: buffer size (in bytes)
+ */
+struct venc_vp8_vpu_buf {
+	u32 align;
+	u32 iova;
+	u32 vpua;
+	u32 size;
+};
+
+/*
+ * struct venc_vp8_vpu_drv - Structure for VPU driver control and info share
+ * This structure is allocated in VPU side and shared to AP side.
+ * @config: vp8 encoder configuration
+ * @work_bufs: working buffer information in VPU side
+ * The work_bufs here is for storing the 'size' info shared to AP side.
+ * The similar item in struct venc_vp8_inst is for memory allocation
+ * in AP side. The AP driver will copy the 'size' from here to the one in
+ * struct mtk_vcodec_mem, then invoke mtk_vcodec_mem_alloc to allocate
+ * the buffer. After that, bypass the 'dma_addr' to the 'iova' field here for
+ * register setting in VPU side.
+ */
+struct venc_vp8_vpu_drv {
+	struct venc_vp8_vpu_config config;
+	struct venc_vp8_vpu_buf work_bufs[VENC_VP8_VPU_WORK_BUF_MAX];
+};
+
+/*
+ * struct venc_vp8_vpu_inst - vp8 encoder VPU driver instance
+ * @wq_hd: wait queue used for vpu cmd trigger then wait vpu interrupt done
+ * @signaled: flag used for checking vpu interrupt done
+ * @failure: flag to show vpu cmd succeeds or not
+ * @state: enum venc_ipi_msg_enc_state
+ * @id: VPU instance id
+ * @drv: driver structure allocated by VPU side and shared to AP side for
+ *	 control and info share
+ */
+struct venc_vp8_vpu_inst {
+	wait_queue_head_t wq_hd;
+	int signaled;
+	int failure;
+	int state;
+	unsigned int id;
+	struct venc_vp8_vpu_drv *drv;
+};
+
+/*
+ * struct venc_vp8_inst - vp8 encoder AP driver instance
+ * @hw_base: vp8 encoder hardware register base
+ * @work_bufs: working buffer
+ * @work_buf_allocated: working buffer allocated flag
+ * @frm_cnt: encoded frame count, it's used for I-frame judgement and
+ *	     reset when force intra cmd received.
+ * @ts_mode: temporal scalability mode (0: disable, 1: enable)
+ *	     support three temporal layers - 0: 7.5fps 1: 7.5fps 2: 15fps.
+ * @is_key_frm: key frame flag
+ * @vpu_inst: VPU instance to exchange information between AP and VPU
+ * @ctx: context for v4l2 layer integration
+ * @dev: device for v4l2 layer integration
+ */
+struct venc_vp8_inst {
+	void __iomem *hw_base;
+	struct mtk_vcodec_mem work_bufs[VENC_VP8_VPU_WORK_BUF_MAX];
+	bool work_buf_allocated;
+	unsigned int frm_cnt;
+	unsigned int ts_mode;
+	unsigned int is_key_frm;
+	struct venc_vp8_vpu_inst vpu_inst;
+	void *ctx;
+	struct platform_device *dev;
+};
+
+struct venc_common_if *get_vp8_enc_comm_if(void);
+
+#endif
diff --git a/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c
new file mode 100644
index 0000000..5e987aa
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c
@@ -0,0 +1,240 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#include "mtk_vpu.h"
+
+#include "venc_vp8_if.h"
+#include "venc_vp8_vpu.h"
+#include "venc_ipi_msg.h"
+
+static void handle_vp8_enc_init_msg(struct venc_vp8_inst *inst, void *data)
+{
+	struct venc_vpu_ipi_msg_init *msg = data;
+
+	inst->vpu_inst.id = msg->inst_id;
+	inst->vpu_inst.drv = (struct venc_vp8_vpu_drv *)
+		vpu_mapping_dm_addr(inst->dev, msg->inst_id);
+}
+
+static void handle_vp8_enc_encode_msg(struct venc_vp8_inst *inst, void *data)
+{
+	struct venc_vpu_ipi_msg_enc *msg = data;
+
+	inst->vpu_inst.state = msg->state;
+	inst->is_key_frm = msg->key_frame;
+}
+
+static void vp8_enc_vpu_ipi_handler(void *data, unsigned int len, void *priv)
+{
+	struct venc_vpu_ipi_msg_common *msg = data;
+	struct venc_vp8_inst *inst = (struct venc_vp8_inst *)msg->venc_inst;
+
+	mtk_vcodec_debug(inst, "->msg_id=%x inst=%p status=%d",
+			 msg->msg_id, inst, msg->status);
+
+	switch (msg->msg_id) {
+	case VPU_IPIMSG_VP8_ENC_INIT_DONE:
+		handle_vp8_enc_init_msg(inst, data);
+		break;
+	case VPU_IPIMSG_VP8_ENC_SET_PARAM_DONE:
+		break;
+	case VPU_IPIMSG_VP8_ENC_ENCODE_DONE:
+		handle_vp8_enc_encode_msg(inst, data);
+		break;
+	case VPU_IPIMSG_VP8_ENC_DEINIT_DONE:
+		break;
+	default:
+		mtk_vcodec_err(inst, "unknown msg id=%x", msg->msg_id);
+		break;
+	}
+
+	inst->vpu_inst.signaled = 1;
+	inst->vpu_inst.failure = (msg->status != VENC_IPI_MSG_STATUS_OK);
+
+	mtk_vcodec_debug_leave(inst);
+}
+
+static int vp8_enc_vpu_send_msg(struct venc_vp8_inst *inst, void *msg,
+				int len)
+{
+	int status;
+
+	mtk_vcodec_debug_enter(inst);
+	status = vpu_ipi_send(inst->dev, IPI_VENC_VP8, (void *)msg, len);
+	if (status) {
+		mtk_vcodec_err(inst,
+			       "vpu_ipi_send msg_id=%x len=%d failed status=%d",
+			       *(unsigned int *)msg, len, status);
+		return -EINVAL;
+	}
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
+
+int vp8_enc_vpu_init(struct venc_vp8_inst *inst)
+{
+	int status;
+	struct venc_ap_ipi_msg_init out;
+
+	mtk_vcodec_debug_enter(inst);
+
+	init_waitqueue_head(&inst->vpu_inst.wq_hd);
+	inst->vpu_inst.signaled = 0;
+	inst->vpu_inst.failure = 0;
+
+	status = vpu_ipi_register(inst->dev, IPI_VENC_VP8,
+				  vp8_enc_vpu_ipi_handler,
+				  "vp8_enc", NULL);
+	if (status) {
+		mtk_vcodec_err(inst,
+			       "vpu_ipi_register failed status=%d", status);
+		return -EINVAL;
+	}
+
+	out.msg_id = AP_IPIMSG_VP8_ENC_INIT;
+	out.venc_inst = (unsigned long)inst;
+	if (vp8_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst, "AP_IPIMSG_VP8_ENC_INIT failed");
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
+
+int vp8_enc_vpu_set_param(struct venc_vp8_inst *inst, unsigned int id,
+			  void *param)
+{
+	struct venc_ap_ipi_msg_set_param out;
+
+	mtk_vcodec_debug_enter(inst);
+
+	out.msg_id = AP_IPIMSG_VP8_ENC_SET_PARAM;
+	out.inst_id = inst->vpu_inst.id;
+	out.param_id = id;
+	switch (id) {
+	case VENC_SET_PARAM_ENC: {
+		struct venc_enc_prm *enc_param = (struct venc_enc_prm *)param;
+
+		inst->vpu_inst.drv->config.input_fourcc =
+			enc_param->input_fourcc;
+		inst->vpu_inst.drv->config.bitrate = enc_param->bitrate;
+		inst->vpu_inst.drv->config.pic_w = enc_param->width;
+		inst->vpu_inst.drv->config.pic_h = enc_param->height;
+		inst->vpu_inst.drv->config.buf_w = enc_param->buf_width;
+		inst->vpu_inst.drv->config.buf_h = enc_param->buf_height;
+		inst->vpu_inst.drv->config.intra_period =
+			enc_param->intra_period;
+		inst->vpu_inst.drv->config.framerate = enc_param->frm_rate;
+		inst->vpu_inst.drv->config.ts_mode = inst->ts_mode;
+		out.data_item = 0;
+		break;
+	}
+	case VENC_SET_PARAM_FORCE_INTRA:
+		out.data_item = 0;
+		break;
+	case VENC_SET_PARAM_ADJUST_BITRATE:
+		out.data_item = 1;
+		out.data[0] = *(unsigned int *)param;
+		break;
+	case VENC_SET_PARAM_ADJUST_FRAMERATE:
+		out.data_item = 1;
+		out.data[0] = *(unsigned int *)param;
+		break;
+	case VENC_SET_PARAM_I_FRAME_INTERVAL:
+		out.data_item = 1;
+		out.data[0] = *(unsigned int *)param;
+		break;
+	}
+	if (vp8_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst, "AP_IPIMSG_VP8_ENC_SET_PARAM failed");
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
+
+int vp8_enc_vpu_encode(struct venc_vp8_inst *inst,
+		       struct venc_frm_buf *frm_buf,
+		       struct mtk_vcodec_mem *bs_buf)
+{
+	struct venc_ap_ipi_msg_enc out;
+
+	mtk_vcodec_debug_enter(inst);
+
+	out.msg_id = AP_IPIMSG_VP8_ENC_ENCODE;
+	out.inst_id = inst->vpu_inst.id;
+	if (frm_buf) {
+		if ((frm_buf->fb_addr.dma_addr % 16 == 0) &&
+		    (frm_buf->fb_addr1.dma_addr % 16 == 0) &&
+		    (frm_buf->fb_addr2.dma_addr % 16 == 0)) {
+			out.input_addr[0] = frm_buf->fb_addr.dma_addr;
+			out.input_addr[1] = frm_buf->fb_addr1.dma_addr;
+			out.input_addr[2] = frm_buf->fb_addr2.dma_addr;
+		} else {
+			mtk_vcodec_err(inst, "dma_addr not align to 16");
+			return -EINVAL;
+		}
+	} else {
+		out.input_addr[0] = 0;
+		out.input_addr[1] = 0;
+		out.input_addr[2] = 0;
+	}
+	if (bs_buf) {
+		out.bs_addr = bs_buf->dma_addr;
+		out.bs_size = bs_buf->size;
+	} else {
+		out.bs_addr = 0;
+		out.bs_size = 0;
+	}
+	if (vp8_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst, "AP_IPIMSG_VP8_ENC_ENCODE failed");
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug(inst, "state=%d key_frm=%d",
+			 inst->vpu_inst.state, inst->is_key_frm);
+
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
+
+int vp8_enc_vpu_deinit(struct venc_vp8_inst *inst)
+{
+	struct venc_ap_ipi_msg_deinit out;
+
+	mtk_vcodec_debug_enter(inst);
+
+	out.msg_id = AP_IPIMSG_VP8_ENC_DEINIT;
+	out.inst_id = inst->vpu_inst.id;
+	if (vp8_enc_vpu_send_msg(inst, &out, sizeof(out)) ||
+	    inst->vpu_inst.failure) {
+		mtk_vcodec_err(inst, "AP_IPIMSG_VP8_ENC_DEINIT failed");
+		return -EINVAL;
+	}
+
+	mtk_vcodec_debug_leave(inst);
+
+	return 0;
+}
diff --git a/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h
new file mode 100644
index 0000000..482823d
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h
@@ -0,0 +1,28 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Daniel Hsiao <daniel.hsiao at mediatek.com>
+ *         PoChun Lin <pochun.lin at mediatek.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.
+ */
+
+#ifndef _VENC_VP8_VPU_H_
+#define _VENC_VP8_VPU_H_
+
+int vp8_enc_vpu_init(struct venc_vp8_inst *inst);
+int vp8_enc_vpu_set_param(struct venc_vp8_inst *inst, unsigned int id,
+			  void *param);
+int vp8_enc_vpu_encode(struct venc_vp8_inst *inst,
+		       struct venc_frm_buf *frm_buf,
+		       struct mtk_vcodec_mem *bs_buf);
+int vp8_enc_vpu_deinit(struct venc_vp8_inst *inst);
+
+#endif
-- 
1.7.9.5



From tiffany.lin at mediatek.com  Tue Feb 23 00:11:15 2016
From: tiffany.lin at mediatek.com (Tiffany Lin)
Date: Tue, 23 Feb 2016 16:11:15 +0800
Subject: [PATCH v5 2/8] [media] VPU: mediatek: support Mediatek VPU
In-Reply-To: <1456215081-16858-2-git-send-email-tiffany.lin@mediatek.com>
References: <1456215081-16858-1-git-send-email-tiffany.lin@mediatek.com>
 <1456215081-16858-2-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <1456215081-16858-3-git-send-email-tiffany.lin@mediatek.com>

From: Andrew-CT Chen <andrew-ct.chen at mediatek.com>

The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
It is able to handle video decoding/encoding of in a range of formats.
The driver provides with VPU firmware download, memory management and
the communication interface between CPU and VPU.
For VPU initialization, it will create virtual memory for CPU access and
IOMMU address for vcodec hw device access. When a decode/encode instance
opens a device node, vpu driver will download vpu firmware to the device.
A decode/encode instant will decode/encode a frame using VPU
interface to interrupt vpu to handle decoding/encoding jobs.

Signed-off-by: Andrew-CT Chen <andrew-ct.chen at mediatek.com>
Signed-off-by: Tiffany Lin <tiffany.lin at mediatek.com>
---
 drivers/media/platform/Kconfig           |   12 +
 drivers/media/platform/Makefile          |    2 +
 drivers/media/platform/mtk-vpu/Makefile  |    1 +
 drivers/media/platform/mtk-vpu/mtk_vpu.c |  949 ++++++++++++++++++++++++++++++
 drivers/media/platform/mtk-vpu/mtk_vpu.h |  163 +++++
 5 files changed, 1127 insertions(+)
 create mode 100644 drivers/media/platform/mtk-vpu/Makefile
 create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c
 create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ccbc974..6b59dbc 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -148,6 +148,18 @@ config VIDEO_CODA
 	   Coda is a range of video codec IPs that supports
 	   H.264, MPEG-4, and other video formats.
 
+config VIDEO_MEDIATEK_VPU
+	tristate "Mediatek Video Processor Unit"
+	depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MEDIATEK
+	---help---
+	    This driver provides downloading VPU firmware and
+	    communicating with VPU. This driver for hw video
+	    codec embedded in Mediatek's MT8173 SOCs. It is able
+	    to handle video decoding/encoding in a range of formats.
+
+	    To compile this driver as a module, choose M here: the
+	    module will be called mtk-vpu.
+
 config VIDEO_MEM2MEM_DEINTERLACE
 	tristate "Deinterlace support"
 	depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index efa0295..e5b19c6 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -55,3 +55,5 @@ obj-$(CONFIG_VIDEO_AM437X_VPFE)		+= am437x/
 obj-$(CONFIG_VIDEO_XILINX)		+= xilinx/
 
 ccflags-y += -I$(srctree)/drivers/media/i2c
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VPU)	+= mtk-vpu/
diff --git a/drivers/media/platform/mtk-vpu/Makefile b/drivers/media/platform/mtk-vpu/Makefile
new file mode 100644
index 0000000..d890a66
--- /dev/null
+++ b/drivers/media/platform/mtk-vpu/Makefile
@@ -0,0 +1 @@
+obj-y += mtk_vpu.o
diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c
new file mode 100644
index 0000000..bb4867b
--- /dev/null
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
@@ -0,0 +1,949 @@
+/*
+* Copyright (c) 2016 MediaTek Inc.
+* Author: Andrew-CT Chen <andrew-ct.chen at mediatek.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.
+*/
+#include <linux/bootmem.h>
+#include <linux/clk.h>
+#include <linux/debugfs.h>
+#include <linux/firmware.h>
+#include <linux/interrupt.h>
+#include <linux/iommu.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/of_reserved_mem.h>
+#include <linux/sched.h>
+#include <linux/sizes.h>
+
+#include "mtk_vpu.h"
+
+/**
+ * VPU (video processor unit) is a tiny processor controlling video hardware
+ * related to video codec, scaling and color format converting.
+ * VPU interfaces with other blocks by share memory and interrupt.
+ **/
+
+#define INIT_TIMEOUT_MS		2000U
+#define IPI_TIMEOUT_MS		2000U
+#define VPU_FW_VER_LEN		16
+
+/* maximum program/data TCM (Tightly-Coupled Memory) size */
+#define VPU_PTCM_SIZE		(96 * SZ_1K)
+#define VPU_DTCM_SIZE		(32 * SZ_1K)
+/* the offset to get data tcm address */
+#define VPU_DTCM_OFFSET		0x18000UL
+/* daynamic allocated maximum extended memory size */
+#define VPU_EXT_P_SIZE		SZ_1M
+#define VPU_EXT_D_SIZE		SZ_4M
+/* maximum binary firmware size */
+#define VPU_P_FW_SIZE		(VPU_PTCM_SIZE + VPU_EXT_P_SIZE)
+#define VPU_D_FW_SIZE		(VPU_DTCM_SIZE + VPU_EXT_D_SIZE)
+/* the size of share buffer between Host and  VPU */
+#define SHARE_BUF_SIZE		48
+
+/* binary firmware name */
+#define VPU_P_FW		"vpu_p.bin"
+#define VPU_D_FW		"vpu_d.bin"
+
+#define VPU_RESET		0x0
+#define VPU_TCM_CFG		0x0008
+#define VPU_PMEM_EXT0_ADDR	0x000C
+#define VPU_PMEM_EXT1_ADDR	0x0010
+#define VPU_TO_HOST		0x001C
+#define VPU_DMEM_EXT0_ADDR	0x0014
+#define VPU_DMEM_EXT1_ADDR	0x0018
+#define HOST_TO_VPU		0x0024
+#define VPU_PC_REG		0x0060
+#define VPU_WDT_REG		0x0084
+
+/* vpu inter-processor communication interrupt */
+#define VPU_IPC_INT		BIT(8)
+
+/**
+ * enum vpu_fw_type - VPU firmware type
+ *
+ * @P_FW: program firmware
+ * @D_FW: data firmware
+ *
+ */
+enum vpu_fw_type {
+	P_FW,
+	D_FW,
+};
+
+/**
+ * struct vpu_mem - VPU extended program/data memory information
+ *
+ * @va:		the kernel virtual memory address of VPU extended memory
+ * @pa:		the physical memory address of VPU extended memory
+ *
+ */
+struct vpu_mem {
+	void *va;
+	phys_addr_t pa;
+};
+
+/**
+ * struct vpu_regs - VPU TCM and configuration registers
+ *
+ * @tcm:	the register for VPU Tightly-Coupled Memory
+ * @cfg:	the register for VPU configuration
+ * @irq:	the irq number for VPU interrupt
+ */
+struct vpu_regs {
+	void __iomem *tcm;
+	void __iomem *cfg;
+	int irq;
+};
+
+/**
+ * struct vpu_wdt_handler - VPU watchdog reset handler
+ *
+ * @reset_func:	reset handler
+ * @priv:	private data
+ */
+struct vpu_wdt_handler {
+	void (*reset_func)(void *);
+	void *priv;
+};
+
+/**
+ * struct vpu_wdt - VPU watchdog workqueue
+ *
+ * @handler:	VPU watchdog reset handler
+ * @ws:		workstruct for VPU watchdog
+ * @wq:		workqueue for VPU watchdog
+ */
+struct vpu_wdt {
+	struct vpu_wdt_handler handler[VPU_RST_MAX];
+	struct work_struct ws;
+	struct workqueue_struct *wq;
+};
+
+/**
+ * struct vpu_run - VPU initialization status
+ *
+ * @signaled:		the signal of vpu initialization completed
+ * @fw_ver:		VPU firmware version
+ * @enc_capability:	encoder capability which is not used for now and
+ *			the value is reserved for future use
+ * @wq:			wait queue for VPU initialization status
+ */
+struct vpu_run {
+	u32 signaled;
+	char fw_ver[VPU_FW_VER_LEN];
+	unsigned int	enc_capability;
+	wait_queue_head_t wq;
+};
+
+/**
+ * struct vpu_ipi_desc - VPU IPI descriptor
+ *
+ * @handler:	IPI handler
+ * @name:	the name of IPI handler
+ * @priv:	the private data of IPI handler
+ */
+struct vpu_ipi_desc {
+	ipi_handler_t handler;
+	const char *name;
+	void *priv;
+};
+
+/**
+ * struct share_obj - DTCM (Data Tightly-Coupled Memory) buffer shared with
+ *		      AP and VPU
+ *
+ * @id:		IPI id
+ * @len:	share buffer length
+ * @share_buf:	share buffer data
+ */
+struct share_obj {
+	s32 id;
+	u32 len;
+	unsigned char share_buf[SHARE_BUF_SIZE];
+};
+
+/**
+ * struct mtk_vpu - vpu driver data
+ * @extmem:		VPU extended memory information
+ * @reg:		VPU TCM and configuration registers
+ * @run:		VPU initialization status
+ * @ipi_desc:		VPU IPI descriptor
+ * @recv_buf:		VPU DTCM share buffer for receiving. The
+ *			receive buffer is only accessed in interrupt context.
+ * @send_buf:		VPU DTCM share buffer for sending
+ * @dev:		VPU struct device
+ * @clk:		VPU clock on/off
+ * @enable_4GB:		VPU 4GB mode on/off
+ * @vpu_mutex:		protect mtk_vpu (except recv_buf) and ensure only
+ *			one client to use VPU service at a time. For example,
+ *			suppose a client is using VPU to decode VP8.
+ *			If the other client wants to encode VP8,
+ *			it has to wait until VP8 decode completes.
+ * @wdt_refcnt		WDT reference count to make sure the watchdog can be
+ *			disabled if no other client is using VPU service
+ * @ack_wq:		The wait queue for each codec and mdp. When sleeping
+ *			processes wake up, they will check the condition
+ *			"ipi_id_ack" to run the corresponding action or
+ *			go back to sleep.
+ * @ipi_id_ack:		The ACKs for registered IPI function sending
+ *			interrupt to VPU
+ *
+ */
+struct mtk_vpu {
+	struct vpu_mem extmem[2];
+	struct vpu_regs reg;
+	struct vpu_run run;
+	struct vpu_wdt wdt;
+	struct vpu_ipi_desc ipi_desc[IPI_MAX];
+	struct share_obj *recv_buf;
+	struct share_obj *send_buf;
+	struct device *dev;
+	struct clk *clk;
+	bool enable_4GB;
+	struct mutex vpu_mutex; /* for protecting vpu data data structure */
+	u32 wdt_refcnt;
+	wait_queue_head_t ack_wq;
+	bool ipi_id_ack[IPI_MAX];
+};
+
+static inline void vpu_cfg_writel(struct mtk_vpu *vpu, u32 val, u32 offset)
+{
+	writel(val, vpu->reg.cfg + offset);
+}
+
+static inline u32 vpu_cfg_readl(struct mtk_vpu *vpu, u32 offset)
+{
+	return readl(vpu->reg.cfg + offset);
+}
+
+static inline bool vpu_running(struct mtk_vpu *vpu)
+{
+	return vpu_cfg_readl(vpu, VPU_RESET) & BIT(0);
+}
+
+void vpu_clock_disable(struct mtk_vpu *vpu)
+{
+	/* Disable VPU watchdog */
+	mutex_lock(&vpu->vpu_mutex);
+	if (!--vpu->wdt_refcnt)
+		vpu_cfg_writel(vpu,
+			       vpu_cfg_readl(vpu, VPU_WDT_REG) & ~(1L << 31),
+			       VPU_WDT_REG);
+	mutex_unlock(&vpu->vpu_mutex);
+
+	clk_disable(vpu->clk);
+}
+
+int vpu_clock_enable(struct mtk_vpu *vpu)
+{
+	int ret;
+
+	ret = clk_enable(vpu->clk);
+	if (ret)
+		return ret;
+	/* Enable VPU watchdog */
+	mutex_lock(&vpu->vpu_mutex);
+	if (!vpu->wdt_refcnt++)
+		vpu_cfg_writel(vpu,
+			       vpu_cfg_readl(vpu, VPU_WDT_REG) | (1L << 31),
+			       VPU_WDT_REG);
+	mutex_unlock(&vpu->vpu_mutex);
+
+	return ret;
+}
+
+int vpu_ipi_register(struct platform_device *pdev,
+		     enum ipi_id id, ipi_handler_t handler,
+		     const char *name, void *priv)
+{
+	struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+	struct vpu_ipi_desc *ipi_desc;
+
+	if (!vpu) {
+		dev_err(&pdev->dev, "vpu device in not ready\n");
+		return -EPROBE_DEFER;
+	}
+
+	if (id >= 0 && id < IPI_MAX && handler) {
+		ipi_desc = vpu->ipi_desc;
+		ipi_desc[id].name = name;
+		ipi_desc[id].handler = handler;
+		ipi_desc[id].priv = priv;
+		return 0;
+	}
+
+	dev_err(&pdev->dev, "register vpu ipi id %d with invalid arguments\n",
+		id);
+	return -EINVAL;
+}
+
+int vpu_ipi_send(struct platform_device *pdev,
+		 enum ipi_id id, void *buf,
+		 unsigned int len)
+{
+	struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+	struct share_obj *send_obj = vpu->send_buf;
+	unsigned long timeout;
+	int ret = 0;
+
+	if (id <= IPI_VPU_INIT || id >= IPI_MAX ||
+	    len > sizeof(send_obj->share_buf) || !buf) {
+		dev_err(vpu->dev, "failed to send ipi message\n");
+		return -EINVAL;
+	}
+
+	ret = vpu_clock_enable(vpu);
+	if (ret) {
+		dev_err(vpu->dev, "failed to enable vpu clock\n");
+		return ret;
+	}
+	if (!vpu_running(vpu)) {
+		dev_err(vpu->dev, "vpu_ipi_send: VPU is not running\n");
+		ret = -EINVAL;
+		goto clock_disable;
+	}
+
+	mutex_lock(&vpu->vpu_mutex);
+
+	 /* Wait until VPU receives the last command */
+	timeout = jiffies + msecs_to_jiffies(IPI_TIMEOUT_MS);
+	do {
+		if (time_after(jiffies, timeout)) {
+			dev_err(vpu->dev, "vpu_ipi_send: IPI timeout!\n");
+			ret = -EIO;
+			goto mut_unlock;
+		}
+	} while (vpu_cfg_readl(vpu, HOST_TO_VPU));
+
+	memcpy((void *)send_obj->share_buf, buf, len);
+	send_obj->len = len;
+	send_obj->id = id;
+
+	vpu->ipi_id_ack[id] = false;
+	/* send the command to VPU */
+	vpu_cfg_writel(vpu, 0x1, HOST_TO_VPU);
+
+	mutex_unlock(&vpu->vpu_mutex);
+
+	/* wait for VPU's ACK */
+	timeout = msecs_to_jiffies(IPI_TIMEOUT_MS);
+	ret = wait_event_interruptible_timeout(vpu->ack_wq,
+					       vpu->ipi_id_ack[id], timeout);
+	vpu->ipi_id_ack[id] = false;
+	if (ret == 0) {
+		dev_err(vpu->dev, "vpu ipi %d ack time out !", id);
+		ret = -EIO;
+		goto clock_disable;
+	} else if (-ERESTARTSYS == ret) {
+		dev_err(vpu->dev, "vpu ipi %d ack wait interrupted by a signal",
+			id);
+		ret = -ERESTARTSYS;
+		goto clock_disable;
+	}
+	vpu_clock_disable(vpu);
+
+	return 0;
+
+mut_unlock:
+	mutex_unlock(&vpu->vpu_mutex);
+clock_disable:
+	vpu_clock_disable(vpu);
+
+	return ret;
+}
+
+static void vpu_wdt_reset_func(struct work_struct *ws)
+{
+	struct vpu_wdt *wdt = container_of(ws, struct vpu_wdt, ws);
+	struct mtk_vpu *vpu = container_of(wdt, struct mtk_vpu, wdt);
+	struct vpu_wdt_handler *handler = wdt->handler;
+	int index, ret;
+
+	dev_info(vpu->dev, "vpu reset\n");
+	ret = vpu_clock_enable(vpu);
+	if (ret) {
+		dev_err(vpu->dev, "[VPU] wdt enables clock failed %d\n", ret);
+		return;
+	}
+	mutex_lock(&vpu->vpu_mutex);
+	vpu_cfg_writel(vpu, 0x0, VPU_RESET);
+	mutex_unlock(&vpu->vpu_mutex);
+	vpu_clock_disable(vpu);
+
+	for (index = 0; index < VPU_RST_MAX; index++) {
+		if (handler[index].reset_func) {
+			handler[index].reset_func(handler[index].priv);
+			dev_dbg(vpu->dev, "wdt handler func %d\n", index);
+		}
+	}
+}
+
+int vpu_wdt_reg_handler(struct platform_device *pdev,
+			void wdt_reset(void *),
+			void *priv, enum rst_id id)
+{
+	struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+	struct vpu_wdt_handler *handler = vpu->wdt.handler;
+
+	if (!vpu) {
+		dev_err(vpu->dev, "vpu device in not ready\n");
+		return -EPROBE_DEFER;
+	}
+
+	if (id > 0 && id < VPU_RST_MAX && wdt_reset) {
+		dev_dbg(vpu->dev, "wdt register id %d\n", id);
+		mutex_lock(&vpu->vpu_mutex);
+		handler[id].reset_func = wdt_reset;
+		handler[id].priv = priv;
+		mutex_unlock(&vpu->vpu_mutex);
+		return 0;
+	}
+
+	dev_err(vpu->dev, "register vpu wdt handler failed\n");
+	return -EINVAL;
+}
+
+unsigned int vpu_get_venc_hw_capa(struct platform_device *pdev)
+{
+	struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+
+	return vpu->run.enc_capability;
+}
+
+void *vpu_mapping_dm_addr(struct platform_device *pdev,
+			  u32 dtcm_dmem_addr)
+{
+	struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+
+	if (!dtcm_dmem_addr ||
+	    (dtcm_dmem_addr > (VPU_DTCM_SIZE + VPU_EXT_D_SIZE))) {
+		dev_err(vpu->dev, "invalid virtual data memory address\n");
+		return ERR_PTR(-EINVAL);
+	}
+
+	if (dtcm_dmem_addr < VPU_DTCM_SIZE)
+		return dtcm_dmem_addr + vpu->reg.tcm + VPU_DTCM_OFFSET;
+
+	return vpu->extmem[D_FW].va + (dtcm_dmem_addr - VPU_DTCM_SIZE);
+}
+
+struct platform_device *vpu_get_plat_device(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *vpu_node;
+	struct platform_device *vpu_pdev;
+
+	vpu_node = of_parse_phandle(dev->of_node, "mediatek,vpu", 0);
+	if (!vpu_node) {
+		dev_err(dev, "can't get vpu node\n");
+		return NULL;
+	}
+
+	vpu_pdev = of_find_device_by_node(vpu_node);
+	if (WARN_ON(!vpu_pdev)) {
+		dev_err(dev, "vpu pdev failed\n");
+		of_node_put(vpu_node);
+		return NULL;
+	}
+
+	return vpu_pdev;
+}
+
+/* load vpu program/data memory */
+static int load_requested_vpu(struct mtk_vpu *vpu,
+			      const struct firmware *vpu_fw,
+			      u8 fw_type)
+{
+	size_t tcm_size = fw_type ? VPU_DTCM_SIZE : VPU_PTCM_SIZE;
+	size_t fw_size = fw_type ? VPU_D_FW_SIZE : VPU_P_FW_SIZE;
+	char *fw_name = fw_type ? VPU_D_FW : VPU_P_FW;
+	size_t dl_size = 0;
+	size_t extra_fw_size = 0;
+	void *dest;
+	int ret;
+
+	ret = request_firmware(&vpu_fw, fw_name, vpu->dev);
+	if (ret < 0) {
+		dev_err(vpu->dev, "Failed to load %s, %d\n", fw_name, ret);
+		return ret;
+	}
+	dl_size = vpu_fw->size;
+	if (dl_size > fw_size) {
+		dev_err(vpu->dev, "fw %s size %zu is abnormal\n", fw_name,
+			dl_size);
+		release_firmware(vpu_fw);
+		return  -EFBIG;
+	}
+	dev_dbg(vpu->dev, "Downloaded fw %s size: %zu.\n",
+		fw_name,
+		dl_size);
+	/* reset VPU */
+	vpu_cfg_writel(vpu, 0x0, VPU_RESET);
+
+	/* handle extended firmware size */
+	if (dl_size > tcm_size) {
+		dev_dbg(vpu->dev, "fw size %lx > limited fw size %lx\n",
+			dl_size, tcm_size);
+		extra_fw_size = dl_size - tcm_size;
+		dev_dbg(vpu->dev, "extra_fw_size %lx\n", extra_fw_size);
+		dl_size = tcm_size;
+	}
+	dest = vpu->reg.tcm;
+	if (fw_type == D_FW)
+		dest += VPU_DTCM_OFFSET;
+	memcpy(dest, vpu_fw->data, dl_size);
+	/* download to extended memory if need */
+	if (extra_fw_size > 0) {
+		dest = vpu->extmem[fw_type].va;
+		dev_dbg(vpu->dev, "download extended memory type %x\n",
+			fw_type);
+		memcpy(dest, vpu_fw->data + tcm_size, extra_fw_size);
+	}
+
+	release_firmware(vpu_fw);
+
+	return 0;
+}
+
+int vpu_load_firmware(struct platform_device *pdev)
+{
+	struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+	struct device *dev = &pdev->dev;
+	struct vpu_run *run = &vpu->run;
+	const struct firmware *vpu_fw;
+	int ret;
+
+	if (!pdev) {
+		dev_err(dev, "VPU platform device is invalid\n");
+		return -EINVAL;
+	}
+
+	ret = vpu_clock_enable(vpu);
+	if (ret) {
+		dev_err(dev, "enable clock failed %d\n", ret);
+		return ret;
+	}
+
+	mutex_lock(&vpu->vpu_mutex);
+
+	if (vpu_running(vpu)) {
+		mutex_unlock(&vpu->vpu_mutex);
+		vpu_clock_disable(vpu);
+		dev_warn(dev, "vpu is running already\n");
+		return 0;
+	}
+
+	run->signaled = false;
+	dev_dbg(vpu->dev, "firmware request\n");
+	/* Downloading program firmware to device*/
+	ret = load_requested_vpu(vpu, vpu_fw, P_FW);
+	if (ret < 0) {
+		dev_err(dev, "Failed to request %s, %d\n", VPU_P_FW, ret);
+		goto OUT_LOAD_FW;
+	}
+
+	/* Downloading data firmware to device */
+	ret = load_requested_vpu(vpu, vpu_fw, D_FW);
+	if (ret < 0) {
+		dev_err(dev, "Failed to request %s, %d\n", VPU_D_FW, ret);
+		goto OUT_LOAD_FW;
+	}
+
+	/* boot up vpu */
+	vpu_cfg_writel(vpu, 0x1, VPU_RESET);
+
+	ret = wait_event_interruptible_timeout(run->wq,
+					       run->signaled,
+					       msecs_to_jiffies(INIT_TIMEOUT_MS)
+					       );
+	if (ret == 0) {
+		ret = -ETIME;
+		dev_err(dev, "wait vpu initialization timout!\n");
+		goto OUT_LOAD_FW;
+	} else if (-ERESTARTSYS == ret) {
+		dev_err(dev, "wait vpu interrupted by a signal!\n");
+		goto OUT_LOAD_FW;
+	}
+
+	ret = 0;
+	dev_info(dev, "vpu is ready. Fw version %s\n", run->fw_ver);
+
+OUT_LOAD_FW:
+	mutex_unlock(&vpu->vpu_mutex);
+	vpu_clock_disable(vpu);
+
+	return ret;
+}
+
+static void vpu_init_ipi_handler(void *data, unsigned int len, void *priv)
+{
+	struct mtk_vpu *vpu = (struct mtk_vpu *)priv;
+	struct vpu_run *run = (struct vpu_run *)data;
+
+	vpu->run.signaled = run->signaled;
+	strncpy(vpu->run.fw_ver, run->fw_ver, VPU_FW_VER_LEN);
+	vpu->run.enc_capability = run->enc_capability;
+	wake_up_interruptible(&vpu->run.wq);
+}
+
+#ifdef CONFIG_DEBUG_FS
+static int vpu_debug_open(struct inode *inode, struct file *file)
+{
+	file->private_data = inode->i_private;
+	return 0;
+}
+
+static ssize_t vpu_debug_read(struct file *file, char __user *user_buf,
+			      size_t count, loff_t *ppos)
+{
+	char buf[256];
+	unsigned int len;
+	unsigned int running, pc, vpu_to_host, host_to_vpu, wdt;
+	int ret;
+	struct device *dev = file->private_data;
+	struct mtk_vpu *vpu = dev_get_drvdata(dev);
+
+	ret = vpu_clock_enable(vpu);
+	if (ret) {
+		dev_err(vpu->dev, "[VPU] enable clock failed %d\n", ret);
+		return 0;
+	}
+
+	/* vpu register status */
+	running = vpu_running(vpu);
+	pc = vpu_cfg_readl(vpu, VPU_PC_REG);
+	wdt = vpu_cfg_readl(vpu, VPU_WDT_REG);
+	host_to_vpu = vpu_cfg_readl(vpu, HOST_TO_VPU);
+	vpu_to_host = vpu_cfg_readl(vpu, VPU_TO_HOST);
+	vpu_clock_disable(vpu);
+
+	if (running) {
+		len = snprintf(buf, sizeof(buf), "VPU is running\n\n"
+		"FW Version: %s\n"
+		"PC: 0x%x\n"
+		"WDT: 0x%x\n"
+		"Host to VPU: 0x%x\n"
+		"VPU to Host: 0x%x\n",
+		vpu->run.fw_ver, pc, wdt,
+		host_to_vpu, vpu_to_host);
+	} else {
+		len = snprintf(buf, sizeof(buf), "VPU not running\n");
+	}
+
+	return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static const struct file_operations vpu_debug_fops = {
+	.open = vpu_debug_open,
+	.read = vpu_debug_read,
+};
+#endif /* CONFIG_DEBUG_FS */
+
+static void vpu_free_ext_mem(struct mtk_vpu *vpu, u8 fw_type)
+{
+	struct device *dev = vpu->dev;
+	size_t fw_ext_size = fw_type ? VPU_EXT_D_SIZE : VPU_EXT_P_SIZE;
+
+	dma_free_coherent(dev, fw_ext_size, vpu->extmem[fw_type].va,
+			  vpu->extmem[fw_type].pa);
+}
+
+static int vpu_alloc_ext_mem(struct mtk_vpu *vpu, u32 fw_type)
+{
+	struct device *dev = vpu->dev;
+	size_t fw_ext_size = fw_type ? VPU_EXT_D_SIZE : VPU_EXT_P_SIZE;
+	u32 vpu_ext_mem0 = fw_type ? VPU_DMEM_EXT0_ADDR : VPU_PMEM_EXT0_ADDR;
+	u32 vpu_ext_mem1 = fw_type ? VPU_DMEM_EXT1_ADDR : VPU_PMEM_EXT1_ADDR;
+	u32 offset_4gb = vpu->enable_4GB ? 0x40000000 : 0;
+
+	vpu->extmem[fw_type].va = dma_alloc_coherent(dev,
+					       fw_ext_size,
+					       &vpu->extmem[fw_type].pa,
+					       GFP_KERNEL);
+	if (!vpu->extmem[fw_type].va) {
+		dev_err(dev, "Failed to allocate the extended program memory\n");
+		return PTR_ERR(vpu->extmem[fw_type].va);
+	}
+
+	/* Disable extend0. Enable extend1 */
+	vpu_cfg_writel(vpu, 0x1, vpu_ext_mem0);
+	vpu_cfg_writel(vpu, (vpu->extmem[fw_type].pa & 0xFFFFF000) + offset_4gb,
+		       vpu_ext_mem1);
+
+	dev_info(dev, "%s extend memory phy=0x%llx virt=0x%p\n",
+		 fw_type ? "Data" : "Program",
+		 (unsigned long long)vpu->extmem[fw_type].pa,
+		 vpu->extmem[fw_type].va);
+
+	return 0;
+}
+
+static void vpu_ipi_handler(struct mtk_vpu *vpu)
+{
+	struct share_obj *rcv_obj = vpu->recv_buf;
+	struct vpu_ipi_desc *ipi_desc = vpu->ipi_desc;
+
+	if (rcv_obj->id < IPI_MAX && ipi_desc[rcv_obj->id].handler) {
+		ipi_desc[rcv_obj->id].handler(rcv_obj->share_buf,
+					      rcv_obj->len,
+					      ipi_desc[rcv_obj->id].priv);
+		if (rcv_obj->id > IPI_VPU_INIT) {
+			vpu->ipi_id_ack[rcv_obj->id] = true;
+			wake_up_interruptible(&vpu->ack_wq);
+		}
+	} else {
+		dev_err(vpu->dev, "No such ipi id = %d\n", rcv_obj->id);
+	}
+}
+
+static int vpu_ipi_init(struct mtk_vpu *vpu)
+{
+	/* Disable VPU to host interrupt */
+	vpu_cfg_writel(vpu, 0x0, VPU_TO_HOST);
+
+	/* shared buffer initialization */
+	vpu->recv_buf = (struct share_obj *)(vpu->reg.tcm + VPU_DTCM_OFFSET);
+	vpu->send_buf = vpu->recv_buf + 1;
+	memset(vpu->recv_buf, 0, sizeof(struct share_obj));
+	memset(vpu->send_buf, 0, sizeof(struct share_obj));
+
+	return 0;
+}
+
+static irqreturn_t vpu_irq_handler(int irq, void *priv)
+{
+	struct mtk_vpu *vpu = priv;
+	u32 vpu_to_host;
+	int ret;
+
+	/*
+	 * Clock should have been enabled already.
+	 * Enable again in case vpu_ipi_send times out
+	 * and has disabled the clock.
+	 */
+	ret = clk_enable(vpu->clk);
+	if (ret) {
+		dev_err(vpu->dev, "[VPU] enable clock failed %d\n", ret);
+		return IRQ_NONE;
+	}
+	vpu_to_host = vpu_cfg_readl(vpu, VPU_TO_HOST);
+	if (vpu_to_host & VPU_IPC_INT) {
+		vpu_ipi_handler(vpu);
+	} else {
+		dev_err(vpu->dev, "vpu watchdog timeout! 0x%x", vpu_to_host);
+		queue_work(vpu->wdt.wq, &vpu->wdt.ws);
+	}
+
+	/* VPU won't send another interrupt until we set VPU_TO_HOST to 0. */
+	vpu_cfg_writel(vpu, 0x0, VPU_TO_HOST);
+	clk_disable(vpu->clk);
+
+	return IRQ_HANDLED;
+}
+
+#ifdef CONFIG_DEBUG_FS
+static struct dentry *vpu_debugfs;
+#endif
+static int mtk_vpu_probe(struct platform_device *pdev)
+{
+	struct mtk_vpu *vpu;
+	struct device *dev;
+	struct resource *res;
+	int ret = 0;
+
+	dev_dbg(&pdev->dev, "initialization\n");
+
+	dev = &pdev->dev;
+	vpu = devm_kzalloc(dev, sizeof(*vpu), GFP_KERNEL);
+	if (!vpu)
+		return -ENOMEM;
+
+	vpu->dev = &pdev->dev;
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "tcm");
+	vpu->reg.tcm = devm_ioremap_resource(dev, res);
+	if (IS_ERR(vpu->reg.tcm)) {
+		dev_err(dev, "devm_ioremap_resource vpu tcm failed.\n");
+		return PTR_ERR(vpu->reg.tcm);
+	}
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg_reg");
+	vpu->reg.cfg = devm_ioremap_resource(dev, res);
+	if (IS_ERR(vpu->reg.cfg)) {
+		dev_err(dev, "devm_ioremap_resource vpu cfg failed.\n");
+		return PTR_ERR(vpu->reg.cfg);
+	}
+
+	/* Get VPU clock */
+	vpu->clk = devm_clk_get(dev, "main");
+	if (!vpu->clk) {
+		dev_err(dev, "get vpu clock failed\n");
+		return -EINVAL;
+	}
+
+	platform_set_drvdata(pdev, vpu);
+
+	ret = clk_prepare(vpu->clk);
+	if (ret) {
+		dev_err(dev, "prepare vpu clock failed\n");
+		return ret;
+	}
+
+	/* VPU watchdog */
+	vpu->wdt.wq = create_singlethread_workqueue("vpu_wdt");
+	if (!vpu->wdt.wq) {
+		dev_err(dev, "initialize wdt workqueue failed\n");
+		return -ENOMEM;
+	}
+	INIT_WORK(&vpu->wdt.ws, vpu_wdt_reset_func);
+	mutex_init(&vpu->vpu_mutex);
+
+	ret = vpu_clock_enable(vpu);
+	if (ret) {
+		dev_err(dev, "enable vpu clock failed\n");
+		goto workqueue_destroy;
+	}
+
+	dev_dbg(dev, "vpu ipi init\n");
+	ret = vpu_ipi_init(vpu);
+	if (ret) {
+		dev_err(dev, "Failed to init ipi\n");
+		goto disable_vpu_clk;
+	}
+
+	/* register vpu initialization IPI */
+	ret = vpu_ipi_register(pdev, IPI_VPU_INIT, vpu_init_ipi_handler,
+			       "vpu_init", vpu);
+	if (ret) {
+		dev_err(dev, "Failed to register IPI_VPU_INIT\n");
+		goto vpu_mutex_destroy;
+	}
+
+#ifdef CONFIG_DEBUG_FS
+	vpu_debugfs = debugfs_create_file("mtk_vpu", S_IRUGO, NULL, (void *)dev,
+					  &vpu_debug_fops);
+	if (!vpu_debugfs) {
+		ret = -ENOMEM;
+		goto cleanup_ipi;
+	}
+#endif
+
+	/* Set PTCM to 96K and DTCM to 32K */
+	vpu_cfg_writel(vpu, 0x2, VPU_TCM_CFG);
+
+	vpu->enable_4GB = !!(max_pfn > (0xffffffffUL >> PAGE_SHIFT));
+	dev_dbg(dev, "4GB mode %u\n", vpu->enable_4GB);
+
+	if (vpu->enable_4GB) {
+		ret = of_reserved_mem_device_init(dev);
+		if (ret)
+			dev_info(dev, "init reserved memory failed\n");
+			/* continue to use dynamic allocation if failed */
+	}
+
+	ret = vpu_alloc_ext_mem(vpu, D_FW);
+	if (ret) {
+		dev_err(dev, "Allocate DM failed\n");
+		goto remove_debugfs;
+	}
+
+	ret = vpu_alloc_ext_mem(vpu, P_FW);
+	if (ret) {
+		dev_err(dev, "Allocate PM failed\n");
+		goto free_d_mem;
+	}
+
+	init_waitqueue_head(&vpu->run.wq);
+	init_waitqueue_head(&vpu->ack_wq);
+
+	res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+	if (!res) {
+		dev_err(dev, "get IRQ resource failed.\n");
+		ret = -ENXIO;
+		goto free_p_mem;
+	}
+	vpu->reg.irq = platform_get_irq(pdev, 0);
+	ret = devm_request_irq(dev, vpu->reg.irq, vpu_irq_handler, 0,
+			       pdev->name, vpu);
+	if (ret) {
+		dev_err(dev, "failed to request irq\n");
+		goto free_p_mem;
+	}
+
+	vpu_clock_disable(vpu);
+	dev_dbg(dev, "initialization completed\n");
+
+	return 0;
+
+free_p_mem:
+	vpu_free_ext_mem(vpu, P_FW);
+free_d_mem:
+	vpu_free_ext_mem(vpu, D_FW);
+remove_debugfs:
+	of_reserved_mem_device_release(dev);
+#ifdef CONFIG_DEBUG_FS
+	debugfs_remove(vpu_debugfs);
+cleanup_ipi:
+#endif
+	memset(vpu->ipi_desc, 0, sizeof(struct vpu_ipi_desc) * IPI_MAX);
+vpu_mutex_destroy:
+	mutex_destroy(&vpu->vpu_mutex);
+disable_vpu_clk:
+	vpu_clock_disable(vpu);
+workqueue_destroy:
+	destroy_workqueue(vpu->wdt.wq);
+
+	return ret;
+}
+
+static const struct of_device_id mtk_vpu_match[] = {
+	{
+		.compatible = "mediatek,mt8173-vpu",
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, mtk_vpu_match);
+
+static int mtk_vpu_remove(struct platform_device *pdev)
+{
+	struct mtk_vpu *vpu = platform_get_drvdata(pdev);
+
+#ifdef CONFIG_DEBUG_FS
+	debugfs_remove(vpu_debugfs);
+#endif
+	if (vpu->wdt.wq) {
+		flush_workqueue(vpu->wdt.wq);
+		destroy_workqueue(vpu->wdt.wq);
+	}
+	vpu_free_ext_mem(vpu, P_FW);
+	vpu_free_ext_mem(vpu, D_FW);
+	mutex_destroy(&vpu->vpu_mutex);
+	clk_unprepare(vpu->clk);
+
+	return 0;
+}
+
+static struct platform_driver mtk_vpu_driver = {
+	.probe	= mtk_vpu_probe,
+	.remove	= mtk_vpu_remove,
+	.driver	= {
+		.name	= "mtk_vpu",
+		.owner	= THIS_MODULE,
+		.of_match_table = mtk_vpu_match,
+	},
+};
+
+module_platform_driver(mtk_vpu_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Mediatek Video Prosessor Unit driver");
diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.h b/drivers/media/platform/mtk-vpu/mtk_vpu.h
new file mode 100644
index 0000000..0ba90bf
--- /dev/null
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.h
@@ -0,0 +1,163 @@
+/*
+* Copyright (c) 2016 MediaTek Inc.
+* Author: Andrew-CT Chen <andrew-ct.chen at mediatek.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.
+*/
+
+#ifndef _MTK_VPU_H
+#define _MTK_VPU_H
+
+#include <linux/platform_device.h>
+
+/**
+ * VPU (video processor unit) is a tiny processor controlling video hardware
+ * related to video codec, scaling and color format converting.
+ * VPU interfaces with other blocks by share memory and interrupt.
+ **/
+
+typedef void (*ipi_handler_t) (void *data,
+			       unsigned int len,
+			       void *priv);
+
+/**
+ * enum ipi_id - the id of inter-processor interrupt
+ *
+ * @IPI_VPU_INIT:	 The interrupt from vpu is to notfiy kernel
+			 VPU initialization completed.
+			 IPI_VPU_INIT is sent from VPU when firmware is
+			 loaded. AP doesn't need to send IPI_VPU_INIT
+			 command to VPU.
+			 For other IPI below, AP should send the request
+			 to VPU to trigger the interrupt.
+ * @IPI_VENC_H264:	 The interrupt from vpu is to notify kernel to
+			 handle H264 video encoder job, and vice versa.
+ * @IPI_VENC_VP8:	 The interrupt fro vpu is to notify kernel to
+			 handle VP8 video encoder job,, and vice versa.
+ * @IPI_MAX:		 The maximum IPI number
+ */
+
+enum ipi_id {
+	IPI_VPU_INIT = 0,
+	IPI_VENC_H264,
+	IPI_VENC_VP8,
+	IPI_MAX,
+};
+
+/**
+ * enum rst_id - reset id to register reset function for VPU watchdog timeout
+ *
+ * @VPU_RST_ENC: encoder reset id
+ * @VPU_RST_MAX: maximum reset id
+ */
+enum rst_id {
+	VPU_RST_ENC,
+	VPU_RST_MAX,
+};
+
+/**
+ * vpu_ipi_register - register an ipi function
+ *
+ * @pdev:	VPU platform device
+ * @id:		IPI ID
+ * @handler:	IPI handler
+ * @name:	IPI name
+ * @priv:	private data for IPI handler
+ *
+ * Register an ipi function to receive ipi interrupt from VPU.
+ *
+ * Return: Return 0 if ipi registers successfully, otherwise it is failed.
+ */
+int vpu_ipi_register(struct platform_device *pdev, enum ipi_id id,
+		     ipi_handler_t handler, const char *name, void *priv);
+
+/**
+ * vpu_ipi_send - send data from AP to vpu.
+ *
+ * @pdev:	VPU platform device
+ * @id:		IPI ID
+ * @buf:	the data buffer
+ * @len:	the data buffer length
+ *
+ * This function is thread-safe. When this function returns,
+ * VPU has received the data and starts the processing.
+ * When the processing completes, IPI handler registered
+ * by vpu_ipi_register will be called in interrupt context.
+ *
+ * Return: Return 0 if sending data successfully, otherwise it is failed.
+ **/
+int vpu_ipi_send(struct platform_device *pdev,
+		 enum ipi_id id, void *buf,
+		 unsigned int len);
+
+/**
+ * vpu_get_plat_device - get VPU's platform device
+ *
+ * @pdev:	the platform device of the module requesting VPU platform
+ *		device for using VPU API.
+ *
+ * Return: Return NULL if it is failed.
+ * otherwise it is VPU's platform device
+ **/
+struct platform_device *vpu_get_plat_device(struct platform_device *pdev);
+
+/**
+ * vpu_wdt_reg_handler - register a VPU watchdog handler
+ *
+ * @pdev:               VPU platform device
+ * @vpu_wdt_reset_func:	the callback reset function
+ * @private_data:       the private data for reset function
+ * @rst_id:		reset id
+ *
+ * Register a handler performing own tasks when vpu reset by watchdog
+ *
+ * Return: Return 0 if the handler is added successfully,
+ * otherwise it is failed.
+ *
+ **/
+int vpu_wdt_reg_handler(struct platform_device *pdev,
+			void vpu_wdt_reset_func(void *),
+			void *priv, enum rst_id id);
+
+/**
+ * vpu_get_venc_hw_capa - get video encoder hardware capability
+ *
+ * @pdev:	VPU platform device
+ *
+ * Return: video encoder hardware capability
+ **/
+unsigned int vpu_get_venc_hw_capa(struct platform_device *pdev);
+
+/**
+ * vpu_load_firmware - download VPU firmware and boot it
+ *
+ * @pdev:	VPU platform device
+ *
+ * Return: Return 0 if downloading firmware successfully,
+ * otherwise it is failed
+ **/
+int vpu_load_firmware(struct platform_device *pdev);
+
+/**
+ * vpu_mapping_dm_addr - Mapping DTCM/DMEM to kernel virtual address
+ *
+ * @pdev:	VPU platform device
+ * @dmem_addr:	VPU's data memory address
+ *
+ * Mapping the VPU's DTCM (Data Tightly-Coupled Memory) /
+ * DMEM (Data Extended Memory) memory address to
+ * kernel virtual address.
+ *
+ * Return: Return ERR_PTR(-EINVAL) if mapping failed,
+ * otherwise the mapped kernel virtual address
+ **/
+void *vpu_mapping_dm_addr(struct platform_device *pdev,
+			  u32 dtcm_dmem_addr);
+#endif /* _MTK_VPU_H */
-- 
1.7.9.5



From k.kozlowski at samsung.com  Tue Feb 23 00:21:14 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 23 Feb 2016 17:21:14 +0900
Subject: [PATCH] ARM: dts: add support for gpio buttons for
 exynos5422-odroidxu3
In-Reply-To: <1456214467-3344-1-git-send-email-linux.amoon@gmail.com>
References: <1456214467-3344-1-git-send-email-linux.amoon@gmail.com>
Message-ID: <56CC167A.8040303@samsung.com>

On 23.02.2016 17:01, Anand Moon wrote:
> Add support for gpio-based button on Odroid-XU3 boards
> for reboot/poweroff feature.
> 
> Signed-off-by: Anand Moon <linux.amoon at gmail.com>
> ---
> changes rebase based on linux next-20160222.
> 
> Tested on Odroid-XU4
> 
> dmesg output.
> [    3.286068] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio_keys/power_key[0]' - status (0)
> [    3.286206] gpio-11 (power key): gpiod_set_debounce: missing set() or set_debounce() operations
> [    3.286600] input: gpio_keys as /devices/platform/gpio_keys/input/input0
> ---
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index 1bd507b..db9770b 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -11,6 +11,7 @@
>  */
>  
>  #include <dt-bindings/clock/samsung,s2mps11.h>
> +#include <dt-bindings/input/input.h>
>  #include <dt-bindings/interrupt-controller/irq.h>
>  #include <dt-bindings/gpio/gpio.h>
>  #include <dt-bindings/sound/samsung-i2s.h>
> @@ -54,6 +55,22 @@
>  		#cooling-cells = <2>;
>  		cooling-levels = <0 130 170 230>;
>  	};
> +
> +	gpio_keys {
> +		compatible = "gpio-keys";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&gpio_power_key>;
> +
> +		power_key {
> +			interrupt-parent = <&gpx0>;
> +			interrupts = <3 IRQ_TYPE_NONE>;

Hmmm.... why you specify the interrupts?

> +			gpios = <&gpx0 3 GPIO_ACTIVE_LOW>;
> +			linux,code = <KEY_POWER>;
> +			label = "power key";

Just "power".

> +			debounce-interval = <10>;
> +			wakeup-source;
> +		};
> +	};
>  };
>  
>  &clock_audss {
> @@ -362,6 +379,11 @@
>  };
>  
>  &pinctrl_0 {
> +	gpio_power_key: power_key {

The naming is mixed... Everything is GPIO here so don't add such prefix.
Underscores only in label, not in name of node.

	power_key_irq: power-key-irq {

> +		samsung,pins = "gpx0-3";
> +		samsung,pin-pud = <0>;

Don't you want to set specific pin function? And what about drive strength?

Best regards,
Krzysztof

> +	};
> +
>  	hdmi_hpd_irq: hdmi-hpd-irq {
>  		samsung,pins = "gpx3-7";
>  		samsung,pin-function = <0>;
> 



From pc.liao at mediatek.com  Tue Feb 23 00:20:24 2016
From: pc.liao at mediatek.com (PC Liao)
Date: Tue, 23 Feb 2016 16:20:24 +0800
Subject: [PATCH] ASoC: mediatek: remove soft reset and add second I2S clock
Message-ID: <1456215624-40383-1-git-send-email-pc.liao@mediatek.com>

To improve I2S flow, this patch removes soft reset and adds second
I2S clock to use.

Signed-off-by: PC Liao <pc.liao at mediatek.com>
---
 sound/soc/mediatek/mtk-afe-pcm.c |   14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/sound/soc/mediatek/mtk-afe-pcm.c b/sound/soc/mediatek/mtk-afe-pcm.c
index 689c51f..3456bfa 100644
--- a/sound/soc/mediatek/mtk-afe-pcm.c
+++ b/sound/soc/mediatek/mtk-afe-pcm.c
@@ -283,20 +283,13 @@ static void mtk_afe_set_i2s_enable(struct mtk_afe *afe, bool enable)
 
 	regmap_read(afe->regmap, AFE_I2S_CON2, &val);
 	if (!!(val & AFE_I2S_CON2_EN) == enable)
-		return; /* must skip soft reset */
-
-	/* I2S soft reset begin */
-	regmap_update_bits(afe->regmap, AUDIO_TOP_CON1, 0x4, 0x4);
+		return;
 
 	/* input */
 	regmap_update_bits(afe->regmap, AFE_I2S_CON2, 0x1, enable);
 
 	/* output */
 	regmap_update_bits(afe->regmap, AFE_I2S_CON1, 0x1, enable);
-
-	/* I2S soft reset end */
-	udelay(1);
-	regmap_update_bits(afe->regmap, AUDIO_TOP_CON1, 0x4, 0);
 }
 
 static int mtk_afe_dais_enable_clks(struct mtk_afe *afe,
@@ -365,6 +358,7 @@ static int mtk_afe_i2s_startup(struct snd_pcm_substream *substream,
 		return 0;
 
 	mtk_afe_dais_enable_clks(afe, afe->clocks[MTK_CLK_I2S1_M], NULL);
+	mtk_afe_dais_enable_clks(afe, afe->clocks[MTK_CLK_I2S2_M], NULL);
 	regmap_update_bits(afe->regmap, AUDIO_TOP_CON0,
 			   AUD_TCON0_PDN_22M | AUD_TCON0_PDN_24M, 0);
 	return 0;
@@ -384,6 +378,7 @@ static void mtk_afe_i2s_shutdown(struct snd_pcm_substream *substream,
 			   AUD_TCON0_PDN_22M | AUD_TCON0_PDN_24M,
 			   AUD_TCON0_PDN_22M | AUD_TCON0_PDN_24M);
 	mtk_afe_dais_disable_clks(afe, afe->clocks[MTK_CLK_I2S1_M], NULL);
+	mtk_afe_dais_disable_clks(afe, afe->clocks[MTK_CLK_I2S2_M], NULL);
 }
 
 static int mtk_afe_i2s_prepare(struct snd_pcm_substream *substream,
@@ -397,6 +392,9 @@ static int mtk_afe_i2s_prepare(struct snd_pcm_substream *substream,
 	mtk_afe_dais_set_clks(afe,
 			      afe->clocks[MTK_CLK_I2S1_M], runtime->rate * 256,
 			      NULL, 0);
+	mtk_afe_dais_set_clks(afe,
+			      afe->clocks[MTK_CLK_I2S2_M], runtime->rate * 256,
+			      NULL, 0);
 	/* config I2S */
 	ret = mtk_afe_set_i2s(afe, substream->runtime->rate);
 	if (ret)
-- 
1.7.9.5



From geert at linux-m68k.org  Tue Feb 23 00:25:33 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 23 Feb 2016 09:25:33 +0100
Subject: [PATCH 1/2] ARM: dts: r8a7790: use fallback etheravb
 compatibility string
In-Reply-To: <1456190266-3781-2-git-send-email-horms+renesas@verge.net.au>
References: <1456190266-3781-1-git-send-email-horms+renesas@verge.net.au>
 <1456190266-3781-2-git-send-email-horms+renesas@verge.net.au>
Message-ID: <CAMuHMdUJLQFTS9YWdm6RJOOAch6xTkkh=LprVbtumYwc4hKyqQ@mail.gmail.com>

On Tue, Feb 23, 2016 at 2:17 AM, Simon Horman
<horms+renesas at verge.net.au> wrote:
> Use recently added fallback compatibility string in r8a7790 device tree.
>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From geert at linux-m68k.org  Tue Feb 23 00:27:46 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Tue, 23 Feb 2016 09:27:46 +0100
Subject: [PATCH 2/2] arm64: dts: r8a7795: use fallback etheravb
 compatibility string
In-Reply-To: <1456190266-3781-3-git-send-email-horms+renesas@verge.net.au>
References: <1456190266-3781-1-git-send-email-horms+renesas@verge.net.au>
 <1456190266-3781-3-git-send-email-horms+renesas@verge.net.au>
Message-ID: <CAMuHMdV-nrfcWGOW5aAiR2RTe-340ER=TcWgbfe4MEVU_iyYqw@mail.gmail.com>

On Tue, Feb 23, 2016 at 2:17 AM, Simon Horman
<horms+renesas at verge.net.au> wrote:
> Use recently added fallback compatibility string in r8a7795 device tree.
>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From lkp at intel.com  Tue Feb 23 00:27:20 2016
From: lkp at intel.com (kbuild test robot)
Date: Tue, 23 Feb 2016 16:27:20 +0800
Subject: [PATCH v11 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
In-Reply-To: <1456212937-7635-2-git-send-email-jitao.shi@mediatek.com>
Message-ID: <201602231614.ijDQkkJH%fengguang.wu@intel.com>

Hi Jitao,

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.5-rc5 next-20160223]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Jitao-Shi/Documentation-bridge-Add-documentation-for-ps8640-DT-properties/20160223-153819
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-allmodconfig (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/bridge/parade-ps8640.c: In function 'ps8640_bridge_attach':
>> drivers/gpu/drm/bridge/parade-ps8640.c:435:10: error: implicit declaration of function 'of_find_mipi_dsi_host_by_node' [-Werror=implicit-function-declaration]
      host = of_find_mipi_dsi_host_by_node(dsi_node);
             ^
   drivers/gpu/drm/bridge/parade-ps8640.c:435:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
      host = of_find_mipi_dsi_host_by_node(dsi_node);
           ^
   cc1: some warnings being treated as errors

vim +/of_find_mipi_dsi_host_by_node +435 drivers/gpu/drm/bridge/parade-ps8640.c

   429			if (in_ep) {
   430				dsi_node = of_graph_get_remote_port_parent(in_ep);
   431				of_node_put(in_ep);
   432			}
   433		}
   434		if (dsi_node) {
 > 435			host = of_find_mipi_dsi_host_by_node(dsi_node);
   436			of_node_put(dsi_node);
   437			if (!host)
   438				return -ENODEV;

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 53317 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/4a6b5bb3/attachment-0001.obj>

From marc.zyngier at arm.com  Tue Feb 23 00:33:13 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 23 Feb 2016 08:33:13 +0000
Subject: [PATCH v12 03/21] KVM: ARM64: Add offset defines for PMU registers
In-Reply-To: <56CBBA06.4040902@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
 <1456133877-9584-4-git-send-email-zhaoshenglong@huawei.com>
 <56CB4A98.2020403@arm.com> <56CBBA06.4040902@huawei.com>
Message-ID: <56CC1949.2020907@arm.com>

On 23/02/16 01:46, Shannon Zhao wrote:
> 
> 
> On 2016/2/23 1:51, Marc Zyngier wrote:
>> On 22/02/16 09:37, Shannon Zhao wrote:
>>> From: Shannon Zhao <shannon.zhao at linaro.org>
>>>
>>> We are about to trap and emulate accesses to each PMU register
>>> individually. This adds the context offsets for the AArch64 PMU
>>> registers.
>>>
>>> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
>>> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
>>> Reviewed-by: Andrew Jones <drjones at redhat.com>
>>> ---
>>>  arch/arm64/include/asm/kvm_host.h | 15 +++++++++++++++
>>>  1 file changed, 15 insertions(+)
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>>> index 6f0241f..6bab7fb 100644
>>> --- a/arch/arm64/include/asm/kvm_host.h
>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>> @@ -115,6 +115,21 @@ enum vcpu_sysreg {
>>>  	MDSCR_EL1,	/* Monitor Debug System Control Register */
>>>  	MDCCINT_EL1,	/* Monitor Debug Comms Channel Interrupt Enable Reg */
>>>  
>>> +	/* Performance Monitors Registers */
>>> +	PMCR_EL0,	/* Control Register */
>>> +	PMOVSSET_EL0,	/* Overflow Flag Status Set Register */
>>> +	PMSELR_EL0,	/* Event Counter Selection Register */
>>> +	PMEVCNTR0_EL0,	/* Event Counter Register (0-30) */
>>> +	PMEVCNTR30_EL0 = PMEVCNTR0_EL0 + 30,
>>> +	PMCCNTR_EL0,	/* Cycle Counter Register */
>>> +	PMEVTYPER0_EL0,	/* Event Type Register (0-30) */
>>> +	PMEVTYPER30_EL0 = PMEVTYPER0_EL0 + 30,
>>> +	PMCCFILTR_EL0,	/* Cycle Count Filter Register */
>>> +	PMCNTENSET_EL0,	/* Count Enable Set Register */
>>> +	PMINTENSET_EL1,	/* Interrupt Enable Set Register */
>>> +	PMUSERENR_EL0,	/* User Enable Register */
>>> +	PMSWINC_EL0,	/* Software Increment Register */
>>> +
>>
>> I've just noticed a rather fundamental issue with this: this makes it
>> impossible to bisect the whole series.
>>
> Ah, sorry. Will fix this.

Thanks.

> 
>> I was trying to pinpoint a performance regression with this series, and
>> started bisecting.
> You mean this series introduce a performance regression? Is there any
> method to measure that? Then I can have a look too.

I'm not quite sure this is related to this series. What I'm observing is
that hackbench runs faster in a VM spawned with kvmtool than the same VM
run with qemu. As in significantly faster (62 vs 55 seconds - 2 vcpus,
1GB memory).

Given that hackbench doesn't do any IO, I don't really see why we should
see a difference. I'll add support for the PMU to kvmtool today, and
I'll be able to see if that has any impact.

	M.
-- 
Jazz is not dead. It just smells funny...


From k.kozlowski at samsung.com  Tue Feb 23 00:33:19 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 23 Feb 2016 17:33:19 +0900
Subject: [PATCH] ARM: dts: add support for gpio buttons for
 exynos5422-odroidxu3
In-Reply-To: <56CC167A.8040303@samsung.com>
References: <1456214467-3344-1-git-send-email-linux.amoon@gmail.com>
 <56CC167A.8040303@samsung.com>
Message-ID: <56CC194F.6080905@samsung.com>

On 23.02.2016 17:21, Krzysztof Kozlowski wrote:
> On 23.02.2016 17:01, Anand Moon wrote:
>> Add support for gpio-based button on Odroid-XU3 boards
>> for reboot/poweroff feature.
>>
>> Signed-off-by: Anand Moon <linux.amoon at gmail.com>
>> ---
>> changes rebase based on linux next-20160222.
>>
>> Tested on Odroid-XU4
>>
>> dmesg output.
>> [    3.286068] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio_keys/power_key[0]' - status (0)
>> [    3.286206] gpio-11 (power key): gpiod_set_debounce: missing set() or set_debounce() operations
>> [    3.286600] input: gpio_keys as /devices/platform/gpio_keys/input/input0
>> ---
>>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 22 ++++++++++++++++++++++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 1bd507b..db9770b 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -11,6 +11,7 @@
>>  */
>>  
>>  #include <dt-bindings/clock/samsung,s2mps11.h>
>> +#include <dt-bindings/input/input.h>
>>  #include <dt-bindings/interrupt-controller/irq.h>
>>  #include <dt-bindings/gpio/gpio.h>
>>  #include <dt-bindings/sound/samsung-i2s.h>
>> @@ -54,6 +55,22 @@
>>  		#cooling-cells = <2>;
>>  		cooling-levels = <0 130 170 230>;
>>  	};
>> +
>> +	gpio_keys {
>> +		compatible = "gpio-keys";
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&gpio_power_key>;
>> +
>> +		power_key {
>> +			interrupt-parent = <&gpx0>;
>> +			interrupts = <3 IRQ_TYPE_NONE>;
> 
> Hmmm.... why you specify the interrupts?
> 
>> +			gpios = <&gpx0 3 GPIO_ACTIVE_LOW>;

Please, explain it to me. The SW2 key is connected to PWRON of PMIC.
However you are adding a GPIO key for external interrupt source 3
(XE.INT3)... which comes from PMIC's ONOB.

It's interesting.... how does it work? The PMIC will generate ONOB
interrupt on PWRON low->high change (when PWRHOLD is high)?

Best regards,
Krzysztof



From John.Youn at synopsys.com  Tue Feb 23 00:42:02 2016
From: John.Youn at synopsys.com (John Youn)
Date: Tue, 23 Feb 2016 00:42:02 -0800
Subject: [PATCH 1/2] usb: dwc2: Move register save and restore functions
In-Reply-To: <cover.1456213319.git.johnyoun@synopsys.com>
References: <cover.1456213319.git.johnyoun@synopsys.com>
Message-ID: <8cb0a09d08414388ad62f57320dc67bb2ee8d0f6.1456213319.git.johnyoun@synopsys.com>

Move the register save and restore functions into the host and gadget
specific files.

Signed-off-by: John Youn <johnyoun at synopsys.com>
---
 drivers/usb/dwc2/core.c   | 183 ----------------------------------------------
 drivers/usb/dwc2/core.h   |  13 ++++
 drivers/usb/dwc2/gadget.c | 102 ++++++++++++++++++++++++++
 drivers/usb/dwc2/hcd.c    |  64 ++++++++++++++++
 4 files changed, 179 insertions(+), 183 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 3c9c0b2..dc60339 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -56,189 +56,6 @@
 #include "core.h"
 #include "hcd.h"
 
-#if IS_ENABLED(CONFIG_USB_DWC2_HOST) || IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE)
-/**
- * dwc2_backup_host_registers() - Backup controller host registers.
- * When suspending usb bus, registers needs to be backuped
- * if controller power is disabled once suspended.
- *
- * @hsotg: Programming view of the DWC_otg controller
- */
-static int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
-{
-	struct dwc2_hregs_backup *hr;
-	int i;
-
-	dev_dbg(hsotg->dev, "%s\n", __func__);
-
-	/* Backup Host regs */
-	hr = &hsotg->hr_backup;
-	hr->hcfg = dwc2_readl(hsotg->regs + HCFG);
-	hr->haintmsk = dwc2_readl(hsotg->regs + HAINTMSK);
-	for (i = 0; i < hsotg->core_params->host_channels; ++i)
-		hr->hcintmsk[i] = dwc2_readl(hsotg->regs + HCINTMSK(i));
-
-	hr->hprt0 = dwc2_read_hprt0(hsotg);
-	hr->hfir = dwc2_readl(hsotg->regs + HFIR);
-	hr->valid = true;
-
-	return 0;
-}
-
-/**
- * dwc2_restore_host_registers() - Restore controller host registers.
- * When resuming usb bus, device registers needs to be restored
- * if controller power were disabled.
- *
- * @hsotg: Programming view of the DWC_otg controller
- */
-static int dwc2_restore_host_registers(struct dwc2_hsotg *hsotg)
-{
-	struct dwc2_hregs_backup *hr;
-	int i;
-
-	dev_dbg(hsotg->dev, "%s\n", __func__);
-
-	/* Restore host regs */
-	hr = &hsotg->hr_backup;
-	if (!hr->valid) {
-		dev_err(hsotg->dev, "%s: no host registers to restore\n",
-				__func__);
-		return -EINVAL;
-	}
-	hr->valid = false;
-
-	dwc2_writel(hr->hcfg, hsotg->regs + HCFG);
-	dwc2_writel(hr->haintmsk, hsotg->regs + HAINTMSK);
-
-	for (i = 0; i < hsotg->core_params->host_channels; ++i)
-		dwc2_writel(hr->hcintmsk[i], hsotg->regs + HCINTMSK(i));
-
-	dwc2_writel(hr->hprt0, hsotg->regs + HPRT0);
-	dwc2_writel(hr->hfir, hsotg->regs + HFIR);
-	hsotg->frame_number = 0;
-
-	return 0;
-}
-#else
-static inline int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
-{ return 0; }
-
-static inline int dwc2_restore_host_registers(struct dwc2_hsotg *hsotg)
-{ return 0; }
-#endif
-
-#if IS_ENABLED(CONFIG_USB_DWC2_PERIPHERAL) || \
-	IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE)
-/**
- * dwc2_backup_device_registers() - Backup controller device registers.
- * When suspending usb bus, registers needs to be backuped
- * if controller power is disabled once suspended.
- *
- * @hsotg: Programming view of the DWC_otg controller
- */
-static int dwc2_backup_device_registers(struct dwc2_hsotg *hsotg)
-{
-	struct dwc2_dregs_backup *dr;
-	int i;
-
-	dev_dbg(hsotg->dev, "%s\n", __func__);
-
-	/* Backup dev regs */
-	dr = &hsotg->dr_backup;
-
-	dr->dcfg = dwc2_readl(hsotg->regs + DCFG);
-	dr->dctl = dwc2_readl(hsotg->regs + DCTL);
-	dr->daintmsk = dwc2_readl(hsotg->regs + DAINTMSK);
-	dr->diepmsk = dwc2_readl(hsotg->regs + DIEPMSK);
-	dr->doepmsk = dwc2_readl(hsotg->regs + DOEPMSK);
-
-	for (i = 0; i < hsotg->num_of_eps; i++) {
-		/* Backup IN EPs */
-		dr->diepctl[i] = dwc2_readl(hsotg->regs + DIEPCTL(i));
-
-		/* Ensure DATA PID is correctly configured */
-		if (dr->diepctl[i] & DXEPCTL_DPID)
-			dr->diepctl[i] |= DXEPCTL_SETD1PID;
-		else
-			dr->diepctl[i] |= DXEPCTL_SETD0PID;
-
-		dr->dieptsiz[i] = dwc2_readl(hsotg->regs + DIEPTSIZ(i));
-		dr->diepdma[i] = dwc2_readl(hsotg->regs + DIEPDMA(i));
-
-		/* Backup OUT EPs */
-		dr->doepctl[i] = dwc2_readl(hsotg->regs + DOEPCTL(i));
-
-		/* Ensure DATA PID is correctly configured */
-		if (dr->doepctl[i] & DXEPCTL_DPID)
-			dr->doepctl[i] |= DXEPCTL_SETD1PID;
-		else
-			dr->doepctl[i] |= DXEPCTL_SETD0PID;
-
-		dr->doeptsiz[i] = dwc2_readl(hsotg->regs + DOEPTSIZ(i));
-		dr->doepdma[i] = dwc2_readl(hsotg->regs + DOEPDMA(i));
-	}
-	dr->valid = true;
-	return 0;
-}
-
-/**
- * dwc2_restore_device_registers() - Restore controller device registers.
- * When resuming usb bus, device registers needs to be restored
- * if controller power were disabled.
- *
- * @hsotg: Programming view of the DWC_otg controller
- */
-static int dwc2_restore_device_registers(struct dwc2_hsotg *hsotg)
-{
-	struct dwc2_dregs_backup *dr;
-	u32 dctl;
-	int i;
-
-	dev_dbg(hsotg->dev, "%s\n", __func__);
-
-	/* Restore dev regs */
-	dr = &hsotg->dr_backup;
-	if (!dr->valid) {
-		dev_err(hsotg->dev, "%s: no device registers to restore\n",
-				__func__);
-		return -EINVAL;
-	}
-	dr->valid = false;
-
-	dwc2_writel(dr->dcfg, hsotg->regs + DCFG);
-	dwc2_writel(dr->dctl, hsotg->regs + DCTL);
-	dwc2_writel(dr->daintmsk, hsotg->regs + DAINTMSK);
-	dwc2_writel(dr->diepmsk, hsotg->regs + DIEPMSK);
-	dwc2_writel(dr->doepmsk, hsotg->regs + DOEPMSK);
-
-	for (i = 0; i < hsotg->num_of_eps; i++) {
-		/* Restore IN EPs */
-		dwc2_writel(dr->diepctl[i], hsotg->regs + DIEPCTL(i));
-		dwc2_writel(dr->dieptsiz[i], hsotg->regs + DIEPTSIZ(i));
-		dwc2_writel(dr->diepdma[i], hsotg->regs + DIEPDMA(i));
-
-		/* Restore OUT EPs */
-		dwc2_writel(dr->doepctl[i], hsotg->regs + DOEPCTL(i));
-		dwc2_writel(dr->doeptsiz[i], hsotg->regs + DOEPTSIZ(i));
-		dwc2_writel(dr->doepdma[i], hsotg->regs + DOEPDMA(i));
-	}
-
-	/* Set the Power-On Programming done bit */
-	dctl = dwc2_readl(hsotg->regs + DCTL);
-	dctl |= DCTL_PWRONPRGDONE;
-	dwc2_writel(dctl, hsotg->regs + DCTL);
-
-	return 0;
-}
-#else
-static inline int dwc2_backup_device_registers(struct dwc2_hsotg *hsotg)
-{ return 0; }
-
-static inline int dwc2_restore_device_registers(struct dwc2_hsotg *hsotg)
-{ return 0; }
-#endif
-
 /**
  * dwc2_backup_global_registers() - Backup global controller registers.
  * When suspending usb bus, registers needs to be backuped
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1159259..606629a 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -1295,6 +1295,8 @@ extern void dwc2_hsotg_core_connect(struct dwc2_hsotg *hsotg);
 extern void dwc2_hsotg_disconnect(struct dwc2_hsotg *dwc2);
 extern int dwc2_hsotg_set_test_mode(struct dwc2_hsotg *hsotg, int testmode);
 #define dwc2_is_device_connected(hsotg) (hsotg->connected)
+int dwc2_backup_device_registers(struct dwc2_hsotg *hsotg);
+int dwc2_restore_device_registers(struct dwc2_hsotg *hsotg);
 #else
 static inline int dwc2_hsotg_remove(struct dwc2_hsotg *dwc2)
 { return 0; }
@@ -1312,6 +1314,10 @@ static inline int dwc2_hsotg_set_test_mode(struct dwc2_hsotg *hsotg,
 							int testmode)
 { return 0; }
 #define dwc2_is_device_connected(hsotg) (0)
+static inline int dwc2_backup_device_registers(struct dwc2_hsotg *hsotg)
+{ return 0; }
+static inline int dwc2_restore_device_registers(struct dwc2_hsotg *hsotg)
+{ return 0; }
 #endif
 
 #if IS_ENABLED(CONFIG_USB_DWC2_HOST) || IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE)
@@ -1320,6 +1326,8 @@ extern int dwc2_hcd_get_future_frame_number(struct dwc2_hsotg *hsotg, int us);
 extern void dwc2_hcd_connect(struct dwc2_hsotg *hsotg);
 extern void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool force);
 extern void dwc2_hcd_start(struct dwc2_hsotg *hsotg);
+int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg);
+int dwc2_restore_host_registers(struct dwc2_hsotg *hsotg);
 #else
 static inline int dwc2_hcd_get_frame_number(struct dwc2_hsotg *hsotg)
 { return 0; }
@@ -1332,6 +1340,11 @@ static inline void dwc2_hcd_start(struct dwc2_hsotg *hsotg) {}
 static inline void dwc2_hcd_remove(struct dwc2_hsotg *hsotg) {}
 static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
 { return 0; }
+static inline int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
+{ return 0; }
+static inline int dwc2_restore_host_registers(struct dwc2_hsotg *hsotg)
+{ return 0; }
+
 #endif
 
 #endif /* __DWC2_CORE_H__ */
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 422ab7d..e9940dd 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3668,3 +3668,105 @@ int dwc2_hsotg_resume(struct dwc2_hsotg *hsotg)
 
 	return 0;
 }
+
+/**
+ * dwc2_backup_device_registers() - Backup controller device registers.
+ * When suspending usb bus, registers needs to be backuped
+ * if controller power is disabled once suspended.
+ *
+ * @hsotg: Programming view of the DWC_otg controller
+ */
+int dwc2_backup_device_registers(struct dwc2_hsotg *hsotg)
+{
+	struct dwc2_dregs_backup *dr;
+	int i;
+
+	dev_dbg(hsotg->dev, "%s\n", __func__);
+
+	/* Backup dev regs */
+	dr = &hsotg->dr_backup;
+
+	dr->dcfg = dwc2_readl(hsotg->regs + DCFG);
+	dr->dctl = dwc2_readl(hsotg->regs + DCTL);
+	dr->daintmsk = dwc2_readl(hsotg->regs + DAINTMSK);
+	dr->diepmsk = dwc2_readl(hsotg->regs + DIEPMSK);
+	dr->doepmsk = dwc2_readl(hsotg->regs + DOEPMSK);
+
+	for (i = 0; i < hsotg->num_of_eps; i++) {
+		/* Backup IN EPs */
+		dr->diepctl[i] = dwc2_readl(hsotg->regs + DIEPCTL(i));
+
+		/* Ensure DATA PID is correctly configured */
+		if (dr->diepctl[i] & DXEPCTL_DPID)
+			dr->diepctl[i] |= DXEPCTL_SETD1PID;
+		else
+			dr->diepctl[i] |= DXEPCTL_SETD0PID;
+
+		dr->dieptsiz[i] = dwc2_readl(hsotg->regs + DIEPTSIZ(i));
+		dr->diepdma[i] = dwc2_readl(hsotg->regs + DIEPDMA(i));
+
+		/* Backup OUT EPs */
+		dr->doepctl[i] = dwc2_readl(hsotg->regs + DOEPCTL(i));
+
+		/* Ensure DATA PID is correctly configured */
+		if (dr->doepctl[i] & DXEPCTL_DPID)
+			dr->doepctl[i] |= DXEPCTL_SETD1PID;
+		else
+			dr->doepctl[i] |= DXEPCTL_SETD0PID;
+
+		dr->doeptsiz[i] = dwc2_readl(hsotg->regs + DOEPTSIZ(i));
+		dr->doepdma[i] = dwc2_readl(hsotg->regs + DOEPDMA(i));
+	}
+	dr->valid = true;
+	return 0;
+}
+
+/**
+ * dwc2_restore_device_registers() - Restore controller device registers.
+ * When resuming usb bus, device registers needs to be restored
+ * if controller power were disabled.
+ *
+ * @hsotg: Programming view of the DWC_otg controller
+ */
+int dwc2_restore_device_registers(struct dwc2_hsotg *hsotg)
+{
+	struct dwc2_dregs_backup *dr;
+	u32 dctl;
+	int i;
+
+	dev_dbg(hsotg->dev, "%s\n", __func__);
+
+	/* Restore dev regs */
+	dr = &hsotg->dr_backup;
+	if (!dr->valid) {
+		dev_err(hsotg->dev, "%s: no device registers to restore\n",
+			__func__);
+		return -EINVAL;
+	}
+	dr->valid = false;
+
+	dwc2_writel(dr->dcfg, hsotg->regs + DCFG);
+	dwc2_writel(dr->dctl, hsotg->regs + DCTL);
+	dwc2_writel(dr->daintmsk, hsotg->regs + DAINTMSK);
+	dwc2_writel(dr->diepmsk, hsotg->regs + DIEPMSK);
+	dwc2_writel(dr->doepmsk, hsotg->regs + DOEPMSK);
+
+	for (i = 0; i < hsotg->num_of_eps; i++) {
+		/* Restore IN EPs */
+		dwc2_writel(dr->diepctl[i], hsotg->regs + DIEPCTL(i));
+		dwc2_writel(dr->dieptsiz[i], hsotg->regs + DIEPTSIZ(i));
+		dwc2_writel(dr->diepdma[i], hsotg->regs + DIEPDMA(i));
+
+		/* Restore OUT EPs */
+		dwc2_writel(dr->doepctl[i], hsotg->regs + DOEPCTL(i));
+		dwc2_writel(dr->doeptsiz[i], hsotg->regs + DOEPTSIZ(i));
+		dwc2_writel(dr->doepdma[i], hsotg->regs + DOEPDMA(i));
+	}
+
+	/* Set the Power-On Programming done bit */
+	dctl = dwc2_readl(hsotg->regs + DCTL);
+	dctl |= DCTL_PWRONPRGDONE;
+	dwc2_writel(dctl, hsotg->regs + DCTL);
+
+	return 0;
+}
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 2b5a706..b403f6a 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -3433,3 +3433,67 @@ void dwc2_hcd_remove(struct dwc2_hsotg *hsotg)
 	kfree(hsotg->frame_num_array);
 #endif
 }
+
+/**
+ * dwc2_backup_host_registers() - Backup controller host registers.
+ * When suspending usb bus, registers needs to be backuped
+ * if controller power is disabled once suspended.
+ *
+ * @hsotg: Programming view of the DWC_otg controller
+ */
+int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
+{
+	struct dwc2_hregs_backup *hr;
+	int i;
+
+	dev_dbg(hsotg->dev, "%s\n", __func__);
+
+	/* Backup Host regs */
+	hr = &hsotg->hr_backup;
+	hr->hcfg = dwc2_readl(hsotg->regs + HCFG);
+	hr->haintmsk = dwc2_readl(hsotg->regs + HAINTMSK);
+	for (i = 0; i < hsotg->core_params->host_channels; ++i)
+		hr->hcintmsk[i] = dwc2_readl(hsotg->regs + HCINTMSK(i));
+
+	hr->hprt0 = dwc2_read_hprt0(hsotg);
+	hr->hfir = dwc2_readl(hsotg->regs + HFIR);
+	hr->valid = true;
+
+	return 0;
+}
+
+/**
+ * dwc2_restore_host_registers() - Restore controller host registers.
+ * When resuming usb bus, device registers needs to be restored
+ * if controller power were disabled.
+ *
+ * @hsotg: Programming view of the DWC_otg controller
+ */
+int dwc2_restore_host_registers(struct dwc2_hsotg *hsotg)
+{
+	struct dwc2_hregs_backup *hr;
+	int i;
+
+	dev_dbg(hsotg->dev, "%s\n", __func__);
+
+	/* Restore host regs */
+	hr = &hsotg->hr_backup;
+	if (!hr->valid) {
+		dev_err(hsotg->dev, "%s: no host registers to restore\n",
+			__func__);
+		return -EINVAL;
+	}
+	hr->valid = false;
+
+	dwc2_writel(hr->hcfg, hsotg->regs + HCFG);
+	dwc2_writel(hr->haintmsk, hsotg->regs + HAINTMSK);
+
+	for (i = 0; i < hsotg->core_params->host_channels; ++i)
+		dwc2_writel(hr->hcintmsk[i], hsotg->regs + HCINTMSK(i));
+
+	dwc2_writel(hr->hprt0, hsotg->regs + HPRT0);
+	dwc2_writel(hr->hfir, hsotg->regs + HFIR);
+	hsotg->frame_number = 0;
+
+	return 0;
+}
-- 
2.6.3



From John.Youn at synopsys.com  Tue Feb 23 00:41:43 2016
From: John.Youn at synopsys.com (John Youn)
Date: Tue, 23 Feb 2016 00:41:43 -0800
Subject: [PATCH 0/2] usb: dwc2: Remove host and gadget only code from core
Message-ID: <cover.1456213319.git.johnyoun@synopsys.com>

This series moves the host/gadget-specific code from core.c to hcd.c
and gadget.c so that they will be compiled only when their respective
configurations are selected, or in DRD.

This is mostly just a straight move of the code. I have also added
some comments to group related functions together.

Compiled and tested in all three modes.

This should also solve the issue reported here:
http://marc.info/?l=linux-usb&m=145591813410106&w=2

Although I wasn't able to test it... couldn't figure out how to
disable CONFIG_USB and enable DWC2 in gadget mode.

Felipe,

This should be applied after Doug's series on your testing/next
branch.

Regards,
John

John Youn (2):
  usb: dwc2: Move register save and restore functions
  usb: dwc2: Move host-specific core functions into hcd.c

 drivers/usb/dwc2/core.c   | 1959 ---------------------------------------------
 drivers/usb/dwc2/core.h   |   35 +-
 drivers/usb/dwc2/gadget.c |  102 +++
 drivers/usb/dwc2/hcd.c    | 1947 ++++++++++++++++++++++++++++++++++++++++++--
 drivers/usb/dwc2/hcd.h    |   10 +
 5 files changed, 2023 insertions(+), 2030 deletions(-)

-- 
2.6.3



From k.kozlowski at samsung.com  Tue Feb 23 00:47:31 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 23 Feb 2016 17:47:31 +0900
Subject: [PATCH] ARM: dts: add support for gpio buttons for
 exynos5422-odroidxu3
In-Reply-To: <56CC194F.6080905@samsung.com>
References: <1456214467-3344-1-git-send-email-linux.amoon@gmail.com>
 <56CC167A.8040303@samsung.com> <56CC194F.6080905@samsung.com>
Message-ID: <56CC1CA3.7010803@samsung.com>

On 23.02.2016 17:33, Krzysztof Kozlowski wrote:
> On 23.02.2016 17:21, Krzysztof Kozlowski wrote:
>> On 23.02.2016 17:01, Anand Moon wrote:
>>> Add support for gpio-based button on Odroid-XU3 boards
>>> for reboot/poweroff feature.
>>>
>>> Signed-off-by: Anand Moon <linux.amoon at gmail.com>
>>> ---
>>> changes rebase based on linux next-20160222.
>>>
>>> Tested on Odroid-XU4
>>>
>>> dmesg output.
>>> [    3.286068] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio_keys/power_key[0]' - status (0)
>>> [    3.286206] gpio-11 (power key): gpiod_set_debounce: missing set() or set_debounce() operations
>>> [    3.286600] input: gpio_keys as /devices/platform/gpio_keys/input/input0
>>> ---
>>>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 22 ++++++++++++++++++++++
>>>  1 file changed, 22 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> index 1bd507b..db9770b 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> @@ -11,6 +11,7 @@
>>>  */
>>>  
>>>  #include <dt-bindings/clock/samsung,s2mps11.h>
>>> +#include <dt-bindings/input/input.h>
>>>  #include <dt-bindings/interrupt-controller/irq.h>
>>>  #include <dt-bindings/gpio/gpio.h>
>>>  #include <dt-bindings/sound/samsung-i2s.h>
>>> @@ -54,6 +55,22 @@
>>>  		#cooling-cells = <2>;
>>>  		cooling-levels = <0 130 170 230>;
>>>  	};
>>> +
>>> +	gpio_keys {
>>> +		compatible = "gpio-keys";
>>> +		pinctrl-names = "default";
>>> +		pinctrl-0 = <&gpio_power_key>;
>>> +
>>> +		power_key {
>>> +			interrupt-parent = <&gpx0>;
>>> +			interrupts = <3 IRQ_TYPE_NONE>;
>>
>> Hmmm.... why you specify the interrupts?
>>
>>> +			gpios = <&gpx0 3 GPIO_ACTIVE_LOW>;
> 
> Please, explain it to me. The SW2 key is connected to PWRON of PMIC.
> However you are adding a GPIO key for external interrupt source 3
> (XE.INT3)... which comes from PMIC's ONOB.
> 
> It's interesting.... how does it work? The PMIC will generate ONOB
> interrupt on PWRON low->high change (when PWRHOLD is high)?

Hmmm... This is not well documented but apparently that is the case. The
PMIC will generate ONOB interrupt (with 16 ms de-bounce for PWRON) on
each PWRON flip.

This looks kind of hacky or indirect usage. Using a GPIO key not for
GPIO itself but for an interrupt generated by PMIC on a key press...

Best regards,
Krzysztof



From hverkuil at xs4all.nl  Tue Feb 23 00:47:39 2016
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Tue, 23 Feb 2016 09:47:39 +0100
Subject: [PATCH v5 0/8] Add MT8173 Video Encoder Driver and VPU Driver
In-Reply-To: <1456215081-16858-1-git-send-email-tiffany.lin@mediatek.com>
References: <1456215081-16858-1-git-send-email-tiffany.lin@mediatek.com>
Message-ID: <56CC1CAB.1060409@xs4all.nl>

On 02/23/16 09:11, Tiffany Lin wrote:
> ==============
>  Introduction
> ==============
> 
> The purpose of this series is to add the driver for video codec hw embedded in the Mediatek's MT8173 SoCs.
> Mediatek Video Codec is able to handle video encoding of in a range of formats.
> 
> This patch series also include VPU driver. Mediatek Video Codec driver rely on VPU driver to load,
> communicate with VPU.
> 
> Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI.
> MTK IOMMU[1] and MTK SMI[2] have not yet been merged, but we wanted to start discussion about the driver
> earlier so it could be merged sooner.
> 
> [1]https://patchwork.kernel.org/patch/8335461/
> [2]https://patchwork.kernel.org/patch/7596181/

<snip>

> v4l2-compliance test output:
> localhost ~ # /usr/bin/v4l2-compliance -d /dev/video1
> Driver Info:
>         Driver name   : mtk-vcodec-enc
>         Card type     : platform:mt8173
>         Bus info      : platform:mt8173
>         Driver version: 4.4.0
>         Capabilities  : 0x84204000
>                 Video Memory-to-Memory Multiplanar
>                 Streaming
>                 Extended Pix Format
>                 Device Capabilities
>         Device Caps   : 0x04204000
>                 Video Memory-to-Memory Multiplanar
>                 Streaming
>                 Extended Pix Format
> 
> Compliance test for device /dev/video1 (not using libv4l2):
> 
> Required ioctls:
>         test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
>         test second video open: OK
>         test VIDIOC_QUERYCAP: OK
>         test VIDIOC_G/S_PRIORITY: OK
> 
> Debug ioctls:
>         test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>         test VIDIOC_LOG_STATUS: OK (Not Supported)
> 
> Input ioctls:
>         test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>         test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>         test VIDIOC_ENUMAUDIO: OK (Not Supported)
>         test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
>         test VIDIOC_G/S_AUDIO: OK (Not Supported)
>         Inputs: 0 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
>         test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>         test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>         test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>         test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>         Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
>         test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>         test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>         test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>         test VIDIOC_G/S_EDID: OK (Not Supported)
> 
>         Control ioctls:
>                 test VIDIOC_QUERYCTRL/MENU: OK
>                 test VIDIOC_G/S_CTRL: OK
>                 test VIDIOC_G/S/TRY_EXT_CTRLS: OK
>                 test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
>                 test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>                 Standard Controls: 12 Private Controls: 0
> 
>         Format ioctls:
>                 test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>                 test VIDIOC_G/S_PARM: OK
>                 test VIDIOC_G_FBUF: OK (Not Supported)
>                 test VIDIOC_G_FMT: OK
>                 test VIDIOC_TRY_FMT: OK
>                 test VIDIOC_S_FMT: OK
>                 test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> 
>         Codec ioctls:
>                 test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
>                 test VIDIOC_G_ENC_INDEX: OK (Not Supported)
>                 test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> 
>         Buffer ioctls:
>                 test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
>                 test VIDIOC_EXPBUF: OK
> 
> Total: 38, Succeeded: 38, Failed: 0, Warnings: 0

Nice!

Can you try 'v4l2-compliance -s'? Note that this may not work since I know
that v4l2-compliance doesn't work all that well with codecs, but I am
curious what the output is when you try streaming.

Don't bother trying to chase down reported failures, those are likely from
v4l2-compliance itself. It is something I would like to improve, but -ENOTIME.

Regards,

	Hans


From marc.zyngier at arm.com  Tue Feb 23 00:51:15 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 23 Feb 2016 08:51:15 +0000
Subject: [PATCH] irqchip/gicv3-its: Don't allow devices whose ID is
 outside range
In-Reply-To: <1456199868-9054-1-git-send-email-shankerd@codeaurora.org>
References: <1456199868-9054-1-git-send-email-shankerd@codeaurora.org>
Message-ID: <56CC1D83.4060503@arm.com>

On 23/02/16 03:57, Shanker Donthineni wrote:
> We are not checking whether the requested device identifier fits into
> table or not. The ITS MAPD command fails if 'Device ID' is outside of
> device table range.
> 
> Add a simple validation check to avoid MAPD failures since we are
> not handling ITS command errors. This change also helps to return an
> error -ENOMEM instead of success to caller.
> 

In which circumstances do you see this failing? We allocate memory for
the whole DevID range (as advertised by the ITS), so anything that comes
up outside of that range cannot be handled anyway, and is a HW
integration issue. You might as well pretend that these devices do not
exist.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From matthias.bgg at gmail.com  Tue Feb 23 00:53:34 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 23 Feb 2016 09:53:34 +0100
Subject: [PATCH] ARM64: dts: Mediatek: mt8173-evb: fix access MMC fail
 issue
In-Reply-To: <7h37skw9jd.fsf@baylibre.com>
References: <1455861643-24307-1-git-send-email-eddie.huang@mediatek.com>
 <7h37skw9jd.fsf@baylibre.com>
Message-ID: <56CC1E0E.4050400@gmail.com>



On 23/02/16 01:32, Kevin Hilman wrote:
> Eddie Huang <eddie.huang at mediatek.com> writes:
>
>> MT8173 E1 chip has one bug that if turn off USB power domain, vcore
>> power will also be off, thus cause modules using vcore power domain
>> fail, like MMC. The E1 chip only found on MT8173-evb board and this
>> board only has E1 chip, so implement this as a board specific
>> workaround.
>>
>> Pwrapper use vcore power, so add pwrapper using USB power domain to
>> keep USB power domain not to zero and disabled.
>>
>> Signed-off-by: Eddie Huang <eddie.huang at mediatek.com>
>
> Tested-by: Kevin Hilman <khilman at baylibre.com>
>

I send the patch in a pull request yesterday, so I won't be able to add 
your tag.
Thanks for testing and reporting this issue!

Matthias

> I verified that this gets my mt8173-evb booting again when I enable MMC
> support.
>
> Thanks,
>
> Kevin
>


From s.hauer at pengutronix.de  Tue Feb 23 00:55:06 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Feb 2016 09:55:06 +0100
Subject: [PATCH] thermal: mediatek: add missing dependencies
In-Reply-To: <1455921381-1881305-1-git-send-email-arnd@arndb.de>
References: <1455921381-1881305-1-git-send-email-arnd@arndb.de>
Message-ID: <20160223085506.GB3939@pengutronix.de>

Hi Arnd,

On Fri, Feb 19, 2016 at 11:36:06PM +0100, Arnd Bergmann wrote:
> The newly added mtk_thermal driver uses the generic reset
> and nvmem infrastructure, but lacks a dependency that enforces
> them from actually being present:
> 
> drivers/thermal/mtk_thermal.c: In function 'mtk_thermal_probe':
> drivers/thermal/mtk_thermal.c:560:8: error: implicit declaration of function 'device_reset' [-Werror=implicit-function-declaration]
> drivers/thermal/built-in.o: In function `mtk_thermal_probe':
> mtk_thermal.c:(.text+0x7fb0): undefined reference to `nvmem_cell_get'
> mtk_thermal.c:(.text+0x7fd8): undefined reference to `nvmem_cell_read'
> mtk_thermal.c:(.text+0x7fe4): undefined reference to `nvmem_cell_put'
> 
> Without CONFIG_THERMAL, the driver cannot build, so this needs
> to be a hard dependency.

s/CONFIG_THERMAL/CONFIG_RESET_CONTROLLER/ ?

> 
> For CONFIG_NVMEM, the header file allows building the driver even
> when the subsystem is disabled, but we get the link error above
> when nvmem is built as a module and the thermal driver is built-in,
> so we can allow compile-testing when NVMEM is completely disabled,
> but otherwise require the dependency.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  drivers/thermal/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 5e7c97a3f1d8..75d164341f0d 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -368,6 +368,8 @@ config INTEL_PCH_THERMAL
>  config MTK_THERMAL
>  	tristate "Temperature sensor driver for mediatek SoCs"
>  	depends on ARCH_MEDIATEK || COMPILE_TEST
> +	depends on NVMEM || (!NVMEM && COMPILE_TEST)

This doesn't work as expected. When NVMEM is off I can still not select
MTK_THERMAL, even when COMPILE_TEST is enabled.

Even if it would work, do we really want this? It raises eyebrows and
without reading the commit messages it's probably not clear what's going
on here. I don't see that much value in it.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From s.hauer at pengutronix.de  Tue Feb 23 00:57:40 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Feb 2016 09:57:40 +0100
Subject: [PATCH] bus: imx-weim: Take the 'status' property value into
 account
In-Reply-To: <1456142513-12876-1-git-send-email-festevam@gmail.com>
References: <1456142513-12876-1-git-send-email-festevam@gmail.com>
Message-ID: <20160223085740.GC3939@pengutronix.de>

On Mon, Feb 22, 2016 at 09:01:53AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at nxp.com>
> 
> Currently we have an incorrect behaviour when multiple devices
> are present under the weim node. For example:
> 
> &weim {
> 	...
> 	status = "okay";
> 	
> 	sram at 0,0 {
> 		...
>         	status = "okay";
> 	};
> 
> 	mram at 0,0 {
> 		...
>         	status = "disabled";
>     	};
> };
> 
> In this case only the 'sram' device should be probed and not 'mram'.
> 
> However what happens currently is that the status variable is ignored,
> causing the 'sram' device to be disabled and 'mram' to be enabled.  
> 
> Change the weim_parse_dt() function to use
> for_each_available_child_of_node()so that the devices marked with
> 'status = disabled' are not probed.
> 
> Cc: <stable at vger.kernel.org>
> Suggested-by: Wolfgang Netbal <wolfgang.netbal at sigmatek.at>
> Signed-off-by: Fabio Estevam <fabio.estevam at nxp.com>
> ---
>  drivers/bus/imx-weim.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Seems to be the right thing to do.

Reviewed-by: Sascha Hauer <s.hauer at pengutronix.de>

Sascha

> 
> diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
> index e98d15e..1827fc4 100644
> --- a/drivers/bus/imx-weim.c
> +++ b/drivers/bus/imx-weim.c
> @@ -150,7 +150,7 @@ static int __init weim_parse_dt(struct platform_device *pdev,
>  			return ret;
>  	}
>  
> -	for_each_child_of_node(pdev->dev.of_node, child) {
> +	for_each_available_child_of_node(pdev->dev.of_node, child) {
>  		if (!child->name)
>  			continue;
>  
> -- 
> 1.9.1
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From carlo at caione.org  Tue Feb 23 00:58:37 2016
From: carlo at caione.org (Carlo Caione)
Date: Tue, 23 Feb 2016 09:58:37 +0100
Subject: [PATCH v2] MAINTAINERS: Extend info,
 add wiki and ml for meson arch
In-Reply-To: <1455575651-16157-1-git-send-email-carlo@caione.org>
References: <1455575651-16157-1-git-send-email-carlo@caione.org>
Message-ID: <CAOQ7t2Zrx7N3a=RKpr2M3R6QYDeC=8yUs61NrohvrbT=vvjLiQ@mail.gmail.com>

On Mon, Feb 15, 2016 at 11:34 PM, Carlo Caione <carlo at caione.org> wrote:
> From: Carlo Caione <carlo at endlessm.com>
>
> Update the maintainers info with wiki and mailing list for the meson
> platform. Fix a wrong file attribution and add maintainership for the
> generic meson platforms.
>
> Signed-off-by: Carlo Caione <carlo at endlessm.com>
> ---
>  MAINTAINERS | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 28eb61b..7f51744 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -920,12 +920,15 @@ M:        Emilio L?pez <emilio at elopez.com.ar>
>  S:     Maintained
>  F:     drivers/clk/sunxi/
>
> -ARM/Amlogic MesonX SoC support
> +ARM/Amlogic Meson SoC support
>  M:     Carlo Caione <carlo at caione.org>
>  L:     linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +L:     linux-meson at googlegroups.com
> +W:     http://linux-meson.com/
>  S:     Maintained
> -F:     drivers/media/rc/meson-ir.c
> -N:     meson[x68]
> +F:     arch/arm/mach-meson/
> +F:     arch/arm/boot/dts/meson*
> +N:     meson

Hey Arnd,
Does this usually go through the armsoc tree?

Thanks,

-- 
Carlo Caione


From pankaj.dubey at samsung.com  Tue Feb 23 01:06:13 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Tue, 23 Feb 2016 14:36:13 +0530
Subject: [PATCH] ARM: plat-samsung: remove unused register definitions
Message-ID: <1456218373-23658-1-git-send-email-pankaj.dubey@samsung.com>

This patch removes S5P_VA_TWD and S3C_UART_OFFSET as it is no more used
by any platform which including this header file.

Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
---
 arch/arm/plat-samsung/include/plat/map-s5p.h | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/plat-samsung/include/plat/map-s5p.h b/arch/arm/plat-samsung/include/plat/map-s5p.h
index e555769..b63aeeb 100644
--- a/arch/arm/plat-samsung/include/plat/map-s5p.h
+++ b/arch/arm/plat-samsung/include/plat/map-s5p.h
@@ -22,7 +22,6 @@
 #define S5P_VA_COREPERI_BASE	S3C_ADDR(0x02800000)
 #define S5P_VA_COREPERI(x)	(S5P_VA_COREPERI_BASE + (x))
 #define S5P_VA_SCU		S5P_VA_COREPERI(0x0)
-#define S5P_VA_TWD		S5P_VA_COREPERI(0x600)
 
 #define VA_VIC(x)		(S3C_VA_IRQ + ((x) * 0x10000))
 #define VA_VIC0			VA_VIC(0)
@@ -30,10 +29,6 @@
 #define VA_VIC2			VA_VIC(2)
 #define VA_VIC3			VA_VIC(3)
 
-#ifndef S3C_UART_OFFSET
-#define S3C_UART_OFFSET		(0x400)
-#endif
-
 #include <plat/map-s3c.h>
 
 #endif /* __ASM_PLAT_MAP_S5P_H */
-- 
2.4.5



From linus.walleij at linaro.org  Tue Feb 23 01:08:05 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Feb 2016 10:08:05 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
Message-ID: <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>

On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij at linaro.org> wrote:

> This moves the versatile CLCD configuration to the device tree by:

As this Schr?dinger's cat approach seems controversial, as well
as the alternative to manipulate the DT in memory at run-time,
I will respin the series without the full Versatile support, adding
plug-in for the other ARM boards and and half-baked support
for the Versatile supporting just VGA (like the other reference
designs from ARM).

The pluggable displays prove yet again to be a problem to the
world, sigh.

I will think of a better solution, if any, for this for v4.6, but will
put forward something that handles the Nomadik and all the
other ARM reference designs for now.

Yours,
Linus Walleij


From pankaj.dubey at samsung.com  Tue Feb 23 01:11:20 2016
From: pankaj.dubey at samsung.com (pankaj.dubey)
Date: Tue, 23 Feb 2016 14:41:20 +0530
Subject: [PATCH 2/3] ARM: EXYNOS: remove unused register offset definition
In-Reply-To: <56CBA1BC.4050003@samsung.com>
References: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
 <1456135396-17767-3-git-send-email-pankaj.dubey@samsung.com>
 <56CBA1BC.4050003@samsung.com>
Message-ID: <56CC2238.2040303@samsung.com>

Hi Krzysztof,

On Tuesday 23 February 2016 05:33 AM, Krzysztof Kozlowski wrote:
> On 22.02.2016 19:03, Pankaj Dubey wrote:
>> This patch cleans up map.h by removing unused register offset
>> and changing EXYNOS4 to EXYNOS in header comment section.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
>> ---
>>  arch/arm/mach-exynos/include/mach/map.h | 9 +--------
>>  1 file changed, 1 insertion(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
>> index 351e839..c48ba4f 100644
>> --- a/arch/arm/mach-exynos/include/mach/map.h
>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>> @@ -2,7 +2,7 @@
>>   * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
>>   *		http://www.samsung.com/
>>   *
>> - * EXYNOS4 - Memory map definitions
>> + * EXYNOS - Memory map definitions
>>   *
>>   * 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
>> @@ -14,12 +14,6 @@
>>  
>>  #include <plat/map-base.h>
>>  
>> -/*
>> - * EXYNOS4 UART offset is 0x10000 but the older S5P SoCs are 0x400.
>> - * So need to define it, and here is to avoid redefinition warning.
>> - */
>> -#define S3C_UART_OFFSET			(0x10000)
>> -
>>  #include <plat/map-s5p.h>
> 
> This does not look good. The S3C_UART_OFFSET is used in plat/map-s5p.h.
> 

Actually it's just defined there but not getting used anywhere. In fact
we can remove it from there also. So I submitted another patch to
cleanup such redundant register definitions from plat/map-s5p.h.
Only platform using S3C_UART_OFFSET is s3c64xx and its using definition
from map-s3c.h. I have compiled all related platform defconfigs and
found no issues because of removal of S3C_UART_OFFSET from map-s5p.c and
map.h.

Thanks,
Pankaj Dubey
> Best regards,
> Krzysztof
> 


From linus.walleij at linaro.org  Tue Feb 23 01:10:06 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Feb 2016 10:10:06 +0100
Subject: [PATCH] ARM: realview: add EB syscon variants to bindings
Message-ID: <1456218606-3749-1-git-send-email-linus.walleij@linaro.org>

There are two distinct RealView EB system controller that we need
to detect and handle because their register layout differ
slightly.

Cc: Rob Herring <robh+dt at kernel.org>
Cc: devicetree at vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 Documentation/devicetree/bindings/arm/arm-boards | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards
index 2daeabc519de..7b05fc936d23 100644
--- a/Documentation/devicetree/bindings/arm/arm-boards
+++ b/Documentation/devicetree/bindings/arm/arm-boards
@@ -131,7 +131,9 @@ Required nodes:
 
 - syscon: some subnode of the RealView SoC node must be a
   system controller node pointing to the control registers,
-  with the compatible string set to one of these tuples:
+  with the compatible string set to one of these:
+   "arm,realview-eb11mp-revb-syscon", "arm,realview-eb-syscon", "syscon"
+   "arm,realview-eb11mp-revc-syscon", "arm,realview-eb-syscon", "syscon"
    "arm,realview-eb-syscon", "syscon"
    "arm,realview-pb1176-syscon", "syscon"
    "arm,realview-pb11mp-syscon", "syscon"
-- 
2.4.3



From ldewangan at nvidia.com  Tue Feb 23 01:01:08 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Tue, 23 Feb 2016 14:31:08 +0530
Subject: [PATCH 00/61] gpio: Add and use devm_gpiochip_add_data()
In-Reply-To: <CACRpkdbt+RiWMA74e40MNZVnDM0t0futtFnbyu9sRhv7p93-Tg@mail.gmail.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
 <CACRpkdbt+RiWMA74e40MNZVnDM0t0futtFnbyu9sRhv7p93-Tg@mail.gmail.com>
Message-ID: <56CC1FD4.1080905@nvidia.com>


On Monday 22 February 2016 08:14 PM, Linus Walleij wrote:
> On Mon, Feb 22, 2016 at 3:07 PM, Laxman Dewangan <ldewangan at nvidia.com> wrote:
>
>> Add resource management APIs for gpiochip_add_data() and
>> gpiochip_remove() and use these APIs from different HW drivers.
>>
>> This is based on discussion on patch to use the new APIs.
>>          gpio: Add devm_ apis for gpio_chip_add and remove
> Awesome!
>
> Do you have a git I can just pull these off so I don't have to apply
> then all one-by-one?


Nop, I do not have the git repo for sharing as of now at this time.
Trying to learn to how to create.



From p.zabel at pengutronix.de  Tue Feb 23 01:14:38 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Tue, 23 Feb 2016 10:14:38 +0100
Subject: [PATCH v9 2/6] clk: hisilicon: add CRG driver for hi3519 soc
In-Reply-To: <1456127280-23275-3-git-send-email-xuejiancheng@huawei.com>
References: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
 <1456127280-23275-3-git-send-email-xuejiancheng@huawei.com>
Message-ID: <1456218878.3387.9.camel@pengutronix.de>

Hi,

Am Montag, den 22.02.2016, 15:47 +0800 schrieb Jiancheng Xue:
> The CRG(Clock and Reset Generator) block provides clock
> and reset signals for other modules in hi3519 soc.
> 
> Signed-off-by: Jiancheng Xue <xuejiancheng at huawei.com>
> Acked-by: Rob Herring <robh at kernel.org>
[...]
> diff --git a/drivers/clk/hisilicon/reset.c b/drivers/clk/hisilicon/reset.c
> new file mode 100644
> index 0000000..50e00e7
> --- /dev/null
> +++ b/drivers/clk/hisilicon/reset.c
> @@ -0,0 +1,124 @@
> +/*
> + * Hisilicon Reset Controller Driver
> + *
> + * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * 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/io.h>
> +#include <linux/of_address.h>
> +#include <linux/reset-controller.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +
> +#define	HISI_RESET_BIT_MASK	0x1f
> +#define	HISI_RESET_OFFSET_SHIFT	8
> +#define	HISI_RESET_OFFSET_MASK	0xffff00
> +
> +struct hisi_reset_controller {
> +	spinlock_t	lock;
> +	void __iomem	*membase;
> +	struct reset_controller_dev	rcdev;
> +};
> +
> +
> +#define to_hisi_reset_controller(rcdev)  \
> +	container_of(rcdev, struct hisi_reset_controller, rcdev)
> +
> +static int hisi_reset_of_xlate(struct reset_controller_dev *rcdev,
> +			const struct of_phandle_args *reset_spec)
> +{
> +	u32 offset;
> +	u8 bit;
> +
> +	if (WARN_ON(reset_spec->args_count != rcdev->of_reset_n_cells))
> +		return -EINVAL;

This check now has been moved to the core in e677774f5026 ("reset: Move
DT cell size check to the core"). It is not necessary anymore to check
this in the .of_xlate callback.

> +	offset = (reset_spec->args[0] << HISI_RESET_OFFSET_SHIFT)
> +		& HISI_RESET_OFFSET_MASK;
> +	bit = reset_spec->args[1] & HISI_RESET_BIT_MASK;
> +	return (offset | bit);
> +}
> +
> +static int hisi_reset_assert(struct reset_controller_dev *rcdev,
> +			      unsigned long id)
> +{
> +	struct hisi_reset_controller *rstc = to_hisi_reset_controller(rcdev);
> +	unsigned long flags;
> +	u32 offset, reg;
> +	u8 bit;
> +
> +	offset = (id & HISI_RESET_OFFSET_MASK) >> HISI_RESET_OFFSET_SHIFT;
> +	bit = id & HISI_RESET_BIT_MASK;
> +
> +	spin_lock_irqsave(&rstc->lock, flags);
> +
> +	reg = readl(rstc->membase + offset);
> +	writel(reg | BIT(bit), rstc->membase + offset);
> +
> +	spin_unlock_irqrestore(&rstc->lock, flags);
> +
> +	return 0;
> +}
> +
> +static int hisi_reset_deassert(struct reset_controller_dev *rcdev,
> +				unsigned long id)
> +{
> +	struct hisi_reset_controller *rstc = to_hisi_reset_controller(rcdev);
> +	unsigned long flags;
> +	u32 offset, reg;
> +	u8 bit;
> +
> +	offset = (id & HISI_RESET_OFFSET_MASK) >> HISI_RESET_OFFSET_SHIFT;
> +	bit = id & HISI_RESET_BIT_MASK;
> +
> +	spin_lock_irqsave(&rstc->lock, flags);
> +
> +	reg = readl(rstc->membase + offset);
> +	writel(reg & ~BIT(bit), rstc->membase + offset);
> +
> +	spin_unlock_irqrestore(&rstc->lock, flags);
> +
> +	return 0;
> +}
> +
> +static struct reset_control_ops hisi_reset_ops = {
> +	.assert		= hisi_reset_assert,
> +	.deassert	= hisi_reset_deassert,
> +};

These can be made const after commit 203d4f347d86 ("reset: Make
reset_control_ops const") is merged. Since this is to be merged through
the clock tree, both change could be made later.

For the reset driver part,
Acked-by: Philipp Zabel <p.zabel at pengutronix.de>

regards
Philipp



From pankaj.dubey at samsung.com  Tue Feb 23 01:17:33 2016
From: pankaj.dubey at samsung.com (pankaj.dubey)
Date: Tue, 23 Feb 2016 14:47:33 +0530
Subject: [PATCH 3/3] ARM: EXYNOS: cleanup header files inclusion
In-Reply-To: <56CBA32D.4020905@samsung.com>
References: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
 <1456135396-17767-4-git-send-email-pankaj.dubey@samsung.com>
 <56CBA32D.4020905@samsung.com>
Message-ID: <56CC23AD.10103@samsung.com>

Hi Krzysztof,

On Tuesday 23 February 2016 05:39 AM, Krzysztof Kozlowski wrote:
> On 22.02.2016 19:03, Pankaj Dubey wrote:
>> This includes trivial cleanup in exynos files such as
>>     - remove unused header files inclusion from exynos.c, s5p-dev-mfc.c,
>>       firmware.c, pm.c.
>>     - move inclusion of of.h from common.h to pm.c where it is really
>>       required
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
>> ---
>>  arch/arm/mach-exynos/common.h      | 1 -
>>  arch/arm/mach-exynos/exynos.c      | 5 -----
>>  arch/arm/mach-exynos/firmware.c    | 2 --
>>  arch/arm/mach-exynos/platsmp.c     | 1 -
>>  arch/arm/mach-exynos/pm.c          | 4 +---
>>  arch/arm/mach-exynos/s5p-dev-mfc.c | 1 -
>>  6 files changed, 1 insertion(+), 13 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
>> index e349a03..5365bf1 100644
>> --- a/arch/arm/mach-exynos/common.h
>> +++ b/arch/arm/mach-exynos/common.h
>> @@ -12,7 +12,6 @@
>>  #ifndef __ARCH_ARM_MACH_EXYNOS_COMMON_H
>>  #define __ARCH_ARM_MACH_EXYNOS_COMMON_H
>>  
>> -#include <linux/of.h>
>>  #include <linux/platform_data/cpuidle-exynos.h>
>>  
>>  #define EXYNOS3250_SOC_ID	0xE3472000
>> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
>> index 99947ad..54262a1 100644
>> --- a/arch/arm/mach-exynos/exynos.c
>> +++ b/arch/arm/mach-exynos/exynos.c
>> @@ -11,14 +11,10 @@
>>  
>>  #include <linux/init.h>
>>  #include <linux/io.h>
>> -#include <linux/kernel.h>
>> -#include <linux/serial_s3c.h>
>>  #include <linux/of.h>
>>  #include <linux/of_address.h>
>>  #include <linux/of_fdt.h>
>>  #include <linux/of_platform.h>
>> -#include <linux/platform_device.h>
> 
> platform_device is actually used in that file. It looks unused because
> it is pulled by of_platform, but it makes sense to include it here.
>
Thanks for review.

Well I tried to grep for of_platform.h and platform_device.h in
arch/arm/ and out of 88 files including of_platform.h only 16 files are
including platform_device.h also. So majority do not include both of
them even do they need. So majority of files both are not included. So
If we got with majority it's not required. What's your opinion?

Thanks,
Pankaj Dubey

> Rest looks good.
> 

> BR,
> Krzysztof
> 
> 


From linux.amoon at gmail.com  Tue Feb 23 01:17:18 2016
From: linux.amoon at gmail.com (Anand Moon)
Date: Tue, 23 Feb 2016 14:47:18 +0530
Subject: [PATCH] ARM: dts: add support for gpio buttons for
 exynos5422-odroidxu3
In-Reply-To: <56CC194F.6080905@samsung.com>
References: <1456214467-3344-1-git-send-email-linux.amoon@gmail.com>
 <56CC167A.8040303@samsung.com> <56CC194F.6080905@samsung.com>
Message-ID: <CANAwSgTRu6pb9cdA50AzBSNLS+Y+sssyc_CX7FKuV=FDYWaOsA@mail.gmail.com>

Hi Krzysztof,

On 23 February 2016 at 14:03, Krzysztof Kozlowski
<k.kozlowski at samsung.com> wrote:
> On 23.02.2016 17:21, Krzysztof Kozlowski wrote:
>> On 23.02.2016 17:01, Anand Moon wrote:
>>> Add support for gpio-based button on Odroid-XU3 boards
>>> for reboot/poweroff feature.
>>>
>>> Signed-off-by: Anand Moon <linux.amoon at gmail.com>
>>> ---
>>> changes rebase based on linux next-20160222.
>>>
>>> Tested on Odroid-XU4
>>>
>>> dmesg output.
>>> [    3.286068] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio_keys/power_key[0]' - status (0)
>>> [    3.286206] gpio-11 (power key): gpiod_set_debounce: missing set() or set_debounce() operations
>>> [    3.286600] input: gpio_keys as /devices/platform/gpio_keys/input/input0
>>> ---
>>>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 22 ++++++++++++++++++++++
>>>  1 file changed, 22 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> index 1bd507b..db9770b 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>>> @@ -11,6 +11,7 @@
>>>  */
>>>
>>>  #include <dt-bindings/clock/samsung,s2mps11.h>
>>> +#include <dt-bindings/input/input.h>
>>>  #include <dt-bindings/interrupt-controller/irq.h>
>>>  #include <dt-bindings/gpio/gpio.h>
>>>  #include <dt-bindings/sound/samsung-i2s.h>
>>> @@ -54,6 +55,22 @@
>>>              #cooling-cells = <2>;
>>>              cooling-levels = <0 130 170 230>;
>>>      };
>>> +
>>> +    gpio_keys {
>>> +            compatible = "gpio-keys";
>>> +            pinctrl-names = "default";
>>> +            pinctrl-0 = <&gpio_power_key>;
>>> +
>>> +            power_key {
>>> +                    interrupt-parent = <&gpx0>;
>>> +                    interrupts = <3 IRQ_TYPE_NONE>;
>>
>> Hmmm.... why you specify the interrupts?
>>
>>> +                    gpios = <&gpx0 3 GPIO_ACTIVE_LOW>;
>
> Please, explain it to me. The SW2 key is connected to PWRON of PMIC.
> However you are adding a GPIO key for external interrupt source 3
> (XE.INT3)... which comes from PMIC's ONOB.
>
> It's interesting.... how does it work? The PMIC will generate ONOB
> interrupt on PWRON low->high change (when PWRHOLD is high)?
>
> Best regards,
> Krzysztof
>

I have re-base my changes on HK dts.
I could not find much details for the schematic diagram.
I don't know much low level detains on this.

How dose this works: This changes will initial the shudown/reboot on Ubuntu.
I have also tested this similar feature on Odroid U3.

Best Regards.
-Anand Moon


From s.hauer at pengutronix.de  Tue Feb 23 01:23:56 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Feb 2016 10:23:56 +0100
Subject: [PATCH 7/9] spi: imx: make some register defines simpler
In-Reply-To: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
References: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456219438-21205-8-git-send-email-s.hauer@pengutronix.de>

The watermark levels in the DMA register are write only, the driver
should never have to read them back from the hardware. Replace the
current _MASK and _OFFSET defines with defines taking the watermark
level directly.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 287ec0c..96e32d4 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -256,12 +256,9 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 #define MX51_ECSPI_INT_RREN		(1 <<  3)
 
 #define MX51_ECSPI_DMA      0x14
-#define MX51_ECSPI_DMA_TX_WML_OFFSET	0
-#define MX51_ECSPI_DMA_TX_WML_MASK	0x3F
-#define MX51_ECSPI_DMA_RX_WML_OFFSET	16
-#define MX51_ECSPI_DMA_RX_WML_MASK	(0x3F << 16)
-#define MX51_ECSPI_DMA_RXT_WML_OFFSET	24
-#define MX51_ECSPI_DMA_RXT_WML_MASK	(0x3F << 24)
+#define MX51_ECSPI_DMA_TX_WML(wml)	((wml) & 0x3f)
+#define MX51_ECSPI_DMA_RX_WML(wml)	(((wml) & 0x3f) << 16)
+#define MX51_ECSPI_DMA_RXT_WML(wml)	(((wml) & 0x3f) << 24)
 
 #define MX51_ECSPI_DMA_TEDEN		(1 << 7)
 #define MX51_ECSPI_DMA_RXDEN		(1 << 23)
@@ -408,9 +405,9 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 	 * and enable DMA request.
 	 */
 
-	writel(spi_imx->wml << MX51_ECSPI_DMA_RX_WML_OFFSET |
-		spi_imx->wml << MX51_ECSPI_DMA_TX_WML_OFFSET |
-		spi_imx->wml << MX51_ECSPI_DMA_RXT_WML_OFFSET |
+	writel(MX51_ECSPI_DMA_RX_WML(spi_imx->wml) |
+		MX51_ECSPI_DMA_TX_WML(spi_imx->wml) |
+		MX51_ECSPI_DMA_RXT_WML(spi_imx->wml) |
 		MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
 		MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
 
-- 
2.7.0



From s.hauer at pengutronix.de  Tue Feb 23 01:23:50 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Feb 2016 10:23:50 +0100
Subject: [PATCH 1/9] spi: imx: drop fallback to PIO
In-Reply-To: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
References: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456219438-21205-2-git-send-email-s.hauer@pengutronix.de>

At the moment the driver decides to fallback to PIO mode the buffers
are already mapped for DMA. It's a bug to access them with the CPU
afterwards, so we cannot just fallback to PIO mode.
It should not be necessary anyway, since we only use DMA when we
verified that it's possible in the fist place, so when prep_slave_sg
fails it's a bug, either in the SDMA driver or in the can_dma
implementation.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 19 ++++++-------------
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 6497fc9..a61b1b1 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -945,7 +945,7 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 					tx->sgl, tx->nents, DMA_MEM_TO_DEV,
 					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
 		if (!desc_tx)
-			goto tx_nodma;
+			return -EINVAL;
 
 		desc_tx->callback = spi_imx_dma_tx_callback;
 		desc_tx->callback_param = (void *)spi_imx;
@@ -956,8 +956,10 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 		desc_rx = dmaengine_prep_slave_sg(master->dma_rx,
 					rx->sgl, rx->nents, DMA_DEV_TO_MEM,
 					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
-		if (!desc_rx)
-			goto rx_nodma;
+		if (!desc_rx) {
+			dmaengine_terminate_all(master->dma_tx);
+			return -EINVAL;
+		}
 
 		desc_rx->callback = spi_imx_dma_rx_callback;
 		desc_rx->callback_param = (void *)spi_imx;
@@ -1010,12 +1012,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 		ret = transfer->len;
 
 	return ret;
-
-rx_nodma:
-	dmaengine_terminate_all(master->dma_tx);
-tx_nodma:
-	dev_warn_once(spi_imx->dev, "DMA not available, falling back to PIO\n");
-	return -EAGAIN;
 }
 
 static int spi_imx_pio_transfer(struct spi_device *spi,
@@ -1042,15 +1038,12 @@ static int spi_imx_pio_transfer(struct spi_device *spi,
 static int spi_imx_transfer(struct spi_device *spi,
 				struct spi_transfer *transfer)
 {
-	int ret;
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
 
 	if (spi_imx->bitbang.master->can_dma &&
 	    spi_imx_can_dma(spi_imx->bitbang.master, spi, transfer)) {
 		spi_imx->usedma = true;
-		ret = spi_imx_dma_transfer(spi_imx, transfer);
-		if (ret != -EAGAIN)
-			return ret;
+		return spi_imx_dma_transfer(spi_imx, transfer);
 	}
 	spi_imx->usedma = false;
 
-- 
2.7.0



From s.hauer at pengutronix.de  Tue Feb 23 01:23:49 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Feb 2016 10:23:49 +0100
Subject: [PATCH v3] i.MX SPI DMA cleanup
Message-ID: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>

(hopefully) final round...

Changes since v2:

- Drop patches already applied
- rebase on next

Changes since v1:

- Add missing Signed-off-by to Patch 3
- Drop device tree change as it's already applied by Shawn
- Add patch subject when referring to commits

----------------------------------------------------------------
Anton Bondarenko (1):
      spi: imx: add support for all SPI word width for DMA

Sascha Hauer (8):
      spi: imx: drop fallback to PIO
      spi: imx: initialize usedma earlier
      spi: imx: drop unnecessary read/modify/write
      spi: imx: drop unncessary dma_is_inited variable
      spi: imx: remove unnecessary bit clearing in mx51_ecspi_config
      spi: imx: make some register defines simpler
      spi: imx: set MX51_ECSPI_CTRL_SMC bit in setup function
      spi: imx: drop bogus tests for rx/tx bufs in DMA transfer

 drivers/spi/spi-imx.c | 296 ++++++++++++++++++++++++++------------------------
 1 file changed, 153 insertions(+), 143 deletions(-)


From s.hauer at pengutronix.de  Tue Feb 23 01:23:52 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Feb 2016 10:23:52 +0100
Subject: [PATCH 3/9] spi: imx: drop unnecessary read/modify/write
In-Reply-To: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
References: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456219438-21205-4-git-send-email-s.hauer@pengutronix.de>

When the MX51_ECSPI_DMA is configured we control every single bit
of the register, so there's no need to read/modify/write it. Instead
just write the value we want to have in the register. Also, drop
unnecessary check if we are actually doing DMA. The values written
to the register have no effect in PIO mode and value written there
during the last DMA transfer is still in the register, so we can
equally well always write a value.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 31 ++++++++++---------------------
 1 file changed, 10 insertions(+), 21 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 5792918..ec03304 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -240,9 +240,9 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 #define MX51_ECSPI_DMA_RXT_WML_OFFSET	24
 #define MX51_ECSPI_DMA_RXT_WML_MASK	(0x3F << 24)
 
-#define MX51_ECSPI_DMA_TEDEN_OFFSET	7
-#define MX51_ECSPI_DMA_RXDEN_OFFSET	23
-#define MX51_ECSPI_DMA_RXTDEN_OFFSET	31
+#define MX51_ECSPI_DMA_TEDEN		(1 << 7)
+#define MX51_ECSPI_DMA_RXDEN		(1 << 23)
+#define MX51_ECSPI_DMA_RXTDEN		(1 << 31)
 
 #define MX51_ECSPI_STAT		0x18
 #define MX51_ECSPI_STAT_RR		(1 <<  3)
@@ -318,8 +318,7 @@ static void __maybe_unused mx51_ecspi_trigger(struct spi_imx_data *spi_imx)
 static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 		struct spi_imx_config *config)
 {
-	u32 ctrl = MX51_ECSPI_CTRL_ENABLE, cfg = 0, dma = 0;
-	u32 tx_wml_cfg, rx_wml_cfg, rxt_wml_cfg;
+	u32 ctrl = MX51_ECSPI_CTRL_ENABLE, cfg = 0;
 	u32 clk = config->speed_hz, delay, reg;
 
 	/*
@@ -392,22 +391,12 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 	 * Configure the DMA register: setup the watermark
 	 * and enable DMA request.
 	 */
-	if (spi_imx->dma_is_inited) {
-		dma = readl(spi_imx->base + MX51_ECSPI_DMA);
-
-		rx_wml_cfg = spi_imx->wml << MX51_ECSPI_DMA_RX_WML_OFFSET;
-		tx_wml_cfg = spi_imx->wml << MX51_ECSPI_DMA_TX_WML_OFFSET;
-		rxt_wml_cfg = spi_imx->wml << MX51_ECSPI_DMA_RXT_WML_OFFSET;
-		dma = (dma & ~MX51_ECSPI_DMA_TX_WML_MASK
-			   & ~MX51_ECSPI_DMA_RX_WML_MASK
-			   & ~MX51_ECSPI_DMA_RXT_WML_MASK)
-			   | rx_wml_cfg | tx_wml_cfg | rxt_wml_cfg
-			   |(1 << MX51_ECSPI_DMA_TEDEN_OFFSET)
-			   |(1 << MX51_ECSPI_DMA_RXDEN_OFFSET)
-			   |(1 << MX51_ECSPI_DMA_RXTDEN_OFFSET);
-
-		writel(dma, spi_imx->base + MX51_ECSPI_DMA);
-	}
+
+	writel(spi_imx->wml << MX51_ECSPI_DMA_RX_WML_OFFSET |
+		spi_imx->wml << MX51_ECSPI_DMA_TX_WML_OFFSET |
+		spi_imx->wml << MX51_ECSPI_DMA_RXT_WML_OFFSET |
+		MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
+		MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
 
 	return 0;
 }
-- 
2.7.0



From s.hauer at pengutronix.de  Tue Feb 23 01:23:55 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Feb 2016 10:23:55 +0100
Subject: [PATCH 6/9] spi: imx: remove unnecessary bit clearing in
 mx51_ecspi_config
In-Reply-To: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
References: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456219438-21205-7-git-send-email-s.hauer@pengutronix.de>

This reverts patch 1476253cef (spi: imx: fix ecspi mode setup)
The patch tried to fix something by clearing bits in the cfg variable,
but cfg is initialized to zero on function entry. There are no bits to
clear.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 15b23f0..287ec0c 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -366,20 +366,13 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 
 	if (config->mode & SPI_CPHA)
 		cfg |= MX51_ECSPI_CONFIG_SCLKPHA(config->cs);
-	else
-		cfg &= ~MX51_ECSPI_CONFIG_SCLKPHA(config->cs);
 
 	if (config->mode & SPI_CPOL) {
 		cfg |= MX51_ECSPI_CONFIG_SCLKPOL(config->cs);
 		cfg |= MX51_ECSPI_CONFIG_SCLKCTL(config->cs);
-	} else {
-		cfg &= ~MX51_ECSPI_CONFIG_SCLKPOL(config->cs);
-		cfg &= ~MX51_ECSPI_CONFIG_SCLKCTL(config->cs);
 	}
 	if (config->mode & SPI_CS_HIGH)
 		cfg |= MX51_ECSPI_CONFIG_SSBPOL(config->cs);
-	else
-		cfg &= ~MX51_ECSPI_CONFIG_SSBPOL(config->cs);
 
 	/* CTRL register always go first to bring out controller from reset */
 	writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
-- 
2.7.0



From s.hauer at pengutronix.de  Tue Feb 23 01:23:58 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Feb 2016 10:23:58 +0100
Subject: [PATCH 9/9] spi: imx: drop bogus tests for rx/tx bufs in DMA transfer
In-Reply-To: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
References: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456219438-21205-10-git-send-email-s.hauer@pengutronix.de>

The driver tries to be clever by only setting up DMA channels when
the corresponding sg tables are non NULL. The sg tables are embedded
structs in struct spi_transfer, so they are guaranteed to be non NULL
which makes the if(tx)/if(rx) tests completely bogus. The driver even
sets the SPI_MASTER_MUST_RX / SPI_MASTER_MUST_TX flags which makes sure
the sg tables are not only present but also non empty.
Drop the tests and make the DMA path easier to follow.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 82 +++++++++++++++++++++------------------------------
 1 file changed, 34 insertions(+), 48 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 91890b2..e7a19be 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -974,51 +974,40 @@ static int spi_imx_calculate_timeout(struct spi_imx_data *spi_imx, int size)
 static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 				struct spi_transfer *transfer)
 {
-	struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
-	int ret;
+	struct dma_async_tx_descriptor *desc_tx, *desc_rx;
 	unsigned long transfer_timeout;
 	unsigned long timeout;
 	struct spi_master *master = spi_imx->bitbang.master;
 	struct sg_table *tx = &transfer->tx_sg, *rx = &transfer->rx_sg;
 
-	if (tx) {
-		desc_tx = dmaengine_prep_slave_sg(master->dma_tx,
-					tx->sgl, tx->nents, DMA_MEM_TO_DEV,
-					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
-		if (!desc_tx)
-			return -EINVAL;
-
-		desc_tx->callback = spi_imx_dma_tx_callback;
-		desc_tx->callback_param = (void *)spi_imx;
-		dmaengine_submit(desc_tx);
-	}
+	/*
+	 * The TX DMA setup starts the transfer, so make sure RX is configured
+	 * before TX.
+	 */
+	desc_rx = dmaengine_prep_slave_sg(master->dma_rx,
+				rx->sgl, rx->nents, DMA_DEV_TO_MEM,
+				DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	if (!desc_rx)
+		return -EINVAL;
 
-	if (rx) {
-		desc_rx = dmaengine_prep_slave_sg(master->dma_rx,
-					rx->sgl, rx->nents, DMA_DEV_TO_MEM,
-					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
-		if (!desc_rx) {
-			dmaengine_terminate_all(master->dma_tx);
-			return -EINVAL;
-		}
+	desc_rx->callback = spi_imx_dma_rx_callback;
+	desc_rx->callback_param = (void *)spi_imx;
+	dmaengine_submit(desc_rx);
+	reinit_completion(&spi_imx->dma_rx_completion);
+	dma_async_issue_pending(master->dma_rx);
 
-		desc_rx->callback = spi_imx_dma_rx_callback;
-		desc_rx->callback_param = (void *)spi_imx;
-		dmaengine_submit(desc_rx);
+	desc_tx = dmaengine_prep_slave_sg(master->dma_tx,
+				tx->sgl, tx->nents, DMA_MEM_TO_DEV,
+				DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	if (!desc_tx) {
+		dmaengine_terminate_all(master->dma_tx);
+		return -EINVAL;
 	}
 
-	reinit_completion(&spi_imx->dma_rx_completion);
+	desc_tx->callback = spi_imx_dma_tx_callback;
+	desc_tx->callback_param = (void *)spi_imx;
+	dmaengine_submit(desc_tx);
 	reinit_completion(&spi_imx->dma_tx_completion);
-
-	/*
-	 * Set these order to avoid potential RX overflow. The overflow may
-	 * happen if we enable SPI HW before starting RX DMA due to rescheduling
-	 * for another task and/or interrupt.
-	 * So RX DMA enabled first to make sure data would be read out from FIFO
-	 * ASAP. TX DMA enabled next to start filling TX FIFO with new data.
-	 * And finaly SPI HW enabled to start actual data transfer.
-	 */
-	dma_async_issue_pending(master->dma_rx);
 	dma_async_issue_pending(master->dma_tx);
 
 	transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len);
@@ -1030,22 +1019,19 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 		dev_err(spi_imx->dev, "I/O Error in DMA TX\n");
 		dmaengine_terminate_all(master->dma_tx);
 		dmaengine_terminate_all(master->dma_rx);
-	} else {
-		timeout = wait_for_completion_timeout(
-				&spi_imx->dma_rx_completion, transfer_timeout);
-		if (!timeout) {
-			dev_err(spi_imx->dev, "I/O Error in DMA RX\n");
-			spi_imx->devtype_data->reset(spi_imx);
-			dmaengine_terminate_all(master->dma_rx);
-		}
+		return -ETIMEDOUT;
 	}
 
-	if (!timeout)
-		ret = -ETIMEDOUT;
-	else
-		ret = transfer->len;
+	timeout = wait_for_completion_timeout(&spi_imx->dma_rx_completion,
+					      transfer_timeout);
+	if (!timeout) {
+		dev_err(&master->dev, "I/O Error in DMA RX\n");
+		spi_imx->devtype_data->reset(spi_imx);
+		dmaengine_terminate_all(master->dma_rx);
+		return -ETIMEDOUT;
+	}
 
-	return ret;
+	return transfer->len;
 }
 
 static int spi_imx_pio_transfer(struct spi_device *spi,
-- 
2.7.0



From s.hauer at pengutronix.de  Tue Feb 23 01:23:54 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Feb 2016 10:23:54 +0100
Subject: [PATCH 5/9] spi: imx: add support for all SPI word width for DMA
In-Reply-To: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
References: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456219438-21205-6-git-send-email-s.hauer@pengutronix.de>

From: Anton Bondarenko <anton.bondarenko.sama at gmail.com>

DMA transfer for SPI was limited to up to 8 bits word size until now.
Sync in SPI burst size and DMA bus width is necessary to correctly
support 16 and 32 BPW.

Signed-off-by: Anton Bondarenko <anton.bondarenko.sama at gmail.com>
Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 118 ++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 91 insertions(+), 27 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 567a242..15b23f0 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -89,11 +89,15 @@ struct spi_imx_data {
 
 	struct completion xfer_done;
 	void __iomem *base;
+	unsigned long base_phys;
+
 	struct clk *clk_per;
 	struct clk *clk_ipg;
 	unsigned long spi_clk;
 	unsigned int spi_bus_clk;
 
+	unsigned int bytes_per_word;
+
 	unsigned int count;
 	void (*tx)(struct spi_imx_data *);
 	void (*rx)(struct spi_imx_data *);
@@ -199,15 +203,35 @@ static unsigned int spi_imx_clkdiv_2(unsigned int fin,
 	return 7;
 }
 
+static int spi_imx_bytes_per_word(const int bpw)
+{
+	return DIV_ROUND_UP(bpw, BITS_PER_BYTE);
+}
+
 static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 			 struct spi_transfer *transfer)
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+	unsigned int bpw = transfer->bits_per_word;
+
+	if (!master->dma_rx)
+		return false;
+
+	if (!bpw)
+		bpw = spi->bits_per_word;
+
+	bpw = spi_imx_bytes_per_word(bpw);
+
+	if (bpw != 1 && bpw != 2 && bpw != 4)
+		return false;
+
+	if (transfer->len < spi_imx->wml * bpw)
+		return false;
+
+	if (transfer->len % (spi_imx->wml * bpw))
+		return false;
 
-	if (master->dma_rx && transfer->len >= spi_imx->wml &&
-	    (transfer->len % spi_imx->wml) == 0)
-		return true;
-	return false;
+	return true;
 }
 
 #define MX51_ECSPI_CTRL		0x08
@@ -775,11 +799,63 @@ static irqreturn_t spi_imx_isr(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static int spi_imx_dma_configure(struct spi_master *master,
+				 int bytes_per_word)
+{
+	int ret;
+	enum dma_slave_buswidth buswidth;
+	struct dma_slave_config rx = {}, tx = {};
+	struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+
+	if (bytes_per_word == spi_imx->bytes_per_word)
+		/* Same as last time */
+		return 0;
+
+	switch (bytes_per_word) {
+	case 4:
+		buswidth = DMA_SLAVE_BUSWIDTH_4_BYTES;
+		break;
+	case 2:
+		buswidth = DMA_SLAVE_BUSWIDTH_2_BYTES;
+		break;
+	case 1:
+		buswidth = DMA_SLAVE_BUSWIDTH_1_BYTE;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	tx.direction = DMA_MEM_TO_DEV;
+	tx.dst_addr = spi_imx->base_phys + MXC_CSPITXDATA;
+	tx.dst_addr_width = buswidth;
+	tx.dst_maxburst = spi_imx->wml;
+	ret = dmaengine_slave_config(master->dma_tx, &tx);
+	if (ret) {
+		dev_err(spi_imx->dev, "TX dma configuration failed with %d\n", ret);
+		return ret;
+	}
+
+	rx.direction = DMA_DEV_TO_MEM;
+	rx.src_addr = spi_imx->base_phys + MXC_CSPIRXDATA;
+	rx.src_addr_width = buswidth;
+	rx.src_maxburst = spi_imx->wml;
+	ret = dmaengine_slave_config(master->dma_rx, &rx);
+	if (ret) {
+		dev_err(spi_imx->dev, "RX dma configuration failed with %d\n", ret);
+		return ret;
+	}
+
+	spi_imx->bytes_per_word = bytes_per_word;
+
+	return 0;
+}
+
 static int spi_imx_setupxfer(struct spi_device *spi,
 				 struct spi_transfer *t)
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
 	struct spi_imx_config config;
+	int ret;
 
 	config.bpw = t ? t->bits_per_word : spi->bits_per_word;
 	config.speed_hz  = t ? t->speed_hz : spi->max_speed_hz;
@@ -808,6 +884,13 @@ static int spi_imx_setupxfer(struct spi_device *spi,
 	else
 		spi_imx->usedma = 0;
 
+	if (spi_imx->usedma) {
+		ret = spi_imx_dma_configure(spi->master,
+					    spi_imx_bytes_per_word(config.bpw));
+		if (ret)
+			return ret;
+	}
+
 	spi_imx->devtype_data->config(spi_imx, &config);
 
 	return 0;
@@ -829,10 +912,8 @@ static void spi_imx_sdma_exit(struct spi_imx_data *spi_imx)
 }
 
 static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
-			     struct spi_master *master,
-			     const struct resource *res)
+			     struct spi_master *master)
 {
-	struct dma_slave_config slave_config = {};
 	int ret;
 
 	/* use pio mode for i.mx6dl chip TKT238285 */
@@ -850,16 +931,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 		goto err;
 	}
 
-	slave_config.direction = DMA_MEM_TO_DEV;
-	slave_config.dst_addr = res->start + MXC_CSPITXDATA;
-	slave_config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
-	slave_config.dst_maxburst = spi_imx->wml;
-	ret = dmaengine_slave_config(master->dma_tx, &slave_config);
-	if (ret) {
-		dev_err(dev, "error in TX dma configuration.\n");
-		goto err;
-	}
-
 	/* Prepare for RX : */
 	master->dma_rx = dma_request_slave_channel_reason(dev, "rx");
 	if (IS_ERR(master->dma_rx)) {
@@ -869,15 +940,7 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 		goto err;
 	}
 
-	slave_config.direction = DMA_DEV_TO_MEM;
-	slave_config.src_addr = res->start + MXC_CSPIRXDATA;
-	slave_config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
-	slave_config.src_maxburst = spi_imx->wml;
-	ret = dmaengine_slave_config(master->dma_rx, &slave_config);
-	if (ret) {
-		dev_err(dev, "error in RX dma configuration.\n");
-		goto err;
-	}
+	spi_imx_dma_configure(master, 1);
 
 	init_completion(&spi_imx->dma_rx_completion);
 	init_completion(&spi_imx->dma_tx_completion);
@@ -1164,6 +1227,7 @@ static int spi_imx_probe(struct platform_device *pdev)
 		ret = PTR_ERR(spi_imx->base);
 		goto out_master_put;
 	}
+	spi_imx->base_phys = res->start;
 
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
@@ -1204,7 +1268,7 @@ static int spi_imx_probe(struct platform_device *pdev)
 	 * other chips.
 	 */
 	if (is_imx51_ecspi(spi_imx)) {
-		ret = spi_imx_sdma_init(&pdev->dev, spi_imx, master, res);
+		ret = spi_imx_sdma_init(&pdev->dev, spi_imx, master);
 		if (ret == -EPROBE_DEFER)
 			goto out_clk_put;
 
-- 
2.7.0



From s.hauer at pengutronix.de  Tue Feb 23 01:23:57 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Feb 2016 10:23:57 +0100
Subject: [PATCH 8/9] spi: imx: set MX51_ECSPI_CTRL_SMC bit in setup function
In-Reply-To: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
References: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456219438-21205-9-git-send-email-s.hauer@pengutronix.de>

Now that the config function knows whether we are doing DMA or not we
can do the necessary register setup in the config function and no longer
have to do this in the trigger function. With this the trigger function
becomes a no-op for DMA, so instead of testing if we are doing DMA or
not in the trigger function we simply no longer call it in the DMA case.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 21 ++++++---------------
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 96e32d4..91890b2 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -106,7 +106,6 @@ struct spi_imx_data {
 	unsigned int txfifo; /* number of words pushed in tx FIFO */
 
 	/* DMA */
-	unsigned int dma_finished;
 	bool usedma;
 	u32 wml;
 	struct completion dma_rx_completion;
@@ -324,14 +323,10 @@ static void __maybe_unused mx51_ecspi_intctrl(struct spi_imx_data *spi_imx, int
 
 static void __maybe_unused mx51_ecspi_trigger(struct spi_imx_data *spi_imx)
 {
-	u32 reg = readl(spi_imx->base + MX51_ECSPI_CTRL);
+	u32 reg;
 
-	if (!spi_imx->usedma)
-		reg |= MX51_ECSPI_CTRL_XCH;
-	else if (!spi_imx->dma_finished)
-		reg |= MX51_ECSPI_CTRL_SMC;
-	else
-		reg &= ~MX51_ECSPI_CTRL_SMC;
+	reg = readl(spi_imx->base + MX51_ECSPI_CTRL);
+	reg |= MX51_ECSPI_CTRL_XCH;
 	writel(reg, spi_imx->base + MX51_ECSPI_CTRL);
 }
 
@@ -371,6 +366,9 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 	if (config->mode & SPI_CS_HIGH)
 		cfg |= MX51_ECSPI_CONFIG_SSBPOL(config->cs);
 
+	if (spi_imx->usedma)
+		ctrl |= MX51_ECSPI_CTRL_SMC;
+
 	/* CTRL register always go first to bring out controller from reset */
 	writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
 
@@ -1012,9 +1010,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	reinit_completion(&spi_imx->dma_rx_completion);
 	reinit_completion(&spi_imx->dma_tx_completion);
 
-	/* Trigger the cspi module. */
-	spi_imx->dma_finished = 0;
-
 	/*
 	 * Set these order to avoid potential RX overflow. The overflow may
 	 * happen if we enable SPI HW before starting RX DMA due to rescheduling
@@ -1025,7 +1020,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	 */
 	dma_async_issue_pending(master->dma_rx);
 	dma_async_issue_pending(master->dma_tx);
-	spi_imx->devtype_data->trigger(spi_imx);
 
 	transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len);
 
@@ -1046,9 +1040,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 		}
 	}
 
-	spi_imx->dma_finished = 1;
-	spi_imx->devtype_data->trigger(spi_imx);
-
 	if (!timeout)
 		ret = -ETIMEDOUT;
 	else
-- 
2.7.0



From s.hauer at pengutronix.de  Tue Feb 23 01:23:53 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Feb 2016 10:23:53 +0100
Subject: [PATCH 4/9] spi: imx: drop unncessary dma_is_inited variable
In-Reply-To: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
References: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456219438-21205-5-git-send-email-s.hauer@pengutronix.de>

There's no need for an extra dma_is_inited variable when we can
equally well check for the existence of a DMA channel.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index ec03304..567a242 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -102,7 +102,6 @@ struct spi_imx_data {
 	unsigned int txfifo; /* number of words pushed in tx FIFO */
 
 	/* DMA */
-	unsigned int dma_is_inited;
 	unsigned int dma_finished;
 	bool usedma;
 	u32 wml;
@@ -205,7 +204,7 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
 
-	if (spi_imx->dma_is_inited && transfer->len >= spi_imx->wml &&
+	if (master->dma_rx && transfer->len >= spi_imx->wml &&
 	    (transfer->len % spi_imx->wml) == 0)
 		return true;
 	return false;
@@ -827,8 +826,6 @@ static void spi_imx_sdma_exit(struct spi_imx_data *spi_imx)
 		dma_release_channel(master->dma_tx);
 		master->dma_tx = NULL;
 	}
-
-	spi_imx->dma_is_inited = 0;
 }
 
 static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
@@ -888,7 +885,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 	master->max_dma_len = MAX_SDMA_BD_BYTES;
 	spi_imx->bitbang.master->flags = SPI_MASTER_MUST_RX |
 					 SPI_MASTER_MUST_TX;
-	spi_imx->dma_is_inited = 1;
 
 	return 0;
 err:
-- 
2.7.0



From s.hauer at pengutronix.de  Tue Feb 23 01:23:51 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Feb 2016 10:23:51 +0100
Subject: [PATCH 2/9] spi: imx: initialize usedma earlier
In-Reply-To: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
References: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456219438-21205-3-git-send-email-s.hauer@pengutronix.de>

So that the SoC specific config function can know if we will do
DMA or not. Will be needed in following patches.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index a61b1b1..5792918 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -815,6 +815,11 @@ static int spi_imx_setupxfer(struct spi_device *spi,
 		spi_imx->tx = spi_imx_buf_tx_u32;
 	}
 
+	if (spi_imx_can_dma(spi_imx->bitbang.master, spi, t))
+		spi_imx->usedma = 1;
+	else
+		spi_imx->usedma = 0;
+
 	spi_imx->devtype_data->config(spi_imx, &config);
 
 	return 0;
@@ -1040,14 +1045,10 @@ static int spi_imx_transfer(struct spi_device *spi,
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
 
-	if (spi_imx->bitbang.master->can_dma &&
-	    spi_imx_can_dma(spi_imx->bitbang.master, spi, transfer)) {
-		spi_imx->usedma = true;
+	if (spi_imx->usedma)
 		return spi_imx_dma_transfer(spi_imx, transfer);
-	}
-	spi_imx->usedma = false;
-
-	return spi_imx_pio_transfer(spi, transfer);
+	else
+		return spi_imx_pio_transfer(spi, transfer);
 }
 
 static int spi_imx_setup(struct spi_device *spi)
-- 
2.7.0



From thomas.petazzoni at free-electrons.com  Tue Feb 23 01:25:50 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 23 Feb 2016 10:25:50 +0100
Subject: [PATCH 2/3] clk: mvebu: add AP806 core clock driver
In-Reply-To: <CAL_Jsq+iiUBcTdnqzFWLJ+5jPvq0rmWgBboab4xyj1dQyDQE+Q@mail.gmail.com>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455521698-7905-3-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160222025357.GE15973@rob-hp-laptop>
 <20160222091423.4756a579@free-electrons.com>
 <20160222141617.GA14970@lunn.ch>
 <20160222183203.2278.60153@quark.deferred.io>
 <CAL_Jsq+iiUBcTdnqzFWLJ+5jPvq0rmWgBboab4xyj1dQyDQE+Q@mail.gmail.com>
Message-ID: <20160223102550.2e0cba04@free-electrons.com>

Hello,

On Mon, 22 Feb 2016 13:42:49 -0600, Rob Herring wrote:

> >> Maybe add a big fat warning that the bindings are unstable, and the DT
> >> blob must be kept in sync with the kernel?
> >
> > +1 and feel free to blame the lack of documentation.  No one can expect
> > bindings to be finalized when the chip topology is not fully understood.
> 
> I can understand not understanding the full clock tree. I have "full"
> documentation of a Marvell chip and don't understand the clock tree
> fully. But I can't believe you don't have some sense of how many
> clocks you have to deal with. 10? 100? 1000? What I see is 2 nodes of
> a single register each for clocks at roughly the same address. That
> tells me your binding is too fine grained. If you really don't know
> what is right, then err on the side of a single clock provider node
> and don't put the clock details in DT.

I don't quite understand the reasoning behind this conclusion. We know
for sure that those two registers control only those core and ring
clocks. Maybe there are other registers controlling other clocks,  that
we don't know. But for sure, those two registers only give details
about those core and ring clocks, so I don't see what would be the
usefulness of merging that into a single DT node.

We would lose the fact that the relationship between the ring clocks
and one of the core clock is represented in the DT. Instead of having a
clear <&coreclk X> or <&ringclk Y> reference, we would have a
mysterious <&allclk XYZ> reference, which doesn't tell immediately
whether it's a core clock or ring clock.

So, while I definitely agree that a syscon is probably in order to
cover all the system registers, I don't see the point of having a
single node to cover all the clocks.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From shannon.zhao at linaro.org  Tue Feb 23 01:29:01 2016
From: shannon.zhao at linaro.org (Shannon Zhao)
Date: Tue, 23 Feb 2016 17:29:01 +0800
Subject: [PATCH v12 03/21] KVM: ARM64: Add offset defines for PMU registers
In-Reply-To: <56CBBA06.4040902@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
 <1456133877-9584-4-git-send-email-zhaoshenglong@huawei.com>
 <56CB4A98.2020403@arm.com> <56CBBA06.4040902@huawei.com>
Message-ID: <56CC265D.9000406@linaro.org>



On 2016/2/23 9:46, Shannon Zhao wrote:
> 
> On 2016/2/23 1:51, Marc Zyngier wrote:
>> > On 22/02/16 09:37, Shannon Zhao wrote:
>>> >> From: Shannon Zhao <shannon.zhao at linaro.org>
>>> >>
>>> >> We are about to trap and emulate accesses to each PMU register
>>> >> individually. This adds the context offsets for the AArch64 PMU
>>> >> registers.
>>> >>
>>> >> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
>>> >> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
>>> >> Reviewed-by: Andrew Jones <drjones at redhat.com>
>>> >> ---
>>> >>  arch/arm64/include/asm/kvm_host.h | 15 +++++++++++++++
>>> >>  1 file changed, 15 insertions(+)
>>> >>
>>> >> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>>> >> index 6f0241f..6bab7fb 100644
>>> >> --- a/arch/arm64/include/asm/kvm_host.h
>>> >> +++ b/arch/arm64/include/asm/kvm_host.h
>>> >> @@ -115,6 +115,21 @@ enum vcpu_sysreg {
>>> >>  	MDSCR_EL1,	/* Monitor Debug System Control Register */
>>> >>  	MDCCINT_EL1,	/* Monitor Debug Comms Channel Interrupt Enable Reg */
>>> >>  
>>> >> +	/* Performance Monitors Registers */
>>> >> +	PMCR_EL0,	/* Control Register */
>>> >> +	PMOVSSET_EL0,	/* Overflow Flag Status Set Register */
>>> >> +	PMSELR_EL0,	/* Event Counter Selection Register */
>>> >> +	PMEVCNTR0_EL0,	/* Event Counter Register (0-30) */
>>> >> +	PMEVCNTR30_EL0 = PMEVCNTR0_EL0 + 30,
>>> >> +	PMCCNTR_EL0,	/* Cycle Counter Register */
>>> >> +	PMEVTYPER0_EL0,	/* Event Type Register (0-30) */
>>> >> +	PMEVTYPER30_EL0 = PMEVTYPER0_EL0 + 30,
>>> >> +	PMCCFILTR_EL0,	/* Cycle Count Filter Register */
>>> >> +	PMCNTENSET_EL0,	/* Count Enable Set Register */
>>> >> +	PMINTENSET_EL1,	/* Interrupt Enable Set Register */
>>> >> +	PMUSERENR_EL0,	/* User Enable Register */
>>> >> +	PMSWINC_EL0,	/* Software Increment Register */
>>> >> +
>> > 
>> > I've just noticed a rather fundamental issue with this: this makes it
>> > impossible to bisect the whole series.
>> > 
> Ah, sorry. Will fix this.
> 
I've fixed this problem and pushed this series to below place. You can
fetch it from there.

https://git.linaro.org/people/shannon.zhao/linux-mainline.git/shortlog/refs/heads/KVM_ARM64_PMU_v13

Thanks,
-- 
Shannon


From John.Youn at synopsys.com  Tue Feb 23 01:31:25 2016
From: John.Youn at synopsys.com (John Youn)
Date: Tue, 23 Feb 2016 01:31:25 -0800
Subject: [PATCH 0/2] usb: dwc2: Remove host and gadget only code from core
In-Reply-To: <cover.1456213319.git.johnyoun@synopsys.com>
References: <cover.1456213319.git.johnyoun@synopsys.com>
Message-ID: <56CC26ED.50004@synopsys.com>

On 2/23/2016 12:35 AM, John Youn wrote:
> This series moves the host/gadget-specific code from core.c to hcd.c
> and gadget.c so that they will be compiled only when their respective
> configurations are selected, or in DRD.
> 
> This is mostly just a straight move of the code. I have also added
> some comments to group related functions together.
> 
> Compiled and tested in all three modes.
> 
> This should also solve the issue reported here:
> http://marc.info/?l=linux-usb&m=145591813410106&w=2
> 
> Although I wasn't able to test it... couldn't figure out how to
> disable CONFIG_USB and enable DWC2 in gadget mode.
> 
> Felipe,
> 
> This should be applied after Doug's series on your testing/next
> branch.
> 
> 

Hi Felipe,

Patch 2/2 is triggering our corporate mail filters however I try to
send it. I'll look into this with IT tomorrow, maybe have to send it
from another account.

Regards,
John


From arnd at arndb.de  Tue Feb 23 01:35:47 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 10:35:47 +0100
Subject: [PATCH v2] MAINTAINERS: Extend info,
 add wiki and ml for meson arch
In-Reply-To: <CAOQ7t2Zrx7N3a=RKpr2M3R6QYDeC=8yUs61NrohvrbT=vvjLiQ@mail.gmail.com>
References: <1455575651-16157-1-git-send-email-carlo@caione.org>
 <CAOQ7t2Zrx7N3a=RKpr2M3R6QYDeC=8yUs61NrohvrbT=vvjLiQ@mail.gmail.com>
Message-ID: <2635297.jXo9vSA2rm@wuerfel>

On Tuesday 23 February 2016 09:58:37 Carlo Caione wrote:
> 
> Hey Arnd,
> Does this usually go through the armsoc tree?
> 

Yes, I've put it in my todo folder now, but maybe resend to arm at kernel.org
anyway so Olof also sees it.

	Arnd


From arnd at arndb.de  Tue Feb 23 01:34:46 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 10:34:46 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
Message-ID: <3695074.sKSIyOjpjD@wuerfel>

On Tuesday 23 February 2016 10:08:05 Linus Walleij wrote:
> I will think of a better solution, if any, for this for v4.6, but will
> put forward something that handles the Nomadik and all the
> other ARM reference designs for now.
> 

How about still describing all known panels in the DT marked 'status="disabled"',
but then having a minimal piece of board specific code that just enables
whichever one gets detected at boot time?

	Arnd


From carlo at caione.org  Tue Feb 23 01:43:11 2016
From: carlo at caione.org (Carlo Caione)
Date: Tue, 23 Feb 2016 10:43:11 +0100
Subject: [PATCH v2] MAINTAINERS: Extend info, add wiki and ml for meson arch
Message-ID: <1456220591-11901-1-git-send-email-carlo@caione.org>

From: Carlo Caione <carlo at endlessm.com>

Update the maintainers info with wiki and mailing list for the meson
platform. Fix a wrong file attribution and add maintainership for the
generic meson platforms.

Signed-off-by: Carlo Caione <carlo at endlessm.com>
---
 MAINTAINERS | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2fa3303..e913098 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -920,12 +920,15 @@ M:	Emilio L?pez <emilio at elopez.com.ar>
 S:	Maintained
 F:	drivers/clk/sunxi/
 
-ARM/Amlogic MesonX SoC support
+ARM/Amlogic Meson SoC support
 M:	Carlo Caione <carlo at caione.org>
 L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+L:	linux-meson at googlegroups.com
+W:	http://linux-meson.com/
 S:	Maintained
-F:	drivers/media/rc/meson-ir.c
-N:	meson[x68]
+F:	arch/arm/mach-meson/
+F:	arch/arm/boot/dts/meson*
+N:	meson
 
 ARM/Annapurna Labs ALPINE ARCHITECTURE
 M:	Tsahee Zidenberg <tsahee at annapurnalabs.com>
-- 
2.5.0



From nsekhar at ti.com  Tue Feb 23 01:53:33 2016
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 23 Feb 2016 15:23:33 +0530
Subject: [GIT PULL] DaVinci fixes for v4.6
Message-ID: <1456221214-18042-1-git-send-email-nsekhar@ti.com>

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.6/fixes

for you to fetch changes up to 8e58041114319ad290e85a7a82077dc9e2f93613:

  ARM: davinci: make I2C support optional (2016-02-17 19:20:05 +0530)

----------------------------------------------------------------
Warning fixes for DaVinci collected while testing
randconfig builds.

----------------------------------------------------------------
Arnd Bergmann (4):
      ARM: davinci: limit DT support to DA850
      ARM: davinci: avoid unused mityomapl138_pn_info variable
      ARM: davinci: DA8xx+DMx combined kernels need PATCH_PHYS_VIRT
      ARM: davinci: make I2C support optional

 arch/arm/Kconfig                           |  1 +
 arch/arm/mach-davinci/Kconfig              | 22 ++++------------------
 arch/arm/mach-davinci/board-dm644x-evm.c   |  8 ++++++--
 arch/arm/mach-davinci/board-dm646x-evm.c   |  7 +++++++
 arch/arm/mach-davinci/board-mityomapl138.c |  2 +-
 5 files changed, 19 insertions(+), 21 deletions(-)


From nsekhar at ti.com  Tue Feb 23 01:53:34 2016
From: nsekhar at ti.com (Sekhar Nori)
Date: Tue, 23 Feb 2016 15:23:34 +0530
Subject: [GIT PULL] DaVinci EDMA enhancements for v4.6
In-Reply-To: <1456221214-18042-1-git-send-email-nsekhar@ti.com>
References: <1456221214-18042-1-git-send-email-nsekhar@ti.com>
Message-ID: <1456221214-18042-2-git-send-email-nsekhar@ti.com>

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.6/edma

for you to fetch changes up to 2137d54d1643c1dcb1ff919f169b4542669a372e:

  ARM: davinci: dm646x: Add dma_slave_map to edma (2016-02-22 15:55:27 +0530)

----------------------------------------------------------------
Pass dma_slave_map data to EDMA driver. This will help
migration to new DMA engine API for requesting
slave channels dma_request_chan().

----------------------------------------------------------------
Peter Ujfalusi (5):
      ARM: davinci: devices-da8xx: Add dma_slave_map to edma
      ARM: davinci: dm355: Add dma_slave_map to edma
      ARM: davinci: dm365: Add dma_slave_map to edma
      ARM: davinci: dm644x: Add dma_slave_map to edma
      ARM: davinci: dm646x: Add dma_slave_map to edma

 arch/arm/mach-davinci/devices-da8xx.c | 46 +++++++++++++++++++++++++++++++++++
 arch/arm/mach-davinci/dm355.c         | 20 +++++++++++++++
 arch/arm/mach-davinci/dm365.c         | 22 +++++++++++++++++
 arch/arm/mach-davinci/dm644x.c        | 12 +++++++++
 arch/arm/mach-davinci/dm646x.c        | 11 +++++++++
 5 files changed, 111 insertions(+)


From tomi.valkeinen at ti.com  Tue Feb 23 01:58:17 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 23 Feb 2016 11:58:17 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
Message-ID: <56CC2D39.80909@ti.com>

(cc'ing a few more people as this is going into generic direction)

On 23/02/16 11:08, Linus Walleij wrote:
> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> 
>> This moves the versatile CLCD configuration to the device tree by:
> 
> As this Schr?dinger's cat approach seems controversial, as well
> as the alternative to manipulate the DT in memory at run-time,
> I will respin the series without the full Versatile support, adding
> plug-in for the other ARM boards and and half-baked support
> for the Versatile supporting just VGA (like the other reference
> designs from ARM).
> 
> The pluggable displays prove yet again to be a problem to the
> world, sigh.
> 
> I will think of a better solution, if any, for this for v4.6, but will
> put forward something that handles the Nomadik and all the
> other ARM reference designs for now.

I had a chat with Tom Rini and Pantelis Antoniou yesterday.

Panto is about to send a new series for DT overlay management soon. I
haven't had time to test that yet, but what it would give us is that you
could build DT overlay binaries as "firmware" into the kernel image, and
thus the panel DT data would be there even before rootfs is mounted. The
DT overlays can be loaded from the rootfs or initramfs too, if it's not
critical to get the display up early.

I'm not quite sure how it works if, as in versatile display case, there
are multiple DT overlays of which one has to be enabled. I hope there's
support to choose which one to use via kernel cmdline or similar.

I would personally like it much more if the bootloader would either
compose a final dtb from DT fragments and pass it to the kernel, or
alternatively the bootloader would pass the base dtb image and a bunch
of DT overlays to the kernel, and the kernel would deal with the DT
overlays.

In any case, I think the firmware solution is a good step forward, and
will probably work fine for many users. Then again, I haven't tested it
yet so I don't know the details, and it's not in the mainline.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/79e69ace/attachment.sig>

From alexandre.torgue at gmail.com  Tue Feb 23 01:59:15 2016
From: alexandre.torgue at gmail.com (Alexandre Torgue)
Date: Tue, 23 Feb 2016 10:59:15 +0100
Subject: [PATCH 1/4] net: ethernet: dwmac: add Ethernet glue logic for
 stm32 chip
In-Reply-To: <CAGhQ9VzPTgRqqLi4zjHkP-++v5smZ7s52drev1z-AvgXaLuC7Q@mail.gmail.com>
References: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
 <1454511275-9791-2-git-send-email-alexandre.torgue@gmail.com>
 <CAGhQ9VypZ5J0pQmrf1Mk-mNsv=XTXu7fhoLt_r2LHJ_Lsyj0yA@mail.gmail.com>
 <CAJgp7zwOVEq=hnxfUt7eHZWSFUAwuK6MCVHdH591=xReRUsW8Q@mail.gmail.com>
 <CAGhQ9VzPTgRqqLi4zjHkP-++v5smZ7s52drev1z-AvgXaLuC7Q@mail.gmail.com>
Message-ID: <CAJgp7zxYhbQ4yQHBB3cu50TU9N9xvk3HxCp0NP5fxFbxrMsD_g@mail.gmail.com>

2016-02-22 22:52 GMT+01:00 Joachim  Eastwood <manabian at gmail.com>:
> On 22 February 2016 at 15:50, Alexandre Torgue
> <alexandre.torgue at gmail.com> wrote:
>> 2016-02-13 14:48 GMT+01:00 Joachim  Eastwood <manabian at gmail.com>:
>>> On 3 February 2016 at 15:54, Alexandre TORGUE
>>> <alexandre.torgue at gmail.com> wrote:
>>>> +       plat_dat->bsp_priv = dwmac;
>>>> +       plat_dat->init = stm32_dwmac_init;
>>>> +       plat_dat->exit = stm32_dwmac_exit;
>>>
>>> Instead of using these callbacks could you rather implement the PM
>>> callbacks directly in this driver?
>>> I don't think it should add much code and it will make it look more
>>> like standard driver. This will also give you some more control and
>>> flexibility in your code.
>>
>> I prefer to keep the code as it is. Glue layer is directly linked to
>> stmmac driver and I don't want to brake the link between the glue and
>> the stmmac driver.
>
> What do you mean by break the link?
>

I thought that you wanted to split stmmac_pltfr_supend (glue part and
stmamc part), but I well understood it is not the case (sorry for
mistake).

> There has been numerous of patch sets to make the stmmac "glue"
> drivers into more standard platform drivers.
> http://marc.info/?l=linux-netdev&m=143159850631093&w=2
> http://marc.info/?l=linux-netdev&m=143708560009851&w=2
> http://marc.info/?l=linux-netdev&m=143812136600541&w=2
>
> Do you see any advantage by using the init and exit hooks in your
> driver instead of using the standard driver PM callbacks and remove
> function?
> The only "cost" I see is slightly more boilerplate code. But since you
> already have init/exit functions you could easily make them into PM
> resume/suspend so I doubt there would be much increase in code size.
>

If I well understood you want to continue the stmmac glue driver
rework by moving stmmac_pltfr_suspend/resume/remove in each glue
driver (stm32, sun, sti ....).
Each glue driver will call directly stmmac_suspend/resume/remove and
their own init/exit function.
If it is what you meant, I can do it.

> One other thing;
> Do you need to have the PHY mode setup code in the init function which
> is called each time on resume?

I can't guarantee that after a suspend the sysconfig register will
contain same data than before suspend.

Best regards.

Alex

> If you could move it to probe you could drop the interface priv data
> member and use plat_dat->interface as stmmac_probe_config_dt() has
> already done of_get_phy_mode().
>
>
> regards,
> Joachim Eastwood


From linus.walleij at linaro.org  Tue Feb 23 02:01:37 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Feb 2016 11:01:37 +0100
Subject: [PATCH 0/7] video: ARM CLCD: non-controversial parts
Message-ID: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>

This is a redux version of the previous patch set that strips out
any attempts to auto-switch or rewrite the device tree to match
the CLCD Versatile panel.

Instead, it does detect it and COMPARE it to what was found in
the device tree, prints a warning if those do not match, and
continue anyway.

This patch series brings support for device tree-only boot with
graphics to the Nomadik and all RealView platforms (so we can boot
RealView with only device tree) so it is very useful still even
if the Versatile is not yet fully supported.

Please consider applying this for v4.6 if these parts look
uncontroversial. Or applying partly from low to high patch
numbers so I'm not sitting with too much out-of-tree code.

Also resending a fix which has not yet landed upstream (1/7)
I guess it was lost.

Linus Walleij (7):
  video: ARM CLCD: runtime check for Versatile
  video: ARM CLCD: backlight support for OF
  video: ARM CLCD: support DT signal inversion flags
  video: ARM CLCD: support pads connected in reverse order
  video: ARM CLCD: support Nomadik variant
  video: ARM CLCD: add special board and panel hooks for Nomadik
  video: ARM CLCD: add special panel hook for Versatiles

 drivers/video/fbdev/Kconfig               |   6 +-
 drivers/video/fbdev/Makefile              |   1 +
 drivers/video/fbdev/amba-clcd-nomadik.c   | 257 ++++++++++++++++++++
 drivers/video/fbdev/amba-clcd-nomadik.h   |  24 ++
 drivers/video/fbdev/amba-clcd-versatile.c | 391 ++++++++++++++++++++++++++++++
 drivers/video/fbdev/amba-clcd-versatile.h |  17 ++
 drivers/video/fbdev/amba-clcd.c           | 218 +++++++++++++++--
 include/linux/amba/clcd.h                 |  76 +++++-
 8 files changed, 958 insertions(+), 32 deletions(-)
 create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.c
 create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.h
 create mode 100644 drivers/video/fbdev/amba-clcd-versatile.h

-- 
2.4.3



From linus.walleij at linaro.org  Tue Feb 23 02:01:38 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Feb 2016 11:01:38 +0100
Subject: [PATCH 1/7 RESEND] video: ARM CLCD: runtime check for Versatile
In-Reply-To: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
References: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1456221704-5792-2-git-send-email-linus.walleij@linaro.org>

The current compile-time check for inversed IENB/CNTL does not
work in multiplatform boots: as soon as versatile is included
in the build, the IENB/CNTL is switched and breaks graphics.
Convert this to a runtime switch.

Cc: stable at vger.kernel.org
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Fixes: a29da136de34 ("ARM: versatile: convert to multi-platform")
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/video/fbdev/amba-clcd.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 9362424c2340..f9ef06d0cd48 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -440,13 +440,14 @@ static int clcdfb_register(struct clcd_fb *fb)
 		fb->off_ienb = CLCD_PL111_IENB;
 		fb->off_cntl = CLCD_PL111_CNTL;
 	} else {
-#ifdef CONFIG_ARCH_VERSATILE
-		fb->off_ienb = CLCD_PL111_IENB;
-		fb->off_cntl = CLCD_PL111_CNTL;
-#else
-		fb->off_ienb = CLCD_PL110_IENB;
-		fb->off_cntl = CLCD_PL110_CNTL;
-#endif
+		if (of_machine_is_compatible("arm,versatile-ab") ||
+		    of_machine_is_compatible("arm,versatile-pb")) {
+			fb->off_ienb = CLCD_PL111_IENB;
+			fb->off_cntl = CLCD_PL111_CNTL;
+		} else {
+			fb->off_ienb = CLCD_PL110_IENB;
+			fb->off_cntl = CLCD_PL110_CNTL;
+		}
 	}
 
 	fb->clk = clk_get(&fb->dev->dev, NULL);
-- 
2.4.3



From linus.walleij at linaro.org  Tue Feb 23 02:01:39 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Feb 2016 11:01:39 +0100
Subject: [PATCH 2/7 v2] video: ARM CLCD: backlight support for OF
In-Reply-To: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
References: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1456221704-5792-3-git-send-email-linus.walleij@linaro.org>

If the device is probed from device tree, we can support
backlight. This is used with some systems such as the
ST Microelectronics Nomadik.

We have to add HAS_IOMEM to the dependencies of CLCD since
the backlight class device will now be selected, and if it
gets selected on an arch that does not have IOMEM,
compilation will fail.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- No changes. Just reposting.
---
 drivers/video/fbdev/Kconfig     |  4 +++-
 drivers/video/fbdev/amba-clcd.c | 40 ++++++++++++++++++++++++++++++++++++++++
 include/linux/amba/clcd.h       |  3 +++
 3 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8ea45a5cd806..6dcd91237551 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -284,12 +284,14 @@ config FB_PM2_FIFO_DISCONNECT
 config FB_ARMCLCD
 	tristate "ARM PrimeCell PL110 support"
 	depends on ARM || ARM64 || COMPILE_TEST
-	depends on FB && ARM_AMBA
+	depends on FB && ARM_AMBA && HAS_IOMEM
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
 	select FB_MODE_HELPERS if OF
 	select VIDEOMODE_HELPERS if OF
+	select BACKLIGHT_LCD_SUPPORT if OF
+	select BACKLIGHT_CLASS_DEVICE if OF
 	help
 	  This framebuffer device driver is for the ARM PrimeCell PL110
 	  Colour LCD controller.  ARM PrimeCells provide the building
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index f9ef06d0cd48..c5d1e9ca81ab 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -30,6 +30,7 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_graph.h>
+#include <linux/backlight.h>
 #include <video/display_timing.h>
 #include <video/of_display_timing.h>
 #include <video/videomode.h>
@@ -73,6 +74,11 @@ static void clcdfb_disable(struct clcd_fb *fb)
 	if (fb->board->disable)
 		fb->board->disable(fb);
 
+	if (fb->panel->backlight) {
+		fb->panel->backlight->props.power = FB_BLANK_POWERDOWN;
+		backlight_update_status(fb->panel->backlight);
+	}
+
 	val = readl(fb->regs + fb->off_cntl);
 	if (val & CNTL_LCDPWR) {
 		val &= ~CNTL_LCDPWR;
@@ -119,6 +125,14 @@ static void clcdfb_enable(struct clcd_fb *fb, u32 cntl)
 	writel(cntl, fb->regs + fb->off_cntl);
 
 	/*
+	 * Turn on backlight
+	 */
+	if (fb->panel->backlight) {
+		fb->panel->backlight->props.power = FB_BLANK_UNBLANK;
+		backlight_update_status(fb->panel->backlight);
+	}
+
+	/*
 	 * finally, enable the interface.
 	 */
 	if (fb->board->enable)
@@ -578,6 +592,28 @@ static int clcdfb_snprintf_mode(char *buf, int size, struct fb_videomode *mode)
 			mode->refresh);
 }
 
+static int clcdfb_of_get_backlight(struct device_node *endpoint,
+				   struct clcd_panel *clcd_panel)
+{
+	struct device_node *panel;
+	struct device_node *backlight;
+
+	panel = of_graph_get_remote_port_parent(endpoint);
+	if (!panel)
+		return -ENODEV;
+
+	/* Look up the optional backlight phandle */
+	backlight = of_parse_phandle(panel, "backlight", 0);
+	if (backlight) {
+		clcd_panel->backlight = of_find_backlight_by_node(backlight);
+		of_node_put(backlight);
+
+		if (!clcd_panel->backlight)
+			return -EPROBE_DEFER;
+	}
+	return 0;
+}
+
 static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
 		struct fb_videomode *mode)
 {
@@ -664,6 +700,10 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
 	if (!endpoint)
 		return -ENODEV;
 
+	err = clcdfb_of_get_backlight(endpoint, fb->panel);
+	if (err)
+		return err;
+
 	err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, &fb->panel->mode);
 	if (err)
 		return err;
diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h
index e82e3ee2c54a..e64c1ccebb76 100644
--- a/include/linux/amba/clcd.h
+++ b/include/linux/amba/clcd.h
@@ -93,6 +93,8 @@ enum {
 	CLCD_CAP_ALL		= CLCD_CAP_BGR | CLCD_CAP_RGB,
 };
 
+struct backlight_device;
+
 struct clcd_panel {
 	struct fb_videomode	mode;
 	signed short		width;	/* width in mm */
@@ -105,6 +107,7 @@ struct clcd_panel {
 				fixedtimings:1,
 				grayscale:1;
 	unsigned int		connector;
+	struct backlight_device	*backlight;
 };
 
 struct clcd_regs {
-- 
2.4.3



From linus.walleij at linaro.org  Tue Feb 23 02:01:41 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Feb 2016 11:01:41 +0100
Subject: [PATCH 4/7 v2] video: ARM CLCD: support pads connected in reverse
 order
In-Reply-To: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
References: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1456221704-5792-5-git-send-email-linus.walleij@linaro.org>

There are CLCDs connected with the pads in BGR rather than RGB
order. It really doesn't matter since the CLCD has a flag and
a bit to switch the position of the RGB and BGR components.
This is needed to put something logical into the
arm,pl11x,tft-r0g0b0-pads property of the device tree on the
Nomadik which will then be <16 8 0>.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- No changes. Just reposting.
---
 drivers/video/fbdev/amba-clcd.c |  8 ++++++++
 include/linux/amba/clcd.h       | 31 ++++++++++++++++++++++++-------
 2 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 8903a42c4122..9a631a8e2c04 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -681,6 +681,7 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
 	} panels[] = {
 		{ 0x110, 1,  7, 13, CLCD_CAP_5551 },
 		{ 0x110, 0,  8, 16, CLCD_CAP_888 },
+		{ 0x110, 16, 8, 0,  CLCD_CAP_888 },
 		{ 0x111, 4, 14, 20, CLCD_CAP_444 },
 		{ 0x111, 3, 11, 19, CLCD_CAP_444 | CLCD_CAP_5551 },
 		{ 0x111, 3, 10, 19, CLCD_CAP_444 | CLCD_CAP_5551 |
@@ -708,6 +709,13 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
 			fb->panel->caps = panels[i].caps;
 	}
 
+	/*
+	 * If we actually physically connected the R lines to B and
+	 * vice versa
+	 */
+	if (r0 != 0 && b0 == 0)
+		fb->panel->bgr_connection = true;
+
 	return fb->panel->caps ? 0 : -EINVAL;
 }
 
diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h
index e64c1ccebb76..c60f32e23a83 100644
--- a/include/linux/amba/clcd.h
+++ b/include/linux/amba/clcd.h
@@ -108,6 +108,12 @@ struct clcd_panel {
 				grayscale:1;
 	unsigned int		connector;
 	struct backlight_device	*backlight;
+	/*
+	 * If the B/R lines are switched between the CLCD
+	 * and the panel we need to know this and not try to
+	 * compensate with the BGR bit in the control register.
+	 */
+	bool			bgr_connection;
 };
 
 struct clcd_regs {
@@ -234,16 +240,27 @@ static inline void clcdfb_decode(struct clcd_fb *fb, struct clcd_regs *regs)
 	if (var->grayscale)
 		val |= CNTL_LCDBW;
 
-	if (fb->panel->caps && fb->board->caps &&
-	    var->bits_per_pixel >= 16) {
+	if (fb->panel->caps && fb->board->caps && var->bits_per_pixel >= 16) {
 		/*
 		 * if board and panel supply capabilities, we can support
-		 * changing BGR/RGB depending on supplied parameters
+		 * changing BGR/RGB depending on supplied parameters. Here
+		 * we switch to what the framebuffer is providing if need
+		 * be, so if the framebuffer is BGR but the display connection
+		 * is RGB (first case) we switch it around. Vice versa mutatis
+		 * mutandis if the framebuffer is RGB but the display connection
+		 * is BGR, we flip it around.
 		 */
-		if (var->red.offset == 0)
-			val &= ~CNTL_BGR;
-		else
-			val |= CNTL_BGR;
+		if (!fb->panel->bgr_connection) {
+			if (var->red.offset == 0)
+				val &= ~CNTL_BGR;
+			else
+				val |= CNTL_BGR;
+		} else {
+			if (var->blue.offset == 0)
+				val &= ~CNTL_BGR;
+			else
+				val |= CNTL_BGR;
+		}
 	}
 
 	switch (var->bits_per_pixel) {
-- 
2.4.3



From linus.walleij at linaro.org  Tue Feb 23 02:01:42 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Feb 2016 11:01:42 +0100
Subject: [PATCH 5/7 v2] video: ARM CLCD: support Nomadik variant
In-Reply-To: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
References: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1456221704-5792-6-git-send-email-linus.walleij@linaro.org>

The Nomadik variant has a few special quirks that need to be respected
to make the driver work:

- The block need to be clocked during writing of the TIMn registers
  or the bus will stall.
- Special bits in the control register select how many of the output
  display lines get activated.
- Special bits in the control register select how to manage the
  different 565 and 5551 modes.
- There is a packed 24bit graphics mode, i.e 888 pixels can be stored
  in memory is three consecutive bytes, not evenly aligned to a 32bit
  word.

This patch uses the vendor data pointer from the AMBA matching mechanism
to track the quirks for this variant, and adds two hooks that variants
can use to initialize boards and panels during start-up. These will
later be used to adopt a Nomadik board profile.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- No changes. Just reposting.
---
 drivers/video/fbdev/amba-clcd.c | 106 ++++++++++++++++++++++++++++++++++++----
 include/linux/amba/clcd.h       |  42 ++++++++++++++++
 2 files changed, 139 insertions(+), 9 deletions(-)

diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 9a631a8e2c04..24f4b596d502 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -227,6 +227,15 @@ clcdfb_set_bitfields(struct clcd_fb *fb, struct fb_var_screeninfo *var)
 			var->blue.length = 4;
 		}
 		break;
+	case 24:
+		if (fb->vendor->packed_24_bit_pixels) {
+			var->red.length = 8;
+			var->green.length = 8;
+			var->blue.length = 8;
+		} else {
+			ret = -EINVAL;
+		}
+		break;
 	case 32:
 		/* If we can't do 888, reject */
 		caps &= CLCD_CAP_888;
@@ -313,6 +322,12 @@ static int clcdfb_set_par(struct fb_info *info)
 
 	clcdfb_disable(fb);
 
+	/* Some variants must be clocked here */
+	if (fb->vendor->clock_timregs && !fb->clk_enabled) {
+		fb->clk_enabled = true;
+		clk_enable(fb->clk);
+	}
+
 	writel(regs.tim0, fb->regs + CLCD_TIM0);
 	writel(regs.tim1, fb->regs + CLCD_TIM1);
 	writel(regs.tim2, fb->regs + CLCD_TIM2);
@@ -716,6 +731,42 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
 	if (r0 != 0 && b0 == 0)
 		fb->panel->bgr_connection = true;
 
+	if (fb->panel->caps && fb->vendor->st_bitmux_control) {
+		/*
+		 * Set up the special bits for the Nomadik control register
+		 * (other platforms tend to do this through an external
+		 * register).
+		 */
+
+		/* Offset of the highest used color */
+		int maxoff = max3(r0, g0, b0);
+		/* Most significant bit out, highest used bit */
+		int msb = 0;
+
+		if (fb->panel->caps & CLCD_CAP_888) {
+			msb = maxoff + 8 - 1;
+		} else if (fb->panel->caps & CLCD_CAP_565) {
+			msb = maxoff + 5 - 1;
+			fb->panel->cntl |= CNTL_ST_1XBPP_565;
+		} else if (fb->panel->caps & CLCD_CAP_5551) {
+			msb = maxoff + 5 - 1;
+			fb->panel->cntl |= CNTL_ST_1XBPP_5551;
+		} else if (fb->panel->caps & CLCD_CAP_444) {
+			msb = maxoff + 4 - 1;
+			fb->panel->cntl |= CNTL_ST_1XBPP_444;
+		}
+
+		/* Send out as many bits as we need */
+		if (msb > 17)
+			fb->panel->cntl |= CNTL_ST_CDWID_24;
+		else if (msb > 15)
+			fb->panel->cntl |= CNTL_ST_CDWID_18;
+		else if (msb > 11)
+			fb->panel->cntl |= CNTL_ST_CDWID_16;
+		else
+			fb->panel->cntl |= CNTL_ST_CDWID_12;
+	}
+
 	return fb->panel->caps ? 0 : -EINVAL;
 }
 
@@ -731,9 +782,21 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
 	if (!fb->panel)
 		return -ENOMEM;
 
-	endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node, NULL);
-	if (!endpoint)
-		return -ENODEV;
+	/*
+	 * Fetch the panel endpoint.
+	 */
+	if (!endpoint) {
+		endpoint = of_graph_get_next_endpoint(fb->dev->dev.of_node,
+						      NULL);
+		if (!endpoint)
+			return -ENODEV;
+	}
+
+	if (fb->vendor->init_panel) {
+		err = fb->vendor->init_panel(fb, endpoint);
+		if (err)
+			return err;
+	}
 
 	err = clcdfb_of_get_backlight(endpoint, fb->panel);
 	if (err)
@@ -770,11 +833,11 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
 
 	if (of_property_read_u32_array(endpoint,
 			"arm,pl11x,tft-r0g0b0-pads",
-			tft_r0b0g0, ARRAY_SIZE(tft_r0b0g0)) == 0)
-		return clcdfb_of_init_tft_panel(fb, tft_r0b0g0[0],
-				 tft_r0b0g0[1],  tft_r0b0g0[2]);
+			tft_r0b0g0, ARRAY_SIZE(tft_r0b0g0)) != 0)
+		return -ENOENT;
 
-	return -ENOENT;
+	return clcdfb_of_init_tft_panel(fb, tft_r0b0g0[0],
+					tft_r0b0g0[1],  tft_r0b0g0[2]);
 }
 
 static int clcdfb_of_vram_setup(struct clcd_fb *fb)
@@ -895,6 +958,7 @@ static struct clcd_board *clcdfb_of_get_board(struct amba_device *dev)
 static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
 {
 	struct clcd_board *board = dev_get_platdata(&dev->dev);
+	struct clcd_vendor_data *vendor = id->data;
 	struct clcd_fb *fb;
 	int ret;
 
@@ -904,6 +968,12 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
 	if (!board)
 		return -EINVAL;
 
+	if (vendor->init_board) {
+		ret = vendor->init_board(dev, board);
+		if (ret)
+			return ret;
+	}
+
 	ret = dma_set_mask_and_coherent(&dev->dev, DMA_BIT_MASK(32));
 	if (ret)
 		goto out;
@@ -922,10 +992,11 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
 	}
 
 	fb->dev = dev;
+	fb->vendor = vendor;
 	fb->board = board;
 
-	dev_info(&fb->dev->dev, "PL%03x rev%u at 0x%08llx\n",
-		amba_part(dev), amba_rev(dev),
+	dev_info(&fb->dev->dev, "PL%03x designer %02x rev%u at 0x%08llx\n",
+		amba_part(dev), amba_manf(dev), amba_rev(dev),
 		(unsigned long long)dev->res.start);
 
 	ret = fb->board->setup(fb);
@@ -968,10 +1039,27 @@ static int clcdfb_remove(struct amba_device *dev)
 	return 0;
 }
 
+static struct clcd_vendor_data vendor_arm = {
+	/* No special business */
+};
+
+static struct clcd_vendor_data vendor_nomadik = {
+	.clock_timregs = true,
+	.packed_24_bit_pixels = true,
+	.st_bitmux_control = true,
+};
+
 static struct amba_id clcdfb_id_table[] = {
 	{
 		.id	= 0x00041110,
 		.mask	= 0x000ffffe,
+		.data	= &vendor_arm,
+	},
+	/* ST Electronics Nomadik variant */
+	{
+		.id	= 0x00180110,
+		.mask	= 0x00fffffe,
+		.data	= &vendor_nomadik,
 	},
 	{ 0, 0 },
 };
diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h
index c60f32e23a83..7d95633250a4 100644
--- a/include/linux/amba/clcd.h
+++ b/include/linux/amba/clcd.h
@@ -67,6 +67,17 @@
 #define CNTL_LDMAFIFOTIME	(1 << 15)
 #define CNTL_WATERMARK		(1 << 16)
 
+/* ST Microelectronics variant bits */
+#define CNTL_ST_1XBPP_444	0x0
+#define CNTL_ST_1XBPP_5551	(1 << 17)
+#define CNTL_ST_1XBPP_565	(1 << 18)
+#define CNTL_ST_CDWID_12	0x0
+#define CNTL_ST_CDWID_16	(1 << 19)
+#define CNTL_ST_CDWID_18	(1 << 20)
+#define CNTL_ST_CDWID_24	((1 << 19)|(1 << 20))
+#define CNTL_ST_CEAEN		(1 << 21)
+#define CNTL_ST_LCDBPP24_PACKED	(6 << 1)
+
 enum {
 	/* individual formats */
 	CLCD_CAP_RGB444		= (1 << 0),
@@ -179,11 +190,38 @@ struct clcd_board {
 struct amba_device;
 struct clk;
 
+/**
+ * struct clcd_vendor_data - holds hardware (IP-block) vendor-specific
+ * variant information
+ *
+ * @clock_timregs: the CLCD needs to be clocked when accessing the
+ * timer registers, or the hardware will hang.
+ * @packed_24_bit_pixels: this variant supports 24bit packed pixel data,
+ * so that RGB accesses 3 bytes at a time, not just on even 32bit
+ * boundaries, packing the pixel data in memory. ST Microelectronics
+ * have this.
+ * @st_bitmux_control: ST Microelectronics have implemented output
+ * bit line multiplexing into the CLCD control register. This indicates
+ * that we need to use this.
+ * @init_board: custom board init function for this variant
+ * @init_panel: custom panel init function for this variant
+ */
+struct clcd_vendor_data {
+	bool	clock_timregs;
+	bool	packed_24_bit_pixels;
+	bool	st_bitmux_control;
+	int	(*init_board)(struct amba_device *adev,
+			      struct clcd_board *board);
+	int	(*init_panel)(struct clcd_fb *fb,
+			      struct device_node *panel);
+};
+
 /* this data structure describes each frame buffer device we find */
 struct clcd_fb {
 	struct fb_info		fb;
 	struct amba_device	*dev;
 	struct clk		*clk;
+	struct clcd_vendor_data	*vendor;
 	struct clcd_panel	*panel;
 	struct clcd_board	*board;
 	void			*board_data;
@@ -290,6 +328,10 @@ static inline void clcdfb_decode(struct clcd_fb *fb, struct clcd_regs *regs)
 		else
 			val |= CNTL_LCDBPP16_444;
 		break;
+	case 24:
+		/* Modified variant supporting 24 bit packed pixels */
+		val |= CNTL_ST_LCDBPP24_PACKED;
+		break;
 	case 32:
 		val |= CNTL_LCDBPP24;
 		break;
-- 
2.4.3



From linus.walleij at linaro.org  Tue Feb 23 02:01:43 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Feb 2016 11:01:43 +0100
Subject: [PATCH 6/7 v2] video: ARM CLCD: add special board and panel hooks for
 Nomadik
In-Reply-To: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
References: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1456221704-5792-7-git-send-email-linus.walleij@linaro.org>

In the .board_init() callback will set up a mux register in
the Nomadik system controller. It so happens that the platform
has two display output engines, and we have to poke a bit in
a special register to make sure the right engine is muxed in
as they are mutually exclusive.

The Nomadik CLCD variant is instantiated on a platform where
it is combined with a 800x480 TPO WVGA display. In the
.panel_init() hook we will detect this display from the
compatible string and set it up. We also add .enable() and
.disable() callbacks for it as the sleep state is software
controlled.

The display is connected with a special 3-wire serial bus
(this is sadly neither I2C or SPI) using three GPIO lines that
we bitbang to detect the display and enable/disable sleep
state.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- No changes. Just reposting.
---
 drivers/video/fbdev/Makefile            |   1 +
 drivers/video/fbdev/amba-clcd-nomadik.c | 257 ++++++++++++++++++++++++++++++++
 drivers/video/fbdev/amba-clcd-nomadik.h |  24 +++
 drivers/video/fbdev/amba-clcd.c         |   6 +-
 4 files changed, 287 insertions(+), 1 deletion(-)
 create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.c
 create mode 100644 drivers/video/fbdev/amba-clcd-nomadik.h

diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index 65fb15075c8f..f0aec3aa213c 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_FB_ATMEL)		  += atmel_lcdfb.o
 obj-$(CONFIG_FB_PVR2)             += pvr2fb.o
 obj-$(CONFIG_FB_VOODOO1)          += sstfb.o
 obj-$(CONFIG_FB_ARMCLCD)	  += amba-clcd.o
+obj-$(CONFIG_ARCH_NOMADIK)	  += amba-clcd-nomadik.o
 obj-$(CONFIG_PLAT_VERSATILE_CLCD) += amba-clcd-versatile.o
 obj-$(CONFIG_FB_GOLDFISH)         += goldfishfb.o
 obj-$(CONFIG_FB_68328)            += 68328fb.o
diff --git a/drivers/video/fbdev/amba-clcd-nomadik.c b/drivers/video/fbdev/amba-clcd-nomadik.c
new file mode 100644
index 000000000000..243167c8ee15
--- /dev/null
+++ b/drivers/video/fbdev/amba-clcd-nomadik.c
@@ -0,0 +1,257 @@
+#include <linux/amba/bus.h>
+#include <linux/amba/clcd.h>
+#include <linux/gpio/consumer.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/delay.h>
+#include <linux/bitops.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+
+#include "amba-clcd-nomadik.h"
+
+static struct gpio_desc *grestb;
+static struct gpio_desc *scen;
+static struct gpio_desc *scl;
+static struct gpio_desc *sda;
+
+static u8 tpg110_readwrite_reg(bool write, u8 address, u8 outval)
+{
+	int i;
+	u8 inval = 0;
+
+	/* Assert SCEN */
+	gpiod_set_value_cansleep(scen, 1);
+	ndelay(150);
+	/* Hammer out the address */
+	for (i = 5; i >= 0; i--) {
+		if (address & BIT(i))
+			gpiod_set_value_cansleep(sda, 1);
+		else
+			gpiod_set_value_cansleep(sda, 0);
+		ndelay(150);
+		/* Send an SCL pulse */
+		gpiod_set_value_cansleep(scl, 1);
+		ndelay(160);
+		gpiod_set_value_cansleep(scl, 0);
+		ndelay(160);
+	}
+
+	if (write) {
+		/* WRITE */
+		gpiod_set_value_cansleep(sda, 0);
+	} else {
+		/* READ */
+		gpiod_set_value_cansleep(sda, 1);
+	}
+	ndelay(150);
+	/* Send an SCL pulse */
+	gpiod_set_value_cansleep(scl, 1);
+	ndelay(160);
+	gpiod_set_value_cansleep(scl, 0);
+	ndelay(160);
+
+	if (!write)
+		/* HiZ turn-around cycle */
+		gpiod_direction_input(sda);
+	ndelay(150);
+	/* Send an SCL pulse */
+	gpiod_set_value_cansleep(scl, 1);
+	ndelay(160);
+	gpiod_set_value_cansleep(scl, 0);
+	ndelay(160);
+
+	/* Hammer in/out the data */
+	for (i = 7; i >= 0; i--) {
+		int value;
+
+		if (write) {
+			value = !!(outval & BIT(i));
+			gpiod_set_value_cansleep(sda, value);
+		} else {
+			value = gpiod_get_value(sda);
+			if (value)
+				inval |= BIT(i);
+		}
+		ndelay(150);
+		/* Send an SCL pulse */
+		gpiod_set_value_cansleep(scl, 1);
+		ndelay(160);
+		gpiod_set_value_cansleep(scl, 0);
+		ndelay(160);
+	}
+
+	gpiod_direction_output(sda, 0);
+	/* Deassert SCEN */
+	gpiod_set_value_cansleep(scen, 0);
+	/* Satisfies SCEN pulse width */
+	udelay(1);
+
+	return inval;
+}
+
+static u8 tpg110_read_reg(u8 address)
+{
+	return tpg110_readwrite_reg(false, address, 0);
+}
+
+static void tpg110_write_reg(u8 address, u8 outval)
+{
+	tpg110_readwrite_reg(true, address, outval);
+}
+
+static void tpg110_startup(struct device *dev)
+{
+	u8 val;
+
+	dev_info(dev, "TPG110 display enable\n");
+	/* De-assert the reset signal */
+	gpiod_set_value_cansleep(grestb, 0);
+	mdelay(1);
+	dev_info(dev, "de-asserted GRESTB\n");
+
+	/* Test display communication */
+	tpg110_write_reg(0x00, 0x55);
+	val = tpg110_read_reg(0x00);
+	if (val == 0x55)
+		dev_info(dev, "passed communication test\n");
+	val = tpg110_read_reg(0x01);
+	dev_info(dev, "TPG110 chip ID: %d version: %d\n",
+		val>>4, val&0x0f);
+
+	/* Show display resolution */
+	val = tpg110_read_reg(0x02);
+	val &= 7;
+	switch (val) {
+	case 0x0:
+		dev_info(dev, "IN 400x240 RGB -> OUT 800x480 RGB (dual scan)");
+		break;
+	case 0x1:
+		dev_info(dev, "IN 480x272 RGB -> OUT 800x480 RGB (dual scan)");
+		break;
+	case 0x4:
+		dev_info(dev, "480x640 RGB");
+		break;
+	case 0x5:
+		dev_info(dev, "480x272 RGB");
+		break;
+	case 0x6:
+		dev_info(dev, "640x480 RGB");
+		break;
+	case 0x7:
+		dev_info(dev, "800x480 RGB");
+		break;
+	default:
+		dev_info(dev, "ILLEGAL RESOLUTION");
+		break;
+	}
+
+	val = tpg110_read_reg(0x03);
+	dev_info(dev, "resolution is controlled by %s\n",
+		(val & BIT(7)) ? "software" : "hardware");
+}
+
+static void tpg110_enable(struct clcd_fb *fb)
+{
+	struct device *dev = &fb->dev->dev;
+	static bool startup;
+	u8 val;
+
+	if (!startup) {
+		tpg110_startup(dev);
+		startup = true;
+	}
+
+	/* Take chip out of standby */
+	val = tpg110_read_reg(0x03);
+	val |= BIT(0);
+	tpg110_write_reg(0x03, val);
+}
+
+static void tpg110_disable(struct clcd_fb *fb)
+{
+	u8 val;
+
+	dev_info(&fb->dev->dev, "TPG110 display disable\n");
+	val = tpg110_read_reg(0x03);
+	/* Put into standby */
+	val &= ~BIT(0);
+	tpg110_write_reg(0x03, val);
+}
+
+static void tpg110_init(struct device *dev, struct device_node *np,
+			struct clcd_board *board)
+{
+	dev_info(dev, "TPG110 display init\n");
+
+	grestb = devm_get_gpiod_from_child(dev, "grestb", &np->fwnode);
+	if (IS_ERR(grestb)) {
+		dev_err(dev, "no GRESTB GPIO\n");
+		return;
+	}
+	/* This asserts the GRESTB signal, putting the display into reset */
+	gpiod_direction_output(grestb, 1);
+
+	scen = devm_get_gpiod_from_child(dev, "scen", &np->fwnode);
+	if (IS_ERR(scen)) {
+		dev_err(dev, "no SCEN GPIO\n");
+		return;
+	}
+	gpiod_direction_output(scen, 0);
+	scl = devm_get_gpiod_from_child(dev, "scl", &np->fwnode);
+	if (IS_ERR(scl)) {
+		dev_err(dev, "no SCL GPIO\n");
+		return;
+	}
+	gpiod_direction_output(scl, 0);
+	sda = devm_get_gpiod_from_child(dev, "sda", &np->fwnode);
+	if (IS_ERR(sda)) {
+		dev_err(dev, "no SDA GPIO\n");
+		return;
+	}
+	gpiod_direction_output(sda, 0);
+	board->enable = tpg110_enable;
+	board->disable = tpg110_disable;
+}
+
+int nomadik_clcd_init_panel(struct clcd_fb *fb,
+			    struct device_node *endpoint)
+{
+	struct device_node *panel;
+
+	panel = of_graph_get_remote_port_parent(endpoint);
+	if (!panel)
+		return -ENODEV;
+
+	if (of_device_is_compatible(panel, "tpo,tpg110"))
+		tpg110_init(&fb->dev->dev, panel, fb->board);
+	else
+		dev_info(&fb->dev->dev, "unknown panel\n");
+
+	/* Unknown panel, fall through */
+	return 0;
+}
+
+#define PMU_CTRL_OFFSET 0x0000
+#define PMU_CTRL_LCDNDIF BIT(26)
+
+int nomadik_clcd_init_board(struct amba_device *adev,
+			    struct clcd_board *board)
+{
+	struct regmap *pmu_regmap;
+
+	dev_info(&adev->dev, "Nomadik CLCD board init\n");
+	pmu_regmap =
+		syscon_regmap_lookup_by_compatible("stericsson,nomadik-pmu");
+	if (IS_ERR(pmu_regmap)) {
+		dev_err(&adev->dev, "could not find PMU syscon regmap\n");
+		return PTR_ERR(pmu_regmap);
+	}
+	regmap_update_bits(pmu_regmap,
+			   PMU_CTRL_OFFSET,
+			   PMU_CTRL_LCDNDIF,
+			   0);
+	dev_info(&adev->dev, "set PMU mux to CLCD mode\n");
+
+	return 0;
+}
diff --git a/drivers/video/fbdev/amba-clcd-nomadik.h b/drivers/video/fbdev/amba-clcd-nomadik.h
new file mode 100644
index 000000000000..50aa9bda69fd
--- /dev/null
+++ b/drivers/video/fbdev/amba-clcd-nomadik.h
@@ -0,0 +1,24 @@
+#ifndef _AMBA_CLCD_NOMADIK_H
+#define _AMBA_CLCD_NOMADIK_H
+
+#include <linux/amba/bus.h>
+
+#ifdef CONFIG_ARCH_NOMADIK
+int nomadik_clcd_init_board(struct amba_device *adev,
+			     struct clcd_board *board);
+int nomadik_clcd_init_panel(struct clcd_fb *fb,
+			    struct device_node *endpoint);
+#else
+static inline int nomadik_clcd_init_board(struct amba_device *adev,
+					  struct clcd_board *board)
+{
+	return 0;
+}
+static inline int nomadik_clcd_init_panel(struct clcd_fb *fb,
+					  struct device_node *endpoint)
+{
+	return 0;
+}
+#endif
+
+#endif /* inclusion guard */
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 24f4b596d502..2541b237e46e 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -37,6 +37,8 @@
 
 #include <asm/sizes.h>
 
+#include "amba-clcd-nomadik.h"
+
 #define to_clcd(info)	container_of(info, struct clcd_fb, fb)
 
 /* This is limited to 16 characters when displayed by X startup */
@@ -1003,7 +1005,7 @@ static int clcdfb_probe(struct amba_device *dev, const struct amba_id *id)
 	if (ret)
 		goto free_fb;
 
-	ret = clcdfb_register(fb); 
+	ret = clcdfb_register(fb);
 	if (ret == 0) {
 		amba_set_drvdata(dev, fb);
 		goto out;
@@ -1047,6 +1049,8 @@ static struct clcd_vendor_data vendor_nomadik = {
 	.clock_timregs = true,
 	.packed_24_bit_pixels = true,
 	.st_bitmux_control = true,
+	.init_board = nomadik_clcd_init_board,
+	.init_panel = nomadik_clcd_init_panel,
 };
 
 static struct amba_id clcdfb_id_table[] = {
-- 
2.4.3



From linus.walleij at linaro.org  Tue Feb 23 02:01:40 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Feb 2016 11:01:40 +0100
Subject: [PATCH 3/7 v2] video: ARM CLCD: support DT signal inversion flags
In-Reply-To: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
References: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1456221704-5792-4-git-send-email-linus.walleij@linaro.org>

The device tree bindings from display-timing.txt allows us to
specify if data enable, hsync, vsync or the pixed clock should be
inverted on the way to the display. The driver does not currently
handle this so add support for those flags as it is needed for
the Versatile Sanyo LCD display.

Note that the previous behaviour was to invert the pixel clock
for all displays, so unless the pixel clock polarity is
explicitly defined in the device tree (i.e. the timings node
has the "pixelclk-active" property) we fall back to inverting
the pixel clock. This needs some extra compatibility code.

Since the timing flags have to be set up inside the struct
clcd_panel, we need to refactor the code a bit to pass around
the panel rather than just the mode.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- No changes. Just reposting.
---
 drivers/video/fbdev/amba-clcd.c | 41 ++++++++++++++++++++++++++++++++++-------
 1 file changed, 34 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index c5d1e9ca81ab..8903a42c4122 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -567,10 +567,11 @@ static int clcdfb_register(struct clcd_fb *fb)
 
 #ifdef CONFIG_OF
 static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
-		struct fb_videomode *mode)
+		struct clcd_panel *clcd_panel)
 {
 	int err;
 	struct display_timing timing;
+	struct device_node *timnp;
 	struct videomode video;
 
 	err = of_get_display_timing(node, "panel-timing", &timing);
@@ -579,10 +580,34 @@ static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
 
 	videomode_from_timing(&timing, &video);
 
-	err = fb_videomode_from_videomode(&video, mode);
+	err = fb_videomode_from_videomode(&video, &clcd_panel->mode);
 	if (err)
 		return err;
 
+	/* Set up some inversion flags */
+	timnp = of_get_child_by_name(node, "panel-timing");
+	if (timnp && of_property_read_bool(timnp, "pixelclk-active")) {
+		if (timing.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+			clcd_panel->tim2 |= TIM2_IPC;
+	} else {
+		/*
+		 * To preserve backwards compatibility, the IPC (inverted
+		 * pixel clock) flag needs to be set on any display that
+		 * doesn't explicitly specify that the pixel clock is
+		 * active on the negative edge.
+		 */
+		clcd_panel->tim2 |= TIM2_IPC;
+	}
+
+	if (timing.flags & DISPLAY_FLAGS_HSYNC_LOW)
+		clcd_panel->tim2 |= TIM2_IHS;
+
+	if (timing.flags & DISPLAY_FLAGS_VSYNC_LOW)
+		clcd_panel->tim2 |= TIM2_IVS;
+
+	if (timing.flags & DISPLAY_FLAGS_DE_LOW)
+		clcd_panel->tim2 |= TIM2_IOE;
+
 	return 0;
 }
 
@@ -615,10 +640,11 @@ static int clcdfb_of_get_backlight(struct device_node *endpoint,
 }
 
 static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
-		struct fb_videomode *mode)
+		struct clcd_panel *clcd_panel)
 {
 	int err;
 	struct device_node *panel;
+	struct fb_videomode *mode;
 	char *name;
 	int len;
 
@@ -628,11 +654,12 @@ static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
 
 	/* Only directly connected DPI panels supported for now */
 	if (of_device_is_compatible(panel, "panel-dpi"))
-		err = clcdfb_of_get_dpi_panel_mode(panel, mode);
+		err = clcdfb_of_get_dpi_panel_mode(panel, clcd_panel);
 	else
 		err = -ENOENT;
 	if (err)
 		return err;
+	mode = &clcd_panel->mode;
 
 	len = clcdfb_snprintf_mode(NULL, 0, mode);
 	name = devm_kzalloc(dev, len + 1, GFP_KERNEL);
@@ -663,8 +690,8 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
 	};
 	int i;
 
-	/* Bypass pixel clock divider, data output on the falling edge */
-	fb->panel->tim2 = TIM2_BCD | TIM2_IPC;
+	/* Bypass pixel clock divider */
+	fb->panel->tim2 |= TIM2_BCD;
 
 	/* TFT display, vert. comp. interrupt at the start of the back porch */
 	fb->panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
@@ -704,7 +731,7 @@ static int clcdfb_of_init_display(struct clcd_fb *fb)
 	if (err)
 		return err;
 
-	err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, &fb->panel->mode);
+	err = clcdfb_of_get_mode(&fb->dev->dev, endpoint, fb->panel);
 	if (err)
 		return err;
 
-- 
2.4.3



From linus.walleij at linaro.org  Tue Feb 23 02:01:44 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Feb 2016 11:01:44 +0100
Subject: [PATCH 7/7 v2] video: ARM CLCD: add special panel hook for Versatiles
In-Reply-To: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
References: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1456221704-5792-8-git-send-email-linus.walleij@linaro.org>

This adds a special panel init hook for the ARM reference designs
Integrator (IM-PD1), Versatile and RealView, so we can configure
a DPI panel from device tree and have it working without
boardfiles for these machines.

Basically this is the same code as from the board files, just
moved over to look up the syscon DT node and manipulate the
special CLCD register from their regmap.

Tested on RealView PB11MPcore.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- For Versatile: just detect the panel and look up and compare
  the expected compatible string to what is provided by the device
  tree. If the device tree does not match the hardware-detected
  display, print a warning and continue anyways.
- Make no attempt at actually switching the panel at runtime or
  to modify the device tree at runtime.
---
 drivers/video/fbdev/Kconfig               |   2 +
 drivers/video/fbdev/amba-clcd-versatile.c | 391 ++++++++++++++++++++++++++++++
 drivers/video/fbdev/amba-clcd-versatile.h |  17 ++
 drivers/video/fbdev/amba-clcd.c           |   4 +-
 4 files changed, 413 insertions(+), 1 deletion(-)
 create mode 100644 drivers/video/fbdev/amba-clcd-versatile.h

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 6dcd91237551..a3fdc4cd1837 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -307,6 +307,8 @@ config PLAT_VERSATILE_CLCD
 	def_bool ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS || ARCH_INTEGRATOR
 	depends on ARM
 	depends on FB_ARMCLCD && FB=y
+	select REGMAP
+	select MFD_SYSCON
 
 config FB_ACORN
 	bool "Acorn VIDC support"
diff --git a/drivers/video/fbdev/amba-clcd-versatile.c b/drivers/video/fbdev/amba-clcd-versatile.c
index 7a8afcd4573e..892bbf6c6a07 100644
--- a/drivers/video/fbdev/amba-clcd-versatile.c
+++ b/drivers/video/fbdev/amba-clcd-versatile.c
@@ -3,6 +3,12 @@
 #include <linux/amba/bus.h>
 #include <linux/amba/clcd.h>
 #include <linux/platform_data/video-clcd-versatile.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+#include <linux/bitops.h>
+#include "amba-clcd-versatile.h"
 
 static struct clcd_panel vga = {
 	.mode		= {
@@ -180,3 +186,388 @@ void versatile_clcd_remove_dma(struct clcd_fb *fb)
 	dma_free_writecombine(&fb->dev->dev, fb->fb.fix.smem_len,
 			      fb->fb.screen_base, fb->fb.fix.smem_start);
 }
+
+#ifdef CONFIG_OF
+
+static struct regmap *versatile_syscon_map;
+static struct regmap *versatile_ib2_map;
+
+/*
+ * We detect the different syscon types from the compatible strings.
+ */
+enum versatile_clcd {
+	INTEGRATOR_CLCD_CM,
+	VERSATILE_CLCD,
+	REALVIEW_CLCD_EB,
+	REALVIEW_CLCD_PB1176,
+	REALVIEW_CLCD_PB11MP,
+	REALVIEW_CLCD_PBA8,
+	REALVIEW_CLCD_PBX,
+};
+
+static const struct of_device_id versatile_clcd_of_match[] = {
+	{
+		.compatible = "arm,core-module-integrator",
+		.data = (void *)INTEGRATOR_CLCD_CM,
+	},
+	{
+		.compatible = "arm,versatile-sysreg",
+		.data = (void *)VERSATILE_CLCD,
+	},
+	{
+		.compatible = "arm,realview-eb-syscon",
+		.data = (void *)REALVIEW_CLCD_EB,
+	},
+	{
+		.compatible = "arm,realview-pb1176-syscon",
+		.data = (void *)REALVIEW_CLCD_PB1176,
+	},
+	{
+		.compatible = "arm,realview-pb11mp-syscon",
+		.data = (void *)REALVIEW_CLCD_PB11MP,
+	},
+	{
+		.compatible = "arm,realview-pba8-syscon",
+		.data = (void *)REALVIEW_CLCD_PBA8,
+	},
+	{
+		.compatible = "arm,realview-pbx-syscon",
+		.data = (void *)REALVIEW_CLCD_PBX,
+	},
+	{},
+};
+
+/*
+ * Core module CLCD control on the Integrator/CP, bits
+ * 8 thru 19 of the CM_CONTROL register controls a bunch
+ * of CLCD settings.
+ */
+#define INTEGRATOR_HDR_CTRL_OFFSET	0x0C
+#define INTEGRATOR_CLCD_LCDBIASEN	BIT(8)
+#define INTEGRATOR_CLCD_LCDBIASUP	BIT(9)
+#define INTEGRATOR_CLCD_LCDBIASDN	BIT(10)
+/* Bits 11,12,13 controls the LCD type */
+#define INTEGRATOR_CLCD_LCDMUX_MASK	(BIT(11)|BIT(12)|BIT(13))
+#define INTEGRATOR_CLCD_LCDMUX_LCD24	BIT(11)
+#define INTEGRATOR_CLCD_LCDMUX_VGA565	BIT(12)
+#define INTEGRATOR_CLCD_LCDMUX_SHARP	(BIT(11)|BIT(12))
+#define INTEGRATOR_CLCD_LCDMUX_VGA555	BIT(13)
+#define INTEGRATOR_CLCD_LCDMUX_VGA24	(BIT(11)|BIT(12)|BIT(13))
+#define INTEGRATOR_CLCD_LCD0_EN		BIT(14)
+#define INTEGRATOR_CLCD_LCD1_EN		BIT(15)
+/* R/L flip on Sharp */
+#define INTEGRATOR_CLCD_LCD_STATIC1	BIT(16)
+/* U/D flip on Sharp */
+#define INTEGRATOR_CLCD_LCD_STATIC2	BIT(17)
+/* No connection on Sharp */
+#define INTEGRATOR_CLCD_LCD_STATIC	BIT(18)
+/* 0 = 24bit VGA, 1 = 18bit VGA */
+#define INTEGRATOR_CLCD_LCD_N24BITEN	BIT(19)
+
+#define INTEGRATOR_CLCD_MASK		(INTEGRATOR_CLCD_LCDMUX_MASK | \
+					 INTEGRATOR_CLCD_LCD0_EN | \
+					 INTEGRATOR_CLCD_LCD1_EN | \
+					 INTEGRATOR_CLCD_LCD_STATIC1 | \
+					 INTEGRATOR_CLCD_LCD_STATIC2 | \
+					 INTEGRATOR_CLCD_LCD_STATIC | \
+					 INTEGRATOR_CLCD_LCD_N24BITEN)
+
+static void integrator_clcd_enable(struct clcd_fb *fb)
+{
+	struct fb_var_screeninfo *var = &fb->fb.var;
+	u32 val;
+
+	dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");
+
+	val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
+		INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
+	if (var->bits_per_pixel <= 8 ||
+	    (var->bits_per_pixel == 16 && var->green.length == 5))
+		/* Pseudocolor, RGB555, BGR555 */
+		val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
+	else if (fb->fb.var.bits_per_pixel <= 16)
+		/* truecolor RGB565 */
+		val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
+	else
+		val = 0; /* no idea for this, don't trust the docs */
+
+	regmap_update_bits(versatile_syscon_map,
+			   INTEGRATOR_HDR_CTRL_OFFSET,
+			   0,
+			   INTEGRATOR_CLCD_MASK);
+}
+
+/*
+ * This configuration register in the Versatile and RealView
+ * family is uniformly present but appears more and more
+ * unutilized starting with the RealView series.
+ */
+#define SYS_CLCD			0x50
+#define SYS_CLCD_MODE_MASK		(BIT(0)|BIT(1))
+#define SYS_CLCD_MODE_888		0
+#define SYS_CLCD_MODE_5551		BIT(0)
+#define SYS_CLCD_MODE_565_R_LSB		BIT(1)
+#define SYS_CLCD_MODE_565_B_LSB		(BIT(0)|BIT(1))
+#define SYS_CLCD_CONNECTOR_MASK		(BIT(2)|BIT(3)|BIT(4)|BIT(5))
+#define SYS_CLCD_NLCDIOON		BIT(2)
+#define SYS_CLCD_VDDPOSSWITCH		BIT(3)
+#define SYS_CLCD_PWR3V5SWITCH		BIT(4)
+#define SYS_CLCD_VDDNEGSWITCH		BIT(5)
+#define SYS_CLCD_TSNSS			BIT(6) /* touchscreen enable */
+#define SYS_CLCD_SSPEXP			BIT(7) /* SSP expansion enable */
+
+/* The Versatile can detect the connected panel type */
+#define SYS_CLCD_CLCDID_MASK		(BIT(8)|BIT(9)|BIT(10)|BIT(11)|BIT(12))
+#define SYS_CLCD_ID_SANYO_3_8		(0x00 << 8)
+#define SYS_CLCD_ID_SHARP_8_4		(0x01 << 8)
+#define SYS_CLCD_ID_EPSON_2_2		(0x02 << 8)
+#define SYS_CLCD_ID_SANYO_2_5		(0x07 << 8)
+#define SYS_CLCD_ID_VGA			(0x1f << 8)
+
+#define SYS_CLCD_TSNDAV			BIT(13) /* data ready from TS */
+
+/* IB2 control register for the Versatile daughterboard */
+#define IB2_CTRL			0x00
+#define IB2_CTRL_LCD_SD			BIT(1) /* 1 = shut down LCD */
+#define IB2_CTRL_LCD_BL_ON		BIT(0)
+#define IB2_CTRL_LCD_MASK		(BIT(0)|BIT(1))
+
+static void versatile_clcd_disable(struct clcd_fb *fb)
+{
+	dev_info(&fb->dev->dev, "disable Versatile CLCD connectors\n");
+	regmap_update_bits(versatile_syscon_map,
+			   SYS_CLCD,
+			   SYS_CLCD_CONNECTOR_MASK,
+			   0);
+
+	/* If we're on an IB2 daughterboard, turn off display */
+	if (versatile_ib2_map) {
+		dev_info(&fb->dev->dev, "disable IB2 display\n");
+		regmap_update_bits(versatile_ib2_map,
+				   IB2_CTRL,
+				   IB2_CTRL_LCD_MASK,
+				   IB2_CTRL_LCD_SD);
+	}
+}
+
+static void versatile_clcd_enable(struct clcd_fb *fb)
+{
+	struct fb_var_screeninfo *var = &fb->fb.var;
+	u32 val = 0;
+
+	dev_info(&fb->dev->dev, "enable Versatile CLCD connectors\n");
+	switch (var->green.length) {
+	case 5:
+		val |= SYS_CLCD_MODE_5551;
+		break;
+	case 6:
+		if (var->red.offset == 0)
+			val |= SYS_CLCD_MODE_565_R_LSB;
+		else
+			val |= SYS_CLCD_MODE_565_B_LSB;
+		break;
+	case 8:
+		val |= SYS_CLCD_MODE_888;
+		break;
+	}
+
+	/* Set up the MUX */
+	regmap_update_bits(versatile_syscon_map,
+			   SYS_CLCD,
+			   SYS_CLCD_MODE_MASK,
+			   val);
+
+	/* Then enable the display */
+	regmap_update_bits(versatile_syscon_map,
+			   SYS_CLCD,
+			   SYS_CLCD_CONNECTOR_MASK,
+			   SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH);
+
+	/* If we're on an IB2 daughterboard, turn on display */
+	if (versatile_ib2_map) {
+		dev_info(&fb->dev->dev, "enable IB2 display\n");
+		regmap_update_bits(versatile_ib2_map,
+				   IB2_CTRL,
+				   IB2_CTRL_LCD_MASK,
+				   IB2_CTRL_LCD_BL_ON);
+	}
+}
+
+static void versatile_clcd_decode(struct clcd_fb *fb, struct clcd_regs *regs)
+{
+	clcdfb_decode(fb, regs);
+
+	/* Always clear BGR for RGB565: we do the routing externally */
+	if (fb->fb.var.green.length == 6)
+		regs->cntl &= ~CNTL_BGR;
+}
+
+static void realview_clcd_disable(struct clcd_fb *fb)
+{
+	dev_info(&fb->dev->dev, "disable RealView CLCD connectors\n");
+	regmap_update_bits(versatile_syscon_map,
+			   SYS_CLCD,
+			   SYS_CLCD_CONNECTOR_MASK,
+			   0);
+}
+
+static void realview_clcd_enable(struct clcd_fb *fb)
+{
+	dev_info(&fb->dev->dev, "enable RealView CLCD connectors\n");
+	regmap_update_bits(versatile_syscon_map,
+			   SYS_CLCD,
+			   SYS_CLCD_CONNECTOR_MASK,
+			   SYS_CLCD_NLCDIOON | SYS_CLCD_PWR3V5SWITCH);
+}
+
+struct versatile_panel {
+	u32 id;
+	char *compatible;
+	bool ib2;
+};
+
+static const struct versatile_panel versatile_panels[] = {
+	{
+		.id = SYS_CLCD_ID_VGA,
+		.compatible = "VGA",
+	},
+	{
+		.id = SYS_CLCD_ID_SANYO_3_8,
+		.compatible = "sanyo,tm38qv67a02a",
+	},
+	{
+		.id = SYS_CLCD_ID_SHARP_8_4,
+		.compatible = "sharp,lq084v1dg21",
+	},
+	{
+		.id = SYS_CLCD_ID_EPSON_2_2,
+		.compatible = "epson,l2f50113t00",
+	},
+	{
+		.id = SYS_CLCD_ID_SANYO_2_5,
+		.compatible = "sanyo,alr252rgt",
+		.ib2 = true,
+	},
+};
+
+static void versatile_panel_probe(struct device *dev,
+				  struct device_node *endpoint)
+{
+	struct versatile_panel const *vpanel = NULL;
+	struct device_node *panel = NULL;
+	u32 val;
+	int ret;
+	int i;
+
+	/*
+	 * The Versatile CLCD has a panel auto-detection mechanism.
+	 * We use this and look for the compatible panel in the
+	 * device tree.
+	 */
+	ret = regmap_read(versatile_syscon_map, SYS_CLCD, &val);
+	if (ret) {
+		dev_err(dev, "cannot read CLCD syscon register\n");
+		return;
+	}
+	val &= SYS_CLCD_CLCDID_MASK;
+
+	/* First find corresponding panel information */
+	for (i = 0; i < ARRAY_SIZE(versatile_panels); i++) {
+		vpanel = &versatile_panels[i];
+
+		if (val == vpanel->id) {
+			dev_err(dev, "autodetected panel \"%s\"\n",
+				vpanel->compatible);
+			break;
+		}
+	}
+	if (i == ARRAY_SIZE(versatile_panels)) {
+		dev_err(dev, "could not auto-detect panel\n");
+		return;
+	}
+
+	panel = of_graph_get_remote_port_parent(endpoint);
+	if (!panel) {
+		dev_err(dev, "could not locate panel in DT\n");
+		return;
+	}
+	if (!of_device_is_compatible(panel, vpanel->compatible))
+		dev_err(dev, "panel in DT is not compatible with the "
+			"auto-detected panel, continuing anyway\n");
+
+	/*
+	 * If we have a Sanyo 2.5" port
+	 * that we're running on an IB2 and proceed to look for the
+	 * IB2 syscon regmap.
+	 */
+	if (!vpanel->ib2)
+		return;
+
+	versatile_ib2_map = syscon_regmap_lookup_by_compatible(
+		"arm,versatile-ib2-syscon");
+	if (IS_ERR(versatile_ib2_map)) {
+		dev_err(dev, "could not locate IB2 control register\n");
+		versatile_ib2_map = NULL;
+		return;
+	}
+}
+
+int versatile_clcd_init_panel(struct clcd_fb *fb,
+			      struct device_node *endpoint)
+{
+	const struct of_device_id *clcd_id;
+	enum versatile_clcd versatile_clcd_type;
+	struct device_node *np;
+	struct regmap *map;
+	struct device *dev = &fb->dev->dev;
+
+	np = of_find_matching_node_and_match(NULL, versatile_clcd_of_match,
+					     &clcd_id);
+	if (!np) {
+		dev_err(dev, "no Versatile syscon node\n");
+		return -ENODEV;
+	}
+	versatile_clcd_type = (enum versatile_clcd)clcd_id->data;
+
+	map = syscon_node_to_regmap(np);
+	if (!map) {
+		dev_err(dev, "no Versatile syscon regmap\n");
+		return -ENODEV;
+	}
+
+	switch (versatile_clcd_type) {
+	case INTEGRATOR_CLCD_CM:
+		versatile_syscon_map = map;
+		fb->board->enable = integrator_clcd_enable;
+		/* Override the caps, we have only these */
+		fb->board->caps = CLCD_CAP_5551 | CLCD_CAP_RGB565 |
+			CLCD_CAP_888;
+		dev_info(dev, "set up callbacks for Integrator PL110\n");
+		break;
+	case VERSATILE_CLCD:
+		versatile_syscon_map = map;
+		fb->board->enable = versatile_clcd_enable;
+		fb->board->disable = versatile_clcd_disable;
+		fb->board->decode = versatile_clcd_decode;
+		versatile_panel_probe(dev, endpoint);
+		dev_info(dev, "set up callbacks for Versatile\n");
+		break;
+	case REALVIEW_CLCD_EB:
+	case REALVIEW_CLCD_PB1176:
+	case REALVIEW_CLCD_PB11MP:
+	case REALVIEW_CLCD_PBA8:
+	case REALVIEW_CLCD_PBX:
+		versatile_syscon_map = map;
+		fb->board->enable = realview_clcd_enable;
+		fb->board->disable = realview_clcd_disable;
+		dev_info(dev, "set up callbacks for RealView PL111\n");
+		break;
+	default:
+		dev_info(dev, "unknown Versatile system controller\n");
+		break;
+	}
+
+	return 0;
+}
+
+#endif
diff --git a/drivers/video/fbdev/amba-clcd-versatile.h b/drivers/video/fbdev/amba-clcd-versatile.h
new file mode 100644
index 000000000000..1b14359c2cf6
--- /dev/null
+++ b/drivers/video/fbdev/amba-clcd-versatile.h
@@ -0,0 +1,17 @@
+/*
+ * Special local versatile callbacks
+ */
+#include <linux/of.h>
+#include <linux/amba/bus.h>
+#include <linux/platform_data/video-clcd-versatile.h>
+
+#if defined(CONFIG_PLAT_VERSATILE_CLCD) && defined(CONFIG_OF)
+int versatile_clcd_init_panel(struct clcd_fb *fb,
+			      struct device_node *endpoint);
+#else
+static inline int versatile_clcd_init_panel(struct clcd_fb *fb,
+				struct device_node *endpoint)
+{
+	return 0;
+}
+#endif
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 2541b237e46e..9a0e7ebeaa33 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -38,6 +38,7 @@
 #include <asm/sizes.h>
 
 #include "amba-clcd-nomadik.h"
+#include "amba-clcd-versatile.h"
 
 #define to_clcd(info)	container_of(info, struct clcd_fb, fb)
 
@@ -1042,7 +1043,8 @@ static int clcdfb_remove(struct amba_device *dev)
 }
 
 static struct clcd_vendor_data vendor_arm = {
-	/* No special business */
+	/* Sets up the versatile board displays */
+	.init_panel = versatile_clcd_init_panel,
 };
 
 static struct clcd_vendor_data vendor_nomadik = {
-- 
2.4.3



From ard.biesheuvel at linaro.org  Tue Feb 23 02:03:12 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 23 Feb 2016 11:03:12 +0100
Subject: [RFC PATCH 00/10] arm64: restrict __pa translation to linear
 virtual addresses
In-Reply-To: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <CAKv+Gu8mrgRZaK5c+AuZBS=XA-66P3=UqP-J3O0_vNck_iUQMA@mail.gmail.com>

On 22 February 2016 at 21:54, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> As pointed out by Will, performing non-trivial arithmetic in the implementation
> of __pa() may affect performance. So instead of allowing __pa() to deal with
> addresses that are either covered by the kernel mappin in the vmalloc area, or
> by the linear region, let's restrict ourselves to the latter.
>
> This involves replacing some __pa() translations with a specific translation
> for kernel symbols (__pa_symbol), but other than that it is fairly
> straightforward (except KASAN is being a pain again, but for the purpose of this
> discussion that should not matter too much)
>

With some additional s/__pa/__pa_symbol/ replacements for SMP and KVM,
this runs happily on my Seattle A0 (no kasan yet, though)


> Patch #1 is a fix for a bug that I spotted  while working on this.
>
> Patch #2 introduces the new translations __kimg_to_phys and __pa_symbol. They
> do exactly the same but the former matches the existing __phys_to_kimg, and the
> latter already exists on x86 as well for translating 'symbols visible to C code'
>
> Patch #3 - #9 replace various instances of __pa() translations involving virtual
> addresses pointing into the kernel image.
>
> Patch #10 finally removes the comparison against PAGE_OFFSET from the
> implementation of __virt_to_phys(), so that it can only be used for addresses
> that are known to be in the linear region.
>
> git://git.linaro.org/people/ard.biesheuvel/linux-arm.git arm64-pa-linear-mapping
>
> Ard Biesheuvel (10):
>   arm64: mm: move assignment of 'high_memory' before its first use
>   arm64: introduce __kimg_to_phys() and __pa_symbol()
>   arm64: mm: avoid __pa translations in cpu_replace_ttbr1
>   arm64: mm: avoid __pa translations on empty_zero_page
>   arm64: mm: avoid __pa translations in early_fixmap_init
>   arm64: mm: use __pa_symbol() not __pa() for section boundary symbols
>   arm64: mm: avoid __pa translations for idmap_pg_dir and swapper_pg_dir
>   arm64: vdso: avoid __pa translations
>   arm64: insn: avoid __pa translations
>   arm64: mm: restrict __pa() translations to linear virtual addresses
>
>  arch/arm64/include/asm/memory.h      | 15 ++++++++----
>  arch/arm64/include/asm/mmu_context.h | 10 ++++----
>  arch/arm64/include/asm/pgalloc.h     |  2 --
>  arch/arm64/include/asm/pgtable.h     |  2 +-
>  arch/arm64/kernel/insn.c             |  2 +-
>  arch/arm64/kernel/setup.c            |  8 +++----
>  arch/arm64/kernel/vdso.c             |  5 ++--
>  arch/arm64/mm/init.c                 | 13 +++++++----
>  arch/arm64/mm/mmu.c                  | 24 ++++++++++----------
>  9 files changed, 43 insertions(+), 38 deletions(-)
>
> --
> 2.5.0
>


From linus.walleij at linaro.org  Tue Feb 23 02:10:33 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Feb 2016 11:10:33 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <3695074.sKSIyOjpjD@wuerfel>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <3695074.sKSIyOjpjD@wuerfel>
Message-ID: <CACRpkdZjfjOCFUucF1U5yVZBxSwa41GKEMv-HHQE=ymF2NZ21g@mail.gmail.com>

On Tue, Feb 23, 2016 at 10:34 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Tuesday 23 February 2016 10:08:05 Linus Walleij wrote:
>> I will think of a better solution, if any, for this for v4.6, but will
>> put forward something that handles the Nomadik and all the
>> other ARM reference designs for now.
>>
>
> How about still describing all known panels in the DT marked 'status="disabled"',
> but then having a minimal piece of board specific code that just enables
> whichever one gets detected at boot time?

Close but no cigar :D

It means that all panels (enabled and all disabled) have to have the same
endpoint in the of_graph.

I tried it:

    panel at 0 {
        compatible = "panel-dpi";
        port {
            clcd_panel: endpoint {
                remote-endpoint = <&clcd_pads>;
            };
        };
(...)

    panel at 1 {
        compatible = "panel-dpi";
        port {
            clcd_panel: endpoint {
                remote-endpoint = <&clcd_pads>;
            };
        };
(...)


        display at 10120000 {
(...)
            port {
(...)
                clcd_pads: endpoint at 0 {
                    reg = <0>;
                    remote-endpoint = <&clcd_panel>;
                    arm,pl11x,tft-r0g0b0-pads = <1 7 13>;
                };
            };



Building the device tree:

ERROR (duplicate_label): ERROR (duplicate_label): Duplicate label
'clcd_panel' on /panel at 1/port/endpoint and /panel at 0/port/endpoint
Duplicate label 'clcd_panel' on /panel at 1/port/endpoint and
/panel at 0/port/endpoint

So the dtc does not allow duplicate node labels for the phandle
even if the node it resides in is disabled. Tough luck...

Yours,
Linus Walleij


From LW at KARO-electronics.de  Tue Feb 23 02:15:59 2016
From: LW at KARO-electronics.de (Lothar =?UTF-8?B?V2HDn21hbm4=?=)
Date: Tue, 23 Feb 2016 11:15:59 +0100
Subject: [PATCH 2/9] spi: imx: initialize usedma earlier
In-Reply-To: <1456219438-21205-3-git-send-email-s.hauer@pengutronix.de>
References: <1456219438-21205-1-git-send-email-s.hauer@pengutronix.de>
 <1456219438-21205-3-git-send-email-s.hauer@pengutronix.de>
Message-ID: <20160223111559.3c2cb641@ipc1.ka-ro>

Hi,

On Tue, 23 Feb 2016 10:23:51 +0100 Sascha Hauer wrote:
> So that the SoC specific config function can know if we will do
> DMA or not. Will be needed in following patches.
> 
> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
>
The first sentence of the commit log sounds silly unless you read it in
conjunction with the subject header. I made this remark already in
<20160219090846.3004de9d at ipc1.ka-ro>

Is there any reason why this commit log is written as a continuation of
the subject line (whithout making that obvious) while all the other
commit logs in your patch set are self-contained?


Lothar Wa?mann


From will.deacon at arm.com  Tue Feb 23 02:16:42 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Feb 2016 10:16:42 +0000
Subject: [PATCH] arm64: move brk immediate argument definitions to
 separate header
In-Reply-To: <1456214205-18743-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456214205-18743-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160223101642.GB3966@arm.com>

On Tue, Feb 23, 2016 at 08:56:45AM +0100, Ard Biesheuvel wrote:
> Instead of reversing the header dependency between asm/bug.h and
> asm/debug-monitors.h, split off the brk instruction immediate value
> defines into a new header asm/brk-imm.h, and include it from both.
> 
> This solves the circular dependency issue that prevents BUG() from
> being used in some header files, and keeps the definitions together.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
>  arch/arm64/include/asm/brk-imm.h        | 25 +++++++++++++++++++++++++
>  arch/arm64/include/asm/bug.h            |  2 +-
>  arch/arm64/include/asm/debug-monitors.h | 14 +-------------
>  3 files changed, 27 insertions(+), 14 deletions(-)
>  create mode 100644 arch/arm64/include/asm/brk-imm.h

Acked-by: Will Deacon <will.deacon at arm.com>

Will


From s.hauer at pengutronix.de  Tue Feb 23 02:24:55 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Tue, 23 Feb 2016 11:24:55 +0100
Subject: [PATCH] spi: imx: initialize usedma earlier
In-Reply-To: <20160223111559.3c2cb641@ipc1.ka-ro>
References: <20160223111559.3c2cb641@ipc1.ka-ro>
Message-ID: <1456223095-32185-1-git-send-email-s.hauer@pengutronix.de>

The SoC specific config function does not know if DMA will be used or
not. This information will be useful to configure the SPI controller
correctly for DMA in following patches, so initialize the usedma
variable before calling into the SoC specific config function.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index a61b1b1..5792918 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -815,6 +815,11 @@ static int spi_imx_setupxfer(struct spi_device *spi,
 		spi_imx->tx = spi_imx_buf_tx_u32;
 	}
 
+	if (spi_imx_can_dma(spi_imx->bitbang.master, spi, t))
+		spi_imx->usedma = 1;
+	else
+		spi_imx->usedma = 0;
+
 	spi_imx->devtype_data->config(spi_imx, &config);
 
 	return 0;
@@ -1040,14 +1045,10 @@ static int spi_imx_transfer(struct spi_device *spi,
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
 
-	if (spi_imx->bitbang.master->can_dma &&
-	    spi_imx_can_dma(spi_imx->bitbang.master, spi, transfer)) {
-		spi_imx->usedma = true;
+	if (spi_imx->usedma)
 		return spi_imx_dma_transfer(spi_imx, transfer);
-	}
-	spi_imx->usedma = false;
-
-	return spi_imx_pio_transfer(spi, transfer);
+	else
+		return spi_imx_pio_transfer(spi, transfer);
 }
 
 static int spi_imx_setup(struct spi_device *spi)
-- 
2.7.0



From will.deacon at arm.com  Tue Feb 23 02:26:11 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Feb 2016 10:26:11 +0000
Subject: [PATCH v12 4/5] arm64, numa: Add NUMA support for arm64 platforms.
In-Reply-To: <1456192703-2274-5-git-send-email-ddaney.cavm@gmail.com>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
 <1456192703-2274-5-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <20160223102610.GD3966@arm.com>

On Mon, Feb 22, 2016 at 05:58:22PM -0800, David Daney wrote:
> From: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
> 
> Attempt to get the memory and CPU NUMA node via of_numa.  If that
> fails, default the dummy NUMA node and map all memory and CPUs to node
> 0.
> 
> Tested-by: Shannon Zhao <shannon.zhao at linaro.org>
> Reviewed-by: Robert Richter <rrichter at cavium.com>
> Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
> Signed-off-by: David Daney <david.daney at cavium.com>
> ---
>  arch/arm64/Kconfig                |  26 +++
>  arch/arm64/include/asm/mmzone.h   |  12 ++
>  arch/arm64/include/asm/numa.h     |  45 +++++
>  arch/arm64/include/asm/topology.h |  10 +
>  arch/arm64/kernel/pci.c           |  10 +
>  arch/arm64/kernel/setup.c         |   4 +
>  arch/arm64/kernel/smp.c           |   4 +
>  arch/arm64/mm/Makefile            |   1 +
>  arch/arm64/mm/init.c              |  34 +++-
>  arch/arm64/mm/mmu.c               |   1 +
>  arch/arm64/mm/numa.c              | 403 ++++++++++++++++++++++++++++++++++++++
>  11 files changed, 545 insertions(+), 5 deletions(-)
>  create mode 100644 arch/arm64/include/asm/mmzone.h
>  create mode 100644 arch/arm64/include/asm/numa.h
>  create mode 100644 arch/arm64/mm/numa.c

[...]

> diff --git a/arch/arm64/include/asm/mmzone.h b/arch/arm64/include/asm/mmzone.h
> new file mode 100644
> index 0000000..a0de9e6
> --- /dev/null
> +++ b/arch/arm64/include/asm/mmzone.h
> @@ -0,0 +1,12 @@
> +#ifndef __ASM_MMZONE_H
> +#define __ASM_MMZONE_H
> +
> +#ifdef CONFIG_NUMA
> +
> +#include <asm/numa.h>
> +
> +extern struct pglist_data *node_data[];
> +#define NODE_DATA(nid)		(node_data[(nid)])
> +
> +#endif /* CONFIG_NUMA */
> +#endif /* __ASM_MMZONE_H */

What happened to the patch cleaning this up in generic code?

Will


From aford173 at gmail.com  Tue Feb 23 02:32:00 2016
From: aford173 at gmail.com (Adam Ford)
Date: Tue, 23 Feb 2016 04:32:00 -0600
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56CC2D39.80909@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
Message-ID: <CAHCN7xLo7q=Ts3WLvx_GzSBWt5r1SiU7vr+W==kUAaAvmwXJYA@mail.gmail.com>

On Tue, Feb 23, 2016 at 3:58 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> (cc'ing a few more people as this is going into generic direction)
>
> On 23/02/16 11:08, Linus Walleij wrote:
>> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
>>
>>> This moves the versatile CLCD configuration to the device tree by:
>>
>> As this Schr?dinger's cat approach seems controversial, as well
>> as the alternative to manipulate the DT in memory at run-time,
>> I will respin the series without the full Versatile support, adding
>> plug-in for the other ARM boards and and half-baked support
>> for the Versatile supporting just VGA (like the other reference
>> designs from ARM).
>>
>> The pluggable displays prove yet again to be a problem to the
>> world, sigh.
>>
>> I will think of a better solution, if any, for this for v4.6, but will
>> put forward something that handles the Nomadik and all the
>> other ARM reference designs for now.
>
> I had a chat with Tom Rini and Pantelis Antoniou yesterday.
>
> Panto is about to send a new series for DT overlay management soon. I
> haven't had time to test that yet, but what it would give us is that you
> could build DT overlay binaries as "firmware" into the kernel image, and
> thus the panel DT data would be there even before rootfs is mounted. The
> DT overlays can be loaded from the rootfs or initramfs too, if it's not
> critical to get the display up early.
>
> I'm not quite sure how it works if, as in versatile display case, there
> are multiple DT overlays of which one has to be enabled. I hope there's
> support to choose which one to use via kernel cmdline or similar.
>
> I would personally like it much more if the bootloader would either
> compose a final dtb from DT fragments and pass it to the kernel, or
> alternatively the bootloader would pass the base dtb image and a bunch
> of DT overlays to the kernel, and the kernel would deal with the DT
> overlays.
>
If there was a nice way to merge the device trees, I would love to
create device tree 'modules' that could be loaded at will and merged
just before the time of boot.  I could see this being useful beyond
just plugable displays.

> In any case, I think the firmware solution is a good step forward, and
> will probably work fine for many users. Then again, I haven't tested it
> yet so I don't know the details, and it's not in the mainline.
>
I am willing to test it, but I'll need the patch and some instructions
from Panto.

>  Tomi
>


From suzuki.poulose at arm.com  Tue Feb 23 02:31:39 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:31:39 +0000
Subject: [PATCH v5 1/7] arm64: Add a helper for parking CPUs in a loop
In-Reply-To: <1456223505-2955-1-git-send-email-suzuki.poulose@arm.com>
References: <1456223505-2955-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456223505-2955-2-git-send-email-suzuki.poulose@arm.com>

Adds a routine which can be used to park CPUs (spinning in kernel)
when they can't be killed.

Cc: Catalin Marinas <catalin.marinas at arm.com>
Cc: Mark Rutland <mark.rutland at arm.com>
Acked-by: Will Deacon <will.deacon at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/include/asm/smp.h   |    8 ++++++++
 arch/arm64/kernel/cpufeature.c |    5 +----
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index d9c3d6a..53b53a9 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -69,4 +69,12 @@ extern int __cpu_disable(void);
 extern void __cpu_die(unsigned int cpu);
 extern void cpu_die(void);
 
+static inline void cpu_park_loop(void)
+{
+	for (;;) {
+		wfe();
+		wfi();
+	}
+}
+
 #endif /* ifndef __ASM_SMP_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 5c90aa4..cc4a089 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -842,10 +842,7 @@ static void fail_incapable_cpu(char *cap_type,
 	/* Check if we can park ourselves */
 	if (cpu_ops[cpu] && cpu_ops[cpu]->cpu_die)
 		cpu_ops[cpu]->cpu_die(cpu);
-	asm(
-	"1:	wfe\n"
-	"	wfi\n"
-	"	b	1b");
+	cpu_park_loop();
 }
 
 /*
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:31:41 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:31:41 +0000
Subject: [PATCH v5 3/7] arm64: Move cpu_die_early to smp.c
In-Reply-To: <1456223505-2955-1-git-send-email-suzuki.poulose@arm.com>
References: <1456223505-2955-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456223505-2955-4-git-send-email-suzuki.poulose@arm.com>

This patch moves cpu_die_early to smp.c, where it fits better.
No functional changes, except for adding the necessary checks
for CONFIG_HOTPLUG_CPU.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Acked-by: Will Deacon <will.deacon at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/include/asm/smp.h   |    1 +
 arch/arm64/kernel/cpufeature.c |   19 -------------------
 arch/arm64/kernel/smp.c        |   22 ++++++++++++++++++++++
 3 files changed, 23 insertions(+), 19 deletions(-)

diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index 53b53a9..32e75ee 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -68,6 +68,7 @@ extern int __cpu_disable(void);
 
 extern void __cpu_die(unsigned int cpu);
 extern void cpu_die(void);
+extern void cpu_die_early(void);
 
 static inline void cpu_park_loop(void)
 {
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 8275e7d..60c3f47 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -827,25 +827,6 @@ static u64 __raw_read_system_reg(u32 sys_id)
 }
 
 /*
- * Kill the calling secondary CPU, early in bringup before it is turned
- * online.
- */
-void cpu_die_early(void)
-{
-	int cpu = smp_processor_id();
-
-	pr_crit("CPU%d: will not boot\n", cpu);
-
-	/* Mark this CPU absent */
-	set_cpu_present(cpu, 0);
-
-	/* Check if we can park ourselves */
-	if (cpu_ops[cpu] && cpu_ops[cpu]->cpu_die)
-		cpu_ops[cpu]->cpu_die(cpu);
-	cpu_park_loop();
-}
-
-/*
  * Run through the enabled system capabilities and enable() it on this CPU.
  * The capabilities were decided based on the available CPUs at the boot time.
  * Any new CPU should match the system wide status of the capability. If the
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index b1adc51..59f032b 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -313,6 +313,28 @@ void cpu_die(void)
 }
 #endif
 
+/*
+ * Kill the calling secondary CPU, early in bringup before it is turned
+ * online.
+ */
+void cpu_die_early(void)
+{
+	int cpu = smp_processor_id();
+
+	pr_crit("CPU%d: will not boot\n", cpu);
+
+	/* Mark this CPU absent */
+	set_cpu_present(cpu, 0);
+
+#ifdef CONFIG_HOTPLUG_CPU
+	/* Check if we can park ourselves */
+	if (cpu_ops[cpu] && cpu_ops[cpu]->cpu_die)
+		cpu_ops[cpu]->cpu_die(cpu);
+#endif
+
+	cpu_park_loop();
+}
+
 static void __init hyp_mode_check(void)
 {
 	if (is_hyp_mode_available())
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:31:38 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:31:38 +0000
Subject: [PATCH v5 0/7] Verify early CPU features
Message-ID: <1456223505-2955-1-git-send-email-suzuki.poulose@arm.com>

This series adds support for verifying some of the cpufeatures
that are decided early in the boot process based on the boot
CPU and cannot be delayed until all the CPUs are up (e.g, ASIDBits
and may be VHE?). It also adds support for handling the failures
in booting the secondary CPUs which could not be synchronised
with the master CPU, otherwise.

It also adds one of the users of this early hook, check for ASIDBits.
The mm_context id is based on the ASIDBits width supported by the
boot CPU and is used early in the initialisation. So we need to make
sure that all the secondary CPUs supports the width reported by the
booting CPU, failing which we crash the system.

This series has been tested on Juno, Fast model by injecting smaller
ASIDBits and lack of page-size support.

Changes since V4:
 - Move __early_cpu_boot_status to .data.cache_aligned section.
 - Add dsb() to update_boot_cpu_status() - Suggested by: Mark Rutland
 - Added Ack from Will.

Changes since V3:
 - Sanitise the boot status handling code, removing unnecessary dsb()/isb().
   (aka: write the code with a little bit more of thought), removed RFC tag.
 - Store the status in head.txt when MMU turned off, so that it is not shared
   in the CWG and can be invalidated reliably.

Changes since V2:
 - Add support for synchronising the booting status of a secondary
   CPU. Added RFC Tag. Patch - 4
 - Panic the system with incompatible ASIDBits


Suzuki K Poulose (7):
  arm64: Add a helper for parking CPUs in a loop
  arm64: Introduce cpu_die_early
  arm64: Move cpu_die_early to smp.c
  arm64: Handle early CPU boot failures
  arm64: Enable CPU capability verification unconditionally
  arm64: Add helper for extracting ASIDBits
  arm64: Ensure the secondary CPUs have safe ASIDBits size

 arch/arm64/include/asm/cpufeature.h  |    6 ---
 arch/arm64/include/asm/mmu_context.h |    2 +
 arch/arm64/include/asm/smp.h         |   37 +++++++++++++++++++
 arch/arm64/kernel/asm-offsets.c      |    2 +
 arch/arm64/kernel/cpufeature.c       |   48 +++++++++---------------
 arch/arm64/kernel/head.S             |   34 ++++++++++++++++-
 arch/arm64/kernel/smp.c              |   67 ++++++++++++++++++++++++++++++++++
 arch/arm64/mm/context.c              |   54 ++++++++++++++++++++-------
 8 files changed, 198 insertions(+), 52 deletions(-)

-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:31:42 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:31:42 +0000
Subject: [PATCH v5 4/7] arm64: Handle early CPU boot failures
In-Reply-To: <1456223505-2955-1-git-send-email-suzuki.poulose@arm.com>
References: <1456223505-2955-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456223505-2955-5-git-send-email-suzuki.poulose@arm.com>

A secondary CPU could fail to come online due to insufficient
capabilities and could simply die or loop in the kernel.
e.g, a CPU with no support for the selected kernel PAGE_SIZE
loops in kernel with MMU turned off.
or a hotplugged CPU which doesn't have one of the advertised
system capability will die during the activation.

There is no way to synchronise the status of the failing CPU
back to the master. This patch solves the issue by adding a
field to the secondary_data which can be updated by the failing
CPU. If the secondary CPU fails even before turning the MMU on,
it updates the status in a special variable reserved in the head.txt
section to make sure that the update can be cache invalidated safely
without possible sharing of cache write back granule.

Here are the possible states :

 -1. CPU_MMU_OFF - Initial value set by the master CPU, this value
indicates that the CPU could not turn the MMU on, hence the status
could not be reliably updated in the secondary_data. Instead, the
CPU has updated the status @ __early_cpu_boot_status.

 0. CPU_BOOT_SUCCESS - CPU has booted successfully.

 1. CPU_KILL_ME - CPU has invoked cpu_ops->die, indicating the
master CPU to synchronise by issuing a cpu_ops->cpu_kill.

 2. CPU_STUCK_IN_KERNEL - CPU couldn't invoke die(), instead is
looping in the kernel. This information could be used by say,
kexec to check if it is really safe to do a kexec reboot.

 3. CPU_PANIC_KERNEL - CPU detected some serious issues which
requires kernel to crash immediately. The secondary CPU cannot
call panic() until it has initialised the GIC. This flag can
be used to instruct the master to do so.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Acked-by: Will Deacon <will.deacon at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
Changes since V4:
 - Add braces around status values.
 - Use adr_l macro for write to __early_cpu_boot_status
 - Move __early_cpu_boot_status to .data..cacheline_aligned section. Invalidate
   only on the write side.
 - Get rid of the smp_{w,r}mb() around updates to secondary_data.status.
 - Add dsb() to update_boot_cpu_status()
---
 arch/arm64/include/asm/smp.h    |   28 ++++++++++++++++++++++++
 arch/arm64/kernel/asm-offsets.c |    2 ++
 arch/arm64/kernel/head.S        |   34 +++++++++++++++++++++++++++--
 arch/arm64/kernel/smp.c         |   45 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 107 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index 32e75ee..42baa97 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -16,6 +16,19 @@
 #ifndef __ASM_SMP_H
 #define __ASM_SMP_H
 
+/* Values for secondary_data.status */
+
+#define CPU_MMU_OFF		(-1)
+#define CPU_BOOT_SUCCESS	(0)
+/* The cpu invoked ops->cpu_die, synchronise it with cpu_kill */
+#define CPU_KILL_ME		(1)
+/* The cpu couldn't die gracefully and is looping in the kernel */
+#define CPU_STUCK_IN_KERNEL	(2)
+/* Fatal system error detected by secondary CPU, crash the system */
+#define CPU_PANIC_KERNEL	(3)
+
+#ifndef __ASSEMBLY__
+
 #include <linux/threads.h>
 #include <linux/cpumask.h>
 #include <linux/thread_info.h>
@@ -54,11 +67,17 @@ asmlinkage void secondary_start_kernel(void);
 
 /*
  * Initial data for bringing up a secondary CPU.
+ * @stack  - sp for the secondary CPU
+ * @status - Result passed back from the secondary CPU to
+ *           indicate failure.
  */
 struct secondary_data {
 	void *stack;
+	int status;
 };
+
 extern struct secondary_data secondary_data;
+extern int __early_cpu_boot_status;
 extern void secondary_entry(void);
 
 extern void arch_send_call_function_single_ipi(int cpu);
@@ -78,4 +97,13 @@ static inline void cpu_park_loop(void)
 	}
 }
 
+static inline void update_cpu_boot_status(int val)
+{
+	WRITE_ONCE(secondary_data.status, val);
+	/* Ensure the visibility of the status update */
+	dsb(ishst);
+}
+
+#endif /* ifndef __ASSEMBLY__ */
+
 #endif /* ifndef __ASM_SMP_H */
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index fffa4ac6..463fcf1 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -104,6 +104,8 @@ int main(void)
   DEFINE(TZ_MINWEST,		offsetof(struct timezone, tz_minuteswest));
   DEFINE(TZ_DSTTIME,		offsetof(struct timezone, tz_dsttime));
   BLANK();
+  DEFINE(CPU_BOOT_STACK,	offsetof(struct secondary_data, stack));
+  BLANK();
 #ifdef CONFIG_KVM_ARM_HOST
   DEFINE(VCPU_CONTEXT,		offsetof(struct kvm_vcpu, arch.ctxt));
   DEFINE(CPU_GP_REGS,		offsetof(struct kvm_cpu_context, gp_regs));
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 917d981..4d26d92 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -34,6 +34,7 @@
 #include <asm/pgtable-hwdef.h>
 #include <asm/pgtable.h>
 #include <asm/page.h>
+#include <asm/smp.h>
 #include <asm/sysreg.h>
 #include <asm/thread_info.h>
 #include <asm/virt.h>
@@ -611,7 +612,7 @@ ENTRY(secondary_startup)
 ENDPROC(secondary_startup)
 
 ENTRY(__secondary_switched)
-	ldr	x0, [x21]			// get secondary_data.stack
+	ldr	x0, [x21, #CPU_BOOT_STACK]	// get secondary_data.stack
 	mov	sp, x0
 	and	x0, x0, #~(THREAD_SIZE - 1)
 	msr	sp_el0, x0			// save thread_info
@@ -620,6 +621,30 @@ ENTRY(__secondary_switched)
 ENDPROC(__secondary_switched)
 
 /*
+ * The booting CPU updates the failed status @__early_cpu_boot_status,
+ * with MMU turned off. 
+ *
+ * update_early_cpu_boot_status tmp, status
+ *  - Corrupts tmp1, tmp2
+ *  - Writes 'status' to __early_cpu_boot_status and makes sure
+ *    it is committed to memory.
+ */
+
+	.macro	update_early_cpu_boot_status status, tmp1, tmp2
+	adr_l	\tmp1, __early_cpu_boot_status
+	mov	\tmp2, #\status
+	str	\tmp2, [\tmp1]
+	dmb	sy
+	dc	ivac, \tmp1			// Invalidate potentially stale cache line
+	.endm
+
+	.pushsection	.data..cacheline_aligned
+	.align	L1_CACHE_SHIFT
+ENTRY(__early_cpu_boot_status)
+	.long 	0
+	.popsection
+
+/*
  * Enable the MMU.
  *
  *  x0  = SCTLR_EL1 value for turning on the MMU.
@@ -636,6 +661,7 @@ __enable_mmu:
 	ubfx	x2, x1, #ID_AA64MMFR0_TGRAN_SHIFT, 4
 	cmp	x2, #ID_AA64MMFR0_TGRAN_SUPPORTED
 	b.ne	__no_granule_support
+	update_early_cpu_boot_status 0, x1, x2
 	ldr	x5, =vectors
 	msr	vbar_el1, x5
 	msr	ttbr0_el1, x25			// load TTBR0
@@ -655,6 +681,10 @@ __enable_mmu:
 ENDPROC(__enable_mmu)
 
 __no_granule_support:
+	/* Indicate that this CPU can't boot and is stuck in the kernel */
+	update_early_cpu_boot_status CPU_STUCK_IN_KERNEL, x1, x2
+1:
 	wfe
-	b __no_granule_support
+	wfi
+	b 1b
 ENDPROC(__no_granule_support)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 59f032b..a0bba03 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -63,6 +63,8 @@
  * where to place its SVC stack
  */
 struct secondary_data secondary_data;
+/* Number of CPUs which aren't online, but looping in kernel text. */
+int cpus_stuck_in_kernel;
 
 enum ipi_msg_type {
 	IPI_RESCHEDULE,
@@ -72,6 +74,16 @@ enum ipi_msg_type {
 	IPI_IRQ_WORK,
 };
 
+#ifdef CONFIG_HOTPLUG_CPU
+static int op_cpu_kill(unsigned int cpu);
+#else
+static inline int op_cpu_kill(unsigned int cpu)
+{
+	return -ENOSYS;
+}
+#endif
+
+
 /*
  * Boot a secondary CPU, and assign it the specified idle task.
  * This also gives us the initial stack to use for this CPU.
@@ -89,12 +101,14 @@ static DECLARE_COMPLETION(cpu_running);
 int __cpu_up(unsigned int cpu, struct task_struct *idle)
 {
 	int ret;
+	int status;
 
 	/*
 	 * We need to tell the secondary core where to find its stack and the
 	 * page tables.
 	 */
 	secondary_data.stack = task_stack_page(idle) + THREAD_START_SP;
+	update_cpu_boot_status(CPU_MMU_OFF);
 	__flush_dcache_area(&secondary_data, sizeof(secondary_data));
 
 	/*
@@ -118,6 +132,32 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
 	}
 
 	secondary_data.stack = NULL;
+	status = READ_ONCE(secondary_data.status);
+	if (ret && status) {
+
+		if (status == CPU_MMU_OFF)
+			status = READ_ONCE(__early_cpu_boot_status);
+
+		switch (status) {
+		default:
+			pr_err("CPU%u: failed in unknown state : 0x%x\n",
+					cpu, status);
+			break;
+		case CPU_KILL_ME:
+			if (!op_cpu_kill(cpu)) {
+				pr_crit("CPU%u: died during early boot\n", cpu);
+				break;
+			}
+			/* Fall through */
+			pr_crit("CPU%u: may not have shut down cleanly\n", cpu);
+		case CPU_STUCK_IN_KERNEL:
+			pr_crit("CPU%u: is stuck in kernel\n", cpu);
+			cpus_stuck_in_kernel++;
+			break;
+		case CPU_PANIC_KERNEL:
+			panic("CPU%u detected unsupported configuration\n", cpu);
+		}
+	}
 
 	return ret;
 }
@@ -185,6 +225,9 @@ asmlinkage void secondary_start_kernel(void)
 	 */
 	pr_info("CPU%u: Booted secondary processor [%08x]\n",
 					 cpu, read_cpuid_id());
+	update_cpu_boot_status(CPU_BOOT_SUCCESS);
+	/* Make sure the status update is visible before we complete */
+	smp_wmb();
 	set_cpu_online(cpu, true);
 	complete(&cpu_running);
 
@@ -327,10 +370,12 @@ void cpu_die_early(void)
 	set_cpu_present(cpu, 0);
 
 #ifdef CONFIG_HOTPLUG_CPU
+	update_cpu_boot_status(CPU_KILL_ME);
 	/* Check if we can park ourselves */
 	if (cpu_ops[cpu] && cpu_ops[cpu]->cpu_die)
 		cpu_ops[cpu]->cpu_die(cpu);
 #endif
+	update_cpu_boot_status(CPU_STUCK_IN_KERNEL);
 
 	cpu_park_loop();
 }
-- 
1.7.9.5



From kirill at shutemov.name  Tue Feb 23 02:32:21 2016
From: kirill at shutemov.name (Kirill A. Shutemov)
Date: Tue, 23 Feb 2016 13:32:21 +0300
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160212181640.4eabb85f@thinkpad>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
Message-ID: <20160223103221.GA1418@node.shutemov.name>

On Fri, Feb 12, 2016 at 06:16:40PM +0100, Gerald Schaefer wrote:
> On Fri, 12 Feb 2016 16:57:27 +0100
> Christian Borntraeger <borntraeger at de.ibm.com> wrote:
> 
> > > I'm also confused by pmd_none() is equal to !pmd_present() on s390. Hm?
> > 
> > Don't know, Gerald or Martin?
> 
> The implementation frequently changes depending on how many new bits Martin
> needs to squeeze out :-)
> We don't have a _PAGE_PRESENT bit for pmds, so pmd_present() just checks if the
> entry is not empty. pmd_none() of course does the opposite, it checks if it is
> empty.

I still worry about pmd_present(). It looks wrong to me. I wounder if
patch below makes a difference.

The theory is that the splitting bit effetely masked bogus pmd_present():
we had pmd_trans_splitting() in all code path and that prevented mm from
touching the pmd. Once pmd_trans_splitting() has gone, mm proceed with the
pmd where it shouldn't and here's a boom.

I'm not sure that the patch is correct wrt yound/old pmds and I have no
way to test it...

diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 64ead8091248..2eeb17ab68ac 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -490,7 +490,7 @@ static inline int pud_bad(pud_t pud)
 
 static inline int pmd_present(pmd_t pmd)
 {
-	return pmd_val(pmd) != _SEGMENT_ENTRY_INVALID;
+	return !(pmd_val(pmd) & _SEGMENT_ENTRY_INVALID);
 }
 
 static inline int pmd_none(pmd_t pmd)
-- 
 Kirill A. Shutemov


From suzuki.poulose at arm.com  Tue Feb 23 02:31:40 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:31:40 +0000
Subject: [PATCH v5 2/7] arm64: Introduce cpu_die_early
In-Reply-To: <1456223505-2955-1-git-send-email-suzuki.poulose@arm.com>
References: <1456223505-2955-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456223505-2955-3-git-send-email-suzuki.poulose@arm.com>

Or in other words, make fail_incapable_cpu() reusable.

We use fail_incapable_cpu() to kill a secondary CPU early during the
bringup, which doesn't have the system advertised capabilities.
This patch makes the routine more generic, to kill a secondary
booting CPU, getting rid of the dependency on capability struct.
This can be used by checks which are not necessarily attached to
a capability struct (e.g, cpu ASIDBits).

In that process, renames the function to cpu_die_early() to better
match its functionality. This will be moved to arch/arm64/kernel/smp.c
later.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Acked-by: Will Deacon <will.deacon at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/kernel/cpufeature.c |   24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index cc4a089..8275e7d 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -827,15 +827,15 @@ static u64 __raw_read_system_reg(u32 sys_id)
 }
 
 /*
- * Park the CPU which doesn't have the capability as advertised
- * by the system.
+ * Kill the calling secondary CPU, early in bringup before it is turned
+ * online.
  */
-static void fail_incapable_cpu(char *cap_type,
-				 const struct arm64_cpu_capabilities *cap)
+void cpu_die_early(void)
 {
 	int cpu = smp_processor_id();
 
-	pr_crit("CPU%d: missing %s : %s\n", cpu, cap_type, cap->desc);
+	pr_crit("CPU%d: will not boot\n", cpu);
+
 	/* Mark this CPU absent */
 	set_cpu_present(cpu, 0);
 
@@ -873,8 +873,11 @@ void verify_local_cpu_capabilities(void)
 		 * If the new CPU misses an advertised feature, we cannot proceed
 		 * further, park the cpu.
 		 */
-		if (!feature_matches(__raw_read_system_reg(caps[i].sys_reg), &caps[i]))
-			fail_incapable_cpu("arm64_features", &caps[i]);
+		if (!feature_matches(__raw_read_system_reg(caps[i].sys_reg), &caps[i])) {
+			pr_crit("CPU%d: missing feature: %s\n",
+					smp_processor_id(), caps[i].desc);
+			cpu_die_early();
+		}
 		if (caps[i].enable)
 			caps[i].enable(NULL);
 	}
@@ -882,8 +885,11 @@ void verify_local_cpu_capabilities(void)
 	for (i = 0, caps = arm64_hwcaps; caps[i].desc; i++) {
 		if (!cpus_have_hwcap(&caps[i]))
 			continue;
-		if (!feature_matches(__raw_read_system_reg(caps[i].sys_reg), &caps[i]))
-			fail_incapable_cpu("arm64_hwcaps", &caps[i]);
+		if (!feature_matches(__raw_read_system_reg(caps[i].sys_reg), &caps[i])) {
+			pr_crit("CPU%d: missing HWCAP: %s\n",
+					smp_processor_id(), caps[i].desc);
+			cpu_die_early();
+		}
 	}
 }
 
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:31:44 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:31:44 +0000
Subject: [PATCH v5 6/7] arm64: Add helper for extracting ASIDBits
In-Reply-To: <1456223505-2955-1-git-send-email-suzuki.poulose@arm.com>
References: <1456223505-2955-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456223505-2955-7-git-send-email-suzuki.poulose@arm.com>

Add a helper to extract ASIDBits on the current cpu

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Acked-by: Will Deacon <will.deacon at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/mm/context.c |   36 +++++++++++++++++++++++-------------
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index e87f53f..643bf4b 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -40,6 +40,28 @@ static cpumask_t tlb_flush_pending;
 #define ASID_FIRST_VERSION	(1UL << asid_bits)
 #define NUM_USER_ASIDS		ASID_FIRST_VERSION
 
+/* Get the ASIDBits supported by the current CPU */
+static u32 get_cpu_asid_bits(void)
+{
+	u32 asid;
+	int fld = cpuid_feature_extract_field(read_cpuid(ID_AA64MMFR0_EL1),
+						ID_AA64MMFR0_ASID_SHIFT);
+
+	switch (fld) {
+	default:
+		pr_warn("CPU%d: Unknown ASID size (%d); assuming 8-bit\n",
+					smp_processor_id(),  fld);
+		/* Fallthrough */
+	case 0:
+		asid = 8;
+		break;
+	case 2:
+		asid = 16;
+	}
+
+	return asid;
+}
+
 static void flush_context(unsigned int cpu)
 {
 	int i;
@@ -187,19 +209,7 @@ switch_mm_fastpath:
 
 static int asids_init(void)
 {
-	int fld = cpuid_feature_extract_field(read_cpuid(ID_AA64MMFR0_EL1), 4);
-
-	switch (fld) {
-	default:
-		pr_warn("Unknown ASID size (%d); assuming 8-bit\n", fld);
-		/* Fallthrough */
-	case 0:
-		asid_bits = 8;
-		break;
-	case 2:
-		asid_bits = 16;
-	}
-
+	asid_bits = get_cpu_asid_bits();
 	/* If we end up with more CPUs than ASIDs, expect things to crash */
 	WARN_ON(NUM_USER_ASIDS < num_possible_cpus());
 	atomic64_set(&asid_generation, ASID_FIRST_VERSION);
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:31:45 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:31:45 +0000
Subject: [PATCH v5 7/7] arm64: Ensure the secondary CPUs have safe ASIDBits
 size
In-Reply-To: <1456223505-2955-1-git-send-email-suzuki.poulose@arm.com>
References: <1456223505-2955-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456223505-2955-8-git-send-email-suzuki.poulose@arm.com>

Adds a hook for checking whether a secondary CPU has the
features used already by the kernel during early boot, based
on the boot CPU and plugs in the check for ASID size.

The ID_AA64MMFR0_EL1:ASIDBits determines the size of the mm context
id and is used in the early boot to make decisions. The value is
picked up from the Boot CPU and cannot be delayed until other CPUs
are up. If a secondary CPU has a smaller size than that of the Boot
CPU, things will break horribly and the usual SANITY check is not good
enough to prevent the system from crashing. So, crash the system with
enough information.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Acked-by: Will Deacon <will.deacon at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/include/asm/mmu_context.h |    2 ++
 arch/arm64/kernel/cpufeature.c       |   12 ++++++++++++
 arch/arm64/mm/context.c              |   18 ++++++++++++++++++
 3 files changed, 32 insertions(+)

diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index 2416578..bd8a0b9 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -147,4 +147,6 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
 #define deactivate_mm(tsk,mm)	do { } while (0)
 #define activate_mm(prev,next)	switch_mm(prev, next, NULL)
 
+void verify_cpu_asid_bits(void);
+
 #endif
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 5ba3ef1..3614066 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -24,6 +24,7 @@
 #include <asm/cpu.h>
 #include <asm/cpufeature.h>
 #include <asm/cpu_ops.h>
+#include <asm/mmu_context.h>
 #include <asm/processor.h>
 #include <asm/sysreg.h>
 
@@ -825,6 +826,15 @@ static u64 __raw_read_system_reg(u32 sys_id)
 }
 
 /*
+ * Check for CPU features that are used in early boot
+ * based on the Boot CPU value.
+ */
+static void check_early_cpu_features(void)
+{
+	verify_cpu_asid_bits();
+}
+
+/*
  * Run through the enabled system capabilities and enable() it on this CPU.
  * The capabilities were decided based on the available CPUs at the boot time.
  * Any new CPU should match the system wide status of the capability. If the
@@ -837,6 +847,8 @@ void verify_local_cpu_capabilities(void)
 	int i;
 	const struct arm64_cpu_capabilities *caps;
 
+	check_early_cpu_features();
+
 	/*
 	 * If we haven't computed the system capabilities, there is nothing
 	 * to verify.
diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 643bf4b..3b23cb4 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -24,6 +24,7 @@
 
 #include <asm/cpufeature.h>
 #include <asm/mmu_context.h>
+#include <asm/smp.h>
 #include <asm/tlbflush.h>
 
 static u32 asid_bits;
@@ -62,6 +63,23 @@ static u32 get_cpu_asid_bits(void)
 	return asid;
 }
 
+/* Check if the current cpu's ASIDBits is compatible with asid_bits */
+void verify_cpu_asid_bits(void)
+{
+	u32 asid = get_cpu_asid_bits();
+
+	if (asid < asid_bits) {
+		/*
+		 * We cannot decrease the ASID size at runtime, so panic if we support
+		 * fewer ASID bits than the boot CPU.
+		 */
+		pr_crit("CPU%d: smaller ASID size(%u) than boot CPU (%u)\n",
+				smp_processor_id(), asid, asid_bits);
+		update_cpu_boot_status(CPU_PANIC_KERNEL);
+		cpu_park_loop();
+	}
+}
+
 static void flush_context(unsigned int cpu)
 {
 	int i;
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:31:43 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:31:43 +0000
Subject: [PATCH v5 5/7] arm64: Enable CPU capability verification
 unconditionally
In-Reply-To: <1456223505-2955-1-git-send-email-suzuki.poulose@arm.com>
References: <1456223505-2955-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456223505-2955-6-git-send-email-suzuki.poulose@arm.com>

We verify the capabilities of the secondary CPUs only when
hotplug is enabled. The boot time activated CPUs do not
go through the verification by checking whether the system
wide capabilities were initialised or not.

This patch removes the capability check dependency on CONFIG_HOTPLUG_CPU,
to make sure that all the secondary CPUs go through the check.
The boot time activated CPUs will still skip the system wide
capability check. The plan is to hook in a check for CPU features
used by the kernel at early boot up, based on the Boot CPU values.

Cc: Mark Rutland <mark.rutland at arm.com>
Cc: Catalin Marinas <catalin.marinas at arm.com>
Acked-by: Will Deacon <will.deacon at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/include/asm/cpufeature.h |    6 ------
 arch/arm64/kernel/cpufeature.c      |   10 ----------
 2 files changed, 16 deletions(-)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 8f271b8..26024c4 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -164,13 +164,7 @@ void update_cpu_capabilities(const struct arm64_cpu_capabilities *caps,
 			    const char *info);
 void check_local_cpu_errata(void);
 
-#ifdef CONFIG_HOTPLUG_CPU
 void verify_local_cpu_capabilities(void);
-#else
-static inline void verify_local_cpu_capabilities(void)
-{
-}
-#endif
 
 u64 read_system_reg(u32 id);
 
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 60c3f47..5ba3ef1 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -768,8 +768,6 @@ enable_cpu_capabilities(const struct arm64_cpu_capabilities *caps)
 			on_each_cpu(caps[i].enable, NULL, true);
 }
 
-#ifdef CONFIG_HOTPLUG_CPU
-
 /*
  * Flag to indicate if we have computed the system wide
  * capabilities based on the boot time active CPUs. This
@@ -874,14 +872,6 @@ void verify_local_cpu_capabilities(void)
 	}
 }
 
-#else	/* !CONFIG_HOTPLUG_CPU */
-
-static inline void set_sys_caps_initialised(void)
-{
-}
-
-#endif	/* CONFIG_HOTPLUG_CPU */
-
 static void __init setup_feature_capabilities(void)
 {
 	update_cpu_capabilities(arm64_features, "detected feature:");
-- 
1.7.9.5



From linux at arm.linux.org.uk  Tue Feb 23 02:35:18 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 23 Feb 2016 10:35:18 +0000
Subject: [PATCH 4/7 v2] video: ARM CLCD: support pads connected in
 reverse order
In-Reply-To: <1456221704-5792-5-git-send-email-linus.walleij@linaro.org>
References: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
 <1456221704-5792-5-git-send-email-linus.walleij@linaro.org>
Message-ID: <20160223103518.GG19428@n2100.arm.linux.org.uk>

On Tue, Feb 23, 2016 at 11:01:41AM +0100, Linus Walleij wrote:
> -		if (var->red.offset == 0)
> -			val &= ~CNTL_BGR;
> -		else
> -			val |= CNTL_BGR;
> +		if (!fb->panel->bgr_connection) {
> +			if (var->red.offset == 0)
> +				val &= ~CNTL_BGR;
> +			else
> +				val |= CNTL_BGR;
> +		} else {
> +			if (var->blue.offset == 0)
> +				val &= ~CNTL_BGR;
> +			else
> +				val |= CNTL_BGR;
> +		}

		if (fb->panel->bgr_connection)
			val ^= CNTL_BGR;

is a shorter way to write the above, and probably easier on the compiler
too.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From arnd at arndb.de  Tue Feb 23 02:36:02 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 11:36:02 +0100
Subject: [PATCH] bnx2x: add a separate GENEVE Kconfig symbol
Message-ID: <1456223774-1383513-1-git-send-email-arnd@arndb.de>

When CONFIG_GENEVE is built as a loadable module, and bnx2x is built-in,
we get this link error:

drivers/net/built-in.o: In function `bnx2x_open':
:(.text+0x33322): undefined reference to `geneve_get_rx_port'
drivers/net/built-in.o: In function `bnx2x_sp_rtnl_task':
:(.text+0x3e632): undefined reference to `geneve_get_rx_port'

This avoids the problem by adding a separate Kconfig symbol named
CONFIG_BNX2X_GENEVE that is only enabled when the code is
reachable from the driver.

This is the same trick that BNX2X does for VXLAN support, and
is similar to how I40E handles both.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 883ce97d25b0 ("bnx2x: Add Geneve inner-RSS support")
---
 drivers/net/ethernet/broadcom/Kconfig            | 10 ++++++++++
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 14 +++++++-------
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/Kconfig b/drivers/net/ethernet/broadcom/Kconfig
index 19f7cd02e085..18042c2460bd 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -149,6 +149,16 @@ config BNX2X_VXLAN
 	  Say Y here if you want to enable hardware offload support for
 	  Virtual eXtensible Local Area Network (VXLAN) in the driver.
 
+config BNX2X_GENEVE
+	bool "Generic Network Virtualization Encapsulation (GENEVE) support"
+	depends on BNX2X && GENEVE && !(BNX2X=y && GENEVE=m)
+	---help---
+          This allows one to create GENEVE virtual interfaces that provide
+          Layer 2 Networks over Layer 3 Networks. GENEVE is often used
+          to tunnel virtual network infrastructure in virtualized environments.
+	  Say Y here if you want to enable hardware offload support for
+	  Generic Network Virtualization Encapsulation (GENEVE) in the driver.
+
 config BGMAC
 	tristate "BCMA bus GBit core support"
 	depends on BCMA && BCMA_HOST_SOC
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 81fc51c4ec2b..5c95d0c3b076 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -59,7 +59,7 @@
 #include <linux/semaphore.h>
 #include <linux/stringify.h>
 #include <linux/vmalloc.h>
-#if IS_ENABLED(CONFIG_GENEVE)
+#if IS_ENABLED(CONFIG_BNX2X_GENEVE)
 #include <net/geneve.h>
 #endif
 #include "bnx2x.h"
@@ -10078,7 +10078,7 @@ static void bnx2x_parity_recover(struct bnx2x *bp)
 	}
 }
 
-#if defined(CONFIG_BNX2X_VXLAN) || IS_ENABLED(CONFIG_GENEVE)
+#if defined(CONFIG_BNX2X_VXLAN) || IS_ENABLED(CONFIG_BNX2X_GENEVE)
 static int bnx2x_udp_port_update(struct bnx2x *bp)
 {
 	struct bnx2x_func_switch_update_params *switch_update_params;
@@ -10201,7 +10201,7 @@ static void bnx2x_del_vxlan_port(struct net_device *netdev,
 }
 #endif
 
-#if IS_ENABLED(CONFIG_GENEVE)
+#if IS_ENABLED(CONFIG_BNX2X_GENEVE)
 static void bnx2x_add_geneve_port(struct net_device *netdev,
 				  sa_family_t sa_family, __be16 port)
 {
@@ -10327,7 +10327,7 @@ sp_rtnl_not_reset:
 			       &bp->sp_rtnl_state))
 		bnx2x_update_mng_version(bp);
 
-#if defined(CONFIG_BNX2X_VXLAN) || IS_ENABLED(CONFIG_GENEVE)
+#if defined(CONFIG_BNX2X_VXLAN) || IS_ENABLED(CONFIG_BNX2X_GENEVE)
 	if (test_and_clear_bit(BNX2X_SP_RTNL_CHANGE_UDP_PORT,
 			       &bp->sp_rtnl_state)) {
 		if (bnx2x_udp_port_update(bp)) {
@@ -10344,7 +10344,7 @@ sp_rtnl_not_reset:
 			if (!bp->udp_tunnel_ports[BNX2X_UDP_PORT_VXLAN].count)
 				vxlan_get_rx_port(bp->dev);
 #endif
-#if IS_ENABLED(CONFIG_GENEVE)
+#if IS_ENABLED(CONFIG_BNX2X_GENEVE)
 			if (!bp->udp_tunnel_ports[BNX2X_UDP_PORT_GENEVE].count)
 				geneve_get_rx_port(bp->dev);
 #endif
@@ -12557,7 +12557,7 @@ static int bnx2x_open(struct net_device *dev)
 	if (IS_PF(bp))
 		vxlan_get_rx_port(dev);
 #endif
-#if IS_ENABLED(CONFIG_GENEVE)
+#if IS_ENABLED(CONFIG_BNX2X_GENEVE)
 	if (IS_PF(bp))
 		geneve_get_rx_port(dev);
 #endif
@@ -13078,7 +13078,7 @@ static const struct net_device_ops bnx2x_netdev_ops = {
 	.ndo_add_vxlan_port	= bnx2x_add_vxlan_port,
 	.ndo_del_vxlan_port	= bnx2x_del_vxlan_port,
 #endif
-#if IS_ENABLED(CONFIG_GENEVE)
+#if IS_ENABLED(CONFIG_BNX2X_GENEVE)
 	.ndo_add_geneve_port	= bnx2x_add_geneve_port,
 	.ndo_del_geneve_port	= bnx2x_del_geneve_port,
 #endif
-- 
2.7.0



From heiko at sntech.de  Tue Feb 23 02:40:05 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Tue, 23 Feb 2016 11:40:05 +0100
Subject: [PATCH] clk: rockchip: rk3368: fix section mismatches with new
 child-clocks
In-Reply-To: <1456214322-20161-1-git-send-email-zhangqing@rock-chips.com>
References: <1456214322-20161-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1544165.HkeRmE5WOy@phil>

Hi Elaine,

Am Dienstag, 23. Februar 2016, 15:58:42 schrieb Elaine Zhang:
> To model the muxes downstream of fractional dividers we introduced the
> child property, allowing to describe a direct child clock.
> The first implementation seems to cause section warnings, as the core
> clock-tree is marked as initdata while the data pointed to from the
> child element is not.
> 
> While there may be some way to also set that missing property in the
> inline notation I didn't find it, so to actually fix the issue for now
> move the sub-definitions into separate declarations that can have
> their own __initdata properties.

The change below is correct, but the patch message is wrong.

The core change is commit 667464208989 ("clk: rockchip: include downstream 
muxes into fractional dividers") with the second change being a fixup as the 
first introduced issues. So your commit message should orient itself on the 
other commit, like

------
clk: rockchip: include downstream muxes into fractional dividers on rk3368

During the initial conversion to the newly introduced combined fractional
dividers+muxes the rk3368 clocks were left out, so convert them now.
----

> 
> Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
> ---
>  drivers/clk/rockchip/clk-rk3368.c | 97
> ++++++++++++++++++++++++--------------- 1 file changed, 60 insertions(+),
> 37 deletions(-)
> 
> diff --git a/drivers/clk/rockchip/clk-rk3368.c
> b/drivers/clk/rockchip/clk-rk3368.c index c2b0421..a2bb122 100644
> --- a/drivers/clk/rockchip/clk-rk3368.c
> +++ b/drivers/clk/rockchip/clk-rk3368.c
> @@ -243,6 +243,34 @@ static struct rockchip_cpuclk_rate_table
> rk3368_cpuclkl_rates[] __initdata = { RK3368_CPUCLKL_RATE( 312000000, 1,
> 1, 1),
>  };
> 
> +static struct rockchip_clk_branch rk3368_i2s_8ch_fracmux __initdata =
> +	MUX(0, "i2s_8ch_pre", mux_i2s_8ch_pre_p, CLK_SET_RATE_PARENT,
> +	    RK3368_CLKSEL_CON(27), 8, 2, MFLAGS);
> +
> +static struct rockchip_clk_branch rk3368_spdif_8ch_fracmux __initdata =
> +	MUX(0, "spdif_8ch_pre", mux_spdif_8ch_p, CLK_SET_RATE_PARENT,
> +	    RK3368_CLKSEL_CON(31), 8, 2, MFLAGS);
> +
> +static struct rockchip_clk_branch rk3368_i2s_2ch_fracmux __initdata =
> +	MUX(0, "i2s_2ch_pre", mux_i2s_2ch_p, CLK_SET_RATE_PARENT,
> +	    RK3368_CLKSEL_CON(53), 8, 2, MFLAGS);
> +
> +static struct rockchip_clk_branch rk3368_uart0_fracmux __initdata =
> +	MUX(SCLK_UART0, "sclk_uart0", mux_uart0_p, CLK_SET_RATE_PARENT,
> +	    RK3368_CLKSEL_CON(33), 8, 2, MFLAGS);
> +
> +static struct rockchip_clk_branch rk3368_uart1_fracmux __initdata =
> +	MUX(SCLK_UART1, "sclk_uart1", mux_uart1_p, CLK_SET_RATE_PARENT,
> +	    RK3368_CLKSEL_CON(35), 8, 2, MFLAGS);
> +
> +static struct rockchip_clk_branch rk3368_uart3_fracmux __initdata =
> +	MUX(SCLK_UART3, "sclk_uart3", mux_uart3_p, CLK_SET_RATE_PARENT,
> +	    RK3368_CLKSEL_CON(39), 8, 2, MFLAGS);
> +
> +static struct rockchip_clk_branch rk3368_uart4_fracmux __initdata =
> +	MUX(SCLK_UART4, "sclk_uart4", mux_uart4_p, CLK_SET_RATE_PARENT,
> +	    RK3368_CLKSEL_CON(41), 8, 2, MFLAGS);
> +
>  static struct rockchip_clk_branch rk3368_clk_branches[] __initdata = {
>  	/*
>  	 * Clock-Architecture Diagram 2
> @@ -339,11 +367,10 @@ static struct rockchip_clk_branch
> rk3368_clk_branches[] __initdata = { COMPOSITE(0, "i2s_8ch_src",
> mux_pll_src_cpll_gpll_p, 0,
>  			RK3368_CLKSEL_CON(27), 12, 1, MFLAGS, 0, 7, DFLAGS,
>  			RK3368_CLKGATE_CON(6), 1, GFLAGS),
> -	COMPOSITE_FRAC(0, "i2s_8ch_frac", "i2s_8ch_src", CLK_SET_RATE_PARENT,
> -			RK3368_CLKSEL_CON(28), 0,
> -			RK3368_CLKGATE_CON(6), 2, GFLAGS),
> -	MUX(0, "i2s_8ch_pre", mux_i2s_8ch_pre_p, CLK_SET_RATE_PARENT,
> -			RK3368_CLKSEL_CON(27), 8, 2, MFLAGS),
> +	COMPOSITE_FRACMUX(0, "i2s_8ch_frac", "i2s_8ch_src", CLK_SET_RATE_PARENT,
> +			  RK3368_CLKSEL_CON(28), 0,
> +			  RK3368_CLKGATE_CON(6), 2, GFLAGS,
> +			  &rk3368_i2s_8ch_fracmux),
>  	COMPOSITE_NODIV(SCLK_I2S_8CH_OUT, "i2s_8ch_clkout",
> mux_i2s_8ch_clkout_p, 0, RK3368_CLKSEL_CON(27), 15, 1, MFLAGS,
>  			RK3368_CLKGATE_CON(6), 0, GFLAGS),
> @@ -352,21 +379,21 @@ static struct rockchip_clk_branch
> rk3368_clk_branches[] __initdata = { COMPOSITE(0, "spdif_8ch_src",
> mux_pll_src_cpll_gpll_p, 0,
>  			RK3368_CLKSEL_CON(31), 12, 1, MFLAGS, 0, 7, DFLAGS,
>  			RK3368_CLKGATE_CON(6), 4, GFLAGS),
> -	COMPOSITE_FRAC(0, "spdif_8ch_frac", "spdif_8ch_src",
> CLK_SET_RATE_PARENT, -			RK3368_CLKSEL_CON(32), 0,
> -			RK3368_CLKGATE_CON(6), 5, GFLAGS),
> -	COMPOSITE_NODIV(SCLK_SPDIF_8CH, "sclk_spdif_8ch", mux_spdif_8ch_p,
> CLK_SET_RATE_PARENT, -			RK3368_CLKSEL_CON(31), 8, 2, MFLAGS,
> -			RK3368_CLKGATE_CON(6), 6, GFLAGS),
> +	COMPOSITE_FRACMUX(0, "spdif_8ch_frac", "spdif_8ch_src",
> CLK_SET_RATE_PARENT, +			  RK3368_CLKSEL_CON(32), 0,
> +			  RK3368_CLKGATE_CON(6), 5, GFLAGS,
> +			  &rk3368_spdif_8ch_fracmux),
> +	GATE(SCLK_SPDIF_8CH, "sclk_spdif_8ch", "spdif_8ch_pre",
> CLK_SET_RATE_PARENT, +	     RK3368_CLKGATE_CON(6), 6, GFLAGS),
>  	COMPOSITE(0, "i2s_2ch_src", mux_pll_src_cpll_gpll_p, 0,
>  			RK3368_CLKSEL_CON(53), 12, 1, MFLAGS, 0, 7, DFLAGS,
>  			RK3368_CLKGATE_CON(5), 13, GFLAGS),
> -	COMPOSITE_FRAC(0, "i2s_2ch_frac", "i2s_2ch_src", CLK_SET_RATE_PARENT,
> -			RK3368_CLKSEL_CON(54), 0,
> -			RK3368_CLKGATE_CON(5), 14, GFLAGS),
> -	COMPOSITE_NODIV(SCLK_I2S_2CH, "sclk_i2s_2ch", mux_i2s_2ch_p,
> CLK_SET_RATE_PARENT, -			RK3368_CLKSEL_CON(53), 8, 2, MFLAGS,
> -			RK3368_CLKGATE_CON(5), 15, GFLAGS),
> +	COMPOSITE_FRACMUX(0, "i2s_2ch_frac", "i2s_2ch_src", CLK_SET_RATE_PARENT,
> +			  RK3368_CLKSEL_CON(54), 0,
> +			  RK3368_CLKGATE_CON(5), 14, GFLAGS,
> +			  &rk3368_i2s_2ch_fracmux),
> +	GATE(SCLK_I2S_2CH, "sclk_i2s_2ch", "i2s_2ch_pre", CLK_SET_RATE_PARENT,
> +	     RK3368_CLKGATE_CON(5), 15, GFLAGS),
> 
>  	COMPOSITE(0, "sclk_tsp", mux_pll_src_cpll_gpll_npll_p, 0,
>  			RK3368_CLKSEL_CON(46), 6, 2, MFLAGS, 0, 5, DFLAGS,
> @@ -562,38 +589,34 @@ static struct rockchip_clk_branch
> rk3368_clk_branches[] __initdata = { COMPOSITE(0, "uart0_src",
> mux_pll_src_cpll_gpll_usb_usb_p, 0,
>  			RK3368_CLKSEL_CON(33), 12, 2, MFLAGS, 0, 7, DFLAGS,
>  			RK3368_CLKGATE_CON(2), 0, GFLAGS),
> -	COMPOSITE_FRAC(0, "uart0_frac", "uart0_src", CLK_SET_RATE_PARENT,
> -			RK3368_CLKSEL_CON(34), 0,
> -			RK3368_CLKGATE_CON(2), 1, GFLAGS),
> -	MUX(SCLK_UART0, "sclk_uart0", mux_uart0_p, CLK_SET_RATE_PARENT,
> -			RK3368_CLKSEL_CON(33), 8, 2, MFLAGS),
> +	COMPOSITE_FRACMUX(0, "uart0_frac", "uart0_src", CLK_SET_RATE_PARENT,
> +			  RK3368_CLKSEL_CON(34), 0,
> +			  RK3368_CLKGATE_CON(2), 1, GFLAGS,
> +			  &rk3368_uart0_fracmux),
> 
>  	COMPOSITE_NOMUX(0, "uart1_src", "uart_src", 0,
>  			RK3368_CLKSEL_CON(35), 0, 7, DFLAGS,
>  			RK3368_CLKGATE_CON(2), 2, GFLAGS),
> -	COMPOSITE_FRAC(0, "uart1_frac", "uart1_src", CLK_SET_RATE_PARENT,
> -			RK3368_CLKSEL_CON(36), 0,
> -			RK3368_CLKGATE_CON(2), 3, GFLAGS),
> -	MUX(SCLK_UART1, "sclk_uart1", mux_uart1_p, CLK_SET_RATE_PARENT,
> -			RK3368_CLKSEL_CON(35), 8, 2, MFLAGS),
> +	COMPOSITE_FRACMUX(0, "uart1_frac", "uart1_src", CLK_SET_RATE_PARENT,
> +			  RK3368_CLKSEL_CON(36), 0,
> +			  RK3368_CLKGATE_CON(2), 3, GFLAGS,
> +			  &rk3368_uart1_fracmux),
> 
>  	COMPOSITE_NOMUX(0, "uart3_src", "uart_src", 0,
>  			RK3368_CLKSEL_CON(39), 0, 7, DFLAGS,
>  			RK3368_CLKGATE_CON(2), 6, GFLAGS),
> -	COMPOSITE_FRAC(0, "uart3_frac", "uart3_src", CLK_SET_RATE_PARENT,
> -			RK3368_CLKSEL_CON(40), 0,
> -			RK3368_CLKGATE_CON(2), 7, GFLAGS),
> -	MUX(SCLK_UART3, "sclk_uart3", mux_uart3_p, CLK_SET_RATE_PARENT,
> -			RK3368_CLKSEL_CON(39), 8, 2, MFLAGS),
> +	COMPOSITE_FRACMUX(0, "uart3_frac", "uart3_src", CLK_SET_RATE_PARENT,
> +			  RK3368_CLKSEL_CON(40), 0,
> +			  RK3368_CLKGATE_CON(2), 7, GFLAGS,
> +			  &rk3368_uart3_fracmux),
> 
>  	COMPOSITE_NOMUX(0, "uart4_src", "uart_src", 0,
>  			RK3368_CLKSEL_CON(41), 0, 7, DFLAGS,
>  			RK3368_CLKGATE_CON(2), 8, GFLAGS),
> -	COMPOSITE_FRAC(0, "uart4_frac", "uart4_src", CLK_SET_RATE_PARENT,
> -			RK3368_CLKSEL_CON(42), 0,
> -			RK3368_CLKGATE_CON(2), 9, GFLAGS),
> -	MUX(SCLK_UART4, "sclk_uart4", mux_uart4_p, CLK_SET_RATE_PARENT,
> -			RK3368_CLKSEL_CON(41), 8, 2, MFLAGS),
> +	COMPOSITE_FRACMUX(0, "uart4_frac", "uart4_src", CLK_SET_RATE_PARENT,
> +			  RK3368_CLKSEL_CON(42), 0,
> +			  RK3368_CLKGATE_CON(2), 9, GFLAGS,
> +			  &rk3368_uart4_fracmux),
> 
>  	COMPOSITE(0, "mac_pll_src", mux_pll_src_npll_cpll_gpll_p, 0,
>  			RK3368_CLKSEL_CON(43), 6, 2, MFLAGS, 0, 5, DFLAGS,



From nicolas.ferre at atmel.com  Tue Feb 23 02:49:31 2016
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 23 Feb 2016 11:49:31 +0100
Subject: [PATCH v3] mtd: atmel_nand: move the hsmc_clk from nfc node to
 nand node
In-Reply-To: <1456207220-7757-1-git-send-email-wenyou.yang@atmel.com>
References: <1456207220-7757-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <56CC393B.6090801@atmel.com>

Le 23/02/2016 07:00, Wenyou Yang a ?crit :
> From: Josh Wu <josh.wu at atmel.com>
> 
> For SAMA5D3, SAMA5D4 SoC family, PMECC becomes a part of HSMC, they
> need the HSMC clock enabled to work.
> The NFC is a sub feature for current nand driver, it can be disabled.
> But if HSMC clock is controlled by NFC, so disable NFC will also disable
> the HSMC clock. then, it will make the PMECC fail to work.
> 
> So the solution is move the HSMC clock out of NFC to nand node. When
> nand driver probed, it will check whether the chip has HSMC, if yes then
> it will require a HSMC clock.
> 
> Add a new "atmel,sama5d3-nand" compatiable string for SAMA5D3's nand.
> 
> Signed-off-by: Josh Wu <josh.wu at atmel.com>
> Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> ---
> 
> Changes in v3:
>  - add "atmel,sama5d3-nand" compatiable string for SAMA5D3's nand.
>  - revert the mail address of Josh's Signed-off to the original.

It seems okay now:
Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

Brian, can we take this patch (if you acknowledged it) with us (through
the arm-soc tree) to keep the synchronization with the DT part of this work?
I will also consider squashing the DT part in this one as well as they
cannot be separated.

Bye,

> Changes in v2:
>  - add missing .has_hsmc_clk assignment for sama5d2_caps.
> 
>  .../devicetree/bindings/mtd/atmel-nand.txt         |    4 +-
>  drivers/mtd/nand/atmel_nand.c                      |   51 +++++++++++---------
>  2 files changed, 30 insertions(+), 25 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> index d53aba9..29bee7c 100644
> --- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> @@ -15,6 +15,7 @@ Required properties:
>  - atmel,nand-cmd-offset : offset for the command latch.
>  - #address-cells, #size-cells : Must be present if the device has sub-nodes
>    representing partitions.
> +- clocks: phandle to the peripheral clock
>  
>  - gpios : specifies the gpio pins to control the NAND device. detect is an
>    optional gpio and may be set to 0 if not present.
> @@ -43,7 +44,6 @@ Required properties:
>  - reg : should specify the address and size used for NFC command registers,
>          NFC registers and NFC SRAM. NFC SRAM address and size can be absent
>          if don't want to use it.
> -- clocks: phandle to the peripheral clock
>  Optional properties:
>  - atmel,write-by-sram: boolean to enable NFC write by SRAM.
>  
> @@ -100,13 +100,13 @@ nand0: nand at 40000000 {
>  	compatible = "atmel,at91rm9200-nand";
>  	#address-cells = <1>;
>  	#size-cells = <1>;
> +	clocks = <&hsmc_clk>
>  	ranges;
>          ...
>          nfc at 70000000 {
>  		compatible = "atmel,sama5d3-nfc";
>  		#address-cells = <1>;
>  		#size-cells = <1>;
> -		clocks = <&hsmc_clk>
>  		reg = <
>  			0x70000000 0x10000000	/* NFC Command Registers */
>  			0xffffc000 0x00000070	/* NFC HSMC regs */
> diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
> index 20cbaab..482251c 100644
> --- a/drivers/mtd/nand/atmel_nand.c
> +++ b/drivers/mtd/nand/atmel_nand.c
> @@ -66,6 +66,7 @@ module_param(on_flash_bbt, int, 0);
>  struct atmel_nand_caps {
>  	bool pmecc_correct_erase_page;
>  	uint8_t pmecc_max_correction;
> +	bool has_hsmc_clk;
>  };
>  
>  struct atmel_nand_nfc_caps {
> @@ -106,8 +107,6 @@ struct atmel_nfc {
>  	bool			use_nfc_sram;
>  	bool			write_by_sram;
>  
> -	struct clk		*clk;
> -
>  	bool			is_initialized;
>  	struct completion	comp_ready;
>  	struct completion	comp_cmd_done;
> @@ -132,6 +131,7 @@ struct atmel_nand_host {
>  	struct dma_chan		*dma_chan;
>  
>  	struct atmel_nfc	*nfc;
> +	struct clk		*clk;
>  
>  	const struct atmel_nand_caps	*caps;
>  	bool			has_pmecc;
> @@ -2157,6 +2157,19 @@ static int atmel_nand_probe(struct platform_device *pdev)
>  	nand_chip->IO_ADDR_R = host->io_base;
>  	nand_chip->IO_ADDR_W = host->io_base;
>  
> +	if (host->caps->has_hsmc_clk) {
> +		host->clk = devm_clk_get(&pdev->dev, NULL);
> +		if (IS_ERR(host->clk)) {
> +			dev_err(&pdev->dev, "HSMC clock is missing, update your Device Tree");
> +			res = PTR_ERR(host->clk);
> +			goto err_nand_ioremap;
> +		}
> +
> +		res = clk_prepare_enable(host->clk);
> +		if (res)
> +			goto err_nand_ioremap;
> +	}
> +
>  	if (nand_nfc.is_initialized) {
>  		/* NFC driver is probed and initialized */
>  		host->nfc = &nand_nfc;
> @@ -2321,6 +2334,9 @@ static int atmel_nand_remove(struct platform_device *pdev)
>  	if (host->dma_chan)
>  		dma_release_channel(host->dma_chan);
>  
> +	if (!IS_ERR(host->clk))
> +		clk_disable_unprepare(host->clk);
> +
>  	platform_driver_unregister(&atmel_nand_nfc_driver);
>  
>  	return 0;
> @@ -2334,11 +2350,19 @@ static int atmel_nand_remove(struct platform_device *pdev)
>  static const struct atmel_nand_caps at91rm9200_caps = {
>  	.pmecc_correct_erase_page = false,
>  	.pmecc_max_correction = 24,
> +	.has_hsmc_clk = false,
> +};
> +
> +static struct atmel_nand_caps sama5d3_caps = {
> +	.pmecc_correct_erase_page = false,
> +	.pmecc_max_correction = 24,
> +	.has_hsmc_clk = true,
>  };
>  
>  static const struct atmel_nand_caps sama5d4_caps = {
>  	.pmecc_correct_erase_page = true,
>  	.pmecc_max_correction = 24,
> +	.has_hsmc_clk = true,
>  };
>  
>  /*
> @@ -2348,11 +2372,13 @@ static const struct atmel_nand_caps sama5d4_caps = {
>  static const struct atmel_nand_caps sama5d2_caps = {
>  	.pmecc_correct_erase_page = true,
>  	.pmecc_max_correction = 32,
> +	.has_hsmc_clk = true,
>  };
>  
>  static const struct of_device_id atmel_nand_dt_ids[] = {
>  	{ .compatible = "atmel,at91rm9200-nand", .data = &at91rm9200_caps },
>  	{ .compatible = "atmel,sama5d4-nand", .data = &sama5d4_caps },
> +	{ .compatible = "atmel,sama5d3-nand", .data = &sama5d3_caps },
>  	{ .compatible = "atmel,sama5d2-nand", .data = &sama5d2_caps },
>  	{ /* sentinel */ }
>  };
> @@ -2363,7 +2389,6 @@ static int atmel_nand_nfc_probe(struct platform_device *pdev)
>  {
>  	struct atmel_nfc *nfc = &nand_nfc;
>  	struct resource *nfc_cmd_regs, *nfc_hsmc_regs, *nfc_sram;
> -	int ret;
>  
>  	nfc_cmd_regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	nfc->base_cmd_regs = devm_ioremap_resource(&pdev->dev, nfc_cmd_regs);
> @@ -2401,31 +2426,12 @@ static int atmel_nand_nfc_probe(struct platform_device *pdev)
>  	nfc_writel(nfc->hsmc_regs, IDR, 0xffffffff);
>  	nfc_readl(nfc->hsmc_regs, SR);	/* clear the NFC_SR */
>  
> -	nfc->clk = devm_clk_get(&pdev->dev, NULL);
> -	if (!IS_ERR(nfc->clk)) {
> -		ret = clk_prepare_enable(nfc->clk);
> -		if (ret)
> -			return ret;
> -	} else {
> -		dev_warn(&pdev->dev, "NFC clock missing, update your Device Tree");
> -	}
> -
>  	nfc->is_initialized = true;
>  	dev_info(&pdev->dev, "NFC is probed.\n");
>  
>  	return 0;
>  }
>  
> -static int atmel_nand_nfc_remove(struct platform_device *pdev)
> -{
> -	struct atmel_nfc *nfc = &nand_nfc;
> -
> -	if (!IS_ERR(nfc->clk))
> -		clk_disable_unprepare(nfc->clk);
> -
> -	return 0;
> -}
> -
>  static const struct atmel_nand_nfc_caps sama5d3_nfc_caps = {
>  	.rb_mask = NFC_SR_RB_EDGE0,
>  };
> @@ -2447,7 +2453,6 @@ static struct platform_driver atmel_nand_nfc_driver = {
>  		.of_match_table = of_match_ptr(atmel_nand_nfc_match),
>  	},
>  	.probe = atmel_nand_nfc_probe,
> -	.remove = atmel_nand_nfc_remove,
>  };
>  
>  static struct platform_driver atmel_nand_driver = {
> 


-- 
Nicolas Ferre


From suzuki.poulose at arm.com  Tue Feb 23 02:49:42 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:49:42 +0000
Subject: [PATCH 00/13] arm-cci: PMU driver updates for 4.6
Message-ID: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>

Here are some fixes and updates for arm-cci pmu driver targeting v4.6,
applies on top of v4.5-rc5.

Highlights include :
 - Support for CoreLink CCI-550 PMU
 - Reliable writes to PMU Counter registers for CCI-500/550.

All the patches have been Acked. Please let me know how this
can be merged.

Andrzej Hajda (1):
  arm-cci: fix handling cpumask_any_but return value

Mark Rutland (1):
  arm-cci: simplify sysfs attr handling

Suzuki K Poulose (11):
  arm-cci: Group writes to counter
  arm-cci: Refactor CCI PMU enable/disable methods
  arm-cci: Delay PMU counter writes to pmu::pmu_enable
  arm-cci: write_counter: Remove redundant check
  arm-cci: Get the status of a counter
  arm-cci: Add routines to save/restore all counters
  arm-cci: Add helper to enable PMU without synchornising counters
  arm-cci: Provide hook for writing to PMU counters
  arm-cci: CCI-500: Work around PMU counter writes
  arm-cci500: Rearrange PMU driver for code sharing with CCI-550 PMU
  arm-cci: CoreLink CCI-550 PMU driver

 Documentation/devicetree/bindings/arm/cci.txt |    2 +
 drivers/bus/Kconfig                           |   10 +-
 drivers/bus/arm-cci.c                         |  612 +++++++++++++++++--------
 3 files changed, 427 insertions(+), 197 deletions(-)

-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:49:44 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:49:44 +0000
Subject: [PATCH 02/13] arm-cci: fix handling cpumask_any_but return value
In-Reply-To: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456224595-3282-3-git-send-email-suzuki.poulose@arm.com>

From: Andrzej Hajda <a.hajda at samsung.com>

cpumask_any_but returns value >= nr_cpu_ids if there are no more CPUs.

The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].

[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576

Signed-off-by: Andrzej Hajda <a.hajda at samsung.com>
Acked-by: Will Deacon <will.deacon at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/bus/arm-cci.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index ee47e6b..5fb1c06 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -1270,7 +1270,7 @@ static int cci_pmu_cpu_notifier(struct notifier_block *self,
 		if (!cpumask_test_and_clear_cpu(cpu, &cci_pmu->cpus))
 			break;
 		target = cpumask_any_but(cpu_online_mask, cpu);
-		if (target < 0) // UP, last CPU
+		if (target >= nr_cpu_ids) // UP, last CPU
 			break;
 		/*
 		 * TODO: migrate context once core races on event->ctx have
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:49:43 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:49:43 +0000
Subject: [PATCH 01/13] arm-cci: simplify sysfs attr handling
In-Reply-To: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456224595-3282-2-git-send-email-suzuki.poulose@arm.com>

From: Mark Rutland <mark.rutland at arm.com>

There's no need to dynamically initialise attribute pointers when we can
get the compiler to do it for us. We also don't need a dev_ext_attribute
for the cpumask, as the drvdata for a PMU device is a pointer to struct
pmu.

Cc: Punit Agrawal <punit.agrawal at arm.com>
Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Tested-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/bus/arm-cci.c |  100 +++++++++++++------------------------------------
 1 file changed, 25 insertions(+), 75 deletions(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 577cc4b..ee47e6b 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -121,10 +121,8 @@ struct cci_pmu_model {
 	u32 fixed_hw_cntrs;
 	u32 num_hw_cntrs;
 	u32 cntr_size;
-	u64 nformat_attrs;
-	u64 nevent_attrs;
-	struct dev_ext_attribute *format_attrs;
-	struct dev_ext_attribute *event_attrs;
+	struct attribute **format_attrs;
+	struct attribute **event_attrs;
 	struct event_range event_ranges[CCI_IF_MAX];
 	int (*validate_hw_event)(struct cci_pmu *, unsigned long);
 	int (*get_event_idx)(struct cci_pmu *, struct cci_pmu_hw_events *, unsigned long);
@@ -166,8 +164,10 @@ static ssize_t cci_pmu_format_show(struct device *dev,
 static ssize_t cci_pmu_event_show(struct device *dev,
 			struct device_attribute *attr, char *buf);
 
-#define CCI_EXT_ATTR_ENTRY(_name, _func, _config) \
-	{ __ATTR(_name, S_IRUGO, _func, NULL), (void *)_config }
+#define CCI_EXT_ATTR_ENTRY(_name, _func, _config) 				\
+	&((struct dev_ext_attribute[]) {					\
+		{ __ATTR(_name, S_IRUGO, _func, NULL), (void *)_config }	\
+	})[0].attr.attr
 
 #define CCI_FORMAT_EXT_ATTR_ENTRY(_name, _config) \
 	CCI_EXT_ATTR_ENTRY(_name, cci_pmu_format_show, (char *)_config)
@@ -242,12 +242,13 @@ enum cci400_perf_events {
 static ssize_t cci400_pmu_cycle_event_show(struct device *dev,
 			struct device_attribute *attr, char *buf);
 
-static struct dev_ext_attribute cci400_pmu_format_attrs[] = {
+static struct attribute *cci400_pmu_format_attrs[] = {
 	CCI_FORMAT_EXT_ATTR_ENTRY(event, "config:0-4"),
 	CCI_FORMAT_EXT_ATTR_ENTRY(source, "config:5-7"),
+	NULL
 };
 
-static struct dev_ext_attribute cci400_r0_pmu_event_attrs[] = {
+static struct attribute *cci400_r0_pmu_event_attrs[] = {
 	/* Slave events */
 	CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_hs_any, 0x0),
 	CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_hs_device, 0x01),
@@ -279,9 +280,10 @@ static struct dev_ext_attribute cci400_r0_pmu_event_attrs[] = {
 	CCI_EVENT_EXT_ATTR_ENTRY(mi_wrq_stall_tt_full, 0x1A),
 	/* Special event for cycles counter */
 	CCI400_CYCLE_EVENT_EXT_ATTR_ENTRY(cycles, 0xff),
+	NULL
 };
 
-static struct dev_ext_attribute cci400_r1_pmu_event_attrs[] = {
+static struct attribute *cci400_r1_pmu_event_attrs[] = {
 	/* Slave events */
 	CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_hs_any, 0x0),
 	CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_hs_device, 0x01),
@@ -325,6 +327,7 @@ static struct dev_ext_attribute cci400_r1_pmu_event_attrs[] = {
 	CCI_EVENT_EXT_ATTR_ENTRY(mi_wrq_unique_or_line_unique_addr_hazard, 0x11),
 	/* Special event for cycles counter */
 	CCI400_CYCLE_EVENT_EXT_ATTR_ENTRY(cycles, 0xff),
+	NULL
 };
 
 static ssize_t cci400_pmu_cycle_event_show(struct device *dev,
@@ -480,12 +483,13 @@ static inline struct cci_pmu_model *probe_cci_model(struct platform_device *pdev
 static ssize_t cci500_pmu_global_event_show(struct device *dev,
 				struct device_attribute *attr, char *buf);
 
-static struct dev_ext_attribute cci500_pmu_format_attrs[] = {
+static struct attribute *cci500_pmu_format_attrs[] = {
 	CCI_FORMAT_EXT_ATTR_ENTRY(event, "config:0-4"),
 	CCI_FORMAT_EXT_ATTR_ENTRY(source, "config:5-8"),
+	NULL,
 };
 
-static struct dev_ext_attribute cci500_pmu_event_attrs[] = {
+static struct attribute *cci500_pmu_event_attrs[] = {
 	/* Slave events */
 	CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_hs_arvalid, 0x0),
 	CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_dev, 0x1),
@@ -546,6 +550,7 @@ static struct dev_ext_attribute cci500_pmu_event_attrs[] = {
 	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_rq_stall_addr_hazard, 0xD),
 	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snopp_rq_stall_tt_full, 0xE),
 	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_rq_tzmp1_prot, 0xF),
+	NULL
 };
 
 static ssize_t cci500_pmu_global_event_show(struct device *dev,
@@ -1176,9 +1181,8 @@ static int cci_pmu_event_init(struct perf_event *event)
 static ssize_t pmu_cpumask_attr_show(struct device *dev,
 				     struct device_attribute *attr, char *buf)
 {
-	struct dev_ext_attribute *eattr = container_of(attr,
-					struct dev_ext_attribute, attr);
-	struct cci_pmu *cci_pmu = eattr->var;
+	struct pmu *pmu = dev_get_drvdata(dev);
+	struct cci_pmu *cci_pmu = to_cci_pmu(pmu);
 
 	int n = scnprintf(buf, PAGE_SIZE - 1, "%*pbl",
 			  cpumask_pr_args(&cci_pmu->cpus));
@@ -1187,13 +1191,11 @@ static ssize_t pmu_cpumask_attr_show(struct device *dev,
 	return n;
 }
 
-static struct dev_ext_attribute pmu_cpumask_attr = {
-	__ATTR(cpumask, S_IRUGO, pmu_cpumask_attr_show, NULL),
-	NULL,		/* Populated in cci_pmu_init */
-};
+static struct device_attribute pmu_cpumask_attr =
+	__ATTR(cpumask, S_IRUGO, pmu_cpumask_attr_show, NULL);
 
 static struct attribute *pmu_attrs[] = {
-	&pmu_cpumask_attr.attr.attr,
+	&pmu_cpumask_attr.attr,
 	NULL,
 };
 
@@ -1218,60 +1220,14 @@ static const struct attribute_group *pmu_attr_groups[] = {
 	NULL
 };
 
-static struct attribute **alloc_attrs(struct platform_device *pdev,
-				int n, struct dev_ext_attribute *source)
-{
-	int i;
-	struct attribute **attrs;
-
-	/* Alloc n + 1 (for terminating NULL) */
-	attrs  = devm_kcalloc(&pdev->dev, n + 1, sizeof(struct attribute *),
-								GFP_KERNEL);
-	if (!attrs)
-		return attrs;
-	for(i = 0; i < n; i++)
-		attrs[i] = &source[i].attr.attr;
-	return attrs;
-}
-
-static int cci_pmu_init_attrs(struct cci_pmu *cci_pmu, struct platform_device *pdev)
-{
-	const struct cci_pmu_model *model = cci_pmu->model;
-	struct attribute **attrs;
-
-	/*
-	 * All allocations below are managed, hence doesn't need to be
-	 * free'd explicitly in case of an error.
-	 */
-
-	if (model->nevent_attrs) {
-		attrs = alloc_attrs(pdev, model->nevent_attrs,
-						model->event_attrs);
-		if (!attrs)
-			return -ENOMEM;
-		pmu_event_attr_group.attrs = attrs;
-	}
-	if (model->nformat_attrs) {
-		attrs = alloc_attrs(pdev, model->nformat_attrs,
-						 model->format_attrs);
-		if (!attrs)
-			return -ENOMEM;
-		pmu_format_attr_group.attrs = attrs;
-	}
-	pmu_cpumask_attr.var = cci_pmu;
-
-	return 0;
-}
-
 static int cci_pmu_init(struct cci_pmu *cci_pmu, struct platform_device *pdev)
 {
-	char *name = cci_pmu->model->name;
+	const struct cci_pmu_model *model = cci_pmu->model;
+	char *name = model->name;
 	u32 num_cntrs;
-	int rc;
 
-	rc = cci_pmu_init_attrs(cci_pmu, pdev);
-	if (rc)
-		return rc;
+	pmu_event_attr_group.attrs = model->event_attrs;
+	pmu_format_attr_group.attrs = model->format_attrs;
 
 	cci_pmu->pmu = (struct pmu) {
 		.name		= cci_pmu->model->name,
@@ -1336,9 +1292,7 @@ static struct cci_pmu_model cci_pmu_models[] = {
 		.num_hw_cntrs = 4,
 		.cntr_size = SZ_4K,
 		.format_attrs = cci400_pmu_format_attrs,
-		.nformat_attrs = ARRAY_SIZE(cci400_pmu_format_attrs),
 		.event_attrs = cci400_r0_pmu_event_attrs,
-		.nevent_attrs = ARRAY_SIZE(cci400_r0_pmu_event_attrs),
 		.event_ranges = {
 			[CCI_IF_SLAVE] = {
 				CCI400_R0_SLAVE_PORT_MIN_EV,
@@ -1358,9 +1312,7 @@ static struct cci_pmu_model cci_pmu_models[] = {
 		.num_hw_cntrs = 4,
 		.cntr_size = SZ_4K,
 		.format_attrs = cci400_pmu_format_attrs,
-		.nformat_attrs = ARRAY_SIZE(cci400_pmu_format_attrs),
 		.event_attrs = cci400_r1_pmu_event_attrs,
-		.nevent_attrs = ARRAY_SIZE(cci400_r1_pmu_event_attrs),
 		.event_ranges = {
 			[CCI_IF_SLAVE] = {
 				CCI400_R1_SLAVE_PORT_MIN_EV,
@@ -1382,9 +1334,7 @@ static struct cci_pmu_model cci_pmu_models[] = {
 		.num_hw_cntrs = 8,
 		.cntr_size = SZ_64K,
 		.format_attrs = cci500_pmu_format_attrs,
-		.nformat_attrs = ARRAY_SIZE(cci500_pmu_format_attrs),
 		.event_attrs = cci500_pmu_event_attrs,
-		.nevent_attrs = ARRAY_SIZE(cci500_pmu_event_attrs),
 		.event_ranges = {
 			[CCI_IF_SLAVE] = {
 				CCI500_SLAVE_PORT_MIN_EV,
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:49:52 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:49:52 +0000
Subject: [PATCH 10/13] arm-cci: Provide hook for writing to PMU counters
In-Reply-To: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456224595-3282-11-git-send-email-suzuki.poulose@arm.com>

Add a hook for writing to CCI PMU counters. This callback
can be used for CCI models which requires some extra work
to program the PMU counter values. To accommodate group writes
and single counter writes, the call back accepts a bitmask
of the counter indices which need to be programmed with the
given value.

Cc: Punit Agrawal <punit.agrawal at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/bus/arm-cci.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index bcc4c59..f1d3f47 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -126,6 +126,7 @@ struct cci_pmu_model {
 	struct event_range event_ranges[CCI_IF_MAX];
 	int (*validate_hw_event)(struct cci_pmu *, unsigned long);
 	int (*get_event_idx)(struct cci_pmu *, struct cci_pmu_hw_events *, unsigned long);
+	void (*write_counters)(struct cci_pmu *, unsigned long *);
 };
 
 static struct cci_pmu_model cci_pmu_models[];
@@ -868,7 +869,7 @@ static void pmu_write_counter(struct cci_pmu *cci_pmu, u32 value, int idx)
 	pmu_write_register(cci_pmu, value, idx, CCI_PMU_CNTR);
 }
 
-static void pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
+static void __pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
 {
 	int i;
 	struct cci_pmu_hw_events *cci_hw = &cci_pmu->hw_events;
@@ -882,6 +883,14 @@ static void pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
 	}
 }
 
+static void pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
+{
+	if (cci_pmu->model->write_counters)
+		cci_pmu->model->write_counters(cci_pmu, mask);
+	else
+		__pmu_write_counters(cci_pmu, mask);
+}
+
 static u64 pmu_event_update(struct perf_event *event)
 {
 	struct hw_perf_event *hwc = &event->hw;
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:49:51 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:49:51 +0000
Subject: [PATCH 09/13] arm-cci: Add helper to enable PMU without synchornising
 counters
In-Reply-To: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456224595-3282-10-git-send-email-suzuki.poulose@arm.com>

On CCI-500 writing to a counter requires turning the PMU on. So,
synchronising the counter state should not be performed for such special cases,
while turning the PMU on. This patch adds a helper, __cci_pmu_enable_nosync(),
without flushing the counter states.

Cc: Punit Agrawal <punit.agrawal at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/bus/arm-cci.c |   15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 7ce7da0..bcc4c59 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -640,18 +640,23 @@ void cci_pmu_sync_counters(struct cci_pmu *cci_pmu)
 }
 
 /* Should be called with cci_pmu->hw_events->pmu_lock held */
-static void __cci_pmu_enable(struct cci_pmu *cci_pmu)
+static void __cci_pmu_enable_nosync(struct cci_pmu *cci_pmu)
 {
 	u32 val;
 
-	cci_pmu_sync_counters(cci_pmu);
-
 	/* Enable all the PMU counters. */
 	val = readl_relaxed(cci_ctrl_base + CCI_PMCR) | CCI_PMCR_CEN;
 	writel(val, cci_ctrl_base + CCI_PMCR);
 }
 
 /* Should be called with cci_pmu->hw_events->pmu_lock held */
+static void __cci_pmu_enable_sync(struct cci_pmu *cci_pmu)
+{
+	cci_pmu_sync_counters(cci_pmu);
+	__cci_pmu_enable_nosync(cci_pmu);
+}
+
+/* Should be called with cci_pmu->hw_events->pmu_lock held */
 static void __cci_pmu_disable(void)
 {
 	u32 val;
@@ -960,7 +965,7 @@ static irqreturn_t pmu_handle_irq(int irq_num, void *dev)
 	}
 
 	/* Enable the PMU and sync possibly overflowed counters */
-	__cci_pmu_enable(cci_pmu);
+	__cci_pmu_enable_sync(cci_pmu);
 	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
 
 	return IRQ_RETVAL(handled);
@@ -1004,7 +1009,7 @@ static void cci_pmu_enable(struct pmu *pmu)
 		return;
 
 	raw_spin_lock_irqsave(&hw_events->pmu_lock, flags);
-	__cci_pmu_enable(cci_pmu);
+	__cci_pmu_enable_sync(cci_pmu);
 	raw_spin_unlock_irqrestore(&hw_events->pmu_lock, flags);
 
 }
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:49:48 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:49:48 +0000
Subject: [PATCH 06/13] arm-cci: write_counter: Remove redundant check
In-Reply-To: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456224595-3282-7-git-send-email-suzuki.poulose@arm.com>

pmu_write_counter() is now only called from pmu_write_counters(),
which does so for each set index in the given mask, bounded by
cci_pmu->num_cntrs. So, there is no need for an extra check to
make sure the given counter is valid inside pmu_write_counter.
This patch gets rid of that.

Cc: Punit Agrawal <punit.agrawal at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/bus/arm-cci.c |   13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 629c9e0..420c30c 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -814,16 +814,9 @@ static u32 pmu_read_counter(struct perf_event *event)
 	return value;
 }
 
-static void pmu_write_counter(struct perf_event *event, u32 value)
+static void pmu_write_counter(struct cci_pmu *cci_pmu, u32 value, int idx)
 {
-	struct cci_pmu *cci_pmu = to_cci_pmu(event->pmu);
-	struct hw_perf_event *hw_counter = &event->hw;
-	int idx = hw_counter->idx;
-
-	if (unlikely(!pmu_is_valid_counter(cci_pmu, idx)))
-		dev_err(&cci_pmu->plat_device->dev, "Invalid CCI PMU counter %d\n", idx);
-	else
-		pmu_write_register(cci_pmu, value, idx, CCI_PMU_CNTR);
+	pmu_write_register(cci_pmu, value, idx, CCI_PMU_CNTR);
 }
 
 static void pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
@@ -836,7 +829,7 @@ static void pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
 
 		if (WARN_ON(!event))
 			continue;
-		pmu_write_counter(event, local64_read(&event->hw.prev_count));
+		pmu_write_counter(cci_pmu, local64_read(&event->hw.prev_count), i);
 	}
 }
 
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:49:47 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:49:47 +0000
Subject: [PATCH 05/13] arm-cci: Delay PMU counter writes to pmu::pmu_enable
In-Reply-To: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456224595-3282-6-git-send-email-suzuki.poulose@arm.com>

CCI PMU driver always reprograms the counters to a safe value (half of the
counter max, = 2^31) before starting the profiling to account for extreme
interrupt latencies. Also, the cost of writing to a PMU counter could be
very costly on some PMUs(e.g, CCI-500). In order to ammortise the cost of
programming the counters, this patch delays the counter writes to pmu::pmu_enable().
We use the PER_HES_ARCH flag to keep track of the counters which need to
be programmed. Before turning on the PMU, we go through the counters that
were marked for write, and perform the operation in a batch.

To unify all the counter writes to pmu_enable(), this patch also makes sure that
we disable-and-enable the PMU in the irq handler to program any counters that
overflowed.

Cc: Punit Agrawal <punit.agrawal at arm.com>
Cc: Peter Zijlstra <peterz at infradead.org>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/bus/arm-cci.c |   57 ++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 52 insertions(+), 5 deletions(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index e42842b..629c9e0 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -159,6 +159,8 @@ enum cci_models {
 	CCI_MODEL_MAX
 };
 
+static void pmu_write_counters(struct cci_pmu *cci_pmu,
+				 unsigned long *mask);
 static ssize_t cci_pmu_format_show(struct device *dev,
 			struct device_attribute *attr, char *buf);
 static ssize_t cci_pmu_event_show(struct device *dev,
@@ -606,11 +608,44 @@ static int cci500_validate_hw_event(struct cci_pmu *cci_pmu,
 }
 #endif	/* CONFIG_ARM_CCI500_PMU */
 
+/*
+ * Program the CCI PMU counters which have PERF_HES_ARCH set
+ * with the event period and mark them ready before we enable
+ * PMU.
+ */
+void cci_pmu_sync_counters(struct cci_pmu *cci_pmu)
+{
+	int i;
+	struct cci_pmu_hw_events *cci_hw = &cci_pmu->hw_events;
+
+	DECLARE_BITMAP(mask, cci_pmu->num_cntrs);
+
+	bitmap_zero(mask, cci_pmu->num_cntrs);
+	for_each_set_bit(i, cci_pmu->hw_events.used_mask, cci_pmu->num_cntrs) {
+		struct perf_event *event = cci_hw->events[i];
+
+		if (WARN_ON(!event))
+			continue;
+
+		/* Leave the events which are not counting */
+		if (event->hw.state & PERF_HES_STOPPED)
+			continue;
+		if (event->hw.state & PERF_HES_ARCH) {
+			set_bit(i, mask);
+			event->hw.state &= ~PERF_HES_ARCH;
+		}
+	}
+
+	pmu_write_counters(cci_pmu, mask);
+}
+
 /* Should be called with cci_pmu->hw_events->pmu_lock held */
-static void __cci_pmu_enable(void)
+static void __cci_pmu_enable(struct cci_pmu *cci_pmu)
 {
 	u32 val;
 
+	cci_pmu_sync_counters(cci_pmu);
+
 	/* Enable all the PMU counters. */
 	val = readl_relaxed(cci_ctrl_base + CCI_PMCR) | CCI_PMCR_CEN;
 	writel(val, cci_ctrl_base + CCI_PMCR);
@@ -791,8 +826,7 @@ static void pmu_write_counter(struct perf_event *event, u32 value)
 		pmu_write_register(cci_pmu, value, idx, CCI_PMU_CNTR);
 }
 
-static void __maybe_unused
-pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
+static void pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
 {
 	int i;
 	struct cci_pmu_hw_events *cci_hw = &cci_pmu->hw_events;
@@ -840,7 +874,14 @@ void pmu_event_set_period(struct perf_event *event)
 	 */
 	u64 val = 1ULL << 31;
 	local64_set(&hwc->prev_count, val);
-	pmu_write_counter(event, val);
+
+	/*
+	 * CCI PMU uses PERF_HES_ARCH to keep track of the counters, whose
+	 * values needs to be sync-ed with the s/w state before the PMU is
+	 * enabled.
+	 * Mark this counter for sync.
+	 */
+	hwc->state |= PERF_HES_ARCH;
 }
 
 static irqreturn_t pmu_handle_irq(int irq_num, void *dev)
@@ -851,6 +892,9 @@ static irqreturn_t pmu_handle_irq(int irq_num, void *dev)
 	int idx, handled = IRQ_NONE;
 
 	raw_spin_lock_irqsave(&events->pmu_lock, flags);
+
+	/* Disable the PMU while we walk through the counters */
+	__cci_pmu_disable();
 	/*
 	 * Iterate over counters and update the corresponding perf events.
 	 * This should work regardless of whether we have per-counter overflow
@@ -877,6 +921,9 @@ static irqreturn_t pmu_handle_irq(int irq_num, void *dev)
 		pmu_event_set_period(event);
 		handled = IRQ_HANDLED;
 	}
+
+	/* Enable the PMU and sync possibly overflowed counters */
+	__cci_pmu_enable(cci_pmu);
 	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
 
 	return IRQ_RETVAL(handled);
@@ -920,7 +967,7 @@ static void cci_pmu_enable(struct pmu *pmu)
 		return;
 
 	raw_spin_lock_irqsave(&hw_events->pmu_lock, flags);
-	__cci_pmu_enable();
+	__cci_pmu_enable(cci_pmu);
 	raw_spin_unlock_irqrestore(&hw_events->pmu_lock, flags);
 
 }
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:49:45 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:49:45 +0000
Subject: [PATCH 03/13] arm-cci: Group writes to counter
In-Reply-To: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456224595-3282-4-git-send-email-suzuki.poulose@arm.com>

Add a helper to group the writes to PMU counter, this will be
used to delay setting the event period to pmu::pmu_enable()

Cc: Punit Agrawal <punit.agrawal at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K. Poulose <suzuki.poulose at arm.com>
---
 drivers/bus/arm-cci.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 5fb1c06..6a76ac7 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -771,6 +771,21 @@ static void pmu_write_counter(struct perf_event *event, u32 value)
 		pmu_write_register(cci_pmu, value, idx, CCI_PMU_CNTR);
 }
 
+static void __maybe_unused
+pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
+{
+	int i;
+	struct cci_pmu_hw_events *cci_hw = &cci_pmu->hw_events;
+
+	for_each_set_bit(i, mask, cci_pmu->num_cntrs) {
+		struct perf_event *event = cci_hw->events[i];
+
+		if (WARN_ON(!event))
+			continue;
+		pmu_write_counter(event, local64_read(&event->hw.prev_count));
+	}
+}
+
 static u64 pmu_event_update(struct perf_event *event)
 {
 	struct hw_perf_event *hwc = &event->hw;
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:49:46 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:49:46 +0000
Subject: [PATCH 04/13] arm-cci: Refactor CCI PMU enable/disable methods
In-Reply-To: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456224595-3282-5-git-send-email-suzuki.poulose@arm.com>

This patch refactors the CCI PMU driver code a little bit to
make it easier share the code for enabling/disabling the CCI
PMU. This will be used by the hooks to work around the special cases
where writing to a counter is not always that easy(e.g, CCI-500)

No functional changes.

Cc: Punit Agrawal <punit.agrawal at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/bus/arm-cci.c |   32 ++++++++++++++++++++++----------
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 6a76ac7..e42842b 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -606,6 +606,26 @@ static int cci500_validate_hw_event(struct cci_pmu *cci_pmu,
 }
 #endif	/* CONFIG_ARM_CCI500_PMU */
 
+/* Should be called with cci_pmu->hw_events->pmu_lock held */
+static void __cci_pmu_enable(void)
+{
+	u32 val;
+
+	/* Enable all the PMU counters. */
+	val = readl_relaxed(cci_ctrl_base + CCI_PMCR) | CCI_PMCR_CEN;
+	writel(val, cci_ctrl_base + CCI_PMCR);
+}
+
+/* Should be called with cci_pmu->hw_events->pmu_lock held */
+static void __cci_pmu_disable(void)
+{
+	u32 val;
+
+	/* Disable all the PMU counters. */
+	val = readl_relaxed(cci_ctrl_base + CCI_PMCR) & ~CCI_PMCR_CEN;
+	writel(val, cci_ctrl_base + CCI_PMCR);
+}
+
 static ssize_t cci_pmu_format_show(struct device *dev,
 			struct device_attribute *attr, char *buf)
 {
@@ -895,16 +915,12 @@ static void cci_pmu_enable(struct pmu *pmu)
 	struct cci_pmu_hw_events *hw_events = &cci_pmu->hw_events;
 	int enabled = bitmap_weight(hw_events->used_mask, cci_pmu->num_cntrs);
 	unsigned long flags;
-	u32 val;
 
 	if (!enabled)
 		return;
 
 	raw_spin_lock_irqsave(&hw_events->pmu_lock, flags);
-
-	/* Enable all the PMU counters. */
-	val = readl_relaxed(cci_ctrl_base + CCI_PMCR) | CCI_PMCR_CEN;
-	writel(val, cci_ctrl_base + CCI_PMCR);
+	__cci_pmu_enable();
 	raw_spin_unlock_irqrestore(&hw_events->pmu_lock, flags);
 
 }
@@ -914,13 +930,9 @@ static void cci_pmu_disable(struct pmu *pmu)
 	struct cci_pmu *cci_pmu = to_cci_pmu(pmu);
 	struct cci_pmu_hw_events *hw_events = &cci_pmu->hw_events;
 	unsigned long flags;
-	u32 val;
 
 	raw_spin_lock_irqsave(&hw_events->pmu_lock, flags);
-
-	/* Disable all the PMU counters. */
-	val = readl_relaxed(cci_ctrl_base + CCI_PMCR) & ~CCI_PMCR_CEN;
-	writel(val, cci_ctrl_base + CCI_PMCR);
+	__cci_pmu_disable();
 	raw_spin_unlock_irqrestore(&hw_events->pmu_lock, flags);
 }
 
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:49:50 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:49:50 +0000
Subject: [PATCH 08/13] arm-cci: Add routines to save/restore all counters
In-Reply-To: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456224595-3282-9-git-send-email-suzuki.poulose@arm.com>

Adds helper routines to disable the counter controls for
all the counters on the CCI PMU and restore it back, by
preserving the original state in caller provided mask.

Cc: Punit Agrawal <punit.agrawal at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/bus/arm-cci.c |   38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index d289037..7ce7da0 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -719,6 +719,44 @@ static void pmu_set_event(struct cci_pmu *cci_pmu, int idx, unsigned long event)
 }
 
 /*
+ * For all counters on the CCI-PMU, disable any 'enabled' counters,
+ * saving the changed counters in the mask, so that we can restore
+ * it later using pmu_restore_counters. The mask is private to the
+ * caller. We cannot rely on the used_mask maintained by the CCI_PMU
+ * as it only tells us if the counter is assigned to perf_event or not.
+ * The state of the perf_event cannot be locked by the PMU layer, hence
+ * we check the individual counter status (which can be locked by
+ * cci_pm->hw_events->pmu_lock).
+ *
+ * @mask should be initialised to empty by the caller.
+ */
+static void __maybe_unused
+pmu_save_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
+{
+	int i;
+
+	for (i = 0; i < cci_pmu->num_cntrs; i++) {
+		if (pmu_counter_is_enabled(cci_pmu, i)) {
+			set_bit(i, mask);
+			pmu_disable_counter(cci_pmu, i);
+		}
+	}
+}
+
+/*
+ * Restore the status of the counters. Reversal of the pmu_save_counters().
+ * For each counter set in the mask, enable the counter back.
+ */
+static void __maybe_unused
+pmu_restore_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
+{
+	int i;
+
+	for_each_set_bit(i, mask, cci_pmu->num_cntrs)
+		pmu_enable_counter(cci_pmu, i);
+}
+
+/*
  * Returns the number of programmable counters actually implemented
  * by the cci
  */
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:49:49 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:49:49 +0000
Subject: [PATCH 07/13] arm-cci: Get the status of a counter
In-Reply-To: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456224595-3282-8-git-send-email-suzuki.poulose@arm.com>

Add helper routines to check if the counter is enabled or not.

Cc: Punit Agrawal <punit.agrawal at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/bus/arm-cci.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 420c30c..d289037 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -707,6 +707,12 @@ static void pmu_enable_counter(struct cci_pmu *cci_pmu, int idx)
 	pmu_write_register(cci_pmu, 1, idx, CCI_PMU_CNTR_CTRL);
 }
 
+static bool __maybe_unused
+pmu_counter_is_enabled(struct cci_pmu *cci_pmu, int idx)
+{
+	return (pmu_read_register(cci_pmu, idx, CCI_PMU_CNTR_CTRL) & 0x1) != 0;
+}
+
 static void pmu_set_event(struct cci_pmu *cci_pmu, int idx, unsigned long event)
 {
 	pmu_write_register(cci_pmu, event, idx, CCI_PMU_EVT_SEL);
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:49:53 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:49:53 +0000
Subject: [PATCH 11/13] arm-cci: CCI-500: Work around PMU counter writes
In-Reply-To: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456224595-3282-12-git-send-email-suzuki.poulose@arm.com>

The CCI PMU driver sets the event counter to the half of the maximum
value(2^31) it can count before we start the counters via
pmu_event_set_period(). This is done to give us the best chance to
handle the overflow interrupt, taking care of extreme interrupt latencies.

However, CCI-500 comes with advanced power saving schemes, which
disables the clock to the event counters unless the counters are enabled to
count (PMCR.CEN). This prevents the driver from writing the period to the
counters before starting them.  Also, there is no way we can reset the
individual event counter to 0 (PMCR.RST resets all the counters, losing
their current readings). However the value of the counter is preserved and
could be read back, when the counters are not enabled.

So we cannot reliably use the counters and compute the number of events
generated during the sampling period since we don't have the value of the
counter at start.

This patch works around this issue by changing writes to the counter
with the following steps.

 1) Disable all the counters (remembering any counters which were enabled)
 2) Enable the PMU, now that all the counters are disabled.

 For each counter to be programmed, repeat steps 3-7
 3) Save the current event and program the target counter to count an
    invalid event, which by spec is guaranteed to not-generate any events.
 4) Enable the target counter.
 5) Write to the target counter.
 6) Disable the target counter
 7) Restore the event back on the target counter.

 8) Disable the PMU
 9) Restore the status of the all the counters

Cc: Punit Agrawal <punit.agrawal at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/bus/arm-cci.c |   66 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index f1d3f47..ebb2f1e 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -891,6 +891,71 @@ static void pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
 		__pmu_write_counters(cci_pmu, mask);
 }
 
+#ifdef CONFIG_ARM_CCI500_PMU
+
+/*
+ * CCI-500 has advanced power saving policies, which could gate the
+ * clocks to the PMU counters, which makes the writes to them ineffective.
+ * The only way to write to those counters is when the global counters
+ * are enabled and the particular counter is enabled.
+ *
+ * So we do the following :
+ *
+ * 1) Disable all the PMU counters, saving their current state
+ * 2) Enable the global PMU profiling, now that all counters are
+ *    disabled.
+ *
+ * For each counter to be programmed, repeat steps 3-7:
+ *
+ * 3) Write an invalid event code to the event control register for the
+      counter, so that the counters are not modified.
+ * 4) Enable the counter control for the counter.
+ * 5) Set the counter value
+ * 6) Disable the counter
+ * 7) Restore the event in the target counter
+ *
+ * 8) Disable the global PMU.
+ * 9) Restore the status of the rest of the counters.
+ *
+ * We choose an event which for CCI-500 is guaranteed not to count.
+ * We use the highest possible event code (0x1f) for the master interface 0.
+ */
+#define CCI500_INVALID_EVENT	((CCI500_PORT_M0 << CCI500_PMU_EVENT_SOURCE_SHIFT) | \
+				 (CCI500_PMU_EVENT_CODE_MASK << CCI500_PMU_EVENT_CODE_SHIFT))
+static void cci500_pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
+{
+	int i;
+	DECLARE_BITMAP(saved_mask, cci_pmu->num_cntrs);
+
+	bitmap_zero(saved_mask, cci_pmu->num_cntrs);
+	pmu_save_counters(cci_pmu, saved_mask);
+
+	/*
+	 * Now that all the counters are disabled, we can safely turn the PMU on,
+	 * without syncing the status of the counters
+	 */
+	__cci_pmu_enable_nosync(cci_pmu);
+
+	for_each_set_bit(i, mask, cci_pmu->num_cntrs) {
+		struct perf_event *event = cci_pmu->hw_events.events[i];
+
+		if (WARN_ON(!event))
+			continue;
+
+		pmu_set_event(cci_pmu, i, CCI500_INVALID_EVENT);
+		pmu_enable_counter(cci_pmu, i);
+		pmu_write_counter(cci_pmu, local64_read(&event->hw.prev_count), i);
+		pmu_disable_counter(cci_pmu, i);
+		pmu_set_event(cci_pmu, i, event->hw.config_base);
+	}
+
+	__cci_pmu_disable();
+
+	pmu_restore_counters(cci_pmu, saved_mask);
+}
+
+#endif	/* CONFIG_ARM_CCI500_PMU */
+
 static u64 pmu_event_update(struct perf_event *event)
 {
 	struct hw_perf_event *hwc = &event->hw;
@@ -1475,6 +1540,7 @@ static struct cci_pmu_model cci_pmu_models[] = {
 			},
 		},
 		.validate_hw_event = cci500_validate_hw_event,
+		.write_counters	= cci500_pmu_write_counters,
 	},
 #endif
 };
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:49:54 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:49:54 +0000
Subject: [PATCH 12/13] arm-cci500: Rearrange PMU driver for code sharing with
 CCI-550 PMU
In-Reply-To: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456224595-3282-13-git-send-email-suzuki.poulose@arm.com>

CCI-550 PMU shares most of the CCI-500 PMU attributes including the
event format, PMU event codes. The only difference is an additional
master interface (MI6 - 0xe). Hence we share the driver code for both,
except for a model specific event validate method.
This patch renames the common CCI500 symbols to CCI5xx, including the
Kconfig symbol.

No functional changes to the PMU driver.

Acked-by: Punit Agrawal <punit.agrawal at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 drivers/bus/Kconfig   |    2 +-
 drivers/bus/arm-cci.c |  220 +++++++++++++++++++++++++------------------------
 2 files changed, 113 insertions(+), 109 deletions(-)

diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 9a92c07..e553834 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -34,7 +34,7 @@ config ARM_CCI400_PORT_CTRL
 	  Low level power management driver for CCI400 cache coherent
 	  interconnect for ARM platforms.
 
-config ARM_CCI500_PMU
+config ARM_CCI5xx_PMU
 	bool "ARM CCI500 PMU support"
 	depends on (ARM && CPU_V7) || ARM64
 	depends on PERF_EVENTS
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index ebb2f1e..683e289 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -52,7 +52,7 @@ static const struct of_device_id arm_cci_matches[] = {
 #ifdef CONFIG_ARM_CCI400_COMMON
 	{.compatible = "arm,cci-400", .data = CCI400_PORTS_DATA },
 #endif
-#ifdef CONFIG_ARM_CCI500_PMU
+#ifdef CONFIG_ARM_CCI5xx_PMU
 	{ .compatible = "arm,cci-500", },
 #endif
 	{},
@@ -92,7 +92,7 @@ static const struct of_device_id arm_cci_matches[] = {
 enum {
 	CCI_IF_SLAVE,
 	CCI_IF_MASTER,
-#ifdef CONFIG_ARM_CCI500_PMU
+#ifdef CONFIG_ARM_CCI5xx_PMU
 	CCI_IF_GLOBAL,
 #endif
 	CCI_IF_MAX,
@@ -154,7 +154,7 @@ enum cci_models {
 	CCI400_R0,
 	CCI400_R1,
 #endif
-#ifdef CONFIG_ARM_CCI500_PMU
+#ifdef CONFIG_ARM_CCI5xx_PMU
 	CCI500_R0,
 #endif
 	CCI_MODEL_MAX
@@ -426,73 +426,67 @@ static inline struct cci_pmu_model *probe_cci_model(struct platform_device *pdev
 }
 #endif	/* CONFIG_ARM_CCI400_PMU */
 
-#ifdef CONFIG_ARM_CCI500_PMU
+#ifdef CONFIG_ARM_CCI5xx_PMU
 
 /*
- * CCI500 provides 8 independent event counters that can count
- * any of the events available.
- *
- * CCI500 PMU event id is an 9-bit value made of two parts.
+ * CCI5xx PMU event id is an 9-bit value made of two parts.
  *	 bits [8:5] - Source for the event
- *		      0x0-0x6 - Slave interfaces
- *		      0x8-0xD - Master interfaces
- *		      0xf     - Global Events
- *		      0x7,0xe - Reserved
- *
  *	 bits [4:0] - Event code (specific to type of interface)
+ *
+ *
  */
 
 /* Port ids */
-#define CCI500_PORT_S0			0x0
-#define CCI500_PORT_S1			0x1
-#define CCI500_PORT_S2			0x2
-#define CCI500_PORT_S3			0x3
-#define CCI500_PORT_S4			0x4
-#define CCI500_PORT_S5			0x5
-#define CCI500_PORT_S6			0x6
-
-#define CCI500_PORT_M0			0x8
-#define CCI500_PORT_M1			0x9
-#define CCI500_PORT_M2			0xa
-#define CCI500_PORT_M3			0xb
-#define CCI500_PORT_M4			0xc
-#define CCI500_PORT_M5			0xd
-
-#define CCI500_PORT_GLOBAL 		0xf
-
-#define CCI500_PMU_EVENT_MASK		0x1ffUL
-#define CCI500_PMU_EVENT_SOURCE_SHIFT	0x5
-#define CCI500_PMU_EVENT_SOURCE_MASK	0xf
-#define CCI500_PMU_EVENT_CODE_SHIFT	0x0
-#define CCI500_PMU_EVENT_CODE_MASK	0x1f
-
-#define CCI500_PMU_EVENT_SOURCE(event)	\
-	((event >> CCI500_PMU_EVENT_SOURCE_SHIFT) & CCI500_PMU_EVENT_SOURCE_MASK)
-#define CCI500_PMU_EVENT_CODE(event)	\
-	((event >> CCI500_PMU_EVENT_CODE_SHIFT) & CCI500_PMU_EVENT_CODE_MASK)
-
-#define CCI500_SLAVE_PORT_MIN_EV	0x00
-#define CCI500_SLAVE_PORT_MAX_EV	0x1f
-#define CCI500_MASTER_PORT_MIN_EV	0x00
-#define CCI500_MASTER_PORT_MAX_EV	0x06
-#define CCI500_GLOBAL_PORT_MIN_EV	0x00
-#define CCI500_GLOBAL_PORT_MAX_EV	0x0f
-
-
-#define CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(_name, _config) \
-	CCI_EXT_ATTR_ENTRY(_name, cci500_pmu_global_event_show, \
+#define CCI5xx_PORT_S0			0x0
+#define CCI5xx_PORT_S1			0x1
+#define CCI5xx_PORT_S2			0x2
+#define CCI5xx_PORT_S3			0x3
+#define CCI5xx_PORT_S4			0x4
+#define CCI5xx_PORT_S5			0x5
+#define CCI5xx_PORT_S6			0x6
+
+#define CCI5xx_PORT_M0			0x8
+#define CCI5xx_PORT_M1			0x9
+#define CCI5xx_PORT_M2			0xa
+#define CCI5xx_PORT_M3			0xb
+#define CCI5xx_PORT_M4			0xc
+#define CCI5xx_PORT_M5			0xd
+
+#define CCI5xx_PORT_GLOBAL		0xf
+
+#define CCI5xx_PMU_EVENT_MASK		0x1ffUL
+#define CCI5xx_PMU_EVENT_SOURCE_SHIFT	0x5
+#define CCI5xx_PMU_EVENT_SOURCE_MASK	0xf
+#define CCI5xx_PMU_EVENT_CODE_SHIFT	0x0
+#define CCI5xx_PMU_EVENT_CODE_MASK	0x1f
+
+#define CCI5xx_PMU_EVENT_SOURCE(event)	\
+	((event >> CCI5xx_PMU_EVENT_SOURCE_SHIFT) & CCI5xx_PMU_EVENT_SOURCE_MASK)
+#define CCI5xx_PMU_EVENT_CODE(event)	\
+	((event >> CCI5xx_PMU_EVENT_CODE_SHIFT) & CCI5xx_PMU_EVENT_CODE_MASK)
+
+#define CCI5xx_SLAVE_PORT_MIN_EV	0x00
+#define CCI5xx_SLAVE_PORT_MAX_EV	0x1f
+#define CCI5xx_MASTER_PORT_MIN_EV	0x00
+#define CCI5xx_MASTER_PORT_MAX_EV	0x06
+#define CCI5xx_GLOBAL_PORT_MIN_EV	0x00
+#define CCI5xx_GLOBAL_PORT_MAX_EV	0x0f
+
+
+#define CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(_name, _config) \
+	CCI_EXT_ATTR_ENTRY(_name, cci5xx_pmu_global_event_show, \
 					(unsigned long) _config)
 
-static ssize_t cci500_pmu_global_event_show(struct device *dev,
+static ssize_t cci5xx_pmu_global_event_show(struct device *dev,
 				struct device_attribute *attr, char *buf);
 
-static struct attribute *cci500_pmu_format_attrs[] = {
+static struct attribute *cci5xx_pmu_format_attrs[] = {
 	CCI_FORMAT_EXT_ATTR_ENTRY(event, "config:0-4"),
 	CCI_FORMAT_EXT_ATTR_ENTRY(source, "config:5-8"),
 	NULL,
 };
 
-static struct attribute *cci500_pmu_event_attrs[] = {
+static struct attribute *cci5xx_pmu_event_attrs[] = {
 	/* Slave events */
 	CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_hs_arvalid, 0x0),
 	CCI_EVENT_EXT_ATTR_ENTRY(si_rrq_dev, 0x1),
@@ -537,64 +531,73 @@ static struct attribute *cci500_pmu_event_attrs[] = {
 	CCI_EVENT_EXT_ATTR_ENTRY(mi_w_resp_stall, 0x6),
 
 	/* Global events */
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_filter_bank_0_1, 0x0),
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_filter_bank_2_3, 0x1),
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_filter_bank_4_5, 0x2),
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_filter_bank_6_7, 0x3),
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_miss_filter_bank_0_1, 0x4),
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_miss_filter_bank_2_3, 0x5),
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_miss_filter_bank_4_5, 0x6),
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_miss_filter_bank_6_7, 0x7),
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_back_invalidation, 0x8),
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_stall_alloc_busy, 0x9),
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_stall_tt_full, 0xA),
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_wrq, 0xB),
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_cd_hs, 0xC),
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_rq_stall_addr_hazard, 0xD),
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snopp_rq_stall_tt_full, 0xE),
-	CCI500_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_rq_tzmp1_prot, 0xF),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_filter_bank_0_1, 0x0),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_filter_bank_2_3, 0x1),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_filter_bank_4_5, 0x2),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_filter_bank_6_7, 0x3),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_miss_filter_bank_0_1, 0x4),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_miss_filter_bank_2_3, 0x5),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_miss_filter_bank_4_5, 0x6),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_access_miss_filter_bank_6_7, 0x7),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_back_invalidation, 0x8),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_stall_alloc_busy, 0x9),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_stall_tt_full, 0xA),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_wrq, 0xB),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_cd_hs, 0xC),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_rq_stall_addr_hazard, 0xD),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snopp_rq_stall_tt_full, 0xE),
+	CCI5xx_GLOBAL_EVENT_EXT_ATTR_ENTRY(cci_snoop_rq_tzmp1_prot, 0xF),
 	NULL
 };
 
-static ssize_t cci500_pmu_global_event_show(struct device *dev,
+static ssize_t cci5xx_pmu_global_event_show(struct device *dev,
 				struct device_attribute *attr, char *buf)
 {
 	struct dev_ext_attribute *eattr = container_of(attr,
 					struct dev_ext_attribute, attr);
 	/* Global events have single fixed source code */
 	return snprintf(buf, PAGE_SIZE, "event=0x%lx,source=0x%x\n",
-				(unsigned long)eattr->var, CCI500_PORT_GLOBAL);
+				(unsigned long)eattr->var, CCI5xx_PORT_GLOBAL);
 }
 
+/*
+ * CCI500 provides 8 independent event counters that can count
+ * any of the events available.
+ * CCI500 PMU event source ids
+ *	0x0-0x6 - Slave interfaces
+ *	0x8-0xD - Master interfaces
+ *	0xf     - Global Events
+ *	0x7,0xe - Reserved
+ */
 static int cci500_validate_hw_event(struct cci_pmu *cci_pmu,
 					unsigned long hw_event)
 {
-	u32 ev_source = CCI500_PMU_EVENT_SOURCE(hw_event);
-	u32 ev_code = CCI500_PMU_EVENT_CODE(hw_event);
+	u32 ev_source = CCI5xx_PMU_EVENT_SOURCE(hw_event);
+	u32 ev_code = CCI5xx_PMU_EVENT_CODE(hw_event);
 	int if_type;
 
-	if (hw_event & ~CCI500_PMU_EVENT_MASK)
+	if (hw_event & ~CCI5xx_PMU_EVENT_MASK)
 		return -ENOENT;
 
 	switch (ev_source) {
-	case CCI500_PORT_S0:
-	case CCI500_PORT_S1:
-	case CCI500_PORT_S2:
-	case CCI500_PORT_S3:
-	case CCI500_PORT_S4:
-	case CCI500_PORT_S5:
-	case CCI500_PORT_S6:
+	case CCI5xx_PORT_S0:
+	case CCI5xx_PORT_S1:
+	case CCI5xx_PORT_S2:
+	case CCI5xx_PORT_S3:
+	case CCI5xx_PORT_S4:
+	case CCI5xx_PORT_S5:
+	case CCI5xx_PORT_S6:
 		if_type = CCI_IF_SLAVE;
 		break;
-	case CCI500_PORT_M0:
-	case CCI500_PORT_M1:
-	case CCI500_PORT_M2:
-	case CCI500_PORT_M3:
-	case CCI500_PORT_M4:
-	case CCI500_PORT_M5:
+	case CCI5xx_PORT_M0:
+	case CCI5xx_PORT_M1:
+	case CCI5xx_PORT_M2:
+	case CCI5xx_PORT_M3:
+	case CCI5xx_PORT_M4:
+	case CCI5xx_PORT_M5:
 		if_type = CCI_IF_MASTER;
 		break;
-	case CCI500_PORT_GLOBAL:
+	case CCI5xx_PORT_GLOBAL:
 		if_type = CCI_IF_GLOBAL;
 		break;
 	default:
@@ -607,7 +610,8 @@ static int cci500_validate_hw_event(struct cci_pmu *cci_pmu,
 
 	return -ENOENT;
 }
-#endif	/* CONFIG_ARM_CCI500_PMU */
+
+#endif	/* CONFIG_ARM_CCI5xx_PMU */
 
 /*
  * Program the CCI PMU counters which have PERF_HES_ARCH set
@@ -891,7 +895,7 @@ static void pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
 		__pmu_write_counters(cci_pmu, mask);
 }
 
-#ifdef CONFIG_ARM_CCI500_PMU
+#ifdef CONFIG_ARM_CCI5xx_PMU
 
 /*
  * CCI-500 has advanced power saving policies, which could gate the
@@ -917,12 +921,12 @@ static void pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
  * 8) Disable the global PMU.
  * 9) Restore the status of the rest of the counters.
  *
- * We choose an event which for CCI-500 is guaranteed not to count.
+ * We choose an event which for CCI-5xx is guaranteed not to count.
  * We use the highest possible event code (0x1f) for the master interface 0.
  */
-#define CCI500_INVALID_EVENT	((CCI500_PORT_M0 << CCI500_PMU_EVENT_SOURCE_SHIFT) | \
-				 (CCI500_PMU_EVENT_CODE_MASK << CCI500_PMU_EVENT_CODE_SHIFT))
-static void cci500_pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
+#define CCI5xx_INVALID_EVENT	((CCI5xx_PORT_M0 << CCI5xx_PMU_EVENT_SOURCE_SHIFT) | \
+				 (CCI5xx_PMU_EVENT_CODE_MASK << CCI5xx_PMU_EVENT_CODE_SHIFT))
+static void cci5xx_pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
 {
 	int i;
 	DECLARE_BITMAP(saved_mask, cci_pmu->num_cntrs);
@@ -942,7 +946,7 @@ static void cci500_pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *ma
 		if (WARN_ON(!event))
 			continue;
 
-		pmu_set_event(cci_pmu, i, CCI500_INVALID_EVENT);
+		pmu_set_event(cci_pmu, i, CCI5xx_INVALID_EVENT);
 		pmu_enable_counter(cci_pmu, i);
 		pmu_write_counter(cci_pmu, local64_read(&event->hw.prev_count), i);
 		pmu_disable_counter(cci_pmu, i);
@@ -954,7 +958,7 @@ static void cci500_pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *ma
 	pmu_restore_counters(cci_pmu, saved_mask);
 }
 
-#endif	/* CONFIG_ARM_CCI500_PMU */
+#endif	/* CONFIG_ARM_CCI5xx_PMU */
 
 static u64 pmu_event_update(struct perf_event *event)
 {
@@ -1517,30 +1521,30 @@ static struct cci_pmu_model cci_pmu_models[] = {
 		.get_event_idx = cci400_get_event_idx,
 	},
 #endif
-#ifdef CONFIG_ARM_CCI500_PMU
+#ifdef CONFIG_ARM_CCI5xx_PMU
 	[CCI500_R0] = {
 		.name = "CCI_500",
 		.fixed_hw_cntrs = 0,
 		.num_hw_cntrs = 8,
 		.cntr_size = SZ_64K,
-		.format_attrs = cci500_pmu_format_attrs,
-		.event_attrs = cci500_pmu_event_attrs,
+		.format_attrs = cci5xx_pmu_format_attrs,
+		.event_attrs = cci5xx_pmu_event_attrs,
 		.event_ranges = {
 			[CCI_IF_SLAVE] = {
-				CCI500_SLAVE_PORT_MIN_EV,
-				CCI500_SLAVE_PORT_MAX_EV,
+				CCI5xx_SLAVE_PORT_MIN_EV,
+				CCI5xx_SLAVE_PORT_MAX_EV,
 			},
 			[CCI_IF_MASTER] = {
-				CCI500_MASTER_PORT_MIN_EV,
-				CCI500_MASTER_PORT_MAX_EV,
+				CCI5xx_MASTER_PORT_MIN_EV,
+				CCI5xx_MASTER_PORT_MAX_EV,
 			},
 			[CCI_IF_GLOBAL] = {
-				CCI500_GLOBAL_PORT_MIN_EV,
-				CCI500_GLOBAL_PORT_MAX_EV,
+				CCI5xx_GLOBAL_PORT_MIN_EV,
+				CCI5xx_GLOBAL_PORT_MAX_EV,
 			},
 		},
 		.validate_hw_event = cci500_validate_hw_event,
-		.write_counters	= cci500_pmu_write_counters,
+		.write_counters	= cci5xx_pmu_write_counters,
 	},
 #endif
 };
@@ -1560,7 +1564,7 @@ static const struct of_device_id arm_cci_pmu_matches[] = {
 		.data	= &cci_pmu_models[CCI400_R1],
 	},
 #endif
-#ifdef CONFIG_ARM_CCI500_PMU
+#ifdef CONFIG_ARM_CCI5xx_PMU
 	{
 		.compatible = "arm,cci-500-pmu,r0",
 		.data = &cci_pmu_models[CCI500_R0],
-- 
1.7.9.5



From suzuki.poulose at arm.com  Tue Feb 23 02:49:55 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Tue, 23 Feb 2016 10:49:55 +0000
Subject: [PATCH 13/13] arm-cci: CoreLink CCI-550 PMU driver
In-Reply-To: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456224595-3282-14-git-send-email-suzuki.poulose@arm.com>

Add ARM CoreLink CCI-550  cache coherent interconnect PMU
driver support. The CCI-550 PMU shares all the attributes of CCI-500
PMU, except for an additional master interface (MI-6 - 0xe).
CCI-550 requires the same work around as for CCI-500 to
write to the PMU counter.

Acked-by: Punit Agrawal <punit.agrawal at arm.com>
Acked-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 Documentation/devicetree/bindings/arm/cci.txt |    2 +
 drivers/bus/Kconfig                           |    8 +--
 drivers/bus/arm-cci.c                         |   85 ++++++++++++++++++++++++-
 3 files changed, 90 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/cci.txt b/Documentation/devicetree/bindings/arm/cci.txt
index aef1d20..a1a5a7e 100644
--- a/Documentation/devicetree/bindings/arm/cci.txt
+++ b/Documentation/devicetree/bindings/arm/cci.txt
@@ -34,6 +34,7 @@ specific to ARM.
 		Definition: must contain one of the following:
 			    "arm,cci-400"
 			    "arm,cci-500"
+			    "arm,cci-550"
 
 	- reg
 		Usage: required
@@ -101,6 +102,7 @@ specific to ARM.
 				 "arm,cci-400-pmu"  - DEPRECATED, permitted only where OS has
 						      secure acces to CCI registers
 				 "arm,cci-500-pmu,r0"
+				 "arm,cci-550-pmu,r0"
 		- reg:
 			Usage: required
 			Value type: Integer cells. A register entry, expressed
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index e553834..d4a3a31 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -35,14 +35,14 @@ config ARM_CCI400_PORT_CTRL
 	  interconnect for ARM platforms.
 
 config ARM_CCI5xx_PMU
-	bool "ARM CCI500 PMU support"
+	bool "ARM CCI-500/CCI-550 PMU support"
 	depends on (ARM && CPU_V7) || ARM64
 	depends on PERF_EVENTS
 	select ARM_CCI_PMU
 	help
-	  Support for PMU events monitoring on the ARM CCI-500 cache coherent
-	  interconnect. CCI-500 provides 8 independent event counters, which
-	  can count events pertaining to the slave/master interfaces as well
+	  Support for PMU events monitoring on the ARM CCI-500/CCI-550 cache
+	  coherent interconnects. Both of them provide 8 independent event counters,
+	  which can count events pertaining to the slave/master interfaces as well
 	  as the internal events to the CCI.
 
 	  If unsure, say Y
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 683e289..494bd39 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -54,6 +54,7 @@ static const struct of_device_id arm_cci_matches[] = {
 #endif
 #ifdef CONFIG_ARM_CCI5xx_PMU
 	{ .compatible = "arm,cci-500", },
+	{ .compatible = "arm,cci-550", },
 #endif
 	{},
 };
@@ -156,6 +157,7 @@ enum cci_models {
 #endif
 #ifdef CONFIG_ARM_CCI5xx_PMU
 	CCI500_R0,
+	CCI550_R0,
 #endif
 	CCI_MODEL_MAX
 };
@@ -451,6 +453,7 @@ static inline struct cci_pmu_model *probe_cci_model(struct platform_device *pdev
 #define CCI5xx_PORT_M3			0xb
 #define CCI5xx_PORT_M4			0xc
 #define CCI5xx_PORT_M5			0xd
+#define CCI5xx_PORT_M6			0xe
 
 #define CCI5xx_PORT_GLOBAL		0xf
 
@@ -611,6 +614,58 @@ static int cci500_validate_hw_event(struct cci_pmu *cci_pmu,
 	return -ENOENT;
 }
 
+/*
+ * CCI550 provides 8 independent event counters that can count
+ * any of the events available.
+ * CCI550 PMU event source ids
+ *	0x0-0x6 - Slave interfaces
+ *	0x8-0xe - Master interfaces
+ *	0xf     - Global Events
+ *	0x7	- Reserved
+ */
+static int cci550_validate_hw_event(struct cci_pmu *cci_pmu,
+					unsigned long hw_event)
+{
+	u32 ev_source = CCI5xx_PMU_EVENT_SOURCE(hw_event);
+	u32 ev_code = CCI5xx_PMU_EVENT_CODE(hw_event);
+	int if_type;
+
+	if (hw_event & ~CCI5xx_PMU_EVENT_MASK)
+		return -ENOENT;
+
+	switch (ev_source) {
+	case CCI5xx_PORT_S0:
+	case CCI5xx_PORT_S1:
+	case CCI5xx_PORT_S2:
+	case CCI5xx_PORT_S3:
+	case CCI5xx_PORT_S4:
+	case CCI5xx_PORT_S5:
+	case CCI5xx_PORT_S6:
+		if_type = CCI_IF_SLAVE;
+		break;
+	case CCI5xx_PORT_M0:
+	case CCI5xx_PORT_M1:
+	case CCI5xx_PORT_M2:
+	case CCI5xx_PORT_M3:
+	case CCI5xx_PORT_M4:
+	case CCI5xx_PORT_M5:
+	case CCI5xx_PORT_M6:
+		if_type = CCI_IF_MASTER;
+		break;
+	case CCI5xx_PORT_GLOBAL:
+		if_type = CCI_IF_GLOBAL;
+		break;
+	default:
+		return -ENOENT;
+	}
+
+	if (ev_code >= cci_pmu->model->event_ranges[if_type].min &&
+		ev_code <= cci_pmu->model->event_ranges[if_type].max)
+		return hw_event;
+
+	return -ENOENT;
+}
+
 #endif	/* CONFIG_ARM_CCI5xx_PMU */
 
 /*
@@ -898,7 +953,7 @@ static void pmu_write_counters(struct cci_pmu *cci_pmu, unsigned long *mask)
 #ifdef CONFIG_ARM_CCI5xx_PMU
 
 /*
- * CCI-500 has advanced power saving policies, which could gate the
+ * CCI-500/CCI-550 has advanced power saving policies, which could gate the
  * clocks to the PMU counters, which makes the writes to them ineffective.
  * The only way to write to those counters is when the global counters
  * are enabled and the particular counter is enabled.
@@ -1546,6 +1601,30 @@ static struct cci_pmu_model cci_pmu_models[] = {
 		.validate_hw_event = cci500_validate_hw_event,
 		.write_counters	= cci5xx_pmu_write_counters,
 	},
+	[CCI550_R0] = {
+		.name = "CCI_550",
+		.fixed_hw_cntrs = 0,
+		.num_hw_cntrs = 8,
+		.cntr_size = SZ_64K,
+		.format_attrs = cci5xx_pmu_format_attrs,
+		.event_attrs = cci5xx_pmu_event_attrs,
+		.event_ranges = {
+			[CCI_IF_SLAVE] = {
+				CCI5xx_SLAVE_PORT_MIN_EV,
+				CCI5xx_SLAVE_PORT_MAX_EV,
+			},
+			[CCI_IF_MASTER] = {
+				CCI5xx_MASTER_PORT_MIN_EV,
+				CCI5xx_MASTER_PORT_MAX_EV,
+			},
+			[CCI_IF_GLOBAL] = {
+				CCI5xx_GLOBAL_PORT_MIN_EV,
+				CCI5xx_GLOBAL_PORT_MAX_EV,
+			},
+		},
+		.validate_hw_event = cci550_validate_hw_event,
+		.write_counters	= cci5xx_pmu_write_counters,
+	},
 #endif
 };
 
@@ -1569,6 +1648,10 @@ static const struct of_device_id arm_cci_pmu_matches[] = {
 		.compatible = "arm,cci-500-pmu,r0",
 		.data = &cci_pmu_models[CCI500_R0],
 	},
+	{
+		.compatible = "arm,cci-550-pmu,r0",
+		.data = &cci_pmu_models[CCI550_R0],
+	},
 #endif
 	{},
 };
-- 
1.7.9.5



From pantelis.antoniou at konsulko.com  Tue Feb 23 02:59:50 2016
From: pantelis.antoniou at konsulko.com (Pantelis Antoniou)
Date: Tue, 23 Feb 2016 12:59:50 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CAHCN7xLo7q=Ts3WLvx_GzSBWt5r1SiU7vr+W==kUAaAvmwXJYA@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAHCN7xLo7q=Ts3WLvx_GzSBWt5r1SiU7vr+W==kUAaAvmwXJYA@mail.gmail.com>
Message-ID: <6A77838A-7F72-40C3-B279-710F305AEB40@konsulko.com>

Hi Adam,

> On Feb 23, 2016, at 12:32 , Adam Ford <aford173 at gmail.com> wrote:
> 
> On Tue, Feb 23, 2016 at 3:58 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
>> (cc'ing a few more people as this is going into generic direction)
>> 
>> On 23/02/16 11:08, Linus Walleij wrote:
>>> On Thu, Feb 4, 2016 at 3:04 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
>>> 
>>>> This moves the versatile CLCD configuration to the device tree by:
>>> 
>>> As this Schr?dinger's cat approach seems controversial, as well
>>> as the alternative to manipulate the DT in memory at run-time,
>>> I will respin the series without the full Versatile support, adding
>>> plug-in for the other ARM boards and and half-baked support
>>> for the Versatile supporting just VGA (like the other reference
>>> designs from ARM).
>>> 
>>> The pluggable displays prove yet again to be a problem to the
>>> world, sigh.
>>> 
>>> I will think of a better solution, if any, for this for v4.6, but will
>>> put forward something that handles the Nomadik and all the
>>> other ARM reference designs for now.
>> 
>> I had a chat with Tom Rini and Pantelis Antoniou yesterday.
>> 
>> Panto is about to send a new series for DT overlay management soon. I
>> haven't had time to test that yet, but what it would give us is that you
>> could build DT overlay binaries as "firmware" into the kernel image, and
>> thus the panel DT data would be there even before rootfs is mounted. The
>> DT overlays can be loaded from the rootfs or initramfs too, if it's not
>> critical to get the display up early.
>> 
>> I'm not quite sure how it works if, as in versatile display case, there
>> are multiple DT overlays of which one has to be enabled. I hope there's
>> support to choose which one to use via kernel cmdline or similar.
>> 
>> I would personally like it much more if the bootloader would either
>> compose a final dtb from DT fragments and pass it to the kernel, or
>> alternatively the bootloader would pass the base dtb image and a bunch
>> of DT overlays to the kernel, and the kernel would deal with the DT
>> overlays.
>> 
> If there was a nice way to merge the device trees, I would love to
> create device tree 'modules' that could be loaded at will and merged
> just before the time of boot.  I could see this being useful beyond
> just plugable displays.
> 

Looks like you would be happy by having a way to boot using a device tree
blob + a number of device tree overlay blobs to be applied in sequence.

You could append the dtbo?s to the device tree blob (where-ever that may be)
and it should work.

The good thing about this scheme is that it?s independent of the bootloader.

An advanced bootloader (like u-boot) with DT smarts can create the appended
DT blob itself, while a dumb one can just be given the appended blob as
it was created outside of the device.

>> In any case, I think the firmware solution is a good step forward, and
>> will probably work fine for many users. Then again, I haven't tested it
>> yet so I don't know the details, and it's not in the mainline.
>> 
> I am willing to test it, but I'll need the patch and some instructions
> from Panto.
> 

The appended device tree blob thing does not exist yet, but it?s not such a big
problem to add. I?d give it a shot this week.

The standard device tree overlays are in my overlay branch at
https://github.com/pantoniou/linux-beagle-track-mainline/tree/bbb-overlays

The capemgr has options for parsing a kernel command line to apply an overlay:

https://github.com/pantoniou/linux-beagle-track-mainline/blob/bbb-overlays/drivers/misc/bone_capemgr.c

The command line options are enable_partno & disable_partno where you supply
the part numbers of the capes you want enabled/disabled at boot.

The capemgr is complicated due to the eeprom detection and the horrible kludges done with the
variants (beaglebone white/beaglebone black), but I think you can figure out what?s going
on with the command line options.


>> Tomi
>> 

Regards

? Pantelis



From michal.simek at xilinx.com  Tue Feb 23 03:08:34 2016
From: michal.simek at xilinx.com (Michal Simek)
Date: Tue, 23 Feb 2016 12:08:34 +0100
Subject: [PATCH V4 5/5] Microblaze: Modifying microblaze PCI subsytem to
 support generic Xilinx AXI PCIe Host Bridge IP driver
In-Reply-To: <1455208091-15556-6-git-send-email-bharatku@xilinx.com>
References: <1455208091-15556-1-git-send-email-bharatku@xilinx.com>
 <1455208091-15556-6-git-send-email-bharatku@xilinx.com>
Message-ID: <56CC3DB2.3080900@xilinx.com>

On 11.2.2016 17:28, Bharat Kumar Gogada wrote:
> This patch does required modifications to microblaze PCI subsystem, to
> work with generic driver (drivers/pci/host/pcie-xilinx.c) on Microblaze
> and Zynq.
> 
> Signed-off-by: Bharat Kumar Gogada <bharatku at xilinx.com>
> Signed-off-by: Ravi Kiran Gummaluri <rgummal at xilinx.com>
> ---
> Changes:
> Removed pcibios_get_phb_of_node in pci-common.c, using generic version
> instead.
> Modified pcibios_fixup_bus in pci-common.c, as per generic architecuture.
> Modified pcibios_align_resource in pci-common.c, as per generic
> architecuture, removed temporary variable.
> Removed pci_domain_nr in pci-common.c, instead using generic code.
> Added pcibios_add_device in pci-common.c, as per generic architecuture.
> Adding Kernel configuration in arch/microblaze as required for generic PCI
> domains.
> Added kernel configuration for driver to support Microblaze.
> ---
>  arch/microblaze/Kconfig          |  3 +++
>  arch/microblaze/pci/pci-common.c | 56 +++++++---------------------------------
>  drivers/pci/host/Kconfig         |  2 +-
>  3 files changed, 14 insertions(+), 47 deletions(-)
> 
> diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
> index 0bce820..c3702b9 100644
> --- a/arch/microblaze/Kconfig
> +++ b/arch/microblaze/Kconfig
> @@ -271,6 +271,9 @@ config PCI
>  config PCI_DOMAINS
>  	def_bool PCI
>  
> +config PCI_DOMAINS_GENERIC
> +	def_bool PCI_DOMAINS
> +
>  config PCI_SYSCALL
>  	def_bool PCI
>  
> diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
> index ae838ed..35654be 100644
> --- a/arch/microblaze/pci/pci-common.c
> +++ b/arch/microblaze/pci/pci-common.c
> @@ -123,17 +123,6 @@ unsigned long pci_address_to_pio(phys_addr_t address)
>  }
>  EXPORT_SYMBOL_GPL(pci_address_to_pio);
>  
> -/*
> - * Return the domain number for this bus.
> - */
> -int pci_domain_nr(struct pci_bus *bus)
> -{
> -	struct pci_controller *hose = pci_bus_to_host(bus);
> -
> -	return hose->global_number;
> -}
> -EXPORT_SYMBOL(pci_domain_nr);
> -
>  /* This routine is meant to be used early during boot, when the
>   * PCI bus numbers have not yet been assigned, and you need to
>   * issue PCI config cycles to an OF device.
> @@ -863,26 +852,10 @@ void pcibios_setup_bus_devices(struct pci_bus *bus)
>  
>  void pcibios_fixup_bus(struct pci_bus *bus)
>  {
> -	/* When called from the generic PCI probe, read PCI<->PCI bridge
> -	 * bases. This is -not- called when generating the PCI tree from
> -	 * the OF device-tree.
> -	 */
> -	if (bus->self != NULL)
> -		pci_read_bridge_bases(bus);
> -
> -	/* Now fixup the bus bus */
> -	pcibios_setup_bus_self(bus);
> -
> -	/* Now fixup devices on that bus */
> -	pcibios_setup_bus_devices(bus);
> +	/* nothing to do */
>  }
>  EXPORT_SYMBOL(pcibios_fixup_bus);
>  
> -static int skip_isa_ioresource_align(struct pci_dev *dev)
> -{
> -	return 0;
> -}
> -
>  /*
>   * We need to avoid collisions with `mirrored' VGA ports
>   * and other strange ISA hardware, so we always want the
> @@ -899,20 +872,18 @@ static int skip_isa_ioresource_align(struct pci_dev *dev)
>  resource_size_t pcibios_align_resource(void *data, const struct resource *res,
>  				resource_size_t size, resource_size_t align)
>  {
> -	struct pci_dev *dev = data;
> -	resource_size_t start = res->start;
> -
> -	if (res->flags & IORESOURCE_IO) {
> -		if (skip_isa_ioresource_align(dev))
> -			return start;
> -		if (start & 0x300)
> -			start = (start + 0x3ff) & ~0x3ff;
> -	}
> -
> -	return start;
> +	return res->start;
>  }
>  EXPORT_SYMBOL(pcibios_align_resource);
>  
> +int pcibios_add_device(struct pci_dev *dev)
> +{
> +	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL(pcibios_add_device);
> +
>  /*
>   * Reparent resource children of pr that conflict with res
>   * under res, and make res replace those children.
> @@ -1333,13 +1304,6 @@ static void pcibios_setup_phb_resources(struct pci_controller *hose,
>  		 (unsigned long)hose->io_base_virt - _IO_BASE);
>  }
>  
> -struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus)
> -{
> -	struct pci_controller *hose = bus->sysdata;
> -
> -	return of_node_get(hose->dn);
> -}
> -
>  static void pcibios_scan_phb(struct pci_controller *hose)
>  {
>  	LIST_HEAD(resources);
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index d5e58ba..7c56c2e 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -79,7 +79,7 @@ config PCI_KEYSTONE
>  
>  config PCIE_XILINX
>  	bool "Xilinx AXI PCIe host bridge support"
> -	depends on ARCH_ZYNQ
> +	depends on ARCH_ZYNQ || MICROBLAZE
>  	help
>  	  Say 'Y' here if you want kernel to support the Xilinx AXI PCIe
>  	  Host Bridge driver.
> 

Less code in arch is better.

Acked-by: Michal Simek <michal.simek at xilinx.com>

Bjorn: Please take this via your tree.

Thanks,
Michal


From manabian at gmail.com  Tue Feb 23 03:21:35 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Tue, 23 Feb 2016 12:21:35 +0100
Subject: [PATCH 1/4] net: ethernet: dwmac: add Ethernet glue logic for
 stm32 chip
In-Reply-To: <CAJgp7zxYhbQ4yQHBB3cu50TU9N9xvk3HxCp0NP5fxFbxrMsD_g@mail.gmail.com>
References: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
 <1454511275-9791-2-git-send-email-alexandre.torgue@gmail.com>
 <CAGhQ9VypZ5J0pQmrf1Mk-mNsv=XTXu7fhoLt_r2LHJ_Lsyj0yA@mail.gmail.com>
 <CAJgp7zwOVEq=hnxfUt7eHZWSFUAwuK6MCVHdH591=xReRUsW8Q@mail.gmail.com>
 <CAGhQ9VzPTgRqqLi4zjHkP-++v5smZ7s52drev1z-AvgXaLuC7Q@mail.gmail.com>
 <CAJgp7zxYhbQ4yQHBB3cu50TU9N9xvk3HxCp0NP5fxFbxrMsD_g@mail.gmail.com>
Message-ID: <CAGhQ9VxQ3nW+dr9pdj=H8UcsNHEATxVeAf8N_PsQA7-73uksTA@mail.gmail.com>

On 23 February 2016 at 10:59, Alexandre Torgue
<alexandre.torgue at gmail.com> wrote:
> 2016-02-22 22:52 GMT+01:00 Joachim  Eastwood <manabian at gmail.com>:
>> On 22 February 2016 at 15:50, Alexandre Torgue
>> <alexandre.torgue at gmail.com> wrote:
>>> 2016-02-13 14:48 GMT+01:00 Joachim  Eastwood <manabian at gmail.com>:
>>>> On 3 February 2016 at 15:54, Alexandre TORGUE
>>>> <alexandre.torgue at gmail.com> wrote:
>>>>> +       plat_dat->bsp_priv = dwmac;
>>>>> +       plat_dat->init = stm32_dwmac_init;
>>>>> +       plat_dat->exit = stm32_dwmac_exit;
>>>>
>>>> Instead of using these callbacks could you rather implement the PM
>>>> callbacks directly in this driver?
>>>> I don't think it should add much code and it will make it look more
>>>> like standard driver. This will also give you some more control and
>>>> flexibility in your code.
>>>
>>> I prefer to keep the code as it is. Glue layer is directly linked to
>>> stmmac driver and I don't want to brake the link between the glue and
>>> the stmmac driver.
>>
>> What do you mean by break the link?
>>
>
> I thought that you wanted to split stmmac_pltfr_supend (glue part and
> stmamc part), but I well understood it is not the case (sorry for
> mistake).
>
>> There has been numerous of patch sets to make the stmmac "glue"
>> drivers into more standard platform drivers.
>> http://marc.info/?l=linux-netdev&m=143159850631093&w=2
>> http://marc.info/?l=linux-netdev&m=143708560009851&w=2
>> http://marc.info/?l=linux-netdev&m=143812136600541&w=2
>>
>> Do you see any advantage by using the init and exit hooks in your
>> driver instead of using the standard driver PM callbacks and remove
>> function?
>> The only "cost" I see is slightly more boilerplate code. But since you
>> already have init/exit functions you could easily make them into PM
>> resume/suspend so I doubt there would be much increase in code size.
>>
>
> If I well understood you want to continue the stmmac glue driver
> rework by moving stmmac_pltfr_suspend/resume/remove in each glue
> driver (stm32, sun, sti ....).

At least I want to avoid the init/exit callbacks for new drivers like
stm32-dwmac.


> Each glue driver will call directly stmmac_suspend/resume/remove and
> their own init/exit function.
> If it is what you meant, I can do it.

Yes, in your stm32 driver's suspend/resume/remove functions call
stmmac_suspend/stmmac_resume/stmmac_dvr_remove directly. Then you
shouldn't need to use the init/exit callbacks. Just put the need code
in the driver's suspend/resume/remove functions instead of init/exit
functions.

For example:
static int stm32_dwmac_resume(struct device *dev)
{
    struct net_device *ndev = dev_get_drvdata(dev);
    struct plat_stmmacenet_data *plat_dat = get_stmmac_plat_data(ndev)
    struct stm32_dwmac *dwmac =plat_dat->bsp_priv;

    /* enable clocks */
    /* set phy mode */

    return stmmac_resume(ndev);
}

If it makes sense to have the enable clk/phy mode stuff in it's own
function that is fine too.


>> One other thing;
>> Do you need to have the PHY mode setup code in the init function which
>> is called each time on resume?
>
> I can't guarantee that after a suspend the sysconfig register will
> contain same data than before suspend.

I see.


regards,
Joachim Eastwood


From will.deacon at arm.com  Tue Feb 23 03:22:19 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Feb 2016 11:22:19 +0000
Subject: [PATCH V2] iommu/arm-smmu-v2: Add support for 16 bit VMID
In-Reply-To: <1455906813-9721-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1455906813-9721-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <20160223112219.GE3966@arm.com>

Hi Tirumalesh,

I still have some questions and comments about this.

On Fri, Feb 19, 2016 at 10:33:33AM -0800, tchalamarla at caviumnetworks.com wrote:
> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> 
> ARM-SMMUv2 supports upto 16 bit VMID. This patch enables
> 16 bit VMID when HW supports.
> 
> changes from V1:
> 	- Remove DT Property and enable 16 bit VMID if ID says.

Does this mean we can remove the comment from arm_smmu_init_context_bank
about CBA2R initialisation, or is that behaviour still required by some
parts? Further, what happens if we set CR0.VMID16EN on those
implementations?

> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> ---
>  drivers/iommu/arm-smmu.c | 24 +++++++++++++++++++++++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 59ee4b8..92caab8 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -93,6 +93,7 @@
>  #define sCR0_VMIDPNE			(1 << 11)
>  #define sCR0_PTM			(1 << 12)
>  #define sCR0_FB				(1 << 13)
> +#define sCR0_VMID16EN			(1 << 31)
>  #define sCR0_BSU_SHIFT			14
>  #define sCR0_BSU_MASK			0x3
>  
> @@ -140,6 +141,7 @@
>  #define ID2_PTFS_4K			(1 << 12)
>  #define ID2_PTFS_16K			(1 << 13)
>  #define ID2_PTFS_64K			(1 << 14)
> +#define ID2_VMID16			(1 << 15)
>  
>  /* Global TLB invalidation */
>  #define ARM_SMMU_GR0_TLBIVMID		0x64
> @@ -189,6 +191,8 @@
>  #define ARM_SMMU_GR1_CBA2R(n)		(0x800 + ((n) << 2))
>  #define CBA2R_RW64_32BIT		(0 << 0)
>  #define CBA2R_RW64_64BIT		(1 << 0)
> +#define CBA2R_VMID_SHIFT		16
> +#define CBA2R_VMID_MASK			0xffff
>  
>  /* Translation context bank */
>  #define ARM_SMMU_CB_BASE(smmu)		((smmu)->base + ((smmu)->size >> 1))
> @@ -297,6 +301,7 @@ struct arm_smmu_device {
>  #define ARM_SMMU_FEAT_TRANS_S2		(1 << 3)
>  #define ARM_SMMU_FEAT_TRANS_NESTED	(1 << 4)
>  #define ARM_SMMU_FEAT_TRANS_OPS		(1 << 5)
> +#define ARM_SMMU_FEAT_VMID16		(1 << 6)
>  	u32				features;
>  
>  #define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
> @@ -736,6 +741,10 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>  #else
>  		reg = CBA2R_RW64_32BIT;
>  #endif
> +		/* if 16bit VMID supported set VMID in CBA2R */
> +		if (smmu->features & ARM_SMMU_FEAT_VMID16)
> +			reg |= ARM_SMMU_CB_VMID(cfg) << CBA2R_VMID_SHIFT;
> +
>  		writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBA2R(cfg->cbndx));
>  	}
>  
> @@ -751,7 +760,8 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>  	if (stage1) {
>  		reg |= (CBAR_S1_BPSHCFG_NSH << CBAR_S1_BPSHCFG_SHIFT) |
>  			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
> -	} else {
> +	} else if (!(smmu->features & ARM_SMMU_FEAT_VMID16)) {
> +		/*16 bit VMID is not supported set 8 bit VMID here */
>  		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
>  	}
>  	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
> @@ -1508,6 +1518,9 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
>  	/* Don't upgrade barriers */
>  	reg &= ~(sCR0_BSU_MASK << sCR0_BSU_SHIFT);
>  
> +	if (smmu->features & ARM_SMMU_FEAT_VMID16)
> +		reg |= sCR0_VMID16EN;
> +
>  	/* Push the button */
>  	__arm_smmu_tlb_sync(smmu);
>  	writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
> @@ -1658,6 +1671,10 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
>  	size = arm_smmu_id_size_to_bits((id >> ID2_OAS_SHIFT) & ID2_OAS_MASK);
>  	smmu->pa_size = size;
>  
> +	/* See if 16bit VMID is supported */
> +	if (id & ID2_VMID16)
> +		smmu->features = ARM_SMMU_FEAT_VMID16;

This should be |=

> +
>  	/*
>  	 * What the page table walker can address actually depends on which
>  	 * descriptor format is in use, but since a) we don't know that yet,
> @@ -1696,6 +1713,11 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
>  		dev_notice(smmu->dev, "\tStage-2: %lu-bit IPA -> %lu-bit PA\n",
>  			   smmu->ipa_size, smmu->pa_size);
>  
> +	if (smmu->features & ARM_SMMU_FEAT_VMID16)
> +		dev_notice(smmu->dev, "\t 16 bit VMID Supported.\n");
> +	else
> +		dev_notice(smmu->dev, "\t Only 8 bit VMID Supported.\n");

Supporting "only" 8-bit VMIDs is usually plenty ;) In fact, your patch
doesn't change the allocator, so we'll still use a zero-extended 8-bit
VMID, so this print is fairly useless.

Will


From zhaoshenglong at huawei.com  Tue Feb 23 03:13:29 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Tue, 23 Feb 2016 19:13:29 +0800
Subject: [PATCH v4 16/17] FDT: Add a helper to get specified name subnode
In-Reply-To: <CAL_JsqK8F6PQX2kC_+CtDk1-ykKRB3YB54o4FaypsRY_tNzK5w@mail.gmail.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
 <1454641552-12576-17-git-send-email-zhaoshenglong@huawei.com>
 <CAL_JsqK8F6PQX2kC_+CtDk1-ykKRB3YB54o4FaypsRY_tNzK5w@mail.gmail.com>
Message-ID: <56CC3ED9.5000101@huawei.com>



On 2016/2/9 13:04, Rob Herring wrote:
> On Thu, Feb 4, 2016 at 9:05 PM, Shannon Zhao <zhaoshenglong at huawei.com> wrote:
>> From: Shannon Zhao <shannon.zhao at linaro.org>
>>
>> Sometimes it needs to check if there is a node in FDT by full path.
> 
> I'm confused. Are you searching by full path or...
> 
>> Introduce this helper to get the specified name subnode if it exists.
> 
> name of sub node?
> 
get the offset of sub node by specified name.

> Either way, fdt_subnode_offset or fdt_path_offset doesn't work?
> 
Ah?right?both of them should work. Does it need to add a wrapper in
drivers/of/fdt.c for them or directly use them with the parameter
initial_boot_params?

Thanks,
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
>> ---
>> CC: Rob Herring <robh at kernel.org>
>> ---
>>  drivers/of/fdt.c       | 25 +++++++++++++++++++++++++
>>  include/linux/of_fdt.h |  2 ++
>>  2 files changed, 27 insertions(+)
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 655f79d..eacb188 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -645,6 +645,31 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,
>>  }
>>
>>  /**
>> + * of_get_flat_dt_subnode_by_name - get subnode of specified node by name
>> + *
>> + * @node: the parent node
>> + * @uname: the name of subnode
>> + * @return offset of the subnode, or -FDT_ERR_NOTFOUND if there is none
>> + */
>> +
>> +int of_get_flat_dt_subnode_by_name(unsigned long node, const char *uname)
>> +{
>> +       const void *blob = initial_boot_params;
>> +       int offset;
>> +       const char *pathp;
>> +
>> +       for (offset = fdt_first_subnode(blob, node);
>> +            offset >= 0;
>> +            offset = fdt_next_subnode(blob, offset)) {
>> +               pathp = fdt_get_name(blob, offset, NULL);
>> +               if (strcmp(pathp, uname) == 0)
>> +                       return offset;
>> +       }
>> +
>> +       return -FDT_ERR_NOTFOUND;
>> +}
>> +
>> +/**
>>   * of_get_flat_dt_root - find the root node in the flat blob
>>   */
>>  unsigned long __init of_get_flat_dt_root(void)
>> diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
>> index df9ef38..fc28162 100644
>> --- a/include/linux/of_fdt.h
>> +++ b/include/linux/of_fdt.h
>> @@ -52,6 +52,8 @@ extern char __dtb_end[];
>>  extern int of_scan_flat_dt(int (*it)(unsigned long node, const char *uname,
>>                                      int depth, void *data),
>>                            void *data);
>> +extern int of_get_flat_dt_subnode_by_name(unsigned long node,
>> +                                         const char *uname);
>>  extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
>>                                        int *size);
>>  extern int of_flat_dt_is_compatible(unsigned long node, const char *name);
>> --
>> 2.0.4
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> .
> 

-- 
Shannon



From arnd at arndb.de  Tue Feb 23 03:22:34 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 12:22:34 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CACRpkdZjfjOCFUucF1U5yVZBxSwa41GKEMv-HHQE=ymF2NZ21g@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <3695074.sKSIyOjpjD@wuerfel>
 <CACRpkdZjfjOCFUucF1U5yVZBxSwa41GKEMv-HHQE=ymF2NZ21g@mail.gmail.com>
Message-ID: <6859810.tb1t0IEONi@wuerfel>

On Tuesday 23 February 2016 11:10:33 Linus Walleij wrote:
> 
> ERROR (duplicate_label): ERROR (duplicate_label): Duplicate label
> 'clcd_panel' on /panel at 1/port/endpoint and /panel at 0/port/endpoint
> Duplicate label 'clcd_panel' on /panel at 1/port/endpoint and
> /panel at 0/port/endpoint
> 
> So the dtc does not allow duplicate node labels for the phandle
> even if the node it resides in is disabled. Tough luck...

Ah, too bad. I guess we could still do it by also setting the
remote-endpoint property to node->phandle, but then it's
not as simple any more.

	Arnd


From linux at arm.linux.org.uk  Tue Feb 23 03:30:59 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 23 Feb 2016 11:30:59 +0000
Subject: [PATCH] clk: gpio: Really allow an optional clock= DT property
In-Reply-To: <1455851525-18972-1-git-send-email-sboyd@codeaurora.org>
References: <20160219030731.GS4847@codeaurora.org>
 <1455851525-18972-1-git-send-email-sboyd@codeaurora.org>
Message-ID: <20160223113059.GH19428@n2100.arm.linux.org.uk>

On Thu, Feb 18, 2016 at 07:12:05PM -0800, Stephen Boyd wrote:
> We mis-merged the original patch from Russell here and so the
> patch went almost all the way, except that we still failed to
> probe when there wasn't a clocks property in the DT node. Allow
> that case by making a negative value from
> of_clk_get_parent_count() into "no parents", like the original
> patch did.

So you apply it anyway, and ignore all further discussion.  I've
no idea what kind of politics is going on here, but it has to stop.

I'm also still waiting for that apology from Mike - never apply a
modified patch without stating in the commit log that it was modified.
It's basically fraud.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From will.deacon at arm.com  Tue Feb 23 03:40:03 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Feb 2016 11:40:03 +0000
Subject: [PATCH 00/13] arm-cci: PMU driver updates for 4.6
In-Reply-To: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <20160223114003.GF3966@arm.com>

On Tue, Feb 23, 2016 at 10:49:42AM +0000, Suzuki K Poulose wrote:
> Here are some fixes and updates for arm-cci pmu driver targeting v4.6,
> applies on top of v4.5-rc5.
> 
> Highlights include :
>  - Support for CoreLink CCI-550 PMU
>  - Reliable writes to PMU Counter registers for CCI-500/550.
> 
> All the patches have been Acked. Please let me know how this
> can be merged.
> 
> Andrzej Hajda (1):
>   arm-cci: fix handling cpumask_any_but return value
> 
> Mark Rutland (1):
>   arm-cci: simplify sysfs attr handling
> 
> Suzuki K Poulose (11):
>   arm-cci: Group writes to counter
>   arm-cci: Refactor CCI PMU enable/disable methods
>   arm-cci: Delay PMU counter writes to pmu::pmu_enable
>   arm-cci: write_counter: Remove redundant check
>   arm-cci: Get the status of a counter
>   arm-cci: Add routines to save/restore all counters
>   arm-cci: Add helper to enable PMU without synchornising counters
>   arm-cci: Provide hook for writing to PMU counters
>   arm-cci: CCI-500: Work around PMU counter writes
>   arm-cci500: Rearrange PMU driver for code sharing with CCI-550 PMU
>   arm-cci: CoreLink CCI-550 PMU driver
> 
>  Documentation/devicetree/bindings/arm/cci.txt |    2 +
>  drivers/bus/Kconfig                           |   10 +-
>  drivers/bus/arm-cci.c                         |  612 +++++++++++++++++--------
>  3 files changed, 427 insertions(+), 197 deletions(-)

How do you plan to merge this? I can take it all onto a branch for
arm-soc, or I can include it on my perf/updates branch, or ...?

Will


From dsterba at suse.cz  Tue Feb 23 03:40:55 2016
From: dsterba at suse.cz (David Sterba)
Date: Tue, 23 Feb 2016 12:40:55 +0100
Subject: [PATCH] btrfs: avoid uninitialized variable warning
In-Reply-To: <1456178006-1619105-1-git-send-email-arnd@arndb.de>
References: <1456178006-1619105-1-git-send-email-arnd@arndb.de>
Message-ID: <20160223114055.GK4374@suse.cz>

On Mon, Feb 22, 2016 at 10:53:20PM +0100, Arnd Bergmann wrote:
> With CONFIG_SMP and CONFIG_PREEMPT both disabled, gcc decides
> to partially inline the get_state_failrec() function but cannot
> figure out that means the failrec pointer is always valid
> if the function returns success, which causes a harmless
> warning:
> 
> fs/btrfs/extent_io.c: In function 'clean_io_failure':
> fs/btrfs/extent_io.c:2131:4: error: 'failrec' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This marks get_state_failrec() and set_state_failrec() both
> as 'noinline', which avoids the warning in all cases for me,
> and seems less ugly than adding a fake initialization.

Thanks for the analysis and the fix, works for me.


From will.deacon at arm.com  Tue Feb 23 03:49:50 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Feb 2016 11:49:50 +0000
Subject: [PATCH V2] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <20160223114950.GG3966@arm.com>

On Thu, Feb 18, 2016 at 10:29:18AM -0800, tchalamarla at caviumnetworks.com wrote:
> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> 
> Due to Errata#27704 CN88xx SMMUv2,supports  only shared ASID and VMID
> namespaces; specifically within a given node SMMU0 and SMMU1 share,
> as does SMMU2 and SMMU3.
> 
> This patch tries to address these issuee by supplying asid and vmid
> base from devicetree.
> 
> changes from V1:
> 	- rebased on top of 16 bit VMID patch
> 	- removed redundent options from DT
> 	- insted of transform, DT now supplies starting ASID/VMID
> 
> Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> ---
>  .../devicetree/bindings/iommu/arm,smmu.txt         |  8 +++++
>  drivers/iommu/arm-smmu.c                           | 37 +++++++++++++++-------
>  2 files changed, 34 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index bb7e569..80b8484 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -57,6 +57,14 @@ conditions.
>  
>  - smmu-enable-vmid16 : Enable 16 bit VMID, if allowed.
>  
> +- asid-base :	Buggy SMMUv2 implementations which doesn't satisfy the
> +		ASID namespace needs, use this field to specify starting
> +		ASID for the SMMU.

Can you make this cavium,asid-base please?

> +
> +- vmid-base :	Buggy SMMUv2 implementations which doesn't satisfy the VMID
> +		namespace needs, use this field to specify starting VMID
> +		for the SMMU.

Similarly here.

> +
>  Example:
>  
>          smmu {
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 003c442..dc46b9a 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -320,6 +320,9 @@ struct arm_smmu_device {
>  	unsigned long			ipa_size;
>  	unsigned long			pa_size;
>  
> +	u32				asid_base;
> +	u32				vmid_base;
> +
>  	u32				num_global_irqs;
>  	u32				num_context_irqs;
>  	unsigned int			*irqs;
> @@ -335,8 +338,8 @@ struct arm_smmu_cfg {
>  };
>  #define INVALID_IRPTNDX			0xff
>  
> -#define ARM_SMMU_CB_ASID(cfg)		((cfg)->cbndx)
> -#define ARM_SMMU_CB_VMID(cfg)		((cfg)->cbndx + 1)
> +#define ARM_SMMU_CB_ASID(smmu, cfg)	((u16)((smmu)->asid_base + (cfg)->cbndx))
> +#define ARM_SMMU_CB_VMID(smmu, cfg)	((u16)((smmu)->vmid_base + (cfg)->cbndx))

Why are you removing the +1 from the macro and then adding it to all the
callers instead? I also think we should be performing a range-check
somewhere so that we don't silently truncate values (e.g. if we try to
program more than 8 bits on a system with 8-bit VMIDs).

>  
>  enum arm_smmu_domain_stage {
>  	ARM_SMMU_DOMAIN_S1 = 0,
> @@ -576,11 +579,11 @@ static void arm_smmu_tlb_inv_context(void *cookie)
>  
>  	if (stage1) {
>  		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
> -		writel_relaxed(ARM_SMMU_CB_ASID(cfg),
> +		writel_relaxed(ARM_SMMU_CB_ASID(smmu, cfg),
>  			       base + ARM_SMMU_CB_S1_TLBIASID);
>  	} else {
>  		base = ARM_SMMU_GR0(smmu);
> -		writel_relaxed(ARM_SMMU_CB_VMID(cfg),
> +		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg),
>  			       base + ARM_SMMU_GR0_TLBIVMID);
>  	}
>  
> @@ -602,7 +605,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>  
>  		if (!IS_ENABLED(CONFIG_64BIT) || smmu->version == ARM_SMMU_V1) {
>  			iova &= ~12UL;
> -			iova |= ARM_SMMU_CB_ASID(cfg);
> +			iova |= ARM_SMMU_CB_ASID(smmu, cfg);
>  			do {
>  				writel_relaxed(iova, reg);
>  				iova += granule;
> @@ -610,7 +613,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>  #ifdef CONFIG_64BIT
>  		} else {
>  			iova >>= 12;
> -			iova |= (u64)ARM_SMMU_CB_ASID(cfg) << 48;
> +			iova |= (u64)ARM_SMMU_CB_ASID(smmu, cfg) << 48;
>  			do {
>  				writeq_relaxed(iova, reg);
>  				iova += granule >> 12;
> @@ -630,7 +633,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>  #endif
>  	} else {
>  		reg = ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_TLBIVMID;
> -		writel_relaxed(ARM_SMMU_CB_VMID(cfg), reg);
> +		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg), reg);
>  	}
>  }
>  
> @@ -744,7 +747,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>  #endif
>  		/* if 16bit VMID required set VMID in CBA2R */
>  		if (smmu->options & ARM_SMMU_OPT_ENABLE_VMID16)
> -			reg |= ARM_SMMU_CB_VMID(cfg) << CBA2R_VMID_SHIFT;
> +			reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBA2R_VMID_SHIFT;
>  
>  		writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBA2R(cfg->cbndx));
>  	}
> @@ -763,7 +766,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>  			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
>  	} else if (!(smmu->options & ARM_SMMU_OPT_ENABLE_VMID16)) {
>  		/*16 bit VMID is not enabled set 8 bit VMID here */
> -		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
> +		reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBAR_VMID_SHIFT;
>  	}
>  	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
>  
> @@ -771,11 +774,11 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>  	if (stage1) {
>  		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>  
> -		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
> +		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
>  		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR0);
>  
>  		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
> -		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
> +		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
>  		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR1);
>  	} else {
>  		reg64 = pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
> @@ -1812,6 +1815,18 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
>  
>  	parse_driver_options(smmu);
>  
> +	if (of_property_read_u32(dev->of_node, "#asid-base",
> +				 &smmu->asid_base)) {
> +		smmu->asid_base = 0;

The smmu structure is zeroed on allocation, so no need for this.

Will


From peter.maydell at linaro.org  Tue Feb 23 03:56:34 2016
From: peter.maydell at linaro.org (Peter Maydell)
Date: Tue, 23 Feb 2016 11:56:34 +0000
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56CC2D39.80909@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
Message-ID: <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>

On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> I'm not quite sure how it works if, as in versatile display case, there
> are multiple DT overlays of which one has to be enabled. I hope there's
> support to choose which one to use via kernel cmdline or similar.
>
> I would personally like it much more if the bootloader would either
> compose a final dtb from DT fragments and pass it to the kernel, or
> alternatively the bootloader would pass the base dtb image and a bunch
> of DT overlays to the kernel, and the kernel would deal with the DT
> overlays.

Speaking as somebody who's written the "bootloader" code that's
used for what I guess are the majority of versatile kernel boots,
i.e. the one in QEMU, I think that requiring the bootloader to do this
would be a significant worsening from the current state.

Right now the bootloader doesn't need to do much at all with device
trees, except pass the kernel the DT that the user gave us, which
is just the kernel's own data structures in a separate file for
convenience. You need to do some very minor tweaks to the /chosen
node, but these can be handled the same way for any board and aren't
hardware specific. There's no need to worry about dt fragments
either for the bootloader or for the user. Imposing a new requirement
for the bootloader to have to probe hardware which it otherwise
has no need to even care about, and then edit and update the DT
in a board-specific manner, or have board-specific DT fragments,
seems like a totally unnecessary imposition on both bootloader
authors and end-users, and of course it would break booting newer
kernels on the great mass of already existing boot loaders and
QEMU installs.

The kernel is in a position to probe the display hardware and determine
what is there, and do the right thing, and that's exactly what it
does today. The kernel should continue to do this.
The advantage of DT is that it allows moving information about
non-probeable hardware that was previously hardwired in the kernel
C sources into a separate data structure, but the versatile displays
are not non-probeable. I can see no benefit at all from hardwiring into
the dt something which the kernel has previously been successfully
dynamically getting right without any bootloader intervention -- it just
makes the kernel less flexible and less user-friendly.

thanks
-- PMM


From kishon at ti.com  Tue Feb 23 03:57:03 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Tue, 23 Feb 2016 17:27:03 +0530
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <56CADB23.8020202@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com> <56BACCDB.2070507@ti.com>
 <alpine.DEB.2.02.1602111921090.20757@utopia.booyaka.com>
 <56BD8091.4090007@ti.com> <56BE1454.3030002@ti.com> <56C5D377.50901@ti.com>
 <56CAA82D.6000507@ti.com>
 <alpine.DEB.2.02.1602220631300.3418@utopia.booyaka.com>
 <56CADB23.8020202@ti.com>
Message-ID: <56CC490F.3040301@ti.com>

Hi Paul,

On Monday 22 February 2016 03:25 PM, Kishon Vijay Abraham I wrote:
> Hi Paul,
> 
> On Monday 22 February 2016 12:01 PM, Paul Walmsley wrote:
>> Kishon,
>>
>> On Mon, 22 Feb 2016, Kishon Vijay Abraham I wrote:
>>
>>> Sekhar,
>>>
>>> On Thursday 18 February 2016 07:51 PM, Sekhar Nori wrote:
>>>> On Friday 12 February 2016 10:50 PM, Suman Anna wrote:
>>>>> Sekhar,
>>>>> Will you be following up with above suggestion since Kishon is gonna be out?
>>>>
>>>> Alright, noticed this action for me :) Went through the thread, and 
>>>> looks like this is what we want to see?
>>>>
>>>> Thanks,
>>>> Sekhar
>>>>
>>>> ---8<---
>>>> From e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19 Mon Sep 17 00:00:00 2001
>>>> Message-Id: <e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19.1455803758.git.nsekhar at ti.com>
>>>> From: Sekhar Nori <nsekhar at ti.com>
>>>> Date: Thu, 18 Feb 2016 16:49:56 +0530
>>>> Subject: [PATCH 1/1] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS
>>>>
>>>> Add a custom reset handler for DRA7x PCIeSS. This
>>>> handler is required to deassert PCIe hardreset lines
>>>> after they have been asserted.
>>>>
>>>> This enables the PCIe driver to access registers after
>>>> PCIeSS has been runtime enabled without having to
>>>> deassert hardreset lines itself.
>>>>
>>>> With this patch applied, used lspci to make sure
>>>> connected PCIe device enumerates on DRA74x and DRA72x
>>>> EVMs.
>>>>
>>>> Signed-off-by: Sekhar Nori <nsekhar at ti.com>
>>>> ---
>>>> Applies to tag for-v4.6/omap-hwmod-a of Paul W's tree.
>>>>
>>>>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++
>>>>  1 file changed, 23 insertions(+)
>>>>
>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>>> index b61355e2a771..252b74633e31 100644
>>>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>>> @@ -1526,8 +1526,31 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
>>>>   *
>>>>   */
>>>>  
>>>> +/*
>>>> + * As noted in documentation for _reset() in omap_hwmod.c, the stock reset
>>>> + * functionality of OMAP HWMOD layer does not deassert the hardreset lines
>>>> + * associated with an IP automatically leaving the driver to handle that
>>>> + * by itself. This does not work for PCIeSS which needs the reset lines
>>>> + * deasserted for the driver to start accessing registers.
>>>> + *
>>>> + * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset
>>>> + * lines after asserting them.
>>>> + */
>>>> +static int dra7xx_pciess_reset(struct omap_hwmod *oh)
>>>> +{
>>>> +	int i;
>>>> +
>>>> +	for (i = 0; i < oh->rst_lines_cnt; i++) {
>>>> +		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);
>>>> +		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);
>>>> +	}
>>>> +
>>>> +	return 0;
>>>> +}
>>>> +
>>>>  static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {
>>>>  	.name	= "pcie",
>>>> +	.reset	= dra7xx_pciess_reset,
>>>>  };
>>>
>>> Thanks for the patch.
>>
>> Could you please test the bind/unbind functionality just to make sure it 
>> works?
> 
> The pci-dra7xx driver neither expose the bind/unbind sysfs entry nor can be
> built as module.
> 
> However I hacked the pci-dra7xx driver to be built as module [and reverted
> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe error
> and driver unbind")] and I don't see an abort when the PCI registers are
> accessed after rmmod/modprobe cycle (that was the issue that Sekhar's patch
> tried to solve). However PCI as such doesn't work after rmmod/modprobe cycle
> [1], but this is a different issue most likely in PCIe core and has to debugged.
> 
> In summary, there are other issues in PCI across rmmod/modprobe cycle but the
> reset of pci-dra7xx happens fine with this patch.

Do you expect any other testing from me?

-Kishon

> 
> Thanks
> Kishon
> 
> [1] -> http://pastebin.ubuntu.com/15169387/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From mark.rutland at arm.com  Tue Feb 23 03:58:05 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 23 Feb 2016 11:58:05 +0000
Subject: [PATCH v12 1/5] efi: ARM/arm64: ignore DT memory nodes instead
 of removing them
In-Reply-To: <1456192703-2274-2-git-send-email-ddaney.cavm@gmail.com>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
 <1456192703-2274-2-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <20160223115805.GB4989@leverpostej>

Hi,

On Mon, Feb 22, 2016 at 05:58:19PM -0800, David Daney wrote:
> From: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> 
> There are two problems with the UEFI stub DT memory node removal
> routine:
> - it deletes nodes as it traverses the tree, which happens to work
>   but is not supported, as deletion invalidates the node iterator;
> - deleting memory nodes entirely may discard annotations in the form
>   of additional properties on the nodes.
> 
> Since the discovery of DT memory nodes occurs strictly before the
> UEFI init sequence, we can simply clear the memblock memory table
> before parsing the UEFI memory map. This way, it is no longer
> necessary to remove the nodes, so we can remove that logic from the
> stub as well.

This is a little bit scary, but I guess this works.

My only concern is that when we get kexec, a subsequent kernel must also
have EFI memory map support, or things go bad for the next EFI-aware
kernel after that (as things like the runtime services may have been
corrupted by the kernel in the middle). It's difficult to fix the
general case later.

A different option would be to support status="disabled" for the memory
nodes, and ignore these in early_init_dt_scan_memory. That way a kernel
cannot use memory without first having parsed the EFI memory map, and we
can still get NUMA info from the disabled nodes.

You'd still need a new kernel to take into account status, but at least
we'd know all kernels would avoid using RAM that potentially needs to be
preserved.

Ard, Rob, thoughts?

Mark.

> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> Signed-off-by: David Daney <david.daney at cavium.com>
> ---
>  drivers/firmware/efi/arm-init.c    |  8 ++++++++
>  drivers/firmware/efi/libstub/fdt.c | 24 +-----------------------
>  2 files changed, 9 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
> index 9e15d57..40c9d85 100644
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@ -143,6 +143,14 @@ static __init void reserve_regions(void)
>  	if (efi_enabled(EFI_DBG))
>  		pr_info("Processing EFI memory map:\n");
>  
> +	/*
> +	 * Discard memblocks discovered so far: if there are any at this
> +	 * point, they originate from memory nodes in the DT, and UEFI
> +	 * uses its own memory map instead.
> +	 */
> +	memblock_dump_all();
> +	memblock_remove(0, ULLONG_MAX);
> +
>  	for_each_efi_memory_desc(&memmap, md) {
>  		paddr = md->phys_addr;
>  		npages = md->num_pages;
> diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
> index cf7b7d4..9df1560 100644
> --- a/drivers/firmware/efi/libstub/fdt.c
> +++ b/drivers/firmware/efi/libstub/fdt.c
> @@ -24,7 +24,7 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
>  			unsigned long map_size, unsigned long desc_size,
>  			u32 desc_ver)
>  {
> -	int node, prev, num_rsv;
> +	int node, num_rsv;
>  	int status;
>  	u32 fdt_val32;
>  	u64 fdt_val64;
> @@ -54,28 +54,6 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
>  		goto fdt_set_fail;
>  
>  	/*
> -	 * Delete any memory nodes present. We must delete nodes which
> -	 * early_init_dt_scan_memory may try to use.
> -	 */
> -	prev = 0;
> -	for (;;) {
> -		const char *type;
> -		int len;
> -
> -		node = fdt_next_node(fdt, prev, NULL);
> -		if (node < 0)
> -			break;
> -
> -		type = fdt_getprop(fdt, node, "device_type", &len);
> -		if (type && strncmp(type, "memory", len) == 0) {
> -			fdt_del_node(fdt, node);
> -			continue;
> -		}
> -
> -		prev = node;
> -	}
> -
> -	/*
>  	 * Delete all memory reserve map entries. When booting via UEFI,
>  	 * kernel will use the UEFI memory map to find reserved regions.
>  	 */
> -- 
> 1.8.3.1
> 


From linux at arm.linux.org.uk  Tue Feb 23 03:58:35 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 23 Feb 2016 11:58:35 +0000
Subject: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB
 mappings
In-Reply-To: <CAKv+Gu9gwnuu7hnYpjv7ozuKYmC8ApMakSJmYvQMaevNEd5zvA@mail.gmail.com>
References: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456149728-16706-2-git-send-email-ard.biesheuvel@linaro.org>
 <CAPcyv4ivN9c8PHBR77vd36ovB28OETJUr6VYf_8gNtXgqEmATw@mail.gmail.com>
 <CAKv+Gu9OWVgo+Qm85jPjY7xJ1UELm-4LYORHKF8Yy+_HuzmtGw@mail.gmail.com>
 <20160222200227.GF19428@n2100.arm.linux.org.uk>
 <CAKv+Gu9gwnuu7hnYpjv7ozuKYmC8ApMakSJmYvQMaevNEd5zvA@mail.gmail.com>
Message-ID: <20160223115835.GI19428@n2100.arm.linux.org.uk>

On Mon, Feb 22, 2016 at 09:35:24PM +0100, Ard Biesheuvel wrote:
> OK, thanks for the historical context.
> 
> So what is your opinion on this series, i.e., to wire up memremap() to
> remap arbitrary memory regions into the vmalloc area with MT_MEMORY_RW
> attributes, and at the same time lift the restriction that the region
> must be disjoint from memory covered by lowmem or kmap?

The historical context is still present, because pxa2xx-flash has
been converted to use memremap() from ioremap_cache() - possibly
inappropriately.

I've already described the semantics of ioremap_cache(), which are
to always create a cacheable mapping irrespective of the system
memory mapping type.  However, memremap() says that MEMREMAP_WB
matches system RAM, which on ARM it doesn't right now.

Changing it to MT_MEMORY_RW would satisfy that comment against
memremap(), but at the same time changes what happens with
pxa2xx-flash - the memory region (which is not system RAM) then
changes with the cache status of system RAM.

So, I'm not that happy about the memremap() stuff right now, and
I don't like the idea of making memremap() conform to its stated
requirements without first preventing pxa2xx-flash being affected
by such a change.

Perhaps we need to reinstate the original ioremap_cached() API for
pxa2xx-flash, and then switch memremap() to MT_MEMORY_RW - that
would seem to result in the expected behaviour by all parties.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From linux at arm.linux.org.uk  Tue Feb 23 04:01:01 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 23 Feb 2016 12:01:01 +0000
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
Message-ID: <20160223120101.GJ19428@n2100.arm.linux.org.uk>

On Tue, Feb 23, 2016 at 11:56:34AM +0000, Peter Maydell wrote:
> On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> > I'm not quite sure how it works if, as in versatile display case, there
> > are multiple DT overlays of which one has to be enabled. I hope there's
> > support to choose which one to use via kernel cmdline or similar.
> >
> > I would personally like it much more if the bootloader would either
> > compose a final dtb from DT fragments and pass it to the kernel, or
> > alternatively the bootloader would pass the base dtb image and a bunch
> > of DT overlays to the kernel, and the kernel would deal with the DT
> > overlays.
> 
> Speaking as somebody who's written the "bootloader" code that's
> used for what I guess are the majority of versatile kernel boots,
> i.e. the one in QEMU, I think that requiring the bootloader to do this
> would be a significant worsening from the current state.
> 
> Right now the bootloader doesn't need to do much at all with device
> trees, except pass the kernel the DT that the user gave us, which
> is just the kernel's own data structures in a separate file for
> convenience. You need to do some very minor tweaks to the /chosen
> node, but these can be handled the same way for any board and aren't
> hardware specific. There's no need to worry about dt fragments
> either for the bootloader or for the user. Imposing a new requirement
> for the bootloader to have to probe hardware which it otherwise
> has no need to even care about, and then edit and update the DT
> in a board-specific manner, or have board-specific DT fragments,
> seems like a totally unnecessary imposition on both bootloader
> authors and end-users, and of course it would break booting newer
> kernels on the great mass of already existing boot loaders and
> QEMU installs.
> 
> The kernel is in a position to probe the display hardware and determine
> what is there, and do the right thing, and that's exactly what it
> does today. The kernel should continue to do this.
> The advantage of DT is that it allows moving information about
> non-probeable hardware that was previously hardwired in the kernel
> C sources into a separate data structure, but the versatile displays
> are not non-probeable. I can see no benefit at all from hardwiring into
> the dt something which the kernel has previously been successfully
> dynamically getting right without any bootloader intervention -- it just
> makes the kernel less flexible and less user-friendly.

+1.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From ynvich at gmail.com  Tue Feb 23 04:01:41 2016
From: ynvich at gmail.com (Sergei Ianovich)
Date: Tue, 23 Feb 2016 15:01:41 +0300
Subject: [PATCH v1] arm: pxa: fix DT node name for PXA27X usb
In-Reply-To: <87oab8wyfe.fsf@belgarion.home>
References: <1456139297-5854-1-git-send-email-ynvich@gmail.com>
 <87oab8wyfe.fsf@belgarion.home>
Message-ID: <1456228901.23036.9.camel@gmail.com>

Hi Robert,?

On Mon, 2016-02-22 at 16:35 +0100, Robert Jarzmik wrote:
> You're right, I haven't seen the pxa2xx.dtsi statement before.
> 
> As such, could you amend a bit your patch please to :
> ?- add:
> Fixes: 0ec1939668e5 ("ARM: dts: pxa: add the usb host controller")
> ?- make the same change in pxa3xx.dtsi, as the same error is there
> ?- and more globally align pxa2xx.dtsi, pxa27x.dtsi and pxa3xx.dtsi
> ?- remove the compatible, reg, interrupts and status from both pxa27x.dtsi and
> ???pxa3xx.dtsi as they are redundant with the included pxa2xxx.dsti one

No problem. Let's figure out the best approach.

> I'm even wondering if the proper change wouldn't be to scrap the ohci
> declarations from pxa27x.dtsi and pxa3xx.dtsi, and only add the "clocks"
> property to pxa2xx.dtsi ...

Since clocks are declared in pxa27x.dtsi and?pxa3xx.dtsi, there is a
stronger ground to have node clocks properties set in pxa27x.dtsi
and?pxa3xx.dtsi as well. However, there is already nodes with clocks
properties in pxa2xx.dtsi.

I cannot choose, you should make a decision.


-- 
Sergei Ianovich <ynvich at gmail.com>



From k.kozlowski at samsung.com  Tue Feb 23 04:02:16 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Tue, 23 Feb 2016 21:02:16 +0900
Subject: [PATCH] ARM: dts: add support for gpio buttons for
 exynos5422-odroidxu3
In-Reply-To: <CANAwSgTRu6pb9cdA50AzBSNLS+Y+sssyc_CX7FKuV=FDYWaOsA@mail.gmail.com>
References: <1456214467-3344-1-git-send-email-linux.amoon@gmail.com>
 <56CC167A.8040303@samsung.com> <56CC194F.6080905@samsung.com>
 <CANAwSgTRu6pb9cdA50AzBSNLS+Y+sssyc_CX7FKuV=FDYWaOsA@mail.gmail.com>
Message-ID: <CAJKOXPftm7P44Zxn9rHt1THJOX3Oxu-mg5GD7=T3se4iRe1DkA@mail.gmail.com>

2016-02-23 18:17 GMT+09:00 Anand Moon <linux.amoon at gmail.com>:
> Hi Krzysztof,
>
> On 23 February 2016 at 14:03, Krzysztof Kozlowski
>>>>      };
>>>> +
>>>> +    gpio_keys {
>>>> +            compatible = "gpio-keys";
>>>> +            pinctrl-names = "default";
>>>> +            pinctrl-0 = <&gpio_power_key>;
>>>> +
>>>> +            power_key {
>>>> +                    interrupt-parent = <&gpx0>;
>>>> +                    interrupts = <3 IRQ_TYPE_NONE>;
>>>
>>> Hmmm.... why you specify the interrupts?
>>>
>>>> +                    gpios = <&gpx0 3 GPIO_ACTIVE_LOW>;
>>
>> Please, explain it to me. The SW2 key is connected to PWRON of PMIC.
>> However you are adding a GPIO key for external interrupt source 3
>> (XE.INT3)... which comes from PMIC's ONOB.
>>
>> It's interesting.... how does it work? The PMIC will generate ONOB
>> interrupt on PWRON low->high change (when PWRHOLD is high)?
>>
>> Best regards,
>> Krzysztof
>>
>
> I have re-base my changes on HK dts.
> I could not find much details for the schematic diagram.
> I don't know much low level detains on this.

If I understand this correctly: you just took some vendor code,
similar to existing code of Odroid U3, and without full understanding
of the code nor checking with public schematics, you sent it.

Taking vendor stuff is okay but you need to think about it, use it as
an example and deliver proper solution based on that. Not copy-paste.

> How dose this works: This changes will initial the shudown/reboot on Ubuntu.
> I have also tested this similar feature on Odroid U3.

Great :), yes it works because ONOB interrupt from PMIC is generated
on key press. However this is not a strictly speaking key... I don't
really know what to do with this commit and your explanation
(Hardkernel has such code) is not sufficient to convince me.

Best regards,
Krzysztof


From ard.biesheuvel at linaro.org  Tue Feb 23 04:03:14 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 23 Feb 2016 13:03:14 +0100
Subject: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB
 mappings
In-Reply-To: <20160223115835.GI19428@n2100.arm.linux.org.uk>
References: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456149728-16706-2-git-send-email-ard.biesheuvel@linaro.org>
 <CAPcyv4ivN9c8PHBR77vd36ovB28OETJUr6VYf_8gNtXgqEmATw@mail.gmail.com>
 <CAKv+Gu9OWVgo+Qm85jPjY7xJ1UELm-4LYORHKF8Yy+_HuzmtGw@mail.gmail.com>
 <20160222200227.GF19428@n2100.arm.linux.org.uk>
 <CAKv+Gu9gwnuu7hnYpjv7ozuKYmC8ApMakSJmYvQMaevNEd5zvA@mail.gmail.com>
 <20160223115835.GI19428@n2100.arm.linux.org.uk>
Message-ID: <CAKv+Gu8oCnu6kv5SxUAdWE_Z0V+PMAKDgM6MxTi4mTm5z6EFqA@mail.gmail.com>

On 23 February 2016 at 12:58, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Mon, Feb 22, 2016 at 09:35:24PM +0100, Ard Biesheuvel wrote:
>> OK, thanks for the historical context.
>>
>> So what is your opinion on this series, i.e., to wire up memremap() to
>> remap arbitrary memory regions into the vmalloc area with MT_MEMORY_RW
>> attributes, and at the same time lift the restriction that the region
>> must be disjoint from memory covered by lowmem or kmap?
>
> The historical context is still present, because pxa2xx-flash has
> been converted to use memremap() from ioremap_cache() - possibly
> inappropriately.
>
> I've already described the semantics of ioremap_cache(), which are
> to always create a cacheable mapping irrespective of the system
> memory mapping type.  However, memremap() says that MEMREMAP_WB
> matches system RAM, which on ARM it doesn't right now.
>

Indeed. Hence this series, to decouple memremap(MEMREMAP_WB) from
ioremap_cache() for ARM

> Changing it to MT_MEMORY_RW would satisfy that comment against
> memremap(), but at the same time changes what happens with
> pxa2xx-flash - the memory region (which is not system RAM) then
> changes with the cache status of system RAM.
>
> So, I'm not that happy about the memremap() stuff right now, and
> I don't like the idea of making memremap() conform to its stated
> requirements without first preventing pxa2xx-flash being affected
> by such a change.
>

Actually, my change fixes this issue, since it will cause memremap()
to always create MT_MEMORY_RW mappings, and not fallback to
ioremap_cache() for ranges that are not covered by lowmem.

> Perhaps we need to reinstate the original ioremap_cached() API for
> pxa2xx-flash, and then switch memremap() to MT_MEMORY_RW - that
> would seem to result in the expected behaviour by all parties.
>

I think we can simply revert the change to pxa2xx-flash if it is
deemed inappropriate.


From catalin.marinas at arm.com  Tue Feb 23 04:14:36 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Feb 2016 12:14:36 +0000
Subject: [RFC PATCH 01/10] arm64: mm: move assignment of 'high_memory'
 before its first use
In-Reply-To: <1456174472-30028-2-git-send-email-ard.biesheuvel@linaro.org>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456174472-30028-2-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160223121435.GA4777@e104818-lin.cambridge.arm.com>

On Mon, Feb 22, 2016 at 09:54:23PM +0100, Ard Biesheuvel wrote:
> The variable 'high_memory' ends up being referenced in the call to
> dma_contiguous_reserve(). So move the assignment before that call.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>

Does this need cc stable? It looks like we've had this issue for a while
and it ends up being used in cma_declare_contiguous(). So we either get
a high enough value to not affect this function or we don't trigger this
code path very often.

-- 
Catalin


From will.deacon at arm.com  Tue Feb 23 04:16:49 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Feb 2016 12:16:49 +0000
Subject: [PATCH v12 1/5] efi: ARM/arm64: ignore DT memory nodes instead
 of removing them
In-Reply-To: <20160223115805.GB4989@leverpostej>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
 <1456192703-2274-2-git-send-email-ddaney.cavm@gmail.com>
 <20160223115805.GB4989@leverpostej>
Message-ID: <20160223121648.GI3966@arm.com>

On Tue, Feb 23, 2016 at 11:58:05AM +0000, Mark Rutland wrote:
> On Mon, Feb 22, 2016 at 05:58:19PM -0800, David Daney wrote:
> > From: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> > 
> > There are two problems with the UEFI stub DT memory node removal
> > routine:
> > - it deletes nodes as it traverses the tree, which happens to work
> >   but is not supported, as deletion invalidates the node iterator;
> > - deleting memory nodes entirely may discard annotations in the form
> >   of additional properties on the nodes.
> > 
> > Since the discovery of DT memory nodes occurs strictly before the
> > UEFI init sequence, we can simply clear the memblock memory table
> > before parsing the UEFI memory map. This way, it is no longer
> > necessary to remove the nodes, so we can remove that logic from the
> > stub as well.
> 
> This is a little bit scary, but I guess this works.
> 
> My only concern is that when we get kexec, a subsequent kernel must also
> have EFI memory map support, or things go bad for the next EFI-aware
> kernel after that (as things like the runtime services may have been
> corrupted by the kernel in the middle). It's difficult to fix the
> general case later.
> 
> A different option would be to support status="disabled" for the memory
> nodes, and ignore these in early_init_dt_scan_memory. That way a kernel
> cannot use memory without first having parsed the EFI memory map, and we
> can still get NUMA info from the disabled nodes.

So in that case, the middle, non-EFI kernel would fail to boot?
Realistically, once you've kexec'd a non-EFI payload, I don't think you
can rely on the EFI state remaining intact for future EFI applications.

Is this really something we should be trying to police in the kernel?

Will


From ard.biesheuvel at linaro.org  Tue Feb 23 04:18:12 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 23 Feb 2016 13:18:12 +0100
Subject: [RFC PATCH 01/10] arm64: mm: move assignment of 'high_memory'
 before its first use
In-Reply-To: <20160223121435.GA4777@e104818-lin.cambridge.arm.com>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456174472-30028-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160223121435.GA4777@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu9ceu3sBUCemq6DK7frYh7vKDOPGvHswQw4JCVOA6AvZA@mail.gmail.com>

On 23 February 2016 at 13:14, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 22, 2016 at 09:54:23PM +0100, Ard Biesheuvel wrote:
>> The variable 'high_memory' ends up being referenced in the call to
>> dma_contiguous_reserve(). So move the assignment before that call.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>
> Does this need cc stable? It looks like we've had this issue for a while
> and it ends up being used in cma_declare_contiguous(). So we either get
> a high enough value to not affect this function or we don't trigger this
> code path very often.
>

I would guess cc'ing stable would be appropriate, although I think
keeping it at 0x0 has no ill side effects, other than that the CMA
layer cannot figure out if the allocation is entirely above or
entirely below the highmem limit, and of course, that is kind of moot
on arm64

I haven't noticed any runtime changes with this fixed


From robin.murphy at arm.com  Tue Feb 23 04:19:20 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Tue, 23 Feb 2016 12:19:20 +0000
Subject: [PATCH V2] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <56CC4E48.1060103@arm.com>

On 18/02/16 18:29, tchalamarla at caviumnetworks.com wrote:
> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>
> Due to Errata#27704 CN88xx SMMUv2,supports  only shared ASID and VMID
> namespaces; specifically within a given node SMMU0 and SMMU1 share,
> as does SMMU2 and SMMU3.
>
> This patch tries to address these issuee by supplying asid and vmid
> base from devicetree.
>
> changes from V1:
> 	- rebased on top of 16 bit VMID patch
> 	- removed redundent options from DT
> 	- insted of transform, DT now supplies starting ASID/VMID
>
> Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> ---
>   .../devicetree/bindings/iommu/arm,smmu.txt         |  8 +++++
>   drivers/iommu/arm-smmu.c                           | 37 +++++++++++++++-------
>   2 files changed, 34 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index bb7e569..80b8484 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -57,6 +57,14 @@ conditions.
>
>   - smmu-enable-vmid16 : Enable 16 bit VMID, if allowed.
>
> +- asid-base :	Buggy SMMUv2 implementations which doesn't satisfy the
> +		ASID namespace needs, use this field to specify starting
> +		ASID for the SMMU.
> +
> +- vmid-base :	Buggy SMMUv2 implementations which doesn't satisfy the VMID
> +		namespace needs, use this field to specify starting VMID
> +		for the SMMU.
> +

 From how you've described the situation, this is still just some 
arbitrary number for the sake of a driver workaround and not an actual 
property of the hardware. Either way there should be a proper compatible 
string for this implementation, e.g. something like "cavium,cn88xx-smmu".

Given that, you then shouldn't actually need anything else, because you 
can simply keep track of how many Cavium SMMUs have been probed and 
automatically generate a suitable offset, e.g. (smmu->index * 
ARM_SMMU_MAX_CBS) to ensure global ASID/VMID uniqueness.

Robin.

>   Example:
>
>           smmu {
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 003c442..dc46b9a 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -320,6 +320,9 @@ struct arm_smmu_device {
>   	unsigned long			ipa_size;
>   	unsigned long			pa_size;
>
> +	u32				asid_base;
> +	u32				vmid_base;
> +
>   	u32				num_global_irqs;
>   	u32				num_context_irqs;
>   	unsigned int			*irqs;
> @@ -335,8 +338,8 @@ struct arm_smmu_cfg {
>   };
>   #define INVALID_IRPTNDX			0xff
>
> -#define ARM_SMMU_CB_ASID(cfg)		((cfg)->cbndx)
> -#define ARM_SMMU_CB_VMID(cfg)		((cfg)->cbndx + 1)
> +#define ARM_SMMU_CB_ASID(smmu, cfg)	((u16)((smmu)->asid_base + (cfg)->cbndx))
> +#define ARM_SMMU_CB_VMID(smmu, cfg)	((u16)((smmu)->vmid_base + (cfg)->cbndx))
>
>   enum arm_smmu_domain_stage {
>   	ARM_SMMU_DOMAIN_S1 = 0,
> @@ -576,11 +579,11 @@ static void arm_smmu_tlb_inv_context(void *cookie)
>
>   	if (stage1) {
>   		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
> -		writel_relaxed(ARM_SMMU_CB_ASID(cfg),
> +		writel_relaxed(ARM_SMMU_CB_ASID(smmu, cfg),
>   			       base + ARM_SMMU_CB_S1_TLBIASID);
>   	} else {
>   		base = ARM_SMMU_GR0(smmu);
> -		writel_relaxed(ARM_SMMU_CB_VMID(cfg),
> +		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg),
>   			       base + ARM_SMMU_GR0_TLBIVMID);
>   	}
>
> @@ -602,7 +605,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>
>   		if (!IS_ENABLED(CONFIG_64BIT) || smmu->version == ARM_SMMU_V1) {
>   			iova &= ~12UL;
> -			iova |= ARM_SMMU_CB_ASID(cfg);
> +			iova |= ARM_SMMU_CB_ASID(smmu, cfg);
>   			do {
>   				writel_relaxed(iova, reg);
>   				iova += granule;
> @@ -610,7 +613,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>   #ifdef CONFIG_64BIT
>   		} else {
>   			iova >>= 12;
> -			iova |= (u64)ARM_SMMU_CB_ASID(cfg) << 48;
> +			iova |= (u64)ARM_SMMU_CB_ASID(smmu, cfg) << 48;
>   			do {
>   				writeq_relaxed(iova, reg);
>   				iova += granule >> 12;
> @@ -630,7 +633,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
>   #endif
>   	} else {
>   		reg = ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_TLBIVMID;
> -		writel_relaxed(ARM_SMMU_CB_VMID(cfg), reg);
> +		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg), reg);
>   	}
>   }
>
> @@ -744,7 +747,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>   #endif
>   		/* if 16bit VMID required set VMID in CBA2R */
>   		if (smmu->options & ARM_SMMU_OPT_ENABLE_VMID16)
> -			reg |= ARM_SMMU_CB_VMID(cfg) << CBA2R_VMID_SHIFT;
> +			reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBA2R_VMID_SHIFT;
>
>   		writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBA2R(cfg->cbndx));
>   	}
> @@ -763,7 +766,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>   			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
>   	} else if (!(smmu->options & ARM_SMMU_OPT_ENABLE_VMID16)) {
>   		/*16 bit VMID is not enabled set 8 bit VMID here */
> -		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
> +		reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBAR_VMID_SHIFT;
>   	}
>   	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
>
> @@ -771,11 +774,11 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>   	if (stage1) {
>   		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>
> -		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
> +		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
>   		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR0);
>
>   		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
> -		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
> +		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
>   		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR1);
>   	} else {
>   		reg64 = pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
> @@ -1812,6 +1815,18 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
>
>   	parse_driver_options(smmu);
>
> +	if (of_property_read_u32(dev->of_node, "#asid-base",
> +				 &smmu->asid_base)) {
> +		smmu->asid_base = 0;
> +	}
> +
> +	if (of_property_read_u32(dev->of_node, "#vmid-base",
> +				 &smmu->vmid_base)) {
> +		smmu->vmid_base = 1;
> +	}
> +	if (smmu->vmid_base == 0)
> +		smmu->vmid_base = 1;
> +
>   	if (smmu->version > ARM_SMMU_V1 &&
>   	    smmu->num_context_banks != smmu->num_context_irqs) {
>   		dev_err(dev,
>



From ard.biesheuvel at linaro.org  Tue Feb 23 04:20:10 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 23 Feb 2016 13:20:10 +0100
Subject: [PATCH v12 1/5] efi: ARM/arm64: ignore DT memory nodes instead of
 removing them
In-Reply-To: <20160223121648.GI3966@arm.com>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
 <1456192703-2274-2-git-send-email-ddaney.cavm@gmail.com>
 <20160223115805.GB4989@leverpostej> <20160223121648.GI3966@arm.com>
Message-ID: <CAKv+Gu8fOKqLrnbre7sHko+hPd3wq_O6U5Ev27tN3zEc7W8Mww@mail.gmail.com>

On 23 February 2016 at 13:16, Will Deacon <will.deacon at arm.com> wrote:
> On Tue, Feb 23, 2016 at 11:58:05AM +0000, Mark Rutland wrote:
>> On Mon, Feb 22, 2016 at 05:58:19PM -0800, David Daney wrote:
>> > From: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> >
>> > There are two problems with the UEFI stub DT memory node removal
>> > routine:
>> > - it deletes nodes as it traverses the tree, which happens to work
>> >   but is not supported, as deletion invalidates the node iterator;
>> > - deleting memory nodes entirely may discard annotations in the form
>> >   of additional properties on the nodes.
>> >
>> > Since the discovery of DT memory nodes occurs strictly before the
>> > UEFI init sequence, we can simply clear the memblock memory table
>> > before parsing the UEFI memory map. This way, it is no longer
>> > necessary to remove the nodes, so we can remove that logic from the
>> > stub as well.
>>
>> This is a little bit scary, but I guess this works.
>>
>> My only concern is that when we get kexec, a subsequent kernel must also
>> have EFI memory map support, or things go bad for the next EFI-aware
>> kernel after that (as things like the runtime services may have been
>> corrupted by the kernel in the middle). It's difficult to fix the
>> general case later.
>>
>> A different option would be to support status="disabled" for the memory
>> nodes, and ignore these in early_init_dt_scan_memory. That way a kernel
>> cannot use memory without first having parsed the EFI memory map, and we
>> can still get NUMA info from the disabled nodes.
>
> So in that case, the middle, non-EFI kernel would fail to boot?
> Realistically, once you've kexec'd a non-EFI payload, I don't think you
> can rely on the EFI state remaining intact for future EFI applications.
>
> Is this really something we should be trying to police in the kernel?
>

Well, we could add entries to /reserved-memory in the stub for all the
regions UEFI cares about, that would probably be sufficient to fix
this case.


From will.deacon at arm.com  Tue Feb 23 04:26:15 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Feb 2016 12:26:15 +0000
Subject: [RFC PATCH 10/10] arm64: mm: restrict __pa() translations to
 linear virtual addresses
In-Reply-To: <1456174472-30028-11-git-send-email-ard.biesheuvel@linaro.org>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456174472-30028-11-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160223122615.GJ3966@arm.com>

On Mon, Feb 22, 2016 at 09:54:32PM +0100, Ard Biesheuvel wrote:
> Now that we have replaced all occurrences of __pa() translations
> involving virtual addresses that are covered by the kernel text,
> we can redefine __virt_to_phys and __pa() etc to only take virtual
> address that are covered by the linear mapping. This means we can
> remove the comparison with PAGE_OFFSET in the definition of
> __virt_to_phys().
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
>  arch/arm64/include/asm/memory.h | 12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 56d6739430f3..3b5dc5b243ac 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -86,11 +86,14 @@
>   * private definitions which should NOT be used outside memory.h
>   * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
>   */
> -#define __virt_to_phys(x) ({						\
> +#ifndef CONFIG_DEBUG_VM
> +#define __virt_to_phys(x)	(((phys_addr_t)(x) & ~PAGE_OFFSET) + PHYS_OFFSET)
> +#else
> +#define __virt_to_phys(x)	({					\
>  	phys_addr_t __x = (phys_addr_t)(x);				\
> -	__x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET :	\
> -				 (__x - kimage_voffset); })
> -
> +	BUG_ON(__x < PAGE_OFFSET);					\
> +	(((phys_addr_t)__x & ~PAGE_OFFSET) + PHYS_OFFSET); })

What's the #include-hell like if you try to use VM_BUG_ON instead?

Will


From ard.biesheuvel at linaro.org  Tue Feb 23 04:26:13 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 23 Feb 2016 13:26:13 +0100
Subject: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB
 mappings
In-Reply-To: <CAKv+Gu8oCnu6kv5SxUAdWE_Z0V+PMAKDgM6MxTi4mTm5z6EFqA@mail.gmail.com>
References: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456149728-16706-2-git-send-email-ard.biesheuvel@linaro.org>
 <CAPcyv4ivN9c8PHBR77vd36ovB28OETJUr6VYf_8gNtXgqEmATw@mail.gmail.com>
 <CAKv+Gu9OWVgo+Qm85jPjY7xJ1UELm-4LYORHKF8Yy+_HuzmtGw@mail.gmail.com>
 <20160222200227.GF19428@n2100.arm.linux.org.uk>
 <CAKv+Gu9gwnuu7hnYpjv7ozuKYmC8ApMakSJmYvQMaevNEd5zvA@mail.gmail.com>
 <20160223115835.GI19428@n2100.arm.linux.org.uk>
 <CAKv+Gu8oCnu6kv5SxUAdWE_Z0V+PMAKDgM6MxTi4mTm5z6EFqA@mail.gmail.com>
Message-ID: <CAKv+Gu_iEOC6E+N28pp9eEJxWFYTgLaQcBYEy1SvTUHT=cybYA@mail.gmail.com>

On 23 February 2016 at 13:03, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 23 February 2016 at 12:58, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
>> On Mon, Feb 22, 2016 at 09:35:24PM +0100, Ard Biesheuvel wrote:
>>> OK, thanks for the historical context.
>>>
>>> So what is your opinion on this series, i.e., to wire up memremap() to
>>> remap arbitrary memory regions into the vmalloc area with MT_MEMORY_RW
>>> attributes, and at the same time lift the restriction that the region
>>> must be disjoint from memory covered by lowmem or kmap?
>>
>> The historical context is still present, because pxa2xx-flash has
>> been converted to use memremap() from ioremap_cache() - possibly
>> inappropriately.
>>
>> I've already described the semantics of ioremap_cache(), which are
>> to always create a cacheable mapping irrespective of the system
>> memory mapping type.  However, memremap() says that MEMREMAP_WB
>> matches system RAM, which on ARM it doesn't right now.
>>
>
> Indeed. Hence this series, to decouple memremap(MEMREMAP_WB) from
> ioremap_cache() for ARM
>
>> Changing it to MT_MEMORY_RW would satisfy that comment against
>> memremap(), but at the same time changes what happens with
>> pxa2xx-flash - the memory region (which is not system RAM) then
>> changes with the cache status of system RAM.
>>
>> So, I'm not that happy about the memremap() stuff right now, and
>> I don't like the idea of making memremap() conform to its stated
>> requirements without first preventing pxa2xx-flash being affected
>> by such a change.
>>
>
> Actually, my change fixes this issue, since it will cause memremap()
> to always create MT_MEMORY_RW mappings, and not fallback to
> ioremap_cache() for ranges that are not covered by lowmem.
>
>> Perhaps we need to reinstate the original ioremap_cached() API for
>> pxa2xx-flash, and then switch memremap() to MT_MEMORY_RW - that
>> would seem to result in the expected behaviour by all parties.
>>
>
> I think we can simply revert the change to pxa2xx-flash if it is
> deemed inappropriate.

OK, I see what you mean. I find it unfortunate that ioremap_cache()
instances are blindly being replaced with memremap(), and I wonder if
this wasted test by and/or cc'ed to people who can actually test this
driver. Dan?

Anyway, I don't think it makes sense to stipulate at the generic level
that ioremap_cache() and memremap(MEMREMAP_WB) shall be the same, and
deprecating it is a bit premature since the cross-architecturally
loosely defined semantics of ioremap_cache() can never be replaced 1:1
with what memremap() promises.

So what I suggest is that I revert the change to pxa2xx-flash as a new
1/3 in this series, and put these existing two on top to decouple
memremap(MEMREMAP_WB) from ioremap_cache() entirely.

Thanks,
Ard.


From mark.rutland at arm.com  Tue Feb 23 04:26:17 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 23 Feb 2016 12:26:17 +0000
Subject: [PATCH V2] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <20160223122616.GE4989@leverpostej>

On Thu, Feb 18, 2016 at 10:29:18AM -0800, tchalamarla at caviumnetworks.com wrote:
> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> 
> Due to Errata#27704 CN88xx SMMUv2,supports  only shared ASID and VMID
> namespaces; specifically within a given node SMMU0 and SMMU1 share,
> as does SMMU2 and SMMU3.
> 
> This patch tries to address these issuee by supplying asid and vmid
> base from devicetree.
> 
> changes from V1:
> 	- rebased on top of 16 bit VMID patch
> 	- removed redundent options from DT
> 	- insted of transform, DT now supplies starting ASID/VMID
> 
> Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> ---
>  .../devicetree/bindings/iommu/arm,smmu.txt         |  8 +++++
>  drivers/iommu/arm-smmu.c                           | 37 +++++++++++++++-------
>  2 files changed, 34 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index bb7e569..80b8484 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -57,6 +57,14 @@ conditions.
>  
>  - smmu-enable-vmid16 : Enable 16 bit VMID, if allowed.
>  
> +- asid-base :	Buggy SMMUv2 implementations which doesn't satisfy the
> +		ASID namespace needs, use this field to specify starting
> +		ASID for the SMMU.
> +
> +- vmid-base :	Buggy SMMUv2 implementations which doesn't satisfy the VMID
> +		namespace needs, use this field to specify starting VMID
> +		for the SMMU.

As has been pointed out, these are not strictly properties of the
hardware, and are insufficient to aovid the issue in general (adding an
arbitrary base does not enforce IDs fall within a particular range).

So NAK for *-base properties alone.

> +	if (of_property_read_u32(dev->of_node, "#asid-base",
> +				 &smmu->asid_base)) {
> +		smmu->asid_base = 0;
> +	}
> +
> +	if (of_property_read_u32(dev->of_node, "#vmid-base",
> +				 &smmu->vmid_base)) {
> +		smmu->vmid_base = 1;
> +	}

These do not match the documentation above.

Mark.


From ard.biesheuvel at linaro.org  Tue Feb 23 04:29:21 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 23 Feb 2016 13:29:21 +0100
Subject: [RFC PATCH 10/10] arm64: mm: restrict __pa() translations to
 linear virtual addresses
In-Reply-To: <20160223122615.GJ3966@arm.com>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456174472-30028-11-git-send-email-ard.biesheuvel@linaro.org>
 <20160223122615.GJ3966@arm.com>
Message-ID: <CAKv+Gu_zdt-sk_moCeF8u95DCZgcT26CDH1gL87Q4qXKA_hKrg@mail.gmail.com>

On 23 February 2016 at 13:26, Will Deacon <will.deacon at arm.com> wrote:
> On Mon, Feb 22, 2016 at 09:54:32PM +0100, Ard Biesheuvel wrote:
>> Now that we have replaced all occurrences of __pa() translations
>> involving virtual addresses that are covered by the kernel text,
>> we can redefine __virt_to_phys and __pa() etc to only take virtual
>> address that are covered by the linear mapping. This means we can
>> remove the comparison with PAGE_OFFSET in the definition of
>> __virt_to_phys().
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> ---
>>  arch/arm64/include/asm/memory.h | 12 +++++++-----
>>  1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index 56d6739430f3..3b5dc5b243ac 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -86,11 +86,14 @@
>>   * private definitions which should NOT be used outside memory.h
>>   * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
>>   */
>> -#define __virt_to_phys(x) ({                                         \
>> +#ifndef CONFIG_DEBUG_VM
>> +#define __virt_to_phys(x)    (((phys_addr_t)(x) & ~PAGE_OFFSET) + PHYS_OFFSET)
>> +#else
>> +#define __virt_to_phys(x)    ({                                      \
>>       phys_addr_t __x = (phys_addr_t)(x);                             \
>> -     __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET :   \
>> -                              (__x - kimage_voffset); })
>> -
>> +     BUG_ON(__x < PAGE_OFFSET);                                      \
>> +     (((phys_addr_t)__x & ~PAGE_OFFSET) + PHYS_OFFSET); })
>
> What's the #include-hell like if you try to use VM_BUG_ON instead?
>

The #include hell would not change I think, since

include/linux/mmdebug.h:18:#define VM_BUG_ON(cond) BUG_ON(cond)

but it would certainly make this code look a lot cleaner.


From will.deacon at arm.com  Tue Feb 23 04:31:51 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Feb 2016 12:31:51 +0000
Subject: [RFC PATCH 10/10] arm64: mm: restrict __pa() translations to
 linear virtual addresses
In-Reply-To: <CAKv+Gu_zdt-sk_moCeF8u95DCZgcT26CDH1gL87Q4qXKA_hKrg@mail.gmail.com>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456174472-30028-11-git-send-email-ard.biesheuvel@linaro.org>
 <20160223122615.GJ3966@arm.com>
 <CAKv+Gu_zdt-sk_moCeF8u95DCZgcT26CDH1gL87Q4qXKA_hKrg@mail.gmail.com>
Message-ID: <20160223123151.GK3966@arm.com>

On Tue, Feb 23, 2016 at 01:29:21PM +0100, Ard Biesheuvel wrote:
> On 23 February 2016 at 13:26, Will Deacon <will.deacon at arm.com> wrote:
> > On Mon, Feb 22, 2016 at 09:54:32PM +0100, Ard Biesheuvel wrote:
> >> Now that we have replaced all occurrences of __pa() translations
> >> involving virtual addresses that are covered by the kernel text,
> >> we can redefine __virt_to_phys and __pa() etc to only take virtual
> >> address that are covered by the linear mapping. This means we can
> >> remove the comparison with PAGE_OFFSET in the definition of
> >> __virt_to_phys().
> >>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >> ---
> >>  arch/arm64/include/asm/memory.h | 12 +++++++-----
> >>  1 file changed, 7 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> >> index 56d6739430f3..3b5dc5b243ac 100644
> >> --- a/arch/arm64/include/asm/memory.h
> >> +++ b/arch/arm64/include/asm/memory.h
> >> @@ -86,11 +86,14 @@
> >>   * private definitions which should NOT be used outside memory.h
> >>   * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
> >>   */
> >> -#define __virt_to_phys(x) ({                                         \
> >> +#ifndef CONFIG_DEBUG_VM
> >> +#define __virt_to_phys(x)    (((phys_addr_t)(x) & ~PAGE_OFFSET) + PHYS_OFFSET)
> >> +#else
> >> +#define __virt_to_phys(x)    ({                                      \
> >>       phys_addr_t __x = (phys_addr_t)(x);                             \
> >> -     __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET :   \
> >> -                              (__x - kimage_voffset); })
> >> -
> >> +     BUG_ON(__x < PAGE_OFFSET);                                      \
> >> +     (((phys_addr_t)__x & ~PAGE_OFFSET) + PHYS_OFFSET); })
> >
> > What's the #include-hell like if you try to use VM_BUG_ON instead?
> >
> 
> The #include hell would not change I think, since
> 
> include/linux/mmdebug.h:18:#define VM_BUG_ON(cond) BUG_ON(cond)
> 
> but it would certainly make this code look a lot cleaner.

Yup, and likewise for PHYS_OFFSET.

Will


From will.deacon at arm.com  Tue Feb 23 04:33:22 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Feb 2016 12:33:22 +0000
Subject: [GIT PULL] iommu/arm-smmu: Updates for 4.6
Message-ID: <20160223123322.GL3966@arm.com>

Hi Joerg,

Please pull the following arm-smmu updates for 4.6. This lays the
foundations for a functional IOMMU_DOMAIN_DMA for the two drivers,
although we haven't yet thrown the switch since we need to ensure
that the DMA ops all point in the right direction first. Hopefully we'll
get that going for 4.7.

Will

--->8

The following changes since commit 18558cae0272f8fd9647e69d3fec1565a7949865:

  Linux 4.5-rc4 (2016-02-14 13:05:20 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-joerg/arm-smmu/updates

for you to fetch changes up to cbf8277ef4562075eb4e3932ccd60cc11ee9454c:

  iommu/arm-smmu: Treat IOMMU_DOMAIN_DMA as bypass for now (2016-02-18 15:02:44 +0000)

----------------------------------------------------------------
Anup Patel (1):
      of: iommu: Increment DT node refcount in of_iommu_set_ops()

Robin Murphy (3):
      iommu/arm-smmu: Treat all device transactions as unprivileged
      iommu/arm-smmu: Support DMA-API domains
      iommu/arm-smmu: Allow disabling unmatched stream bypass

Will Deacon (2):
      iommu/arm-smmu: Don't fail device attach if already attached to a domain
      iommu/arm-smmu: Treat IOMMU_DOMAIN_DMA as bypass for now

 drivers/iommu/arm-smmu-v3.c | 50 +++++++++++++++-------------
 drivers/iommu/arm-smmu.c    | 79 ++++++++++++++++++++++++++++-----------------
 drivers/iommu/of_iommu.c    |  1 +
 3 files changed, 78 insertions(+), 52 deletions(-)


From john at metanate.com  Tue Feb 23 04:39:41 2016
From: john at metanate.com (John Keeping)
Date: Tue, 23 Feb 2016 12:39:41 +0000
Subject: [PATCH] ARM: dts: rockchip: add mipi_dsi to VIO power domain on rk3288
Message-ID: <1456231181-13989-1-git-send-email-john@metanate.com>

The MIPI controllers are part of the VIO power domain so add the
necessary property to indicate this for the controller we support.

Signed-off-by: John Keeping <john at metanate.com>
---
 arch/arm/boot/dts/rk3288.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index d879a89..a92a3b5 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -890,6 +890,7 @@
 		clocks = <&cru SCLK_MIPIDSI_24M>, <&cru PCLK_MIPI_DSI0>;
 		clock-names = "ref", "pclk";
 		rockchip,grf = <&grf>;
+		power-domains = <&power RK3288_PD_VIO>;
 		status = "disabled";
 
 		ports {
-- 
2.7.0.226.gfe986fe



From tomi.valkeinen at ti.com  Tue Feb 23 04:45:30 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 23 Feb 2016 14:45:30 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
Message-ID: <56CC546A.9070705@ti.com>

On 23/02/16 13:56, Peter Maydell wrote:
> On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
>> I'm not quite sure how it works if, as in versatile display case, there
>> are multiple DT overlays of which one has to be enabled. I hope there's
>> support to choose which one to use via kernel cmdline or similar.
>>
>> I would personally like it much more if the bootloader would either
>> compose a final dtb from DT fragments and pass it to the kernel, or
>> alternatively the bootloader would pass the base dtb image and a bunch
>> of DT overlays to the kernel, and the kernel would deal with the DT
>> overlays.
> 
> Speaking as somebody who's written the "bootloader" code that's
> used for what I guess are the majority of versatile kernel boots,
> i.e. the one in QEMU, I think that requiring the bootloader to do this
> would be a significant worsening from the current state.
> 
> Right now the bootloader doesn't need to do much at all with device
> trees, except pass the kernel the DT that the user gave us, which
> is just the kernel's own data structures in a separate file for
> convenience. You need to do some very minor tweaks to the /chosen
> node, but these can be handled the same way for any board and aren't
> hardware specific. There's no need to worry about dt fragments
> either for the bootloader or for the user. Imposing a new requirement
> for the bootloader to have to probe hardware which it otherwise
> has no need to even care about, and then edit and update the DT
> in a board-specific manner, or have board-specific DT fragments,
> seems like a totally unnecessary imposition on both bootloader
> authors and end-users, and of course it would break booting newer
> kernels on the great mass of already existing boot loaders and
> QEMU installs.

I'm looking for a good generic solution for going forward that can be
used on new boards, for both non-probeable and probeable displays.

When we have that solution, we can see if and how the solution could be
used for current boards. I'm sure that for some boards we need to
support whatever legacy methods are out there already.

> The kernel is in a position to probe the display hardware and determine
> what is there, and do the right thing, and that's exactly what it
> does today. The kernel should continue to do this.
> The advantage of DT is that it allows moving information about
> non-probeable hardware that was previously hardwired in the kernel
> C sources into a separate data structure, but the versatile displays
> are not non-probeable. I can see no benefit at all from hardwiring into
> the dt something which the kernel has previously been successfully
> dynamically getting right without any bootloader intervention -- it just
> makes the kernel less flexible and less user-friendly.

My opinion is that the bootloader should be responsible for telling the
kernel what hardware there is on the board. For busses like PCI we have
proper probing mechanism with global unique identifiers for the devices,
and nothing is needed from the bootloader.

In the Versatile case the panels are kind of probeable, but not in the
same sense as PCI: all that can be probed on Versatile is a board
specific ID, which in itself doesn't tell what kind of panel there is.
In addition to the ID we need board specific tables listing the details
of the panels.

So, true, there's probing going on, but it's all board specific,
requiring a board specific driver to support it in the kernel. And I
think that makes the bootloader much better place for supporting it.
But, again, for legacy reasons that may not be possible.

Now, _if_ the Versatile panels were hotpluggable, and it would be a
normal use case to switch the panels at runtime and having the kernel
automatically switch to the correct video mode, we would obviously need
a kernel driver for it. But afaik that's not the case.

I think one of the core questions here is: do we want to start adding
board specific drivers to the kernel, instead of dealing with it in the
bootloader when possible? My understanding is that we've been trying to
reduce board specific code from the kernel.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/3b325e20/attachment.sig>

From tomi.valkeinen at ti.com  Tue Feb 23 05:00:44 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 23 Feb 2016 15:00:44 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <6859810.tb1t0IEONi@wuerfel>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <3695074.sKSIyOjpjD@wuerfel>
 <CACRpkdZjfjOCFUucF1U5yVZBxSwa41GKEMv-HHQE=ymF2NZ21g@mail.gmail.com>
 <6859810.tb1t0IEONi@wuerfel>
Message-ID: <56CC57FC.20707@ti.com>



On 23/02/16 13:22, Arnd Bergmann wrote:
> On Tuesday 23 February 2016 11:10:33 Linus Walleij wrote:
>>
>> ERROR (duplicate_label): ERROR (duplicate_label): Duplicate label
>> 'clcd_panel' on /panel at 1/port/endpoint and /panel at 0/port/endpoint
>> Duplicate label 'clcd_panel' on /panel at 1/port/endpoint and
>> /panel at 0/port/endpoint
>>
>> So the dtc does not allow duplicate node labels for the phandle
>> even if the node it resides in is disabled. Tough luck...
> 
> Ah, too bad. I guess we could still do it by also setting the
> remote-endpoint property to node->phandle, but then it's
> not as simple any more.

I think it could be done with all panels in an endpoint of their own, as
it is currently in this patch. All the panels would be disabled by
default, and one of them gets enabled at some early boot phase. The
fbdev driver would then iterate the endpoints and pick the first panel
that's enabled.

That would be almost the same as what's already in this patch, except
(if I'm not mistaken) the detection part could be in platform code, and
the fbdev driver itself would know nothing about board specific
detection or board specific panel lists.

So maybe that would be a bit cleaner. Still ugly, I think =). I really
don't like having possible-panels in the Schr?dinger's DT data
(http://www.angryflower.com/387.html).

That said, maybe this is the best way to deal with Versatile, without
requiring any change to the bootloader or the boot mechanism.

What is the current status of Versatile? Have we had working display
with Versatile when booting with device tree? Or has the display been
supported only with legacy boot?

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/39c3ae95/attachment.sig>

From linus.walleij at linaro.org  Tue Feb 23 05:08:22 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Feb 2016 14:08:22 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
Message-ID: <CACRpkdZ9PQ5Wk2sADW5=ZQngAnx+mSfpOKpwV1-vz1XZtZ3Xkg@mail.gmail.com>

On Tue, Feb 23, 2016 at 12:56 PM, Peter Maydell
<peter.maydell at linaro.org> wrote:
> On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
>> I'm not quite sure how it works if, as in versatile display case, there
>> are multiple DT overlays of which one has to be enabled. I hope there's
>> support to choose which one to use via kernel cmdline or similar.
>>
>> I would personally like it much more if the bootloader would either
>> compose a final dtb from DT fragments and pass it to the kernel, or
>> alternatively the bootloader would pass the base dtb image and a bunch
>> of DT overlays to the kernel, and the kernel would deal with the DT
>> overlays.
>
> Speaking as somebody who's written the "bootloader" code that's
> used for what I guess are the majority of versatile kernel boots,
> i.e. the one in QEMU, I think that requiring the bootloader to do this
> would be a significant worsening from the current state.
>
> Right now the bootloader doesn't need to do much at all with device
> trees, except pass the kernel the DT that the user gave us, which
> is just the kernel's own data structures in a separate file for
> convenience. You need to do some very minor tweaks to the /chosen
> node, but these can be handled the same way for any board and aren't
> hardware specific. There's no need to worry about dt fragments
> either for the bootloader or for the user. Imposing a new requirement
> for the bootloader to have to probe hardware which it otherwise
> has no need to even care about, and then edit and update the DT
> in a board-specific manner, or have board-specific DT fragments,
> seems like a totally unnecessary imposition on both bootloader
> authors and end-users, and of course it would break booting newer
> kernels on the great mass of already existing boot loaders and
> QEMU installs.
>
> The kernel is in a position to probe the display hardware and determine
> what is there, and do the right thing, and that's exactly what it
> does today. The kernel should continue to do this.
> The advantage of DT is that it allows moving information about
> non-probeable hardware that was previously hardwired in the kernel
> C sources into a separate data structure, but the versatile displays
> are not non-probeable. I can see no benefit at all from hardwiring into
> the dt something which the kernel has previously been successfully
> dynamically getting right without any bootloader intervention -- it just
> makes the kernel less flexible and less user-friendly.

I agree with Peter and Russell on this, as you could guess.
Today the kernel knows about all the hardware and it
JustWorks(TM) and that is so neat.

I'm still trying to appeal to the subsystem maintainer as well.
Pretty tough deal.

Yours,
Linus Walleij


From mcoquelin.stm32 at gmail.com  Tue Feb 23 05:10:04 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Tue, 23 Feb 2016 14:10:04 +0100
Subject: [PATCH] ARM: dts: stm32f429: Fix clocks referenced by GPIO banks
Message-ID: <1456233004-17848-1-git-send-email-mcoquelin.stm32@gmail.com>

All the clocks referenced by the GPIO banks were not the good ones.

Reported-by: Bruno Herrera <bruherrera at gmail.com>
Signed-off-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
---
 arch/arm/boot/dts/stm32f429.dtsi | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 35b2ab1..598362e 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -182,7 +182,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				reg = <0x0 0x400>;
-				clocks = <&rcc 0 256>;
+				clocks = <&rcc 0 0>;
 				st,bank-name = "GPIOA";
 			};
 
@@ -190,7 +190,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				reg = <0x400 0x400>;
-				clocks = <&rcc 0 257>;
+				clocks = <&rcc 0 1>;
 				st,bank-name = "GPIOB";
 			};
 
@@ -198,7 +198,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				reg = <0x800 0x400>;
-				clocks = <&rcc 0 258>;
+				clocks = <&rcc 0 2>;
 				st,bank-name = "GPIOC";
 			};
 
@@ -206,7 +206,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				reg = <0xc00 0x400>;
-				clocks = <&rcc 0 259>;
+				clocks = <&rcc 0 3>;
 				st,bank-name = "GPIOD";
 			};
 
@@ -214,7 +214,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				reg = <0x1000 0x400>;
-				clocks = <&rcc 0 260>;
+				clocks = <&rcc 0 4>;
 				st,bank-name = "GPIOE";
 			};
 
@@ -222,7 +222,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				reg = <0x1400 0x400>;
-				clocks = <&rcc 0 261>;
+				clocks = <&rcc 0 5>;
 				st,bank-name = "GPIOF";
 			};
 
@@ -230,7 +230,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				reg = <0x1800 0x400>;
-				clocks = <&rcc 0 262>;
+				clocks = <&rcc 0 6>;
 				st,bank-name = "GPIOG";
 			};
 
@@ -238,7 +238,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				reg = <0x1c00 0x400>;
-				clocks = <&rcc 0 263>;
+				clocks = <&rcc 0 7>;
 				st,bank-name = "GPIOH";
 			};
 
@@ -246,7 +246,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				reg = <0x2000 0x400>;
-				clocks = <&rcc 0 264>;
+				clocks = <&rcc 0 8>;
 				st,bank-name = "GPIOI";
 			};
 
@@ -254,7 +254,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				reg = <0x2400 0x400>;
-				clocks = <&rcc 0 265>;
+				clocks = <&rcc 0 9>;
 				st,bank-name = "GPIOJ";
 			};
 
@@ -262,7 +262,7 @@
 				gpio-controller;
 				#gpio-cells = <2>;
 				reg = <0x2800 0x400>;
-				clocks = <&rcc 0 266>;
+				clocks = <&rcc 0 10>;
 				st,bank-name = "GPIOK";
 			};
 
-- 
1.9.1



From linus.walleij at linaro.org  Tue Feb 23 05:16:08 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Feb 2016 14:16:08 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56CC57FC.20707@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <3695074.sKSIyOjpjD@wuerfel>
 <CACRpkdZjfjOCFUucF1U5yVZBxSwa41GKEMv-HHQE=ymF2NZ21g@mail.gmail.com>
 <6859810.tb1t0IEONi@wuerfel> <56CC57FC.20707@ti.com>
Message-ID: <CACRpkdYNaNtQQJ-tsBe5ksa4-z380ZQj-zN8ZnK0ED2kNPUwvg@mail.gmail.com>

On Tue, Feb 23, 2016 at 2:00 PM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:

> That would be almost the same as what's already in this patch, except
> (if I'm not mistaken) the detection part could be in platform code, and
> the fbdev driver itself would know nothing about board specific
> detection or board specific panel lists.

In this patch set the board/platform-specific plugins are separated
out adding the opaque .board_init() and .panel_init() to the driver.
The platform-specific code is in completely separate files this way,
and the CLCD driver itself just handles various versions of that
IP block.

> So maybe that would be a bit cleaner. Still ugly, I think =). I really
> don't like having possible-panels in the Schr?dinger's DT data
> (http://www.angryflower.com/387.html).

OK I will focus my work on the DT-augment code instead.

> That said, maybe this is the best way to deal with Versatile, without
> requiring any change to the bootloader or the boot mechanism.

Depends on if the OF core maintainers will accept my patches to
dynamically alter DT properties at runtime. If I can't do that then
I have to go back to the Schr?dinger patch.

> What is the current status of Versatile? Have we had working display
> with Versatile when booting with device tree? Or has the display been
> supported only with legacy boot?

Versatile is DT only as of kernel v4.5. The DT boot uses AUXDATA
which is the Frankenstein solution, bolting on a boardfile piece
to the DT boot and ignoring the existing panel bindings, and of
course standing in the way of cleaning things up.

IMO Schr?dinger > Frankenstein.

Yours,
Linus Walleij


From alexandre.torgue at gmail.com  Tue Feb 23 05:17:21 2016
From: alexandre.torgue at gmail.com (Alexandre Torgue)
Date: Tue, 23 Feb 2016 14:17:21 +0100
Subject: [PATCH 1/4] net: ethernet: dwmac: add Ethernet glue logic for
 stm32 chip
In-Reply-To: <CAGhQ9VxQ3nW+dr9pdj=H8UcsNHEATxVeAf8N_PsQA7-73uksTA@mail.gmail.com>
References: <1454511275-9791-1-git-send-email-alexandre.torgue@gmail.com>
 <1454511275-9791-2-git-send-email-alexandre.torgue@gmail.com>
 <CAGhQ9VypZ5J0pQmrf1Mk-mNsv=XTXu7fhoLt_r2LHJ_Lsyj0yA@mail.gmail.com>
 <CAJgp7zwOVEq=hnxfUt7eHZWSFUAwuK6MCVHdH591=xReRUsW8Q@mail.gmail.com>
 <CAGhQ9VzPTgRqqLi4zjHkP-++v5smZ7s52drev1z-AvgXaLuC7Q@mail.gmail.com>
 <CAJgp7zxYhbQ4yQHBB3cu50TU9N9xvk3HxCp0NP5fxFbxrMsD_g@mail.gmail.com>
 <CAGhQ9VxQ3nW+dr9pdj=H8UcsNHEATxVeAf8N_PsQA7-73uksTA@mail.gmail.com>
Message-ID: <CAJgp7zxToxdKH_UU4UpF_jW2hTGvCxOPmxoDMLfphWEcKmsYHA@mail.gmail.com>

2016-02-23 12:21 GMT+01:00 Joachim  Eastwood <manabian at gmail.com>:
> On 23 February 2016 at 10:59, Alexandre Torgue
> <alexandre.torgue at gmail.com> wrote:
>> 2016-02-22 22:52 GMT+01:00 Joachim  Eastwood <manabian at gmail.com>:
>>> On 22 February 2016 at 15:50, Alexandre Torgue
>>> <alexandre.torgue at gmail.com> wrote:
>>>> 2016-02-13 14:48 GMT+01:00 Joachim  Eastwood <manabian at gmail.com>:
>>>>> On 3 February 2016 at 15:54, Alexandre TORGUE
>>>>> <alexandre.torgue at gmail.com> wrote:
>>>>>> +       plat_dat->bsp_priv = dwmac;
>>>>>> +       plat_dat->init = stm32_dwmac_init;
>>>>>> +       plat_dat->exit = stm32_dwmac_exit;
>>>>>
>>>>> Instead of using these callbacks could you rather implement the PM
>>>>> callbacks directly in this driver?
>>>>> I don't think it should add much code and it will make it look more
>>>>> like standard driver. This will also give you some more control and
>>>>> flexibility in your code.
>>>>
>>>> I prefer to keep the code as it is. Glue layer is directly linked to
>>>> stmmac driver and I don't want to brake the link between the glue and
>>>> the stmmac driver.
>>>
>>> What do you mean by break the link?
>>>
>>
>> I thought that you wanted to split stmmac_pltfr_supend (glue part and
>> stmamc part), but I well understood it is not the case (sorry for
>> mistake).
>>
>>> There has been numerous of patch sets to make the stmmac "glue"
>>> drivers into more standard platform drivers.
>>> http://marc.info/?l=linux-netdev&m=143159850631093&w=2
>>> http://marc.info/?l=linux-netdev&m=143708560009851&w=2
>>> http://marc.info/?l=linux-netdev&m=143812136600541&w=2
>>>
>>> Do you see any advantage by using the init and exit hooks in your
>>> driver instead of using the standard driver PM callbacks and remove
>>> function?
>>> The only "cost" I see is slightly more boilerplate code. But since you
>>> already have init/exit functions you could easily make them into PM
>>> resume/suspend so I doubt there would be much increase in code size.
>>>
>>
>> If I well understood you want to continue the stmmac glue driver
>> rework by moving stmmac_pltfr_suspend/resume/remove in each glue
>> driver (stm32, sun, sti ....).
>
> At least I want to avoid the init/exit callbacks for new drivers like
> stm32-dwmac.
>
>
>> Each glue driver will call directly stmmac_suspend/resume/remove and
>> their own init/exit function.
>> If it is what you meant, I can do it.
>
> Yes, in your stm32 driver's suspend/resume/remove functions call
> stmmac_suspend/stmmac_resume/stmmac_dvr_remove directly. Then you
> shouldn't need to use the init/exit callbacks. Just put the need code
> in the driver's suspend/resume/remove functions instead of init/exit
> functions.
>
> For example:
> static int stm32_dwmac_resume(struct device *dev)
> {
>     struct net_device *ndev = dev_get_drvdata(dev);
>     struct plat_stmmacenet_data *plat_dat = get_stmmac_plat_data(ndev)
>     struct stm32_dwmac *dwmac =plat_dat->bsp_priv;
>
>     /* enable clocks */
>     /* set phy mode */
>
>     return stmmac_resume(ndev);
> }
>
> If it makes sense to have the enable clk/phy mode stuff in it's own
> function that is fine too.

Ok. I will send v2 with this approach. After this series I could
provide a new series to change all glues with this approach ? (but I
will not able to test on each platform).

Best regards

Alexandre
>
>
>>> One other thing;
>>> Do you need to have the PHY mode setup code in the init function which
>>> is called each time on resume?
>>
>> I can't guarantee that after a suspend the sysconfig register will
>> contain same data than before suspend.
>
> I see.
>
>
> regards,
> Joachim Eastwood


From arnd at arndb.de  Tue Feb 23 05:35:58 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 14:35:58 +0100
Subject: [PATCH] ARM: realview: hide unused 'pmu_device' object
Message-ID: <1456234567-3705502-1-git-send-email-arnd@arndb.de>

The pmu_device is only accessed when CACHE_L2X0 is enabled,
and we get a warning otherwise:

mach-realview/realview_pbx.c:274:31: error: 'pmu_device' defined but not used [-Werror=unused-variable]

This adds another #ifdef for it.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
Linus, I'm not sure how long you plan to keep the board file around,
so just ignore the patch if this is getting deleted anyway, otherwise
it would be nice if you could add the patch to your series.

 arch/arm/mach-realview/realview_pbx.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-realview/realview_pbx.c b/arch/arm/mach-realview/realview_pbx.c
index b9f0757787ac..be1cec5fe3ad 100644
--- a/arch/arm/mach-realview/realview_pbx.c
+++ b/arch/arm/mach-realview/realview_pbx.c
@@ -248,6 +248,7 @@ static struct resource realview_pbx_isp1761_resources[] = {
 	},
 };
 
+#ifdef CONFIG_CACHE_L2X0
 static struct resource pmu_resources[] = {
 	[0] = {
 		.start		= IRQ_PBX_PMU_CPU0,
@@ -277,6 +278,7 @@ static struct platform_device pmu_device = {
 	.num_resources		= ARRAY_SIZE(pmu_resources),
 	.resource		= pmu_resources,
 };
+#endif
 
 static void __init gic_init_irq(void)
 {
-- 
2.7.0



From tomi.valkeinen at ti.com  Tue Feb 23 05:38:12 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Tue, 23 Feb 2016 15:38:12 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CACRpkdYNaNtQQJ-tsBe5ksa4-z380ZQj-zN8ZnK0ED2kNPUwvg@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <3695074.sKSIyOjpjD@wuerfel>
 <CACRpkdZjfjOCFUucF1U5yVZBxSwa41GKEMv-HHQE=ymF2NZ21g@mail.gmail.com>
 <6859810.tb1t0IEONi@wuerfel> <56CC57FC.20707@ti.com>
 <CACRpkdYNaNtQQJ-tsBe5ksa4-z380ZQj-zN8ZnK0ED2kNPUwvg@mail.gmail.com>
Message-ID: <56CC60C4.6040908@ti.com>



On 23/02/16 15:16, Linus Walleij wrote:
> On Tue, Feb 23, 2016 at 2:00 PM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> 
>> That would be almost the same as what's already in this patch, except
>> (if I'm not mistaken) the detection part could be in platform code, and
>> the fbdev driver itself would know nothing about board specific
>> detection or board specific panel lists.
> 
> In this patch set the board/platform-specific plugins are separated
> out adding the opaque .board_init() and .panel_init() to the driver.
> The platform-specific code is in completely separate files this way,
> and the CLCD driver itself just handles various versions of that
> IP block.

I see. Yes, it's in separate files but still part of the fbdev driver.

One thing to mention is that I'm looking at this maybe from a slightly
different perspective.

TI makes SoCs which may be used on a lot of different boards from
different vendors. I will not allow any solution on TI display subsystem
that would contain any board specific data, as that would quickly expand
to an unmaintainable mess. All the display data has to come from the
bootloader.

Maybe Versatile is different. If CLCD is only used on that board, or a
small family of boards, from one vendor, I guess it is maintainable to
have board specific driver parts for CLCD. But if CLCD can be used by
many vendors in many different boards, I'd steer clear of board specific
driver code.

>> So maybe that would be a bit cleaner. Still ugly, I think =). I really
>> don't like having possible-panels in the Schr?dinger's DT data
>> (http://www.angryflower.com/387.html).
> 
> OK I will focus my work on the DT-augment code instead.

Yeah, I don't know if that will fly either, so I think it's better to
see if these discussion go somewhere first.

>> That said, maybe this is the best way to deal with Versatile, without
>> requiring any change to the bootloader or the boot mechanism.
> 
> Depends on if the OF core maintainers will accept my patches to
> dynamically alter DT properties at runtime. If I can't do that then
> I have to go back to the Schr?dinger patch.
> 
>> What is the current status of Versatile? Have we had working display
>> with Versatile when booting with device tree? Or has the display been
>> supported only with legacy boot?
> 
> Versatile is DT only as of kernel v4.5. The DT boot uses AUXDATA
> which is the Frankenstein solution, bolting on a boardfile piece
> to the DT boot and ignoring the existing panel bindings, and of
> course standing in the way of cleaning things up.

Ok. I feel everyone is trying to push the ugly part out of their domain.
I want the board specific hacks out of fbdev. Bootloader people don't
want it there. arch/arm/ people don't want it there. =)

So what you're saying is that Versatile boots now with DT, and supports
display without any panel info in the DT data? If so, it means that when
you add panel data to the .dts, the old .dts will not support display
anymore, except if you leave all the current boardfile stuff there.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/9c052c07/attachment.sig>

From linus.walleij at linaro.org  Tue Feb 23 05:39:22 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Tue, 23 Feb 2016 14:39:22 +0100
Subject: [PATCH] ARM: realview: hide unused 'pmu_device' object
In-Reply-To: <1456234567-3705502-1-git-send-email-arnd@arndb.de>
References: <1456234567-3705502-1-git-send-email-arnd@arndb.de>
Message-ID: <CACRpkdYGbg1S9MCVdcy6z1qBF6zXMA=JJag=51mGre+n+-Ar0Q@mail.gmail.com>

On Tue, Feb 23, 2016 at 2:35 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> The pmu_device is only accessed when CACHE_L2X0 is enabled,
> and we get a warning otherwise:
>
> mach-realview/realview_pbx.c:274:31: error: 'pmu_device' defined but not used [-Werror=unused-variable]
>
> This adds another #ifdef for it.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
> Linus, I'm not sure how long you plan to keep the board file around,
> so just ignore the patch if this is getting deleted anyway, otherwise
> it would be nice if you could add the patch to your series.

I'll queue it in the bottom of my stack, it doesn't hurt.

I'm working on DTSes for the PBX as we speak.

Yours,
Linus Walleij


From john at metanate.com  Tue Feb 23 05:40:58 2016
From: john at metanate.com (John Keeping)
Date: Tue, 23 Feb 2016 13:40:58 +0000
Subject: [PATCH 0/2] ARM: dts: rockchip: fix some interrupts on rk3288
Message-ID: <1456234860-18832-1-git-send-email-john@metanate.com>

None of these are used by drivers so these don't fix any bugs but maybe
they'll save someone debugging time in the future.

John Keeping (2):
  ARM: dts: rockchip: fix MIPI interrupt on rk3288
  ARM: dts: rockchip: fix audio interrupts on rk3288

 arch/arm/boot/dts/rk3288.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.7.0.226.gfe986fe



From john at metanate.com  Tue Feb 23 05:40:59 2016
From: john at metanate.com (John Keeping)
Date: Tue, 23 Feb 2016 13:40:59 +0000
Subject: [PATCH 1/2] ARM: dts: rockchip: fix MIPI interrupt on rk3288
In-Reply-To: <1456234860-18832-1-git-send-email-john@metanate.com>
References: <1456234860-18832-1-git-send-email-john@metanate.com>
Message-ID: <1456234860-18832-2-git-send-email-john@metanate.com>

This isn't currently used by the driver but the correct value is 19
since DSIHOST0 is 51 in the TRM and the GIC offset requires 32 to be
subtracted.

Signed-off-by: John Keeping <john at metanate.com>
---
 arch/arm/boot/dts/rk3288.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index c75914b..5597105 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -857,7 +857,7 @@
 	mipi_dsi: mipi at ff960000 {
 		compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi";
 		reg = <0xff960000 0x4000>;
-		interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&cru SCLK_MIPIDSI_24M>, <&cru PCLK_MIPI_DSI0>;
 		clock-names = "ref", "pclk";
 		rockchip,grf = <&grf>;
-- 
2.7.0.226.gfe986fe



From john at metanate.com  Tue Feb 23 05:41:00 2016
From: john at metanate.com (John Keeping)
Date: Tue, 23 Feb 2016 13:41:00 +0000
Subject: [PATCH 2/2] ARM: dts: rockchip: fix audio interrupts on rk3288
In-Reply-To: <1456234860-18832-1-git-send-email-john@metanate.com>
References: <1456234860-18832-1-git-send-email-john@metanate.com>
Message-ID: <1456234860-18832-3-git-send-email-john@metanate.com>

These must be translated from the values in the TRM by subtracting 32,
which has not been done.  The SPDIF interrupt is also off-by-one.

Signed-off-by: John Keeping <john at metanate.com>
---
 arch/arm/boot/dts/rk3288.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 5597105..a82d4b1 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -758,7 +758,7 @@
 		clocks = <&cru HCLK_SPDIF8CH>, <&cru SCLK_SPDIF8CH>;
 		dmas = <&dmac_bus_s 3>;
 		dma-names = "tx";
-		interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&spdif_tx>;
 		rockchip,grf = <&grf>;
@@ -768,7 +768,7 @@
 	i2s: i2s at ff890000 {
 		compatible = "rockchip,rk3288-i2s", "rockchip,rk3066-i2s";
 		reg = <0xff890000 0x10000>;
-		interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
 		#address-cells = <1>;
 		#size-cells = <0>;
 		dmas = <&dmac_bus_s 0>, <&dmac_bus_s 1>;
-- 
2.7.0.226.gfe986fe



From trini at konsulko.com  Tue Feb 23 05:45:20 2016
From: trini at konsulko.com (Tom Rini)
Date: Tue, 23 Feb 2016 08:45:20 -0500
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <20160223120101.GJ19428@n2100.arm.linux.org.uk>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
 <20160223120101.GJ19428@n2100.arm.linux.org.uk>
Message-ID: <20160223134520.GJ23166@bill-the-cat>

On Tue, Feb 23, 2016 at 12:01:01PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 23, 2016 at 11:56:34AM +0000, Peter Maydell wrote:
> > On 23 February 2016 at 09:58, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> > > I'm not quite sure how it works if, as in versatile display case, there
> > > are multiple DT overlays of which one has to be enabled. I hope there's
> > > support to choose which one to use via kernel cmdline or similar.
> > >
> > > I would personally like it much more if the bootloader would either
> > > compose a final dtb from DT fragments and pass it to the kernel, or
> > > alternatively the bootloader would pass the base dtb image and a bunch
> > > of DT overlays to the kernel, and the kernel would deal with the DT
> > > overlays.
> > 
> > Speaking as somebody who's written the "bootloader" code that's
> > used for what I guess are the majority of versatile kernel boots,
> > i.e. the one in QEMU, I think that requiring the bootloader to do this
> > would be a significant worsening from the current state.
> > 
> > Right now the bootloader doesn't need to do much at all with device
> > trees, except pass the kernel the DT that the user gave us, which
> > is just the kernel's own data structures in a separate file for
> > convenience. You need to do some very minor tweaks to the /chosen
> > node, but these can be handled the same way for any board and aren't
> > hardware specific. There's no need to worry about dt fragments
> > either for the bootloader or for the user. Imposing a new requirement
> > for the bootloader to have to probe hardware which it otherwise
> > has no need to even care about, and then edit and update the DT
> > in a board-specific manner, or have board-specific DT fragments,
> > seems like a totally unnecessary imposition on both bootloader
> > authors and end-users, and of course it would break booting newer
> > kernels on the great mass of already existing boot loaders and
> > QEMU installs.
> > 
> > The kernel is in a position to probe the display hardware and determine
> > what is there, and do the right thing, and that's exactly what it
> > does today. The kernel should continue to do this.
> > The advantage of DT is that it allows moving information about
> > non-probeable hardware that was previously hardwired in the kernel
> > C sources into a separate data structure, but the versatile displays
> > are not non-probeable. I can see no benefit at all from hardwiring into
> > the dt something which the kernel has previously been successfully
> > dynamically getting right without any bootloader intervention -- it just
> > makes the kernel less flexible and less user-friendly.
> 
> +1.

+1 from me too.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/bfdb2434/attachment.sig>

From matthijsvanduin at gmail.com  Tue Feb 23 05:47:31 2016
From: matthijsvanduin at gmail.com (Matthijs van Duin)
Date: Tue, 23 Feb 2016 14:47:31 +0100
Subject: [PATCH 2/2] clk: ti: Add support for dm814x ADPLL
In-Reply-To: <20160217230253.2278.80903@quark.deferred.io>
References: <1455312009-808-1-git-send-email-tony@atomide.com>
 <1455312009-808-3-git-send-email-tony@atomide.com>
 <20160217011930.2278.38316@quark.deferred.io>
 <20160217173949.GB21202@atomide.com>
 <20160217205257.2278.11639@quark.deferred.io>
 <20160217212045.GE21202@atomide.com>
 <20160217230253.2278.80903@quark.deferred.io>
Message-ID: <CAALWOA-dA1r5Ac-y7d3yLhDR1fNM5WJvOmQ3YvvNM+6NP84VLw@mail.gmail.com>

On 17 February 2016 at 22:20, Tony Lindgren <tony at atomide.com> wrote:
>* Michael Turquette <mturquette at baylibre.com> [160217 12:53]:
>> Do you think you will ever have a driver that wants to gate these
>> clocks? Probably not for MPU/DDR, but the HAND_OFF flag is a better fit
>> if you do. It's the same as CRITICAL but transfers the prepare/enable
>> reference counting to the consumer driver after that driver calls
>> clk_get() and clk_prepare_enable() on the HAND_OFF clk.
>
> OK I'll use CLK_ENABLE_HAND_OFF then. Who knows maybe somebody
> somewhere has code running on one of the coprocessors in SRAM that
> actually allows gating these :)

An arrangement somewhat similar to the one the am335x has should
indeed be doable, but note that it would be the coprocessor that would
gate and ungate the clocks, not linux. The L3 clock is actually even
more essential and can never be gated at all.

In the absence of help from a coprocessor linux could still put the L3
and MPU PLLs into bypass for power saving, and DDR can be gated if
it's first put into self-refresh and helper code in on-chip SRAM is
used to manage the transitions.

On 18 February 2016 at 00:02, Michael Turquette <mturquette at baylibre.com> wrote:
> Low power mp3 decoder executing out of ARM icache with DDR clock cut ;-)

L1 cache is rather tricky since you can't lock it. You can however
lock 448 KB of the 512 KB L2 cache, which should be plenty of space.
There's also quite a bit of SRAM on chip usable for buffering data.

The C674x DSP would probably also be a good candidate for such an application.

Matthijs


From peter.maydell at linaro.org  Tue Feb 23 05:49:23 2016
From: peter.maydell at linaro.org (Peter Maydell)
Date: Tue, 23 Feb 2016 13:49:23 +0000
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56CC546A.9070705@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
 <56CC546A.9070705@ti.com>
Message-ID: <CAFEAcA-Y7rE_9CiOphgmae3FDApRznoBS7vsVN_+9hBqvAzEEA@mail.gmail.com>

On 23 February 2016 at 12:45, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> So, true, there's probing going on, but it's all board specific,
> requiring a board specific driver to support it in the kernel. And I
> think that makes the bootloader much better place for supporting it.

This doesn't seem to me like a reason to put the requirement
in the bootloader. A huge part of the purpose of the kernel
is to support the hardware (whether that's completely generic
and probeable, like PCI, or generic but not probeable, or
completely specific to a particular board). The kernel has to
support the hardware, and just because it happens to be board
specific hardware rather than generic hardware doesn't seem to
me to imply that the kernel gets to drop part of its core purpose.

> I think one of the core questions here is: do we want to start adding
> board specific drivers to the kernel, instead of dealing with it in the
> bootloader when possible? My understanding is that we've been trying to
> reduce board specific code from the kernel.

I think there's a difference between "reduce board specific code
in the kernel by replacing it with the combination of generic
or parameterisable code in the kernel plus a kernel data structure
(DT) that supplies the parameterisation needed", and "reduce
board specific code in the kernel by forcing the bootloader to
do the kernel's job for it".

thanks
-- PMM


From Suzuki.Poulose at arm.com  Tue Feb 23 05:55:51 2016
From: Suzuki.Poulose at arm.com (Suzuki K. Poulose)
Date: Tue, 23 Feb 2016 13:55:51 +0000
Subject: [PATCH 00/13] arm-cci: PMU driver updates for 4.6
In-Reply-To: <20160223114003.GF3966@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
 <20160223114003.GF3966@arm.com>
Message-ID: <56CC64E7.3040407@arm.com>

On 23/02/16 11:40, Will Deacon wrote:
> On Tue, Feb 23, 2016 at 10:49:42AM +0000, Suzuki K Poulose wrote:
>> Here are some fixes and updates for arm-cci pmu driver targeting v4.6,
>> applies on top of v4.5-rc5.
>>
>> Highlights include :
>>   - Support for CoreLink CCI-550 PMU
>>   - Reliable writes to PMU Counter registers for CCI-500/550.
>>
>> All the patches have been Acked. Please let me know how this
>> can be merged.

>>
>>   Documentation/devicetree/bindings/arm/cci.txt |    2 +
>>   drivers/bus/Kconfig                           |   10 +-
>>   drivers/bus/arm-cci.c                         |  612 +++++++++++++++++--------
>>   3 files changed, 427 insertions(+), 197 deletions(-)
>
> How do you plan to merge this? I can take it all onto a branch for
> arm-soc, or I can include it on my perf/updates branch, or ...?

Arnd, Olof,

What do you think would be the best route ?

Cheers
Suzuki







From gg at slimlogic.co.uk  Tue Feb 23 05:57:31 2016
From: gg at slimlogic.co.uk (Graeme Gregory)
Date: Tue, 23 Feb 2016 13:57:31 +0000
Subject: [PATCH 1/8] arm64: move acpi/dt decision earlier in boot process
In-Reply-To: <56CB2D0D.3090408@gmail.com>
References: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
 <1456148818-26257-2-git-send-email-aleksey.makarov@linaro.org>
 <56CB2D0D.3090408@gmail.com>
Message-ID: <20160223135731.GA24781@xora-haswell.xora.org.uk>

On Mon, Feb 22, 2016 at 04:45:17PM +0100, Matthias Brugger wrote:
> 
> 
> On 22/02/16 14:46, Aleksey Makarov wrote:
> >From: Leif Lindholm <leif.lindholm at linaro.org>
> >
> >In order to support selecting earlycon via either ACPI or DT, move
> >the decision on whether to attempt ACPI configuration into the
> >early_param handling. Then make acpi_boot_table_init() bail out if
> >acpi_disabled.
> >
> >Signed-off-by: Leif Lindholm <leif.lindholm at linaro.org>
> >---
> >  arch/arm64/kernel/acpi.c | 54 ++++++++++++++++++++++++++----------------------
> >  1 file changed, 29 insertions(+), 25 deletions(-)
> >
> >diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> >index d1ce8e2..7a944f7 100644
> >--- a/arch/arm64/kernel/acpi.c
> >+++ b/arch/arm64/kernel/acpi.c
> >@@ -44,6 +44,19 @@ EXPORT_SYMBOL(acpi_pci_disabled);
> >  static bool param_acpi_off __initdata;
> >  static bool param_acpi_force __initdata;
> >
> >+static int __init dt_scan_depth1_nodes(unsigned long node,
> >+				       const char *uname, int depth,
> >+				       void *data)
> >+{
> >+	/*
> >+	 * Return 1 as soon as we encounter a node at depth 1 that is
> >+	 * not the /chosen node.
> >+	 */
> >+	if (depth == 1 && (strcmp(uname, "chosen") != 0))
> >+		return 1;
> >+	return 0;
> >+}
> >+
> >  static int __init parse_acpi(char *arg)
> >  {
> >  	if (!arg)
> >@@ -57,23 +70,27 @@ static int __init parse_acpi(char *arg)
> >  	else
> >  		return -EINVAL;	/* Core will print when we return error */
> >
> >-	return 0;
> >-}
> >-early_param("acpi", parse_acpi);
> >+	/*
> >+	 * Enable ACPI instead of device tree unless
> >+	 * - ACPI has been disabled explicitly (acpi=off), or
> >+	 * - the device tree is not empty (it has more than just a /chosen node)
> >+	 *   and ACPI has not been force enabled (acpi=force)
> >+	 */
> >+	if (param_acpi_off ||
> >+	    (!param_acpi_force && of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
> >+		return 0;
> >
> >-static int __init dt_scan_depth1_nodes(unsigned long node,
> >-				       const char *uname, int depth,
> >-				       void *data)
> >-{
> >  	/*
> >-	 * Return 1 as soon as we encounter a node at depth 1 that is
> >-	 * not the /chosen node.
> >+	 * ACPI is disabled at this point. Enable it in order to parse
> >+	 * the ACPI tables and carry out sanity checks
> >  	 */
> >-	if (depth == 1 && (strcmp(uname, "chosen") != 0))
> >-		return 1;
> >+	enable_acpi();
> >+
> 
> So we only enable ACPI if we pass acpi=force as kernel parameter?
> I'm not sure if this is what you wanted to do.
> 

The current preference from ARM64 maintainers was that is both ACPI
tables and a DT were presented then DT should take precedence.

With no DT provided the code should use ACPI.

Graeme



From arnd at arndb.de  Tue Feb 23 05:57:50 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 14:57:50 +0100
Subject: [PATCH 0/3] ARM: omap: randconfig warning fixes
Message-ID: <1456235876-4088840-1-git-send-email-arnd@arndb.de>

Hi Tony,

Here are three patches to fix the remaining warnings I get
in OMAP randconfig builds. The problems are all harmless,
and the patches are just shutting up the compiler, but I
think it's still worthwhile to include them to reduce the
noise.

	Arnd



From arnd at arndb.de  Tue Feb 23 05:57:51 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 14:57:51 +0100
Subject: [PATCH 1/3] ARM: omap2: mark unused functions as __maybe_unused
In-Reply-To: <1456235876-4088840-1-git-send-email-arnd@arndb.de>
References: <1456235876-4088840-1-git-send-email-arnd@arndb.de>
Message-ID: <1456235876-4088840-2-git-send-email-arnd@arndb.de>

The omap_generic_init() and omap_hwmod_init_postsetup() functions are
used in the initialization for all OMAP2+ SoC types, but in the
extreme case that those are all disabled, we get a warning about
unused code:

arch/arm/mach-omap2/io.c:412:123: error: 'omap_hwmod_init_postsetup' defined but not used [-Werror=unused-function]
arch/arm/mach-omap2/board-generic.c:30:123: error: 'omap_generic_init' defined but not used [-Werror=unused-function]

This annotates both as __maybe_unused to shut up that warning.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-omap2/board-generic.c | 2 +-
 arch/arm/mach-omap2/io.c            | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index bab814d2f37d..d75ec64ae0b5 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -28,7 +28,7 @@ static const struct of_device_id omap_dt_match_table[] __initconst = {
 	{ }
 };
 
-static void __init omap_generic_init(void)
+static void __init __maybe_unused omap_generic_init(void)
 {
 	omapdss_early_init_of();
 
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 3c87e40650cf..f192fc7fd4f7 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -409,7 +409,7 @@ static int _set_hwmod_postsetup_state(struct omap_hwmod *oh, void *data)
 	return omap_hwmod_set_postsetup_state(oh, *(u8 *)data);
 }
 
-static void __init omap_hwmod_init_postsetup(void)
+static void __init __maybe_unused omap_hwmod_init_postsetup(void)
 {
 	u8 postsetup_state;
 
-- 
2.7.0



From arnd at arndb.de  Tue Feb 23 05:57:52 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 14:57:52 +0100
Subject: [PATCH 2/3] ARM: omap1: avoid unused variable warning
In-Reply-To: <1456235876-4088840-1-git-send-email-arnd@arndb.de>
References: <1456235876-4088840-1-git-send-email-arnd@arndb.de>
Message-ID: <1456235876-4088840-3-git-send-email-arnd@arndb.de>

The osk_mistral_init() contains code that is only compiled when
CONFIG_PM is set, but it uses a variable that is declared outside
of the #ifdef:

arch/arm/mach-omap1/board-osk.c: In function 'osk_mistral_init':
arch/arm/mach-omap1/board-osk.c:513:7: warning: unused variable 'ret' [-Wunused-variable]

This puts the variable in the same #ifdef to avoid the warning.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-omap1/board-osk.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index 209aecb0df68..fcc5c0650429 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -510,7 +510,9 @@ static void __init osk_mistral_init(void)
 	 */
 	omap_cfg_reg(N15_1610_MPUIO2);
 	if (gpio_request(OMAP_MPUIO(2), "wakeup") == 0) {
+#ifdef	CONFIG_PM
 		int ret = 0;
+#endif
 		int irq = gpio_to_irq(OMAP_MPUIO(2));
 
 		gpio_direction_input(OMAP_MPUIO(2));
-- 
2.7.0



From arnd at arndb.de  Tue Feb 23 05:57:53 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 14:57:53 +0100
Subject: [PATCH 3/3] ARM: omap1/ams-delta: warn about failed regulator enable
In-Reply-To: <1456235876-4088840-1-git-send-email-arnd@arndb.de>
References: <1456235876-4088840-1-git-send-email-arnd@arndb.de>
Message-ID: <1456235876-4088840-4-git-send-email-arnd@arndb.de>

The modem pm handler in the ams-delta board uses regulator_enable()
but does not check for a successful return code:

board-ams-delta.c:521:3: error: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Werror=unused-result]

It is not easy to propagate that return code to the callers in
uart_configure_port/uart_suspend_port/uart_resume_port, unless
we change all UART drivers, and it is unclear what those would
do with the return code.

Instead, this patch uses a runtime warning to replace the
compiletime warning. I have checked that the regulator in question
is hardcoded to a fixed-voltage GPIO regulator, and that should
never fail to get enabled if I understand the code right.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-omap1/board-ams-delta.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 6613a6ff5dbc..6cbc69c92913 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -510,6 +510,7 @@ static void __init ams_delta_init(void)
 static void modem_pm(struct uart_port *port, unsigned int state, unsigned old)
 {
 	struct modem_private_data *priv = port->private_data;
+	int ret;
 
 	if (IS_ERR(priv->regulator))
 		return;
@@ -518,9 +519,16 @@ static void modem_pm(struct uart_port *port, unsigned int state, unsigned old)
 		return;
 
 	if (state == 0)
-		regulator_enable(priv->regulator);
+		ret = regulator_enable(priv->regulator);
 	else if (old == 0)
-		regulator_disable(priv->regulator);
+		ret = regulator_disable(priv->regulator);
+	else
+		ret = 0;
+
+	if (ret)
+		dev_warn(port->dev,
+			 "ams_delta modem_pm: failed to %sable regulator: %d\n",
+			 state ? "dis" : "en", ret);
 }
 
 static struct plat_serial8250_port ams_delta_modem_ports[] = {
-- 
2.7.0



From arnd at arndb.de  Tue Feb 23 06:06:36 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 15:06:36 +0100
Subject: [PATCH 0/3] ARM: mvebu: randconfig warning fixes
Message-ID: <1456236403-115511-1-git-send-email-arnd@arndb.de>

Here are three more warning fixes for orion/mv78xx0/mvebu. All
are really harmless and I'm just shutting up the warnings
as the current code is basically ok.

	Arnd



From arnd at arndb.de  Tue Feb 23 06:06:37 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 15:06:37 +0100
Subject: [PATCH 1/3] ARM: orion: only select I2C_BOARDINFO when using I2C
In-Reply-To: <1456236403-115511-1-git-send-email-arnd@arndb.de>
References: <1456236403-115511-1-git-send-email-arnd@arndb.de>
Message-ID: <1456236403-115511-2-git-send-email-arnd@arndb.de>

If we select I2C_BOARDINFO and I2C is disabled, we get a
harmless Kconfig warning:

warning: (MACH_DOVE_DB && MACH_DB88F5281 && MACH_RD88F5182 && MACH_RD88F5182_DT && MACH_KUROBOX_PRO && MACH_DNS323 && MACH_LINKSTATION_PRO && MACH_LINKSTATION_LSCHL && MACH_LINKSTATION_LS_HGL && MACH_NET2BIG) selects I2C_BOARDINFO which has unmet direct dependencies (I2C)

Making the select itself conditional avoids the warning and
makes the kernel slightly smaller as the compiler will be
able to drop the unused board info.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-dove/Kconfig    |  2 +-
 arch/arm/mach-orion5x/Kconfig | 18 +++++++++---------
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
index 0fd506125cde..5cc9f7450197 100644
--- a/arch/arm/mach-dove/Kconfig
+++ b/arch/arm/mach-dove/Kconfig
@@ -18,7 +18,7 @@ config DOVE_LEGACY
 config MACH_DOVE_DB
 	bool "Marvell DB-MV88AP510 Development Board"
 	select DOVE_LEGACY
-	select I2C_BOARDINFO
+	select I2C_BOARDINFO if I2C
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell DB-MV88AP510 Development Board.
diff --git a/arch/arm/mach-orion5x/Kconfig b/arch/arm/mach-orion5x/Kconfig
index 4c0acd844429..a9ae143703f8 100644
--- a/arch/arm/mach-orion5x/Kconfig
+++ b/arch/arm/mach-orion5x/Kconfig
@@ -28,14 +28,14 @@ config ARCH_ORION5X_DT
 
 config MACH_DB88F5281
 	bool "Marvell Orion-2 Development Board"
-	select I2C_BOARDINFO
+	select I2C_BOARDINFO if I2C
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell Orion-2 (88F5281) Development Board
 
 config MACH_RD88F5182
 	bool "Marvell Orion-NAS Reference Design"
-	select I2C_BOARDINFO
+	select I2C_BOARDINFO if I2C
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Marvell Orion-NAS (88F5182) RD2
@@ -43,14 +43,14 @@ config MACH_RD88F5182
 config MACH_RD88F5182_DT
 	bool "Marvell Orion-NAS Reference Design (Flattened Device Tree)"
 	select ARCH_ORION5X_DT
-	select I2C_BOARDINFO
+	select I2C_BOARDINFO if I2C
 	help
 	  Say 'Y' here if you want your kernel to support the Marvell
 	  Orion-NAS (88F5182) RD2, Flattened Device Tree.
 
 config MACH_KUROBOX_PRO
 	bool "KuroBox Pro"
-	select I2C_BOARDINFO
+	select I2C_BOARDINFO if I2C
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  KuroBox Pro platform.
@@ -58,7 +58,7 @@ config MACH_KUROBOX_PRO
 config MACH_DNS323
 	bool "D-Link DNS-323"
 	select GENERIC_NET_UTILS
-	select I2C_BOARDINFO
+	select I2C_BOARDINFO if I2C
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  D-Link DNS-323 platform.
@@ -78,7 +78,7 @@ config MACH_TERASTATION_PRO2
 
 config MACH_LINKSTATION_PRO
 	bool "Buffalo Linkstation Pro/Live"
-	select I2C_BOARDINFO
+	select I2C_BOARDINFO if I2C
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Buffalo Linkstation Pro/Live platform. Both v1 and
@@ -86,7 +86,7 @@ config MACH_LINKSTATION_PRO
 
 config MACH_LINKSTATION_LSCHL
 	bool "Buffalo Linkstation Live v3 (LS-CHL)"
-	select I2C_BOARDINFO
+	select I2C_BOARDINFO if I2C
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Buffalo Linkstation Live v3 (LS-CHL) platform.
@@ -100,7 +100,7 @@ config MACH_LINKSTATION_MINI
 
 config MACH_LINKSTATION_LS_HGL
 	bool "Buffalo Linkstation LS-HGL"
-	select I2C_BOARDINFO
+	select I2C_BOARDINFO if I2C
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  Buffalo Linkstation LS-HGL platform.
@@ -139,7 +139,7 @@ config MACH_D2NET_DT
 
 config MACH_NET2BIG
 	bool "LaCie 2Big Network"
-	select I2C_BOARDINFO
+	select I2C_BOARDINFO if I2C
 	help
 	  Say 'Y' here if you want your kernel to support the
 	  LaCie 2Big Network NAS.
-- 
2.7.0



From arnd at arndb.de  Tue Feb 23 06:06:39 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 15:06:39 +0100
Subject: [PATCH 3/3] ARM: mvebu: mark mvebu_hwcc_pci_nb as __maybe_unused
In-Reply-To: <1456236403-115511-1-git-send-email-arnd@arndb.de>
References: <1456236403-115511-1-git-send-email-arnd@arndb.de>
Message-ID: <1456236403-115511-4-git-send-email-arnd@arndb.de>

The coherency notifier block is only used when CONFIG_PCI
is enabled, otherwise we get a warning:

arch/arm/mach-mvebu/coherency.c:110:30: warning: 'mvebu_hwcc_pci_nb' defined but not used [-Wunused-variable]

There is no nice way to use an if(IS_ENABLED()) check here to
let the compiler know that it might be used, so let's mark
the structure as __maybe_unused.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-mvebu/coherency.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index 55348ee5a352..7e989d61159c 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -107,7 +107,7 @@ static struct notifier_block mvebu_hwcc_nb = {
 	.notifier_call = mvebu_hwcc_notifier,
 };
 
-static struct notifier_block mvebu_hwcc_pci_nb = {
+static struct notifier_block mvebu_hwcc_pci_nb __maybe_unused = {
 	.notifier_call = mvebu_hwcc_notifier,
 };
 
-- 
2.7.0



From arnd at arndb.de  Tue Feb 23 06:06:38 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 15:06:38 +0100
Subject: [PATCH 2/3] ARM: mv78xx0: avoid unused function warning
In-Reply-To: <1456236403-115511-1-git-send-email-arnd@arndb.de>
References: <1456236403-115511-1-git-send-email-arnd@arndb.de>
Message-ID: <1456236403-115511-3-git-send-email-arnd@arndb.de>

mv78xx0 produces a harmless warning when CONFIG_CACHE_FEROCEON_L2 is
disabled:

arch/arm/mach-mv78xx0/common.c:385:19: warning: 'is_l2_writethrough' defined but not used [-Wunused-function]

This avoids the warning by changing the #ifdef to an if(IS_ENABLED())
check with the same resulting object code.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-mv78xx0/common.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-mv78xx0/common.c b/arch/arm/mach-mv78xx0/common.c
index a1a04df9c05c..99cc93900a24 100644
--- a/arch/arm/mach-mv78xx0/common.c
+++ b/arch/arm/mach-mv78xx0/common.c
@@ -405,9 +405,8 @@ void __init mv78xx0_init(void)
 	printk("HCLK = %dMHz, ", (hclk + 499999) / 1000000);
 	printk("TCLK = %dMHz\n", (get_tclk() + 499999) / 1000000);
 
-#ifdef CONFIG_CACHE_FEROCEON_L2
-	feroceon_l2_init(is_l2_writethrough());
-#endif
+	if (IS_ENABLED(CONFIG_CACHE_FEROCEON_L2))
+		feroceon_l2_init(is_l2_writethrough());
 
 	/* Setup root of clk tree */
 	clk_init();
-- 
2.7.0



From arnd at arndb.de  Tue Feb 23 06:08:42 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 15:08:42 +0100
Subject: [PATCH] ARM: socfpga: hide unused functions
Message-ID: <1456236527-189885-1-git-send-email-arnd@arndb.de>

The cpu_die and cpu_kill callbacks are only used when CONFIG_HOTPLUG_CPU
is enabled, otherwise we get a warning about them:

arch/arm/mach-socfpga/platsmp.c:102:13: error: 'socfpga_cpu_die' defined but not used [-Werror=unused-function]
arch/arm/mach-socfpga/platsmp.c:115:12: error: 'socfpga_cpu_kill' defined but not used [-Werror=unused-function]

This adds the appropriate #ifdef.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-socfpga/platsmp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-socfpga/platsmp.c b/arch/arm/mach-socfpga/platsmp.c
index cbb0a54df80a..07945748b571 100644
--- a/arch/arm/mach-socfpga/platsmp.c
+++ b/arch/arm/mach-socfpga/platsmp.c
@@ -94,6 +94,7 @@ static void __init socfpga_smp_prepare_cpus(unsigned int max_cpus)
 	scu_enable(socfpga_scu_base_addr);
 }
 
+#ifdef CONFIG_HOTPLUG_CPU
 /*
  * platform-specific code to shutdown a CPU
  *
@@ -116,6 +117,7 @@ static int socfpga_cpu_kill(unsigned int cpu)
 {
 	return 1;
 }
+#endif
 
 static const struct smp_operations socfpga_smp_ops __initconst = {
 	.smp_prepare_cpus	= socfpga_smp_prepare_cpus,
-- 
2.7.0



From srinivas.kandagatla at linaro.org  Tue Feb 23 06:10:39 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 14:10:39 +0000
Subject: [PATCH 00/12] ARM: dts: apq8064: spi and i2c dt patches
Message-ID: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>

Hi Andy, 

Here are some apq8064 dts patches which are mostly to do with spi and i2c.

Most of the patches are additions of missing nodes required for ifc6410.

thanks,
srini

Srinivas Kandagatla (12):
  ARM: dts: qcom: fix i2c lables to be inline with others
  ARM: dts: apq8064: move pinctrls to dedicated dtsi
  ARM: dts: apq8064: add pci support in CM QS600
  ARM: dts: apq8064: add i2c sleep pinctrl states.
  ARM: dts: apq8064: add spi5 device node.
  ARM: dts: ifc6410: enable spi device on expansion
  ARM: dts: apq8064: add missing i2c2 pinctrl info
  ARM: dts: ifc6410: enable i2c2 on expansion connector
  ARM: dts: apq8064: add gsbi4 with i2c node.
  ARM: dts: ifc6410: enable cam i2c device
  ARM: dts: apq8064: add i2c6 device node.
  ARM: dts: ifc6410: add correct aliases to the i2c and spi bus

 arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts |  27 ++++
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts  |  35 ++++-
 arch/arm/boot/dts/qcom-apq8064-pins.dtsi    | 208 ++++++++++++++++++++++++++++
 arch/arm/boot/dts/qcom-apq8064.dtsi         | 126 ++++++++---------
 4 files changed, 329 insertions(+), 67 deletions(-)
 create mode 100644 arch/arm/boot/dts/qcom-apq8064-pins.dtsi

-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 06:11:10 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 14:11:10 +0000
Subject: [PATCH 01/12] ARM: dts: qcom: fix i2c lables to be inline with others
In-Reply-To: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456236670-1423-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch fixes i2c lables to be inline with serial labels.
The reason to do this is that it would look odd if we add aliases in the
board file along with serial.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 2 +-
 arch/arm/boot/dts/qcom-apq8064.dtsi        | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index fd4d49e..0073294 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -157,7 +157,7 @@
 		gsbi3: gsbi at 16200000 {
 			status = "okay";
 			qcom,mode = <GSBI_PROT_I2C>;
-			i2c3: i2c at 16280000 {
+			i2c at 16280000 {
 				status = "okay";
 			};
 		};
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 394c43b..a7af35d 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -281,7 +281,7 @@
 
 			syscon-tcsr = <&tcsr>;
 
-			i2c1: i2c at 12460000 {
+			gsbi1_i2c: i2c at 12460000 {
 				compatible = "qcom,i2c-qup-v1.1.1";
 				pinctrl-0 = <&i2c1_pins>;
 				pinctrl-names = "default";
@@ -307,7 +307,7 @@
 
 			syscon-tcsr = <&tcsr>;
 
-			i2c2: i2c at 124a0000 {
+			gsbi2_i2c: i2c at 124a0000 {
 				compatible = "qcom,i2c-qup-v1.1.1";
 				reg = <0x124a0000 0x1000>;
 				interrupts = <0 196 IRQ_TYPE_NONE>;
@@ -328,7 +328,7 @@
 			#address-cells = <1>;
 			#size-cells = <1>;
 			ranges;
-			i2c3: i2c at 16280000 {
+			gsbi3_i2c: i2c at 16280000 {
 				compatible = "qcom,i2c-qup-v1.1.1";
 				pinctrl-0 = <&i2c3_pins>;
 				pinctrl-names = "default";
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 06:14:07 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 14:14:07 +0000
Subject: [PATCH 02/12] ARM: dts: apq8064: move pinctrls to dedicated dtsi
In-Reply-To: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456236847-2445-1-git-send-email-srinivas.kandagatla@linaro.org>

As there are more pinctrls to come, moving these to dedicated dtsi makes
more sense.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm/boot/dts/qcom-apq8064-pins.dtsi | 58 ++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/qcom-apq8064.dtsi      | 57 +------------------------------
 2 files changed, 59 insertions(+), 56 deletions(-)
 create mode 100644 arch/arm/boot/dts/qcom-apq8064-pins.dtsi

diff --git a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
new file mode 100644
index 0000000..c711aca
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
@@ -0,0 +1,58 @@
+
+&tlmm_pinmux {
+	sdc4_gpios: sdc4-gpios {
+		pios {
+			pins = "gpio63", "gpio64", "gpio65", "gpio66", "gpio67", "gpio68";
+			function = "sdc4";
+		};
+	};
+
+	ps_hold: ps_hold {
+		mux {
+			pins = "gpio78";
+			function = "ps_hold";
+		};
+	};
+
+	i2c1_pins: i2c1 {
+		mux {
+			pins = "gpio20", "gpio21";
+			function = "gsbi1";
+		};
+	};
+
+	i2c3_pins: i2c3 {
+		mux {
+			pins = "gpio8", "gpio9";
+			function = "gsbi3";
+		};
+	};
+
+	gsbi6_uart_2pins: gsbi6_uart_2pins {
+		mux {
+			pins = "gpio14", "gpio15";
+			function = "gsbi6";
+		};
+	};
+
+	gsbi6_uart_4pins: gsbi6_uart_4pins {
+		mux {
+			pins = "gpio14", "gpio15", "gpio16", "gpio17";
+			function = "gsbi6";
+		};
+	};
+
+	gsbi7_uart_2pins: gsbi7_uart_2pins {
+		mux {
+			pins = "gpio82", "gpio83";
+			function = "gsbi7";
+		};
+	};
+
+	gsbi7_uart_4pins: gsbi7_uart_4pins {
+		mux {
+			pins = "gpio82", "gpio83", "gpio84", "gpio85";
+			function = "gsbi7";
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
index a7af35d..3d95534b 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -142,62 +142,6 @@
 
 			pinctrl-names = "default";
 			pinctrl-0 = <&ps_hold>;
-
-			sdc4_gpios: sdc4-gpios {
-				pios {
-					pins = "gpio63", "gpio64", "gpio65", "gpio66", "gpio67", "gpio68";
-					function = "sdc4";
-				};
-			};
-
-			ps_hold: ps_hold {
-				mux {
-					pins = "gpio78";
-					function = "ps_hold";
-				};
-			};
-
-			i2c1_pins: i2c1 {
-				mux {
-					pins = "gpio20", "gpio21";
-					function = "gsbi1";
-				};
-			};
-
-			i2c3_pins: i2c3 {
-				mux {
-					pins = "gpio8", "gpio9";
-					function = "gsbi3";
-				};
-			};
-
-			gsbi6_uart_2pins: gsbi6_uart_2pins {
-				mux {
-					pins = "gpio14", "gpio15";
-					function = "gsbi6";
-				};
-			};
-
-			gsbi6_uart_4pins: gsbi6_uart_4pins {
-				mux {
-					pins = "gpio14", "gpio15", "gpio16", "gpio17";
-					function = "gsbi6";
-				};
-			};
-
-			gsbi7_uart_2pins: gsbi7_uart_2pins {
-				mux {
-					pins = "gpio82", "gpio83";
-					function = "gsbi7";
-				};
-			};
-
-			gsbi7_uart_4pins: gsbi7_uart_4pins {
-				mux {
-					pins = "gpio82", "gpio83", "gpio84", "gpio85";
-					function = "gsbi7";
-				};
-			};
 		};
 
 		sfpb_wrapper_mutex: syscon at 1200000 {
@@ -828,3 +772,4 @@
 		};
 	};
 };
+#include "qcom-apq8064-pins.dtsi"
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 06:14:14 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 14:14:14 +0000
Subject: [PATCH 03/12] ARM: dts: apq8064: add pci support in CM QS600
In-Reply-To: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456236854-2511-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds PCIE support to APQ8064, tested with Ethernet on
Compulab QS600 board.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
index 21095da..35f1d46 100644
--- a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
@@ -37,6 +37,18 @@
 					bias-disable;
 				};
 			};
+
+			pcie_pins: pcie_pinmux {
+				mux {
+					pins = "gpio27";
+					function = "gpio";
+				};
+				conf {
+					pins = "gpio27";
+					drive-strength = <12>;
+					bias-disable;
+				};
+			};
 		};
 
 		rpm at 108000 {
@@ -103,6 +115,11 @@
 					regulator-max-microvolt = <1900000>;
 					bias-pull-down;
 				};
+
+				pm8921_lvs6: lvs6 {
+					bias-pull-down;
+				};
+
 			};
 		};
 
@@ -195,6 +212,16 @@
 			};
 		};
 
+		pci at 1b500000 {
+			status = "ok";
+			vdda-supply = <&pm8921_s3>;
+			vdda_phy-supply = <&pm8921_lvs6>;
+			vdda_refclk-supply = <&v3p3_fixed>;
+			pinctrl-0 = <&pcie_pins>;
+			pinctrl-names = "default";
+			perst-gpio = <&tlmm_pinmux 27 GPIO_ACTIVE_LOW>;
+		};
+
 		amba {
 			/* eMMC */
 			sdcc1: sdcc at 12400000 {
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 06:14:26 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 14:14:26 +0000
Subject: [PATCH 04/12] ARM: dts: apq8064: add i2c sleep pinctrl states.
In-Reply-To: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456236866-2588-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds missing i2c pinctrl sleep states.
Also add 16mA drive strength to the pins so that we can detect wide
range of i2c devices on the other side of level shifters.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm/boot/dts/qcom-apq8064-pins.dtsi | 36 ++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/qcom-apq8064.dtsi      |  8 +++----
 2 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
index c711aca..ce15c67 100644
--- a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
@@ -19,6 +19,24 @@
 			pins = "gpio20", "gpio21";
 			function = "gsbi1";
 		};
+
+		pinconf {
+			pins = "gpio20", "gpio21";
+			drive-strength = <16>;
+			bias-disable;
+		};
+	};
+
+	i2c1_pins_sleep: i2c1_pins_sleep {
+		mux {
+			pins = "gpio20", "gpio21";
+			function = "gpio";
+		};
+		pinconf {
+			pins = "gpio20", "gpio21";
+			drive-strength = <2>;
+			bias-disable = <0>;
+		};
 	};
 
 	i2c3_pins: i2c3 {
@@ -26,6 +44,24 @@
 			pins = "gpio8", "gpio9";
 			function = "gsbi3";
 		};
+
+		pinconf {
+			pins = "gpio8", "gpio9";
+			drive-strength = <16>;
+			bias-disable;
+		};
+	};
+
+	i2c3_pins_sleep: i2c3_pins_sleep {
+		mux {
+			pins = "gpio8", "gpio9";
+			function = "gpio";
+		};
+		pinconf {
+			pins = "gpio8", "gpio9";
+			drive-strength = <2>;
+			bias-disable = <0>;
+		};
 	};
 
 	gsbi6_uart_2pins: gsbi6_uart_2pins {
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 3d95534b..3fb66b9 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -227,8 +227,8 @@
 
 			gsbi1_i2c: i2c at 12460000 {
 				compatible = "qcom,i2c-qup-v1.1.1";
-				pinctrl-0 = <&i2c1_pins>;
-				pinctrl-names = "default";
+				pinctrl-0 = <&i2c1_pins &i2c1_pins_sleep>;
+				pinctrl-names = "default", "sleep";
 				reg = <0x12460000 0x1000>;
 				interrupts = <0 194 IRQ_TYPE_NONE>;
 				clocks = <&gcc GSBI1_QUP_CLK>, <&gcc GSBI1_H_CLK>;
@@ -274,8 +274,8 @@
 			ranges;
 			gsbi3_i2c: i2c at 16280000 {
 				compatible = "qcom,i2c-qup-v1.1.1";
-				pinctrl-0 = <&i2c3_pins>;
-				pinctrl-names = "default";
+				pinctrl-0 = <&i2c3_pins &i2c3_pins_sleep>;
+				pinctrl-names = "default", "sleep";
 				reg = <0x16280000 0x1000>;
 				interrupts = <GIC_SPI 151 IRQ_TYPE_NONE>;
 				clocks = <&gcc GSBI3_QUP_CLK>,
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 06:14:33 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 14:14:33 +0000
Subject: [PATCH 05/12] ARM: dts: apq8064: add spi5 device node.
In-Reply-To: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456236873-2649-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds spi5 device node, spi5 is used on ifc6410 on the
expansion connector.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm/boot/dts/qcom-apq8064-pins.dtsi | 38 ++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/qcom-apq8064.dtsi      | 14 ++++++++++++
 2 files changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
index ce15c67..0b7b10e 100644
--- a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
@@ -64,6 +64,44 @@
 		};
 	};
 
+	spi5_default: spi5_default {
+		pinmux {
+			pins = "gpio51", "gpio52", "gpio54";
+			function = "gsbi5";
+		};
+
+		pinmux_cs {
+			function = "gpio";
+			pins = "gpio53";
+		};
+
+		pinconf {
+			pins = "gpio51", "gpio52", "gpio54";
+			drive-strength = <16>;
+			bias-disable;
+		};
+
+		pinconf_cs {
+			pins = "gpio53";
+			drive-strength = <16>;
+			bias-disable;
+			output-high;
+		};
+	};
+
+	spi5_sleep: spi5_sleep {
+		pinmux {
+			function = "gpio";
+			pins = "gpio51", "gpio52", "gpio53", "gpio54";
+		};
+
+		pinconf {
+			pins = "gpio51", "gpio52", "gpio53", "gpio54";
+			drive-strength = <2>;
+			bias-pull-down;
+		};
+	};
+
 	gsbi6_uart_2pins: gsbi6_uart_2pins {
 		mux {
 			pins = "gpio14", "gpio15";
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 3fb66b9..3fefb2e 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -236,6 +236,7 @@
 				#address-cells = <1>;
 				#size-cells = <0>;
 			};
+
 		};
 
 		gsbi2: gsbi at 12480000 {
@@ -304,6 +305,19 @@
 				clock-names = "core", "iface";
 				status = "disabled";
 			};
+
+			gsbi5_spi: spi at 1a280000 {
+				compatible = "qcom,spi-qup-v1.1.1";
+				reg = <0x1a280000 0x1000>;
+				interrupts = <0 155 0>;
+				pinctrl-0 = <&spi5_default &spi5_sleep>;
+				pinctrl-names = "default", "sleep";
+				clocks = <&gcc GSBI5_QUP_CLK>, <&gcc GSBI5_H_CLK>;
+				clock-names = "core", "iface";
+				status = "disabled";
+				#address-cells = <1>;
+				#size-cells = <0>;
+			};
 		};
 
 		gsbi6: gsbi at 16500000 {
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 06:14:39 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 14:14:39 +0000
Subject: [PATCH 06/12] ARM: dts: ifc6410: enable spi device on expansion
In-Reply-To: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456236879-2698-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch enables spi device on the 30 pin expansion connector.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 0073294..8de774c 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -178,6 +178,16 @@
 			};
 		};
 
+		gsbi at 1a200000 {
+			qcom,mode = <GSBI_PROT_SPI>;
+			status = "okay";
+			spi4: spi at 1a280000 {
+				status = "okay";
+				num-cs = <1>;
+				cs-gpios = <&tlmm_pinmux 53 0>;
+			};
+		};
+
 		gsbi at 16500000 {
 			status = "ok";
 			qcom,mode = <GSBI_PROT_UART_W_FC>;
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 06:14:45 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 14:14:45 +0000
Subject: [PATCH 07/12] ARM: dts: apq8064: add missing i2c2 pinctrl info
In-Reply-To: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456236885-2741-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds missing i2c2 pinctrl information in i2c2 node.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm/boot/dts/qcom-apq8064-pins.dtsi | 26 ++++++++++++++++++++++++++
 arch/arm/boot/dts/qcom-apq8064.dtsi      |  2 ++
 2 files changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
index 0b7b10e..0a342d3 100644
--- a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
@@ -39,6 +39,32 @@
 		};
 	};
 
+	i2c2_pins: i2c2 {
+		mux {
+			pins = "gpio24", "gpio25";
+			function = "gsbi2";
+		};
+
+		pinconf {
+			pins = "gpio24", "gpio25";
+			drive-strength = <16>;
+			bias-disable;
+		};
+	};
+
+	i2c2_pins_sleep: i2c2_pins_sleep {
+		mux {
+			pins = "gpio24", "gpio25";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio24", "gpio25";
+			drive-strength = <2>;
+			bias-disable = <0>;
+		};
+	};
+
 	i2c3_pins: i2c3 {
 		mux {
 			pins = "gpio8", "gpio9";
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 3fefb2e..2367adc 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -255,6 +255,8 @@
 			gsbi2_i2c: i2c at 124a0000 {
 				compatible = "qcom,i2c-qup-v1.1.1";
 				reg = <0x124a0000 0x1000>;
+				pinctrl-0 = <&i2c2_pins &i2c2_pins_sleep>;
+				pinctrl-names = "default", "sleep";
 				interrupts = <0 196 IRQ_TYPE_NONE>;
 				clocks = <&gcc GSBI2_QUP_CLK>, <&gcc GSBI2_H_CLK>;
 				clock-names = "core", "iface";
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 06:14:50 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 14:14:50 +0000
Subject: [PATCH 09/12] ARM: dts: apq8064: add gsbi4 with i2c node.
In-Reply-To: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456236890-2783-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds gsbi4 and i2c node.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm/boot/dts/qcom-apq8064-pins.dtsi | 25 +++++++++++++++++++++++++
 arch/arm/boot/dts/qcom-apq8064.dtsi      | 23 +++++++++++++++++++++++
 2 files changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
index 0a342d3..0cb22cf 100644
--- a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
@@ -90,6 +90,31 @@
 		};
 	};
 
+	i2c4_pins: i2c4 {
+		mux {
+			pins = "gpio12", "gpio13";
+			function = "gsbi4";
+		};
+
+		pinconf {
+			pins = "gpio12", "gpio13";
+			drive-strength = <16>;
+			bias-disable;
+		};
+	};
+
+	i2c4_pins_sleep: i2c4_pins_sleep {
+		mux {
+			pins = "gpio12", "gpio13";
+			function = "gpio";
+		};
+		pinconf {
+			pins = "gpio12", "gpio13";
+			drive-strength = <2>;
+			bias-disable = <0>;
+		};
+	};
+
 	spi5_default: spi5_default {
 		pinmux {
 			pins = "gpio51", "gpio52", "gpio54";
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 2367adc..445297c 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -287,6 +287,29 @@
 			};
 		};
 
+		gsbi4: gsbi at 16300000 {
+			status = "disabled";
+			compatible = "qcom,gsbi-v1.0.0";
+			cell-index = <4>;
+			reg = <0x16300000 0x03>;
+			clocks = <&gcc GSBI4_H_CLK>;
+			clock-names = "iface";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			gsbi4_i2c: i2c at 16380000 {
+				compatible = "qcom,i2c-qup-v1.1.1";
+				pinctrl-0 = <&i2c4_pins &i2c4_pins_sleep>;
+				pinctrl-names = "default", "sleep";
+				reg = <0x16380000 0x1000>;
+				interrupts = <GIC_SPI 153 IRQ_TYPE_NONE>;
+				clocks = <&gcc GSBI4_QUP_CLK>,
+					 <&gcc GSBI4_H_CLK>;
+				clock-names = "core", "iface";
+			};
+		};
+
 		gsbi5: gsbi at 1a200000 {
 			status = "disabled";
 			compatible = "qcom,gsbi-v1.0.0";
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 06:14:56 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 14:14:56 +0000
Subject: [PATCH 10/12] ARM: dts: ifc6410: enable cam i2c device
In-Reply-To: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456236896-2826-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch enables i2c bus for camera via mipi-csi connector on ifc6410.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 949aa04..6a43b0b 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -162,6 +162,15 @@
 			};
 		};
 
+		gsbi at 16300000 {
+			status = "okay";
+			qcom,mode = <GSBI_PROT_I2C>;
+			/* CAM I2C MIPI-CSI connector */
+			i2c at 16380000 {
+				status = "okay";
+			};
+		};
+
 		gsbi at 12440000 {
 			status = "okay";
 			qcom,mode = <GSBI_PROT_I2C>;
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 06:15:08 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 14:15:08 +0000
Subject: [PATCH 12/12] ARM: dts: ifc6410: add correct aliases to the i2c and
 spi bus
In-Reply-To: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456236908-2927-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds correct aliases to spi and i2c buses so that they get
correct matching bus numbers.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 6a43b0b..8032686 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -9,6 +9,11 @@
 	aliases {
 		serial0 = &gsbi7_serial;
 		serial1 = &gsbi6_serial;
+		i2c0 = &gsbi1_i2c;
+		i2c1 = &gsbi2_i2c;
+		i2c2 = &gsbi3_i2c;
+		i2c3 = &gsbi4_i2c;
+		spi0 = &gsbi5_spi;
 	};
 
 	chosen {
-- 
1.9.1



From marc.zyngier at arm.com  Tue Feb 23 06:14:54 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 23 Feb 2016 14:14:54 +0000
Subject: [PATCH v12 16/21] KVM: ARM64: Add PMU overflow interrupt routing
In-Reply-To: <1456133877-9584-17-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
 <1456133877-9584-17-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <56CC695E.4010805@arm.com>

On 22/02/16 09:37, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
> 
> When calling perf_event_create_kernel_counter to create perf_event,
> assign a overflow handler. Then when the perf event overflows, set the
> corresponding bit of guest PMOVSSET register. If this counter is enabled
> and its interrupt is enabled as well, kick the vcpu to sync the
> interrupt.
> 
> On VM entry, if there is counter overflowed, inject the interrupt with
> the level set to 1. Otherwise, inject the interrupt with the level set
> to 0.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
> Reviewed-by: Andrew Jones <drjones at redhat.com>

As I mentioned yesterday, I was trying to pinpoint a performance drop, so I added PMU support to kvmtool (and made it an optional flag). This allowed be to find this:

> ---
>  arch/arm/kvm/arm.c    |  2 ++
>  include/kvm/arm_pmu.h |  2 ++
>  virt/kvm/arm/pmu.c    | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
>  3 files changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index dda1959..f54264c 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -28,6 +28,7 @@
>  #include <linux/sched.h>
>  #include <linux/kvm.h>
>  #include <trace/events/kvm.h>
> +#include <kvm/arm_pmu.h>
>  
>  #define CREATE_TRACE_POINTS
>  #include "trace.h"
> @@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  		 * non-preemptible context.
>  		 */
>  		preempt_disable();
> +		kvm_pmu_flush_hwstate(vcpu);
>  		kvm_timer_flush_hwstate(vcpu);
>  		kvm_vgic_flush_hwstate(vcpu);
>  
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 8bc92d1..cf68f9a 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -44,6 +44,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
>  void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
>  void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> @@ -67,6 +68,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
>  static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
> +static inline void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
>  static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index cda869c..6ac52ce 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -21,6 +21,7 @@
>  #include <linux/perf_event.h>
>  #include <asm/kvm_emulate.h>
>  #include <kvm/arm_pmu.h>
> +#include <kvm/arm_vgic.h>
>  
>  /**
>   * kvm_pmu_get_counter_value - get PMU counter value
> @@ -181,6 +182,49 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
>  }
>  
>  /**
> + * kvm_pmu_flush_hwstate - flush pmu state to cpu
> + * @vcpu: The vcpu pointer
> + *
> + * Inject virtual PMU IRQ if IRQ is pending for this cpu.
> + */
> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
> +{
> +	struct kvm_pmu *pmu = &vcpu->arch.pmu;
> +	u64 overflow;
> +
> +	if (!kvm_arm_pmu_v3_ready(vcpu))
> +		return;
> +
> +	overflow = kvm_pmu_overflow_status(vcpu);
> +	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id, pmu->irq_num, !!overflow);

It turns out that this single line costs us about 400 cycles on each entry:

maz at flakes:~/kvm-ws-tests$ make LKVM=~/kvmtool/lkvm LKVM_ARGS=--pmu PERF=perf_4.3 tests-gicv2
GICv2:
do_hvc.bin:5690.17
do_sgi.bin:9395.05
do_sysreg.bin:5912.6
maz at flakes:~/kvm-ws-tests$ make LKVM=~/kvmtool/lkvm PERF=perf_4.3 tests-gicv2
GICv2:
do_hvc.bin:5285.02
do_sgi.bin:9131.24
do_sysreg.bin:5563.7

Caching the irq state and only injecting it if it has changed (just like we do for the timer) brings performance back to its previous level:

diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 176913f..b23e636 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -35,6 +35,7 @@ struct kvm_pmu {
 	int irq_num;
 	struct kvm_pmc pmc[ARMV8_PMU_MAX_COUNTERS];
 	bool ready;
+	bool irq_level;
 };
 
 #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 904617e..7156f8b 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -229,13 +229,17 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
 void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
 {
 	struct kvm_pmu *pmu = &vcpu->arch.pmu;
-	u64 overflow;
+	bool overflow;
 
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return;
 
-	overflow = kvm_pmu_overflow_status(vcpu);
-	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id, pmu->irq_num, !!overflow);
+	overflow = !!kvm_pmu_overflow_status(vcpu);
+	if (pmu->irq_level != overflow) {
+		pmu->irq_level = overflow;
+		kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
+				    pmu->irq_num, overflow);
+	}
 }
 
 static inline struct kvm_vcpu *kvm_pmc_to_vcpu(struct kvm_pmc *pmc)


Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From srinivas.kandagatla at linaro.org  Tue Feb 23 06:15:03 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 14:15:03 +0000
Subject: [PATCH 11/12] ARM: dts: apq8064: add i2c6 device node.
In-Reply-To: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456236639-1379-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456236903-2878-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds i2c6 device node and pinctrls required for IFC6410 on
MIPI-CSI connector.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm/boot/dts/qcom-apq8064-pins.dtsi | 25 +++++++++++++++++++++++++
 arch/arm/boot/dts/qcom-apq8064.dtsi      | 11 +++++++++++
 2 files changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
index 0cb22cf..b57c59d 100644
--- a/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064-pins.dtsi
@@ -153,6 +153,31 @@
 		};
 	};
 
+	i2c6_pins: i2c6 {
+		mux {
+			pins = "gpio16", "gpio17";
+			function = "gsbi6";
+		};
+
+		pinconf {
+			pins = "gpio16", "gpio17";
+			drive-strength = <16>;
+			bias-disable;
+		};
+	};
+
+	i2c6_pins_sleep: i2c6_pins_sleep {
+		mux {
+			pins = "gpio16", "gpio17";
+			function = "gpio";
+		};
+		pinconf {
+			pins = "gpio16", "gpio17";
+			drive-strength = <2>;
+			bias-disable = <0>;
+		};
+	};
+
 	gsbi6_uart_2pins: gsbi6_uart_2pins {
 		mux {
 			pins = "gpio14", "gpio15";
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 445297c..5540b34 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -365,6 +365,17 @@
 				clock-names = "core", "iface";
 				status = "disabled";
 			};
+
+			gsbi6_i2c: i2c at 16580000 {
+				compatible = "qcom,i2c-qup-v1.1.1";
+				pinctrl-0 = <&i2c6_pins &i2c6_pins_sleep>;
+				pinctrl-names = "default", "sleep";
+				reg = <0x16580000 0x1000>;
+				interrupts = <GIC_SPI 157 IRQ_TYPE_NONE>;
+				clocks = <&gcc GSBI6_QUP_CLK>,
+					 <&gcc GSBI6_H_CLK>;
+				clock-names = "core", "iface";
+			};
 		};
 
 		gsbi7: gsbi at 16600000 {
-- 
1.9.1



From shankerd at codeaurora.org  Tue Feb 23 06:15:35 2016
From: shankerd at codeaurora.org (Shanker Donthineni)
Date: Tue, 23 Feb 2016 08:15:35 -0600
Subject: [PATCH] irqchip/gicv3-its: Don't allow devices whose ID is
 outside range
In-Reply-To: <56CC1D83.4060503@arm.com>
References: <1456199868-9054-1-git-send-email-shankerd@codeaurora.org>
 <56CC1D83.4060503@arm.com>
Message-ID: <56CC6987.1050107@codeaurora.org>

Hi Marc,

On 02/23/2016 02:51 AM, Marc Zyngier wrote:
> On 23/02/16 03:57, Shanker Donthineni wrote:
>> We are not checking whether the requested device identifier fits into
>> table or not. The ITS MAPD command fails if 'Device ID' is outside of
>> device table range.
>>
>> Add a simple validation check to avoid MAPD failures since we are
>> not handling ITS command errors. This change also helps to return an
>> error -ENOMEM instead of success to caller.
>>
> In which circumstances do you see this failing? We allocate memory for
> the whole DevID range (as advertised by the ITS), so anything that comes
> up outside of that range cannot be handled anyway, and is a HW
> integration issue. You might as well pretend that these devices do not
> exist.
>
> Thanks,
>
> 	M.
We will try to allocate maximum memory as much as possible to cover 
whole DevID.
sparse. We may not always successful, sometimes we limit memory 
allocation size
for two reasons MAX_ORDER and ITS flat table capacity.

1) According to ARM-GIC spec, ITS hw can access maximum of 256 (ITS-pages) *
    64K (ITS-pageszie) bytes.

     21bits = 16 MBytes / 8 (flat table size / device table entry size)

Assuming: minimum device table entry size 8 Bytes

2) On 4K page size kernel with default arch/arm64/defconfig.

    19bits = 4 MBytes / 8 (flat table size / device table entry size)

Assuming: minimum device table entry size 8 Bytes

This is definitely a problem if DevID range is much more than 19Bits and 
we fail to allocate
enough memory. Our ITS hardware has capable of supporting all 32bits, so 
it advertises
DevID 32.

I am preparing an another patch to support ITS-Indirection (two-level 
table walk) feature.

-- 
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project



From linux.amoon at gmail.com  Tue Feb 23 06:16:31 2016
From: linux.amoon at gmail.com (Anand Moon)
Date: Tue, 23 Feb 2016 19:46:31 +0530
Subject: [PATCH] ARM: dts: add support for gpio buttons for
 exynos5422-odroidxu3
In-Reply-To: <CAJKOXPftm7P44Zxn9rHt1THJOX3Oxu-mg5GD7=T3se4iRe1DkA@mail.gmail.com>
References: <1456214467-3344-1-git-send-email-linux.amoon@gmail.com>
 <56CC167A.8040303@samsung.com> <56CC194F.6080905@samsung.com>
 <CANAwSgTRu6pb9cdA50AzBSNLS+Y+sssyc_CX7FKuV=FDYWaOsA@mail.gmail.com>
 <CAJKOXPftm7P44Zxn9rHt1THJOX3Oxu-mg5GD7=T3se4iRe1DkA@mail.gmail.com>
Message-ID: <CANAwSgR17csDub4fszP5+=M5qrG5FbHu=rmfny6-5e8x6bWBFg@mail.gmail.com>

Hi Krzysztof,

On 23 February 2016 at 17:32, Krzysztof Kozlowski
<k.kozlowski at samsung.com> wrote:
> 2016-02-23 18:17 GMT+09:00 Anand Moon <linux.amoon at gmail.com>:
>> Hi Krzysztof,
>>
>> On 23 February 2016 at 14:03, Krzysztof Kozlowski
>>>>>      };
>>>>> +
>>>>> +    gpio_keys {
>>>>> +            compatible = "gpio-keys";
>>>>> +            pinctrl-names = "default";
>>>>> +            pinctrl-0 = <&gpio_power_key>;
>>>>> +
>>>>> +            power_key {
>>>>> +                    interrupt-parent = <&gpx0>;
>>>>> +                    interrupts = <3 IRQ_TYPE_NONE>;
>>>>
>>>> Hmmm.... why you specify the interrupts?
>>>>
>>>>> +                    gpios = <&gpx0 3 GPIO_ACTIVE_LOW>;
>>>
>>> Please, explain it to me. The SW2 key is connected to PWRON of PMIC.
>>> However you are adding a GPIO key for external interrupt source 3
>>> (XE.INT3)... which comes from PMIC's ONOB.
>>>
>>> It's interesting.... how does it work? The PMIC will generate ONOB
>>> interrupt on PWRON low->high change (when PWRHOLD is high)?
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>> I have re-base my changes on HK dts.
>> I could not find much details for the schematic diagram.
>> I don't know much low level detains on this.
>
> If I understand this correctly: you just took some vendor code,
> similar to existing code of Odroid U3, and without full understanding
> of the code nor checking with public schematics, you sent it.
>
> Taking vendor stuff is okay but you need to think about it, use it as
> an example and deliver proper solution based on that. Not copy-paste.
>
>> How dose this works: This changes will initial the shudown/reboot on Ubuntu.
>> I have also tested this similar feature on Odroid U3.
>
> Great :), yes it works because ONOB interrupt from PMIC is generated
> on key press. However this is not a strictly speaking key... I don't
> really know what to do with this commit and your explanation
> (Hardkernel has such code) is not sufficient to convince me.
>
> Best regards,
> Krzysztof

Nothing come easy to me, I had to do bit of work on this.
Internally I might not know the detail of the board and features of
the registers of the PMIC.
I have to improvise some time for changes. I don't know who is the
original author of the code.

It's relay hard to convince you on the changes, as I continue to
repeat the mistake.
I will try to improve my commits a be specific to the changes in the future.

Best Regards,
-Anand Moon


From andrew at lunn.ch  Tue Feb 23 06:27:56 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 23 Feb 2016 15:27:56 +0100
Subject: [PATCH 0/3] ARM: mvebu: randconfig warning fixes
In-Reply-To: <1456236403-115511-1-git-send-email-arnd@arndb.de>
References: <1456236403-115511-1-git-send-email-arnd@arndb.de>
Message-ID: <20160223142756.GA25137@lunn.ch>

On Tue, Feb 23, 2016 at 03:06:36PM +0100, Arnd Bergmann wrote:
> Here are three more warning fixes for orion/mv78xx0/mvebu. All
> are really harmless and I'm just shutting up the warnings
> as the current code is basically ok.

Hi Arnd

Reviewed-by: Andrew Lunn <andrew at lunn.ch>

Thanks
	Andrew


From arnd at arndb.de  Tue Feb 23 06:32:01 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 15:32:01 +0100
Subject: [PATCH] ARM: sirf: mark sirfsoc_init_late as __maybe_unused
Message-ID: <1456237925-727550-1-git-send-email-arnd@arndb.de>

sirfsoc_init_late is called by each of the three individual
SoC definitions, but in a randconfig build, we can encounter
a situation where they are all disabled:

arch/arm/mach-prima2/common.c:18:123: warning: 'sirfsoc_init_late' defined but not used [-Wunused-function]

While that is not a useful configuration, the warning also
doesn't help, so this patch marks the function as __maybe_unused
to let the compiler know it is there intentionally.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-prima2/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-prima2/common.c b/arch/arm/mach-prima2/common.c
index 8cadb302a7d2..ffe05c27087e 100644
--- a/arch/arm/mach-prima2/common.c
+++ b/arch/arm/mach-prima2/common.c
@@ -15,7 +15,7 @@
 #include <linux/of_platform.h>
 #include "common.h"
 
-static void __init sirfsoc_init_late(void)
+static void __init __maybe_unused sirfsoc_init_late(void)
 {
 	sirfsoc_pm_init();
 }
-- 
2.7.0



From arnd at arndb.de  Tue Feb 23 06:34:45 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 15:34:45 +0100
Subject: [PATCH] ARM: sa1100: make sa1100_register_uart_fns a function
Message-ID: <1456238094-778916-1-git-send-email-arnd@arndb.de>

Calling sa1100_register_uart_fns() leaves the port structure
unused when CONFIG_SERIAL_SA1100 is disabled, and we get a
compiler warning about that:

arch/arm/mach-sa1100/badge4.c:317:31: warning: 'badge4_port_fns' defined but not used [-Wunused-variable]
 static struct sa1100_port_fns badge4_port_fns __initdata = {

This turns the two empty macros into empty inline functions,
which has the same effect, but lets the compiler know that the
variables are intentionally unused.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 include/linux/platform_data/sa11x0-serial.h | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/linux/platform_data/sa11x0-serial.h b/include/linux/platform_data/sa11x0-serial.h
index 4504d5d592f0..009e1d83fe39 100644
--- a/include/linux/platform_data/sa11x0-serial.h
+++ b/include/linux/platform_data/sa11x0-serial.h
@@ -26,8 +26,12 @@ struct sa1100_port_fns {
 void sa1100_register_uart_fns(struct sa1100_port_fns *fns);
 void sa1100_register_uart(int idx, int port);
 #else
-#define sa1100_register_uart_fns(fns) do { } while (0)
-#define sa1100_register_uart(idx,port) do { } while (0)
+static inline void sa1100_register_uart_fns(struct sa1100_port_fns *fns)
+{
+}
+static inline void sa1100_register_uart(int idx, int port)
+{
+}
 #endif
 
 #endif
-- 
2.7.0



From arnd at arndb.de  Tue Feb 23 06:35:35 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 15:35:35 +0100
Subject: [PATCH] ARM: rpc: rename RAM_SIZE macro
Message-ID: <1456238141-794068-1-git-send-email-arnd@arndb.de>

The RAM_SIZE macro in mach/hardware.h conflicts with macros of
the same name in multiple drivers, leading to annoying build warnings:

In file included from drivers/net/ethernet/cirrus/cs89x0.c:79:0:
drivers/net/ethernet/cirrus/cs89x0.h:324:0: error: "RAM_SIZE" redefined [-Werror]
 #define RAM_SIZE 0x1000       /*  The card has 4k bytes or RAM */
 ^
In file included from /git/arm-soc/arch/arm/mach-rpc/include/mach/io.h:16:0,
                 from /git/arm-soc/arch/arm/include/asm/io.h:194,
                 from /git/arm-soc/include/linux/scatterlist.h:8,
                 from /git/arm-soc/include/linux/dmaengine.h:24,
                 from /git/arm-soc/include/linux/netdevice.h:38,
                 from /git/arm-soc/drivers/net/ethernet/cirrus/cs89x0.c:54:
arch/arm/mach-rpc/include/mach/hardware.h:28:0: note: this is the location of the previous definition
 #define RAM_SIZE  0x10000000

We don't use RAM_SIZE/RAM_START at all, so we could just remove
them, but it might be nice to leave them for documentation purposes,
so this renames them to RPC_RAM_SIZE/RPC_RAM_START in order to
avoid the build warnings

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-rpc/include/mach/hardware.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-rpc/include/mach/hardware.h b/arch/arm/mach-rpc/include/mach/hardware.h
index 257166b21f3d..39459eed2973 100644
--- a/arch/arm/mach-rpc/include/mach/hardware.h
+++ b/arch/arm/mach-rpc/include/mach/hardware.h
@@ -25,8 +25,8 @@
  *  *_SIZE  is the size of the region
  *  *_BASE  is the virtual address
  */
-#define RAM_SIZE		0x10000000
-#define RAM_START		0x10000000
+#define RPC_RAM_SIZE		0x10000000
+#define RPC_RAM_START		0x10000000
 
 #define EASI_SIZE		0x08000000	/* EASI I/O */
 #define EASI_START		0x08000000
-- 
2.7.0



From vladimir.murzin at arm.com  Tue Feb 23 06:34:18 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 23 Feb 2016 14:34:18 +0000
Subject: [PATCH v4 00/10] Support for Cortex-M Prototyping System
Message-ID: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>

Hi,

This patch series provide the basic support for running ucLinux on V2M-MPS2
platform.

With these patches applied ucLinux can be run on both HW and FVP models
with Cortex-M3/M4/M7 configurations.

Board description:

http://infocenter.arm.com/help/topic/com.arm.doc.100112_0100_03_en/arm_versatile_express_cortex_m_prototyping_system_(v2m_mps2)_technical_reference_manual_100112_0100_03_en.pdf

Application notes (cover Cortex-M3/M4/M7):

http://infocenter.arm.com/help/topic/com.arm.doc.dai0385a/DAI0385A_cortex_m3_on_v2m_mps2.pdf
http://infocenter.arm.com/help/topic/com.arm.doc.dai0386a/DAI0386A_cortex_m4_on_v2m_mps2.pdf
http://infocenter.arm.com/help/topic/com.arm.doc.dai0399a/DAI0399A_cortex_m7_on_v2m_mps2.pdf
http://infocenter.arm.com/help/topic/com.arm.doc.dai0400a/DAI0400A_cortex_m7_on_v2m_mps2.pdf

Cortex-M System Design Kit (referenced as CMDK from documents above):

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0479c/DDI0479C_cortex_m_system_design_kit_r1p0_trm.pdf

I'd be happy to hear any feedback/comments on this series!

Changelog:

  v3  -> v4:
      - rebased on 4.5-rc5
      - updated mps2-uart per Andy, Alan and Peter
      - dropped "zombie" EMBEDDED from defconfg per Arnd
      - moved mps2 under vexpress umbrella per Arnd
      - updated device-tree sources per Arnd
      - dropped low-level debug support, seems earlycon works well for that

  v2  -> v3:
      - rebased on 4.5-rc4
      - fixes for mps2-timer per Thomas
      - swicthed back to ttyMPS naming per Greg

  v1  -> v2:
      - rebased on 4.5-rc2
      - fixes for mps2-timer per Daniel and Rob (added Ack from Daniel)
      - fixes for mps2-uart per Greg and Andy

  RFC -> v1:
      - dropped RFC tag
      - rebased on 4.4-rc3
      - added Acks from Rob
      - updated mps2-timer per Daniel
      - fixed build failures reported by 0-DAY kernel test infrastructure

Thanks!

Vladimir Murzin (10):
  dt-bindings: document the MPS2 timer bindings
  clockevents/drivers: add MPS2 Timer driver
  dt-bindings: document the MPS2 UART bindings
  serial: mps2-uart: add MPS2 UART driver
  serial: mps2-uart: add support for early console
  ARM: vexpress/mps2: introduce MPS2 platform
  ARM: configs: add MPS2 defconfig
  ARM: dts: introduce MPS2 AN385/AN386
  ARM: dts: introduce MPS2 AN399/AN400
  MAINTAINERS: Update ARM Versatile Express platform entry

 .../devicetree/bindings/serial/arm,mps2-uart.txt   |   19 +
 .../devicetree/bindings/timer/arm,mps2-timer.txt   |   28 +
 MAINTAINERS                                        |    1 +
 arch/arm/Kconfig                                   |    8 +
 arch/arm/Makefile                                  |    1 +
 arch/arm/boot/dts/Makefile                         |    3 +
 arch/arm/boot/dts/mps2-an385.dts                   |   92 +++
 arch/arm/boot/dts/mps2-an399.dts                   |   92 +++
 arch/arm/boot/dts/mps2.dtsi                        |  242 ++++++++
 arch/arm/configs/mps2_defconfig                    |  109 ++++
 arch/arm/mach-vexpress/Makefile                    |    4 +-
 arch/arm/mach-vexpress/Makefile.boot               |    3 +
 arch/arm/mach-vexpress/v2m-mps2.c                  |   21 +
 drivers/clocksource/Kconfig                        |    6 +
 drivers/clocksource/Makefile                       |    1 +
 drivers/clocksource/mps2-timer.c                   |  275 +++++++++
 drivers/tty/serial/Kconfig                         |   13 +
 drivers/tty/serial/Makefile                        |    1 +
 drivers/tty/serial/mps2-uart.c                     |  614 ++++++++++++++++++++
 include/uapi/linux/serial_core.h                   |    3 +
 20 files changed, 1535 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/serial/arm,mps2-uart.txt
 create mode 100644 Documentation/devicetree/bindings/timer/arm,mps2-timer.txt
 create mode 100644 arch/arm/boot/dts/mps2-an385.dts
 create mode 100644 arch/arm/boot/dts/mps2-an399.dts
 create mode 100644 arch/arm/boot/dts/mps2.dtsi
 create mode 100644 arch/arm/configs/mps2_defconfig
 create mode 100644 arch/arm/mach-vexpress/Makefile.boot
 create mode 100644 arch/arm/mach-vexpress/v2m-mps2.c
 create mode 100644 drivers/clocksource/mps2-timer.c
 create mode 100644 drivers/tty/serial/mps2-uart.c

-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 23 06:34:19 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 23 Feb 2016 14:34:19 +0000
Subject: [PATCH v4 01/10] dt-bindings: document the MPS2 timer bindings
In-Reply-To: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
References: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1456238068-25079-2-git-send-email-vladimir.murzin@arm.com>

This adds documentation of device tree bindings for the
timers found on ARM MPS2 platform.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/timer/arm,mps2-timer.txt   |   28 ++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/arm,mps2-timer.txt

diff --git a/Documentation/devicetree/bindings/timer/arm,mps2-timer.txt b/Documentation/devicetree/bindings/timer/arm,mps2-timer.txt
new file mode 100644
index 0000000..48f84d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/arm,mps2-timer.txt
@@ -0,0 +1,28 @@
+ARM MPS2 timer
+
+The MPS2 platform has simple general-purpose 32 bits timers.
+
+Required properties:
+- compatible	: Should be "arm,mps2-timer"
+- reg		: Address and length of the register set
+- interrupts	: Reference to the timer interrupt
+
+Required clocking property, have to be one of:
+- clocks	  : The input clock of the timer
+- clock-frequency : The rate in HZ in input of the ARM MPS2 timer
+
+Examples:
+
+timer1: mps2-timer at 40000000 {
+	compatible = "arm,mps2-timer";
+	reg = <0x40000000 0x1000>;
+	interrupts = <8>;
+	clocks = <&sysclk>;
+};
+
+timer2: mps2-timer at 40001000 {
+	compatible = "arm,mps2-timer";
+	reg = <0x40001000 0x1000>;
+	interrupts = <9>;
+	clock-frequency = <25000000>;
+};
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 23 06:34:21 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 23 Feb 2016 14:34:21 +0000
Subject: [PATCH v4 03/10] dt-bindings: document the MPS2 UART bindings
In-Reply-To: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
References: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1456238068-25079-4-git-send-email-vladimir.murzin@arm.com>

This adds documentation of device tree bindings for the
UART found on ARM MPS2 platform

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
Acked-by: Rob Herring <robh at kernel.org>
---
 .../devicetree/bindings/serial/arm,mps2-uart.txt   |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/arm,mps2-uart.txt

diff --git a/Documentation/devicetree/bindings/serial/arm,mps2-uart.txt b/Documentation/devicetree/bindings/serial/arm,mps2-uart.txt
new file mode 100644
index 0000000..128cc6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/arm,mps2-uart.txt
@@ -0,0 +1,19 @@
+ARM MPS2 UART
+
+Required properties:
+- compatible	: Should be "arm,mps2-uart"
+- reg		: Address and length of the register set
+- interrupts	: Reference to the UART RX, TX and overrun interrupts
+
+Required clocking property:
+- clocks	  : The input clock of the UART
+
+
+Examples:
+
+uart0: serial at 40004000 {
+	compatible = "arm,mps2-uart";
+	reg = <0x40004000 0x1000>;
+	interrupts = <0 1 12>;
+	clocks = <&sysclk>;
+};
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 23 06:34:20 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 23 Feb 2016 14:34:20 +0000
Subject: [PATCH v4 02/10] clockevents/drivers: add MPS2 Timer driver
In-Reply-To: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
References: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1456238068-25079-3-git-send-email-vladimir.murzin@arm.com>

MPS2 platform has simple 32 bits general purpose countdown timers.

The driver uses the first detected timer as a clocksource and the rest
of the timers as a clockevent

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
Acked-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 drivers/clocksource/Kconfig      |    6 +
 drivers/clocksource/Makefile     |    1 +
 drivers/clocksource/mps2-timer.c |  275 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 282 insertions(+)
 create mode 100644 drivers/clocksource/mps2-timer.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 33db740..7ce3892 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -185,6 +185,12 @@ config CLKSRC_STM32
 	depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
 	select CLKSRC_MMIO
 
+config CLKSRC_MPS2
+	bool "Clocksource for MPS2 SoCs" if COMPILE_TEST
+	depends on GENERIC_SCHED_CLOCK
+	select CLKSRC_MMIO
+	select CLKSRC_OF
+
 config ARM_ARCH_TIMER
 	bool
 	select CLKSRC_OF if OF
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index dc2b899..b0a3c96 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_CLKSRC_EFM32)	+= time-efm32.o
 obj-$(CONFIG_CLKSRC_STM32)	+= timer-stm32.o
 obj-$(CONFIG_CLKSRC_EXYNOS_MCT)	+= exynos_mct.o
 obj-$(CONFIG_CLKSRC_LPC32XX)	+= time-lpc32xx.o
+obj-$(CONFIG_CLKSRC_MPS2)	+= mps2-timer.o
 obj-$(CONFIG_CLKSRC_SAMSUNG_PWM)	+= samsung_pwm_timer.o
 obj-$(CONFIG_FSL_FTM_TIMER)	+= fsl_ftm_timer.o
 obj-$(CONFIG_VF_PIT_TIMER)	+= vf_pit_timer.o
diff --git a/drivers/clocksource/mps2-timer.c b/drivers/clocksource/mps2-timer.c
new file mode 100644
index 0000000..bdc965f
--- /dev/null
+++ b/drivers/clocksource/mps2-timer.c
@@ -0,0 +1,275 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.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.
+ *
+ */
+
+#define pr_fmt(fmt)	KBUILD_MODNAME ": " fmt
+
+#include <linux/clk.h>
+#include <linux/clockchips.h>
+#include <linux/clocksource.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/of_address.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/sched_clock.h>
+#include <linux/slab.h>
+
+#define TIMER_CTRL		0x0
+#define TIMER_CTRL_ENABLE	BIT(0)
+#define TIMER_CTRL_IE		BIT(3)
+
+#define TIMER_VALUE		0x4
+#define TIMER_RELOAD		0x8
+#define TIMER_INT		0xc
+
+struct clockevent_mps2 {
+	void __iomem *reg;
+	u32 clock_count_per_tick;
+	struct clock_event_device clkevt;
+};
+
+static void __iomem *sched_clock_base;
+
+static u64 notrace mps2_sched_read(void)
+{
+	return ~readl_relaxed(sched_clock_base + TIMER_VALUE);
+}
+
+static inline struct clockevent_mps2 *to_mps2_clkevt(struct clock_event_device *c)
+{
+	return container_of(c, struct clockevent_mps2, clkevt);
+}
+
+static void clockevent_mps2_writel(u32 val, struct clock_event_device *c, u32 offset)
+{
+	writel_relaxed(val, to_mps2_clkevt(c)->reg + offset);
+}
+
+static int mps2_timer_shutdown(struct clock_event_device *ce)
+{
+	clockevent_mps2_writel(0, ce, TIMER_RELOAD);
+	clockevent_mps2_writel(0, ce, TIMER_CTRL);
+
+	return 0;
+}
+
+static int mps2_timer_set_next_event(unsigned long next, struct clock_event_device *ce)
+{
+	clockevent_mps2_writel(next, ce, TIMER_VALUE);
+	clockevent_mps2_writel(TIMER_CTRL_IE | TIMER_CTRL_ENABLE, ce, TIMER_CTRL);
+
+	return 0;
+}
+
+static int mps2_timer_set_periodic(struct clock_event_device *ce)
+{
+	u32 clock_count_per_tick = to_mps2_clkevt(ce)->clock_count_per_tick;
+
+	clockevent_mps2_writel(clock_count_per_tick, ce, TIMER_RELOAD);
+	clockevent_mps2_writel(clock_count_per_tick, ce, TIMER_VALUE);
+	clockevent_mps2_writel(TIMER_CTRL_IE | TIMER_CTRL_ENABLE, ce, TIMER_CTRL);
+
+	return 0;
+}
+
+static irqreturn_t mps2_timer_interrupt(int irq, void *dev_id)
+{
+	struct clockevent_mps2 *ce = dev_id;
+	u32 status = readl_relaxed(ce->reg + TIMER_INT);
+
+	if (!status) {
+		pr_warn("spurious interrupt\n");
+		return IRQ_NONE;
+	}
+
+	writel_relaxed(1, ce->reg + TIMER_INT);
+
+	ce->clkevt.event_handler(&ce->clkevt);
+
+	return IRQ_HANDLED;
+}
+
+static int __init mps2_clockevent_init(struct device_node *np)
+{
+	void __iomem *base;
+	struct clk *clk = NULL;
+	struct clockevent_mps2 *ce;
+	u32 rate;
+	int irq, ret;
+	const char *name = "mps2-clkevt";
+
+	ret = of_property_read_u32(np, "clock-frequency", &rate);
+	if (ret) {
+		clk = of_clk_get(np, 0);
+		if (IS_ERR(clk)) {
+			ret = PTR_ERR(clk);
+			pr_err("failed to get clock for clockevent: %d\n", ret);
+			goto out;
+		}
+
+		ret = clk_prepare_enable(clk);
+		if (ret) {
+			pr_err("failed to enable clock for clockevent: %d\n", ret);
+			goto out_clk_put;
+		}
+
+		rate = clk_get_rate(clk);
+	}
+
+	base = of_iomap(np, 0);
+	if (!base) {
+		ret = -EADDRNOTAVAIL;
+		pr_err("failed to map register for clockevent: %d\n", ret);
+		goto out_clk_disable;
+	}
+
+	irq = irq_of_parse_and_map(np, 0);
+	if (!irq) {
+		ret = -ENOENT;
+		pr_err("failed to get irq for clockevent: %d\n", ret);
+		goto out_iounmap;
+	}
+
+	ce = kzalloc(sizeof(struct clockevent_mps2), GFP_KERNEL);
+	if (!ce) {
+		ret = -ENOMEM;
+		goto out_iounmap;
+	}
+
+	ce->reg = base;
+	ce->clock_count_per_tick = DIV_ROUND_CLOSEST(rate, HZ);
+	ce->clkevt.irq = irq;
+	ce->clkevt.name = name;
+	ce->clkevt.rating = 200;
+	ce->clkevt.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
+	ce->clkevt.cpumask = cpu_possible_mask;
+	ce->clkevt.set_state_shutdown	= mps2_timer_shutdown,
+	ce->clkevt.set_state_periodic	= mps2_timer_set_periodic,
+	ce->clkevt.set_state_oneshot	= mps2_timer_shutdown,
+	ce->clkevt.set_next_event	= mps2_timer_set_next_event;
+
+	/* Ensure timer is disabled */
+	writel_relaxed(0, base + TIMER_CTRL);
+
+	ret = request_irq(irq, mps2_timer_interrupt, IRQF_TIMER, name, ce);
+	if (ret) {
+		pr_err("failed to request irq for clockevent: %d\n", ret);
+		goto out_kfree;
+	}
+
+	clockevents_config_and_register(&ce->clkevt, rate, 0xf, 0xffffffff);
+
+	return 0;
+
+out_kfree:
+	kfree(ce);
+out_iounmap:
+	iounmap(base);
+out_clk_disable:
+	/* clk_{disable, unprepare, put}() can handle NULL as a parameter */
+	clk_disable_unprepare(clk);
+out_clk_put:
+	clk_put(clk);
+out:
+	return ret;
+}
+
+static int __init mps2_clocksource_init(struct device_node *np)
+{
+	void __iomem *base;
+	struct clk *clk = NULL;
+	u32 rate;
+	int ret;
+	const char *name = "mps2-clksrc";
+
+	ret = of_property_read_u32(np, "clock-frequency", &rate);
+	if (ret) {
+		clk = of_clk_get(np, 0);
+		if (IS_ERR(clk)) {
+			ret = PTR_ERR(clk);
+			pr_err("failed to get clock for clocksource: %d\n", ret);
+			goto out;
+		}
+
+		ret = clk_prepare_enable(clk);
+		if (ret) {
+			pr_err("failed to enable clock for clocksource: %d\n", ret);
+			goto out_clk_put;
+		}
+
+		rate = clk_get_rate(clk);
+	}
+
+	base = of_iomap(np, 0);
+	if (!base) {
+		ret = -EADDRNOTAVAIL;
+		pr_err("failed to map register for clocksource: %d\n", ret);
+		goto out_clk_disable;
+	}
+
+	/* Ensure timer is disabled */
+	writel_relaxed(0, base + TIMER_CTRL);
+
+	/* ... and set it up as free-running clocksource */
+	writel_relaxed(0xffffffff, base + TIMER_VALUE);
+	writel_relaxed(0xffffffff, base + TIMER_RELOAD);
+
+	writel_relaxed(TIMER_CTRL_ENABLE, base + TIMER_CTRL);
+
+	ret = clocksource_mmio_init(base + TIMER_VALUE, name,
+				    rate, 200, 32,
+				    clocksource_mmio_readl_down);
+	if (ret) {
+		pr_err("failed to init clocksource: %d\n", ret);
+		goto out_iounmap;
+	}
+
+	sched_clock_base = base;
+	sched_clock_register(mps2_sched_read, 32, rate);
+
+	return 0;
+
+out_iounmap:
+	iounmap(base);
+out_clk_disable:
+	/* clk_{disable, unprepare, put}() can handle NULL as a parameter */
+	clk_disable_unprepare(clk);
+out_clk_put:
+	clk_put(clk);
+out:
+	return ret;
+}
+
+static void __init mps2_timer_init(struct device_node *np)
+{
+	static int has_clocksource, has_clockevent;
+	int ret;
+
+	if (!has_clocksource) {
+		ret = mps2_clocksource_init(np);
+		if (!ret) {
+			has_clocksource = 1;
+			return;
+		}
+	}
+
+	if (!has_clockevent) {
+		ret = mps2_clockevent_init(np);
+		if (!ret) {
+			has_clockevent = 1;
+			return;
+		}
+	}
+}
+
+CLOCKSOURCE_OF_DECLARE(mps2_timer, "arm,mps2-timer", mps2_timer_init);
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 23 06:34:22 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 23 Feb 2016 14:34:22 +0000
Subject: [PATCH v4 04/10] serial: mps2-uart: add MPS2 UART driver
In-Reply-To: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
References: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1456238068-25079-5-git-send-email-vladimir.murzin@arm.com>

This driver adds support to the UART controller found on ARM MPS2
platform.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 drivers/tty/serial/Kconfig       |   12 +
 drivers/tty/serial/Makefile      |    1 +
 drivers/tty/serial/mps2-uart.c   |  586 ++++++++++++++++++++++++++++++++++++++
 include/uapi/linux/serial_core.h |    3 +
 4 files changed, 602 insertions(+)
 create mode 100644 drivers/tty/serial/mps2-uart.c

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 39721ec..3a248be 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1450,6 +1450,18 @@ config SERIAL_EFM32_UART
 	  This driver support the USART and UART ports on
 	  Energy Micro's efm32 SoCs.
 
+config SERIAL_MPS2_UART_CONSOLE
+	bool "MPS2 UART console support"
+	depends on SERIAL_MPS2_UART
+	select SERIAL_CORE_CONSOLE
+
+config SERIAL_MPS2_UART
+	bool "MPS2 UART port"
+	depends on ARM || COMPILE_TEST
+	select SERIAL_CORE
+	help
+	  This driver support the UART ports on ARM MPS2.
+
 config SERIAL_EFM32_UART_CONSOLE
 	bool "EFM32 UART/USART console support"
 	depends on SERIAL_EFM32_UART=y
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index b391c9b..1062503 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
 obj-$(CONFIG_SERIAL_MEN_Z135)	+= men_z135_uart.o
 obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
 obj-$(CONFIG_SERIAL_STM32)	+= stm32-usart.o
+obj-$(CONFIG_SERIAL_MPS2_UART)	+= mps2-uart.o
 
 # GPIOLIB helpers for modem control lines
 obj-$(CONFIG_SERIAL_MCTRL_GPIO)	+= serial_mctrl_gpio.o
diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
new file mode 100644
index 0000000..5a4e167
--- /dev/null
+++ b/drivers/tty/serial/mps2-uart.c
@@ -0,0 +1,586 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.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.
+ *
+ * TODO: support for SysRq
+ */
+
+#define pr_fmt(fmt)	KBUILD_MODNAME ": " fmt
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/console.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/serial_core.h>
+#include <linux/tty_flip.h>
+#include <linux/types.h>
+
+#define SERIAL_NAME	"ttyMPS"
+#define DRIVER_NAME	"mps2-uart"
+#define MAKE_NAME(x)	(DRIVER_NAME # x)
+
+#define UARTn_DATA				0x00
+
+#define UARTn_STATE				0x04
+#define UARTn_STATE_TX_FULL			BIT(0)
+#define UARTn_STATE_RX_FULL			BIT(1)
+#define UARTn_STATE_TX_OVERRUN			BIT(2)
+#define UARTn_STATE_RX_OVERRUN			BIT(3)
+
+#define UARTn_CTRL				0x08
+#define UARTn_CTRL_TX_ENABLE			BIT(0)
+#define UARTn_CTRL_RX_ENABLE			BIT(1)
+#define UARTn_CTRL_TX_INT_ENABLE		BIT(2)
+#define UARTn_CTRL_RX_INT_ENABLE		BIT(3)
+#define UARTn_CTRL_TX_OVERRUN_INT_ENABLE	BIT(4)
+#define UARTn_CTRL_RX_OVERRUN_INT_ENABLE	BIT(5)
+
+#define UARTn_INT				0x0c
+#define UARTn_INT_TX				BIT(0)
+#define UARTn_INT_RX				BIT(1)
+#define UARTn_INT_TX_OVERRUN			BIT(2)
+#define UARTn_INT_RX_OVERRUN			BIT(3)
+
+#define UARTn_BAUDDIV				0x10
+#define UARTn_BAUDDIV_MASK			GENMASK(20, 0)
+
+/*
+ * Helpers to make typical enable/disable operations more readable.
+ */
+#define UARTn_CTRL_TX_GRP 			(UARTn_CTRL_TX_ENABLE		 |\
+						 UARTn_CTRL_TX_INT_ENABLE	 |\
+						 UARTn_CTRL_TX_OVERRUN_INT_ENABLE)
+
+#define UARTn_CTRL_RX_GRP 			(UARTn_CTRL_RX_ENABLE		 |\
+						 UARTn_CTRL_RX_INT_ENABLE	 |\
+						 UARTn_CTRL_RX_OVERRUN_INT_ENABLE)
+
+#define MPS2_MAX_PORTS				3
+
+struct mps2_uart_port {
+	struct uart_port port;
+	struct clk *clk;
+	unsigned int tx_irq;
+	unsigned int rx_irq;
+};
+
+static inline struct mps2_uart_port *to_mps2_port(struct uart_port *port)
+{
+	return container_of(port, struct mps2_uart_port, port);
+}
+
+static void mps2_uart_write8(struct uart_port *port, u8 val, unsigned off)
+{
+	struct mps2_uart_port *mps_port = to_mps2_port(port);
+
+	writeb(val, mps_port->port.membase + off);
+}
+
+static u8 mps2_uart_read8(struct uart_port *port, unsigned off)
+{
+	struct mps2_uart_port *mps_port = to_mps2_port(port);
+
+	return readb(mps_port->port.membase + off);
+}
+
+static void mps2_uart_write32(struct uart_port *port, u32 val, unsigned off)
+{
+	struct mps2_uart_port *mps_port = to_mps2_port(port);
+
+	writel_relaxed(val, mps_port->port.membase + off);
+}
+
+static unsigned int mps2_uart_tx_empty(struct uart_port *port)
+{
+	u8 status = mps2_uart_read8(port, UARTn_STATE);
+
+	return (status & UARTn_STATE_TX_FULL) ? 0 : TIOCSER_TEMT;
+}
+
+static void mps2_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
+{
+}
+
+static unsigned int mps2_uart_get_mctrl(struct uart_port *port)
+{
+	return TIOCM_CAR | TIOCM_CTS | TIOCM_DSR;
+}
+
+static void mps2_uart_stop_tx(struct uart_port *port)
+{
+	u8 control = mps2_uart_read8(port, UARTn_CTRL);
+
+	control &= ~UARTn_CTRL_TX_GRP;
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+}
+
+static void mps2_uart_tx_chars(struct uart_port *port)
+{
+	struct circ_buf *xmit = &port->state->xmit;
+
+	while (!(mps2_uart_read8(port, UARTn_STATE) & UARTn_STATE_TX_FULL)) {
+		if (port->x_char) {
+			mps2_uart_write8(port, port->x_char, UARTn_DATA);
+			port->x_char = 0;
+			port->icount.tx++;
+			continue;
+		}
+
+		if (uart_circ_empty(xmit) || uart_tx_stopped(port))
+			break;
+
+		mps2_uart_write8(port, xmit->buf[xmit->tail], UARTn_DATA);
+		xmit->tail = (xmit->tail + 1) % UART_XMIT_SIZE;
+		port->icount.tx++;
+	}
+
+	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+		uart_write_wakeup(port);
+
+	if (uart_circ_empty(xmit))
+		mps2_uart_stop_tx(port);
+}
+
+static void mps2_uart_start_tx(struct uart_port *port)
+{
+	u8 control = mps2_uart_read8(port, UARTn_CTRL);
+
+	control |= UARTn_CTRL_TX_GRP;
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+	mps2_uart_tx_chars(port);
+}
+
+static void mps2_uart_stop_rx(struct uart_port *port)
+{
+	u8 control = mps2_uart_read8(port, UARTn_CTRL);
+
+	control &= ~UARTn_CTRL_RX_GRP;
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+}
+
+static void mps2_uart_break_ctl(struct uart_port *port, int ctl)
+{
+}
+
+static void mps2_uart_rx_chars(struct uart_port *port)
+{
+	struct tty_port *tport = &port->state->port;
+
+	while (mps2_uart_read8(port, UARTn_STATE) & UARTn_STATE_RX_FULL) {
+		u8 rxdata = mps2_uart_read8(port, UARTn_DATA);
+
+		port->icount.rx++;
+		tty_insert_flip_char(&port->state->port, rxdata, TTY_NORMAL);
+	}
+
+	spin_unlock(&port->lock);
+	tty_flip_buffer_push(tport);
+	spin_lock(&port->lock);
+}
+
+static irqreturn_t mps2_uart_rxirq(int irq, void *data)
+{
+
+	struct uart_port *port = data;
+	u8 irqflag = mps2_uart_read8(port, UARTn_INT);
+
+	if (unlikely(!(irqflag & UARTn_INT_RX)))
+		return IRQ_NONE;
+
+	spin_lock(&port->lock);
+
+	mps2_uart_write8(port, UARTn_INT_RX, UARTn_INT);
+	mps2_uart_rx_chars(port);
+
+	spin_unlock(&port->lock);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t mps2_uart_txirq(int irq, void *data)
+{
+	struct uart_port *port = data;
+	u8 irqflag = mps2_uart_read8(port, UARTn_INT);
+
+	if (unlikely(!(irqflag & UARTn_INT_TX)))
+		return IRQ_NONE;
+
+	mps2_uart_write8(port, UARTn_INT_TX, UARTn_INT);
+	mps2_uart_tx_chars(port);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t mps2_uart_oerrirq(int irq, void *data)
+{
+	irqreturn_t handled = IRQ_NONE;
+	struct uart_port *port = data;
+	u8 irqflag = mps2_uart_read8(port, UARTn_INT);
+
+	spin_lock(&port->lock);
+
+	if (irqflag & UARTn_INT_RX_OVERRUN) {
+		struct tty_port *tport = &port->state->port;
+
+		mps2_uart_write8(port, UARTn_INT_RX_OVERRUN, UARTn_INT);
+		tty_insert_flip_char(tport, 0, TTY_OVERRUN);
+		port->icount.overrun++;
+		handled = IRQ_HANDLED;
+	}
+
+	/*
+	 * It's never been seen in practice and it never *should* happen since
+	 * we check if there is enough room in TX buffer before sending data.
+	 * So we keep this check in case something suspicious has happened.
+	 */
+	if (irqflag & UARTn_INT_TX_OVERRUN) {
+		mps2_uart_write8(port, UARTn_INT_TX_OVERRUN, UARTn_INT);
+		handled = IRQ_HANDLED;
+	}
+
+	spin_unlock(&port->lock);
+
+	return handled;
+}
+
+static int mps2_uart_startup(struct uart_port *port)
+{
+	struct mps2_uart_port *mps_port = to_mps2_port(port);
+	u8 control = mps2_uart_read8(port, UARTn_CTRL);
+	int ret;
+
+	control &= ~(UARTn_CTRL_RX_GRP | UARTn_CTRL_TX_GRP);
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+
+	ret = request_irq(mps_port->rx_irq, mps2_uart_rxirq, 0,
+			  MAKE_NAME(-rx), mps_port);
+	if (ret) {
+		dev_err(port->dev, "failed to register rxirq (%d)\n", ret);
+		return ret;
+	}
+
+	ret = request_irq(mps_port->tx_irq, mps2_uart_txirq, 0,
+			  MAKE_NAME(-tx), mps_port);
+	if (ret) {
+		dev_err(port->dev, "failed to register txirq (%d)\n", ret);
+		goto err_free_rxirq;
+	}
+
+	ret = request_irq(port->irq, mps2_uart_oerrirq, IRQF_SHARED,
+			  MAKE_NAME(-overrun), mps_port);
+
+	if (ret) {
+		dev_err(port->dev, "failed to register oerrirq (%d)\n", ret);
+		goto err_free_txirq;
+	}
+
+	control |= UARTn_CTRL_RX_GRP | UARTn_CTRL_TX_GRP;
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+
+	return 0;
+
+err_free_txirq:
+	free_irq(mps_port->tx_irq, mps_port);
+err_free_rxirq:
+	free_irq(mps_port->rx_irq, mps_port);
+
+	return ret;
+}
+
+static void mps2_uart_shutdown(struct uart_port *port)
+{
+	struct mps2_uart_port *mps_port = to_mps2_port(port);
+	u8 control = mps2_uart_read8(port, UARTn_CTRL);
+
+	control &= ~(UARTn_CTRL_RX_GRP | UARTn_CTRL_TX_GRP);
+
+	mps2_uart_write8(port, control, UARTn_CTRL);
+
+	free_irq(mps_port->rx_irq, mps_port);
+	free_irq(mps_port->tx_irq, mps_port);
+	free_irq(port->irq, mps_port);
+}
+
+static void mps2_uart_set_termios(struct uart_port *port,
+	struct ktermios *termios, struct ktermios *old)
+{
+	unsigned long flags;
+	unsigned int baud, bauddiv;
+
+	termios->c_cflag &= ~(CRTSCTS | CMSPAR);
+	termios->c_cflag &= ~CSIZE;
+	termios->c_cflag |= CS8;
+	termios->c_cflag &= ~PARENB;
+	termios->c_cflag &= ~CSTOPB;
+
+	baud = uart_get_baud_rate(port, termios, old,
+			DIV_ROUND_CLOSEST(port->uartclk, UARTn_BAUDDIV_MASK),
+			DIV_ROUND_CLOSEST(port->uartclk, 16));
+
+	bauddiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	uart_update_timeout(port, termios->c_cflag, baud);
+	mps2_uart_write32(port, bauddiv, UARTn_BAUDDIV);
+
+	if (tty_termios_baud_rate(termios))
+		tty_termios_encode_baud_rate(termios, baud, baud);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *mps2_uart_type(struct uart_port *port)
+{
+	return (port->type == PORT_MPS2UART) ? DRIVER_NAME : NULL;
+}
+
+static void mps2_uart_release_port(struct uart_port *port)
+{
+}
+
+static int mps2_uart_request_port(struct uart_port *port)
+{
+	return 0;
+}
+
+static void mps2_uart_config_port(struct uart_port *port, int type)
+{
+	if (type & UART_CONFIG_TYPE && !mps2_uart_request_port(port))
+		port->type = PORT_MPS2UART;
+}
+
+static int mps2_uart_verify_port(struct uart_port *port, struct serial_struct *serinfo)
+{
+	return -EINVAL;
+}
+
+static const struct uart_ops mps2_uart_pops = {
+	.tx_empty = mps2_uart_tx_empty,
+	.set_mctrl = mps2_uart_set_mctrl,
+	.get_mctrl = mps2_uart_get_mctrl,
+	.stop_tx = mps2_uart_stop_tx,
+	.start_tx = mps2_uart_start_tx,
+	.stop_rx = mps2_uart_stop_rx,
+	.break_ctl = mps2_uart_break_ctl,
+	.startup = mps2_uart_startup,
+	.shutdown = mps2_uart_shutdown,
+	.set_termios = mps2_uart_set_termios,
+	.type = mps2_uart_type,
+	.release_port = mps2_uart_release_port,
+	.request_port = mps2_uart_request_port,
+	.config_port = mps2_uart_config_port,
+	.verify_port = mps2_uart_verify_port,
+};
+
+static struct mps2_uart_port mps2_uart_ports[MPS2_MAX_PORTS];
+
+#ifdef CONFIG_SERIAL_MPS2_UART_CONSOLE
+static void mps2_uart_console_putchar(struct uart_port *port, int ch)
+{
+	while (mps2_uart_read8(port, UARTn_STATE) & UARTn_STATE_TX_FULL)
+		cpu_relax();
+
+	mps2_uart_write8(port, ch, UARTn_DATA);
+}
+
+static void mps2_uart_console_write(struct console *co, const char *s, unsigned int cnt)
+{
+	struct uart_port *port = &mps2_uart_ports[co->index].port;
+
+	uart_console_write(port, s, cnt, mps2_uart_console_putchar);
+}
+
+static int mps2_uart_console_setup(struct console *co, char *options)
+{
+	struct mps2_uart_port *mps_port;
+	int baud = 9600;
+	int bits = 8;
+	int parity = 'n';
+	int flow = 'n';
+
+	if (co->index < 0 || co->index >= MPS2_MAX_PORTS)
+		return -ENODEV;
+
+	mps_port = &mps2_uart_ports[co->index];
+
+	if (options)
+		uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+	return uart_set_options(&mps_port->port, co, baud, parity, bits, flow);
+}
+
+static struct uart_driver mps2_uart_driver;
+
+static struct console mps2_uart_console = {
+	.name = SERIAL_NAME,
+	.device = uart_console_device,
+	.write = mps2_uart_console_write,
+	.setup = mps2_uart_console_setup,
+	.flags = CON_PRINTBUFFER,
+	.index = -1,
+	.data = &mps2_uart_driver,
+};
+
+#define MPS2_SERIAL_CONSOLE (&mps2_uart_console)
+
+#else
+#define MPS2_SERIAL_CONSOLE NULL
+#endif
+
+static struct uart_driver mps2_uart_driver = {
+	.driver_name = DRIVER_NAME,
+	.dev_name = SERIAL_NAME,
+	.nr = MPS2_MAX_PORTS,
+	.cons = MPS2_SERIAL_CONSOLE,
+};
+
+static struct mps2_uart_port *mps2_of_get_port(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	int id;
+
+	if (!np)
+		return NULL;
+
+	id = of_alias_get_id(np, "serial");
+	if (id < 0)
+		id = 0;
+
+	if (WARN_ON(id >= MPS2_MAX_PORTS))
+		return NULL;
+
+	mps2_uart_ports[id].port.line = id;
+	return &mps2_uart_ports[id];
+}
+
+static int mps2_init_port(struct mps2_uart_port *mps_port,
+			struct platform_device *pdev)
+{
+	struct resource *res;
+	int ret;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	mps_port->port.membase = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(mps_port->port.membase))
+		return PTR_ERR(mps_port->port.membase);
+
+	mps_port->port.mapbase = res->start;
+	mps_port->port.mapsize = resource_size(res);
+
+	mps_port->rx_irq = platform_get_irq(pdev, 0);
+	mps_port->tx_irq = platform_get_irq(pdev, 1);
+	mps_port->port.irq = platform_get_irq(pdev, 2);
+
+	mps_port->port.iotype = UPIO_MEM;
+	mps_port->port.flags = UPF_BOOT_AUTOCONF;
+	mps_port->port.fifosize = 1;
+	mps_port->port.ops = &mps2_uart_pops;
+	mps_port->port.dev = &pdev->dev;
+
+	mps_port->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(mps_port->clk))
+		return PTR_ERR(mps_port->clk);
+
+	ret = clk_prepare_enable(mps_port->clk);
+	if (ret)
+		return ret;
+
+	mps_port->port.uartclk = clk_get_rate(mps_port->clk);
+
+	clk_disable_unprepare(mps_port->clk);
+
+	return ret;
+}
+
+static int mps2_serial_probe(struct platform_device *pdev)
+{
+	struct mps2_uart_port *mps_port;
+	int ret;
+
+	mps_port = mps2_of_get_port(pdev);
+	if (!mps_port)
+		return -ENODEV;
+
+	ret = mps2_init_port(mps_port, pdev);
+	if (ret)
+		return ret;
+
+	ret = uart_add_one_port(&mps2_uart_driver, &mps_port->port);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, mps_port);
+
+	return 0;
+}
+
+static int mps2_serial_remove(struct platform_device *pdev)
+{
+	struct mps2_uart_port *mps_port = platform_get_drvdata(pdev);
+
+	uart_remove_one_port(&mps2_uart_driver, &mps_port->port);
+
+	return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id mps2_match[] = {
+	{ .compatible = "arm,mps2-uart", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, mps2_match);
+#endif
+
+static struct platform_driver mps2_serial_driver = {
+	.probe = mps2_serial_probe,
+	.remove = mps2_serial_remove,
+
+	.driver = {
+		.name = DRIVER_NAME,
+		.of_match_table = of_match_ptr(mps2_match),
+	},
+};
+
+static int __init mps2_uart_init(void)
+{
+	int ret;
+
+	ret = uart_register_driver(&mps2_uart_driver);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&mps2_serial_driver);
+	if (ret)
+		uart_unregister_driver(&mps2_uart_driver);
+
+	return ret;
+}
+module_init(mps2_uart_init);
+
+static void __exit mps2_uart_exit(void)
+{
+	platform_driver_unregister(&mps2_serial_driver);
+	uart_unregister_driver(&mps2_uart_driver);
+}
+module_exit(mps2_uart_exit);
+
+MODULE_AUTHOR("Vladimir Murzin <vladimir.murzin at arm.com>");
+MODULE_DESCRIPTION("MPS2 UART driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:" DRIVER_NAME);
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 3e5d757..1fa57bb 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -261,4 +261,7 @@
 /* STM32 USART */
 #define PORT_STM32	113
 
+/* MPS2 UART */
+#define PORT_MPS2UART	114
+
 #endif /* _UAPILINUX_SERIAL_CORE_H */
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 23 06:34:23 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 23 Feb 2016 14:34:23 +0000
Subject: [PATCH v4 05/10] serial: mps2-uart: add support for early console
In-Reply-To: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
References: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1456238068-25079-6-git-send-email-vladimir.murzin@arm.com>

This adds support early console for MPS2 UART which can be enabled via
earlycon=mps2,0x40004000

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 drivers/tty/serial/Kconfig     |    1 +
 drivers/tty/serial/mps2-uart.c |   28 ++++++++++++++++++++++++++++
 2 files changed, 29 insertions(+)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 3a248be..4ed6e51 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1454,6 +1454,7 @@ config SERIAL_MPS2_UART_CONSOLE
 	bool "MPS2 UART console support"
 	depends on SERIAL_MPS2_UART
 	select SERIAL_CORE_CONSOLE
+	select SERIAL_EARLYCON
 
 config SERIAL_MPS2_UART
 	bool "MPS2 UART port"
diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
index 5a4e167..4f42326 100644
--- a/drivers/tty/serial/mps2-uart.c
+++ b/drivers/tty/serial/mps2-uart.c
@@ -439,6 +439,34 @@ static struct console mps2_uart_console = {
 
 #define MPS2_SERIAL_CONSOLE (&mps2_uart_console)
 
+static void mps2_early_putchar(struct uart_port *port, int ch)
+{
+
+	while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
+		cpu_relax();
+
+	writeb((unsigned char)ch, port->membase + UARTn_DATA);
+}
+
+static void mps2_early_write(struct console *con, const char *s, unsigned n)
+{
+	struct earlycon_device *dev = con->data;
+
+	uart_console_write(&dev->port, s, n, mps2_early_putchar);
+}
+
+static int __init mps2_early_console_setup(struct earlycon_device *device,
+					   const char *opt)
+{
+	if (!device->port.membase)
+		return -ENODEV;
+
+	device->con->write = mps2_early_write;
+
+	return 0;
+}
+OF_EARLYCON_DECLARE(mps2, "arm,mps2-uart", mps2_early_console_setup);
+
 #else
 #define MPS2_SERIAL_CONSOLE NULL
 #endif
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 23 06:34:24 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 23 Feb 2016 14:34:24 +0000
Subject: [PATCH v4 06/10] ARM: vexpress/mps2: introduce MPS2 platform
In-Reply-To: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
References: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1456238068-25079-7-git-send-email-vladimir.murzin@arm.com>

The Cortex-M Prototyping System (or V2M-MPS2) is designed for
prototyping and evaluation Cortex-M family of processors including the
latest Cortex-M7

It comes with a range of useful peripherals including 8MB single cycle
SRAM, 16MB PSRAM, Ethernet, QSVGA touch screen panel, 4bit RGB VGA
connector, Audio, SPI and GPIO.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 arch/arm/Kconfig                     |    8 ++++++++
 arch/arm/Makefile                    |    1 +
 arch/arm/mach-vexpress/Makefile      |    4 +++-
 arch/arm/mach-vexpress/Makefile.boot |    3 +++
 arch/arm/mach-vexpress/v2m-mps2.c    |   21 +++++++++++++++++++++
 5 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-vexpress/Makefile.boot
 create mode 100644 arch/arm/mach-vexpress/v2m-mps2.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4f799e5..48fa6c4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -883,6 +883,14 @@ config ARCH_STM32
 	help
 	  Support for STMicroelectronics STM32 processors.
 
+config ARCH_MPS2
+	bool "ARM MPS2 paltform"
+	depends on ARM_SINGLE_ARMV7M
+	select ARM_AMBA
+	select CLKSRC_MPS2
+	help
+	  Support for ARM MPS2 Cortex-M platform.
+
 # Definitions to make life easier
 config ARCH_ACORN
 	bool
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index fe25410..e08a211 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -182,6 +182,7 @@ machine-$(CONFIG_ARCH_LPC18XX)		+= lpc18xx
 machine-$(CONFIG_ARCH_LPC32XX)		+= lpc32xx
 machine-$(CONFIG_ARCH_MESON)		+= meson
 machine-$(CONFIG_ARCH_MMP)		+= mmp
+machine-$(CONFIG_ARCH_MPS2)		+= vexpress
 machine-$(CONFIG_ARCH_MOXART)		+= moxart
 machine-$(CONFIG_ARCH_MV78XX0)		+= mv78xx0
 machine-$(CONFIG_ARCH_MVEBU)		+= mvebu
diff --git a/arch/arm/mach-vexpress/Makefile b/arch/arm/mach-vexpress/Makefile
index f5c1006..a1d8ec9 100644
--- a/arch/arm/mach-vexpress/Makefile
+++ b/arch/arm/mach-vexpress/Makefile
@@ -4,7 +4,7 @@
 ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := \
 	-I$(srctree)/arch/arm/plat-versatile/include
 
-obj-y					:= v2m.o
+obj-$(CONFIG_ARCH_VEXPRESS)		:= v2m.o
 obj-$(CONFIG_ARCH_VEXPRESS_DCSCB)	+= dcscb.o	dcscb_setup.o
 CFLAGS_dcscb.o				+= -march=armv7-a
 CFLAGS_REMOVE_dcscb.o			= -pg
@@ -15,3 +15,5 @@ CFLAGS_tc2_pm.o				+= -march=armv7-a
 CFLAGS_REMOVE_tc2_pm.o			= -pg
 obj-$(CONFIG_SMP)			+= platsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= hotplug.o
+
+obj-$(COFIG_ARCH_MPS2)			+= v2m-mps2.o
diff --git a/arch/arm/mach-vexpress/Makefile.boot b/arch/arm/mach-vexpress/Makefile.boot
new file mode 100644
index 0000000..eacfc3f
--- /dev/null
+++ b/arch/arm/mach-vexpress/Makefile.boot
@@ -0,0 +1,3 @@
+# Empty file waiting for deletion once Makefile.boot isn't needed any more.
+# Patch waits for application at
+# http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7889/1 .
diff --git a/arch/arm/mach-vexpress/v2m-mps2.c b/arch/arm/mach-vexpress/v2m-mps2.c
new file mode 100644
index 0000000..e7ad9c2
--- /dev/null
+++ b/arch/arm/mach-vexpress/v2m-mps2.c
@@ -0,0 +1,21 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.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.
+ *
+ */
+
+#include <asm/mach/arch.h>
+
+static const char *const mps2_compat[] __initconst = {
+	"arm,mps2",
+	NULL
+};
+
+DT_MACHINE_START(MPS2DT, "MPS2 (Device Tree Support)")
+	.dt_compat = mps2_compat,
+MACHINE_END
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 23 06:34:26 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 23 Feb 2016 14:34:26 +0000
Subject: [PATCH v4 08/10] ARM: dts: introduce MPS2 AN385/AN386
In-Reply-To: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
References: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1456238068-25079-9-git-send-email-vladimir.murzin@arm.com>

Application Notes 385 and 386 shares the same memory map and features
except the CPU is used. AN385 is supplied with Cortex-M3 CPU and AN386
is supplied with Cortex-M4.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
Reviewed-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/Makefile       |    1 +
 arch/arm/boot/dts/mps2-an385.dts |   92 +++++++++++++++
 arch/arm/boot/dts/mps2.dtsi      |  242 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 335 insertions(+)
 create mode 100644 arch/arm/boot/dts/mps2-an385.dts
 create mode 100644 arch/arm/boot/dts/mps2.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..96418d2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -245,6 +245,7 @@ dtb-$(CONFIG_ARCH_MMP) += \
 dtb-$(CONFIG_MACH_MESON8B) += \
 	meson8b-mxq.dtb \
 	meson8b-odroidc1.dtb
+dtb-$(CONFIG_ARCH_MPS2) += mps2-an385.dtb
 dtb-$(CONFIG_ARCH_MOXART) += \
 	moxart-uc7112lx.dtb
 dtb-$(CONFIG_SOC_IMX1) += \
diff --git a/arch/arm/boot/dts/mps2-an385.dts b/arch/arm/boot/dts/mps2-an385.dts
new file mode 100644
index 0000000..d7cb594
--- /dev/null
+++ b/arch/arm/boot/dts/mps2-an385.dts
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "mps2.dtsi"
+
+/ {
+	model = "ARM MPS2 Application Note 385/386";
+	compatible = "arm,mps2";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		bootargs = "rdinit=/sbin/init earlycon";
+		stdout-path = "serial0:9600n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x21000000 0x1000000>;
+	};
+
+	smb {
+		ethernet at 0,0 {
+			compatible = "smsc,lan9220", "smsc,lan9115";
+			reg = <0 0x0 0x10000>;
+			interrupts = <13>;
+			interrupt-parent = <&nvic>;
+			smsc,irq-active-high;
+		};
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&timer0 {
+	status = "okay";
+};
+
+&timer1 {
+	status = "okay";
+};
+
+&wdt {
+	status = "okay";
+};
diff --git a/arch/arm/boot/dts/mps2.dtsi b/arch/arm/boot/dts/mps2.dtsi
new file mode 100644
index 0000000..6c84ca3
--- /dev/null
+++ b/arch/arm/boot/dts/mps2.dtsi
@@ -0,0 +1,242 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "armv7-m.dtsi"
+
+/ {
+	oscclk0: clk-osc0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <50000000>;
+	};
+
+	oscclk1: clk-osc1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24576000>;
+	};
+
+	oscclk2: clk-osc2 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <25000000>;
+	};
+
+	cfgclk: clk-cfg {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <5000000>;
+	};
+
+	spicfgclk: clk-spicfg {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <75000000>;
+	};
+
+	sysclk: clk-sys {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk0>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	audmclk: clk-audm {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk1>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	audsclk: clk-auds {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk1>;
+		#clock-cells = <0>;
+		clock-div = <8>;
+		clock-mult = <1>;
+	};
+
+	spiclcd: clk-cpiclcd {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk0>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	spicon: clk-spicon {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk0>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	i2cclcd: clk-i2cclcd {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk0>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	i2caud: clk-i2caud {
+		compatible = "fixed-factor-clock";
+		clocks = <&oscclk0>;
+		#clock-cells = <0>;
+		clock-div = <2>;
+		clock-mult = <1>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		ranges;
+
+		apb {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0 0x40000000 0x10000>;
+
+			timer0: mps2-timer0 at 0 {
+				compatible = "arm,mps2-timer";
+				reg = <0x0 0x1000>;
+				interrupts = <8>;
+				clocks = <&sysclk>;
+				status = "disabled";
+			};
+
+			timer1: mps2-timer1 at 1000 {
+				compatible = "arm,mps2-timer";
+				reg = <0x1000 0x1000>;
+				interrupts = <9>;
+				clocks = <&sysclk>;
+				status = "disabled";
+			};
+
+			timer2: dual-timer at 2000 {
+				compatible = "arm,sp804";
+				reg = <0x2000 0x1000>;
+				clocks = <&sysclk>;
+				interrupts = <10>;
+				status = "disabled";
+			};
+
+
+			uart0: serial at 4000 {
+				compatible = "arm,mps2-uart";
+				reg = <0x4000 0x1000>;
+				interrupts = <0 1 12>;
+				clocks = <&sysclk>;
+				status = "disabled";
+			};
+
+			uart1: serial at 5000 {
+				compatible = "arm,mps2-uart";
+				reg = <0x5000 0x1000>;
+				interrupts = <2 3 12>;
+				clocks = <&sysclk>;
+				status = "disabled";
+			};
+
+			uart2: serial at 6000 {
+				compatible = "arm,mps2-uart";
+				reg = <0x6000 0x1000>;
+				interrupts = <4 5 12>;
+				clocks = <&sysclk>;
+				status = "disabled";
+			};
+
+			wdt: watchdog at 8000 {
+				compatible = "arm,sp805", "arm,primecell";
+				arm,primecell-periphid = <0x00141805>;
+				reg = <0x8000 0x1000>;
+				interrupts = <0>;
+				clocks = <&sysclk>;
+				clock-names = "apb_pclk";
+				status = "disabled";
+			};
+		};
+	};
+
+	fpga {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0x40020000 0x10000>;
+
+		fpgaio at 8000 {
+			compatible = "syscon", "simple-mfd";
+			reg = <0x8000 0x10>;
+
+			led at 0 {
+				compatible = "register-bit-led";
+				offset = <0x0>;
+				mask = <0x01>;
+				label = "userled:0";
+				linux,default-trigger = "heartbeat";
+				default-state = "on";
+			};
+
+			led at 1 {
+				compatible = "register-bit-led";
+				offset = <0x0>;
+				mask = <0x02>;
+				label = "userled:1";
+				linux,default-trigger = "usr";
+				default-state = "off";
+			};
+		};
+	};
+
+	smb {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges = <0 0 0x40200000 0x10000>,
+			 <1 0 0xa0000000 0x10000>;
+	};
+};
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 23 06:34:27 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 23 Feb 2016 14:34:27 +0000
Subject: [PATCH v4 09/10] ARM: dts: introduce MPS2 AN399/AN400
In-Reply-To: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
References: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1456238068-25079-10-git-send-email-vladimir.murzin@arm.com>

Application Notes 399 and 400 shares the same memory map and
features. Both are shipped with Cortex-M7 and have the same  peripheral
as AN385/AN386, but with different location of PSRAM and Ethernet
controller.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 arch/arm/boot/dts/Makefile       |    4 +-
 arch/arm/boot/dts/mps2-an399.dts |   92 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 95 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/mps2-an399.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 96418d2..ad5622b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -245,7 +245,9 @@ dtb-$(CONFIG_ARCH_MMP) += \
 dtb-$(CONFIG_MACH_MESON8B) += \
 	meson8b-mxq.dtb \
 	meson8b-odroidc1.dtb
-dtb-$(CONFIG_ARCH_MPS2) += mps2-an385.dtb
+dtb-$(CONFIG_ARCH_MPS2) += \
+	mps2-an385.dtb \
+	mps2-an399.dtb
 dtb-$(CONFIG_ARCH_MOXART) += \
 	moxart-uc7112lx.dtb
 dtb-$(CONFIG_SOC_IMX1) += \
diff --git a/arch/arm/boot/dts/mps2-an399.dts b/arch/arm/boot/dts/mps2-an399.dts
new file mode 100644
index 0000000..776595f
--- /dev/null
+++ b/arch/arm/boot/dts/mps2-an399.dts
@@ -0,0 +1,92 @@
+/*
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Vladimir Murzin <vladimir.murzin at arm.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "mps2.dtsi"
+
+/ {
+	model = "ARM MPS2 Application Note 399/400";
+	compatible = "arm,mps2";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	chosen {
+		bootargs = "rdinit=/sbin/init earlycon";
+		stdout-path = "serial0:9600n8";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x60000000 0x1000000>;
+	};
+
+	smb {
+		ethernet at 1,0 {
+			compatible = "smsc,lan9220", "smsc,lan9115";
+			reg = <1 0x0 0x10000>;
+			interrupts = <13>;
+			interrupt-parent = <&nvic>;
+			smsc,irq-active-high;
+		};
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&timer0 {
+	status = "okay";
+};
+
+&timer1 {
+	status = "okay";
+};
+
+&wdt {
+	status = "okay";
+};
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 23 06:34:25 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 23 Feb 2016 14:34:25 +0000
Subject: [PATCH v4 07/10] ARM: configs: add MPS2 defconfig
In-Reply-To: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
References: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1456238068-25079-8-git-send-email-vladimir.murzin@arm.com>

This patch adds a new config for MPS2 platform.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 arch/arm/configs/mps2_defconfig |  109 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 109 insertions(+)
 create mode 100644 arch/arm/configs/mps2_defconfig

diff --git a/arch/arm/configs/mps2_defconfig b/arch/arm/configs/mps2_defconfig
new file mode 100644
index 0000000..19d119f
--- /dev/null
+++ b/arch/arm/configs/mps2_defconfig
@@ -0,0 +1,109 @@
+CONFIG_NO_HZ_IDLE=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_LOG_BUF_SHIFT=16
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_EXPERT=y
+# CONFIG_UID16 is not set
+# CONFIG_BASE_FULL is not set
+# CONFIG_FUTEX is not set
+# CONFIG_EPOLL is not set
+# CONFIG_SIGNALFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_BLOCK is not set
+# CONFIG_MMU is not set
+CONFIG_ARCH_MPS2=y
+CONFIG_SET_MEM_PARAM=y
+CONFIG_DRAM_BASE=0x21000000
+CONFIG_DRAM_SIZE=0x1000000
+CONFIG_PREEMPT_VOLUNTARY=y
+# CONFIG_ATAGS is not set
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_BINFMT_FLAT=y
+CONFIG_BINFMT_SHARED_FLAT=y
+# CONFIG_COREDUMP is not set
+# CONFIG_SUSPEND is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+# CONFIG_IPV6 is not set
+# CONFIG_WIRELESS is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_FW_LOADER is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NET_CORE is not set
+# 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_EZCHIP is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_HISILICON 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_NET_VENDOR_QUALCOMM is not set
+# CONFIG_NET_VENDOR_RENESAS is not set
+# CONFIG_NET_VENDOR_ROCKER is not set
+# CONFIG_NET_VENDOR_SAMSUNG is not set
+# 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_WLAN is not set
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_NONSTANDARD=y
+# CONFIG_DEVKMEM is not set
+CONFIG_SERIAL_MPS2_UART_CONSOLE=y
+CONFIG_SERIAL_MPS2_UART=y
+# CONFIG_HW_RANDOM is not set
+# CONFIG_HWMON is not set
+CONFIG_WATCHDOG=y
+CONFIG_ARM_SP805_WATCHDOG=y
+CONFIG_MFD_SYSCON=y
+# CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_SYSCON=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_ONESHOT=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_BACKLIGHT=y
+CONFIG_LEDS_TRIGGER_CPU=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_ARM_TIMER_SP804=y
+# CONFIG_DNOTIFY is not set
+# CONFIG_INOTIFY_USER is not set
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_NFS_FS=y
+CONFIG_NFS_V4=y
+CONFIG_NFS_V4_1=y
+CONFIG_NFS_V4_2=y
+CONFIG_ROOT_NFS=y
+CONFIG_NLS=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DEBUG_INFO=y
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+CONFIG_DEBUG_FS=y
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+CONFIG_MEMTEST=y
-- 
1.7.9.5



From vladimir.murzin at arm.com  Tue Feb 23 06:34:28 2016
From: vladimir.murzin at arm.com (Vladimir Murzin)
Date: Tue, 23 Feb 2016 14:34:28 +0000
Subject: [PATCH v4 10/10] MAINTAINERS: Update ARM Versatile Express platform
 entry
In-Reply-To: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
References: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
Message-ID: <1456238068-25079-11-git-send-email-vladimir.murzin@arm.com>

This patch update ARM Versatile Express entry to cover bits needed for
Cortex-M Prototyping System (MPS2 platform). So patches for the latter
are collected by existing Vexpress and Juno maintainers (Liviu, Sudeep,
Lorenzo) and find their way upstream via Vexpess and/or Juno trees.

Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
---
 MAINTAINERS |    1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4978dc1..e827e3b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1726,6 +1726,7 @@ F:	*/*/vexpress*
 F:	*/*/*/vexpress*
 F:	drivers/clk/versatile/clk-vexpress-osc.c
 F:	drivers/clocksource/versatile.c
+N:	mps2
 
 ARM/VFP SUPPORT
 M:	Russell King <linux at arm.linux.org.uk>
-- 
1.7.9.5



From matthias.bgg at gmail.com  Tue Feb 23 06:37:26 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Tue, 23 Feb 2016 15:37:26 +0100
Subject: [PATCH 1/8] arm64: move acpi/dt decision earlier in boot process
In-Reply-To: <20160223135731.GA24781@xora-haswell.xora.org.uk>
References: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
 <1456148818-26257-2-git-send-email-aleksey.makarov@linaro.org>
 <56CB2D0D.3090408@gmail.com>
 <20160223135731.GA24781@xora-haswell.xora.org.uk>
Message-ID: <56CC6EA6.4020909@gmail.com>



On 23/02/16 14:57, Graeme Gregory wrote:
> On Mon, Feb 22, 2016 at 04:45:17PM +0100, Matthias Brugger wrote:
>>
>>
>> On 22/02/16 14:46, Aleksey Makarov wrote:
>>> From: Leif Lindholm <leif.lindholm at linaro.org>
>>>
>>> In order to support selecting earlycon via either ACPI or DT, move
>>> the decision on whether to attempt ACPI configuration into the
>>> early_param handling. Then make acpi_boot_table_init() bail out if
>>> acpi_disabled.
>>>
>>> Signed-off-by: Leif Lindholm <leif.lindholm at linaro.org>
>>> ---
>>>   arch/arm64/kernel/acpi.c | 54 ++++++++++++++++++++++++++----------------------
>>>   1 file changed, 29 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>>> index d1ce8e2..7a944f7 100644
>>> --- a/arch/arm64/kernel/acpi.c
>>> +++ b/arch/arm64/kernel/acpi.c
>>> @@ -44,6 +44,19 @@ EXPORT_SYMBOL(acpi_pci_disabled);
>>>   static bool param_acpi_off __initdata;
>>>   static bool param_acpi_force __initdata;
>>>
>>> +static int __init dt_scan_depth1_nodes(unsigned long node,
>>> +				       const char *uname, int depth,
>>> +				       void *data)
>>> +{
>>> +	/*
>>> +	 * Return 1 as soon as we encounter a node at depth 1 that is
>>> +	 * not the /chosen node.
>>> +	 */
>>> +	if (depth == 1 && (strcmp(uname, "chosen") != 0))
>>> +		return 1;
>>> +	return 0;
>>> +}
>>> +
>>>   static int __init parse_acpi(char *arg)
>>>   {
>>>   	if (!arg)
>>> @@ -57,23 +70,27 @@ static int __init parse_acpi(char *arg)
>>>   	else
>>>   		return -EINVAL;	/* Core will print when we return error */

If argument of parse_acpi is neither "off" nor "force" we return with 
-EINVAL here. Actually parse_acpi will be only called if we pass "acpi=" 
as kernel parameter. Therefor we can get rid of "acpi=off" as this is 
the _new_ standard. IMHO we should introduce "acpi=on" if we really want 
to change the standard behavior.

>>>
>>> -	return 0;
>>> -}
>>> -early_param("acpi", parse_acpi);
>>> +	/*
>>> +	 * Enable ACPI instead of device tree unless
>>> +	 * - ACPI has been disabled explicitly (acpi=off), or
>>> +	 * - the device tree is not empty (it has more than just a /chosen node)
>>> +	 *   and ACPI has not been force enabled (acpi=force)
>>> +	 */
>>> +	if (param_acpi_off ||
>>> +	    (!param_acpi_force && of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
>>> +		return 0;

Or param_acpi_off is true or param_acpi_force is true, the depth of the 
DT has no influence.

>>>
>>> -static int __init dt_scan_depth1_nodes(unsigned long node,
>>> -				       const char *uname, int depth,
>>> -				       void *data)
>>> -{
>>>   	/*
>>> -	 * Return 1 as soon as we encounter a node at depth 1 that is
>>> -	 * not the /chosen node.
>>> +	 * ACPI is disabled at this point. Enable it in order to parse
>>> +	 * the ACPI tables and carry out sanity checks
>>>   	 */
>>> -	if (depth == 1 && (strcmp(uname, "chosen") != 0))
>>> -		return 1;
>>> +	enable_acpi();
>>> +
>>
>> So we only enable ACPI if we pass acpi=force as kernel parameter?
>> I'm not sure if this is what you wanted to do.
>>
>
> The current preference from ARM64 maintainers was that is both ACPI
> tables and a DT were presented then DT should take precedence.
>
> With no DT provided the code should use ACPI.

 From my understanding in this patch that can never happen.

On which version is this set based on?
I'm looking on v4.5-rc5 ATM.

Regards,
Matthias


From thierry.reding at gmail.com  Tue Feb 23 06:38:59 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 23 Feb 2016 15:38:59 +0100
Subject: [PATCH v3 00/12] pwm: add support for atomic update
In-Reply-To: <CAD=FV=UCErW3EjYRtwt49_ztNR7cyY4U0o4R_dxdomer-Ac2Dg@mail.gmail.com>
References: <1442828009-6241-1-git-send-email-boris.brezillon@free-electrons.com>
 <2341981.a79ioYM9Es@diego> <20151110173416.GB21727@ulmo>
 <CAD=FV=WL3jYEgVe-m6QcAyQwfJgdX4J5OtKisKwyoKOrTSpEQA@mail.gmail.com>
 <20160125170855.GA10182@ulmo>
 <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
 <20160203145337.GD9650@ulmo>
 <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
 <20160222175929.GA23899@ulmo>
 <CAD=FV=UCErW3EjYRtwt49_ztNR7cyY4U0o4R_dxdomer-Ac2Dg@mail.gmail.com>
Message-ID: <20160223143859.GA27656@ulmo>

On Mon, Feb 22, 2016 at 11:15:09AM -0800, Doug Anderson wrote:
> Thierry,
> 
> On Mon, Feb 22, 2016 at 9:59 AM, Thierry Reding <thierry.reding at gmail.com> wrote:
[...]
> >> When we add a new feature then it's expected that only updated drivers
> >> will support that feature.
> >>
> >> We need to make sure that we don't regress / negatively change the
> >> behavior for anyone running non-updated drivers.  ...and we should
> >> strive to require as few changes to drivers as possible.  ...but if
> >> the best we can do requires changes to the PWM driver API then we will
> >> certainly have differences depending on the PWM driver.
> >
> > How so? Drivers should behave consistently, irrespective of the API. Of
> > course if you need to change behaviour of the user driver depending on
> > the availability of a certain feature, that's perfectly fine.
> >
> > Furthermore it's out of the question that changes to the API will be
> > required. That's precisely the reason why the atomic PWM proposal came
> > about. It's an attempt to solve the shortcomings of the current API for
> > cases such as Rockchip.
> 
> I _think_ we're on the same page here.  If there are shortcomings with
> the current API that make it impossible to implement a feature, we've
> got to change and/or add to the existing API.  ...but we don't want to
> break existing users / drivers.
> 
> Note that historically I remember that Linus Torvalds has stated that
> there is no stable API within the Linux kernel and that forcing the
> in-kernel API to never change was bad for software development.  I
> tracked down my memory and found
> <http://lwn.net/1999/0211/a/lt-binary.html>.  Linus is rabid about not
> breaking userspace, but in general there's no strong requirement to
> never change the driver API inside the kernel.  That being said,
> changing the driver API causes a lot of churn, so presumably changing
> it in a backward compatible way (like adding to the API instead of
> changing it) will make things happier.

I didn't say anything about stable API. All I said is that new API
should be well-thought-out. Those are two very different things.

> >> So all we need is a new API call that lets you read the hardware
> >> values and make sure that the PWM regulator calls that before anyone
> >> calls pwm_config().  That's roughly B) above.
> >
> > Yes. I'm thinking that we should have a pwm_get_state() which retrieves
> > the current state of the PWM. For drivers that support hardware readout
> > this state should match the hardware state. For other drivers it should
> > reflect whatever was specified in DT; essentially what pwm_get_period()
> > and friends return today.
> 
> Excellent, so pwm_get_period() gets the period as specified in the
> device tree (or other board config) and pwm_get_state() returns the
> hardware state.  SGTM.

That's not quite what I was thinking. If hardware readout is supported
then whatever we report back should be the current hardware state unless
we're explicitly asked for something else. If we start mixing the state
and legacy APIs this way, we'll get into a situation where drivers that
support hardware readout behave differently than drivers that don't.

For example: A PWM device that's controlled by a driver that supports
hardware readout has a current period of 50000 ns and the firmware set
the period to 25000 ns. pwm_get_period() for this PWM device will return
50000 ns. If you reconfigure the PWM to generate a PWM signal with a
period of 30000 ns, pwm_get_period() would still return 50000 ns.

A driver that doesn't support hardware readout, on the contrary, would
return 50000 ns from pwm_get_period() on the first call, but after you
have reconfigured it using pwm_config() it will return the new period.

> > That way if you want to get the current voltage in the regulator-pwm
> > driver you'd simply do a pwm_get_state() and compute the voltage from
> > the period and duty cycle. If the PWM driver that you happen to use
> > doesn't support hardware readout, you'll get an initial output voltage
> > of 0, which is as good as any, really.
> 
> Sounds fine to me.  PWM regulator is in charge of calling
> pwm_get_state(), which can return 0 (or an error?) if driver (or
> underlying hardware) doesn't support hardware readout.  PWM regulator
> is in charge of using the resulting period / duty cycle to calculate a
> percentage.

I'm not sure if pwm_get_state() should ever return an error. For drivers
that support hardware readout, the resulting state should match what's
programmed to the hardware.

But for drivers without hardware readout support pwm_get_state() still
makes sense because after a pwm_apply_state() the internal logical state
would again match hardware.

The simplest way to get rid of this would be to change the core to apply
an initial configuration on probe. However that's probably going to
break your use-case again (it would set a 0 duty cycle because it isn't
configured in DT).

To allow your use-case to work we'd need to deal with two states: the
current hardware state and the "initial" state as defined by DT.
Unfortunately the PWM specifier in DT is not a full definition, it is
more like a partial initial configuration. The problem with that, and
I think that's what Mark was originally objecting to, is that it isn't
clear when to use the "initial" state and when to use the read hardware
state. After the first pwm_apply_state() you wouldn't ever have to use
the "initial" state again, because it's the same as the current state
(modulo the duty cycle).

Also for drivers such as clk-pwm the usefulness of the "initial" state
is reduced even more, because it doesn't even need the period specified
in DT. It uses only the flags (if at all).

Perhaps to avoid this confusion a new type of object, e.g. pwm_args,
could be introduced to hold configuration arguments given in the PWM
specifier (in DT) or the PWM lookup table (in board files).

It would then be the responsibility of the users to deal with that
information in a sensible way. In (almost?) all cases I would expect
that to be to program the PWM device in the user's ->probe(). In the
case of regulator-pwm I'd expect that ->probe() would do something
along these lines (error handling excluded):

	struct pwm_state state;
	struct pwm_args args;
	unsigned int ratio;

	pwm = pwm_get(...);

	pwm_get_state(pwm, &state);
	pwm_get_args(pwm, &args);

	ratio = (state.duty_cycle * 100) / state.period;

	state.duty_cycle = (ratio * args.period) / 100;
	state.period = args.period;
	state.flags = args.flags;

	pwm_apply_state(pwm, &state);

The ->set_voltage() implementation would then never need to care about
the PWM args, but rather do something like this:

	struct pwm_state state;
	unsigned int ratio;

	pwm_get_state(pwm, &state);

	state.duty_cycle = (ratio * state.period) / 100;

	pwm_apply_state(pwm, &state);

Does that sound about right?

> I _think_ the end result of all this is just:
> 
> 1. Introduce pwm_get_state() that gets hardware state.  Up for debate
> if this returns 0 or ERROR if a driver doesn't implement this.

Like I said above, I don't think pwm_get_state() should ever fail. It
should simply return the current state of the PWM, which might coincide
with the hardware state (for drivers that support hardware readout) or
will be the logical state (for drivers that don't).

Note that in the above example the logical state of the PWM, in cases
where the driver doesn't support hardware readout, the duty cycle will
be assumed to be 0, so the regulator-pwm driver would at ->probe() time
disable the regulator, at which point hardware state and logical state
will coincide again.

> 2. PWM regulator calls pwm_get_state at probe time to get hardware
> state, calculates a percentage (and voltage) with this.

I don't think that's enough. If we do this, we'll keep carrying around
the mismatch between hardware state and logical state indefinitely.

> 3. PWM regulator does nothing else until it is asked to set the
> voltage, but uses the voltage calculated from #2 to satisfy any "get
> voltage" calls.

This should work out of the box in the above. The initial state would
yield a voltage of 0 if hardware readout is not supported, whereas for
drivers that support hardware readout, the proper value can be derived
from duty cycle, period and the lookup table.

> 4. When asked to set the voltage, PWM regulator uses pwm_get_period()
> and calculates a duty cycle based on that, just like it does today.
> This uses pwm_config() which includes a duty cycle and period and is
> thus "atomic".

pwm_config() isn't atomic. pwm_apply_state() would be. The difference is
that pwm_config() can't at the same time enable/disable the PWM or set
the polarity.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/8ac9a4dd/attachment-0001.sig>

From arnd at arndb.de  Tue Feb 23 06:39:38 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 15:39:38 +0100
Subject: [PATCH] ARM: at91: avoid defining CONFIG_* symbols in source code
Message-ID: <1456238384-882646-1-git-send-email-arnd@arndb.de>

In an invalid randconfig build (fixed by another patch),
I ran across this warning:

arch/arm/include/debug/at91.S:18:0: error: "CONFIG_DEBUG_UART_VIRT" redefined [-Werror]
 #define CONFIG_DEBUG_UART_VIRT AT91_IO_P2V(CONFIG_DEBUG_UART_PHYS)

As Russell pointed out, we should never #define a macro starting
with CONFIG_ in a source file, as that is rather confusing.

This renames the macro to avoid the symbol clash.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Suggested-by: Russell King <linux at arm.linux.org.uk>
---
 arch/arm/include/debug/at91.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/debug/at91.S b/arch/arm/include/debug/at91.S
index 43243be94cfc..d4ae3b8e2426 100644
--- a/arch/arm/include/debug/at91.S
+++ b/arch/arm/include/debug/at91.S
@@ -15,7 +15,7 @@
 #define AT91_IO_P2V(x) (x)
 #endif
 
-#define CONFIG_DEBUG_UART_VIRT AT91_IO_P2V(CONFIG_DEBUG_UART_PHYS)
+#define AT91_DEBUG_UART_VIRT AT91_IO_P2V(CONFIG_DEBUG_UART_PHYS)
 
 #define AT91_DBGU_SR		(0x14)	/* Status Register */
 #define AT91_DBGU_THR		(0x1c)	/* Transmitter Holding Register */
@@ -24,7 +24,7 @@
 
 	.macro	addruart, rp, rv, tmp
 	ldr	\rp, =CONFIG_DEBUG_UART_PHYS		@ System peripherals (phys address)
-	ldr	\rv, =CONFIG_DEBUG_UART_VIRT		@ System peripherals (virt address)
+	ldr	\rv, =AT91_DEBUG_UART_VIRT		@ System peripherals (virt address)
 	.endm
 
 	.macro	senduart,rd,rx
-- 
2.7.0



From arnd at arndb.de  Tue Feb 23 06:43:21 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 15:43:21 +0100
Subject: [PATCH] [RFC] ARM: keystone: possibly fix big-endian kernels
Message-ID: <1456238609-962461-1-git-send-email-arnd@arndb.de>

While discussing a regressing in the netcp driver, I wondered
whether Keystone can work with a big-endian kernel, and noticed
that we don't switch endianess when we enter the kernel on the
secondary CPU, or when we call into smc.

I don't know whether this works on the machine, but on others
it does not, so this adds the explicit switch to big-endian
in keystone_secondary_startup.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-keystone/keystone.h | 2 +-
 arch/arm/mach-keystone/platsmp.c  | 2 +-
 arch/arm/mach-keystone/smc.S      | 8 ++++++++
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-keystone/keystone.h b/arch/arm/mach-keystone/keystone.h
index 33eaa037af5a..016ae7644e73 100644
--- a/arch/arm/mach-keystone/keystone.h
+++ b/arch/arm/mach-keystone/keystone.h
@@ -16,7 +16,7 @@
 #ifndef __ASSEMBLER__
 
 extern const struct smp_operations keystone_smp_ops;
-extern void secondary_startup(void);
+extern void keystone_secondary_startup(void);
 extern u32 keystone_cpu_smc(u32 command, u32 cpu, u32 addr);
 extern int keystone_pm_runtime_init(void);
 
diff --git a/arch/arm/mach-keystone/platsmp.c b/arch/arm/mach-keystone/platsmp.c
index 5665276972ec..c427787f78d1 100644
--- a/arch/arm/mach-keystone/platsmp.c
+++ b/arch/arm/mach-keystone/platsmp.c
@@ -26,7 +26,7 @@
 static int keystone_smp_boot_secondary(unsigned int cpu,
 						struct task_struct *idle)
 {
-	unsigned long start = virt_to_idmap(&secondary_startup);
+	unsigned long start = virt_to_idmap(&keystone_secondary_startup);
 	int error;
 
 	pr_debug("keystone-smp: booting cpu %d, vector %08lx\n",
diff --git a/arch/arm/mach-keystone/smc.S b/arch/arm/mach-keystone/smc.S
index d15de8179fab..81604c0d4e1b 100644
--- a/arch/arm/mach-keystone/smc.S
+++ b/arch/arm/mach-keystone/smc.S
@@ -10,6 +10,7 @@
  */
 
 #include <linux/linkage.h>
+#include <asm/assembler.h>
 
 /**
  * u32 keystone_cpu_smc(u32 command, u32 cpu, u32 addr)
@@ -26,3 +27,10 @@ ENTRY(keystone_cpu_smc)
 	smc	#0
 	ldmfd   sp!, {r4-r11, pc}
 ENDPROC(keystone_cpu_smc)
+
+#ifdef CONFIG_SMP
+ENTRY(keystone_secondary_startup)
+ARM_BE8(setend	be)			@ go BE8 if entered LE
+	b	secondary_startup
+ENDPROC(keystone_secondary_startup)
+#endif
-- 
2.7.0



From shannon.zhao at linaro.org  Tue Feb 23 06:52:16 2016
From: shannon.zhao at linaro.org (Shannon Zhao)
Date: Tue, 23 Feb 2016 22:52:16 +0800
Subject: [PATCH v12 16/21] KVM: ARM64: Add PMU overflow interrupt routing
In-Reply-To: <56CC695E.4010805@arm.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
 <1456133877-9584-17-git-send-email-zhaoshenglong@huawei.com>
 <56CC695E.4010805@arm.com>
Message-ID: <56CC7220.3020807@linaro.org>



On 2016/2/23 22:14, Marc Zyngier wrote:
> On 22/02/16 09:37, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao at linaro.org>
>>
>> When calling perf_event_create_kernel_counter to create perf_event,
>> assign a overflow handler. Then when the perf event overflows, set the
>> corresponding bit of guest PMOVSSET register. If this counter is enabled
>> and its interrupt is enabled as well, kick the vcpu to sync the
>> interrupt.
>>
>> On VM entry, if there is counter overflowed, inject the interrupt with
>> the level set to 1. Otherwise, inject the interrupt with the level set
>> to 0.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
>> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
>> Reviewed-by: Andrew Jones <drjones at redhat.com>
>
> As I mentioned yesterday, I was trying to pinpoint a performance drop, so I added PMU support to kvmtool (and made it an optional flag). This allowed be to find this:
>
>> ---
>>   arch/arm/kvm/arm.c    |  2 ++
>>   include/kvm/arm_pmu.h |  2 ++
>>   virt/kvm/arm/pmu.c    | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
>>   3 files changed, 50 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index dda1959..f54264c 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -28,6 +28,7 @@
>>   #include <linux/sched.h>
>>   #include <linux/kvm.h>
>>   #include <trace/events/kvm.h>
>> +#include <kvm/arm_pmu.h>
>>
>>   #define CREATE_TRACE_POINTS
>>   #include "trace.h"
>> @@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>   		 * non-preemptible context.
>>   		 */
>>   		preempt_disable();
>> +		kvm_pmu_flush_hwstate(vcpu);
>>   		kvm_timer_flush_hwstate(vcpu);
>>   		kvm_vgic_flush_hwstate(vcpu);
>>
>> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
>> index 8bc92d1..cf68f9a 100644
>> --- a/include/kvm/arm_pmu.h
>> +++ b/include/kvm/arm_pmu.h
>> @@ -44,6 +44,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
>>   void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
>>   void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
>>   void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
>> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
>>   void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
>>   void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
>>   void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>> @@ -67,6 +68,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
>>   static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>>   static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>>   static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
>> +static inline void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
>>   static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
>>   static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
>>   static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
>> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
>> index cda869c..6ac52ce 100644
>> --- a/virt/kvm/arm/pmu.c
>> +++ b/virt/kvm/arm/pmu.c
>> @@ -21,6 +21,7 @@
>>   #include <linux/perf_event.h>
>>   #include <asm/kvm_emulate.h>
>>   #include <kvm/arm_pmu.h>
>> +#include <kvm/arm_vgic.h>
>>
>>   /**
>>    * kvm_pmu_get_counter_value - get PMU counter value
>> @@ -181,6 +182,49 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
>>   }
>>
>>   /**
>> + * kvm_pmu_flush_hwstate - flush pmu state to cpu
>> + * @vcpu: The vcpu pointer
>> + *
>> + * Inject virtual PMU IRQ if IRQ is pending for this cpu.
>> + */
>> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
>> +{
>> +	struct kvm_pmu *pmu = &vcpu->arch.pmu;
>> +	u64 overflow;
>> +
>> +	if (!kvm_arm_pmu_v3_ready(vcpu))
>> +		return;
>> +
>> +	overflow = kvm_pmu_overflow_status(vcpu);
>> +	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id, pmu->irq_num, !!overflow);
>
> It turns out that this single line costs us about 400 cycles on each entry:
>
Oh, it's really a time-consuming function.

> maz at flakes:~/kvm-ws-tests$ make LKVM=~/kvmtool/lkvm LKVM_ARGS=--pmu PERF=perf_4.3 tests-gicv2
> GICv2:
> do_hvc.bin:5690.17
> do_sgi.bin:9395.05
> do_sysreg.bin:5912.6
> maz at flakes:~/kvm-ws-tests$ make LKVM=~/kvmtool/lkvm PERF=perf_4.3 tests-gicv2
> GICv2:
> do_hvc.bin:5285.02
> do_sgi.bin:9131.24
> do_sysreg.bin:5563.7
>
> Caching the irq state and only injecting it if it has changed (just like we do for the timer) brings performance back to its previous level:
>
Marc, thanks a lot for finding out this. I'll merge below changes into 
this series and send out v13 tomorrow.

> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 176913f..b23e636 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -35,6 +35,7 @@ struct kvm_pmu {
>   	int irq_num;
>   	struct kvm_pmc pmc[ARMV8_PMU_MAX_COUNTERS];
>   	bool ready;
> +	bool irq_level;
>   };
>
>   #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index 904617e..7156f8b 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -229,13 +229,17 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
>   void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
>   {
>   	struct kvm_pmu *pmu = &vcpu->arch.pmu;
> -	u64 overflow;
> +	bool overflow;
>
>   	if (!kvm_arm_pmu_v3_ready(vcpu))
>   		return;
>
> -	overflow = kvm_pmu_overflow_status(vcpu);
> -	kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id, pmu->irq_num, !!overflow);
> +	overflow = !!kvm_pmu_overflow_status(vcpu);
> +	if (pmu->irq_level != overflow) {
> +		pmu->irq_level = overflow;
> +		kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
> +				    pmu->irq_num, overflow);
> +	}
>   }
>
>   static inline struct kvm_vcpu *kvm_pmc_to_vcpu(struct kvm_pmc *pmc)
>
>
> Thanks,
>
> 	M.
>

-- 
Shannon


From linux at arm.linux.org.uk  Tue Feb 23 06:53:18 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Tue, 23 Feb 2016 14:53:18 +0000
Subject: [PATCH] [RFC] ARM: keystone: possibly fix big-endian kernels
In-Reply-To: <1456238609-962461-1-git-send-email-arnd@arndb.de>
References: <1456238609-962461-1-git-send-email-arnd@arndb.de>
Message-ID: <20160223145318.GK19428@n2100.arm.linux.org.uk>

On Tue, Feb 23, 2016 at 03:43:21PM +0100, Arnd Bergmann wrote:
> While discussing a regressing in the netcp driver, I wondered
> whether Keystone can work with a big-endian kernel, and noticed
> that we don't switch endianess when we enter the kernel on the
> secondary CPU, or when we call into smc.

NAK.  Sorry Arnd, you're worringly wrong on this.

secondary_startup will do the setend if necessary, there's no need
to do this kind of junk in each and every platform.  It's been this
way since:

commit 97bcb0fea590d3d704f985bec08f342d28992634
Author: Ben Dooks <ben.dooks at codethink.co.uk>
Date:   Fri Feb 1 09:40:42 2013 +0000

So, I hope you've not been telling platform folk to do this.  Please
audit the arm-soc code to make sure, thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From hdegoede at redhat.com  Tue Feb 23 06:53:44 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Tue, 23 Feb 2016 15:53:44 +0100
Subject: [linux-sunxi] [PATCH] ARM: dts: sun4i: Enable USB DRC on
 Hyundai-a7hd
In-Reply-To: <1455656404-31191-1-git-send-email-peter@korsgaard.com>
References: <1455656404-31191-1-git-send-email-peter@korsgaard.com>
Message-ID: <56CC7278.6060901@redhat.com>

Hi,

On 02/16/2016 10:00 PM, Peter Korsgaard wrote:
> Enable the OTG USB controller on the A7HD.
>
> Signed-off-by: Peter Korsgaard <peter at korsgaard.com>

Patch looks good to me:

Reviewed-by: Hans de Goede <hdegoede at redhat.com>

Regards,

Hans


> ---
>   arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts | 34 ++++++++++++++++++++++++++++
>   1 file changed, 34 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts b/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
> index 43f58fb..9103864 100644
> --- a/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-hyundai-a7hd.dts
> @@ -87,6 +87,30 @@
>   	status = "okay";
>   };
>
> +&otg_sram {
> +	status = "okay";
> +};
> +
> +&pio {
> +	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
> +		allwinner,pins = "PH4";
> +		allwinner,function = "gpio_in";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> +	};
> +
> +	usb0_vbus_detect_pin: usb0_vbus_detect_pin at 0 {
> +		allwinner,pins = "PH5";
> +		allwinner,function = "gpio_in";
> +		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> +		allwinner,pull = <SUN4I_PINCTRL_PULL_DOWN>;
> +	};
> +};
> +
> +&reg_usb0_vbus {
> +	status = "okay";
> +};
> +
>   &reg_usb2_vbus {
>   	gpio = <&pio 7 6 GPIO_ACTIVE_HIGH>; /* PH6 */
>   	status = "okay";
> @@ -102,7 +126,17 @@
>   	allwinner,pins = "PH6";
>   };
>
> +&usb_otg {
> +	dr_mode = "otg";
> +	status = "okay";
> +};
> +
>   &usbphy {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
> +	usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
> +	usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
> +	usb0_vbus-supply = <&reg_usb0_vbus>;
>   	usb2_vbus-supply = <&reg_usb2_vbus>;
>   	status = "okay";
>   };
>


From thierry.reding at gmail.com  Tue Feb 23 06:57:32 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 23 Feb 2016 15:57:32 +0100
Subject: [PATCH v3 00/12] pwm: add support for atomic update
In-Reply-To: <20160204150150.553d36df@bbrezillon>
References: <1442828009-6241-1-git-send-email-boris.brezillon@free-electrons.com>
 <2341981.a79ioYM9Es@diego> <20151110173416.GB21727@ulmo>
 <CAD=FV=WL3jYEgVe-m6QcAyQwfJgdX4J5OtKisKwyoKOrTSpEQA@mail.gmail.com>
 <20160125170855.GA10182@ulmo>
 <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
 <20160203145337.GD9650@ulmo>
 <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
 <20160204110203.GL4455@sirena.org.uk>
 <20160204150150.553d36df@bbrezillon>
Message-ID: <20160223145732.GB27656@ulmo>

On Thu, Feb 04, 2016 at 03:01:50PM +0100, Boris Brezillon wrote:
> Hi Mark, Thierry,
> 
> On Thu, 4 Feb 2016 11:02:03 +0000
> Mark Brown <broonie at kernel.org> wrote:
> 
> > On Wed, Feb 03, 2016 at 11:04:20AM -0800, Doug Anderson wrote:
> > 
> > > Sure.  ...but you agree that somehow you need a new API call for this,
> > > right?  Somehow the PWM regulator needs to be able to say that it
> > > wants the hardware state, not the initial state as specified in the
> > > device tree.
> > 
> > Wouldn't the most direct way to do that be to just not specify anything
> > in the DT?  If there *is* something in DT but we ignore it that's a bit
> > weird.
> 
> Just adding some inputs on this specific aspect. The reason we have to
> specify a period (and, to a lesser extent, the polarity) in the DT or
> PWM lookup table is because what most PWM users want is to specify a
> dutycycle relatively to a predefined period value.

That's not quite correct. The reason why we need the information in DT
is because it can't be derived from anything else. It is board-specific
data for which there's no heuristic that will work in all cases.

> If we decide to remove those information from the DT, then you'll need
> a way to define it somewhere else, and then the is question is 'where?'.
> 
> Users that really want to control their period (this could the case for
> the clk-pwm driver) could completely ignore DT/lookup-table information
> and set the period and absolute dutycycle directly.

Yes, I think clk-pwm is very special in this regard because the period
can be derived from the requested clock rate. It would be complicated to
implement DT parsing that ignores parts of the specifier in some cases
but not in others. Simply having the clk-pwm driver ignore whatever is
in the table (or perhaps bail out on periods other than 0 for example).

> Now, from what I seen, what most PWM users want to do is:
> 
> 	pwm_set_rel_duty_scale(pwm, rel_value, scale);
> or 
> 	rel_duty = pwm_get_rel_duty_cycle(pwm, scale);
> 
> where scale depends on the precision you need for your use case (most
> of the time it's expressed in percent).
> 
> So, how about providing this kind of API (this is what I proposed in
> one of my previous email)?
> 
> This would not only solve our problem (say you have a period at
> boot-time that differs from the one you'll set when first applying a
> new relative duty cycle, then the resulting relative value would still
> be correct), but it would also remove a lot of boiler plate code from
> PWM users code (if you take a look at pwm-regulator, pwm-leds, pwm-fan
> and probably others, you'll see that they are all doing this conversion
> manually).

I don't think this gains us much. The above would work for pwm-regulator
and pwm-fan, in both cases it'd replace a single line with two lines and
fitting the expressions into function arguments is likely going to be
hideous. For leds-pwm this wouldn't work, because of the low-active case
that it supports.

> Now, the last blocking point is, what if the PWM driver does not
> implement HW-readout. In this case, the pwm-regulator will probably
> expose a 0V output (IIRC, dutycycle is set to 0 by default) when it's
> actually providing something else. But is this really important? I
> mean, if the user really wants to have a reliable information, then he
> will implement initial-state retrieval in its PWM controller driver.
> Alternatively, we could put a flag specifying whether the PWM chip
> supports initial state retrieval.

I reached the same conclusion in another subthread. If hardware readout
isn't supported, I think the most natural thing to do is simply use the
initial state (i.e. what's defined in DT or board files) instead. There
is an argument, I think, to be made for having users apply the initial
state at probe time to forcibly apply the logical state to hardware and
subsequently not care about the initial state anymore. For most cases
that might not even be necessary, though.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/169b7150/attachment-0001.sig>

From arnd at arndb.de  Tue Feb 23 07:01:06 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Tue, 23 Feb 2016 16:01:06 +0100
Subject: [PATCH] [RFC] ARM: keystone: possibly fix big-endian kernels
In-Reply-To: <20160223145318.GK19428@n2100.arm.linux.org.uk>
References: <1456238609-962461-1-git-send-email-arnd@arndb.de>
 <20160223145318.GK19428@n2100.arm.linux.org.uk>
Message-ID: <3249746.5p1eRtyJ9a@wuerfel>

On Tuesday 23 February 2016 14:53:18 Russell King - ARM Linux wrote:
> On Tue, Feb 23, 2016 at 03:43:21PM +0100, Arnd Bergmann wrote:
> > While discussing a regressing in the netcp driver, I wondered
> > whether Keystone can work with a big-endian kernel, and noticed
> > that we don't switch endianess when we enter the kernel on the
> > secondary CPU, or when we call into smc.
> 
> NAK.  Sorry Arnd, you're worringly wrong on this.
> 
> secondary_startup will do the setend if necessary, there's no need
> to do this kind of junk in each and every platform.  It's been this
> way since:
> 
> commit 97bcb0fea590d3d704f985bec08f342d28992634
> Author: Ben Dooks <ben.dooks at codethink.co.uk>
> Date:   Fri Feb 1 09:40:42 2013 +0000
> 
> So, I hope you've not been telling platform folk to do this.  Please
> audit the arm-soc code to make sure, thanks.
> 

I see my mistake now: I looked at the secondary_startup() function
by looking up the location in ctags, and that pointed me to
arch/arm/kernel/head-nommu.S.

I was surprised when I didn't see the setend() in there, but
didn't realize that I was looking in the wrong place, but it
made some sense when I found the setend in a couple of other
platforms that all need a wrapper anyway.

Sorry about the noise.

	Arnd


From ldewangan at nvidia.com  Tue Feb 23 06:58:24 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Tue, 23 Feb 2016 20:28:24 +0530
Subject: [PATCH 10/61] gpio: ath79: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <20160222211323.5c10533f@tock>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>	<1456150130-2668-11-git-send-email-ldewangan@nvidia.com>
 <20160222211323.5c10533f@tock>
Message-ID: <56CC7390.6050805@nvidia.com>


On Tuesday 23 February 2016 01:43 AM, Alban wrote:
> On Mon, 22 Feb 2016 19:37:59 +0530
> Laxman Dewangan <ldewangan at nvidia.com> wrote:
>
>> Use devm_gpiochip_add_data() for GPIO registration.
>>
>> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
>> Cc: Alban Bedel <albeu at free.fr>
>> ---
>>   drivers/gpio/gpio-ath79.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpio/gpio-ath79.c b/drivers/gpio/gpio-ath79.c
>> index d13dd13..a6aad59 100644
>> --- a/drivers/gpio/gpio-ath79.c
>> +++ b/drivers/gpio/gpio-ath79.c
>> @@ -182,7 +182,7 @@ static int ath79_gpio_probe(struct platform_device *pdev)
>>   		ctrl->chip.direction_output = ar934x_gpio_direction_output;
>>   	}
>>   
>> -	err = gpiochip_add_data(&ctrl->chip, ctrl);
>> +	err = devm_gpiochip_add_data(&pdev->dev, &ctrl->chip, ctrl);
>>   	if (err) {
>>   		dev_err(&pdev->dev,
>>   			"cannot add AR71xx GPIO chip, error=%d", err);
> With the patches already applied to the devel branch a few more changes
> will be needed to remove the calls to gpiochip_remove() in the probe
> error path and the remove callback.
>
OK, I will drop this patch when provide the git pointer to Linus.
We can work on this later.



From alexandre.torgue at gmail.com  Tue Feb 23 07:10:40 2016
From: alexandre.torgue at gmail.com (Alexandre TORGUE)
Date: Tue, 23 Feb 2016 16:10:40 +0100
Subject: [PATCH v2 0/4] Add Ethernet support on STM32F429
Message-ID: <1456240244-10275-1-git-send-email-alexandre.torgue@gmail.com>

STM32F429 Chip embeds a Synopsys 3.50a MAC IP.
This series:
 -enhance current stmmac driver to control it (code already
available) and adds basic glue for STM32F429 chip.
 -Enable basic Net config in kernel.

Note that DT patches are not present because STM32 pinctrl code is not
yet avalaible.

Changes since v1:
 -Fix Kbuild issue in Kconfig.
 -Remove init/exit callbacks. Suspend/Resume and remove driver is no more
driven in stmmac_pltfr but directly in dwmac-stm32 glue driver.
 -Take into account Joachim review.

Regards.

Alexandre.

Alexandre TORGUE (4):
  net: ethernet: dwmac: add Ethernet glue logic for stm32 chip
  Documentation: Bindings: Add STM32 DWMAC glue
  net: ethernet: stmmac: add support of Synopsys 3.50a MAC IP
  ARM: STM32: Enable Ethernet in stm32_defconfig

 .../devicetree/bindings/net/stm32-dwmac.txt        |  41 ++++
 arch/arm/configs/stm32_defconfig                   |   9 +
 drivers/net/ethernet/stmicro/stmmac/Kconfig        |  12 ++
 drivers/net/ethernet/stmicro/stmmac/Makefile       |   1 +
 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c  | 208 +++++++++++++++++++++
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |   1 +
 6 files changed, 272 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/stm32-dwmac.txt
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c

-- 
1.9.1



From alexandre.torgue at gmail.com  Tue Feb 23 07:10:41 2016
From: alexandre.torgue at gmail.com (Alexandre TORGUE)
Date: Tue, 23 Feb 2016 16:10:41 +0100
Subject: [PATCH v2 1/4] net: ethernet: dwmac: add Ethernet glue logic for
 stm32 chip
In-Reply-To: <1456240244-10275-1-git-send-email-alexandre.torgue@gmail.com>
References: <1456240244-10275-1-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <1456240244-10275-2-git-send-email-alexandre.torgue@gmail.com>

stm324xx family chips support Synopsys MAC 3.510 IP.
This patch adds settings for logical glue logic:
-clocks
-mode selection MII or RMII.

Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index cec147d..f63bdcf 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -114,6 +114,18 @@ config DWMAC_SUNXI
 	  This selects Allwinner SoC glue layer support for the
 	  stmmac device driver. This driver is used for A20/A31
 	  GMAC ethernet controller.
+
+config DWMAC_STM32
+	tristate "STM32 DWMAC support"
+	default ARCH_STM32
+	depends on OF && HAS_IOMEM
+	select MFD_SYSCON
+	---help---
+	  Support for ethernet controller on STM32 SOCs.
+
+	  This selects STM32 SoC glue layer support for the stmmac
+	  device driver. This driver is used on for the STM32 series
+	  SOCs GMAC ethernet controller.
 endif
 
 config STMMAC_PCI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index b390161..559086d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_DWMAC_ROCKCHIP)	+= dwmac-rk.o
 obj-$(CONFIG_DWMAC_SOCFPGA)	+= dwmac-socfpga.o
 obj-$(CONFIG_DWMAC_STI)		+= dwmac-sti.o
 obj-$(CONFIG_DWMAC_SUNXI)	+= dwmac-sunxi.o
+obj-$(CONFIG_DWMAC_STM32)	+= dwmac-stm32.o
 obj-$(CONFIG_DWMAC_GENERIC)	+= dwmac-generic.o
 stmmac-platform-objs:= stmmac_platform.o
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
new file mode 100644
index 0000000..0b48ee7
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
@@ -0,0 +1,208 @@
+/*
+ * dwmac-stm32.c - DWMAC Specific Glue layer for STM32 MCU
+ *
+ * Copyright (C) Alexandre Torgue 2015
+ * Author:  Alexandre Torgue <alexandre.torgue at gmail.com>
+ * License terms:  GNU General Public License (GPL), version 2
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_net.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/stmmac.h>
+
+#include "stmmac_platform.h"
+
+#define MII_PHY_SEL_MASK	BIT(23)
+
+struct stm32_dwmac {
+	int interface;		/* MII interface */
+	struct clk *clk_tx;
+	struct clk *clk_rx;
+	u32 mode_reg;		/* MAC glue-logic mode register */
+	struct regmap *regmap;
+	u32 speed;
+};
+
+static int stm32_dwmac_init(void *priv)
+{
+	struct stm32_dwmac *dwmac = priv;
+	struct regmap *regmap = dwmac->regmap;
+	int ret, iface = dwmac->interface;
+	u32 reg = dwmac->mode_reg;
+	u32 val;
+
+	ret = clk_prepare_enable(dwmac->clk_tx);
+	if (ret)
+		goto out;
+
+	ret = clk_prepare_enable(dwmac->clk_rx);
+	if (ret)
+		goto out_disable_clk_tx;
+
+	val = (iface == PHY_INTERFACE_MODE_MII) ? 0 : 1;
+	ret = regmap_update_bits(regmap, reg, MII_PHY_SEL_MASK, val);
+	if (ret)
+		goto out_disable_clk_tx_rx;
+
+	return 0;
+
+out_disable_clk_tx_rx:
+	clk_disable_unprepare(dwmac->clk_rx);
+out_disable_clk_tx:
+	clk_disable_unprepare(dwmac->clk_tx);
+out:
+	return ret;
+}
+
+static void stm32_dwmac_exit(void *priv)
+{
+	struct stm32_dwmac *dwmac = priv;
+
+	clk_disable_unprepare(dwmac->clk_tx);
+	clk_disable_unprepare(dwmac->clk_rx);
+}
+
+static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
+				  struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct regmap *regmap;
+	int err;
+
+	/*  Get TX/RX clocks */
+	dwmac->clk_tx = devm_clk_get(dev, "tx-clk");
+	if (IS_ERR(dwmac->clk_tx)) {
+		dev_warn(dev, "No tx clock provided...\n");
+		dwmac->clk_tx = NULL;
+	}
+	dwmac->clk_rx = devm_clk_get(dev, "rx-clk");
+	if (IS_ERR(dwmac->clk_rx)) {
+		dev_warn(dev, "No rx clock provided...\n");
+		dwmac->clk_rx = NULL;
+	}
+
+	/* Get mode register */
+	regmap = syscon_regmap_lookup_by_phandle(np, "st,syscon");
+	if (IS_ERR(regmap))
+		return PTR_ERR(regmap);
+
+	err = of_property_read_u32_index(np, "st,syscon", 1, &dwmac->mode_reg);
+	if (err) {
+		dev_err(dev, "Can't get sysconfig mode offset (%d)\n", err);
+		return err;
+	}
+
+	dwmac->interface = of_get_phy_mode(np);
+	dwmac->regmap = regmap;
+
+	return 0;
+}
+
+static int stm32_dwmac_probe(struct platform_device *pdev)
+{
+	struct plat_stmmacenet_data *plat_dat;
+	struct stmmac_resources stmmac_res;
+	struct stm32_dwmac *dwmac;
+	int ret;
+
+	ret = stmmac_get_platform_resources(pdev, &stmmac_res);
+	if (ret)
+		return ret;
+
+	plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
+	if (IS_ERR(plat_dat))
+		return PTR_ERR(plat_dat);
+
+	dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
+	if (!dwmac)
+		return -ENOMEM;
+
+	ret = stm32_dwmac_parse_data(dwmac, pdev);
+	if (ret) {
+		dev_err(&pdev->dev, "Unable to parse OF data\n");
+		return ret;
+	}
+
+	plat_dat->bsp_priv = dwmac;
+
+	ret = stm32_dwmac_init(plat_dat->bsp_priv);
+	if (ret)
+		return ret;
+
+	return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
+}
+
+static int stm32_dwmac_remove(struct platform_device *pdev)
+{
+	struct net_device *ndev = platform_get_drvdata(pdev);
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	int ret = stmmac_dvr_remove(ndev);
+
+	stm32_dwmac_exit(priv->plat->bsp_priv);
+
+	return ret;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int stm32_dwmac_suspend(struct device *dev)
+{
+	struct net_device *ndev = dev_get_drvdata(dev);
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	int ret;
+
+	ret = stmmac_suspend(ndev);
+	stm32_dwmac_exit(priv->plat->bsp_priv);
+
+	return ret;
+}
+
+static int stm32_dwmac_resume(struct device *dev)
+{
+	struct net_device *ndev = dev_get_drvdata(dev);
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	int ret;
+
+	ret = stm32_dwmac_init(priv->plat->bsp_priv);
+	if (ret)
+		goto out_regmap;
+
+	ret = stmmac_resume(ndev);
+
+out_regmap:
+	return ret;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+SIMPLE_DEV_PM_OPS(stm32_dwmac_pm_ops, stm32_dwmac_suspend, stm32_dwmac_resume);
+
+static const struct of_device_id stm32_dwmac_match[] = {
+	{ .compatible = "st,stm32-dwmac"},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, stm32_dwmac_match);
+
+static struct platform_driver stm32_dwmac_driver = {
+	.probe  = stm32_dwmac_probe,
+	.remove = stm32_dwmac_remove,
+	.driver = {
+		.name           = "stm32-dwmac",
+		.pm		= &stm32_dwmac_pm_ops,
+		.of_match_table = stm32_dwmac_match,
+	},
+};
+module_platform_driver(stm32_dwmac_driver);
+
+MODULE_AUTHOR("Alexandre Torgue <alexandre.torgue at gmail.com>");
+MODULE_DESCRIPTION("STMicroelectronics MCU DWMAC Specific Glue layer");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1



From alexandre.torgue at gmail.com  Tue Feb 23 07:10:42 2016
From: alexandre.torgue at gmail.com (Alexandre TORGUE)
Date: Tue, 23 Feb 2016 16:10:42 +0100
Subject: [PATCH v2 2/4] Documentation: Bindings: Add STM32 DWMAC glue
In-Reply-To: <1456240244-10275-1-git-send-email-alexandre.torgue@gmail.com>
References: <1456240244-10275-1-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <1456240244-10275-3-git-send-email-alexandre.torgue@gmail.com>

Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>

diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
new file mode 100644
index 0000000..18734b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
@@ -0,0 +1,41 @@
+STMicroelectronics STM32 / MCU DWMAC glue layer controller
+
+This file documents platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+The device node has following properties.
+
+Required properties:
+- compatible:  Should be "st,stm32-dwmac" to select glue, and
+	       "snps,dwmac-3.50a" to select IP vesrion.
+- clocks: Should contain the GMAC main clock, and tx clock
+- compatible:  Should be "st,stm32-dwmac" to select glue and
+	       "snps,dwmac-3.50a" to select IP version.
+- clocks: Should contain the MAC main clock
+- clock-names: Should contain the clock names "stmmaceth".
+- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
+	      encompases the glue register, and the offset of the control register.
+
+Optional properties:
+- clocks: Could contain:
+	- the tx clock,
+	- the rx clock
+- clock-names: Could contain the clock names "tx-clk", "rx-clk"
+
+Example:
+
+		ethernet0: dwmac at 40028000 {
+			device_type = "network";
+			compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
+			status = "disabled";
+			reg = <0x40028000 0x8000>;
+			reg-names = "stmmaceth";
+			interrupts = <0 61 0>, <0 62 0>;
+			interrupt-names = "macirq", "eth_wake_irq";
+			clock-names = "stmmaceth", "tx-clk", "rx-clk";
+			clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
+			st,syscon = <&syscfg 0x4>;
+			snps,pbl = <32>;
+			snps,mixed-burst;
+			dma-ranges;
+		};
-- 
1.9.1



From alexandre.torgue at gmail.com  Tue Feb 23 07:10:43 2016
From: alexandre.torgue at gmail.com (Alexandre TORGUE)
Date: Tue, 23 Feb 2016 16:10:43 +0100
Subject: [PATCH v2 3/4] net: ethernet: stmmac: add support of Synopsys 3.50a
 MAC IP
In-Reply-To: <1456240244-10275-1-git-send-email-alexandre.torgue@gmail.com>
References: <1456240244-10275-1-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <1456240244-10275-4-git-send-email-alexandre.torgue@gmail.com>

Adds support of Synopsys 3.50a MAC IP in stmmac driver.

Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 6a52fa1..6cca626 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -178,6 +178,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
 	 * once needed on other platforms.
 	 */
 	if (of_device_is_compatible(np, "st,spear600-gmac") ||
+		of_device_is_compatible(np, "snps,dwmac-3.50a") ||
 		of_device_is_compatible(np, "snps,dwmac-3.70a") ||
 		of_device_is_compatible(np, "snps,dwmac")) {
 		/* Note that the max-frame-size parameter as defined in the
-- 
1.9.1



From alexandre.torgue at gmail.com  Tue Feb 23 07:10:44 2016
From: alexandre.torgue at gmail.com (Alexandre TORGUE)
Date: Tue, 23 Feb 2016 16:10:44 +0100
Subject: [PATCH v2 4/4] ARM: STM32: Enable Ethernet in stm32_defconfig
In-Reply-To: <1456240244-10275-1-git-send-email-alexandre.torgue@gmail.com>
References: <1456240244-10275-1-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <1456240244-10275-5-git-send-email-alexandre.torgue@gmail.com>

Enable basic Ethernet support (IPV4) for stm32 defconfig.

Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index ec52505..8b8abe0 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -33,11 +33,20 @@ CONFIG_XIP_PHYS_ADDR=0x08008000
 CONFIG_BINFMT_FLAT=y
 CONFIG_BINFMT_SHARED_FLAT=y
 # CONFIG_COREDUMP is not set
+CONFIG_NET=y
+CONFIG_INET=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_IPV6 is not set
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_FW_LOADER is not set
 # CONFIG_BLK_DEV is not set
 CONFIG_EEPROM_93CX6=y
+CONFIG_NETDEVICES=y
+CONFIG_STMMAC_ETH=y
+# CONFIG_WLAN is not set
 # CONFIG_INPUT is not set
 # CONFIG_SERIO is not set
 # CONFIG_VT is not set
-- 
1.9.1



From thierry.reding at gmail.com  Tue Feb 23 07:12:41 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 23 Feb 2016 16:12:41 +0100
Subject: [PATCH v2 2/2] drm/panel: Support for LG lp120up1 panel with eDP
 input
In-Reply-To: <CAGUYZuSVghfC75eWihA82WxC8pF67mWKQMJ-95F2ezqMssyxfQ@mail.gmail.com>
References: <1456138904-15258-1-git-send-email-jitao.shi@mediatek.com>
 <1456138904-15258-2-git-send-email-jitao.shi@mediatek.com>
 <CAGUYZuSsrneg8zQ0Ro8z5C469A2D-TOKpONECxWdoM6T+xNAeg@mail.gmail.com>
 <20160222114308.GA22505@ulmo>
 <CAGUYZuSVghfC75eWihA82WxC8pF67mWKQMJ-95F2ezqMssyxfQ@mail.gmail.com>
Message-ID: <20160223151241.GC27656@ulmo>

On Tue, Feb 23, 2016 at 10:45:01AM +0530, sanjeev sharma wrote:
> Hello Thierry,
> 
> I am not agree here and how it would be redundant ?

The panel being a separate device means that it needs a compatible
value and the compatible value implies a specific video timing. It
would be redundant, therefore, to repeat the video timing in the
panel's device tree node that already has the compatible string.

> please see lvds interface, where panel timing parameter is defined in the
> Device Tree. If there are multiple display panel then we can create a
> separate dtsi file and include in main Board dts file. I believe that, It
> is simpler way to support multiple panel.

Two things: you can define a separate .dtsi file with the panel
definition with the current approach, too. But it would be a waste to do
so because really the only thing you need to change is the compatible
string.

The approach chosen in the DTS that you link to below might seem like a
simpler way, but it completely ignores aspects other than timings. What
if the panel requires a GPIO and or regulator to turn on. How are you
going to represent the power up sequence for that in DT? This was
attempted a long time ago and deemed too complicated to do in DT, hence
why we ended up with what we have now.

There are also panels on more complicated busses, such as DSI. These
panels often require additional register programming, so in addition to
the above you'd need some sort of register programming table in DT for
these to work.

> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/boot/dts/imx6q-sabrelite.dts?h=imx_3.14.38_6qp_beta#n225

That's not an upstream tree, so it isn't relevant to this discussion.
The decision to make the panel a separate device and put the video
timings into the driver was made a couple of years ago and we're not
going to change that. It's fine if you want to disagree, but I'm afraid
it won't change things.

Thierry

> On Mon, Feb 22, 2016 at 5:13 PM, Thierry Reding <thierry.reding at gmail.com>
> wrote:
> 
> > On Mon, Feb 22, 2016 at 04:42:54PM +0530, sanjeev sharma wrote:
> > > Hello Jitao,
> > >
> > > Can't we add this panel information in device tree file instead inside
> > the
> > > device driver ?
> >
> > We could, but that would be redundant. Panels need to be represented by
> > a specific compatible string anyway, and that compatible string implies
> > the video timings, bits-per-color, width and height.
> >
> > Also there's more to panels than just the timings or dimensions. Power
> > up and power down sequences are also implied by the compatible stirng.
> > Describing all of that in the device tree was at some point attempted,
> > but in the end it turned out too complicated and we ended up with what
> > we have now.
> >
> > Thierry
> >
> > > On Mon, Feb 22, 2016 at 4:31 PM, Jitao Shi <jitao.shi at mediatek.com>
> > wrote:
> > >
> > > > The LG lp120up1 TFT LCD panel with eDP interface is a 12.0" 1920x1280
> > > > panel, which can be supported by the simple panel driver
> > > >
> > > > Signed-off-by: Jitao Shi <jitao.shi at mediatek.com>
> > > > ---
> > > > Changes since v1:
> > > >  - Add eDP panel type in comment msg
> > > >  - Fixed comment msg with 72 characters width
> > > > ---
> > > >  drivers/gpu/drm/panel/panel-simple.c |   26 ++++++++++++++++++++++++++
> > > >  1 file changed, 26 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > > b/drivers/gpu/drm/panel/panel-simple.c
> > > > index f88a631..2030c37 100644
> > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > @@ -982,6 +982,29 @@ static const struct panel_desc lg_lb070wv8 = {
> > > >         .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> > > >  };
> > > >
> > > > +static const struct drm_display_mode lg_lp120up1_mode = {
> > > > +       .clock = 162300,
> > > > +       .hdisplay = 1920,
> > > > +       .hsync_start = 1920 + 40,
> > > > +       .hsync_end = 1920 + 40 + 40,
> > > > +       .htotal = 1920 + 40 + 40+ 80,
> > > > +       .vdisplay = 1280,
> > > > +       .vsync_start = 1280 + 4,
> > > > +       .vsync_end = 1280 + 4 + 4,
> > > > +       .vtotal = 1280 + 4 + 4 + 12,
> > > > +       .vrefresh = 60,
> > > > +};
> > > > +
> > > > +static const struct panel_desc lg_lp120up1 = {
> > > > +       .modes = &lg_lp120up1_mode,
> > > > +       .num_modes = 1,
> > > > +       .bpc = 8,
> > > > +       .size = {
> > > > +               .width = 267,
> > > > +               .height = 183,
> > > > +       },
> > > > +};
> > > > +
> > > >  static const struct drm_display_mode lg_lp129qe_mode = {
> > > >         .clock = 285250,
> > > >         .hdisplay = 2560,
> > > > @@ -1256,6 +1279,9 @@ static const struct of_device_id
> > platform_of_match[]
> > > > = {
> > > >                 .compatible = "lg,lb070wv8",
> > > >                 .data = &lg_lb070wv8,
> > > >         }, {
> > > > +               .compatible = "lg,lp120up1",
> > > > +               .data = &lg_lp120up1,
> > > > +       }, {
> > > >                 .compatible = "lg,lp129qe",
> > > >                 .data = &lg_lp129qe,
> > > >         }, {
> > > > --
> > > > 1.7.9.5
> > > >
> > > >
> > > > _______________________________________________
> > > > linux-arm-kernel mailing list
> > > > linux-arm-kernel at lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > > >
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/84469bc0/attachment.sig>

From jason at lakedaemon.net  Tue Feb 23 07:17:03 2016
From: jason at lakedaemon.net (Jason Cooper)
Date: Tue, 23 Feb 2016 15:17:03 +0000
Subject: [PATCH 0/3] ARM: mvebu: randconfig warning fixes
In-Reply-To: <1456236403-115511-1-git-send-email-arnd@arndb.de>
References: <1456236403-115511-1-git-send-email-arnd@arndb.de>
Message-ID: <20160223151703.GI958@io.lakedaemon.net>

Hey Arnd,

On Tue, Feb 23, 2016 at 03:06:36PM +0100, Arnd Bergmann wrote:
> Here are three more warning fixes for orion/mv78xx0/mvebu. All
> are really harmless and I'm just shutting up the warnings
> as the current code is basically ok.

Acked-by: Jason Cooper <jason at lakedaemon.net>

thx,

Jason.


From dinguyen at opensource.altera.com  Tue Feb 23 07:22:47 2016
From: dinguyen at opensource.altera.com (Dinh Nguyen)
Date: Tue, 23 Feb 2016 09:22:47 -0600
Subject: [PATCH] ARM: socfpga: hide unused functions
In-Reply-To: <1456236527-189885-1-git-send-email-arnd@arndb.de>
References: <1456236527-189885-1-git-send-email-arnd@arndb.de>
Message-ID: <56CC7947.6000909@opensource.altera.com>



On 02/23/2016 08:08 AM, Arnd Bergmann wrote:
> The cpu_die and cpu_kill callbacks are only used when CONFIG_HOTPLUG_CPU
> is enabled, otherwise we get a warning about them:
> 
> arch/arm/mach-socfpga/platsmp.c:102:13: error: 'socfpga_cpu_die' defined but not used [-Werror=unused-function]
> arch/arm/mach-socfpga/platsmp.c:115:12: error: 'socfpga_cpu_kill' defined but not used [-Werror=unused-function]
> 
> This adds the appropriate #ifdef.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/mach-socfpga/platsmp.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/mach-socfpga/platsmp.c b/arch/arm/mach-socfpga/platsmp.c
> index cbb0a54df80a..07945748b571 100644
> --- a/arch/arm/mach-socfpga/platsmp.c
> +++ b/arch/arm/mach-socfpga/platsmp.c
> @@ -94,6 +94,7 @@ static void __init socfpga_smp_prepare_cpus(unsigned int max_cpus)
>  	scu_enable(socfpga_scu_base_addr);
>  }
>  
> +#ifdef CONFIG_HOTPLUG_CPU
>  /*
>   * platform-specific code to shutdown a CPU
>   *
> @@ -116,6 +117,7 @@ static int socfpga_cpu_kill(unsigned int cpu)
>  {
>  	return 1;
>  }
> +#endif
>  
>  static const struct smp_operations socfpga_smp_ops __initconst = {
>  	.smp_prepare_cpus	= socfpga_smp_prepare_cpus,
> 

Acked-by: Dinh Nguyen <dinguyen at opensource.altera.com>

Dinh


From rabin at rab.in  Tue Feb 23 07:23:53 2016
From: rabin at rab.in (Rabin Vincent)
Date: Tue, 23 Feb 2016 16:23:53 +0100
Subject: [PATCH 2/2] ARM: dma-mapping: fix alloc/free for coherent + CMA
 + gfp=0
In-Reply-To: <20160219140600.GW19428@n2100.arm.linux.org.uk>
References: <1455869524-13874-1-git-send-email-rabin.vincent@axis.com>
 <1455869524-13874-2-git-send-email-rabin.vincent@axis.com>
 <20160219140600.GW19428@n2100.arm.linux.org.uk>
Message-ID: <20160223152353.GA22447@lnxrabinv.se.axis.com>

On Fri, Feb 19, 2016 at 02:06:00PM +0000, Russell King - ARM Linux wrote:
> On Fri, Feb 19, 2016 at 09:12:04AM +0100, Rabin Vincent wrote:
> > Given a device which uses arm_coherent_dma_ops and on which
> > dev_get_cma_area(dev) returns non-NULL, the following usage of the DMA
> > API with gfp=0 results in a memory leak and memory corruption.
> > 
> >  p = dma_alloc_coherent(dev, sz, &dma, 0);
> >  if (p)
> >  	dma_free_coherent(dev, sz, p, dma);
> > 
> > The memory leak is because the alloc allocates using
> > __alloc_simple_buffer() but the free attempts
> > dma_release_from_contiguous(), which does not do free anything since the
> > page is not in the CMA area.
> 
> I'd really like to see a better solution to this problem: over the course
> of the years, I've seen a number of patches that rearrange the test order
> at allocation time because of some problem or the other.
> 
> What we need is a better way to ensure that we use the correct release
> functionality - having two independent set of tests where the order
> matters is really not very good.

I've sent a v2 of this series which refactors the code so that we no
longer have two independent sets of tests.


From ldewangan at nvidia.com  Tue Feb 23 07:15:29 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Tue, 23 Feb 2016 20:45:29 +0530
Subject: [PATCH 00/61] gpio: Add and use devm_gpiochip_add_data()
In-Reply-To: <56CC1FD4.1080905@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
 <CACRpkdbt+RiWMA74e40MNZVnDM0t0futtFnbyu9sRhv7p93-Tg@mail.gmail.com>
 <56CC1FD4.1080905@nvidia.com>
Message-ID: <56CC7791.2000607@nvidia.com>


Hi Linus,

On Tuesday 23 February 2016 02:31 PM, Laxman Dewangan wrote:
>
> On Monday 22 February 2016 08:14 PM, Linus Walleij wrote:
>> On Mon, Feb 22, 2016 at 3:07 PM, Laxman Dewangan 
>> <ldewangan at nvidia.com> wrote:
>>
>>> Add resource management APIs for gpiochip_add_data() and
>>> gpiochip_remove() and use these APIs from different HW drivers.
>>>
>>> This is based on discussion on patch to use the new APIs.
>>>          gpio: Add devm_ apis for gpio_chip_add and remove
>> Awesome!
>>
>> Do you have a git I can just pull these off so I don't have to apply
>> then all one-by-one?
>
>
> Nop, I do not have the git repo for sharing as of now at this time.
> Trying to learn to how to create.
>


I have made the repo in git hub as
     https://github.com/ldewangan/linux-upstream.git

branch name is devm_gpiochip.
     https://github.com/ldewangan/linux-upstream/tree/devm_gpiochip

I am not sure that it will work or not but I have pushed all changes to 
this repo/branch.
This is on top of your repo
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
          branch gpio-fornext

I collected acked by and also added in patch.



Thanks,
Laxman


From peter at hurleysoftware.com  Tue Feb 23 07:28:23 2016
From: peter at hurleysoftware.com (Peter Hurley)
Date: Tue, 23 Feb 2016 07:28:23 -0800
Subject: [PATCH v4 04/10] serial: mps2-uart: add MPS2 UART driver
In-Reply-To: <1456238068-25079-5-git-send-email-vladimir.murzin@arm.com>
References: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
 <1456238068-25079-5-git-send-email-vladimir.murzin@arm.com>
Message-ID: <56CC7A97.6020801@hurleysoftware.com>

Hi Vladimir,

On 02/23/2016 06:34 AM, Vladimir Murzin wrote:
> This driver adds support to the UART controller found on ARM MPS2
> platform.

Comments below.

> Signed-off-by: Vladimir Murzin <vladimir.murzin at arm.com>
> ---
>  drivers/tty/serial/Kconfig       |   12 +
>  drivers/tty/serial/Makefile      |    1 +
>  drivers/tty/serial/mps2-uart.c   |  586 ++++++++++++++++++++++++++++++++++++++
>  include/uapi/linux/serial_core.h |    3 +
>  4 files changed, 602 insertions(+)
>  create mode 100644 drivers/tty/serial/mps2-uart.c
> 
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 39721ec..3a248be 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1450,6 +1450,18 @@ config SERIAL_EFM32_UART
>  	  This driver support the USART and UART ports on
>  	  Energy Micro's efm32 SoCs.
>  
> +config SERIAL_MPS2_UART_CONSOLE
> +	bool "MPS2 UART console support"
> +	depends on SERIAL_MPS2_UART
> +	select SERIAL_CORE_CONSOLE
> +
> +config SERIAL_MPS2_UART
> +	bool "MPS2 UART port"
> +	depends on ARM || COMPILE_TEST
> +	select SERIAL_CORE
> +	help
> +	  This driver support the UART ports on ARM MPS2.
> +
>  config SERIAL_EFM32_UART_CONSOLE
>  	bool "EFM32 UART/USART console support"
>  	depends on SERIAL_EFM32_UART=y
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index b391c9b..1062503 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -91,6 +91,7 @@ obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)	+= digicolor-usart.o
>  obj-$(CONFIG_SERIAL_MEN_Z135)	+= men_z135_uart.o
>  obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
>  obj-$(CONFIG_SERIAL_STM32)	+= stm32-usart.o
> +obj-$(CONFIG_SERIAL_MPS2_UART)	+= mps2-uart.o
>  
>  # GPIOLIB helpers for modem control lines
>  obj-$(CONFIG_SERIAL_MCTRL_GPIO)	+= serial_mctrl_gpio.o
> diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
> new file mode 100644
> index 0000000..5a4e167
> --- /dev/null
> +++ b/drivers/tty/serial/mps2-uart.c
> @@ -0,0 +1,586 @@
> +/*
> + * Copyright (C) 2015 ARM Limited
> + *
> + * Author: Vladimir Murzin <vladimir.murzin at arm.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.
> + *
> + * TODO: support for SysRq
> + */
> +
> +#define pr_fmt(fmt)	KBUILD_MODNAME ": " fmt
> +
> +#include <linux/bitops.h>
> +#include <linux/clk.h>
> +#include <linux/console.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/serial_core.h>
> +#include <linux/tty_flip.h>
> +#include <linux/types.h>
> +
> +#define SERIAL_NAME	"ttyMPS"
> +#define DRIVER_NAME	"mps2-uart"
> +#define MAKE_NAME(x)	(DRIVER_NAME # x)
> +
> +#define UARTn_DATA				0x00
> +
> +#define UARTn_STATE				0x04
> +#define UARTn_STATE_TX_FULL			BIT(0)
> +#define UARTn_STATE_RX_FULL			BIT(1)
> +#define UARTn_STATE_TX_OVERRUN			BIT(2)
> +#define UARTn_STATE_RX_OVERRUN			BIT(3)
> +
> +#define UARTn_CTRL				0x08
> +#define UARTn_CTRL_TX_ENABLE			BIT(0)
> +#define UARTn_CTRL_RX_ENABLE			BIT(1)
> +#define UARTn_CTRL_TX_INT_ENABLE		BIT(2)
> +#define UARTn_CTRL_RX_INT_ENABLE		BIT(3)
> +#define UARTn_CTRL_TX_OVERRUN_INT_ENABLE	BIT(4)
> +#define UARTn_CTRL_RX_OVERRUN_INT_ENABLE	BIT(5)
> +
> +#define UARTn_INT				0x0c
> +#define UARTn_INT_TX				BIT(0)
> +#define UARTn_INT_RX				BIT(1)
> +#define UARTn_INT_TX_OVERRUN			BIT(2)
> +#define UARTn_INT_RX_OVERRUN			BIT(3)
> +
> +#define UARTn_BAUDDIV				0x10
> +#define UARTn_BAUDDIV_MASK			GENMASK(20, 0)
> +
> +/*
> + * Helpers to make typical enable/disable operations more readable.
> + */
> +#define UARTn_CTRL_TX_GRP 			(UARTn_CTRL_TX_ENABLE		 |\
> +						 UARTn_CTRL_TX_INT_ENABLE	 |\
> +						 UARTn_CTRL_TX_OVERRUN_INT_ENABLE)
> +
> +#define UARTn_CTRL_RX_GRP 			(UARTn_CTRL_RX_ENABLE		 |\
> +						 UARTn_CTRL_RX_INT_ENABLE	 |\
> +						 UARTn_CTRL_RX_OVERRUN_INT_ENABLE)
> +
> +#define MPS2_MAX_PORTS				3
> +
> +struct mps2_uart_port {
> +	struct uart_port port;
> +	struct clk *clk;
> +	unsigned int tx_irq;
> +	unsigned int rx_irq;
> +};
> +
> +static inline struct mps2_uart_port *to_mps2_port(struct uart_port *port)
> +{
> +	return container_of(port, struct mps2_uart_port, port);
> +}
> +
> +static void mps2_uart_write8(struct uart_port *port, u8 val, unsigned off)
> +{
> +	struct mps2_uart_port *mps_port = to_mps2_port(port);
> +
> +	writeb(val, mps_port->port.membase + off);
> +}
> +
> +static u8 mps2_uart_read8(struct uart_port *port, unsigned off)
> +{
> +	struct mps2_uart_port *mps_port = to_mps2_port(port);
> +
> +	return readb(mps_port->port.membase + off);
> +}
> +
> +static void mps2_uart_write32(struct uart_port *port, u32 val, unsigned off)
> +{
> +	struct mps2_uart_port *mps_port = to_mps2_port(port);
> +
> +	writel_relaxed(val, mps_port->port.membase + off);
> +}
> +
> +static unsigned int mps2_uart_tx_empty(struct uart_port *port)
> +{
> +	u8 status = mps2_uart_read8(port, UARTn_STATE);
> +
> +	return (status & UARTn_STATE_TX_FULL) ? 0 : TIOCSER_TEMT;
> +}
> +
> +static void mps2_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
> +{
> +}
> +
> +static unsigned int mps2_uart_get_mctrl(struct uart_port *port)
> +{
> +	return TIOCM_CAR | TIOCM_CTS | TIOCM_DSR;
> +}
> +
> +static void mps2_uart_stop_tx(struct uart_port *port)
> +{
> +	u8 control = mps2_uart_read8(port, UARTn_CTRL);
> +
> +	control &= ~UARTn_CTRL_TX_GRP;
> +
> +	mps2_uart_write8(port, control, UARTn_CTRL);
> +}
> +
> +static void mps2_uart_tx_chars(struct uart_port *port)
> +{
> +	struct circ_buf *xmit = &port->state->xmit;
> +
> +	while (!(mps2_uart_read8(port, UARTn_STATE) & UARTn_STATE_TX_FULL)) {
> +		if (port->x_char) {
> +			mps2_uart_write8(port, port->x_char, UARTn_DATA);
> +			port->x_char = 0;
> +			port->icount.tx++;
> +			continue;
> +		}
> +
> +		if (uart_circ_empty(xmit) || uart_tx_stopped(port))
> +			break;
> +
> +		mps2_uart_write8(port, xmit->buf[xmit->tail], UARTn_DATA);
> +		xmit->tail = (xmit->tail + 1) % UART_XMIT_SIZE;
> +		port->icount.tx++;
> +	}
> +
> +	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
> +		uart_write_wakeup(port);
> +
> +	if (uart_circ_empty(xmit))
> +		mps2_uart_stop_tx(port);
> +}
> +
> +static void mps2_uart_start_tx(struct uart_port *port)
> +{

Your start_tx() method should just enable tx interrupt (if not already
enabled), and not actually perform the transfer synchronously.


> +	u8 control = mps2_uart_read8(port, UARTn_CTRL);
> +
> +	control |= UARTn_CTRL_TX_GRP;
> +
> +	mps2_uart_write8(port, control, UARTn_CTRL);
> +	mps2_uart_tx_chars(port);
> +}
> +
> +static void mps2_uart_stop_rx(struct uart_port *port)
> +{
> +	u8 control = mps2_uart_read8(port, UARTn_CTRL);
> +
> +	control &= ~UARTn_CTRL_RX_GRP;
> +
> +	mps2_uart_write8(port, control, UARTn_CTRL);
> +}
> +
> +static void mps2_uart_break_ctl(struct uart_port *port, int ctl)
> +{
> +}
> +
> +static void mps2_uart_rx_chars(struct uart_port *port)
> +{
> +	struct tty_port *tport = &port->state->port;
> +
> +	while (mps2_uart_read8(port, UARTn_STATE) & UARTn_STATE_RX_FULL) {
> +		u8 rxdata = mps2_uart_read8(port, UARTn_DATA);
> +
> +		port->icount.rx++;
> +		tty_insert_flip_char(&port->state->port, rxdata, TTY_NORMAL);
> +	}
> +
> +	spin_unlock(&port->lock);
> +	tty_flip_buffer_push(tport);
> +	spin_lock(&port->lock);

Not necessary to drop the port lock across push.


> +}
> +
> +static irqreturn_t mps2_uart_rxirq(int irq, void *data)
> +{
> +
> +	struct uart_port *port = data;
> +	u8 irqflag = mps2_uart_read8(port, UARTn_INT);
> +
> +	if (unlikely(!(irqflag & UARTn_INT_RX)))
> +		return IRQ_NONE;
> +
> +	spin_lock(&port->lock);
> +
> +	mps2_uart_write8(port, UARTn_INT_RX, UARTn_INT);
> +	mps2_uart_rx_chars(port);
> +
> +	spin_unlock(&port->lock);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t mps2_uart_txirq(int irq, void *data)
> +{
> +	struct uart_port *port = data;
> +	u8 irqflag = mps2_uart_read8(port, UARTn_INT);
> +
> +	if (unlikely(!(irqflag & UARTn_INT_TX)))
> +		return IRQ_NONE;
> +
> +	mps2_uart_write8(port, UARTn_INT_TX, UARTn_INT);
> +	mps2_uart_tx_chars(port);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t mps2_uart_oerrirq(int irq, void *data)
> +{
> +	irqreturn_t handled = IRQ_NONE;
> +	struct uart_port *port = data;
> +	u8 irqflag = mps2_uart_read8(port, UARTn_INT);
> +
> +	spin_lock(&port->lock);
> +
> +	if (irqflag & UARTn_INT_RX_OVERRUN) {
> +		struct tty_port *tport = &port->state->port;
> +
> +		mps2_uart_write8(port, UARTn_INT_RX_OVERRUN, UARTn_INT);
> +		tty_insert_flip_char(tport, 0, TTY_OVERRUN);
> +		port->icount.overrun++;
> +		handled = IRQ_HANDLED;
> +	}
> +
> +	/*
> +	 * It's never been seen in practice and it never *should* happen since
> +	 * we check if there is enough room in TX buffer before sending data.
> +	 * So we keep this check in case something suspicious has happened.
> +	 */
> +	if (irqflag & UARTn_INT_TX_OVERRUN) {
> +		mps2_uart_write8(port, UARTn_INT_TX_OVERRUN, UARTn_INT);
> +		handled = IRQ_HANDLED;
> +	}
> +
> +	spin_unlock(&port->lock);

No buffer push for the overrun char?

> +
> +	return handled;
> +}
> +
> +static int mps2_uart_startup(struct uart_port *port)
> +{
> +	struct mps2_uart_port *mps_port = to_mps2_port(port);
> +	u8 control = mps2_uart_read8(port, UARTn_CTRL);
> +	int ret;
> +
> +	control &= ~(UARTn_CTRL_RX_GRP | UARTn_CTRL_TX_GRP);
> +
> +	mps2_uart_write8(port, control, UARTn_CTRL);
> +
> +	ret = request_irq(mps_port->rx_irq, mps2_uart_rxirq, 0,
> +			  MAKE_NAME(-rx), mps_port);
> +	if (ret) {
> +		dev_err(port->dev, "failed to register rxirq (%d)\n", ret);
> +		return ret;
> +	}
> +
> +	ret = request_irq(mps_port->tx_irq, mps2_uart_txirq, 0,
> +			  MAKE_NAME(-tx), mps_port);
> +	if (ret) {
> +		dev_err(port->dev, "failed to register txirq (%d)\n", ret);
> +		goto err_free_rxirq;
> +	}
> +
> +	ret = request_irq(port->irq, mps2_uart_oerrirq, IRQF_SHARED,
> +			  MAKE_NAME(-overrun), mps_port);
> +
> +	if (ret) {
> +		dev_err(port->dev, "failed to register oerrirq (%d)\n", ret);
> +		goto err_free_txirq;
> +	}
> +
> +	control |= UARTn_CTRL_RX_GRP | UARTn_CTRL_TX_GRP;
> +
> +	mps2_uart_write8(port, control, UARTn_CTRL);
> +
> +	return 0;
> +
> +err_free_txirq:
> +	free_irq(mps_port->tx_irq, mps_port);
> +err_free_rxirq:
> +	free_irq(mps_port->rx_irq, mps_port);
> +
> +	return ret;
> +}
> +
> +static void mps2_uart_shutdown(struct uart_port *port)
> +{
> +	struct mps2_uart_port *mps_port = to_mps2_port(port);
> +	u8 control = mps2_uart_read8(port, UARTn_CTRL);
> +
> +	control &= ~(UARTn_CTRL_RX_GRP | UARTn_CTRL_TX_GRP);
> +
> +	mps2_uart_write8(port, control, UARTn_CTRL);
> +
> +	free_irq(mps_port->rx_irq, mps_port);
> +	free_irq(mps_port->tx_irq, mps_port);
> +	free_irq(port->irq, mps_port);
> +}
> +
> +static void mps2_uart_set_termios(struct uart_port *port,
> +	struct ktermios *termios, struct ktermios *old)
> +{
> +	unsigned long flags;
> +	unsigned int baud, bauddiv;
> +
> +	termios->c_cflag &= ~(CRTSCTS | CMSPAR);
> +	termios->c_cflag &= ~CSIZE;
> +	termios->c_cflag |= CS8;
> +	termios->c_cflag &= ~PARENB;
> +	termios->c_cflag &= ~CSTOPB;
> +
> +	baud = uart_get_baud_rate(port, termios, old,
> +			DIV_ROUND_CLOSEST(port->uartclk, UARTn_BAUDDIV_MASK),
> +			DIV_ROUND_CLOSEST(port->uartclk, 16));
> +
> +	bauddiv = DIV_ROUND_CLOSEST(port->uartclk, baud);
> +
> +	spin_lock_irqsave(&port->lock, flags);
> +
> +	uart_update_timeout(port, termios->c_cflag, baud);
> +	mps2_uart_write32(port, bauddiv, UARTn_BAUDDIV);

termios structure itself is already protected from concurrent access
by the tty core so the port lock should only be used for
driver structures and the actual hardware i/o.

IOW, the lock can be dropped before encoding new line rate, like so:

> +	spin_unlock_irqrestore(&port->lock, flags);
> +

> +	if (tty_termios_baud_rate(termios))
> +		tty_termios_encode_baud_rate(termios, baud, baud);
> +}


> +
> +static const char *mps2_uart_type(struct uart_port *port)
> +{
> +	return (port->type == PORT_MPS2UART) ? DRIVER_NAME : NULL;
> +}
> +
> +static void mps2_uart_release_port(struct uart_port *port)
> +{
> +}
> +
> +static int mps2_uart_request_port(struct uart_port *port)
> +{
> +	return 0;
> +}
> +
> +static void mps2_uart_config_port(struct uart_port *port, int type)
> +{
> +	if (type & UART_CONFIG_TYPE && !mps2_uart_request_port(port))
> +		port->type = PORT_MPS2UART;
> +}
> +
> +static int mps2_uart_verify_port(struct uart_port *port, struct serial_struct *serinfo)
> +{
> +	return -EINVAL;
> +}
> +
> +static const struct uart_ops mps2_uart_pops = {
> +	.tx_empty = mps2_uart_tx_empty,
> +	.set_mctrl = mps2_uart_set_mctrl,
> +	.get_mctrl = mps2_uart_get_mctrl,
> +	.stop_tx = mps2_uart_stop_tx,
> +	.start_tx = mps2_uart_start_tx,
> +	.stop_rx = mps2_uart_stop_rx,
> +	.break_ctl = mps2_uart_break_ctl,
> +	.startup = mps2_uart_startup,
> +	.shutdown = mps2_uart_shutdown,
> +	.set_termios = mps2_uart_set_termios,
> +	.type = mps2_uart_type,
> +	.release_port = mps2_uart_release_port,
> +	.request_port = mps2_uart_request_port,
> +	.config_port = mps2_uart_config_port,
> +	.verify_port = mps2_uart_verify_port,
> +};
> +
> +static struct mps2_uart_port mps2_uart_ports[MPS2_MAX_PORTS];
> +
> +#ifdef CONFIG_SERIAL_MPS2_UART_CONSOLE
> +static void mps2_uart_console_putchar(struct uart_port *port, int ch)
> +{
> +	while (mps2_uart_read8(port, UARTn_STATE) & UARTn_STATE_TX_FULL)
> +		cpu_relax();
> +
> +	mps2_uart_write8(port, ch, UARTn_DATA);
> +}
> +
> +static void mps2_uart_console_write(struct console *co, const char *s, unsigned int cnt)
> +{
> +	struct uart_port *port = &mps2_uart_ports[co->index].port;
> +
> +	uart_console_write(port, s, cnt, mps2_uart_console_putchar);
> +}
> +
> +static int mps2_uart_console_setup(struct console *co, char *options)
> +{
> +	struct mps2_uart_port *mps_port;
> +	int baud = 9600;
> +	int bits = 8;
> +	int parity = 'n';
> +	int flow = 'n';
> +
> +	if (co->index < 0 || co->index >= MPS2_MAX_PORTS)
> +		return -ENODEV;
> +
> +	mps_port = &mps2_uart_ports[co->index];
> +
> +	if (options)
> +		uart_parse_options(options, &baud, &parity, &bits, &flow);
> +
> +	return uart_set_options(&mps_port->port, co, baud, parity, bits, flow);
> +}
> +
> +static struct uart_driver mps2_uart_driver;
> +
> +static struct console mps2_uart_console = {
> +	.name = SERIAL_NAME,
> +	.device = uart_console_device,
> +	.write = mps2_uart_console_write,
> +	.setup = mps2_uart_console_setup,
> +	.flags = CON_PRINTBUFFER,
> +	.index = -1,
> +	.data = &mps2_uart_driver,
> +};
> +
> +#define MPS2_SERIAL_CONSOLE (&mps2_uart_console)
> +
> +#else
> +#define MPS2_SERIAL_CONSOLE NULL
> +#endif
> +
> +static struct uart_driver mps2_uart_driver = {
> +	.driver_name = DRIVER_NAME,
> +	.dev_name = SERIAL_NAME,
> +	.nr = MPS2_MAX_PORTS,
> +	.cons = MPS2_SERIAL_CONSOLE,
> +};
> +
> +static struct mps2_uart_port *mps2_of_get_port(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	int id;
> +
> +	if (!np)
> +		return NULL;
> +
> +	id = of_alias_get_id(np, "serial");
> +	if (id < 0)
> +		id = 0;
> +
> +	if (WARN_ON(id >= MPS2_MAX_PORTS))
> +		return NULL;
> +
> +	mps2_uart_ports[id].port.line = id;
> +	return &mps2_uart_ports[id];
> +}
> +
> +static int mps2_init_port(struct mps2_uart_port *mps_port,
> +			struct platform_device *pdev)
> +{
> +	struct resource *res;
> +	int ret;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	mps_port->port.membase = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(mps_port->port.membase))
> +		return PTR_ERR(mps_port->port.membase);
> +
> +	mps_port->port.mapbase = res->start;
> +	mps_port->port.mapsize = resource_size(res);
> +
> +	mps_port->rx_irq = platform_get_irq(pdev, 0);
> +	mps_port->tx_irq = platform_get_irq(pdev, 1);
> +	mps_port->port.irq = platform_get_irq(pdev, 2);
> +
> +	mps_port->port.iotype = UPIO_MEM;
> +	mps_port->port.flags = UPF_BOOT_AUTOCONF;
> +	mps_port->port.fifosize = 1;
> +	mps_port->port.ops = &mps2_uart_pops;
> +	mps_port->port.dev = &pdev->dev;
> +
> +	mps_port->clk = devm_clk_get(&pdev->dev, NULL);
> +	if (IS_ERR(mps_port->clk))
> +		return PTR_ERR(mps_port->clk);
> +
> +	ret = clk_prepare_enable(mps_port->clk);
> +	if (ret)
> +		return ret;
> +
> +	mps_port->port.uartclk = clk_get_rate(mps_port->clk);
> +
> +	clk_disable_unprepare(mps_port->clk);
> +
> +	return ret;
> +}
> +
> +static int mps2_serial_probe(struct platform_device *pdev)
> +{
> +	struct mps2_uart_port *mps_port;
> +	int ret;
> +
> +	mps_port = mps2_of_get_port(pdev);
> +	if (!mps_port)
> +		return -ENODEV;
> +
> +	ret = mps2_init_port(mps_port, pdev);
> +	if (ret)
> +		return ret;
> +
> +	ret = uart_add_one_port(&mps2_uart_driver, &mps_port->port);
> +	if (ret)
> +		return ret;
> +
> +	platform_set_drvdata(pdev, mps_port);
> +
> +	return 0;
> +}
> +
> +static int mps2_serial_remove(struct platform_device *pdev)
> +{
> +	struct mps2_uart_port *mps_port = platform_get_drvdata(pdev);
> +
> +	uart_remove_one_port(&mps2_uart_driver, &mps_port->port);
> +
> +	return 0;
> +}
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id mps2_match[] = {
> +	{ .compatible = "arm,mps2-uart", },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, mps2_match);
> +#endif
> +
> +static struct platform_driver mps2_serial_driver = {
> +	.probe = mps2_serial_probe,
> +	.remove = mps2_serial_remove,
> +
> +	.driver = {
> +		.name = DRIVER_NAME,
> +		.of_match_table = of_match_ptr(mps2_match),
> +	},
> +};
> +
> +static int __init mps2_uart_init(void)
> +{
> +	int ret;
> +
> +	ret = uart_register_driver(&mps2_uart_driver);
> +	if (ret)
> +		return ret;
> +
> +	ret = platform_driver_register(&mps2_serial_driver);
> +	if (ret)
> +		uart_unregister_driver(&mps2_uart_driver);
> +
> +	return ret;
> +}
> +module_init(mps2_uart_init);
> +
> +static void __exit mps2_uart_exit(void)
> +{
> +	platform_driver_unregister(&mps2_serial_driver);
> +	uart_unregister_driver(&mps2_uart_driver);
> +}
> +module_exit(mps2_uart_exit);
> +
> +MODULE_AUTHOR("Vladimir Murzin <vladimir.murzin at arm.com>");
> +MODULE_DESCRIPTION("MPS2 UART driver");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:" DRIVER_NAME);
> diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
> index 3e5d757..1fa57bb 100644
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -261,4 +261,7 @@
>  /* STM32 USART */
>  #define PORT_STM32	113
>  
> +/* MPS2 UART */
> +#define PORT_MPS2UART	114
> +
>  #endif /* _UAPILINUX_SERIAL_CORE_H */
> 



From rabin at rab.in  Tue Feb 23 07:30:03 2016
From: rabin at rab.in (Rabin Vincent)
Date: Tue, 23 Feb 2016 16:30:03 +0100
Subject: [PATCH 2/2] ARM: dma-mapping: fix alloc/free for coherent + CMA
 + gfp=0
In-Reply-To: <xa1tio1kzu4j.fsf@mina86.com>
References: <1455869524-13874-1-git-send-email-rabin.vincent@axis.com>
 <1455869524-13874-2-git-send-email-rabin.vincent@axis.com>
 <xa1tio1kzu4j.fsf@mina86.com>
Message-ID: <20160223153003.GB22447@lnxrabinv.se.axis.com>

On Fri, Feb 19, 2016 at 02:50:52PM +0100, Michal Nazarewicz wrote:
> I haven?t looked closely at the code, but why not:
> 
> 	struct cma *cma = 
>         if (!cma_release(dev_get_cma_area(dev), page, size >> PAGE_SHIFT)) {
> 		// ... do whatever other non-CMA free
> 	}

The page tables changes need to be done before we release the area with
cma_release().  With the v2 patchset which I've sent to LAKML we won't
need a new in_cma() function since we'll now record how we allocated the
buffer and use this information in the free routine.


From peter at hurleysoftware.com  Tue Feb 23 07:32:22 2016
From: peter at hurleysoftware.com (Peter Hurley)
Date: Tue, 23 Feb 2016 07:32:22 -0800
Subject: [PATCH v4 05/10] serial: mps2-uart: add support for early console
In-Reply-To: <1456238068-25079-6-git-send-email-vladimir.murzin@arm.com>
References: <1456238068-25079-1-git-send-email-vladimir.murzin@arm.com>
 <1456238068-25079-6-git-send-email-vladimir.murzin@arm.com>
Message-ID: <56CC7B86.5020307@hurleysoftware.com>

On 02/23/2016 06:34 AM, Vladimir Murzin wrote:
> This adds support early console for MPS2 UART which can be enabled via
> earlycon=mps2,0x40004000

Reviewed-by: Peter Hurley <peter at hurleysoftware.com>



From nicolas.ferre at atmel.com  Tue Feb 23 07:33:17 2016
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Tue, 23 Feb 2016 16:33:17 +0100
Subject: [PATCH] tty/serial: at91: fix bad offset for UART timeout register
In-Reply-To: <1456150735-11635-1-git-send-email-ludovic.desroches@atmel.com>
References: <1456150735-11635-1-git-send-email-ludovic.desroches@atmel.com>
Message-ID: <56CC7BBD.4000004@atmel.com>

Le 22/02/2016 15:18, Ludovic Desroches a ?crit :
> With SAMA5D2, the UART has hw timeout but the offset of the register to
> define this value is not the same as the one for USART.
> When using the new UART, the value of this register was 0 so we never
> get timeout irqs. It involves that when using DMA, we were stuck until
> the execution of the dma callback which happens when a buffer is full
> (so after receiving 2048 bytes).
> 
> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>

Yes, sure: it fixes my previous patch "[PATCH v2 2/2] serial: atmel: add
support for new UART version" that Greg had already included in his
tty-testing and tty-next branches. Greg, it could be interesting to
stick this fix with the patch cited above.

Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

Thanks, bye.


> ---
>  drivers/tty/serial/atmel_serial.c | 19 +++++++++++++------
>  include/linux/atmel_serial.h      |  3 ++-
>  2 files changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index b30c93f..4b6f04a 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -159,6 +159,7 @@ struct atmel_uart_port {
>  	u32			rts_high;
>  	u32			rts_low;
>  	bool			ms_irq_enabled;
> +	u32			rtor;	/* address of receiver timeout register if it exists */
>  	bool			has_hw_timer;
>  	struct timer_list	uart_timer;
>  
> @@ -1718,12 +1719,16 @@ static void atmel_get_ip_name(struct uart_port *port)
>  
>  	atmel_port->has_hw_timer = false;
>  
> -	if (name == usart || name == new_uart) {
> -		dev_dbg(port->dev, "Usart or uart with hw timer\n");
> +	if (name == new_uart) {
> +		dev_dbg(port->dev, "Uart with hw timer");
>  		atmel_port->has_hw_timer = true;
> +		atmel_port->rtor = ATMEL_UA_RTOR;
> +	} else if (name == usart) {
> +		dev_dbg(port->dev, "Usart\n");
> +		atmel_port->has_hw_timer = true;
> +		atmel_port->rtor = ATMEL_US_RTOR;
>  	} else if (name == dbgu_uart) {
>  		dev_dbg(port->dev, "Dbgu or uart without hw timer\n");
> -		atmel_port->has_hw_timer = false;
>  	} else {
>  		/* fallback for older SoCs: use version field */
>  		version = atmel_uart_readl(port, ATMEL_US_VERSION);
> @@ -1732,11 +1737,11 @@ static void atmel_get_ip_name(struct uart_port *port)
>  		case 0x10213:
>  			dev_dbg(port->dev, "This version is usart\n");
>  			atmel_port->has_hw_timer = true;
> +			atmel_port->rtor = ATMEL_US_RTOR;
>  			break;
>  		case 0x203:
>  		case 0x10202:
>  			dev_dbg(port->dev, "This version is uart\n");
> -			atmel_port->has_hw_timer = false;
>  			break;
>  		default:
>  			dev_err(port->dev, "Not supported ip name nor version, set to uart\n");
> @@ -1841,7 +1846,8 @@ static int atmel_startup(struct uart_port *port)
>  					jiffies + uart_poll_timeout(port));
>  		/* set USART timeout */
>  		} else {
> -			atmel_uart_writel(port, ATMEL_US_RTOR, PDC_RX_TIMEOUT);
> +			atmel_uart_writel(port, atmel_port->rtor,
> +					  PDC_RX_TIMEOUT);
>  			atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_STTTO);
>  
>  			atmel_uart_writel(port, ATMEL_US_IER,
> @@ -1856,7 +1862,8 @@ static int atmel_startup(struct uart_port *port)
>  					jiffies + uart_poll_timeout(port));
>  		/* set USART timeout */
>  		} else {
> -			atmel_uart_writel(port, ATMEL_US_RTOR, PDC_RX_TIMEOUT);
> +			atmel_uart_writel(port, atmel_port->rtor,
> +					  PDC_RX_TIMEOUT);
>  			atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_STTTO);
>  
>  			atmel_uart_writel(port, ATMEL_US_IER,
> diff --git a/include/linux/atmel_serial.h b/include/linux/atmel_serial.h
> index ee696d7..5a4d664 100644
> --- a/include/linux/atmel_serial.h
> +++ b/include/linux/atmel_serial.h
> @@ -119,7 +119,8 @@
>  #define ATMEL_US_BRGR		0x20	/* Baud Rate Generator Register */
>  #define	ATMEL_US_CD		GENMASK(15, 0)	/* Clock Divider */
>  
> -#define ATMEL_US_RTOR		0x24	/* Receiver Time-out Register */
> +#define ATMEL_US_RTOR		0x24	/* Receiver Time-out Register for USART */
> +#define ATMEL_UA_RTOR		0x28	/* Receiver Time-out Register for UART */
>  #define	ATMEL_US_TO		GENMASK(15, 0)	/* Time-out Value */
>  
>  #define ATMEL_US_TTGR		0x28	/* Transmitter Timeguard Register */
> 


-- 
Nicolas Ferre


From thomas.petazzoni at free-electrons.com  Tue Feb 23 07:56:03 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Tue, 23 Feb 2016 16:56:03 +0100
Subject: [PATCH 2/3] clk: mvebu: add AP806 core clock driver
In-Reply-To: <20160223102550.2e0cba04@free-electrons.com>
References: <1455521698-7905-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1455521698-7905-3-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160222025357.GE15973@rob-hp-laptop>
 <20160222091423.4756a579@free-electrons.com>
 <20160222141617.GA14970@lunn.ch>
 <20160222183203.2278.60153@quark.deferred.io>
 <CAL_Jsq+iiUBcTdnqzFWLJ+5jPvq0rmWgBboab4xyj1dQyDQE+Q@mail.gmail.com>
 <20160223102550.2e0cba04@free-electrons.com>
Message-ID: <20160223165603.74576dca@free-electrons.com>

Rob, Michael, Stephen,

On Tue, 23 Feb 2016 10:25:50 +0100, Thomas Petazzoni wrote:

> > >> Maybe add a big fat warning that the bindings are unstable, and the DT
> > >> blob must be kept in sync with the kernel?
> > >
> > > +1 and feel free to blame the lack of documentation.  No one can expect
> > > bindings to be finalized when the chip topology is not fully understood.
> > 
> > I can understand not understanding the full clock tree. I have "full"
> > documentation of a Marvell chip and don't understand the clock tree
> > fully. But I can't believe you don't have some sense of how many
> > clocks you have to deal with. 10? 100? 1000? What I see is 2 nodes of
> > a single register each for clocks at roughly the same address. That
> > tells me your binding is too fine grained. If you really don't know
> > what is right, then err on the side of a single clock provider node
> > and don't put the clock details in DT.
> 
> I don't quite understand the reasoning behind this conclusion. We know
> for sure that those two registers control only those core and ring
> clocks. Maybe there are other registers controlling other clocks,  that
> we don't know. But for sure, those two registers only give details
> about those core and ring clocks, so I don't see what would be the
> usefulness of merging that into a single DT node.
> 
> We would lose the fact that the relationship between the ring clocks
> and one of the core clock is represented in the DT. Instead of having a
> clear <&coreclk X> or <&ringclk Y> reference, we would have a
> mysterious <&allclk XYZ> reference, which doesn't tell immediately
> whether it's a core clock or ring clock.
> 
> So, while I definitely agree that a syscon is probably in order to
> cover all the system registers, I don't see the point of having a
> single node to cover all the clocks.

So, I had a discussion with Marvell engineers and a closer look at the
matter. It turns out that those two clock registers are in the middle
of an area called DFX (Design for Testability), which contain registers
to fine tune the silicon and detect manufacturing issues. This area of
registers is most likely never going to be publicly documented, and the
fact that those two clock-related registers were placed there was more
an oversight than a real architecture choice.

For this reason, there is in fact no real benefit in mapping the entire
area using a syscon, and having the two DT nodes for the core clocks
and ring clocks, mapping just their own registers is by far the
simplest solution considering the register layout.

We would prefer to keep things as proposed in terms of DT
representation, with the understanding that the submission of the Linux
support for this platform comes very early in the chip development
cycle, and that as such, the DT bindings should be considered unstable.

Thanks a lot,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From tony at atomide.com  Tue Feb 23 08:07:12 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 23 Feb 2016 08:07:12 -0800
Subject: [PATCH 1/3] ARM: omap2: mark unused functions as __maybe_unused
In-Reply-To: <1456235876-4088840-2-git-send-email-arnd@arndb.de>
References: <1456235876-4088840-1-git-send-email-arnd@arndb.de>
 <1456235876-4088840-2-git-send-email-arnd@arndb.de>
Message-ID: <20160223160711.GX13417@atomide.com>

* Arnd Bergmann <arnd at arndb.de> [160223 05:58]:
> The omap_generic_init() and omap_hwmod_init_postsetup() functions are
> used in the initialization for all OMAP2+ SoC types, but in the
> extreme case that those are all disabled, we get a warning about
> unused code:
> 
> arch/arm/mach-omap2/io.c:412:123: error: 'omap_hwmod_init_postsetup' defined but not used [-Werror=unused-function]
> arch/arm/mach-omap2/board-generic.c:30:123: error: 'omap_generic_init' defined but not used [-Werror=unused-function]
> 
> This annotates both as __maybe_unused to shut up that warning.

Looks OK to me:

Acked-by: Tony Lindgren <tony at atomide.com>


From tony at atomide.com  Tue Feb 23 08:10:04 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 23 Feb 2016 08:10:04 -0800
Subject: [PATCH 2/3] ARM: omap1: avoid unused variable warning
In-Reply-To: <1456235876-4088840-3-git-send-email-arnd@arndb.de>
References: <1456235876-4088840-1-git-send-email-arnd@arndb.de>
 <1456235876-4088840-3-git-send-email-arnd@arndb.de>
Message-ID: <20160223161003.GY13417@atomide.com>

* Arnd Bergmann <arnd at arndb.de> [160223 05:58]:
> The osk_mistral_init() contains code that is only compiled when
> CONFIG_PM is set, but it uses a variable that is declared outside
> of the #ifdef:
> 
> arch/arm/mach-omap1/board-osk.c: In function 'osk_mistral_init':
> arch/arm/mach-omap1/board-osk.c:513:7: warning: unused variable 'ret' [-Wunused-variable]
> 
> This puts the variable in the same #ifdef to avoid the warning.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/mach-omap1/board-osk.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
> index 209aecb0df68..fcc5c0650429 100644
> --- a/arch/arm/mach-omap1/board-osk.c
> +++ b/arch/arm/mach-omap1/board-osk.c
> @@ -510,7 +510,9 @@ static void __init osk_mistral_init(void)
>  	 */
>  	omap_cfg_reg(N15_1610_MPUIO2);
>  	if (gpio_request(OMAP_MPUIO(2), "wakeup") == 0) {
> +#ifdef	CONFIG_PM
>  		int ret = 0;
> +#endif
>  		int irq = gpio_to_irq(OMAP_MPUIO(2));
>  
>  		gpio_direction_input(OMAP_MPUIO(2));

Let's just remove the #ifdef CONFIG_PM in osk_mistral_init()
instead. That's for the wake-up button and I'm not aware
of any other use cases for that button.

Regards,

Tony


From tony at atomide.com  Tue Feb 23 08:10:35 2016
From: tony at atomide.com (Tony Lindgren)
Date: Tue, 23 Feb 2016 08:10:35 -0800
Subject: [PATCH 3/3] ARM: omap1/ams-delta: warn about failed regulator
 enable
In-Reply-To: <1456235876-4088840-4-git-send-email-arnd@arndb.de>
References: <1456235876-4088840-1-git-send-email-arnd@arndb.de>
 <1456235876-4088840-4-git-send-email-arnd@arndb.de>
Message-ID: <20160223161034.GZ13417@atomide.com>

* Arnd Bergmann <arnd at arndb.de> [160223 05:58]:
> The modem pm handler in the ams-delta board uses regulator_enable()
> but does not check for a successful return code:
> 
> board-ams-delta.c:521:3: error: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Werror=unused-result]
> 
> It is not easy to propagate that return code to the callers in
> uart_configure_port/uart_suspend_port/uart_resume_port, unless
> we change all UART drivers, and it is unclear what those would
> do with the return code.
> 
> Instead, this patch uses a runtime warning to replace the
> compiletime warning. I have checked that the regulator in question
> is hardcoded to a fixed-voltage GPIO regulator, and that should
> never fail to get enabled if I understand the code right.

Looks OK to me:

Acked-by: Tony Lindgren <tony at atomide.com>


From gnomes at lxorguk.ukuu.org.uk  Tue Feb 23 08:15:19 2016
From: gnomes at lxorguk.ukuu.org.uk (One Thousand Gnomes)
Date: Tue, 23 Feb 2016 16:15:19 +0000
Subject: [PATCH 3/3] ARM: omap1/ams-delta: warn about failed regulator
 enable
In-Reply-To: <20160223161034.GZ13417@atomide.com>
References: <1456235876-4088840-1-git-send-email-arnd@arndb.de>
 <1456235876-4088840-4-git-send-email-arnd@arndb.de>
 <20160223161034.GZ13417@atomide.com>
Message-ID: <20160223161519.32dd296f@lxorguk.ukuu.org.uk>

> > It is not easy to propagate that return code to the callers in
> > uart_configure_port/uart_suspend_port/uart_resume_port, unless
> > we change all UART drivers, and it is unclear what those would
> > do with the return code.
> > 
> > Instead, this patch uses a runtime warning to replace the
> > compiletime warning. I have checked that the regulator in question
> > is hardcoded to a fixed-voltage GPIO regulator, and that should
> > never fail to get enabled if I understand the code right.  
> 
> Looks OK to me:

If it was a concern for a real driver I think I'd perform a hangup on the
port at that moment. That's what happens if for example you hot unplug a
serial port which would be approximately the same as finding out you
can't power it back up.

Alan


From thierry.reding at gmail.com  Tue Feb 23 08:30:47 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 23 Feb 2016 17:30:47 +0100
Subject: [PATCH 46/61] gpio: tegra: Use devm_gpiochip_add_data() for gpio
 registration
In-Reply-To: <1456150130-2668-47-git-send-email-ldewangan@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
 <1456150130-2668-47-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160223163047.GB13755@ulmo.nvidia.com>

On Mon, Feb 22, 2016 at 07:38:35PM +0530, Laxman Dewangan wrote:
> Use devm_gpiochip_add_data() for GPIO registration.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Stephen Warren <swarren at wwwdotorg.org>
> Cc: Thierry Reding <thierry.reding at gmail.com>
> ---
>  drivers/gpio/gpio-tegra.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
> index 9a1a7e2..790bb11 100644
> --- a/drivers/gpio/gpio-tegra.c
> +++ b/drivers/gpio/gpio-tegra.c
> @@ -545,7 +545,7 @@ static int tegra_gpio_probe(struct platform_device *pdev)
>  
>  	tegra_gpio_chip.of_node = pdev->dev.of_node;
>  
> -	ret = gpiochip_add_data(&tegra_gpio_chip, NULL);
> +	ret = devm_gpiochip_add_data(&pdev->dev, &tegra_gpio_chip, NULL);
>  	if (ret < 0) {
>  		irq_domain_remove(irq_domain);
>  		return ret;

It's slightly redundant to do this because the driver probe will never
fail after this point and the driver can't be unloaded, so there's no
way that the GPIO chip would ever be removed.

But in the interest of consistency I have no objections to doing this.
It might also happen that, eventually, we might turn this into a proper
driver, at which point this would come in useful.

Acked-by: Thierry Reding <treding at nvidia.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/6b2ab1fd/attachment.sig>

From srinivas.kandagatla at linaro.org  Tue Feb 23 08:49:13 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 16:49:13 +0000
Subject: [PATCH v3 0/8] arm64: dts: apq8016 dt patches (Set2).
Message-ID: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>

Hi Andy, 

Here are few more dt patches (set2) which enables usb and lpass,
with some fixes. I have tested these patches with few changes
to defconfig on DB410C + a usb phy fix.

Thanks,
srini

Changes since v2:
 - fixed usb and usb-id pinctrl nodes as suggested by Bjorn

Changes since v1:
 - moved usb usb2513 and usb_id nodes out of soc
 as suggested by Stephen Boyd.
 - fixed lpass node name, spotted by Stephen Boyd.
 - added new patch to enable bam dma
 - added a fix from Ivan on led mpp pins.


Ivan T. Ivanov (1):
  arm64: dts: qcom: Fix MPP's function used for LED control

Srinivas Kandagatla (7):
  arm64: dts: qcom: add manual pullup setting to otg.
  arm64: dts: qcom: apq8016-sbc: add usb support
  arm64: dts: qcom: add audio pinctrls
  arm64: dts: qcom: add lpass node
  arm64: dts: qcom: apq8016-sbc: enable lpass on DB410c
  arm64: dts: qcom: fix usb digital voltage levels
  arm64: dts: qcom: apq8016-sbc: enable bam dma node.

 .../arm64/boot/dts/qcom/apq8016-sbc-pmic-pins.dtsi |   2 +-
 arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi |  14 ++
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi          |  42 ++++
 arch/arm64/boot/dts/qcom/msm8916-pins.dtsi         | 216 +++++++++++++++++++++
 arch/arm64/boot/dts/qcom/msm8916.dtsi              |  29 ++-
 5 files changed, 301 insertions(+), 2 deletions(-)

-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 08:49:46 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 16:49:46 +0000
Subject: [PATCH v3 1/8] arm64: dts: qcom: add manual pullup setting to otg.
In-Reply-To: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456246186-18130-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds manual pull up setting for usb otg indicating that the
vbus is vbus is not routed to USB controller/phy therefore enables
pull-up explicitly before starting controller.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index ff7ca44..c1592d4 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -399,6 +399,7 @@
 			qcom,phy-init-sequence = <0x44 0x6B 0x24 0x13>;
 			dr_mode = "peripheral";
 			qcom,otg-control = <2>; // PMIC
+			qcom,manual-pullup;
 
 			clocks = <&gcc GCC_USB_HS_AHB_CLK>,
 				 <&gcc GCC_USB_HS_SYSTEM_CLK>,
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 08:49:56 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 16:49:56 +0000
Subject: [PATCH v3 2/8] arm64: dts: qcom: apq8016-sbc: add usb support
In-Reply-To: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456246196-18173-1-git-send-email-srinivas.kandagatla@linaro.org>

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi | 14 +++++++++
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi          | 34 ++++++++++++++++++++++
 2 files changed, 48 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
index cbeee0b..ee828a8 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
@@ -10,4 +10,18 @@
 			output-low;
 		};
 	};
+
+	usb_id_default: usb-id-default {
+		pinmux {
+			function = "gpio";
+			pins = "gpio121";
+		};
+
+		pinconf {
+			pins = "gpio121";
+			drive-strength = <8>;
+			input-enable;
+			bias-pull-up;
+		};
+	};
 };
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 8102929..15bb485 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -133,6 +133,40 @@
 		sdhci at 07824000 {
 			status = "okay";
 		};
+
+		usb at 78d9000 {
+			extcon = <&usb_id>, <&usb_id>;
+			status = "okay";
+		};
+
+		ehci at 78d9000 {
+			status = "okay";
+		};
+
+		phy at 78d9000 {
+			v1p8-supply = <&pm8916_l7>;
+			v3p3-supply = <&pm8916_l13>;
+			vddcx-supply = <&pm8916_s1>;
+			extcon = <&usb_id>, <&usb_id>;
+			dr_mode = "otg";
+			status = "okay";
+			switch-gpio = <&pm8916_gpios 4 GPIO_ACTIVE_HIGH>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&usb_sw_sel_pm>;
+		};
+	};
+
+	usb2513 {
+		compatible = "smsc,usb3503";
+		reset-gpios = <&pm8916_gpios 3 GPIO_ACTIVE_LOW>;
+		initial-mode = <1>;
+	};
+
+	usb_id: usb-id {
+		compatible = "linux,extcon-usb-gpio";
+		id-gpio = <&msmgpio 121 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_id_default>;
 	};
 };
 
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 08:50:05 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 16:50:05 +0000
Subject: [PATCH v3 3/8] arm64: dts: qcom: add audio pinctrls
In-Reply-To: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456246205-18215-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds pinctrls required for digital and analog audio via lpass.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 216 +++++++++++++++++++++++++++++
 1 file changed, 216 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
index 8d05005..e9ea5ca 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
@@ -504,4 +504,220 @@
 			};
 		};
 	};
+
+	ext-codec-lines {
+		ext_codec_lines_act: lines_on {
+			pinmux {
+				function = "gpio";
+				pins = "gpio67";
+			};
+			pinconf {
+				pins = "gpio67";
+				drive-strength = <8>;
+				bias-disable;
+				output-high;
+			};
+		};
+		ext_codec_lines_sus: lines_off {
+			pinmux {
+				function = "gpio";
+				pins = "gpio67";
+			};
+			pinconf {
+				pins = "gpio67";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	cdc-pdm-lines {
+		cdc_pdm_lines_act: pdm_lines_on {
+			pinmux {
+				function = "cdc_pdm0";
+				pins = "gpio63", "gpio64", "gpio65", "gpio66",
+				       "gpio67", "gpio68";
+			};
+			pinconf {
+				pins = "gpio63", "gpio64", "gpio65", "gpio66",
+				       "gpio67", "gpio68";
+				drive-strength = <8>;
+				bias-pull-none;
+			};
+		};
+		cdc_pdm_lines_sus: pdm_lines_off {
+			pinmux {
+				function = "cdc_pdm0";
+				pins = "gpio63", "gpio64", "gpio65", "gpio66",
+				       "gpio67", "gpio68";
+			};
+			pinconf {
+				pins = "gpio63", "gpio64", "gpio65", "gpio66",
+				       "gpio67", "gpio68";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	ext-pri-tlmm-lines {
+		ext_pri_tlmm_lines_act: ext_pa_on {
+			pinmux {
+				function = "pri_mi2s";
+				pins = "gpio113", "gpio114", "gpio115",
+				       "gpio116";
+			};
+			pinconf {
+				pins = "gpio113", "gpio114", "gpio115",
+				       "gpio116";
+				drive-strength = <8>;
+				bias-pull-none;
+			};
+		};
+
+		ext_pri_tlmm_lines_sus: ext_pa_off {
+			pinmux {
+				function = "pri_mi2s";
+				pins = "gpio113", "gpio114", "gpio115",
+				       "gpio116";
+			};
+			pinconf {
+				pins = "gpio113", "gpio114", "gpio115",
+				       "gpio116";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	ext-pri-ws-line {
+		ext_pri_ws_act: ext_pa_on {
+			pinmux {
+				function = "pri_mi2s_ws";
+				pins = "gpio110";
+			};
+			pinconf {
+				pins = "gpio110";
+				drive-strength = <8>;
+				bias-pull-none;
+			};
+		};
+
+		ext_pri_ws_sus: ext_pa_off {
+			pinmux {
+				function = "pri_mi2s_ws";
+				pins = "gpio110";
+			};
+			pinconf {
+				pins = "gpio110";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	ext-mclk-tlmm-lines {
+		ext_mclk_tlmm_lines_act: mclk_lines_on {
+			pinmux {
+				function = "pri_mi2s";
+				pins = "gpio116";
+			};
+			pinconf {
+				pins = "gpio116";
+				drive-strength = <8>;
+				bias-pull-none;
+			};
+		};
+		ext_mclk_tlmm_lines_sus: mclk_lines_off {
+			pinmux {
+				function = "pri_mi2s";
+				pins = "gpio116";
+			};
+			pinconf {
+				pins = "gpio116";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	/* secondary Mi2S */
+	ext-sec-tlmm-lines {
+		ext_sec_tlmm_lines_act: tlmm_lines_on {
+			pinmux {
+				function = "sec_mi2s";
+				pins = "gpio112", "gpio117", "gpio118",
+				       "gpio119";
+			};
+			pinconf {
+				pins = "gpio112", "gpio117", "gpio118",
+					"gpio119";
+				drive-strength = <8>;
+				bias-pull-none;
+			};
+		};
+		ext_sec_tlmm_lines_sus: tlmm_lines_off {
+			pinmux {
+				function = "sec_mi2s";
+				pins = "gpio112", "gpio117", "gpio118",
+				       "gpio119";
+			};
+			pinconf {
+				pins = "gpio112", "gpio117", "gpio118",
+					"gpio119";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	cdc-dmic-lines {
+		cdc_dmic_lines_act: dmic_lines_on {
+			pinmux_dmic0_clk {
+				function = "dmic0_clk";
+				pins = "gpio0";
+			};
+			pinmux_dmic0_data {
+				function = "dmic0_data";
+				pins = "gpio1";
+			};
+			pinconf {
+				pins = "gpio0", "gpio1";
+				drive-strength = <8>;
+			};
+		};
+		cdc_dmic_lines_sus: dmic_lines_off {
+			pinconf {
+				pins = "gpio0", "gpio1";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
+
+	cross-conn-det {
+		cross_conn_det_act: lines_on {
+			pinmux {
+				function = "gpio";
+				pins = "gpio120";
+			};
+			pinconf {
+				pins = "gpio120";
+				drive-strength = <8>;
+				output-low;
+				bias-pull-down;
+			};
+		};
+		cross_conn_det_sus: lines_off {
+			pinmux {
+				function = "gpio";
+				pins = "gpio120";
+			};
+			pinconf {
+				pins = "gpio120";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+	};
 };
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 08:50:19 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 16:50:19 +0000
Subject: [PATCH v3 4/8] arm64: dts: qcom: add lpass node
In-Reply-To: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456246219-18257-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch adds lpass node to the SOC.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index c1592d4..a6fddce 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -343,6 +343,32 @@
 			status = "disabled";
 		};
 
+		lpass: lpass at 07708000 {
+			status = "disabled";
+			compatible = "qcom,lpass-cpu-apq8016";
+			clocks = <&gcc GCC_ULTAUDIO_AHBFABRIC_IXFABRIC_CLK>,
+				 <&gcc GCC_ULTAUDIO_PCNOC_MPORT_CLK>,
+				 <&gcc GCC_ULTAUDIO_PCNOC_SWAY_CLK>,
+				 <&gcc GCC_ULTAUDIO_LPAIF_PRI_I2S_CLK>,
+				 <&gcc GCC_ULTAUDIO_LPAIF_SEC_I2S_CLK>,
+				 <&gcc GCC_ULTAUDIO_LPAIF_SEC_I2S_CLK>,
+				 <&gcc GCC_ULTAUDIO_LPAIF_AUX_I2S_CLK>;
+
+			clock-names = "ahbix-clk",
+					"pcnoc-mport-clk",
+					"pcnoc-sway-clk",
+					"mi2s-bit-clk0",
+					"mi2s-bit-clk1",
+					"mi2s-bit-clk2",
+					"mi2s-bit-clk3";
+			#sound-dai-cells = <1>;
+
+			interrupts = <0 160 0>;
+			interrupt-names = "lpass-irq-lpaif";
+			reg = <0x07708000 0x10000>;
+			reg-names = "lpass-lpaif";
+		};
+
 		sdhc_1: sdhci at 07824000 {
 			compatible = "qcom,sdhci-msm-v4";
 			reg = <0x07824900 0x11c>, <0x07824000 0x800>;
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 08:50:28 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 16:50:28 +0000
Subject: [PATCH v3 5/8] arm64: dts: qcom: apq8016-sbc: enable lpass on DB410c
In-Reply-To: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456246228-18299-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch enables the lpass on DB410C. LPASS is used as cpu dai for
both analog and digital audio.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 15bb485..27288ee 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -154,6 +154,10 @@
 			pinctrl-names = "default";
 			pinctrl-0 = <&usb_sw_sel_pm>;
 		};
+
+		lpass at 07708000 {
+			status = "okay";
+		};
 	};
 
 	usb2513 {
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 08:50:36 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 16:50:36 +0000
Subject: [PATCH v3 6/8] arm64: dts: qcom: fix usb digital voltage levels
In-Reply-To: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456246236-18341-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch updates the digital voltage levels from corner values to
microvolts as we are going to use s1 regulator directly for vddcx
instead of s1_corner.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index a6fddce..2f40fdd 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -421,7 +421,7 @@
 			interrupts = <GIC_SPI 134 IRQ_TYPE_EDGE_BOTH>,
 				     <GIC_SPI 140 IRQ_TYPE_EDGE_RISING>;
 
-			qcom,vdd-levels = <1 5 7>;
+			qcom,vdd-levels = <500000 1000000 1320000>;
 			qcom,phy-init-sequence = <0x44 0x6B 0x24 0x13>;
 			dr_mode = "peripheral";
 			qcom,otg-control = <2>; // PMIC
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 08:50:45 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 16:50:45 +0000
Subject: [PATCH v3 7/8] arm64: dts: qcom: apq8016-sbc: enable bam dma node.
In-Reply-To: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456246245-18383-1-git-send-email-srinivas.kandagatla@linaro.org>

This patch enables bam dma node, dma is used for both tx and rx on spi
and on high speed serial.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
---
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 27288ee..3f15b19 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -33,6 +33,10 @@
 	};
 
 	soc {
+		dma at 7884000 {
+			status = "okay";
+		};
+
 		serial at 78af000 {
 			label = "LS-UART0";
 			status = "okay";
-- 
1.9.1



From srinivas.kandagatla at linaro.org  Tue Feb 23 08:50:53 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 23 Feb 2016 16:50:53 +0000
Subject: [PATCH v3 8/8] arm64: dts: qcom: Fix MPP's function used for LED
 control
In-Reply-To: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <1456246253-18425-1-git-send-email-srinivas.kandagatla@linaro.org>

From: "Ivan T. Ivanov" <ivan.ivanov at linaro.org>

The qcom-spmi-mpp driver is now using string "digital" to denote
old "normal" functionality. Update DTS file.
Also update the powersource.

Signed-off-by: Ivan T. Ivanov <ivan.ivanov at linaro.org>
---
 arch/arm64/boot/dts/qcom/apq8016-sbc-pmic-pins.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc-pmic-pins.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc-pmic-pins.dtsi
index e03c11d..f881437 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc-pmic-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc-pmic-pins.dtsi
@@ -33,7 +33,7 @@
 	pm8916_mpps_leds: pm8916_mpps_leds {
 		pinconf {
 			pins = "mpp2", "mpp3";
-			function = PMIC_GPIO_FUNC_NORMAL;
+			function = "digital";
 			output-low;
 		};
 	};
-- 
1.9.1



From catalin.marinas at arm.com  Tue Feb 23 09:12:41 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Feb 2016 17:12:41 +0000
Subject: [RFC PATCH 05/10] arm64: mm: avoid __pa translations in
 early_fixmap_init
In-Reply-To: <1456174472-30028-6-git-send-email-ard.biesheuvel@linaro.org>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456174472-30028-6-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160223171241.GE4777@e104818-lin.cambridge.arm.com>

On Mon, Feb 22, 2016 at 09:54:27PM +0100, Ard Biesheuvel wrote:
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -679,7 +679,7 @@ void __init early_fixmap_init(void)
>  
>  	pgd = pgd_offset_k(addr);
>  	if (CONFIG_PGTABLE_LEVELS > 3 &&
> -	    !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa(bm_pud))) {
> +	    !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa_symbol(bm_pud))) {
>  		/*
>  		 * We only end up here if the kernel mapping and the fixmap
>  		 * share the top level pgd entry, which should only happen on

Do I miss any patches? The for-next/core branch has a pgd_none(*pgd)
check here, so this patch does not apply.

-- 
Catalin


From ard.biesheuvel at linaro.org  Tue Feb 23 09:16:50 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 23 Feb 2016 18:16:50 +0100
Subject: [RFC PATCH 05/10] arm64: mm: avoid __pa translations in
 early_fixmap_init
In-Reply-To: <20160223171241.GE4777@e104818-lin.cambridge.arm.com>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456174472-30028-6-git-send-email-ard.biesheuvel@linaro.org>
 <20160223171241.GE4777@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu-3VpzkVi8ygorRvW7E4XHqnV019VF0M1KZTy9Fu3yMBA@mail.gmail.com>

On 23 February 2016 at 18:12, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 22, 2016 at 09:54:27PM +0100, Ard Biesheuvel wrote:
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -679,7 +679,7 @@ void __init early_fixmap_init(void)
>>
>>       pgd = pgd_offset_k(addr);
>>       if (CONFIG_PGTABLE_LEVELS > 3 &&
>> -         !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa(bm_pud))) {
>> +         !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa_symbol(bm_pud))) {
>>               /*
>>                * We only end up here if the kernel mapping and the fixmap
>>                * share the top level pgd entry, which should only happen on
>
> Do I miss any patches? The for-next/core branch has a pgd_none(*pgd)
> check here, so this patch does not apply.
>

This is actually based on the kaslr branch, not for-next/core

I'm happy to rebase and resend. I have added some patches for kasan,
kvm and smp as well.


From dan.j.williams at intel.com  Tue Feb 23 09:21:44 2016
From: dan.j.williams at intel.com (Dan Williams)
Date: Tue, 23 Feb 2016 09:21:44 -0800
Subject: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB
 mappings
In-Reply-To: <CAKv+Gu_iEOC6E+N28pp9eEJxWFYTgLaQcBYEy1SvTUHT=cybYA@mail.gmail.com>
References: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456149728-16706-2-git-send-email-ard.biesheuvel@linaro.org>
 <CAPcyv4ivN9c8PHBR77vd36ovB28OETJUr6VYf_8gNtXgqEmATw@mail.gmail.com>
 <CAKv+Gu9OWVgo+Qm85jPjY7xJ1UELm-4LYORHKF8Yy+_HuzmtGw@mail.gmail.com>
 <20160222200227.GF19428@n2100.arm.linux.org.uk>
 <CAKv+Gu9gwnuu7hnYpjv7ozuKYmC8ApMakSJmYvQMaevNEd5zvA@mail.gmail.com>
 <20160223115835.GI19428@n2100.arm.linux.org.uk>
 <CAKv+Gu8oCnu6kv5SxUAdWE_Z0V+PMAKDgM6MxTi4mTm5z6EFqA@mail.gmail.com>
 <CAKv+Gu_iEOC6E+N28pp9eEJxWFYTgLaQcBYEy1SvTUHT=cybYA@mail.gmail.com>
Message-ID: <CAPcyv4h86uzieFV4HM-tZoWSVZ7GY2GKEUk334J+5sD_GyzWKg@mail.gmail.com>

On Tue, Feb 23, 2016 at 4:26 AM, Ard Biesheuvel
<ard.biesheuvel at linaro.org> wrote:
> On 23 February 2016 at 13:03, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>> On 23 February 2016 at 12:58, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>>> On Mon, Feb 22, 2016 at 09:35:24PM +0100, Ard Biesheuvel wrote:
>>>> OK, thanks for the historical context.
>>>>
>>>> So what is your opinion on this series, i.e., to wire up memremap() to
>>>> remap arbitrary memory regions into the vmalloc area with MT_MEMORY_RW
>>>> attributes, and at the same time lift the restriction that the region
>>>> must be disjoint from memory covered by lowmem or kmap?
>>>
>>> The historical context is still present, because pxa2xx-flash has
>>> been converted to use memremap() from ioremap_cache() - possibly
>>> inappropriately.
>>>
>>> I've already described the semantics of ioremap_cache(), which are
>>> to always create a cacheable mapping irrespective of the system
>>> memory mapping type.  However, memremap() says that MEMREMAP_WB
>>> matches system RAM, which on ARM it doesn't right now.
>>>
>>
>> Indeed. Hence this series, to decouple memremap(MEMREMAP_WB) from
>> ioremap_cache() for ARM
>>
>>> Changing it to MT_MEMORY_RW would satisfy that comment against
>>> memremap(), but at the same time changes what happens with
>>> pxa2xx-flash - the memory region (which is not system RAM) then
>>> changes with the cache status of system RAM.
>>>
>>> So, I'm not that happy about the memremap() stuff right now, and
>>> I don't like the idea of making memremap() conform to its stated
>>> requirements without first preventing pxa2xx-flash being affected
>>> by such a change.
>>>
>>
>> Actually, my change fixes this issue, since it will cause memremap()
>> to always create MT_MEMORY_RW mappings, and not fallback to
>> ioremap_cache() for ranges that are not covered by lowmem.
>>
>>> Perhaps we need to reinstate the original ioremap_cached() API for
>>> pxa2xx-flash, and then switch memremap() to MT_MEMORY_RW - that
>>> would seem to result in the expected behaviour by all parties.
>>>
>>
>> I think we can simply revert the change to pxa2xx-flash if it is
>> deemed inappropriate.
>
> OK, I see what you mean. I find it unfortunate that ioremap_cache()
> instances are blindly being replaced with memremap(), and I wonder if
> this wasted test by and/or cc'ed to people who can actually test this
> driver. Dan?

I included that change in my original "convert ARM to memremap"
patchset [1].  I admit I didn't see the problem initially, but in
hindsight I should have told Brian to hold off until the whole
approach was sanity checked by ARM core maintainers.  Since then I've
been deferring the deprecation of ioremap_cache() until we could have
a conversation like this one.

> Anyway, I don't think it makes sense to stipulate at the generic level
> that ioremap_cache() and memremap(MEMREMAP_WB) shall be the same, and
> deprecating it is a bit premature since the cross-architecturally
> loosely defined semantics of ioremap_cache() can never be replaced 1:1
> with what memremap() promises.

Ok, my goal was to clean all the cases the were mishandling the
__iomem annotation where the *accesses* did not have I/O side effects.
What I overlooked was the difference between varying flavors of
writeback cacheable mappings.

> So what I suggest is that I revert the change to pxa2xx-flash as a new
> 1/3 in this series, and put these existing two on top to decouple
> memremap(MEMREMAP_WB) from ioremap_cache() entirely.

Should we formalize the pxa2xx-flash case with a new MEMREMAP_<type>?
Part of the original confusion is that we have ioremap_cache() with
varying semantics across architectures.

[1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/360888.html


From catalin.marinas at arm.com  Tue Feb 23 09:22:50 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Feb 2016 17:22:50 +0000
Subject: [RFC PATCH 10/10] arm64: mm: restrict __pa() translations to
 linear virtual addresses
In-Reply-To: <CAKv+Gu_zdt-sk_moCeF8u95DCZgcT26CDH1gL87Q4qXKA_hKrg@mail.gmail.com>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456174472-30028-11-git-send-email-ard.biesheuvel@linaro.org>
 <20160223122615.GJ3966@arm.com>
 <CAKv+Gu_zdt-sk_moCeF8u95DCZgcT26CDH1gL87Q4qXKA_hKrg@mail.gmail.com>
Message-ID: <20160223172250.GF4777@e104818-lin.cambridge.arm.com>

On Tue, Feb 23, 2016 at 01:29:21PM +0100, Ard Biesheuvel wrote:
> On 23 February 2016 at 13:26, Will Deacon <will.deacon at arm.com> wrote:
> > On Mon, Feb 22, 2016 at 09:54:32PM +0100, Ard Biesheuvel wrote:
> >> Now that we have replaced all occurrences of __pa() translations
> >> involving virtual addresses that are covered by the kernel text,
> >> we can redefine __virt_to_phys and __pa() etc to only take virtual
> >> address that are covered by the linear mapping. This means we can
> >> remove the comparison with PAGE_OFFSET in the definition of
> >> __virt_to_phys().
> >>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >> ---
> >>  arch/arm64/include/asm/memory.h | 12 +++++++-----
> >>  1 file changed, 7 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> >> index 56d6739430f3..3b5dc5b243ac 100644
> >> --- a/arch/arm64/include/asm/memory.h
> >> +++ b/arch/arm64/include/asm/memory.h
> >> @@ -86,11 +86,14 @@
> >>   * private definitions which should NOT be used outside memory.h
> >>   * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
> >>   */
> >> -#define __virt_to_phys(x) ({                                         \
> >> +#ifndef CONFIG_DEBUG_VM
> >> +#define __virt_to_phys(x)    (((phys_addr_t)(x) & ~PAGE_OFFSET) + PHYS_OFFSET)
> >> +#else
> >> +#define __virt_to_phys(x)    ({                                      \
> >>       phys_addr_t __x = (phys_addr_t)(x);                             \
> >> -     __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET :   \
> >> -                              (__x - kimage_voffset); })
> >> -
> >> +     BUG_ON(__x < PAGE_OFFSET);                                      \
> >> +     (((phys_addr_t)__x & ~PAGE_OFFSET) + PHYS_OFFSET); })
> >
> > What's the #include-hell like if you try to use VM_BUG_ON instead?
> >
> 
> The #include hell would not change I think, since
> 
> include/linux/mmdebug.h:18:#define VM_BUG_ON(cond) BUG_ON(cond)
> 
> but it would certainly make this code look a lot cleaner.

I just tried the fixup below on top of your PHYS_OFFSET patch from
yesterday and it seems to work (I can fold it in once I finish testing
more build configurations):

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index d862c62a33b8..e02bfef18552 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -132,14 +132,11 @@
 
 #ifndef __ASSEMBLY__
 #include <linux/bitops.h>
+#include <linux/mmdebug.h>
 
 extern phys_addr_t		memstart_addr;
 /* PHYS_OFFSET - the physical address of the start of memory. */
-#ifndef CONFIG_DEBUG_VM
-#define PHYS_OFFSET		({ memstart_addr; })
-#else
-#define PHYS_OFFSET		({ BUG_ON(memstart_addr & 1); memstart_addr; })
-#endif
+#define PHYS_OFFSET		({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
 
 /* the offset between the kernel virtual and physical mappings */
 extern u64			kimage_voffset;

-- 
Catalin


From catalin.marinas at arm.com  Tue Feb 23 09:26:26 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Feb 2016 17:26:26 +0000
Subject: [RFC PATCH 05/10] arm64: mm: avoid __pa translations in
 early_fixmap_init
In-Reply-To: <CAKv+Gu-3VpzkVi8ygorRvW7E4XHqnV019VF0M1KZTy9Fu3yMBA@mail.gmail.com>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456174472-30028-6-git-send-email-ard.biesheuvel@linaro.org>
 <20160223171241.GE4777@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-3VpzkVi8ygorRvW7E4XHqnV019VF0M1KZTy9Fu3yMBA@mail.gmail.com>
Message-ID: <20160223172625.GG4777@e104818-lin.cambridge.arm.com>

On Tue, Feb 23, 2016 at 06:16:50PM +0100, Ard Biesheuvel wrote:
> On 23 February 2016 at 18:12, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Mon, Feb 22, 2016 at 09:54:27PM +0100, Ard Biesheuvel wrote:
> >> --- a/arch/arm64/mm/mmu.c
> >> +++ b/arch/arm64/mm/mmu.c
> >> @@ -679,7 +679,7 @@ void __init early_fixmap_init(void)
> >>
> >>       pgd = pgd_offset_k(addr);
> >>       if (CONFIG_PGTABLE_LEVELS > 3 &&
> >> -         !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa(bm_pud))) {
> >> +         !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa_symbol(bm_pud))) {
> >>               /*
> >>                * We only end up here if the kernel mapping and the fixmap
> >>                * share the top level pgd entry, which should only happen on
> >
> > Do I miss any patches? The for-next/core branch has a pgd_none(*pgd)
> > check here, so this patch does not apply.
> >
> 
> This is actually based on the kaslr branch, not for-next/core
> 
> I'm happy to rebase and resend.

That's fine, no need to resend. I plan to move those as well onto
for-next/core but wanted some more testing first on the initial part.

> I have added some patches for kasan, kvm and smp as well.

Patches related to the __pa clean-up? Or something else?

-- 
Catalin


From ard.biesheuvel at linaro.org  Tue Feb 23 09:27:27 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 23 Feb 2016 18:27:27 +0100
Subject: [RFC PATCH 05/10] arm64: mm: avoid __pa translations in
 early_fixmap_init
In-Reply-To: <20160223172625.GG4777@e104818-lin.cambridge.arm.com>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456174472-30028-6-git-send-email-ard.biesheuvel@linaro.org>
 <20160223171241.GE4777@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-3VpzkVi8ygorRvW7E4XHqnV019VF0M1KZTy9Fu3yMBA@mail.gmail.com>
 <20160223172625.GG4777@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu8dORsacisDdw02cznp-6jh9-WnesZXVYLJv7Qg_VpApA@mail.gmail.com>

On 23 February 2016 at 18:26, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Tue, Feb 23, 2016 at 06:16:50PM +0100, Ard Biesheuvel wrote:
>> On 23 February 2016 at 18:12, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > On Mon, Feb 22, 2016 at 09:54:27PM +0100, Ard Biesheuvel wrote:
>> >> --- a/arch/arm64/mm/mmu.c
>> >> +++ b/arch/arm64/mm/mmu.c
>> >> @@ -679,7 +679,7 @@ void __init early_fixmap_init(void)
>> >>
>> >>       pgd = pgd_offset_k(addr);
>> >>       if (CONFIG_PGTABLE_LEVELS > 3 &&
>> >> -         !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa(bm_pud))) {
>> >> +         !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa_symbol(bm_pud))) {
>> >>               /*
>> >>                * We only end up here if the kernel mapping and the fixmap
>> >>                * share the top level pgd entry, which should only happen on
>> >
>> > Do I miss any patches? The for-next/core branch has a pgd_none(*pgd)
>> > check here, so this patch does not apply.
>> >
>>
>> This is actually based on the kaslr branch, not for-next/core
>>
>> I'm happy to rebase and resend.
>
> That's fine, no need to resend. I plan to move those as well onto
> for-next/core but wanted some more testing first on the initial part.
>
>> I have added some patches for kasan, kvm and smp as well.
>
> Patches related to the __pa clean-up? Or something else?
>

No, related to the __pa restriction


From shankerd at codeaurora.org  Tue Feb 23 09:30:51 2016
From: shankerd at codeaurora.org (Shanker Donthineni)
Date: Tue, 23 Feb 2016 11:30:51 -0600
Subject: [PATCH] irqchip/gicv3-its: Don't allow devices whose ID is
 outside range
In-Reply-To: <1456199868-9054-1-git-send-email-shankerd@codeaurora.org>
References: <1456199868-9054-1-git-send-email-shankerd@codeaurora.org>
Message-ID: <56CC974B.8080907@codeaurora.org>

Hi Marc,


On 02/22/2016 09:57 PM, Shanker Donthineni wrote:
> We are not checking whether the requested device identifier fits into
> table or not. The ITS MAPD command fails if 'Device ID' is outside of
> device table range.
>
> Add a simple validation check to avoid MAPD failures since we are
> not handling ITS command errors. This change also helps to return an
> error -ENOMEM instead of success to caller.
>
> Signed-off-by: Shanker Donthineni <shankerd at codeaurora.org>
> ---
> This patch depends on https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/gic-4.5-fixes&id=2eca0d6ceea1f108b2d3ac81fb34698c4fd41006
>
>   drivers/irqchip/irq-gic-v3-its.c | 18 +++++++++++++++---
>   1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index c0f227a..9bdcdf5 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -70,6 +70,7 @@ struct its_node {
>   	struct {
>   		void		*base;
>   		u32		order;
> +		u32		entry_size;
>   	} tables[GITS_BASER_NR_REGS];
>   	struct its_collection	*collections;
>   	struct list_head	its_device_list;
> @@ -880,6 +881,7 @@ static int its_alloc_tables(const char *node_name, struct its_node *its)
>   					node_name, order);
>   			}
>   		}
> +		its->tables[type].entry_size = entry_size;
>   
>   retry_alloc_baser:
>   		alloc_pages = (PAGE_ORDER_TO_SIZE(order) / psz);
> @@ -896,8 +898,8 @@ retry_alloc_baser:
>   			goto out_free;
>   		}
>   
> -		its->tables[i].base = base;
> -		its->tables[i].order = order;
> +		its->tables[type].base = base;
> +		its->tables[type].order = order;
>   
>   retry_baser:
>   		val = (virt_to_phys(base) 				 |
> @@ -947,7 +949,7 @@ retry_baser:
>   			 * something is horribly wrong...
>   			 */
>   			free_pages((unsigned long)base, order);
> -			its->tables[i].base = NULL;
> +			its->tables[type].base = NULL;
>   
>   			switch (psz) {
>   			case SZ_16K:
> @@ -1152,12 +1154,22 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id,
>   	unsigned long *lpi_map;
>   	unsigned long flags;
>   	u16 *col_map = NULL;
> +	u8 type = GITS_BASER_TYPE_DEVICE;
> +	u32 entry_size;
> +	u32 order;
>   	void *itt;
>   	int lpi_base;
>   	int nr_lpis;
>   	int nr_ites;
>   	int sz;
>   
> +	entry_size = its->tables[type].entry_size;
> +	order = its->tables[type].order;
> +
> +	/* Don't allow 'dev_id' that exceeds single, flat table limit */
> +	if (dev_id >= (PAGE_ORDER_TO_SIZE(order) / entry_size))
> +		return NULL;
> +
>   	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
>   	/*
>   	 * At least one bit of EventID is being used, hence a minimum
ITS probe function tries to allocate maximum memory as much as possible 
to cover whole DevID.
sparse which is reported (ITS_TYPER.Devbits) by HW. We might not be able 
to allocate enough
memory for device table.  We reduce memory allocation size for two 
reasons either because of
crossing MAX_ORDER limit or max ITS_BASERn size.

1) According to ARM-GIC spec, we can assign maximum memory size 256 
(ITS-Size) *
    64K (ITS-PageSzie) Bytes to level-one (flat) device table.

     DevID = flat_table_size / device_table_entry_size = 16 MBytes / 8  
= 21bits (max)

2) Maximum 4Mbytes memory is possible on kernel using PAGE_SIZE=4K with 
default
     arch/arm64/defconfig (MAX_ORDER = 12).

     DevID = flat_table_size / device_table_entry_size = 4 MBytes / 8  = 
19bits (max)

Assuming: minimum device table entry size 8 Bytes.

I think it is a generic problem and this fail scenario happens if DevID 
range is more than 21bits or
failed to allocate required memory size for device table.

Our ITS hardware is capable of supporting 32bit DevID space, so it 
advertises ITS_TYPER.Devbits
field with value 31 causing this problem. I think we need some 
protection in its_create_device() to
avoid this scenario.

I am planning to post an another patch to add support for 
ITS-Indirection (two-level) table walk feature.

-- 
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project



From catalin.marinas at arm.com  Tue Feb 23 09:32:54 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Feb 2016 17:32:54 +0000
Subject: [RFC PATCH 05/10] arm64: mm: avoid __pa translations in
 early_fixmap_init
In-Reply-To: <CAKv+Gu8dORsacisDdw02cznp-6jh9-WnesZXVYLJv7Qg_VpApA@mail.gmail.com>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456174472-30028-6-git-send-email-ard.biesheuvel@linaro.org>
 <20160223171241.GE4777@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-3VpzkVi8ygorRvW7E4XHqnV019VF0M1KZTy9Fu3yMBA@mail.gmail.com>
 <20160223172625.GG4777@e104818-lin.cambridge.arm.com>
 <CAKv+Gu8dORsacisDdw02cznp-6jh9-WnesZXVYLJv7Qg_VpApA@mail.gmail.com>
Message-ID: <20160223173253.GH4777@e104818-lin.cambridge.arm.com>

On Tue, Feb 23, 2016 at 06:27:27PM +0100, Ard Biesheuvel wrote:
> On 23 February 2016 at 18:26, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Tue, Feb 23, 2016 at 06:16:50PM +0100, Ard Biesheuvel wrote:
> >> On 23 February 2016 at 18:12, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> > On Mon, Feb 22, 2016 at 09:54:27PM +0100, Ard Biesheuvel wrote:
> >> >> --- a/arch/arm64/mm/mmu.c
> >> >> +++ b/arch/arm64/mm/mmu.c
> >> >> @@ -679,7 +679,7 @@ void __init early_fixmap_init(void)
> >> >>
> >> >>       pgd = pgd_offset_k(addr);
> >> >>       if (CONFIG_PGTABLE_LEVELS > 3 &&
> >> >> -         !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa(bm_pud))) {
> >> >> +         !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa_symbol(bm_pud))) {
> >> >>               /*
> >> >>                * We only end up here if the kernel mapping and the fixmap
> >> >>                * share the top level pgd entry, which should only happen on
> >> >
> >> > Do I miss any patches? The for-next/core branch has a pgd_none(*pgd)
> >> > check here, so this patch does not apply.
> >> >
> >>
> >> This is actually based on the kaslr branch, not for-next/core
> >>
> >> I'm happy to rebase and resend.
> >
> > That's fine, no need to resend. I plan to move those as well onto
> > for-next/core but wanted some more testing first on the initial part.
> >
> >> I have added some patches for kasan, kvm and smp as well.
> >
> > Patches related to the __pa clean-up? Or something else?
> 
> No, related to the __pa restriction

OK. I'll wait for a while before merging this series to get more reviews
and testing. I picked the first patch though (high_memory fix).

-- 
Catalin


From ddaney at caviumnetworks.com  Tue Feb 23 09:34:24 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Tue, 23 Feb 2016 09:34:24 -0800
Subject: [PATCH v12 4/5] arm64, numa: Add NUMA support for arm64 platforms.
In-Reply-To: <20160223102610.GD3966@arm.com>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
 <1456192703-2274-5-git-send-email-ddaney.cavm@gmail.com>
 <20160223102610.GD3966@arm.com>
Message-ID: <56CC9820.3010406@caviumnetworks.com>

On 02/23/2016 02:26 AM, Will Deacon wrote:
> On Mon, Feb 22, 2016 at 05:58:22PM -0800, David Daney wrote:
>> From: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
>>
>> Attempt to get the memory and CPU NUMA node via of_numa.  If that
>> fails, default the dummy NUMA node and map all memory and CPUs to node
>> 0.
>>
>> Tested-by: Shannon Zhao <shannon.zhao at linaro.org>
>> Reviewed-by: Robert Richter <rrichter at cavium.com>
>> Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
>> Signed-off-by: David Daney <david.daney at cavium.com>
>> ---
>>   arch/arm64/Kconfig                |  26 +++
>>   arch/arm64/include/asm/mmzone.h   |  12 ++
>>   arch/arm64/include/asm/numa.h     |  45 +++++
>>   arch/arm64/include/asm/topology.h |  10 +
>>   arch/arm64/kernel/pci.c           |  10 +
>>   arch/arm64/kernel/setup.c         |   4 +
>>   arch/arm64/kernel/smp.c           |   4 +
>>   arch/arm64/mm/Makefile            |   1 +
>>   arch/arm64/mm/init.c              |  34 +++-
>>   arch/arm64/mm/mmu.c               |   1 +
>>   arch/arm64/mm/numa.c              | 403 ++++++++++++++++++++++++++++++++++++++
>>   11 files changed, 545 insertions(+), 5 deletions(-)
>>   create mode 100644 arch/arm64/include/asm/mmzone.h
>>   create mode 100644 arch/arm64/include/asm/numa.h
>>   create mode 100644 arch/arm64/mm/numa.c
>
> [...]
>
>> diff --git a/arch/arm64/include/asm/mmzone.h b/arch/arm64/include/asm/mmzone.h
>> new file mode 100644
>> index 0000000..a0de9e6
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/mmzone.h
>> @@ -0,0 +1,12 @@
>> +#ifndef __ASM_MMZONE_H
>> +#define __ASM_MMZONE_H
>> +
>> +#ifdef CONFIG_NUMA
>> +
>> +#include <asm/numa.h>
>> +
>> +extern struct pglist_data *node_data[];
>> +#define NODE_DATA(nid)		(node_data[(nid)])
>> +
>> +#endif /* CONFIG_NUMA */
>> +#endif /* __ASM_MMZONE_H */
>
> What happened to the patch cleaning this up in generic code?

As per 0/5 :

    v11:
	- Dropped cleanup patches for other architectures, they will be
           submitted as a separate set after more testing.

The "cleanup patches" were not building on x86, which is a bit of a
problem.  I believe I have corrected that issue, but would like to do
a little more build testing on all the other architectures that are
effected.

I probably should have supplied more detail as to my plan of attack
for these.  To make review more manageable, I would like to consider
the arm64 patches separately.  The parties interested in getting arm64
NUMA working can proceed without waiting for the cleanups to be fully
tested and acknowledged.  I am working on testing the cleanups on each
architecture touched, and will resubmit them as a separate patch set
this week.  I think splitting them like this will streamline the
process of getting to the eventual goal of having both arm64 NUMA and
the cleanups merged.

David.


From dianders at google.com  Tue Feb 23 09:35:48 2016
From: dianders at google.com (Doug Anderson)
Date: Tue, 23 Feb 2016 09:35:48 -0800
Subject: [PATCH v3 00/12] pwm: add support for atomic update
In-Reply-To: <20160223143859.GA27656@ulmo>
References: <1442828009-6241-1-git-send-email-boris.brezillon@free-electrons.com>
 <2341981.a79ioYM9Es@diego> <20151110173416.GB21727@ulmo>
 <CAD=FV=WL3jYEgVe-m6QcAyQwfJgdX4J5OtKisKwyoKOrTSpEQA@mail.gmail.com>
 <20160125170855.GA10182@ulmo>
 <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
 <20160203145337.GD9650@ulmo>
 <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
 <20160222175929.GA23899@ulmo>
 <CAD=FV=UCErW3EjYRtwt49_ztNR7cyY4U0o4R_dxdomer-Ac2Dg@mail.gmail.com>
 <20160223143859.GA27656@ulmo>
Message-ID: <CAD=FV=UvxG3MYD4MKQJqN7W68uMjd-s+FH-e8tkrLCpS0RLmZQ@mail.gmail.com>

Thierry,

On Tue, Feb 23, 2016 at 6:38 AM, Thierry Reding
<thierry.reding at gmail.com> wrote:
>> > Furthermore it's out of the question that changes to the API will be
>> > required. That's precisely the reason why the atomic PWM proposal came
>> > about. It's an attempt to solve the shortcomings of the current API for
>> > cases such as Rockchip.
>>
>> I _think_ we're on the same page here.  If there are shortcomings with
>> the current API that make it impossible to implement a feature, we've
>> got to change and/or add to the existing API.  ...but we don't want to
>> break existing users / drivers.
>>
>> Note that historically I remember that Linus Torvalds has stated that
>> there is no stable API within the Linux kernel and that forcing the
>> in-kernel API to never change was bad for software development.  I
>> tracked down my memory and found
>> <http://lwn.net/1999/0211/a/lt-binary.html>.  Linus is rabid about not
>> breaking userspace, but in general there's no strong requirement to
>> never change the driver API inside the kernel.  That being said,
>> changing the driver API causes a lot of churn, so presumably changing
>> it in a backward compatible way (like adding to the API instead of
>> changing it) will make things happier.
>
> I didn't say anything about stable API. All I said is that new API
> should be well-thought-out. Those are two very different things.

I guess I just misunderstood "it's out of the question that changes to
the API will be required".  In any case, I think everyone's on the
same page here, so no need to debate further.  :)


>> >> So all we need is a new API call that lets you read the hardware
>> >> values and make sure that the PWM regulator calls that before anyone
>> >> calls pwm_config().  That's roughly B) above.
>> >
>> > Yes. I'm thinking that we should have a pwm_get_state() which retrieves
>> > the current state of the PWM. For drivers that support hardware readout
>> > this state should match the hardware state. For other drivers it should
>> > reflect whatever was specified in DT; essentially what pwm_get_period()
>> > and friends return today.
>>
>> Excellent, so pwm_get_period() gets the period as specified in the
>> device tree (or other board config) and pwm_get_state() returns the
>> hardware state.  SGTM.
>
> That's not quite what I was thinking. If hardware readout is supported
> then whatever we report back should be the current hardware state unless
> we're explicitly asked for something else. If we start mixing the state
> and legacy APIs this way, we'll get into a situation where drivers that
> support hardware readout behave differently than drivers that don't.
>
> For example: A PWM device that's controlled by a driver that supports
> hardware readout has a current period of 50000 ns and the firmware set
> the period to 25000 ns. pwm_get_period() for this PWM device will return
> 50000 ns. If you reconfigure the PWM to generate a PWM signal with a
> period of 30000 ns, pwm_get_period() would still return 50000 ns.
>
> A driver that doesn't support hardware readout, on the contrary, would
> return 50000 ns from pwm_get_period() on the first call, but after you
> have reconfigured it using pwm_config() it will return the new period.

Ah, right!  I forgot that the existing API will be updated if you've
reconfigured the period via pwm_config().  Ugh, you're right that's a
little ugly then.

So do we define it as:

pwm_get_state(): always get the hardware state w/ no caching (maybe
even pwm_get_raw_state() or pwm_get_hw_state())

pwm_get_period(): get the period of the PWM; if the PWM has not yet
been configured by software this gets the default period (possibly
specified by the device tree).


Is that OK?  That is well defined and doesn't change the existing
behavior of pwm_get_period().


>> > That way if you want to get the current voltage in the regulator-pwm
>> > driver you'd simply do a pwm_get_state() and compute the voltage from
>> > the period and duty cycle. If the PWM driver that you happen to use
>> > doesn't support hardware readout, you'll get an initial output voltage
>> > of 0, which is as good as any, really.
>>
>> Sounds fine to me.  PWM regulator is in charge of calling
>> pwm_get_state(), which can return 0 (or an error?) if driver (or
>> underlying hardware) doesn't support hardware readout.  PWM regulator
>> is in charge of using the resulting period / duty cycle to calculate a
>> percentage.
>
> I'm not sure if pwm_get_state() should ever return an error. For drivers
> that support hardware readout, the resulting state should match what's
> programmed to the hardware.
>
> But for drivers without hardware readout support pwm_get_state() still
> makes sense because after a pwm_apply_state() the internal logical state
> would again match hardware.

I guess it depends on how you define things.  With my above
definitions it seems clearest if pwm_get_state() returns an error if
hardware readout is not supported.  If we call it pwm_get_hw_state()
it's even clearer that it should return an error.


> The simplest way to get rid of this would be to change the core to apply
> an initial configuration on probe. However that's probably going to
> break your use-case again (it would set a 0 duty cycle because it isn't
> configured in DT).

Right, so we can't do that.


> To allow your use-case to work we'd need to deal with two states: the
> current hardware state and the "initial" state as defined by DT.
> Unfortunately the PWM specifier in DT is not a full definition, it is
> more like a partial initial configuration. The problem with that, and
> I think that's what Mark was originally objecting to, is that it isn't
> clear when to use the "initial" state and when to use the read hardware
> state. After the first pwm_apply_state() you wouldn't ever have to use
> the "initial" state again, because it's the same as the current state
> (modulo the duty cycle).
>
> Also for drivers such as clk-pwm the usefulness of the "initial" state
> is reduced even more, because it doesn't even need the period specified
> in DT. It uses only the flags (if at all).
>
> Perhaps to avoid this confusion a new type of object, e.g. pwm_args,
> could be introduced to hold configuration arguments given in the PWM
> specifier (in DT) or the PWM lookup table (in board files).
>
> It would then be the responsibility of the users to deal with that
> information in a sensible way. In (almost?) all cases I would expect
> that to be to program the PWM device in the user's ->probe(). In the
> case of regulator-pwm I'd expect that ->probe() would do something
> along these lines (error handling excluded):
>
>         struct pwm_state state;
>         struct pwm_args args;
>         unsigned int ratio;
>
>         pwm = pwm_get(...);
>
>         pwm_get_state(pwm, &state);
>         pwm_get_args(pwm, &args);
>
>         ratio = (state.duty_cycle * 100) / state.period;
>
>         state.duty_cycle = (ratio * args.period) / 100;
>         state.period = args.period;
>         state.flags = args.flags;
>
>         pwm_apply_state(pwm, &state);
>
> The ->set_voltage() implementation would then never need to care about
> the PWM args, but rather do something like this:
>
>         struct pwm_state state;
>         unsigned int ratio;
>
>         pwm_get_state(pwm, &state);
>
>         state.duty_cycle = (ratio * state.period) / 100;
>
>         pwm_apply_state(pwm, &state);
>
> Does that sound about right?

That should work with one minor problem.  If HW readout isn't
supported then pwm_get_state() in probe will presumably return 0 for
the duty cycle.  That means it will change the voltage.  That's in
contrast to how I think things work today where the voltage isn't
changed until the first set_voltage() call.  At least the last time I
tested things get_voltage() would simply report an incorrect value
until the first set_voltage().  I think existing behavior (reporting
the wrong value) is better than new behavior (change the value at
probe).

I'm curious, though.  In your proposal, how does pwm_get_period()
behave?  To be backward compatible, I'd imagine that even in your
proposal we'd have the same definition as I had above:

pwm_get_period(): get the period of the PWM; if the PWM has not yet
been configured by software this gets the default period (possibly
specified by the device tree).


If you have a different definition of pwm_get_period() in your
proposal, please let me know!  If my definition matches your thoughts
then I think we can actually just not touch the "set_voltage" call.
It can always use pwm_get_period() and always use pwm_config() just
like today.

...and if set_voltage() remains untouched then we can solve my probe
problem by renaming pwm_get_state() to pwm_get_hw_state() and having
it return an error if HW readout is not supported.  Then we only call
pwm_get_args() / pwm_apply_state() when we support HW readout.


Thus, if HW readout:

* In probe, we read HW state (pwm_get_hw_state) and atomically adjust
(pwm_apply_state) based on arguments (pwm_get_args).

* In set_voltage we use pwm_get_period which will return the period we
applied in pwm_apply_state() and use pwm_config() to change the duty
cycle.


If no HW readout, no behavior change at all from today:

* In probe we don't do anything to change the PWM

* Upon the first set_voltage we use pwm_get_period() to get the period
as specified in DT and use pwm_config() to change the duty cycle.


That seems pretty sane to me.  What do you think?

-Doug


From ddaney at caviumnetworks.com  Tue Feb 23 09:39:36 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Tue, 23 Feb 2016 09:39:36 -0800
Subject: [PATCH v12 4/5] arm64, numa: Add NUMA support for arm64 platforms.
In-Reply-To: <1456192703-2274-5-git-send-email-ddaney.cavm@gmail.com>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
 <1456192703-2274-5-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <56CC9958.50309@caviumnetworks.com>

+ Bjorn Helgaas

Bjorn,

I Inadvertently omitted you from the list of recipients.  There is an 
arm64 PCI bit in here that may be of interest...

On 02/22/2016 05:58 PM, David Daney wrote:
> From: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
>
> Attempt to get the memory and CPU NUMA node via of_numa.  If that
> fails, default the dummy NUMA node and map all memory and CPUs to node
> 0.
>
> Tested-by: Shannon Zhao <shannon.zhao at linaro.org>
> Reviewed-by: Robert Richter <rrichter at cavium.com>
> Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
> Signed-off-by: David Daney <david.daney at cavium.com>
> ---
>   arch/arm64/Kconfig                |  26 +++
>   arch/arm64/include/asm/mmzone.h   |  12 ++
>   arch/arm64/include/asm/numa.h     |  45 +++++
>   arch/arm64/include/asm/topology.h |  10 +
>   arch/arm64/kernel/pci.c           |  10 +
>   arch/arm64/kernel/setup.c         |   4 +
>   arch/arm64/kernel/smp.c           |   4 +
>   arch/arm64/mm/Makefile            |   1 +
>   arch/arm64/mm/init.c              |  34 +++-
>   arch/arm64/mm/mmu.c               |   1 +
>   arch/arm64/mm/numa.c              | 403 ++++++++++++++++++++++++++++++++++++++
>   11 files changed, 545 insertions(+), 5 deletions(-)
>   create mode 100644 arch/arm64/include/asm/mmzone.h
>   create mode 100644 arch/arm64/include/asm/numa.h
>   create mode 100644 arch/arm64/mm/numa.c
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index a969970..9f0972a 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -74,6 +74,7 @@ config ARM64
>   	select HAVE_HW_BREAKPOINT if PERF_EVENTS
>   	select HAVE_IRQ_TIME_ACCOUNTING
>   	select HAVE_MEMBLOCK
> +	select HAVE_MEMBLOCK_NODE_MAP if NUMA
>   	select HAVE_PATA_PLATFORM
>   	select HAVE_PERF_EVENTS
>   	select HAVE_PERF_REGS
> @@ -96,6 +97,7 @@ config ARM64
>   	select SYSCTL_EXCEPTION_TRACE
>   	select HAVE_CONTEXT_TRACKING
>   	select HAVE_ARM_SMCCC
> +	select OF_NUMA if NUMA && OF
>   	help
>   	  ARM 64-bit (AArch64) Linux support.
>
> @@ -545,6 +547,30 @@ config HOTPLUG_CPU
>   	  Say Y here to experiment with turning CPUs off and on.  CPUs
>   	  can be controlled through /sys/devices/system/cpu.
>
> +# Common NUMA Features
> +config NUMA
> +	bool "Numa Memory Allocation and Scheduler Support"
> +	depends on SMP
> +	help
> +	  Enable NUMA (Non Uniform Memory Access) support.
> +
> +	  The kernel will try to allocate memory used by a CPU on the
> +	  local memory of the CPU and add some more
> +	  NUMA awareness to the kernel.
> +
> +config NODES_SHIFT
> +	int "Maximum NUMA Nodes (as a power of 2)"
> +	range 1 10
> +	default "2"
> +	depends on NEED_MULTIPLE_NODES
> +	help
> +	  Specify the maximum number of NUMA Nodes available on the target
> +	  system.  Increases memory reserved to accommodate various tables.
> +
> +config USE_PERCPU_NUMA_NODE_ID
> +	def_bool y
> +	depends on NUMA
> +
>   source kernel/Kconfig.preempt
>   source kernel/Kconfig.hz
>
> diff --git a/arch/arm64/include/asm/mmzone.h b/arch/arm64/include/asm/mmzone.h
> new file mode 100644
> index 0000000..a0de9e6
> --- /dev/null
> +++ b/arch/arm64/include/asm/mmzone.h
> @@ -0,0 +1,12 @@
> +#ifndef __ASM_MMZONE_H
> +#define __ASM_MMZONE_H
> +
> +#ifdef CONFIG_NUMA
> +
> +#include <asm/numa.h>
> +
> +extern struct pglist_data *node_data[];
> +#define NODE_DATA(nid)		(node_data[(nid)])
> +
> +#endif /* CONFIG_NUMA */
> +#endif /* __ASM_MMZONE_H */
> diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
> new file mode 100644
> index 0000000..e9b4f29
> --- /dev/null
> +++ b/arch/arm64/include/asm/numa.h
> @@ -0,0 +1,45 @@
> +#ifndef __ASM_NUMA_H
> +#define __ASM_NUMA_H
> +
> +#include <asm/topology.h>
> +
> +#ifdef CONFIG_NUMA
> +
> +/* currently, arm64 implements flat NUMA topology */
> +#define parent_node(node)	(node)
> +
> +int __node_distance(int from, int to);
> +#define node_distance(a, b) __node_distance(a, b)
> +
> +extern nodemask_t numa_nodes_parsed __initdata;
> +
> +/* Mappings between node number and cpus on that node. */
> +extern cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
> +void numa_clear_node(unsigned int cpu);
> +
> +#ifdef CONFIG_DEBUG_PER_CPU_MAPS
> +const struct cpumask *cpumask_of_node(int node);
> +#else
> +/* Returns a pointer to the cpumask of CPUs on Node 'node'. */
> +static inline const struct cpumask *cpumask_of_node(int node)
> +{
> +	return node_to_cpumask_map[node];
> +}
> +#endif
> +
> +void __init arm64_numa_init(void);
> +int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> +void __init numa_set_distance(int from, int to, int distance);
> +void __init numa_free_distance(void);
> +void __init early_map_cpu_to_node(unsigned int cpu, int nid);
> +void numa_store_cpu_info(unsigned int cpu);
> +
> +#else	/* CONFIG_NUMA */
> +
> +static inline void numa_store_cpu_info(unsigned int cpu) { }
> +static inline void arm64_numa_init(void) { }
> +static inline void early_map_cpu_to_node(unsigned int cpu, int nid) { }
> +
> +#endif	/* CONFIG_NUMA */
> +
> +#endif	/* __ASM_NUMA_H */
> diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> index a3e9d6f..8b57339 100644
> --- a/arch/arm64/include/asm/topology.h
> +++ b/arch/arm64/include/asm/topology.h
> @@ -22,6 +22,16 @@ void init_cpu_topology(void);
>   void store_cpu_topology(unsigned int cpuid);
>   const struct cpumask *cpu_coregroup_mask(int cpu);
>
> +#ifdef CONFIG_NUMA
> +
> +struct pci_bus;
> +int pcibus_to_node(struct pci_bus *bus);
> +#define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ?		\
> +				 cpu_all_mask :				\
> +				 cpumask_of_node(pcibus_to_node(bus)))
> +
> +#endif /* CONFIG_NUMA */
> +
>   #include <asm-generic/topology.h>
>
>   #endif /* _ASM_ARM_TOPOLOGY_H */
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index b3d098b..65e6b7d 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -76,6 +76,16 @@ int raw_pci_write(unsigned int domain, unsigned int bus,
>   	return -ENXIO;
>   }
>
> +#ifdef CONFIG_NUMA
> +
> +int pcibus_to_node(struct pci_bus *bus)
> +{
> +	return dev_to_node(&bus->dev);
> +}
> +EXPORT_SYMBOL(pcibus_to_node);
> +
> +#endif
> +
>   #ifdef CONFIG_ACPI
>   /* Root bridge scanning */
>   struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 8119479..d9b9761 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -53,6 +53,7 @@
>   #include <asm/cpufeature.h>
>   #include <asm/cpu_ops.h>
>   #include <asm/kasan.h>
> +#include <asm/numa.h>
>   #include <asm/sections.h>
>   #include <asm/setup.h>
>   #include <asm/smp_plat.h>
> @@ -372,6 +373,9 @@ static int __init topology_init(void)
>   {
>   	int i;
>
> +	for_each_online_node(i)
> +		register_one_node(i);
> +
>   	for_each_possible_cpu(i) {
>   		struct cpu *cpu = &per_cpu(cpu_data.cpu, i);
>   		cpu->hotpluggable = 1;
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index b1adc51..46c45c8 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -45,6 +45,7 @@
>   #include <asm/cputype.h>
>   #include <asm/cpu_ops.h>
>   #include <asm/mmu_context.h>
> +#include <asm/numa.h>
>   #include <asm/pgtable.h>
>   #include <asm/pgalloc.h>
>   #include <asm/processor.h>
> @@ -125,6 +126,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
>   static void smp_store_cpu_info(unsigned int cpuid)
>   {
>   	store_cpu_topology(cpuid);
> +	numa_store_cpu_info(cpuid);
>   }
>
>   /*
> @@ -518,6 +520,8 @@ static void __init of_parse_and_init_cpus(void)
>
>   		pr_debug("cpu logical map 0x%llx\n", hwid);
>   		cpu_logical_map(cpu_count) = hwid;
> +
> +		early_map_cpu_to_node(cpu_count, of_node_to_nid(dn));
>   next:
>   		cpu_count++;
>   	}
> diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
> index 57f57fd..54bb209 100644
> --- a/arch/arm64/mm/Makefile
> +++ b/arch/arm64/mm/Makefile
> @@ -4,6 +4,7 @@ obj-y				:= dma-mapping.o extable.o fault.o init.o \
>   				   context.o proc.o pageattr.o
>   obj-$(CONFIG_HUGETLB_PAGE)	+= hugetlbpage.o
>   obj-$(CONFIG_ARM64_PTDUMP)	+= dump.o
> +obj-$(CONFIG_NUMA)		+= numa.o
>
>   obj-$(CONFIG_KASAN)		+= kasan_init.o
>   KASAN_SANITIZE_kasan_init.o	:= n
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index f3b061e..c39c670 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -37,6 +37,7 @@
>
>   #include <asm/fixmap.h>
>   #include <asm/memory.h>
> +#include <asm/numa.h>
>   #include <asm/sections.h>
>   #include <asm/setup.h>
>   #include <asm/sizes.h>
> @@ -77,6 +78,21 @@ static phys_addr_t __init max_zone_dma_phys(void)
>   	return min(offset + (1ULL << 32), memblock_end_of_DRAM());
>   }
>
> +#ifdef CONFIG_NUMA
> +
> +static void __init zone_sizes_init(unsigned long min, unsigned long max)
> +{
> +	unsigned long max_zone_pfns[MAX_NR_ZONES]  = {0};
> +
> +	if (IS_ENABLED(CONFIG_ZONE_DMA))
> +		max_zone_pfns[ZONE_DMA] = PFN_DOWN(max_zone_dma_phys());
> +	max_zone_pfns[ZONE_NORMAL] = max;
> +
> +	free_area_init_nodes(max_zone_pfns);
> +}
> +
> +#else
> +
>   static void __init zone_sizes_init(unsigned long min, unsigned long max)
>   {
>   	struct memblock_region *reg;
> @@ -117,6 +133,8 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
>   	free_area_init_node(0, zone_size, min, zhole_size);
>   }
>
> +#endif /* CONFIG_NUMA */
> +
>   #ifdef CONFIG_HAVE_ARCH_PFN_VALID
>   int pfn_valid(unsigned long pfn)
>   {
> @@ -133,10 +151,15 @@ static void __init arm64_memory_present(void)
>   static void __init arm64_memory_present(void)
>   {
>   	struct memblock_region *reg;
> +	int nid = 0;
>
> -	for_each_memblock(memory, reg)
> -		memory_present(0, memblock_region_memory_base_pfn(reg),
> -			       memblock_region_memory_end_pfn(reg));
> +	for_each_memblock(memory, reg) {
> +#ifdef CONFIG_NUMA
> +		nid = reg->nid;
> +#endif
> +		memory_present(nid, memblock_region_memory_base_pfn(reg),
> +				memblock_region_memory_end_pfn(reg));
> +	}
>   }
>   #endif
>
> @@ -181,7 +204,6 @@ void __init arm64_memblock_init(void)
>   	dma_contiguous_reserve(arm64_dma_phys_limit);
>
>   	memblock_allow_resize();
> -	memblock_dump_all();
>   }
>
>   void __init bootmem_init(void)
> @@ -193,6 +215,9 @@ void __init bootmem_init(void)
>
>   	early_memtest(min << PAGE_SHIFT, max << PAGE_SHIFT);
>
> +	max_pfn = max_low_pfn = max;
> +
> +	arm64_numa_init();
>   	/*
>   	 * Sparsemem tries to allocate bootmem in memory_present(), so must be
>   	 * done after the fixed reservations.
> @@ -203,7 +228,6 @@ void __init bootmem_init(void)
>   	zone_sizes_init(min, max);
>
>   	high_memory = __va((max << PAGE_SHIFT) - 1) + 1;
> -	max_pfn = max_low_pfn = max;
>   }
>
>   #ifndef CONFIG_SPARSEMEM_VMEMMAP
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 58faeaa..44e3854 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -463,6 +463,7 @@ void __init paging_init(void)
>   	zero_page = early_alloc(PAGE_SIZE);
>
>   	bootmem_init();
> +	memblock_dump_all();
>
>   	empty_zero_page = virt_to_page(zero_page);
>
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> new file mode 100644
> index 0000000..604e886
> --- /dev/null
> +++ b/arch/arm64/mm/numa.c
> @@ -0,0 +1,403 @@
> +/*
> + * NUMA support, based on the x86 implementation.
> + *
> + * Copyright (C) 2015 Cavium Inc.
> + * Author: Ganapatrao Kulkarni <gkulkarni at 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/bootmem.h>
> +#include <linux/memblock.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +
> +struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
> +EXPORT_SYMBOL(node_data);
> +nodemask_t numa_nodes_parsed __initdata;
> +static int cpu_to_node_map[NR_CPUS] = { [0 ... NR_CPUS-1] = NUMA_NO_NODE };
> +
> +static int numa_off;
> +static int numa_distance_cnt;
> +static u8 *numa_distance;
> +
> +static __init int numa_parse_early_param(char *opt)
> +{
> +	if (!opt)
> +		return -EINVAL;
> +	if (!strncmp(opt, "off", 3)) {
> +		pr_info("%s\n", "NUMA turned off");
> +		numa_off = 1;
> +	}
> +	return 0;
> +}
> +early_param("numa", numa_parse_early_param);
> +
> +cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
> +EXPORT_SYMBOL(node_to_cpumask_map);
> +
> +#ifdef CONFIG_DEBUG_PER_CPU_MAPS
> +
> +/*
> + * Returns a pointer to the bitmask of CPUs on Node 'node'.
> + */
> +const struct cpumask *cpumask_of_node(int node)
> +{
> +	if (WARN_ON(node >= nr_node_ids))
> +		return cpu_none_mask;
> +
> +	if (WARN_ON(node_to_cpumask_map[node] == NULL))
> +		return cpu_online_mask;
> +
> +	return node_to_cpumask_map[node];
> +}
> +EXPORT_SYMBOL(cpumask_of_node);
> +
> +#endif
> +
> +static void map_cpu_to_node(unsigned int cpu, int nid)
> +{
> +	set_cpu_numa_node(cpu, nid);
> +	if (nid >= 0)
> +		cpumask_set_cpu(cpu, node_to_cpumask_map[nid]);
> +}
> +
> +static void unmap_cpu_to_node(unsigned int cpu)
> +{
> +	int nid = cpu_to_node(cpu);
> +
> +	if (nid >= 0)
> +		cpumask_clear_cpu(cpu, node_to_cpumask_map[nid]);
> +	set_cpu_numa_node(cpu, NUMA_NO_NODE);
> +}
> +
> +void numa_clear_node(unsigned int cpu)
> +{
> +	unmap_cpu_to_node(cpu);
> +}
> +
> +/*
> + * Allocate node_to_cpumask_map based on number of available nodes
> + * Requires node_possible_map to be valid.
> + *
> + * Note: cpumask_of_node() is not valid until after this is done.
> + * (Use CONFIG_DEBUG_PER_CPU_MAPS to check this.)
> + */
> +static void __init setup_node_to_cpumask_map(void)
> +{
> +	unsigned int cpu;
> +	int node;
> +
> +	/* setup nr_node_ids if not done yet */
> +	if (nr_node_ids == MAX_NUMNODES)
> +		setup_nr_node_ids();
> +
> +	/* allocate and clear the mapping */
> +	for (node = 0; node < nr_node_ids; node++) {
> +		alloc_bootmem_cpumask_var(&node_to_cpumask_map[node]);
> +		cpumask_clear(node_to_cpumask_map[node]);
> +	}
> +
> +	for_each_possible_cpu(cpu)
> +		set_cpu_numa_node(cpu, NUMA_NO_NODE);
> +
> +	/* cpumask_of_node() will now work */
> +	pr_debug("NUMA: Node to cpumask map for %d nodes\n", nr_node_ids);
> +}
> +
> +/*
> + *  Set the cpu to node and mem mapping
> + */
> +void numa_store_cpu_info(unsigned int cpu)
> +{
> +	map_cpu_to_node(cpu, numa_off ? 0 : cpu_to_node_map[cpu]);
> +}
> +
> +void __init early_map_cpu_to_node(unsigned int cpu, int nid)
> +{
> +	/* fallback to node 0 */
> +	if (nid < 0 || nid >= MAX_NUMNODES)
> +		nid = 0;
> +
> +	cpu_to_node_map[cpu] = nid;
> +}
> +
> +/**
> + * numa_add_memblk - Set node id to memblk
> + * @nid: NUMA node ID of the new memblk
> + * @start: Start address of the new memblk
> + * @size:  Size of the new memblk
> + *
> + * RETURNS:
> + * 0 on success, -errno on failure.
> + */
> +int __init numa_add_memblk(int nid, u64 start, u64 size)
> +{
> +	int ret;
> +
> +	ret = memblock_set_node(start, size, &memblock.memory, nid);
> +	if (ret < 0) {
> +		pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node %d\n",
> +			start, (start + size - 1), nid);
> +		return ret;
> +	}
> +
> +	node_set(nid, numa_nodes_parsed);
> +	pr_info("NUMA: Adding memblock [0x%llx - 0x%llx] on node %d\n",
> +			start, (start + size - 1), nid);
> +	return ret;
> +}
> +EXPORT_SYMBOL(numa_add_memblk);
> +
> +/**
> + * Initialize NODE_DATA for a node on the local memory
> + */
> +static void __init setup_node_data(int nid, u64 start_pfn, u64 end_pfn)
> +{
> +	const size_t nd_size = roundup(sizeof(pg_data_t), SMP_CACHE_BYTES);
> +	u64 nd_pa;
> +	void *nd;
> +	int tnid;
> +
> +	pr_info("NUMA: Initmem setup node %d [mem %#010Lx-%#010Lx]\n",
> +			nid, start_pfn << PAGE_SHIFT,
> +			(end_pfn << PAGE_SHIFT) - 1);
> +
> +	nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
> +	nd = __va(nd_pa);
> +
> +	/* report and initialize */
> +	pr_info("NUMA: NODE_DATA [mem %#010Lx-%#010Lx]\n",
> +		nd_pa, nd_pa + nd_size - 1);
> +	tnid = early_pfn_to_nid(nd_pa >> PAGE_SHIFT);
> +	if (tnid != nid)
> +		pr_info("NUMA: NODE_DATA(%d) on node %d\n", nid, tnid);
> +
> +	node_data[nid] = nd;
> +	memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
> +	NODE_DATA(nid)->node_id = nid;
> +	NODE_DATA(nid)->node_start_pfn = start_pfn;
> +	NODE_DATA(nid)->node_spanned_pages = end_pfn - start_pfn;
> +}
> +
> +/**
> + * numa_free_distance
> + *
> + * The current table is freed.
> + */
> +void __init numa_free_distance(void)
> +{
> +	size_t size;
> +
> +	if (!numa_distance)
> +		return;
> +
> +	size = numa_distance_cnt * numa_distance_cnt *
> +		sizeof(numa_distance[0]);
> +
> +	memblock_free(__pa(numa_distance), size);
> +	numa_distance_cnt = 0;
> +	numa_distance = NULL;
> +}
> +
> +/**
> + *
> + * Create a new NUMA distance table.
> + *
> + */
> +static int __init numa_alloc_distance(void)
> +{
> +	size_t size;
> +	u64 phys;
> +	int i, j;
> +
> +	size = nr_node_ids * nr_node_ids * sizeof(numa_distance[0]);
> +	phys = memblock_find_in_range(0, PFN_PHYS(max_pfn),
> +				      size, PAGE_SIZE);
> +	if (WARN_ON(!phys))
> +		return -ENOMEM;
> +
> +	memblock_reserve(phys, size);
> +
> +	numa_distance = __va(phys);
> +	numa_distance_cnt = nr_node_ids;
> +
> +	/* fill with the default distances */
> +	for (i = 0; i < numa_distance_cnt; i++)
> +		for (j = 0; j < numa_distance_cnt; j++)
> +			numa_distance[i * numa_distance_cnt + j] = i == j ?
> +				LOCAL_DISTANCE : REMOTE_DISTANCE;
> +
> +	pr_debug("NUMA: Initialized distance table, cnt=%d\n",
> +			numa_distance_cnt);
> +
> +	return 0;
> +}
> +
> +/**
> + * numa_set_distance - Set inter node NUMA distance from node to node.
> + * @from: the 'from' node to set distance
> + * @to: the 'to'  node to set distance
> + * @distance: NUMA distance
> + *
> + * Set the distance from node @from to @to to @distance.
> + * If distance table doesn't exist, a warning is printed.
> + *
> + * If @from or @to is higher than the highest known node or lower than zero
> + * or @distance doesn't make sense, the call is ignored.
> + *
> + */
> +void __init numa_set_distance(int from, int to, int distance)
> +{
> +	if (!numa_distance) {
> +		pr_warn_once("NUMA: Warning: distance table not allocated yet\n");
> +		return;
> +	}
> +
> +	if (from >= numa_distance_cnt || to >= numa_distance_cnt ||
> +			from < 0 || to < 0) {
> +		pr_warn_once("NUMA: Warning: node ids are out of bound, from=%d to=%d distance=%d\n",
> +			    from, to, distance);
> +		return;
> +	}
> +
> +	if ((u8)distance != distance ||
> +	    (from == to && distance != LOCAL_DISTANCE)) {
> +		pr_warn_once("NUMA: Warning: invalid distance parameter, from=%d to=%d distance=%d\n",
> +			     from, to, distance);
> +		return;
> +	}
> +
> +	numa_distance[from * numa_distance_cnt + to] = distance;
> +}
> +EXPORT_SYMBOL(numa_set_distance);
> +
> +/**
> + * Return NUMA distance @from to @to
> + */
> +int __node_distance(int from, int to)
> +{
> +	if (from >= numa_distance_cnt || to >= numa_distance_cnt)
> +		return from == to ? LOCAL_DISTANCE : REMOTE_DISTANCE;
> +	return numa_distance[from * numa_distance_cnt + to];
> +}
> +EXPORT_SYMBOL(__node_distance);
> +
> +static int __init numa_register_nodes(void)
> +{
> +	int nid;
> +	struct memblock_region *mblk;
> +
> +	/* Check that valid nid is set to memblks */
> +	for_each_memblock(memory, mblk)
> +		if (mblk->nid == NUMA_NO_NODE || mblk->nid >= MAX_NUMNODES) {
> +			pr_warn("NUMA: Warning: invalid memblk node %d [mem %#010Lx-%#010Lx]\n",
> +				mblk->nid, mblk->base,
> +				mblk->base + mblk->size - 1);
> +			return -EINVAL;
> +		}
> +
> +	/* Finally register nodes. */
> +	for_each_node_mask(nid, numa_nodes_parsed) {
> +		unsigned long start_pfn, end_pfn;
> +
> +		get_pfn_range_for_nid(nid, &start_pfn, &end_pfn);
> +		setup_node_data(nid, start_pfn, end_pfn);
> +		node_set_online(nid);
> +	}
> +
> +	/* Setup online nodes to actual nodes*/
> +	node_possible_map = numa_nodes_parsed;
> +
> +	return 0;
> +}
> +
> +static int __init numa_init(int (*init_func)(void))
> +{
> +	int ret;
> +
> +	nodes_clear(numa_nodes_parsed);
> +	nodes_clear(node_possible_map);
> +	nodes_clear(node_online_map);
> +	numa_free_distance();
> +
> +	ret = numa_alloc_distance();
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = init_func();
> +	if (ret < 0)
> +		return ret;
> +
> +	if (nodes_empty(numa_nodes_parsed))
> +		return -EINVAL;
> +
> +	ret = numa_register_nodes();
> +	if (ret < 0)
> +		return ret;
> +
> +	setup_node_to_cpumask_map();
> +
> +	/* init boot processor */
> +	cpu_to_node_map[0] = 0;
> +	map_cpu_to_node(0, 0);
> +
> +	return 0;
> +}
> +
> +/**
> + * dummy_numa_init - Fallback dummy NUMA init
> + *
> + * Used if there's no underlying NUMA architecture, NUMA initialization
> + * fails, or NUMA is disabled on the command line.
> + *
> + * Must online at least one node (node 0) and add memory blocks that cover all
> + * allowed memory. It is unlikely that this function fails.
> + */
> +static int __init dummy_numa_init(void)
> +{
> +	int ret;
> +	struct memblock_region *mblk;
> +
> +	pr_info("%s\n", "No NUMA configuration found");
> +	pr_info("NUMA: Faking a node at [mem %#018Lx-%#018Lx]\n",
> +	       0LLU, PFN_PHYS(max_pfn) - 1);
> +
> +	for_each_memblock(memory, mblk) {
> +		ret = numa_add_memblk(0, mblk->base, mblk->size);
> +		if (!ret)
> +			continue;
> +
> +		pr_err("NUMA init failed\n");
> +		return ret;
> +	}
> +
> +	numa_off = 1;
> +	return 0;
> +}
> +
> +/**
> + * arm64_numa_init - Initialize NUMA
> + *
> + * Try each configured NUMA initialization method until one succeeds.  The
> + * last fallback is dummy single node config encomapssing whole memory.
> + */
> +void __init arm64_numa_init(void)
> +{
> +	if (!numa_off) {
> +		if (!numa_init(of_numa_init))
> +			return;
> +	}
> +
> +	numa_init(dummy_numa_init);
> +}
>



From marc.zyngier at arm.com  Tue Feb 23 09:42:42 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Tue, 23 Feb 2016 17:42:42 +0000
Subject: [PATCH v12 07/21] KVM: ARM64: PMU: Add perf event map and
 introduce perf event creating function
In-Reply-To: <1456133877-9584-8-git-send-email-zhaoshenglong@huawei.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
 <1456133877-9584-8-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <56CC9A12.6040001@arm.com>

Hi Shannon,

Still picking up on details...

On 22/02/16 09:37, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
> 
> When we use tools like perf on host, perf passes the event type and the
> id of this event type category to kernel, then kernel will map them to
> hardware event number and write this number to PMU PMEVTYPER<n>_EL0
> register. When getting the event number in KVM, directly use raw event
> type to create a perf_event for it.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/include/asm/perf_event.h |   2 +
>  arch/arm64/kvm/Makefile             |   1 +
>  include/kvm/arm_pmu.h               |  12 ++++
>  virt/kvm/arm/pmu.c                  | 122 ++++++++++++++++++++++++++++++++++++
>  4 files changed, 137 insertions(+)
>  create mode 100644 virt/kvm/arm/pmu.c
> 
> diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
> index 5c77ef8..867140d 100644
> --- a/arch/arm64/include/asm/perf_event.h
> +++ b/arch/arm64/include/asm/perf_event.h
> @@ -29,6 +29,8 @@
>  #define ARMV8_PMU_PMCR_D	(1 << 3) /* CCNT counts every 64th cpu cycle */
>  #define ARMV8_PMU_PMCR_X	(1 << 4) /* Export to ETM */
>  #define ARMV8_PMU_PMCR_DP	(1 << 5) /* Disable CCNT if non-invasive debug*/
> +/* Determines which bit of PMCCNTR_EL0 generates an overflow */
> +#define ARMV8_PMU_PMCR_LC	(1 << 6)

nit: this #define is only being used in patch #14. Consider moving it
there...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From ard.biesheuvel at linaro.org  Tue Feb 23 09:43:37 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Tue, 23 Feb 2016 18:43:37 +0100
Subject: [RFC PATCH 05/10] arm64: mm: avoid __pa translations in
 early_fixmap_init
In-Reply-To: <20160223173253.GH4777@e104818-lin.cambridge.arm.com>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456174472-30028-6-git-send-email-ard.biesheuvel@linaro.org>
 <20160223171241.GE4777@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-3VpzkVi8ygorRvW7E4XHqnV019VF0M1KZTy9Fu3yMBA@mail.gmail.com>
 <20160223172625.GG4777@e104818-lin.cambridge.arm.com>
 <CAKv+Gu8dORsacisDdw02cznp-6jh9-WnesZXVYLJv7Qg_VpApA@mail.gmail.com>
 <20160223173253.GH4777@e104818-lin.cambridge.arm.com>
Message-ID: <CAKv+Gu_9BLrptH3YvP+8T1hL_xg09UBugnSbOn0eFZ=Sp-oBRA@mail.gmail.com>

On 23 February 2016 at 18:32, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Tue, Feb 23, 2016 at 06:27:27PM +0100, Ard Biesheuvel wrote:
>> On 23 February 2016 at 18:26, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > On Tue, Feb 23, 2016 at 06:16:50PM +0100, Ard Biesheuvel wrote:
>> >> On 23 February 2016 at 18:12, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> >> > On Mon, Feb 22, 2016 at 09:54:27PM +0100, Ard Biesheuvel wrote:
>> >> >> --- a/arch/arm64/mm/mmu.c
>> >> >> +++ b/arch/arm64/mm/mmu.c
>> >> >> @@ -679,7 +679,7 @@ void __init early_fixmap_init(void)
>> >> >>
>> >> >>       pgd = pgd_offset_k(addr);
>> >> >>       if (CONFIG_PGTABLE_LEVELS > 3 &&
>> >> >> -         !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa(bm_pud))) {
>> >> >> +         !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa_symbol(bm_pud))) {
>> >> >>               /*
>> >> >>                * We only end up here if the kernel mapping and the fixmap
>> >> >>                * share the top level pgd entry, which should only happen on
>> >> >
>> >> > Do I miss any patches? The for-next/core branch has a pgd_none(*pgd)
>> >> > check here, so this patch does not apply.
>> >> >
>> >>
>> >> This is actually based on the kaslr branch, not for-next/core
>> >>
>> >> I'm happy to rebase and resend.
>> >
>> > That's fine, no need to resend. I plan to move those as well onto
>> > for-next/core but wanted some more testing first on the initial part.
>> >
>> >> I have added some patches for kasan, kvm and smp as well.
>> >
>> > Patches related to the __pa clean-up? Or something else?
>>
>> No, related to the __pa restriction
>
> OK. I'll wait for a while before merging this series to get more reviews
> and testing. I picked the first patch though (high_memory fix).
>

OK, I'll hold off for now. I have enough stuff in flight as it is.
However, I suppose that you will want to address the performance
concern at some point

If anyone wants to do any benchmarking:
git://git.linaro.org/people/ard.biesheuvel/linux-arm.git arm64-pa-linear-mapping

(updated for kasan, KVM, smp etc)


From robert.jarzmik at free.fr  Tue Feb 23 09:45:09 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Tue, 23 Feb 2016 18:45:09 +0100
Subject: [PATCH v2 2/4] dmaengine: mmp-pdma: add number of requestors
In-Reply-To: <1455569868-25017-2-git-send-email-robert.jarzmik@free.fr>
 (Robert Jarzmik's message of "Mon, 15 Feb 2016 21:57:46 +0100")
References: <1455569868-25017-1-git-send-email-robert.jarzmik@free.fr>
 <1455569868-25017-2-git-send-email-robert.jarzmik@free.fr>
Message-ID: <8737sjwcbe.fsf@belgarion.home>

Robert Jarzmik <robert.jarzmik at free.fr> writes:

> The DMA chip has a fixed number of requestor lines used for flow
> control. This number is platform dependent. The pxa_dma dma driver will
> use this value to activate or not the flow control.
>
> There won't be any impact on mmp_pdma driver.
Haojian,

Even if mmp_pdma will not be impacted, it would be good to have have your ack on
this trivial patch.

Cheers.

--
Robert

[1] The patch
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
> ---
>  include/linux/platform_data/mmp_dma.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/platform_data/mmp_dma.h b/include/linux/platform_data/mmp_dma.h
> index 2a330ec9e2af..d1397c8ed94e 100644
> --- a/include/linux/platform_data/mmp_dma.h
> +++ b/include/linux/platform_data/mmp_dma.h
> @@ -14,6 +14,7 @@
>  
>  struct mmp_dma_platdata {
>  	int dma_channels;
> +	int nb_requestors;
>  };
>  
>  #endif /* MMP_DMA_H */

-- 
Robert


From torvalds at linux-foundation.org  Tue Feb 23 09:46:08 2016
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Tue, 23 Feb 2016 09:46:08 -0800
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160223103221.GA1418@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160223103221.GA1418@node.shutemov.name>
Message-ID: <CA+55aFxh5P57Qg2xPYbTekAXzpWWON2qw76ZtC93ZQKqaqBA6A@mail.gmail.com>

On Tue, Feb 23, 2016 at 2:32 AM, Kirill A. Shutemov
<kirill at shutemov.name> wrote:
>
> I still worry about pmd_present(). It looks wrong to me. I wounder if
> patch below makes a difference.

Let's hope that's it, but in the meantime I do want to start the
discussion about what to do if it isn't. We're at rc5, and 4.5 is just
a few weeks away, and so far this issue hasn't gone anywhere.

So the *good* scenario is that your pmd_present() patch fixes it, and
we can all take a relieved breath.

But if not, what then? It looks like we have two options:

 (a) do a (hopefully minimal) revert.

     I say "hopefully minimal", but I suspect the revert is going to
have to undo pretty much all of the core THP changes. I'd hate to see
that, because I really liked the cleanups.

 (b) mark THP as "depends on !S390" in the 4.5 release

The (b) option is obviously much simpler, but it's a regression. I
really don't like it, even if it generally shouldn't be the kind of
regression that is actually user-noticeable (apart from performance).
I also hate the fact that while the problem only seems to happen on
s390, we don't even understand it, so maybe it's a more generic issue
that for some reason just ends up being *much* more noticeable on one
odd architecture that happens to be a bit different.

I'm inclined to think of (b) as just a "give us more time to figure it
out" thing, but I'm also worried that it will then make people not
pursue this issue.

How big is a revert patch that makes THP work on s390 again? Can we do
a revert that keeps the infrastructure intact and makes it easy to
revisit the THP cleanups later? Or is the revert inevitably going to
be all the core patches in that series?

                   Linus


From hdegoede at redhat.com  Tue Feb 23 09:46:23 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Tue, 23 Feb 2016 18:46:23 +0100
Subject: [PATCH v4 0/3] reset: Add support for shared reset controls
Message-ID: <1456249586-12101-1-git-send-email-hdegoede@redhat.com>

Hi All,

Here is v4 of my shared reset-controls patch.

Changes in v3:
-Rewrite as result of mailinglist discussions changing the API

Changes in v4:
-Improve documentation for shared reset-controls
-Move WARN_ON(foo) to inside if () conditions

Regards,

Hans


From hdegoede at redhat.com  Tue Feb 23 09:46:24 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Tue, 23 Feb 2016 18:46:24 +0100
Subject: [PATCH v4 1/3] reset: Make [of_]reset_control_get[_foo] functions
 wrappers
In-Reply-To: <1456249586-12101-1-git-send-email-hdegoede@redhat.com>
References: <1456249586-12101-1-git-send-email-hdegoede@redhat.com>
Message-ID: <1456249586-12101-2-git-send-email-hdegoede@redhat.com>

With both the regular, _by_index and _optional variants we already have
quite a few variants of [of_]reset_control_get[_foo], the upcoming
addition of shared reset lines support makes this worse.

This commit changes all the variants into wrappers around common core
functions. For completeness sake this commit also adds a new
devm_get_reset_control_by_index wrapper.

Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
 drivers/reset/core.c  |  84 +++++++--------------------------
 include/linux/reset.h | 126 +++++++++++++++++++++++++++++++++++---------------
 2 files changed, 107 insertions(+), 103 deletions(-)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 8737663..f695429 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -139,18 +139,8 @@ int reset_control_status(struct reset_control *rstc)
 }
 EXPORT_SYMBOL_GPL(reset_control_status);
 
-/**
- * of_reset_control_get_by_index - Lookup and obtain a reference to a reset
- * controller by index.
- * @node: device to be reset by the controller
- * @index: index of the reset controller
- *
- * This is to be used to perform a list of resets for a device or power domain
- * in whatever order. Returns a struct reset_control or IS_ERR() condition
- * containing errno.
- */
-struct reset_control *of_reset_control_get_by_index(struct device_node *node,
-					   int index)
+struct reset_control *__of_reset_control_get(struct device_node *node,
+					     const char *id, int index)
 {
 	struct reset_control *rstc = ERR_PTR(-EPROBE_DEFER);
 	struct reset_controller_dev *r, *rcdev;
@@ -158,6 +148,16 @@ struct reset_control *of_reset_control_get_by_index(struct device_node *node,
 	int rstc_id;
 	int ret;
 
+	if (!node)
+		return ERR_PTR(-EINVAL);
+
+	if (id) {
+		index = of_property_match_string(node,
+						 "reset-names", id);
+		if (index < 0)
+			return ERR_PTR(-ENOENT);
+	}
+
 	ret = of_parse_phandle_with_args(node, "resets", "#reset-cells",
 					 index, &args);
 	if (ret)
@@ -198,49 +198,7 @@ struct reset_control *of_reset_control_get_by_index(struct device_node *node,
 
 	return rstc;
 }
-EXPORT_SYMBOL_GPL(of_reset_control_get_by_index);
-
-/**
- * of_reset_control_get - Lookup and obtain a reference to a reset controller.
- * @node: device to be reset by the controller
- * @id: reset line name
- *
- * Returns a struct reset_control or IS_ERR() condition containing errno.
- *
- * Use of id names is optional.
- */
-struct reset_control *of_reset_control_get(struct device_node *node,
-					   const char *id)
-{
-	int index = 0;
-
-	if (id) {
-		index = of_property_match_string(node,
-						 "reset-names", id);
-		if (index < 0)
-			return ERR_PTR(-ENOENT);
-	}
-	return of_reset_control_get_by_index(node, index);
-}
-EXPORT_SYMBOL_GPL(of_reset_control_get);
-
-/**
- * reset_control_get - Lookup and obtain a reference to a reset controller.
- * @dev: device to be reset by the controller
- * @id: reset line name
- *
- * Returns a struct reset_control or IS_ERR() condition containing errno.
- *
- * Use of id names is optional.
- */
-struct reset_control *reset_control_get(struct device *dev, const char *id)
-{
-	if (!dev)
-		return ERR_PTR(-EINVAL);
-
-	return of_reset_control_get(dev->of_node, id);
-}
-EXPORT_SYMBOL_GPL(reset_control_get);
+EXPORT_SYMBOL_GPL(__of_reset_control_get);
 
 /**
  * reset_control_put - free the reset controller
@@ -262,16 +220,8 @@ static void devm_reset_control_release(struct device *dev, void *res)
 	reset_control_put(*(struct reset_control **)res);
 }
 
-/**
- * devm_reset_control_get - resource managed reset_control_get()
- * @dev: device to be reset by the controller
- * @id: reset line name
- *
- * Managed reset_control_get(). For reset controllers returned from this
- * function, reset_control_put() is called automatically on driver detach.
- * See reset_control_get() for more information.
- */
-struct reset_control *devm_reset_control_get(struct device *dev, const char *id)
+struct reset_control *__devm_reset_control_get(struct device *dev,
+					       const char *id, int index)
 {
 	struct reset_control **ptr, *rstc;
 
@@ -280,7 +230,7 @@ struct reset_control *devm_reset_control_get(struct device *dev, const char *id)
 	if (!ptr)
 		return ERR_PTR(-ENOMEM);
 
-	rstc = reset_control_get(dev, id);
+	rstc = __of_reset_control_get(dev ? dev->of_node : NULL, id, index);
 	if (!IS_ERR(rstc)) {
 		*ptr = rstc;
 		devres_add(dev, ptr);
@@ -290,7 +240,7 @@ struct reset_control *devm_reset_control_get(struct device *dev, const char *id)
 
 	return rstc;
 }
-EXPORT_SYMBOL_GPL(devm_reset_control_get);
+EXPORT_SYMBOL_GPL(__devm_reset_control_get);
 
 /**
  * device_reset - find reset controller associated with the device
diff --git a/include/linux/reset.h b/include/linux/reset.h
index c4c097d..1bb69a2 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -1,8 +1,8 @@
 #ifndef _LINUX_RESET_H_
 #define _LINUX_RESET_H_
 
-struct device;
-struct device_node;
+#include <linux/device.h>
+
 struct reset_control;
 
 #ifdef CONFIG_RESET_CONTROLLER
@@ -12,9 +12,11 @@ int reset_control_assert(struct reset_control *rstc);
 int reset_control_deassert(struct reset_control *rstc);
 int reset_control_status(struct reset_control *rstc);
 
-struct reset_control *reset_control_get(struct device *dev, const char *id);
+struct reset_control *__of_reset_control_get(struct device_node *node,
+					     const char *id, int index);
 void reset_control_put(struct reset_control *rstc);
-struct reset_control *devm_reset_control_get(struct device *dev, const char *id);
+struct reset_control *__devm_reset_control_get(struct device *dev,
+					       const char *id, int index);
 
 int __must_check device_reset(struct device *dev);
 
@@ -23,24 +25,6 @@ static inline int device_reset_optional(struct device *dev)
 	return device_reset(dev);
 }
 
-static inline struct reset_control *reset_control_get_optional(
-					struct device *dev, const char *id)
-{
-	return reset_control_get(dev, id);
-}
-
-static inline struct reset_control *devm_reset_control_get_optional(
-					struct device *dev, const char *id)
-{
-	return devm_reset_control_get(dev, id);
-}
-
-struct reset_control *of_reset_control_get(struct device_node *node,
-					   const char *id);
-
-struct reset_control *of_reset_control_get_by_index(
-					struct device_node *node, int index);
-
 #else
 
 static inline int reset_control_reset(struct reset_control *rstc)
@@ -77,44 +61,114 @@ static inline int device_reset_optional(struct device *dev)
 	return -ENOTSUPP;
 }
 
-static inline struct reset_control *__must_check reset_control_get(
-					struct device *dev, const char *id)
+static inline struct reset_control *__of_reset_control_get(
+					struct device_node *node,
+					const char *id, int index)
 {
-	WARN_ON(1);
 	return ERR_PTR(-EINVAL);
 }
 
-static inline struct reset_control *__must_check devm_reset_control_get(
-					struct device *dev, const char *id)
+static inline struct reset_control *__devm_reset_control_get(
+					struct device *dev,
+					const char *id, int index)
 {
-	WARN_ON(1);
 	return ERR_PTR(-EINVAL);
 }
 
-static inline struct reset_control *reset_control_get_optional(
+#endif /* CONFIG_RESET_CONTROLLER */
+
+/**
+ * reset_control_get - Lookup and obtain a reference to a reset controller.
+ * @dev: device to be reset by the controller
+ * @id: reset line name
+ *
+ * Returns a struct reset_control or IS_ERR() condition containing errno.
+ *
+ * Use of id names is optional.
+ */
+static inline struct reset_control *__must_check reset_control_get(
 					struct device *dev, const char *id)
 {
-	return ERR_PTR(-ENOTSUPP);
+#ifndef CONFIG_RESET_CONTROLLER
+	WARN_ON(1);
+#endif
+	return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0);
 }
 
-static inline struct reset_control *devm_reset_control_get_optional(
+static inline struct reset_control *reset_control_get_optional(
 					struct device *dev, const char *id)
 {
-	return ERR_PTR(-ENOTSUPP);
+	return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0);
 }
 
+/**
+ * of_reset_control_get - Lookup and obtain a reference to a reset controller.
+ * @node: device to be reset by the controller
+ * @id: reset line name
+ *
+ * Returns a struct reset_control or IS_ERR() condition containing errno.
+ *
+ * Use of id names is optional.
+ */
 static inline struct reset_control *of_reset_control_get(
 				struct device_node *node, const char *id)
 {
-	return ERR_PTR(-ENOTSUPP);
+	return __of_reset_control_get(node, id, 0);
 }
 
+/**
+ * of_reset_control_get_by_index - Lookup and obtain a reference to a reset
+ * controller by index.
+ * @node: device to be reset by the controller
+ * @index: index of the reset controller
+ *
+ * This is to be used to perform a list of resets for a device or power domain
+ * in whatever order. Returns a struct reset_control or IS_ERR() condition
+ * containing errno.
+ */
 static inline struct reset_control *of_reset_control_get_by_index(
-				struct device_node *node, int index)
+					struct device_node *node, int index)
 {
-	return ERR_PTR(-ENOTSUPP);
+	return __of_reset_control_get(node, NULL, index);
 }
 
-#endif /* CONFIG_RESET_CONTROLLER */
+/**
+ * devm_reset_control_get - resource managed reset_control_get()
+ * @dev: device to be reset by the controller
+ * @id: reset line name
+ *
+ * Managed reset_control_get(). For reset controllers returned from this
+ * function, reset_control_put() is called automatically on driver detach.
+ * See reset_control_get() for more information.
+ */
+static inline struct reset_control *__must_check devm_reset_control_get(
+					struct device *dev, const char *id)
+{
+#ifndef CONFIG_RESET_CONTROLLER
+	WARN_ON(1);
+#endif
+	return __devm_reset_control_get(dev, id, 0);
+}
+
+static inline struct reset_control *devm_reset_control_get_optional(
+					struct device *dev, const char *id)
+{
+	return __devm_reset_control_get(dev, id, 0);
+}
+
+/**
+ * devm_reset_control_get_by_index - resource managed reset_control_get
+ * @dev: device to be reset by the controller
+ * @index: index of the reset controller
+ *
+ * Managed reset_control_get(). For reset controllers returned from this
+ * function, reset_control_put() is called automatically on driver detach.
+ * See reset_control_get() for more information.
+ */
+static inline struct reset_control *devm_reset_control_get_by_index(
+					struct device *dev, int index)
+{
+	return __devm_reset_control_get(dev, NULL, index);
+}
 
 #endif
-- 
2.7.1



From hdegoede at redhat.com  Tue Feb 23 09:46:25 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Tue, 23 Feb 2016 18:46:25 +0100
Subject: [PATCH v4 2/3] reset: Share struct reset_control between
 reset_control_get calls
In-Reply-To: <1456249586-12101-1-git-send-email-hdegoede@redhat.com>
References: <1456249586-12101-1-git-send-email-hdegoede@redhat.com>
Message-ID: <1456249586-12101-3-git-send-email-hdegoede@redhat.com>

Now that struct reset_control no longer stores the device pointer for
the device calling reset_control_get we can share a single struct
reset_control when multiple calls to reset_control_get are made for
the same reset line (same id / index).

This is a preparation patch for adding support for shared reset lines.

Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
 drivers/reset/core.c             | 82 ++++++++++++++++++++++++++++++----------
 include/linux/reset-controller.h |  2 +
 2 files changed, 64 insertions(+), 20 deletions(-)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index f695429..e439ae2 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -18,19 +18,23 @@
 #include <linux/reset-controller.h>
 #include <linux/slab.h>
 
-static DEFINE_MUTEX(reset_controller_list_mutex);
+static DEFINE_MUTEX(reset_list_mutex);
 static LIST_HEAD(reset_controller_list);
 
 /**
  * struct reset_control - a reset control
  * @rcdev: a pointer to the reset controller device
  *         this reset control belongs to
+ * @list: list entry for the rcdev's reset controller list
  * @id: ID of the reset controller in the reset
  *      controller device
+ * @refcnt: Number of gets of this reset_control
  */
 struct reset_control {
 	struct reset_controller_dev *rcdev;
+	struct list_head list;
 	unsigned int id;
+	unsigned int refcnt;
 };
 
 /**
@@ -65,9 +69,11 @@ int reset_controller_register(struct reset_controller_dev *rcdev)
 		rcdev->of_xlate = of_reset_simple_xlate;
 	}
 
-	mutex_lock(&reset_controller_list_mutex);
+	INIT_LIST_HEAD(&rcdev->reset_control_head);
+
+	mutex_lock(&reset_list_mutex);
 	list_add(&rcdev->list, &reset_controller_list);
-	mutex_unlock(&reset_controller_list_mutex);
+	mutex_unlock(&reset_list_mutex);
 
 	return 0;
 }
@@ -79,9 +85,9 @@ EXPORT_SYMBOL_GPL(reset_controller_register);
  */
 void reset_controller_unregister(struct reset_controller_dev *rcdev)
 {
-	mutex_lock(&reset_controller_list_mutex);
+	mutex_lock(&reset_list_mutex);
 	list_del(&rcdev->list);
-	mutex_unlock(&reset_controller_list_mutex);
+	mutex_unlock(&reset_list_mutex);
 }
 EXPORT_SYMBOL_GPL(reset_controller_unregister);
 
@@ -139,6 +145,48 @@ int reset_control_status(struct reset_control *rstc)
 }
 EXPORT_SYMBOL_GPL(reset_control_status);
 
+static struct reset_control *__reset_control_get(
+				struct reset_controller_dev *rcdev,
+				unsigned int index)
+{
+	struct reset_control *rstc;
+
+	lockdep_assert_held(&reset_list_mutex);
+
+	list_for_each_entry(rstc, &rcdev->reset_control_head, list) {
+		if (rstc->id == index) {
+			rstc->refcnt++;
+			return rstc;
+		}
+	}
+
+	rstc = kzalloc(sizeof(*rstc), GFP_KERNEL);
+	if (!rstc)
+		return ERR_PTR(-ENOMEM);
+
+	try_module_get(rcdev->owner);
+
+	rstc->rcdev = rcdev;
+	list_add(&rstc->list, &rcdev->reset_control_head);
+	rstc->id = index;
+	rstc->refcnt = 1;
+
+	return rstc;
+}
+
+static void __reset_control_put(struct reset_control *rstc)
+{
+	lockdep_assert_held(&reset_list_mutex);
+
+	if (--rstc->refcnt)
+		return;
+
+	module_put(rstc->rcdev->owner);
+
+	list_del(&rstc->list);
+	kfree(rstc);
+}
+
 struct reset_control *__of_reset_control_get(struct device_node *node,
 					     const char *id, int index)
 {
@@ -163,7 +211,7 @@ struct reset_control *__of_reset_control_get(struct device_node *node,
 	if (ret)
 		return ERR_PTR(ret);
 
-	mutex_lock(&reset_controller_list_mutex);
+	mutex_lock(&reset_list_mutex);
 	rcdev = NULL;
 	list_for_each_entry(r, &reset_controller_list, list) {
 		if (args.np == r->of_node) {
@@ -174,27 +222,20 @@ struct reset_control *__of_reset_control_get(struct device_node *node,
 	of_node_put(args.np);
 
 	if (!rcdev) {
-		mutex_unlock(&reset_controller_list_mutex);
+		mutex_unlock(&reset_list_mutex);
 		return ERR_PTR(-EPROBE_DEFER);
 	}
 
 	rstc_id = rcdev->of_xlate(rcdev, &args);
 	if (rstc_id < 0) {
-		mutex_unlock(&reset_controller_list_mutex);
+		mutex_unlock(&reset_list_mutex);
 		return ERR_PTR(rstc_id);
 	}
 
-	try_module_get(rcdev->owner);
-	mutex_unlock(&reset_controller_list_mutex);
-
-	rstc = kzalloc(sizeof(*rstc), GFP_KERNEL);
-	if (!rstc) {
-		module_put(rcdev->owner);
-		return ERR_PTR(-ENOMEM);
-	}
+	/* reset_list_mutex also protects the rcdev's reset_control list */
+	rstc = __reset_control_get(rcdev, rstc_id);
 
-	rstc->rcdev = rcdev;
-	rstc->id = rstc_id;
+	mutex_unlock(&reset_list_mutex);
 
 	return rstc;
 }
@@ -210,8 +251,9 @@ void reset_control_put(struct reset_control *rstc)
 	if (IS_ERR(rstc))
 		return;
 
-	module_put(rstc->rcdev->owner);
-	kfree(rstc);
+	mutex_lock(&reset_list_mutex);
+	__reset_control_put(rstc);
+	mutex_unlock(&reset_list_mutex);
 }
 EXPORT_SYMBOL_GPL(reset_control_put);
 
diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller.h
index ce6b962..2decc20 100644
--- a/include/linux/reset-controller.h
+++ b/include/linux/reset-controller.h
@@ -31,6 +31,7 @@ struct of_phandle_args;
  * @ops: a pointer to device specific struct reset_control_ops
  * @owner: kernel module of the reset controller driver
  * @list: internal list of reset controller devices
+ * @reset_control_head: head of internal list of requested reset controls
  * @of_node: corresponding device tree node as phandle target
  * @of_reset_n_cells: number of cells in reset line specifiers
  * @of_xlate: translation function to translate from specifier as found in the
@@ -41,6 +42,7 @@ struct reset_controller_dev {
 	struct reset_control_ops *ops;
 	struct module *owner;
 	struct list_head list;
+	struct list_head reset_control_head;
 	struct device_node *of_node;
 	int of_reset_n_cells;
 	int (*of_xlate)(struct reset_controller_dev *rcdev,
-- 
2.7.1



From hdegoede at redhat.com  Tue Feb 23 09:46:26 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Tue, 23 Feb 2016 18:46:26 +0100
Subject: [PATCH v4 3/3] reset: Add support for shared reset controls
In-Reply-To: <1456249586-12101-1-git-send-email-hdegoede@redhat.com>
References: <1456249586-12101-1-git-send-email-hdegoede@redhat.com>
Message-ID: <1456249586-12101-4-git-send-email-hdegoede@redhat.com>

In some SoCs some hw-blocks share a reset control. Add support for this
setup by adding new:

reset_control_get_shared()
devm_reset_control_get_shared()
devm_reset_control_get_shared_by_index()

methods to get a reset_control. Note that this patch omits adding of_
variants, if these are needed later they can be easily added.

This patch also changes the behavior of the existing exclusive
reset_control_get() variants, if these are now called more then once
for the same reset_control they will return -EBUSY. To catch existing
drivers triggering this error (there should not be any) a WARN_ON(1)
is added in this path.

When a reset_control is shared, the behavior of reset_control_assert /
deassert is changed, for shared reset_controls these will work like the
clock-enable/disable and regulator-on/off functions. They will keep a
deassert_count, and only (re-)assert the reset after reset_control_assert
has been called as many times as reset_control_deassert was called.

Calling reset_control_assert without first calling reset_control_deassert
is not allowed on a shared reset control. Calling reset_control_reset is
also not allowed on a shared reset control.

Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
 drivers/reset/core.c  | 59 +++++++++++++++++++++++++------
 include/linux/reset.h | 96 +++++++++++++++++++++++++++++++++++++++++++--------
 2 files changed, 129 insertions(+), 26 deletions(-)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index e439ae2..400e42f 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -8,6 +8,7 @@
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  */
+#include <linux/atomic.h>
 #include <linux/device.h>
 #include <linux/err.h>
 #include <linux/export.h>
@@ -29,12 +30,16 @@ static LIST_HEAD(reset_controller_list);
  * @id: ID of the reset controller in the reset
  *      controller device
  * @refcnt: Number of gets of this reset_control
+ * @shared: Is this a shared (1), or an exclusive (0) reset_control?
+ * @deassert_cnt: Number of times this reset line has been deasserted
  */
 struct reset_control {
 	struct reset_controller_dev *rcdev;
 	struct list_head list;
 	unsigned int id;
 	unsigned int refcnt;
+	int shared;
+	atomic_t deassert_count;
 };
 
 /**
@@ -94,9 +99,14 @@ EXPORT_SYMBOL_GPL(reset_controller_unregister);
 /**
  * reset_control_reset - reset the controlled device
  * @rstc: reset controller
+ *
+ * Calling this on a shared reset controller is an error.
  */
 int reset_control_reset(struct reset_control *rstc)
 {
+	if (WARN_ON(rstc->shared))
+		return -EINVAL;
+
 	if (rstc->rcdev->ops->reset)
 		return rstc->rcdev->ops->reset(rstc->rcdev, rstc->id);
 
@@ -107,26 +117,48 @@ EXPORT_SYMBOL_GPL(reset_control_reset);
 /**
  * reset_control_assert - asserts the reset line
  * @rstc: reset controller
+ *
+ * Calling this on an exclusive reset controller guarantees that the reset
+ * will be asserted. When called on a shared reset controller the line may
+ * still be deasserted, as long as other users keep it so.
+ *
+ * For shared reset controls a driver cannot expect the hw's registers and
+ * internal state to be reset, but must be prepared for this to happen. 
  */
 int reset_control_assert(struct reset_control *rstc)
 {
-	if (rstc->rcdev->ops->assert)
-		return rstc->rcdev->ops->assert(rstc->rcdev, rstc->id);
+	if (!rstc->rcdev->ops->assert)
+		return -ENOTSUPP;
 
-	return -ENOTSUPP;
+	if (rstc->shared) {
+		if (WARN_ON(atomic_read(&rstc->deassert_count) == 0))
+			return -EINVAL;
+
+		if (atomic_dec_return(&rstc->deassert_count) != 0)
+			return 0;
+	}
+
+	return rstc->rcdev->ops->assert(rstc->rcdev, rstc->id);
 }
 EXPORT_SYMBOL_GPL(reset_control_assert);
 
 /**
  * reset_control_deassert - deasserts the reset line
  * @rstc: reset controller
+ *
+ * After calling this function, the reset is guaranteed to be deasserted.
  */
 int reset_control_deassert(struct reset_control *rstc)
 {
-	if (rstc->rcdev->ops->deassert)
-		return rstc->rcdev->ops->deassert(rstc->rcdev, rstc->id);
+	if (!rstc->rcdev->ops->deassert)
+		return -ENOTSUPP;
 
-	return -ENOTSUPP;
+	if (rstc->shared) {
+		if (atomic_inc_return(&rstc->deassert_count) != 1)
+			return 0;
+	}
+
+	return rstc->rcdev->ops->deassert(rstc->rcdev, rstc->id);
 }
 EXPORT_SYMBOL_GPL(reset_control_deassert);
 
@@ -147,7 +179,7 @@ EXPORT_SYMBOL_GPL(reset_control_status);
 
 static struct reset_control *__reset_control_get(
 				struct reset_controller_dev *rcdev,
-				unsigned int index)
+				unsigned int index, int shared)
 {
 	struct reset_control *rstc;
 
@@ -155,6 +187,9 @@ static struct reset_control *__reset_control_get(
 
 	list_for_each_entry(rstc, &rcdev->reset_control_head, list) {
 		if (rstc->id == index) {
+			if (WARN_ON(!rstc->shared || !shared))
+				return ERR_PTR(-EBUSY);
+
 			rstc->refcnt++;
 			return rstc;
 		}
@@ -170,6 +205,7 @@ static struct reset_control *__reset_control_get(
 	list_add(&rstc->list, &rcdev->reset_control_head);
 	rstc->id = index;
 	rstc->refcnt = 1;
+	rstc->shared = shared;
 
 	return rstc;
 }
@@ -188,7 +224,7 @@ static void __reset_control_put(struct reset_control *rstc)
 }
 
 struct reset_control *__of_reset_control_get(struct device_node *node,
-					     const char *id, int index)
+				     const char *id, int index, int shared)
 {
 	struct reset_control *rstc = ERR_PTR(-EPROBE_DEFER);
 	struct reset_controller_dev *r, *rcdev;
@@ -233,7 +269,7 @@ struct reset_control *__of_reset_control_get(struct device_node *node,
 	}
 
 	/* reset_list_mutex also protects the rcdev's reset_control list */
-	rstc = __reset_control_get(rcdev, rstc_id);
+	rstc = __reset_control_get(rcdev, rstc_id, shared);
 
 	mutex_unlock(&reset_list_mutex);
 
@@ -263,7 +299,7 @@ static void devm_reset_control_release(struct device *dev, void *res)
 }
 
 struct reset_control *__devm_reset_control_get(struct device *dev,
-					       const char *id, int index)
+				     const char *id, int index, int shared)
 {
 	struct reset_control **ptr, *rstc;
 
@@ -272,7 +308,8 @@ struct reset_control *__devm_reset_control_get(struct device *dev,
 	if (!ptr)
 		return ERR_PTR(-ENOMEM);
 
-	rstc = __of_reset_control_get(dev ? dev->of_node : NULL, id, index);
+	rstc = __of_reset_control_get(dev ? dev->of_node : NULL,
+				      id, index, shared);
 	if (!IS_ERR(rstc)) {
 		*ptr = rstc;
 		devres_add(dev, ptr);
diff --git a/include/linux/reset.h b/include/linux/reset.h
index 1bb69a2..a552134 100644
--- a/include/linux/reset.h
+++ b/include/linux/reset.h
@@ -13,10 +13,10 @@ int reset_control_deassert(struct reset_control *rstc);
 int reset_control_status(struct reset_control *rstc);
 
 struct reset_control *__of_reset_control_get(struct device_node *node,
-					     const char *id, int index);
+				     const char *id, int index, int shared);
 void reset_control_put(struct reset_control *rstc);
 struct reset_control *__devm_reset_control_get(struct device *dev,
-					       const char *id, int index);
+				     const char *id, int index, int shared);
 
 int __must_check device_reset(struct device *dev);
 
@@ -63,14 +63,14 @@ static inline int device_reset_optional(struct device *dev)
 
 static inline struct reset_control *__of_reset_control_get(
 					struct device_node *node,
-					const char *id, int index)
+					const char *id, int index, int shared)
 {
 	return ERR_PTR(-EINVAL);
 }
 
 static inline struct reset_control *__devm_reset_control_get(
 					struct device *dev,
-					const char *id, int index)
+					const char *id, int index, int shared)
 {
 	return ERR_PTR(-EINVAL);
 }
@@ -78,11 +78,17 @@ static inline struct reset_control *__devm_reset_control_get(
 #endif /* CONFIG_RESET_CONTROLLER */
 
 /**
- * reset_control_get - Lookup and obtain a reference to a reset controller.
+ * reset_control_get - Lookup and obtain an exclusive reference to a
+ *                     reset controller.
  * @dev: device to be reset by the controller
  * @id: reset line name
  *
  * Returns a struct reset_control or IS_ERR() condition containing errno.
+ * If this function is called more then once for the same reset_control it will
+ * return -EBUSY.
+ *
+ * See reset_control_get_shared for details on shared references to
+ * reset-controls.
  *
  * Use of id names is optional.
  */
@@ -92,17 +98,46 @@ static inline struct reset_control *__must_check reset_control_get(
 #ifndef CONFIG_RESET_CONTROLLER
 	WARN_ON(1);
 #endif
-	return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0);
+	return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0, 0);
 }
 
 static inline struct reset_control *reset_control_get_optional(
 					struct device *dev, const char *id)
 {
-	return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0);
+	return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0, 0);
 }
 
 /**
- * of_reset_control_get - Lookup and obtain a reference to a reset controller.
+ * reset_control_get_shared - Lookup and obtain a shared reference to a
+ *                            reset controller.
+ * @dev: device to be reset by the controller
+ * @id: reset line name
+ *
+ * Returns a struct reset_control or IS_ERR() condition containing errno.
+ * This function is intended for use with reset-controls which are shared
+ * between hardware-blocks.
+ *
+ * When a reset-control is shared, the behavior of reset_control_assert /
+ * deassert is changed, the reset-core will keep track of a deassert_count
+ * and only (re-)assert the reset after reset_control_assert has been called
+ * as many times as reset_control_deassert was called. Also see the remark
+ * about shared reset-controls in the reset_control_assert docs.
+ *
+ * Calling reset_control_assert without first calling reset_control_deassert
+ * is not allowed on a shared reset control. Calling reset_control_reset is
+ * also not allowed on a shared reset control.
+ *
+ * Use of id names is optional.
+ */
+static inline struct reset_control *reset_control_get_shared(
+					struct device *dev, const char *id)
+{
+	return __of_reset_control_get(dev ? dev->of_node : NULL, id, 0, 1);
+}
+
+/**
+ * of_reset_control_get - Lookup and obtain an exclusive reference to a
+ *                        reset controller.
  * @node: device to be reset by the controller
  * @id: reset line name
  *
@@ -113,12 +148,12 @@ static inline struct reset_control *reset_control_get_optional(
 static inline struct reset_control *of_reset_control_get(
 				struct device_node *node, const char *id)
 {
-	return __of_reset_control_get(node, id, 0);
+	return __of_reset_control_get(node, id, 0, 0);
 }
 
 /**
- * of_reset_control_get_by_index - Lookup and obtain a reference to a reset
- * controller by index.
+ * of_reset_control_get_by_index - Lookup and obtain an exclusive reference to
+ *                                 a reset controller by index.
  * @node: device to be reset by the controller
  * @index: index of the reset controller
  *
@@ -129,7 +164,7 @@ static inline struct reset_control *of_reset_control_get(
 static inline struct reset_control *of_reset_control_get_by_index(
 					struct device_node *node, int index)
 {
-	return __of_reset_control_get(node, NULL, index);
+	return __of_reset_control_get(node, NULL, index, 0);
 }
 
 /**
@@ -147,13 +182,13 @@ static inline struct reset_control *__must_check devm_reset_control_get(
 #ifndef CONFIG_RESET_CONTROLLER
 	WARN_ON(1);
 #endif
-	return __devm_reset_control_get(dev, id, 0);
+	return __devm_reset_control_get(dev, id, 0, 0);
 }
 
 static inline struct reset_control *devm_reset_control_get_optional(
 					struct device *dev, const char *id)
 {
-	return __devm_reset_control_get(dev, id, 0);
+	return __devm_reset_control_get(dev, id, 0, 0);
 }
 
 /**
@@ -168,7 +203,38 @@ static inline struct reset_control *devm_reset_control_get_optional(
 static inline struct reset_control *devm_reset_control_get_by_index(
 					struct device *dev, int index)
 {
-	return __devm_reset_control_get(dev, NULL, index);
+	return __devm_reset_control_get(dev, NULL, index, 0);
+}
+
+/**
+ * devm_reset_control_get_shared - resource managed reset_control_get_shared()
+ * @dev: device to be reset by the controller
+ * @id: reset line name
+ *
+ * Managed reset_control_get_shared(). For reset controllers returned from
+ * this function, reset_control_put() is called automatically on driver detach.
+ * See reset_control_get_shared() for more information.
+ */
+static inline struct reset_control *devm_reset_control_get_shared(
+					struct device *dev, const char *id)
+{
+	return __devm_reset_control_get(dev, id, 0, 1);
+}
+
+/**
+ * devm_reset_control_get_shared_by_index - resource managed
+ * reset_control_get_shared
+ * @dev: device to be reset by the controller
+ * @index: index of the reset controller
+ *
+ * Managed reset_control_get_shared(). For reset controllers returned from
+ * this function, reset_control_put() is called automatically on driver detach.
+ * See reset_control_get_shared() for more information.
+ */
+static inline struct reset_control *devm_reset_control_get_shared_by_index(
+					struct device *dev, int index)
+{
+	return __devm_reset_control_get(dev, NULL, index, 1);
 }
 
 #endif
-- 
2.7.1



From shankerd at codeaurora.org  Tue Feb 23 09:48:37 2016
From: shankerd at codeaurora.org (Shanker Donthineni)
Date: Tue, 23 Feb 2016 11:48:37 -0600
Subject: [PATCH] irqchip/gicv3-its: Don't allow devices whose ID is
 outside range
In-Reply-To: <56CC1D83.4060503@arm.com>
References: <1456199868-9054-1-git-send-email-shankerd@codeaurora.org>
 <56CC1D83.4060503@arm.com>
Message-ID: <56CC9B75.7090801@codeaurora.org>

Hi Marc,

Sorry, I have not responded to your email earlier, by mistake replied to 
original patch.

On 02/23/2016 02:51 AM, Marc Zyngier wrote:
> On 23/02/16 03:57, Shanker Donthineni wrote:
>> We are not checking whether the requested device identifier fits into
>> table or not. The ITS MAPD command fails if 'Device ID' is outside of
>> device table range.
>>
>> Add a simple validation check to avoid MAPD failures since we are
>> not handling ITS command errors. This change also helps to return an
>> error -ENOMEM instead of success to caller.
>>
> In which circumstances do you see this failing? We allocate memory for
> the whole DevID range (as advertised by the ITS), so anything that comes
> up outside of that range cannot be handled anyway, and is a HW
> integration issue. You might as well pretend that these devices do not
> exist.
>
> Thanks,
>
> 	M.
ITS probe function tries to allocate maximum memory as much as possible to
cover whole DevID. sparse which is reported (ITS_TYPER.Devbits) by HW. We
might not be able to allocate enough memory for device table.  We reduce
memory allocation size for two reasons either because of crossing MAX_ORDER
limit or max ITS_BASERn size.

1) According to ARM-GIC spec, we can assign maximum memory size
     256 (ITS-Size) * 64K (ITS-PageSzie) Bytes to level-one (flat) 
device table.

     DevID = flat_table_size/device_table_entry_size = 16MBytes/8  = 
21bits (max)

2) Maximum 4Mbytes memory is possible on kernel using PAGE_SIZE=4K with 
default
     arch/arm64/defconfig (MAX_ORDER = 12).

     DevID = flat_table_size/device_table_entry_size = 4MBytes/8  = 
19bits (max)

Assuming: minimum device table entry size 8 Bytes.

I think it is a generic problem and this fail scenario happens if DevID 
range is more
than 21bits or failed to allocate required memory size for device table.

Our ITS hardware is capable of supporting 32bit DevID space, so it 
advertises
ITS_TYPER.Devbits field with value 31 causing this problem. I think we need
some protection in its_create_device() to avoid this scenario.

I am planning to post an another patch to add support for ITS-Indirection
(two-level) table walk feature.

-- 
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project



From tchalamarla at caviumnetworks.com  Tue Feb 23 09:53:44 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Tue, 23 Feb 2016 09:53:44 -0800
Subject: [PATCH V2] iommu/arm-smmu-v2: Add support for 16 bit VMID
In-Reply-To: <20160223112219.GE3966@arm.com>
References: <1455906813-9721-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160223112219.GE3966@arm.com>
Message-ID: <56CC9CA8.7080507@caviumnetworks.com>



On 02/23/2016 03:22 AM, Will Deacon wrote:
> Hi Tirumalesh,
>
> I still have some questions and comments about this.
>
> On Fri, Feb 19, 2016 at 10:33:33AM -0800, tchalamarla at caviumnetworks.com wrote:
>> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>>
>> ARM-SMMUv2 supports upto 16 bit VMID. This patch enables
>> 16 bit VMID when HW supports.
>>
>> changes from V1:
>> 	- Remove DT Property and enable 16 bit VMID if ID says.
>
> Does this mean we can remove the comment from arm_smmu_init_context_bank
> about CBA2R initialisation, or is that behaviour still required by some
> parts? Further, what happens if we set CR0.VMID16EN on those
> implementations?
>

For Thunder, we can remove the prints, The parts which are target for 
upstreaming will check for VMID16EN and don't overwrite 8bit VMID.

>> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>> ---
>>   drivers/iommu/arm-smmu.c | 24 +++++++++++++++++++++++-
>>   1 file changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 59ee4b8..92caab8 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -93,6 +93,7 @@
>>   #define sCR0_VMIDPNE			(1 << 11)
>>   #define sCR0_PTM			(1 << 12)
>>   #define sCR0_FB				(1 << 13)
>> +#define sCR0_VMID16EN			(1 << 31)
>>   #define sCR0_BSU_SHIFT			14
>>   #define sCR0_BSU_MASK			0x3
>>
>> @@ -140,6 +141,7 @@
>>   #define ID2_PTFS_4K			(1 << 12)
>>   #define ID2_PTFS_16K			(1 << 13)
>>   #define ID2_PTFS_64K			(1 << 14)
>> +#define ID2_VMID16			(1 << 15)
>>
>>   /* Global TLB invalidation */
>>   #define ARM_SMMU_GR0_TLBIVMID		0x64
>> @@ -189,6 +191,8 @@
>>   #define ARM_SMMU_GR1_CBA2R(n)		(0x800 + ((n) << 2))
>>   #define CBA2R_RW64_32BIT		(0 << 0)
>>   #define CBA2R_RW64_64BIT		(1 << 0)
>> +#define CBA2R_VMID_SHIFT		16
>> +#define CBA2R_VMID_MASK			0xffff
>>
>>   /* Translation context bank */
>>   #define ARM_SMMU_CB_BASE(smmu)		((smmu)->base + ((smmu)->size >> 1))
>> @@ -297,6 +301,7 @@ struct arm_smmu_device {
>>   #define ARM_SMMU_FEAT_TRANS_S2		(1 << 3)
>>   #define ARM_SMMU_FEAT_TRANS_NESTED	(1 << 4)
>>   #define ARM_SMMU_FEAT_TRANS_OPS		(1 << 5)
>> +#define ARM_SMMU_FEAT_VMID16		(1 << 6)
>>   	u32				features;
>>
>>   #define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
>> @@ -736,6 +741,10 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>>   #else
>>   		reg = CBA2R_RW64_32BIT;
>>   #endif
>> +		/* if 16bit VMID supported set VMID in CBA2R */
>> +		if (smmu->features & ARM_SMMU_FEAT_VMID16)
>> +			reg |= ARM_SMMU_CB_VMID(cfg) << CBA2R_VMID_SHIFT;
>> +
>>   		writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBA2R(cfg->cbndx));
>>   	}
>>
>> @@ -751,7 +760,8 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>>   	if (stage1) {
>>   		reg |= (CBAR_S1_BPSHCFG_NSH << CBAR_S1_BPSHCFG_SHIFT) |
>>   			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
>> -	} else {
>> +	} else if (!(smmu->features & ARM_SMMU_FEAT_VMID16)) {
>> +		/*16 bit VMID is not supported set 8 bit VMID here */
>>   		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
>>   	}
>>   	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
>> @@ -1508,6 +1518,9 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
>>   	/* Don't upgrade barriers */
>>   	reg &= ~(sCR0_BSU_MASK << sCR0_BSU_SHIFT);
>>
>> +	if (smmu->features & ARM_SMMU_FEAT_VMID16)
>> +		reg |= sCR0_VMID16EN;
>> +
>>   	/* Push the button */
>>   	__arm_smmu_tlb_sync(smmu);
>>   	writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
>> @@ -1658,6 +1671,10 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
>>   	size = arm_smmu_id_size_to_bits((id >> ID2_OAS_SHIFT) & ID2_OAS_MASK);
>>   	smmu->pa_size = size;
>>
>> +	/* See if 16bit VMID is supported */
>> +	if (id & ID2_VMID16)
>> +		smmu->features = ARM_SMMU_FEAT_VMID16;
>
> This should be |=
>
my bad.
>> +
>>   	/*
>>   	 * What the page table walker can address actually depends on which
>>   	 * descriptor format is in use, but since a) we don't know that yet,
>> @@ -1696,6 +1713,11 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
>>   		dev_notice(smmu->dev, "\tStage-2: %lu-bit IPA -> %lu-bit PA\n",
>>   			   smmu->ipa_size, smmu->pa_size);
>>
>> +	if (smmu->features & ARM_SMMU_FEAT_VMID16)
>> +		dev_notice(smmu->dev, "\t 16 bit VMID Supported.\n");
>> +	else
>> +		dev_notice(smmu->dev, "\t Only 8 bit VMID Supported.\n");
>
> Supporting "only" 8-bit VMIDs is usually plenty ;) In fact, your patch
> doesn't change the allocator, so we'll still use a zero-extended 8-bit
> VMID, so this print is fairly useless.
this will be removed.


>
> Will
>


From catalin.marinas at arm.com  Tue Feb 23 10:10:07 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Tue, 23 Feb 2016 18:10:07 +0000
Subject: [RFC PATCH 05/10] arm64: mm: avoid __pa translations in
 early_fixmap_init
In-Reply-To: <CAKv+Gu_9BLrptH3YvP+8T1hL_xg09UBugnSbOn0eFZ=Sp-oBRA@mail.gmail.com>
References: <1456174472-30028-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456174472-30028-6-git-send-email-ard.biesheuvel@linaro.org>
 <20160223171241.GE4777@e104818-lin.cambridge.arm.com>
 <CAKv+Gu-3VpzkVi8ygorRvW7E4XHqnV019VF0M1KZTy9Fu3yMBA@mail.gmail.com>
 <20160223172625.GG4777@e104818-lin.cambridge.arm.com>
 <CAKv+Gu8dORsacisDdw02cznp-6jh9-WnesZXVYLJv7Qg_VpApA@mail.gmail.com>
 <20160223173253.GH4777@e104818-lin.cambridge.arm.com>
 <CAKv+Gu_9BLrptH3YvP+8T1hL_xg09UBugnSbOn0eFZ=Sp-oBRA@mail.gmail.com>
Message-ID: <20160223181007.GI4777@e104818-lin.cambridge.arm.com>

On Tue, Feb 23, 2016 at 06:43:37PM +0100, Ard Biesheuvel wrote:
> On 23 February 2016 at 18:32, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Tue, Feb 23, 2016 at 06:27:27PM +0100, Ard Biesheuvel wrote:
> >> On 23 February 2016 at 18:26, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> > On Tue, Feb 23, 2016 at 06:16:50PM +0100, Ard Biesheuvel wrote:
> >> >> On 23 February 2016 at 18:12, Catalin Marinas <catalin.marinas at arm.com> wrote:
> >> >> > On Mon, Feb 22, 2016 at 09:54:27PM +0100, Ard Biesheuvel wrote:
> >> >> >> --- a/arch/arm64/mm/mmu.c
> >> >> >> +++ b/arch/arm64/mm/mmu.c
> >> >> >> @@ -679,7 +679,7 @@ void __init early_fixmap_init(void)
> >> >> >>
> >> >> >>       pgd = pgd_offset_k(addr);
> >> >> >>       if (CONFIG_PGTABLE_LEVELS > 3 &&
> >> >> >> -         !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa(bm_pud))) {
> >> >> >> +         !(pgd_none(*pgd) || pgd_page_paddr(*pgd) == __pa_symbol(bm_pud))) {
> >> >> >>               /*
> >> >> >>                * We only end up here if the kernel mapping and the fixmap
> >> >> >>                * share the top level pgd entry, which should only happen on
> >> >> >
> >> >> > Do I miss any patches? The for-next/core branch has a pgd_none(*pgd)
> >> >> > check here, so this patch does not apply.
> >> >> >
> >> >>
> >> >> This is actually based on the kaslr branch, not for-next/core
> >> >>
> >> >> I'm happy to rebase and resend.
> >> >
> >> > That's fine, no need to resend. I plan to move those as well onto
> >> > for-next/core but wanted some more testing first on the initial part.
> >> >
> >> >> I have added some patches for kasan, kvm and smp as well.
> >> >
> >> > Patches related to the __pa clean-up? Or something else?
> >>
> >> No, related to the __pa restriction
> >
> > OK. I'll wait for a while before merging this series to get more reviews
> > and testing. I picked the first patch though (high_memory fix).
> 
> OK, I'll hold off for now. I have enough stuff in flight as it is.
> However, I suppose that you will want to address the performance
> concern at some point

Yes, though we first need to identify how real this concern is.
PHYS_OFFSET was a low-hanging fruit, so worth merging without additional
benchmarking.

The __pa clean-up, while nice, is relatively intrusive and would need
acks from the KVM guys as well. I wouldn't rush into merging it unless
it shows some benefits in benchmarks.

One concern I have is that we still find something in the generic code
doing a virt_to_phys() on kernel image addresses which would render all
this clean-up unnecessary (since most of the changes are not on the
critical path, we do them just to simplify virt_to_phys()).

> If anyone wants to do any benchmarking:
> git://git.linaro.org/people/ard.biesheuvel/linux-arm.git arm64-pa-linear-mapping

Thanks. We'll give this a try in the next few days.

-- 
Catalin


From thierry.reding at gmail.com  Tue Feb 23 10:14:48 2016
From: thierry.reding at gmail.com (Thierry Reding)
Date: Tue, 23 Feb 2016 19:14:48 +0100
Subject: [PATCH v3 00/12] pwm: add support for atomic update
In-Reply-To: <CAD=FV=UvxG3MYD4MKQJqN7W68uMjd-s+FH-e8tkrLCpS0RLmZQ@mail.gmail.com>
References: <20151110173416.GB21727@ulmo>
 <CAD=FV=WL3jYEgVe-m6QcAyQwfJgdX4J5OtKisKwyoKOrTSpEQA@mail.gmail.com>
 <20160125170855.GA10182@ulmo>
 <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
 <20160203145337.GD9650@ulmo>
 <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
 <20160222175929.GA23899@ulmo>
 <CAD=FV=UCErW3EjYRtwt49_ztNR7cyY4U0o4R_dxdomer-Ac2Dg@mail.gmail.com>
 <20160223143859.GA27656@ulmo>
 <CAD=FV=UvxG3MYD4MKQJqN7W68uMjd-s+FH-e8tkrLCpS0RLmZQ@mail.gmail.com>
Message-ID: <20160223181448.GA14754@ulmo.nvidia.com>

On Tue, Feb 23, 2016 at 09:35:48AM -0800, Doug Anderson wrote:
> On Tue, Feb 23, 2016 at 6:38 AM, Thierry Reding <thierry.reding at gmail.com> wrote:
[...]
> > That's not quite what I was thinking. If hardware readout is supported
> > then whatever we report back should be the current hardware state unless
> > we're explicitly asked for something else. If we start mixing the state
> > and legacy APIs this way, we'll get into a situation where drivers that
> > support hardware readout behave differently than drivers that don't.
> >
> > For example: A PWM device that's controlled by a driver that supports
> > hardware readout has a current period of 50000 ns and the firmware set
> > the period to 25000 ns. pwm_get_period() for this PWM device will return
> > 50000 ns. If you reconfigure the PWM to generate a PWM signal with a
> > period of 30000 ns, pwm_get_period() would still return 50000 ns.
> >
> > A driver that doesn't support hardware readout, on the contrary, would
> > return 50000 ns from pwm_get_period() on the first call, but after you
> > have reconfigured it using pwm_config() it will return the new period.
> 
> Ah, right!  I forgot that the existing API will be updated if you've
> reconfigured the period via pwm_config().  Ugh, you're right that's a
> little ugly then.
> 
> So do we define it as:
> 
> pwm_get_state(): always get the hardware state w/ no caching (maybe
> even pwm_get_raw_state() or pwm_get_hw_state())

Caching vs. no caching should be irrelevant here. Unless PWM hardware is
autonomous the current state will always match the hardware state after
the initial hardware readout.

> pwm_get_period(): get the period of the PWM; if the PWM has not yet
> been configured by software this gets the default period (possibly
> specified by the device tree).

No. I think we'll need a different construct for the period defined by
DT or board files. pwm_get_period() is the legacy API to retrieve the
"current" period, even if it was lying a little before the atomic API.

> Is that OK?  That is well defined and doesn't change the existing
> behavior of pwm_get_period().

pwm_get_period() is legacy API and in order to transition to the atomic
API it should be implemented in terms of atomic API. So the goal is to
get everything internally converted to deal with states only, then wrap
the existing API around that concept. pwm_get_period() would become:

	unsigned int pwm_get_period(struct pwm_device *pwm)
	{
		struct pwm_state state;

		pwm_get_state(pwm, &state);

		return state.period;
	}

If we don't do that, we'll never be able to get rid of the legacy API.

> >> > That way if you want to get the current voltage in the regulator-pwm
> >> > driver you'd simply do a pwm_get_state() and compute the voltage from
> >> > the period and duty cycle. If the PWM driver that you happen to use
> >> > doesn't support hardware readout, you'll get an initial output voltage
> >> > of 0, which is as good as any, really.
> >>
> >> Sounds fine to me.  PWM regulator is in charge of calling
> >> pwm_get_state(), which can return 0 (or an error?) if driver (or
> >> underlying hardware) doesn't support hardware readout.  PWM regulator
> >> is in charge of using the resulting period / duty cycle to calculate a
> >> percentage.
> >
> > I'm not sure if pwm_get_state() should ever return an error. For drivers
> > that support hardware readout, the resulting state should match what's
> > programmed to the hardware.
> >
> > But for drivers without hardware readout support pwm_get_state() still
> > makes sense because after a pwm_apply_state() the internal logical state
> > would again match hardware.
> 
> I guess it depends on how you define things.  With my above
> definitions it seems clearest if pwm_get_state() returns an error if
> hardware readout is not supported.  If we call it pwm_get_hw_state()
> it's even clearer that it should return an error.

Again, if we do this, we'll have to keep the legacy API around forever
and keep special-casing atomic vs. legacy API in every user. The goal is
to converge on the atomic API as the standard API in users so that the
legacy API can be removed when all users have been converted.

> > To allow your use-case to work we'd need to deal with two states: the
> > current hardware state and the "initial" state as defined by DT.
> > Unfortunately the PWM specifier in DT is not a full definition, it is
> > more like a partial initial configuration. The problem with that, and
> > I think that's what Mark was originally objecting to, is that it isn't
> > clear when to use the "initial" state and when to use the read hardware
> > state. After the first pwm_apply_state() you wouldn't ever have to use
> > the "initial" state again, because it's the same as the current state
> > (modulo the duty cycle).
> >
> > Also for drivers such as clk-pwm the usefulness of the "initial" state
> > is reduced even more, because it doesn't even need the period specified
> > in DT. It uses only the flags (if at all).
> >
> > Perhaps to avoid this confusion a new type of object, e.g. pwm_args,
> > could be introduced to hold configuration arguments given in the PWM
> > specifier (in DT) or the PWM lookup table (in board files).
> >
> > It would then be the responsibility of the users to deal with that
> > information in a sensible way. In (almost?) all cases I would expect
> > that to be to program the PWM device in the user's ->probe(). In the
> > case of regulator-pwm I'd expect that ->probe() would do something
> > along these lines (error handling excluded):
> >
> >         struct pwm_state state;
> >         struct pwm_args args;
> >         unsigned int ratio;
> >
> >         pwm = pwm_get(...);
> >
> >         pwm_get_state(pwm, &state);
> >         pwm_get_args(pwm, &args);
> >
> >         ratio = (state.duty_cycle * 100) / state.period;
> >
> >         state.duty_cycle = (ratio * args.period) / 100;
> >         state.period = args.period;
> >         state.flags = args.flags;
> >
> >         pwm_apply_state(pwm, &state);
> >
> > The ->set_voltage() implementation would then never need to care about
> > the PWM args, but rather do something like this:
> >
> >         struct pwm_state state;
> >         unsigned int ratio;
> >
> >         pwm_get_state(pwm, &state);
> >
> >         state.duty_cycle = (ratio * state.period) / 100;
> >
> >         pwm_apply_state(pwm, &state);
> >
> > Does that sound about right?
> 
> That should work with one minor problem.  If HW readout isn't
> supported then pwm_get_state() in probe will presumably return 0 for
> the duty cycle.  That means it will change the voltage.  That's in
> contrast to how I think things work today where the voltage isn't
> changed until the first set_voltage() call.  At least the last time I
> tested things get_voltage() would simply report an incorrect value
> until the first set_voltage().  I think existing behavior (reporting
> the wrong value) is better than new behavior (change the value at
> probe).

That's exactly the point. Reporting a wrong value isn't really a good
option. Changing the voltage on boot is the only way to make the logical
state match the hardware state on boot. Chances are that if you don't
have hardware readout support you probably don't care what state your
regulator will be in.

Then again, if we don't support hardware readout, setting up the logical
state with data from DT (or board files) and defaulting the duty cycle
to 0, we end up with exactly what we had before, even with the atomic
API, right? Maybe that's okay, too.

> I'm curious, though.  In your proposal, how does pwm_get_period()
> behave?  To be backward compatible, I'd imagine that even in your
> proposal we'd have the same definition as I had above:
> 
> pwm_get_period(): get the period of the PWM; if the PWM has not yet
> been configured by software this gets the default period (possibly
> specified by the device tree).

It would simply return the logical period of the PWM. For drivers that
support hardware readout it would always match the hardware period, but
for drivers that don't it might be wrong until state is first applied.

> If you have a different definition of pwm_get_period() in your
> proposal, please let me know!  If my definition matches your thoughts
> then I think we can actually just not touch the "set_voltage" call.
> It can always use pwm_get_period() and always use pwm_config() just
> like today.
> 
> ...and if set_voltage() remains untouched then we can solve my probe
> problem by renaming pwm_get_state() to pwm_get_hw_state() and having
> it return an error if HW readout is not supported.  Then we only call
> pwm_get_args() / pwm_apply_state() when we support HW readout.

The problem is that we make the API clumsy to use. If we don't sync the
"initial" state (as defined by DT or board files) to hardware at any
point, then we need to add the pwm_args construct and always stick to
it. I think it weird to have to use the pwm_args.period instead of the
current period.

So we're back to square one, really. That's exactly what Mark brought up
originally.

> Thus, if HW readout:
> 
> * In probe, we read HW state (pwm_get_hw_state) and atomically adjust
> (pwm_apply_state) based on arguments (pwm_get_args).
> 
> * In set_voltage we use pwm_get_period which will return the period we
> applied in pwm_apply_state() and use pwm_config() to change the duty
> cycle.
> 
> 
> If no HW readout, no behavior change at all from today:
> 
> * In probe we don't do anything to change the PWM
> 
> * Upon the first set_voltage we use pwm_get_period() to get the period
> as specified in DT and use pwm_config() to change the duty cycle.
> 
> 
> That seems pretty sane to me.  What do you think?

This has the big disadvantage of having to special case hardware readout
vs. non-hardware readout providers. I think that makes the API really
difficult to use. It requires too many details to be aware of.

I guess this boils down to whether applying the "initial" state on probe
really is problematic.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/8a7a7470/attachment.sig>

From tchalamarla at caviumnetworks.com  Tue Feb 23 10:19:00 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Tue, 23 Feb 2016 10:19:00 -0800
Subject: [PATCH V3] iommu/arm-smmu-v2: Add support for 16 bit VMID
Message-ID: <1456251540-1269-1-git-send-email-tchalamarla@caviumnetworks.com>

ARM-SMMUv2 supports upto 16 bit VMID. This patch enables
16 bit VMID when HW supports.

Changes from V2:
	- Bug fix.
	- Removed not needed prints and comments.

changes from V1:
	- Remove DT Property and enable 16 bit VMID if ID says.

Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
---
 drivers/iommu/arm-smmu.c | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 59ee4b8..247a469 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -93,6 +93,7 @@
 #define sCR0_VMIDPNE			(1 << 11)
 #define sCR0_PTM			(1 << 12)
 #define sCR0_FB				(1 << 13)
+#define sCR0_VMID16EN			(1 << 31)
 #define sCR0_BSU_SHIFT			14
 #define sCR0_BSU_MASK			0x3
 
@@ -140,6 +141,7 @@
 #define ID2_PTFS_4K			(1 << 12)
 #define ID2_PTFS_16K			(1 << 13)
 #define ID2_PTFS_64K			(1 << 14)
+#define ID2_VMID16			(1 << 15)
 
 /* Global TLB invalidation */
 #define ARM_SMMU_GR0_TLBIVMID		0x64
@@ -189,6 +191,8 @@
 #define ARM_SMMU_GR1_CBA2R(n)		(0x800 + ((n) << 2))
 #define CBA2R_RW64_32BIT		(0 << 0)
 #define CBA2R_RW64_64BIT		(1 << 0)
+#define CBA2R_VMID_SHIFT		16
+#define CBA2R_VMID_MASK			0xffff
 
 /* Translation context bank */
 #define ARM_SMMU_CB_BASE(smmu)		((smmu)->base + ((smmu)->size >> 1))
@@ -297,6 +301,7 @@ struct arm_smmu_device {
 #define ARM_SMMU_FEAT_TRANS_S2		(1 << 3)
 #define ARM_SMMU_FEAT_TRANS_NESTED	(1 << 4)
 #define ARM_SMMU_FEAT_TRANS_OPS		(1 << 5)
+#define ARM_SMMU_FEAT_VMID16		(1 << 6)
 	u32				features;
 
 #define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
@@ -726,16 +731,15 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 	cb_base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
 
 	if (smmu->version > ARM_SMMU_V1) {
-		/*
-		 * CBA2R.
-		 * *Must* be initialised before CBAR thanks to VMID16
-		 * architectural oversight affected some implementations.
-		 */
 #ifdef CONFIG_64BIT
 		reg = CBA2R_RW64_64BIT;
 #else
 		reg = CBA2R_RW64_32BIT;
 #endif
+		/* if 16bit VMID supported set VMID in CBA2R */
+		if (smmu->features & ARM_SMMU_FEAT_VMID16)
+			reg |= ARM_SMMU_CB_VMID(cfg) << CBA2R_VMID_SHIFT;
+
 		writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBA2R(cfg->cbndx));
 	}
 
@@ -751,7 +755,8 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 	if (stage1) {
 		reg |= (CBAR_S1_BPSHCFG_NSH << CBAR_S1_BPSHCFG_SHIFT) |
 			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
-	} else {
+	} else if (!(smmu->features & ARM_SMMU_FEAT_VMID16)) {
+		/*16 bit VMID is not supported set 8 bit VMID here */
 		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
 	}
 	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
@@ -1508,6 +1513,9 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
 	/* Don't upgrade barriers */
 	reg &= ~(sCR0_BSU_MASK << sCR0_BSU_SHIFT);
 
+	if (smmu->features & ARM_SMMU_FEAT_VMID16)
+		reg |= sCR0_VMID16EN;
+
 	/* Push the button */
 	__arm_smmu_tlb_sync(smmu);
 	writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
@@ -1658,6 +1666,10 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
 	size = arm_smmu_id_size_to_bits((id >> ID2_OAS_SHIFT) & ID2_OAS_MASK);
 	smmu->pa_size = size;
 
+	/* See if 16bit VMID is supported */
+	if (id & ID2_VMID16)
+		smmu->features |= ARM_SMMU_FEAT_VMID16;
+
 	/*
 	 * What the page table walker can address actually depends on which
 	 * descriptor format is in use, but since a) we don't know that yet,
-- 
2.1.0



From gerald.schaefer at de.ibm.com  Tue Feb 23 10:19:07 2016
From: gerald.schaefer at de.ibm.com (Gerald Schaefer)
Date: Tue, 23 Feb 2016 19:19:07 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe
 also on PowerPC and ARM)
In-Reply-To: <20160223103221.GA1418@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160223103221.GA1418@node.shutemov.name>
Message-ID: <20160223191907.25719a4d@thinkpad>

On Tue, 23 Feb 2016 13:32:21 +0300
"Kirill A. Shutemov" <kirill at shutemov.name> wrote:

> On Fri, Feb 12, 2016 at 06:16:40PM +0100, Gerald Schaefer wrote:
> > On Fri, 12 Feb 2016 16:57:27 +0100
> > Christian Borntraeger <borntraeger at de.ibm.com> wrote:
> > 
> > > > I'm also confused by pmd_none() is equal to !pmd_present() on s390. Hm?
> > > 
> > > Don't know, Gerald or Martin?
> > 
> > The implementation frequently changes depending on how many new bits Martin
> > needs to squeeze out :-)
> > We don't have a _PAGE_PRESENT bit for pmds, so pmd_present() just checks if the
> > entry is not empty. pmd_none() of course does the opposite, it checks if it is
> > empty.
> 
> I still worry about pmd_present(). It looks wrong to me. I wounder if
> patch below makes a difference.
> 
> The theory is that the splitting bit effetely masked bogus pmd_present():
> we had pmd_trans_splitting() in all code path and that prevented mm from
> touching the pmd. Once pmd_trans_splitting() has gone, mm proceed with the
> pmd where it shouldn't and here's a boom.

Well, I don't think pmd_present() == true is bogus for a trans_huge pmd under
splitting, after all there is a page behind the the pmd. Also, if it was
bogus, and it would need to be false, why should it be marked !pmd_present()
only at the pmdp_invalidate() step before the pmd_populate()? It clearly
is pmd_present() before that, on all architectures, and if there was any
problem/race with that, setting it to !pmd_present() at this stage would
only (marginally) reduce the race window.

BTW, PowerPC and Sparc seem to do the same thing in pmdp_invalidate(),
i.e. they do not set pmd_present() == false, only mark it so that it would
not generate a new TLB entry, just like on s390. After all, the function
is called pmdp_invalidate(), and I think the comment in mm/huge_memory.c
before that call is just a little ambiguous in its wording. When it says
"mark the pmd notpresent" it probably means "mark it so that it will not
generate a new TLB entry", which is also what the comment is really about:
prevent huge and small entries in the TLB for the same page at the same
time.

FWIW, and since the ARM arch-list is already on cc, I think there is
an issue with pmdp_invalidate() on ARM, since it also seems to clear
the trans_huge (and formerly trans_splitting) bit, which actually makes
the pmd !pmd_present(), but it violates the other requirement from the
comment:
"the pmd_trans_huge and pmd_trans_splitting must remain set at all times
on the pmd until the split is complete for this pmd"

> 
> I'm not sure that the patch is correct wrt yound/old pmds and I have no
> way to test it...
> 
> diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
> index 64ead8091248..2eeb17ab68ac 100644
> --- a/arch/s390/include/asm/pgtable.h
> +++ b/arch/s390/include/asm/pgtable.h
> @@ -490,7 +490,7 @@ static inline int pud_bad(pud_t pud)
> 
>  static inline int pmd_present(pmd_t pmd)
>  {
> -	return pmd_val(pmd) != _SEGMENT_ENTRY_INVALID;
> +	return !(pmd_val(pmd) & _SEGMENT_ENTRY_INVALID);
>  }
> 
>  static inline int pmd_none(pmd_t pmd)

No, that would not work well with young rw and ro pmds. We do now
have an extra free bit in the pmd on s390, after the removal of the
splitting bit, so we could try to implement pmd_present() with that
sw bit, but that would also require several not-so-trivial changes
to the other code in arch/s390/include/asm/pgtable.h.

I'll check with Martin, maybe it is actually trivial, then we can
do a quick test it to rule that one out.



From lorenzo.pieralisi at arm.com  Tue Feb 23 10:22:39 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Tue, 23 Feb 2016 18:22:39 +0000
Subject: [PATCH] drivers: perf: arm: implement CPU_PM notifier
Message-ID: <1456251759-24768-1-git-send-email-lorenzo.pieralisi@arm.com>

When a CPU is suspended (either through suspend-to-RAM or CPUidle),
its PMU registers content can be lost, which means that counters
registers values that were initialized on power down entry have to be
reprogrammed on power-up to make sure the counters set-up is preserved
(ie on power-up registers take the reset values on Cold or Warm reset,
which can be architecturally UNKNOWN).

To guarantee seamless profiling conditions across a core power down
this patch adds a CPU PM notifier to ARM pmus, that upon CPU PM
entry/exit from low-power states saves/restores the pmu registers
set-up (by using the ARM perf API), so that the power-down/up cycle does
not affect the perf behaviour (apart from a black-out period between
power-up/down CPU PM notifications that is unavoidable).

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
Cc: Ashwin Chaugule <ashwin.chaugule at linaro.org>
Cc: Will Deacon <will.deacon at arm.com>
Cc: Kevin Hilman <khilman at baylibre.com>
Cc: Sudeep Holla <sudeep.holla at arm.com>
Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
Cc: Mark Rutland <mark.rutland at arm.com>
---
 drivers/perf/arm_pmu.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/perf/arm_pmu.h |  1 +
 2 files changed, 96 insertions(+)

diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 166637f..12317a9 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -13,6 +13,7 @@
 
 #include <linux/bitmap.h>
 #include <linux/cpumask.h>
+#include <linux/cpu_pm.h>
 #include <linux/export.h>
 #include <linux/kernel.h>
 #include <linux/of_device.h>
@@ -710,6 +711,93 @@ static int cpu_pmu_notify(struct notifier_block *b, unsigned long action,
 	return NOTIFY_OK;
 }
 
+#ifdef CONFIG_CPU_PM
+static void cpu_pm_pmu_setup(struct arm_pmu *armpmu, unsigned long cmd)
+{
+	struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
+	struct perf_event *event;
+	int idx;
+
+	for (idx = 0; idx < armpmu->num_events; idx++) {
+		/*
+		 * If the counter is not used skip it, there is no
+		 * need of stopping/restarting it.
+		 */
+		if (!test_bit(idx, hw_events->used_mask))
+			continue;
+
+		event = hw_events->events[idx];
+
+		switch (cmd) {
+		case CPU_PM_ENTER:
+			/*
+			 * Stop and update the counter
+			 */
+			armpmu_stop(event, PERF_EF_UPDATE);
+			break;
+		case CPU_PM_EXIT:
+		case CPU_PM_ENTER_FAILED:
+			 /* Restore and enable the counter */
+			armpmu_start(event, PERF_EF_RELOAD);
+			break;
+		default:
+			break;
+		}
+	}
+}
+
+static int cpu_pm_pmu_notify(struct notifier_block *b, unsigned long cmd,
+			     void *v)
+{
+	struct arm_pmu *armpmu = container_of(b, struct arm_pmu, cpu_pm_nb);
+	struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
+	int enabled = bitmap_weight(hw_events->used_mask, armpmu->num_events);
+
+	if (!cpumask_test_cpu(smp_processor_id(), &armpmu->supported_cpus))
+		return NOTIFY_DONE;
+
+	/*
+	 * Always reset the PMU registers on power-up even if
+	 * there are no events running.
+	 */
+	if (cmd == CPU_PM_EXIT && armpmu->reset)
+		armpmu->reset(armpmu);
+
+	if (!enabled)
+		return NOTIFY_OK;
+
+	switch (cmd) {
+	case CPU_PM_ENTER:
+		armpmu->stop(armpmu);
+		cpu_pm_pmu_setup(armpmu, cmd);
+		break;
+	case CPU_PM_EXIT:
+		cpu_pm_pmu_setup(armpmu, cmd);
+	case CPU_PM_ENTER_FAILED:
+		armpmu->start(armpmu);
+		break;
+	default:
+		return NOTIFY_DONE;
+	}
+
+	return NOTIFY_OK;
+}
+
+static int cpu_pm_pmu_register(struct arm_pmu *cpu_pmu)
+{
+	cpu_pmu->cpu_pm_nb.notifier_call = cpu_pm_pmu_notify;
+	return cpu_pm_register_notifier(&cpu_pmu->cpu_pm_nb);
+}
+
+static void cpu_pm_pmu_unregister(struct arm_pmu *cpu_pmu)
+{
+	cpu_pm_unregister_notifier(&cpu_pmu->cpu_pm_nb);
+}
+#else
+static inline int cpu_pm_pmu_register(struct arm_pmu *cpu_pmu) { return 0; }
+static inline void cpu_pm_pmu_unregister(struct arm_pmu *cpu_pmu) { }
+#endif
+
 static int cpu_pmu_init(struct arm_pmu *cpu_pmu)
 {
 	int err;
@@ -725,6 +813,10 @@ static int cpu_pmu_init(struct arm_pmu *cpu_pmu)
 	if (err)
 		goto out_hw_events;
 
+	err = cpu_pm_pmu_register(cpu_pmu);
+	if (err)
+		goto out_unregister;
+
 	for_each_possible_cpu(cpu) {
 		struct pmu_hw_events *events = per_cpu_ptr(cpu_hw_events, cpu);
 		raw_spin_lock_init(&events->pmu_lock);
@@ -746,6 +838,8 @@ static int cpu_pmu_init(struct arm_pmu *cpu_pmu)
 
 	return 0;
 
+out_unregister:
+	unregister_cpu_notifier(&cpu_pmu->hotplug_nb);
 out_hw_events:
 	free_percpu(cpu_hw_events);
 	return err;
@@ -753,6 +847,7 @@ out_hw_events:
 
 static void cpu_pmu_destroy(struct arm_pmu *cpu_pmu)
 {
+	cpu_pm_pmu_unregister(cpu_pmu);
 	unregister_cpu_notifier(&cpu_pmu->hotplug_nb);
 	free_percpu(cpu_pmu->hw_events);
 }
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 83b5e34..9ffa316 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -107,6 +107,7 @@ struct arm_pmu {
 	struct platform_device	*plat_device;
 	struct pmu_hw_events	__percpu *hw_events;
 	struct notifier_block	hotplug_nb;
+	struct notifier_block	cpu_pm_nb;
 };
 
 #define to_arm_pmu(p) (container_of(p, struct arm_pmu, pmu))
-- 
2.5.1



From paul at pwsan.com  Tue Feb 23 10:28:36 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Tue, 23 Feb 2016 18:28:36 +0000 (UTC)
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <56CC490F.3040301@ti.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com> <56BACCDB.2070507@ti.com>
 <alpine.DEB.2.02.1602111921090.20757@utopia.booyaka.com>
 <56BD8091.4090007@ti.com> <56BE1454.3030002@ti.com> <56C5D377.50901@ti.com>
 <56CAA82D.6000507@ti.com>
 <alpine.DEB.2.02.1602220631300.3418@utopia.booyaka.com>
 <56CADB23.8020202@ti.com> <56CC490F.3040301@ti.com>
Message-ID: <alpine.DEB.2.02.1602231827300.27173@utopia.booyaka.com>

Kishon

On Tue, 23 Feb 2016, Kishon Vijay Abraham I wrote:

> On Monday 22 February 2016 03:25 PM, Kishon Vijay Abraham I wrote:
> > On Monday 22 February 2016 12:01 PM, Paul Walmsley wrote:
> >> On Mon, 22 Feb 2016, Kishon Vijay Abraham I wrote:
> >>> On Thursday 18 February 2016 07:51 PM, Sekhar Nori wrote:
> >>>> On Friday 12 February 2016 10:50 PM, Suman Anna wrote:
> >>>>> Will you be following up with above suggestion since Kishon is gonna be out?
> >>>>
> >>>> Alright, noticed this action for me :) Went through the thread, and 
> >>>> looks like this is what we want to see?
> >>>>
> >>>> Thanks,
> >>>> Sekhar
> >>>>
> >>>> ---8<---
> >>>> From e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19 Mon Sep 17 00:00:00 2001
> >>>> Message-Id: <e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19.1455803758.git.nsekhar at ti.com>
> >>>> From: Sekhar Nori <nsekhar at ti.com>
> >>>> Date: Thu, 18 Feb 2016 16:49:56 +0530
> >>>> Subject: [PATCH 1/1] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS
> >>>>
> >>>> Add a custom reset handler for DRA7x PCIeSS. This
> >>>> handler is required to deassert PCIe hardreset lines
> >>>> after they have been asserted.
> >>>>
> >>>> This enables the PCIe driver to access registers after
> >>>> PCIeSS has been runtime enabled without having to
> >>>> deassert hardreset lines itself.
> >>>>
> >>>> With this patch applied, used lspci to make sure
> >>>> connected PCIe device enumerates on DRA74x and DRA72x
> >>>> EVMs.
> >>>>
> >>>> Signed-off-by: Sekhar Nori <nsekhar at ti.com>
> >>>> ---
> >>>> Applies to tag for-v4.6/omap-hwmod-a of Paul W's tree.
> >>>>
> >>>>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++
> >>>>  1 file changed, 23 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> >>>> index b61355e2a771..252b74633e31 100644
> >>>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> >>>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> >>>> @@ -1526,8 +1526,31 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
> >>>>   *
> >>>>   */
> >>>>  
> >>>> +/*
> >>>> + * As noted in documentation for _reset() in omap_hwmod.c, the stock reset
> >>>> + * functionality of OMAP HWMOD layer does not deassert the hardreset lines
> >>>> + * associated with an IP automatically leaving the driver to handle that
> >>>> + * by itself. This does not work for PCIeSS which needs the reset lines
> >>>> + * deasserted for the driver to start accessing registers.
> >>>> + *
> >>>> + * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset
> >>>> + * lines after asserting them.
> >>>> + */
> >>>> +static int dra7xx_pciess_reset(struct omap_hwmod *oh)
> >>>> +{
> >>>> +	int i;
> >>>> +
> >>>> +	for (i = 0; i < oh->rst_lines_cnt; i++) {
> >>>> +		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);
> >>>> +		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);
> >>>> +	}
> >>>> +
> >>>> +	return 0;
> >>>> +}
> >>>> +
> >>>>  static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {
> >>>>  	.name	= "pcie",
> >>>> +	.reset	= dra7xx_pciess_reset,
> >>>>  };
> >>>
> >>> Thanks for the patch.
> >>
> >> Could you please test the bind/unbind functionality just to make sure it 
> >> works?
> > 
> > The pci-dra7xx driver neither expose the bind/unbind sysfs entry nor can be
> > built as module.
> > 
> > However I hacked the pci-dra7xx driver to be built as module [and reverted
> > Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe error
> > and driver unbind")] and I don't see an abort when the PCI registers are
> > accessed after rmmod/modprobe cycle (that was the issue that Sekhar's patch
> > tried to solve). However PCI as such doesn't work after rmmod/modprobe cycle
> > [1], but this is a different issue most likely in PCIe core and has to debugged.
> > 
> > In summary, there are other issues in PCI across rmmod/modprobe cycle but the
> > reset of pci-dra7xx happens fine with this patch.
> 
> Do you expect any other testing from me?

No I think that's sufficient for the time being, thanks - but, two 
questions:

1. Can I add your Tested-by: ?

2. Are you going to follow up with these PCIe core issues with the PCIe 
core developers?


- Paul


From khilman at baylibre.com  Tue Feb 23 10:29:02 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Tue, 23 Feb 2016 10:29:02 -0800
Subject: [PATCH v5 00/15] arm64: kernel: Add support for
 hibernate/suspend-to-disk
In-Reply-To: <1455637767-31561-1-git-send-email-james.morse@arm.com> (James
 Morse's message of "Tue, 16 Feb 2016 15:49:12 +0000")
References: <1455637767-31561-1-git-send-email-james.morse@arm.com>
Message-ID: <7h37sjuvpt.fsf@baylibre.com>

James Morse <james.morse at arm.com> writes:

> This version of hibernate is based on v4.5-rc4, with the contents of the arm64
> for-next/pgtable branch and Ard's v6sub1 "arm64: split linear and kernel
> mappings" series [0]. The patches shared with kexec still come from v13 [1].

FYI... in addition to juno-r2, I've now tested this version on the
Mediatek mt8173-evb platform as well, using an exteral MMC card as swap,
and everything worked well.

Tested-by: Kevin Hilman <khilman at baylibre.com>

Kevin


From khilman at baylibre.com  Tue Feb 23 10:32:04 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Tue, 23 Feb 2016 10:32:04 -0800
Subject: [PATCH] ARM64: dts: Mediatek: mt8173-evb: fix access MMC fail
 issue
In-Reply-To: <56CC1E0E.4050400@gmail.com> (Matthias Brugger's message of "Tue, 
 23 Feb 2016 09:53:34 +0100")
References: <1455861643-24307-1-git-send-email-eddie.huang@mediatek.com>
 <7h37skw9jd.fsf@baylibre.com> <56CC1E0E.4050400@gmail.com>
Message-ID: <7hlh6bth0b.fsf@baylibre.com>

Matthias Brugger <matthias.bgg at gmail.com> writes:

> On 23/02/16 01:32, Kevin Hilman wrote:
>> Eddie Huang <eddie.huang at mediatek.com> writes:
>>
>>> MT8173 E1 chip has one bug that if turn off USB power domain, vcore
>>> power will also be off, thus cause modules using vcore power domain
>>> fail, like MMC. The E1 chip only found on MT8173-evb board and this
>>> board only has E1 chip, so implement this as a board specific
>>> workaround.
>>>
>>> Pwrapper use vcore power, so add pwrapper using USB power domain to
>>> keep USB power domain not to zero and disabled.
>>>
>>> Signed-off-by: Eddie Huang <eddie.huang at mediatek.com>
>>
>> Tested-by: Kevin Hilman <khilman at baylibre.com>
>>
>
> I send the patch in a pull request yesterday, so I won't be able to
> add your tag.

No worries.  Was on vacation, so couldn't test sooner.

> Thanks for testing and reporting this issue!

You're welcome,

Kevin


From Yuval.Mintz at qlogic.com  Tue Feb 23 10:33:10 2016
From: Yuval.Mintz at qlogic.com (Yuval Mintz)
Date: Tue, 23 Feb 2016 18:33:10 +0000
Subject: [PATCH] bnx2x: add a separate GENEVE Kconfig symbol
In-Reply-To: <1456223774-1383513-1-git-send-email-arnd@arndb.de>
References: <1456223774-1383513-1-git-send-email-arnd@arndb.de>
Message-ID: <CO2PR11MB0088CC09F328C0CFE10187BF97A40@CO2PR11MB0088.namprd11.prod.outlook.com>

> When CONFIG_GENEVE is built as a loadable module, and bnx2x is built-in,
> we get this link error:

> drivers/net/built-in.o: In function `bnx2x_open':
> :(.text+0x33322): undefined reference to `geneve_get_rx_port'
> drivers/net/built-in.o: In function `bnx2x_sp_rtnl_task':
> :(.text+0x3e632): undefined reference to `geneve_get_rx_port'

> This avoids the problem by adding a separate Kconfig symbol named
> CONFIG_BNX2X_GENEVE that is only enabled when the code is
> reachable from the driver.

> This is the same trick that BNX2X does for VXLAN support, and
> is similar to how I40E handles both.

> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 883ce97d25b0 ("bnx2x: Add Geneve inner-RSS support")

Ouch. Thanks for fixing this one; I tried avoiding this solution
since I don't think there's any reason to encumber the config
file with needless options [I.e., what's the gain in the ability to
disable a single offloaded protocol on a single network driver?],
but obviously, I botched the job.

BTW, if you want to handle this exactly like vxlan, you might
consider using `defined(CONFIG_BNX2X_GENEVE)' instead of
`IS_ENABLED(CONFIG_BNX2X_GENEVE)'  [It not a tristate].
But that's truly insignificant.

Acked-By: Yuval Mintz <Yuval.Mintz at qlogic.com>

From mark.rutland at arm.com  Tue Feb 23 10:37:27 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Tue, 23 Feb 2016 18:37:27 +0000
Subject: [PATCH v5 01/11] drm/hisilicon: Add device tree binding for
 hi6220 display subsystem
In-Reply-To: <1456196431-19923-2-git-send-email-xinliang.liu@linaro.org>
References: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
 <1456196431-19923-2-git-send-email-xinliang.liu@linaro.org>
Message-ID: <20160223183726.GA10246@leverpostej>

On Tue, Feb 23, 2016 at 11:00:21AM +0800, Xinliang Liu wrote:
> Add ADE display controller binding doc.
> Add DesignWare DSI Host Controller v1.20a binding doc.
> 
> v5:
> - Remove endpoint unit address of dsi output port.
> - Add "hisilicon,noc-syscon" property for ADE NOC QoS syscon.
> - Add "resets" property for ADE reset.
> v4:
> - Describe more specific of clocks and ports.
> - Fix indentation.
> v3:
> - Make ade as the drm master node.
> - Use assigned-clocks to set clock rate.
> - Use ports to connect display relavant nodes.
> v2:
> - Move dt binding docs to bindings/display/hisilicon directory.
> 
> Signed-off-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
> Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
> ---
>  .../bindings/display/hisilicon/dw-dsi.txt          | 72 ++++++++++++++++++++++
>  .../bindings/display/hisilicon/hisi-ade.txt        | 64 +++++++++++++++++++
>  2 files changed, 136 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>  create mode 100644 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
> new file mode 100644
> index 000000000000..0d234b5e19af
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
> @@ -0,0 +1,72 @@
> +Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
> +
> +A DSI Host Controller resides in the middle of display controller and external
> +HDMI converter or panel.
> +
> +Required properties:
> +- compatible: value should be "hisilicon,hi6220-dsi".
> +- reg: physical base address and length of dsi controller's registers.
> +- clocks: the clocks needed.
> +- clock-names: the name of the clocks.

You _must_ specify the precise set of clock names you expect here.

Per the example, you seem to expect "pclk_dsi".

Is that the name given in the DSI controller manual? Or is it just
"pclk"? It's already specific to the DSI controller...

> diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
> new file mode 100644
> index 000000000000..c1844b3ff878
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
> @@ -0,0 +1,64 @@
> +Device-Tree bindings for hisilicon ADE display controller driver
> +
> +ADE (Advanced Display Engine) is the display controller which grab image
> +data from memory, do composition, do post image processing, generate RGB
> +timing stream and transfer to DSI.
> +
> +Required properties:
> +- compatible: value should be "hisilicon,hi6220-ade".
> +- reg: physical base address and length of the ADE controller's registers.
> +  Value should be "<0x0 0xf4100000 0x0 0x7800>".

Get rid of the "Value should be ... " part. It is nonsensical to
describe this in the binding. Just describe what this is with relation
to _this_ IP block.

> +- reg-names: name of physical base. Value should be "ade_base".

That obviously doesn't apply to *-names propertiesm which must all be
specified in the binding (they're local to the device rather than
remote).

> +- hisilicon,noc-syscon: ADE NOC QoS syscon. Value should be "<&medianoc_ade>"
> +- resets: The ADE reset controller node. Value should be "<&media_ctrl
> +  MEDIA_ADE>".

Likewise.

> +- interrupt: the ldi vblank interrupt number used.
> +- clocks: the clocks needed. Three clocks are used in ADE driver:
> +  ADE core clock, value should be "<&media_ctrl HI6220_ADE_CORE>";
> +  ADE pixel clok, value should be "<&media_ctrl HI6220_ADE_PIX_SRC>";
> +  media NOC QoS clock, value should be "<&media_ctrl HI6220_CODEC_JPEG>".
> +- clock-names: the name of the clocks. Values should be "clk_ade_core",
> +  "clk_codec_jpeg" and "clk_ade_pix".

Likewise, don't specify the value.

Jsut define clocks in terms of clock-names, e.g.

- clocks: a list of phandle + clock-specifier pairs, one for each entry
  in clock-names.
- clock-names: should contain:
  * "clk_ade_core" for the ADE ciore clock
  * ...
  * ...

> +- assigned-clocks: clocks to be assigned rate.
> +- assigned-clock-rates: clock rates which are assigned to assigned-clocks.
> +  The rate of <&media_ctrl HI6220_ADE_CORE> could be "360000000" or
> +  "180000000";
> +  The rate of <&media_ctrl HI6220_CODEC_JPEG> could be less than "1440000000".

Is this strictly necessary? Why can the druiver not configure this?

Does this have to match some pre-existing boot-time configuration?

Thanks,
Mark.


From peter at korsgaard.com  Tue Feb 23 10:39:10 2016
From: peter at korsgaard.com (Peter Korsgaard)
Date: Tue, 23 Feb 2016 19:39:10 +0100
Subject: [linux-sunxi] [PATCH] ARM: dts: sun4i: Enable USB DRC on
 Hyundai-a7hd
In-Reply-To: <56CC7278.6060901@redhat.com> (Hans de Goede's message of "Tue,
 23 Feb 2016 15:53:44 +0100")
References: <1455656404-31191-1-git-send-email-peter@korsgaard.com>
 <56CC7278.6060901@redhat.com>
Message-ID: <87si0j6zld.fsf@dell.be.48ers.dk>

>>>>> "Hans" == Hans de Goede <hdegoede at redhat.com> writes:

 > Hi,
 > On 02/16/2016 10:00 PM, Peter Korsgaard wrote:
 >> Enable the OTG USB controller on the A7HD.
 >> 
 >> Signed-off-by: Peter Korsgaard <peter at korsgaard.com>

 > Patch looks good to me:

 > Reviewed-by: Hans de Goede <hdegoede at redhat.com>

Thanks, but you already sent your review-by on the 17th - And Maxime
said he applied it (but he apparently hasn't pushed his tree yet).

-- 
Venlig hilsen,
Peter Korsgaard 


From dianders at google.com  Tue Feb 23 10:42:03 2016
From: dianders at google.com (Doug Anderson)
Date: Tue, 23 Feb 2016 10:42:03 -0800
Subject: [PATCH v3 00/12] pwm: add support for atomic update
In-Reply-To: <20160223181448.GA14754@ulmo.nvidia.com>
References: <20151110173416.GB21727@ulmo>
 <CAD=FV=WL3jYEgVe-m6QcAyQwfJgdX4J5OtKisKwyoKOrTSpEQA@mail.gmail.com>
 <20160125170855.GA10182@ulmo>
 <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
 <20160203145337.GD9650@ulmo>
 <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
 <20160222175929.GA23899@ulmo>
 <CAD=FV=UCErW3EjYRtwt49_ztNR7cyY4U0o4R_dxdomer-Ac2Dg@mail.gmail.com>
 <20160223143859.GA27656@ulmo>
 <CAD=FV=UvxG3MYD4MKQJqN7W68uMjd-s+FH-e8tkrLCpS0RLmZQ@mail.gmail.com>
 <20160223181448.GA14754@ulmo.nvidia.com>
Message-ID: <CAD=FV=VM3cOQ0HqwLANBw9MVBCyFTrSyPe_dGzgPucuMUEWRKA@mail.gmail.com>

Thierry,

On Tue, Feb 23, 2016 at 10:14 AM, Thierry Reding
<thierry.reding at gmail.com> wrote:
>> pwm_get_period(): get the period of the PWM; if the PWM has not yet
>> been configured by software this gets the default period (possibly
>> specified by the device tree).
>
> No. I think we'll need a different construct for the period defined by
> DT or board files. pwm_get_period() is the legacy API to retrieve the
> "current" period, even if it was lying a little before the atomic API.

Ah, got it.  I think I missed that you considered pwm_get_period()
legacy and that you eventually wanted to get rid of it.  OK, then what
you say makes sense.


>> That should work with one minor problem.  If HW readout isn't
>> supported then pwm_get_state() in probe will presumably return 0 for
>> the duty cycle.  That means it will change the voltage.  That's in
>> contrast to how I think things work today where the voltage isn't
>> changed until the first set_voltage() call.  At least the last time I
>> tested things get_voltage() would simply report an incorrect value
>> until the first set_voltage().  I think existing behavior (reporting
>> the wrong value) is better than new behavior (change the value at
>> probe).
>
> That's exactly the point. Reporting a wrong value isn't really a good
> option. Changing the voltage on boot is the only way to make the logical
> state match the hardware state on boot. Chances are that if you don't
> have hardware readout support you probably don't care what state your
> regulator will be in.
>
> Then again, if we don't support hardware readout, setting up the logical
> state with data from DT (or board files) and defaulting the duty cycle
> to 0, we end up with exactly what we had before, even with the atomic
> API, right? Maybe that's okay, too.

IMHO this is a change in behavior that will break existing users.
Anyone using a PWM regulator will suddenly find their voltage changing
at bootup.  Certainly today all users of the PWM regulator don't seem
to mind (apparently) the the voltage is reported incorrectly at bootup
but I bet they'd mind if the voltage suddenly started changing for
them at bootup.

It seems better to preserve existing behavior and print a warning that
the voltage will be reported incorrectly until HW Readout is
supported.

Of course, we're only talking about two real users in mainline here:
Rockchip boards and the "stih407-family".  If we just fix both of
those to support HW Readout before landing the change then I'm fine
with doing what you say.


>> ...and if set_voltage() remains untouched then we can solve my probe
>> problem by renaming pwm_get_state() to pwm_get_hw_state() and having
>> it return an error if HW readout is not supported.  Then we only call
>> pwm_get_args() / pwm_apply_state() when we support HW readout.
>
> The problem is that we make the API clumsy to use. If we don't sync the
> "initial" state (as defined by DT or board files) to hardware at any
> point, then we need to add the pwm_args construct and always stick to
> it. I think it weird to have to use the pwm_args.period instead of the
> current period.
>
> So we're back to square one, really. That's exactly what Mark brought up
> originally.

I had missed the part where you wanted to deprecate pwm_get_period().
Thus my points here aren't really valid.

In my mind the old API was perfectly fine (and actually quite clean /
simple to use) except in the special case of avoiding the PWM
regulator glitches.  With that mindset I think my previous email make
sense.  However, this is your subsystem to maintain and if you think
moving everyone to a new atomic API makes more sense then you're in
the best position to make that decision.  :)


-Doug


From maxime.ripard at free-electrons.com  Tue Feb 23 10:45:13 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Tue, 23 Feb 2016 10:45:13 -0800
Subject: [PATCH 10/11] arm64: dts: add Allwinner A64 SoC .dtsi
In-Reply-To: <56B8630B.8060608@arm.com>
References: <1454348370-3816-1-git-send-email-andre.przywara@arm.com>
 <1454348370-3816-11-git-send-email-andre.przywara@arm.com>
 <20160205085026.GA1139@lukather> <56B8630B.8060608@arm.com>
Message-ID: <20160223184513.GI19169@lukather>

Hi,

Sorry for the late reply,

On Mon, Feb 08, 2016 at 09:42:35AM +0000, Andre Przywara wrote:
> >> +	memory {
> >> +		device_type = "memory";
> >> +		reg = <0x40000000 0>;
> >> +	};
> > 
> > I'm guessing u-boot fixes that, can we just remove it entirely?
> 
> Don't know, can we? I found it nice to have it in here to give people at
> the least the idea of where DRAM starts and also making it clear that a
> bootloader is expected to patch this (and having a node already makes
> patching easier).

Well, U-Boot seems to deal with it just fine. The only SoCs where we
do it are SoCs where had to use the Allwinner bootloader.

I guess I don't really care, but if it's to indicate where the RAM is
mapped, we'd be better off by putting the max memory size there
instead of 0, and a comment saying that the bootloader is supposed to
patch this node.

> >> +	timer {
> >> +		compatible = "arm,armv8-timer";
> >> +		interrupts = <GIC_PPI 13
> >> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> >> +			     <GIC_PPI 14
> >> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> >> +			     <GIC_PPI 11
> >> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> >> +			     <GIC_PPI 10
> >> +			(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> >> +	};
> >> +
> >> +	clocks {
> >> +		#address-cells = <1>;
> >> +		#size-cells = <1>;
> >> +		ranges;
> >> +
> >> +		osc24M: osc24M_clk {
> >> +			#clock-cells = <0>;
> >> +			compatible = "fixed-clock";
> >> +			clock-frequency = <24000000>;
> >> +			clock-output-names = "osc24M";
> >> +		};
> >> +
> >> +		osc32k: osc32k_clk {
> >> +			#clock-cells = <0>;
> >> +			compatible = "fixed-clock";
> >> +			clock-frequency = <32768>;
> >> +			clock-output-names = "osc32k";
> >> +		};
> >> +
> >> +		pll1: clk at 01c20000 {
> >> +			#clock-cells = <0>;
> >> +			compatible = "allwinner,sun8i-a23-pll1-clk";
> >> +			reg = <0x01c20000 0x4>;
> >> +			clocks = <&osc24M>;
> >> +			clock-output-names = "pll1";
> >> +		};
> >> +
> >> +		pll6: clk at 01c20028 {
> >> +			#clock-cells = <1>;
> >> +			compatible = "allwinner,sun6i-a31-pll6-clk";
> >> +			reg = <0x01c20028 0x4>;
> >> +			clocks = <&osc24M>;
> >> +			clock-output-names = "pll6", "pll6x2";
> > 
> > The output names have changed, and it doesn't take an argument
> > anymore.
> 
> Would be happy to adapt to this, but we should sort this approach out
> (see the other mail).

Yeah.

> 
> >> +		};
> >> +
> >> +		pll6d2: pll6d2_clk {
> >> +			#clock-cells = <0>;
> >> +			compatible = "fixed-factor-clock";
> >> +			clock-div = <2>;
> >> +			clock-mult = <1>;
> >> +			clocks = <&pll6 0>;
> >> +			clock-output-names = "pll6d2";
> >> +		};
> >> +
> >> +		/* dummy clock until pll6 can be reused */
> >> +		pll8: pll8_clk {
> >> +			#clock-cells = <0>;
> >> +			compatible = "fixed-clock";
> >> +			clock-frequency = <1>;
> >> +			clock-output-names = "pll8";
> >> +		};
> >> +
> >> +		cpu: cpu_clk at 01c20050 {
> >> +			#clock-cells = <0>;
> >> +			compatible = "allwinner,sun4i-a10-cpu-clk";
> >> +			reg = <0x01c20050 0x4>;
> >> +			clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
> >> +			clock-output-names = "cpu";
> >> +			critical-clocks = <0>;
> >> +		};
> >> +
> >> +		axi: axi_clk at 01c20050 {
> >> +			#clock-cells = <0>;
> >> +			compatible = "allwinner,sun4i-a10-axi-clk";
> >> +			reg = <0x01c20050 0x4>;
> >> +			clocks = <&cpu>;
> >> +			clock-output-names = "axi";
> >> +		};
> >> +
> >> +		ahb1: ahb1_clk at 01c20054 {
> >> +			#clock-cells = <0>;
> >> +			compatible = "allwinner,sun6i-a31-ahb1-clk";
> >> +			reg = <0x01c20054 0x4>;
> >> +			clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
> >> +			clock-output-names = "ahb1";
> >> +		};
> >> +
> >> +		ahb2: ahb2_clk at 01c2005c {
> >> +			#clock-cells = <0>;
> >> +			compatible = "allwinner,sun8i-h3-ahb2-clk";
> >> +			reg = <0x01c2005c 0x4>;
> >> +			clocks = <&ahb1>, <&pll6d2>;
> >> +			clock-output-names = "ahb2";
> >> +		};
> >> +
> >> +		apb1: apb1_clk at 01c20054 {
> >> +			#clock-cells = <0>;
> >> +			compatible = "allwinner,sun4i-a10-apb0-clk";
> >> +			reg = <0x01c20054 0x4>;
> >> +			clocks = <&ahb1>;
> >> +			clock-output-names = "apb1";
> >> +		};
> >> +
> >> +		apb2: apb2_clk at 01c20058 {
> >> +			#clock-cells = <0>;
> >> +			compatible = "allwinner,sun4i-a10-apb1-clk";
> >> +			reg = <0x01c20058 0x4>;
> >> +			clocks = <&osc32k>, <&osc24M>, <&pll6 1>, <&pll6 1>;
> >> +			clock-output-names = "apb2";
> >> +		};
> >> +
> >> +		bus_gates: clk at 01c20060 {
> >> +			#clock-cells = <1>;
> >> +			compatible = "allwinner,a64-bus-gates-clk",
> >> +				     "allwinner,sunxi-multi-bus-gates-clk";
> >> +			reg = <0x01c20060 0x14>;
> >> +			ahb1_parent {
> >> +				clocks = <&ahb1>;
> >> +				clock-indices = <1>, <5>,
> >> +						<6>, <8>,
> >> +						<9>, <10>,
> >> +						<13>, <14>,
> >> +						<18>, <19>,
> >> +						<20>, <21>,
> >> +						<23>, <24>,
> >> +						<25>, <28>,
> >> +						<32>, <35>,
> >> +						<36>, <37>,
> >> +						<40>, <43>,
> >> +						<44>, <52>,
> >> +						<53>, <54>,
> >> +						<135>;
> >> +				clock-output-names = "bus_mipidsi", "bus_ce",
> >> +						"bus_dma", "bus_mmc0",
> >> +						"bus_mmc1", "bus_mmc2",
> >> +						"bus_nand", "bus_sdram",
> >> +						"bus_ts", "bus_hstimer",
> >> +						"bus_spi0", "bus_spi1",
> >> +						"bus_otg", "bus_otg_ehci0",
> >> +						"bus_ehci0", "bus_otg_ohci0",
> >> +						"bus_ve", "bus_lcd0",
> >> +						"bus_lcd1", "bus_deint",
> >> +						"bus_csi", "bus_hdmi",
> >> +						"bus_de", "bus_gpu",
> >> +						"bus_msgbox", "bus_spinlock",
> >> +						"bus_dbg";
> >> +			};
> >> +			ahb2_parent {
> >> +				clocks = <&ahb2>;
> >> +				clock-indices = <17>, <29>;
> >> +				clock-output-names = "bus_gmac", "bus_ohci0";
> >> +			};
> >> +			apb1_parent {
> >> +				clocks = <&apb1>;
> >> +				clock-indices = <64>, <65>,
> >> +						<69>, <72>,
> >> +						<76>, <77>,
> >> +						<78>;
> >> +				clock-output-names = "bus_codec", "bus_spdif",
> >> +						"bus_pio", "bus_ths",
> >> +						"bus_i2s0", "bus_i2s1",
> >> +						"bus_i2s2";
> >> +			};
> >> +			abp2_parent {
> >> +				clocks = <&apb2>;
> >> +				clock-indices = <96>, <97>,
> >> +						<98>, <101>,
> >> +						<112>, <113>,
> >> +						<114>, <115>,
> >> +						<116>;
> >> +				clock-output-names = "bus_i2c0", "bus_i2c1",
> >> +						"bus_i2c2", "bus_scr",
> >> +						"bus_uart0", "bus_uart1",
> >> +						"bus_uart2", "bus_uart3",
> >> +						"bus_uart4";
> >> +			};
> >> +		};
> > 
> > As I've already told you I'm not really fond of this one, for two main
> > topics.
> > 
> > The first one is about the DT bindings itself which is quite exotic,
> > especially the fact that you define clocks using clocks, clock-indices
> > and clock-output-names in nodes that are not the one referred to by
> > consumer, which goes against both the clock bindings documentation and
> > the usage.
> 
> You are right in one point: it is not documented. I just see that I
> forgot to update the bindings doc and describe this behaviour there.
> 
> But I don't see an issue with abstracting the clock provider's internal
> details by referring to the parent node and use the DT's natural tree
> structure to properly represent these clock gates. I cannot read
> anything in clock-bindings.txt that would prevent this.
> 
> Happy to hear from DT maintainers about it.
> 
> > The second one is pretty much the same one than for the discussion we
> > had about pinctrl. There is SoCs where we simply don't have that
> > information, or at least are not really sure about what to put where
> > (namely, the A83t). In such a case, we would knowingly put invalid
> > information in the DT, which is already quite bad in itself.
> 
> And in your case we would put knowingly invalid information into the kernel?
> So what is wrong with just _not_ putting this information until we know
> it? With my patch you would just enumerate the gates we know the parents
> of so far.

And what happens when you simply don't have that information?

> Once we learn about the other gates, we add them. If we don't
> know the parent, we probably can't use it anyway, I guess.
> So we do as we do with other new features: updated DTs provide new
> functionality.

The issue is broader than that. It basically boils down to that: What
is your fixing strategy in case one of the clocks you put there
doesn't belong to the right parent?

> And also: this is about A64, not A83t.

If the driver is generic, it should not be just about the A64,
otherwise it's simply not generic.

> > The worst part is, when we will identify issues and fix them
> > (hopefully), there will be no way to fix the current DT users.
> 
> But if we have a broken DT out there where a feature never worked or had
> bugs, we _can_ fix it. Interested users will upgrade their DT and are
> able to use the new feature or run without bugs now. This mimics the
> approach when we add features: users update. However if users are happy
> with the current feature set or are not affected by the bug, they can
> use the older DT.

So basically, you just tell "if you want to be as bug free and
featureful as possible, always keep your DT as up to date as
possible". Isn't that the exact same situation than before that whole
DT ABI debate?

> Also from my point of view it is much harder to provide an updated
> kernel to people, since every distribution would need to pick up the
> changes and provide updates to their users.

Do you know a single linux distribution that doesn't update the kernel
to the latest stable kernel version?

> 
> > And it just became a pain to maintain in the long run.
> 
> How so?
> 
> > On the opposite side, having something like the H3 bus gates driver
> > address all these concerns and is easily extensible, which is why we
> > ended up merging it.
> 
> Speaking of this driver: I really dislike that it hardcodes Soc specific
> information into the kernel. I consider this bad style. The clock gates
> are a rather generic functionality (one bit per gate), and we provide
> the SoC specific part (mapping names and bit numbers) already in the DT.
> So with the parent relation in the code we hide some information from
> the DT which clearly belongs there, also ending up with having something
> in the kernel and something in the DT.

It's true to some extent, but it's also something that is not critical
in any way: a typo'd name or a missing index will not affect the
system in any way. A wrong parent relationship might completely crash
the system if the actual parent is not enabled and you try to access
the device.

> Also this requires to add support for each and every SoC explicitly in
> the kernel.

Which is something that you already have to do for any other drivers.

> Also please keep in mind that the DT is not just for Linux: why should
> other OS developers hard code the same information over and over again
> when we could have it once for everybody in the DT?

Since the "other OS developers" don't care about our bindings anyway and
make up their own, is that really something we should care about?

> I think we should stop with supporting each and every SoC explicitly in
> the kernel and go for more generic drivers, that use DTs to describe
> each SoC.
> That way we can eventually reach the point where we have (at least)
> basic functionality for a new SoC in existing(!) kernels - like from a
> LTS style distribution kernel.

It's an argument that has been used since basically the switch to the
device tree, and it never happened, because there's basically no such
thing as a generic driver.

Let's take the example of the A64: we had a driver that was common to
all the SoCs so far for the MMC and MMC clocks, which was working fine
for all of them, so I guess it would be elligible to your definition
of generic. Comes the A64, with its modified phase behaviour, and a
MMC clock factor. Is it really something you expect to support without
a single change to the MMC driver and clocks driver?

This also goes against the whole policy of the clock framework for the
past couple of years to put less information in the DT. Mike asked
repeatedly to switch to a single clock controller node, and have a
driver that is registering everything, instead of exposing each and
every clock in the DT.

It's something we never took the time to do because we knew that we
could switch to it at any point in time. If you want to really have a
stable DT for the A64, then please use that scheme so that we never
have to switch to it in the future and break the ABI.

> New SoCs would just come with their DTs as part of their firmware, as
> it's the case with many arm64 boards out there at the moment. As long as
> they don't have fundamentally new IP blocks (for the basic
> functionality), that could just work out of the box.

Who would provide that firmware? The vendor? Whose binding were never
ever reviewed?

> >> +		pio: pinctrl at 01c20800 {
> >> +			compatible = "allwinner,a64-pinctrl";
> >> +			reg = <0x01c20800 0x400>;
> >> +			interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
> >> +				     <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
> >> +				     <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
> >> +			clocks = <&bus_gates 69>;
> >> +			gpio-controller;
> >> +			#gpio-cells = <3>;
> >> +			interrupt-controller;
> >> +			#interrupt-cells = <2>;
> >> +
> >> +			uart0_pins_a: uart0 at 0 {
> >> +				allwinner,pins = "PB8", "PB9";
> >> +				allwinner,function = "uart0";
> >> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> >> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> >> +			};
> >> +
> >> +			uart0_pins_b: uart0 at 1 {
> >> +				allwinner,pins = "PF2", "PF3";
> >> +				allwinner,function = "uart0";
> >> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> >> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> >> +			};
> >> +
> >> +			uart1_pins: uart1 at 0 {
> >> +				allwinner,pins = "PG6", "PG7", "PG8", "PG9";
> >> +				allwinner,function = "uart1";
> >> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> >> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> >> +			};
> >> +
> >> +			uart2_pins: uart2 at 0 {
> >> +				allwinner,pins = "PB0", "PB1", "PB2", "PB3";
> >> +				allwinner,function = "uart2";
> >> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> >> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> >> +			};
> >> +
> >> +			uart3_pins_a: uart3 at 0 {
> >> +				allwinner,pins = "PD0", "PD1";
> >> +				allwinner,function = "uart3";
> >> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> >> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> >> +			};
> >> +
> >> +			uart3_pins_b: uart3 at 1 {
> >> +				allwinner,pins = "PH4", "PH5", "PH6", "PH7";
> >> +				allwinner,function = "uart3";
> >> +				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> >> +				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> >> +			};
> > 
> > You have several options for all these controllers, which is why we
> > have the _a or _b suffices.
> > 
> > Usually, the uart pins we had were only using RX and TX, I guess you
> > could add a separate node for the RTS / CTS pins if some board want to
> > use them.
> 
> Makes sense. Do you want the RTS/CTS pins in a separate child node or
> another variant (like uart3_pins_b_hwhs) with all four pins in addition
> to the two-pin version?

I think we can have RTS/CTS alone in a separate node, just like we
already do for the SPI and its chip select, where each board can then
pick the combination it uses, without duplicating pins definitions.

Thanks (and sorry again for the slow answer),
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160223/8cdfca44/attachment-0001.sig>

From will.deacon at arm.com  Tue Feb 23 10:47:14 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Feb 2016 18:47:14 +0000
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160223191907.25719a4d@thinkpad>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160223103221.GA1418@node.shutemov.name>
 <20160223191907.25719a4d@thinkpad>
Message-ID: <20160223184658.GA27281@arm.com>

[adding Steve, since he worked on THP for 32-bit ARM]

On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> On Tue, 23 Feb 2016 13:32:21 +0300
> "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> > The theory is that the splitting bit effetely masked bogus pmd_present():
> > we had pmd_trans_splitting() in all code path and that prevented mm from
> > touching the pmd. Once pmd_trans_splitting() has gone, mm proceed with the
> > pmd where it shouldn't and here's a boom.
> 
> Well, I don't think pmd_present() == true is bogus for a trans_huge pmd under
> splitting, after all there is a page behind the the pmd. Also, if it was
> bogus, and it would need to be false, why should it be marked !pmd_present()
> only at the pmdp_invalidate() step before the pmd_populate()? It clearly
> is pmd_present() before that, on all architectures, and if there was any
> problem/race with that, setting it to !pmd_present() at this stage would
> only (marginally) reduce the race window.
> 
> BTW, PowerPC and Sparc seem to do the same thing in pmdp_invalidate(),
> i.e. they do not set pmd_present() == false, only mark it so that it would
> not generate a new TLB entry, just like on s390. After all, the function
> is called pmdp_invalidate(), and I think the comment in mm/huge_memory.c
> before that call is just a little ambiguous in its wording. When it says
> "mark the pmd notpresent" it probably means "mark it so that it will not
> generate a new TLB entry", which is also what the comment is really about:
> prevent huge and small entries in the TLB for the same page at the same
> time.
> 
> FWIW, and since the ARM arch-list is already on cc, I think there is
> an issue with pmdp_invalidate() on ARM, since it also seems to clear
> the trans_huge (and formerly trans_splitting) bit, which actually makes
> the pmd !pmd_present(), but it violates the other requirement from the
> comment:
> "the pmd_trans_huge and pmd_trans_splitting must remain set at all times
> on the pmd until the split is complete for this pmd"

I've only been testing this for arm64 (where I'm yet to see a problem),
but we use the generic pmdp_invalidate implementation from
mm/pgtable-generic.c there. On arm64, pmd_trans_huge will return true
after pmd_mknotpresent. On arm, it does look to be buggy, since it nukes
the entire entry... Steve?

Will


From chris.brandt at renesas.com  Tue Feb 23 11:15:36 2016
From: chris.brandt at renesas.com (Chris Brandt)
Date: Tue, 23 Feb 2016 14:15:36 -0500
Subject: [PATCH v2] ARM: Allow MULTIPLATFORM to select XIP
In-Reply-To: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
References: <1455816310-11308-1-git-send-email-chris.brandt@renesas.com>
Message-ID: <1456254936-28875-1-git-send-email-chris.brandt@renesas.com>

As devices move to multiplatform only, you should not be restricted from
selecting XIP. Whether it makes sense or not depends on how you configure
the rest of the kernel (as in, removing individual platforms).
While there is no easy way to guarantee success when XIP is selected,
the MULTIPLATFORM_XIP_CAPABLE attribute at least provides a means to
show what devices have been known to boot (when configured correctly).

Signed-off-by: Chris Brandt <chris.brandt at renesas.com>
---
v2:
* Added MULTIPLATFORM_XIP_CAPABLE because there is no good way to
restrict that only 1 device can be selected at one time, so this at
least narrows down the the exposure of XIP in multiplatform.
---
 arch/arm/Kconfig               | 7 +++++--
 arch/arm/mach-shmobile/Kconfig | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d67f1aa..0d838ed 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -226,6 +226,9 @@ config NEED_RET_TO_USER
 config ARCH_MTD_XIP
 	bool
 
+config MULTIPLATFORM_XIP_CAPABLE
+	bool
+
 config VECTORS_BASE
 	hex
 	default 0xffff0000 if MMU || CPU_HIGH_VECTOR
@@ -327,7 +330,7 @@ config ARCH_MULTIPLATFORM
 	depends on MMU
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select ARM_HAS_SG_CHAIN
-	select ARM_PATCH_PHYS_VIRT
+	select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL
 	select AUTO_ZRELADDR
 	select CLKSRC_OF
 	select COMMON_CLK
@@ -1918,7 +1921,7 @@ endchoice
 
 config XIP_KERNEL
 	bool "Kernel Execute-In-Place from ROM"
-	depends on !ARM_LPAE && !ARCH_MULTIPLATFORM
+	depends on (!ARM_LPAE && !ARCH_MULTIPLATFORM) || (!ARM_LPAE && MULTIPLATFORM_XIP_CAPABLE)
 	help
 	  Execute-In-Place allows the kernel to run from non-volatile storage
 	  directly addressable by the CPU, such as NOR flash. This saves RAM
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index cd5f171..b27661e 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -57,6 +57,7 @@ config ARCH_R7S72100
 	bool "RZ/A1H (R7S72100)"
 	select PM_GENERIC_DOMAINS if PM
 	select SYS_SUPPORTS_SH_MTU2
+	select MULTIPLATFORM_XIP_CAPABLE
 
 config ARCH_R8A73A4
 	bool "R-Mobile APE6 (R8A73A40)"
-- 
1.9.1




From robh at kernel.org  Tue Feb 23 11:19:34 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 23 Feb 2016 13:19:34 -0600
Subject: [PATCH 3/4] ASoC: pxa: add binding for pxa2xx-ac97 audio complex
In-Reply-To: <1455979079-9030-3-git-send-email-robert.jarzmik@free.fr>
References: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
 <1455979079-9030-3-git-send-email-robert.jarzmik@free.fr>
Message-ID: <20160223191934.GA29262@rob-hp-laptop>

On Sat, Feb 20, 2016 at 03:37:58PM +0100, Robert Jarzmik wrote:
> This adds a binding for the Marvell PXA audio complex, available in
> pxa2xx and pxa3xx variants.
> 
> Signed-off-by: Robert Jarzmik <robert.jarzmik at free.fr>
> ---
>  .../bindings/sound/marvell,pxa2xx-ac97.txt         | 25 ++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
> 
> diff --git a/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt b/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
> new file mode 100644
> index 000000000000..b3f2882d9c7d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/marvell,pxa2xx-ac97.txt
> @@ -0,0 +1,25 @@
> +Marvell PXA2xx audio complex
> +
> +This descriptions matches the AC97 controller found in pxa2xx and pxa3xx series.
> +
> +Required properties:
> +  - compatible: "marvell,pxa2xx-ac97"
> +  - reg: device MMIO address space
> +  - interrupts: single interrupt generated by AC97 IP
> +  - clocks: input clock of the AC97 IP, refer to clock-bindings.txt
> +
> +Optional properties:
> +  - pinctrl-names, pinctrl-0: refer to pinctrl-bindings.txt
> +  - reset-gpio: gpio used for AC97 reset, refer to gpio.txt

reset-gpios

> +
> +Example:
> +	ac97: sound at 40500000 {
> +	      	compatible = "marvell,pxa2xx-ac97";
> +		reg = < 0x40500000 0x1000 >;
> +		interrupts = <14>;
> +		reset-gpio = <&gpio 113 GPIO_ACTIVE_HIGH>;
> +		#sound-dai-cells = <1>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = < &pmux_ac97_default >;
> +		status = "okay";

No clocks prop, yet required.

> +	};
> -- 
> 2.1.4
> 


From kirill at shutemov.name  Tue Feb 23 11:33:45 2016
From: kirill at shutemov.name (Kirill A. Shutemov)
Date: Tue, 23 Feb 2016 22:33:45 +0300
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160223191907.25719a4d@thinkpad>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160223103221.GA1418@node.shutemov.name>
 <20160223191907.25719a4d@thinkpad>
Message-ID: <20160223193345.GC21820@node.shutemov.name>

On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> I'll check with Martin, maybe it is actually trivial, then we can
> do a quick test it to rule that one out.

Oh. I found a bug in __split_huge_pmd_locked(). Although, not sure if it's
_the_ bug.

pmdp_invalidate() is called for the wrong address :-/
I guess that can be destructive on the architecture, right?

Could you check this?

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 1c317b85ea7d..4246bc70e55a 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2865,7 +2865,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
 	pgtable = pgtable_trans_huge_withdraw(mm, pmd);
 	pmd_populate(mm, &_pmd, pgtable);
 
-	for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
+	for (i = 0; i < HPAGE_PMD_NR; i++) {
 		pte_t entry, *pte;
 		/*
 		 * Note that NUMA hinting access restrictions are not
@@ -2886,9 +2886,9 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
 		}
 		if (dirty)
 			SetPageDirty(page + i);
-		pte = pte_offset_map(&_pmd, haddr);
+		pte = pte_offset_map(&_pmd, haddr + i * PAGE_SIZE);
 		BUG_ON(!pte_none(*pte));
-		set_pte_at(mm, haddr, pte, entry);
+		set_pte_at(mm, haddr + i * PAGE_SIZE, pte, entry);
 		atomic_inc(&page[i]._mapcount);
 		pte_unmap(pte);
 	}
@@ -2938,7 +2938,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
 	pmd_populate(mm, pmd, pgtable);
 
 	if (freeze) {
-		for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
+		for (i = 0; i < HPAGE_PMD_NR; i++) {
 			page_remove_rmap(page + i, false);
 			put_page(page + i);
 		}
-- 
 Kirill A. Shutemov


From robh at kernel.org  Tue Feb 23 11:36:51 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 23 Feb 2016 13:36:51 -0600
Subject: [PATCH v11 08/10] dt, numa: Add NUMA dt binding implementation.
In-Reply-To: <1455930799-5371-9-git-send-email-ddaney.cavm@gmail.com>
References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
 <1455930799-5371-9-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <20160223193651.GA8491@rob-hp-laptop>

On Fri, Feb 19, 2016 at 05:13:17PM -0800, David Daney wrote:
> From: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
> 
> ADD device tree node parsing for NUMA topology using device
> "numa-node-id" property distance-map.

I still want an adequate explanation why NUMA setup cannot be done with 
an unflattened tree. PowerPC manages to do that and should have a 
similar init flow being memblock based, so I would expect arm64 can too.

Rob



From stefan at agner.ch  Tue Feb 23 11:36:49 2016
From: stefan at agner.ch (Stefan Agner)
Date: Tue, 23 Feb 2016 11:36:49 -0800
Subject: [PATCH] ARM: dts: vf610-zii-dev: Add ZII development board.
In-Reply-To: <1456084314-9871-1-git-send-email-andrew@lunn.ch>
References: <1456084314-9871-1-git-send-email-andrew@lunn.ch>
Message-ID: <c67c93683d9440bd050386df0e200881@agner.ch>

Hi Andrew,

Some comments below:

On 2016-02-21 11:51, Andrew Lunn wrote:
> From: Cory Tusar <cory.tusar at pid1solutions.com>
> 
> This commit adds support for Rev. B of a Zodiac Inflight Innovations
> development board, mainly intended for DSA and ARINC 429 development
> work.
> 
> Signed-off-by: Cory Tusar <cory.tusar at pid1solutions.com>
> Signed-off-by: Andrew Lunn <andrew at lunn.ch>
> ---
>  arch/arm/boot/dts/Makefile                |   3 +-
>  arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 683 ++++++++++++++++++++++++++++++
>  2 files changed, 685 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index a4a6d70e8b26..47c4c2ff41de 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -372,7 +372,8 @@ dtb-$(CONFIG_SOC_VF610) += \
>  	vf610m4-colibri.dtb \
>  	vf610-cosmic.dtb \
>  	vf610m4-cosmic.dtb \
> -	vf610-twr.dtb
> +	vf610-twr.dtb \
> +	vf610-zii-dev-rev-b.dtb
>  dtb-$(CONFIG_ARCH_MXS) += \
>  	imx23-evk.dtb \
>  	imx23-olinuxino.dtb \
> diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> new file mode 100644
> index 000000000000..fafe0039ebce
> --- /dev/null
> +++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> @@ -0,0 +1,683 @@
> +/*
> + * Copyright 2013 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */

I recently changed the license of most Vybrid device trees to the new
dual license. Is it possible to change this device tree too?

> +
> +/dts-v1/;
> +#include "vf610.dtsi"
> +
> +/ {
> +	model = "ZII VF610 Development Board, Rev B";
> +	compatible = "zii,vf610dev-b", "zii,vf610dev", "fsl,vf610";
> +
> +	chosen {
> +		bootargs = "console=ttyLP0,115200n8";
> +		stdout-path = &uart0;

Is bootargs necessary?

For the stdout-path I would recommend to use the advanced format:
stdout-path = "serial0:115200n8";

> +	};
> +
> +	memory {
> +		reg = <0x80000000 0x8000000>;
> +	};
> +
> +	gpio-leds {
> +		compatible = "gpio-leds";
> +		pinctrl-0 = <&pinctrl_leds_debug>;
> +		pinctrl-names = "default";
> +
> +		debug_1 {
> +			label = "zii:green:debug1";
> +			gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
> +		};
> +	};
> +
> +	mdio-mux {
> +		compatible = "mdio-mux-gpio";
> +		pinctrl-0 = <&pinctrl_mdio_mux>;
> +		pinctrl-names = "default";
> +		gpios = <&gpio0 8  GPIO_ACTIVE_HIGH
> +			 &gpio0 9  GPIO_ACTIVE_HIGH
> +			 &gpio0 24 GPIO_ACTIVE_HIGH
> +			 &gpio0 25 GPIO_ACTIVE_HIGH>;
> +		mdio-parent-bus = <&mdio1>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		mdio_mux_1: mdio at 1 {
> +			reg = <1>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;

Since there are no child nodes the #address- and #size-cells properties
are not necessary.

> +		};
> +
> +		mdio_mux_2: mdio at 2 {
> +			reg = <2>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		mdio_mux_4: mdio at 4 {
> +			reg = <4>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +
> +		mdio_mux_8: mdio at 8 {
> +			reg = <8>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};
> +	};
> +
> +	dsa at 0 {
> +		compatible = "marvell,dsa";
> +		#address-cells = <2>;
> +		#size-cells = <0>;
> +
> +		dsa,ethernet = <&fec1>;
> +		dsa,mii-bus = <&mdio_mux_1>;
> +
> +		/* 6352 - Primary - 7 ports */
> +		switch0: switch at 2 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x00 0>;
> +			eeprom-length = <512>;
> +
> +			port at 0 {
> +				reg = <0>;
> +				label = "lan0";
> +			};
> +
> +			port at 1 {
> +				reg = <1>;
> +				label = "lan1";
> +			};
> +
> +			port at 2 {
> +				reg = <2>;
> +				label = "lan2";
> +			};
> +
> +			switch0port5: port at 5 {
> +				reg = <5>;
> +				label = "dsa";
> +				phy-mode = "rgmii-txid";
> +				link = <&switch1port6
> +					&switch2port9>;
> +				fixed-link {
> +					speed = <1000>;
> +					full-duplex;
> +				};
> +			};
> +
> +			port at 6 {
> +				reg = <6>;
> +				label = "cpu";
> +				fixed-link {
> +					speed = <100>;
> +					full-duplex;
> +				};
> +			};
> +
> +		};
> +
> +		/* 6352 - Secondary - 7 ports */
> +		switch1: switch at 0 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x00 1>;
> +			eeprom-length = <512>;
> +			mii-bus = <&mdio_mux_2>;
> +
> +			port at 0 {
> +				reg = <0>;
> +				label = "lan3";
> +			};
> +
> +			port at 1 {
> +				reg = <1>;
> +				label = "lan4";
> +			};
> +
> +			port at 2 {
> +				reg = <2>;
> +				label = "lan5";
> +			};
> +
> +			switch1port5: port at 5 {
> +				reg = <5>;
> +				label = "dsa";
> +				link = <&switch2port9>;
> +				phy-mode = "rgmii-txid";
> +				fixed-link {
> +					speed = <1000>;
> +					full-duplex;
> +				};
> +			};
> +
> +			switch1port6: port at 6 {
> +				reg = <6>;
> +				label = "dsa";
> +				phy-mode = "rgmii-txid";
> +				link = <&switch0port5>;
> +				fixed-link {
> +					speed = <1000>;
> +					full-duplex;
> +				};
> +			};
> +		};
> +
> +		/* 6185 - 10 ports */
> +		switch2: switch at 6 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0x00 2>;
> +			mii-bus = <&mdio_mux_4>;
> +
> +			port at 0 {
> +				reg = <0>;
> +				label = "lan6";
> +			};
> +
> +			port at 1 {
> +				reg = <1>;
> +				label = "lan7";
> +			};
> +
> +			port at 2 {
> +				reg = <2>;
> +				label = "lan8";
> +			};
> +
> +			port at 3 {
> +				reg = <3>;
> +				label = "optical3";
> +				fixed-link {
> +					speed = <1000>;
> +					full-duplex;
> +					link-gpios = <&gpio6 2
> +						      GPIO_ACTIVE_HIGH>;
> +				};
> +			};
> +
> +			port at 4 {
> +				reg = <4>;
> +				label = "optical4";
> +				fixed-link {
> +					speed = <1000>;
> +					full-duplex;
> +					link-gpios = <&gpio6 3
> +						      GPIO_ACTIVE_HIGH>;
> +				};
> +			};
> +
> +			switch2port9: port at 9 {
> +				reg = <9>;
> +				label = "dsa";
> +				phy-mode = "rgmii-txid";
> +				link = <&switch1port5
> +					&switch0port5>;
> +				fixed-link {
> +					speed = <1000>;
> +					full-duplex;
> +				};
> +			};
> +		};
> +	};
> +
> +	audio_ext: mclk-osc {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <24576000>;
> +	};

This seems not to be used anywhere. Maybe needs to be assigned to the
clks node?

> +
> +	enet_ext: eth-osc {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <50000000>;
> +	};

Same here...

> +
> +	reg_3p3v: regulator at 0 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "3P3V";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		regulator-always-on;
> +	};

Do not use the address format (@0) in node name if the regulator is not
part of a bus.

Use regulator-3p3v as node name.


> +
> +	reg_vcc_3v3_mcu: regulator at 1 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_3v3_mcu";
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +	};
> +
> +	usb0_vbus: regulator at 2 {
> +		compatible = "regulator-fixed";
> +		pinctrl-0 = <&pinctrl_usb_vbus>;
> +		regulator-name = "usb_vbus";
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		enable-active-high;
> +		regulator-always-on;
> +		regulator-boot-on;
> +		gpio = <&gpio0 6 0>;
> +	};
> +};
> +
> +&fec0 {
> +	phy-mode = "rmii";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_fec0>;
> +	status = "okay";
> +};
> +
> +&fec1 {
> +	phy-mode = "rmii";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_fec1>;
> +	status = "okay";
> +
> +	fixed-link {
> +		   speed = <100>;
> +		   full-duplex;
> +	};
> +
> +	mdio1: mdio {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "okay";
> +	};
> +};
> +
> +&adc0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_adc0_ad5>;
> +	vref-supply = <&reg_vcc_3v3_mcu>;
> +	status = "okay";
> +};
> +
> +&edma0 {
> +	status = "okay";
> +};
> +
> +&esdhc1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_esdhc1>;
> +	bus-width = <4>;
> +	status = "okay";
> +};
> +
> +&i2c0 {
> +	clock-frequency = <100000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c0>;
> +	status = "okay";
> +
> +	gpio5: pca9505 at 20 {
> +		compatible = "nxp,pca9554";
> +		reg = <0x20>;
> +		gpio-controller;
> +		#gpio-cells = <2>;
> +
> +	};
> +
> +	gpio6: pca9505 at 22 {
> +		compatible = "nxp,pca9554";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_pca9554_opt>;
> +		reg = <0x22>;
> +		interrupt-parent = <&gpio1>;
> +		interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> +	};

Hm, any reason why one of this is a gpio-controller while the other
isn't?

> +
> +	lm75 at 48 {
> +		compatible = "national,lm75";
> +		reg = <0x48>;
> +	};
> +
> +	at24c04 at 50 {
> +		compatible = "atmel,24c04";
> +		reg = <0x50>;
> +	};
> +
> +	at24c04 at 52 {
> +		compatible = "atmel,24c04";
> +		reg = <0x52>;
> +	};
> +
> +	ds1682 at 6b {
> +		compatible = "dallas,ds1682";
> +		reg = <0x6b>;
> +	};
> +};
> +
> +&i2c1 {
> +	clock-frequency = <100000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c1>;
> +	status = "okay";
> +};
> +
> +&i2c2 {
> +	clock-frequency = <100000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c2>;
> +	status = "okay";
> +
> +	tca9548 at 70 {
> +		compatible = "nxp,pca9548";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		reg = <0x70>;
> +		reset-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
> +
> +		i2c2_0: i2c at 0 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0>;
> +
> +			sfp1: at24c04 at 50 {
> +				compatible = "atmel,24c02";
> +				reg = <0x50>;
> +			};
> +		};
> +
> +		i2c2_1: i2c at 1 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <1>;
> +
> +			sfp2: at24c04 at 50 {
> +				compatible = "atmel,24c02";
> +				reg = <0x50>;
> +			};
> +		};
> +
> +		i2c2_2: i2c at 2 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <2>;
> +
> +			sfp3: at24c04 at 50 {
> +				compatible = "atmel,24c02";
> +				reg = <0x50>;
> +			};
> +		};
> +
> +		i2c2_3:	 i2c at 3 {

There is an extra space between the colon and i2c at 3...

> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <3>;
> +
> +			sfp4: at24c04 at 50 {
> +				compatible = "atmel,24c02";
> +				reg = <0x50>;
> +			};
> +
> +		};
> +
> +		i2c2_4: i2c at 4 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <4>;
> +		};
> +	};
> +};
> +
> +&i2c3 {
> +	clock-frequency = <100000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c3>;
> +	status = "okay";
> +};
> +
> +&iomuxc {

We normally put the iomuxc node at the very end.

> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c_mux_reset>;
> +
> +	vf610-zii {
> +		pinctrl_usb_vbus: pinctrl-usb-vbus {
> +			fsl,pins = <
> +				VF610_PAD_PTA16__GPIO_6	0x31c2
> +			>;
> +		};
> +
> +		pinctrl_i2c_mux_reset: pinctrl-i2c-mux-reset {
> +			fsl,pins = <
> +				 VF610_PAD_PTE14__GPIO_119	0x31c2
> +				 >;
> +		};
> +
> +		pinctrl_adc0_ad5: adc0ad5grp {
> +			fsl,pins = <
> +				VF610_PAD_PTC30__ADC0_SE5	0x00a1
> +			>;
> +		};
> +
> +		pinctrl_esdhc1: esdhc1grp {
> +			fsl,pins = <
> +				VF610_PAD_PTA24__ESDHC1_CLK	0x31ef
> +				VF610_PAD_PTA25__ESDHC1_CMD	0x31ef
> +				VF610_PAD_PTA26__ESDHC1_DAT0	0x31ef
> +				VF610_PAD_PTA27__ESDHC1_DAT1	0x31ef
> +				VF610_PAD_PTA28__ESDHC1_DATA2	0x31ef
> +				VF610_PAD_PTA29__ESDHC1_DAT3	0x31ef
> +				VF610_PAD_PTA7__GPIO_134	0x219d
> +			>;
> +		};
> +
> +		pinctrl_fec1: fec1grp {
> +			fsl,pins = <
> +				VF610_PAD_PTA6__RMII_CLKIN		0x30d1
> +				VF610_PAD_PTC9__ENET_RMII1_MDC		0x30d2
> +				VF610_PAD_PTC10__ENET_RMII1_MDIO	0x30d3
> +				VF610_PAD_PTC11__ENET_RMII1_CRS		0x30d1
> +				VF610_PAD_PTC12__ENET_RMII1_RXD1	0x30d1
> +				VF610_PAD_PTC13__ENET_RMII1_RXD0	0x30d1
> +				VF610_PAD_PTC14__ENET_RMII1_RXER	0x30d1
> +				VF610_PAD_PTC15__ENET_RMII1_TXD1	0x30d2
> +				VF610_PAD_PTC16__ENET_RMII1_TXD0	0x30d2
> +				VF610_PAD_PTC17__ENET_RMII1_TXEN	0x30d2
> +			>;
> +		};
> +
> +		pinctrl_i2c0: i2c0grp {
> +			fsl,pins = <
> +				VF610_PAD_PTB14__I2C0_SCL	0x37ff
> +				VF610_PAD_PTB15__I2C0_SDA	0x37ff
> +			>;
> +		};
> +
> +		pinctrl_i2c1: i2c1grp {
> +			fsl,pins = <
> +				VF610_PAD_PTB16__I2C1_SCL	0x37ff
> +				VF610_PAD_PTB17__I2C1_SDA	0x37ff
> +			>;
> +		};
> +
> +		pinctrl_i2c2: i2c2grp {
> +			fsl,pins = <
> +				VF610_PAD_PTA22__I2C2_SCL	0x37ff
> +				VF610_PAD_PTA23__I2C2_SDA	0x37ff
> +			>;
> +		};
> +
> +		pinctrl_i2c3: i2c3grp {
> +			fsl,pins = <
> +				VF610_PAD_PTA30__I2C3_SCL	0x37ff
> +				VF610_PAD_PTA31__I2C3_SDA	0x37ff
> +			>;
> +		};
> +
> +		pinctrl_pwm0: pwm0grp {
> +			fsl,pins = <
> +				VF610_PAD_PTB0__FTM0_CH0	0x1582
> +				VF610_PAD_PTB1__FTM0_CH1	0x1582
> +				VF610_PAD_PTB2__FTM0_CH2	0x1582
> +				VF610_PAD_PTB3__FTM0_CH3	0x1582
> +			>;
> +		};
> +
> +		pinctrl_uart0: uart0grp {
> +			fsl,pins = <
> +				VF610_PAD_PTB10__UART0_TX	0x21a2
> +				VF610_PAD_PTB11__UART0_RX	0x21a1
> +			>;
> +		};
> +
> +		pinctrl_uart1: uart1grp {
> +			fsl,pins = <
> +				VF610_PAD_PTB23__UART1_TX	0x21a2
> +				VF610_PAD_PTB24__UART1_RX	0x21a1
> +			>;
> +		};
> +
> +		pinctrl_uart2: uart2grp {
> +			fsl,pins = <
> +				VF610_PAD_PTD0__UART2_TX	0x21a2
> +				VF610_PAD_PTD1__UART2_RX	0x21a1
> +			>;
> +		};
> +
> +		pinctrl_qspi0: qspi0grp {
> +			fsl,pins = <
> +				VF610_PAD_PTD7__QSPI0_B_QSCK	0x31c3
> +				VF610_PAD_PTD8__QSPI0_B_CS0	0x31ff
> +				VF610_PAD_PTD9__QSPI0_B_DATA3	0x31c3
> +				VF610_PAD_PTD10__QSPI0_B_DATA2	0x31c3
> +				VF610_PAD_PTD11__QSPI0_B_DATA1	0x31c3
> +				VF610_PAD_PTD12__QSPI0_B_DATA0	0x31c3
> +			>;
> +		};
> +
> +		pinctrl_usb0_host: usb0-host-grp {
> +			fsl,pins = <
> +				VF610_PAD_PTD6__GPIO_85		0x0062
> +			>;
> +		};
> +		pinctrl_mdio_mux: pinctrl-mdio-mux {
> +			fsl,pins = <
> +				VF610_PAD_PTA18__GPIO_8		0x31c2
> +				VF610_PAD_PTA19__GPIO_9		0x31c2
> +				VF610_PAD_PTB2__GPIO_24		0x31c2
> +				VF610_PAD_PTB3__GPIO_25		0x31c2
> +			>;
> +		};
> +		pinctrl_fec0: fec0grp {
> +			fsl,pins = <
> +				VF610_PAD_PTC0__ENET_RMII0_MDC	0x30d2
> +				VF610_PAD_PTC1__ENET_RMII0_MDIO	0x30d3
> +				VF610_PAD_PTC2__ENET_RMII0_CRS	0x30d1
> +				VF610_PAD_PTC3__ENET_RMII0_RXD1	0x30d1
> +				VF610_PAD_PTC4__ENET_RMII0_RXD0	0x30d1
> +				VF610_PAD_PTC5__ENET_RMII0_RXER	0x30d1
> +				VF610_PAD_PTC6__ENET_RMII0_TXD1	0x30d2
> +				VF610_PAD_PTC7__ENET_RMII0_TXD0	0x30d2
> +				VF610_PAD_PTC8__ENET_RMII0_TXEN	0x30d2
> +			>;
> +		};
> +
> +		pinctrl_leds_debug: pinctrl-leds-debug {
> +			fsl,pins = <
> +				 VF610_PAD_PTD20__GPIO_74	0x31c2
> +				 >;
> +		};
> +
> +		pinctrl_pca9554_opt: pinctrl-pca95540-opt {
> +			fsl,pins = <
> +				VF610_PAD_PTB18__GPIO_40	0x219d
> +			>;
> +		};
> +	};
> +};
> +
> +&L2 {
> +	arm,data-latency = <2 1 2>;
> +	arm,tag-latency = <3 2 3>;
> +};

Are you sure about that?

With 9c17190595 ("ARM: dts: vf610: use reset values for L2 cache
latencies") we have reasonable values in the base device tree
vf610.dtsi, I think therefor this is not necessary anymore, even if you
use 500MHz as CPU clock.

--
Stefan

> +
> +&uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart0>;
> +	status = "okay";
> +};
> +
> +&uart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart1>;
> +	status = "okay";
> +};
> +
> +&uart2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_uart2>;
> +	status = "okay";
> +};
> +
> +&usbdev0 {
> +	disable-over-current;
> +	status = "okay";
> +	vbus-supply = <&usb0_vbus>;
> +	dr_mode = "host";
> +};
> +
> +&usbh1 {
> +	disable-over-current;
> +	status = "okay";
> +};
> +
> +&usbmisc0 {
> +	status = "okay";
> +};
> +
> +&usbmisc1 {
> +	status = "okay";
> +};
> +
> +&usbphy0 {
> +	status = "okay";
> +};
> +
> +&usbphy1 {
> +	status = "okay";
> +};
> +
> +&qspi0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_qspi0>;
> +	fsl,nor-size = <0x10000000>;
> +	fsl,spi-num-chipselects = <2>;
> +	status = "okay";
> +
> +	flash0: mt25ql02gc at 0 {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		compatible = "micron,mt25ql02gc";
> +		spi-max-frequency = <66000000>;
> +		reg = <0>;
> +
> +		partition at 0 {
> +			label = "mt25ql02gc-0-uboot";
> +			reg = <0x0 0x0100000>;
> +		};
> +
> +		partition2 at 100000 {
> +			label = "mt25ql02gc-0-dtb";
> +			reg = <0x0100000 0x0100000>;
> +		};
> +
> +		partition3 at 200000 {
> +			label = "mt25ql02gc-0-kernel";
> +			reg = <0x0200000 0x0500000>;
> +		};
> +
> +		partition4 at 700000 {
> +			label = "mt25ql02gc-0-rfs";
> +			reg = <0x0600000 0x8000000>;
> +		};
> +	};
> +};


From robh at kernel.org  Tue Feb 23 12:08:51 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 23 Feb 2016 14:08:51 -0600
Subject: [PATCH/RFC v2 01/11] PM / Domains: Add DT bindings for the R-Car
 System Controller
In-Reply-To: <CAMuHMdXqVL6_P6Lnea6z8jFtR2v4NFnzn=ibZVyauZ8-ODb6dg@mail.gmail.com>
References: <1455571020-18968-1-git-send-email-geert+renesas@glider.be>
 <1455571020-18968-2-git-send-email-geert+renesas@glider.be>
 <20160218143826.GB9654@rob-hp-laptop>
 <CAMuHMdXqVL6_P6Lnea6z8jFtR2v4NFnzn=ibZVyauZ8-ODb6dg@mail.gmail.com>
Message-ID: <20160223200851.GA468@rob-hp-laptop>

On Thu, Feb 18, 2016 at 06:18:56PM +0100, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> On Thu, Feb 18, 2016 at 3:38 PM, Rob Herring <robh at kernel.org> wrote:
> > On Mon, Feb 15, 2016 at 10:16:50PM +0100, Geert Uytterhoeven wrote:
> >> The Renesas R-Car System Controller provides power management for the
> >> CPU cores and various coprocessors, following the generic PM domain
> >> bindings in Documentation/devicetree/bindings/power/power_domain.txt.
> >>
> >> This supports R-Car Gen1, Gen2, and Gen3.
> >>
> >> Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
> >> ---

> >>   - Keeping the power register block offset and the bit number as separate
> >>     "reg" cells, increasing "#address-cells" from 2 to 3,
> >>
> >>   - Merging the interrupt bit (which needs only 5 bits) in the other "reg"
> >>     cell, decreasing "#address-cells" from 2 to 1.
> >
> > I think I'd move to not encoding mulitple things into reg. This seems
> > like a bit of abuse of reg. Otherwise, I don't have much to comment on.
> 
> Thanks!
> 
> (quoting the encoding of the reg properties)
> > +== PM Domain Nodes ==
> > +
> > +Each of the PM domain nodes represents a PM domain, as documented by the
> > +generic PM domain bindings in
> > +Documentation/devicetree/bindings/power/power_domain.txt.
> > +
> > +Required properties:
> > +  - #power-domain-cells: Must be 0.
> > +  - reg: This property must contain 2 values:
> > +          - The first value is the number of the interrupt bit representing
> > +            the power area in the various Interrupt Registers (e.g. SYSCISR,
> > +            Interrupt Status Register),
> > +          - The second value encodes the power register block offset (which is
> > +            a multiple of 64), and the number of the bit representing the
> > +            power area in the various Power Control Registers (e.g. PWROFFSR,
> > +            Power Shutoff Status Register). This value is created by ORing
> > +            these two numbers.
> 
> Not encoding multiple things into reg means adding more properties to provide
> that information, iff we want to describe the PM Domain Nodes in DT.
> I considered the reg property a two-dimensional address space.
> 
> Taking the lessons from CCF and the new CPG/MSSR bindings into account
> (which was BTW designed after the SYSC DT bindings), perhaps the PM Domain
> hierarchy should be moved from DT to C, in the driver, too?
> 
> That would mean we have in DT:
>   1) "#power-domain-cells = <1>"
>   2) defines for the various domains, e.g. "#define R8A7791_PD_CA15_SCU      12"
>   3) e.g. "power-domains = <&sysc R8A7791_PD_CA15_SCU>"
>   4) and we can get rid of the fallback compatibility strings again.
> 
> Thoughts?

Seems fine to me.

Rob


From robert.jarzmik at free.fr  Tue Feb 23 12:12:25 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Tue, 23 Feb 2016 21:12:25 +0100
Subject: [PATCH v1] arm: pxa: fix DT node name for PXA27X usb
In-Reply-To: <1456228901.23036.9.camel@gmail.com> (Sergei Ianovich's message
 of "Tue, 23 Feb 2016 15:01:41 +0300")
References: <1456139297-5854-1-git-send-email-ynvich@gmail.com>
 <87oab8wyfe.fsf@belgarion.home> <1456228901.23036.9.camel@gmail.com>
Message-ID: <87y4abuqxi.fsf@belgarion.home>

Sergei Ianovich <ynvich at gmail.com> writes:

> Hi Robert,?
>
> On Mon, 2016-02-22 at 16:35 +0100, Robert Jarzmik wrote:
>> You're right, I haven't seen the pxa2xx.dtsi statement before.
>> 
>> As such, could you amend a bit your patch please to :
>> ?- add:
>> Fixes: 0ec1939668e5 ("ARM: dts: pxa: add the usb host controller")
>> ?- make the same change in pxa3xx.dtsi, as the same error is there
>> ?- and more globally align pxa2xx.dtsi, pxa27x.dtsi and pxa3xx.dtsi
>> ?- remove the compatible, reg, interrupts and status from both pxa27x.dtsi and
>> ???pxa3xx.dtsi as they are redundant with the included pxa2xxx.dsti one
>
> No problem. Let's figure out the best approach.
>
>> I'm even wondering if the proper change wouldn't be to scrap the ohci
>> declarations from pxa27x.dtsi and pxa3xx.dtsi, and only add the "clocks"
>> property to pxa2xx.dtsi ...
>
> Since clocks are declared in pxa27x.dtsi and?pxa3xx.dtsi, there is a
> stronger ground to have node clocks properties set in pxa27x.dtsi
> and?pxa3xx.dtsi as well. However, there is already nodes with clocks
> properties in pxa2xx.dtsi.
>
> I cannot choose, you should make a decision.
I have checked my manuals, and pxa25x doesn't have an USB Host controller.

So I'd rather have :
 - remove the usb0: ohci at 4c000000 node from pxa2xx.dtsi
 - add it completely to pxa27x.dtsi and pxa3xx.dtsi, with clocks and everything,
   in "disabled" status.

Cheers.

-- 
Robert


From will.deacon at arm.com  Tue Feb 23 12:22:33 2016
From: will.deacon at arm.com (Will Deacon)
Date: Tue, 23 Feb 2016 20:22:33 +0000
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160223193345.GC21820@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160223103221.GA1418@node.shutemov.name>
 <20160223191907.25719a4d@thinkpad>
 <20160223193345.GC21820@node.shutemov.name>
Message-ID: <20160223202233.GE27281@arm.com>

On Tue, Feb 23, 2016 at 10:33:45PM +0300, Kirill A. Shutemov wrote:
> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> > I'll check with Martin, maybe it is actually trivial, then we can
> > do a quick test it to rule that one out.
> 
> Oh. I found a bug in __split_huge_pmd_locked(). Although, not sure if it's
> _the_ bug.
> 
> pmdp_invalidate() is called for the wrong address :-/
> I guess that can be destructive on the architecture, right?

FWIW, arm64 ignores the address parameter for set_pmd_at, so this would
only result in the TLBI nuking the wrong entries, which is going to be
tricky to observe in practice given that we install a table entry
immediately afterwards that maps the same pages. If s390 does more here
(I see some magic asm using the address), that could be the answer...

Will


From robh at kernel.org  Tue Feb 23 12:26:12 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 23 Feb 2016 14:26:12 -0600
Subject: [PATCH 1/3] thermal: exynos: List vtmu-supply as optional
 property in DT binding
In-Reply-To: <1455819551-4666-2-git-send-email-javier@osg.samsung.com>
References: <1455819551-4666-1-git-send-email-javier@osg.samsung.com>
 <1455819551-4666-2-git-send-email-javier@osg.samsung.com>
Message-ID: <20160223202612.GA10733@rob-hp-laptop>

On Thu, Feb 18, 2016 at 03:19:09PM -0300, Javier Martinez Canillas wrote:
> The Exynos Thermal Management Unit binding says that the vtmu-supply
> is optional but is listed in the required properties section. Add an
> optional properties section and move the regulator property there.
> 
> Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>
> ---
> 
>  Documentation/devicetree/bindings/thermal/exynos-thermal.txt | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)

Acked-by: Rob Herring <robh at kernel.org>


From robh at kernel.org  Tue Feb 23 12:27:59 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 23 Feb 2016 14:27:59 -0600
Subject: [PATCH v4 5/6] dt-bindings: add documentation of rk3399 clock
 controller
In-Reply-To: <1455847186-4423-1-git-send-email-jay.xu@rock-chips.com>
References: <1455846978-4272-1-git-send-email-jay.xu@rock-chips.com>
 <1455847186-4423-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <20160223202759.GA11885@rob-hp-laptop>

On Fri, Feb 19, 2016 at 09:59:46AM +0800, jianqun.xu wrote:
> From: Xing Zheng <zhengxing at rock-chips.com>
> 
> Add the devicetree binding for the cru on the rk3399 which quite
> similar structured as previous clock controllers.
> 
> Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
> Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
> ---
> changes in v4:
> - none
> changes in v3:
> - none
> changes in v2:
> - none
> 
>  .../bindings/clock/rockchip,rk3399-cru.txt         | 82 ++++++++++++++++++++++
>  1 file changed, 82 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt

Acked-by: Rob Herring <robh at kernel.org>

> 
> diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
> new file mode 100644
> index 0000000..07bcc6e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
> @@ -0,0 +1,82 @@
> +* Rockchip RK3399 Clock and Reset Unit
> +
> +The RK3399 clock controller generates and supplies clock to various
> +controllers within the SoC and also implements a reset controller for SoC
> +peripherals.
> +
> +Required Properties:
> +
> +- compatible: PMU for CRU should be "rockchip,rk3399-pmucru"
> +- compatible: CRU should be "rockchip,rk3399-cru"
> +- reg: physical base address of the controller and length of memory mapped
> +  region.
> +- #clock-cells: should be 1.
> +- #reset-cells: should be 1.
> +
> +Optional Properties:
> +
> +- rockchip,grf: phandle to the syscon managing the "general register files"
> +  If missing, pll rates are not changeable, due to the missing pll lock status.
> +
> +Each clock is assigned an identifier and client nodes can use this identifier
> +to specify the clock which they consume. All available clocks are defined as
> +preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be
> +used in device tree sources. Similar macros exist for the reset sources in
> +these files.
> +
> +External clocks:
> +
> +There are several clocks that are generated outside the SoC. It is expected
> +that they are defined using standard clock bindings with following
> +clock-output-names:
> + - "xin24m" - crystal input - required,
> + - "xin32k" - rtc clock - optional,
> + - "ext_i2s" - external I2S clock - optional,
> + - "ext_gmac" - external GMAC clock - optional
> + - "ext_hsadc" - external HSADC clock - optional,
> + - "ext_isp" - external ISP clock - optional,
> + - "ext_jtag" - external JTAG clock - optional
> + - "ext_vip" - external VIP clock - optional,
> + - "usbotg_out" - output clock of the pll in the otg phy
> +
> +Example: General Register Files
> +
> +	pmugrf: syscon at ff320000 {
> +		compatible = "rockchip,rk3399-pmugrf", "syscon";
> +		reg = <0x0 0xff320000 0x0 0x1000>;
> +	};
> +
> +	grf: syscon at ff770000 {
> +		compatible = "rockchip,rk3399-grf", "syscon";
> +		reg = <0x0 0xff770000 0x0 0x10000>;
> +	};
> +
> +Example: Clock controller node:
> +
> +	pmucru: pmu-clock-controller at ff750000 {
> +		compatible = "rockchip,rk3399-pmucru";
> +		reg = <0x0 0xff750000 0x0 0x1000>;
> +		#clock-cells = <1>;
> +		#reset-cells = <1>;
> +	};
> +
> +	cru: clock-controller at ff760000 {
> +		compatible = "rockchip,rk3399-cru";
> +		reg = <0x0 0xff760000 0x0 0x1000>;
> +		rockchip,grf = <&grf>;
> +		#clock-cells = <1>;
> +		#reset-cells = <1>;
> +	};
> +
> +Example: UART controller node that consumes the clock generated by the clock
> +  controller:
> +
> +	uart0: serial at ff1a0000 {
> +		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
> +		reg = <0x0 0xff180000 0x0 0x100>;
> +		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
> +		clock-names = "baudclk", "apb_pclk";
> +		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
> +		reg-shift = <2>;
> +		reg-io-width = <4>;
> +	};
> -- 
> 1.9.1
> 
> 


From andrew at lunn.ch  Tue Feb 23 12:32:13 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Tue, 23 Feb 2016 21:32:13 +0100
Subject: [PATCH] ARM: dts: vf610-zii-dev: Add ZII development board.
In-Reply-To: <c67c93683d9440bd050386df0e200881@agner.ch>
References: <1456084314-9871-1-git-send-email-andrew@lunn.ch>
 <c67c93683d9440bd050386df0e200881@agner.ch>
Message-ID: <20160223203213.GA31401@lunn.ch>

On Tue, Feb 23, 2016 at 11:36:49AM -0800, Stefan Agner wrote:
> Hi Andrew,
> 
> Some comments below:
> 
> On 2016-02-21 11:51, Andrew Lunn wrote:
> > From: Cory Tusar <cory.tusar at pid1solutions.com>
> > 
> > This commit adds support for Rev. B of a Zodiac Inflight Innovations
> > development board, mainly intended for DSA and ARINC 429 development
> > work.
> > 
> > Signed-off-by: Cory Tusar <cory.tusar at pid1solutions.com>
> > Signed-off-by: Andrew Lunn <andrew at lunn.ch>
> > ---
> >  arch/arm/boot/dts/Makefile                |   3 +-
> >  arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 683 ++++++++++++++++++++++++++++++
> >  2 files changed, 685 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> > 
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index a4a6d70e8b26..47c4c2ff41de 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -372,7 +372,8 @@ dtb-$(CONFIG_SOC_VF610) += \
> >  	vf610m4-colibri.dtb \
> >  	vf610-cosmic.dtb \
> >  	vf610m4-cosmic.dtb \
> > -	vf610-twr.dtb
> > +	vf610-twr.dtb \
> > +	vf610-zii-dev-rev-b.dtb
> >  dtb-$(CONFIG_ARCH_MXS) += \
> >  	imx23-evk.dtb \
> >  	imx23-olinuxino.dtb \
> > diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> > b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> > new file mode 100644
> > index 000000000000..fafe0039ebce
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> > @@ -0,0 +1,683 @@
> > +/*
> > + * Copyright 2013 Freescale Semiconductor, Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> 
> I recently changed the license of most Vybrid device trees to the new
> dual license. Is it possible to change this device tree too?

Hi Stefan

I need to check with Cory about from which Freescale files this file
was derived from. If those files have been relicenced, we can probably
follow suit.

> > +	chosen {
> > +		bootargs = "console=ttyLP0,115200n8";
> > +		stdout-path = &uart0;
> 
> Is bootargs necessary?
> 
> For the stdout-path I would recommend to use the advanced format:
> stdout-path = "serial0:115200n8";

That probably works. I will test it.

> > +	mdio-mux {
> > +		compatible = "mdio-mux-gpio";
> > +		pinctrl-0 = <&pinctrl_mdio_mux>;
> > +		pinctrl-names = "default";
> > +		gpios = <&gpio0 8  GPIO_ACTIVE_HIGH
> > +			 &gpio0 9  GPIO_ACTIVE_HIGH
> > +			 &gpio0 24 GPIO_ACTIVE_HIGH
> > +			 &gpio0 25 GPIO_ACTIVE_HIGH>;
> > +		mdio-parent-bus = <&mdio1>;
> > +		#address-cells = <1>;
> > +		#size-cells = <0>;
> > +
> > +		mdio_mux_1: mdio at 1 {
> > +			reg = <1>;
> > +			#address-cells = <1>;
> > +			#size-cells = <0>;
> 
> Since there are no child nodes the #address- and #size-cells properties
> are not necessary.

Humm, i would want to test that. Plus, i know there will be patches in
the next few months adding children.

> > +	audio_ext: mclk-osc {
> > +		compatible = "fixed-clock";
> > +		#clock-cells = <0>;
> > +		clock-frequency = <24576000>;
> > +	};
> 
> This seems not to be used anywhere. Maybe needs to be assigned to the
> clks node?
> 
> > +
> > +	enet_ext: eth-osc {
> > +		compatible = "fixed-clock";
> > +		#clock-cells = <0>;
> > +		clock-frequency = <50000000>;
> > +	};
> 
> Same here...

I'll let Cory comment on this.
 
> > +
> > +	reg_3p3v: regulator at 0 {
> > +		compatible = "regulator-fixed";
> > +		regulator-name = "3P3V";
> > +		regulator-min-microvolt = <3300000>;
> > +		regulator-max-microvolt = <3300000>;
> > +		regulator-always-on;
> > +	};
> 
> Do not use the address format (@0) in node name if the regulator is not
> part of a bus.
> 
> Use regulator-3p3v as node name.

Yes. These used to be inside a simple bus, which i removed, but forgot
to remove this part.
 
> > +	gpio5: pca9505 at 20 {
> > +		compatible = "nxp,pca9554";
> > +		reg = <0x20>;
> > +		gpio-controller;
> > +		#gpio-cells = <2>;
> > +
> > +	};
> > +
> > +	gpio6: pca9505 at 22 {
> > +		compatible = "nxp,pca9554";
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_pca9554_opt>;
> > +		reg = <0x22>;
> > +		interrupt-parent = <&gpio1>;
> > +		interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> > +	};
> 
> Hm, any reason why one of this is a gpio-controller while the other
> isn't?

Humm, interesting. No idea. However, i have used the gpio6, but i'm
not sure about gpio5. I will add the missing property and retest.

> > +		i2c2_3:	 i2c at 3 {
> 
> There is an extra space between the colon and i2c at 3...

O.K.
 
> > +&iomuxc {
> 
> We normally put the iomuxc node at the very end.

O.K. I can move it.
 
> > +
> > +&L2 {
> > +	arm,data-latency = <2 1 2>;
> > +	arm,tag-latency = <3 2 3>;
> > +};
> 
> Are you sure about that?
> 
> With 9c17190595 ("ARM: dts: vf610: use reset values for L2 cache
> latencies") we have reasonable values in the base device tree
> vf610.dtsi, I think therefor this is not necessary anymore, even if you
> use 500MHz as CPU clock.

It is probably copy and paste from before that patch.

Thanks for the review.

       Andrew


From hdegoede at redhat.com  Tue Feb 23 12:41:30 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Tue, 23 Feb 2016 21:41:30 +0100
Subject: [PATCH v2] ARM: dts: sun7i: Add dts file for the lamobo-r1 board
Message-ID: <1456260090-23635-1-git-send-email-hdegoede@redhat.com>

From: Jelle de Jong <jelledejong at powercraft.nl>

The lamobo-r1 board, sometimes called the BPI-R1 but not labelled as such
on the PCB, is meant as a A20 based router board. As such the board comes
with a built-in switch chip giving it 5 gigabit ethernet boards, and it
has a large empty area on the pcb with mounting holes which will fit a
2.5 inch harddisk. To complete its networking features it has a
Realtek RTL8192CU for WiFi 802.11 b/g/n.

Signed-off-by: Jelle de Jong <jelledejong at powercraft.nl>
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
Changes in v2:
-Drop custom CPU operating points
---
 arch/arm/boot/dts/Makefile                |   1 +
 arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts | 287 ++++++++++++++++++++++++++++++
 2 files changed, 288 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 04b90fc..ef39613 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -669,6 +669,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
 	sun7i-a20-itead-ibox.dtb \
 	sun7i-a20-i12-tvbox.dtb \
 	sun7i-a20-icnova-swac.dtb \
+	sun7i-a20-lamobo-r1.dtb \
 	sun7i-a20-m3.dtb \
 	sun7i-a20-mk808c.dtb \
 	sun7i-a20-olimex-som-evb.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts b/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
new file mode 100644
index 0000000..5ee43d8
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
@@ -0,0 +1,287 @@
+/*
+ * Copyright 2015 Jelle de Jong <jelledejong at powercraft.nl>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+	model = "Lamobo R1";
+	compatible = "lamobo,lamobo-r1", "allwinner,sun7i-a20";
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart3;
+		serial2 = &uart7;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&led_pins_lamobo_r1>;
+
+		green {
+			label = "lamobo_r1:green:usr";
+			gpios = <&pio 7 24 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	reg_gmac_3v3: gmac-3v3 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&gmac_power_pin_lamobo_r1>;
+		regulator-name = "gmac-3v3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		startup-delay-us = <100000>;
+		enable-active-high;
+		gpio = <&pio 7 23 GPIO_ACTIVE_HIGH>; /* PH23 */
+	};
+};
+
+&ahci_pwr_pin_a {
+	allwinner,pins = "PB3";
+};
+
+&ahci {
+	target-supply = <&reg_ahci_5v>;
+	status = "okay";
+};
+
+&cpu0 {
+	cpu-supply = <&reg_dcdc2>;
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&gmac {
+	pinctrl-names = "default";
+	pinctrl-0 = <&gmac_pins_rgmii_a>;
+	phy = <&phy1>;
+	phy-mode = "rgmii";
+	phy-supply = <&reg_gmac_3v3>;
+	status = "okay";
+
+	phy1: ethernet-phy at 1 {
+		reg = <1>;
+	};
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins_a>;
+	status = "okay";
+
+	axp209: pmic at 34 {
+		reg = <0x34>;
+		interrupt-parent = <&nmi_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+&i2c2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c2_pins_a>;
+	status = "okay";
+};
+
+&ir0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ir0_rx_pins_a>;
+	status = "okay";
+};
+
+&mmc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_lamobo_r1>;
+	vmmc-supply = <&reg_vcc3v3>;
+	bus-width = <4>;
+	cd-gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
+	cd-inverted;
+	status = "okay";
+};
+
+&ohci0 {
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&otg_sram {
+	status = "okay";
+};
+
+&pio {
+	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
+		allwinner,pins = "PH4";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+	};
+
+	mmc0_cd_pin_lamobo_r1: mmc0_cd_pin at 0 {
+		allwinner,pins = "PH10";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+	};
+
+	gmac_power_pin_lamobo_r1: gmac_power_pin at 0 {
+		allwinner,pins = "PH23";
+		allwinner,function = "gpio_out";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+
+	led_pins_lamobo_r1: led_pins at 0 {
+		allwinner,pins = "PH24";
+		allwinner,function = "gpio_out";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+};
+
+#include "axp209.dtsi"
+
+&reg_ahci_5v {
+	gpio = <&pio 1 3 0>; /* PB3 */
+	status = "okay";
+};
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1000000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-cpu";
+};
+
+&reg_dcdc3 {
+	regulator-always-on;
+	regulator-min-microvolt = <1000000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-int-dll";
+};
+
+&reg_ldo1 {
+	regulator-name = "vdd-rtc";
+};
+
+&reg_ldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "avcc";
+};
+
+&reg_usb0_vbus {
+	status = "okay";
+};
+
+&reg_usb1_vbus {
+	status = "okay";
+};
+
+&reg_usb2_vbus {
+	status = "okay";
+};
+
+&spi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi0_pins_a>,
+		    <&spi0_cs0_pins_a>,
+		    <&spi0_cs1_pins_a>;
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins_a>;
+	status = "okay";
+};
+
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart3_pins_b>;
+	status = "okay";
+};
+
+&uart7 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart7_pins_a>;
+	status = "okay";
+};
+
+&usb_otg {
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&usb_power_supply {
+	status = "okay";
+};
+
+&usbphy {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb0_id_detect_pin>;
+	usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+	usb0_vbus_power-supply = <&usb_power_supply>;
+	usb0_vbus-supply = <&reg_usb0_vbus>;
+	usb1_vbus-supply = <&reg_usb1_vbus>;
+	usb2_vbus-supply = <&reg_usb2_vbus>;
+	status = "okay";
+};
-- 
2.7.1



From robh at kernel.org  Tue Feb 23 12:54:37 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 23 Feb 2016 14:54:37 -0600
Subject: [PATCH v3 2/2] iio: dac: vf610_dac: Add IIO DAC driver for
 Vybrid SoC
In-Reply-To: <1a70acdd3ffae273bbfe2f80c5e3952d152921df.1456121233.git.maitysanchayan@gmail.com>
References: <cover.1456121233.git.maitysanchayan@gmail.com>
 <1a70acdd3ffae273bbfe2f80c5e3952d152921df.1456121233.git.maitysanchayan@gmail.com>
Message-ID: <20160223205437.GA27366@rob-hp-laptop>

On Mon, Feb 22, 2016 at 11:48:37AM +0530, Sanchayan Maity wrote:
> Add driver support for DAC peripheral on Vybrid SoC.
> 
> Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
> ---
>  Documentation/ABI/testing/sysfs-bus-iio-vf610      |   9 +
>  .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++

For the binding:

Acked-by: Rob Herring <robh at kernel.org>

>  drivers/iio/dac/Kconfig                            |  10 +
>  drivers/iio/dac/Makefile                           |   1 +
>  drivers/iio/dac/vf610_dac.c                        | 298 +++++++++++++++++++++
>  5 files changed, 338 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>  create mode 100644 drivers/iio/dac/vf610_dac.c


From johnyoun at synopsys.com  Tue Feb 23 13:33:17 2016
From: johnyoun at synopsys.com (John Youn)
Date: Tue, 23 Feb 2016 13:33:17 -0800
Subject: [PATCH RESEND 0/2] usb: dwc2: Remove host and gadget only code from
 core
Message-ID: <cover.1456260533.git.johnyoun@synopsys.com>

This series moves the host/gadget-specific code from core.c to hcd.c
and gadget.c so that they will be compiled only when their respective
configurations are selected, or in DRD.

This is mostly just a straight move of the code. I have also added
some comments to group related functions together.

Compiled and tested in all three modes.

This should also solve the issue reported here:
http://marc.info/?l=linux-usb&m=145591813410106&w=2

Although I wasn't able to test it... couldn't figure out how to
disable CONFIG_USB and enable DWC2 in gadget mode.

Felipe,

This should be applied after Doug's series on your testing/next
branch.

Regards,
John

John Youn (2):
  usb: dwc2: Move register save and restore functions
  usb: dwc2: Move host-specific core functions into hcd.c

 drivers/usb/dwc2/core.c   | 1959 ---------------------------------------------
 drivers/usb/dwc2/core.h   |   35 +-
 drivers/usb/dwc2/gadget.c |  102 +++
 drivers/usb/dwc2/hcd.c    | 1948 ++++++++++++++++++++++++++++++++++++++++++--
 drivers/usb/dwc2/hcd.h    |   10 +
 5 files changed, 2024 insertions(+), 2030 deletions(-)

-- 
2.6.3



From johnyoun at synopsys.com  Tue Feb 23 13:33:22 2016
From: johnyoun at synopsys.com (John Youn)
Date: Tue, 23 Feb 2016 13:33:22 -0800
Subject: [PATCH RESEND 1/2] usb: dwc2: Move register save and restore functions
In-Reply-To: <cover.1456260533.git.johnyoun@synopsys.com>
References: <cover.1456260533.git.johnyoun@synopsys.com>
Message-ID: <8cb0a09d08414388ad62f57320dc67bb2ee8d0f6.1456260533.git.johnyoun@synopsys.com>

Move the register save and restore functions into the host and gadget
specific files.

Signed-off-by: John Youn <johnyoun at synopsys.com>
---
 drivers/usb/dwc2/core.c   | 183 ----------------------------------------------
 drivers/usb/dwc2/core.h   |  13 ++++
 drivers/usb/dwc2/gadget.c | 102 ++++++++++++++++++++++++++
 drivers/usb/dwc2/hcd.c    |  64 ++++++++++++++++
 4 files changed, 179 insertions(+), 183 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 3c9c0b2..dc60339 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -56,189 +56,6 @@
 #include "core.h"
 #include "hcd.h"
 
-#if IS_ENABLED(CONFIG_USB_DWC2_HOST) || IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE)
-/**
- * dwc2_backup_host_registers() - Backup controller host registers.
- * When suspending usb bus, registers needs to be backuped
- * if controller power is disabled once suspended.
- *
- * @hsotg: Programming view of the DWC_otg controller
- */
-static int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
-{
-	struct dwc2_hregs_backup *hr;
-	int i;
-
-	dev_dbg(hsotg->dev, "%s\n", __func__);
-
-	/* Backup Host regs */
-	hr = &hsotg->hr_backup;
-	hr->hcfg = dwc2_readl(hsotg->regs + HCFG);
-	hr->haintmsk = dwc2_readl(hsotg->regs + HAINTMSK);
-	for (i = 0; i < hsotg->core_params->host_channels; ++i)
-		hr->hcintmsk[i] = dwc2_readl(hsotg->regs + HCINTMSK(i));
-
-	hr->hprt0 = dwc2_read_hprt0(hsotg);
-	hr->hfir = dwc2_readl(hsotg->regs + HFIR);
-	hr->valid = true;
-
-	return 0;
-}
-
-/**
- * dwc2_restore_host_registers() - Restore controller host registers.
- * When resuming usb bus, device registers needs to be restored
- * if controller power were disabled.
- *
- * @hsotg: Programming view of the DWC_otg controller
- */
-static int dwc2_restore_host_registers(struct dwc2_hsotg *hsotg)
-{
-	struct dwc2_hregs_backup *hr;
-	int i;
-
-	dev_dbg(hsotg->dev, "%s\n", __func__);
-
-	/* Restore host regs */
-	hr = &hsotg->hr_backup;
-	if (!hr->valid) {
-		dev_err(hsotg->dev, "%s: no host registers to restore\n",
-				__func__);
-		return -EINVAL;
-	}
-	hr->valid = false;
-
-	dwc2_writel(hr->hcfg, hsotg->regs + HCFG);
-	dwc2_writel(hr->haintmsk, hsotg->regs + HAINTMSK);
-
-	for (i = 0; i < hsotg->core_params->host_channels; ++i)
-		dwc2_writel(hr->hcintmsk[i], hsotg->regs + HCINTMSK(i));
-
-	dwc2_writel(hr->hprt0, hsotg->regs + HPRT0);
-	dwc2_writel(hr->hfir, hsotg->regs + HFIR);
-	hsotg->frame_number = 0;
-
-	return 0;
-}
-#else
-static inline int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
-{ return 0; }
-
-static inline int dwc2_restore_host_registers(struct dwc2_hsotg *hsotg)
-{ return 0; }
-#endif
-
-#if IS_ENABLED(CONFIG_USB_DWC2_PERIPHERAL) || \
-	IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE)
-/**
- * dwc2_backup_device_registers() - Backup controller device registers.
- * When suspending usb bus, registers needs to be backuped
- * if controller power is disabled once suspended.
- *
- * @hsotg: Programming view of the DWC_otg controller
- */
-static int dwc2_backup_device_registers(struct dwc2_hsotg *hsotg)
-{
-	struct dwc2_dregs_backup *dr;
-	int i;
-
-	dev_dbg(hsotg->dev, "%s\n", __func__);
-
-	/* Backup dev regs */
-	dr = &hsotg->dr_backup;
-
-	dr->dcfg = dwc2_readl(hsotg->regs + DCFG);
-	dr->dctl = dwc2_readl(hsotg->regs + DCTL);
-	dr->daintmsk = dwc2_readl(hsotg->regs + DAINTMSK);
-	dr->diepmsk = dwc2_readl(hsotg->regs + DIEPMSK);
-	dr->doepmsk = dwc2_readl(hsotg->regs + DOEPMSK);
-
-	for (i = 0; i < hsotg->num_of_eps; i++) {
-		/* Backup IN EPs */
-		dr->diepctl[i] = dwc2_readl(hsotg->regs + DIEPCTL(i));
-
-		/* Ensure DATA PID is correctly configured */
-		if (dr->diepctl[i] & DXEPCTL_DPID)
-			dr->diepctl[i] |= DXEPCTL_SETD1PID;
-		else
-			dr->diepctl[i] |= DXEPCTL_SETD0PID;
-
-		dr->dieptsiz[i] = dwc2_readl(hsotg->regs + DIEPTSIZ(i));
-		dr->diepdma[i] = dwc2_readl(hsotg->regs + DIEPDMA(i));
-
-		/* Backup OUT EPs */
-		dr->doepctl[i] = dwc2_readl(hsotg->regs + DOEPCTL(i));
-
-		/* Ensure DATA PID is correctly configured */
-		if (dr->doepctl[i] & DXEPCTL_DPID)
-			dr->doepctl[i] |= DXEPCTL_SETD1PID;
-		else
-			dr->doepctl[i] |= DXEPCTL_SETD0PID;
-
-		dr->doeptsiz[i] = dwc2_readl(hsotg->regs + DOEPTSIZ(i));
-		dr->doepdma[i] = dwc2_readl(hsotg->regs + DOEPDMA(i));
-	}
-	dr->valid = true;
-	return 0;
-}
-
-/**
- * dwc2_restore_device_registers() - Restore controller device registers.
- * When resuming usb bus, device registers needs to be restored
- * if controller power were disabled.
- *
- * @hsotg: Programming view of the DWC_otg controller
- */
-static int dwc2_restore_device_registers(struct dwc2_hsotg *hsotg)
-{
-	struct dwc2_dregs_backup *dr;
-	u32 dctl;
-	int i;
-
-	dev_dbg(hsotg->dev, "%s\n", __func__);
-
-	/* Restore dev regs */
-	dr = &hsotg->dr_backup;
-	if (!dr->valid) {
-		dev_err(hsotg->dev, "%s: no device registers to restore\n",
-				__func__);
-		return -EINVAL;
-	}
-	dr->valid = false;
-
-	dwc2_writel(dr->dcfg, hsotg->regs + DCFG);
-	dwc2_writel(dr->dctl, hsotg->regs + DCTL);
-	dwc2_writel(dr->daintmsk, hsotg->regs + DAINTMSK);
-	dwc2_writel(dr->diepmsk, hsotg->regs + DIEPMSK);
-	dwc2_writel(dr->doepmsk, hsotg->regs + DOEPMSK);
-
-	for (i = 0; i < hsotg->num_of_eps; i++) {
-		/* Restore IN EPs */
-		dwc2_writel(dr->diepctl[i], hsotg->regs + DIEPCTL(i));
-		dwc2_writel(dr->dieptsiz[i], hsotg->regs + DIEPTSIZ(i));
-		dwc2_writel(dr->diepdma[i], hsotg->regs + DIEPDMA(i));
-
-		/* Restore OUT EPs */
-		dwc2_writel(dr->doepctl[i], hsotg->regs + DOEPCTL(i));
-		dwc2_writel(dr->doeptsiz[i], hsotg->regs + DOEPTSIZ(i));
-		dwc2_writel(dr->doepdma[i], hsotg->regs + DOEPDMA(i));
-	}
-
-	/* Set the Power-On Programming done bit */
-	dctl = dwc2_readl(hsotg->regs + DCTL);
-	dctl |= DCTL_PWRONPRGDONE;
-	dwc2_writel(dctl, hsotg->regs + DCTL);
-
-	return 0;
-}
-#else
-static inline int dwc2_backup_device_registers(struct dwc2_hsotg *hsotg)
-{ return 0; }
-
-static inline int dwc2_restore_device_registers(struct dwc2_hsotg *hsotg)
-{ return 0; }
-#endif
-
 /**
  * dwc2_backup_global_registers() - Backup global controller registers.
  * When suspending usb bus, registers needs to be backuped
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1159259..606629a 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -1295,6 +1295,8 @@ extern void dwc2_hsotg_core_connect(struct dwc2_hsotg *hsotg);
 extern void dwc2_hsotg_disconnect(struct dwc2_hsotg *dwc2);
 extern int dwc2_hsotg_set_test_mode(struct dwc2_hsotg *hsotg, int testmode);
 #define dwc2_is_device_connected(hsotg) (hsotg->connected)
+int dwc2_backup_device_registers(struct dwc2_hsotg *hsotg);
+int dwc2_restore_device_registers(struct dwc2_hsotg *hsotg);
 #else
 static inline int dwc2_hsotg_remove(struct dwc2_hsotg *dwc2)
 { return 0; }
@@ -1312,6 +1314,10 @@ static inline int dwc2_hsotg_set_test_mode(struct dwc2_hsotg *hsotg,
 							int testmode)
 { return 0; }
 #define dwc2_is_device_connected(hsotg) (0)
+static inline int dwc2_backup_device_registers(struct dwc2_hsotg *hsotg)
+{ return 0; }
+static inline int dwc2_restore_device_registers(struct dwc2_hsotg *hsotg)
+{ return 0; }
 #endif
 
 #if IS_ENABLED(CONFIG_USB_DWC2_HOST) || IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE)
@@ -1320,6 +1326,8 @@ extern int dwc2_hcd_get_future_frame_number(struct dwc2_hsotg *hsotg, int us);
 extern void dwc2_hcd_connect(struct dwc2_hsotg *hsotg);
 extern void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool force);
 extern void dwc2_hcd_start(struct dwc2_hsotg *hsotg);
+int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg);
+int dwc2_restore_host_registers(struct dwc2_hsotg *hsotg);
 #else
 static inline int dwc2_hcd_get_frame_number(struct dwc2_hsotg *hsotg)
 { return 0; }
@@ -1332,6 +1340,11 @@ static inline void dwc2_hcd_start(struct dwc2_hsotg *hsotg) {}
 static inline void dwc2_hcd_remove(struct dwc2_hsotg *hsotg) {}
 static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
 { return 0; }
+static inline int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
+{ return 0; }
+static inline int dwc2_restore_host_registers(struct dwc2_hsotg *hsotg)
+{ return 0; }
+
 #endif
 
 #endif /* __DWC2_CORE_H__ */
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 422ab7d..e9940dd 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3668,3 +3668,105 @@ int dwc2_hsotg_resume(struct dwc2_hsotg *hsotg)
 
 	return 0;
 }
+
+/**
+ * dwc2_backup_device_registers() - Backup controller device registers.
+ * When suspending usb bus, registers needs to be backuped
+ * if controller power is disabled once suspended.
+ *
+ * @hsotg: Programming view of the DWC_otg controller
+ */
+int dwc2_backup_device_registers(struct dwc2_hsotg *hsotg)
+{
+	struct dwc2_dregs_backup *dr;
+	int i;
+
+	dev_dbg(hsotg->dev, "%s\n", __func__);
+
+	/* Backup dev regs */
+	dr = &hsotg->dr_backup;
+
+	dr->dcfg = dwc2_readl(hsotg->regs + DCFG);
+	dr->dctl = dwc2_readl(hsotg->regs + DCTL);
+	dr->daintmsk = dwc2_readl(hsotg->regs + DAINTMSK);
+	dr->diepmsk = dwc2_readl(hsotg->regs + DIEPMSK);
+	dr->doepmsk = dwc2_readl(hsotg->regs + DOEPMSK);
+
+	for (i = 0; i < hsotg->num_of_eps; i++) {
+		/* Backup IN EPs */
+		dr->diepctl[i] = dwc2_readl(hsotg->regs + DIEPCTL(i));
+
+		/* Ensure DATA PID is correctly configured */
+		if (dr->diepctl[i] & DXEPCTL_DPID)
+			dr->diepctl[i] |= DXEPCTL_SETD1PID;
+		else
+			dr->diepctl[i] |= DXEPCTL_SETD0PID;
+
+		dr->dieptsiz[i] = dwc2_readl(hsotg->regs + DIEPTSIZ(i));
+		dr->diepdma[i] = dwc2_readl(hsotg->regs + DIEPDMA(i));
+
+		/* Backup OUT EPs */
+		dr->doepctl[i] = dwc2_readl(hsotg->regs + DOEPCTL(i));
+
+		/* Ensure DATA PID is correctly configured */
+		if (dr->doepctl[i] & DXEPCTL_DPID)
+			dr->doepctl[i] |= DXEPCTL_SETD1PID;
+		else
+			dr->doepctl[i] |= DXEPCTL_SETD0PID;
+
+		dr->doeptsiz[i] = dwc2_readl(hsotg->regs + DOEPTSIZ(i));
+		dr->doepdma[i] = dwc2_readl(hsotg->regs + DOEPDMA(i));
+	}
+	dr->valid = true;
+	return 0;
+}
+
+/**
+ * dwc2_restore_device_registers() - Restore controller device registers.
+ * When resuming usb bus, device registers needs to be restored
+ * if controller power were disabled.
+ *
+ * @hsotg: Programming view of the DWC_otg controller
+ */
+int dwc2_restore_device_registers(struct dwc2_hsotg *hsotg)
+{
+	struct dwc2_dregs_backup *dr;
+	u32 dctl;
+	int i;
+
+	dev_dbg(hsotg->dev, "%s\n", __func__);
+
+	/* Restore dev regs */
+	dr = &hsotg->dr_backup;
+	if (!dr->valid) {
+		dev_err(hsotg->dev, "%s: no device registers to restore\n",
+			__func__);
+		return -EINVAL;
+	}
+	dr->valid = false;
+
+	dwc2_writel(dr->dcfg, hsotg->regs + DCFG);
+	dwc2_writel(dr->dctl, hsotg->regs + DCTL);
+	dwc2_writel(dr->daintmsk, hsotg->regs + DAINTMSK);
+	dwc2_writel(dr->diepmsk, hsotg->regs + DIEPMSK);
+	dwc2_writel(dr->doepmsk, hsotg->regs + DOEPMSK);
+
+	for (i = 0; i < hsotg->num_of_eps; i++) {
+		/* Restore IN EPs */
+		dwc2_writel(dr->diepctl[i], hsotg->regs + DIEPCTL(i));
+		dwc2_writel(dr->dieptsiz[i], hsotg->regs + DIEPTSIZ(i));
+		dwc2_writel(dr->diepdma[i], hsotg->regs + DIEPDMA(i));
+
+		/* Restore OUT EPs */
+		dwc2_writel(dr->doepctl[i], hsotg->regs + DOEPCTL(i));
+		dwc2_writel(dr->doeptsiz[i], hsotg->regs + DOEPTSIZ(i));
+		dwc2_writel(dr->doepdma[i], hsotg->regs + DOEPDMA(i));
+	}
+
+	/* Set the Power-On Programming done bit */
+	dctl = dwc2_readl(hsotg->regs + DCTL);
+	dctl |= DCTL_PWRONPRGDONE;
+	dwc2_writel(dctl, hsotg->regs + DCTL);
+
+	return 0;
+}
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 2b5a706..b403f6a 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -3433,3 +3433,67 @@ void dwc2_hcd_remove(struct dwc2_hsotg *hsotg)
 	kfree(hsotg->frame_num_array);
 #endif
 }
+
+/**
+ * dwc2_backup_host_registers() - Backup controller host registers.
+ * When suspending usb bus, registers needs to be backuped
+ * if controller power is disabled once suspended.
+ *
+ * @hsotg: Programming view of the DWC_otg controller
+ */
+int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
+{
+	struct dwc2_hregs_backup *hr;
+	int i;
+
+	dev_dbg(hsotg->dev, "%s\n", __func__);
+
+	/* Backup Host regs */
+	hr = &hsotg->hr_backup;
+	hr->hcfg = dwc2_readl(hsotg->regs + HCFG);
+	hr->haintmsk = dwc2_readl(hsotg->regs + HAINTMSK);
+	for (i = 0; i < hsotg->core_params->host_channels; ++i)
+		hr->hcintmsk[i] = dwc2_readl(hsotg->regs + HCINTMSK(i));
+
+	hr->hprt0 = dwc2_read_hprt0(hsotg);
+	hr->hfir = dwc2_readl(hsotg->regs + HFIR);
+	hr->valid = true;
+
+	return 0;
+}
+
+/**
+ * dwc2_restore_host_registers() - Restore controller host registers.
+ * When resuming usb bus, device registers needs to be restored
+ * if controller power were disabled.
+ *
+ * @hsotg: Programming view of the DWC_otg controller
+ */
+int dwc2_restore_host_registers(struct dwc2_hsotg *hsotg)
+{
+	struct dwc2_hregs_backup *hr;
+	int i;
+
+	dev_dbg(hsotg->dev, "%s\n", __func__);
+
+	/* Restore host regs */
+	hr = &hsotg->hr_backup;
+	if (!hr->valid) {
+		dev_err(hsotg->dev, "%s: no host registers to restore\n",
+			__func__);
+		return -EINVAL;
+	}
+	hr->valid = false;
+
+	dwc2_writel(hr->hcfg, hsotg->regs + HCFG);
+	dwc2_writel(hr->haintmsk, hsotg->regs + HAINTMSK);
+
+	for (i = 0; i < hsotg->core_params->host_channels; ++i)
+		dwc2_writel(hr->hcintmsk[i], hsotg->regs + HCINTMSK(i));
+
+	dwc2_writel(hr->hprt0, hsotg->regs + HPRT0);
+	dwc2_writel(hr->hfir, hsotg->regs + HFIR);
+	hsotg->frame_number = 0;
+
+	return 0;
+}
-- 
2.6.3



From robh at kernel.org  Tue Feb 23 13:52:20 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 23 Feb 2016 15:52:20 -0600
Subject: [PATCH 1/3 v2] irqchip: gic/realview: support more RealView DCC
 variants
In-Reply-To: <1456149661-19118-1-git-send-email-linus.walleij@linaro.org>
References: <1456149661-19118-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <20160223215219.GA26531@rob-hp-laptop>

On Mon, Feb 22, 2016 at 03:01:01PM +0100, Linus Walleij wrote:
> In the add-on file for the GIC dealing with the RealView family
> we currently only handle the PB11MPCore, let's extend this to
> manage the RealView EB ARM11MPCore as well. The Revision B of the
> ARM11MPCore core tile is a bit special and needs special handling
> as it moves a system control register around at random.
> 
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Marc Zyngier <marc.zyngier at arm.com>
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> ChangeLog v1->v2:
> - Detect syscon register location based on the syscon compatible
>   string instead of the GIC compatible string, just define one
>   compatible string for the 11mp test chip GIC.
> - Consistently return -ENODEV
> This can be applied in isolation from the other patches so Marc
> one you're happy with it, please take it into the IRQchip tree.
> ---
>  .../bindings/interrupt-controller/arm,gic.txt      |  1 +
>  drivers/irqchip/irq-gic-realview.c                 | 44 +++++++++++++++++++---
>  2 files changed, 39 insertions(+), 6 deletions(-)

Acked-by: Rob Herring <robh at kernel.org>


From swarren at wwwdotorg.org  Tue Feb 23 13:56:53 2016
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Tue, 23 Feb 2016 14:56:53 -0700
Subject: [PATCH] ARM: dts: tegra: correct Beaver pinmux
In-Reply-To: <1456260543-18076-1-git-send-email-dev@lynxeye.de>
References: <1456260543-18076-1-git-send-email-dev@lynxeye.de>
Message-ID: <56CCD5A5.9080809@wwwdotorg.org>

On 02/23/2016 01:49 PM, Lucas Stach wrote:
> Update pinmux to get rid of invalid uses of the rsvd1 function and
> add correct drive settings for SDIO1, which makes some more SD-cards
> work.

(Adding a variety of missing CCs)

I think this patch looks OK. Looking at the kernel pinctrl driver, I 
think that before this patch, because some of the mux settings were 
deemed invalid by the pinctrl driver, the pinmux settings were not all 
applied, and this change fixes it? Ouch! Luckily U-Boot programmed what 
is hopefully the same table before the kernel booted!

> diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts

... (many other fixes; see original email)

> +			sdio1 {
> +				nvidia,pins = "drive_sdio1";
> +				nvidia,high-speed-mode = <TEGRA_PIN_DISABLE>;
> +				nvidia,schmitt = <TEGRA_PIN_DISABLE>;
> +				nvidia,pull-down-strength = <46>;
> +				nvidia,pull-up-strength = <42>;
> +				nvidia,slew-rate-rising = <1>;
> +				nvidia,slew-rate-falling = <1>;
> +			};

I think it would be worth mentioning in the commit description where 
this data came from.


From brad.mouring at ni.com  Tue Feb 23 14:03:37 2016
From: brad.mouring at ni.com (Brad Mouring)
Date: Tue, 23 Feb 2016 16:03:37 -0600
Subject: [PATCH 0/2] Control PL310 pwr_ctrl register through DT
Message-ID: <1456265019-23900-1-git-send-email-brad.mouring@ni.com>


During some performance-oriented benchmarking on a Cortex A9
platform, a slight performance degradation was noted on datasets
that spanned into the L2 cache (<10%). This performance hit was
minor, but it prompted investigation into the cause.

One difference in the actual PL310 configuration that was concerning
was the enabling of two PM-related changes: Dynamic Clock Gating
and Standby Mode Enabling. As the kernel being tested was patched
and configured to use the PREEMPT_RT patchset, it was desired to
disable these settings for our use-case since anything PM can
(and usually does) impact determinism.

Making these changes resulted in a modest performance improvement
and those wonderful warm-n-fuzzies regarding determinism and enabling
system control without needing to change the kernel.

In the following set, there's the actual change to control these
features given DT presence of a couple of new bindings and the
documenation to accompany those changes. Thanks!


From brad.mouring at ni.com  Tue Feb 23 14:03:38 2016
From: brad.mouring at ni.com (Brad Mouring)
Date: Tue, 23 Feb 2016 16:03:38 -0600
Subject: [PATCH 1/2] pl2x0: Add OF control of cache power management
In-Reply-To: <1456265019-23900-1-git-send-email-brad.mouring@ni.com>
References: <1456265019-23900-1-git-send-email-brad.mouring@ni.com>
Message-ID: <1456265019-23900-2-git-send-email-brad.mouring@ni.com>

Add ability to override power management bits of 310 controllers
through OF entries. As the saved register is only applied when
working on a supported controller, it is safe to save the settings.

Additionally, to control the actual configuration of the power
control register, remove the unconditional enabling of features in
the l2c310_enable function.

Signed-off-by: Brad Mouring <brad.mouring at ni.com>
Acked-by: Josh Cartwright <joshc at ni.com>
---
 arch/arm/mm/cache-l2x0.c | 29 ++++++++++++++++++++++++-----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index d6e43d8..42f4ad1 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -639,11 +639,6 @@ static void __init l2c310_enable(void __iomem *base, u32 aux, unsigned num_lock)
 		aux &= ~(L310_AUX_CTRL_FULL_LINE_ZERO | L310_AUX_CTRL_EARLY_BRESP);
 	}
 
-	/* r3p0 or later has power control register */
-	if (rev >= L310_CACHE_ID_RTL_R3P0)
-		l2x0_saved_regs.pwr_ctrl = L310_DYNAMIC_CLK_GATING_EN |
-						L310_STNDBY_MODE_EN;
-
 	/*
 	 * Always enable non-secure access to the lockdown registers -
 	 * we write to them as part of the L2C enable sequence so they
@@ -1103,6 +1098,7 @@ static void __init l2c310_of_parse(const struct device_node *np,
 	u32 filter[2] = { 0, 0 };
 	u32 assoc;
 	u32 prefetch;
+	u32 power;
 	u32 val;
 	int ret;
 
@@ -1220,6 +1216,29 @@ static void __init l2c310_of_parse(const struct device_node *np,
 	}
 
 	l2x0_saved_regs.prefetch_ctrl = prefetch;
+
+	power = l2x0_saved_regs.pwr_ctrl;
+
+	ret = of_property_read_u32(np, "arm,dynamic-clock-gating", &val);
+	if (ret == 0) {
+		if (val)
+			power |= L310_DYNAMIC_CLK_GATING_EN;
+		else
+			power &= ~L310_DYNAMIC_CLK_GATING_EN;
+	} else if (ret != -EINVAL) {
+		pr_err("L2C-310 OF dynamic-clock-gating property value is missing\n");
+	}
+	ret = of_property_read_u32(np, "arm,standby-mode", &val);
+	if (ret == 0) {
+		if (val)
+			power |= L310_STNDBY_MODE_EN;
+		else
+			power &= ~L310_STNDBY_MODE_EN;
+	} else if (ret != -EINVAL) {
+		pr_err("L2C-310 OF standby-mode property value is missing\n");
+	}
+
+	l2x0_saved_regs.pwr_ctrl = power;
 }
 
 static const struct l2c_init_data of_l2c310_data __initconst = {
-- 
2.7.1



From brad.mouring at ni.com  Tue Feb 23 14:03:39 2016
From: brad.mouring at ni.com (Brad Mouring)
Date: Tue, 23 Feb 2016 16:03:39 -0600
Subject: [PATCH 2/2] Documentation: devicetree: Add PL310 PM bindings
In-Reply-To: <1456265019-23900-1-git-send-email-brad.mouring@ni.com>
References: <1456265019-23900-1-git-send-email-brad.mouring@ni.com>
Message-ID: <1456265019-23900-3-git-send-email-brad.mouring@ni.com>

Document the DT bindings for controlling ARM PL310 Power Control
settings.

Signed-off-by: Brad Mouring <brad.mouring at ni.com>
Acked-by: Josh Cartwright <joshc at ni.com>
---
 Documentation/devicetree/bindings/arm/l2c2x0.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/l2c2x0.txt b/Documentation/devicetree/bindings/arm/l2c2x0.txt
index 2251dcc..4c2d764 100644
--- a/Documentation/devicetree/bindings/arm/l2c2x0.txt
+++ b/Documentation/devicetree/bindings/arm/l2c2x0.txt
@@ -72,6 +72,10 @@ Optional properties:
 - prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),
   <1> (forcibly enable), property absent (retain settings set by
   firmware)
+- arm,dynamic-clock-gating : L2 dynamic clock gating. Value: <0> (forcibly
+  disable), <1> (forcibly enable), property absent (retain firmware settings)
+- arm,standby-mode: L2 standby mode enable. Value <0> (forcibly disable),
+  <1> (forcibly enable), property absent (retain firmware settings)
 
 Example:
 
-- 
2.7.1



From hdegoede at redhat.com  Tue Feb 23 14:11:22 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Tue, 23 Feb 2016 23:11:22 +0100
Subject: [linux-sunxi] [PATCH v2] ARM: dts: sun7i: Add dts file for the
 lamobo-r1 board
In-Reply-To: <20160223221041.GA2992@excalibur.cnev.de>
References: <1456260090-23635-1-git-send-email-hdegoede@redhat.com>
 <20160223221041.GA2992@excalibur.cnev.de>
Message-ID: <56CCD90A.5070908@redhat.com>

Hi,

On 02/23/2016 11:10 PM, Karsten Merker wrote:
> On Tue, Feb 23, 2016 at 09:41:30PM +0100, Hans de Goede wrote:
>> From: Jelle de Jong <jelledejong at powercraft.nl>
>>
>> The lamobo-r1 board, sometimes called the BPI-R1 but not labelled as such
>> on the PCB, is meant as a A20 based router board. As such the board comes
>> with a built-in switch chip giving it 5 gigabit ethernet boards, and it
>
> s/gigabit ethernet boards/gigabit ethernet ports/ ?

Erm, yes.

Regards,

hans


>
>> has a large empty area on the pcb with mounting holes which will fit a
>> 2.5 inch harddisk. To complete its networking features it has a
>> Realtek RTL8192CU for WiFi 802.11 b/g/n.
>>
>> Signed-off-by: Jelle de Jong <jelledejong at powercraft.nl>
>> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>
> Regards,
> Karsten
>


From robh at kernel.org  Tue Feb 23 14:12:02 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 23 Feb 2016 16:12:02 -0600
Subject: [PATCH v12 1/5] efi: ARM/arm64: ignore DT memory nodes instead
 of removing them
In-Reply-To: <20160223115805.GB4989@leverpostej>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
 <1456192703-2274-2-git-send-email-ddaney.cavm@gmail.com>
 <20160223115805.GB4989@leverpostej>
Message-ID: <20160223221202.GA32031@rob-hp-laptop>

On Tue, Feb 23, 2016 at 11:58:05AM +0000, Mark Rutland wrote:
> Hi,
> 
> On Mon, Feb 22, 2016 at 05:58:19PM -0800, David Daney wrote:
> > From: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> > 
> > There are two problems with the UEFI stub DT memory node removal
> > routine:
> > - it deletes nodes as it traverses the tree, which happens to work
> >   but is not supported, as deletion invalidates the node iterator;
> > - deleting memory nodes entirely may discard annotations in the form
> >   of additional properties on the nodes.
> > 
> > Since the discovery of DT memory nodes occurs strictly before the
> > UEFI init sequence, we can simply clear the memblock memory table
> > before parsing the UEFI memory map. This way, it is no longer
> > necessary to remove the nodes, so we can remove that logic from the
> > stub as well.
> 
> This is a little bit scary, but I guess this works.

The way it is worded/implemented is, I agree. But if we simply say both 
can be present and the kernel will default to UEFI memory map, that 
seems sufficient to me.
 
> My only concern is that when we get kexec, a subsequent kernel must also
> have EFI memory map support, or things go bad for the next EFI-aware
> kernel after that (as things like the runtime services may have been
> corrupted by the kernel in the middle). It's difficult to fix the
> general case later.
> 
> A different option would be to support status="disabled" for the memory
> nodes, and ignore these in early_init_dt_scan_memory. That way a kernel
> cannot use memory without first having parsed the EFI memory map, and we
> can still get NUMA info from the disabled nodes.

That would be a bit strange that the node is disabled, but still used. 

What if DT and UEFI tables are out of sync somehow? RAM is multiple 
mapped and different addresses were picked for example.

> You'd still need a new kernel to take into account status, but at least
> we'd know all kernels would avoid using RAM that potentially needs to be
> preserved.
> 
> Ard, Rob, thoughts?


From hdegoede at redhat.com  Tue Feb 23 14:12:43 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Tue, 23 Feb 2016 23:12:43 +0100
Subject: [PATCH v3] ARM: dts: sun7i: Add dts file for the lamobo-r1 board
Message-ID: <1456265563-2940-1-git-send-email-hdegoede@redhat.com>

From: Jelle de Jong <jelledejong at powercraft.nl>

The lamobo-r1 board, sometimes called the BPI-R1 but not labelled as such
on the PCB, is meant as a A20 based router board. As such the board comes
with a built-in switch chip giving it 5 gigabit ethernet ports, and it
has a large empty area on the pcb with mounting holes which will fit a
2.5 inch harddisk. To complete its networking features it has a
Realtek RTL8192CU for WiFi 802.11 b/g/n.

Signed-off-by: Jelle de Jong <jelledejong at powercraft.nl>
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
Changes in v2:
-Drop custom CPU operating points
Changes in v3:
-Fix type in commit msg
---
 arch/arm/boot/dts/Makefile                |   1 +
 arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts | 287 ++++++++++++++++++++++++++++++
 2 files changed, 288 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 04b90fc..ef39613 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -669,6 +669,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
 	sun7i-a20-itead-ibox.dtb \
 	sun7i-a20-i12-tvbox.dtb \
 	sun7i-a20-icnova-swac.dtb \
+	sun7i-a20-lamobo-r1.dtb \
 	sun7i-a20-m3.dtb \
 	sun7i-a20-mk808c.dtb \
 	sun7i-a20-olimex-som-evb.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts b/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
new file mode 100644
index 0000000..5ee43d8
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
@@ -0,0 +1,287 @@
+/*
+ * Copyright 2015 Jelle de Jong <jelledejong at powercraft.nl>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+	model = "Lamobo R1";
+	compatible = "lamobo,lamobo-r1", "allwinner,sun7i-a20";
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart3;
+		serial2 = &uart7;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&led_pins_lamobo_r1>;
+
+		green {
+			label = "lamobo_r1:green:usr";
+			gpios = <&pio 7 24 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	reg_gmac_3v3: gmac-3v3 {
+		compatible = "regulator-fixed";
+		pinctrl-names = "default";
+		pinctrl-0 = <&gmac_power_pin_lamobo_r1>;
+		regulator-name = "gmac-3v3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		startup-delay-us = <100000>;
+		enable-active-high;
+		gpio = <&pio 7 23 GPIO_ACTIVE_HIGH>; /* PH23 */
+	};
+};
+
+&ahci_pwr_pin_a {
+	allwinner,pins = "PB3";
+};
+
+&ahci {
+	target-supply = <&reg_ahci_5v>;
+	status = "okay";
+};
+
+&cpu0 {
+	cpu-supply = <&reg_dcdc2>;
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+&gmac {
+	pinctrl-names = "default";
+	pinctrl-0 = <&gmac_pins_rgmii_a>;
+	phy = <&phy1>;
+	phy-mode = "rgmii";
+	phy-supply = <&reg_gmac_3v3>;
+	status = "okay";
+
+	phy1: ethernet-phy at 1 {
+		reg = <1>;
+	};
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_pins_a>;
+	status = "okay";
+
+	axp209: pmic at 34 {
+		reg = <0x34>;
+		interrupt-parent = <&nmi_intc>;
+		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+&i2c2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c2_pins_a>;
+	status = "okay";
+};
+
+&ir0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ir0_rx_pins_a>;
+	status = "okay";
+};
+
+&mmc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_lamobo_r1>;
+	vmmc-supply = <&reg_vcc3v3>;
+	bus-width = <4>;
+	cd-gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
+	cd-inverted;
+	status = "okay";
+};
+
+&ohci0 {
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&otg_sram {
+	status = "okay";
+};
+
+&pio {
+	usb0_id_detect_pin: usb0_id_detect_pin at 0 {
+		allwinner,pins = "PH4";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+	};
+
+	mmc0_cd_pin_lamobo_r1: mmc0_cd_pin at 0 {
+		allwinner,pins = "PH10";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+	};
+
+	gmac_power_pin_lamobo_r1: gmac_power_pin at 0 {
+		allwinner,pins = "PH23";
+		allwinner,function = "gpio_out";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+
+	led_pins_lamobo_r1: led_pins at 0 {
+		allwinner,pins = "PH24";
+		allwinner,function = "gpio_out";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+};
+
+#include "axp209.dtsi"
+
+&reg_ahci_5v {
+	gpio = <&pio 1 3 0>; /* PB3 */
+	status = "okay";
+};
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1000000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-cpu";
+};
+
+&reg_dcdc3 {
+	regulator-always-on;
+	regulator-min-microvolt = <1000000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-int-dll";
+};
+
+&reg_ldo1 {
+	regulator-name = "vdd-rtc";
+};
+
+&reg_ldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "avcc";
+};
+
+&reg_usb0_vbus {
+	status = "okay";
+};
+
+&reg_usb1_vbus {
+	status = "okay";
+};
+
+&reg_usb2_vbus {
+	status = "okay";
+};
+
+&spi0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi0_pins_a>,
+		    <&spi0_cs0_pins_a>,
+		    <&spi0_cs1_pins_a>;
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_pins_a>;
+	status = "okay";
+};
+
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart3_pins_b>;
+	status = "okay";
+};
+
+&uart7 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart7_pins_a>;
+	status = "okay";
+};
+
+&usb_otg {
+	dr_mode = "otg";
+	status = "okay";
+};
+
+&usb_power_supply {
+	status = "okay";
+};
+
+&usbphy {
+	pinctrl-names = "default";
+	pinctrl-0 = <&usb0_id_detect_pin>;
+	usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+	usb0_vbus_power-supply = <&usb_power_supply>;
+	usb0_vbus-supply = <&reg_usb0_vbus>;
+	usb1_vbus-supply = <&reg_usb1_vbus>;
+	usb2_vbus-supply = <&reg_usb2_vbus>;
+	status = "okay";
+};
-- 
2.7.1



From robh at kernel.org  Tue Feb 23 14:15:55 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 23 Feb 2016 16:15:55 -0600
Subject: [PATCH 1/4] soc: rockchip: add bindings for Rockchip grf
In-Reply-To: <1456210864-29037-2-git-send-email-jay.xu@rock-chips.com>
References: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
 <1456210864-29037-2-git-send-email-jay.xu@rock-chips.com>
Message-ID: <20160223221555.GA7531@rob-hp-laptop>

On Tue, Feb 23, 2016 at 03:01:01PM +0800, jianqun.xu wrote:
> From: Jianqun Xu <jay.xu at rock-chips.com>
> 
> Add devicetree bindings for Rockchip grf which found on
> Rockchip SoCs.
> 
> Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
> ---
> changes in v2:
> - add grf.txt (Heiko)
> 
>  .../devicetree/bindings/soc/rockchip/grf.txt       | 35 ++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt
> 
> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> new file mode 100644
> index 0000000..7fb0410
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
> @@ -0,0 +1,35 @@
> +* Rockchip General Register Files (GRF)
> +
> +The general register file will be used to do static set by software, which
> +is composed of many registers for system control.
> +
> +From RK3368 SoCs, the GRF is divided into two sections,
> +- GRF, used for general non-secure system,
> +- PMUGRF, used for always on sysyem

s/sysyem/system/

Otherwise:

Acked-by: Rob Herring <robh at kernel.org>

> +
> +Required Properties:
> +
> +- compatible: GRF should be one of the followings
> +   - "rockchip,rk3066-grf", "syscon": for rk3066
> +   - "rockchip,rk3188-grf", "syscon": for rk3188
> +   - "rockchip,rk3228-grf", "syscon": for rk3228
> +   - "rockchip,rk3288-grf", "syscon": for rk3288
> +   - "rockchip,rk3368-grf", "syscon": for rk3368
> +   - "rockchip,rk3399-grf", "syscon": for rk3399
> +- compatible: PMUGRF should be one of the followings
> +   - "rockchip,rk3368-pmugrf", "syscon": for rk3368
> +   - "rockchip,rk3399-pmugrf", "syscon": for rk3399
> +- reg: physical base address of the controller and length of memory mapped
> +  region.
> +
> +Example: GRF and PMUGRF of RK3399 SoCs
> +
> +	pmugrf: syscon at ff320000 {
> +		compatible = "rockchip,rk3399-pmugrf", "syscon";
> +		reg = <0x0 0xff320000 0x0 0x1000>;
> +	};
> +
> +	grf: syscon at ff770000 {
> +		compatible = "rockchip,rk3399-grf", "syscon";
> +		reg = <0x0 0xff770000 0x0 0x10000>;
> +	};
> -- 
> 1.9.1
> 
> 


From manabian at gmail.com  Tue Feb 23 14:16:38 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Tue, 23 Feb 2016 23:16:38 +0100
Subject: [PATCH v2 1/4] net: ethernet: dwmac: add Ethernet glue logic for
 stm32 chip
In-Reply-To: <1456240244-10275-2-git-send-email-alexandre.torgue@gmail.com>
References: <1456240244-10275-1-git-send-email-alexandre.torgue@gmail.com>
 <1456240244-10275-2-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <CAGhQ9Vz8uUeyhEutTPh3Zb3C=T3F2xC7kgHorZyWcz6HW+ySmw@mail.gmail.com>

Hi Alexandre,

On 23 February 2016 at 16:10, Alexandre TORGUE
<alexandre.torgue at gmail.com> wrote:
> stm324xx family chips support Synopsys MAC 3.510 IP.
> This patch adds settings for logical glue logic:
> -clocks
> -mode selection MII or RMII.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> index cec147d..f63bdcf 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
> @@ -114,6 +114,18 @@ config DWMAC_SUNXI
>           This selects Allwinner SoC glue layer support for the
>           stmmac device driver. This driver is used for A20/A31
>           GMAC ethernet controller.
> +
> +config DWMAC_STM32
> +       tristate "STM32 DWMAC support"
> +       default ARCH_STM32
> +       depends on OF && HAS_IOMEM
> +       select MFD_SYSCON
> +       ---help---
> +         Support for ethernet controller on STM32 SOCs.
> +
> +         This selects STM32 SoC glue layer support for the stmmac
> +         device driver. This driver is used on for the STM32 series
> +         SOCs GMAC ethernet controller.
>  endif
>
>  config STMMAC_PCI
> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
> index b390161..559086d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_DWMAC_ROCKCHIP)  += dwmac-rk.o
>  obj-$(CONFIG_DWMAC_SOCFPGA)    += dwmac-socfpga.o
>  obj-$(CONFIG_DWMAC_STI)                += dwmac-sti.o
>  obj-$(CONFIG_DWMAC_SUNXI)      += dwmac-sunxi.o
> +obj-$(CONFIG_DWMAC_STM32)      += dwmac-stm32.o

Put them in alphabetic order. Same goes for the KConfig entry.


>  obj-$(CONFIG_DWMAC_GENERIC)    += dwmac-generic.o
>  stmmac-platform-objs:= stmmac_platform.o
...
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
> +struct stm32_dwmac {
> +       int interface;          /* MII interface */
> +       struct clk *clk_tx;
> +       struct clk *clk_rx;
> +       u32 mode_reg;           /* MAC glue-logic mode register */
> +       struct regmap *regmap;
> +       u32 speed;
> +};
> +
> +static int stm32_dwmac_init(void *priv)

If you used 'struct stm32_dwmac *' instead of 'void *' you could skip
the local variable assignment.

Even better; you could pass 'struct plat_stmmacenet_data *' and use
it's 'interface' member to set the phy mode. Then you could drop the
interface member in your priv data struct and remove of_get_phy_mode()
in stm32_dwmac_parse_data().


> +{
> +       struct stm32_dwmac *dwmac = priv;
> +       struct regmap *regmap = dwmac->regmap;
> +       int ret, iface = dwmac->interface;
> +       u32 reg = dwmac->mode_reg;
> +       u32 val;
> +
> +       ret = clk_prepare_enable(dwmac->clk_tx);
> +       if (ret)
> +               goto out;
> +
> +       ret = clk_prepare_enable(dwmac->clk_rx);
> +       if (ret)
> +               goto out_disable_clk_tx;
> +
> +       val = (iface == PHY_INTERFACE_MODE_MII) ? 0 : 1;
> +       ret = regmap_update_bits(regmap, reg, MII_PHY_SEL_MASK, val);
> +       if (ret)
> +               goto out_disable_clk_tx_rx;
> +
> +       return 0;
> +
> +out_disable_clk_tx_rx:
> +       clk_disable_unprepare(dwmac->clk_rx);
> +out_disable_clk_tx:
> +       clk_disable_unprepare(dwmac->clk_tx);
> +out:
> +       return ret;
> +}
> +
> +static void stm32_dwmac_exit(void *priv)
> +{
> +       struct stm32_dwmac *dwmac = priv;

Again; instead of 'void *' use 'struct stm32_dwmac *' to avoid the
local assignment.


> +
> +       clk_disable_unprepare(dwmac->clk_tx);
> +       clk_disable_unprepare(dwmac->clk_rx);
> +}

To be honest I really don't see the point in having a function with
just two other function calls in it. Consider dropping the function
altogether and place the clk_disable_unprepare() calls where it's
called from. If you still want to keep it, please put a more
descriptive name on it.


> +static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
> +                                 struct platform_device *pdev)

Since you are only interested in *dev and not *pdev you could pass a
'struct dev *' instead.

> +{
> +       struct device *dev = &pdev->dev;
> +       struct device_node *np = dev->of_node;
> +       struct regmap *regmap;
> +       int err;
> +
> +       /*  Get TX/RX clocks */
> +       dwmac->clk_tx = devm_clk_get(dev, "tx-clk");
> +       if (IS_ERR(dwmac->clk_tx)) {
> +               dev_warn(dev, "No tx clock provided...\n");
> +               dwmac->clk_tx = NULL;
> +       }
> +       dwmac->clk_rx = devm_clk_get(dev, "rx-clk");
> +       if (IS_ERR(dwmac->clk_rx)) {
> +               dev_warn(dev, "No rx clock provided...\n");
> +               dwmac->clk_rx = NULL;
> +       }
> +
> +       /* Get mode register */
> +       regmap = syscon_regmap_lookup_by_phandle(np, "st,syscon");
> +       if (IS_ERR(regmap))
> +               return PTR_ERR(regmap);
> +
> +       err = of_property_read_u32_index(np, "st,syscon", 1, &dwmac->mode_reg);
> +       if (err) {
> +               dev_err(dev, "Can't get sysconfig mode offset (%d)\n", err);
> +               return err;
> +       }
> +
> +       dwmac->interface = of_get_phy_mode(np);
> +       dwmac->regmap = regmap;

Why the temporary local regmap variable?

Assigning dwmac->regmap with syscon_regmap_lookup_by_phandle() should
not exceed 80 chars if that is what you are worried about.


> +       return 0;
> +}
> +
> +static int stm32_dwmac_probe(struct platform_device *pdev)
> +{
> +       struct plat_stmmacenet_data *plat_dat;
> +       struct stmmac_resources stmmac_res;
> +       struct stm32_dwmac *dwmac;
> +       int ret;
> +
> +       ret = stmmac_get_platform_resources(pdev, &stmmac_res);
> +       if (ret)
> +               return ret;
> +
> +       plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
> +       if (IS_ERR(plat_dat))
> +               return PTR_ERR(plat_dat);
> +
> +       dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
> +       if (!dwmac)
> +               return -ENOMEM;
> +
> +       ret = stm32_dwmac_parse_data(dwmac, pdev);
> +       if (ret) {
> +               dev_err(&pdev->dev, "Unable to parse OF data\n");
> +               return ret;
> +       }
> +
> +       plat_dat->bsp_priv = dwmac;
> +
> +       ret = stm32_dwmac_init(plat_dat->bsp_priv);
> +       if (ret)
> +               return ret;
> +
> +       return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);

Note that stmmac_dvr_probe() can fail and if so you should disable
your tx/rx clks before you return.

Consider putting the clk_prepare_enable() directly here and use goto
labels for the clean up like most other drivers do in probe.

Also if you put regmap_update_bits() for phy mode above the
clk_prepare_enable() calls you remove one of the gotos.
I assume you don't need to enable tx/rx clock before you write to syscon.


> +static int stm32_dwmac_remove(struct platform_device *pdev)
> +{
> +       struct net_device *ndev = platform_get_drvdata(pdev);
> +       struct stmmac_priv *priv = netdev_priv(ndev);
> +       int ret = stmmac_dvr_remove(ndev);
> +
> +       stm32_dwmac_exit(priv->plat->bsp_priv);
> +
> +       return ret;
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int stm32_dwmac_suspend(struct device *dev)
> +{
> +       struct net_device *ndev = dev_get_drvdata(dev);
> +       struct stmmac_priv *priv = netdev_priv(ndev);
> +       int ret;
> +
> +       ret = stmmac_suspend(ndev);
> +       stm32_dwmac_exit(priv->plat->bsp_priv);
> +
> +       return ret;
> +}
> +
> +static int stm32_dwmac_resume(struct device *dev)
> +{
> +       struct net_device *ndev = dev_get_drvdata(dev);
> +       struct stmmac_priv *priv = netdev_priv(ndev);
> +       int ret;
> +
> +       ret = stm32_dwmac_init(priv->plat->bsp_priv);
> +       if (ret)
> +               goto out_regmap;
> +
> +       ret = stmmac_resume(ndev);
> +
> +out_regmap:
> +       return ret;

Why the goto?

This could be written:
    ret = stm32_dwmac_init(priv->plat->bsp_priv);
    if (ret)
       return ret;

    return stmmac_resume(ndev);


regards,
Joachim Eastwood


From robh at kernel.org  Tue Feb 23 14:17:22 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 23 Feb 2016 16:17:22 -0600
Subject: [PATCH 2/4] dt-bindings: add bindings for rk3399 clock controller
In-Reply-To: <1456210864-29037-3-git-send-email-jay.xu@rock-chips.com>
References: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
 <1456210864-29037-3-git-send-email-jay.xu@rock-chips.com>
Message-ID: <20160223221722.GA8375@rob-hp-laptop>

On Tue, Feb 23, 2016 at 03:01:02PM +0800, jianqun.xu wrote:
> From: Xing Zheng <zhengxing at rock-chips.com>
> 
> Add devicetree bindings for Rockchip cru which found on
> Rockchip SoCs.
> 
> Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
> Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
> ---
>  .../bindings/clock/rockchip,rk3399-cru.txt         | 82 ++++++++++++++++++++++
>  1 file changed, 82 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt


Acked-by: Rob Herring <robh at kernel.org>


From eric at anholt.net  Tue Feb 23 14:21:48 2016
From: eric at anholt.net (Eric Anholt)
Date: Tue, 23 Feb 2016 14:21:48 -0800
Subject: [PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard
 groups.
In-Reply-To: <1456266111-2508-1-git-send-email-eric@anholt.net>
References: <1456266111-2508-1-git-send-email-eric@anholt.net>
Message-ID: <1456266111-2508-3-git-send-email-eric@anholt.net>

Since all of these pins were documented, we can use their names to
explain what's going on.

Signed-off-by: Eric Anholt <eric at anholt.net>
---
 arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 17 ++++++++++-------
 arch/arm/boot/dts/bcm2835-rpi-a.dts      | 17 ++++++++++-------
 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 17 ++++++++++-------
 arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 17 ++++++++++-------
 arch/arm/boot/dts/bcm2835-rpi-b.dts      | 10 +++++++++-
 arch/arm/boot/dts/bcm2835-rpi.dtsi       |  5 -----
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts    | 17 ++++++++++-------
 7 files changed, 59 insertions(+), 41 deletions(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
index 228614f..0a8b92e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
@@ -21,11 +21,14 @@
 };
 
 &gpio {
-	pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
-
-	/* I2S interface */
-	i2s_alt0: i2s_alt0 {
-		brcm,pins = <18 19 20 21>;
-		brcm,function = <BCM2835_FSEL_ALT0>;
-	};
+	pinctrl-0 = <&i2c0_gpio0
+		     &i2c1_gpio2
+		     &gpclk0_gpio4
+		     &gpclk1_gpio5
+		     &spi0_gpio7
+		     &pcm_gpio18
+		     &pwm0_gpio40
+		     &pwm1_gpio45
+		     &gpioout
+		     &alt3>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a.dts b/arch/arm/boot/dts/bcm2835-rpi-a.dts
index ddbbbbd..d093407 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a.dts
@@ -14,11 +14,14 @@
 };
 
 &gpio {
-	pinctrl-0 = <&gpioout &alt0 &i2s_alt2 &alt3>;
-
-	/* I2S interface */
-	i2s_alt2: i2s_alt2 {
-		brcm,pins = <28 29 30 31>;
-		brcm,function = <BCM2835_FSEL_ALT2>;
-	};
+	pinctrl-0 = <&i2c0_gpio0
+		     &i2c1_gpio2
+		     &gpclk0_gpio4
+		     &gpclk1_gpio5
+		     &spi0_gpio7
+		     &pcm_gpio28
+		     &pwm0_gpio40
+		     &pwm1_gpio45
+		     &gpioout
+		     &alt3>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index ef54050..c26b81d 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -21,11 +21,14 @@
 };
 
 &gpio {
-	pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
-
-	/* I2S interface */
-	i2s_alt0: i2s_alt0 {
-		brcm,pins = <18 19 20 21>;
-		brcm,function = <BCM2835_FSEL_ALT0>;
-	};
+	pinctrl-0 = <&i2c0_gpio0
+		     &i2c1_gpio2
+		     &gpclk0_gpio4
+		     &gpclk1_gpio5
+		     &spi0_gpio7
+		     &pcm_gpio18
+		     &pwm0_gpio40
+		     &pwm1_gpio45
+		     &gpioout
+		     &alt3>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
index 86f1f2f..a5b606e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
@@ -14,11 +14,14 @@
 };
 
 &gpio {
-	pinctrl-0 = <&gpioout &alt0 &i2s_alt2 &alt3>;
-
-	/* I2S interface */
-	i2s_alt2: i2s_alt2 {
-		brcm,pins = <28 29 30 31>;
-		brcm,function = <BCM2835_FSEL_ALT2>;
-	};
+	pinctrl-0 = <&i2c0_gpio0
+		     &i2c1_gpio2
+		     &gpclk0_gpio4
+		     &gpclk1_gpio5
+		     &spi0_gpio7
+		     &pcm_gpio28
+		     &pwm0_gpio40
+		     &pwm1_gpio45
+		     &gpioout
+		     &alt3>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index 4859e9d..97e3c2f 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -14,5 +14,13 @@
 };
 
 &gpio {
-	pinctrl-0 = <&gpioout &alt0 &alt3>;
+	pinctrl-0 = <&i2c0_gpio0
+		     &i2c1_gpio2
+		     &gpclk0_gpio4
+		     &gpclk1_gpio5
+		     &spi0_gpio7
+		     &pwm0_gpio40
+		     &pwm1_gpio45
+		     &gpioout
+		     &alt3>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 76bdbca..141b18c 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -37,11 +37,6 @@
 		brcm,function = <BCM2835_FSEL_GPIO_OUT>;
 	};
 
-	alt0: alt0 {
-		brcm,pins = <0 1 2 3 4 5 7 8 9 10 11 14 15 40 45>;
-		brcm,function = <BCM2835_FSEL_ALT0>;
-	};
-
 	alt3: alt3 {
 		brcm,pins = <48 49 50 51 52 53>;
 		brcm,function = <BCM2835_FSEL_ALT3>;
diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index ff94666..52798ca 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -25,11 +25,14 @@
 };
 
 &gpio {
-	pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
-
-	/* I2S interface */
-	i2s_alt0: i2s_alt0 {
-		brcm,pins = <18 19 20 21>;
-		brcm,function = <BCM2835_FSEL_ALT0>;
-	};
+	pinctrl-0 = <&i2c0_gpio0
+		     &i2c1_gpio2
+		     &gpclk0_gpio4
+		     &gpclk1_gpio5
+		     &spi0_gpio7
+		     &pcm_gpio18
+		     &pwm0_gpio40
+		     &pwm1_gpio45
+		     &gpioout
+		     &alt3>;
 };
-- 
2.7.0



From robert.jarzmik at free.fr  Tue Feb 23 14:23:42 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Tue, 23 Feb 2016 23:23:42 +0100
Subject: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB
 mappings
In-Reply-To: <CAPcyv4h86uzieFV4HM-tZoWSVZ7GY2GKEUk334J+5sD_GyzWKg@mail.gmail.com>
 (Dan Williams's message of "Tue, 23 Feb 2016 09:21:44 -0800")
References: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456149728-16706-2-git-send-email-ard.biesheuvel@linaro.org>
 <CAPcyv4ivN9c8PHBR77vd36ovB28OETJUr6VYf_8gNtXgqEmATw@mail.gmail.com>
 <CAKv+Gu9OWVgo+Qm85jPjY7xJ1UELm-4LYORHKF8Yy+_HuzmtGw@mail.gmail.com>
 <20160222200227.GF19428@n2100.arm.linux.org.uk>
 <CAKv+Gu9gwnuu7hnYpjv7ozuKYmC8ApMakSJmYvQMaevNEd5zvA@mail.gmail.com>
 <20160223115835.GI19428@n2100.arm.linux.org.uk>
 <CAKv+Gu8oCnu6kv5SxUAdWE_Z0V+PMAKDgM6MxTi4mTm5z6EFqA@mail.gmail.com>
 <CAKv+Gu_iEOC6E+N28pp9eEJxWFYTgLaQcBYEy1SvTUHT=cybYA@mail.gmail.com>
 <CAPcyv4h86uzieFV4HM-tZoWSVZ7GY2GKEUk334J+5sD_GyzWKg@mail.gmail.com>
Message-ID: <87twkzukup.fsf@belgarion.home>

Dan Williams <dan.j.williams at intel.com> writes:

> On Tue, Feb 23, 2016 at 4:26 AM, Ard Biesheuvel
> <ard.biesheuvel at linaro.org> wrote:
>> On 23 February 2016 at 13:03, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>>> On 23 February 2016 at 12:58, Russell King - ARM Linux
>>> <linux at arm.linux.org.uk> wrote:
>>>> On Mon, Feb 22, 2016 at 09:35:24PM +0100, Ard Biesheuvel wrote:
>> OK, I see what you mean. I find it unfortunate that ioremap_cache()
>> instances are blindly being replaced with memremap(), and I wonder if
>> this wasted test by and/or cc'ed to people who can actually test this
>> driver. Dan?

Actually I have the hardware to test it.

And I also know what is behind :
 - it's a CFI NOR based memory
 - these are Intel StrataFlash 28F128J3A chips
 - as a CFI memory it is mapped on the system bus
 - from a read perspective, it behaves like a normal memory
 - but once the first write reaches the CFI, everything changes (the address
   space layout doesn't have the same meaning, be that becoming a status code or
   something else).
   In these conditions reordering of writes versus reads, merging reads after
   a write or coalescing writes is a recipe for disaster.

All of this to say I can make a small discrete number of tests (less than 10
write or erase ones to preserve the precious NOR).

Cheers.

--
Robert


From manabian at gmail.com  Tue Feb 23 14:37:55 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Tue, 23 Feb 2016 23:37:55 +0100
Subject: [PATCH v2 2/4] Documentation: Bindings: Add STM32 DWMAC glue
In-Reply-To: <1456240244-10275-3-git-send-email-alexandre.torgue@gmail.com>
References: <1456240244-10275-1-git-send-email-alexandre.torgue@gmail.com>
 <1456240244-10275-3-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <CAGhQ9VwsSb-Nb4nQ4Q9=b-Dj_8EhSi=LOK-r4JbKcE=nfODufw@mail.gmail.com>

Hi Alexandre,

You should copy 'devicetree at vger.kernel.org' on bindings doc. Adding cc here.

On 23 February 2016 at 16:10, Alexandre TORGUE
<alexandre.torgue at gmail.com> wrote:
> Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>
>
> diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
> new file mode 100644
> index 0000000..18734b3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
> @@ -0,0 +1,41 @@
> +STMicroelectronics STM32 / MCU DWMAC glue layer controller
> +
> +This file documents platform glue layer for stmmac.
> +Please see stmmac.txt for the other unchanged properties.
> +
> +The device node has following properties.
> +
> +Required properties:
> +- compatible:  Should be "st,stm32-dwmac" to select glue, and
> +              "snps,dwmac-3.50a" to select IP vesrion.
> +- clocks: Should contain the GMAC main clock, and tx clock
> +- compatible:  Should be "st,stm32-dwmac" to select glue and
> +              "snps,dwmac-3.50a" to select IP version.
> +- clocks: Should contain the MAC main clock
> +- clock-names: Should contain the clock names "stmmaceth".
> +- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
> +             encompases the glue register, and the offset of the control register.
> +
> +Optional properties:
> +- clocks: Could contain:
> +       - the tx clock,
> +       - the rx clock
> +- clock-names: Could contain the clock names "tx-clk", "rx-clk"
> +
> +Example:
> +
> +               ethernet0: dwmac at 40028000 {
> +                       device_type = "network";

What is this 'device_type = "network"' for?
It seems to used in a lot of powerpc DTs, but only a couple of arm DTs.

Maybe Rob could enlighten us?

> +                       compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
> +                       status = "disabled";
> +                       reg = <0x40028000 0x8000>;
> +                       reg-names = "stmmaceth";
> +                       interrupts = <0 61 0>, <0 62 0>;
> +                       interrupt-names = "macirq", "eth_wake_irq";
> +                       clock-names = "stmmaceth", "tx-clk", "rx-clk";
> +                       clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
> +                       st,syscon = <&syscfg 0x4>;
> +                       snps,pbl = <32>;

Regarding snps,pbl; using 32 here might not give you what you would except.
See comment in dwmac1000_dma_init().

The driver is hard coded to use PBL4X/PBL8X mode. Just a heads up.


regards,
Joachim Eastwood


From hdegoede at redhat.com  Tue Feb 23 15:03:15 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Wed, 24 Feb 2016 00:03:15 +0100
Subject: [PATCH 0/2] ARM: dts: sun8i: Add ir receiver nodes for H3
Message-ID: <1456268597-13692-1-git-send-email-hdegoede@redhat.com>

Hi All,

Here is a set of patches for H3 ir receiver support, tested on an
orangepi pc. This series applies on top of the R_PIO series for H3.

Regards,

Hans


From hdegoede at redhat.com  Tue Feb 23 15:03:16 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Wed, 24 Feb 2016 00:03:16 +0100
Subject: [PATCH 1/2] ARM: dts: sun8i: Add ir receiver nodes to H3 dtsi
In-Reply-To: <1456268597-13692-1-git-send-email-hdegoede@redhat.com>
References: <1456268597-13692-1-git-send-email-hdegoede@redhat.com>
Message-ID: <1456268597-13692-2-git-send-email-hdegoede@redhat.com>

The H3 ir receiver is completely compatible with the one found in the A31.

Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 3fdf213..c2f63c5 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -307,6 +307,14 @@
 			clock-indices = <0>, <1>;
 			clock-output-names = "apb0_pio", "apb0_ir";
 		};
+
+		ir_clk: ir_clk at 01f01454 {
+			compatible = "allwinner,sun4i-a10-mod0-clk";
+			reg = <0x01f01454 0x4>;
+			#clock-cells = <0>;
+			clocks = <&osc32k>, <&osc24M>;
+			clock-output-names = "ir";
+		};
 	};
 
 	soc {
@@ -632,6 +640,16 @@
 			#reset-cells = <1>;
 		};
 
+		ir: ir at 01f02000 {
+			compatible = "allwinner,sun5i-a13-ir";
+			clocks = <&apb0_gates 1>, <&ir_clk>;
+			clock-names = "apb", "ir";
+			resets = <&apb0_reset 1>;
+			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+			reg = <0x01f02000 0x40>;
+			status = "disabled";
+		};
+
 		r_pio: pinctrl at 01f02c00 {
 			compatible = "allwinner,sun8i-h3-r-pinctrl";
 			reg = <0x01f02c00 0x400>;
@@ -642,6 +660,13 @@
 			#gpio-cells = <3>;
 			interrupt-controller;
 			#interrupt-cells = <3>;
+
+			ir_pins_a: ir at 0 {
+				allwinner,pins = "PL11";
+				allwinner,function = "s_cir_rx";
+				allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+				allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+			};
 		};
 	};
 };
-- 
2.7.1



From hdegoede at redhat.com  Tue Feb 23 15:03:17 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Wed, 24 Feb 2016 00:03:17 +0100
Subject: [PATCH 2/2] ARM: dts: sun8i: Enable ir receiver on orangepi pc
In-Reply-To: <1456268597-13692-1-git-send-email-hdegoede@redhat.com>
References: <1456268597-13692-1-git-send-email-hdegoede@redhat.com>
Message-ID: <1456268597-13692-3-git-send-email-hdegoede@redhat.com>

Enable the ir receiver found on the orangepi pc board.

Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
 arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
index 4b25dcc..dc73b2a 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
@@ -72,6 +72,12 @@
 	status = "okay";
 };
 
+&ir {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ir_pins_a>;
+	status = "okay";
+};
+
 &mmc0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
-- 
2.7.1



From adam.buchbinder at gmail.com  Tue Feb 23 15:26:05 2016
From: adam.buchbinder at gmail.com (Adam Buchbinder)
Date: Tue, 23 Feb 2016 15:26:05 -0800
Subject: [PATCH] ARM: Fix misspellings in comments.
Message-ID: <1456269965-25963-1-git-send-email-adam.buchbinder@gmail.com>

Signed-off-by: Adam Buchbinder <adam.buchbinder at gmail.com>
---
 arch/arm/boot/dts/exynos3250.dtsi                    | 4 ++--
 arch/arm/boot/dts/exynos4.dtsi                       | 2 +-
 arch/arm/boot/dts/exynos4210.dtsi                    | 4 ++--
 arch/arm/boot/dts/exynos4212.dtsi                    | 4 ++--
 arch/arm/boot/dts/exynos4412.dtsi                    | 4 ++--
 arch/arm/boot/dts/exynos4x12.dtsi                    | 4 ++--
 arch/arm/boot/dts/exynos5.dtsi                       | 2 +-
 arch/arm/boot/dts/exynos5250.dtsi                    | 2 +-
 arch/arm/boot/dts/exynos5410.dtsi                    | 2 +-
 arch/arm/boot/dts/exynos5420.dtsi                    | 2 +-
 arch/arm/boot/dts/exynos5800.dtsi                    | 2 +-
 arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi            | 2 +-
 arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi            | 2 +-
 arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi | 2 +-
 arch/arm/boot/dts/r8a7779.dtsi                       | 2 +-
 arch/arm/boot/dts/r8a7790.dtsi                       | 2 +-
 arch/arm/boot/dts/r8a7791.dtsi                       | 2 +-
 arch/arm/boot/dts/r8a7794.dtsi                       | 2 +-
 arch/arm/boot/dts/s3c6400.dtsi                       | 4 ++--
 arch/arm/boot/dts/s3c6410.dtsi                       | 4 ++--
 arch/arm/boot/dts/s3c64xx.dtsi                       | 2 +-
 arch/arm/boot/dts/s5pv210-pinctrl.dtsi               | 4 ++--
 arch/arm/boot/dts/s5pv210.dtsi                       | 4 ++--
 arch/arm/boot/dts/tegra114.dtsi                      | 2 +-
 arch/arm/boot/dts/tegra124.dtsi                      | 2 +-
 arch/arm/boot/dts/tegra20.dtsi                       | 2 +-
 arch/arm/boot/dts/tegra30.dtsi                       | 2 +-
 arch/arm/include/asm/kvm_asm.h                       | 8 ++++----
 arch/arm/include/asm/pgtable-2level.h                | 2 +-
 arch/arm/include/asm/uaccess.h                       | 2 +-
 arch/arm/include/asm/xen/page-coherent.h             | 2 +-
 arch/arm/kernel/cpuidle.c                            | 4 ++--
 arch/arm/kernel/hyp-stub.S                           | 2 +-
 arch/arm/kernel/kgdb.c                               | 4 ++--
 arch/arm/kvm/interrupts.S                            | 2 +-
 arch/arm/mach-davinci/board-dm355-evm.c              | 2 +-
 arch/arm/mach-davinci/board-dm365-evm.c              | 2 +-
 arch/arm/mach-davinci/board-dm644x-evm.c             | 2 +-
 arch/arm/mach-imx/mm-imx3.c                          | 2 +-
 arch/arm/mach-imx/tzic.c                             | 2 +-
 arch/arm/mach-ixp4xx/ixp4xx_npe.c                    | 2 +-
 arch/arm/mach-omap1/clock_data.c                     | 2 +-
 arch/arm/mach-omap2/dma.c                            | 2 +-
 arch/arm/mach-pxa/include/mach/palmtx.h              | 2 +-
 arch/arm/mach-pxa/include/mach/trizeps4.h            | 2 +-
 arch/arm/mach-pxa/palmt5.h                           | 2 +-
 arch/arm/mach-pxa/palmte2.h                          | 2 +-
 arch/arm/mach-pxa/palmz72.h                          | 2 +-
 arch/arm/mach-s3c24xx/bast.h                         | 2 +-
 arch/arm/mach-s3c24xx/vr1000.h                       | 2 +-
 arch/arm/mach-s3c64xx/include/mach/irqs.h            | 2 +-
 arch/arm/mach-s5pv210/regs-clock.h                   | 2 +-
 arch/arm/mach-tegra/pm.c                             | 2 +-
 arch/arm/mm/context.c                                | 4 ++--
 arch/arm/plat-omap/dmtimer.c                         | 2 +-
 arch/arm/plat-samsung/include/plat/gpio-cfg.h        | 2 +-
 arch/arm/probes/kprobes/test-core.c                  | 2 +-
 arch/arm/xen/hypercall.S                             | 4 ++--
 58 files changed, 74 insertions(+), 74 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 18e3def..9a2afec 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -5,8 +5,8 @@
  *		http://www.samsung.com
  *
  * Samsung's Exynos3250 SoC device nodes are listed in this file. Exynos3250
- * based board files can include this file and provide values for board specfic
- * bindings.
+ * based board files can include this file and provide values for board
+ * specific bindings.
  *
  * Note: This file does not include device nodes for all the controllers in
  * Exynos3250 SoC. As device tree coverage for Exynos3250 increases, additional
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 045785c..5503d54 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -8,7 +8,7 @@
  *
  * Samsung's Exynos4 SoC series device nodes are listed in this file.  Particular
  * SoCs from Exynos4 series can include this file and provide values for SoCs
- * specfic bindings.
+ * specific bindings.
  *
  * Note: This file does not include device nodes for all the controllers in
  * Exynos4 SoCs. As device tree coverage for Exynos4 increases, additional
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index c1cb8df..ba1852a 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -7,8 +7,8 @@
  *		www.linaro.org
  *
  * Samsung's Exynos4210 SoC device nodes are listed in this file. Exynos4210
- * based board files can include this file and provide values for board specfic
- * bindings.
+ * based board files can include this file and provide values for board
+ * specific bindings.
  *
  * Note: This file does not include device nodes for all the controllers in
  * Exynos4210 SoC. As device tree coverage for Exynos4210 increases, additional
diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
index 5389011..d993eb0 100644
--- a/arch/arm/boot/dts/exynos4212.dtsi
+++ b/arch/arm/boot/dts/exynos4212.dtsi
@@ -5,8 +5,8 @@
  *		http://www.samsung.com
  *
  * Samsung's Exynos4212 SoC device nodes are listed in this file. Exynos4212
- * based board files can include this file and provide values for board specfic
- * bindings.
+ * based board files can include this file and provide values for board
+ * specific bindings.
  *
  * Note: This file does not include device nodes for all the controllers in
  * Exynos4212 SoC. As device tree coverage for Exynos4212 increases, additional
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 40beede..0896878 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -5,8 +5,8 @@
  *		http://www.samsung.com
  *
  * Samsung's Exynos4412 SoC device nodes are listed in this file. Exynos4412
- * based board files can include this file and provide values for board specfic
- * bindings.
+ * based board files can include this file and provide values for board
+ * specific bindings.
  *
  * Note: This file does not include device nodes for all the controllers in
  * Exynos4412 SoC. As device tree coverage for Exynos4412 increases, additional
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index 84a23f9..7358359 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -5,8 +5,8 @@
  *		http://www.samsung.com
  *
  * Samsung's Exynos4x12 SoCs device nodes are listed in this file. Exynos4x12
- * based board files can include this file and provide values for board specfic
- * bindings.
+ * based board files can include this file and provide values for board
+ * specific bindings.
  *
  * Note: This file does not include device nodes for all the controllers in
  * Exynos4x12 SoC. As device tree coverage for Exynos4x12 increases, additional
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index e2439e8..7ef446c 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -6,7 +6,7 @@
  *
  * Samsung's Exynos5 SoC series device nodes are listed in this file. Particular
  * SoCs from Exynos5 series can include this file and provide values for SoCs
- * specfic bindings.
+ * specific bindings.
  *
  * 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
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 33e2d5f..b576611 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -6,7 +6,7 @@
  *
  * SAMSUNG EXYNOS5250 SoC device nodes are listed in this file.
  * EXYNOS5250 based board files can include this file and provide
- * values for board specfic bindings.
+ * values for board specific bindings.
  *
  * Note: This file does not include device nodes for all the controllers in
  * EXYNOS5250 SoC. As device tree coverage for EXYNOS5250 increases,
diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
index fad0779..dfc01c6 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -6,7 +6,7 @@
  *
  * SAMSUNG EXYNOS5410 SoC device nodes are listed in this file.
  * EXYNOS5410 based board files can include this file and provide
- * values for board specfic bindings.
+ * values for board specific bindings.
  *
  * 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
diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 48a0a55..55373f4 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -6,7 +6,7 @@
  *
  * SAMSUNG EXYNOS54200 SoC device nodes are listed in this file.
  * EXYNOS5420 based board files can include this file and provide
- * values for board specfic bindings.
+ * values for board specific bindings.
  *
  * 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
diff --git a/arch/arm/boot/dts/exynos5800.dtsi b/arch/arm/boot/dts/exynos5800.dtsi
index c0bb356..15d98bf 100644
--- a/arch/arm/boot/dts/exynos5800.dtsi
+++ b/arch/arm/boot/dts/exynos5800.dtsi
@@ -6,7 +6,7 @@
  *
  * SAMSUNG EXYNOS5800 SoC device nodes are listed in this file.
  * EXYNOS5800 based board files can include this file and provide
- * values for board specfic bindings.
+ * values for board specific bindings.
  *
  * 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
diff --git a/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi b/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
index 445fafc..9c74c99 100644
--- a/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
+++ b/arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
@@ -1,7 +1,7 @@
 /*
  * Common file for GPMC connected smsc911x on omaps
  *
- * Note that the board specifc DTS file needs to specify
+ * Note that the board specific DTS file needs to specify
  * ranges, pinctrl, reg, interrupt parent and interrupts.
  */
 
diff --git a/arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi b/arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi
index 73e272f..7f37b00 100644
--- a/arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi
+++ b/arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi
@@ -5,7 +5,7 @@
  * or smsc 9218) has faster timings, leading to higher
  * bandwidth.
  *
- * Note that the board specifc DTS file needs to specify
+ * Note that the board specific DTS file needs to specify
  * ranges, pinctrl, reg, interrupt parent and interrupts.
  */
 
diff --git a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
index 157345b..3a26dbf 100644
--- a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -1,7 +1,7 @@
 /*
  * Common file for omap dpi panels with QVGA and reset pins
  *
- * Note that the board specifc DTS file needs to specify
+ * Note that the board specific DTS file needs to specify
  * at minimum the GPIO enable-gpios for display, and
  * gpios for gpio-backlight.
  */
diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 6afa909..f3e2925 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -436,7 +436,7 @@
 		extal_clk: extal_clk {
 			compatible = "fixed-clock";
 			#clock-cells = <0>;
-			/* This value must be overriden by the board. */
+			/* This value must be overridden by the board. */
 			clock-frequency = <0>;
 			clock-output-names = "extal";
 		};
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 7dfd393..717dece 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -949,7 +949,7 @@
 		extal_clk: extal_clk {
 			compatible = "fixed-clock";
 			#clock-cells = <0>;
-			/* This value must be overriden by the board. */
+			/* This value must be overridden by the board. */
 			clock-frequency = <0>;
 			clock-output-names = "extal";
 		};
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 2a369dd..1bb450e 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -994,7 +994,7 @@
 		extal_clk: extal_clk {
 			compatible = "fixed-clock";
 			#clock-cells = <0>;
-			/* This value must be overriden by the board. */
+			/* This value must be overridden by the board. */
 			clock-frequency = <0>;
 			clock-output-names = "extal";
 		};
diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 6c78f1f..2b52360 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -792,7 +792,7 @@
 		extal_clk: extal_clk {
 			compatible = "fixed-clock";
 			#clock-cells = <0>;
-			/* This value must be overriden by the board. */
+			/* This value must be overridden by the board. */
 			clock-frequency = <0>;
 			clock-output-names = "extal";
 		};
diff --git a/arch/arm/boot/dts/s3c6400.dtsi b/arch/arm/boot/dts/s3c6400.dtsi
index a7d1c8e..fc371bb 100644
--- a/arch/arm/boot/dts/s3c6400.dtsi
+++ b/arch/arm/boot/dts/s3c6400.dtsi
@@ -4,8 +4,8 @@
  * Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.com>
  *
  * Samsung's S3C6400 SoC device nodes are listed in this file. S3C6400
- * based board files can include this file and provide values for board specfic
- * bindings.
+ * based board files can include this file and provide values for board
+ * specific bindings.
  *
  * Note: This file does not include device nodes for all the controllers in
  * S3C6400 SoC. As device tree coverage for S3C6400 increases, additional
diff --git a/arch/arm/boot/dts/s3c6410.dtsi b/arch/arm/boot/dts/s3c6410.dtsi
index eb4226b..c527033 100644
--- a/arch/arm/boot/dts/s3c6410.dtsi
+++ b/arch/arm/boot/dts/s3c6410.dtsi
@@ -4,8 +4,8 @@
  * Copyright (c) 2013 Tomasz Figa <tomasz.figa at gmail.com>
  *
  * Samsung's S3C6410 SoC device nodes are listed in this file. S3C6410
- * based board files can include this file and provide values for board specfic
- * bindings.
+ * based board files can include this file and provide values for board
+ * specific bindings.
  *
  * Note: This file does not include device nodes for all the controllers in
  * S3C6410 SoC. As device tree coverage for S3C6410 increases, additional
diff --git a/arch/arm/boot/dts/s3c64xx.dtsi b/arch/arm/boot/dts/s3c64xx.dtsi
index 0ccb414..3852736 100644
--- a/arch/arm/boot/dts/s3c64xx.dtsi
+++ b/arch/arm/boot/dts/s3c64xx.dtsi
@@ -5,7 +5,7 @@
  *
  * Samsung's S3C64xx SoC series device nodes are listed in this file.
  * Particular SoCs from S3C64xx series can include this file and provide
- * values for SoCs specfic bindings.
+ * values for SoCs specific bindings.
  *
  * Note: This file does not include device nodes for all the controllers in
  * S3C64xx SoCs. As device tree coverage for S3C64xx increases, additional
diff --git a/arch/arm/boot/dts/s5pv210-pinctrl.dtsi b/arch/arm/boot/dts/s5pv210-pinctrl.dtsi
index 8c71408..4b1bbe6 100644
--- a/arch/arm/boot/dts/s5pv210-pinctrl.dtsi
+++ b/arch/arm/boot/dts/s5pv210-pinctrl.dtsi
@@ -7,8 +7,8 @@
  * Tomasz Figa <t.figa at samsung.com>
  *
  * Samsung's S5PV210 SoC device nodes are listed in this file. S5PV210
- * based board files can include this file and provide values for board specfic
- * bindings.
+ * based board files can include this file and provide values for board
+ * specific bindings.
  *
  * Note: This file does not include device nodes for all the controllers in
  * S5PV210 SoC. As device tree coverage for S5PV210 increases, additional
diff --git a/arch/arm/boot/dts/s5pv210.dtsi b/arch/arm/boot/dts/s5pv210.dtsi
index 8344a0e..e030218 100644
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -7,8 +7,8 @@
  * Tomasz Figa <t.figa at samsung.com>
  *
  * Samsung's S5PV210 SoC device nodes are listed in this file. S5PV210
- * based board files can include this file and provide values for board specfic
- * bindings.
+ * based board files can include this file and provide values for board
+ * specific bindings.
  *
  * Note: This file does not include device nodes for all the controllers in
  * S5PV210 SoC. As device tree coverage for S5PV210 increases, additional
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index d845bd1..f9a700f 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -254,7 +254,7 @@
 	/*
 	 * There are two serial driver i.e. 8250 based simple serial
 	 * driver and APB DMA based serial driver for higher baudrate
-	 * and performace. To enable the 8250 based driver, the compatible
+	 * and performance. To enable the 8250 based driver, the compatible
 	 * is "nvidia,tegra114-uart", "nvidia,tegra20-uart" and to enable
 	 * the APB DMA based serial driver, the comptible is
 	 * "nvidia,tegra114-hsuart", "nvidia,tegra30-hsuart".
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 68669f7..260bc1f 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -320,7 +320,7 @@
 	/*
 	 * There are two serial driver i.e. 8250 based simple serial
 	 * driver and APB DMA based serial driver for higher baudrate
-	 * and performace. To enable the 8250 based driver, the compatible
+	 * and performance. To enable the 8250 based driver, the compatible
 	 * is "nvidia,tegra124-uart", "nvidia,tegra20-uart" and to enable
 	 * the APB DMA based serial driver, the comptible is
 	 * "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart".
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 33173e1..503c5df 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -307,7 +307,7 @@
 	/*
 	 * There are two serial driver i.e. 8250 based simple serial
 	 * driver and APB DMA based serial driver for higher baudrate
-	 * and performace. To enable the 8250 based driver, the compatible
+	 * and performance. To enable the 8250 based driver, the compatible
 	 * is "nvidia,tegra20-uart" and to enable the APB DMA based serial
 	 * driver, the comptible is "nvidia,tegra20-hsuart".
 	 */
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 313e260..35e21c0 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -369,7 +369,7 @@
 	/*
 	 * There are two serial driver i.e. 8250 based simple serial
 	 * driver and APB DMA based serial driver for higher baudrate
-	 * and performace. To enable the 8250 based driver, the compatible
+	 * and performance. To enable the 8250 based driver, the compatible
 	 * is "nvidia,tegra30-uart", "nvidia,tegra20-uart" and to enable
 	 * the APB DMA based serial driver, the comptible is
 	 * "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart".
diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index 194c91b..c5d0af5 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -33,8 +33,8 @@
 #define c3_DACR		11	/* Domain Access Control Register */
 #define c5_DFSR		12	/* Data Fault Status Register */
 #define c5_IFSR		13	/* Instruction Fault Status Register */
-#define c5_ADFSR	14	/* Auxilary Data Fault Status R */
-#define c5_AIFSR	15	/* Auxilary Instrunction Fault Status R */
+#define c5_ADFSR	14	/* Auxiliary Data Fault Status R */
+#define c5_AIFSR	15	/* Auxiliary Instrunction Fault Status R */
 #define c6_DFAR		16	/* Data Fault Address Register */
 #define c6_IFAR		17	/* Instruction Fault Address Register */
 #define c7_PAR		18	/* Physical Address Register */
@@ -48,8 +48,8 @@
 #define c13_TID_URO	26	/* Thread ID, User R/O */
 #define c13_TID_PRIV	27	/* Thread ID, Privileged */
 #define c14_CNTKCTL	28	/* Timer Control Register (PL1) */
-#define c10_AMAIR0	29	/* Auxilary Memory Attribute Indirection Reg0 */
-#define c10_AMAIR1	30	/* Auxilary Memory Attribute Indirection Reg1 */
+#define c10_AMAIR0	29	/* Aux Memory Attribute Indirection Reg0 */
+#define c10_AMAIR1	30	/* Aux Memory Attribute Indirection Reg1 */
 #define NR_CP15_REGS	31	/* Number of regs (incl. invalid) */
 
 #define ARM_EXCEPTION_RESET	  0
diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h
index aeddd28..b37ca84 100644
--- a/arch/arm/include/asm/pgtable-2level.h
+++ b/arch/arm/include/asm/pgtable-2level.h
@@ -66,7 +66,7 @@
  *
  * However, when the "young" bit is cleared, we deny access to the page
  * by clearing the hardware PTE.  Currently Linux does not flush the TLB
- * for us in this case, which means the TLB will retain the transation
+ * for us in this case, which means the TLB will retain the transaction
  * until either the TLB entry is evicted under pressure, or a context
  * switch which changes the user space mapping occurs.
  */
diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 35c9db8..553ae49 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -53,7 +53,7 @@ extern int fixup_exception(struct pt_regs *regs);
  * These two functions allow hooking accesses to userspace to increase
  * system integrity by ensuring that the kernel can not inadvertantly
  * perform such accesses (eg, via list poison values) which could then
- * be exploited for priviledge escalation.
+ * be exploited for privilege escalation.
  */
 static inline unsigned int uaccess_save_and_enable(void)
 {
diff --git a/arch/arm/include/asm/xen/page-coherent.h b/arch/arm/include/asm/xen/page-coherent.h
index 9408a99..55cb181 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -63,7 +63,7 @@ static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
 {
 	unsigned long pfn = PFN_DOWN(handle);
 	/*
-	 * Dom0 is mapped 1:1, while the Linux page can be spanned accross
+	 * Dom0 is mapped 1:1, while the Linux page can be spanned across
 	 * multiple Xen page, it's not possible to have a mix of local and
 	 * foreign Xen page. Dom0 is mapped 1:1, so calling pfn_valid on a
 	 * foreign mfn will always return false. If the page is local we can
diff --git a/arch/arm/kernel/cpuidle.c b/arch/arm/kernel/cpuidle.c
index 703926e..b307410 100644
--- a/arch/arm/kernel/cpuidle.c
+++ b/arch/arm/kernel/cpuidle.c
@@ -91,8 +91,8 @@ static struct cpuidle_ops *__init arm_cpuidle_get_ops(const char *method)
  * cpuidle_ops are tagged __initdata and will be unloaded after the init
  * process.
  *
- * Return 0 on sucess, -ENOENT if no 'enable-method' is defined, -EOPNOTSUPP if
- * no cpuidle_ops is registered for the 'enable-method'.
+ * Return 0 on success, -ENOENT if no 'enable-method' is defined, -EOPNOTSUPP
+ * if no cpuidle_ops is registered for the 'enable-method'.
  */
 static int __init arm_cpuidle_read_ops(struct device_node *dn, int cpu)
 {
diff --git a/arch/arm/kernel/hyp-stub.S b/arch/arm/kernel/hyp-stub.S
index 2a55373..91e98cd 100644
--- a/arch/arm/kernel/hyp-stub.S
+++ b/arch/arm/kernel/hyp-stub.S
@@ -49,7 +49,7 @@ ENTRY(__boot_cpu_mode)
 	 * Compare the current mode with the one saved on the primary CPU.
 	 * If they don't match, record that fact. The Z bit indicates
 	 * if there's a match or not.
-	 * Requires 3 additionnal scratch registers.
+	 * Requires 3 additional scratch registers.
 	 */
 	.macro	compare_cpu_mode_with_primary mode, reg1, reg2, reg3
 	adr	\reg2, .L__boot_cpu_mode_offset
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index 9232cae..091f05f 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -209,9 +209,9 @@ static struct notifier_block kgdb_notifier = {
 
 
 /**
- *	kgdb_arch_init - Perform any architecture specific initalization.
+ *	kgdb_arch_init - Perform any architecture specific initialization.
  *
- *	This function will handle the initalization of any architecture
+ *	This function will handle the initialization of any architecture
  *	specific callbacks.
  */
 int kgdb_arch_init(void)
diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
index 900ef6d..30bded6 100644
--- a/arch/arm/kvm/interrupts.S
+++ b/arch/arm/kvm/interrupts.S
@@ -353,7 +353,7 @@ hyp_dabt:
 	.align
 hyp_hvc:
 	/*
-	 * Getting here is either becuase of a trap from a guest or from calling
+	 * Getting here is either because of a trap from a guest or from calling
 	 * HVC from the host kernel, which means "switch to Hyp mode".
 	 */
 	push	{r0, r1, r2}
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
index 1844076..37f6b63 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -202,7 +202,7 @@ static struct v4l2_input tvp5146_inputs[] = {
 
 /*
  * this is the route info for connecting each input to decoder
- * ouput that goes to vpfe. There is a one to one correspondence
+ * output that goes to vpfe. There is a one to one correspondence
  * with tvp5146_inputs
  */
 static struct vpfe_route tvp5146_routes[] = {
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index f073518..9d15f42 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -333,7 +333,7 @@ static struct v4l2_input tvp5146_inputs[] = {
 
 /*
  * this is the route info for connecting each input to decoder
- * ouput that goes to vpfe. There is a one to one correspondence
+ * output that goes to vpfe. There is a one to one correspondence
  * with tvp5146_inputs
  */
 static struct vpfe_route tvp5146_routes[] = {
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 7a20507..090aad8 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -217,7 +217,7 @@ static struct v4l2_input dm644xevm_tvp5146_inputs[] = {
 
 /*
  * this is the route info for connecting each input to decoder
- * ouput that goes to vpfe. There is a one to one correspondence
+ * output that goes to vpfe. There is a one to one correspondence
  * with tvp5146_inputs
  */
 static struct vpfe_route dm644xevm_tvp5146_routes[] = {
diff --git a/arch/arm/mach-imx/mm-imx3.c b/arch/arm/mach-imx/mm-imx3.c
index 0884ca9..8774fdb 100644
--- a/arch/arm/mach-imx/mm-imx3.c
+++ b/arch/arm/mach-imx/mm-imx3.c
@@ -90,7 +90,7 @@ static void __init imx3_init_l2x0(void)
 
 /*
  * First of all, we must repair broken chip settings. There are some
- * i.MX35 CPUs in the wild, comming with bogus L2 cache settings. These
+ * i.MX35 CPUs in the wild, coming with bogus L2 cache settings. These
  * misconfigured CPUs will run amok immediately when the L2 cache gets enabled.
  * Workaraound is to setup the correct register setting prior enabling the
  * L2 cache. This should not hurt already working CPUs, as they are using the
diff --git a/arch/arm/mach-imx/tzic.c b/arch/arm/mach-imx/tzic.c
index 4de65ee..50fe4f1 100644
--- a/arch/arm/mach-imx/tzic.c
+++ b/arch/arm/mach-imx/tzic.c
@@ -48,7 +48,7 @@
 #define TZIC_HIPND(i)	(0x0D80+ ((i) << 2))	/* High Priority Pending Register */
 #define TZIC_WAKEUP0(i)	(0x0E00 + ((i) << 2))	/* Wakeup Config Register */
 #define TZIC_SWINT	0x0F00	/* Software Interrupt Rigger Register */
-#define TZIC_ID0	0x0FD0	/* Indentification Register 0 */
+#define TZIC_ID0	0x0FD0	/* Identification Register 0 */
 
 static void __iomem *tzic_base;
 static struct irq_domain *domain;
diff --git a/arch/arm/mach-ixp4xx/ixp4xx_npe.c b/arch/arm/mach-ixp4xx/ixp4xx_npe.c
index d4eb09a..548b675 100644
--- a/arch/arm/mach-ixp4xx/ixp4xx_npe.c
+++ b/arch/arm/mach-ixp4xx/ixp4xx_npe.c
@@ -317,7 +317,7 @@ static int npe_reset(struct npe *npe)
 			  __raw_readl(&npe->regs->in_out_fifo));
 
 	while (__raw_readl(&npe->regs->messaging_status) & MSGSTAT_IFNE)
-		/* step execution of the NPE intruction to read inFIFO using
+		/* step execution of the NPE instruction to read inFIFO using
 		   the Debug Executing Context stack */
 		if (npe_debug_instr(npe, INSTR_RD_FIFO, 0, 0))
 			return -ETIMEDOUT;
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index 6c4f766..460d9bc 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -821,7 +821,7 @@ int __init omap1_clk_init(void)
 		omap_readw(ARM_SYSST), omap_readw(DPLL_CTL),
 		omap_readw(ARM_CKCTL));
 
-	/* We want to be in syncronous scalable mode */
+	/* We want to be in synchronous scalable mode */
 	omap_writew(0x1000, ARM_SYSST);
 
 
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index 1ed4be1..1a1efb5 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -159,7 +159,7 @@ static unsigned configure_dma_errata(void)
 	/*
 	 * Erratum ID: i378: OMAP2+: sDMA Channel is not disabled
 	 * after a transaction error.
-	 * Workaround: SW should explicitely disable the channel.
+	 * Workaround: SW should explicitly disable the channel.
 	 */
 	if (cpu_class_is_omap2())
 		SET_DMA_ERRATA(DMA_ERRATA_i378);
diff --git a/arch/arm/mach-pxa/include/mach/palmtx.h b/arch/arm/mach-pxa/include/mach/palmtx.h
index 92bc1f0..ca29d9d 100644
--- a/arch/arm/mach-pxa/include/mach/palmtx.h
+++ b/arch/arm/mach-pxa/include/mach/palmtx.h
@@ -35,7 +35,7 @@
 /* TOUCHSCREEN */
 #define GPIO_NR_PALMTX_WM9712_IRQ		27
 
-/* IRDA -  disable GPIO connected to SD pin of tranceiver (TFBS4710?) ? */
+/* IRDA -  disable GPIO connected to SD pin of transceiver (TFBS4710?) ? */
 #define GPIO_NR_PALMTX_IR_DISABLE		40
 
 /* USB */
diff --git a/arch/arm/mach-pxa/include/mach/trizeps4.h b/arch/arm/mach-pxa/include/mach/trizeps4.h
index ae3ca01..f647272 100644
--- a/arch/arm/mach-pxa/include/mach/trizeps4.h
+++ b/arch/arm/mach-pxa/include/mach/trizeps4.h
@@ -100,7 +100,7 @@ static inline unsigned short CFSR_readw(void)
 }
 static inline void BCR_writew(unsigned short value)
 {
-	/* [Board Control Regsiter] is write only */
+	/* [Board Control Register] is write only */
 	*((unsigned short *)BCR_P2V(0x0E000000)) = value;
 }
 static inline void DCR_writew(unsigned short value)
diff --git a/arch/arm/mach-pxa/palmt5.h b/arch/arm/mach-pxa/palmt5.h
index f850cc9..a27cda9 100644
--- a/arch/arm/mach-pxa/palmt5.h
+++ b/arch/arm/mach-pxa/palmt5.h
@@ -34,7 +34,7 @@
 /* TOUCHSCREEN */
 #define GPIO_NR_PALMT5_WM9712_IRQ		27
 
-/* IRDA - disable GPIO connected to SD pin of tranceiver (TFBS4710?) ? */
+/* IRDA - disable GPIO connected to SD pin of transceiver (TFBS4710?) ? */
 #define GPIO_NR_PALMT5_IR_DISABLE		40
 
 /* USB */
diff --git a/arch/arm/mach-pxa/palmte2.h b/arch/arm/mach-pxa/palmte2.h
index f89e989..17a9bac 100644
--- a/arch/arm/mach-pxa/palmte2.h
+++ b/arch/arm/mach-pxa/palmte2.h
@@ -25,7 +25,7 @@
 #define GPIO_NR_PALMTE2_SD_POWER		55
 #define GPIO_NR_PALMTE2_SD_READONLY		51
 
-/* IRDA -  disable GPIO connected to SD pin of tranceiver (TFBS4710?) ? */
+/* IRDA -  disable GPIO connected to SD pin of transceiver (TFBS4710?) ? */
 #define GPIO_NR_PALMTE2_IR_DISABLE		48
 
 /* USB */
diff --git a/arch/arm/mach-pxa/palmz72.h b/arch/arm/mach-pxa/palmz72.h
index 0d4700a..1f992c3 100644
--- a/arch/arm/mach-pxa/palmz72.h
+++ b/arch/arm/mach-pxa/palmz72.h
@@ -26,7 +26,7 @@
 /* Touchscreen */
 #define GPIO_NR_PALMZ72_WM9712_IRQ		27
 
-/* IRDA -  disable GPIO connected to SD pin of tranceiver (TFBS4710?) ? */
+/* IRDA -  disable GPIO connected to SD pin of transceiver (TFBS4710?) ? */
 #define GPIO_NR_PALMZ72_IR_DISABLE		49
 
 /* USB */
diff --git a/arch/arm/mach-s3c24xx/bast.h b/arch/arm/mach-s3c24xx/bast.h
index 5c7534b..a22ea49 100644
--- a/arch/arm/mach-s3c24xx/bast.h
+++ b/arch/arm/mach-s3c24xx/bast.h
@@ -149,7 +149,7 @@
  * 0x02500000 to 0x02600000 1MB  Davicom DM9000 ethernet controller
  * 0x02600000 to 0x02700000 1MB  PC SuperIO controller
  *
- * the phyiscal layout of the zones are:
+ * the physical layout of the zones are:
  *  nGCS2 - 8bit, slow
  *  nGCS3 - 16bit, slow
  *  nGCS4 - 16bit, net
diff --git a/arch/arm/mach-s3c24xx/vr1000.h b/arch/arm/mach-s3c24xx/vr1000.h
index 7fcd2c2..e3d92e8 100644
--- a/arch/arm/mach-s3c24xx/vr1000.h
+++ b/arch/arm/mach-s3c24xx/vr1000.h
@@ -78,7 +78,7 @@
  * 0x02500000 to 0x02600000 1MB  Davicom DM9000 ethernet controllers
  * 0x02600000 to 0x02700000 1MB
  *
- * the phyiscal layout of the zones are:
+ * the physical layout of the zones are:
  *  nGCS2 - 8bit, slow
  *  nGCS3 - 16bit, slow
  *  nGCS4 - 16bit, net
diff --git a/arch/arm/mach-s3c64xx/include/mach/irqs.h b/arch/arm/mach-s3c64xx/include/mach/irqs.h
index 3ceb00b..28990b0 100644
--- a/arch/arm/mach-s3c64xx/include/mach/irqs.h
+++ b/arch/arm/mach-s3c64xx/include/mach/irqs.h
@@ -17,7 +17,7 @@
  * standard ISA drivers....
  *
  * note, since we're using the VICs, our start must be a
- * mulitple of 32 to allow the common code to work
+ * multiple of 32 to allow the common code to work
  */
 
 #define S3C_IRQ_OFFSET	(32)
diff --git a/arch/arm/mach-s5pv210/regs-clock.h b/arch/arm/mach-s5pv210/regs-clock.h
index 4640f0f..4c035a4 100644
--- a/arch/arm/mach-s5pv210/regs-clock.h
+++ b/arch/arm/mach-s5pv210/regs-clock.h
@@ -187,7 +187,7 @@
 #define S5P_SLEEP_CFG_OSC_EN		(1 << 0)
 #define S5P_SLEEP_CFG_USBOSC_EN		(1 << 1)
 
-/* OTHERS Resgister */
+/* OTHERS Register */
 #define S5P_OTHERS_RET_IO		(1 << 31)
 #define S5P_OTHERS_RET_CF		(1 << 30)
 #define S5P_OTHERS_RET_MMC		(1 << 29)
diff --git a/arch/arm/mach-tegra/pm.c b/arch/arm/mach-tegra/pm.c
index b0f48a3..e7de9b9 100644
--- a/arch/arm/mach-tegra/pm.c
+++ b/arch/arm/mach-tegra/pm.c
@@ -228,7 +228,7 @@ static int tegra_sleep_core(unsigned long v2p)
  * tegra_lp1_iram_hook
  *
  * Hooking the address of LP1 reset vector and SDRAM self-refresh code in
- * SDRAM. These codes not be copied to IRAM in this fuction. We need to
+ * SDRAM. These codes not be copied to IRAM in this function. We need to
  * copy these code to IRAM before LP0/LP1 suspend and restore the content
  * of IRAM after resume.
  */
diff --git a/arch/arm/mm/context.c b/arch/arm/mm/context.c
index c8c8b9e..d982207 100644
--- a/arch/arm/mm/context.c
+++ b/arch/arm/mm/context.c
@@ -79,7 +79,7 @@ void a15_erratum_get_cpumask(int this_cpu, struct mm_struct *mm,
 
 #ifdef CONFIG_ARM_LPAE
 /*
- * With LPAE, the ASID and page tables are updated atomicly, so there is
+ * With LPAE, the ASID and page tables are updated atomically, so there is
  * no need for a reserved set of tables (the active ASID tracking prevents
  * any issues across a rollover).
  */
@@ -247,7 +247,7 @@ void check_and_switch_context(struct mm_struct *mm, struct task_struct *tsk)
 		__check_vmalloc_seq(mm);
 
 	/*
-	 * We cannot update the pgd and the ASID atomicly with classic
+	 * We cannot update the pgd and the ASID atomically with classic
 	 * MMU, so switch exclusively to global mappings to avoid
 	 * speculative page table walking with the wrong TTBR.
 	 */
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 7a327bd..1f90aa4 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -255,7 +255,7 @@ static struct omap_dm_timer *_omap_dm_timer_request(int req_type, void *data)
 				/*
 				 * If timer is not NULL, we have already found
 				 * one timer but it was not an exact match
-				 * because it had more capabilites that what
+				 * because it had more capabilities that what
 				 * was required. Therefore, unreserve the last
 				 * timer found and see if this one is a better
 				 * match.
diff --git a/arch/arm/plat-samsung/include/plat/gpio-cfg.h b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
index b5294ef..ae61176 100644
--- a/arch/arm/plat-samsung/include/plat/gpio-cfg.h
+++ b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
@@ -40,7 +40,7 @@ struct samsung_gpio_chip;
  * @get_config: Read the current configuration for the GPIO
  *
  * Each chip can have more than one type of GPIO bank available and some
- * have different capabilites even when they have the same control register
+ * have different capabilities even when they have the same control register
  * layouts. Provide an point to vector control routine and provide any
  * per-bank configuration information that other systems such as the
  * external interrupt code will need.
diff --git a/arch/arm/probes/kprobes/test-core.c b/arch/arm/probes/kprobes/test-core.c
index 9775de2..ddd9f8c 100644
--- a/arch/arm/probes/kprobes/test-core.c
+++ b/arch/arm/probes/kprobes/test-core.c
@@ -128,7 +128,7 @@
  *	.byte	ARG_TYPE_END
  *	.byte	TEST_ISA	@ flags, including ISA being tested
  *	.short	50f-0f		@ offset of 'test_before'
- *	.short	2f-0f		@ offset of 'test_after2' (if relevent)
+ *	.short	2f-0f		@ offset of 'test_after2' (if relevant)
  *	.short	99f-0f		@ offset of 'test_done'
  *	@ start of test case code...
  *	0:
diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S
index 9a36f4f..d49b04a 100644
--- a/arch/arm/xen/hypercall.S
+++ b/arch/arm/xen/hypercall.S
@@ -32,9 +32,9 @@
 
 /*
  * The Xen hypercall calling convention is very similar to the ARM
- * procedure calling convention: the first paramter is passed in r0, the
+ * procedure calling convention: the first parameter is passed in r0, the
  * second in r1, the third in r2 and the fourth in r3. Considering that
- * Xen hypercalls have 5 arguments at most, the fifth paramter is passed
+ * Xen hypercalls have 5 arguments at most, the fifth parameter is passed
  * in r4, differently from the procedure calling convention of using the
  * stack for that case.
  *
-- 
2.7.0.rc3.207.g0ac5344



From adam.buchbinder at gmail.com  Tue Feb 23 15:26:46 2016
From: adam.buchbinder at gmail.com (Adam Buchbinder)
Date: Tue, 23 Feb 2016 15:26:46 -0800
Subject: [PATCH] arm64: Fix misspellings in comments.
Message-ID: <1456270006-26035-1-git-send-email-adam.buchbinder@gmail.com>

Signed-off-by: Adam Buchbinder <adam.buchbinder at gmail.com>
---
 arch/arm64/boot/dts/nvidia/tegra132.dtsi | 2 +-
 arch/arm64/boot/dts/nvidia/tegra210.dtsi | 2 +-
 arch/arm64/include/asm/ftrace.h          | 2 +-
 arch/arm64/include/asm/kvm_arm.h         | 2 +-
 arch/arm64/include/asm/kvm_host.h        | 4 ++--
 arch/arm64/kernel/fpsimd.c               | 2 +-
 arch/arm64/kernel/kgdb.c                 | 4 ++--
 arch/arm64/kernel/signal32.c             | 2 +-
 arch/arm64/lib/memcmp.S                  | 2 +-
 9 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra132.dtsi b/arch/arm64/boot/dts/nvidia/tegra132.dtsi
index e8bb460..6e28e41 100644
--- a/arch/arm64/boot/dts/nvidia/tegra132.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra132.dtsi
@@ -313,7 +313,7 @@
 	/*
 	 * There are two serial driver i.e. 8250 based simple serial
 	 * driver and APB DMA based serial driver for higher baudrate
-	 * and performace. To enable the 8250 based driver, the compatible
+	 * and performance. To enable the 8250 based driver, the compatible
 	 * is "nvidia,tegra124-uart", "nvidia,tegra20-uart" and to enable
 	 * the APB DMA based serial driver, the comptible is
 	 * "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart".
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index bc23f4d..23b0630 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -345,7 +345,7 @@
 	/*
 	 * There are two serial driver i.e. 8250 based simple serial
 	 * driver and APB DMA based serial driver for higher baudrate
-	 * and performace. To enable the 8250 based driver, the compatible
+	 * and performance. To enable the 8250 based driver, the compatible
 	 * is "nvidia,tegra124-uart", "nvidia,tegra20-uart" and to enable
 	 * the APB DMA based serial driver, the comptible is
 	 * "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart".
diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
index 3c60f37..caa955f 100644
--- a/arch/arm64/include/asm/ftrace.h
+++ b/arch/arm64/include/asm/ftrace.h
@@ -48,7 +48,7 @@ static inline unsigned long ftrace_call_adjust(unsigned long addr)
  * See kernel/trace/trace_syscalls.c
  *
  * x86 code says:
- * If the user realy wants these, then they should use the
+ * If the user really wants these, then they should use the
  * raw syscall tracepoints with filtering.
  */
 #define ARCH_TRACE_IGNORE_COMPAT_SYSCALLS
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index d201d4b..0215b57 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -61,7 +61,7 @@
 
 /*
  * The bits we set in HCR:
- * RW:		64bit by default, can be overriden for 32bit VMs
+ * RW:		64bit by default, can be overridden for 32bit VMs
  * TAC:		Trap ACTLR
  * TSC:		Trap SMC
  * TVM:		Trap VM ops (until M+C set in SCTLR_EL1)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 689d4c9..56284eb 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -99,8 +99,8 @@ enum vcpu_sysreg {
 	TTBR1_EL1,	/* Translation Table Base Register 1 */
 	TCR_EL1,	/* Translation Control Register */
 	ESR_EL1,	/* Exception Syndrome Register */
-	AFSR0_EL1,	/* Auxilary Fault Status Register 0 */
-	AFSR1_EL1,	/* Auxilary Fault Status Register 1 */
+	AFSR0_EL1,	/* Auxiliary Fault Status Register 0 */
+	AFSR1_EL1,	/* Auxiliary Fault Status Register 1 */
 	FAR_EL1,	/* Fault Address Register */
 	MAIR_EL1,	/* Memory Attribute Indirection Register */
 	VBAR_EL1,	/* Vector Base Address Register */
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index acc1afd..975b274 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -45,7 +45,7 @@
  *     been used to perform kernel mode NEON in the meantime.
  *
  * For (a), we add a 'cpu' field to struct fpsimd_state, which gets updated to
- * the id of the current CPU everytime the state is loaded onto a CPU. For (b),
+ * the id of the current CPU every time the state is loaded onto a CPU. For (b),
  * we add the per-cpu variable 'fpsimd_last_state' (below), which contains the
  * address of the userland FPSIMD state of the task that was loaded onto the CPU
  * the most recently, or NULL if kernel mode NEON has been performed after that.
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index bcac81e..b67531a 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -292,8 +292,8 @@ static struct notifier_block kgdb_notifier = {
 };
 
 /*
- * kgdb_arch_init - Perform any architecture specific initalization.
- * This function will handle the initalization of any architecture
+ * kgdb_arch_init - Perform any architecture specific initialization.
+ * This function will handle the initialization of any architecture
  * specific callbacks.
  */
 int kgdb_arch_init(void)
diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index 71ef6dc..71c1cf4 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -166,7 +166,7 @@ int copy_siginfo_to_user32(compat_siginfo_t __user *to, const siginfo_t *from)
 #ifdef BUS_MCEERR_AO
 		/*
 		 * Other callers might not initialize the si_lsb field,
-		 * so check explicitely for the right codes here.
+		 * so check explicitly for the right codes here.
 		 */
 		if (from->si_signo == SIGBUS &&
 		    (from->si_code == BUS_MCEERR_AR || from->si_code == BUS_MCEERR_AO))
diff --git a/arch/arm64/lib/memcmp.S b/arch/arm64/lib/memcmp.S
index ffbdec0..dc5f17c 100644
--- a/arch/arm64/lib/memcmp.S
+++ b/arch/arm64/lib/memcmp.S
@@ -211,7 +211,7 @@ CPU_LE( lsr	tmp2, tmp2, tmp1 )
 .Lunequal_proc:
 	cbz	diff, .Lremain8
 
-/*There is differnence occured in the latest comparison.*/
+/*There is differnence occurred in the latest comparison.*/
 .Lnot_limit:
 /*
 * For little endian,reverse the low significant equal bits into MSB,then
-- 
2.7.0.rc3.207.g0ac5344



From aaro.koskinen at iki.fi  Tue Feb 23 15:40:14 2016
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Wed, 24 Feb 2016 01:40:14 +0200
Subject: [PATCH 2/3] ARM: omap1: avoid unused variable warning
In-Reply-To: <1456235876-4088840-3-git-send-email-arnd@arndb.de>
References: <1456235876-4088840-1-git-send-email-arnd@arndb.de>
 <1456235876-4088840-3-git-send-email-arnd@arndb.de>
Message-ID: <20160223234013.GV1640@darkstar.musicnaut.iki.fi>

On Tue, Feb 23, 2016 at 02:57:52PM +0100, Arnd Bergmann wrote:
> The osk_mistral_init() contains code that is only compiled when
> CONFIG_PM is set, but it uses a variable that is declared outside
> of the #ifdef:
> 
> arch/arm/mach-omap1/board-osk.c: In function 'osk_mistral_init':
> arch/arm/mach-omap1/board-osk.c:513:7: warning: unused variable 'ret' [-Wunused-variable]
> 
> This puts the variable in the same #ifdef to avoid the warning.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Acked-by: Aaro Koskinen <aaro.koskinen at iki.fi>

A.


From aaro.koskinen at iki.fi  Tue Feb 23 15:40:44 2016
From: aaro.koskinen at iki.fi (Aaro Koskinen)
Date: Wed, 24 Feb 2016 01:40:44 +0200
Subject: [PATCH 3/3] ARM: omap1/ams-delta: warn about failed regulator
 enable
In-Reply-To: <1456235876-4088840-4-git-send-email-arnd@arndb.de>
References: <1456235876-4088840-1-git-send-email-arnd@arndb.de>
 <1456235876-4088840-4-git-send-email-arnd@arndb.de>
Message-ID: <20160223234044.GW1640@darkstar.musicnaut.iki.fi>

On Tue, Feb 23, 2016 at 02:57:53PM +0100, Arnd Bergmann wrote:
> The modem pm handler in the ams-delta board uses regulator_enable()
> but does not check for a successful return code:
> 
> board-ams-delta.c:521:3: error: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Werror=unused-result]
> 
> It is not easy to propagate that return code to the callers in
> uart_configure_port/uart_suspend_port/uart_resume_port, unless
> we change all UART drivers, and it is unclear what those would
> do with the return code.
> 
> Instead, this patch uses a runtime warning to replace the
> compiletime warning. I have checked that the regulator in question
> is hardcoded to a fixed-voltage GPIO regulator, and that should
> never fail to get enabled if I understand the code right.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Acked-by: Aaro Koskinen <aaro.koskinen at iki.fi>

A.


From k.kozlowski at samsung.com  Tue Feb 23 15:47:16 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 24 Feb 2016 08:47:16 +0900
Subject: [PATCH 2/3] ARM: EXYNOS: remove unused register offset definition
In-Reply-To: <56CC2238.2040303@samsung.com>
References: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
 <1456135396-17767-3-git-send-email-pankaj.dubey@samsung.com>
 <56CBA1BC.4050003@samsung.com> <56CC2238.2040303@samsung.com>
Message-ID: <56CCEF84.6090502@samsung.com>

On 23.02.2016 18:11, pankaj.dubey wrote:
> Hi Krzysztof,
> 
> On Tuesday 23 February 2016 05:33 AM, Krzysztof Kozlowski wrote:
>> On 22.02.2016 19:03, Pankaj Dubey wrote:
>>> This patch cleans up map.h by removing unused register offset
>>> and changing EXYNOS4 to EXYNOS in header comment section.
>>>
>>> Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
>>> ---
>>>  arch/arm/mach-exynos/include/mach/map.h | 9 +--------
>>>  1 file changed, 1 insertion(+), 8 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
>>> index 351e839..c48ba4f 100644
>>> --- a/arch/arm/mach-exynos/include/mach/map.h
>>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>>> @@ -2,7 +2,7 @@
>>>   * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
>>>   *		http://www.samsung.com/
>>>   *
>>> - * EXYNOS4 - Memory map definitions
>>> + * EXYNOS - Memory map definitions
>>>   *
>>>   * 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
>>> @@ -14,12 +14,6 @@
>>>  
>>>  #include <plat/map-base.h>
>>>  
>>> -/*
>>> - * EXYNOS4 UART offset is 0x10000 but the older S5P SoCs are 0x400.
>>> - * So need to define it, and here is to avoid redefinition warning.
>>> - */
>>> -#define S3C_UART_OFFSET			(0x10000)
>>> -
>>>  #include <plat/map-s5p.h>
>>
>> This does not look good. The S3C_UART_OFFSET is used in plat/map-s5p.h.
>>
> 
> Actually it's just defined there but not getting used anywhere. In fact
> we can remove it from there also.

The point is that your patch introduce changes. Before S3C_UART_OFFSET
was defined to 0x10000, after (because of #ifndef) it will be 0x400.
Description of "unused" is not accurate. Unused stuff does not impact
anything.

> So I submitted another patch to
> cleanup such redundant register definitions from plat/map-s5p.h.

That would be good.

> Only platform using S3C_UART_OFFSET is s3c64xx and its using definition
> from map-s3c.h. I have compiled all related platform defconfigs and
> found no issues because of removal of S3C_UART_OFFSET from map-s5p.c and
> map.h.

The compilation is not a test. You compiled something like this:
-#define S3C_UART_OFFSET			(0x10000)
 #ifndef S3C_UART_OFFSET
 #define S3C_UART_OFFSET         (0x400)
 #endif

... and found no errors. Of course there are no compilation errors! But
the value has changed!

Best regards,
Krzysztof




From tchalamarla at caviumnetworks.com  Tue Feb 23 15:50:21 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Tue, 23 Feb 2016 15:50:21 -0800
Subject: [PATCH V2] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <20160223122616.GE4989@leverpostej>
References: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160223122616.GE4989@leverpostej>
Message-ID: <56CCF03D.3000809@caviumnetworks.com>

in Summary,

if i change asid-base to cavium,asid-base and still use DT for supplying 
base value, is this a solution that will be accepted, of course i will 
do range check to see we are not supplying 16bit VMID for 8 bit systems 
even though the property now indicates Cavium only.

Thanks,
Tirumalesh.

On 02/23/2016 04:26 AM, Mark Rutland wrote:
> On Thu, Feb 18, 2016 at 10:29:18AM -0800, tchalamarla at caviumnetworks.com wrote:
>> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>>
>> Due to Errata#27704 CN88xx SMMUv2,supports  only shared ASID and VMID
>> namespaces; specifically within a given node SMMU0 and SMMU1 share,
>> as does SMMU2 and SMMU3.
>>
>> This patch tries to address these issuee by supplying asid and vmid
>> base from devicetree.
>>
>> changes from V1:
>> 	- rebased on top of 16 bit VMID patch
>> 	- removed redundent options from DT
>> 	- insted of transform, DT now supplies starting ASID/VMID
>>
>> Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
>> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>> ---
>>   .../devicetree/bindings/iommu/arm,smmu.txt         |  8 +++++
>>   drivers/iommu/arm-smmu.c                           | 37 +++++++++++++++-------
>>   2 files changed, 34 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> index bb7e569..80b8484 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> @@ -57,6 +57,14 @@ conditions.
>>
>>   - smmu-enable-vmid16 : Enable 16 bit VMID, if allowed.
>>
>> +- asid-base :	Buggy SMMUv2 implementations which doesn't satisfy the
>> +		ASID namespace needs, use this field to specify starting
>> +		ASID for the SMMU.
>> +
>> +- vmid-base :	Buggy SMMUv2 implementations which doesn't satisfy the VMID
>> +		namespace needs, use this field to specify starting VMID
>> +		for the SMMU.
>
> As has been pointed out, these are not strictly properties of the
> hardware, and are insufficient to aovid the issue in general (adding an
> arbitrary base does not enforce IDs fall within a particular range).
>
> So NAK for *-base properties alone.
>
>> +	if (of_property_read_u32(dev->of_node, "#asid-base",
>> +				 &smmu->asid_base)) {
>> +		smmu->asid_base = 0;
>> +	}
>> +
>> +	if (of_property_read_u32(dev->of_node, "#vmid-base",
>> +				 &smmu->vmid_base)) {
>> +		smmu->vmid_base = 1;
>> +	}
>
> These do not match the documentation above.
>
> Mark.
>


From tchalamarla at caviumnetworks.com  Tue Feb 23 15:54:47 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Tue, 23 Feb 2016 15:54:47 -0800
Subject: [PATCH V2] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <20160223122616.GE4989@leverpostej>
References: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160223122616.GE4989@leverpostej>
Message-ID: <56CCF147.7080308@caviumnetworks.com>



On 02/23/2016 04:26 AM, Mark Rutland wrote:
> On Thu, Feb 18, 2016 at 10:29:18AM -0800, tchalamarla at caviumnetworks.com wrote:
>> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>>
>> Due to Errata#27704 CN88xx SMMUv2,supports  only shared ASID and VMID
>> namespaces; specifically within a given node SMMU0 and SMMU1 share,
>> as does SMMU2 and SMMU3.
>>
>> This patch tries to address these issuee by supplying asid and vmid
>> base from devicetree.
>>
>> changes from V1:
>> 	- rebased on top of 16 bit VMID patch
>> 	- removed redundent options from DT
>> 	- insted of transform, DT now supplies starting ASID/VMID
>>
>> Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
>> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>> ---
>>   .../devicetree/bindings/iommu/arm,smmu.txt         |  8 +++++
>>   drivers/iommu/arm-smmu.c                           | 37 +++++++++++++++-------
>>   2 files changed, 34 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> index bb7e569..80b8484 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> @@ -57,6 +57,14 @@ conditions.
>>
>>   - smmu-enable-vmid16 : Enable 16 bit VMID, if allowed.
>>
>> +- asid-base :	Buggy SMMUv2 implementations which doesn't satisfy the
>> +		ASID namespace needs, use this field to specify starting
>> +		ASID for the SMMU.
>> +
>> +- vmid-base :	Buggy SMMUv2 implementations which doesn't satisfy the VMID
>> +		namespace needs, use this field to specify starting VMID
>> +		for the SMMU.
>
> As has been pointed out, these are not strictly properties of the
> hardware, and are insufficient to aovid the issue in general (adding an
> arbitrary base does not enforce IDs fall within a particular range).
>

pardon my ignorance, are you saying what happens if DT don't know what 
values to send?
> So NAK for *-base properties alone.
>
>> +	if (of_property_read_u32(dev->of_node, "#asid-base",
>> +				 &smmu->asid_base)) {
>> +		smmu->asid_base = 0;
>> +	}
>> +
>> +	if (of_property_read_u32(dev->of_node, "#vmid-base",
>> +				 &smmu->vmid_base)) {
>> +		smmu->vmid_base = 1;
>> +	}
>
> These do not match the documentation above.
>
> Mark.
>


From tchalamarla at caviumnetworks.com  Tue Feb 23 15:56:08 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Tue, 23 Feb 2016 15:56:08 -0800
Subject: [PATCH V2] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <56CC4E48.1060103@arm.com>
References: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>
 <56CC4E48.1060103@arm.com>
Message-ID: <56CCF198.3090409@caviumnetworks.com>



On 02/23/2016 04:19 AM, Robin Murphy wrote:
> On 18/02/16 18:29, tchalamarla at caviumnetworks.com wrote:
>> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>>
>> Due to Errata#27704 CN88xx SMMUv2,supports  only shared ASID and VMID
>> namespaces; specifically within a given node SMMU0 and SMMU1 share,
>> as does SMMU2 and SMMU3.
>>
>> This patch tries to address these issuee by supplying asid and vmid
>> base from devicetree.
>>
>> changes from V1:
>>     - rebased on top of 16 bit VMID patch
>>     - removed redundent options from DT
>>     - insted of transform, DT now supplies starting ASID/VMID
>>
>> Signed-off-by: Akula Geethasowjanya
>> <Geethasowjanya.Akula at caviumnetworks.com>
>> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>> ---
>>   .../devicetree/bindings/iommu/arm,smmu.txt         |  8 +++++
>>   drivers/iommu/arm-smmu.c                           | 37
>> +++++++++++++++-------
>>   2 files changed, 34 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> index bb7e569..80b8484 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> @@ -57,6 +57,14 @@ conditions.
>>
>>   - smmu-enable-vmid16 : Enable 16 bit VMID, if allowed.
>>
>> +- asid-base :    Buggy SMMUv2 implementations which doesn't satisfy the
>> +        ASID namespace needs, use this field to specify starting
>> +        ASID for the SMMU.
>> +
>> +- vmid-base :    Buggy SMMUv2 implementations which doesn't satisfy
>> the VMID
>> +        namespace needs, use this field to specify starting VMID
>> +        for the SMMU.
>> +
>
>  From how you've described the situation, this is still just some
> arbitrary number for the sake of a driver workaround and not an actual
> property of the hardware. Either way there should be a proper compatible
> string for this implementation, e.g. something like "cavium,cn88xx-smmu".
>
> Given that, you then shouldn't actually need anything else, because you
> can simply keep track of how many Cavium SMMUs have been probed and
> automatically generate a suitable offset, e.g. (smmu->index *
> ARM_SMMU_MAX_CBS) to ensure global ASID/VMID uniqueness.

This particular solution might not be accurate in all cases. what 
happens if SMMU stage 1 is used by a guest?
>
> Robin.
>
>>   Example:
>>
>>           smmu {
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 003c442..dc46b9a 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -320,6 +320,9 @@ struct arm_smmu_device {
>>       unsigned long            ipa_size;
>>       unsigned long            pa_size;
>>
>> +    u32                asid_base;
>> +    u32                vmid_base;
>> +
>>       u32                num_global_irqs;
>>       u32                num_context_irqs;
>>       unsigned int            *irqs;
>> @@ -335,8 +338,8 @@ struct arm_smmu_cfg {
>>   };
>>   #define INVALID_IRPTNDX            0xff
>>
>> -#define ARM_SMMU_CB_ASID(cfg)        ((cfg)->cbndx)
>> -#define ARM_SMMU_CB_VMID(cfg)        ((cfg)->cbndx + 1)
>> +#define ARM_SMMU_CB_ASID(smmu, cfg)    ((u16)((smmu)->asid_base +
>> (cfg)->cbndx))
>> +#define ARM_SMMU_CB_VMID(smmu, cfg)    ((u16)((smmu)->vmid_base +
>> (cfg)->cbndx))
>>
>>   enum arm_smmu_domain_stage {
>>       ARM_SMMU_DOMAIN_S1 = 0,
>> @@ -576,11 +579,11 @@ static void arm_smmu_tlb_inv_context(void *cookie)
>>
>>       if (stage1) {
>>           base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
>> -        writel_relaxed(ARM_SMMU_CB_ASID(cfg),
>> +        writel_relaxed(ARM_SMMU_CB_ASID(smmu, cfg),
>>                      base + ARM_SMMU_CB_S1_TLBIASID);
>>       } else {
>>           base = ARM_SMMU_GR0(smmu);
>> -        writel_relaxed(ARM_SMMU_CB_VMID(cfg),
>> +        writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg),
>>                      base + ARM_SMMU_GR0_TLBIVMID);
>>       }
>>
>> @@ -602,7 +605,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned
>> long iova, size_t size,
>>
>>           if (!IS_ENABLED(CONFIG_64BIT) || smmu->version ==
>> ARM_SMMU_V1) {
>>               iova &= ~12UL;
>> -            iova |= ARM_SMMU_CB_ASID(cfg);
>> +            iova |= ARM_SMMU_CB_ASID(smmu, cfg);
>>               do {
>>                   writel_relaxed(iova, reg);
>>                   iova += granule;
>> @@ -610,7 +613,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned
>> long iova, size_t size,
>>   #ifdef CONFIG_64BIT
>>           } else {
>>               iova >>= 12;
>> -            iova |= (u64)ARM_SMMU_CB_ASID(cfg) << 48;
>> +            iova |= (u64)ARM_SMMU_CB_ASID(smmu, cfg) << 48;
>>               do {
>>                   writeq_relaxed(iova, reg);
>>                   iova += granule >> 12;
>> @@ -630,7 +633,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned
>> long iova, size_t size,
>>   #endif
>>       } else {
>>           reg = ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_TLBIVMID;
>> -        writel_relaxed(ARM_SMMU_CB_VMID(cfg), reg);
>> +        writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg), reg);
>>       }
>>   }
>>
>> @@ -744,7 +747,7 @@ static void arm_smmu_init_context_bank(struct
>> arm_smmu_domain *smmu_domain,
>>   #endif
>>           /* if 16bit VMID required set VMID in CBA2R */
>>           if (smmu->options & ARM_SMMU_OPT_ENABLE_VMID16)
>> -            reg |= ARM_SMMU_CB_VMID(cfg) << CBA2R_VMID_SHIFT;
>> +            reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBA2R_VMID_SHIFT;
>>
>>           writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBA2R(cfg->cbndx));
>>       }
>> @@ -763,7 +766,7 @@ static void arm_smmu_init_context_bank(struct
>> arm_smmu_domain *smmu_domain,
>>               (CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
>>       } else if (!(smmu->options & ARM_SMMU_OPT_ENABLE_VMID16)) {
>>           /*16 bit VMID is not enabled set 8 bit VMID here */
>> -        reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
>> +        reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBAR_VMID_SHIFT;
>>       }
>>       writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
>>
>> @@ -771,11 +774,11 @@ static void arm_smmu_init_context_bank(struct
>> arm_smmu_domain *smmu_domain,
>>       if (stage1) {
>>           reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>>
>> -        reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
>> +        reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
>>           smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR0);
>>
>>           reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
>> -        reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
>> +        reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
>>           smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR1);
>>       } else {
>>           reg64 = pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
>> @@ -1812,6 +1815,18 @@ static int arm_smmu_device_dt_probe(struct
>> platform_device *pdev)
>>
>>       parse_driver_options(smmu);
>>
>> +    if (of_property_read_u32(dev->of_node, "#asid-base",
>> +                 &smmu->asid_base)) {
>> +        smmu->asid_base = 0;
>> +    }
>> +
>> +    if (of_property_read_u32(dev->of_node, "#vmid-base",
>> +                 &smmu->vmid_base)) {
>> +        smmu->vmid_base = 1;
>> +    }
>> +    if (smmu->vmid_base == 0)
>> +        smmu->vmid_base = 1;
>> +
>>       if (smmu->version > ARM_SMMU_V1 &&
>>           smmu->num_context_banks != smmu->num_context_irqs) {
>>           dev_err(dev,
>>
>


From tchalamarla at caviumnetworks.com  Tue Feb 23 16:00:31 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Tue, 23 Feb 2016 16:00:31 -0800
Subject: [PATCH V3] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <1455653329-4934-1-git-send-email-tchalamarla@caviumnetworks.com>
References: <1455653329-4934-1-git-send-email-tchalamarla@caviumnetworks.com>
Message-ID: <56CCF29F.8030105@caviumnetworks.com>

Hi Tejun,

Any more comments on this?

Thanks,
Tirumalesh.


On 02/16/2016 12:08 PM, tchalamarla at caviumnetworks.com wrote:
> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>
> Due to Errata in ThunderX, HOST_IRQ_STAT should be
> cleared before leaving the interrupt handler.
> The patch attempts to satisfy the need.
>
> Changes from V2:
> 	- removed newfile
> 	- code is now under CONFIG_ARM64
>
> Changes from V1:
> 	- Rebased on top of libata/for-4.6
>          - Moved ThunderX intr handler to new file
>
> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> ---
>   drivers/ata/ahci.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 44 insertions(+)
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 546a369..c8496fc 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1325,6 +1325,44 @@ static inline void ahci_gtf_filter_workaround(struct ata_host *host)
>   {}
>   #endif
>
> +#ifdef CONFIG_ARM64
> +/* Due to ERRATA#22536, ThunderX need to handle
> + * HOST_IRQ_STAT differently.
> + * Work around is to make sure all pending IRQs
> + * are served before leaving handler
> + */
> +static irqreturn_t ahci_thunderx_irq_handler(int irq, void *dev_instance)
> +{
> +	struct ata_host *host = dev_instance;
> +	struct ahci_host_priv *hpriv;
> +	unsigned int rc = 0;
> +	void __iomem *mmio;
> +	u32 irq_stat, irq_masked;
> +	unsigned int handled = 1;
> +
> +	VPRINTK("ENTER\n");
> +	hpriv = host->private_data;
> +	mmio = hpriv->mmio;
> +	irq_stat = readl(mmio + HOST_IRQ_STAT);
> +	if (!irq_stat)
> +		return IRQ_NONE;
> +
> +	do {
> +		irq_masked = irq_stat & hpriv->port_map;
> +		spin_lock(&host->lock);
> +		rc = ahci_handle_port_intr(host, irq_masked);
> +		if (!rc)
> +			handled = 0;
> +		writel(irq_stat, mmio + HOST_IRQ_STAT);
> +		irq_stat = readl(mmio + HOST_IRQ_STAT);
> +		spin_unlock(&host->lock);
> +	} while (irq_stat);
> +	VPRINTK("EXIT\n");
> +
> +	return IRQ_RETVAL(handled);
> +}
> +#endif
> +
>   /*
>    * ahci_init_msix() - optionally enable per-port MSI-X otherwise defer
>    * to single msi.
> @@ -1560,6 +1598,12 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>   	if (ahci_broken_devslp(pdev))
>   		hpriv->flags |= AHCI_HFLAG_NO_DEVSLP;
>
> +#ifdef CONFIG_ARM64
> +	/* this should be done before save config*/
> +	if (pdev->vendor == 0x177d && pdev->device == 0xa01c)
> +		hpriv->irq_handler = ahci_thunderx_irq_handler;
> +#endif
> +
>   	/* save initial config */
>   	ahci_pci_save_initial_config(pdev, hpriv);
>
>


From khilman at baylibre.com  Tue Feb 23 16:03:32 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Tue, 23 Feb 2016 16:03:32 -0800
Subject: [PATCH V5 11/14] soc: tegra: pmc: Add generic PM domain support
In-Reply-To: <56C5F1DA.2060705@nvidia.com> (Jon Hunter's message of "Thu, 18
 Feb 2016 16:31:22 +0000")
References: <1453998832-27383-1-git-send-email-jonathanh@nvidia.com>
 <1453998832-27383-12-git-send-email-jonathanh@nvidia.com>
 <CAPDyKFpnUJA2pLSUOw8rkjyXLY6b__TM=38jsvYAZVhe+DS=zg@mail.gmail.com>
 <7hh9hdzflv.fsf@baylibre.com> <56C1B62B.5060708@nvidia.com>
 <CAPDyKFoPrFoMOFxC37zXX4L3VdLKknaw_LUTw7ycr9mfa_=7_A@mail.gmail.com>
 <56C5F1DA.2060705@nvidia.com>
Message-ID: <7h60xft1nv.fsf@baylibre.com>

Jon Hunter <jonathanh at nvidia.com> writes:

> On 18/02/16 16:00, Ulf Hansson wrote:
>> [...]
>> 
>>>>
>>>> What about the pm_clk_* API which was built for tracking clocks
>>>> associated with devices for runtime PM.
>>>>
>>>> IOW, you could pm_clk_add(pg->pmc->dev, pg->clks[i]) and then your
>>>> _enable_clocks() would become pm_clk_suspend() an dyour
>>>> _disable_clocks() would become pm_clk_resume().
>>>
>>> Very interesting, I was not aware of this.
>>>
>>>> I might not be following the mapping between PMC and PGs though so not
>>>> sure pg->pmc->dev is the right struct device, but you get the idea.
>>>
>>> Yes, so this will not work here as-is, because the pmc->dev is common to
>>> all pm-domains (it is the device that creates all the pm-domains). So to
>>> make this work, I would need to create a device for each pm-domain and
>>> add the clocks to that.
>>>
>>> I see that this works very well for normal drivers, but it does not feel
>>> so natural for pm-domains where we don't have a device struct today. By
>>> the way, the rockchip pm-domains implementation is very much in the same
>>> boat as tegra, where there are multiple clocks per pm-domain and it is
>>> handled by a simple list. So I am not sure if you think that we should
>>> be turning all pm-domains registered by pm_genpd_init() into a device
>>> and then we can make use of these pm_clk_XXXX() APIs?
>>>
>>> I have implemented the generic clk APIs that Ulf and I discussed for
>>> handling multiple clocks, but if we think that this is a better way,
>>> then I will hold off for now.
>> 
>> I think Kevin has a point that we already have PM clocks to build upon.
>> Could we perhaps try to extend that API instead to suite this needs as well?
>
> We certainly could and I am not against it, however, it means that we
> need to create a device structure for each pm-domain. If you and Kevin
> are ok with me adding this to pm_genpd_init(), then I can give it a try.

At this point, I'm thinking that the added complexity of a per-pm-domain
struct device isn't justified.  Managing simple lists of clocks in the
SoC specific PM domains is quite easy to review and maintain, IMO.

So I recommend just keeping it that way for now.  If it starts to get
unwieldy for tegra, rockchip and any others, we can revisit a common way
of doing it then.

Kevin



From ddaney.cavm at gmail.com  Tue Feb 23 16:08:54 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Tue, 23 Feb 2016 16:08:54 -0800
Subject: [PATCH v3] arm64: Add workaround for Cavium erratum 27456
Message-ID: <1456272534-21692-1-git-send-email-ddaney.cavm@gmail.com>

From: Andrew Pinski <apinski at cavium.com>

On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
instructions may cause the icache to become corrupted if it contains
data for a non-current ASID.

This patch implements the workaround (which flushes the local icache
when switching the mm) by using code patching.

Signed-off-by: Andrew Pinski <apinski at cavium.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 Documentation/arm64/silicon-errata.txt |  1 +
 arch/arm64/Kconfig                     | 11 +++++++++++
 arch/arm64/include/asm/cpufeature.h    |  3 ++-
 arch/arm64/kernel/cpu_errata.c         |  9 +++++++++
 arch/arm64/mm/proc.S                   | 12 ++++++++++++
 5 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index 58b71dd..ba4b6ac 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -56,3 +56,4 @@ stable kernels.
 |                |                 |                 |                         |
 | Cavium         | ThunderX ITS    | #22375, #24313  | CAVIUM_ERRATUM_22375    |
 | Cavium         | ThunderX GICv3  | #23154          | CAVIUM_ERRATUM_23154    |
+| Cavium         | ThunderX Core   | #27456          | CAVIUM_ERRATUM_27456    |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8cc6228..39f2203 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -432,6 +432,17 @@ config CAVIUM_ERRATUM_23154
 
 	  If unsure, say Y.
 
+config CAVIUM_ERRATUM_27456
+	bool "Cavium erratum 27456: Broadcast TLBI instructions may cause the icache corruption"
+	default y
+	help
+	  On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
+	  instructions may cause the icache to become corrupted if it
+	  contains data for a non-current ASID.  The fix is to flush
+	  the icache when changing the mm context.
+
+	  If unsure, say Y.
+
 endmenu
 
 
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 8f271b8..8136afc 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -30,8 +30,9 @@
 #define ARM64_HAS_LSE_ATOMICS			5
 #define ARM64_WORKAROUND_CAVIUM_23154		6
 #define ARM64_WORKAROUND_834220			7
+#define ARM64_WORKAROUND_CAVIUM_27456		8
 
-#define ARM64_NCAPS				8
+#define ARM64_NCAPS				9
 
 #ifndef __ASSEMBLY__
 
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index feb6b4e..a3e846a 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -100,6 +100,15 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
 		MIDR_RANGE(MIDR_THUNDERX, 0x00, 0x01),
 	},
 #endif
+#ifdef CONFIG_CAVIUM_ERRATUM_27456
+	{
+	/* Cavium ThunderX, T88 pass 1.x - 2.1 */
+		.desc = "Cavium erratum 27456",
+		.capability = ARM64_WORKAROUND_CAVIUM_27456,
+		MIDR_RANGE(MIDR_THUNDERX, 0x00,
+			   (1 << MIDR_VARIANT_SHIFT) | 1),
+	},
+#endif
 	{
 	}
 };
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index c164d2c..0f3be00 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -25,6 +25,8 @@
 #include <asm/hwcap.h>
 #include <asm/pgtable-hwdef.h>
 #include <asm/pgtable.h>
+#include <asm/cpufeature.h>
+#include <asm/alternative.h>
 
 #include "proc-macros.S"
 
@@ -137,7 +139,17 @@ ENTRY(cpu_do_switch_mm)
 	bfi	x0, x1, #48, #16		// set the ASID
 	msr	ttbr0_el1, x0			// set TTBR0
 	isb
+alternative_if_not ARM64_WORKAROUND_CAVIUM_27456
 	ret
+	nop
+	nop
+	nop
+alternative_else
+	ic	iallu
+	dsb	nsh
+	isb
+	ret
+alternative_endif
 ENDPROC(cpu_do_switch_mm)
 
 /*
-- 
1.8.3.1



From jay.xu at rock-chips.com  Tue Feb 23 16:18:16 2016
From: jay.xu at rock-chips.com (Jianqun Xu)
Date: Wed, 24 Feb 2016 08:18:16 +0800
Subject: [PATCH 1/4] soc: rockchip: add bindings for Rockchip grf
In-Reply-To: <20160223221555.GA7531@rob-hp-laptop>
References: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
 <1456210864-29037-2-git-send-email-jay.xu@rock-chips.com>
 <20160223221555.GA7531@rob-hp-laptop>
Message-ID: <56CCF6C8.6010602@rock-chips.com>

Hi Rob

? 24/02/2016 06:15, Rob Herring ??:
> On Tue, Feb 23, 2016 at 03:01:01PM +0800, jianqun.xu wrote:
>> From: Jianqun Xu <jay.xu at rock-chips.com>
>>
>> Add devicetree bindings for Rockchip grf which found on
>> Rockchip SoCs.
>>
>> Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
>> ---
>> changes in v2:
>> - add grf.txt (Heiko)
>>
>>   .../devicetree/bindings/soc/rockchip/grf.txt       | 35 ++++++++++++++++++++++
>>   1 file changed, 35 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/soc/rockchip/grf.txt
>>
>> diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
>> new file mode 100644
>> index 0000000..7fb0410
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt
>> @@ -0,0 +1,35 @@
>> +* Rockchip General Register Files (GRF)
>> +
>> +The general register file will be used to do static set by software, which
>> +is composed of many registers for system control.
>> +
>> +From RK3368 SoCs, the GRF is divided into two sections,
>> +- GRF, used for general non-secure system,
>> +- PMUGRF, used for always on sysyem
>
> s/sysyem/system/
>
> Otherwise:
>
> Acked-by: Rob Herring <robh at kernel.org>
>
ok, thanks
>> +
>> +Required Properties:
>> +
>> +- compatible: GRF should be one of the followings
>> +   - "rockchip,rk3066-grf", "syscon": for rk3066
>> +   - "rockchip,rk3188-grf", "syscon": for rk3188
>> +   - "rockchip,rk3228-grf", "syscon": for rk3228
>> +   - "rockchip,rk3288-grf", "syscon": for rk3288
>> +   - "rockchip,rk3368-grf", "syscon": for rk3368
>> +   - "rockchip,rk3399-grf", "syscon": for rk3399
>> +- compatible: PMUGRF should be one of the followings
>> +   - "rockchip,rk3368-pmugrf", "syscon": for rk3368
>> +   - "rockchip,rk3399-pmugrf", "syscon": for rk3399
>> +- reg: physical base address of the controller and length of memory mapped
>> +  region.
>> +
>> +Example: GRF and PMUGRF of RK3399 SoCs
>> +
>> +	pmugrf: syscon at ff320000 {
>> +		compatible = "rockchip,rk3399-pmugrf", "syscon";
>> +		reg = <0x0 0xff320000 0x0 0x1000>;
>> +	};
>> +
>> +	grf: syscon at ff770000 {
>> +		compatible = "rockchip,rk3399-grf", "syscon";
>> +		reg = <0x0 0xff770000 0x0 0x10000>;
>> +	};
>> --
>> 1.9.1
>>
>>
>
>
>



From dianders at chromium.org  Tue Feb 23 16:22:16 2016
From: dianders at chromium.org (Doug Anderson)
Date: Tue, 23 Feb 2016 16:22:16 -0800
Subject: [PATCH RESEND 2/2] usb: dwc2: Move host-specific core functions
 into hcd.c
In-Reply-To: <8c76999579912385f7aa371960e5321864d5d86c.1456260533.git.johnyoun@synopsys.com>
References: <cover.1456260533.git.johnyoun@synopsys.com>
 <8c76999579912385f7aa371960e5321864d5d86c.1456260533.git.johnyoun@synopsys.com>
Message-ID: <CAD=FV=VXJdEH0+h2UWmh5++N9uax4NLujXStqS2fgWB-qw2UgA@mail.gmail.com>

John,

On Tue, Feb 23, 2016 at 1:33 PM, John Youn <johnyoun at synopsys.com> wrote:

> +u32 dwc2_calc_frame_interval(struct dwc2_hsotg *hsotg)

You seem to have lost the function comments for
dwc2_calc_frame_interval().  Was that intentional?  If not, can you
add them back?


> +/**
> + * dwc2_hc_do_ping() - Starts a PING transfer
> + *
> + * @hsotg: Programming view of DWC_otg controller
> + * @chan:  Information needed to initialize the host channel
> + *
> + * This function should only be called in Slave mode. The Do Ping bit is set in
> + * the HCTSIZ register, then the channel is enabled.
> + */
> +void dwc2_hc_do_ping(struct dwc2_hsotg *hsotg, struct dwc2_host_chan *chan)

Presumably can be static?  ...and remove prototype from "core.h"?


> +/**
> + * dwc2_core_init() - Initializes the DWC_otg controller registers and
> + * prepares the core for device mode or host mode operation
> + *
> + * @hsotg:         Programming view of the DWC_otg controller
> + * @initial_setup: If true then this is the first init for this instance.
> + */
> +int dwc2_core_init(struct dwc2_hsotg *hsotg, bool initial_setup)

Presumably can be static?  ...and remove prototype from "core.h"?


> +/**
> + * dwc2_core_host_init() - Initializes the DWC_otg controller registers for
> + * Host mode
> + *
> + * @hsotg: Programming view of DWC_otg controller
> + *
> + * This function flushes the Tx and Rx FIFOs and flushes any entries in the
> + * request queues. Host channels are reset to ensure that they are ready for
> + * performing transfers.
> + */
> +void dwc2_core_host_init(struct dwc2_hsotg *hsotg)

Presumably can be static?  ...and remove prototype from "core.h"?


Other than those nits, things look good.  I didn't analyze exactly
where you placed all the functions but a quick glance shows that they
seem sanely organized.  :)

I picked these back to my chromeos-3.14 kernel (with many many dwc2
backports) and I confirmed that I can still compile the kernel, boot
it, and use USB.  I also confirmed no warnings were introduced for me.
I'm only testing HOST, not gadget mode.

Feel free to add my Reviewed-by and Tested-by once nits are fixed up.

-Doug


From dianders at chromium.org  Tue Feb 23 16:22:31 2016
From: dianders at chromium.org (Doug Anderson)
Date: Tue, 23 Feb 2016 16:22:31 -0800
Subject: [PATCH RESEND 1/2] usb: dwc2: Move register save and restore
 functions
In-Reply-To: <8cb0a09d08414388ad62f57320dc67bb2ee8d0f6.1456260533.git.johnyoun@synopsys.com>
References: <cover.1456260533.git.johnyoun@synopsys.com>
 <8cb0a09d08414388ad62f57320dc67bb2ee8d0f6.1456260533.git.johnyoun@synopsys.com>
Message-ID: <CAD=FV=Vr2q5Gz=VaS2k5u04zKqT-y48v2GmqJt_cmw3eib0UXQ@mail.gmail.com>

John,

On Tue, Feb 23, 2016 at 1:33 PM, John Youn <johnyoun at synopsys.com> wrote:
> Move the register save and restore functions into the host and gadget
> specific files.
>
> Signed-off-by: John Youn <johnyoun at synopsys.com>
> ---
>  drivers/usb/dwc2/core.c   | 183 ----------------------------------------------
>  drivers/usb/dwc2/core.h   |  13 ++++
>  drivers/usb/dwc2/gadget.c | 102 ++++++++++++++++++++++++++
>  drivers/usb/dwc2/hcd.c    |  64 ++++++++++++++++
>  4 files changed, 179 insertions(+), 183 deletions(-)

I picked these back to my chromeos-3.14 kernel (with many many dwc2
backports) and I confirmed that I can still compile the kernel, boot
it, and use USB.  I also confirmed no warnings were introduced for me.
I'm only testing HOST, not gadget mode.

I also reviewed the code and agree that it looks good.  Thanks!

Tested-by: Douglas Anderson <dianders at chromium.org>
Reviewed-by: Douglas Anderson <dianders at chromium.org>


From horms at verge.net.au  Tue Feb 23 16:25:29 2016
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Feb 2016 09:25:29 +0900
Subject: [PATCH 1/2] ARM: dts: r8a7790: use fallback etheravb
 compatibility string
In-Reply-To: <CAMuHMdUJLQFTS9YWdm6RJOOAch6xTkkh=LprVbtumYwc4hKyqQ@mail.gmail.com>
References: <1456190266-3781-1-git-send-email-horms+renesas@verge.net.au>
 <1456190266-3781-2-git-send-email-horms+renesas@verge.net.au>
 <CAMuHMdUJLQFTS9YWdm6RJOOAch6xTkkh=LprVbtumYwc4hKyqQ@mail.gmail.com>
Message-ID: <20160224002528.GB28853@verge.net.au>

On Tue, Feb 23, 2016 at 09:25:33AM +0100, Geert Uytterhoeven wrote:
> On Tue, Feb 23, 2016 at 2:17 AM, Simon Horman
> <horms+renesas at verge.net.au> wrote:
> > Use recently added fallback compatibility string in r8a7790 device tree.
> >
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>

Thanks, I have queued this up.


From horms at verge.net.au  Tue Feb 23 16:25:36 2016
From: horms at verge.net.au (Simon Horman)
Date: Wed, 24 Feb 2016 09:25:36 +0900
Subject: [PATCH 2/2] arm64: dts: r8a7795: use fallback etheravb
 compatibility string
In-Reply-To: <CAMuHMdV-nrfcWGOW5aAiR2RTe-340ER=TcWgbfe4MEVU_iyYqw@mail.gmail.com>
References: <1456190266-3781-1-git-send-email-horms+renesas@verge.net.au>
 <1456190266-3781-3-git-send-email-horms+renesas@verge.net.au>
 <CAMuHMdV-nrfcWGOW5aAiR2RTe-340ER=TcWgbfe4MEVU_iyYqw@mail.gmail.com>
Message-ID: <20160224002535.GC28853@verge.net.au>

On Tue, Feb 23, 2016 at 09:27:46AM +0100, Geert Uytterhoeven wrote:
> On Tue, Feb 23, 2016 at 2:17 AM, Simon Horman
> <horms+renesas at verge.net.au> wrote:
> > Use recently added fallback compatibility string in r8a7795 device tree.
> >
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>

Thanks, I have queued this up.


From ddaney at caviumnetworks.com  Tue Feb 23 16:38:22 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Tue, 23 Feb 2016 16:38:22 -0800
Subject: [PATCH v6 0/3] Add host controller drivers for Cavium ThunderX PCI
In-Reply-To: <1454975731-13618-1-git-send-email-ddaney.cavm@gmail.com>
References: <1454975731-13618-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <56CCFB7E.6030307@caviumnetworks.com>

Bjorn,

I haven't seen any feedback on this revision of the patch set.

Are there any remaining issues that you are aware of that are blocking 
these?

Thanks in advance,
David Daney


On 02/08/2016 03:55 PM, David Daney wrote:
> From: David Daney <david.daney at cavium.com>
>
> Some Cavium ThunderX processors require quirky access methods for the
> config space of the PCIe bridge.
>
> There are now three patches:
>
> 1) Refactor code in pci-host-generic so that it can more easily be
>     used by other drivers.  This splits the driver for CAM and ECAM
>     access methods to a separate file from the common host driver code.
>
> 2) Add the ThunderX PCIe driver to external PCIe buses, which
>     leverages the code in pci-host-generic
>
> 3) Add ThunderX PCI driver for internel SoC buses used on early
>     ThunderX chip revisions.
>
> Changes from v5: Added Acked-by Rob Herring for the device tree
> binding in 3/3.  Fixed typo and split large functions as suggested by
> Bjorn Helgaas.
>
> Changes from v4: Added patch 3/3.  Stylistic changes to 2/3 suggested
> by Bjorn Helgaas.  When expanding config write width to 32-bits, mask
> out unintened writes to W1C bits, also suggested by Bjorn Helgaas.
>
> Changes from v3: Add some Acked-by, rebased to v4.5.0-rc1
>
> Changes from v2: Improve device tree binding example as noted by Rob
> Herring.  Rename pcie-thunder-pem.* to pci-thunder-pem.* for better
> consistency.  Update MAINTAINERS to reflect the changes.
>
> Changes from v1: Split CAM and ECAM code from common driver code as
> suggested by Arnd Bergmann.  Fix spelling errors in
> pcie-thunder-pem.txt
>
> David Daney (3):
>    PCI: generic: Refactor code to enable reuse by other drivers.
>    pci, pci-thunder-pem: Add PCIe host driver for ThunderX processors.
>    pci, pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices
>
>   .../devicetree/bindings/pci/pci-thunder-ecam.txt   |  30 ++
>   .../devicetree/bindings/pci/pci-thunder-pem.txt    |  43 +++
>   MAINTAINERS                                        |   9 +
>   drivers/pci/host/Kconfig                           |  18 ++
>   drivers/pci/host/Makefile                          |   3 +
>   drivers/pci/host/pci-host-common.c                 | 194 +++++++++++
>   drivers/pci/host/pci-host-common.h                 |  47 +++
>   drivers/pci/host/pci-host-generic.c                | 181 +----------
>   drivers/pci/host/pci-thunder-ecam.c                | 358 +++++++++++++++++++++
>   drivers/pci/host/pci-thunder-pem.c                 | 347 ++++++++++++++++++++
>   10 files changed, 1053 insertions(+), 177 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-ecam.txt
>   create mode 100644 Documentation/devicetree/bindings/pci/pci-thunder-pem.txt
>   create mode 100644 drivers/pci/host/pci-host-common.c
>   create mode 100644 drivers/pci/host/pci-host-common.h
>   create mode 100644 drivers/pci/host/pci-thunder-ecam.c
>   create mode 100644 drivers/pci/host/pci-thunder-pem.c
>



From zhangqing at rock-chips.com  Tue Feb 23 16:44:11 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Wed, 24 Feb 2016 08:44:11 +0800
Subject: [RESEND PATCH] clk: rockchip: include downstream muxes into
 fractional dividers on rk3368
Message-ID: <1456274651-23202-1-git-send-email-zhangqing@rock-chips.com>

During the initial conversion to the newly introduced combined fractional
dividers+muxes the rk3368 clocks were left out, so convert them now.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 drivers/clk/rockchip/clk-rk3368.c | 97 ++++++++++++++++++++++++---------------
 1 file changed, 60 insertions(+), 37 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3368.c b/drivers/clk/rockchip/clk-rk3368.c
index c2b0421..a2bb122 100644
--- a/drivers/clk/rockchip/clk-rk3368.c
+++ b/drivers/clk/rockchip/clk-rk3368.c
@@ -243,6 +243,34 @@ static struct rockchip_cpuclk_rate_table rk3368_cpuclkl_rates[] __initdata = {
 	RK3368_CPUCLKL_RATE( 312000000, 1, 1, 1),
 };
 
+static struct rockchip_clk_branch rk3368_i2s_8ch_fracmux __initdata =
+	MUX(0, "i2s_8ch_pre", mux_i2s_8ch_pre_p, CLK_SET_RATE_PARENT,
+	    RK3368_CLKSEL_CON(27), 8, 2, MFLAGS);
+
+static struct rockchip_clk_branch rk3368_spdif_8ch_fracmux __initdata =
+	MUX(0, "spdif_8ch_pre", mux_spdif_8ch_p, CLK_SET_RATE_PARENT,
+	    RK3368_CLKSEL_CON(31), 8, 2, MFLAGS);
+
+static struct rockchip_clk_branch rk3368_i2s_2ch_fracmux __initdata =
+	MUX(0, "i2s_2ch_pre", mux_i2s_2ch_p, CLK_SET_RATE_PARENT,
+	    RK3368_CLKSEL_CON(53), 8, 2, MFLAGS);
+
+static struct rockchip_clk_branch rk3368_uart0_fracmux __initdata =
+	MUX(SCLK_UART0, "sclk_uart0", mux_uart0_p, CLK_SET_RATE_PARENT,
+	    RK3368_CLKSEL_CON(33), 8, 2, MFLAGS);
+
+static struct rockchip_clk_branch rk3368_uart1_fracmux __initdata =
+	MUX(SCLK_UART1, "sclk_uart1", mux_uart1_p, CLK_SET_RATE_PARENT,
+	    RK3368_CLKSEL_CON(35), 8, 2, MFLAGS);
+
+static struct rockchip_clk_branch rk3368_uart3_fracmux __initdata =
+	MUX(SCLK_UART3, "sclk_uart3", mux_uart3_p, CLK_SET_RATE_PARENT,
+	    RK3368_CLKSEL_CON(39), 8, 2, MFLAGS);
+
+static struct rockchip_clk_branch rk3368_uart4_fracmux __initdata =
+	MUX(SCLK_UART4, "sclk_uart4", mux_uart4_p, CLK_SET_RATE_PARENT,
+	    RK3368_CLKSEL_CON(41), 8, 2, MFLAGS);
+
 static struct rockchip_clk_branch rk3368_clk_branches[] __initdata = {
 	/*
 	 * Clock-Architecture Diagram 2
@@ -339,11 +367,10 @@ static struct rockchip_clk_branch rk3368_clk_branches[] __initdata = {
 	COMPOSITE(0, "i2s_8ch_src", mux_pll_src_cpll_gpll_p, 0,
 			RK3368_CLKSEL_CON(27), 12, 1, MFLAGS, 0, 7, DFLAGS,
 			RK3368_CLKGATE_CON(6), 1, GFLAGS),
-	COMPOSITE_FRAC(0, "i2s_8ch_frac", "i2s_8ch_src", CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(28), 0,
-			RK3368_CLKGATE_CON(6), 2, GFLAGS),
-	MUX(0, "i2s_8ch_pre", mux_i2s_8ch_pre_p, CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(27), 8, 2, MFLAGS),
+	COMPOSITE_FRACMUX(0, "i2s_8ch_frac", "i2s_8ch_src", CLK_SET_RATE_PARENT,
+			  RK3368_CLKSEL_CON(28), 0,
+			  RK3368_CLKGATE_CON(6), 2, GFLAGS,
+			  &rk3368_i2s_8ch_fracmux),
 	COMPOSITE_NODIV(SCLK_I2S_8CH_OUT, "i2s_8ch_clkout", mux_i2s_8ch_clkout_p, 0,
 			RK3368_CLKSEL_CON(27), 15, 1, MFLAGS,
 			RK3368_CLKGATE_CON(6), 0, GFLAGS),
@@ -352,21 +379,21 @@ static struct rockchip_clk_branch rk3368_clk_branches[] __initdata = {
 	COMPOSITE(0, "spdif_8ch_src", mux_pll_src_cpll_gpll_p, 0,
 			RK3368_CLKSEL_CON(31), 12, 1, MFLAGS, 0, 7, DFLAGS,
 			RK3368_CLKGATE_CON(6), 4, GFLAGS),
-	COMPOSITE_FRAC(0, "spdif_8ch_frac", "spdif_8ch_src", CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(32), 0,
-			RK3368_CLKGATE_CON(6), 5, GFLAGS),
-	COMPOSITE_NODIV(SCLK_SPDIF_8CH, "sclk_spdif_8ch", mux_spdif_8ch_p, CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(31), 8, 2, MFLAGS,
-			RK3368_CLKGATE_CON(6), 6, GFLAGS),
+	COMPOSITE_FRACMUX(0, "spdif_8ch_frac", "spdif_8ch_src", CLK_SET_RATE_PARENT,
+			  RK3368_CLKSEL_CON(32), 0,
+			  RK3368_CLKGATE_CON(6), 5, GFLAGS,
+			  &rk3368_spdif_8ch_fracmux),
+	GATE(SCLK_SPDIF_8CH, "sclk_spdif_8ch", "spdif_8ch_pre", CLK_SET_RATE_PARENT,
+	     RK3368_CLKGATE_CON(6), 6, GFLAGS),
 	COMPOSITE(0, "i2s_2ch_src", mux_pll_src_cpll_gpll_p, 0,
 			RK3368_CLKSEL_CON(53), 12, 1, MFLAGS, 0, 7, DFLAGS,
 			RK3368_CLKGATE_CON(5), 13, GFLAGS),
-	COMPOSITE_FRAC(0, "i2s_2ch_frac", "i2s_2ch_src", CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(54), 0,
-			RK3368_CLKGATE_CON(5), 14, GFLAGS),
-	COMPOSITE_NODIV(SCLK_I2S_2CH, "sclk_i2s_2ch", mux_i2s_2ch_p, CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(53), 8, 2, MFLAGS,
-			RK3368_CLKGATE_CON(5), 15, GFLAGS),
+	COMPOSITE_FRACMUX(0, "i2s_2ch_frac", "i2s_2ch_src", CLK_SET_RATE_PARENT,
+			  RK3368_CLKSEL_CON(54), 0,
+			  RK3368_CLKGATE_CON(5), 14, GFLAGS,
+			  &rk3368_i2s_2ch_fracmux),
+	GATE(SCLK_I2S_2CH, "sclk_i2s_2ch", "i2s_2ch_pre", CLK_SET_RATE_PARENT,
+	     RK3368_CLKGATE_CON(5), 15, GFLAGS),
 
 	COMPOSITE(0, "sclk_tsp", mux_pll_src_cpll_gpll_npll_p, 0,
 			RK3368_CLKSEL_CON(46), 6, 2, MFLAGS, 0, 5, DFLAGS,
@@ -562,38 +589,34 @@ static struct rockchip_clk_branch rk3368_clk_branches[] __initdata = {
 	COMPOSITE(0, "uart0_src", mux_pll_src_cpll_gpll_usb_usb_p, 0,
 			RK3368_CLKSEL_CON(33), 12, 2, MFLAGS, 0, 7, DFLAGS,
 			RK3368_CLKGATE_CON(2), 0, GFLAGS),
-	COMPOSITE_FRAC(0, "uart0_frac", "uart0_src", CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(34), 0,
-			RK3368_CLKGATE_CON(2), 1, GFLAGS),
-	MUX(SCLK_UART0, "sclk_uart0", mux_uart0_p, CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(33), 8, 2, MFLAGS),
+	COMPOSITE_FRACMUX(0, "uart0_frac", "uart0_src", CLK_SET_RATE_PARENT,
+			  RK3368_CLKSEL_CON(34), 0,
+			  RK3368_CLKGATE_CON(2), 1, GFLAGS,
+			  &rk3368_uart0_fracmux),
 
 	COMPOSITE_NOMUX(0, "uart1_src", "uart_src", 0,
 			RK3368_CLKSEL_CON(35), 0, 7, DFLAGS,
 			RK3368_CLKGATE_CON(2), 2, GFLAGS),
-	COMPOSITE_FRAC(0, "uart1_frac", "uart1_src", CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(36), 0,
-			RK3368_CLKGATE_CON(2), 3, GFLAGS),
-	MUX(SCLK_UART1, "sclk_uart1", mux_uart1_p, CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(35), 8, 2, MFLAGS),
+	COMPOSITE_FRACMUX(0, "uart1_frac", "uart1_src", CLK_SET_RATE_PARENT,
+			  RK3368_CLKSEL_CON(36), 0,
+			  RK3368_CLKGATE_CON(2), 3, GFLAGS,
+			  &rk3368_uart1_fracmux),
 
 	COMPOSITE_NOMUX(0, "uart3_src", "uart_src", 0,
 			RK3368_CLKSEL_CON(39), 0, 7, DFLAGS,
 			RK3368_CLKGATE_CON(2), 6, GFLAGS),
-	COMPOSITE_FRAC(0, "uart3_frac", "uart3_src", CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(40), 0,
-			RK3368_CLKGATE_CON(2), 7, GFLAGS),
-	MUX(SCLK_UART3, "sclk_uart3", mux_uart3_p, CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(39), 8, 2, MFLAGS),
+	COMPOSITE_FRACMUX(0, "uart3_frac", "uart3_src", CLK_SET_RATE_PARENT,
+			  RK3368_CLKSEL_CON(40), 0,
+			  RK3368_CLKGATE_CON(2), 7, GFLAGS,
+			  &rk3368_uart3_fracmux),
 
 	COMPOSITE_NOMUX(0, "uart4_src", "uart_src", 0,
 			RK3368_CLKSEL_CON(41), 0, 7, DFLAGS,
 			RK3368_CLKGATE_CON(2), 8, GFLAGS),
-	COMPOSITE_FRAC(0, "uart4_frac", "uart4_src", CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(42), 0,
-			RK3368_CLKGATE_CON(2), 9, GFLAGS),
-	MUX(SCLK_UART4, "sclk_uart4", mux_uart4_p, CLK_SET_RATE_PARENT,
-			RK3368_CLKSEL_CON(41), 8, 2, MFLAGS),
+	COMPOSITE_FRACMUX(0, "uart4_frac", "uart4_src", CLK_SET_RATE_PARENT,
+			  RK3368_CLKSEL_CON(42), 0,
+			  RK3368_CLKGATE_CON(2), 9, GFLAGS,
+			  &rk3368_uart4_fracmux),
 
 	COMPOSITE(0, "mac_pll_src", mux_pll_src_npll_cpll_gpll_p, 0,
 			RK3368_CLKSEL_CON(43), 6, 2, MFLAGS, 0, 5, DFLAGS,
-- 
1.9.1




From k.kozlowski at samsung.com  Tue Feb 23 16:53:32 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 24 Feb 2016 09:53:32 +0900
Subject: [PATCH] ARM: plat-samsung: remove unused register definitions
In-Reply-To: <1456218373-23658-1-git-send-email-pankaj.dubey@samsung.com>
References: <1456218373-23658-1-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <56CCFF0C.3000004@samsung.com>

On 23.02.2016 18:06, Pankaj Dubey wrote:
> This patch removes S5P_VA_TWD and S3C_UART_OFFSET as it is no more used
> by any platform which including this header file.
> 
> Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
> ---
>  arch/arm/plat-samsung/include/plat/map-s5p.h | 5 -----
>  1 file changed, 5 deletions(-)

Just squash it with previous patch and remove S3C_UART_OFFSET
atomically. Everywhere or nowhere. Not a little bit here, a little bit
there.

Best regards,
Krzysztof


From k.kozlowski at samsung.com  Tue Feb 23 17:02:59 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 24 Feb 2016 10:02:59 +0900
Subject: [PATCH 3/3] ARM: EXYNOS: cleanup header files inclusion
In-Reply-To: <56CC23AD.10103@samsung.com>
References: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
 <1456135396-17767-4-git-send-email-pankaj.dubey@samsung.com>
 <56CBA32D.4020905@samsung.com> <56CC23AD.10103@samsung.com>
Message-ID: <56CD0143.2010909@samsung.com>

On 23.02.2016 18:17, pankaj.dubey wrote:
> Hi Krzysztof,
> 
> On Tuesday 23 February 2016 05:39 AM, Krzysztof Kozlowski wrote:
>> On 22.02.2016 19:03, Pankaj Dubey wrote:
>>> This includes trivial cleanup in exynos files such as
>>>     - remove unused header files inclusion from exynos.c, s5p-dev-mfc.c,
>>>       firmware.c, pm.c.
>>>     - move inclusion of of.h from common.h to pm.c where it is really
>>>       required
>>>
>>> Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
>>> ---
>>>  arch/arm/mach-exynos/common.h      | 1 -
>>>  arch/arm/mach-exynos/exynos.c      | 5 -----
>>>  arch/arm/mach-exynos/firmware.c    | 2 --
>>>  arch/arm/mach-exynos/platsmp.c     | 1 -
>>>  arch/arm/mach-exynos/pm.c          | 4 +---
>>>  arch/arm/mach-exynos/s5p-dev-mfc.c | 1 -
>>>  6 files changed, 1 insertion(+), 13 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
>>> index e349a03..5365bf1 100644
>>> --- a/arch/arm/mach-exynos/common.h
>>> +++ b/arch/arm/mach-exynos/common.h
>>> @@ -12,7 +12,6 @@
>>>  #ifndef __ARCH_ARM_MACH_EXYNOS_COMMON_H
>>>  #define __ARCH_ARM_MACH_EXYNOS_COMMON_H
>>>  
>>> -#include <linux/of.h>
>>>  #include <linux/platform_data/cpuidle-exynos.h>
>>>  
>>>  #define EXYNOS3250_SOC_ID	0xE3472000
>>> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
>>> index 99947ad..54262a1 100644
>>> --- a/arch/arm/mach-exynos/exynos.c
>>> +++ b/arch/arm/mach-exynos/exynos.c
>>> @@ -11,14 +11,10 @@
>>>  
>>>  #include <linux/init.h>
>>>  #include <linux/io.h>
>>> -#include <linux/kernel.h>
>>> -#include <linux/serial_s3c.h>
>>>  #include <linux/of.h>
>>>  #include <linux/of_address.h>
>>>  #include <linux/of_fdt.h>
>>>  #include <linux/of_platform.h>
>>> -#include <linux/platform_device.h>
>>
>> platform_device is actually used in that file. It looks unused because
>> it is pulled by of_platform, but it makes sense to include it here.
>>
> Thanks for review.
> 
> Well I tried to grep for of_platform.h and platform_device.h in
> arch/arm/ and out of 88 files including of_platform.h only 16 files are
> including platform_device.h also. So majority do not include both of
> them even do they need. So majority of files both are not included. So
> If we got with majority it's not required. What's your opinion?

Actually most of files including of_platform.h and not including
platform_device.h just do not require the second one (I checked like 20
of them and only one was referring to platform device function... of
course maybe my random selection of 20 files was not random enough :) ).
They do not directly reference platform device stuff.

In that file the platform_device is used so the header may stay.

Best regards,
Krzysztof


From helgaas at kernel.org  Tue Feb 23 17:14:18 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Tue, 23 Feb 2016 19:14:18 -0600
Subject: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
 HiSilicon SoCs Host Controllers
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1ECC5F00@lhreml503-mbs>
References: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
 <1455039260-6040-4-git-send-email-gabriele.paoloni@huawei.com>
 <20160209182429.GD4348@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1591@lhreml503-mbs>
 <20160210111234.GC2632@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1D30@lhreml503-mbs>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECC5F00@lhreml503-mbs>
Message-ID: <20160224011418.GB13026@localhost>

On Tue, Feb 23, 2016 at 02:47:22AM +0000, Gabriele Paoloni wrote:
> > -----Original Message-----
> > From: Gabriele Paoloni
> > Sent: 10 February 2016 22:45
> > To: Mark Rutland
> > Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C); Linuxarm;
> > qiujiang; bhelgaas at google.com; arnd at arndb.de; Lorenzo.Pieralisi at arm.com;
> > tn at semihalf.com; linux-pci at vger.kernel.org; linux-
> > kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> > jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth); linux-arm-
> > kernel at lists.infradead.org
> > Subject: RE: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
> > HiSilicon SoCs Host Controllers
> > 
> > > -----Original Message-----
> > > From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> > > owner at vger.kernel.org] On Behalf Of Mark Rutland
> > > Sent: 10 February 2016 11:13
> > > To: Gabriele Paoloni
> > > Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C); Linuxarm;
> > > qiujiang; bhelgaas at google.com; arnd at arndb.de;
> > > Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-pci at vger.kernel.org;
> > > linux-kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> > > jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth); linux-arm-
> > > kernel at lists.infradead.org
> > > Subject: Re: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
> > > HiSilicon SoCs Host Controllers
> > >
> > > On Wed, Feb 10, 2016 at 09:52:36AM +0000, Gabriele Paoloni wrote:
> > > > Hi Mark
> > > >
> > > > > On Tue, Feb 09, 2016 at 05:34:20PM +0000, Gabriele Paoloni wrote:
> > > > > > From: gabriele paoloni <gabriele.paoloni at huawei.com>
> > > > > > +/*
> > > > > > + * Retrieve rc_dbi base and size from _DSD
> > > > > > + * Name (_DSD, Package () {
> > > > > > + *	ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > > > > > + *	Package () {
> > > > > > + *	Package () {"rc-dbi", Package () { 0x0, 0xb0080000, 0x0,
> > > 0x10000
> > > > > }},
> > > > > > + *	}
> > > > > > + *	})
> > > > > > + */
> > > > >
> > > > > As above, this does not look right. ACPI has standard mechanisms
> > > for
> > > > > describing addresses. Making something up like this is not a good
> > > idea.
> > > >
> > > > I am quite new to ACPI, may I ask you to explain a bit?
> > >
> > > ACPI has standard mechanisms for describing certain resources, and
> > > these
> > > should not be described in _DSD. Memory or IO address regions are
> > such
> > > resources (in _CRS, IIRC), and should not be described in _DSD.
> > 
> > Hi Mark,
> > 
> > In my case I think in need to look into the MCFG object as the problem
> > I have is RC using a different range than the rest of the hierarchy.
> > 
> > I'll investigate this and try to come with a solution in v4
> 
> I have looked into this and in our case we cannot use the
> standard MCFG object to pass the RC config space addresses.
> 
> The reason is that in our HW we have the config base addresses of the 
> root complex ports that are less than 0x100000 byte distant one from
> the other as we only map the first 0x10000 bytes.

The ECAM spec requires 4096 bytes per function, 8 functions per
device, 32 devices per bus, which means you need 0x100000 bytes of
address space per bus.  If your device doesn't supply that, it doesn't
really implement ECAM, and you probably can't use the standard ways of
describing ECAM (MCFG, _CBA).

> Now the MCFG acpi framework always fix the MCFG resource size to 0x100000
> for each bus; therefore if we pass our RC addresses through MCFG we end
> up with a resource conflict.
> 
> To give you a practical example we are in a situation where we have:
> 
> port0: [0x00000000b0080000 - 0x00000000b0080000 + 0x10000]
> port1: [0x00000000b0090000 - 0x00000000b0090000 + 0x10000]
> port2: [0x00000000b00A0000 - 0x00000000b00A0000 + 0x10000]
> port3: [0x00000000b00B0000 - 0x00000000b00B0000 + 0x10000]
>   
> So if we pass the base addresses through MCFG the resources
> will overlap as MCFG will consider 0x100000 size for each base
> address of the root complex (only the RC bus uses that address)
> 
> So far I do not see many option other than using _DSD to pass
> these RC config base addresses.

I don't want to take over Mark's discussion, but I really do not think
_DSD is the correct way to fix this.  _CRS is like a generalized PCI
BAR.  A PCI device is only allowed to respond to address space
reported via a BAR.  An ACPI device is only allowed to respond to
address space reported via _CRS.  Those are important rules because
they mean we can manage address space with generic code instead of
device-specific code.

Bjorn


From horms+renesas at verge.net.au  Tue Feb 23 17:20:50 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Feb 2016 10:20:50 +0900
Subject: [GIT PULL] Second Round of Renesas ARM Based SoC Cleanup for v4.6
Message-ID: <cover.1456275967.git.horms+renesas@verge.net.au>

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these second round of Renesas ARM based SoC cleanups for v4.6.

This pull request is based on "Renesas ARM Based SoC Fixes for v4.5",
tagged as renesas-soc-fixes-for-v4.5, which I have already sent a
pull-request for.

The reason for that base is that the SCU cleanup depends on a change
in the fixes pull request.


The following changes since commit 901c5ffaaed117a38be9d0c29247c4888d6c8636:

  ARM: shmobile: Remove shmobile_boot_arg (2016-02-17 18:27:21 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-cleanup2-for-v4.6

for you to fetch changes up to cf77db5165b606fca7d1d59735528ee43202392e:

  ARM: shmobile: Kconfig: Get rid of old comment (2016-02-17 21:24:29 +0900)

----------------------------------------------------------------
Second Round of Renesas ARM Based SoC Cleanup for v4.6

* Remove stale comment from Kconfig
* Consolidate SCU mapping code

----------------------------------------------------------------
Geert Uytterhoeven (1):
      ARM: shmobile: Consolidate SCU mapping code

Magnus Damm (1):
      ARM: shmobile: Kconfig: Get rid of old comment

 arch/arm/mach-shmobile/Kconfig       |  2 --
 arch/arm/mach-shmobile/common.h      |  5 ++---
 arch/arm/mach-shmobile/platsmp-scu.c | 10 +++++++---
 arch/arm/mach-shmobile/smp-emev2.c   |  3 +--
 arch/arm/mach-shmobile/smp-r8a7779.c |  3 +--
 arch/arm/mach-shmobile/smp-sh73a0.c  |  3 +--
 6 files changed, 12 insertions(+), 14 deletions(-)


From horms+renesas at verge.net.au  Tue Feb 23 17:21:16 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Feb 2016 10:21:16 +0900
Subject: [PATCH 1/2] ARM: shmobile: Consolidate SCU mapping code
In-Reply-To: <cover.1456275967.git.horms+renesas@verge.net.au>
References: <cover.1456275967.git.horms+renesas@verge.net.au>
Message-ID: <8701d8083d1e4b9210b9cf4f420bcf7b4b36bd6d.1456275967.git.horms+renesas@verge.net.au>

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

Currently the SCU registers are mapped in SoC-specific code, using
different methods, all involving the static mapping set up from
machine_desc.map_io():
  - On emev2, a static (non-identity) mapping is used, with ioremap().
    As the static mapping uses the MT_DEVICE type, ioremap() reuses it,
    and the returned virtual address is suitable for passing to
    shmobile_smp_hook(),
  - On sh73a0 and r8a7779, a static identity mapping is used, with the
    legacy IOMEM() macro.
    As the static mapping uses the MT_DEVICE_NONSHARED type, replacing
    IOMEM() by ioremap() would create a new mapping, whose virtual
    address cannot be passed to shmobile_smp_hook().

Move the mapping of the SCU registers from SoC-specific code to common
code, always using ioremap(). To work in the absence of a static
mapping, this requires passing the physical SCU base address to
shmobile_smp_hook().

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/common.h      |  5 ++---
 arch/arm/mach-shmobile/platsmp-scu.c | 10 +++++++---
 arch/arm/mach-shmobile/smp-emev2.c   |  3 +--
 arch/arm/mach-shmobile/smp-r8a7779.c |  3 +--
 arch/arm/mach-shmobile/smp-sh73a0.c  |  3 +--
 5 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-shmobile/common.h b/arch/arm/mach-shmobile/common.h
index b3a4ed5289ec..5464b7a75e30 100644
--- a/arch/arm/mach-shmobile/common.h
+++ b/arch/arm/mach-shmobile/common.h
@@ -11,7 +11,8 @@ extern void shmobile_smp_hook(unsigned int cpu, unsigned long fn,
 			      unsigned long arg);
 extern bool shmobile_smp_cpu_can_disable(unsigned int cpu);
 extern void shmobile_boot_scu(void);
-extern void shmobile_smp_scu_prepare_cpus(unsigned int max_cpus);
+extern void shmobile_smp_scu_prepare_cpus(phys_addr_t scu_base_phys,
+					  unsigned int max_cpus);
 extern void shmobile_smp_scu_cpu_die(unsigned int cpu);
 extern int shmobile_smp_scu_cpu_kill(unsigned int cpu);
 extern struct platform_suspend_ops shmobile_suspend_ops;
@@ -30,8 +31,6 @@ int shmobile_cpufreq_init(void);
 static inline int shmobile_cpufreq_init(void) { return 0; }
 #endif
 
-extern void __iomem *shmobile_scu_base;
-
 static inline void __init shmobile_init_late(void)
 {
 	shmobile_suspend_init();
diff --git a/arch/arm/mach-shmobile/platsmp-scu.c b/arch/arm/mach-shmobile/platsmp-scu.c
index 081a097c9219..8d478f1da265 100644
--- a/arch/arm/mach-shmobile/platsmp-scu.c
+++ b/arch/arm/mach-shmobile/platsmp-scu.c
@@ -18,7 +18,8 @@
 #include "common.h"
 
 
-void __iomem *shmobile_scu_base;
+static phys_addr_t shmobile_scu_base_phys;
+static void __iomem *shmobile_scu_base;
 
 static int shmobile_smp_scu_notifier_call(struct notifier_block *nfb,
 					  unsigned long action, void *hcpu)
@@ -29,7 +30,7 @@ static int shmobile_smp_scu_notifier_call(struct notifier_block *nfb,
 	case CPU_UP_PREPARE:
 		/* For this particular CPU register SCU SMP boot vector */
 		shmobile_smp_hook(cpu, virt_to_phys(shmobile_boot_scu),
-				  (unsigned long)shmobile_scu_base);
+				  shmobile_scu_base_phys);
 		break;
 	};
 
@@ -40,12 +41,15 @@ static struct notifier_block shmobile_smp_scu_notifier = {
 	.notifier_call = shmobile_smp_scu_notifier_call,
 };
 
-void __init shmobile_smp_scu_prepare_cpus(unsigned int max_cpus)
+void __init shmobile_smp_scu_prepare_cpus(phys_addr_t scu_base_phys,
+					  unsigned int max_cpus)
 {
 	/* install boot code shared by all CPUs */
 	shmobile_boot_fn = virt_to_phys(shmobile_smp_boot);
 
 	/* enable SCU and cache coherency on booting CPU */
+	shmobile_scu_base_phys = scu_base_phys;
+	shmobile_scu_base = ioremap(scu_base_phys, PAGE_SIZE);
 	scu_enable(shmobile_scu_base);
 	scu_power_mode(shmobile_scu_base, SCU_PM_NORMAL);
 
diff --git a/arch/arm/mach-shmobile/smp-emev2.c b/arch/arm/mach-shmobile/smp-emev2.c
index adbac6963f2b..4dfafd845452 100644
--- a/arch/arm/mach-shmobile/smp-emev2.c
+++ b/arch/arm/mach-shmobile/smp-emev2.c
@@ -45,8 +45,7 @@ static void __init emev2_smp_prepare_cpus(unsigned int max_cpus)
 	}
 
 	/* setup EMEV2 specific SCU bits */
-	shmobile_scu_base = ioremap(EMEV2_SCU_BASE, PAGE_SIZE);
-	shmobile_smp_scu_prepare_cpus(max_cpus);
+	shmobile_smp_scu_prepare_cpus(EMEV2_SCU_BASE, max_cpus);
 }
 
 const struct smp_operations emev2_smp_ops __initconst = {
diff --git a/arch/arm/mach-shmobile/smp-r8a7779.c b/arch/arm/mach-shmobile/smp-r8a7779.c
index 0b024a9dbd43..f5c31fbc10b2 100644
--- a/arch/arm/mach-shmobile/smp-r8a7779.c
+++ b/arch/arm/mach-shmobile/smp-r8a7779.c
@@ -94,8 +94,7 @@ static void __init r8a7779_smp_prepare_cpus(unsigned int max_cpus)
 	__raw_writel(__pa(shmobile_boot_vector), AVECR);
 
 	/* setup r8a7779 specific SCU bits */
-	shmobile_scu_base = IOMEM(R8A7779_SCU_BASE);
-	shmobile_smp_scu_prepare_cpus(max_cpus);
+	shmobile_smp_scu_prepare_cpus(R8A7779_SCU_BASE, max_cpus);
 
 	r8a7779_pm_init();
 
diff --git a/arch/arm/mach-shmobile/smp-sh73a0.c b/arch/arm/mach-shmobile/smp-sh73a0.c
index ee1a4b70604b..41137404382e 100644
--- a/arch/arm/mach-shmobile/smp-sh73a0.c
+++ b/arch/arm/mach-shmobile/smp-sh73a0.c
@@ -52,8 +52,7 @@ static void __init sh73a0_smp_prepare_cpus(unsigned int max_cpus)
 	__raw_writel(__pa(shmobile_boot_vector), SBAR);
 
 	/* setup sh73a0 specific SCU bits */
-	shmobile_scu_base = IOMEM(SH73A0_SCU_BASE);
-	shmobile_smp_scu_prepare_cpus(max_cpus);
+	shmobile_smp_scu_prepare_cpus(SH73A0_SCU_BASE, max_cpus);
 }
 
 const struct smp_operations sh73a0_smp_ops __initconst = {
-- 
2.1.4



From horms+renesas at verge.net.au  Tue Feb 23 17:21:25 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Feb 2016 10:21:25 +0900
Subject: [GIT PULL v2] Renesas ARM Based SoC Updates for v4.6
Message-ID: <cover.1456275652.git.horms+renesas@verge.net.au>

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM based SoC updates for v4.6.


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-for-v4.6

for you to fetch changes up to 71d076ceb245f0d9a05e552bbebd5911660bd2ac:

  ARM: shmobile: Enable PM and PM_GENERIC_DOMAINS for SoCs with PM Domains (2016-02-19 14:52:41 +0900)

----------------------------------------------------------------
Renesas ARM Based SoC Updates for v4.6

* Enable PM and PM_GENERIC_DOMAINS for SoCs with PM Domains
* Move emev2_smp_ops to emev2
* Remove legacy map_io callbacks on r8a7740 and emev2 SoCs
* Migrate to generic l2c OF initialization on r8a7740

----------------------------------------------------------------
Geert Uytterhoeven (6):
      ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization
      ARM: shmobile: r8a7740: Remove mapping of L2 cache controller registers
      ARM: shmobile: r8a7740: Remove legacy machine_desc.map_io() callback
      ARM: shmobile: emev2: Remove legacy machine_desc.map_io() callback
      ARM: shmobile: emev2: Move declaration of emev2_smp_ops to emev2.h
      ARM: shmobile: Enable PM and PM_GENERIC_DOMAINS for SoCs with PM Domains

 arch/arm/mach-shmobile/Kconfig         | 13 +++++++-----
 arch/arm/mach-shmobile/emev2.h         |  6 ++++++
 arch/arm/mach-shmobile/setup-emev2.c   | 22 ++-----------------
 arch/arm/mach-shmobile/setup-r8a7740.c | 39 ++--------------------------------
 arch/arm/mach-shmobile/smp-emev2.c     |  2 ++
 5 files changed, 20 insertions(+), 62 deletions(-)
 create mode 100644 arch/arm/mach-shmobile/emev2.h


From horms+renesas at verge.net.au  Tue Feb 23 17:21:26 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Feb 2016 10:21:26 +0900
Subject: [PATCH 1/6] ARM: shmobile: r8a7740: Migrate to generic l2c OF
 initialization
In-Reply-To: <cover.1456275652.git.horms+renesas@verge.net.au>
References: <cover.1456275652.git.horms+renesas@verge.net.au>
Message-ID: <4a6cc501511f68c9aafb4985231eaa932d97cff4.1456275652.git.horms+renesas@verge.net.au>

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

Migrate the generic r8a7740 platform from calling l2x0_of_init() to the
generic l2c OF initialization.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7740.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 0c8f80c5b04d..bf221e05c8dc 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -23,7 +23,6 @@
 #include <asm/mach/map.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
-#include <asm/hardware/cache-l2x0.h>
 
 #include "common.h"
 
@@ -110,10 +109,6 @@ static void __init r8a7740_generic_init(void)
 {
 	r8a7740_meram_workaround();
 
-#ifdef CONFIG_CACHE_L2X0
-	/* Shared attribute override enable, 32K*8way */
-	l2x0_init(IOMEM(0xf0002000), 0x00400000, 0xc20f0fff);
-#endif
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
@@ -123,6 +118,8 @@ static const char *const r8a7740_boards_compat_dt[] __initconst = {
 };
 
 DT_MACHINE_START(R8A7740_DT, "Generic R8A7740 (Flattened Device Tree)")
+	.l2c_aux_val	= 0,
+	.l2c_aux_mask	= ~0,
 	.map_io		= r8a7740_map_io,
 	.init_early	= shmobile_init_delay,
 	.init_irq	= r8a7740_init_irq_of,
-- 
2.1.4



From horms+renesas at verge.net.au  Tue Feb 23 17:21:27 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Feb 2016 10:21:27 +0900
Subject: [PATCH 2/6] ARM: shmobile: r8a7740: Remove mapping of L2 cache
 controller registers
In-Reply-To: <cover.1456275652.git.horms+renesas@verge.net.au>
References: <cover.1456275652.git.horms+renesas@verge.net.au>
Message-ID: <c4be044abc6292f392c286b599e260f0c1bbb8ba.1456275652.git.horms+renesas@verge.net.au>

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

Now all r8a7740-based platforms have been migrated to the generic l2c OF
initialization, it's no longer needed to map the L2 cache controller
registers from .map_io().

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7740.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index bf221e05c8dc..3e71cd4168dd 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -37,18 +37,6 @@ static struct map_desc r8a7740_io_desc[] __initdata = {
 		.length		= 160 << 20,
 		.type		= MT_DEVICE_NONSHARED
 	},
-#ifdef CONFIG_CACHE_L2X0
-	/*
-	 * for l2x0_init()
-	 * 0xf0100000-0xf0101000 -> 0xf0002000-0xf0003000
-	 */
-	{
-		.virtual	= 0xf0002000,
-		.pfn		= __phys_to_pfn(0xf0100000),
-		.length		= PAGE_SIZE,
-		.type		= MT_DEVICE_NONSHARED
-	},
-#endif
 };
 
 static void __init r8a7740_map_io(void)
-- 
2.1.4



From horms+renesas at verge.net.au  Tue Feb 23 17:21:28 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Feb 2016 10:21:28 +0900
Subject: [PATCH 3/6] ARM: shmobile: r8a7740: Remove legacy
 machine_desc.map_io() callback
In-Reply-To: <cover.1456275652.git.horms+renesas@verge.net.au>
References: <cover.1456275652.git.horms+renesas@verge.net.au>
Message-ID: <f5757b9af80af1ecf229bac6ba9ecb143a724aa0.1456275652.git.horms+renesas@verge.net.au>

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

Commit 37201ba5c99d0be8 ("ARM: shmobile: r8a7740: Migrate to generic l2c
OF initialization") removed the last user of the legacy "IOMEM()" macro
on r8a7740-based systems. Hence there's no longer a need to set up a
transparent mapping of system I/O registers. Remove the mapping and the
legacy machine_desc.map_io() callback.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-r8a7740.c | 20 --------------------
 1 file changed, 20 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-r8a7740.c b/arch/arm/mach-shmobile/setup-r8a7740.c
index 3e71cd4168dd..db6dbfbaf9f1 100644
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -26,25 +26,6 @@
 
 #include "common.h"
 
-static struct map_desc r8a7740_io_desc[] __initdata = {
-	 /*
-	  * for CPGA/INTC/PFC
-	  * 0xe6000000-0xefffffff -> 0xe6000000-0xefffffff
-	  */
-	{
-		.virtual	= 0xe6000000,
-		.pfn		= __phys_to_pfn(0xe6000000),
-		.length		= 160 << 20,
-		.type		= MT_DEVICE_NONSHARED
-	},
-};
-
-static void __init r8a7740_map_io(void)
-{
-	debug_ll_io_init();
-	iotable_init(r8a7740_io_desc, ARRAY_SIZE(r8a7740_io_desc));
-}
-
 /*
  * r8a7740 chip has lasting errata on MERAM buffer.
  * this is work-around for it.
@@ -108,7 +89,6 @@ static const char *const r8a7740_boards_compat_dt[] __initconst = {
 DT_MACHINE_START(R8A7740_DT, "Generic R8A7740 (Flattened Device Tree)")
 	.l2c_aux_val	= 0,
 	.l2c_aux_mask	= ~0,
-	.map_io		= r8a7740_map_io,
 	.init_early	= shmobile_init_delay,
 	.init_irq	= r8a7740_init_irq_of,
 	.init_machine	= r8a7740_generic_init,
-- 
2.1.4



From horms+renesas at verge.net.au  Tue Feb 23 17:21:29 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Feb 2016 10:21:29 +0900
Subject: [PATCH 4/6] ARM: shmobile: emev2: Remove legacy machine_desc.map_io()
 callback
In-Reply-To: <cover.1456275652.git.horms+renesas@verge.net.au>
References: <cover.1456275652.git.horms+renesas@verge.net.au>
Message-ID: <247ac89b99102f79483f7e08b9a94911f9b482d9.1456275652.git.horms+renesas@verge.net.au>

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

Commit FIXME ("ARM: shmobile: Consolidate SCU mapping code") removed the
last user of the static mapping on emev2-based systems.  Remove the
mapping and the legacy machine_desc.map_io() callback.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/setup-emev2.c | 18 ------------------
 1 file changed, 18 deletions(-)

diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
index 10b7cb5dcb3a..0829d0215c38 100644
--- a/arch/arm/mach-shmobile/setup-emev2.c
+++ b/arch/arm/mach-shmobile/setup-emev2.c
@@ -20,23 +20,6 @@
 #include <asm/mach/map.h>
 #include "common.h"
 
-static struct map_desc emev2_io_desc[] __initdata = {
-#ifdef CONFIG_SMP
-	/* 2M mapping for SCU + L2 controller */
-	{
-		.virtual	= 0xf0000000,
-		.pfn		= __phys_to_pfn(0x1e000000),
-		.length		= SZ_2M,
-		.type		= MT_DEVICE
-	},
-#endif
-};
-
-static void __init emev2_map_io(void)
-{
-	iotable_init(emev2_io_desc, ARRAY_SIZE(emev2_io_desc));
-}
-
 static const char *const emev2_boards_compat_dt[] __initconst = {
 	"renesas,emev2",
 	NULL,
@@ -46,7 +29,6 @@ extern const struct smp_operations emev2_smp_ops;
 
 DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 (Flattened Device Tree)")
 	.smp		= smp_ops(emev2_smp_ops),
-	.map_io		= emev2_map_io,
 	.init_early	= shmobile_init_delay,
 	.init_late	= shmobile_init_late,
 	.dt_compat	= emev2_boards_compat_dt,
-- 
2.1.4



From horms+renesas at verge.net.au  Tue Feb 23 17:21:30 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Feb 2016 10:21:30 +0900
Subject: [PATCH 5/6] ARM: shmobile: emev2: Move declaration of emev2_smp_ops
 to emev2.h
In-Reply-To: <cover.1456275652.git.horms+renesas@verge.net.au>
References: <cover.1456275652.git.horms+renesas@verge.net.au>
Message-ID: <c58b31aa46b4c1197acd3503e8c07da79b6bc1c2.1456275652.git.horms+renesas@verge.net.au>

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

make C=1:

    arch/arm/mach-shmobile/smp-emev2.c:51:29: warning: symbol 'emev2_smp_ops' was not declared. Should it be static?

To fix this, move the forward declaration of emev2_smp_ops to a header
file, and include it where appropriate.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/emev2.h       | 6 ++++++
 arch/arm/mach-shmobile/setup-emev2.c | 4 ++--
 arch/arm/mach-shmobile/smp-emev2.c   | 2 ++
 3 files changed, 10 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-shmobile/emev2.h

diff --git a/arch/arm/mach-shmobile/emev2.h b/arch/arm/mach-shmobile/emev2.h
new file mode 100644
index 000000000000..916d25f6780e
--- /dev/null
+++ b/arch/arm/mach-shmobile/emev2.h
@@ -0,0 +1,6 @@
+#ifndef __ASM_EMEV2_H__
+#define __ASM_EMEV2_H__
+
+extern const struct smp_operations emev2_smp_ops;
+
+#endif /* __ASM_EMEV2_H__ */
diff --git a/arch/arm/mach-shmobile/setup-emev2.c b/arch/arm/mach-shmobile/setup-emev2.c
index 0829d0215c38..3c99aaf65325 100644
--- a/arch/arm/mach-shmobile/setup-emev2.c
+++ b/arch/arm/mach-shmobile/setup-emev2.c
@@ -18,15 +18,15 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
+
 #include "common.h"
+#include "emev2.h"
 
 static const char *const emev2_boards_compat_dt[] __initconst = {
 	"renesas,emev2",
 	NULL,
 };
 
-extern const struct smp_operations emev2_smp_ops;
-
 DT_MACHINE_START(EMEV2_DT, "Generic Emma Mobile EV2 (Flattened Device Tree)")
 	.smp		= smp_ops(emev2_smp_ops),
 	.init_early	= shmobile_init_delay,
diff --git a/arch/arm/mach-shmobile/smp-emev2.c b/arch/arm/mach-shmobile/smp-emev2.c
index adbac6963f2b..871220bf5870 100644
--- a/arch/arm/mach-shmobile/smp-emev2.c
+++ b/arch/arm/mach-shmobile/smp-emev2.c
@@ -21,7 +21,9 @@
 #include <linux/delay.h>
 #include <asm/smp_plat.h>
 #include <asm/smp_scu.h>
+
 #include "common.h"
+#include "emev2.h"
 
 #define EMEV2_SCU_BASE 0x1e000000
 #define EMEV2_SMU_BASE 0xe0110000
-- 
2.1.4



From horms+renesas at verge.net.au  Tue Feb 23 17:21:17 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Feb 2016 10:21:17 +0900
Subject: [PATCH 2/2] ARM: shmobile: Kconfig: Get rid of old comment
In-Reply-To: <cover.1456275967.git.horms+renesas@verge.net.au>
References: <cover.1456275967.git.horms+renesas@verge.net.au>
Message-ID: <cf77db5165b606fca7d1d59735528ee43202392e.1456275967.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm+renesas at opensource.se>

Remove comment that used to be part of non-multiplatform
kernel support. Now with multiplatform-only we have no
Renesas-specific System Configuration entries.

Signed-off-by: Magnus Damm <damm+renesas at opensource.se>
Acked-by: by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index cd5f171f83ce..aa0b1a177d3e 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -99,6 +99,4 @@ config ARCH_SH73A0
 	bool "SH-Mobile AG5 (R8A73A00)"
 	select ARCH_RMOBILE
 	select RENESAS_INTC_IRQPIN
-
-comment "Renesas ARM SoCs System Configuration"
 endif
-- 
2.1.4



From horms+renesas at verge.net.au  Tue Feb 23 17:21:31 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Feb 2016 10:21:31 +0900
Subject: [PATCH 6/6] ARM: shmobile: Enable PM and PM_GENERIC_DOMAINS for SoCs
 with PM Domains
In-Reply-To: <cover.1456275652.git.horms+renesas@verge.net.au>
References: <cover.1456275652.git.horms+renesas@verge.net.au>
Message-ID: <71d076ceb245f0d9a05e552bbebd5911660bd2ac.1456275652.git.horms+renesas@verge.net.au>

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

All supported Renesas ARM SoCs (except for Emma Mobile EV2) have clock
domains. Some SoCs also have power domains. To ensure proper operation
of on-SoC modules, module clocks must be ungated, and power domains must
be powered up when needed.

Currently the user can choose to build a kernel with power management
enabled or disabled:
  - If CONFIG_PM=y, power domains and/or module clocks are handled
    dynamically by Runtime PM and the generic power domain.
  - If CONFIG_PM=n, power domains are assumed to be powered up by reset
    state or by the boot loader, and module clocks are handled by the
    legacy clock domain on driver (un)bind.
    The latter is implemented using a platform bus notifier, which
    applies not only to all on-SoC devices, but to all platform devices
    present in the system.

To remove the dependency on implicit assumptions, and to get rid of the
peculiarities of the legacy clock domain, enable CONFIG_PM and
CONFIG_PM_GENERIC_DOMAINS unconditionally, for all Renesas ARM SoCs with
clock and/or power domains.

This does cause an increase in kernel size.  Given bloat-o-meter reports
a modest increase of 26 KiB for an RZ/A1H kernel, this should not be a
problem, even when used on RZ/A1H with XIP and internal RAM only.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/mach-shmobile/Kconfig | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index cd5f171f83ce..2824b81f1a39 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -6,28 +6,30 @@ config ARCH_SHMOBILE_MULTI
 
 config PM_RCAR
 	bool
-	select PM_GENERIC_DOMAINS if PM
+	select PM
+	select PM_GENERIC_DOMAINS
 
 config PM_RMOBILE
 	bool
+	select PM
 	select PM_GENERIC_DOMAINS
 
 config ARCH_RCAR_GEN1
 	bool
-	select PM_RCAR if PM || SMP
+	select PM_RCAR
 	select RENESAS_INTC_IRQPIN
 	select SYS_SUPPORTS_SH_TMU
 
 config ARCH_RCAR_GEN2
 	bool
-	select PM_RCAR if PM || SMP
+	select PM_RCAR
 	select RENESAS_IRQC
 	select SYS_SUPPORTS_SH_CMT
 	select PCI_DOMAINS if PCI
 
 config ARCH_RMOBILE
 	bool
-	select PM_RMOBILE if PM
+	select PM_RMOBILE
 	select SYS_SUPPORTS_SH_CMT
 	select SYS_SUPPORTS_SH_TMU
 
@@ -55,7 +57,8 @@ config ARCH_EMEV2
 
 config ARCH_R7S72100
 	bool "RZ/A1H (R7S72100)"
-	select PM_GENERIC_DOMAINS if PM
+	select PM
+	select PM_GENERIC_DOMAINS
 	select SYS_SUPPORTS_SH_MTU2
 
 config ARCH_R8A73A4
-- 
2.1.4



From zhaoshenglong at huawei.com  Tue Feb 23 17:27:43 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 09:27:43 +0800
Subject: [PATCH v12 07/21] KVM: ARM64: PMU: Add perf event map and
 introduce perf event creating function
In-Reply-To: <56CC9A12.6040001@arm.com>
References: <1456133877-9584-1-git-send-email-zhaoshenglong@huawei.com>
 <1456133877-9584-8-git-send-email-zhaoshenglong@huawei.com>
 <56CC9A12.6040001@arm.com>
Message-ID: <56CD070F.7070603@huawei.com>



On 2016/2/24 1:42, Marc Zyngier wrote:
> Hi Shannon,
> 
> Still picking up on details...
> 
> On 22/02/16 09:37, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao at linaro.org>
>>
>> When we use tools like perf on host, perf passes the event type and the
>> id of this event type category to kernel, then kernel will map them to
>> hardware event number and write this number to PMU PMEVTYPER<n>_EL0
>> register. When getting the event number in KVM, directly use raw event
>> type to create a perf_event for it.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
>> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>>  arch/arm64/include/asm/perf_event.h |   2 +
>>  arch/arm64/kvm/Makefile             |   1 +
>>  include/kvm/arm_pmu.h               |  12 ++++
>>  virt/kvm/arm/pmu.c                  | 122 ++++++++++++++++++++++++++++++++++++
>>  4 files changed, 137 insertions(+)
>>  create mode 100644 virt/kvm/arm/pmu.c
>>
>> diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
>> index 5c77ef8..867140d 100644
>> --- a/arch/arm64/include/asm/perf_event.h
>> +++ b/arch/arm64/include/asm/perf_event.h
>> @@ -29,6 +29,8 @@
>>  #define ARMV8_PMU_PMCR_D	(1 << 3) /* CCNT counts every 64th cpu cycle */
>>  #define ARMV8_PMU_PMCR_X	(1 << 4) /* Export to ETM */
>>  #define ARMV8_PMU_PMCR_DP	(1 << 5) /* Disable CCNT if non-invasive debug*/
>> +/* Determines which bit of PMCCNTR_EL0 generates an overflow */
>> +#define ARMV8_PMU_PMCR_LC	(1 << 6)
> 
> nit: this #define is only being used in patch #14. Consider moving it
> there...
> 
Sure, thanks!

-- 
Shannon



From robh at kernel.org  Tue Feb 23 17:33:43 2016
From: robh at kernel.org (Rob Herring)
Date: Tue, 23 Feb 2016 19:33:43 -0600
Subject: [PATCH 2/2] Documentation: devicetree: Add PL310 PM bindings
In-Reply-To: <1456265019-23900-3-git-send-email-brad.mouring@ni.com>
References: <1456265019-23900-1-git-send-email-brad.mouring@ni.com>
 <1456265019-23900-3-git-send-email-brad.mouring@ni.com>
Message-ID: <20160224013343.GA9705@rob-hp-laptop>

On Tue, Feb 23, 2016 at 04:03:39PM -0600, Brad Mouring wrote:
> Document the DT bindings for controlling ARM PL310 Power Control
> settings.
> 
> Signed-off-by: Brad Mouring <brad.mouring at ni.com>
> Acked-by: Josh Cartwright <joshc at ni.com>
> ---
>  Documentation/devicetree/bindings/arm/l2c2x0.txt | 4 ++++
>  1 file changed, 4 insertions(+)

Acked-by: Rob Herring <robh at kernel.org>


From jamesjj.liao at mediatek.com  Tue Feb 23 18:26:13 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Wed, 24 Feb 2016 10:26:13 +0800
Subject: [PATCH v6 7/7] clk: mediatek: Enable critical clocks for MT2701
In-Reply-To: <1455529857.29688.36.camel@mtksdaap41>
References: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
 <1454665050-37776-8-git-send-email-jamesjj.liao@mediatek.com>
 <20160211213542.26445.82983@quark.deferred.io>
 <1455529857.29688.36.camel@mtksdaap41>
Message-ID: <1456280773.22545.1.camel@mtksdaap41>

Hi Mike,

On Mon, 2016-02-15 at 17:50 +0800, James Liao wrote:
> On Thu, 2016-02-11 at 13:35 -0800, Michael Turquette wrote:
> > Hi James,
> > 
> > Quoting James Liao (2016-02-05 01:37:30)
> > > Some system clocks should be turned on by default on MT2701.
> > > This patch enable these clocks when related clocks have
> > > been registered.
> > > 
> > > Signed-off-by: James Liao <jamesjj.liao at mediatek.com>
> > > ---
> > >  drivers/clk/mediatek/clk-mt2701.c | 23 +++++++++++++++++++++--
> > >  1 file changed, 21 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/clk/mediatek/clk-mt2701.c b/drivers/clk/mediatek/clk-mt2701.c
> > > index 01722e0..f7b4d52 100644
> > > --- a/drivers/clk/mediatek/clk-mt2701.c
> > > +++ b/drivers/clk/mediatek/clk-mt2701.c
> > > @@ -573,6 +573,21 @@ static const struct mtk_gate top_clks[] __initconst = {
> > >         GATE_TOP_AUD(CLK_TOP_AUD_I2S6_MCLK, "aud_i2s6_mclk", "aud_k6_src_div", 28),
> > >  };
> > >  
> > > +static struct clk_onecell_data *top_clk_data __initdata;
> > > +static struct clk_onecell_data *pll_clk_data __initdata;
> > > +
> > > +static void __init mtk_clk_enable_critical(void)
> > > +{
> > > +       if (!top_clk_data || !pll_clk_data)
> > > +               return;
> > > +
> > > +       clk_prepare_enable(pll_clk_data->clks[CLK_APMIXED_ARMPLL]);
> > > +       clk_prepare_enable(top_clk_data->clks[CLK_TOP_AXI_SEL]);
> > > +       clk_prepare_enable(top_clk_data->clks[CLK_TOP_MEM_SEL]);
> > > +       clk_prepare_enable(top_clk_data->clks[CLK_TOP_DDRPHYCFG_SEL]);
> > > +       clk_prepare_enable(top_clk_data->clks[CLK_TOP_RTC_SEL]);
> > > +}
> > 
> > I think we're close to having a better solution. Please see this patch
> > series[0] and let me know if it provides a better way for you to enable
> > these critical clocks instead of the open-coded solution.
> > 
> > [0] http://lkml.kernel.org/r/<1455225554-13267-1-git-send-email-mturquette at baylibre.com>
> > 
> 
> I took a quick view of this patchset, CLK_ENABLE_HAND_OFF is not
> suitable for these critical clocks. I'm not sure CLK_IS_CRITICAL
> suitable or not. A clock with CLK_IS_CRITICAL will be prepare_enable
> when it is registered. But if its parent is not registered into CCF, it
> will not be enabled even the parent clock register into CCF later.
> 
> > > +
> > >  static void __init mtk_topckgen_init(struct device_node *node)
> > >  {
> > >         struct clk_onecell_data *clk_data;
> > > @@ -585,7 +600,7 @@ static void __init mtk_topckgen_init(struct device_node *node)
> > >                 return;
> > >         }
> > >  
> > > -       clk_data = mtk_alloc_clk_data(CLK_TOP_NR);
> > > +       top_clk_data = clk_data = mtk_alloc_clk_data(CLK_TOP_NR);
> > >  
> > >         mtk_clk_register_fixed_clks(top_fixed_clks, ARRAY_SIZE(top_fixed_clks),
> > >                                                                 clk_data);
> > > @@ -606,6 +621,8 @@ static void __init mtk_topckgen_init(struct device_node *node)
> > >         if (r)
> > >                 pr_err("%s(): could not register clock provider: %d\n",
> > >                         __func__, r);
> > > +
> > > +       mtk_clk_enable_critical();
> > 
> > So you call the function here, and ...
> > >  }
> > >  CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt2701-topckgen", mtk_topckgen_init);
> > >  
> > > @@ -1201,7 +1218,7 @@ static void __init mtk_apmixedsys_init(struct device_node *node)
> > >         struct clk_onecell_data *clk_data;
> > >         int r;
> > >  
> > > -       clk_data = mtk_alloc_clk_data(ARRAY_SIZE(apmixed_plls));
> > > +       pll_clk_data = clk_data = mtk_alloc_clk_data(ARRAY_SIZE(apmixed_plls));
> > >         if (!clk_data)
> > >                 return;
> > >  
> > > @@ -1212,6 +1229,8 @@ static void __init mtk_apmixedsys_init(struct device_node *node)
> > >         if (r)
> > >                 pr_err("%s(): could not register clock provider: %d\n",
> > >                         __func__, r);
> > > +
> > > +       mtk_clk_enable_critical();
> > 
> > ... here as well. So the prepare_count and enable_count will be 2? I'm
> > not sure that this makes sense. If you have different clocks that need
> > to be enabled at different times (due to the split registration scheme
> > that you employ in this driver) then why not pass an array of those
> > clocks into mtk_clk_enable_critical?
> 
> No. After topckgen and apmixedsys initialized, critical clocks'
> reference count will be 1.
> 
> There is a guard at the beginning of mtk_clk_enable_critical():
> 
> 	if (!top_clk_data || !pll_clk_data)
> 		return;
> 
> So this function will be only executed when topckgen and apmixedsys init
> done.
> 
> We need to enable critical clocks:
> 
> 1. As early as possible.
> 2. After critical clocks and their parents are registered into CCF.
> 
> We need to wait all necessary clock providers because parents of
> critical clocks must be enabled at the same time. For example,
> CLK_TOP_AXI_SEL may have different parent on different platforms. We
> also need to keep new parent clock on if CLK_TOP_AXI_SEL change its
> parent dynamically.
> 
> Because we can't ensure the init ordering of clock providers, we can
> only check all necessary providers are registered or not in each init
> function.
> 
> > Anyways, like I mentioned above I think we're close to a solution to
> > handle this in the framework.
> > 
> > One question: do you ever want these critical clocks to be gated by a
> > driver, or do you want them always on, forever?
> 
> In this patch, these clocks should be always on (in SW view) even if
> there are other drivers controlling them.
> 
> If these is a common way to keep critical clocks and their parents on, I
> would like to use the common way. But the solution in your patch series
> [0] looks not handle parent clocks well. What's your suggestion to
> implement critical clocks base on [0]?

Do you have comments for this patch series?


Best regards,

James



From horms+renesas at verge.net.au  Tue Feb 23 18:29:04 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Feb 2016 11:29:04 +0900
Subject: [PATCH 0/2] ARM: dts: use fallback jpu compatibility string
Message-ID: <1456280946-14859-1-git-send-email-horms+renesas@verge.net.au>

Use recently added fallback jpu compatibility string in
device trees where it is not already used.

Based on renesas-devel-20160223-v4.5-rc5

Simon Horman (2):
  ARM: dts: r8a7790: use fallback jpu compatibility string
  ARM: dts: r8a7791: use fallback jpu compatibility string

 arch/arm/boot/dts/r8a7790.dtsi | 2 +-
 arch/arm/boot/dts/r8a7791.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.1.4



From horms+renesas at verge.net.au  Tue Feb 23 18:29:05 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Feb 2016 11:29:05 +0900
Subject: [PATCH 1/2] ARM: dts: r8a7790: use fallback jpu compatibility string
In-Reply-To: <1456280946-14859-1-git-send-email-horms+renesas@verge.net.au>
References: <1456280946-14859-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1456280946-14859-2-git-send-email-horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7790 device trees.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index ba4c2530d79f..e785831c30f3 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -989,7 +989,7 @@
 	};
 
 	jpu: jpeg-codec at fe980000 {
-		compatible = "renesas,jpu-r8a7790";
+		compatible = "renesas,jpu-r8a7790", "renesas,rcar-gen2-jpu";
 		reg = <0 0xfe980000 0 0x10300>;
 		interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7790_CLK_JPU>;
-- 
2.1.4



From horms+renesas at verge.net.au  Tue Feb 23 18:29:06 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Wed, 24 Feb 2016 11:29:06 +0900
Subject: [PATCH 2/2] ARM: dts: r8a7791: use fallback jpu compatibility string
In-Reply-To: <1456280946-14859-1-git-send-email-horms+renesas@verge.net.au>
References: <1456280946-14859-1-git-send-email-horms+renesas@verge.net.au>
Message-ID: <1456280946-14859-3-git-send-email-horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7791 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 6439f0569fe2..9bfd1dc054b3 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1035,7 +1035,7 @@
 	};
 
 	jpu: jpeg-codec at fe980000 {
-		compatible = "renesas,jpu-r8a7791";
+		compatible = "renesas,jpu-r8a7791", "renesas,rcar-gen2-jpu";
 		reg = <0 0xfe980000 0 0x10300>;
 		interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp1_clks R8A7791_CLK_JPU>;
-- 
2.1.4



From broonie at kernel.org  Tue Feb 23 19:19:36 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 24 Feb 2016 12:19:36 +0900
Subject: [PATCH] spi: imx: initialize usedma earlier
In-Reply-To: <1456223095-32185-1-git-send-email-s.hauer@pengutronix.de>
References: <20160223111559.3c2cb641@ipc1.ka-ro>
 <1456223095-32185-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <20160224031936.GI18327@sirena.org.uk>

On Tue, Feb 23, 2016 at 11:24:55AM +0100, Sascha Hauer wrote:
> The SoC specific config function does not know if DMA will be used or
> not. This information will be useful to configure the SPI controller
> correctly for DMA in following patches, so initialize the usedma
> variable before calling into the SoC specific config function.

Don't send new patches in reply to old serieses, especially not in the
middle of them - it makes it confusing to follow what's going on.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/e4e85b54/attachment-0001.sig>

From broonie at kernel.org  Tue Feb 23 19:28:42 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 24 Feb 2016 12:28:42 +0900
Subject: next-20160222 build: 5 failures 9 warnings (next-20160222)
In-Reply-To: <56CAE5E6.7030707@arm.com>
References: <E1aXlz4-000486-Pb@optimist> <20160222100832.GX18327@sirena.org.uk>
 <56CAE5E6.7030707@arm.com>
Message-ID: <20160224032842.GK18327@sirena.org.uk>

On Mon, Feb 22, 2016 at 10:41:42AM +0000, Marc Zyngier wrote:
> On 22/02/16 10:08, Mark Brown wrote:
> > On Mon, Feb 22, 2016 at 08:36:46AM +0000, Build bot for Mark Brown wrote:

> > Today's -next fails to build on arm64 due to:

> >> 	arm64-allnoconfig
> >> ../arch/arm64/include/asm/kvm_host.h:338:2: error: implicit declaration of function 'kvm_call_hyp' [-Werror=implicit-function-declaration]

> I'm about to push the following patch on top of the KVM tree:

> This will create a new conflict, but will make the resolution 100% clear.

That didn't work out unfortunately, the error is still there today.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/d80a1d16/attachment.sig>

From broonie at kernel.org  Tue Feb 23 19:37:08 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 24 Feb 2016 12:37:08 +0900
Subject: [PATCH] ASoC: rockchip: i2s: add default values for registers
In-Reply-To: <1456190362-15653-1-git-send-email-sugar.zhang@rock-chips.com>
References: <1456190362-15653-1-git-send-email-sugar.zhang@rock-chips.com>
Message-ID: <20160224033708.GM18327@sirena.org.uk>

On Tue, Feb 23, 2016 at 09:19:22AM +0800, Sugar Zhang wrote:
> this patch add default values for registers according description from TRM.

This patch has already been applied, please send incremental changes if
any are required.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/dcc533fc/attachment.sig>

From johnyoun at synopsys.com  Tue Feb 23 19:54:54 2016
From: johnyoun at synopsys.com (John Youn)
Date: Tue, 23 Feb 2016 19:54:54 -0800
Subject: [PATCH v2 0/2] usb: dwc2: Remove host and gadget only code from core
Message-ID: <cover.1456285777.git.johnyoun@synopsys.com>

This series moves the host/gadget-specific code from core.c to hcd.c
and gadget.c so that they will be compiled only when their respective
configurations are selected, or in DRD.

This is mostly just a straight move of the code. I have also added
some comments to group related functions together.

Compiled and tested in all three modes.

This should also solve the issue reported here:
http://marc.info/?l=linux-usb&m=145591813410106&w=2

Although I wasn't able to test it... couldn't figure out how to
disable CONFIG_USB and enable DWC2 in gadget mode.

Felipe,

This should be applied after Doug's series on your testing/next
branch.

Regards,
John

v2:
* Addressed issues from Douglas Anderson
* Restored comments on dwc2_calc_frame_interval()
* Made some functions static and removed their prototypes from headers
* Added tags

John Youn (2):
  usb: dwc2: Move register save and restore functions
  usb: dwc2: Move host-specific core functions into hcd.c

 drivers/usb/dwc2/core.c   | 1959 ---------------------------------------------
 drivers/usb/dwc2/core.h   |   37 +-
 drivers/usb/dwc2/gadget.c |  102 +++
 drivers/usb/dwc2/hcd.c    | 1959 +++++++++++++++++++++++++++++++++++++++++++--
 drivers/usb/dwc2/hcd.h    |    8 +
 5 files changed, 2033 insertions(+), 2032 deletions(-)

-- 
2.6.3



From johnyoun at synopsys.com  Tue Feb 23 19:54:57 2016
From: johnyoun at synopsys.com (John Youn)
Date: Tue, 23 Feb 2016 19:54:57 -0800
Subject: [PATCH v2 1/2] usb: dwc2: Move register save and restore functions
In-Reply-To: <cover.1456285777.git.johnyoun@synopsys.com>
References: <cover.1456285777.git.johnyoun@synopsys.com>
Message-ID: <7bad59a44a0f85962b181a79ba7fd5081763b0a2.1456285777.git.johnyoun@synopsys.com>

Move the register save and restore functions into the host and gadget
specific files.

Tested-by: Douglas Anderson <dianders at chromium.org>
Reviewed-by: Douglas Anderson <dianders at chromium.org>
Signed-off-by: John Youn <johnyoun at synopsys.com>
---
 drivers/usb/dwc2/core.c   | 183 ----------------------------------------------
 drivers/usb/dwc2/core.h   |  13 ++++
 drivers/usb/dwc2/gadget.c | 102 ++++++++++++++++++++++++++
 drivers/usb/dwc2/hcd.c    |  64 ++++++++++++++++
 4 files changed, 179 insertions(+), 183 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 3c9c0b2..dc60339 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -56,189 +56,6 @@
 #include "core.h"
 #include "hcd.h"
 
-#if IS_ENABLED(CONFIG_USB_DWC2_HOST) || IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE)
-/**
- * dwc2_backup_host_registers() - Backup controller host registers.
- * When suspending usb bus, registers needs to be backuped
- * if controller power is disabled once suspended.
- *
- * @hsotg: Programming view of the DWC_otg controller
- */
-static int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
-{
-	struct dwc2_hregs_backup *hr;
-	int i;
-
-	dev_dbg(hsotg->dev, "%s\n", __func__);
-
-	/* Backup Host regs */
-	hr = &hsotg->hr_backup;
-	hr->hcfg = dwc2_readl(hsotg->regs + HCFG);
-	hr->haintmsk = dwc2_readl(hsotg->regs + HAINTMSK);
-	for (i = 0; i < hsotg->core_params->host_channels; ++i)
-		hr->hcintmsk[i] = dwc2_readl(hsotg->regs + HCINTMSK(i));
-
-	hr->hprt0 = dwc2_read_hprt0(hsotg);
-	hr->hfir = dwc2_readl(hsotg->regs + HFIR);
-	hr->valid = true;
-
-	return 0;
-}
-
-/**
- * dwc2_restore_host_registers() - Restore controller host registers.
- * When resuming usb bus, device registers needs to be restored
- * if controller power were disabled.
- *
- * @hsotg: Programming view of the DWC_otg controller
- */
-static int dwc2_restore_host_registers(struct dwc2_hsotg *hsotg)
-{
-	struct dwc2_hregs_backup *hr;
-	int i;
-
-	dev_dbg(hsotg->dev, "%s\n", __func__);
-
-	/* Restore host regs */
-	hr = &hsotg->hr_backup;
-	if (!hr->valid) {
-		dev_err(hsotg->dev, "%s: no host registers to restore\n",
-				__func__);
-		return -EINVAL;
-	}
-	hr->valid = false;
-
-	dwc2_writel(hr->hcfg, hsotg->regs + HCFG);
-	dwc2_writel(hr->haintmsk, hsotg->regs + HAINTMSK);
-
-	for (i = 0; i < hsotg->core_params->host_channels; ++i)
-		dwc2_writel(hr->hcintmsk[i], hsotg->regs + HCINTMSK(i));
-
-	dwc2_writel(hr->hprt0, hsotg->regs + HPRT0);
-	dwc2_writel(hr->hfir, hsotg->regs + HFIR);
-	hsotg->frame_number = 0;
-
-	return 0;
-}
-#else
-static inline int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
-{ return 0; }
-
-static inline int dwc2_restore_host_registers(struct dwc2_hsotg *hsotg)
-{ return 0; }
-#endif
-
-#if IS_ENABLED(CONFIG_USB_DWC2_PERIPHERAL) || \
-	IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE)
-/**
- * dwc2_backup_device_registers() - Backup controller device registers.
- * When suspending usb bus, registers needs to be backuped
- * if controller power is disabled once suspended.
- *
- * @hsotg: Programming view of the DWC_otg controller
- */
-static int dwc2_backup_device_registers(struct dwc2_hsotg *hsotg)
-{
-	struct dwc2_dregs_backup *dr;
-	int i;
-
-	dev_dbg(hsotg->dev, "%s\n", __func__);
-
-	/* Backup dev regs */
-	dr = &hsotg->dr_backup;
-
-	dr->dcfg = dwc2_readl(hsotg->regs + DCFG);
-	dr->dctl = dwc2_readl(hsotg->regs + DCTL);
-	dr->daintmsk = dwc2_readl(hsotg->regs + DAINTMSK);
-	dr->diepmsk = dwc2_readl(hsotg->regs + DIEPMSK);
-	dr->doepmsk = dwc2_readl(hsotg->regs + DOEPMSK);
-
-	for (i = 0; i < hsotg->num_of_eps; i++) {
-		/* Backup IN EPs */
-		dr->diepctl[i] = dwc2_readl(hsotg->regs + DIEPCTL(i));
-
-		/* Ensure DATA PID is correctly configured */
-		if (dr->diepctl[i] & DXEPCTL_DPID)
-			dr->diepctl[i] |= DXEPCTL_SETD1PID;
-		else
-			dr->diepctl[i] |= DXEPCTL_SETD0PID;
-
-		dr->dieptsiz[i] = dwc2_readl(hsotg->regs + DIEPTSIZ(i));
-		dr->diepdma[i] = dwc2_readl(hsotg->regs + DIEPDMA(i));
-
-		/* Backup OUT EPs */
-		dr->doepctl[i] = dwc2_readl(hsotg->regs + DOEPCTL(i));
-
-		/* Ensure DATA PID is correctly configured */
-		if (dr->doepctl[i] & DXEPCTL_DPID)
-			dr->doepctl[i] |= DXEPCTL_SETD1PID;
-		else
-			dr->doepctl[i] |= DXEPCTL_SETD0PID;
-
-		dr->doeptsiz[i] = dwc2_readl(hsotg->regs + DOEPTSIZ(i));
-		dr->doepdma[i] = dwc2_readl(hsotg->regs + DOEPDMA(i));
-	}
-	dr->valid = true;
-	return 0;
-}
-
-/**
- * dwc2_restore_device_registers() - Restore controller device registers.
- * When resuming usb bus, device registers needs to be restored
- * if controller power were disabled.
- *
- * @hsotg: Programming view of the DWC_otg controller
- */
-static int dwc2_restore_device_registers(struct dwc2_hsotg *hsotg)
-{
-	struct dwc2_dregs_backup *dr;
-	u32 dctl;
-	int i;
-
-	dev_dbg(hsotg->dev, "%s\n", __func__);
-
-	/* Restore dev regs */
-	dr = &hsotg->dr_backup;
-	if (!dr->valid) {
-		dev_err(hsotg->dev, "%s: no device registers to restore\n",
-				__func__);
-		return -EINVAL;
-	}
-	dr->valid = false;
-
-	dwc2_writel(dr->dcfg, hsotg->regs + DCFG);
-	dwc2_writel(dr->dctl, hsotg->regs + DCTL);
-	dwc2_writel(dr->daintmsk, hsotg->regs + DAINTMSK);
-	dwc2_writel(dr->diepmsk, hsotg->regs + DIEPMSK);
-	dwc2_writel(dr->doepmsk, hsotg->regs + DOEPMSK);
-
-	for (i = 0; i < hsotg->num_of_eps; i++) {
-		/* Restore IN EPs */
-		dwc2_writel(dr->diepctl[i], hsotg->regs + DIEPCTL(i));
-		dwc2_writel(dr->dieptsiz[i], hsotg->regs + DIEPTSIZ(i));
-		dwc2_writel(dr->diepdma[i], hsotg->regs + DIEPDMA(i));
-
-		/* Restore OUT EPs */
-		dwc2_writel(dr->doepctl[i], hsotg->regs + DOEPCTL(i));
-		dwc2_writel(dr->doeptsiz[i], hsotg->regs + DOEPTSIZ(i));
-		dwc2_writel(dr->doepdma[i], hsotg->regs + DOEPDMA(i));
-	}
-
-	/* Set the Power-On Programming done bit */
-	dctl = dwc2_readl(hsotg->regs + DCTL);
-	dctl |= DCTL_PWRONPRGDONE;
-	dwc2_writel(dctl, hsotg->regs + DCTL);
-
-	return 0;
-}
-#else
-static inline int dwc2_backup_device_registers(struct dwc2_hsotg *hsotg)
-{ return 0; }
-
-static inline int dwc2_restore_device_registers(struct dwc2_hsotg *hsotg)
-{ return 0; }
-#endif
-
 /**
  * dwc2_backup_global_registers() - Backup global controller registers.
  * When suspending usb bus, registers needs to be backuped
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1159259..606629a 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -1295,6 +1295,8 @@ extern void dwc2_hsotg_core_connect(struct dwc2_hsotg *hsotg);
 extern void dwc2_hsotg_disconnect(struct dwc2_hsotg *dwc2);
 extern int dwc2_hsotg_set_test_mode(struct dwc2_hsotg *hsotg, int testmode);
 #define dwc2_is_device_connected(hsotg) (hsotg->connected)
+int dwc2_backup_device_registers(struct dwc2_hsotg *hsotg);
+int dwc2_restore_device_registers(struct dwc2_hsotg *hsotg);
 #else
 static inline int dwc2_hsotg_remove(struct dwc2_hsotg *dwc2)
 { return 0; }
@@ -1312,6 +1314,10 @@ static inline int dwc2_hsotg_set_test_mode(struct dwc2_hsotg *hsotg,
 							int testmode)
 { return 0; }
 #define dwc2_is_device_connected(hsotg) (0)
+static inline int dwc2_backup_device_registers(struct dwc2_hsotg *hsotg)
+{ return 0; }
+static inline int dwc2_restore_device_registers(struct dwc2_hsotg *hsotg)
+{ return 0; }
 #endif
 
 #if IS_ENABLED(CONFIG_USB_DWC2_HOST) || IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE)
@@ -1320,6 +1326,8 @@ extern int dwc2_hcd_get_future_frame_number(struct dwc2_hsotg *hsotg, int us);
 extern void dwc2_hcd_connect(struct dwc2_hsotg *hsotg);
 extern void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool force);
 extern void dwc2_hcd_start(struct dwc2_hsotg *hsotg);
+int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg);
+int dwc2_restore_host_registers(struct dwc2_hsotg *hsotg);
 #else
 static inline int dwc2_hcd_get_frame_number(struct dwc2_hsotg *hsotg)
 { return 0; }
@@ -1332,6 +1340,11 @@ static inline void dwc2_hcd_start(struct dwc2_hsotg *hsotg) {}
 static inline void dwc2_hcd_remove(struct dwc2_hsotg *hsotg) {}
 static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
 { return 0; }
+static inline int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
+{ return 0; }
+static inline int dwc2_restore_host_registers(struct dwc2_hsotg *hsotg)
+{ return 0; }
+
 #endif
 
 #endif /* __DWC2_CORE_H__ */
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 422ab7d..e9940dd 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3668,3 +3668,105 @@ int dwc2_hsotg_resume(struct dwc2_hsotg *hsotg)
 
 	return 0;
 }
+
+/**
+ * dwc2_backup_device_registers() - Backup controller device registers.
+ * When suspending usb bus, registers needs to be backuped
+ * if controller power is disabled once suspended.
+ *
+ * @hsotg: Programming view of the DWC_otg controller
+ */
+int dwc2_backup_device_registers(struct dwc2_hsotg *hsotg)
+{
+	struct dwc2_dregs_backup *dr;
+	int i;
+
+	dev_dbg(hsotg->dev, "%s\n", __func__);
+
+	/* Backup dev regs */
+	dr = &hsotg->dr_backup;
+
+	dr->dcfg = dwc2_readl(hsotg->regs + DCFG);
+	dr->dctl = dwc2_readl(hsotg->regs + DCTL);
+	dr->daintmsk = dwc2_readl(hsotg->regs + DAINTMSK);
+	dr->diepmsk = dwc2_readl(hsotg->regs + DIEPMSK);
+	dr->doepmsk = dwc2_readl(hsotg->regs + DOEPMSK);
+
+	for (i = 0; i < hsotg->num_of_eps; i++) {
+		/* Backup IN EPs */
+		dr->diepctl[i] = dwc2_readl(hsotg->regs + DIEPCTL(i));
+
+		/* Ensure DATA PID is correctly configured */
+		if (dr->diepctl[i] & DXEPCTL_DPID)
+			dr->diepctl[i] |= DXEPCTL_SETD1PID;
+		else
+			dr->diepctl[i] |= DXEPCTL_SETD0PID;
+
+		dr->dieptsiz[i] = dwc2_readl(hsotg->regs + DIEPTSIZ(i));
+		dr->diepdma[i] = dwc2_readl(hsotg->regs + DIEPDMA(i));
+
+		/* Backup OUT EPs */
+		dr->doepctl[i] = dwc2_readl(hsotg->regs + DOEPCTL(i));
+
+		/* Ensure DATA PID is correctly configured */
+		if (dr->doepctl[i] & DXEPCTL_DPID)
+			dr->doepctl[i] |= DXEPCTL_SETD1PID;
+		else
+			dr->doepctl[i] |= DXEPCTL_SETD0PID;
+
+		dr->doeptsiz[i] = dwc2_readl(hsotg->regs + DOEPTSIZ(i));
+		dr->doepdma[i] = dwc2_readl(hsotg->regs + DOEPDMA(i));
+	}
+	dr->valid = true;
+	return 0;
+}
+
+/**
+ * dwc2_restore_device_registers() - Restore controller device registers.
+ * When resuming usb bus, device registers needs to be restored
+ * if controller power were disabled.
+ *
+ * @hsotg: Programming view of the DWC_otg controller
+ */
+int dwc2_restore_device_registers(struct dwc2_hsotg *hsotg)
+{
+	struct dwc2_dregs_backup *dr;
+	u32 dctl;
+	int i;
+
+	dev_dbg(hsotg->dev, "%s\n", __func__);
+
+	/* Restore dev regs */
+	dr = &hsotg->dr_backup;
+	if (!dr->valid) {
+		dev_err(hsotg->dev, "%s: no device registers to restore\n",
+			__func__);
+		return -EINVAL;
+	}
+	dr->valid = false;
+
+	dwc2_writel(dr->dcfg, hsotg->regs + DCFG);
+	dwc2_writel(dr->dctl, hsotg->regs + DCTL);
+	dwc2_writel(dr->daintmsk, hsotg->regs + DAINTMSK);
+	dwc2_writel(dr->diepmsk, hsotg->regs + DIEPMSK);
+	dwc2_writel(dr->doepmsk, hsotg->regs + DOEPMSK);
+
+	for (i = 0; i < hsotg->num_of_eps; i++) {
+		/* Restore IN EPs */
+		dwc2_writel(dr->diepctl[i], hsotg->regs + DIEPCTL(i));
+		dwc2_writel(dr->dieptsiz[i], hsotg->regs + DIEPTSIZ(i));
+		dwc2_writel(dr->diepdma[i], hsotg->regs + DIEPDMA(i));
+
+		/* Restore OUT EPs */
+		dwc2_writel(dr->doepctl[i], hsotg->regs + DOEPCTL(i));
+		dwc2_writel(dr->doeptsiz[i], hsotg->regs + DOEPTSIZ(i));
+		dwc2_writel(dr->doepdma[i], hsotg->regs + DOEPDMA(i));
+	}
+
+	/* Set the Power-On Programming done bit */
+	dctl = dwc2_readl(hsotg->regs + DCTL);
+	dctl |= DCTL_PWRONPRGDONE;
+	dwc2_writel(dctl, hsotg->regs + DCTL);
+
+	return 0;
+}
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 2b5a706..b403f6a 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -3433,3 +3433,67 @@ void dwc2_hcd_remove(struct dwc2_hsotg *hsotg)
 	kfree(hsotg->frame_num_array);
 #endif
 }
+
+/**
+ * dwc2_backup_host_registers() - Backup controller host registers.
+ * When suspending usb bus, registers needs to be backuped
+ * if controller power is disabled once suspended.
+ *
+ * @hsotg: Programming view of the DWC_otg controller
+ */
+int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
+{
+	struct dwc2_hregs_backup *hr;
+	int i;
+
+	dev_dbg(hsotg->dev, "%s\n", __func__);
+
+	/* Backup Host regs */
+	hr = &hsotg->hr_backup;
+	hr->hcfg = dwc2_readl(hsotg->regs + HCFG);
+	hr->haintmsk = dwc2_readl(hsotg->regs + HAINTMSK);
+	for (i = 0; i < hsotg->core_params->host_channels; ++i)
+		hr->hcintmsk[i] = dwc2_readl(hsotg->regs + HCINTMSK(i));
+
+	hr->hprt0 = dwc2_read_hprt0(hsotg);
+	hr->hfir = dwc2_readl(hsotg->regs + HFIR);
+	hr->valid = true;
+
+	return 0;
+}
+
+/**
+ * dwc2_restore_host_registers() - Restore controller host registers.
+ * When resuming usb bus, device registers needs to be restored
+ * if controller power were disabled.
+ *
+ * @hsotg: Programming view of the DWC_otg controller
+ */
+int dwc2_restore_host_registers(struct dwc2_hsotg *hsotg)
+{
+	struct dwc2_hregs_backup *hr;
+	int i;
+
+	dev_dbg(hsotg->dev, "%s\n", __func__);
+
+	/* Restore host regs */
+	hr = &hsotg->hr_backup;
+	if (!hr->valid) {
+		dev_err(hsotg->dev, "%s: no host registers to restore\n",
+			__func__);
+		return -EINVAL;
+	}
+	hr->valid = false;
+
+	dwc2_writel(hr->hcfg, hsotg->regs + HCFG);
+	dwc2_writel(hr->haintmsk, hsotg->regs + HAINTMSK);
+
+	for (i = 0; i < hsotg->core_params->host_channels; ++i)
+		dwc2_writel(hr->hcintmsk[i], hsotg->regs + HCINTMSK(i));
+
+	dwc2_writel(hr->hprt0, hsotg->regs + HPRT0);
+	dwc2_writel(hr->hfir, hsotg->regs + HFIR);
+	hsotg->frame_number = 0;
+
+	return 0;
+}
-- 
2.6.3



From sfr at canb.auug.org.au  Tue Feb 23 19:48:59 2016
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Wed, 24 Feb 2016 14:48:59 +1100
Subject: next-20160222 build: 5 failures 9 warnings (next-20160222)
In-Reply-To: <20160224032842.GK18327@sirena.org.uk>
References: <E1aXlz4-000486-Pb@optimist> <20160222100832.GX18327@sirena.org.uk>
 <56CAE5E6.7030707@arm.com> <20160224032842.GK18327@sirena.org.uk>
Message-ID: <20160224144859.027a3564@canb.auug.org.au>

Hi Mark,

On Wed, 24 Feb 2016 12:28:42 +0900 Mark Brown <broonie at kernel.org> wrote:
>
> That didn't work out unfortunately, the error is still there today.

Yeah, the patch didn't hit -next yesterday and I missed the opportunity
to fix in manually.  However, it should be fixed in today's linux-next
(out in a few hours, hopefully).

-- 
Cheers,
Stephen Rothwell


From pankaj.dubey at samsung.com  Tue Feb 23 20:01:59 2016
From: pankaj.dubey at samsung.com (pankaj.dubey)
Date: Wed, 24 Feb 2016 09:31:59 +0530
Subject: [PATCH 3/3] ARM: EXYNOS: cleanup header files inclusion
In-Reply-To: <56CD0143.2010909@samsung.com>
References: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
 <1456135396-17767-4-git-send-email-pankaj.dubey@samsung.com>
 <56CBA32D.4020905@samsung.com> <56CC23AD.10103@samsung.com>
 <56CD0143.2010909@samsung.com>
Message-ID: <56CD2B37.1080008@samsung.com>



On Wednesday 24 February 2016 06:32 AM, Krzysztof Kozlowski wrote:
> On 23.02.2016 18:17, pankaj.dubey wrote:
>> Hi Krzysztof,
>>
>> On Tuesday 23 February 2016 05:39 AM, Krzysztof Kozlowski wrote:
>>> On 22.02.2016 19:03, Pankaj Dubey wrote:
>>>> This includes trivial cleanup in exynos files such as
>>>>     - remove unused header files inclusion from exynos.c, s5p-dev-mfc.c,
>>>>       firmware.c, pm.c.
>>>>     - move inclusion of of.h from common.h to pm.c where it is really
>>>>       required
>>>>
>>>> Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
>>>> ---
>>>>  arch/arm/mach-exynos/common.h      | 1 -
>>>>  arch/arm/mach-exynos/exynos.c      | 5 -----
>>>>  arch/arm/mach-exynos/firmware.c    | 2 --
>>>>  arch/arm/mach-exynos/platsmp.c     | 1 -
>>>>  arch/arm/mach-exynos/pm.c          | 4 +---
>>>>  arch/arm/mach-exynos/s5p-dev-mfc.c | 1 -
>>>>  6 files changed, 1 insertion(+), 13 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
>>>> index e349a03..5365bf1 100644
>>>> --- a/arch/arm/mach-exynos/common.h
>>>> +++ b/arch/arm/mach-exynos/common.h
>>>> @@ -12,7 +12,6 @@
>>>>  #ifndef __ARCH_ARM_MACH_EXYNOS_COMMON_H
>>>>  #define __ARCH_ARM_MACH_EXYNOS_COMMON_H
>>>>  
>>>> -#include <linux/of.h>
>>>>  #include <linux/platform_data/cpuidle-exynos.h>
>>>>  
>>>>  #define EXYNOS3250_SOC_ID	0xE3472000
>>>> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
>>>> index 99947ad..54262a1 100644
>>>> --- a/arch/arm/mach-exynos/exynos.c
>>>> +++ b/arch/arm/mach-exynos/exynos.c
>>>> @@ -11,14 +11,10 @@
>>>>  
>>>>  #include <linux/init.h>
>>>>  #include <linux/io.h>
>>>> -#include <linux/kernel.h>
>>>> -#include <linux/serial_s3c.h>
>>>>  #include <linux/of.h>
>>>>  #include <linux/of_address.h>
>>>>  #include <linux/of_fdt.h>
>>>>  #include <linux/of_platform.h>
>>>> -#include <linux/platform_device.h>
>>>
>>> platform_device is actually used in that file. It looks unused because
>>> it is pulled by of_platform, but it makes sense to include it here.
>>>
>> Thanks for review.
>>
>> Well I tried to grep for of_platform.h and platform_device.h in
>> arch/arm/ and out of 88 files including of_platform.h only 16 files are
>> including platform_device.h also. So majority do not include both of
>> them even do they need. So majority of files both are not included. So
>> If we got with majority it's not required. What's your opinion?
> 
> Actually most of files including of_platform.h and not including
> platform_device.h just do not require the second one (I checked like 20
> of them and only one was referring to platform device function... of
> course maybe my random selection of 20 files was not random enough :) ).
> They do not directly reference platform device stuff.
> 
> In that file the platform_device is used so the header may stay.

OK. will resend this again with keeping back platform_device.h in
exynos.c file.

Thanks,
Pankaj Dubey
> 
> Best regards,
> Krzysztof
> 


From zhaoshenglong at huawei.com  Tue Feb 23 21:08:24 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:24 +0800
Subject: [PATCH v13 04/20] KVM: ARM64: Add access handler for PMSELR register
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-5-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Since the reset value of PMSELR_EL0 is UNKNOWN, use reset_unknown for
its reset handler. When reading PMSELR, return the PMSELR.SEL field to
guest.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/kvm_host.h |  1 +
 arch/arm64/kvm/sys_regs.c         | 20 ++++++++++++++++++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 1f3ca98..e342b48 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -117,6 +117,7 @@ enum vcpu_sysreg {
 
 	/* Performance Monitors Registers */
 	PMCR_EL0,	/* Control Register */
+	PMSELR_EL0,	/* Event Counter Selection Register */
 
 	/* 32bit specific registers. Keep them at the end of the range */
 	DACR32_EL2,	/* Domain Access Control Register */
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index e88ae2d..b05e20f 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -477,6 +477,22 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			  const struct sys_reg_desc *r)
+{
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write)
+		vcpu_sys_reg(vcpu, PMSELR_EL0) = p->regval;
+	else
+		/* return PMSELR.SEL field */
+		p->regval = vcpu_sys_reg(vcpu, PMSELR_EL0)
+			    & ARMV8_PMU_COUNTER_MASK;
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -676,7 +692,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  trap_raz_wi },
 	/* PMSELR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
-	  trap_raz_wi },
+	  access_pmselr, reset_unknown, PMSELR_EL0 },
 	/* PMCEID0_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
 	  trap_raz_wi },
@@ -927,7 +943,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:33 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:33 +0800
Subject: [PATCH v13 13/20] KVM: ARM64: Add helper to handle PMCR register bits
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-14-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

According to ARMv8 spec, when writing 1 to PMCR.E, all counters are
enabled by PMCNTENSET, while writing 0 to PMCR.E, all counters are
disabled. When writing 1 to PMCR.P, reset all event counters, not
including PMCCNTR, to zero. When writing 1 to PMCR.C, reset PMCCNTR to
zero.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/include/asm/perf_event.h |  2 ++
 arch/arm64/kvm/sys_regs.c           |  1 +
 include/kvm/arm_pmu.h               |  2 ++
 virt/kvm/arm/pmu.c                  | 34 ++++++++++++++++++++++++++++++++++
 4 files changed, 39 insertions(+)

diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
index ceb14a1..c3f5937 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -29,6 +29,8 @@
 #define ARMV8_PMU_PMCR_D	(1 << 3) /* CCNT counts every 64th cpu cycle */
 #define ARMV8_PMU_PMCR_X	(1 << 4) /* Export to ETM */
 #define ARMV8_PMU_PMCR_DP	(1 << 5) /* Disable CCNT if non-invasive debug*/
+/* Determines which bit of PMCCNTR_EL0 generates an overflow */
+#define ARMV8_PMU_PMCR_LC	(1 << 6)
 #define	ARMV8_PMU_PMCR_N_SHIFT	11	 /* Number of counters supported */
 #define	ARMV8_PMU_PMCR_N_MASK	0x1f
 #define	ARMV8_PMU_PMCR_MASK	0x3f	 /* Mask for writable bits */
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 10e5379..12f36ef 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -467,6 +467,7 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 		val &= ~ARMV8_PMU_PMCR_MASK;
 		val |= p->regval & ARMV8_PMU_PMCR_MASK;
 		vcpu_sys_reg(vcpu, PMCR_EL0) = val;
+		kvm_pmu_handle_pmcr(vcpu, val);
 	} else {
 		/* PMCR.P & PMCR.C are RAZ */
 		val = vcpu_sys_reg(vcpu, PMCR_EL0)
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 348c4c9..8bc92d1 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -45,6 +45,7 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 #else
@@ -67,6 +68,7 @@ static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 9fc775e..cda869c 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -210,6 +210,40 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
 	}
 }
 
+/**
+ * kvm_pmu_handle_pmcr - handle PMCR register
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCR register
+ */
+void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val)
+{
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_pmc *pmc;
+	u64 mask;
+	int i;
+
+	mask = kvm_pmu_valid_counter_mask(vcpu);
+	if (val & ARMV8_PMU_PMCR_E) {
+		kvm_pmu_enable_counter(vcpu,
+				vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & mask);
+	} else {
+		kvm_pmu_disable_counter(vcpu, mask);
+	}
+
+	if (val & ARMV8_PMU_PMCR_C)
+		kvm_pmu_set_counter_value(vcpu, ARMV8_PMU_CYCLE_IDX, 0);
+
+	if (val & ARMV8_PMU_PMCR_P) {
+		for (i = 0; i < ARMV8_PMU_CYCLE_IDX; i++)
+			kvm_pmu_set_counter_value(vcpu, i, 0);
+	}
+
+	if (val & ARMV8_PMU_PMCR_LC) {
+		pmc = &pmu->pmc[ARMV8_PMU_CYCLE_IDX];
+		pmc->bitmask = 0xffffffffffffffffUL;
+	}
+}
+
 static bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu, u64 select_idx)
 {
 	return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E) &&
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:22 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:22 +0800
Subject: [PATCH v13 02/20] KVM: ARM64: Define PMU data structure for each vcpu
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-3-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Here we plan to support virtual PMU for guest by full software
emulation, so define some basic structs and functions preparing for
futher steps. Define struct kvm_pmc for performance monitor counter and
struct kvm_pmu for performance monitor unit for each vcpu. According to
ARMv8 spec, the PMU contains at most 32(ARMV8_PMU_MAX_COUNTERS)
counters.

Since this only supports ARM64 (or PMUv3), add a separate config symbol
for it.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/kvm_host.h |  2 ++
 arch/arm64/kvm/Kconfig            |  7 +++++++
 include/kvm/arm_pmu.h             | 42 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 51 insertions(+)
 create mode 100644 include/kvm/arm_pmu.h

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 689d4c9..6f0241f 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -36,6 +36,7 @@
 
 #include <kvm/arm_vgic.h>
 #include <kvm/arm_arch_timer.h>
+#include <kvm/arm_pmu.h>
 
 #define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
 
@@ -211,6 +212,7 @@ struct kvm_vcpu_arch {
 	/* VGIC state */
 	struct vgic_cpu vgic_cpu;
 	struct arch_timer_cpu timer_cpu;
+	struct kvm_pmu pmu;
 
 	/*
 	 * Anything that is not used directly from assembly code goes
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index a5272c0..de7450d 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -36,6 +36,7 @@ config KVM
 	select HAVE_KVM_EVENTFD
 	select HAVE_KVM_IRQFD
 	select KVM_ARM_VGIC_V3
+	select KVM_ARM_PMU if HW_PERF_EVENTS
 	---help---
 	  Support hosting virtualized guest machines.
 	  We don't support KVM with 16K page tables yet, due to the multiple
@@ -48,6 +49,12 @@ config KVM_ARM_HOST
 	---help---
 	  Provides host support for ARM processors.
 
+config KVM_ARM_PMU
+	bool
+	---help---
+	  Adds support for a virtual Performance Monitoring Unit (PMU) in
+	  virtual machines.
+
 source drivers/vhost/Kconfig
 
 endif # VIRTUALIZATION
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
new file mode 100644
index 0000000..3c2fd56
--- /dev/null
+++ b/include/kvm/arm_pmu.h
@@ -0,0 +1,42 @@
+/*
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Shannon Zhao <shannon.zhao at linaro.org>
+ *
+ * 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/>.
+ */
+
+#ifndef __ASM_ARM_KVM_PMU_H
+#define __ASM_ARM_KVM_PMU_H
+
+#ifdef CONFIG_KVM_ARM_PMU
+
+#include <linux/perf_event.h>
+#include <asm/perf_event.h>
+
+struct kvm_pmc {
+	u8 idx;	/* index into the pmu->pmc array */
+	struct perf_event *perf_event;
+	u64 bitmask;
+};
+
+struct kvm_pmu {
+	int irq_num;
+	struct kvm_pmc pmc[ARMV8_PMU_MAX_COUNTERS];
+	bool ready;
+};
+#else
+struct kvm_pmu {
+};
+#endif
+
+#endif
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:31 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:31 +0800
Subject: [PATCH v13 11/20] KVM: ARM64: Add access handler for PMOVSSET and
 PMOVSCLR register
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-12-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Since the reset value of PMOVSSET and PMOVSCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMOVSSET or PMOVSCLR register.

When writing non-zero value to PMOVSSET, the counter and its interrupt
is enabled, kick this vcpu to sync PMU interrupt.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/kvm_host.h |  1 +
 arch/arm64/kvm/sys_regs.c         | 29 ++++++++++++++++++++++++++---
 include/kvm/arm_pmu.h             |  2 ++
 virt/kvm/arm/pmu.c                | 31 +++++++++++++++++++++++++++++++
 4 files changed, 60 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index c7642de..05f4808 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -126,6 +126,7 @@ enum vcpu_sysreg {
 	PMCCFILTR_EL0,	/* Cycle Count Filter Register */
 	PMCNTENSET_EL0,	/* Count Enable Set Register */
 	PMINTENSET_EL1,	/* Interrupt Enable Set Register */
+	PMOVSSET_EL0,	/* Overflow Flag Status Set Register */
 
 	/* 32bit specific registers. Keep them at the end of the range */
 	DACR32_EL2,	/* Domain Access Control Register */
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index bfc70b2..6a774f9 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -650,6 +650,28 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			 const struct sys_reg_desc *r)
+{
+	u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write) {
+		if (r->CRm & 0x2)
+			/* accessing PMOVSSET_EL0 */
+			kvm_pmu_overflow_set(vcpu, p->regval & mask);
+		else
+			/* accessing PMOVSCLR_EL0 */
+			vcpu_sys_reg(vcpu, PMOVSSET_EL0) &= ~(p->regval & mask);
+	} else {
+		p->regval = vcpu_sys_reg(vcpu, PMOVSSET_EL0) & mask;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -857,7 +879,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmcnten, NULL, PMCNTENSET_EL0 },
 	/* PMOVSCLR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
-	  trap_raz_wi },
+	  access_pmovs, NULL, PMOVSSET_EL0 },
 	/* PMSWINC_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
 	  trap_raz_wi },
@@ -884,7 +906,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  trap_raz_wi },
 	/* PMOVSSET_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
-	  trap_raz_wi },
+	  access_pmovs, reset_unknown, PMOVSSET_EL0 },
 
 	/* TPIDR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b010),
@@ -1198,7 +1220,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
@@ -1208,6 +1230,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
+	{ Op1( 0), CRn( 9), CRm(14), Op2( 3), access_pmovs },
 
 	{ Op1( 0), CRn(10), CRm( 2), Op2( 0), access_vm_reg, NULL, c10_PRRR },
 	{ Op1( 0), CRn(10), CRm( 2), Op2( 1), access_vm_reg, NULL, c10_NMRR },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index c5737797..60061da 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -43,6 +43,7 @@ void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 #else
@@ -63,6 +64,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 }
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 591a11d..0232861 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -149,6 +149,37 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
 	}
 }
 
+static u64 kvm_pmu_overflow_status(struct kvm_vcpu *vcpu)
+{
+	u64 reg = 0;
+
+	if ((vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E))
+		reg = vcpu_sys_reg(vcpu, PMOVSSET_EL0);
+		reg &= vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
+		reg &= vcpu_sys_reg(vcpu, PMINTENSET_EL1);
+		reg &= kvm_pmu_valid_counter_mask(vcpu);
+
+	return reg;
+}
+
+/**
+ * kvm_pmu_overflow_set - set PMU overflow interrupt
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMOVSSET register
+ */
+void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
+{
+	u64 reg;
+
+	if (val == 0)
+		return;
+
+	vcpu_sys_reg(vcpu, PMOVSSET_EL0) |= val;
+	reg = kvm_pmu_overflow_status(vcpu);
+	if (reg != 0)
+		kvm_vcpu_kick(vcpu);
+}
+
 static bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu, u64 select_idx)
 {
 	return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E) &&
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:32 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:32 +0800
Subject: [PATCH v13 12/20] KVM: ARM64: Add access handler for PMSWINC register
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-13-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Add access handler which emulates writing and reading PMSWINC
register and add support for creating software increment event.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/kvm_host.h   |  1 +
 arch/arm64/include/asm/perf_event.h |  2 ++
 arch/arm64/kvm/sys_regs.c           | 20 +++++++++++++++++++-
 include/kvm/arm_pmu.h               |  2 ++
 virt/kvm/arm/pmu.c                  | 34 ++++++++++++++++++++++++++++++++++
 5 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 05f4808..de1f82d 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -127,6 +127,7 @@ enum vcpu_sysreg {
 	PMCNTENSET_EL0,	/* Count Enable Set Register */
 	PMINTENSET_EL1,	/* Interrupt Enable Set Register */
 	PMOVSSET_EL0,	/* Overflow Flag Status Set Register */
+	PMSWINC_EL0,	/* Software Increment Register */
 
 	/* 32bit specific registers. Keep them at the end of the range */
 	DACR32_EL2,	/* Domain Access Control Register */
diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
index 5c77ef8..ceb14a1 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -45,6 +45,8 @@
 #define	ARMV8_PMU_EVTYPE_MASK	0xc80003ff	/* Mask for writable bits */
 #define	ARMV8_PMU_EVTYPE_EVENT	0x3ff		/* Mask for EVENT bits */
 
+#define ARMV8_PMU_EVTYPE_EVENT_SW_INCR	0	/* Software increment event */
+
 /*
  * Event filters for PMUv3
  */
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 6a774f9..10e5379 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -672,6 +672,23 @@ static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			   const struct sys_reg_desc *r)
+{
+	u64 mask;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write) {
+		mask = kvm_pmu_valid_counter_mask(vcpu);
+		kvm_pmu_software_increment(vcpu, p->regval & mask);
+		return true;
+	}
+
+	return false;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -882,7 +899,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmovs, NULL, PMOVSSET_EL0 },
 	/* PMSWINC_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b100),
-	  trap_raz_wi },
+	  access_pmswinc, reset_unknown, PMSWINC_EL0 },
 	/* PMSELR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b101),
 	  access_pmselr, reset_unknown, PMSELR_EL0 },
@@ -1221,6 +1238,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), access_pmovs },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 4), access_pmswinc },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 60061da..348c4c9 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -44,6 +44,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 #else
@@ -65,6 +66,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 0232861..9fc775e 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -180,6 +180,36 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
 		kvm_vcpu_kick(vcpu);
 }
 
+/**
+ * kvm_pmu_software_increment - do software increment
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMSWINC register
+ */
+void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val)
+{
+	int i;
+	u64 type, enable, reg;
+
+	if (val == 0)
+		return;
+
+	enable = vcpu_sys_reg(vcpu, PMCNTENSET_EL0);
+	for (i = 0; i < ARMV8_PMU_CYCLE_IDX; i++) {
+		if (!(val & BIT(i)))
+			continue;
+		type = vcpu_sys_reg(vcpu, PMEVTYPER0_EL0 + i)
+		       & ARMV8_PMU_EVTYPE_EVENT;
+		if ((type == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
+		    && (enable & BIT(i))) {
+			reg = vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) + 1;
+			reg = lower_32_bits(reg);
+			vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i) = reg;
+			if (!reg)
+				kvm_pmu_overflow_set(vcpu, BIT(i));
+		}
+	}
+}
+
 static bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu, u64 select_idx)
 {
 	return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E) &&
@@ -208,6 +238,10 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 	kvm_pmu_stop_counter(vcpu, pmc);
 	eventsel = data & ARMV8_PMU_EVTYPE_EVENT;
 
+	/* Software increment event does't need to be backed by a perf event */
+	if (eventsel == ARMV8_PMU_EVTYPE_EVENT_SW_INCR)
+		return;
+
 	memset(&attr, 0, sizeof(struct perf_event_attr));
 	attr.type = PERF_TYPE_RAW;
 	attr.size = sizeof(attr);
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:25 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:25 +0800
Subject: [PATCH v13 05/20] KVM: ARM64: Add access handler for PMCEID0 and
 PMCEID1 register
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-6-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Add access handler which gets host value of PMCEID0 or PMCEID1 when
guest access these registers. Writing action to PMCEID0 or PMCEID1 is
UNDEFINED.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
---
 arch/arm64/kvm/sys_regs.c | 28 ++++++++++++++++++++++++----
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index b05e20f..ca8cdf6 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -493,6 +493,26 @@ static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			  const struct sys_reg_desc *r)
+{
+	u64 pmceid;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	BUG_ON(p->is_write);
+
+	if (!(p->Op2 & 1))
+		asm volatile("mrs %0, pmceid0_el0\n" : "=r" (pmceid));
+	else
+		asm volatile("mrs %0, pmceid1_el0\n" : "=r" (pmceid));
+
+	p->regval = pmceid;
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -695,10 +715,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmselr, reset_unknown, PMSELR_EL0 },
 	/* PMCEID0_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b110),
-	  trap_raz_wi },
+	  access_pmceid },
 	/* PMCEID1_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b111),
-	  trap_raz_wi },
+	  access_pmceid },
 	/* PMCCNTR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
 	  trap_raz_wi },
@@ -944,8 +964,8 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:39 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:39 +0800
Subject: [PATCH v13 19/20] KVM: ARM: Introduce per-vcpu kvm device controls
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-20-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

In some cases it needs to get/set attributes specific to a vcpu and so
needs something else than ONE_REG.

Let's copy the KVM_DEVICE approach, and define the respective ioctls
for the vcpu file descriptor.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
Acked-by: Peter Maydell <peter.maydell at linaro.org>
---
 Documentation/virtual/kvm/api.txt          | 10 +++---
 Documentation/virtual/kvm/devices/vcpu.txt |  8 +++++
 arch/arm/kvm/arm.c                         | 55 ++++++++++++++++++++++++++++++
 arch/arm64/kvm/reset.c                     |  1 +
 include/uapi/linux/kvm.h                   |  1 +
 5 files changed, 71 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/virtual/kvm/devices/vcpu.txt

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 9684f8d..cb2ef0b 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2507,8 +2507,9 @@ struct kvm_create_device {
 
 4.80 KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR
 
-Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device
-Type: device ioctl, vm ioctl
+Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device,
+  KVM_CAP_VCPU_ATTRIBUTES for vcpu device
+Type: device ioctl, vm ioctl, vcpu ioctl
 Parameters: struct kvm_device_attr
 Returns: 0 on success, -1 on error
 Errors:
@@ -2533,8 +2534,9 @@ struct kvm_device_attr {
 
 4.81 KVM_HAS_DEVICE_ATTR
 
-Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device
-Type: device ioctl, vm ioctl
+Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device,
+  KVM_CAP_VCPU_ATTRIBUTES for vcpu device
+Type: device ioctl, vm ioctl, vcpu ioctl
 Parameters: struct kvm_device_attr
 Returns: 0 on success, -1 on error
 Errors:
diff --git a/Documentation/virtual/kvm/devices/vcpu.txt b/Documentation/virtual/kvm/devices/vcpu.txt
new file mode 100644
index 0000000..3cc59c5
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/vcpu.txt
@@ -0,0 +1,8 @@
+Generic vcpu interface
+====================================
+
+The virtual cpu "device" also accepts the ioctls KVM_SET_DEVICE_ATTR,
+KVM_GET_DEVICE_ATTR, and KVM_HAS_DEVICE_ATTR. The interface uses the same struct
+kvm_device_attr as other devices, but targets VCPU-wide settings and controls.
+
+The groups and attributes per virtual cpu, if any, are architecture specific.
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index d2c2cc3..34d7395 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -826,11 +826,51 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu,
 	return 0;
 }
 
+static int kvm_arm_vcpu_set_attr(struct kvm_vcpu *vcpu,
+				 struct kvm_device_attr *attr)
+{
+	int ret = -ENXIO;
+
+	switch (attr->group) {
+	default:
+		break;
+	}
+
+	return ret;
+}
+
+static int kvm_arm_vcpu_get_attr(struct kvm_vcpu *vcpu,
+				 struct kvm_device_attr *attr)
+{
+	int ret = -ENXIO;
+
+	switch (attr->group) {
+	default:
+		break;
+	}
+
+	return ret;
+}
+
+static int kvm_arm_vcpu_has_attr(struct kvm_vcpu *vcpu,
+				 struct kvm_device_attr *attr)
+{
+	int ret = -ENXIO;
+
+	switch (attr->group) {
+	default:
+		break;
+	}
+
+	return ret;
+}
+
 long kvm_arch_vcpu_ioctl(struct file *filp,
 			 unsigned int ioctl, unsigned long arg)
 {
 	struct kvm_vcpu *vcpu = filp->private_data;
 	void __user *argp = (void __user *)arg;
+	struct kvm_device_attr attr;
 
 	switch (ioctl) {
 	case KVM_ARM_VCPU_INIT: {
@@ -873,6 +913,21 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
 			return -E2BIG;
 		return kvm_arm_copy_reg_indices(vcpu, user_list->reg);
 	}
+	case KVM_SET_DEVICE_ATTR: {
+		if (copy_from_user(&attr, argp, sizeof(attr)))
+			return -EFAULT;
+		return kvm_arm_vcpu_set_attr(vcpu, &attr);
+	}
+	case KVM_GET_DEVICE_ATTR: {
+		if (copy_from_user(&attr, argp, sizeof(attr)))
+			return -EFAULT;
+		return kvm_arm_vcpu_get_attr(vcpu, &attr);
+	}
+	case KVM_HAS_DEVICE_ATTR: {
+		if (copy_from_user(&attr, argp, sizeof(attr)))
+			return -EFAULT;
+		return kvm_arm_vcpu_has_attr(vcpu, &attr);
+	}
 	default:
 		return -EINVAL;
 	}
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index cf4f28a..9677bf0 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -81,6 +81,7 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
 		r = kvm_arm_support_pmu_v3();
 		break;
 	case KVM_CAP_SET_GUEST_DEBUG:
+	case KVM_CAP_VCPU_ATTRIBUTES:
 		r = 1;
 		break;
 	default:
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index dc16d30..50f44a2 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -851,6 +851,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_HYPERV_SYNIC 123
 #define KVM_CAP_S390_RI 124
 #define KVM_CAP_ARM_PMU_V3 125
+#define KVM_CAP_VCPU_ATTRIBUTES 126
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:28 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:28 +0800
Subject: [PATCH v13 08/20] KVM: ARM64: PMU: Add perf event map and introduce
 perf event creating function
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-9-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When we use tools like perf on host, perf passes the event type and the
id of this event type category to kernel, then kernel will map them to
hardware event number and write this number to PMU PMEVTYPER<n>_EL0
register. When getting the event number in KVM, directly use raw event
type to create a perf_event for it.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
---
 include/kvm/arm_pmu.h |  4 +++
 virt/kvm/arm/pmu.c    | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 78 insertions(+)

diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index b70058e..c5737797 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -43,6 +43,8 @@ void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
+				    u64 select_idx);
 #else
 struct kvm_pmu {
 };
@@ -61,6 +63,8 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 }
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
+						  u64 data, u64 select_idx) {}
 #endif
 
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index f8dc174..591a11d 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -62,6 +62,27 @@ void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val)
 	vcpu_sys_reg(vcpu, reg) += (s64)val - kvm_pmu_get_counter_value(vcpu, select_idx);
 }
 
+/**
+ * kvm_pmu_stop_counter - stop PMU counter
+ * @pmc: The PMU counter pointer
+ *
+ * If this counter has been configured to monitor some event, release it here.
+ */
+static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
+{
+	u64 counter, reg;
+
+	if (pmc->perf_event) {
+		counter = kvm_pmu_get_counter_value(vcpu, pmc->idx);
+		reg = (pmc->idx == ARMV8_PMU_CYCLE_IDX)
+		       ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + pmc->idx;
+		vcpu_sys_reg(vcpu, reg) = counter;
+		perf_event_disable(pmc->perf_event);
+		perf_event_release_kernel(pmc->perf_event);
+		pmc->perf_event = NULL;
+	}
+}
+
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 {
 	u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMU_PMCR_N_SHIFT;
@@ -127,3 +148,56 @@ void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
 			perf_event_disable(pmc->perf_event);
 	}
 }
+
+static bool kvm_pmu_counter_is_enabled(struct kvm_vcpu *vcpu, u64 select_idx)
+{
+	return (vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E) &&
+	       (vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & BIT(select_idx));
+}
+
+/**
+ * kvm_pmu_set_counter_event_type - set selected counter to monitor some event
+ * @vcpu: The vcpu pointer
+ * @data: The data guest writes to PMXEVTYPER_EL0
+ * @select_idx: The number of selected counter
+ *
+ * When OS accesses PMXEVTYPER_EL0, that means it wants to set a PMC to count an
+ * event with given hardware event number. Here we call perf_event API to
+ * emulate this action and create a kernel perf event for it.
+ */
+void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
+				    u64 select_idx)
+{
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_pmc *pmc = &pmu->pmc[select_idx];
+	struct perf_event *event;
+	struct perf_event_attr attr;
+	u64 eventsel, counter;
+
+	kvm_pmu_stop_counter(vcpu, pmc);
+	eventsel = data & ARMV8_PMU_EVTYPE_EVENT;
+
+	memset(&attr, 0, sizeof(struct perf_event_attr));
+	attr.type = PERF_TYPE_RAW;
+	attr.size = sizeof(attr);
+	attr.pinned = 1;
+	attr.disabled = !kvm_pmu_counter_is_enabled(vcpu, select_idx);
+	attr.exclude_user = data & ARMV8_PMU_EXCLUDE_EL0 ? 1 : 0;
+	attr.exclude_kernel = data & ARMV8_PMU_EXCLUDE_EL1 ? 1 : 0;
+	attr.exclude_hv = 1; /* Don't count EL2 events */
+	attr.exclude_host = 1; /* Don't count host events */
+	attr.config = eventsel;
+
+	counter = kvm_pmu_get_counter_value(vcpu, select_idx);
+	/* The initial sample period (overflow count) of an event. */
+	attr.sample_period = (-counter) & pmc->bitmask;
+
+	event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
+	if (IS_ERR(event)) {
+		pr_err_once("kvm: pmu event creation failed %ld\n",
+			    PTR_ERR(event));
+		return;
+	}
+
+	pmc->perf_event = event;
+}
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:27 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:27 +0800
Subject: [PATCH v13 07/20] KVM: ARM64: Add access handler for PMCNTENSET and
 PMCNTENCLR register
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-8-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Since the reset value of PMCNTENSET and PMCNTENCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMCNTENSET or PMCNTENCLR register.

When writing to PMCNTENSET, call perf_event_enable to enable the perf
event. When writing to PMCNTENCLR, call perf_event_disable to disable
the perf event.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
---
 arch/arm64/include/asm/kvm_host.h |  1 +
 arch/arm64/kvm/sys_regs.c         | 35 ++++++++++++++++++---
 include/kvm/arm_pmu.h             |  9 ++++++
 virt/kvm/arm/pmu.c                | 66 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 107 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 627f01e..e6910db 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -121,6 +121,7 @@ enum vcpu_sysreg {
 	PMEVCNTR0_EL0,	/* Event Counter Register (0-30) */
 	PMEVCNTR30_EL0 = PMEVCNTR0_EL0 + 30,
 	PMCCNTR_EL0,	/* Cycle Counter Register */
+	PMCNTENSET_EL0,	/* Count Enable Set Register */
 
 	/* 32bit specific registers. Keep them at the end of the range */
 	DACR32_EL2,	/* Domain Access Control Register */
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index ff3214b..d4b6ae3 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -563,6 +563,33 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
 	return true;
 }
 
+static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			   const struct sys_reg_desc *r)
+{
+	u64 val, mask;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	mask = kvm_pmu_valid_counter_mask(vcpu);
+	if (p->is_write) {
+		val = p->regval & mask;
+		if (r->Op2 & 0x1) {
+			/* accessing PMCNTENSET_EL0 */
+			vcpu_sys_reg(vcpu, PMCNTENSET_EL0) |= val;
+			kvm_pmu_enable_counter(vcpu, val);
+		} else {
+			/* accessing PMCNTENCLR_EL0 */
+			vcpu_sys_reg(vcpu, PMCNTENSET_EL0) &= ~val;
+			kvm_pmu_disable_counter(vcpu, val);
+		}
+	} else {
+		p->regval = vcpu_sys_reg(vcpu, PMCNTENSET_EL0) & mask;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -757,10 +784,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmcr, reset_pmcr, },
 	/* PMCNTENSET_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
-	  trap_raz_wi },
+	  access_pmcnten, reset_unknown, PMCNTENSET_EL0 },
 	/* PMCNTENCLR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b010),
-	  trap_raz_wi },
+	  access_pmcnten, NULL, PMCNTENSET_EL0 },
 	/* PMOVSCLR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b011),
 	  trap_raz_wi },
@@ -1057,8 +1084,8 @@ static const struct sys_reg_desc cp15_regs[] = {
 
 	/* PMU */
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), access_pmcnten },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), access_pmcnten },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index bcb7698..b70058e 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -40,6 +40,9 @@ struct kvm_pmu {
 #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
 u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
 void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
+u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
+void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 #else
 struct kvm_pmu {
 };
@@ -52,6 +55,12 @@ static inline u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu,
 }
 static inline void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu,
 					     u64 select_idx, u64 val) {}
+static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
+{
+	return 0;
+}
+static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 #endif
 
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index cd74e63..f8dc174 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -61,3 +61,69 @@ void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val)
 	      ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + select_idx;
 	vcpu_sys_reg(vcpu, reg) += (s64)val - kvm_pmu_get_counter_value(vcpu, select_idx);
 }
+
+u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
+{
+	u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMU_PMCR_N_SHIFT;
+
+	val &= ARMV8_PMU_PMCR_N_MASK;
+	if (val == 0)
+		return BIT(ARMV8_PMU_CYCLE_IDX);
+	else
+		return GENMASK(val - 1, 0) | BIT(ARMV8_PMU_CYCLE_IDX);
+}
+
+/**
+ * kvm_pmu_enable_counter - enable selected PMU counter
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCNTENSET register
+ *
+ * Call perf_event_enable to start counting the perf event
+ */
+void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val)
+{
+	int i;
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_pmc *pmc;
+
+	if (!(vcpu_sys_reg(vcpu, PMCR_EL0) & ARMV8_PMU_PMCR_E) || !val)
+		return;
+
+	for (i = 0; i < ARMV8_PMU_MAX_COUNTERS; i++) {
+		if (!(val & BIT(i)))
+			continue;
+
+		pmc = &pmu->pmc[i];
+		if (pmc->perf_event) {
+			perf_event_enable(pmc->perf_event);
+			if (pmc->perf_event->state != PERF_EVENT_STATE_ACTIVE)
+				kvm_debug("fail to enable perf event\n");
+		}
+	}
+}
+
+/**
+ * kvm_pmu_disable_counter - disable selected PMU counter
+ * @vcpu: The vcpu pointer
+ * @val: the value guest writes to PMCNTENCLR register
+ *
+ * Call perf_event_disable to stop counting the perf event
+ */
+void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val)
+{
+	int i;
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_pmc *pmc;
+
+	if (!val)
+		return;
+
+	for (i = 0; i < ARMV8_PMU_MAX_COUNTERS; i++) {
+		if (!(val & BIT(i)))
+			continue;
+
+		pmc = &pmu->pmc[i];
+		if (pmc->perf_event)
+			perf_event_disable(pmc->perf_event);
+	}
+}
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:21 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:21 +0800
Subject: [PATCH v13 01/20] ARM64: Move PMU register related defines to
 asm/perf_event.h
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-2-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

To use the ARMv8 PMU related register defines from the KVM code, we move
the relevant definitions to asm/perf_event.h header file and rename them
with prefix ARMV8_PMU_.

Signed-off-by: Anup Patel <anup.patel at linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/perf_event.h | 35 +++++++++++++++++++
 arch/arm64/kernel/perf_event.c      | 68 ++++++++++---------------------------
 2 files changed, 52 insertions(+), 51 deletions(-)

diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
index 7bd3cdb..5c77ef8 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -17,6 +17,41 @@
 #ifndef __ASM_PERF_EVENT_H
 #define __ASM_PERF_EVENT_H
 
+#define	ARMV8_PMU_MAX_COUNTERS	32
+#define	ARMV8_PMU_COUNTER_MASK	(ARMV8_PMU_MAX_COUNTERS - 1)
+
+/*
+ * Per-CPU PMCR: config reg
+ */
+#define ARMV8_PMU_PMCR_E	(1 << 0) /* Enable all counters */
+#define ARMV8_PMU_PMCR_P	(1 << 1) /* Reset all counters */
+#define ARMV8_PMU_PMCR_C	(1 << 2) /* Cycle counter reset */
+#define ARMV8_PMU_PMCR_D	(1 << 3) /* CCNT counts every 64th cpu cycle */
+#define ARMV8_PMU_PMCR_X	(1 << 4) /* Export to ETM */
+#define ARMV8_PMU_PMCR_DP	(1 << 5) /* Disable CCNT if non-invasive debug*/
+#define	ARMV8_PMU_PMCR_N_SHIFT	11	 /* Number of counters supported */
+#define	ARMV8_PMU_PMCR_N_MASK	0x1f
+#define	ARMV8_PMU_PMCR_MASK	0x3f	 /* Mask for writable bits */
+
+/*
+ * PMOVSR: counters overflow flag status reg
+ */
+#define	ARMV8_PMU_OVSR_MASK		0xffffffff	/* Mask for writable bits */
+#define	ARMV8_PMU_OVERFLOWED_MASK	ARMV8_PMU_OVSR_MASK
+
+/*
+ * PMXEVTYPER: Event selection reg
+ */
+#define	ARMV8_PMU_EVTYPE_MASK	0xc80003ff	/* Mask for writable bits */
+#define	ARMV8_PMU_EVTYPE_EVENT	0x3ff		/* Mask for EVENT bits */
+
+/*
+ * Event filters for PMUv3
+ */
+#define	ARMV8_PMU_EXCLUDE_EL1	(1 << 31)
+#define	ARMV8_PMU_EXCLUDE_EL0	(1 << 30)
+#define	ARMV8_PMU_INCLUDE_EL2	(1 << 27)
+
 #ifdef CONFIG_PERF_EVENTS
 struct pt_regs;
 extern unsigned long perf_instruction_pointer(struct pt_regs *regs);
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index f7ab14c..212c9fc4 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -24,6 +24,7 @@
 #include <linux/of.h>
 #include <linux/perf/arm_pmu.h>
 #include <linux/platform_device.h>
+#include <asm/perf_event.h>
 
 /*
  * ARMv8 PMUv3 Performance Events handling code.
@@ -333,9 +334,6 @@ static const struct attribute_group *armv8_pmuv3_attr_groups[] = {
 #define	ARMV8_IDX_COUNTER_LAST(cpu_pmu) \
 	(ARMV8_IDX_CYCLE_COUNTER + cpu_pmu->num_events - 1)
 
-#define	ARMV8_MAX_COUNTERS	32
-#define	ARMV8_COUNTER_MASK	(ARMV8_MAX_COUNTERS - 1)
-
 /*
  * ARMv8 low level PMU access
  */
@@ -344,39 +342,7 @@ static const struct attribute_group *armv8_pmuv3_attr_groups[] = {
  * Perf Event to low level counters mapping
  */
 #define	ARMV8_IDX_TO_COUNTER(x)	\
-	(((x) - ARMV8_IDX_COUNTER0) & ARMV8_COUNTER_MASK)
-
-/*
- * Per-CPU PMCR: config reg
- */
-#define ARMV8_PMCR_E		(1 << 0) /* Enable all counters */
-#define ARMV8_PMCR_P		(1 << 1) /* Reset all counters */
-#define ARMV8_PMCR_C		(1 << 2) /* Cycle counter reset */
-#define ARMV8_PMCR_D		(1 << 3) /* CCNT counts every 64th cpu cycle */
-#define ARMV8_PMCR_X		(1 << 4) /* Export to ETM */
-#define ARMV8_PMCR_DP		(1 << 5) /* Disable CCNT if non-invasive debug*/
-#define	ARMV8_PMCR_N_SHIFT	11	 /* Number of counters supported */
-#define	ARMV8_PMCR_N_MASK	0x1f
-#define	ARMV8_PMCR_MASK		0x3f	 /* Mask for writable bits */
-
-/*
- * PMOVSR: counters overflow flag status reg
- */
-#define	ARMV8_OVSR_MASK		0xffffffff	/* Mask for writable bits */
-#define	ARMV8_OVERFLOWED_MASK	ARMV8_OVSR_MASK
-
-/*
- * PMXEVTYPER: Event selection reg
- */
-#define	ARMV8_EVTYPE_MASK	0xc80003ff	/* Mask for writable bits */
-#define	ARMV8_EVTYPE_EVENT	0x3ff		/* Mask for EVENT bits */
-
-/*
- * Event filters for PMUv3
- */
-#define	ARMV8_EXCLUDE_EL1	(1 << 31)
-#define	ARMV8_EXCLUDE_EL0	(1 << 30)
-#define	ARMV8_INCLUDE_EL2	(1 << 27)
+	(((x) - ARMV8_IDX_COUNTER0) & ARMV8_PMU_COUNTER_MASK)
 
 static inline u32 armv8pmu_pmcr_read(void)
 {
@@ -387,14 +353,14 @@ static inline u32 armv8pmu_pmcr_read(void)
 
 static inline void armv8pmu_pmcr_write(u32 val)
 {
-	val &= ARMV8_PMCR_MASK;
+	val &= ARMV8_PMU_PMCR_MASK;
 	isb();
 	asm volatile("msr pmcr_el0, %0" :: "r" (val));
 }
 
 static inline int armv8pmu_has_overflowed(u32 pmovsr)
 {
-	return pmovsr & ARMV8_OVERFLOWED_MASK;
+	return pmovsr & ARMV8_PMU_OVERFLOWED_MASK;
 }
 
 static inline int armv8pmu_counter_valid(struct arm_pmu *cpu_pmu, int idx)
@@ -453,7 +419,7 @@ static inline void armv8pmu_write_counter(struct perf_event *event, u32 value)
 static inline void armv8pmu_write_evtype(int idx, u32 val)
 {
 	if (armv8pmu_select_counter(idx) == idx) {
-		val &= ARMV8_EVTYPE_MASK;
+		val &= ARMV8_PMU_EVTYPE_MASK;
 		asm volatile("msr pmxevtyper_el0, %0" :: "r" (val));
 	}
 }
@@ -499,7 +465,7 @@ static inline u32 armv8pmu_getreset_flags(void)
 	asm volatile("mrs %0, pmovsclr_el0" : "=r" (value));
 
 	/* Write to clear flags */
-	value &= ARMV8_OVSR_MASK;
+	value &= ARMV8_PMU_OVSR_MASK;
 	asm volatile("msr pmovsclr_el0, %0" :: "r" (value));
 
 	return value;
@@ -637,7 +603,7 @@ static void armv8pmu_start(struct arm_pmu *cpu_pmu)
 
 	raw_spin_lock_irqsave(&events->pmu_lock, flags);
 	/* Enable all counters */
-	armv8pmu_pmcr_write(armv8pmu_pmcr_read() | ARMV8_PMCR_E);
+	armv8pmu_pmcr_write(armv8pmu_pmcr_read() | ARMV8_PMU_PMCR_E);
 	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
 }
 
@@ -648,7 +614,7 @@ static void armv8pmu_stop(struct arm_pmu *cpu_pmu)
 
 	raw_spin_lock_irqsave(&events->pmu_lock, flags);
 	/* Disable all counters */
-	armv8pmu_pmcr_write(armv8pmu_pmcr_read() & ~ARMV8_PMCR_E);
+	armv8pmu_pmcr_write(armv8pmu_pmcr_read() & ~ARMV8_PMU_PMCR_E);
 	raw_spin_unlock_irqrestore(&events->pmu_lock, flags);
 }
 
@@ -658,7 +624,7 @@ static int armv8pmu_get_event_idx(struct pmu_hw_events *cpuc,
 	int idx;
 	struct arm_pmu *cpu_pmu = to_arm_pmu(event->pmu);
 	struct hw_perf_event *hwc = &event->hw;
-	unsigned long evtype = hwc->config_base & ARMV8_EVTYPE_EVENT;
+	unsigned long evtype = hwc->config_base & ARMV8_PMU_EVTYPE_EVENT;
 
 	/* Always place a cycle counter into the cycle counter. */
 	if (evtype == ARMV8_PMUV3_PERFCTR_CLOCK_CYCLES) {
@@ -692,11 +658,11 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
 	if (attr->exclude_idle)
 		return -EPERM;
 	if (attr->exclude_user)
-		config_base |= ARMV8_EXCLUDE_EL0;
+		config_base |= ARMV8_PMU_EXCLUDE_EL0;
 	if (attr->exclude_kernel)
-		config_base |= ARMV8_EXCLUDE_EL1;
+		config_base |= ARMV8_PMU_EXCLUDE_EL1;
 	if (!attr->exclude_hv)
-		config_base |= ARMV8_INCLUDE_EL2;
+		config_base |= ARMV8_PMU_INCLUDE_EL2;
 
 	/*
 	 * Install the filter into config_base as this is used to
@@ -719,28 +685,28 @@ static void armv8pmu_reset(void *info)
 	}
 
 	/* Initialize & Reset PMNC: C and P bits. */
-	armv8pmu_pmcr_write(ARMV8_PMCR_P | ARMV8_PMCR_C);
+	armv8pmu_pmcr_write(ARMV8_PMU_PMCR_P | ARMV8_PMU_PMCR_C);
 }
 
 static int armv8_pmuv3_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv8_pmuv3_perf_map,
 				&armv8_pmuv3_perf_cache_map,
-				ARMV8_EVTYPE_EVENT);
+				ARMV8_PMU_EVTYPE_EVENT);
 }
 
 static int armv8_a53_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv8_a53_perf_map,
 				&armv8_a53_perf_cache_map,
-				ARMV8_EVTYPE_EVENT);
+				ARMV8_PMU_EVTYPE_EVENT);
 }
 
 static int armv8_a57_map_event(struct perf_event *event)
 {
 	return armpmu_map_event(event, &armv8_a57_perf_map,
 				&armv8_a57_perf_cache_map,
-				ARMV8_EVTYPE_EVENT);
+				ARMV8_PMU_EVTYPE_EVENT);
 }
 
 static void armv8pmu_read_num_pmnc_events(void *info)
@@ -748,7 +714,7 @@ static void armv8pmu_read_num_pmnc_events(void *info)
 	int *nb_cnt = info;
 
 	/* Read the nb of CNTx counters supported from PMNC */
-	*nb_cnt = (armv8pmu_pmcr_read() >> ARMV8_PMCR_N_SHIFT) & ARMV8_PMCR_N_MASK;
+	*nb_cnt = (armv8pmu_pmcr_read() >> ARMV8_PMU_PMCR_N_SHIFT) & ARMV8_PMU_PMCR_N_MASK;
 
 	/* Add the CPU cycles counter */
 	*nb_cnt += 1;
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:30 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:30 +0800
Subject: [PATCH v13 10/20] KVM: ARM64: Add access handler for PMINTENSET and
 PMINTENCLR register
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-11-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Since the reset value of PMINTENSET and PMINTENCLR is UNKNOWN, use
reset_unknown for its reset handler. Add a handler to emulate writing
PMINTENSET or PMINTENCLR register.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/kvm_host.h |  1 +
 arch/arm64/kvm/sys_regs.c         | 32 ++++++++++++++++++++++++++++----
 2 files changed, 29 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index bf97e79..c7642de 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -125,6 +125,7 @@ enum vcpu_sysreg {
 	PMEVTYPER30_EL0 = PMEVTYPER0_EL0 + 30,
 	PMCCFILTR_EL0,	/* Cycle Count Filter Register */
 	PMCNTENSET_EL0,	/* Count Enable Set Register */
+	PMINTENSET_EL1,	/* Interrupt Enable Set Register */
 
 	/* 32bit specific registers. Keep them at the end of the range */
 	DACR32_EL2,	/* Domain Access Control Register */
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 4faf324..bfc70b2 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -626,6 +626,30 @@ static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			   const struct sys_reg_desc *r)
+{
+	u64 mask = kvm_pmu_valid_counter_mask(vcpu);
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write) {
+		u64 val = p->regval & mask;
+
+		if (r->Op2 & 0x1)
+			/* accessing PMINTENSET_EL1 */
+			vcpu_sys_reg(vcpu, PMINTENSET_EL1) |= val;
+		else
+			/* accessing PMINTENCLR_EL1 */
+			vcpu_sys_reg(vcpu, PMINTENSET_EL1) &= ~val;
+	} else {
+		p->regval = vcpu_sys_reg(vcpu, PMINTENSET_EL1) & mask;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -784,10 +808,10 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 
 	/* PMINTENSET_EL1 */
 	{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b001),
-	  trap_raz_wi },
+	  access_pminten, reset_unknown, PMINTENSET_EL1 },
 	/* PMINTENCLR_EL1 */
 	{ Op0(0b11), Op1(0b000), CRn(0b1001), CRm(0b1110), Op2(0b010),
-	  trap_raz_wi },
+	  access_pminten, NULL, PMINTENSET_EL1 },
 
 	/* MAIR_EL1 */
 	{ Op0(0b11), Op1(0b000), CRn(0b1010), CRm(0b0010), Op2(0b000),
@@ -1182,8 +1206,8 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
+	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
 
 	{ Op1( 0), CRn(10), CRm( 2), Op2( 0), access_vm_reg, NULL, c10_PRRR },
 	{ Op1( 0), CRn(10), CRm( 2), Op2( 1), access_vm_reg, NULL, c10_NMRR },
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:23 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:23 +0800
Subject: [PATCH v13 03/20] KVM: ARM64: Add access handler for PMCR register
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-4-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

Add reset handler which gets host value of PMCR_EL0 and make writable
bits architecturally UNKNOWN except PMCR.E which is zero. Add an access
handler for PMCR.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/kvm_host.h |  3 +++
 arch/arm64/kvm/sys_regs.c         | 42 +++++++++++++++++++++++++++++++++++++--
 include/kvm/arm_pmu.h             |  4 ++++
 3 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 6f0241f..1f3ca98 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -115,6 +115,9 @@ enum vcpu_sysreg {
 	MDSCR_EL1,	/* Monitor Debug System Control Register */
 	MDCCINT_EL1,	/* Monitor Debug Comms Channel Interrupt Enable Reg */
 
+	/* Performance Monitors Registers */
+	PMCR_EL0,	/* Control Register */
+
 	/* 32bit specific registers. Keep them at the end of the range */
 	DACR32_EL2,	/* Domain Access Control Register */
 	IFSR32_EL2,	/* Instruction Fault Status Register */
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 2e90371..e88ae2d 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -34,6 +34,7 @@
 #include <asm/kvm_emulate.h>
 #include <asm/kvm_host.h>
 #include <asm/kvm_mmu.h>
+#include <asm/perf_event.h>
 
 #include <trace/events/kvm.h>
 
@@ -439,6 +440,43 @@ static void reset_mpidr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
 	vcpu_sys_reg(vcpu, MPIDR_EL1) = (1ULL << 31) | mpidr;
 }
 
+static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
+{
+	u64 pmcr, val;
+
+	asm volatile("mrs %0, pmcr_el0\n" : "=r" (pmcr));
+	/* Writable bits of PMCR_EL0 (ARMV8_PMU_PMCR_MASK) is reset to UNKNOWN
+	 * except PMCR.E resetting to zero.
+	 */
+	val = ((pmcr & ~ARMV8_PMU_PMCR_MASK)
+	       | (ARMV8_PMU_PMCR_MASK & 0xdecafbad)) & (~ARMV8_PMU_PMCR_E);
+	vcpu_sys_reg(vcpu, PMCR_EL0) = val;
+}
+
+static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			const struct sys_reg_desc *r)
+{
+	u64 val;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write) {
+		/* Only update writeable bits of PMCR */
+		val = vcpu_sys_reg(vcpu, PMCR_EL0);
+		val &= ~ARMV8_PMU_PMCR_MASK;
+		val |= p->regval & ARMV8_PMU_PMCR_MASK;
+		vcpu_sys_reg(vcpu, PMCR_EL0) = val;
+	} else {
+		/* PMCR.P & PMCR.C are RAZ */
+		val = vcpu_sys_reg(vcpu, PMCR_EL0)
+		      & ~(ARMV8_PMU_PMCR_P | ARMV8_PMU_PMCR_C);
+		p->regval = val;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -623,7 +661,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 
 	/* PMCR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b000),
-	  trap_raz_wi },
+	  access_pmcr, reset_pmcr, },
 	/* PMCNTENSET_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1100), Op2(0b001),
 	  trap_raz_wi },
@@ -885,7 +923,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 7), CRm(14), Op2( 2), access_dcsw },
 
 	/* PMU */
-	{ Op1( 0), CRn( 9), CRm(12), Op2( 0), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(12), Op2( 0), access_pmcr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 1), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 2), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 3), trap_raz_wi },
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 3c2fd56..8157fe5 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -34,9 +34,13 @@ struct kvm_pmu {
 	struct kvm_pmc pmc[ARMV8_PMU_MAX_COUNTERS];
 	bool ready;
 };
+
+#define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
 #else
 struct kvm_pmu {
 };
+
+#define kvm_arm_pmu_v3_ready(v)		(false)
 #endif
 
 #endif
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:38 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:38 +0800
Subject: [PATCH v13 18/20] KVM: ARM64: Add a new feature bit for PMUv3
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-19-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

To support guest PMUv3, use one bit of the VCPU INIT feature array.
Initialize the PMU when initialzing the vcpu with that bit and PMU
overflow interrupt set.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Peter Maydell <peter.maydell at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 Documentation/virtual/kvm/api.txt |  2 ++
 arch/arm64/include/asm/kvm_host.h |  2 +-
 arch/arm64/include/uapi/asm/kvm.h |  1 +
 arch/arm64/kvm/reset.c            |  3 +++
 include/kvm/arm_pmu.h             |  2 ++
 include/uapi/linux/kvm.h          |  1 +
 virt/kvm/arm/pmu.c                | 10 ++++++++++
 7 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 07e4cdf..9684f8d 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2577,6 +2577,8 @@ Possible features:
 	  Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
 	- KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 for the CPU.
 	  Depends on KVM_CAP_ARM_PSCI_0_2.
+	- KVM_ARM_VCPU_PMU_V3: Emulate PMUv3 for the CPU.
+	  Depends on KVM_CAP_ARM_PMU_V3.
 
 
 4.83 KVM_ARM_PREFERRED_TARGET
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 7b61675..cd177e9 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -40,7 +40,7 @@
 
 #define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
 
-#define KVM_VCPU_MAX_FEATURES 3
+#define KVM_VCPU_MAX_FEATURES 4
 
 int __attribute_const__ kvm_target_cpu(void);
 int kvm_reset_vcpu(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 2d4ca4b..6aedbe3 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -94,6 +94,7 @@ struct kvm_regs {
 #define KVM_ARM_VCPU_POWER_OFF		0 /* CPU is started in OFF state */
 #define KVM_ARM_VCPU_EL1_32BIT		1 /* CPU running a 32bit VM */
 #define KVM_ARM_VCPU_PSCI_0_2		2 /* CPU uses PSCI v0.2 */
+#define KVM_ARM_VCPU_PMU_V3		3 /* Support guest PMUv3 */
 
 struct kvm_vcpu_init {
 	__u32 target;
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index dfbce78..cf4f28a 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
 	case KVM_CAP_GUEST_DEBUG_HW_WPS:
 		r = get_num_wrps();
 		break;
+	case KVM_CAP_ARM_PMU_V3:
+		r = kvm_arm_support_pmu_v3();
+		break;
 	case KVM_CAP_SET_GUEST_DEBUG:
 		r = 1;
 		break;
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index fd396d6..1d12e55 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -52,6 +52,7 @@ void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
+bool kvm_arm_support_pmu_v3(void);
 #else
 struct kvm_pmu {
 };
@@ -78,6 +79,7 @@ static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
+static inline bool kvm_arm_support_pmu_v3(void) { return false; }
 #endif
 
 #endif
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 9da9051..dc16d30 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -850,6 +850,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_IOEVENTFD_ANY_LENGTH 122
 #define KVM_CAP_HYPERV_SYNIC 123
 #define KVM_CAP_S390_RI 124
+#define KVM_CAP_ARM_PMU_V3 125
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index cb946fd..d226360 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -387,3 +387,13 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 
 	pmc->perf_event = event;
 }
+
+bool kvm_arm_support_pmu_v3(void)
+{
+	/*
+	 * Check if HW_PERF_EVENTS are supported by checking the number of
+	 * hardware performance counters. This could ensure the presence of
+	 * a physical PMU and CONFIG_PERF_EVENT is selected.
+	 */
+	return (perf_num_counters() > 0);
+}
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:40 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:40 +0800
Subject: [PATCH v13 20/20] KVM: ARM64: Add a new vcpu device control group for
 PMUv3
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-21-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

To configure the virtual PMUv3 overflow interrupt number, we use the
vcpu kvm_device ioctl, encapsulating the KVM_ARM_VCPU_PMU_V3_IRQ
attribute within the KVM_ARM_VCPU_PMU_V3_CTRL group.

After configuring the PMUv3, call the vcpu ioctl with attribute
KVM_ARM_VCPU_PMU_V3_INIT to initialize the PMUv3.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Acked-by: Peter Maydell <peter.maydell at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
---
 Documentation/virtual/kvm/devices/vcpu.txt |  25 +++++++
 arch/arm/include/asm/kvm_host.h            |  15 ++++
 arch/arm/kvm/arm.c                         |   3 +
 arch/arm64/include/asm/kvm_host.h          |   6 ++
 arch/arm64/include/uapi/asm/kvm.h          |   5 ++
 arch/arm64/kvm/guest.c                     |  51 +++++++++++++
 include/kvm/arm_pmu.h                      |  23 ++++++
 virt/kvm/arm/pmu.c                         | 112 +++++++++++++++++++++++++++++
 8 files changed, 240 insertions(+)

diff --git a/Documentation/virtual/kvm/devices/vcpu.txt b/Documentation/virtual/kvm/devices/vcpu.txt
index 3cc59c5..c041658 100644
--- a/Documentation/virtual/kvm/devices/vcpu.txt
+++ b/Documentation/virtual/kvm/devices/vcpu.txt
@@ -6,3 +6,28 @@ KVM_GET_DEVICE_ATTR, and KVM_HAS_DEVICE_ATTR. The interface uses the same struct
 kvm_device_attr as other devices, but targets VCPU-wide settings and controls.
 
 The groups and attributes per virtual cpu, if any, are architecture specific.
+
+1. GROUP: KVM_ARM_VCPU_PMU_V3_CTRL
+Architectures: ARM64
+
+1.1. ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_IRQ
+Parameters: in kvm_device_attr.addr the address for PMU overflow interrupt is a
+            pointer to an int
+Returns: -EBUSY: The PMU overflow interrupt is already set
+         -ENXIO: The overflow interrupt not set when attempting to get it
+         -ENODEV: PMUv3 not supported
+         -EINVAL: Invalid PMU overflow interrupt number supplied
+
+A value describing the PMUv3 (Performance Monitor Unit v3) overflow interrupt
+number for this vcpu. This interrupt could be a PPI or SPI, but the interrupt
+type must be same for each vcpu. As a PPI, the interrupt number is the same for
+all vcpus, while as an SPI it must be a separate number per vcpu.
+
+1.2 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_INIT
+Parameters: no additional parameter in kvm_device_attr.addr
+Returns: -ENODEV: PMUv3 not supported
+         -ENXIO: PMUv3 not properly configured as required prior to calling this
+                 attribute
+         -EBUSY: PMUv3 already initialized
+
+Request the initialization of the PMUv3.
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index f9f2779..6dd0992 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -242,5 +242,20 @@ static inline void kvm_arm_init_debug(void) {}
 static inline void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) {}
 static inline void kvm_arm_clear_debug(struct kvm_vcpu *vcpu) {}
 static inline void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu) {}
+static inline int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
+					     struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
+static inline int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
+					     struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
+static inline int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
+					     struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
 
 #endif /* __ARM_KVM_HOST_H__ */
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 34d7395..dc8644f 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -833,6 +833,7 @@ static int kvm_arm_vcpu_set_attr(struct kvm_vcpu *vcpu,
 
 	switch (attr->group) {
 	default:
+		ret = kvm_arm_vcpu_arch_set_attr(vcpu, attr);
 		break;
 	}
 
@@ -846,6 +847,7 @@ static int kvm_arm_vcpu_get_attr(struct kvm_vcpu *vcpu,
 
 	switch (attr->group) {
 	default:
+		ret = kvm_arm_vcpu_arch_get_attr(vcpu, attr);
 		break;
 	}
 
@@ -859,6 +861,7 @@ static int kvm_arm_vcpu_has_attr(struct kvm_vcpu *vcpu,
 
 	switch (attr->group) {
 	default:
+		ret = kvm_arm_vcpu_arch_has_attr(vcpu, attr);
 		break;
 	}
 
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index cd177e9..48e1a12 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -359,5 +359,11 @@ void kvm_arm_init_debug(void);
 void kvm_arm_setup_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_clear_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu);
+int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr);
+int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr);
+int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr);
 
 #endif /* __ARM64_KVM_HOST_H__ */
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 6aedbe3..f209ea1 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -205,6 +205,11 @@ struct kvm_arch_memory_slot {
 #define KVM_DEV_ARM_VGIC_GRP_CTRL	4
 #define   KVM_DEV_ARM_VGIC_CTRL_INIT	0
 
+/* Device Control API on vcpu fd */
+#define KVM_ARM_VCPU_PMU_V3_CTRL	0
+#define   KVM_ARM_VCPU_PMU_V3_IRQ	0
+#define   KVM_ARM_VCPU_PMU_V3_INIT	1
+
 /* KVM_IRQ_LINE irq field index values */
 #define KVM_ARM_IRQ_TYPE_SHIFT		24
 #define KVM_ARM_IRQ_TYPE_MASK		0xff
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index fcb7788..dbe45c3 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -380,3 +380,54 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
 	}
 	return 0;
 }
+
+int kvm_arm_vcpu_arch_set_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr)
+{
+	int ret;
+
+	switch (attr->group) {
+	case KVM_ARM_VCPU_PMU_V3_CTRL:
+		ret = kvm_arm_pmu_v3_set_attr(vcpu, attr);
+		break;
+	default:
+		ret = -ENXIO;
+		break;
+	}
+
+	return ret;
+}
+
+int kvm_arm_vcpu_arch_get_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr)
+{
+	int ret;
+
+	switch (attr->group) {
+	case KVM_ARM_VCPU_PMU_V3_CTRL:
+		ret = kvm_arm_pmu_v3_get_attr(vcpu, attr);
+		break;
+	default:
+		ret = -ENXIO;
+		break;
+	}
+
+	return ret;
+}
+
+int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
+			       struct kvm_device_attr *attr)
+{
+	int ret;
+
+	switch (attr->group) {
+	case KVM_ARM_VCPU_PMU_V3_CTRL:
+		ret = kvm_arm_pmu_v3_has_attr(vcpu, attr);
+		break;
+	default:
+		ret = -ENXIO;
+		break;
+	}
+
+	return ret;
+}
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 1d12e55..b23e636 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -39,6 +39,7 @@ struct kvm_pmu {
 };
 
 #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
+#define kvm_arm_pmu_irq_initialized(v)	((v)->arch.pmu.irq_num >= VGIC_NR_SGIS)
 u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
 void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
@@ -53,11 +54,18 @@ void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 				    u64 select_idx);
 bool kvm_arm_support_pmu_v3(void);
+int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu,
+			    struct kvm_device_attr *attr);
+int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu,
+			    struct kvm_device_attr *attr);
+int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu,
+			    struct kvm_device_attr *attr);
 #else
 struct kvm_pmu {
 };
 
 #define kvm_arm_pmu_v3_ready(v)		(false)
+#define kvm_arm_pmu_irq_initialized(v)	(false)
 static inline u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu,
 					    u64 select_idx)
 {
@@ -80,6 +88,21 @@ static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
 						  u64 data, u64 select_idx) {}
 static inline bool kvm_arm_support_pmu_v3(void) { return false; }
+static inline int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu,
+					  struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
+static inline int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu,
+					  struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
+static inline int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu,
+					  struct kvm_device_attr *attr)
+{
+	return -ENXIO;
+}
 #endif
 
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index d226360..7156f8b 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -19,6 +19,7 @@
 #include <linux/kvm.h>
 #include <linux/kvm_host.h>
 #include <linux/perf_event.h>
+#include <linux/uaccess.h>
 #include <asm/kvm_emulate.h>
 #include <kvm/arm_pmu.h>
 #include <kvm/arm_vgic.h>
@@ -397,3 +398,114 @@ bool kvm_arm_support_pmu_v3(void)
 	 */
 	return (perf_num_counters() > 0);
 }
+
+static int kvm_arm_pmu_v3_init(struct kvm_vcpu *vcpu)
+{
+	if (!kvm_arm_support_pmu_v3())
+		return -ENODEV;
+
+	if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features) ||
+	    !kvm_arm_pmu_irq_initialized(vcpu))
+		return -ENXIO;
+
+	if (kvm_arm_pmu_v3_ready(vcpu))
+		return -EBUSY;
+
+	kvm_pmu_vcpu_reset(vcpu);
+	vcpu->arch.pmu.ready = true;
+
+	return 0;
+}
+
+static bool irq_is_valid(struct kvm *kvm, int irq, bool is_ppi)
+{
+	int i;
+	struct kvm_vcpu *vcpu;
+
+	kvm_for_each_vcpu(i, vcpu, kvm) {
+		if (!kvm_arm_pmu_irq_initialized(vcpu))
+			continue;
+
+		if (is_ppi) {
+			if (vcpu->arch.pmu.irq_num != irq)
+				return false;
+		} else {
+			if (vcpu->arch.pmu.irq_num == irq)
+				return false;
+		}
+	}
+
+	return true;
+}
+
+
+int kvm_arm_pmu_v3_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
+{
+	switch (attr->attr) {
+	case KVM_ARM_VCPU_PMU_V3_IRQ: {
+		int __user *uaddr = (int __user *)(long)attr->addr;
+		int irq;
+
+		if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
+			return -ENODEV;
+
+		if (get_user(irq, uaddr))
+			return -EFAULT;
+
+		/*
+		 * The PMU overflow interrupt could be a PPI or SPI, but for one
+		 * VM the interrupt type must be same for each vcpu. As a PPI,
+		 * the interrupt number is the same for all vcpus, while as an
+		 * SPI it must be a separate number per vcpu.
+		 */
+		if (irq < VGIC_NR_SGIS || irq >= vcpu->kvm->arch.vgic.nr_irqs ||
+		    !irq_is_valid(vcpu->kvm, irq, irq < VGIC_NR_PRIVATE_IRQS))
+			return -EINVAL;
+
+		if (kvm_arm_pmu_irq_initialized(vcpu))
+			return -EBUSY;
+
+		kvm_debug("Set kvm ARM PMU irq: %d\n", irq);
+		vcpu->arch.pmu.irq_num = irq;
+		return 0;
+	}
+	case KVM_ARM_VCPU_PMU_V3_INIT:
+		return kvm_arm_pmu_v3_init(vcpu);
+	}
+
+	return -ENXIO;
+}
+
+int kvm_arm_pmu_v3_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
+{
+	switch (attr->attr) {
+	case KVM_ARM_VCPU_PMU_V3_IRQ: {
+		int __user *uaddr = (int __user *)(long)attr->addr;
+		int irq;
+
+		if (!test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
+			return -ENODEV;
+
+		if (!kvm_arm_pmu_irq_initialized(vcpu))
+			return -ENXIO;
+
+		irq = vcpu->arch.pmu.irq_num;
+		return put_user(irq, uaddr);
+	}
+	}
+
+	return -ENXIO;
+}
+
+int kvm_arm_pmu_v3_has_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
+{
+	switch (attr->attr) {
+	case KVM_ARM_VCPU_PMU_V3_IRQ:
+	case KVM_ARM_VCPU_PMU_V3_INIT:
+		if (kvm_arm_support_pmu_v3() &&
+		    test_bit(KVM_ARM_VCPU_PMU_V3, vcpu->arch.features))
+			return 0;
+	}
+
+	return -ENXIO;
+}
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:29 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:29 +0800
Subject: [PATCH v13 09/20] KVM: ARM64: Add access handler for event type
 register
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-10-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

These kind of registers include PMEVTYPERn, PMCCFILTR and PMXEVTYPER
which is mapped to PMEVTYPERn or PMCCFILTR.

The access handler translates all aarch32 register offsets to aarch64
ones and uses vcpu_sys_reg() to access their values to avoid taking care
of big endian.

When writing to these registers, create a perf_event for the selected
event type.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/kvm_host.h |   3 +
 arch/arm64/kvm/sys_regs.c         | 126 +++++++++++++++++++++++++++++++++++++-
 2 files changed, 127 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index e6910db..bf97e79 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -121,6 +121,9 @@ enum vcpu_sysreg {
 	PMEVCNTR0_EL0,	/* Event Counter Register (0-30) */
 	PMEVCNTR30_EL0 = PMEVCNTR0_EL0 + 30,
 	PMCCNTR_EL0,	/* Cycle Counter Register */
+	PMEVTYPER0_EL0,	/* Event Type Register (0-30) */
+	PMEVTYPER30_EL0 = PMEVTYPER0_EL0 + 30,
+	PMCCFILTR_EL0,	/* Cycle Count Filter Register */
 	PMCNTENSET_EL0,	/* Count Enable Set Register */
 
 	/* 32bit specific registers. Keep them at the end of the range */
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index d4b6ae3..4faf324 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -563,6 +563,42 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
 	return true;
 }
 
+static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			       const struct sys_reg_desc *r)
+{
+	u64 idx, reg;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (r->CRn == 9 && r->CRm == 13 && r->Op2 == 1) {
+		/* PMXEVTYPER_EL0 */
+		idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_PMU_COUNTER_MASK;
+		reg = PMEVTYPER0_EL0 + idx;
+	} else if (r->CRn == 14 && (r->CRm & 12) == 12) {
+		idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+		if (idx == ARMV8_PMU_CYCLE_IDX)
+			reg = PMCCFILTR_EL0;
+		else
+			/* PMEVTYPERn_EL0 */
+			reg = PMEVTYPER0_EL0 + idx;
+	} else {
+		BUG();
+	}
+
+	if (!pmu_counter_idx_valid(vcpu, idx))
+		return false;
+
+	if (p->is_write) {
+		kvm_pmu_set_counter_event_type(vcpu, p->regval, idx);
+		vcpu_sys_reg(vcpu, reg) = p->regval & ARMV8_PMU_EVTYPE_MASK;
+	} else {
+		p->regval = vcpu_sys_reg(vcpu, reg) & ARMV8_PMU_EVTYPE_MASK;
+	}
+
+	return true;
+}
+
 static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 			   const struct sys_reg_desc *r)
 {
@@ -612,6 +648,13 @@ static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	  CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)),		\
 	  access_pmu_evcntr, reset_unknown, (PMEVCNTR0_EL0 + n), }
 
+/* Macro to expand the PMEVTYPERn_EL0 register */
+#define PMU_PMEVTYPER_EL0(n)						\
+	/* PMEVTYPERn_EL0 */						\
+	{ Op0(0b11), Op1(0b011), CRn(0b1110),				\
+	  CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)),		\
+	  access_pmu_evtyper, reset_unknown, (PMEVTYPER0_EL0 + n), }
+
 /*
  * Architected system registers.
  * Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
@@ -808,7 +851,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmu_evcntr, reset_unknown, PMCCNTR_EL0 },
 	/* PMXEVTYPER_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
-	  trap_raz_wi },
+	  access_pmu_evtyper },
 	/* PMXEVCNTR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
 	  access_pmu_evcntr },
@@ -858,6 +901,44 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	PMU_PMEVCNTR_EL0(28),
 	PMU_PMEVCNTR_EL0(29),
 	PMU_PMEVCNTR_EL0(30),
+	/* PMEVTYPERn_EL0 */
+	PMU_PMEVTYPER_EL0(0),
+	PMU_PMEVTYPER_EL0(1),
+	PMU_PMEVTYPER_EL0(2),
+	PMU_PMEVTYPER_EL0(3),
+	PMU_PMEVTYPER_EL0(4),
+	PMU_PMEVTYPER_EL0(5),
+	PMU_PMEVTYPER_EL0(6),
+	PMU_PMEVTYPER_EL0(7),
+	PMU_PMEVTYPER_EL0(8),
+	PMU_PMEVTYPER_EL0(9),
+	PMU_PMEVTYPER_EL0(10),
+	PMU_PMEVTYPER_EL0(11),
+	PMU_PMEVTYPER_EL0(12),
+	PMU_PMEVTYPER_EL0(13),
+	PMU_PMEVTYPER_EL0(14),
+	PMU_PMEVTYPER_EL0(15),
+	PMU_PMEVTYPER_EL0(16),
+	PMU_PMEVTYPER_EL0(17),
+	PMU_PMEVTYPER_EL0(18),
+	PMU_PMEVTYPER_EL0(19),
+	PMU_PMEVTYPER_EL0(20),
+	PMU_PMEVTYPER_EL0(21),
+	PMU_PMEVTYPER_EL0(22),
+	PMU_PMEVTYPER_EL0(23),
+	PMU_PMEVTYPER_EL0(24),
+	PMU_PMEVTYPER_EL0(25),
+	PMU_PMEVTYPER_EL0(26),
+	PMU_PMEVTYPER_EL0(27),
+	PMU_PMEVTYPER_EL0(28),
+	PMU_PMEVTYPER_EL0(29),
+	PMU_PMEVTYPER_EL0(30),
+	/* PMCCFILTR_EL0
+	 * This register resets as unknown in 64bit mode while it resets as zero
+	 * in 32bit mode. Here we choose to reset it as zero for consistency.
+	 */
+	{ Op0(0b11), Op1(0b011), CRn(0b1110), CRm(0b1111), Op2(0b111),
+	  access_pmu_evtyper, reset_val, PMCCFILTR_EL0, 0 },
 
 	/* DACR32_EL2 */
 	{ Op0(0b11), Op1(0b100), CRn(0b0011), CRm(0b0000), Op2(0b000),
@@ -1055,6 +1136,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
 	  CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)),		\
 	  access_pmu_evcntr }
 
+/* Macro to expand the PMEVTYPERn register */
+#define PMU_PMEVTYPER(n)						\
+	/* PMEVTYPERn */						\
+	{ Op1(0), CRn(0b1110),						\
+	  CRm((0b1100 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)),		\
+	  access_pmu_evtyper }
+
 /*
  * Trapped cp15 registers. TTBR0/TTBR1 get a double encoding,
  * depending on the way they are accessed (as a 32bit or a 64bit
@@ -1091,7 +1179,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), access_pmu_evcntr },
-	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
@@ -1139,6 +1227,40 @@ static const struct sys_reg_desc cp15_regs[] = {
 	PMU_PMEVCNTR(28),
 	PMU_PMEVCNTR(29),
 	PMU_PMEVCNTR(30),
+	/* PMEVTYPERn */
+	PMU_PMEVTYPER(0),
+	PMU_PMEVTYPER(1),
+	PMU_PMEVTYPER(2),
+	PMU_PMEVTYPER(3),
+	PMU_PMEVTYPER(4),
+	PMU_PMEVTYPER(5),
+	PMU_PMEVTYPER(6),
+	PMU_PMEVTYPER(7),
+	PMU_PMEVTYPER(8),
+	PMU_PMEVTYPER(9),
+	PMU_PMEVTYPER(10),
+	PMU_PMEVTYPER(11),
+	PMU_PMEVTYPER(12),
+	PMU_PMEVTYPER(13),
+	PMU_PMEVTYPER(14),
+	PMU_PMEVTYPER(15),
+	PMU_PMEVTYPER(16),
+	PMU_PMEVTYPER(17),
+	PMU_PMEVTYPER(18),
+	PMU_PMEVTYPER(19),
+	PMU_PMEVTYPER(20),
+	PMU_PMEVTYPER(21),
+	PMU_PMEVTYPER(22),
+	PMU_PMEVTYPER(23),
+	PMU_PMEVTYPER(24),
+	PMU_PMEVTYPER(25),
+	PMU_PMEVTYPER(26),
+	PMU_PMEVTYPER(27),
+	PMU_PMEVTYPER(28),
+	PMU_PMEVTYPER(29),
+	PMU_PMEVTYPER(30),
+	/* PMCCFILTR */
+	{ Op1(0), CRn(14), CRm(15), Op2(7), access_pmu_evtyper },
 };
 
 static const struct sys_reg_desc cp15_64_regs[] = {
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:26 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:26 +0800
Subject: [PATCH v13 06/20] KVM: ARM64: Add access handler for event counter
 register
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-7-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

These kind of registers include PMEVCNTRn, PMCCNTR and PMXEVCNTR which
is mapped to PMEVCNTRn.

The access handler translates all aarch32 register offsets to aarch64
ones and uses vcpu_sys_reg() to access their values to avoid taking care
of big endian.

When reading these registers, return the sum of register value and the
value perf event counts.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/include/asm/kvm_host.h |   3 +
 arch/arm64/kvm/Makefile           |   1 +
 arch/arm64/kvm/sys_regs.c         | 139 ++++++++++++++++++++++++++++++++++++--
 include/kvm/arm_pmu.h             |  11 +++
 virt/kvm/arm/pmu.c                |  63 +++++++++++++++++
 5 files changed, 213 insertions(+), 4 deletions(-)
 create mode 100644 virt/kvm/arm/pmu.c

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index e342b48..627f01e 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -118,6 +118,9 @@ enum vcpu_sysreg {
 	/* Performance Monitors Registers */
 	PMCR_EL0,	/* Control Register */
 	PMSELR_EL0,	/* Event Counter Selection Register */
+	PMEVCNTR0_EL0,	/* Event Counter Register (0-30) */
+	PMEVCNTR30_EL0 = PMEVCNTR0_EL0 + 30,
+	PMCCNTR_EL0,	/* Cycle Counter Register */
 
 	/* 32bit specific registers. Keep them at the end of the range */
 	DACR32_EL2,	/* Domain Access Control Register */
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index caee9ee..122cff4 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -26,3 +26,4 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v2-emul.o
 kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3.o
 kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic-v3-emul.o
 kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
+kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index ca8cdf6..ff3214b 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -513,6 +513,56 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return true;
 }
 
+static bool pmu_counter_idx_valid(struct kvm_vcpu *vcpu, u64 idx)
+{
+	u64 pmcr, val;
+
+	pmcr = vcpu_sys_reg(vcpu, PMCR_EL0);
+	val = (pmcr >> ARMV8_PMU_PMCR_N_SHIFT) & ARMV8_PMU_PMCR_N_MASK;
+	if (idx >= val && idx != ARMV8_PMU_CYCLE_IDX)
+		return false;
+
+	return true;
+}
+
+static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
+			      struct sys_reg_params *p,
+			      const struct sys_reg_desc *r)
+{
+	u64 idx;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (r->CRn == 9 && r->CRm == 13) {
+		if (r->Op2 == 2) {
+			/* PMXEVCNTR_EL0 */
+			idx = vcpu_sys_reg(vcpu, PMSELR_EL0)
+			      & ARMV8_PMU_COUNTER_MASK;
+		} else if (r->Op2 == 0) {
+			/* PMCCNTR_EL0 */
+			idx = ARMV8_PMU_CYCLE_IDX;
+		} else {
+			BUG();
+		}
+	} else if (r->CRn == 14 && (r->CRm & 12) == 8) {
+		/* PMEVCNTRn_EL0 */
+		idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
+	} else {
+		BUG();
+	}
+
+	if (!pmu_counter_idx_valid(vcpu, idx))
+		return false;
+
+	if (p->is_write)
+		kvm_pmu_set_counter_value(vcpu, idx, p->regval);
+	else
+		p->regval = kvm_pmu_get_counter_value(vcpu, idx);
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -528,6 +578,13 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	{ Op0(0b10), Op1(0b000), CRn(0b0000), CRm((n)), Op2(0b111),	\
 	  trap_wcr, reset_wcr, n, 0,  get_wcr, set_wcr }
 
+/* Macro to expand the PMEVCNTRn_EL0 register */
+#define PMU_PMEVCNTR_EL0(n)						\
+	/* PMEVCNTRn_EL0 */						\
+	{ Op0(0b11), Op1(0b011), CRn(0b1110),				\
+	  CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)),		\
+	  access_pmu_evcntr, reset_unknown, (PMEVCNTR0_EL0 + n), }
+
 /*
  * Architected system registers.
  * Important: Must be sorted ascending by Op0, Op1, CRn, CRm, Op2
@@ -721,13 +778,13 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	  access_pmceid },
 	/* PMCCNTR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b000),
-	  trap_raz_wi },
+	  access_pmu_evcntr, reset_unknown, PMCCNTR_EL0 },
 	/* PMXEVTYPER_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b001),
 	  trap_raz_wi },
 	/* PMXEVCNTR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
-	  trap_raz_wi },
+	  access_pmu_evcntr },
 	/* PMUSERENR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
 	  trap_raz_wi },
@@ -742,6 +799,39 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	{ Op0(0b11), Op1(0b011), CRn(0b1101), CRm(0b0000), Op2(0b011),
 	  NULL, reset_unknown, TPIDRRO_EL0 },
 
+	/* PMEVCNTRn_EL0 */
+	PMU_PMEVCNTR_EL0(0),
+	PMU_PMEVCNTR_EL0(1),
+	PMU_PMEVCNTR_EL0(2),
+	PMU_PMEVCNTR_EL0(3),
+	PMU_PMEVCNTR_EL0(4),
+	PMU_PMEVCNTR_EL0(5),
+	PMU_PMEVCNTR_EL0(6),
+	PMU_PMEVCNTR_EL0(7),
+	PMU_PMEVCNTR_EL0(8),
+	PMU_PMEVCNTR_EL0(9),
+	PMU_PMEVCNTR_EL0(10),
+	PMU_PMEVCNTR_EL0(11),
+	PMU_PMEVCNTR_EL0(12),
+	PMU_PMEVCNTR_EL0(13),
+	PMU_PMEVCNTR_EL0(14),
+	PMU_PMEVCNTR_EL0(15),
+	PMU_PMEVCNTR_EL0(16),
+	PMU_PMEVCNTR_EL0(17),
+	PMU_PMEVCNTR_EL0(18),
+	PMU_PMEVCNTR_EL0(19),
+	PMU_PMEVCNTR_EL0(20),
+	PMU_PMEVCNTR_EL0(21),
+	PMU_PMEVCNTR_EL0(22),
+	PMU_PMEVCNTR_EL0(23),
+	PMU_PMEVCNTR_EL0(24),
+	PMU_PMEVCNTR_EL0(25),
+	PMU_PMEVCNTR_EL0(26),
+	PMU_PMEVCNTR_EL0(27),
+	PMU_PMEVCNTR_EL0(28),
+	PMU_PMEVCNTR_EL0(29),
+	PMU_PMEVCNTR_EL0(30),
+
 	/* DACR32_EL2 */
 	{ Op0(0b11), Op1(0b100), CRn(0b0011), CRm(0b0000), Op2(0b000),
 	  NULL, reset_unknown, DACR32_EL2 },
@@ -931,6 +1021,13 @@ static const struct sys_reg_desc cp14_64_regs[] = {
 	{ Op1( 0), CRm( 2), .access = trap_raz_wi },
 };
 
+/* Macro to expand the PMEVCNTRn register */
+#define PMU_PMEVCNTR(n)							\
+	/* PMEVCNTRn */							\
+	{ Op1(0), CRn(0b1110),						\
+	  CRm((0b1000 | (((n) >> 3) & 0x3))), Op2(((n) & 0x7)),		\
+	  access_pmu_evcntr }
+
 /*
  * Trapped cp15 registers. TTBR0/TTBR1 get a double encoding,
  * depending on the way they are accessed (as a 32bit or a 64bit
@@ -966,9 +1063,9 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 5), access_pmselr },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 6), access_pmceid },
 	{ Op1( 0), CRn( 9), CRm(12), Op2( 7), access_pmceid },
-	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), access_pmu_evcntr },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), trap_raz_wi },
-	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), trap_raz_wi },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), trap_raz_wi },
@@ -982,10 +1079,44 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn(12), CRm(12), Op2( 5), trap_raz_wi },
 
 	{ Op1( 0), CRn(13), CRm( 0), Op2( 1), access_vm_reg, NULL, c13_CID },
+
+	/* PMEVCNTRn */
+	PMU_PMEVCNTR(0),
+	PMU_PMEVCNTR(1),
+	PMU_PMEVCNTR(2),
+	PMU_PMEVCNTR(3),
+	PMU_PMEVCNTR(4),
+	PMU_PMEVCNTR(5),
+	PMU_PMEVCNTR(6),
+	PMU_PMEVCNTR(7),
+	PMU_PMEVCNTR(8),
+	PMU_PMEVCNTR(9),
+	PMU_PMEVCNTR(10),
+	PMU_PMEVCNTR(11),
+	PMU_PMEVCNTR(12),
+	PMU_PMEVCNTR(13),
+	PMU_PMEVCNTR(14),
+	PMU_PMEVCNTR(15),
+	PMU_PMEVCNTR(16),
+	PMU_PMEVCNTR(17),
+	PMU_PMEVCNTR(18),
+	PMU_PMEVCNTR(19),
+	PMU_PMEVCNTR(20),
+	PMU_PMEVCNTR(21),
+	PMU_PMEVCNTR(22),
+	PMU_PMEVCNTR(23),
+	PMU_PMEVCNTR(24),
+	PMU_PMEVCNTR(25),
+	PMU_PMEVCNTR(26),
+	PMU_PMEVCNTR(27),
+	PMU_PMEVCNTR(28),
+	PMU_PMEVCNTR(29),
+	PMU_PMEVCNTR(30),
 };
 
 static const struct sys_reg_desc cp15_64_regs[] = {
 	{ Op1( 0), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR0 },
+	{ Op1( 0), CRn( 0), CRm( 9), Op2( 0), access_pmu_evcntr },
 	{ Op1( 0), CRn( 0), CRm(12), Op2( 0), access_gic_sgi },
 	{ Op1( 1), CRn( 0), CRm( 2), Op2( 0), access_vm_reg, NULL, c2_TTBR1 },
 };
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 8157fe5..bcb7698 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -23,6 +23,8 @@
 #include <linux/perf_event.h>
 #include <asm/perf_event.h>
 
+#define ARMV8_PMU_CYCLE_IDX		(ARMV8_PMU_MAX_COUNTERS - 1)
+
 struct kvm_pmc {
 	u8 idx;	/* index into the pmu->pmc array */
 	struct perf_event *perf_event;
@@ -36,11 +38,20 @@ struct kvm_pmu {
 };
 
 #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
+u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
+void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 #else
 struct kvm_pmu {
 };
 
 #define kvm_arm_pmu_v3_ready(v)		(false)
+static inline u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu,
+					    u64 select_idx)
+{
+	return 0;
+}
+static inline void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu,
+					     u64 select_idx, u64 val) {}
 #endif
 
 #endif
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
new file mode 100644
index 0000000..cd74e63
--- /dev/null
+++ b/virt/kvm/arm/pmu.c
@@ -0,0 +1,63 @@
+/*
+ * Copyright (C) 2015 Linaro Ltd.
+ * Author: Shannon Zhao <shannon.zhao at linaro.org>
+ *
+ * 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/cpu.h>
+#include <linux/kvm.h>
+#include <linux/kvm_host.h>
+#include <linux/perf_event.h>
+#include <asm/kvm_emulate.h>
+#include <kvm/arm_pmu.h>
+
+/**
+ * kvm_pmu_get_counter_value - get PMU counter value
+ * @vcpu: The vcpu pointer
+ * @select_idx: The counter index
+ */
+u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx)
+{
+	u64 counter, reg, enabled, running;
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	struct kvm_pmc *pmc = &pmu->pmc[select_idx];
+
+	reg = (select_idx == ARMV8_PMU_CYCLE_IDX)
+	      ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + select_idx;
+	counter = vcpu_sys_reg(vcpu, reg);
+
+	/* The real counter value is equal to the value of counter register plus
+	 * the value perf event counts.
+	 */
+	if (pmc->perf_event)
+		counter += perf_event_read_value(pmc->perf_event, &enabled,
+						 &running);
+
+	return counter & pmc->bitmask;
+}
+
+/**
+ * kvm_pmu_set_counter_value - set PMU counter value
+ * @vcpu: The vcpu pointer
+ * @select_idx: The counter index
+ * @val: The counter value
+ */
+void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val)
+{
+	u64 reg;
+
+	reg = (select_idx == ARMV8_PMU_CYCLE_IDX)
+	      ? PMCCNTR_EL0 : PMEVCNTR0_EL0 + select_idx;
+	vcpu_sys_reg(vcpu, reg) += (s64)val - kvm_pmu_get_counter_value(vcpu, select_idx);
+}
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:37 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:37 +0800
Subject: [PATCH v13 17/20] KVM: ARM64: Free perf event of PMU when destroying
 vcpu
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-18-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When KVM frees VCPU, it needs to free the perf_event of PMU.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm/kvm/arm.c    |  1 +
 include/kvm/arm_pmu.h |  2 ++
 virt/kvm/arm/pmu.c    | 21 +++++++++++++++++++++
 3 files changed, 24 insertions(+)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index f54264c..d2c2cc3 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -266,6 +266,7 @@ void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
 	kvm_mmu_free_memory_caches(vcpu);
 	kvm_timer_vcpu_terminate(vcpu);
 	kvm_vgic_vcpu_destroy(vcpu);
+	kvm_pmu_vcpu_destroy(vcpu);
 	kmem_cache_free(kvm_vcpu_cache, vcpu);
 }
 
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index a227213..fd396d6 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -43,6 +43,7 @@ u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
 void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
 void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu);
+void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
@@ -68,6 +69,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 	return 0;
 }
 static inline void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu) {}
+static inline void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu) {}
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index ee3772c..cb946fd 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -101,6 +101,27 @@ void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu)
 	}
 }
 
+/**
+ * kvm_pmu_vcpu_destroy - free perf event of PMU for cpu
+ * @vcpu: The vcpu pointer
+ *
+ */
+void kvm_pmu_vcpu_destroy(struct kvm_vcpu *vcpu)
+{
+	int i;
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+	for (i = 0; i < ARMV8_PMU_MAX_COUNTERS; i++) {
+		struct kvm_pmc *pmc = &pmu->pmc[i];
+
+		if (pmc->perf_event) {
+			perf_event_disable(pmc->perf_event);
+			perf_event_release_kernel(pmc->perf_event);
+			pmc->perf_event = NULL;
+		}
+	}
+}
+
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 {
 	u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMU_PMCR_N_SHIFT;
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:36 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:36 +0800
Subject: [PATCH v13 16/20] KVM: ARM64: Reset PMU state when resetting vcpu
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-17-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When resetting vcpu, it needs to reset the PMU state to initial status.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm64/kvm/reset.c |  3 +++
 include/kvm/arm_pmu.h  |  2 ++
 virt/kvm/arm/pmu.c     | 17 +++++++++++++++++
 3 files changed, 22 insertions(+)

diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index f34745c..dfbce78 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -120,6 +120,9 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 	/* Reset system registers */
 	kvm_reset_sys_regs(vcpu);
 
+	/* Reset PMU */
+	kvm_pmu_vcpu_reset(vcpu);
+
 	/* Reset timer */
 	return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
 }
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 0aed4d4..a227213 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -42,6 +42,7 @@ struct kvm_pmu {
 u64 kvm_pmu_get_counter_value(struct kvm_vcpu *vcpu, u64 select_idx);
 void kvm_pmu_set_counter_value(struct kvm_vcpu *vcpu, u64 select_idx, u64 val);
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
+void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
@@ -66,6 +67,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 {
 	return 0;
 }
+static inline void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu) {}
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index 1cd4214..ee3772c 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -84,6 +84,23 @@ static void kvm_pmu_stop_counter(struct kvm_vcpu *vcpu, struct kvm_pmc *pmc)
 	}
 }
 
+/**
+ * kvm_pmu_vcpu_reset - reset pmu state for cpu
+ * @vcpu: The vcpu pointer
+ *
+ */
+void kvm_pmu_vcpu_reset(struct kvm_vcpu *vcpu)
+{
+	int i;
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+
+	for (i = 0; i < ARMV8_PMU_MAX_COUNTERS; i++) {
+		kvm_pmu_stop_counter(vcpu, &pmu->pmc[i]);
+		pmu->pmc[i].idx = i;
+		pmu->pmc[i].bitmask = 0xffffffffUL;
+	}
+}
+
 u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 {
 	u64 val = vcpu_sys_reg(vcpu, PMCR_EL0) >> ARMV8_PMU_PMCR_N_SHIFT;
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:20 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:20 +0800
Subject: [PATCH v13 00/20] KVM: ARM64: Add guest PMU support
Message-ID: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

This patchset adds guest PMU support for KVM on ARM64. It takes
trap-and-emulate approach. When guest wants to monitor one event, it
will be trapped by KVM and KVM will call perf_event API to create a perf
event and call relevant perf_event APIs to get the count value of event.

Use perf to test this patchset in guest. When using "perf list", it
shows the list of the hardware events and hardware cache events perf
supports. Then use "perf stat -e EVENT" to monitor some event. For
example, use "perf stat -e cycles" to count cpu cycles and
"perf stat -e cache-misses" to count cache misses.

Below are the outputs of "perf stat -r 5 sleep 5" when running in host
and guest.

Host:
 Performance counter stats for 'sleep 5' (5 runs):

          0.529248      task-clock (msec)         #    0.000 CPUs utilized            ( +-  1.65% )
                 1      context-switches          #    0.002 M/sec
                 0      cpu-migrations            #    0.000 K/sec
                49      page-faults               #    0.092 M/sec                    ( +-  1.05% )
           1104279      cycles                    #    2.087 GHz                      ( +-  1.65% )
   <not supported>      stalled-cycles-frontend
   <not supported>      stalled-cycles-backend
            528112      instructions              #    0.48  insns per cycle          ( +-  1.12% )
   <not supported>      branches
              9579      branch-misses             #   18.099 M/sec                    ( +-  2.40% )

       5.000851904 seconds time elapsed                                          ( +-  0.00% )

Guest:
 Performance counter stats for 'sleep 5' (5 runs):

          0.695412      task-clock (msec)         #    0.000 CPUs utilized            ( +-  1.26% )
                 1      context-switches          #    0.001 M/sec
                 0      cpu-migrations            #    0.000 K/sec
                49      page-faults               #    0.070 M/sec                    ( +-  1.29% )
           1430471      cycles                    #    2.057 GHz                      ( +-  1.25% )
   <not supported>      stalled-cycles-frontend
   <not supported>      stalled-cycles-backend
            659173      instructions              #    0.46  insns per cycle          ( +-  2.64% )
   <not supported>      branches
             10893      branch-misses             #   15.664 M/sec                    ( +-  1.23% )

       5.001277044 seconds time elapsed                                          ( +-  0.00% )

Have a cycle counter read test like below in guest and host:

static void test(void)
{
	unsigned long count, count1, count2;
	count1 = read_cycles();
	count++;
	count2 = read_cycles();
}

Host:
count1: 3046505444
count2: 3046505575
delta: 131

Guest:
count1: 5932773531
count2: 5932773668
delta: 137

The gap between guest and host is very small. One reason for this I
think is that it doesn't count the cycles in EL2 and host since we add
exclude_hv = 1. So the cycles spent to store/restore registers which
happens at EL2 are not included.

This patchset can be fetched from [1] and the relevant QEMU version for
test can be fetched from [2].

The results of 'perf test' can be found from [3][4].
The results of perf_event_tests test suite can be found from [5][6].

Also, I have tested "perf top" in two VMs and host at the same time. It
works well.

Thanks,
Shannon

[1] https://git.linaro.org/people/shannon.zhao/linux-mainline.git  KVM_ARM64_PMU_v13
[2] https://git.linaro.org/people/shannon.zhao/qemu.git  PMU
[3] http://people.linaro.org/~shannon.zhao/PMU/perf-test-host.txt
[4] http://people.linaro.org/~shannon.zhao/PMU/perf-test-guest.txt
[5] http://people.linaro.org/~shannon.zhao/PMU/perf_event_tests-host.txt
[6] http://people.linaro.org/~shannon.zhao/PMU/perf_event_tests-guest.txt

Changes since v12:
* Fix bisect problem
* Move ARMV8_PMU_PMCR_LC into the patch which firstly uses it
* Inject PMU irq only when level changed to save cycles(Marc, thanks!)

Changes since v11:
* Move PMU register related defines to asm/perf_event.h and rename them
  with prefix ARMV8_PMU_*
* BUG_ON when writing to PMCEID0/1 register
* Lower the PMU interrupt line when PMCR_EL0.E == 0
* Fix come coding styles
* Drop kvm_arm_pmu_irq_access

Changes since v10:
* Check if PMCR.N is zero before using GENMASK
* Fix attr.disabled
* use same way to reset counter's value in PATCH 14

Changes since v9:
* Change kvm_arm_support_pmu_v3 to a bool function [PATCH 19/21]
* Fix several typoes, change checking logic of kvm_arm_pmu_v3_init and
  change irq_is_invalid to irq_is_valid [PATCH 21/21]
* Add Acks and Rb from Peter and Andrew, thanks a lot

Changes since v8:
* Fix the wrong use of r->reg in register accessors for 32bit part
* Rewrite the handle of PMUSERENR based on the new inject UND patch
* Drop the inline attribute
* Introduce SET/GET/HAS_DEVICE_ATTR for vcpu iotcl and set the PMU
  overflow interrupt via this API
* Use one feature bit for PMUv3

Changes since v7:
* Rebase on kvm-arm next
* Fix the handler of PMUSERENR and add a helper to forward trap to guest
  EL1
* Fix some small bugs found by Marc

Changes since v6:
* Rebase on v4.4-rc5
* Drop access_pmu_cp15_regs() so that it could use same handler for both
  arch64 and arch32. And it could drop the definitions of CP15 register
  offsets, also avoid same codes added twice
* Use vcpu_sys_reg() when accessing PMU registers to avoid endian things
* Add handler for PMUSERENR and some checkers for other registers
* Add kvm_arm_pmu_get_attr()

Changes since v5:
* Rebase on new linux kernel mainline
* Remove state duplications and drop PMOVSCLR, PMCNTENCLR, PMINTENCLR,
  PMXEVCNTR, PMXEVTYPER
* Add a helper to check if vPMU is already initialized
* remove kvm_vcpu from kvm_pmc

Changes since v4:
* Rebase on new linux kernel mainline 
* Drop the reset handler of CP15 registers
* Fix a compile failure on arch ARM due to lack of asm/pmu.h
* Refactor the interrupt injecting flow according to Marc's suggestion
* Check the value of PMSELR register
* Calculate the attr.disabled according to PMCR.E and PMCNTENSET/CLR
* Fix some coding style
* Document the vPMU irq range

Changes since v3:
* Rebase on new linux kernel mainline 
* Use ARMV8_MAX_COUNTERS instead of 32
* Reset PMCR.E to zero.
* Trigger overflow for software increment.
* Optimize PMU interrupt inject logic.
* Add handler for E,C,P bits of PMCR
* Fix the overflow bug found by perf_event_tests
* Run 'perf test', 'perf top' and perf_event_tests test suite
* Add exclude_hv = 1 configuration to not count in EL2

Changes since v2:
* Directly use perf raw event type to create perf_event in KVM
* Add a helper vcpu_sysreg_write
* remove unrelated header file

Changes since v1:
* Use switch...case for registers access handler instead of adding
  alone handler for each register
* Try to use the sys_regs to store the register value instead of adding
  new variables in struct kvm_pmc
* Fix the handle of cp15 regs
* Create a new kvm device vPMU, then userspace could choose whether to
  create PMU
* Fix the handle of PMU overflow interrupt

Shannon Zhao (20):
  ARM64: Move PMU register related defines to asm/perf_event.h
  KVM: ARM64: Define PMU data structure for each vcpu
  KVM: ARM64: Add access handler for PMCR register
  KVM: ARM64: Add access handler for PMSELR register
  KVM: ARM64: Add access handler for PMCEID0 and PMCEID1 register
  KVM: ARM64: Add access handler for event counter register
  KVM: ARM64: Add access handler for PMCNTENSET and PMCNTENCLR register
  KVM: ARM64: PMU: Add perf event map and introduce perf event creating
    function
  KVM: ARM64: Add access handler for event type register
  KVM: ARM64: Add access handler for PMINTENSET and PMINTENCLR register
  KVM: ARM64: Add access handler for PMOVSSET and PMOVSCLR register
  KVM: ARM64: Add access handler for PMSWINC register
  KVM: ARM64: Add helper to handle PMCR register bits
  KVM: ARM64: Add access handler for PMUSERENR register
  KVM: ARM64: Add PMU overflow interrupt routing
  KVM: ARM64: Reset PMU state when resetting vcpu
  KVM: ARM64: Free perf event of PMU when destroying vcpu
  KVM: ARM64: Add a new feature bit for PMUv3
  KVM: ARM: Introduce per-vcpu kvm device controls
  KVM: ARM64: Add a new vcpu device control group for PMUv3

 Documentation/virtual/kvm/api.txt          |  12 +-
 Documentation/virtual/kvm/devices/vcpu.txt |  33 ++
 arch/arm/include/asm/kvm_host.h            |  15 +
 arch/arm/kvm/arm.c                         |  61 ++++
 arch/arm64/include/asm/kvm_host.h          |  25 +-
 arch/arm64/include/asm/perf_event.h        |  48 +++
 arch/arm64/include/uapi/asm/kvm.h          |   6 +
 arch/arm64/kernel/perf_event.c             |  68 +---
 arch/arm64/kvm/Kconfig                     |   7 +
 arch/arm64/kvm/Makefile                    |   1 +
 arch/arm64/kvm/guest.c                     |  51 +++
 arch/arm64/kvm/hyp/hyp.h                   |   1 +
 arch/arm64/kvm/hyp/switch.c                |   3 +
 arch/arm64/kvm/reset.c                     |   7 +
 arch/arm64/kvm/sys_regs.c                  | 569 +++++++++++++++++++++++++++--
 include/kvm/arm_pmu.h                      | 108 ++++++
 include/uapi/linux/kvm.h                   |   2 +
 virt/kvm/arm/pmu.c                         | 511 ++++++++++++++++++++++++++
 18 files changed, 1443 insertions(+), 85 deletions(-)
 create mode 100644 Documentation/virtual/kvm/devices/vcpu.txt
 create mode 100644 include/kvm/arm_pmu.h
 create mode 100644 virt/kvm/arm/pmu.c

-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:34 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:34 +0800
Subject: [PATCH v13 14/20] KVM: ARM64: Add access handler for PMUSERENR
 register
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-15-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

This register resets as unknown in 64bit mode while it resets as zero
in 32bit mode. Here we choose to reset it as zero for consistency.

PMUSERENR_EL0 holds some bits which decide whether PMU registers can be
accessed from EL0. Add some check helpers to handle the access from EL0.

When these bits are zero, only reading PMUSERENR will trap to EL2 and
writing PMUSERENR or reading/writing other PMU registers will trap to
EL1 other than EL2 when HCR.TGE==0. To current KVM configuration
(HCR.TGE==0) there is no way to get these traps. Here we write 0xf to
physical PMUSERENR register on VM entry, so that it will trap PMU access
from EL0 to EL2. Within the register access handler we check the real
value of guest PMUSERENR register to decide whether this access is
allowed. If not allowed, return false to inject UND to guest.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
---
 arch/arm64/include/asm/kvm_host.h   |   1 +
 arch/arm64/include/asm/perf_event.h |   9 ++++
 arch/arm64/kvm/hyp/hyp.h            |   1 +
 arch/arm64/kvm/hyp/switch.c         |   3 ++
 arch/arm64/kvm/sys_regs.c           | 101 ++++++++++++++++++++++++++++++++++--
 5 files changed, 110 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index de1f82d..7b61675 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -128,6 +128,7 @@ enum vcpu_sysreg {
 	PMINTENSET_EL1,	/* Interrupt Enable Set Register */
 	PMOVSSET_EL0,	/* Overflow Flag Status Set Register */
 	PMSWINC_EL0,	/* Software Increment Register */
+	PMUSERENR_EL0,	/* User Enable Register */
 
 	/* 32bit specific registers. Keep them at the end of the range */
 	DACR32_EL2,	/* Domain Access Control Register */
diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
index c3f5937..76e1931 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -56,6 +56,15 @@
 #define	ARMV8_PMU_EXCLUDE_EL0	(1 << 30)
 #define	ARMV8_PMU_INCLUDE_EL2	(1 << 27)
 
+/*
+ * PMUSERENR: user enable reg
+ */
+#define ARMV8_PMU_USERENR_MASK	0xf		/* Mask for writable bits */
+#define ARMV8_PMU_USERENR_EN	(1 << 0) /* PMU regs can be accessed at EL0 */
+#define ARMV8_PMU_USERENR_SW	(1 << 1) /* PMSWINC can be written at EL0 */
+#define ARMV8_PMU_USERENR_CR	(1 << 2) /* Cycle counter can be read at EL0 */
+#define ARMV8_PMU_USERENR_ER	(1 << 3) /* Event counter can be read at EL0 */
+
 #ifdef CONFIG_PERF_EVENTS
 struct pt_regs;
 extern unsigned long perf_instruction_pointer(struct pt_regs *regs);
diff --git a/arch/arm64/kvm/hyp/hyp.h b/arch/arm64/kvm/hyp/hyp.h
index fb27517..c65f8c9 100644
--- a/arch/arm64/kvm/hyp/hyp.h
+++ b/arch/arm64/kvm/hyp/hyp.h
@@ -22,6 +22,7 @@
 #include <linux/kvm_host.h>
 #include <asm/kvm_mmu.h>
 #include <asm/sysreg.h>
+#include <asm/perf_event.h>
 
 #define __hyp_text __section(.hyp.text) notrace
 
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index f0e7bdf..dfe111d 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -41,6 +41,8 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
 	val |= CPTR_EL2_TTA | CPTR_EL2_TFP;
 	write_sysreg(val, cptr_el2);
 
+	/* Make sure we trap PMU access from EL0 to EL2 */
+	write_sysreg(ARMV8_PMU_USERENR_MASK, pmuserenr_el0);
 	write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
 }
 
@@ -49,6 +51,7 @@ static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
 	write_sysreg(HCR_RW, hcr_el2);
 	write_sysreg(0, hstr_el2);
 	write_sysreg(read_sysreg(mdcr_el2) & MDCR_EL2_HPMN_MASK, mdcr_el2);
+	write_sysreg(0, pmuserenr_el0);
 	write_sysreg(CPTR_EL2_DEFAULT, cptr_el2);
 }
 
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 12f36ef..fe15c23 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -453,6 +453,37 @@ static void reset_pmcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *r)
 	vcpu_sys_reg(vcpu, PMCR_EL0) = val;
 }
 
+static bool pmu_access_el0_disabled(struct kvm_vcpu *vcpu)
+{
+	u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+	return !((reg & ARMV8_PMU_USERENR_EN) || vcpu_mode_priv(vcpu));
+}
+
+static bool pmu_write_swinc_el0_disabled(struct kvm_vcpu *vcpu)
+{
+	u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+	return !((reg & (ARMV8_PMU_USERENR_SW | ARMV8_PMU_USERENR_EN))
+		 || vcpu_mode_priv(vcpu));
+}
+
+static bool pmu_access_cycle_counter_el0_disabled(struct kvm_vcpu *vcpu)
+{
+	u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+	return !((reg & (ARMV8_PMU_USERENR_CR | ARMV8_PMU_USERENR_EN))
+		 || vcpu_mode_priv(vcpu));
+}
+
+static bool pmu_access_event_counter_el0_disabled(struct kvm_vcpu *vcpu)
+{
+	u64 reg = vcpu_sys_reg(vcpu, PMUSERENR_EL0);
+
+	return !((reg & (ARMV8_PMU_USERENR_ER | ARMV8_PMU_USERENR_EN))
+		 || vcpu_mode_priv(vcpu));
+}
+
 static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 			const struct sys_reg_desc *r)
 {
@@ -461,6 +492,9 @@ static bool access_pmcr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_access_el0_disabled(vcpu))
+		return false;
+
 	if (p->is_write) {
 		/* Only update writeable bits of PMCR */
 		val = vcpu_sys_reg(vcpu, PMCR_EL0);
@@ -484,6 +518,9 @@ static bool access_pmselr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_access_event_counter_el0_disabled(vcpu))
+		return false;
+
 	if (p->is_write)
 		vcpu_sys_reg(vcpu, PMSELR_EL0) = p->regval;
 	else
@@ -504,6 +541,9 @@ static bool access_pmceid(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 
 	BUG_ON(p->is_write);
 
+	if (pmu_access_el0_disabled(vcpu))
+		return false;
+
 	if (!(p->Op2 & 1))
 		asm volatile("mrs %0, pmceid0_el0\n" : "=r" (pmceid));
 	else
@@ -538,16 +578,25 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
 	if (r->CRn == 9 && r->CRm == 13) {
 		if (r->Op2 == 2) {
 			/* PMXEVCNTR_EL0 */
+			if (pmu_access_event_counter_el0_disabled(vcpu))
+				return false;
+
 			idx = vcpu_sys_reg(vcpu, PMSELR_EL0)
 			      & ARMV8_PMU_COUNTER_MASK;
 		} else if (r->Op2 == 0) {
 			/* PMCCNTR_EL0 */
+			if (pmu_access_cycle_counter_el0_disabled(vcpu))
+				return false;
+
 			idx = ARMV8_PMU_CYCLE_IDX;
 		} else {
 			BUG();
 		}
 	} else if (r->CRn == 14 && (r->CRm & 12) == 8) {
 		/* PMEVCNTRn_EL0 */
+		if (pmu_access_event_counter_el0_disabled(vcpu))
+			return false;
+
 		idx = ((r->CRm & 3) << 3) | (r->Op2 & 7);
 	} else {
 		BUG();
@@ -556,10 +605,14 @@ static bool access_pmu_evcntr(struct kvm_vcpu *vcpu,
 	if (!pmu_counter_idx_valid(vcpu, idx))
 		return false;
 
-	if (p->is_write)
+	if (p->is_write) {
+		if (pmu_access_el0_disabled(vcpu))
+			return false;
+
 		kvm_pmu_set_counter_value(vcpu, idx, p->regval);
-	else
+	} else {
 		p->regval = kvm_pmu_get_counter_value(vcpu, idx);
+	}
 
 	return true;
 }
@@ -572,6 +625,9 @@ static bool access_pmu_evtyper(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_access_el0_disabled(vcpu))
+		return false;
+
 	if (r->CRn == 9 && r->CRm == 13 && r->Op2 == 1) {
 		/* PMXEVTYPER_EL0 */
 		idx = vcpu_sys_reg(vcpu, PMSELR_EL0) & ARMV8_PMU_COUNTER_MASK;
@@ -608,6 +664,9 @@ static bool access_pmcnten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_access_el0_disabled(vcpu))
+		return false;
+
 	mask = kvm_pmu_valid_counter_mask(vcpu);
 	if (p->is_write) {
 		val = p->regval & mask;
@@ -635,6 +694,9 @@ static bool access_pminten(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (!vcpu_mode_priv(vcpu))
+		return false;
+
 	if (p->is_write) {
 		u64 val = p->regval & mask;
 
@@ -659,6 +721,9 @@ static bool access_pmovs(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_access_el0_disabled(vcpu))
+		return false;
+
 	if (p->is_write) {
 		if (r->CRm & 0x2)
 			/* accessing PMOVSSET_EL0 */
@@ -681,6 +746,9 @@ static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	if (!kvm_arm_pmu_v3_ready(vcpu))
 		return trap_raz_wi(vcpu, p, r);
 
+	if (pmu_write_swinc_el0_disabled(vcpu))
+		return false;
+
 	if (p->is_write) {
 		mask = kvm_pmu_valid_counter_mask(vcpu);
 		kvm_pmu_software_increment(vcpu, p->regval & mask);
@@ -690,6 +758,26 @@ static bool access_pmswinc(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
 	return false;
 }
 
+static bool access_pmuserenr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
+			     const struct sys_reg_desc *r)
+{
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return trap_raz_wi(vcpu, p, r);
+
+	if (p->is_write) {
+		if (!vcpu_mode_priv(vcpu))
+			return false;
+
+		vcpu_sys_reg(vcpu, PMUSERENR_EL0) = p->regval
+						    & ARMV8_PMU_USERENR_MASK;
+	} else {
+		p->regval = vcpu_sys_reg(vcpu, PMUSERENR_EL0)
+			    & ARMV8_PMU_USERENR_MASK;
+	}
+
+	return true;
+}
+
 /* Silly macro to expand the DBG{BCR,BVR,WVR,WCR}n_EL1 registers in one go */
 #define DBG_BCR_BVR_WCR_WVR_EL1(n)					\
 	/* DBGBVRn_EL1 */						\
@@ -919,9 +1007,12 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 	/* PMXEVCNTR_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1101), Op2(0b010),
 	  access_pmu_evcntr },
-	/* PMUSERENR_EL0 */
+	/* PMUSERENR_EL0
+	 * This register resets as unknown in 64bit mode while it resets as zero
+	 * in 32bit mode. Here we choose to reset it as zero for consistency.
+	 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b000),
-	  trap_raz_wi },
+	  access_pmuserenr, reset_val, PMUSERENR_EL0, 0 },
 	/* PMOVSSET_EL0 */
 	{ Op0(0b11), Op1(0b011), CRn(0b1001), CRm(0b1110), Op2(0b011),
 	  access_pmovs, reset_unknown, PMOVSSET_EL0 },
@@ -1246,7 +1337,7 @@ static const struct sys_reg_desc cp15_regs[] = {
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 0), access_pmu_evcntr },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 1), access_pmu_evtyper },
 	{ Op1( 0), CRn( 9), CRm(13), Op2( 2), access_pmu_evcntr },
-	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), trap_raz_wi },
+	{ Op1( 0), CRn( 9), CRm(14), Op2( 0), access_pmuserenr },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 1), access_pminten },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 2), access_pminten },
 	{ Op1( 0), CRn( 9), CRm(14), Op2( 3), access_pmovs },
-- 
2.0.4




From zhaoshenglong at huawei.com  Tue Feb 23 21:08:35 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Wed, 24 Feb 2016 13:08:35 +0800
Subject: [PATCH v13 15/20] KVM: ARM64: Add PMU overflow interrupt routing
In-Reply-To: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456290520-10012-16-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When calling perf_event_create_kernel_counter to create perf_event,
assign a overflow handler. Then when the perf event overflows, set the
corresponding bit of guest PMOVSSET register. If this counter is enabled
and its interrupt is enabled as well, kick the vcpu to sync the
interrupt.

On VM entry, if there is counter overflowed, inject the interrupt with
the level set to 1. Otherwise, inject the interrupt with the level set
to 0.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm/kvm/arm.c    |  2 ++
 include/kvm/arm_pmu.h |  3 +++
 virt/kvm/arm/pmu.c    | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dda1959..f54264c 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -28,6 +28,7 @@
 #include <linux/sched.h>
 #include <linux/kvm.h>
 #include <trace/events/kvm.h>
+#include <kvm/arm_pmu.h>
 
 #define CREATE_TRACE_POINTS
 #include "trace.h"
@@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
 		 * non-preemptible context.
 		 */
 		preempt_disable();
+		kvm_pmu_flush_hwstate(vcpu);
 		kvm_timer_flush_hwstate(vcpu);
 		kvm_vgic_flush_hwstate(vcpu);
 
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 8bc92d1..0aed4d4 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -35,6 +35,7 @@ struct kvm_pmu {
 	int irq_num;
 	struct kvm_pmc pmc[ARMV8_PMU_MAX_COUNTERS];
 	bool ready;
+	bool irq_level;
 };
 
 #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
@@ -44,6 +45,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
 void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
@@ -67,6 +69,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
 static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index cda869c..1cd4214 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -21,6 +21,7 @@
 #include <linux/perf_event.h>
 #include <asm/kvm_emulate.h>
 #include <kvm/arm_pmu.h>
+#include <kvm/arm_vgic.h>
 
 /**
  * kvm_pmu_get_counter_value - get PMU counter value
@@ -181,6 +182,53 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
 }
 
 /**
+ * kvm_pmu_flush_hwstate - flush pmu state to cpu
+ * @vcpu: The vcpu pointer
+ *
+ * Inject virtual PMU IRQ if IRQ is pending for this cpu.
+ */
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
+{
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	bool overflow;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return;
+
+	overflow = !!kvm_pmu_overflow_status(vcpu);
+	if (pmu->irq_level != overflow) {
+		pmu->irq_level = overflow;
+		kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
+				    pmu->irq_num, overflow);
+	}
+}
+
+static inline struct kvm_vcpu *kvm_pmc_to_vcpu(struct kvm_pmc *pmc)
+{
+	struct kvm_pmu *pmu;
+	struct kvm_vcpu_arch *vcpu_arch;
+
+	pmc -= pmc->idx;
+	pmu = container_of(pmc, struct kvm_pmu, pmc[0]);
+	vcpu_arch = container_of(pmu, struct kvm_vcpu_arch, pmu);
+	return container_of(vcpu_arch, struct kvm_vcpu, arch);
+}
+
+/**
+ * When perf event overflows, call kvm_pmu_overflow_set to set overflow status.
+ */
+static void kvm_pmu_perf_overflow(struct perf_event *perf_event,
+				  struct perf_sample_data *data,
+				  struct pt_regs *regs)
+{
+	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+	struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
+	int idx = pmc->idx;
+
+	kvm_pmu_overflow_set(vcpu, BIT(idx));
+}
+
+/**
  * kvm_pmu_software_increment - do software increment
  * @vcpu: The vcpu pointer
  * @val: the value guest writes to PMSWINC register
@@ -291,7 +339,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 	/* The initial sample period (overflow count) of an event. */
 	attr.sample_period = (-counter) & pmc->bitmask;
 
-	event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
+	event = perf_event_create_kernel_counter(&attr, -1, current,
+						 kvm_pmu_perf_overflow, pmc);
 	if (IS_ERR(event)) {
 		pr_err_once("kvm: pmu event creation failed %ld\n",
 			    PTR_ERR(event));
-- 
2.0.4




From kishon at ti.com  Tue Feb 23 22:09:26 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 24 Feb 2016 11:39:26 +0530
Subject: [PATCH 0/5] Modularize PCI_DW related drivers.
In-Reply-To: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
References: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
Message-ID: <56CD4916.3050904@ti.com>

Hi,

On Monday 08 February 2016 05:30 AM, Paul Gortmaker wrote:
> In a recent patch series that aimed to remove code related to module
> unload for PCI support that was simply non modular, the discussion
> led to people wanting to keep the code and push towards taking the
> steps needed to support moving it towards tristate instead[1].
> 
> Here, we take step one, which is simply making the Kconfig change
> and then dealing with any build fallout or modpost fallout.  What
> amounts to essentially a sanity build test.  To be clear, these
> have not been runtime validated; that will need to be done by those
> with access to real hardware.  However, the changes are not anything
> that should disrupt any existing built-in validation, so real world
> users should not be impacted by this change.
> 
> We start with a smaller family of drivers; those that actively select
> PCI_DW, as a nice self contained group to test the waters and see if
> everyone is still good with this approach before investing more time
> on a wider scale to other pci/host/ code blocks.
> 
> As such the drivers here share a dependency on having the same group
> of functions exported in order to successfully complete modpost.
> 
> In addition, we have to stray outside drivers/pci to add exports
> in two places; once for an ARM fault handler, and once for an OF
> variable.
> 
> The pci-keystone-dw.c instance was handled separately because it
> consists of two source files that need their own group of driver
> specific exports above and beyond the "shared" ones.
> 
> Then we convert the Kconfig for all remaining at once; we could have
> done it on a per driver basis for ease of revert if anyone really
> objects, but since it would be a one line change, that seemed like
> not a real concern.
> 
> Build testing was done on the linux-next tree for arm allmodconfig.

I took these patches and gave a test with DRA7xx board. As expected there was
no issues when the driver was built-in. However when I tried to rmmod/modprobe
I got this error [2].

Thanks
Kishon

[2] -> http://pastebin.ubuntu.com/15185894/
> 
> [1] https://lkml.kernel.org/r/20160108203102.GH5354 at localhost
> 


From kishon at ti.com  Tue Feb 23 22:21:21 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Wed, 24 Feb 2016 11:51:21 +0530
Subject: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset
In-Reply-To: <alpine.DEB.2.02.1602231827300.27173@utopia.booyaka.com>
References: <1452780672-14339-1-git-send-email-kishon@ti.com>
 <1452780672-14339-4-git-send-email-kishon@ti.com>
 <20160127173104.GQ19432@atomide.com> <56A90971.4020409@ti.com>
 <20160127185649.GV19432@atomide.com> <56A94FB7.6020903@ti.com>
 <20160128183156.GH19432@atomide.com> <56B087AD.4000505@ti.com>
 <alpine.DEB.2.02.1602080208070.2182@utopia.booyaka.com>
 <56B900E9.9040306@ti.com>
 <alpine.DEB.2.02.1602090846480.2906@utopia.booyaka.com>
 <56BA2495.9020407@ti.com>
 <alpine.DEB.2.02.1602091932160.2906@utopia.booyaka.com>
 <56BA958A.1020503@ti.com> <56BACCDB.2070507@ti.com>
 <alpine.DEB.2.02.1602111921090.20757@utopia.booyaka.com>
 <56BD8091.4090007@ti.com> <56BE1454.3030002@ti.com> <56C5D377.50901@ti.com>
 <56CAA82D.6000507@ti.com>
 <alpine.DEB.2.02.1602220631300.3418@utopia.booyaka.com>
 <56CADB23.8020202@ti.com> <56CC490F.3040301@ti.com>
 <alpine.DEB.2.02.1602231827300.27173@utopia.booyaka.com>
Message-ID: <56CD4BE1.3010701@ti.com>

Hi Paul,

On Tuesday 23 February 2016 11:58 PM, Paul Walmsley wrote:
> Kishon
> 
> On Tue, 23 Feb 2016, Kishon Vijay Abraham I wrote:
> 
>> On Monday 22 February 2016 03:25 PM, Kishon Vijay Abraham I wrote:
>>> On Monday 22 February 2016 12:01 PM, Paul Walmsley wrote:
>>>> On Mon, 22 Feb 2016, Kishon Vijay Abraham I wrote:
>>>>> On Thursday 18 February 2016 07:51 PM, Sekhar Nori wrote:
>>>>>> On Friday 12 February 2016 10:50 PM, Suman Anna wrote:
>>>>>>> Will you be following up with above suggestion since Kishon is gonna be out?
>>>>>>
>>>>>> Alright, noticed this action for me :) Went through the thread, and 
>>>>>> looks like this is what we want to see?
>>>>>>
>>>>>> Thanks,
>>>>>> Sekhar
>>>>>>
>>>>>> ---8<---
>>>>>> From e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19 Mon Sep 17 00:00:00 2001
>>>>>> Message-Id: <e3ba368f2235e1bf38a22ba8ea4e5c12aaafda19.1455803758.git.nsekhar at ti.com>
>>>>>> From: Sekhar Nori <nsekhar at ti.com>
>>>>>> Date: Thu, 18 Feb 2016 16:49:56 +0530
>>>>>> Subject: [PATCH 1/1] ARM: DRA7: hwmod: Add custom reset handler for PCIeSS
>>>>>>
>>>>>> Add a custom reset handler for DRA7x PCIeSS. This
>>>>>> handler is required to deassert PCIe hardreset lines
>>>>>> after they have been asserted.
>>>>>>
>>>>>> This enables the PCIe driver to access registers after
>>>>>> PCIeSS has been runtime enabled without having to
>>>>>> deassert hardreset lines itself.
>>>>>>
>>>>>> With this patch applied, used lspci to make sure
>>>>>> connected PCIe device enumerates on DRA74x and DRA72x
>>>>>> EVMs.
>>>>>>
>>>>>> Signed-off-by: Sekhar Nori <nsekhar at ti.com>
>>>>>> ---
>>>>>> Applies to tag for-v4.6/omap-hwmod-a of Paul W's tree.
>>>>>>
>>>>>>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 23 +++++++++++++++++++++++
>>>>>>  1 file changed, 23 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>>>>> index b61355e2a771..252b74633e31 100644
>>>>>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>>>>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>>>>> @@ -1526,8 +1526,31 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
>>>>>>   *
>>>>>>   */
>>>>>>  
>>>>>> +/*
>>>>>> + * As noted in documentation for _reset() in omap_hwmod.c, the stock reset
>>>>>> + * functionality of OMAP HWMOD layer does not deassert the hardreset lines
>>>>>> + * associated with an IP automatically leaving the driver to handle that
>>>>>> + * by itself. This does not work for PCIeSS which needs the reset lines
>>>>>> + * deasserted for the driver to start accessing registers.
>>>>>> + *
>>>>>> + * We use a PCIeSS HWMOD class specific reset handler to deassert the hardreset
>>>>>> + * lines after asserting them.
>>>>>> + */
>>>>>> +static int dra7xx_pciess_reset(struct omap_hwmod *oh)
>>>>>> +{
>>>>>> +	int i;
>>>>>> +
>>>>>> +	for (i = 0; i < oh->rst_lines_cnt; i++) {
>>>>>> +		omap_hwmod_assert_hardreset(oh, oh->rst_lines[i].name);
>>>>>> +		omap_hwmod_deassert_hardreset(oh, oh->rst_lines[i].name);
>>>>>> +	}
>>>>>> +
>>>>>> +	return 0;
>>>>>> +}
>>>>>> +
>>>>>>  static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {
>>>>>>  	.name	= "pcie",
>>>>>> +	.reset	= dra7xx_pciess_reset,
>>>>>>  };
>>>>>
>>>>> Thanks for the patch.
>>>>
>>>> Could you please test the bind/unbind functionality just to make sure it 
>>>> works?
>>>
>>> The pci-dra7xx driver neither expose the bind/unbind sysfs entry nor can be
>>> built as module.
>>>
>>> However I hacked the pci-dra7xx driver to be built as module [and reverted
>>> Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe error
>>> and driver unbind")] and I don't see an abort when the PCI registers are
>>> accessed after rmmod/modprobe cycle (that was the issue that Sekhar's patch
>>> tried to solve). However PCI as such doesn't work after rmmod/modprobe cycle
>>> [1], but this is a different issue most likely in PCIe core and has to debugged.
>>>
>>> In summary, there are other issues in PCI across rmmod/modprobe cycle but the
>>> reset of pci-dra7xx happens fine with this patch.
>>
>> Do you expect any other testing from me?
> 
> No I think that's sufficient for the time being, thanks - but, two 
> questions:
> 
> 1. Can I add your Tested-by: ?

sure..
Tested-by: Kishon Vijay Abraham I <kishon at ti.com>

> 
> 2. Are you going to follow up with these PCIe core issues with the PCIe 
> core developers?

yeah, I see efforts have already started to convert the PCI drivers from
built-in to module [1] and issues arising out of that will be debugged.

Thanks
Kishon

[1] -> http://lkml.iu.edu/hypermail/linux/kernel/1602.0/06011.html
> 
> 
> - Paul
> 


From gabriele.paoloni at huawei.com  Tue Feb 23 22:46:09 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Wed, 24 Feb 2016 06:46:09 +0000
Subject: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
 HiSilicon SoCs Host Controllers
In-Reply-To: <20160224011418.GB13026@localhost>
References: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
 <1455039260-6040-4-git-send-email-gabriele.paoloni@huawei.com>
 <20160209182429.GD4348@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1591@lhreml503-mbs>
 <20160210111234.GC2632@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1D30@lhreml503-mbs>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECC5F00@lhreml503-mbs>
 <20160224011418.GB13026@localhost>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECCAD6A@lhreml503-mbs>


Hi Bjorn, many thanks for replying

> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas at kernel.org]
> Sent: 24 February 2016 09:14
> To: Gabriele Paoloni
> Cc: 'Mark Rutland'; Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong
> (C); Linuxarm; qiujiang; 'bhelgaas at google.com'; 'arnd at arndb.de';
> 'Lorenzo.Pieralisi at arm.com'; 'tn at semihalf.com'; 'linux-
> pci at vger.kernel.org'; 'linux-kernel at vger.kernel.org'; xuwei (O);
> 'linux-acpi at vger.kernel.org'; 'jcm at redhat.com'; zhangjukuo; Liguozhu
> (Kenneth); 'linux-arm-kernel at lists.infradead.org'
> Subject: Re: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
> HiSilicon SoCs Host Controllers
> 
> On Tue, Feb 23, 2016 at 02:47:22AM +0000, Gabriele Paoloni wrote:
> > > -----Original Message-----
> > > From: Gabriele Paoloni
> > > Sent: 10 February 2016 22:45
> > > To: Mark Rutland
> > > Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C); Linuxarm;
> > > qiujiang; bhelgaas at google.com; arnd at arndb.de;
> Lorenzo.Pieralisi at arm.com;
> > > tn at semihalf.com; linux-pci at vger.kernel.org; linux-
> > > kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> > > jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth); linux-arm-
> > > kernel at lists.infradead.org
> > > Subject: RE: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support
> for
> > > HiSilicon SoCs Host Controllers
> > >
> > > > -----Original Message-----
> > > > From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> > > > owner at vger.kernel.org] On Behalf Of Mark Rutland
> > > > Sent: 10 February 2016 11:13
> > > > To: Gabriele Paoloni
> > > > Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C);
> Linuxarm;
> > > > qiujiang; bhelgaas at google.com; arnd at arndb.de;
> > > > Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-
> pci at vger.kernel.org;
> > > > linux-kernel at vger.kernel.org; xuwei (O); linux-
> acpi at vger.kernel.org;
> > > > jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth); linux-arm-
> > > > kernel at lists.infradead.org
> > > > Subject: Re: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support
> for
> > > > HiSilicon SoCs Host Controllers
> > > >
> > > > On Wed, Feb 10, 2016 at 09:52:36AM +0000, Gabriele Paoloni wrote:
> > > > > Hi Mark
> > > > >
> > > > > > On Tue, Feb 09, 2016 at 05:34:20PM +0000, Gabriele Paoloni
> wrote:
> > > > > > > From: gabriele paoloni <gabriele.paoloni at huawei.com>
> > > > > > > +/*
> > > > > > > + * Retrieve rc_dbi base and size from _DSD
> > > > > > > + * Name (_DSD, Package () {
> > > > > > > + *	ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > > > > > > + *	Package () {
> > > > > > > + *	Package () {"rc-dbi", Package () { 0x0, 0xb0080000,
> 0x0,
> > > > 0x10000
> > > > > > }},
> > > > > > > + *	}
> > > > > > > + *	})
> > > > > > > + */
> > > > > >
> > > > > > As above, this does not look right. ACPI has standard
> mechanisms
> > > > for
> > > > > > describing addresses. Making something up like this is not a
> good
> > > > idea.
> > > > >
> > > > > I am quite new to ACPI, may I ask you to explain a bit?
> > > >
> > > > ACPI has standard mechanisms for describing certain resources,
> and
> > > > these
> > > > should not be described in _DSD. Memory or IO address regions are
> > > such
> > > > resources (in _CRS, IIRC), and should not be described in _DSD.
> > >
> > > Hi Mark,
> > >
> > > In my case I think in need to look into the MCFG object as the
> problem
> > > I have is RC using a different range than the rest of the hierarchy.
> > >
> > > I'll investigate this and try to come with a solution in v4
> >
> > I have looked into this and in our case we cannot use the
> > standard MCFG object to pass the RC config space addresses.
> >
> > The reason is that in our HW we have the config base addresses of the
> > root complex ports that are less than 0x100000 byte distant one from
> > the other as we only map the first 0x10000 bytes.
> 
> The ECAM spec requires 4096 bytes per function, 8 functions per
> device, 32 devices per bus, which means you need 0x100000 bytes of
> address space per bus.  If your device doesn't supply that, it doesn't
> really implement ECAM, and you probably can't use the standard ways of
> describing ECAM (MCFG, _CBA).

Correct, our host bridge is non ECAM only for the RC bus config space;
for any other bus underneath the root bus we support ECAM access, so
we need a quirk for the RC config rd/wr  

> 
> > Now the MCFG acpi framework always fix the MCFG resource size to
> 0x100000
> > for each bus; therefore if we pass our RC addresses through MCFG we
> end
> > up with a resource conflict.
> >
> > To give you a practical example we are in a situation where we have:
> >
> > port0: [0x00000000b0080000 - 0x00000000b0080000 + 0x10000]
> > port1: [0x00000000b0090000 - 0x00000000b0090000 + 0x10000]
> > port2: [0x00000000b00A0000 - 0x00000000b00A0000 + 0x10000]
> > port3: [0x00000000b00B0000 - 0x00000000b00B0000 + 0x10000]
> >
> > So if we pass the base addresses through MCFG the resources
> > will overlap as MCFG will consider 0x100000 size for each base
> > address of the root complex (only the RC bus uses that address)
> >
> > So far I do not see many option other than using _DSD to pass
> > these RC config base addresses.
> 
> I don't want to take over Mark's discussion, but I really do not think
> _DSD is the correct way to fix this.  _CRS is like a generalized PCI
> BAR.  A PCI device is only allowed to respond to address space
> reported via a BAR.  An ACPI device is only allowed to respond to
> address space reported via _CRS.  Those are important rules because
> they mean we can manage address space with generic code instead of
> device-specific code.

>From what I see in 
http://lxr.free-electrons.com/source/drivers/acpi/pci_root.c#L723
acpi_pci_probe_root_resources() parses the _CRS method and
it only works for MEM and IO resources, so I don't think it is 
right to pass a config space address by _CRS or to modify the 
current ACPI framework to support this.

On the other side, since this is an exception only for the config
space address of our host controller (as said before all the buses
below the root one support ECAM), I think that it is right to put
this address as a device specific data (in fact the rest of the
config space addresses will be parsed from MCFG).
I thought the purpose of the quirks from Nowicki patchset were meant
to handle this sort of special cases...


Thanks and Regards

Gab

> 
> Bjorn


From dave.long at linaro.org  Tue Feb 23 22:56:52 2016
From: dave.long at linaro.org (David Long)
Date: Wed, 24 Feb 2016 01:56:52 -0500
Subject: [PATCH 5/8] arm64: kprobes instruction simulation support
In-Reply-To: <56C720F0.9080108@arm.com>
References: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
 <1455839301-26464-6-git-send-email-dave.long@linaro.org>
 <56C720F0.9080108@arm.com>
Message-ID: <56CD5434.30108@linaro.org>

On 02/19/2016 09:04 AM, Marc Zyngier wrote:
> Hi David,
>
> On 18/02/16 23:48, David Long wrote:
>> From: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>
>>
>> Kprobes needs simulation of instructions that cannot be stepped
>> from different memory location, e.g.: those instructions
>> that uses PC-relative addressing. In simulation, the behaviour
>> of the instruction is implemented using a copy of pt_regs.
>>
>> Following instruction catagories are simulated:
>>   - All branching instructions(conditional, register, and immediate)
>>   - Literal access instructions(load-literal, adr/adrp)
>>
>> Conditional execution is limited to branching instructions in
>> ARM v8. If conditions at PSTATE do not match the condition fields
>> of opcode, the instruction is effectively NOP. Kprobes considers
>> this case as 'miss'.
>>
>> This code also replaces the use of arch/arm/opcodes.c for
>> arm_check_condition().
>>
>> Thanks to Will Cohen for assorted suggested changes.
>>
>> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>
>> Signed-off-by: William Cohen <wcohen at redhat.com>
>> Signed-off-by: David A. Long <dave.long at linaro.org>
>> ---
>>   arch/arm64/include/asm/insn.h            |   3 +
>>   arch/arm64/include/asm/probes.h          |   5 +-
>>   arch/arm64/kernel/Makefile               |   6 +-
>>   arch/arm64/kernel/insn.c                 | 111 ++++++++++++++++++
>>   arch/arm64/kernel/kprobes-arm64.c        |  29 +++++
>>   arch/arm64/kernel/kprobes.c              |  32 +++++-
>>   arch/arm64/kernel/probes-simulate-insn.c | 187 +++++++++++++++++++++++++++++++
>>   arch/arm64/kernel/probes-simulate-insn.h |  30 +++++
>>   8 files changed, 395 insertions(+), 8 deletions(-)
>>   create mode 100644 arch/arm64/kernel/probes-simulate-insn.c
>>   create mode 100644 arch/arm64/kernel/probes-simulate-insn.h
>>
>> diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
>> index cf43773..2cac976 100644
>> --- a/arch/arm64/include/asm/insn.h
>> +++ b/arch/arm64/include/asm/insn.h
>> @@ -407,6 +407,9 @@ u32 aarch64_insn_extract_system_reg(u32 insn);
>>   u32 aarch32_insn_extract_reg_num(u32 insn, int offset);
>>   u32 aarch32_insn_mcr_extract_opc2(u32 insn);
>>   u32 aarch32_insn_mcr_extract_crm(u32 insn);
>> +
>> +typedef unsigned long (pstate_check_t)(unsigned long);
>> +
>>   #endif /* __ASSEMBLY__ */
>>
>>   #endif	/* __ASM_INSN_H */
>> diff --git a/arch/arm64/include/asm/probes.h b/arch/arm64/include/asm/probes.h
>> index c5fcbe6..d524f7d 100644
>> --- a/arch/arm64/include/asm/probes.h
>> +++ b/arch/arm64/include/asm/probes.h
>> @@ -15,11 +15,12 @@
>>   #ifndef _ARM_PROBES_H
>>   #define _ARM_PROBES_H
>>
>> +#include <asm/opcodes.h>
>> +
>>   struct kprobe;
>>   struct arch_specific_insn;
>>
>>   typedef u32 kprobe_opcode_t;
>> -typedef unsigned long (kprobes_pstate_check_t)(unsigned long);
>>   typedef void (kprobes_handler_t) (u32 opcode, long addr, struct pt_regs *);
>>
>>   enum pc_restore_type {
>> @@ -35,7 +36,7 @@ struct kprobe_pc_restore {
>>   /* architecture specific copy of original instruction */
>>   struct arch_specific_insn {
>>   	kprobe_opcode_t *insn;
>> -	kprobes_pstate_check_t *pstate_cc;
>> +	pstate_check_t *pstate_cc;
>>   	kprobes_handler_t *handler;
>>   	/* restore address after step xol */
>>   	struct kprobe_pc_restore restore;
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index 5b0ee7d..08325e5 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -26,8 +26,7 @@ $(obj)/%.stub.o: $(obj)/%.o FORCE
>>   	$(call if_changed,objcopy)
>>
>>   arm64-obj-$(CONFIG_COMPAT)		+= sys32.o kuser32.o signal32.o 	\
>> -					   sys_compat.o entry32.o		\
>> -					   ../../arm/kernel/opcodes.o
>> +					   sys_compat.o entry32.o
>>   arm64-obj-$(CONFIG_FUNCTION_TRACER)	+= ftrace.o entry-ftrace.o
>>   arm64-obj-$(CONFIG_MODULES)		+= arm64ksyms.o module.o
>>   arm64-obj-$(CONFIG_PERF_EVENTS)		+= perf_regs.o perf_callchain.o
>> @@ -37,7 +36,8 @@ arm64-obj-$(CONFIG_CPU_PM)		+= sleep.o suspend.o
>>   arm64-obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
>>   arm64-obj-$(CONFIG_JUMP_LABEL)		+= jump_label.o
>>   arm64-obj-$(CONFIG_KGDB)		+= kgdb.o
>> -arm64-obj-$(CONFIG_KPROBES)		+= kprobes.o kprobes-arm64.o
>> +arm64-obj-$(CONFIG_KPROBES)		+= kprobes.o kprobes-arm64.o		\
>> +					   probes-simulate-insn.o
>>   arm64-obj-$(CONFIG_EFI)			+= efi.o efi-entry.stub.o
>>   arm64-obj-$(CONFIG_PCI)			+= pci.o
>>   arm64-obj-$(CONFIG_ARMV8_DEPRECATED)	+= armv8_deprecated.o
>> diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
>> index 60c1c71..74a08db 100644
>> --- a/arch/arm64/kernel/insn.c
>> +++ b/arch/arm64/kernel/insn.c
>> @@ -30,6 +30,7 @@
>>   #include <asm/cacheflush.h>
>>   #include <asm/debug-monitors.h>
>>   #include <asm/fixmap.h>
>> +#include <asm/opcodes.h>
>>   #include <asm/insn.h>
>>
>>   #define AARCH64_INSN_SF_BIT	BIT(31)
>> @@ -1234,3 +1235,113 @@ u32 aarch32_insn_mcr_extract_crm(u32 insn)
>>   {
>>   	return insn & CRM_MASK;
>>   }
>> +
>> +#define	ARM_OPCODE_CONDITION_UNCOND	0xf
>> +
>> +static unsigned long __kprobes __check_eq(unsigned long pstate)
>> +{
>> +	return pstate & PSR_Z_BIT;
>> +}
>> +
>> +static unsigned long __kprobes __check_ne(unsigned long pstate)
>> +{
>> +	return (~pstate) & PSR_Z_BIT;
>> +}
>> +
>> +static unsigned long __kprobes __check_cs(unsigned long pstate)
>> +{
>> +	return pstate & PSR_C_BIT;
>> +}
>> +
>> +static unsigned long __kprobes __check_cc(unsigned long pstate)
>> +{
>> +	return (~pstate) & PSR_C_BIT;
>> +}
>> +
>> +static unsigned long __kprobes __check_mi(unsigned long pstate)
>> +{
>> +	return pstate & PSR_N_BIT;
>> +}
>> +
>> +static unsigned long __kprobes __check_pl(unsigned long pstate)
>> +{
>> +	return (~pstate) & PSR_N_BIT;
>> +}
>> +
>> +static unsigned long __kprobes __check_vs(unsigned long pstate)
>> +{
>> +	return pstate & PSR_V_BIT;
>> +}
>> +
>> +static unsigned long __kprobes __check_vc(unsigned long pstate)
>> +{
>> +	return (~pstate) & PSR_V_BIT;
>> +}
>> +
>> +static unsigned long __kprobes __check_hi(unsigned long pstate)
>> +{
>> +	pstate &= ~(pstate >> 1);	/* PSR_C_BIT &= ~PSR_Z_BIT */
>> +	return pstate & PSR_C_BIT;
>> +}
>> +
>> +static unsigned long __kprobes __check_ls(unsigned long pstate)
>> +{
>> +	pstate &= ~(pstate >> 1);	/* PSR_C_BIT &= ~PSR_Z_BIT */
>> +	return (~pstate) & PSR_C_BIT;
>> +}
>> +
>> +static unsigned long __kprobes __check_ge(unsigned long pstate)
>> +{
>> +	pstate ^= (pstate << 3);	/* PSR_N_BIT ^= PSR_V_BIT */
>> +	return (~pstate) & PSR_N_BIT;
>> +}
>> +
>> +static unsigned long __kprobes __check_lt(unsigned long pstate)
>> +{
>> +	pstate ^= (pstate << 3);	/* PSR_N_BIT ^= PSR_V_BIT */
>> +	return pstate & PSR_N_BIT;
>> +}
>> +
>> +static unsigned long __kprobes __check_gt(unsigned long pstate)
>> +{
>> +	/*PSR_N_BIT ^= PSR_V_BIT */
>> +	unsigned long temp = pstate ^ (pstate << 3);
>> +
>> +	temp |= (pstate << 1);	/*PSR_N_BIT |= PSR_Z_BIT */
>> +	return (~temp) & PSR_N_BIT;
>> +}
>> +
>> +static unsigned long __kprobes __check_le(unsigned long pstate)
>> +{
>> +	/*PSR_N_BIT ^= PSR_V_BIT */
>> +	unsigned long temp = pstate ^ (pstate << 3);
>> +
>> +	temp |= (pstate << 1);	/*PSR_N_BIT |= PSR_Z_BIT */
>> +	return temp & PSR_N_BIT;
>> +}
>> +
>> +static unsigned long __kprobes __check_al(unsigned long pstate)
>> +{
>> +	return true;
>> +}
>
> This is rather inconsistent. Either you're returning always returning a
> boolean, or returning a long that has a meaningful bit position in it.
> I'd vote for the first case, and the conversion of all __check_* functions.
>

I see your point.  Changes made.

>> +
>> +pstate_check_t * const opcode_condition_checks[16] = {
>> +	&__check_eq, &__check_ne, &__check_cs, &__check_cc,
>> +	&__check_mi, &__check_pl, &__check_vs, &__check_vc,
>> +	&__check_hi, &__check_ls, &__check_ge, &__check_lt,
>> +	&__check_gt, &__check_le, &__check_al, &__check_al
>
> You can probably loose the '&'.
>

Yup.  Changed.

>> +};
>> +
>> +asmlinkage unsigned int __kprobes arm_check_condition(u32 opcode, u32 psr)
>
> Why asmlinkage? This function is never called from assembly code on arm64.
>

This comes from the 32-bit ARM code that tests the condition from 
entry.S.  We include arch/arm/include/asm/opcodes.h in 
arch/arm64/include/asm/opcodes.h so it gets declared there with 
asmlinkage. I can remove the asmlinkage in the actual function 
definition and it still compiles but I'm not sure that is kosher. Will 
Deacon was advocating getting rid of the include of the 32-bit header 
file but it looked to me like this would mean a lot of duplicated 
defines and the work would be mostly unrelated to kprobes.

>> +{
>> +	u32 cc_bits  = opcode >> 28;
>> +
>> +	if (cc_bits != ARM_OPCODE_CONDITION_UNCOND) {
>> +		if ((*opcode_condition_checks[cc_bits])(psr))
>> +			return ARM_OPCODE_CONDTEST_PASS;
>> +		else
>> +			return ARM_OPCODE_CONDTEST_FAIL;
>> +	}
>> +	return ARM_OPCODE_CONDTEST_UNCOND;
>> +}
>> +EXPORT_SYMBOL_GPL(arm_check_condition);
>
> Why do we need this to be exported at all? Also, it'd be better located
> together with the deprecated instruction handling, possibly in a
> separate patch (nothing uses this function in this patch).
>

I've made the function static and moved it to armv8_deprecated.  I have 
to leave the static functions that test the individual conditions and 
the global array of pointers to them outside of the conditionally 
compiled armv8_deprecated.c as they have to always be present for 
kprobes to simulate a conditional branch.

>> diff --git a/arch/arm64/kernel/kprobes-arm64.c b/arch/arm64/kernel/kprobes-arm64.c
>> index e07727a..487238a 100644
>> --- a/arch/arm64/kernel/kprobes-arm64.c
>> +++ b/arch/arm64/kernel/kprobes-arm64.c
>> @@ -21,6 +21,7 @@
>>   #include <asm/sections.h>
>>
>>   #include "kprobes-arm64.h"
>> +#include "probes-simulate-insn.h"
>>
>>   static bool __kprobes aarch64_insn_is_steppable(u32 insn)
>>   {
>> @@ -62,8 +63,36 @@ arm_probe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi)
>>   	 */
>>   	if (aarch64_insn_is_steppable(insn))
>>   		return INSN_GOOD;
>> +
>> +	if (aarch64_insn_is_bcond(insn)) {
>> +		asi->handler = simulate_b_cond;
>> +	} else if (aarch64_insn_is_cbz(insn) ||
>> +	    aarch64_insn_is_cbnz(insn)) {
>> +		asi->handler = simulate_cbz_cbnz;
>> +	} else if (aarch64_insn_is_tbz(insn) ||
>> +	    aarch64_insn_is_tbnz(insn)) {
>> +		asi->handler = simulate_tbz_tbnz;
>> +	} else if (aarch64_insn_is_adr_adrp(insn))
>> +		asi->handler = simulate_adr_adrp;
>> +	else if (aarch64_insn_is_b(insn) ||
>> +	    aarch64_insn_is_bl(insn))
>> +		asi->handler = simulate_b_bl;
>> +	else if (aarch64_insn_is_br(insn) ||
>> +	    aarch64_insn_is_blr(insn) ||
>> +	    aarch64_insn_is_ret(insn))
>> +		asi->handler = simulate_br_blr_ret;
>> +	else if (aarch64_insn_is_ldr_lit(insn))
>> +		asi->handler = simulate_ldr_literal;
>> +	else if (aarch64_insn_is_ldrsw_lit(insn))
>> +		asi->handler = simulate_ldrsw_literal;
>>   	else
>> +		/*
>> +		 * Instruction cannot be stepped out-of-line and we don't
>> +		 * (yet) simulate it.
>> +		 */
>>   		return INSN_REJECTED;
>> +
>> +	return INSN_GOOD_NO_SLOT;
>>   }
>>
>>   static bool __kprobes
>> diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
>> index 8db71a4..52f6c3d 100644
>> --- a/arch/arm64/kernel/kprobes.c
>> +++ b/arch/arm64/kernel/kprobes.c
>> @@ -40,6 +40,9 @@ void jprobe_return_break(void);
>>   DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
>>   DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
>>
>> +static void __kprobes
>> +post_kprobe_handler(struct kprobe_ctlblk *, struct pt_regs *);
>> +
>>   static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
>>   {
>>   	/* prepare insn slot */
>> @@ -57,6 +60,24 @@ static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
>>   	p->ainsn.restore.type = RESTORE_PC;
>>   }
>>
>> +static void __kprobes arch_prepare_simulate(struct kprobe *p)
>> +{
>> +	/* This instructions is not executed xol. No need to adjust the PC */
>> +	p->ainsn.restore.addr = 0;
>> +	p->ainsn.restore.type = NO_RESTORE;
>> +}
>> +
>> +static void __kprobes arch_simulate_insn(struct kprobe *p, struct pt_regs *regs)
>> +{
>> +	struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>> +
>> +	if (p->ainsn.handler)
>> +		p->ainsn.handler((u32)p->opcode, (long)p->addr, regs);
>> +
>> +	/* single step simulated, now go for post processing */
>> +	post_kprobe_handler(kcb, regs);
>> +}
>> +
>>   int __kprobes arch_prepare_kprobe(struct kprobe *p)
>>   {
>>   	unsigned long probe_addr = (unsigned long)p->addr;
>> @@ -73,7 +94,8 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
>>   		return -EINVAL;
>>
>>   	case INSN_GOOD_NO_SLOT:	/* insn need simulation */
>> -		return -EINVAL;
>> +		p->ainsn.insn = NULL;
>> +		break;
>>
>>   	case INSN_GOOD:	/* instruction uses slot */
>>   		p->ainsn.insn = get_insn_slot();
>> @@ -83,7 +105,10 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
>>   	};
>>
>>   	/* prepare the instruction */
>> -	arch_prepare_ss_slot(p);
>> +	if (p->ainsn.insn)
>> +		arch_prepare_ss_slot(p);
>> +	else
>> +		arch_prepare_simulate(p);
>>
>>   	return 0;
>>   }
>> @@ -225,7 +250,8 @@ static void __kprobes setup_singlestep(struct kprobe *p,
>>   		kernel_enable_single_step(regs);
>>   		instruction_pointer(regs) = slot;
>>   	} else	{
>> -		BUG();
>> +		/* insn simulation */
>> +		arch_simulate_insn(p, regs);
>>   	}
>>   }
>>
>> diff --git a/arch/arm64/kernel/probes-simulate-insn.c b/arch/arm64/kernel/probes-simulate-insn.c
>> new file mode 100644
>> index 0000000..dfcece9
>> --- /dev/null
>> +++ b/arch/arm64/kernel/probes-simulate-insn.c
>> @@ -0,0 +1,187 @@
>> +/*
>> + * arch/arm64/kernel/probes-simulate-insn.c
>> + *
>> + * Copyright (C) 2013 Linaro Limited.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * General Public License for more details.
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/kprobes.h>
>> +#include <linux/module.h>
>> +
>> +#include "probes-simulate-insn.h"
>> +
>> +#define sign_extend(x, signbit)		\
>> +	((x) | (0 - ((x) & (1 << (signbit)))))
>> +
>> +#define bbl_displacement(insn)		\
>> +	sign_extend(((insn) & 0x3ffffff) << 2, 27)
>> +
>> +#define bcond_displacement(insn)	\
>> +	sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
>> +
>> +#define cbz_displacement(insn)	\
>> +	sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
>> +
>> +#define tbz_displacement(insn)	\
>> +	sign_extend(((insn >> 5) & 0x3fff) << 2, 15)
>> +
>> +#define ldr_displacement(insn)	\
>> +	sign_extend(((insn >> 5) & 0x7ffff) << 2, 20)
>> +
>> +
>> +static unsigned long __kprobes check_cbz(u32 opcode, struct pt_regs *regs)
>> +{
>> +	int xn = opcode & 0x1f;
>> +
>> +	return (opcode & (1 << 31)) ?
>> +	    !(regs->regs[xn]) : !(regs->regs[xn] & 0xffffffff);
>> +}
>> +
>> +static unsigned long __kprobes check_cbnz(u32 opcode, struct pt_regs *regs)
>> +{
>> +	int xn = opcode & 0x1f;
>> +
>> +	return (opcode & (1 << 31)) ?
>> +	    (regs->regs[xn]) : (regs->regs[xn] & 0xffffffff);
>> +}
>> +
>> +static unsigned long __kprobes check_tbz(u32 opcode, struct pt_regs *regs)
>> +{
>> +	int xn = opcode & 0x1f;
>> +	int bit_pos = ((opcode & (1 << 31)) >> 26) | ((opcode >> 19) & 0x1f);
>> +
>> +	return !((regs->regs[xn] >> bit_pos) & 0x1);
>> +}
>> +
>> +static unsigned long __kprobes check_tbnz(u32 opcode, struct pt_regs *regs)
>> +{
>> +	int xn = opcode & 0x1f;
>> +	int bit_pos = ((opcode & (1 << 31)) >> 26) | ((opcode >> 19) & 0x1f);
>> +
>> +	return (regs->regs[xn] >> bit_pos) & 0x1;
>> +}
>
> Same remark as above: these should be returning a boolean value.
>

Yup.  Fixed.

>> +
>> +/*
>> + * instruction simulation functions
>> + */
>> +void __kprobes
>> +simulate_adr_adrp(u32 opcode, long addr, struct pt_regs *regs)
>> +{
>> +	long imm, xn, val;
>> +
>> +	xn = opcode & 0x1f;
>> +	imm = ((opcode >> 3) & 0x1ffffc) | ((opcode >> 29) & 0x3);
>> +	imm = sign_extend(imm, 20);
>> +	if (opcode & 0x80000000)
>> +		val = (imm<<12) + (addr & 0xfffffffffffff000);
>> +	else
>> +		val = imm + addr;
>> +
>> +	regs->regs[xn] = val;
>> +
>> +	instruction_pointer(regs) += 4;
>> +}
>> +
>> +void __kprobes
>> +simulate_b_bl(u32 opcode, long addr, struct pt_regs *regs)
>> +{
>> +	int disp = bbl_displacement(opcode);
>> +
>> +	/* Link register is x30 */
>> +	if (opcode & (1 << 31))
>> +		regs->regs[30] = addr + 4;
>> +
>> +	instruction_pointer(regs) = addr + disp;
>> +}
>> +
>> +void __kprobes
>> +simulate_b_cond(u32 opcode, long addr, struct pt_regs *regs)
>> +{
>> +	int disp = 4;
>> +
>> +	if (opcode_condition_checks[opcode & 0xf](regs->pstate & 0xffffffff))
>> +		disp = bcond_displacement(opcode);
>> +
>> +	instruction_pointer(regs) = addr + disp;
>> +}
>> +
>> +void __kprobes
>> +simulate_br_blr_ret(u32 opcode, long addr, struct pt_regs *regs)
>> +{
>> +	int xn = (opcode >> 5) & 0x1f;
>> +
>> +	/* Link register is x30 */
>> +	if (((opcode >> 21) & 0x3) == 1)
>> +		regs->regs[30] = addr + 4;
>> +
>> +	instruction_pointer(regs) = regs->regs[xn];
>> +}
>> +
>> +void __kprobes
>> +simulate_cbz_cbnz(u32 opcode, long addr, struct pt_regs *regs)
>> +{
>> +	int disp = 4;
>> +
>> +	if (opcode & (1 << 24)) {
>> +		if (check_cbnz(opcode, regs))
>> +			disp = cbz_displacement(opcode);
>> +	} else {
>> +		if (check_cbz(opcode, regs))
>> +			disp = cbz_displacement(opcode);
>> +	}
>> +	instruction_pointer(regs) = addr + disp;
>> +}
>> +
>> +void __kprobes
>> +simulate_tbz_tbnz(u32 opcode, long addr, struct pt_regs *regs)
>> +{
>> +	int disp = 4;
>> +
>> +	if (opcode & (1 << 24)) {
>> +		if (check_tbnz(opcode, regs))
>> +			disp = tbz_displacement(opcode);
>> +	} else {
>> +		if (check_tbz(opcode, regs))
>> +			disp = tbz_displacement(opcode);
>> +	}
>> +	instruction_pointer(regs) = addr + disp;
>> +}
>> +
>> +void __kprobes
>> +simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs)
>> +{
>> +	u64 *load_addr;
>> +	int xn = opcode & 0x1f;
>> +	int disp = ldr_displacement(opcode);
>> +
>> +	load_addr = (u64 *) (addr + disp);
>> +
>> +	if (opcode & (1 << 30))	/* x0-x31 */
>> +		regs->regs[xn] = *load_addr;
>> +	else			/* w0-w31 */
>> +		*(u32 *) (&regs->regs[xn]) = (*(u32 *) (load_addr));
>> +
>> +	instruction_pointer(regs) += 4;
>> +}
>> +
>> +void __kprobes
>> +simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs)
>> +{
>> +	s32 *load_addr;
>> +	int xn = opcode & 0x1f;
>> +	int disp = ldr_displacement(opcode);
>> +
>> +	load_addr = (s32 *) (addr + disp);
>> +	regs->regs[xn] = *load_addr;
>> +
>> +	instruction_pointer(regs) += 4;
>> +}
>> diff --git a/arch/arm64/kernel/probes-simulate-insn.h b/arch/arm64/kernel/probes-simulate-insn.h
>> new file mode 100644
>> index 0000000..337384e
>> --- /dev/null
>> +++ b/arch/arm64/kernel/probes-simulate-insn.h
>> @@ -0,0 +1,30 @@
>> +/*
>> + * arch/arm64/kernel/probes-simulate-insn.h
>> + *
>> + * Copyright (C) 2013 Linaro Limited
>> + *
>> + * 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.
>> + */
>> +
>> +#ifndef _ARM_KERNEL_PROBES_SIMULATE_INSN_H
>> +#define _ARM_KERNEL_PROBES_SIMULATE_INSN_H
>> +
>> +extern pstate_check_t * const opcode_condition_checks[16];
>> +
>> +void simulate_adr_adrp(u32 opcode, long addr, struct pt_regs *regs);
>> +void simulate_b_bl(u32 opcode, long addr, struct pt_regs *regs);
>> +void simulate_b_cond(u32 opcode, long addr, struct pt_regs *regs);
>> +void simulate_br_blr_ret(u32 opcode, long addr, struct pt_regs *regs);
>> +void simulate_cbz_cbnz(u32 opcode, long addr, struct pt_regs *regs);
>> +void simulate_tbz_tbnz(u32 opcode, long addr, struct pt_regs *regs);
>> +void simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs);
>> +void simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs);
>> +
>> +#endif /* _ARM_KERNEL_PROBES_SIMULATE_INSN_H */
>>
>
> Thanks,
>
> 	M.
>

Thanks for the review.

-dl



From yong.wu at mediatek.com  Tue Feb 23 15:02:30 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Wed, 24 Feb 2016 07:02:30 +0800
Subject: [PATCH 0/2] MT8173 IOMMU 4GB MODE SUPPORT
Message-ID: <1456268552-16635-1-git-send-email-yong.wu@mediatek.com>

  This patch-set add MTK 4GB mode support on the Short-Descriptor.
MTK extend the bit9 of the standard pgtable descriptor as the 4GB mode.
We add a special quirk for this.
  This two patches are based on Robin's Short-decriptor v3[1], MTK
IOMMU v10[2] and Robin's "Rationalise quirk handling"[3].

[1]: http://lists.linuxfoundation.org/pipermail/iommu/2016-January/015463.html
[2]: http://lists.linuxfoundation.org/pipermail/iommu/2016-February/015795.html
[3]: http://lists.linuxfoundation.org/pipermail/iommu/2016-February/015663.html

Yong Wu (2):
  iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor
  iommu/mediatek: Add 4GB mode support

 drivers/iommu/io-pgtable-arm-v7s.c | 14 +++++++++++++-
 drivers/iommu/io-pgtable.h         |  6 ++++++
 drivers/iommu/mtk_iommu.c          | 14 +++++++++++---
 3 files changed, 30 insertions(+), 4 deletions(-)

-- 
1.8.1.1.dirty 



From yong.wu at mediatek.com  Tue Feb 23 15:02:31 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Wed, 24 Feb 2016 07:02:31 +0800
Subject: [PATCH 1/2] iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor
In-Reply-To: <1456268552-16635-1-git-send-email-yong.wu@mediatek.com>
References: <1456268552-16635-1-git-send-email-yong.wu@mediatek.com>
Message-ID: <1456268552-16635-2-git-send-email-yong.wu@mediatek.com>

Mediatek extend bit9 in the lvl1 and lvl2 pgtable descriptor of the
Short-descriptor as the 4GB mode in which the dram size will be
over 4GB.

We add a special quirk for this MTK-4GB mode, And in the standard
spec, Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while it's AP[2]
in the lvl2, therefore if this quirk is enabled, NO_PERMS is also
expected.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
In arm_v7s_init_pte, We add bit9 if the 4GB mode is enabled no matter
the current pa is over 4GB or not.

 drivers/iommu/io-pgtable-arm-v7s.c | 14 +++++++++++++-
 drivers/iommu/io-pgtable.h         |  6 ++++++
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index 9fcceb1..bf6a6f0 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -121,6 +121,8 @@
 #define ARM_V7S_TEX_MASK		0x7
 #define ARM_V7S_ATTR_TEX(val)		(((val) & ARM_V7S_TEX_MASK) << ARM_V7S_TEX_SHIFT)
 
+#define ARM_V7S_ATTR_MTK_4GB		BIT(9) /* MTK extend it for 4GB mode */
+
 /* *well, except for TEX on level 2 large pages, of course :( */
 #define ARM_V7S_CONT_PAGE_TEX_SHIFT	6
 #define ARM_V7S_CONT_PAGE_TEX_MASK	(ARM_V7S_TEX_MASK << ARM_V7S_CONT_PAGE_TEX_SHIFT)
@@ -364,6 +366,9 @@ static int arm_v7s_init_pte(struct arm_v7s_io_pgtable *data,
 	if (lvl == 1 && (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS))
 		pte |= ARM_V7S_ATTR_NS_SECTION;
 
+	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT)
+		pte |= ARM_V7S_ATTR_MTK_4GB;
+
 	if (num_entries > 1)
 		pte = arm_v7s_pte_to_cont(pte, lvl);
 
@@ -625,9 +630,16 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct io_pgtable_cfg *cfg,
 
 	if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
 			    IO_PGTABLE_QUIRK_NO_PERMS |
-			    IO_PGTABLE_QUIRK_TLBI_ON_MAP))
+			    IO_PGTABLE_QUIRK_TLBI_ON_MAP |
+			    IO_PGTABLE_QUIRK_MTK_4GB_EXT))
 		return NULL;
 
+	/* If MTK_4GB_EXT is enabled, the NO_PERMS is also expected. */
+	if (cfg->quirks & IO_PGTABLE_QUIRK_MTK_4GB_EXT) {
+		if (!(cfg->quirks & IO_PGTABLE_QUIRK_NO_PERMS))
+			return NULL;
+	}
+
 	data = kmalloc(sizeof(*data), GFP_KERNEL);
 	if (!data)
 		return NULL;
diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
index d4f5027..a84a60a 100644
--- a/drivers/iommu/io-pgtable.h
+++ b/drivers/iommu/io-pgtable.h
@@ -60,10 +60,16 @@ struct io_pgtable_cfg {
 	 * IO_PGTABLE_QUIRK_TLBI_ON_MAP: If the format forbids caching invalid
 	 *	(unmapped) entries but the hardware might do so anyway, perform
 	 *	TLB maintenance when mapping as well as when unmapping.
+	 *
+	 * IO_PGTABLE_QUIRK_MTK_4GB_EXT: Mediatek extend bit9 in the lvl1 and
+	 *	lvl2 descriptor of the Short-descriptor as the 4GB mode.
+	 *	Note that: Bit9 in the lvl1 is "IMPLEMENTATION DEFINED", while
+	 *	it is AP[2] in the lvl2.
 	 */
 	#define IO_PGTABLE_QUIRK_ARM_NS		BIT(0)
 	#define IO_PGTABLE_QUIRK_NO_PERMS	BIT(1)
 	#define IO_PGTABLE_QUIRK_TLBI_ON_MAP	BIT(2)
+	#define IO_PGTABLE_QUIRK_MTK_4GB_EXT	BIT(3)
 	unsigned long			quirks;
 	unsigned long			pgsize_bitmap;
 	unsigned int			ias;
-- 
1.8.1.1.dirty



From yong.wu at mediatek.com  Tue Feb 23 15:02:32 2016
From: yong.wu at mediatek.com (Yong Wu)
Date: Wed, 24 Feb 2016 07:02:32 +0800
Subject: [PATCH 2/2] iommu/mediatek: Add 4GB mode support
In-Reply-To: <1456268552-16635-1-git-send-email-yong.wu@mediatek.com>
References: <1456268552-16635-1-git-send-email-yong.wu@mediatek.com>
Message-ID: <1456268552-16635-3-git-send-email-yong.wu@mediatek.com>

This patch add 4GB mode support for m4u.

Signed-off-by: Yong Wu <yong.wu at mediatek.com>
---
In this patch I use the global "max_pfn" to check whether the current
dram size is over 4GB, I am not sure this is proper.

If there is any other suggestions, please let me know.
Thanks.

 drivers/iommu/mtk_iommu.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 721ffdb..5b1ddb5 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -11,6 +11,7 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  */
+#include <linux/bootmem.h>
 #include <linux/bug.h>
 #include <linux/clk.h>
 #include <linux/component.h>
@@ -56,7 +57,7 @@
 #define F_MMU_TF_PROTECT_SEL(prot)		(((prot) & 0x3) << 5)
 
 #define REG_MMU_IVRP_PADDR			0x114
-#define F_MMU_IVRP_PA_SET(pa)			((pa) >> 1)
+#define F_MMU_IVRP_PA_SET(pa, ext)		(((pa) >> 1) | ((!!(ext)) << 31))
 
 #define REG_MMU_INT_CONTROL0			0x120
 #define F_L2_MULIT_HIT_EN			BIT(0)
@@ -125,6 +126,7 @@ struct mtk_iommu_data {
 	struct mtk_iommu_domain		*m4u_dom;
 	struct iommu_group		*m4u_group;
 	struct mtk_smi_iommu		smi_imu;      /* SMI larb iommu info */
+	bool                            enable_4GB;
 };
 
 static struct iommu_ops mtk_iommu_ops;
@@ -257,6 +259,9 @@ static int mtk_iommu_domain_finalise(struct mtk_iommu_data *data)
 		.iommu_dev = data->dev,
 	};
 
+	if (data->enable_4GB)
+		dom->cfg.quirks |= IO_PGTABLE_QUIRK_MTK_4GB_EXT;
+
 	dom->iop = alloc_io_pgtable_ops(ARM_V7S, &dom->cfg, data);
 	if (!dom->iop) {
 		dev_err(data->dev, "Failed to alloc io pgtable\n");
@@ -530,7 +535,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
 		F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
 	writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
 
-	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base),
+	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base, data->enable_4GB),
 		       data->base + REG_MMU_IVRP_PADDR);
 
 	writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
@@ -592,6 +597,9 @@ static int mtk_iommu_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
 
+	/* Whether the current dram size is over 4GB */
+	data->enable_4GB = !!(max_pfn > (0xffffffffUL >> PAGE_SHIFT));
+
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	data->base = devm_ioremap_resource(dev, res);
 	if (IS_ERR(data->base))
@@ -691,7 +699,7 @@ static int mtk_iommu_resume(struct device *dev)
 	writel_relaxed(reg->ctrl_reg, base + REG_MMU_CTRL_REG);
 	writel_relaxed(reg->int_control0, base + REG_MMU_INT_CONTROL0);
 	writel_relaxed(reg->int_main_control, base + REG_MMU_INT_MAIN_CONTROL);
-	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base),
+	writel_relaxed(F_MMU_IVRP_PA_SET(data->protect_base, data->enable_4GB),
 		       base + REG_MMU_IVRP_PADDR);
 	return 0;
 }
-- 
1.8.1.1.dirty



From k.kozlowski at samsung.com  Tue Feb 23 23:27:54 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 24 Feb 2016 16:27:54 +0900
Subject: [PATCH] ARM: dts: add support for gpio buttons for
 exynos5422-odroidxu3
In-Reply-To: <CANAwSgR17csDub4fszP5+=M5qrG5FbHu=rmfny6-5e8x6bWBFg@mail.gmail.com>
References: <1456214467-3344-1-git-send-email-linux.amoon@gmail.com>
 <56CC167A.8040303@samsung.com> <56CC194F.6080905@samsung.com>
 <CANAwSgTRu6pb9cdA50AzBSNLS+Y+sssyc_CX7FKuV=FDYWaOsA@mail.gmail.com>
 <CAJKOXPftm7P44Zxn9rHt1THJOX3Oxu-mg5GD7=T3se4iRe1DkA@mail.gmail.com>
 <CANAwSgR17csDub4fszP5+=M5qrG5FbHu=rmfny6-5e8x6bWBFg@mail.gmail.com>
Message-ID: <56CD5B7A.10908@samsung.com>

On 23.02.2016 23:16, Anand Moon wrote:
> Hi Krzysztof,
> 
> On 23 February 2016 at 17:32, Krzysztof Kozlowski
> <k.kozlowski at samsung.com> wrote:
>> 2016-02-23 18:17 GMT+09:00 Anand Moon <linux.amoon at gmail.com>:
>>> Hi Krzysztof,
>>>
>>> On 23 February 2016 at 14:03, Krzysztof Kozlowski
>>>>>>      };
>>>>>> +
>>>>>> +    gpio_keys {
>>>>>> +            compatible = "gpio-keys";
>>>>>> +            pinctrl-names = "default";
>>>>>> +            pinctrl-0 = <&gpio_power_key>;
>>>>>> +
>>>>>> +            power_key {
>>>>>> +                    interrupt-parent = <&gpx0>;
>>>>>> +                    interrupts = <3 IRQ_TYPE_NONE>;
>>>>>
>>>>> Hmmm.... why you specify the interrupts?
>>>>>
>>>>>> +                    gpios = <&gpx0 3 GPIO_ACTIVE_LOW>;
>>>>
>>>> Please, explain it to me. The SW2 key is connected to PWRON of PMIC.
>>>> However you are adding a GPIO key for external interrupt source 3
>>>> (XE.INT3)... which comes from PMIC's ONOB.
>>>>
>>>> It's interesting.... how does it work? The PMIC will generate ONOB
>>>> interrupt on PWRON low->high change (when PWRHOLD is high)?
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>> I have re-base my changes on HK dts.
>>> I could not find much details for the schematic diagram.
>>> I don't know much low level detains on this.
>>
>> If I understand this correctly: you just took some vendor code,
>> similar to existing code of Odroid U3, and without full understanding
>> of the code nor checking with public schematics, you sent it.
>>
>> Taking vendor stuff is okay but you need to think about it, use it as
>> an example and deliver proper solution based on that. Not copy-paste.
>>
>>> How dose this works: This changes will initial the shudown/reboot on Ubuntu.
>>> I have also tested this similar feature on Odroid U3.
>>
>> Great :), yes it works because ONOB interrupt from PMIC is generated
>> on key press. However this is not a strictly speaking key... I don't
>> really know what to do with this commit and your explanation
>> (Hardkernel has such code) is not sufficient to convince me.
>>
>> Best regards,
>> Krzysztof
> 
> Nothing come easy to me, I had to do bit of work on this.
> Internally I might not know the detail of the board and features of
> the registers of the PMIC.
> I have to improvise some time for changes. I don't know who is the
> original author of the code.
> 
> It's relay hard to convince you on the changes, as I continue to
> repeat the mistake.
> I will try to improve my commits a be specific to the changes in the future.

No worries. :)

Anand,

Anyway I was thinking about this and discussed it even offline. This is
a little bit funny design choice because:
1. The generated interrupt (on line ONOB) is not coming from the
physical key. It is coming from the PMIC, after receiving the change of
PWRON level (which comes from the key).

2. The behaviour and correlation between PWRON and ONOB is poorly
described in datasheet. Only one place mentions it.

3. The other funny idea we had, was to add a input driver for PMIC...
but that IMHO won't solve anything. It won't even make this logically
correct.

4. What I don't like personally, that I had to discover all of it,
instead of reading this in commit message coming from you. I would like
to see the explanation of this design (ONOB, PWRON etc) in comment in
DTS. Written with your own words, not mine (which would be a
confirmation that you understood the code you wrote and sent).
Why? Because you are adding a gpio-key for something which is not a key.
Funny, isn't it? :)

5. If anyone else has some ideas how to solve this (a key-PMIC mixture),
please share!

Best regards,
Krzysztof



From geert at linux-m68k.org  Tue Feb 23 23:37:09 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 24 Feb 2016 08:37:09 +0100
Subject: [PATCH 1/2] ARM: dts: r8a7790: use fallback jpu compatibility
 string
In-Reply-To: <1456280946-14859-2-git-send-email-horms+renesas@verge.net.au>
References: <1456280946-14859-1-git-send-email-horms+renesas@verge.net.au>
 <1456280946-14859-2-git-send-email-horms+renesas@verge.net.au>
Message-ID: <CAMuHMdWvL0HA542+BY=H5C3=vhOrmej_hDWRheEAJyFnjd92kw@mail.gmail.com>

On Wed, Feb 24, 2016 at 3:29 AM, Simon Horman
<horms+renesas at verge.net.au> wrote:
> Use recently added fallback compatibility string in r8a7790 device trees.
>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From geert at linux-m68k.org  Tue Feb 23 23:37:47 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 24 Feb 2016 08:37:47 +0100
Subject: [PATCH 2/2] ARM: dts: r8a7791: use fallback jpu compatibility
 string
In-Reply-To: <1456280946-14859-3-git-send-email-horms+renesas@verge.net.au>
References: <1456280946-14859-1-git-send-email-horms+renesas@verge.net.au>
 <1456280946-14859-3-git-send-email-horms+renesas@verge.net.au>
Message-ID: <CAMuHMdX3fKAyqO=_2g78PJPf0ebgQ9n3qp4uJdXKRX=Tub7V-Q@mail.gmail.com>

On Wed, Feb 24, 2016 at 3:29 AM, Simon Horman
<horms+renesas at verge.net.au> wrote:
> Use recently added fallback compatibility string in r8a7791 device tree.
>
> Signed-off-by: Simon Horman <horms+renesas at verge.net.au>

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From broonie at kernel.org  Tue Feb 23 20:16:44 2016
From: broonie at kernel.org (Mark Brown)
Date: Wed, 24 Feb 2016 13:16:44 +0900
Subject: next-20160222 build: 5 failures 9 warnings (next-20160222)
In-Reply-To: <20160224144859.027a3564@canb.auug.org.au>
References: <E1aXlz4-000486-Pb@optimist> <20160222100832.GX18327@sirena.org.uk>
 <56CAE5E6.7030707@arm.com> <20160224032842.GK18327@sirena.org.uk>
 <20160224144859.027a3564@canb.auug.org.au>
Message-ID: <20160224041644.GS18327@sirena.org.uk>

On Wed, Feb 24, 2016 at 02:48:59PM +1100, Stephen Rothwell wrote:
> On Wed, 24 Feb 2016 12:28:42 +0900 Mark Brown <broonie at kernel.org> wrote:

> > That didn't work out unfortunately, the error is still there today.

> Yeah, the patch didn't hit -next yesterday and I missed the opportunity
> to fix in manually.  However, it should be fixed in today's linux-next
> (out in a few hours, hopefully).

Ah, good - it was just too late rather than not working.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/4b822083/attachment.sig>

From olof at lixom.net  Wed Feb 24 00:03:59 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 00:03:59 -0800
Subject: [GIT PULL] ARM: mvebu: fixes for v4.5 (#2)
In-Reply-To: <874mdfxkjx.fsf@free-electrons.com>
References: <874mdfxkjx.fsf@free-electrons.com>
Message-ID: <20160224080359.GA30231@localhost>

On Thu, Feb 11, 2016 at 05:45:38PM +0100, Gregory CLEMENT wrote:
> Hi,
> 
> Here is the second pull request for fixes for mvebu for v4.5.
> 
> Gregory
> 
> The following changes since commit ff61ee84e7aa5842d9e33c0b442f0b43a6a44eaf:
> 
>   ARM: dts: orion5x: gpio pin fixes for linkstation lswtgl (2016-01-25 16:22:59 +0100)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-4.5-2
> 
> for you to fetch changes up to 44361a2cc13493fc41216d33bb9a562ec3a9cc4e:
> 
>   ARM: dts: orion5x: fix the missing mtd flash on linkstation lswtgl (2016-02-09 11:17:53 +0100)
> 
> ----------------------------------------------------------------
> mvebu fixes for 4.5 (part 2)
> 
> - Fix the missing mtd flash on linkstation lswtgl
> - Use unique machine name for the kirkwood ds112 (for Debian flash-kernel tool)

Merged now, apologies for the delay.


-Olof


From olof at lixom.net  Wed Feb 24 00:05:42 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 00:05:42 -0800
Subject: [GIT PULL] omap fixes against v4.5-rc3
In-Reply-To: <20160212225018.GA3500@atomide.com>
References: <20160212225018.GA3500@atomide.com>
Message-ID: <20160224080542.GB30231@localhost>

On Fri, Feb 12, 2016 at 02:50:18PM -0800, Tony Lindgren wrote:
> The following changes since commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95:
> 
>   Linux 4.5-rc3 (2016-02-07 15:38:30 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.5/fixes-rc3-v2
> 
> for you to fetch changes up to cf26f1137333251f3515dea31f95775b99df0fd5:
> 
>   ARM: OMAP2+: Fix omap_device for module reload on PM runtime forbid (2016-02-12 08:56:52 -0800)

Merged, thanks.


-Olof


From olof at lixom.net  Wed Feb 24 00:08:03 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 00:08:03 -0800
Subject: [GIT PULL] Renesas ARM Based SoC Fixes for v4.5
In-Reply-To: <cover.1455859965.git.horms+renesas@verge.net.au>
References: <cover.1455859965.git.horms+renesas@verge.net.au>
Message-ID: <20160224080803.GD30231@localhost>

On Fri, Feb 19, 2016 at 03:09:46PM +0900, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
> 
> Please consider these Renesas ARM based SoC fixes for v4.5.
> 
> This pull request is comprised of patches from Geert Uytterhoeven to avoid
> writing to .text.
> 
> * "ARM: shmobile: Move shmobile_scu_base from .text to .bss"
> 
>   Resolves a problem for XIP kernels as writing to .text is not allowed.
>   For non-XIP kernels a problem does not manifst as the pages are mapped
>   read-only during late kernel startup.
> 
> * The remaining patches resolve a kernel-crash that occurs during system
>   suspend for CONFIG_DEBUG_RODATA=y kernels.
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-fixes-for-v4.5
> 
> for you to fetch changes up to 901c5ffaaed117a38be9d0c29247c4888d6c8636:
> 
>   ARM: shmobile: Remove shmobile_boot_arg (2016-02-17 18:27:21 +0900)

Hi Simon, Geert,

I don't think any of these fixes are for regressions, are they? I.e. this is
work to enable configs that never used to work (XIP, CONFIG_DEBUG_RODATA)?


-Olof



From olof at lixom.net  Wed Feb 24 00:06:13 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 00:06:13 -0800
Subject: [GIT PULL] ARM: imx: fixes for 4.5
In-Reply-To: <20160214085852.GT6756@tiger>
References: <20160214085852.GT6756@tiger>
Message-ID: <20160224080613.GC30231@localhost>

On Sun, Feb 14, 2016 at 04:58:52PM +0800, Shawn Guo wrote:
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-4.5
> 
> for you to fetch changes up to f5d0ca224a071d7077bbdae347cb514949d64fd9:
> 
>   ARM: dts: imx6: remove bogus interrupt-parent from CAAM node (2016-01-28 16:48:15 +0800)
> 
> ----------------------------------------------------------------
> The i.MX fixes for v4.5:
>  - Drop the bogus interrupt-parent from i.MX6 CAAM node, which leads to
>    the CAAM IRQs not getting unmasked at the GPC level.
> 
> ----------------------------------------------------------------
> Lucas Stach (1):
>       ARM: dts: imx6: remove bogus interrupt-parent from CAAM node

Merged, thanks.


-Olof


From olof at lixom.net  Wed Feb 24 00:09:47 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 00:09:47 -0800
Subject: [PATCH] MAINTAINERS: alpine: add a new maintainer and update the
 entry
In-Reply-To: <CABM=7knwGCMJsc5WP0NQaVr5vbUNC4XNMxnXDu6ep_rJd8VQnw@mail.gmail.com>
References: <1456147350-7236-1-git-send-email-antoine.tenart@free-electrons.com>
 <CABM=7knwGCMJsc5WP0NQaVr5vbUNC4XNMxnXDu6ep_rJd8VQnw@mail.gmail.com>
Message-ID: <20160224080947.GF30231@localhost>

On Mon, Feb 22, 2016 at 03:24:22PM +0200, Tsahee Zidenberg wrote:
> Acked -by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
> 
> 
> On 22 February 2016 at 15:22, Antoine Tenart
> <antoine.tenart at free-electrons.com> wrote:
> > Add myself as a co-maintainer for the Alpine support. Also update the
> > entry to take in account Alpine ARM64 boards, Alpine ARM device trees
> > and Alpine-specific drivers.
> >
> > Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>


Applied to fixes. THanks.


-Olof


From olof at lixom.net  Wed Feb 24 00:10:14 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 00:10:14 -0800
Subject: [GIT PULL] omap fixes against v4.5-rc5, fixes more onenand
 corruption
In-Reply-To: <20160222213427.GU13417@atomide.com>
References: <20160222213427.GU13417@atomide.com>
Message-ID: <20160224081014.GG30231@localhost>

On Mon, Feb 22, 2016 at 01:34:28PM -0800, Tony Lindgren wrote:
> The following changes since commit cf26f1137333251f3515dea31f95775b99df0fd5:
> 
>   ARM: OMAP2+: Fix omap_device for module reload on PM runtime forbid (2016-02-12 08:56:52 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.5/fixes-rc5
> 
> for you to fetch changes up to 3f315c5b850fa7aff73f50de8e316b98f611a32b:
> 
>   ARM: OMAP2+: Fix onenand initialization to avoid filesystem corruption (2016-02-22 09:24:10 -0800)
> 
> ----------------------------------------------------------------
> Two omap fixes for omaps against v4.5-rc5:
> 
> - Yet another fix for n900 onenand to avoid corruption. This time to
>   fix the issue of mounting onenand back and forth between the original
>   maemo kernel and mainline Linux kernel. And it also seems there will
>   be two more fixes coming via the MTD tree as issues were discovered
>   also in the onenand driver during testing.
> 
> - Revert tps65217 regulator clean up as it breaks MMC for am335x
>   variants. The proper way to clean this up is just to rename the
>   tps65217.dtsi file into tps65217-am335x.dtsi as a similar setup
>   is used on many am335x boards.

Thanks, merged.


-Olof


From olof at lixom.net  Wed Feb 24 00:11:25 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 00:11:25 -0800
Subject: [PATCH v2] MAINTAINERS: Extend info, add wiki and ml for meson
 arch
In-Reply-To: <1456220591-11901-1-git-send-email-carlo@caione.org>
References: <1456220591-11901-1-git-send-email-carlo@caione.org>
Message-ID: <20160224081125.GH30231@localhost>

On Tue, Feb 23, 2016 at 10:43:11AM +0100, Carlo Caione wrote:
> From: Carlo Caione <carlo at endlessm.com>
> 
> Update the maintainers info with wiki and mailing list for the meson
> platform. Fix a wrong file attribution and add maintainership for the
> generic meson platforms.
> 
> Signed-off-by: Carlo Caione <carlo at endlessm.com>

Thanks, applied to fixes.


-Olof


From s.hauer at pengutronix.de  Wed Feb 24 00:20:25 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 24 Feb 2016 09:20:25 +0100
Subject: [PATCH 1/9] spi: imx: drop fallback to PIO
In-Reply-To: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
References: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456302033-25638-2-git-send-email-s.hauer@pengutronix.de>

At the moment the driver decides to fallback to PIO mode the buffers
are already mapped for DMA. It's a bug to access them with the CPU
afterwards, so we cannot just fallback to PIO mode.
It should not be necessary anyway, since we only use DMA when we
verified that it's possible in the fist place, so when prep_slave_sg
fails it's a bug, either in the SDMA driver or in the can_dma
implementation.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 19 ++++++-------------
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 6497fc9..a61b1b1 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -945,7 +945,7 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 					tx->sgl, tx->nents, DMA_MEM_TO_DEV,
 					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
 		if (!desc_tx)
-			goto tx_nodma;
+			return -EINVAL;
 
 		desc_tx->callback = spi_imx_dma_tx_callback;
 		desc_tx->callback_param = (void *)spi_imx;
@@ -956,8 +956,10 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 		desc_rx = dmaengine_prep_slave_sg(master->dma_rx,
 					rx->sgl, rx->nents, DMA_DEV_TO_MEM,
 					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
-		if (!desc_rx)
-			goto rx_nodma;
+		if (!desc_rx) {
+			dmaengine_terminate_all(master->dma_tx);
+			return -EINVAL;
+		}
 
 		desc_rx->callback = spi_imx_dma_rx_callback;
 		desc_rx->callback_param = (void *)spi_imx;
@@ -1010,12 +1012,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 		ret = transfer->len;
 
 	return ret;
-
-rx_nodma:
-	dmaengine_terminate_all(master->dma_tx);
-tx_nodma:
-	dev_warn_once(spi_imx->dev, "DMA not available, falling back to PIO\n");
-	return -EAGAIN;
 }
 
 static int spi_imx_pio_transfer(struct spi_device *spi,
@@ -1042,15 +1038,12 @@ static int spi_imx_pio_transfer(struct spi_device *spi,
 static int spi_imx_transfer(struct spi_device *spi,
 				struct spi_transfer *transfer)
 {
-	int ret;
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
 
 	if (spi_imx->bitbang.master->can_dma &&
 	    spi_imx_can_dma(spi_imx->bitbang.master, spi, transfer)) {
 		spi_imx->usedma = true;
-		ret = spi_imx_dma_transfer(spi_imx, transfer);
-		if (ret != -EAGAIN)
-			return ret;
+		return spi_imx_dma_transfer(spi_imx, transfer);
 	}
 	spi_imx->usedma = false;
 
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 24 00:20:28 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 24 Feb 2016 09:20:28 +0100
Subject: [PATCH 4/9] spi: imx: drop unncessary dma_is_inited variable
In-Reply-To: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
References: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456302033-25638-5-git-send-email-s.hauer@pengutronix.de>

There's no need for an extra dma_is_inited variable when we can
equally well check for the existence of a DMA channel.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index ec03304..567a242 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -102,7 +102,6 @@ struct spi_imx_data {
 	unsigned int txfifo; /* number of words pushed in tx FIFO */
 
 	/* DMA */
-	unsigned int dma_is_inited;
 	unsigned int dma_finished;
 	bool usedma;
 	u32 wml;
@@ -205,7 +204,7 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
 
-	if (spi_imx->dma_is_inited && transfer->len >= spi_imx->wml &&
+	if (master->dma_rx && transfer->len >= spi_imx->wml &&
 	    (transfer->len % spi_imx->wml) == 0)
 		return true;
 	return false;
@@ -827,8 +826,6 @@ static void spi_imx_sdma_exit(struct spi_imx_data *spi_imx)
 		dma_release_channel(master->dma_tx);
 		master->dma_tx = NULL;
 	}
-
-	spi_imx->dma_is_inited = 0;
 }
 
 static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
@@ -888,7 +885,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 	master->max_dma_len = MAX_SDMA_BD_BYTES;
 	spi_imx->bitbang.master->flags = SPI_MASTER_MUST_RX |
 					 SPI_MASTER_MUST_TX;
-	spi_imx->dma_is_inited = 1;
 
 	return 0;
 err:
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 24 00:20:26 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 24 Feb 2016 09:20:26 +0100
Subject: [PATCH 2/9] spi: imx: initialize usedma earlier
In-Reply-To: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
References: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456302033-25638-3-git-send-email-s.hauer@pengutronix.de>

The SoC specific config function does not know if DMA will be used or
not. This information will be useful to configure the SPI controller
correctly for DMA in following patches, so initialize the usedma
variable before calling into the SoC specific config function.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index a61b1b1..5792918 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -815,6 +815,11 @@ static int spi_imx_setupxfer(struct spi_device *spi,
 		spi_imx->tx = spi_imx_buf_tx_u32;
 	}
 
+	if (spi_imx_can_dma(spi_imx->bitbang.master, spi, t))
+		spi_imx->usedma = 1;
+	else
+		spi_imx->usedma = 0;
+
 	spi_imx->devtype_data->config(spi_imx, &config);
 
 	return 0;
@@ -1040,14 +1045,10 @@ static int spi_imx_transfer(struct spi_device *spi,
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
 
-	if (spi_imx->bitbang.master->can_dma &&
-	    spi_imx_can_dma(spi_imx->bitbang.master, spi, transfer)) {
-		spi_imx->usedma = true;
+	if (spi_imx->usedma)
 		return spi_imx_dma_transfer(spi_imx, transfer);
-	}
-	spi_imx->usedma = false;
-
-	return spi_imx_pio_transfer(spi, transfer);
+	else
+		return spi_imx_pio_transfer(spi, transfer);
 }
 
 static int spi_imx_setup(struct spi_device *spi)
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 24 00:20:24 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 24 Feb 2016 09:20:24 +0100
Subject: [PATCH v4] i.MX SPI DMA cleanup
Message-ID: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>

Changes since v3:

- improve commit description for "spi: imx: initialize usedma earlier"

Changes since v2:

- Drop patches already applied
- rebase on next

Changes since v1:

- Add missing Signed-off-by to Patch 3
- Drop device tree change as it's already applied by Shawn
- Add patch subject when referring to commits

----------------------------------------------------------------
Anton Bondarenko (1):
      spi: imx: add support for all SPI word width for DMA

Sascha Hauer (8):
      spi: imx: drop fallback to PIO
      spi: imx: initialize usedma earlier
      spi: imx: drop unnecessary read/modify/write
      spi: imx: drop unncessary dma_is_inited variable
      spi: imx: remove unnecessary bit clearing in mx51_ecspi_config
      spi: imx: make some register defines simpler
      spi: imx: set MX51_ECSPI_CTRL_SMC bit in setup function
      spi: imx: drop bogus tests for rx/tx bufs in DMA transfer

 drivers/spi/spi-imx.c | 296 ++++++++++++++++++++++++++------------------------
 1 file changed, 153 insertions(+), 143 deletions(-)


From s.hauer at pengutronix.de  Wed Feb 24 00:20:32 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 24 Feb 2016 09:20:32 +0100
Subject: [PATCH 8/9] spi: imx: set MX51_ECSPI_CTRL_SMC bit in setup function
In-Reply-To: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
References: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456302033-25638-9-git-send-email-s.hauer@pengutronix.de>

Now that the config function knows whether we are doing DMA or not we
can do the necessary register setup in the config function and no longer
have to do this in the trigger function. With this the trigger function
becomes a no-op for DMA, so instead of testing if we are doing DMA or
not in the trigger function we simply no longer call it in the DMA case.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 21 ++++++---------------
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 96e32d4..91890b2 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -106,7 +106,6 @@ struct spi_imx_data {
 	unsigned int txfifo; /* number of words pushed in tx FIFO */
 
 	/* DMA */
-	unsigned int dma_finished;
 	bool usedma;
 	u32 wml;
 	struct completion dma_rx_completion;
@@ -324,14 +323,10 @@ static void __maybe_unused mx51_ecspi_intctrl(struct spi_imx_data *spi_imx, int
 
 static void __maybe_unused mx51_ecspi_trigger(struct spi_imx_data *spi_imx)
 {
-	u32 reg = readl(spi_imx->base + MX51_ECSPI_CTRL);
+	u32 reg;
 
-	if (!spi_imx->usedma)
-		reg |= MX51_ECSPI_CTRL_XCH;
-	else if (!spi_imx->dma_finished)
-		reg |= MX51_ECSPI_CTRL_SMC;
-	else
-		reg &= ~MX51_ECSPI_CTRL_SMC;
+	reg = readl(spi_imx->base + MX51_ECSPI_CTRL);
+	reg |= MX51_ECSPI_CTRL_XCH;
 	writel(reg, spi_imx->base + MX51_ECSPI_CTRL);
 }
 
@@ -371,6 +366,9 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 	if (config->mode & SPI_CS_HIGH)
 		cfg |= MX51_ECSPI_CONFIG_SSBPOL(config->cs);
 
+	if (spi_imx->usedma)
+		ctrl |= MX51_ECSPI_CTRL_SMC;
+
 	/* CTRL register always go first to bring out controller from reset */
 	writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
 
@@ -1012,9 +1010,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	reinit_completion(&spi_imx->dma_rx_completion);
 	reinit_completion(&spi_imx->dma_tx_completion);
 
-	/* Trigger the cspi module. */
-	spi_imx->dma_finished = 0;
-
 	/*
 	 * Set these order to avoid potential RX overflow. The overflow may
 	 * happen if we enable SPI HW before starting RX DMA due to rescheduling
@@ -1025,7 +1020,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 	 */
 	dma_async_issue_pending(master->dma_rx);
 	dma_async_issue_pending(master->dma_tx);
-	spi_imx->devtype_data->trigger(spi_imx);
 
 	transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len);
 
@@ -1046,9 +1040,6 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 		}
 	}
 
-	spi_imx->dma_finished = 1;
-	spi_imx->devtype_data->trigger(spi_imx);
-
 	if (!timeout)
 		ret = -ETIMEDOUT;
 	else
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 24 00:20:29 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 24 Feb 2016 09:20:29 +0100
Subject: [PATCH 5/9] spi: imx: add support for all SPI word width for DMA
In-Reply-To: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
References: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456302033-25638-6-git-send-email-s.hauer@pengutronix.de>

From: Anton Bondarenko <anton.bondarenko.sama at gmail.com>

DMA transfer for SPI was limited to up to 8 bits word size until now.
Sync in SPI burst size and DMA bus width is necessary to correctly
support 16 and 32 BPW.

Signed-off-by: Anton Bondarenko <anton.bondarenko.sama at gmail.com>
Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 118 ++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 91 insertions(+), 27 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 567a242..15b23f0 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -89,11 +89,15 @@ struct spi_imx_data {
 
 	struct completion xfer_done;
 	void __iomem *base;
+	unsigned long base_phys;
+
 	struct clk *clk_per;
 	struct clk *clk_ipg;
 	unsigned long spi_clk;
 	unsigned int spi_bus_clk;
 
+	unsigned int bytes_per_word;
+
 	unsigned int count;
 	void (*tx)(struct spi_imx_data *);
 	void (*rx)(struct spi_imx_data *);
@@ -199,15 +203,35 @@ static unsigned int spi_imx_clkdiv_2(unsigned int fin,
 	return 7;
 }
 
+static int spi_imx_bytes_per_word(const int bpw)
+{
+	return DIV_ROUND_UP(bpw, BITS_PER_BYTE);
+}
+
 static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 			 struct spi_transfer *transfer)
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+	unsigned int bpw = transfer->bits_per_word;
+
+	if (!master->dma_rx)
+		return false;
+
+	if (!bpw)
+		bpw = spi->bits_per_word;
+
+	bpw = spi_imx_bytes_per_word(bpw);
+
+	if (bpw != 1 && bpw != 2 && bpw != 4)
+		return false;
+
+	if (transfer->len < spi_imx->wml * bpw)
+		return false;
+
+	if (transfer->len % (spi_imx->wml * bpw))
+		return false;
 
-	if (master->dma_rx && transfer->len >= spi_imx->wml &&
-	    (transfer->len % spi_imx->wml) == 0)
-		return true;
-	return false;
+	return true;
 }
 
 #define MX51_ECSPI_CTRL		0x08
@@ -775,11 +799,63 @@ static irqreturn_t spi_imx_isr(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
+static int spi_imx_dma_configure(struct spi_master *master,
+				 int bytes_per_word)
+{
+	int ret;
+	enum dma_slave_buswidth buswidth;
+	struct dma_slave_config rx = {}, tx = {};
+	struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
+
+	if (bytes_per_word == spi_imx->bytes_per_word)
+		/* Same as last time */
+		return 0;
+
+	switch (bytes_per_word) {
+	case 4:
+		buswidth = DMA_SLAVE_BUSWIDTH_4_BYTES;
+		break;
+	case 2:
+		buswidth = DMA_SLAVE_BUSWIDTH_2_BYTES;
+		break;
+	case 1:
+		buswidth = DMA_SLAVE_BUSWIDTH_1_BYTE;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	tx.direction = DMA_MEM_TO_DEV;
+	tx.dst_addr = spi_imx->base_phys + MXC_CSPITXDATA;
+	tx.dst_addr_width = buswidth;
+	tx.dst_maxburst = spi_imx->wml;
+	ret = dmaengine_slave_config(master->dma_tx, &tx);
+	if (ret) {
+		dev_err(spi_imx->dev, "TX dma configuration failed with %d\n", ret);
+		return ret;
+	}
+
+	rx.direction = DMA_DEV_TO_MEM;
+	rx.src_addr = spi_imx->base_phys + MXC_CSPIRXDATA;
+	rx.src_addr_width = buswidth;
+	rx.src_maxburst = spi_imx->wml;
+	ret = dmaengine_slave_config(master->dma_rx, &rx);
+	if (ret) {
+		dev_err(spi_imx->dev, "RX dma configuration failed with %d\n", ret);
+		return ret;
+	}
+
+	spi_imx->bytes_per_word = bytes_per_word;
+
+	return 0;
+}
+
 static int spi_imx_setupxfer(struct spi_device *spi,
 				 struct spi_transfer *t)
 {
 	struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
 	struct spi_imx_config config;
+	int ret;
 
 	config.bpw = t ? t->bits_per_word : spi->bits_per_word;
 	config.speed_hz  = t ? t->speed_hz : spi->max_speed_hz;
@@ -808,6 +884,13 @@ static int spi_imx_setupxfer(struct spi_device *spi,
 	else
 		spi_imx->usedma = 0;
 
+	if (spi_imx->usedma) {
+		ret = spi_imx_dma_configure(spi->master,
+					    spi_imx_bytes_per_word(config.bpw));
+		if (ret)
+			return ret;
+	}
+
 	spi_imx->devtype_data->config(spi_imx, &config);
 
 	return 0;
@@ -829,10 +912,8 @@ static void spi_imx_sdma_exit(struct spi_imx_data *spi_imx)
 }
 
 static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
-			     struct spi_master *master,
-			     const struct resource *res)
+			     struct spi_master *master)
 {
-	struct dma_slave_config slave_config = {};
 	int ret;
 
 	/* use pio mode for i.mx6dl chip TKT238285 */
@@ -850,16 +931,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 		goto err;
 	}
 
-	slave_config.direction = DMA_MEM_TO_DEV;
-	slave_config.dst_addr = res->start + MXC_CSPITXDATA;
-	slave_config.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
-	slave_config.dst_maxburst = spi_imx->wml;
-	ret = dmaengine_slave_config(master->dma_tx, &slave_config);
-	if (ret) {
-		dev_err(dev, "error in TX dma configuration.\n");
-		goto err;
-	}
-
 	/* Prepare for RX : */
 	master->dma_rx = dma_request_slave_channel_reason(dev, "rx");
 	if (IS_ERR(master->dma_rx)) {
@@ -869,15 +940,7 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 		goto err;
 	}
 
-	slave_config.direction = DMA_DEV_TO_MEM;
-	slave_config.src_addr = res->start + MXC_CSPIRXDATA;
-	slave_config.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
-	slave_config.src_maxburst = spi_imx->wml;
-	ret = dmaengine_slave_config(master->dma_rx, &slave_config);
-	if (ret) {
-		dev_err(dev, "error in RX dma configuration.\n");
-		goto err;
-	}
+	spi_imx_dma_configure(master, 1);
 
 	init_completion(&spi_imx->dma_rx_completion);
 	init_completion(&spi_imx->dma_tx_completion);
@@ -1164,6 +1227,7 @@ static int spi_imx_probe(struct platform_device *pdev)
 		ret = PTR_ERR(spi_imx->base);
 		goto out_master_put;
 	}
+	spi_imx->base_phys = res->start;
 
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
@@ -1204,7 +1268,7 @@ static int spi_imx_probe(struct platform_device *pdev)
 	 * other chips.
 	 */
 	if (is_imx51_ecspi(spi_imx)) {
-		ret = spi_imx_sdma_init(&pdev->dev, spi_imx, master, res);
+		ret = spi_imx_sdma_init(&pdev->dev, spi_imx, master);
 		if (ret == -EPROBE_DEFER)
 			goto out_clk_put;
 
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 24 00:20:33 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 24 Feb 2016 09:20:33 +0100
Subject: [PATCH 9/9] spi: imx: drop bogus tests for rx/tx bufs in DMA transfer
In-Reply-To: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
References: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456302033-25638-10-git-send-email-s.hauer@pengutronix.de>

The driver tries to be clever by only setting up DMA channels when
the corresponding sg tables are non NULL. The sg tables are embedded
structs in struct spi_transfer, so they are guaranteed to be non NULL
which makes the if(tx)/if(rx) tests completely bogus. The driver even
sets the SPI_MASTER_MUST_RX / SPI_MASTER_MUST_TX flags which makes sure
the sg tables are not only present but also non empty.
Drop the tests and make the DMA path easier to follow.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 82 +++++++++++++++++++++------------------------------
 1 file changed, 34 insertions(+), 48 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 91890b2..e7a19be 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -974,51 +974,40 @@ static int spi_imx_calculate_timeout(struct spi_imx_data *spi_imx, int size)
 static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 				struct spi_transfer *transfer)
 {
-	struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
-	int ret;
+	struct dma_async_tx_descriptor *desc_tx, *desc_rx;
 	unsigned long transfer_timeout;
 	unsigned long timeout;
 	struct spi_master *master = spi_imx->bitbang.master;
 	struct sg_table *tx = &transfer->tx_sg, *rx = &transfer->rx_sg;
 
-	if (tx) {
-		desc_tx = dmaengine_prep_slave_sg(master->dma_tx,
-					tx->sgl, tx->nents, DMA_MEM_TO_DEV,
-					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
-		if (!desc_tx)
-			return -EINVAL;
-
-		desc_tx->callback = spi_imx_dma_tx_callback;
-		desc_tx->callback_param = (void *)spi_imx;
-		dmaengine_submit(desc_tx);
-	}
+	/*
+	 * The TX DMA setup starts the transfer, so make sure RX is configured
+	 * before TX.
+	 */
+	desc_rx = dmaengine_prep_slave_sg(master->dma_rx,
+				rx->sgl, rx->nents, DMA_DEV_TO_MEM,
+				DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	if (!desc_rx)
+		return -EINVAL;
 
-	if (rx) {
-		desc_rx = dmaengine_prep_slave_sg(master->dma_rx,
-					rx->sgl, rx->nents, DMA_DEV_TO_MEM,
-					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
-		if (!desc_rx) {
-			dmaengine_terminate_all(master->dma_tx);
-			return -EINVAL;
-		}
+	desc_rx->callback = spi_imx_dma_rx_callback;
+	desc_rx->callback_param = (void *)spi_imx;
+	dmaengine_submit(desc_rx);
+	reinit_completion(&spi_imx->dma_rx_completion);
+	dma_async_issue_pending(master->dma_rx);
 
-		desc_rx->callback = spi_imx_dma_rx_callback;
-		desc_rx->callback_param = (void *)spi_imx;
-		dmaengine_submit(desc_rx);
+	desc_tx = dmaengine_prep_slave_sg(master->dma_tx,
+				tx->sgl, tx->nents, DMA_MEM_TO_DEV,
+				DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	if (!desc_tx) {
+		dmaengine_terminate_all(master->dma_tx);
+		return -EINVAL;
 	}
 
-	reinit_completion(&spi_imx->dma_rx_completion);
+	desc_tx->callback = spi_imx_dma_tx_callback;
+	desc_tx->callback_param = (void *)spi_imx;
+	dmaengine_submit(desc_tx);
 	reinit_completion(&spi_imx->dma_tx_completion);
-
-	/*
-	 * Set these order to avoid potential RX overflow. The overflow may
-	 * happen if we enable SPI HW before starting RX DMA due to rescheduling
-	 * for another task and/or interrupt.
-	 * So RX DMA enabled first to make sure data would be read out from FIFO
-	 * ASAP. TX DMA enabled next to start filling TX FIFO with new data.
-	 * And finaly SPI HW enabled to start actual data transfer.
-	 */
-	dma_async_issue_pending(master->dma_rx);
 	dma_async_issue_pending(master->dma_tx);
 
 	transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len);
@@ -1030,22 +1019,19 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
 		dev_err(spi_imx->dev, "I/O Error in DMA TX\n");
 		dmaengine_terminate_all(master->dma_tx);
 		dmaengine_terminate_all(master->dma_rx);
-	} else {
-		timeout = wait_for_completion_timeout(
-				&spi_imx->dma_rx_completion, transfer_timeout);
-		if (!timeout) {
-			dev_err(spi_imx->dev, "I/O Error in DMA RX\n");
-			spi_imx->devtype_data->reset(spi_imx);
-			dmaengine_terminate_all(master->dma_rx);
-		}
+		return -ETIMEDOUT;
 	}
 
-	if (!timeout)
-		ret = -ETIMEDOUT;
-	else
-		ret = transfer->len;
+	timeout = wait_for_completion_timeout(&spi_imx->dma_rx_completion,
+					      transfer_timeout);
+	if (!timeout) {
+		dev_err(&master->dev, "I/O Error in DMA RX\n");
+		spi_imx->devtype_data->reset(spi_imx);
+		dmaengine_terminate_all(master->dma_rx);
+		return -ETIMEDOUT;
+	}
 
-	return ret;
+	return transfer->len;
 }
 
 static int spi_imx_pio_transfer(struct spi_device *spi,
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 24 00:20:30 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 24 Feb 2016 09:20:30 +0100
Subject: [PATCH 6/9] spi: imx: remove unnecessary bit clearing in
 mx51_ecspi_config
In-Reply-To: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
References: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456302033-25638-7-git-send-email-s.hauer@pengutronix.de>

This reverts patch 1476253cef (spi: imx: fix ecspi mode setup)
The patch tried to fix something by clearing bits in the cfg variable,
but cfg is initialized to zero on function entry. There are no bits to
clear.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 15b23f0..287ec0c 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -366,20 +366,13 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 
 	if (config->mode & SPI_CPHA)
 		cfg |= MX51_ECSPI_CONFIG_SCLKPHA(config->cs);
-	else
-		cfg &= ~MX51_ECSPI_CONFIG_SCLKPHA(config->cs);
 
 	if (config->mode & SPI_CPOL) {
 		cfg |= MX51_ECSPI_CONFIG_SCLKPOL(config->cs);
 		cfg |= MX51_ECSPI_CONFIG_SCLKCTL(config->cs);
-	} else {
-		cfg &= ~MX51_ECSPI_CONFIG_SCLKPOL(config->cs);
-		cfg &= ~MX51_ECSPI_CONFIG_SCLKCTL(config->cs);
 	}
 	if (config->mode & SPI_CS_HIGH)
 		cfg |= MX51_ECSPI_CONFIG_SSBPOL(config->cs);
-	else
-		cfg &= ~MX51_ECSPI_CONFIG_SSBPOL(config->cs);
 
 	/* CTRL register always go first to bring out controller from reset */
 	writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 24 00:20:31 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 24 Feb 2016 09:20:31 +0100
Subject: [PATCH 7/9] spi: imx: make some register defines simpler
In-Reply-To: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
References: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456302033-25638-8-git-send-email-s.hauer@pengutronix.de>

The watermark levels in the DMA register are write only, the driver
should never have to read them back from the hardware. Replace the
current _MASK and _OFFSET defines with defines taking the watermark
level directly.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 287ec0c..96e32d4 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -256,12 +256,9 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 #define MX51_ECSPI_INT_RREN		(1 <<  3)
 
 #define MX51_ECSPI_DMA      0x14
-#define MX51_ECSPI_DMA_TX_WML_OFFSET	0
-#define MX51_ECSPI_DMA_TX_WML_MASK	0x3F
-#define MX51_ECSPI_DMA_RX_WML_OFFSET	16
-#define MX51_ECSPI_DMA_RX_WML_MASK	(0x3F << 16)
-#define MX51_ECSPI_DMA_RXT_WML_OFFSET	24
-#define MX51_ECSPI_DMA_RXT_WML_MASK	(0x3F << 24)
+#define MX51_ECSPI_DMA_TX_WML(wml)	((wml) & 0x3f)
+#define MX51_ECSPI_DMA_RX_WML(wml)	(((wml) & 0x3f) << 16)
+#define MX51_ECSPI_DMA_RXT_WML(wml)	(((wml) & 0x3f) << 24)
 
 #define MX51_ECSPI_DMA_TEDEN		(1 << 7)
 #define MX51_ECSPI_DMA_RXDEN		(1 << 23)
@@ -408,9 +405,9 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 	 * and enable DMA request.
 	 */
 
-	writel(spi_imx->wml << MX51_ECSPI_DMA_RX_WML_OFFSET |
-		spi_imx->wml << MX51_ECSPI_DMA_TX_WML_OFFSET |
-		spi_imx->wml << MX51_ECSPI_DMA_RXT_WML_OFFSET |
+	writel(MX51_ECSPI_DMA_RX_WML(spi_imx->wml) |
+		MX51_ECSPI_DMA_TX_WML(spi_imx->wml) |
+		MX51_ECSPI_DMA_RXT_WML(spi_imx->wml) |
 		MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
 		MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
 
-- 
2.7.0



From s.hauer at pengutronix.de  Wed Feb 24 00:20:27 2016
From: s.hauer at pengutronix.de (Sascha Hauer)
Date: Wed, 24 Feb 2016 09:20:27 +0100
Subject: [PATCH 3/9] spi: imx: drop unnecessary read/modify/write
In-Reply-To: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
References: <1456302033-25638-1-git-send-email-s.hauer@pengutronix.de>
Message-ID: <1456302033-25638-4-git-send-email-s.hauer@pengutronix.de>

When the MX51_ECSPI_DMA is configured we control every single bit
of the register, so there's no need to read/modify/write it. Instead
just write the value we want to have in the register. Also, drop
unnecessary check if we are actually doing DMA. The values written
to the register have no effect in PIO mode and value written there
during the last DMA transfer is still in the register, so we can
equally well always write a value.

Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
 drivers/spi/spi-imx.c | 31 ++++++++++---------------------
 1 file changed, 10 insertions(+), 21 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 5792918..ec03304 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -240,9 +240,9 @@ static bool spi_imx_can_dma(struct spi_master *master, struct spi_device *spi,
 #define MX51_ECSPI_DMA_RXT_WML_OFFSET	24
 #define MX51_ECSPI_DMA_RXT_WML_MASK	(0x3F << 24)
 
-#define MX51_ECSPI_DMA_TEDEN_OFFSET	7
-#define MX51_ECSPI_DMA_RXDEN_OFFSET	23
-#define MX51_ECSPI_DMA_RXTDEN_OFFSET	31
+#define MX51_ECSPI_DMA_TEDEN		(1 << 7)
+#define MX51_ECSPI_DMA_RXDEN		(1 << 23)
+#define MX51_ECSPI_DMA_RXTDEN		(1 << 31)
 
 #define MX51_ECSPI_STAT		0x18
 #define MX51_ECSPI_STAT_RR		(1 <<  3)
@@ -318,8 +318,7 @@ static void __maybe_unused mx51_ecspi_trigger(struct spi_imx_data *spi_imx)
 static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 		struct spi_imx_config *config)
 {
-	u32 ctrl = MX51_ECSPI_CTRL_ENABLE, cfg = 0, dma = 0;
-	u32 tx_wml_cfg, rx_wml_cfg, rxt_wml_cfg;
+	u32 ctrl = MX51_ECSPI_CTRL_ENABLE, cfg = 0;
 	u32 clk = config->speed_hz, delay, reg;
 
 	/*
@@ -392,22 +391,12 @@ static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
 	 * Configure the DMA register: setup the watermark
 	 * and enable DMA request.
 	 */
-	if (spi_imx->dma_is_inited) {
-		dma = readl(spi_imx->base + MX51_ECSPI_DMA);
-
-		rx_wml_cfg = spi_imx->wml << MX51_ECSPI_DMA_RX_WML_OFFSET;
-		tx_wml_cfg = spi_imx->wml << MX51_ECSPI_DMA_TX_WML_OFFSET;
-		rxt_wml_cfg = spi_imx->wml << MX51_ECSPI_DMA_RXT_WML_OFFSET;
-		dma = (dma & ~MX51_ECSPI_DMA_TX_WML_MASK
-			   & ~MX51_ECSPI_DMA_RX_WML_MASK
-			   & ~MX51_ECSPI_DMA_RXT_WML_MASK)
-			   | rx_wml_cfg | tx_wml_cfg | rxt_wml_cfg
-			   |(1 << MX51_ECSPI_DMA_TEDEN_OFFSET)
-			   |(1 << MX51_ECSPI_DMA_RXDEN_OFFSET)
-			   |(1 << MX51_ECSPI_DMA_RXTDEN_OFFSET);
-
-		writel(dma, spi_imx->base + MX51_ECSPI_DMA);
-	}
+
+	writel(spi_imx->wml << MX51_ECSPI_DMA_RX_WML_OFFSET |
+		spi_imx->wml << MX51_ECSPI_DMA_TX_WML_OFFSET |
+		spi_imx->wml << MX51_ECSPI_DMA_RXT_WML_OFFSET |
+		MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
+		MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
 
 	return 0;
 }
-- 
2.7.0



From pankaj.dubey at samsung.com  Wed Feb 24 00:23:33 2016
From: pankaj.dubey at samsung.com (pankaj.dubey)
Date: Wed, 24 Feb 2016 13:53:33 +0530
Subject: [PATCH 2/3] ARM: EXYNOS: remove unused register offset definition
In-Reply-To: <56CCEF84.6090502@samsung.com>
References: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
 <1456135396-17767-3-git-send-email-pankaj.dubey@samsung.com>
 <56CBA1BC.4050003@samsung.com> <56CC2238.2040303@samsung.com>
 <56CCEF84.6090502@samsung.com>
Message-ID: <56CD6885.4060904@samsung.com>



On Wednesday 24 February 2016 05:17 AM, Krzysztof Kozlowski wrote:
> On 23.02.2016 18:11, pankaj.dubey wrote:
>> Hi Krzysztof,
>>
>> On Tuesday 23 February 2016 05:33 AM, Krzysztof Kozlowski wrote:
>>> On 22.02.2016 19:03, Pankaj Dubey wrote:
>>>> This patch cleans up map.h by removing unused register offset
>>>> and changing EXYNOS4 to EXYNOS in header comment section.
>>>>
>>>> Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
>>>> ---
>>>>  arch/arm/mach-exynos/include/mach/map.h | 9 +--------
>>>>  1 file changed, 1 insertion(+), 8 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
>>>> index 351e839..c48ba4f 100644
>>>> --- a/arch/arm/mach-exynos/include/mach/map.h
>>>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>>>> @@ -2,7 +2,7 @@
>>>>   * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
>>>>   *		http://www.samsung.com/
>>>>   *
>>>> - * EXYNOS4 - Memory map definitions
>>>> + * EXYNOS - Memory map definitions
>>>>   *
>>>>   * 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
>>>> @@ -14,12 +14,6 @@
>>>>  
>>>>  #include <plat/map-base.h>
>>>>  
>>>> -/*
>>>> - * EXYNOS4 UART offset is 0x10000 but the older S5P SoCs are 0x400.
>>>> - * So need to define it, and here is to avoid redefinition warning.
>>>> - */
>>>> -#define S3C_UART_OFFSET			(0x10000)
>>>> -
>>>>  #include <plat/map-s5p.h>
>>>
>>> This does not look good. The S3C_UART_OFFSET is used in plat/map-s5p.h.
>>>
>>
>> Actually it's just defined there but not getting used anywhere. In fact
>> we can remove it from there also.
> 
> The point is that your patch introduce changes. Before S3C_UART_OFFSET
> was defined to 0x10000, after (because of #ifndef) it will be 0x400.
> Description of "unused" is not accurate. Unused stuff does not impact
> anything.
> 
>> So I submitted another patch to
>> cleanup such redundant register definitions from plat/map-s5p.h.
> 
> That would be good.
> 
>> Only platform using S3C_UART_OFFSET is s3c64xx and its using definition
>> from map-s3c.h. I have compiled all related platform defconfigs and
>> found no issues because of removal of S3C_UART_OFFSET from map-s5p.c and
>> map.h.
> 
> The compilation is not a test. You compiled something like this:
> -#define S3C_UART_OFFSET			(0x10000)
>  #ifndef S3C_UART_OFFSET
>  #define S3C_UART_OFFSET         (0x400)
>  #endif
> 
> ... and found no errors. Of course there are no compilation errors! But
> the value has changed!
> 

OK. I see, there are quite a few places these definitions are scattered
even though not used (not used in the sense what ever values these
macros are taking in code it's not used). Such as
mach-exynos/include/map.h, plat-samsung/include/plat/{map-s3c.h,
map-s5p.h} and mach-s3c24xx/include/mach/map.h. So I will remove all
these in one go.
Is this fine?
Also I have one doubt in case I am touching files across various mach
files and preparing a single patch what should be commit message
heading? Is commit starting with "ARM: samsung" fine? or anything more
appropriate you would suggest.

Thanks,
Pankaj Dubey
> Best regards,
> Krzysztof
> 
> 
> 


From schwidefsky at de.ibm.com  Wed Feb 24 00:22:08 2016
From: schwidefsky at de.ibm.com (Martin Schwidefsky)
Date: Wed, 24 Feb 2016 09:22:08 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe
 also on PowerPC and ARM)
In-Reply-To: <20160223191907.25719a4d@thinkpad>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160223103221.GA1418@node.shutemov.name>
 <20160223191907.25719a4d@thinkpad>
Message-ID: <20160224092208.49e013ff@mschwide>

On Tue, 23 Feb 2016 19:19:07 +0100
Gerald Schaefer <gerald.schaefer at de.ibm.com> wrote:

> On Tue, 23 Feb 2016 13:32:21 +0300
> "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> 
> > On Fri, Feb 12, 2016 at 06:16:40PM +0100, Gerald Schaefer wrote:
> > > On Fri, 12 Feb 2016 16:57:27 +0100
> > > Christian Borntraeger <borntraeger at de.ibm.com> wrote:
> > > 
> > > > > I'm also confused by pmd_none() is equal to !pmd_present() on s390. Hm?
> > > > 
> > > > Don't know, Gerald or Martin?
> > > 
> > > The implementation frequently changes depending on how many new bits Martin
> > > needs to squeeze out :-)
> > > We don't have a _PAGE_PRESENT bit for pmds, so pmd_present() just checks if the
> > > entry is not empty. pmd_none() of course does the opposite, it checks if it is
> > > empty.
> > 
> > I still worry about pmd_present(). It looks wrong to me. I wounder if
> > patch below makes a difference.
> > 
> > The theory is that the splitting bit effetely masked bogus pmd_present():
> > we had pmd_trans_splitting() in all code path and that prevented mm from
> > touching the pmd. Once pmd_trans_splitting() has gone, mm proceed with the
> > pmd where it shouldn't and here's a boom.
> 
> Well, I don't think pmd_present() == true is bogus for a trans_huge pmd under
> splitting, after all there is a page behind the the pmd. Also, if it was
> bogus, and it would need to be false, why should it be marked !pmd_present()
> only at the pmdp_invalidate() step before the pmd_populate()? It clearly
> is pmd_present() before that, on all architectures, and if there was any
> problem/race with that, setting it to !pmd_present() at this stage would
> only (marginally) reduce the race window.
> 
> BTW, PowerPC and Sparc seem to do the same thing in pmdp_invalidate(),
> i.e. they do not set pmd_present() == false, only mark it so that it would
> not generate a new TLB entry, just like on s390. After all, the function
> is called pmdp_invalidate(), and I think the comment in mm/huge_memory.c
> before that call is just a little ambiguous in its wording. When it says
> "mark the pmd notpresent" it probably means "mark it so that it will not
> generate a new TLB entry", which is also what the comment is really about:
> prevent huge and small entries in the TLB for the same page at the same
> time.

If I am not mistaken this is true for x86 as well. The generic implementation
for pmdp_invalidate sets a new pmd that has been modified with
pmd_mknotpresent. For x86 this function removes the _PAGE_PRESENT and
_PAGE_PROTNONE bits from the entry. The _PAGE_PSE bit stays set and that
makes pmd_present return true.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.



From tiffany.lin at mediatek.com  Wed Feb 24 00:23:43 2016
From: tiffany.lin at mediatek.com (tiffany lin)
Date: Wed, 24 Feb 2016 16:23:43 +0800
Subject: [PATCH v5 0/8] Add MT8173 Video Encoder Driver and VPU Driver
In-Reply-To: <56CC1CAB.1060409@xs4all.nl>
References: <1456215081-16858-1-git-send-email-tiffany.lin@mediatek.com>
 <56CC1CAB.1060409@xs4all.nl>
Message-ID: <1456302223.15077.8.camel@mtksdaap41>

Hi Hans,

On Tue, 2016-02-23 at 09:47 +0100, Hans Verkuil wrote:
> On 02/23/16 09:11, Tiffany Lin wrote:
> > ==============
> >  Introduction
> > ==============
> > 
> > The purpose of this series is to add the driver for video codec hw embedded in the Mediatek's MT8173 SoCs.
> > Mediatek Video Codec is able to handle video encoding of in a range of formats.
> > 
> > This patch series also include VPU driver. Mediatek Video Codec driver rely on VPU driver to load,
> > communicate with VPU.
> > 
> > Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI.
> > MTK IOMMU[1] and MTK SMI[2] have not yet been merged, but we wanted to start discussion about the driver
> > earlier so it could be merged sooner.
> > 
> > [1]https://patchwork.kernel.org/patch/8335461/
> > [2]https://patchwork.kernel.org/patch/7596181/
> 
> <snip>
> 
> > v4l2-compliance test output:
> > localhost ~ # /usr/bin/v4l2-compliance -d /dev/video1
> > Driver Info:
> >         Driver name   : mtk-vcodec-enc
> >         Card type     : platform:mt8173
> >         Bus info      : platform:mt8173
> >         Driver version: 4.4.0
> >         Capabilities  : 0x84204000
> >                 Video Memory-to-Memory Multiplanar
> >                 Streaming
> >                 Extended Pix Format
> >                 Device Capabilities
> >         Device Caps   : 0x04204000
> >                 Video Memory-to-Memory Multiplanar
> >                 Streaming
> >                 Extended Pix Format
> > 
> > Compliance test for device /dev/video1 (not using libv4l2):
> > 
> > Required ioctls:
> >         test VIDIOC_QUERYCAP: OK
> > 
> > Allow for multiple opens:
> >         test second video open: OK
> >         test VIDIOC_QUERYCAP: OK
> >         test VIDIOC_G/S_PRIORITY: OK
> > 
> > Debug ioctls:
> >         test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> >         test VIDIOC_LOG_STATUS: OK (Not Supported)
> > 
> > Input ioctls:
> >         test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> >         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> >         test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> >         test VIDIOC_ENUMAUDIO: OK (Not Supported)
> >         test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
> >         test VIDIOC_G/S_AUDIO: OK (Not Supported)
> >         Inputs: 0 Audio Inputs: 0 Tuners: 0
> > 
> > Output ioctls:
> >         test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> >         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> >         test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> >         test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> >         test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> >         Outputs: 0 Audio Outputs: 0 Modulators: 0
> > 
> > Input/Output configuration ioctls:
> >         test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> >         test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> >         test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> >         test VIDIOC_G/S_EDID: OK (Not Supported)
> > 
> >         Control ioctls:
> >                 test VIDIOC_QUERYCTRL/MENU: OK
> >                 test VIDIOC_G/S_CTRL: OK
> >                 test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> >                 test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> >                 test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> >                 Standard Controls: 12 Private Controls: 0
> > 
> >         Format ioctls:
> >                 test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> >                 test VIDIOC_G/S_PARM: OK
> >                 test VIDIOC_G_FBUF: OK (Not Supported)
> >                 test VIDIOC_G_FMT: OK
> >                 test VIDIOC_TRY_FMT: OK
> >                 test VIDIOC_S_FMT: OK
> >                 test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> > 
> >         Codec ioctls:
> >                 test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> >                 test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> >                 test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> > 
> >         Buffer ioctls:
> >                 test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> >                 test VIDIOC_EXPBUF: OK
> > 
> > Total: 38, Succeeded: 38, Failed: 0, Warnings: 0
> 
> Nice!
> 
> Can you try 'v4l2-compliance -s'? Note that this may not work since I know
> that v4l2-compliance doesn't work all that well with codecs, but I am
> curious what the output is when you try streaming.
> 
> Don't bother trying to chase down reported failures, those are likely from
> v4l2-compliance itself. It is something I would like to improve, but -ENOTIME.
> 

When I try to run 'v4l2-compliance -d /dev/video1 -s, I got follow
output.
I use v4.4-rc5 kernel and v4l-utils 1.6 version.

Streaming ioctls:
        test read/write: OK (Not Supported)
fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(332): buf.querybuf(node, i) fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(868): testQueryBuf(node, cur_fmt.type, q.g_buffers())
        test MMAP: FAIL
fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(923): ret && ret != ENOTTY

fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(988): setupUserPtr(node, q)
        test USERPTR: FAIL
        test DMABUF: Cannot test, specify --expbuf-device

best regards,
Tiffany

> Regards,
> 
> 	Hans




From hverkuil at xs4all.nl  Wed Feb 24 00:30:47 2016
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Wed, 24 Feb 2016 09:30:47 +0100
Subject: [PATCH v5 0/8] Add MT8173 Video Encoder Driver and VPU Driver
In-Reply-To: <1456302223.15077.8.camel@mtksdaap41>
References: <1456215081-16858-1-git-send-email-tiffany.lin@mediatek.com>
 <56CC1CAB.1060409@xs4all.nl> <1456302223.15077.8.camel@mtksdaap41>
Message-ID: <56CD6A37.2040700@xs4all.nl>

Hi Tiffany,

On 02/24/16 09:23, tiffany lin wrote:
> Hi Hans,
> 
> On Tue, 2016-02-23 at 09:47 +0100, Hans Verkuil wrote:
>> On 02/23/16 09:11, Tiffany Lin wrote:
>>> ==============
>>>  Introduction
>>> ==============
>>>
>>> The purpose of this series is to add the driver for video codec hw embedded in the Mediatek's MT8173 SoCs.
>>> Mediatek Video Codec is able to handle video encoding of in a range of formats.
>>>
>>> This patch series also include VPU driver. Mediatek Video Codec driver rely on VPU driver to load,
>>> communicate with VPU.
>>>
>>> Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI.
>>> MTK IOMMU[1] and MTK SMI[2] have not yet been merged, but we wanted to start discussion about the driver
>>> earlier so it could be merged sooner.
>>>
>>> [1]https://patchwork.kernel.org/patch/8335461/
>>> [2]https://patchwork.kernel.org/patch/7596181/
>>
>> <snip>
>>
>>> v4l2-compliance test output:
>>> localhost ~ # /usr/bin/v4l2-compliance -d /dev/video1
>>> Driver Info:
>>>         Driver name   : mtk-vcodec-enc
>>>         Card type     : platform:mt8173
>>>         Bus info      : platform:mt8173
>>>         Driver version: 4.4.0
>>>         Capabilities  : 0x84204000
>>>                 Video Memory-to-Memory Multiplanar
>>>                 Streaming
>>>                 Extended Pix Format
>>>                 Device Capabilities
>>>         Device Caps   : 0x04204000
>>>                 Video Memory-to-Memory Multiplanar
>>>                 Streaming
>>>                 Extended Pix Format
>>>
>>> Compliance test for device /dev/video1 (not using libv4l2):
>>>
>>> Required ioctls:
>>>         test VIDIOC_QUERYCAP: OK
>>>
>>> Allow for multiple opens:
>>>         test second video open: OK
>>>         test VIDIOC_QUERYCAP: OK
>>>         test VIDIOC_G/S_PRIORITY: OK
>>>
>>> Debug ioctls:
>>>         test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
>>>         test VIDIOC_LOG_STATUS: OK (Not Supported)
>>>
>>> Input ioctls:
>>>         test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
>>>         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>         test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
>>>         test VIDIOC_ENUMAUDIO: OK (Not Supported)
>>>         test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
>>>         test VIDIOC_G/S_AUDIO: OK (Not Supported)
>>>         Inputs: 0 Audio Inputs: 0 Tuners: 0
>>>
>>> Output ioctls:
>>>         test VIDIOC_G/S_MODULATOR: OK (Not Supported)
>>>         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
>>>         test VIDIOC_ENUMAUDOUT: OK (Not Supported)
>>>         test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
>>>         test VIDIOC_G/S_AUDOUT: OK (Not Supported)
>>>         Outputs: 0 Audio Outputs: 0 Modulators: 0
>>>
>>> Input/Output configuration ioctls:
>>>         test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
>>>         test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
>>>         test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
>>>         test VIDIOC_G/S_EDID: OK (Not Supported)
>>>
>>>         Control ioctls:
>>>                 test VIDIOC_QUERYCTRL/MENU: OK
>>>                 test VIDIOC_G/S_CTRL: OK
>>>                 test VIDIOC_G/S/TRY_EXT_CTRLS: OK
>>>                 test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
>>>                 test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
>>>                 Standard Controls: 12 Private Controls: 0
>>>
>>>         Format ioctls:
>>>                 test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>>>                 test VIDIOC_G/S_PARM: OK
>>>                 test VIDIOC_G_FBUF: OK (Not Supported)
>>>                 test VIDIOC_G_FMT: OK
>>>                 test VIDIOC_TRY_FMT: OK
>>>                 test VIDIOC_S_FMT: OK
>>>                 test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
>>>
>>>         Codec ioctls:
>>>                 test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
>>>                 test VIDIOC_G_ENC_INDEX: OK (Not Supported)
>>>                 test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
>>>
>>>         Buffer ioctls:
>>>                 test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
>>>                 test VIDIOC_EXPBUF: OK
>>>
>>> Total: 38, Succeeded: 38, Failed: 0, Warnings: 0
>>
>> Nice!
>>
>> Can you try 'v4l2-compliance -s'? Note that this may not work since I know
>> that v4l2-compliance doesn't work all that well with codecs, but I am
>> curious what the output is when you try streaming.
>>
>> Don't bother trying to chase down reported failures, those are likely from
>> v4l2-compliance itself. It is something I would like to improve, but -ENOTIME.
>>
> 
> When I try to run 'v4l2-compliance -d /dev/video1 -s, I got follow
> output.
> I use v4.4-rc5 kernel and v4l-utils 1.6 version.

Can you compile v4l2-compliance straight from the v4l-utils.git master branch?
Version 1.6 is too old, and for proper compliance testing you should always use
the master branch. It probably won't matter for this -s test, but for the
regular test (without -s) it does make a difference.

If nothing else, using the master branch will make it easier for me to match up
the line numbers that v4l2-compliance reports to the actual source.

Thanks!

	Hans

> 
> Streaming ioctls:
>         test read/write: OK (Not Supported)
> fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(332): buf.querybuf(node, i) fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(868): testQueryBuf(node, cur_fmt.type, q.g_buffers())
>         test MMAP: FAIL
> fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(923): ret && ret != ENOTTY
> 
> fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(988): setupUserPtr(node, q)
>         test USERPTR: FAIL
>         test DMABUF: Cannot test, specify --expbuf-device
> 
> best regards,
> Tiffany
> 
>> Regards,
>>
>> 	Hans
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From geert at linux-m68k.org  Wed Feb 24 00:37:46 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 24 Feb 2016 09:37:46 +0100
Subject: [GIT PULL] Renesas ARM Based SoC Fixes for v4.5
In-Reply-To: <20160224080803.GD30231@localhost>
References: <cover.1455859965.git.horms+renesas@verge.net.au>
 <20160224080803.GD30231@localhost>
Message-ID: <CAMuHMdWxXFf0MFKP27y6g7CUc1MeG0PuJ-FdoSkV+2gB5NvQTA@mail.gmail.com>

Hi Olof,

On Wed, Feb 24, 2016 at 9:08 AM, Olof Johansson <olof at lixom.net> wrote:
> On Fri, Feb 19, 2016 at 03:09:46PM +0900, Simon Horman wrote:
>> Please consider these Renesas ARM based SoC fixes for v4.5.
>>
>> This pull request is comprised of patches from Geert Uytterhoeven to avoid
>> writing to .text.
>>
>> * "ARM: shmobile: Move shmobile_scu_base from .text to .bss"
>>
>>   Resolves a problem for XIP kernels as writing to .text is not allowed.
>>   For non-XIP kernels a problem does not manifst as the pages are mapped
>>   read-only during late kernel startup.
>>
>> * The remaining patches resolve a kernel-crash that occurs during system
>>   suspend for CONFIG_DEBUG_RODATA=y kernels.
>>
>>
>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>
>>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-fixes-for-v4.5
>>
>> for you to fetch changes up to 901c5ffaaed117a38be9d0c29247c4888d6c8636:
>>
>>   ARM: shmobile: Remove shmobile_boot_arg (2016-02-17 18:27:21 +0900)
>
> Hi Simon, Geert,
>
> I don't think any of these fixes are for regressions, are they? I.e. this is
> work to enable configs that never used to work (XIP, CONFIG_DEBUG_RODATA)?

These configs indeed never worked before.

However,

commit 25362dc496edaf17f714c0fecd8b3eb79670207b
Author: Kees Cook <keescook at chromium.org>
Date:   Tue Jan 26 01:19:36 2016 +0100

    ARM: 8501/1: mm: flip priority of CONFIG_DEBUG_RODATA

in arm/for-next will enable CONFIG_DEBUG_RODATA by default.

Not having the fixes in v4.5 means that if Russell's tree is merged
into mainline
for v4.6 before arm-soc, it will cause regressions and bisection issues.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From schwidefsky at de.ibm.com  Wed Feb 24 00:39:15 2016
From: schwidefsky at de.ibm.com (Martin Schwidefsky)
Date: Wed, 24 Feb 2016 09:39:15 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe
 also on PowerPC and ARM)
In-Reply-To: <20160223193345.GC21820@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160223103221.GA1418@node.shutemov.name>
 <20160223191907.25719a4d@thinkpad>
 <20160223193345.GC21820@node.shutemov.name>
Message-ID: <20160224093915.6e163a33@mschwide>

On Tue, 23 Feb 2016 22:33:45 +0300
"Kirill A. Shutemov" <kirill at shutemov.name> wrote:

> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> > I'll check with Martin, maybe it is actually trivial, then we can
> > do a quick test it to rule that one out.
> 
> Oh. I found a bug in __split_huge_pmd_locked(). Although, not sure if it's
> _the_ bug.
> 
> pmdp_invalidate() is called for the wrong address :-/
> I guess that can be destructive on the architecture, right?
> 
> Could you check this?
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 1c317b85ea7d..4246bc70e55a 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2865,7 +2865,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
>  	pgtable = pgtable_trans_huge_withdraw(mm, pmd);
>  	pmd_populate(mm, &_pmd, pgtable);
> 
> -	for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
> +	for (i = 0; i < HPAGE_PMD_NR; i++) {
>  		pte_t entry, *pte;
>  		/*
>  		 * Note that NUMA hinting access restrictions are not
> @@ -2886,9 +2886,9 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
>  		}
>  		if (dirty)
>  			SetPageDirty(page + i);
> -		pte = pte_offset_map(&_pmd, haddr);
> +		pte = pte_offset_map(&_pmd, haddr + i * PAGE_SIZE);
>  		BUG_ON(!pte_none(*pte));
> -		set_pte_at(mm, haddr, pte, entry);
> +		set_pte_at(mm, haddr + i * PAGE_SIZE, pte, entry);
>  		atomic_inc(&page[i]._mapcount);
>  		pte_unmap(pte);
>  	}
> @@ -2938,7 +2938,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
>  	pmd_populate(mm, pmd, pgtable);
> 
>  	if (freeze) {
> -		for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
> +		for (i = 0; i < HPAGE_PMD_NR; i++) {
>  			page_remove_rmap(page + i, false);
>  			put_page(page + i);
>  		}

Test is running and it looks good so far. For the final assessment I defer
to Gerald and Sebastian.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.



From alexandre.torgue at gmail.com  Wed Feb 24 00:40:55 2016
From: alexandre.torgue at gmail.com (Alexandre Torgue)
Date: Wed, 24 Feb 2016 09:40:55 +0100
Subject: [PATCH v2 2/4] Documentation: Bindings: Add STM32 DWMAC glue
In-Reply-To: <CAGhQ9VwsSb-Nb4nQ4Q9=b-Dj_8EhSi=LOK-r4JbKcE=nfODufw@mail.gmail.com>
References: <1456240244-10275-1-git-send-email-alexandre.torgue@gmail.com>
 <1456240244-10275-3-git-send-email-alexandre.torgue@gmail.com>
 <CAGhQ9VwsSb-Nb4nQ4Q9=b-Dj_8EhSi=LOK-r4JbKcE=nfODufw@mail.gmail.com>
Message-ID: <CAJgp7zzrJWuJBQyjRdyU5qg=emCjqWfSPVRhT-D6G6Ho=hJzVA@mail.gmail.com>

2016-02-23 23:37 GMT+01:00 Joachim  Eastwood <manabian at gmail.com>:
> Hi Alexandre,
>
> You should copy 'devicetree at vger.kernel.org' on bindings doc. Adding cc here.
>
> On 23 February 2016 at 16:10, Alexandre TORGUE
> <alexandre.torgue at gmail.com> wrote:
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>
>>
>> diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
>> new file mode 100644
>> index 0000000..18734b3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
>> @@ -0,0 +1,41 @@
>> +STMicroelectronics STM32 / MCU DWMAC glue layer controller
>> +
>> +This file documents platform glue layer for stmmac.
>> +Please see stmmac.txt for the other unchanged properties.
>> +
>> +The device node has following properties.
>> +
>> +Required properties:
>> +- compatible:  Should be "st,stm32-dwmac" to select glue, and
>> +              "snps,dwmac-3.50a" to select IP vesrion.
>> +- clocks: Should contain the GMAC main clock, and tx clock
>> +- compatible:  Should be "st,stm32-dwmac" to select glue and
>> +              "snps,dwmac-3.50a" to select IP version.
>> +- clocks: Should contain the MAC main clock
>> +- clock-names: Should contain the clock names "stmmaceth".
>> +- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
>> +             encompases the glue register, and the offset of the control register.
>> +
>> +Optional properties:
>> +- clocks: Could contain:
>> +       - the tx clock,
>> +       - the rx clock
>> +- clock-names: Could contain the clock names "tx-clk", "rx-clk"
>> +
>> +Example:
>> +
>> +               ethernet0: dwmac at 40028000 {
>> +                       device_type = "network";
>
> What is this 'device_type = "network"' for?
> It seems to used in a lot of powerpc DTs, but only a couple of arm DTs.
>
> Maybe Rob could enlighten us?
>
>> +                       compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
>> +                       status = "disabled";
>> +                       reg = <0x40028000 0x8000>;
>> +                       reg-names = "stmmaceth";
>> +                       interrupts = <0 61 0>, <0 62 0>;
>> +                       interrupt-names = "macirq", "eth_wake_irq";
>> +                       clock-names = "stmmaceth", "tx-clk", "rx-clk";
>> +                       clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
>> +                       st,syscon = <&syscfg 0x4>;
>> +                       snps,pbl = <32>;
>
> Regarding snps,pbl; using 32 here might not give you what you would except.
> See comment in dwmac1000_dma_init().
>
> The driver is hard coded to use PBL4X/PBL8X mode. Just a heads up.
>
Hi Joachim,

My fault, It is not working with 32. I will modify it (should be 8 for example)

Regards

Alexandre

>
> regards,
> Joachim Eastwood


From linus.walleij at linaro.org  Wed Feb 24 00:48:34 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 24 Feb 2016 09:48:34 +0100
Subject: [PATCH] ARM: realview: DT support for the PBA8
Message-ID: <1456303714-31039-1-git-send-email-linus.walleij@linaro.org>

This adds a devicetree for the ARM RealView PBA8 platform,
also known as HBI-0178, "RealView(R) Platform Baseboard for
Cortex(TM)-A8".

Tested in QEMU with -M realview-pb-a8 and works like a charm,
however with these annoying boot messages:

of_amba_device_create(): amba_device_add()
    failed (-19) for /soc/sysctl at 10001000
of_amba_device_create(): amba_device_add()
    failed (-19) for /soc/ssp at 1000d000
of_amba_device_create(): amba_device_add()
    failed (-19) for /soc/timer at 10018000
of_amba_device_create(): amba_device_add()
    failed (-19) for /soc/timer at 10019000
of_amba_device_create(): amba_device_add()
    failed (-19) for /soc/sysctl at 1001a000

I think this is because these PrimeCells do not exist in the
QEMU machine model but would work fine on the real hardware.
QEMU still works, because the SP810 clocks will anyway probe,
as they are not amba_devices but use the special CLK_OF_DECLARE()
probing macro.

Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Peter Maydell <peter.maydell at linaro.org>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/boot/dts/Makefile              |   3 +-
 arch/arm/boot/dts/arm-realview-pba8.dts | 620 ++++++++++++++++++++++++++++++++
 2 files changed, 622 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/arm-realview-pba8.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 39deb1741465..bf01d0641531 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -537,7 +537,8 @@ dtb-$(CONFIG_ARCH_REALVIEW) += \
 	arm-realview-eb.dtb \
 	arm-realview-eb-11mp.dtb \
 	arm-realview-eb-11mp-revb.dtb \
-	arm-realview-eb-a9mp.dtb
+	arm-realview-eb-a9mp.dtb \
+	arm-realview-pba8.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3036-evb.dtb \
 	rk3036-kylin.dtb \
diff --git a/arch/arm/boot/dts/arm-realview-pba8.dts b/arch/arm/boot/dts/arm-realview-pba8.dts
new file mode 100644
index 000000000000..722b29308720
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-pba8.dts
@@ -0,0 +1,620 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "skeleton.dtsi"
+
+/ {
+	model = "ARM RealView PB-A8";
+	compatible = "arm,realview-pba8";
+	arm,hbi = <0x178>;
+
+	chosen { };
+
+	aliases {
+		serial0 = &serial0;
+		serial1 = &serial1;
+		serial2 = &serial2;
+		serial3 = &serial3;
+		i2c0 = &i2c;
+	};
+
+	memory {
+		/* 128 MiB memory @ 0x0 */
+		reg = <0x00000000 0x08000000>;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		enable-method = "arm,realview-smp";
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a8";
+			reg = <0>;
+		};
+	};
+
+	pmu: pmu at 0 {
+		compatible = "arm,cortex-a8-pmu";
+		interrupt-parent = <&intc>;
+		interrupts = <0 47 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu0>;
+	};
+
+	/* The voltage to the MMC card is hardwired at 3.3V */
+	vmmc: fixedregulator at 0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vmmc";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+        };
+
+	veth: fixedregulator at 0 {
+		compatible = "regulator-fixed";
+		regulator-name = "veth";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+	};
+
+	xtal24mhz: xtal24mhz at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <24000000>;
+	};
+
+	refclk32khz: refclk32khz {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <32768>;
+	};
+
+	timclk: timclk at 1M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <24>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	mclk: mclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	kmiclk: kmiclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	sspclk: sspclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	uartclk: uartclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	wdogclk: wdogclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	/* FIXME: this actually hangs off the PLL clocks */
+	pclk: pclk at 0 {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <0>;
+	};
+
+	flash0 at 40000000 {
+		/* 2 * 32MiB NOR Flash memory */
+		compatible = "arm,versatile-flash", "cfi-flash";
+		reg = <0x40000000 0x04000000>;
+		bank-width = <4>;
+	};
+
+	flash1 at 44000000 {
+		/* 2 * 32MiB NOR Flash memory */
+		compatible = "arm,versatile-flash", "cfi-flash";
+		reg = <0x44000000 0x04000000>;
+		bank-width = <4>;
+	};
+
+	/* SMSC 9118 ethernet with PHY and EEPROM */
+	ethernet: ethernet at 4e000000 {
+		compatible = "smsc,lan9118", "smsc,lan9115";
+		reg = <0x4e000000 0x10000>;
+		phy-mode = "mii";
+		reg-io-width = <4>;
+		smsc,irq-active-high;
+		smsc,irq-push-pull;
+		vdd33a-supply = <&veth>;
+		vddvario-supply = <&veth>;
+		interrupt-parent = <&intc>;
+		interrupts = <0 28 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	usb: usb at 4f000000 {
+		compatible = "nxp,usb-isp1761";
+		reg = <0x4f000000 0x20000>;
+		interrupt-parent = <&intc>;
+		interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>;
+		port1-otg;
+	};
+
+	soc {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "arm,realview-pba8-soc", "simple-bus";
+		regmap = <&syscon>;
+		ranges;
+
+		syscon: syscon at 10000000 {
+			compatible = "arm,realview-pba8-syscon", "syscon", "simple-mfd";
+			reg = <0x10000000 0x1000>;
+
+			led at 08.0 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x01>;
+				label = "versatile:0";
+				linux,default-trigger = "heartbeat";
+				default-state = "on";
+			};
+			led at 08.1 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x02>;
+				label = "versatile:1";
+				linux,default-trigger = "mmc0";
+				default-state = "off";
+			};
+			led at 08.2 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x04>;
+				label = "versatile:2";
+				linux,default-trigger = "cpu0";
+				default-state = "off";
+			};
+			led at 08.3 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x08>;
+				label = "versatile:3";
+				default-state = "off";
+			};
+			led at 08.4 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x10>;
+				label = "versatile:4";
+				default-state = "off";
+			};
+			led at 08.5 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x20>;
+				label = "versatile:5";
+				default-state = "off";
+			};
+			led at 08.6 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x40>;
+				label = "versatile:6";
+				default-state = "off";
+			};
+			led at 08.7 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x80>;
+				label = "versatile:7";
+				default-state = "off";
+			};
+			oscclk0: osc0 at 0c {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x0C>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk1: osc1 at 10 {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x10>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk2: osc2 at 14 {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x14>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk3: osc3 at 18 {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x18>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk4: osc4 at 1c {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x1c>;
+				clocks = <&xtal24mhz>;
+			};
+		};
+
+		sp810_syscon0: sysctl at 10001000 {
+			compatible = "arm,sp810", "arm,primecell";
+			reg = <0x10001000 0x1000>;
+			clocks = <&refclk32khz>, <&timclk>, <&xtal24mhz>;
+			clock-names = "refclk", "timclk", "apb_pclk";
+			#clock-cells = <1>;
+			clock-output-names = "timerclk0",
+					     "timerclk1",
+					     "timerclk2",
+					     "timerclk3";
+			assigned-clocks = <&sp810_syscon0 0>,
+					  <&sp810_syscon0 1>,
+					  <&sp810_syscon0 2>,
+					  <&sp810_syscon0 3>;
+			assigned-clock-parents = <&timclk>,
+					       <&timclk>,
+					       <&timclk>,
+					       <&timclk>;
+		};
+
+		i2c: i2c at 10002000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "arm,versatile-i2c";
+			reg = <0x10002000 0x1000>;
+
+			rtc at 68 {
+				compatible = "dallas,ds1338";
+				reg = <0x68>;
+			};
+		};
+
+		serial0: serial at 10009000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x10009000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 12 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		serial1: serial at 1000a000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x1000a000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 13 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		serial2: serial at 1000b000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x1000b000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		ssp: ssp at 1000d000 {
+			compatible = "arm,pl022", "arm,primecell";
+			reg = <0x1000d000 0x1000>;
+			clocks = <&sspclk>, <&pclk>;
+			clock-names = "SSPCLK", "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		wdog0: watchdog at 1000f000 {
+			compatible = "arm,sp805", "arm,primecell";
+			reg = <0x1000f000 0x1000>;
+			clocks = <&wdogclk>, <&pclk>;
+			clock-names = "wdogclk", "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		wdog1: watchdog at 10010000 {
+			compatible = "arm,sp805", "arm,primecell";
+			reg = <0x10010000 0x1000>;
+			clocks = <&wdogclk>, <&pclk>;
+			clock-names = "wdogclk", "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>;
+			status = "disabled";
+		};
+
+		timer01: timer at 10011000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x10011000 0x1000>;
+			clocks = <&sp810_syscon0 0>,
+			         <&sp810_syscon0 1>,
+				 <&pclk>;
+			clock-names = "timerclk0",
+				    "timerclk1",
+				    "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		timer23: timer at 10012000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x10012000 0x1000>;
+			clocks = <&sp810_syscon0 2>,
+			         <&sp810_syscon0 3>,
+				 <&pclk>;
+			clock-names = "timerclk2",
+				    "timerclk3",
+				    "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+			arm,sp804-has-irq = <1>;
+		};
+
+		gpio0: gpio at 10013000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x10013000 0x1000>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		gpio1: gpio at 10014000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x10014000 0x1000>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		gpio2: gpio at 10015000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x10015000 0x1000>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		/* DVI serial bus control is at 10016000 */
+
+		rtc: rtc at 10017000 {
+			compatible = "arm,pl031", "arm,primecell";
+			reg = <0x10017000 0x1000>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		timer45: timer at 10018000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x10018000 0x1000>;
+			clocks = <&timclk>, <&timclk>, <&pclk>;
+			clock-names = "timerclk4", "timerclk5", "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		timer67: timer at 10019000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x10019000 0x1000>;
+			clocks = <&timclk>, <&timclk>, <&pclk>;
+			clock-names = "timerclk6", "timerclk7", "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 42 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		sp810_syscon1: sysctl at 1001a000 {
+			compatible = "arm,sp810", "arm,primecell";
+			reg = <0x1001a000 0x1000>;
+			clocks = <&refclk32khz>, <&timclk>, <&xtal24mhz>;
+			clock-names = "refclk", "timclk", "apb_pclk";
+			#clock-cells = <1>;
+			clock-output-names = "timerclk4",
+					     "timerclk5",
+					     "timerclk6",
+					     "timerclk7";
+			assigned-clocks = <&sp810_syscon1 0>,
+					  <&sp810_syscon1 1>,
+					  <&sp810_syscon1 2>,
+					  <&sp810_syscon1 3>;
+			assigned-clock-parents = <&timclk>,
+					       <&timclk>,
+					       <&timclk>,
+					       <&timclk>;
+		};
+
+		/* Primary GIC PL390 interrupt controller in the test chip */
+		intc: interrupt-controller at 1e000000 {
+			compatible = "arm,pl390";
+			#interrupt-cells = <3>;
+			#address-cells = <1>;
+			interrupt-controller;
+			reg = <0x1e001000 0x1000>,
+			      <0x1e000000 0x100>;
+		};
+	};
+
+
+	/* These peripherals are inside the FPGA */
+	fpga {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		ranges;
+
+		aaci: aaci at 10004000 {
+			compatible = "arm,pl041", "arm,primecell";
+			reg = <0x10004000 0x1000>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		mmc: mmcsd at 10005000 {
+			compatible = "arm,pl18x", "arm,primecell";
+			reg = <0x10005000 0x1000>;
+
+			/* Due to frequent FIFO overruns, use just 500 kHz */
+			max-frequency = <500000>;
+			bus-width = <4>;
+			cap-sd-highspeed;
+			cap-mmc-highspeed;
+			clocks = <&mclk>, <&pclk>;
+			clock-names = "mclk", "apb_pclk";
+			vmmc-supply = <&vmmc>;
+			cd-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
+			wp-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>;
+			interrupt-parent = <&intc>;
+			interrupts = <0 17 IRQ_TYPE_LEVEL_HIGH>,
+				     <0 18 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		kmi0: kmi at 10006000 {
+			compatible = "arm,pl050", "arm,primecell";
+			reg = <0x10006000 0x1000>;
+			clocks = <&kmiclk>, <&pclk>;
+			clock-names = "KMIREFCLK", "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		kmi1: kmi at 10007000 {
+			compatible = "arm,pl050", "arm,primecell";
+			reg = <0x10007000 0x1000>;
+			clocks = <&kmiclk>, <&pclk>;
+			clock-names = "KMIREFCLK", "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		serial3: serial at 1000c000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x1000c000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+			interrupt-parent = <&intc>;
+			interrupts = <0 15 IRQ_TYPE_LEVEL_HIGH>;
+		};
+	};
+
+	/* These peripherals are inside the NEC ISSP */
+	issp {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		ranges;
+
+		clcd: clcd at 10020000 {
+			compatible = "arm,pl111", "arm,primecell";
+			reg = <0x10020000 0x1000>;
+			interrupt-parent = <&intc>;
+			interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "combined";
+			clocks = <&oscclk4>, <&pclk>;
+			clock-names = "clcdclk", "apb_pclk";
+
+			port {
+				clcd_pads: endpoint {
+					remote-endpoint = <&clcd_panel>;
+					arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+				};
+			};
+
+			panel {
+				compatible = "panel-dpi";
+
+				port {
+					clcd_panel: endpoint {
+						remote-endpoint = <&clcd_pads>;
+					};
+				};
+
+				/* Standard 640x480 VGA timings */
+				panel-timing {
+					clock-frequency = <25175000>;
+					hactive = <640>;
+					hback-porch = <48>;
+					hfront-porch = <16>;
+					hsync-len = <96>;
+					vactive = <480>;
+					vback-porch = <33>;
+					vfront-porch = <10>;
+					vsync-len = <2>;
+				};
+			};
+		};
+	};
+};
+
-- 
2.4.3



From arnd at arndb.de  Wed Feb 24 00:53:55 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Feb 2016 09:53:55 +0100
Subject: [PATCH] ARM: realview: DT support for the PBA8
In-Reply-To: <1456303714-31039-1-git-send-email-linus.walleij@linaro.org>
References: <1456303714-31039-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <30042109.XpH2Vid3ZU@wuerfel>

On Wednesday 24 February 2016 09:48:34 Linus Walleij wrote:
> This adds a devicetree for the ARM RealView PBA8 platform,
> also known as HBI-0178, "RealView(R) Platform Baseboard for
> Cortex(TM)-A8".

Nice!

> Tested in QEMU with -M realview-pb-a8 and works like a charm,
> however with these annoying boot messages:
> 
> of_amba_device_create(): amba_device_add()
>     failed (-19) for /soc/sysctl at 10001000
> of_amba_device_create(): amba_device_add()
>     failed (-19) for /soc/ssp at 1000d000
> of_amba_device_create(): amba_device_add()
>     failed (-19) for /soc/timer at 10018000
> of_amba_device_create(): amba_device_add()
>     failed (-19) for /soc/timer at 10019000
> of_amba_device_create(): amba_device_add()
>     failed (-19) for /soc/sysctl at 1001a000
> 
> I think this is because these PrimeCells do not exist in the
> QEMU machine model but would work fine on the real hardware.
> QEMU still works, because the SP810 clocks will anyway probe,
> as they are not amba_devices but use the special CLK_OF_DECLARE()
> probing macro.
> 

I think we can treat this as a harmless qemu deficiency.

It would be nice to fix qemu to avoid the warnings, but as you say
it's not a showstopper.

	Arnd


From draakje197 at gmail.com  Wed Feb 24 00:57:25 2016
From: draakje197 at gmail.com (Henry Paulissen)
Date: Wed, 24 Feb 2016 09:57:25 +0100
Subject: [PATCH] Add triggers for cubietruck leds
Message-ID: <1456304247-2481-1-git-send-email-henry@nitronetworks.nl>

This (small) patch gives the same led trigger functionality
as the 3.4 sunxi kernel and although mainline doesn't has
to be the same, it helps in identifying and builds upon the
user expectations about what those leds mean.

Signed-off-by: Henry Paulissen <henry at nitronetworks.nl>
---
 arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index 8da939a..bea6b0f 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -70,21 +70,29 @@
 		blue {
 			label = "cubietruck:blue:usr";
 			gpios = <&pio 7 21 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+			default-state = "off";
 		};
 
 		orange {
 			label = "cubietruck:orange:usr";
 			gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "cpu0";
+			default-state = "off";
 		};
 
 		white {
 			label = "cubietruck:white:usr";
 			gpios = <&pio 7 11 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "cpu1";
+			default-state = "off";
 		};
 
 		green {
 			label = "cubietruck:green:usr";
 			gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "mmc1";
+			default-state = "off";
 		};
 	};
 
-- 
2.5.0



From alexandre.torgue at gmail.com  Wed Feb 24 01:03:08 2016
From: alexandre.torgue at gmail.com (Alexandre Torgue)
Date: Wed, 24 Feb 2016 10:03:08 +0100
Subject: [PATCH v2 1/4] net: ethernet: dwmac: add Ethernet glue logic for
 stm32 chip
In-Reply-To: <CAGhQ9Vz8uUeyhEutTPh3Zb3C=T3F2xC7kgHorZyWcz6HW+ySmw@mail.gmail.com>
References: <1456240244-10275-1-git-send-email-alexandre.torgue@gmail.com>
 <1456240244-10275-2-git-send-email-alexandre.torgue@gmail.com>
 <CAGhQ9Vz8uUeyhEutTPh3Zb3C=T3F2xC7kgHorZyWcz6HW+ySmw@mail.gmail.com>
Message-ID: <CAJgp7zwEcsk3gAQ+xJZoKYTYjp-R2_K5kZ47kCrXv3Y1mL4s8A@mail.gmail.com>

2016-02-23 23:16 GMT+01:00 Joachim  Eastwood <manabian at gmail.com>:
> Hi Alexandre,
>
> On 23 February 2016 at 16:10, Alexandre TORGUE
> <alexandre.torgue at gmail.com> wrote:
>> stm324xx family chips support Synopsys MAC 3.510 IP.
>> This patch adds settings for logical glue logic:
>> -clocks
>> -mode selection MII or RMII.
>>
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
>> index cec147d..f63bdcf 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
>> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
>> @@ -114,6 +114,18 @@ config DWMAC_SUNXI
>>           This selects Allwinner SoC glue layer support for the
>>           stmmac device driver. This driver is used for A20/A31
>>           GMAC ethernet controller.
>> +
>> +config DWMAC_STM32
>> +       tristate "STM32 DWMAC support"
>> +       default ARCH_STM32
>> +       depends on OF && HAS_IOMEM
>> +       select MFD_SYSCON
>> +       ---help---
>> +         Support for ethernet controller on STM32 SOCs.
>> +
>> +         This selects STM32 SoC glue layer support for the stmmac
>> +         device driver. This driver is used on for the STM32 series
>> +         SOCs GMAC ethernet controller.
>>  endif
>>
>>  config STMMAC_PCI
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
>> index b390161..559086d 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/Makefile
>> +++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
>> @@ -13,6 +13,7 @@ obj-$(CONFIG_DWMAC_ROCKCHIP)  += dwmac-rk.o
>>  obj-$(CONFIG_DWMAC_SOCFPGA)    += dwmac-socfpga.o
>>  obj-$(CONFIG_DWMAC_STI)                += dwmac-sti.o
>>  obj-$(CONFIG_DWMAC_SUNXI)      += dwmac-sunxi.o
>> +obj-$(CONFIG_DWMAC_STM32)      += dwmac-stm32.o
>

Hi Joachim,

> Put them in alphabetic order. Same goes for the KConfig entry.

Ok

>
>
>>  obj-$(CONFIG_DWMAC_GENERIC)    += dwmac-generic.o
>>  stmmac-platform-objs:= stmmac_platform.o
> ...
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
>> +struct stm32_dwmac {
>> +       int interface;          /* MII interface */
>> +       struct clk *clk_tx;
>> +       struct clk *clk_rx;
>> +       u32 mode_reg;           /* MAC glue-logic mode register */
>> +       struct regmap *regmap;
>> +       u32 speed;
>> +};
>> +
>> +static int stm32_dwmac_init(void *priv)
>
> If you used 'struct stm32_dwmac *' instead of 'void *' you could skip
> the local variable assignment.
>
> Even better; you could pass 'struct plat_stmmacenet_data *' and use
> it's 'interface' member to set the phy mode. Then you could drop the
> interface member in your priv data struct and remove of_get_phy_mode()
> in stm32_dwmac_parse_data().

Yes, interesting.
>
>
>> +{
>> +       struct stm32_dwmac *dwmac = priv;
>> +       struct regmap *regmap = dwmac->regmap;
>> +       int ret, iface = dwmac->interface;
>> +       u32 reg = dwmac->mode_reg;
>> +       u32 val;
>> +
>> +       ret = clk_prepare_enable(dwmac->clk_tx);
>> +       if (ret)
>> +               goto out;
>> +
>> +       ret = clk_prepare_enable(dwmac->clk_rx);
>> +       if (ret)
>> +               goto out_disable_clk_tx;
>> +
>> +       val = (iface == PHY_INTERFACE_MODE_MII) ? 0 : 1;
>> +       ret = regmap_update_bits(regmap, reg, MII_PHY_SEL_MASK, val);
>> +       if (ret)
>> +               goto out_disable_clk_tx_rx;
>> +
>> +       return 0;
>> +
>> +out_disable_clk_tx_rx:
>> +       clk_disable_unprepare(dwmac->clk_rx);
>> +out_disable_clk_tx:
>> +       clk_disable_unprepare(dwmac->clk_tx);
>> +out:
>> +       return ret;
>> +}
>> +
>> +static void stm32_dwmac_exit(void *priv)
>> +{
>> +       struct stm32_dwmac *dwmac = priv;
>
> Again; instead of 'void *' use 'struct stm32_dwmac *' to avoid the
> local assignment.
>
>
>> +
>> +       clk_disable_unprepare(dwmac->clk_tx);
>> +       clk_disable_unprepare(dwmac->clk_rx);
>> +}
>
> To be honest I really don't see the point in having a function with
> just two other function calls in it. Consider dropping the function
> altogether and place the clk_disable_unprepare() calls where it's
> called from. If you still want to keep it, please put a more
> descriptive name on it.

It was just to avoid redundant code, but yes there is not a big
interest to do it.

>
>
>> +static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
>> +                                 struct platform_device *pdev)
>
> Since you are only interested in *dev and not *pdev you could pass a
> 'struct dev *' instead.

ok

>
>> +{
>> +       struct device *dev = &pdev->dev;
>> +       struct device_node *np = dev->of_node;
>> +       struct regmap *regmap;
>> +       int err;
>> +
>> +       /*  Get TX/RX clocks */
>> +       dwmac->clk_tx = devm_clk_get(dev, "tx-clk");
>> +       if (IS_ERR(dwmac->clk_tx)) {
>> +               dev_warn(dev, "No tx clock provided...\n");
>> +               dwmac->clk_tx = NULL;
>> +       }
>> +       dwmac->clk_rx = devm_clk_get(dev, "rx-clk");
>> +       if (IS_ERR(dwmac->clk_rx)) {
>> +               dev_warn(dev, "No rx clock provided...\n");
>> +               dwmac->clk_rx = NULL;
>> +       }
>> +
>> +       /* Get mode register */
>> +       regmap = syscon_regmap_lookup_by_phandle(np, "st,syscon");
>> +       if (IS_ERR(regmap))
>> +               return PTR_ERR(regmap);
>> +
>> +       err = of_property_read_u32_index(np, "st,syscon", 1, &dwmac->mode_reg);
>> +       if (err) {
>> +               dev_err(dev, "Can't get sysconfig mode offset (%d)\n", err);
>> +               return err;
>> +       }
>> +
>> +       dwmac->interface = of_get_phy_mode(np);
>> +       dwmac->regmap = regmap;
>
> Why the temporary local regmap variable?
>
> Assigning dwmac->regmap with syscon_regmap_lookup_by_phandle() should
> not exceed 80 chars if that is what you are worried about.

yes you are right.

>
>
>> +       return 0;
>> +}
>> +
>> +static int stm32_dwmac_probe(struct platform_device *pdev)
>> +{
>> +       struct plat_stmmacenet_data *plat_dat;
>> +       struct stmmac_resources stmmac_res;
>> +       struct stm32_dwmac *dwmac;
>> +       int ret;
>> +
>> +       ret = stmmac_get_platform_resources(pdev, &stmmac_res);
>> +       if (ret)
>> +               return ret;
>> +
>> +       plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
>> +       if (IS_ERR(plat_dat))
>> +               return PTR_ERR(plat_dat);
>> +
>> +       dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
>> +       if (!dwmac)
>> +               return -ENOMEM;
>> +
>> +       ret = stm32_dwmac_parse_data(dwmac, pdev);
>> +       if (ret) {
>> +               dev_err(&pdev->dev, "Unable to parse OF data\n");
>> +               return ret;
>> +       }
>> +
>> +       plat_dat->bsp_priv = dwmac;
>> +
>> +       ret = stm32_dwmac_init(plat_dat->bsp_priv);
>> +       if (ret)
>> +               return ret;
>> +
>> +       return stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
>
> Note that stmmac_dvr_probe() can fail and if so you should disable
> your tx/rx clks before you return.
>
> Consider putting the clk_prepare_enable() directly here and use goto
> labels for the clean up like most other drivers do in probe.

Ok catch.

>
> Also if you put regmap_update_bits() for phy mode above the
> clk_prepare_enable() calls you remove one of the gotos.
> I assume you don't need to enable tx/rx clock before you write to syscon.

I will check.
>
>
>> +static int stm32_dwmac_remove(struct platform_device *pdev)
>> +{
>> +       struct net_device *ndev = platform_get_drvdata(pdev);
>> +       struct stmmac_priv *priv = netdev_priv(ndev);
>> +       int ret = stmmac_dvr_remove(ndev);
>> +
>> +       stm32_dwmac_exit(priv->plat->bsp_priv);
>> +
>> +       return ret;
>> +}
>> +
>> +#ifdef CONFIG_PM_SLEEP
>> +static int stm32_dwmac_suspend(struct device *dev)
>> +{
>> +       struct net_device *ndev = dev_get_drvdata(dev);
>> +       struct stmmac_priv *priv = netdev_priv(ndev);
>> +       int ret;
>> +
>> +       ret = stmmac_suspend(ndev);
>> +       stm32_dwmac_exit(priv->plat->bsp_priv);
>> +
>> +       return ret;
>> +}
>> +
>> +static int stm32_dwmac_resume(struct device *dev)
>> +{
>> +       struct net_device *ndev = dev_get_drvdata(dev);
>> +       struct stmmac_priv *priv = netdev_priv(ndev);
>> +       int ret;
>> +
>> +       ret = stm32_dwmac_init(priv->plat->bsp_priv);
>> +       if (ret)
>> +               goto out_regmap;
>> +
>> +       ret = stmmac_resume(ndev);
>> +
>> +out_regmap:
>> +       return ret;
>
> Why the goto?

Sorry no sens. I thought that it was better to avoid multiple return
but it this case it is stupid.

Best regards.

Alexandre

>
> This could be written:
>     ret = stm32_dwmac_init(priv->plat->bsp_priv);
>     if (ret)
>        return ret;
>
>     return stmmac_resume(ndev);
>
>
> regards,
> Joachim Eastwood


From arnd at arndb.de  Wed Feb 24 01:04:57 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Feb 2016 10:04:57 +0100
Subject: [PATCH 0/5] Modularize PCI_DW related drivers.
In-Reply-To: <56CD4916.3050904@ti.com>
References: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
 <56CD4916.3050904@ti.com>
Message-ID: <6350001.oOdGGcH81x@wuerfel>

On Wednesday 24 February 2016 11:39:26 Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Monday 08 February 2016 05:30 AM, Paul Gortmaker wrote:
> > In a recent patch series that aimed to remove code related to module
> > unload for PCI support that was simply non modular, the discussion
> > led to people wanting to keep the code and push towards taking the
> > steps needed to support moving it towards tristate instead[1].
> > 
> > Here, we take step one, which is simply making the Kconfig change
> > and then dealing with any build fallout or modpost fallout.  What
> > amounts to essentially a sanity build test.  To be clear, these
> > have not been runtime validated; that will need to be done by those
> > with access to real hardware.  However, the changes are not anything
> > that should disrupt any existing built-in validation, so real world
> > users should not be impacted by this change.
> > 
> > We start with a smaller family of drivers; those that actively select
> > PCI_DW, as a nice self contained group to test the waters and see if
> > everyone is still good with this approach before investing more time
> > on a wider scale to other pci/host/ code blocks.
> > 
> > As such the drivers here share a dependency on having the same group
> > of functions exported in order to successfully complete modpost.
> > 
> > In addition, we have to stray outside drivers/pci to add exports
> > in two places; once for an ARM fault handler, and once for an OF
> > variable.
> > 
> > The pci-keystone-dw.c instance was handled separately because it
> > consists of two source files that need their own group of driver
> > specific exports above and beyond the "shared" ones.
> > 
> > Then we convert the Kconfig for all remaining at once; we could have
> > done it on a per driver basis for ease of revert if anyone really
> > objects, but since it would be a one line change, that seemed like
> > not a real concern.
> > 
> > Build testing was done on the linux-next tree for arm allmodconfig.
> 
> I took these patches and gave a test with DRA7xx board. As expected there was
> no issues when the driver was built-in. However when I tried to rmmod/modprobe
> I got this error [2].

Thanks for testing this!

> [2] -> http://pastebin.ubuntu.com/15185894/

It looks like you are hitting the BUG_ON() in ioremap_pte_range()
that checks if a virtual address already has a page table entry,
which in turn is probably a result of dw_pcie_host_init()
calling pci_remap_iospace() again for the same memory area
it has called the last time, and no cleanup done inbetween.

Could you try adding a pci_unmap_iospace() and calling that
in the device remove function? Let me know if you need help
implementing it.

	Arnd


From marc.zyngier at arm.com  Wed Feb 24 01:05:30 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Feb 2016 09:05:30 +0000
Subject: [PATCH 5/8] arm64: kprobes instruction simulation support
In-Reply-To: <56CD5434.30108@linaro.org>
References: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
 <1455839301-26464-6-git-send-email-dave.long@linaro.org>
 <56C720F0.9080108@arm.com> <56CD5434.30108@linaro.org>
Message-ID: <20160224090530.5e86e867@arm.com>

On Wed, 24 Feb 2016 01:56:52 -0500
David Long <dave.long at linaro.org> wrote:

> On 02/19/2016 09:04 AM, Marc Zyngier wrote:
> > Hi David,
> >
> > On 18/02/16 23:48, David Long wrote:
> >> From: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>
> >>
> >> Kprobes needs simulation of instructions that cannot be stepped
> >> from different memory location, e.g.: those instructions
> >> that uses PC-relative addressing. In simulation, the behaviour
> >> of the instruction is implemented using a copy of pt_regs.
> >>
> >> Following instruction catagories are simulated:
> >>   - All branching instructions(conditional, register, and immediate)
> >>   - Literal access instructions(load-literal, adr/adrp)
> >>
> >> Conditional execution is limited to branching instructions in
> >> ARM v8. If conditions at PSTATE do not match the condition fields
> >> of opcode, the instruction is effectively NOP. Kprobes considers
> >> this case as 'miss'.
> >>
> >> This code also replaces the use of arch/arm/opcodes.c for
> >> arm_check_condition().
> >>
> >> Thanks to Will Cohen for assorted suggested changes.
> >>
> >> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>
> >> Signed-off-by: William Cohen <wcohen at redhat.com>
> >> Signed-off-by: David A. Long <dave.long at linaro.org>

[...]

> >> +};
> >> +
> >> +asmlinkage unsigned int __kprobes arm_check_condition(u32 opcode, u32 psr)
> >
> > Why asmlinkage? This function is never called from assembly code on arm64.
> >
> 
> This comes from the 32-bit ARM code that tests the condition from 
> entry.S.  We include arch/arm/include/asm/opcodes.h in 
> arch/arm64/include/asm/opcodes.h so it gets declared there with 
> asmlinkage. I can remove the asmlinkage in the actual function 
> definition and it still compiles but I'm not sure that is kosher. 

asmlinkage is only meaningful if you're calling it from assembly code.
As you seem to only call it from C code, having asmlinkage is both
pointless and confusing.

> Will Deacon was advocating getting rid of the include of the 32-bit header 
> file but it looked to me like this would mean a lot of duplicated 
> defines and the work would be mostly unrelated to kprobes.

Arguably, arm_check_condition() (which only matters to 32bit code,
hence userspace) is also completely unrelated to kprobes. I still think
Will's point stands.

> 
> >> +{
> >> +	u32 cc_bits  = opcode >> 28;
> >> +
> >> +	if (cc_bits != ARM_OPCODE_CONDITION_UNCOND) {
> >> +		if ((*opcode_condition_checks[cc_bits])(psr))
> >> +			return ARM_OPCODE_CONDTEST_PASS;
> >> +		else
> >> +			return ARM_OPCODE_CONDTEST_FAIL;
> >> +	}
> >> +	return ARM_OPCODE_CONDTEST_UNCOND;
> >> +}
> >> +EXPORT_SYMBOL_GPL(arm_check_condition);
> >
> > Why do we need this to be exported at all? Also, it'd be better located
> > together with the deprecated instruction handling, possibly in a
> > separate patch (nothing uses this function in this patch).
> >
> 
> I've made the function static and moved it to armv8_deprecated.  I have 
> to leave the static functions that test the individual conditions and 
> the global array of pointers to them outside of the conditionally 
> compiled armv8_deprecated.c as they have to always be present for 
> kprobes to simulate a conditional branch.

I think that's fine.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.


From k.kozlowski at samsung.com  Wed Feb 24 01:14:52 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Wed, 24 Feb 2016 18:14:52 +0900
Subject: [PATCH 2/3] ARM: EXYNOS: remove unused register offset definition
In-Reply-To: <56CD6885.4060904@samsung.com>
References: <1456135396-17767-1-git-send-email-pankaj.dubey@samsung.com>
 <1456135396-17767-3-git-send-email-pankaj.dubey@samsung.com>
 <56CBA1BC.4050003@samsung.com> <56CC2238.2040303@samsung.com>
 <56CCEF84.6090502@samsung.com> <56CD6885.4060904@samsung.com>
Message-ID: <56CD748C.7060007@samsung.com>

On 24.02.2016 17:23, pankaj.dubey wrote:
> 
> 
> On Wednesday 24 February 2016 05:17 AM, Krzysztof Kozlowski wrote:
>> On 23.02.2016 18:11, pankaj.dubey wrote:
>>> Hi Krzysztof,
>>>
>>> On Tuesday 23 February 2016 05:33 AM, Krzysztof Kozlowski wrote:
>>>> On 22.02.2016 19:03, Pankaj Dubey wrote:
>>>>> This patch cleans up map.h by removing unused register offset
>>>>> and changing EXYNOS4 to EXYNOS in header comment section.
>>>>>
>>>>> Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
>>>>> ---
>>>>>  arch/arm/mach-exynos/include/mach/map.h | 9 +--------
>>>>>  1 file changed, 1 insertion(+), 8 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
>>>>> index 351e839..c48ba4f 100644
>>>>> --- a/arch/arm/mach-exynos/include/mach/map.h
>>>>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>>>>> @@ -2,7 +2,7 @@
>>>>>   * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
>>>>>   *		http://www.samsung.com/
>>>>>   *
>>>>> - * EXYNOS4 - Memory map definitions
>>>>> + * EXYNOS - Memory map definitions
>>>>>   *
>>>>>   * 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
>>>>> @@ -14,12 +14,6 @@
>>>>>  
>>>>>  #include <plat/map-base.h>
>>>>>  
>>>>> -/*
>>>>> - * EXYNOS4 UART offset is 0x10000 but the older S5P SoCs are 0x400.
>>>>> - * So need to define it, and here is to avoid redefinition warning.
>>>>> - */
>>>>> -#define S3C_UART_OFFSET			(0x10000)
>>>>> -
>>>>>  #include <plat/map-s5p.h>
>>>>
>>>> This does not look good. The S3C_UART_OFFSET is used in plat/map-s5p.h.
>>>>
>>>
>>> Actually it's just defined there but not getting used anywhere. In fact
>>> we can remove it from there also.
>>
>> The point is that your patch introduce changes. Before S3C_UART_OFFSET
>> was defined to 0x10000, after (because of #ifndef) it will be 0x400.
>> Description of "unused" is not accurate. Unused stuff does not impact
>> anything.
>>
>>> So I submitted another patch to
>>> cleanup such redundant register definitions from plat/map-s5p.h.
>>
>> That would be good.
>>
>>> Only platform using S3C_UART_OFFSET is s3c64xx and its using definition
>>> from map-s3c.h. I have compiled all related platform defconfigs and
>>> found no issues because of removal of S3C_UART_OFFSET from map-s5p.c and
>>> map.h.
>>
>> The compilation is not a test. You compiled something like this:
>> -#define S3C_UART_OFFSET			(0x10000)
>>  #ifndef S3C_UART_OFFSET
>>  #define S3C_UART_OFFSET         (0x400)
>>  #endif
>>
>> ... and found no errors. Of course there are no compilation errors! But
>> the value has changed!
>>
> 
> OK. I see, there are quite a few places these definitions are scattered
> even though not used (not used in the sense what ever values these
> macros are taking in code it's not used). Such as
> mach-exynos/include/map.h, plat-samsung/include/plat/{map-s3c.h,
> map-s5p.h} and mach-s3c24xx/include/mach/map.h. So I will remove all
> these in one go.
> Is this fine?

Except the used ones (s3c64xx) - yes, all at once. Some of them depend
on previous ones (ifndef) so "unused" when patching this one-by-one is
not accurate.

> Also I have one doubt in case I am touching files across various mach
> files and preparing a single patch what should be commit message
> heading? Is commit starting with "ARM: samsung" fine? or anything more
> appropriate you would suggest.

It is still the same Samsung tree and either way it would end in the
same branch. ARM: SAMSUNG: is fine (I saw it in the log).

Best regards,
Krzysztof



From hzpeterchen at gmail.com  Wed Feb 24 01:22:52 2016
From: hzpeterchen at gmail.com (Peter Chen)
Date: Wed, 24 Feb 2016 17:22:52 +0800
Subject: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
In-Reply-To: <CAL_Jsq+rqv1NBSUToX5BsbnBp_goUWhdczU7ETSxOrJ5D4D1rw@mail.gmail.com>
References: <CAL411-rK6qfkbQsSjvXH5VPAQAm4tMyD6fVTEgFQrpLHNGMXeA@mail.gmail.com>
 <Pine.LNX.4.44L0.1512181030590.1682-100000@iolanthe.rowland.org>
 <CAL411-qKE=12VZAN9=tUWPqkC5BfSgpQb9aNgCU6rmPLasXNHQ@mail.gmail.com>
 <CAL_Jsq+P8SBmWzNURrmNgz8soCn4QPOPid4SXF0a3TYL_SH27A@mail.gmail.com>
 <20160106032027.GA23726@shlinux2>
 <CAL_Jsq+rqv1NBSUToX5BsbnBp_goUWhdczU7ETSxOrJ5D4D1rw@mail.gmail.com>
Message-ID: <20160224092252.GA9297@shlinux2.ap.freescale.net>

On Thu, Jan 07, 2016 at 08:18:02AM -0600, Rob Herring wrote:
> On Tue, Jan 5, 2016 at 9:20 PM, Peter Chen <hzpeterchen at gmail.com> wrote:
> > On Tue, Jan 05, 2016 at 08:36:31AM -0600, Rob Herring wrote:
> >> > 2. There are MFD USB devices, which includes several interfaces under
> >> > USB device,
> >> > like i2c, gpios, etc. Due to lack of device tree support, USB
> >> > class/device driver doesn't know
> >> > which kinds of interfaces are needed for this board.
> >>
> >> Are you talking about a device hard wired on the same board or
> >> something like GPIOs on FTDI chip which could be hot-plugged in any
> >> host (including non-DT based)?
> >
> > I talked about the case that the device hard wired on the board.
> > Hot-plug device's bus topology is unknown, we can't describe it
> > statically at dts.
> 
> Correct, upstream (the USB side) can't be described, but it is the
> downstream side we care about describing.
> 
> >> For the hotplug case, we will need a way to associate a DT overlay
> >> with the USB device and there may not even be a base DT to map the
> >> overlay into. In this case, the USB device's driver will need to load
> >> the overlay and trigger enumerating the child devices. Anyway, this is
> >> a separate issue from your problem.
> >>
> >
> > Since both you and Alan agree with my problem should be fixed at
> > bootloader, I give the kernel solution up.
> 
> Surprising, no one ever seems to agree with that solution... There
> will be people with this problem and unable to update their
> bootloader.
> 

Hi Rob, I noticed there are still some platform needs to this solution,
I would like to see if I can move this on, please review below dts
solution. In below case, there are two ports on the root hub, one is
USB HUB, the another is a USB wifi. Both of these devices need to have
power control before they can work.

At USB hcd driver, it will try to look-up all USB devices on this
controller, if the usb-pwr-ops is existed, it will try to get its
phandle, and do gpio and clock operations.

Optional properties:
- usb-pwr-ops: the power operations which need to do before this USB device
  can work.

Example:

/ {
	...

	hub_genesys_1_pwr_ops: hub_genesys_1_pwr_ops {
		compatible = "usb-pwrseq-simple";
		reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
		reset-duration-us = <10>;
		clocks = <&clks IMX6QDL_CLK_CKO>;
	};

	wifi_nxp_2_pwr_ops: wifi_nxp_2_pwr_ops {
		compatible = "usb-pwrseq-simple";
		reset-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>, /* wifi_rst */
				<&gpio4 7 GPIO_ACTIVE_LOW>; /* wifi_en */
		reset-duration-us = <10>;
		clocks = <&clks IMX6QDL_CLK_CKO1>;
	};

	...
};

&usb1 {
	status = "okay";

	#address-cells = <1>;
	#size-cells = <0>;

	hub: genesys at 1 {
		compatible = "usb5e3,608";
		reg = <1>;
		usb-pwr-ops = <&hub_genesys_1_pwr_ops>
	};

	wifi: nxp at 2 {
		compatible = "usb5e3,608";
		reg = <2>;
		usb-pwr-ops = <&wifi_nxp_2_pwr_ops>
	};
}

-- 

Best Regards,
Peter Chen


From a0131933 at ti.com  Wed Feb 24 01:29:32 2016
From: a0131933 at ti.com (Lokesh Vutla)
Date: Wed, 24 Feb 2016 14:59:32 +0530
Subject: [PATCH v4 1/3] ARM: hwmod: RTC: Add lock and unlock functions
In-Reply-To: <alpine.DEB.2.02.1602072209460.2182@utopia.booyaka.com>
References: <1454650952-20154-1-git-send-email-lokeshvutla@ti.com>
 <1454650952-20154-2-git-send-email-lokeshvutla@ti.com>
 <alpine.DEB.2.02.1602072209460.2182@utopia.booyaka.com>
Message-ID: <56CD77FC.8030103@ti.com>

Hi Paul,

On Monday 08 February 2016 03:54 AM, Paul Walmsley wrote:
> Hi Lokesh
> 
> I apologize for the delay.
> 
> A few comments:
> 
> On Fri, 5 Feb 2016, Lokesh Vutla wrote:
> 
>> RTC IP have kicker feature which prevents spurious writes to its registers.
>> In order to write into any of the RTC registers, KICK values has to be
>> written to KICK registers.
>> Introduce omap_hwmod_rtc_unlock/lock functions, which  writes into these
>> KICK registers inorder to lock and unlock RTC registers.
>>
>> Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
>> ---
> 
> ...
> 
>> +/**
>> + * omap_rtc_wait_not_busy - Wait for the RTC BUSY flag
>> + * @oh: struct omap_hwmod *
>> + *
>> + * For updating certain RTC registers, the MPU must wait
>> + * for the BUSY status in OMAP_RTC_STATUS_REG to become zero.
>> + * Once the BUSY status is zero, there is a 15-?s access
> 
> Probably best just to write out "microseconds" or "us" here to avoid the 
> high-bit character problem.
> 
>> + * period in which the MPU can program.
>> + */
>> +static void omap_rtc_wait_not_busy(struct omap_hwmod *oh)
>> +{
>> +	int i;
>> +
>> +	/* BUSY may stay active for 1/32768 second (~30 usec) */
>> +	omap_test_timeout(omap_hwmod_read(oh, OMAP_RTC_STATUS_REG)
>> +			  & OMAP_RTC_STATUS_REG, OMAP_RTC_MAX_READY_TIME, i);
> 
> This test looks bogus.  Shouldn't it AND the register value with 
> OMAP_RTC_STATUS_BUSY?  Right now the code is AND-ing with 0x44, which 
> doesn't include the BUSY bit.  So I guess the tests that you mentioned in 
> the first message of the series don't cover the BUSY case?
> 
>> +	/* now we have ~15 usec to read/write various registers */
>> +}
>> +
>> +/**
>> + * omap_hwmod_rtc_unlock - Unlock the Kicker mechanism.
>> + * @oh: struct omap_hwmod *
>> + *
>> + * RTC IP have kicker feature. This prevents spurious writes to its registers.
>> + * In order to write into any of the RTC registers, KICK values has te be
>> + * written in respective KICK registers. This is needed for hwmod to write into
>> + * sysconfig register.
>> + */
>> +void omap_hwmod_rtc_unlock(struct omap_hwmod *oh)
>> +{
>> +	local_irq_disable();
>> +	omap_rtc_wait_not_busy(oh);
>> +	omap_hwmod_write(OMAP_RTC_KICK0_VALUE, oh, OMAP_RTC_KICK0_REG);
>> +	omap_hwmod_write(OMAP_RTC_KICK1_VALUE, oh, OMAP_RTC_KICK1_REG);
>> +	local_irq_enable();
> 
> Finally, could you ask the IP block maintainer to confirm the 
> interpretation that, for any STATUS_REG read where the BUSY bit is 0, that 
> we are guaranteed to have at least 15 microseconds from that point in time 
> to access the IP block?  It appears to be this way from my reading of the 
> TRM; but to me, the phrasing is not explicit.  Another interpretation 
> could be that the BUSY bit reflects the IP block's current status.  If 
> this latter case is true, then to ensure that the IP block accesses 
> complete inside the access window, we'll either need to test the BUSY bit 
> after the writes to ensure that it is still 0, and otherwise repeat the 
> busy test and writes; or we'll need to wait for a 0->1 BUSY transition 
> before we wait for a 1->0 BUSY transition.

As per the HW folks, once SW sees the transistion from 1->0, it is
guaranteed that SW has 15.25 us to do all the write transactions for all
the TC updates.

Also as per TRM, in RTC there are three types of registers:
-> TC registers and TC alarm registers:
-> General registers
-> Compensation registers.

MPU must wait for the BUSY bit for accessing the TC registers and  MPU
can access the general registers at any point of time. SYSCONFIG, KICK
registers comes under general registers. Since hwmod modifies only the
sysconfig register, this omap_rtc_wait_not_busy() is not required here.
We can directly write into sysconfig and KICK registers. Does this sound
fine to you?
Shall I resend this patch without omap_rtc_wait_not_busy()?


Thanks and regards,
Lokesh


> 
>> +}
>> +
>> +/**
>> + * omap_hwmod_rtc_lock - Lock the Kicker mechanism.
>> + * @oh: struct omap_hwmod *
>> + *
>> + * RTC IP have kicker feature. This prevents spurious writes to its registers.
>> + * Once the RTC registers are written, KICK mechanism needs to be locked,
>> + * in order to prevent any spurious writes. This function locks back the RTC
>> + * registers once hwmod completes its write into sysconfig register.
>> + */
>> +void omap_hwmod_rtc_lock(struct omap_hwmod *oh)
>> +{
>> +	local_irq_disable();
>> +	omap_rtc_wait_not_busy(oh);
>> +	omap_hwmod_write(0x0, oh, OMAP_RTC_KICK0_REG);
>> +	omap_hwmod_write(0x0, oh, OMAP_RTC_KICK1_REG);
>> +	local_irq_enable();
>> +}
>> -- 
>> 2.1.4
>>
> 
> 
> - Paul
> 


From Wenyou.Yang at atmel.com  Wed Feb 24 01:33:13 2016
From: Wenyou.Yang at atmel.com (Yang, Wenyou)
Date: Wed, 24 Feb 2016 09:33:13 +0000
Subject: [PATCH v9 0/2] power: act8945a: add charger driver for the
 sub-device of ACT8945A MFD
In-Reply-To: <1455524524-9359-1-git-send-email-wenyou.yang@atmel.com>
References: <1455524524-9359-1-git-send-email-wenyou.yang@atmel.com>
Message-ID: <B256D81BAE5131468A838E5D7A243641D6428FF2@penmbx01>

Hello Sebastian,

> -----Original Message-----
> From: Wenyou Yang [mailto:wenyou.yang at atmel.com]
> Sent: 2016?2?15? 16:22
> To: Sebastian Reichel <sre at kernel.org>; Dmitry Eremin-Solenikov
> <dbaryshkov at gmail.com>; David Woodhouse <dwmw2 at infradead.org>; Rob
> Herring <robh+dt at kernel.org>; Pawel Moll <pawel.moll at arm.com>; Mark Brown
> <broonie at kernel.org>; Ian Campbell <ijc+devicetree at hellion.org.uk>; Kumar
> Gala <galak at codeaurora.org>
> Cc: Krzysztof Kozlowski <k.kozlowski at samsung.com>; Javier Martinez Canillas
> <javier at dowhile0.org>; Lee Jones <lee.jones at linaro.org>; Peter Korsgaard
> <jacmet at gmail.com>; Ferre, Nicolas <Nicolas.FERRE at atmel.com>; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-
> pm at vger.kernel.org; Yang, Wenyou <Wenyou.Yang at atmel.com>
> Subject: [PATCH v9 0/2] power: act8945a: add charger driver for the sub-device
> of ACT8945A MFD
> 
> The ACT8945A is a Multi Function Device with the following subdevices:
>  - Regulator
>  - Charger

I would like to know if this patch set is okay to apply.  Or any comments?

Thanks.

> 
> This patch set is to add regulator driver for ACT8945A.
> It is based on the patch set:
> 	http://lists.infradead.org/pipermail/linux-arm-kernel/2016-
> February/405258.html
> 
> Changes in v9:
>  - add check if charger->regmap is a NULL pointer.
>  - collect Reviewed-by tag.
> 
> Changes in v8:
>  - remove the OF table.
>  - due to the mfd cell .of_compatible removal, use the platform
>    device's parent of_node to read the property and assign it
>    to the psy_cfg.of_node.
>  - fix the typo.
>  - due the mfd cell .of_compatible removal, update the compatibe
>    description and example.
> 
> Changes in v7:
>  - use the helper dev_get_regmap(pdev->dev.parent, NULL) to get regmap.
>  - remove *act8945a_dev member from struct act8945a_charger.
>  - remove *psy member from struct act8945a_charger.
>  - merge _parse_dt() and _charger_config() functions, remove relevent
>    members from struct act8945a_charger.
>  - remove unused platform_set_drvdata(pdev, charger) statement.
> 
> Changes in v6:
>  - change the type value to unsigned int.
> 
> Changes in v5:
>  - remove spare spaces after #define.
>  - add OF match table.
>  - collect Reviewed-by from Krzysztof.
> 
> Changes in v4:
>  - use spaces after #define, not tabs.
>  - use BIT(n) macros to substitute (0x01 << x).
>  - change dt properties with more legible name.
>  - change the properties with more legible name, clearer description.
> 
> Changes in v3:
>  - update the file header with short version license and author line.
>  - remove unused member of struct act8945a_charger, dev.
>  - action due to removing the member of stuct act8945a_dev, dev.
>  - remove the unnecessary print out.
>  - remove the unnecessary act8945a_charger_remove().
>  - fix align of the code-style.
> 
> Changes in v2:
>  1./ Substitute of_property_read_bool() for of_get_property().
>  2./ Substitute devm_power_supply_register() for power_supply_register().
>  3./ Use module_platform_driver(), instead of subsys_initcall().
>  4./ Substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").
> 
> Wenyou Yang (2):
>   power: act8945a: add charger driver for ACT8945A
>   power: add documentation for ACT8945A's charger DT bindings
> 
>  .../devicetree/bindings/power/act8945a-charger.txt |   35 ++
>  drivers/power/Kconfig                              |    7 +
>  drivers/power/Makefile                             |    1 +
>  drivers/power/act8945a_charger.c                   |  359 ++++++++++++++++++++
>  4 files changed, 402 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/act8945a-
> charger.txt
>  create mode 100644 drivers/power/act8945a_charger.c
> 
> --
> 1.7.9.5


Best Regards,
Wenyou Yang


From peter.chen at nxp.com  Wed Feb 24 01:33:59 2016
From: peter.chen at nxp.com (Peter Chen)
Date: Wed, 24 Feb 2016 09:33:59 +0000
Subject: [PATCH v1] ARM: dts: nitrogen6x: add USB host 1 support
In-Reply-To: <CAOMZO5BoPtUfL6PVzqLkZvwvn4=zNTTYgR1u4TOe4268cu+WLg@mail.gmail.com>
References: <1456171421-10044-1-git-send-email-ps.report@gmx.net>
 <56CB7438.5030102@boundarydevices.com>
 <CAOMZO5BoPtUfL6PVzqLkZvwvn4=zNTTYgR1u4TOe4268cu+WLg@mail.gmail.com>
Message-ID: <HE1PR04MB14503F844CF2C8E898DB03DE8BA50@HE1PR04MB1450.eurprd04.prod.outlook.com>

 
> 
> On Mon, Feb 22, 2016 at 5:48 PM, Troy Kisky
> <troy.kisky at boundarydevices.com> wrote:
> 
> > I'm ok with this patch, but a more correct fix would be to add a
> > reset-gpios to usbh1 instead, as this is a reset pin for a usb hub. So
> > if nobody else has a problem,
> 
> The problem is that such solution does not exist today.
> 
> Peter Chen has been working on it lately.

Yes, I will cc you when I send new patch.

Peter

From xinliang.liu at linaro.org  Wed Feb 24 01:38:27 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Wed, 24 Feb 2016 17:38:27 +0800
Subject: [PATCH v7 0/5] Add mipi dsi support for rk3288
In-Reply-To: <56B869F4.6090507@codeaurora.org>
References: <1452053038-32098-1-git-send-email-zyw@rock-chips.com>
 <56B869F4.6090507@codeaurora.org>
Message-ID: <CAGd==049mj+K5u28SQQR+7Fh5aj-fGfOZtuPFHodmCZyKQhmqQ@mail.gmail.com>

On 8 February 2016 at 18:12, Archit Taneja <architt at codeaurora.org> wrote:
> Hi,
>
> On 01/06/2016 09:33 AM, Chris Zhong wrote:
>>
>>
>> The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
>> IP. This series adds support for a Synopsys DesignWare MIPI DSI host
>> controller DRM driver.
>>
>> The MIPI DSI feature is tested on rk3288 evb board, backport them to
>> chrome os kernel chrome_v3.14, and it can display normally.
>>
>> This patchset is base on the patchset from Ying.liu at freescale.com.
>> <http://www.spinics.net/lists/dri-devel/msg77181.html>
>>
>> According to the suggestion from Thierry, I have get rid of the bridge,
>> and register the encoder & connecter in drm/rockchip/dw-mipi-dsi.c.
>
>
> I've raised this question too late, but what was the reason to not
> implement the DSI block as a bridge driver?
>
> The drm/hisilicon IP seems to use a very similar DSI Designware IP (the
> register offsets seems to be the same). There is a good potential of
> re-use here by different kms drivers here the way it's already done for
> DW HDMI and the analogix DP driver that's in review process.

yes, Hisilicon's hi6220 SoC use a Designware DSI Controller IP similar
to rockchip.
Maybe the version number is different.
I notice this recently when I am doing the upstream of hi6220's DRM driver.

And I have a look at Ying liu's original patches. It seems that it is
implemented in bridge.
His patches were sent in the early of last year, I can't get all the
background easily.
I wonder why his patches was not accecpted? What's the problem? And
why Thierry suggested get rid of bridge?

Thanks,
-xinliang

>
> Archit
>
>
>> After backport below patches from linux-next, I can merge this serial into
>> Dave's drm-next branch.
>>
>> 94d5d6a0fbf3 clk: rockchip: add an id for rk3288 crypto clk
>> c6d49fbcfcc4 clk: rockchip: add id for mipidsi sclk on rk3288
>> a2f4c560f18e clk: rockchip: add mipidsi clock on rk3288
>> 69c923743640 ARM: dts: rockchip: correct the name of REG8 for
>> rk3288-evb-act8846
>> 662513a14c9d ARM: dts: rockchip: add 2 regulators for rk3288-evb-act8846
>> b04061e6599b ARM: dts: rockchip: move the public part to rk3288-evb common
>>
>>
>> Changes in v7:
>> - modify the config to tristate for modules build (Mark Yao)
>> - Pass NULL 'name' to drm_encoder_init() to fix compile err (Mark Yao)
>> - Move the lcd_en control to act8846 dts
>>
>> Changes in v6:
>> - update the document, since the bridge device has been deleted.
>> - move the mipi_en gate to ockchip_drm_crtc_mode_config
>> - Remove the atomic feature check (Mark Yao)
>> - Add atomic API support (Heiko St?bne)
>> - Do not use bridge driver (Thierry Reding)
>> - Optimization the phy init sequence
>>
>> Changes in v5:
>> - modify the clk name to SCLK_MIPIDSI_24M
>> - add a blank line befor lcd_en
>>
>> Changes in v4:
>> - use clk_round_rate to check the clock rate in vop_crtc_mode_fixup
>>
>> Changes in v3:
>> - move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/
>>
>> Chris Zhong (5):
>>    drm/rockchip: return a true clock rate to adjusted_mode
>>    Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver
>>    drm: rockchip: Support Synopsys DW MIPI DSI
>>    ARM: dts: rockchip: add rk3288 mipi_dsi nodes
>>    ARM: dts: rockchip: add support mipi panel tv080wum-nl0
>>
>>   .../display/rockchip/dw_mipi_dsi_rockchip.txt      |   60 +
>>   arch/arm/boot/dts/rk3288-evb-act8846.dts           |    2 +
>>   arch/arm/boot/dts/rk3288-evb.dtsi                  |   12 +-
>>   arch/arm/boot/dts/rk3288.dtsi                      |   39 +
>>   drivers/gpu/drm/rockchip/Kconfig                   |   10 +
>>   drivers/gpu/drm/rockchip/Makefile                  |    1 +
>>   drivers/gpu/drm/rockchip/dw-mipi-dsi.c             | 1196
>> ++++++++++++++++++++
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c        |    8 +
>>   8 files changed, 1327 insertions(+), 1 deletion(-)
>>   create mode 100644
>> Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
>>   create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c
>>
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation


From ykk at rock-chips.com  Wed Feb 24 02:05:03 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Wed, 24 Feb 2016 18:05:03 +0800
Subject: [PATCH v1 0/4] Add clock ids for RK3228 HDMI/VOP modules
Message-ID: <1456308303-29706-1-git-send-email-ykk@rock-chips.com>


Add clocks ids for RK3228 HDMI/VOP modules which driver already have been
posted.

RK3228 HDMI driver: https://patchwork.kernel.org/patch/7974671
RK3228 VOP driver: https://patchwork.kernel.org/patch/7952591

Yakir Yang (4):
  clk: rockchip: add the new clock ids for RK3228 VOP
  clk: rockchip: set the clock ids for RK3228 VOP
  clk: rockchip: add the new clock ids for RK3228 HDMI
  clk: rockchip: set the clock ids for RK3228 HDMI

 drivers/clk/rockchip/clk-rk3228.c      | 14 +++++++-------
 include/dt-bindings/clock/rk3228-cru.h | 10 ++++++++++
 2 files changed, 17 insertions(+), 7 deletions(-)

-- 
1.9.1




From ykk at rock-chips.com  Wed Feb 24 02:08:20 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Wed, 24 Feb 2016 18:08:20 +0800
Subject: [PATCH v1 1/4] clk: rockchip: add the new clock ids for RK3228 VOP
In-Reply-To: <1456308303-29706-1-git-send-email-ykk@rock-chips.com>
References: <1456308303-29706-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1456308500-30075-1-git-send-email-ykk@rock-chips.com>

There are four clocks that vop module would need to operate:
    DCLK_VOP,  HCLK_VOP,  SCLK_VOP,  ACLK_VOP,

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
---
 include/dt-bindings/clock/rk3228-cru.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/include/dt-bindings/clock/rk3228-cru.h b/include/dt-bindings/clock/rk3228-cru.h
index a78dd89..5656bf6 100644
--- a/include/dt-bindings/clock/rk3228-cru.h
+++ b/include/dt-bindings/clock/rk3228-cru.h
@@ -49,10 +49,15 @@
 #define SCLK_SDMMC_SAMPLE	118
 #define SCLK_SDIO_SAMPLE	119
 #define SCLK_EMMC_SAMPLE	121
+#define SCLK_VOP		122
+
+/* dclk gates */
+#define DCLK_VOP		190
 
 /* aclk gates */
 #define ACLK_DMAC		194
 #define ACLK_PERI		210
+#define ACLK_VOP		211
 
 /* pclk gates */
 #define PCLK_GPIO0		320
@@ -73,6 +78,7 @@
 #define PCLK_PERI		363
 
 /* hclk gates */
+#define HCLK_VOP		452
 #define HCLK_NANDC		453
 #define HCLK_SDMMC		456
 #define HCLK_SDIO		457
-- 
1.9.1




From kernel at tekno-soft.it  Wed Feb 24 02:12:19 2016
From: kernel at tekno-soft.it (Roberto Fichera)
Date: Wed, 24 Feb 2016 11:12:19 +0100
Subject: iMX6q PCIe phy link never came up on kernel v4.4.x
Message-ID: <56CD8203.8050209@tekno-soft.it>

Hi There,

Working on a custom iMX6q board I'm getting a PCIe phy link never came up, even if uboot detect
everything ok. My DTS is enabling PCIe with

&pcie {
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_pcie_reset>;
    reset-gpio = <&gpio7 12 0>;
    status = "okay";
};

The PCIe is connected to a PCIe-to-PCI TI XIO2001, so I'd like to know if there is any other special
setup to do in order to get it to work on a v4.4.x kernel.

Any idea?

Thanks in advance,
Roberto Fichera.

U-Boot 2014.04-imx_v2014.04_3.14.38_6qp_beta+g6e9282c (Feb 15 2016 - 10:02:31)

CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
CPU:   Temperature 35 C, calibration data: 0x5664d569
Reset cause: POR
Board: Janas iMX6Q (ID:e315c064140749d4)
I2C:   ready
DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
*** Warning - bad CRC, using default environment

  00:01.0     - 16c3:abcd - Bridge device
   01:00.0    - 104c:8240 - Bridge device
    02:04.0   - 1397:08b4 - Network controller
In:    serial
Out:   serial
Err:   serial
Found PFUZE100! deviceid=10,revid=21
mmc1(part 0) is current device
Net:   FEC [PRIME]
Warning: failed to set MAC address

Normal Boot
....
....
[    0.236141] PCI host bridge /soc/pcie at 0x01000000 ranges:
[    0.236162]   No bus range found for /soc/pcie at 0x01000000, using [bus 00-ff]
[    0.236213]   err 0x01f00000..0x01f7ffff -> 0x01f00000
[    0.236250]    IO 0x01f80000..0x01f8ffff -> 0x00000000
[    0.236330]   MEM 0x01000000..0x01efffff -> 0x01000000
-->>> [    0.546690] imx6q-pcie 1ffc000.pcie: phy link never came up
[    0.547263] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[    0.547287] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.547304] pci_bus 0000:00: root bus resource [??? 0x01f00000-0x01f7ffff flags 0x0]
[    0.547321] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    0.547335] pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
[    0.548608] PCI: bus0: Fast back to back transfers disabled
[    0.548950] PCI: bus1: Fast back to back transfers enabled
[    0.549107] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
[    0.549137] pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
[    0.549159] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.549945] pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt
...


From lokeshvutla at ti.com  Wed Feb 24 02:11:04 2016
From: lokeshvutla at ti.com (Lokesh Vutla)
Date: Wed, 24 Feb 2016 15:41:04 +0530
Subject: [PATCH] ARM: dts: DRA7: change address-cells and size-cells
Message-ID: <1456308664-28308-1-git-send-email-lokeshvutla@ti.com>

DRA7 SoC has the capability to support DDR memory upto 4GB. In order to
represent this in memory dt node, the address-cells and size cells
should be 2. So, changing the address-cells and size-cells to 2 and
updating the memory nodes accordingly.

Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts   |  2 +-
 arch/arm/boot/dts/am57xx-cl-som-am57x.dts |  2 +-
 arch/arm/boot/dts/dra7-evm.dts            |  2 +-
 arch/arm/boot/dts/dra7.dtsi               | 20 ++++++++++----------
 arch/arm/boot/dts/dra72-evm.dts           |  2 +-
 5 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 50312f8..9b664c5 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -24,7 +24,7 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x80000000 0x80000000>;
+		reg = <0x0 0x80000000 0x0 0x80000000>;
 	};
 
 	vdd_3v3: fixedregulator-vdd_3v3 {
diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
index c538826..e6c40db 100644
--- a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
+++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
@@ -21,7 +21,7 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x80000000 0x20000000>; /* 512 MB - minimal configuration */
+		reg = <0x0 0x80000000 0x0 0x20000000>; /* 512 MB - minimal configuration */
 	};
 
 	leds {
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index cfc24e5..2d1d3dd 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -18,7 +18,7 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x80000000 0x60000000>; /* 1536 MB */
+		reg = <0x0 0x80000000 0x0 0x60000000>; /* 1536 MB */
 	};
 
 	evm_3v3_sd: fixedregulator-sd {
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8ea153a..5460a2a 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -15,8 +15,8 @@
 #define MAX_SOURCES 400
 
 / {
-	#address-cells = <1>;
-	#size-cells = <1>;
+	#address-cells = <2>;
+	#size-cells = <2>;
 
 	compatible = "ti,dra7xx";
 	interrupt-parent = <&crossbar_mpu>;
@@ -57,10 +57,10 @@
 		compatible = "arm,cortex-a15-gic";
 		interrupt-controller;
 		#interrupt-cells = <3>;
-		reg = <0x48211000 0x1000>,
-		      <0x48212000 0x1000>,
-		      <0x48214000 0x2000>,
-		      <0x48216000 0x2000>;
+		reg = <0x0 0x48211000 0x0 0x1000>,
+		      <0x0 0x48212000 0x0 0x1000>,
+		      <0x0 0x48214000 0x0 0x2000>,
+		      <0x0 0x48216000 0x0 0x2000>;
 		interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
 		interrupt-parent = <&gic>;
 	};
@@ -69,7 +69,7 @@
 		compatible = "ti,omap5-wugen-mpu", "ti,omap4-wugen-mpu";
 		interrupt-controller;
 		#interrupt-cells = <3>;
-		reg = <0x48281000 0x1000>;
+		reg = <0x0 0x48281000 0x0 0x1000>;
 		interrupt-parent = <&gic>;
 	};
 
@@ -96,10 +96,10 @@
 		compatible = "ti,dra7-l3-noc", "simple-bus";
 		#address-cells = <1>;
 		#size-cells = <1>;
-		ranges;
+		ranges = <0x0 0x0 0x0 0xc0000000>;
 		ti,hwmods = "l3_main_1", "l3_main_2";
-		reg = <0x44000000 0x1000000>,
-		      <0x45000000 0x1000>;
+		reg = <0x0 0x44000000 0x0 0x1000000>,
+		      <0x0 0x45000000 0x0 0x1000>;
 		interrupts-extended = <&crossbar_mpu GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
 				      <&wakeupgen GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
 
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 00b1200..6a5b0c8 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -17,7 +17,7 @@
 
 	memory {
 		device_type = "memory";
-		reg = <0x80000000 0x40000000>; /* 1024 MB */
+		reg = <0x0 0x80000000 0x0 0x40000000>; /* 1024 MB */
 	};
 
 	aliases {
-- 
2.1.4



From ykk at rock-chips.com  Wed Feb 24 02:14:25 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Wed, 24 Feb 2016 18:14:25 +0800
Subject: [PATCH v1 3/4] clk: rockchip: add the new clock ids for RK3228 HDMI
In-Reply-To: <1456308303-29706-1-git-send-email-ykk@rock-chips.com>
References: <1456308303-29706-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1456308865-30876-1-git-send-email-ykk@rock-chips.com>

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
---
 include/dt-bindings/clock/rk3228-cru.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/dt-bindings/clock/rk3228-cru.h b/include/dt-bindings/clock/rk3228-cru.h
index 5656bf6..fda9308 100644
--- a/include/dt-bindings/clock/rk3228-cru.h
+++ b/include/dt-bindings/clock/rk3228-cru.h
@@ -50,9 +50,11 @@
 #define SCLK_SDIO_SAMPLE	119
 #define SCLK_EMMC_SAMPLE	121
 #define SCLK_VOP		122
+#define SCLK_HDMI_HDCP		123
 
 /* dclk gates */
 #define DCLK_VOP		190
+#define DCLK_HDMI_PHY		191
 
 /* aclk gates */
 #define ACLK_DMAC		194
@@ -76,6 +78,8 @@
 #define PCLK_PWM		350
 #define PCLK_TIMER		353
 #define PCLK_PERI		363
+#define PCLK_HDMI_CTRL		364
+#define PCLK_HDMI_PHY		365
 
 /* hclk gates */
 #define HCLK_VOP		452
-- 
1.9.1




From borntraeger at de.ibm.com  Wed Feb 24 02:16:34 2016
From: borntraeger at de.ibm.com (Christian Borntraeger)
Date: Wed, 24 Feb 2016 11:16:34 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160223202233.GE27281@arm.com>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name> <56BE00E7.1010303@de.ibm.com>
 <20160212181640.4eabb85f@thinkpad> <20160223103221.GA1418@node.shutemov.name>
 <20160223191907.25719a4d@thinkpad>
 <20160223193345.GC21820@node.shutemov.name> <20160223202233.GE27281@arm.com>
Message-ID: <56CD8302.9080202@de.ibm.com>

On 02/23/2016 09:22 PM, Will Deacon wrote:
> On Tue, Feb 23, 2016 at 10:33:45PM +0300, Kirill A. Shutemov wrote:
>> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
>>> I'll check with Martin, maybe it is actually trivial, then we can
>>> do a quick test it to rule that one out.
>>
>> Oh. I found a bug in __split_huge_pmd_locked(). Although, not sure if it's
>> _the_ bug.
>>
>> pmdp_invalidate() is called for the wrong address :-/
>> I guess that can be destructive on the architecture, right?
> 
> FWIW, arm64 ignores the address parameter for set_pmd_at, so this would
> only result in the TLBI nuking the wrong entries, which is going to be
> tricky to observe in practice given that we install a table entry
> immediately afterwards that maps the same pages. If s390 does more here
> (I see some magic asm using the address), that could be the answer...

This patch does not change the address for set_pmd_at, it does that for the 
pmdp_invalidate here (by keeping haddr at the start of the pmd)

--->    pmdp_invalidate(vma, haddr, pmd);
        pmd_populate(mm, pmd, pgtable);
 



Without that fix we would clearly have stale tlb entries, no?




From ykk at rock-chips.com  Wed Feb 24 02:16:28 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Wed, 24 Feb 2016 18:16:28 +0800
Subject: [PATCH v1 4/4] clk: rockchip: set the clock ids for RK3228 HDMI
In-Reply-To: <1456308303-29706-1-git-send-email-ykk@rock-chips.com>
References: <1456308303-29706-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1456308988-30974-1-git-send-email-ykk@rock-chips.com>

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
---
 drivers/clk/rockchip/clk-rk3228.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3228.c b/drivers/clk/rockchip/clk-rk3228.c
index 8747b25..a8a6be2 100644
--- a/drivers/clk/rockchip/clk-rk3228.c
+++ b/drivers/clk/rockchip/clk-rk3228.c
@@ -285,7 +285,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[] __initdata = {
 			RK2928_CLKSEL_CON(23), 14, 2, MFLAGS, 8, 6, DFLAGS,
 			RK2928_CLKGATE_CON(3), 5, GFLAGS),
 
-	GATE(0, "sclk_hdmi_hdcp", "xin24m", 0,
+	GATE(SCLK_HDMI_HDCP, "sclk_hdmi_hdcp", "xin24m", 0,
 			RK2928_CLKGATE_CON(3), 7, GFLAGS),
 
 	COMPOSITE(0, "sclk_hdmi_cec", mux_sclk_hdmi_cec_p, 0,
@@ -364,7 +364,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[] __initdata = {
 			RK2928_CLKGATE_CON(3), 1, GFLAGS),
 	MUX(0, "sclk_vop_src", mux_sclk_vop_src_p, 0,
 			RK2928_CLKSEL_CON(27), 0, 1, MFLAGS),
-	DIV(0, "dclk_hdmiphy", "sclk_vop_src", 0,
+	DIV(DCLK_HDMI_PHY, "dclk_hdmiphy", "sclk_vop_src", 0,
 			RK2928_CLKSEL_CON(29), 0, 3, DFLAGS),
 	DIV(0, "sclk_vop_pre", "sclk_vop_src", 0,
 			RK2928_CLKSEL_CON(27), 8, 8, DFLAGS),
@@ -517,7 +517,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[] __initdata = {
 	GATE(0, "hclk_vop_noc", "hclk_vio_pre", 0, RK2928_CLKGATE_CON(13), 13, GFLAGS),
 	GATE(0, "hclk_vio_h2p", "hclk_vio_pre", 0, RK2928_CLKGATE_CON(14), 7, GFLAGS),
 	GATE(0, "hclk_hdcp_mmu", "hclk_vio_pre", 0, RK2928_CLKGATE_CON(14), 12, GFLAGS),
-	GATE(0, "pclk_hdmi_ctrl", "hclk_vio_pre", 0, RK2928_CLKGATE_CON(14), 6, GFLAGS),
+	GATE(PCLK_HDMI_CTRL, "pclk_hdmi_ctrl", "hclk_vio_pre", 0, RK2928_CLKGATE_CON(14), 6, GFLAGS),
 	GATE(0, "pclk_vio_h2p", "hclk_vio_pre", 0, RK2928_CLKGATE_CON(14), 8, GFLAGS),
 	GATE(0, "pclk_hdcp", "hclk_vio_pre", 0, RK2928_CLKGATE_CON(14), 11, GFLAGS),
 
@@ -590,7 +590,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[] __initdata = {
 
 	GATE(0, "pclk_ddrphy", "pclk_phy_pre", 0, RK2928_CLKGATE_CON(10), 3, GFLAGS),
 	GATE(0, "pclk_acodecphy", "pclk_phy_pre", 0, RK2928_CLKGATE_CON(10), 5, GFLAGS),
-	GATE(0, "pclk_hdmiphy", "pclk_phy_pre", 0, RK2928_CLKGATE_CON(10), 7, GFLAGS),
+	GATE(PCLK_HDMI_PHY, "pclk_hdmiphy", "pclk_phy_pre", 0, RK2928_CLKGATE_CON(10), 7, GFLAGS),
 	GATE(0, "pclk_vdacphy", "pclk_phy_pre", 0, RK2928_CLKGATE_CON(10), 8, GFLAGS),
 	GATE(0, "pclk_phy_noc", "pclk_phy_pre", 0, RK2928_CLKGATE_CON(10), 9, GFLAGS),
 
-- 
1.9.1




From peter.maydell at linaro.org  Wed Feb 24 02:18:33 2016
From: peter.maydell at linaro.org (Peter Maydell)
Date: Wed, 24 Feb 2016 10:18:33 +0000
Subject: [PATCH] ARM: realview: DT support for the PBA8
In-Reply-To: <1456303714-31039-1-git-send-email-linus.walleij@linaro.org>
References: <1456303714-31039-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <CAFEAcA8hH2Q0LXp_vDiyTCLYX4xFff_fkp7=saPmi-ET104SHw@mail.gmail.com>

On 24 February 2016 at 08:48, Linus Walleij <linus.walleij at linaro.org> wrote:
> This adds a devicetree for the ARM RealView PBA8 platform,
> also known as HBI-0178, "RealView(R) Platform Baseboard for
> Cortex(TM)-A8".
>
> Tested in QEMU with -M realview-pb-a8 and works like a charm,
> however with these annoying boot messages:
>
> of_amba_device_create(): amba_device_add()
>     failed (-19) for /soc/sysctl at 10001000
> of_amba_device_create(): amba_device_add()
>     failed (-19) for /soc/ssp at 1000d000
> of_amba_device_create(): amba_device_add()
>     failed (-19) for /soc/timer at 10018000
> of_amba_device_create(): amba_device_add()
>     failed (-19) for /soc/timer at 10019000
> of_amba_device_create(): amba_device_add()
>     failed (-19) for /soc/sysctl at 1001a000

The missing timers would be a two-line QEMU patch,
as would the ssp, since we have SP804 and PL022 device
models. We have no model of the SP810 but it would probably
not be too hard to write a "mostly does nothing" version.
Patches welcome :-)

thanks
-- PMM


From wsa at the-dreams.de  Wed Feb 24 02:19:49 2016
From: wsa at the-dreams.de (Wolfram Sang)
Date: Wed, 24 Feb 2016 11:19:49 +0100
Subject: [RESEND PATCH V7 4/6] i2c: qup: Add bam dma capabilities
In-Reply-To: <1456142895-32646-1-git-send-email-sricharan@codeaurora.org>
References: <1456142895-32646-1-git-send-email-sricharan@codeaurora.org>
Message-ID: <20160224101949.GB1391@katana>

On Mon, Feb 22, 2016 at 05:38:15PM +0530, Sricharan R wrote:
> QUP cores can be attached to a BAM module, which acts as
> a dma engine for the QUP core. When DMA with BAM is enabled,
> the BAM consumer pipe transmitted data is written to the
> output FIFO and the BAM producer pipe received data is read
> from the input FIFO.
> 
> With BAM capabilities, qup-i2c core can transfer more than
> 256 bytes, without a 'stop' which is not possible otherwise.
> 
> Signed-off-by: Sricharan R <sricharan at codeaurora.org>
> Reviewed-by: Andy Gross <andy.gross at linaro.org>
> Tested-by: Archit Taneja <architt at codeaurora.org>
> Tested-by: Telkar Nagender <ntelkar at codeaurora.org>

Applied to for-next, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/096b241c/attachment.sig>

From will.deacon at arm.com  Wed Feb 24 02:23:52 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Feb 2016 10:23:52 +0000
Subject: [PATCH] arm64: Fix misspellings in comments.
In-Reply-To: <1456270006-26035-1-git-send-email-adam.buchbinder@gmail.com>
References: <1456270006-26035-1-git-send-email-adam.buchbinder@gmail.com>
Message-ID: <20160224102351.GB28310@arm.com>

On Tue, Feb 23, 2016 at 03:26:46PM -0800, Adam Buchbinder wrote:
> Signed-off-by: Adam Buchbinder <adam.buchbinder at gmail.com>
> ---
>  arch/arm64/boot/dts/nvidia/tegra132.dtsi | 2 +-
>  arch/arm64/boot/dts/nvidia/tegra210.dtsi | 2 +-
>  arch/arm64/include/asm/ftrace.h          | 2 +-
>  arch/arm64/include/asm/kvm_arm.h         | 2 +-
>  arch/arm64/include/asm/kvm_host.h        | 4 ++--
>  arch/arm64/kernel/fpsimd.c               | 2 +-
>  arch/arm64/kernel/kgdb.c                 | 4 ++--
>  arch/arm64/kernel/signal32.c             | 2 +-
>  arch/arm64/lib/memcmp.S                  | 2 +-
>  9 files changed, 11 insertions(+), 11 deletions(-)

[...]

> diff --git a/arch/arm64/lib/memcmp.S b/arch/arm64/lib/memcmp.S
> index ffbdec0..dc5f17c 100644
> --- a/arch/arm64/lib/memcmp.S
> +++ b/arch/arm64/lib/memcmp.S
> @@ -211,7 +211,7 @@ CPU_LE( lsr	tmp2, tmp2, tmp1 )
>  .Lunequal_proc:
>  	cbz	diff, .Lremain8
>  
> -/*There is differnence occured in the latest comparison.*/
> +/*There is differnence occurred in the latest comparison.*/

If you insist on doing this, please do it properly.

Will


From will.deacon at arm.com  Wed Feb 24 02:41:40 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Feb 2016 10:41:40 +0000
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <56CD8302.9080202@de.ibm.com>
References: <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160223103221.GA1418@node.shutemov.name>
 <20160223191907.25719a4d@thinkpad>
 <20160223193345.GC21820@node.shutemov.name>
 <20160223202233.GE27281@arm.com> <56CD8302.9080202@de.ibm.com>
Message-ID: <20160224104139.GC28310@arm.com>

On Wed, Feb 24, 2016 at 11:16:34AM +0100, Christian Borntraeger wrote:
> On 02/23/2016 09:22 PM, Will Deacon wrote:
> > On Tue, Feb 23, 2016 at 10:33:45PM +0300, Kirill A. Shutemov wrote:
> >> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> >>> I'll check with Martin, maybe it is actually trivial, then we can
> >>> do a quick test it to rule that one out.
> >>
> >> Oh. I found a bug in __split_huge_pmd_locked(). Although, not sure if it's
> >> _the_ bug.
> >>
> >> pmdp_invalidate() is called for the wrong address :-/
> >> I guess that can be destructive on the architecture, right?
> > 
> > FWIW, arm64 ignores the address parameter for set_pmd_at, so this would
> > only result in the TLBI nuking the wrong entries, which is going to be
> > tricky to observe in practice given that we install a table entry
> > immediately afterwards that maps the same pages. If s390 does more here
> > (I see some magic asm using the address), that could be the answer...
> 
> This patch does not change the address for set_pmd_at, it does that for the 
> pmdp_invalidate here (by keeping haddr at the start of the pmd)
> 
> --->    pmdp_invalidate(vma, haddr, pmd);
>         pmd_populate(mm, pmd, pgtable);

On arm64, pmdp_invalidate looks like:

void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
		     pmd_t *pmdp)
{
	pmd_t entry = *pmdp;
	set_pmd_at(vma->vm_mm, address, pmdp, pmd_mknotpresent(entry));
	flush_pmd_tlb_range(vma, address, address + hpage_pmd_size);
}

so that's the set_pmd_at call I was referring to.

On s390, that address ends up in __pmdp_idte[_local], but I don't know
what .insn rrf,0xb98e0000,%2,%3,0,{0,1} do ;)

> Without that fix we would clearly have stale tlb entries, no?

Yes, but AFAIU the sequence on arm64 is:

1.  trans huge mapping (block mapping in arm64 speak)
2.  faulting entry (pmd_mknotpresent)
3.  tlb invalidation
4.  table entry mapping the same pages as (1).

so if the microarchitecture we're on can tolerate a mixture of block
mappings and page mappings mapping the same VA to the same PA, then the
lack of TLB maintenance would go unnoticed. There are certainly systems
where that could cause an issue, but I believe the one I've been testing
on would be ok.

Will


From p.zabel at pengutronix.de  Wed Feb 24 02:42:37 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Wed, 24 Feb 2016 11:42:37 +0100
Subject: [PATCH v4 0/3] reset: Add support for shared reset controls
In-Reply-To: <1456249586-12101-1-git-send-email-hdegoede@redhat.com>
References: <1456249586-12101-1-git-send-email-hdegoede@redhat.com>
Message-ID: <1456310557.3396.34.camel@pengutronix.de>

Hi Hans,

Am Dienstag, den 23.02.2016, 18:46 +0100 schrieb Hans de Goede:
> Hi All,
> 
> Here is v4 of my shared reset-controls patch.
> 
> Changes in v3:
> -Rewrite as result of mailinglist discussions changing the API

Thank you, I have applied them with a small fixup on
  git://git.pengutronix.de/git/pza/linux.git reset/next

best regards
Philipp



From linux at arm.linux.org.uk  Wed Feb 24 02:46:38 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 24 Feb 2016 10:46:38 +0000
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56CC546A.9070705@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
 <56CC546A.9070705@ti.com>
Message-ID: <20160224104638.GL19428@n2100.arm.linux.org.uk>

On Tue, Feb 23, 2016 at 02:45:30PM +0200, Tomi Valkeinen wrote:
> My opinion is that the bootloader should be responsible for telling the
> kernel what hardware there is on the board. For busses like PCI we have
> proper probing mechanism with global unique identifiers for the devices,
> and nothing is needed from the bootloader.

Exactly, but that is _NOT_ the case here, because we're not talking
about an on-board display.

> In the Versatile case the panels are kind of probeable, but not in the
> same sense as PCI: all that can be probed on Versatile is a board
> specific ID, which in itself doesn't tell what kind of panel there is.
> In addition to the ID we need board specific tables listing the details
> of the panels.

That argument does not stack up.  Just because you've plugged in a
network device does not mean that the kernel can drive it: the kernel
needs a device specific driver, which is determined by looking at the
IDs.  There is no standard network driver PCI interface.

> I think one of the core questions here is: do we want to start adding
> board specific drivers to the kernel, instead of dealing with it in the
> bootloader when possible? My understanding is that we've been trying to
> reduce board specific code from the kernel.

That's not really the question, because that question assumes that it
isn't already present, which is not true.  The code is already present.
The question is how to deal with this from the DT perspective.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From borntraeger at de.ibm.com  Wed Feb 24 02:51:47 2016
From: borntraeger at de.ibm.com (Christian Borntraeger)
Date: Wed, 24 Feb 2016 11:51:47 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160224104139.GC28310@arm.com>
References: <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name> <56BE00E7.1010303@de.ibm.com>
 <20160212181640.4eabb85f@thinkpad> <20160223103221.GA1418@node.shutemov.name>
 <20160223191907.25719a4d@thinkpad>
 <20160223193345.GC21820@node.shutemov.name> <20160223202233.GE27281@arm.com>
 <56CD8302.9080202@de.ibm.com> <20160224104139.GC28310@arm.com>
Message-ID: <56CD8B43.9070509@de.ibm.com>

On 02/24/2016 11:41 AM, Will Deacon wrote:
> On Wed, Feb 24, 2016 at 11:16:34AM +0100, Christian Borntraeger wrote:
>> On 02/23/2016 09:22 PM, Will Deacon wrote:
>>> On Tue, Feb 23, 2016 at 10:33:45PM +0300, Kirill A. Shutemov wrote:
>>>> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
>>>>> I'll check with Martin, maybe it is actually trivial, then we can
>>>>> do a quick test it to rule that one out.
>>>>
>>>> Oh. I found a bug in __split_huge_pmd_locked(). Although, not sure if it's
>>>> _the_ bug.
>>>>
>>>> pmdp_invalidate() is called for the wrong address :-/
>>>> I guess that can be destructive on the architecture, right?
>>>
>>> FWIW, arm64 ignores the address parameter for set_pmd_at, so this would
>>> only result in the TLBI nuking the wrong entries, which is going to be
>>> tricky to observe in practice given that we install a table entry
>>> immediately afterwards that maps the same pages. If s390 does more here
>>> (I see some magic asm using the address), that could be the answer...
>>
>> This patch does not change the address for set_pmd_at, it does that for the 
>> pmdp_invalidate here (by keeping haddr at the start of the pmd)
>>
>> --->    pmdp_invalidate(vma, haddr, pmd);
>>         pmd_populate(mm, pmd, pgtable);
> 
> On arm64, pmdp_invalidate looks like:
> 
> void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
> 		     pmd_t *pmdp)
> {
> 	pmd_t entry = *pmdp;
> 	set_pmd_at(vma->vm_mm, address, pmdp, pmd_mknotpresent(entry));
> 	flush_pmd_tlb_range(vma, address, address + hpage_pmd_size);
> }
> 
> so that's the set_pmd_at call I was referring to.
> 
> On s390, that address ends up in __pmdp_idte[_local], but I don't know
> what .insn rrf,0xb98e0000,%2,%3,0,{0,1} do ;)

It does invalidation of the pmd entry and tlb clearing for this entry.

> 
>> Without that fix we would clearly have stale tlb entries, no?
> 
> Yes, but AFAIU the sequence on arm64 is:
> 
> 1.  trans huge mapping (block mapping in arm64 speak)
> 2.  faulting entry (pmd_mknotpresent)
> 3.  tlb invalidation
> 4.  table entry mapping the same pages as (1).
> 
> so if the microarchitecture we're on can tolerate a mixture of block
> mappings and page mappings mapping the same VA to the same PA, then the
> lack of TLB maintenance would go unnoticed. There are certainly systems
> where that could cause an issue, but I believe the one I've been testing
> on would be ok.

So in essence you say it does not matter that you flush the wrong range in 
flush_pmd_tlb_range as long as it will be flushed later on when the pages
really go away. Yes, then it really might be ok for arm64.



From linux at arm.linux.org.uk  Wed Feb 24 02:53:04 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 24 Feb 2016 10:53:04 +0000
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56CC60C4.6040908@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <3695074.sKSIyOjpjD@wuerfel>
 <CACRpkdZjfjOCFUucF1U5yVZBxSwa41GKEMv-HHQE=ymF2NZ21g@mail.gmail.com>
 <6859810.tb1t0IEONi@wuerfel> <56CC57FC.20707@ti.com>
 <CACRpkdYNaNtQQJ-tsBe5ksa4-z380ZQj-zN8ZnK0ED2kNPUwvg@mail.gmail.com>
 <56CC60C4.6040908@ti.com>
Message-ID: <20160224105304.GM19428@n2100.arm.linux.org.uk>

On Tue, Feb 23, 2016 at 03:38:12PM +0200, Tomi Valkeinen wrote:
> Ok. I feel everyone is trying to push the ugly part out of their domain.
> I want the board specific hacks out of fbdev. Bootloader people don't
> want it there. arch/arm/ people don't want it there. =)

I think that is really really unfair.  No one is trying to push ugly
bits out of their domain - this is being driven by Linus, who is
trying to convert Versatile to DT.  There is no other agenda here.

Remember, I was the one who wrote the CLCD driver, and it was written
to support the boards at the time using the best methods at the time.
Things change, people's ideas of what's acceptable change.  What was
acceptable when classes of boards were separate is no longer acceptable
with single zImage.

The board specific parts of CLCD were in arch/arm for a very long time,
but that gets in the way of single zImage, and the solution adopted by
the newly interested parties has been to move them to drivers/video
to keep things working.

That's how we're here: there isn't a conspiracy as you seem to be
thinking.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From tiffany.lin at mediatek.com  Wed Feb 24 02:53:15 2016
From: tiffany.lin at mediatek.com (tiffany lin)
Date: Wed, 24 Feb 2016 18:53:15 +0800
Subject: [PATCH v5 0/8] Add MT8173 Video Encoder Driver and VPU Driver
In-Reply-To: <56CD6A37.2040700@xs4all.nl>
References: <1456215081-16858-1-git-send-email-tiffany.lin@mediatek.com>
 <56CC1CAB.1060409@xs4all.nl> <1456302223.15077.8.camel@mtksdaap41>
 <56CD6A37.2040700@xs4all.nl>
Message-ID: <1456311195.15077.17.camel@mtksdaap41>

On Wed, 2016-02-24 at 09:30 +0100, Hans Verkuil wrote:
> Hi Tiffany,
> 
> On 02/24/16 09:23, tiffany lin wrote:
> > Hi Hans,
> > 
> > On Tue, 2016-02-23 at 09:47 +0100, Hans Verkuil wrote:
> >> On 02/23/16 09:11, Tiffany Lin wrote:
> >>> ==============
> >>>  Introduction
> >>> ==============
> >>>
> >>> The purpose of this series is to add the driver for video codec hw embedded in the Mediatek's MT8173 SoCs.
> >>> Mediatek Video Codec is able to handle video encoding of in a range of formats.
> >>>
> >>> This patch series also include VPU driver. Mediatek Video Codec driver rely on VPU driver to load,
> >>> communicate with VPU.
> >>>
> >>> Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI.
> >>> MTK IOMMU[1] and MTK SMI[2] have not yet been merged, but we wanted to start discussion about the driver
> >>> earlier so it could be merged sooner.
> >>>
> >>> [1]https://patchwork.kernel.org/patch/8335461/
> >>> [2]https://patchwork.kernel.org/patch/7596181/
> >>
> >> <snip>
> >>
> >>> v4l2-compliance test output:
> >>> localhost ~ # /usr/bin/v4l2-compliance -d /dev/video1
> >>> Driver Info:
> >>>         Driver name   : mtk-vcodec-enc
> >>>         Card type     : platform:mt8173
> >>>         Bus info      : platform:mt8173
> >>>         Driver version: 4.4.0
> >>>         Capabilities  : 0x84204000
> >>>                 Video Memory-to-Memory Multiplanar
> >>>                 Streaming
> >>>                 Extended Pix Format
> >>>                 Device Capabilities
> >>>         Device Caps   : 0x04204000
> >>>                 Video Memory-to-Memory Multiplanar
> >>>                 Streaming
> >>>                 Extended Pix Format
> >>>
> >>> Compliance test for device /dev/video1 (not using libv4l2):
> >>>
> >>> Required ioctls:
> >>>         test VIDIOC_QUERYCAP: OK
> >>>
> >>> Allow for multiple opens:
> >>>         test second video open: OK
> >>>         test VIDIOC_QUERYCAP: OK
> >>>         test VIDIOC_G/S_PRIORITY: OK
> >>>
> >>> Debug ioctls:
> >>>         test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> >>>         test VIDIOC_LOG_STATUS: OK (Not Supported)
> >>>
> >>> Input ioctls:
> >>>         test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> >>>         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> >>>         test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> >>>         test VIDIOC_ENUMAUDIO: OK (Not Supported)
> >>>         test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
> >>>         test VIDIOC_G/S_AUDIO: OK (Not Supported)
> >>>         Inputs: 0 Audio Inputs: 0 Tuners: 0
> >>>
> >>> Output ioctls:
> >>>         test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> >>>         test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> >>>         test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> >>>         test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> >>>         test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> >>>         Outputs: 0 Audio Outputs: 0 Modulators: 0
> >>>
> >>> Input/Output configuration ioctls:
> >>>         test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> >>>         test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> >>>         test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> >>>         test VIDIOC_G/S_EDID: OK (Not Supported)
> >>>
> >>>         Control ioctls:
> >>>                 test VIDIOC_QUERYCTRL/MENU: OK
> >>>                 test VIDIOC_G/S_CTRL: OK
> >>>                 test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> >>>                 test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> >>>                 test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> >>>                 Standard Controls: 12 Private Controls: 0
> >>>
> >>>         Format ioctls:
> >>>                 test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> >>>                 test VIDIOC_G/S_PARM: OK
> >>>                 test VIDIOC_G_FBUF: OK (Not Supported)
> >>>                 test VIDIOC_G_FMT: OK
> >>>                 test VIDIOC_TRY_FMT: OK
> >>>                 test VIDIOC_S_FMT: OK
> >>>                 test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> >>>
> >>>         Codec ioctls:
> >>>                 test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> >>>                 test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> >>>                 test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> >>>
> >>>         Buffer ioctls:
> >>>                 test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> >>>                 test VIDIOC_EXPBUF: OK
> >>>
> >>> Total: 38, Succeeded: 38, Failed: 0, Warnings: 0
> >>
> >> Nice!
> >>
> >> Can you try 'v4l2-compliance -s'? Note that this may not work since I know
> >> that v4l2-compliance doesn't work all that well with codecs, but I am
> >> curious what the output is when you try streaming.
> >>
> >> Don't bother trying to chase down reported failures, those are likely from
> >> v4l2-compliance itself. It is something I would like to improve, but -ENOTIME.
> >>
> > 
> > When I try to run 'v4l2-compliance -d /dev/video1 -s, I got follow
> > output.
> > I use v4.4-rc5 kernel and v4l-utils 1.6 version.
> 
> Can you compile v4l2-compliance straight from the v4l-utils.git master branch?
> Version 1.6 is too old, and for proper compliance testing you should always use
> the master branch. It probably won't matter for this -s test, but for the
> regular test (without -s) it does make a difference.
> 
> If nothing else, using the master branch will make it easier for me to match up
> the line numbers that v4l2-compliance reports to the actual source.
> 

Sorry, our development branch default get
"http://linuxtv.org/downloads/v4l-utils/v4l-utils-1.6.0.tar.bz2"
I try to change to use master branch.
I got following output:


Streaming ioctls:
        test read/write: OK (Not Supported)
                fail: v4l2-test-buffers.cpp(970): ret != EINVAL
        test MMAP: FAIL
                warn: v4l2-test-buffers.cpp(278): buf.length=1,
vp->length=1024, ff9a42a8/ff9a4270, ff9a4284/ff9a429c/ff9a42a4
fail: v4l2-test-buffers.cpp(1032): ret && ret != ENOTTY
                fail: v4l2-test-buffers.cpp(1098): setupUserPtr(node, q)
        test USERPTR: FAIL
        test DMABUF: Cannot test, specify --expbuf-device


After change to use master branch, VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF:
test FAIL.

I got this error output, do I need to fix this issue. I need to figure
out this.

                warn: v4l2-test-buffers.cpp(467): mmap_valid 1
warn: v4l2-test-buffers.cpp(278): buf.length=1, vp->length=1024,
ff9a40b8/ff9a4080, ff9a4094/ff9a40ac/ff9a40b4          warn:
v4l2-test-buffers.cpp(475): mmap_valid 2          warn:
v4l2-test-buffers.cpp(480): userptr_valid 1          warn:
v4l2-test-buffers.cpp(278): buf.length=1, vp->length=1024,
ff9a40b8/ff9a4080, ff9a4094/ff9a40ac/ff9a40b4          warn:
v4l2-test-buffers.cpp(488): userptr_valid 2               warn:
v4l2-test-buffers.cpp(493): dmabuf_valid  1          warn:
v4l2-test-buffers.cpp(278): buf.length=1, vp->length=1024,
ff9a40b8/ff9a4080, ff9a4094/ff9a40ac/ff9a40b4          warn:
v4l2-test-buffers.cpp(501): dmabuf_valid  2               warn:
v4l2-test-buffers.cpp(278): buf.length=1, vp->length=1024,
ff9a40b8/ff9a4080, ff9a4094/ff9a40ac/ff9a40b4             warn:
v4l2-test-buffers.cpp(278): buf.length=1, vp->length=1024,
ff9a40b8/ff9a4080, ff9a4094/ff9a40ac/ff9a40b4          warn:
v4l2-test-buffers.cpp(278): buf.length=1, vp->length=1024,
ff9a40b8/ff9a4080, ff9a4094/ff9a40ac/ff9a40b4             fail:
v4l2-test-buffers.cpp(564): check_0(crbufs.reserved,
sizeof(crbufs.reserved))
                test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
                warn: v4l2-test-buffers.cpp(597): ....2         warn:
v4l2-test-buffers.cpp(597): ....2         test VIDIOC_EXPBUF: OK


best regards,
Tiffany


> Thanks!
> 
> 	Hans
> 
> > 
> > Streaming ioctls:
> >         test read/write: OK (Not Supported)
> > fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(332): buf.querybuf(node, i) fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(868): testQueryBuf(node, cur_fmt.type, q.g_buffers())
> >         test MMAP: FAIL
> > fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(923): ret && ret != ENOTTY
> > 
> > fail: ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(988): setupUserPtr(node, q)
> >         test USERPTR: FAIL
> >         test DMABUF: Cannot test, specify --expbuf-device
> > 
> > best regards,
> > Tiffany
> > 
> >> Regards,
> >>
> >> 	Hans
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 




From ykk at rock-chips.com  Wed Feb 24 02:54:18 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Wed, 24 Feb 2016 18:54:18 +0800
Subject: [PATCH v1 2/4] clk: rockchip: set the clock ids for RK3228 VOP
In-Reply-To: <1456308303-29706-1-git-send-email-ykk@rock-chips.com>
References: <1456308303-29706-1-git-send-email-ykk@rock-chips.com>
Message-ID: <1456311258-4311-1-git-send-email-ykk@rock-chips.com>

Signed-off-by: Yakir Yang <ykk at rock-chips.com>
---
 drivers/clk/rockchip/clk-rk3228.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3228.c b/drivers/clk/rockchip/clk-rk3228.c
index 981a502..8747b25 100644
--- a/drivers/clk/rockchip/clk-rk3228.c
+++ b/drivers/clk/rockchip/clk-rk3228.c
@@ -368,7 +368,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[] __initdata = {
 			RK2928_CLKSEL_CON(29), 0, 3, DFLAGS),
 	DIV(0, "sclk_vop_pre", "sclk_vop_src", 0,
 			RK2928_CLKSEL_CON(27), 8, 8, DFLAGS),
-	MUX(0, "dclk_vop", mux_dclk_vop_p, 0,
+	MUX(DCLK_VOP, "dclk_vop", mux_dclk_vop_p, 0,
 			RK2928_CLKSEL_CON(27), 1, 1, MFLAGS),
 
 	COMPOSITE(0, "i2s0_src", mux_pll_src_2plls_p, 0,
@@ -503,7 +503,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[] __initdata = {
 	GATE(0, "aclk_iep", "aclk_iep_pre", 0, RK2928_CLKGATE_CON(13), 2, GFLAGS),
 	GATE(0, "aclk_iep_noc", "aclk_iep_pre", 0, RK2928_CLKGATE_CON(13), 9, GFLAGS),
 
-	GATE(0, "aclk_vop", "aclk_vop_pre", 0, RK2928_CLKGATE_CON(13), 5, GFLAGS),
+	GATE(ACLK_VOP, "aclk_vop", "aclk_vop_pre", 0, RK2928_CLKGATE_CON(13), 5, GFLAGS),
 	GATE(0, "aclk_vop_noc", "aclk_vop_pre", 0, RK2928_CLKGATE_CON(13), 12, GFLAGS),
 
 	GATE(0, "aclk_hdcp", "aclk_hdcp_pre", 0, RK2928_CLKGATE_CON(14), 10, GFLAGS),
@@ -511,7 +511,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[] __initdata = {
 
 	GATE(0, "hclk_rga", "hclk_vio_pre", 0, RK2928_CLKGATE_CON(13), 1, GFLAGS),
 	GATE(0, "hclk_iep", "hclk_vio_pre", 0, RK2928_CLKGATE_CON(13), 3, GFLAGS),
-	GATE(0, "hclk_vop", "hclk_vio_pre", 0, RK2928_CLKGATE_CON(13), 6, GFLAGS),
+	GATE(HCLK_VOP, "hclk_vop", "hclk_vio_pre", 0, RK2928_CLKGATE_CON(13), 6, GFLAGS),
 	GATE(0, "hclk_vio_ahb_arbi", "hclk_vio_pre", 0, RK2928_CLKGATE_CON(13), 7, GFLAGS),
 	GATE(0, "hclk_vio_noc", "hclk_vio_pre", 0, RK2928_CLKGATE_CON(13), 8, GFLAGS),
 	GATE(0, "hclk_vop_noc", "hclk_vio_pre", 0, RK2928_CLKGATE_CON(13), 13, GFLAGS),
-- 
1.9.1




From will.deacon at arm.com  Wed Feb 24 03:02:22 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Feb 2016 11:02:22 +0000
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <56CD8B43.9070509@de.ibm.com>
References: <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160223103221.GA1418@node.shutemov.name>
 <20160223191907.25719a4d@thinkpad>
 <20160223193345.GC21820@node.shutemov.name>
 <20160223202233.GE27281@arm.com> <56CD8302.9080202@de.ibm.com>
 <20160224104139.GC28310@arm.com> <56CD8B43.9070509@de.ibm.com>
Message-ID: <20160224110221.GF28310@arm.com>

On Wed, Feb 24, 2016 at 11:51:47AM +0100, Christian Borntraeger wrote:
> On 02/24/2016 11:41 AM, Will Deacon wrote:
> > On Wed, Feb 24, 2016 at 11:16:34AM +0100, Christian Borntraeger wrote:
> >> Without that fix we would clearly have stale tlb entries, no?
> > 
> > Yes, but AFAIU the sequence on arm64 is:
> > 
> > 1.  trans huge mapping (block mapping in arm64 speak)
> > 2.  faulting entry (pmd_mknotpresent)
> > 3.  tlb invalidation
> > 4.  table entry mapping the same pages as (1).
> > 
> > so if the microarchitecture we're on can tolerate a mixture of block
> > mappings and page mappings mapping the same VA to the same PA, then the
> > lack of TLB maintenance would go unnoticed. There are certainly systems
> > where that could cause an issue, but I believe the one I've been testing
> > on would be ok.
> 
> So in essence you say it does not matter that you flush the wrong range in 
> flush_pmd_tlb_range as long as it will be flushed later on when the pages
> really go away. Yes, then it really might be ok for arm64.

Indeed, although that's a property of the microarchitecture I'm using
rather than an architectural guarantee so the code should certainly be
fixed!

Will


From sunil.kovvuri at gmail.com  Wed Feb 24 03:10:50 2016
From: sunil.kovvuri at gmail.com (sunil.kovvuri at gmail.com)
Date: Wed, 24 Feb 2016 16:40:50 +0530
Subject: [PATCH] net: thunderx: Fix for Qset error due to CQ full
Message-ID: <1456312250-25694-1-git-send-email-sunil.kovvuri@gmail.com>

From: Sunil Goutham <sgoutham at cavium.com>

On Thunderx pass 1.x and pass2 due to a HW errata default CQ
DROP_LEVEL of 0x80 is not sufficient to avoid CQ_WR_FULL Qset
error when packets are being received at >20Mpps resulting in
complete stall of packet reception.

This patch will configure it to 0x100 which is what is expected
by HW on Thunderx. On future passes of thunderx and other chips
HW default/reset value will be 0x100 or higher hence not overwritten.

Signed-off-by: Jerin Jacob <jerin.jacob at caviumnetworks.com>
Signed-off-by: Sunil Goutham <sgoutham at cavium.com>
---
 drivers/net/ethernet/cavium/thunder/nic.h      |    9 +++++++++
 drivers/net/ethernet/cavium/thunder/nic_main.c |    6 ++++++
 drivers/net/ethernet/cavium/thunder/nic_reg.h  |    2 +-
 3 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nic.h b/drivers/net/ethernet/cavium/thunder/nic.h
index 6888288..34e9ace 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -116,6 +116,15 @@
 #define NIC_PF_INTR_ID_MBOX0		8
 #define NIC_PF_INTR_ID_MBOX1		9
 
+/* Minimum FIFO level before all packets for the CQ are dropped
+ *
+ * This value ensures that once a packet has been "accepted"
+ * for reception it will not get dropped due to non-availability
+ * of CQ descriptor. An errata in HW mandates this value to be
+ * atleast 0x100.
+ */
+#define NICPF_CQM_MIN_DROP_LEVEL       0x100
+
 /* Global timer for CQ timer thresh interrupts
  * Calculated for SCLK of 700Mhz
  * value written should be a 1/16th of what is expected
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c b/drivers/net/ethernet/cavium/thunder/nic_main.c
index 4dded90..95f17f8 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -304,6 +304,7 @@ static void nic_set_lmac_vf_mapping(struct nicpf *nic)
 static void nic_init_hw(struct nicpf *nic)
 {
 	int i;
+	u64 cqm_cfg;
 
 	/* Enable NIC HW block */
 	nic_reg_write(nic, NIC_PF_CFG, 0x3);
@@ -340,6 +341,11 @@ static void nic_init_hw(struct nicpf *nic)
 	/* Enable VLAN ethertype matching and stripping */
 	nic_reg_write(nic, NIC_PF_RX_ETYPE_0_7,
 		      (2 << 19) | (ETYPE_ALG_VLAN_STRIP << 16) | ETH_P_8021Q);
+
+	/* Check if HW expected value is higher (could be in future chips) */
+	cqm_cfg = nic_reg_read(nic, NIC_PF_CQM_CFG);
+	if (cqm_cfg < NICPF_CQM_MIN_DROP_LEVEL)
+		nic_reg_write(nic, NIC_PF_CQM_CFG, NICPF_CQM_MIN_DROP_LEVEL);
 }
 
 /* Channel parse index configuration */
diff --git a/drivers/net/ethernet/cavium/thunder/nic_reg.h b/drivers/net/ethernet/cavium/thunder/nic_reg.h
index dd536be..afb10e3 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_reg.h
+++ b/drivers/net/ethernet/cavium/thunder/nic_reg.h
@@ -21,7 +21,7 @@
 #define   NIC_PF_TCP_TIMER			(0x0060)
 #define   NIC_PF_BP_CFG				(0x0080)
 #define   NIC_PF_RRM_CFG			(0x0088)
-#define   NIC_PF_CQM_CF				(0x00A0)
+#define   NIC_PF_CQM_CFG			(0x00A0)
 #define   NIC_PF_CNM_CF				(0x00A8)
 #define   NIC_PF_CNM_STATUS			(0x00B0)
 #define   NIC_PF_CQ_AVG_CFG			(0x00C0)
-- 
1.7.1



From hdegoede at redhat.com  Wed Feb 24 03:15:15 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Wed, 24 Feb 2016 12:15:15 +0100
Subject: [PATCH v3 0/2] ?hci-platform: Add support for controllers with more
 then one reset line
Message-ID: <1456312517-24211-1-git-send-email-hdegoede@redhat.com>

Hi All,

Here is a new version of my patch-set to support usb controllers which
have multiple resets. These patches apply on top of the related
reset-controller patches which have just been merged here:

git://git.pengutronix.de/git/pza/linux.git reset/next

Changes in v2:
-Switch to now shared reset_[de]assert functions

Changes in v3:
-Adjust for changes to shared-reset reset-controller functions

Regards,

Hans


From hdegoede at redhat.com  Wed Feb 24 03:15:16 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Wed, 24 Feb 2016 12:15:16 +0100
Subject: [PATCH v3 1/2] ehci-platform: Add support for controllers with
 multiple reset lines
In-Reply-To: <1456312517-24211-1-git-send-email-hdegoede@redhat.com>
References: <1456312517-24211-1-git-send-email-hdegoede@redhat.com>
Message-ID: <1456312517-24211-2-git-send-email-hdegoede@redhat.com>

From: Reinder de Haan <patchesrdh at mveas.com>

At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
reset lines, the controller will not initialize while the reset for
its companion is still asserted, which means we need to de-assert
2 resets for the controller to work.

Signed-off-by: Reinder de Haan <patchesrdh at mveas.com>
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
Changes in v2:
-Use the new reset_control_[de]assert_shared reset-controller functions
Changes in v3:
-Adjust for changes to shared-reset reset-controller functions
---
 Documentation/devicetree/bindings/usb/usb-ehci.txt |  2 +-
 drivers/usb/host/ehci-platform.c                   | 41 ++++++++++++----------
 2 files changed, 24 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index a12d601..0701812 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -18,7 +18,7 @@ Optional properties:
  - clocks : a list of phandle + clock specifier pairs
  - phys : phandle + phy specifier pair
  - phy-names : "usb"
- - resets : phandle + reset specifier pair
+ - resets : a list of phandle + reset specifier pairs
 
 Example (Sequoia 440EPx):
     ehci at e0000300 {
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index bd7082f2..3f195ba 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -39,11 +39,12 @@
 
 #define DRIVER_DESC "EHCI generic platform driver"
 #define EHCI_MAX_CLKS 3
+#define EHCI_MAX_RESETS 2
 #define hcd_to_ehci_priv(h) ((struct ehci_platform_priv *)hcd_to_ehci(h)->priv)
 
 struct ehci_platform_priv {
 	struct clk *clks[EHCI_MAX_CLKS];
-	struct reset_control *rst;
+	struct reset_control *resets[EHCI_MAX_RESETS];
 	struct phy **phys;
 	int num_phys;
 	bool reset_on_resume;
@@ -149,7 +150,7 @@ static int ehci_platform_probe(struct platform_device *dev)
 	struct usb_ehci_pdata *pdata = dev_get_platdata(&dev->dev);
 	struct ehci_platform_priv *priv;
 	struct ehci_hcd *ehci;
-	int err, irq, phy_num, clk = 0;
+	int err, irq, phy_num, clk = 0, rst = 0;
 
 	if (usb_disabled())
 		return -ENODEV;
@@ -232,18 +233,22 @@ static int ehci_platform_probe(struct platform_device *dev)
 				break;
 			}
 		}
-	}
 
-	priv->rst = devm_reset_control_get_optional(&dev->dev, NULL);
-	if (IS_ERR(priv->rst)) {
-		err = PTR_ERR(priv->rst);
-		if (err == -EPROBE_DEFER)
-			goto err_put_clks;
-		priv->rst = NULL;
-	} else {
-		err = reset_control_deassert(priv->rst);
-		if (err)
-			goto err_put_clks;
+		for (rst = 0; rst < EHCI_MAX_RESETS; rst++) {
+			priv->resets[rst] =
+				devm_reset_control_get_shared_by_index(
+								&dev->dev, rst);
+			if (IS_ERR(priv->resets[rst])) {
+				err = PTR_ERR(priv->resets[rst]);
+				if (err == -EPROBE_DEFER)
+					goto err_reset;
+				priv->resets[rst] = NULL;
+				break;
+			}
+			err = reset_control_deassert(priv->resets[rst]);
+			if (err)
+				goto err_reset;
+		}
 	}
 
 	if (pdata->big_endian_desc)
@@ -300,8 +305,8 @@ err_power:
 	if (pdata->power_off)
 		pdata->power_off(dev);
 err_reset:
-	if (priv->rst)
-		reset_control_assert(priv->rst);
+	while (--rst >= 0)
+		reset_control_assert(priv->resets[rst]);
 err_put_clks:
 	while (--clk >= 0)
 		clk_put(priv->clks[clk]);
@@ -319,15 +324,15 @@ static int ehci_platform_remove(struct platform_device *dev)
 	struct usb_hcd *hcd = platform_get_drvdata(dev);
 	struct usb_ehci_pdata *pdata = dev_get_platdata(&dev->dev);
 	struct ehci_platform_priv *priv = hcd_to_ehci_priv(hcd);
-	int clk;
+	int clk, rst;
 
 	usb_remove_hcd(hcd);
 
 	if (pdata->power_off)
 		pdata->power_off(dev);
 
-	if (priv->rst)
-		reset_control_assert(priv->rst);
+	for (rst = 0; rst < EHCI_MAX_RESETS && priv->resets[rst]; rst++)
+		reset_control_assert(priv->resets[rst]);
 
 	for (clk = 0; clk < EHCI_MAX_CLKS && priv->clks[clk]; clk++)
 		clk_put(priv->clks[clk]);
-- 
2.7.1



From hdegoede at redhat.com  Wed Feb 24 03:15:17 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Wed, 24 Feb 2016 12:15:17 +0100
Subject: [PATCH v3 2/2] ohci-platform: Add support for controllers with
 multiple reset lines
In-Reply-To: <1456312517-24211-1-git-send-email-hdegoede@redhat.com>
References: <1456312517-24211-1-git-send-email-hdegoede@redhat.com>
Message-ID: <1456312517-24211-3-git-send-email-hdegoede@redhat.com>

At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
reset lines, the controller will not initialize while the reset for
its companion is still asserted, which means we need to de-assert
2 resets for the controller to work.

Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
Changes in v2:
-New patch in v2 of this patch-set, to complement the identical patch for
 the ehci-platform code
Changes in v3:
-Adjust for changes to shared-reset reset-controller functions
---
 Documentation/devicetree/bindings/usb/usb-ohci.txt |  2 +-
 drivers/usb/host/ohci-platform.c                   | 43 ++++++++++++----------
 2 files changed, 24 insertions(+), 21 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt b/Documentation/devicetree/bindings/usb/usb-ohci.txt
index 19233b7..9df4569 100644
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -14,7 +14,7 @@ Optional properties:
 - clocks : a list of phandle + clock specifier pairs
 - phys : phandle + phy specifier pair
 - phy-names : "usb"
-- resets : phandle + reset specifier pair
+- resets : a list of phandle + reset specifier pairs
 
 Example:
 
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index c2669f18..5fa5813 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -33,11 +33,12 @@
 
 #define DRIVER_DESC "OHCI generic platform driver"
 #define OHCI_MAX_CLKS 3
+#define OHCI_MAX_RESETS 2
 #define hcd_to_ohci_priv(h) ((struct ohci_platform_priv *)hcd_to_ohci(h)->priv)
 
 struct ohci_platform_priv {
 	struct clk *clks[OHCI_MAX_CLKS];
-	struct reset_control *rst;
+	struct reset_control *resets[OHCI_MAX_RESETS];
 	struct phy **phys;
 	int num_phys;
 };
@@ -117,7 +118,7 @@ static int ohci_platform_probe(struct platform_device *dev)
 	struct usb_ohci_pdata *pdata = dev_get_platdata(&dev->dev);
 	struct ohci_platform_priv *priv;
 	struct ohci_hcd *ohci;
-	int err, irq, phy_num, clk = 0;
+	int err, irq, phy_num, clk = 0, rst = 0;
 
 	if (usb_disabled())
 		return -ENODEV;
@@ -195,19 +196,21 @@ static int ohci_platform_probe(struct platform_device *dev)
 				break;
 			}
 		}
-
-	}
-
-	priv->rst = devm_reset_control_get_optional(&dev->dev, NULL);
-	if (IS_ERR(priv->rst)) {
-		err = PTR_ERR(priv->rst);
-		if (err == -EPROBE_DEFER)
-			goto err_put_clks;
-		priv->rst = NULL;
-	} else {
-		err = reset_control_deassert(priv->rst);
-		if (err)
-			goto err_put_clks;
+		for (rst = 0; rst < OHCI_MAX_RESETS; rst++) {
+			priv->resets[rst] =
+				devm_reset_control_get_shared_by_index(
+								&dev->dev, rst);
+			if (IS_ERR(priv->resets[rst])) {
+				err = PTR_ERR(priv->resets[rst]);
+				if (err == -EPROBE_DEFER)
+					goto err_reset;
+				priv->resets[rst] = NULL;
+				break;
+			}
+			err = reset_control_deassert(priv->resets[rst]);
+			if (err)
+				goto err_reset;
+		}
 	}
 
 	if (pdata->big_endian_desc)
@@ -265,8 +268,8 @@ err_power:
 	if (pdata->power_off)
 		pdata->power_off(dev);
 err_reset:
-	if (priv->rst)
-		reset_control_assert(priv->rst);
+	while (--rst >= 0)
+		reset_control_assert(priv->resets[rst]);
 err_put_clks:
 	while (--clk >= 0)
 		clk_put(priv->clks[clk]);
@@ -284,15 +287,15 @@ static int ohci_platform_remove(struct platform_device *dev)
 	struct usb_hcd *hcd = platform_get_drvdata(dev);
 	struct usb_ohci_pdata *pdata = dev_get_platdata(&dev->dev);
 	struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
-	int clk;
+	int clk, rst;
 
 	usb_remove_hcd(hcd);
 
 	if (pdata->power_off)
 		pdata->power_off(dev);
 
-	if (priv->rst)
-		reset_control_assert(priv->rst);
+	for (rst = 0; rst < OHCI_MAX_RESETS && priv->resets[rst]; rst++)
+		reset_control_assert(priv->resets[rst]);
 
 	for (clk = 0; clk < OHCI_MAX_CLKS && priv->clks[clk]; clk++)
 		clk_put(priv->clks[clk]);
-- 
2.7.1



From tomi.valkeinen at ti.com  Wed Feb 24 03:21:51 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Wed, 24 Feb 2016 13:21:51 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <20160224104638.GL19428@n2100.arm.linux.org.uk>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
 <56CC546A.9070705@ti.com> <20160224104638.GL19428@n2100.arm.linux.org.uk>
Message-ID: <56CD924F.50108@ti.com>

On 24/02/16 12:46, Russell King - ARM Linux wrote:
> On Tue, Feb 23, 2016 at 02:45:30PM +0200, Tomi Valkeinen wrote:
>> My opinion is that the bootloader should be responsible for telling the
>> kernel what hardware there is on the board. For busses like PCI we have
>> proper probing mechanism with global unique identifiers for the devices,
>> and nothing is needed from the bootloader.
> 
> Exactly, but that is _NOT_ the case here, because we're not talking
> about an on-board display.

Ok, what is it then? I'm not familiar with the boards in question.

When does a display become an on-board display? All the panels I have
can be disconnected quite easily, but I still consider them as on-board
displays.

>> In the Versatile case the panels are kind of probeable, but not in the
>> same sense as PCI: all that can be probed on Versatile is a board
>> specific ID, which in itself doesn't tell what kind of panel there is.
>> In addition to the ID we need board specific tables listing the details
>> of the panels.
> 
> That argument does not stack up.  Just because you've plugged in a
> network device does not mean that the kernel can drive it: the kernel
> needs a device specific driver, which is determined by looking at the
> IDs.  There is no standard network driver PCI interface.

Yes, but you can connect the network device to any board with a PCI bus
and it works. Here, if I'm not mistaken, the displays are built for this
single board, making them board specific.

So sure, someone could build boards with the same connector, allowing
you to connect the same displays. If that's the case, then CLCD should
be taken out of this picture, as the board could have something else
than CLCD as the display controller.

>> I think one of the core questions here is: do we want to start adding
>> board specific drivers to the kernel, instead of dealing with it in the
>> bootloader when possible? My understanding is that we've been trying to
>> reduce board specific code from the kernel.
> 
> That's not really the question, because that question assumes that it
> isn't already present, which is not true.  The code is already present.
> The question is how to deal with this from the DT perspective.

Yes. As I commented in this (or the other thread), I'm looking for a
proper generic solution which can be recommended for all new boards.
When we know what that is, we can see if and how that could fit into
Versatile's case. Versatile is not the only board with the exact same
problem.

I wouldn't be at all surprised if the final solution is to just go with
Linus' current patches for Versatile, as everything else would break
compatibility or be overly complex.

But I cannot accept that as a general solution for all similar cases
going forward, especially when moving to DRM world, that's just bad SW
design.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/9d13a40f/attachment.sig>

From dvyukov at google.com  Wed Feb 24 03:26:26 2016
From: dvyukov at google.com (Dmitry Vyukov)
Date: Wed, 24 Feb 2016 12:26:26 +0100
Subject: [PATCH v8] kernel: add kcov code coverage
In-Reply-To: <20160204143007.674a7e847b4c8fed957bba7c@linux-foundation.org>
References: <1454600441-70701-1-git-send-email-dvyukov@google.com>
 <20160204143007.674a7e847b4c8fed957bba7c@linux-foundation.org>
Message-ID: <CACT4Y+Z2ZZfGy+=zU3a53y5sT2s=ZJg6E9j8=VdqqUY6pZoozQ@mail.gmail.com>

On Thu, Feb 4, 2016 at 11:30 PM, Andrew Morton
<akpm at linux-foundation.org> wrote:
> On Thu,  4 Feb 2016 16:40:41 +0100 Dmitry Vyukov <dvyukov at google.com> wrote:
>
>> kcov provides code coverage collection for coverage-guided fuzzing
>> (randomized testing). Coverage-guided fuzzing is a testing technique
>> that uses coverage feedback to determine new interesting inputs to a
>> system. A notable user-space example is AFL
>> (http://lcamtuf.coredump.cx/afl/). However, this technique is not
>> widely used for kernel testing due to missing compiler and kernel
>> support.
>>
>> kcov does not aim to collect as much coverage as possible. It aims
>> to collect more or less stable coverage that is function of syscall
>> inputs. To achieve this goal it does not collect coverage in
>> soft/hard interrupts and instrumentation of some inherently
>> non-deterministic or non-interesting parts of kernel is disbled
>> (e.g. scheduler, locking).
>>
>> Currently there is a single coverage collection mode (tracing),
>> but the API anticipates additional collection modes.
>> Initially I also implemented a second mode which exposes
>> coverage in a fixed-size hash table of counters (what Quentin
>> used in his original patch). I've dropped the second mode for
>> simplicity.
>>
>> This patch adds the necessary support on kernel side.
>> The complimentary compiler support was added in gcc revision 231296.
>>
>> We've used this support to build syzkaller system call fuzzer,
>> which has found 90 kernel bugs in just 2 months:
>> https://github.com/google/syzkaller/wiki/Found-Bugs
>> We've also found 30+ bugs in our internal systems with syzkaller.
>> Another (yet unexplored) direction where kcov coverage would greatly
>> help is more traditional "blob mutation". For example, mounting
>> a random blob as a filesystem, or receiving a random blob over wire.
>>
>> Why not gcov. Typical fuzzing loop looks as follows: (1) reset
>> coverage, (2) execute a bit of code, (3) collect coverage, repeat.
>> A typical coverage can be just a dozen of basic blocks (e.g. an
>> invalid input). In such context gcov becomes prohibitively expensive
>> as reset/collect coverage steps depend on total number of basic
>> blocks/edges in program (in case of kernel it is about 2M). Cost of
>> kcov depends only on number of executed basic blocks/edges. On top of
>> that, kernel requires per-thread coverage because there are
>> always background threads and unrelated processes that also produce
>> coverage. With inlined gcov instrumentation per-thread coverage is not
>> possible.
>>
>> kcov exposes kernel PCs and control flow to user-space which
>> is insecure. But debugfs should not be mapped as user accessible.
>
> So the proposed user interface is ioctls against /sys/kernel/debug/kcov.
>
> I guess that's OK.  We could just add sys_kcov() - syscalls are cheap
> enough.  But we store state within the fd, don't we?  So sys_kcov()
> would take an fd argument.
>
>> Based on a patch by Quentin Casasnovas.
>> Signed-off-by: Dmitry Vyukov <dvyukov at google.com>
>> Reviewed-by: Kees Cook <keescook at chromium.org>
>> ---
>> Anticipating reasonable questions regarding usage of this feature.
>> Quentin Casasnovas and Vegard Nossum also plan to use kcov for
>> coverage-guided fuzzing. Currently they use a custom kernel patch
>> for their fuzzer and found several dozens of bugs.
>> There is also interest from Intel 0-DAY kernel test infrastructure.
>>
>> ...
>>
>> --- a/include/linux/sched.h
>> +++ b/include/linux/sched.h
>> @@ -1811,6 +1811,16 @@ struct task_struct {
>>       /* bitmask and counter of trace recursion */
>>       unsigned long trace_recursion;
>>  #endif /* CONFIG_TRACING */
>> +#ifdef CONFIG_KCOV
>> +     /* Coverage collection mode enabled for this task (0 if disabled). */
>> +     int             kcov_mode;
>
> Should really be enum kcov_mode.  We could move it into <linux/kcov.h>:
>
> --- a/include/linux/kcov.h~kernel-add-kcov-code-coverage-fix
> +++ a/include/linux/kcov.h
> @@ -10,6 +10,14 @@ struct task_struct;
>  void kcov_task_init(struct task_struct *t);
>  void kcov_task_exit(struct task_struct *t);
>
> +enum kcov_mode {
> +       /*
> +        * Tracing coverage collection mode.
> +        * Covered PCs are collected in a per-task buffer.
> +        */
> +       KCOV_MODE_TRACE = 1,
> +};
> +
>  #else
>
>  static inline void kcov_task_init(struct task_struct *t) {}
> --- a/include/linux/sched.h~kernel-add-kcov-code-coverage-fix
> +++ a/include/linux/sched.h
> @@ -51,6 +51,7 @@ struct sched_param {
>  #include <linux/resource.h>
>  #include <linux/timer.h>
>  #include <linux/hrtimer.h>
> +#include <linux/kcov.h>
>  #include <linux/task_io_accounting.h>
>  #include <linux/latencytop.h>
>  #include <linux/cred.h>
> @@ -1814,7 +1815,7 @@ struct task_struct {
>  #endif /* CONFIG_TRACING */
>  #ifdef CONFIG_KCOV
>         /* Coverage collection mode enabled for this task (0 if disabled). */
> -       int             kcov_mode;
> +       enum kcov_mode kcov_mode;
>         /* Size of the kcov_area. */
>         unsigned        kcov_size;
>         /* Buffer for coverage collection. */
> --- a/kernel/kcov.c~kernel-add-kcov-code-coverage-fix
> +++ a/kernel/kcov.c
> @@ -13,14 +13,6 @@
>  #include <linux/uaccess.h>
>  #include <linux/kcov.h>
>
> -enum kcov_mode {
> -       /*
> -        * Tracing coverage collection mode.
> -        * Covered PCs are collected in a per-task buffer.
> -        */
> -       KCOV_MODE_TRACE = 1,
> -};
> -
>  /*
>   * kcov descriptor (one per opened debugfs file).
>   * State transitions of the descriptor:
>
>>
>> ...
>>
>> +/*
>> + * kcov descriptor (one per opened debugfs file).
>> + * State transitions of the descriptor:
>> + * - initial state after open()
>> + * - then there must be a single ioctl(KCOV_INIT_TRACE) call
>> + * - then, mmap() call (several calls are allowed but not useful)
>> + * - then, repeated enable/disable for a task (only one task a time allowed)
>> + */
>> +struct kcov {
>> + /*
>> + * Reference counter.  We keep one for:
>> + * - opened file descriptor
>> + * - task with enabled coverage (we can't unwire it from another task)
>> + */
>> +     atomic_t rc;
>
> "rc" usually means "return code".  Calling this "refcount" would cause
> less surprise.
>
>> +     /* The lock protects mode, size, area and t. */
>> +     spinlock_t              lock;
>> +     enum kcov_mode          mode;
>> +     unsigned                size;
>> +     void                    *area;
>> +     struct task_struct      *t;
>
> Can we get some documentation in place for the above?  I find that
> documenting the data structures is more valuable than documenting the
> code.
>
>> +};
>> +
>> +/*
>> + * Entry point from instrumented code.
>> + * This is called once per basic-block/edge.
>> + */
>> +void __sanitizer_cov_trace_pc(void)
>> +{
>> +     struct task_struct *t;
>> +     enum kcov_mode mode;
>> +
>> +     t = current;
>> +     /*
>> +      * We are interested in code coverage as a function of a syscall inputs,
>> +      * so we ignore code executed in interrupts.
>> +      */
>> +     if (!t || in_interrupt())
>> +             return;
>> +     mode = READ_ONCE(t->kcov_mode);
>> +     if (mode == KCOV_MODE_TRACE) {
>> +             unsigned long *area;
>> +             unsigned long pos;
>> +
>> +             /*
>> +              * There is some code that runs in interrupts but for which
>> +              * in_interrupt() returns false (e.g. preempt_schedule_irq()).
>> +              * READ_ONCE()/barrier() effectively provides load-acquire wrt
>> +              * interrupts, there are paired barrier()/WRITE_ONCE() in
>> +              * kcov_ioctl_locked().
>> +              */
>> +             barrier();
>> +             area = t->kcov_area;
>> +             /* The first word is number of subsequent PCs. */
>> +             pos = READ_ONCE(area[0]) + 1;
>> +             if (likely(pos < t->kcov_size)) {
>> +                     area[pos] = _RET_IP_;
>> +                     WRITE_ONCE(area[0], pos);
>> +             }
>> +     }
>> +}
>> +EXPORT_SYMBOL(__sanitizer_cov_trace_pc);
>
> Why is this exported to modules?  gcc emits the call?

Yes, gcc emits the call.

>> ...
>>
>> +static int kcov_mmap(struct file *filep, struct vm_area_struct *vma)
>> +{
>> +     int res = 0;
>> +     void *area;
>> +     struct kcov *kcov = vma->vm_file->private_data;
>> +     unsigned long size, off;
>> +     struct page *page;
>> +
>> +     area = vmalloc_user(vma->vm_end - vma->vm_start);
>> +     if (!area)
>> +             return -ENOMEM;
>> +
>> +     spin_lock(&kcov->lock);
>> +     size = kcov->size * sizeof(unsigned long);
>> +     if (kcov->mode == 0 || vma->vm_pgoff != 0 ||
>
> kcov->mode has type `enum kcov_mode'.  We should hard-wire a zero in
> here: neater to create KCOV_MODE_DISABLED or whatever?  In multiple
> places.
>
>> +         vma->vm_end - vma->vm_start != size) {
>> +             res = -EINVAL;
>> +             goto exit;
>> +     }
>> +     if (!kcov->area) {
>> +             kcov->area = area;
>> +             vma->vm_flags |= VM_DONTEXPAND;
>> +             spin_unlock(&kcov->lock);
>> +             for (off = 0; off < size; off += PAGE_SIZE) {
>> +                     page = vmalloc_to_page(kcov->area + off);
>> +                     if (vm_insert_page(vma, vma->vm_start + off, page))
>> +                             WARN_ONCE(1, "vm_insert_page() failed");
>> +             }
>> +             return 0;
>> +     }
>> +exit:
>> +     spin_unlock(&kcov->lock);
>> +     vfree(area);
>> +     return res;
>> +}
>> +
>>
>> ...
>>
>> +static int kcov_ioctl_locked(struct kcov *kcov, unsigned int cmd,
>> +                          unsigned long arg)
>> +{
>> +     struct task_struct *t;
>> +
>> +     switch (cmd) {
>> +     case KCOV_INIT_TRACE:
>> +             /*
>> +              * Enable kcov in trace mode and setup buffer size.
>> +              * Must happen before anything else.
>> +              * Size must be at least 2 to hold current position and one PC.
>> +              */
>> +             if (arg < 2 || arg > INT_MAX)
>> +                     return -EINVAL;
>> +             if (kcov->mode != 0)
>> +                     return -EBUSY;
>> +             kcov->mode = KCOV_MODE_TRACE;
>> +             kcov->size = arg;
>
> kcov->size comes in from userspace and later get multiplied by
> sizeof(unsigned long).  This means that userspace can trigger math
> overflows (on 32-bit if that happens) and havoc might ensue.  So can we
> please get some better checks in place for `size'?
>
> Also, move these checks (of `arg') so they immediately precede this
> *usage* of `arg' so the reader can better see what's happening.
>
>> +             return 0;
>> +     case KCOV_ENABLE:
>> +             /*
>> +              * Enable coverage for the current task.
>> +              * At this point user must have been enabled trace mode,
>> +              * and mmapped the file. Coverage collection is disabled only
>> +              * at task exit or voluntary by KCOV_DISABLE. After that it can
>> +              * be enabled for another task.
>> +              */
>> +             if (arg != 0 || kcov->mode == 0 || kcov->area == NULL)
>> +                     return -EINVAL;
>
> This reader doesn't know what is in "arg".  Documentation, please.  Or
> copy `arg' into a suitably named local.
>
>> +             if (kcov->t != NULL)
>> +                     return -EBUSY;
>> +             t = current;
>> +             /* Cache in task struct for performance. */
>> +             t->kcov_size = kcov->size;
>> +             t->kcov_area = kcov->area;
>> +             /* See comment in __sanitizer_cov_trace_pc(). */
>> +             barrier();
>> +             WRITE_ONCE(t->kcov_mode, kcov->mode);
>> +             t->kcov = kcov;
>> +             kcov->t = t;
>> +             /* This is put either in kcov_task_exit() or in KCOV_DISABLE. */
>> +             kcov_get(kcov);
>
> We didn't get a ref on the task_struct.  I guess that's OK because
> task_struct.kcov gets torn down in kcov_task_exit().

Yes. We can't have coverage collection enabled for a dead task.

> But what happens if userspace simply closes the fd without running
> KCOV_DISABLE?  ?

That's why we take the reference here. Struct kcov descriptor lives
while (1) the fd is opened _or_ (2) coverage collection is enabled for
a task. It would be weird for a program to close the fd (and unmap the
mapping) while coverage collection is still enabled, but it should not
affect collection. Struct kcov will be freed when the task exits in
this case.



>> +             return 0;
>> +     case KCOV_DISABLE:
>> +             /* Disable coverage for the current task. */
>> +             if (arg != 0 || current->kcov != kcov)
>> +                     return -EINVAL;
>
> This reader doesn't know what `arg' means.
>
>> +             t = current;
>> +             if (WARN_ON(kcov->t != t))
>> +                     return -EINVAL;
>> +             kcov_task_init(t);
>> +             kcov->t = NULL;
>> +             kcov_put(kcov);
>> +             return 0;
>> +     default:
>> +             return -EINVAL;
>
> For reasons I don't recall, we conventionally return -ENOTTY for
> unimplemented ioctl modes.  Alan Cox will remember ;)
>
> http://www.makelinux.net/ldd3/chp-6-sect-1 says
>
> : This error code is interpreted by the C library as "inappropriate ioctl
> : for device," which is usually exactly what the programmer needs to
> : hear.  It's still pretty common, though, to return -EINVAL in response
> : to an invalid ioctl command.
>
>> +     }
>> +}
>> +
>> +static long kcov_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
>> +{
>> +     struct kcov *kcov;
>> +     int res;
>> +
>> +     kcov = filep->private_data;
>> +     spin_lock(&kcov->lock);
>> +     res = kcov_ioctl_locked(kcov, cmd, arg);
>> +     spin_unlock(&kcov->lock);
>> +     return res;
>> +}
>
> Wait.  `unsigned long arg' is going to be a 32-bit quantity when a
> 32-bit executable is running on a 64-bit kernel.  Doesn't this ioctl
> need compat handling?

As far as I see in compat_ioctl.c, in my case arg will be just
zero-extended. Since we use the arg only to pass buffer size,
zero-extension is fine.

Mailed "kcov: clean up code" patch to address the rest of comments.


From lkp at intel.com  Wed Feb 24 03:29:21 2016
From: lkp at intel.com (kbuild test robot)
Date: Wed, 24 Feb 2016 19:29:21 +0800
Subject: [PATCH v3 2/2] ohci-platform: Add support for controllers with
 multiple reset lines
In-Reply-To: <1456312517-24211-3-git-send-email-hdegoede@redhat.com>
Message-ID: <201602241923.LqWYVmK3%fengguang.wu@intel.com>

Hi Hans,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.5-rc5 next-20160223]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Hans-de-Goede/ehci-platform-Add-support-for-controllers-with-multiple-reset-lines/20160224-191812
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: x86_64-randconfig-x004-201608 (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/usb/host/ohci-platform.c: In function 'ohci_platform_probe':
>> drivers/usb/host/ohci-platform.c:201:5: error: implicit declaration of function 'devm_reset_control_get_shared_by_index' [-Werror=implicit-function-declaration]
        devm_reset_control_get_shared_by_index(
        ^
>> drivers/usb/host/ohci-platform.c:200:22: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
       priv->resets[rst] =
                         ^
   cc1: some warnings being treated as errors

vim +/devm_reset_control_get_shared_by_index +201 drivers/usb/host/ohci-platform.c

   194						goto err_put_clks;
   195					priv->clks[clk] = NULL;
   196					break;
   197				}
   198			}
   199			for (rst = 0; rst < OHCI_MAX_RESETS; rst++) {
 > 200				priv->resets[rst] =
 > 201					devm_reset_control_get_shared_by_index(
   202									&dev->dev, rst);
   203				if (IS_ERR(priv->resets[rst])) {
   204					err = PTR_ERR(priv->resets[rst]);

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 24241 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/c3f43aad/attachment-0001.obj>

From mark.rutland at arm.com  Wed Feb 24 03:32:28 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 24 Feb 2016 11:32:28 +0000
Subject: [PATCH V2] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <56CCF03D.3000809@caviumnetworks.com>
References: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160223122616.GE4989@leverpostej>
 <56CCF03D.3000809@caviumnetworks.com>
Message-ID: <20160224113227.GB11579@leverpostej>

On Tue, Feb 23, 2016 at 03:50:21PM -0800, Tirumalesh Chalamarla wrote:
> in Summary,
> 
> if i change asid-base to cavium,asid-base and still use DT for
> supplying base value, is this a solution that will be accepted, 

No. The property is _insufficient_, regardless of its name. This has
been pointed out more than once.

A base alone does not tell you what set of IDs it is valid to use
without risking a clash. The OS is well within its rights to allocate
_any_ ID above that base. It is not a requirement of the hardware nor
the binding that the OS allocate a contiguous set of IDs starting at the
base.

Consider:

smmu_a {
	whatver,*id-base = <128>;
};

smmu_b {
	whatever,*id-base = <64>;
};

In both cases, the *IDs 129+ could be allocated on both SMMUs.

Mark.

> of course i will do range check to see we are not supplying 16bit VMID
> for 8 bit systems even though the property now indicates Cavium only.
> 
> Thanks,
> Tirumalesh.
> 
> On 02/23/2016 04:26 AM, Mark Rutland wrote:
> >On Thu, Feb 18, 2016 at 10:29:18AM -0800, tchalamarla at caviumnetworks.com wrote:
> >>From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> >>
> >>Due to Errata#27704 CN88xx SMMUv2,supports  only shared ASID and VMID
> >>namespaces; specifically within a given node SMMU0 and SMMU1 share,
> >>as does SMMU2 and SMMU3.
> >>
> >>This patch tries to address these issuee by supplying asid and vmid
> >>base from devicetree.
> >>
> >>changes from V1:
> >>	- rebased on top of 16 bit VMID patch
> >>	- removed redundent options from DT
> >>	- insted of transform, DT now supplies starting ASID/VMID
> >>
> >>Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
> >>Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
> >>---
> >>  .../devicetree/bindings/iommu/arm,smmu.txt         |  8 +++++
> >>  drivers/iommu/arm-smmu.c                           | 37 +++++++++++++++-------
> >>  2 files changed, 34 insertions(+), 11 deletions(-)
> >>
> >>diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> >>index bb7e569..80b8484 100644
> >>--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> >>+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> >>@@ -57,6 +57,14 @@ conditions.
> >>
> >>  - smmu-enable-vmid16 : Enable 16 bit VMID, if allowed.
> >>
> >>+- asid-base :	Buggy SMMUv2 implementations which doesn't satisfy the
> >>+		ASID namespace needs, use this field to specify starting
> >>+		ASID for the SMMU.
> >>+
> >>+- vmid-base :	Buggy SMMUv2 implementations which doesn't satisfy the VMID
> >>+		namespace needs, use this field to specify starting VMID
> >>+		for the SMMU.
> >
> >As has been pointed out, these are not strictly properties of the
> >hardware, and are insufficient to aovid the issue in general (adding an
> >arbitrary base does not enforce IDs fall within a particular range).
> >
> >So NAK for *-base properties alone.
> >
> >>+	if (of_property_read_u32(dev->of_node, "#asid-base",
> >>+				 &smmu->asid_base)) {
> >>+		smmu->asid_base = 0;
> >>+	}
> >>+
> >>+	if (of_property_read_u32(dev->of_node, "#vmid-base",
> >>+				 &smmu->vmid_base)) {
> >>+		smmu->vmid_base = 1;
> >>+	}
> >
> >These do not match the documentation above.
> >
> >Mark.
> >
> 


From lkp at intel.com  Wed Feb 24 03:32:33 2016
From: lkp at intel.com (kbuild test robot)
Date: Wed, 24 Feb 2016 19:32:33 +0800
Subject: [PATCH v3 1/2] ehci-platform: Add support for controllers with
 multiple reset lines
In-Reply-To: <1456312517-24211-2-git-send-email-hdegoede@redhat.com>
Message-ID: <201602241959.92PQx0Sd%fengguang.wu@intel.com>

Hi Reinder,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.5-rc5 next-20160223]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Hans-de-Goede/ehci-platform-Add-support-for-controllers-with-multiple-reset-lines/20160224-191812
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: x86_64-randconfig-x004-201608 (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/usb/host/ehci-platform.c: In function 'ehci_platform_probe':
>> drivers/usb/host/ehci-platform.c:239:5: error: implicit declaration of function 'devm_reset_control_get_shared_by_index' [-Werror=implicit-function-declaration]
        devm_reset_control_get_shared_by_index(
        ^
>> drivers/usb/host/ehci-platform.c:238:22: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
       priv->resets[rst] =
                         ^
   cc1: some warnings being treated as errors

vim +/devm_reset_control_get_shared_by_index +239 drivers/usb/host/ehci-platform.c

   232					priv->clks[clk] = NULL;
   233					break;
   234				}
   235			}
   236	
   237			for (rst = 0; rst < EHCI_MAX_RESETS; rst++) {
 > 238				priv->resets[rst] =
 > 239					devm_reset_control_get_shared_by_index(
   240									&dev->dev, rst);
   241				if (IS_ERR(priv->resets[rst])) {
   242					err = PTR_ERR(priv->resets[rst]);

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 24241 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/733e3be9/attachment-0001.obj>

From linux at arm.linux.org.uk  Wed Feb 24 03:35:49 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 24 Feb 2016 11:35:49 +0000
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56CD924F.50108@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
 <56CC546A.9070705@ti.com>
 <20160224104638.GL19428@n2100.arm.linux.org.uk>
 <56CD924F.50108@ti.com>
Message-ID: <20160224113549.GN19428@n2100.arm.linux.org.uk>

On Wed, Feb 24, 2016 at 01:21:51PM +0200, Tomi Valkeinen wrote:
> On 24/02/16 12:46, Russell King - ARM Linux wrote:
> > On Tue, Feb 23, 2016 at 02:45:30PM +0200, Tomi Valkeinen wrote:
> >> My opinion is that the bootloader should be responsible for telling the
> >> kernel what hardware there is on the board. For busses like PCI we have
> >> proper probing mechanism with global unique identifiers for the devices,
> >> and nothing is needed from the bootloader.
> > 
> > Exactly, but that is _NOT_ the case here, because we're not talking
> > about an on-board display.
> 
> Ok, what is it then? I'm not familiar with the boards in question.
> 
> When does a display become an on-board display? All the panels I have
> can be disconnected quite easily, but I still consider them as on-board
> displays.

The difference to me is quite clear.

If the connector is a flexi-strip or LVDS connector designed to be
connected directly to a panel, it is not designed as a user connector,
and the display can be regarded as part of the board: the connector
probably isn't rated for a large number of mating cycles.

If the connector is a board-edge external-unit connector, then the
panel is not part of the board.

In the case of Versatile, it's the latter: the connector is situated
at the board edge, next to the serial port connectors, and is designed
to connect to an external box housing the display.

> > That argument does not stack up.  Just because you've plugged in a
> > network device does not mean that the kernel can drive it: the kernel
> > needs a device specific driver, which is determined by looking at the
> > IDs.  There is no standard network driver PCI interface.
> 
> Yes, but you can connect the network device to any board with a PCI bus
> and it works. Here, if I'm not mistaken, the displays are built for this
> single board, making them board specific.

It only works because Linux has a rich array of network drivers supporting
all that hardware, and the appropriate network driver is bound depending
on the hardware ID of the card.  If a new PCI network device comes out,
it'll more likely than not require an update to a network driver to make
it work.

The displays are not built for "this single board" but for a family of
boards: not only Versatile PB/AB, but also the Realview family of boards
too.

> But I cannot accept that as a general solution for all similar cases
> going forward, especially when moving to DRM world, that's just bad SW
> design.

I think that's a matter of personal opinion, perspective and situation.
What is good design today is not necessary good design yesterday or
tomorrow.  I thought we already ascertained that earlier in this
discussion. :)

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From tomi.valkeinen at ti.com  Wed Feb 24 03:35:56 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Wed, 24 Feb 2016 13:35:56 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <20160224105304.GM19428@n2100.arm.linux.org.uk>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <3695074.sKSIyOjpjD@wuerfel>
 <CACRpkdZjfjOCFUucF1U5yVZBxSwa41GKEMv-HHQE=ymF2NZ21g@mail.gmail.com>
 <6859810.tb1t0IEONi@wuerfel> <56CC57FC.20707@ti.com>
 <CACRpkdYNaNtQQJ-tsBe5ksa4-z380ZQj-zN8ZnK0ED2kNPUwvg@mail.gmail.com>
 <56CC60C4.6040908@ti.com> <20160224105304.GM19428@n2100.arm.linux.org.uk>
Message-ID: <56CD959C.9050007@ti.com>

On 24/02/16 12:53, Russell King - ARM Linux wrote:
> On Tue, Feb 23, 2016 at 03:38:12PM +0200, Tomi Valkeinen wrote:
>> Ok. I feel everyone is trying to push the ugly part out of their domain.
>> I want the board specific hacks out of fbdev. Bootloader people don't
>> want it there. arch/arm/ people don't want it there. =)
> 
> I think that is really really unfair.  No one is trying to push ugly
> bits out of their domain - this is being driven by Linus, who is
> trying to convert Versatile to DT.  There is no other agenda here.
> 
> Remember, I was the one who wrote the CLCD driver, and it was written
> to support the boards at the time using the best methods at the time.
> Things change, people's ideas of what's acceptable change.  What was
> acceptable when classes of boards were separate is no longer acceptable
> with single zImage.

That's fine. I've done the same. The point here is where should we aim
for with today's kernel? What's the good solution for the future boards?

> The board specific parts of CLCD were in arch/arm for a very long time,
> but that gets in the way of single zImage, and the solution adopted by
> the newly interested parties has been to move them to drivers/video
> to keep things working.

And I'm fine with having board specific parts in drivers/video when
needed. That's the only option when we really need a driver for the
board specific parts, i.e. we need to do something with the board
specific HW at runtime.

But that's not really the case with Versatile. Correct me if I'm wrong,
but there's just one panel connected to the board at a time and the
panel cannot be changed at runtime. We need to do the board specific
panel probing once at boot time, but other than that, there's no
difference to a single on-board panel.

To me it sounds that the cleanest solution to this is that the
bootloader does the detection (it's a trivial detection, isn't it? no
complex busses need to be used?), and just passes the kernel the correct
HW setup with DT.

Again, I understand there are lots of board out there without bootloader
doing that, so we may not get there with Versatile. But if someone comes
with patches for a new board, I'd like to have a good suggestion how to
handle similar cases the best way.

> That's how we're here: there isn't a conspiracy as you seem to be
> thinking.

I wasn't exactly serious there, as the smiley tried to imply...

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/6b6f3241/attachment.sig>

From rogerq at ti.com  Wed Feb 24 03:37:49 2016
From: rogerq at ti.com (Roger Quadros)
Date: Wed, 24 Feb 2016 13:37:49 +0200
Subject: [PATCH v3 1/2] ehci-platform: Add support for controllers with
 multiple reset lines
In-Reply-To: <1456312517-24211-2-git-send-email-hdegoede@redhat.com>
References: <1456312517-24211-1-git-send-email-hdegoede@redhat.com>
 <1456312517-24211-2-git-send-email-hdegoede@redhat.com>
Message-ID: <56CD960D.3000900@ti.com>

Hi,

On 24/02/16 13:15, Hans de Goede wrote:
> From: Reinder de Haan <patchesrdh at mveas.com>
> 
> At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
> reset lines, the controller will not initialize while the reset for
> its companion is still asserted, which means we need to de-assert
> 2 resets for the controller to work.
> 
> Signed-off-by: Reinder de Haan <patchesrdh at mveas.com>
> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
> ---
> Changes in v2:
> -Use the new reset_control_[de]assert_shared reset-controller functions
> Changes in v3:
> -Adjust for changes to shared-reset reset-controller functions
> ---
>  Documentation/devicetree/bindings/usb/usb-ehci.txt |  2 +-
>  drivers/usb/host/ehci-platform.c                   | 41 ++++++++++++----------
>  2 files changed, 24 insertions(+), 19 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt
> index a12d601..0701812 100644
> --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
> @@ -18,7 +18,7 @@ Optional properties:
>   - clocks : a list of phandle + clock specifier pairs
>   - phys : phandle + phy specifier pair
>   - phy-names : "usb"
> - - resets : phandle + reset specifier pair
> + - resets : a list of phandle + reset specifier pairs
>  
>  Example (Sequoia 440EPx):
>      ehci at e0000300 {
> diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
> index bd7082f2..3f195ba 100644
> --- a/drivers/usb/host/ehci-platform.c
> +++ b/drivers/usb/host/ehci-platform.c
> @@ -39,11 +39,12 @@
>  
>  #define DRIVER_DESC "EHCI generic platform driver"
>  #define EHCI_MAX_CLKS 3
> +#define EHCI_MAX_RESETS 2
>  #define hcd_to_ehci_priv(h) ((struct ehci_platform_priv *)hcd_to_ehci(h)->priv)
>  
>  struct ehci_platform_priv {
>  	struct clk *clks[EHCI_MAX_CLKS];
> -	struct reset_control *rst;
> +	struct reset_control *resets[EHCI_MAX_RESETS];
>  	struct phy **phys;
>  	int num_phys;
>  	bool reset_on_resume;
> @@ -149,7 +150,7 @@ static int ehci_platform_probe(struct platform_device *dev)
>  	struct usb_ehci_pdata *pdata = dev_get_platdata(&dev->dev);
>  	struct ehci_platform_priv *priv;
>  	struct ehci_hcd *ehci;
> -	int err, irq, phy_num, clk = 0;
> +	int err, irq, phy_num, clk = 0, rst = 0;
>  
>  	if (usb_disabled())
>  		return -ENODEV;
> @@ -232,18 +233,22 @@ static int ehci_platform_probe(struct platform_device *dev)
>  				break;
>  			}
>  		}
> -	}
>  
> -	priv->rst = devm_reset_control_get_optional(&dev->dev, NULL);
> -	if (IS_ERR(priv->rst)) {
> -		err = PTR_ERR(priv->rst);
> -		if (err == -EPROBE_DEFER)
> -			goto err_put_clks;
> -		priv->rst = NULL;
> -	} else {
> -		err = reset_control_deassert(priv->rst);
> -		if (err)
> -			goto err_put_clks;
> +		for (rst = 0; rst < EHCI_MAX_RESETS; rst++) {
> +			priv->resets[rst] =
> +				devm_reset_control_get_shared_by_index(
> +								&dev->dev, rst);
> +			if (IS_ERR(priv->resets[rst])) {
> +				err = PTR_ERR(priv->resets[rst]);
> +				if (err == -EPROBE_DEFER)
> +					goto err_reset;
> +				priv->resets[rst] = NULL;
> +				break;
> +			}
> +			err = reset_control_deassert(priv->resets[rst]);
> +			if (err)
> +				goto err_reset;
> +		}

Why is this code within "if (dev->of.node)" ?
Previous code looked like it worked for non-DT boots as well.

>  	}
>  
>  	if (pdata->big_endian_desc)
> @@ -300,8 +305,8 @@ err_power:
>  	if (pdata->power_off)
>  		pdata->power_off(dev);
>  err_reset:
> -	if (priv->rst)
> -		reset_control_assert(priv->rst);
> +	while (--rst >= 0)
> +		reset_control_assert(priv->resets[rst]);
>  err_put_clks:
>  	while (--clk >= 0)
>  		clk_put(priv->clks[clk]);
> @@ -319,15 +324,15 @@ static int ehci_platform_remove(struct platform_device *dev)
>  	struct usb_hcd *hcd = platform_get_drvdata(dev);
>  	struct usb_ehci_pdata *pdata = dev_get_platdata(&dev->dev);
>  	struct ehci_platform_priv *priv = hcd_to_ehci_priv(hcd);
> -	int clk;
> +	int clk, rst;
>  
>  	usb_remove_hcd(hcd);
>  
>  	if (pdata->power_off)
>  		pdata->power_off(dev);
>  
> -	if (priv->rst)
> -		reset_control_assert(priv->rst);
> +	for (rst = 0; rst < EHCI_MAX_RESETS && priv->resets[rst]; rst++)
> +		reset_control_assert(priv->resets[rst]);
>  
>  	for (clk = 0; clk < EHCI_MAX_CLKS && priv->clks[clk]; clk++)
>  		clk_put(priv->clks[clk]);
> 

cheers,
-roger


From christoffer.dall at linaro.org  Wed Feb 24 03:40:44 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 24 Feb 2016 12:40:44 +0100
Subject: [PATCH] arm/arm64: KVM: Feed initialized memory to MMIO accesses
In-Reply-To: <1455723260-23793-1-git-send-email-marc.zyngier@arm.com>
References: <1455723260-23793-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160224114044.GA18451@cbox>

On Wed, Feb 17, 2016 at 03:34:20PM +0000, Marc Zyngier wrote:
> On an MMIO access, we always copy the on-stack buffer info
> the shared "run" structure, even if this is a read access.
> This ends up leaking up to 8 bytes of uninitialized memory
> into userspace.

I think it only leaks 'len' bytes to userspace ;)

> 
> An obvious fix for this one is to only perform the copy if
> this is an actual write.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>

> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm/kvm/mmio.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
> index 7f33b20..0f6600f 100644
> --- a/arch/arm/kvm/mmio.c
> +++ b/arch/arm/kvm/mmio.c
> @@ -206,7 +206,8 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run,
>  	run->mmio.is_write	= is_write;
>  	run->mmio.phys_addr	= fault_ipa;
>  	run->mmio.len		= len;
> -	memcpy(run->mmio.data, data_buf, len);
> +	if (is_write)
> +		memcpy(run->mmio.data, data_buf, len);
>  
>  	if (!ret) {
>  		/* We handled the access successfully in the kernel. */
> -- 
> 2.1.4
> 


From tomi.valkeinen at ti.com  Wed Feb 24 03:47:36 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Wed, 24 Feb 2016 13:47:36 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <20160224113549.GN19428@n2100.arm.linux.org.uk>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
 <56CC546A.9070705@ti.com> <20160224104638.GL19428@n2100.arm.linux.org.uk>
 <56CD924F.50108@ti.com> <20160224113549.GN19428@n2100.arm.linux.org.uk>
Message-ID: <56CD9858.40104@ti.com>

On 24/02/16 13:35, Russell King - ARM Linux wrote:

> If the connector is a flexi-strip or LVDS connector designed to be
> connected directly to a panel, it is not designed as a user connector,
> and the display can be regarded as part of the board: the connector
> probably isn't rated for a large number of mating cycles.
> 
> If the connector is a board-edge external-unit connector, then the
> panel is not part of the board.

Ok, I see. I presumed the display-board was attached directly to the
mainboard. Of course, we could still argue about the difference, with
the exact same pins used with an external connector and with an on-board
connector, but lets not go there.

I agree in this case the panels are external devices =).

However, I would still be interested in opinions how to implement the
exact same case, but for boards where the panels were considered
on-board panels.

> The displays are not built for "this single board" but for a family of
> boards: not only Versatile PB/AB, but also the Realview family of boards
> too.

Alright.

So, if this is to be done correctly, we need to disconnect the display
board code from the CLCD code, as they really have nothing to do with
each other.

Perhaps a panel driver which covers the display boards used here, which
does the probing and contains the video timings for the panels in question?

One could then use that panel driver with other display controllers too.
Although the probing part is perhaps difficult to make generic, but that
board specific code should still be part of the panel-board driver, not
CLCD driver.

>> But I cannot accept that as a general solution for all similar cases
>> going forward, especially when moving to DRM world, that's just bad SW
>> design.
> 
> I think that's a matter of personal opinion, perspective and situation.
> What is good design today is not necessary good design yesterday or
> tomorrow.  I thought we already ascertained that earlier in this
> discussion. :)

Well, I was mostly referring to combining separate devices into single
driver. CLCD and the external displays, in this case. Then again,
"complexity" is part of the SW design, and splitting the devices drivers
into independent pieces often increases complexity, so...

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/2f80fff6/attachment-0001.sig>

From christoffer.dall at linaro.org  Wed Feb 24 03:51:00 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 24 Feb 2016 12:51:00 +0100
Subject: [PATCH] arm/arm64: KVM: vgic: Handle out-of-bound MMIO access
In-Reply-To: <1455723281-23846-1-git-send-email-marc.zyngier@arm.com>
References: <1455723281-23846-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160224115100.GB18451@cbox>

On Wed, Feb 17, 2016 at 03:34:41PM +0000, Marc Zyngier wrote:
> When performing a MMIO access via a KVM IO bus, it is possible
> that the access will actually be out-of-bounds (the redistributor
> handlers do not cover the whole device, for example). In this case,
> we return an error code, which leads to escaping to userspace
> to handle it. Not that good.

Are all such OOB accesses on hardware simply RAZ/WI?

> 
> Instead, let's just treat it like any other OOB access, by either
> ignoring the write, or by returning a bunch of zeroes.
> 
> And let's keep the code quiet while we're at it, as nobody likes
> it when a guest can generate zillions on messages on the host's
> console...
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  virt/kvm/arm/vgic.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
> index 043032c..2358272 100644
> --- a/virt/kvm/arm/vgic.c
> +++ b/virt/kvm/arm/vgic.c
> @@ -830,8 +830,11 @@ static int vgic_handle_mmio_access(struct kvm_vcpu *vcpu,
>  	offset = addr - iodev->addr;
>  	range = vgic_find_range(iodev->reg_ranges, len, offset);
>  	if (unlikely(!range || !range->handle_mmio)) {
> -		pr_warn("Unhandled access %d %08llx %d\n", is_write, addr, len);
> -		return -ENXIO;
> +		/* Treat an OOR access as RAZ/WI. */
> +		if (!is_write)
> +			memset(val, 0, len);
> +		pr_debug("Unhandled access %d %08llx %d\n", is_write, addr, len);
> +		return 0;
>  	}
>  
>  	mmio.phys_addr = addr;
> -- 
> 2.1.4
> 

This patch looks fine, but looking at that code, why do we write to
vcpu->run->mmio and call kvm_handle_mio_return in
vgic_handle_mmio_access and also in io_mem_abort?

After this patch you now have two return paths from this function that
both return 0, but only one of them does copies to vcpu->run and calls
the handle return function.

/me confused.

Thanks,
-Christoffer


From christoffer.dall at linaro.org  Wed Feb 24 03:53:24 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 24 Feb 2016 12:53:24 +0100
Subject: [PATCH] arm64: KVM: vgic-v3: Restore ICH_APR0Rn_EL2 before
 ICH_APR0Rn_EL2
In-Reply-To: <1455723312-23896-1-git-send-email-marc.zyngier@arm.com>
References: <1455723312-23896-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <20160224115324.GC18451@cbox>

On Wed, Feb 17, 2016 at 03:35:12PM +0000, Marc Zyngier wrote:
> The GICv3 architecture spec says:
> 
> Writing to the active priority registers in any order other than
> the following order will result in UNPREDICTABLE behavior:
> - ICH_AP0R<n>_EL2.
> - ICH_AP1R<n>_EL2.
> 
> So let's not pointlessly go against the rule...
> 
> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> ---
>  arch/arm64/kvm/hyp/vgic-v3-sr.c | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
> index 9142e082..93f6c5c 100644
> --- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
> +++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
> @@ -149,16 +149,6 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
>  
>  	switch (nr_pri_bits) {
>  	case 7:
> -		 write_gicreg(cpu_if->vgic_ap1r[3], ICH_AP1R3_EL2);
> -		 write_gicreg(cpu_if->vgic_ap1r[2], ICH_AP1R2_EL2);
> -	case 6:
> -		 write_gicreg(cpu_if->vgic_ap1r[1], ICH_AP1R1_EL2);
> -	default:
> -		 write_gicreg(cpu_if->vgic_ap1r[0], ICH_AP1R0_EL2);
> -	}	 	                           
> -		 	                           
> -	switch (nr_pri_bits) {
> -	case 7:
>  		 write_gicreg(cpu_if->vgic_ap0r[3], ICH_AP0R3_EL2);
>  		 write_gicreg(cpu_if->vgic_ap0r[2], ICH_AP0R2_EL2);
>  	case 6:
> @@ -167,6 +157,16 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
>  		 write_gicreg(cpu_if->vgic_ap0r[0], ICH_AP0R0_EL2);
>  	}
>  
> +	switch (nr_pri_bits) {
> +	case 7:
> +		 write_gicreg(cpu_if->vgic_ap1r[3], ICH_AP1R3_EL2);
> +		 write_gicreg(cpu_if->vgic_ap1r[2], ICH_AP1R2_EL2);
> +	case 6:
> +		 write_gicreg(cpu_if->vgic_ap1r[1], ICH_AP1R1_EL2);
> +	default:
> +		 write_gicreg(cpu_if->vgic_ap1r[0], ICH_AP1R0_EL2);
> +	}	 	                           
> +		 	                           

could you prune that extra pointless white space while you're at it?

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>

Thanks,
-Christoffer

>  	switch (max_lr_idx) {
>  	case 15:
>  		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(15)], ICH_LR15_EL2);
> -- 
> 2.1.4
> 


From tomi.valkeinen at ti.com  Wed Feb 24 04:06:21 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Wed, 24 Feb 2016 14:06:21 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CAFEAcA-Y7rE_9CiOphgmae3FDApRznoBS7vsVN_+9hBqvAzEEA@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
 <56CC546A.9070705@ti.com>
 <CAFEAcA-Y7rE_9CiOphgmae3FDApRznoBS7vsVN_+9hBqvAzEEA@mail.gmail.com>
Message-ID: <56CD9CBD.5010106@ti.com>

On 23/02/16 15:49, Peter Maydell wrote:
> On 23 February 2016 at 12:45, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
>> So, true, there's probing going on, but it's all board specific,
>> requiring a board specific driver to support it in the kernel. And I
>> think that makes the bootloader much better place for supporting it.
> 
> This doesn't seem to me like a reason to put the requirement
> in the bootloader. A huge part of the purpose of the kernel
> is to support the hardware (whether that's completely generic
> and probeable, like PCI, or generic but not probeable, or
> completely specific to a particular board). The kernel has to
> support the hardware, and just because it happens to be board
> specific hardware rather than generic hardware doesn't seem to
> me to imply that the kernel gets to drop part of its core purpose.

The thing here is, the kernel doesn't have to support the hardware (the
probing method). The kernel _has_ to support the display controller and
the panels, but the probing could as well be done in the bootloader. It
would work fine, and it would be a cleaner solution that what's being
proposed so far.

>> I think one of the core questions here is: do we want to start adding
>> board specific drivers to the kernel, instead of dealing with it in the
>> bootloader when possible? My understanding is that we've been trying to
>> reduce board specific code from the kernel.
> 
> I think there's a difference between "reduce board specific code
> in the kernel by replacing it with the combination of generic
> or parameterisable code in the kernel plus a kernel data structure
> (DT) that supplies the parameterisation needed", and "reduce
> board specific code in the kernel by forcing the bootloader to
> do the kernel's job for it".

Perhaps my phone background affects here, but I see the vendor provided
bootloader as the place for board specific custom solutions, and then
the kernel doesn't have to deal with those if at all possible.

With an open source generic bootloader like u-boot that doesn't exactly
hold, though, as the custom solutions will still pile up in a common
project.

Anyway, as discussed in the thread, I'm fine with having a kernel driver
for this, as the display boards for Versatile are an external device.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/b8465d20/attachment.sig>

From marc.zyngier at arm.com  Wed Feb 24 04:06:52 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Feb 2016 12:06:52 +0000
Subject: [PATCH] arm/arm64: KVM: Feed initialized memory to MMIO accesses
In-Reply-To: <20160224114044.GA18451@cbox>
References: <1455723260-23793-1-git-send-email-marc.zyngier@arm.com>
 <20160224114044.GA18451@cbox>
Message-ID: <56CD9CDC.2020100@arm.com>

On 24/02/16 11:40, Christoffer Dall wrote:
> On Wed, Feb 17, 2016 at 03:34:20PM +0000, Marc Zyngier wrote:
>> On an MMIO access, we always copy the on-stack buffer info
>> the shared "run" structure, even if this is a read access.
>> This ends up leaking up to 8 bytes of uninitialized memory
>> into userspace.
> 
> I think it only leaks 'len' bytes to userspace ;)
> 
>>
>> An obvious fix for this one is to only perform the copy if
>> this is an actual write.
> 
> Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>

Thanks. I've pushed this onto master, with a view of sending a PR to
Paolo this evening (hopefully the last one for this cycle).

	M.
-- 
Jazz is not dead. It just smells funny...


From sebott at linux.vnet.ibm.com  Wed Feb 24 04:11:58 2016
From: sebott at linux.vnet.ibm.com (Sebastian Ott)
Date: Wed, 24 Feb 2016 13:11:58 +0100 (CET)
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160224093915.6e163a33@mschwide>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name> <56BE00E7.1010303@de.ibm.com>
 <20160212181640.4eabb85f@thinkpad> <20160223103221.GA1418@node.shutemov.name>
 <20160223191907.25719a4d@thinkpad> <20160223193345.GC21820@node.shutemov.name>
 <20160224093915.6e163a33@mschwide>
Message-ID: <alpine.LFD.2.20.1602241307130.1533@schleppi>

On Wed, 24 Feb 2016, Martin Schwidefsky wrote:
> On Tue, 23 Feb 2016 22:33:45 +0300
> "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> 
> > On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> > > I'll check with Martin, maybe it is actually trivial, then we can
> > > do a quick test it to rule that one out.
> > 
> > Oh. I found a bug in __split_huge_pmd_locked(). Although, not sure if it's
> > _the_ bug.
> > 
> > pmdp_invalidate() is called for the wrong address :-/
> > I guess that can be destructive on the architecture, right?
> > 
> > Could you check this?
> > 
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 1c317b85ea7d..4246bc70e55a 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -2865,7 +2865,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
> >  	pgtable = pgtable_trans_huge_withdraw(mm, pmd);
> >  	pmd_populate(mm, &_pmd, pgtable);
> > 
> > -	for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
> > +	for (i = 0; i < HPAGE_PMD_NR; i++) {
> >  		pte_t entry, *pte;
> >  		/*
> >  		 * Note that NUMA hinting access restrictions are not
> > @@ -2886,9 +2886,9 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
> >  		}
> >  		if (dirty)
> >  			SetPageDirty(page + i);
> > -		pte = pte_offset_map(&_pmd, haddr);
> > +		pte = pte_offset_map(&_pmd, haddr + i * PAGE_SIZE);
> >  		BUG_ON(!pte_none(*pte));
> > -		set_pte_at(mm, haddr, pte, entry);
> > +		set_pte_at(mm, haddr + i * PAGE_SIZE, pte, entry);
> >  		atomic_inc(&page[i]._mapcount);
> >  		pte_unmap(pte);
> >  	}
> > @@ -2938,7 +2938,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
> >  	pmd_populate(mm, pmd, pgtable);
> > 
> >  	if (freeze) {
> > -		for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
> > +		for (i = 0; i < HPAGE_PMD_NR; i++) {
> >  			page_remove_rmap(page + i, false);
> >  			put_page(page + i);
> >  		}
> 
> Test is running and it looks good so far. For the final assessment I defer
> to Gerald and Sebastian.
> 

Yes, that one worked. My testsystem is doing make -j10 && make clean
in a loop since 4 hours now. Thanks!

Sebastian



From pantelis.antoniou at konsulko.com  Wed Feb 24 04:13:49 2016
From: pantelis.antoniou at konsulko.com (Pantelis Antoniou)
Date: Wed, 24 Feb 2016 14:13:49 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56CD924F.50108@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
 <56CC546A.9070705@ti.com> <20160224104638.GL19428@n2100.arm.linux.org.uk>
 <56CD924F.50108@ti.com>
Message-ID: <B8A82546-46C7-4A21-92D8-62418E49FBB6@konsulko.com>

Hi Tomi,

> On Feb 24, 2016, at 13:21 , Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> 

[snip]

>> 
>> That argument does not stack up.  Just because you've plugged in a
>> network device does not mean that the kernel can drive it: the kernel
>> needs a device specific driver, which is determined by looking at the
>> IDs.  There is no standard network driver PCI interface.
> 
> Yes, but you can connect the network device to any board with a PCI bus
> and it works. Here, if I'm not mistaken, the displays are built for this
> single board, making them board specific.
> 
> So sure, someone could build boards with the same connector, allowing
> you to connect the same displays. If that's the case, then CLCD should
> be taken out of this picture, as the board could have something else
> than CLCD as the display controller.
> 
>>> I think one of the core questions here is: do we want to start adding
>>> board specific drivers to the kernel, instead of dealing with it in the
>>> bootloader when possible? My understanding is that we've been trying to
>>> reduce board specific code from the kernel.
>> 
>> That's not really the question, because that question assumes that it
>> isn't already present, which is not true.  The code is already present.
>> The question is how to deal with this from the DT perspective.
> 
> Yes. As I commented in this (or the other thread), I'm looking for a
> proper generic solution which can be recommended for all new boards.
> When we know what that is, we can see if and how that could fit into
> Versatile's case. Versatile is not the only board with the exact same
> problem.
> 
> I wouldn't be at all surprised if the final solution is to just go with
> Linus' current patches for Versatile, as everything else would break
> compatibility or be overly complex.
> 
> But I cannot accept that as a general solution for all similar cases
> going forward, especially when moving to DRM world, that's just bad SW
> design.
> 

IMHO DT+overlays handle all your cases just fine.

As far as I see these are the cases which we need to handle:

1) The expansion board in question has some means of identification, whether it?s an
EEPROM or a GPIO keying combination etc. In that case it is the kernel?s job to match this
id value with a dtbo firmware file and apply it. The blob is located via means of request_firmware().

2) The expansion board in question has no means of identification. In that case the bootloader?s
job is to provide user-configured means to the kernel to use the expansion board.

We talked about two basic schemes.

2.1) The kernel command line contains information about the extra overlays to apply upon booting.
Something like ?applyoverlays=foo.dtbo,bar.dtbo? is sufficient. The problem with this approach is that
if the firmware files must be present in the initrd/rootfs/builtin-kernel-image. For some this is a
problem.

2.2) The base DTB provided to the kernel from the bootloader is augmented with extra DTBOs that describe
the extra hardware. The concatenation is as simple as performing a ?$ cat base.dtb foo.dtbo bar.dtbo?, which
can be done either by the bootloader or offline.  At the moment this is not being done, but it?s easy enough
to add it and other people expressed interest for it.

Am I missing something here?

> Tomi
> 

Regards

? Pantelis



From k at japko.eu  Wed Feb 24 04:16:41 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Wed, 24 Feb 2016 13:16:41 +0100
Subject: [linux-sunxi] [PATCH 2/2] ARM: dts: sun8i: Enable ir receiver on
 orangepi pc
In-Reply-To: <1456268597-13692-3-git-send-email-hdegoede@redhat.com>
References: <1456268597-13692-1-git-send-email-hdegoede@redhat.com>
 <1456268597-13692-3-git-send-email-hdegoede@redhat.com>
Message-ID: <20160224121640.GA25658@box2.japko.eu>

On Wed, Feb 24, 2016 at 12:03:17AM +0100, Hans de Goede wrote:
>Enable the ir receiver found on the orangepi pc board.
>
>Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>---
> arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 6 ++++++
> 1 file changed, 6 insertions(+)
>
>diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts

I don't think this file is avaiable in mainline. Wouldn't it be better 
to use patch against existing orangepi-plus dts file?

Otherwise I tested this patch and it works fine on my Orangepi PC (some 
data is splitted out when reading /dev/input/event0).

Best regards,
Krzysztof Adamski


From vigneshr at ti.com  Wed Feb 24 04:21:08 2016
From: vigneshr at ti.com (Vignesh R)
Date: Wed, 24 Feb 2016 17:51:08 +0530
Subject: [PATCH v5 3/5] mtd: devices: m25p80: add support for mmap read
 request
In-Reply-To: <56C49B9E.8060506@ti.com>
References: <1449807000-6457-1-git-send-email-vigneshr@ti.com>
 <1449807000-6457-4-git-send-email-vigneshr@ti.com>
 <20160209193616.GN13270@sirena.org.uk> <56BC1D3E.5020203@ti.com>
 <20160212223711.GD18988@sirena.org.uk> <56C2D731.6050306@ti.com>
 <20160216123854.GJ18327@sirena.org.uk> <56C49B9E.8060506@ti.com>
Message-ID: <56CDA034.7050607@ti.com>



On 02/17/2016 09:41 PM, R, Vignesh wrote:
> 
> 
> On 02/16/2016 06:08 PM, Mark Brown wrote:
>> On Tue, Feb 16, 2016 at 01:30:49PM +0530, Vignesh R wrote:
>>> On 02/13/2016 04:07 AM, Mark Brown wrote:
>>>> On Thu, Feb 11, 2016 at 11:03:50AM +0530, Vignesh R wrote:
>>>>> On 02/10/2016 01:06 AM, Mark Brown wrote:
>>
>>>>>> Looking at this I can't help but think that spi_flash_read() ought to
>>>>>> have the stub in rather than the caller.  But given that we're pretty
>>>>>> much only ever expecting one user I'm not 100% sure it actually matters.
>>
>>>>> Well, my initial patch set passed long list of arguments to
>>>>> spi_flash_read(), but Brian suggested to use struct[1] in order to avoid
>>>>> unnecessary churn when things need changed in the API.
>>
>>>> I don't see what that has to do with my point?
>>
>>> AFAIU, your previous comment was to move initialization of
>>> spi_flash_read_message struct to spi_flash_read(). This would mean
>>
>> No, not at all.  I'm talking about how we handle the case where we don't
>> have hardware support for this and need to implement it in software -
>> currently that's in a separate place to the place where we call the
>> driver.
>>
> 
> Yeah, but AFAIK, hardware accelerated read support is applicable for
> m25p80 flashes only, I doubt whether spi_flash_read() will be used by
> other types. I felt keeping the software implementation in m25p80_read()
> will be consistent with m25p80_write().

Is there any further work required on the patch? If not, what's the plan
to merge this patch?

-- 
Regards
Vignesh


From robin.murphy at arm.com  Wed Feb 24 04:24:16 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 24 Feb 2016 12:24:16 +0000
Subject: [PATCH] ARM: realview: DT support for the PBA8
In-Reply-To: <1456303714-31039-1-git-send-email-linus.walleij@linaro.org>
References: <1456303714-31039-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <56CDA0F0.9050608@arm.com>

Hi Linus,

On 24/02/16 08:48, Linus Walleij wrote:
> This adds a devicetree for the ARM RealView PBA8 platform,
> also known as HBI-0178, "RealView(R) Platform Baseboard for
> Cortex(TM)-A8".
>
> Tested in QEMU with -M realview-pb-a8 and works like a charm,
> however with these annoying boot messages:
>
> of_amba_device_create(): amba_device_add()
>      failed (-19) for /soc/sysctl at 10001000
> of_amba_device_create(): amba_device_add()
>      failed (-19) for /soc/ssp at 1000d000
> of_amba_device_create(): amba_device_add()
>      failed (-19) for /soc/timer at 10018000
> of_amba_device_create(): amba_device_add()
>      failed (-19) for /soc/timer at 10019000
> of_amba_device_create(): amba_device_add()
>      failed (-19) for /soc/sysctl at 1001a000
>
> I think this is because these PrimeCells do not exist in the
> QEMU machine model but would work fine on the real hardware.
> QEMU still works, because the SP810 clocks will anyway probe,
> as they are not amba_devices but use the special CLK_OF_DECLARE()
> probing macro.

And here I thought that big black box on the far corner of my desk was 
only good for taking up space. I have no idea of its provenance, but 
here's what it had to say (using appended dtb and a hack in the 
decompressor to set r1=-1, r2=0 because I can't be bothered faffing with 
a 2010-vintage u-boot):

RealView PBA8 #go 0x7fc0
## Starting application at 0x00007FC0 ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.5.0-rc4-00004-ga81bbd8-dirty (robmur01 at e104324-lin) (gcc 
version 5.2.1 20151005 (Linaro GCC 5.2-2015.11-2) ) #16 SMP Wed Feb 24 
11:39:06 GMT 2016
CPU: ARMv7 Processor [411fc081] revision 1 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: ARM RealView PB-A8
bootconsole [earlycon0] enabled
Memory policy: Data cache writeback
CPU: All CPU(s) started in SVC mode.
PERCPU: Embedded 11 pages/cpu @c7ee4000 s13376 r8192 d23488 u45056
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: root=/dev/mmcblk0p1 rw rootwait console=ttyAMA0 
earlyprintk
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 124392K/131072K available (3863K kernel code, 128K rwdata, 1076K 
rodata, 212K init, 138K bss, 6680K reserved, 0K cma-reserved)
Virtual kernel memory layout:
     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
     DTCM    : 0xfffe8000 - 0xfffe8000   (   0 kB)
     ITCM    : 0xfffe0000 - 0xfffe0000   (   0 kB)
     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
     vmalloc : 0xc8800000 - 0xff800000   ( 880 MB)
     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
     modules : 0xbf000000 - 0xc0000000   (  16 MB)
       .text : 0xc0008000 - 0xc04dafec   (4940 kB)
       .init : 0xc04db000 - 0xc0510000   ( 212 kB)
       .data : 0xc0510000 - 0xc05303a0   ( 129 kB)
        .bss : 0xc0531000 - 0xc05538e0   ( 139 kB)
Hierarchical RCU implementation.
	Build-time adjustment of leaf fanout to 32.
	RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.
RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=1
NR_IRQS:16 nr_irqs:16 16
L2C: failed to init: -19
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at drivers/clk/versatile/clk-sp810.c:137 
clk_sp810_of_setup+0x124/0x168()
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc4-00004-ga81bbd8-dirty #16
Hardware name: ARM RealView Machine (Device Tree Support)
Backtrace:
[<c0013a98>] (dump_backtrace) from [<c0013c8c>] (show_stack+0x18/0x1c)
  r6:600000d3 r5:00000000 r4:c051f800
[<c0013c74>] (show_stack) from [<c01b26b0>] (dump_stack+0x94/0xb0)
[<c01b261c>] (dump_stack) from [<c0025884>] (warn_slowpath_common+0x7c/0xb8)
  r6:00000009 r5:00000089 r4:00000000
[<c0025808>] (warn_slowpath_common) from [<c0025964>] 
(warn_slowpath_null+0x24/0x28)
  r8:c7ef7570 r7:00000001 r6:c7ef7394 r5:c7807980 r4:c780798c
[<c0025940>] (warn_slowpath_null) from [<c04f4f34>] 
(clk_sp810_of_setup+0x124/0x168)
[<c04f4e10>] (clk_sp810_of_setup) from [<c04f4714>] 
(of_clk_init+0x13c/0x1e0)
  r10:00000003 r9:00000001 r8:00000000 r7:00000001 r6:c0511f6c r5:c78054c0
  r4:c0511f74
[<c04f45d8>] (of_clk_init) from [<c04ddac0>] (time_init+0x2c/0x38)
  r10:c05008c0 r9:c7ffc840 r8:c0531000 r7:c05127c0 r6:c0531000 r5:ffffffff
  r4:00000000
[<c04dda94>] (time_init) from [<c04dbbc4>] (start_kernel+0x248/0x364)
[<c04db97c>] (start_kernel) from [<0000807c>] (0x807c)
  r10:00000000 r9:411fc081 r8:00004059 r7:c0516910 r6:c05008bc r5:c051286c
  r4:c0531294
---[ end trace cb88537fdc8fa200 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at drivers/clk/versatile/clk-sp810.c:137 
clk_sp810_of_setup+0x124/0x168()
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W 
4.5.0-rc4-00004-ga81bbd8-dirty #16
Hardware name: ARM RealView Machine (Device Tree Support)
Backtrace:
[<c0013a98>] (dump_backtrace) from [<c0013c8c>] (show_stack+0x18/0x1c)
  r6:600000d3 r5:00000000 r4:c051f800
[<c0013c74>] (show_stack) from [<c01b26b0>] (dump_stack+0x94/0xb0)
[<c01b261c>] (dump_stack) from [<c0025884>] (warn_slowpath_common+0x7c/0xb8)
  r6:00000009 r5:00000089 r4:00000000
[<c0025808>] (warn_slowpath_common) from [<c0025964>] 
(warn_slowpath_null+0x24/0x28)
  r8:c7ef7570 r7:00000002 r6:c7ef7394 r5:c7807980 r4:c78079a4
[<c0025940>] (warn_slowpath_null) from [<c04f4f34>] 
(clk_sp810_of_setup+0x124/0x168)
[<c04f4e10>] (clk_sp810_of_setup) from [<c04f4714>] 
(of_clk_init+0x13c/0x1e0)
  r10:00000003 r9:00000001 r8:00000000 r7:00000001 r6:c0511f6c r5:c78054c0
  r4:c0511f74
[<c04f45d8>] (of_clk_init) from [<c04ddac0>] (time_init+0x2c/0x38)
  r10:c05008c0 r9:c7ffc840 r8:c0531000 r7:c05127c0 r6:c0531000 r5:ffffffff
  r4:00000000
[<c04dda94>] (time_init) from [<c04dbbc4>] (start_kernel+0x248/0x364)
[<c04db97c>] (start_kernel) from [<0000807c>] (0x807c)
  r10:00000000 r9:411fc081 r8:00004059 r7:c0516910 r6:c05008bc r5:c051286c
  r4:c0531294
---[ end trace cb88537fdc8fa201 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at drivers/clk/versatile/clk-sp810.c:137 
clk_sp810_of_setup+0x124/0x168()
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W 
4.5.0-rc4-00004-ga81bbd8-dirty #16
Hardware name: ARM RealView Machine (Device Tree Support)
Backtrace:
[<c0013a98>] (dump_backtrace) from [<c0013c8c>] (show_stack+0x18/0x1c)
  r6:600000d3 r5:00000000 r4:c051f800
[<c0013c74>] (show_stack) from [<c01b26b0>] (dump_stack+0x94/0xb0)
[<c01b261c>] (dump_stack) from [<c0025884>] (warn_slowpath_common+0x7c/0xb8)
  r6:00000009 r5:00000089 r4:00000000
[<c0025808>] (warn_slowpath_common) from [<c0025964>] 
(warn_slowpath_null+0x24/0x28)
  r8:c7ef7570 r7:00000003 r6:c7ef7394 r5:c7807980 r4:c78079bc
[<c0025940>] (warn_slowpath_null) from [<c04f4f34>] 
(clk_sp810_of_setup+0x124/0x168)
[<c04f4e10>] (clk_sp810_of_setup) from [<c04f4714>] 
(of_clk_init+0x13c/0x1e0)
  r10:00000003 r9:00000001 r8:00000000 r7:00000001 r6:c0511f6c r5:c78054c0
  r4:c0511f74
[<c04f45d8>] (of_clk_init) from [<c04ddac0>] (time_init+0x2c/0x38)
  r10:c05008c0 r9:c7ffc840 r8:c0531000 r7:c05127c0 r6:c0531000 r5:ffffffff
  r4:00000000
[<c04dda94>] (time_init) from [<c04dbbc4>] (start_kernel+0x248/0x364)
[<c04db97c>] (start_kernel) from [<0000807c>] (0x807c)
  r10:00000000 r9:411fc081 r8:00004059 r7:c0516910 r6:c05008bc r5:c051286c
  r4:c0531294
---[ end trace cb88537fdc8fa202 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at drivers/clk/versatile/clk-sp810.c:137 
clk_sp810_of_setup+0x124/0x168()
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W 
4.5.0-rc4-00004-ga81bbd8-dirty #16
Hardware name: ARM RealView Machine (Device Tree Support)
Backtrace:
[<c0013a98>] (dump_backtrace) from [<c0013c8c>] (show_stack+0x18/0x1c)
  r6:600000d3 r5:00000000 r4:c051f800
[<c0013c74>] (show_stack) from [<c01b26b0>] (dump_stack+0x94/0xb0)
[<c01b261c>] (dump_stack) from [<c0025884>] (warn_slowpath_common+0x7c/0xb8)
  r6:00000009 r5:00000089 r4:00000000
[<c0025808>] (warn_slowpath_common) from [<c0025964>] 
(warn_slowpath_null+0x24/0x28)
  r8:c7ef7570 r7:00000004 r6:c7ef7394 r5:c7807980 r4:c78079d4
[<c0025940>] (warn_slowpath_null) from [<c04f4f34>] 
(clk_sp810_of_setup+0x124/0x168)
[<c04f4e10>] (clk_sp810_of_setup) from [<c04f4714>] 
(of_clk_init+0x13c/0x1e0)
  r10:00000003 r9:00000001 r8:00000000 r7:00000001 r6:c0511f6c r5:c78054c0
  r4:c0511f74
[<c04f45d8>] (of_clk_init) from [<c04ddac0>] (time_init+0x2c/0x38)
  r10:c05008c0 r9:c7ffc840 r8:c0531000 r7:c05127c0 r6:c0531000 r5:ffffffff
  r4:00000000
[<c04dda94>] (time_init) from [<c04dbbc4>] (start_kernel+0x248/0x364)
[<c04db97c>] (start_kernel) from [<0000807c>] (0x807c)
  r10:00000000 r9:411fc081 r8:00004059 r7:c0516910 r6:c05008bc r5:c051286c
  r4:c0531294
---[ end trace cb88537fdc8fa203 ]---
clk: couldn't get parent clock 0 for /soc/sysctl at 1001a000
clk: couldn't get parent clock 0 for /soc/sysctl at 1001a000
clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, 
max_idle_ns: 1911260446275 ns
sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 
2147483647500ns
Console: colour dummy device 80x30
Calibrating delay loop... 743.83 BogoMIPS (lpj=3719168)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket -1, mpidr 0
Setting up static identity map for 0x82a0 - 0x8310
Brought up 1 CPUs
SMP: Total of 1 processors activated (743.83 BogoMIPS).
CPU: All CPU(s) started in SVC mode.
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, 
max_idle_ns: 19112604462750000 ns
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
hw-breakpoint: debug architecture 0x4 unsupported.
Serial: AMBA PL011 UART driver
10009000.serial: ttyAMA0 at MMIO 0x10009000 (irq = 20, base_baud = 0) is 
a PL011 rev2
console [ttyAMA0] enabled
console [ttyAMA0] enabled
bootconsole [earlycon0] disabled
bootconsole [earlycon0] disabled
1000a000.serial: ttyAMA1 at MMIO 0x1000a000 (irq = 21, base_baud = 0) is 
a PL011 rev2
1000b000.serial: ttyAMA2 at MMIO 0x1000b000 (irq = 22, base_baud = 0) is 
a PL011 rev2
1000c000.serial: ttyAMA3 at MMIO 0x1000c000 (irq = 36, base_baud = 0) is 
a PL011 rev2
ssp-pl022 1000d000.ssp: ARM PL022 driver, device ID: 0x00041022
ssp-pl022 1000d000.ssp: mapped registers from 0x1000d000 to c8884000
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
i2c i2c-0: Failed to register i2c client ds1338 at 0x68 (-16)
i2c i2c-0: Can't create device at 0x68
Advanced Linux Sound Architecture Driver Initialized.
clocksource: Switched to clocksource arm,sp804
NET: Registered protocol family 2
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
hw perfevents: enabled with armv7_cortex_a8 PMU driver, 5 counters available
futex hash table entries: 256 (order: 2, 16384 bytes)
io scheduler noop registered
io scheduler deadline registered (default)
pl061_gpio 10013000.gpio: PL061 GPIO chip @0x10013000 registered
pl061_gpio 10014000.gpio: PL061 GPIO chip @0x10014000 registered
pl061_gpio 10015000.gpio: PL061 GPIO chip @0x10015000 registered
clcd-pl11x 10020000.clcd: PL111 rev0 at 0x10020000
clcd-pl11x 10020000.clcd: /issp/clcd at 10020000 hardware, 640x480 at 59 display
Console: switching to colour frame buffer device 80x30
realview-soc soc: RealView Syscon Core ID: 0x2178f505, HBI-178
libphy: smsc911x-mdio: probed
SMSC LAN911x Internal PHY 4e000000.etherne:01: attached PHY driver [SMSC 
LAN911x Internal PHY] (mii_bus:phy_addr=4e000000.etherne:01, irq=-1)
smsc911x 4e000000.ethernet eth0: MAC Address: 00:02:f7:00:0a:c2
isp1760 4f000000.usb: bus width: 32, oc: digital
isp1760 4f000000.usb: NXP ISP1760 USB Host Controller
isp1760 4f000000.usb: new USB bus registered, assigned bus number 1
isp1760 4f000000.usb: irq 19, io mem 0x4f000000
isp1760 4f000000.usb: USB ISP 1761 HW rev. 1 started
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ISP1760 USB device initialised
mousedev: PS/2 mouse device common for all mice
rtc-ds1307 0-0068: rtc core: registered ds1338 as rtc0
rtc-ds1307 0-0068: 56 bytes nvram
rtc-pl031 10017000.rtc: rtc core: registered pl031 as rtc1
versatile reboot driver registered
mmci-pl18x 10005000.mmcsd: Got CD GPIO
mmci-pl18x 10005000.mmcsd: Got WP GPIO
mmci-pl18x 10005000.mmcsd: mmc0: PL180 manf 41 rev0 at 0x10005000 irq 
32,33 (pio)
ledtrig-cpu: registered to indicate activity on CPUs
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
aaci-pl041 10004000.aaci: ARM AC'97 Interface PL041 rev0 at 0x10004000, 
irq 31
aaci-pl041 10004000.aaci: FIFO 512 entries
NET: Registered protocol family 17
Registering SWP/SWPB emulation handler
isp1760 4f000000.usb: port 1 high speed
rtc-ds1307 0-0068: setting system clock to 2000-01-01 00:17:12 UTC 
(946685832)
ALSA device list:
   #0: ARM AC'97 Interface PL041 rev0 at 0x10004000, irq 31
usb 1-1: new high-speed USB device number 2 using isp1760
isp1760 4f000000.usb: port 1 high speed
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 3 ports detected
atkbd serio0: keyboard reset failed on 10006000.kmi
atkbd serio1: keyboard reset failed on 10007000.kmi
atkbd serio0: keyboard reset failed on 10006000.kmi
atkbd serio1: keyboard reset failed on 10007000.kmi
Waiting for root device /dev/mmcblk0p1...


It then fails to notice my SD card, even if I eject and reinsert it :(

Robin.


From christoffer.dall at linaro.org  Wed Feb 24 04:27:18 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Wed, 24 Feb 2016 13:27:18 +0100
Subject: [PATCH v13 15/20] KVM: ARM64: Add PMU overflow interrupt routing
In-Reply-To: <1456290520-10012-16-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
 <1456290520-10012-16-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <20160224122718.GD18451@cbox>

On Wed, Feb 24, 2016 at 01:08:35PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
> 
> When calling perf_event_create_kernel_counter to create perf_event,
> assign a overflow handler. Then when the perf event overflows, set the
> corresponding bit of guest PMOVSSET register. If this counter is enabled
> and its interrupt is enabled as well, kick the vcpu to sync the
> interrupt.
> 
> On VM entry, if there is counter overflowed, inject the interrupt with
> the level set to 1. Otherwise, inject the interrupt with the level set
> to 0.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
> Reviewed-by: Andrew Jones <drjones at redhat.com>
> ---
>  arch/arm/kvm/arm.c    |  2 ++
>  include/kvm/arm_pmu.h |  3 +++
>  virt/kvm/arm/pmu.c    | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++-
>  3 files changed, 55 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index dda1959..f54264c 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -28,6 +28,7 @@
>  #include <linux/sched.h>
>  #include <linux/kvm.h>
>  #include <trace/events/kvm.h>
> +#include <kvm/arm_pmu.h>
>  
>  #define CREATE_TRACE_POINTS
>  #include "trace.h"
> @@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  		 * non-preemptible context.
>  		 */
>  		preempt_disable();
> +		kvm_pmu_flush_hwstate(vcpu);
>  		kvm_timer_flush_hwstate(vcpu);
>  		kvm_vgic_flush_hwstate(vcpu);
>  
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 8bc92d1..0aed4d4 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -35,6 +35,7 @@ struct kvm_pmu {
>  	int irq_num;
>  	struct kvm_pmc pmc[ARMV8_PMU_MAX_COUNTERS];
>  	bool ready;
> +	bool irq_level;
>  };
>  
>  #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
> @@ -44,6 +45,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
>  void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
>  void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> @@ -67,6 +69,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
>  static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
> +static inline void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
>  static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index cda869c..1cd4214 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -21,6 +21,7 @@
>  #include <linux/perf_event.h>
>  #include <asm/kvm_emulate.h>
>  #include <kvm/arm_pmu.h>
> +#include <kvm/arm_vgic.h>
>  
>  /**
>   * kvm_pmu_get_counter_value - get PMU counter value
> @@ -181,6 +182,53 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
>  }
>  
>  /**
> + * kvm_pmu_flush_hwstate - flush pmu state to cpu
> + * @vcpu: The vcpu pointer
> + *
> + * Inject virtual PMU IRQ if IRQ is pending for this cpu.
> + */
> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
> +{
> +	struct kvm_pmu *pmu = &vcpu->arch.pmu;
> +	bool overflow;
> +
> +	if (!kvm_arm_pmu_v3_ready(vcpu))
> +		return;
> +
> +	overflow = !!kvm_pmu_overflow_status(vcpu);
> +	if (pmu->irq_level != overflow) {
> +		pmu->irq_level = overflow;
> +		kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
> +				    pmu->irq_num, overflow);
> +	}

a consequence of only doing this on flush and not checking if the input
to the vgic should be adjusted on sync is that if you exit the guest
because the guest does a 'wfi', for example, and you entered with the
overflow interrupt set, then kvm_arch_vcpu_runnable() will return true,
and the VCPU will not block but will run anyway.

Maybe not a big deal, but I think we might as well check the overflow
status on sync (coming back from the VM) and reset the line at that time
so that we have a 'more up to date' view of the interrupt line after
exiting a vcpu.

Thanks,
-Christoffer

> +}
> +
> +static inline struct kvm_vcpu *kvm_pmc_to_vcpu(struct kvm_pmc *pmc)
> +{
> +	struct kvm_pmu *pmu;
> +	struct kvm_vcpu_arch *vcpu_arch;
> +
> +	pmc -= pmc->idx;
> +	pmu = container_of(pmc, struct kvm_pmu, pmc[0]);
> +	vcpu_arch = container_of(pmu, struct kvm_vcpu_arch, pmu);
> +	return container_of(vcpu_arch, struct kvm_vcpu, arch);
> +}
> +
> +/**
> + * When perf event overflows, call kvm_pmu_overflow_set to set overflow status.
> + */
> +static void kvm_pmu_perf_overflow(struct perf_event *perf_event,
> +				  struct perf_sample_data *data,
> +				  struct pt_regs *regs)
> +{
> +	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
> +	struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
> +	int idx = pmc->idx;
> +
> +	kvm_pmu_overflow_set(vcpu, BIT(idx));
> +}
> +
> +/**
>   * kvm_pmu_software_increment - do software increment
>   * @vcpu: The vcpu pointer
>   * @val: the value guest writes to PMSWINC register
> @@ -291,7 +339,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>  	/* The initial sample period (overflow count) of an event. */
>  	attr.sample_period = (-counter) & pmc->bitmask;
>  
> -	event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
> +	event = perf_event_create_kernel_counter(&attr, -1, current,
> +						 kvm_pmu_perf_overflow, pmc);
>  	if (IS_ERR(event)) {
>  		pr_err_once("kvm: pmu event creation failed %ld\n",
>  			    PTR_ERR(event));
> -- 
> 2.0.4
> 
> 


From tixy at linaro.org  Wed Feb 24 05:14:34 2016
From: tixy at linaro.org (Jon Medhurst (Tixy))
Date: Wed, 24 Feb 2016 13:14:34 +0000
Subject: [PATCH] dmaengine: pl330: Fix some race conditions in residue
 calculation
Message-ID: <1456319674.2867.15.camel@linaro.org>

The residue calculation in pl330_tx_status doesn't handle transitional
states that occur at the time one descriptor (A) is completed and the
next (B) is started. Specifically, both A and B can simultaneously be in
the BUSY state and at this time the thread's 'req_running' may (or may
not) be -1.

To cope with this situation we change the code to ensure A is treated as
complete and B as having not yet started. Prior to the change, the code
would calculate a transferred byte count as if both A and B had
completed.

Fixes: aee4d1fac887 ("dmaengine: pl330: improve pl330_tx_status() function")

Signed-off-by: Jon Medhurst <tixy at linaro.org>
---

I discovered this issue when trying to work out why audio stopped
working on ARM's Juno platform and bisected it to commit aee4d1fac887.
Whilst this patch seems to fix the problems I was seeing, I can't help
but think there are more race conditions with this code. E.g. if the
running descriptor changes under us, pl330_get_current_xferred_count
can end up reading values from hardware that relate to a different
descriptor. And if we're really unlucky, the reading of the 'val' and
'addr' values in pl330_get_current_xferred_count can come from different
descriptors. I don't know if there is any locks we can use to prevent
such races or if we need to try and detect when things have changed and
redo/abort the residue calculation...

 drivers/dma/pl330.c | 24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 17ee758..55e3c5f 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2240,6 +2240,7 @@ pl330_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
 	struct dma_pl330_desc *desc, *running = NULL;
 	struct dma_pl330_chan *pch = to_pchan(chan);
 	unsigned int transferred, residual = 0;
+	bool first_busy;
 
 	ret = dma_cookie_status(chan, cookie, txstate);
 
@@ -2253,16 +2254,31 @@ pl330_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
 
 	if (pch->thread->req_running != -1)
 		running = pch->thread->req[pch->thread->req_running].desc;
+	first_busy = true;
 
 	/* Check in pending list */
 	list_for_each_entry(desc, &pch->work_list, node) {
 		if (desc->status == DONE)
 			transferred = desc->bytes_requested;
-		else if (running && desc == running)
-			transferred =
-				pl330_get_current_xferred_count(pch, desc);
-		else
+		else if (desc->status == BUSY && first_busy) {
+			first_busy = false;
+			if (running && desc == running) {
+				transferred =
+					pl330_get_current_xferred_count(pch, desc);
+			} else {
+				/* BUSY but not running means it's just completed */
+				transferred = desc->bytes_requested;
+			}
+		} else {
+			/*
+			 * Descriptor is either in PREP state queued for future
+			 * transfer or it is the second BUSY descriptor we have
+			 * seen. The latter case means it has just, or is about
+			 * to be, started, so treat it as having not yet
+			 * transferred any bytes, the same as PREP.
+			 */
 			transferred = 0;
+		}
 		residual += desc->bytes_requested - transferred;
 		if (desc->txd.cookie == cookie) {
 			switch (desc->status) {
-- 
2.1.4




From marc.zyngier at arm.com  Wed Feb 24 05:19:57 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Feb 2016 13:19:57 +0000
Subject: [PATCH v13 15/20] KVM: ARM64: Add PMU overflow interrupt routing
In-Reply-To: <20160224122718.GD18451@cbox>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
 <1456290520-10012-16-git-send-email-zhaoshenglong@huawei.com>
 <20160224122718.GD18451@cbox>
Message-ID: <56CDADFD.10805@arm.com>

On 24/02/16 12:27, Christoffer Dall wrote:
> On Wed, Feb 24, 2016 at 01:08:35PM +0800, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao at linaro.org>
>>
>> When calling perf_event_create_kernel_counter to create perf_event,
>> assign a overflow handler. Then when the perf event overflows, set the
>> corresponding bit of guest PMOVSSET register. If this counter is enabled
>> and its interrupt is enabled as well, kick the vcpu to sync the
>> interrupt.
>>
>> On VM entry, if there is counter overflowed, inject the interrupt with
>> the level set to 1. Otherwise, inject the interrupt with the level set
>> to 0.
>>
>> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
>> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
>> Reviewed-by: Andrew Jones <drjones at redhat.com>
>> ---
>>  arch/arm/kvm/arm.c    |  2 ++
>>  include/kvm/arm_pmu.h |  3 +++
>>  virt/kvm/arm/pmu.c    | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++-
>>  3 files changed, 55 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index dda1959..f54264c 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -28,6 +28,7 @@
>>  #include <linux/sched.h>
>>  #include <linux/kvm.h>
>>  #include <trace/events/kvm.h>
>> +#include <kvm/arm_pmu.h>
>>  
>>  #define CREATE_TRACE_POINTS
>>  #include "trace.h"
>> @@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>  		 * non-preemptible context.
>>  		 */
>>  		preempt_disable();
>> +		kvm_pmu_flush_hwstate(vcpu);
>>  		kvm_timer_flush_hwstate(vcpu);
>>  		kvm_vgic_flush_hwstate(vcpu);
>>  
>> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
>> index 8bc92d1..0aed4d4 100644
>> --- a/include/kvm/arm_pmu.h
>> +++ b/include/kvm/arm_pmu.h
>> @@ -35,6 +35,7 @@ struct kvm_pmu {
>>  	int irq_num;
>>  	struct kvm_pmc pmc[ARMV8_PMU_MAX_COUNTERS];
>>  	bool ready;
>> +	bool irq_level;
>>  };
>>  
>>  #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
>> @@ -44,6 +45,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
>>  void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
>>  void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
>>  void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
>> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
>>  void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
>>  void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
>>  void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>> @@ -67,6 +69,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
>>  static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>>  static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>>  static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
>> +static inline void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
>>  static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
>>  static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
>>  static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
>> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
>> index cda869c..1cd4214 100644
>> --- a/virt/kvm/arm/pmu.c
>> +++ b/virt/kvm/arm/pmu.c
>> @@ -21,6 +21,7 @@
>>  #include <linux/perf_event.h>
>>  #include <asm/kvm_emulate.h>
>>  #include <kvm/arm_pmu.h>
>> +#include <kvm/arm_vgic.h>
>>  
>>  /**
>>   * kvm_pmu_get_counter_value - get PMU counter value
>> @@ -181,6 +182,53 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
>>  }
>>  
>>  /**
>> + * kvm_pmu_flush_hwstate - flush pmu state to cpu
>> + * @vcpu: The vcpu pointer
>> + *
>> + * Inject virtual PMU IRQ if IRQ is pending for this cpu.
>> + */
>> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
>> +{
>> +	struct kvm_pmu *pmu = &vcpu->arch.pmu;
>> +	bool overflow;
>> +
>> +	if (!kvm_arm_pmu_v3_ready(vcpu))
>> +		return;
>> +
>> +	overflow = !!kvm_pmu_overflow_status(vcpu);
>> +	if (pmu->irq_level != overflow) {
>> +		pmu->irq_level = overflow;
>> +		kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
>> +				    pmu->irq_num, overflow);
>> +	}
> 
> a consequence of only doing this on flush and not checking if the input
> to the vgic should be adjusted on sync is that if you exit the guest
> because the guest does a 'wfi', for example, and you entered with the
> overflow interrupt set, then kvm_arch_vcpu_runnable() will return true,
> and the VCPU will not block but will run anyway.
> 
> Maybe not a big deal, but I think we might as well check the overflow
> status on sync (coming back from the VM) and reset the line at that time
> so that we have a 'more up to date' view of the interrupt line after
> exiting a vcpu.

That's a very good point. I can definitely imagine pathological
behaviours if the guest otherwise relies on the overflow interrupt
triggering.

Shannon, can you please address this?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From hdegoede at redhat.com  Wed Feb 24 05:22:05 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Wed, 24 Feb 2016 14:22:05 +0100
Subject: [PATCH v3 1/2] ehci-platform: Add support for controllers with
 multiple reset lines
In-Reply-To: <56CD960D.3000900@ti.com>
References: <1456312517-24211-1-git-send-email-hdegoede@redhat.com>
 <1456312517-24211-2-git-send-email-hdegoede@redhat.com>
 <56CD960D.3000900@ti.com>
Message-ID: <56CDAE7D.6000204@redhat.com>

Hi,

On 24-02-16 12:37, Roger Quadros wrote:
> Hi,
>
> On 24/02/16 13:15, Hans de Goede wrote:
>> From: Reinder de Haan <patchesrdh at mveas.com>
>>
>> At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
>> reset lines, the controller will not initialize while the reset for
>> its companion is still asserted, which means we need to de-assert
>> 2 resets for the controller to work.
>>
>> Signed-off-by: Reinder de Haan <patchesrdh at mveas.com>
>> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>> ---
>> Changes in v2:
>> -Use the new reset_control_[de]assert_shared reset-controller functions
>> Changes in v3:
>> -Adjust for changes to shared-reset reset-controller functions
>> ---
>>   Documentation/devicetree/bindings/usb/usb-ehci.txt |  2 +-
>>   drivers/usb/host/ehci-platform.c                   | 41 ++++++++++++----------
>>   2 files changed, 24 insertions(+), 19 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt
>> index a12d601..0701812 100644
>> --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
>> +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
>> @@ -18,7 +18,7 @@ Optional properties:
>>    - clocks : a list of phandle + clock specifier pairs
>>    - phys : phandle + phy specifier pair
>>    - phy-names : "usb"
>> - - resets : phandle + reset specifier pair
>> + - resets : a list of phandle + reset specifier pairs
>>
>>   Example (Sequoia 440EPx):
>>       ehci at e0000300 {
>> diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
>> index bd7082f2..3f195ba 100644
>> --- a/drivers/usb/host/ehci-platform.c
>> +++ b/drivers/usb/host/ehci-platform.c
>> @@ -39,11 +39,12 @@
>>
>>   #define DRIVER_DESC "EHCI generic platform driver"
>>   #define EHCI_MAX_CLKS 3
>> +#define EHCI_MAX_RESETS 2
>>   #define hcd_to_ehci_priv(h) ((struct ehci_platform_priv *)hcd_to_ehci(h)->priv)
>>
>>   struct ehci_platform_priv {
>>   	struct clk *clks[EHCI_MAX_CLKS];
>> -	struct reset_control *rst;
>> +	struct reset_control *resets[EHCI_MAX_RESETS];
>>   	struct phy **phys;
>>   	int num_phys;
>>   	bool reset_on_resume;
>> @@ -149,7 +150,7 @@ static int ehci_platform_probe(struct platform_device *dev)
>>   	struct usb_ehci_pdata *pdata = dev_get_platdata(&dev->dev);
>>   	struct ehci_platform_priv *priv;
>>   	struct ehci_hcd *ehci;
>> -	int err, irq, phy_num, clk = 0;
>> +	int err, irq, phy_num, clk = 0, rst = 0;
>>
>>   	if (usb_disabled())
>>   		return -ENODEV;
>> @@ -232,18 +233,22 @@ static int ehci_platform_probe(struct platform_device *dev)
>>   				break;
>>   			}
>>   		}
>> -	}
>>
>> -	priv->rst = devm_reset_control_get_optional(&dev->dev, NULL);
>> -	if (IS_ERR(priv->rst)) {
>> -		err = PTR_ERR(priv->rst);
>> -		if (err == -EPROBE_DEFER)
>> -			goto err_put_clks;
>> -		priv->rst = NULL;
>> -	} else {
>> -		err = reset_control_deassert(priv->rst);
>> -		if (err)
>> -			goto err_put_clks;
>> +		for (rst = 0; rst < EHCI_MAX_RESETS; rst++) {
>> +			priv->resets[rst] =
>> +				devm_reset_control_get_shared_by_index(
>> +								&dev->dev, rst);
>> +			if (IS_ERR(priv->resets[rst])) {
>> +				err = PTR_ERR(priv->resets[rst]);
>> +				if (err == -EPROBE_DEFER)
>> +					goto err_reset;
>> +				priv->resets[rst] = NULL;
>> +				break;
>> +			}
>> +			err = reset_control_deassert(priv->resets[rst]);
>> +			if (err)
>> +				goto err_reset;
>> +		}
>
> Why is this code within "if (dev->of.node)" ?
> Previous code looked like it worked for non-DT boots as well.

Because devm_reset_control_get_shared_by_index() only works for DT platforms
(it is safe to call on non DT platforms, it will just always return -EINVAL
there) and the old reset paths were ever only used / only ever worked with
DT too.

Regards,

Hans


From hdegoede at redhat.com  Wed Feb 24 05:26:37 2016
From: hdegoede at redhat.com (Hans de Goede)
Date: Wed, 24 Feb 2016 14:26:37 +0100
Subject: [linux-sunxi] [PATCH 2/2] ARM: dts: sun8i: Enable ir receiver on
 orangepi pc
In-Reply-To: <20160224121640.GA25658@box2.japko.eu>
References: <1456268597-13692-1-git-send-email-hdegoede@redhat.com>
 <1456268597-13692-3-git-send-email-hdegoede@redhat.com>
 <20160224121640.GA25658@box2.japko.eu>
Message-ID: <56CDAF8D.70501@redhat.com>

Hi,

On 24-02-16 13:16, Krzysztof Adamski wrote:
> On Wed, Feb 24, 2016 at 12:03:17AM +0100, Hans de Goede wrote:
>> Enable the ir receiver found on the orangepi pc board.
>>
>> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
>> ---
>> arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts
>
> I don't think this file is avaiable in mainline. Wouldn't it be better to use patch against existing orangepi-plus dts file?
>
> Otherwise I tested this patch and it works fine on my Orangepi PC (some data is splitted out when reading /dev/input/event0).

Ah yes, that is my bad, I've been waiting with upstreaming an orangepi-pc dts until all the
usb bits are upstream as my dts has usb host support enabled, I should probably split
out the usb-host support and upstream the rest already.

Regards,

Hans


From shannon.zhao at linaro.org  Wed Feb 24 05:26:18 2016
From: shannon.zhao at linaro.org (Shannon Zhao)
Date: Wed, 24 Feb 2016 21:26:18 +0800
Subject: [PATCH v13 15/20] KVM: ARM64: Add PMU overflow interrupt routing
In-Reply-To: <56CDADFD.10805@arm.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
 <1456290520-10012-16-git-send-email-zhaoshenglong@huawei.com>
 <20160224122718.GD18451@cbox> <56CDADFD.10805@arm.com>
Message-ID: <56CDAF7A.3080505@linaro.org>



On 2016/2/24 21:19, Marc Zyngier wrote:
> On 24/02/16 12:27, Christoffer Dall wrote:
>> >On Wed, Feb 24, 2016 at 01:08:35PM +0800, Shannon Zhao wrote:
>>> >>From: Shannon Zhao<shannon.zhao at linaro.org>
>>> >>
>>> >>When calling perf_event_create_kernel_counter to create perf_event,
>>> >>assign a overflow handler. Then when the perf event overflows, set the
>>> >>corresponding bit of guest PMOVSSET register. If this counter is enabled
>>> >>and its interrupt is enabled as well, kick the vcpu to sync the
>>> >>interrupt.
>>> >>
>>> >>On VM entry, if there is counter overflowed, inject the interrupt with
>>> >>the level set to 1. Otherwise, inject the interrupt with the level set
>>> >>to 0.
>>> >>
>>> >>Signed-off-by: Shannon Zhao<shannon.zhao at linaro.org>
>>> >>Reviewed-by: Marc Zyngier<marc.zyngier at arm.com>
>>> >>Reviewed-by: Andrew Jones<drjones at redhat.com>
>>> >>---
>>> >>  arch/arm/kvm/arm.c    |  2 ++
>>> >>  include/kvm/arm_pmu.h |  3 +++
>>> >>  virt/kvm/arm/pmu.c    | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++-
>>> >>  3 files changed, 55 insertions(+), 1 deletion(-)
>>> >>
>>> >>diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>> >>index dda1959..f54264c 100644
>>> >>--- a/arch/arm/kvm/arm.c
>>> >>+++ b/arch/arm/kvm/arm.c
>>> >>@@ -28,6 +28,7 @@
>>> >>  #include <linux/sched.h>
>>> >>  #include <linux/kvm.h>
>>> >>  #include <trace/events/kvm.h>
>>> >>+#include <kvm/arm_pmu.h>
>>> >>
>>> >>  #define CREATE_TRACE_POINTS
>>> >>  #include "trace.h"
>>> >>@@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>> >>  		 * non-preemptible context.
>>> >>  		 */
>>> >>  		preempt_disable();
>>> >>+		kvm_pmu_flush_hwstate(vcpu);
>>> >>  		kvm_timer_flush_hwstate(vcpu);
>>> >>  		kvm_vgic_flush_hwstate(vcpu);
>>> >>
>>> >>diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
>>> >>index 8bc92d1..0aed4d4 100644
>>> >>--- a/include/kvm/arm_pmu.h
>>> >>+++ b/include/kvm/arm_pmu.h
>>> >>@@ -35,6 +35,7 @@ struct kvm_pmu {
>>> >>  	int irq_num;
>>> >>  	struct kvm_pmc pmc[ARMV8_PMU_MAX_COUNTERS];
>>> >>  	bool ready;
>>> >>+	bool irq_level;
>>> >>  };
>>> >>
>>> >>  #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
>>> >>@@ -44,6 +45,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
>>> >>  void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
>>> >>  void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
>>> >>  void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
>>> >>+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
>>> >>  void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
>>> >>  void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
>>> >>  void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>>> >>@@ -67,6 +69,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
>>> >>  static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>>> >>  static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>>> >>  static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
>>> >>+static inline void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
>>> >>  static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
>>> >>  static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
>>> >>  static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
>>> >>diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
>>> >>index cda869c..1cd4214 100644
>>> >>--- a/virt/kvm/arm/pmu.c
>>> >>+++ b/virt/kvm/arm/pmu.c
>>> >>@@ -21,6 +21,7 @@
>>> >>  #include <linux/perf_event.h>
>>> >>  #include <asm/kvm_emulate.h>
>>> >>  #include <kvm/arm_pmu.h>
>>> >>+#include <kvm/arm_vgic.h>
>>> >>
>>> >>  /**
>>> >>   * kvm_pmu_get_counter_value - get PMU counter value
>>> >>@@ -181,6 +182,53 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
>>> >>  }
>>> >>
>>> >>  /**
>>> >>+ * kvm_pmu_flush_hwstate - flush pmu state to cpu
>>> >>+ * @vcpu: The vcpu pointer
>>> >>+ *
>>> >>+ * Inject virtual PMU IRQ if IRQ is pending for this cpu.
>>> >>+ */
>>> >>+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
>>> >>+{
>>> >>+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
>>> >>+	bool overflow;
>>> >>+
>>> >>+	if (!kvm_arm_pmu_v3_ready(vcpu))
>>> >>+		return;
>>> >>+
>>> >>+	overflow = !!kvm_pmu_overflow_status(vcpu);
>>> >>+	if (pmu->irq_level != overflow) {
>>> >>+		pmu->irq_level = overflow;
>>> >>+		kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
>>> >>+				    pmu->irq_num, overflow);
>>> >>+	}
>> >
>> >a consequence of only doing this on flush and not checking if the input
>> >to the vgic should be adjusted on sync is that if you exit the guest
>> >because the guest does a 'wfi', for example, and you entered with the
>> >overflow interrupt set, then kvm_arch_vcpu_runnable() will return true,
>> >and the VCPU will not block but will run anyway.
>> >
>> >Maybe not a big deal, but I think we might as well check the overflow
>> >status on sync (coming back from the VM) and reset the line at that time
>> >so that we have a 'more up to date' view of the interrupt line after
>> >exiting a vcpu.
> That's a very good point. I can definitely imagine pathological
> behaviours if the guest otherwise relies on the overflow interrupt
> triggering.
>
> Shannon, can you please address this?

Sure. So on sync we only update the irq level if the overflow status is 
changed like what we do on flush, right?

BTW, to reduce email traffic, I want to only update this patch, is this 
fine?

Thanks,
-- 
Shannon


From heiko at sntech.de  Wed Feb 24 05:27:43 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Wed, 24 Feb 2016 14:27:43 +0100
Subject: [PATCH 3/4] clk: rockchip: add dt-binding header for rk3399
In-Reply-To: <1456210864-29037-4-git-send-email-jay.xu@rock-chips.com>
References: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
 <1456210864-29037-4-git-send-email-jay.xu@rock-chips.com>
Message-ID: <4483822.0pRK7cKepF@phil>

Hi Jianqun,

Am Dienstag, 23. Februar 2016, 15:01:03 schrieb jianqun.xu:
> From: Xing Zheng <zhengxing at rock-chips.com>
> 
> Add the dt-bindings header for the rk3399, that gets shared between
> the clock controller and the clock references in the dts.
> 
> Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
> Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>

looks ok so far, do you have an estimate when the revised clk driver will be 
sent? Before committing to support this binding header forever I'd like to 
take a look over the clock-tree itself, just to be sure ;-)


Thanks
Heiko


From ldewangan at nvidia.com  Wed Feb 24 05:15:25 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:25 +0530
Subject: [PATCH 00/50] pinctrl: Add and use devm_ apis for pinctrl_{register,
 unregister}
Message-ID: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>

Add resource manageemnt APIs fro pinctrl_register() and pinctrl_unregister()
and use these new APIs on hw driver to reduce the error path code and
remove callback for driver.

Laxman Dewangan (50):
  pinctrl: Add devm_ apis for pinctrl_{register, unregister}
  pinctrl: Add resource management devm_pinctrl_{register, unregister}
  pinctrl: bcm281xx: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: bcm2835: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: cygnus-mux: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: iproc-gpio: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: nsp-gpio: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: berlin: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: imx: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: imxl: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: cherryview: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: intel: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: mtk-common: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: meson: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: mvebu: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: nomadic: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: spmi-gpio: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: spmi: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: ssbi-gpi: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: ssbi-mpp: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: msm: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: pxa: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: exynos5440: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: samsung: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: ish-pfc: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: spear: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: stm32: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: ssbi-mpp: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: tegra: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: tegra-xusb: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: uniphier: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: vt8500: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: adi2: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: amd: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: as3722: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: at91-pio4: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: at91: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: digicolor: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: lantiq: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: lpc18xx: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: palmas: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: pic32: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: pistachio: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: rockchip: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: st: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: tb10x: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: tz1090-pdc: Use devm_pinctrl_register() for pinctrl
    registration
  pinctrl: tz1090 Use devm_pinctrl_register() for pinctrl registration
  pinctrl: u300: Use devm_pinctrl_register() for pinctrl registration
  pinctrl: zynq: Use devm_pinctrl_register() for pinctrl registration

 Documentation/driver-model/devres.txt            |  2 +
 drivers/pinctrl/bcm/pinctrl-bcm281xx.c           |  4 +-
 drivers/pinctrl/bcm/pinctrl-bcm2835.c            |  3 +-
 drivers/pinctrl/bcm/pinctrl-cygnus-mux.c         |  2 +-
 drivers/pinctrl/bcm/pinctrl-iproc-gpio.c         | 12 +----
 drivers/pinctrl/bcm/pinctrl-nsp-gpio.c           |  2 +-
 drivers/pinctrl/berlin/berlin.c                  |  3 +-
 drivers/pinctrl/core.c                           | 69 ++++++++++++++++++++++++
 drivers/pinctrl/freescale/pinctrl-imx.c          | 11 +---
 drivers/pinctrl/freescale/pinctrl-imx.h          |  1 -
 drivers/pinctrl/freescale/pinctrl-imx1-core.c    | 11 +---
 drivers/pinctrl/freescale/pinctrl-imx1.c         |  1 -
 drivers/pinctrl/freescale/pinctrl-imx1.h         |  1 -
 drivers/pinctrl/freescale/pinctrl-imx21.c        |  1 -
 drivers/pinctrl/freescale/pinctrl-imx25.c        |  1 -
 drivers/pinctrl/freescale/pinctrl-imx27.c        |  1 -
 drivers/pinctrl/freescale/pinctrl-imx35.c        |  1 -
 drivers/pinctrl/freescale/pinctrl-imx50.c        |  1 -
 drivers/pinctrl/freescale/pinctrl-imx51.c        |  1 -
 drivers/pinctrl/freescale/pinctrl-imx53.c        |  1 -
 drivers/pinctrl/freescale/pinctrl-imx6dl.c       |  1 -
 drivers/pinctrl/freescale/pinctrl-imx6q.c        |  1 -
 drivers/pinctrl/freescale/pinctrl-imx6sl.c       |  1 -
 drivers/pinctrl/freescale/pinctrl-imx6sx.c       |  1 -
 drivers/pinctrl/freescale/pinctrl-imx6ul.c       |  1 -
 drivers/pinctrl/freescale/pinctrl-imx7d.c        |  1 -
 drivers/pinctrl/freescale/pinctrl-vf610.c        |  1 -
 drivers/pinctrl/intel/pinctrl-cherryview.c       |  4 +-
 drivers/pinctrl/intel/pinctrl-intel.c            |  4 +-
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c    | 17 +++---
 drivers/pinctrl/meson/pinctrl-meson.c            |  2 +-
 drivers/pinctrl/mvebu/pinctrl-armada-370.c       |  6 ---
 drivers/pinctrl/mvebu/pinctrl-armada-375.c       |  6 ---
 drivers/pinctrl/mvebu/pinctrl-armada-38x.c       |  6 ---
 drivers/pinctrl/mvebu/pinctrl-armada-39x.c       |  6 ---
 drivers/pinctrl/mvebu/pinctrl-armada-xp.c        |  6 ---
 drivers/pinctrl/mvebu/pinctrl-dove.c             |  5 +-
 drivers/pinctrl/mvebu/pinctrl-kirkwood.c         |  6 ---
 drivers/pinctrl/mvebu/pinctrl-mvebu.c            |  9 +---
 drivers/pinctrl/nomadik/pinctrl-abx500.c         |  3 +-
 drivers/pinctrl/nomadik/pinctrl-nomadik.c        |  2 +-
 drivers/pinctrl/pinctrl-adi2.c                   | 13 +----
 drivers/pinctrl/pinctrl-amd.c                    |  9 ++--
 drivers/pinctrl/pinctrl-as3722.c                 |  9 ++--
 drivers/pinctrl/pinctrl-at91-pio4.c              | 26 ++++-----
 drivers/pinctrl/pinctrl-at91.c                   | 13 +----
 drivers/pinctrl/pinctrl-digicolor.c              |  7 +--
 drivers/pinctrl/pinctrl-lantiq.c                 |  2 +-
 drivers/pinctrl/pinctrl-lpc18xx.c                |  3 +-
 drivers/pinctrl/pinctrl-palmas.c                 | 12 +----
 drivers/pinctrl/pinctrl-pic32.c                  |  3 +-
 drivers/pinctrl/pinctrl-pistachio.c              |  4 +-
 drivers/pinctrl/pinctrl-rockchip.c               |  2 +-
 drivers/pinctrl/pinctrl-st.c                     |  2 +-
 drivers/pinctrl/pinctrl-tb10x.c                  |  3 +-
 drivers/pinctrl/pinctrl-tz1090-pdc.c             | 13 +----
 drivers/pinctrl/pinctrl-tz1090.c                 | 13 +----
 drivers/pinctrl/pinctrl-u300.c                   | 12 +----
 drivers/pinctrl/pinctrl-zynq.c                   | 12 +----
 drivers/pinctrl/pxa/pinctrl-pxa2xx.c             | 10 +---
 drivers/pinctrl/qcom/pinctrl-msm.c               |  8 ++-
 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c         |  7 +--
 drivers/pinctrl/qcom/pinctrl-spmi-mpp.c          |  7 +--
 drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c         |  9 +---
 drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c          |  9 +---
 drivers/pinctrl/samsung/pinctrl-exynos5440.c     |  2 +-
 drivers/pinctrl/samsung/pinctrl-samsung.c        |  3 +-
 drivers/pinctrl/sh-pfc/core.c                    |  1 -
 drivers/pinctrl/sh-pfc/core.h                    |  1 -
 drivers/pinctrl/sh-pfc/pinctrl.c                 | 12 +----
 drivers/pinctrl/spear/pinctrl-spear.c            | 11 +---
 drivers/pinctrl/spear/pinctrl-spear.h            |  1 -
 drivers/pinctrl/spear/pinctrl-spear1310.c        |  6 ---
 drivers/pinctrl/spear/pinctrl-spear1340.c        |  6 ---
 drivers/pinctrl/spear/pinctrl-spear300.c         |  6 ---
 drivers/pinctrl/spear/pinctrl-spear310.c         |  6 ---
 drivers/pinctrl/spear/pinctrl-spear320.c         |  6 ---
 drivers/pinctrl/stm32/pinctrl-stm32.c            |  7 +--
 drivers/pinctrl/sunxi/pinctrl-sunxi.c            | 13 ++---
 drivers/pinctrl/tegra/pinctrl-tegra-xusb.c       | 13 ++---
 drivers/pinctrl/tegra/pinctrl-tegra.c            | 12 +----
 drivers/pinctrl/tegra/pinctrl-tegra.h            |  2 -
 drivers/pinctrl/tegra/pinctrl-tegra114.c         |  1 -
 drivers/pinctrl/tegra/pinctrl-tegra124.c         |  1 -
 drivers/pinctrl/tegra/pinctrl-tegra20.c          |  1 -
 drivers/pinctrl/tegra/pinctrl-tegra210.c         |  1 -
 drivers/pinctrl/tegra/pinctrl-tegra30.c          |  1 -
 drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c       |  1 -
 drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c      |  1 -
 drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c      |  1 -
 drivers/pinctrl/uniphier/pinctrl-ph1-pro5.c      |  1 -
 drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c      |  1 -
 drivers/pinctrl/uniphier/pinctrl-proxstream2.c   |  1 -
 drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 12 +----
 drivers/pinctrl/uniphier/pinctrl-uniphier.h      |  2 -
 drivers/pinctrl/vt8500/pinctrl-wmt.c             |  7 +--
 include/linux/pinctrl/pinctrl.h                  |  6 +++
 97 files changed, 179 insertions(+), 393 deletions(-)

-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:26 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:26 +0530
Subject: [PATCH 01/50] pinctrl: Add devm_ apis for pinctrl_{register,
 unregister}
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-2-git-send-email-ldewangan@nvidia.com>

Add device managed APIs devm_pinctrl_register() and
devm_pinctrl_unregister() for the APIs pinctrl_register()
and pinctrl_unregister().

This helps in reducing code in error path and sometimes
removal of .remove callback for driver unbind.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/pinctrl/core.c          | 69 +++++++++++++++++++++++++++++++++++++++++
 include/linux/pinctrl/pinctrl.h |  6 ++++
 2 files changed, 75 insertions(+)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 2686a44..ea4a7e6 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1861,6 +1861,75 @@ void pinctrl_unregister(struct pinctrl_dev *pctldev)
 }
 EXPORT_SYMBOL_GPL(pinctrl_unregister);
 
+static void devm_pinctrl_dev_release(struct device *dev, void *res)
+{
+	struct pinctrl_dev *pctldev = *(struct pinctrl_dev **)res;
+
+	pinctrl_unregister(pctldev);
+}
+
+static int devm_pinctrl_dev_match(struct device *dev, void *res, void *data)
+{
+	struct pctldev **r = res;
+
+	if (!r || !*r) {
+		WARN_ON(!r || !*r);
+		return 0;
+	}
+
+	return *r == data;
+}
+
+/**
+ * devm_pinctrl_register() - Resource manager pinctrl_register()
+ * @dev: parent device for this pin controller
+ * @pctldesc: descriptor for this pin controller
+ * @driver_data: private pin controller data for this pin controller
+ *
+ * Returns an error pointer if pincontrol register failed. Otherwise
+ * it returns valid pinctrl handle.
+ *
+ * The pinctrl device will be automatically released when the device is unbound.
+ */
+struct pinctrl_dev *devm_pinctrl_register(struct device *dev,
+					  struct pinctrl_desc *pctldesc,
+					  void *driver_data)
+{
+	struct pinctrl_dev **ptr, *pctldev;
+
+	ptr = devres_alloc(devm_pinctrl_dev_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return ERR_PTR(-ENOMEM);
+
+	pctldev = pinctrl_register(pctldesc, dev, driver_data);
+	if (IS_ERR(pctldev)) {
+		devres_free(ptr);
+		return pctldev;
+	}
+
+	*ptr = pctldev;
+	devres_add(dev, ptr);
+
+	return pctldev;
+}
+EXPORT_SYMBOL_GPL(devm_pinctrl_register);
+
+/**
+ * devm_pinctrl_unregister() - Resource manager of pinctrl_unregister()
+ * @dev: device for which which resource was allocated
+ * @pctldev: the pinctrl device to unregister.
+ */
+void devm_pinctrl_unregister(struct device *dev, struct pinctrl_dev *pctldev)
+{
+	int ret;
+
+	ret = devres_release(dev, devm_pinctrl_dev_release,
+			     devm_pinctrl_dev_match, pctldev);
+	if (!ret)
+		WARN_ON(ret);
+}
+EXPORT_SYMBOL_GPL(devm_pinctrl_unregister);
+
 static int __init pinctrl_init(void)
 {
 	pr_info("initialized pinctrl subsystem\n");
diff --git a/include/linux/pinctrl/pinctrl.h b/include/linux/pinctrl/pinctrl.h
index 9ba59fc..a42e57d 100644
--- a/include/linux/pinctrl/pinctrl.h
+++ b/include/linux/pinctrl/pinctrl.h
@@ -144,6 +144,12 @@ struct pinctrl_desc {
 extern struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
 				struct device *dev, void *driver_data);
 extern void pinctrl_unregister(struct pinctrl_dev *pctldev);
+extern struct pinctrl_dev *devm_pinctrl_register(struct device *dev,
+				struct pinctrl_desc *pctldesc,
+				void *driver_data);
+extern void devm_pinctrl_unregister(struct device *dev,
+				struct pinctrl_dev *pctldev);
+
 extern bool pin_is_valid(struct pinctrl_dev *pctldev, int pin);
 extern void pinctrl_add_gpio_range(struct pinctrl_dev *pctldev,
 				struct pinctrl_gpio_range *range);
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:29 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:29 +0530
Subject: [PATCH 04/50] pinctrl: bcm2835: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-5-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Ray Jui <rjui at broadcom.com>
---
 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 0f5997c..25bc4a2 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -1027,7 +1027,7 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
 		return err;
 	}
 
-	pc->pctl_dev = pinctrl_register(&bcm2835_pinctrl_desc, dev, pc);
+	pc->pctl_dev = devm_pinctrl_register(dev, &bcm2835_pinctrl_desc, pc);
 	if (IS_ERR(pc->pctl_dev)) {
 		gpiochip_remove(&pc->gpio_chip);
 		return PTR_ERR(pc->pctl_dev);
@@ -1045,7 +1045,6 @@ static int bcm2835_pinctrl_remove(struct platform_device *pdev)
 {
 	struct bcm2835_pinctrl *pc = platform_get_drvdata(pdev);
 
-	pinctrl_unregister(pc->pctl_dev);
 	gpiochip_remove(&pc->gpio_chip);
 
 	return 0;
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:28 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:28 +0530
Subject: [PATCH 03/50] pinctrl: bcm281xx: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-4-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Ray Jui <rjui at broadcom.com>
---
 drivers/pinctrl/bcm/pinctrl-bcm281xx.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
index c3c692e..0c0c0f0 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
@@ -1422,9 +1422,7 @@ static int __init bcm281xx_pinctrl_probe(struct platform_device *pdev)
 	bcm281xx_pinctrl_desc.pins = bcm281xx_pinctrl.pins;
 	bcm281xx_pinctrl_desc.npins = bcm281xx_pinctrl.npins;
 
-	pctl = pinctrl_register(&bcm281xx_pinctrl_desc,
-				&pdev->dev,
-				pdata);
+	pctl = devm_pinctrl_register(&pdev->dev, &bcm281xx_pinctrl_desc, pdata);
 	if (IS_ERR(pctl)) {
 		dev_err(&pdev->dev, "Failed to register pinctrl\n");
 		return PTR_ERR(pctl);
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:30 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:30 +0530
Subject: [PATCH 05/50] pinctrl: cygnus-mux: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-6-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Ray Jui <rjui at broadcom.com>
Cc: Scott Branden <sbranden at broadcom.com>
Cc: Jon Mason <jonmason at broadcom.com>
---
 drivers/pinctrl/bcm/pinctrl-cygnus-mux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
index 9728f3d..9382a0a 100644
--- a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
+++ b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
@@ -987,7 +987,7 @@ static int cygnus_pinmux_probe(struct platform_device *pdev)
 	cygnus_pinctrl_desc.pins = pins;
 	cygnus_pinctrl_desc.npins = num_pins;
 
-	pinctrl->pctl = pinctrl_register(&cygnus_pinctrl_desc, &pdev->dev,
+	pinctrl->pctl = devm_pinctrl_register(&pdev->dev, &cygnus_pinctrl_desc,
 			pinctrl);
 	if (IS_ERR(pinctrl->pctl)) {
 		dev_err(&pdev->dev, "unable to register Cygnus IOMUX pinctrl\n");
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:31 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:31 +0530
Subject: [PATCH 06/50] pinctrl: iproc-gpio: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-7-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and clean
the error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Ray Jui <rjui at broadcom.com>
Cc: Scott Branden <sbranden at broadcom.com>
Cc: Jon Mason <jonmason at broadcom.com>
---
 drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index d530ab4..e753af3 100644
--- a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -623,7 +623,7 @@ static int iproc_gpio_register_pinconf(struct iproc_gpio *chip)
 	pctldesc->npins = gc->ngpio;
 	pctldesc->confops = &iproc_pconf_ops;
 
-	chip->pctl = pinctrl_register(pctldesc, chip->dev, chip);
+	chip->pctl = devm_pinctrl_register(chip->dev, pctldesc, chip);
 	if (IS_ERR(chip->pctl)) {
 		dev_err(chip->dev, "unable to register pinctrl device\n");
 		return PTR_ERR(chip->pctl);
@@ -632,11 +632,6 @@ static int iproc_gpio_register_pinconf(struct iproc_gpio *chip)
 	return 0;
 }
 
-static void iproc_gpio_unregister_pinconf(struct iproc_gpio *chip)
-{
-	pinctrl_unregister(chip->pctl);
-}
-
 static const struct of_device_id iproc_gpio_of_match[] = {
 	{ .compatible = "brcm,cygnus-ccm-gpio" },
 	{ .compatible = "brcm,cygnus-asiu-gpio" },
@@ -720,7 +715,7 @@ static int iproc_gpio_probe(struct platform_device *pdev)
 					   handle_simple_irq, IRQ_TYPE_NONE);
 		if (ret) {
 			dev_err(dev, "no GPIO irqchip\n");
-			goto err_unregister_pinconf;
+			goto err_rm_gpiochip;
 		}
 
 		gpiochip_set_chained_irqchip(gc, &iproc_gpio_irq_chip, irq,
@@ -729,9 +724,6 @@ static int iproc_gpio_probe(struct platform_device *pdev)
 
 	return 0;
 
-err_unregister_pinconf:
-	iproc_gpio_unregister_pinconf(chip);
-
 err_rm_gpiochip:
 	gpiochip_remove(gc);
 
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:41 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:41 +0530
Subject: [PATCH 16/50] pinctrl: nomadic: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-17-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Alessandro Rubini <rubini at unipv.it>
Cc: linux-arm-kernel at lists.infradead.org
---
 drivers/pinctrl/nomadik/pinctrl-abx500.c  | 3 ++-
 drivers/pinctrl/nomadik/pinctrl-nomadik.c | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/nomadik/pinctrl-abx500.c b/drivers/pinctrl/nomadik/pinctrl-abx500.c
index 1f7469c..d488124 100644
--- a/drivers/pinctrl/nomadik/pinctrl-abx500.c
+++ b/drivers/pinctrl/nomadik/pinctrl-abx500.c
@@ -1212,7 +1212,8 @@ static int abx500_gpio_probe(struct platform_device *pdev)
 
 	abx500_pinctrl_desc.pins = pct->soc->pins;
 	abx500_pinctrl_desc.npins = pct->soc->npins;
-	pct->pctldev = pinctrl_register(&abx500_pinctrl_desc, &pdev->dev, pct);
+	pct->pctldev = devm_pinctrl_register(&pdev->dev, &abx500_pinctrl_desc,
+					     pct);
 	if (IS_ERR(pct->pctldev)) {
 		dev_err(&pdev->dev,
 			"could not register abx500 pinctrl driver\n");
diff --git a/drivers/pinctrl/nomadik/pinctrl-nomadik.c b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
index 3524061..ca5e9ea 100644
--- a/drivers/pinctrl/nomadik/pinctrl-nomadik.c
+++ b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
@@ -2044,7 +2044,7 @@ static int nmk_pinctrl_probe(struct platform_device *pdev)
 	nmk_pinctrl_desc.npins = npct->soc->npins;
 	npct->dev = &pdev->dev;
 
-	npct->pctl = pinctrl_register(&nmk_pinctrl_desc, &pdev->dev, npct);
+	npct->pctl = devm_pinctrl_register(&pdev->dev, &nmk_pinctrl_desc, npct);
 	if (IS_ERR(npct->pctl)) {
 		dev_err(&pdev->dev, "could not register Nomadik pinctrl driver\n");
 		return PTR_ERR(npct->pctl);
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:45 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:45 +0530
Subject: [PATCH 20/50] pinctrl: ssbi-mpp: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-21-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and clean
the error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Bjorn Andersson <bjorn.andersson at sonymobile.com>
---
 drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c b/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
index 54a5402..49cc734 100644
--- a/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
+++ b/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
@@ -820,7 +820,7 @@ static int pm8xxx_mpp_probe(struct platform_device *pdev)
 	pctrl->desc.custom_conf_items = pm8xxx_conf_items;
 #endif
 
-	pctrl->pctrl = pinctrl_register(&pctrl->desc, &pdev->dev, pctrl);
+	pctrl->pctrl = devm_pinctrl_register(&pdev->dev, &pctrl->desc, pctrl);
 	if (IS_ERR(pctrl->pctrl)) {
 		dev_err(&pdev->dev, "couldn't register pm8xxx mpp driver\n");
 		return PTR_ERR(pctrl->pctrl);
@@ -836,7 +836,7 @@ static int pm8xxx_mpp_probe(struct platform_device *pdev)
 	ret = gpiochip_add_data(&pctrl->chip, pctrl);
 	if (ret) {
 		dev_err(&pdev->dev, "failed register gpiochip\n");
-		goto unregister_pinctrl;
+		return ret;
 	}
 
 	ret = gpiochip_add_pin_range(&pctrl->chip,
@@ -856,9 +856,6 @@ static int pm8xxx_mpp_probe(struct platform_device *pdev)
 unregister_gpiochip:
 	gpiochip_remove(&pctrl->chip);
 
-unregister_pinctrl:
-	pinctrl_unregister(pctrl->pctrl);
-
 	return ret;
 }
 
@@ -868,8 +865,6 @@ static int pm8xxx_mpp_remove(struct platform_device *pdev)
 
 	gpiochip_remove(&pctrl->chip);
 
-	pinctrl_unregister(pctrl->pctrl);
-
 	return 0;
 }
 
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:53 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:53 +0530
Subject: [PATCH 28/50] pinctrl: ssbi-mpp: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-29-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and clean
the error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Maxime Ripard <maxime.ripard at free-electrons.com>
Cc: Chen-Yu Tsai <wens at csie.org>
---
 drivers/pinctrl/sunxi/pinctrl-sunxi.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 4513550..8eb6de8 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -932,18 +932,15 @@ int sunxi_pinctrl_init(struct platform_device *pdev,
 	pctrl_desc->pctlops = &sunxi_pctrl_ops;
 	pctrl_desc->pmxops =  &sunxi_pmx_ops;
 
-	pctl->pctl_dev = pinctrl_register(pctrl_desc,
-					  &pdev->dev, pctl);
+	pctl->pctl_dev = devm_pinctrl_register(&pdev->dev, pctrl_desc, pctl);
 	if (IS_ERR(pctl->pctl_dev)) {
 		dev_err(&pdev->dev, "couldn't register pinctrl driver\n");
 		return PTR_ERR(pctl->pctl_dev);
 	}
 
 	pctl->chip = devm_kzalloc(&pdev->dev, sizeof(*pctl->chip), GFP_KERNEL);
-	if (!pctl->chip) {
-		ret = -ENOMEM;
-		goto pinctrl_error;
-	}
+	if (!pctl->chip)
+		return -ENOMEM;
 
 	last_pin = pctl->desc->pins[pctl->desc->npins - 1].pin.number;
 	pctl->chip->owner = THIS_MODULE;
@@ -965,7 +962,7 @@ int sunxi_pinctrl_init(struct platform_device *pdev,
 
 	ret = gpiochip_add_data(pctl->chip, pctl);
 	if (ret)
-		goto pinctrl_error;
+		return ret;
 
 	for (i = 0; i < pctl->desc->npins; i++) {
 		const struct sunxi_desc_pin *pin = pctl->desc->pins + i;
@@ -1041,7 +1038,5 @@ clk_error:
 	clk_disable_unprepare(clk);
 gpiochip_error:
 	gpiochip_remove(pctl->chip);
-pinctrl_error:
-	pinctrl_unregister(pctl->pctl_dev);
 	return ret;
 }
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:50 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:50 +0530
Subject: [PATCH 25/50] pinctrl: ish-pfc: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-26-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Cc: Geert Uytterhoeven <geert+renesas at glider.be>
Cc: linux-renesas-soc at vger.kernel.org
---
 drivers/pinctrl/sh-pfc/core.c    |  1 -
 drivers/pinctrl/sh-pfc/core.h    |  1 -
 drivers/pinctrl/sh-pfc/pinctrl.c | 12 +-----------
 3 files changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/pinctrl/sh-pfc/core.c b/drivers/pinctrl/sh-pfc/core.c
index 181ea98..4b28fbb 100644
--- a/drivers/pinctrl/sh-pfc/core.c
+++ b/drivers/pinctrl/sh-pfc/core.c
@@ -587,7 +587,6 @@ static int sh_pfc_remove(struct platform_device *pdev)
 #ifdef CONFIG_GPIO_SH_PFC
 	sh_pfc_unregister_gpiochip(pfc);
 #endif
-	sh_pfc_unregister_pinctrl(pfc);
 
 	return 0;
 }
diff --git a/drivers/pinctrl/sh-pfc/core.h b/drivers/pinctrl/sh-pfc/core.h
index 62f53b2..8272114 100644
--- a/drivers/pinctrl/sh-pfc/core.h
+++ b/drivers/pinctrl/sh-pfc/core.h
@@ -57,7 +57,6 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc);
 int sh_pfc_unregister_gpiochip(struct sh_pfc *pfc);
 
 int sh_pfc_register_pinctrl(struct sh_pfc *pfc);
-int sh_pfc_unregister_pinctrl(struct sh_pfc *pfc);
 
 u32 sh_pfc_read_raw_reg(void __iomem *mapped_reg, unsigned int reg_width);
 void sh_pfc_write_raw_reg(void __iomem *mapped_reg, unsigned int reg_width,
diff --git a/drivers/pinctrl/sh-pfc/pinctrl.c b/drivers/pinctrl/sh-pfc/pinctrl.c
index 87b0a59..f17b5fc 100644
--- a/drivers/pinctrl/sh-pfc/pinctrl.c
+++ b/drivers/pinctrl/sh-pfc/pinctrl.c
@@ -692,19 +692,9 @@ int sh_pfc_register_pinctrl(struct sh_pfc *pfc)
 	pmx->pctl_desc.pins = pmx->pins;
 	pmx->pctl_desc.npins = pfc->info->nr_pins;
 
-	pmx->pctl = pinctrl_register(&pmx->pctl_desc, pfc->dev, pmx);
+	pmx->pctl = devm_pinctrl_register(pfc->dev, &pmx->pctl_desc, pmx);
 	if (IS_ERR(pmx->pctl))
 		return PTR_ERR(pmx->pctl);
 
 	return 0;
 }
-
-int sh_pfc_unregister_pinctrl(struct sh_pfc *pfc)
-{
-	struct sh_pfc_pinctrl *pmx = pfc->pinctrl;
-
-	pinctrl_unregister(pmx->pctl);
-
-	pfc->pinctrl = NULL;
-	return 0;
-}
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:51 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:51 +0530
Subject: [PATCH 26/50] pinctrl: spear: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-27-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and remove
need of .remove callback.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Viresh Kumar <vireshk at kernel.org>
Cc: spear-devel at list.st.com
Cc: linux-arm-kernel at lists.infradead.org
---
 drivers/pinctrl/spear/pinctrl-spear.c     | 11 +----------
 drivers/pinctrl/spear/pinctrl-spear.h     |  1 -
 drivers/pinctrl/spear/pinctrl-spear1310.c |  6 ------
 drivers/pinctrl/spear/pinctrl-spear1340.c |  6 ------
 drivers/pinctrl/spear/pinctrl-spear300.c  |  6 ------
 drivers/pinctrl/spear/pinctrl-spear310.c  |  6 ------
 drivers/pinctrl/spear/pinctrl-spear320.c  |  6 ------
 7 files changed, 1 insertion(+), 41 deletions(-)

diff --git a/drivers/pinctrl/spear/pinctrl-spear.c b/drivers/pinctrl/spear/pinctrl-spear.c
index 0afaf79..4db52ba 100644
--- a/drivers/pinctrl/spear/pinctrl-spear.c
+++ b/drivers/pinctrl/spear/pinctrl-spear.c
@@ -395,7 +395,7 @@ int spear_pinctrl_probe(struct platform_device *pdev,
 	spear_pinctrl_desc.pins = machdata->pins;
 	spear_pinctrl_desc.npins = machdata->npins;
 
-	pmx->pctl = pinctrl_register(&spear_pinctrl_desc, &pdev->dev, pmx);
+	pmx->pctl = devm_pinctrl_register(&pdev->dev, &spear_pinctrl_desc, pmx);
 	if (IS_ERR(pmx->pctl)) {
 		dev_err(&pdev->dev, "Couldn't register pinctrl driver\n");
 		return PTR_ERR(pmx->pctl);
@@ -403,12 +403,3 @@ int spear_pinctrl_probe(struct platform_device *pdev,
 
 	return 0;
 }
-
-int spear_pinctrl_remove(struct platform_device *pdev)
-{
-	struct spear_pmx *pmx = platform_get_drvdata(pdev);
-
-	pinctrl_unregister(pmx->pctl);
-
-	return 0;
-}
diff --git a/drivers/pinctrl/spear/pinctrl-spear.h b/drivers/pinctrl/spear/pinctrl-spear.h
index 27c2cc8..aa5cf70 100644
--- a/drivers/pinctrl/spear/pinctrl-spear.h
+++ b/drivers/pinctrl/spear/pinctrl-spear.h
@@ -197,7 +197,6 @@ void pmx_init_gpio_pingroup_addr(struct spear_gpio_pingroup *gpio_pingroup,
 				 unsigned count, u16 reg);
 int spear_pinctrl_probe(struct platform_device *pdev,
 			struct spear_pinctrl_machdata *machdata);
-int spear_pinctrl_remove(struct platform_device *pdev);
 
 #define SPEAR_PIN_0_TO_101		\
 	PINCTRL_PIN(0, "PLGPIO0"),	\
diff --git a/drivers/pinctrl/spear/pinctrl-spear1310.c b/drivers/pinctrl/spear/pinctrl-spear1310.c
index 92611bb..1821068 100644
--- a/drivers/pinctrl/spear/pinctrl-spear1310.c
+++ b/drivers/pinctrl/spear/pinctrl-spear1310.c
@@ -2704,18 +2704,12 @@ static int spear1310_pinctrl_probe(struct platform_device *pdev)
 	return spear_pinctrl_probe(pdev, &spear1310_machdata);
 }
 
-static int spear1310_pinctrl_remove(struct platform_device *pdev)
-{
-	return spear_pinctrl_remove(pdev);
-}
-
 static struct platform_driver spear1310_pinctrl_driver = {
 	.driver = {
 		.name = DRIVER_NAME,
 		.of_match_table = spear1310_pinctrl_of_match,
 	},
 	.probe = spear1310_pinctrl_probe,
-	.remove = spear1310_pinctrl_remove,
 };
 
 static int __init spear1310_pinctrl_init(void)
diff --git a/drivers/pinctrl/spear/pinctrl-spear1340.c b/drivers/pinctrl/spear/pinctrl-spear1340.c
index f842e9d..c01fb23 100644
--- a/drivers/pinctrl/spear/pinctrl-spear1340.c
+++ b/drivers/pinctrl/spear/pinctrl-spear1340.c
@@ -2020,18 +2020,12 @@ static int spear1340_pinctrl_probe(struct platform_device *pdev)
 	return spear_pinctrl_probe(pdev, &spear1340_machdata);
 }
 
-static int spear1340_pinctrl_remove(struct platform_device *pdev)
-{
-	return spear_pinctrl_remove(pdev);
-}
-
 static struct platform_driver spear1340_pinctrl_driver = {
 	.driver = {
 		.name = DRIVER_NAME,
 		.of_match_table = spear1340_pinctrl_of_match,
 	},
 	.probe = spear1340_pinctrl_probe,
-	.remove = spear1340_pinctrl_remove,
 };
 
 static int __init spear1340_pinctrl_init(void)
diff --git a/drivers/pinctrl/spear/pinctrl-spear300.c b/drivers/pinctrl/spear/pinctrl-spear300.c
index d998a2c..111148d 100644
--- a/drivers/pinctrl/spear/pinctrl-spear300.c
+++ b/drivers/pinctrl/spear/pinctrl-spear300.c
@@ -677,18 +677,12 @@ static int spear300_pinctrl_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int spear300_pinctrl_remove(struct platform_device *pdev)
-{
-	return spear_pinctrl_remove(pdev);
-}
-
 static struct platform_driver spear300_pinctrl_driver = {
 	.driver = {
 		.name = DRIVER_NAME,
 		.of_match_table = spear300_pinctrl_of_match,
 	},
 	.probe = spear300_pinctrl_probe,
-	.remove = spear300_pinctrl_remove,
 };
 
 static int __init spear300_pinctrl_init(void)
diff --git a/drivers/pinctrl/spear/pinctrl-spear310.c b/drivers/pinctrl/spear/pinctrl-spear310.c
index 609b18a..a7b0000 100644
--- a/drivers/pinctrl/spear/pinctrl-spear310.c
+++ b/drivers/pinctrl/spear/pinctrl-spear310.c
@@ -400,18 +400,12 @@ static int spear310_pinctrl_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int spear310_pinctrl_remove(struct platform_device *pdev)
-{
-	return spear_pinctrl_remove(pdev);
-}
-
 static struct platform_driver spear310_pinctrl_driver = {
 	.driver = {
 		.name = DRIVER_NAME,
 		.of_match_table = spear310_pinctrl_of_match,
 	},
 	.probe = spear310_pinctrl_probe,
-	.remove = spear310_pinctrl_remove,
 };
 
 static int __init spear310_pinctrl_init(void)
diff --git a/drivers/pinctrl/spear/pinctrl-spear320.c b/drivers/pinctrl/spear/pinctrl-spear320.c
index c071144..e2b3817 100644
--- a/drivers/pinctrl/spear/pinctrl-spear320.c
+++ b/drivers/pinctrl/spear/pinctrl-spear320.c
@@ -3441,18 +3441,12 @@ static int spear320_pinctrl_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int spear320_pinctrl_remove(struct platform_device *pdev)
-{
-	return spear_pinctrl_remove(pdev);
-}
-
 static struct platform_driver spear320_pinctrl_driver = {
 	.driver = {
 		.name = DRIVER_NAME,
 		.of_match_table = spear320_pinctrl_of_match,
 	},
 	.probe = spear320_pinctrl_probe,
-	.remove = spear320_pinctrl_remove,
 };
 
 static int __init spear320_pinctrl_init(void)
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:40 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:40 +0530
Subject: [PATCH 15/50] pinctrl: mvebu: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-16-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and remove
need of .remove callback.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Cc: Hongzhou Yang <hongzhou.yang at mediatek.com>
Cc: Fabian Frederick <fabf at skynet.be>
Cc: Andrew Andrianov <andrew at ncrmnt.org>
---
 drivers/pinctrl/mvebu/pinctrl-armada-370.c | 6 ------
 drivers/pinctrl/mvebu/pinctrl-armada-375.c | 6 ------
 drivers/pinctrl/mvebu/pinctrl-armada-38x.c | 6 ------
 drivers/pinctrl/mvebu/pinctrl-armada-39x.c | 6 ------
 drivers/pinctrl/mvebu/pinctrl-armada-xp.c  | 6 ------
 drivers/pinctrl/mvebu/pinctrl-dove.c       | 5 +----
 drivers/pinctrl/mvebu/pinctrl-kirkwood.c   | 6 ------
 drivers/pinctrl/mvebu/pinctrl-mvebu.c      | 9 +--------
 8 files changed, 2 insertions(+), 48 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-370.c b/drivers/pinctrl/mvebu/pinctrl-armada-370.c
index 73dc1bc..9cc1cc3 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-370.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-370.c
@@ -417,18 +417,12 @@ static int armada_370_pinctrl_probe(struct platform_device *pdev)
 	return mvebu_pinctrl_probe(pdev);
 }
 
-static int armada_370_pinctrl_remove(struct platform_device *pdev)
-{
-	return mvebu_pinctrl_remove(pdev);
-}
-
 static struct platform_driver armada_370_pinctrl_driver = {
 	.driver = {
 		.name = "armada-370-pinctrl",
 		.of_match_table = armada_370_pinctrl_of_match,
 	},
 	.probe = armada_370_pinctrl_probe,
-	.remove = armada_370_pinctrl_remove,
 };
 
 module_platform_driver(armada_370_pinctrl_driver);
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-375.c b/drivers/pinctrl/mvebu/pinctrl-armada-375.c
index 54e9fbd..0706514 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-375.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-375.c
@@ -435,18 +435,12 @@ static int armada_375_pinctrl_probe(struct platform_device *pdev)
 	return mvebu_pinctrl_probe(pdev);
 }
 
-static int armada_375_pinctrl_remove(struct platform_device *pdev)
-{
-	return mvebu_pinctrl_remove(pdev);
-}
-
 static struct platform_driver armada_375_pinctrl_driver = {
 	.driver = {
 		.name = "armada-375-pinctrl",
 		.of_match_table = of_match_ptr(armada_375_pinctrl_of_match),
 	},
 	.probe = armada_375_pinctrl_probe,
-	.remove = armada_375_pinctrl_remove,
 };
 
 module_platform_driver(armada_375_pinctrl_driver);
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-38x.c b/drivers/pinctrl/mvebu/pinctrl-armada-38x.c
index 6ec82c6..4e84c8e 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-38x.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-38x.c
@@ -446,18 +446,12 @@ static int armada_38x_pinctrl_probe(struct platform_device *pdev)
 	return mvebu_pinctrl_probe(pdev);
 }
 
-static int armada_38x_pinctrl_remove(struct platform_device *pdev)
-{
-	return mvebu_pinctrl_remove(pdev);
-}
-
 static struct platform_driver armada_38x_pinctrl_driver = {
 	.driver = {
 		.name = "armada-38x-pinctrl",
 		.of_match_table = of_match_ptr(armada_38x_pinctrl_of_match),
 	},
 	.probe = armada_38x_pinctrl_probe,
-	.remove = armada_38x_pinctrl_remove,
 };
 
 module_platform_driver(armada_38x_pinctrl_driver);
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-39x.c b/drivers/pinctrl/mvebu/pinctrl-armada-39x.c
index fcfe9b4..e288f8b 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-39x.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-39x.c
@@ -428,18 +428,12 @@ static int armada_39x_pinctrl_probe(struct platform_device *pdev)
 	return mvebu_pinctrl_probe(pdev);
 }
 
-static int armada_39x_pinctrl_remove(struct platform_device *pdev)
-{
-	return mvebu_pinctrl_remove(pdev);
-}
-
 static struct platform_driver armada_39x_pinctrl_driver = {
 	.driver = {
 		.name = "armada-39x-pinctrl",
 		.of_match_table = of_match_ptr(armada_39x_pinctrl_of_match),
 	},
 	.probe = armada_39x_pinctrl_probe,
-	.remove = armada_39x_pinctrl_remove,
 };
 
 module_platform_driver(armada_39x_pinctrl_driver);
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index bf70e09..e4ea71a 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -502,18 +502,12 @@ static int armada_xp_pinctrl_probe(struct platform_device *pdev)
 	return mvebu_pinctrl_probe(pdev);
 }
 
-static int armada_xp_pinctrl_remove(struct platform_device *pdev)
-{
-	return mvebu_pinctrl_remove(pdev);
-}
-
 static struct platform_driver armada_xp_pinctrl_driver = {
 	.driver = {
 		.name = "armada-xp-pinctrl",
 		.of_match_table = armada_xp_pinctrl_of_match,
 	},
 	.probe = armada_xp_pinctrl_probe,
-	.remove = armada_xp_pinctrl_remove,
 	.suspend = armada_xp_pinctrl_suspend,
 	.resume = armada_xp_pinctrl_resume,
 };
diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c b/drivers/pinctrl/mvebu/pinctrl-dove.c
index 95bfd06..f93ae0d 100644
--- a/drivers/pinctrl/mvebu/pinctrl-dove.c
+++ b/drivers/pinctrl/mvebu/pinctrl-dove.c
@@ -840,12 +840,9 @@ static int dove_pinctrl_probe(struct platform_device *pdev)
 
 static int dove_pinctrl_remove(struct platform_device *pdev)
 {
-	int ret;
-
-	ret = mvebu_pinctrl_remove(pdev);
 	if (!IS_ERR(clk))
 		clk_disable_unprepare(clk);
-	return ret;
+	return 0;
 }
 
 static struct platform_driver dove_pinctrl_driver = {
diff --git a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
index 0f07dc55..a78e9a4 100644
--- a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
+++ b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
@@ -481,18 +481,12 @@ static int kirkwood_pinctrl_probe(struct platform_device *pdev)
 	return mvebu_pinctrl_probe(pdev);
 }
 
-static int kirkwood_pinctrl_remove(struct platform_device *pdev)
-{
-	return mvebu_pinctrl_remove(pdev);
-}
-
 static struct platform_driver kirkwood_pinctrl_driver = {
 	.driver = {
 		.name = "kirkwood-pinctrl",
 		.of_match_table = kirkwood_pinctrl_of_match,
 	},
 	.probe = kirkwood_pinctrl_probe,
-	.remove = kirkwood_pinctrl_remove,
 };
 
 module_platform_driver(kirkwood_pinctrl_driver);
diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
index 3ef798f..b6ec6db 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -711,7 +711,7 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	pctl->pctldev = pinctrl_register(&pctl->desc, &pdev->dev, pctl);
+	pctl->pctldev = devm_pinctrl_register(&pdev->dev, &pctl->desc, pctl);
 	if (IS_ERR(pctl->pctldev)) {
 		dev_err(&pdev->dev, "unable to register pinctrl driver\n");
 		return PTR_ERR(pctl->pctldev);
@@ -725,10 +725,3 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
 
 	return 0;
 }
-
-int mvebu_pinctrl_remove(struct platform_device *pdev)
-{
-	struct mvebu_pinctrl *pctl = platform_get_drvdata(pdev);
-	pinctrl_unregister(pctl->pctldev);
-	return 0;
-}
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:37 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:37 +0530
Subject: [PATCH 12/50] pinctrl: intel: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-13-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Mika Westerberg <mika.westerberg at linux.intel.com>
Cc: Heikki Krogerus <heikki.krogerus at linux.intel.com>
---
 drivers/pinctrl/intel/pinctrl-intel.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c
index 85536b4..27bb21b 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -1014,7 +1014,8 @@ int intel_pinctrl_probe(struct platform_device *pdev,
 	pctrl->pctldesc.pins = pctrl->soc->pins;
 	pctrl->pctldesc.npins = pctrl->soc->npins;
 
-	pctrl->pctldev = pinctrl_register(&pctrl->pctldesc, &pdev->dev, pctrl);
+	pctrl->pctldev = devm_pinctrl_register(&pdev->dev, &pctrl->pctldesc,
+					       pctrl);
 	if (IS_ERR(pctrl->pctldev)) {
 		dev_err(&pdev->dev, "failed to register pinctrl driver\n");
 		return PTR_ERR(pctrl->pctldev);
@@ -1037,7 +1038,6 @@ int intel_pinctrl_remove(struct platform_device *pdev)
 	struct intel_pinctrl *pctrl = platform_get_drvdata(pdev);
 
 	gpiochip_remove(&pctrl->chip);
-	pinctrl_unregister(pctrl->pctldev);
 
 	return 0;
 }
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:43 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:43 +0530
Subject: [PATCH 18/50] pinctrl: spmi: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-19-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and clean
the error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Bjorn Andersson <bjorn.andersson at sonymobile.com>
Cc: Ivan T. Ivanov <ivan.ivanov at linaro.org>
Cc: Lee Jones <lee.jones at linaro.org>
Cc: Stephen Boyd <sboyd at codeaurora.org>
Cc: Jonas Gorski <jogo at openwrt.org>
---
 drivers/pinctrl/qcom/pinctrl-spmi-mpp.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
index 2a3e549..418367e 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
@@ -877,14 +877,14 @@ static int pmic_mpp_probe(struct platform_device *pdev)
 	state->chip.of_gpio_n_cells = 2;
 	state->chip.can_sleep = false;
 
-	state->ctrl = pinctrl_register(pctrldesc, dev, state);
+	state->ctrl = devm_pinctrl_register(dev, pctrldesc, state);
 	if (IS_ERR(state->ctrl))
 		return PTR_ERR(state->ctrl);
 
 	ret = gpiochip_add_data(&state->chip, state);
 	if (ret) {
 		dev_err(state->dev, "can't add gpio chip\n");
-		goto err_chip;
+		return ret;
 	}
 
 	ret = gpiochip_add_pin_range(&state->chip, dev_name(dev), 0, 0, npins);
@@ -897,8 +897,6 @@ static int pmic_mpp_probe(struct platform_device *pdev)
 
 err_range:
 	gpiochip_remove(&state->chip);
-err_chip:
-	pinctrl_unregister(state->ctrl);
 	return ret;
 }
 
@@ -907,7 +905,6 @@ static int pmic_mpp_remove(struct platform_device *pdev)
 	struct pmic_mpp_state *state = platform_get_drvdata(pdev);
 
 	gpiochip_remove(&state->chip);
-	pinctrl_unregister(state->ctrl);
 	return 0;
 }
 
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:42 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:42 +0530
Subject: [PATCH 17/50] pinctrl: spmi-gpio: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-18-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and clean
the error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: "Bj?rn Andersson" <bjorn.andersson at sonymobile.com>
Cc: "Ivan T. Ivanov" <ivan.ivanov at linaro.org>
Cc: Lee Jones <lee.jones at linaro.org>
Cc: Stephen Boyd <sboyd at codeaurora.org>
Cc: Jonas Gorski <jogo at openwrt.org>
---
 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index 4e12ded..330e822 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -764,14 +764,14 @@ static int pmic_gpio_probe(struct platform_device *pdev)
 	state->chip.of_gpio_n_cells = 2;
 	state->chip.can_sleep = false;
 
-	state->ctrl = pinctrl_register(pctrldesc, dev, state);
+	state->ctrl = devm_pinctrl_register(dev, pctrldesc, state);
 	if (IS_ERR(state->ctrl))
 		return PTR_ERR(state->ctrl);
 
 	ret = gpiochip_add_data(&state->chip, state);
 	if (ret) {
 		dev_err(state->dev, "can't add gpio chip\n");
-		goto err_chip;
+		return ret;
 	}
 
 	ret = gpiochip_add_pin_range(&state->chip, dev_name(dev), 0, 0, npins);
@@ -784,8 +784,6 @@ static int pmic_gpio_probe(struct platform_device *pdev)
 
 err_range:
 	gpiochip_remove(&state->chip);
-err_chip:
-	pinctrl_unregister(state->ctrl);
 	return ret;
 }
 
@@ -794,7 +792,6 @@ static int pmic_gpio_remove(struct platform_device *pdev)
 	struct pmic_gpio_state *state = platform_get_drvdata(pdev);
 
 	gpiochip_remove(&state->chip);
-	pinctrl_unregister(state->ctrl);
 	return 0;
 }
 
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:38 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:38 +0530
Subject: [PATCH 13/50] pinctrl: mtk-common: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-14-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and clean
the error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Matthias Brugger <matthias.bgg at gmail.com>
Cc: Hongzhou Yang <hongzhou.yang at mediatek.com>
Cc: Yingjoe Chen <yingjoe.chen at mediatek.com>
---
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index ddc9217..194413d 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -1390,17 +1390,16 @@ int mtk_pctrl_init(struct platform_device *pdev,
 	pctl->pctl_desc.pmxops = &mtk_pmx_ops;
 	pctl->dev = &pdev->dev;
 
-	pctl->pctl_dev = pinctrl_register(&pctl->pctl_desc, &pdev->dev, pctl);
+	pctl->pctl_dev = devm_pinctrl_register(&pdev->dev, &pctl->pctl_desc,
+					       pctl);
 	if (IS_ERR(pctl->pctl_dev)) {
 		dev_err(&pdev->dev, "couldn't register pinctrl driver\n");
 		return PTR_ERR(pctl->pctl_dev);
 	}
 
 	pctl->chip = devm_kzalloc(&pdev->dev, sizeof(*pctl->chip), GFP_KERNEL);
-	if (!pctl->chip) {
-		ret = -ENOMEM;
-		goto pctrl_error;
-	}
+	if (!pctl->chip)
+		return -ENOMEM;
 
 	*pctl->chip = mtk_gpio_chip;
 	pctl->chip->ngpio = pctl->devdata->npins;
@@ -1409,10 +1408,8 @@ int mtk_pctrl_init(struct platform_device *pdev,
 	pctl->chip->base = -1;
 
 	ret = gpiochip_add_data(pctl->chip, pctl);
-	if (ret) {
-		ret = -EINVAL;
-		goto pctrl_error;
-	}
+	if (ret)
+		return -EINVAL;
 
 	/* Register the GPIO to pin mappings. */
 	ret = gpiochip_add_pin_range(pctl->chip, dev_name(&pdev->dev),
@@ -1490,8 +1487,6 @@ int mtk_pctrl_init(struct platform_device *pdev,
 
 chip_error:
 	gpiochip_remove(pctl->chip);
-pctrl_error:
-	pinctrl_unregister(pctl->pctl_dev);
 	return ret;
 }
 
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:52 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:52 +0530
Subject: [PATCH 27/50] pinctrl: stm32: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-28-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
Cc: Patrice Chotard <patrice.chotard at st.com>
---
 drivers/pinctrl/stm32/pinctrl-stm32.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c
index 8deb566..7291f07 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -813,10 +813,11 @@ int stm32_pctl_probe(struct platform_device *pdev)
 	pctl->pctl_desc.pmxops = &stm32_pmx_ops;
 	pctl->dev = &pdev->dev;
 
-	pctl->pctl_dev = pinctrl_register(&pctl->pctl_desc, &pdev->dev, pctl);
-	if (!pctl->pctl_dev) {
+	pctl->pctl_dev = devm_pinctrl_register(&pdev->dev, &pctl->pctl_desc,
+					       pctl);
+	if (IS_ERR(pctl->pctl_dev)) {
 		dev_err(&pdev->dev, "Failed pinctrl registration\n");
-		return -EINVAL;
+		return PTR_ERR(pctl->pctl_dev);
 	}
 
 	for (i = 0; i < pctl->nbanks; i++)
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:59 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:59 +0530
Subject: [PATCH 34/50] pinctrl: amd: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-35-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and clean
error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/pinctrl/pinctrl-amd.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c
index 5c025f5..59aa2ca 100644
--- a/drivers/pinctrl/pinctrl-amd.c
+++ b/drivers/pinctrl/pinctrl-amd.c
@@ -783,8 +783,8 @@ static int amd_gpio_probe(struct platform_device *pdev)
 	gpio_dev->ngroups = ARRAY_SIZE(kerncz_groups);
 
 	amd_pinctrl_desc.name = dev_name(&pdev->dev);
-	gpio_dev->pctrl = pinctrl_register(&amd_pinctrl_desc,
-					&pdev->dev, gpio_dev);
+	gpio_dev->pctrl = devm_pinctrl_register(&pdev->dev, &amd_pinctrl_desc,
+						gpio_dev);
 	if (IS_ERR(gpio_dev->pctrl)) {
 		dev_err(&pdev->dev, "Couldn't register pinctrl driver\n");
 		return PTR_ERR(gpio_dev->pctrl);
@@ -792,7 +792,7 @@ static int amd_gpio_probe(struct platform_device *pdev)
 
 	ret = gpiochip_add_data(&gpio_dev->gc, gpio_dev);
 	if (ret)
-		goto out1;
+		return ret;
 
 	ret = gpiochip_add_pin_range(&gpio_dev->gc, dev_name(&pdev->dev),
 				0, 0, TOTAL_NUMBER_OF_PINS);
@@ -825,8 +825,6 @@ static int amd_gpio_probe(struct platform_device *pdev)
 out2:
 	gpiochip_remove(&gpio_dev->gc);
 
-out1:
-	pinctrl_unregister(gpio_dev->pctrl);
 	return ret;
 }
 
@@ -837,7 +835,6 @@ static int amd_gpio_remove(struct platform_device *pdev)
 	gpio_dev = platform_get_drvdata(pdev);
 
 	gpiochip_remove(&gpio_dev->gc);
-	pinctrl_unregister(gpio_dev->pctrl);
 
 	return 0;
 }
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:03 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:03 +0530
Subject: [PATCH 38/50] pinctrl: digicolor: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-39-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and clean
error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Baruch Siach <baruch at tkos.co.il>
---
 drivers/pinctrl/pinctrl-digicolor.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-digicolor.c b/drivers/pinctrl/pinctrl-digicolor.c
index f1343d6..c18014d 100644
--- a/drivers/pinctrl/pinctrl-digicolor.c
+++ b/drivers/pinctrl/pinctrl-digicolor.c
@@ -326,17 +326,15 @@ static int dc_pinctrl_probe(struct platform_device *pdev)
 
 	pmap->dev = &pdev->dev;
 
-	pmap->pctl = pinctrl_register(pctl_desc, &pdev->dev, pmap);
+	pmap->pctl = devm_pinctrl_register(&pdev->dev, pctl_desc, pmap);
 	if (IS_ERR(pmap->pctl)) {
 		dev_err(&pdev->dev, "pinctrl driver registration failed\n");
 		return PTR_ERR(pmap->pctl);
 	}
 
 	ret = dc_gpiochip_add(pmap, pdev->dev.of_node);
-	if (ret < 0) {
-		pinctrl_unregister(pmap->pctl);
+	if (ret < 0)
 		return ret;
-	}
 
 	return 0;
 }
@@ -345,7 +343,6 @@ static int dc_pinctrl_remove(struct platform_device *pdev)
 {
 	struct dc_pinmap *pmap = platform_get_drvdata(pdev);
 
-	pinctrl_unregister(pmap->pctl);
 	gpiochip_remove(&pmap->chip);
 
 	return 0;
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:27 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:27 +0530
Subject: [PATCH 02/50] pinctrl: Add resource management devm_pinctrl_{register,
 unregister}
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-3-git-send-email-ldewangan@nvidia.com>

Add new member of devm wrappers for the pinctrl_register and
pinctrl_unregister in list of managed interfaces.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 Documentation/driver-model/devres.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 831a536..eed5e56 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -323,6 +323,8 @@ PHY
 PINCTRL
   devm_pinctrl_get()
   devm_pinctrl_put()
+  devm_pinctrl_register()
+  devm_pinctrl_unregister()
 
 PWM
   devm_pwm_get()
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:32 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:32 +0530
Subject: [PATCH 07/50] pinctrl: nsp-gpio: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-8-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Ray Jui <rjui at broadcom.com>
Cc: Scott Branden <sbranden at broadcom.com>
Cc: Jon Mason <jonmason at broadcom.com>
---
 drivers/pinctrl/bcm/pinctrl-nsp-gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c b/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
index ac90043..2873f73 100644
--- a/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
@@ -609,7 +609,7 @@ static int nsp_gpio_register_pinconf(struct nsp_gpio *chip)
 	pctldesc->npins = gc->ngpio;
 	pctldesc->confops = &nsp_pconf_ops;
 
-	chip->pctl = pinctrl_register(pctldesc, chip->dev, chip);
+	chip->pctl = devm_pinctrl_register(chip->dev, pctldesc, chip);
 	if (IS_ERR(chip->pctl)) {
 		dev_err(chip->dev, "unable to register pinctrl device\n");
 		return PTR_ERR(chip->pctl);
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:33 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:33 +0530
Subject: [PATCH 08/50] pinctrl: berlin: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-9-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Antoine T?nart <antoine.tenart at free-electrons.com>
---
 drivers/pinctrl/berlin/berlin.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/berlin/berlin.c b/drivers/pinctrl/berlin/berlin.c
index 46f2b48..2d58166 100644
--- a/drivers/pinctrl/berlin/berlin.c
+++ b/drivers/pinctrl/berlin/berlin.c
@@ -316,7 +316,8 @@ int berlin_pinctrl_probe_regmap(struct platform_device *pdev,
 		return ret;
 	}
 
-	pctrl->pctrl_dev = pinctrl_register(&berlin_pctrl_desc, dev, pctrl);
+	pctrl->pctrl_dev = devm_pinctrl_register(dev, &berlin_pctrl_desc,
+						 pctrl);
 	if (IS_ERR(pctrl->pctrl_dev)) {
 		dev_err(dev, "failed to register pinctrl driver\n");
 		return PTR_ERR(pctrl->pctrl_dev);
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:34 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:34 +0530
Subject: [PATCH 09/50] pinctrl: imx: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-10-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and remove
need of .remove callback.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Shawn Guo <shawnguo at kernel.org>
Cc: Stefan Agner <stefan at agner.ch>
Cc: Adrian Alonso <aalonso at freescale.com>
Cc: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
---
 drivers/pinctrl/freescale/pinctrl-imx.c    | 11 +----------
 drivers/pinctrl/freescale/pinctrl-imx.h    |  1 -
 drivers/pinctrl/freescale/pinctrl-imx25.c  |  1 -
 drivers/pinctrl/freescale/pinctrl-imx35.c  |  1 -
 drivers/pinctrl/freescale/pinctrl-imx50.c  |  1 -
 drivers/pinctrl/freescale/pinctrl-imx51.c  |  1 -
 drivers/pinctrl/freescale/pinctrl-imx53.c  |  1 -
 drivers/pinctrl/freescale/pinctrl-imx6dl.c |  1 -
 drivers/pinctrl/freescale/pinctrl-imx6q.c  |  1 -
 drivers/pinctrl/freescale/pinctrl-imx6sl.c |  1 -
 drivers/pinctrl/freescale/pinctrl-imx6sx.c |  1 -
 drivers/pinctrl/freescale/pinctrl-imx6ul.c |  1 -
 drivers/pinctrl/freescale/pinctrl-imx7d.c  |  1 -
 drivers/pinctrl/freescale/pinctrl-vf610.c  |  1 -
 14 files changed, 1 insertion(+), 23 deletions(-)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c b/drivers/pinctrl/freescale/pinctrl-imx.c
index 4c435cf..c231874 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -780,7 +780,7 @@ int imx_pinctrl_probe(struct platform_device *pdev,
 	ipctl->info = info;
 	ipctl->dev = info->dev;
 	platform_set_drvdata(pdev, ipctl);
-	ipctl->pctl = pinctrl_register(&imx_pinctrl_desc, &pdev->dev, ipctl);
+	ipctl->pctl = devm_pinctrl_register(&pdev->dev, &imx_pinctrl_desc, ipctl);
 	if (IS_ERR(ipctl->pctl)) {
 		dev_err(&pdev->dev, "could not register IMX pinctrl driver\n");
 		return PTR_ERR(ipctl->pctl);
@@ -790,12 +790,3 @@ int imx_pinctrl_probe(struct platform_device *pdev,
 
 	return 0;
 }
-
-int imx_pinctrl_remove(struct platform_device *pdev)
-{
-	struct imx_pinctrl *ipctl = platform_get_drvdata(pdev);
-
-	pinctrl_unregister(ipctl->pctl);
-
-	return 0;
-}
diff --git a/drivers/pinctrl/freescale/pinctrl-imx.h b/drivers/pinctrl/freescale/pinctrl-imx.h
index 2a592f6..7bbb6ed 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.h
+++ b/drivers/pinctrl/freescale/pinctrl-imx.h
@@ -98,5 +98,4 @@ struct imx_pinctrl_soc_info {
 
 int imx_pinctrl_probe(struct platform_device *pdev,
 			struct imx_pinctrl_soc_info *info);
-int imx_pinctrl_remove(struct platform_device *pdev);
 #endif /* __DRIVERS_PINCTRL_IMX_H */
diff --git a/drivers/pinctrl/freescale/pinctrl-imx25.c b/drivers/pinctrl/freescale/pinctrl-imx25.c
index 293ed43..81ad546 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx25.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx25.c
@@ -331,7 +331,6 @@ static struct platform_driver imx25_pinctrl_driver = {
 		.of_match_table = of_match_ptr(imx25_pinctrl_of_match),
 	},
 	.probe = imx25_pinctrl_probe,
-	.remove = imx_pinctrl_remove,
 };
 
 static int __init imx25_pinctrl_init(void)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx35.c b/drivers/pinctrl/freescale/pinctrl-imx35.c
index 9109c10..13eb224 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx35.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx35.c
@@ -1021,7 +1021,6 @@ static struct platform_driver imx35_pinctrl_driver = {
 		.of_match_table = imx35_pinctrl_of_match,
 	},
 	.probe = imx35_pinctrl_probe,
-	.remove = imx_pinctrl_remove,
 };
 
 static int __init imx35_pinctrl_init(void)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx50.c b/drivers/pinctrl/freescale/pinctrl-imx50.c
index 51b31df..742c378 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx50.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx50.c
@@ -407,7 +407,6 @@ static struct platform_driver imx50_pinctrl_driver = {
 		.of_match_table = of_match_ptr(imx50_pinctrl_of_match),
 	},
 	.probe = imx50_pinctrl_probe,
-	.remove = imx_pinctrl_remove,
 };
 
 static int __init imx50_pinctrl_init(void)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx51.c b/drivers/pinctrl/freescale/pinctrl-imx51.c
index 8dec494..0863e527 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx51.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx51.c
@@ -784,7 +784,6 @@ static struct platform_driver imx51_pinctrl_driver = {
 		.of_match_table = imx51_pinctrl_of_match,
 	},
 	.probe = imx51_pinctrl_probe,
-	.remove = imx_pinctrl_remove,
 };
 
 static int __init imx51_pinctrl_init(void)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx53.c b/drivers/pinctrl/freescale/pinctrl-imx53.c
index 7344d34..898e387 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx53.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx53.c
@@ -470,7 +470,6 @@ static struct platform_driver imx53_pinctrl_driver = {
 		.of_match_table = imx53_pinctrl_of_match,
 	},
 	.probe = imx53_pinctrl_probe,
-	.remove = imx_pinctrl_remove,
 };
 
 static int __init imx53_pinctrl_init(void)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx6dl.c b/drivers/pinctrl/freescale/pinctrl-imx6dl.c
index 6805c67..d1bc3d9 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx6dl.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx6dl.c
@@ -476,7 +476,6 @@ static struct platform_driver imx6dl_pinctrl_driver = {
 		.of_match_table = imx6dl_pinctrl_of_match,
 	},
 	.probe = imx6dl_pinctrl_probe,
-	.remove = imx_pinctrl_remove,
 };
 
 static int __init imx6dl_pinctrl_init(void)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx6q.c b/drivers/pinctrl/freescale/pinctrl-imx6q.c
index 4d1fcb8..b6d19fb 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx6q.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx6q.c
@@ -482,7 +482,6 @@ static struct platform_driver imx6q_pinctrl_driver = {
 		.of_match_table = imx6q_pinctrl_of_match,
 	},
 	.probe = imx6q_pinctrl_probe,
-	.remove = imx_pinctrl_remove,
 };
 
 static int __init imx6q_pinctrl_init(void)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx6sl.c b/drivers/pinctrl/freescale/pinctrl-imx6sl.c
index 83fa5f1..b165a82 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx6sl.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx6sl.c
@@ -383,7 +383,6 @@ static struct platform_driver imx6sl_pinctrl_driver = {
 		.of_match_table = imx6sl_pinctrl_of_match,
 	},
 	.probe = imx6sl_pinctrl_probe,
-	.remove = imx_pinctrl_remove,
 };
 
 static int __init imx6sl_pinctrl_init(void)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx6sx.c b/drivers/pinctrl/freescale/pinctrl-imx6sx.c
index 0d78fe6..c66d37d 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx6sx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx6sx.c
@@ -386,7 +386,6 @@ static struct platform_driver imx6sx_pinctrl_driver = {
 		.of_match_table = of_match_ptr(imx6sx_pinctrl_of_match),
 	},
 	.probe = imx6sx_pinctrl_probe,
-	.remove = imx_pinctrl_remove,
 };
 
 static int __init imx6sx_pinctrl_init(void)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx6ul.c b/drivers/pinctrl/freescale/pinctrl-imx6ul.c
index 08e7576..2bfd7e8 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx6ul.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx6ul.c
@@ -302,7 +302,6 @@ static struct platform_driver imx6ul_pinctrl_driver = {
 		.of_match_table = of_match_ptr(imx6ul_pinctrl_of_match),
 	},
 	.probe = imx6ul_pinctrl_probe,
-	.remove = imx_pinctrl_remove,
 };
 
 static int __init imx6ul_pinctrl_init(void)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx7d.c b/drivers/pinctrl/freescale/pinctrl-imx7d.c
index 16dc925..ebb39a0 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx7d.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx7d.c
@@ -394,7 +394,6 @@ static struct platform_driver imx7d_pinctrl_driver = {
 		.of_match_table = of_match_ptr(imx7d_pinctrl_of_match),
 	},
 	.probe = imx7d_pinctrl_probe,
-	.remove = imx_pinctrl_remove,
 };
 
 static int __init imx7d_pinctrl_init(void)
diff --git a/drivers/pinctrl/freescale/pinctrl-vf610.c b/drivers/pinctrl/freescale/pinctrl-vf610.c
index 587d1ff..6d81be0 100644
--- a/drivers/pinctrl/freescale/pinctrl-vf610.c
+++ b/drivers/pinctrl/freescale/pinctrl-vf610.c
@@ -318,7 +318,6 @@ static struct platform_driver vf610_pinctrl_driver = {
 		.of_match_table = vf610_pinctrl_of_match,
 	},
 	.probe = vf610_pinctrl_probe,
-	.remove = imx_pinctrl_remove,
 };
 
 static int __init vf610_pinctrl_init(void)
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:36 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:36 +0530
Subject: [PATCH 11/50] pinctrl: cherryview: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-12-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Mika Westerberg <mika.westerberg at linux.intel.com>
Cc: Heikki Krogerus <heikki.krogerus at linux.intel.com>
---
 drivers/pinctrl/intel/pinctrl-cherryview.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c b/drivers/pinctrl/intel/pinctrl-cherryview.c
index 4251e07..1152b8a 100644
--- a/drivers/pinctrl/intel/pinctrl-cherryview.c
+++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
@@ -1526,7 +1526,8 @@ static int chv_pinctrl_probe(struct platform_device *pdev)
 	pctrl->pctldesc.pins = pctrl->community->pins;
 	pctrl->pctldesc.npins = pctrl->community->npins;
 
-	pctrl->pctldev = pinctrl_register(&pctrl->pctldesc, &pdev->dev, pctrl);
+	pctrl->pctldev = devm_pinctrl_register(&pdev->dev, &pctrl->pctldesc,
+					       pctrl);
 	if (IS_ERR(pctrl->pctldev)) {
 		dev_err(&pdev->dev, "failed to register pinctrl driver\n");
 		return PTR_ERR(pctrl->pctldev);
@@ -1548,7 +1549,6 @@ static int chv_pinctrl_remove(struct platform_device *pdev)
 	struct chv_pinctrl *pctrl = platform_get_drvdata(pdev);
 
 	gpiochip_remove(&pctrl->chip);
-	pinctrl_unregister(pctrl->pctldev);
 
 	return 0;
 }
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:35 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:35 +0530
Subject: [PATCH 10/50] pinctrl: imxl: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-11-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and remove
need of .remove callback.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Hongzhou Yang <hongzhou.yang at mediatek.com>
Cc: Antoine Tenart <antoine.tenart at free-electrons.com>
Cc: Heiko Stuebner <heiko at sntech.de>
---
 drivers/pinctrl/freescale/pinctrl-imx1-core.c | 11 +----------
 drivers/pinctrl/freescale/pinctrl-imx1.c      |  1 -
 drivers/pinctrl/freescale/pinctrl-imx1.h      |  1 -
 drivers/pinctrl/freescale/pinctrl-imx21.c     |  1 -
 drivers/pinctrl/freescale/pinctrl-imx27.c     |  1 -
 5 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx1-core.c b/drivers/pinctrl/freescale/pinctrl-imx1-core.c
index acaf84c..b4400cb 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx1-core.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx1-core.c
@@ -635,7 +635,7 @@ int imx1_pinctrl_core_probe(struct platform_device *pdev,
 	ipctl->info = info;
 	ipctl->dev = info->dev;
 	platform_set_drvdata(pdev, ipctl);
-	ipctl->pctl = pinctrl_register(pctl_desc, &pdev->dev, ipctl);
+	ipctl->pctl = devm_pinctrl_register(&pdev->dev, pctl_desc, ipctl);
 	if (IS_ERR(ipctl->pctl)) {
 		dev_err(&pdev->dev, "could not register IMX pinctrl driver\n");
 		return PTR_ERR(ipctl->pctl);
@@ -652,12 +652,3 @@ int imx1_pinctrl_core_probe(struct platform_device *pdev,
 
 	return 0;
 }
-
-int imx1_pinctrl_core_remove(struct platform_device *pdev)
-{
-	struct imx1_pinctrl *ipctl = platform_get_drvdata(pdev);
-
-	pinctrl_unregister(ipctl->pctl);
-
-	return 0;
-}
diff --git a/drivers/pinctrl/freescale/pinctrl-imx1.c b/drivers/pinctrl/freescale/pinctrl-imx1.c
index d3bacb7..0472345 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx1.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx1.c
@@ -269,7 +269,6 @@ static struct platform_driver imx1_pinctrl_driver = {
 		.name		= "imx1-pinctrl",
 		.of_match_table	= imx1_pinctrl_of_match,
 	},
-	.remove	= imx1_pinctrl_core_remove,
 };
 module_platform_driver_probe(imx1_pinctrl_driver, imx1_pinctrl_probe);
 
diff --git a/drivers/pinctrl/freescale/pinctrl-imx1.h b/drivers/pinctrl/freescale/pinctrl-imx1.h
index 692a54c..1740743 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx1.h
+++ b/drivers/pinctrl/freescale/pinctrl-imx1.h
@@ -69,5 +69,4 @@ struct imx1_pinctrl_soc_info {
 
 int imx1_pinctrl_core_probe(struct platform_device *pdev,
 			struct imx1_pinctrl_soc_info *info);
-int imx1_pinctrl_core_remove(struct platform_device *pdev);
 #endif /* __DRIVERS_PINCTRL_IMX1_H */
diff --git a/drivers/pinctrl/freescale/pinctrl-imx21.c b/drivers/pinctrl/freescale/pinctrl-imx21.c
index 9d9aca3..aa1221f 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx21.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx21.c
@@ -332,7 +332,6 @@ static struct platform_driver imx21_pinctrl_driver = {
 		.name		= "imx21-pinctrl",
 		.of_match_table	= imx21_pinctrl_of_match,
 	},
-	.remove	= imx1_pinctrl_core_remove,
 };
 module_platform_driver_probe(imx21_pinctrl_driver, imx21_pinctrl_probe);
 
diff --git a/drivers/pinctrl/freescale/pinctrl-imx27.c b/drivers/pinctrl/freescale/pinctrl-imx27.c
index a461d58..f828fbb 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx27.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx27.c
@@ -405,7 +405,6 @@ static struct platform_driver imx27_pinctrl_driver = {
 		.of_match_table = of_match_ptr(imx27_pinctrl_of_match),
 	},
 	.probe = imx27_pinctrl_probe,
-	.remove = imx1_pinctrl_core_remove,
 };
 
 static int __init imx27_pinctrl_init(void)
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:39 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:39 +0530
Subject: [PATCH 14/50] pinctrl: meson: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-15-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Carlo Caione <carlo at endlessm.com>
Cc: Beniamino Galvani <b.galvani at gmail.com>
Cc: Lee Jones <lee.jones at linaro.org>
---
 drivers/pinctrl/meson/pinctrl-meson.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/meson/pinctrl-meson.c b/drivers/pinctrl/meson/pinctrl-meson.c
index 50cab27..9e1247f 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.c
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -732,7 +732,7 @@ static int meson_pinctrl_probe(struct platform_device *pdev)
 	pc->desc.pins		= pc->data->pins;
 	pc->desc.npins		= pc->data->num_pins;
 
-	pc->pcdev = pinctrl_register(&pc->desc, pc->dev, pc);
+	pc->pcdev = devm_pinctrl_register(pc->dev, &pc->desc, pc);
 	if (IS_ERR(pc->pcdev)) {
 		dev_err(pc->dev, "can't register pinctrl device");
 		return PTR_ERR(pc->pcdev);
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:46 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:46 +0530
Subject: [PATCH 21/50] pinctrl: msm: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-22-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and clean
the error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Bjorn Andersson <bjorn.andersson at sonymobile.com>
Cc: Thomas Gleixner <tglx at linutronix.de>
Cc: Lee Jones <lee.jones at linaro.org>
Cc: Stephen Boyd <sboyd at codeaurora.org>
---
 drivers/pinctrl/qcom/pinctrl-msm.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
index 8777cf0..dc7bf77 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -898,17 +898,16 @@ int msm_pinctrl_probe(struct platform_device *pdev,
 	msm_pinctrl_desc.name = dev_name(&pdev->dev);
 	msm_pinctrl_desc.pins = pctrl->soc->pins;
 	msm_pinctrl_desc.npins = pctrl->soc->npins;
-	pctrl->pctrl = pinctrl_register(&msm_pinctrl_desc, &pdev->dev, pctrl);
+	pctrl->pctrl = devm_pinctrl_register(&pdev->dev, &msm_pinctrl_desc,
+					     pctrl);
 	if (IS_ERR(pctrl->pctrl)) {
 		dev_err(&pdev->dev, "Couldn't register pinctrl driver\n");
 		return PTR_ERR(pctrl->pctrl);
 	}
 
 	ret = msm_gpio_init(pctrl);
-	if (ret) {
-		pinctrl_unregister(pctrl->pctrl);
+	if (ret)
 		return ret;
-	}
 
 	platform_set_drvdata(pdev, pctrl);
 
@@ -923,7 +922,6 @@ int msm_pinctrl_remove(struct platform_device *pdev)
 	struct msm_pinctrl *pctrl = platform_get_drvdata(pdev);
 
 	gpiochip_remove(&pctrl->chip);
-	pinctrl_unregister(pctrl->pctrl);
 
 	unregister_restart_handler(&pctrl->restart_nb);
 
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:44 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:44 +0530
Subject: [PATCH 19/50] pinctrl: ssbi-gpi: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-20-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and clean
the error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Bjorn Andersson <bjorn.andersson at sonymobile.com>
---
 drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
index cd8580d..f71dda6 100644
--- a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
@@ -729,7 +729,7 @@ static int pm8xxx_gpio_probe(struct platform_device *pdev)
 	pctrl->desc.custom_conf_items = pm8xxx_conf_items;
 #endif
 
-	pctrl->pctrl = pinctrl_register(&pctrl->desc, &pdev->dev, pctrl);
+	pctrl->pctrl = devm_pinctrl_register(&pdev->dev, &pctrl->desc, pctrl);
 	if (IS_ERR(pctrl->pctrl)) {
 		dev_err(&pdev->dev, "couldn't register pm8xxx gpio driver\n");
 		return PTR_ERR(pctrl->pctrl);
@@ -745,7 +745,7 @@ static int pm8xxx_gpio_probe(struct platform_device *pdev)
 	ret = gpiochip_add_data(&pctrl->chip, pctrl);
 	if (ret) {
 		dev_err(&pdev->dev, "failed register gpiochip\n");
-		goto unregister_pinctrl;
+		return ret;
 	}
 
 	ret = gpiochip_add_pin_range(&pctrl->chip,
@@ -765,9 +765,6 @@ static int pm8xxx_gpio_probe(struct platform_device *pdev)
 unregister_gpiochip:
 	gpiochip_remove(&pctrl->chip);
 
-unregister_pinctrl:
-	pinctrl_unregister(pctrl->pctrl);
-
 	return ret;
 }
 
@@ -777,8 +774,6 @@ static int pm8xxx_gpio_remove(struct platform_device *pdev)
 
 	gpiochip_remove(&pctrl->chip);
 
-	pinctrl_unregister(pctrl->pctrl);
-
 	return 0;
 }
 
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:48 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:48 +0530
Subject: [PATCH 23/50] pinctrl: exynos5440: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-24-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Tomasz Figa <tomasz.figa at gmail.com>
Cc: Kukjin Kim <kgene at kernel.org>
Cc: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---
 drivers/pinctrl/samsung/pinctrl-exynos5440.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos5440.c b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
index 00ab63a..71f9f13 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos5440.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
@@ -788,7 +788,7 @@ static int exynos5440_pinctrl_register(struct platform_device *pdev,
 	if (ret)
 		return ret;
 
-	pctl_dev = pinctrl_register(ctrldesc, &pdev->dev, priv);
+	pctl_dev = devm_pinctrl_register(&pdev->dev, ctrldesc, priv);
 	if (IS_ERR(pctl_dev)) {
 		dev_err(&pdev->dev, "could not register pinctrl driver\n");
 		return PTR_ERR(pctl_dev);
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:47 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:47 +0530
Subject: [PATCH 22/50] pinctrl: pxa: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-23-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and clean
the error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Daniel Mack <daniel at zonque.org>
Cc: Haojian Zhuang <haojian.zhuang at gmail.com>
Cc: Robert Jarzmik <robert.jarzmik at free.fr>
Cc: linux-arm-kernel at lists.infradead.org
---
 drivers/pinctrl/pxa/pinctrl-pxa2xx.c | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/pinctrl/pxa/pinctrl-pxa2xx.c b/drivers/pinctrl/pxa/pinctrl-pxa2xx.c
index 216f227..deb6aa1 100644
--- a/drivers/pinctrl/pxa/pinctrl-pxa2xx.c
+++ b/drivers/pinctrl/pxa/pinctrl-pxa2xx.c
@@ -416,7 +416,7 @@ int pxa2xx_pinctrl_init(struct platform_device *pdev,
 	if (ret)
 		return ret;
 
-	pctl->pctl_dev = pinctrl_register(&pctl->desc, &pdev->dev, pctl);
+	pctl->pctl_dev = devm_pinctrl_register(&pdev->dev, &pctl->desc, pctl);
 	if (IS_ERR(pctl->pctl_dev)) {
 		dev_err(&pdev->dev, "couldn't register pinctrl driver\n");
 		return PTR_ERR(pctl->pctl_dev);
@@ -427,11 +427,3 @@ int pxa2xx_pinctrl_init(struct platform_device *pdev,
 	return 0;
 }
 EXPORT_SYMBOL(pxa2xx_pinctrl_init);
-
-int pxa2xx_pinctrl_exit(struct platform_device *pdev)
-{
-	struct pxa_pinctrl *pctl = platform_get_drvdata(pdev);
-
-	pinctrl_unregister(pctl->pctl_dev);
-	return 0;
-}
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:49 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:49 +0530
Subject: [PATCH 24/50] pinctrl: samsung: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-25-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Tomasz Figa <tomasz.figa at gmail.com>
Cc: Kukjin Kim <kgene at kernel.org>
Cc: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---
 drivers/pinctrl/samsung/pinctrl-samsung.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 5cc97f8..ed0b708 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -884,7 +884,8 @@ static int samsung_pinctrl_register(struct platform_device *pdev,
 	if (ret)
 		return ret;
 
-	drvdata->pctl_dev = pinctrl_register(ctrldesc, &pdev->dev, drvdata);
+	drvdata->pctl_dev = devm_pinctrl_register(&pdev->dev, ctrldesc,
+						  drvdata);
 	if (IS_ERR(drvdata->pctl_dev)) {
 		dev_err(&pdev->dev, "could not register pinctrl driver\n");
 		return PTR_ERR(drvdata->pctl_dev);
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:56 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:56 +0530
Subject: [PATCH 31/50] pinctrl: uniphier: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-32-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and remove
need of .remove callback.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Masahiro Yamada <yamada.masahiro at socionext.com>
---
 drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c       |  1 -
 drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c      |  1 -
 drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c      |  1 -
 drivers/pinctrl/uniphier/pinctrl-ph1-pro5.c      |  1 -
 drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c      |  1 -
 drivers/pinctrl/uniphier/pinctrl-proxstream2.c   |  1 -
 drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 12 +-----------
 drivers/pinctrl/uniphier/pinctrl-uniphier.h      |  2 --
 8 files changed, 1 insertion(+), 19 deletions(-)

diff --git a/drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c b/drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c
index a7056dc..4a0439c 100644
--- a/drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c
+++ b/drivers/pinctrl/uniphier/pinctrl-ph1-ld4.c
@@ -878,7 +878,6 @@ MODULE_DEVICE_TABLE(of, ph1_ld4_pinctrl_match);
 
 static struct platform_driver ph1_ld4_pinctrl_driver = {
 	.probe = ph1_ld4_pinctrl_probe,
-	.remove = uniphier_pinctrl_remove,
 	.driver = {
 		.name = DRIVER_NAME,
 		.of_match_table = ph1_ld4_pinctrl_match,
diff --git a/drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c b/drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c
index 1824831..150d339 100644
--- a/drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c
+++ b/drivers/pinctrl/uniphier/pinctrl-ph1-ld6b.c
@@ -1266,7 +1266,6 @@ MODULE_DEVICE_TABLE(of, ph1_ld6b_pinctrl_match);
 
 static struct platform_driver ph1_ld6b_pinctrl_driver = {
 	.probe = ph1_ld6b_pinctrl_probe,
-	.remove = uniphier_pinctrl_remove,
 	.driver = {
 		.name = DRIVER_NAME,
 		.of_match_table = ph1_ld6b_pinctrl_match,
diff --git a/drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c b/drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c
index ec8e92d..b1f09e6 100644
--- a/drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c
+++ b/drivers/pinctrl/uniphier/pinctrl-ph1-pro4.c
@@ -1552,7 +1552,6 @@ MODULE_DEVICE_TABLE(of, ph1_pro4_pinctrl_match);
 
 static struct platform_driver ph1_pro4_pinctrl_driver = {
 	.probe = ph1_pro4_pinctrl_probe,
-	.remove = uniphier_pinctrl_remove,
 	.driver = {
 		.name = DRIVER_NAME,
 		.of_match_table = ph1_pro4_pinctrl_match,
diff --git a/drivers/pinctrl/uniphier/pinctrl-ph1-pro5.c b/drivers/pinctrl/uniphier/pinctrl-ph1-pro5.c
index e3d648e..3087f76 100644
--- a/drivers/pinctrl/uniphier/pinctrl-ph1-pro5.c
+++ b/drivers/pinctrl/uniphier/pinctrl-ph1-pro5.c
@@ -1343,7 +1343,6 @@ MODULE_DEVICE_TABLE(of, ph1_pro5_pinctrl_match);
 
 static struct platform_driver ph1_pro5_pinctrl_driver = {
 	.probe = ph1_pro5_pinctrl_probe,
-	.remove = uniphier_pinctrl_remove,
 	.driver = {
 		.name = DRIVER_NAME,
 		.of_match_table = ph1_pro5_pinctrl_match,
diff --git a/drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c b/drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c
index c3700a3..ceb7a98 100644
--- a/drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c
+++ b/drivers/pinctrl/uniphier/pinctrl-ph1-sld8.c
@@ -786,7 +786,6 @@ MODULE_DEVICE_TABLE(of, ph1_sld8_pinctrl_match);
 
 static struct platform_driver ph1_sld8_pinctrl_driver = {
 	.probe = ph1_sld8_pinctrl_probe,
-	.remove = uniphier_pinctrl_remove,
 	.driver = {
 		.name = DRIVER_NAME,
 		.of_match_table = ph1_sld8_pinctrl_match,
diff --git a/drivers/pinctrl/uniphier/pinctrl-proxstream2.c b/drivers/pinctrl/uniphier/pinctrl-proxstream2.c
index bc00d75..e868030 100644
--- a/drivers/pinctrl/uniphier/pinctrl-proxstream2.c
+++ b/drivers/pinctrl/uniphier/pinctrl-proxstream2.c
@@ -1261,7 +1261,6 @@ MODULE_DEVICE_TABLE(of, proxstream2_pinctrl_match);
 
 static struct platform_driver proxstream2_pinctrl_driver = {
 	.probe = proxstream2_pinctrl_probe,
-	.remove = uniphier_pinctrl_remove,
 	.driver = {
 		.name = DRIVER_NAME,
 		.of_match_table = proxstream2_pinctrl_match,
diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c b/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
index 589872c..0176061 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
@@ -665,7 +665,7 @@ int uniphier_pinctrl_probe(struct platform_device *pdev,
 	desc->pmxops = &uniphier_pmxops;
 	desc->confops = &uniphier_confops;
 
-	priv->pctldev = pinctrl_register(desc, dev, priv);
+	priv->pctldev = devm_pinctrl_register(dev, desc, priv);
 	if (IS_ERR(priv->pctldev)) {
 		dev_err(dev, "failed to register UniPhier pinctrl driver\n");
 		return PTR_ERR(priv->pctldev);
@@ -676,13 +676,3 @@ int uniphier_pinctrl_probe(struct platform_device *pdev,
 	return 0;
 }
 EXPORT_SYMBOL_GPL(uniphier_pinctrl_probe);
-
-int uniphier_pinctrl_remove(struct platform_device *pdev)
-{
-	struct uniphier_pinctrl_priv *priv = platform_get_drvdata(pdev);
-
-	pinctrl_unregister(priv->pctldev);
-
-	return 0;
-}
-EXPORT_SYMBOL_GPL(uniphier_pinctrl_remove);
diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier.h b/drivers/pinctrl/uniphier/pinctrl-uniphier.h
index e1e98b8..a21154f 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier.h
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier.h
@@ -212,6 +212,4 @@ int uniphier_pinctrl_probe(struct platform_device *pdev,
 			   struct pinctrl_desc *desc,
 			   struct uniphier_pinctrl_socdata *socdata);
 
-int uniphier_pinctrl_remove(struct platform_device *pdev);
-
 #endif /* __PINCTRL_UNIPHIER_H__ */
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:05 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:05 +0530
Subject: [PATCH 40/50] pinctrl: lpc18xx: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-41-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Joachim Eastwood <manabian at gmail.com>
---
 drivers/pinctrl/pinctrl-lpc18xx.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-lpc18xx.c b/drivers/pinctrl/pinctrl-lpc18xx.c
index f0bebbe..7227e40 100644
--- a/drivers/pinctrl/pinctrl-lpc18xx.c
+++ b/drivers/pinctrl/pinctrl-lpc18xx.c
@@ -1225,7 +1225,7 @@ static int lpc18xx_scu_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, scu);
 
-	scu->pctl = pinctrl_register(&lpc18xx_scu_desc, &pdev->dev, scu);
+	scu->pctl = devm_pinctrl_register(&pdev->dev, &lpc18xx_scu_desc, scu);
 	if (IS_ERR(scu->pctl)) {
 		dev_err(&pdev->dev, "Could not register pinctrl driver\n");
 		clk_disable_unprepare(scu->clk);
@@ -1239,7 +1239,6 @@ static int lpc18xx_scu_remove(struct platform_device *pdev)
 {
 	struct lpc18xx_scu_data *scu = platform_get_drvdata(pdev);
 
-	pinctrl_unregister(scu->pctl);
 	clk_disable_unprepare(scu->clk);
 
 	return 0;
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:04 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:04 +0530
Subject: [PATCH 39/50] pinctrl: lantiq: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-40-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/pinctrl/pinctrl-lantiq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-lantiq.c b/drivers/pinctrl/pinctrl-lantiq.c
index fc38a85..a4d6474 100644
--- a/drivers/pinctrl/pinctrl-lantiq.c
+++ b/drivers/pinctrl/pinctrl-lantiq.c
@@ -336,7 +336,7 @@ int ltq_pinctrl_register(struct platform_device *pdev,
 	desc->pmxops = &ltq_pmx_ops;
 	info->dev = &pdev->dev;
 
-	info->pctrl = pinctrl_register(desc, &pdev->dev, info);
+	info->pctrl = devm_pinctrl_register(&pdev->dev, desc, info);
 	if (IS_ERR(info->pctrl)) {
 		dev_err(&pdev->dev, "failed to register LTQ pinmux driver\n");
 		return PTR_ERR(info->pctrl);
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:54 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:54 +0530
Subject: [PATCH 29/50] pinctrl: tegra: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-30-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and remove
need of .remove callback.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Stephen Warren <swarren at wwwdotorg.org>
Cc: Thierry Reding <thierry.reding at gmail.com>
Cc: Alexandre Courbot <gnurou at gmail.com>
---
 drivers/pinctrl/tegra/pinctrl-tegra.c    | 12 +-----------
 drivers/pinctrl/tegra/pinctrl-tegra.h    |  2 --
 drivers/pinctrl/tegra/pinctrl-tegra114.c |  1 -
 drivers/pinctrl/tegra/pinctrl-tegra124.c |  1 -
 drivers/pinctrl/tegra/pinctrl-tegra20.c  |  1 -
 drivers/pinctrl/tegra/pinctrl-tegra210.c |  1 -
 drivers/pinctrl/tegra/pinctrl-tegra30.c  |  1 -
 7 files changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c b/drivers/pinctrl/tegra/pinctrl-tegra.c
index 4938882..e9e8744 100644
--- a/drivers/pinctrl/tegra/pinctrl-tegra.c
+++ b/drivers/pinctrl/tegra/pinctrl-tegra.c
@@ -719,7 +719,7 @@ int tegra_pinctrl_probe(struct platform_device *pdev,
 			return PTR_ERR(pmx->regs[i]);
 	}
 
-	pmx->pctl = pinctrl_register(&tegra_pinctrl_desc, &pdev->dev, pmx);
+	pmx->pctl = devm_pinctrl_register(&pdev->dev, &tegra_pinctrl_desc, pmx);
 	if (IS_ERR(pmx->pctl)) {
 		dev_err(&pdev->dev, "Couldn't register pinctrl driver\n");
 		return PTR_ERR(pmx->pctl);
@@ -735,13 +735,3 @@ int tegra_pinctrl_probe(struct platform_device *pdev,
 	return 0;
 }
 EXPORT_SYMBOL_GPL(tegra_pinctrl_probe);
-
-int tegra_pinctrl_remove(struct platform_device *pdev)
-{
-	struct tegra_pmx *pmx = platform_get_drvdata(pdev);
-
-	pinctrl_unregister(pmx->pctl);
-
-	return 0;
-}
-EXPORT_SYMBOL_GPL(tegra_pinctrl_remove);
diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.h b/drivers/pinctrl/tegra/pinctrl-tegra.h
index 1615db7..05785e5 100644
--- a/drivers/pinctrl/tegra/pinctrl-tegra.h
+++ b/drivers/pinctrl/tegra/pinctrl-tegra.h
@@ -189,6 +189,4 @@ struct tegra_pinctrl_soc_data {
 
 int tegra_pinctrl_probe(struct platform_device *pdev,
 			const struct tegra_pinctrl_soc_data *soc_data);
-int tegra_pinctrl_remove(struct platform_device *pdev);
-
 #endif
diff --git a/drivers/pinctrl/tegra/pinctrl-tegra114.c b/drivers/pinctrl/tegra/pinctrl-tegra114.c
index 05e49d5..236cc57 100644
--- a/drivers/pinctrl/tegra/pinctrl-tegra114.c
+++ b/drivers/pinctrl/tegra/pinctrl-tegra114.c
@@ -1863,7 +1863,6 @@ static struct platform_driver tegra114_pinctrl_driver = {
 		.of_match_table = tegra114_pinctrl_of_match,
 	},
 	.probe = tegra114_pinctrl_probe,
-	.remove = tegra_pinctrl_remove,
 };
 module_platform_driver(tegra114_pinctrl_driver);
 
diff --git a/drivers/pinctrl/tegra/pinctrl-tegra124.c b/drivers/pinctrl/tegra/pinctrl-tegra124.c
index 7cd44c7..749ea05 100644
--- a/drivers/pinctrl/tegra/pinctrl-tegra124.c
+++ b/drivers/pinctrl/tegra/pinctrl-tegra124.c
@@ -2075,7 +2075,6 @@ static struct platform_driver tegra124_pinctrl_driver = {
 		.of_match_table = tegra124_pinctrl_of_match,
 	},
 	.probe = tegra124_pinctrl_probe,
-	.remove = tegra_pinctrl_remove,
 };
 module_platform_driver(tegra124_pinctrl_driver);
 
diff --git a/drivers/pinctrl/tegra/pinctrl-tegra20.c b/drivers/pinctrl/tegra/pinctrl-tegra20.c
index 4833db4..979e329 100644
--- a/drivers/pinctrl/tegra/pinctrl-tegra20.c
+++ b/drivers/pinctrl/tegra/pinctrl-tegra20.c
@@ -2242,7 +2242,6 @@ static struct platform_driver tegra20_pinctrl_driver = {
 		.of_match_table = tegra20_pinctrl_of_match,
 	},
 	.probe = tegra20_pinctrl_probe,
-	.remove = tegra_pinctrl_remove,
 };
 module_platform_driver(tegra20_pinctrl_driver);
 
diff --git a/drivers/pinctrl/tegra/pinctrl-tegra210.c b/drivers/pinctrl/tegra/pinctrl-tegra210.c
index 252b464..cb2c87d8 100644
--- a/drivers/pinctrl/tegra/pinctrl-tegra210.c
+++ b/drivers/pinctrl/tegra/pinctrl-tegra210.c
@@ -1579,7 +1579,6 @@ static struct platform_driver tegra210_pinctrl_driver = {
 		.of_match_table = tegra210_pinctrl_of_match,
 	},
 	.probe = tegra210_pinctrl_probe,
-	.remove = tegra_pinctrl_remove,
 };
 module_platform_driver(tegra210_pinctrl_driver);
 
diff --git a/drivers/pinctrl/tegra/pinctrl-tegra30.c b/drivers/pinctrl/tegra/pinctrl-tegra30.c
index 47b2fd8..6b3e96c 100644
--- a/drivers/pinctrl/tegra/pinctrl-tegra30.c
+++ b/drivers/pinctrl/tegra/pinctrl-tegra30.c
@@ -2498,7 +2498,6 @@ static struct platform_driver tegra30_pinctrl_driver = {
 		.of_match_table = tegra30_pinctrl_of_match,
 	},
 	.probe = tegra30_pinctrl_probe,
-	.remove = tegra_pinctrl_remove,
 };
 module_platform_driver(tegra30_pinctrl_driver);
 
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:55 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:55 +0530
Subject: [PATCH 30/50] pinctrl: tegra-xusb: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-31-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and clean
the error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Stephen Warren <swarren at wwwdotorg.org>
Cc: Thierry Reding <thierry.reding at gmail.com>
Cc: Alexandre Courbot <gnurou at gmail.com>
Cc: Jon Hunter <jonathanh at nvidia.com>
---
 drivers/pinctrl/tegra/pinctrl-tegra-xusb.c | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/tegra/pinctrl-tegra-xusb.c b/drivers/pinctrl/tegra/pinctrl-tegra-xusb.c
index 2f06029..19f16f4 100644
--- a/drivers/pinctrl/tegra/pinctrl-tegra-xusb.c
+++ b/drivers/pinctrl/tegra/pinctrl-tegra-xusb.c
@@ -914,7 +914,8 @@ static int tegra_xusb_padctl_probe(struct platform_device *pdev)
 	padctl->desc.confops = &tegra_xusb_padctl_pinconf_ops;
 	padctl->desc.owner = THIS_MODULE;
 
-	padctl->pinctrl = pinctrl_register(&padctl->desc, &pdev->dev, padctl);
+	padctl->pinctrl = devm_pinctrl_register(&pdev->dev, &padctl->desc,
+						padctl);
 	if (IS_ERR(padctl->pinctrl)) {
 		dev_err(&pdev->dev, "failed to register pincontrol\n");
 		err = PTR_ERR(padctl->pinctrl);
@@ -924,7 +925,7 @@ static int tegra_xusb_padctl_probe(struct platform_device *pdev)
 	phy = devm_phy_create(&pdev->dev, NULL, &pcie_phy_ops);
 	if (IS_ERR(phy)) {
 		err = PTR_ERR(phy);
-		goto unregister;
+		goto reset;
 	}
 
 	padctl->phys[TEGRA_XUSB_PADCTL_PCIE] = phy;
@@ -933,7 +934,7 @@ static int tegra_xusb_padctl_probe(struct platform_device *pdev)
 	phy = devm_phy_create(&pdev->dev, NULL, &sata_phy_ops);
 	if (IS_ERR(phy)) {
 		err = PTR_ERR(phy);
-		goto unregister;
+		goto reset;
 	}
 
 	padctl->phys[TEGRA_XUSB_PADCTL_SATA] = phy;
@@ -944,13 +945,11 @@ static int tegra_xusb_padctl_probe(struct platform_device *pdev)
 	if (IS_ERR(padctl->provider)) {
 		err = PTR_ERR(padctl->provider);
 		dev_err(&pdev->dev, "failed to register PHYs: %d\n", err);
-		goto unregister;
+		goto reset;
 	}
 
 	return 0;
 
-unregister:
-	pinctrl_unregister(padctl->pinctrl);
 reset:
 	reset_control_assert(padctl->rst);
 	return err;
@@ -961,8 +960,6 @@ static int tegra_xusb_padctl_remove(struct platform_device *pdev)
 	struct tegra_xusb_padctl *padctl = platform_get_drvdata(pdev);
 	int err;
 
-	pinctrl_unregister(padctl->pinctrl);
-
 	err = reset_control_assert(padctl->rst);
 	if (err < 0)
 		dev_err(&pdev->dev, "failed to assert reset: %d\n", err);
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:06 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:06 +0530
Subject: [PATCH 41/50] pinctrl: palmas: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-42-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and
remove the need of .remove callback.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/pinctrl/pinctrl-palmas.c | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-palmas.c b/drivers/pinctrl/pinctrl-palmas.c
index f7e1680..07b952b 100644
--- a/drivers/pinctrl/pinctrl-palmas.c
+++ b/drivers/pinctrl/pinctrl-palmas.c
@@ -1043,7 +1043,8 @@ static int palmas_pinctrl_probe(struct platform_device *pdev)
 	palmas_pinctrl_desc.name = dev_name(&pdev->dev);
 	palmas_pinctrl_desc.pins = palmas_pins_desc;
 	palmas_pinctrl_desc.npins = ARRAY_SIZE(palmas_pins_desc);
-	pci->pctl = pinctrl_register(&palmas_pinctrl_desc, &pdev->dev, pci);
+	pci->pctl = devm_pinctrl_register(&pdev->dev, &palmas_pinctrl_desc,
+					  pci);
 	if (IS_ERR(pci->pctl)) {
 		dev_err(&pdev->dev, "Couldn't register pinctrl driver\n");
 		return PTR_ERR(pci->pctl);
@@ -1051,21 +1052,12 @@ static int palmas_pinctrl_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int palmas_pinctrl_remove(struct platform_device *pdev)
-{
-	struct palmas_pctrl_chip_info *pci = platform_get_drvdata(pdev);
-
-	pinctrl_unregister(pci->pctl);
-	return 0;
-}
-
 static struct platform_driver palmas_pinctrl_driver = {
 	.driver = {
 		.name = "palmas-pinctrl",
 		.of_match_table = palmas_pinctrl_of_match,
 	},
 	.probe = palmas_pinctrl_probe,
-	.remove = palmas_pinctrl_remove,
 };
 
 module_platform_driver(palmas_pinctrl_driver);
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:07 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:07 +0530
Subject: [PATCH 42/50] pinctrl: pic32: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-43-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/pinctrl/pinctrl-pic32.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-pic32.c b/drivers/pinctrl/pinctrl-pic32.c
index 0b07d4b..2a3fcd6 100644
--- a/drivers/pinctrl/pinctrl-pic32.c
+++ b/drivers/pinctrl/pinctrl-pic32.c
@@ -2194,7 +2194,8 @@ static int pic32_pinctrl_probe(struct platform_device *pdev)
 	pic32_pinctrl_desc.custom_params = pic32_mpp_bindings;
 	pic32_pinctrl_desc.num_custom_params = ARRAY_SIZE(pic32_mpp_bindings);
 
-	pctl->pctldev = pinctrl_register(&pic32_pinctrl_desc, &pdev->dev, pctl);
+	pctl->pctldev = devm_pinctrl_register(&pdev->dev, &pic32_pinctrl_desc,
+					      pctl);
 	if (IS_ERR(pctl->pctldev)) {
 		dev_err(&pdev->dev, "Failed to register pinctrl device\n");
 		return PTR_ERR(pctl->pctldev);
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:09 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:09 +0530
Subject: [PATCH 44/50] pinctrl: rockchip: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-45-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Heiko Stuebner <heiko at sntech.de>
Cc: linux-rockchip at lists.infradead.org
---
 drivers/pinctrl/pinctrl-rockchip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
index bf032b9..3427103 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -1636,7 +1636,7 @@ static int rockchip_pinctrl_register(struct platform_device *pdev,
 	if (ret)
 		return ret;
 
-	info->pctl_dev = pinctrl_register(ctrldesc, &pdev->dev, info);
+	info->pctl_dev = devm_pinctrl_register(&pdev->dev, ctrldesc, info);
 	if (IS_ERR(info->pctl_dev)) {
 		dev_err(&pdev->dev, "could not register pinctrl driver\n");
 		return PTR_ERR(info->pctl_dev);
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:00 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:00 +0530
Subject: [PATCH 35/50] pinctrl: as3722: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-36-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and clean
error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/pinctrl/pinctrl-as3722.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-as3722.c b/drivers/pinctrl/pinctrl-as3722.c
index e844fdc..0808569 100644
--- a/drivers/pinctrl/pinctrl-as3722.c
+++ b/drivers/pinctrl/pinctrl-as3722.c
@@ -569,8 +569,8 @@ static int as3722_pinctrl_probe(struct platform_device *pdev)
 	as3722_pinctrl_desc.name = dev_name(&pdev->dev);
 	as3722_pinctrl_desc.pins = as3722_pins_desc;
 	as3722_pinctrl_desc.npins = ARRAY_SIZE(as3722_pins_desc);
-	as_pci->pctl = pinctrl_register(&as3722_pinctrl_desc,
-					&pdev->dev, as_pci);
+	as_pci->pctl = devm_pinctrl_register(&pdev->dev, &as3722_pinctrl_desc,
+					     as_pci);
 	if (IS_ERR(as_pci->pctl)) {
 		dev_err(&pdev->dev, "Couldn't register pinctrl driver\n");
 		return PTR_ERR(as_pci->pctl);
@@ -582,7 +582,7 @@ static int as3722_pinctrl_probe(struct platform_device *pdev)
 	ret = gpiochip_add_data(&as_pci->gpio_chip, as_pci);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Couldn't register gpiochip, %d\n", ret);
-		goto fail_chip_add;
+		return ret;
 	}
 
 	ret = gpiochip_add_pin_range(&as_pci->gpio_chip, dev_name(&pdev->dev),
@@ -596,8 +596,6 @@ static int as3722_pinctrl_probe(struct platform_device *pdev)
 
 fail_range_add:
 	gpiochip_remove(&as_pci->gpio_chip);
-fail_chip_add:
-	pinctrl_unregister(as_pci->pctl);
 	return ret;
 }
 
@@ -606,7 +604,6 @@ static int as3722_pinctrl_remove(struct platform_device *pdev)
 	struct as3722_pctrl_info *as_pci = platform_get_drvdata(pdev);
 
 	gpiochip_remove(&as_pci->gpio_chip);
-	pinctrl_unregister(as_pci->pctl);
 	return 0;
 }
 
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:10 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:10 +0530
Subject: [PATCH 45/50] pinctrl: st: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-46-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Srinivas Kandagatla <srinivas.kandagatla at gmail.com>
Cc: Maxime Coquelin <maxime.coquelin at st.com>
Cc: Patrice Chotard <patrice.chotard at st.com>
Cc: kernel at stlinux.com
---
 drivers/pinctrl/pinctrl-st.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-st.c b/drivers/pinctrl/pinctrl-st.c
index cab66c6..d0ba968 100644
--- a/drivers/pinctrl/pinctrl-st.c
+++ b/drivers/pinctrl/pinctrl-st.c
@@ -1724,7 +1724,7 @@ static int st_pctl_probe(struct platform_device *pdev)
 	pctl_desc->confops	= &st_confops;
 	pctl_desc->name		= dev_name(&pdev->dev);
 
-	info->pctl = pinctrl_register(pctl_desc, &pdev->dev, info);
+	info->pctl = devm_pinctrl_register(&pdev->dev, pctl_desc, info);
 	if (IS_ERR(info->pctl)) {
 		dev_err(&pdev->dev, "Failed pinctrl registration\n");
 		return PTR_ERR(info->pctl);
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:58 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:58 +0530
Subject: [PATCH 33/50] pinctrl: adi2: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-34-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and remove
the need of .remove callback.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/pinctrl/pinctrl-adi2.c | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-adi2.c b/drivers/pinctrl/pinctrl-adi2.c
index ecb57635..54569a7 100644
--- a/drivers/pinctrl/pinctrl-adi2.c
+++ b/drivers/pinctrl/pinctrl-adi2.c
@@ -1058,7 +1058,8 @@ static int adi_pinctrl_probe(struct platform_device *pdev)
 	adi_pinmux_desc.npins = pinctrl->soc->npins;
 
 	/* Now register the pin controller and all pins it handles */
-	pinctrl->pctl = pinctrl_register(&adi_pinmux_desc, &pdev->dev, pinctrl);
+	pinctrl->pctl = devm_pinctrl_register(&pdev->dev, &adi_pinmux_desc,
+					      pinctrl);
 	if (IS_ERR(pinctrl->pctl)) {
 		dev_err(&pdev->dev, "could not register pinctrl ADI2 driver\n");
 		return PTR_ERR(pinctrl->pctl);
@@ -1069,18 +1070,8 @@ static int adi_pinctrl_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int adi_pinctrl_remove(struct platform_device *pdev)
-{
-	struct adi_pinctrl *pinctrl = platform_get_drvdata(pdev);
-
-	pinctrl_unregister(pinctrl->pctl);
-
-	return 0;
-}
-
 static struct platform_driver adi_pinctrl_driver = {
 	.probe		= adi_pinctrl_probe,
-	.remove		= adi_pinctrl_remove,
 	.driver		= {
 		.name	= DRIVER_NAME,
 	},
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:11 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:11 +0530
Subject: [PATCH 46/50] pinctrl: tb10x: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-47-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/pinctrl/pinctrl-tb10x.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-tb10x.c b/drivers/pinctrl/pinctrl-tb10x.c
index 6546b9b..170d3ee 100644
--- a/drivers/pinctrl/pinctrl-tb10x.c
+++ b/drivers/pinctrl/pinctrl-tb10x.c
@@ -806,7 +806,7 @@ static int tb10x_pinctrl_probe(struct platform_device *pdev)
 		}
 	}
 
-	state->pctl = pinctrl_register(&tb10x_pindesc, dev, state);
+	state->pctl = devm_pinctrl_register(dev, &tb10x_pindesc, state);
 	if (IS_ERR(state->pctl)) {
 		dev_err(dev, "could not register TB10x pin driver\n");
 		ret = PTR_ERR(state->pctl);
@@ -824,7 +824,6 @@ static int tb10x_pinctrl_remove(struct platform_device *pdev)
 {
 	struct tb10x_pinctrl *state = platform_get_drvdata(pdev);
 
-	pinctrl_unregister(state->pctl);
 	mutex_destroy(&state->mutex);
 
 	return 0;
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:15:57 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:45:57 +0530
Subject: [PATCH 32/50] pinctrl: vt8500: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-33-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and clean
the error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Lee Jones <lee.jones at linaro.org>
Cc: Heiko Stuebner <heiko at sntech.de>
Cc: Mika Westerberg <mika.westerberg at linux.intel.com>
Cc: Hongzhou Yang <hongzhou.yang at mediatek.com>
---
 drivers/pinctrl/vt8500/pinctrl-wmt.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/vt8500/pinctrl-wmt.c b/drivers/pinctrl/vt8500/pinctrl-wmt.c
index 5c261bf..159672b 100644
--- a/drivers/pinctrl/vt8500/pinctrl-wmt.c
+++ b/drivers/pinctrl/vt8500/pinctrl-wmt.c
@@ -583,7 +583,7 @@ int wmt_pinctrl_probe(struct platform_device *pdev,
 
 	data->dev = &pdev->dev;
 
-	data->pctl_dev = pinctrl_register(&wmt_desc, &pdev->dev, data);
+	data->pctl_dev = devm_pinctrl_register(&pdev->dev, &wmt_desc, data);
 	if (IS_ERR(data->pctl_dev)) {
 		dev_err(&pdev->dev, "Failed to register pinctrl\n");
 		return PTR_ERR(data->pctl_dev);
@@ -592,7 +592,7 @@ int wmt_pinctrl_probe(struct platform_device *pdev,
 	err = gpiochip_add_data(&data->gpio_chip, data);
 	if (err) {
 		dev_err(&pdev->dev, "could not add GPIO chip\n");
-		goto fail_gpio;
+		return ret;
 	}
 
 	err = gpiochip_add_pin_range(&data->gpio_chip, dev_name(data->dev),
@@ -606,8 +606,6 @@ int wmt_pinctrl_probe(struct platform_device *pdev,
 
 fail_range:
 	gpiochip_remove(&data->gpio_chip);
-fail_gpio:
-	pinctrl_unregister(data->pctl_dev);
 	return err;
 }
 
@@ -616,7 +614,6 @@ int wmt_pinctrl_remove(struct platform_device *pdev)
 	struct wmt_pinctrl_data *data = platform_get_drvdata(pdev);
 
 	gpiochip_remove(&data->gpio_chip);
-	pinctrl_unregister(data->pctl_dev);
 
 	return 0;
 }
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:15 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:15 +0530
Subject: [PATCH 50/50] pinctrl: zynq: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-51-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and
remove the need of .remove callback.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Michal Simek <michal.simek at xilinx.com>
Cc: S?ren Brinkmann <soren.brinkmann at xilinx.com>
Cc: linux-gpio at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
 drivers/pinctrl/pinctrl-zynq.c | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-zynq.c b/drivers/pinctrl/pinctrl-zynq.c
index 76f1abd..5bbf94c0 100644
--- a/drivers/pinctrl/pinctrl-zynq.c
+++ b/drivers/pinctrl/pinctrl-zynq.c
@@ -1195,7 +1195,7 @@ static int zynq_pinctrl_probe(struct platform_device *pdev)
 	pctrl->funcs = zynq_pmux_functions;
 	pctrl->nfuncs = ARRAY_SIZE(zynq_pmux_functions);
 
-	pctrl->pctrl = pinctrl_register(&zynq_desc, &pdev->dev, pctrl);
+	pctrl->pctrl = devm_pinctrl_register(&pdev->dev, &zynq_desc, pctrl);
 	if (IS_ERR(pctrl->pctrl))
 		return PTR_ERR(pctrl->pctrl);
 
@@ -1206,15 +1206,6 @@ static int zynq_pinctrl_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int zynq_pinctrl_remove(struct platform_device *pdev)
-{
-	struct zynq_pinctrl *pctrl = platform_get_drvdata(pdev);
-
-	pinctrl_unregister(pctrl->pctrl);
-
-	return 0;
-}
-
 static const struct of_device_id zynq_pinctrl_of_match[] = {
 	{ .compatible = "xlnx,pinctrl-zynq" },
 	{ }
@@ -1227,7 +1218,6 @@ static struct platform_driver zynq_pinctrl_driver = {
 		.of_match_table = zynq_pinctrl_of_match,
 	},
 	.probe = zynq_pinctrl_probe,
-	.remove = zynq_pinctrl_remove,
 };
 
 static int __init zynq_pinctrl_init(void)
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:08 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:08 +0530
Subject: [PATCH 43/50] pinctrl: pistachio: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-44-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/pinctrl/pinctrl-pistachio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-pistachio.c b/drivers/pinctrl/pinctrl-pistachio.c
index 856f736..adf526d 100644
--- a/drivers/pinctrl/pinctrl-pistachio.c
+++ b/drivers/pinctrl/pinctrl-pistachio.c
@@ -1457,8 +1457,8 @@ static int pistachio_pinctrl_probe(struct platform_device *pdev)
 	pistachio_pinctrl_desc.pins = pctl->pins;
 	pistachio_pinctrl_desc.npins = pctl->npins;
 
-	pctl->pctldev = pinctrl_register(&pistachio_pinctrl_desc, &pdev->dev,
-					 pctl);
+	pctl->pctldev = devm_pinctrl_register(&pdev->dev, &pistachio_pinctrl_desc,
+					      pctl);
 	if (IS_ERR(pctl->pctldev)) {
 		dev_err(&pdev->dev, "Failed to register pinctrl device\n");
 		return PTR_ERR(pctl->pctldev);
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:01 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:01 +0530
Subject: [PATCH 36/50] pinctrl: at91-pio4: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-37-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and clean
error path.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: linux-arm-kernel at lists.infradead.org
---
 drivers/pinctrl/pinctrl-at91-pio4.c | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c b/drivers/pinctrl/pinctrl-at91-pio4.c
index ee69db6..9d33ef5 100644
--- a/drivers/pinctrl/pinctrl-at91-pio4.c
+++ b/drivers/pinctrl/pinctrl-at91-pio4.c
@@ -1034,18 +1034,19 @@ static int atmel_pinctrl_probe(struct platform_device *pdev)
 		goto clk_prepare_enable_error;
 	}
 
-	atmel_pioctrl->pinctrl_dev = pinctrl_register(&atmel_pinctrl_desc,
-						      &pdev->dev,
-						      atmel_pioctrl);
-	if (!atmel_pioctrl->pinctrl_dev) {
+	atmel_pioctrl->pinctrl_dev = devm_pinctrl_register(&pdev->dev,
+							   &atmel_pinctrl_desc,
+							   atmel_pioctrl);
+	if (IS_ERR(atmel_pioctrl->pinctrl_dev)) {
+		ret = PTR_ERR(atmel_pioctrl->pinctrl_dev);
 		dev_err(dev, "pinctrl registration failed\n");
-		goto pinctrl_register_error;
+		goto clk_unprep;
 	}
 
 	ret = gpiochip_add_data(atmel_pioctrl->gpio_chip, atmel_pioctrl);
 	if (ret) {
 		dev_err(dev, "failed to add gpiochip\n");
-		goto gpiochip_add_error;
+		goto clk_unprep;
 	}
 
 	ret = gpiochip_add_pin_range(atmel_pioctrl->gpio_chip, dev_name(dev),
@@ -1059,15 +1060,15 @@ static int atmel_pinctrl_probe(struct platform_device *pdev)
 
 	return 0;
 
-clk_prepare_enable_error:
-	irq_domain_remove(atmel_pioctrl->irq_domain);
-pinctrl_register_error:
-	clk_disable_unprepare(atmel_pioctrl->clk);
-gpiochip_add_error:
-	pinctrl_unregister(atmel_pioctrl->pinctrl_dev);
 gpiochip_add_pin_range_error:
 	gpiochip_remove(atmel_pioctrl->gpio_chip);
 
+clk_unprep:
+	clk_disable_unprepare(atmel_pioctrl->clk);
+
+clk_prepare_enable_error:
+	irq_domain_remove(atmel_pioctrl->irq_domain);
+
 	return ret;
 }
 
@@ -1077,7 +1078,6 @@ int atmel_pinctrl_remove(struct platform_device *pdev)
 
 	irq_domain_remove(atmel_pioctrl->irq_domain);
 	clk_disable_unprepare(atmel_pioctrl->clk);
-	pinctrl_unregister(atmel_pioctrl->pinctrl_dev);
 	gpiochip_remove(atmel_pioctrl->gpio_chip);
 
 	return 0;
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:02 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:02 +0530
Subject: [PATCH 37/50] pinctrl: at91: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-38-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and remove
the need of .remove callback.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj at jcrosoft.com>
Cc: linux-arm-kernel at lists.infradead.org
---
 drivers/pinctrl/pinctrl-at91.c | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 523b6b7..f265ebe 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -1252,7 +1252,8 @@ static int at91_pinctrl_probe(struct platform_device *pdev)
 	}
 
 	platform_set_drvdata(pdev, info);
-	info->pctl = pinctrl_register(&at91_pinctrl_desc, &pdev->dev, info);
+	info->pctl = devm_pinctrl_register(&pdev->dev, &at91_pinctrl_desc,
+					   info);
 
 	if (IS_ERR(info->pctl)) {
 		dev_err(&pdev->dev, "could not register AT91 pinctrl driver\n");
@@ -1269,15 +1270,6 @@ static int at91_pinctrl_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int at91_pinctrl_remove(struct platform_device *pdev)
-{
-	struct at91_pinctrl *info = platform_get_drvdata(pdev);
-
-	pinctrl_unregister(info->pctl);
-
-	return 0;
-}
-
 static int at91_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
 {
 	struct at91_gpio_chip *at91_gpio = gpiochip_get_data(chip);
@@ -1821,7 +1813,6 @@ static struct platform_driver at91_pinctrl_driver = {
 		.of_match_table = at91_pinctrl_of_match,
 	},
 	.probe = at91_pinctrl_probe,
-	.remove = at91_pinctrl_remove,
 };
 
 static struct platform_driver * const drivers[] = {
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:12 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:12 +0530
Subject: [PATCH 47/50] pinctrl: tz1090-pdc: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-48-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and
remove the need of .remove callback.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/pinctrl/pinctrl-tz1090-pdc.c | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-tz1090-pdc.c b/drivers/pinctrl/pinctrl-tz1090-pdc.c
index b89ad3c..e70e362 100644
--- a/drivers/pinctrl/pinctrl-tz1090-pdc.c
+++ b/drivers/pinctrl/pinctrl-tz1090-pdc.c
@@ -947,7 +947,8 @@ static int tz1090_pdc_pinctrl_probe(struct platform_device *pdev)
 	if (IS_ERR(pmx->regs))
 		return PTR_ERR(pmx->regs);
 
-	pmx->pctl = pinctrl_register(&tz1090_pdc_pinctrl_desc, &pdev->dev, pmx);
+	pmx->pctl = devm_pinctrl_register(&pdev->dev, &tz1090_pdc_pinctrl_desc,
+					  pmx);
 	if (IS_ERR(pmx->pctl)) {
 		dev_err(&pdev->dev, "Couldn't register pinctrl driver\n");
 		return PTR_ERR(pmx->pctl);
@@ -960,15 +961,6 @@ static int tz1090_pdc_pinctrl_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int tz1090_pdc_pinctrl_remove(struct platform_device *pdev)
-{
-	struct tz1090_pdc_pmx *pmx = platform_get_drvdata(pdev);
-
-	pinctrl_unregister(pmx->pctl);
-
-	return 0;
-}
-
 static const struct of_device_id tz1090_pdc_pinctrl_of_match[] = {
 	{ .compatible = "img,tz1090-pdc-pinctrl", },
 	{ },
@@ -980,7 +972,6 @@ static struct platform_driver tz1090_pdc_pinctrl_driver = {
 		.of_match_table	= tz1090_pdc_pinctrl_of_match,
 	},
 	.probe	= tz1090_pdc_pinctrl_probe,
-	.remove	= tz1090_pdc_pinctrl_remove,
 };
 
 static int __init tz1090_pdc_pinctrl_init(void)
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:13 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:13 +0530
Subject: [PATCH 48/50] pinctrl: tz1090 Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-49-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and
remove the need of .remove callback.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/pinctrl/pinctrl-tz1090.c | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-tz1090.c b/drivers/pinctrl/pinctrl-tz1090.c
index 5425299..04cbe53 100644
--- a/drivers/pinctrl/pinctrl-tz1090.c
+++ b/drivers/pinctrl/pinctrl-tz1090.c
@@ -1962,7 +1962,8 @@ static int tz1090_pinctrl_probe(struct platform_device *pdev)
 	if (IS_ERR(pmx->regs))
 		return PTR_ERR(pmx->regs);
 
-	pmx->pctl = pinctrl_register(&tz1090_pinctrl_desc, &pdev->dev, pmx);
+	pmx->pctl = devm_pinctrl_register(&pdev->dev, &tz1090_pinctrl_desc,
+					  pmx);
 	if (IS_ERR(pmx->pctl)) {
 		dev_err(&pdev->dev, "Couldn't register pinctrl driver\n");
 		return PTR_ERR(pmx->pctl);
@@ -1975,15 +1976,6 @@ static int tz1090_pinctrl_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int tz1090_pinctrl_remove(struct platform_device *pdev)
-{
-	struct tz1090_pmx *pmx = platform_get_drvdata(pdev);
-
-	pinctrl_unregister(pmx->pctl);
-
-	return 0;
-}
-
 static const struct of_device_id tz1090_pinctrl_of_match[] = {
 	{ .compatible = "img,tz1090-pinctrl", },
 	{ },
@@ -1995,7 +1987,6 @@ static struct platform_driver tz1090_pinctrl_driver = {
 		.of_match_table	= tz1090_pinctrl_of_match,
 	},
 	.probe	= tz1090_pinctrl_probe,
-	.remove	= tz1090_pinctrl_remove,
 };
 
 static int __init tz1090_pinctrl_init(void)
-- 
2.1.4



From ldewangan at nvidia.com  Wed Feb 24 05:16:14 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 18:46:14 +0530
Subject: [PATCH 49/50] pinctrl: u300: Use devm_pinctrl_register() for pinctrl
 registration
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456319775-3216-50-git-send-email-ldewangan@nvidia.com>

Use devm_pinctrl_register() for pin control registration and
remove the need of .remove callback.

Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
---
 drivers/pinctrl/pinctrl-u300.c | 12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-u300.c b/drivers/pinctrl/pinctrl-u300.c
index c076021..d1af908 100644
--- a/drivers/pinctrl/pinctrl-u300.c
+++ b/drivers/pinctrl/pinctrl-u300.c
@@ -1067,7 +1067,7 @@ static int u300_pmx_probe(struct platform_device *pdev)
 	if (IS_ERR(upmx->virtbase))
 		return PTR_ERR(upmx->virtbase);
 
-	upmx->pctl = pinctrl_register(&u300_pmx_desc, &pdev->dev, upmx);
+	upmx->pctl = devm_pinctrl_register(&pdev->dev, &u300_pmx_desc, upmx);
 	if (IS_ERR(upmx->pctl)) {
 		dev_err(&pdev->dev, "could not register U300 pinmux driver\n");
 		return PTR_ERR(upmx->pctl);
@@ -1080,15 +1080,6 @@ static int u300_pmx_probe(struct platform_device *pdev)
 	return 0;
 }
 
-static int u300_pmx_remove(struct platform_device *pdev)
-{
-	struct u300_pmx *upmx = platform_get_drvdata(pdev);
-
-	pinctrl_unregister(upmx->pctl);
-
-	return 0;
-}
-
 static const struct of_device_id u300_pinctrl_match[] = {
 	{ .compatible = "stericsson,pinctrl-u300" },
 	{},
@@ -1101,7 +1092,6 @@ static struct platform_driver u300_pmx_driver = {
 		.of_match_table = u300_pinctrl_match,
 	},
 	.probe = u300_pmx_probe,
-	.remove = u300_pmx_remove,
 };
 
 static int __init u300_pmx_init(void)
-- 
2.1.4



From matthias.bgg at gmail.com  Wed Feb 24 05:36:15 2016
From: matthias.bgg at gmail.com (Matthias Brugger)
Date: Wed, 24 Feb 2016 14:36:15 +0100
Subject: [PATCH 13/50] pinctrl: mtk-common: Use devm_pinctrl_register()
 for pinctrl registration
In-Reply-To: <1456319775-3216-14-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-14-git-send-email-ldewangan@nvidia.com>
Message-ID: <56CDB1CF.6000007@gmail.com>



On 24/02/16 14:15, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration and clean
> the error path.
>
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Matthias Brugger <matthias.bgg at gmail.com>
> Cc: Hongzhou Yang <hongzhou.yang at mediatek.com>
> Cc: Yingjoe Chen <yingjoe.chen at mediatek.com>
> ---

Reviewed-by: Matthias Brugger <matthias.bgg at gmail.com>

>   drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 17 ++++++-----------
>   1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> index ddc9217..194413d 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> @@ -1390,17 +1390,16 @@ int mtk_pctrl_init(struct platform_device *pdev,
>   	pctl->pctl_desc.pmxops = &mtk_pmx_ops;
>   	pctl->dev = &pdev->dev;
>
> -	pctl->pctl_dev = pinctrl_register(&pctl->pctl_desc, &pdev->dev, pctl);
> +	pctl->pctl_dev = devm_pinctrl_register(&pdev->dev, &pctl->pctl_desc,
> +					       pctl);
>   	if (IS_ERR(pctl->pctl_dev)) {
>   		dev_err(&pdev->dev, "couldn't register pinctrl driver\n");
>   		return PTR_ERR(pctl->pctl_dev);
>   	}
>
>   	pctl->chip = devm_kzalloc(&pdev->dev, sizeof(*pctl->chip), GFP_KERNEL);
> -	if (!pctl->chip) {
> -		ret = -ENOMEM;
> -		goto pctrl_error;
> -	}
> +	if (!pctl->chip)
> +		return -ENOMEM;
>
>   	*pctl->chip = mtk_gpio_chip;
>   	pctl->chip->ngpio = pctl->devdata->npins;
> @@ -1409,10 +1408,8 @@ int mtk_pctrl_init(struct platform_device *pdev,
>   	pctl->chip->base = -1;
>
>   	ret = gpiochip_add_data(pctl->chip, pctl);
> -	if (ret) {
> -		ret = -EINVAL;
> -		goto pctrl_error;
> -	}
> +	if (ret)
> +		return -EINVAL;
>
>   	/* Register the GPIO to pin mappings. */
>   	ret = gpiochip_add_pin_range(pctl->chip, dev_name(&pdev->dev),
> @@ -1490,8 +1487,6 @@ int mtk_pctrl_init(struct platform_device *pdev,
>
>   chip_error:
>   	gpiochip_remove(pctl->chip);
> -pctrl_error:
> -	pinctrl_unregister(pctl->pctl_dev);
>   	return ret;
>   }
>
>


From heiko at sntech.de  Wed Feb 24 05:37:05 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Wed, 24 Feb 2016 14:37:05 +0100
Subject: [PATCH 0/2] ARM: dts: rockchip: fix some interrupts on rk3288
In-Reply-To: <1456234860-18832-1-git-send-email-john@metanate.com>
References: <1456234860-18832-1-git-send-email-john@metanate.com>
Message-ID: <2022698.P5dgKXtQhu@phil>

Am Dienstag, 23. Februar 2016, 13:40:58 schrieb John Keeping:
> None of these are used by drivers so these don't fix any bugs but maybe
> they'll save someone debugging time in the future.
> 
> John Keeping (2):
>   ARM: dts: rockchip: fix MIPI interrupt on rk3288
>   ARM: dts: rockchip: fix audio interrupts on rk3288

applied both to my dts32 branch for 4.6 after verifying against the TRM as 
well.

Thanks for catching these
Heiko


From robin.murphy at arm.com  Wed Feb 24 05:38:56 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 24 Feb 2016 13:38:56 +0000
Subject: [PATCH V2] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <56CCF198.3090409@caviumnetworks.com>
References: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>
 <56CC4E48.1060103@arm.com> <56CCF198.3090409@caviumnetworks.com>
Message-ID: <56CDB270.7040706@arm.com>

On 23/02/16 23:56, Tirumalesh Chalamarla wrote:
>
>
> On 02/23/2016 04:19 AM, Robin Murphy wrote:
>> On 18/02/16 18:29, tchalamarla at caviumnetworks.com wrote:
>>> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>>>
>>> Due to Errata#27704 CN88xx SMMUv2,supports  only shared ASID and VMID
>>> namespaces; specifically within a given node SMMU0 and SMMU1 share,
>>> as does SMMU2 and SMMU3.
>>>
>>> This patch tries to address these issuee by supplying asid and vmid
>>> base from devicetree.
>>>
>>> changes from V1:
>>>     - rebased on top of 16 bit VMID patch
>>>     - removed redundent options from DT
>>>     - insted of transform, DT now supplies starting ASID/VMID
>>>
>>> Signed-off-by: Akula Geethasowjanya
>>> <Geethasowjanya.Akula at caviumnetworks.com>
>>> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>>> ---
>>>   .../devicetree/bindings/iommu/arm,smmu.txt         |  8 +++++
>>>   drivers/iommu/arm-smmu.c                           | 37
>>> +++++++++++++++-------
>>>   2 files changed, 34 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>>> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>>> index bb7e569..80b8484 100644
>>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>>> @@ -57,6 +57,14 @@ conditions.
>>>
>>>   - smmu-enable-vmid16 : Enable 16 bit VMID, if allowed.
>>>
>>> +- asid-base :    Buggy SMMUv2 implementations which doesn't satisfy the
>>> +        ASID namespace needs, use this field to specify starting
>>> +        ASID for the SMMU.
>>> +
>>> +- vmid-base :    Buggy SMMUv2 implementations which doesn't satisfy
>>> the VMID
>>> +        namespace needs, use this field to specify starting VMID
>>> +        for the SMMU.
>>> +
>>
>>  From how you've described the situation, this is still just some
>> arbitrary number for the sake of a driver workaround and not an actual
>> property of the hardware. Either way there should be a proper compatible
>> string for this implementation, e.g. something like "cavium,cn88xx-smmu".
>>
>> Given that, you then shouldn't actually need anything else, because you
>> can simply keep track of how many Cavium SMMUs have been probed and
>> automatically generate a suitable offset, e.g. (smmu->index *
>> ARM_SMMU_MAX_CBS) to ensure global ASID/VMID uniqueness.
>
> This particular solution might not be accurate in all cases. what
> happens if SMMU stage 1 is used by a guest?

Even if we supported passing through stage 1 contexts, which we don't, a 
malicious guest can freely ignore your arbitrary numbers in the DT, put 
whatever nonsense it feels like in the TTBRs, and corrupt I/O in other 
guests and/or the host.

You cannot safely pass through raw stage 1 contexts on this hardware, so 
it's a non-issue.

Robin.

>>>   Example:
>>>
>>>           smmu {
>>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>>> index 003c442..dc46b9a 100644
>>> --- a/drivers/iommu/arm-smmu.c
>>> +++ b/drivers/iommu/arm-smmu.c
>>> @@ -320,6 +320,9 @@ struct arm_smmu_device {
>>>       unsigned long            ipa_size;
>>>       unsigned long            pa_size;
>>>
>>> +    u32                asid_base;
>>> +    u32                vmid_base;
>>> +
>>>       u32                num_global_irqs;
>>>       u32                num_context_irqs;
>>>       unsigned int            *irqs;
>>> @@ -335,8 +338,8 @@ struct arm_smmu_cfg {
>>>   };
>>>   #define INVALID_IRPTNDX            0xff
>>>
>>> -#define ARM_SMMU_CB_ASID(cfg)        ((cfg)->cbndx)
>>> -#define ARM_SMMU_CB_VMID(cfg)        ((cfg)->cbndx + 1)
>>> +#define ARM_SMMU_CB_ASID(smmu, cfg)    ((u16)((smmu)->asid_base +
>>> (cfg)->cbndx))
>>> +#define ARM_SMMU_CB_VMID(smmu, cfg)    ((u16)((smmu)->vmid_base +
>>> (cfg)->cbndx))
>>>
>>>   enum arm_smmu_domain_stage {
>>>       ARM_SMMU_DOMAIN_S1 = 0,
>>> @@ -576,11 +579,11 @@ static void arm_smmu_tlb_inv_context(void *cookie)
>>>
>>>       if (stage1) {
>>>           base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
>>> -        writel_relaxed(ARM_SMMU_CB_ASID(cfg),
>>> +        writel_relaxed(ARM_SMMU_CB_ASID(smmu, cfg),
>>>                      base + ARM_SMMU_CB_S1_TLBIASID);
>>>       } else {
>>>           base = ARM_SMMU_GR0(smmu);
>>> -        writel_relaxed(ARM_SMMU_CB_VMID(cfg),
>>> +        writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg),
>>>                      base + ARM_SMMU_GR0_TLBIVMID);
>>>       }
>>>
>>> @@ -602,7 +605,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned
>>> long iova, size_t size,
>>>
>>>           if (!IS_ENABLED(CONFIG_64BIT) || smmu->version ==
>>> ARM_SMMU_V1) {
>>>               iova &= ~12UL;
>>> -            iova |= ARM_SMMU_CB_ASID(cfg);
>>> +            iova |= ARM_SMMU_CB_ASID(smmu, cfg);
>>>               do {
>>>                   writel_relaxed(iova, reg);
>>>                   iova += granule;
>>> @@ -610,7 +613,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned
>>> long iova, size_t size,
>>>   #ifdef CONFIG_64BIT
>>>           } else {
>>>               iova >>= 12;
>>> -            iova |= (u64)ARM_SMMU_CB_ASID(cfg) << 48;
>>> +            iova |= (u64)ARM_SMMU_CB_ASID(smmu, cfg) << 48;
>>>               do {
>>>                   writeq_relaxed(iova, reg);
>>>                   iova += granule >> 12;
>>> @@ -630,7 +633,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned
>>> long iova, size_t size,
>>>   #endif
>>>       } else {
>>>           reg = ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_TLBIVMID;
>>> -        writel_relaxed(ARM_SMMU_CB_VMID(cfg), reg);
>>> +        writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg), reg);
>>>       }
>>>   }
>>>
>>> @@ -744,7 +747,7 @@ static void arm_smmu_init_context_bank(struct
>>> arm_smmu_domain *smmu_domain,
>>>   #endif
>>>           /* if 16bit VMID required set VMID in CBA2R */
>>>           if (smmu->options & ARM_SMMU_OPT_ENABLE_VMID16)
>>> -            reg |= ARM_SMMU_CB_VMID(cfg) << CBA2R_VMID_SHIFT;
>>> +            reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBA2R_VMID_SHIFT;
>>>
>>>           writel_relaxed(reg, gr1_base +
>>> ARM_SMMU_GR1_CBA2R(cfg->cbndx));
>>>       }
>>> @@ -763,7 +766,7 @@ static void arm_smmu_init_context_bank(struct
>>> arm_smmu_domain *smmu_domain,
>>>               (CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
>>>       } else if (!(smmu->options & ARM_SMMU_OPT_ENABLE_VMID16)) {
>>>           /*16 bit VMID is not enabled set 8 bit VMID here */
>>> -        reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
>>> +        reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBAR_VMID_SHIFT;
>>>       }
>>>       writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
>>>
>>> @@ -771,11 +774,11 @@ static void arm_smmu_init_context_bank(struct
>>> arm_smmu_domain *smmu_domain,
>>>       if (stage1) {
>>>           reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>>>
>>> -        reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
>>> +        reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) <<
>>> TTBRn_ASID_SHIFT;
>>>           smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR0);
>>>
>>>           reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
>>> -        reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
>>> +        reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) <<
>>> TTBRn_ASID_SHIFT;
>>>           smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR1);
>>>       } else {
>>>           reg64 = pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
>>> @@ -1812,6 +1815,18 @@ static int arm_smmu_device_dt_probe(struct
>>> platform_device *pdev)
>>>
>>>       parse_driver_options(smmu);
>>>
>>> +    if (of_property_read_u32(dev->of_node, "#asid-base",
>>> +                 &smmu->asid_base)) {
>>> +        smmu->asid_base = 0;
>>> +    }
>>> +
>>> +    if (of_property_read_u32(dev->of_node, "#vmid-base",
>>> +                 &smmu->vmid_base)) {
>>> +        smmu->vmid_base = 1;
>>> +    }
>>> +    if (smmu->vmid_base == 0)
>>> +        smmu->vmid_base = 1;
>>> +
>>>       if (smmu->version > ARM_SMMU_V1 &&
>>>           smmu->num_context_banks != smmu->num_context_irqs) {
>>>           dev_err(dev,
>>>
>>
>



From will.deacon at arm.com  Wed Feb 24 05:40:16 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Feb 2016 13:40:16 +0000
Subject: [PATCH v3] arm64: Add workaround for Cavium erratum 27456
In-Reply-To: <1456272534-21692-1-git-send-email-ddaney.cavm@gmail.com>
References: <1456272534-21692-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <20160224134016.GH28310@arm.com>

On Tue, Feb 23, 2016 at 04:08:54PM -0800, David Daney wrote:
> From: Andrew Pinski <apinski at cavium.com>
> 
> On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
> instructions may cause the icache to become corrupted if it contains
> data for a non-current ASID.
> 
> This patch implements the workaround (which flushes the local icache
> when switching the mm) by using code patching.
> 
> Signed-off-by: Andrew Pinski <apinski at cavium.com>
> Signed-off-by: David Daney <david.daney at cavium.com>
> ---
>  Documentation/arm64/silicon-errata.txt |  1 +
>  arch/arm64/Kconfig                     | 11 +++++++++++
>  arch/arm64/include/asm/cpufeature.h    |  3 ++-
>  arch/arm64/kernel/cpu_errata.c         |  9 +++++++++
>  arch/arm64/mm/proc.S                   | 12 ++++++++++++
>  5 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
> index 58b71dd..ba4b6ac 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -56,3 +56,4 @@ stable kernels.
>  |                |                 |                 |                         |
>  | Cavium         | ThunderX ITS    | #22375, #24313  | CAVIUM_ERRATUM_22375    |
>  | Cavium         | ThunderX GICv3  | #23154          | CAVIUM_ERRATUM_23154    |
> +| Cavium         | ThunderX Core   | #27456          | CAVIUM_ERRATUM_27456    |
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 8cc6228..39f2203 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -432,6 +432,17 @@ config CAVIUM_ERRATUM_23154
>  
>  	  If unsure, say Y.
>  
> +config CAVIUM_ERRATUM_27456
> +	bool "Cavium erratum 27456: Broadcast TLBI instructions may cause the icache corruption"

Doesn't really make sense. Maybe just drop the "the"?

> +	default y
> +	help
> +	  On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
> +	  instructions may cause the icache to become corrupted if it
> +	  contains data for a non-current ASID.  The fix is to flush
> +	  the icache when changing the mm context.

s/flush/invalidate/

Anyway, the rest of the patch looks fine. I still don't have a good idea
as to whether or not KVM is affected by this, but I guess that's your
problem, so:

Reviewed-by: Will Deacon <will.deacon at arm.com>

(and Catalin, if you pick this up, watch out for the conflicts in
cpufeature.h)

Will


From balbi at kernel.org  Wed Feb 24 05:40:32 2016
From: balbi at kernel.org (Felipe Balbi)
Date: Wed, 24 Feb 2016 15:40:32 +0200
Subject: [PATCH 0/2] usb: dwc2: Remove host and gadget only code from core
In-Reply-To: <56CC26ED.50004@synopsys.com>
References: <cover.1456213319.git.johnyoun@synopsys.com>
 <56CC26ED.50004@synopsys.com>
Message-ID: <87mvqqjkfj.fsf@ti.com>


Hi,

John Youn <John.Youn at synopsys.com> writes:
> On 2/23/2016 12:35 AM, John Youn wrote:
>> This series moves the host/gadget-specific code from core.c to hcd.c
>> and gadget.c so that they will be compiled only when their respective
>> configurations are selected, or in DRD.
>> 
>> This is mostly just a straight move of the code. I have also added
>> some comments to group related functions together.
>> 
>> Compiled and tested in all three modes.
>> 
>> This should also solve the issue reported here:
>> http://marc.info/?l=linux-usb&m=145591813410106&w=2
>> 
>> Although I wasn't able to test it... couldn't figure out how to
>> disable CONFIG_USB and enable DWC2 in gadget mode.
>> 
>> Felipe,
>> 
>> This should be applied after Doug's series on your testing/next
>> branch.
>> 
>> 
>
> Hi Felipe,
>
> Patch 2/2 is triggering our corporate mail filters however I try to
> send it. I'll look into this with IT tomorrow, maybe have to send it
> from another account.

okay, I don't have patch 2/2. 1/2 is now in testing/next

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/0164cfa4/attachment-0001.sig>

From baruch at tkos.co.il  Wed Feb 24 05:42:19 2016
From: baruch at tkos.co.il (Baruch Siach)
Date: Wed, 24 Feb 2016 15:42:19 +0200
Subject: [PATCH 38/50] pinctrl: digicolor: Use devm_pinctrl_register()
 for pinctrl registration
In-Reply-To: <1456319775-3216-39-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-39-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160224134219.GI2225@tarshish>

Hi Laxman Dewangan,

On Wed, Feb 24, 2016 at 06:46:03PM +0530, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration and clean
> error path.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Baruch Siach <baruch at tkos.co.il>
> ---
>  drivers/pinctrl/pinctrl-digicolor.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-digicolor.c b/drivers/pinctrl/pinctrl-digicolor.c
> index f1343d6..c18014d 100644
> --- a/drivers/pinctrl/pinctrl-digicolor.c
> +++ b/drivers/pinctrl/pinctrl-digicolor.c
> @@ -326,17 +326,15 @@ static int dc_pinctrl_probe(struct platform_device *pdev)
>  
>  	pmap->dev = &pdev->dev;
>  
> -	pmap->pctl = pinctrl_register(pctl_desc, &pdev->dev, pmap);
> +	pmap->pctl = devm_pinctrl_register(&pdev->dev, pctl_desc, pmap);
>  	if (IS_ERR(pmap->pctl)) {
>  		dev_err(&pdev->dev, "pinctrl driver registration failed\n");
>  		return PTR_ERR(pmap->pctl);
>  	}
>  
>  	ret = dc_gpiochip_add(pmap, pdev->dev.of_node);
> -	if (ret < 0) {
> -		pinctrl_unregister(pmap->pctl);
> +	if (ret < 0)
>  		return ret;
> -	}
>  
>  	return 0;

Please simplify even more to just:

   return dc_gpiochip_add(pmap, pdev->dev.of_node);

and remove the no longer used 'ret' variable.

Thanks,
baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -


From marc.zyngier at arm.com  Wed Feb 24 05:42:27 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Feb 2016 13:42:27 +0000
Subject: [PATCH v13 15/20] KVM: ARM64: Add PMU overflow interrupt routing
In-Reply-To: <56CDAF7A.3080505@linaro.org>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
 <1456290520-10012-16-git-send-email-zhaoshenglong@huawei.com>
 <20160224122718.GD18451@cbox> <56CDADFD.10805@arm.com>
 <56CDAF7A.3080505@linaro.org>
Message-ID: <56CDB343.2090309@arm.com>

On 24/02/16 13:26, Shannon Zhao wrote:
> 
> 
> On 2016/2/24 21:19, Marc Zyngier wrote:
>> On 24/02/16 12:27, Christoffer Dall wrote:
>>>> On Wed, Feb 24, 2016 at 01:08:35PM +0800, Shannon Zhao wrote:
>>>>>> From: Shannon Zhao<shannon.zhao at linaro.org>
>>>>>>
>>>>>> When calling perf_event_create_kernel_counter to create perf_event,
>>>>>> assign a overflow handler. Then when the perf event overflows, set the
>>>>>> corresponding bit of guest PMOVSSET register. If this counter is enabled
>>>>>> and its interrupt is enabled as well, kick the vcpu to sync the
>>>>>> interrupt.
>>>>>>
>>>>>> On VM entry, if there is counter overflowed, inject the interrupt with
>>>>>> the level set to 1. Otherwise, inject the interrupt with the level set
>>>>>> to 0.
>>>>>>
>>>>>> Signed-off-by: Shannon Zhao<shannon.zhao at linaro.org>
>>>>>> Reviewed-by: Marc Zyngier<marc.zyngier at arm.com>
>>>>>> Reviewed-by: Andrew Jones<drjones at redhat.com>
>>>>>> ---
>>>>>>  arch/arm/kvm/arm.c    |  2 ++
>>>>>>  include/kvm/arm_pmu.h |  3 +++
>>>>>>  virt/kvm/arm/pmu.c    | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++-
>>>>>>  3 files changed, 55 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>>>>> index dda1959..f54264c 100644
>>>>>> --- a/arch/arm/kvm/arm.c
>>>>>> +++ b/arch/arm/kvm/arm.c
>>>>>> @@ -28,6 +28,7 @@
>>>>>>  #include <linux/sched.h>
>>>>>>  #include <linux/kvm.h>
>>>>>>  #include <trace/events/kvm.h>
>>>>>> +#include <kvm/arm_pmu.h>
>>>>>>
>>>>>>  #define CREATE_TRACE_POINTS
>>>>>>  #include "trace.h"
>>>>>> @@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>>>>>>  		 * non-preemptible context.
>>>>>>  		 */
>>>>>>  		preempt_disable();
>>>>>> +		kvm_pmu_flush_hwstate(vcpu);
>>>>>>  		kvm_timer_flush_hwstate(vcpu);
>>>>>>  		kvm_vgic_flush_hwstate(vcpu);
>>>>>>
>>>>>> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
>>>>>> index 8bc92d1..0aed4d4 100644
>>>>>> --- a/include/kvm/arm_pmu.h
>>>>>> +++ b/include/kvm/arm_pmu.h
>>>>>> @@ -35,6 +35,7 @@ struct kvm_pmu {
>>>>>>  	int irq_num;
>>>>>>  	struct kvm_pmc pmc[ARMV8_PMU_MAX_COUNTERS];
>>>>>>  	bool ready;
>>>>>> +	bool irq_level;
>>>>>>  };
>>>>>>
>>>>>>  #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
>>>>>> @@ -44,6 +45,7 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
>>>>>>  void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
>>>>>>  void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
>>>>>>  void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
>>>>>> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
>>>>>>  void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
>>>>>>  void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
>>>>>>  void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>>>>>> @@ -67,6 +69,7 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
>>>>>>  static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>>>>>>  static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>>>>>>  static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
>>>>>> +static inline void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
>>>>>>  static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
>>>>>>  static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
>>>>>>  static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
>>>>>> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
>>>>>> index cda869c..1cd4214 100644
>>>>>> --- a/virt/kvm/arm/pmu.c
>>>>>> +++ b/virt/kvm/arm/pmu.c
>>>>>> @@ -21,6 +21,7 @@
>>>>>>  #include <linux/perf_event.h>
>>>>>>  #include <asm/kvm_emulate.h>
>>>>>>  #include <kvm/arm_pmu.h>
>>>>>> +#include <kvm/arm_vgic.h>
>>>>>>
>>>>>>  /**
>>>>>>   * kvm_pmu_get_counter_value - get PMU counter value
>>>>>> @@ -181,6 +182,53 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
>>>>>>  }
>>>>>>
>>>>>>  /**
>>>>>> + * kvm_pmu_flush_hwstate - flush pmu state to cpu
>>>>>> + * @vcpu: The vcpu pointer
>>>>>> + *
>>>>>> + * Inject virtual PMU IRQ if IRQ is pending for this cpu.
>>>>>> + */
>>>>>> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
>>>>>> +{
>>>>>> +	struct kvm_pmu *pmu = &vcpu->arch.pmu;
>>>>>> +	bool overflow;
>>>>>> +
>>>>>> +	if (!kvm_arm_pmu_v3_ready(vcpu))
>>>>>> +		return;
>>>>>> +
>>>>>> +	overflow = !!kvm_pmu_overflow_status(vcpu);
>>>>>> +	if (pmu->irq_level != overflow) {
>>>>>> +		pmu->irq_level = overflow;
>>>>>> +		kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
>>>>>> +				    pmu->irq_num, overflow);
>>>>>> +	}
>>>>
>>>> a consequence of only doing this on flush and not checking if the input
>>>> to the vgic should be adjusted on sync is that if you exit the guest
>>>> because the guest does a 'wfi', for example, and you entered with the
>>>> overflow interrupt set, then kvm_arch_vcpu_runnable() will return true,
>>>> and the VCPU will not block but will run anyway.
>>>>
>>>> Maybe not a big deal, but I think we might as well check the overflow
>>>> status on sync (coming back from the VM) and reset the line at that time
>>>> so that we have a 'more up to date' view of the interrupt line after
>>>> exiting a vcpu.
>> That's a very good point. I can definitely imagine pathological
>> behaviours if the guest otherwise relies on the overflow interrupt
>> triggering.
>>
>> Shannon, can you please address this?
> 
> Sure. So on sync we only update the irq level if the overflow status is 
> changed like what we do on flush, right?

Exactly. You can probably create a helper function for that.

> BTW, to reduce email traffic, I want to only update this patch, is this 
> fine?

Works for me.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From boris.brezillon at free-electrons.com  Wed Feb 24 05:57:50 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Wed, 24 Feb 2016 14:57:50 +0100
Subject: [PATCH RESEND] gpmi-nand: Handle ECC Errors in erased pages
In-Reply-To: <1456059126-25469-1-git-send-email-mpa@pengutronix.de>
References: <1456059126-25469-1-git-send-email-mpa@pengutronix.de>
Message-ID: <20160224145750.21050def@bbrezillon>

Hi Markus,

On Sun, 21 Feb 2016 13:52:06 +0100
Markus Pargmann <mpa at pengutronix.de> wrote:

> ECC is only calculated for written pages. As erased pages are not
> actively written the ECC is always invalid. For this purpose the
> Hardware BCH unit is able to check for erased pages and does not raise
> an ECC error in this case. This behaviour can be influenced using the
> BCH_MODE register which sets the number of allowed bitflips in an erased
> page. Unfortunately the unit is not capable of fixing the bitflips in
> memory.
> 
> To avoid complete software checks for erased pages, we can simply check
> buffers with uncorrectable ECC errors because we know that any erased
> page with errors is uncorrectable by the BCH unit.
> 
> This patch adds the generic nand_check_erased_ecc_chunk() to gpmi-nand
> to correct erased pages. To have the valid data in the buffer before
> using them, this patch moves the read_page_swap_end() call before the
> ECC status checking for-loop.
> 
> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
> ---
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 49 ++++++++++++++++++++++++++++++----
>  1 file changed, 44 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> index 235ddcb58f39..ce5a21252102 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -1035,14 +1035,58 @@ static int gpmi_ecc_read_page(struct mtd_info *mtd, struct nand_chip *chip,
>  	/* Loop over status bytes, accumulating ECC status. */
>  	status = auxiliary_virt + nfc_geo->auxiliary_status_offset;
>  
> +	read_page_swap_end(this, buf, nfc_geo->payload_size,
> +			   this->payload_virt, this->payload_phys,
> +			   nfc_geo->payload_size,
> +			   payload_virt, payload_phys);
> +
>  	for (i = 0; i < nfc_geo->ecc_chunk_count; i++, status++) {
>  		if ((*status == STATUS_GOOD) || (*status == STATUS_ERASED))
>  			continue;
>  
>  		if (*status == STATUS_UNCORRECTABLE) {
> +			int flips;
> +
> +			/*
> +			 * The ECC hardware has an uncorrectable ECC status
> +			 * code in case we have bitflips in an erased page. As
> +			 * nothing was written into this subpage the ECC is
> +			 * obviously wrong and we can not trust it. We assume
> +			 * at this point that we are reading an erased page and
> +			 * try to correct the bitflips in buffer up to
> +			 * ecc_strength bitflips. If this is a page with random
> +			 * data, we exceed this number of bitflips and have a
> +			 * ECC failure. Otherwise we use the corrected buffer.
> +			 */
> +			if (i == 0) {
> +				/* The first block includes metadata */
> +				flips = nand_check_erased_ecc_chunk(
> +						buf + i * nfc_geo->ecc_chunk_size,
> +						nfc_geo->ecc_chunk_size,
> +						NULL, 0,
> +						auxiliary_virt,
> +						nfc_geo->metadata_size,
> +						nfc_geo->ecc_strength);
> +			} else {
> +				flips = nand_check_erased_ecc_chunk(
> +						buf + i * nfc_geo->ecc_chunk_size,
> +						nfc_geo->ecc_chunk_size,
> +						NULL, 0,
> +						NULL, 0,
> +						nfc_geo->ecc_strength);
> +			}

You're not checking ECC bytes. I know it's a bit more complicated to
implement, but as Brian stated several times, you should always check
ECC bytes along with data bytes when testing for an erased chunk.

Indeed, it might appear that the user really programmed ff on the page,
and in this case you don't want to consider the page as erased.
In this case, the ECC bytes will be different from ff, and you'll
be able to identify it by checking those ECC bytes.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


From geert at linux-m68k.org  Wed Feb 24 05:59:44 2016
From: geert at linux-m68k.org (Geert Uytterhoeven)
Date: Wed, 24 Feb 2016 14:59:44 +0100
Subject: [PATCH 25/50] pinctrl: ish-pfc: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-26-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-26-git-send-email-ldewangan@nvidia.com>
Message-ID: <CAMuHMdVBjn02J1tAwXb7XQKQa3jk=D4LX-f-1cZ2wsjc3Gfxqw@mail.gmail.com>

Hi Laxman,

On Wed, Feb 24, 2016 at 2:15 PM, Laxman Dewangan <ldewangan at nvidia.com> wrote:
> Use devm_pinctrl_register() for pin control registration.
>
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> Cc: Geert Uytterhoeven <geert+renesas at glider.be>
> Cc: linux-renesas-soc at vger.kernel.org

Thanks for your patch!

> index 87b0a59..f17b5fc 100644
> --- a/drivers/pinctrl/sh-pfc/pinctrl.c
> +++ b/drivers/pinctrl/sh-pfc/pinctrl.c
> @@ -692,19 +692,9 @@ int sh_pfc_register_pinctrl(struct sh_pfc *pfc)
>         pmx->pctl_desc.pins = pmx->pins;
>         pmx->pctl_desc.npins = pfc->info->nr_pins;
>
> -       pmx->pctl = pinctrl_register(&pmx->pctl_desc, pfc->dev, pmx);
> +       pmx->pctl = devm_pinctrl_register(pfc->dev, &pmx->pctl_desc, pmx);
>         if (IS_ERR(pmx->pctl))
>                 return PTR_ERR(pmx->pctl);
>
>         return 0;
>  }
> -
> -int sh_pfc_unregister_pinctrl(struct sh_pfc *pfc)
> -{
> -       struct sh_pfc_pinctrl *pmx = pfc->pinctrl;
> -
> -       pinctrl_unregister(pmx->pctl);
> -
> -       pfc->pinctrl = NULL;
> -       return 0;
> -}

There's no longer a need to have sh_pfc.pinctrl, so please remove that field
while you're at it.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


From marc.zyngier at arm.com  Wed Feb 24 06:07:14 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Feb 2016 14:07:14 +0000
Subject: [PATCH v3] arm64: Add workaround for Cavium erratum 27456
In-Reply-To: <20160224134016.GH28310@arm.com>
References: <1456272534-21692-1-git-send-email-ddaney.cavm@gmail.com>
 <20160224134016.GH28310@arm.com>
Message-ID: <56CDB912.6000300@arm.com>

On 24/02/16 13:40, Will Deacon wrote:

[...]

> (and Catalin, if you pick this up, watch out for the conflicts in
> cpufeature.h)

Yup, that one is about to become a minefield (ARM64_HAS_NO_HW_PREFETCH,
ARM64_HAS_UAO, ARM64_ALT_PAN_NOT_UAO and ARM64_HAS_VIRT_HOST_EXTN are
already happily clashing into -next). But hey, the more the merrier! ;-)

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From thomas.petazzoni at free-electrons.com  Wed Feb 24 06:07:16 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 24 Feb 2016 15:07:16 +0100
Subject: [PATCH 15/50] pinctrl: mvebu: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-16-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-16-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160224150716.3a2781af@free-electrons.com>

Dear Laxman Dewangan,

On Wed, 24 Feb 2016 18:45:40 +0530, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration and remove
> need of .remove callback.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> Cc: Hongzhou Yang <hongzhou.yang at mediatek.com>
> Cc: Fabian Frederick <fabf at skynet.be>
> Cc: Andrew Andrianov <andrew at ncrmnt.org>
> ---
>  drivers/pinctrl/mvebu/pinctrl-armada-370.c | 6 ------
>  drivers/pinctrl/mvebu/pinctrl-armada-375.c | 6 ------
>  drivers/pinctrl/mvebu/pinctrl-armada-38x.c | 6 ------
>  drivers/pinctrl/mvebu/pinctrl-armada-39x.c | 6 ------
>  drivers/pinctrl/mvebu/pinctrl-armada-xp.c  | 6 ------
>  drivers/pinctrl/mvebu/pinctrl-dove.c       | 5 +----
>  drivers/pinctrl/mvebu/pinctrl-kirkwood.c   | 6 ------
>  drivers/pinctrl/mvebu/pinctrl-mvebu.c      | 9 +--------
>  8 files changed, 2 insertions(+), 48 deletions(-)

Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From lorenzo.pieralisi at arm.com  Wed Feb 24 06:18:32 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Feb 2016 14:18:32 +0000
Subject: [PATCH v3] ARM64: kernel: implement ACPI parking protocol
In-Reply-To: <20160203161834.GB26487@MBP.local>
References: <1453806638-23167-1-git-send-email-lorenzo.pieralisi@arm.com>
 <20160202182657.GC15706@e104818-lin.cambridge.arm.com>
 <20160203112112.GA18387@red-moon>
 <20160203161834.GB26487@MBP.local>
Message-ID: <20160224141832.GA26630@red-moon>

[+ Itaru]

On Wed, Feb 03, 2016 at 04:18:36PM +0000, Catalin Marinas wrote:
> On Wed, Feb 03, 2016 at 11:21:12AM +0000, Lorenzo Pieralisi wrote:
> > On Tue, Feb 02, 2016 at 06:26:58PM +0000, Catalin Marinas wrote:
> > > On Tue, Jan 26, 2016 at 11:10:38AM +0000, Lorenzo Pieralisi wrote:
> > > > The SBBR and ACPI specifications allow ACPI based systems that do not
> > > > implement PSCI (eg systems with no EL3) to boot through the ACPI parking
> > > > protocol specification[1].
> > > > 
> > > > This patch implements the ACPI parking protocol CPU operations, and adds
> > > > code that eases parsing the parking protocol data structures to the
> > > > ARM64 SMP initializion carried out at the same time as cpus enumeration.
> > > > 
> > > > To wake-up the CPUs from the parked state, this patch implements a
> > > > wakeup IPI for ARM64 (ie arch_send_wakeup_ipi_mask()) that mirrors the
> > > > ARM one, so that a specific IPI is sent for wake-up purpose in order
> > > > to distinguish it from other IPI sources.
> > > > 
> > > > Given the current ACPI MADT parsing API, the patch implements a glue
> > > > layer that helps passing MADT GICC data structure from SMP initialization
> > > > code to the parking protocol implementation somewhat overriding the CPU
> > > > operations interfaces. This to avoid creating a completely trasparent
> > > > DT/ACPI CPU operations layer that would require creating opaque
> > > > structure handling for CPUs data (DT represents CPU through DT nodes, ACPI
> > > > through static MADT table entries), which seems overkill given that ACPI
> > > > on ARM64 mandates only two booting protocols (PSCI and parking protocol),
> > > > so there is no need for further protocol additions.
> > > > 
> > > > Based on the original work by Mark Salter <msalter at redhat.com>
> > > > 
> > > > [1] https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.docx
> > > > 
> > > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > > > Cc: Will Deacon <will.deacon at arm.com>
> > > > Cc: Hanjun Guo <hanjun.guo at linaro.org>
> > > > Cc: Loc Ho <lho at apm.com>
> > > > Cc: Sudeep Holla <sudeep.holla at arm.com>
> > > > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > > > Cc: Mark Rutland <mark.rutland at arm.com>
> > > > Cc: Mark Salter <msalter at redhat.com>
> > > > Cc: Al Stone <ahs3 at redhat.com>
> > > 
> > > Applied, with a minor addition just to warn people from not using it in
> > > other configurations (#ifdef still needed otherwise the
> > > acpi_parking_protocol_valid symbol is not available; but I prefer uglier
> > > code than people starting to use this IPI in their firmware):
> > 
> > It makes sense, we could include asm/acpi.h in smp.c (which is not
> > included by linux/acpi.h if !CONFIG_ACPI) to pull in the symbol and
> > remove the ifdef if you think it is cleaner.
> 
> I don't think it's worth.
> 
> BTW, the acpi_parking_protocol_valid() definition has an __init
> annotation while the declaration does not. I removed the __init
> altogether since I get a section mismatch warning when being called from
> handle_IPI.

Catalin,

Itaru spotted an issue related to ioremapping the mailbox in the
cpu_postboot method where I can't really use ioremap since irqs
are disabled on the secondaries coming up at that point, I missed
that, apologies (I wanted to avoid leaving the mailboxes mapped
after boot).

So, options to fix it:

(1) we leave the mailboxes mapped
(2) we remove the FW check in the postboot method (running on
    secondaries)
(3) I add a cpu_ops method to clean-up resources used for
    booting secondaries and there I can unmap the mailboxes

Frankly, they are all unappealing, I would go for (1), patch below, Itaru
can you give it a go please on Mustang against arm64 for-next/core ?

Thanks,
Lorenzo

-- >8 --
diff --git a/arch/arm64/kernel/acpi_parking_protocol.c b/arch/arm64/kernel/acpi_parking_protocol.c
index 4b1e5a7..b56fc0d 100644
--- a/arch/arm64/kernel/acpi_parking_protocol.c
+++ b/arch/arm64/kernel/acpi_parking_protocol.c
@@ -21,7 +21,14 @@
 
 #include <asm/cpu_ops.h>
 
+struct parking_protocol_mailbox {
+	__le32 cpu_id;
+	__le32 reserved;
+	__le64 entry_point;
+};
+
 struct cpu_mailbox_entry {
+	struct parking_protocol_mailbox __iomem *mailbox;
 	phys_addr_t mailbox_addr;
 	u8 version;
 	u8 gic_cpu_id;
@@ -59,12 +66,6 @@ static int acpi_parking_protocol_cpu_prepare(unsigned int cpu)
 	return 0;
 }
 
-struct parking_protocol_mailbox {
-	__le32 cpu_id;
-	__le32 reserved;
-	__le64 entry_point;
-};
-
 static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
 {
 	struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
@@ -107,7 +108,11 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
 
 	arch_send_wakeup_ipi_mask(cpumask_of(cpu));
 
-	iounmap(mailbox);
+	/*
+	 * stash the mailbox address mapping to use it for checks
+	 * in post boot method
+	 */
+	cpu_entry->mailbox = mailbox;
 
 	return 0;
 }
@@ -116,32 +121,15 @@ static void acpi_parking_protocol_cpu_postboot(void)
 {
 	int cpu = smp_processor_id();
 	struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
-	struct parking_protocol_mailbox __iomem *mailbox;
+	struct parking_protocol_mailbox __iomem *mailbox = cpu_entry->mailbox;
 	__le64 entry_point;
 
-	/*
-	 * Map mailbox memory with attribute device nGnRE (ie ioremap -
-	 * this deviates from the parking protocol specifications since
-	 * the mailboxes are required to be mapped nGnRnE; the attribute
-	 * discrepancy is harmless insofar as the protocol specification
-	 * is concerned).
-	 * If the mailbox is mistakenly allocated in the linear mapping
-	 * by FW ioremap will fail since the mapping will be prevented
-	 * by the kernel (it clashes with the linear mapping attributes
-	 * specifications).
-	 */
-	mailbox = ioremap(cpu_entry->mailbox_addr, sizeof(*mailbox));
-	if (!mailbox)
-		return;
-
 	entry_point = readl_relaxed(&mailbox->entry_point);
 	/*
 	 * Check if firmware has cleared the entry_point as expected
 	 * by the protocol specification.
 	 */
 	WARN_ON(entry_point);
-
-	iounmap(mailbox);
 }
 
 const struct cpu_operations acpi_parking_protocol_ops = {


From heiko at sntech.de  Wed Feb 24 06:21:20 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Wed, 24 Feb 2016 15:21:20 +0100
Subject: [PATCH] ARM: dts: rockchip: add mipi_dsi to VIO power domain on
 rk3288
In-Reply-To: <1456231181-13989-1-git-send-email-john@metanate.com>
References: <1456231181-13989-1-git-send-email-john@metanate.com>
Message-ID: <1682563.dHMl0I8iqX@phil>

Am Dienstag, 23. Februar 2016, 12:39:41 schrieb John Keeping:
> The MIPI controllers are part of the VIO power domain so add the
> necessary property to indicate this for the controller we support.
> 
> Signed-off-by: John Keeping <john at metanate.com>
> ---
>  arch/arm/boot/dts/rk3288.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index d879a89..a92a3b5 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -890,6 +890,7 @@
>  		clocks = <&cru SCLK_MIPIDSI_24M>, <&cru PCLK_MIPI_DSI0>;
>  		clock-names = "ref", "pclk";
>  		rockchip,grf = <&grf>;
> +		power-domains = <&power RK3288_PD_VIO>;
>  		status = "disabled";

applied to my dts32 branch after moving power-domains above rockchip,grf and 
adapting to the "#address-cells" and "#size-cells" present in the dtsi.


Thanks
Heiko




From shannon.zhao at linaro.org  Wed Feb 24 06:33:37 2016
From: shannon.zhao at linaro.org (Shannon Zhao)
Date: Wed, 24 Feb 2016 22:33:37 +0800
Subject: [PATCH v14 15/20] KVM: ARM64: Add PMU overflow interrupt routing
In-Reply-To: <1456290520-10012-16-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-16-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <1456324417-18992-1-git-send-email-shannon.zhao@linaro.org>

When calling perf_event_create_kernel_counter to create perf_event,
assign a overflow handler. Then when the perf event overflows, set the
corresponding bit of guest PMOVSSET register. If this counter is enabled
and its interrupt is enabled as well, kick the vcpu to sync the
interrupt.

On VM entry, if there is counter overflowed and interrupt level is
changed, inject the interrupt with corresponding level. On VM exit, sync
the interrupt level as well if it has been changed.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
---
 arch/arm/kvm/arm.c    |  5 ++++
 include/kvm/arm_pmu.h |  5 ++++
 virt/kvm/arm/pmu.c    | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 78 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dda1959..5c133ac 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -28,6 +28,7 @@
 #include <linux/sched.h>
 #include <linux/kvm.h>
 #include <trace/events/kvm.h>
+#include <kvm/arm_pmu.h>
 
 #define CREATE_TRACE_POINTS
 #include "trace.h"
@@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
 		 * non-preemptible context.
 		 */
 		preempt_disable();
+		kvm_pmu_flush_hwstate(vcpu);
 		kvm_timer_flush_hwstate(vcpu);
 		kvm_vgic_flush_hwstate(vcpu);
 
@@ -593,6 +595,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
 		if (ret <= 0 || need_new_vmid_gen(vcpu->kvm) ||
 			vcpu->arch.power_off || vcpu->arch.pause) {
 			local_irq_enable();
+			kvm_pmu_sync_hwstate(vcpu);
 			kvm_timer_sync_hwstate(vcpu);
 			kvm_vgic_sync_hwstate(vcpu);
 			preempt_enable();
@@ -641,6 +644,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
 		kvm_guest_exit();
 		trace_kvm_exit(ret, kvm_vcpu_trap_get_class(vcpu), *vcpu_pc(vcpu));
 
+		kvm_pmu_sync_hwstate(vcpu);
+
 		/*
 		 * We must sync the timer state before the vgic state so that
 		 * the vgic can properly sample the updated state of the
diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
index 8bc92d1..9c184ed 100644
--- a/include/kvm/arm_pmu.h
+++ b/include/kvm/arm_pmu.h
@@ -35,6 +35,7 @@ struct kvm_pmu {
 	int irq_num;
 	struct kvm_pmc pmc[ARMV8_PMU_MAX_COUNTERS];
 	bool ready;
+	bool irq_level;
 };
 
 #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
@@ -44,6 +45,8 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
 void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
+void kvm_pmu_sync_hwstate(struct kvm_vcpu *vcpu);
 void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
 void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
@@ -67,6 +70,8 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
 static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
+static inline void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
+static inline void kvm_pmu_sync_hwstate(struct kvm_vcpu *vcpu) {}
 static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
 static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
index cda869c..74e858c 100644
--- a/virt/kvm/arm/pmu.c
+++ b/virt/kvm/arm/pmu.c
@@ -21,6 +21,7 @@
 #include <linux/perf_event.h>
 #include <asm/kvm_emulate.h>
 #include <kvm/arm_pmu.h>
+#include <kvm/arm_vgic.h>
 
 /**
  * kvm_pmu_get_counter_value - get PMU counter value
@@ -180,6 +181,71 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
 		kvm_vcpu_kick(vcpu);
 }
 
+static void kvm_pmu_update_state(struct kvm_vcpu *vcpu)
+{
+	struct kvm_pmu *pmu = &vcpu->arch.pmu;
+	bool overflow;
+
+	if (!kvm_arm_pmu_v3_ready(vcpu))
+		return;
+
+	overflow = !!kvm_pmu_overflow_status(vcpu);
+	if (pmu->irq_level != overflow) {
+		pmu->irq_level = overflow;
+		kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
+				    pmu->irq_num, overflow);
+	}
+}
+
+/**
+ * kvm_pmu_flush_hwstate - flush pmu state to cpu
+ * @vcpu: The vcpu pointer
+ *
+ * Check if the PMU has overflowed while we were running in the host, and inject
+ * an interrupt if that was the case.
+ */
+void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
+{
+	kvm_pmu_update_state(vcpu);
+}
+
+/**
+ * kvm_pmu_sync_hwstate - sync pmu state from cpu
+ * @vcpu: The vcpu pointer
+ *
+ * Check if the PMU has overflowed while we were running in the guest, and
+ * inject an interrupt if that was the case.
+ */
+void kvm_pmu_sync_hwstate(struct kvm_vcpu *vcpu)
+{
+	kvm_pmu_update_state(vcpu);
+}
+
+static inline struct kvm_vcpu *kvm_pmc_to_vcpu(struct kvm_pmc *pmc)
+{
+	struct kvm_pmu *pmu;
+	struct kvm_vcpu_arch *vcpu_arch;
+
+	pmc -= pmc->idx;
+	pmu = container_of(pmc, struct kvm_pmu, pmc[0]);
+	vcpu_arch = container_of(pmu, struct kvm_vcpu_arch, pmu);
+	return container_of(vcpu_arch, struct kvm_vcpu, arch);
+}
+
+/**
+ * When perf event overflows, call kvm_pmu_overflow_set to set overflow status.
+ */
+static void kvm_pmu_perf_overflow(struct perf_event *perf_event,
+				  struct perf_sample_data *data,
+				  struct pt_regs *regs)
+{
+	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
+	struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
+	int idx = pmc->idx;
+
+	kvm_pmu_overflow_set(vcpu, BIT(idx));
+}
+
 /**
  * kvm_pmu_software_increment - do software increment
  * @vcpu: The vcpu pointer
@@ -291,7 +357,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
 	/* The initial sample period (overflow count) of an event. */
 	attr.sample_period = (-counter) & pmc->bitmask;
 
-	event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
+	event = perf_event_create_kernel_counter(&attr, -1, current,
+						 kvm_pmu_perf_overflow, pmc);
 	if (IS_ERR(event)) {
 		pr_err_once("kvm: pmu event creation failed %ld\n",
 			    PTR_ERR(event));
-- 
2.1.0



From heiko at sntech.de  Wed Feb 24 06:35:31 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Wed, 24 Feb 2016 15:35:31 +0100
Subject: [PATCH 1/4] soc: rockchip: add bindings for Rockchip grf
In-Reply-To: <1456210864-29037-2-git-send-email-jay.xu@rock-chips.com>
References: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
 <1456210864-29037-2-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1832389.c46G87NAnj@phil>

Am Dienstag, 23. Februar 2016, 15:01:01 schrieb jianqun.xu:
> From: Jianqun Xu <jay.xu at rock-chips.com>
> 
> Add devicetree bindings for Rockchip grf which found on
> Rockchip SoCs.
> 
> Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>

applied to my dts32 branch for 4.6 with Rob's Ack.


Thanks
Heiko


From arnd at arndb.de  Wed Feb 24 06:51:10 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Feb 2016 15:51:10 +0100
Subject: [PATCH] ARM: realview: add EB syscon variants to bindings
In-Reply-To: <1456218606-3749-1-git-send-email-linus.walleij@linaro.org>
References: <1456218606-3749-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <3716654.ki0irAFpjQ@wuerfel>

On Tuesday 23 February 2016 10:10:06 Linus Walleij wrote:
> There are two distinct RealView EB system controller that we need
> to detect and handle because their register layout differ
> slightly.
> 
> Cc: Rob Herring <robh+dt at kernel.org>
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> 

Looks ok.

Acked-by: Arnd Bergmann <arnd at arndb.de>

	Arnd


From p.zabel at pengutronix.de  Wed Feb 24 06:52:46 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Wed, 24 Feb 2016 15:52:46 +0100
Subject: [PATCH] ARM: dts: imx6q: add missing links between ipu2 and mipi dsi
Message-ID: <1456325566-20375-1-git-send-email-p.zabel@pengutronix.de>

The backlinks are already there since commit 4520e69238b3 ("ARM: dts:
imx6qdl: Add IPU DI ports and endpoints, move imx-drm node to dtsi")
and were moved by commit 70c2652c6c5b ("ARM: dts: imx6qdl: Move existing
MIPI DSI ports into a new 'ports' node"), but the links from IPU2 DI0/1
to the MIPI DSI mux are missing. Fix this.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 arch/arm/boot/dts/imx6q.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 0d93c0e..26418f9 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -162,6 +162,7 @@
 				};
 
 				ipu2_di0_mipi: endpoint at 2 {
+					remote-endpoint = <&mipi_mux_2>;
 				};
 
 				ipu2_di0_lvds0: endpoint at 3 {
@@ -183,6 +184,7 @@
 				};
 
 				ipu2_di1_mipi: endpoint at 2 {
+					remote-endpoint = <&mipi_mux_3>;
 				};
 
 				ipu2_di1_lvds0: endpoint at 3 {
-- 
2.7.0



From robh at kernel.org  Wed Feb 24 06:53:46 2016
From: robh at kernel.org (Rob Herring)
Date: Wed, 24 Feb 2016 08:53:46 -0600
Subject: [PATCH v4 16/17] FDT: Add a helper to get specified name subnode
In-Reply-To: <56CC3ED9.5000101@huawei.com>
References: <1454641552-12576-1-git-send-email-zhaoshenglong@huawei.com>
 <1454641552-12576-17-git-send-email-zhaoshenglong@huawei.com>
 <CAL_JsqK8F6PQX2kC_+CtDk1-ykKRB3YB54o4FaypsRY_tNzK5w@mail.gmail.com>
 <56CC3ED9.5000101@huawei.com>
Message-ID: <CAL_JsqJJx_agcQRa=vU25Db33t8LtaoBw+dZB5jS2N7LA2KX2g@mail.gmail.com>

On Tue, Feb 23, 2016 at 5:13 AM, Shannon Zhao <zhaoshenglong at huawei.com> wrote:
>
>
> On 2016/2/9 13:04, Rob Herring wrote:
>> On Thu, Feb 4, 2016 at 9:05 PM, Shannon Zhao <zhaoshenglong at huawei.com> wrote:
>>> From: Shannon Zhao <shannon.zhao at linaro.org>
>>>
>>> Sometimes it needs to check if there is a node in FDT by full path.
>>
>> I'm confused. Are you searching by full path or...
>>
>>> Introduce this helper to get the specified name subnode if it exists.
>>
>> name of sub node?
>>
> get the offset of sub node by specified name.
>
>> Either way, fdt_subnode_offset or fdt_path_offset doesn't work?
>>
> Ah?right?both of them should work. Does it need to add a wrapper in
> drivers/of/fdt.c for them or directly use them with the parameter
> initial_boot_params?

Add a wrapper in fdt.c.

Rob


From per.hallsmark at windriver.com  Wed Feb 24 06:54:59 2016
From: per.hallsmark at windriver.com (per.hallsmark at windriver.com)
Date: Wed, 24 Feb 2016 15:54:59 +0100
Subject: [PATCH] arm64: ni_syscall should be similar to other archs
Message-ID: <1456325699-25849-1-git-send-email-per.hallsmark@windriver.com>

From: Per Hallsmark <per.hallsmark at windriver.com>

Today arm64 have it's own variant when a userspace app is doing a
non-implemented syscall in that it dumps on console process name,
registers and such. This makes a different behaviour on arm64 than
on all other archs.

This patch propose to get inline with other archs.

If we want to have a note on console, syslog or so when doing a
nonimplemented syscall, it would be better to add a variable
show_nonimplemented_syscalls and sense on it in the generic
kernel/sys_ni.c::sys_ni_syscall() which could dump info (and then
it would be generic for all archs). But that is another discussion
alltogether, lets first synchronize the archs to behave similar.

Signed-off-by: Per Hallsmark <per.hallsmark at windriver.com>
---
 arch/arm64/kernel/traps.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index cbedd72..980ff63 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -403,14 +403,6 @@ asmlinkage long do_ni_syscall(struct pt_regs *regs)
 	}
 #endif
 
-	if (show_unhandled_signals_ratelimited()) {
-		pr_info("%s[%d]: syscall %d\n", current->comm,
-			task_pid_nr(current), (int)regs->syscallno);
-		dump_instr("", regs);
-		if (user_mode(regs))
-			__show_regs(regs);
-	}
-
 	return sys_ni_syscall();
 }
 
-- 
2.5.0



From m.grzeschik at pengutronix.de  Wed Feb 24 06:57:46 2016
From: m.grzeschik at pengutronix.de (Michael Grzeschik)
Date: Wed, 24 Feb 2016 15:57:46 +0100
Subject: [PATCH 1/2] ARM: imx_v4_v5_defconfig: Cleanup imx_v4_v5_defconfig
Message-ID: <1456325867-5309-1-git-send-email-m.grzeschik@pengutronix.de>

From: Jan Luebbe <jlu at pengutronix.de>

Regenerate imx_v4_v5_defconfig by running:
make imx_v4_v5_defconfig
make savedefconfig
mv defconfig arch/arm/configs/imx_v4_v5_defconfig

Signed-off-by: Jan Luebbe <jlu at pengutronix.de>
Signed-off-by: Michael Grzeschik <m.grzeschik at pengutronix.de>
---
 arch/arm/configs/imx_v4_v5_defconfig | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/arm/configs/imx_v4_v5_defconfig b/arch/arm/configs/imx_v4_v5_defconfig
index d3a8018..f23b3ba 100644
--- a/arch/arm/configs/imx_v4_v5_defconfig
+++ b/arch/arm/configs/imx_v4_v5_defconfig
@@ -24,14 +24,12 @@ CONFIG_ARCH_MXC=y
 CONFIG_MACH_SCB9328=y
 CONFIG_MACH_APF9328=y
 CONFIG_MACH_MX21ADS=y
-CONFIG_MACH_EUKREA_CPUIMX25SD=y
-CONFIG_SOC_IMX25=y
 CONFIG_MACH_MX27ADS=y
 CONFIG_MACH_MX27_3DS=y
 CONFIG_MACH_IMX27_VISSTRIM_M10=y
 CONFIG_MACH_PCA100=y
-CONFIG_MACH_MXT_TD60=y
 CONFIG_MACH_IMX27_DT=y
+CONFIG_SOC_IMX25=y
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
@@ -169,12 +167,11 @@ CONFIG_RTC_DRV_IMXDI=y
 CONFIG_RTC_DRV_MC13XXX=y
 CONFIG_RTC_DRV_MXC=y
 CONFIG_DMADEVICES=y
-CONFIG_IMX_SDMA=y
 CONFIG_IMX_DMA=y
+CONFIG_IMX_SDMA=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
-CONFIG_EXT4_FS=y
 # CONFIG_DNOTIFY is not set
 CONFIG_VFAT_FS=y
 # CONFIG_PROC_PAGE_MONITOR is not set
@@ -187,6 +184,5 @@ CONFIG_NLS_CODEPAGE_437=m
 CONFIG_NLS_CODEPAGE_850=m
 CONFIG_NLS_ISO8859_1=y
 CONFIG_NLS_ISO8859_15=m
-# CONFIG_CRYPTO_ANSI_CPRNG is not set
 CONFIG_FONTS=y
 CONFIG_FONT_8x8=y
-- 
2.7.0



From m.grzeschik at pengutronix.de  Wed Feb 24 06:57:47 2016
From: m.grzeschik at pengutronix.de (Michael Grzeschik)
Date: Wed, 24 Feb 2016 15:57:47 +0100
Subject: [PATCH 2/2] ARM: imx_v4_v5_defconfig: Enable initramfs support
In-Reply-To: <1456325867-5309-1-git-send-email-m.grzeschik@pengutronix.de>
References: <1456325867-5309-1-git-send-email-m.grzeschik@pengutronix.de>
Message-ID: <1456325867-5309-2-git-send-email-m.grzeschik@pengutronix.de>

From: Jan Luebbe <jlu at pengutronix.de>

This makes it possible to automatically boot-test this defconfig with
kernelci.org.

Signed-off-by: Jan Luebbe <jlu at pengutronix.de>
Signed-off-by: Michael Grzeschik <m.grzeschik at pengutronix.de>
---
 arch/arm/configs/imx_v4_v5_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/imx_v4_v5_defconfig b/arch/arm/configs/imx_v4_v5_defconfig
index f23b3ba..cb7b0f5 100644
--- a/arch/arm/configs/imx_v4_v5_defconfig
+++ b/arch/arm/configs/imx_v4_v5_defconfig
@@ -6,6 +6,7 @@ CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_LOG_BUF_SHIFT=14
 CONFIG_CGROUPS=y
+CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
 # CONFIG_COMPAT_BRK is not set
 CONFIG_SLAB=y
-- 
2.7.0



From lorenzo.pieralisi at arm.com  Wed Feb 24 07:03:14 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Feb 2016 15:03:14 +0000
Subject: [PATCH v3] ARM64: kernel: implement ACPI parking protocol
In-Reply-To: <20160224141832.GA26630@red-moon>
References: <1453806638-23167-1-git-send-email-lorenzo.pieralisi@arm.com>
 <20160202182657.GC15706@e104818-lin.cambridge.arm.com>
 <20160203112112.GA18387@red-moon>
 <20160203161834.GB26487@MBP.local>
 <20160224141832.GA26630@red-moon>
Message-ID: <20160224150314.GD25385@red-moon>

On Wed, Feb 24, 2016 at 02:18:32PM +0000, Lorenzo Pieralisi wrote:

[...]

>  static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
>  {
>  	struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
> @@ -107,7 +108,11 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
>  
>  	arch_send_wakeup_ipi_mask(cpumask_of(cpu));
>  
> -	iounmap(mailbox);
> +	/*
> +	 * stash the mailbox address mapping to use it for checks
> +	 * in post boot method
> +	 */
> +	cpu_entry->mailbox = mailbox;

The mailbox VA entry should be stashed before setting up the mailbox
and sending the IPI, anyway, if Loc and Itaru can test it I will wrap
this change into the final version with appropriate log.

Lorenzo

>  
>  	return 0;
>  }
> @@ -116,32 +121,15 @@ static void acpi_parking_protocol_cpu_postboot(void)
>  {
>  	int cpu = smp_processor_id();
>  	struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
> -	struct parking_protocol_mailbox __iomem *mailbox;
> +	struct parking_protocol_mailbox __iomem *mailbox = cpu_entry->mailbox;
>  	__le64 entry_point;
>  
> -	/*
> -	 * Map mailbox memory with attribute device nGnRE (ie ioremap -
> -	 * this deviates from the parking protocol specifications since
> -	 * the mailboxes are required to be mapped nGnRnE; the attribute
> -	 * discrepancy is harmless insofar as the protocol specification
> -	 * is concerned).
> -	 * If the mailbox is mistakenly allocated in the linear mapping
> -	 * by FW ioremap will fail since the mapping will be prevented
> -	 * by the kernel (it clashes with the linear mapping attributes
> -	 * specifications).
> -	 */
> -	mailbox = ioremap(cpu_entry->mailbox_addr, sizeof(*mailbox));
> -	if (!mailbox)
> -		return;
> -
>  	entry_point = readl_relaxed(&mailbox->entry_point);
>  	/*
>  	 * Check if firmware has cleared the entry_point as expected
>  	 * by the protocol specification.
>  	 */
>  	WARN_ON(entry_point);
> -
> -	iounmap(mailbox);
>  }
>  
>  const struct cpu_operations acpi_parking_protocol_ops = {


From m.grzeschik at pengutronix.de  Wed Feb 24 07:03:19 2016
From: m.grzeschik at pengutronix.de (Michael Grzeschik)
Date: Wed, 24 Feb 2016 16:03:19 +0100
Subject: [PATCH 2/2] ARM: multi_v5_defconfig: Enable initramfs support
In-Reply-To: <1456326199-12438-1-git-send-email-m.grzeschik@pengutronix.de>
References: <1456326199-12438-1-git-send-email-m.grzeschik@pengutronix.de>
Message-ID: <1456326199-12438-2-git-send-email-m.grzeschik@pengutronix.de>

From: Jan Luebbe <jlu at pengutronix.de>

This makes it possible to automatically boot-test this defconfig with
kernelci.org.

Signed-off-by: Jan Luebbe <jlu at pengutronix.de>
Signed-off-by: Michael Grzeschik <m.grzeschik at pengutronix.de>
---
 arch/arm/configs/multi_v5_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
index fcbc633..ab503c2 100644
--- a/arch/arm/configs/multi_v5_defconfig
+++ b/arch/arm/configs/multi_v5_defconfig
@@ -2,6 +2,7 @@ CONFIG_SYSVIPC=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_LOG_BUF_SHIFT=19
+CONFIG_BLK_DEV_INITRD=y
 CONFIG_PROFILING=y
 CONFIG_OPROFILE=y
 CONFIG_KPROBES=y
-- 
2.7.0



From m.grzeschik at pengutronix.de  Wed Feb 24 07:03:18 2016
From: m.grzeschik at pengutronix.de (Michael Grzeschik)
Date: Wed, 24 Feb 2016 16:03:18 +0100
Subject: [PATCH 1/2] ARM: multi_v5_defconfig: Cleanup multi_v5_defconfig
Message-ID: <1456326199-12438-1-git-send-email-m.grzeschik@pengutronix.de>

From: Jan Luebbe <jlu at pengutronix.de>

Regenerate multi_v5_defconfig by running:
make multi_v5_defconfig
make savedefconfig
mv defconfig arch/arm/configs/multi_v5_defconfig

Signed-off-by: Jan Luebbe <jlu at pengutronix.de>
Signed-off-by: Michael Grzeschik <m.grzeschik at pengutronix.de>
---
 arch/arm/configs/multi_v5_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
index 1f9ca47..fcbc633 100644
--- a/arch/arm/configs/multi_v5_defconfig
+++ b/arch/arm/configs/multi_v5_defconfig
@@ -97,9 +97,9 @@ CONFIG_NET_DSA_MV88E6352=y
 CONFIG_MV643XX_ETH=y
 CONFIG_R8169=y
 CONFIG_MARVELL_PHY=y
-CONFIG_MWL8K=m
 CONFIG_LIBERTAS=y
 CONFIG_LIBERTAS_SDIO=y
+CONFIG_MWL8K=m
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_GPIO=y
 # CONFIG_INPUT_MOUSE is not set
-- 
2.7.0



From m.grzeschik at pengutronix.de  Wed Feb 24 07:04:50 2016
From: m.grzeschik at pengutronix.de (Michael Grzeschik)
Date: Wed, 24 Feb 2016 16:04:50 +0100
Subject: [PATCH 1/2] ARM: mxs_defconfig: Cleanup mxs_defconfig
Message-ID: <1456326291-20618-1-git-send-email-m.grzeschik@pengutronix.de>

From: Jan Luebbe <jlu at pengutronix.de>

Regenerate mxs_defconfig by running:
make mxs_defconfig
make savedefconfig
mv defconfig arch/arm/configs/mxs_defconfig

Signed-off-by: Jan Luebbe <jlu at pengutronix.de>
Signed-off-by: Michael Grzeschik <m.grzeschik at pengutronix.de>
---
 arch/arm/configs/mxs_defconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/configs/mxs_defconfig b/arch/arm/configs/mxs_defconfig
index b47e7c6..5e7b7df 100644
--- a/arch/arm/configs/mxs_defconfig
+++ b/arch/arm/configs/mxs_defconfig
@@ -144,7 +144,6 @@ CONFIG_PWM_MXS=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT3_FS=y
-CONFIG_EXT4_FS=y
 # CONFIG_DNOTIFY is not set
 CONFIG_FSCACHE=m
 CONFIG_FSCACHE_STATS=y
@@ -178,7 +177,6 @@ CONFIG_PROVE_LOCKING=y
 CONFIG_BLK_DEV_IO_TRACE=y
 CONFIG_STRICT_DEVMEM=y
 CONFIG_DEBUG_USER=y
-# CONFIG_CRYPTO_ANSI_CPRNG is not set
 CONFIG_CRYPTO_DEV_MXS_DCP=y
 CONFIG_CRC_ITU_T=m
 CONFIG_CRC7=m
-- 
2.7.0



From m.grzeschik at pengutronix.de  Wed Feb 24 07:04:51 2016
From: m.grzeschik at pengutronix.de (Michael Grzeschik)
Date: Wed, 24 Feb 2016 16:04:51 +0100
Subject: [PATCH 2/2] ARM: mxs_defconfig: Enable initramfs support
In-Reply-To: <1456326291-20618-1-git-send-email-m.grzeschik@pengutronix.de>
References: <1456326291-20618-1-git-send-email-m.grzeschik@pengutronix.de>
Message-ID: <1456326291-20618-2-git-send-email-m.grzeschik@pengutronix.de>

From: Jan Luebbe <jlu at pengutronix.de>

This makes it possible to automatically boot-test this defconfig with
kernelci.org.

Signed-off-by: Jan Luebbe <jlu at pengutronix.de>
Signed-off-by: Michael Grzeschik <m.grzeschik at pengutronix.de>
---
 arch/arm/configs/mxs_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/mxs_defconfig b/arch/arm/configs/mxs_defconfig
index 5e7b7df..dc498cd 100644
--- a/arch/arm/configs/mxs_defconfig
+++ b/arch/arm/configs/mxs_defconfig
@@ -12,6 +12,7 @@ CONFIG_IKCONFIG_PROC=y
 # CONFIG_IPC_NS is not set
 # CONFIG_PID_NS is not set
 # CONFIG_NET_NS is not set
+CONFIG_BLK_DEV_INITRD=y
 CONFIG_PERF_EVENTS=y
 # CONFIG_COMPAT_BRK is not set
 CONFIG_MODULES=y
-- 
2.7.0



From manabian at gmail.com  Wed Feb 24 07:06:02 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Wed, 24 Feb 2016 16:06:02 +0100
Subject: [PATCH 40/50] pinctrl: lpc18xx: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-41-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-41-git-send-email-ldewangan@nvidia.com>
Message-ID: <CAGhQ9Vzoosj=SpSn-fj1thL9bdfW+cay_truUR9VF8nP9HUwbg@mail.gmail.com>

Hi Laxman,

On 24 February 2016 at 14:16, Laxman Dewangan <ldewangan at nvidia.com> wrote:
> Use devm_pinctrl_register() for pin control registration.
>
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Joachim Eastwood <manabian at gmail.com>
> ---
>  drivers/pinctrl/pinctrl-lpc18xx.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Acked-by: Joachim Eastwood <manabian at gmail.com>


regards,
Joachim Eastwood


From dave.long at linaro.org  Wed Feb 24 07:07:32 2016
From: dave.long at linaro.org (David Long)
Date: Wed, 24 Feb 2016 10:07:32 -0500
Subject: [PATCH 5/8] arm64: kprobes instruction simulation support
In-Reply-To: <20160224090530.5e86e867@arm.com>
References: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
 <1455839301-26464-6-git-send-email-dave.long@linaro.org>
 <56C720F0.9080108@arm.com> <56CD5434.30108@linaro.org>
 <20160224090530.5e86e867@arm.com>
Message-ID: <56CDC734.4000201@linaro.org>

On 02/24/2016 04:05 AM, Marc Zyngier wrote:
> On Wed, 24 Feb 2016 01:56:52 -0500
> David Long <dave.long at linaro.org> wrote:
>
>> On 02/19/2016 09:04 AM, Marc Zyngier wrote:
>>> Hi David,
>>>
>>> On 18/02/16 23:48, David Long wrote:
>>>> From: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>
>>>>
>>>> Kprobes needs simulation of instructions that cannot be stepped
>>>> from different memory location, e.g.: those instructions
>>>> that uses PC-relative addressing. In simulation, the behaviour
>>>> of the instruction is implemented using a copy of pt_regs.
>>>>
>>>> Following instruction catagories are simulated:
>>>>    - All branching instructions(conditional, register, and immediate)
>>>>    - Literal access instructions(load-literal, adr/adrp)
>>>>
>>>> Conditional execution is limited to branching instructions in
>>>> ARM v8. If conditions at PSTATE do not match the condition fields
>>>> of opcode, the instruction is effectively NOP. Kprobes considers
>>>> this case as 'miss'.
>>>>
>>>> This code also replaces the use of arch/arm/opcodes.c for
>>>> arm_check_condition().
>>>>
>>>> Thanks to Will Cohen for assorted suggested changes.
>>>>
>>>> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>
>>>> Signed-off-by: William Cohen <wcohen at redhat.com>
>>>> Signed-off-by: David A. Long <dave.long at linaro.org>
>
> [...]
>
>>>> +};
>>>> +
>>>> +asmlinkage unsigned int __kprobes arm_check_condition(u32 opcode, u32 psr)
>>>
>>> Why asmlinkage? This function is never called from assembly code on arm64.
>>>
>>
>> This comes from the 32-bit ARM code that tests the condition from
>> entry.S.  We include arch/arm/include/asm/opcodes.h in
>> arch/arm64/include/asm/opcodes.h so it gets declared there with
>> asmlinkage. I can remove the asmlinkage in the actual function
>> definition and it still compiles but I'm not sure that is kosher.
>
> asmlinkage is only meaningful if you're calling it from assembly code.
> As you seem to only call it from C code, having asmlinkage is both
> pointless and confusing.
>
>> Will Deacon was advocating getting rid of the include of the 32-bit header
>> file but it looked to me like this would mean a lot of duplicated
>> defines and the work would be mostly unrelated to kprobes.
>
> Arguably, arm_check_condition() (which only matters to 32bit code,
> hence userspace) is also completely unrelated to kprobes. I still think
> Will's point stands.
>

Yes, I would not argue about that cross-architecture include needing to 
be fixed.  Can I assume you agree that need not be a part of this 
kprobes patch though, nor a prerequisite patch for it?

>>
>>>> +{
>>>> +	u32 cc_bits  = opcode >> 28;
>>>> +
>>>> +	if (cc_bits != ARM_OPCODE_CONDITION_UNCOND) {
>>>> +		if ((*opcode_condition_checks[cc_bits])(psr))
>>>> +			return ARM_OPCODE_CONDTEST_PASS;
>>>> +		else
>>>> +			return ARM_OPCODE_CONDTEST_FAIL;
>>>> +	}
>>>> +	return ARM_OPCODE_CONDTEST_UNCOND;
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(arm_check_condition);
>>>
>>> Why do we need this to be exported at all? Also, it'd be better located
>>> together with the deprecated instruction handling, possibly in a
>>> separate patch (nothing uses this function in this patch).
>>>
>>
>> I've made the function static and moved it to armv8_deprecated.  I have
>> to leave the static functions that test the individual conditions and
>> the global array of pointers to them outside of the conditionally
>> compiled armv8_deprecated.c as they have to always be present for
>> kprobes to simulate a conditional branch.
>
> I think that's fine.
>
> Thanks,
>
> 	M.
>



From thomas.petazzoni at free-electrons.com  Wed Feb 24 07:14:20 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 24 Feb 2016 16:14:20 +0100
Subject: [PATCH v2 0/6] clk: mvebu: initial support for AP806 clocks
Message-ID: <1456326866-30854-1-git-send-email-thomas.petazzoni@free-electrons.com>

Hello,

The following set of patches add initial support for the main clocks
found in the AP806 hardware block, which is the central block used in
the newest Marvell 7K and 8K 64-bits processors.

Two new drivers are added, one for the so-called "core" clocks and one
for the "ring" clocks. The latter are child clocks from one of the
core clocks. The "core" clocks are fixed rate clocks, but their rate
is calculated from values in the Sample At Reset register.

Changes since v1:
 - Introduce a minimal DT binding for the AP806 DFX Server register
   area, and make the clock DT nodes child nodes of the DFX server
   node. Implementation-wise, we use the simple-mfd/syscon mechanism.
 - Separate the DT binding documentation into its own patches.

Thanks!

Thomas

Thomas Petazzoni (6):
  dt-bindings: arm/marvell: add DT bindings for AP806 DFX Server
  dt-bindings: clock: add DT bindings for AP806 core clocks
  dt-bindings: clock: add DT bindings for AP806 ring clocks
  clk: unconditionally recurse into clk/mvebu/
  clk: mvebu: add AP806 core clock driver
  clk: mvebu: add AP806 ring clock driver

 .../arm/marvell/marvell,ap806-dfx-server.txt       |  19 ++++
 .../clock/mvebu-armada-ap806-core-clock.txt        |  35 ++++++
 .../clock/mvebu-armada-ap806-ring-clock.txt        |  36 ++++++
 drivers/clk/Makefile                               |   2 +-
 drivers/clk/mvebu/Kconfig                          |   6 +
 drivers/clk/mvebu/Makefile                         |   3 +-
 drivers/clk/mvebu/ap806-core.c                     | 121 +++++++++++++++++++++
 drivers/clk/mvebu/ap806-ring.c                     |  74 +++++++++++++
 8 files changed, 294 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/marvell,ap806-dfx-server.txt
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt
 create mode 100644 drivers/clk/mvebu/ap806-core.c
 create mode 100644 drivers/clk/mvebu/ap806-ring.c

-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 24 07:14:24 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 24 Feb 2016 16:14:24 +0100
Subject: [PATCH v2 4/6] clk: unconditionally recurse into clk/mvebu/
In-Reply-To: <1456326866-30854-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1456326866-30854-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1456326866-30854-5-git-send-email-thomas.petazzoni@free-electrons.com>

The drivers/clk/mvebu directory is only being built when
CONFIG_PLAT_ORION=y. As we are going to support additional mvebu
platforms in drivers/clk/mvebu, which don't have CONFIG_PLAT_ORION=y,
we need to recurse into this directory regardless of the value of
CONFIG_PLAT_ORION.

Since all files in drivers/clk/mvebu/ are already conditionally
compiled depending on various Kconfig options, we can recurse
unconditionally into drivers/clk/mvebu without any other change.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/clk/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index b038e36..e08bb0e 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -61,7 +61,7 @@ obj-$(CONFIG_ARCH_MEDIATEK)		+= mediatek/
 ifeq ($(CONFIG_COMMON_CLK), y)
 obj-$(CONFIG_ARCH_MMP)			+= mmp/
 endif
-obj-$(CONFIG_PLAT_ORION)		+= mvebu/
+obj-y					+= mvebu/
 obj-$(CONFIG_ARCH_MESON)		+= meson/
 obj-$(CONFIG_ARCH_MXS)			+= mxs/
 obj-$(CONFIG_MACH_PISTACHIO)		+= pistachio/
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 24 07:14:23 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 24 Feb 2016 16:14:23 +0100
Subject: [PATCH v2 3/6] dt-bindings: clock: add DT bindings for AP806 ring
 clocks
In-Reply-To: <1456326866-30854-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1456326866-30854-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1456326866-30854-4-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adds the Device Tree binding description for the AP806
ring clocks, used on Marvell Armada 7K/8K SOCs.

Since the AP806 ring clocks register is part of the "DFX Server"
register area, the DT binding is meant to be used as a sub-node of the
DFX Server DT binding, which is described separately.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../clock/mvebu-armada-ap806-ring-clock.txt        | 36 ++++++++++++++++++++++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt
new file mode 100644
index 0000000..8c8030a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-ring-clock.txt
@@ -0,0 +1,36 @@
+* Clock bindings for Marvell MVEBU AP806 Ring clocks
+
+The Marvell MVEBU Armada 7K/8K SoCs contain a block called AP806,
+hosting the CPU and other core components of the CPU. This Device Tree
+binding allows to describe the ring clocks of the AP806, which are
+derived from the Ring Core clock, after a dividing factor.
+
+The register giving the dividing factors is part of the DFX server
+register area, covered by the DT binding described at
+Documentation/devicetree/bindings/arm/marvell/marvell,ap806-dfx-server.txt. Therefore,
+the DT node for the AP806 Ring clocks must appear as a child node of
+the DFX server Device Tree node.
+
+The following is a list of provided IDs and clock names on Armada
+AP806 RING dividers:
+
+ 0 = Ring 0
+ 1 = Ring 2
+ 2 = Ring 3
+ 3 = Ring 4
+ 4 = Ring 5
+
+Required properties:
+- compatible: must be one of the following:
+	"marvell,armada-ap806-ring-clock"
+- #clock-cells : from common clock binding; shall be set to 1
+- clock-output-names: name of the output clocks
+
+Example:
+
+	ringclk: clk at 250 {
+		compatible = "marvell,armada-ap806-ring-clock";
+		#clock-cells = <1>;
+		clock-output-names = "ring-0", "ring-2", "ring-3", "ring-4", "ring-5";
+		clocks = <&coreclk 1>;
+	};
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 24 07:14:21 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 24 Feb 2016 16:14:21 +0100
Subject: [PATCH v2 1/6] dt-bindings: arm/marvell: add DT bindings for AP806
 DFX Server
In-Reply-To: <1456326866-30854-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1456326866-30854-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1456326866-30854-2-git-send-email-thomas.petazzoni@free-electrons.com>

The following patch adds a Device Tree binding documentation for the
AP806 DFX Server register area found in Marvell Armada 7K/8K SOCs.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../bindings/arm/marvell/marvell,ap806-dfx-server.txt | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell/marvell,ap806-dfx-server.txt

diff --git a/Documentation/devicetree/bindings/arm/marvell/marvell,ap806-dfx-server.txt b/Documentation/devicetree/bindings/arm/marvell/marvell,ap806-dfx-server.txt
new file mode 100644
index 0000000..44eb3f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/marvell,ap806-dfx-server.txt
@@ -0,0 +1,19 @@
+Marvell AP806 DFX Server
+------------------------
+
+The Marvell AP806 HW block (which is a core component of the Marvell
+Armada 7K and 8K SOCs) has a set of registers called "DFX
+Server". This set of registers contains miscellaneous registers, most
+of them being used for silicon fine-tuning and manufacturing testing,
+and as such are not publicly documented. However, this DFX server
+register range also contains a few documented and useful registers,
+for example for clock control.
+
+This Device Tree binding allows to represent the entire DFX server
+register space as one single DT node.
+
+Required properties:
+- compatible: the first and second values must be:
+	"simple-mfd", "syscon"
+- reg: address and length of following register sets for the DFX
+  server
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 24 07:14:22 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 24 Feb 2016 16:14:22 +0100
Subject: [PATCH v2 2/6] dt-bindings: clock: add DT bindings for AP806 core
 clocks
In-Reply-To: <1456326866-30854-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1456326866-30854-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1456326866-30854-3-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adds the Device Tree binding description for the AP806
core clocks, used on Marvell Armada 7K/8K SOCs.

Since the AP806 core clocks register is part of the "DFX Server"
register area, the DT binding is meant to be used as a sub-node of the
DFX Server DT binding, which is described separately.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../clock/mvebu-armada-ap806-core-clock.txt        | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt
new file mode 100644
index 0000000..996c47f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-armada-ap806-core-clock.txt
@@ -0,0 +1,35 @@
+* Clock bindings for Marvell MVEBU AP806 Core clocks
+
+The Marvell MVEBU Armada 7K/8K SoCs contain a block called AP806,
+hosting the CPU and other core components of the CPU. This Device Tree
+binding allows to describe the core clocks of the AP806, whose
+frequencies are determined by reading the Sample-At-Reset (SAR)
+register. This register is part of the DFX server register area,
+covered by the DT binding described at
+Documentation/devicetree/bindings/arm/marvell/marvell,ap806-dfx-server.txt. Therefore,
+the DT node for the AP806 Core clocks must appear as a child node of
+the DFX server Device Tree node.
+
+Clock consumers must specify the desired clock by having the clock ID
+in its "clocks" phandle cell.
+
+The following is a list of provided IDs and clock names for the core
+Armada AP806 clocks:
+
+ 0 = DDR
+ 1 = Ring
+ 2 = CPU
+
+Required properties:
+- compatible: must be be one of the following:
+	"marvell,armada-ap806-core-clock"
+- #clock-cells: from common clock binding; shall be set to 1
+- clock-output-names: name of the output clocks
+
+Example:
+
+	coreclk: clk at 204 {
+		compatible = "marvell,armada-ap806-core-clock";
+		#clock-cells = <1>;
+		clock-output-names = "ddr", "ring", "cpu";
+	};
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 24 07:14:26 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 24 Feb 2016 16:14:26 +0100
Subject: [PATCH v2 6/6] clk: mvebu: add AP806 ring clock driver
In-Reply-To: <1456326866-30854-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1456326866-30854-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1456326866-30854-7-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adds a new driver to handle the ring clocks found in the
AP806 HW block, which is the core block of all Armada 7K and 8K
Marvell 64-bits processors. Those ring clocks are derived from the
core ring clock handled by the AP806 core clock driver. The ring
clocks are used by various peripherals inside the AP806.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/clk/mvebu/Kconfig      |  3 ++
 drivers/clk/mvebu/Makefile     |  1 +
 drivers/clk/mvebu/ap806-ring.c | 74 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 78 insertions(+)
 create mode 100644 drivers/clk/mvebu/ap806-ring.c

diff --git a/drivers/clk/mvebu/Kconfig b/drivers/clk/mvebu/Kconfig
index fd84172..5d30aac 100644
--- a/drivers/clk/mvebu/Kconfig
+++ b/drivers/clk/mvebu/Kconfig
@@ -45,3 +45,6 @@ config ORION_CLK
 
 config ARMADA_AP806_CORE_CLK
 	bool
+
+config ARMADA_AP806_RING_CLK
+	bool
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
index db5c28c..48ca2d3 100644
--- a/drivers/clk/mvebu/Makefile
+++ b/drivers/clk/mvebu/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_ARMADA_375_CLK)	+= armada-375.o
 obj-$(CONFIG_ARMADA_38X_CLK)	+= armada-38x.o
 obj-$(CONFIG_ARMADA_39X_CLK)	+= armada-39x.o
 obj-$(CONFIG_ARMADA_AP806_CORE_CLK) += ap806-core.o
+obj-$(CONFIG_ARMADA_AP806_RING_CLK) += ap806-ring.o
 obj-$(CONFIG_ARMADA_XP_CLK)	+= armada-xp.o
 obj-$(CONFIG_DOVE_CLK)		+= dove.o dove-divider.o
 obj-$(CONFIG_KIRKWOOD_CLK)	+= kirkwood.o
diff --git a/drivers/clk/mvebu/ap806-ring.c b/drivers/clk/mvebu/ap806-ring.c
new file mode 100644
index 0000000..f980192
--- /dev/null
+++ b/drivers/clk/mvebu/ap806-ring.c
@@ -0,0 +1,74 @@
+/*
+ * Marvell Armada AP806 ring clocks
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#define pr_fmt(fmt) "ap806-ring-clk: " fmt
+
+#include <linux/kernel.h>
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/regmap.h>
+
+#define AP806_RING_DIV_CLK_REG 0x250
+
+#define AP806_RING_DIV_NUM	5
+
+static struct clk *ap806_ring_clks[AP806_RING_DIV_NUM];
+
+static struct clk_onecell_data ap806_ring_clk_data = {
+	.clks = ap806_ring_clks,
+	.clk_num = AP806_RING_DIV_NUM,
+};
+
+static void __init ap806_ring_clk_init(struct device_node *np)
+{
+	struct regmap *regmap;
+	const char *parent;
+	u32 reg;
+	int i;
+
+	regmap = syscon_node_to_regmap(np->parent);
+	if (IS_ERR(regmap)) {
+		pr_err("cannot get regmap\n");
+		return;
+	}
+
+	if (regmap_read(regmap, AP806_RING_DIV_CLK_REG, &reg)) {
+		pr_err("cannot read from regmap\n");
+		return;
+	}
+
+	parent = of_clk_get_parent_name(np, 0);
+
+	for (i = 0; i < AP806_RING_DIV_NUM; i++) {
+		unsigned long divider;
+		const char *name;
+
+		/* Each clock is represented by 6 bits */
+		divider = (reg >> (6 * i)) & 0x3f;
+
+		of_property_read_string_index(np, "clock-output-names",
+					      i, &name);
+
+		ap806_ring_clks[i] =
+			clk_register_fixed_factor(NULL, name, parent,
+						  0, 1, divider);
+	}
+
+	of_clk_add_provider(np, of_clk_src_onecell_get, &ap806_ring_clk_data);
+}
+
+CLK_OF_DECLARE(ap806_ring_clk, "marvell,armada-ap806-ring-clock",
+	       ap806_ring_clk_init);
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 24 07:14:25 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 24 Feb 2016 16:14:25 +0100
Subject: [PATCH v2 5/6] clk: mvebu: add AP806 core clock driver
In-Reply-To: <1456326866-30854-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1456326866-30854-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1456326866-30854-6-git-send-email-thomas.petazzoni@free-electrons.com>

This commit adds a new driver to handle the core clocks found in the
AP806 HW block, which is the core block of all Armada 7K and 8K
Marvell 64-bits processors. This core clock driver reads the
Sample-At-Reset register to determine the frequencies of several core
clocks: DDR, Ring and CPU clocks.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 drivers/clk/mvebu/Kconfig      |   3 +
 drivers/clk/mvebu/Makefile     |   2 +-
 drivers/clk/mvebu/ap806-core.c | 121 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 125 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/mvebu/ap806-core.c

diff --git a/drivers/clk/mvebu/Kconfig b/drivers/clk/mvebu/Kconfig
index 2769625..fd84172 100644
--- a/drivers/clk/mvebu/Kconfig
+++ b/drivers/clk/mvebu/Kconfig
@@ -42,3 +42,6 @@ config KIRKWOOD_CLK
 config ORION_CLK
 	bool
 	select MVEBU_CLK_COMMON
+
+config ARMADA_AP806_CORE_CLK
+	bool
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
index 8866115..db5c28c 100644
--- a/drivers/clk/mvebu/Makefile
+++ b/drivers/clk/mvebu/Makefile
@@ -1,11 +1,11 @@
 obj-$(CONFIG_MVEBU_CLK_COMMON)	+= common.o
 obj-$(CONFIG_MVEBU_CLK_CPU) 	+= clk-cpu.o
 obj-$(CONFIG_MVEBU_CLK_COREDIV)	+= clk-corediv.o
-
 obj-$(CONFIG_ARMADA_370_CLK)	+= armada-370.o
 obj-$(CONFIG_ARMADA_375_CLK)	+= armada-375.o
 obj-$(CONFIG_ARMADA_38X_CLK)	+= armada-38x.o
 obj-$(CONFIG_ARMADA_39X_CLK)	+= armada-39x.o
+obj-$(CONFIG_ARMADA_AP806_CORE_CLK) += ap806-core.o
 obj-$(CONFIG_ARMADA_XP_CLK)	+= armada-xp.o
 obj-$(CONFIG_DOVE_CLK)		+= dove.o dove-divider.o
 obj-$(CONFIG_KIRKWOOD_CLK)	+= kirkwood.o
diff --git a/drivers/clk/mvebu/ap806-core.c b/drivers/clk/mvebu/ap806-core.c
new file mode 100644
index 0000000..b858d6b
--- /dev/null
+++ b/drivers/clk/mvebu/ap806-core.c
@@ -0,0 +1,121 @@
+/*
+ * Marvell Armada AP806 core clocks
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#define pr_fmt(fmt) "ap806-core-clk: " fmt
+
+#include <linux/kernel.h>
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/regmap.h>
+
+/*
+ * AP806 PLLs:
+ *   0 - DDR
+ *   1 - Ring
+ *   2 - CPU
+ */
+
+#define AP806_SAMPLE_AT_RESET_REG 0x204
+
+#define AP806_PLL_NUM	3
+#define AP806_PLL_FREQ  7
+
+/* SAR parameters to get the PLL data */
+struct apclk_sar {
+	int mask;
+	int offset;
+	const char *name;
+};
+
+static const struct apclk_sar
+ap806_core_clk_sar[AP806_PLL_NUM]  __initconst = {
+	{ .mask = 0x7,	.offset = 21 },
+	{ .mask = 0x7,	.offset = 18 },
+	{ .mask = 0x7,	.offset = 15 },
+};
+
+static struct clk *ap806_core_clks[AP806_PLL_NUM];
+
+static struct clk_onecell_data ap806_core_clk_data = {
+	.clks = ap806_core_clks,
+	.clk_num = AP806_PLL_NUM,
+};
+
+/* mapping between SAR value to frequency */
+static const u32
+ap806_core_clk_freq[AP806_PLL_NUM][AP806_PLL_FREQ] __initconst = {
+	{ 2400000000, 2100000000, 1800000000,
+	  1600000000, 1300000000, 1300000000,
+	  1300000000 },
+	{ 2000000000, 1800000000, 1600000000,
+	  1400000000, 1200000000, 1200000000,
+	  1200000000 },
+	{ 2500000000, 2200000000, 2000000000,
+	  1700000000, 1600000000, 1200000000,
+	  1200000000 },
+};
+
+static unsigned long __init ap806_core_clk_get_freq(u32 reg, int clk_idx)
+{
+	int freq_idx;
+	const struct apclk_sar *clk_info;
+
+	clk_info = &ap806_core_clk_sar[clk_idx];
+
+	freq_idx = (reg >> clk_info->offset) & clk_info->mask;
+	if (WARN_ON(freq_idx > AP806_PLL_FREQ))
+		return 0;
+	else
+		return ap806_core_clk_freq[clk_idx][freq_idx];
+}
+
+static void __init ap806_core_clk_init(struct device_node *np)
+{
+	struct regmap *regmap;
+	u32 reg;
+	int i;
+
+	regmap = syscon_node_to_regmap(np->parent);
+	if (IS_ERR(regmap)) {
+		pr_err("cannot get regmap\n");
+		return;
+	}
+
+	if (regmap_read(regmap, AP806_SAMPLE_AT_RESET_REG, &reg)) {
+		pr_err("cannot read from regmap\n");
+		return;
+	}
+
+	for (i = 0; i < AP806_PLL_NUM; i++) {
+		unsigned long freq;
+		const char *name;
+
+		freq = ap806_core_clk_get_freq(reg, i);
+
+		of_property_read_string_index(np, "clock-output-names",
+					      i, &name);
+
+		ap806_core_clks[i] =
+			clk_register_fixed_rate(NULL, name, NULL,
+						CLK_IS_ROOT, freq);
+	}
+
+	of_clk_add_provider(np, of_clk_src_onecell_get,
+			    &ap806_core_clk_data);
+}
+
+CLK_OF_DECLARE(ap806_core_clk, "marvell,armada-ap806-core-clock",
+	       ap806_core_clk_init);
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 24 07:16:45 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 24 Feb 2016 16:16:45 +0100
Subject: [PATCH 1/3] dt-bindings: arm/marvell: ABI unstability warning about
 Marvell 7K/8K
In-Reply-To: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1456327007-31008-2-git-send-email-thomas.petazzoni@free-electrons.com>

Since we are still very early in the support of Marvell Armada 7/8K
chips and those chips are significantly different from earlier 32 bits
Armada SOCs, it is difficult to commit to Device Tree ABI stability at
this point.

Therefore, this commit adds a warning to the Marvell 7K/8K DT binding
documentation to indicate that the bindings are for the moment
unstable.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 .../devicetree/bindings/arm/marvell/armada-7k-8k.txt         | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
index df98a9c..758b3ae 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
@@ -1,6 +1,18 @@
 Marvell Armada 7K/8K Platforms Device Tree Bindings
 ---------------------------------------------------
 
+Work in progress statement:
+
+Device tree files and bindings applying to Marvell Armada 7K and 8K
+SoCs and boards are considered "unstable". Any Marvell Armada 7K/8K
+device tree binding may change at any time. Be sure to use a device
+tree binary and a kernel image generated from the same source tree.
+
+Please refer to Documentation/devicetree/bindings/ABI.txt for a
+definition of a stable binding/ABI.
+
+---------------------------------------------------------------
+
 Boards using a SoC of the Marvell Armada 7K or 8K families must carry
 the following root node property:
 
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 24 07:16:47 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 24 Feb 2016 16:16:47 +0100
Subject: [PATCH 3/3] arm64: marvell: re-order Device Tree nodes for Armada
 AP806
In-Reply-To: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1456327007-31008-4-git-send-email-thomas.petazzoni@free-electrons.com>

The DT nodes representing the XOR engines were not placed at the
proper location to comply with the requirement of ordering DT nodes by
their unit address. This commit fixes this mistake.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 64 +++++++++++++--------------
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
index 88e3348..556a92b 100644
--- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
@@ -136,6 +136,38 @@
 				marvell,spi-base = <128>, <136>, <144>, <152>;
 			};
 
+			xor0 at 400000 {
+				compatible = "marvell,mv-xor-v2";
+				reg = <0x400000 0x1000>,
+				      <0x410000 0x1000>;
+				msi-parent = <&gic_v2m0>;
+				dma-coherent;
+			};
+
+			xor1 at 420000 {
+				compatible = "marvell,mv-xor-v2";
+				reg = <0x420000 0x1000>,
+				      <0x430000 0x1000>;
+				msi-parent = <&gic_v2m0>;
+				dma-coherent;
+			};
+
+			xor2 at 440000 {
+				compatible = "marvell,mv-xor-v2";
+				reg = <0x440000 0x1000>,
+				      <0x450000 0x1000>;
+				msi-parent = <&gic_v2m0>;
+				dma-coherent;
+			};
+
+			xor3 at 460000 {
+				compatible = "marvell,mv-xor-v2";
+				reg = <0x460000 0x1000>,
+				      <0x470000 0x1000>;
+				msi-parent = <&gic_v2m0>;
+				dma-coherent;
+			};
+
 			spi0: spi at 510600 {
 				compatible = "marvell,armada-380-spi";
 				reg = <0x510600 0x50>;
@@ -179,38 +211,6 @@
 
 			};
 
-			xor0 at 400000 {
-				compatible = "marvell,mv-xor-v2";
-				reg = <0x400000 0x1000>,
-				      <0x410000 0x1000>;
-				msi-parent = <&gic_v2m0>;
-				dma-coherent;
-			};
-
-			xor1 at 420000 {
-				compatible = "marvell,mv-xor-v2";
-				reg = <0x420000 0x1000>,
-				      <0x430000 0x1000>;
-				msi-parent = <&gic_v2m0>;
-				dma-coherent;
-			};
-
-			xor2 at 440000 {
-				compatible = "marvell,mv-xor-v2";
-				reg = <0x440000 0x1000>,
-				      <0x450000 0x1000>;
-				msi-parent = <&gic_v2m0>;
-				dma-coherent;
-			};
-
-			xor3 at 460000 {
-				compatible = "marvell,mv-xor-v2";
-				reg = <0x460000 0x1000>,
-				      <0x470000 0x1000>;
-				msi-parent = <&gic_v2m0>;
-				dma-coherent;
-			};
-
 			dfx-server at 6f8000 {
 				compatible = "simple-mfd", "syscon";
 				reg = <0x6f8000 0x70000>;
-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 24 07:16:44 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 24 Feb 2016 16:16:44 +0100
Subject: [PATCH 0/3] arm64: marvell: additional DT changes for Armada 7K/8K
Message-ID: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>

Dear mvebu maintainers,

This small set of three patches apply on top of the changes already
merged in the mvebu/dt64 branch, and make some changes to the 7K/8K
Device Trees:

 - Document that the DT bindings for this platform are unstable.

 - Adjust the armada-ap806.dtsi to the clock DT binding change which
   was requested by Rob Herring.

 - Re-order DT nodes by unit address.

Thanks!

Thomas

Thomas Petazzoni (3):
  dt-bindings: arm/marvell: ABI unstability warning about Marvell 7K/8K
  arm64: marvell: update Armada AP806 clock description
  arm64: marvell: re-order Device Tree nodes for Armada AP806

 .../bindings/arm/marvell/armada-7k-8k.txt          | 12 +++
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi      | 93 +++++++++++-----------
 2 files changed, 60 insertions(+), 45 deletions(-)

-- 
2.6.4



From thomas.petazzoni at free-electrons.com  Wed Feb 24 07:16:46 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 24 Feb 2016 16:16:46 +0100
Subject: [PATCH 2/3] arm64: marvell: update Armada AP806 clock description
In-Reply-To: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <1456327007-31008-3-git-send-email-thomas.petazzoni@free-electrons.com>

Following the review from the DT maintainers, the DT binding for the
clocks has changed, and we now use a DFX server node exposing a
syscon, with the clock nodes being subnodes of the DFX server
node. This commit therefore updates the AP806 Device Tree file to use
this new DT binding.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 37 +++++++++++++++------------
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
index 63f25ce..88e3348 100644
--- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
@@ -179,23 +179,6 @@
 
 			};
 
-			coreclk: clk at 0x6F8204 {
-				compatible = "marvell,armada-ap806-core-clock";
-				reg = <0x6F8204 0x04>;
-				#clock-cells = <1>;
-				clock-output-names = "ddr", "ring", "cpu";
-			};
-
-			ringclk: clk at 0x6F8250 {
-				compatible = "marvell,armada-ap806-ring-clock";
-				reg = <0x6F8250 0x04>;
-				#clock-cells = <1>;
-				clock-output-names = "ring-0", "ring-2",
-						     "ring-3", "ring-4",
-						     "ring-5";
-				clocks = <&coreclk 1>;
-			};
-
 			xor0 at 400000 {
 				compatible = "marvell,mv-xor-v2";
 				reg = <0x400000 0x1000>,
@@ -227,6 +210,26 @@
 				msi-parent = <&gic_v2m0>;
 				dma-coherent;
 			};
+
+			dfx-server at 6f8000 {
+				compatible = "simple-mfd", "syscon";
+				reg = <0x6f8000 0x70000>;
+
+				coreclk: clk at 204 {
+					compatible = "marvell,armada-ap806-core-clock";
+					#clock-cells = <1>;
+					clock-output-names = "ddr", "ring", "cpu";
+				};
+
+				ringclk: clk at 250 {
+					compatible = "marvell,armada-ap806-ring-clock";
+					#clock-cells = <1>;
+					clock-output-names = "ring-0", "ring-2",
+							     "ring-3", "ring-4",
+							     "ring-5";
+					clocks = <&coreclk 1>;
+				};
+			};
 		};
 	};
 
-- 
2.6.4



From marc.zyngier at arm.com  Wed Feb 24 07:21:15 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Feb 2016 15:21:15 +0000
Subject: [PATCH 5/8] arm64: kprobes instruction simulation support
In-Reply-To: <56CDC734.4000201@linaro.org>
References: <1455839301-26464-1-git-send-email-dave.long@linaro.org>
 <1455839301-26464-6-git-send-email-dave.long@linaro.org>
 <56C720F0.9080108@arm.com> <56CD5434.30108@linaro.org>
 <20160224090530.5e86e867@arm.com> <56CDC734.4000201@linaro.org>
Message-ID: <56CDCA6B.7000207@arm.com>

On 24/02/16 15:07, David Long wrote:
> On 02/24/2016 04:05 AM, Marc Zyngier wrote:
>> On Wed, 24 Feb 2016 01:56:52 -0500
>> David Long <dave.long at linaro.org> wrote:
>>
>>> On 02/19/2016 09:04 AM, Marc Zyngier wrote:
>>>> Hi David,
>>>>
>>>> On 18/02/16 23:48, David Long wrote:
>>>>> From: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>
>>>>>
>>>>> Kprobes needs simulation of instructions that cannot be stepped
>>>>> from different memory location, e.g.: those instructions
>>>>> that uses PC-relative addressing. In simulation, the behaviour
>>>>> of the instruction is implemented using a copy of pt_regs.
>>>>>
>>>>> Following instruction catagories are simulated:
>>>>>    - All branching instructions(conditional, register, and immediate)
>>>>>    - Literal access instructions(load-literal, adr/adrp)
>>>>>
>>>>> Conditional execution is limited to branching instructions in
>>>>> ARM v8. If conditions at PSTATE do not match the condition fields
>>>>> of opcode, the instruction is effectively NOP. Kprobes considers
>>>>> this case as 'miss'.
>>>>>
>>>>> This code also replaces the use of arch/arm/opcodes.c for
>>>>> arm_check_condition().
>>>>>
>>>>> Thanks to Will Cohen for assorted suggested changes.
>>>>>
>>>>> Signed-off-by: Sandeepa Prabhu <sandeepa.s.prabhu at gmail.com>
>>>>> Signed-off-by: William Cohen <wcohen at redhat.com>
>>>>> Signed-off-by: David A. Long <dave.long at linaro.org>
>>
>> [...]
>>
>>>>> +};
>>>>> +
>>>>> +asmlinkage unsigned int __kprobes arm_check_condition(u32 opcode, u32 psr)
>>>>
>>>> Why asmlinkage? This function is never called from assembly code on arm64.
>>>>
>>>
>>> This comes from the 32-bit ARM code that tests the condition from
>>> entry.S.  We include arch/arm/include/asm/opcodes.h in
>>> arch/arm64/include/asm/opcodes.h so it gets declared there with
>>> asmlinkage. I can remove the asmlinkage in the actual function
>>> definition and it still compiles but I'm not sure that is kosher.
>>
>> asmlinkage is only meaningful if you're calling it from assembly code.
>> As you seem to only call it from C code, having asmlinkage is both
>> pointless and confusing.
>>
>>> Will Deacon was advocating getting rid of the include of the 32-bit header
>>> file but it looked to me like this would mean a lot of duplicated
>>> defines and the work would be mostly unrelated to kprobes.
>>
>> Arguably, arm_check_condition() (which only matters to 32bit code,
>> hence userspace) is also completely unrelated to kprobes. I still think
>> Will's point stands.
>>
> 
> Yes, I would not argue about that cross-architecture include needing to 
> be fixed.  Can I assume you agree that need not be a part of this 
> kprobes patch though, nor a prerequisite patch for it?

My usual stand on this kind of issue is that if you start digging in the
middle of the road, you're also responsible for cleaning the pavement
(sorry if that's a bad analogy).

In the end, this is the arm64 maintainers that decide what they want to
see, and by the look of it, Will has made his point clear...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...


From thomas.petazzoni at free-electrons.com  Wed Feb 24 07:24:54 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 24 Feb 2016 16:24:54 +0100
Subject: [PATCH] dt-bindings: interrupt-controller: add SoC-specific
 compatible string to Marvell ODMI
Message-ID: <1456327494-31358-1-git-send-email-thomas.petazzoni@free-electrons.com>

As requested by Rob Herring, this commit adds a SoC-specific
compatible string to the Marvell ODMI DT binding.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
---
This commit applies on top of the Marvell ODMI driver patch, which has
already been merged.
---
 .../bindings/interrupt-controller/marvell,odmi-controller.txt      | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
index 252d5c9..8af0a8e 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt
@@ -6,7 +6,9 @@ which can be used by on-board peripheral for MSI interrupts.
 
 Required properties:
 
-- compatible           : The value here should contain "marvell,odmi-controller".
+- compatible           : The value here should contain:
+
+    "marvell,ap806-odmi-controller", "marvell,odmi-controller".
 
 - interrupt,controller : Identifies the node as an interrupt controller.
 
@@ -29,7 +31,8 @@ Required properties:
 Example:
 
 	odmi: odmi at 300000 {
-		compatible = "marvell,odmi-controller";
+		compatible = "marvell,ap806-odm-controller",
+			     "marvell,odmi-controller";
 		interrupt-controller;
 		msi-controller;
 		marvell,odmi-frames = <4>;
-- 
2.6.4



From helgaas at kernel.org  Wed Feb 24 07:25:38 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Wed, 24 Feb 2016 09:25:38 -0600
Subject: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
 HiSilicon SoCs Host Controllers
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1ECCAD6A@lhreml503-mbs>
References: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
 <1455039260-6040-4-git-send-email-gabriele.paoloni@huawei.com>
 <20160209182429.GD4348@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1591@lhreml503-mbs>
 <20160210111234.GC2632@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1D30@lhreml503-mbs>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECC5F00@lhreml503-mbs>
 <20160224011418.GB13026@localhost>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECCAD6A@lhreml503-mbs>
Message-ID: <20160224152538.GA19700@localhost>

On Wed, Feb 24, 2016 at 06:46:09AM +0000, Gabriele Paoloni wrote:
> 
> Hi Bjorn, many thanks for replying
> 
> > -----Original Message-----
> > From: Bjorn Helgaas [mailto:helgaas at kernel.org]
> > Sent: 24 February 2016 09:14
> > To: Gabriele Paoloni
> > Cc: 'Mark Rutland'; Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong
> > (C); Linuxarm; qiujiang; 'bhelgaas at google.com'; 'arnd at arndb.de';
> > 'Lorenzo.Pieralisi at arm.com'; 'tn at semihalf.com'; 'linux-
> > pci at vger.kernel.org'; 'linux-kernel at vger.kernel.org'; xuwei (O);
> > 'linux-acpi at vger.kernel.org'; 'jcm at redhat.com'; zhangjukuo; Liguozhu
> > (Kenneth); 'linux-arm-kernel at lists.infradead.org'
> > Subject: Re: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
> > HiSilicon SoCs Host Controllers
> > 
> > On Tue, Feb 23, 2016 at 02:47:22AM +0000, Gabriele Paoloni wrote:
> > > > -----Original Message-----
> > > > From: Gabriele Paoloni
> > > > Sent: 10 February 2016 22:45
> > > > To: Mark Rutland
> > > > Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C); Linuxarm;
> > > > qiujiang; bhelgaas at google.com; arnd at arndb.de;
> > Lorenzo.Pieralisi at arm.com;
> > > > tn at semihalf.com; linux-pci at vger.kernel.org; linux-
> > > > kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> > > > jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth); linux-arm-
> > > > kernel at lists.infradead.org
> > > > Subject: RE: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support
> > for
> > > > HiSilicon SoCs Host Controllers
> > > >
> > > > > -----Original Message-----
> > > > > From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> > > > > owner at vger.kernel.org] On Behalf Of Mark Rutland
> > > > > Sent: 10 February 2016 11:13
> > > > > To: Gabriele Paoloni
> > > > > Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C);
> > Linuxarm;
> > > > > qiujiang; bhelgaas at google.com; arnd at arndb.de;
> > > > > Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-
> > pci at vger.kernel.org;
> > > > > linux-kernel at vger.kernel.org; xuwei (O); linux-
> > acpi at vger.kernel.org;
> > > > > jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth); linux-arm-
> > > > > kernel at lists.infradead.org
> > > > > Subject: Re: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support
> > for
> > > > > HiSilicon SoCs Host Controllers
> > > > >
> > > > > On Wed, Feb 10, 2016 at 09:52:36AM +0000, Gabriele Paoloni wrote:
> > > > > > Hi Mark
> > > > > >
> > > > > > > On Tue, Feb 09, 2016 at 05:34:20PM +0000, Gabriele Paoloni
> > wrote:
> > > > > > > > From: gabriele paoloni <gabriele.paoloni at huawei.com>
> > > > > > > > +/*
> > > > > > > > + * Retrieve rc_dbi base and size from _DSD
> > > > > > > > + * Name (_DSD, Package () {
> > > > > > > > + *	ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > > > > > > > + *	Package () {
> > > > > > > > + *	Package () {"rc-dbi", Package () { 0x0, 0xb0080000,
> > 0x0,
> > > > > 0x10000
> > > > > > > }},
> > > > > > > > + *	}
> > > > > > > > + *	})
> > > > > > > > + */
> > > > > > >
> > > > > > > As above, this does not look right. ACPI has standard
> > mechanisms
> > > > > for
> > > > > > > describing addresses. Making something up like this is not a
> > good
> > > > > idea.
> > > > > >
> > > > > > I am quite new to ACPI, may I ask you to explain a bit?
> > > > >
> > > > > ACPI has standard mechanisms for describing certain resources,
> > and
> > > > > these
> > > > > should not be described in _DSD. Memory or IO address regions are
> > > > such
> > > > > resources (in _CRS, IIRC), and should not be described in _DSD.
> > > >
> > > > Hi Mark,
> > > >
> > > > In my case I think in need to look into the MCFG object as the
> > problem
> > > > I have is RC using a different range than the rest of the hierarchy.
> > > >
> > > > I'll investigate this and try to come with a solution in v4
> > >
> > > I have looked into this and in our case we cannot use the
> > > standard MCFG object to pass the RC config space addresses.
> > >
> > > The reason is that in our HW we have the config base addresses of the
> > > root complex ports that are less than 0x100000 byte distant one from
> > > the other as we only map the first 0x10000 bytes.
> > 
> > The ECAM spec requires 4096 bytes per function, 8 functions per
> > device, 32 devices per bus, which means you need 0x100000 bytes of
> > address space per bus.  If your device doesn't supply that, it doesn't
> > really implement ECAM, and you probably can't use the standard ways of
> > describing ECAM (MCFG, _CBA).
> 
> Correct, our host bridge is non ECAM only for the RC bus config space;
> for any other bus underneath the root bus we support ECAM access, so
> we need a quirk for the RC config rd/wr  

MCFG can specify a bus number range, so you might be able to use it
to describe the ECAM space for buses below the root bus, e.g.,
[bus 01-ff].

> > > Now the MCFG acpi framework always fix the MCFG resource size to
> > 0x100000
> > > for each bus; therefore if we pass our RC addresses through MCFG we
> > end
> > > up with a resource conflict.
> > >
> > > To give you a practical example we are in a situation where we have:
> > >
> > > port0: [0x00000000b0080000 - 0x00000000b0080000 + 0x10000]
> > > port1: [0x00000000b0090000 - 0x00000000b0090000 + 0x10000]
> > > port2: [0x00000000b00A0000 - 0x00000000b00A0000 + 0x10000]
> > > port3: [0x00000000b00B0000 - 0x00000000b00B0000 + 0x10000]
> > >
> > > So if we pass the base addresses through MCFG the resources
> > > will overlap as MCFG will consider 0x100000 size for each base
> > > address of the root complex (only the RC bus uses that address)
> > >
> > > So far I do not see many option other than using _DSD to pass
> > > these RC config base addresses.
> > 
> > I don't want to take over Mark's discussion, but I really do not think
> > _DSD is the correct way to fix this.  _CRS is like a generalized PCI
> > BAR.  A PCI device is only allowed to respond to address space
> > reported via a BAR.  An ACPI device is only allowed to respond to
> > address space reported via _CRS.  Those are important rules because
> > they mean we can manage address space with generic code instead of
> > device-specific code.
> 
> From what I see in 
> http://lxr.free-electrons.com/source/drivers/acpi/pci_root.c#L723
> acpi_pci_probe_root_resources() parses the _CRS method and
> it only works for MEM and IO resources, so I don't think it is 
> right to pass a config space address by _CRS or to modify the 
> current ACPI framework to support this.

Config space addresses are made up of [bus, device, function, register
offset], and you're right that _CRS doesn't contain those addresses
directly; _CRS only describes memory, I/O, and bus number ranges.

But part of the function of a host bridge is to convert memory or I/O
accesses on the primary (CPU) side to PCI config accesses on the
secondary (PCI) side, and this CPU-side memory or I/O region should be
reported via _CRS.

I think the relevant spec is the PCI Firmware Spec, r3.0, sec 4.1.2.
Note 2 in that section says the address range of an MMCFG region
must be reserved by declaring a motherboard resource, i.e., included
in the _CRS of a PNP0C02 or similar device.

> On the other side, since this is an exception only for the config
> space address of our host controller (as said before all the buses
> below the root one support ECAM), I think that it is right to put
> this address as a device specific data (in fact the rest of the
> config space addresses will be parsed from MCFG).

A kernel with no support for your host controller (and thus no
knowledge of its _DSD) should still be able to operate the rest of the
system correctly.  That means we must have a generic way to learn what
address space is consumed by the host controller so we don't try to
assign it to other devices.

Bjorn


From petr at barix.com  Wed Feb 24 07:41:49 2016
From: petr at barix.com (Petr Kulhavy)
Date: Wed, 24 Feb 2016 16:41:49 +0100
Subject: [PATCH v2] ARM: DaVinci USB: removed deprecated properties from MUSB
 config
Message-ID: <1456328509-17839-1-git-send-email-petr@barix.com>

The following properties of the musb_hdrc_config structure
are deprecated and no longer required/used by the MUSB driver:

.dyn_fifo
.soft_con
.dma
.dma_channels
.eps_bits

Signed-off-by: Petr Kulhavy <petr at barix.com>
---
v1: <initial>

v2:
 - patch recreated for the 4.5-rc2 tree

 arch/arm/mach-davinci/usb.c | 16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/arch/arm/mach-davinci/usb.c b/arch/arm/mach-davinci/usb.c
index b0a6b52..6ed5a54 100644
--- a/arch/arm/mach-davinci/usb.c
+++ b/arch/arm/mach-davinci/usb.c
@@ -19,27 +19,11 @@
 #define DA8XX_USB1_BASE 	0x01e25000
 
 #if IS_ENABLED(CONFIG_USB_MUSB_HDRC)
-static struct musb_hdrc_eps_bits musb_eps[] = {
-	{ "ep1_tx", 8, },
-	{ "ep1_rx", 8, },
-	{ "ep2_tx", 8, },
-	{ "ep2_rx", 8, },
-	{ "ep3_tx", 5, },
-	{ "ep3_rx", 5, },
-	{ "ep4_tx", 5, },
-	{ "ep4_rx", 5, },
-};
-
 static struct musb_hdrc_config musb_config = {
 	.multipoint	= true,
-	.dyn_fifo	= true,
-	.soft_con	= true,
-	.dma		= true,
 
 	.num_eps	= 5,
-	.dma_channels	= 8,
 	.ram_bits	= 10,
-	.eps_bits	= musb_eps,
 };
 
 static struct musb_hdrc_platform_data usb_data = {
-- 
1.9.1



From robin.murphy at arm.com  Wed Feb 24 07:48:57 2016
From: robin.murphy at arm.com (Robin Murphy)
Date: Wed, 24 Feb 2016 15:48:57 +0000
Subject: [PATCH] ARM: realview: DT support for the PBA8
In-Reply-To: <56CDA0F0.9050608@arm.com>
References: <1456303714-31039-1-git-send-email-linus.walleij@linaro.org>
 <56CDA0F0.9050608@arm.com>
Message-ID: <56CDD0E9.70504@arm.com>

On 24/02/16 12:24, Robin Murphy wrote:
> Hi Linus,
>
> On 24/02/16 08:48, Linus Walleij wrote:
>> This adds a devicetree for the ARM RealView PBA8 platform,
>> also known as HBI-0178, "RealView(R) Platform Baseboard for
>> Cortex(TM)-A8".
>>
>> Tested in QEMU with -M realview-pb-a8 and works like a charm,
>> however with these annoying boot messages:
>>
>> of_amba_device_create(): amba_device_add()
>>      failed (-19) for /soc/sysctl at 10001000
>> of_amba_device_create(): amba_device_add()
>>      failed (-19) for /soc/ssp at 1000d000
>> of_amba_device_create(): amba_device_add()
>>      failed (-19) for /soc/timer at 10018000
>> of_amba_device_create(): amba_device_add()
>>      failed (-19) for /soc/timer at 10019000
>> of_amba_device_create(): amba_device_add()
>>      failed (-19) for /soc/sysctl at 1001a000
>>
>> I think this is because these PrimeCells do not exist in the
>> QEMU machine model but would work fine on the real hardware.
>> QEMU still works, because the SP810 clocks will anyway probe,
>> as they are not amba_devices but use the special CLK_OF_DECLARE()
>> probing macro.
>
> And here I thought that big black box on the far corner of my desk was
> only good for taking up space. I have no idea of its provenance, but
> here's what it had to say (using appended dtb and a hack in the
> decompressor to set r1=-1, r2=0 because I can't be bothered faffing with
> a 2010-vintage u-boot):
>
> RealView PBA8 #go 0x7fc0
> ## Starting application at 0x00007FC0 ...
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0

[...]

> pl061_gpio 10013000.gpio: PL061 GPIO chip @0x10013000 registered
> pl061_gpio 10014000.gpio: PL061 GPIO chip @0x10014000 registered
> pl061_gpio 10015000.gpio: PL061 GPIO chip @0x10015000 registered

[...]

> mmci-pl18x 10005000.mmcsd: Got CD GPIO
> mmci-pl18x 10005000.mmcsd: Got WP GPIO

[...]

> Waiting for root device /dev/mmcblk0p1...
>
>
> It then fails to notice my SD card, even if I eject and reinsert it :(

Ah, it's because it's requesting those GPIOS from &gpio1, rather than 
&gpio2 where they really are. With that fixed up the card detect now 
works, but apparently nothing I have around my desk actually supports 
3.3V...

Robin.



From linus.walleij at linaro.org  Wed Feb 24 07:52:24 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 24 Feb 2016 16:52:24 +0100
Subject: [PATCH] ARM: realview: DT support for the PBA8
In-Reply-To: <56CDA0F0.9050608@arm.com>
References: <1456303714-31039-1-git-send-email-linus.walleij@linaro.org>
 <56CDA0F0.9050608@arm.com>
Message-ID: <CACRpkdbQKZxMgYRUq6cjAXHq5q1EufVwcHG=wJ0QsDcqUVoRhQ@mail.gmail.com>

On Wed, Feb 24, 2016 at 1:24 PM, Robin Murphy <robin.murphy at arm.com> wrote:

> And here I thought that big black box on the far corner of my desk was only
> good for taking up space. I have no idea of its provenance, but here's what
> it had to say (using appended dtb and a hack in the decompressor to set
> r1=-1, r2=0 because I can't be bothered faffing with a 2010-vintage u-boot):

Nice! Thanks!

> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at drivers/clk/versatile/clk-sp810.c:137

This noise is fixed in another separate patch I sent earlier:
http://permalink.gmane.org/gmane.linux.kernel.clk/4383

> Waiting for root device /dev/mmcblk0p1...
>
> It then fails to notice my SD card, even if I eject and reinsert it :(

Fixing a v2 as we speak.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Wed Feb 24 07:54:36 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 24 Feb 2016 16:54:36 +0100
Subject: [PATCH] ARM: realview: DT support for the PBA8 and PBX-A9
Message-ID: <1456329276-29529-1-git-send-email-linus.walleij@linaro.org>

This adds a devicetree for the ARM RealView PBA8 platform,
also known as HBI-0178, "RealView Platform Baseboard for
Cortex-A8" and PBX-A9 "RealView Platform Baseboard
Explore for Cortex-A9"

Tested in QEMU with -M realview-pb-a8, as well as with
-M realview-pbx-a9 -smp cpus=2

Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Peter Maydell <peter.maydell at linaro.org>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: Robin Murphy <robin.murphy at arm.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- Realized that the PBA8 and the PBX-A9 is very similar so
  merged these machines into one patch sharing a common PBX
  .dtsi file and enabled PBX-A9 as well.
- Fixed the assignment of the SD/MMC card detect to route
  to gpio instance 2.
- Drop QEMU sob story from commit message.
---
 arch/arm/boot/dts/Makefile                |   4 +-
 arch/arm/boot/dts/arm-realview-pba8.dts   | 178 ++++++++++
 arch/arm/boot/dts/arm-realview-pbx-a9.dts | 229 +++++++++++++
 arch/arm/boot/dts/arm-realview-pbx.dtsi   | 542 ++++++++++++++++++++++++++++++
 4 files changed, 952 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/arm-realview-pba8.dts
 create mode 100644 arch/arm/boot/dts/arm-realview-pbx-a9.dts
 create mode 100644 arch/arm/boot/dts/arm-realview-pbx.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 39deb1741465..74261429e679 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -537,7 +537,9 @@ dtb-$(CONFIG_ARCH_REALVIEW) += \
 	arm-realview-eb.dtb \
 	arm-realview-eb-11mp.dtb \
 	arm-realview-eb-11mp-revb.dtb \
-	arm-realview-eb-a9mp.dtb
+	arm-realview-eb-a9mp.dtb \
+	arm-realview-pba8.dtb \
+	arm-realview-pbx-a9.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3036-evb.dtb \
 	rk3036-kylin.dtb \
diff --git a/arch/arm/boot/dts/arm-realview-pba8.dts b/arch/arm/boot/dts/arm-realview-pba8.dts
new file mode 100644
index 000000000000..d3238c252b59
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-pba8.dts
@@ -0,0 +1,178 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "arm-realview-pbx.dtsi"
+
+/ {
+	model = "ARM RealView Platform Baseboard for Cortex-A8";
+	compatible = "arm,realview-pba8";
+	arm,hbi = <0x178>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		enable-method = "arm,realview-smp";
+
+		cpu0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a8";
+			reg = <0>;
+		};
+	};
+
+	pmu: pmu at 0 {
+		compatible = "arm,cortex-a8-pmu";
+		interrupt-parent = <&intc>;
+		interrupts = <0 47 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&cpu0>;
+	};
+
+	/* Primary GIC PL390 interrupt controller in the test chip */
+	intc: interrupt-controller at 1e000000 {
+		compatible = "arm,pl390";
+		#interrupt-cells = <3>;
+		#address-cells = <1>;
+		interrupt-controller;
+		reg = <0x1e001000 0x1000>,
+		      <0x1e000000 0x100>;
+	};
+};
+
+&ethernet {
+	interrupt-parent = <&intc>;
+	interrupts = <0 28 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&usb {
+	interrupt-parent = <&intc>;
+	interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&soc {
+	compatible = "arm,realview-pba8-soc", "simple-bus";
+};
+
+&syscon {
+	compatible = "arm,realview-pba8-syscon", "syscon", "simple-mfd";
+};
+
+&serial0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 12 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 13 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial2 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial3 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 15 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&ssp {
+	interrupt-parent = <&intc>;
+	interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&wdog0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&wdog1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer01 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer23 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio2 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&rtc {
+	interrupt-parent = <&intc>;
+	interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer45 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer67 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 42 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&aaci {
+	interrupt-parent = <&intc>;
+	interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&mmc {
+	interrupt-parent = <&intc>;
+	interrupts = <0 17 IRQ_TYPE_LEVEL_HIGH>,
+		     <0 18 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&kmi0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&kmi1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&clcd {
+	interrupt-parent = <&intc>;
+	interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
+};
diff --git a/arch/arm/boot/dts/arm-realview-pbx-a9.dts b/arch/arm/boot/dts/arm-realview-pbx-a9.dts
new file mode 100644
index 000000000000..db808f92dd79
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-pbx-a9.dts
@@ -0,0 +1,229 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "arm-realview-pbx.dtsi"
+
+/ {
+	/*
+	 * This is the RealView Platform Baseboard Explore for Cortex-A9
+	 * (HBI0182 + HBI0183) as described in ARM DUI 0440B
+	 */
+	model = "ARM RealView Platform Baseboard Explore for Cortex-A9";
+	arm,hbi = <0x182>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		enable-method = "arm,realview-smp";
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&CPU0>;
+				};
+				core1 {
+					cpu = <&CPU1>;
+				};
+			};
+		};
+		CPU0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0x0>;
+			next-level-cache = <&L2>;
+		};
+		CPU1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a9";
+			reg = <0x1>;
+			next-level-cache = <&L2>;
+		};
+	};
+
+	L2: l2-cache {
+		compatible = "arm,pl310-cache";
+		reg = <0x1f002000 0x1000>;
+		cache-unified;
+		cache-level = <2>;
+		/*
+		 * Override default cache size, sets and
+		 * associativity as these may be erroneously set
+		 * up by boot loader(s).
+		 */
+		cache-size = <1048576>; // 1MB
+		cache-sets = <4096>;
+		cache-line-size = <32>;
+		arm,parity-disable;
+		arm,tag-latency = <1>;
+		arm,data-latency = <1 1>;
+		arm,dirty-latency = <1>;
+	};
+
+	scu: scu at 1f000000 {
+		compatible = "arm,cortex-a9-scu";
+		reg = <0x1f000000 0x100>;
+	};
+
+	twd_timer: timer at 1f000600 {
+		compatible = "arm,cortex-a9-twd-timer";
+		reg = <0x1f000600 0x20>;
+		interrupt-parent = <&intc>;
+		interrupts = <1 13 0xf04>;
+	};
+
+	twd_wdog: watchdog at 1f000620 {
+		compatible = "arm,cortex-a9-twd-wdt";
+		reg = <0x1f000620 0x20>;
+		interrupt-parent = <&intc>;
+		interrupts = <1 14 0xf04>;
+	};
+
+	pmu: pmu at 0 {
+		compatible = "arm,cortex-a9-pmu";
+		interrupt-parent = <&intc>;
+		interrupts = <0 44 IRQ_TYPE_LEVEL_HIGH>,
+			     <0 45 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-affinity = <&CPU0>, <&CPU1>;
+	};
+
+	/* Primary GIC PL390 interrupt controller in the test chip */
+	intc: interrupt-controller at 1f000000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <1>;
+		interrupt-controller;
+		reg = <0x1f001000 0x1000>,
+		      <0x1f000100 0x100>;
+	};
+};
+
+&ethernet {
+	interrupt-parent = <&intc>;
+	interrupts = <0 28 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&usb {
+	interrupt-parent = <&intc>;
+	interrupts = <0 29 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 12 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 13 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial2 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&serial3 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 15 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&ssp {
+	interrupt-parent = <&intc>;
+	interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&wdog0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&wdog1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer01 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer23 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 5 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 6 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 7 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&gpio2 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&rtc {
+	interrupt-parent = <&intc>;
+	interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer45 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&timer67 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 42 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&aaci {
+	interrupt-parent = <&intc>;
+	interrupts = <0 19 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&mmc {
+	interrupt-parent = <&intc>;
+	interrupts = <0 17 IRQ_TYPE_LEVEL_HIGH>,
+		     <0 18 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&kmi0 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 20 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&kmi1 {
+	interrupt-parent = <&intc>;
+	interrupts = <0 21 IRQ_TYPE_LEVEL_HIGH>;
+};
+
+&clcd {
+	interrupt-parent = <&intc>;
+	interrupts = <0 23 IRQ_TYPE_LEVEL_HIGH>;
+};
diff --git a/arch/arm/boot/dts/arm-realview-pbx.dtsi b/arch/arm/boot/dts/arm-realview-pbx.dtsi
new file mode 100644
index 000000000000..aeb49c4bd773
--- /dev/null
+++ b/arch/arm/boot/dts/arm-realview-pbx.dtsi
@@ -0,0 +1,542 @@
+/*
+ * Copyright 2016 Linaro Ltd
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "skeleton.dtsi"
+
+/ {
+	compatible = "arm,realview-pbx";
+
+	chosen { };
+
+	aliases {
+		serial0 = &serial0;
+		serial1 = &serial1;
+		serial2 = &serial2;
+		serial3 = &serial3;
+		i2c0 = &i2c;
+	};
+
+	memory {
+		/* 128 MiB memory @ 0x0 */
+		reg = <0x00000000 0x08000000>;
+	};
+
+	/* The voltage to the MMC card is hardwired at 3.3V */
+	vmmc: fixedregulator at 0 {
+		compatible = "regulator-fixed";
+		regulator-name = "vmmc";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+        };
+
+	veth: fixedregulator at 0 {
+		compatible = "regulator-fixed";
+		regulator-name = "veth";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-boot-on;
+	};
+
+	xtal24mhz: xtal24mhz at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <24000000>;
+	};
+
+	refclk32khz: refclk32khz {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <32768>;
+	};
+
+	timclk: timclk at 1M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <24>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	mclk: mclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	kmiclk: kmiclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	sspclk: sspclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	uartclk: uartclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	wdogclk: wdogclk at 24M {
+		#clock-cells = <0>;
+		compatible = "fixed-factor-clock";
+		clock-div = <1>;
+		clock-mult = <1>;
+		clocks = <&xtal24mhz>;
+	};
+
+	/* FIXME: this actually hangs off the PLL clocks */
+	pclk: pclk at 0 {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <0>;
+	};
+
+	flash0 at 40000000 {
+		/* 2 * 32MiB NOR Flash memory */
+		compatible = "arm,versatile-flash", "cfi-flash";
+		reg = <0x40000000 0x04000000>;
+		bank-width = <4>;
+	};
+
+	flash1 at 44000000 {
+		/* 2 * 32MiB NOR Flash memory */
+		compatible = "arm,versatile-flash", "cfi-flash";
+		reg = <0x44000000 0x04000000>;
+		bank-width = <4>;
+	};
+
+	/* SMSC 9118 ethernet with PHY and EEPROM */
+	ethernet: ethernet at 4e000000 {
+		compatible = "smsc,lan9118", "smsc,lan9115";
+		reg = <0x4e000000 0x10000>;
+		phy-mode = "mii";
+		reg-io-width = <4>;
+		smsc,irq-active-high;
+		smsc,irq-push-pull;
+		vdd33a-supply = <&veth>;
+		vddvario-supply = <&veth>;
+	};
+
+	usb: usb at 4f000000 {
+		compatible = "nxp,usb-isp1761";
+		reg = <0x4f000000 0x20000>;
+		port1-otg;
+	};
+
+	soc: soc at 0 {
+		compatible = "arm,realview-pbx-soc", "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		regmap = <&syscon>;
+		ranges;
+
+		syscon: syscon at 10000000 {
+			compatible = "arm,realview-pbx-syscon", "syscon", "simple-mfd";
+			reg = <0x10000000 0x1000>;
+
+			led at 08.0 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x01>;
+				label = "versatile:0";
+				linux,default-trigger = "heartbeat";
+				default-state = "on";
+			};
+			led at 08.1 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x02>;
+				label = "versatile:1";
+				linux,default-trigger = "mmc0";
+				default-state = "off";
+			};
+			led at 08.2 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x04>;
+				label = "versatile:2";
+				linux,default-trigger = "cpu0";
+				default-state = "off";
+			};
+			led at 08.3 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x08>;
+				label = "versatile:3";
+				default-state = "off";
+			};
+			led at 08.4 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x10>;
+				label = "versatile:4";
+				default-state = "off";
+			};
+			led at 08.5 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x20>;
+				label = "versatile:5";
+				default-state = "off";
+			};
+			led at 08.6 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x40>;
+				label = "versatile:6";
+				default-state = "off";
+			};
+			led at 08.7 {
+				compatible = "register-bit-led";
+				offset = <0x08>;
+				mask = <0x80>;
+				label = "versatile:7";
+				default-state = "off";
+			};
+			oscclk0: osc0 at 0c {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x0C>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk1: osc1 at 10 {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x10>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk2: osc2 at 14 {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x14>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk3: osc3 at 18 {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x18>;
+				clocks = <&xtal24mhz>;
+			};
+			oscclk4: osc4 at 1c {
+				compatible = "arm,syscon-icst307";
+				#clock-cells = <0>;
+				lock-offset = <0x20>;
+				vco-offset = <0x1c>;
+				clocks = <&xtal24mhz>;
+			};
+		};
+
+		sp810_syscon0: sysctl at 10001000 {
+			compatible = "arm,sp810", "arm,primecell";
+			reg = <0x10001000 0x1000>;
+			clocks = <&refclk32khz>, <&timclk>, <&xtal24mhz>;
+			clock-names = "refclk", "timclk", "apb_pclk";
+			#clock-cells = <1>;
+			clock-output-names = "timerclk0",
+					     "timerclk1",
+					     "timerclk2",
+					     "timerclk3";
+			assigned-clocks = <&sp810_syscon0 0>,
+					  <&sp810_syscon0 1>,
+					  <&sp810_syscon0 2>,
+					  <&sp810_syscon0 3>;
+			assigned-clock-parents = <&timclk>,
+					       <&timclk>,
+					       <&timclk>,
+					       <&timclk>;
+		};
+
+		i2c: i2c at 10002000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "arm,versatile-i2c";
+			reg = <0x10002000 0x1000>;
+
+			rtc at 68 {
+				compatible = "dallas,ds1338";
+				reg = <0x68>;
+			};
+		};
+
+		serial0: serial at 10009000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x10009000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+		};
+
+		serial1: serial at 1000a000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x1000a000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+		};
+
+		serial2: serial at 1000b000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x1000b000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+		};
+
+		ssp: ssp at 1000d000 {
+			compatible = "arm,pl022", "arm,primecell";
+			reg = <0x1000d000 0x1000>;
+			clocks = <&sspclk>, <&pclk>;
+			clock-names = "SSPCLK", "apb_pclk";
+		};
+
+		wdog0: watchdog at 1000f000 {
+			compatible = "arm,sp805", "arm,primecell";
+			reg = <0x1000f000 0x1000>;
+			clocks = <&wdogclk>, <&pclk>;
+			clock-names = "wdogclk", "apb_pclk";
+			status = "disabled";
+		};
+
+		wdog1: watchdog at 10010000 {
+			compatible = "arm,sp805", "arm,primecell";
+			reg = <0x10010000 0x1000>;
+			clocks = <&wdogclk>, <&pclk>;
+			clock-names = "wdogclk", "apb_pclk";
+			status = "disabled";
+		};
+
+		timer01: timer at 10011000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x10011000 0x1000>;
+			clocks = <&sp810_syscon0 0>,
+			         <&sp810_syscon0 1>,
+				 <&pclk>;
+			clock-names = "timerclk0",
+				    "timerclk1",
+				    "apb_pclk";
+		};
+
+		timer23: timer at 10012000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x10012000 0x1000>;
+			clocks = <&sp810_syscon0 2>,
+			         <&sp810_syscon0 3>,
+				 <&pclk>;
+			clock-names = "timerclk2",
+				    "timerclk3",
+				    "apb_pclk";
+		};
+
+		gpio0: gpio at 10013000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x10013000 0x1000>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio1: gpio at 10014000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x10014000 0x1000>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		gpio2: gpio at 10015000 {
+			compatible = "arm,pl061", "arm,primecell";
+			reg = <0x10015000 0x1000>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		/* DVI serial bus control is at 10016000 */
+
+		rtc: rtc at 10017000 {
+			compatible = "arm,pl031", "arm,primecell";
+			reg = <0x10017000 0x1000>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		timer45: timer at 10018000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x10018000 0x1000>;
+			clocks = <&timclk>, <&timclk>, <&pclk>;
+			clock-names = "timerclk4", "timerclk5", "apb_pclk";
+		};
+
+		timer67: timer at 10019000 {
+			compatible = "arm,sp804", "arm,primecell";
+			reg = <0x10019000 0x1000>;
+			clocks = <&timclk>, <&timclk>, <&pclk>;
+			clock-names = "timerclk6", "timerclk7", "apb_pclk";
+		};
+
+		sp810_syscon1: sysctl at 1001a000 {
+			compatible = "arm,sp810", "arm,primecell";
+			reg = <0x1001a000 0x1000>;
+			clocks = <&refclk32khz>, <&timclk>, <&xtal24mhz>;
+			clock-names = "refclk", "timclk", "apb_pclk";
+			#clock-cells = <1>;
+			clock-output-names = "timerclk4",
+					     "timerclk5",
+					     "timerclk6",
+					     "timerclk7";
+			assigned-clocks = <&sp810_syscon1 0>,
+					  <&sp810_syscon1 1>,
+					  <&sp810_syscon1 2>,
+					  <&sp810_syscon1 3>;
+			assigned-clock-parents = <&timclk>,
+					       <&timclk>,
+					       <&timclk>,
+					       <&timclk>;
+		};
+	};
+
+
+	/* These peripherals are inside the FPGA */
+	fpga {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		ranges;
+
+		aaci: aaci at 10004000 {
+			compatible = "arm,pl041", "arm,primecell";
+			reg = <0x10004000 0x1000>;
+			clocks = <&pclk>;
+			clock-names = "apb_pclk";
+		};
+
+		mmc: mmcsd at 10005000 {
+			compatible = "arm,pl18x", "arm,primecell";
+			reg = <0x10005000 0x1000>;
+
+			/* Due to frequent FIFO overruns, use just 500 kHz */
+			max-frequency = <500000>;
+			bus-width = <4>;
+			cap-sd-highspeed;
+			cap-mmc-highspeed;
+			clocks = <&mclk>, <&pclk>;
+			clock-names = "mclk", "apb_pclk";
+			vmmc-supply = <&vmmc>;
+			cd-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+			wp-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
+		};
+
+		kmi0: kmi at 10006000 {
+			compatible = "arm,pl050", "arm,primecell";
+			reg = <0x10006000 0x1000>;
+			clocks = <&kmiclk>, <&pclk>;
+			clock-names = "KMIREFCLK", "apb_pclk";
+		};
+
+		kmi1: kmi at 10007000 {
+			compatible = "arm,pl050", "arm,primecell";
+			reg = <0x10007000 0x1000>;
+			clocks = <&kmiclk>, <&pclk>;
+			clock-names = "KMIREFCLK", "apb_pclk";
+		};
+
+		serial3: serial at 1000c000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x1000c000 0x1000>;
+			clocks = <&uartclk>, <&pclk>;
+			clock-names = "uartclk", "apb_pclk";
+		};
+	};
+
+	/* These peripherals are inside the NEC ISSP */
+	issp {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "simple-bus";
+		ranges;
+
+		clcd: clcd at 10020000 {
+			compatible = "arm,pl111", "arm,primecell";
+			reg = <0x10020000 0x1000>;
+			interrupt-names = "combined";
+			clocks = <&oscclk4>, <&pclk>;
+			clock-names = "clcdclk", "apb_pclk";
+
+			port {
+				clcd_pads: endpoint {
+					remote-endpoint = <&clcd_panel>;
+					arm,pl11x,tft-r0g0b0-pads = <0 8 16>;
+				};
+			};
+
+			panel {
+				compatible = "panel-dpi";
+
+				port {
+					clcd_panel: endpoint {
+						remote-endpoint = <&clcd_pads>;
+					};
+				};
+
+				/* Standard 640x480 VGA timings */
+				panel-timing {
+					clock-frequency = <25175000>;
+					hactive = <640>;
+					hback-porch = <48>;
+					hfront-porch = <16>;
+					hsync-len = <96>;
+					vactive = <480>;
+					vback-porch = <33>;
+					vfront-porch = <10>;
+					vsync-len = <2>;
+				};
+			};
+		};
+	};
+};
+
-- 
2.4.3



From Tirumalesh.Chalamarla at caviumnetworks.com  Wed Feb 24 07:54:48 2016
From: Tirumalesh.Chalamarla at caviumnetworks.com (Chalamarla, Tirumalesh)
Date: Wed, 24 Feb 2016 15:54:48 +0000
Subject: [PATCH V2] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <20160224113227.GB11579@leverpostej>
References: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160223122616.GE4989@leverpostej> <56CCF03D.3000809@caviumnetworks.com>
 <20160224113227.GB11579@leverpostej>
Message-ID: <1452D0BB-4AF3-4A19-983A-3A54E94A4F2F@caviumnetworks.com>






On 2/24/16, 3:32 AM, "Mark Rutland" <mark.rutland at arm.com> wrote:

>On Tue, Feb 23, 2016 at 03:50:21PM -0800, Tirumalesh Chalamarla wrote:
>> in Summary,
>> 
>> if i change asid-base to cavium,asid-base and still use DT for
>> supplying base value, is this a solution that will be accepted, 
>
>No. The property is _insufficient_, regardless of its name. This has
>been pointed out more than once.
>
>A base alone does not tell you what set of IDs it is valid to use
>without risking a clash. The OS is well within its rights to allocate
>_any_ ID above that base. It is not a requirement of the hardware nor
>the binding that the OS allocate a contiguous set of IDs starting at the
>base.
>
>Consider:
>
>smmu_a {
>	whatver,*id-base = <128>;
>};
>
>smmu_b {
>	whatever,*id-base = <64>;
>};
>
>In both cases, the *IDs 129+ could be allocated on both SMMUs.

Does adding a check to see if base + number of contexts supported will not overlap with each other
Make it acceptable. 
Or do you want the size be provided from DT also?

Thanks,
Tirumalesh. 
>
>Mark.
>
>> of course i will do range check to see we are not supplying 16bit VMID
>> for 8 bit systems even though the property now indicates Cavium only.
>> 
>> Thanks,
>> Tirumalesh.
>> 
>> On 02/23/2016 04:26 AM, Mark Rutland wrote:
>> >On Thu, Feb 18, 2016 at 10:29:18AM -0800, tchalamarla at caviumnetworks.com wrote:
>> >>From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>> >>
>> >>Due to Errata#27704 CN88xx SMMUv2,supports  only shared ASID and VMID
>> >>namespaces; specifically within a given node SMMU0 and SMMU1 share,
>> >>as does SMMU2 and SMMU3.
>> >>
>> >>This patch tries to address these issuee by supplying asid and vmid
>> >>base from devicetree.
>> >>
>> >>changes from V1:
>> >>	- rebased on top of 16 bit VMID patch
>> >>	- removed redundent options from DT
>> >>	- insted of transform, DT now supplies starting ASID/VMID
>> >>
>> >>Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
>> >>Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>> >>---
>> >>  .../devicetree/bindings/iommu/arm,smmu.txt         |  8 +++++
>> >>  drivers/iommu/arm-smmu.c                           | 37 +++++++++++++++-------
>> >>  2 files changed, 34 insertions(+), 11 deletions(-)
>> >>
>> >>diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> >>index bb7e569..80b8484 100644
>> >>--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> >>+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>> >>@@ -57,6 +57,14 @@ conditions.
>> >>
>> >>  - smmu-enable-vmid16 : Enable 16 bit VMID, if allowed.
>> >>
>> >>+- asid-base :	Buggy SMMUv2 implementations which doesn't satisfy the
>> >>+		ASID namespace needs, use this field to specify starting
>> >>+		ASID for the SMMU.
>> >>+
>> >>+- vmid-base :	Buggy SMMUv2 implementations which doesn't satisfy the VMID
>> >>+		namespace needs, use this field to specify starting VMID
>> >>+		for the SMMU.
>> >
>> >As has been pointed out, these are not strictly properties of the
>> >hardware, and are insufficient to aovid the issue in general (adding an
>> >arbitrary base does not enforce IDs fall within a particular range).
>> >
>> >So NAK for *-base properties alone.
>> >
>> >>+	if (of_property_read_u32(dev->of_node, "#asid-base",
>> >>+				 &smmu->asid_base)) {
>> >>+		smmu->asid_base = 0;
>> >>+	}
>> >>+
>> >>+	if (of_property_read_u32(dev->of_node, "#vmid-base",
>> >>+				 &smmu->vmid_base)) {
>> >>+		smmu->vmid_base = 1;
>> >>+	}
>> >
>> >These do not match the documentation above.
>> >
>> >Mark.
>> >
>> 

From linus.walleij at linaro.org  Wed Feb 24 07:59:16 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Wed, 24 Feb 2016 16:59:16 +0100
Subject: [PATCH] ARM: realview: DT support for the PBA8
In-Reply-To: <CACRpkdbQKZxMgYRUq6cjAXHq5q1EufVwcHG=wJ0QsDcqUVoRhQ@mail.gmail.com>
References: <1456303714-31039-1-git-send-email-linus.walleij@linaro.org>
 <56CDA0F0.9050608@arm.com>
 <CACRpkdbQKZxMgYRUq6cjAXHq5q1EufVwcHG=wJ0QsDcqUVoRhQ@mail.gmail.com>
Message-ID: <CACRpkdbYB8pkgiE9NevOgR2WJpwv03ng5ZUwCMt=4=BsTVokfw@mail.gmail.com>

On Wed, Feb 24, 2016 at 4:52 PM, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Wed, Feb 24, 2016 at 1:24 PM, Robin Murphy <robin.murphy at arm.com> wrote:

>> Waiting for root device /dev/mmcblk0p1...
>>
>> It then fails to notice my SD card, even if I eject and reinsert it :(
>
> Fixing a v2 as we speak.

Also notice: if you want working graphics, I have a pending CLCD patch
set for that, and then there is a patch for reset too. I still hope to land
it all for v4.6 and delete the board files but it depends on a few subsystem
maintainers.

Yours,
Linus Walleij


From miles.chen at mediatek.com  Wed Feb 24 08:01:48 2016
From: miles.chen at mediatek.com (miles.chen at mediatek.com)
Date: Thu, 25 Feb 2016 00:01:48 +0800
Subject: [PATCH] arm64/mm: fix virtual address boundary check
Message-ID: <1456329708-2042-1-git-send-email-miles.chen@mediatek.com>

From: Miles Chen <miles.chen at mediatek.com>

The MODULES_VADDR is not the lowest possible
kernel virtual address. TASK_SIZE_64 may be larger than
MODULES_VADDR, FIXADDR_TOP, and PCI_IO_START.

Fix this by comparing TASK_SIZE_64 (highest user virtual address)
with VA_START (lowest kernel virtual address).

 #define VA_BITS		(CONFIG_ARM64_VA_BITS)
 #define VA_START		(UL(0xffffffffffffffff) << VA_BITS)
 #define PAGE_OFFSET		(UL(0xffffffffffffffff) << (VA_BITS - 1))
 #define MODULES_END		(PAGE_OFFSET)
 #define MODULES_VADDR		(MODULES_END - SZ_64M)
 #define PCI_IO_END		(MODULES_VADDR - SZ_2M)
 #define PCI_IO_START		(PCI_IO_END - PCI_IO_SIZE)
 #define FIXADDR_TOP		(PCI_IO_START - SZ_2M)
 #define TASK_SIZE_64		(UL(1) << VA_BITS)

Signed-off-by: Miles Chen <miles.chen at mediatek.com>
---
 arch/arm64/mm/init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3b061e..7d75697 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -343,8 +343,8 @@ void __init mem_init(void)
 #ifdef CONFIG_COMPAT
 	BUILD_BUG_ON(TASK_SIZE_32			> TASK_SIZE_64);
 #endif
-	BUILD_BUG_ON(TASK_SIZE_64			> MODULES_VADDR);
-	BUG_ON(TASK_SIZE_64				> MODULES_VADDR);
+	BUILD_BUG_ON(TASK_SIZE_64			> VA_START);
+	BUG_ON(TASK_SIZE_64				> VA_START);
 
 	if (PAGE_SIZE >= 16384 && get_num_physpages() <= 128) {
 		extern int sysctl_overcommit_memory;
-- 
1.9.1



From romain.izard.pro at gmail.com  Wed Feb 24 08:04:42 2016
From: romain.izard.pro at gmail.com (Romain Izard)
Date: Wed, 24 Feb 2016 17:04:42 +0100
Subject: [PATCH v2] clocksource: atmel-pit: register as a sched_clock
Message-ID: <1456329882-20709-1-git-send-email-romain.izard.pro@gmail.com>

Register the counter of the Periodic Interval Timer as a possible source
for sched_clock. Keep the timer running even if the related clockevent
is disabled.

This provides a better precision than the jiffies-based default. The
TCB clocksource does not work, as it is registered too late in the
initialization sequence.

Signed-off-by: Romain Izard <romain.izard.pro at gmail.com>
---
Changelog:
v2:
- Keep the tick counter updated when the clocksource is disabled
- Ensure that sched_clock is a 64 bit counter

 drivers/clocksource/timer-atmel-pit.c | 31 ++++++++++++++++---------------
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/clocksource/timer-atmel-pit.c b/drivers/clocksource/timer-atmel-pit.c
index d911c5dca8f1..609892bbf9da 100644
--- a/drivers/clocksource/timer-atmel-pit.c
+++ b/drivers/clocksource/timer-atmel-pit.c
@@ -21,6 +21,7 @@
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
 #include <linux/slab.h>
+#include <linux/sched_clock.h>
 
 #define AT91_PIT_MR		0x00			/* Mode Register */
 #define AT91_PIT_PITIEN			BIT(25)			/* Timer Interrupt Enable */
@@ -44,7 +45,7 @@ struct pit_data {
 
 	void __iomem	*base;
 	u32		cycle;
-	u32		cnt;
+	u64		cnt;
 	unsigned int	irq;
 	struct clk	*mck;
 };
@@ -77,7 +78,7 @@ static cycle_t read_pit_clk(struct clocksource *cs)
 {
 	struct pit_data *data = clksrc_to_pit_data(cs);
 	unsigned long flags;
-	u32 elapsed;
+	u64 elapsed;
 	u32 t;
 
 	raw_local_irq_save(flags);
@@ -90,15 +91,6 @@ static cycle_t read_pit_clk(struct clocksource *cs)
 	return elapsed;
 }
 
-static int pit_clkevt_shutdown(struct clock_event_device *dev)
-{
-	struct pit_data *data = clkevt_to_pit_data(dev);
-
-	/* disable irq, leaving the clocksource active */
-	pit_write(data->base, AT91_PIT_MR, (data->cycle - 1) | AT91_PIT_PITEN);
-	return 0;
-}
-
 /*
  * Clockevent device:  interrupts every 1/HZ (== pit_cycles * MCK/16)
  */
@@ -156,15 +148,15 @@ static irqreturn_t at91sam926x_pit_interrupt(int irq, void *dev_id)
 	WARN_ON_ONCE(!irqs_disabled());
 
 	/* The PIT interrupt may be disabled, and is shared */
-	if (clockevent_state_periodic(&data->clkevt) &&
-	    (pit_read(data->base, AT91_PIT_SR) & AT91_PIT_PITS)) {
+	if (pit_read(data->base, AT91_PIT_SR) & AT91_PIT_PITS) {
 		unsigned nr_ticks;
 
 		/* Get number of ticks performed before irq, and ack it */
 		nr_ticks = PIT_PICNT(pit_read(data->base, AT91_PIT_PIVR));
 		do {
 			data->cnt += data->cycle;
-			data->clkevt.event_handler(&data->clkevt);
+			if (clockevent_state_periodic(&data->clkevt))
+				data->clkevt.event_handler(&data->clkevt);
 			nr_ticks--;
 		} while (nr_ticks);
 
@@ -174,6 +166,13 @@ static irqreturn_t at91sam926x_pit_interrupt(int irq, void *dev_id)
 	return IRQ_NONE;
 }
 
+static struct clocksource *pit_sched_clock;
+
+static u64 pit_sched_clock_read(void)
+{
+	return read_pit_clk(pit_sched_clock);
+}
+
 /*
  * Set up both clocksource and clockevent support.
  */
@@ -206,6 +205,9 @@ static void __init at91sam926x_pit_common_init(struct pit_data *data)
 	data->clksrc.flags = CLOCK_SOURCE_IS_CONTINUOUS;
 	clocksource_register_hz(&data->clksrc, pit_rate);
 
+	pit_sched_clock = &data->clksrc;
+	sched_clock_register(pit_sched_clock_read, bits, pit_rate);
+
 	/* Set up irq handler */
 	ret = request_irq(data->irq, at91sam926x_pit_interrupt,
 			  IRQF_SHARED | IRQF_TIMER | IRQF_IRQPOLL,
@@ -221,7 +223,6 @@ static void __init at91sam926x_pit_common_init(struct pit_data *data)
 	data->clkevt.rating = 100;
 	data->clkevt.cpumask = cpumask_of(0);
 
-	data->clkevt.set_state_shutdown = pit_clkevt_shutdown;
 	data->clkevt.set_state_periodic = pit_clkevt_set_periodic;
 	data->clkevt.resume = at91sam926x_pit_resume;
 	data->clkevt.suspend = at91sam926x_pit_suspend;
-- 
2.5.0



From matt at codeblueprint.co.uk  Wed Feb 24 08:05:52 2016
From: matt at codeblueprint.co.uk (Matt Fleming)
Date: Wed, 24 Feb 2016 16:05:52 +0000
Subject: [PATCH] arm*: efi: drop permanent mapping of the UEFI System table
In-Reply-To: <CAKv+Gu_pnjL557dE1xez_y2tESOjZj9_2XEbNtm_b4yAA-WdYg@mail.gmail.com>
References: <1456153179-27214-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160222154314.GJ3435@leverpostej>
 <CAKv+Gu_pnjL557dE1xez_y2tESOjZj9_2XEbNtm_b4yAA-WdYg@mail.gmail.com>
Message-ID: <20160224160552.GB2603@codeblueprint.co.uk>

On Mon, 22 Feb, at 04:56:57PM, Ard Biesheuvel wrote:
> On 22 February 2016 at 16:43, Mark Rutland <mark.rutland at arm.com> wrote:
> > On Mon, Feb 22, 2016 at 03:59:39PM +0100, Ard Biesheuvel wrote:
> >> diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
> >> index 848ede1587dc..6ce13d6b7122 100644
> >> --- a/drivers/firmware/efi/arm-runtime.c
> >> +++ b/drivers/firmware/efi/arm-runtime.c
> >> @@ -64,6 +64,16 @@ static bool __init efi_virtmap_init(void)
> >>                               &phys, ret);
> >>                       return false;
> >>               }
> >> +             /*
> >> +              * If this entry covers the address of the UEFI system table,
> >> +              * calculate and record its virtual address.
> >> +              */
> >> +             if (efi_system_table >= phys &&
> >> +                 efi_system_table < phys + (md->num_pages * EFI_PAGE_SIZE)) {
> >> +                     efi.systab = (void *)(efi_system_table - phys +
> >> +                                           md->virt_addr);
> >> +                     set_bit(EFI_SYSTEM_TABLES, &efi.flags);
> >> +             }
> >
> > It seems very odd to me to set this given it's currently unused, and we
> > don't have permanent access to the table. That sounds like we're just
> > setting ourselves up for future fragility as users appear.
> >
> 
> I wondered about the purpose as well. It is only ever set, and never
> tested (until this patch)
> 
> @Matt: any thoughts?

Good question. EFI_SYSTEM_TABLES was introduced over 4 years ago, but
it looks like it has never had any users. I don't remember why I added
it, probably just be to be "complete" since we had bits for all the
other tables.

If somebody wants to rip it out, I wouldn't object.

To be fair, we don't have permanent access to any of the tables - you
always have to switch to the dedicated EFI page tables before
accessing regions.


From msalter at redhat.com  Wed Feb 24 08:09:11 2016
From: msalter at redhat.com (Mark Salter)
Date: Wed, 24 Feb 2016 11:09:11 -0500
Subject: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot
 for X-Gene v1
In-Reply-To: <1455069384-22323-1-git-send-email-dhdang@apm.com>
References: <1455069384-22323-1-git-send-email-dhdang@apm.com>
Message-ID: <1456330151.5681.46.camel@redhat.com>

On Tue, 2016-02-09 at 17:56 -0800, Duc Dang wrote:
> This patch makes pci-xgene-msi driver ACPI-aware and provides
> MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode.
> 
> Signed-off-by: Duc Dang <dhdang at apm.com>
> ---
> ?drivers/pci/host/pci-xgene-msi.c | 35 ++++++++++++++++++++++++++++++++---
> ?1 file changed, 32 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
> index a6456b5..466aa93 100644
> --- a/drivers/pci/host/pci-xgene-msi.c
> +++ b/drivers/pci/host/pci-xgene-msi.c
> @@ -24,6 +24,7 @@
> ?#include <linux/pci.h>
> ?#include <linux/platform_device.h>
> ?#include <linux/of_pci.h>
> +#include <linux/acpi.h>
> ?
> ?#define MSI_IR0			0x000000
> ?#define MSI_INT0		0x800000
> @@ -39,7 +40,7 @@ struct xgene_msi_group {
> ?};
> ?
> ?struct xgene_msi {
> -	struct device_node	*node;
> +	struct fwnode_handle	*fwnode;
> ?	struct irq_domain	*inner_domain;
> ?	struct irq_domain	*msi_domain;
> ?	u64			msi_addr;
> @@ -249,6 +250,13 @@ static const struct irq_domain_ops msi_domain_ops = {
> ?	.free???= xgene_irq_domain_free,
> ?};
> ?
> +#ifdef CONFIG_ACPI
> +static struct fwnode_handle *xgene_msi_get_fwnode(struct device *dev)
> +{
> +	return xgene_msi_ctrl.fwnode;
> +}
> +#endif
> +
> ?static int xgene_allocate_domains(struct xgene_msi *msi)
> ?{
> ?	msi->inner_domain = irq_domain_add_linear(NULL, NR_MSI_VEC,
> @@ -256,7 +264,7 @@ static int xgene_allocate_domains(struct xgene_msi *msi)
> ?	if (!msi->inner_domain)
> ?		return -ENOMEM;
> ?
> -	msi->msi_domain = pci_msi_create_irq_domain(of_node_to_fwnode(msi->node),
> +	msi->msi_domain = pci_msi_create_irq_domain(msi->fwnode,
> ?						????&xgene_msi_domain_info,
> ?						????msi->inner_domain);

This doesn't work for me (ACPI probing on Mustang) unless I change this
to be?pci_msi_create_default_irq_domain(). The problem seems to be that
the MSI probe happens after the PCIe RC is probed so there is no MSI domain
at the time the PCIe root is initialized by ACPI.

> ?
> @@ -265,6 +273,9 @@ static int xgene_allocate_domains(struct xgene_msi *msi)
> ?		return -ENOMEM;
> ?	}
> ?
> +#ifdef CONFIG_ACPI
> +	pci_msi_register_fwnode_provider(&xgene_msi_get_fwnode);
> +#endif
> ?	return 0;
> ?}
> ?
> @@ -473,6 +484,13 @@ static const struct of_device_id xgene_msi_match_table[] = {
> ?	{},
> ?};
> ?
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id xgene_msi_acpi_ids[] = {
> +	{"APMC0D0E", 0},
> +	{ },
> +};
> +#endif
> +
> ?static int xgene_msi_probe(struct platform_device *pdev)
> ?{
> ?	struct resource *res;
> @@ -494,7 +512,17 @@ static int xgene_msi_probe(struct platform_device *pdev)
> ?		goto error;
> ?	}
> ?	xgene_msi->msi_addr = res->start;
> -	xgene_msi->node = pdev->dev.of_node;
> +
> +	xgene_msi->fwnode = of_node_to_fwnode(pdev->dev.of_node);
> +	if (!xgene_msi->fwnode) {
> +		xgene_msi->fwnode = irq_domain_alloc_fwnode(NULL);
> +		if (!xgene_msi->fwnode) {
> +			dev_err(&pdev->dev, "Failed to create fwnode\n");
> +			rc = ENOMEM;
> +			goto error;
> +		}
> +	}
> +
> ?	xgene_msi->num_cpus = num_possible_cpus();
> ?
> ?	rc = xgene_msi_init_allocator(xgene_msi);
> @@ -571,6 +599,7 @@ static struct platform_driver xgene_msi_driver = {
> ?	.driver = {
> ?		.name = "xgene-msi",
> ?		.of_match_table = xgene_msi_match_table,
> +		.acpi_match_table = ACPI_PTR(xgene_msi_acpi_ids),
> ?	},
> ?	.probe = xgene_msi_probe,
> ?	.remove = xgene_msi_remove,



From amakarov.linux at gmail.com  Wed Feb 24 08:09:59 2016
From: amakarov.linux at gmail.com (Aleksey Makarov)
Date: Wed, 24 Feb 2016 19:09:59 +0300
Subject: [PATCH 1/8] arm64: move acpi/dt decision earlier in boot process
In-Reply-To: <56CC6EA6.4020909@gmail.com>
References: <1456148818-26257-1-git-send-email-aleksey.makarov@linaro.org>
 <1456148818-26257-2-git-send-email-aleksey.makarov@linaro.org>
 <56CB2D0D.3090408@gmail.com>
 <20160223135731.GA24781@xora-haswell.xora.org.uk>
 <56CC6EA6.4020909@gmail.com>
Message-ID: <56CDD5D7.5070703@gmail.com>

Hi Matthias,

Thank you for review.  The bug is fixed in the next version of the patchset.

Aleksey Makarov

On 02/23/2016 05:37 PM, Matthias Brugger wrote:
> 
> 
> On 23/02/16 14:57, Graeme Gregory wrote:
>> On Mon, Feb 22, 2016 at 04:45:17PM +0100, Matthias Brugger wrote:
>>>
>>>
>>> On 22/02/16 14:46, Aleksey Makarov wrote:
>>>> From: Leif Lindholm <leif.lindholm at linaro.org>
>>>>
>>>> In order to support selecting earlycon via either ACPI or DT, move
>>>> the decision on whether to attempt ACPI configuration into the
>>>> early_param handling. Then make acpi_boot_table_init() bail out if
>>>> acpi_disabled.
>>>>
>>>> Signed-off-by: Leif Lindholm <leif.lindholm at linaro.org>
>>>> ---
>>>>   arch/arm64/kernel/acpi.c | 54 ++++++++++++++++++++++++++----------------------
>>>>   1 file changed, 29 insertions(+), 25 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>>>> index d1ce8e2..7a944f7 100644
>>>> --- a/arch/arm64/kernel/acpi.c
>>>> +++ b/arch/arm64/kernel/acpi.c
>>>> @@ -44,6 +44,19 @@ EXPORT_SYMBOL(acpi_pci_disabled);
>>>>   static bool param_acpi_off __initdata;
>>>>   static bool param_acpi_force __initdata;
>>>>
>>>> +static int __init dt_scan_depth1_nodes(unsigned long node,
>>>> +                       const char *uname, int depth,
>>>> +                       void *data)
>>>> +{
>>>> +    /*
>>>> +     * Return 1 as soon as we encounter a node at depth 1 that is
>>>> +     * not the /chosen node.
>>>> +     */
>>>> +    if (depth == 1 && (strcmp(uname, "chosen") != 0))
>>>> +        return 1;
>>>> +    return 0;
>>>> +}
>>>> +
>>>>   static int __init parse_acpi(char *arg)
>>>>   {
>>>>       if (!arg)
>>>> @@ -57,23 +70,27 @@ static int __init parse_acpi(char *arg)
>>>>       else
>>>>           return -EINVAL;    /* Core will print when we return error */
> 
> If argument of parse_acpi is neither "off" nor "force" we return with -EINVAL here. Actually parse_acpi will be only called if we pass "acpi=" as kernel parameter. Therefor we can get rid of "acpi=off" as this is the _new_ standard. IMHO we should introduce "acpi=on" if we really want to change the standard behavior.
> 
>>>>
>>>> -    return 0;
>>>> -}
>>>> -early_param("acpi", parse_acpi);
>>>> +    /*
>>>> +     * Enable ACPI instead of device tree unless
>>>> +     * - ACPI has been disabled explicitly (acpi=off), or
>>>> +     * - the device tree is not empty (it has more than just a /chosen node)
>>>> +     *   and ACPI has not been force enabled (acpi=force)
>>>> +     */
>>>> +    if (param_acpi_off ||
>>>> +        (!param_acpi_force && of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
>>>> +        return 0;
> 
> Or param_acpi_off is true or param_acpi_force is true, the depth of the DT has no influence.
> 
>>>>
>>>> -static int __init dt_scan_depth1_nodes(unsigned long node,
>>>> -                       const char *uname, int depth,
>>>> -                       void *data)
>>>> -{
>>>>       /*
>>>> -     * Return 1 as soon as we encounter a node at depth 1 that is
>>>> -     * not the /chosen node.
>>>> +     * ACPI is disabled at this point. Enable it in order to parse
>>>> +     * the ACPI tables and carry out sanity checks
>>>>        */
>>>> -    if (depth == 1 && (strcmp(uname, "chosen") != 0))
>>>> -        return 1;
>>>> +    enable_acpi();
>>>> +
>>>
>>> So we only enable ACPI if we pass acpi=force as kernel parameter?
>>> I'm not sure if this is what you wanted to do.
>>>
>>
>> The current preference from ARM64 maintainers was that is both ACPI
>> tables and a DT were presented then DT should take precedence.
>>
>> With no DT provided the code should use ACPI.
> 
> From my understanding in this patch that can never happen.
> 
> On which version is this set based on?
> I'm looking on v4.5-rc5 ATM.
> 
> Regards,
> Matthias
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From maxime.coquelin at st.com  Wed Feb 24 08:14:51 2016
From: maxime.coquelin at st.com (Maxime Coquelin)
Date: Wed, 24 Feb 2016 17:14:51 +0100
Subject: [PATCH 45/50] pinctrl: st: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-46-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-46-git-send-email-ldewangan@nvidia.com>
Message-ID: <56CDD6FB.5020805@st.com>



On 02/24/2016 02:16 PM, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration.
>
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Srinivas Kandagatla <srinivas.kandagatla at gmail.com>
> Cc: Maxime Coquelin <maxime.coquelin at st.com>
> Cc: Patrice Chotard <patrice.chotard at st.com>
> Cc: kernel at stlinux.com
> ---
>   drivers/pinctrl/pinctrl-st.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Maxime Coquelin <maxime.coquelin at st.com>

Thanks!
Maxime



From alexandre.belloni at free-electrons.com  Wed Feb 24 08:15:08 2016
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Wed, 24 Feb 2016 17:15:08 +0100
Subject: [PATCH v2] clocksource: atmel-pit: register as a sched_clock
In-Reply-To: <1456329882-20709-1-git-send-email-romain.izard.pro@gmail.com>
References: <1456329882-20709-1-git-send-email-romain.izard.pro@gmail.com>
Message-ID: <20160224161508.GJ10681@piout.net>

On 24/02/2016 at 17:04:42 +0100, Romain Izard wrote :
> Register the counter of the Periodic Interval Timer as a possible source
> for sched_clock. Keep the timer running even if the related clockevent
> is disabled.
> 
> This provides a better precision than the jiffies-based default. The
> TCB clocksource does not work, as it is registered too late in the
> initialization sequence.
> 
> Signed-off-by: Romain Izard <romain.izard.pro at gmail.com>
> ---
> Changelog:
> v2:
> - Keep the tick counter updated when the clocksource is disabled
> - Ensure that sched_clock is a 64 bit counter
> 
>  drivers/clocksource/timer-atmel-pit.c | 31 ++++++++++++++++---------------
>  1 file changed, 16 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/clocksource/timer-atmel-pit.c b/drivers/clocksource/timer-atmel-pit.c
> index d911c5dca8f1..609892bbf9da 100644
> --- a/drivers/clocksource/timer-atmel-pit.c
> +++ b/drivers/clocksource/timer-atmel-pit.c
> @@ -21,6 +21,7 @@
>  #include <linux/of_address.h>
>  #include <linux/of_irq.h>
>  #include <linux/slab.h>
> +#include <linux/sched_clock.h>
>  
>  #define AT91_PIT_MR		0x00			/* Mode Register */
>  #define AT91_PIT_PITIEN			BIT(25)			/* Timer Interrupt Enable */
> @@ -44,7 +45,7 @@ struct pit_data {
>  
>  	void __iomem	*base;
>  	u32		cycle;
> -	u32		cnt;
> +	u64		cnt;
>  	unsigned int	irq;
>  	struct clk	*mck;
>  };
> @@ -77,7 +78,7 @@ static cycle_t read_pit_clk(struct clocksource *cs)
>  {
>  	struct pit_data *data = clksrc_to_pit_data(cs);
>  	unsigned long flags;
> -	u32 elapsed;
> +	u64 elapsed;
>  	u32 t;
>  
>  	raw_local_irq_save(flags);
> @@ -90,15 +91,6 @@ static cycle_t read_pit_clk(struct clocksource *cs)
>  	return elapsed;
>  }
>  
> -static int pit_clkevt_shutdown(struct clock_event_device *dev)
> -{
> -	struct pit_data *data = clkevt_to_pit_data(dev);
> -
> -	/* disable irq, leaving the clocksource active */
> -	pit_write(data->base, AT91_PIT_MR, (data->cycle - 1) | AT91_PIT_PITEN);
> -	return 0;
> -}
> -

What about preempt-rt where really we want to disable the pit?

>  /*
>   * Clockevent device:  interrupts every 1/HZ (== pit_cycles * MCK/16)
>   */
> @@ -156,15 +148,15 @@ static irqreturn_t at91sam926x_pit_interrupt(int irq, void *dev_id)
>  	WARN_ON_ONCE(!irqs_disabled());
>  
>  	/* The PIT interrupt may be disabled, and is shared */
> -	if (clockevent_state_periodic(&data->clkevt) &&
> -	    (pit_read(data->base, AT91_PIT_SR) & AT91_PIT_PITS)) {
> +	if (pit_read(data->base, AT91_PIT_SR) & AT91_PIT_PITS) {
>  		unsigned nr_ticks;
>  
>  		/* Get number of ticks performed before irq, and ack it */
>  		nr_ticks = PIT_PICNT(pit_read(data->base, AT91_PIT_PIVR));
>  		do {
>  			data->cnt += data->cycle;
> -			data->clkevt.event_handler(&data->clkevt);
> +			if (clockevent_state_periodic(&data->clkevt))
> +				data->clkevt.event_handler(&data->clkevt);
>  			nr_ticks--;
>  		} while (nr_ticks);
>  
> @@ -174,6 +166,13 @@ static irqreturn_t at91sam926x_pit_interrupt(int irq, void *dev_id)
>  	return IRQ_NONE;
>  }
>  
> +static struct clocksource *pit_sched_clock;
> +
> +static u64 pit_sched_clock_read(void)
> +{
> +	return read_pit_clk(pit_sched_clock);
> +}
> +
>  /*
>   * Set up both clocksource and clockevent support.
>   */
> @@ -206,6 +205,9 @@ static void __init at91sam926x_pit_common_init(struct pit_data *data)
>  	data->clksrc.flags = CLOCK_SOURCE_IS_CONTINUOUS;
>  	clocksource_register_hz(&data->clksrc, pit_rate);
>  
> +	pit_sched_clock = &data->clksrc;
> +	sched_clock_register(pit_sched_clock_read, bits, pit_rate);
> +
>  	/* Set up irq handler */
>  	ret = request_irq(data->irq, at91sam926x_pit_interrupt,
>  			  IRQF_SHARED | IRQF_TIMER | IRQF_IRQPOLL,
> @@ -221,7 +223,6 @@ static void __init at91sam926x_pit_common_init(struct pit_data *data)
>  	data->clkevt.rating = 100;
>  	data->clkevt.cpumask = cpumask_of(0);
>  
> -	data->clkevt.set_state_shutdown = pit_clkevt_shutdown;
>  	data->clkevt.set_state_periodic = pit_clkevt_set_periodic;
>  	data->clkevt.resume = at91sam926x_pit_resume;
>  	data->clkevt.suspend = at91sam926x_pit_suspend;
> -- 
> 2.5.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From marc.zyngier at arm.com  Wed Feb 24 08:16:39 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Feb 2016 16:16:39 +0000
Subject: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot
 for X-Gene v1
In-Reply-To: <1456330151.5681.46.camel@redhat.com>
References: <1455069384-22323-1-git-send-email-dhdang@apm.com>
 <1456330151.5681.46.camel@redhat.com>
Message-ID: <56CDD767.6020103@arm.com>

On 24/02/16 16:09, Mark Salter wrote:
> On Tue, 2016-02-09 at 17:56 -0800, Duc Dang wrote:
>> This patch makes pci-xgene-msi driver ACPI-aware and provides
>> MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode.
>>
>> Signed-off-by: Duc Dang <dhdang at apm.com>
>> ---
>>  drivers/pci/host/pci-xgene-msi.c | 35 ++++++++++++++++++++++++++++++++---
>>  1 file changed, 32 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
>> index a6456b5..466aa93 100644
>> --- a/drivers/pci/host/pci-xgene-msi.c
>> +++ b/drivers/pci/host/pci-xgene-msi.c
>> @@ -24,6 +24,7 @@
>>  #include <linux/pci.h>
>>  #include <linux/platform_device.h>
>>  #include <linux/of_pci.h>
>> +#include <linux/acpi.h>
>>  
>>  #define MSI_IR0			0x000000
>>  #define MSI_INT0		0x800000
>> @@ -39,7 +40,7 @@ struct xgene_msi_group {
>>  };
>>  
>>  struct xgene_msi {
>> -	struct device_node	*node;
>> +	struct fwnode_handle	*fwnode;
>>  	struct irq_domain	*inner_domain;
>>  	struct irq_domain	*msi_domain;
>>  	u64			msi_addr;
>> @@ -249,6 +250,13 @@ static const struct irq_domain_ops msi_domain_ops = {
>>  	.free   = xgene_irq_domain_free,
>>  };
>>  
>> +#ifdef CONFIG_ACPI
>> +static struct fwnode_handle *xgene_msi_get_fwnode(struct device *dev)
>> +{
>> +	return xgene_msi_ctrl.fwnode;
>> +}
>> +#endif
>> +
>>  static int xgene_allocate_domains(struct xgene_msi *msi)
>>  {
>>  	msi->inner_domain = irq_domain_add_linear(NULL, NR_MSI_VEC,
>> @@ -256,7 +264,7 @@ static int xgene_allocate_domains(struct xgene_msi *msi)
>>  	if (!msi->inner_domain)
>>  		return -ENOMEM;
>>  
>> -	msi->msi_domain = pci_msi_create_irq_domain(of_node_to_fwnode(msi->node),
>> +	msi->msi_domain = pci_msi_create_irq_domain(msi->fwnode,
>>  						    &xgene_msi_domain_info,
>>  						    msi->inner_domain);
> 
> This doesn't work for me (ACPI probing on Mustang) unless I change this
> to be pci_msi_create_default_irq_domain(). The problem seems to be that
> the MSI probe happens after the PCIe RC is probed so there is no MSI domain
> at the time the PCIe root is initialized by ACPI.

pci_msi_create_default_irq_domain is the wrong thing do use, specially
if you have multiple MSI controllers in the system. I certainly wouldn't
want to see it being used on arm64.

This is the usual dependency hell. You try moving the probing earlier,
but that may break something else in the process.

	M.
-- 
Jazz is not dead. It just smells funny...


From arnd at arndb.de  Wed Feb 24 08:18:58 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Feb 2016 17:18:58 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <s5h1t8b65n7.wl-tiwai@suse.de>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
 <s5h8u2j6749.wl-tiwai@suse.de> <s5h1t8b65n7.wl-tiwai@suse.de>
Message-ID: <3238725.1iS2dg6EkI@wuerfel>

On Wednesday 17 February 2016 10:35:40 Takashi Iwai wrote:
> On Wed, 17 Feb 2016 10:03:50 +0100,
> +	const char *id;
> +#ifdef CONFIG_SND_JACK_INPUT_DEV
> +	struct input_dev *input_dev;
>  	int registered;
>  	int type;
> -	const char *id;
>  	char name[100];
>  	unsigned int key[6];   /* Keep in sync with definitions above */
> +#endif /* CONFIG_SND_JACK_INPUT_DEV */
>  	void *private_data;
>  	void (*private_free)(struct snd_jack *);
>  };

I got a build error from this today, as the trace event tries to print
the jack "name" field. I've managed to get it to build again by printing
the "id" field in place of the "name". The name is normally assigned
from id in snd_jack_dev_register using

        snprintf(jack->name, sizeof(jack->name), "%s %s",
                 card->shortname, jack->id);

but that code is not called here at all. My patch will slightly
alter the output as a consequence, but I don't know if this change
is critical or not.

	Arnd

diff --git a/include/trace/events/asoc.h b/include/trace/events/asoc.h
index 317a1ed2f4ac..9130dd5a184a 100644
--- a/include/trace/events/asoc.h
+++ b/include/trace/events/asoc.h
@@ -231,13 +231,13 @@ TRACE_EVENT(snd_soc_jack_report,
 	TP_ARGS(jack, mask, val),
 
 	TP_STRUCT__entry(
-		__string(	name,		jack->jack->name	)
+		__string(	name,		jack->jack->id		)
 		__field(	int,		mask			)
 		__field(	int,		val			)
 	),
 
 	TP_fast_assign(
-		__assign_str(name, jack->jack->name);
+		__assign_str(name, jack->jack->id);
 		__entry->mask = mask;
 		__entry->val = val;
 	),
@@ -253,12 +253,12 @@ TRACE_EVENT(snd_soc_jack_notify,
 	TP_ARGS(jack, val),
 
 	TP_STRUCT__entry(
-		__string(	name,		jack->jack->name	)
+		__string(	name,		jack->jack->id		)
 		__field(	int,		val			)
 	),
 
 	TP_fast_assign(
-		__assign_str(name, jack->jack->name);
+		__assign_str(name, jack->jack->id);
 		__entry->val = val;
 	),
 



From catalin.marinas at arm.com  Wed Feb 24 08:19:44 2016
From: catalin.marinas at arm.com (Catalin Marinas)
Date: Wed, 24 Feb 2016 16:19:44 +0000
Subject: [PATCH] arm64/mm: fix virtual address boundary check
In-Reply-To: <1456329708-2042-1-git-send-email-miles.chen@mediatek.com>
References: <1456329708-2042-1-git-send-email-miles.chen@mediatek.com>
Message-ID: <20160224161944.GJ4777@e104818-lin.cambridge.arm.com>

On Thu, Feb 25, 2016 at 12:01:48AM +0800, miles.chen at mediatek.com wrote:
> From: Miles Chen <miles.chen at mediatek.com>
> 
> The MODULES_VADDR is not the lowest possible
> kernel virtual address. TASK_SIZE_64 may be larger than
> MODULES_VADDR, FIXADDR_TOP, and PCI_IO_START.
> 
> Fix this by comparing TASK_SIZE_64 (highest user virtual address)
> with VA_START (lowest kernel virtual address).
> 
>  #define VA_BITS		(CONFIG_ARM64_VA_BITS)
>  #define VA_START		(UL(0xffffffffffffffff) << VA_BITS)
>  #define PAGE_OFFSET		(UL(0xffffffffffffffff) << (VA_BITS - 1))
>  #define MODULES_END		(PAGE_OFFSET)
>  #define MODULES_VADDR		(MODULES_END - SZ_64M)
>  #define PCI_IO_END		(MODULES_VADDR - SZ_2M)
>  #define PCI_IO_START		(PCI_IO_END - PCI_IO_SIZE)
>  #define FIXADDR_TOP		(PCI_IO_START - SZ_2M)
>  #define TASK_SIZE_64		(UL(1) << VA_BITS)

We should remove these checks altogether. There is a huge gap between
the user and kernel addresses that they would never overlap (we don't
have enough levels of page tables to cover 64-bit VA space).

-- 
Catalin


From mathieu.poirier at linaro.org  Wed Feb 24 08:20:22 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Wed, 24 Feb 2016 09:20:22 -0700
Subject: [PATCH] drivers: perf: arm: implement CPU_PM notifier
In-Reply-To: <1456251759-24768-1-git-send-email-lorenzo.pieralisi@arm.com>
References: <1456251759-24768-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <CANLsYkzvB0GbPeYHrcLtUz8DMHJh4FA5RVwVZ-UAm3BCznB_3w@mail.gmail.com>

On 23 February 2016 at 11:22, Lorenzo Pieralisi
<lorenzo.pieralisi at arm.com> wrote:
> When a CPU is suspended (either through suspend-to-RAM or CPUidle),
> its PMU registers content can be lost, which means that counters
> registers values that were initialized on power down entry have to be
> reprogrammed on power-up to make sure the counters set-up is preserved
> (ie on power-up registers take the reset values on Cold or Warm reset,
> which can be architecturally UNKNOWN).
>
> To guarantee seamless profiling conditions across a core power down
> this patch adds a CPU PM notifier to ARM pmus, that upon CPU PM
> entry/exit from low-power states saves/restores the pmu registers
> set-up (by using the ARM perf API), so that the power-down/up cycle does
> not affect the perf behaviour (apart from a black-out period between
> power-up/down CPU PM notifications that is unavoidable).
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> Cc: Ashwin Chaugule <ashwin.chaugule at linaro.org>
> Cc: Will Deacon <will.deacon at arm.com>
> Cc: Kevin Hilman <khilman at baylibre.com>
> Cc: Sudeep Holla <sudeep.holla at arm.com>
> Cc: Daniel Lezcano <daniel.lezcano at linaro.org>
> Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
> Cc: Mark Rutland <mark.rutland at arm.com>
> ---
>  drivers/perf/arm_pmu.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/perf/arm_pmu.h |  1 +
>  2 files changed, 96 insertions(+)
>
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index 166637f..12317a9 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -13,6 +13,7 @@
>
>  #include <linux/bitmap.h>
>  #include <linux/cpumask.h>
> +#include <linux/cpu_pm.h>
>  #include <linux/export.h>
>  #include <linux/kernel.h>
>  #include <linux/of_device.h>
> @@ -710,6 +711,93 @@ static int cpu_pmu_notify(struct notifier_block *b, unsigned long action,
>         return NOTIFY_OK;
>  }
>
> +#ifdef CONFIG_CPU_PM
> +static void cpu_pm_pmu_setup(struct arm_pmu *armpmu, unsigned long cmd)
> +{
> +       struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
> +       struct perf_event *event;
> +       int idx;
> +
> +       for (idx = 0; idx < armpmu->num_events; idx++) {
> +               /*
> +                * If the counter is not used skip it, there is no
> +                * need of stopping/restarting it.
> +                */
> +               if (!test_bit(idx, hw_events->used_mask))
> +                       continue;
> +
> +               event = hw_events->events[idx];
> +
> +               switch (cmd) {
> +               case CPU_PM_ENTER:
> +                       /*
> +                        * Stop and update the counter
> +                        */
> +                       armpmu_stop(event, PERF_EF_UPDATE);
> +                       break;
> +               case CPU_PM_EXIT:
> +               case CPU_PM_ENTER_FAILED:
> +                        /* Restore and enable the counter */
> +                       armpmu_start(event, PERF_EF_RELOAD);
> +                       break;
> +               default:
> +                       break;
> +               }
> +       }
> +}
> +
> +static int cpu_pm_pmu_notify(struct notifier_block *b, unsigned long cmd,
> +                            void *v)
> +{
> +       struct arm_pmu *armpmu = container_of(b, struct arm_pmu, cpu_pm_nb);
> +       struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
> +       int enabled = bitmap_weight(hw_events->used_mask, armpmu->num_events);
> +
> +       if (!cpumask_test_cpu(smp_processor_id(), &armpmu->supported_cpus))
> +               return NOTIFY_DONE;
> +
> +       /*
> +        * Always reset the PMU registers on power-up even if
> +        * there are no events running.
> +        */
> +       if (cmd == CPU_PM_EXIT && armpmu->reset)
> +               armpmu->reset(armpmu);

I think this patch does the right thing but I can't get the above
reset.  Wouldn't it be better to do the reset as part of the
CPU_PM_EXIT case below?  At this point nothing tells us the CPU won't
go back down before the event is enabled, wasting the cycle needed to
reset the PMU.

Thanks,
Mathieu

> +
> +       if (!enabled)
> +               return NOTIFY_OK;
> +
> +       switch (cmd) {
> +       case CPU_PM_ENTER:
> +               armpmu->stop(armpmu);
> +               cpu_pm_pmu_setup(armpmu, cmd);
> +               break;
> +       case CPU_PM_EXIT:
> +               cpu_pm_pmu_setup(armpmu, cmd);
> +       case CPU_PM_ENTER_FAILED:
> +               armpmu->start(armpmu);
> +               break;
> +       default:
> +               return NOTIFY_DONE;
> +       }
> +
> +       return NOTIFY_OK;
> +}
> +
> +static int cpu_pm_pmu_register(struct arm_pmu *cpu_pmu)
> +{
> +       cpu_pmu->cpu_pm_nb.notifier_call = cpu_pm_pmu_notify;
> +       return cpu_pm_register_notifier(&cpu_pmu->cpu_pm_nb);
> +}
> +
> +static void cpu_pm_pmu_unregister(struct arm_pmu *cpu_pmu)
> +{
> +       cpu_pm_unregister_notifier(&cpu_pmu->cpu_pm_nb);
> +}
> +#else
> +static inline int cpu_pm_pmu_register(struct arm_pmu *cpu_pmu) { return 0; }
> +static inline void cpu_pm_pmu_unregister(struct arm_pmu *cpu_pmu) { }
> +#endif
> +
>  static int cpu_pmu_init(struct arm_pmu *cpu_pmu)
>  {
>         int err;
> @@ -725,6 +813,10 @@ static int cpu_pmu_init(struct arm_pmu *cpu_pmu)
>         if (err)
>                 goto out_hw_events;
>
> +       err = cpu_pm_pmu_register(cpu_pmu);
> +       if (err)
> +               goto out_unregister;
> +
>         for_each_possible_cpu(cpu) {
>                 struct pmu_hw_events *events = per_cpu_ptr(cpu_hw_events, cpu);
>                 raw_spin_lock_init(&events->pmu_lock);
> @@ -746,6 +838,8 @@ static int cpu_pmu_init(struct arm_pmu *cpu_pmu)
>
>         return 0;
>
> +out_unregister:
> +       unregister_cpu_notifier(&cpu_pmu->hotplug_nb);
>  out_hw_events:
>         free_percpu(cpu_hw_events);
>         return err;
> @@ -753,6 +847,7 @@ out_hw_events:
>
>  static void cpu_pmu_destroy(struct arm_pmu *cpu_pmu)
>  {
> +       cpu_pm_pmu_unregister(cpu_pmu);
>         unregister_cpu_notifier(&cpu_pmu->hotplug_nb);
>         free_percpu(cpu_pmu->hw_events);
>  }
> diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
> index 83b5e34..9ffa316 100644
> --- a/include/linux/perf/arm_pmu.h
> +++ b/include/linux/perf/arm_pmu.h
> @@ -107,6 +107,7 @@ struct arm_pmu {
>         struct platform_device  *plat_device;
>         struct pmu_hw_events    __percpu *hw_events;
>         struct notifier_block   hotplug_nb;
> +       struct notifier_block   cpu_pm_nb;
>  };
>
>  #define to_arm_pmu(p) (container_of(p, struct arm_pmu, pmu))
> --
> 2.5.1
>


From sylvain.rochet at finsecur.com  Wed Feb 24 08:20:46 2016
From: sylvain.rochet at finsecur.com (Sylvain Rochet)
Date: Wed, 24 Feb 2016 17:20:46 +0100
Subject: [PATCH v2] clocksource: atmel-pit: register as a sched_clock
In-Reply-To: <1456329882-20709-1-git-send-email-romain.izard.pro@gmail.com>
References: <1456329882-20709-1-git-send-email-romain.izard.pro@gmail.com>
Message-ID: <20160224162046.GA28743@finsecur.com>

Hi,

On Wed, Feb 24, 2016 at 05:04:42PM +0100, Romain Izard wrote:
> Register the counter of the Periodic Interval Timer as a possible source
> for sched_clock. Keep the timer running even if the related clockevent
> is disabled.
> 
> This provides a better precision than the jiffies-based default. The
> TCB clocksource does not work, as it is registered too late in the
> initialization sequence.

I have mixed feelings about that, but this is probably just a 
misunderstanding from my part.

The PIT timer should not be used for systems with PM_SUSPEND enabled and 
used because it takes ages to synchronize on resume, how does this patch 
affect that ?

Ref: commit ac34ad27fc ("clockevents: Do not suspend/resume if unused")

Sylvain


From ard.biesheuvel at linaro.org  Wed Feb 24 08:21:30 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 24 Feb 2016 17:21:30 +0100
Subject: [RFC PATCH 3/6] arm64: mm: free __init memory via the linear mapping
In-Reply-To: <1456330893-19228-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456330893-19228-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456330893-19228-4-git-send-email-ard.biesheuvel@linaro.org>

The implementation of free_initmem_default() expects __init_begin
and __init_end to be covered by the linear mapping, which is no
longer the case. So open code it instead, using addresses that are
explicitly translated from kernel virtual to linear virtual.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/mm/init.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 88046b94fa87..e286716848af 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -398,7 +398,8 @@ void __init mem_init(void)
 
 void free_initmem(void)
 {
-	free_initmem_default(0);
+	free_reserved_area(__va(__pa(__init_begin)), __va(__pa(__init_end)),
+			   0, "unused kernel");
 	fixup_init();
 }
 
-- 
2.5.0



From ard.biesheuvel at linaro.org  Wed Feb 24 08:21:27 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 24 Feb 2016 17:21:27 +0100
Subject: [RFC PATCH 0/6] restrict virt_to_page to linear region (instead of
 __pa)
Message-ID: <1456330893-19228-1-git-send-email-ard.biesheuvel@linaro.org>

Another approach, and another bugfix in patch #1; this series supersedes the
__pa replacement series I sent out two days ago.

While looking into the [alleged] performance hit we are taking due to the
virt_to_phys() changes that are queued up, I noticed two things:

(a) I broke vmemmap in commit dd006da21646 ("arm64: mm: increase VA range of
    identity map"), since it results in the struct page array corresponding
    with the memory outside of the VA range to be mapped outside the vmemmap
    range as well. This can be worked around fairly easily by making the
    vmemmap range a projection of the virtual linear range rather than the
    physical range (patch #1). This is a bugfix, and should probably go to
    -stable?

(b) Once we have the fix for (a) in place, the relation between a page in the
    linear region and its struct page in the vmemmap region is no longer based
    on the placement of physical RAM, and we can reimplement virt_to_page()
    without regard for PHYS_OFFSET, and base it entirely on arithmetic involving
    build time constants only, which hopefully helps regain some performance we
    [allegedly] lost (patch #6)

In a couple of cases (#2 - #5), a fixup is needed similar to the fixups in my
__pa() replacement series, to prevent virt_to_page() being used on kernel
symbols. Other than that, the code does look somewhat cleaner, and it is
arguably more reasonable to restrict virt_to_page() to linear addresses than it
is to restrict __pa().

As far as the performance is concerned, I wonder how many __pa translations
remain on hot paths after eliminating it from virt_to_page(). Suggestions
for testing the performance gain/loss are appreciated. (hackbench?)

Ard Biesheuvel (6):
  arm64: vmemmap: use virtual projection of linear region
  arm64: vdso: avoid virt_to_page() translations on kernel symbols
  arm64: mm: free __init memory via the linear mapping
  arm64: mm: avoid virt_to_page() translation for the zero page
  kernel: insn: avoid virt_to_page() translations on core kernel symbols
  arm64: mm: restrict virt_to_page() to the linear mapping

 arch/arm64/include/asm/memory.h  | 9 ++++++++-
 arch/arm64/include/asm/pgtable.h | 9 +++++----
 arch/arm64/kernel/insn.c         | 2 +-
 arch/arm64/kernel/vdso.c         | 7 ++++---
 arch/arm64/mm/init.c             | 7 ++++---
 5 files changed, 22 insertions(+), 12 deletions(-)

-- 
2.5.0



From ard.biesheuvel at linaro.org  Wed Feb 24 08:21:31 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 24 Feb 2016 17:21:31 +0100
Subject: [RFC PATCH 4/6] arm64: mm: avoid virt_to_page() translation for the
 zero page
In-Reply-To: <1456330893-19228-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456330893-19228-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456330893-19228-5-git-send-email-ard.biesheuvel@linaro.org>

The zero page is statically allocated, so grab its struct page pointer
without using virt_to_page(), which will be restricted to the linear
mapping later.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/pgtable.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 8e6baea0ff61..ab84cafde3c9 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -118,7 +118,7 @@ extern void __pgd_error(const char *file, int line, unsigned long val);
  * for zero-mapped memory areas etc..
  */
 extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)];
-#define ZERO_PAGE(vaddr)	virt_to_page(empty_zero_page)
+#define ZERO_PAGE(vaddr)	pfn_to_page(__pa(empty_zero_page) >> PAGE_SHIFT)
 
 #define pte_ERROR(pte)		__pte_error(__FILE__, __LINE__, pte_val(pte))
 
-- 
2.5.0



From ard.biesheuvel at linaro.org  Wed Feb 24 08:21:32 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 24 Feb 2016 17:21:32 +0100
Subject: [RFC PATCH 5/6] kernel: insn: avoid virt_to_page() translations on
 core kernel symbols
In-Reply-To: <1456330893-19228-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456330893-19228-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456330893-19228-6-git-send-email-ard.biesheuvel@linaro.org>

Before restricting virt_to_page() to the linear mapping, ensure that
the text patching code does not use it to resolve references into the
core kernel text, which is mapped in the vmalloc area.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/kernel/insn.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 7371455160e5..219d3a5df142 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -96,7 +96,7 @@ static void __kprobes *patch_map(void *addr, int fixmap)
 	if (module && IS_ENABLED(CONFIG_DEBUG_SET_MODULE_RONX))
 		page = vmalloc_to_page(addr);
 	else if (!module && IS_ENABLED(CONFIG_DEBUG_RODATA))
-		page = virt_to_page(addr);
+		page = pfn_to_page(__pa(addr) >> PAGE_SHIFT);
 	else
 		return addr;
 
-- 
2.5.0



From ard.biesheuvel at linaro.org  Wed Feb 24 08:21:33 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 24 Feb 2016 17:21:33 +0100
Subject: [RFC PATCH 6/6] arm64: mm: disregard PHYS_OFFSET in virt_to_page()
In-Reply-To: <1456330893-19228-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456330893-19228-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456330893-19228-7-git-send-email-ard.biesheuvel@linaro.org>

The mm layer makes heavy use of virt_to_page(), which translates from
virtual addresses to offsets in the struct page array using an intermediate
translation to physical addresses. However, these physical translations
are based on the actual placement of physical memory, which can only be
discovered at runtime. This means virt_to_page() translations involve a
global PHYS_OFFSET variable, and hence a memory access.
    
Now that the vmemmap region has been redefined to cover the linear region
rather than the entire physical address space, we no longer need to perform
a virtual-to-physical translation in the implementation of virt_to_page(),
which means we can get rid of the memory access.

This restricts virt_to_page() translations to the linear region, so
redefine virt_addr_valid() as well.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/memory.h | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index eb798156cf56..9d4b7733caa3 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -189,8 +189,15 @@ static inline void *phys_to_virt(phys_addr_t x)
  */
 #define ARCH_PFN_OFFSET		((unsigned long)PHYS_PFN_OFFSET)
 
+#ifndef CONFIG_SPARSEMEM_VMEMMAP
 #define virt_to_page(kaddr)	pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
-#define	virt_addr_valid(kaddr)	pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
+#define virt_addr_valid(kaddr)	pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
+#else
+#define virt_to_page(kaddr)	((struct page *)VMEMMAP_START + \
+				 (((u64)(kaddr) & ~PAGE_OFFSET) >> PAGE_SHIFT))
+#define virt_addr_valid(kaddr)	pfn_valid((((u64)(kaddr) & ~PAGE_OFFSET) \
+					   + PHYS_OFFSET) >> PAGE_SHIFT)
+#endif
 
 #endif
 
-- 
2.5.0



From ard.biesheuvel at linaro.org  Wed Feb 24 08:21:28 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 24 Feb 2016 17:21:28 +0100
Subject: [RFC PATCH 1/6] arm64: vmemmap: use virtual projection of linear
 region
In-Reply-To: <1456330893-19228-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456330893-19228-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456330893-19228-2-git-send-email-ard.biesheuvel@linaro.org>

Commit dd006da21646 ("arm64: mm: increase VA range of identity map") made
some changes to the memory mapping code to allow physical memory to reside
at an offset that exceeds the size of the virtual address space.

However, since the size of the vmemmap area is proportional to the size of
the VA area, but it is populated relative to the physical space, we may
end up with the struct page array being mapped outside of the vmemmap
region. For instance, on my Seattle A0 box, I can see the following output
in the dmesg log.

   vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000   (     8 GB maximum)
             0xffffffbfc0000000 - 0xffffffbfd0000000   (   256 MB actual)

We can fix this by deciding that the vmemmap region is not a projection of
the physical space, but of the virtual space above PAGE_OFFSET, i.e., the
linear region. This way, we are guaranteed that the vmemmap region is of
sufficient size, and we can also reduce its size by half.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/pgtable.h | 7 ++++---
 arch/arm64/mm/init.c             | 4 ++--
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index a440f5a85d08..8e6baea0ff61 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -34,18 +34,19 @@
 /*
  * VMALLOC and SPARSEMEM_VMEMMAP ranges.
  *
- * VMEMAP_SIZE: allows the whole VA space to be covered by a struct page array
+ * VMEMAP_SIZE: allows the whole linear region to be covered by a struct page array
  *	(rounded up to PUD_SIZE).
  * VMALLOC_START: beginning of the kernel vmalloc space
  * VMALLOC_END: extends to the available space below vmmemmap, PCI I/O space,
  *	fixed mappings and modules
  */
-#define VMEMMAP_SIZE		ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) * sizeof(struct page), PUD_SIZE)
+#define VMEMMAP_SIZE		ALIGN((1UL << (VA_BITS - PAGE_SHIFT - 1)) * sizeof(struct page), PUD_SIZE)
 
 #define VMALLOC_START		(MODULES_END)
 #define VMALLOC_END		(PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - SZ_64K)
 
-#define vmemmap			((struct page *)(VMALLOC_END + SZ_64K))
+#define VMEMMAP_START		(VMALLOC_END + SZ_64K)
+#define vmemmap			((struct page *)(VMEMMAP_START - memstart_addr / sizeof(struct page)))
 
 #define FIRST_USER_ADDRESS	0UL
 
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index c0ea54bd9995..88046b94fa87 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -363,8 +363,8 @@ void __init mem_init(void)
 		  MLK_ROUNDUP(_text, _etext),
 		  MLK_ROUNDUP(_sdata, _edata),
 #ifdef CONFIG_SPARSEMEM_VMEMMAP
-		  MLG((unsigned long)vmemmap,
-		      (unsigned long)vmemmap + VMEMMAP_SIZE),
+		  MLG(VMEMMAP_START,
+		      VMEMMAP_START + VMEMMAP_SIZE),
 		  MLM((unsigned long)virt_to_page(PAGE_OFFSET),
 		      (unsigned long)virt_to_page(high_memory)),
 #endif
-- 
2.5.0



From ard.biesheuvel at linaro.org  Wed Feb 24 08:21:29 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Wed, 24 Feb 2016 17:21:29 +0100
Subject: [RFC PATCH 2/6] arm64: vdso: avoid virt_to_page() translations on
 kernel symbols
In-Reply-To: <1456330893-19228-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456330893-19228-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <1456330893-19228-3-git-send-email-ard.biesheuvel@linaro.org>

The translation performed by virt_to_page() is only valid for linear
addresses, and kernel symbols are no longer in the linear mapping.
So perform the __pa() translation explicitly, which does the right
thing in either case, and only then translate to a struct page offset.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/kernel/vdso.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 97bc68f4c689..fb3c17f031aa 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -131,11 +131,12 @@ static int __init vdso_init(void)
 		return -ENOMEM;
 
 	/* Grab the vDSO data page. */
-	vdso_pagelist[0] = virt_to_page(vdso_data);
+	vdso_pagelist[0] = pfn_to_page(__pa(vdso_data) >> PAGE_SHIFT);
 
 	/* Grab the vDSO code pages. */
-	for (i = 0; i < vdso_pages; i++)
-		vdso_pagelist[i + 1] = virt_to_page(&vdso_start + i * PAGE_SIZE);
+	vdso_pagelist[1] = pfn_to_page(__pa(&vdso_start) >> PAGE_SHIFT);
+	for (i = 1; i < vdso_pages; i++)
+		vdso_pagelist[i + 1] = vdso_pagelist[1] + i;
 
 	/* Populate the special mapping structures */
 	vdso_spec[0] = (struct vm_special_mapping) {
-- 
2.5.0



From arnd at arndb.de  Wed Feb 24 08:22:57 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Feb 2016 17:22:57 +0100
Subject: [PATCH 1/2] ARM: mxs_defconfig: Cleanup mxs_defconfig
In-Reply-To: <1456326291-20618-1-git-send-email-m.grzeschik@pengutronix.de>
References: <1456326291-20618-1-git-send-email-m.grzeschik@pengutronix.de>
Message-ID: <5137278.2zPjnDRSyU@wuerfel>

On Wednesday 24 February 2016 16:04:50 Michael Grzeschik wrote:
> @@ -144,7 +144,6 @@ CONFIG_PWM_MXS=y
>  CONFIG_EXT2_FS=y
>  CONFIG_EXT2_FS_XATTR=y
>  CONFIG_EXT3_FS=y
> -CONFIG_EXT4_FS=y
>  # CONFIG_DNOTIFY is not set
>  CONFIG_FSCACHE=m
>  CONFIG_FSCACHE_STATS=y
> @@ -178,7 +177,6 @@ CONFIG_PROVE_LOCKING=y
> 

EXT3_FS is deprecated and only there to select EXT4_FS. Please drop
the other one instead. While we are there, you could also drop EXT2_FS,
as that is now handled by EXT4_FS as well.

	Arnd


From tiwai at suse.de  Wed Feb 24 08:25:42 2016
From: tiwai at suse.de (Takashi Iwai)
Date: Wed, 24 Feb 2016 17:25:42 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <3238725.1iS2dg6EkI@wuerfel>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
 <s5h8u2j6749.wl-tiwai@suse.de> <s5h1t8b65n7.wl-tiwai@suse.de>
 <3238725.1iS2dg6EkI@wuerfel>
Message-ID: <s5hziuqcby1.wl-tiwai@suse.de>

On Wed, 24 Feb 2016 17:18:58 +0100,
Arnd Bergmann wrote:
> 
> On Wednesday 17 February 2016 10:35:40 Takashi Iwai wrote:
> > On Wed, 17 Feb 2016 10:03:50 +0100,
> > +	const char *id;
> > +#ifdef CONFIG_SND_JACK_INPUT_DEV
> > +	struct input_dev *input_dev;
> >  	int registered;
> >  	int type;
> > -	const char *id;
> >  	char name[100];
> >  	unsigned int key[6];   /* Keep in sync with definitions above */
> > +#endif /* CONFIG_SND_JACK_INPUT_DEV */
> >  	void *private_data;
> >  	void (*private_free)(struct snd_jack *);
> >  };
> 
> I got a build error from this today, as the trace event tries to print
> the jack "name" field. I've managed to get it to build again by printing
> the "id" field in place of the "name". The name is normally assigned
> from id in snd_jack_dev_register using
> 
>         snprintf(jack->name, sizeof(jack->name), "%s %s",
>                  card->shortname, jack->id);
> 
> but that code is not called here at all. My patch will slightly
> alter the output as a consequence, but I don't know if this change
> is critical or not.

Thanks for catching this.  Yes, your fix is correct.  This must have
been a wrong pick up when converting from the standalone hda jack to
unified jack stuff.

Could you send a proper patch for inclusion?


Takashi

> 
> 	Arnd
> 
> diff --git a/include/trace/events/asoc.h b/include/trace/events/asoc.h
> index 317a1ed2f4ac..9130dd5a184a 100644
> --- a/include/trace/events/asoc.h
> +++ b/include/trace/events/asoc.h
> @@ -231,13 +231,13 @@ TRACE_EVENT(snd_soc_jack_report,
>  	TP_ARGS(jack, mask, val),
>  
>  	TP_STRUCT__entry(
> -		__string(	name,		jack->jack->name	)
> +		__string(	name,		jack->jack->id		)
>  		__field(	int,		mask			)
>  		__field(	int,		val			)
>  	),
>  
>  	TP_fast_assign(
> -		__assign_str(name, jack->jack->name);
> +		__assign_str(name, jack->jack->id);
>  		__entry->mask = mask;
>  		__entry->val = val;
>  	),
> @@ -253,12 +253,12 @@ TRACE_EVENT(snd_soc_jack_notify,
>  	TP_ARGS(jack, val),
>  
>  	TP_STRUCT__entry(
> -		__string(	name,		jack->jack->name	)
> +		__string(	name,		jack->jack->id		)
>  		__field(	int,		val			)
>  	),
>  
>  	TP_fast_assign(
> -		__assign_str(name, jack->jack->name);
> +		__assign_str(name, jack->jack->id);
>  		__entry->val = val;
>  	),
>  
> 


From arnd at arndb.de  Wed Feb 24 08:38:14 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Feb 2016 17:38:14 +0100
Subject: [PATCH] ASoC: trace: fix printing jack name
Message-ID: <1456331903-3999234-1-git-send-email-arnd@arndb.de>

After a change to the snd_jack structure, the 'name' member
is no longer available in all configurations, which results in a
build failure in the tracing code:

include/trace/events/asoc.h: In function 'trace_event_raw_event_snd_soc_jack_report':
include/trace/events/asoc.h:240:32: error: 'struct snd_jack' has no member named 'name'

The name field is normally initialized from the card shortname and
the jack "id" field:

        snprintf(jack->name, sizeof(jack->name), "%s %s",
                 card->shortname, jack->id);

This changes the tracing output to just contain the 'id' by
itself, which slightly changes the output format but avoids the
link error and is hopefully still enough to see what is going on.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: fe0d128c57bf ("ALSA: jack: Allow building the jack layer without input device")
---
 include/trace/events/asoc.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/trace/events/asoc.h b/include/trace/events/asoc.h
index 317a1ed2f4ac..9130dd5a184a 100644
--- a/include/trace/events/asoc.h
+++ b/include/trace/events/asoc.h
@@ -231,13 +231,13 @@ TRACE_EVENT(snd_soc_jack_report,
 	TP_ARGS(jack, mask, val),
 
 	TP_STRUCT__entry(
-		__string(	name,		jack->jack->name	)
+		__string(	name,		jack->jack->id		)
 		__field(	int,		mask			)
 		__field(	int,		val			)
 	),
 
 	TP_fast_assign(
-		__assign_str(name, jack->jack->name);
+		__assign_str(name, jack->jack->id);
 		__entry->mask = mask;
 		__entry->val = val;
 	),
@@ -253,12 +253,12 @@ TRACE_EVENT(snd_soc_jack_notify,
 	TP_ARGS(jack, val),
 
 	TP_STRUCT__entry(
-		__string(	name,		jack->jack->name	)
+		__string(	name,		jack->jack->id		)
 		__field(	int,		val			)
 	),
 
 	TP_fast_assign(
-		__assign_str(name, jack->jack->name);
+		__assign_str(name, jack->jack->id);
 		__entry->val = val;
 	),
 
-- 
2.7.0



From arnd at arndb.de  Wed Feb 24 08:39:02 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Feb 2016 17:39:02 +0100
Subject: [PATCH] sound: hdmi: avoid dereferencing uninitialized 'jack'
 pointer
In-Reply-To: <s5hziuqcby1.wl-tiwai@suse.de>
References: <1455634059-1896914-1-git-send-email-arnd@arndb.de>
 <3238725.1iS2dg6EkI@wuerfel> <s5hziuqcby1.wl-tiwai@suse.de>
Message-ID: <2576612.maDBOzAeKt@wuerfel>

On Wednesday 24 February 2016 17:25:42 Takashi Iwai wrote:
> 
> Thanks for catching this.  Yes, your fix is correct.  This must have
> been a wrong pick up when converting from the standalone hda jack to
> unified jack stuff.
> 
> Could you send a proper patch for inclusion?

Ok, done.

	Arnd


From swarren at wwwdotorg.org  Wed Feb 24 08:41:42 2016
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 24 Feb 2016 09:41:42 -0700
Subject: [PATCH 30/50] pinctrl: tegra-xusb: Use devm_pinctrl_register()
 for pinctrl registration
In-Reply-To: <1456319775-3216-31-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-31-git-send-email-ldewangan@nvidia.com>
Message-ID: <56CDDD46.1060907@wwwdotorg.org>

On 02/24/2016 06:15 AM, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration and clean
> the error path.

Acked-by: Stephen Warren <swarren at nvidia.com>



From swarren at wwwdotorg.org  Wed Feb 24 08:44:08 2016
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 24 Feb 2016 09:44:08 -0700
Subject: [PATCH 29/50] pinctrl: tegra: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-30-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-30-git-send-email-ldewangan@nvidia.com>
Message-ID: <56CDDDD8.8040304@wwwdotorg.org>

On 02/24/2016 06:15 AM, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration and remove
> need of .remove callback.

Acked-by: Stephen Warren <swarren at nvidia.com>

Any chance you could send a patch to soc-to-kernel-pinctrl-driver.py in 
git://github.com/NVIDIA/tegra-pinmux-scripts.git for this too?


From gerald.schaefer at de.ibm.com  Wed Feb 24 08:44:46 2016
From: gerald.schaefer at de.ibm.com (Gerald Schaefer)
Date: Wed, 24 Feb 2016 17:44:46 +0100
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe
 also on PowerPC and ARM)
In-Reply-To: <20160223193345.GC21820@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160223103221.GA1418@node.shutemov.name>
 <20160223191907.25719a4d@thinkpad>
 <20160223193345.GC21820@node.shutemov.name>
Message-ID: <20160224174446.76095849@thinkpad>

On Tue, 23 Feb 2016 22:33:45 +0300
"Kirill A. Shutemov" <kirill at shutemov.name> wrote:

> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> > I'll check with Martin, maybe it is actually trivial, then we can
> > do a quick test it to rule that one out.
> 
> Oh. I found a bug in __split_huge_pmd_locked(). Although, not sure if it's
> _the_ bug.
> 
> pmdp_invalidate() is called for the wrong address :-/
> I guess that can be destructive on the architecture, right?

Thanks, that's it! We can no longer reproduce the crashes and calling
pmdp_invalidate() with a wrong address also perfectly explains the
memory corruption that I found in several dumps: 0x020 was ORed into
pte entries, which didn't make sense, and caused the list corruption
for example. 0x020 it is the invalid bit for pmd entries on s390 and
thus can be explained by this bug when a pte table lies before a pmd
table in memory.

> 
> Could you check this?
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 1c317b85ea7d..4246bc70e55a 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2865,7 +2865,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
>  	pgtable = pgtable_trans_huge_withdraw(mm, pmd);
>  	pmd_populate(mm, &_pmd, pgtable);
> 
> -	for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
> +	for (i = 0; i < HPAGE_PMD_NR; i++) {
>  		pte_t entry, *pte;
>  		/*
>  		 * Note that NUMA hinting access restrictions are not
> @@ -2886,9 +2886,9 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
>  		}
>  		if (dirty)
>  			SetPageDirty(page + i);
> -		pte = pte_offset_map(&_pmd, haddr);
> +		pte = pte_offset_map(&_pmd, haddr + i * PAGE_SIZE);
>  		BUG_ON(!pte_none(*pte));
> -		set_pte_at(mm, haddr, pte, entry);
> +		set_pte_at(mm, haddr + i * PAGE_SIZE, pte, entry);
>  		atomic_inc(&page[i]._mapcount);
>  		pte_unmap(pte);
>  	}
> @@ -2938,7 +2938,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
>  	pmd_populate(mm, pmd, pgtable);
> 
>  	if (freeze) {
> -		for (i = 0; i < HPAGE_PMD_NR; i++, haddr += PAGE_SIZE) {
> +		for (i = 0; i < HPAGE_PMD_NR; i++) {
>  			page_remove_rmap(page + i, false);
>  			put_page(page + i);
>  		}



From romain.izard.pro at gmail.com  Wed Feb 24 08:44:59 2016
From: romain.izard.pro at gmail.com (Romain Izard)
Date: Wed, 24 Feb 2016 17:44:59 +0100
Subject: [PATCH v2] clocksource: atmel-pit: register as a sched_clock
In-Reply-To: <20160224162046.GA28743@finsecur.com>
References: <1456329882-20709-1-git-send-email-romain.izard.pro@gmail.com>
 <20160224162046.GA28743@finsecur.com>
Message-ID: <CAGkQfmPpyhU025nt+tcnsjWK3V+K3_7oiXxeqa7mPuHT08sLig@mail.gmail.com>

2016-02-24 17:20 GMT+01:00 Sylvain Rochet <sylvain.rochet at finsecur.com>:
> Hi,
>
> On Wed, Feb 24, 2016 at 05:04:42PM +0100, Romain Izard wrote:
>> Register the counter of the Periodic Interval Timer as a possible
>> source for sched_clock. Keep the timer running even if the related
>> clockevent is disabled.
>>
>> This provides a better precision than the jiffies-based default. The
>> TCB clocksource does not work, as it is registered too late in the
>> initialization sequence.
>
> I have mixed feelings about that, but this is probably just a
> misunderstanding from my part.
>
My goal is to get a better precision on my printk and trace logs,
because the precision of jiffies is really very bad compared to
everything else I have encountered until now. But it looks like reading
a timer is quite complicated on AT91...

> The PIT timer should not be used for systems with PM_SUSPEND enabled
> and used because it takes ages to synchronize on resume, how does this
> patch affect that ?
>
> Ref: commit ac34ad27fc ("clockevents: Do not suspend/resume if
> unused")

So your advice would be to stay clear of the PIT, because it is
(globally) useless.

I'll keep it in mind.

Best regards,
-- 
Romain Izard


From olof at lixom.net  Wed Feb 24 08:48:08 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 08:48:08 -0800
Subject: [GIT PULL] Renesas ARM Based SoC Fixes for v4.5
In-Reply-To: <CAMuHMdWxXFf0MFKP27y6g7CUc1MeG0PuJ-FdoSkV+2gB5NvQTA@mail.gmail.com>
References: <cover.1455859965.git.horms+renesas@verge.net.au>
 <20160224080803.GD30231@localhost>
 <CAMuHMdWxXFf0MFKP27y6g7CUc1MeG0PuJ-FdoSkV+2gB5NvQTA@mail.gmail.com>
Message-ID: <CAOesGMhab6SX5o-1CXKt-FNOrg+Nk9w1ccR=Co1DVXrJUKN4cw@mail.gmail.com>

On Wed, Feb 24, 2016 at 12:37 AM, Geert Uytterhoeven
<geert at linux-m68k.org> wrote:
> Hi Olof,
>
> On Wed, Feb 24, 2016 at 9:08 AM, Olof Johansson <olof at lixom.net> wrote:
>> On Fri, Feb 19, 2016 at 03:09:46PM +0900, Simon Horman wrote:
>>> Please consider these Renesas ARM based SoC fixes for v4.5.
>>>
>>> This pull request is comprised of patches from Geert Uytterhoeven to avoid
>>> writing to .text.
>>>
>>> * "ARM: shmobile: Move shmobile_scu_base from .text to .bss"
>>>
>>>   Resolves a problem for XIP kernels as writing to .text is not allowed.
>>>   For non-XIP kernels a problem does not manifst as the pages are mapped
>>>   read-only during late kernel startup.
>>>
>>> * The remaining patches resolve a kernel-crash that occurs during system
>>>   suspend for CONFIG_DEBUG_RODATA=y kernels.
>>>
>>>
>>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>>
>>>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-fixes-for-v4.5
>>>
>>> for you to fetch changes up to 901c5ffaaed117a38be9d0c29247c4888d6c8636:
>>>
>>>   ARM: shmobile: Remove shmobile_boot_arg (2016-02-17 18:27:21 +0900)
>>
>> Hi Simon, Geert,
>>
>> I don't think any of these fixes are for regressions, are they? I.e. this is
>> work to enable configs that never used to work (XIP, CONFIG_DEBUG_RODATA)?
>
> These configs indeed never worked before.
>
> However,
>
> commit 25362dc496edaf17f714c0fecd8b3eb79670207b
> Author: Kees Cook <keescook at chromium.org>
> Date:   Tue Jan 26 01:19:36 2016 +0100
>
>     ARM: 8501/1: mm: flip priority of CONFIG_DEBUG_RODATA
>
> in arm/for-next will enable CONFIG_DEBUG_RODATA by default.
>
> Not having the fixes in v4.5 means that if Russell's tree is merged
> into mainline
> for v4.6 before arm-soc, it will cause regressions and bisection issues.

Ok, either way there'll be windows in which bisect will fail since the
changes are on independent branches.

Based on that, and looking at the patches, I'll pick it up now for fixes.


-Olof


From rostedt at goodmis.org  Wed Feb 24 08:50:37 2016
From: rostedt at goodmis.org (Steven Rostedt)
Date: Wed, 24 Feb 2016 11:50:37 -0500
Subject: [PATCH] ASoC: trace: fix printing jack name
In-Reply-To: <1456331903-3999234-1-git-send-email-arnd@arndb.de>
References: <1456331903-3999234-1-git-send-email-arnd@arndb.de>
Message-ID: <20160224115037.40772a90@gandalf.local.home>

On Wed, 24 Feb 2016 17:38:14 +0100
Arnd Bergmann <arnd at arndb.de> wrote:

> After a change to the snd_jack structure, the 'name' member
> is no longer available in all configurations, which results in a
> build failure in the tracing code:
> 
> include/trace/events/asoc.h: In function 'trace_event_raw_event_snd_soc_jack_report':
> include/trace/events/asoc.h:240:32: error: 'struct snd_jack' has no member named 'name'
> 
> The name field is normally initialized from the card shortname and
> the jack "id" field:
> 
>         snprintf(jack->name, sizeof(jack->name), "%s %s",
>                  card->shortname, jack->id);
> 
> This changes the tracing output to just contain the 'id' by
> itself, which slightly changes the output format but avoids the
> link error and is hopefully still enough to see what is going on.

If people would like name if available, we could do:

#ifdef CONFIG_SND_JACK_INPUT_DEV
# define JACK_NAME(jk)		(jk)->jack->name
#else
# define JACK_NAME(jk)		(jk)->jack->id
#endif

And then below have:

	__string(	name,	JACK_NAME(jack)	)


The #ifdef can stay in the events/asoc.h file.

-- Steve


>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: fe0d128c57bf ("ALSA: jack: Allow building the jack layer without input device")
> ---
>  include/trace/events/asoc.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/include/trace/events/asoc.h b/include/trace/events/asoc.h
> index 317a1ed2f4ac..9130dd5a184a 100644
> --- a/include/trace/events/asoc.h
> +++ b/include/trace/events/asoc.h
> @@ -231,13 +231,13 @@ TRACE_EVENT(snd_soc_jack_report,
>  	TP_ARGS(jack, mask, val),
>  
>  	TP_STRUCT__entry(
> -		__string(	name,		jack->jack->name	)
> +		__string(	name,		jack->jack->id		)
>  		__field(	int,		mask			)
>  		__field(	int,		val			)
>  	),
>  
>  	TP_fast_assign(
> -		__assign_str(name, jack->jack->name);
> +		__assign_str(name, jack->jack->id);
>  		__entry->mask = mask;
>  		__entry->val = val;
>  	),
> @@ -253,12 +253,12 @@ TRACE_EVENT(snd_soc_jack_notify,
>  	TP_ARGS(jack, val),
>  
>  	TP_STRUCT__entry(
> -		__string(	name,		jack->jack->name	)
> +		__string(	name,		jack->jack->id		)
>  		__field(	int,		val			)
>  	),
>  
>  	TP_fast_assign(
> -		__assign_str(name, jack->jack->name);
> +		__assign_str(name, jack->jack->id);
>  		__entry->val = val;
>  	),
>  



From arnd at arndb.de  Wed Feb 24 08:56:57 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Feb 2016 17:56:57 +0100
Subject: [PATCH] rtc: mt6397: Add platform device ID table
In-Reply-To: <1455628747.2981.4.camel@mtksdaap41>
References: <1455016095-13724-1-git-send-email-javier@osg.samsung.com>
 <2416670.q30ahHlzPm@wuerfel> <1455628747.2981.4.camel@mtksdaap41>
Message-ID: <3216713.qF8RyQVuPO@wuerfel>

On Tuesday 16 February 2016 21:19:07 Eddie Huang wrote:
> On Tue, 2016-02-16 at 12:37 +0100, Arnd Bergmann wrote:
> > On Monday 15 February 2016 11:50:48 Javier Martinez Canillas wrote:
> > > 
> > > On 02/14/2016 10:58 PM, Eddie Huang wrote:
> > > 
> > > [snip]
> > > 
> > > >> @@ -412,6 +418,7 @@ static struct platform_driver mtk_rtc_driver = {
> > > >>      },
> > > >>      .probe  = mtk_rtc_probe,
> > > >>      .remove = mtk_rtc_remove,
> > > >> +    .id_table = mt6397_rtc_id,
> > > >>   };
> > > >>
> > > >>   module_platform_driver(mtk_rtc_driver);
> > > >> @@ -419,4 +426,3 @@ module_platform_driver(mtk_rtc_driver);
> > > >>   MODULE_LICENSE("GPL v2");
> > > >>   MODULE_AUTHOR("Tianping Fang <tianping.fang at mediatek.com>");
> > > >>   MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC");
> > > >> -MODULE_ALIAS("platform:mt6397-rtc");
> > > >
> > > > This patch looks good to me, but I am wondering, since we tend to use
> > > > device tree method to match driver, do we still need support platform
> > > > device ID ?
> > > >
> > > 
> > > I'm not familiar with neither this IP block nor the SoC so it is up to
> > > you. I just noticed this issue when reviewing a regulator driver for a
> > > similar PMIC posted by someone from mediatek.
> > > 
> > > I thought platform device was needed since the driver has a MODULE_ALIAS()
> > > but please let me know what you prefer and I can re-spin the patch and
> > > just remove the MODULE_ALIAS() if that makes more sense for this platform.
> > >   
> > > 
> > 
> > I agree. We can alway add a MODULE_DEVICE_TABLE() if we get multiple
> > users of this driver on architectures that don't use devicetree yet.
> > 
> 
> Sure. Thanks the patch to add expandability to this driver.
> 
> Acked-by: Eddie Huang <eddie.huang at mediatek.com>

I think we misunderstood one another. I think we can drop both the MODULE_DEVICE_TABLE and the MODULE_ALIAS: there is no need for another
driver ID when it is always probed using DT.

	Arnd


From dinguyen at opensource.altera.com  Wed Feb 24 08:50:15 2016
From: dinguyen at opensource.altera.com (Dinh Nguyen)
Date: Wed, 24 Feb 2016 10:50:15 -0600
Subject: [PATCH] dts: add specific compatible type for Terasic DE0-NANO-SoC
 Board
In-Reply-To: <8416439.76b9YNhpgR@dabox>
References: <8416439.76b9YNhpgR@dabox>
Message-ID: <alpine.DEB.2.02.1602241048100.3815@linux-builds1>

Hi Tim,

On Fri, 12 Feb 2016, Tim Sander wrote:

> From: Tim Sander <tim at krieglstein.org>
> 
> Add a more specific compatible string:"terasic,de0-nano-soc" for respective board.
> Background: when checking for bootspec entries, some board specific fixups
>                          are not apropriate for board of the same platform ("altr,socfpga-cyclone5").
>                         The same aproach is taken with the EBV-Socrates board.
>

Please fix up the spacing in the commit message.

> Signed-off-by: Tim Sander <tim at krieglstein.org>
> ---
>  arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
> index 555e9caf21e1..3a427423168e 100644
> --- a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
> +++ b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
> @@ -18,7 +18,7 @@
>  
>  / {
>         model = "Terasic DE-0(Atlas)";
> -       compatible = "altr,socfpga-cyclone5", "altr,socfpga";
> +       compatible = "terasic,de0-nano-soc"," altr,socfpga-cyclone5", "altr,socfpga";
> 

"terasic" is not listed in Documentation/devicetree/bindings/vendor-prefixes.txt.
 
BR,
Dinh


From olof at lixom.net  Wed Feb 24 08:58:14 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 08:58:14 -0800
Subject: [PATCH 00/13] arm-cci: PMU driver updates for 4.6
In-Reply-To: <56CC64E7.3040407@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
 <20160223114003.GF3966@arm.com> <56CC64E7.3040407@arm.com>
Message-ID: <20160224165814.GA10126@localhost>

On Tue, Feb 23, 2016 at 01:55:51PM +0000, Suzuki K. Poulose wrote:
> On 23/02/16 11:40, Will Deacon wrote:
> >On Tue, Feb 23, 2016 at 10:49:42AM +0000, Suzuki K Poulose wrote:
> >>Here are some fixes and updates for arm-cci pmu driver targeting v4.6,
> >>applies on top of v4.5-rc5.
> >>
> >>Highlights include :
> >>  - Support for CoreLink CCI-550 PMU
> >>  - Reliable writes to PMU Counter registers for CCI-500/550.
> >>
> >>All the patches have been Acked. Please let me know how this
> >>can be merged.
> 
> >>
> >>  Documentation/devicetree/bindings/arm/cci.txt |    2 +
> >>  drivers/bus/Kconfig                           |   10 +-
> >>  drivers/bus/arm-cci.c                         |  612 +++++++++++++++++--------
> >>  3 files changed, 427 insertions(+), 197 deletions(-)
> >
> >How do you plan to merge this? I can take it all onto a branch for
> >arm-soc, or I can include it on my perf/updates branch, or ...?
> 
> Arnd, Olof,
> 
> What do you think would be the best route ?

Traditionally we've been picking these up in arm-soc in our drivers branch.

Will, unless you want them in your tree for some reason that's what I'll do
here as well.


-Olof


From javier at osg.samsung.com  Wed Feb 24 09:02:09 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Wed, 24 Feb 2016 14:02:09 -0300
Subject: [PATCH] rtc: mt6397: Add platform device ID table
In-Reply-To: <3216713.qF8RyQVuPO@wuerfel>
References: <1455016095-13724-1-git-send-email-javier@osg.samsung.com>
 <2416670.q30ahHlzPm@wuerfel> <1455628747.2981.4.camel@mtksdaap41>
 <3216713.qF8RyQVuPO@wuerfel>
Message-ID: <56CDE211.1000802@osg.samsung.com>

Hello Arnd,

On 02/24/2016 01:56 PM, Arnd Bergmann wrote:
> On Tuesday 16 February 2016 21:19:07 Eddie Huang wrote:
>> On Tue, 2016-02-16 at 12:37 +0100, Arnd Bergmann wrote:
>>> On Monday 15 February 2016 11:50:48 Javier Martinez Canillas wrote:
>>>>
>>>> On 02/14/2016 10:58 PM, Eddie Huang wrote:
>>>>
>>>> [snip]
>>>>
>>>>>> @@ -412,6 +418,7 @@ static struct platform_driver mtk_rtc_driver = {
>>>>>>       },
>>>>>>       .probe  = mtk_rtc_probe,
>>>>>>       .remove = mtk_rtc_remove,
>>>>>> +    .id_table = mt6397_rtc_id,
>>>>>>    };
>>>>>>
>>>>>>    module_platform_driver(mtk_rtc_driver);
>>>>>> @@ -419,4 +426,3 @@ module_platform_driver(mtk_rtc_driver);
>>>>>>    MODULE_LICENSE("GPL v2");
>>>>>>    MODULE_AUTHOR("Tianping Fang <tianping.fang at mediatek.com>");
>>>>>>    MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC");
>>>>>> -MODULE_ALIAS("platform:mt6397-rtc");
>>>>>
>>>>> This patch looks good to me, but I am wondering, since we tend to use
>>>>> device tree method to match driver, do we still need support platform
>>>>> device ID ?
>>>>>
>>>>
>>>> I'm not familiar with neither this IP block nor the SoC so it is up to
>>>> you. I just noticed this issue when reviewing a regulator driver for a
>>>> similar PMIC posted by someone from mediatek.
>>>>
>>>> I thought platform device was needed since the driver has a MODULE_ALIAS()
>>>> but please let me know what you prefer and I can re-spin the patch and
>>>> just remove the MODULE_ALIAS() if that makes more sense for this platform.
>>>>
>>>>
>>>
>>> I agree. We can alway add a MODULE_DEVICE_TABLE() if we get multiple
>>> users of this driver on architectures that don't use devicetree yet.
>>>
>>
>> Sure. Thanks the patch to add expandability to this driver.
>>
>> Acked-by: Eddie Huang <eddie.huang at mediatek.com>
>
> I think we misunderstood one another. I think we can drop both the MODULE_DEVICE_TABLE and the MODULE_ALIAS: there is no need for another
> driver ID when it is always probed using DT.
>

That's how I understood but then Eddie said the opposite so I got confused
and was waiting for your clarification. I'll re-spin and remove the alias.

> 	Arnd
>

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America


From aleksey.makarov at linaro.org  Wed Feb 24 09:10:10 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Wed, 24 Feb 2016 20:10:10 +0300
Subject: [PATCH v2 1/8] arm64: move acpi/dt decision earlier in boot process
In-Reply-To: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456333819-13482-2-git-send-email-aleksey.makarov@linaro.org>

From: Leif Lindholm <leif.lindholm at linaro.org>

In order to support selecting earlycon via either ACPI or DT, move
the decision on whether to attempt ACPI configuration into the
early_param handling. Then make acpi_boot_table_init() bail out if
acpi_disabled.

Signed-off-by: Leif Lindholm <leif.lindholm at linaro.org>
Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 arch/arm64/kernel/acpi.c | 62 +++++++++++++++++++++++-------------------------
 1 file changed, 30 insertions(+), 32 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index d1ce8e2..3faa323 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -41,26 +41,8 @@ EXPORT_SYMBOL(acpi_disabled);
 int acpi_pci_disabled = 1;	/* skip ACPI PCI scan and IRQ initialization */
 EXPORT_SYMBOL(acpi_pci_disabled);
 
-static bool param_acpi_off __initdata;
 static bool param_acpi_force __initdata;
 
-static int __init parse_acpi(char *arg)
-{
-	if (!arg)
-		return -EINVAL;
-
-	/* "acpi=off" disables both ACPI table parsing and interpreter */
-	if (strcmp(arg, "off") == 0)
-		param_acpi_off = true;
-	else if (strcmp(arg, "force") == 0) /* force ACPI to be enabled */
-		param_acpi_force = true;
-	else
-		return -EINVAL;	/* Core will print when we return error */
-
-	return 0;
-}
-early_param("acpi", parse_acpi);
-
 static int __init dt_scan_depth1_nodes(unsigned long node,
 				       const char *uname, int depth,
 				       void *data)
@@ -74,6 +56,35 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
 	return 0;
 }
 
+static int __init parse_acpi(char *arg)
+{
+	if (!arg)
+		return -EINVAL;
+
+	/*
+	 * Enable ACPI instead of device tree unless
+	 * - ACPI has been disabled explicitly (acpi=off), or
+	 * - the device tree is not empty (it has more than just a /chosen node)
+	 *   and ACPI has not been force enabled (acpi=force)
+	 */
+	if (strcmp(arg, "off") == 0)
+		return 0;
+	else if (strcmp(arg, "force") == 0)
+		param_acpi_force = true;
+	else if (of_scan_flat_dt(dt_scan_depth1_nodes, NULL))
+		return 0;
+
+	/*
+	 * ACPI is disabled at this point. Enable it in order to parse
+	 * the ACPI tables and carry out sanity checks
+	 */
+	enable_acpi();
+
+	return 0;
+}
+
+early_param("acpi", parse_acpi);
+
 /*
  * __acpi_map_table() will be called before page_init(), so early_ioremap()
  * or early_memremap() should be called here to for ACPI table mapping.
@@ -181,23 +192,10 @@ out:
  */
 void __init acpi_boot_table_init(void)
 {
-	/*
-	 * Enable ACPI instead of device tree unless
-	 * - ACPI has been disabled explicitly (acpi=off), or
-	 * - the device tree is not empty (it has more than just a /chosen node)
-	 *   and ACPI has not been force enabled (acpi=force)
-	 */
-	if (param_acpi_off ||
-	    (!param_acpi_force && of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
+	if (acpi_disabled)
 		return;
 
 	/*
-	 * ACPI is disabled at this point. Enable it in order to parse
-	 * the ACPI tables and carry out sanity checks
-	 */
-	enable_acpi();
-
-	/*
 	 * If ACPI tables are initialized and FADT sanity checks passed,
 	 * leave ACPI enabled and carry on booting; otherwise disable ACPI
 	 * on initialization error.
-- 
2.7.1



From aleksey.makarov at linaro.org  Wed Feb 24 09:10:09 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Wed, 24 Feb 2016 20:10:09 +0300
Subject: [PATCH v2 0/8] ACPI: parse the DBG2 table
Message-ID: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>

"ARM Server Base Boot Requiremets" [1] mentions DBG2 (Microsoft Debug
Port Table 2) [2] as a mandatory ACPI table that specifies debug ports.

- Move acpi/dt decision earlier in boot process on ARM64
- Move earlycon early_param handling to serial to parse earlycon option once
- Add definition of DBG2 subtypes.  It's the same patch as in the SPCR series [3]
- Refactor ACPI linker tables code to enable iterating over subtables other than
  subtables having acpi_subtype header (such as DBG2)
- Implement macros

	ACPI_DBG2_DECLARE(name, type, subtype, setup_fn, data_ptr)

  that defines a handler for the port of the given type and subtype.
- For each port defined by that macros that is also described in the ACPI DBG2
  table call provided callback.
- Implement a helper macros that can be used to define early serial console
- Enable DBG2 on ARM64
- Define early console for pl011 serial

Based on the original work by Leif Lindholm <leif.lindholm at linaro.org> [4]

Should be applied to next-20160224.

Tested on last QEMU with patches that introduce DBG2 and fix a QEMU bug:

https://git.linaro.org/people/aleksey.makarov/qemu.git amakarov/gdb2.03

v2:
- Fix parse_acpi() (Matthias Brugger)
- Add a reference to QEMU DBG2 patches and to original work
- Rebase to the last linux-next

v1:
https://lkml.kernel.org/g/1456148818-26257-1-git-send-email-aleksey.makarov at linaro.org

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
[2] http://go.microsoft.com/fwlink/p/?LinkId=234837
[3] https://lkml.kernel.org/g/1455559532-8305-1-git-send-email-aleksey.makarov at linaro.org
[4] https://lkml.kernel.org/g/1441716217-23786-1-git-send-email-leif.lindholm at linaro.org

Aleksey Makarov (6):
  ACPI: add definitions of DBG2 subtypes
  ACPI: genaralize iterating over subtables in ACPI_PROBE_TABLE()
  ACPI: parse DBG2 table
  ACPI: serial: implement earlycon on ACPI DBG2 port
  ACPI: enable ACPI_DBG2_TABLE on ARM64
  serial: pl011: add ACPI DBG2 serial port

Leif Lindholm (2):
  arm64: move acpi/dt decision earlier in boot process
  of/serial: move earlycon early_param handling to serial

 Documentation/kernel-parameters.txt  |   3 +
 arch/arm64/Kconfig                   |   1 +
 arch/arm64/kernel/acpi.c             |  64 ++++++++++-----------
 drivers/acpi/Kconfig                 |   3 +
 drivers/acpi/Makefile                |   1 +
 drivers/acpi/dbg2.c                  |  85 ++++++++++++++++++++++++++++
 drivers/acpi/scan.c                  |  44 ++++++++++-----
 drivers/clocksource/arm_arch_timer.c |   3 +-
 drivers/irqchip/irq-gic.c            |   4 +-
 drivers/of/fdt.c                     |  11 +---
 drivers/tty/serial/amba-pl011.c      |   3 +
 drivers/tty/serial/earlycon.c        |  61 ++++++++++++++++++++
 include/acpi/actbl2.h                |   5 ++
 include/asm-generic/vmlinux.lds.h    |   1 +
 include/linux/acpi.h                 | 104 ++++++++++++++++++++++++-----------
 include/linux/acpi_dbg2.h            |  68 +++++++++++++++++++++++
 include/linux/clocksource.h          |   2 +-
 include/linux/irqchip.h              |   5 +-
 include/linux/of_fdt.h               |   2 +
 19 files changed, 375 insertions(+), 95 deletions(-)
 create mode 100644 drivers/acpi/dbg2.c
 create mode 100644 include/linux/acpi_dbg2.h

-- 
2.7.1



From aleksey.makarov at linaro.org  Wed Feb 24 09:10:11 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Wed, 24 Feb 2016 20:10:11 +0300
Subject: [PATCH v2 2/8] of/serial: move earlycon early_param handling to serial
In-Reply-To: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456333819-13482-3-git-send-email-aleksey.makarov@linaro.org>

From: Leif Lindholm <leif.lindholm at linaro.org>

We have multiple "earlycon" early_param handlers - merge the DT one into
the main earlycon one. This means the earlycon early_param handler does
not just return success if no options are specified.

Signed-off-by: Leif Lindholm <leif.lindholm at linaro.org>
Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 drivers/of/fdt.c              | 11 +----------
 drivers/tty/serial/earlycon.c |  3 ++-
 include/linux/of_fdt.h        |  2 ++
 3 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 3349d2a..0547256 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -805,7 +805,7 @@ static inline void early_init_dt_check_for_initrd(unsigned long node)
 
 #ifdef CONFIG_SERIAL_EARLYCON
 
-static int __init early_init_dt_scan_chosen_serial(void)
+int __init early_init_dt_scan_chosen_serial(void)
 {
 	int offset;
 	const char *p, *q, *options = NULL;
@@ -849,15 +849,6 @@ static int __init early_init_dt_scan_chosen_serial(void)
 	}
 	return -ENODEV;
 }
-
-static int __init setup_of_earlycon(char *buf)
-{
-	if (buf)
-		return 0;
-
-	return early_init_dt_scan_chosen_serial();
-}
-early_param("earlycon", setup_of_earlycon);
 #endif
 
 /**
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 067783f..d217366 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -17,6 +17,7 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/io.h>
+#include <linux/of_fdt.h>
 #include <linux/serial_core.h>
 #include <linux/sizes.h>
 #include <linux/of.h>
@@ -209,7 +210,7 @@ static int __init param_setup_earlycon(char *buf)
 	 * don't generate a warning from parse_early_params() in that case
 	 */
 	if (!buf || !buf[0])
-		return 0;
+		return early_init_dt_scan_chosen_serial();
 
 	err = setup_earlycon(buf);
 	if (err == -ENOENT || err == -EALREADY)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 2fbe868..56b2a43 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -63,6 +63,7 @@ extern int early_init_dt_scan_chosen(unsigned long node, const char *uname,
 				     int depth, void *data);
 extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
 				     int depth, void *data);
+extern int early_init_dt_scan_chosen_serial(void);
 extern void early_init_fdt_scan_reserved_mem(void);
 extern void early_init_fdt_reserve_self(void);
 extern void early_init_dt_add_memory_arch(u64 base, u64 size);
@@ -91,6 +92,7 @@ extern void early_get_first_memblock_info(void *, phys_addr_t *);
 extern u64 of_flat_dt_translate_address(unsigned long node);
 extern void of_fdt_limit_memory(int limit);
 #else /* CONFIG_OF_FLATTREE */
+static inline int early_init_dt_scan_chosen_serial(void) { return -ENODEV; }
 static inline void early_init_fdt_scan_reserved_mem(void) {}
 static inline void early_init_fdt_reserve_self(void) {}
 static inline const char *of_flat_dt_get_machine_name(void) { return NULL; }
-- 
2.7.1



From aleksey.makarov at linaro.org  Wed Feb 24 09:10:12 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Wed, 24 Feb 2016 20:10:12 +0300
Subject: [PATCH v2 3/8] ACPI: add definitions of DBG2 subtypes
In-Reply-To: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456333819-13482-4-git-send-email-aleksey.makarov@linaro.org>

The recent version of Microsoft Debug Port Table 2 (DBG2) [1]
specifies additional serial debug port subtypes.  These constants
are also referred by Serial Port Console Redirection Table (SPCR) [2]

Add these constants.

[1] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
[2] https://msdn.microsoft.com/en-us/library/windows/hardware/dn639132(v=vs.85).aspx

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 include/acpi/actbl2.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index a4ef625..652f747 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -371,6 +371,11 @@ struct acpi_dbg2_device {
 
 #define ACPI_DBG2_16550_COMPATIBLE  0x0000
 #define ACPI_DBG2_16550_SUBSET      0x0001
+#define ACPI_DBG2_ARM_PL011         0x0003
+#define ACPI_DBG2_ARM_SBSA_32BIT    0x000D
+#define ACPI_DBG2_ARM_SBSA_GENERIC  0x000E
+#define ACPI_DBG2_ARM_DCC           0x000F
+#define ACPI_DBG2_BCM2835           0x0010
 
 #define ACPI_DBG2_1394_STANDARD     0x0000
 
-- 
2.7.1



From aleksey.makarov at linaro.org  Wed Feb 24 09:10:13 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Wed, 24 Feb 2016 20:10:13 +0300
Subject: [PATCH v2 4/8] ACPI: genaralize iterating over subtables in
 ACPI_PROBE_TABLE()
In-Reply-To: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456333819-13482-5-git-send-email-aleksey.makarov@linaro.org>

Refactor ACPI_PROBE_TABLE() so that it is possible to iterate
over subtables that do not have acpi_subtype header (for example
over subtables of DBG2 table)

To do so:

- Add void * data pointer argument for callback.  It will allow to
  parse the table and iterate over subtables calling the subtable
  callbacks that are provided via this data pointer.
- Save only ACPI table id, callback and callback data in the linker
  tables.  This makes tables more terse and simplifies the semantics
  of the fields of it's elements.
  The additional data that required for subtable parsing are saved
  in static namespace without increasing the size of linker tables.
- Introduce two macros with clear meaning of arguments, instead one.
  The old ACPI_DECLARE_PROBE_ENTRY() macros has arguments that have
  different meaning if the entry is for table or for subtable.  The
  arguments of the new macroses ACPI_DECLARE_PROBE_ENTRY() and
  ACPI_DECLARE_PROBE_SUBTYPE_ENTRY() have unambiguous meaning.
- Document arguments of those macroses instead of the fields of linker
  table data.
- Fix the issue that prevents using this macros for parsing subtables
  other than MADT.  In the original code, MADT-specific function
  was used to iterate over subtables, while the name was common.
  Introduce a new parameter to macors that specifies the size of
  the table to do it in common way.
- Don't expose the internals of the tables to the drivers passing
  a pointer to struct acpi_probe_entry to the subtable callback validator.
  Instead, pass the sideband data specified by the driver.
- Fix the driver's callback signatures: a. Add an unused pointer to void
  for table matchers (currently only clocksource callback) b. Change
  the type of sideband data to kernel_ulong_t.

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 drivers/acpi/scan.c                  |  44 ++++++++++-----
 drivers/clocksource/arm_arch_timer.c |   3 +-
 drivers/irqchip/irq-gic.c            |   4 +-
 include/linux/acpi.h                 | 104 ++++++++++++++++++++++++-----------
 include/linux/clocksource.h          |   2 +-
 include/linux/irqchip.h              |   5 +-
 6 files changed, 109 insertions(+), 53 deletions(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..09b5f63 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1969,16 +1969,38 @@ static struct acpi_probe_entry *ape;
 static int acpi_probe_count;
 static DEFINE_SPINLOCK(acpi_probe_lock);
 
-static int __init acpi_match_madt(struct acpi_subtable_header *header,
-				  const unsigned long end)
+static int __init acpi_match_and_setup(struct acpi_subtable_header *header,
+				       const unsigned long end)
 {
-	if (!ape->subtable_valid || ape->subtable_valid(header, ape))
-		if (!ape->probe_subtbl(header, end))
+	const struct acpi_probe_subtype_data *data = ape->data;
+
+	if (data->valid(header, data->data))
+		if (!data->setup(header, end))
 			acpi_probe_count++;
 
 	return 0;
 }
 
+int __init acpi_probe_subtype_setup(struct acpi_table_header *table,
+				    const void *data)
+{
+	const struct acpi_probe_subtype_data *data_subtype = data;
+
+	return acpi_parse_entries(ape->id, data_subtype->size,
+				  acpi_match_and_setup, table,
+				  data_subtype->subtype, 0);
+}
+
+static int __init acpi_probe_table_handler(struct acpi_table_header *table)
+{
+	int err = ape->setup(table, ape->data);
+
+	if (ape->setup != acpi_probe_subtype_setup && err >= 0)
+		acpi_probe_count++;
+
+	return err;
+}
+
 int __init __acpi_probe_device_table(struct acpi_probe_entry *ap_head, int nr)
 {
 	int count = 0;
@@ -1988,16 +2010,10 @@ int __init __acpi_probe_device_table(struct acpi_probe_entry *ap_head, int nr)
 
 	spin_lock(&acpi_probe_lock);
 	for (ape = ap_head; nr; ape++, nr--) {
-		if (ACPI_COMPARE_NAME(ACPI_SIG_MADT, ape->id)) {
-			acpi_probe_count = 0;
-			acpi_table_parse_madt(ape->type, acpi_match_madt, 0);
-			count += acpi_probe_count;
-		} else {
-			int res;
-			res = acpi_table_parse(ape->id, ape->probe_table);
-			if (!res)
-				count++;
-		}
+		acpi_probe_count = 0;
+		if (acpi_table_parse(ape->id, acpi_probe_table_handler) < 0)
+			continue;
+		count += acpi_probe_count;
 	}
 	spin_unlock(&acpi_probe_lock);
 
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index f492ced..c0df7cb 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -868,7 +868,8 @@ static int __init map_generic_timer_interrupt(u32 interrupt, u32 flags)
 }
 
 /* Initialize per-processor generic timer */
-static int __init arch_timer_acpi_init(struct acpi_table_header *table)
+static int __init arch_timer_acpi_init(struct acpi_table_header *table,
+				       const void *data)
 {
 	struct acpi_table_gtdt *gtdt;
 
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 282344b..13d8323 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -1287,12 +1287,12 @@ static bool __init acpi_gic_redist_is_present(void)
 }
 
 static bool __init gic_validate_dist(struct acpi_subtable_header *header,
-				     struct acpi_probe_entry *ape)
+				     kernel_ulong_t driver_data)
 {
 	struct acpi_madt_generic_distributor *dist;
 	dist = (struct acpi_madt_generic_distributor *)header;
 
-	return (dist->version == ape->driver_data &&
+	return (dist->version == driver_data &&
 		(dist->version != ACPI_MADT_GIC_VERSION_NONE ||
 		 !acpi_gic_redist_is_present()));
 }
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 06ed7e5..9636c32 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -879,47 +879,76 @@ int acpi_dev_prop_read(struct acpi_device *adev, const char *propname,
 struct fwnode_handle *acpi_get_next_subnode(struct device *dev,
 					    struct fwnode_handle *subnode);
 
-struct acpi_probe_entry;
 typedef bool (*acpi_probe_entry_validate_subtbl)(struct acpi_subtable_header *,
-						 struct acpi_probe_entry *);
+						 kernel_ulong_t);
+
+typedef int (*acpi_probe_entry_setup)(struct acpi_table_header *, const void *);
 
 #define ACPI_TABLE_ID_LEN	5
 
-/**
- * struct acpi_probe_entry - boot-time probing entry
- * @id:			ACPI table name
- * @type:		Optional subtable type to match
- *			(if @id contains subtables)
- * @subtable_valid:	Optional callback to check the validity of
- *			the subtable
- * @probe_table:	Callback to the driver being probed when table
- *			match is successful
- * @probe_subtbl:	Callback to the driver being probed when table and
- *			subtable match (and optional callback is successful)
- * @driver_data:	Sideband data provided back to the driver
- */
 struct acpi_probe_entry {
 	__u8 id[ACPI_TABLE_ID_LEN];
-	__u8 type;
-	acpi_probe_entry_validate_subtbl subtable_valid;
-	union {
-		acpi_tbl_table_handler probe_table;
-		acpi_tbl_entry_handler probe_subtbl;
-	};
-	kernel_ulong_t driver_data;
+	acpi_probe_entry_setup setup;
+	const void *data;
 };
 
-#define ACPI_DECLARE_PROBE_ENTRY(table, name, table_id, subtable, valid, data, fn)	\
+/**
+ * ACPI_DECLARE_PROBE_ENTRY() - declare boot-time probing entry
+ * @table:		Name of subsystem to match
+ * @name:               Identifier to compose name of table data
+ * @table_id:		ACPI table name
+ * @setup_fn:		Callback to the driver being probed when table
+ *			matches (of type acpi_probe_entry_setup)
+ * @data_ptr:		Sideband data provided back to the driver
+ */
+#define ACPI_DECLARE_PROBE_ENTRY(table, name, table_id, setup_fn, data_ptr) \
 	static const struct acpi_probe_entry __acpi_probe_##name	\
 		__used __section(__##table##_acpi_probe_table)		\
 		 = {							\
 			.id = table_id,					\
-			.type = subtable,				\
-			.subtable_valid = valid,			\
-			.probe_table = (acpi_tbl_table_handler)fn,	\
-			.driver_data = data, 				\
+			.setup = setup_fn,				\
+			.data = data_ptr,				\
 		   }
 
+struct acpi_probe_subtype_data {
+	u8 subtype;
+	unsigned long size;
+	acpi_probe_entry_validate_subtbl valid;
+	acpi_tbl_entry_handler setup;
+	kernel_ulong_t data;
+};
+
+int acpi_probe_subtype_setup(struct acpi_table_header *table, const void *data);
+
+/**
+ * ACPI_DECLARE_PROBE_SUBTYPE_ENTRY() - declare boot-time probing entry that
+ *				      matches subtables
+ * @table:		Name of subsystem to match
+ * @name:               Identifier to compose name of table data
+ * @table_id:		ACPI table name
+ * @table_size:		Size of the table (without subtables) of type table_id
+ * @subtable:		Subtable type to match
+ * @valid_fn:		Callback to check the validity of the subtable
+ *			(of type acpi_probe_entry_validate_subtbl)
+ * @data_int:		Sideband data provided back to the driver
+ *			(of type kernel_ulong_t)
+ * @setup_fn:		Callback to the driver being probed when table and
+ *			subtable match and valid_fn callback is successful
+ *			(of type acpi_tbl_entry_handler)
+ */
+#define ACPI_DECLARE_PROBE_SUBTYPE_ENTRY(table, name, table_id, table_size, \
+				subtable, valid_fn, data_int, setup_fn)     \
+	static const struct acpi_probe_subtype_data			    \
+	__acpi_probe_subtype_##name __used = {				    \
+			.subtype = subtable,				    \
+			.size = table_size,				    \
+			.valid = valid_fn,				    \
+			.setup = setup_fn,				    \
+			.data = data_int,				    \
+		   };							    \
+	ACPI_DECLARE_PROBE_ENTRY(table, name, table_id,			    \
+		acpi_probe_subtype_setup, &__acpi_probe_subtype_##name)
+
 #define ACPI_PROBE_TABLE(name)		__##name##_acpi_probe_table
 #define ACPI_PROBE_TABLE_END(name)	__##name##_acpi_probe_table_end
 
@@ -992,14 +1021,23 @@ static inline struct fwnode_handle *acpi_get_next_subnode(struct device *dev,
 	return NULL;
 }
 
-#define ACPI_DECLARE_PROBE_ENTRY(table, name, table_id, subtable, validate, data, fn) \
+#define ACPI_DECLARE_PROBE_ENTRY(table, name, table_id, match, data)	\
 	static const void * __acpi_table_##name[]			\
 		__attribute__((unused))					\
-		 = { (void *) table_id,					\
-		     (void *) subtable,					\
-		     (void *) valid,					\
-		     (void *) fn,					\
-		     (void *) data }
+		 = { (void *)table_id,					\
+		     (void *)match,					\
+		     (void *)data }
+
+#define ACPI_DECLARE_PROBE_SUBTYPE_ENTRY(table, name, table_id, table_size, \
+				subtable, valid_fn, data_int, setup_fn)	    \
+	static const void *__acpi_table_##name[]			\
+		__attribute__((unused))					\
+		 = { (void *)table_id,					\
+		     (void *)table_size,				\
+		     (void *)subtable,					\
+		     (void *)valid_fn,					\
+		     (void *)data_int,					\
+		     (void *)setup_fn }
 
 #define acpi_probe_device_table(t)	({ int __r = 0; __r;})
 #endif
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 6013021..2bb5d51 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -259,6 +259,6 @@ static inline void clocksource_probe(void) {}
 #endif
 
 #define CLOCKSOURCE_ACPI_DECLARE(name, table_id, fn)		\
-	ACPI_DECLARE_PROBE_ENTRY(clksrc, name, table_id, 0, NULL, 0, fn)
+	ACPI_DECLARE_PROBE_ENTRY(clksrc, name, table_id, fn, NULL)
 
 #endif /* _LINUX_CLOCKSOURCE_H */
diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h
index 89c34b2..cc4c455 100644
--- a/include/linux/irqchip.h
+++ b/include/linux/irqchip.h
@@ -39,8 +39,9 @@
  * @fn: initialization function
  */
 #define IRQCHIP_ACPI_DECLARE(name, subtable, validate, data, fn)	\
-	ACPI_DECLARE_PROBE_ENTRY(irqchip, name, ACPI_SIG_MADT, 		\
-				 subtable, validate, data, fn)
+	ACPI_DECLARE_PROBE_SUBTYPE_ENTRY(irqchip, name, ACPI_SIG_MADT,	\
+					 sizeof(struct acpi_table_madt),\
+					 subtable, validate, data, fn)
 
 #ifdef CONFIG_IRQCHIP
 void irqchip_init(void);
-- 
2.7.1



From aleksey.makarov at linaro.org  Wed Feb 24 09:10:15 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Wed, 24 Feb 2016 20:10:15 +0300
Subject: [PATCH v2 6/8] ACPI: serial: implement earlycon on ACPI DBG2 port
In-Reply-To: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456333819-13482-7-git-send-email-aleksey.makarov@linaro.org>

Add ACPI_DBG2_EARLYCON_DECLARE() macros that declares
an earlycon on the serial port specified in the DBG2 ACPI table.

Pass the string "earlycon=acpi_dbg2" to the kernel to activate it.

Callbacks for EARLYCON_DECLARE() and OF_EARLYCON_DECLARE()
can also be used for this macros.

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 Documentation/kernel-parameters.txt |  3 ++
 drivers/tty/serial/earlycon.c       | 60 +++++++++++++++++++++++++++++++++++++
 include/linux/acpi_dbg2.h           | 20 +++++++++++++
 3 files changed, 83 insertions(+)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 1fee970..22600e0 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1069,6 +1069,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			A valid base address must be provided, and the serial
 			port must already be setup and configured.
 
+		acpi_dbg2
+			Use serial port specified by the DBG2 ACPI table.
+
 	earlyprintk=	[X86,SH,BLACKFIN,ARM,M68k]
 			earlyprintk=vga
 			earlyprintk=efi
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index d217366..9ba3a04 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -22,6 +22,7 @@
 #include <linux/sizes.h>
 #include <linux/of.h>
 #include <linux/of_fdt.h>
+#include <linux/acpi.h>
 
 #ifdef CONFIG_FIX_EARLYCON_MEM
 #include <asm/fixmap.h>
@@ -200,6 +201,8 @@ int __init setup_earlycon(char *buf)
 	return -ENOENT;
 }
 
+static bool setup_dbg2_earlycon;
+
 /* early_param wrapper for setup_earlycon() */
 static int __init param_setup_earlycon(char *buf)
 {
@@ -212,6 +215,11 @@ static int __init param_setup_earlycon(char *buf)
 	if (!buf || !buf[0])
 		return early_init_dt_scan_chosen_serial();
 
+	if (!strcmp(buf, "acpi_dbg2")) {
+		setup_dbg2_earlycon = true;
+		return 0;
+	}
+
 	err = setup_earlycon(buf);
 	if (err == -ENOENT || err == -EALREADY)
 		return 0;
@@ -286,3 +294,55 @@ int __init of_setup_earlycon(const struct earlycon_id *match,
 }
 
 #endif /* CONFIG_OF_EARLY_FLATTREE */
+
+#ifdef CONFIG_ACPI_DBG2_TABLE
+
+int __init acpi_setup_earlycon(struct acpi_dbg2_device *device, void *d)
+{
+	int err;
+	struct uart_port *port = &early_console_dev.port;
+	int (*setup)(struct earlycon_device *, const char *) = d;
+	struct acpi_generic_address *reg;
+
+	if (!setup_dbg2_earlycon)
+		return -ENODEV;
+
+	if (device->register_count < 1)
+		return -ENODEV;
+
+	if (device->base_address_offset >= device->length)
+		return -EINVAL;
+
+	reg = (void *)device + device->base_address_offset;
+
+	if (reg->space_id != ACPI_ADR_SPACE_SYSTEM_MEMORY &&
+	    reg->space_id != ACPI_ADR_SPACE_SYSTEM_IO)
+		return -EINVAL;
+
+	spin_lock_init(&port->lock);
+	port->uartclk = BASE_BAUD * 16;
+
+	if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
+		if (device->port_type == ACPI_DBG2_ARM_SBSA_32BIT)
+			port->iotype = UPIO_MEM32;
+		else
+			port->iotype = UPIO_MEM;
+		port->mapbase = reg->address;
+		port->membase = earlycon_map(reg->address, SZ_4K);
+	} else {
+		port->iotype = UPIO_PORT;
+		port->iobase = reg->address;
+	}
+
+	early_console_dev.con->data = &early_console_dev;
+	err = setup(&early_console_dev, NULL);
+	if (err < 0)
+		return err;
+	if (!early_console_dev.con->write)
+		return -ENODEV;
+
+	register_console(early_console_dev.con);
+	return 0;
+}
+
+#endif /* CONFIG_ACPI_DBG2_TABLE */
diff --git a/include/linux/acpi_dbg2.h b/include/linux/acpi_dbg2.h
index 125ae7e..b653752 100644
--- a/include/linux/acpi_dbg2.h
+++ b/include/linux/acpi_dbg2.h
@@ -37,12 +37,32 @@ int acpi_dbg2_setup(struct acpi_table_header *header, const void *data);
 	ACPI_DECLARE_PROBE_ENTRY(dbg2, name, ACPI_SIG_DBG2,		\
 				 acpi_dbg2_setup, &__acpi_dbg2_data_##name)
 
+int acpi_setup_earlycon(struct acpi_dbg2_device *device, void *d);
+
+/**
+ * ACPI_DBG2_EARLYCON_DECLARE() - Define handler for ACPI GDB2 serial port
+ * @name:		Identifier to compose name of table data
+ * @subtype:		Subtype of the port
+ * @console_setup:	Function to be called to setup the port
+ *
+ * Type of the console_setup() callback is
+ * int (*setup)(struct earlycon_device *, const char *)
+ * It's the type of callback of of_setup_earlycon().
+ */
+#define ACPI_DBG2_EARLYCON_DECLARE(name, subtype, console_setup)	\
+	ACPI_DBG2_DECLARE(name, ACPI_DBG2_SERIAL_PORT, subtype,		\
+			  acpi_setup_earlycon, console_setup)
+
 #else
 
 #define ACPI_DBG2_DECLARE(name, type, subtype, setup_fn, data_ptr)	\
 	static const void *__acpi_dbg_data_##name[]			\
 		__used __initdata = { (void *)setup_fn,	(void *)data_ptr }
 
+#define ACPI_DBG2_EARLYCON_DECLARE(name, subtype, console_setup)	\
+	static const void *__acpi_dbg_data_serial_##name[]		\
+		__used __initdata = { (void *)console_setup }
+
 #endif
 
 #endif
-- 
2.7.1



From aleksey.makarov at linaro.org  Wed Feb 24 09:10:16 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Wed, 24 Feb 2016 20:10:16 +0300
Subject: [PATCH v2 7/8] ACPI: enable ACPI_DBG2_TABLE on ARM64
In-Reply-To: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456333819-13482-8-git-send-email-aleksey.makarov@linaro.org>

SBBR mentions DBG2 as a mandatory ACPI table.
So enable it for ARM64

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 arch/arm64/Kconfig       | 1 +
 arch/arm64/kernel/acpi.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 2ee5731..4ad33f8 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -3,6 +3,7 @@ config ARM64
 	select ACPI_CCA_REQUIRED if ACPI
 	select ACPI_GENERIC_GSI if ACPI
 	select ACPI_REDUCED_HARDWARE_ONLY if ACPI
+	select ACPI_DBG2_TABLE if ACPI
 	select ARCH_HAS_DEVMEM_IS_ALLOWED
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_ELF_RANDOMIZE
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 3faa323..bb93022 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -207,6 +207,8 @@ void __init acpi_boot_table_init(void)
 		if (!param_acpi_force)
 			disable_acpi();
 	}
+
+	acpi_probe_device_table(dbg2);
 }
 
 #ifdef CONFIG_ACPI_APEI
-- 
2.7.1



From aleksey.makarov at linaro.org  Wed Feb 24 09:10:14 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Wed, 24 Feb 2016 20:10:14 +0300
Subject: [PATCH v2 5/8] ACPI: parse DBG2 table
In-Reply-To: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456333819-13482-6-git-send-email-aleksey.makarov@linaro.org>

'ARM Server Base Boot Requiremets' [1] mentions DBG2 (Microsoft Debug
Port Table 2) [2] as a mandatory ACPI table that specifies debug ports.

- Implement macros

	ACPI_DBG2_DECLARE(name, type, subtype, setup_fn, data_ptr)

  that defines a handler for the port of given type and subtype.

- For each declared port that is also described in the ACPI DBG2 table
  call the provided callback.

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
[2] http://go.microsoft.com/fwlink/p/?LinkId=234837

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 drivers/acpi/Kconfig              |  3 ++
 drivers/acpi/Makefile             |  1 +
 drivers/acpi/dbg2.c               | 85 +++++++++++++++++++++++++++++++++++++++
 include/asm-generic/vmlinux.lds.h |  1 +
 include/linux/acpi_dbg2.h         | 48 ++++++++++++++++++++++
 5 files changed, 138 insertions(+)
 create mode 100644 drivers/acpi/dbg2.c
 create mode 100644 include/linux/acpi_dbg2.h

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 65fb483..660666e 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -57,6 +57,9 @@ config ACPI_SYSTEM_POWER_STATES_SUPPORT
 config ACPI_CCA_REQUIRED
 	bool
 
+config ACPI_DBG2_TABLE
+	bool
+
 config ACPI_DEBUGGER
 	bool "AML debugger interface"
 	select ACPI_DEBUG
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 7395928..3b5f1ea 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -83,6 +83,7 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
 obj-$(CONFIG_ACPI_BGRT)		+= bgrt.o
 obj-$(CONFIG_ACPI_CPPC_LIB)	+= cppc_acpi.o
 obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
+obj-$(CONFIG_ACPI_DBG2_TABLE)	+= dbg2.o
 
 # processor has its own "processor." module_param namespace
 processor-y			:= processor_driver.o
diff --git a/drivers/acpi/dbg2.c b/drivers/acpi/dbg2.c
new file mode 100644
index 0000000..8a79117
--- /dev/null
+++ b/drivers/acpi/dbg2.c
@@ -0,0 +1,85 @@
+/*
+ * Copyright (c) 2012, Intel Corporation
+ * Copyright (c) 2015, 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#define pr_fmt(fmt) "ACPI: DBG2: " fmt
+
+#include <linux/acpi_dbg2.h>
+#include <linux/acpi.h>
+#include <linux/kernel.h>
+
+static const char * __init type2string(u16 type)
+{
+	switch (type) {
+	case ACPI_DBG2_SERIAL_PORT:
+		return "SERIAL";
+	case ACPI_DBG2_1394_PORT:
+		return "1394";
+	case ACPI_DBG2_USB_PORT:
+		return "USB";
+	case ACPI_DBG2_NET_PORT:
+		return "NET";
+	default:
+		return "?";
+	}
+}
+
+static const char * __init subtype2string(u16 subtype)
+{
+	switch (subtype) {
+	case ACPI_DBG2_16550_COMPATIBLE:
+		return "16550_COMPATIBLE";
+	case ACPI_DBG2_16550_SUBSET:
+		return "16550_SUBSET";
+	case ACPI_DBG2_ARM_PL011:
+		return "ARM_PL011";
+	case ACPI_DBG2_ARM_SBSA_32BIT:
+		return "ARM_SBSA_32BIT";
+	case ACPI_DBG2_ARM_SBSA_GENERIC:
+		return "ARM_SBSA_GENERIC";
+	case ACPI_DBG2_ARM_DCC:
+		return "ARM_DCC";
+	case ACPI_DBG2_BCM2835:
+		return "BCM2835";
+	default:
+		return "?";
+	}
+}
+
+int __init acpi_dbg2_setup(struct acpi_table_header *table, const void *data)
+{
+	struct acpi_table_dbg2 *dbg2 = (struct acpi_table_dbg2 *)table;
+	struct acpi_dbg2_data *dbg2_data = (struct acpi_dbg2_data *)data;
+	struct acpi_dbg2_device *dbg2_device, *dbg2_end;
+	int i;
+
+	dbg2_device = ACPI_ADD_PTR(struct acpi_dbg2_device, dbg2,
+				   dbg2->info_offset);
+	dbg2_end = ACPI_ADD_PTR(struct acpi_dbg2_device, dbg2, table->length);
+
+	for (i = 0; i < dbg2->info_count; i++) {
+		if (dbg2_device + 1 > dbg2_end) {
+			pr_err("device pointer overflows, bad table\n");
+			return 0;
+		}
+
+		if (dbg2_device->port_type == dbg2_data->port_type &&
+		    dbg2_device->port_subtype == dbg2_data->port_subtype) {
+			pr_info("debug port type: %s subtype: %s\n",
+				type2string(dbg2_device->port_type),
+				subtype2string(dbg2_device->port_subtype));
+			dbg2_data->setup(dbg2_device, dbg2_data->data);
+		}
+
+		dbg2_device = ACPI_ADD_PTR(struct acpi_dbg2_device, dbg2_device,
+					   dbg2_device->length);
+	}
+
+	return 0;
+}
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index e9a81a6..ab6a727 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -525,6 +525,7 @@
 	IRQCHIP_OF_MATCH_TABLE()					\
 	ACPI_PROBE_TABLE(irqchip)					\
 	ACPI_PROBE_TABLE(clksrc)					\
+	ACPI_PROBE_TABLE(dbg2)						\
 	EARLYCON_TABLE()
 
 #define INIT_TEXT							\
diff --git a/include/linux/acpi_dbg2.h b/include/linux/acpi_dbg2.h
new file mode 100644
index 0000000..125ae7e
--- /dev/null
+++ b/include/linux/acpi_dbg2.h
@@ -0,0 +1,48 @@
+#ifndef _ACPI_DBG2_H_
+#define _ACPI_DBG2_H_
+
+#ifdef CONFIG_ACPI_DBG2_TABLE
+
+#include <linux/kernel.h>
+
+struct acpi_dbg2_device;
+struct acpi_table_header;
+
+struct acpi_dbg2_data {
+	u16 port_type;
+	u16 port_subtype;
+	int (*setup)(struct acpi_dbg2_device *, void *);
+	void *data;
+};
+
+int acpi_dbg2_setup(struct acpi_table_header *header, const void *data);
+
+/**
+ * ACPI_DBG2_DECLARE() - Define handler for ACPI DBG2 port
+ * @name:	Identifier to compose name of table data
+ * @type:	Type of the port
+ * @subtype:	Subtype of the port
+ * @setup_fn:	Function to be called to setup the port
+ *		(of type int (*)(struct acpi_dbg2_device *, void *);)
+ * @data_ptr:	Sideband data provided back to the driver
+ */
+#define ACPI_DBG2_DECLARE(name, type, subtype, setup_fn, data_ptr)	\
+	static const struct acpi_dbg2_data				\
+		__acpi_dbg2_data_##name __used = {			\
+			.port_type = type,				\
+			.port_subtype = subtype,			\
+			.setup = setup_fn,				\
+			.data = data_ptr,				\
+		   };							\
+	ACPI_DECLARE_PROBE_ENTRY(dbg2, name, ACPI_SIG_DBG2,		\
+				 acpi_dbg2_setup, &__acpi_dbg2_data_##name)
+
+#else
+
+#define ACPI_DBG2_DECLARE(name, type, subtype, setup_fn, data_ptr)	\
+	static const void *__acpi_dbg_data_##name[]			\
+		__used __initdata = { (void *)setup_fn,	(void *)data_ptr }
+
+#endif
+
+#endif
-- 
2.7.1



From swarren at wwwdotorg.org  Wed Feb 24 09:11:09 2016
From: swarren at wwwdotorg.org (Stephen Warren)
Date: Wed, 24 Feb 2016 10:11:09 -0700
Subject: [PATCH 2/5] ARM: bcm2835: Replace alt0/i2s_alt[02] with standard
 groups.
In-Reply-To: <1456266111-2508-3-git-send-email-eric@anholt.net>
References: <1456266111-2508-1-git-send-email-eric@anholt.net>
 <1456266111-2508-3-git-send-email-eric@anholt.net>
Message-ID: <56CDE42D.4010907@wwwdotorg.org>

On 02/23/2016 03:21 PM, Eric Anholt wrote:
> Since all of these pins were documented, we can use their names to
> explain what's going on.

I only received patch 2/5, and e.g. the spinics.net email archive seems 
to be in the same boat.


From aleksey.makarov at linaro.org  Wed Feb 24 09:10:17 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Wed, 24 Feb 2016 20:10:17 +0300
Subject: [PATCH v2 8/8] serial: pl011: add ACPI DBG2 serial port
In-Reply-To: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
References: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <1456333819-13482-9-git-send-email-aleksey.makarov@linaro.org>

Add a handler for ACPI DBG2 serial port of type ACPI_DBG2_ARM_PL011
that sets up an earlycon on it.

Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
---
 drivers/tty/serial/amba-pl011.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 500232a..d38da86 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -59,6 +59,7 @@
 #include <linux/sizes.h>
 #include <linux/io.h>
 #include <linux/acpi.h>
+#include <linux/acpi_dbg2.h>
 
 #include "amba-pl011.h"
 
@@ -2327,6 +2328,8 @@ static int __init pl011_early_console_setup(struct earlycon_device *device,
 	return 0;
 }
 OF_EARLYCON_DECLARE(pl011, "arm,pl011", pl011_early_console_setup);
+ACPI_DBG2_EARLYCON_DECLARE(pl011, ACPI_DBG2_ARM_PL011,
+			   pl011_early_console_setup);
 
 #else
 #define AMBA_CONSOLE	NULL
-- 
2.7.1



From will.deacon at arm.com  Wed Feb 24 09:12:18 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Feb 2016 17:12:18 +0000
Subject: [PATCH 00/13] arm-cci: PMU driver updates for 4.6
In-Reply-To: <20160224165814.GA10126@localhost>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
 <20160223114003.GF3966@arm.com> <56CC64E7.3040407@arm.com>
 <20160224165814.GA10126@localhost>
Message-ID: <20160224171218.GC12471@arm.com>

On Wed, Feb 24, 2016 at 08:58:14AM -0800, Olof Johansson wrote:
> On Tue, Feb 23, 2016 at 01:55:51PM +0000, Suzuki K. Poulose wrote:
> > On 23/02/16 11:40, Will Deacon wrote:
> > >On Tue, Feb 23, 2016 at 10:49:42AM +0000, Suzuki K Poulose wrote:
> > >>Here are some fixes and updates for arm-cci pmu driver targeting v4.6,
> > >>applies on top of v4.5-rc5.
> > >>
> > >>Highlights include :
> > >>  - Support for CoreLink CCI-550 PMU
> > >>  - Reliable writes to PMU Counter registers for CCI-500/550.
> > >>
> > >>All the patches have been Acked. Please let me know how this
> > >>can be merged.
> > 
> > >>
> > >>  Documentation/devicetree/bindings/arm/cci.txt |    2 +
> > >>  drivers/bus/Kconfig                           |   10 +-
> > >>  drivers/bus/arm-cci.c                         |  612 +++++++++++++++++--------
> > >>  3 files changed, 427 insertions(+), 197 deletions(-)
> > >
> > >How do you plan to merge this? I can take it all onto a branch for
> > >arm-soc, or I can include it on my perf/updates branch, or ...?
> > 
> > Arnd, Olof,
> > 
> > What do you think would be the best route ?
> 
> Traditionally we've been picking these up in arm-soc in our drivers branch.
> 
> Will, unless you want them in your tree for some reason that's what I'll do
> here as well.

Just that I already have some CPU PMU patches that I planned to send, so
I could bundle these in with those if necessary. I have no preference
either way though, as long as they get queued someplace.

At some point, those drivers should be largely moved from drivers/bus/
to drivers/perf/, but that's a separate issue.

Will


From nicolas.ferre at atmel.com  Wed Feb 24 09:13:08 2016
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Wed, 24 Feb 2016 18:13:08 +0100
Subject: [PATCH v2] clocksource: atmel-pit: register as a sched_clock
In-Reply-To: <CAGkQfmPpyhU025nt+tcnsjWK3V+K3_7oiXxeqa7mPuHT08sLig@mail.gmail.com>
References: <1456329882-20709-1-git-send-email-romain.izard.pro@gmail.com>
 <20160224162046.GA28743@finsecur.com>
 <CAGkQfmPpyhU025nt+tcnsjWK3V+K3_7oiXxeqa7mPuHT08sLig@mail.gmail.com>
Message-ID: <56CDE4A4.7080508@atmel.com>

Le 24/02/2016 17:44, Romain Izard a ?crit :
> 2016-02-24 17:20 GMT+01:00 Sylvain Rochet <sylvain.rochet at finsecur.com>:
>> Hi,
>>
>> On Wed, Feb 24, 2016 at 05:04:42PM +0100, Romain Izard wrote:
>>> Register the counter of the Periodic Interval Timer as a possible
>>> source for sched_clock. Keep the timer running even if the related
>>> clockevent is disabled.
>>>
>>> This provides a better precision than the jiffies-based default. The
>>> TCB clocksource does not work, as it is registered too late in the
>>> initialization sequence.
>>
>> I have mixed feelings about that, but this is probably just a
>> misunderstanding from my part.
>>
> My goal is to get a better precision on my printk and trace logs,
> because the precision of jiffies is really very bad compared to
> everything else I have encountered until now. But it looks like reading
> a timer is quite complicated on AT91...
> 
>> The PIT timer should not be used for systems with PM_SUSPEND enabled
>> and used because it takes ages to synchronize on resume, how does this
>> patch affect that ?
>>
>> Ref: commit ac34ad27fc ("clockevents: Do not suspend/resume if
>> unused")
> 
> So your advice would be to stay clear of the PIT, because it is
> (globally) useless.
> 
> I'll keep it in mind.

I tend to think like this as well.

I would like to simplify our timer handling on AT91 and stick with TC
for this purpose.
It has de disadvantage of being obliged to use a TC(block) for
clockevent/clocksource and loose it if we want to do something else with
it but I do think that it's worth it.

If you want a modified TC driver that registers sched_clock, we can
provide you one as a workaround before that we rework the TC driver
completely. It has it's own flaws (like re-using a compatible string or
preventing the use of the "tclib") but is certainly handy.

Bye,
-- 
Nicolas Ferre


From robert.moore at intel.com  Wed Feb 24 09:17:54 2016
From: robert.moore at intel.com (Moore, Robert)
Date: Wed, 24 Feb 2016 17:17:54 +0000
Subject: [PATCH v2 3/8] ACPI: add definitions of DBG2 subtypes
In-Reply-To: <1456333819-13482-4-git-send-email-aleksey.makarov@linaro.org>
References: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
 <1456333819-13482-4-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E37E44BCB5@ORSMSX110.amr.corp.intel.com>

I've got these for the next release of ACPICA


> -----Original Message-----
> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
> Sent: Wednesday, February 24, 2016 9:10 AM
> To: linux-acpi at vger.kernel.org
> Cc: linux-serial at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; Aleksey Makarov; Russell King; Greg Kroah-
> Hartman; Rafael J . Wysocki; Leif Lindholm; Graeme Gregory; Al Stone;
> Christopher Covington; Len Brown; Moore, Robert; Zheng, Lv;
> devel at acpica.org
> Subject: [PATCH v2 3/8] ACPI: add definitions of DBG2 subtypes
> 
> The recent version of Microsoft Debug Port Table 2 (DBG2) [1] specifies
> additional serial debug port subtypes.  These constants are also referred
> by Serial Port Console Redirection Table (SPCR) [2]
> 
> Add these constants.
> 
> [1] https://msdn.microsoft.com/en-
> us/library/windows/hardware/dn639131(v=vs.85).aspx
> [2] https://msdn.microsoft.com/en-
> us/library/windows/hardware/dn639132(v=vs.85).aspx
> 
> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> ---
>  include/acpi/actbl2.h | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h index
> a4ef625..652f747 100644
> --- a/include/acpi/actbl2.h
> +++ b/include/acpi/actbl2.h
> @@ -371,6 +371,11 @@ struct acpi_dbg2_device {
> 
>  #define ACPI_DBG2_16550_COMPATIBLE  0x0000
>  #define ACPI_DBG2_16550_SUBSET      0x0001
> +#define ACPI_DBG2_ARM_PL011         0x0003
> +#define ACPI_DBG2_ARM_SBSA_32BIT    0x000D
> +#define ACPI_DBG2_ARM_SBSA_GENERIC  0x000E
> +#define ACPI_DBG2_ARM_DCC           0x000F
> +#define ACPI_DBG2_BCM2835           0x0010
> 
>  #define ACPI_DBG2_1394_STANDARD     0x0000
> 
> --
> 2.7.1



From stefan.wahren at i2se.com  Wed Feb 24 09:22:06 2016
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Wed, 24 Feb 2016 18:22:06 +0100 (CET)
Subject: [PATCH 00/50] pinctrl: Add and use devm_ apis for
 pinctrl_{register, unregister}
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <771728522.222286.b52ca77e-fe5e-4536-8e14-525e9a846cdc.open-xchange@email.1und1.de>

Hi Laxman,

> Laxman Dewangan <ldewangan at nvidia.com> hat am 24. Februar 2016 um 14:15
> geschrieben:
>
>
> Add resource manageemnt APIs fro pinctrl_register() and pinctrl_unregister()
> and use these new APIs on hw driver to reduce the error path code and
> remove callback for driver.
>

just for interest: why didn't you patch freescale/pinctrl-mxs.c?

Regards
Stefan


From aneesh.kumar at linux.vnet.ibm.com  Wed Feb 24 09:22:23 2016
From: aneesh.kumar at linux.vnet.ibm.com (Aneesh Kumar K.V)
Date: Wed, 24 Feb 2016 22:52:23 +0530
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <56CD8B43.9070509@de.ibm.com>
References: <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name> <56BE00E7.1010303@de.ibm.com>
 <20160212181640.4eabb85f@thinkpad> <20160223103221.GA1418@node.shutemov.name>
 <20160223191907.25719a4d@thinkpad>
 <20160223193345.GC21820@node.shutemov.name> <20160223202233.GE27281@arm.com>
 <56CD8302.9080202@de.ibm.com> <20160224104139.GC28310@arm.com>
 <56CD8B43.9070509@de.ibm.com>
Message-ID: <87a8mqt44w.fsf@linux.vnet.ibm.com>

Christian Borntraeger <borntraeger at de.ibm.com> writes:

> On 02/24/2016 11:41 AM, Will Deacon wrote:
>> On Wed, Feb 24, 2016 at 11:16:34AM +0100, Christian Borntraeger wrote:
>>> On 02/23/2016 09:22 PM, Will Deacon wrote:
>>>> On Tue, Feb 23, 2016 at 10:33:45PM +0300, Kirill A. Shutemov wrote:
>>>>> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
>>>>>> I'll check with Martin, maybe it is actually trivial, then we can
>>>>>> do a quick test it to rule that one out.
>>>>>
>>>>> Oh. I found a bug in __split_huge_pmd_locked(). Although, not sure if it's
>>>>> _the_ bug.
>>>>>
>>>>> pmdp_invalidate() is called for the wrong address :-/
>>>>> I guess that can be destructive on the architecture, right?
>>>>
>>>> FWIW, arm64 ignores the address parameter for set_pmd_at, so this would
>>>> only result in the TLBI nuking the wrong entries, which is going to be
>>>> tricky to observe in practice given that we install a table entry
>>>> immediately afterwards that maps the same pages. If s390 does more here
>>>> (I see some magic asm using the address), that could be the answer...
>>>
>>> This patch does not change the address for set_pmd_at, it does that for the 
>>> pmdp_invalidate here (by keeping haddr at the start of the pmd)
>>>
>>> --->    pmdp_invalidate(vma, haddr, pmd);
>>>         pmd_populate(mm, pmd, pgtable);
>> 
>> On arm64, pmdp_invalidate looks like:
>> 
>> void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
>> 		     pmd_t *pmdp)
>> {
>> 	pmd_t entry = *pmdp;
>> 	set_pmd_at(vma->vm_mm, address, pmdp, pmd_mknotpresent(entry));
>> 	flush_pmd_tlb_range(vma, address, address + hpage_pmd_size);
>> }
>> 
>> so that's the set_pmd_at call I was referring to.
>> 
>> On s390, that address ends up in __pmdp_idte[_local], but I don't know
>> what .insn rrf,0xb98e0000,%2,%3,0,{0,1} do ;)
>
> It does invalidation of the pmd entry and tlb clearing for this entry.
>
>> 
>>> Without that fix we would clearly have stale tlb entries, no?
>> 
>> Yes, but AFAIU the sequence on arm64 is:
>> 
>> 1.  trans huge mapping (block mapping in arm64 speak)
>> 2.  faulting entry (pmd_mknotpresent)
>> 3.  tlb invalidation
>> 4.  table entry mapping the same pages as (1).
>> 
>> so if the microarchitecture we're on can tolerate a mixture of block
>> mappings and page mappings mapping the same VA to the same PA, then the
>> lack of TLB maintenance would go unnoticed. There are certainly systems
>> where that could cause an issue, but I believe the one I've been testing
>> on would be ok.
>
> So in essence you say it does not matter that you flush the wrong range in 
> flush_pmd_tlb_range as long as it will be flushed later on when the pages
> really go away. Yes, then it really might be ok for arm64.

This is more or less same for ppc64 too. With ppc64 the actual flush
happened in pmdp_huge_split_prepare() and pmdp_invalidate() is mostly a
no-op w.r.t thp split in our case.

-aneesh



From aleksey.makarov at linaro.org  Wed Feb 24 09:25:16 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Wed, 24 Feb 2016 20:25:16 +0300
Subject: [PATCH v2 3/8] ACPI: add definitions of DBG2 subtypes
In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E37E44BCB5@ORSMSX110.amr.corp.intel.com>
References: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
 <1456333819-13482-4-git-send-email-aleksey.makarov@linaro.org>
 <94F2FBAB4432B54E8AACC7DFDE6C92E37E44BCB5@ORSMSX110.amr.corp.intel.com>
Message-ID: <56CDE77C.2050301@linaro.org>



On 02/24/2016 08:17 PM, Moore, Robert wrote:
> I've got these for the next release of ACPICA

It have not been pulled to linux-next but is required for the patchset.
So I included it here.

> 
> 
>> -----Original Message-----
>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
>> Sent: Wednesday, February 24, 2016 9:10 AM
>> To: linux-acpi at vger.kernel.org
>> Cc: linux-serial at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
>> kernel at lists.infradead.org; Aleksey Makarov; Russell King; Greg Kroah-
>> Hartman; Rafael J . Wysocki; Leif Lindholm; Graeme Gregory; Al Stone;
>> Christopher Covington; Len Brown; Moore, Robert; Zheng, Lv;
>> devel at acpica.org
>> Subject: [PATCH v2 3/8] ACPI: add definitions of DBG2 subtypes
>>
>> The recent version of Microsoft Debug Port Table 2 (DBG2) [1] specifies
>> additional serial debug port subtypes.  These constants are also referred
>> by Serial Port Console Redirection Table (SPCR) [2]
>>
>> Add these constants.
>>
>> [1] https://msdn.microsoft.com/en-
>> us/library/windows/hardware/dn639131(v=vs.85).aspx
>> [2] https://msdn.microsoft.com/en-
>> us/library/windows/hardware/dn639132(v=vs.85).aspx
>>
>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
>> ---
>>  include/acpi/actbl2.h | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h index
>> a4ef625..652f747 100644
>> --- a/include/acpi/actbl2.h
>> +++ b/include/acpi/actbl2.h
>> @@ -371,6 +371,11 @@ struct acpi_dbg2_device {
>>
>>  #define ACPI_DBG2_16550_COMPATIBLE  0x0000
>>  #define ACPI_DBG2_16550_SUBSET      0x0001
>> +#define ACPI_DBG2_ARM_PL011         0x0003
>> +#define ACPI_DBG2_ARM_SBSA_32BIT    0x000D
>> +#define ACPI_DBG2_ARM_SBSA_GENERIC  0x000E
>> +#define ACPI_DBG2_ARM_DCC           0x000F
>> +#define ACPI_DBG2_BCM2835           0x0010
>>
>>  #define ACPI_DBG2_1394_STANDARD     0x0000
>>
>> --
>> 2.7.1
> 


From mark.rutland at arm.com  Wed Feb 24 09:25:46 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 24 Feb 2016 17:25:46 +0000
Subject: [PATCH 1/3] dt-bindings: arm/marvell: ABI unstability warning
 about Marvell 7K/8K
In-Reply-To: <1456327007-31008-2-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1456327007-31008-2-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20160224172545.GC9137@leverpostej>

Hi,

[adding the device tree list to Cc]

On Wed, Feb 24, 2016 at 04:16:45PM +0100, Thomas Petazzoni wrote:
> Since we are still very early in the support of Marvell Armada 7/8K
> chips and those chips are significantly different from earlier 32 bits
> Armada SOCs, it is difficult to commit to Device Tree ABI stability at
> this point.

I don't see why difference to an existing SoC means that we cannot
guarantee support for this DT. Why does that contribute to instability?

If there's something we're unsure about, we should be seeding the DT
with sufficient information to do the right thing(TM) in future. What
areas in particular do you think are likely to be problematic? Is there
anything in particular that you think that approach doesn't work for?

>From my PoV, if we're so uncertain about a DT binding that it cannot be
kept supported, it is a prototype not yet fit for mainline.

> Therefore, this commit adds a warning to the Marvell 7K/8K DT binding
> documentation to indicate that the bindings are for the moment
> unstable.

As with the other thread, I'm strongly opposed to this mentality.

This is really the last thing we want to see for new platforms which are
DT from day one. The messy problems with platform data => DT don't
apply, and I really can't see a compelling reason to not put the effort
in here to do things "properly".

Thanks.
Mark.

> Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  .../devicetree/bindings/arm/marvell/armada-7k-8k.txt         | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
> index df98a9c..758b3ae 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.txt
> @@ -1,6 +1,18 @@
>  Marvell Armada 7K/8K Platforms Device Tree Bindings
>  ---------------------------------------------------
>  
> +Work in progress statement:
> +
> +Device tree files and bindings applying to Marvell Armada 7K and 8K
> +SoCs and boards are considered "unstable". Any Marvell Armada 7K/8K
> +device tree binding may change at any time. Be sure to use a device
> +tree binary and a kernel image generated from the same source tree.
> +
> +Please refer to Documentation/devicetree/bindings/ABI.txt for a
> +definition of a stable binding/ABI.
> +
> +---------------------------------------------------------------
> +
>  Boards using a SoC of the Marvell Armada 7K or 8K families must carry
>  the following root node property:
>  
> -- 
> 2.6.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


From javier at osg.samsung.com  Wed Feb 24 09:26:20 2016
From: javier at osg.samsung.com (Javier Martinez Canillas)
Date: Wed, 24 Feb 2016 14:26:20 -0300
Subject: [PATCH] rtc: mt6397: Remove plaform module alias
Message-ID: <1456334780-17380-1-git-send-email-javier@osg.samsung.com>

The driver uses the MODULE_ALIAS() macro to export a platform module alias
to allow the module to be autoloaded if the device is registered using the
legacy platform registration mechanism but the driver is always used by OF
only machines so the alias is not needed and should just be removed.

Suggested-by: Arnd Bergmann <arnd at arndb.de>
Signed-off-by: Javier Martinez Canillas <javier at osg.samsung.com>

---
Hello,

This patch supersedes "rtc: mt6397: Add platform device ID table":
https://lkml.org/lkml/2016/2/9/192.

Best regards,
Javier

 drivers/rtc/rtc-mt6397.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index 06a5c52b292f..44f622c3e048 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -419,4 +419,3 @@ module_platform_driver(mtk_rtc_driver);
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Tianping Fang <tianping.fang at mediatek.com>");
 MODULE_DESCRIPTION("RTC Driver for MediaTek MT6397 PMIC");
-MODULE_ALIAS("platform:mt6397-rtc");
-- 
2.5.0



From ldewangan at nvidia.com  Wed Feb 24 09:14:52 2016
From: ldewangan at nvidia.com (Laxman Dewangan)
Date: Wed, 24 Feb 2016 22:44:52 +0530
Subject: [PATCH 00/50] pinctrl: Add and use devm_ apis for
 pinctrl_{register, unregister}
In-Reply-To: <771728522.222286.b52ca77e-fe5e-4536-8e14-525e9a846cdc.open-xchange@email.1und1.de>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <771728522.222286.b52ca77e-fe5e-4536-8e14-525e9a846cdc.open-xchange@email.1und1.de>
Message-ID: <56CDE50C.4050504@nvidia.com>


On Wednesday 24 February 2016 10:52 PM, Stefan Wahren wrote:
> Hi Laxman,
>
>> Laxman Dewangan <ldewangan at nvidia.com> hat am 24. Februar 2016 um 14:15
>> geschrieben:
>>
>>
>> Add resource manageemnt APIs fro pinctrl_register() and pinctrl_unregister()
>> and use these new APIs on hw driver to reduce the error path code and
>> remove callback for driver.
>>
> just for interest: why didn't you patch freescale/pinctrl-mxs.c?
>


The remove callback is implemented as:

int mxs_pinctrl_remove(struct platform_device *pdev)
{
         struct mxs_pinctrl_data *d = platform_get_drvdata(pdev);

         pinctrl_unregister(d->pctl);
         iounmap(d->base);

         return 0;
}


So if I use devm_pinctrl_register() then the sequence will be different like
     iounmap()
     pinctrl_unregister()

And I did not want to change the sequence as dont know the side effect 
until I test it on actual platform which is not there with me.



From stefan.wahren at i2se.com  Wed Feb 24 09:29:43 2016
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Wed, 24 Feb 2016 18:29:43 +0100 (CET)
Subject: [PATCH] i2c: bcm2835: Don't complain on -EPROBE_DEFER from
 getting our clock
In-Reply-To: <1455844375-15019-1-git-send-email-eric@anholt.net>
References: <1455844375-15019-1-git-send-email-eric@anholt.net>
Message-ID: <1956465948.222514.b52ca77e-fe5e-4536-8e14-525e9a846cdc.open-xchange@email.1und1.de>

Hi Eric,

> Eric Anholt <eric at anholt.net> hat am 19. Februar 2016 um 02:12 geschrieben:
>
>
> Fixes dmesg spam when we just need to wait a moment for the clock
> driver to probe.
>
> Signed-off-by: Eric Anholt <eric at anholt.net>
> ---
> drivers/i2c/busses/i2c-bcm2835.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-bcm2835.c
> b/drivers/i2c/busses/i2c-bcm2835.c
> index 818b051..d4f3239 100644
> --- a/drivers/i2c/busses/i2c-bcm2835.c
> +++ b/drivers/i2c/busses/i2c-bcm2835.c
> @@ -253,7 +253,8 @@ static int bcm2835_i2c_probe(struct platform_device *pdev)
>
> i2c_dev->clk = devm_clk_get(&pdev->dev, NULL);
> if (IS_ERR(i2c_dev->clk)) {
> - dev_err(&pdev->dev, "Could not get clock\n");
> + if (PTR_ERR(i2c_dev->clk) != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Could not get clock\n");

i know it's something different, but how about printing the error code here?

Regards
Stefan

> return PTR_ERR(i2c_dev->clk);
> }
>
> --
> 2.7.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From antoine.tenart at free-electrons.com  Wed Feb 24 09:28:59 2016
From: antoine.tenart at free-electrons.com (Antoine =?iso-8859-1?Q?T=E9nart?=)
Date: Wed, 24 Feb 2016 18:28:59 +0100
Subject: [PATCH 08/50] pinctrl: berlin: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-9-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-9-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160224172859.GB29884@kwain>

Hello,

On Wed, Feb 24, 2016 at 06:45:33PM +0530, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>

Acked-by: Antoine Tenart <antoine.tenart at free-electrons.com>

Thanks!

Antoine

> Cc: Antoine T?nart <antoine.tenart at free-electrons.com>
> ---
>  drivers/pinctrl/berlin/berlin.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/berlin/berlin.c b/drivers/pinctrl/berlin/berlin.c
> index 46f2b48..2d58166 100644
> --- a/drivers/pinctrl/berlin/berlin.c
> +++ b/drivers/pinctrl/berlin/berlin.c
> @@ -316,7 +316,8 @@ int berlin_pinctrl_probe_regmap(struct platform_device *pdev,
>  		return ret;
>  	}
>  
> -	pctrl->pctrl_dev = pinctrl_register(&berlin_pctrl_desc, dev, pctrl);
> +	pctrl->pctrl_dev = devm_pinctrl_register(dev, &berlin_pctrl_desc,
> +						 pctrl);
>  	if (IS_ERR(pctrl->pctrl_dev)) {
>  		dev_err(dev, "failed to register pinctrl driver\n");
>  		return PTR_ERR(pctrl->pctrl_dev);
> -- 
> 2.1.4
> 

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/88b78011/attachment-0001.sig>

From colin.king at canonical.com  Wed Feb 24 09:32:50 2016
From: colin.king at canonical.com (Colin King)
Date: Wed, 24 Feb 2016 17:32:50 +0000
Subject: [PATCH] pinctrl: lpc18xx: ensure ngroups is initialized at correct
 place
Message-ID: <1456335170-20718-1-git-send-email-colin.king@canonical.com>

From: Colin Ian King <colin.king at canonical.com>

The initialization of ngroups is occurring at the end of the
first iteration of the outer loop, which means that the
assignment  pins[ngroups++] = i is potentially indexing into
a region outside of array pins because ngroups is not initialized.
Instead, initialize ngroups in the inner loop before the first
inner loop iteration.

Signed-off-by: Colin Ian King <colin.king at canonical.com>
---
 drivers/pinctrl/pinctrl-lpc18xx.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-lpc18xx.c b/drivers/pinctrl/pinctrl-lpc18xx.c
index f0bebbe..ed1cfa7 100644
--- a/drivers/pinctrl/pinctrl-lpc18xx.c
+++ b/drivers/pinctrl/pinctrl-lpc18xx.c
@@ -1170,9 +1170,8 @@ static int lpc18xx_create_group_func_map(struct device *dev,
 	u16 pins[ARRAY_SIZE(lpc18xx_pins)];
 	int func, ngroups, i;
 
-	for (func = 0; func < FUNC_MAX; ngroups = 0, func++) {
-
-		for (i = 0; i < ARRAY_SIZE(lpc18xx_pins); i++) {
+	for (func = 0; func < FUNC_MAX; func++) {
+		for (ngroups = 0, i = 0; i < ARRAY_SIZE(lpc18xx_pins); i++) {
 			if (lpc18xx_valid_pin_function(i, func))
 				pins[ngroups++] = i;
 		}
-- 
2.7.0



From lorenzo.pieralisi at arm.com  Wed Feb 24 09:35:11 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Feb 2016 17:35:11 +0000
Subject: [PATCH] drivers: perf: arm: implement CPU_PM notifier
In-Reply-To: <CANLsYkzvB0GbPeYHrcLtUz8DMHJh4FA5RVwVZ-UAm3BCznB_3w@mail.gmail.com>
References: <1456251759-24768-1-git-send-email-lorenzo.pieralisi@arm.com>
 <CANLsYkzvB0GbPeYHrcLtUz8DMHJh4FA5RVwVZ-UAm3BCznB_3w@mail.gmail.com>
Message-ID: <20160224173511.GF25385@red-moon>

On Wed, Feb 24, 2016 at 09:20:22AM -0700, Mathieu Poirier wrote:
> On 23 February 2016 at 11:22, Lorenzo Pieralisi

[...]

> > +static int cpu_pm_pmu_notify(struct notifier_block *b, unsigned long cmd,
> > +                            void *v)
> > +{
> > +       struct arm_pmu *armpmu = container_of(b, struct arm_pmu, cpu_pm_nb);
> > +       struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
> > +       int enabled = bitmap_weight(hw_events->used_mask, armpmu->num_events);
> > +
> > +       if (!cpumask_test_cpu(smp_processor_id(), &armpmu->supported_cpus))
> > +               return NOTIFY_DONE;
> > +
> > +       /*
> > +        * Always reset the PMU registers on power-up even if
> > +        * there are no events running.
> > +        */
> > +       if (cmd == CPU_PM_EXIT && armpmu->reset)
> > +               armpmu->reset(armpmu);
> 
> I think this patch does the right thing but I can't get the above
> reset.  Wouldn't it be better to do the reset as part of the
> CPU_PM_EXIT case below?  At this point nothing tells us the CPU won't
> go back down before the event is enabled, wasting the cycle needed to
> reset the PMU.

The logic goes, if the cpu is woken up and it has no events enabled,
if we do not reset it (mind, ->reset here sets the PMU register values
to a sane default, some of them are architecturally UNKNOWN on reset, it
does NOT reset the PMU) _and_ we subsequently install an event on it we
do have a problem, that's why whenever a core gets out of low-power we
have to reset its pmu.

Does it make sense ?

Thanks,
Lorenzo

> 
> Thanks,
> Mathieu
> 
> > +
> > +       if (!enabled)
> > +               return NOTIFY_OK;
> > +
> > +       switch (cmd) {
> > +       case CPU_PM_ENTER:
> > +               armpmu->stop(armpmu);
> > +               cpu_pm_pmu_setup(armpmu, cmd);
> > +               break;
> > +       case CPU_PM_EXIT:
> > +               cpu_pm_pmu_setup(armpmu, cmd);
> > +       case CPU_PM_ENTER_FAILED:
> > +               armpmu->start(armpmu);
> > +               break;
> > +       default:
> > +               return NOTIFY_DONE;
> > +       }
> > +
> > +       return NOTIFY_OK;
> > +}
> > +
> > +static int cpu_pm_pmu_register(struct arm_pmu *cpu_pmu)
> > +{
> > +       cpu_pmu->cpu_pm_nb.notifier_call = cpu_pm_pmu_notify;
> > +       return cpu_pm_register_notifier(&cpu_pmu->cpu_pm_nb);
> > +}
> > +
> > +static void cpu_pm_pmu_unregister(struct arm_pmu *cpu_pmu)
> > +{
> > +       cpu_pm_unregister_notifier(&cpu_pmu->cpu_pm_nb);
> > +}
> > +#else
> > +static inline int cpu_pm_pmu_register(struct arm_pmu *cpu_pmu) { return 0; }
> > +static inline void cpu_pm_pmu_unregister(struct arm_pmu *cpu_pmu) { }
> > +#endif
> > +
> >  static int cpu_pmu_init(struct arm_pmu *cpu_pmu)
> >  {
> >         int err;
> > @@ -725,6 +813,10 @@ static int cpu_pmu_init(struct arm_pmu *cpu_pmu)
> >         if (err)
> >                 goto out_hw_events;
> >
> > +       err = cpu_pm_pmu_register(cpu_pmu);
> > +       if (err)
> > +               goto out_unregister;
> > +
> >         for_each_possible_cpu(cpu) {
> >                 struct pmu_hw_events *events = per_cpu_ptr(cpu_hw_events, cpu);
> >                 raw_spin_lock_init(&events->pmu_lock);
> > @@ -746,6 +838,8 @@ static int cpu_pmu_init(struct arm_pmu *cpu_pmu)
> >
> >         return 0;
> >
> > +out_unregister:
> > +       unregister_cpu_notifier(&cpu_pmu->hotplug_nb);
> >  out_hw_events:
> >         free_percpu(cpu_hw_events);
> >         return err;
> > @@ -753,6 +847,7 @@ out_hw_events:
> >
> >  static void cpu_pmu_destroy(struct arm_pmu *cpu_pmu)
> >  {
> > +       cpu_pm_pmu_unregister(cpu_pmu);
> >         unregister_cpu_notifier(&cpu_pmu->hotplug_nb);
> >         free_percpu(cpu_pmu->hw_events);
> >  }
> > diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
> > index 83b5e34..9ffa316 100644
> > --- a/include/linux/perf/arm_pmu.h
> > +++ b/include/linux/perf/arm_pmu.h
> > @@ -107,6 +107,7 @@ struct arm_pmu {
> >         struct platform_device  *plat_device;
> >         struct pmu_hw_events    __percpu *hw_events;
> >         struct notifier_block   hotplug_nb;
> > +       struct notifier_block   cpu_pm_nb;
> >  };
> >
> >  #define to_arm_pmu(p) (container_of(p, struct arm_pmu, pmu))
> > --
> > 2.5.1
> >
> 


From marc.zyngier at arm.com  Wed Feb 24 09:33:44 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Feb 2016 17:33:44 +0000
Subject: [PATCH 3/3] arm64: KVM: vgic-v3: Restore ICH_APR0Rn_EL2 before
 ICH_APR1Rn_EL2
In-Reply-To: <1456335224-20603-1-git-send-email-marc.zyngier@arm.com>
References: <1456335224-20603-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1456335224-20603-4-git-send-email-marc.zyngier@arm.com>

The GICv3 architecture spec says:

Writing to the active priority registers in any order other than
the following order will result in UNPREDICTABLE behavior:
- ICH_AP0R<n>_EL2.
- ICH_AP1R<n>_EL2.

So let's not pointlessly go against the rule...

Acked-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm64/kvm/hyp/vgic-v3-sr.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
index 9142e082..5dd2a26 100644
--- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
+++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
@@ -149,16 +149,6 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
 
 	switch (nr_pri_bits) {
 	case 7:
-		 write_gicreg(cpu_if->vgic_ap1r[3], ICH_AP1R3_EL2);
-		 write_gicreg(cpu_if->vgic_ap1r[2], ICH_AP1R2_EL2);
-	case 6:
-		 write_gicreg(cpu_if->vgic_ap1r[1], ICH_AP1R1_EL2);
-	default:
-		 write_gicreg(cpu_if->vgic_ap1r[0], ICH_AP1R0_EL2);
-	}	 	                           
-		 	                           
-	switch (nr_pri_bits) {
-	case 7:
 		 write_gicreg(cpu_if->vgic_ap0r[3], ICH_AP0R3_EL2);
 		 write_gicreg(cpu_if->vgic_ap0r[2], ICH_AP0R2_EL2);
 	case 6:
@@ -167,6 +157,16 @@ void __hyp_text __vgic_v3_restore_state(struct kvm_vcpu *vcpu)
 		 write_gicreg(cpu_if->vgic_ap0r[0], ICH_AP0R0_EL2);
 	}
 
+	switch (nr_pri_bits) {
+	case 7:
+		 write_gicreg(cpu_if->vgic_ap1r[3], ICH_AP1R3_EL2);
+		 write_gicreg(cpu_if->vgic_ap1r[2], ICH_AP1R2_EL2);
+	case 6:
+		 write_gicreg(cpu_if->vgic_ap1r[1], ICH_AP1R1_EL2);
+	default:
+		 write_gicreg(cpu_if->vgic_ap1r[0], ICH_AP1R0_EL2);
+	}
+
 	switch (max_lr_idx) {
 	case 15:
 		write_gicreg(cpu_if->vgic_lr[VGIC_V3_LR_INDEX(15)], ICH_LR15_EL2);
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 24 09:33:41 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Feb 2016 17:33:41 +0000
Subject: [PULL] KVM/ARM fixes for 4.5-rc6
Message-ID: <1456335224-20603-1-git-send-email-marc.zyngier@arm.com>

Hi Paolo,

This is hopefully the last batch of fixes for 4.5. One case of bitmap
going overboard, another case of uninitialized memory, and a fix for
an unpredictable behaviour.

Please pull!

Thanks,

	M.

The following changes since commit 3c5b1d92b3b02be07873d611a27950addff544d3:

  arm64: KVM: Configure TCR_EL2.PS at runtime (2016-02-11 13:16:47 +0000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvm-arm-for-4.5-rc6

for you to fetch changes up to fd451b90e78c4178bcfc5072f2b2b637500c109a:

  arm64: KVM: vgic-v3: Restore ICH_APR0Rn_EL2 before ICH_APR1Rn_EL2 (2016-02-24 17:25:58 +0000)

----------------------------------------------------------------
KVM/ARM fixes for 4.5-rc6

- Fix per-vcpu vgic bitmap allocation
- Do not give copy random memory on MMIO read
- Fix GICv3 APR register restore order

----------------------------------------------------------------
Marc Zyngier (2):
      arm/arm64: KVM: Feed initialized memory to MMIO accesses
      arm64: KVM: vgic-v3: Restore ICH_APR0Rn_EL2 before ICH_APR1Rn_EL2

Mark Rutland (1):
      KVM: arm/arm64: vgic: Ensure bitmaps are long enough

 arch/arm/kvm/mmio.c             |  3 ++-
 arch/arm64/kvm/hyp/vgic-v3-sr.c | 20 ++++++++++----------
 virt/kvm/arm/vgic.c             |  4 ++--
 3 files changed, 14 insertions(+), 13 deletions(-)


From marc.zyngier at arm.com  Wed Feb 24 09:33:43 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Feb 2016 17:33:43 +0000
Subject: [PATCH 2/3] arm/arm64: KVM: Feed initialized memory to MMIO accesses
In-Reply-To: <1456335224-20603-1-git-send-email-marc.zyngier@arm.com>
References: <1456335224-20603-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1456335224-20603-3-git-send-email-marc.zyngier@arm.com>

On an MMIO access, we always copy the on-stack buffer info
the shared "run" structure, even if this is a read access.
This ends up leaking up to 8 bytes of uninitialized memory
into userspace, depending on the size of the access.

An obvious fix for this one is to only perform the copy if
this is an actual write.

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 arch/arm/kvm/mmio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
index 7f33b20..0f6600f 100644
--- a/arch/arm/kvm/mmio.c
+++ b/arch/arm/kvm/mmio.c
@@ -206,7 +206,8 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run,
 	run->mmio.is_write	= is_write;
 	run->mmio.phys_addr	= fault_ipa;
 	run->mmio.len		= len;
-	memcpy(run->mmio.data, data_buf, len);
+	if (is_write)
+		memcpy(run->mmio.data, data_buf, len);
 
 	if (!ret) {
 		/* We handled the access successfully in the kernel. */
-- 
2.1.4



From marc.zyngier at arm.com  Wed Feb 24 09:33:42 2016
From: marc.zyngier at arm.com (Marc Zyngier)
Date: Wed, 24 Feb 2016 17:33:42 +0000
Subject: [PATCH 1/3] KVM: arm/arm64: vgic: Ensure bitmaps are long enough
In-Reply-To: <1456335224-20603-1-git-send-email-marc.zyngier@arm.com>
References: <1456335224-20603-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <1456335224-20603-2-git-send-email-marc.zyngier@arm.com>

From: Mark Rutland <mark.rutland at arm.com>

When we allocate bitmaps in vgic_vcpu_init_maps, we divide the number of
bits we need by 8 to figure out how many bytes to allocate. However,
bitmap elements are always accessed as unsigned longs, and if we didn't
happen to allocate a size such that size % sizeof(unsigned long) == 0,
bitmap accesses may go past the end of the allocation.

When using KASAN (which does byte-granular access checks), this results
in a continuous stream of BUGs whenever these bitmaps are accessed:

=============================================================================
BUG kmalloc-128 (Tainted: G    B          ): kasan: bad access detected
-----------------------------------------------------------------------------

INFO: Allocated in vgic_init.part.25+0x55c/0x990 age=7493 cpu=3 pid=1730
INFO: Slab 0xffffffbde6d5da40 objects=16 used=15 fp=0xffffffc935769700 flags=0x4000000000000080
INFO: Object 0xffffffc935769500 @offset=1280 fp=0x          (null)

Bytes b4 ffffffc9357694f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Object ffffffc935769570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Padding ffffffc9357695b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Padding ffffffc9357695c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Padding ffffffc9357695d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Padding ffffffc9357695e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Padding ffffffc9357695f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
CPU: 3 PID: 1740 Comm: kvm-vcpu-0 Tainted: G    B           4.4.0+ #17
Hardware name: ARM Juno development board (r1) (DT)
Call trace:
[<ffffffc00008e770>] dump_backtrace+0x0/0x280
[<ffffffc00008ea04>] show_stack+0x14/0x20
[<ffffffc000726360>] dump_stack+0x100/0x188
[<ffffffc00030d324>] print_trailer+0xfc/0x168
[<ffffffc000312294>] object_err+0x3c/0x50
[<ffffffc0003140fc>] kasan_report_error+0x244/0x558
[<ffffffc000314548>] __asan_report_load8_noabort+0x48/0x50
[<ffffffc000745688>] __bitmap_or+0xc0/0xc8
[<ffffffc0000d9e44>] kvm_vgic_flush_hwstate+0x1bc/0x650
[<ffffffc0000c514c>] kvm_arch_vcpu_ioctl_run+0x2ec/0xa60
[<ffffffc0000b9a6c>] kvm_vcpu_ioctl+0x474/0xa68
[<ffffffc00036b7b0>] do_vfs_ioctl+0x5b8/0xcb0
[<ffffffc00036bf34>] SyS_ioctl+0x8c/0xa0
[<ffffffc000086cb0>] el0_svc_naked+0x24/0x28
Memory state around the buggy address:
 ffffffc935769400: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffffffc935769480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffffffc935769500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                   ^
 ffffffc935769580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffffffc935769600: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================

Fix the issue by always allocating a multiple of sizeof(unsigned long),
as we do elsewhere in the vgic code.

Fixes: c1bfb577a ("arm/arm64: KVM: vgic: switch to dynamic allocation")
Cc: stable at vger.kernel.org
Acked-by: Marc Zyngier <marc.zyngier at arm.com>
Acked-by: Christoffer Dall <christoffer.dall at linaro.org>
Signed-off-by: Mark Rutland <mark.rutland at arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
---
 virt/kvm/arm/vgic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 043032c..00429b3 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -1875,8 +1875,8 @@ void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu)
 static int vgic_vcpu_init_maps(struct kvm_vcpu *vcpu, int nr_irqs)
 {
 	struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
-
-	int sz = (nr_irqs - VGIC_NR_PRIVATE_IRQS) / 8;
+	int nr_longs = BITS_TO_LONGS(nr_irqs - VGIC_NR_PRIVATE_IRQS);
+	int sz = nr_longs * sizeof(unsigned long);
 	vgic_cpu->pending_shared = kzalloc(sz, GFP_KERNEL);
 	vgic_cpu->active_shared = kzalloc(sz, GFP_KERNEL);
 	vgic_cpu->pend_act_shared = kzalloc(sz, GFP_KERNEL);
-- 
2.1.4



From slemieux.tyco at gmail.com  Wed Feb 24 09:46:52 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Wed, 24 Feb 2016 12:46:52 -0500
Subject: [PATCH v3 0/6] watchdog: pnx4008: add restart handler
Message-ID: <1456336018-6620-1-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

The LPC32xx provide the capability to perform a soft or hard reset;
a soft reset will no reset the external peripheral
(i.e. RESOUT_N output not asserted).

This changeset migrate the restart code from the "mach-lpc32xx" to
the "pnx-4008" watchdog driver and add the soft reset capability.

The default behavior (i.e. hard reset) remain unchanged.

The core restart handler support added by this change:
2165bf524da5f5e496d - "watchdog: core: add restart handler support"
is not use in this changeset; it does not support the reboot mode.

Note:
The patch #6 was generated with the option "--unified=2" to ensure
it can be apply before or after the following git pull request
for the LPC32xx platform:
- http://permalink.gmane.org/gmane.linux.ports.arm.kernel/477137
- http://permalink.gmane.org/gmane.linux.ports.arm.kernel/477138
---
Changes from v2 to v3:
* Update the patch as per the feedback received from:
  Joachim: http://permalink.gmane.org/gmane.linux.watchdog/3303
  - remove explicit clock enable from restart handler.
  - verify "register_restart_handler" return value.
  - add call to unregister_restart_handler".
  - do the restart handling directly in "pnx4008_restart_handler".
* Move the change to "phy3250.c" into a separate patch and generate
  the new patch with the "--unified=2" option.

Changes from v1 to v2:
* Rename patch title;
  was "arm: lpc32xx: restart: add support for soft reset"
* Update the patch as per the feedback received from:
  Joachim: http://permalink.gmane.org/gmane.linux.ports.arm.kernel/479791
  - migrate restart code from "mach-lpc32xx" to "pnx-4008" driver.
* Add soft reset support to "pnx-4008" driver instead of "mach-lpc32xx".
* Use define available in "pnx-4008" when writting to watchdog register.
* Remove restart handler from "mach-lpc32xx".
* Remove restart hook from "phy3250.c".
* Update driver logging during power-on. 

Sylvain Lemieux (6):
  watchdog: pnx4008: update logging during power-on
  watchdog: pnx4008: add restart handler
  watchdog: pnx4008: add support for soft reset
  watchdog: pnx4008: restart: support "cmd" from userspace
  arm: lpc32xx: remove restart handler
  arm: lpc32xx: phy3250 remove restart hook

 arch/arm/mach-lpc32xx/common.c  | 15 ------------
 arch/arm/mach-lpc32xx/common.h  |  1 -
 arch/arm/mach-lpc32xx/phy3250.c |  1 -
 drivers/watchdog/pnx4008_wdt.c  | 51 +++++++++++++++++++++++++++++++++++++++--
 4 files changed, 49 insertions(+), 19 deletions(-)

-- 
1.8.3.1



From slemieux.tyco at gmail.com  Wed Feb 24 09:46:53 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Wed, 24 Feb 2016 12:46:53 -0500
Subject: [PATCH v3 1/6] watchdog: pnx4008: update logging during power-on
In-Reply-To: <1456336018-6620-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456336018-6620-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456336018-6620-2-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

There is no need add the driver name in the text to display
on the console during the power-on:
pnx4008-watchdog 4003c000.watchdog: PNX4008 Watchdog Timer: heartbeat 19 sec

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Changes from v2 to v3:
- none.

Changes from v1 to v2:
- new patch in v2.

 drivers/watchdog/pnx4008_wdt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
index 313cd1c..88264a2 100644
--- a/drivers/watchdog/pnx4008_wdt.c
+++ b/drivers/watchdog/pnx4008_wdt.c
@@ -178,8 +178,7 @@ static int pnx4008_wdt_probe(struct platform_device *pdev)
 		goto disable_clk;
 	}
 
-	dev_info(&pdev->dev, "PNX4008 Watchdog Timer: heartbeat %d sec\n",
-		 pnx4008_wdd.timeout);
+	dev_info(&pdev->dev, "heartbeat %d sec\n", pnx4008_wdd.timeout);
 
 	return 0;
 
-- 
1.8.3.1



From slemieux.tyco at gmail.com  Wed Feb 24 09:46:56 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Wed, 24 Feb 2016 12:46:56 -0500
Subject: [PATCH v3 4/6] watchdog: pnx4008: restart: support "cmd" from
 userspace
In-Reply-To: <1456336018-6620-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456336018-6620-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456336018-6620-5-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Added support to verify if a "cmd" is passed from the userspace program rebooting the system;
- if a valid "cmd" is available, handle it;
- If the received "cmd" is not supported, use the default reboot mode.

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Changes from v2 to v3:
- no logical change; updated to work with new revision of patch #2.

Changes from v1 to v2:
- Rename patch title;
  was "arm: lpc32xx: restart: support "cmd" from userspace"
- Add change to "pnx-4008" driver instead of "mach-lpc32xx".

 drivers/watchdog/pnx4008_wdt.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
index fbf027e..e97b611 100644
--- a/drivers/watchdog/pnx4008_wdt.c
+++ b/drivers/watchdog/pnx4008_wdt.c
@@ -130,6 +130,21 @@ static int pnx4008_wdt_set_timeout(struct watchdog_device *wdd,
 static int pnx4008_restart_handler(struct notifier_block *this,
 				   unsigned long mode, void *cmd)
 {
+	const char *boot_cmd = (const char *)cmd;
+
+	/*
+	 * Verify if a "cmd" passed from the userspace program rebooting
+	 * the system; if available, handle it.
+	 * - For details, see the 'reboot' syscall in kernel/reboot.c
+	 * - If the received "cmd" is not supported, use the default mode.
+	 */
+	if (boot_cmd) {
+		if (boot_cmd[0] == 'h')
+			mode = (unsigned long)REBOOT_HARD;
+		else if (boot_cmd[0] == 's')
+			mode = (unsigned long)REBOOT_SOFT;
+	}
+
 	if (mode == (unsigned long)REBOOT_SOFT) {
 		/* Force match output active */
 		writel(EXT_MATCH0, WDTIM_EMR(wdt_base));
-- 
1.8.3.1



From slemieux.tyco at gmail.com  Wed Feb 24 09:46:54 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Wed, 24 Feb 2016 12:46:54 -0500
Subject: [PATCH v3 2/6] watchdog: pnx4008: add restart handler
In-Reply-To: <1456336018-6620-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456336018-6620-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456336018-6620-3-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Add restart handler capability to the driver;
the restart handler implementation was taken from
"mach-lpc32xx" ("lpc23xx_restart" function).

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Changes from v2 to v3:
- remove explicit clock enable from restart handler.
- verify "register_restart_handler" return value.
- add call to unregister_restart_handler".
- do the restart handling directly in "pnx4008_restart_handler".

Changes from v1 to v2:
- new patch in v2.

 drivers/watchdog/pnx4008_wdt.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
index 88264a2..80ee4af 100644
--- a/drivers/watchdog/pnx4008_wdt.c
+++ b/drivers/watchdog/pnx4008_wdt.c
@@ -31,6 +31,8 @@
 #include <linux/slab.h>
 #include <linux/err.h>
 #include <linux/of.h>
+#include <linux/delay.h>
+#include <linux/reboot.h>
 #include <mach/hardware.h>
 
 /* WatchDog Timer - Chapter 23 Page 207 */
@@ -77,6 +79,7 @@
 
 static bool nowayout = WATCHDOG_NOWAYOUT;
 static unsigned int heartbeat = DEFAULT_HEARTBEAT;
+static struct notifier_block restart_handler;
 
 static DEFINE_SPINLOCK(io_lock);
 static void __iomem	*wdt_base;
@@ -124,6 +127,19 @@ static int pnx4008_wdt_set_timeout(struct watchdog_device *wdd,
 	return 0;
 }
 
+static int pnx4008_restart_handler(struct notifier_block *this,
+				   unsigned long mode, void *cmd)
+{
+	/* Instant assert of RESETOUT_N with pulse length 1mS */
+	writel(13000, WDTIM_PULSE(wdt_base));
+	writel(M_RES2 | RESFRC1 | RESFRC2, WDTIM_MCTRL(wdt_base));
+
+	/* Wait for watchdog to reset system */
+	mdelay(1000);
+
+	return NOTIFY_DONE;
+}
+
 static const struct watchdog_info pnx4008_wdt_ident = {
 	.options = WDIOF_CARDRESET | WDIOF_MAGICCLOSE |
 	    WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
@@ -157,6 +173,15 @@ static int pnx4008_wdt_probe(struct platform_device *pdev)
 	if (IS_ERR(wdt_base))
 		return PTR_ERR(wdt_base);
 
+	/* Register restart handler. */
+	restart_handler.notifier_call = pnx4008_restart_handler;
+	restart_handler.priority = 128;
+	ret = register_restart_handler(&restart_handler);
+	if (ret) {
+		dev_warn(&pdev->dev, "cannot register restart handler\n");
+		return ret;
+	}
+
 	wdt_clk = devm_clk_get(&pdev->dev, NULL);
 	if (IS_ERR(wdt_clk))
 		return PTR_ERR(wdt_clk);
@@ -189,6 +214,7 @@ disable_clk:
 
 static int pnx4008_wdt_remove(struct platform_device *pdev)
 {
+	unregister_restart_handler(&restart_handler);
 	watchdog_unregister_device(&pnx4008_wdd);
 
 	clk_disable_unprepare(wdt_clk);
-- 
1.8.3.1



From slemieux.tyco at gmail.com  Wed Feb 24 09:46:55 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Wed, 24 Feb 2016 12:46:55 -0500
Subject: [PATCH v3 3/6] watchdog: pnx4008: add support for soft reset
In-Reply-To: <1456336018-6620-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456336018-6620-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456336018-6620-4-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Add support for explicit soft reset using the reboot mode.

The default reboot mode behavior is unchanged;
you can overwrite the default reboot type in the board specific file
"DT_MACHINE_START" definition using the "reboot_mode" parameter.

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Changes from v2 to v3:
- no logical change; updated to work with new revision of patch #2.

Changes from v1 to v2:
- Rename patch title;
  was "arm: lpc32xx: restart: add support for soft reset"
- Add change to "pnx-4008" driver instead of "mach-lpc32xx".
- Use define available in "pnx-4008" when writting to watchdog register.

 drivers/watchdog/pnx4008_wdt.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
index 80ee4af..fbf027e 100644
--- a/drivers/watchdog/pnx4008_wdt.c
+++ b/drivers/watchdog/pnx4008_wdt.c
@@ -130,9 +130,16 @@ static int pnx4008_wdt_set_timeout(struct watchdog_device *wdd,
 static int pnx4008_restart_handler(struct notifier_block *this,
 				   unsigned long mode, void *cmd)
 {
-	/* Instant assert of RESETOUT_N with pulse length 1mS */
-	writel(13000, WDTIM_PULSE(wdt_base));
-	writel(M_RES2 | RESFRC1 | RESFRC2, WDTIM_MCTRL(wdt_base));
+	if (mode == (unsigned long)REBOOT_SOFT) {
+		/* Force match output active */
+		writel(EXT_MATCH0, WDTIM_EMR(wdt_base));
+		/* Internal reset on match output (RESOUT_N not asserted) */
+		writel(M_RES1, WDTIM_MCTRL(wdt_base));
+	} else {
+		/* Instant assert of RESETOUT_N with pulse length 1mS */
+		writel(13000, WDTIM_PULSE(wdt_base));
+		writel(M_RES2 | RESFRC1 | RESFRC2, WDTIM_MCTRL(wdt_base));
+	}
 
 	/* Wait for watchdog to reset system */
 	mdelay(1000);
-- 
1.8.3.1



From slemieux.tyco at gmail.com  Wed Feb 24 09:46:57 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Wed, 24 Feb 2016 12:46:57 -0500
Subject: [PATCH v3 5/6] arm: lpc32xx: remove restart handler
In-Reply-To: <1456336018-6620-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456336018-6620-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456336018-6620-6-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Remove the restart handler from "mach-lpc32xx";
this functionality is now available in the
pnx4008 watchdog driver.

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Changes from v2 to v3:
- move the change to "phy3250.c" into a separate patch.

Changes from v1 to v2:
- new patch in v2.

 arch/arm/mach-lpc32xx/common.c | 15 ---------------
 arch/arm/mach-lpc32xx/common.h |  1 -
 2 files changed, 16 deletions(-)

diff --git a/arch/arm/mach-lpc32xx/common.c b/arch/arm/mach-lpc32xx/common.c
index 716e83e..5b7a1e7 100644
--- a/arch/arm/mach-lpc32xx/common.c
+++ b/arch/arm/mach-lpc32xx/common.c
@@ -194,21 +194,6 @@ void __init lpc32xx_map_io(void)
 	iotable_init(lpc32xx_io_desc, ARRAY_SIZE(lpc32xx_io_desc));
 }
 
-void lpc23xx_restart(enum reboot_mode mode, const char *cmd)
-{
-	/* Make sure WDT clocks are enabled */
-	__raw_writel(LPC32XX_CLKPWR_PWMCLK_WDOG_EN,
-		LPC32XX_CLKPWR_TIMER_CLK_CTRL);
-
-	/* Instant assert of RESETOUT_N with pulse length 1mS */
-	__raw_writel(13000, io_p2v(LPC32XX_WDTIM_BASE + 0x18));
-	__raw_writel(0x70, io_p2v(LPC32XX_WDTIM_BASE + 0xC));
-
-	/* Wait for watchdog to reset system */
-	while (1)
-		;
-}
-
 static int __init lpc32xx_check_uid(void)
 {
 	u32 uid[4];
diff --git a/arch/arm/mach-lpc32xx/common.h b/arch/arm/mach-lpc32xx/common.h
index 1cd8853..2d90801 100644
--- a/arch/arm/mach-lpc32xx/common.h
+++ b/arch/arm/mach-lpc32xx/common.h
@@ -30,7 +30,6 @@ extern void lpc32xx_timer_init(void);
 extern void __init lpc32xx_init_irq(void);
 extern void __init lpc32xx_map_io(void);
 extern void __init lpc32xx_serial_init(void);
-extern void lpc23xx_restart(enum reboot_mode, const char *);
 
 
 /*
-- 
1.8.3.1



From slemieux.tyco at gmail.com  Wed Feb 24 09:46:58 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Wed, 24 Feb 2016 12:46:58 -0500
Subject: [PATCH v3 6/6] arm: lpc32xx: phy3250 remove restart hook
In-Reply-To: <1456336018-6620-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456336018-6620-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456336018-6620-7-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Remove the restart hook assignment from phy3250;
this functionality is now managed by
the pnx4008 watchdog driver.

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Note:
This patch was generated with the option "--unified=2" to ensure
it can be apply before or after the following git pull request
for the LPC32xx platform:
- http://permalink.gmane.org/gmane.linux.ports.arm.kernel/477137
- http://permalink.gmane.org/gmane.linux.ports.arm.kernel/477138

Changes from v2 to v3:
- new patch in v3.

 arch/arm/mach-lpc32xx/phy3250.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-lpc32xx/phy3250.c b/arch/arm/mach-lpc32xx/phy3250.c
index 65ec92c..26de053 100644
--- a/arch/arm/mach-lpc32xx/phy3250.c
+++ b/arch/arm/mach-lpc32xx/phy3250.c
@@ -264,4 +264,3 @@ DT_MACHINE_START(LPC32XX_DT, "LPC32XX SoC (Flattened Device Tree)")
 	.init_machine	= lpc3250_machine_init,
 	.dt_compat	= lpc32xx_dt_compat,
-	.restart	= lpc23xx_restart,
 MACHINE_END
-- 
1.8.3.1



From will.deacon at arm.com  Wed Feb 24 09:52:48 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Feb 2016 17:52:48 +0000
Subject: [PATCH v13 01/20] ARM64: Move PMU register related defines to
 asm/perf_event.h
In-Reply-To: <1456290520-10012-2-git-send-email-zhaoshenglong@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
 <1456290520-10012-2-git-send-email-zhaoshenglong@huawei.com>
Message-ID: <20160224175247.GE12471@arm.com>

On Wed, Feb 24, 2016 at 01:08:21PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao <shannon.zhao at linaro.org>
> 
> To use the ARMv8 PMU related register defines from the KVM code, we move
> the relevant definitions to asm/perf_event.h header file and rename them
> with prefix ARMV8_PMU_.
> 
> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> Acked-by: Marc Zyngier <marc.zyngier at arm.com>
> Reviewed-by: Andrew Jones <drjones at redhat.com>
> ---
>  arch/arm64/include/asm/perf_event.h | 35 +++++++++++++++++++
>  arch/arm64/kernel/perf_event.c      | 68 ++++++++++---------------------------
>  2 files changed, 52 insertions(+), 51 deletions(-)

Looks fine to me, but we're going to get some truly horrible conflicts
in -next.

I'm open to suggestions on the best way to handle this, but one way
would be:

  1. Duplicate all the #defines privately in KVM (queue via kvm tree)
  2. Rebase this patch onto my perf/updates branch [1] (queue via me)
  3. Patch at -rc1 dropping the #defines from (1) and moving to the new
     perf_event.h stuff

Thoughts?

Will

[1] git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/updates


From adam.buchbinder at gmail.com  Wed Feb 24 09:52:41 2016
From: adam.buchbinder at gmail.com (Adam Buchbinder)
Date: Wed, 24 Feb 2016 09:52:41 -0800
Subject: [PATCH v2] arm64: Fix misspellings in comments.
In-Reply-To: <20160224102351.GB28310@arm.com>
References: <20160224102351.GB28310@arm.com>
Message-ID: <1456336361-30697-1-git-send-email-adam.buchbinder@gmail.com>

Signed-off-by: Adam Buchbinder <adam.buchbinder at gmail.com>
---
 arch/arm64/boot/dts/nvidia/tegra132.dtsi | 2 +-
 arch/arm64/boot/dts/nvidia/tegra210.dtsi | 2 +-
 arch/arm64/include/asm/ftrace.h          | 2 +-
 arch/arm64/include/asm/kvm_arm.h         | 2 +-
 arch/arm64/include/asm/kvm_host.h        | 4 ++--
 arch/arm64/kernel/fpsimd.c               | 2 +-
 arch/arm64/kernel/kgdb.c                 | 4 ++--
 arch/arm64/kernel/signal32.c             | 2 +-
 arch/arm64/lib/memcmp.S                  | 2 +-
 9 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra132.dtsi b/arch/arm64/boot/dts/nvidia/tegra132.dtsi
index e8bb460..6e28e41 100644
--- a/arch/arm64/boot/dts/nvidia/tegra132.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra132.dtsi
@@ -313,7 +313,7 @@
 	/*
 	 * There are two serial driver i.e. 8250 based simple serial
 	 * driver and APB DMA based serial driver for higher baudrate
-	 * and performace. To enable the 8250 based driver, the compatible
+	 * and performance. To enable the 8250 based driver, the compatible
 	 * is "nvidia,tegra124-uart", "nvidia,tegra20-uart" and to enable
 	 * the APB DMA based serial driver, the comptible is
 	 * "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart".
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index bc23f4d..23b0630 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -345,7 +345,7 @@
 	/*
 	 * There are two serial driver i.e. 8250 based simple serial
 	 * driver and APB DMA based serial driver for higher baudrate
-	 * and performace. To enable the 8250 based driver, the compatible
+	 * and performance. To enable the 8250 based driver, the compatible
 	 * is "nvidia,tegra124-uart", "nvidia,tegra20-uart" and to enable
 	 * the APB DMA based serial driver, the comptible is
 	 * "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart".
diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
index 3c60f37..caa955f 100644
--- a/arch/arm64/include/asm/ftrace.h
+++ b/arch/arm64/include/asm/ftrace.h
@@ -48,7 +48,7 @@ static inline unsigned long ftrace_call_adjust(unsigned long addr)
  * See kernel/trace/trace_syscalls.c
  *
  * x86 code says:
- * If the user realy wants these, then they should use the
+ * If the user really wants these, then they should use the
  * raw syscall tracepoints with filtering.
  */
 #define ARCH_TRACE_IGNORE_COMPAT_SYSCALLS
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index d201d4b..0215b57 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -61,7 +61,7 @@
 
 /*
  * The bits we set in HCR:
- * RW:		64bit by default, can be overriden for 32bit VMs
+ * RW:		64bit by default, can be overridden for 32bit VMs
  * TAC:		Trap ACTLR
  * TSC:		Trap SMC
  * TVM:		Trap VM ops (until M+C set in SCTLR_EL1)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 689d4c9..56284eb 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -99,8 +99,8 @@ enum vcpu_sysreg {
 	TTBR1_EL1,	/* Translation Table Base Register 1 */
 	TCR_EL1,	/* Translation Control Register */
 	ESR_EL1,	/* Exception Syndrome Register */
-	AFSR0_EL1,	/* Auxilary Fault Status Register 0 */
-	AFSR1_EL1,	/* Auxilary Fault Status Register 1 */
+	AFSR0_EL1,	/* Auxiliary Fault Status Register 0 */
+	AFSR1_EL1,	/* Auxiliary Fault Status Register 1 */
 	FAR_EL1,	/* Fault Address Register */
 	MAIR_EL1,	/* Memory Attribute Indirection Register */
 	VBAR_EL1,	/* Vector Base Address Register */
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index acc1afd..975b274 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -45,7 +45,7 @@
  *     been used to perform kernel mode NEON in the meantime.
  *
  * For (a), we add a 'cpu' field to struct fpsimd_state, which gets updated to
- * the id of the current CPU everytime the state is loaded onto a CPU. For (b),
+ * the id of the current CPU every time the state is loaded onto a CPU. For (b),
  * we add the per-cpu variable 'fpsimd_last_state' (below), which contains the
  * address of the userland FPSIMD state of the task that was loaded onto the CPU
  * the most recently, or NULL if kernel mode NEON has been performed after that.
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index bcac81e..b67531a 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -292,8 +292,8 @@ static struct notifier_block kgdb_notifier = {
 };
 
 /*
- * kgdb_arch_init - Perform any architecture specific initalization.
- * This function will handle the initalization of any architecture
+ * kgdb_arch_init - Perform any architecture specific initialization.
+ * This function will handle the initialization of any architecture
  * specific callbacks.
  */
 int kgdb_arch_init(void)
diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index 71ef6dc..71c1cf4 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -166,7 +166,7 @@ int copy_siginfo_to_user32(compat_siginfo_t __user *to, const siginfo_t *from)
 #ifdef BUS_MCEERR_AO
 		/*
 		 * Other callers might not initialize the si_lsb field,
-		 * so check explicitely for the right codes here.
+		 * so check explicitly for the right codes here.
 		 */
 		if (from->si_signo == SIGBUS &&
 		    (from->si_code == BUS_MCEERR_AR || from->si_code == BUS_MCEERR_AO))
diff --git a/arch/arm64/lib/memcmp.S b/arch/arm64/lib/memcmp.S
index ffbdec0..f9903d0 100644
--- a/arch/arm64/lib/memcmp.S
+++ b/arch/arm64/lib/memcmp.S
@@ -211,7 +211,7 @@ CPU_LE( lsr	tmp2, tmp2, tmp1 )
 .Lunequal_proc:
 	cbz	diff, .Lremain8
 
-/*There is differnence occured in the latest comparison.*/
+/*There is difference occurred in the latest comparison.*/
 .Lnot_limit:
 /*
 * For little endian,reverse the low significant equal bits into MSB,then
-- 
2.7.0.rc3.207.g0ac5344



From maxime.ripard at free-electrons.com  Wed Feb 24 10:00:59 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Feb 2016 10:00:59 -0800
Subject: [PATCH 28/50] pinctrl: ssbi-mpp: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-29-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-29-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160224180059.GA4736@lukather>

On Wed, Feb 24, 2016 at 06:45:53PM +0530, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration and clean
> the error path.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Maxime Ripard <maxime.ripard at free-electrons.com>
> Cc: Chen-Yu Tsai <wens at csie.org>

Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/7c580f04/attachment.sig>

From ddaney at caviumnetworks.com  Wed Feb 24 10:03:02 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Wed, 24 Feb 2016 10:03:02 -0800
Subject: [PATCH v3] arm64: Add workaround for Cavium erratum 27456
In-Reply-To: <56CDB912.6000300@arm.com>
References: <1456272534-21692-1-git-send-email-ddaney.cavm@gmail.com>
 <20160224134016.GH28310@arm.com> <56CDB912.6000300@arm.com>
Message-ID: <56CDF056.8020408@caviumnetworks.com>

On 02/24/2016 06:07 AM, Marc Zyngier wrote:
> On 24/02/16 13:40, Will Deacon wrote:
>
> [...]
>
>> (and Catalin, if you pick this up, watch out for the conflicts in
>> cpufeature.h)
>
> Yup, that one is about to become a minefield (ARM64_HAS_NO_HW_PREFETCH,
> ARM64_HAS_UAO, ARM64_ALT_PAN_NOT_UAO and ARM64_HAS_VIRT_HOST_EXTN are
> already happily clashing into -next). But hey, the more the merrier! ;-)
>

Would you like me to rebase it to for-next/core ?


David.

> Thanks,
>
> 	M.
>



From will.deacon at arm.com  Wed Feb 24 10:06:26 2016
From: will.deacon at arm.com (Will Deacon)
Date: Wed, 24 Feb 2016 18:06:26 +0000
Subject: [PATCH v3] arm64: Add workaround for Cavium erratum 27456
In-Reply-To: <56CDF056.8020408@caviumnetworks.com>
References: <1456272534-21692-1-git-send-email-ddaney.cavm@gmail.com>
 <20160224134016.GH28310@arm.com> <56CDB912.6000300@arm.com>
 <56CDF056.8020408@caviumnetworks.com>
Message-ID: <20160224180626.GF12471@arm.com>

On Wed, Feb 24, 2016 at 10:03:02AM -0800, David Daney wrote:
> On 02/24/2016 06:07 AM, Marc Zyngier wrote:
> >On 24/02/16 13:40, Will Deacon wrote:
> >
> >[...]
> >
> >>(and Catalin, if you pick this up, watch out for the conflicts in
> >>cpufeature.h)
> >
> >Yup, that one is about to become a minefield (ARM64_HAS_NO_HW_PREFETCH,
> >ARM64_HAS_UAO, ARM64_ALT_PAN_NOT_UAO and ARM64_HAS_VIRT_HOST_EXTN are
> >already happily clashing into -next). But hey, the more the merrier! ;-)
> >
> 
> Would you like me to rebase it to for-next/core ?

I think ARM64_HAS_VIRT_HOST_EXTN is in the KVM tree, so you're probably
best off looking at linux-next and choosing your feature number based on
that, whilst basing the patch on either for-next/core or mainline.

Will


From bjorn.andersson at linaro.org  Wed Feb 24 10:06:37 2016
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Wed, 24 Feb 2016 10:06:37 -0800
Subject: [PATCH 17/50] pinctrl: spmi-gpio: Use devm_pinctrl_register()
 for pinctrl registration
In-Reply-To: <1456319775-3216-18-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-18-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160224180637.GK21240@tuxbot>

On Wed 24 Feb 05:15 PST 2016, Laxman Dewangan wrote:

> Use devm_pinctrl_register() for pin control registration and clean
> the error path.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: "Ivan T. Ivanov" <ivan.ivanov at linaro.org>
> Cc: Lee Jones <lee.jones at linaro.org>
> Cc: Stephen Boyd <sboyd at codeaurora.org>
> Cc: Jonas Gorski <jogo at openwrt.org>
> ---

Reviewed-by Bjorn Andersson <bjorn.andersson at linaro.org>

Regards,
Bjorn

>  drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> index 4e12ded..330e822 100644
> --- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> +++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> @@ -764,14 +764,14 @@ static int pmic_gpio_probe(struct platform_device *pdev)
>  	state->chip.of_gpio_n_cells = 2;
>  	state->chip.can_sleep = false;
>  
> -	state->ctrl = pinctrl_register(pctrldesc, dev, state);
> +	state->ctrl = devm_pinctrl_register(dev, pctrldesc, state);
>  	if (IS_ERR(state->ctrl))
>  		return PTR_ERR(state->ctrl);
>  
>  	ret = gpiochip_add_data(&state->chip, state);
>  	if (ret) {
>  		dev_err(state->dev, "can't add gpio chip\n");
> -		goto err_chip;
> +		return ret;
>  	}
>  
>  	ret = gpiochip_add_pin_range(&state->chip, dev_name(dev), 0, 0, npins);
> @@ -784,8 +784,6 @@ static int pmic_gpio_probe(struct platform_device *pdev)
>  
>  err_range:
>  	gpiochip_remove(&state->chip);
> -err_chip:
> -	pinctrl_unregister(state->ctrl);
>  	return ret;
>  }
>  
> @@ -794,7 +792,6 @@ static int pmic_gpio_remove(struct platform_device *pdev)
>  	struct pmic_gpio_state *state = platform_get_drvdata(pdev);
>  
>  	gpiochip_remove(&state->chip);
> -	pinctrl_unregister(state->ctrl);
>  	return 0;
>  }
>  
> -- 
> 2.1.4
> 


From paul at pwsan.com  Wed Feb 24 10:07:17 2016
From: paul at pwsan.com (Paul Walmsley)
Date: Wed, 24 Feb 2016 18:07:17 +0000 (UTC)
Subject: [PATCH v4 1/3] ARM: hwmod: RTC: Add lock and unlock functions
In-Reply-To: <56CD77FC.8030103@ti.com>
References: <1454650952-20154-1-git-send-email-lokeshvutla@ti.com>
 <1454650952-20154-2-git-send-email-lokeshvutla@ti.com>
 <alpine.DEB.2.02.1602072209460.2182@utopia.booyaka.com>
 <56CD77FC.8030103@ti.com>
Message-ID: <alpine.DEB.2.02.1602241805470.26779@utopia.booyaka.com>

Lokesh,

On Wed, 24 Feb 2016, Lokesh Vutla wrote:

> On Monday 08 February 2016 03:54 AM, Paul Walmsley wrote:
> > On Fri, 5 Feb 2016, Lokesh Vutla wrote:
> > 
> >> RTC IP have kicker feature which prevents spurious writes to its registers.
> >> In order to write into any of the RTC registers, KICK values has to be
> >> written to KICK registers.
> >> Introduce omap_hwmod_rtc_unlock/lock functions, which  writes into these
> >> KICK registers inorder to lock and unlock RTC registers.
> >>
> >> Signed-off-by: Lokesh Vutla <lokeshvutla at ti.com>
> >> ---
> > 
> > ...
> > 
> >> +/**
> >> + * omap_rtc_wait_not_busy - Wait for the RTC BUSY flag
> >> + * @oh: struct omap_hwmod *
> >> + *
> >> + * For updating certain RTC registers, the MPU must wait
> >> + * for the BUSY status in OMAP_RTC_STATUS_REG to become zero.
> >> + * Once the BUSY status is zero, there is a 15-?s access
> > 
> > Probably best just to write out "microseconds" or "us" here to avoid the 
> > high-bit character problem.
> > 
> >> + * period in which the MPU can program.
> >> + */
> >> +static void omap_rtc_wait_not_busy(struct omap_hwmod *oh)
> >> +{
> >> +	int i;
> >> +
> >> +	/* BUSY may stay active for 1/32768 second (~30 usec) */
> >> +	omap_test_timeout(omap_hwmod_read(oh, OMAP_RTC_STATUS_REG)
> >> +			  & OMAP_RTC_STATUS_REG, OMAP_RTC_MAX_READY_TIME, i);
> > 
> > This test looks bogus.  Shouldn't it AND the register value with 
> > OMAP_RTC_STATUS_BUSY?  Right now the code is AND-ing with 0x44, which 
> > doesn't include the BUSY bit.  So I guess the tests that you mentioned in 
> > the first message of the series don't cover the BUSY case?
> > 
> >> +	/* now we have ~15 usec to read/write various registers */
> >> +}
> >> +
> >> +/**
> >> + * omap_hwmod_rtc_unlock - Unlock the Kicker mechanism.
> >> + * @oh: struct omap_hwmod *
> >> + *
> >> + * RTC IP have kicker feature. This prevents spurious writes to its registers.
> >> + * In order to write into any of the RTC registers, KICK values has te be
> >> + * written in respective KICK registers. This is needed for hwmod to write into
> >> + * sysconfig register.
> >> + */
> >> +void omap_hwmod_rtc_unlock(struct omap_hwmod *oh)
> >> +{
> >> +	local_irq_disable();
> >> +	omap_rtc_wait_not_busy(oh);
> >> +	omap_hwmod_write(OMAP_RTC_KICK0_VALUE, oh, OMAP_RTC_KICK0_REG);
> >> +	omap_hwmod_write(OMAP_RTC_KICK1_VALUE, oh, OMAP_RTC_KICK1_REG);
> >> +	local_irq_enable();
> > 
> > Finally, could you ask the IP block maintainer to confirm the 
> > interpretation that, for any STATUS_REG read where the BUSY bit is 0, that 
> > we are guaranteed to have at least 15 microseconds from that point in time 
> > to access the IP block?  It appears to be this way from my reading of the 
> > TRM; but to me, the phrasing is not explicit.  Another interpretation 
> > could be that the BUSY bit reflects the IP block's current status.  If 
> > this latter case is true, then to ensure that the IP block accesses 
> > complete inside the access window, we'll either need to test the BUSY bit 
> > after the writes to ensure that it is still 0, and otherwise repeat the 
> > busy test and writes; or we'll need to wait for a 0->1 BUSY transition 
> > before we wait for a 1->0 BUSY transition.
> 
> As per the HW folks, once SW sees the transistion from 1->0, it is
> guaranteed that SW has 15.25 us to do all the write transactions for all
> the TC updates.

Great

> Also as per TRM, in RTC there are three types of registers:
> -> TC registers and TC alarm registers:
> -> General registers
> -> Compensation registers.
> 
> MPU must wait for the BUSY bit for accessing the TC registers and  MPU
> can access the general registers at any point of time. SYSCONFIG, KICK
> registers comes under general registers. Since hwmod modifies only the
> sysconfig register, this omap_rtc_wait_not_busy() is not required here.
> We can directly write into sysconfig and KICK registers. Does this sound
> fine to you?
> Shall I resend this patch without omap_rtc_wait_not_busy()?

If there's no need for the unlock/lock sequence to ensure that the IP 
block is completely reset, then there doesn't seem to be much point in 
including it?  


- Paul


From bjorn.andersson at linaro.org  Wed Feb 24 10:07:27 2016
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Wed, 24 Feb 2016 10:07:27 -0800
Subject: [PATCH 18/50] pinctrl: spmi: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-19-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-19-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160224180727.GL21240@tuxbot>

On Wed 24 Feb 05:15 PST 2016, Laxman Dewangan wrote:

> Use devm_pinctrl_register() for pin control registration and clean
> the error path.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Ivan T. Ivanov <ivan.ivanov at linaro.org>
> Cc: Lee Jones <lee.jones at linaro.org>
> Cc: Stephen Boyd <sboyd at codeaurora.org>
> Cc: Jonas Gorski <jogo at openwrt.org>

Reviewed-by: Bjorn Andersson <bjorn.anderss at linaro.org>

Regards,
Bjorn

> ---
>  drivers/pinctrl/qcom/pinctrl-spmi-mpp.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
> index 2a3e549..418367e 100644
> --- a/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
> +++ b/drivers/pinctrl/qcom/pinctrl-spmi-mpp.c
> @@ -877,14 +877,14 @@ static int pmic_mpp_probe(struct platform_device *pdev)
>  	state->chip.of_gpio_n_cells = 2;
>  	state->chip.can_sleep = false;
>  
> -	state->ctrl = pinctrl_register(pctrldesc, dev, state);
> +	state->ctrl = devm_pinctrl_register(dev, pctrldesc, state);
>  	if (IS_ERR(state->ctrl))
>  		return PTR_ERR(state->ctrl);
>  
>  	ret = gpiochip_add_data(&state->chip, state);
>  	if (ret) {
>  		dev_err(state->dev, "can't add gpio chip\n");
> -		goto err_chip;
> +		return ret;
>  	}
>  
>  	ret = gpiochip_add_pin_range(&state->chip, dev_name(dev), 0, 0, npins);
> @@ -897,8 +897,6 @@ static int pmic_mpp_probe(struct platform_device *pdev)
>  
>  err_range:
>  	gpiochip_remove(&state->chip);
> -err_chip:
> -	pinctrl_unregister(state->ctrl);
>  	return ret;
>  }
>  
> @@ -907,7 +905,6 @@ static int pmic_mpp_remove(struct platform_device *pdev)
>  	struct pmic_mpp_state *state = platform_get_drvdata(pdev);
>  
>  	gpiochip_remove(&state->chip);
> -	pinctrl_unregister(state->ctrl);
>  	return 0;
>  }
>  
> -- 
> 2.1.4
> 


From ddaney at caviumnetworks.com  Wed Feb 24 10:07:44 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Wed, 24 Feb 2016 10:07:44 -0800
Subject: [PATCH v3] arm64: Add workaround for Cavium erratum 27456
In-Reply-To: <20160224180626.GF12471@arm.com>
References: <1456272534-21692-1-git-send-email-ddaney.cavm@gmail.com>
 <20160224134016.GH28310@arm.com> <56CDB912.6000300@arm.com>
 <56CDF056.8020408@caviumnetworks.com> <20160224180626.GF12471@arm.com>
Message-ID: <56CDF170.30509@caviumnetworks.com>

On 02/24/2016 10:06 AM, Will Deacon wrote:
> On Wed, Feb 24, 2016 at 10:03:02AM -0800, David Daney wrote:
>> On 02/24/2016 06:07 AM, Marc Zyngier wrote:
>>> On 24/02/16 13:40, Will Deacon wrote:
>>>
>>> [...]
>>>
>>>> (and Catalin, if you pick this up, watch out for the conflicts in
>>>> cpufeature.h)
>>>
>>> Yup, that one is about to become a minefield (ARM64_HAS_NO_HW_PREFETCH,
>>> ARM64_HAS_UAO, ARM64_ALT_PAN_NOT_UAO and ARM64_HAS_VIRT_HOST_EXTN are
>>> already happily clashing into -next). But hey, the more the merrier! ;-)
>>>
>>
>> Would you like me to rebase it to for-next/core ?
>
> I think ARM64_HAS_VIRT_HOST_EXTN is in the KVM tree, so you're probably
> best off looking at linux-next and choosing your feature number based on
> that, whilst basing the patch on either for-next/core or mainline.
>

OK, I will do that now.

David.

> Will
>



From bjorn.andersson at linaro.org  Wed Feb 24 10:08:41 2016
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Wed, 24 Feb 2016 10:08:41 -0800
Subject: [PATCH 19/50] pinctrl: ssbi-gpi: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-20-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-20-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160224180841.GM21240@tuxbot>

On Wed 24 Feb 05:15 PST 2016, Laxman Dewangan wrote:

> Use devm_pinctrl_register() for pin control registration and clean
> the error path.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Bjorn Andersson <bjorn.andersson at sonymobile.com>
> ---

Reviewed-by: Bjorn Andersson <bjorn.andersson at linaro.org>

Regards,
Bjorn

>  drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c | 9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
> index cd8580d..f71dda6 100644
> --- a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
> +++ b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c
> @@ -729,7 +729,7 @@ static int pm8xxx_gpio_probe(struct platform_device *pdev)
>  	pctrl->desc.custom_conf_items = pm8xxx_conf_items;
>  #endif
>  
> -	pctrl->pctrl = pinctrl_register(&pctrl->desc, &pdev->dev, pctrl);
> +	pctrl->pctrl = devm_pinctrl_register(&pdev->dev, &pctrl->desc, pctrl);
>  	if (IS_ERR(pctrl->pctrl)) {
>  		dev_err(&pdev->dev, "couldn't register pm8xxx gpio driver\n");
>  		return PTR_ERR(pctrl->pctrl);
> @@ -745,7 +745,7 @@ static int pm8xxx_gpio_probe(struct platform_device *pdev)
>  	ret = gpiochip_add_data(&pctrl->chip, pctrl);
>  	if (ret) {
>  		dev_err(&pdev->dev, "failed register gpiochip\n");
> -		goto unregister_pinctrl;
> +		return ret;
>  	}
>  
>  	ret = gpiochip_add_pin_range(&pctrl->chip,
> @@ -765,9 +765,6 @@ static int pm8xxx_gpio_probe(struct platform_device *pdev)
>  unregister_gpiochip:
>  	gpiochip_remove(&pctrl->chip);
>  
> -unregister_pinctrl:
> -	pinctrl_unregister(pctrl->pctrl);
> -
>  	return ret;
>  }
>  
> @@ -777,8 +774,6 @@ static int pm8xxx_gpio_remove(struct platform_device *pdev)
>  
>  	gpiochip_remove(&pctrl->chip);
>  
> -	pinctrl_unregister(pctrl->pctrl);
> -
>  	return 0;
>  }
>  
> -- 
> 2.1.4
> 


From bjorn.andersson at linaro.org  Wed Feb 24 10:09:13 2016
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Wed, 24 Feb 2016 10:09:13 -0800
Subject: [PATCH 20/50] pinctrl: ssbi-mpp: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-21-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-21-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160224180913.GN21240@tuxbot>

On Wed 24 Feb 05:15 PST 2016, Laxman Dewangan wrote:

> Use devm_pinctrl_register() for pin control registration and clean
> the error path.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Bjorn Andersson <bjorn.andersson at sonymobile.com>
> ---

Reviewed-by: Bjorn Andersson <bjorn.andersson at linaro.org>

Regards,
Bjorn

>  drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c | 9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c b/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
> index 54a5402..49cc734 100644
> --- a/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
> +++ b/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
> @@ -820,7 +820,7 @@ static int pm8xxx_mpp_probe(struct platform_device *pdev)
>  	pctrl->desc.custom_conf_items = pm8xxx_conf_items;
>  #endif
>  
> -	pctrl->pctrl = pinctrl_register(&pctrl->desc, &pdev->dev, pctrl);
> +	pctrl->pctrl = devm_pinctrl_register(&pdev->dev, &pctrl->desc, pctrl);
>  	if (IS_ERR(pctrl->pctrl)) {
>  		dev_err(&pdev->dev, "couldn't register pm8xxx mpp driver\n");
>  		return PTR_ERR(pctrl->pctrl);
> @@ -836,7 +836,7 @@ static int pm8xxx_mpp_probe(struct platform_device *pdev)
>  	ret = gpiochip_add_data(&pctrl->chip, pctrl);
>  	if (ret) {
>  		dev_err(&pdev->dev, "failed register gpiochip\n");
> -		goto unregister_pinctrl;
> +		return ret;
>  	}
>  
>  	ret = gpiochip_add_pin_range(&pctrl->chip,
> @@ -856,9 +856,6 @@ static int pm8xxx_mpp_probe(struct platform_device *pdev)
>  unregister_gpiochip:
>  	gpiochip_remove(&pctrl->chip);
>  
> -unregister_pinctrl:
> -	pinctrl_unregister(pctrl->pctrl);
> -
>  	return ret;
>  }
>  
> @@ -868,8 +865,6 @@ static int pm8xxx_mpp_remove(struct platform_device *pdev)
>  
>  	gpiochip_remove(&pctrl->chip);
>  
> -	pinctrl_unregister(pctrl->pctrl);
> -
>  	return 0;
>  }
>  
> -- 
> 2.1.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From bjorn.andersson at linaro.org  Wed Feb 24 10:11:09 2016
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Wed, 24 Feb 2016 10:11:09 -0800
Subject: [PATCH 21/50] pinctrl: msm: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-22-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-22-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160224181109.GO21240@tuxbot>

On Wed 24 Feb 05:15 PST 2016, Laxman Dewangan wrote:

> Use devm_pinctrl_register() for pin control registration and clean
> the error path.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Bjorn Andersson <bjorn.andersson at sonymobile.com>
> Cc: Thomas Gleixner <tglx at linutronix.de>
> Cc: Lee Jones <lee.jones at linaro.org>
> Cc: Stephen Boyd <sboyd at codeaurora.org>
> ---

Reviewed-by: Bjorn Andersson <bjorn.andersson at linaro.org>

Regards,
Bjorn

>  drivers/pinctrl/qcom/pinctrl-msm.c | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
> index 8777cf0..dc7bf77 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -898,17 +898,16 @@ int msm_pinctrl_probe(struct platform_device *pdev,
>  	msm_pinctrl_desc.name = dev_name(&pdev->dev);
>  	msm_pinctrl_desc.pins = pctrl->soc->pins;
>  	msm_pinctrl_desc.npins = pctrl->soc->npins;
> -	pctrl->pctrl = pinctrl_register(&msm_pinctrl_desc, &pdev->dev, pctrl);
> +	pctrl->pctrl = devm_pinctrl_register(&pdev->dev, &msm_pinctrl_desc,
> +					     pctrl);
>  	if (IS_ERR(pctrl->pctrl)) {
>  		dev_err(&pdev->dev, "Couldn't register pinctrl driver\n");
>  		return PTR_ERR(pctrl->pctrl);
>  	}
>  
>  	ret = msm_gpio_init(pctrl);
> -	if (ret) {
> -		pinctrl_unregister(pctrl->pctrl);
> +	if (ret)
>  		return ret;
> -	}
>  
>  	platform_set_drvdata(pdev, pctrl);
>  
> @@ -923,7 +922,6 @@ int msm_pinctrl_remove(struct platform_device *pdev)
>  	struct msm_pinctrl *pctrl = platform_get_drvdata(pdev);
>  
>  	gpiochip_remove(&pctrl->chip);
> -	pinctrl_unregister(pctrl->pctrl);
>  
>  	unregister_restart_handler(&pctrl->restart_nb);
>  
> -- 
> 2.1.4
> 


From sre at kernel.org  Wed Feb 24 10:17:27 2016
From: sre at kernel.org (Sebastian Reichel)
Date: Wed, 24 Feb 2016 19:17:27 +0100
Subject: [PATCH v9 0/2] power: act8945a: add charger driver for the
 sub-device of ACT8945A MFD
In-Reply-To: <B256D81BAE5131468A838E5D7A243641D6428FF2@penmbx01>
References: <1455524524-9359-1-git-send-email-wenyou.yang@atmel.com>
 <B256D81BAE5131468A838E5D7A243641D6428FF2@penmbx01>
Message-ID: <20160224181727.GA19106@earth>

Hi,

On Wed, Feb 24, 2016 at 09:33:13AM +0000, Yang, Wenyou wrote:
> > -----Original Message-----
> > From: Wenyou Yang [mailto:wenyou.yang at atmel.com]
> > Sent: 2016?2?15? 16:22
> > To: Sebastian Reichel <sre at kernel.org>; Dmitry Eremin-Solenikov
> > <dbaryshkov at gmail.com>; David Woodhouse <dwmw2 at infradead.org>; Rob
> > Herring <robh+dt at kernel.org>; Pawel Moll <pawel.moll at arm.com>; Mark Brown
> > <broonie at kernel.org>; Ian Campbell <ijc+devicetree at hellion.org.uk>; Kumar
> > Gala <galak at codeaurora.org>
> > Cc: Krzysztof Kozlowski <k.kozlowski at samsung.com>; Javier Martinez Canillas
> > <javier at dowhile0.org>; Lee Jones <lee.jones at linaro.org>; Peter Korsgaard
> > <jacmet at gmail.com>; Ferre, Nicolas <Nicolas.FERRE at atmel.com>; linux-arm-
> > kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-
> > pm at vger.kernel.org; Yang, Wenyou <Wenyou.Yang at atmel.com>
> > Subject: [PATCH v9 0/2] power: act8945a: add charger driver for the sub-device
> > of ACT8945A MFD
> > 
> > The ACT8945A is a Multi Function Device with the following subdevices:
> >  - Regulator
> >  - Charger
> 
> I would like to know if this patch set is okay to apply.
> Or any comments?

No comments, I just queued it with "|| COMPILE_TEST" dependency
added.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/9d0d7c5a/attachment.sig>

From bjorn.andersson at linaro.org  Wed Feb 24 10:21:16 2016
From: bjorn.andersson at linaro.org (Bjorn Andersson)
Date: Wed, 24 Feb 2016 10:21:16 -0800
Subject: [PATCH 01/50] pinctrl: Add devm_ apis for pinctrl_{register,
 unregister}
In-Reply-To: <1456319775-3216-2-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-2-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160224182116.GP21240@tuxbot>

On Wed 24 Feb 05:15 PST 2016, Laxman Dewangan wrote:

> Add device managed APIs devm_pinctrl_register() and
> devm_pinctrl_unregister() for the APIs pinctrl_register()
> and pinctrl_unregister().
> 
> This helps in reducing code in error path and sometimes
> removal of .remove callback for driver unbind.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> ---
>  drivers/pinctrl/core.c          | 69 +++++++++++++++++++++++++++++++++++++++++
>  include/linux/pinctrl/pinctrl.h |  6 ++++
>  2 files changed, 75 insertions(+)
> 
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
[..]
> +static int devm_pinctrl_dev_match(struct device *dev, void *res, void *data)
> +{
> +	struct pctldev **r = res;
> +
> +	if (!r || !*r) {
> +		WARN_ON(!r || !*r);
> +		return 0;
> +	}

The idiomatic way is to wrap your condition in the WARN_ON; i.e. 

if (WARN_ON(!r || !*r))
	return 0;

> +
> +	return *r == data;
> +}
> +
[..]
> +
> +/**
> + * devm_pinctrl_unregister() - Resource manager of pinctrl_unregister()
> + * @dev: device for which which resource was allocated
> + * @pctldev: the pinctrl device to unregister.
> + */
> +void devm_pinctrl_unregister(struct device *dev, struct pinctrl_dev *pctldev)
> +{
> +	int ret;
> +
> +	ret = devres_release(dev, devm_pinctrl_dev_release,
> +			     devm_pinctrl_dev_match, pctldev);
> +	if (!ret)
> +		WARN_ON(ret);

ret is unlikely to be non-zero in a code path only taken when ret is
zero.

Do either:

WARN_ON(devres_release(...));

rc = devres_release(..);
WARN_ON(rc);

> +}
> +EXPORT_SYMBOL_GPL(devm_pinctrl_unregister);
> +
>  static int __init pinctrl_init(void)
>  {
>  	pr_info("initialized pinctrl subsystem\n");
> diff --git a/include/linux/pinctrl/pinctrl.h b/include/linux/pinctrl/pinctrl.h
> index 9ba59fc..a42e57d 100644
> --- a/include/linux/pinctrl/pinctrl.h
> +++ b/include/linux/pinctrl/pinctrl.h
> @@ -144,6 +144,12 @@ struct pinctrl_desc {
>  extern struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
>  				struct device *dev, void *driver_data);
>  extern void pinctrl_unregister(struct pinctrl_dev *pctldev);
> +extern struct pinctrl_dev *devm_pinctrl_register(struct device *dev,
> +				struct pinctrl_desc *pctldesc,
> +				void *driver_data);
> +extern void devm_pinctrl_unregister(struct device *dev,
> +				struct pinctrl_dev *pctldev);
> +
>  extern bool pin_is_valid(struct pinctrl_dev *pctldev, int pin);
>  extern void pinctrl_add_gpio_range(struct pinctrl_dev *pctldev,
>  				struct pinctrl_gpio_range *range);

Apart from these style issues you have my ack.

Regards,
Bjorn


From mbrugger at suse.com  Wed Feb 24 10:22:12 2016
From: mbrugger at suse.com (Matthias Brugger)
Date: Wed, 24 Feb 2016 19:22:12 +0100
Subject: [PATCH v2 1/8] arm64: move acpi/dt decision earlier in boot
 process
In-Reply-To: <1456333819-13482-2-git-send-email-aleksey.makarov@linaro.org>
References: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
 <1456333819-13482-2-git-send-email-aleksey.makarov@linaro.org>
Message-ID: <56CDF4D4.6000506@suse.com>



On 24/02/16 18:10, Aleksey Makarov wrote:
> From: Leif Lindholm <leif.lindholm at linaro.org>
>
> In order to support selecting earlycon via either ACPI or DT, move
> the decision on whether to attempt ACPI configuration into the
> early_param handling. Then make acpi_boot_table_init() bail out if
> acpi_disabled.
>
> Signed-off-by: Leif Lindholm <leif.lindholm at linaro.org>
> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> ---
>   arch/arm64/kernel/acpi.c | 62 +++++++++++++++++++++++-------------------------
>   1 file changed, 30 insertions(+), 32 deletions(-)
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index d1ce8e2..3faa323 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -41,26 +41,8 @@ EXPORT_SYMBOL(acpi_disabled);
>   int acpi_pci_disabled = 1;	/* skip ACPI PCI scan and IRQ initialization */
>   EXPORT_SYMBOL(acpi_pci_disabled);
>
> -static bool param_acpi_off __initdata;
>   static bool param_acpi_force __initdata;
>
> -static int __init parse_acpi(char *arg)
> -{
> -	if (!arg)
> -		return -EINVAL;
> -
> -	/* "acpi=off" disables both ACPI table parsing and interpreter */
> -	if (strcmp(arg, "off") == 0)
> -		param_acpi_off = true;
> -	else if (strcmp(arg, "force") == 0) /* force ACPI to be enabled */
> -		param_acpi_force = true;
> -	else
> -		return -EINVAL;	/* Core will print when we return error */
> -
> -	return 0;
> -}
> -early_param("acpi", parse_acpi);
> -
>   static int __init dt_scan_depth1_nodes(unsigned long node,
>   				       const char *uname, int depth,
>   				       void *data)
> @@ -74,6 +56,35 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
>   	return 0;
>   }
>
> +static int __init parse_acpi(char *arg)
> +{
> +	if (!arg)
> +		return -EINVAL;
> +
> +	/*
> +	 * Enable ACPI instead of device tree unless
> +	 * - ACPI has been disabled explicitly (acpi=off), or
> +	 * - the device tree is not empty (it has more than just a /chosen node)
> +	 *   and ACPI has not been force enabled (acpi=force)
> +	 */
> +	if (strcmp(arg, "off") == 0)
> +		return 0;
> +	else if (strcmp(arg, "force") == 0)
> +		param_acpi_force = true;
> +	else if (of_scan_flat_dt(dt_scan_depth1_nodes, NULL))

I think we should strcmp for "on" here and return an error on other 
values. IMHO an update to Documentation/kernel-parameters.txt would be 
convenient.

I still wonder if we really want to change the default to ACPI disabled.
But that's a decision the maintainers have to take.

Regards,
Matthias

> +		return 0;
> +
> +	/*
> +	 * ACPI is disabled at this point. Enable it in order to parse
> +	 * the ACPI tables and carry out sanity checks
> +	 */
> +	enable_acpi();
> +
> +	return 0;
> +}
> +
> +early_param("acpi", parse_acpi);
> +
>   /*
>    * __acpi_map_table() will be called before page_init(), so early_ioremap()
>    * or early_memremap() should be called here to for ACPI table mapping.
> @@ -181,23 +192,10 @@ out:
>    */
>   void __init acpi_boot_table_init(void)
>   {
> -	/*
> -	 * Enable ACPI instead of device tree unless
> -	 * - ACPI has been disabled explicitly (acpi=off), or
> -	 * - the device tree is not empty (it has more than just a /chosen node)
> -	 *   and ACPI has not been force enabled (acpi=force)
> -	 */
> -	if (param_acpi_off ||
> -	    (!param_acpi_force && of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
> +	if (acpi_disabled)
>   		return;
>
>   	/*
> -	 * ACPI is disabled at this point. Enable it in order to parse
> -	 * the ACPI tables and carry out sanity checks
> -	 */
> -	enable_acpi();
> -
> -	/*
>   	 * If ACPI tables are initialized and FADT sanity checks passed,
>   	 * leave ACPI enabled and carry on booting; otherwise disable ACPI
>   	 * on initialization error.
>


From ray.jui at broadcom.com  Wed Feb 24 10:25:38 2016
From: ray.jui at broadcom.com (Ray Jui)
Date: Wed, 24 Feb 2016 10:25:38 -0800
Subject: [PATCH 03/50] pinctrl: bcm281xx: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-4-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-4-git-send-email-ldewangan@nvidia.com>
Message-ID: <d5eeb969-8c51-e716-ff21-084feed01183@broadcom.com>



On 2/24/2016 5:15 AM, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration.
>
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Ray Jui <rjui at broadcom.com>
> ---
>  drivers/pinctrl/bcm/pinctrl-bcm281xx.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
> index c3c692e..0c0c0f0 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
> @@ -1422,9 +1422,7 @@ static int __init bcm281xx_pinctrl_probe(struct platform_device *pdev)
>  	bcm281xx_pinctrl_desc.pins = bcm281xx_pinctrl.pins;
>  	bcm281xx_pinctrl_desc.npins = bcm281xx_pinctrl.npins;
>
> -	pctl = pinctrl_register(&bcm281xx_pinctrl_desc,
> -				&pdev->dev,
> -				pdata);
> +	pctl = devm_pinctrl_register(&pdev->dev, &bcm281xx_pinctrl_desc, pdata);
>  	if (IS_ERR(pctl)) {
>  		dev_err(&pdev->dev, "Failed to register pinctrl\n");
>  		return PTR_ERR(pctl);
>

Acked-by: Ray Jui <ray.jui at broadcom.com>

Thanks!

Ray


From ray.jui at broadcom.com  Wed Feb 24 10:27:13 2016
From: ray.jui at broadcom.com (Ray Jui)
Date: Wed, 24 Feb 2016 10:27:13 -0800
Subject: [PATCH 05/50] pinctrl: cygnus-mux: Use devm_pinctrl_register()
 for pinctrl registration
In-Reply-To: <1456319775-3216-6-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-6-git-send-email-ldewangan@nvidia.com>
Message-ID: <f0a27367-6b6d-602d-fd8f-c6b08fe6a1a9@broadcom.com>



On 2/24/2016 5:15 AM, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration.
>
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Ray Jui <rjui at broadcom.com>
> Cc: Scott Branden <sbranden at broadcom.com>
> Cc: Jon Mason <jonmason at broadcom.com>
> ---
>  drivers/pinctrl/bcm/pinctrl-cygnus-mux.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
> index 9728f3d..9382a0a 100644
> --- a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
> +++ b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
> @@ -987,7 +987,7 @@ static int cygnus_pinmux_probe(struct platform_device *pdev)
>  	cygnus_pinctrl_desc.pins = pins;
>  	cygnus_pinctrl_desc.npins = num_pins;
>
> -	pinctrl->pctl = pinctrl_register(&cygnus_pinctrl_desc, &pdev->dev,
> +	pinctrl->pctl = devm_pinctrl_register(&pdev->dev, &cygnus_pinctrl_desc,
>  			pinctrl);
>  	if (IS_ERR(pinctrl->pctl)) {
>  		dev_err(&pdev->dev, "unable to register Cygnus IOMUX pinctrl\n");
>


Acked-by: Ray Jui <ray.jui at broadcom.com>

Thanks!

Ray


From ray.jui at broadcom.com  Wed Feb 24 10:27:59 2016
From: ray.jui at broadcom.com (Ray Jui)
Date: Wed, 24 Feb 2016 10:27:59 -0800
Subject: [PATCH 04/50] pinctrl: bcm2835: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-5-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-5-git-send-email-ldewangan@nvidia.com>
Message-ID: <d3e4a7ae-6c51-1a2f-8344-8f8b2ff3f5ec@broadcom.com>



On 2/24/2016 5:15 AM, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration.
>
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Ray Jui <rjui at broadcom.com>
> ---
>  drivers/pinctrl/bcm/pinctrl-bcm2835.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index 0f5997c..25bc4a2 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> @@ -1027,7 +1027,7 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
>  		return err;
>  	}
>
> -	pc->pctl_dev = pinctrl_register(&bcm2835_pinctrl_desc, dev, pc);
> +	pc->pctl_dev = devm_pinctrl_register(dev, &bcm2835_pinctrl_desc, pc);
>  	if (IS_ERR(pc->pctl_dev)) {
>  		gpiochip_remove(&pc->gpio_chip);
>  		return PTR_ERR(pc->pctl_dev);
> @@ -1045,7 +1045,6 @@ static int bcm2835_pinctrl_remove(struct platform_device *pdev)
>  {
>  	struct bcm2835_pinctrl *pc = platform_get_drvdata(pdev);
>
> -	pinctrl_unregister(pc->pctl_dev);
>  	gpiochip_remove(&pc->gpio_chip);
>
>  	return 0;
>

Reviewed-by: Ray Jui <ray.jui at broadcom.com>

Thanks!

Ray


From javi.merino at arm.com  Wed Feb 24 10:28:57 2016
From: javi.merino at arm.com (Javi Merino)
Date: Wed, 24 Feb 2016 18:28:57 +0000
Subject: [PATCH 3/3] arm64: dts: register Hi6220's thermal zone for power
 allocator
In-Reply-To: <1455983529-9559-4-git-send-email-leo.yan@linaro.org>
References: <1455983529-9559-1-git-send-email-leo.yan@linaro.org>
 <1455983529-9559-4-git-send-email-leo.yan@linaro.org>
Message-ID: <20160224182856.GD3006@e104805>

On Sat, Feb 20, 2016 at 11:52:09PM +0800, Leo Yan wrote:
> With profiling Hi6220's power modeling so get dynamic coefficient and
> sustainable power. So pass these parameters from DT.
> 
> Now enable power allocator wit only one actor for CPU part, so directly
> use cluster0's thermal sensor for monitoring temperature.
> 
> Signed-off-by: Leo Yan <leo.yan at linaro.org>
> ---
>  arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 36 +++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 50ba1b0..3608a3e 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -6,6 +6,7 @@
>  
>  #include <dt-bindings/interrupt-controller/arm-gic.h>
>  #include <dt-bindings/clock/hi6220-clock.h>
> +#include <dt-bindings/thermal/thermal.h>
>  
>  / {
>  	compatible = "hisilicon,hi6220";
> @@ -87,6 +88,7 @@
>  			cooling-max-level = <0>;
>  			#cooling-cells = <2>; /* min followed by max */
>  			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
> +			dynamic-power-coefficient = <311>;
>  		};
>  
>  		cpu1: cpu at 1 {
> @@ -322,5 +324,39 @@
>  			clock-names = "thermal_clk";
>  			#thermal-sensor-cells = <1>;
>  		};
> +
> +		thermal-zones {
> +
> +			cls0: cls0 {
> +				polling-delay = <1000>;
> +				polling-delay-passive = <100>;
> +				sustainable-power = <3326>;
> +
> +				/* sensor ID */
> +				thermal-sensors = <&tsensor 2>;
> +
> +				trips {
> +					threshold: trip-point at 0 {
> +						temperature = <65000>;
> +						hysteresis = <1000>;

As far as I know, hysteresis is ignored in the thermal subsystem right
now, so you could remove it from both trip points.

> +						type = "passive";
> +					};
> +
> +					target: trip-point at 1 {
> +						temperature = <75000>;
> +						hysteresis = <1000>;
> +						type = "passive";
> +					};
> +				};
> +
> +				cooling-maps {
> +					map0 {
> +						trip = <&target>;
> +						contribution = <1024>;

As Hikey has only one voltage domain, you only have one cpu cooling
device.  "contribution" is only useful when you have more than one
cooling device, as it's relative to the other cooling device's
contribution.  You can remove contribution from here.

Other than this minor stuff, it looks good to me. FWIW,

Reviewed-by: Javi Merino <javi.merino at arm.com>

> +						cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> +					};
> +				};
> +			};
> +		};
>  	};
>  };


From ray.jui at broadcom.com  Wed Feb 24 10:29:52 2016
From: ray.jui at broadcom.com (Ray Jui)
Date: Wed, 24 Feb 2016 10:29:52 -0800
Subject: [PATCH 06/50] pinctrl: iproc-gpio: Use devm_pinctrl_register()
 for pinctrl registration
In-Reply-To: <1456319775-3216-7-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-7-git-send-email-ldewangan@nvidia.com>
Message-ID: <fccabf34-d5a7-e176-f8a8-cb9657d36450@broadcom.com>



On 2/24/2016 5:15 AM, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration and clean
> the error path.
>
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Ray Jui <rjui at broadcom.com>
> Cc: Scott Branden <sbranden at broadcom.com>
> Cc: Jon Mason <jonmason at broadcom.com>
> ---
>  drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 12 ++----------
>  1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
> index d530ab4..e753af3 100644
> --- a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
> +++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
> @@ -623,7 +623,7 @@ static int iproc_gpio_register_pinconf(struct iproc_gpio *chip)
>  	pctldesc->npins = gc->ngpio;
>  	pctldesc->confops = &iproc_pconf_ops;
>
> -	chip->pctl = pinctrl_register(pctldesc, chip->dev, chip);
> +	chip->pctl = devm_pinctrl_register(chip->dev, pctldesc, chip);
>  	if (IS_ERR(chip->pctl)) {
>  		dev_err(chip->dev, "unable to register pinctrl device\n");
>  		return PTR_ERR(chip->pctl);
> @@ -632,11 +632,6 @@ static int iproc_gpio_register_pinconf(struct iproc_gpio *chip)
>  	return 0;
>  }
>
> -static void iproc_gpio_unregister_pinconf(struct iproc_gpio *chip)
> -{
> -	pinctrl_unregister(chip->pctl);
> -}
> -
>  static const struct of_device_id iproc_gpio_of_match[] = {
>  	{ .compatible = "brcm,cygnus-ccm-gpio" },
>  	{ .compatible = "brcm,cygnus-asiu-gpio" },
> @@ -720,7 +715,7 @@ static int iproc_gpio_probe(struct platform_device *pdev)
>  					   handle_simple_irq, IRQ_TYPE_NONE);
>  		if (ret) {
>  			dev_err(dev, "no GPIO irqchip\n");
> -			goto err_unregister_pinconf;
> +			goto err_rm_gpiochip;
>  		}
>
>  		gpiochip_set_chained_irqchip(gc, &iproc_gpio_irq_chip, irq,
> @@ -729,9 +724,6 @@ static int iproc_gpio_probe(struct platform_device *pdev)
>
>  	return 0;
>
> -err_unregister_pinconf:
> -	iproc_gpio_unregister_pinconf(chip);
> -
>  err_rm_gpiochip:
>  	gpiochip_remove(gc);
>
>

Acked-by: Ray Jui <ray.jui at broadcom.com>

Thanks!

Ray


From lkp at intel.com  Wed Feb 24 10:28:45 2016
From: lkp at intel.com (kbuild test robot)
Date: Thu, 25 Feb 2016 02:28:45 +0800
Subject: [PATCH 15/50] pinctrl: mvebu: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-16-git-send-email-ldewangan@nvidia.com>
Message-ID: <201602250248.psr4kejZ%fengguang.wu@intel.com>

Hi Laxman,

[auto build test ERROR on pinctrl/for-next]
[also build test ERROR on v4.5-rc5 next-20160224]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Laxman-Dewangan/pinctrl-Add-and-use-devm_-apis-for-pinctrl_-register-unregister/20160225-002237
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git for-next
config: arm-multi_v5_defconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `orion_pinctrl_remove':
>> drivers/pinctrl/mvebu/pinctrl-orion.c:244: undefined reference to `mvebu_pinctrl_remove'

vim +244 drivers/pinctrl/mvebu/pinctrl-orion.c

fd67f884 Thomas Petazzoni 2014-04-22  238  
fd67f884 Thomas Petazzoni 2014-04-22  239  	return mvebu_pinctrl_probe(pdev);
fd67f884 Thomas Petazzoni 2014-04-22  240  }
fd67f884 Thomas Petazzoni 2014-04-22  241  
fd67f884 Thomas Petazzoni 2014-04-22  242  static int orion_pinctrl_remove(struct platform_device *pdev)
fd67f884 Thomas Petazzoni 2014-04-22  243  {
fd67f884 Thomas Petazzoni 2014-04-22 @244  	return mvebu_pinctrl_remove(pdev);
fd67f884 Thomas Petazzoni 2014-04-22  245  }
fd67f884 Thomas Petazzoni 2014-04-22  246  
fd67f884 Thomas Petazzoni 2014-04-22  247  static struct platform_driver orion_pinctrl_driver = {

:::::: The code at line 244 was first introduced by commit
:::::: fd67f884782a281eb033e40b0f8eae623416035e pinctrl: mvebu: new driver for Orion platforms

:::::: TO: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
:::::: CC: Linus Walleij <linus.walleij at linaro.org>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 22481 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/2aca0525/attachment-0001.obj>

From ray.jui at broadcom.com  Wed Feb 24 10:30:34 2016
From: ray.jui at broadcom.com (Ray Jui)
Date: Wed, 24 Feb 2016 10:30:34 -0800
Subject: [PATCH 07/50] pinctrl: nsp-gpio: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-8-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-8-git-send-email-ldewangan@nvidia.com>
Message-ID: <dbd2ae89-1e62-e7d3-58f0-681d26fee2c9@broadcom.com>



On 2/24/2016 5:15 AM, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration.
>
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Ray Jui <rjui at broadcom.com>
> Cc: Scott Branden <sbranden at broadcom.com>
> Cc: Jon Mason <jonmason at broadcom.com>
> ---
>  drivers/pinctrl/bcm/pinctrl-nsp-gpio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c b/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
> index ac90043..2873f73 100644
> --- a/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
> +++ b/drivers/pinctrl/bcm/pinctrl-nsp-gpio.c
> @@ -609,7 +609,7 @@ static int nsp_gpio_register_pinconf(struct nsp_gpio *chip)
>  	pctldesc->npins = gc->ngpio;
>  	pctldesc->confops = &nsp_pconf_ops;
>
> -	chip->pctl = pinctrl_register(pctldesc, chip->dev, chip);
> +	chip->pctl = devm_pinctrl_register(chip->dev, pctldesc, chip);
>  	if (IS_ERR(chip->pctl)) {
>  		dev_err(chip->dev, "unable to register pinctrl device\n");
>  		return PTR_ERR(chip->pctl);
>

Acked-by: Ray Jui <ray.jui at broadcom.com>

Thanks!

Ray


From ynorov at caviumnetworks.com  Wed Feb 24 10:34:09 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Wed, 24 Feb 2016 21:34:09 +0300
Subject: [PATCH v2 0/5] all: s390: make compat wrappers the generic solution
Message-ID: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>

The problem that makes us use wrappers is that some compat
architectures allows user code to access top halves of registers.
This is not a problem for syscalls that are already handled by compat
code, or for that who has types of the same size in kernel and
userspace. In case of s390 and lp64/ilp32 the problem is in pointer
types, long, unsigned long.

S390 folks already have the solution for it. In this patchset,
it is turned to be general, as arm64/ilp32 needs it too.

This patchset is created as the part of the work of enabling arm64
with ILP32 user mode. See details here:
http://thread.gmane.org/gmane.linux.kernel/2126946

This is the implementation of one of two possible approaches. First
one defines new syscall handler declaration macro, that creates both compat and
non-compat handlers, see [1]. This one declares all wrappers in separated file
kernel/compat_wrapper.c

Build-tested on s390.

[1] http://www.spinics.net/lists/linux-s390/msg11593.html

Yury Norov (5):
  all: syscall wrappers: add documentation
  all: introduce COMPAT_WRAPPER option and enable it for s390
  all: s390: move wrapper infrastructure to generic headers
  all: s390: move compat_wrappers.c from arch/s390/kernel to kernel/
  all: wrap needed syscalls in generic unistd

 Documentation/adding-syscalls.txt |  32 +++++
 arch/Kconfig                      |   4 +
 arch/s390/Kconfig                 |   1 +
 arch/s390/include/asm/compat.h    |  17 ++-
 arch/s390/kernel/Makefile         |   2 +-
 arch/s390/kernel/compat_wrapper.c | 180 ------------------------
 include/linux/compat.h            | 278 ++++++++++++++++++++++++++++++++++++++
 include/linux/syscalls.h          |  57 +-------
 include/linux/syscalls_structs.h  |  60 ++++++++
 include/uapi/asm-generic/unistd.h | 231 +++++++++++++++----------------
 kernel/Makefile                   |   1 +
 kernel/compat_wrapper.c           | 170 +++++++++++++++++++++++
 12 files changed, 680 insertions(+), 353 deletions(-)
 delete mode 100644 arch/s390/kernel/compat_wrapper.c
 create mode 100644 include/linux/syscalls_structs.h
 create mode 100644 kernel/compat_wrapper.c

-- 
2.5.0



From ynorov at caviumnetworks.com  Wed Feb 24 10:34:10 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Wed, 24 Feb 2016 21:34:10 +0300
Subject: [PATCH 1/5] all: syscall wrappers: add documentation
In-Reply-To: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
References: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
Message-ID: <1456338854-14901-2-git-send-email-ynorov@caviumnetworks.com>

Signed-off-by: Yury Norov <ynorov at caviumnetworks.com>
---
 Documentation/adding-syscalls.txt | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/Documentation/adding-syscalls.txt b/Documentation/adding-syscalls.txt
index cc2d4ac..1db880c 100644
--- a/Documentation/adding-syscalls.txt
+++ b/Documentation/adding-syscalls.txt
@@ -341,6 +341,38 @@ To summarize, you need:
  - instance of __SC_COMP not __SYSCALL in include/uapi/asm-generic/unistd.h
 
 
+Compatibility System Calls Wrappers
+--------------------------------
+
+Some architectures prevent 32-bit userspace from access to top halves of 64-bit
+registers, but some not. It's not a problem if specific argument is the same
+size in kernel and userspace. It also is not a problem if system call is already
+handled by compatible routine. Otherwise we'd take care of it. Usually, glibc
+and compiler handles register's top halve, but from kernel side, we cannot rely
+on it, as malicious code may cause incorrect behaviour and/or security
+vulnerabilities.
+
+For now, only s390 and arm64/ilp32 are affected.
+
+To clear that top halves, automatic wrappers are introduced. They clear all
+required registers before passing control to regular syscall handler.
+
+If your architecture allows userspace code to access top halves of register,
+you need to:
+ - enable COMPAT_WRAPPER in configuration file;
+ - declare: "#define __SC_WRAP(nr, sym) [nr] = compat_##sym,", just before
+   compatible syscall table declaration, if you use generic unistd; or
+ - declare compat wrappers manually, if you use non-generic syscall table.
+   The list of unsafe syscalls is in kernel/compat_wrapper.
+
+If you write new syscall, make sure, its arguments are the same size in both
+64- and 32-bits modes. If no, and if there's no explicit compat version for
+syscall handler, you need to:
+ - declare compat version prototype in 'include/linux/compat.h';
+ - in 'include/uapi/asm-generic/unistd.h' declare syscall with macro '__SC_WRAP'
+   instead of '__SYSCALL';
+ - add corresponding line to 'kernel/compat_wrapper.c' to let it generate wrapper.
+
 Compatibility System Calls (x86)
 --------------------------------
 
-- 
2.5.0



From ynorov at caviumnetworks.com  Wed Feb 24 10:34:11 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Wed, 24 Feb 2016 21:34:11 +0300
Subject: [PATCH 2/5] all: introduce COMPAT_WRAPPER option and enable it for
 s390
In-Reply-To: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
References: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
Message-ID: <1456338854-14901-3-git-send-email-ynorov@caviumnetworks.com>

Signed-off-by: Yury Norov <ynorov at caviumnetworks.com>
---
 arch/Kconfig      | 4 ++++
 arch/s390/Kconfig | 1 +
 2 files changed, 5 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index f6b649d..6393093 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -583,6 +583,10 @@ config HAVE_COPY_THREAD_TLS
 	  normal C parameter passing, rather than extracting the syscall
 	  argument from pt_regs.
 
+config COMPAT_WRAPPER
+	bool
+	depends on COMPAT
+
 #
 # ABI hall of shame
 #
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 3be9c83..082b861 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -333,6 +333,7 @@ config COMPAT
 	select COMPAT_BINFMT_ELF if BINFMT_ELF
 	select ARCH_WANT_OLD_COMPAT_IPC
 	select COMPAT_OLD_SIGACTION
+	select COMPAT_WRAPPER
 	depends on MULTIUSER
 	help
 	  Select this option if you want to enable your system kernel to
-- 
2.5.0



From ynorov at caviumnetworks.com  Wed Feb 24 10:34:12 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Wed, 24 Feb 2016 21:34:12 +0300
Subject: [PATCH 3/5] all: s390: move wrapper infrastructure to generic headers
In-Reply-To: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
References: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
Message-ID: <1456338854-14901-4-git-send-email-ynorov@caviumnetworks.com>

__SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so it's
moved to arch/s390/include/asm/compat.h. Generic declaration assumes that long,
unsigned long and pointer types are all 32-bit length.

linux/syscalls_structs.h header is introduced, because from now (see next patch)
structure types listed there are needed for both normal and compat mode.

cond_syscall_wrapped now defined two symbols: sys_foo() and compat_sys_foo(), if
compat wrappers are enabled.

Here __SC_WRAP() macro is introduced as well. s390 doesn't need it as it uses
asm-generated syscall table. But architectures that generate that tables with
C code (ARM64/ILP32) should redefine it as '#define __SC_WRAP(name) compat_##name'.

Signed-off-by: Yury Norov <ynorov at caviumnetworks.com>
---
 arch/s390/include/asm/compat.h    | 17 +++++++++--
 arch/s390/kernel/compat_wrapper.c | 51 ---------------------------------
 include/linux/compat.h            | 53 ++++++++++++++++++++++++++++++++++
 include/linux/syscalls.h          | 57 +------------------------------------
 include/linux/syscalls_structs.h  | 60 +++++++++++++++++++++++++++++++++++++++
 include/uapi/asm-generic/unistd.h |  4 +++
 6 files changed, 133 insertions(+), 109 deletions(-)
 create mode 100644 include/linux/syscalls_structs.h

diff --git a/arch/s390/include/asm/compat.h b/arch/s390/include/asm/compat.h
index 352f7bd..f412723 100644
--- a/arch/s390/include/asm/compat.h
+++ b/arch/s390/include/asm/compat.h
@@ -7,13 +7,26 @@
 #include <linux/sched.h>
 #include <linux/thread_info.h>
 
-#define __TYPE_IS_PTR(t) (!__builtin_types_compatible_p(typeof(0?(t)0:0ULL), u64))
-
 #define __SC_DELOUSE(t,v) ({ \
 	BUILD_BUG_ON(sizeof(t) > 4 && !__TYPE_IS_PTR(t)); \
 	(t)(__TYPE_IS_PTR(t) ? ((v) & 0x7fffffff) : (v)); \
 })
 
+#define __SC_COMPAT_CAST(t, a)						\
+({									\
+	long __ReS = a;							\
+									\
+	BUILD_BUG_ON((sizeof(t) > 4) && !__TYPE_IS_L(t) &&		\
+		     !__TYPE_IS_UL(t) && !__TYPE_IS_PTR(t));		\
+	if (__TYPE_IS_L(t))						\
+		__ReS = (s32)a;						\
+	if (__TYPE_IS_UL(t))						\
+		__ReS = (u32)a;						\
+	if (__TYPE_IS_PTR(t))						\
+		__ReS = a & 0x7fffffff;					\
+	(t)__ReS;							\
+})
+
 #define PSW32_MASK_PER		0x40000000UL
 #define PSW32_MASK_DAT		0x04000000UL
 #define PSW32_MASK_IO		0x02000000UL
diff --git a/arch/s390/kernel/compat_wrapper.c b/arch/s390/kernel/compat_wrapper.c
index ae2cda5..1614e15 100644
--- a/arch/s390/kernel/compat_wrapper.c
+++ b/arch/s390/kernel/compat_wrapper.c
@@ -8,57 +8,6 @@
 #include <linux/compat.h>
 #include "entry.h"
 
-#define COMPAT_SYSCALL_WRAP1(name, ...) \
-	COMPAT_SYSCALL_WRAPx(1, _##name, __VA_ARGS__)
-#define COMPAT_SYSCALL_WRAP2(name, ...) \
-	COMPAT_SYSCALL_WRAPx(2, _##name, __VA_ARGS__)
-#define COMPAT_SYSCALL_WRAP3(name, ...) \
-	COMPAT_SYSCALL_WRAPx(3, _##name, __VA_ARGS__)
-#define COMPAT_SYSCALL_WRAP4(name, ...) \
-	COMPAT_SYSCALL_WRAPx(4, _##name, __VA_ARGS__)
-#define COMPAT_SYSCALL_WRAP5(name, ...) \
-	COMPAT_SYSCALL_WRAPx(5, _##name, __VA_ARGS__)
-#define COMPAT_SYSCALL_WRAP6(name, ...) \
-	COMPAT_SYSCALL_WRAPx(6, _##name, __VA_ARGS__)
-
-#define __SC_COMPAT_TYPE(t, a) \
-	__typeof(__builtin_choose_expr(sizeof(t) > 4, 0L, (t)0)) a
-
-#define __SC_COMPAT_CAST(t, a)						\
-({									\
-	long __ReS = a;							\
-									\
-	BUILD_BUG_ON((sizeof(t) > 4) && !__TYPE_IS_L(t) &&		\
-		     !__TYPE_IS_UL(t) && !__TYPE_IS_PTR(t));		\
-	if (__TYPE_IS_L(t))						\
-		__ReS = (s32)a;						\
-	if (__TYPE_IS_UL(t))						\
-		__ReS = (u32)a;						\
-	if (__TYPE_IS_PTR(t))						\
-		__ReS = a & 0x7fffffff;					\
-	(t)__ReS;							\
-})
-
-/*
- * The COMPAT_SYSCALL_WRAP macro generates system call wrappers to be used by
- * compat tasks. These wrappers will only be used for system calls where only
- * the system call arguments need sign or zero extension or zeroing of the upper
- * 33 bits of pointers.
- * Note: since the wrapper function will afterwards call a system call which
- * again performs zero and sign extension for all system call arguments with
- * a size of less than eight bytes, these compat wrappers only touch those
- * system call arguments with a size of eight bytes ((unsigned) long and
- * pointers). Zero and sign extension for e.g. int parameters will be done by
- * the regular system call wrappers.
- */
-#define COMPAT_SYSCALL_WRAPx(x, name, ...)					\
-asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));			\
-asmlinkage long notrace compat_sys##name(__MAP(x,__SC_COMPAT_TYPE,__VA_ARGS__));\
-asmlinkage long notrace compat_sys##name(__MAP(x,__SC_COMPAT_TYPE,__VA_ARGS__))	\
-{										\
-	return sys##name(__MAP(x,__SC_COMPAT_CAST,__VA_ARGS__));		\
-}
-
 COMPAT_SYSCALL_WRAP2(creat, const char __user *, pathname, umode_t, mode);
 COMPAT_SYSCALL_WRAP2(link, const char __user *, oldname, const char __user *, newname);
 COMPAT_SYSCALL_WRAP1(unlink, const char __user *, pathname);
diff --git a/include/linux/compat.h b/include/linux/compat.h
index a76c917..243b656 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -28,6 +28,10 @@
 #define __SC_DELOUSE(t,v) ((t)(unsigned long)(v))
 #endif
 
+#ifndef __TYPE_IS_PTR
+#define __TYPE_IS_PTR(t) (!__builtin_types_compatible_p(typeof(0?(t)0:0ULL), u64))
+#endif
+
 #define COMPAT_SYSCALL_DEFINE0(name) \
 	asmlinkage long compat_sys_##name(void)
 
@@ -718,4 +722,53 @@ asmlinkage long compat_sys_fanotify_mark(int, unsigned int, __u32, __u32,
 #define is_compat_task() (0)
 
 #endif /* CONFIG_COMPAT */
+
+#ifdef CONFIG_COMPAT_WRAPPER
+
+#define COMPAT_SYSCALL_WRAP1(name, ...) COMPAT_SYSCALL_WRAPx(1, _##name, __VA_ARGS__)
+#define COMPAT_SYSCALL_WRAP2(name, ...) COMPAT_SYSCALL_WRAPx(2, _##name, __VA_ARGS__)
+#define COMPAT_SYSCALL_WRAP3(name, ...) COMPAT_SYSCALL_WRAPx(3, _##name, __VA_ARGS__)
+#define COMPAT_SYSCALL_WRAP4(name, ...) COMPAT_SYSCALL_WRAPx(4, _##name, __VA_ARGS__)
+#define COMPAT_SYSCALL_WRAP5(name, ...) COMPAT_SYSCALL_WRAPx(5, _##name, __VA_ARGS__)
+#define COMPAT_SYSCALL_WRAP6(name, ...) COMPAT_SYSCALL_WRAPx(6, _##name, __VA_ARGS__)
+
+#ifndef __SC_COMPAT_TYPE
+#define __SC_COMPAT_TYPE(t, a) \
+	__typeof(__builtin_choose_expr(sizeof(t) > 4, 0L, (t)0)) a
+#endif
+
+#ifndef __SC_COMPAT_CAST
+#define __SC_COMPAT_CAST(t, a) ({					\
+	BUILD_BUG_ON((sizeof(t) > 4) && !__TYPE_IS_L(t) &&		\
+		     !__TYPE_IS_UL(t) && !__TYPE_IS_PTR(t));		\
+	((t) ((t)(-1) < 0 ? (s64)(s32)(a) : (u64)(u32)(a)));		\
+})
+#endif
+
+#ifndef COMPAT_SYSCALL_WRAPx
+/*
+ * The COMPAT_SYSCALL_WRAP macro generates system call wrappers to be used by
+ * compat tasks. These wrappers will only be used for system calls where only
+ * the system call arguments need sign or zero extension or zeroing of the upper
+ * 33 bits of pointers.
+ * Note: since the wrapper function will afterwards call a system call which
+ * again performs zero and sign extension for all system call arguments with
+ * a size of less than eight bytes, these compat wrappers only touch those
+ * system call arguments with a size of eight bytes ((unsigned) long and
+ * pointers). Zero and sign extension for e.g. int parameters will be done by
+ * the regular system call wrappers.
+ */
+#define COMPAT_SYSCALL_WRAPx(x, name, ...)						\
+asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));				\
+asmlinkage long compat_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))			\
+		__attribute__((alias(__stringify(compat_SyS##name))));			\
+asmlinkage long notrace compat_SyS##name(__MAP(x,__SC_COMPAT_TYPE,__VA_ARGS__));	\
+asmlinkage long notrace compat_SyS##name(__MAP(x,__SC_COMPAT_TYPE,__VA_ARGS__))		\
+{											\
+	return sys##name(__MAP(x,__SC_COMPAT_CAST,__VA_ARGS__));			\
+}
+#endif
+
+#endif /* CONFIG_COMPAT_WRAPPER */
+
 #endif /* _LINUX_COMPAT_H */
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 185815c..2875b13 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -11,62 +11,7 @@
 #ifndef _LINUX_SYSCALLS_H
 #define _LINUX_SYSCALLS_H
 
-struct epoll_event;
-struct iattr;
-struct inode;
-struct iocb;
-struct io_event;
-struct iovec;
-struct itimerspec;
-struct itimerval;
-struct kexec_segment;
-struct linux_dirent;
-struct linux_dirent64;
-struct list_head;
-struct mmap_arg_struct;
-struct msgbuf;
-struct user_msghdr;
-struct mmsghdr;
-struct msqid_ds;
-struct new_utsname;
-struct nfsctl_arg;
-struct __old_kernel_stat;
-struct oldold_utsname;
-struct old_utsname;
-struct pollfd;
-struct rlimit;
-struct rlimit64;
-struct rusage;
-struct sched_param;
-struct sched_attr;
-struct sel_arg_struct;
-struct semaphore;
-struct sembuf;
-struct shmid_ds;
-struct sockaddr;
-struct stat;
-struct stat64;
-struct statfs;
-struct statfs64;
-struct __sysctl_args;
-struct sysinfo;
-struct timespec;
-struct timeval;
-struct timex;
-struct timezone;
-struct tms;
-struct utimbuf;
-struct mq_attr;
-struct compat_stat;
-struct compat_timeval;
-struct robust_list_head;
-struct getcpu_cache;
-struct old_linux_dirent;
-struct perf_event_attr;
-struct file_handle;
-struct sigaltstack;
-union bpf_attr;
-
+#include <linux/syscalls_structs.h>
 #include <linux/types.h>
 #include <linux/aio_abi.h>
 #include <linux/capability.h>
diff --git a/include/linux/syscalls_structs.h b/include/linux/syscalls_structs.h
new file mode 100644
index 0000000..a920cbc
--- /dev/null
+++ b/include/linux/syscalls_structs.h
@@ -0,0 +1,60 @@
+#ifndef _LINUX_SYSCALL_STRUCTS_H
+#define _LINUX_SYSCALL_STRUCTS_H
+
+struct epoll_event;
+struct iattr;
+struct inode;
+struct iocb;
+struct io_event;
+struct iovec;
+struct itimerspec;
+struct itimerval;
+struct kexec_segment;
+struct linux_dirent;
+struct linux_dirent64;
+struct list_head;
+struct mmap_arg_struct;
+struct msgbuf;
+struct user_msghdr;
+struct mmsghdr;
+struct msqid_ds;
+struct new_utsname;
+struct nfsctl_arg;
+struct __old_kernel_stat;
+struct oldold_utsname;
+struct old_utsname;
+struct pollfd;
+struct rlimit;
+struct rlimit64;
+struct rusage;
+struct sched_param;
+struct sched_attr;
+struct sel_arg_struct;
+struct semaphore;
+struct sembuf;
+struct shmid_ds;
+struct sockaddr;
+struct stat;
+struct stat64;
+struct statfs;
+struct statfs64;
+struct __sysctl_args;
+struct sysinfo;
+struct timespec;
+struct timeval;
+struct timex;
+struct timezone;
+struct tms;
+struct utimbuf;
+struct mq_attr;
+struct compat_stat;
+struct compat_timeval;
+struct robust_list_head;
+struct getcpu_cache;
+struct old_linux_dirent;
+struct perf_event_attr;
+struct file_handle;
+struct sigaltstack;
+union bpf_attr;
+
+#endif /* _LINUX_SYSCALL_STRUCTS_H */
diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
index 2622b33..f10a316 100644
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@ -29,6 +29,10 @@
 #define __SC_COMP_3264(_nr, _32, _64, _comp) __SC_3264(_nr, _32, _64)
 #endif
 
+#ifndef __SC_WRAP
+#define __SC_WRAP __SYSCALL
+#endif
+
 #define __NR_io_setup 0
 __SC_COMP(__NR_io_setup, sys_io_setup, compat_sys_io_setup)
 #define __NR_io_destroy 1
-- 
2.5.0



From ynorov at caviumnetworks.com  Wed Feb 24 10:34:13 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Wed, 24 Feb 2016 21:34:13 +0300
Subject: [PATCH 4/5] all: s390: move compat_wrappers.c from arch/s390/kernel
 to kernel/
In-Reply-To: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
References: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
Message-ID: <1456338854-14901-5-git-send-email-ynorov@caviumnetworks.com>

Some syscalls are declared conditionally, so corresponding wrappers
are conditional accordingly.

Signed-off-by: Yury Norov <ynorov at caviumnetworks.com>
---
 arch/s390/kernel/Makefile         |   2 +-
 arch/s390/kernel/compat_wrapper.c | 129 -----------------------------
 kernel/Makefile                   |   1 +
 kernel/compat_wrapper.c           | 170 ++++++++++++++++++++++++++++++++++++++
 4 files changed, 172 insertions(+), 130 deletions(-)
 delete mode 100644 arch/s390/kernel/compat_wrapper.c
 create mode 100644 kernel/compat_wrapper.c

diff --git a/arch/s390/kernel/Makefile b/arch/s390/kernel/Makefile
index 2f5586a..145d3d8 100644
--- a/arch/s390/kernel/Makefile
+++ b/arch/s390/kernel/Makefile
@@ -57,7 +57,7 @@ obj-$(CONFIG_HIBERNATION)	+= suspend.o swsusp.o
 obj-$(CONFIG_AUDIT)		+= audit.o
 compat-obj-$(CONFIG_AUDIT)	+= compat_audit.o
 obj-$(CONFIG_COMPAT)		+= compat_linux.o compat_signal.o
-obj-$(CONFIG_COMPAT)		+= compat_wrapper.o $(compat-obj-y)
+obj-$(CONFIG_COMPAT)		+= $(compat-obj-y)
 
 obj-$(CONFIG_STACKTRACE)	+= stacktrace.o
 obj-$(CONFIG_KPROBES)		+= kprobes.o
diff --git a/arch/s390/kernel/compat_wrapper.c b/arch/s390/kernel/compat_wrapper.c
deleted file mode 100644
index 1614e15..0000000
--- a/arch/s390/kernel/compat_wrapper.c
+++ /dev/null
@@ -1,129 +0,0 @@
-/*
- *  Compat system call wrappers.
- *
- *    Copyright IBM Corp. 2014
- */
-
-#include <linux/syscalls.h>
-#include <linux/compat.h>
-#include "entry.h"
-
-COMPAT_SYSCALL_WRAP2(creat, const char __user *, pathname, umode_t, mode);
-COMPAT_SYSCALL_WRAP2(link, const char __user *, oldname, const char __user *, newname);
-COMPAT_SYSCALL_WRAP1(unlink, const char __user *, pathname);
-COMPAT_SYSCALL_WRAP1(chdir, const char __user *, filename);
-COMPAT_SYSCALL_WRAP3(mknod, const char __user *, filename, umode_t, mode, unsigned, dev);
-COMPAT_SYSCALL_WRAP2(chmod, const char __user *, filename, umode_t, mode);
-COMPAT_SYSCALL_WRAP1(oldumount, char __user *, name);
-COMPAT_SYSCALL_WRAP2(access, const char __user *, filename, int, mode);
-COMPAT_SYSCALL_WRAP2(rename, const char __user *, oldname, const char __user *, newname);
-COMPAT_SYSCALL_WRAP2(mkdir, const char __user *, pathname, umode_t, mode);
-COMPAT_SYSCALL_WRAP1(rmdir, const char __user *, pathname);
-COMPAT_SYSCALL_WRAP1(pipe, int __user *, fildes);
-COMPAT_SYSCALL_WRAP1(brk, unsigned long, brk);
-COMPAT_SYSCALL_WRAP2(signal, int, sig, __sighandler_t, handler);
-COMPAT_SYSCALL_WRAP1(acct, const char __user *, name);
-COMPAT_SYSCALL_WRAP2(umount, char __user *, name, int, flags);
-COMPAT_SYSCALL_WRAP1(chroot, const char __user *, filename);
-COMPAT_SYSCALL_WRAP3(sigsuspend, int, unused1, int, unused2, old_sigset_t, mask);
-COMPAT_SYSCALL_WRAP2(sethostname, char __user *, name, int, len);
-COMPAT_SYSCALL_WRAP2(symlink, const char __user *, old, const char __user *, new);
-COMPAT_SYSCALL_WRAP3(readlink, const char __user *, path, char __user *, buf, int, bufsiz);
-COMPAT_SYSCALL_WRAP1(uselib, const char __user *, library);
-COMPAT_SYSCALL_WRAP2(swapon, const char __user *, specialfile, int, swap_flags);
-COMPAT_SYSCALL_WRAP4(reboot, int, magic1, int, magic2, unsigned int, cmd, void __user *, arg);
-COMPAT_SYSCALL_WRAP2(munmap, unsigned long, addr, size_t, len);
-COMPAT_SYSCALL_WRAP3(syslog, int, type, char __user *, buf, int, len);
-COMPAT_SYSCALL_WRAP1(swapoff, const char __user *, specialfile);
-COMPAT_SYSCALL_WRAP2(setdomainname, char __user *, name, int, len);
-COMPAT_SYSCALL_WRAP1(newuname, struct new_utsname __user *, name);
-COMPAT_SYSCALL_WRAP3(mprotect, unsigned long, start, size_t, len, unsigned long, prot);
-COMPAT_SYSCALL_WRAP3(init_module, void __user *, umod, unsigned long, len, const char __user *, uargs);
-COMPAT_SYSCALL_WRAP2(delete_module, const char __user *, name_user, unsigned int, flags);
-COMPAT_SYSCALL_WRAP4(quotactl, unsigned int, cmd, const char __user *, special, qid_t, id, void __user *, addr);
-COMPAT_SYSCALL_WRAP2(bdflush, int, func, long, data);
-COMPAT_SYSCALL_WRAP3(sysfs, int, option, unsigned long, arg1, unsigned long, arg2);
-COMPAT_SYSCALL_WRAP5(llseek, unsigned int, fd, unsigned long, high, unsigned long, low, loff_t __user *, result, unsigned int, whence);
-COMPAT_SYSCALL_WRAP3(msync, unsigned long, start, size_t, len, int, flags);
-COMPAT_SYSCALL_WRAP2(mlock, unsigned long, start, size_t, len);
-COMPAT_SYSCALL_WRAP2(munlock, unsigned long, start, size_t, len);
-COMPAT_SYSCALL_WRAP2(sched_setparam, pid_t, pid, struct sched_param __user *, param);
-COMPAT_SYSCALL_WRAP2(sched_getparam, pid_t, pid, struct sched_param __user *, param);
-COMPAT_SYSCALL_WRAP3(sched_setscheduler, pid_t, pid, int, policy, struct sched_param __user *, param);
-COMPAT_SYSCALL_WRAP5(mremap, unsigned long, addr, unsigned long, old_len, unsigned long, new_len, unsigned long, flags, unsigned long, new_addr);
-COMPAT_SYSCALL_WRAP3(poll, struct pollfd __user *, ufds, unsigned int, nfds, int, timeout);
-COMPAT_SYSCALL_WRAP5(prctl, int, option, unsigned long, arg2, unsigned long, arg3, unsigned long, arg4, unsigned long, arg5);
-COMPAT_SYSCALL_WRAP2(getcwd, char __user *, buf, unsigned long, size);
-COMPAT_SYSCALL_WRAP2(capget, cap_user_header_t, header, cap_user_data_t, dataptr);
-COMPAT_SYSCALL_WRAP2(capset, cap_user_header_t, header, const cap_user_data_t, data);
-COMPAT_SYSCALL_WRAP3(lchown, const char __user *, filename, uid_t, user, gid_t, group);
-COMPAT_SYSCALL_WRAP2(getgroups, int, gidsetsize, gid_t __user *, grouplist);
-COMPAT_SYSCALL_WRAP2(setgroups, int, gidsetsize, gid_t __user *, grouplist);
-COMPAT_SYSCALL_WRAP3(getresuid, uid_t __user *, ruid, uid_t __user *, euid, uid_t __user *, suid);
-COMPAT_SYSCALL_WRAP3(getresgid, gid_t __user *, rgid, gid_t __user *, egid, gid_t __user *, sgid);
-COMPAT_SYSCALL_WRAP3(chown, const char __user *, filename, uid_t, user, gid_t, group);
-COMPAT_SYSCALL_WRAP2(pivot_root, const char __user *, new_root, const char __user *, put_old);
-COMPAT_SYSCALL_WRAP3(mincore, unsigned long, start, size_t, len, unsigned char __user *, vec);
-COMPAT_SYSCALL_WRAP3(madvise, unsigned long, start, size_t, len, int, behavior);
-COMPAT_SYSCALL_WRAP5(setxattr, const char __user *, path, const char __user *, name, const void __user *, value, size_t, size, int, flags);
-COMPAT_SYSCALL_WRAP5(lsetxattr, const char __user *, path, const char __user *, name, const void __user *, value, size_t, size, int, flags);
-COMPAT_SYSCALL_WRAP5(fsetxattr, int, fd, const char __user *, name, const void __user *, value, size_t, size, int, flags);
-COMPAT_SYSCALL_WRAP3(getdents64, unsigned int, fd, struct linux_dirent64 __user *, dirent, unsigned int, count);
-COMPAT_SYSCALL_WRAP4(getxattr, const char __user *, path, const char __user *, name, void __user *, value, size_t, size);
-COMPAT_SYSCALL_WRAP4(lgetxattr, const char __user *, path, const char __user *, name, void __user *, value, size_t, size);
-COMPAT_SYSCALL_WRAP4(fgetxattr, int, fd, const char __user *, name, void __user *, value, size_t, size);
-COMPAT_SYSCALL_WRAP3(listxattr, const char __user *, path, char __user *, list, size_t, size);
-COMPAT_SYSCALL_WRAP3(llistxattr, const char __user *, path, char __user *, list, size_t, size);
-COMPAT_SYSCALL_WRAP3(flistxattr, int, fd, char __user *, list, size_t, size);
-COMPAT_SYSCALL_WRAP2(removexattr, const char __user *, path, const char __user *, name);
-COMPAT_SYSCALL_WRAP2(lremovexattr, const char __user *, path, const char __user *, name);
-COMPAT_SYSCALL_WRAP2(fremovexattr, int, fd, const char __user *, name);
-COMPAT_SYSCALL_WRAP1(set_tid_address, int __user *, tidptr);
-COMPAT_SYSCALL_WRAP4(epoll_ctl, int, epfd, int, op, int, fd, struct epoll_event __user *, event);
-COMPAT_SYSCALL_WRAP4(epoll_wait, int, epfd, struct epoll_event __user *, events, int, maxevents, int, timeout);
-COMPAT_SYSCALL_WRAP1(io_destroy, aio_context_t, ctx);
-COMPAT_SYSCALL_WRAP3(io_cancel, aio_context_t, ctx_id, struct iocb __user *, iocb, struct io_event __user *, result);
-COMPAT_SYSCALL_WRAP1(mq_unlink, const char __user *, name);
-COMPAT_SYSCALL_WRAP5(add_key, const char __user *, tp, const char __user *, dsc, const void __user *, pld, size_t, len, key_serial_t, id);
-COMPAT_SYSCALL_WRAP4(request_key, const char __user *, tp, const char __user *, dsc, const char __user *, info, key_serial_t, id);
-COMPAT_SYSCALL_WRAP5(remap_file_pages, unsigned long, start, unsigned long, size, unsigned long, prot, unsigned long, pgoff, unsigned long, flags);
-COMPAT_SYSCALL_WRAP3(inotify_add_watch, int, fd, const char __user *, path, u32, mask);
-COMPAT_SYSCALL_WRAP3(mkdirat, int, dfd, const char __user *, pathname, umode_t, mode);
-COMPAT_SYSCALL_WRAP4(mknodat, int, dfd, const char __user *, filename, umode_t, mode, unsigned, dev);
-COMPAT_SYSCALL_WRAP5(fchownat, int, dfd, const char __user *, filename, uid_t, user, gid_t, group, int, flag);
-COMPAT_SYSCALL_WRAP3(unlinkat, int, dfd, const char __user *, pathname, int, flag);
-COMPAT_SYSCALL_WRAP4(renameat, int, olddfd, const char __user *, oldname, int, newdfd, const char __user *, newname);
-COMPAT_SYSCALL_WRAP5(linkat, int, olddfd, const char __user *, oldname, int, newdfd, const char __user *, newname, int, flags);
-COMPAT_SYSCALL_WRAP3(symlinkat, const char __user *, oldname, int, newdfd, const char __user *, newname);
-COMPAT_SYSCALL_WRAP4(readlinkat, int, dfd, const char __user *, path, char __user *, buf, int, bufsiz);
-COMPAT_SYSCALL_WRAP3(fchmodat, int, dfd, const char __user *, filename, umode_t, mode);
-COMPAT_SYSCALL_WRAP3(faccessat, int, dfd, const char __user *, filename, int, mode);
-COMPAT_SYSCALL_WRAP1(unshare, unsigned long, unshare_flags);
-COMPAT_SYSCALL_WRAP6(splice, int, fd_in, loff_t __user *, off_in, int, fd_out, loff_t __user *, off_out, size_t, len, unsigned int, flags);
-COMPAT_SYSCALL_WRAP4(tee, int, fdin, int, fdout, size_t, len, unsigned int, flags);
-COMPAT_SYSCALL_WRAP3(getcpu, unsigned __user *, cpu, unsigned __user *, node, struct getcpu_cache __user *, cache);
-COMPAT_SYSCALL_WRAP2(pipe2, int __user *, fildes, int, flags);
-COMPAT_SYSCALL_WRAP5(perf_event_open, struct perf_event_attr __user *, attr_uptr, pid_t, pid, int, cpu, int, group_fd, unsigned long, flags);
-COMPAT_SYSCALL_WRAP5(clone, unsigned long, newsp, unsigned long, clone_flags, int __user *, parent_tidptr, int __user *, child_tidptr, unsigned long, tls);
-COMPAT_SYSCALL_WRAP4(prlimit64, pid_t, pid, unsigned int, resource, const struct rlimit64 __user *, new_rlim, struct rlimit64 __user *, old_rlim);
-COMPAT_SYSCALL_WRAP5(name_to_handle_at, int, dfd, const char __user *, name, struct file_handle __user *, handle, int __user *, mnt_id, int, flag);
-COMPAT_SYSCALL_WRAP5(kcmp, pid_t, pid1, pid_t, pid2, int, type, unsigned long, idx1, unsigned long, idx2);
-COMPAT_SYSCALL_WRAP3(finit_module, int, fd, const char __user *, uargs, int, flags);
-COMPAT_SYSCALL_WRAP3(sched_setattr, pid_t, pid, struct sched_attr __user *, attr, unsigned int, flags);
-COMPAT_SYSCALL_WRAP4(sched_getattr, pid_t, pid, struct sched_attr __user *, attr, unsigned int, size, unsigned int, flags);
-COMPAT_SYSCALL_WRAP5(renameat2, int, olddfd, const char __user *, oldname, int, newdfd, const char __user *, newname, unsigned int, flags);
-COMPAT_SYSCALL_WRAP3(seccomp, unsigned int, op, unsigned int, flags, const char __user *, uargs)
-COMPAT_SYSCALL_WRAP3(getrandom, char __user *, buf, size_t, count, unsigned int, flags)
-COMPAT_SYSCALL_WRAP2(memfd_create, const char __user *, uname, unsigned int, flags)
-COMPAT_SYSCALL_WRAP3(bpf, int, cmd, union bpf_attr *, attr, unsigned int, size);
-COMPAT_SYSCALL_WRAP3(s390_pci_mmio_write, const unsigned long, mmio_addr, const void __user *, user_buffer, const size_t, length);
-COMPAT_SYSCALL_WRAP3(s390_pci_mmio_read, const unsigned long, mmio_addr, void __user *, user_buffer, const size_t, length);
-COMPAT_SYSCALL_WRAP4(socketpair, int, family, int, type, int, protocol, int __user *, usockvec);
-COMPAT_SYSCALL_WRAP3(bind, int, fd, struct sockaddr __user *, umyaddr, int, addrlen);
-COMPAT_SYSCALL_WRAP3(connect, int, fd, struct sockaddr __user *, uservaddr, int, addrlen);
-COMPAT_SYSCALL_WRAP4(accept4, int, fd, struct sockaddr __user *, upeer_sockaddr, int __user *, upeer_addrlen, int, flags);
-COMPAT_SYSCALL_WRAP3(getsockname, int, fd, struct sockaddr __user *, usockaddr, int __user *, usockaddr_len);
-COMPAT_SYSCALL_WRAP3(getpeername, int, fd, struct sockaddr __user *, usockaddr, int __user *, usockaddr_len);
-COMPAT_SYSCALL_WRAP6(sendto, int, fd, void __user *, buff, size_t, len, unsigned int, flags, struct sockaddr __user *, addr, int, addr_len);
-COMPAT_SYSCALL_WRAP3(mlock2, unsigned long, start, size_t, len, int, flags);
-COMPAT_SYSCALL_WRAP6(copy_file_range, int, fd_in, loff_t __user *, off_in, int, fd_out, loff_t __user *, off_out, size_t, len, unsigned int, flags);
diff --git a/kernel/Makefile b/kernel/Makefile
index 53abf00..208906e 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_KEXEC_FILE) += kexec_file.o
 obj-$(CONFIG_BACKTRACE_SELF_TEST) += backtracetest.o
 obj-$(CONFIG_COMPAT) += compat.o
+obj-$(CONFIG_COMPAT_WRAPPER) += compat_wrapper.o
 obj-$(CONFIG_CGROUPS) += cgroup.o
 obj-$(CONFIG_CGROUP_FREEZER) += cgroup_freezer.o
 obj-$(CONFIG_CGROUP_PIDS) += cgroup_pids.o
diff --git a/kernel/compat_wrapper.c b/kernel/compat_wrapper.c
new file mode 100644
index 0000000..662602e
--- /dev/null
+++ b/kernel/compat_wrapper.c
@@ -0,0 +1,170 @@
+/*
+ *  Compat system call wrappers.
+ *
+ *    Copyright IBM Corp. 2014
+ */
+
+#include <linux/syscalls.h>
+#include <linux/compat.h>
+
+COMPAT_SYSCALL_WRAP2(creat, const char __user *, pathname, umode_t, mode);
+COMPAT_SYSCALL_WRAP2(link, const char __user *, oldname, const char __user *, newname);
+COMPAT_SYSCALL_WRAP1(unlink, const char __user *, pathname);
+COMPAT_SYSCALL_WRAP1(chdir, const char __user *, filename);
+COMPAT_SYSCALL_WRAP3(mknod, const char __user *, filename, umode_t, mode, unsigned, dev);
+COMPAT_SYSCALL_WRAP2(chmod, const char __user *, filename, umode_t, mode);
+
+#ifdef __ARCH_WANT_SYS_OLDUMOUNT
+COMPAT_SYSCALL_WRAP1(oldumount, char __user *, name);
+#endif
+
+COMPAT_SYSCALL_WRAP2(access, const char __user *, filename, int, mode);
+COMPAT_SYSCALL_WRAP2(rename, const char __user *, oldname, const char __user *, newname);
+COMPAT_SYSCALL_WRAP2(mkdir, const char __user *, pathname, umode_t, mode);
+COMPAT_SYSCALL_WRAP1(rmdir, const char __user *, pathname);
+COMPAT_SYSCALL_WRAP1(pipe, int __user *, fildes);
+COMPAT_SYSCALL_WRAP1(brk, unsigned long, brk);
+
+#ifdef __ARCH_WANT_SYS_SIGNAL
+COMPAT_SYSCALL_WRAP2(signal, int, sig, __sighandler_t, handler);
+#endif
+
+COMPAT_SYSCALL_WRAP1(acct, const char __user *, name);
+COMPAT_SYSCALL_WRAP2(umount, char __user *, name, int, flags);
+COMPAT_SYSCALL_WRAP1(chroot, const char __user *, filename);
+COMPAT_SYSCALL_WRAP3(sigsuspend, int, unused1, int, unused2, old_sigset_t, mask);
+COMPAT_SYSCALL_WRAP2(sethostname, char __user *, name, int, len);
+COMPAT_SYSCALL_WRAP2(symlink, const char __user *, old, const char __user *, new);
+COMPAT_SYSCALL_WRAP3(readlink, const char __user *, path, char __user *, buf, int, bufsiz);
+COMPAT_SYSCALL_WRAP1(uselib, const char __user *, library);
+COMPAT_SYSCALL_WRAP2(swapon, const char __user *, specialfile, int, swap_flags);
+COMPAT_SYSCALL_WRAP4(reboot, int, magic1, int, magic2, unsigned int, cmd, void __user *, arg);
+COMPAT_SYSCALL_WRAP2(munmap, unsigned long, addr, size_t, len);
+COMPAT_SYSCALL_WRAP3(syslog, int, type, char __user *, buf, int, len);
+COMPAT_SYSCALL_WRAP1(swapoff, const char __user *, specialfile);
+COMPAT_SYSCALL_WRAP2(setdomainname, char __user *, name, int, len);
+COMPAT_SYSCALL_WRAP1(newuname, struct new_utsname __user *, name);
+COMPAT_SYSCALL_WRAP3(mprotect, unsigned long, start, size_t, len, unsigned long, prot);
+COMPAT_SYSCALL_WRAP3(init_module, void __user *, umod, unsigned long, len, const char __user *, uargs);
+COMPAT_SYSCALL_WRAP2(delete_module, const char __user *, name_user, unsigned int, flags);
+COMPAT_SYSCALL_WRAP4(quotactl, unsigned int, cmd, const char __user *, special, qid_t, id, void __user *, addr);
+COMPAT_SYSCALL_WRAP2(bdflush, int, func, long, data);
+COMPAT_SYSCALL_WRAP3(sysfs, int, option, unsigned long, arg1, unsigned long, arg2);
+
+#ifdef __ARCH_WANT_SYS_LLSEEK
+COMPAT_SYSCALL_WRAP5(llseek, unsigned int, fd, unsigned long, high, unsigned long, low, loff_t __user *, result, unsigned int, whence);
+#endif
+
+COMPAT_SYSCALL_WRAP3(msync, unsigned long, start, size_t, len, int, flags);
+COMPAT_SYSCALL_WRAP2(mlock, unsigned long, start, size_t, len);
+COMPAT_SYSCALL_WRAP2(munlock, unsigned long, start, size_t, len);
+COMPAT_SYSCALL_WRAP2(sched_setparam, pid_t, pid, struct sched_param __user *, param);
+COMPAT_SYSCALL_WRAP2(sched_getparam, pid_t, pid, struct sched_param __user *, param);
+COMPAT_SYSCALL_WRAP3(sched_setscheduler, pid_t, pid, int, policy, struct sched_param __user *, param);
+COMPAT_SYSCALL_WRAP5(mremap, unsigned long, addr, unsigned long, old_len, unsigned long, new_len, unsigned long, flags, unsigned long, new_addr);
+COMPAT_SYSCALL_WRAP3(poll, struct pollfd __user *, ufds, unsigned int, nfds, int, timeout);
+COMPAT_SYSCALL_WRAP5(prctl, int, option, unsigned long, arg2, unsigned long, arg3, unsigned long, arg4, unsigned long, arg5);
+COMPAT_SYSCALL_WRAP2(getcwd, char __user *, buf, unsigned long, size);
+COMPAT_SYSCALL_WRAP2(capget, cap_user_header_t, header, cap_user_data_t, dataptr);
+COMPAT_SYSCALL_WRAP2(capset, cap_user_header_t, header, const cap_user_data_t, data);
+COMPAT_SYSCALL_WRAP3(lchown, const char __user *, filename, uid_t, user, gid_t, group);
+COMPAT_SYSCALL_WRAP2(getgroups, int, gidsetsize, gid_t __user *, grouplist);
+COMPAT_SYSCALL_WRAP2(setgroups, int, gidsetsize, gid_t __user *, grouplist);
+COMPAT_SYSCALL_WRAP3(getresuid, uid_t __user *, ruid, uid_t __user *, euid, uid_t __user *, suid);
+COMPAT_SYSCALL_WRAP3(getresgid, gid_t __user *, rgid, gid_t __user *, egid, gid_t __user *, sgid);
+COMPAT_SYSCALL_WRAP3(chown, const char __user *, filename, uid_t, user, gid_t, group);
+COMPAT_SYSCALL_WRAP2(pivot_root, const char __user *, new_root, const char __user *, put_old);
+COMPAT_SYSCALL_WRAP3(mincore, unsigned long, start, size_t, len, unsigned char __user *, vec);
+COMPAT_SYSCALL_WRAP3(madvise, unsigned long, start, size_t, len, int, behavior);
+COMPAT_SYSCALL_WRAP5(setxattr, const char __user *, path, const char __user *, name, const void __user *, value, size_t, size, int, flags);
+COMPAT_SYSCALL_WRAP5(lsetxattr, const char __user *, path, const char __user *, name, const void __user *, value, size_t, size, int, flags);
+COMPAT_SYSCALL_WRAP5(fsetxattr, int, fd, const char __user *, name, const void __user *, value, size_t, size, int, flags);
+
+#ifndef __ARCH_WANT_COMPAT_SYS_GETDENTS64
+COMPAT_SYSCALL_WRAP3(getdents64, unsigned int, fd, struct linux_dirent64 __user *, dirent, unsigned int, count);
+#endif
+
+COMPAT_SYSCALL_WRAP4(getxattr, const char __user *, path, const char __user *, name, void __user *, value, size_t, size);
+COMPAT_SYSCALL_WRAP4(lgetxattr, const char __user *, path, const char __user *, name, void __user *, value, size_t, size);
+COMPAT_SYSCALL_WRAP4(fgetxattr, int, fd, const char __user *, name, void __user *, value, size_t, size);
+COMPAT_SYSCALL_WRAP3(listxattr, const char __user *, path, char __user *, list, size_t, size);
+COMPAT_SYSCALL_WRAP3(llistxattr, const char __user *, path, char __user *, list, size_t, size);
+COMPAT_SYSCALL_WRAP3(flistxattr, int, fd, char __user *, list, size_t, size);
+COMPAT_SYSCALL_WRAP2(removexattr, const char __user *, path, const char __user *, name);
+COMPAT_SYSCALL_WRAP2(lremovexattr, const char __user *, path, const char __user *, name);
+COMPAT_SYSCALL_WRAP2(fremovexattr, int, fd, const char __user *, name);
+COMPAT_SYSCALL_WRAP1(set_tid_address, int __user *, tidptr);
+COMPAT_SYSCALL_WRAP4(epoll_ctl, int, epfd, int, op, int, fd, struct epoll_event __user *, event);
+COMPAT_SYSCALL_WRAP4(epoll_wait, int, epfd, struct epoll_event __user *, events, int, maxevents, int, timeout);
+COMPAT_SYSCALL_WRAP1(io_destroy, aio_context_t, ctx);
+COMPAT_SYSCALL_WRAP3(io_cancel, aio_context_t, ctx_id, struct iocb __user *, iocb, struct io_event __user *, result);
+COMPAT_SYSCALL_WRAP1(mq_unlink, const char __user *, name);
+COMPAT_SYSCALL_WRAP5(add_key, const char __user *, tp, const char __user *, dsc, const void __user *, pld, size_t, len, key_serial_t, id);
+COMPAT_SYSCALL_WRAP4(request_key, const char __user *, tp, const char __user *, dsc, const char __user *, info, key_serial_t, id);
+COMPAT_SYSCALL_WRAP5(remap_file_pages, unsigned long, start, unsigned long, size, unsigned long, prot, unsigned long, pgoff, unsigned long, flags);
+COMPAT_SYSCALL_WRAP3(inotify_add_watch, int, fd, const char __user *, path, u32, mask);
+COMPAT_SYSCALL_WRAP3(mkdirat, int, dfd, const char __user *, pathname, umode_t, mode);
+COMPAT_SYSCALL_WRAP4(mknodat, int, dfd, const char __user *, filename, umode_t, mode, unsigned, dev);
+COMPAT_SYSCALL_WRAP5(fchownat, int, dfd, const char __user *, filename, uid_t, user, gid_t, group, int, flag);
+COMPAT_SYSCALL_WRAP3(unlinkat, int, dfd, const char __user *, pathname, int, flag);
+COMPAT_SYSCALL_WRAP4(renameat, int, olddfd, const char __user *, oldname, int, newdfd, const char __user *, newname);
+COMPAT_SYSCALL_WRAP5(linkat, int, olddfd, const char __user *, oldname, int, newdfd, const char __user *, newname, int, flags);
+COMPAT_SYSCALL_WRAP3(symlinkat, const char __user *, oldname, int, newdfd, const char __user *, newname);
+COMPAT_SYSCALL_WRAP4(readlinkat, int, dfd, const char __user *, path, char __user *, buf, int, bufsiz);
+COMPAT_SYSCALL_WRAP3(fchmodat, int, dfd, const char __user *, filename, umode_t, mode);
+COMPAT_SYSCALL_WRAP3(faccessat, int, dfd, const char __user *, filename, int, mode);
+COMPAT_SYSCALL_WRAP1(unshare, unsigned long, unshare_flags);
+COMPAT_SYSCALL_WRAP6(splice, int, fd_in, loff_t __user *, off_in, int, fd_out, loff_t __user *, off_out, size_t, len, unsigned int, flags);
+COMPAT_SYSCALL_WRAP4(tee, int, fdin, int, fdout, size_t, len, unsigned int, flags);
+COMPAT_SYSCALL_WRAP3(getcpu, unsigned __user *, cpu, unsigned __user *, node, struct getcpu_cache __user *, cache);
+COMPAT_SYSCALL_WRAP2(pipe2, int __user *, fildes, int, flags);
+COMPAT_SYSCALL_WRAP5(perf_event_open, struct perf_event_attr __user *, attr_uptr, pid_t, pid, int, cpu, int, group_fd, unsigned long, flags);
+
+#ifdef __ARCH_WANT_SYS_CLONE
+#ifdef CONFIG_CLONE_BACKWARDS
+COMPAT_SYSCALL_WRAP5(clone, unsigned long, clone_flags, unsigned long, newsp,
+                int __user *, parent_tidptr,
+                unsigned long, tls,
+                int __user *, child_tidptr);
+#elif defined(CONFIG_CLONE_BACKWARDS2)
+       COMPAT_SYSCALL_WRAP5(clone, unsigned long, newsp, unsigned long, clone_flags,
+               int __user *, parent_tidptr,
+               int __user *, child_tidptr,
+               unsigned long, tls);
+#elif defined(CONFIG_CLONE_BACKWARDS3)
+       COMPAT_SYSCALL_WRAP6(clone, unsigned long, clone_flags, unsigned long, newsp,
+              int, stack_size,
+              int __user *, parent_tidptr,
+              int __user *, child_tidptr,
+               unsigned long, tls);
+#else
+COMPAT_SYSCALL_WRAP5(clone, unsigned long, clone_flags, unsigned long, newsp,
+       int __user *, parent_tidptr,
+       int __user *, child_tidptr,
+       unsigned long, tls);
+#endif
+#endif
+
+
+COMPAT_SYSCALL_WRAP4(prlimit64, pid_t, pid, unsigned int, resource, const struct rlimit64 __user *, new_rlim, struct rlimit64 __user *, old_rlim);
+COMPAT_SYSCALL_WRAP5(name_to_handle_at, int, dfd, const char __user *, name, struct file_handle __user *, handle, int __user *, mnt_id, int, flag);
+COMPAT_SYSCALL_WRAP5(kcmp, pid_t, pid1, pid_t, pid2, int, type, unsigned long, idx1, unsigned long, idx2);
+COMPAT_SYSCALL_WRAP3(finit_module, int, fd, const char __user *, uargs, int, flags);
+COMPAT_SYSCALL_WRAP3(sched_setattr, pid_t, pid, struct sched_attr __user *, attr, unsigned int, flags);
+COMPAT_SYSCALL_WRAP4(sched_getattr, pid_t, pid, struct sched_attr __user *, attr, unsigned int, size, unsigned int, flags);
+COMPAT_SYSCALL_WRAP5(renameat2, int, olddfd, const char __user *, oldname, int, newdfd, const char __user *, newname, unsigned int, flags);
+COMPAT_SYSCALL_WRAP3(seccomp, unsigned int, op, unsigned int, flags, const char __user *, uargs)
+COMPAT_SYSCALL_WRAP3(getrandom, char __user *, buf, size_t, count, unsigned int, flags)
+COMPAT_SYSCALL_WRAP2(memfd_create, const char __user *, uname, unsigned int, flags)
+COMPAT_SYSCALL_WRAP3(bpf, int, cmd, union bpf_attr *, attr, unsigned int, size);
+COMPAT_SYSCALL_WRAP3(s390_pci_mmio_write, const unsigned long, mmio_addr, const void __user *, user_buffer, const size_t, length);
+COMPAT_SYSCALL_WRAP3(s390_pci_mmio_read, const unsigned long, mmio_addr, void __user *, user_buffer, const size_t, length);
+COMPAT_SYSCALL_WRAP4(socketpair, int, family, int, type, int, protocol, int __user *, usockvec);
+COMPAT_SYSCALL_WRAP3(bind, int, fd, struct sockaddr __user *, umyaddr, int, addrlen);
+COMPAT_SYSCALL_WRAP3(connect, int, fd, struct sockaddr __user *, uservaddr, int, addrlen);
+COMPAT_SYSCALL_WRAP4(accept4, int, fd, struct sockaddr __user *, upeer_sockaddr, int __user *, upeer_addrlen, int, flags);
+COMPAT_SYSCALL_WRAP3(getsockname, int, fd, struct sockaddr __user *, usockaddr, int __user *, usockaddr_len);
+COMPAT_SYSCALL_WRAP3(getpeername, int, fd, struct sockaddr __user *, usockaddr, int __user *, usockaddr_len);
+COMPAT_SYSCALL_WRAP6(sendto, int, fd, void __user *, buff, size_t, len, unsigned int, flags, struct sockaddr __user *, addr, int, addr_len);
+COMPAT_SYSCALL_WRAP3(mlock2, unsigned long, start, size_t, len, int, flags);
+COMPAT_SYSCALL_WRAP6(copy_file_range, int, fd_in, loff_t __user *, off_in, int, fd_out, loff_t __user *, off_out, size_t, len, unsigned int, flags);
-- 
2.5.0



From ynorov at caviumnetworks.com  Wed Feb 24 10:34:14 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Wed, 24 Feb 2016 21:34:14 +0300
Subject: [PATCH 5/5] all: wrap needed syscalls in generic unistd
In-Reply-To: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
References: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
Message-ID: <1456338854-14901-6-git-send-email-ynorov@caviumnetworks.com>

As generic unistd syscall table is written in C, syscall
prototypes declaration is needed. It's added to compat header.

Signed-off-by: Yury Norov <ynorov at caviumnetworks.com>
---
 include/linux/compat.h            | 225 +++++++++++++++++++++++++++++++++++++
 include/uapi/asm-generic/unistd.h | 227 +++++++++++++++++++-------------------
 2 files changed, 338 insertions(+), 114 deletions(-)

diff --git a/include/linux/compat.h b/include/linux/compat.h
index 243b656..72c922f 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -769,6 +769,231 @@ asmlinkage long notrace compat_SyS##name(__MAP(x,__SC_COMPAT_TYPE,__VA_ARGS__))
 }
 #endif
 
+/* Compat wrappers */
+#include <linux/syscalls_structs.h>
+asmlinkage long compat_sys_creat(const char __user *pathname, umode_t mode);
+asmlinkage long compat_sys_link(const char __user *oldname,
+				const char __user *newname);
+asmlinkage long compat_sys_chdir(const char __user *filename);
+asmlinkage long compat_sys_mknod(const char __user *filename, umode_t mode,
+				unsigned dev);
+asmlinkage long compat_sys_chmod(const char __user *filename, umode_t mode);
+asmlinkage long compat_sys_oldumount(char __user *name);
+asmlinkage long compat_sys_access(const char __user *filename, int mode);
+asmlinkage long compat_sys_rename(const char __user *oldname,
+				const char __user *newname);
+asmlinkage long compat_sys_mkdir(const char __user *pathname, umode_t mode);
+asmlinkage long compat_sys_rmdir(const char __user *pathname);
+asmlinkage long compat_sys_pipe(int __user *fildes);
+asmlinkage long compat_sys_brk(unsigned long brk);
+asmlinkage long compat_sys_signal(int sig, __sighandler_t handler);
+asmlinkage long compat_sys_acct(const char __user *name);
+asmlinkage long compat_sys_umount(char __user *name, int flags);
+asmlinkage long compat_sys_chroot(const char __user *filename);
+
+#ifdef CONFIG_OLD_SIGSUSPEND
+asmlinkage long compat_sys_sigsuspend(old_sigset_t mask);
+#endif
+
+#ifdef CONFIG_OLD_SIGSUSPEND3
+asmlinkage long compat_sys_sigsuspend(int unused1, int unused2, old_sigset_t mask);
+#endif
+
+asmlinkage long compat_sys_sethostname(char __user *name, int len);
+asmlinkage long compat_sys_symlink(const char __user *old, const char __user *new);
+asmlinkage long compat_sys_readlink(const char __user *path,
+				char __user *buf, int bufsiz);
+asmlinkage long compat_sys_uselib(const char __user *library);
+asmlinkage long compat_sys_swapon(const char __user *specialfile, int swap_flags);
+asmlinkage long compat_sys_reboot(int magic1, int magic2, unsigned int cmd,
+				void __user *arg);
+asmlinkage long compat_sys_munmap(unsigned long addr, size_t len);
+asmlinkage long compat_sys_munmap(unsigned long addr, size_t len);
+asmlinkage long compat_sys_syslog(int type, char __user *buf, int len);
+asmlinkage long compat_sys_swapoff(const char __user *specialfile);
+asmlinkage long compat_sys_setdomainname(char __user *name, int len);
+asmlinkage long compat_sys_newuname(struct new_utsname __user *name);
+asmlinkage long compat_sys_mprotect(unsigned long start, size_t len,
+				unsigned long prot);
+asmlinkage long compat_sys_init_module(void __user *umod, unsigned long len,
+				const char __user *uargs);
+asmlinkage long compat_sys_delete_module(const char __user *name_user,
+				unsigned int flags);
+asmlinkage long compat_sys_quotactl(unsigned int cmd, const char __user *special,
+				qid_t id, void __user *addr);
+asmlinkage long compat_sys_bdflush(int func, long data);
+asmlinkage long compat_sys_sysfs(int option,
+				unsigned long arg1, unsigned long arg2);
+asmlinkage long compat_sys_llseek(unsigned int fd, unsigned long offset_high,
+			unsigned long offset_low, loff_t __user *result,
+			unsigned int whence);
+asmlinkage long compat_sys_msync(unsigned long start, size_t len, int flags);
+asmlinkage long compat_sys_mlock(unsigned long start, size_t len);
+asmlinkage long compat_sys_munlock(unsigned long start, size_t len);
+asmlinkage long compat_sys_sched_setparam(pid_t pid,
+					struct sched_param __user *param);
+asmlinkage long compat_sys_sched_getparam(pid_t pid,
+					struct sched_param __user *param);
+asmlinkage long compat_sys_sched_setscheduler(pid_t pid, int policy,
+					struct sched_param __user *param);
+asmlinkage long compat_sys_mremap(unsigned long addr,
+			   unsigned long old_len, unsigned long new_len,
+			   unsigned long flags, unsigned long new_addr);
+asmlinkage long compat_sys_poll(struct pollfd __user *ufds, unsigned int nfds,
+				int timeout);
+asmlinkage long compat_sys_prctl(int option, unsigned long arg2, unsigned long arg3,
+			unsigned long arg4, unsigned long arg5);
+asmlinkage long compat_sys_getcwd(char __user *buf, unsigned long size);
+asmlinkage long compat_sys_capget(cap_user_header_t header,
+				cap_user_data_t dataptr);
+asmlinkage long compat_sys_capset(cap_user_header_t header,
+				const cap_user_data_t data);
+asmlinkage long compat_sys_lchown(const char __user *filename,
+				uid_t user, gid_t group);
+asmlinkage long compat_sys_getgroups(int gidsetsize, gid_t __user *grouplist);
+asmlinkage long compat_sys_setgroups(int gidsetsize, gid_t __user *grouplist);
+asmlinkage long compat_sys_getresuid(uid_t __user *ruid, uid_t __user *euid, uid_t __user *suid);
+asmlinkage long compat_sys_getresgid(gid_t __user *rgid, gid_t __user *egid, gid_t __user *sgid);
+asmlinkage long compat_sys_chown(const char __user *filename,
+				uid_t user, gid_t group);
+asmlinkage long compat_sys_pivot_root(const char __user *new_root,
+				const char __user *put_old);
+asmlinkage long compat_sys_mincore(unsigned long start, size_t len,
+				unsigned char __user * vec);
+asmlinkage long compat_sys_madvise(unsigned long start, size_t len, int behavior);
+asmlinkage long compat_sys_setxattr(const char __user *path, const char __user *name,
+			     const void __user *value, size_t size, int flags);
+asmlinkage long compat_sys_lsetxattr(const char __user *path, const char __user *name,
+			      const void __user *value, size_t size, int flags);
+asmlinkage long compat_sys_fsetxattr(int fd, const char __user *name,
+			      const void __user *value, size_t size, int flags);
+asmlinkage long compat_sys_getdents64(unsigned int fd,
+				struct linux_dirent64 __user *dirent,
+				unsigned int count);
+asmlinkage long compat_sys_getxattr(const char __user *path, const char __user *name,
+			     void __user *value, size_t size);
+asmlinkage long compat_sys_lgetxattr(const char __user *path, const char __user *name,
+			      void __user *value, size_t size);
+asmlinkage long compat_sys_fgetxattr(int fd, const char __user *name,
+			      void __user *value, size_t size);
+asmlinkage long compat_sys_listxattr(const char __user *path, char __user *list,
+			      size_t size);
+asmlinkage long compat_sys_llistxattr(const char __user *path, char __user *list,
+			       size_t size);
+asmlinkage long compat_sys_flistxattr(int fd, char __user *list, size_t size);
+asmlinkage long compat_sys_listxattr(const char __user *path, char __user *list,
+			      size_t size);
+asmlinkage long compat_sys_llistxattr(const char __user *path, char __user *list,
+			       size_t size);
+asmlinkage long compat_sys_flistxattr(int fd, char __user *list, size_t size);
+asmlinkage long compat_sys_removexattr(const char __user *path,
+				const char __user *name);
+asmlinkage long compat_sys_lremovexattr(const char __user *path,
+				 const char __user *name);
+asmlinkage long compat_sys_fremovexattr(int fd, const char __user *name);
+asmlinkage long compat_sys_set_tid_address(int __user *tidptr);
+asmlinkage long compat_sys_epoll_ctl(int epfd, int op, int fd,
+				struct epoll_event __user *event);
+asmlinkage long compat_sys_epoll_wait(int epfd, struct epoll_event __user *events,
+				int maxevents, int timeout);
+asmlinkage long compat_sys_io_destroy(aio_context_t ctx);
+asmlinkage long compat_sys_io_cancel(aio_context_t ctx_id, struct iocb __user *iocb,
+			      struct io_event __user *result);
+asmlinkage long compat_sys_mq_unlink(const char __user *name);
+asmlinkage long compat_sys_add_key(const char __user *_type,
+			    const char __user *_description,
+			    const void __user *_payload,
+			    size_t plen,
+			    key_serial_t destringid);
+asmlinkage long compat_sys_request_key(const char __user *_type,
+				const char __user *_description,
+				const char __user *_callout_info,
+				key_serial_t destringid);
+asmlinkage long compat_sys_remap_file_pages(unsigned long start, unsigned long size,
+			unsigned long prot, unsigned long pgoff,
+			unsigned long flags);
+asmlinkage long compat_sys_inotify_add_watch(int fd, const char __user *path,
+					u32 mask);
+asmlinkage long compat_sys_mknodat(int dfd, const char __user * filename, umode_t mode,
+			    unsigned dev);
+asmlinkage long compat_sys_mkdirat(int dfd, const char __user * pathname, umode_t mode);
+asmlinkage long compat_sys_fchownat(int dfd, const char __user *filename, uid_t user,
+			     gid_t group, int flag);
+asmlinkage long compat_sys_unlinkat(int dfd, const char __user * pathname, int flag);
+asmlinkage long compat_sys_renameat(int olddfd, const char __user * oldname,
+			     int newdfd, const char __user * newname);
+asmlinkage long compat_sys_symlinkat(const char __user * oldname,
+			      int newdfd, const char __user * newname);
+asmlinkage long compat_sys_linkat(int olddfd, const char __user *oldname,
+			   int newdfd, const char __user *newname, int flags);
+asmlinkage long compat_sys_readlinkat(int dfd, const char __user *path, char __user *buf,
+			       int bufsiz);
+asmlinkage long compat_sys_fchmodat(int dfd, const char __user * filename,
+			     umode_t mode);
+asmlinkage long compat_sys_faccessat(int dfd, const char __user *filename, int mode);
+asmlinkage long compat_sys_unshare(unsigned long unshare_flags);
+asmlinkage long compat_sys_splice(int fd_in, loff_t __user *off_in,
+			   int fd_out, loff_t __user *off_out,
+			   size_t len, unsigned int flags);
+asmlinkage long compat_sys_tee(int fdin, int fdout, size_t len, unsigned int flags);
+asmlinkage long compat_sys_getcpu(unsigned __user *cpu, unsigned __user *node, struct getcpu_cache __user *cache);
+asmlinkage long compat_sys_pipe2(int __user *fildes, int flags);
+asmlinkage long compat_sys_perf_event_open(
+		struct perf_event_attr __user *attr_uptr,
+		pid_t pid, int cpu, int group_fd, unsigned long flags);
+
+#ifdef CONFIG_CLONE_BACKWARDS
+asmlinkage long compat_sys_clone(unsigned long, unsigned long, int __user *, unsigned long,
+	       int __user *);
+#else
+#ifdef CONFIG_CLONE_BACKWARDS3
+asmlinkage long compat_sys_clone(unsigned long, unsigned long, int, int __user *,
+			  int __user *, unsigned long);
+#else
+asmlinkage long compat_sys_clone(unsigned long, unsigned long, int __user *,
+	       int __user *, unsigned long);
+#endif
+#endif
+
+asmlinkage long compat_sys_prlimit64(pid_t pid, unsigned int resource,
+				const struct rlimit64 __user *new_rlim,
+				struct rlimit64 __user *old_rlim);
+asmlinkage long compat_sys_name_to_handle_at(int dfd, const char __user *name,
+				      struct file_handle __user *handle,
+				      int __user *mnt_id, int flag);
+asmlinkage long compat_sys_kcmp(pid_t pid1, pid_t pid2, int type,
+			 unsigned long idx1, unsigned long idx2);
+asmlinkage long compat_sys_finit_module(int fd, const char __user *uargs, int flags);
+asmlinkage long compat_sys_sched_setattr(pid_t pid,
+					struct sched_attr __user *attr,
+					unsigned int flags);
+asmlinkage long compat_sys_sched_getattr(pid_t pid,
+					struct sched_attr __user *attr,
+					unsigned int size,
+					unsigned int flags);
+asmlinkage long compat_sys_renameat2(int olddfd, const char __user *oldname,
+			      int newdfd, const char __user *newname,
+			      unsigned int flags);
+asmlinkage long compat_sys_seccomp(unsigned int op, unsigned int flags,
+			    const char __user *uargs);
+asmlinkage long compat_sys_getrandom(char __user *buf, size_t count,
+			      unsigned int flags);
+asmlinkage long compat_sys_memfd_create(const char __user *uname_ptr, unsigned int flags);
+asmlinkage long compat_sys_bpf(int cmd, union bpf_attr *attr, unsigned int size);
+asmlinkage long compat_sys_socketpair(int, int, int, int __user *);
+asmlinkage long compat_sys_bind(int, struct sockaddr __user *, int);
+asmlinkage long compat_sys_connect(int, struct sockaddr __user *, int);
+asmlinkage long compat_sys_accept4(int, struct sockaddr __user *, int __user *, int);
+asmlinkage long compat_sys_getsockname(int, struct sockaddr __user *, int __user *);
+asmlinkage long compat_sys_getpeername(int, struct sockaddr __user *, int __user *);
+asmlinkage long compat_sys_sendto(int, void __user *, size_t, unsigned,
+				struct sockaddr __user *, int);
+asmlinkage long compat_sys_mlock2(unsigned long start, size_t len, int flags);
+
+asmlinkage long compat_sys_copy_file_range(int fd_in, loff_t __user *off_in,
+				    int fd_out, loff_t __user *off_out,
+				    size_t len, unsigned int flags);
+
 #endif /* CONFIG_COMPAT_WRAPPER */
 
 #endif /* _LINUX_COMPAT_H */
diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
index f10a316..01d43b0 100644
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@ -36,43 +36,43 @@
 #define __NR_io_setup 0
 __SC_COMP(__NR_io_setup, sys_io_setup, compat_sys_io_setup)
 #define __NR_io_destroy 1
-__SYSCALL(__NR_io_destroy, sys_io_destroy)
+__SC_WRAP(__NR_io_destroy, sys_io_destroy)
 #define __NR_io_submit 2
 __SC_COMP(__NR_io_submit, sys_io_submit, compat_sys_io_submit)
 #define __NR_io_cancel 3
-__SYSCALL(__NR_io_cancel, sys_io_cancel)
+__SC_WRAP(__NR_io_cancel, sys_io_cancel)
 #define __NR_io_getevents 4
 __SC_COMP(__NR_io_getevents, sys_io_getevents, compat_sys_io_getevents)
 
 /* fs/xattr.c */
 #define __NR_setxattr 5
-__SYSCALL(__NR_setxattr, sys_setxattr)
+__SC_WRAP(__NR_setxattr, sys_setxattr)
 #define __NR_lsetxattr 6
-__SYSCALL(__NR_lsetxattr, sys_lsetxattr)
+__SC_WRAP(__NR_lsetxattr, sys_lsetxattr)
 #define __NR_fsetxattr 7
-__SYSCALL(__NR_fsetxattr, sys_fsetxattr)
+__SC_WRAP(__NR_fsetxattr, sys_fsetxattr)
 #define __NR_getxattr 8
-__SYSCALL(__NR_getxattr, sys_getxattr)
+__SC_WRAP(__NR_getxattr, sys_getxattr)
 #define __NR_lgetxattr 9
-__SYSCALL(__NR_lgetxattr, sys_lgetxattr)
+__SC_WRAP(__NR_lgetxattr, sys_lgetxattr)
 #define __NR_fgetxattr 10
-__SYSCALL(__NR_fgetxattr, sys_fgetxattr)
+__SC_WRAP(__NR_fgetxattr, sys_fgetxattr)
 #define __NR_listxattr 11
-__SYSCALL(__NR_listxattr, sys_listxattr)
+__SC_WRAP(__NR_listxattr, sys_listxattr)
 #define __NR_llistxattr 12
-__SYSCALL(__NR_llistxattr, sys_llistxattr)
+__SC_WRAP(__NR_llistxattr, sys_llistxattr)
 #define __NR_flistxattr 13
-__SYSCALL(__NR_flistxattr, sys_flistxattr)
+__SC_WRAP(__NR_flistxattr, sys_flistxattr)
 #define __NR_removexattr 14
-__SYSCALL(__NR_removexattr, sys_removexattr)
+__SC_WRAP(__NR_removexattr, sys_removexattr)
 #define __NR_lremovexattr 15
-__SYSCALL(__NR_lremovexattr, sys_lremovexattr)
+__SC_WRAP(__NR_lremovexattr, sys_lremovexattr)
 #define __NR_fremovexattr 16
-__SYSCALL(__NR_fremovexattr, sys_fremovexattr)
+__SC_WRAP(__NR_fremovexattr, sys_fremovexattr)
 
 /* fs/dcache.c */
 #define __NR_getcwd 17
-__SYSCALL(__NR_getcwd, sys_getcwd)
+__SC_WRAP(__NR_getcwd, sys_getcwd)
 
 /* fs/cookies.c */
 #define __NR_lookup_dcookie 18
@@ -86,7 +86,7 @@ __SYSCALL(__NR_eventfd2, sys_eventfd2)
 #define __NR_epoll_create1 20
 __SYSCALL(__NR_epoll_create1, sys_epoll_create1)
 #define __NR_epoll_ctl 21
-__SYSCALL(__NR_epoll_ctl, sys_epoll_ctl)
+__SC_WRAP(__NR_epoll_ctl, sys_epoll_ctl)
 #define __NR_epoll_pwait 22
 __SC_COMP(__NR_epoll_pwait, sys_epoll_pwait, compat_sys_epoll_pwait)
 
@@ -102,7 +102,7 @@ __SC_COMP_3264(__NR3264_fcntl, sys_fcntl64, sys_fcntl, compat_sys_fcntl64)
 #define __NR_inotify_init1 26
 __SYSCALL(__NR_inotify_init1, sys_inotify_init1)
 #define __NR_inotify_add_watch 27
-__SYSCALL(__NR_inotify_add_watch, sys_inotify_add_watch)
+__SC_WRAP(__NR_inotify_add_watch, sys_inotify_add_watch)
 #define __NR_inotify_rm_watch 28
 __SYSCALL(__NR_inotify_rm_watch, sys_inotify_rm_watch)
 
@@ -122,17 +122,17 @@ __SYSCALL(__NR_flock, sys_flock)
 
 /* fs/namei.c */
 #define __NR_mknodat 33
-__SYSCALL(__NR_mknodat, sys_mknodat)
+__SC_WRAP(__NR_mknodat, sys_mknodat)
 #define __NR_mkdirat 34
-__SYSCALL(__NR_mkdirat, sys_mkdirat)
+__SC_WRAP(__NR_mkdirat, sys_mkdirat)
 #define __NR_unlinkat 35
-__SYSCALL(__NR_unlinkat, sys_unlinkat)
+__SC_WRAP(__NR_unlinkat, sys_unlinkat)
 #define __NR_symlinkat 36
-__SYSCALL(__NR_symlinkat, sys_symlinkat)
+__SC_WRAP(__NR_symlinkat, sys_symlinkat)
 #define __NR_linkat 37
-__SYSCALL(__NR_linkat, sys_linkat)
+__SC_WRAP(__NR_linkat, sys_linkat)
 #define __NR_renameat 38
-__SYSCALL(__NR_renameat, sys_renameat)
+__SC_WRAP(__NR_renameat, sys_renameat)
 
 /* fs/namespace.c */
 #define __NR_umount2 39
@@ -140,7 +140,7 @@ __SYSCALL(__NR_umount2, sys_umount)
 #define __NR_mount 40
 __SC_COMP(__NR_mount, sys_mount, compat_sys_mount)
 #define __NR_pivot_root 41
-__SYSCALL(__NR_pivot_root, sys_pivot_root)
+__SC_WRAP(__NR_pivot_root, sys_pivot_root)
 
 /* fs/nfsctl.c */
 #define __NR_nfsservctl 42
@@ -163,23 +163,23 @@ __SC_COMP_3264(__NR3264_ftruncate, sys_ftruncate64, sys_ftruncate, \
 #define __NR_fallocate 47
 __SC_COMP(__NR_fallocate, sys_fallocate, compat_sys_fallocate)
 #define __NR_faccessat 48
-__SYSCALL(__NR_faccessat, sys_faccessat)
+__SC_WRAP(__NR_faccessat, sys_faccessat)
 #define __NR_chdir 49
-__SYSCALL(__NR_chdir, sys_chdir)
+__SC_WRAP(__NR_chdir, sys_chdir)
 #define __NR_fchdir 50
 __SYSCALL(__NR_fchdir, sys_fchdir)
 #define __NR_chroot 51
-__SYSCALL(__NR_chroot, sys_chroot)
+__SC_WRAP(__NR_chroot, sys_chroot)
 #define __NR_fchmod 52
 __SYSCALL(__NR_fchmod, sys_fchmod)
 #define __NR_fchmodat 53
-__SYSCALL(__NR_fchmodat, sys_fchmodat)
+__SC_WRAP(__NR_fchmodat, sys_fchmodat)
 #define __NR_fchownat 54
-__SYSCALL(__NR_fchownat, sys_fchownat)
+__SC_WRAP(__NR_fchownat, sys_fchownat)
 #define __NR_fchown 55
 __SYSCALL(__NR_fchown, sys_fchown)
 #define __NR_openat 56
-__SC_COMP(__NR_openat, sys_openat, compat_sys_openat)
+__SYSCALL(__NR_openat, sys_openat)
 #define __NR_close 57
 __SYSCALL(__NR_close, sys_close)
 #define __NR_vhangup 58
@@ -187,11 +187,11 @@ __SYSCALL(__NR_vhangup, sys_vhangup)
 
 /* fs/pipe.c */
 #define __NR_pipe2 59
-__SYSCALL(__NR_pipe2, sys_pipe2)
+__SC_WRAP(__NR_pipe2, sys_pipe2)
 
 /* fs/quota.c */
 #define __NR_quotactl 60
-__SYSCALL(__NR_quotactl, sys_quotactl)
+__SC_WRAP(__NR_quotactl, sys_quotactl)
 
 /* fs/readdir.c */
 #define __NR_getdents64 61
@@ -236,13 +236,13 @@ __SC_COMP(__NR_signalfd4, sys_signalfd4, compat_sys_signalfd4)
 #define __NR_vmsplice 75
 __SC_COMP(__NR_vmsplice, sys_vmsplice, compat_sys_vmsplice)
 #define __NR_splice 76
-__SYSCALL(__NR_splice, sys_splice)
+__SC_WRAP(__NR_splice, sys_splice)
 #define __NR_tee 77
-__SYSCALL(__NR_tee, sys_tee)
+__SC_WRAP(__NR_tee, sys_tee)
 
 /* fs/stat.c */
 #define __NR_readlinkat 78
-__SYSCALL(__NR_readlinkat, sys_readlinkat)
+__SC_WRAP(__NR_readlinkat, sys_readlinkat)
 #define __NR3264_fstatat 79
 __SC_3264(__NR3264_fstatat, sys_fstatat64, sys_newfstatat)
 #define __NR3264_fstat 80
@@ -281,13 +281,13 @@ __SC_COMP(__NR_utimensat, sys_utimensat, compat_sys_utimensat)
 
 /* kernel/acct.c */
 #define __NR_acct 89
-__SYSCALL(__NR_acct, sys_acct)
+__SC_WRAP(__NR_acct, sys_acct)
 
 /* kernel/capability.c */
 #define __NR_capget 90
-__SYSCALL(__NR_capget, sys_capget)
+__SC_WRAP(__NR_capget, sys_capget)
 #define __NR_capset 91
-__SYSCALL(__NR_capset, sys_capset)
+__SC_WRAP(__NR_capset, sys_capset)
 
 /* kernel/exec_domain.c */
 #define __NR_personality 92
@@ -303,9 +303,9 @@ __SC_COMP(__NR_waitid, sys_waitid, compat_sys_waitid)
 
 /* kernel/fork.c */
 #define __NR_set_tid_address 96
-__SYSCALL(__NR_set_tid_address, sys_set_tid_address)
+__SC_WRAP(__NR_set_tid_address, sys_set_tid_address)
 #define __NR_unshare 97
-__SYSCALL(__NR_unshare, sys_unshare)
+__SC_WRAP(__NR_unshare, sys_unshare)
 
 /* kernel/futex.c */
 #define __NR_futex 98
@@ -333,9 +333,9 @@ __SC_COMP(__NR_kexec_load, sys_kexec_load, compat_sys_kexec_load)
 
 /* kernel/module.c */
 #define __NR_init_module 105
-__SYSCALL(__NR_init_module, sys_init_module)
+__SC_WRAP(__NR_init_module, sys_init_module)
 #define __NR_delete_module 106
-__SYSCALL(__NR_delete_module, sys_delete_module)
+__SC_WRAP(__NR_delete_module, sys_delete_module)
 
 /* kernel/posix-timers.c */
 #define __NR_timer_create 107
@@ -360,7 +360,7 @@ __SC_COMP(__NR_clock_nanosleep, sys_clock_nanosleep, \
 
 /* kernel/printk.c */
 #define __NR_syslog 116
-__SYSCALL(__NR_syslog, sys_syslog)
+__SC_WRAP(__NR_syslog, sys_syslog)
 
 /* kernel/ptrace.c */
 #define __NR_ptrace 117
@@ -368,13 +368,13 @@ __SYSCALL(__NR_ptrace, sys_ptrace)
 
 /* kernel/sched/core.c */
 #define __NR_sched_setparam 118
-__SYSCALL(__NR_sched_setparam, sys_sched_setparam)
+__SC_WRAP(__NR_sched_setparam, sys_sched_setparam)
 #define __NR_sched_setscheduler 119
-__SYSCALL(__NR_sched_setscheduler, sys_sched_setscheduler)
+__SC_WRAP(__NR_sched_setscheduler, sys_sched_setscheduler)
 #define __NR_sched_getscheduler 120
 __SYSCALL(__NR_sched_getscheduler, sys_sched_getscheduler)
 #define __NR_sched_getparam 121
-__SYSCALL(__NR_sched_getparam, sys_sched_getparam)
+__SC_WRAP(__NR_sched_getparam, sys_sched_getparam)
 #define __NR_sched_setaffinity 122
 __SC_COMP(__NR_sched_setaffinity, sys_sched_setaffinity, \
 	  compat_sys_sched_setaffinity)
@@ -425,7 +425,7 @@ __SYSCALL(__NR_setpriority, sys_setpriority)
 #define __NR_getpriority 141
 __SYSCALL(__NR_getpriority, sys_getpriority)
 #define __NR_reboot 142
-__SYSCALL(__NR_reboot, sys_reboot)
+__SC_WRAP(__NR_reboot, sys_reboot)
 #define __NR_setregid 143
 __SYSCALL(__NR_setregid, sys_setregid)
 #define __NR_setgid 144
@@ -437,11 +437,11 @@ __SYSCALL(__NR_setuid, sys_setuid)
 #define __NR_setresuid 147
 __SYSCALL(__NR_setresuid, sys_setresuid)
 #define __NR_getresuid 148
-__SYSCALL(__NR_getresuid, sys_getresuid)
+__SC_WRAP(__NR_getresuid, sys_getresuid)
 #define __NR_setresgid 149
 __SYSCALL(__NR_setresgid, sys_setresgid)
 #define __NR_getresgid 150
-__SYSCALL(__NR_getresgid, sys_getresgid)
+__SC_WRAP(__NR_getresgid, sys_getresgid)
 #define __NR_setfsuid 151
 __SYSCALL(__NR_setfsuid, sys_setfsuid)
 #define __NR_setfsgid 152
@@ -457,15 +457,15 @@ __SYSCALL(__NR_getsid, sys_getsid)
 #define __NR_setsid 157
 __SYSCALL(__NR_setsid, sys_setsid)
 #define __NR_getgroups 158
-__SYSCALL(__NR_getgroups, sys_getgroups)
+__SC_WRAP(__NR_getgroups, sys_getgroups)
 #define __NR_setgroups 159
-__SYSCALL(__NR_setgroups, sys_setgroups)
+__SC_WRAP(__NR_setgroups, sys_setgroups)
 #define __NR_uname 160
-__SYSCALL(__NR_uname, sys_newuname)
+__SC_WRAP(__NR_uname, sys_newuname)
 #define __NR_sethostname 161
-__SYSCALL(__NR_sethostname, sys_sethostname)
+__SC_WRAP(__NR_sethostname, sys_sethostname)
 #define __NR_setdomainname 162
-__SYSCALL(__NR_setdomainname, sys_setdomainname)
+__SC_WRAP(__NR_setdomainname, sys_setdomainname)
 #define __NR_getrlimit 163
 __SC_COMP(__NR_getrlimit, sys_getrlimit, compat_sys_getrlimit)
 #define __NR_setrlimit 164
@@ -475,9 +475,9 @@ __SC_COMP(__NR_getrusage, sys_getrusage, compat_sys_getrusage)
 #define __NR_umask 166
 __SYSCALL(__NR_umask, sys_umask)
 #define __NR_prctl 167
-__SYSCALL(__NR_prctl, sys_prctl)
+__SC_WRAP(__NR_prctl, sys_prctl)
 #define __NR_getcpu 168
-__SYSCALL(__NR_getcpu, sys_getcpu)
+__SC_WRAP(__NR_getcpu, sys_getcpu)
 
 /* kernel/time.c */
 #define __NR_gettimeofday 169
@@ -509,7 +509,7 @@ __SC_COMP(__NR_sysinfo, sys_sysinfo, compat_sys_sysinfo)
 #define __NR_mq_open 180
 __SC_COMP(__NR_mq_open, sys_mq_open, compat_sys_mq_open)
 #define __NR_mq_unlink 181
-__SYSCALL(__NR_mq_unlink, sys_mq_unlink)
+__SC_WRAP(__NR_mq_unlink, sys_mq_unlink)
 #define __NR_mq_timedsend 182
 __SC_COMP(__NR_mq_timedsend, sys_mq_timedsend, compat_sys_mq_timedsend)
 #define __NR_mq_timedreceive 183
@@ -554,21 +554,21 @@ __SYSCALL(__NR_shmdt, sys_shmdt)
 #define __NR_socket 198
 __SYSCALL(__NR_socket, sys_socket)
 #define __NR_socketpair 199
-__SYSCALL(__NR_socketpair, sys_socketpair)
+__SC_WRAP(__NR_socketpair, sys_socketpair)
 #define __NR_bind 200
-__SYSCALL(__NR_bind, sys_bind)
+__SC_WRAP(__NR_bind, sys_bind)
 #define __NR_listen 201
 __SYSCALL(__NR_listen, sys_listen)
 #define __NR_accept 202
 __SYSCALL(__NR_accept, sys_accept)
 #define __NR_connect 203
-__SYSCALL(__NR_connect, sys_connect)
+__SC_WRAP(__NR_connect, sys_connect)
 #define __NR_getsockname 204
-__SYSCALL(__NR_getsockname, sys_getsockname)
+__SC_WRAP(__NR_getsockname, sys_getsockname)
 #define __NR_getpeername 205
-__SYSCALL(__NR_getpeername, sys_getpeername)
+__SC_WRAP(__NR_getpeername, sys_getpeername)
 #define __NR_sendto 206
-__SYSCALL(__NR_sendto, sys_sendto)
+__SC_WRAP(__NR_sendto, sys_sendto)
 #define __NR_recvfrom 207
 __SC_COMP(__NR_recvfrom, sys_recvfrom, compat_sys_recvfrom)
 #define __NR_setsockopt 208
@@ -588,23 +588,23 @@ __SC_COMP(__NR_readahead, sys_readahead, compat_sys_readahead)
 
 /* mm/nommu.c, also with MMU */
 #define __NR_brk 214
-__SYSCALL(__NR_brk, sys_brk)
+__SC_WRAP(__NR_brk, sys_brk)
 #define __NR_munmap 215
-__SYSCALL(__NR_munmap, sys_munmap)
+__SC_WRAP(__NR_munmap, sys_munmap)
 #define __NR_mremap 216
-__SYSCALL(__NR_mremap, sys_mremap)
+__SC_WRAP(__NR_mremap, sys_mremap)
 
 /* security/keys/keyctl.c */
 #define __NR_add_key 217
-__SYSCALL(__NR_add_key, sys_add_key)
+__SC_WRAP(__NR_add_key, sys_add_key)
 #define __NR_request_key 218
-__SYSCALL(__NR_request_key, sys_request_key)
+__SC_WRAP(__NR_request_key, sys_request_key)
 #define __NR_keyctl 219
 __SC_COMP(__NR_keyctl, sys_keyctl, compat_sys_keyctl)
 
 /* arch/example/kernel/sys_example.c */
 #define __NR_clone 220
-__SYSCALL(__NR_clone, sys_clone)
+__SC_WRAP(__NR_clone, sys_clone)
 #define __NR_execve 221
 __SC_COMP(__NR_execve, sys_execve, compat_sys_execve)
 
@@ -617,27 +617,27 @@ __SC_COMP(__NR3264_fadvise64, sys_fadvise64_64, compat_sys_fadvise64_64)
 /* mm/, CONFIG_MMU only */
 #ifndef __ARCH_NOMMU
 #define __NR_swapon 224
-__SYSCALL(__NR_swapon, sys_swapon)
+__SC_WRAP(__NR_swapon, sys_swapon)
 #define __NR_swapoff 225
-__SYSCALL(__NR_swapoff, sys_swapoff)
+__SC_WRAP(__NR_swapoff, sys_swapoff)
 #define __NR_mprotect 226
-__SYSCALL(__NR_mprotect, sys_mprotect)
+__SC_WRAP(__NR_mprotect, sys_mprotect)
 #define __NR_msync 227
-__SYSCALL(__NR_msync, sys_msync)
+__SC_WRAP(__NR_msync, sys_msync)
 #define __NR_mlock 228
-__SYSCALL(__NR_mlock, sys_mlock)
+__SC_WRAP(__NR_mlock, sys_mlock)
 #define __NR_munlock 229
-__SYSCALL(__NR_munlock, sys_munlock)
+__SC_WRAP(__NR_munlock, sys_munlock)
 #define __NR_mlockall 230
 __SYSCALL(__NR_mlockall, sys_mlockall)
 #define __NR_munlockall 231
 __SYSCALL(__NR_munlockall, sys_munlockall)
 #define __NR_mincore 232
-__SYSCALL(__NR_mincore, sys_mincore)
+__SC_WRAP(__NR_mincore, sys_mincore)
 #define __NR_madvise 233
-__SYSCALL(__NR_madvise, sys_madvise)
+__SC_WRAP(__NR_madvise, sys_madvise)
 #define __NR_remap_file_pages 234
-__SYSCALL(__NR_remap_file_pages, sys_remap_file_pages)
+__SC_WRAP(__NR_remap_file_pages, sys_remap_file_pages)
 #define __NR_mbind 235
 __SC_COMP(__NR_mbind, sys_mbind, compat_sys_mbind)
 #define __NR_get_mempolicy 236
@@ -654,9 +654,9 @@ __SC_COMP(__NR_move_pages, sys_move_pages, compat_sys_move_pages)
 __SC_COMP(__NR_rt_tgsigqueueinfo, sys_rt_tgsigqueueinfo, \
 	  compat_sys_rt_tgsigqueueinfo)
 #define __NR_perf_event_open 241
-__SYSCALL(__NR_perf_event_open, sys_perf_event_open)
+__SC_WRAP(__NR_perf_event_open, sys_perf_event_open)
 #define __NR_accept4 242
-__SYSCALL(__NR_accept4, sys_accept4)
+__SC_WRAP(__NR_accept4, sys_accept4)
 #define __NR_recvmmsg 243
 __SC_COMP(__NR_recvmmsg, sys_recvmmsg, compat_sys_recvmmsg)
 
@@ -669,16 +669,15 @@ __SC_COMP(__NR_recvmmsg, sys_recvmmsg, compat_sys_recvmmsg)
 #define __NR_wait4 260
 __SC_COMP(__NR_wait4, sys_wait4, compat_sys_wait4)
 #define __NR_prlimit64 261
-__SYSCALL(__NR_prlimit64, sys_prlimit64)
+__SC_WRAP(__NR_prlimit64, sys_prlimit64)
 #define __NR_fanotify_init 262
 __SYSCALL(__NR_fanotify_init, sys_fanotify_init)
 #define __NR_fanotify_mark 263
 __SYSCALL(__NR_fanotify_mark, sys_fanotify_mark)
 #define __NR_name_to_handle_at         264
-__SYSCALL(__NR_name_to_handle_at, sys_name_to_handle_at)
+__SC_WRAP(__NR_name_to_handle_at, sys_name_to_handle_at)
 #define __NR_open_by_handle_at         265
-__SC_COMP(__NR_open_by_handle_at, sys_open_by_handle_at, \
-	  compat_sys_open_by_handle_at)
+__SYSCALL(__NR_open_by_handle_at, sys_open_by_handle_at)
 #define __NR_clock_adjtime 266
 __SC_COMP(__NR_clock_adjtime, sys_clock_adjtime, compat_sys_clock_adjtime)
 #define __NR_syncfs 267
@@ -694,23 +693,23 @@ __SC_COMP(__NR_process_vm_readv, sys_process_vm_readv, \
 __SC_COMP(__NR_process_vm_writev, sys_process_vm_writev, \
           compat_sys_process_vm_writev)
 #define __NR_kcmp 272
-__SYSCALL(__NR_kcmp, sys_kcmp)
+__SC_WRAP(__NR_kcmp, sys_kcmp)
 #define __NR_finit_module 273
-__SYSCALL(__NR_finit_module, sys_finit_module)
+__SC_WRAP(__NR_finit_module, sys_finit_module)
 #define __NR_sched_setattr 274
-__SYSCALL(__NR_sched_setattr, sys_sched_setattr)
+__SC_WRAP(__NR_sched_setattr, sys_sched_setattr)
 #define __NR_sched_getattr 275
-__SYSCALL(__NR_sched_getattr, sys_sched_getattr)
+__SC_WRAP(__NR_sched_getattr, sys_sched_getattr)
 #define __NR_renameat2 276
-__SYSCALL(__NR_renameat2, sys_renameat2)
+__SC_WRAP(__NR_renameat2, sys_renameat2)
 #define __NR_seccomp 277
-__SYSCALL(__NR_seccomp, sys_seccomp)
+__SC_WRAP(__NR_seccomp, sys_seccomp)
 #define __NR_getrandom 278
-__SYSCALL(__NR_getrandom, sys_getrandom)
+__SC_WRAP(__NR_getrandom, sys_getrandom)
 #define __NR_memfd_create 279
-__SYSCALL(__NR_memfd_create, sys_memfd_create)
+__SC_WRAP(__NR_memfd_create, sys_memfd_create)
 #define __NR_bpf 280
-__SYSCALL(__NR_bpf, sys_bpf)
+__SC_WRAP(__NR_bpf, sys_bpf)
 #define __NR_execveat 281
 __SC_COMP(__NR_execveat, sys_execveat, compat_sys_execveat)
 #define __NR_userfaultfd 282
@@ -718,9 +717,9 @@ __SYSCALL(__NR_userfaultfd, sys_userfaultfd)
 #define __NR_membarrier 283
 __SYSCALL(__NR_membarrier, sys_membarrier)
 #define __NR_mlock2 284
-__SYSCALL(__NR_mlock2, sys_mlock2)
+__SC_WRAP(__NR_mlock2, sys_mlock2)
 #define __NR_copy_file_range 285
-__SYSCALL(__NR_copy_file_range, sys_copy_file_range)
+__SC_WRAP(__NR_copy_file_range, sys_copy_file_range)
 
 #undef __NR_syscalls
 #define __NR_syscalls 286
@@ -737,29 +736,29 @@ __SYSCALL(__NR_copy_file_range, sys_copy_file_range)
 #define __NR_open 1024
 __SYSCALL(__NR_open, sys_open)
 #define __NR_link 1025
-__SYSCALL(__NR_link, sys_link)
+__SC_WRAP(__NR_link, sys_link)
 #define __NR_unlink 1026
-__SYSCALL(__NR_unlink, sys_unlink)
+__SC_WRAP(__NR_unlink, sys_unlink)
 #define __NR_mknod 1027
-__SYSCALL(__NR_mknod, sys_mknod)
+__SC_WRAP(__NR_mknod, sys_mknod)
 #define __NR_chmod 1028
-__SYSCALL(__NR_chmod, sys_chmod)
+__SC_WRAP(__NR_chmod, sys_chmod)
 #define __NR_chown 1029
-__SYSCALL(__NR_chown, sys_chown)
+__SC_WRAP(__NR_chown, sys_chown)
 #define __NR_mkdir 1030
-__SYSCALL(__NR_mkdir, sys_mkdir)
+__SC_WRAP(__NR_mkdir, sys_mkdir)
 #define __NR_rmdir 1031
-__SYSCALL(__NR_rmdir, sys_rmdir)
+__SC_WRAP(__NR_rmdir, sys_rmdir)
 #define __NR_lchown 1032
-__SYSCALL(__NR_lchown, sys_lchown)
+__SC_WRAP(__NR_lchown, sys_lchown)
 #define __NR_access 1033
-__SYSCALL(__NR_access, sys_access)
+__SC_WRAP(__NR_access, sys_access)
 #define __NR_rename 1034
-__SYSCALL(__NR_rename, sys_rename)
+__SC_WRAP(__NR_rename, sys_rename)
 #define __NR_readlink 1035
-__SYSCALL(__NR_readlink, sys_readlink)
+__SC_WRAP(__NR_readlink, sys_readlink)
 #define __NR_symlink 1036
-__SYSCALL(__NR_symlink, sys_symlink)
+__SC_WRAP(__NR_symlink, sys_symlink)
 #define __NR_utimes 1037
 __SYSCALL(__NR_utimes, sys_utimes)
 #define __NR3264_stat 1038
@@ -773,7 +772,7 @@ __SC_3264(__NR3264_lstat, sys_lstat64, sys_newlstat)
 
 #ifdef __ARCH_WANT_SYSCALL_NO_FLAGS
 #define __NR_pipe 1040
-__SYSCALL(__NR_pipe, sys_pipe)
+__SC_WRAP(__NR_pipe, sys_pipe)
 #define __NR_dup2 1041
 __SYSCALL(__NR_dup2, sys_dup2)
 #define __NR_epoll_create 1042
@@ -843,7 +842,7 @@ __SYSCALL(__NR_time, sys_time)
 __SYSCALL(__NR_utime, sys_utime)
 
 #define __NR_creat 1064
-__SYSCALL(__NR_creat, sys_creat)
+__SC_WRAP(__NR_creat, sys_creat)
 #define __NR_getdents 1065
 #define __ARCH_WANT_SYS_GETDENTS
 __SYSCALL(__NR_getdents, sys_getdents)
@@ -853,9 +852,9 @@ __SYSCALL(__NR_futimesat, sys_futimesat)
 #define __ARCH_WANT_SYS_SELECT
 __SYSCALL(__NR_select, sys_select)
 #define __NR_poll 1068
-__SYSCALL(__NR_poll, sys_poll)
+__SC_WRAP(__NR_poll, sys_poll)
 #define __NR_epoll_wait 1069
-__SYSCALL(__NR_epoll_wait, sys_epoll_wait)
+__SC_WRAP(__NR_epoll_wait, sys_epoll_wait)
 #define __NR_ustat 1070
 __SYSCALL(__NR_ustat, sys_ustat)
 #define __NR_vfork 1071
@@ -867,12 +866,12 @@ __SYSCALL(__NR_recv, sys_recv)
 #define __NR_send 1074
 __SYSCALL(__NR_send, sys_send)
 #define __NR_bdflush 1075
-__SYSCALL(__NR_bdflush, sys_bdflush)
+__SC_WRAP(__NR_bdflush, sys_bdflush)
 #define __NR_umount 1076
-__SYSCALL(__NR_umount, sys_oldumount)
+__SC_WRAP(__NR_umount, sys_oldumount)
 #define __ARCH_WANT_SYS_OLDUMOUNT
 #define __NR_uselib 1077
-__SYSCALL(__NR_uselib, sys_uselib)
+__SC_WRAP(__NR_uselib, sys_uselib)
 #define __NR__sysctl 1078
 __SYSCALL(__NR__sysctl, sys_sysctl)
 
-- 
2.5.0



From w at 1wt.eu  Wed Feb 24 10:41:14 2016
From: w at 1wt.eu (Willy Tarreau)
Date: Wed, 24 Feb 2016 19:41:14 +0100
Subject: [PATCH 1/2] ARM: mvebu: change order of ethernet DT nodes on
 Armada 38x
In-Reply-To: <20160129114853.GQ10826@n2100.arm.linux.org.uk>
References: <1453907300-28283-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1453907300-28283-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160127193143.GF10826@n2100.arm.linux.org.uk>
 <20160127194512.GA16638@1wt.eu>
 <20160129114853.GQ10826@n2100.arm.linux.org.uk>
Message-ID: <20160224184114.GB2292@1wt.eu>

Hi Russell,

On Fri, Jan 29, 2016 at 11:48:53AM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 27, 2016 at 08:45:12PM +0100, Willy Tarreau wrote:
> > On Wed, Jan 27, 2016 at 07:31:44PM +0000, Russell King - ARM Linux wrote:
> > (...)
> > > > For example, on the Armada 388 GP, the board has two ports, labelled
> > > > GE0 and GE1. One has to know that GE0 is eth1 and GE1 is eth0, which
> > > > isn't really obvious.
> > > > 
> > > > In order to solve this, this patch proposes to exceptionaly violate
> > > > the rule of "order DT nodes by register address", and put the 0x70000
> > > > node before the 0x30000 node, so that network interfaces get named in
> > > > a more natural way.
> > > 
> > > The danger is that this will completely mess up people's existing
> > > scripts/distro configuration which are now used to the current
> > > labelling of the network ports.
> > > 
> > > Not every distro provides a sane way to deal with this...
> > 
> > Well, may be that's one more reason for fixing it before boards start to
> > ship and run distro kernels. If some boards are already in the wild running
> > on a BSP kernel, people will complain that mainline reorders their network
> > ports and will stick to the BSP kernel instead.
> 
> I've checked, and we believe not many people are using mainline kernels
> on clearfog.  I'll have to adjust my debian jessie setup to fix the
> resulting carnage though.  On the plus side, it means that mainline
> matches Marvell's kernel for interface naming.

Well, now I'm one of these and I confirm that it's really painful to
have a different ordering between the DTB provided in mainline and the
DTB provided with the board. The worst thing is that using mainline,
eth0 corresponds to the switch and appears up, so you don't immediately
realize that it's not where your cable is connected :-/

Thus could we please get Thomas' patch to ensure that the board boots
with similar interface naming with both the original and mainline kernel ?

Thanks in advance,
Willy



From olof at lixom.net  Wed Feb 24 10:46:09 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 10:46:09 -0800
Subject: [PATCH 00/13] arm-cci: PMU driver updates for 4.6
In-Reply-To: <20160224171218.GC12471@arm.com>
References: <1456224595-3282-1-git-send-email-suzuki.poulose@arm.com>
 <20160223114003.GF3966@arm.com> <56CC64E7.3040407@arm.com>
 <20160224165814.GA10126@localhost> <20160224171218.GC12471@arm.com>
Message-ID: <CAOesGMhYP8tQXVYX70_U2EYnvOdTtE2xgDi77dKRkJsyjypgDw@mail.gmail.com>

On Wed, Feb 24, 2016 at 9:12 AM, Will Deacon <will.deacon at arm.com> wrote:
> On Wed, Feb 24, 2016 at 08:58:14AM -0800, Olof Johansson wrote:
>> On Tue, Feb 23, 2016 at 01:55:51PM +0000, Suzuki K. Poulose wrote:
>> > On 23/02/16 11:40, Will Deacon wrote:
>> > >On Tue, Feb 23, 2016 at 10:49:42AM +0000, Suzuki K Poulose wrote:
>> > >>Here are some fixes and updates for arm-cci pmu driver targeting v4.6,
>> > >>applies on top of v4.5-rc5.
>> > >>
>> > >>Highlights include :
>> > >>  - Support for CoreLink CCI-550 PMU
>> > >>  - Reliable writes to PMU Counter registers for CCI-500/550.
>> > >>
>> > >>All the patches have been Acked. Please let me know how this
>> > >>can be merged.
>> >
>> > >>
>> > >>  Documentation/devicetree/bindings/arm/cci.txt |    2 +
>> > >>  drivers/bus/Kconfig                           |   10 +-
>> > >>  drivers/bus/arm-cci.c                         |  612 +++++++++++++++++--------
>> > >>  3 files changed, 427 insertions(+), 197 deletions(-)
>> > >
>> > >How do you plan to merge this? I can take it all onto a branch for
>> > >arm-soc, or I can include it on my perf/updates branch, or ...?
>> >
>> > Arnd, Olof,
>> >
>> > What do you think would be the best route ?
>>
>> Traditionally we've been picking these up in arm-soc in our drivers branch.
>>
>> Will, unless you want them in your tree for some reason that's what I'll do
>> here as well.
>
> Just that I already have some CPU PMU patches that I planned to send, so
> I could bundle these in with those if necessary. I have no preference
> either way though, as long as they get queued someplace.

Ok, I'm alright with you queueing these if that makes it easier. Feel
free to add:

Acked-by: Olof Johansson <olof at lixom.net>

Only concern is if we cause confusion on where people should send
these patches down the road, but there aren't that many authors of
them so it's not a huge problem.

> At some point, those drivers should be largely moved from drivers/bus/
> to drivers/perf/, but that's a separate issue.

And with a maintainer on that, that'd resolve the "where do I send
this" issue. The maintainer, of course, needs to know where to feed
things next, but that's easier to solve.


-Olof


From stern at rowland.harvard.edu  Wed Feb 24 10:47:44 2016
From: stern at rowland.harvard.edu (Alan Stern)
Date: Wed, 24 Feb 2016 13:47:44 -0500 (EST)
Subject: [PATCH v3 1/2] ehci-platform: Add support for controllers with
 multiple reset lines
In-Reply-To: <56CD960D.3000900@ti.com>
Message-ID: <Pine.LNX.4.44L0.1602241345350.3812-100000@iolanthe.rowland.org>

On Wed, 24 Feb 2016, Roger Quadros wrote:

> Hi,
> 
> On 24/02/16 13:15, Hans de Goede wrote:
> > From: Reinder de Haan <patchesrdh at mveas.com>
> > 
> > At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
> > reset lines, the controller will not initialize while the reset for
> > its companion is still asserted, which means we need to de-assert
> > 2 resets for the controller to work.
> > 
> > Signed-off-by: Reinder de Haan <patchesrdh at mveas.com>
> > Signed-off-by: Hans de Goede <hdegoede at redhat.com>

> > -	} else {
> > -		err = reset_control_deassert(priv->rst);
> > -		if (err)
> > -			goto err_put_clks;
> > +		for (rst = 0; rst < EHCI_MAX_RESETS; rst++) {
> > +			priv->resets[rst] =
> > +				devm_reset_control_get_shared_by_index(
> > +								&dev->dev, rst);

Ugly continuation line.  The convention in these files is to indent 
continuation lines by two tab stops beyond the original source line.
Same comment applies to the 2/2 patch.

Once that is changed, you can add:

Acked-by: Alan Stern <stern at rowland.harvard.edu>

to both.

Alan Stern



From tchalamarla at caviumnetworks.com  Wed Feb 24 10:53:10 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Wed, 24 Feb 2016 10:53:10 -0800
Subject: [PATCH V2] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <56CDB270.7040706@arm.com>
References: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>
 <56CC4E48.1060103@arm.com> <56CCF198.3090409@caviumnetworks.com>
 <56CDB270.7040706@arm.com>
Message-ID: <56CDFC16.5000202@caviumnetworks.com>



On 02/24/2016 05:38 AM, Robin Murphy wrote:
> On 23/02/16 23:56, Tirumalesh Chalamarla wrote:
>>
>>
>> On 02/23/2016 04:19 AM, Robin Murphy wrote:
>>> On 18/02/16 18:29, tchalamarla at caviumnetworks.com wrote:
>>>> From: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>>>>
>>>> Due to Errata#27704 CN88xx SMMUv2,supports  only shared ASID and VMID
>>>> namespaces; specifically within a given node SMMU0 and SMMU1 share,
>>>> as does SMMU2 and SMMU3.
>>>>
>>>> This patch tries to address these issuee by supplying asid and vmid
>>>> base from devicetree.
>>>>
>>>> changes from V1:
>>>>     - rebased on top of 16 bit VMID patch
>>>>     - removed redundent options from DT
>>>>     - insted of transform, DT now supplies starting ASID/VMID
>>>>
>>>> Signed-off-by: Akula Geethasowjanya
>>>> <Geethasowjanya.Akula at caviumnetworks.com>
>>>> Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
>>>> ---
>>>>   .../devicetree/bindings/iommu/arm,smmu.txt         |  8 +++++
>>>>   drivers/iommu/arm-smmu.c                           | 37
>>>> +++++++++++++++-------
>>>>   2 files changed, 34 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>>>> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>>>> index bb7e569..80b8484 100644
>>>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>>>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
>>>> @@ -57,6 +57,14 @@ conditions.
>>>>
>>>>   - smmu-enable-vmid16 : Enable 16 bit VMID, if allowed.
>>>>
>>>> +- asid-base :    Buggy SMMUv2 implementations which doesn't satisfy
>>>> the
>>>> +        ASID namespace needs, use this field to specify starting
>>>> +        ASID for the SMMU.
>>>> +
>>>> +- vmid-base :    Buggy SMMUv2 implementations which doesn't satisfy
>>>> the VMID
>>>> +        namespace needs, use this field to specify starting VMID
>>>> +        for the SMMU.
>>>> +
>>>
>>>  From how you've described the situation, this is still just some
>>> arbitrary number for the sake of a driver workaround and not an actual
>>> property of the hardware. Either way there should be a proper compatible
>>> string for this implementation, e.g. something like
>>> "cavium,cn88xx-smmu".
>>>
>>> Given that, you then shouldn't actually need anything else, because you
>>> can simply keep track of how many Cavium SMMUs have been probed and
>>> automatically generate a suitable offset, e.g. (smmu->index *
>>> ARM_SMMU_MAX_CBS) to ensure global ASID/VMID uniqueness.
>>
>> This particular solution might not be accurate in all cases. what
>> happens if SMMU stage 1 is used by a guest?
>
> Even if we supported passing through stage 1 contexts, which we don't, a
> malicious guest can freely ignore your arbitrary numbers in the DT, put
> whatever nonsense it feels like in the TTBRs, and corrupt I/O in other
> guests and/or the host.
>
> You cannot safely pass through raw stage 1 contexts on this hardware, so
> it's a non-issue.
>
Agreed. will re post based on the suggestions.
> Robin.
>
>>>>   Example:
>>>>
>>>>           smmu {
>>>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>>>> index 003c442..dc46b9a 100644
>>>> --- a/drivers/iommu/arm-smmu.c
>>>> +++ b/drivers/iommu/arm-smmu.c
>>>> @@ -320,6 +320,9 @@ struct arm_smmu_device {
>>>>       unsigned long            ipa_size;
>>>>       unsigned long            pa_size;
>>>>
>>>> +    u32                asid_base;
>>>> +    u32                vmid_base;
>>>> +
>>>>       u32                num_global_irqs;
>>>>       u32                num_context_irqs;
>>>>       unsigned int            *irqs;
>>>> @@ -335,8 +338,8 @@ struct arm_smmu_cfg {
>>>>   };
>>>>   #define INVALID_IRPTNDX            0xff
>>>>
>>>> -#define ARM_SMMU_CB_ASID(cfg)        ((cfg)->cbndx)
>>>> -#define ARM_SMMU_CB_VMID(cfg)        ((cfg)->cbndx + 1)
>>>> +#define ARM_SMMU_CB_ASID(smmu, cfg)    ((u16)((smmu)->asid_base +
>>>> (cfg)->cbndx))
>>>> +#define ARM_SMMU_CB_VMID(smmu, cfg)    ((u16)((smmu)->vmid_base +
>>>> (cfg)->cbndx))
>>>>
>>>>   enum arm_smmu_domain_stage {
>>>>       ARM_SMMU_DOMAIN_S1 = 0,
>>>> @@ -576,11 +579,11 @@ static void arm_smmu_tlb_inv_context(void
>>>> *cookie)
>>>>
>>>>       if (stage1) {
>>>>           base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu,
>>>> cfg->cbndx);
>>>> -        writel_relaxed(ARM_SMMU_CB_ASID(cfg),
>>>> +        writel_relaxed(ARM_SMMU_CB_ASID(smmu, cfg),
>>>>                      base + ARM_SMMU_CB_S1_TLBIASID);
>>>>       } else {
>>>>           base = ARM_SMMU_GR0(smmu);
>>>> -        writel_relaxed(ARM_SMMU_CB_VMID(cfg),
>>>> +        writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg),
>>>>                      base + ARM_SMMU_GR0_TLBIVMID);
>>>>       }
>>>>
>>>> @@ -602,7 +605,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned
>>>> long iova, size_t size,
>>>>
>>>>           if (!IS_ENABLED(CONFIG_64BIT) || smmu->version ==
>>>> ARM_SMMU_V1) {
>>>>               iova &= ~12UL;
>>>> -            iova |= ARM_SMMU_CB_ASID(cfg);
>>>> +            iova |= ARM_SMMU_CB_ASID(smmu, cfg);
>>>>               do {
>>>>                   writel_relaxed(iova, reg);
>>>>                   iova += granule;
>>>> @@ -610,7 +613,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned
>>>> long iova, size_t size,
>>>>   #ifdef CONFIG_64BIT
>>>>           } else {
>>>>               iova >>= 12;
>>>> -            iova |= (u64)ARM_SMMU_CB_ASID(cfg) << 48;
>>>> +            iova |= (u64)ARM_SMMU_CB_ASID(smmu, cfg) << 48;
>>>>               do {
>>>>                   writeq_relaxed(iova, reg);
>>>>                   iova += granule >> 12;
>>>> @@ -630,7 +633,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned
>>>> long iova, size_t size,
>>>>   #endif
>>>>       } else {
>>>>           reg = ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_TLBIVMID;
>>>> -        writel_relaxed(ARM_SMMU_CB_VMID(cfg), reg);
>>>> +        writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg), reg);
>>>>       }
>>>>   }
>>>>
>>>> @@ -744,7 +747,7 @@ static void arm_smmu_init_context_bank(struct
>>>> arm_smmu_domain *smmu_domain,
>>>>   #endif
>>>>           /* if 16bit VMID required set VMID in CBA2R */
>>>>           if (smmu->options & ARM_SMMU_OPT_ENABLE_VMID16)
>>>> -            reg |= ARM_SMMU_CB_VMID(cfg) << CBA2R_VMID_SHIFT;
>>>> +            reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBA2R_VMID_SHIFT;
>>>>
>>>>           writel_relaxed(reg, gr1_base +
>>>> ARM_SMMU_GR1_CBA2R(cfg->cbndx));
>>>>       }
>>>> @@ -763,7 +766,7 @@ static void arm_smmu_init_context_bank(struct
>>>> arm_smmu_domain *smmu_domain,
>>>>               (CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
>>>>       } else if (!(smmu->options & ARM_SMMU_OPT_ENABLE_VMID16)) {
>>>>           /*16 bit VMID is not enabled set 8 bit VMID here */
>>>> -        reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
>>>> +        reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBAR_VMID_SHIFT;
>>>>       }
>>>>       writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
>>>>
>>>> @@ -771,11 +774,11 @@ static void arm_smmu_init_context_bank(struct
>>>> arm_smmu_domain *smmu_domain,
>>>>       if (stage1) {
>>>>           reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>>>>
>>>> -        reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
>>>> +        reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) <<
>>>> TTBRn_ASID_SHIFT;
>>>>           smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR0);
>>>>
>>>>           reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
>>>> -        reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
>>>> +        reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) <<
>>>> TTBRn_ASID_SHIFT;
>>>>           smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR1);
>>>>       } else {
>>>>           reg64 = pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
>>>> @@ -1812,6 +1815,18 @@ static int arm_smmu_device_dt_probe(struct
>>>> platform_device *pdev)
>>>>
>>>>       parse_driver_options(smmu);
>>>>
>>>> +    if (of_property_read_u32(dev->of_node, "#asid-base",
>>>> +                 &smmu->asid_base)) {
>>>> +        smmu->asid_base = 0;
>>>> +    }
>>>> +
>>>> +    if (of_property_read_u32(dev->of_node, "#vmid-base",
>>>> +                 &smmu->vmid_base)) {
>>>> +        smmu->vmid_base = 1;
>>>> +    }
>>>> +    if (smmu->vmid_base == 0)
>>>> +        smmu->vmid_base = 1;
>>>> +
>>>>       if (smmu->version > ARM_SMMU_V1 &&
>>>>           smmu->num_context_banks != smmu->num_context_irqs) {
>>>>           dev_err(dev,
>>>>
>>>
>>
>


From dianders at chromium.org  Wed Feb 24 11:01:31 2016
From: dianders at chromium.org (Doug Anderson)
Date: Wed, 24 Feb 2016 11:01:31 -0800
Subject: [PATCH 0/2] usb: dwc2: Remove host and gadget only code from core
In-Reply-To: <87mvqqjkfj.fsf@ti.com>
References: <cover.1456213319.git.johnyoun@synopsys.com>
 <56CC26ED.50004@synopsys.com> <87mvqqjkfj.fsf@ti.com>
Message-ID: <CAD=FV=WsBM-50gnDWq7AsXnSQPOu3ELabtbDRYjejAbN4h8b1Q@mail.gmail.com>

Felipe,

On Wed, Feb 24, 2016 at 5:40 AM, Felipe Balbi <balbi at kernel.org> wrote:
>
> Hi,
>
> John Youn <John.Youn at synopsys.com> writes:
>> On 2/23/2016 12:35 AM, John Youn wrote:
>>> This series moves the host/gadget-specific code from core.c to hcd.c
>>> and gadget.c so that they will be compiled only when their respective
>>> configurations are selected, or in DRD.
>>>
>>> This is mostly just a straight move of the code. I have also added
>>> some comments to group related functions together.
>>>
>>> Compiled and tested in all three modes.
>>>
>>> This should also solve the issue reported here:
>>> http://marc.info/?l=linux-usb&m=145591813410106&w=2
>>>
>>> Although I wasn't able to test it... couldn't figure out how to
>>> disable CONFIG_USB and enable DWC2 in gadget mode.
>>>
>>> Felipe,
>>>
>>> This should be applied after Doug's series on your testing/next
>>> branch.
>>>
>>>
>>
>> Hi Felipe,
>>
>> Patch 2/2 is triggering our corporate mail filters however I try to
>> send it. I'll look into this with IT tomorrow, maybe have to send it
>> from another account.
>
> okay, I don't have patch 2/2. 1/2 is now in testing/next

Perhaps John's solution for working around his company's mail filters
somehow sent it to your SPAM folder?  I saw his repost of v1 at on
patchwork.  GMail put them in my inbox but marked them slightly
different, saying they were from "John Youn via messagingengine.com"

8396481 New          [RESEND,1/2] usb: dwc2: Move register save and
restore functions
8396491 New          [RESEND,2/2] usb: dwc2: Move host-specific core
functions into hcd.c

...I reviewed both 1/2 and 2/2.  For 1/2 I added my reviewed-by /
tested-by.  For 2/2 I requested some nitfixes.  John posted v2 at:

8398461 New          [v2,1/2] usb: dwc2: Move register save and
restore functions
8398471 New          [v2,2/2] usb: dwc2: Move host-specific core
functions into hcd.c

v2 of 2/2 looks good to me.  All patches can be found at
<https://patchwork.kernel.org/patch/<PATCHNUM>/>, like:

https://patchwork.kernel.org/patch/8398461/
https://patchwork.kernel.org/patch/8398471/


-Doug


From kaloz at openwrt.org  Wed Feb 24 11:02:09 2016
From: kaloz at openwrt.org (Imre Kaloz)
Date: Wed, 24 Feb 2016 20:02:09 +0100
Subject: [PATCH 1/2] ARM: mvebu: change order of ethernet DT nodes on
 Armada 38x
In-Reply-To: <20160224184114.GB2292@1wt.eu>
References: <1453907300-28283-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1453907300-28283-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160127193143.GF10826@n2100.arm.linux.org.uk>
 <20160127194512.GA16638@1wt.eu>
 <20160129114853.GQ10826@n2100.arm.linux.org.uk>
 <20160224184114.GB2292@1wt.eu>
Message-ID: <op.ydcptvss2s3iss@ecaz>

On Wed, 24 Feb 2016 19:41:14 +0100, Willy Tarreau <w at 1wt.eu> wrote:

> Hi Russell,
>
> On Fri, Jan 29, 2016 at 11:48:53AM +0000, Russell King - ARM Linux wrote:
>> On Wed, Jan 27, 2016 at 08:45:12PM +0100, Willy Tarreau wrote:
>> > On Wed, Jan 27, 2016 at 07:31:44PM +0000, Russell King - ARM Linux  
>> wrote:
>> > (...)
>> > > > For example, on the Armada 388 GP, the board has two ports,  
>> labelled
>> > > > GE0 and GE1. One has to know that GE0 is eth1 and GE1 is eth0,  
>> which
>> > > > isn't really obvious.
>> > > >
>> > > > In order to solve this, this patch proposes to exceptionaly  
>> violate
>> > > > the rule of "order DT nodes by register address", and put the  
>> 0x70000
>> > > > node before the 0x30000 node, so that network interfaces get  
>> named in
>> > > > a more natural way.
>> > >
>> > > The danger is that this will completely mess up people's existing
>> > > scripts/distro configuration which are now used to the current
>> > > labelling of the network ports.
>> > >
>> > > Not every distro provides a sane way to deal with this...
>> >
>> > Well, may be that's one more reason for fixing it before boards start  
>> to
>> > ship and run distro kernels. If some boards are already in the wild  
>> running
>> > on a BSP kernel, people will complain that mainline reorders their  
>> network
>> > ports and will stick to the BSP kernel instead.
>>
>> I've checked, and we believe not many people are using mainline kernels
>> on clearfog.  I'll have to adjust my debian jessie setup to fix the
>> resulting carnage though.  On the plus side, it means that mainline
>> matches Marvell's kernel for interface naming.
>
> Well, now I'm one of these and I confirm that it's really painful to
> have a different ordering between the DTB provided in mainline and the
> DTB provided with the board. The worst thing is that using mainline,
> eth0 corresponds to the switch and appears up, so you don't immediately
> realize that it's not where your cable is connected :-/
>
> Thus could we please get Thomas' patch to ensure that the board boots
> with similar interface naming with both the original and mainline kernel  
> ?

Shouldn't this change be device specific then instead of messing up the  
dtsi?


Cheers,

Imre


From frowand.list at gmail.com  Wed Feb 24 11:03:08 2016
From: frowand.list at gmail.com (Frank Rowand)
Date: Wed, 24 Feb 2016 11:03:08 -0800
Subject: [PATCH v12 1/5] efi: ARM/arm64: ignore DT memory nodes instead
 of removing them
In-Reply-To: <20160223115805.GB4989@leverpostej>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
 <1456192703-2274-2-git-send-email-ddaney.cavm@gmail.com>
 <20160223115805.GB4989@leverpostej>
Message-ID: <56CDFE6C.4020600@gmail.com>

On 2/23/2016 3:58 AM, Mark Rutland wrote:
> Hi,
> 
> On Mon, Feb 22, 2016 at 05:58:19PM -0800, David Daney wrote:
>> From: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>>
>> There are two problems with the UEFI stub DT memory node removal
>> routine:
>> - it deletes nodes as it traverses the tree, which happens to work
>>   but is not supported, as deletion invalidates the node iterator;
>> - deleting memory nodes entirely may discard annotations in the form
>>   of additional properties on the nodes.
>>
>> Since the discovery of DT memory nodes occurs strictly before the
>> UEFI init sequence, we can simply clear the memblock memory table
>> before parsing the UEFI memory map. This way, it is no longer
>> necessary to remove the nodes, so we can remove that logic from the
>> stub as well.
> 
> This is a little bit scary, but I guess this works.
> 
> My only concern is that when we get kexec, a subsequent kernel must also
> have EFI memory map support, or things go bad for the next EFI-aware
> kernel after that (as things like the runtime services may have been
> corrupted by the kernel in the middle). It's difficult to fix the
> general case later.
> 
> A different option would be to support status="disabled" for the memory
> nodes, and ignore these in early_init_dt_scan_memory. That way a kernel
> cannot use memory without first having parsed the EFI memory map, and we
> can still get NUMA info from the disabled nodes.

Please do not play games of treating nodes with status="disabled" as
valid nodes.  The mindset should be if it is disabled, it does not exist.

There have been two bugs reported in the last week where code should
have been ignoring disabled nodes and failed to.  An audit of code
scanning all nodes instead of all enabled nodes is now on my todo list.

< snip >

-Frank


From w at 1wt.eu  Wed Feb 24 11:07:12 2016
From: w at 1wt.eu (Willy Tarreau)
Date: Wed, 24 Feb 2016 20:07:12 +0100
Subject: [PATCH 1/2] ARM: mvebu: change order of ethernet DT nodes on
 Armada 38x
In-Reply-To: <op.ydcptvss2s3iss@ecaz>
References: <1453907300-28283-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1453907300-28283-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160127193143.GF10826@n2100.arm.linux.org.uk>
 <20160127194512.GA16638@1wt.eu>
 <20160129114853.GQ10826@n2100.arm.linux.org.uk>
 <20160224184114.GB2292@1wt.eu> <op.ydcptvss2s3iss@ecaz>
Message-ID: <20160224190712.GA2333@1wt.eu>

On Wed, Feb 24, 2016 at 08:02:09PM +0100, Imre Kaloz wrote:
> >>I've checked, and we believe not many people are using mainline kernels
> >>on clearfog.  I'll have to adjust my debian jessie setup to fix the
> >>resulting carnage though.  On the plus side, it means that mainline
> >>matches Marvell's kernel for interface naming.
> >
> >Well, now I'm one of these and I confirm that it's really painful to
> >have a different ordering between the DTB provided in mainline and the
> >DTB provided with the board. The worst thing is that using mainline,
> >eth0 corresponds to the switch and appears up, so you don't immediately
> >realize that it's not where your cable is connected :-/
> >
> >Thus could we please get Thomas' patch to ensure that the board boots
> >with similar interface naming with both the original and mainline kernel  
> >?
> 
> Shouldn't this change be device specific then instead of messing up the  
> dtsi?

According to what Thomas explained, it's related to the ordering of
the NICs in the SoC's datasheet, so there are little chances that
anyone would see them enumerated differently on their board.

Willy



From mark.rutland at arm.com  Wed Feb 24 11:10:00 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 24 Feb 2016 19:10:00 +0000
Subject: [PATCH V2] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <1452D0BB-4AF3-4A19-983A-3A54E94A4F2F@caviumnetworks.com>
References: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160223122616.GE4989@leverpostej>
 <56CCF03D.3000809@caviumnetworks.com>
 <20160224113227.GB11579@leverpostej>
 <1452D0BB-4AF3-4A19-983A-3A54E94A4F2F@caviumnetworks.com>
Message-ID: <20160224190628.GA9003@leverpostej>

On Wed, Feb 24, 2016 at 03:54:48PM +0000, Chalamarla, Tirumalesh wrote:
> 
> On 2/24/16, 3:32 AM, "Mark Rutland" <mark.rutland at arm.com> wrote:
> 
> >On Tue, Feb 23, 2016 at 03:50:21PM -0800, Tirumalesh Chalamarla wrote:
> >> in Summary,
> >> 
> >> if i change asid-base to cavium,asid-base and still use DT for
> >> supplying base value, is this a solution that will be accepted, 
> >
> >No. The property is _insufficient_, regardless of its name. This has
> >been pointed out more than once.
> >
> >A base alone does not tell you what set of IDs it is valid to use
> >without risking a clash. The OS is well within its rights to allocate
> >_any_ ID above that base. It is not a requirement of the hardware nor
> >the binding that the OS allocate a contiguous set of IDs starting at the
> >base.
> >
> >Consider:
> >
> >smmu_a {
> >	whatver,*id-base = <128>;
> >};
> >
> >smmu_b {
> >	whatever,*id-base = <64>;
> >};
> >
> >In both cases, the *IDs 129+ could be allocated on both SMMUs.
> 
> Does adding a check to see if base + number of contexts supported will not overlap with each other
> Make it acceptable. 
> Or do you want the size be provided from DT also?

At this point I think Robin's suggestion of giving the ThunderX SMMU a
different compatible string and treating that as a separate case
entirely is the best thing to do.

Then the only requirement is that _all_ the ThunderX SMMUs with shared
TLBs are under the control of the OS, and it can allocate IDs as it
chooses, so long as it ensures that there are no conflicts across all
the SMMUs it is in control of.

Mark.


From tchalamarla at caviumnetworks.com  Wed Feb 24 11:15:23 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Wed, 24 Feb 2016 11:15:23 -0800
Subject: [PATCH V2] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
In-Reply-To: <20160224190628.GA9003@leverpostej>
References: <1455820158-8529-1-git-send-email-tchalamarla@caviumnetworks.com>
 <20160223122616.GE4989@leverpostej> <56CCF03D.3000809@caviumnetworks.com>
 <20160224113227.GB11579@leverpostej>
 <1452D0BB-4AF3-4A19-983A-3A54E94A4F2F@caviumnetworks.com>
 <20160224190628.GA9003@leverpostej>
Message-ID: <56CE014B.3080400@caviumnetworks.com>



On 02/24/2016 11:10 AM, Mark Rutland wrote:
> On Wed, Feb 24, 2016 at 03:54:48PM +0000, Chalamarla, Tirumalesh wrote:
>>
>> On 2/24/16, 3:32 AM, "Mark Rutland" <mark.rutland at arm.com> wrote:
>>
>>> On Tue, Feb 23, 2016 at 03:50:21PM -0800, Tirumalesh Chalamarla wrote:
>>>> in Summary,
>>>>
>>>> if i change asid-base to cavium,asid-base and still use DT for
>>>> supplying base value, is this a solution that will be accepted,
>>>
>>> No. The property is _insufficient_, regardless of its name. This has
>>> been pointed out more than once.
>>>
>>> A base alone does not tell you what set of IDs it is valid to use
>>> without risking a clash. The OS is well within its rights to allocate
>>> _any_ ID above that base. It is not a requirement of the hardware nor
>>> the binding that the OS allocate a contiguous set of IDs starting at the
>>> base.
>>>
>>> Consider:
>>>
>>> smmu_a {
>>> 	whatver,*id-base = <128>;
>>> };
>>>
>>> smmu_b {
>>> 	whatever,*id-base = <64>;
>>> };
>>>
>>> In both cases, the *IDs 129+ could be allocated on both SMMUs.
>>
>> Does adding a check to see if base + number of contexts supported will not overlap with each other
>> Make it acceptable.
>> Or do you want the size be provided from DT also?
>
> At this point I think Robin's suggestion of giving the ThunderX SMMU a
> different compatible string and treating that as a separate case
> entirely is the best thing to do.
>
> Then the only requirement is that _all_ the ThunderX SMMUs with shared
> TLBs are under the control of the OS, and it can allocate IDs as it
> chooses, so long as it ensures that there are no conflicts across all
> the SMMUs it is in control of.
>
yes, resending based on the suggestions.
> Mark.
>


From robh+dt at kernel.org  Wed Feb 24 11:30:55 2016
From: robh+dt at kernel.org (Rob Herring)
Date: Wed, 24 Feb 2016 13:30:55 -0600
Subject: [PATCH v12 1/5] efi: ARM/arm64: ignore DT memory nodes instead of
 removing them
In-Reply-To: <56CDFE6C.4020600@gmail.com>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
 <1456192703-2274-2-git-send-email-ddaney.cavm@gmail.com>
 <20160223115805.GB4989@leverpostej> <56CDFE6C.4020600@gmail.com>
Message-ID: <CAL_Jsq+e9PXi936Dm6V9mYBFTa+_tyw4yWx3R8NyASfp0mK2xQ@mail.gmail.com>

On Wed, Feb 24, 2016 at 1:03 PM, Frank Rowand <frowand.list at gmail.com> wrote:
> On 2/23/2016 3:58 AM, Mark Rutland wrote:
>> Hi,
>>
>> On Mon, Feb 22, 2016 at 05:58:19PM -0800, David Daney wrote:
>>> From: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>>>
>>> There are two problems with the UEFI stub DT memory node removal
>>> routine:
>>> - it deletes nodes as it traverses the tree, which happens to work
>>>   but is not supported, as deletion invalidates the node iterator;
>>> - deleting memory nodes entirely may discard annotations in the form
>>>   of additional properties on the nodes.
>>>
>>> Since the discovery of DT memory nodes occurs strictly before the
>>> UEFI init sequence, we can simply clear the memblock memory table
>>> before parsing the UEFI memory map. This way, it is no longer
>>> necessary to remove the nodes, so we can remove that logic from the
>>> stub as well.
>>
>> This is a little bit scary, but I guess this works.
>>
>> My only concern is that when we get kexec, a subsequent kernel must also
>> have EFI memory map support, or things go bad for the next EFI-aware
>> kernel after that (as things like the runtime services may have been
>> corrupted by the kernel in the middle). It's difficult to fix the
>> general case later.
>>
>> A different option would be to support status="disabled" for the memory
>> nodes, and ignore these in early_init_dt_scan_memory. That way a kernel
>> cannot use memory without first having parsed the EFI memory map, and we
>> can still get NUMA info from the disabled nodes.
>
> Please do not play games of treating nodes with status="disabled" as
> valid nodes.  The mindset should be if it is disabled, it does not exist.
>
> There have been two bugs reported in the last week where code should
> have been ignoring disabled nodes and failed to.  An audit of code
> scanning all nodes instead of all enabled nodes is now on my todo list.

Perhaps we should merge the default/available variants of iterators
into one. I suspect there are some valid uses. Otherwise, we could
also just not even populate those nodes in the live tree. There are
some cases where the kernel changes the status.

Rob


From mark.rutland at arm.com  Wed Feb 24 11:33:40 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 24 Feb 2016 19:33:40 +0000
Subject: [PATCH v12 1/5] efi: ARM/arm64: ignore DT memory nodes instead
 of removing them
In-Reply-To: <56CDFE6C.4020600@gmail.com>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
 <1456192703-2274-2-git-send-email-ddaney.cavm@gmail.com>
 <20160223115805.GB4989@leverpostej> <56CDFE6C.4020600@gmail.com>
Message-ID: <20160224193339.GB9003@leverpostej>

On Wed, Feb 24, 2016 at 11:03:08AM -0800, Frank Rowand wrote:
> On 2/23/2016 3:58 AM, Mark Rutland wrote:
> > Hi,
> > 
> > On Mon, Feb 22, 2016 at 05:58:19PM -0800, David Daney wrote:
> >> From: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >>
> >> There are two problems with the UEFI stub DT memory node removal
> >> routine:
> >> - it deletes nodes as it traverses the tree, which happens to work
> >>   but is not supported, as deletion invalidates the node iterator;
> >> - deleting memory nodes entirely may discard annotations in the form
> >>   of additional properties on the nodes.
> >>
> >> Since the discovery of DT memory nodes occurs strictly before the
> >> UEFI init sequence, we can simply clear the memblock memory table
> >> before parsing the UEFI memory map. This way, it is no longer
> >> necessary to remove the nodes, so we can remove that logic from the
> >> stub as well.
> > 
> > This is a little bit scary, but I guess this works.
> > 
> > My only concern is that when we get kexec, a subsequent kernel must also
> > have EFI memory map support, or things go bad for the next EFI-aware
> > kernel after that (as things like the runtime services may have been
> > corrupted by the kernel in the middle). It's difficult to fix the
> > general case later.
> > 
> > A different option would be to support status="disabled" for the memory
> > nodes, and ignore these in early_init_dt_scan_memory. That way a kernel
> > cannot use memory without first having parsed the EFI memory map, and we
> > can still get NUMA info from the disabled nodes.
> 
> Please do not play games of treating nodes with status="disabled" as
> valid nodes.  The mindset should be if it is disabled, it does not exist.

I completely agree with this generally.

The only possible wiggle room is ePAPR's decription of the precise
meaning of the status property being binding-specific (and there may be
some way to later "enable" the node or otehrwise make use of it). As
with above, we'd only be extracting some information in the presence of
a UEFI memory map.

I agree that this is not a great pattern, and we don't necessarily want
that even for "safe" cases like NUMA.

> There have been two bugs reported in the last week where code should
> have been ignoring disabled nodes and failed to.  An audit of code
> scanning all nodes instead of all enabled nodes is now on my todo list.

That would be great!

Mark.


From tchalamarla at caviumnetworks.com  Wed Feb 24 11:37:00 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Wed, 24 Feb 2016 11:37:00 -0800
Subject: [PATCH V3] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
Message-ID: <1456342620-3138-1-git-send-email-tchalamarla@caviumnetworks.com>

Due to Errata#27704 CN88xx SMMUv2,supports  only shared ASID and VMID
namespaces; specifically within a given node SMMU0 and SMMU1 share,
as does SMMU2 and SMMU3.

This patch tries to address these issuee by supplying asid and vmid
base from devicetree.

changes from V2:
	- removed *_base from DT, and replaced with compatible string

changes from V1:
	- rebased on top of 16 bit VMID patch
	- removed redundent options from DT
	- insted of transform, DT now supplies starting ASID/VMID

Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
---
 .../devicetree/bindings/iommu/arm,smmu.txt         |  1 +
 drivers/iommu/arm-smmu.c                           | 48 +++++++++++++++++-----
 2 files changed, 38 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index 7180745..19fe6f2 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -16,6 +16,7 @@ conditions.
                         "arm,mmu-400"
                         "arm,mmu-401"
                         "arm,mmu-500"
+                        "cavium,smmu-v2"

                   depending on the particular implementation and/or the
                   version of the architecture implemented.
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 247a469..f2287a5 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -326,6 +326,12 @@ struct arm_smmu_device {

 	struct list_head		list;
 	struct rb_root			masters;
+	/*
+	 *The follwoing fields are specific to Cavium, Thunder
+	 */
+	u32				cavium_smmu_id;
+	u32				cavium_id_base;
+
 };

 struct arm_smmu_cfg {
@@ -335,8 +341,8 @@ struct arm_smmu_cfg {
 };
 #define INVALID_IRPTNDX			0xff

-#define ARM_SMMU_CB_ASID(cfg)		((cfg)->cbndx)
-#define ARM_SMMU_CB_VMID(cfg)		((cfg)->cbndx + 1)
+#define ARM_SMMU_CB_ASID(smmu, cfg) ((u16)(smmu)->cavium_id_base + (cfg)->cbndx)
+#define ARM_SMMU_CB_VMID(smmu, cfg) ((u16)(smmu)->cavium_id_base + (cfg)->cbndx + 1)

 enum arm_smmu_domain_stage {
 	ARM_SMMU_DOMAIN_S1 = 0,
@@ -364,6 +370,8 @@ struct arm_smmu_option_prop {
 	const char *prop;
 };

+static int cavium_smmu_count;
+
 static struct arm_smmu_option_prop arm_smmu_options[] = {
 	{ ARM_SMMU_OPT_SECURE_CFG_ACCESS, "calxeda,smmu-secure-config-access" },
 	{ 0, NULL},
@@ -575,11 +583,11 @@ static void arm_smmu_tlb_inv_context(void *cookie)

 	if (stage1) {
 		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
-		writel_relaxed(ARM_SMMU_CB_ASID(cfg),
+		writel_relaxed(ARM_SMMU_CB_ASID(smmu, cfg),
 			       base + ARM_SMMU_CB_S1_TLBIASID);
 	} else {
 		base = ARM_SMMU_GR0(smmu);
-		writel_relaxed(ARM_SMMU_CB_VMID(cfg),
+		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg),
 			       base + ARM_SMMU_GR0_TLBIVMID);
 	}

@@ -601,7 +609,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,

 		if (!IS_ENABLED(CONFIG_64BIT) || smmu->version == ARM_SMMU_V1) {
 			iova &= ~12UL;
-			iova |= ARM_SMMU_CB_ASID(cfg);
+			iova |= ARM_SMMU_CB_ASID(smmu, cfg);
 			do {
 				writel_relaxed(iova, reg);
 				iova += granule;
@@ -609,7 +617,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
 #ifdef CONFIG_64BIT
 		} else {
 			iova >>= 12;
-			iova |= (u64)ARM_SMMU_CB_ASID(cfg) << 48;
+			iova |= (u64)ARM_SMMU_CB_ASID(smmu, cfg) << 48;
 			do {
 				writeq_relaxed(iova, reg);
 				iova += granule >> 12;
@@ -629,7 +637,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
 #endif
 	} else {
 		reg = ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_TLBIVMID;
-		writel_relaxed(ARM_SMMU_CB_VMID(cfg), reg);
+		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg), reg);
 	}
 }

@@ -738,7 +746,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 #endif
 		/* if 16bit VMID supported set VMID in CBA2R */
 		if (smmu->features & ARM_SMMU_FEAT_VMID16)
-			reg |= ARM_SMMU_CB_VMID(cfg) << CBA2R_VMID_SHIFT;
+			reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBA2R_VMID_SHIFT;

 		writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBA2R(cfg->cbndx));
 	}
@@ -757,7 +765,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
 	} else if (!(smmu->features & ARM_SMMU_FEAT_VMID16)) {
 		/*16 bit VMID is not supported set 8 bit VMID here */
-		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
+		reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBAR_VMID_SHIFT;
 	}
 	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));

@@ -765,11 +773,11 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 	if (stage1) {
 		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];

-		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
+		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
 		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR0);

 		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
-		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
+		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
 		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR1);
 	} else {
 		reg64 = pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
@@ -1717,6 +1725,7 @@ static const struct of_device_id arm_smmu_of_match[] = {
 	{ .compatible = "arm,mmu-400", .data = (void *)ARM_SMMU_V1 },
 	{ .compatible = "arm,mmu-401", .data = (void *)ARM_SMMU_V1 },
 	{ .compatible = "arm,mmu-500", .data = (void *)ARM_SMMU_V2 },
+	{ .compatible = "cavium,smmu-v2", .data = (void *)ARM_SMMU_V2 },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
@@ -1827,6 +1836,23 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 		}
 	}

+	/*
+	 * Due to Errata#27704 CN88xx SMMUv2,supports  only shared ASID and VMID
+	 * namespaces; specifically within a given node SMMU0 and SMMU1 share,
+	 * as does SMMU2 and SMMU3. see if this is a Cavium SMMU, if so
+	 * set asid and vmid base such that each SMMU gets unique
+	 * asid/vmid space.
+	 */
+	if (!strcasecmp(of_id->compatible, "cavium,smmu-v2")) {
+		/* VMID16 must be present on Cavium SMMUv2*/
+		if (!(smmu->features & ARM_SMMU_FEAT_VMID16))
+			goto out_free_irqs;
+		smmu->cavium_smmu_id = cavium_smmu_count;
+		cavium_smmu_count++;
+		smmu->cavium_id_base =
+			(smmu->cavium_smmu_id * ARM_SMMU_MAX_CBS);
+	}
+
 	INIT_LIST_HEAD(&smmu->list);
 	spin_lock(&arm_smmu_devices_lock);
 	list_add(&smmu->list, &arm_smmu_devices);
--
2.1.0



From mark.rutland at arm.com  Wed Feb 24 11:38:07 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Wed, 24 Feb 2016 19:38:07 +0000
Subject: [PATCH v12 1/5] efi: ARM/arm64: ignore DT memory nodes instead
 of removing them
In-Reply-To: <20160223221202.GA32031@rob-hp-laptop>
References: <1456192703-2274-1-git-send-email-ddaney.cavm@gmail.com>
 <1456192703-2274-2-git-send-email-ddaney.cavm@gmail.com>
 <20160223115805.GB4989@leverpostej>
 <20160223221202.GA32031@rob-hp-laptop>
Message-ID: <20160224193807.GC9003@leverpostej>

On Tue, Feb 23, 2016 at 04:12:02PM -0600, Rob Herring wrote:
> On Tue, Feb 23, 2016 at 11:58:05AM +0000, Mark Rutland wrote:
> > Hi,
> > 
> > On Mon, Feb 22, 2016 at 05:58:19PM -0800, David Daney wrote:
> > > From: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> > > 
> > > There are two problems with the UEFI stub DT memory node removal
> > > routine:
> > > - it deletes nodes as it traverses the tree, which happens to work
> > >   but is not supported, as deletion invalidates the node iterator;
> > > - deleting memory nodes entirely may discard annotations in the form
> > >   of additional properties on the nodes.
> > > 
> > > Since the discovery of DT memory nodes occurs strictly before the
> > > UEFI init sequence, we can simply clear the memblock memory table
> > > before parsing the UEFI memory map. This way, it is no longer
> > > necessary to remove the nodes, so we can remove that logic from the
> > > stub as well.
> > 
> > This is a little bit scary, but I guess this works.
> 
> The way it is worded/implemented is, I agree. But if we simply say both 
> can be present and the kernel will default to UEFI memory map, that 
> seems sufficient to me.
>  
> > My only concern is that when we get kexec, a subsequent kernel must also
> > have EFI memory map support, or things go bad for the next EFI-aware
> > kernel after that (as things like the runtime services may have been
> > corrupted by the kernel in the middle). It's difficult to fix the
> > general case later.
> > 
> > A different option would be to support status="disabled" for the memory
> > nodes, and ignore these in early_init_dt_scan_memory. That way a kernel
> > cannot use memory without first having parsed the EFI memory map, and we
> > can still get NUMA info from the disabled nodes.
> 
> That would be a bit strange that the node is disabled, but still used. 

I agree this would be strange, and not necessarily a precedent we'd want
to see copied elsewhere.

Per ePAPR, a "disabled" node can be enabled in a binding-specific
manner, so having the presence of a UEFI memory map "enable" the NUMA
information would appear to be permitted.

> What if DT and UEFI tables are out of sync somehow? RAM is multiple 
> mapped and different addresses were picked for example.

That applies regardless of the status of the memory nodes.

My suggestion was only that we acquired the NUMA node information, and
added this node information (and not any additional extent of memory) to
the UEFI memory map.

This is precisely what we do with Ard's code, with the exception that in
the absence of a UEFI memory map the kernel would know it was not
permitted to access memory.

Mark.


From khilman at baylibre.com  Wed Feb 24 11:48:46 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Wed, 24 Feb 2016 11:48:46 -0800
Subject: [PATCH v5 0/4] Mediatek MT2701 SCPSYS power domain support
In-Reply-To: <1455692499-56828-1-git-send-email-jamesjj.liao@mediatek.com>
 (James Liao's message of "Wed, 17 Feb 2016 15:01:35 +0800")
References: <1455692499-56828-1-git-send-email-jamesjj.liao@mediatek.com>
Message-ID: <7hmvqpsxcx.fsf@baylibre.com>

James Liao <jamesjj.liao at mediatek.com> writes:

> This patchset is based on v4.5-rc4 and adds scpsys power domain support
> for Mediatek MT2701.
>
> To share the code between MT2701 and MT8173, this patchset also refined
> original mtk-scpsys.c to separate common codes and platform codes, so
> that mtk-scpsys.c can support new SoCs more easily.

Thanks for refactoring to support multiple SoCs, I like this version
much better.

Reviewed-by: Kevin Hilman <khilman at baylibre.com>

Kevin


From ashwin.chaugule at linaro.org  Wed Feb 24 11:53:02 2016
From: ashwin.chaugule at linaro.org (Ashwin Chaugule)
Date: Wed, 24 Feb 2016 14:53:02 -0500
Subject: [PATCH] drivers: perf: arm: implement CPU_PM notifier
In-Reply-To: <20160224173511.GF25385@red-moon>
References: <1456251759-24768-1-git-send-email-lorenzo.pieralisi@arm.com>
 <CANLsYkzvB0GbPeYHrcLtUz8DMHJh4FA5RVwVZ-UAm3BCznB_3w@mail.gmail.com>
 <20160224173511.GF25385@red-moon>
Message-ID: <CAJ5Y-ea3gxxOEGdJMPZAh78Ap0GBvzGePhBKzQRVoJBwwY6NzA@mail.gmail.com>

Hi Lorenzo,

On 24 February 2016 at 12:35, Lorenzo Pieralisi
<lorenzo.pieralisi at arm.com> wrote:
> On Wed, Feb 24, 2016 at 09:20:22AM -0700, Mathieu Poirier wrote:
>> On 23 February 2016 at 11:22, Lorenzo Pieralisi
>
> [...]
>
>> > +static int cpu_pm_pmu_notify(struct notifier_block *b, unsigned long cmd,
>> > +                            void *v)
>> > +{
>> > +       struct arm_pmu *armpmu = container_of(b, struct arm_pmu, cpu_pm_nb);
>> > +       struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
>> > +       int enabled = bitmap_weight(hw_events->used_mask, armpmu->num_events);
>> > +
>> > +       if (!cpumask_test_cpu(smp_processor_id(), &armpmu->supported_cpus))
>> > +               return NOTIFY_DONE;
>> > +
>> > +       /*
>> > +        * Always reset the PMU registers on power-up even if
>> > +        * there are no events running.
>> > +        */
>> > +       if (cmd == CPU_PM_EXIT && armpmu->reset)
>> > +               armpmu->reset(armpmu);
>>
>> I think this patch does the right thing but I can't get the above
>> reset.  Wouldn't it be better to do the reset as part of the
>> CPU_PM_EXIT case below?  At this point nothing tells us the CPU won't
>> go back down before the event is enabled, wasting the cycle needed to
>> reset the PMU.
>
> The logic goes, if the cpu is woken up and it has no events enabled,
> if we do not reset it (mind, ->reset here sets the PMU register values
> to a sane default, some of them are architecturally UNKNOWN on reset, it
> does NOT reset the PMU) _and_ we subsequently install an event on it we
> do have a problem, that's why whenever a core gets out of low-power we
> have to reset its pmu.

Dont we blow out the previous value in the counter when installing an
event? Or has that changed lately? IIRC, there was some initial value
we'd program into the counter to avoid missing the overflow event.
(sorry its been too long) ;)

Cheers,
Ashwin.


From rafael at kernel.org  Wed Feb 24 12:03:45 2016
From: rafael at kernel.org (Rafael J. Wysocki)
Date: Wed, 24 Feb 2016 21:03:45 +0100
Subject: [PATCH v2 3/8] ACPI: add definitions of DBG2 subtypes
In-Reply-To: <56CDE77C.2050301@linaro.org>
References: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
 <1456333819-13482-4-git-send-email-aleksey.makarov@linaro.org>
 <94F2FBAB4432B54E8AACC7DFDE6C92E37E44BCB5@ORSMSX110.amr.corp.intel.com>
 <56CDE77C.2050301@linaro.org>
Message-ID: <CAJZ5v0hO0pD+N5y5au4mgMj0YQrO3A0cvFwNVOsvE9i353K6iA@mail.gmail.com>

On Wed, Feb 24, 2016 at 6:25 PM, Aleksey Makarov
<aleksey.makarov at linaro.org> wrote:
>
>
> On 02/24/2016 08:17 PM, Moore, Robert wrote:
>> I've got these for the next release of ACPICA
>
> It have not been pulled to linux-next but is required for the patchset.

No, it hasn't.

It will go to linux-next when I get ACPICA patches for the next
release from the upstream.

Thanks,
Rafael


From thomas.petazzoni at free-electrons.com  Wed Feb 24 12:10:45 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Wed, 24 Feb 2016 21:10:45 +0100
Subject: [PATCH 1/3] dt-bindings: arm/marvell: ABI unstability warning
 about Marvell 7K/8K
In-Reply-To: <20160224172545.GC9137@leverpostej>
References: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1456327007-31008-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160224172545.GC9137@leverpostej>
Message-ID: <20160224211045.379352d3@free-electrons.com>

Hello,

On Wed, 24 Feb 2016 17:25:46 +0000, Mark Rutland wrote:

> On Wed, Feb 24, 2016 at 04:16:45PM +0100, Thomas Petazzoni wrote:
> > Since we are still very early in the support of Marvell Armada 7/8K
> > chips and those chips are significantly different from earlier 32 bits
> > Armada SOCs, it is difficult to commit to Device Tree ABI stability at
> > this point.
> 
> I don't see why difference to an existing SoC means that we cannot
> guarantee support for this DT. Why does that contribute to instability?
> 
> If there's something we're unsure about, we should be seeding the DT
> with sufficient information to do the right thing(TM) in future. What
> areas in particular do you think are likely to be problematic? Is there
> anything in particular that you think that approach doesn't work for?

At this point, we have incomplete information about the HW capabilities
and register layout. Our past experience has shown that when we start
supporting SoC that early, 

> From my PoV, if we're so uncertain about a DT binding that it cannot be
> kept supported, it is a prototype not yet fit for mainline.

Are you really serious when you say that ?

The Linux kernel community has been encouraging hardware vendor for
*years* to get their code merged as early as possible. And now that
they are doing it, you are telling them that they shouldn't submit
their code to mainline ?

If that's what you want, then sorry, but I don't buy this argument, and
I will continue to encourage HW vendors to submit their code early,
even if it means that indeed in the early stages, things remain a bit
in-flux and need to be refined progressively.

You seem to really be in your ivory tower and not seeing the reality of
an SoC development and how to push the support for it in mainline as
early as possible, so that the BSPs shipped to actual customers are as
close to mainline as possible. Together with the Marvell engineers, we
are doing a huge amount of work to ensure that this vendor BSP is as
close as mainline as possible. And you're basically telling us we
should this effort ?

Come on, be serious.

> > Therefore, this commit adds a warning to the Marvell 7K/8K DT binding
> > documentation to indicate that the bindings are for the moment
> > unstable.
> 
> As with the other thread, I'm strongly opposed to this mentality.

Many other platforms have made this choice: Atmel, Marvell Berlin, and
probably others.

I think it should be up to each platform vendor to decide whether they
care about DT stability or not, and at which point in time in the life
cycle of their platform they want to claim the DT bindings as stable.
You might believe that DT bindings are stable, but they are not. They
change constantly, in very subtle way, and nobody ever tests DT from
kernel version N-x with kernel version N. On any real-life platform, it
simply doesn't work, unless that platform is 5+ years old.

I made a talk at ELC about DT stability being a fairy tale, and I
remember very well Rob Herring coming to me during the social event
afterwards, telling me that it has never been said that all platforms
should conform strictly to this DT stability requirement.

So please get to an agreement between DT binding maintainers. And stop
saying this ridiculous statement that HW vendors should stop submitting
their code to the mainline.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From antoine.tenart at free-electrons.com  Wed Feb 24 12:23:12 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Wed, 24 Feb 2016 21:23:12 +0100
Subject: [PATCH v3 0/7] irqchip: introduce the Alpine MSIX driver
In-Reply-To: <20160220104019.21e425c6@arm.com>
References: <1455895369-13187-1-git-send-email-antoine.tenart@free-electrons.com>
 <20160220104019.21e425c6@arm.com>
Message-ID: <20160224202312.GC29884@kwain>

Hi Marc,

On Sat, Feb 20, 2016 at 10:40:19AM +0000, Marc Zyngier wrote:
> On Fri, 19 Feb 2016 16:22:42 +0100
> Antoine Tenart <antoine.tenart at free-electrons.com> wrote:
> > 
> > This series introduce the Alpine MSIX driver, and enables it in both
> > the Alpine v1 and Alpine v2 device trees.
> > 
> > This series depends on "[PATCH v2 0/3] arm64: introduce the Alpine support":
> > https://lkml.org/lkml/2016/2/10/83
> > 
> > You can find the series at:
> > https://github.com/atenart/linux.git 4.5-rc1/alpinev2-msix
> > 
> > Antoine
> > 
> > Since v2:
> >   - Updated the documentation (added a reference to the GIC documentation).
> > 
> > Since v1:
> >   - Added an interrupt-parent property in the documentation example.
> >   - Updated to use bitmap_*() instead of *_bit().
> >   - Removed the static irq_set_affinity to use irq_chip_set_affinity_parent().
> >   - Updated the address field to use phys_addr_t.
> >   - Added a comment on why we're setting bit 16 in the address.
> >   - Patched the gic_set_affinity() function in irqchip/gic-v3.
> > 
> > Antoine Tenart (7):
> >   irqchip/gic-v3: always return IRQ_SET_MASK_OK_DONE in gic_set_affinity
> >   irqchip: add the Alpine MSIX interrupt controller
> >   Documentation: bindings: document the Alpine MSIX driver
> >   arm64: dts: alpine: add the MSIX node in the Alpine v2 dtsi
> >   ARM: dts: alpine: add the MSIX node
> >   arm64: alpine: select the Alpine MSI controller driver
> >   arm: alpine: select the Alpine MSI controller driver
> > 
> >  .../interrupt-controller/al,alpine-msix.txt        |  26 ++
> >  arch/arm/boot/dts/alpine.dtsi                      |  10 +
> >  arch/arm/mach-alpine/Kconfig                       |   1 +
> >  arch/arm64/Kconfig.platforms                       |   1 +
> >  arch/arm64/boot/dts/al/alpine-v2.dtsi              |  10 +
> >  drivers/irqchip/Kconfig                            |   6 +
> >  drivers/irqchip/Makefile                           |   1 +
> >  drivers/irqchip/irq-alpine-msi.c                   | 293 +++++++++++++++++++++
> >  drivers/irqchip/irq-gic-v3.c                       |   2 +-
> >  9 files changed, 349 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt
> >  create mode 100644 drivers/irqchip/irq-alpine-msi.c
> > 
> 
> I've queued the first three patches in my irq/gic-4.6 branch. I'd
> expect the last 4 patches to be taken care off by armsoc once the code
> has made it into Linus' tree.

I'm taking care of the Alpine patches for 4.6, so I'll take the last 4
myself (and ensure their dependencies are met).

Antoine

-- 
Antoine T?nart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/ba59590a/attachment.sig>

From hongzhou.yang at mediatek.com  Wed Feb 24 12:28:25 2016
From: hongzhou.yang at mediatek.com (Hongzhou Yang)
Date: Wed, 24 Feb 2016 12:28:25 -0800
Subject: [PATCH 13/50] pinctrl: mtk-common: Use devm_pinctrl_register()
 for pinctrl registration
In-Reply-To: <1456319775-3216-14-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-14-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456345705.14518.1.camel@mussux00>

On Wed, 2016-02-24 at 18:45 +0530, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration and clean
> the error path.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Matthias Brugger <matthias.bgg at gmail.com>
> Cc: Hongzhou Yang <hongzhou.yang at mediatek.com>
> Cc: Yingjoe Chen <yingjoe.chen at mediatek.com>
> ---

Acked-by: Hongzhou Yang <hongzhou.yang at mediatek.com>

Thanks,
Hongzhou

>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 17 ++++++-----------
>  1 file changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> index ddc9217..194413d 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> @@ -1390,17 +1390,16 @@ int mtk_pctrl_init(struct platform_device *pdev,
>  	pctl->pctl_desc.pmxops = &mtk_pmx_ops;
>  	pctl->dev = &pdev->dev;
>  
> -	pctl->pctl_dev = pinctrl_register(&pctl->pctl_desc, &pdev->dev, pctl);
> +	pctl->pctl_dev = devm_pinctrl_register(&pdev->dev, &pctl->pctl_desc,
> +					       pctl);
>  	if (IS_ERR(pctl->pctl_dev)) {
>  		dev_err(&pdev->dev, "couldn't register pinctrl driver\n");
>  		return PTR_ERR(pctl->pctl_dev);
>  	}
>  
>  	pctl->chip = devm_kzalloc(&pdev->dev, sizeof(*pctl->chip), GFP_KERNEL);
> -	if (!pctl->chip) {
> -		ret = -ENOMEM;
> -		goto pctrl_error;
> -	}
> +	if (!pctl->chip)
> +		return -ENOMEM;
>  
>  	*pctl->chip = mtk_gpio_chip;
>  	pctl->chip->ngpio = pctl->devdata->npins;
> @@ -1409,10 +1408,8 @@ int mtk_pctrl_init(struct platform_device *pdev,
>  	pctl->chip->base = -1;
>  
>  	ret = gpiochip_add_data(pctl->chip, pctl);
> -	if (ret) {
> -		ret = -EINVAL;
> -		goto pctrl_error;
> -	}
> +	if (ret)
> +		return -EINVAL;
>  
>  	/* Register the GPIO to pin mappings. */
>  	ret = gpiochip_add_pin_range(pctl->chip, dev_name(&pdev->dev),
> @@ -1490,8 +1487,6 @@ int mtk_pctrl_init(struct platform_device *pdev,
>  
>  chip_error:
>  	gpiochip_remove(pctl->chip);
> -pctrl_error:
> -	pinctrl_unregister(pctl->pctl_dev);
>  	return ret;
>  }
>  




From troy.kisky at boundarydevices.com  Wed Feb 24 12:38:32 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 13:38:32 -0700
Subject: [PATCH net-next V2 7/8] net: fec: don't transfer ownership until
 descriptor write is complete
In-Reply-To: <20160205170347.45a91314@jclayton-pc>
References: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
 <1454709170-19527-8-git-send-email-troy.kisky@boundarydevices.com>
 <20160205170347.45a91314@jclayton-pc>
Message-ID: <56CE14C8.70708@boundarydevices.com>

On 2/5/2016 6:03 PM, Joshua Clayton wrote:
> On Fri,  5 Feb 2016 14:52:49 -0700
> Troy Kisky <troy.kisky at boundarydevices.com> wrote:
> 
>> If you don't own it, you shouldn't write to it.
>>
>> Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
>> ---
>>  drivers/net/ethernet/freescale/fec_main.c | 14 +++++++++++++-
>>  1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/freescale/fec_main.c
>> b/drivers/net/ethernet/freescale/fec_main.c index ca2708d..97ca72a
>> 100644 --- a/drivers/net/ethernet/freescale/fec_main.c
>> +++ b/drivers/net/ethernet/freescale/fec_main.c
>> @@ -390,6 +390,10 @@ fec_enet_txq_submit_frag_skb(struct
>> fec_enet_priv_tx_q *txq, 
>>  		bdp->cbd_bufaddr = cpu_to_fec32(addr);
>>  		bdp->cbd_datlen = cpu_to_fec16(frag_len);
>> +		/* Make sure the updates to rest of the descriptor
>> are
>> +		 * performed before transferring ownership.
>> +		 */
>> +		wmb();
>>  		bdp->cbd_sc = cpu_to_fec16(status);
> You use almost exactly the same code in each place.
> I'd prefer to have wmb(); bdp->cbd_sc = cpu_to_fec16(status) wrapped in
> a function or function like macro, and put the comment in one place.
> 

Thanks for the review. I added a patch to the end of the series to create a common
"trigger_tx" subroutine which should address this.


From troy.kisky at boundarydevices.com  Wed Feb 24 12:39:14 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 13:39:14 -0700
Subject: [PATCH net-next V2 7/8] net: fec: don't transfer ownership until
 descriptor write is complete
In-Reply-To: <56B5DE6C.9080407@cogentembedded.com>
References: <1454709170-19527-1-git-send-email-troy.kisky@boundarydevices.com>
 <1454709170-19527-8-git-send-email-troy.kisky@boundarydevices.com>
 <56B5DE6C.9080407@cogentembedded.com>
Message-ID: <56CE14F2.8010005@boundarydevices.com>

On 2/6/2016 4:52 AM, Sergei Shtylyov wrote:
> Hello.
> 
> On 2/6/2016 12:52 AM, Troy Kisky wrote:
> 
>> If you don't own it, you shouldn't write to it.
>>
>> Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
>> ---
>>   drivers/net/ethernet/freescale/fec_main.c | 14 +++++++++++++-
>>   1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
>> index ca2708d..97ca72a 100644
>> --- a/drivers/net/ethernet/freescale/fec_main.c
>> +++ b/drivers/net/ethernet/freescale/fec_main.c
>> @@ -390,6 +390,10 @@ fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
>>
>>           bdp->cbd_bufaddr = cpu_to_fec32(addr);
>>           bdp->cbd_datlen = cpu_to_fec16(frag_len);
>> +        /* Make sure the updates to rest of the descriptor are
>> +         * performed before transferring ownership.
>> +         */
>> +        wmb();
>>           bdp->cbd_sc = cpu_to_fec16(status);
>>       }
>>
>> @@ -499,6 +503,10 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
>>
>>       bdp->cbd_datlen = cpu_to_fec16(buflen);
>>       bdp->cbd_bufaddr = cpu_to_fec32(addr);
>> +    /* Make sure the updates to rest of the descriptor are performed before
>> +     * transferring ownership.
>> +     */
>> +    wmb();
>>
>>       /* Send it on its way.  Tell FEC it's ready, interrupt when done,
>>        * it's the last BD of the frame, and to put the CRC on the end.
> [...]
>> @@ -1484,6 +1491,11 @@ rx_processing_done:
>>               ebdp->cbd_prot = 0;
>>               ebdp->cbd_bdu = 0;
>>           }
>> +        /* Make sure the updates to rest of the descriptor are
>> +         * performed before transferring ownership.
>> +         */
>> +        wmb();
>> +        bdp->cbd_sc = cpu_to_fec16(status);
> 
>    I think you can use "ligter" dma_wmb() in this case.
> 


Thanks for the review, I added a patch to the end of the series to address this.

Troy


From carlo at caione.org  Wed Feb 24 12:42:03 2016
From: carlo at caione.org (Carlo Caione)
Date: Wed, 24 Feb 2016 21:42:03 +0100
Subject: [PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node
In-Reply-To: <CAL9uMOG2gnGnxv9RmmKuHjc72xyyyEu3AW6pTyM2oA=aM171eQ@mail.gmail.com>
References: <1455730114-2547-1-git-send-email-romain.perier@gmail.com>
 <CAOQ7t2aqZj3STFsdTSQZMTK5U+8Oem8oFroxHKWkt=AeP+Zczg@mail.gmail.com>
 <CAD8Lp47LGUc3-MFpU+3iNjXJL0i4nLTY_49NUxFXeZ2SokDuaQ@mail.gmail.com>
 <3072897.5MMsyiojns@wuerfel>
 <CAL9uMOG2gnGnxv9RmmKuHjc72xyyyEu3AW6pTyM2oA=aM171eQ@mail.gmail.com>
Message-ID: <CAOQ7t2YXRwxvOpYBPYh7as94ZJSM3z44M2RR3vzG=mJY7ktZAg@mail.gmail.com>

On Fri, Feb 19, 2016 at 2:25 PM, Carlo Caione <carlo at endlessm.com> wrote:

>> Maybe the best way is to make it compatible with both syscon and
>> simple-bus and put the other nodes underneath. That is still rather
>> ugly, but at least it works and can be extended.
>
> This is a good idea actually. I'll prepare a patch.
> Thank you for having spent time on this.

Apparently I talked too soon. The problem is the pinctrl driver where
one of the bank (ao-bank) is mapped into the aobus not cbus
http://lxr.free-electrons.com/source/arch/arm/boot/dts/meson8b.dtsi#L169
If you don't have a better idea probably I should try to decouple the
two banks so that we have two different pinctrl devices for each bus
(aobus and cbus).

Cheers,

-- 
Carlo Caione


From jic23 at kernel.org  Wed Feb 24 12:55:08 2016
From: jic23 at kernel.org (Jonathan Cameron)
Date: Wed, 24 Feb 2016 20:55:08 +0000
Subject: [PATCH v3 2/2] iio: dac: vf610_dac: Add IIO DAC driver for Vybrid
 SoC
In-Reply-To: <20160223205437.GA27366@rob-hp-laptop>
References: <cover.1456121233.git.maitysanchayan@gmail.com>
 <1a70acdd3ffae273bbfe2f80c5e3952d152921df.1456121233.git.maitysanchayan@gmail.com>
 <20160223205437.GA27366@rob-hp-laptop>
Message-ID: <56CE18AC.6020603@kernel.org>

On 23/02/16 20:54, Rob Herring wrote:
> On Mon, Feb 22, 2016 at 11:48:37AM +0530, Sanchayan Maity wrote:
>> Add driver support for DAC peripheral on Vybrid SoC.
>>
>> Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
>> ---
>>  Documentation/ABI/testing/sysfs-bus-iio-vf610      |   9 +
>>  .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
> 
> For the binding:
> 
> Acked-by: Rob Herring <robh at kernel.org>
Applied to the togreg branch of iio.git - initially pushed out as testing
for the autobuilders to play with it.

Note the dts change probably wants to go via the relevant arch trees.
I can take it with an appropriate ack if not.

Jonathan
> 
>>  drivers/iio/dac/Kconfig                            |  10 +
>>  drivers/iio/dac/Makefile                           |   1 +
>>  drivers/iio/dac/vf610_dac.c                        | 298 +++++++++++++++++++++
>>  5 files changed, 338 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
>>  create mode 100644 drivers/iio/dac/vf610_dac.c
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 



From tchalamarla at caviumnetworks.com  Wed Feb 24 13:13:53 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Wed, 24 Feb 2016 13:13:53 -0800
Subject: [PATCH] iommu/arm-smmu-v2: Workaround for ThunderX errata#27704
Message-ID: <1456348433-3337-1-git-send-email-tchalamarla@caviumnetworks.com>

Due to Errata#27704 CN88xx SMMUv2,supports  only shared ASID and VMID
namespaces; specifically within a given node SMMU0 and SMMU1 share,
as does SMMU2 and SMMU3.

This patch address these issuee by supplying asid and vmid
while calculating ASID and VMID for Thunder SMMUv2.

NOTE: resending with commit message fix.

changes from V2:
	- removed *_base from DT, and replaced with compatible string

changes from V1:
	- rebased on top of 16 bit VMID patch
	- removed redundent options from DT
	- insted of transform, DT now supplies starting ASID/VMID

Signed-off-by: Tirumalesh Chalamarla <tchalamarla at caviumnetworks.com>
Signed-off-by: Akula Geethasowjanya <Geethasowjanya.Akula at caviumnetworks.com>
---
 .../devicetree/bindings/iommu/arm,smmu.txt         |  1 +
 drivers/iommu/arm-smmu.c                           | 48 +++++++++++++++++-----
 2 files changed, 38 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index 7180745..19fe6f2 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -16,6 +16,7 @@ conditions.
                         "arm,mmu-400"
                         "arm,mmu-401"
                         "arm,mmu-500"
+                        "cavium,smmu-v2"
 
                   depending on the particular implementation and/or the
                   version of the architecture implemented.
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 247a469..c704f88 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -326,6 +326,12 @@ struct arm_smmu_device {
 
 	struct list_head		list;
 	struct rb_root			masters;
+	/*
+	 *The following fields are specific to Cavium, Thunder
+	 */
+	u32				cavium_smmu_id;
+	u32				cavium_id_base;
+
 };
 
 struct arm_smmu_cfg {
@@ -335,8 +341,8 @@ struct arm_smmu_cfg {
 };
 #define INVALID_IRPTNDX			0xff
 
-#define ARM_SMMU_CB_ASID(cfg)		((cfg)->cbndx)
-#define ARM_SMMU_CB_VMID(cfg)		((cfg)->cbndx + 1)
+#define ARM_SMMU_CB_ASID(smmu, cfg) ((u16)(smmu)->cavium_id_base + (cfg)->cbndx)
+#define ARM_SMMU_CB_VMID(smmu, cfg) ((u16)(smmu)->cavium_id_base + (cfg)->cbndx + 1)
 
 enum arm_smmu_domain_stage {
 	ARM_SMMU_DOMAIN_S1 = 0,
@@ -364,6 +370,8 @@ struct arm_smmu_option_prop {
 	const char *prop;
 };
 
+static int cavium_smmu_count;
+
 static struct arm_smmu_option_prop arm_smmu_options[] = {
 	{ ARM_SMMU_OPT_SECURE_CFG_ACCESS, "calxeda,smmu-secure-config-access" },
 	{ 0, NULL},
@@ -575,11 +583,11 @@ static void arm_smmu_tlb_inv_context(void *cookie)
 
 	if (stage1) {
 		base = ARM_SMMU_CB_BASE(smmu) + ARM_SMMU_CB(smmu, cfg->cbndx);
-		writel_relaxed(ARM_SMMU_CB_ASID(cfg),
+		writel_relaxed(ARM_SMMU_CB_ASID(smmu, cfg),
 			       base + ARM_SMMU_CB_S1_TLBIASID);
 	} else {
 		base = ARM_SMMU_GR0(smmu);
-		writel_relaxed(ARM_SMMU_CB_VMID(cfg),
+		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg),
 			       base + ARM_SMMU_GR0_TLBIVMID);
 	}
 
@@ -601,7 +609,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
 
 		if (!IS_ENABLED(CONFIG_64BIT) || smmu->version == ARM_SMMU_V1) {
 			iova &= ~12UL;
-			iova |= ARM_SMMU_CB_ASID(cfg);
+			iova |= ARM_SMMU_CB_ASID(smmu, cfg);
 			do {
 				writel_relaxed(iova, reg);
 				iova += granule;
@@ -609,7 +617,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
 #ifdef CONFIG_64BIT
 		} else {
 			iova >>= 12;
-			iova |= (u64)ARM_SMMU_CB_ASID(cfg) << 48;
+			iova |= (u64)ARM_SMMU_CB_ASID(smmu, cfg) << 48;
 			do {
 				writeq_relaxed(iova, reg);
 				iova += granule >> 12;
@@ -629,7 +637,7 @@ static void arm_smmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
 #endif
 	} else {
 		reg = ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_TLBIVMID;
-		writel_relaxed(ARM_SMMU_CB_VMID(cfg), reg);
+		writel_relaxed(ARM_SMMU_CB_VMID(smmu, cfg), reg);
 	}
 }
 
@@ -738,7 +746,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 #endif
 		/* if 16bit VMID supported set VMID in CBA2R */
 		if (smmu->features & ARM_SMMU_FEAT_VMID16)
-			reg |= ARM_SMMU_CB_VMID(cfg) << CBA2R_VMID_SHIFT;
+			reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBA2R_VMID_SHIFT;
 
 		writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBA2R(cfg->cbndx));
 	}
@@ -757,7 +765,7 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 			(CBAR_S1_MEMATTR_WB << CBAR_S1_MEMATTR_SHIFT);
 	} else if (!(smmu->features & ARM_SMMU_FEAT_VMID16)) {
 		/*16 bit VMID is not supported set 8 bit VMID here */
-		reg |= ARM_SMMU_CB_VMID(cfg) << CBAR_VMID_SHIFT;
+		reg |= ARM_SMMU_CB_VMID(smmu, cfg) << CBAR_VMID_SHIFT;
 	}
 	writel_relaxed(reg, gr1_base + ARM_SMMU_GR1_CBAR(cfg->cbndx));
 
@@ -765,11 +773,11 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
 	if (stage1) {
 		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
 
-		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
+		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
 		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR0);
 
 		reg64 = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
-		reg64 |= ((u64)ARM_SMMU_CB_ASID(cfg)) << TTBRn_ASID_SHIFT;
+		reg64 |= ((u64)ARM_SMMU_CB_ASID(smmu, cfg)) << TTBRn_ASID_SHIFT;
 		smmu_writeq(reg64, cb_base + ARM_SMMU_CB_TTBR1);
 	} else {
 		reg64 = pgtbl_cfg->arm_lpae_s2_cfg.vttbr;
@@ -1717,6 +1725,7 @@ static const struct of_device_id arm_smmu_of_match[] = {
 	{ .compatible = "arm,mmu-400", .data = (void *)ARM_SMMU_V1 },
 	{ .compatible = "arm,mmu-401", .data = (void *)ARM_SMMU_V1 },
 	{ .compatible = "arm,mmu-500", .data = (void *)ARM_SMMU_V2 },
+	{ .compatible = "cavium,smmu-v2", .data = (void *)ARM_SMMU_V2 },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
@@ -1827,6 +1836,23 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
 		}
 	}
 
+	/*
+	 * Due to Errata#27704 CN88xx SMMUv2,supports  only shared ASID and VMID
+	 * namespaces; specifically within a given node SMMU0 and SMMU1 share,
+	 * as does SMMU2 and SMMU3. see if this is a Cavium SMMU, if so
+	 * set asid and vmid base such that each SMMU gets unique
+	 * asid/vmid space.
+	 */
+	if (!strcasecmp(of_id->compatible, "cavium,smmu-v2")) {
+		/* VMID16 must be present on Cavium SMMUv2*/
+		if (!(smmu->features & ARM_SMMU_FEAT_VMID16))
+			goto out_free_irqs;
+		smmu->cavium_smmu_id = cavium_smmu_count;
+		cavium_smmu_count++;
+		smmu->cavium_id_base =
+			(smmu->cavium_smmu_id * ARM_SMMU_MAX_CBS);
+	}
+
 	INIT_LIST_HEAD(&smmu->list);
 	spin_lock(&arm_smmu_devices_lock);
 	list_add(&smmu->list, &arm_smmu_devices);
-- 
2.1.0



From arnd at arndb.de  Wed Feb 24 13:20:55 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 24 Feb 2016 22:20:55 +0100
Subject: [PATCH v3 6/6] arm: lpc32xx: phy3250 remove restart hook
In-Reply-To: <1456336018-6620-7-git-send-email-slemieux.tyco@gmail.com>
References: <1456336018-6620-1-git-send-email-slemieux.tyco@gmail.com>
 <1456336018-6620-7-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <2913764.6ZXbKHTUYJ@wuerfel>

On Wednesday 24 February 2016 12:46:58 Sylvain Lemieux wrote:
> From: Sylvain Lemieux <slemieux at tycoint.com>
> 
> Remove the restart hook assignment from phy3250;
> this functionality is now managed by
> the pnx4008 watchdog driver.
> 
> Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
> ---
> Note:
> This patch was generated with the option "--unified=2" to ensure
> it can be apply before or after the following git pull request
> for the LPC32xx platform:
> - http://permalink.gmane.org/gmane.linux.ports.arm.kernel/477137
> - http://permalink.gmane.org/gmane.linux.ports.arm.kernel/477138

This patch really needs to come before patch 5 in the series, or
you could combine the two into a single patch.

	Arnd


From mturquette at baylibre.com  Wed Feb 24 13:25:33 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Wed, 24 Feb 2016 13:25:33 -0800
Subject: [PATCH v6 4/7] clk: mediatek: Add MT2701 clock support
In-Reply-To: <1455527982.29688.8.camel@mtksdaap41>
References: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
 <1454665050-37776-5-git-send-email-jamesjj.liao@mediatek.com>
 <20160210200853.26445.15165@quark.deferred.io>
 <1455527982.29688.8.camel@mtksdaap41>
Message-ID: <20160224212533.2278.7597@quark.deferred.io>

Hi James,

Quoting James Liao (2016-02-15 01:19:42)
> Hi Mike,
> 
> On Wed, 2016-02-10 at 12:08 -0800, Michael Turquette wrote:
> > Quoting James Liao (2016-02-05 01:37:27)
> > > +CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt2701-topckgen", mtk_topckgen_init);
> > > +CLK_OF_DECLARE(mtk_infrasys, "mediatek,mt2701-infracfg", mtk_infrasys_init);
> > > +CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt2701-pericfg", mtk_pericfg_init);
> > > +CLK_OF_DECLARE(mtk_mmsys, "mediatek,mt2701-mmsys", mtk_mmsys_init);
> > > +CLK_OF_DECLARE(mtk_imgsys, "mediatek,mt2701-imgsys", mtk_imgsys_init);
> > > +CLK_OF_DECLARE(mtk_vdecsys, "mediatek,mt2701-vdecsys", mtk_vdecsys_init);
> > > +CLK_OF_DECLARE(mtk_hifsys, "mediatek,mt2701-hifsys", mtk_hifsys_init);
> > > +CLK_OF_DECLARE(mtk_ethsys, "mediatek,mt2701-ethsys", mtk_ethsys_init);
> > > +CLK_OF_DECLARE(mtk_bdpsys, "mediatek,mt2701-bdpsys", mtk_bdpsys_init);
> > > +CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt2701-apmixedsys",
> > 
> > :-/
> > 
> > This is way too much CLK_OF_DECLARE and not enough Linux Driver Model.
> > 
> > I understand that some platforms really must initialize some clocks very
> > early, but can we please separate those into one table and call
> > CLK_OF_DECLARE on only that set, and then register the rest through a
> > platform_driver later on?
> 
> I know CLK_OF_DECLARE is much earlier than platform_driver, so it can
> ensure all drivers lookup their clocks successfully during
> platform_driver probe. Is there anything different to init these clock
> providers in CLK_OF_DECLARE and platform_driver?

This a common pattern we're seeing right now. Joachim did a nice job of
supporting early clocks with CLK_OF_DECLARE, and also using a proper
driver in his lpc18xx implementation:

http://marc.info/?l=devicetree&m=145618160610001

Regards,
Mike

> 
> 
> Best regards,
> 
> James
> 
> 
> 


From mturquette at baylibre.com  Wed Feb 24 13:47:06 2016
From: mturquette at baylibre.com (Michael Turquette)
Date: Wed, 24 Feb 2016 13:47:06 -0800
Subject: [PATCH] clk: gpio: Really allow an optional clock= DT property
In-Reply-To: <20160223113059.GH19428@n2100.arm.linux.org.uk>
References: <20160219030731.GS4847@codeaurora.org>
 <1455851525-18972-1-git-send-email-sboyd@codeaurora.org>
 <20160223113059.GH19428@n2100.arm.linux.org.uk>
Message-ID: <20160224214706.2278.79643@quark.deferred.io>

Hi Russell,

Quoting Russell King - ARM Linux (2016-02-23 03:30:59)
> On Thu, Feb 18, 2016 at 07:12:05PM -0800, Stephen Boyd wrote:
> > We mis-merged the original patch from Russell here and so the
> > patch went almost all the way, except that we still failed to
> > probe when there wasn't a clocks property in the DT node. Allow
> > that case by making a negative value from
> > of_clk_get_parent_count() into "no parents", like the original
> > patch did.
> 
> So you apply it anyway, and ignore all further discussion.  I've
> no idea what kind of politics is going on here, but it has to stop.

Stephen fixed the bug, and I didn't ask you to test because you made it
clear that you did not have the time (understandable). Stephen
reproduced the issue locally and insured that his version of the fix
does actually fix it.

He is an equal co-maintainer so of course I support him to merge the
fix, plus I find his version more readable.

> 
> I'm also still waiting for that apology from Mike - never apply a

No thematics please. When you wrongly accused me of merging code outside
of the merge window[0] did I ask for an apology?

> modified patch without stating in the commit log that it was modified.
> It's basically fraud.

An oversight for which we are both equally guilty. The "change" was the
resolution of a merge conflict, and I posted the resolved version of the
patch to the thread[0]. You said, "Looks fine, thanks."

In summary: bugs happen. Let's please just move on and get back to work.

[0] http://lkml.kernel.org/r/<20160103105319.GB5779 at n2100.arm.linux.org.uk>

Regards,
Mike

> 
> -- 
> RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.


From wpdster at gmail.com  Wed Feb 24 14:06:03 2016
From: wpdster at gmail.com (Patrick Doyle)
Date: Wed, 24 Feb 2016 17:06:03 -0500
Subject: USB_GADGETFS in kernel vs module
Message-ID: <CAF_dkJBmwCjjneqiynEiRyC5UuOzkS=2H=uyawxc4V2whySneA@mail.gmail.com>

Yes, I know it's archaic, and possibly even obsolete, but I have code
that uses it.

I have a _defconfig file that sets CONFIG_USB_GADGETFS to "y".

If I do the following:

$ cp path/to/my/defconfig .config
$ yes "" | make -k ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- oldconfig

I get a .config file with CONFIG_USB_GADGETFS set to "m".
(This is what buildroot does, which is where I found this.)

Is there any way I can hand-tweak my _defconfig file so that
CONFIG_USB_GADGETFS remains "y"?

If you want to play along at home (with the linux-at91 kernel, if that
makes a difference, which I doubt), you can do the following to see
the problem:

$ echo CONFIG_MODULES=y > .config
$ echo CONFIG_USB_GADGET=y >> .config
$ echo CONFIG_USB_GADGETFS=y >> .config
$ yes "" | make -k ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- oldconfig
...
$ grep CONFIG_USB_GADGET .config
CONFIG_USB_GADGET=y
# CONFIG_USB_GADGET_DEBUG_FILES is not set
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
# CONFIG_USB_GADGET_XILINX is not set
CONFIG_USB_GADGETFS=m


After some amount of experimentation and bisection, I have learned
that CONFIG_USB_GADGETFS defaults to "m" when CONFIG_MODULES=y,
despite the fact that I set it to "y" in my config file fragment.

Why is that?  Any clues?

Thanks.

--wpd


From sfr at canb.auug.org.au  Wed Feb 24 14:07:02 2016
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Thu, 25 Feb 2016 09:07:02 +1100
Subject: linux-next: manual merge of the renesas tree with the arm-soc tree
Message-ID: <20160225090702.6f090bcf@canb.auug.org.au>

Hi Simon,

Today's linux-next merge of the renesas tree got a conflict in:

  arch/arm64/configs/defconfig

between commit:

  efdda175c07f ("arm64: defconfig: add spmi and usb related configs")

from the arm-soc tree and commit:

  a9c42f02387c ("arm64: defconfig: Add Renesas R-Car Gen3 USB 2.0 phy driver support")

from the renesas tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/configs/defconfig
index 7fddb2188f5c,eaf738a59927..000000000000
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@@ -230,7 -213,7 +230,8 @@@ CONFIG_QCOM_SMD_RPM=
  CONFIG_ARCH_TEGRA_132_SOC=y
  CONFIG_ARCH_TEGRA_210_SOC=y
  CONFIG_HISILICON_IRQ_MBIGEN=y
 +CONFIG_EXTCON_USB_GPIO=y
+ CONFIG_PHY_RCAR_GEN3_USB2=y
  CONFIG_PHY_XGENE=y
  CONFIG_EXT2_FS=y
  CONFIG_EXT3_FS=y


From robh at kernel.org  Wed Feb 24 14:07:04 2016
From: robh at kernel.org (Rob Herring)
Date: Wed, 24 Feb 2016 16:07:04 -0600
Subject: [PATCH 1/3] dt-bindings: arm/marvell: ABI unstability warning
 about Marvell 7K/8K
In-Reply-To: <20160224211045.379352d3@free-electrons.com>
References: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1456327007-31008-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160224172545.GC9137@leverpostej>
 <20160224211045.379352d3@free-electrons.com>
Message-ID: <CAL_JsqLevrujSeYNBvSJA-5T0Ho8y7c0fKid7QvVm8LLvYLotw@mail.gmail.com>

On Wed, Feb 24, 2016 at 2:10 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Hello,
>
> On Wed, 24 Feb 2016 17:25:46 +0000, Mark Rutland wrote:
>
>> On Wed, Feb 24, 2016 at 04:16:45PM +0100, Thomas Petazzoni wrote:
>> > Since we are still very early in the support of Marvell Armada 7/8K
>> > chips and those chips are significantly different from earlier 32 bits
>> > Armada SOCs, it is difficult to commit to Device Tree ABI stability at
>> > this point.
>>
>> I don't see why difference to an existing SoC means that we cannot
>> guarantee support for this DT. Why does that contribute to instability?
>>
>> If there's something we're unsure about, we should be seeding the DT
>> with sufficient information to do the right thing(TM) in future. What
>> areas in particular do you think are likely to be problematic? Is there
>> anything in particular that you think that approach doesn't work for?
>
> At this point, we have incomplete information about the HW capabilities
> and register layout. Our past experience has shown that when we start
> supporting SoC that early,

that early ...?

You should fix the incomplete information problem. I pushed back on
this, you got more information and already the binding is closer to
reality.

>> From my PoV, if we're so uncertain about a DT binding that it cannot be
>> kept supported, it is a prototype not yet fit for mainline.
>
> Are you really serious when you say that ?
>
> The Linux kernel community has been encouraging hardware vendor for
> *years* to get their code merged as early as possible. And now that
> they are doing it, you are telling them that they shouldn't submit
> their code to mainline ?

Mark didn't say don't submit. First, there is value in submitting even
if not accepted immediately and you have to carry some patches for
some time. It was also suggested that you err on the side of less
information in DT if things are uncertain and you have not done that.

> If that's what you want, then sorry, but I don't buy this argument, and
> I will continue to encourage HW vendors to submit their code early,
> even if it means that indeed in the early stages, things remain a bit
> in-flux and need to be refined progressively.
>
> You seem to really be in your ivory tower and not seeing the reality of
> an SoC development and how to push the support for it in mainline as
> early as possible, so that the BSPs shipped to actual customers are as
> close to mainline as possible. Together with the Marvell engineers, we
> are doing a huge amount of work to ensure that this vendor BSP is as
> close as mainline as possible. And you're basically telling us we
> should this effort ?
>
> Come on, be serious.
>
>> > Therefore, this commit adds a warning to the Marvell 7K/8K DT binding
>> > documentation to indicate that the bindings are for the moment
>> > unstable.
>>
>> As with the other thread, I'm strongly opposed to this mentality.
>
> Many other platforms have made this choice: Atmel, Marvell Berlin, and
> probably others.

Atmel has had a year now with that statement. Time to remove it IMO.

I think we need to only allow this at a binding level and not at SoC
family level and also require a timeline to marking stable.

> I think it should be up to each platform vendor to decide whether they
> care about DT stability or not, and at which point in time in the life
> cycle of their platform they want to claim the DT bindings as stable.
> You might believe that DT bindings are stable, but they are not. They
> change constantly, in very subtle way, and nobody ever tests DT from
> kernel version N-x with kernel version N. On any real-life platform, it
> simply doesn't work, unless that platform is 5+ years old.
>
> I made a talk at ELC about DT stability being a fairy tale, and I
> remember very well Rob Herring coming to me during the social event
> afterwards, telling me that it has never been said that all platforms
> should conform strictly to this DT stability requirement.

True, but it is still an exception and I never said I wouldn't push back.

> So please get to an agreement between DT binding maintainers. And stop
> saying this ridiculous statement that HW vendors should stop submitting
> their code to the mainline.

You want us to agree, then you won't like the answer. Bindings must be
stable. I'll allow exceptions to that, but not without push back.

In general, if there is disagreement about whether stability is
required, then it is required. See the recent sunxi discussion. That's
more between users and platform maintainers though.

Rob


From olof at lixom.net  Wed Feb 24 12:18:08 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 12:18:08 -0800
Subject: [GIT PULL] RealView defconfig reduction
In-Reply-To: <CACRpkdYUPFm=s6mZbU8xTHqQBtcvmdCzaTCfSBPfBQ1qQi2f5Q@mail.gmail.com>
References: <CACRpkdYUPFm=s6mZbU8xTHqQBtcvmdCzaTCfSBPfBQ1qQi2f5Q@mail.gmail.com>
Message-ID: <20160224201808.GB10126@localhost>

On Tue, Feb 09, 2016 at 10:49:38AM +0100, Linus Walleij wrote:
> Hi ARM SoC folks,
> 
> this cuts the RealView SMP-specific defconfig. It is just confusing and
> hard to handle now that we can do SMP on UP.
> 
> Tested on RealView PB11MPcore (SMP) and PB1176JZF-S (UP).
> 
> I don't know if people's autobuild systems are made to handled the case
> where a defconfig disappears, so heads up to Kevin & Olof.
> 
> Please pull this in for this or the next kernel cycle whatever suits you
> best.
> 
> Yours,
> Linus Walleij
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git
> tags/realview-defconfig-redux
> 
> for you to fetch changes up to 52abf1eff88d291c5ba092dc93fc8065efd94236:
> 
>   ARM: realview: enable USB storage in the defconfig (2016-02-09 10:39:38 +0100)

Thanks, merged!

-Olof


From olof at lixom.net  Wed Feb 24 12:18:55 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 12:18:55 -0800
Subject: [GIT PULL v2] ARM: mvebu: dt for v4.6 (#1)
In-Reply-To: <87twliyzb2.fsf@free-electrons.com>
References: <87twliyzb2.fsf@free-electrons.com>
Message-ID: <20160224201855.GC10126@localhost>

On Tue, Feb 09, 2016 at 11:04:49AM +0100, Gregory CLEMENT wrote:
> Hi,
> 
> Here is the second version of the first pull request for dt for mvebu
> for v4.6.  This one is based on v4.5-rc3 because it depends on fixes
> merged previously.
> 
> As requested by Olof, I aligned the commit title.
> 
> Gregory
> 
> The following changes since commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95:
> 
>   Linux 4.5-rc3 (2016-02-07 15:38:30 -0800)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/linux-mvebu.git tags/mvebu-dt-4.6-1
> 
> for you to fetch changes up to 5dda254d0cc5cbdcc81dbce0985c35b68dd5e3b1:
> 
>   ARM: dts: kirkwood: add device tree for buffalo linkstation ls-qvl (2016-02-09 11:00:26 +0100)
> 
> ----------------------------------------------------------------
> mvebu dt for 4.6 (part 1)
> 
> - Improve Armada 38x device tree (SATA and XHCI)
> - Fix SD Card and audio support for OpenRD board
> - Provide template for RS-232/485 configuration for the same board
> - Use a common dtsi file for linkstation boards
> - Add support for Buffalo Linkstation LS-QVL

Thanks, merged.


-Olof


From olof at lixom.net  Wed Feb 24 12:19:47 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 12:19:47 -0800
Subject: [PATCH v2] arm64: defconfig: Add Qualcomm sdhci and restart
 functionality
In-Reply-To: <1455013185-946-1-git-send-email-georgi.djakov@linaro.org>
References: <1455013185-946-1-git-send-email-georgi.djakov@linaro.org>
Message-ID: <20160224201947.GD10126@localhost>

Hi,

On Tue, Feb 09, 2016 at 12:19:45PM +0200, Georgi Djakov wrote:
> Enable sdhci and restart functionality for devices based on msm8916 platform.
> Also increase the number of minors per block device to detect all available
> partitions.

Title is unfortunately misleading. Please do two patches, or update the title.


-Olof


From olof at lixom.net  Wed Feb 24 12:20:35 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 12:20:35 -0800
Subject: [PATCH] ARM: dts: spear: replace gpio-key,wakeup with
 wakeup-source property
In-Reply-To: <1455032699-3086-1-git-send-email-sudeep.holla@arm.com>
References: <1454968535-11994-1-git-send-email-sudeep.holla@arm.com>
 <1455032699-3086-1-git-send-email-sudeep.holla@arm.com>
Message-ID: <20160224202035.GE10126@localhost>

On Tue, Feb 09, 2016 at 03:44:59PM +0000, Sudeep Holla wrote:
> Keyboard driver for GPIO buttons(gpio-keys) checks for the legacy
> "gpio-key,wakeup" boolean property to enable gpio buttons as wakeup
> source.
> 
> Few dts files assign value "1" to gpio-key,wakeup which is incorrect.
> Since the presence of the boolean property indicates it is enabled,
> value of "0" or "1" have no significance.
> 
> This patch replaces the legacy "gpio-key,wakeup" with the unified
> "wakeup-source" property which inturn fixes the above mentioned issue.
> 
> Reviewed-by: Viresh Kumar <viresh.kumar at linaro.org>
> Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
> ---
>  arch/arm/boot/dts/spear1310-evb.dts | 2 +-
>  arch/arm/boot/dts/spear1340-evb.dts | 2 +-
>  arch/arm/boot/dts/spear320-hmi.dts  | 4 ++--
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> (this time adding arm at kernel.org correctly)
> 
> Hi ARM-SoC guys,
> 
> This is the only platform which doesn't have regular pull request,
> Viresh has acked it already. Can you pick this up directly for v4.6 ?

Thanks, applied.


-Olof


From olof at lixom.net  Wed Feb 24 13:36:33 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 13:36:33 -0800
Subject: [GIT PULL] NXP LPC32xx Platform Updates for v4.6 #1
In-Reply-To: <56BBE6E6.4080802@mleia.com>
References: <56BBE6E6.4080802@mleia.com>
Message-ID: <20160224213633.GF10126@localhost>

Hi!

On Thu, Feb 11, 2016 at 03:41:58AM +0200, Vladimir Zapolskiy wrote:
> Hi Arnd, Olof, Kevin,
> 
> please consider to include NXP LPC32xx platfrom updates (#1) for v4.6.
> 
> The main change is a switchover to a common clock framework driver
> for LPC32xx, this also allows to reuse a shared LPC32xx clockevent
> driver, and hence remove legacy clock and timer drivers from
> arch/arm/mach-lpc32xx.
> 
> I'm adding an official LPC32xx maintainer Roland to Cc, however
> he seems to be unresponsive for a quite long time (since 2014).
> 
> ----------------------------------------------------------------
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   https://github.com/vzapolskiy/linux.git lpc32xx/soc
> 
> for you to fetch changes up to 0ac1a101f5dd28c3894be3c0230ee7ea2e05e8aa:
> 
>   arm: lpc32xx: remove direct control of GPIOs from shared mach file (2016-02-11 02:27:04 +0200)

In the future, please use the decription you wrote above as part of a tag
description, and sign your tags. For extra credit, get other kernel developers
to sign your key (easiest done at conferences, but maybe there are other
developers in your local area that you can meet up with).

It indeed seems like Roland has gone silent lately. This happens from time to
time, but it's always good to know if it's intentional (and if he's coming
back) or not. Meanwhile, we can merge patches after review but I don't have
hardware to test on so I'd have to rely on you getting that right. If we get
regression reports we'll have to re-evaluate the approach. :)

Roland, any chance we can get a word from you on this? Thanks!


-Olof


From olof at lixom.net  Wed Feb 24 13:38:49 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 13:38:49 -0800
Subject: [GIT PULL] NXP LPC32xx DT Updates for v4.6 #1
In-Reply-To: <56BBE6E9.1080509@mleia.com>
References: <56BBE6E9.1080509@mleia.com>
Message-ID: <20160224213849.GG10126@localhost>

On Thu, Feb 11, 2016 at 03:42:01AM +0200, Vladimir Zapolskiy wrote:
> Hi Arnd, Olof, Kevin,
> 
> please consider to include NXP LPC32xx DT updates (#1) for v4.6.
> 
> The changes add description of clock providers and clock consumers,
> define default irq types of SoC controllers and add PHY3250 board
> regulators.
> 
> I'm adding an official LPC32xx maintainer Roland to Cc, however
> he seems to be unresponsive for a quite long time (since 2014).
> 
> ----------------------------------------------------------------
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   https://github.com/vzapolskiy/linux.git lpc32xx/dt
> 
> for you to fetch changes up to d06670e96267d1f1a771f71f5719c0a2c0092ec1:
> 
>   arm: dts: phy3250: add SD fixed regulator (2016-02-11 03:06:36 +0200)

Merged, thanks.


-Olof


From olof at lixom.net  Wed Feb 24 13:41:59 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 13:41:59 -0800
Subject: [GIT PULL] VExpress/Juno: DT updates for v4.6
In-Reply-To: <56BB48C4.4040604@arm.com>
References: <56BB48C4.4040604@arm.com>
Message-ID: <20160224214159.GH10126@localhost>

On Wed, Feb 10, 2016 at 02:27:16PM +0000, Sudeep Holla wrote:
> Hi ARM-SoC team,
> 
> Please pull DT updates for VExpress/Juno platforms
> 
> --
> Regards,
> Sudeep
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git
> tags/vexpress-for-v4.6/dt-updates
> 
> for you to fetch changes up to 9fd9288ed0899f9e318a97d73e777d6d3357265e:
> 
>   arm64: dts: Add HDLCD support on Juno platforms (2016-02-10 10:58:33
> +0000)

Merged, thanks.


-Olof


From olof at lixom.net  Wed Feb 24 13:47:22 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 13:47:22 -0800
Subject: [GIT PULL] STM32 DT updates for v4.6 #1
In-Reply-To: <56BC8AD7.30607@gmail.com>
References: <56BC8AD7.30607@gmail.com>
Message-ID: <20160224214722.GI10126@localhost>

On Thu, Feb 11, 2016 at 02:21:27PM +0100, Maxime Coquelin wrote:
> Hi Olof, Anrd and Kevin,
> 
> Please consider this first round of STM32 DT updates for v4.6:
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mcoquelin/stm32.git
> tags/stm32-dt-for-v4.6-1
> 
> for you to fetch changes up to b2aa7f7741f511c6a1ea266d62d203662f121ea7:
> 
>   ARM: dts: stm32f429: Boost perfs by remapping SDRAM Bank 1 to 0x0
> (2016-02-11 12:02:59 +0100)

Thanks, merged.


-Olof


From olof at lixom.net  Wed Feb 24 13:48:02 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 13:48:02 -0800
Subject: [GIT PULL] STM32 SoC updates for v4.6 #1
In-Reply-To: <56BC8AFD.7000800@gmail.com>
References: <56BC8AFD.7000800@gmail.com>
Message-ID: <20160224214802.GJ10126@localhost>

On Thu, Feb 11, 2016 at 02:22:05PM +0100, Maxime Coquelin wrote:
> Hi Olof, Arnd and Kevin,
> 
> Please consider this first round of STM32 SoC updates for v4.6:
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mcoquelin/stm32.git
> tags/stm32-soc-for-v4.6-1
> 
> for you to fetch changes up to f64e980450027e15dce5e9ec4ee19bab98aee4c5:
> 
>   ARM: mach-stm32: Select pinctrl (2016-01-27 19:45:57 +0100)

Thanks, merged.


-Olof


From olof at lixom.net  Wed Feb 24 13:50:46 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 13:50:46 -0800
Subject: [GIT PULL 1/4] rockchip soc-driver changes for 4.6
In-Reply-To: <1734524.3yNt5L3F1F@phil>
References: <1734524.3yNt5L3F1F@phil>
Message-ID: <20160224215046.GK10126@localhost>

On Thu, Feb 11, 2016 at 03:47:12PM +0100, Heiko Stuebner wrote:
> Hi Arnd, Olof, Kevin,
> 
> please find below soc driver changes for Rockchip for 4.6
> The tag describes the changes a little bit more.
> 
> 
> Thanks
> Heiko
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.6-rockchip-drivers1
> 
> for you to fetch changes up to 1d961f11a108af9f7fbe89cc950a8d16ddbdbb28:
> 
>   soc: rockchip: power-domain: fix err handle while probing (2016-02-02 22:18:31 +0100)

Merged, thanks.


-Olof


From olof at lixom.net  Wed Feb 24 14:02:53 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 14:02:53 -0800
Subject: [GIT PULL v2] Renesas ARM Based SoC DT Updates for v4.6
In-Reply-To: <cover.1455303422.git.horms+renesas@verge.net.au>
References: <cover.1455303422.git.horms+renesas@verge.net.au>
Message-ID: <20160224220253.GQ10126@localhost>

On Fri, Feb 12, 2016 at 08:05:46PM +0100, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
> 
> Please consider these Renesas ARM based SoC DT updates for v4.6.
> 
> 
> Changes since v1 of this pull-request:
> * Drop two non-DT patches
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt-for-v4.6
> 
> for you to fetch changes up to c3373b09ba0391bcd9e992b0a2ce52d48d33e47b:
> 
>   ARM: dts: silk: Enable SCIF_CLK frequency and pins (2016-02-09 19:43:28 +0100)
> 
> ----------------------------------------------------------------
> Renesas ARM Based SoC DT Updates for v4.6
> 
> * Use SCIF and USBHS fallback compatibility strings
> * Add Baud Rate Generator (BRG) support for (H)SCIF
> * Enable SCIF_CLK frequency and pins
> * Use GIC_* defines
> * Enable audio on r8a7793/gose
> * Enable HDMI vidio out on r8a7793
> * Enable i2c on r8a7793/gose
> * Enable QSPI on alt
> * Enable GPIO keys and leds on gise
> * Enable audio on porter
> * Enable DU on porter

Merged, thanks.


-Olof


From olof at lixom.net  Wed Feb 24 13:51:23 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 13:51:23 -0800
Subject: [GIT PULL 2/4] rockchip arm64 changes for 4.6
In-Reply-To: <2157996.gfpT01ltKJ@phil>
References: <1734524.3yNt5L3F1F@phil>
 <2157996.gfpT01ltKJ@phil>
Message-ID: <20160224215123.GL10126@localhost>

On Thu, Feb 11, 2016 at 03:50:51PM +0100, Heiko Stuebner wrote:
> Hi Arnd, Olof, Kevin,
> 
> This one change enables the rockchip timer driver on 64bit socs as well,
> after it got fixed to actually work on 64bit in 4.5-rc1.
> 
> This time I actually also updated the subject from my previous send-attempt, 
> so here it is again.
> 
> Thanks
> Heiko
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git 
> tags/v4.6-rockchip-soc64-1
> 
> for you to fetch changes up to c840f28bbf643c361c463bcb8fb815d0b2dad4e8:
> 
>   arm64: Enable the timer on Rockchip architecture (2016-01-24 23:33:14 
> +0100)

Merged, thanks.


-Olof


From olof at lixom.net  Wed Feb 24 13:52:12 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 13:52:12 -0800
Subject: [GIT PULL 3/4] rockchip dts64 changes for 4.6
In-Reply-To: <29700148.FpDzERqiyH@phil>
References: <1734524.3yNt5L3F1F@phil>
 <29700148.FpDzERqiyH@phil>
Message-ID: <20160224215212.GM10126@localhost>

On Thu, Feb 11, 2016 at 03:52:40PM +0100, Heiko Stuebner wrote:
> Hi Arnd, Olof, Kevin,
> 
> some small 64bit devicetree changes for 4.6 that allow mmc tuning and
> use the newer wakeup-source property for the gpio-keys.
> 
> 
> Thanks
> Heiko
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.6-rockchip-dts64-1
> 
> for you to fetch changes up to e6f49b118f73a769ec51ed28a085e9dccd67f9a1:
> 
>   arm64: dts: rockchip: replace gpio-key,wakeup with wakeup-source property (2016-02-10 00:23:24 +0100)
> 
> ----------------------------------------------------------------
> Define the tuning-related mmc clocks and move from
> gpio-key,wakeup to the more generic wakeup-source property.

Merged, thanks.


-Olof


From olof at lixom.net  Wed Feb 24 13:53:28 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 13:53:28 -0800
Subject: [GIT PULL 4/4] rockchip dts32 changes for 4.6
In-Reply-To: <22050679.RDDVtpO0ps@phil>
References: <1734524.3yNt5L3F1F@phil>
 <22050679.RDDVtpO0ps@phil>
Message-ID: <20160224215328.GN10126@localhost>

On Thu, Feb 11, 2016 at 04:12:35PM +0100, Heiko Stuebner wrote:
> Hi Arnd, Olof, Kevin,
> 
> and finally this is the biggest set ... 32bit devicetree changes.
> For the clock-ids this includes a shared branch that gets shared
> with the clock-branch sent to the clock-maintainers.
> 
> As the tag describes, contents are pretty diverse but simple changes.
> 
> 
> Thanks
> Heiko
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.6-rockchip-dts32-1
> 
> for you to fetch changes up to 741d3b0c1f6187dbf9b509b6776c77828d4c66d5:
> 
>   ARM: dts: cros-ec-keyboard: Add LOCK key to keyboard matrix (2016-02-10 22:41:53 +0100)
> 
> ----------------------------------------------------------------
> Assorted bunch of 32bit Rockchip devicetree changes. More clocks,
> nodes and fixes like the increased drive-strength on the firefly.
> Most interesting is maybe the enablement of the pl330 option
> for handling the broken flushp operation that is present on the
> current Rockchip SoCs. Together with the driver-side enablement
> this should give us working dma finally.

Merged, thanks!


-Olof


From olof at lixom.net  Wed Feb 24 14:00:03 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 14:00:03 -0800
Subject: [PATCH v3 0/6] arm: Add Artpec-6 SoC
In-Reply-To: <2697188.EpDoHh0fx4@wuerfel>
References: <cover.1455205057.git.larper@axis.com> <2697188.EpDoHh0fx4@wuerfel>
Message-ID: <20160224220003.GO10126@localhost>

Hej,

On Thu, Feb 11, 2016 at 05:20:27PM +0100, Arnd Bergmann wrote:
> On Thursday 11 February 2016 17:06:15 Lars Persson wrote:
> > Basic support for the Axis Artpec-6 ARM SoC. Timers, interrupts, UARTs and
> > ethernet are wired up.
> > 
> > Changes since v2:
> > - Create a syscon binding for the system controller.
> > - Clock patches split out to new patch series "clk: Add Artpec-6 SoC support".
> 
> Looks all good to me now, impressive for v3 on a new platform port!
> 
> We'll apply it in the next few days, unless further review comments come in.

Indeed, nice and clean. I have two minor nits:

1) We prefix with ARM:, not arm:. I fixed this up for you. I also added ARM:
   dts: artpeg: ... on the dts changes. Not a huge deail on those.

2) Several of the patches lacked description. Subject pretty much says it all,
   but it's still nice to have a sentence or two as description. Again, not
   a huge deal, and I applied anyway, but for the future think about it.


That being said, I've applied the series across next/soc, next/dt and
next/defconfig. Thanks!


-Olof


From olof at lixom.net  Wed Feb 24 14:01:57 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 14:01:57 -0800
Subject: [PATCH] dtb: amd: Fix-up for ccn504 and kcs nodes
In-Reply-To: <1455236443-23949-1-git-send-email-Suravee.Suthikulpanit@amd.com>
References: <1455236443-23949-1-git-send-email-Suravee.Suthikulpanit@amd.com>
Message-ID: <20160224220157.GP10126@localhost>

On Fri, Feb 12, 2016 at 07:20:43AM +0700, Suravee Suthikulpanit wrote:
> From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
> 
> This is a fix-up patch based on the review comment from
> Arnd regarding:
>     * fix ccn504 address in the node name
>     * remove kcs interrupt-name
> 
> Signed-off-by: Brijesh Singh <brijesh.singh at amd.com>
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
> Cc: Arnd Bergmann <arnd at arndb.de>
> ---
> 
> Hi Olof,
> 
> Here are the changes from the V3 that I sent earlier. Sorry for confusion.
> Would you please pull this into the next tree?
> 
> Thank you,
> Suravee

Applied.

I also noticed that the patch subjects were nonstandard the last time around.
In the future, please use:

arm64: dts: amd: ...

as prefix, instead of just dtb (which is the binary format). I fixed it up for
this patch, and the others, well, they're already applied. So let's try to
remember it for the future.


-Olof


From olof at lixom.net  Wed Feb 24 14:04:07 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 14:04:07 -0800
Subject: [GIT PULL] arm64: X-Gene platforms DTS changes queued for v4.6 -
 part1
In-Reply-To: <CADaLNDk3n3WQyRZ3rCwDQBhT4QDAycTaqhSbe4P4MMhxUxCdUA@mail.gmail.com>
References: <CADaLNDk3n3WQyRZ3rCwDQBhT4QDAycTaqhSbe4P4MMhxUxCdUA@mail.gmail.com>
Message-ID: <20160224220407.GR10126@localhost>

On Sun, Feb 14, 2016 at 11:13:21AM -0800, Duc Dang wrote:
> [Resend in plain text format]
> 
> Hi Arnd, Olof,
> 
> This is the first part of DT changes for X-Gene platforms queued for
> 4.6. This includes only 1 change in compatible string for X-Gene v2
> SOC PLL.
> 
> Regards,
> Duc Dang.
> -------
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   https://github.com/AppliedMicro/xgene-next.git tags/xgene-dts-for-v4.6-part1
> 
> for you to fetch changes up to a8618b52bca015be7ae342423ba9b6d2e9a8037b:
> 
>   arm64: Update Merlin DT PCP PLL clock node for v2 hardware
> (2016-02-09 18:25:02 -0800)
> 
> ----------------------------------------------------------------
> First part of X-Gene DT changes queued for v4.6
> 
> This includes a change in compatible string of
> X-Gene v2 SOC PLL DT node to reflect the v2 hardware.
> This change is part of Loc's series
> http://www.spinics.net/lists/arm-kernel/msg475481.html
> 
> ----------------------------------------------------------------
> Loc Ho (1):
>       arm64: Update Merlin DT PCP PLL clock node for v2 hardware

Hi,

Please use the following patch subject format:

arm64: dts: apm: ... 

(Respin and send a fresh pull request, please)


-Olof


From linux at arm.linux.org.uk  Wed Feb 24 14:18:18 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 24 Feb 2016 22:18:18 +0000
Subject: [PATCH] clk: gpio: Really allow an optional clock= DT property
In-Reply-To: <20160224214706.2278.79643@quark.deferred.io>
References: <20160219030731.GS4847@codeaurora.org>
 <1455851525-18972-1-git-send-email-sboyd@codeaurora.org>
 <20160223113059.GH19428@n2100.arm.linux.org.uk>
 <20160224214706.2278.79643@quark.deferred.io>
Message-ID: <20160224221818.GO19428@n2100.arm.linux.org.uk>

On Wed, Feb 24, 2016 at 01:47:06PM -0800, Michael Turquette wrote:
> Hi Russell,
> 
> Quoting Russell King - ARM Linux (2016-02-23 03:30:59)
> > On Thu, Feb 18, 2016 at 07:12:05PM -0800, Stephen Boyd wrote:
> > > We mis-merged the original patch from Russell here and so the
> > > patch went almost all the way, except that we still failed to
> > > probe when there wasn't a clocks property in the DT node. Allow
> > > that case by making a negative value from
> > > of_clk_get_parent_count() into "no parents", like the original
> > > patch did.
> > 
> > So you apply it anyway, and ignore all further discussion.  I've
> > no idea what kind of politics is going on here, but it has to stop.
> 
> Stephen fixed the bug, and I didn't ask you to test because you made it
> clear that you did not have the time (understandable). Stephen
> reproduced the issue locally and insured that his version of the fix
> does actually fix it.

Right, so let's go back shall we.

The reason this bug happened is because you changed fully tested code
as a result of a merge conflict.  The result was not tested.

Now, rather than going back to the tested patch, you maintainers decide
to create yet another change, which is also untested and merge it
immediately into mainline.

That's really insane - you had a choice to do the sane thing: you could
have gone back and looked at my patch, realised that my patch resolves
the same problem that the conflicting patch did, and therefore the
correct resolution would be to make the code look the same after both
patches have been applied, as if it would have done if only my patch
had been applied.

And the resulting code would have been tested by implication of the
fact that the original code plus my patch was what I tested here.

But no, you guys think it's better to create some other solution to the
fuck up.

> He is an equal co-maintainer so of course I support him to merge the
> fix, plus I find his version more readable.

I really detest this maintainer shite - it seems anyone can walk up and
take 

> > I'm also still waiting for that apology from Mike - never apply a
> 
> No thematics please. When you wrongly accused me of merging code outside
> of the merge window[0] did I ask for an apology?
> 
> > modified patch without stating in the commit log that it was modified.
> > It's basically fraud.
> 
> An oversight for which we are both equally guilty.

Sorry, I disagree.  I'm not guilty of doing that, because when I apply
patches, they come straight from the patch system and are applied to
my tree unmodified.  There's no intermediate modification step possible.
Any changes I want to make are done in a separate commit.

So that's another apology you now owe me.

> The "change" was the
> resolution of a merge conflict, and I posted the resolved version of the
> patch to the thread[0]. You said, "Looks fine, thanks."

Yes, it _looked_ fine for a quick read, and I didn't test it.  I
trusted you to be competent at merge resolution, but I now see that
trust was misplaced.  I'll try to remember to pay more attention to
any changes you make in the future - or I'll merge them through my
tree.

Trust is something I initially give without earning - break that
trust and you've got to work really hard to regain it.

I'll also remind you that _I_ used to look after the clk code, until
you walked onto the scene and effectively took it away from me - I
didn't say a word about that (or all the other stuff that Linaro
"took" from me without asking.)  So you won't mind if I do a bit of
that myself by merging my own fixes through my tree.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From dhdang at apm.com  Wed Feb 24 14:28:10 2016
From: dhdang at apm.com (Duc Dang)
Date: Wed, 24 Feb 2016 14:28:10 -0800
Subject: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot
 for X-Gene v1
In-Reply-To: <56CDD767.6020103@arm.com>
References: <1455069384-22323-1-git-send-email-dhdang@apm.com>
 <1456330151.5681.46.camel@redhat.com> <56CDD767.6020103@arm.com>
Message-ID: <CADaLND=mrkxOWOzcEb8os16Rb=SDHfnn_8eSgB4bQYH3UguS3w@mail.gmail.com>

On Wed, Feb 24, 2016 at 8:16 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> On 24/02/16 16:09, Mark Salter wrote:
>> On Tue, 2016-02-09 at 17:56 -0800, Duc Dang wrote:
>>> This patch makes pci-xgene-msi driver ACPI-aware and provides
>>> MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode.
>>>
>>> Signed-off-by: Duc Dang <dhdang at apm.com>
>>> ---
>>>  drivers/pci/host/pci-xgene-msi.c | 35 ++++++++++++++++++++++++++++++++---
>>>  1 file changed, 32 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
>>> index a6456b5..466aa93 100644
>>> --- a/drivers/pci/host/pci-xgene-msi.c
>>> +++ b/drivers/pci/host/pci-xgene-msi.c
>>> @@ -24,6 +24,7 @@
>>>  #include <linux/pci.h>
>>>  #include <linux/platform_device.h>
>>>  #include <linux/of_pci.h>
>>> +#include <linux/acpi.h>
>>>
>>>  #define MSI_IR0                     0x000000
>>>  #define MSI_INT0            0x800000
>>> @@ -39,7 +40,7 @@ struct xgene_msi_group {
>>>  };
>>>
>>>  struct xgene_msi {
>>> -    struct device_node      *node;
>>> +    struct fwnode_handle    *fwnode;
>>>      struct irq_domain       *inner_domain;
>>>      struct irq_domain       *msi_domain;
>>>      u64                     msi_addr;
>>> @@ -249,6 +250,13 @@ static const struct irq_domain_ops msi_domain_ops = {
>>>      .free   = xgene_irq_domain_free,
>>>  };
>>>
>>> +#ifdef CONFIG_ACPI
>>> +static struct fwnode_handle *xgene_msi_get_fwnode(struct device *dev)
>>> +{
>>> +    return xgene_msi_ctrl.fwnode;
>>> +}
>>> +#endif
>>> +
>>>  static int xgene_allocate_domains(struct xgene_msi *msi)
>>>  {
>>>      msi->inner_domain = irq_domain_add_linear(NULL, NR_MSI_VEC,
>>> @@ -256,7 +264,7 @@ static int xgene_allocate_domains(struct xgene_msi *msi)
>>>      if (!msi->inner_domain)
>>>              return -ENOMEM;
>>>
>>> -    msi->msi_domain = pci_msi_create_irq_domain(of_node_to_fwnode(msi->node),
>>> +    msi->msi_domain = pci_msi_create_irq_domain(msi->fwnode,
>>>                                                  &xgene_msi_domain_info,
>>>                                                  msi->inner_domain);
>>
>> This doesn't work for me (ACPI probing on Mustang) unless I change this
>> to be pci_msi_create_default_irq_domain(). The problem seems to be that
>> the MSI probe happens after the PCIe RC is probed so there is no MSI domain
>> at the time the PCIe root is initialized by ACPI.
>
> pci_msi_create_default_irq_domain is the wrong thing do use, specially
> if you have multiple MSI controllers in the system. I certainly wouldn't
> want to see it being used on arm64.
>
> This is the usual dependency hell. You try moving the probing earlier,
> but that may break something else in the process.

Hi Mark and Marc,

I have modified Tianocore firmware to have MSI node declared before
PCIe node in Dsdt table. With this modification, the MSI driver will
be loaded before PCIe driver and MSI domain is available at the time
PCIe root is initialized.

So we will need a UEFI firmware update to work with this patch.

Regards,
Duc Dang.

>
>         M.
> --
> Jazz is not dead. It just smells funny...


From lorenzo.pieralisi at arm.com  Wed Feb 24 14:31:28 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Wed, 24 Feb 2016 22:31:28 +0000
Subject: [PATCH] drivers: perf: arm: implement CPU_PM notifier
In-Reply-To: <CAJ5Y-ea3gxxOEGdJMPZAh78Ap0GBvzGePhBKzQRVoJBwwY6NzA@mail.gmail.com>
References: <1456251759-24768-1-git-send-email-lorenzo.pieralisi@arm.com>
 <CANLsYkzvB0GbPeYHrcLtUz8DMHJh4FA5RVwVZ-UAm3BCznB_3w@mail.gmail.com>
 <20160224173511.GF25385@red-moon>
 <CAJ5Y-ea3gxxOEGdJMPZAh78Ap0GBvzGePhBKzQRVoJBwwY6NzA@mail.gmail.com>
Message-ID: <20160224223128.GA30750@red-moon>

On Wed, Feb 24, 2016 at 02:53:02PM -0500, Ashwin Chaugule wrote:
> Hi Lorenzo,
> 
> On 24 February 2016 at 12:35, Lorenzo Pieralisi
> <lorenzo.pieralisi at arm.com> wrote:
> > On Wed, Feb 24, 2016 at 09:20:22AM -0700, Mathieu Poirier wrote:
> >> On 23 February 2016 at 11:22, Lorenzo Pieralisi
> >
> > [...]
> >
> >> > +static int cpu_pm_pmu_notify(struct notifier_block *b, unsigned long cmd,
> >> > +                            void *v)
> >> > +{
> >> > +       struct arm_pmu *armpmu = container_of(b, struct arm_pmu, cpu_pm_nb);
> >> > +       struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
> >> > +       int enabled = bitmap_weight(hw_events->used_mask, armpmu->num_events);
> >> > +
> >> > +       if (!cpumask_test_cpu(smp_processor_id(), &armpmu->supported_cpus))
> >> > +               return NOTIFY_DONE;
> >> > +
> >> > +       /*
> >> > +        * Always reset the PMU registers on power-up even if
> >> > +        * there are no events running.
> >> > +        */
> >> > +       if (cmd == CPU_PM_EXIT && armpmu->reset)
> >> > +               armpmu->reset(armpmu);
> >>
> >> I think this patch does the right thing but I can't get the above
> >> reset.  Wouldn't it be better to do the reset as part of the
> >> CPU_PM_EXIT case below?  At this point nothing tells us the CPU won't
> >> go back down before the event is enabled, wasting the cycle needed to
> >> reset the PMU.
> >
> > The logic goes, if the cpu is woken up and it has no events enabled,
> > if we do not reset it (mind, ->reset here sets the PMU register values
> > to a sane default, some of them are architecturally UNKNOWN on reset, it
> > does NOT reset the PMU) _and_ we subsequently install an event on it we
> > do have a problem, that's why whenever a core gets out of low-power we
> > have to reset its pmu.
> 
> Dont we blow out the previous value in the counter when installing an
> event? Or has that changed lately? IIRC, there was some initial value
> we'd program into the counter to avoid missing the overflow event.
> (sorry its been too long) ;)

If you mean there is no need of resetting the value since we are
overwriting it anyway you should see ->reset from a PMU unit POW
not just an event. If you look at the ->reset method for eg v8, you
will see that the reset method operates on all counters and the PMU
unit as a whole, that's the only sane way of setting up the PMU unit
before enabling single counters (some registers are UNKNOWN at reset).

To make my reply to Mathieu clearer, the ->reset method contains
operations (eg writing PMCR counters reset bits) that do carry out
counters reset, what I wanted to say is that the ->reset method
does not by itself drive the PMU HW reset signal, that's what the
power controller does when it resets the CPU on power up.

The PMU ->reset method must be called on a cpu on power-up, to make
sure PMU HW is set-up to sane default values and ready to be used (ie
install counters), for instance on v8 all counters must be disabled
(irq inclusive) and reset, that's what armv8pmu_reset() does.

I hope this makes things clearer.

Thanks,
Lorenzo


From dhdang at apm.com  Wed Feb 24 14:33:24 2016
From: dhdang at apm.com (Duc Dang)
Date: Wed, 24 Feb 2016 14:33:24 -0800
Subject: [GIT PULL] arm64: X-Gene platforms DTS changes queued for v4.6 -
 part1
In-Reply-To: <20160224220407.GR10126@localhost>
References: <CADaLNDk3n3WQyRZ3rCwDQBhT4QDAycTaqhSbe4P4MMhxUxCdUA@mail.gmail.com>
 <20160224220407.GR10126@localhost>
Message-ID: <CADaLNDk2HEkxV1=2rPj4FGR915Z-9vZmrD_T1aQFK1LmhHaX7w@mail.gmail.com>

On Wed, Feb 24, 2016 at 2:04 PM, Olof Johansson <olof at lixom.net> wrote:
> On Sun, Feb 14, 2016 at 11:13:21AM -0800, Duc Dang wrote:
>> [Resend in plain text format]
>>
>> Hi Arnd, Olof,
>>
>> This is the first part of DT changes for X-Gene platforms queued for
>> 4.6. This includes only 1 change in compatible string for X-Gene v2
>> SOC PLL.
>>
>> Regards,
>> Duc Dang.
>> -------
>>
>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>
>>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>
>> are available in the git repository at:
>>
>>   https://github.com/AppliedMicro/xgene-next.git tags/xgene-dts-for-v4.6-part1
>>
>> for you to fetch changes up to a8618b52bca015be7ae342423ba9b6d2e9a8037b:
>>
>>   arm64: Update Merlin DT PCP PLL clock node for v2 hardware
>> (2016-02-09 18:25:02 -0800)
>>
>> ----------------------------------------------------------------
>> First part of X-Gene DT changes queued for v4.6
>>
>> This includes a change in compatible string of
>> X-Gene v2 SOC PLL DT node to reflect the v2 hardware.
>> This change is part of Loc's series
>> http://www.spinics.net/lists/arm-kernel/msg475481.html
>>
>> ----------------------------------------------------------------
>> Loc Ho (1):
>>       arm64: Update Merlin DT PCP PLL clock node for v2 hardware
>
> Hi,
>
> Please use the following patch subject format:
>
> arm64: dts: apm: ...
>
> (Respin and send a fresh pull request, please)

Hi Olof,

I will send another fresh pull request with fixed patch subject soon.
I have several other patches queued, so I will include them as well in
the new pull request.

Regards,
Duc Dang.
>
>
> -Olof


From linux at arm.linux.org.uk  Wed Feb 24 14:33:50 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Wed, 24 Feb 2016 22:33:50 +0000
Subject: [PATCH 1/2] ARM: mvebu: change order of ethernet DT nodes on
 Armada 38x
In-Reply-To: <20160224184114.GB2292@1wt.eu>
References: <1453907300-28283-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1453907300-28283-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160127193143.GF10826@n2100.arm.linux.org.uk>
 <20160127194512.GA16638@1wt.eu>
 <20160129114853.GQ10826@n2100.arm.linux.org.uk>
 <20160224184114.GB2292@1wt.eu>
Message-ID: <20160224223350.GP19428@n2100.arm.linux.org.uk>

On Wed, Feb 24, 2016 at 07:41:14PM +0100, Willy Tarreau wrote:
> Hi Russell,
> Well, now I'm one of these and I confirm that it's really painful to
> have a different ordering between the DTB provided in mainline and the
> DTB provided with the board. The worst thing is that using mainline,
> eth0 corresponds to the switch and appears up, so you don't immediately
> realize that it's not where your cable is connected :-/
> 
> Thus could we please get Thomas' patch to ensure that the board boots
> with similar interface naming with both the original and mainline kernel ?

I didn't say no to it, I merely asked a few pertinent questions and
made some pertinent points.

Let me restate:

* Today, people who switch between mainline and vendor kernels
  experience some pain due to the NIC order changing.

* Mainline has had support for Armada 38x for 2 years now, which is
  long enough for it to have gained users.  AFAICS, there haven't been
  any complaints about the different NIC ordering.  Changing the NIC
  ordering is going to cause breakage to these users when they migrate
  across the change.

By making the change, we're effectively telling these mainline-only
users "we don't care about your setups, we're going to break them"
because that's exactly what we're going to do.

Of course, if no one complains about the change, you've got away
with it.

I think the folk who want to make this change should be prepared for
userspace breakage reports: Linus feels very strongly about zero
userspace regressions, as we all should know.

What I'm saying, therefore, is make the change, but if you have one
report that someone's userspace setup has broken as a result of the
change, the change must be reverted.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From w at 1wt.eu  Wed Feb 24 14:56:41 2016
From: w at 1wt.eu (Willy Tarreau)
Date: Wed, 24 Feb 2016 23:56:41 +0100
Subject: [PATCH 1/2] ARM: mvebu: change order of ethernet DT nodes on
 Armada 38x
In-Reply-To: <20160224223350.GP19428@n2100.arm.linux.org.uk>
References: <1453907300-28283-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1453907300-28283-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160127193143.GF10826@n2100.arm.linux.org.uk>
 <20160127194512.GA16638@1wt.eu>
 <20160129114853.GQ10826@n2100.arm.linux.org.uk>
 <20160224184114.GB2292@1wt.eu>
 <20160224223350.GP19428@n2100.arm.linux.org.uk>
Message-ID: <20160224225641.GC2333@1wt.eu>

On Wed, Feb 24, 2016 at 10:33:50PM +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 24, 2016 at 07:41:14PM +0100, Willy Tarreau wrote:
> > Hi Russell,
> > Well, now I'm one of these and I confirm that it's really painful to
> > have a different ordering between the DTB provided in mainline and the
> > DTB provided with the board. The worst thing is that using mainline,
> > eth0 corresponds to the switch and appears up, so you don't immediately
> > realize that it's not where your cable is connected :-/
> > 
> > Thus could we please get Thomas' patch to ensure that the board boots
> > with similar interface naming with both the original and mainline kernel ?
> 
> I didn't say no to it, I merely asked a few pertinent questions and
> made some pertinent points.

Yes I'm well aware, which is why I was bringing some feedback.

> Let me restate:
> 
> * Today, people who switch between mainline and vendor kernels
>   experience some pain due to the NIC order changing.
> 
> * Mainline has had support for Armada 38x for 2 years now, which is
>   long enough for it to have gained users.

I didn't realize it had been *that* long, I thought early support was
very limited, but I can indeed see that the first dtsi was already
fairly complete (though lots of patches came up recently, including
one to disable IP checksumming on jumbo frames that's only 3 months
old).

>   AFAICS, there haven't been
>   any complaints about the different NIC ordering.  Changing the NIC
>   ordering is going to cause breakage to these users when they migrate
>   across the change.

Yes, and the problem is that there are two expected breakages : going from
LSP to "old mainline" and going from "old mainline" to "new mainline".
Since boards ship with LSP by default, I think that not doing the change
will lead to causing breakage at least once for each user going to
mainline, while doing it will only cause breakage to users who have
already experienced breakage.

> By making the change, we're effectively telling these mainline-only
> users "we don't care about your setups, we're going to break them"
> because that's exactly what we're going to do.

Not exactly, we're telling "if you moved away from the original kernel,
you have already experienced breakage so apparently you know how to fix
it, and if it's the first time you move away from it you won't notice
anything" :-)

> Of course, if no one complains about the change, you've got away
> with it.
> 
> I think the folk who want to make this change should be prepared for
> userspace breakage reports: Linus feels very strongly about zero
> userspace regressions, as we all should know.

Oh yes and I've always agreed with him regarding this!

> What I'm saying, therefore, is make the change, but if you have one
> report that someone's userspace setup has broken as a result of the
> change, the change must be reverted.

Makes sense. If any breakage is reported, it would be interested to
know if it's on a multi-port board or single-port one.

Thanks,
Willy



From khilman at baylibre.com  Wed Feb 24 14:57:36 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Wed, 24 Feb 2016 14:57:36 -0800
Subject: [PATCH] MAINTAINERS: unify email addrs for Kevin Hilman
Message-ID: <1456354656-23179-1-git-send-email-khilman@baylibre.com>

I have a couple different emails in here.  It's time to make them all
the same.

Signed-off-by: Kevin Hilman <khilman at baylibre.com>
---
 MAINTAINERS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2fa3303ea625..d489445d6d08 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7828,7 +7828,7 @@ S:	Maintained
 F:	arch/arm/*omap*/*clock*
 
 OMAP POWER MANAGEMENT SUPPORT
-M:	Kevin Hilman <khilman at deeprootsystems.com>
+M:	Kevin Hilman <khilman at kernel.org>
 L:	linux-omap at vger.kernel.org
 S:	Maintained
 F:	arch/arm/*omap*/*pm*
@@ -7934,7 +7934,7 @@ F:	arch/arm/*omap*/usb*
 OMAP GPIO DRIVER
 M:	Grygorii Strashko <grygorii.strashko at ti.com>
 M:	Santosh Shilimkar <ssantosh at kernel.org>
-M:	Kevin Hilman <khilman at deeprootsystems.com>
+M:	Kevin Hilman <khilman at kernel.org>
 L:	linux-omap at vger.kernel.org
 S:	Maintained
 F:	Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -9945,7 +9945,7 @@ F:	arch/arm/mach-s3c24xx/bast-irq.c
 
 TI DAVINCI MACHINE SUPPORT
 M:	Sekhar Nori <nsekhar at ti.com>
-M:	Kevin Hilman <khilman at deeprootsystems.com>
+M:	Kevin Hilman <khilman at kernel.org>
 T:	git git://gitorious.org/linux-davinci/linux-davinci.git
 Q:	http://patchwork.kernel.org/project/linux-davinci/list/
 S:	Supported
-- 
2.7.0



From olof at lixom.net  Wed Feb 24 14:18:29 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 14:18:29 -0800
Subject: [GIT PULL 1/7] ARM: EXYNOS: Non-critical fixes for v4.6
In-Reply-To: <1455496446-23779-2-git-send-email-k.kozlowski@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
 <1455496446-23779-2-git-send-email-k.kozlowski@samsung.com>
Message-ID: <20160224221829.GS10126@localhost>

On Mon, Feb 15, 2016 at 09:34:00AM +0900, Krzysztof Kozlowski wrote:
> Hi Arnd, Kevin and Olof,
> 
> Few fixes from Arnd.
> 
> BTW, I did not apply one fix from his set because I had few comments
> (not resolved yet).
> 
> Kind regards,
> Krzysztof
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-fixes-non-critical-4.6
> 
> for you to fetch changes up to dc7eb9d589e595954792cc192bcbb92932e5c2ff:
> 
>   ARM: EXYNOS: select THERMAL_OF (2016-02-01 10:29:20 +0900)
> 
> ----------------------------------------------------------------
> Fixes from Arnd for harmless warnings for Exynos and S3C platforms.

Thanks, merged.


-Olof


From olof at lixom.net  Wed Feb 24 14:25:30 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 14:25:30 -0800
Subject: [GIT PULL 4/7] ARM: EXYNOS: mach/soc changes for v4.6
In-Reply-To: <1455496446-23779-5-git-send-email-k.kozlowski@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
 <1455496446-23779-5-git-send-email-k.kozlowski@samsung.com>
Message-ID: <20160224222530.GV10126@localhost>

On Mon, Feb 15, 2016 at 09:34:03AM +0900, Krzysztof Kozlowski wrote:
> Hi Arnd, Kevin and Olof,
> 
> This pulls previous tags (early DT changes, movement of SROM/PMU
> to drivers/soc) and contains other interesting stuff. Description
> along with a tag.
> 
> Kind regards,
> Krzysztof

Hi,

This shares most of the contents with the drivers/soc branch (the previous
one).

It's useful to get just the incremental delta instead of the full one, so we
can see what's new in this branch compared to the previous one.

Generating that delta is a little awkward, but you can tell git request-pull
about the different base. If you don't have backmerges since then it should
generate the right diffstat.

Holding off on this branch due to the feedback on the previous one.


-Olof


From olof at lixom.net  Wed Feb 24 14:22:54 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 14:22:54 -0800
Subject: [GIT PULL 3/7] drivers: soc: EXYNOS drivers for v4.6
In-Reply-To: <1455496446-23779-4-git-send-email-k.kozlowski@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
 <1455496446-23779-4-git-send-email-k.kozlowski@samsung.com>
Message-ID: <20160224222254.GT10126@localhost>

On Mon, Feb 15, 2016 at 09:34:02AM +0900, Krzysztof Kozlowski wrote:
> Hi Arnd, Kevin and Olof,
> 
> This finally moves SROM controller and PMU code to separate
> driver under drivers/soc/samsung.
> 
> Kind regards,
> Krzysztof
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-soc-srom-pmu-4.6
> 
> for you to fetch changes up to 74a6659e8bf193066ba6bf365de66baa897aebb1:
> 
>   drivers: soc: Add support for Exynos PMU driver (2016-01-25 10:46:59 +0900)
> 
> ----------------------------------------------------------------
> A set of changes adding new drivers under drivers/soc/samsung:
> 
> 1. Split code for handling SROM registers out of arm/mach-exynos
>    in to separate SROM controller driver under drivers/soc/samsung.
>    The driver will save and restore SROM registers during Suspend
>    to RAM.
> 
> 2. Add to this SROM controller driver support for bank configuration
>    used by child devices. This allows usage of SMSC9115 Ethernet chip
>    on SMDK5410 (Exynos5410) directly connected to SROM controller.

Hi,

OMAP has GPMC drivers under drivers/memory. I wonder if SROM should go there
too, since it's a quite similar bus.

Feel free to respin this without SROM now, so we can get the other pieces in
sooner and then revisit the SROM asyncronously. That'll remove the dependencies
on DT as well.


-Olof



From olof at lixom.net  Wed Feb 24 14:23:19 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 14:23:19 -0800
Subject: [GIT PULL 2/7] ARM: dts: Exynos DT dependency for v4.6
In-Reply-To: <1455496446-23779-3-git-send-email-k.kozlowski@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
 <1455496446-23779-3-git-send-email-k.kozlowski@samsung.com>
Message-ID: <20160224222319.GU10126@localhost>

On Mon, Feb 15, 2016 at 09:34:01AM +0900, Krzysztof Kozlowski wrote:
> Hi Arnd, Kevin and Olof,
> 
> Early DT changes for v4.6, needed before removal of SROM support
> from mach-exynos.
> 
> Kind regards,
> Krzysztof
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-srom-4.6
> 
> for you to fetch changes up to d2deef6c61e65d1e0cee40c1d74fa99007da8c84:
> 
>   ARM: dts: Add SROM to exynos5410 (2016-01-25 10:32:07 +0900)
> 
> ----------------------------------------------------------------
> Device Tree changes for v4.6 adding the nodes for Exynos SROM controller
> driver. The driver saves and restores SROM registers during suspend to RAM.
> DT changes should go in before removal of SROM support from mach-exynos.
> 
> ----------------------------------------------------------------
> Pankaj Dubey (2):
>       ARM: dts: Add SROM device node for exynos4
>       ARM: dts: Add SROM device node for exynos5
> 
> Pavel Fedin (1):
>       ARM: dts: Add SROM to exynos5410

Hi,

Please use the format:

ARM: dts: exynos: ...

in the future.

Merged for now.


-Olof


From olof at lixom.net  Wed Feb 24 14:29:54 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 14:29:54 -0800
Subject: [GIT PULL 5/7] ARM: EXYNOS: Driver changes for v4.6
In-Reply-To: <1455496446-23779-6-git-send-email-k.kozlowski@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
 <1455496446-23779-6-git-send-email-k.kozlowski@samsung.com>
Message-ID: <20160224222954.GW10126@localhost>

On Mon, Feb 15, 2016 at 09:34:04AM +0900, Krzysztof Kozlowski wrote:
> Hi Arnd, Kevin and Olof,
> 
> Just one lonely commit.
> 
> Kind regards,
> Krzysztof
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-4.6
> 
> for you to fetch changes up to 9b3f105ef6c75ef4f7f1bd982195db814830d78b:
> 
>   cpufreq: s5pv210: remove superfluous CONFIG_PM ifdefs (2016-01-25 15:13:53 +0900)

Hi,

Merged, but not sure why Viresh acked it instead of applying it.


-Olof


From olof at lixom.net  Wed Feb 24 14:31:54 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 14:31:54 -0800
Subject: [GIT PULL 6/7] ARM: dts: Exynos stuff for v4.6
In-Reply-To: <1455496446-23779-7-git-send-email-k.kozlowski@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
 <1455496446-23779-7-git-send-email-k.kozlowski@samsung.com>
Message-ID: <20160224223154.GX10126@localhost>

On Mon, Feb 15, 2016 at 09:34:05AM +0900, Krzysztof Kozlowski wrote:
> Hi Arnd, Kevin and Olof,
> 
> Rest of DTS changes for v4.6. This also pulls early DT changes (related
> to SROM controller) because rest of patches depend on it.
> 
> Kind regards,
> Krzysztof
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.6
> 
> for you to fetch changes up to 36a0282a41493400428d7df8c99701fb4ee344c2:
> 
>   ARM: dts: Replace legacy *,wakeup property with wakeup-source for exynos boards (2016-01-29 09:09:49 +0900)
> 
> ----------------------------------------------------------------
> Samsung DeviceTree updates and improvements for v4.6:
> 1. Add SROM controller device nodes.
> 2. Add Ethernet chip as child of SROM controller on SMDK5410.
> 3. Allow simultaneous usage exynos-rng and s5p-sss drivers on Exynos5.
> 4. Cleanup CPU configuration on Exynos542x/5800.
> 5. Add necessary nodes for cpufreq-dt driver on Exynos542x/5800 (OPPs,
>    regulator supplies) which allows frequency and voltage scalling
>    of this SoC.
> 6. Minor cleanups.

Merged, thanks. See feedback on the other dt branch regarding subjects.


-Olof



From olof at lixom.net  Wed Feb 24 14:33:01 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 14:33:01 -0800
Subject: [GIT PULL 7/7] ARM: EXYNOS: Defconfig changes for v4.6
In-Reply-To: <1455496446-23779-8-git-send-email-k.kozlowski@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
 <1455496446-23779-8-git-send-email-k.kozlowski@samsung.com>
Message-ID: <20160224223301.GY10126@localhost>

On Mon, Feb 15, 2016 at 09:34:06AM +0900, Krzysztof Kozlowski wrote:
> Hi Arnd, Kevin and Olof,
> 
> Defconfig changes, pulling also a tag from RTC tree (merge
> of max77802 into max77686 RTC driver).
> 
> Kind regards,
> Krzysztof
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-4.6
> 
> for you to fetch changes up to 5d51f1dde207f2d5d43158da75c6608f7bfcec03:
> 
>   ARM: multi_v7_defconfig: Remove MAX77802 RTC Kconfig symbol (2016-02-05 09:11:32 +0900)
> 
> ----------------------------------------------------------------
> Defconfig (exynos and multi_v7) changes for Exynos based boards for v4.6:
> 1. exynos defconfig:
>    a. Enable NEON and accelerated crypto,
>    b. Enable s5p-secss driver (Security SubSystem block for accelerating
>       some cryptographic operations),
> 2. exynos and multi_v7: Remove MAX77802 RTC Kconfig because the driver
>    was combined into existing rtc-max77686 driver. This depends on changes
>    from RTC tree.

Merged, thanks.


-Olof


From sboyd at codeaurora.org  Wed Feb 24 15:06:40 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Wed, 24 Feb 2016 15:06:40 -0800
Subject: [PATCH v3 6/8] arm64: dts: qcom: fix usb digital voltage levels
In-Reply-To: <1456246236-18341-1-git-send-email-srinivas.kandagatla@linaro.org>
References: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
 <1456246236-18341-1-git-send-email-srinivas.kandagatla@linaro.org>
Message-ID: <56CE3780.5060408@codeaurora.org>

On 02/23/2016 08:50 AM, Srinivas Kandagatla wrote:
> This patch updates the digital voltage levels from corner values to
> microvolts as we are going to use s1 regulator directly for vddcx
> instead of s1_corner.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
> ---

What's the plan for corners? Maybe we should remove the voltage setting
from the usb driver or drop the usb node entirely on msm8916 until we
resolve how we're going to handle corners. I'd like to avoid getting
stuck into some DT binding ABI mess here.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project



From itaru.kitayama at riken.jp  Wed Feb 24 15:28:30 2016
From: itaru.kitayama at riken.jp (Itaru Kitayama)
Date: Thu, 25 Feb 2016 08:28:30 +0900
Subject: [PATCH v3] ARM64: kernel: implement ACPI parking protocol
In-Reply-To: <20160224141832.GA26630@red-moon>
References: <1453806638-23167-1-git-send-email-lorenzo.pieralisi@arm.com>
 <20160202182657.GC15706@e104818-lin.cambridge.arm.com>
 <20160203112112.GA18387@red-moon> <20160203161834.GB26487@MBP.local>
 <20160224141832.GA26630@red-moon>
Message-ID: <56CE3C9E.7070505@riken.jp>

Lorenzo,

On Mustang the lockdep warning I reported to you is disappeared and the 
system gets to
the prompt as you implemented, however only 7 CPUs out of 8 brought up.

[    0.069461] ACPI: Core revision 20160108
[    0.098175] ACPI: 4 ACPI AML tables successfully acquired and loaded

[    0.103899] Security Framework initialized
[    0.106883] Mount-cache hash table entries: 65536 (order: 7, 524288 
bytes)
[    0.112616] Mountpoint-cache hash table entries: 65536 (order: 7, 
524288 bytes)
[    0.133953] ftrace: allocating 25237 entries in 99 pages
[    0.228040] ASID allocator initialised with 65536 entries
[    0.253856] Remapping and enabling EFI services.
[    0.257328]   EFI remap 0x0000000010510000 => 0000000020000000
[    0.262000]   EFI remap 0x0000000010548000 => 0000000020018000
[    0.266702]   EFI remap 0x0000000017000000 => 0000000020020000
[    0.271403]   EFI remap 0x000000001c025000 => 0000000020035000
[    0.276060]   EFI remap 0x000000007c0c0000 => 0000000020040000
[    0.280786]   EFI remap 0x000000007c1c0000 => 0000000020050000
[    0.285495]   EFI remap 0x000000007c2c0000 => 0000000020060000
[    0.290204]   EFI remap 0x000000007c3c0000 => 0000000020070000
[    0.294861]   EFI remap 0x000000007c4c0000 => 0000000020080000
[    0.299535]   EFI remap 0x000000007c5c0000 => 0000000020090000
[    0.304244]   EFI remap 0x000000007c6c0000 => 00000000200a0000
[    0.308927]   EFI remap 0x000000007c7c0000 => 00000000200b0000
[    0.313671]   EFI remap 0x00000047fa80c000 => 00000000200cc000
[    0.318428]   EFI remap 0x00000047fa854000 => 00000000200d4000
[    0.323139]   EFI remap 0x00000047ff9fc000 => 00000000202cc000
[    0.327894]   EFI remap 0x00000047ffa10000 => 00000000202e0000
[    0.349223] Unable to handle kernel NULL pointer dereference at 
virtual address 00000008
[    0.349228] pgd = ffffff800a918000
[    0.349236] [00000008] *pgd=00000047ffffe003, *pud=00000047ffffe003, 
*pmd=0000000000000000
[    0.349242] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[    0.349248] Modules linked in:
[    0.349255] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.5.0-rc4-core+ #32
[    0.349257] Hardware name: APM X-Gene Mustang board (DT)
[    0.349261] task: ffffffc7fab6c600 ti: ffffffc7fab70000 task.ti: 
ffffffc7fab70000
[    0.349268] PC is at acpi_parking_protocol_cpu_postboot+0x38/0xa8
[    0.349271] LR is at acpi_parking_protocol_cpu_postboot+0x1c/0xa8
[    0.349274] pc : [<ffffff80080a0a98>] lr : [<ffffff80080a0a7c>] 
pstate: 600003c5
[    0.349275] sp : ffffffc7fab73f50
[    0.349280] x29: ffffffc7fab73f50 x28: 00000000fffebd7d
[    0.349285] x27: ffffff8008082d00 x26: 0000004002b18000
[    0.349289] x25: 0000004002b15000 x24: ffffff80097d1608
[    0.349293] x23: ffffff80096554a8 x22: ffffff80097d1000
[    0.349297] x21: ffffff800972d000 x20: 0000000000000001
[    0.349302] x19: 0000000000000008 x18: 0000000030d00800
[    0.349306] x17: 000000001d100000 x16: 00000000fef7ffed
[    0.349310] x15: dedffffebe7efcae x14: 00000000f2fdfbfd
[    0.349314] x13: 00000000ae7e9e7f x12: 00000000800000c9
[    0.349319] x11: 000000009df2cf7c x10: 0000000000000000
[    0.349323] x9 : 0000000000000000 x8 : ffffff80097cf740
[    0.349327] x7 : 0000000000000000 x6 : 00000000000066a7
[    0.349332] x5 : ffffff80097cf740 x4 : ffffff80098607e0
[    0.349336] x3 : 0000000000000003 x2 : 0000000000000004
[    0.349340] x1 : ffffff8009bfa810 x0 : 0000000000000003

[    0.349344] Process swapper/1 (pid: 0, stack limit = 0xffffffc7fab70020)
[    0.349347] Stack: (0xffffffc7fab73f50 to 0xffffffc7fab74000)
[    0.349351] 3f40: ffffffc7fab73f80 ffffff80080972f8
[    0.349355] 3f60: ffffff80096554a8 0000000000000001 ffffff800972d000 
ffffff80080972b8
[    0.349358] 3f80: 0000000000000000 0000004000282cec 000000001d100000 
0000000000000e12
[    0.349362] 3fa0: 000000001d100000 00000000b77ff5fd 000000001d100000 
00000000f77f7d7f
[    0.349365] 3fc0: 0000004002b15000 0000004002b18000 ffffff8008082d00 
00000000fffebd7d
[    0.349368] 3fe0: 0000000000000000 0000000000000000 0000000000000000 
0000000000000000
[    0.349370] Call trace:
[    0.349374] Exception stack(0xffffffc7fab73d90 to 0xffffffc7fab73eb0)
[    0.349377] 3d80: 0000000000000008 0000000000000001
[    0.349380] 3da0: ffffffc7fab73f50 ffffff80080a0a98 0000000000000000 
0000000000000000
[    0.349383] 3dc0: 0000000000000000 0000000000000000 0000000000000000 
0000000000000000
[    0.349387] 3de0: 0000000000000000 0000000000000000 0000000000000000 
0000000000000000
[    0.349390] 3e00: 0000000000000000 0000000000000000 0000000000000000 
0000000000000000
[    0.349393] 3e20: 0000000000000000 0000000000000000 0000000000000003 
ffffff8009bfa810
[    0.349397] 3e40: 0000000000000004 0000000000000003 ffffff80098607e0 
ffffff80097cf740
[    0.349400] 3e60: 00000000000066a7 0000000000000000 ffffff80097cf740 
0000000000000000
[    0.349404] 3e80: 0000000000000000 000000009df2cf7c 00000000800000c9 
00000000ae7e9e7f
[    0.349406] 3ea0: 00000000f2fdfbfd dedffffebe7efcae
[    0.349411] [<ffffff80080a0a98>] 
acpi_parking_protocol_cpu_postboot+0x38/0xa8
[    0.349415] [<ffffff80080972f8>] secondary_start_kernel+0x268/0x538
[    0.349419] [<0000004000282cec>] 0x4000282cec
[    0.349423] Code: 91204021 cb000040 f8607833 91002273 (b9400273)
[    0.349483] ---[ end trace 80a6d1ac53b24c3c ]---
[    0.349487] Kernel panic - not syncing: Fatal exception
[    0.349496] ---[ end Kernel panic - not syncing: Fatal exception
[    1.350177] CPU1: failed to come online
[    1.367354] Detected PIPT I-cache on CPU2
[    1.367398] CPU2: Booted secondary processor [500f0001]
[    1.379399] Detected PIPT I-cache on CPU3
[    1.379425] CPU3: Booted secondary processor [500f0001]
[    1.391487] Detected PIPT I-cache on CPU4
[    1.391521] CPU4: Booted secondary processor [500f0001]
[    1.403536] Detected PIPT I-cache on CPU5
[    1.403562] CPU5: Booted secondary processor [500f0001]
[    1.415590] Detected PIPT I-cache on CPU6
[    1.415625] CPU6: Booted secondary processor [500f0001]
[    1.427677] Detected PIPT I-cache on CPU7
[    1.427702] CPU7: Booted secondary processor [500f0001]
[    1.427823] Brought up 7 CPUs
[    1.470268] SMP: Total of 7 processors activated.
[    1.473801] CPU: All CPU(s) started at EL2


On 2/24/16 11:18 PM, Lorenzo Pieralisi wrote:
> [+ Itaru]
>
> On Wed, Feb 03, 2016 at 04:18:36PM +0000, Catalin Marinas wrote:
>> On Wed, Feb 03, 2016 at 11:21:12AM +0000, Lorenzo Pieralisi wrote:
>>> On Tue, Feb 02, 2016 at 06:26:58PM +0000, Catalin Marinas wrote:
>>>> On Tue, Jan 26, 2016 at 11:10:38AM +0000, Lorenzo Pieralisi wrote:
>>>>> The SBBR and ACPI specifications allow ACPI based systems that do not
>>>>> implement PSCI (eg systems with no EL3) to boot through the ACPI parking
>>>>> protocol specification[1].
>>>>>
>>>>> This patch implements the ACPI parking protocol CPU operations, and adds
>>>>> code that eases parsing the parking protocol data structures to the
>>>>> ARM64 SMP initializion carried out at the same time as cpus enumeration.
>>>>>
>>>>> To wake-up the CPUs from the parked state, this patch implements a
>>>>> wakeup IPI for ARM64 (ie arch_send_wakeup_ipi_mask()) that mirrors the
>>>>> ARM one, so that a specific IPI is sent for wake-up purpose in order
>>>>> to distinguish it from other IPI sources.
>>>>>
>>>>> Given the current ACPI MADT parsing API, the patch implements a glue
>>>>> layer that helps passing MADT GICC data structure from SMP initialization
>>>>> code to the parking protocol implementation somewhat overriding the CPU
>>>>> operations interfaces. This to avoid creating a completely trasparent
>>>>> DT/ACPI CPU operations layer that would require creating opaque
>>>>> structure handling for CPUs data (DT represents CPU through DT nodes, ACPI
>>>>> through static MADT table entries), which seems overkill given that ACPI
>>>>> on ARM64 mandates only two booting protocols (PSCI and parking protocol),
>>>>> so there is no need for further protocol additions.
>>>>>
>>>>> Based on the original work by Mark Salter <msalter at redhat.com>
>>>>>
>>>>> [1] https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.docx
>>>>>
>>>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
>>>>> Cc: Will Deacon <will.deacon at arm.com>
>>>>> Cc: Hanjun Guo <hanjun.guo at linaro.org>
>>>>> Cc: Loc Ho <lho at apm.com>
>>>>> Cc: Sudeep Holla <sudeep.holla at arm.com>
>>>>> Cc: Catalin Marinas <catalin.marinas at arm.com>
>>>>> Cc: Mark Rutland <mark.rutland at arm.com>
>>>>> Cc: Mark Salter <msalter at redhat.com>
>>>>> Cc: Al Stone <ahs3 at redhat.com>
>>>> Applied, with a minor addition just to warn people from not using it in
>>>> other configurations (#ifdef still needed otherwise the
>>>> acpi_parking_protocol_valid symbol is not available; but I prefer uglier
>>>> code than people starting to use this IPI in their firmware):
>>> It makes sense, we could include asm/acpi.h in smp.c (which is not
>>> included by linux/acpi.h if !CONFIG_ACPI) to pull in the symbol and
>>> remove the ifdef if you think it is cleaner.
>> I don't think it's worth.
>>
>> BTW, the acpi_parking_protocol_valid() definition has an __init
>> annotation while the declaration does not. I removed the __init
>> altogether since I get a section mismatch warning when being called from
>> handle_IPI.
> Catalin,
>
> Itaru spotted an issue related to ioremapping the mailbox in the
> cpu_postboot method where I can't really use ioremap since irqs
> are disabled on the secondaries coming up at that point, I missed
> that, apologies (I wanted to avoid leaving the mailboxes mapped
> after boot).
>
> So, options to fix it:
>
> (1) we leave the mailboxes mapped
> (2) we remove the FW check in the postboot method (running on
>      secondaries)
> (3) I add a cpu_ops method to clean-up resources used for
>      booting secondaries and there I can unmap the mailboxes
>
> Frankly, they are all unappealing, I would go for (1), patch below, Itaru
> can you give it a go please on Mustang against arm64 for-next/core ?
>
> Thanks,
> Lorenzo
>
> -- >8 --
> diff --git a/arch/arm64/kernel/acpi_parking_protocol.c b/arch/arm64/kernel/acpi_parking_protocol.c
> index 4b1e5a7..b56fc0d 100644
> --- a/arch/arm64/kernel/acpi_parking_protocol.c
> +++ b/arch/arm64/kernel/acpi_parking_protocol.c
> @@ -21,7 +21,14 @@
>   
>   #include <asm/cpu_ops.h>
>   
> +struct parking_protocol_mailbox {
> +	__le32 cpu_id;
> +	__le32 reserved;
> +	__le64 entry_point;
> +};
> +
>   struct cpu_mailbox_entry {
> +	struct parking_protocol_mailbox __iomem *mailbox;
>   	phys_addr_t mailbox_addr;
>   	u8 version;
>   	u8 gic_cpu_id;
> @@ -59,12 +66,6 @@ static int acpi_parking_protocol_cpu_prepare(unsigned int cpu)
>   	return 0;
>   }
>   
> -struct parking_protocol_mailbox {
> -	__le32 cpu_id;
> -	__le32 reserved;
> -	__le64 entry_point;
> -};
> -
>   static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
>   {
>   	struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
> @@ -107,7 +108,11 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
>   
>   	arch_send_wakeup_ipi_mask(cpumask_of(cpu));
>   
> -	iounmap(mailbox);
> +	/*
> +	 * stash the mailbox address mapping to use it for checks
> +	 * in post boot method
> +	 */
> +	cpu_entry->mailbox = mailbox;
>   
>   	return 0;
>   }
> @@ -116,32 +121,15 @@ static void acpi_parking_protocol_cpu_postboot(void)
>   {
>   	int cpu = smp_processor_id();
>   	struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
> -	struct parking_protocol_mailbox __iomem *mailbox;
> +	struct parking_protocol_mailbox __iomem *mailbox = cpu_entry->mailbox;
>   	__le64 entry_point;
>   
> -	/*
> -	 * Map mailbox memory with attribute device nGnRE (ie ioremap -
> -	 * this deviates from the parking protocol specifications since
> -	 * the mailboxes are required to be mapped nGnRnE; the attribute
> -	 * discrepancy is harmless insofar as the protocol specification
> -	 * is concerned).
> -	 * If the mailbox is mistakenly allocated in the linear mapping
> -	 * by FW ioremap will fail since the mapping will be prevented
> -	 * by the kernel (it clashes with the linear mapping attributes
> -	 * specifications).
> -	 */
> -	mailbox = ioremap(cpu_entry->mailbox_addr, sizeof(*mailbox));
> -	if (!mailbox)
> -		return;
> -
>   	entry_point = readl_relaxed(&mailbox->entry_point);
>   	/*
>   	 * Check if firmware has cleared the entry_point as expected
>   	 * by the protocol specification.
>   	 */
>   	WARN_ON(entry_point);
> -
> -	iounmap(mailbox);
>   }
>   
>   const struct cpu_operations acpi_parking_protocol_ops = {



From horms at verge.net.au  Wed Feb 24 15:58:38 2016
From: horms at verge.net.au (Simon Horman)
Date: Thu, 25 Feb 2016 08:58:38 +0900
Subject: [PATCH 1/2] ARM: dts: r8a7790: use fallback jpu compatibility
 string
In-Reply-To: <CAMuHMdWvL0HA542+BY=H5C3=vhOrmej_hDWRheEAJyFnjd92kw@mail.gmail.com>
References: <1456280946-14859-1-git-send-email-horms+renesas@verge.net.au>
 <1456280946-14859-2-git-send-email-horms+renesas@verge.net.au>
 <CAMuHMdWvL0HA542+BY=H5C3=vhOrmej_hDWRheEAJyFnjd92kw@mail.gmail.com>
Message-ID: <20160224235838.GB5936@verge.net.au>

On Wed, Feb 24, 2016 at 08:37:09AM +0100, Geert Uytterhoeven wrote:
> On Wed, Feb 24, 2016 at 3:29 AM, Simon Horman
> <horms+renesas at verge.net.au> wrote:
> > Use recently added fallback compatibility string in r8a7790 device trees.
> >
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>

Thanks, I have queued this up for v4.7.


From horms at verge.net.au  Wed Feb 24 15:58:51 2016
From: horms at verge.net.au (Simon Horman)
Date: Thu, 25 Feb 2016 08:58:51 +0900
Subject: [PATCH 2/2] ARM: dts: r8a7791: use fallback jpu compatibility
 string
In-Reply-To: <CAMuHMdX3fKAyqO=_2g78PJPf0ebgQ9n3qp4uJdXKRX=Tub7V-Q@mail.gmail.com>
References: <1456280946-14859-1-git-send-email-horms+renesas@verge.net.au>
 <1456280946-14859-3-git-send-email-horms+renesas@verge.net.au>
 <CAMuHMdX3fKAyqO=_2g78PJPf0ebgQ9n3qp4uJdXKRX=Tub7V-Q@mail.gmail.com>
Message-ID: <20160224235850.GC5936@verge.net.au>

On Wed, Feb 24, 2016 at 08:37:47AM +0100, Geert Uytterhoeven wrote:
> On Wed, Feb 24, 2016 at 3:29 AM, Simon Horman
> <horms+renesas at verge.net.au> wrote:
> > Use recently added fallback compatibility string in r8a7791 device tree.
> >
> > Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
> 
> Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>

Thanks, I have queued this up for v4.7.


From horms at verge.net.au  Wed Feb 24 15:59:36 2016
From: horms at verge.net.au (Simon Horman)
Date: Thu, 25 Feb 2016 08:59:36 +0900
Subject: [GIT PULL] Renesas ARM Based SoC Fixes for v4.5
In-Reply-To: <CAOesGMhab6SX5o-1CXKt-FNOrg+Nk9w1ccR=Co1DVXrJUKN4cw@mail.gmail.com>
References: <cover.1455859965.git.horms+renesas@verge.net.au>
 <20160224080803.GD30231@localhost>
 <CAMuHMdWxXFf0MFKP27y6g7CUc1MeG0PuJ-FdoSkV+2gB5NvQTA@mail.gmail.com>
 <CAOesGMhab6SX5o-1CXKt-FNOrg+Nk9w1ccR=Co1DVXrJUKN4cw@mail.gmail.com>
Message-ID: <20160224235936.GD5936@verge.net.au>

On Wed, Feb 24, 2016 at 08:48:08AM -0800, Olof Johansson wrote:
> On Wed, Feb 24, 2016 at 12:37 AM, Geert Uytterhoeven
> <geert at linux-m68k.org> wrote:
> > Hi Olof,
> >
> > On Wed, Feb 24, 2016 at 9:08 AM, Olof Johansson <olof at lixom.net> wrote:
> >> On Fri, Feb 19, 2016 at 03:09:46PM +0900, Simon Horman wrote:
> >>> Please consider these Renesas ARM based SoC fixes for v4.5.
> >>>
> >>> This pull request is comprised of patches from Geert Uytterhoeven to avoid
> >>> writing to .text.
> >>>
> >>> * "ARM: shmobile: Move shmobile_scu_base from .text to .bss"
> >>>
> >>>   Resolves a problem for XIP kernels as writing to .text is not allowed.
> >>>   For non-XIP kernels a problem does not manifst as the pages are mapped
> >>>   read-only during late kernel startup.
> >>>
> >>> * The remaining patches resolve a kernel-crash that occurs during system
> >>>   suspend for CONFIG_DEBUG_RODATA=y kernels.
> >>>
> >>>
> >>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> >>>
> >>>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> >>>
> >>> are available in the git repository at:
> >>>
> >>>   git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc-fixes-for-v4.5
> >>>
> >>> for you to fetch changes up to 901c5ffaaed117a38be9d0c29247c4888d6c8636:
> >>>
> >>>   ARM: shmobile: Remove shmobile_boot_arg (2016-02-17 18:27:21 +0900)
> >>
> >> Hi Simon, Geert,
> >>
> >> I don't think any of these fixes are for regressions, are they? I.e. this is
> >> work to enable configs that never used to work (XIP, CONFIG_DEBUG_RODATA)?
> >
> > These configs indeed never worked before.
> >
> > However,
> >
> > commit 25362dc496edaf17f714c0fecd8b3eb79670207b
> > Author: Kees Cook <keescook at chromium.org>
> > Date:   Tue Jan 26 01:19:36 2016 +0100
> >
> >     ARM: 8501/1: mm: flip priority of CONFIG_DEBUG_RODATA
> >
> > in arm/for-next will enable CONFIG_DEBUG_RODATA by default.
> >
> > Not having the fixes in v4.5 means that if Russell's tree is merged
> > into mainline
> > for v4.6 before arm-soc, it will cause regressions and bisection issues.
> 
> Ok, either way there'll be windows in which bisect will fail since the
> changes are on independent branches.
> 
> Based on that, and looking at the patches, I'll pick it up now for fixes.

Thanks Olof, much appreciated.


From ddaney.cavm at gmail.com  Wed Feb 24 16:02:06 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Wed, 24 Feb 2016 16:02:06 -0800
Subject: [PATCH 0/2] NUMA related header file cleanups.
Message-ID: <1456358528-24213-1-git-send-email-ddaney.cavm@gmail.com>

From: David Daney <david.daney at cavium.com>

Refactor many architectures' cpumask_of_pcibus and NODE_DATA definitions
by moving them to asm-generic.

Tested on arm64.

Build tested on ia64, m32r, powerpc, s390, sh, sparc(64), tile, x86

This patch set (arm64 portion) depends on this one:

https://lkml.org/lkml/2016/2/22/1066

Earler versions of these patches were part of the arm64 NUMA patch
set.  They have been split out here into a separate set.

Ganapatrao Kulkarni (2):
  topology, cleanup: Avoid redefinition of cpumask_of_pcibus in asm
    header files.
  numa, mm, cleanup: remove redundant NODE_DATA macro from asm header
    files.

 arch/arm64/include/asm/mmzone.h     |  4 +---
 arch/arm64/include/asm/topology.h   |  3 ---
 arch/ia64/include/asm/topology.h    |  4 ----
 arch/m32r/include/asm/mmzone.h      |  4 +---
 arch/metag/include/asm/mmzone.h     |  4 +---
 arch/metag/include/asm/topology.h   |  3 ---
 arch/powerpc/include/asm/mmzone.h   |  8 ++------
 arch/powerpc/include/asm/topology.h |  4 ----
 arch/s390/include/asm/mmzone.h      |  6 +-----
 arch/s390/include/asm/pci.h         |  2 +-
 arch/s390/include/asm/topology.h    |  1 +
 arch/sh/include/asm/mmzone.h        |  4 +---
 arch/sh/include/asm/topology.h      |  3 ---
 arch/sparc/include/asm/mmzone.h     |  6 ++----
 arch/tile/include/asm/pci.h         |  2 --
 arch/tile/include/asm/topology.h    |  3 +++
 arch/x86/include/asm/mmzone.h       |  3 +--
 arch/x86/include/asm/mmzone_32.h    |  5 -----
 arch/x86/include/asm/mmzone_64.h    | 17 -----------------
 arch/x86/include/asm/pci.h          |  2 +-
 arch/x86/include/asm/topology.h     |  1 +
 include/asm-generic/mmzone.h        | 24 ++++++++++++++++++++++++
 include/asm-generic/topology.h      |  4 ++--
 23 files changed, 43 insertions(+), 74 deletions(-)
 delete mode 100644 arch/x86/include/asm/mmzone_64.h
 create mode 100644 include/asm-generic/mmzone.h

-- 
1.8.3.1



From ddaney.cavm at gmail.com  Wed Feb 24 16:02:07 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Wed, 24 Feb 2016 16:02:07 -0800
Subject: [PATCH 1/2] topology,
 cleanup: Avoid redefinition of cpumask_of_pcibus in asm header files.
In-Reply-To: <1456358528-24213-1-git-send-email-ddaney.cavm@gmail.com>
References: <1456358528-24213-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1456358528-24213-2-git-send-email-ddaney.cavm@gmail.com>

From: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>

At present cpumask_of_pcibus is defined for !CONFIG_NUMA and moving out
to common will allow to use for numa too. This also avoids
redefinition of this macro in respective architecture header files.

Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 arch/arm64/include/asm/topology.h   | 3 ---
 arch/ia64/include/asm/topology.h    | 4 ----
 arch/metag/include/asm/topology.h   | 3 ---
 arch/powerpc/include/asm/topology.h | 4 ----
 arch/s390/include/asm/pci.h         | 2 +-
 arch/s390/include/asm/topology.h    | 1 +
 arch/sh/include/asm/topology.h      | 3 ---
 arch/tile/include/asm/pci.h         | 2 --
 arch/tile/include/asm/topology.h    | 3 +++
 arch/x86/include/asm/pci.h          | 2 +-
 arch/x86/include/asm/topology.h     | 1 +
 include/asm-generic/topology.h      | 4 ++--
 12 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index 8b57339..6e1f62c 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -26,9 +26,6 @@ const struct cpumask *cpu_coregroup_mask(int cpu);
 
 struct pci_bus;
 int pcibus_to_node(struct pci_bus *bus);
-#define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ?		\
-				 cpu_all_mask :				\
-				 cpumask_of_node(pcibus_to_node(bus)))
 
 #endif /* CONFIG_NUMA */
 
diff --git a/arch/ia64/include/asm/topology.h b/arch/ia64/include/asm/topology.h
index 3ad8f69..2778eb6 100644
--- a/arch/ia64/include/asm/topology.h
+++ b/arch/ia64/include/asm/topology.h
@@ -58,10 +58,6 @@ void build_cpu_to_node_map(void);
 
 extern void arch_fix_phys_package_id(int num, u32 slot);
 
-#define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ?		\
-				 cpu_all_mask :				\
-				 cpumask_of_node(pcibus_to_node(bus)))
-
 #include <asm-generic/topology.h>
 
 #endif /* _ASM_IA64_TOPOLOGY_H */
diff --git a/arch/metag/include/asm/topology.h b/arch/metag/include/asm/topology.h
index e95f874..b285196 100644
--- a/arch/metag/include/asm/topology.h
+++ b/arch/metag/include/asm/topology.h
@@ -9,9 +9,6 @@
 #define cpumask_of_node(node)	((void)node, cpu_online_mask)
 
 #define pcibus_to_node(bus)	((void)(bus), -1)
-#define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ? \
-					cpu_all_mask : \
-					cpumask_of_node(pcibus_to_node(bus)))
 
 #endif
 
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index 8b3b46b..eee025d 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -32,10 +32,6 @@ static inline int pcibus_to_node(struct pci_bus *bus)
 }
 #endif
 
-#define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ?		\
-				 cpu_all_mask :				\
-				 cpumask_of_node(pcibus_to_node(bus)))
-
 extern int __node_distance(int, int);
 #define node_distance(a, b) __node_distance(a, b)
 
diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
index c873e68..539fb2d 100644
--- a/arch/s390/include/asm/pci.h
+++ b/arch/s390/include/asm/pci.h
@@ -205,7 +205,7 @@ static inline int __pcibus_to_node(const struct pci_bus *bus)
 }
 
 static inline const struct cpumask *
-cpumask_of_pcibus(const struct pci_bus *bus)
+__cpumask_of_pcibus(const struct pci_bus *bus)
 {
 	return cpu_online_mask;
 }
diff --git a/arch/s390/include/asm/topology.h b/arch/s390/include/asm/topology.h
index 6b53962..ac2f88f 100644
--- a/arch/s390/include/asm/topology.h
+++ b/arch/s390/include/asm/topology.h
@@ -78,6 +78,7 @@ static inline const struct cpumask *cpumask_of_node(int node)
 #define parent_node(node) (node)
 
 #define pcibus_to_node(bus) __pcibus_to_node(bus)
+#define cpumask_of_pcibus(bus) __cpumask_of_pcibus(bus)
 
 #define node_distance(a, b) __node_distance(a, b)
 
diff --git a/arch/sh/include/asm/topology.h b/arch/sh/include/asm/topology.h
index b0a282d..357983d 100644
--- a/arch/sh/include/asm/topology.h
+++ b/arch/sh/include/asm/topology.h
@@ -9,9 +9,6 @@
 #define cpumask_of_node(node)	((void)node, cpu_online_mask)
 
 #define pcibus_to_node(bus)	((void)(bus), -1)
-#define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ? \
-					cpu_all_mask : \
-					cpumask_of_node(pcibus_to_node(bus)))
 
 #endif
 
diff --git a/arch/tile/include/asm/pci.h b/arch/tile/include/asm/pci.h
index dfedd7a..473ed46 100644
--- a/arch/tile/include/asm/pci.h
+++ b/arch/tile/include/asm/pci.h
@@ -223,8 +223,6 @@ static inline int pcibios_assign_all_busses(void)
 /* Minimum PCI I/O address, starting at the page boundary. */
 #define PCIBIOS_MIN_IO		PAGE_SIZE
 
-/* Use any cpu for PCI. */
-#define cpumask_of_pcibus(bus) cpu_online_mask
 
 /* implement the pci_ DMA API in terms of the generic device dma_ one */
 #include <asm-generic/pci-dma-compat.h>
diff --git a/arch/tile/include/asm/topology.h b/arch/tile/include/asm/topology.h
index b11d5fc..9770b86 100644
--- a/arch/tile/include/asm/topology.h
+++ b/arch/tile/include/asm/topology.h
@@ -46,6 +46,9 @@ static inline const struct cpumask *cpumask_of_node(int node)
 
 #endif /* CONFIG_NUMA */
 
+/* Use any cpu for PCI. */
+#define cpumask_of_pcibus(bus) cpu_online_mask
+
 #include <asm-generic/topology.h>
 
 #ifdef CONFIG_SMP
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 4625943..4a6f358 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -121,7 +121,7 @@ static inline int __pcibus_to_node(const struct pci_bus *bus)
 }
 
 static inline const struct cpumask *
-cpumask_of_pcibus(const struct pci_bus *bus)
+__cpumask_of_pcibus(const struct pci_bus *bus)
 {
 	int node;
 
diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h
index 0fb4648..980f6ee 100644
--- a/arch/x86/include/asm/topology.h
+++ b/arch/x86/include/asm/topology.h
@@ -91,6 +91,7 @@ extern void setup_node_to_cpumask_map(void);
 #define parent_node(node) (node)
 
 #define pcibus_to_node(bus) __pcibus_to_node(bus)
+#define cpumask_of_pcibus(bus) __cpumask_of_pcibus(bus)
 
 extern int __node_distance(int, int);
 #define node_distance(a, b) __node_distance(a, b)
diff --git a/include/asm-generic/topology.h b/include/asm-generic/topology.h
index fc824e2..ee305f1 100644
--- a/include/asm-generic/topology.h
+++ b/include/asm-generic/topology.h
@@ -54,14 +54,14 @@
 #define pcibus_to_node(bus)	((void)(bus), -1)
 #endif
 
+#endif	/* !CONFIG_NUMA */
+
 #ifndef cpumask_of_pcibus
 #define cpumask_of_pcibus(bus)	(pcibus_to_node(bus) == -1 ?		\
 				 cpu_all_mask :				\
 				 cpumask_of_node(pcibus_to_node(bus)))
 #endif
 
-#endif	/* CONFIG_NUMA */
-
 #if !defined(CONFIG_NUMA) || !defined(CONFIG_HAVE_MEMORYLESS_NODES)
 
 #ifndef set_numa_mem
-- 
1.8.3.1



From ddaney.cavm at gmail.com  Wed Feb 24 16:02:08 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Wed, 24 Feb 2016 16:02:08 -0800
Subject: [PATCH 2/2] numa, mm,
 cleanup: remove redundant NODE_DATA macro from asm header files.
In-Reply-To: <1456358528-24213-1-git-send-email-ddaney.cavm@gmail.com>
References: <1456358528-24213-1-git-send-email-ddaney.cavm@gmail.com>
Message-ID: <1456358528-24213-3-git-send-email-ddaney.cavm@gmail.com>

From: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>

NODE_DATA is defined across multiple asm header files.
Moving generic definition to asm-generic/mmzone.h to
remove redundant definitions.

Reviewed-by: Robert Richter <rrichter at cavium.com>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
Signed-off-by: David Daney <david.daney at cavium.com>
---
 arch/arm64/include/asm/mmzone.h   |  4 +---
 arch/m32r/include/asm/mmzone.h    |  4 +---
 arch/metag/include/asm/mmzone.h   |  4 +---
 arch/powerpc/include/asm/mmzone.h |  8 ++------
 arch/s390/include/asm/mmzone.h    |  6 +-----
 arch/sh/include/asm/mmzone.h      |  4 +---
 arch/sparc/include/asm/mmzone.h   |  6 ++----
 arch/x86/include/asm/mmzone.h     |  3 +--
 arch/x86/include/asm/mmzone_32.h  |  5 -----
 arch/x86/include/asm/mmzone_64.h  | 17 -----------------
 include/asm-generic/mmzone.h      | 24 ++++++++++++++++++++++++
 11 files changed, 34 insertions(+), 51 deletions(-)
 delete mode 100644 arch/x86/include/asm/mmzone_64.h
 create mode 100644 include/asm-generic/mmzone.h

diff --git a/arch/arm64/include/asm/mmzone.h b/arch/arm64/include/asm/mmzone.h
index a0de9e6..611a1cf 100644
--- a/arch/arm64/include/asm/mmzone.h
+++ b/arch/arm64/include/asm/mmzone.h
@@ -4,9 +4,7 @@
 #ifdef CONFIG_NUMA
 
 #include <asm/numa.h>
-
-extern struct pglist_data *node_data[];
-#define NODE_DATA(nid)		(node_data[(nid)])
+#include  <asm-generic/mmzone.h>
 
 #endif /* CONFIG_NUMA */
 #endif /* __ASM_MMZONE_H */
diff --git a/arch/m32r/include/asm/mmzone.h b/arch/m32r/include/asm/mmzone.h
index 115ced3..e3d66a0 100644
--- a/arch/m32r/include/asm/mmzone.h
+++ b/arch/m32r/include/asm/mmzone.h
@@ -7,12 +7,10 @@
 #define _ASM_MMZONE_H_
 
 #include <asm/smp.h>
+#include  <asm-generic/mmzone.h>
 
 #ifdef CONFIG_DISCONTIGMEM
 
-extern struct pglist_data *node_data[];
-#define NODE_DATA(nid)		(node_data[nid])
-
 #define node_localnr(pfn, nid)	((pfn) - NODE_DATA(nid)->node_start_pfn)
 
 #define pmd_page(pmd)		(pfn_to_page(pmd_val(pmd) >> PAGE_SHIFT))
diff --git a/arch/metag/include/asm/mmzone.h b/arch/metag/include/asm/mmzone.h
index 9c88a9c..b1e95b3 100644
--- a/arch/metag/include/asm/mmzone.h
+++ b/arch/metag/include/asm/mmzone.h
@@ -3,9 +3,7 @@
 
 #ifdef CONFIG_NEED_MULTIPLE_NODES
 #include <linux/numa.h>
-
-extern struct pglist_data *node_data[];
-#define NODE_DATA(nid)		(node_data[nid])
+#include  <asm-generic/mmzone.h>
 
 static inline int pfn_to_nid(unsigned long pfn)
 {
diff --git a/arch/powerpc/include/asm/mmzone.h b/arch/powerpc/include/asm/mmzone.h
index 7b58917..da0c5ba 100644
--- a/arch/powerpc/include/asm/mmzone.h
+++ b/arch/powerpc/include/asm/mmzone.h
@@ -19,12 +19,6 @@
 
 #ifdef CONFIG_NEED_MULTIPLE_NODES
 
-extern struct pglist_data *node_data[];
-/*
- * Return a pointer to the node data for node n.
- */
-#define NODE_DATA(nid)		(node_data[nid])
-
 /*
  * Following are specific to this numa platform.
  */
@@ -42,5 +36,7 @@ u64 memory_hotplug_max(void);
 #define memory_hotplug_max() memblock_end_of_DRAM()
 #endif /* CONFIG_NEED_MULTIPLE_NODES */
 
+#include  <asm-generic/mmzone.h>
+
 #endif /* __KERNEL__ */
 #endif /* _ASM_MMZONE_H_ */
diff --git a/arch/s390/include/asm/mmzone.h b/arch/s390/include/asm/mmzone.h
index a9e834e..91f1fcc 100644
--- a/arch/s390/include/asm/mmzone.h
+++ b/arch/s390/include/asm/mmzone.h
@@ -7,10 +7,6 @@
 #ifndef _ASM_S390_MMZONE_H
 #define _ASM_S390_MMZONE_H
 
-#ifdef CONFIG_NUMA
+#include  <asm-generic/mmzone.h>
 
-extern struct pglist_data *node_data[];
-#define NODE_DATA(nid) (node_data[nid])
-
-#endif /* CONFIG_NUMA */
 #endif /* _ASM_S390_MMZONE_H */
diff --git a/arch/sh/include/asm/mmzone.h b/arch/sh/include/asm/mmzone.h
index 15a8496..c070d00 100644
--- a/arch/sh/include/asm/mmzone.h
+++ b/arch/sh/include/asm/mmzone.h
@@ -5,9 +5,7 @@
 
 #ifdef CONFIG_NEED_MULTIPLE_NODES
 #include <linux/numa.h>
-
-extern struct pglist_data *node_data[];
-#define NODE_DATA(nid)		(node_data[nid])
+#include  <asm-generic/mmzone.h>
 
 static inline int pfn_to_nid(unsigned long pfn)
 {
diff --git a/arch/sparc/include/asm/mmzone.h b/arch/sparc/include/asm/mmzone.h
index 99d9b9f..ef1365b 100644
--- a/arch/sparc/include/asm/mmzone.h
+++ b/arch/sparc/include/asm/mmzone.h
@@ -5,13 +5,11 @@
 
 #include <linux/cpumask.h>
 
-extern struct pglist_data *node_data[];
-
-#define NODE_DATA(nid)		(node_data[nid])
-
 extern int numa_cpu_lookup_table[];
 extern cpumask_t numa_cpumask_lookup_table[];
 
 #endif /* CONFIG_NEED_MULTIPLE_NODES */
 
+#include  <asm-generic/mmzone.h>
+
 #endif /* _SPARC64_MMZONE_H */
diff --git a/arch/x86/include/asm/mmzone.h b/arch/x86/include/asm/mmzone.h
index d497bc4..8b9a0c2 100644
--- a/arch/x86/include/asm/mmzone.h
+++ b/arch/x86/include/asm/mmzone.h
@@ -1,5 +1,4 @@
+#include  <asm-generic/mmzone.h>
 #ifdef CONFIG_X86_32
 # include <asm/mmzone_32.h>
-#else
-# include <asm/mmzone_64.h>
 #endif
diff --git a/arch/x86/include/asm/mmzone_32.h b/arch/x86/include/asm/mmzone_32.h
index 1ec990b..09f7cfb 100644
--- a/arch/x86/include/asm/mmzone_32.h
+++ b/arch/x86/include/asm/mmzone_32.h
@@ -8,11 +8,6 @@
 
 #include <asm/smp.h>
 
-#ifdef CONFIG_NUMA
-extern struct pglist_data *node_data[];
-#define NODE_DATA(nid)	(node_data[nid])
-#endif /* CONFIG_NUMA */
-
 #ifdef CONFIG_DISCONTIGMEM
 
 /*
diff --git a/arch/x86/include/asm/mmzone_64.h b/arch/x86/include/asm/mmzone_64.h
deleted file mode 100644
index 129d9aa..0000000
--- a/arch/x86/include/asm/mmzone_64.h
+++ /dev/null
@@ -1,17 +0,0 @@
-/* K8 NUMA support */
-/* Copyright 2002,2003 by Andi Kleen, SuSE Labs */
-/* 2.5 Version loosely based on the NUMAQ Code by Pat Gaughen. */
-#ifndef _ASM_X86_MMZONE_64_H
-#define _ASM_X86_MMZONE_64_H
-
-#ifdef CONFIG_NUMA
-
-#include <linux/mmdebug.h>
-#include <asm/smp.h>
-
-extern struct pglist_data *node_data[];
-
-#define NODE_DATA(nid)		(node_data[nid])
-
-#endif
-#endif /* _ASM_X86_MMZONE_64_H */
diff --git a/include/asm-generic/mmzone.h b/include/asm-generic/mmzone.h
new file mode 100644
index 0000000..ec0fc4c
--- /dev/null
+++ b/include/asm-generic/mmzone.h
@@ -0,0 +1,24 @@
+/*
+ * linux/include/asm-generic/mmzone.h
+ *
+ * Author: Ganapatrao Kulkarni <gkulkarni at cavium.com>
+ * Copyright (C) 2016 Cavium Inc.
+ *
+ * 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.
+ *
+ */
+
+#ifndef _ASM_GENERIC_MMZONE_H
+#define _ASM_GENERIC_MMZONE_H
+
+#if defined(CONFIG_NUMA) || defined(CONFIG_NEED_MULTIPLE_NODES)
+
+#ifndef NODE_DATA
+extern struct pglist_data *node_data[];
+#define NODE_DATA(nid)          (node_data[(nid)])
+#endif
+
+#endif
+#endif /* _ASM_GENERIC_MMZONE_H */
-- 
1.8.3.1



From k.kozlowski at samsung.com  Wed Feb 24 16:13:31 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Thu, 25 Feb 2016 09:13:31 +0900
Subject: [GIT PULL 2/7] ARM: dts: Exynos DT dependency for v4.6
In-Reply-To: <20160224222319.GU10126@localhost>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
 <1455496446-23779-3-git-send-email-k.kozlowski@samsung.com>
 <20160224222319.GU10126@localhost>
Message-ID: <56CE472B.5020201@samsung.com>

On 25.02.2016 07:23, Olof Johansson wrote:
> On Mon, Feb 15, 2016 at 09:34:01AM +0900, Krzysztof Kozlowski wrote:
>> Hi Arnd, Kevin and Olof,
>>
>> Early DT changes for v4.6, needed before removal of SROM support
>> from mach-exynos.
>>
>> Kind regards,
>> Krzysztof
>>
>>
>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>
>>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-srom-4.6
>>
>> for you to fetch changes up to d2deef6c61e65d1e0cee40c1d74fa99007da8c84:
>>
>>   ARM: dts: Add SROM to exynos5410 (2016-01-25 10:32:07 +0900)
>>
>> ----------------------------------------------------------------
>> Device Tree changes for v4.6 adding the nodes for Exynos SROM controller
>> driver. The driver saves and restores SROM registers during suspend to RAM.
>> DT changes should go in before removal of SROM support from mach-exynos.
>>
>> ----------------------------------------------------------------
>> Pankaj Dubey (2):
>>       ARM: dts: Add SROM device node for exynos4
>>       ARM: dts: Add SROM device node for exynos5
>>
>> Pavel Fedin (1):
>>       ARM: dts: Add SROM to exynos5410
> 
> Hi,
> 
> Please use the format:
> 
> ARM: dts: exynos: ...
> 
> in the future.

Sure! I was using it before... but switched to Kukjin's format.

Thanks for merging,
Krzysztof



From olof at lixom.net  Wed Feb 24 16:05:08 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 16:05:08 -0800
Subject: [GIT PULL] Versatile family DT cleanups step 1
In-Reply-To: <CACRpkdYR-_41Ay7b_X4hJkPY7dUR2qAsfsjn-MzpahVWqEiVPQ@mail.gmail.com>
References: <CACRpkdYR-_41Ay7b_X4hJkPY7dUR2qAsfsjn-MzpahVWqEiVPQ@mail.gmail.com>
Message-ID: <20160225000508.GZ10126@localhost>

On Mon, Feb 15, 2016 at 10:07:38AM +0100, Linus Walleij wrote:
> Hi ARM SoC folks,
> 
> this is a first pull request for my cleanups for the Versatile, as the
> finished stuff should not be sitting in my tree but in ARM SoC.
> This completes the ARM RealView PB1176 and PB11MPCore
> device trees, and moves the Versatile to use power/reset.
> 
> The idea is to keep working on this cleanup branch and send
> additional patches on top of this one as the prerequisites are
> merged into the MTD and FBDEV subsystems. So please create
> a special versatile cleanup branch (or suggest another approach).
> 
> As it happens, board files and device trees need to change at the
> same time to make logical sense, especially for Versatile where
> auxdata is replaced with DT entries, such as when reset is moved
> in the last patch in this set. The MTD and CLCD changes will share
> this characteristic.
> 
> Please pull it in!
> 
> Yours,
> Linus Walleij
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git
> tags/versatile-dt-cleanup-1
> 
> for you to fetch changes up to 1c6e288da6cc3c72579ff0062b5a5684fb9ef90e:
> 
>   ARM: versatile: move restart to the device tree (2016-02-15 09:58:08 +0100)

THanks. I've merged this into next/dt, seemed as good as any. Only think
I'm asking is to not modify these board files in another branch so we
can avoid conflicts -- but incremental stuff on top is just fine.


-Olof



From olof at lixom.net  Wed Feb 24 16:07:25 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 16:07:25 -0800
Subject: [GIT PULL] firmware: SCPI driver updates for v4.6
In-Reply-To: <56C33625.5030903@arm.com>
References: <56C33625.5030903@arm.com>
Message-ID: <20160225000725.GB10126@localhost>

On Tue, Feb 16, 2016 at 02:45:57PM +0000, Sudeep Holla wrote:
> Hi ARM-SoC team,
> 
> Here is the set of minor updates to SCPI firmware driver for v4.6
> There's a change in HWMON driver which Guenter Roeck has Acked and
> agreed to take it via arm-soc tree.
> 
> -- 
> Regards,
> Sudeep
> 
> -->8
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git
> tags/scpi-for-v4.6/updates
> 
> for you to fetch changes up to fb3b07ef399bd6984f3361a709829618b75e98d8:
> 
>   hwmon: (scpi) add energy meter support (2016-02-16 09:26:27 +0000)

Merged into next/drivers.


Thanks


-Olof


From olof at lixom.net  Wed Feb 24 16:06:28 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 16:06:28 -0800
Subject: [GIT PULL] plat-versatile clock.c and generic clkdev.h
In-Reply-To: <CACRpkdbJPPR8jADF1p++w60jZre3tpCAECsaqkzAk4-Y4+N-SA@mail.gmail.com>
References: <CACRpkdbJPPR8jADF1p++w60jZre3tpCAECsaqkzAk4-Y4+N-SA@mail.gmail.com>
Message-ID: <20160225000628.GA10126@localhost>

On Mon, Feb 15, 2016 at 10:15:33AM +0100, Linus Walleij wrote:
> Hi ARM SoC folks,
> 
> these are Stephen Boyds changes to remove a stale clock implementation
> and move to the generic clkdev.h that I queued at Arnd's request, it turns
> out I will not have any busines changing stuff in arch/arm/plat-versatile
> for this merge window (however a few changes around mach-*) so
> this can be pulled in separately.
> 
> Please pull this in!
> 
> Yours,
> Linus Walleij
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git
> tags/plat-versatile-cleanup
> 
> for you to fetch changes up to 34d2f4d3a4d6a6b204ebfd12d1d2c159360d41a4:
> 
>   ARM: Use generic clkdev.h header (2016-02-10 09:22:35 +0100)

Merged into next/cleanup. Thanks!


-Olof


From olof at lixom.net  Wed Feb 24 16:26:41 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 16:26:41 -0800
Subject: [PATCH 2/9] ARM: dts: uniphier: rework UniPhier System Bus nodes
In-Reply-To: <1455588911-9827-3-git-send-email-yamada.masahiro@socionext.com>
References: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
 <1455588911-9827-3-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <20160225002641.GC10126@localhost>

Hi,

On Tue, Feb 16, 2016 at 11:15:04AM +0900, Masahiro Yamada wrote:

> diff --git a/arch/arm/mach-uniphier/platsmp.c b/arch/arm/mach-uniphier/platsmp.c
> index e1cfc1d..b53a8d9 100644
> --- a/arch/arm/mach-uniphier/platsmp.c
> +++ b/arch/arm/mach-uniphier/platsmp.c
> @@ -30,7 +30,7 @@
>   * The secondary CPUs check this register from the boot ROM for the jump
>   * destination.  After that, it can be reused as a scratch register.
>   */
> -#define UNIPHIER_SBC_ROM_BOOT_RSV2	0x1208
> +#define UNIPHIER_SMPCTRL_ROM_BOOT_RSV2	0x208
>  
>  static void __iomem *uniphier_smp_rom_boot_rsv2;
>  static unsigned int uniphier_smp_max_cpus;
> @@ -98,15 +98,14 @@ static int __init uniphier_smp_prepare_trampoline(unsigned int max_cpus)
>  	phys_addr_t rom_rsv2_phys;
>  	int ret;
>  
> -	np = of_find_compatible_node(NULL, NULL,
> -				"socionext,uniphier-system-bus-controller");
> -	ret = of_address_to_resource(np, 1, &res);
> +	np = of_find_compatible_node(NULL, NULL, "socionext,uniphier-smpctrl");
> +	ret = of_address_to_resource(np, 0, &res);
>  	if (ret) {
> -		pr_err("failed to get resource of system-bus-controller\n");
> +		pr_err("failed to get resource of uniphier-smpctrl\n");
>  		return ret;
>  	}
>  
> -	rom_rsv2_phys = res.start + UNIPHIER_SBC_ROM_BOOT_RSV2;
> +	rom_rsv2_phys = res.start + UNIPHIER_SMPCTRL_ROM_BOOT_RSV2;
>  
>  	ret = uniphier_smp_copy_trampoline(rom_rsv2_phys);
>  	if (ret)

The previous binding has already been released. You can update, but your driver
should be able to handle the previous binding.

So, you still need to keep the old code around.

This has the benefit of breaking the dependency between the code change and the
DT change, so you no longer have to change your platform code at the same time
as the DT to avoid regressions.


Please adjust and resend. I'll hold off applying the series until then, so we
don't have a partially applied series.


Thanks!

-Olof


From olof at lixom.net  Wed Feb 24 16:29:08 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 16:29:08 -0800
Subject: [PATCH v3 2/6] arm: dts: add Artpec-6 SoC dtsi file
In-Reply-To: <9d3b8e80eeb56ca0808aae62eabd82af23ddb5c5.1455205057.git.larper@axis.com>
References: <cover.1455205057.git.larper@axis.com>
 <9d3b8e80eeb56ca0808aae62eabd82af23ddb5c5.1455205057.git.larper@axis.com>
Message-ID: <20160225002908.GD10126@localhost>

On Thu, Feb 11, 2016 at 05:06:17PM +0100, Lars Persson wrote:
> Initial device tree for the Artpec-6 SoC.
> 
> Signed-off-by: Lars Persson <larper at axis.com>
> ---
>  arch/arm/boot/dts/artpec6.dtsi | 236 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 236 insertions(+)
>  create mode 100644 arch/arm/boot/dts/artpec6.dtsi
> 
> diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/arm/boot/dts/artpec6.dtsi
> new file mode 100644
> index 0000000..f2a7e4a
> --- /dev/null
> +++ b/arch/arm/boot/dts/artpec6.dtsi
> @@ -0,0 +1,236 @@
> +/*
> + * Device Tree Source for the Axis ARTPEC-6 SoC
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2.  This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */

I just realized these are GPL-only. We try to get most DTS/DTSI files dual
licensed now so that they can be separated from the linux kernel and used in
other projects. You can see the boilerplate used by other platforms in the same
directory.

I'd appreciate a patch that changed the licensing (it can be done on top of
this, since I already applied the patches we might as well keep them and fix
incrementally).

(Let me know if your corporate lawyers are giving you a hard time over this,
I'd be happy to talk to them to explain if needed).


-Olof



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:43 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:43 -0700
Subject: [PATCH net-next V2 00/16] net: fec: cleanup and fixes
Message-ID: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>

V2 is a rebase on top of johannes endian-safe patch and
this set is only the next 16 patches.
The testing for this series was done on a nitrogen6x.
The base commit was
commit f5461c27631672b9e95282812ee521c53f502eca
    Merge branch 'dsa-pass-bridge-to-drivers'

Testing showed no change in performance.
Testing used imx_v6_v7_defconfig + CONFIG_MICREL_PHY.
The processor was running at 996Mhz.
The following commands were used to get the transfer rates.

On an x86 ubunto system,
iperf -s -i.5 -u


On a nitrogen6x board, running via SD Card.
I first stopped some background processes

stop cron
stop upstart-file-bridge
stop upstart-socket-bridge
stop upstart-udev-bridge
stop rsyslog
stop dbus
killall dhclient
echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

taskset 0x2 iperf -c 192.168.0.201 -u -t60 -b500M -r

There is a branch available on github with this series, and the rest of
my fec patches, for those who would like to test it.
https://github.com:boundarydevices/linux-imx6.git branch net-next_master



Troy Kisky (16):
SDCard
 TX/RX
379/402	Before any patches
376/402  net: fec: only check queue 0 if RXF_0/TXF_0 interrupt is set
379/399  net: fec: pass rxq to fec_enet_rx_queue instead of queue_id
379/401  net: fec: pass txq to fec_enet_tx_queue instead of queue_id
389/409  net: fec: reduce interrupts
393/411  net: fec: split off napi routine with 3 queues
386/415  net: fec: don't clear all rx queue bits when just one is being checked
387/412  net: fec: set cbd_sc without relying on previous value
385/415  net: fec: eliminate calls to fec_enet_get_prevdesc
389/414  net: fec: move restart test for efficiency
386/412  net: fec: clear cbd_sc after transmission to help with debugging
387/415  net: fec: dump all tx queues in fec_dump
380/418  net: fec: detect tx int lost
385/417  net: fec: print more debug info in fec_timeout
388/417  net: fec: create subroutine reset_tx_queue
389/418  net: fec: call dma_unmap_single on mapped tx buffers at restart
381/414  net: fec: don't set cbd_bufaddr unless no mapping error

 drivers/net/ethernet/freescale/fec.h      |   7 +-
 drivers/net/ethernet/freescale/fec_main.c | 420 ++++++++++++++++--------------
 2 files changed, 224 insertions(+), 203 deletions(-)

-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:44 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:44 -0700
Subject: [PATCH net-next V2 01/16] net: fec: only check queue 0 if RXF_0/TXF_0
 interrupt is set
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-2-git-send-email-troy.kisky@boundarydevices.com>

Before queue 0 was always checked if any queue caused an interrupt.
It is better to just mark queue 0 if queue 0 has caused an interrupt.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index bad0ba2..dbac975 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1534,14 +1534,14 @@ fec_enet_collect_events(struct fec_enet_private *fep, uint int_events)
 	if (int_events == 0)
 		return false;
 
-	if (int_events & FEC_ENET_RXF)
+	if (int_events & FEC_ENET_RXF_0)
 		fep->work_rx |= (1 << 2);
 	if (int_events & FEC_ENET_RXF_1)
 		fep->work_rx |= (1 << 0);
 	if (int_events & FEC_ENET_RXF_2)
 		fep->work_rx |= (1 << 1);
 
-	if (int_events & FEC_ENET_TXF)
+	if (int_events & FEC_ENET_TXF_0)
 		fep->work_tx |= (1 << 2);
 	if (int_events & FEC_ENET_TXF_1)
 		fep->work_tx |= (1 << 0);
-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:45 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:45 -0700
Subject: [PATCH net-next V2 02/16] net: fec: pass rxq to fec_enet_rx_queue
 instead of queue_id
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-3-git-send-email-troy.kisky@boundarydevices.com>

The queue_id is the qid member of struct bufdesc_prop.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index dbac975..9619b9e 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1328,11 +1328,9 @@ static bool fec_enet_copybreak(struct net_device *ndev, struct sk_buff **skb,
  * not been given to the system, we just set the empty indicator,
  * effectively tossing the packet.
  */
-static int
-fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
+static int fec_rxq(struct net_device *ndev, struct fec_enet_private *fep,
+		   struct fec_enet_priv_rx_q *rxq, int budget)
 {
-	struct fec_enet_private *fep = netdev_priv(ndev);
-	struct fec_enet_priv_rx_q *rxq;
 	struct bufdesc *bdp;
 	unsigned short status;
 	struct  sk_buff *skb_new = NULL;
@@ -1350,8 +1348,6 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
 #ifdef CONFIG_M532x
 	flush_cache_all();
 #endif
-	queue_id = FEC_ENET_GET_QUQUE(queue_id);
-	rxq = fep->rx_queue[queue_id];
 
 	/* First, grab all of the stats for the incoming packet.
 	 * These get messed up if we get called due to a busy condition.
@@ -1519,11 +1515,12 @@ fec_enet_rx(struct net_device *ndev, int budget)
 	int     pkt_received = 0;
 	u16	queue_id;
 	struct fec_enet_private *fep = netdev_priv(ndev);
+	struct fec_enet_priv_rx_q *rxq;
 
 	for_each_set_bit(queue_id, &fep->work_rx, FEC_ENET_MAX_RX_QS) {
 		clear_bit(queue_id, &fep->work_rx);
-		pkt_received += fec_enet_rx_queue(ndev,
-					budget - pkt_received, queue_id);
+		rxq = fep->rx_queue[FEC_ENET_GET_QUQUE(queue_id)];
+		pkt_received += fec_rxq(ndev, fep, rxq, budget - pkt_received);
 	}
 	return pkt_received;
 }
-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:46 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:46 -0700
Subject: [PATCH net-next V2 03/16] net: fec: pass txq to fec_enet_tx_queue
 instead of queue_id
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-4-git-send-email-troy.kisky@boundarydevices.com>

queue_id is the qid member of struct bufdesc_prop.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 9619b9e..c517194 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1156,25 +1156,18 @@ fec_enet_hwtstamp(struct fec_enet_private *fep, unsigned ts,
 	hwtstamps->hwtstamp = ns_to_ktime(ns);
 }
 
-static void
-fec_enet_tx_queue(struct net_device *ndev, u16 queue_id)
+static void fec_txq(struct net_device *ndev, struct fec_enet_private *fep,
+		    struct fec_enet_priv_tx_q *txq)
 {
-	struct	fec_enet_private *fep;
 	struct bufdesc *bdp;
 	unsigned short status;
 	struct	sk_buff	*skb;
-	struct fec_enet_priv_tx_q *txq;
 	struct netdev_queue *nq;
 	int	index = 0;
 	int	entries_free;
 
-	fep = netdev_priv(ndev);
-
-	queue_id = FEC_ENET_GET_QUQUE(queue_id);
-
-	txq = fep->tx_queue[queue_id];
 	/* get next bdp of dirty_tx */
-	nq = netdev_get_tx_queue(ndev, queue_id);
+	nq = netdev_get_tx_queue(ndev, txq->bd.qid);
 	bdp = txq->dirty_tx;
 
 	/* get next bdp of dirty_tx */
@@ -1268,11 +1261,13 @@ static void
 fec_enet_tx(struct net_device *ndev)
 {
 	struct fec_enet_private *fep = netdev_priv(ndev);
+	struct fec_enet_priv_tx_q *txq;
 	u16 queue_id;
 	/* First process class A queue, then Class B and Best Effort queue */
 	for_each_set_bit(queue_id, &fep->work_tx, FEC_ENET_MAX_TX_QS) {
 		clear_bit(queue_id, &fep->work_tx);
-		fec_enet_tx_queue(ndev, queue_id);
+		txq = fep->tx_queue[FEC_ENET_GET_QUQUE(queue_id)];
+		fec_txq(ndev, fep, txq);
 	}
 	return;
 }
-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:47 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:47 -0700
Subject: [PATCH net-next V2 04/16] net: fec: reduce interrupts
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-5-git-send-email-troy.kisky@boundarydevices.com>

By clearing the NAPI interrupts in the NAPI routine
and not in the interrupt handler, we can reduce the
number of interrupts. We also don't need any status
variables as the registers are still valid.

Also, notice that if budget pkts are received, the
next call to fec_enet_rx_napi will now continue to
receive the previously pending packets.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec.h      |   6 +-
 drivers/net/ethernet/freescale/fec_main.c | 127 ++++++++++++------------------
 2 files changed, 50 insertions(+), 83 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 195122e..001200b 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -505,11 +505,7 @@ struct fec_enet_private {
 
 	unsigned int total_tx_ring_size;
 	unsigned int total_rx_ring_size;
-
-	unsigned long work_tx;
-	unsigned long work_rx;
-	unsigned long work_ts;
-	unsigned long work_mdio;
+	uint	events;
 
 	struct	platform_device *pdev;
 
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index c517194..4a218b9 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -70,8 +70,6 @@ static void fec_enet_itr_coal_init(struct net_device *ndev);
 
 #define DRIVER_NAME	"fec"
 
-#define FEC_ENET_GET_QUQUE(_x) ((_x == 0) ? 1 : ((_x == 1) ? 2 : 0))
-
 /* Pause frame feild and FIFO threshold */
 #define FEC_ENET_FCE	(1 << 5)
 #define FEC_ENET_RSEM_V	0x84
@@ -1257,21 +1255,6 @@ static void fec_txq(struct net_device *ndev, struct fec_enet_private *fep,
 		writel(0, txq->bd.reg_desc_active);
 }
 
-static void
-fec_enet_tx(struct net_device *ndev)
-{
-	struct fec_enet_private *fep = netdev_priv(ndev);
-	struct fec_enet_priv_tx_q *txq;
-	u16 queue_id;
-	/* First process class A queue, then Class B and Best Effort queue */
-	for_each_set_bit(queue_id, &fep->work_tx, FEC_ENET_MAX_TX_QS) {
-		clear_bit(queue_id, &fep->work_tx);
-		txq = fep->tx_queue[FEC_ENET_GET_QUQUE(queue_id)];
-		fec_txq(ndev, fep, txq);
-	}
-	return;
-}
-
 static int
 fec_enet_new_rxbdp(struct net_device *ndev, struct bufdesc *bdp, struct sk_buff *skb)
 {
@@ -1504,92 +1487,80 @@ rx_processing_done:
 	return pkt_received;
 }
 
-static int
-fec_enet_rx(struct net_device *ndev, int budget)
-{
-	int     pkt_received = 0;
-	u16	queue_id;
-	struct fec_enet_private *fep = netdev_priv(ndev);
-	struct fec_enet_priv_rx_q *rxq;
-
-	for_each_set_bit(queue_id, &fep->work_rx, FEC_ENET_MAX_RX_QS) {
-		clear_bit(queue_id, &fep->work_rx);
-		rxq = fep->rx_queue[FEC_ENET_GET_QUQUE(queue_id)];
-		pkt_received += fec_rxq(ndev, fep, rxq, budget - pkt_received);
-	}
-	return pkt_received;
-}
-
-static bool
-fec_enet_collect_events(struct fec_enet_private *fep, uint int_events)
-{
-	if (int_events == 0)
-		return false;
-
-	if (int_events & FEC_ENET_RXF_0)
-		fep->work_rx |= (1 << 2);
-	if (int_events & FEC_ENET_RXF_1)
-		fep->work_rx |= (1 << 0);
-	if (int_events & FEC_ENET_RXF_2)
-		fep->work_rx |= (1 << 1);
-
-	if (int_events & FEC_ENET_TXF_0)
-		fep->work_tx |= (1 << 2);
-	if (int_events & FEC_ENET_TXF_1)
-		fep->work_tx |= (1 << 0);
-	if (int_events & FEC_ENET_TXF_2)
-		fep->work_tx |= (1 << 1);
-
-	return true;
-}
-
 static irqreturn_t
 fec_enet_interrupt(int irq, void *dev_id)
 {
 	struct net_device *ndev = dev_id;
 	struct fec_enet_private *fep = netdev_priv(ndev);
-	uint int_events;
-	irqreturn_t ret = IRQ_NONE;
+	uint eir = readl(fep->hwp + FEC_IEVENT);
+	uint int_events = eir & readl(fep->hwp + FEC_IMASK);
 
-	int_events = readl(fep->hwp + FEC_IEVENT);
-	writel(int_events, fep->hwp + FEC_IEVENT);
-	fec_enet_collect_events(fep, int_events);
-
-	if ((fep->work_tx || fep->work_rx) && fep->link) {
-		ret = IRQ_HANDLED;
+	if (!int_events)
+		return IRQ_NONE;
 
+	if (int_events & (FEC_ENET_RXF | FEC_ENET_TXF)) {
 		if (napi_schedule_prep(&fep->napi)) {
 			/* Disable the NAPI interrupts */
 			writel(FEC_NAPI_IMASK, fep->hwp + FEC_IMASK);
 			__napi_schedule(&fep->napi);
+			int_events &= ~(FEC_ENET_RXF | FEC_ENET_TXF);
+			if (!int_events)
+				return IRQ_HANDLED;
+		} else {
+			fep->events |= int_events;
+			pr_info("%s: couldn't schedule NAPI\n", __func__);
 		}
 	}
 
-	if (int_events & FEC_ENET_MII) {
-		ret = IRQ_HANDLED;
+	writel(int_events, fep->hwp + FEC_IEVENT);
+	if (int_events & FEC_ENET_MII)
 		complete(&fep->mdio_done);
-	}
 
-	if (fep->ptp_clock)
+	if ((int_events & FEC_ENET_TS_TIMER) && fep->ptp_clock)
 		fec_ptp_check_pps_event(fep);
-
-	return ret;
+	return IRQ_HANDLED;
 }
 
 static int fec_enet_rx_napi(struct napi_struct *napi, int budget)
 {
 	struct net_device *ndev = napi->dev;
 	struct fec_enet_private *fep = netdev_priv(ndev);
-	int pkts;
-
-	pkts = fec_enet_rx(ndev, budget);
+	int pkts = 0;
+	uint events;
 
-	fec_enet_tx(ndev);
+	do {
+		events = readl(fep->hwp + FEC_IEVENT);
+		if (fep->events) {
+			events |= fep->events;
+			fep->events = 0;
+		}
+		events &= FEC_ENET_RXF | FEC_ENET_TXF;
+		if (!events) {
+			if (budget) {
+				napi_complete(napi);
+				writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
+			}
+			return pkts;
+		}
 
-	if (pkts < budget) {
-		napi_complete(napi);
-		writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
-	}
+		writel(events, fep->hwp + FEC_IEVENT);
+		if (events & FEC_ENET_RXF_1)
+			pkts += fec_rxq(ndev, fep, fep->rx_queue[1],
+					budget - pkts);
+		if (events & FEC_ENET_RXF_2)
+			pkts += fec_rxq(ndev, fep, fep->rx_queue[2],
+					budget - pkts);
+		if (events & FEC_ENET_RXF_0)
+			pkts += fec_rxq(ndev, fep, fep->rx_queue[0],
+					budget - pkts);
+		if (events & FEC_ENET_TXF_1)
+			fec_txq(ndev, fep, fep->tx_queue[1]);
+		if (events & FEC_ENET_TXF_2)
+			fec_txq(ndev, fep, fep->tx_queue[2]);
+		if (events & FEC_ENET_TXF_0)
+			fec_txq(ndev, fep, fep->tx_queue[0]);
+	} while (pkts < budget);
+	fep->events |= events & FEC_ENET_RXF;	/* save for next callback */
 	return pkts;
 }
 
-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:48 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:48 -0700
Subject: [PATCH net-next V2 05/16] net: fec: split off napi routine with 3
 queues
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-6-git-send-email-troy.kisky@boundarydevices.com>

If we only have 1 tx/rx queue, we need not check
the other queues.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 39 +++++++++++++++++++++++++++++--
 1 file changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 4a218b9..610cf6c 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1521,7 +1521,7 @@ fec_enet_interrupt(int irq, void *dev_id)
 	return IRQ_HANDLED;
 }
 
-static int fec_enet_rx_napi(struct napi_struct *napi, int budget)
+static int fec_enet_napi_q3(struct napi_struct *napi, int budget)
 {
 	struct net_device *ndev = napi->dev;
 	struct fec_enet_private *fep = netdev_priv(ndev);
@@ -1564,6 +1564,39 @@ static int fec_enet_rx_napi(struct napi_struct *napi, int budget)
 	return pkts;
 }
 
+static int fec_enet_napi_q1(struct napi_struct *napi, int budget)
+{
+	struct net_device *ndev = napi->dev;
+	struct fec_enet_private *fep = netdev_priv(ndev);
+	int pkts = 0;
+	uint events;
+
+	do {
+		events = readl(fep->hwp + FEC_IEVENT);
+		if (fep->events) {
+			events |= fep->events;
+			fep->events = 0;
+		}
+		events &= FEC_ENET_RXF_0 | FEC_ENET_TXF_0;
+		if (!events) {
+			if (budget) {
+				napi_complete(napi);
+				writel(FEC_DEFAULT_IMASK, fep->hwp + FEC_IMASK);
+			}
+			return pkts;
+		}
+
+		writel(events, fep->hwp + FEC_IEVENT);
+		if (events & FEC_ENET_RXF_0)
+			pkts += fec_rxq(ndev, fep, fep->rx_queue[0],
+					budget - pkts);
+		if (events & FEC_ENET_TXF_0)
+			fec_txq(ndev, fep, fep->tx_queue[0]);
+	} while (pkts < budget);
+	fep->events |= FEC_ENET_RXF_0;	/* save for next callback */
+	return pkts;
+}
+
 /* ------------------------------------------------------------------------- */
 static void fec_get_mac(struct net_device *ndev)
 {
@@ -3123,7 +3156,9 @@ static int fec_enet_init(struct net_device *ndev)
 	ndev->ethtool_ops = &fec_enet_ethtool_ops;
 
 	writel(FEC_RX_DISABLED_IMASK, fep->hwp + FEC_IMASK);
-	netif_napi_add(ndev, &fep->napi, fec_enet_rx_napi, NAPI_POLL_WEIGHT);
+	netif_napi_add(ndev, &fep->napi, (fep->num_rx_queues |
+		       fep->num_tx_queues) == 1 ? fec_enet_napi_q1 :
+		       fec_enet_napi_q3, NAPI_POLL_WEIGHT);
 
 	if (fep->quirks & FEC_QUIRK_HAS_VLAN)
 		/* enable hw VLAN support */
-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:49 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:49 -0700
Subject: [PATCH net-next V2 06/16] net: fec: don't clear all rx queue bits
 when just one is being checked
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-7-git-send-email-troy.kisky@boundarydevices.com>

FEC_ENET_RXF is 3 separate bits, we only check one queue
at a time. So, when the last queue is being checked, it is
bad to remove the interrupt on the 1st queue.

Also, since this is now done in the napi
routine and not the interrupt, it is not needed.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 610cf6c..791f385 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1338,8 +1338,6 @@ static int fec_rxq(struct net_device *ndev, struct fec_enet_private *fep,
 			break;
 		pkt_received++;
 
-		writel(FEC_ENET_RXF, fep->hwp + FEC_IEVENT);
-
 		/* Check for errors. */
 		status ^= BD_ENET_RX_LAST;
 		if (status & (BD_ENET_RX_LG | BD_ENET_RX_SH | BD_ENET_RX_NO |
-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:50 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:50 -0700
Subject: [PATCH net-next V2 07/16] net: fec: set cbd_sc without relying on
 previous value
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-8-git-send-email-troy.kisky@boundarydevices.com>

Relying on the wrap bit to stay valid once initialized
when the controller also writes to this byte seems
undesirable since we can easily know what the value
should be.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 38 +++++++++----------------------
 1 file changed, 11 insertions(+), 27 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 791f385..6ceb5f9 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -340,9 +340,8 @@ fec_enet_txq_submit_frag_skb(struct fec_enet_priv_tx_q *txq,
 		bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
 		ebdp = (struct bufdesc_ex *)bdp;
 
-		status = fec16_to_cpu(bdp->cbd_sc);
-		status &= ~BD_ENET_TX_STATS;
-		status |= (BD_ENET_TX_TC | BD_ENET_TX_READY);
+		status = BD_ENET_TX_TC | BD_ENET_TX_READY |
+				((bdp == txq->bd.last) ? BD_SC_WRAP : 0);
 		frag_len = skb_shinfo(skb)->frags[frag].size;
 
 		/* Handle the last BD specially */
@@ -436,8 +435,6 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 	/* Fill in a Tx ring entry */
 	bdp = txq->bd.cur;
 	last_bdp = bdp;
-	status = fec16_to_cpu(bdp->cbd_sc);
-	status &= ~BD_ENET_TX_STATS;
 
 	/* Set buffer length and buffer pointer */
 	bufaddr = skb->data;
@@ -462,6 +459,8 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 		return NETDEV_TX_OK;
 	}
 
+	status = BD_ENET_TX_TC | BD_ENET_TX_READY |
+			((bdp == txq->bd.last) ? BD_SC_WRAP : 0);
 	if (nr_frags) {
 		last_bdp = fec_enet_txq_submit_frag_skb(txq, skb, ndev);
 		if (IS_ERR(last_bdp)) {
@@ -512,7 +511,6 @@ static int fec_enet_txq_submit_skb(struct fec_enet_priv_tx_q *txq,
 	/* Send it on its way.  Tell FEC it's ready, interrupt when done,
 	 * it's the last BD of the frame, and to put the CRC on the end.
 	 */
-	status |= (BD_ENET_TX_READY | BD_ENET_TX_TC);
 	bdp->cbd_sc = cpu_to_fec16(status);
 
 	/* If this was the last BD in the ring, start at the beginning again. */
@@ -544,11 +542,6 @@ fec_enet_txq_put_data_tso(struct fec_enet_priv_tx_q *txq, struct sk_buff *skb,
 	unsigned int estatus = 0;
 	dma_addr_t addr;
 
-	status = fec16_to_cpu(bdp->cbd_sc);
-	status &= ~BD_ENET_TX_STATS;
-
-	status |= (BD_ENET_TX_TC | BD_ENET_TX_READY);
-
 	if (((unsigned long) data) & fep->tx_align ||
 		fep->quirks & FEC_QUIRK_SWAP_FRAME) {
 		memcpy(txq->tx_bounce[index], data, size);
@@ -578,15 +571,16 @@ fec_enet_txq_put_data_tso(struct fec_enet_priv_tx_q *txq, struct sk_buff *skb,
 		ebdp->cbd_esc = cpu_to_fec32(estatus);
 	}
 
+	status = BD_ENET_TX_TC | BD_ENET_TX_READY |
+			((bdp == txq->bd.last) ? BD_SC_WRAP : 0);
 	/* Handle the last BD specially */
 	if (last_tcp)
-		status |= (BD_ENET_TX_LAST | BD_ENET_TX_TC);
+		status |= BD_ENET_TX_LAST;
 	if (is_last) {
 		status |= BD_ENET_TX_INTR;
 		if (fep->bufdesc_ex)
 			ebdp->cbd_esc |= cpu_to_fec32(BD_ENET_TX_INT);
 	}
-
 	bdp->cbd_sc = cpu_to_fec16(status);
 
 	return 0;
@@ -602,13 +596,8 @@ fec_enet_txq_put_hdr_tso(struct fec_enet_priv_tx_q *txq,
 	struct bufdesc_ex *ebdp = container_of(bdp, struct bufdesc_ex, desc);
 	void *bufaddr;
 	unsigned long dmabuf;
-	unsigned short status;
 	unsigned int estatus = 0;
 
-	status = fec16_to_cpu(bdp->cbd_sc);
-	status &= ~BD_ENET_TX_STATS;
-	status |= (BD_ENET_TX_TC | BD_ENET_TX_READY);
-
 	bufaddr = txq->tso_hdrs + index * TSO_HEADER_SIZE;
 	dmabuf = txq->tso_hdrs_dma + index * TSO_HEADER_SIZE;
 	if (((unsigned long)bufaddr) & fep->tx_align ||
@@ -641,8 +630,8 @@ fec_enet_txq_put_hdr_tso(struct fec_enet_priv_tx_q *txq,
 		ebdp->cbd_esc = cpu_to_fec32(estatus);
 	}
 
-	bdp->cbd_sc = cpu_to_fec16(status);
-
+	bdp->cbd_sc = cpu_to_fec16(BD_ENET_TX_TC | BD_ENET_TX_READY |
+			((bdp == txq->bd.last) ? BD_SC_WRAP : 0));
 	return 0;
 }
 
@@ -1453,12 +1442,6 @@ static int fec_rxq(struct net_device *ndev, struct fec_enet_private *fep,
 		}
 
 rx_processing_done:
-		/* Clear the status flags for this buffer */
-		status &= ~BD_ENET_RX_STATS;
-
-		/* Mark the buffer empty */
-		status |= BD_ENET_RX_EMPTY;
-
 		if (fep->bufdesc_ex) {
 			struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp;
 
@@ -1470,7 +1453,8 @@ rx_processing_done:
 		 * performed before transferring ownership.
 		 */
 		wmb();
-		bdp->cbd_sc = cpu_to_fec16(status);
+		bdp->cbd_sc = cpu_to_fec16(BD_ENET_RX_EMPTY |
+				((bdp == rxq->bd.last) ? BD_SC_WRAP : 0));
 
 		/* Update BD pointer to next entry */
 		bdp = fec_enet_get_nextdesc(bdp, &rxq->bd);
-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:51 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:51 -0700
Subject: [PATCH net-next V2 08/16] net: fec: eliminate calls to
 fec_enet_get_prevdesc
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-9-git-send-email-troy.kisky@boundarydevices.com>

This shrinks the code a little.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 37 +++++++++----------------------
 1 file changed, 11 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 6ceb5f9..b5ed287 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -758,6 +758,7 @@ static void fec_enet_bd_init(struct net_device *dev)
 	struct bufdesc *bdp;
 	unsigned int i;
 	unsigned int q;
+	unsigned status;
 
 	for (q = 0; q < fep->num_rx_queues; q++) {
 		/* Initialize the receive buffer descriptors. */
@@ -765,19 +766,13 @@ static void fec_enet_bd_init(struct net_device *dev)
 		bdp = rxq->bd.base;
 
 		for (i = 0; i < rxq->bd.ring_size; i++) {
-
 			/* Initialize the BD for every fragment in the page. */
-			if (bdp->cbd_bufaddr)
-				bdp->cbd_sc = cpu_to_fec16(BD_ENET_RX_EMPTY);
-			else
-				bdp->cbd_sc = cpu_to_fec16(0);
+			status = bdp->cbd_bufaddr ? BD_ENET_RX_EMPTY : 0;
+			if (bdp == rxq->bd.last)
+				status |= BD_SC_WRAP;
+			bdp->cbd_sc = cpu_to_fec16(status);
 			bdp = fec_enet_get_nextdesc(bdp, &rxq->bd);
 		}
-
-		/* Set the last buffer to wrap */
-		bdp = fec_enet_get_prevdesc(bdp, &rxq->bd);
-		bdp->cbd_sc |= cpu_to_fec16(BD_SC_WRAP);
-
 		rxq->bd.cur = rxq->bd.base;
 	}
 
@@ -789,18 +784,16 @@ static void fec_enet_bd_init(struct net_device *dev)
 
 		for (i = 0; i < txq->bd.ring_size; i++) {
 			/* Initialize the BD for every fragment in the page. */
-			bdp->cbd_sc = cpu_to_fec16(0);
 			if (txq->tx_skbuff[i]) {
 				dev_kfree_skb_any(txq->tx_skbuff[i]);
 				txq->tx_skbuff[i] = NULL;
 			}
 			bdp->cbd_bufaddr = cpu_to_fec32(0);
+			bdp->cbd_sc = cpu_to_fec16((bdp == txq->bd.last) ?
+					BD_SC_WRAP : 0);
 			bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
 		}
-
-		/* Set the last buffer to wrap */
 		bdp = fec_enet_get_prevdesc(bdp, &txq->bd);
-		bdp->cbd_sc |= cpu_to_fec16(BD_SC_WRAP);
 		txq->dirty_tx = bdp;
 	}
 }
@@ -2717,19 +2710,16 @@ fec_enet_alloc_rxq_buffers(struct net_device *ndev, unsigned int queue)
 		}
 
 		rxq->rx_skbuff[i] = skb;
-		bdp->cbd_sc = cpu_to_fec16(BD_ENET_RX_EMPTY);
 
 		if (fep->bufdesc_ex) {
 			struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp;
 			ebdp->cbd_esc = cpu_to_fec32(BD_ENET_RX_INT);
 		}
+		bdp->cbd_sc = cpu_to_fec16(BD_ENET_RX_EMPTY |
+				((bdp == rxq->bd.last) ? BD_SC_WRAP : 0));
 
 		bdp = fec_enet_get_nextdesc(bdp, &rxq->bd);
 	}
-
-	/* Set the last buffer to wrap. */
-	bdp = fec_enet_get_prevdesc(bdp, &rxq->bd);
-	bdp->cbd_sc |= cpu_to_fec16(BD_SC_WRAP);
 	return 0;
 
  err_alloc:
@@ -2752,21 +2742,16 @@ fec_enet_alloc_txq_buffers(struct net_device *ndev, unsigned int queue)
 		if (!txq->tx_bounce[i])
 			goto err_alloc;
 
-		bdp->cbd_sc = cpu_to_fec16(0);
 		bdp->cbd_bufaddr = cpu_to_fec32(0);
 
 		if (fep->bufdesc_ex) {
 			struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp;
 			ebdp->cbd_esc = cpu_to_fec32(BD_ENET_TX_INT);
 		}
-
+		bdp->cbd_sc = cpu_to_fec16((bdp == txq->bd.last) ?
+				BD_SC_WRAP : 0);
 		bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
 	}
-
-	/* Set the last buffer to wrap. */
-	bdp = fec_enet_get_prevdesc(bdp, &txq->bd);
-	bdp->cbd_sc |= cpu_to_fec16(BD_SC_WRAP);
-
 	return 0;
 
  err_alloc:
-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:52 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:52 -0700
Subject: [PATCH net-next V2 09/16] net: fec: move restart test for efficiency
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-10-git-send-email-troy.kisky@boundarydevices.com>

This saves 1 comparison.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index b5ed287..1902897 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1157,8 +1157,13 @@ static void fec_txq(struct net_device *ndev, struct fec_enet_private *fep,
 		/* Order the load of bd.cur and cbd_sc */
 		rmb();
 		status = fec16_to_cpu(READ_ONCE(bdp->cbd_sc));
-		if (status & BD_ENET_TX_READY)
+		if (status & BD_ENET_TX_READY) {
+			if (!readl(txq->bd.reg_desc_active)) {
+				/* ERR006358 has hit, restart tx */
+				writel(0, txq->bd.reg_desc_active);
+			}
 			break;
+		}
 
 		index = fec_enet_get_bd_index(bdp, &txq->bd);
 
@@ -1230,11 +1235,6 @@ static void fec_txq(struct net_device *ndev, struct fec_enet_private *fep,
 				netif_tx_wake_queue(nq);
 		}
 	}
-
-	/* ERR006538: Keep the transmitter going */
-	if (bdp != txq->bd.cur &&
-	    readl(txq->bd.reg_desc_active) == 0)
-		writel(0, txq->bd.reg_desc_active);
 }
 
 static int
-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:53 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:53 -0700
Subject: [PATCH net-next V2 10/16] net: fec: clear cbd_sc after transmission
 to help with debugging
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-11-git-send-email-troy.kisky@boundarydevices.com>

When the tx queue is dumped, it is easier to see that this
entry is idle.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 1902897..96a0394 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1164,6 +1164,8 @@ static void fec_txq(struct net_device *ndev, struct fec_enet_private *fep,
 			}
 			break;
 		}
+		bdp->cbd_sc = cpu_to_fec16((bdp == txq->bd.last) ?
+					   BD_SC_WRAP : 0);
 
 		index = fec_enet_get_bd_index(bdp, &txq->bd);
 
-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:54 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:54 -0700
Subject: [PATCH net-next V2 11/16] net: fec: dump all tx queues in fec_dump
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-12-git-send-email-troy.kisky@boundarydevices.com>

Dump all tx queues, not just queue 0.
Also, disable fec interrupts first.
The interrupts will be reenabled in fec_restart.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 40 +++++++++++++++++--------------
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 96a0394..9b24669 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -271,28 +271,32 @@ static void swap_buffer2(void *dst_buf, void *src_buf, int len)
 static void fec_dump(struct net_device *ndev)
 {
 	struct fec_enet_private *fep = netdev_priv(ndev);
-	struct bufdesc *bdp;
-	struct fec_enet_priv_tx_q *txq;
-	int index = 0;
+	int i;
 
+	/* Disable all FEC interrupts */
+	writel(0, fep->hwp + FEC_IMASK);
 	netdev_info(ndev, "TX ring dump\n");
 	pr_info("Nr     SC     addr       len  SKB\n");
 
-	txq = fep->tx_queue[0];
-	bdp = txq->bd.base;
-
-	do {
-		pr_info("%3u %c%c 0x%04x 0x%08x %4u %p\n",
-			index,
-			bdp == txq->bd.cur ? 'S' : ' ',
-			bdp == txq->dirty_tx ? 'H' : ' ',
-			fec16_to_cpu(bdp->cbd_sc),
-			fec32_to_cpu(bdp->cbd_bufaddr),
-			fec16_to_cpu(bdp->cbd_datlen),
-			txq->tx_skbuff[index]);
-		bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
-		index++;
-	} while (bdp != txq->bd.base);
+	for (i = 0; i < fep->num_tx_queues; i++) {
+		struct fec_enet_priv_tx_q *txq = fep->tx_queue[i];
+		struct bufdesc *bdp = txq->bd.base;
+		int index = 0;
+
+		pr_info("tx queue %d\n", i);
+		do {
+			pr_info("%3u %c%c 0x%04x 0x%08x %4u %p\n",
+				index,
+				bdp == txq->bd.cur ? 'S' : ' ',
+				bdp == txq->dirty_tx ? 'H' : ' ',
+				fec16_to_cpu(bdp->cbd_sc),
+				fec32_to_cpu(bdp->cbd_bufaddr),
+				fec16_to_cpu(bdp->cbd_datlen),
+				txq->tx_skbuff[index]);
+			bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
+			index++;
+		} while (bdp != txq->bd.base);
+	}
 }
 
 static inline bool is_ipv4_pkt(struct sk_buff *skb)
-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:55 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:55 -0700
Subject: [PATCH net-next V2 12/16] net: fec: detect tx int lost
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-13-git-send-email-troy.kisky@boundarydevices.com>

If a tx int is lost, no need to reset
the fec. Just mark the event and call napi_schedule.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 38 ++++++++++++++++++++++++++++++-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 9b24669..afd4060 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1094,14 +1094,50 @@ fec_stop(struct net_device *ndev)
 	}
 }
 
+static const uint txint_flags[] = {
+	FEC_ENET_TXF_0, FEC_ENET_TXF_1, FEC_ENET_TXF_2
+};
 
 static void
 fec_timeout(struct net_device *ndev)
 {
 	struct fec_enet_private *fep = netdev_priv(ndev);
+	struct bufdesc *bdp;
+	unsigned short status;
+	int i;
+	uint events = 0;
 
-	fec_dump(ndev);
+	for (i = 0; i < fep->num_tx_queues; i++) {
+		struct fec_enet_priv_tx_q *txq = fep->tx_queue[i];
+		int index;
+		struct sk_buff *skb = NULL;
 
+		bdp = txq->dirty_tx;
+		while (1) {
+			bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
+			if (bdp == txq->bd.cur)
+				break;
+			index = fec_enet_get_bd_index(bdp, &txq->bd);
+			skb = txq->tx_skbuff[index];
+			if (skb) {
+				status = fec16_to_cpu(bdp->cbd_sc);
+				if ((status & BD_ENET_TX_READY) == 0)
+					events |= txint_flags[i];
+				break;
+			}
+		}
+	}
+	if (events) {
+		fep->events |= events;
+		/* Disable the RX/TX interrupt */
+		writel(FEC_NAPI_IMASK, fep->hwp + FEC_IMASK);
+		napi_schedule(&fep->napi);
+		netif_wake_queue(fep->netdev);
+		pr_err("%s: tx int lost\n", __func__);
+		return;
+	}
+
+	fec_dump(ndev);
 	ndev->stats.tx_errors++;
 
 	schedule_work(&fep->tx_timeout_work);
-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:56 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:56 -0700
Subject: [PATCH net-next V2 13/16] net: fec: print more debug info in
 fec_timeout
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-14-git-send-email-troy.kisky@boundarydevices.com>

Print the current interrupt flags and mask and
the interrupt state during the last interrupt in
fec_timeout.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec.h      | 1 +
 drivers/net/ethernet/freescale/fec_main.c | 4 ++++
 2 files changed, 5 insertions(+)

diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 001200b..615cca1 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -506,6 +506,7 @@ struct fec_enet_private {
 	unsigned int total_tx_ring_size;
 	unsigned int total_rx_ring_size;
 	uint	events;
+	uint	last_ievents;
 
 	struct	platform_device *pdev;
 
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index afd4060..9a3136b 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1107,6 +1107,9 @@ fec_timeout(struct net_device *ndev)
 	int i;
 	uint events = 0;
 
+	pr_err("%s: last=%x %x, mask %x\n", __func__, fep->last_ievents,
+	       readl(fep->hwp + FEC_IEVENT), readl(fep->hwp + FEC_IMASK));
+
 	for (i = 0; i < fep->num_tx_queues; i++) {
 		struct fec_enet_priv_tx_q *txq = fep->tx_queue[i];
 		int index;
@@ -1514,6 +1517,7 @@ fec_enet_interrupt(int irq, void *dev_id)
 
 	if (!int_events)
 		return IRQ_NONE;
+	fep->last_ievents = int_events;
 
 	if (int_events & (FEC_ENET_RXF | FEC_ENET_TXF)) {
 		if (napi_schedule_prep(&fep->napi)) {
-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:57 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:57 -0700
Subject: [PATCH net-next V2 14/16] net: fec: create subroutine reset_tx_queue
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-15-git-send-email-troy.kisky@boundarydevices.com>

This creates one place to release any queued
tx skbs.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 50 +++++++++++++++----------------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 9a3136b..8711196 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -752,12 +752,33 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
 	return NETDEV_TX_OK;
 }
 
+static void reset_tx_queue(struct fec_enet_private *fep,
+			   struct fec_enet_priv_tx_q *txq)
+{
+	struct bufdesc *bdp = txq->bd.base;
+	unsigned int i;
+
+	txq->bd.cur = bdp;
+	for (i = 0; i < txq->bd.ring_size; i++) {
+		/* Initialize the BD for every fragment in the page. */
+		if (txq->tx_skbuff[i]) {
+			dev_kfree_skb_any(txq->tx_skbuff[i]);
+			txq->tx_skbuff[i] = NULL;
+		}
+		bdp->cbd_bufaddr = cpu_to_fec32(0);
+		bdp->cbd_sc = cpu_to_fec16((bdp == txq->bd.last) ?
+					   BD_SC_WRAP : 0);
+		bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
+	}
+	bdp = fec_enet_get_prevdesc(bdp, &txq->bd);
+	txq->dirty_tx = bdp;
+}
+
 /* Init RX & TX buffer descriptors
  */
 static void fec_enet_bd_init(struct net_device *dev)
 {
 	struct fec_enet_private *fep = netdev_priv(dev);
-	struct fec_enet_priv_tx_q *txq;
 	struct fec_enet_priv_rx_q *rxq;
 	struct bufdesc *bdp;
 	unsigned int i;
@@ -780,26 +801,8 @@ static void fec_enet_bd_init(struct net_device *dev)
 		rxq->bd.cur = rxq->bd.base;
 	}
 
-	for (q = 0; q < fep->num_tx_queues; q++) {
-		/* ...and the same for transmit */
-		txq = fep->tx_queue[q];
-		bdp = txq->bd.base;
-		txq->bd.cur = bdp;
-
-		for (i = 0; i < txq->bd.ring_size; i++) {
-			/* Initialize the BD for every fragment in the page. */
-			if (txq->tx_skbuff[i]) {
-				dev_kfree_skb_any(txq->tx_skbuff[i]);
-				txq->tx_skbuff[i] = NULL;
-			}
-			bdp->cbd_bufaddr = cpu_to_fec32(0);
-			bdp->cbd_sc = cpu_to_fec16((bdp == txq->bd.last) ?
-					BD_SC_WRAP : 0);
-			bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
-		}
-		bdp = fec_enet_get_prevdesc(bdp, &txq->bd);
-		txq->dirty_tx = bdp;
-	}
+	for (q = 0; q < fep->num_tx_queues; q++)
+		reset_tx_queue(fep, fep->tx_queue[q]);
 }
 
 static void fec_enet_active_rxring(struct net_device *ndev)
@@ -2652,13 +2655,10 @@ static void fec_enet_free_buffers(struct net_device *ndev)
 
 	for (q = 0; q < fep->num_tx_queues; q++) {
 		txq = fep->tx_queue[q];
-		bdp = txq->bd.base;
+		reset_tx_queue(fep, txq);
 		for (i = 0; i < txq->bd.ring_size; i++) {
 			kfree(txq->tx_bounce[i]);
 			txq->tx_bounce[i] = NULL;
-			skb = txq->tx_skbuff[i];
-			txq->tx_skbuff[i] = NULL;
-			dev_kfree_skb(skb);
 		}
 	}
 }
-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:58 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:58 -0700
Subject: [PATCH net-next V2 15/16] net: fec: call dma_unmap_single on mapped
 tx buffers at restart
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-16-git-send-email-troy.kisky@boundarydevices.com>

Make sure any pending tx buffers are unmapped when the
fec is restarted.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 8711196..1d71b2e 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -404,6 +404,7 @@ dma_mapping_error:
 		bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
 		dma_unmap_single(&fep->pdev->dev, fec32_to_cpu(bdp->cbd_bufaddr),
 				 fec16_to_cpu(bdp->cbd_datlen), DMA_TO_DEVICE);
+		bdp->cbd_bufaddr = cpu_to_fec32(0);
 	}
 	return ERR_PTR(-ENOMEM);
 }
@@ -761,11 +762,18 @@ static void reset_tx_queue(struct fec_enet_private *fep,
 	txq->bd.cur = bdp;
 	for (i = 0; i < txq->bd.ring_size; i++) {
 		/* Initialize the BD for every fragment in the page. */
+		if (bdp->cbd_bufaddr) {
+			if (!IS_TSO_HEADER(txq, fec32_to_cpu(bdp->cbd_bufaddr)))
+				dma_unmap_single(&fep->pdev->dev,
+						 fec32_to_cpu(bdp->cbd_bufaddr),
+						 fec16_to_cpu(bdp->cbd_datlen),
+						 DMA_TO_DEVICE);
+			bdp->cbd_bufaddr = cpu_to_fec32(0);
+		}
 		if (txq->tx_skbuff[i]) {
 			dev_kfree_skb_any(txq->tx_skbuff[i]);
 			txq->tx_skbuff[i] = NULL;
 		}
-		bdp->cbd_bufaddr = cpu_to_fec32(0);
 		bdp->cbd_sc = cpu_to_fec16((bdp == txq->bd.last) ?
 					   BD_SC_WRAP : 0);
 		bdp = fec_enet_get_nextdesc(bdp, &txq->bd);
@@ -2647,6 +2655,7 @@ static void fec_enet_free_buffers(struct net_device *ndev)
 						 fec32_to_cpu(bdp->cbd_bufaddr),
 						 FEC_ENET_RX_FRSIZE - fep->rx_align,
 						 DMA_FROM_DEVICE);
+				bdp->cbd_bufaddr = cpu_to_fec32(0);
 				dev_kfree_skb(skb);
 			}
 			bdp = fec_enet_get_nextdesc(bdp, &rxq->bd);
-- 
2.5.0



From troy.kisky at boundarydevices.com  Wed Feb 24 16:36:59 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Wed, 24 Feb 2016 17:36:59 -0700
Subject: [PATCH net-next V2 16/16] net: fec: don't set cbd_bufaddr unless no
 mapping error
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <1456360619-24390-17-git-send-email-troy.kisky@boundarydevices.com>

Not assigning cbd_bufaddr on error will prevent trying to
unmap the error in case the FEC is reset.

Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>
---
 drivers/net/ethernet/freescale/fec_main.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 1d71b2e..c443a96 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -600,7 +600,7 @@ fec_enet_txq_put_hdr_tso(struct fec_enet_priv_tx_q *txq,
 	int hdr_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
 	struct bufdesc_ex *ebdp = container_of(bdp, struct bufdesc_ex, desc);
 	void *bufaddr;
-	unsigned long dmabuf;
+	dma_addr_t dmabuf;
 	unsigned int estatus = 0;
 
 	bufaddr = txq->tso_hdrs + index * TSO_HEADER_SIZE;
@@ -1298,17 +1298,21 @@ fec_enet_new_rxbdp(struct net_device *ndev, struct bufdesc *bdp, struct sk_buff
 {
 	struct  fec_enet_private *fep = netdev_priv(ndev);
 	int off;
+	dma_addr_t dmabuf;
 
 	off = ((unsigned long)skb->data) & fep->rx_align;
 	if (off)
 		skb_reserve(skb, fep->rx_align + 1 - off);
 
-	bdp->cbd_bufaddr = cpu_to_fec32(dma_map_single(&fep->pdev->dev, skb->data, FEC_ENET_RX_FRSIZE - fep->rx_align, DMA_FROM_DEVICE));
-	if (dma_mapping_error(&fep->pdev->dev, fec32_to_cpu(bdp->cbd_bufaddr))) {
+	dmabuf = dma_map_single(&fep->pdev->dev, skb->data,
+				FEC_ENET_RX_FRSIZE - fep->rx_align,
+				DMA_FROM_DEVICE);
+	if (dma_mapping_error(&fep->pdev->dev, dmabuf)) {
 		if (net_ratelimit())
 			netdev_err(ndev, "Rx DMA memory map failed\n");
 		return -ENOMEM;
 	}
+	bdp->cbd_bufaddr = cpu_to_fec32(dmabuf);
 
 	return 0;
 }
-- 
2.5.0



From k.kozlowski at samsung.com  Wed Feb 24 16:43:00 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Thu, 25 Feb 2016 09:43:00 +0900
Subject: [GIT PULL 3/7] drivers: soc: EXYNOS drivers for v4.6
In-Reply-To: <20160224222254.GT10126@localhost>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
 <1455496446-23779-4-git-send-email-k.kozlowski@samsung.com>
 <20160224222254.GT10126@localhost>
Message-ID: <56CE4E14.2050701@samsung.com>

On 25.02.2016 07:22, Olof Johansson wrote:
> On Mon, Feb 15, 2016 at 09:34:02AM +0900, Krzysztof Kozlowski wrote:
>> Hi Arnd, Kevin and Olof,
>>
>> This finally moves SROM controller and PMU code to separate
>> driver under drivers/soc/samsung.
>>
>> Kind regards,
>> Krzysztof
>>
>>
>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>
>>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-soc-srom-pmu-4.6
>>
>> for you to fetch changes up to 74a6659e8bf193066ba6bf365de66baa897aebb1:
>>
>>   drivers: soc: Add support for Exynos PMU driver (2016-01-25 10:46:59 +0900)
>>
>> ----------------------------------------------------------------
>> A set of changes adding new drivers under drivers/soc/samsung:
>>
>> 1. Split code for handling SROM registers out of arm/mach-exynos
>>    in to separate SROM controller driver under drivers/soc/samsung.
>>    The driver will save and restore SROM registers during Suspend
>>    to RAM.
>>
>> 2. Add to this SROM controller driver support for bank configuration
>>    used by child devices. This allows usage of SMSC9115 Ethernet chip
>>    on SMDK5410 (Exynos5410) directly connected to SROM controller.
> 
> Hi,
> 
> OMAP has GPMC drivers under drivers/memory. I wonder if SROM should go there
> too, since it's a quite similar bus.

I wish I get this feedback before, when we were discussing the SROM
patches. :/

Indeed this sounds reasonable. On some boards the omap-gpmc is used for
the same purpose: interfacing to smsc,lan9115 (like on SMDK5410).


> Feel free to respin this without SROM now, so we can get the other pieces in
> sooner and then revisit the SROM asyncronously. That'll remove the dependencies
> on DT as well.

Okay, I'll rebase all drivers/soc branches and respin the pull request
so PMU driver and other stuff could go in.

BTW, just in case, although PMU stands for "Power Management Unit" I
don't think it should be placed under drivers/power because it is not a
avs/charger/battery/reset driver. Existing power-related drivers are
under driver/soc (bcm, dove, tegra).

Re-work of SROM drivers could be started on top of it.

Best regards,
Krzysztof


From jay.xu at rock-chips.com  Wed Feb 24 16:42:57 2016
From: jay.xu at rock-chips.com (Jianqun Xu)
Date: Thu, 25 Feb 2016 08:42:57 +0800
Subject: [PATCH 3/4] clk: rockchip: add dt-binding header for rk3399
In-Reply-To: <4483822.0pRK7cKepF@phil>
References: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
 <1456210864-29037-4-git-send-email-jay.xu@rock-chips.com>
 <4483822.0pRK7cKepF@phil>
Message-ID: <56CE4E11.7090808@rock-chips.com>

Hi Heiko:

? 24/02/2016 21:27, Heiko Stuebner ??:
> Hi Jianqun,
>
> Am Dienstag, 23. Februar 2016, 15:01:03 schrieb jianqun.xu:
>> From: Xing Zheng <zhengxing at rock-chips.com>
>>
>> Add the dt-bindings header for the rk3399, that gets shared between
>> the clock controller and the clock references in the dts.
>>
>> Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
>> Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
>
> looks ok so far, do you have an estimate when the revised clk driver will be
> sent? Before committing to support this binding header forever I'd like to
> take a look over the clock-tree itself, just to be sure ;-)
>
No problem, since the cru head file is needed by many drivers, so it 
must be pushed as
soon as possible.

It's better to send the clk driver by Xing in a separate patch. I will 
co-work with xing.

Thanks
>
> Thanks
> Heiko
>
>
>



From maxime.ripard at free-electrons.com  Wed Feb 24 16:54:12 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Feb 2016 16:54:12 -0800
Subject: [PATCH v6] Fix sun7i pin assignment for IRQ's
In-Reply-To: <1456161251-2303-1-git-send-email-henry@nitronetworks.nl>
References: <1456161251-2303-1-git-send-email-henry@nitronetworks.nl>
Message-ID: <20160225005412.GB4736@lukather>

Hi,

Usually, the patch title should be prefixed by the subsystem it
applies to so that maintainer and reviewers can spot it more
easily. In this case, it would be something like

pinctrl: sunxi: Fix sun7i pin assignment for IRQ's

On Mon, Feb 22, 2016 at 06:14:07PM +0100, Henry Paulissen wrote:
> After testing IRQ pins we found some bugs in the pinctrl declaration.
> Both PI* and PC* pins didn't work. PI* pins seemed to be connected
> to the wrong mux and PC* pins waren't working at all.
> 
> Please note that the A20 soc manual is contradicting between version
> and even within the same document for both the PI and PC pins.

Which sections are in contradiction?

> Patch is based on testing with the hardware itself.

How did you test it? Using the sysfs API, or did you have any hardware
connected to it?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/8bfcd770/attachment.sig>

From maxime.ripard at free-electrons.com  Wed Feb 24 16:56:44 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Wed, 24 Feb 2016 16:56:44 -0800
Subject: [PATCH 01/14] pinctrl: sunxi: Add A83T R_PIO controller support
In-Reply-To: <CACRpkdb7=x2bJP1nXpF2bP3U0t+NUHiuw_aeTAhbR8OXOrHn6A@mail.gmail.com>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-2-git-send-email-vishnupatekar0510@gmail.com>
 <CACRpkdbCgOBQw28d=qc1fAURY3x8UdoWqiMtXMZ=uWLaQj-nbg@mail.gmail.com>
 <20160211123648.GN31506@lukather>
 <CACRpkdaGZ4-S1A9zUUaBXXEazyJf_uZ4ESiBhw-CpozXMxfDHg@mail.gmail.com>
 <20160211151246.GO31506@lukather>
 <CACRpkdb7=x2bJP1nXpF2bP3U0t+NUHiuw_aeTAhbR8OXOrHn6A@mail.gmail.com>
Message-ID: <20160225005644.GC4736@lukather>

Hi Linus,

On Tue, Feb 16, 2016 at 12:23:37AM +0100, Linus Walleij wrote:
> On Thu, Feb 11, 2016 at 4:12 PM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > On Thu, Feb 11, 2016 at 02:47:57PM +0100, Linus Walleij wrote:
> 
> >> Can you guys supply a MAINTAINERS entry for the sunxi
> >> stuff?
> >
> > We have one, and Chen-Yu is listed as co-maintainer:
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n911
> 
> Modified request:
> can you put in F: wildcards there to match the files pertaining to
> the sunxi platform, so that scripts/find-maintainer.pl finds them.

I don't really know what you mean, on my laptop, if I run it, I get
the following result:

$ ./scripts/get_maintainer.pl -f drivers/pinctrl/sunxi/pinctrl-sun8i-a83t.c
Linus Walleij <linus.walleij at linaro.org> (maintainer:PIN CONTROL SUBSYSTEM,commit_signer:2/2=100%)
Maxime Ripard <maxime.ripard at free-electrons.com> (maintainer:ARM/Allwinner sunXi SoC support,commit_signer:1/2=50%)
Chen-Yu Tsai <wens at csie.org> (maintainer:ARM/Allwinner sunXi SoC support)
Fabian Frederick <fabf at skynet.be> (commit_signer:1/2=50%,authored:1/2=50%)
Vishnu Patekar <vishnupatekar0510 at gmail.com> (commit_signer:1/2=50%,authored:1/2=50%)
Hongzhou Yang <hongzhou.yang at mediatek.com> (commit_signer:1/2=50%)
linux-gpio at vger.kernel.org (open list:PIN CONTROL SUBSYSTEM)
linux-arm-kernel at lists.infradead.org (moderated list:ARM/Allwinner sunXi SoC support)
linux-kernel at vger.kernel.org (open list)

With both Chen-Yu and I listed as maintainers.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160224/f137e911/attachment-0001.sig>

From khilman at baylibre.com  Wed Feb 24 17:10:20 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Wed, 24 Feb 2016 17:10:20 -0800
Subject: [PATCH] drivers: perf: arm: implement CPU_PM notifier
In-Reply-To: <1456251759-24768-1-git-send-email-lorenzo.pieralisi@arm.com>
 (Lorenzo Pieralisi's message of "Tue, 23 Feb 2016 18:22:39 +0000")
References: <1456251759-24768-1-git-send-email-lorenzo.pieralisi@arm.com>
Message-ID: <7hsi0hr3wj.fsf@baylibre.com>

Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> writes:

> When a CPU is suspended (either through suspend-to-RAM or CPUidle),
> its PMU registers content can be lost, which means that counters
> registers values that were initialized on power down entry have to be
> reprogrammed on power-up to make sure the counters set-up is preserved

This assumes that the PMUs are always sharing a power rail with a
specific CPU, not the cluster.  Is that a reliable assumption?

Kevin


From miles.chen at mediatek.com  Wed Feb 24 17:34:33 2016
From: miles.chen at mediatek.com (Miles Chen)
Date: Thu, 25 Feb 2016 09:34:33 +0800
Subject: [PATCH] arm64/mm: fix virtual address boundary check
In-Reply-To: <20160224161944.GJ4777@e104818-lin.cambridge.arm.com>
References: <1456329708-2042-1-git-send-email-miles.chen@mediatek.com>
 <20160224161944.GJ4777@e104818-lin.cambridge.arm.com>
Message-ID: <1456364073.16470.8.camel@mtkswgap22>

On Wed, 2016-02-24 at 16:19 +0000, Catalin Marinas wrote:
> On Thu, Feb 25, 2016 at 12:01:48AM +0800, miles.chen at mediatek.com wrote:
> > From: Miles Chen <miles.chen at mediatek.com>
> > 
> > The MODULES_VADDR is not the lowest possible
> > kernel virtual address. TASK_SIZE_64 may be larger than
> > MODULES_VADDR, FIXADDR_TOP, and PCI_IO_START.
> > 
> > Fix this by comparing TASK_SIZE_64 (highest user virtual address)
> > with VA_START (lowest kernel virtual address).
> > 
> >  #define VA_BITS		(CONFIG_ARM64_VA_BITS)
> >  #define VA_START		(UL(0xffffffffffffffff) << VA_BITS)
> >  #define PAGE_OFFSET		(UL(0xffffffffffffffff) << (VA_BITS - 1))
> >  #define MODULES_END		(PAGE_OFFSET)
> >  #define MODULES_VADDR		(MODULES_END - SZ_64M)
> >  #define PCI_IO_END		(MODULES_VADDR - SZ_2M)
> >  #define PCI_IO_START		(PCI_IO_END - PCI_IO_SIZE)
> >  #define FIXADDR_TOP		(PCI_IO_START - SZ_2M)
> >  #define TASK_SIZE_64		(UL(1) << VA_BITS)
> 
> We should remove these checks altogether. There is a huge gap between
> the user and kernel addresses that they would never overlap (we don't
> have enough levels of page tables to cover 64-bit VA space).
> 
Thanks for your reply. I confirmed that in the ARMv8 documentation. 
I'll send another patch to remove these checks.


Cheers,
Miles



From olof at lixom.net  Wed Feb 24 17:35:25 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 17:35:25 -0800
Subject: [GIT PULL 3/7] drivers: soc: EXYNOS drivers for v4.6
In-Reply-To: <56CE4E14.2050701@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
 <1455496446-23779-4-git-send-email-k.kozlowski@samsung.com>
 <20160224222254.GT10126@localhost> <56CE4E14.2050701@samsung.com>
Message-ID: <CAOesGMig_djAEfBjmU8Vu4jO+hR3w6JDAR8pPT1ze0sNck_4-g@mail.gmail.com>

On Wed, Feb 24, 2016 at 4:43 PM, Krzysztof Kozlowski
<k.kozlowski at samsung.com> wrote:
> On 25.02.2016 07:22, Olof Johansson wrote:
>> On Mon, Feb 15, 2016 at 09:34:02AM +0900, Krzysztof Kozlowski wrote:
>>> Hi Arnd, Kevin and Olof,
>>>
>>> This finally moves SROM controller and PMU code to separate
>>> driver under drivers/soc/samsung.
>>>
>>> Kind regards,
>>> Krzysztof
>>>
>>>
>>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>>
>>>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-soc-srom-pmu-4.6
>>>
>>> for you to fetch changes up to 74a6659e8bf193066ba6bf365de66baa897aebb1:
>>>
>>>   drivers: soc: Add support for Exynos PMU driver (2016-01-25 10:46:59 +0900)
>>>
>>> ----------------------------------------------------------------
>>> A set of changes adding new drivers under drivers/soc/samsung:
>>>
>>> 1. Split code for handling SROM registers out of arm/mach-exynos
>>>    in to separate SROM controller driver under drivers/soc/samsung.
>>>    The driver will save and restore SROM registers during Suspend
>>>    to RAM.
>>>
>>> 2. Add to this SROM controller driver support for bank configuration
>>>    used by child devices. This allows usage of SMSC9115 Ethernet chip
>>>    on SMDK5410 (Exynos5410) directly connected to SROM controller.
>>
>> Hi,
>>
>> OMAP has GPMC drivers under drivers/memory. I wonder if SROM should go there
>> too, since it's a quite similar bus.
>
> I wish I get this feedback before, when we were discussing the SROM
> patches. :/

Yeah, I apologize -- I usually don't have the bandwidth to follow all
discussions, so I have to catch them when the pull requests come in.

I usually look up the discussions, this time I didn't.


>
> Indeed this sounds reasonable. On some boards the omap-gpmc is used for
> the same purpose: interfacing to smsc,lan9115 (like on SMDK5410).
>
>
>> Feel free to respin this without SROM now, so we can get the other pieces in
>> sooner and then revisit the SROM asyncronously. That'll remove the dependencies
>> on DT as well.
>
> Okay, I'll rebase all drivers/soc branches and respin the pull request
> so PMU driver and other stuff could go in.
>
> BTW, just in case, although PMU stands for "Power Management Unit" I
> don't think it should be placed under drivers/power because it is not a
> avs/charger/battery/reset driver. Existing power-related drivers are
> under driver/soc (bcm, dove, tegra).
>
> Re-work of SROM drivers could be started on top of it.

Sounds good, and yes -- those sound appropriate to have under
drivers/soc at least at this time.

(At some point in time we'll have to go through and cleanup
drivers/soc, but we're letting it grow at the moment).


-Olof


From ddaney.cavm at gmail.com  Wed Feb 24 17:44:57 2016
From: ddaney.cavm at gmail.com (David Daney)
Date: Wed, 24 Feb 2016 17:44:57 -0800
Subject: [PATCH v4] arm64: Add workaround for Cavium erratum 27456
Message-ID: <1456364697-25083-1-git-send-email-ddaney.cavm@gmail.com>

From: Andrew Pinski <apinski at cavium.com>

On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
instructions may cause the icache to become corrupted if it contains
data for a non-current ASID.

This patch implements the workaround (which invalidates the local
icache when switching the mm) by using code patching.

Signed-off-by: Andrew Pinski <apinski at cavium.com>
Signed-off-by: David Daney <david.daney at cavium.com>
Reviewed-by: Will Deacon <will.deacon at arm.com>
---
v4:
  - Add Reviewed-by
  - Improve wording of changlog and Kconfig help
  - Updated capability constant hoping that it eases merging with KVM patches 

 Documentation/arm64/silicon-errata.txt |  1 +
 arch/arm64/Kconfig                     | 11 +++++++++++
 arch/arm64/include/asm/cpufeature.h    |  3 ++-
 arch/arm64/kernel/cpu_errata.c         |  9 +++++++++
 arch/arm64/mm/proc.S                   | 12 ++++++++++++
 5 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
index 58b71dd..ba4b6ac 100644
--- a/Documentation/arm64/silicon-errata.txt
+++ b/Documentation/arm64/silicon-errata.txt
@@ -56,3 +56,4 @@ stable kernels.
 |                |                 |                 |                         |
 | Cavium         | ThunderX ITS    | #22375, #24313  | CAVIUM_ERRATUM_22375    |
 | Cavium         | ThunderX GICv3  | #23154          | CAVIUM_ERRATUM_23154    |
+| Cavium         | ThunderX Core   | #27456          | CAVIUM_ERRATUM_27456    |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b646091..97cd2b9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -435,6 +435,17 @@ config CAVIUM_ERRATUM_23154
 
 	  If unsure, say Y.
 
+config CAVIUM_ERRATUM_27456
+	bool "Cavium erratum 27456: Broadcast TLBI instructions may cause icache corruption"
+	default y
+	help
+	  On ThunderX T88 pass 1.x through 2.1 parts, broadcast TLBI
+	  instructions may cause the icache to become corrupted if it
+	  contains data for a non-current ASID.  The fix is to
+	  invalidate the icache when changing the mm context.
+
+	  If unsure, say Y.
+
 endmenu
 
 
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 37a53fc..727e594 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -33,8 +33,9 @@
 #define ARM64_HAS_NO_HW_PREFETCH		8
 #define ARM64_HAS_UAO				9
 #define ARM64_ALT_PAN_NOT_UAO			10
+#define ARM64_WORKAROUND_CAVIUM_27456		12
 
-#define ARM64_NCAPS				11
+#define ARM64_NCAPS				13
 
 #ifndef __ASSEMBLY__
 
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index e6bc988..06afd04 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -88,6 +88,15 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
 		MIDR_RANGE(MIDR_THUNDERX, 0x00, 0x01),
 	},
 #endif
+#ifdef CONFIG_CAVIUM_ERRATUM_27456
+	{
+	/* Cavium ThunderX, T88 pass 1.x - 2.1 */
+		.desc = "Cavium erratum 27456",
+		.capability = ARM64_WORKAROUND_CAVIUM_27456,
+		MIDR_RANGE(MIDR_THUNDERX, 0x00,
+			   (1 << MIDR_VARIANT_SHIFT) | 1),
+	},
+#endif
 	{
 	}
 };
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 0c19534..543f519 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -25,6 +25,8 @@
 #include <asm/hwcap.h>
 #include <asm/pgtable-hwdef.h>
 #include <asm/pgtable.h>
+#include <asm/cpufeature.h>
+#include <asm/alternative.h>
 
 #include "proc-macros.S"
 
@@ -137,7 +139,17 @@ ENTRY(cpu_do_switch_mm)
 	bfi	x0, x1, #48, #16		// set the ASID
 	msr	ttbr0_el1, x0			// set TTBR0
 	isb
+alternative_if_not ARM64_WORKAROUND_CAVIUM_27456
 	ret
+	nop
+	nop
+	nop
+alternative_else
+	ic	iallu
+	dsb	nsh
+	isb
+	ret
+alternative_endif
 ENDPROC(cpu_do_switch_mm)
 
 	.pushsection ".idmap.text", "ax"
-- 
1.8.3.1



From olof at lixom.net  Wed Feb 24 16:40:38 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 16:40:38 -0800
Subject: [PATCH v3] dts/ls2080a: Update PCIe compatible
In-Reply-To: <20160218143639.GK9654@rob-hp-laptop>
References: <1455674663-9273-1-git-send-email-Mingkai.Hu@freescale.com>
 <20160218143639.GK9654@rob-hp-laptop>
Message-ID: <20160225004038.GE10126@localhost>

On Thu, Feb 18, 2016 at 08:36:39AM -0600, Rob Herring wrote:
> On Wed, Feb 17, 2016 at 10:04:23AM +0800, Mingkai Hu wrote:
> > From: Minghuan Lian <minghuan.lian at nxp.com>
> > 
> > The patch adds LS2085a to PCIe compatible to fix the compatibility
> > issue when using firmware with LS2085a compatible property.
> > 
> > Signed-off-by: Minghuan Lian <minghuan.lian at nxp.com>
> > Signed-off-by: Mingkai Hu <mingkai.hu at nxp.com>
> > ---
> > v3:
> >  - Make the compatible consistent between layerscape-pci.txt
> >    and dts file.
> > 
> > v2:
> >   - Rebased to latest kernel base
> > 
> >  Documentation/devicetree/bindings/pci/layerscape-pci.txt |  2 +-
> >  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi           | 12 ++++++++----
> >  2 files changed, 9 insertions(+), 5 deletions(-)
> > 
> 
> Acked-by: Rob Herring <robh at kernel.org>

Applied, thanks.


-Olof


From olof at lixom.net  Wed Feb 24 16:55:43 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 16:55:43 -0800
Subject: [GIT PULL] ARM: mvebu: arm64 for v4.6 (#1)
In-Reply-To: <878u2js4cn.fsf@free-electrons.com>
References: <878u2js4cn.fsf@free-electrons.com>
Message-ID: <20160225005543.GA29055@localhost>

On Wed, Feb 17, 2016 at 05:12:40PM +0100, Gregory CLEMENT wrote:
> Hi,
> 
> Here is the first pull request for arm64 for mvebu for v4.6. It is even
> the first pull request ever for arm64 for us. Let me know if I am doing
> it wrong.
> 
> I split my initial series[1] in two parts: device tree related and non
> device tree related. I will also let the driver maintainers directly
> take the related patch for ATA and serial.
> 
> For this non device tree part I have a dependency with the irchip
> subsystem. For this I based on the irqchip/mvebu immutable branch form
> Jason Cooper located at git://git.infradead.org/users/jcooper/linux.git.
> 
> Thanks,
> 
> Gregory
> 
> [1]: https://lkml.org/lkml/2016/2/16/735
> 
> The following changes since commit 63131b636a0ec969e8b98122c1a928b5a2649d3b:
> 
>   irqchip/armada-370-xp: Do not enable it by default when ARCH_MVEBU is selected (2016-02-16 18:11:39 +0000)

PLease do this by explicit merge instead in the future, so it's obvious that
there is an external branch merged in history later.

That way, doing the full diffstat including the merge is just fine too.


> are available in the git repository at:
> 
>   git://git.infradead.org/linux-mvebu.git tags/mvebu-arm64-4.6-1
> 
> for you to fetch changes up to e772ca05cceb1480bdc7a7579e042b18558d0959:
> 
>   arm64: defconfig: enable Armada 3700 related config (2016-02-17 16:23:20 +0100)

Merged, thanks!


-Olof


From olof at lixom.net  Wed Feb 24 16:56:37 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 16:56:37 -0800
Subject: [GIT PULL] at91: defconfig for 4.6 #1
In-Reply-To: <20160218015634.GA31609@piout.net>
References: <20160218015634.GA31609@piout.net>
Message-ID: <20160225005637.GC29055@localhost>

On Thu, Feb 18, 2016 at 02:56:34AM +0100, Alexandre Belloni wrote:
> Arnd, Olof, Kevin,
> 
> A defconfig update, adding the sama5d2 ADC to sama5_defconfig.
> 
> Thanks,
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.6-defconfig
> 
> for you to fetch changes up to 48a2e12adb7f4d1a03720d3923bedbc13ab96143:
> 
>   ARM: at91/defconfig: add sama5d2 adc support in sama5_defconfig (2016-02-17 22:51:48 +0100)
> 
> ----------------------------------------------------------------
> defconfig update for 4.6:
>  - Addition of sama5d2 ADC to sama5_defconfig
> 
> ----------------------------------------------------------------
> Ludovic Desroches (1):
>       ARM: at91/defconfig: add sama5d2 adc support in sama5_defconfig
> 
>  arch/arm/configs/sama5_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Merged, thanks.


-Olof


From olof at lixom.net  Wed Feb 24 16:56:08 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 16:56:08 -0800
Subject: [GIT PULL] ARM: mvebu: dt64 for v4.6 (#1)
In-Reply-To: <877fi3s48z.fsf@free-electrons.com>
References: <877fi3s48z.fsf@free-electrons.com>
Message-ID: <20160225005608.GB29055@localhost>

On Wed, Feb 17, 2016 at 05:14:52PM +0100, Gregory CLEMENT wrote:
> Hi,
> 
> Here is the first pull request for dt64 for mvebu for v4.6.
> 
> This is the second part of the Armada 3700 series[1]. This part is
> easier to handle as there is no dependency. As for the other one, let me
> know if I should do it in a different way.
> 
> Thanks,
> 
> Gregory
> 
> [1]: https://lkml.org/lkml/2016/2/16/735
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/linux-mvebu.git tags/mvebu-dt64-4.6-1
> 
> for you to fetch changes up to adbc3695d9e487fa07214140a46b68ac3156fb78:
> 
>   arm64: dts: add the Marvell Armada 3700 family and a development board (2016-02-17 16:09:55 +0100)
> 
> ----------------------------------------------------------------
> mvebu dt64 for 4.6 (part 1)
> 
> Device tree part of the Armada 3700 support:
> - binding for the Armada 3700 SoCs
> - device tree files for the SoCs and a board
> - tidy up the Marvell related files
> 
> ----------------------------------------------------------------
> Gregory CLEMENT (4):
>       Documentation: dt-bindings: Add a new compatible for the Armada 3700
>       Documentation: dt: Tidy up the Marvell related files
>       devicetree: bindings: add DT binding for the Marvell Armada 3700 SoC family
>       arm64: dts: add the Marvell Armada 3700 family and a development board

Merged, thanks.

In the future, please use arm64: dts: marvell: ...


-Olof


From olof at lixom.net  Wed Feb 24 16:47:49 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 16:47:49 -0800
Subject: [PATCH v4 12/12] arm64: defconfig: enable Armada 3700 related
 config
In-Reply-To: <1455646502-23834-13-git-send-email-gregory.clement@free-electrons.com>
References: <1455646502-23834-1-git-send-email-gregory.clement@free-electrons.com>
 <1455646502-23834-13-git-send-email-gregory.clement@free-electrons.com>
Message-ID: <20160225004749.GF10126@localhost>

On Tue, Feb 16, 2016 at 07:15:02PM +0100, Gregory CLEMENT wrote:
> This patch enables the configuration for the Armada 3700 family and for
> the related driver it uses.
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement at free-electrons.com>
> Reviewed-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
> ---
>  arch/arm64/configs/defconfig | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 18ca9fb9e65f..7ca2f0247ec5 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -31,6 +31,7 @@ CONFIG_MODULES=y
>  CONFIG_MODULE_UNLOAD=y
>  # CONFIG_BLK_DEV_BSG is not set
>  # CONFIG_IOSCHED_DEADLINE is not set
> +CONFIG_ARCH_MVEBU=y
>  CONFIG_ARCH_BCM_IPROC=y
>  CONFIG_ARCH_BERLIN=y
>  CONFIG_ARCH_EXYNOS7=y

How did this end up here? It's in alphabetical order in the Kconfig, and here
you're inserting it first. Savedefconfig inserts it at the expected location.


I've fixed it up in the merge now, which isn't ideal. Maybe you edited
the defconfig by hand?


-Olof


From olof at lixom.net  Wed Feb 24 17:18:23 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 17:18:23 -0800
Subject: [GIT PULL] at91: drivers for 4.6 #1
In-Reply-To: <20160218020608.GA31682@piout.net>
References: <20160218020608.GA31682@piout.net>
Message-ID: <20160225011823.GD29055@localhost>

On Thu, Feb 18, 2016 at 03:06:08AM +0100, Alexandre Belloni wrote:
> Arnd, Olof, Kevin,
> 
> This is a rework of the PMC driver. It touches multiple subsystems so
> the easiest path is through arm-soc.
> 
> Thanks,
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.6-drivers
> 
> for you to fetch changes up to 0002ca168f16e5b6ac67415a4e0198cc39af2b7f:
> 
>   clk: at91: remove useless includes (2016-02-17 17:53:04 +0100)

Merged into next/drivers.


Thanks!


-Olof


From olof at lixom.net  Wed Feb 24 17:19:29 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 17:19:29 -0800
Subject: [GIT PULL] at91: dt for 4.6 #1
In-Reply-To: <20160218022311.GA2466@piout.net>
References: <20160218022311.GA2466@piout.net>
Message-ID: <20160225011929.GE29055@localhost>

On Thu, Feb 18, 2016 at 03:23:11AM +0100, Alexandre Belloni wrote:
> Arnd, Olof, Kevin,
> 
> This is the addition of the ADC support for sama5d2. The driver went
> through the iio tree.
> 
> Thanks!
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.6-dt
> 
> for you to fetch changes up to 5e72c25b40c1e9ed77650f258799514aabd17303:
> 
>   ARM: dts: at91: sama5d2 Xplained: enable the adc device (2016-02-18 03:10:05 +0100)

Merged, thanks.


-Olof


From olof at lixom.net  Wed Feb 24 17:21:21 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 17:21:21 -0800
Subject: [GIT PULL] Reset controller changes for v4.6
In-Reply-To: <1455874787.13163.7.camel@pengutronix.de>
References: <1455874787.13163.7.camel@pengutronix.de>
Message-ID: <20160225012121.GF29055@localhost>

On Fri, Feb 19, 2016 at 10:39:47AM +0100, Philipp Zabel wrote:
> Dear arm-soc maintainers,
> 
> this tag adds reset support for Pistachio, makes
> struct reset_control_ops const, and moves the DT
> cell size check into the core.
> 
> best regards
> Philipp
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.pengutronix.de/git/pza/linux.git tags/reset-for-4.6
> 
> for you to fetch changes up to f673ed4d5fdc123b1552525de30741cd8dfde53f:
> 
>   reset: sti: Make reset_control_ops const (2016-02-10 10:53:38 +0100)
> 
> ----------------------------------------------------------------
> Reset controller changes for v4.6
> 
> - add support for the imgtec Pistachio SoC reset controller
> - make struct reset_control_ops const
> - move DT cell size check into the core to avoid code duplication
>   in the drivers

Merged, thanks!


-Olof



From olof at lixom.net  Wed Feb 24 17:24:18 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 17:24:18 -0800
Subject: [GIT PULL] SoCFPGA defconfig for v4.6
In-Reply-To: <1455876126-26635-1-git-send-email-dinguyen@kernel.org>
References: <1455876126-26635-1-git-send-email-dinguyen@kernel.org>
Message-ID: <20160225012418.GG29055@localhost>

On Fri, Feb 19, 2016 at 04:02:06AM -0600, Dinh Nguyen wrote:
> Hi Arnd, Kevin, and Olof:
> 
> Please consider pulling this defconfig update for v4.6.
> 
> Thanks,
> Dinh
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git socfpga_defconfig_for_v4.6
> 
> for you to fetch changes up to 31d74b2bf0c921276a1e987ca5371e2f79a783c2:
> 
>   ARM: socfpga_defconfig: enable support for initramfs/initrd support (2016-02-19 03:48:20 -0600)
> 
> ----------------------------------------------------------------
> SoCFPGA defconfig update for v4.6
> -Enable initrd/initramfs support
> 
> ----------------------------------------------------------------
> Dinh Nguyen (1):
>       ARM: socfpga_defconfig: enable support for initramfs/initrd support
> 
>  arch/arm/configs/socfpga_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Merged, thanks!


-Olof


From olof at lixom.net  Wed Feb 24 17:28:15 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 17:28:15 -0800
Subject: [GIT PULL] ARM: Keystone DTS for 4.6
In-Reply-To: <1455959351-11524-1-git-send-email-ssantosh@kernel.org>
References: <1455959351-11524-1-git-send-email-ssantosh@kernel.org>
Message-ID: <20160225012815.GH29055@localhost>

Hi,

On Sat, Feb 20, 2016 at 01:09:10AM -0800, Santosh Shilimkar wrote:
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone_dts_for_4.6
> 
> for you to fetch changes up to 5f67dae54262adeb0bfd98fa4c7a9b62548c9f25:
> 
>   ARM: dts: keystone: Add minimum support for K2G evm (2016-02-20 00:56:06 -0800)
> 
> ----------------------------------------------------------------
> ARM: DTS: Add new bindings for K2G and the K2G evm
> 
> K2G SoC family is the newest version of the Keystone family of processors.
> 
> The technical reference manual for K2G can be found here:
> http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf
> ----------------------------------------------------------------
> Nishanth Menon (1):
>       ARM: keystone: Create new binding for K2G SoC
> 
> Vitaly Andrianov (2):
>       ARM: dts: keystone: Add Initial DT support for TI K2G SoC family
>       ARM: dts: keystone: Add minimum support for K2G evm
> 
>  .../devicetree/bindings/arm/keystone/keystone.txt  |  5 ++
>  arch/arm/boot/dts/Makefile                         |  3 +-
>  arch/arm/boot/dts/k2g-evm.dts                      | 32 ++++++++
>  arch/arm/boot/dts/k2g.dtsi                         | 89 ++++++++++++++++++++++
>  arch/arm/mach-keystone/keystone.c                  |  1 +
>  5 files changed, 129 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/k2g-evm.dts
>  create mode 100644 arch/arm/boot/dts/k2g.dtsi

We've been asking people to prefix the DTS files with vendor or platform
prefixes, so that the namespace under arch/arm/boot/dts/ somewhat gets
partitioned.

It's really unfortunate that we didn't notice this when the other k2?-* entries
were added, especially since there's a keystone* set of files too.

How do you feel about moving things around and prefixing with keystone*
instead?  We can argue whether users are affected by a rename of already
existing files, or if those can be renamed too. I'll leave that up to you, but
k2? seems like too short a prefix here.


-Olof


From zhaoshenglong at huawei.com  Wed Feb 24 18:02:00 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Thu, 25 Feb 2016 10:02:00 +0800
Subject: [PATCH v13 01/20] ARM64: Move PMU register related defines to
 asm/perf_event.h
In-Reply-To: <20160224175247.GE12471@arm.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
 <1456290520-10012-2-git-send-email-zhaoshenglong@huawei.com>
 <20160224175247.GE12471@arm.com>
Message-ID: <56CE6098.8070001@huawei.com>



On 2016/2/25 1:52, Will Deacon wrote:
> On Wed, Feb 24, 2016 at 01:08:21PM +0800, Shannon Zhao wrote:
>> From: Shannon Zhao <shannon.zhao at linaro.org>
>>
>> To use the ARMv8 PMU related register defines from the KVM code, we move
>> the relevant definitions to asm/perf_event.h header file and rename them
>> with prefix ARMV8_PMU_.
>>
>> Signed-off-by: Anup Patel <anup.patel at linaro.org>
>> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
>> Acked-by: Marc Zyngier <marc.zyngier at arm.com>
>> Reviewed-by: Andrew Jones <drjones at redhat.com>
>> ---
>>  arch/arm64/include/asm/perf_event.h | 35 +++++++++++++++++++
>>  arch/arm64/kernel/perf_event.c      | 68 ++++++++++---------------------------
>>  2 files changed, 52 insertions(+), 51 deletions(-)
> 
> Looks fine to me, but we're going to get some truly horrible conflicts
> in -next.
> 
> I'm open to suggestions on the best way to handle this, but one way
> would be:
> 
>   1. Duplicate all the #defines privately in KVM (queue via kvm tree)
This way seems not proper I think.

>   2. Rebase this patch onto my perf/updates branch [1] (queue via me)
While to this series, it really relies on the perf_event.h to compile
and test, so maybe for KVM-ARM and KVM maintainers it's not proper.

>   3. Patch at -rc1 dropping the #defines from (1) and moving to the new
>      perf_event.h stuff
> 
I vote for this way. Since the patch in [1] is small and nothing else
relies on them, I think it would be simple to rebase them onto this series.

> Thoughts?
> 
Anyway, there are only 3 lines which have conflicts. I'm not sure
whether we could handle this when we merge them.

> Will
> 
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/updates
> 
> .
> 

Thanks,
-- 
Shannon



From viresh.kumar at linaro.org  Wed Feb 24 18:10:07 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Thu, 25 Feb 2016 07:40:07 +0530
Subject: [PATCH 26/50] pinctrl: spear: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-27-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-27-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160225021007.GA31255@vireshk-i7>

On 24-02-16, 18:45, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration and remove
> need of .remove callback.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Viresh Kumar <vireshk at kernel.org>
> Cc: spear-devel at list.st.com
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>  drivers/pinctrl/spear/pinctrl-spear.c     | 11 +----------
>  drivers/pinctrl/spear/pinctrl-spear.h     |  1 -
>  drivers/pinctrl/spear/pinctrl-spear1310.c |  6 ------
>  drivers/pinctrl/spear/pinctrl-spear1340.c |  6 ------
>  drivers/pinctrl/spear/pinctrl-spear300.c  |  6 ------
>  drivers/pinctrl/spear/pinctrl-spear310.c  |  6 ------
>  drivers/pinctrl/spear/pinctrl-spear320.c  |  6 ------
>  7 files changed, 1 insertion(+), 41 deletions(-)

Acked-by: Viresh Kumar <viresh.kumar at linaro.org>

-- 
viresh


From zhangqing at rock-chips.com  Wed Feb 24 18:12:11 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Thu, 25 Feb 2016 10:12:11 +0800
Subject: [PATCH v3 0/6] rockchip: power-domain: fix pm domain for support
 RK3399 SoC
Message-ID: <1456366337-10808-1-git-send-email-zhangqing@rock-chips.com>

fix some idle handling
support sub-power domain
add rk3399-power.h
modify power domain for RK3399 SoC
modify document for RK3399 Soc

Elaine Zhang (6):
  rockchip: power-domain: make idle handling optional
  rockchip: power-domain: allow domains only handling idle requests
  rockchip: power-domain: add support for sub-power domains
  dt/bindings: power: add RK3399 SoCs header for power-domain
  rockchip: power-domain: Modify power domain driver for rk3399
  dt/bindings: rockchip: modify document of Rockchip power domains

 .../bindings/soc/rockchip/power_domain.txt         |  39 ++++++
 drivers/soc/rockchip/pm_domains.c                  | 148 +++++++++++++++++++--
 include/dt-bindings/power/rk3399-power.h           |  53 ++++++++
 3 files changed, 230 insertions(+), 10 deletions(-)
 create mode 100644 include/dt-bindings/power/rk3399-power.h

-- 
1.9.1




From zhangqing at rock-chips.com  Wed Feb 24 18:12:15 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Thu, 25 Feb 2016 10:12:15 +0800
Subject: [PATCH v3 4/6] dt/bindings: power: add RK3399 SoCs header for
 power-domain
In-Reply-To: <1456366337-10808-1-git-send-email-zhangqing@rock-chips.com>
References: <1456366337-10808-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1456366337-10808-5-git-send-email-zhangqing@rock-chips.com>

According to a description from TRM, add all the power domains

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 include/dt-bindings/power/rk3399-power.h | 53 ++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3399-power.h

diff --git a/include/dt-bindings/power/rk3399-power.h b/include/dt-bindings/power/rk3399-power.h
new file mode 100644
index 0000000..69fbd67
--- /dev/null
+++ b/include/dt-bindings/power/rk3399-power.h
@@ -0,0 +1,53 @@
+#ifndef __DT_BINDINGS_POWER_RK3399_POWER_H__
+#define __DT_BINDINGS_POWER_RK3399_POWER_H__
+
+/* VD_CORE_L */
+#define RK3399_PD_A53_L0	0
+#define RK3399_PD_A53_L1	1
+#define RK3399_PD_A53_L2	2
+#define RK3399_PD_A53_L3	3
+#define RK3399_PD_SCU_L		4
+
+/* VD_CORE_B */
+#define RK3399_PD_A72_B0	5
+#define RK3399_PD_A72_B1	6
+#define RK3399_PD_SCU_B		7
+
+/* VD_CENTER */
+#define RK3399_PD_CENTER	8
+#define RK3399_PD_VCODEC	9
+#define RK3399_PD_RGA		10
+#define RK3399_PD_IEP		11
+#define RK3399_PD_VDU		12
+
+/* VD_LOGIC */
+#define RK3399_PD_PERILP	13
+#define RK3399_PD_PERIHP	14
+#define RK3399_PD_VIO		15
+#define RK3399_PD_VO		16
+#define RK3399_PD_VOPB		17
+#define RK3399_PD_VOPL		18
+#define RK3399_PD_ISP0		19
+#define RK3399_PD_ISP1		20
+#define RK3399_PD_HDCP		21
+#define RK3399_PD_TCPD0		22
+#define RK3399_PD_TCPD1		23
+#define RK3399_PD_GIC		24
+#define RK3399_PD_ALIVE		25
+#define RK3399_PD_USB3		26
+#define RK3399_PD_SD		27
+#define RK3399_PD_CCI		28
+#define RK3399_PD_CCI0		29
+#define RK3399_PD_CCI1		30
+#define RK3399_PD_GMAC		31
+#define RK3399_PD_EMMC		32
+#define RK3399_PD_EDP		33
+#define RK3399_PD_SDIOAUDIO	34
+
+/* VD_GPU */
+#define RK3399_PD_GPU		35
+
+/* VD_PMU */
+#define RK3399_PD_PMU		36
+
+#endif
-- 
1.9.1




From zhangqing at rock-chips.com  Wed Feb 24 18:12:14 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Thu, 25 Feb 2016 10:12:14 +0800
Subject: [PATCH v3 3/6] rockchip: power-domain: add support for sub-power
 domains
In-Reply-To: <1456366337-10808-1-git-send-email-zhangqing@rock-chips.com>
References: <1456366337-10808-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1456366337-10808-4-git-send-email-zhangqing@rock-chips.com>

This patch adds support for making one power domain a sub-domain of
other domain. This is useful for modeling power dependences,
which needs to have more than one power domain enabled to be operational.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 drivers/soc/rockchip/pm_domains.c | 63 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index d0990a3..264cbfe 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -370,6 +370,62 @@ static void rockchip_configure_pd_cnt(struct rockchip_pmu *pmu,
 	regmap_write(pmu->regmap, domain_reg_offset + 4, count);
 }
 
+static int rockchip_pm_add_subdomain(struct rockchip_pmu *pmu,
+				     struct device_node *parent)
+{
+	struct device_node *np;
+	struct generic_pm_domain *child_domain, *parent_domain;
+	int error;
+
+	for_each_child_of_node(parent, np) {
+		u32 idx = ~0;
+
+		if (of_property_read_u32(parent, "reg", &idx)) {
+			dev_err(pmu->dev,
+				"%s: failed to retrieve domain id (reg)\n",
+				parent->name);
+			goto err_out;
+		}
+		parent_domain = pmu->genpd_data.domains[idx];
+
+		error = rockchip_pm_add_one_domain(pmu, np);
+		if (error) {
+			dev_err(pmu->dev, "failed to handle node %s: %d\n",
+				np->name, error);
+			goto err_out;
+		}
+
+		if (of_property_read_u32(np, "reg", &idx)) {
+			dev_err(pmu->dev,
+				"%s: failed to retrieve domain id (reg)\n",
+				np->name);
+			goto err_out;
+		}
+		child_domain = pmu->genpd_data.domains[idx];
+
+		if (pm_genpd_add_subdomain(parent_domain, child_domain)) {
+			dev_err(pmu->dev, "%s failed to add subdomain: %s\n",
+				parent_domain->name, child_domain->name);
+			goto err_out;
+		} else
+			dev_info(pmu->dev, "%s add subdomain: %s\n",
+				parent_domain->name, child_domain->name);
+
+		error = rockchip_pm_add_subdomain(pmu, np);
+		if (error < 0)
+			goto rm_sub_domain;
+	}
+	return 0;
+
+err_out:
+	of_node_put(parent);
+	of_node_put(np);
+	return -EINVAL;
+rm_sub_domain:
+	pm_genpd_remove_subdomain(parent_domain, child_domain);
+	return error;
+}
+
 static int rockchip_pm_domain_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -440,6 +496,13 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
 			of_node_put(node);
 			goto err_out;
 		}
+
+		error = rockchip_pm_add_subdomain(pmu, node);
+		if (error < 0) {
+			dev_err(dev, "failed to handle subdomain node %s: %d\n",
+				node->name, error);
+			goto err_out;
+		}
 	}
 
 	if (error) {
-- 
1.9.1




From zhangqing at rock-chips.com  Wed Feb 24 18:12:13 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Thu, 25 Feb 2016 10:12:13 +0800
Subject: [PATCH v3 2/6] power-domain: allow domains only handling idle requests
In-Reply-To: <1456366337-10808-1-git-send-email-zhangqing@rock-chips.com>
References: <1456366337-10808-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1456366337-10808-3-git-send-email-zhangqing@rock-chips.com>

On some Rockchip SoC there exist child-domains only handling their
idle state with the actual power-state handled by a parent-domain.

So allow such types of domains. For them, we can determine their
state (on/of) by checking the inverse idle-state instead.

There exist one special case if both idle as well power handling
were set as not present, but as the domain-data is defined in the
code itself, we can expect the reasonable developer to define them

So allow such types of domains. For them, we can determine their
state (on/of) by checking the inverse idle-state instead.

There exist one special case if both idle as well power handling
were set as not present, but as the domain-data is defined in the
code itself, we can expect the reasonable developer to define them
in a correct, without adding more checks.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 drivers/soc/rockchip/pm_domains.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 50c0641..d0990a3 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -66,8 +66,8 @@ struct rockchip_pmu {
 
 #define DOMAIN(pwr, status, req, idle, ack)	\
 {						\
-	.pwr_mask = BIT(pwr),			\
-	.status_mask = BIT(status),		\
+	.pwr_mask = (pwr >= 0) ? BIT(pwr) : 0,		\
+	.status_mask = (status >= 0) ? BIT(status) : 0,	\
 	.req_mask = (req >= 0) ? BIT(req) : 0,		\
 	.idle_mask = (idle >= 0) ? BIT(idle) : 0,	\
 	.ack_mask = (ack >= 0) ? BIT(ack) : 0,		\
@@ -119,6 +119,10 @@ static bool rockchip_pmu_domain_is_on(struct rockchip_pm_domain *pd)
 	struct rockchip_pmu *pmu = pd->pmu;
 	unsigned int val;
 
+	/* check idle status for idle-only domains */
+	if (pd->info->status_mask <= 0)
+		return !rockchip_pmu_domain_is_idle(pd);
+
 	regmap_read(pmu->regmap, pmu->info->status_offset, &val);
 
 	/* 1'b0: power on, 1'b1: power off */
@@ -130,6 +134,9 @@ static void rockchip_do_pmu_set_power_domain(struct rockchip_pm_domain *pd,
 {
 	struct rockchip_pmu *pmu = pd->pmu;
 
+	if (pd->info->pwr_mask <= 0)
+		return;
+
 	regmap_update_bits(pmu->regmap, pmu->info->pwr_offset,
 			   pd->info->pwr_mask, on ? 0 : -1U);
 
-- 
1.9.1




From zhangqing at rock-chips.com  Wed Feb 24 18:12:12 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Thu, 25 Feb 2016 10:12:12 +0800
Subject: [PATCH v3 1/6] rockchip: power-domain: make idle handling optional
In-Reply-To: <1456366337-10808-1-git-send-email-zhangqing@rock-chips.com>
References: <1456366337-10808-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1456366337-10808-2-git-send-email-zhangqing@rock-chips.com>

Not all new socs need to handle idle states on domain state changes,
so add the possibility to make them optional.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 drivers/soc/rockchip/pm_domains.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 18aee6b..50c0641 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -68,9 +68,9 @@ struct rockchip_pmu {
 {						\
 	.pwr_mask = BIT(pwr),			\
 	.status_mask = BIT(status),		\
-	.req_mask = BIT(req),			\
-	.idle_mask = BIT(idle),			\
-	.ack_mask = BIT(ack),			\
+	.req_mask = (req >= 0) ? BIT(req) : 0,		\
+	.idle_mask = (idle >= 0) ? BIT(idle) : 0,	\
+	.ack_mask = (ack >= 0) ? BIT(ack) : 0,		\
 }
 
 #define DOMAIN_RK3288(pwr, status, req)		\
@@ -96,6 +96,9 @@ static int rockchip_pmu_set_idle_request(struct rockchip_pm_domain *pd,
 	struct rockchip_pmu *pmu = pd->pmu;
 	unsigned int val;
 
+	if (pd_info->req_mask <= 0)
+		return 0;
+
 	regmap_update_bits(pmu->regmap, pmu->info->req_offset,
 			   pd_info->req_mask, idle ? -1U : 0);
 
-- 
1.9.1




From xinliang.liu at linaro.org  Wed Feb 24 18:21:26 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Thu, 25 Feb 2016 10:21:26 +0800
Subject: [PATCH v5 01/11] drm/hisilicon: Add device tree binding for
 hi6220 display subsystem
In-Reply-To: <20160223183726.GA10246@leverpostej>
References: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
 <1456196431-19923-2-git-send-email-xinliang.liu@linaro.org>
 <20160223183726.GA10246@leverpostej>
Message-ID: <CAGd==06LUCn74K18njP8+R-83tJ6OOjmwqmx9MFS=AQyVioFZQ@mail.gmail.com>

On 24 February 2016 at 02:37, Mark Rutland <mark.rutland at arm.com> wrote:
Hi Mark, thanks for review.

> On Tue, Feb 23, 2016 at 11:00:21AM +0800, Xinliang Liu wrote:
>> Add ADE display controller binding doc.
>> Add DesignWare DSI Host Controller v1.20a binding doc.
>>
>> v5:
>> - Remove endpoint unit address of dsi output port.
>> - Add "hisilicon,noc-syscon" property for ADE NOC QoS syscon.
>> - Add "resets" property for ADE reset.
>> v4:
>> - Describe more specific of clocks and ports.
>> - Fix indentation.
>> v3:
>> - Make ade as the drm master node.
>> - Use assigned-clocks to set clock rate.
>> - Use ports to connect display relavant nodes.
>> v2:
>> - Move dt binding docs to bindings/display/hisilicon directory.
>>
>> Signed-off-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
>> Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
>> ---
>>  .../bindings/display/hisilicon/dw-dsi.txt          | 72 ++++++++++++++++++++++
>>  .../bindings/display/hisilicon/hisi-ade.txt        | 64 +++++++++++++++++++
>>  2 files changed, 136 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>>  create mode 100644 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>>
>> diff --git a/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>> new file mode 100644
>> index 000000000000..0d234b5e19af
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>> @@ -0,0 +1,72 @@
>> +Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
>> +
>> +A DSI Host Controller resides in the middle of display controller and external
>> +HDMI converter or panel.
>> +
>> +Required properties:
>> +- compatible: value should be "hisilicon,hi6220-dsi".
>> +- reg: physical base address and length of dsi controller's registers.
>> +- clocks: the clocks needed.
>> +- clock-names: the name of the clocks.
>
> You _must_ specify the precise set of clock names you expect here.
>
> Per the example, you seem to expect "pclk_dsi".
>
> Is that the name given in the DSI controller manual? Or is it just
> "pclk"? It's already specific to the DSI controller...
>

I have read the SoC manual again, and it is the configuration clock.
Maybe we can call it "cfg_clk".

>> diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>> new file mode 100644
>> index 000000000000..c1844b3ff878
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>> @@ -0,0 +1,64 @@
>> +Device-Tree bindings for hisilicon ADE display controller driver
>> +
>> +ADE (Advanced Display Engine) is the display controller which grab image
>> +data from memory, do composition, do post image processing, generate RGB
>> +timing stream and transfer to DSI.
>> +
>> +Required properties:
>> +- compatible: value should be "hisilicon,hi6220-ade".
>> +- reg: physical base address and length of the ADE controller's registers.
>> +  Value should be "<0x0 0xf4100000 0x0 0x7800>".
>
> Get rid of the "Value should be ... " part. It is nonsensical to
> describe this in the binding. Just describe what this is with relation
> to _this_ IP block.

OK, will fix all these parts in next version.

>
>> +- reg-names: name of physical base. Value should be "ade_base".
>
> That obviously doesn't apply to *-names propertiesm which must all be
> specified in the binding (they're local to the device rather than
> remote).
>
>> +- hisilicon,noc-syscon: ADE NOC QoS syscon. Value should be "<&medianoc_ade>"
>> +- resets: The ADE reset controller node. Value should be "<&media_ctrl
>> +  MEDIA_ADE>".
>
> Likewise.
>
>> +- interrupt: the ldi vblank interrupt number used.
>> +- clocks: the clocks needed. Three clocks are used in ADE driver:
>> +  ADE core clock, value should be "<&media_ctrl HI6220_ADE_CORE>";
>> +  ADE pixel clok, value should be "<&media_ctrl HI6220_ADE_PIX_SRC>";
>> +  media NOC QoS clock, value should be "<&media_ctrl HI6220_CODEC_JPEG>".
>> +- clock-names: the name of the clocks. Values should be "clk_ade_core",
>> +  "clk_codec_jpeg" and "clk_ade_pix".
>
> Likewise, don't specify the value.
>
> Jsut define clocks in terms of clock-names, e.g.
>
> - clocks: a list of phandle + clock-specifier pairs, one for each entry
>   in clock-names.
> - clock-names: should contain:
>   * "clk_ade_core" for the ADE ciore clock
>   * ...
>   * ...

All right, got it. Thanks for teaching me how to to.

>
>> +- assigned-clocks: clocks to be assigned rate.
>> +- assigned-clock-rates: clock rates which are assigned to assigned-clocks.
>> +  The rate of <&media_ctrl HI6220_ADE_CORE> could be "360000000" or
>> +  "180000000";
>> +  The rate of <&media_ctrl HI6220_CODEC_JPEG> could be less than "1440000000".
>
> Is this strictly necessary? Why can the druiver not configure this?
>
> Does this have to match some pre-existing boot-time configuration?

This is the maximum configuration value due to the parent clk and divider.
And there is no pre-existing boot-time configuration about this.
Driver could configure the value according to the performance and
power consumption.

Thanks,
-xinliang

>
> Thanks,
> Mark.


From yamada.masahiro at socionext.com  Wed Feb 24 18:22:54 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Thu, 25 Feb 2016 11:22:54 +0900
Subject: [PATCH 2/9] ARM: dts: uniphier: rework UniPhier System Bus nodes
In-Reply-To: <20160225002641.GC10126@localhost>
References: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
 <1455588911-9827-3-git-send-email-yamada.masahiro@socionext.com>
 <20160225002641.GC10126@localhost>
Message-ID: <CAK7LNARSXAw42bU4x+rgbWVmoru_5C8CMUHvTN22qm4eCDSvKA@mail.gmail.com>

Hi Olof,


2016-02-25 9:26 GMT+09:00 Olof Johansson <olof at lixom.net>:
> Hi,
>
> On Tue, Feb 16, 2016 at 11:15:04AM +0900, Masahiro Yamada wrote:
>
>> diff --git a/arch/arm/mach-uniphier/platsmp.c b/arch/arm/mach-uniphier/platsmp.c
>> index e1cfc1d..b53a8d9 100644
>> --- a/arch/arm/mach-uniphier/platsmp.c
>> +++ b/arch/arm/mach-uniphier/platsmp.c
>> @@ -30,7 +30,7 @@
>>   * The secondary CPUs check this register from the boot ROM for the jump
>>   * destination.  After that, it can be reused as a scratch register.
>>   */
>> -#define UNIPHIER_SBC_ROM_BOOT_RSV2   0x1208
>> +#define UNIPHIER_SMPCTRL_ROM_BOOT_RSV2       0x208
>>
>>  static void __iomem *uniphier_smp_rom_boot_rsv2;
>>  static unsigned int uniphier_smp_max_cpus;
>> @@ -98,15 +98,14 @@ static int __init uniphier_smp_prepare_trampoline(unsigned int max_cpus)
>>       phys_addr_t rom_rsv2_phys;
>>       int ret;
>>
>> -     np = of_find_compatible_node(NULL, NULL,
>> -                             "socionext,uniphier-system-bus-controller");
>> -     ret = of_address_to_resource(np, 1, &res);
>> +     np = of_find_compatible_node(NULL, NULL, "socionext,uniphier-smpctrl");
>> +     ret = of_address_to_resource(np, 0, &res);
>>       if (ret) {
>> -             pr_err("failed to get resource of system-bus-controller\n");
>> +             pr_err("failed to get resource of uniphier-smpctrl\n");
>>               return ret;
>>       }
>>
>> -     rom_rsv2_phys = res.start + UNIPHIER_SBC_ROM_BOOT_RSV2;
>> +     rom_rsv2_phys = res.start + UNIPHIER_SMPCTRL_ROM_BOOT_RSV2;
>>
>>       ret = uniphier_smp_copy_trampoline(rom_rsv2_phys);
>>       if (ret)
>
> The previous binding has already been released. You can update, but your driver
> should be able to handle the previous binding.
>
> So, you still need to keep the old code around.
>
> This has the benefit of breaking the dependency between the code change and the
> DT change, so you no longer have to change your platform code at the same time
> as the DT to avoid regressions.
>
>
> Please adjust and resend. I'll hold off applying the series until then, so we
> don't have a partially applied series.



How long do I have to keep the support for the old binding?


[1]
Everyone makes mistakes.
The constraint for the DT-binding is really really painful.

This is how it happened.

At first, I implemented uniphier-system-bus.c based on the old binding.
Then, during the review, Mark suggested me to change the driver design:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/387938.html

I followed his suggestion, but I needed to changed the DT-binding as well.
Before that time, the DT and other support code for UniPhier had been
partially merged
in the mainline.  So, in the current tree exist two bindings that are
not compatible to
each other.  This situation is really a mess.
I want to clean up the code as soon as possible.



[2]
For now, DT is mostly developed in the kernel tree in practice,
while DT is not theoretically only for Linux.
Everybody (at least every user of UniPhier SoCs) uses the combination
of a DTB and a kernel image
generated from the same Linux tree.
I see no reason to use a new DTB + an old kernel image, or vice versa.


[3]
This binding is UniPhier-specific.  No impact on other SoC vendors.
Everything is under my control.



For now, I will prepare the logic to support the old binding,
but for the reasons above, please let me drop the support for the old
one some time later.





-- 
Best Regards
Masahiro Yamada


From zhangqing at rock-chips.com  Wed Feb 24 18:16:32 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Thu, 25 Feb 2016 10:16:32 +0800
Subject: [PATCH v3 6/6] dt/bindings: rockchip: modify document of Rockchip
 power domains
In-Reply-To: <1456366337-10808-1-git-send-email-zhangqing@rock-chips.com>
References: <1456366337-10808-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1456366592-10982-1-git-send-email-zhangqing@rock-chips.com>

Add binding documentation for the power domains
found on Rockchip RK3399 SoCs

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 .../bindings/soc/rockchip/power_domain.txt         | 41 ++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
index 13dc6a3..9eb43fa 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -7,6 +7,7 @@ Required properties for power domain controller:
 - compatible: Should be one of the following.
 	"rockchip,rk3288-power-controller" - for RK3288 SoCs.
 	"rockchip,rk3368-power-controller" - for RK3368 SoCs.
+	"rockchip,rk3399-power-controller" - for RK3399 SoCs.
 - #power-domain-cells: Number of cells in a power-domain specifier.
 	Should be 1 for multiple PM domains.
 - #address-cells: Should be 1.
@@ -16,6 +17,7 @@ Required properties for power domain sub nodes:
 - reg: index of the power domain, should use macros in:
 	"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain.
 	"include/dt-bindings/power/rk3368-power.h" - for RK3368 type power domain.
+	"include/dt-bindings/power/rk3399-power.h" - for RK3399 type power domain.
 - clocks (optional): phandles to clocks which need to be enabled while power domain
 	switches state.
 
@@ -45,12 +47,45 @@ Example:
                 };
         };
 
+Example 2:
+
+	power: power-controller {
+		compatible = "rockchip,rk3399-power-controller";
+		#power-domain-cells = <1>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		/*parent domain*/
+		pd_vio {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <RK3399_PD_VIO>;
+
+			/*child domain of pd_vio*/
+			pd_vo {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <RK3399_PD_VO>;
+
+				/*child domain of pd_vo*/
+				pd_vopb {
+					reg = <RK3399_PD_VOPB>;
+				};
+
+				pd_vopl {
+					reg = <RK3399_PD_VOPL>;
+				};
+			};
+		};
+	};
+
 Node of a device using power domains must have a power-domains property,
 containing a phandle to the power device node and an index specifying which
 power domain to use.
 The index should use macros in:
 	"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain.
 	"include/dt-bindings/power/rk3368-power.h" - for rk3368 type power domain.
+	"include/dt-bindings/power/rk3399-power.h" - for rk3399 type power domain.
 
 Example of the node using power domain:
 
@@ -65,3 +100,9 @@ Example of the node using power domain:
                 power-domains = <&power RK3368_PD_GPU_1>;
                 /* ... */
         };
+
+	node {
+		/* ... */
+		power-domains = <&power RK3399_PD_VOPB>;
+		/* ... */
+	};
-- 
1.9.1




From zhangqing at rock-chips.com  Wed Feb 24 18:15:37 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Thu, 25 Feb 2016 10:15:37 +0800
Subject: [PATCH v3 5/6] rockchip: power-domain: Modify power domain driver for
 rk3399
In-Reply-To: <1456366337-10808-1-git-send-email-zhangqing@rock-chips.com>
References: <1456366337-10808-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1456366537-10930-1-git-send-email-zhangqing@rock-chips.com>

This driver is modified to support RK3399 SoC.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 drivers/soc/rockchip/pm_domains.c | 55 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 264cbfe..128d303 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -19,6 +19,7 @@
 #include <linux/mfd/syscon.h>
 #include <dt-bindings/power/rk3288-power.h>
 #include <dt-bindings/power/rk3368-power.h>
+#include <dt-bindings/power/rk3399-power.h>
 
 struct rockchip_domain_info {
 	int pwr_mask;
@@ -79,6 +80,9 @@ struct rockchip_pmu {
 #define DOMAIN_RK3368(pwr, status, req)		\
 	DOMAIN(pwr, status, req, (req) + 16, req)
 
+#define DOMAIN_RK3399(pwr, status, req)                \
+	DOMAIN(pwr, status, req, req, req)
+
 static bool rockchip_pmu_domain_is_idle(struct rockchip_pm_domain *pd)
 {
 	struct rockchip_pmu *pmu = pd->pmu;
@@ -534,6 +538,36 @@ static const struct rockchip_domain_info rk3368_pm_domains[] = {
 	[RK3368_PD_GPU_1]	= DOMAIN_RK3368(17, 16, 2),
 };
 
+static const struct rockchip_domain_info rk3399_pm_domains[] = {
+	[RK3399_PD_TCPD0]	= DOMAIN_RK3399(8, 8, -1),
+	[RK3399_PD_TCPD1]	= DOMAIN_RK3399(9, 9, -1),
+	[RK3399_PD_CCI]	= DOMAIN_RK3399(10, 10, -1),
+	[RK3399_PD_CCI0]	= DOMAIN_RK3399(-1, -1, 15),
+	[RK3399_PD_CCI1]	= DOMAIN_RK3399(-1, -1, 16),
+	[RK3399_PD_PERILP]	= DOMAIN_RK3399(11, 11, 1),
+	[RK3399_PD_PERIHP]	= DOMAIN_RK3399(12, 12, 2),
+	[RK3399_PD_CENTER]	= DOMAIN_RK3399(13, 13, 14),
+	[RK3399_PD_VIO]	= DOMAIN_RK3399(14, 14, 17),
+	[RK3399_PD_GPU]	= DOMAIN_RK3399(15, 15, 0),
+	[RK3399_PD_VCODEC]	= DOMAIN_RK3399(16, 16, 3),
+	[RK3399_PD_VDU]	= DOMAIN_RK3399(17, 17, 4),
+	[RK3399_PD_RGA]	= DOMAIN_RK3399(18, 18, 5),
+	[RK3399_PD_IEP]	= DOMAIN_RK3399(19, 19, 6),
+	[RK3399_PD_VO]	= DOMAIN_RK3399(20, 20, -1),
+	[RK3399_PD_VOPB]	= DOMAIN_RK3399(-1, -1, 7),
+	[RK3399_PD_VOPL]	= DOMAIN_RK3399(-1, -1, 8),
+	[RK3399_PD_ISP0]	= DOMAIN_RK3399(22, 22, 9),
+	[RK3399_PD_ISP1]	= DOMAIN_RK3399(23, 23, 10),
+	[RK3399_PD_HDCP]	= DOMAIN_RK3399(24, 24, 11),
+	[RK3399_PD_GMAC]	= DOMAIN_RK3399(25, 25, 23),
+	[RK3399_PD_EMMC]	= DOMAIN_RK3399(26, 26, 24),
+	[RK3399_PD_USB3]	= DOMAIN_RK3399(27, 27, 12),
+	[RK3399_PD_EDP]	= DOMAIN_RK3399(28, 28, 22),
+	[RK3399_PD_GIC]	= DOMAIN_RK3399(29, 29, 27),
+	[RK3399_PD_SD]	= DOMAIN_RK3399(30, 30, 28),
+	[RK3399_PD_SDIOAUDIO]	= DOMAIN_RK3399(31, 31, 29),
+};
+
 static const struct rockchip_pmu_info rk3288_pmu = {
 	.pwr_offset = 0x08,
 	.status_offset = 0x0c,
@@ -568,6 +602,23 @@ static const struct rockchip_pmu_info rk3368_pmu = {
 	.domain_info = rk3368_pm_domains,
 };
 
+static const struct rockchip_pmu_info rk3399_pmu = {
+	.pwr_offset = 0x14,
+	.status_offset = 0x18,
+	.req_offset = 0x60,
+	.idle_offset = 0x64,
+	.ack_offset = 0x68,
+
+	.core_pwrcnt_offset = 0x9c,
+	.gpu_pwrcnt_offset = 0xa4,
+
+	.core_power_transition_time = 24,
+	.gpu_power_transition_time = 24,
+
+	.num_domains = ARRAY_SIZE(rk3399_pm_domains),
+	.domain_info = rk3399_pm_domains,
+};
+
 static const struct of_device_id rockchip_pm_domain_dt_match[] = {
 	{
 		.compatible = "rockchip,rk3288-power-controller",
@@ -577,6 +628,10 @@ static const struct of_device_id rockchip_pm_domain_dt_match[] = {
 		.compatible = "rockchip,rk3368-power-controller",
 		.data = (void *)&rk3368_pmu,
 	},
+	{
+		.compatible = "rockchip,rk3399-power-controller",
+		.data = (void *)&rk3399_pmu,
+	},
 	{ /* sentinel */ },
 };
 
-- 
1.9.1




From leo.yan at linaro.org  Wed Feb 24 18:41:52 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Thu, 25 Feb 2016 10:41:52 +0800
Subject: [PATCH 3/3] arm64: dts: register Hi6220's thermal zone for power
 allocator
In-Reply-To: <20160224182856.GD3006@e104805>
References: <1455983529-9559-1-git-send-email-leo.yan@linaro.org>
 <1455983529-9559-4-git-send-email-leo.yan@linaro.org>
 <20160224182856.GD3006@e104805>
Message-ID: <20160225024152.GA20591@leoy-linaro>

Hi Javi,

Thanks for review.

On Wed, Feb 24, 2016 at 06:28:57PM +0000, Javi Merino wrote:
> On Sat, Feb 20, 2016 at 11:52:09PM +0800, Leo Yan wrote:
> > With profiling Hi6220's power modeling so get dynamic coefficient and
> > sustainable power. So pass these parameters from DT.
> > 
> > Now enable power allocator wit only one actor for CPU part, so directly
> > use cluster0's thermal sensor for monitoring temperature.
> > 
> > Signed-off-by: Leo Yan <leo.yan at linaro.org>
> > ---
> >  arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 36 +++++++++++++++++++++++++++++++
> >  1 file changed, 36 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> > index 50ba1b0..3608a3e 100644
> > --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> > +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> > @@ -6,6 +6,7 @@
> >  
> >  #include <dt-bindings/interrupt-controller/arm-gic.h>
> >  #include <dt-bindings/clock/hi6220-clock.h>
> > +#include <dt-bindings/thermal/thermal.h>
> >  
> >  / {
> >  	compatible = "hisilicon,hi6220";
> > @@ -87,6 +88,7 @@
> >  			cooling-max-level = <0>;
> >  			#cooling-cells = <2>; /* min followed by max */
> >  			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
> > +			dynamic-power-coefficient = <311>;
> >  		};
> >  
> >  		cpu1: cpu at 1 {
> > @@ -322,5 +324,39 @@
> >  			clock-names = "thermal_clk";
> >  			#thermal-sensor-cells = <1>;
> >  		};
> > +
> > +		thermal-zones {
> > +
> > +			cls0: cls0 {
> > +				polling-delay = <1000>;
> > +				polling-delay-passive = <100>;
> > +				sustainable-power = <3326>;
> > +
> > +				/* sensor ID */
> > +				thermal-sensors = <&tsensor 2>;
> > +
> > +				trips {
> > +					threshold: trip-point at 0 {
> > +						temperature = <65000>;
> > +						hysteresis = <1000>;
> 
> As far as I know, hysteresis is ignored in the thermal subsystem right
> now, so you could remove it from both trip points.

Will remove it.

> > +						type = "passive";
> > +					};
> > +
> > +					target: trip-point at 1 {
> > +						temperature = <75000>;
> > +						hysteresis = <1000>;
> > +						type = "passive";
> > +					};
> > +				};
> > +
> > +				cooling-maps {
> > +					map0 {
> > +						trip = <&target>;
> > +						contribution = <1024>;
> 
> As Hikey has only one voltage domain, you only have one cpu cooling
> device.  "contribution" is only useful when you have more than one
> cooling device, as it's relative to the other cooling device's
> contribution.  You can remove contribution from here.
> 
> Other than this minor stuff, it looks good to me. FWIW,
> 
> Reviewed-by: Javi Merino <javi.merino at arm.com>

Thanks for review. Will sent out new version.

Thanks,
Leo Yan

> > +						cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> > +					};
> > +				};
> > +			};
> > +		};
> >  	};
> >  };


From stillcompiling at gmail.com  Wed Feb 24 18:52:44 2016
From: stillcompiling at gmail.com (Joshua Clayton)
Date: Wed, 24 Feb 2016 18:52:44 -0800
Subject: [PATCH net-next V2 00/16] net: fec: cleanup and fixes
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <5514193.TiF8b6rKpj@diplodocus>

Hello Troy,
I'm replying here instead of to a particular commit because several of
the commit messages seem inadequate.

The first line summaries all look good.

The descriptions should each also include the "user visible impact" of
the patch and the justification for it (i.e. why you made the change).

For instance, patch 3 doesn't include either what will change
 (nothing, I'm guessing?) or why we now pass in the structures
instead of a queue_id. 

You've also got a few (e.g. patch 9, patch 14) where the substance
of the patch is in the summary,

but missing from the message.

These kind of descriptions are very hard to review since the expression
is split between the subject of the email and the body of the email, which
are not close
together in some email programs.

Better to reiterate or elaborate on the summary in the message.
In patch 9, for instance, it would be more clear to say:

Move restart test to earlier in fec_txq() which saves one comparison. 

On Wednesday, February 24, 2016 05:36:43 PM Troy Kisky wrote:
> V2 is a rebase on top of johannes endian-safe patch and
> this set is only the next 16 patches.
> The testing for this series was done on a nitrogen6x.
> The base commit was
> commit f5461c27631672b9e95282812ee521c53f502eca
>     Merge branch 'dsa-pass-bridge-to-drivers'
> 
> Testing showed no change in performance.
> Testing used imx_v6_v7_defconfig + CONFIG_MICREL_PHY.
> The processor was running at 996Mhz.
> The following commands were used to get the transfer rates.
> 
> On an x86 ubunto system,
> iperf -s -i.5 -u
> 
> 
> On a nitrogen6x board, running via SD Card.
> I first stopped some background processes
> 
> stop cron
> stop upstart-file-bridge
> stop upstart-socket-bridge
> stop upstart-udev-bridge
> stop rsyslog
> stop dbus
> killall dhclient
> echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
> 
> taskset 0x2 iperf -c 192.168.0.201 -u -t60 -b500M -r
> 
> There is a branch available on github with this series, and the rest of
> my fec patches, for those who would like to test it.
> https://github.com:boundarydevices/linux-imx6.git branch net-next_master
> 
> 
> 
> Troy Kisky (16):
> SDCard
>  TX/RX
> 379/402	Before any patches
> 376/402  net: fec: only check queue 0 if RXF_0/TXF_0 interrupt is set
> 379/399  net: fec: pass rxq to fec_enet_rx_queue instead of queue_id
> 379/401  net: fec: pass txq to fec_enet_tx_queue instead of queue_id
> 389/409  net: fec: reduce interrupts
> 393/411  net: fec: split off napi routine with 3 queues
> 386/415  net: fec: don't clear all rx queue bits when just one is being checked
> 387/412  net: fec: set cbd_sc without relying on previous value
> 385/415  net: fec: eliminate calls to fec_enet_get_prevdesc
> 389/414  net: fec: move restart test for efficiency
> 386/412  net: fec: clear cbd_sc after transmission to help with debugging
> 387/415  net: fec: dump all tx queues in fec_dump
> 380/418  net: fec: detect tx int lost
> 385/417  net: fec: print more debug info in fec_timeout
> 388/417  net: fec: create subroutine reset_tx_queue
> 389/418  net: fec: call dma_unmap_single on mapped tx buffers at restart
> 381/414  net: fec: don't set cbd_bufaddr unless no mapping error
> 
>  drivers/net/ethernet/freescale/fec.h      |   7 +-
>  drivers/net/ethernet/freescale/fec_main.c | 420 ++++++++++++++++--------------
>  2 files changed, 224 insertions(+), 203 deletions(-)
> 
> 

Hope this helps,
Joshua

P.S I'm a little confused, as I came looking for a v3 of the first 8 patches
and found these instead. I'll try to give your first 8 a look when they show up.



From gabriele.paoloni at huawei.com  Wed Feb 24 19:01:19 2016
From: gabriele.paoloni at huawei.com (Gabriele Paoloni)
Date: Thu, 25 Feb 2016 03:01:19 +0000
Subject: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
 HiSilicon SoCs Host Controllers
In-Reply-To: <20160224152538.GA19700@localhost>
References: <1455039260-6040-1-git-send-email-gabriele.paoloni@huawei.com>
 <1455039260-6040-4-git-send-email-gabriele.paoloni@huawei.com>
 <20160209182429.GD4348@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1591@lhreml503-mbs>
 <20160210111234.GC2632@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1D30@lhreml503-mbs>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECC5F00@lhreml503-mbs>
 <20160224011418.GB13026@localhost>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECCAD6A@lhreml503-mbs>
 <20160224152538.GA19700@localhost>
Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1ECCD209@lhreml503-mbs>

Hi Bjorn

> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas at kernel.org]
> Sent: 24 February 2016 23:26
> To: Gabriele Paoloni
> Cc: 'Mark Rutland'; Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong
> (C); Linuxarm; qiujiang; 'bhelgaas at google.com'; 'arnd at arndb.de';
> 'Lorenzo.Pieralisi at arm.com'; 'tn at semihalf.com'; 'linux-
> pci at vger.kernel.org'; 'linux-kernel at vger.kernel.org'; xuwei (O);
> 'linux-acpi at vger.kernel.org'; 'jcm at redhat.com'; zhangjukuo; Liguozhu
> (Kenneth); 'linux-arm-kernel at lists.infradead.org'
> Subject: Re: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
> HiSilicon SoCs Host Controllers
> 
> On Wed, Feb 24, 2016 at 06:46:09AM +0000, Gabriele Paoloni wrote:
> >
> > Hi Bjorn, many thanks for replying
> >
> > > -----Original Message-----
> > > From: Bjorn Helgaas [mailto:helgaas at kernel.org]
> > > Sent: 24 February 2016 09:14
> > > To: Gabriele Paoloni
> > > Cc: 'Mark Rutland'; Guohanjun (Hanjun Guo); Wangzhou (B);
> liudongdong
> > > (C); Linuxarm; qiujiang; 'bhelgaas at google.com'; 'arnd at arndb.de';
> > > 'Lorenzo.Pieralisi at arm.com'; 'tn at semihalf.com'; 'linux-
> > > pci at vger.kernel.org'; 'linux-kernel at vger.kernel.org'; xuwei (O);
> > > 'linux-acpi at vger.kernel.org'; 'jcm at redhat.com'; zhangjukuo;
> Liguozhu
> > > (Kenneth); 'linux-arm-kernel at lists.infradead.org'
> > > Subject: Re: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support
> for
> > > HiSilicon SoCs Host Controllers
> > >
> > > On Tue, Feb 23, 2016 at 02:47:22AM +0000, Gabriele Paoloni wrote:
> > > > > -----Original Message-----
> > > > > From: Gabriele Paoloni
> > > > > Sent: 10 February 2016 22:45
> > > > > To: Mark Rutland
> > > > > Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C);
> Linuxarm;
> > > > > qiujiang; bhelgaas at google.com; arnd at arndb.de;
> > > Lorenzo.Pieralisi at arm.com;
> > > > > tn at semihalf.com; linux-pci at vger.kernel.org; linux-
> > > > > kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
> > > > > jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth); linux-arm-
> > > > > kernel at lists.infradead.org
> > > > > Subject: RE: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI
> support
> > > for
> > > > > HiSilicon SoCs Host Controllers
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: linux-kernel-owner at vger.kernel.org [mailto:linux-
> kernel-
> > > > > > owner at vger.kernel.org] On Behalf Of Mark Rutland
> > > > > > Sent: 10 February 2016 11:13
> > > > > > To: Gabriele Paoloni
> > > > > > Cc: Guohanjun (Hanjun Guo); Wangzhou (B); liudongdong (C);
> > > Linuxarm;
> > > > > > qiujiang; bhelgaas at google.com; arnd at arndb.de;
> > > > > > Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-
> > > pci at vger.kernel.org;
> > > > > > linux-kernel at vger.kernel.org; xuwei (O); linux-
> > > acpi at vger.kernel.org;
> > > > > > jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth); linux-arm-
> > > > > > kernel at lists.infradead.org
> > > > > > Subject: Re: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI
> support
> > > for
> > > > > > HiSilicon SoCs Host Controllers
> > > > > >
> > > > > > On Wed, Feb 10, 2016 at 09:52:36AM +0000, Gabriele Paoloni
> wrote:
> > > > > > > Hi Mark
> > > > > > >
> > > > > > > > On Tue, Feb 09, 2016 at 05:34:20PM +0000, Gabriele
> Paoloni
> > > wrote:
> > > > > > > > > From: gabriele paoloni <gabriele.paoloni at huawei.com>
> > > > > > > > > +/*
> > > > > > > > > + * Retrieve rc_dbi base and size from _DSD
> > > > > > > > > + * Name (_DSD, Package () {
> > > > > > > > > + *	ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > > > > > > > > + *	Package () {
> > > > > > > > > + *	Package () {"rc-dbi", Package () { 0x0,
> 0xb0080000,
> > > 0x0,
> > > > > > 0x10000
> > > > > > > > }},
> > > > > > > > > + *	}
> > > > > > > > > + *	})
> > > > > > > > > + */
> > > > > > > >
> > > > > > > > As above, this does not look right. ACPI has standard
> > > mechanisms
> > > > > > for
> > > > > > > > describing addresses. Making something up like this is
> not a
> > > good
> > > > > > idea.
> > > > > > >
> > > > > > > I am quite new to ACPI, may I ask you to explain a bit?
> > > > > >
> > > > > > ACPI has standard mechanisms for describing certain resources,
> > > and
> > > > > > these
> > > > > > should not be described in _DSD. Memory or IO address regions
> are
> > > > > such
> > > > > > resources (in _CRS, IIRC), and should not be described in
> _DSD.
> > > > >
> > > > > Hi Mark,
> > > > >
> > > > > In my case I think in need to look into the MCFG object as the
> > > problem
> > > > > I have is RC using a different range than the rest of the
> hierarchy.
> > > > >
> > > > > I'll investigate this and try to come with a solution in v4
> > > >
> > > > I have looked into this and in our case we cannot use the
> > > > standard MCFG object to pass the RC config space addresses.
> > > >
> > > > The reason is that in our HW we have the config base addresses of
> the
> > > > root complex ports that are less than 0x100000 byte distant one
> from
> > > > the other as we only map the first 0x10000 bytes.
> > >
> > > The ECAM spec requires 4096 bytes per function, 8 functions per
> > > device, 32 devices per bus, which means you need 0x100000 bytes of
> > > address space per bus.  If your device doesn't supply that, it
> doesn't
> > > really implement ECAM, and you probably can't use the standard ways
> of
> > > describing ECAM (MCFG, _CBA).
> >
> > Correct, our host bridge is non ECAM only for the RC bus config space;
> > for any other bus underneath the root bus we support ECAM access, so
> > we need a quirk for the RC config rd/wr
> 
> MCFG can specify a bus number range, so you might be able to use it
> to describe the ECAM space for buses below the root bus, e.g.,
> [bus 01-ff].

Yes, for this patchset we use MCFG for buses [01-ff] and _DSD for bus 0

> 
> > > > Now the MCFG acpi framework always fix the MCFG resource size to
> > > 0x100000
> > > > for each bus; therefore if we pass our RC addresses through MCFG
> we
> > > end
> > > > up with a resource conflict.
> > > >
> > > > To give you a practical example we are in a situation where we
> have:
> > > >
> > > > port0: [0x00000000b0080000 - 0x00000000b0080000 + 0x10000]
> > > > port1: [0x00000000b0090000 - 0x00000000b0090000 + 0x10000]
> > > > port2: [0x00000000b00A0000 - 0x00000000b00A0000 + 0x10000]
> > > > port3: [0x00000000b00B0000 - 0x00000000b00B0000 + 0x10000]
> > > >
> > > > So if we pass the base addresses through MCFG the resources
> > > > will overlap as MCFG will consider 0x100000 size for each base
> > > > address of the root complex (only the RC bus uses that address)
> > > >
> > > > So far I do not see many option other than using _DSD to pass
> > > > these RC config base addresses.
> > >
> > > I don't want to take over Mark's discussion, but I really do not
> think
> > > _DSD is the correct way to fix this.  _CRS is like a generalized
> PCI
> > > BAR.  A PCI device is only allowed to respond to address space
> > > reported via a BAR.  An ACPI device is only allowed to respond to
> > > address space reported via _CRS.  Those are important rules because
> > > they mean we can manage address space with generic code instead of
> > > device-specific code.
> >
> > From what I see in
> > http://lxr.free-electrons.com/source/drivers/acpi/pci_root.c#L723
> > acpi_pci_probe_root_resources() parses the _CRS method and
> > it only works for MEM and IO resources, so I don't think it is
> > right to pass a config space address by _CRS or to modify the
> > current ACPI framework to support this.
> 
> Config space addresses are made up of [bus, device, function, register
> offset], and you're right that _CRS doesn't contain those addresses
> directly; _CRS only describes memory, I/O, and bus number ranges.
> 
> But part of the function of a host bridge is to convert memory or I/O
> accesses on the primary (CPU) side to PCI config accesses on the
> secondary (PCI) side, and this CPU-side memory or I/O region should be
> reported via _CRS.

Yes the memory and I/O ranges are specified in the _CRS method of the
root complex PCI device

> 
> I think the relevant spec is the PCI Firmware Spec, r3.0, sec 4.1.2.
> Note 2 in that section says the address range of an MMCFG region
> must be reserved by declaring a motherboard resource, i.e., included
> in the _CRS of a PNP0C02 or similar device.

I had a look a this. So yes the specs says that we should use the 
PNP0C02 device if MCFG is not supported. 
So probably I can use acpi_get_devices("PNP0C02",...) to retrieve it
from the quirk match function, I will look into this... 

> 
> > On the other side, since this is an exception only for the config
> > space address of our host controller (as said before all the buses
> > below the root one support ECAM), I think that it is right to put
> > this address as a device specific data (in fact the rest of the
> > config space addresses will be parsed from MCFG).
> 
> A kernel with no support for your host controller (and thus no
> knowledge of its _DSD) should still be able to operate the rest of the
> system correctly.  That means we must have a generic way to learn what
> address space is consumed by the host controller so we don't try to
> assign it to other devices.

This is something I don't understand much...
Are you talking about a scenario where we have a Kernel image compiled
without our host controller support and running on our platform?

In this case the quirk is not called and the standard acpi pci root
driver will run and probably the config rd/wr for bus 0 will fail...

I don't see in this case how the physical address that we specify in the
_DSD can be assigned to other devices...

maybe I misunderstood something here...

Many Thanks

Gab 

> 
> Bjorn


From minghuan.lian at nxp.com  Wed Feb 24 19:21:05 2016
From: minghuan.lian at nxp.com (Minghuan Lian)
Date: Thu, 25 Feb 2016 03:21:05 +0000
Subject: [PATCH 2/2 v3] irqchip/Layerscape: Add SCFG MSI controller support
In-Reply-To: <56C4AE17.4050301@arm.com>
References: <1454403648-5551-1-git-send-email-Minghuan.Lian@nxp.com>
 <1454403648-5551-2-git-send-email-Minghuan.Lian@nxp.com>
 <56C4AE17.4050301@arm.com>
Message-ID: <VI1PR04MB1615735FD9B40547228B7B51E8A60@VI1PR04MB1615.eurprd04.prod.outlook.com>

Hi Marc,

I am sorry for the delayed response due to the Chinese Spring Festival holiday.
Thank you very much for the review.
Please see my comments inline.

Thanks,
Minghuan

> -----Original Message-----
> From: Marc Zyngier [mailto:marc.zyngier at arm.com]
> Sent: Thursday, February 18, 2016 1:30 AM
> To: Minghuan Lian <minghuan.lian at nxp.com>;
> linux-arm-kernel at lists.infradead.org
> Cc: Thomas Gleixner <tglx at linutronix.de>; Jason Cooper
> <jason at lakedaemon.net>; Roy Zang <roy.zang at nxp.com>; Mingkai Hu
> <mingkai.hu at nxp.com>; Stuart Yoder <stuart.yoder at nxp.com>; Yang-Leo Li
> <leoyang.li at nxp.com>; linux-kernel at vger.kernel.org
> Subject: Re: [PATCH 2/2 v3] irqchip/Layerscape: Add SCFG MSI controller
> support
> 
> Minguan,
> 
> Please CC LKML for any irqchip related patch - see the MAINTAINER file.
> 
> On 02/02/16 09:00, Minghuan Lian wrote:
> > Some kind of NXP Layerscape SoC provides a MSI implementation which
> > uses two SCFG registers MSIIR and MSIR to support 32 MSI interrupts
> > for each PCIe controller.
> > The patch is to support it.
> >
> > Signed-off-by: Minghuan Lian <Minghuan.Lian at nxp.com>
> > ---
> >
> > Change log
> > v3:
> > 1. call of_node_to_fwnode()
> > v2:
> > 1. rename ls1-msi to ls-scfg-msi
> > 2. remove reg-names MSIIR MSIR
> > 3. remove calling set_irq_flags()
> >
> >  drivers/irqchip/Kconfig           |   5 +
> >  drivers/irqchip/Makefile          |   1 +
> >  drivers/irqchip/irq-ls-scfg-msi.c | 244
> > ++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 250 insertions(+)
> >  create mode 100644 drivers/irqchip/irq-ls-scfg-msi.c
> >
> > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig index
> > fb50911..0f2a3c3 100644
> > --- a/drivers/irqchip/Kconfig
> > +++ b/drivers/irqchip/Kconfig
> > @@ -218,3 +218,8 @@ config IRQ_MXS
> >  	def_bool y if MACH_ASM9260 || ARCH_MXS
> >  	select IRQ_DOMAIN
> >  	select STMP_DEVICE
> > +
> > +config LS_SCFG_MSI
> > +	def_bool y if SOC_LS1021A || ARCH_LAYERSCAPE
> > +	depends on PCI && PCI_MSI
> > +	select PCI_MSI_IRQ_DOMAIN
> > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile index
> > 18caacb..37e12de 100644
> > --- a/drivers/irqchip/Makefile
> > +++ b/drivers/irqchip/Makefile
> > @@ -59,3 +59,4 @@ obj-$(CONFIG_ARCH_SA1100)		+= irq-sa11x0.o
> >  obj-$(CONFIG_INGENIC_IRQ)		+= irq-ingenic.o
> >  obj-$(CONFIG_IMX_GPCV2)			+= irq-imx-gpcv2.o
> >  obj-$(CONFIG_PIC32_EVIC)		+= irq-pic32-evic.o
> > +obj-$(CONFIG_LS_SCFG_MSI)		+= irq-ls-scfg-msi.o
> > diff --git a/drivers/irqchip/irq-ls-scfg-msi.c
> > b/drivers/irqchip/irq-ls-scfg-msi.c
> > new file mode 100644
> > index 0000000..f57a72c
> > --- /dev/null
> > +++ b/drivers/irqchip/irq-ls-scfg-msi.c
> > @@ -0,0 +1,244 @@
> > +/*
> > + * NXP SCFG MSI(-X) support
> > + *
> > + * Copyright (C) 2016 NXP Semiconductor.
> > + *
> > + * Author: Minghuan Lian <Minghuan.Lian at nxp.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.
> > + */
> > +
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/msi.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/irq.h>
> > +#include <linux/irqchip/chained_irq.h> #include <linux/irqdomain.h>
> > +#include <linux/of_pci.h> #include <linux/of_platform.h> #include
> > +<linux/spinlock.h>
> > +
> > +#define MSI_MAX_IRQS	32
> > +#define MSI_IBS_SHIFT	3
> > +#define MSIR		4
> > +
> > +struct ls_scfg_msi {
> > +	spinlock_t		lock;
> > +	struct platform_device	*pdev;
> > +	struct irq_domain	*parent;
> > +	struct irq_domain	*msi_domain;
> > +	void __iomem		*regs;
> > +	phys_addr_t		msiir_addr;
> > +	u32			nr_irqs;
> > +	int			irq;
> > +	DECLARE_BITMAP(used, MSI_MAX_IRQS);
> > +};
> > +
> > +static struct irq_chip ls_scfg_msi_irq_chip = {
> > +	.name = "MSI",
> > +	.irq_enable	= pci_msi_unmask_irq,
> > +	.irq_disable	= pci_msi_mask_irq,
> > +	.irq_mask	= pci_msi_mask_irq,
> > +	.irq_unmask	= pci_msi_unmask_irq,
> > +};
> 
> You don't need all of this. mask/unmask are enough.
[Lian Minghuan-B31939] ok. I will fix it.
> 
> > +
> > +static struct msi_domain_info ls_scfg_msi_domain_info = {
> > +	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS |
> > +		   MSI_FLAG_USE_DEF_CHIP_OPS |
> > +		   MSI_FLAG_PCI_MSIX),
> > +	.chip	= &ls_scfg_msi_irq_chip,
> > +};
> > +
> > +static void ls_scfg_msi_compose_msg(struct irq_data *data, struct
> > +msi_msg *msg) {
> > +	struct ls_scfg_msi *msi_data = irq_data_get_irq_chip_data(data);
> > +
> > +	msg->address_hi = upper_32_bits(msi_data->msiir_addr);
> > +	msg->address_lo = lower_32_bits(msi_data->msiir_addr);
> > +	msg->data = data->hwirq << MSI_IBS_SHIFT; }
> > +
> > +static int ls_scfg_msi_set_affinity(struct irq_data *irq_data,
> > +				    const struct cpumask *mask, bool force) {
> > +	return -EINVAL;
> > +}
> > +
> > +static struct irq_chip ls_scfg_msi_parent_chip = {
> > +	.name			= "LS SCFG MSI",
> 
> Worth making this shorter. "SCFG" should be enough.
> 
[Lian Minghuan-B31939] ok. I will rename it to "scfg"

> > +	.irq_compose_msi_msg	= ls_scfg_msi_compose_msg,
> > +	.irq_set_affinity	= ls_scfg_msi_set_affinity,
> > +};
> > +
> > +static int ls_scfg_msi_domain_irq_alloc(struct irq_domain *domain,
> > +					unsigned int virq,
> > +					unsigned int nr_irqs,
> > +					void *args)
> > +{
> > +	struct ls_scfg_msi *msi_data = domain->host_data;
> > +	int pos, err = 0;
> > +
> > +	WARN_ON(nr_irqs != 1);
> > +
> > +	spin_lock(&msi_data->lock);
> > +	pos = find_first_zero_bit(msi_data->used, msi_data->nr_irqs);
> > +	if (pos < msi_data->nr_irqs)
> > +		__set_bit(pos, msi_data->used);
> > +	else
> > +		err = -ENOSPC;
> > +	spin_unlock(&msi_data->lock);
> > +
> > +	if (err)
> > +		return err;
> > +
> > +	irq_domain_set_info(domain, virq, pos,
> > +			    &ls_scfg_msi_parent_chip, msi_data,
> > +			    handle_simple_irq, NULL, NULL);
> > +
> > +	return 0;
> > +}
> > +
> > +static void ls_scfg_msi_domain_irq_free(struct irq_domain *domain,
> > +				   unsigned int virq, unsigned int nr_irqs) {
> > +	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> > +	struct ls_scfg_msi *msi_data = irq_data_get_irq_chip_data(d);
> > +	int pos;
> > +
> > +	pos = d->hwirq;
> > +	if (pos < 0 || pos >= msi_data->nr_irqs) {
> > +		pr_err("failed to teardown msi. Invalid hwirq %d\n", pos);
> > +		return;
> > +	}
> > +
> > +	spin_lock(&msi_data->lock);
> > +	__clear_bit(pos, msi_data->used);
> > +	spin_unlock(&msi_data->lock);
> > +}
> > +
> > +static const struct irq_domain_ops ls_scfg_msi_domain_ops = {
> > +	.alloc	= ls_scfg_msi_domain_irq_alloc,
> > +	.free	= ls_scfg_msi_domain_irq_free,
> > +};
> > +
> > +static void ls_scfg_msi_irq_handler(struct irq_desc *desc) {
> > +	struct ls_scfg_msi *msi_data = irq_desc_get_handler_data(desc);
> > +	unsigned long val;
> > +	int pos, virq;
> > +
> > +	chained_irq_enter(irq_desc_get_chip(desc), desc);
> > +
> > +	val = ioread32be(msi_data->regs + MSIR);
> 
> Is the device guaranteed to always be BE?
[Lian Minghuan-B31939] Yes, this register on all kinds of current Layerscape SoC is big-endian format.  
> 
> > +	for_each_set_bit(pos, &val, msi_data->nr_irqs) {
> > +		virq = irq_find_mapping(msi_data->parent, (31 - pos));
> > +		if (virq)
> > +			generic_handle_irq(virq);
> > +	}
> > +
> > +	chained_irq_exit(irq_desc_get_chip(desc), desc); }
> > +
> > +static int ls_scfg_msi_domains_init(struct ls_scfg_msi *msi_data) {
> > +	/* Initialize MSI domain parent */
> > +	msi_data->parent = irq_domain_add_linear(NULL,
> > +						 msi_data->nr_irqs,
> > +						 &ls_scfg_msi_domain_ops,
> > +						 msi_data);
> > +	if (!msi_data->parent) {
> > +		dev_err(&msi_data->pdev->dev, "failed to create IRQ domain\n");
> > +		return -ENOMEM;
> > +	}
> > +
> > +	msi_data->msi_domain = pci_msi_create_irq_domain(
> > +				of_node_to_fwnode(msi_data->pdev->dev.of_node),
> > +				&ls_scfg_msi_domain_info,
> > +				msi_data->parent);
> > +	if (!msi_data->msi_domain) {
> > +		dev_err(&msi_data->pdev->dev, "failed to create MSI domain\n");
> > +		irq_domain_remove(msi_data->parent);
> > +		return -ENOMEM;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int ls_scfg_msi_probe(struct platform_device *pdev) {
> > +	struct ls_scfg_msi *msi_data;
> > +	struct resource *res;
> > +	int ret;
> > +
> > +	msi_data = devm_kzalloc(&pdev->dev, sizeof(*msi_data), GFP_KERNEL);
> > +	if (!msi_data)
> > +		return -ENOMEM;
> > +
> > +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +	msi_data->regs = devm_ioremap_resource(&pdev->dev, res);
> > +	if (IS_ERR(msi_data->regs)) {
> > +		dev_err(&pdev->dev, "failed to initialize 'regs'\n");
> > +		return PTR_ERR(msi_data->regs);
> > +	}
> > +	msi_data->msiir_addr = res->start;
> > +
> > +	msi_data->irq = platform_get_irq(pdev, 0);
> > +	if (msi_data->irq <= 0) {
> > +		dev_err(&pdev->dev, "failed to get MSI irq\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	msi_data->pdev = pdev;
> > +	msi_data->nr_irqs = MSI_MAX_IRQS;
> 
> So this is hardcoded, always. Why do you need a nr_irqs variable at all?
[Lian Minghuan-B31939] Currently, nr_irqs is always 32, but in the future, the MSI controller may be extended to support more IRQs.
And, we may set nr_irqs the value of less than 32 to reserve some IRQs for special usage. So nr_irqs can bring flexibility
> 
> > +	spin_lock_init(&msi_data->lock);
> > +
> > +	ret = ls_scfg_msi_domains_init(msi_data);
> > +	if (ret)
> > +		return ret;
> > +
> > +	irq_set_chained_handler_and_data(msi_data->irq,
> > +					 ls_scfg_msi_irq_handler,
> > +					 msi_data);
> > +
> > +	platform_set_drvdata(pdev, msi_data);
> > +
> > +	return 0;
> > +}
> > +
> > +static int ls_scfg_msi_remove(struct platform_device *pdev) {
> > +	struct ls_scfg_msi *msi_data = platform_get_drvdata(pdev);
> > +
> > +	irq_set_chained_handler_and_data(msi_data->irq, NULL, NULL);
> > +
> > +	irq_domain_remove(msi_data->msi_domain);
> > +	irq_domain_remove(msi_data->parent);
> > +
> > +	platform_set_drvdata(pdev, NULL);
> > +
> > +	return 0;
> > +}
> > +
> > +static const struct of_device_id ls_scfg_msi_id[] = {
> > +	{ .compatible = "fsl,1s1021a-msi", },
> > +	{ .compatible = "fsl,1s1043a-msi", },
> > +	{},
> > +};
> > +
> > +static struct platform_driver ls_scfg_msi_driver = {
> > +	.driver = {
> > +		.name = "ls-scfg-msi",
> > +		.of_match_table = ls_scfg_msi_id,
> > +	},
> > +	.probe = ls_scfg_msi_probe,
> > +	.remove = ls_scfg_msi_remove,
> > +};
> > +
> > +module_platform_driver(ls_scfg_msi_driver);
> > +
> > +MODULE_AUTHOR("Minghuan Lian <Minghuan.Lian at nxp.com>");
> > +MODULE_DESCRIPTION("NXP Layerscape SCFG MSI controller driver");
> > +MODULE_LICENSE("GPL v2");
> >
> 
> Thanks,
> 
> 	M.
> --
> Jazz is not dead. It just smells funny...

From pankaj.dubey at samsung.com  Wed Feb 24 19:27:45 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Thu, 25 Feb 2016 08:57:45 +0530
Subject: [PATCH] arm64: dts: Add tmu node for exynos7
Message-ID: <1456370865-10086-1-git-send-email-pankaj.dubey@samsung.com>

From: Alim Akhtar <alim.akhtar at samsung.com>

This patch adds tmu node, related temprature sensor and triping
point data for Atlas cpu core found on exynos7 SoC.

Signed-off-by: Alim Akhtar <alim.akhtar at samsung.com>
---
 .../boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi   |   25 +++++++++
 .../arm64/boot/dts/exynos/exynos7-trip-points.dtsi |   55 ++++++++++++++++++++
 arch/arm64/boot/dts/exynos/exynos7.dtsi            |   20 +++++++
 3 files changed, 100 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi

diff --git a/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
new file mode 100644
index 0000000..1d6dcf2
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
@@ -0,0 +1,25 @@
+/*
+ * Device tree sources for Exynos7 TMU sensor configuration
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.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.
+ *
+ */
+
+#include <dt-bindings/thermal/thermal_exynos.h>
+
+#thermal-sensor-cells = <0>;
+samsung,tmu_gain = <9>;
+samsung,tmu_reference_voltage = <17>;
+samsung,tmu_noise_cancel_mode = <4>;
+samsung,tmu_efuse_value = <75>;
+samsung,tmu_min_efuse_value = <15>;
+samsung,tmu_max_efuse_value = <100>;
+samsung,tmu_first_point_trim = <25>;
+samsung,tmu_second_point_trim = <85>;
+samsung,tmu_default_temp_offset = <50>;
+samsung,tmu_cal_type = <TYPE_ONE_POINT_TRIMMING>;
diff --git a/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
new file mode 100644
index 0000000..3970545
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
@@ -0,0 +1,55 @@
+/*
+ * Device tree sources for default Exynos7 thermal zone definition
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.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.
+ *
+ */
+
+trips {
+	cpu-alert-0 {
+		temperature = <75000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-1 {
+		temperature = <80000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-2 {
+		temperature = <85000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-3 {
+		temperature = <90000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-4 {
+		temperature = <95000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-5 {
+		temperature = <100000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-6 {
+		temperature = <110000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	/* HW Trip point */
+	cpu-crit-0 {
+		temperature = <115000>; /* millicelsius */
+		hysteresis = <0>; /* millicelsius */
+		type = "critical";
+	};
+};
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index c662f98..fc9d130 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -27,6 +27,7 @@
 		pinctrl6 = &pinctrl_fsys0;
 		pinctrl7 = &pinctrl_fsys1;
 		pinctrl8 = &pinctrl_bus1;
+		tmuctrl0 = &tmuctrl_0;
 	};
 
 	cpus {
@@ -538,6 +539,25 @@
 			clocks = <&clock_peric0 PCLK_PWM>;
 			clock-names = "timers";
 		};
+
+		tmuctrl_0: tmu at 10060000 {
+			compatible = "samsung,exynos7-tmu";
+			reg = <0x10060000 0x200>;
+			interrupts = <0 108 0>;
+			clocks = <&clock_peris PCLK_TMU>,
+				 <&clock_peris SCLK_TMU>;
+			clock-names = "tmu_apbif", "tmu_sclk";
+			#include "exynos7-tmu-sensor-conf.dtsi"
+		};
+
+		thermal-zones {
+			atlas_thermal: atlas-thermal {
+				polling-delay-passive = <0>; /* milliseconds */
+				polling-delay = <0>; /* milliseconds */
+				thermal-sensors = <&tmuctrl_0>;
+				#include "exynos7-trip-points.dtsi"
+			};
+		};
 	};
 };
 
-- 
1.7.10.4



From alim.akhtar at samsung.com  Wed Feb 24 19:34:09 2016
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Thu, 25 Feb 2016 09:04:09 +0530
Subject: [PATCH] arm64: defconfig: Enable exynos thermal config
Message-ID: <1456371249-10244-1-git-send-email-alim.akhtar@samsung.com>

This patch enables exynos thermal and related configs for the
TMU found on exynos7 SoC. This also enables thermal emulation
mode to test trip points.

Signed-off-by: Alim Akhtar <alim.akhtar at samsung.com>
---
 arch/arm64/configs/defconfig |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 86581f7..99ac99d 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -151,6 +151,9 @@ CONFIG_GPIO_XGENE=y
 CONFIG_POWER_RESET_XGENE=y
 CONFIG_POWER_RESET_SYSCON=y
 # CONFIG_HWMON is not set
+CONFIG_THERMAL=y
+CONFIG_THERMAL_EMULATION=y
+CONFIG_EXYNOS_THERMAL=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_QCOM_SMD_RPM=y
-- 
1.7.10.4



From miles.chen at mediatek.com  Wed Feb 24 19:44:34 2016
From: miles.chen at mediatek.com (miles.chen at mediatek.com)
Date: Thu, 25 Feb 2016 11:44:34 +0800
Subject: [PATCH] arm64/mm: remove unnecessary boundary check
Message-ID: <1456371874-19826-1-git-send-email-miles.chen@mediatek.com>

From: Miles Chen <miles.chen at mediatek.com>

Remove the unnecessary boundary check since there is a huge
gap between user and kernel address that they would never overlap.
(arm64 does not have enough levels of page tables to cover 64-bit
virtual address)

See Documentation/arm64/memory.txt

Signed-off-by: Miles Chen <miles.chen at mediatek.com>
---
 arch/arm64/mm/init.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3b061e..4579604 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -343,8 +343,6 @@ void __init mem_init(void)
 #ifdef CONFIG_COMPAT
 	BUILD_BUG_ON(TASK_SIZE_32			> TASK_SIZE_64);
 #endif
-	BUILD_BUG_ON(TASK_SIZE_64			> MODULES_VADDR);
-	BUG_ON(TASK_SIZE_64				> MODULES_VADDR);
 
 	if (PAGE_SIZE >= 16384 && get_num_physpages() <= 128) {
 		extern int sysctl_overcommit_memory;
-- 
1.9.1



From davem at davemloft.net  Wed Feb 24 19:49:20 2016
From: davem at davemloft.net (David Miller)
Date: Wed, 24 Feb 2016 22:49:20 -0500 (EST)
Subject: [PATCH] bnx2x: add a separate GENEVE Kconfig symbol
In-Reply-To: <CO2PR11MB0088CC09F328C0CFE10187BF97A40@CO2PR11MB0088.namprd11.prod.outlook.com>
References: <1456223774-1383513-1-git-send-email-arnd@arndb.de>
 <CO2PR11MB0088CC09F328C0CFE10187BF97A40@CO2PR11MB0088.namprd11.prod.outlook.com>
Message-ID: <20160224.224920.1224016653458748974.davem@davemloft.net>

From: Yuval Mintz <Yuval.Mintz at qlogic.com>
Date: Tue, 23 Feb 2016 18:33:10 +0000

>> When CONFIG_GENEVE is built as a loadable module, and bnx2x is built-in,
>> we get this link error:
> 
>> drivers/net/built-in.o: In function `bnx2x_open':
>> :(.text+0x33322): undefined reference to `geneve_get_rx_port'
>> drivers/net/built-in.o: In function `bnx2x_sp_rtnl_task':
>> :(.text+0x3e632): undefined reference to `geneve_get_rx_port'
> 
>> This avoids the problem by adding a separate Kconfig symbol named
>> CONFIG_BNX2X_GENEVE that is only enabled when the code is
>> reachable from the driver.
> 
>> This is the same trick that BNX2X does for VXLAN support, and
>> is similar to how I40E handles both.
> 
>> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>> Fixes: 883ce97d25b0 ("bnx2x: Add Geneve inner-RSS support")
> 
> Ouch. Thanks for fixing this one; I tried avoiding this solution
> since I don't think there's any reason to encumber the config
> file with needless options [I.e., what's the gain in the ability to
> disable a single offloaded protocol on a single network driver?],
> but obviously, I botched the job.
> 
> BTW, if you want to handle this exactly like vxlan, you might
> consider using `defined(CONFIG_BNX2X_GENEVE)' instead of
> `IS_ENABLED(CONFIG_BNX2X_GENEVE)'  [It not a tristate].
> But that's truly insignificant.
> 
> Acked-By: Yuval Mintz <Yuval.Mintz at qlogic.com>

Applied, thanks everyone.


From k.kozlowski at samsung.com  Wed Feb 24 20:06:04 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Thu, 25 Feb 2016 13:06:04 +0900
Subject: [PATCH] arm64: dts: Add tmu node for exynos7
In-Reply-To: <1456370865-10086-1-git-send-email-pankaj.dubey@samsung.com>
References: <1456370865-10086-1-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <56CE7DAC.4000803@samsung.com>

On 25.02.2016 12:27, Pankaj Dubey wrote:
> From: Alim Akhtar <alim.akhtar at samsung.com>
> 
> This patch adds tmu node, related temprature sensor and triping
> point data for Atlas cpu core found on exynos7 SoC.
> 
> Signed-off-by: Alim Akhtar <alim.akhtar at samsung.com>

Yours Sob is missing.

Cc-ed Lukasz Majewski.

Lukasz,
Your review or ack would be appreciated.


> ---
>  .../boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi   |   25 +++++++++
>  .../arm64/boot/dts/exynos/exynos7-trip-points.dtsi |   55 ++++++++++++++++++++
>  arch/arm64/boot/dts/exynos/exynos7.dtsi            |   20 +++++++
>  3 files changed, 100 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
>  create mode 100644 arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
> new file mode 100644
> index 0000000..1d6dcf2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
> @@ -0,0 +1,25 @@
> +/*
> + * Device tree sources for Exynos7 TMU sensor configuration
> + *
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + *		http://www.samsung.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.
> + *
> + */
> +
> +#include <dt-bindings/thermal/thermal_exynos.h>
> +
> +#thermal-sensor-cells = <0>;
> +samsung,tmu_gain = <9>;
> +samsung,tmu_reference_voltage = <17>;
> +samsung,tmu_noise_cancel_mode = <4>;
> +samsung,tmu_efuse_value = <75>;
> +samsung,tmu_min_efuse_value = <15>;
> +samsung,tmu_max_efuse_value = <100>;
> +samsung,tmu_first_point_trim = <25>;
> +samsung,tmu_second_point_trim = <85>;
> +samsung,tmu_default_temp_offset = <50>;
> +samsung,tmu_cal_type = <TYPE_ONE_POINT_TRIMMING>;
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
> new file mode 100644
> index 0000000..3970545
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
> @@ -0,0 +1,55 @@
> +/*
> + * Device tree sources for default Exynos7 thermal zone definition
> + *
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + *		http://www.samsung.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.
> + *
> + */
> +
> +trips {
> +	cpu-alert-0 {
> +		temperature = <75000>; /* millicelsius */
> +		hysteresis = <10000>; /* millicelsius */
> +		type = "passive";
> +	};
> +	cpu-alert-1 {
> +		temperature = <80000>; /* millicelsius */
> +		hysteresis = <10000>; /* millicelsius */
> +		type = "passive";
> +	};
> +	cpu-alert-2 {
> +		temperature = <85000>; /* millicelsius */
> +		hysteresis = <10000>; /* millicelsius */
> +		type = "passive";
> +	};
> +	cpu-alert-3 {
> +		temperature = <90000>; /* millicelsius */
> +		hysteresis = <10000>; /* millicelsius */
> +		type = "passive";
> +	};
> +	cpu-alert-4 {
> +		temperature = <95000>; /* millicelsius */
> +		hysteresis = <10000>; /* millicelsius */
> +		type = "passive";
> +	};
> +	cpu-alert-5 {
> +		temperature = <100000>; /* millicelsius */
> +		hysteresis = <10000>; /* millicelsius */
> +		type = "passive";
> +	};
> +	cpu-alert-6 {
> +		temperature = <110000>; /* millicelsius */
> +		hysteresis = <10000>; /* millicelsius */
> +		type = "passive";
> +	};
> +	/* HW Trip point */

The comment looks unnecessary, all of these are HW trip points, right?

> +	cpu-crit-0 {
> +		temperature = <115000>; /* millicelsius */
> +		hysteresis = <0>; /* millicelsius */
> +		type = "critical";
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> index c662f98..fc9d130 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -27,6 +27,7 @@
>  		pinctrl6 = &pinctrl_fsys0;
>  		pinctrl7 = &pinctrl_fsys1;
>  		pinctrl8 = &pinctrl_bus1;
> +		tmuctrl0 = &tmuctrl_0;

Why the alias is needed?

>  	};
>  
>  	cpus {
> @@ -538,6 +539,25 @@
>  			clocks = <&clock_peric0 PCLK_PWM>;
>  			clock-names = "timers";
>  		};
> +
> +		tmuctrl_0: tmu at 10060000 {
> +			compatible = "samsung,exynos7-tmu";
> +			reg = <0x10060000 0x200>;
> +			interrupts = <0 108 0>;
> +			clocks = <&clock_peris PCLK_TMU>,
> +				 <&clock_peris SCLK_TMU>;
> +			clock-names = "tmu_apbif", "tmu_sclk";
> +			#include "exynos7-tmu-sensor-conf.dtsi"
> +		};
> +
> +		thermal-zones {
> +			atlas_thermal: atlas-thermal {

The atlas is a Exynos7 specific codename. The name of node should be a
general class of the device, so maybe:
	atlas_thermal: cluster0-thermal
?

Best regards,
Krzysztof


From pankaj.dubey at samsung.com  Wed Feb 24 20:09:58 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Thu, 25 Feb 2016 09:39:58 +0530
Subject: [PATCH v2 0/2] ARM: EXYNOS: Trivial cleanup samsung mach files
Message-ID: <1456373400-10633-1-git-send-email-pankaj.dubey@samsung.com>

This patch series cleans up mach-exynos, mach-s3c24xx, plat-samsung include
header files with resepct to unused header file inclusion, removes redundant
register offset definition. Also corrects comment section at few places.

Changes since v1:
 - Keeping back inclusion of header "platform_device.h" in exynos.c.
 - Removing all unused instances of S3C_UART_OFFSET from mach-exynos,
   mach-s3c24xx, and plat-samsung, in single patch.
 - Patch 1/3 is already merged in maintainer tree so not included in v2. 

Pankaj Dubey (2):
  ARM: EXYNOS: cleanup header files inclusion
  ARM: SAMSUNG: remove unused register offset definition

 arch/arm/mach-exynos/common.h                |  1 -
 arch/arm/mach-exynos/exynos.c                |  4 ----
 arch/arm/mach-exynos/firmware.c              |  2 --
 arch/arm/mach-exynos/include/mach/map.h      |  9 +--------
 arch/arm/mach-exynos/platsmp.c               |  1 -
 arch/arm/mach-exynos/pm.c                    |  4 +---
 arch/arm/mach-exynos/s5p-dev-mfc.c           |  1 -
 arch/arm/mach-s3c24xx/include/mach/map.h     | 11 -----------
 arch/arm/plat-samsung/include/plat/map-s3c.h |  4 ----
 arch/arm/plat-samsung/include/plat/map-s5p.h |  5 -----
 10 files changed, 2 insertions(+), 40 deletions(-)

-- 
2.4.5



From pankaj.dubey at samsung.com  Wed Feb 24 20:09:59 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Thu, 25 Feb 2016 09:39:59 +0530
Subject: [PATCH v2 1/2] ARM: EXYNOS: cleanup header files inclusion
In-Reply-To: <1456373400-10633-1-git-send-email-pankaj.dubey@samsung.com>
References: <1456373400-10633-1-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <1456373400-10633-2-git-send-email-pankaj.dubey@samsung.com>

This includes trivial cleanup in exynos files such as
    - remove unused header files inclusion from exynos.c, s5p-dev-mfc.c,
      firmware.c, pm.c.
    - move inclusion of of.h from common.h to pm.c where it is really
      required

Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
---
 arch/arm/mach-exynos/common.h      | 1 -
 arch/arm/mach-exynos/exynos.c      | 4 ----
 arch/arm/mach-exynos/firmware.c    | 2 --
 arch/arm/mach-exynos/platsmp.c     | 1 -
 arch/arm/mach-exynos/pm.c          | 4 +---
 arch/arm/mach-exynos/s5p-dev-mfc.c | 1 -
 6 files changed, 1 insertion(+), 12 deletions(-)

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index e349a03..5365bf1 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -12,7 +12,6 @@
 #ifndef __ARCH_ARM_MACH_EXYNOS_COMMON_H
 #define __ARCH_ARM_MACH_EXYNOS_COMMON_H
 
-#include <linux/of.h>
 #include <linux/platform_data/cpuidle-exynos.h>
 
 #define EXYNOS3250_SOC_ID	0xE3472000
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 99947ad..f977eea 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -11,14 +11,11 @@
 
 #include <linux/init.h>
 #include <linux/io.h>
-#include <linux/kernel.h>
-#include <linux/serial_s3c.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_fdt.h>
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
-#include <linux/pm_domain.h>
 #include <linux/irqchip.h>
 #include <linux/soc/samsung/exynos-regs-pmu.h>
 
@@ -26,7 +23,6 @@
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
-#include <asm/memory.h>
 
 #include <mach/map.h>
 
diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 111cfbf..1bfd1b0 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -20,8 +20,6 @@
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/suspend.h>
 
-#include <mach/map.h>
-
 #include "common.h"
 #include "smc.h"
 
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index da46c63..85c3be6 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -15,7 +15,6 @@
 #include <linux/init.h>
 #include <linux/errno.h>
 #include <linux/delay.h>
-#include <linux/device.h>
 #include <linux/jiffies.h>
 #include <linux/smp.h>
 #include <linux/io.h>
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index b9b9186..c43b776 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -17,7 +17,7 @@
 #include <linux/suspend.h>
 #include <linux/cpu_pm.h>
 #include <linux/io.h>
-#include <linux/err.h>
+#include <linux/of.h>
 #include <linux/soc/samsung/exynos-regs-pmu.h>
 #include <linux/soc/samsung/exynos-pmu.h>
 
@@ -28,8 +28,6 @@
 
 #include <mach/map.h>
 
-#include <plat/pm-common.h>
-
 #include "common.h"
 
 static inline void __iomem *exynos_boot_vector_addr(void)
diff --git a/arch/arm/mach-exynos/s5p-dev-mfc.c b/arch/arm/mach-exynos/s5p-dev-mfc.c
index 0b04b6b..8ef1f3e 100644
--- a/arch/arm/mach-exynos/s5p-dev-mfc.c
+++ b/arch/arm/mach-exynos/s5p-dev-mfc.c
@@ -9,7 +9,6 @@
  */
 
 #include <linux/kernel.h>
-#include <linux/interrupt.h>
 #include <linux/platform_device.h>
 #include <linux/dma-mapping.h>
 #include <linux/memblock.h>
-- 
2.4.5



From pankaj.dubey at samsung.com  Wed Feb 24 20:10:00 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Thu, 25 Feb 2016 09:40:00 +0530
Subject: [PATCH v2 2/2] ARM: SAMSUNG: remove unused register offset definition
In-Reply-To: <1456373400-10633-1-git-send-email-pankaj.dubey@samsung.com>
References: <1456373400-10633-1-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <1456373400-10633-3-git-send-email-pankaj.dubey@samsung.com>

This patch cleans up various map.h under mach-exynos, mach-s3c24xx and
plat-samsung by removing unused register offset. This patch also does a
minor nitpick of changing EXYNOS4 to EXYNOS from comment section of
header file "mach-exynos/include/mach/map.h".

Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
---
 arch/arm/mach-exynos/include/mach/map.h      |  9 +--------
 arch/arm/mach-s3c24xx/include/mach/map.h     | 11 -----------
 arch/arm/plat-samsung/include/plat/map-s3c.h |  4 ----
 arch/arm/plat-samsung/include/plat/map-s5p.h |  5 -----
 4 files changed, 1 insertion(+), 28 deletions(-)

diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
index 351e839..c48ba4f 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -2,7 +2,7 @@
  * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
  *		http://www.samsung.com/
  *
- * EXYNOS4 - Memory map definitions
+ * EXYNOS - Memory map definitions
  *
  * 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
@@ -14,12 +14,6 @@
 
 #include <plat/map-base.h>
 
-/*
- * EXYNOS4 UART offset is 0x10000 but the older S5P SoCs are 0x400.
- * So need to define it, and here is to avoid redefinition warning.
- */
-#define S3C_UART_OFFSET			(0x10000)
-
 #include <plat/map-s5p.h>
 
 #define EXYNOS_PA_CHIPID		0x10000000
@@ -30,6 +24,5 @@
 #define EXYNOS4_PA_DMC1			0x10410000
 
 #define EXYNOS4_PA_COREPERI		0x10500000
-#define EXYNOS4_PA_L2CC			0x10502000
 
 #endif /* __ASM_ARCH_MAP_H */
diff --git a/arch/arm/mach-s3c24xx/include/mach/map.h b/arch/arm/mach-s3c24xx/include/mach/map.h
index 444793f..adc3904 100644
--- a/arch/arm/mach-s3c24xx/include/mach/map.h
+++ b/arch/arm/mach-s3c24xx/include/mach/map.h
@@ -14,13 +14,6 @@
 #define __ASM_ARCH_MAP_H
 
 #include <plat/map-base.h>
-
-/*
- * S3C2410 UART offset is 0x4000 but the other SoCs are 0x400.
- * So need to define it, and here is to avoid redefinition warning.
- */
-#define S3C_UART_OFFSET		(0x4000)
-
 #include <plat/map-s3c.h>
 
 /*
@@ -34,9 +27,6 @@
 #define S3C2410_PA_MEMCTRL	(0x48000000)
 #define S3C24XX_SZ_MEMCTRL	SZ_1M
 
-/* UARTs */
-#define S3C_VA_UARTx(uart)	(S3C_VA_UART + ((uart * S3C_UART_OFFSET)))
-
 /* Timers */
 #define S3C2410_PA_TIMER	(0x51000000)
 #define S3C24XX_SZ_TIMER	SZ_1M
@@ -157,7 +147,6 @@
 
 #define S3C_PA_FB	    S3C2443_PA_FB
 #define S3C_PA_IIC          S3C2410_PA_IIC
-#define S3C_PA_UART	    S3C24XX_PA_UART
 #define S3C_PA_USBHOST	S3C2410_PA_USBHOST
 #define S3C_PA_HSMMC0	    S3C2416_PA_HSMMC0
 #define S3C_PA_HSMMC1	    S3C2443_PA_HSMMC
diff --git a/arch/arm/plat-samsung/include/plat/map-s3c.h b/arch/arm/plat-samsung/include/plat/map-s3c.h
index c0c70a8..6feedd4 100644
--- a/arch/arm/plat-samsung/include/plat/map-s3c.h
+++ b/arch/arm/plat-samsung/include/plat/map-s3c.h
@@ -27,10 +27,6 @@
 #define S3C2410_PA_UART		(0x50000000)
 #define S3C24XX_PA_UART		S3C2410_PA_UART
 
-#ifndef S3C_UART_OFFSET
-#define S3C_UART_OFFSET		(0x400)
-#endif
-
 /*
  * GPIO ports
  *
diff --git a/arch/arm/plat-samsung/include/plat/map-s5p.h b/arch/arm/plat-samsung/include/plat/map-s5p.h
index e555769..b63aeeb 100644
--- a/arch/arm/plat-samsung/include/plat/map-s5p.h
+++ b/arch/arm/plat-samsung/include/plat/map-s5p.h
@@ -22,7 +22,6 @@
 #define S5P_VA_COREPERI_BASE	S3C_ADDR(0x02800000)
 #define S5P_VA_COREPERI(x)	(S5P_VA_COREPERI_BASE + (x))
 #define S5P_VA_SCU		S5P_VA_COREPERI(0x0)
-#define S5P_VA_TWD		S5P_VA_COREPERI(0x600)
 
 #define VA_VIC(x)		(S3C_VA_IRQ + ((x) * 0x10000))
 #define VA_VIC0			VA_VIC(0)
@@ -30,10 +29,6 @@
 #define VA_VIC2			VA_VIC(2)
 #define VA_VIC3			VA_VIC(3)
 
-#ifndef S3C_UART_OFFSET
-#define S3C_UART_OFFSET		(0x400)
-#endif
-
 #include <plat/map-s3c.h>
 
 #endif /* __ASM_PLAT_MAP_S5P_H */
-- 
2.4.5



From pankaj.dubey at samsung.com  Wed Feb 24 20:15:47 2016
From: pankaj.dubey at samsung.com (pankaj.dubey)
Date: Thu, 25 Feb 2016 09:45:47 +0530
Subject: [PATCH] arm64: dts: Add tmu node for exynos7
In-Reply-To: <56CE7DAC.4000803@samsung.com>
References: <1456370865-10086-1-git-send-email-pankaj.dubey@samsung.com>
 <56CE7DAC.4000803@samsung.com>
Message-ID: <56CE7FF3.4030101@samsung.com>

Hi Krzysztof,

On Thursday 25 February 2016 09:36 AM, Krzysztof Kozlowski wrote:
> On 25.02.2016 12:27, Pankaj Dubey wrote:
>> From: Alim Akhtar <alim.akhtar at samsung.com>
>>
>> This patch adds tmu node, related temprature sensor and triping
>> point data for Atlas cpu core found on exynos7 SoC.
>>
>> Signed-off-by: Alim Akhtar <alim.akhtar at samsung.com>
> 
> Yours Sob is missing.
> 
> Cc-ed Lukasz Majewski.
> 

Due to some technical difficulty Alim posted via my account. He will
re-spin this patch via his account soon.

Thanks,
Pankaj Dubey
> Lukasz,
> Your review or ack would be appreciated.
> 
> 
>> ---
>>  .../boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi   |   25 +++++++++
>>  .../arm64/boot/dts/exynos/exynos7-trip-points.dtsi |   55 ++++++++++++++++++++
>>  arch/arm64/boot/dts/exynos/exynos7.dtsi            |   20 +++++++
>>  3 files changed, 100 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
>>  create mode 100644 arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
>> new file mode 100644
>> index 0000000..1d6dcf2
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
>> @@ -0,0 +1,25 @@
>> +/*
>> + * Device tree sources for Exynos7 TMU sensor configuration
>> + *
>> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
>> + *		http://www.samsung.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.
>> + *
>> + */
>> +
>> +#include <dt-bindings/thermal/thermal_exynos.h>
>> +
>> +#thermal-sensor-cells = <0>;
>> +samsung,tmu_gain = <9>;
>> +samsung,tmu_reference_voltage = <17>;
>> +samsung,tmu_noise_cancel_mode = <4>;
>> +samsung,tmu_efuse_value = <75>;
>> +samsung,tmu_min_efuse_value = <15>;
>> +samsung,tmu_max_efuse_value = <100>;
>> +samsung,tmu_first_point_trim = <25>;
>> +samsung,tmu_second_point_trim = <85>;
>> +samsung,tmu_default_temp_offset = <50>;
>> +samsung,tmu_cal_type = <TYPE_ONE_POINT_TRIMMING>;
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
>> new file mode 100644
>> index 0000000..3970545
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
>> @@ -0,0 +1,55 @@
>> +/*
>> + * Device tree sources for default Exynos7 thermal zone definition
>> + *
>> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
>> + *		http://www.samsung.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.
>> + *
>> + */
>> +
>> +trips {
>> +	cpu-alert-0 {
>> +		temperature = <75000>; /* millicelsius */
>> +		hysteresis = <10000>; /* millicelsius */
>> +		type = "passive";
>> +	};
>> +	cpu-alert-1 {
>> +		temperature = <80000>; /* millicelsius */
>> +		hysteresis = <10000>; /* millicelsius */
>> +		type = "passive";
>> +	};
>> +	cpu-alert-2 {
>> +		temperature = <85000>; /* millicelsius */
>> +		hysteresis = <10000>; /* millicelsius */
>> +		type = "passive";
>> +	};
>> +	cpu-alert-3 {
>> +		temperature = <90000>; /* millicelsius */
>> +		hysteresis = <10000>; /* millicelsius */
>> +		type = "passive";
>> +	};
>> +	cpu-alert-4 {
>> +		temperature = <95000>; /* millicelsius */
>> +		hysteresis = <10000>; /* millicelsius */
>> +		type = "passive";
>> +	};
>> +	cpu-alert-5 {
>> +		temperature = <100000>; /* millicelsius */
>> +		hysteresis = <10000>; /* millicelsius */
>> +		type = "passive";
>> +	};
>> +	cpu-alert-6 {
>> +		temperature = <110000>; /* millicelsius */
>> +		hysteresis = <10000>; /* millicelsius */
>> +		type = "passive";
>> +	};
>> +	/* HW Trip point */
> 
> The comment looks unnecessary, all of these are HW trip points, right?
> 
>> +	cpu-crit-0 {
>> +		temperature = <115000>; /* millicelsius */
>> +		hysteresis = <0>; /* millicelsius */
>> +		type = "critical";
>> +	};
>> +};
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> index c662f98..fc9d130 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> @@ -27,6 +27,7 @@
>>  		pinctrl6 = &pinctrl_fsys0;
>>  		pinctrl7 = &pinctrl_fsys1;
>>  		pinctrl8 = &pinctrl_bus1;
>> +		tmuctrl0 = &tmuctrl_0;
> 
> Why the alias is needed?
> 
>>  	};
>>  
>>  	cpus {
>> @@ -538,6 +539,25 @@
>>  			clocks = <&clock_peric0 PCLK_PWM>;
>>  			clock-names = "timers";
>>  		};
>> +
>> +		tmuctrl_0: tmu at 10060000 {
>> +			compatible = "samsung,exynos7-tmu";
>> +			reg = <0x10060000 0x200>;
>> +			interrupts = <0 108 0>;
>> +			clocks = <&clock_peris PCLK_TMU>,
>> +				 <&clock_peris SCLK_TMU>;
>> +			clock-names = "tmu_apbif", "tmu_sclk";
>> +			#include "exynos7-tmu-sensor-conf.dtsi"
>> +		};
>> +
>> +		thermal-zones {
>> +			atlas_thermal: atlas-thermal {
> 
> The atlas is a Exynos7 specific codename. The name of node should be a
> general class of the device, so maybe:
> 	atlas_thermal: cluster0-thermal
> ?
> 
> Best regards,
> Krzysztof
> 


From pankaj.dubey at samsung.com  Wed Feb 24 20:19:13 2016
From: pankaj.dubey at samsung.com (pankaj.dubey)
Date: Thu, 25 Feb 2016 09:49:13 +0530
Subject: [GIT PULL 3/7] drivers: soc: EXYNOS drivers for v4.6
In-Reply-To: <56CE4E14.2050701@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
 <1455496446-23779-4-git-send-email-k.kozlowski@samsung.com>
 <20160224222254.GT10126@localhost> <56CE4E14.2050701@samsung.com>
Message-ID: <56CE80C1.8040801@samsung.com>

Hi Krzysztof,

On Thursday 25 February 2016 06:13 AM, Krzysztof Kozlowski wrote:
> On 25.02.2016 07:22, Olof Johansson wrote:
>> On Mon, Feb 15, 2016 at 09:34:02AM +0900, Krzysztof Kozlowski wrote:
>>> Hi Arnd, Kevin and Olof,
>>>
>>> This finally moves SROM controller and PMU code to separate
>>> driver under drivers/soc/samsung.
>>>
>>> Kind regards,
>>> Krzysztof
>>>
>>>
>>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>>
>>>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>>
>>> are available in the git repository at:
>>>
>>>   git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-soc-srom-pmu-4.6
>>>
>>> for you to fetch changes up to 74a6659e8bf193066ba6bf365de66baa897aebb1:
>>>
>>>   drivers: soc: Add support for Exynos PMU driver (2016-01-25 10:46:59 +0900)
>>>
>>> ----------------------------------------------------------------
>>> A set of changes adding new drivers under drivers/soc/samsung:
>>>
>>> 1. Split code for handling SROM registers out of arm/mach-exynos
>>>    in to separate SROM controller driver under drivers/soc/samsung.
>>>    The driver will save and restore SROM registers during Suspend
>>>    to RAM.
>>>
>>> 2. Add to this SROM controller driver support for bank configuration
>>>    used by child devices. This allows usage of SMSC9115 Ethernet chip
>>>    on SMDK5410 (Exynos5410) directly connected to SROM controller.
>>
>> Hi,
>>
>> OMAP has GPMC drivers under drivers/memory. I wonder if SROM should go there
>> too, since it's a quite similar bus.
> 
> I wish I get this feedback before, when we were discussing the SROM
> patches. :/
> 
> Indeed this sounds reasonable. On some boards the omap-gpmc is used for
> the same purpose: interfacing to smsc,lan9115 (like on SMDK5410).
> 
> 
>> Feel free to respin this without SROM now, so we can get the other pieces in
>> sooner and then revisit the SROM asyncronously. That'll remove the dependencies
>> on DT as well.
> 
> Okay, I'll rebase all drivers/soc branches and respin the pull request
> so PMU driver and other stuff could go in.
> 
> BTW, just in case, although PMU stands for "Power Management Unit" I
> don't think it should be placed under drivers/power because it is not a
> avs/charger/battery/reset driver. Existing power-related drivers are
> under driver/soc (bcm, dove, tegra).
> 
> Re-work of SROM drivers could be started on top of it.
> 

Please let me know if I need to take care of any of this work.

Thanks,
Pankaj Dubey
> Best regards,
> Krzysztof
> 


From santosh.shilimkar at oracle.com  Wed Feb 24 20:19:22 2016
From: santosh.shilimkar at oracle.com (santosh shilimkar)
Date: Wed, 24 Feb 2016 20:19:22 -0800
Subject: [GIT PULL] ARM: Keystone DTS for 4.6
In-Reply-To: <20160225012815.GH29055@localhost>
References: <1455959351-11524-1-git-send-email-ssantosh@kernel.org>
 <20160225012815.GH29055@localhost>
Message-ID: <56CE80CA.80407@oracle.com>

On 2/24/2016 5:28 PM, Olof Johansson wrote:
> Hi,
>
> On Sat, Feb 20, 2016 at 01:09:10AM -0800, Santosh Shilimkar wrote:
>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>
>>    Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>
>> are available in the git repository at:
>>
>>    git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone_dts_for_4.6
>>
>> for you to fetch changes up to 5f67dae54262adeb0bfd98fa4c7a9b62548c9f25:
>>
>>    ARM: dts: keystone: Add minimum support for K2G evm (2016-02-20 00:56:06 -0800)
>>
>> ----------------------------------------------------------------
>> ARM: DTS: Add new bindings for K2G and the K2G evm
>>
>> K2G SoC family is the newest version of the Keystone family of processors.
>>
>> The technical reference manual for K2G can be found here:
>> http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf
>> ----------------------------------------------------------------
>> Nishanth Menon (1):
>>        ARM: keystone: Create new binding for K2G SoC
>>
>> Vitaly Andrianov (2):
>>        ARM: dts: keystone: Add Initial DT support for TI K2G SoC family
>>        ARM: dts: keystone: Add minimum support for K2G evm
>>
>>   .../devicetree/bindings/arm/keystone/keystone.txt  |  5 ++
>>   arch/arm/boot/dts/Makefile                         |  3 +-
>>   arch/arm/boot/dts/k2g-evm.dts                      | 32 ++++++++
>>   arch/arm/boot/dts/k2g.dtsi                         | 89 ++++++++++++++++++++++
>>   arch/arm/mach-keystone/keystone.c                  |  1 +
>>   5 files changed, 129 insertions(+), 1 deletion(-)
>>   create mode 100644 arch/arm/boot/dts/k2g-evm.dts
>>   create mode 100644 arch/arm/boot/dts/k2g.dtsi
>
> We've been asking people to prefix the DTS files with vendor or platform
> prefixes, so that the namespace under arch/arm/boot/dts/ somewhat gets
> partitioned.
>
Sounds good though it will be hard to rename existing files now
assuming they have been already in use.

> It's really unfortunate that we didn't notice this when the other k2?-* entries
> were added, especially since there's a keystone* set of files too.
>
I missed as well about the nomenclature followed across.

> How do you feel about moving things around and prefixing with keystone*
> instead?  We can argue whether users are affected by a rename of already
> existing files, or if those can be renamed too. I'll leave that up to you, but
> k2? seems like too short a prefix here.
>
I will definitely rename these new ones and resend the pull request.
For older ones, let me RFC it in next merge window and if no one
complains, will rename them too.

Regards,
Santosh




From k.kozlowski at samsung.com  Wed Feb 24 20:26:59 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Thu, 25 Feb 2016 13:26:59 +0900
Subject: [PATCH v2 0/2] ARM: EXYNOS: Trivial cleanup samsung mach files
In-Reply-To: <1456373400-10633-1-git-send-email-pankaj.dubey@samsung.com>
References: <1456373400-10633-1-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <56CE8293.2050901@samsung.com>

On 25.02.2016 13:09, Pankaj Dubey wrote:
> This patch series cleans up mach-exynos, mach-s3c24xx, plat-samsung include
> header files with resepct to unused header file inclusion, removes redundant
> register offset definition. Also corrects comment section at few places.
> 
> Changes since v1:
>  - Keeping back inclusion of header "platform_device.h" in exynos.c.
>  - Removing all unused instances of S3C_UART_OFFSET from mach-exynos,
>    mach-s3c24xx, and plat-samsung, in single patch.
>  - Patch 1/3 is already merged in maintainer tree so not included in v2. 

Thanks for the changes. I appreciate that!

Applied both patches.

Best regards,
Krzysztof



From vigneshr at ti.com  Wed Feb 24 20:47:32 2016
From: vigneshr at ti.com (Vignesh R)
Date: Thu, 25 Feb 2016 10:17:32 +0530
Subject: [PATCH] ARM: dts: dra7: Support QSPI MODE-0 operation at 64MHz
Message-ID: <1456375652-14071-1-git-send-email-vigneshr@ti.com>

According to Data Manual(SPRS915P) of AM57x, TI QSPI controller on
DRA74(rev 1.1+) can support up to 64MHz in MODE-0, whereas MODE-3 is
limited to 48MHz. Hence, switch to MODE-0 for better throughput.

Signed-off-by: Vignesh R <vigneshr at ti.com>
---
 arch/arm/boot/dts/dra7-evm.dts | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index cfc24e52244e..15f10bdc8c31 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -653,15 +653,13 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&qspi1_pins>;
 
-	spi-max-frequency = <48000000>;
+	spi-max-frequency = <64000000>;
 	m25p80 at 0 {
 		compatible = "s25fl256s1";
-		spi-max-frequency = <48000000>;
+		spi-max-frequency = <64000000>;
 		reg = <0>;
 		spi-tx-bus-width = <1>;
 		spi-rx-bus-width = <4>;
-		spi-cpol;
-		spi-cpha;
 		#address-cells = <1>;
 		#size-cells = <1>;
 
-- 
2.7.1



From k.kozlowski at samsung.com  Wed Feb 24 20:50:20 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Thu, 25 Feb 2016 13:50:20 +0900
Subject: [GIT PULL 3/7] drivers: soc: EXYNOS drivers for v4.6
In-Reply-To: <56CE80C1.8040801@samsung.com>
References: <1455496446-23779-1-git-send-email-k.kozlowski@samsung.com>
 <1455496446-23779-4-git-send-email-k.kozlowski@samsung.com>
 <20160224222254.GT10126@localhost> <56CE4E14.2050701@samsung.com>
 <56CE80C1.8040801@samsung.com>
Message-ID: <56CE880C.8090703@samsung.com>

On 25.02.2016 13:19, pankaj.dubey wrote:
> Hi Krzysztof,
> 
>>>
>>> OMAP has GPMC drivers under drivers/memory. I wonder if SROM should go there
>>> too, since it's a quite similar bus.
>>
>> I wish I get this feedback before, when we were discussing the SROM
>> patches. :/
>>
>> Indeed this sounds reasonable. On some boards the omap-gpmc is used for
>> the same purpose: interfacing to smsc,lan9115 (like on SMDK5410).
>>
>>
>>> Feel free to respin this without SROM now, so we can get the other pieces in
>>> sooner and then revisit the SROM asyncronously. That'll remove the dependencies
>>> on DT as well.
>>
>> Okay, I'll rebase all drivers/soc branches and respin the pull request
>> so PMU driver and other stuff could go in.
>>
>> BTW, just in case, although PMU stands for "Power Management Unit" I
>> don't think it should be placed under drivers/power because it is not a
>> avs/charger/battery/reset driver. Existing power-related drivers are
>> under driver/soc (bcm, dove, tegra).
>>
>> Re-work of SROM drivers could be started on top of it.
>>
> 
> Please let me know if I need to take care of any of this work.

Yes, unfortunately I need your help with that.

I rebased mach-exynos/drivers-soc related patches and pushed it to my
next/soc branch:
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/soc

There are some changes in commits, mostly for movement of PMU driver
(now it is applied first, before SROMc driver). I also applied some of
the cleanup and maintainer patches from SROMc patchset. DT changes are
already merged.

Overall, could you rebase remaining patches on top of my next/soc and
move SROM driver to drivers/memory? You can also rebase Pavel Fedin's
patches (if you don't I will rebase them).


Last version of applied SROMc patches is here:
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=for-v4.6/drivers-soc-exynos-srom-pmu

Best regards,
Krzysztof


From Suravee.Suthikulpanit at amd.com  Wed Feb 24 21:23:08 2016
From: Suravee.Suthikulpanit at amd.com (Suravee Suthikulpanit)
Date: Thu, 25 Feb 2016 12:23:08 +0700
Subject: [PATCH] dtb: amd: Fix-up for ccn504 and kcs nodes
In-Reply-To: <20160224220157.GP10126@localhost>
References: <1455236443-23949-1-git-send-email-Suravee.Suthikulpanit@amd.com>
 <20160224220157.GP10126@localhost>
Message-ID: <56CE8FBC.6010508@amd.com>

Hi,

On 02/25/2016 05:01 AM, Olof Johansson wrote:
> On Fri, Feb 12, 2016 at 07:20:43AM +0700, Suravee Suthikulpanit wrote:
>> From: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
>>
>> This is a fix-up patch based on the review comment from
>> Arnd regarding:
>>      * fix ccn504 address in the node name
>>      * remove kcs interrupt-name
>>
>> Signed-off-by: Brijesh Singh <brijesh.singh at amd.com>
>> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit at amd.com>
>> Cc: Arnd Bergmann <arnd at arndb.de>
>> ---
>>
>> Hi Olof,
>>
>> Here are the changes from the V3 that I sent earlier. Sorry for confusion.
>> Would you please pull this into the next tree?
>>
>> Thank you,
>> Suravee
>
> Applied.
>
> I also noticed that the patch subjects were nonstandard the last time around.
> In the future, please use:
>
> arm64: dts: amd: ...
>
> as prefix, instead of just dtb (which is the binary format). I fixed it up for
> this patch, and the others, well, they're already applied. So let's try to
> remember it for the future.
>
>
> -Olof
>

Thanks, and sorry for the mis-use of the subject line.

Suravee


From jamesjj.liao at mediatek.com  Wed Feb 24 22:24:37 2016
From: jamesjj.liao at mediatek.com (James Liao)
Date: Thu, 25 Feb 2016 14:24:37 +0800
Subject: [PATCH v6 4/7] clk: mediatek: Add MT2701 clock support
In-Reply-To: <20160224212533.2278.7597@quark.deferred.io>
References: <1454665050-37776-1-git-send-email-jamesjj.liao@mediatek.com>
 <1454665050-37776-5-git-send-email-jamesjj.liao@mediatek.com>
 <20160210200853.26445.15165@quark.deferred.io>
 <1455527982.29688.8.camel@mtksdaap41>
 <20160224212533.2278.7597@quark.deferred.io>
Message-ID: <1456381477.22545.24.camel@mtksdaap41>

Hi Mike,

On Wed, 2016-02-24 at 13:25 -0800, Michael Turquette wrote:
> Hi James,
> 
> Quoting James Liao (2016-02-15 01:19:42)
> > Hi Mike,
> > 
> > On Wed, 2016-02-10 at 12:08 -0800, Michael Turquette wrote:
> > > Quoting James Liao (2016-02-05 01:37:27)
> > > > +CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt2701-topckgen", mtk_topckgen_init);
> > > > +CLK_OF_DECLARE(mtk_infrasys, "mediatek,mt2701-infracfg", mtk_infrasys_init);
> > > > +CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt2701-pericfg", mtk_pericfg_init);
> > > > +CLK_OF_DECLARE(mtk_mmsys, "mediatek,mt2701-mmsys", mtk_mmsys_init);
> > > > +CLK_OF_DECLARE(mtk_imgsys, "mediatek,mt2701-imgsys", mtk_imgsys_init);
> > > > +CLK_OF_DECLARE(mtk_vdecsys, "mediatek,mt2701-vdecsys", mtk_vdecsys_init);
> > > > +CLK_OF_DECLARE(mtk_hifsys, "mediatek,mt2701-hifsys", mtk_hifsys_init);
> > > > +CLK_OF_DECLARE(mtk_ethsys, "mediatek,mt2701-ethsys", mtk_ethsys_init);
> > > > +CLK_OF_DECLARE(mtk_bdpsys, "mediatek,mt2701-bdpsys", mtk_bdpsys_init);
> > > > +CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt2701-apmixedsys",
> > > 
> > > :-/
> > > 
> > > This is way too much CLK_OF_DECLARE and not enough Linux Driver Model.
> > > 
> > > I understand that some platforms really must initialize some clocks very
> > > early, but can we please separate those into one table and call
> > > CLK_OF_DECLARE on only that set, and then register the rest through a
> > > platform_driver later on?
> > 
> > I know CLK_OF_DECLARE is much earlier than platform_driver, so it can
> > ensure all drivers lookup their clocks successfully during
> > platform_driver probe. Is there anything different to init these clock
> > providers in CLK_OF_DECLARE and platform_driver?
> 
> This a common pattern we're seeing right now. Joachim did a nice job of
> supporting early clocks with CLK_OF_DECLARE, and also using a proper
> driver in his lpc18xx implementation:
> 
> http://marc.info/?l=devicetree&m=145618160610001

Do you mean we should keep most clock init in platform_driver_probe and
use CLK_OF_DECLARE for some early clocks only?

Using CLK_OF_DECLARE() for all clock providers is convenient. The
convenience includes coding structure and driver init order. The coding
structure means we can use a consistency way to add clock providers, so
we can reduce errors and apply code generator on clock drivers.

The driver init order is another issue. In lpc18xx driver you mentioned
in [1], it uses ERR_PTR(-EPROBE_DEFER) to be the place holder for
non-early clocks in arch_init (CLK_OF_DECLARE), and then register early
and non-early clocks again in module_init. The EPROBE_DEFER place holder
is an interesting idea to resolve init order issue. But to register
clocks twice on the same clock provider seems not a good idea, although
it can still work in current CCF implementation.

Is it important to move clock init into platform_driver? If not, I
prefer to keep current implementation on MT2701, and look for a better
way to init clocks in platform_driver in new SoCs.


[1] http://marc.info/?l=devicetree&m=145618160610001


Best regards,

James



From ard.biesheuvel at linaro.org  Wed Feb 24 23:02:00 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 25 Feb 2016 08:02:00 +0100
Subject: [RFC PATCH 1/6] arm64: vmemmap: use virtual projection of linear
 region
In-Reply-To: <1456330893-19228-2-git-send-email-ard.biesheuvel@linaro.org>
References: <1456330893-19228-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456330893-19228-2-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <CAKv+Gu9M6QukGqLWYgDqAp6xaa7RPVW36E591LOPf6xP_TH48w@mail.gmail.com>

On 24 February 2016 at 17:21, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> Commit dd006da21646 ("arm64: mm: increase VA range of identity map") made
> some changes to the memory mapping code to allow physical memory to reside
> at an offset that exceeds the size of the virtual address space.
>
> However, since the size of the vmemmap area is proportional to the size of
> the VA area, but it is populated relative to the physical space, we may
> end up with the struct page array being mapped outside of the vmemmap
> region. For instance, on my Seattle A0 box, I can see the following output
> in the dmesg log.
>
>    vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000   (     8 GB maximum)
>              0xffffffbfc0000000 - 0xffffffbfd0000000   (   256 MB actual)
>
> We can fix this by deciding that the vmemmap region is not a projection of
> the physical space, but of the virtual space above PAGE_OFFSET, i.e., the
> linear region. This way, we are guaranteed that the vmemmap region is of
> sufficient size, and we can also reduce its size by half.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
>  arch/arm64/include/asm/pgtable.h | 7 ++++---
>  arch/arm64/mm/init.c             | 4 ++--
>  2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index a440f5a85d08..8e6baea0ff61 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -34,18 +34,19 @@
>  /*
>   * VMALLOC and SPARSEMEM_VMEMMAP ranges.
>   *
> - * VMEMAP_SIZE: allows the whole VA space to be covered by a struct page array
> + * VMEMAP_SIZE: allows the whole linear region to be covered by a struct page array
>   *     (rounded up to PUD_SIZE).
>   * VMALLOC_START: beginning of the kernel vmalloc space
>   * VMALLOC_END: extends to the available space below vmmemmap, PCI I/O space,
>   *     fixed mappings and modules
>   */
> -#define VMEMMAP_SIZE           ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) * sizeof(struct page), PUD_SIZE)
> +#define VMEMMAP_SIZE           ALIGN((1UL << (VA_BITS - PAGE_SHIFT - 1)) * sizeof(struct page), PUD_SIZE)
>
>  #define VMALLOC_START          (MODULES_END)
>  #define VMALLOC_END            (PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - SZ_64K)
>
> -#define vmemmap                        ((struct page *)(VMALLOC_END + SZ_64K))
> +#define VMEMMAP_START          (VMALLOC_END + SZ_64K)
> +#define vmemmap                        ((struct page *)(VMEMMAP_START - memstart_addr / sizeof(struct page)))
>

Note that with the linear region randomization which is now in -next,
this division needs to be signed (since memstart_addr can wrap).

So I should either update the definition of memstart_addr to s64 in
this patch, or cast to (s64) in the expression above


>  #define FIRST_USER_ADDRESS     0UL
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index c0ea54bd9995..88046b94fa87 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -363,8 +363,8 @@ void __init mem_init(void)
>                   MLK_ROUNDUP(_text, _etext),
>                   MLK_ROUNDUP(_sdata, _edata),
>  #ifdef CONFIG_SPARSEMEM_VMEMMAP
> -                 MLG((unsigned long)vmemmap,
> -                     (unsigned long)vmemmap + VMEMMAP_SIZE),
> +                 MLG(VMEMMAP_START,
> +                     VMEMMAP_START + VMEMMAP_SIZE),
>                   MLM((unsigned long)virt_to_page(PAGE_OFFSET),
>                       (unsigned long)virt_to_page(high_memory)),
>  #endif
> --
> 2.5.0
>


From Minghuan.Lian at nxp.com  Wed Feb 24 23:04:30 2016
From: Minghuan.Lian at nxp.com (Minghuan Lian)
Date: Thu, 25 Feb 2016 15:04:30 +0800
Subject: [PATCH] pci/layerscape: fix MSG TLP drop setting
Message-ID: <1456383870-23302-1-git-send-email-Minghuan.Lian@nxp.com>

Some kinds of Layerscape PCIe controllers will forward the received
message TLPs to system application address space, which could corrupt
system memory or lead to a system hang. The patch enables the MSG_DROP
to fix this issue.

Signed-off-by: Minghuan Lian <Minghuan.Lian at nxp.com>
---
 drivers/pci/host/pci-layerscape.c | 21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/host/pci-layerscape.c b/drivers/pci/host/pci-layerscape.c
index 3923bed..f39961b 100644
--- a/drivers/pci/host/pci-layerscape.c
+++ b/drivers/pci/host/pci-layerscape.c
@@ -77,6 +77,16 @@ static void ls_pcie_fix_class(struct ls_pcie *pcie)
 	iowrite16(PCI_CLASS_BRIDGE_PCI, pcie->dbi + PCI_CLASS_DEVICE);
 }
 
+/* Drop MSG TLP except for Vendor MSG */
+static void ls_pcie_drop_msg_tlp(struct ls_pcie *pcie)
+{
+	u32 val;
+
+	val = ioread32(pcie->dbi + PCIE_STRFMR1);
+	val &= 0xDFFFFFFF;
+	iowrite32(val, pcie->dbi + PCIE_STRFMR1);
+}
+
 static int ls1021_pcie_link_up(struct pcie_port *pp)
 {
 	u32 state;
@@ -97,7 +107,7 @@ static int ls1021_pcie_link_up(struct pcie_port *pp)
 static void ls1021_pcie_host_init(struct pcie_port *pp)
 {
 	struct ls_pcie *pcie = to_ls_pcie(pp);
-	u32 val, index[2];
+	u32 index[2];
 
 	pcie->scfg = syscon_regmap_lookup_by_phandle(pp->dev->of_node,
 						     "fsl,pcie-scfg");
@@ -116,13 +126,7 @@ static void ls1021_pcie_host_init(struct pcie_port *pp)
 
 	dw_pcie_setup_rc(pp);
 
-	/*
-	 * LS1021A Workaround for internal TKT228622
-	 * to fix the INTx hang issue
-	 */
-	val = ioread32(pcie->dbi + PCIE_STRFMR1);
-	val &= 0xffff;
-	iowrite32(val, pcie->dbi + PCIE_STRFMR1);
+	ls_pcie_drop_msg_tlp(pcie);
 }
 
 static int ls_pcie_link_up(struct pcie_port *pp)
@@ -147,6 +151,7 @@ static void ls_pcie_host_init(struct pcie_port *pp)
 	iowrite32(1, pcie->dbi + PCIE_DBI_RO_WR_EN);
 	ls_pcie_fix_class(pcie);
 	ls_pcie_clear_multifunction(pcie);
+	ls_pcie_drop_msg_tlp(pcie);
 	iowrite32(0, pcie->dbi + PCIE_DBI_RO_WR_EN);
 }
 
-- 
1.9.1



From balbi at kernel.org  Wed Feb 24 23:08:18 2016
From: balbi at kernel.org (Felipe Balbi)
Date: Thu, 25 Feb 2016 09:08:18 +0200
Subject: [PATCH 0/2] usb: dwc2: Remove host and gadget only code from core
In-Reply-To: <CAD=FV=WsBM-50gnDWq7AsXnSQPOu3ELabtbDRYjejAbN4h8b1Q@mail.gmail.com>
References: <cover.1456213319.git.johnyoun@synopsys.com>
 <56CC26ED.50004@synopsys.com> <87mvqqjkfj.fsf@ti.com>
 <CAD=FV=WsBM-50gnDWq7AsXnSQPOu3ELabtbDRYjejAbN4h8b1Q@mail.gmail.com>
Message-ID: <87r3g1i7x9.fsf@ti.com>


Hi,

Doug Anderson <dianders at chromium.org> writes:
>> John Youn <John.Youn at synopsys.com> writes:
>>> On 2/23/2016 12:35 AM, John Youn wrote:
>>>> This series moves the host/gadget-specific code from core.c to hcd.c
>>>> and gadget.c so that they will be compiled only when their respective
>>>> configurations are selected, or in DRD.
>>>>
>>>> This is mostly just a straight move of the code. I have also added
>>>> some comments to group related functions together.
>>>>
>>>> Compiled and tested in all three modes.
>>>>
>>>> This should also solve the issue reported here:
>>>> http://marc.info/?l=linux-usb&m=145591813410106&w=2
>>>>
>>>> Although I wasn't able to test it... couldn't figure out how to
>>>> disable CONFIG_USB and enable DWC2 in gadget mode.
>>>>
>>>> Felipe,
>>>>
>>>> This should be applied after Doug's series on your testing/next
>>>> branch.
>>>>
>>>>
>>>
>>> Hi Felipe,
>>>
>>> Patch 2/2 is triggering our corporate mail filters however I try to
>>> send it. I'll look into this with IT tomorrow, maybe have to send it
>>> from another account.
>>
>> okay, I don't have patch 2/2. 1/2 is now in testing/next
>
> Perhaps John's solution for working around his company's mail filters
> somehow sent it to your SPAM folder?  I saw his repost of v1 at on
> patchwork.  GMail put them in my inbox but marked them slightly
> different, saying they were from "John Youn via messagingengine.com"
>
> 8396481 New          [RESEND,1/2] usb: dwc2: Move register save and
> restore functions
> 8396491 New          [RESEND,2/2] usb: dwc2: Move host-specific core
> functions into hcd.c
>
> ...I reviewed both 1/2 and 2/2.  For 1/2 I added my reviewed-by /
> tested-by.  For 2/2 I requested some nitfixes.  John posted v2 at:
>
> 8398461 New          [v2,1/2] usb: dwc2: Move register save and
> restore functions
> 8398471 New          [v2,2/2] usb: dwc2: Move host-specific core
> functions into hcd.c
>
> v2 of 2/2 looks good to me.  All patches can be found at
> <https://patchwork.kernel.org/patch/<PATCHNUM>/>, like:
>
> https://patchwork.kernel.org/patch/8398461/
> https://patchwork.kernel.org/patch/8398471/

thanks, after I replied here I refreshed my inbox and there they were
:-) they're both in my testing/next.

cheers

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/c7f15a0d/attachment.sig>

From pc.liao at mediatek.com  Wed Feb 24 23:12:33 2016
From: pc.liao at mediatek.com (PC Liao)
Date: Thu, 25 Feb 2016 15:12:33 +0800
Subject: [PATCH] ASoC: mediatek: Add I03/I04 widgets and corresponding routes
Message-ID: <1456384353-13041-1-git-send-email-pc.liao@mediatek.com>

From: Koro Chen <koro.chen at mediatek.com>

Add these widgets to allow another path from I2S input.

Change-Id: Ib6804bbbde388830d8359245fe13bbb0f2bb36ba
Signed-off-by: Koro Chen <koro.chen at mediatek.com>
Signed-off-by: PC Liao <pc.liao at mediatek.com>
---
 sound/soc/mediatek/mtk-afe-pcm.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/sound/soc/mediatek/mtk-afe-pcm.c b/sound/soc/mediatek/mtk-afe-pcm.c
index 689c51f..5de878f 100644
--- a/sound/soc/mediatek/mtk-afe-pcm.c
+++ b/sound/soc/mediatek/mtk-afe-pcm.c
@@ -40,6 +40,7 @@
 
 #define AFE_CONN1		0x0024
 #define AFE_CONN2		0x0028
+#define AFE_CONN3		0x002c
 #define AFE_CONN7		0x0460
 #define AFE_CONN8		0x0464
 #define AFE_HDMI_CONN0		0x0390
@@ -63,6 +64,7 @@
 #define AFE_HDMI_OUT_CUR	0x0378
 #define AFE_HDMI_OUT_END	0x037c
 
+#define AFE_ADDA_TOP_CON0	0x0120
 #define AFE_ADDA2_TOP_CON0	0x0600
 
 #define AFE_HDMI_OUT_CON0	0x0370
@@ -259,6 +261,7 @@ static int mtk_afe_set_i2s(struct mtk_afe *afe, unsigned int rate)
 		return -EINVAL;
 
 	/* from external ADC */
+	regmap_update_bits(afe->regmap, AFE_ADDA_TOP_CON0, 0x1, 0x1);
 	regmap_update_bits(afe->regmap, AFE_ADDA2_TOP_CON0, 0x1, 0x1);
 
 	/* set input */
@@ -903,15 +906,19 @@ static const struct snd_kcontrol_new mtk_afe_o04_mix[] = {
 };
 
 static const struct snd_kcontrol_new mtk_afe_o09_mix[] = {
+	SOC_DAPM_SINGLE_AUTODISABLE("I03 Switch", AFE_CONN3, 0, 1, 0),
 	SOC_DAPM_SINGLE_AUTODISABLE("I17 Switch", AFE_CONN7, 30, 1, 0),
 };
 
 static const struct snd_kcontrol_new mtk_afe_o10_mix[] = {
+	SOC_DAPM_SINGLE_AUTODISABLE("I04 Switch", AFE_CONN3, 3, 1, 0),
 	SOC_DAPM_SINGLE_AUTODISABLE("I18 Switch", AFE_CONN8, 0, 1, 0),
 };
 
 static const struct snd_soc_dapm_widget mtk_afe_pcm_widgets[] = {
 	/* inter-connections */
+	SND_SOC_DAPM_MIXER("I03", SND_SOC_NOPM, 0, 0, NULL, 0),
+	SND_SOC_DAPM_MIXER("I04", SND_SOC_NOPM, 0, 0, NULL, 0),
 	SND_SOC_DAPM_MIXER("I05", SND_SOC_NOPM, 0, 0, NULL, 0),
 	SND_SOC_DAPM_MIXER("I06", SND_SOC_NOPM, 0, 0, NULL, 0),
 	SND_SOC_DAPM_MIXER("I17", SND_SOC_NOPM, 0, 0, NULL, 0),
@@ -934,12 +941,16 @@ static const struct snd_soc_dapm_route mtk_afe_pcm_routes[] = {
 	{"I2S Playback", NULL, "O04"},
 	{"VUL", NULL, "O09"},
 	{"VUL", NULL, "O10"},
+	{"I03", NULL, "I2S Capture"},
+	{"I04", NULL, "I2S Capture"},
 	{"I17", NULL, "I2S Capture"},
 	{"I18", NULL, "I2S Capture"},
 	{ "O03", "I05 Switch", "I05" },
 	{ "O04", "I06 Switch", "I06" },
 	{ "O09", "I17 Switch", "I17" },
+	{ "O09", "I03 Switch", "I03" },
 	{ "O10", "I18 Switch", "I18" },
+	{ "O10", "I04 Switch", "I04" },
 };
 
 static const struct snd_soc_dapm_route mtk_afe_hdmi_routes[] = {
-- 
1.7.9.5



From pc.liao at mediatek.com  Wed Feb 24 23:16:38 2016
From: pc.liao at mediatek.com (PC Liao)
Date: Thu, 25 Feb 2016 15:16:38 +0800
Subject: [PATCH] ASoC: mediatek: Add machine driver for rt5650 rt5514 codec
Message-ID: <1456384598-43873-1-git-send-email-pc.liao@mediatek.com>

From: Koro Chen <koro.chen at mediatek.com>

This is the DPCM based machine driver with rt5650 and rt5514.

Signed-off-by: Koro Chen <koro.chen at mediatek.com>
Signed-off-by: PC Liao <pc.liao at mediatek.com>
---
 .../bindings/sound/mt8173-rt5650-rt5514.txt        |   15 ++
 sound/soc/mediatek/Kconfig                         |   28 ++-
 sound/soc/mediatek/Makefile                        |    3 +-
 sound/soc/mediatek/mt8173-rt5650-rt5514.c          |  258 ++++++++++++++++++++
 4 files changed, 294 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5514.txt
 create mode 100644 sound/soc/mediatek/mt8173-rt5650-rt5514.c

diff --git a/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5514.txt b/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5514.txt
new file mode 100644
index 0000000..e8b3c80
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5514.txt
@@ -0,0 +1,15 @@
+MT8173 with RT5650 RT5514 CODECS
+
+Required properties:
+- compatible : "mediatek,mt8173-rt5650-rt5514"
+- mediatek,audio-codec: the phandles of rt5650 and rt5514 codecs
+- mediatek,platform: the phandle of MT8173 ASoC platform
+
+Example:
+
+	sound {
+		compatible = "mediatek,mt8173-rt5650-rt5514";
+		mediatek,audio-codec = <&rt5650 &rt5514>;
+		mediatek,platform = <&afe>;
+	};
+
diff --git a/sound/soc/mediatek/Kconfig b/sound/soc/mediatek/Kconfig
index 6c88087..f7e789e 100644
--- a/sound/soc/mediatek/Kconfig
+++ b/sound/soc/mediatek/Kconfig
@@ -18,14 +18,25 @@ config SND_SOC_MT8173_MAX98090
 	  If unsure select "N".
 
 config SND_SOC_MT8173_RT5650
-        tristate "ASoC Audio driver for MT8173 with RT5650 codec"
-        depends on SND_SOC_MEDIATEK && I2C
-        select SND_SOC_RT5645
-        help
-          This adds ASoC driver for Mediatek MT8173 boards
-          with the RT5650 audio codec.
-          Select Y if you have such device.
-          If unsure select "N".
+	tristate "ASoC Audio driver for MT8173 with RT5650 codec"
+	depends on SND_SOC_MEDIATEK && I2C
+	select SND_SOC_RT5645
+	help
+	  This adds ASoC driver for Mediatek MT8173 boards
+	  with the RT5650 audio codec.
+	  Select Y if you have such device.
+	  If unsure select "N".
+
+config SND_SOC_MT8173_RT5650_RT5514
+	tristate "ASoC Audio driver for MT8173 with RT5650 RT5514 codecs"
+	depends on SND_SOC_MEDIATEK && I2C
+	select SND_SOC_RT5645
+	select SND_SOC_RT5514
+	help
+	  This adds ASoC driver for Mediatek MT8173 boards
+	  with the RT5650 and RT5514 codecs.
+	  Select Y if you have such device.
+	  If unsure select "N".
 
 config SND_SOC_MT8173_RT5650_RT5676
 	tristate "ASoC Audio driver for MT8173 with RT5650 RT5676 codecs"
@@ -37,4 +48,3 @@ config SND_SOC_MT8173_RT5650_RT5676
 	  with the RT5650 and RT5676 codecs.
 	  Select Y if you have such device.
 	  If unsure select "N".
-
diff --git a/sound/soc/mediatek/Makefile b/sound/soc/mediatek/Makefile
index bcdcb06..d486860 100644
--- a/sound/soc/mediatek/Makefile
+++ b/sound/soc/mediatek/Makefile
@@ -2,5 +2,6 @@
 obj-$(CONFIG_SND_SOC_MEDIATEK) += mtk-afe-pcm.o
 # Machine support
 obj-$(CONFIG_SND_SOC_MT8173_MAX98090) += mt8173-max98090.o
-obj-$(CONFIG_SND_SOC_MT8173_RT5650_RT5676) += mt8173-rt5650-rt5676.o
 obj-$(CONFIG_SND_SOC_MT8173_RT5650) += mt8173-rt5650.o
+obj-$(CONFIG_SND_SOC_MT8173_RT5650_RT5514) += mt8173-rt5650-rt5514.o
+obj-$(CONFIG_SND_SOC_MT8173_RT5650_RT5676) += mt8173-rt5650-rt5676.o
diff --git a/sound/soc/mediatek/mt8173-rt5650-rt5514.c b/sound/soc/mediatek/mt8173-rt5650-rt5514.c
new file mode 100644
index 0000000..58e0836
--- /dev/null
+++ b/sound/soc/mediatek/mt8173-rt5650-rt5514.c
@@ -0,0 +1,258 @@
+/*
+ * mt8173-rt5650-rt5514.c  --  MT8173 machine driver with RT5650/5514 codecs
+ *
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Koro Chen <koro.chen at mediatek.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 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+#include <sound/soc.h>
+#include <sound/jack.h>
+#include "../codecs/rt5645.h"
+
+#define MCLK_FOR_CODECS		12288000
+
+static const struct snd_soc_dapm_widget mt8173_rt5650_rt5514_widgets[] = {
+	SND_SOC_DAPM_SPK("Speaker", NULL),
+	SND_SOC_DAPM_MIC("Int Mic", NULL),
+	SND_SOC_DAPM_HP("Headphone", NULL),
+	SND_SOC_DAPM_MIC("Headset Mic", NULL),
+};
+
+static const struct snd_soc_dapm_route mt8173_rt5650_rt5514_routes[] = {
+	{"Speaker", NULL, "SPOL"},
+	{"Speaker", NULL, "SPOR"},
+	{"Sub DMIC1L", NULL, "Int Mic"},
+	{"Sub DMIC1R", NULL, "Int Mic"},
+	{"Headphone", NULL, "HPOL"},
+	{"Headphone", NULL, "HPOR"},
+	{"Headset Mic", NULL, "micbias1"},
+	{"Headset Mic", NULL, "micbias2"},
+	{"IN1P", NULL, "Headset Mic"},
+	{"IN1N", NULL, "Headset Mic"},
+};
+
+static const struct snd_kcontrol_new mt8173_rt5650_rt5514_controls[] = {
+	SOC_DAPM_PIN_SWITCH("Speaker"),
+	SOC_DAPM_PIN_SWITCH("Int Mic"),
+	SOC_DAPM_PIN_SWITCH("Headphone"),
+	SOC_DAPM_PIN_SWITCH("Headset Mic"),
+};
+
+static int mt8173_rt5650_rt5514_hw_params(struct snd_pcm_substream *substream,
+					  struct snd_pcm_hw_params *params)
+{
+	struct snd_soc_pcm_runtime *rtd = substream->private_data;
+	int i, ret;
+
+	for (i = 0; i < rtd->num_codecs; i++) {
+		struct snd_soc_dai *codec_dai = rtd->codec_dais[i];
+
+		/* pll from mclk 12.288M */
+		ret = snd_soc_dai_set_pll(codec_dai, 0, 0, MCLK_FOR_CODECS,
+					  params_rate(params) * 512);
+		if (ret)
+			return ret;
+
+		/* sysclk from pll */
+		ret = snd_soc_dai_set_sysclk(codec_dai, 1,
+					     params_rate(params) * 512,
+					     SND_SOC_CLOCK_IN);
+		if (ret)
+			return ret;
+	}
+	return 0;
+}
+
+static struct snd_soc_ops mt8173_rt5650_rt5514_ops = {
+	.hw_params = mt8173_rt5650_rt5514_hw_params,
+};
+
+static struct snd_soc_jack mt8173_rt5650_rt5514_jack;
+
+static int mt8173_rt5650_rt5514_init(struct snd_soc_pcm_runtime *runtime)
+{
+	struct snd_soc_card *card = runtime->card;
+	struct snd_soc_codec *codec = runtime->codec_dais[0]->codec;
+	int ret;
+
+	rt5645_sel_asrc_clk_src(codec,
+				RT5645_DA_STEREO_FILTER |
+				RT5645_AD_STEREO_FILTER,
+				RT5645_CLK_SEL_I2S1_ASRC);
+
+	/* enable jack detection */
+	ret = snd_soc_card_jack_new(card, "Headset Jack",
+				    SND_JACK_HEADPHONE | SND_JACK_MICROPHONE |
+				    SND_JACK_BTN_0 | SND_JACK_BTN_1 |
+				    SND_JACK_BTN_2 | SND_JACK_BTN_3,
+				    &mt8173_rt5650_rt5514_jack, NULL, 0);
+	if (ret) {
+		dev_err(card->dev, "Can't new Headset Jack %d\n", ret);
+		return ret;
+	}
+
+	return rt5645_set_jack_detect(codec,
+				      &mt8173_rt5650_rt5514_jack,
+				      &mt8173_rt5650_rt5514_jack,
+				      &mt8173_rt5650_rt5514_jack);
+}
+
+static struct snd_soc_dai_link_component mt8173_rt5650_rt5514_codecs[] = {
+	{
+		.dai_name = "rt5645-aif1",
+	},
+	{
+		.dai_name = "rt5514-aif1",
+	},
+};
+
+enum {
+	DAI_LINK_PLAYBACK,
+	DAI_LINK_CAPTURE,
+	DAI_LINK_CODEC_I2S,
+};
+
+/* Digital audio interface glue - connects codec <---> CPU */
+static struct snd_soc_dai_link mt8173_rt5650_rt5514_dais[] = {
+	/* Front End DAI links */
+	[DAI_LINK_PLAYBACK] = {
+		.name = "rt5650_rt5514 Playback",
+		.stream_name = "rt5650_rt5514 Playback",
+		.cpu_dai_name = "DL1",
+		.codec_name = "snd-soc-dummy",
+		.codec_dai_name = "snd-soc-dummy-dai",
+		.trigger = {SND_SOC_DPCM_TRIGGER_POST, SND_SOC_DPCM_TRIGGER_POST},
+		.dynamic = 1,
+		.dpcm_playback = 1,
+	},
+	[DAI_LINK_CAPTURE] = {
+		.name = "rt5650_rt5514 Capture",
+		.stream_name = "rt5650_rt5514 Capture",
+		.cpu_dai_name = "VUL",
+		.codec_name = "snd-soc-dummy",
+		.codec_dai_name = "snd-soc-dummy-dai",
+		.trigger = {SND_SOC_DPCM_TRIGGER_POST, SND_SOC_DPCM_TRIGGER_POST},
+		.dynamic = 1,
+		.dpcm_capture = 1,
+	},
+	/* Back End DAI links */
+	[DAI_LINK_CODEC_I2S] = {
+		.name = "Codec",
+		.cpu_dai_name = "I2S",
+		.no_pcm = 1,
+		.codecs = mt8173_rt5650_rt5514_codecs,
+		.num_codecs = 2,
+		.init = mt8173_rt5650_rt5514_init,
+		.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
+			   SND_SOC_DAIFMT_CBS_CFS,
+		.ops = &mt8173_rt5650_rt5514_ops,
+		.ignore_pmdown_time = 1,
+		.dpcm_playback = 1,
+		.dpcm_capture = 1,
+	},
+};
+
+static struct snd_soc_codec_conf mt8173_rt5650_rt5514_codec_conf[] = {
+	{
+		.name_prefix = "Sub",
+	},
+};
+
+static struct snd_soc_card mt8173_rt5650_rt5514_card = {
+	.name = "mtk-rt5650-rt5514",
+	.owner = THIS_MODULE,
+	.dai_link = mt8173_rt5650_rt5514_dais,
+	.num_links = ARRAY_SIZE(mt8173_rt5650_rt5514_dais),
+	.codec_conf = mt8173_rt5650_rt5514_codec_conf,
+	.num_configs = ARRAY_SIZE(mt8173_rt5650_rt5514_codec_conf),
+	.controls = mt8173_rt5650_rt5514_controls,
+	.num_controls = ARRAY_SIZE(mt8173_rt5650_rt5514_controls),
+	.dapm_widgets = mt8173_rt5650_rt5514_widgets,
+	.num_dapm_widgets = ARRAY_SIZE(mt8173_rt5650_rt5514_widgets),
+	.dapm_routes = mt8173_rt5650_rt5514_routes,
+	.num_dapm_routes = ARRAY_SIZE(mt8173_rt5650_rt5514_routes),
+};
+
+static int mt8173_rt5650_rt5514_dev_probe(struct platform_device *pdev)
+{
+	struct snd_soc_card *card = &mt8173_rt5650_rt5514_card;
+	struct device_node *platform_node;
+	int i, ret;
+
+	platform_node = of_parse_phandle(pdev->dev.of_node,
+					 "mediatek,platform", 0);
+	if (!platform_node) {
+		dev_err(&pdev->dev, "Property 'platform' missing or invalid\n");
+		return -EINVAL;
+	}
+
+	for (i = 0; i < card->num_links; i++) {
+		if (mt8173_rt5650_rt5514_dais[i].platform_name)
+			continue;
+		mt8173_rt5650_rt5514_dais[i].platform_of_node = platform_node;
+	}
+
+	mt8173_rt5650_rt5514_codecs[0].of_node =
+		of_parse_phandle(pdev->dev.of_node, "mediatek,audio-codec", 0);
+	if (!mt8173_rt5650_rt5514_codecs[0].of_node) {
+		dev_err(&pdev->dev,
+			"Property 'audio-codec' missing or invalid\n");
+		return -EINVAL;
+	}
+	mt8173_rt5650_rt5514_codecs[1].of_node =
+		of_parse_phandle(pdev->dev.of_node, "mediatek,audio-codec", 1);
+	if (!mt8173_rt5650_rt5514_codecs[1].of_node) {
+		dev_err(&pdev->dev,
+			"Property 'audio-codec' missing or invalid\n");
+		return -EINVAL;
+	}
+	mt8173_rt5650_rt5514_codec_conf[0].of_node =
+		mt8173_rt5650_rt5514_codecs[1].of_node;
+
+	card->dev = &pdev->dev;
+	platform_set_drvdata(pdev, card);
+
+	ret = devm_snd_soc_register_card(&pdev->dev, card);
+	if (ret)
+		dev_err(&pdev->dev, "%s snd_soc_register_card fail %d\n",
+			__func__, ret);
+	return ret;
+}
+
+static const struct of_device_id mt8173_rt5650_rt5514_dt_match[] = {
+	{ .compatible = "mediatek,mt8173-rt5650-rt5514", },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, mt8173_rt5650_rt5514_dt_match);
+
+static struct platform_driver mt8173_rt5650_rt5514_driver = {
+	.driver = {
+		   .name = "mtk-rt5650-rt5514",
+		   .of_match_table = mt8173_rt5650_rt5514_dt_match,
+#ifdef CONFIG_PM
+		   .pm = &snd_soc_pm_ops,
+#endif
+	},
+	.probe = mt8173_rt5650_rt5514_dev_probe,
+};
+
+module_platform_driver(mt8173_rt5650_rt5514_driver);
+
+/* Module information */
+MODULE_DESCRIPTION("MT8173 RT5650 and RT5514 SoC machine driver");
+MODULE_AUTHOR("Koro Chen <koro.chen at mediatek.com>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:mtk-rt5650-rt5514");
+
-- 
1.7.9.5



From olof at lixom.net  Wed Feb 24 23:20:33 2016
From: olof at lixom.net (Olof Johansson)
Date: Wed, 24 Feb 2016 23:20:33 -0800
Subject: [PATCH 2/9] ARM: dts: uniphier: rework UniPhier System Bus nodes
In-Reply-To: <CAK7LNARSXAw42bU4x+rgbWVmoru_5C8CMUHvTN22qm4eCDSvKA@mail.gmail.com>
References: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
 <1455588911-9827-3-git-send-email-yamada.masahiro@socionext.com>
 <20160225002641.GC10126@localhost>
 <CAK7LNARSXAw42bU4x+rgbWVmoru_5C8CMUHvTN22qm4eCDSvKA@mail.gmail.com>
Message-ID: <CAOesGMimq4Xf3sUB4bkkdr7whiaRDaL6JM1Nu2zN_QfJSHoQxg@mail.gmail.com>

On Wed, Feb 24, 2016 at 6:22 PM, Masahiro Yamada
<yamada.masahiro at socionext.com> wrote:
> Hi Olof,
>
>
> 2016-02-25 9:26 GMT+09:00 Olof Johansson <olof at lixom.net>:
>> Hi,
>>
>> On Tue, Feb 16, 2016 at 11:15:04AM +0900, Masahiro Yamada wrote:
>>
>>> diff --git a/arch/arm/mach-uniphier/platsmp.c b/arch/arm/mach-uniphier/platsmp.c
>>> index e1cfc1d..b53a8d9 100644
>>> --- a/arch/arm/mach-uniphier/platsmp.c
>>> +++ b/arch/arm/mach-uniphier/platsmp.c
>>> @@ -30,7 +30,7 @@
>>>   * The secondary CPUs check this register from the boot ROM for the jump
>>>   * destination.  After that, it can be reused as a scratch register.
>>>   */
>>> -#define UNIPHIER_SBC_ROM_BOOT_RSV2   0x1208
>>> +#define UNIPHIER_SMPCTRL_ROM_BOOT_RSV2       0x208
>>>
>>>  static void __iomem *uniphier_smp_rom_boot_rsv2;
>>>  static unsigned int uniphier_smp_max_cpus;
>>> @@ -98,15 +98,14 @@ static int __init uniphier_smp_prepare_trampoline(unsigned int max_cpus)
>>>       phys_addr_t rom_rsv2_phys;
>>>       int ret;
>>>
>>> -     np = of_find_compatible_node(NULL, NULL,
>>> -                             "socionext,uniphier-system-bus-controller");
>>> -     ret = of_address_to_resource(np, 1, &res);
>>> +     np = of_find_compatible_node(NULL, NULL, "socionext,uniphier-smpctrl");
>>> +     ret = of_address_to_resource(np, 0, &res);
>>>       if (ret) {
>>> -             pr_err("failed to get resource of system-bus-controller\n");
>>> +             pr_err("failed to get resource of uniphier-smpctrl\n");
>>>               return ret;
>>>       }
>>>
>>> -     rom_rsv2_phys = res.start + UNIPHIER_SBC_ROM_BOOT_RSV2;
>>> +     rom_rsv2_phys = res.start + UNIPHIER_SMPCTRL_ROM_BOOT_RSV2;
>>>
>>>       ret = uniphier_smp_copy_trampoline(rom_rsv2_phys);
>>>       if (ret)
>>
>> The previous binding has already been released. You can update, but your driver
>> should be able to handle the previous binding.
>>
>> So, you still need to keep the old code around.
>>
>> This has the benefit of breaking the dependency between the code change and the
>> DT change, so you no longer have to change your platform code at the same time
>> as the DT to avoid regressions.
>>
>>
>> Please adjust and resend. I'll hold off applying the series until then, so we
>> don't have a partially applied series.
>
>
>
> How long do I have to keep the support for the old binding?

You know your platform best -- how many users do you think you have
out there that might have built DTS files based on the old binding?

If there's a good chance there are none, or if you're in good contact
with them and can ask them to update, then you can be more flexible.

> [1]
> Everyone makes mistakes.
> The constraint for the DT-binding is really really painful.
>
> This is how it happened.
>
> At first, I implemented uniphier-system-bus.c based on the old binding.
> Then, during the review, Mark suggested me to change the driver design:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/387938.html
>
> I followed his suggestion, but I needed to changed the DT-binding as well.
> Before that time, the DT and other support code for UniPhier had been
> partially merged
> in the mainline.  So, in the current tree exist two bindings that are
> not compatible to
> each other.  This situation is really a mess.
> I want to clean up the code as soon as possible.

Yeah, I understand that it's hard to come up with perfect bindings
from day one, and that's why we sometimes have to play by ear.

It's not a bad idea to get practice on how to solve it -- in this case
it wouldn't really bad that bad. If you use variables to hold the base
addresses, and get them from either binding, you'll only special-case
during probe and not anywhere else in the driver.

The general idea of decoupling DT changes from code changes is also a
good habit.

> [2]
> For now, DT is mostly developed in the kernel tree in practice,
> while DT is not theoretically only for Linux.
> Everybody (at least every user of UniPhier SoCs) uses the combination
> of a DTB and a kernel image
> generated from the same Linux tree.
> I see no reason to use a new DTB + an old kernel image, or vice versa.

We're not aiming to support new DTB + old kernel image. The main
problem is if someone has a product DTB that's not yet merged, and you
change the binding, then their DTB might no longer work. It's not a
huge deal, and for most changes it's fairly harmless, but the general
principle still applies.

As I said earlier, you know the users of your platform the best (I
hope :), so you'll have the best feel for whether this is a breakage
they will hurt from or not.

> [3]
> This binding is UniPhier-specific.  No impact on other SoC vendors.
> Everything is under my control.
>
>
>
> For now, I will prepare the logic to support the old binding,
> but for the reasons above, please let me drop the support for the old
> one some time later.

Yeah, I'm perfectly fine with not keeping it for a long time. For
example, feel free to remove it next release if you think that will
work for your downstream users.


-Olof


From ard.biesheuvel at linaro.org  Wed Feb 24 23:49:47 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 25 Feb 2016 08:49:47 +0100
Subject: [RFC PATCH 1/2] memremap: add arch specific hook for MEMREMAP_WB
 mappings
In-Reply-To: <87twkzukup.fsf@belgarion.home>
References: <1456149728-16706-1-git-send-email-ard.biesheuvel@linaro.org>
 <1456149728-16706-2-git-send-email-ard.biesheuvel@linaro.org>
 <CAPcyv4ivN9c8PHBR77vd36ovB28OETJUr6VYf_8gNtXgqEmATw@mail.gmail.com>
 <CAKv+Gu9OWVgo+Qm85jPjY7xJ1UELm-4LYORHKF8Yy+_HuzmtGw@mail.gmail.com>
 <20160222200227.GF19428@n2100.arm.linux.org.uk>
 <CAKv+Gu9gwnuu7hnYpjv7ozuKYmC8ApMakSJmYvQMaevNEd5zvA@mail.gmail.com>
 <20160223115835.GI19428@n2100.arm.linux.org.uk>
 <CAKv+Gu8oCnu6kv5SxUAdWE_Z0V+PMAKDgM6MxTi4mTm5z6EFqA@mail.gmail.com>
 <CAKv+Gu_iEOC6E+N28pp9eEJxWFYTgLaQcBYEy1SvTUHT=cybYA@mail.gmail.com>
 <CAPcyv4h86uzieFV4HM-tZoWSVZ7GY2GKEUk334J+5sD_GyzWKg@mail.gmail.com>
 <87twkzukup.fsf@belgarion.home>
Message-ID: <CAKv+Gu9uLmpW9isw9e8bQ8=tsA1VAGiLjm795dWjgicyueSzcA@mail.gmail.com>

On 23 February 2016 at 23:23, Robert Jarzmik <robert.jarzmik at free.fr> wrote:
> Dan Williams <dan.j.williams at intel.com> writes:
>
>> On Tue, Feb 23, 2016 at 4:26 AM, Ard Biesheuvel
>> <ard.biesheuvel at linaro.org> wrote:
>>> On 23 February 2016 at 13:03, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>>>> On 23 February 2016 at 12:58, Russell King - ARM Linux
>>>> <linux at arm.linux.org.uk> wrote:
>>>>> On Mon, Feb 22, 2016 at 09:35:24PM +0100, Ard Biesheuvel wrote:
>>> OK, I see what you mean. I find it unfortunate that ioremap_cache()
>>> instances are blindly being replaced with memremap(), and I wonder if
>>> this wasted test by and/or cc'ed to people who can actually test this
>>> driver. Dan?
>
> Actually I have the hardware to test it.
>
> And I also know what is behind :
>  - it's a CFI NOR based memory
>  - these are Intel StrataFlash 28F128J3A chips
>  - as a CFI memory it is mapped on the system bus
>  - from a read perspective, it behaves like a normal memory
>  - but once the first write reaches the CFI, everything changes (the address
>    space layout doesn't have the same meaning, be that becoming a status code or
>    something else).
>    In these conditions reordering of writes versus reads, merging reads after
>    a write or coalescing writes is a recipe for disaster.
>
> All of this to say I can make a small discrete number of tests (less than 10
> write or erase ones to preserve the precious NOR).
>

Thanks Robert.

But to be honest, I think we should simply revert the change, after
which we can wire up memremap() for ARM properly. And while I agree
that ioremap_cache() is often abused for mapping things like ACPI
tables in RAM (which forces you to cast away the __iomem annotation),
using ioremap_cache() to map NOR flash is totally different IMO, even
if it has memory semantics while in array mode.


From liguo.zhang at mediatek.com  Wed Feb 24 16:01:07 2016
From: liguo.zhang at mediatek.com (Liguo Zhang)
Date: Thu, 25 Feb 2016 08:01:07 +0800
Subject: [PATCH] i2c: mediatek: i2c multi transfer optimization
Message-ID: <1456358467-529-1-git-send-email-liguo.zhang@mediatek.com>

Send the next transfer in the i2c irq handler, and only signal
complete() when the entire transaction has been completed.

Signed-off-by: Liguo Zhang <liguo.zhang at mediatek.com>
---
 drivers/i2c/busses/i2c-mt65xx.c | 220 ++++++++++++++++++++++------------------
 1 file changed, 123 insertions(+), 97 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 453358b..15ce3b8 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -139,6 +139,15 @@ struct mtk_i2c_compatible {
 	unsigned char support_33bits: 1;
 };
 
+struct mtk_i2c_transaction {
+	u32 num;
+	u32 index;
+	dma_addr_t wpaddr;
+	dma_addr_t rpaddr;
+	struct i2c_msg *msgs;
+	int result;
+};
+
 struct mtk_i2c {
 	struct i2c_adapter adap;	/* i2c host adapter */
 	struct device *dev;
@@ -161,6 +170,7 @@ struct mtk_i2c {
 	unsigned char auto_restart;
 	bool ignore_restart_irq;
 	const struct mtk_i2c_compatible *dev_comp;
+	struct mtk_i2c_transaction transac;
 };
 
 static const struct i2c_adapter_quirks mt6577_i2c_quirks = {
@@ -378,8 +388,7 @@ static inline u32 mtk_i2c_set_4g_mode(dma_addr_t addr)
 	return (addr & BIT_ULL(32)) ? I2C_DMA_4G_MODE : I2C_DMA_CLR_FLAG;
 }
 
-static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
-			       int num, int left_num)
+static int mtk_i2c_start_transfer(struct mtk_i2c *i2c)
 {
 	u16 addr_reg;
 	u16 start_reg;
@@ -388,15 +397,31 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 	u32 reg_4g_mode;
 	dma_addr_t rpaddr = 0;
 	dma_addr_t wpaddr = 0;
-	int ret;
+	struct i2c_msg *msg;
+	struct mtk_i2c_transaction *i2c_transac;
+	int num;
+	int left_num;
 
 	i2c->irq_stat = 0;
 
+	i2c_transac = &i2c->transac;
+	num = i2c_transac->num;
+	left_num = i2c_transac->num - i2c_transac->index - 1;
+	msg = &i2c_transac->msgs[i2c_transac->index];
+
+	if (!msg->buf)
+		return -EINVAL;
+
+	if (i2c->op == I2C_MASTER_WRRD)
+		left_num--;
+	else if (msg->flags & I2C_M_RD)
+		i2c->op = I2C_MASTER_RD;
+	else
+		i2c->op = I2C_MASTER_WR;
+
 	if (i2c->auto_restart)
 		restart_flag = I2C_RS_TRANSFER;
 
-	reinit_completion(&i2c->msg_complete);
-
 	control_reg = readw(i2c->base + OFFSET_CONTROL) &
 			~(I2C_CONTROL_DIR_CHANGE | I2C_CONTROL_RS);
 	if ((i2c->speed_hz > 400000) || (left_num >= 1))
@@ -413,7 +438,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 	else
 		writew(I2C_FS_START_CON, i2c->base + OFFSET_EXT_CONF);
 
-	addr_reg = msgs->addr << 1;
+	addr_reg = msg->addr << 1;
 	if (i2c->op == I2C_MASTER_RD)
 		addr_reg |= 0x1;
 
@@ -431,16 +456,16 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 	/* Set transfer and transaction len */
 	if (i2c->op == I2C_MASTER_WRRD) {
 		if (i2c->dev_comp->aux_len_reg) {
-			writew(msgs->len, i2c->base + OFFSET_TRANSFER_LEN);
-			writew((msgs + 1)->len, i2c->base +
+			writew(msg->len, i2c->base + OFFSET_TRANSFER_LEN);
+			writew((msg + 1)->len, i2c->base +
 			       OFFSET_TRANSFER_LEN_AUX);
 		} else {
-			writew(msgs->len | ((msgs + 1)->len) << 8,
+			writew(msg->len | ((msg + 1)->len) << 8,
 			       i2c->base + OFFSET_TRANSFER_LEN);
 		}
 		writew(I2C_WRRD_TRANAC_VALUE, i2c->base + OFFSET_TRANSAC_LEN);
 	} else {
-		writew(msgs->len, i2c->base + OFFSET_TRANSFER_LEN);
+		writew(msg->len, i2c->base + OFFSET_TRANSFER_LEN);
 		writew(num, i2c->base + OFFSET_TRANSAC_LEN);
 	}
 
@@ -448,8 +473,8 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 	if (i2c->op == I2C_MASTER_RD) {
 		writel(I2C_DMA_INT_FLAG_NONE, i2c->pdmabase + OFFSET_INT_FLAG);
 		writel(I2C_DMA_CON_RX, i2c->pdmabase + OFFSET_CON);
-		rpaddr = dma_map_single(i2c->dev, msgs->buf,
-					msgs->len, DMA_FROM_DEVICE);
+		rpaddr = dma_map_single(i2c->dev, msg->buf, msg->len,
+					DMA_FROM_DEVICE);
 		if (dma_mapping_error(i2c->dev, rpaddr))
 			return -ENOMEM;
 
@@ -459,12 +484,13 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 		}
 
 		writel((u32)rpaddr, i2c->pdmabase + OFFSET_RX_MEM_ADDR);
-		writel(msgs->len, i2c->pdmabase + OFFSET_RX_LEN);
+		writel(msg->len, i2c->pdmabase + OFFSET_RX_LEN);
+		i2c_transac->rpaddr = rpaddr;
 	} else if (i2c->op == I2C_MASTER_WR) {
 		writel(I2C_DMA_INT_FLAG_NONE, i2c->pdmabase + OFFSET_INT_FLAG);
 		writel(I2C_DMA_CON_TX, i2c->pdmabase + OFFSET_CON);
-		wpaddr = dma_map_single(i2c->dev, msgs->buf,
-					msgs->len, DMA_TO_DEVICE);
+		wpaddr = dma_map_single(i2c->dev, msg->buf, msg->len,
+					DMA_TO_DEVICE);
 		if (dma_mapping_error(i2c->dev, wpaddr))
 			return -ENOMEM;
 
@@ -474,20 +500,21 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 		}
 
 		writel((u32)wpaddr, i2c->pdmabase + OFFSET_TX_MEM_ADDR);
-		writel(msgs->len, i2c->pdmabase + OFFSET_TX_LEN);
+		writel(msg->len, i2c->pdmabase + OFFSET_TX_LEN);
+
+		i2c_transac->wpaddr = wpaddr;
 	} else {
 		writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_INT_FLAG);
 		writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_CON);
-		wpaddr = dma_map_single(i2c->dev, msgs->buf,
-					msgs->len, DMA_TO_DEVICE);
+		wpaddr = dma_map_single(i2c->dev, msg->buf, msg->len,
+					DMA_TO_DEVICE);
 		if (dma_mapping_error(i2c->dev, wpaddr))
 			return -ENOMEM;
-		rpaddr = dma_map_single(i2c->dev, (msgs + 1)->buf,
-					(msgs + 1)->len,
-					DMA_FROM_DEVICE);
+		rpaddr = dma_map_single(i2c->dev, (msg + 1)->buf,
+					(msg + 1)->len, DMA_FROM_DEVICE);
 		if (dma_mapping_error(i2c->dev, rpaddr)) {
-			dma_unmap_single(i2c->dev, wpaddr,
-					 msgs->len, DMA_TO_DEVICE);
+			dma_unmap_single(i2c->dev, wpaddr, msg->len,
+					 DMA_TO_DEVICE);
 			return -ENOMEM;
 		}
 
@@ -501,8 +528,11 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 
 		writel((u32)wpaddr, i2c->pdmabase + OFFSET_TX_MEM_ADDR);
 		writel((u32)rpaddr, i2c->pdmabase + OFFSET_RX_MEM_ADDR);
-		writel(msgs->len, i2c->pdmabase + OFFSET_TX_LEN);
-		writel((msgs + 1)->len, i2c->pdmabase + OFFSET_RX_LEN);
+		writel(msg->len, i2c->pdmabase + OFFSET_TX_LEN);
+		writel((msg + 1)->len, i2c->pdmabase + OFFSET_RX_LEN);
+
+		i2c_transac->wpaddr = wpaddr;
+		i2c_transac->rpaddr = rpaddr;
 	}
 
 	writel(I2C_DMA_START_EN, i2c->pdmabase + OFFSET_EN);
@@ -516,40 +546,6 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 	}
 	writew(start_reg, i2c->base + OFFSET_START);
 
-	ret = wait_for_completion_timeout(&i2c->msg_complete,
-					  i2c->adap.timeout);
-
-	/* Clear interrupt mask */
-	writew(~(restart_flag | I2C_HS_NACKERR | I2C_ACKERR |
-	       I2C_TRANSAC_COMP), i2c->base + OFFSET_INTR_MASK);
-
-	if (i2c->op == I2C_MASTER_WR) {
-		dma_unmap_single(i2c->dev, wpaddr,
-				 msgs->len, DMA_TO_DEVICE);
-	} else if (i2c->op == I2C_MASTER_RD) {
-		dma_unmap_single(i2c->dev, rpaddr,
-				 msgs->len, DMA_FROM_DEVICE);
-	} else {
-		dma_unmap_single(i2c->dev, wpaddr, msgs->len,
-				 DMA_TO_DEVICE);
-		dma_unmap_single(i2c->dev, rpaddr, (msgs + 1)->len,
-				 DMA_FROM_DEVICE);
-	}
-
-	if (ret == 0) {
-		dev_dbg(i2c->dev, "addr: %x, transfer timeout\n", msgs->addr);
-		mtk_i2c_init_hw(i2c);
-		return -ETIMEDOUT;
-	}
-
-	completion_done(&i2c->msg_complete);
-
-	if (i2c->irq_stat & (I2C_HS_NACKERR | I2C_ACKERR)) {
-		dev_dbg(i2c->dev, "addr: %x, transfer ACK error\n", msgs->addr);
-		mtk_i2c_init_hw(i2c);
-		return -ENXIO;
-	}
-
 	return 0;
 }
 
@@ -559,19 +555,27 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
 	int ret;
 	int left_num = num;
 	struct mtk_i2c *i2c = i2c_get_adapdata(adap);
+	struct mtk_i2c_transaction *i2c_transac = &i2c->transac;
+
+	i2c_transac->num = num;
+	i2c_transac->index = 0;
+	i2c_transac->msgs = msgs;
+	i2c_transac->result = 0;
+
+	reinit_completion(&i2c->msg_complete);
 
 	ret = mtk_i2c_clock_enable(i2c);
 	if (ret)
 		return ret;
 
+	i2c->op = 0;
 	i2c->auto_restart = i2c->dev_comp->auto_restart;
 
 	/* checking if we can skip restart and optimize using WRRD mode */
-	if (i2c->auto_restart && num == 2) {
-		if (!(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
-		    msgs[0].addr == msgs[1].addr) {
-			i2c->auto_restart = 0;
-		}
+	if (num == 2 && !(msgs[0].flags & I2C_M_RD) &&
+	    (msgs[1].flags & I2C_M_RD) && msgs[0].addr == msgs[1].addr) {
+		i2c->op = I2C_MASTER_WRRD;
+		i2c->auto_restart = 0;
 	}
 
 	if (i2c->auto_restart && num >= 2 && i2c->speed_hz > MAX_FS_MODE_SPEED)
@@ -582,33 +586,33 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
 	else
 		i2c->ignore_restart_irq = false;
 
-	while (left_num--) {
-		if (!msgs->buf) {
-			dev_dbg(i2c->dev, "data buffer is NULL.\n");
-			ret = -EINVAL;
-			goto err_exit;
-		}
+	/* always use DMA mode. */
+	ret = mtk_i2c_start_transfer(i2c);
+	if (ret < 0)
+		goto err_exit;
 
-		if (msgs->flags & I2C_M_RD)
-			i2c->op = I2C_MASTER_RD;
-		else
-			i2c->op = I2C_MASTER_WR;
-
-		if (!i2c->auto_restart) {
-			if (num > 1) {
-				/* combined two messages into one transaction */
-				i2c->op = I2C_MASTER_WRRD;
-				left_num--;
-			}
-		}
+	ret = wait_for_completion_timeout(&i2c->msg_complete,
+					  i2c->adap.timeout);
 
-		/* always use DMA mode. */
-		ret = mtk_i2c_do_transfer(i2c, msgs, num, left_num);
-		if (ret < 0)
-			goto err_exit;
+	if (ret == 0) {
+		dev_dbg(i2c->dev, "addr: %x, transfer timeout\n", msgs->addr);
+		mtk_i2c_init_hw(i2c);
+		ret = -ETIMEDOUT;
+		goto err_exit;
+	}
 
-		msgs++;
+	if (i2c->irq_stat & (I2C_HS_NACKERR | I2C_ACKERR)) {
+		dev_dbg(i2c->dev, "addr: %x, transfer ACK error\n", msgs->addr);
+		mtk_i2c_init_hw(i2c);
+		ret = -ENXIO;
+		goto err_exit;
+	}
+
+	if (i2c_transac->result) {
+		ret = i2c_transac->result;
+		goto err_exit;
 	}
+
 	/* the return value is number of executed messages */
 	ret = num;
 
@@ -621,29 +625,51 @@ static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id)
 {
 	struct mtk_i2c *i2c = dev_id;
 	u16 restart_flag = 0;
-	u16 intr_stat;
+	struct i2c_msg *msg;
+	struct mtk_i2c_transaction *i2c_transac = &i2c->transac;
 
 	if (i2c->auto_restart)
 		restart_flag = I2C_RS_TRANSFER;
 
-	intr_stat = readw(i2c->base + OFFSET_INTR_STAT);
-	writew(intr_stat, i2c->base + OFFSET_INTR_STAT);
+	/* Clear interrupt mask */
+	writew(~(restart_flag | I2C_HS_NACKERR | I2C_ACKERR |
+	       I2C_TRANSAC_COMP), i2c->base + OFFSET_INTR_MASK);
 
-	/*
-	 * when occurs ack error, i2c controller generate two interrupts
-	 * first is the ack error interrupt, then the complete interrupt
-	 * i2c->irq_stat need keep the two interrupt value.
-	 */
-	i2c->irq_stat |= intr_stat;
+	i2c->irq_stat = readw(i2c->base + OFFSET_INTR_STAT);
+	writew(i2c->irq_stat, i2c->base + OFFSET_INTR_STAT);
 
 	if (i2c->ignore_restart_irq && (i2c->irq_stat & restart_flag)) {
 		i2c->ignore_restart_irq = false;
 		i2c->irq_stat = 0;
+		/* Enable interrupt */
+		writew(restart_flag | I2C_HS_NACKERR | I2C_ACKERR |
+		       I2C_TRANSAC_COMP, i2c->base + OFFSET_INTR_MASK);
 		writew(I2C_RS_MUL_CNFG | I2C_RS_MUL_TRIG | I2C_TRANSAC_START,
 		       i2c->base + OFFSET_START);
 	} else {
-		if (i2c->irq_stat & (I2C_TRANSAC_COMP | restart_flag))
+		msg = &i2c_transac->msgs[i2c_transac->index];
+
+		if (i2c->op == I2C_MASTER_WR || i2c->op == I2C_MASTER_WRRD) {
+			dma_unmap_single(i2c->dev, i2c_transac->wpaddr,
+					 msg->len, DMA_TO_DEVICE);
+		}
+
+		if (i2c->op == I2C_MASTER_WRRD)
+			dma_unmap_single(i2c->dev, i2c_transac->rpaddr,
+					 (msg + 1)->len, DMA_FROM_DEVICE);
+
+		if (i2c->op == I2C_MASTER_RD)
+			dma_unmap_single(i2c->dev, i2c_transac->rpaddr,
+					 msg->len, DMA_FROM_DEVICE);
+
+		if (i2c->irq_stat & ~restart_flag) {
 			complete(&i2c->msg_complete);
+		} else {
+			i2c_transac->index++;
+			i2c_transac->result = mtk_i2c_start_transfer(i2c);
+			if (i2c_transac->result)
+				complete(&i2c->msg_complete);
+		}
 	}
 
 	return IRQ_HANDLED;
-- 
1.8.1.1.dirty



From yunhui.cui at nxp.com  Thu Feb 25 00:07:22 2016
From: yunhui.cui at nxp.com (Yunhui Cui)
Date: Thu, 25 Feb 2016 08:07:22 +0000
Subject: [PATCH v2 3/4] mtd:spi-nor:fsl-quadspi:Add fast-read mode support
In-Reply-To: <20160217180742.GB17485@shlinux2>
References: <1454326208-4533-1-git-send-email-B56489@freescale.com>
 <1454326208-4533-3-git-send-email-B56489@freescale.com>
 <20160217180742.GB17485@shlinux2>
Message-ID: <DB5PR0401MB1912C9D041FF2B408652F4CD94A60@DB5PR0401MB1912.eurprd04.prod.outlook.com>

Hi Han,

I have provided the options " m25p,fast-read ", because there are probable some flashes can't support quad mode.
So we should support fast-read mode in our driver. Moreover,  There is a option to select fast-read mode in spi_nor.c :
               /* If we were instantiated by DT, use it */
                 if (of_property_read_bool(np, "m25p,fast-read"))
                         nor->flash_read = SPI_NOR_FAST;

Thanks
Yunhui

-----Original Message-----
From: Han Xu [mailto:xhnjupt at gmail.com] 
Sent: Thursday, February 18, 2016 2:08 AM
To: Yunhui Cui
Cc: dwmw2 at infradead.org; computersforpeace at gmail.com; han.xu at freescale.com; linux-mtd at lists.infradead.org; linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Yao Yuan
Subject: Re: [PATCH v2 3/4] mtd:spi-nor:fsl-quadspi:Add fast-read mode support

On Mon, Feb 01, 2016 at 07:30:07PM +0800, Yunhui Cui wrote:
> The qspi driver add generic fast-read mode for different flash 
> venders. There are some different board flash work on different mode, 
> such fast-read, quad-mode.
> So we have to modify the third entrace parameter of spi_nor_scan().
> 
> Signed-off-by: Yunhui Cui <B56489 at freescale.com>
> ---
>  drivers/mtd/spi-nor/fsl-quadspi.c | 27 +++++++++++++++++++++------
>  1 file changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c 
> b/drivers/mtd/spi-nor/fsl-quadspi.c
> index 9861290..0a31cb1 100644
> --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> @@ -389,11 +389,21 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
>  	/* Read */
>  	lut_base = SEQID_READ * 4;
>  
> -	qspi_writel(q, LUT0(CMD, PAD1, read_op) | LUT1(ADDR, PAD1, addrlen),
> -			base + QUADSPI_LUT(lut_base));
> -	qspi_writel(q, LUT0(DUMMY, PAD1, read_dm) |
> -		    LUT1(FSL_READ, PAD4, rxfifo),
> -			base + QUADSPI_LUT(lut_base + 1));
> +	if (nor->flash_read == SPI_NOR_FAST) {
> +		qspi_writel(q, LUT0(CMD, PAD1, read_op) |
> +			    LUT1(ADDR, PAD1, addrlen),
> +				base + QUADSPI_LUT(lut_base));
> +		qspi_writel(q,  LUT0(DUMMY, PAD1, read_dm) |
> +			    LUT1(FSL_READ, PAD1, rxfifo),
> +				base + QUADSPI_LUT(lut_base + 1));
> +	} else if (nor->flash_read == SPI_NOR_QUAD) {
> +		qspi_writel(q, LUT0(CMD, PAD1, read_op) |
> +			    LUT1(ADDR, PAD1, addrlen),
> +				base + QUADSPI_LUT(lut_base));
> +		qspi_writel(q, LUT0(DUMMY, PAD1, read_dm) |
> +			    LUT1(FSL_READ, PAD4, rxfifo),
> +				base + QUADSPI_LUT(lut_base + 1));
> +	}
>  
>  	/* Write enable */
>  	lut_base = SEQID_WREN * 4;
> @@ -468,6 +478,7 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, 
> u8 cmd)  {
>  	switch (cmd) {
>  	case SPINOR_OP_READ_1_1_4:
> +	case SPINOR_OP_READ_FAST:
>  		return SEQID_READ;
>  	case SPINOR_OP_WREN:
>  		return SEQID_WREN;
> @@ -963,6 +974,7 @@ static int fsl_qspi_probe(struct platform_device *pdev)
>  	struct spi_nor *nor;
>  	struct mtd_info *mtd;
>  	int ret, i = 0;
> +	enum read_mode mode = SPI_NOR_QUAD;
>  
>  	q = devm_kzalloc(dev, sizeof(*q), GFP_KERNEL);
>  	if (!q)
> @@ -1064,7 +1076,10 @@ static int fsl_qspi_probe(struct platform_device *pdev)
>  		/* set the chip address for READID */
>  		fsl_qspi_set_base_addr(q, nor);
>  
> -		ret = spi_nor_scan(nor, NULL, SPI_NOR_QUAD);
> +		ret = of_property_read_bool(np, "m25p,fast-read");
> +		mode = (ret) ? SPI_NOR_FAST : SPI_NOR_QUAD;
> +
> +		ret = spi_nor_scan(nor, NULL, mode);
>  		if (ret)
>  			goto mutex_failed;
>  
I understand you want to provide a more generic read mode, but this is a quad spi driver, I prefer to provide the options, either quad read/quad IO read, or just normal read.
> --
> 2.1.0.27.g96db324
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/


From thomas.petazzoni at free-electrons.com  Thu Feb 25 00:09:27 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 25 Feb 2016 09:09:27 +0100
Subject: [PATCH 1/3] dt-bindings: arm/marvell: ABI unstability warning
 about Marvell 7K/8K
In-Reply-To: <CAL_JsqLevrujSeYNBvSJA-5T0Ho8y7c0fKid7QvVm8LLvYLotw@mail.gmail.com>
References: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1456327007-31008-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160224172545.GC9137@leverpostej>
 <20160224211045.379352d3@free-electrons.com>
 <CAL_JsqLevrujSeYNBvSJA-5T0Ho8y7c0fKid7QvVm8LLvYLotw@mail.gmail.com>
Message-ID: <20160225090927.13492cfb@free-electrons.com>

Hello Rob,

On Wed, 24 Feb 2016 16:07:04 -0600, Rob Herring wrote:

> You should fix the incomplete information problem. I pushed back on
> this, you got more information and already the binding is closer to
> reality.

"You should fix the incomplete information problem". You seem to think
that it is a simple thing that can be fixed with a magic wand. But it's
not.

Either because the internal processes are complicated, or simply
because the Linux kernel support is done without cooperation from the
HW vendor (it's not the case of this Marvell platform, but it's the
case of many other platforms).

> Mark didn't say don't submit. First, there is value in submitting even
> if not accepted immediately and you have to carry some patches for
> some time. It was also suggested that you err on the side of less
> information in DT if things are uncertain and you have not done that.

Submitting without merging is useless. The point of submitting is to
get the code merged, to reduce the amount of out-of-tree patches we
have to carry, and to allow users of the platform to simply run
mainline on their platform.

So this proposal really doesn't make any sense. Just like Mark initial
statement of not submitting code so early.

> > So please get to an agreement between DT binding maintainers. And stop
> > saying this ridiculous statement that HW vendors should stop submitting
> > their code to the mainline.
> 
> You want us to agree, then you won't like the answer. Bindings must be
> stable. I'll allow exceptions to that, but not without push back.
> 
> In general, if there is disagreement about whether stability is
> required, then it is required. See the recent sunxi discussion. That's
> more between users and platform maintainers though.

Do you realize that this all DT binding stuff is today the *biggest* to
getting HW support in the Linux kernel? It has become more complicated
to merge a 4 properties DT binding than to merge multiple thousands of
lines of driver code. Simply because of this DT stability fairy tale.

In the mean time, I'm withdrawing this patch. I'll let Mark and you in
your Alice in Wonderland world, where you believe that DT bindings are
stable while the reality is that they are not and that their stability
is actually unneeded for most platforms.

Gregory, can you skip patch 1/3, and merge patches 2/3 and 3/3, once
the new clock DT binding has been approved.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From kishon at ti.com  Thu Feb 25 00:13:48 2016
From: kishon at ti.com (Kishon Vijay Abraham I)
Date: Thu, 25 Feb 2016 13:43:48 +0530
Subject: [PATCH 0/5] Modularize PCI_DW related drivers.
In-Reply-To: <6350001.oOdGGcH81x@wuerfel>
References: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
 <56CD4916.3050904@ti.com> <6350001.oOdGGcH81x@wuerfel>
Message-ID: <56CEB7BC.7010803@ti.com>

Hi Arnd,

On Wednesday 24 February 2016 02:34 PM, Arnd Bergmann wrote:
> On Wednesday 24 February 2016 11:39:26 Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Monday 08 February 2016 05:30 AM, Paul Gortmaker wrote:
>>> In a recent patch series that aimed to remove code related to module
>>> unload for PCI support that was simply non modular, the discussion
>>> led to people wanting to keep the code and push towards taking the
>>> steps needed to support moving it towards tristate instead[1].
>>>
>>> Here, we take step one, which is simply making the Kconfig change
>>> and then dealing with any build fallout or modpost fallout.  What
>>> amounts to essentially a sanity build test.  To be clear, these
>>> have not been runtime validated; that will need to be done by those
>>> with access to real hardware.  However, the changes are not anything
>>> that should disrupt any existing built-in validation, so real world
>>> users should not be impacted by this change.
>>>
>>> We start with a smaller family of drivers; those that actively select
>>> PCI_DW, as a nice self contained group to test the waters and see if
>>> everyone is still good with this approach before investing more time
>>> on a wider scale to other pci/host/ code blocks.
>>>
>>> As such the drivers here share a dependency on having the same group
>>> of functions exported in order to successfully complete modpost.
>>>
>>> In addition, we have to stray outside drivers/pci to add exports
>>> in two places; once for an ARM fault handler, and once for an OF
>>> variable.
>>>
>>> The pci-keystone-dw.c instance was handled separately because it
>>> consists of two source files that need their own group of driver
>>> specific exports above and beyond the "shared" ones.
>>>
>>> Then we convert the Kconfig for all remaining at once; we could have
>>> done it on a per driver basis for ease of revert if anyone really
>>> objects, but since it would be a one line change, that seemed like
>>> not a real concern.
>>>
>>> Build testing was done on the linux-next tree for arm allmodconfig.
>>
>> I took these patches and gave a test with DRA7xx board. As expected there was
>> no issues when the driver was built-in. However when I tried to rmmod/modprobe
>> I got this error [2].
> 
> Thanks for testing this!
> 
>> [2] -> http://pastebin.ubuntu.com/15185894/
> 
> It looks like you are hitting the BUG_ON() in ioremap_pte_range()
> that checks if a virtual address already has a page table entry,
> which in turn is probably a result of dw_pcie_host_init()
> calling pci_remap_iospace() again for the same memory area
> it has called the last time, and no cleanup done inbetween.
> 
> Could you try adding a pci_unmap_iospace() and calling that
> in the device remove function? Let me know if you need help
> implementing it.

That didn't look straight forward to me :-( I'll try to see this next week. Any
help from you will make it simpler for me.

Thanks
Kishon


From peter.ujfalusi at ti.com  Thu Feb 25 00:28:59 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 25 Feb 2016 10:28:59 +0200
Subject: [PATCH] dmaengine: omap-dma: Do not call omap_dma_callback() from
 tx_status()
Message-ID: <1456388939-15722-1-git-send-email-peter.ujfalusi@ti.com>

When based on the CCR_ENABLE bit the channel is stopped we should not call
omap_dma_callback(), only change the return value to DMA_COMPLETE. Client
drivers will do the right thing to clean up the channel after the transfer
has been completed.
Check the CCR_ENABLE only if the channel is not paused since pause in sDMA
means that the channel is stopped.
This will fix one hard to reproduce race condition when the channel is
terminated during transfer (affecting cyclic operation).

Fixes: 1a7cf7b26f25 ("dmaengine: omap-dma: Handle cases when the channel is polled for completion")

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 drivers/dma/omap-dma.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index f6bef0d93998..a6b189fdbbe6 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -671,18 +671,22 @@ static enum dma_status omap_dma_tx_status(struct dma_chan *chan,
 	struct omap_chan *c = to_omap_dma_chan(chan);
 	struct virt_dma_desc *vd;
 	enum dma_status ret;
-	uint32_t ccr;
 	unsigned long flags;
 
-	ccr = omap_dma_chan_read(c, CCR);
-	/* The channel is no longer active, handle the completion right away */
-	if (!(ccr & CCR_ENABLE))
-		omap_dma_callback(c->dma_ch, 0, c);
-
 	ret = dma_cookie_status(chan, cookie, txstate);
 	if (ret == DMA_COMPLETE || !txstate)
 		return ret;
 
+	if (!c->paused) {
+		uint32_t ccr = omap_dma_chan_read(c, CCR);
+		/*
+		 * The channel is no longer active, set the return value
+		 * accordingly
+		 */
+		if (!(ccr & CCR_ENABLE))
+			ret = DMA_COMPLETE;
+	}
+
 	spin_lock_irqsave(&c->vc.lock, flags);
 	vd = vchan_find_desc(&c->vc, cookie);
 	if (vd) {
-- 
2.7.1



From pankaj.dubey at samsung.com  Thu Feb 25 00:33:36 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Thu, 25 Feb 2016 14:03:36 +0530
Subject: [RESPIN 0/6] Add support for Exynos SROM Controller driver.
Message-ID: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>

This series is collection of patches already reviewed and merged in
maintainer's tree, but could not make it thorugh main linus tree, due
to last moment suggestion of proper location of driver should be
"drivers/memory" instead of "drivers/soc". I have rebased all the patches
and moved into "drivers/memory/samsung".

As this is just a movement without changing actual driver code,
I have not removed "Reviewed-By", "Tested-By" or "Acked-By".

To make sure everything is fine, I have again tested it on Exynos5880 based
Chromebook for normal boot, S2R functionality and its working fine.

This series has been prepared on top of next-soc branch of Krzysztof's tree.

Changes w.r.t. original merged patches:
 - Moved exynos-srom driver into "drivers/memory/samsung"
 - Moved DT binding documentation into "bindings/memory-controller"
 - Added new patch for entry of new directory in MAINTAINERS file.
 - Added new CONFIG as SAMSUNG_MC for grouping Samsung's memory controller drivers.
 - Added my Signed-off-by for patch 5/6 and 6/6 for touching it.

Pankaj Dubey (4):
  dt-bindings: EXYNOS: Add exynos-srom device tree binding
  drivers: memory: Add support for exynos SROM driver
  MAINTAINERS: Add maintainers entry for drivers/memory/samsung
  ARM: EXYNOS: Remove SROM related register settings from mach-exynos

Pavel Fedin (2):
  dt-bindings: EXYNOS: Describe SROMc configuration
  drivers: memory: exynos-srom: Add support for bank configuration

 .../bindings/memory-controllers/exynos-srom.txt    |  81 +++++++
 MAINTAINERS                                        |   1 +
 arch/arm/mach-exynos/Kconfig                       |   2 +
 arch/arm/mach-exynos/exynos.c                      |  17 --
 arch/arm/mach-exynos/include/mach/map.h            |   3 -
 arch/arm/mach-exynos/regs-srom.h                   |  53 -----
 arch/arm/mach-exynos/suspend.c                     |  20 +-
 arch/arm/plat-samsung/include/plat/map-s5p.h       |   1 -
 drivers/memory/Kconfig                             |   1 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/samsung/Kconfig                     |  12 ++
 drivers/memory/samsung/Makefile                    |   1 +
 drivers/memory/samsung/exynos-srom.c               | 232 +++++++++++++++++++++
 drivers/memory/samsung/exynos-srom.h               |  51 +++++
 14 files changed, 384 insertions(+), 92 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
 delete mode 100644 arch/arm/mach-exynos/regs-srom.h
 create mode 100644 drivers/memory/samsung/Kconfig
 create mode 100644 drivers/memory/samsung/Makefile
 create mode 100644 drivers/memory/samsung/exynos-srom.c
 create mode 100644 drivers/memory/samsung/exynos-srom.h

-- 
2.4.5



From pankaj.dubey at samsung.com  Thu Feb 25 00:33:37 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Thu, 25 Feb 2016 14:03:37 +0530
Subject: [RESPIN 1/6] dt-bindings: EXYNOS: Add exynos-srom device tree binding
In-Reply-To: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
References: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <1456389222-12738-2-git-send-email-pankaj.dubey@samsung.com>

This patch adds exynos-srom binding information for SROM Controller
driver on Exynos SoCs.

CC: Rob Herring <robh+dt at kernel.org>
CC: Mark Rutland <mark.rutland at arm.com>
CC: Ian Campbell <ijc+devicetree at hellion.org.uk>
CC: devicetree at vger.kernel.org
Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
Signed-off-by: Kukjin Kim <kgene at kernel.org>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---
 .../devicetree/bindings/memory-controllers/exynos-srom.txt   | 12 ++++++++++++
 1 file changed, 12 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt

diff --git a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
new file mode 100644
index 0000000..33886d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
@@ -0,0 +1,12 @@
+SAMSUNG Exynos SoCs SROM Controller driver.
+
+Required properties:
+- compatible : Should contain "samsung,exynos-srom".
+
+- reg: offset and length of the register set
+
+Example:
+	sromc at 12570000 {
+		compatible = "samsung,exynos-srom";
+		reg = <0x12570000 0x10>;
+	};
-- 
2.4.5



From pankaj.dubey at samsung.com  Thu Feb 25 00:33:40 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Thu, 25 Feb 2016 14:03:40 +0530
Subject: [RESPIN 4/6] ARM: EXYNOS: Remove SROM related register settings from
 mach-exynos
In-Reply-To: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
References: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <1456389222-12738-5-git-send-email-pankaj.dubey@samsung.com>

As now we have dedicated driver for SROM controller, it will take care
of saving register banks during S2R so we can safely remove these
settings from mach-exynos.

Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
Signed-off-by: Kukjin Kim <kgene at kernel.org>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---
 arch/arm/mach-exynos/Kconfig                 |  2 ++
 arch/arm/mach-exynos/exynos.c                | 17 ---------
 arch/arm/mach-exynos/include/mach/map.h      |  3 --
 arch/arm/mach-exynos/regs-srom.h             | 53 ----------------------------
 arch/arm/mach-exynos/suspend.c               | 20 ++---------
 arch/arm/plat-samsung/include/plat/map-s5p.h |  1 -
 6 files changed, 4 insertions(+), 92 deletions(-)
 delete mode 100644 arch/arm/mach-exynos/regs-srom.h

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index c4989c2..8da01d1 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -18,6 +18,7 @@ menuconfig ARCH_EXYNOS
 	select COMMON_CLK_SAMSUNG
 	select EXYNOS_THERMAL
 	select EXYNOS_PMU
+	select EXYNOS_SROM if PM
 	select HAVE_ARM_SCU if SMP
 	select HAVE_S3C2410_I2C if I2C
 	select HAVE_S3C2410_WATCHDOG if WATCHDOG
@@ -30,6 +31,7 @@ menuconfig ARCH_EXYNOS
 	select SRAM
 	select THERMAL
 	select MFD_SYSCON
+	select MEMORY
 	select CLKSRC_EXYNOS_MCT
 	select POWER_RESET
 	select POWER_RESET_SYSCON
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index bbf51a4..f977eea 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -31,11 +31,6 @@
 
 static struct map_desc exynos4_iodesc[] __initdata = {
 	{
-		.virtual	= (unsigned long)S5P_VA_SROMC,
-		.pfn		= __phys_to_pfn(EXYNOS4_PA_SROMC),
-		.length		= SZ_4K,
-		.type		= MT_DEVICE,
-	}, {
 		.virtual	= (unsigned long)S5P_VA_CMU,
 		.pfn		= __phys_to_pfn(EXYNOS4_PA_CMU),
 		.length		= SZ_128K,
@@ -58,15 +53,6 @@ static struct map_desc exynos4_iodesc[] __initdata = {
 	},
 };
 
-static struct map_desc exynos5_iodesc[] __initdata = {
-	{
-		.virtual	= (unsigned long)S5P_VA_SROMC,
-		.pfn		= __phys_to_pfn(EXYNOS5_PA_SROMC),
-		.length		= SZ_4K,
-		.type		= MT_DEVICE,
-	},
-};
-
 static struct platform_device exynos_cpuidle = {
 	.name              = "exynos_cpuidle",
 #ifdef CONFIG_ARM_EXYNOS_CPUIDLE
@@ -138,9 +124,6 @@ static void __init exynos_map_io(void)
 {
 	if (soc_is_exynos4())
 		iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
-
-	if (soc_is_exynos5())
-		iotable_init(exynos5_iodesc, ARRAY_SIZE(exynos5_iodesc));
 }
 
 static void __init exynos_init_io(void)
diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
index c88325d..c48ba4f 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -25,7 +25,4 @@
 
 #define EXYNOS4_PA_COREPERI		0x10500000
 
-#define EXYNOS4_PA_SROMC		0x12570000
-#define EXYNOS5_PA_SROMC		0x12250000
-
 #endif /* __ASM_ARCH_MAP_H */
diff --git a/arch/arm/mach-exynos/regs-srom.h b/arch/arm/mach-exynos/regs-srom.h
deleted file mode 100644
index 5c4d442..0000000
--- a/arch/arm/mach-exynos/regs-srom.h
+++ /dev/null
@@ -1,53 +0,0 @@
-/*
- * Copyright (c) 2010 Samsung Electronics Co., Ltd.
- *		http://www.samsung.com
- *
- * S5P SROMC register definitions
- *
- * 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.
-*/
-
-#ifndef __PLAT_SAMSUNG_REGS_SROM_H
-#define __PLAT_SAMSUNG_REGS_SROM_H __FILE__
-
-#include <mach/map.h>
-
-#define S5P_SROMREG(x)		(S5P_VA_SROMC + (x))
-
-#define S5P_SROM_BW		S5P_SROMREG(0x0)
-#define S5P_SROM_BC0		S5P_SROMREG(0x4)
-#define S5P_SROM_BC1		S5P_SROMREG(0x8)
-#define S5P_SROM_BC2		S5P_SROMREG(0xc)
-#define S5P_SROM_BC3		S5P_SROMREG(0x10)
-#define S5P_SROM_BC4		S5P_SROMREG(0x14)
-#define S5P_SROM_BC5		S5P_SROMREG(0x18)
-
-/* one register BW holds 4 x 4-bit packed settings for NCS0 - NCS3 */
-
-#define S5P_SROM_BW__DATAWIDTH__SHIFT		0
-#define S5P_SROM_BW__ADDRMODE__SHIFT		1
-#define S5P_SROM_BW__WAITENABLE__SHIFT		2
-#define S5P_SROM_BW__BYTEENABLE__SHIFT		3
-
-#define S5P_SROM_BW__CS_MASK			0xf
-
-#define S5P_SROM_BW__NCS0__SHIFT		0
-#define S5P_SROM_BW__NCS1__SHIFT		4
-#define S5P_SROM_BW__NCS2__SHIFT		8
-#define S5P_SROM_BW__NCS3__SHIFT		12
-#define S5P_SROM_BW__NCS4__SHIFT		16
-#define S5P_SROM_BW__NCS5__SHIFT		20
-
-/* applies to same to BCS0 - BCS3 */
-
-#define S5P_SROM_BCX__PMC__SHIFT		0
-#define S5P_SROM_BCX__TACP__SHIFT		4
-#define S5P_SROM_BCX__TCAH__SHIFT		8
-#define S5P_SROM_BCX__TCOH__SHIFT		12
-#define S5P_SROM_BCX__TACC__SHIFT		16
-#define S5P_SROM_BCX__TCOS__SHIFT		24
-#define S5P_SROM_BCX__TACS__SHIFT		28
-
-#endif /* __PLAT_SAMSUNG_REGS_SROM_H */
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index fee2b00..f216909 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -34,10 +34,11 @@
 #include <asm/smp_scu.h>
 #include <asm/suspend.h>
 
+#include <mach/map.h>
+
 #include <plat/pm-common.h>
 
 #include "common.h"
-#include "regs-srom.h"
 
 #define REG_TABLE_END (-1U)
 
@@ -53,15 +54,6 @@ struct exynos_wkup_irq {
 	u32 mask;
 };
 
-static struct sleep_save exynos_core_save[] = {
-	/* SROM side */
-	SAVE_ITEM(S5P_SROM_BW),
-	SAVE_ITEM(S5P_SROM_BC0),
-	SAVE_ITEM(S5P_SROM_BC1),
-	SAVE_ITEM(S5P_SROM_BC2),
-	SAVE_ITEM(S5P_SROM_BC3),
-};
-
 struct exynos_pm_data {
 	const struct exynos_wkup_irq *wkup_irq;
 	unsigned int wake_disable_mask;
@@ -343,8 +335,6 @@ static void exynos_pm_prepare(void)
 	/* Set wake-up mask registers */
 	exynos_pm_set_wakeup_mask();
 
-	s3c_pm_do_save(exynos_core_save, ARRAY_SIZE(exynos_core_save));
-
 	exynos_pm_enter_sleep_mode();
 
 	/* ensure at least INFORM0 has the resume address */
@@ -375,8 +365,6 @@ static void exynos5420_pm_prepare(void)
 	/* Set wake-up mask registers */
 	exynos_pm_set_wakeup_mask();
 
-	s3c_pm_do_save(exynos_core_save, ARRAY_SIZE(exynos_core_save));
-
 	exynos_pmu_spare3 = pmu_raw_readl(S5P_PMU_SPARE3);
 	/*
 	 * The cpu state needs to be saved and restored so that the
@@ -467,8 +455,6 @@ static void exynos_pm_resume(void)
 	/* For release retention */
 	exynos_pm_release_retention();
 
-	s3c_pm_do_restore_core(exynos_core_save, ARRAY_SIZE(exynos_core_save));
-
 	if (cpuid == ARM_CPU_PART_CORTEX_A9)
 		scu_enable(S5P_VA_SCU);
 
@@ -535,8 +521,6 @@ static void exynos5420_pm_resume(void)
 
 	pmu_raw_writel(exynos_pmu_spare3, S5P_PMU_SPARE3);
 
-	s3c_pm_do_restore_core(exynos_core_save, ARRAY_SIZE(exynos_core_save));
-
 early_wakeup:
 
 	tmp = pmu_raw_readl(EXYNOS5420_SFR_AXI_CGDIS1);
diff --git a/arch/arm/plat-samsung/include/plat/map-s5p.h b/arch/arm/plat-samsung/include/plat/map-s5p.h
index 4ec9a70..b63aeeb 100644
--- a/arch/arm/plat-samsung/include/plat/map-s5p.h
+++ b/arch/arm/plat-samsung/include/plat/map-s5p.h
@@ -18,7 +18,6 @@
 
 #define S5P_VA_DMC0		S3C_ADDR(0x02440000)
 #define S5P_VA_DMC1		S3C_ADDR(0x02480000)
-#define S5P_VA_SROMC		S3C_ADDR(0x024C0000)
 
 #define S5P_VA_COREPERI_BASE	S3C_ADDR(0x02800000)
 #define S5P_VA_COREPERI(x)	(S5P_VA_COREPERI_BASE + (x))
-- 
2.4.5



From pankaj.dubey at samsung.com  Thu Feb 25 00:33:38 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Thu, 25 Feb 2016 14:03:38 +0530
Subject: [RESPIN 2/6] drivers: memory: Add support for exynos SROM driver
In-Reply-To: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
References: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <1456389222-12738-3-git-send-email-pankaj.dubey@samsung.com>

This patch adds Exynos SROM controller driver which will handle
save restore of SROM registers during S2R.

Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
[p.fedin at samsung.com: tested on SMDK5410]
Tested-by: Pavel Fedin <p.fedin at samsung.com>
Signed-off-by: Kukjin Kim <kgene at kernel.org>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---
 drivers/memory/Kconfig               |   1 +
 drivers/memory/Makefile              |   1 +
 drivers/memory/samsung/Kconfig       |  12 +++
 drivers/memory/samsung/Makefile      |   1 +
 drivers/memory/samsung/exynos-srom.c | 175 +++++++++++++++++++++++++++++++++++
 drivers/memory/samsung/exynos-srom.h |  51 ++++++++++
 6 files changed, 241 insertions(+)
 create mode 100644 drivers/memory/samsung/Kconfig
 create mode 100644 drivers/memory/samsung/Makefile
 create mode 100644 drivers/memory/samsung/exynos-srom.c
 create mode 100644 drivers/memory/samsung/exynos-srom.h

diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 6f31546..bcb1982 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -114,6 +114,7 @@ config JZ4780_NEMC
 	  the Ingenic JZ4780. This controller is used to handle external
 	  memory devices such as NAND and SRAM.
 
+source "drivers/memory/samsung/Kconfig"
 source "drivers/memory/tegra/Kconfig"
 
 endif
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 1c46af5..d100e40 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -16,4 +16,5 @@ obj-$(CONFIG_MVEBU_DEVBUS)	+= mvebu-devbus.o
 obj-$(CONFIG_TEGRA20_MC)	+= tegra20-mc.o
 obj-$(CONFIG_JZ4780_NEMC)	+= jz4780-nemc.o
 
+obj-$(CONFIG_SAMSUNG_MC)	+= samsung/
 obj-$(CONFIG_TEGRA_MC)		+= tegra/
diff --git a/drivers/memory/samsung/Kconfig b/drivers/memory/samsung/Kconfig
new file mode 100644
index 0000000..c2cd45e
--- /dev/null
+++ b/drivers/memory/samsung/Kconfig
@@ -0,0 +1,12 @@
+config SAMSUNG_MC
+	bool "SAMSUNG Exynos Memory Controller support" if COMPILE_TEST
+	default y
+	depends on ARCH_EXYNOS
+	help
+	  This driver supports the Memory Controller (MC) hardwares found on
+	  SAMSUNG Exynos SoCs.
+
+config EXYNOS_SROM
+	bool
+	depends on (ARM && ARCH_EXYNOS && PM) || ((ARM || ARM64) && COMPILE_TEST)
+
diff --git a/drivers/memory/samsung/Makefile b/drivers/memory/samsung/Makefile
new file mode 100644
index 0000000..9c554d5
--- /dev/null
+++ b/drivers/memory/samsung/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_EXYNOS_SROM)	+= exynos-srom.o
diff --git a/drivers/memory/samsung/exynos-srom.c b/drivers/memory/samsung/exynos-srom.c
new file mode 100644
index 0000000..57a232d
--- /dev/null
+++ b/drivers/memory/samsung/exynos-srom.c
@@ -0,0 +1,175 @@
+/*
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ *	      http://www.samsung.com/
+ *
+ * EXYNOS - SROM Controller support
+ * Author: Pankaj Dubey <pankaj.dubey at samsung.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.
+ */
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "exynos-srom.h"
+
+static const unsigned long exynos_srom_offsets[] = {
+	/* SROM side */
+	EXYNOS_SROM_BW,
+	EXYNOS_SROM_BC0,
+	EXYNOS_SROM_BC1,
+	EXYNOS_SROM_BC2,
+	EXYNOS_SROM_BC3,
+};
+
+/**
+ * struct exynos_srom_reg_dump: register dump of SROM Controller registers.
+ * @offset: srom register offset from the controller base address.
+ * @value: the value of register under the offset.
+ */
+struct exynos_srom_reg_dump {
+	u32     offset;
+	u32     value;
+};
+
+/**
+ * struct exynos_srom: platform data for exynos srom controller driver.
+ * @dev: platform device pointer
+ * @reg_base: srom base address
+ * @reg_offset: exynos_srom_reg_dump pointer to hold offset and its value.
+ */
+struct exynos_srom {
+	struct device *dev;
+	void __iomem *reg_base;
+	struct exynos_srom_reg_dump *reg_offset;
+};
+
+static struct exynos_srom_reg_dump *exynos_srom_alloc_reg_dump(
+		const unsigned long *rdump,
+		unsigned long nr_rdump)
+{
+	struct exynos_srom_reg_dump *rd;
+	unsigned int i;
+
+	rd = kcalloc(nr_rdump, sizeof(*rd), GFP_KERNEL);
+	if (!rd)
+		return NULL;
+
+	for (i = 0; i < nr_rdump; ++i)
+		rd[i].offset = rdump[i];
+
+	return rd;
+}
+
+static int exynos_srom_probe(struct platform_device *pdev)
+{
+	struct device_node *np;
+	struct exynos_srom *srom;
+	struct device *dev = &pdev->dev;
+
+	np = dev->of_node;
+	if (!np) {
+		dev_err(&pdev->dev, "could not find device info\n");
+		return -EINVAL;
+	}
+
+	srom = devm_kzalloc(&pdev->dev,
+			sizeof(struct exynos_srom), GFP_KERNEL);
+	if (!srom)
+		return -ENOMEM;
+
+	srom->dev = dev;
+	srom->reg_base = of_iomap(np, 0);
+	if (!srom->reg_base) {
+		dev_err(&pdev->dev, "iomap of exynos srom controller failed\n");
+		return -ENOMEM;
+	}
+
+	platform_set_drvdata(pdev, srom);
+
+	srom->reg_offset = exynos_srom_alloc_reg_dump(exynos_srom_offsets,
+			sizeof(exynos_srom_offsets));
+	if (!srom->reg_offset) {
+		iounmap(srom->reg_base);
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+static int exynos_srom_remove(struct platform_device *pdev)
+{
+	struct exynos_srom *srom = platform_get_drvdata(pdev);
+
+	kfree(srom->reg_offset);
+	iounmap(srom->reg_base);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static void exynos_srom_save(void __iomem *base,
+				    struct exynos_srom_reg_dump *rd,
+				    unsigned int num_regs)
+{
+	for (; num_regs > 0; --num_regs, ++rd)
+		rd->value = readl(base + rd->offset);
+}
+
+static void exynos_srom_restore(void __iomem *base,
+				      const struct exynos_srom_reg_dump *rd,
+				      unsigned int num_regs)
+{
+	for (; num_regs > 0; --num_regs, ++rd)
+		writel(rd->value, base + rd->offset);
+}
+
+static int exynos_srom_suspend(struct device *dev)
+{
+	struct exynos_srom *srom = dev_get_drvdata(dev);
+
+	exynos_srom_save(srom->reg_base, srom->reg_offset,
+				ARRAY_SIZE(exynos_srom_offsets));
+	return 0;
+}
+
+static int exynos_srom_resume(struct device *dev)
+{
+	struct exynos_srom *srom = dev_get_drvdata(dev);
+
+	exynos_srom_restore(srom->reg_base, srom->reg_offset,
+				ARRAY_SIZE(exynos_srom_offsets));
+	return 0;
+}
+#endif
+
+static const struct of_device_id of_exynos_srom_ids[] = {
+	{
+		.compatible	= "samsung,exynos-srom",
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, of_exynos_srom_ids);
+
+static SIMPLE_DEV_PM_OPS(exynos_srom_pm_ops, exynos_srom_suspend, exynos_srom_resume);
+
+static struct platform_driver exynos_srom_driver = {
+	.probe = exynos_srom_probe,
+	.remove = exynos_srom_remove,
+	.driver = {
+		.name = "exynos-srom",
+		.of_match_table = of_exynos_srom_ids,
+		.pm = &exynos_srom_pm_ops,
+	},
+};
+module_platform_driver(exynos_srom_driver);
+
+MODULE_AUTHOR("Pankaj Dubey <pankaj.dubey at samsung.com>");
+MODULE_DESCRIPTION("Exynos SROM Controller Driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/memory/samsung/exynos-srom.h b/drivers/memory/samsung/exynos-srom.h
new file mode 100644
index 0000000..34660c6
--- /dev/null
+++ b/drivers/memory/samsung/exynos-srom.h
@@ -0,0 +1,51 @@
+/*
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.com
+ *
+ * Exynos SROMC register definitions
+ *
+ * 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.
+*/
+
+#ifndef __EXYNOS_SROM_H
+#define __EXYNOS_SROM_H __FILE__
+
+#define EXYNOS_SROMREG(x)		(x)
+
+#define EXYNOS_SROM_BW		EXYNOS_SROMREG(0x0)
+#define EXYNOS_SROM_BC0		EXYNOS_SROMREG(0x4)
+#define EXYNOS_SROM_BC1		EXYNOS_SROMREG(0x8)
+#define EXYNOS_SROM_BC2		EXYNOS_SROMREG(0xc)
+#define EXYNOS_SROM_BC3		EXYNOS_SROMREG(0x10)
+#define EXYNOS_SROM_BC4		EXYNOS_SROMREG(0x14)
+#define EXYNOS_SROM_BC5		EXYNOS_SROMREG(0x18)
+
+/* one register BW holds 4 x 4-bit packed settings for NCS0 - NCS3 */
+
+#define EXYNOS_SROM_BW__DATAWIDTH__SHIFT	0
+#define EXYNOS_SROM_BW__ADDRMODE__SHIFT		1
+#define EXYNOS_SROM_BW__WAITENABLE__SHIFT	2
+#define EXYNOS_SROM_BW__BYTEENABLE__SHIFT	3
+
+#define EXYNOS_SROM_BW__CS_MASK			0xf
+
+#define EXYNOS_SROM_BW__NCS0__SHIFT		0
+#define EXYNOS_SROM_BW__NCS1__SHIFT		4
+#define EXYNOS_SROM_BW__NCS2__SHIFT		8
+#define EXYNOS_SROM_BW__NCS3__SHIFT		12
+#define EXYNOS_SROM_BW__NCS4__SHIFT		16
+#define EXYNOS_SROM_BW__NCS5__SHIFT		20
+
+/* applies to same to BCS0 - BCS3 */
+
+#define EXYNOS_SROM_BCX__PMC__SHIFT		0
+#define EXYNOS_SROM_BCX__TACP__SHIFT		4
+#define EXYNOS_SROM_BCX__TCAH__SHIFT		8
+#define EXYNOS_SROM_BCX__TCOH__SHIFT		12
+#define EXYNOS_SROM_BCX__TACC__SHIFT		16
+#define EXYNOS_SROM_BCX__TCOS__SHIFT		24
+#define EXYNOS_SROM_BCX__TACS__SHIFT		28
+
+#endif /* __EXYNOS_SROM_H */
-- 
2.4.5



From pankaj.dubey at samsung.com  Thu Feb 25 00:33:39 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Thu, 25 Feb 2016 14:03:39 +0530
Subject: [RESPIN 3/6] MAINTAINERS: Add maintainers entry for
 drivers/memory/samsung
In-Reply-To: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
References: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <1456389222-12738-4-git-send-email-pankaj.dubey@samsung.com>

This patch adds maintainers entry for new driver folder
drivers/memory/samsung

Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a6f927c..3a05c6b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1493,6 +1493,7 @@ F:	arch/arm/mach-s5p*/
 F:	arch/arm/mach-exynos*/
 F:	drivers/*/*s3c2410*
 F:	drivers/*/*/*s3c2410*
+F:	drivers/memory/samsung/*
 F:	drivers/soc/samsung/*
 F:	drivers/spi/spi-s3c*
 F:	sound/soc/samsung/*
-- 
2.4.5



From pankaj.dubey at samsung.com  Thu Feb 25 00:33:42 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Thu, 25 Feb 2016 14:03:42 +0530
Subject: [RESPIN 6/6] drivers: memory: exynos-srom: Add support for bank
 configuration
In-Reply-To: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
References: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <1456389222-12738-7-git-send-email-pankaj.dubey@samsung.com>

From: Pavel Fedin <p.fedin at samsung.com>

Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.

Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.

Signed-off-by: Pavel Fedin <p.fedin at samsung.com>
Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---
 arch/arm/mach-exynos/Kconfig         |  2 +-
 drivers/memory/samsung/Kconfig       |  2 +-
 drivers/memory/samsung/exynos-srom.c | 61 ++++++++++++++++++++++++++++++++++--
 3 files changed, 61 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 8da01d1..eb386b3 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -18,7 +18,7 @@ menuconfig ARCH_EXYNOS
 	select COMMON_CLK_SAMSUNG
 	select EXYNOS_THERMAL
 	select EXYNOS_PMU
-	select EXYNOS_SROM if PM
+	select EXYNOS_SROM
 	select HAVE_ARM_SCU if SMP
 	select HAVE_S3C2410_I2C if I2C
 	select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/memory/samsung/Kconfig b/drivers/memory/samsung/Kconfig
index c2cd45e..ca17a27 100644
--- a/drivers/memory/samsung/Kconfig
+++ b/drivers/memory/samsung/Kconfig
@@ -8,5 +8,5 @@ config SAMSUNG_MC
 
 config EXYNOS_SROM
 	bool
-	depends on (ARM && ARCH_EXYNOS && PM) || ((ARM || ARM64) && COMPILE_TEST)
+	depends on (ARM && ARCH_EXYNOS) || ((ARM || ARM64) && COMPILE_TEST)
 
diff --git a/drivers/memory/samsung/exynos-srom.c b/drivers/memory/samsung/exynos-srom.c
index 57a232d..a4cf547 100644
--- a/drivers/memory/samsung/exynos-srom.c
+++ b/drivers/memory/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
+#include <linux/of_platform.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 
@@ -67,11 +68,51 @@ static struct exynos_srom_reg_dump *exynos_srom_alloc_reg_dump(
 	return rd;
 }
 
+static int exynos_srom_configure_bank(struct exynos_srom *srom,
+				      struct device_node *np)
+{
+	u32 bank, width, pmc;
+	u32 timing[6];
+	u32 cs, bw;
+
+	if (of_property_read_u32(np, "reg", &bank))
+		return -EINVAL;
+	if (of_property_read_u32(np, "reg-io-width", &width))
+		width = 1;
+	if (of_property_read_u32(np, "samsung,srom-page-mode", &pmc))
+		pmc = 0;
+	if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+				       ARRAY_SIZE(timing)))
+		return -EINVAL;
+
+	bank *= 4; /* Convert bank into shift/offset */
+
+	cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+	if (width == 2)
+		cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+	bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+	bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+	__raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+	__raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+		    (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+		    (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+		    (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+		    (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+		    (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+		    (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+		    srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+	return 0;
+}
+
 static int exynos_srom_probe(struct platform_device *pdev)
 {
-	struct device_node *np;
+	struct device_node *np, *child;
 	struct exynos_srom *srom;
 	struct device *dev = &pdev->dev;
+	bool bad_bank_config = false;
 
 	np = dev->of_node;
 	if (!np) {
@@ -100,7 +141,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	}
 
-	return 0;
+	for_each_child_of_node(np, child) {
+		if (exynos_srom_configure_bank(srom, child)) {
+			dev_err(dev,
+				"Could not decode bank configuration for %s\n",
+				child->name);
+			bad_bank_config = true;
+		}
+	}
+
+	/*
+	 * If any bank failed to configure, we still provide suspend/resume,
+	 * but do not probe child devices
+	 */
+	if (bad_bank_config)
+		return 0;
+
+	return of_platform_populate(np, NULL, NULL, dev);
 }
 
 static int exynos_srom_remove(struct platform_device *pdev)
-- 
2.4.5



From pankaj.dubey at samsung.com  Thu Feb 25 00:33:41 2016
From: pankaj.dubey at samsung.com (Pankaj Dubey)
Date: Thu, 25 Feb 2016 14:03:41 +0530
Subject: [RESPIN 5/6] dt-bindings: EXYNOS: Describe SROMc configuration
In-Reply-To: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
References: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <1456389222-12738-6-git-send-email-pankaj.dubey@samsung.com>

From: Pavel Fedin <p.fedin at samsung.com>

Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.

Also, fix size of SROMc mapping in the example.

CC: devicetree at vger.kernel.org
Signed-off-by: Pavel Fedin <p.fedin at samsung.com>
Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
---
 .../bindings/memory-controllers/exynos-srom.txt    | 73 +++++++++++++++++++++-
 1 file changed, 71 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
index 33886d5..e5c18df 100644
--- a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
@@ -5,8 +5,77 @@ Required properties:
 
 - reg: offset and length of the register set
 
-Example:
+Optional properties:
+The SROM controller can be used to attach external peripherals. In this case
+extra properties, describing the bus behind it, should be specified as below:
+
+- #address-cells: Must be set to 2 to allow device address translation.
+		  Address is specified as (bank#, offset).
+
+- #size-cells: Must be set to 1 to allow device size passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+	  per bank:
+		<bank-number> 0 <parent address of bank> <size>
+
+Sub-nodes:
+The actual device nodes should be added as subnodes to the SROMc node. These
+subnodes, except regular device specification, should contain the following
+properties, describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+       the memory mapped for the device. Note that base address will be
+       typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+                        following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+                        Each value is specified in cycles and has the following
+                        meaning and valid range:
+                        Tacp : Page mode access cycle at Page mode (0 - 15)
+                        Tcah : Address holding time after CSn (0 - 15)
+                        Tcoh : Chip selection hold on OEn (0 - 15)
+                        Tacc : Access cycle (0 - 31, the actual time is N + 1)
+                        Tcos : Chip selection set-up before OEn (0 - 15)
+                        Tacs : Address set-up before CSn (0 - 15)
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+			   0 - normal (one data)
+			   1 - four data
+			   If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+	sromc at 12570000 {
+		compatible = "samsung,exynos-srom";
+		reg = <0x12570000 0x14>;
+	};
+
+Example: SROMc with SMSC911x ethernet chip on bank 3
 	sromc at 12570000 {
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges = <0 0 0x04000000 0x20000   // Bank0
+			  1 0 0x05000000 0x20000   // Bank1
+			  2 0 0x06000000 0x20000   // Bank2
+			  3 0 0x07000000 0x20000>; // Bank3
+
 		compatible = "samsung,exynos-srom";
-		reg = <0x12570000 0x10>;
+		reg = <0x12570000 0x14>;
+
+		ethernet at 3,0 {
+			compatible = "smsc,lan9115";
+			reg = <3 0 0x10000>;	   // Bank 3, offset = 0
+			phy-mode = "mii";
+			interrupt-parent = <&gpx0>;
+			interrupts = <5 8>;
+			reg-io-width = <2>;
+			smsc,irq-push-pull;
+			smsc,force-internal-phy;
+
+			samsung,srom-page-mode = <1>;
+			samsung,srom-timing = <9 12 1 9 1 1>;
+		};
 	};
-- 
2.4.5



From arnd at arndb.de  Thu Feb 25 00:35:43 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 09:35:43 +0100
Subject: [PATCH 0/5] Modularize PCI_DW related drivers.
In-Reply-To: <56CEB7BC.7010803@ti.com>
References: <1454889644-27830-1-git-send-email-paul.gortmaker@windriver.com>
 <6350001.oOdGGcH81x@wuerfel> <56CEB7BC.7010803@ti.com>
Message-ID: <2837386.VTD89bjPJz@wuerfel>

On Thursday 25 February 2016 13:43:48 Kishon Vijay Abraham I wrote:
> Hi Arnd,
> 
> On Wednesday 24 February 2016 02:34 PM, Arnd Bergmann wrote:
> > On Wednesday 24 February 2016 11:39:26 Kishon Vijay Abraham I wrote:
> >> Hi,
> >>
> >> On Monday 08 February 2016 05:30 AM, Paul Gortmaker wrote:
> >>> In a recent patch series that aimed to remove code related to module
> >>> unload for PCI support that was simply non modular, the discussion
> >>> led to people wanting to keep the code and push towards taking the
> >>> steps needed to support moving it towards tristate instead[1].
> >>>
> >>> Here, we take step one, which is simply making the Kconfig change
> >>> and then dealing with any build fallout or modpost fallout.  What
> >>> amounts to essentially a sanity build test.  To be clear, these
> >>> have not been runtime validated; that will need to be done by those
> >>> with access to real hardware.  However, the changes are not anything
> >>> that should disrupt any existing built-in validation, so real world
> >>> users should not be impacted by this change.
> >>>
> >>> We start with a smaller family of drivers; those that actively select
> >>> PCI_DW, as a nice self contained group to test the waters and see if
> >>> everyone is still good with this approach before investing more time
> >>> on a wider scale to other pci/host/ code blocks.
> >>>
> >>> As such the drivers here share a dependency on having the same group
> >>> of functions exported in order to successfully complete modpost.
> >>>
> >>> In addition, we have to stray outside drivers/pci to add exports
> >>> in two places; once for an ARM fault handler, and once for an OF
> >>> variable.
> >>>
> >>> The pci-keystone-dw.c instance was handled separately because it
> >>> consists of two source files that need their own group of driver
> >>> specific exports above and beyond the "shared" ones.
> >>>
> >>> Then we convert the Kconfig for all remaining at once; we could have
> >>> done it on a per driver basis for ease of revert if anyone really
> >>> objects, but since it would be a one line change, that seemed like
> >>> not a real concern.
> >>>
> >>> Build testing was done on the linux-next tree for arm allmodconfig.
> >>
> >> I took these patches and gave a test with DRA7xx board. As expected there was
> >> no issues when the driver was built-in. However when I tried to rmmod/modprobe
> >> I got this error [2].
> > 
> > Thanks for testing this!
> > 
> >> [2] -> http://pastebin.ubuntu.com/15185894/
> > 
> > It looks like you are hitting the BUG_ON() in ioremap_pte_range()
> > that checks if a virtual address already has a page table entry,
> > which in turn is probably a result of dw_pcie_host_init()
> > calling pci_remap_iospace() again for the same memory area
> > it has called the last time, and no cleanup done inbetween.
> > 
> > Could you try adding a pci_unmap_iospace() and calling that
> > in the device remove function? Let me know if you need help
> > implementing it.
> 
> That didn't look straight forward to me :-( I'll try to see this next week. Any
> help from you will make it simpler for me.

I tried writing the function now, and I think it's actually quite easy:

void pci_unmap_iospace(const struct resource *res)
{
#if defined(PCI_IOBASE) && defined(CONFIG_MMU)
        return iounmap(PCI_IOBASE + res->start);
#endif
}

You just need to pass the same resource in here htat you pass into
pci_remap_iospace().

	Arnd


From holgerschurig at gmail.com  Thu Feb 25 00:39:03 2016
From: holgerschurig at gmail.com (Holger Schurig)
Date: Thu, 25 Feb 2016 09:39:03 +0100
Subject: [PATCH net-next V2 00/16] net: fec: cleanup and fixes
In-Reply-To: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com> (Troy
 Kisky's message of "Wed, 24 Feb 2016 17:36:43 -0700")
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
Message-ID: <87oab518wo.fsf@gmail.com>

Hi Troy,

what is the general aim of your patches?  Stability?  Speed?  Cleanup?


From alexandre.torgue at gmail.com  Thu Feb 25 00:43:45 2016
From: alexandre.torgue at gmail.com (Alexandre Torgue)
Date: Thu, 25 Feb 2016 09:43:45 +0100
Subject: [PATCH v2 2/4] Documentation: Bindings: Add STM32 DWMAC glue
In-Reply-To: <CAGhQ9VwsSb-Nb4nQ4Q9=b-Dj_8EhSi=LOK-r4JbKcE=nfODufw@mail.gmail.com>
References: <1456240244-10275-1-git-send-email-alexandre.torgue@gmail.com>
 <1456240244-10275-3-git-send-email-alexandre.torgue@gmail.com>
 <CAGhQ9VwsSb-Nb4nQ4Q9=b-Dj_8EhSi=LOK-r4JbKcE=nfODufw@mail.gmail.com>
Message-ID: <CAJgp7zyEkQqBc4rgPxXfaYwieQ8ezL543gSKG+tJoNz9JqBg=A@mail.gmail.com>

Hi Joachim,

2016-02-23 23:37 GMT+01:00 Joachim  Eastwood <manabian at gmail.com>:
> Hi Alexandre,
>
> You should copy 'devicetree at vger.kernel.org' on bindings doc. Adding cc here.
>
> On 23 February 2016 at 16:10, Alexandre TORGUE
> <alexandre.torgue at gmail.com> wrote:
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>
>>
>> diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
>> new file mode 100644
>> index 0000000..18734b3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
>> @@ -0,0 +1,41 @@
>> +STMicroelectronics STM32 / MCU DWMAC glue layer controller
>> +
>> +This file documents platform glue layer for stmmac.
>> +Please see stmmac.txt for the other unchanged properties.
>> +
>> +The device node has following properties.
>> +
>> +Required properties:
>> +- compatible:  Should be "st,stm32-dwmac" to select glue, and
>> +              "snps,dwmac-3.50a" to select IP vesrion.
>> +- clocks: Should contain the GMAC main clock, and tx clock
>> +- compatible:  Should be "st,stm32-dwmac" to select glue and
>> +              "snps,dwmac-3.50a" to select IP version.
>> +- clocks: Should contain the MAC main clock
>> +- clock-names: Should contain the clock names "stmmaceth".
>> +- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
>> +             encompases the glue register, and the offset of the control register.
>> +
>> +Optional properties:
>> +- clocks: Could contain:
>> +       - the tx clock,
>> +       - the rx clock
>> +- clock-names: Could contain the clock names "tx-clk", "rx-clk"
>> +
>> +Example:
>> +
>> +               ethernet0: dwmac at 40028000 {
>> +                       device_type = "network";
>
> What is this 'device_type = "network"' for?
> It seems to used in a lot of powerpc DTs, but only a couple of arm DTs.

Actually it seems that this entry is deprecated for ARM
(http://lists.openwall.net/linux-kernel/2013/12/11/372)
Concerning stmmac driver I don't see an issue to remove it (tested).
So If Rob and Peppe could confirm, I will remove it in my V3.

Br

Alexandre


>
> Maybe Rob could enlighten us?
>
>> +                       compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
>> +                       status = "disabled";
>> +                       reg = <0x40028000 0x8000>;
>> +                       reg-names = "stmmaceth";
>> +                       interrupts = <0 61 0>, <0 62 0>;
>> +                       interrupt-names = "macirq", "eth_wake_irq";
>> +                       clock-names = "stmmaceth", "tx-clk", "rx-clk";
>> +                       clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
>> +                       st,syscon = <&syscfg 0x4>;
>> +                       snps,pbl = <32>;
>
> Regarding snps,pbl; using 32 here might not give you what you would except.
> See comment in dwmac1000_dma_init().
>
> The driver is hard coded to use PBL4X/PBL8X mode. Just a heads up.
>
>
> regards,
> Joachim Eastwood


From heiko.carstens at de.ibm.com  Thu Feb 25 00:49:43 2016
From: heiko.carstens at de.ibm.com (Heiko Carstens)
Date: Thu, 25 Feb 2016 09:49:43 +0100
Subject: [PATCH 2/5] all: introduce COMPAT_WRAPPER option and enable it
 for s390
In-Reply-To: <1456338854-14901-3-git-send-email-ynorov@caviumnetworks.com>
References: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
 <1456338854-14901-3-git-send-email-ynorov@caviumnetworks.com>
Message-ID: <20160225084943.GB3980@osiris>

On Wed, Feb 24, 2016 at 09:34:11PM +0300, Yury Norov wrote:
> Signed-off-by: Yury Norov <ynorov at caviumnetworks.com>
> ---
>  arch/Kconfig      | 4 ++++
>  arch/s390/Kconfig | 1 +
>  2 files changed, 5 insertions(+)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index f6b649d..6393093 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -583,6 +583,10 @@ config HAVE_COPY_THREAD_TLS
>  	  normal C parameter passing, rather than extracting the syscall
>  	  argument from pt_regs.
> 
> +config COMPAT_WRAPPER
> +	bool
> +	depends on COMPAT
> +
>  #
>  # ABI hall of shame
>  #
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 3be9c83..082b861 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -333,6 +333,7 @@ config COMPAT
>  	select COMPAT_BINFMT_ELF if BINFMT_ELF
>  	select ARCH_WANT_OLD_COMPAT_IPC
>  	select COMPAT_OLD_SIGACTION
> +	select COMPAT_WRAPPER
>  	depends on MULTIUSER
>  	help
>  	  Select this option if you want to enable your system kernel to

Maybe merge this into patch 4/5?



From heiko.carstens at de.ibm.com  Thu Feb 25 00:51:40 2016
From: heiko.carstens at de.ibm.com (Heiko Carstens)
Date: Thu, 25 Feb 2016 09:51:40 +0100
Subject: [PATCH 3/5] all: s390: move wrapper infrastructure to generic
 headers
In-Reply-To: <1456338854-14901-4-git-send-email-ynorov@caviumnetworks.com>
References: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
 <1456338854-14901-4-git-send-email-ynorov@caviumnetworks.com>
Message-ID: <20160225085140.GC3980@osiris>

On Wed, Feb 24, 2016 at 09:34:12PM +0300, Yury Norov wrote:
> diff --git a/include/linux/syscalls_structs.h b/include/linux/syscalls_structs.h
> new file mode 100644
> index 0000000..a920cbc
> --- /dev/null
> +++ b/include/linux/syscalls_structs.h
> @@ -0,0 +1,60 @@
> +#ifndef _LINUX_SYSCALL_STRUCTS_H
> +#define _LINUX_SYSCALL_STRUCTS_H
> +
> +struct epoll_event;
> +struct iattr;
> +struct inode;
> +struct iocb;
> +struct io_event;
> +struct iovec;
> +struct itimerspec;
> +struct itimerval;

This is not needed for s390, right? So might be worth a separate patch
which moves the forward declarations?



From heiko.carstens at de.ibm.com  Thu Feb 25 00:52:27 2016
From: heiko.carstens at de.ibm.com (Heiko Carstens)
Date: Thu, 25 Feb 2016 09:52:27 +0100
Subject: [PATCH 4/5] all: s390: move compat_wrappers.c from
 arch/s390/kernel to kernel/
In-Reply-To: <1456338854-14901-5-git-send-email-ynorov@caviumnetworks.com>
References: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
 <1456338854-14901-5-git-send-email-ynorov@caviumnetworks.com>
Message-ID: <20160225085227.GD3980@osiris>

On Wed, Feb 24, 2016 at 09:34:13PM +0300, Yury Norov wrote:
> Some syscalls are declared conditionally, so corresponding wrappers
> are conditional accordingly.
> 
> Signed-off-by: Yury Norov <ynorov at caviumnetworks.com>
> ---
>  arch/s390/kernel/Makefile         |   2 +-
>  arch/s390/kernel/compat_wrapper.c | 129 -----------------------------
>  kernel/Makefile                   |   1 +
>  kernel/compat_wrapper.c           | 170 ++++++++++++++++++++++++++++++++++++++
>  4 files changed, 172 insertions(+), 130 deletions(-)
>  delete mode 100644 arch/s390/kernel/compat_wrapper.c
>  create mode 100644 kernel/compat_wrapper.c

Generated code looks identical on s390 and of course still works!



From pbonzini at redhat.com  Thu Feb 25 00:53:58 2016
From: pbonzini at redhat.com (Paolo Bonzini)
Date: Thu, 25 Feb 2016 09:53:58 +0100
Subject: [PULL] KVM/ARM fixes for 4.5-rc6
In-Reply-To: <1456335224-20603-1-git-send-email-marc.zyngier@arm.com>
References: <1456335224-20603-1-git-send-email-marc.zyngier@arm.com>
Message-ID: <56CEC126.5030606@redhat.com>



On 24/02/2016 18:33, Marc Zyngier wrote:
>   git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvm-arm-for-4.5-rc6

Pulled, thanks.

Paolo


From heiko.carstens at de.ibm.com  Thu Feb 25 00:54:09 2016
From: heiko.carstens at de.ibm.com (Heiko Carstens)
Date: Thu, 25 Feb 2016 09:54:09 +0100
Subject: [PATCH v2 0/5] all: s390: make compat wrappers the generic
 solution
In-Reply-To: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
References: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
Message-ID: <20160225085409.GE3980@osiris>

On Wed, Feb 24, 2016 at 09:34:09PM +0300, Yury Norov wrote:
> The problem that makes us use wrappers is that some compat
> architectures allows user code to access top halves of registers.
> This is not a problem for syscalls that are already handled by compat
> code, or for that who has types of the same size in kernel and
> userspace. In case of s390 and lp64/ilp32 the problem is in pointer
> types, long, unsigned long.
> 
> S390 folks already have the solution for it. In this patchset,
> it is turned to be general, as arm64/ilp32 needs it too.
> 
> This patchset is created as the part of the work of enabling arm64
> with ILP32 user mode. See details here:
> http://thread.gmane.org/gmane.linux.kernel/2126946
> 
> This is the implementation of one of two possible approaches. First
> one defines new syscall handler declaration macro, that creates both compat and
> non-compat handlers, see [1]. This one declares all wrappers in separated file
> kernel/compat_wrapper.c
> 
> Build-tested on s390.
> 
> [1] http://www.spinics.net/lists/linux-s390/msg11593.html
> 
> Yury Norov (5):
>   all: syscall wrappers: add documentation
>   all: introduce COMPAT_WRAPPER option and enable it for s390
>   all: s390: move wrapper infrastructure to generic headers
>   all: s390: move compat_wrappers.c from arch/s390/kernel to kernel/
>   all: wrap needed syscalls in generic unistd

Looks good to me. You may consider the possible changes I sent as reply to
some of your patches.
However from an s390 point of view:

Acked-by: Heiko Carstens <heiko.carstens at de.ibm.com>



From l.majewski at samsung.com  Thu Feb 25 00:58:03 2016
From: l.majewski at samsung.com (Lukasz Majewski)
Date: Thu, 25 Feb 2016 09:58:03 +0100
Subject: [PATCH] arm64: dts: Add tmu node for exynos7
In-Reply-To: <56CE7FF3.4030101@samsung.com>
References: <1456370865-10086-1-git-send-email-pankaj.dubey@samsung.com>
 <56CE7DAC.4000803@samsung.com> <56CE7FF3.4030101@samsung.com>
Message-ID: <20160225095803.719122ae@amdc2363>

Hi pankaj.dubey,

> Hi Krzysztof,
> 
> On Thursday 25 February 2016 09:36 AM, Krzysztof Kozlowski wrote:
> > On 25.02.2016 12:27, Pankaj Dubey wrote:
> >> From: Alim Akhtar <alim.akhtar at samsung.com>
> >>
> >> This patch adds tmu node, related temprature sensor and triping
> >> point data for Atlas cpu core found on exynos7 SoC.
> >>
> >> Signed-off-by: Alim Akhtar <alim.akhtar at samsung.com>
> > 
> > Yours Sob is missing.
> > 
> > Cc-ed Lukasz Majewski.
> > 
> 
> Due to some technical difficulty Alim posted via my account. He will
> re-spin this patch via his account soon.

Looking forward to see your patches. :-)

Best regards,
?ukasz Majewski

> 
> Thanks,
> Pankaj Dubey
> > Lukasz,
> > Your review or ack would be appreciated.
> > 
> > 
> >> ---
> >>  .../boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi   |   25
> >> +++++++++ .../arm64/boot/dts/exynos/exynos7-trip-points.dtsi |
> >> 55 ++++++++++++++++++++
> >> arch/arm64/boot/dts/exynos/exynos7.dtsi            |   20 +++++++
> >> 3 files changed, 100 insertions(+) create mode 100644
> >> arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi create
> >> mode 100644 arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
> >>
> >> diff --git
> >> a/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
> >> b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi new file
> >> mode 100644 index 0000000..1d6dcf2 --- /dev/null
> >> +++ b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
> >> @@ -0,0 +1,25 @@
> >> +/*
> >> + * Device tree sources for Exynos7 TMU sensor configuration
> >> + *
> >> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> >> + *		http://www.samsung.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.
> >> + *
> >> + */
> >> +
> >> +#include <dt-bindings/thermal/thermal_exynos.h>
> >> +
> >> +#thermal-sensor-cells = <0>;
> >> +samsung,tmu_gain = <9>;
> >> +samsung,tmu_reference_voltage = <17>;
> >> +samsung,tmu_noise_cancel_mode = <4>;
> >> +samsung,tmu_efuse_value = <75>;
> >> +samsung,tmu_min_efuse_value = <15>;
> >> +samsung,tmu_max_efuse_value = <100>;
> >> +samsung,tmu_first_point_trim = <25>;
> >> +samsung,tmu_second_point_trim = <85>;
> >> +samsung,tmu_default_temp_offset = <50>;
> >> +samsung,tmu_cal_type = <TYPE_ONE_POINT_TRIMMING>;
> >> diff --git a/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
> >> b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi new file
> >> mode 100644 index 0000000..3970545
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
> >> @@ -0,0 +1,55 @@
> >> +/*
> >> + * Device tree sources for default Exynos7 thermal zone definition
> >> + *
> >> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> >> + *		http://www.samsung.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.
> >> + *
> >> + */
> >> +
> >> +trips {
> >> +	cpu-alert-0 {
> >> +		temperature = <75000>; /* millicelsius */
> >> +		hysteresis = <10000>; /* millicelsius */
> >> +		type = "passive";
> >> +	};
> >> +	cpu-alert-1 {
> >> +		temperature = <80000>; /* millicelsius */
> >> +		hysteresis = <10000>; /* millicelsius */
> >> +		type = "passive";
> >> +	};
> >> +	cpu-alert-2 {
> >> +		temperature = <85000>; /* millicelsius */
> >> +		hysteresis = <10000>; /* millicelsius */
> >> +		type = "passive";
> >> +	};
> >> +	cpu-alert-3 {
> >> +		temperature = <90000>; /* millicelsius */
> >> +		hysteresis = <10000>; /* millicelsius */
> >> +		type = "passive";
> >> +	};
> >> +	cpu-alert-4 {
> >> +		temperature = <95000>; /* millicelsius */
> >> +		hysteresis = <10000>; /* millicelsius */
> >> +		type = "passive";
> >> +	};
> >> +	cpu-alert-5 {
> >> +		temperature = <100000>; /* millicelsius */
> >> +		hysteresis = <10000>; /* millicelsius */
> >> +		type = "passive";
> >> +	};
> >> +	cpu-alert-6 {
> >> +		temperature = <110000>; /* millicelsius */
> >> +		hysteresis = <10000>; /* millicelsius */
> >> +		type = "passive";
> >> +	};
> >> +	/* HW Trip point */
> > 
> > The comment looks unnecessary, all of these are HW trip points,
> > right?
> > 
> >> +	cpu-crit-0 {
> >> +		temperature = <115000>; /* millicelsius */
> >> +		hysteresis = <0>; /* millicelsius */
> >> +		type = "critical";
> >> +	};
> >> +};
> >> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> >> b/arch/arm64/boot/dts/exynos/exynos7.dtsi index c662f98..fc9d130
> >> 100644 --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> >> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> >> @@ -27,6 +27,7 @@
> >>  		pinctrl6 = &pinctrl_fsys0;
> >>  		pinctrl7 = &pinctrl_fsys1;
> >>  		pinctrl8 = &pinctrl_bus1;
> >> +		tmuctrl0 = &tmuctrl_0;
> > 
> > Why the alias is needed?
> > 
> >>  	};
> >>  
> >>  	cpus {
> >> @@ -538,6 +539,25 @@
> >>  			clocks = <&clock_peric0 PCLK_PWM>;
> >>  			clock-names = "timers";
> >>  		};
> >> +
> >> +		tmuctrl_0: tmu at 10060000 {
> >> +			compatible = "samsung,exynos7-tmu";
> >> +			reg = <0x10060000 0x200>;
> >> +			interrupts = <0 108 0>;
> >> +			clocks = <&clock_peris PCLK_TMU>,
> >> +				 <&clock_peris SCLK_TMU>;
> >> +			clock-names = "tmu_apbif", "tmu_sclk";
> >> +			#include "exynos7-tmu-sensor-conf.dtsi"
> >> +		};
> >> +
> >> +		thermal-zones {
> >> +			atlas_thermal: atlas-thermal {
> > 
> > The atlas is a Exynos7 specific codename. The name of node should
> > be a general class of the device, so maybe:
> > 	atlas_thermal: cluster0-thermal
> > ?
> > 
> > Best regards,
> > Krzysztof
> > 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group


From alim.akhtar at samsung.com  Thu Feb 25 01:05:16 2016
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Thu, 25 Feb 2016 14:35:16 +0530
Subject: [RESPIN/PATCH] arm64: dts: Add tmu node for exynos7
Message-ID: <1456391116-11553-1-git-send-email-alim.akhtar@samsung.com>

This patch adds tmu node, related temprature sensor and triping
point data for Atlas cpu core found on exynos7 SoC.

Signed-off-by: Alim Akhtar <alim.akhtar at samsung.com>
---
Change log:
* no changes, just sending back from my email id.

 .../boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi   |   25 +++++++++
 .../arm64/boot/dts/exynos/exynos7-trip-points.dtsi |   55 ++++++++++++++++++++
 arch/arm64/boot/dts/exynos/exynos7.dtsi            |   20 +++++++
 3 files changed, 100 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi

diff --git a/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
new file mode 100644
index 0000000..1d6dcf2
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
@@ -0,0 +1,25 @@
+/*
+ * Device tree sources for Exynos7 TMU sensor configuration
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.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.
+ *
+ */
+
+#include <dt-bindings/thermal/thermal_exynos.h>
+
+#thermal-sensor-cells = <0>;
+samsung,tmu_gain = <9>;
+samsung,tmu_reference_voltage = <17>;
+samsung,tmu_noise_cancel_mode = <4>;
+samsung,tmu_efuse_value = <75>;
+samsung,tmu_min_efuse_value = <15>;
+samsung,tmu_max_efuse_value = <100>;
+samsung,tmu_first_point_trim = <25>;
+samsung,tmu_second_point_trim = <85>;
+samsung,tmu_default_temp_offset = <50>;
+samsung,tmu_cal_type = <TYPE_ONE_POINT_TRIMMING>;
diff --git a/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
new file mode 100644
index 0000000..3970545
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
@@ -0,0 +1,55 @@
+/*
+ * Device tree sources for default Exynos7 thermal zone definition
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.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.
+ *
+ */
+
+trips {
+	cpu-alert-0 {
+		temperature = <75000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-1 {
+		temperature = <80000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-2 {
+		temperature = <85000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-3 {
+		temperature = <90000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-4 {
+		temperature = <95000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-5 {
+		temperature = <100000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-6 {
+		temperature = <110000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	/* HW Trip point */
+	cpu-crit-0 {
+		temperature = <115000>; /* millicelsius */
+		hysteresis = <0>; /* millicelsius */
+		type = "critical";
+	};
+};
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index c662f98..fc9d130 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -27,6 +27,7 @@
 		pinctrl6 = &pinctrl_fsys0;
 		pinctrl7 = &pinctrl_fsys1;
 		pinctrl8 = &pinctrl_bus1;
+		tmuctrl0 = &tmuctrl_0;
 	};
 
 	cpus {
@@ -538,6 +539,25 @@
 			clocks = <&clock_peric0 PCLK_PWM>;
 			clock-names = "timers";
 		};
+
+		tmuctrl_0: tmu at 10060000 {
+			compatible = "samsung,exynos7-tmu";
+			reg = <0x10060000 0x200>;
+			interrupts = <0 108 0>;
+			clocks = <&clock_peris PCLK_TMU>,
+				 <&clock_peris SCLK_TMU>;
+			clock-names = "tmu_apbif", "tmu_sclk";
+			#include "exynos7-tmu-sensor-conf.dtsi"
+		};
+
+		thermal-zones {
+			atlas_thermal: atlas-thermal {
+				polling-delay-passive = <0>; /* milliseconds */
+				polling-delay = <0>; /* milliseconds */
+				thermal-sensors = <&tmuctrl_0>;
+				#include "exynos7-trip-points.dtsi"
+			};
+		};
 	};
 };
 
-- 
1.7.10.4



From lars.persson at axis.com  Thu Feb 25 01:11:56 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 25 Feb 2016 10:11:56 +0100
Subject: [PATCH] ARM: dts: artpec: dual-license on artpec6.dtsi
Message-ID: <1456391516-10561-1-git-send-email-larper@axis.com>

Relaxed the license on the dtsi to permit use in other projects.

Signed-off-by: Lars Persson <larper at axis.com>
---
 arch/arm/boot/dts/artpec6.dtsi | 40 +++++++++++++++++++++++++++++++++++++---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/arm/boot/dts/artpec6.dtsi
index f2a7e4a..3043016 100644
--- a/arch/arm/boot/dts/artpec6.dtsi
+++ b/arch/arm/boot/dts/artpec6.dtsi
@@ -1,9 +1,43 @@
 /*
  * Device Tree Source for the Axis ARTPEC-6 SoC
  *
- * This file is licensed under the terms of the GNU General Public License
- * version 2.  This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
  */
 
 #include <dt-bindings/interrupt-controller/arm-gic.h>
-- 
2.1.4



From lkp at intel.com  Thu Feb 25 01:10:18 2016
From: lkp at intel.com (kbuild test robot)
Date: Thu, 25 Feb 2016 17:10:18 +0800
Subject: [PATCH] i2c: mediatek: i2c multi transfer optimization
In-Reply-To: <1456358467-529-1-git-send-email-liguo.zhang@mediatek.com>
Message-ID: <201602251730.JTaXPXHL%fengguang.wu@intel.com>

Hi Liguo,

[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on next-20160224]
[cannot apply to v4.5-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Liguo-Zhang/i2c-mediatek-i2c-multi-transfer-optimization/20160225-160535
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux i2c/for-next
config: i386-allmodconfig (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/i2c/busses/i2c-mt65xx.c: In function 'mtk_i2c_transfer':
>> drivers/i2c/busses/i2c-mt65xx.c:556:6: warning: unused variable 'left_num' [-Wunused-variable]
     int left_num = num;
         ^

vim +/left_num +556 drivers/i2c/busses/i2c-mt65xx.c

173b77e8d Liguo Zhang 2015-11-09  540  	if (!i2c->auto_restart) {
b2ed11e22 Eddie Huang 2015-05-21  541  		start_reg = I2C_TRANSAC_START;
b2ed11e22 Eddie Huang 2015-05-21  542  	} else {
b2ed11e22 Eddie Huang 2015-05-21  543  		start_reg = I2C_TRANSAC_START | I2C_RS_MUL_TRIG;
b2ed11e22 Eddie Huang 2015-05-21  544  		if (left_num >= 1)
b2ed11e22 Eddie Huang 2015-05-21  545  			start_reg |= I2C_RS_MUL_CNFG;
b2ed11e22 Eddie Huang 2015-05-21  546  	}
b2ed11e22 Eddie Huang 2015-05-21  547  	writew(start_reg, i2c->base + OFFSET_START);
ce38815d3 Xudong Chen 2015-05-21  548  
ce38815d3 Xudong Chen 2015-05-21  549  	return 0;
ce38815d3 Xudong Chen 2015-05-21  550  }
ce38815d3 Xudong Chen 2015-05-21  551  
ce38815d3 Xudong Chen 2015-05-21  552  static int mtk_i2c_transfer(struct i2c_adapter *adap,
ce38815d3 Xudong Chen 2015-05-21  553  			    struct i2c_msg msgs[], int num)
ce38815d3 Xudong Chen 2015-05-21  554  {
ce38815d3 Xudong Chen 2015-05-21  555  	int ret;
ce38815d3 Xudong Chen 2015-05-21 @556  	int left_num = num;
ce38815d3 Xudong Chen 2015-05-21  557  	struct mtk_i2c *i2c = i2c_get_adapdata(adap);
cc7e965fd Liguo Zhang 2016-02-25  558  	struct mtk_i2c_transaction *i2c_transac = &i2c->transac;
cc7e965fd Liguo Zhang 2016-02-25  559  
cc7e965fd Liguo Zhang 2016-02-25  560  	i2c_transac->num = num;
cc7e965fd Liguo Zhang 2016-02-25  561  	i2c_transac->index = 0;
cc7e965fd Liguo Zhang 2016-02-25  562  	i2c_transac->msgs = msgs;
cc7e965fd Liguo Zhang 2016-02-25  563  	i2c_transac->result = 0;
cc7e965fd Liguo Zhang 2016-02-25  564  

:::::: The code at line 556 was first introduced by commit
:::::: ce38815d39eac9c73d37dd4b0039c87f15dcbe18 I2C: mediatek: Add driver for MediaTek I2C controller

:::::: TO: Xudong Chen <xudong.chen at mediatek.com>
:::::: CC: Wolfram Sang <wsa at the-dreams.de>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 53458 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/63b14e49/attachment-0001.obj>

From alim.akhtar at samsung.com  Thu Feb 25 01:16:03 2016
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Thu, 25 Feb 2016 14:46:03 +0530
Subject: [PATCH] arm64: dts: Add tmu node for exynos7
In-Reply-To: <20160225095803.719122ae@amdc2363>
References: <1456370865-10086-1-git-send-email-pankaj.dubey@samsung.com>
 <56CE7DAC.4000803@samsung.com> <56CE7FF3.4030101@samsung.com>
 <20160225095803.719122ae@amdc2363>
Message-ID: <56CEC653.4010004@samsung.com>

Hi Lukasz,

On 02/25/2016 02:28 PM, Lukasz Majewski wrote:
> Hi pankaj.dubey,
>
>> Hi Krzysztof,
>>
>> On Thursday 25 February 2016 09:36 AM, Krzysztof Kozlowski wrote:
>>> On 25.02.2016 12:27, Pankaj Dubey wrote:
>>>> From: Alim Akhtar <alim.akhtar at samsung.com>
>>>>
>>>> This patch adds tmu node, related temprature sensor and triping
>>>> point data for Atlas cpu core found on exynos7 SoC.
>>>>
>>>> Signed-off-by: Alim Akhtar <alim.akhtar at samsung.com>
>>>
>>> Yours Sob is missing.
>>>
>>> Cc-ed Lukasz Majewski.
>>>
>>
>> Due to some technical difficulty Alim posted via my account. He will
>> re-spin this patch via his account soon.
>
> Looking forward to see your patches. :-)
>
I have resend the patch..please review.
Thanks for your time.

> Best regards,
> ?ukasz Majewski
>
>>
>> Thanks,
>> Pankaj Dubey
>>> Lukasz,
>>> Your review or ack would be appreciated.
>>>
>>>
>>>> ---
>>>>   .../boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi   |   25
>>>> +++++++++ .../arm64/boot/dts/exynos/exynos7-trip-points.dtsi |
>>>> 55 ++++++++++++++++++++
>>>> arch/arm64/boot/dts/exynos/exynos7.dtsi            |   20 +++++++
>>>> 3 files changed, 100 insertions(+) create mode 100644
>>>> arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi create
>>>> mode 100644 arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
>>>>
>>>> diff --git
>>>> a/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
>>>> b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi new file
>>>> mode 100644 index 0000000..1d6dcf2 --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
>>>> @@ -0,0 +1,25 @@
>>>> +/*
>>>> + * Device tree sources for Exynos7 TMU sensor configuration
>>>> + *
>>>> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
>>>> + *		http://www.samsung.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.
>>>> + *
>>>> + */
>>>> +
>>>> +#include <dt-bindings/thermal/thermal_exynos.h>
>>>> +
>>>> +#thermal-sensor-cells = <0>;
>>>> +samsung,tmu_gain = <9>;
>>>> +samsung,tmu_reference_voltage = <17>;
>>>> +samsung,tmu_noise_cancel_mode = <4>;
>>>> +samsung,tmu_efuse_value = <75>;
>>>> +samsung,tmu_min_efuse_value = <15>;
>>>> +samsung,tmu_max_efuse_value = <100>;
>>>> +samsung,tmu_first_point_trim = <25>;
>>>> +samsung,tmu_second_point_trim = <85>;
>>>> +samsung,tmu_default_temp_offset = <50>;
>>>> +samsung,tmu_cal_type = <TYPE_ONE_POINT_TRIMMING>;
>>>> diff --git a/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
>>>> b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi new file
>>>> mode 100644 index 0000000..3970545
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
>>>> @@ -0,0 +1,55 @@
>>>> +/*
>>>> + * Device tree sources for default Exynos7 thermal zone definition
>>>> + *
>>>> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
>>>> + *		http://www.samsung.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.
>>>> + *
>>>> + */
>>>> +
>>>> +trips {
>>>> +	cpu-alert-0 {
>>>> +		temperature = <75000>; /* millicelsius */
>>>> +		hysteresis = <10000>; /* millicelsius */
>>>> +		type = "passive";
>>>> +	};
>>>> +	cpu-alert-1 {
>>>> +		temperature = <80000>; /* millicelsius */
>>>> +		hysteresis = <10000>; /* millicelsius */
>>>> +		type = "passive";
>>>> +	};
>>>> +	cpu-alert-2 {
>>>> +		temperature = <85000>; /* millicelsius */
>>>> +		hysteresis = <10000>; /* millicelsius */
>>>> +		type = "passive";
>>>> +	};
>>>> +	cpu-alert-3 {
>>>> +		temperature = <90000>; /* millicelsius */
>>>> +		hysteresis = <10000>; /* millicelsius */
>>>> +		type = "passive";
>>>> +	};
>>>> +	cpu-alert-4 {
>>>> +		temperature = <95000>; /* millicelsius */
>>>> +		hysteresis = <10000>; /* millicelsius */
>>>> +		type = "passive";
>>>> +	};
>>>> +	cpu-alert-5 {
>>>> +		temperature = <100000>; /* millicelsius */
>>>> +		hysteresis = <10000>; /* millicelsius */
>>>> +		type = "passive";
>>>> +	};
>>>> +	cpu-alert-6 {
>>>> +		temperature = <110000>; /* millicelsius */
>>>> +		hysteresis = <10000>; /* millicelsius */
>>>> +		type = "passive";
>>>> +	};
>>>> +	/* HW Trip point */
>>>
>>> The comment looks unnecessary, all of these are HW trip points,
>>> right?
>>>
>>>> +	cpu-crit-0 {
>>>> +		temperature = <115000>; /* millicelsius */
>>>> +		hysteresis = <0>; /* millicelsius */
>>>> +		type = "critical";
>>>> +	};
>>>> +};
>>>> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
>>>> b/arch/arm64/boot/dts/exynos/exynos7.dtsi index c662f98..fc9d130
>>>> 100644 --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
>>>> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>>>> @@ -27,6 +27,7 @@
>>>>   		pinctrl6 = &pinctrl_fsys0;
>>>>   		pinctrl7 = &pinctrl_fsys1;
>>>>   		pinctrl8 = &pinctrl_bus1;
>>>> +		tmuctrl0 = &tmuctrl_0;
>>>
>>> Why the alias is needed?
>>>
>>>>   	};
>>>>
>>>>   	cpus {
>>>> @@ -538,6 +539,25 @@
>>>>   			clocks = <&clock_peric0 PCLK_PWM>;
>>>>   			clock-names = "timers";
>>>>   		};
>>>> +
>>>> +		tmuctrl_0: tmu at 10060000 {
>>>> +			compatible = "samsung,exynos7-tmu";
>>>> +			reg = <0x10060000 0x200>;
>>>> +			interrupts = <0 108 0>;
>>>> +			clocks = <&clock_peris PCLK_TMU>,
>>>> +				 <&clock_peris SCLK_TMU>;
>>>> +			clock-names = "tmu_apbif", "tmu_sclk";
>>>> +			#include "exynos7-tmu-sensor-conf.dtsi"
>>>> +		};
>>>> +
>>>> +		thermal-zones {
>>>> +			atlas_thermal: atlas-thermal {
>>>
>>> The atlas is a Exynos7 specific codename. The name of node should
>>> be a general class of the device, so maybe:
>>> 	atlas_thermal: cluster0-thermal
>>> ?
>>>
>>> Best regards,
>>> Krzysztof
>>>
>
>
>


From lorenzo.pieralisi at arm.com  Thu Feb 25 01:24:27 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 25 Feb 2016 09:24:27 +0000
Subject: [PATCH v3] ARM64: kernel: implement ACPI parking protocol
In-Reply-To: <56CE3C9E.7070505@riken.jp>
References: <1453806638-23167-1-git-send-email-lorenzo.pieralisi@arm.com>
 <20160202182657.GC15706@e104818-lin.cambridge.arm.com>
 <20160203112112.GA18387@red-moon>
 <20160203161834.GB26487@MBP.local>
 <20160224141832.GA26630@red-moon> <56CE3C9E.7070505@riken.jp>
Message-ID: <20160225092427.GA31728@red-moon>

On Thu, Feb 25, 2016 at 08:28:30AM +0900, Itaru Kitayama wrote:
> Lorenzo,
> 
> On Mustang the lockdep warning I reported to you is disappeared and
> the system gets to
> the prompt as you implemented, however only 7 CPUs out of 8 brought up.

It is because, as I mentioned in the other reply to this thread,
the VA should be stashed before setting up the mailboxes, patch below,
that should be final (I tested it on AMD Seattle too), please give it a go.

Thanks,
Lorenzo

-- >8 --
diff --git a/arch/arm64/kernel/acpi_parking_protocol.c b/arch/arm64/kernel/acpi_parking_protocol.c
index 4b1e5a7..dd671ef 100644
--- a/arch/arm64/kernel/acpi_parking_protocol.c
+++ b/arch/arm64/kernel/acpi_parking_protocol.c
@@ -21,7 +21,14 @@
 
 #include <asm/cpu_ops.h>
 
+struct parking_protocol_mailbox {
+	__le32 cpu_id;
+	__le32 reserved;
+	__le64 entry_point;
+};
+
 struct cpu_mailbox_entry {
+	struct parking_protocol_mailbox __iomem *mailbox;
 	phys_addr_t mailbox_addr;
 	u8 version;
 	u8 gic_cpu_id;
@@ -59,12 +66,6 @@ static int acpi_parking_protocol_cpu_prepare(unsigned int cpu)
 	return 0;
 }
 
-struct parking_protocol_mailbox {
-	__le32 cpu_id;
-	__le32 reserved;
-	__le64 entry_point;
-};
-
 static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
 {
 	struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
@@ -97,6 +98,12 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
 	}
 
 	/*
+	 * stash the mailbox address mapping to use it for further checks
+	 * in postboot method
+	 */
+	cpu_entry->mailbox = mailbox;
+
+	/*
 	 * We write the entry point and cpu id as LE regardless of the
 	 * native endianness of the kernel. Therefore, any boot-loaders
 	 * that read this address need to convert this address to the
@@ -107,8 +114,6 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
 
 	arch_send_wakeup_ipi_mask(cpumask_of(cpu));
 
-	iounmap(mailbox);
-
 	return 0;
 }
 
@@ -116,32 +121,15 @@ static void acpi_parking_protocol_cpu_postboot(void)
 {
 	int cpu = smp_processor_id();
 	struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
-	struct parking_protocol_mailbox __iomem *mailbox;
+	struct parking_protocol_mailbox __iomem *mailbox = cpu_entry->mailbox;
 	__le64 entry_point;
 
-	/*
-	 * Map mailbox memory with attribute device nGnRE (ie ioremap -
-	 * this deviates from the parking protocol specifications since
-	 * the mailboxes are required to be mapped nGnRnE; the attribute
-	 * discrepancy is harmless insofar as the protocol specification
-	 * is concerned).
-	 * If the mailbox is mistakenly allocated in the linear mapping
-	 * by FW ioremap will fail since the mapping will be prevented
-	 * by the kernel (it clashes with the linear mapping attributes
-	 * specifications).
-	 */
-	mailbox = ioremap(cpu_entry->mailbox_addr, sizeof(*mailbox));
-	if (!mailbox)
-		return;
-
 	entry_point = readl_relaxed(&mailbox->entry_point);
 	/*
 	 * Check if firmware has cleared the entry_point as expected
 	 * by the protocol specification.
 	 */
 	WARN_ON(entry_point);
-
-	iounmap(mailbox);
 }
 
 const struct cpu_operations acpi_parking_protocol_ops = {


From linus.walleij at linaro.org  Thu Feb 25 01:26:34 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 10:26:34 +0100
Subject: [PATCH v4] Fix sun7i pin assignment for IRQ's
In-Reply-To: <1456096638-21961-1-git-send-email-henry@nitronetworks.nl>
References: <1456096638-21961-1-git-send-email-henry@nitronetworks.nl>
Message-ID: <CACRpkdbh8Svn4Y8XfoXVBzTuePufoZGaRVe8AALT31uK-aawWQ@mail.gmail.com>

On Mon, Feb 22, 2016 at 12:17 AM, Henry Paulissen <draakje197 at gmail.com> wrote:

> After testing IRQ pins we found some bugs in the pinctrl declaration.
>
> Signed-off-by: Henry Paulissen <henry at nitronetworks.nl>

This v4 patch applied with Chen-Yu's ACK.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Feb 25 01:27:55 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 10:27:55 +0100
Subject: [PATCH] pinctrl: sunxi: Add missing H3 R_PIO binding documentation
In-Reply-To: <20160218194931.GA16393@box2.japko.eu>
References: <CACRpkdbfNeh7_=3ReQtJc7OxkkQEn+BUhZ0O0SKnFsRD=WZiUQ@mail.gmail.com>
 <20160218194931.GA16393@box2.japko.eu>
Message-ID: <CACRpkdaOpjhqUBSvYrCcZQgtTtFs79FwvKO5f4z07CCzNA44PA@mail.gmail.com>

On Thu, Feb 18, 2016 at 8:49 PM, Krzysztof Adamski <k at japko.eu> wrote:

> allwinner,sun8i-h3-r-pinctrl was added by
> commit ba83a11104ae ("pinctrl: sunxi: Add H3 R_PIO controller support")
> but the patch was missing proper binding documentation. This patch fixes
> this issue.
>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

Patch applied with Chen-Yu's ACK.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Feb 25 01:31:29 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 10:31:29 +0100
Subject: [PATCH v5 3/4] ARM: dts: sun8i-h3: Add R_PIO controller node to
 the dtsi
In-Reply-To: <1456146208-13890-4-git-send-email-k@japko.eu>
References: <1456146208-13890-1-git-send-email-k@japko.eu>
 <1456146208-13890-4-git-send-email-k@japko.eu>
Message-ID: <CACRpkdaoNwmf93ut1Nk83N5j+rGjmUX5TTrKjWyfhEMUwXyeJQ@mail.gmail.com>

On Mon, Feb 22, 2016 at 2:03 PM, Krzysztof Adamski <k at japko.eu> wrote:

> Add the corresponding device node for R_PIO on H3 to the dtsi. Support
> for the controller was added in earlier commit.
>
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

Please funnel this through the ARM SoC tree.

Yours,
Linus Walleij


From lars.persson at axis.com  Thu Feb 25 01:34:14 2016
From: lars.persson at axis.com (Lars Persson)
Date: Thu, 25 Feb 2016 10:34:14 +0100
Subject: [PATCH] ARM: dts: artpec: update clock bindings in artpec6.dtsi
Message-ID: <1456392854-13527-1-git-send-email-larper@axis.com>

The clock bindings for the main clock controller was changed to an
indexed controller style binding on request of the clk
maintainers. This updates the dtsi to use the new bindings.

Signed-off-by: Lars Persson <larper at axis.com>
---
Note: This patch depends on a header file delivered through the clk tree in
"clk: add device tree binding for Artpec-6 clock controller".

 arch/arm/boot/dts/artpec6.dtsi | 100 +++++++++--------------------------------
 1 file changed, 21 insertions(+), 79 deletions(-)

diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/arm/boot/dts/artpec6.dtsi
index 3043016..db41b52 100644
--- a/arch/arm/boot/dts/artpec6.dtsi
+++ b/arch/arm/boot/dts/artpec6.dtsi
@@ -41,6 +41,7 @@
  */
 
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/axis,artpec6-clkctrl.h>
 #include "skeleton.dtsi"
 
 / {
@@ -91,96 +92,32 @@
 		clock-frequency = <50000000>;
 	};
 
-	/* PLL1 is used by CPU and some peripherals */
-	pll1_clk: pll1_clk at f8000000 {
+	eth_phy_ref_clk: eth_phy_ref_clk {
 		#clock-cells = <0>;
-		compatible = "axis,artpec6-pll1-clock";
-		reg = <0xf8000000 4>;
-		clocks = <&ext_clk>;
-	};
-
-	cpu_clk: cpu_clk {
-		#clock-cells = <0>;
-		compatible = "fixed-factor-clock";
-		clock-div = <1>;
-		clock-mult = <1>;
-		clocks = <&pll1_clk>;
-		clock-output-names = "cpu_clk";
-	};
-
-	cpu_clkdiv2: cpu_clkdiv2 {
-		#clock-cells = <0>;
-		compatible = "fixed-factor-clock";
-		clock-div = <2>;
-		clock-mult = <1>;
-		clocks = <&cpu_clk>;
-	};
-
-	cpu_clkdiv4: cpu_clkdiv4 {
-		#clock-cells = <0>;
-		compatible = "fixed-factor-clock";
-		clock-div = <4>;
-		clock-mult = <1>;
-		clocks = <&cpu_clk>;
-	};
-
-	apb_pclk: apb_pclk {
-		#clock-cells = <0>;
-		compatible = "fixed-factor-clock";
-		clock-div = <8>;
-		clock-mult = <1>;
-		clocks = <&cpu_clk>;
-		clock-output-names = "apb_pclk";
+		compatible = "fixed-clock";
+		clock-frequency = <125000000>;
 	};
 
-	/* PLL2 is used by a number of peripherals, including UDL */
-	pll2: pll2 {
-		#clock-cells = <0>;
-		compatible = "fixed-factor-clock";
-		clock-div = <1>;
-		clock-mult = <24>;
+	clkctrl: clkctrl at 0xf8000000 {
+		#clock-cells = <1>;
+		compatible = "axis,artpec6-clkctrl";
+		reg = <0xf8000000 0x48>;
 		clocks = <&ext_clk>;
+		clock-names = "sys_refclk";
 	};
 
-	/* PLL2DIV2 is used by the Fractional Clock Divider, for i2s */
-	pll2div2: pll2div2 {
-		#clock-cells = <0>;
-		compatible = "fixed-factor-clock";
-		clock-div = <2>;
-		clock-mult = <1>;
-		clocks = <&pll2>;
-	};
-
-	pll2div12: pll2div12 {
-		#clock-cells = <0>;
-		compatible = "fixed-factor-clock";
-		clock-div = <12>;
-		clock-mult = <1>;
-		clocks = <&pll2>;
-	};
-
-	pll2div24: pll2div24 {
-		#clock-cells = <0>;
-		compatible = "fixed-factor-clock";
-		clock-div = <24>;
-		clock-mult = <1>;
-		clocks = <&pll2>;
-		clock-output-names = "uart_clk";
-	};
-
-
 	gtimer at faf00200 {
 		compatible = "arm,cortex-a9-global-timer";
 		reg = <0xfaf00200 0x20>;
 		interrupts = <GIC_PPI 11 0xf01>;
-		clocks = <&cpu_clkdiv2>;
+		clocks = <&clkctrl ARTPEC6_CLK_CPU_PERIPH>;
 	};
 
 	timer at faf00600 {
 		compatible = "arm,cortex-a9-twd-timer";
 		reg = <0xfaf00600 0x20>;
 		interrupts = <GIC_PPI 13 0xf04>;
-		clocks = <&cpu_clkdiv2>;
+		clocks = <&clkctrl ARTPEC6_CLK_CPU_PERIPH>;
 		status = "disabled";
 	};
 
@@ -220,7 +157,8 @@
 
 		ethernet: ethernet at f8010000 {
 			clock-names = "phy_ref_clk", "apb_pclk";
-			clocks = <&ext_clk>, <&apb_pclk>;
+			clocks = <&eth_phy_ref_clk>,
+				<&clkctrl ARTPEC6_CLK_ETH_ACLK>;
 			compatible = "snps,dwc-qos-ethernet-4.10";
 			interrupt-parent = <&intc>;
 			interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
@@ -238,7 +176,8 @@
 			compatible = "arm,pl011", "arm,primecell";
 			reg = <0xf8036000 0x1000>;
 			interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&pll2div24>, <&apb_pclk>;
+			clocks = <&clkctrl ARTPEC6_CLK_UART_REFCLK>,
+				<&clkctrl ARTPEC6_CLK_UART_PCLK>;
 			clock-names = "uart_clk", "apb_pclk";
 			status = "disabled";
 		};
@@ -246,7 +185,8 @@
 			compatible = "arm,pl011", "arm,primecell";
 			reg = <0xf8037000 0x1000>;
 			interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&pll2div24>, <&apb_pclk>;
+			clocks = <&clkctrl ARTPEC6_CLK_UART_REFCLK>,
+				<&clkctrl ARTPEC6_CLK_UART_PCLK>;
 			clock-names = "uart_clk", "apb_pclk";
 			status = "disabled";
 		};
@@ -254,7 +194,8 @@
 			compatible = "arm,pl011", "arm,primecell";
 			reg = <0xf8038000 0x1000>;
 			interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&pll2div24>, <&apb_pclk>;
+			clocks = <&clkctrl ARTPEC6_CLK_UART_REFCLK>,
+				<&clkctrl ARTPEC6_CLK_UART_PCLK>;
 			clock-names = "uart_clk", "apb_pclk";
 			status = "disabled";
 		};
@@ -262,7 +203,8 @@
 			compatible = "arm,pl011", "arm,primecell";
 			reg = <0xf8039000 0x1000>;
 			interrupts = <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&pll2div24>, <&apb_pclk>;
+			clocks = <&clkctrl ARTPEC6_CLK_UART_REFCLK>,
+				<&clkctrl ARTPEC6_CLK_UART_PCLK>;
 			clock-names = "uart_clk", "apb_pclk";
 			status = "disabled";
 		};
-- 
2.1.4



From linus.walleij at linaro.org  Thu Feb 25 01:36:35 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 10:36:35 +0100
Subject: [PATCH v5] Fix sun7i pin assignment for IRQ's
In-Reply-To: <1456129208-11490-1-git-send-email-henry@nitronetworks.nl>
References: <1456129208-11490-1-git-send-email-henry@nitronetworks.nl>
Message-ID: <CACRpkdbbOyp-=5n64QBhigtAebKV5BmFcnvFumjXv3f8bj8pbg@mail.gmail.com>

On Mon, Feb 22, 2016 at 9:20 AM, Henry Paulissen <draakje197 at gmail.com> wrote:

> After testing IRQ pins we found some bugs in the pinctrl declaration.
> Both PI* and PC* pins didn't work. PI* pins seemed to be connected
> to the wrong mux and PC* pins waren't working at all.
>
> Please note that the A20 soc manual is contradicting between version
> and even within the same document for both the PI and PC pins.
>
> Patch is based on testing with the hardware itself.
>
> Signed-off-by: Henry Paulissen <henry at nitronetworks.nl>
(...)
> Changes in v5:
>     Added a more detailed description.

Aha there is a v5. I took out the v4 and applied this
instead.

Yours,
Linus Walleij


From peter.ujfalusi at ti.com  Thu Feb 25 01:39:35 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 25 Feb 2016 11:39:35 +0200
Subject: [PATCH 3/5] ARM: davinci: dm365: Add dma_slave_map to edma
In-Reply-To: <56CADBB1.9040908@ti.com>
References: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>
 <1454416997-14230-4-git-send-email-peter.ujfalusi@ti.com>
 <56CADBB1.9040908@ti.com>
Message-ID: <56CECBD7.1020101@ti.com>

On 02/22/2016 11:58 AM, Sekhar Nori wrote:
> On Tuesday 02 February 2016 06:13 PM, Peter Ujfalusi wrote:
>> Provide the dma_slave_map to edma which will allow us to move the drivers
>> to the new, simpler dmaengine API and we can remove the DMA resources also
>> for the devices.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> 
>> FIX: dm365
> 
> dropped this "note to self" :)

Oh, yes, thanks. I needed to fix up things while addressing the core support
comments and the struct changed on the way several times.
Sorry about it.

> 
>> ---
>>  arch/arm/mach-davinci/dm365.c | 22 ++++++++++++++++++++++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
>> index 01843fbcc9ea..d26dc2b4339a 100644
>> --- a/arch/arm/mach-davinci/dm365.c
>> +++ b/arch/arm/mach-davinci/dm365.c
>> @@ -17,6 +17,7 @@
>>  #include <linux/serial_8250.h>
>>  #include <linux/platform_device.h>
>>  #include <linux/dma-mapping.h>
>> +#include <linux/dmaengine.h>
>>  #include <linux/spi/spi.h>
>>  #include <linux/platform_data/edma.h>
>>  #include <linux/platform_data/gpio-davinci.h>
>> @@ -862,9 +863,30 @@ static s8 dm365_queue_priority_mapping[][2] = {
>>  	{-1, -1},
>>  };
>>  
>> +static const struct dma_slave_map da365_edma_map[] = {
> 
> This should be "dm365_edma_map".
> 
> Fixed both locally while applying.
> 
> Regards,
> Sekhar
> 


-- 
P?ter


From peter.ujfalusi at ti.com  Thu Feb 25 01:40:08 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 25 Feb 2016 11:40:08 +0200
Subject: [PATCH 1/5] ARM: davinci: devices-da8xx: Add dma_slave_map to edma
In-Reply-To: <56CAD6B7.2030706@ti.com>
References: <1454416997-14230-1-git-send-email-peter.ujfalusi@ti.com>
 <1454416997-14230-2-git-send-email-peter.ujfalusi@ti.com>
 <56CAD6B7.2030706@ti.com>
Message-ID: <56CECBF8.6040504@ti.com>

On 02/22/2016 11:36 AM, Sekhar Nori wrote:
> On Tuesday 02 February 2016 06:13 PM, Peter Ujfalusi wrote:
> 
>> +static const struct dma_slave_map da850_edma1_map[] = {
>> +	{ "da830-mmc.1", "rx", EDMA_FILTER_PARAM(0, 28) },
>> +	{ "da830-mmc.1", "tx", EDMA_FILTER_PARAM(0, 29) },
> 
> This should be EDMA_FILTER_PARAM(1, 29) (and similar for rx). No need to
> resend though, I will fix while applying.

True and thank you for fixing it up!

> 
> Regards,
> Sekhar
> 


-- 
P?ter


From lorenzo.pieralisi at arm.com  Thu Feb 25 01:44:18 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 25 Feb 2016 09:44:18 +0000
Subject: [PATCH] drivers: perf: arm: implement CPU_PM notifier
In-Reply-To: <7hsi0hr3wj.fsf@baylibre.com>
References: <1456251759-24768-1-git-send-email-lorenzo.pieralisi@arm.com>
 <7hsi0hr3wj.fsf@baylibre.com>
Message-ID: <20160225094417.GB31728@red-moon>

On Wed, Feb 24, 2016 at 05:10:20PM -0800, Kevin Hilman wrote:
> Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> writes:
> 
> > When a CPU is suspended (either through suspend-to-RAM or CPUidle),
> > its PMU registers content can be lost, which means that counters
> > registers values that were initialized on power down entry have to be
> > reprogrammed on power-up to make sure the counters set-up is preserved
> 
> This assumes that the PMUs are always sharing a power rail with a
> specific CPU, not the cluster.  Is that a reliable assumption?

As reliable as assuming the GIC HW state needs save/restore on idle-state
entry, if we have no power domains information linked to CPU PM
notifiers saving/restoring everything every time an idle state deeper
than wfi is entered is the best we can do.

As far as this patch is concerned, if the PMU is on a different power
domain than the CPU, I agree that stopping/resetting/restoring the
PMU registers is a waste of cycles (I will test it also by triggering
the notifiers on wfi, to make sure the reset is not disruptive on
a cpu that is not powered off), I see no alternative other than disabling
idle to carry out profiling sanely (or implement CPU PM notifiers with
runtime PM).

Thanks,
Lorenzo


From p.zabel at pengutronix.de  Thu Feb 25 01:44:40 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 25 Feb 2016 10:44:40 +0100
Subject: [PATCH 0/2] ARM: Make reset_control_ops const
Message-ID: <1456393482-26318-1-git-send-email-p.zabel@pengutronix.de>

Since commit 203d4f347d86 ("reset: Make reset_control_ops const") marked
the ops pointer in struct reset_controller_dev as const, these structs
can be made const, too. The commit is currently sitting in the
arm-soc/for-next branch.

regards
Philipp

Philipp Zabel (2):
  ARM: imx: Make reset_control_ops const
  ARM: sirf: Make reset_control_ops const

 arch/arm/mach-imx/src.c     | 2 +-
 arch/arm/mach-prima2/rstc.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.7.0



From p.zabel at pengutronix.de  Thu Feb 25 01:44:41 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 25 Feb 2016 10:44:41 +0100
Subject: [PATCH 1/2] ARM: imx: Make reset_control_ops const
In-Reply-To: <1456393482-26318-1-git-send-email-p.zabel@pengutronix.de>
References: <1456393482-26318-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1456393482-26318-2-git-send-email-p.zabel@pengutronix.de>

The imx_src_ops structure is never modified. Make it const.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 arch/arm/mach-imx/src.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/src.c b/arch/arm/mach-imx/src.c
index 45f7f4e..70b083f 100644
--- a/arch/arm/mach-imx/src.c
+++ b/arch/arm/mach-imx/src.c
@@ -73,7 +73,7 @@ static int imx_src_reset_module(struct reset_controller_dev *rcdev,
 	return 0;
 }
 
-static struct reset_control_ops imx_src_ops = {
+static const struct reset_control_ops imx_src_ops = {
 	.reset = imx_src_reset_module,
 };
 
-- 
2.7.0



From p.zabel at pengutronix.de  Thu Feb 25 01:44:42 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 25 Feb 2016 10:44:42 +0100
Subject: [PATCH 2/2] ARM: sirf: Make reset_control_ops const
In-Reply-To: <1456393482-26318-1-git-send-email-p.zabel@pengutronix.de>
References: <1456393482-26318-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1456393482-26318-3-git-send-email-p.zabel@pengutronix.de>

The sirfsoc_rstc_ops structure is never modified. Make it const.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 arch/arm/mach-prima2/rstc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-prima2/rstc.c b/arch/arm/mach-prima2/rstc.c
index 7c251eb..1cdb6167 100644
--- a/arch/arm/mach-prima2/rstc.c
+++ b/arch/arm/mach-prima2/rstc.c
@@ -54,7 +54,7 @@ static int sirfsoc_reset_module(struct reset_controller_dev *rcdev,
 	return 0;
 }
 
-static struct reset_control_ops sirfsoc_rstc_ops = {
+static const struct reset_control_ops sirfsoc_rstc_ops = {
 	.reset = sirfsoc_reset_module,
 };
 
-- 
2.7.0



From p.zabel at pengutronix.de  Thu Feb 25 01:46:08 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 25 Feb 2016 10:46:08 +0100
Subject: [PATCH] soc: dove: Make reset_control_ops const
Message-ID: <1456393568-28363-1-git-send-email-p.zabel@pengutronix.de>

The pmu_reset_ops structure is never modified. Make it const.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
Since commit 203d4f347d86 ("reset: Make reset_control_ops const") marked
the ops pointer in struct reset_controller_dev as const, this struct can
be made const, too. The commit is currently sitting in the
arm-soc/for-next branch.
---
 drivers/soc/dove/pmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/dove/pmu.c b/drivers/soc/dove/pmu.c
index 039374e..95d77ec 100644
--- a/drivers/soc/dove/pmu.c
+++ b/drivers/soc/dove/pmu.c
@@ -87,7 +87,7 @@ static int pmu_reset_deassert(struct reset_controller_dev *rc, unsigned long id)
 	return 0;
 }
 
-static struct reset_control_ops pmu_reset_ops = {
+static const struct reset_control_ops pmu_reset_ops = {
 	.reset = pmu_reset_reset,
 	.assert = pmu_reset_assert,
 	.deassert = pmu_reset_deassert,
-- 
2.7.0



From suzuki.poulose at arm.com  Thu Feb 25 01:52:42 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Thu, 25 Feb 2016 09:52:42 +0000
Subject: [PATCH v2 2/8] arm64: HWCAP: Split COMPAT HWCAP table entries
In-Reply-To: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
References: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456393968-17386-3-git-send-email-suzuki.poulose@arm.com>

In order to handle systems which do not support 32bit at EL0,
split the COMPAT HWCAP entries into a separate table which can
be processed, only if the support is available.

Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/kernel/cpufeature.c |   78 ++++++++++++++++++++++++----------------
 1 file changed, 47 insertions(+), 31 deletions(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index a3c254b..b88cbef 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -691,6 +691,10 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
 	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_ATOMICS_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, HWCAP_ATOMICS),
 	HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_FP),
 	HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_ASIMD),
+	{},
+};
+
+static const struct arm64_cpu_capabilities compat_elf_hwcaps[] = {
 #ifdef CONFIG_COMPAT
 	HWCAP_CAP(SYS_ID_ISAR5_EL1, ID_ISAR5_AES_SHIFT, FTR_UNSIGNED, 2, CAP_COMPAT_HWCAP2, COMPAT_HWCAP2_PMULL),
 	HWCAP_CAP(SYS_ID_ISAR5_EL1, ID_ISAR5_AES_SHIFT, FTR_UNSIGNED, 1, CAP_COMPAT_HWCAP2, COMPAT_HWCAP2_AES),
@@ -746,10 +750,9 @@ static bool cpus_have_elf_hwcap(const struct arm64_cpu_capabilities *cap)
 	return rc;
 }
 
-static void __init setup_elf_hwcaps(void)
+static void __init setup_elf_hwcaps(const struct arm64_cpu_capabilities *hwcaps)
 {
 	int i;
-	const struct arm64_cpu_capabilities *hwcaps = arm64_elf_hwcaps;
 
 	for (i = 0; hwcaps[i].desc; i++)
 		if (hwcaps[i].matches(&hwcaps[i]))
@@ -850,29 +853,26 @@ static void check_early_cpu_features(void)
 	verify_cpu_asid_bits();
 }
 
-/*
- * Run through the enabled system capabilities and enable() it on this CPU.
- * The capabilities were decided based on the available CPUs at the boot time.
- * Any new CPU should match the system wide status of the capability. If the
- * new CPU doesn't have a capability which the system now has enabled, we
- * cannot do anything to fix it up and could cause unexpected failures. So
- * we park the CPU.
- */
-void verify_local_cpu_capabilities(void)
+static void
+verify_local_elf_hwcaps(const struct arm64_cpu_capabilities *caps)
 {
 	int i;
-	const struct arm64_cpu_capabilities *caps;
 
-	check_early_cpu_features();
-
-	/*
-	 * If we haven't computed the system capabilities, there is nothing
-	 * to verify.
-	 */
-	if (!sys_caps_initialised)
-		return;
+	for (i = 0; caps[i].desc; i++) {
+		if (!cpus_have_elf_hwcap(&caps[i]))
+			continue;
+		if (!feature_matches(__raw_read_system_reg(caps[i].sys_reg), &caps[i])) {
+			pr_crit("CPU%d: missing HWCAP: %s\n",
+					smp_processor_id(), caps[i].desc);
+			cpu_die_early();
+		}
+	}
+}
 
-	caps = arm64_features;
+static void
+verify_local_cpu_features(const struct arm64_cpu_capabilities *caps)
+{
+	int i;
 	for (i = 0; caps[i].desc; i++) {
 		if (!cpus_have_cap(caps[i].capability) || !caps[i].sys_reg)
 			continue;
@@ -888,16 +888,31 @@ void verify_local_cpu_capabilities(void)
 		if (caps[i].enable)
 			caps[i].enable(NULL);
 	}
+}
 
-	for (i = 0, caps = arm64_elf_hwcaps; caps[i].desc; i++) {
-		if (!cpus_have_elf_hwcap(&caps[i]))
-			continue;
-		if (!feature_matches(__raw_read_system_reg(caps[i].sys_reg), &caps[i])) {
-			pr_crit("CPU%d: missing HWCAP: %s\n",
-					smp_processor_id(), caps[i].desc);
-			cpu_die_early();
-		}
-	}
+/*
+ * Run through the enabled system capabilities and enable() it on this CPU.
+ * The capabilities were decided based on the available CPUs at the boot time.
+ * Any new CPU should match the system wide status of the capability. If the
+ * new CPU doesn't have a capability which the system now has enabled, we
+ * cannot do anything to fix it up and could cause unexpected failures. So
+ * we park the CPU.
+ */
+void verify_local_cpu_capabilities(void)
+{
+
+	check_early_cpu_features();
+
+	/*
+	 * If we haven't computed the system capabilities, there is nothing
+	 * to verify.
+	 */
+	if (!sys_caps_initialised)
+		return;
+
+	verify_local_cpu_features(arm64_features);
+	verify_local_elf_hwcaps(arm64_elf_hwcaps);
+	verify_local_elf_hwcaps(compat_elf_hwcaps);
 }
 
 static void __init setup_feature_capabilities(void)
@@ -913,7 +928,8 @@ void __init setup_cpu_features(void)
 
 	/* Set the CPU feature capabilies */
 	setup_feature_capabilities();
-	setup_elf_hwcaps();
+	setup_elf_hwcaps(arm64_elf_hwcaps);
+	setup_elf_hwcaps(compat_elf_hwcaps);
 
 	/* Advertise that we have computed the system capabilities */
 	set_sys_caps_initialised();
-- 
1.7.9.5



From suzuki.poulose at arm.com  Thu Feb 25 01:52:41 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Thu, 25 Feb 2016 09:52:41 +0000
Subject: [PATCH v2 1/8] arm64: hwcaps: Cleanup naming
In-Reply-To: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
References: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456393968-17386-2-git-send-email-suzuki.poulose@arm.com>

We use hwcaps for referring to ELF hwcaps capability information.
However this can be confusing with 'cpu_hwcaps' which stands for the
CPU capability bit field. This patch cleans up the names to make it
a bit more readable.

Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/kernel/cpufeature.c |   18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index f29d63c..a3c254b 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -682,7 +682,7 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.hwcap = cap,					\
 	}
 
-static const struct arm64_cpu_capabilities arm64_hwcaps[] = {
+static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
 	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_AES_SHIFT, FTR_UNSIGNED, 2, CAP_HWCAP, HWCAP_PMULL),
 	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_AES_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_AES),
 	HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SHA1_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SHA1),
@@ -701,7 +701,7 @@ static const struct arm64_cpu_capabilities arm64_hwcaps[] = {
 	{},
 };
 
-static void __init cap_set_hwcap(const struct arm64_cpu_capabilities *cap)
+static void __init cap_set_elf_hwcap(const struct arm64_cpu_capabilities *cap)
 {
 	switch (cap->hwcap_type) {
 	case CAP_HWCAP:
@@ -722,7 +722,7 @@ static void __init cap_set_hwcap(const struct arm64_cpu_capabilities *cap)
 }
 
 /* Check if we have a particular HWCAP enabled */
-static bool __maybe_unused cpus_have_hwcap(const struct arm64_cpu_capabilities *cap)
+static bool cpus_have_elf_hwcap(const struct arm64_cpu_capabilities *cap)
 {
 	bool rc;
 
@@ -746,14 +746,14 @@ static bool __maybe_unused cpus_have_hwcap(const struct arm64_cpu_capabilities *
 	return rc;
 }
 
-static void __init setup_cpu_hwcaps(void)
+static void __init setup_elf_hwcaps(void)
 {
 	int i;
-	const struct arm64_cpu_capabilities *hwcaps = arm64_hwcaps;
+	const struct arm64_cpu_capabilities *hwcaps = arm64_elf_hwcaps;
 
 	for (i = 0; hwcaps[i].desc; i++)
 		if (hwcaps[i].matches(&hwcaps[i]))
-			cap_set_hwcap(&hwcaps[i]);
+			cap_set_elf_hwcap(&hwcaps[i]);
 }
 
 void update_cpu_capabilities(const struct arm64_cpu_capabilities *caps,
@@ -889,8 +889,8 @@ void verify_local_cpu_capabilities(void)
 			caps[i].enable(NULL);
 	}
 
-	for (i = 0, caps = arm64_hwcaps; caps[i].desc; i++) {
-		if (!cpus_have_hwcap(&caps[i]))
+	for (i = 0, caps = arm64_elf_hwcaps; caps[i].desc; i++) {
+		if (!cpus_have_elf_hwcap(&caps[i]))
 			continue;
 		if (!feature_matches(__raw_read_system_reg(caps[i].sys_reg), &caps[i])) {
 			pr_crit("CPU%d: missing HWCAP: %s\n",
@@ -913,7 +913,7 @@ void __init setup_cpu_features(void)
 
 	/* Set the CPU feature capabilies */
 	setup_feature_capabilities();
-	setup_cpu_hwcaps();
+	setup_elf_hwcaps();
 
 	/* Advertise that we have computed the system capabilities */
 	set_sys_caps_initialised();
-- 
1.7.9.5



From suzuki.poulose at arm.com  Thu Feb 25 01:52:40 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Thu, 25 Feb 2016 09:52:40 +0000
Subject: [PATCH v2 0/8] arm64: Support for systems without AArch32 state
Message-ID: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>

This series add checks to make sure that the AArch32 state is
supported before we process the 32bit ID registers. Also
checks the same for COMPAT binary execution.

(Painfully) applies on top of 4.5-rc5 + [1] + [2].

Or it is available here :
  git://linux-arm.org/linux-skp.git noaarch32/v2-4.5-rc5

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/410556.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/401913.html

Changes since V1:
  - Prevent changing the personality to PER_LINUX32 by adding
    wrapper for personality() syscall.
  - Add the check to KVM before initialising a AArch32 vcpu
  - Tested on hardware.

Btw, linux32 doesn't complain when the personality() syscall fails to change
to PER_LINUX32. You can verify the personality by running 
 $ cat /proc/cpuinfo
 which would still list the 64bit features for the CPUs.


Suzuki K Poulose (7):
  arm64: hwcaps: Cleanup naming
  arm64: HWCAP: Split COMPAT HWCAP table entries
  arm64: Add helpers for detecting AArch32 support at EL0
  arm64: cpufeature: Check availability of AArch32
  arm64: cpufeature: Track 32bit EL0 support
  arm64: Add a wrapper for personality() syscall
  arm64: kvm: Check support for AArch32 for 32bit guests

Yury Norov (1):
  arm64: compat: Check for AArch32 state

 arch/arm/include/asm/kvm_host.h     |    5 +
 arch/arm/kvm/arm.c                  |    3 +
 arch/arm64/include/asm/cpufeature.h |   15 ++-
 arch/arm64/include/asm/elf.h        |    3 +-
 arch/arm64/include/asm/kvm_host.h   |    8 ++
 arch/arm64/include/asm/sysreg.h     |    1 +
 arch/arm64/kernel/cpufeature.c      |  184 +++++++++++++++++++++--------------
 arch/arm64/kernel/cpuinfo.c         |   37 +++----
 arch/arm64/kernel/sys.c             |   10 ++
 9 files changed, 173 insertions(+), 93 deletions(-)

-- 
1.7.9.5



From suzuki.poulose at arm.com  Thu Feb 25 01:52:46 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Thu, 25 Feb 2016 09:52:46 +0000
Subject: [PATCH v2 6/8] arm64: Add a wrapper for personality() syscall
In-Reply-To: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
References: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456393968-17386-7-git-send-email-suzuki.poulose@arm.com>

In order to prevent setting PER_LINUX32 on systems without
32bit EL0 support, add a wrapper for personality() syscall.

Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/kernel/sys.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/kernel/sys.c b/arch/arm64/kernel/sys.c
index 75151aa..817d860 100644
--- a/arch/arm64/kernel/sys.c
+++ b/arch/arm64/kernel/sys.c
@@ -36,11 +36,17 @@ asmlinkage long sys_mmap(unsigned long addr, unsigned long len,
 	return sys_mmap_pgoff(addr, len, prot, flags, fd, off >> PAGE_SHIFT);
 }
 
+SYSCALL_DEFINE1(arm64_personality, unsigned int, personality)
+{
+	return sys_personality(personality);
+}
+
 /*
  * Wrappers to pass the pt_regs argument.
  */
 asmlinkage long sys_rt_sigreturn_wrapper(void);
 #define sys_rt_sigreturn	sys_rt_sigreturn_wrapper
+#define sys_personality		sys_arm64_personality
 
 #undef __SYSCALL
 #define __SYSCALL(nr, sym)	[nr] = sym,
-- 
1.7.9.5



From suzuki.poulose at arm.com  Thu Feb 25 01:52:45 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Thu, 25 Feb 2016 09:52:45 +0000
Subject: [PATCH v2 5/8] arm64: cpufeature: Track 32bit EL0 support
In-Reply-To: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
References: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456393968-17386-6-git-send-email-suzuki.poulose@arm.com>

Keep track of the support for 32bit EL0.

Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/include/asm/cpufeature.h |    8 +++++++-
 arch/arm64/kernel/cpufeature.c      |    9 +++++++++
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 98f83d7..46c6f4c 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -30,8 +30,9 @@
 #define ARM64_HAS_LSE_ATOMICS			5
 #define ARM64_WORKAROUND_CAVIUM_23154		6
 #define ARM64_WORKAROUND_834220			7
+#define ARM64_HAS_32BIT_EL0			8
 
-#define ARM64_NCAPS				8
+#define ARM64_NCAPS				9
 
 #ifndef __ASSEMBLY__
 
@@ -187,6 +188,11 @@ static inline bool cpu_supports_mixed_endian_el0(void)
 	return id_aa64mmfr0_mixed_endian_el0(read_cpuid(ID_AA64MMFR0_EL1));
 }
 
+static inline bool system_supports_32bit_el0(void)
+{
+	return cpus_have_cap(ARM64_HAS_32BIT_EL0);
+}
+
 static inline bool system_supports_mixed_endian_el0(void)
 {
 	return id_aa64mmfr0_mixed_endian_el0(read_system_reg(SYS_ID_AA64MMFR0_EL1));
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 853e575..8f6b674 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -675,6 +675,15 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.min_field_value = 2,
 	},
 #endif /* CONFIG_AS_LSE && CONFIG_ARM64_LSE_ATOMICS */
+	{
+		.desc = "32 bit EL0",
+		.capability = ARM64_HAS_32BIT_EL0,
+		.matches = has_cpuid_feature,
+		.sys_reg = SYS_ID_AA64PFR0_EL1,
+		.field_pos = ID_AA64PFR0_EL0_SHIFT,
+		.sign = FTR_UNSIGNED,
+		.min_field_value = ID_AA64PFR0_EL0_32BIT_64BIT,
+	},
 	{},
 };
 
-- 
1.7.9.5



From suzuki.poulose at arm.com  Thu Feb 25 01:52:43 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Thu, 25 Feb 2016 09:52:43 +0000
Subject: [PATCH v2 3/8] arm64: Add helpers for detecting AArch32 support at EL0
In-Reply-To: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
References: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456393968-17386-4-git-send-email-suzuki.poulose@arm.com>

Adds a helper to extract the support for AArch32 at EL0

Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/include/asm/cpufeature.h |    7 +++++++
 arch/arm64/include/asm/sysreg.h     |    1 +
 2 files changed, 8 insertions(+)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 5444a77..98f83d7 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -165,6 +165,13 @@ static inline bool id_aa64mmfr0_mixed_endian_el0(u64 mmfr0)
 		cpuid_feature_extract_unsigned_field(mmfr0, ID_AA64MMFR0_BIGENDEL0_SHIFT) == 0x1;
 }
 
+static inline bool id_aa64pfr0_32bit_el0(u64 pfr0)
+{
+	u32 val = cpuid_feature_extract_unsigned_field(pfr0, ID_AA64PFR0_EL0_SHIFT);
+
+	return val == ID_AA64PFR0_EL0_32BIT_64BIT;
+}
+
 void __init setup_cpu_features(void);
 
 void update_cpu_capabilities(const struct arm64_cpu_capabilities *caps,
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 4aeebec..76d2f3e 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -111,6 +111,7 @@
 #define ID_AA64PFR0_ASIMD_SUPPORTED	0x0
 #define ID_AA64PFR0_EL1_64BIT_ONLY	0x1
 #define ID_AA64PFR0_EL0_64BIT_ONLY	0x1
+#define ID_AA64PFR0_EL0_32BIT_64BIT	0x2
 
 /* id_aa64mmfr0 */
 #define ID_AA64MMFR0_TGRAN4_SHIFT	28
-- 
1.7.9.5



From suzuki.poulose at arm.com  Thu Feb 25 01:52:44 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Thu, 25 Feb 2016 09:52:44 +0000
Subject: [PATCH v2 4/8] arm64: cpufeature: Check availability of AArch32
In-Reply-To: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
References: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456393968-17386-5-git-send-email-suzuki.poulose@arm.com>

On ARMv8 support for AArch32 state is optional. Hence it is
not safe to check the AArch32 ID registers for sanity, which
could lead to false warnings. This patch makes sure that the
AArch32 state is implemented before we keep track of the 32bit
ID registers.

As per ARM ARM (D.1.21.2 - Support for Exception Levels and
Execution States, DDI0487A.h), checking the support for AArch32
at EL0 is good enough to check the support for AArch32 (i.e,
AArch32 at EL1 => AArch32 at EL0, but not vice versa).

Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/kernel/cpufeature.c |   86 ++++++++++++++++++++++------------------
 arch/arm64/kernel/cpuinfo.c    |   37 +++++++++--------
 2 files changed, 67 insertions(+), 56 deletions(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index b88cbef..853e575 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -423,22 +423,26 @@ void __init init_cpu_features(struct cpuinfo_arm64 *info)
 	init_cpu_ftr_reg(SYS_ID_AA64MMFR1_EL1, info->reg_id_aa64mmfr1);
 	init_cpu_ftr_reg(SYS_ID_AA64PFR0_EL1, info->reg_id_aa64pfr0);
 	init_cpu_ftr_reg(SYS_ID_AA64PFR1_EL1, info->reg_id_aa64pfr1);
-	init_cpu_ftr_reg(SYS_ID_DFR0_EL1, info->reg_id_dfr0);
-	init_cpu_ftr_reg(SYS_ID_ISAR0_EL1, info->reg_id_isar0);
-	init_cpu_ftr_reg(SYS_ID_ISAR1_EL1, info->reg_id_isar1);
-	init_cpu_ftr_reg(SYS_ID_ISAR2_EL1, info->reg_id_isar2);
-	init_cpu_ftr_reg(SYS_ID_ISAR3_EL1, info->reg_id_isar3);
-	init_cpu_ftr_reg(SYS_ID_ISAR4_EL1, info->reg_id_isar4);
-	init_cpu_ftr_reg(SYS_ID_ISAR5_EL1, info->reg_id_isar5);
-	init_cpu_ftr_reg(SYS_ID_MMFR0_EL1, info->reg_id_mmfr0);
-	init_cpu_ftr_reg(SYS_ID_MMFR1_EL1, info->reg_id_mmfr1);
-	init_cpu_ftr_reg(SYS_ID_MMFR2_EL1, info->reg_id_mmfr2);
-	init_cpu_ftr_reg(SYS_ID_MMFR3_EL1, info->reg_id_mmfr3);
-	init_cpu_ftr_reg(SYS_ID_PFR0_EL1, info->reg_id_pfr0);
-	init_cpu_ftr_reg(SYS_ID_PFR1_EL1, info->reg_id_pfr1);
-	init_cpu_ftr_reg(SYS_MVFR0_EL1, info->reg_mvfr0);
-	init_cpu_ftr_reg(SYS_MVFR1_EL1, info->reg_mvfr1);
-	init_cpu_ftr_reg(SYS_MVFR2_EL1, info->reg_mvfr2);
+
+	if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0)) {
+		init_cpu_ftr_reg(SYS_ID_DFR0_EL1, info->reg_id_dfr0);
+		init_cpu_ftr_reg(SYS_ID_ISAR0_EL1, info->reg_id_isar0);
+		init_cpu_ftr_reg(SYS_ID_ISAR1_EL1, info->reg_id_isar1);
+		init_cpu_ftr_reg(SYS_ID_ISAR2_EL1, info->reg_id_isar2);
+		init_cpu_ftr_reg(SYS_ID_ISAR3_EL1, info->reg_id_isar3);
+		init_cpu_ftr_reg(SYS_ID_ISAR4_EL1, info->reg_id_isar4);
+		init_cpu_ftr_reg(SYS_ID_ISAR5_EL1, info->reg_id_isar5);
+		init_cpu_ftr_reg(SYS_ID_MMFR0_EL1, info->reg_id_mmfr0);
+		init_cpu_ftr_reg(SYS_ID_MMFR1_EL1, info->reg_id_mmfr1);
+		init_cpu_ftr_reg(SYS_ID_MMFR2_EL1, info->reg_id_mmfr2);
+		init_cpu_ftr_reg(SYS_ID_MMFR3_EL1, info->reg_id_mmfr3);
+		init_cpu_ftr_reg(SYS_ID_PFR0_EL1, info->reg_id_pfr0);
+		init_cpu_ftr_reg(SYS_ID_PFR1_EL1, info->reg_id_pfr1);
+		init_cpu_ftr_reg(SYS_MVFR0_EL1, info->reg_mvfr0);
+		init_cpu_ftr_reg(SYS_MVFR1_EL1, info->reg_mvfr1);
+		init_cpu_ftr_reg(SYS_MVFR2_EL1, info->reg_mvfr2);
+	}
+
 }
 
 static void update_cpu_ftr_reg(struct arm64_ftr_reg *reg, u64 new)
@@ -541,47 +545,51 @@ void update_cpu_features(int cpu,
 				      info->reg_id_aa64pfr1, boot->reg_id_aa64pfr1);
 
 	/*
-	 * If we have AArch32, we care about 32-bit features for compat. These
-	 * registers should be RES0 otherwise.
+	 * If we have AArch32, we care about 32-bit features for compat.
+	 * If the system doesn't support AArch32, don't update them.
 	 */
-	taint |= check_update_ftr_reg(SYS_ID_DFR0_EL1, cpu,
+	if (id_aa64pfr0_32bit_el0(read_system_reg(SYS_ID_AA64PFR0_EL1)) &&
+		id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0)) {
+
+		taint |= check_update_ftr_reg(SYS_ID_DFR0_EL1, cpu,
 					info->reg_id_dfr0, boot->reg_id_dfr0);
-	taint |= check_update_ftr_reg(SYS_ID_ISAR0_EL1, cpu,
+		taint |= check_update_ftr_reg(SYS_ID_ISAR0_EL1, cpu,
 					info->reg_id_isar0, boot->reg_id_isar0);
-	taint |= check_update_ftr_reg(SYS_ID_ISAR1_EL1, cpu,
+		taint |= check_update_ftr_reg(SYS_ID_ISAR1_EL1, cpu,
 					info->reg_id_isar1, boot->reg_id_isar1);
-	taint |= check_update_ftr_reg(SYS_ID_ISAR2_EL1, cpu,
+		taint |= check_update_ftr_reg(SYS_ID_ISAR2_EL1, cpu,
 					info->reg_id_isar2, boot->reg_id_isar2);
-	taint |= check_update_ftr_reg(SYS_ID_ISAR3_EL1, cpu,
+		taint |= check_update_ftr_reg(SYS_ID_ISAR3_EL1, cpu,
 					info->reg_id_isar3, boot->reg_id_isar3);
-	taint |= check_update_ftr_reg(SYS_ID_ISAR4_EL1, cpu,
+		taint |= check_update_ftr_reg(SYS_ID_ISAR4_EL1, cpu,
 					info->reg_id_isar4, boot->reg_id_isar4);
-	taint |= check_update_ftr_reg(SYS_ID_ISAR5_EL1, cpu,
+		taint |= check_update_ftr_reg(SYS_ID_ISAR5_EL1, cpu,
 					info->reg_id_isar5, boot->reg_id_isar5);
 
-	/*
-	 * Regardless of the value of the AuxReg field, the AIFSR, ADFSR, and
-	 * ACTLR formats could differ across CPUs and therefore would have to
-	 * be trapped for virtualization anyway.
-	 */
-	taint |= check_update_ftr_reg(SYS_ID_MMFR0_EL1, cpu,
+		/*
+		 * Regardless of the value of the AuxReg field, the AIFSR, ADFSR, and
+		 * ACTLR formats could differ across CPUs and therefore would have to
+		 * be trapped for virtualization anyway.
+		 */
+		taint |= check_update_ftr_reg(SYS_ID_MMFR0_EL1, cpu,
 					info->reg_id_mmfr0, boot->reg_id_mmfr0);
-	taint |= check_update_ftr_reg(SYS_ID_MMFR1_EL1, cpu,
+		taint |= check_update_ftr_reg(SYS_ID_MMFR1_EL1, cpu,
 					info->reg_id_mmfr1, boot->reg_id_mmfr1);
-	taint |= check_update_ftr_reg(SYS_ID_MMFR2_EL1, cpu,
+		taint |= check_update_ftr_reg(SYS_ID_MMFR2_EL1, cpu,
 					info->reg_id_mmfr2, boot->reg_id_mmfr2);
-	taint |= check_update_ftr_reg(SYS_ID_MMFR3_EL1, cpu,
+		taint |= check_update_ftr_reg(SYS_ID_MMFR3_EL1, cpu,
 					info->reg_id_mmfr3, boot->reg_id_mmfr3);
-	taint |= check_update_ftr_reg(SYS_ID_PFR0_EL1, cpu,
+		taint |= check_update_ftr_reg(SYS_ID_PFR0_EL1, cpu,
 					info->reg_id_pfr0, boot->reg_id_pfr0);
-	taint |= check_update_ftr_reg(SYS_ID_PFR1_EL1, cpu,
+		taint |= check_update_ftr_reg(SYS_ID_PFR1_EL1, cpu,
 					info->reg_id_pfr1, boot->reg_id_pfr1);
-	taint |= check_update_ftr_reg(SYS_MVFR0_EL1, cpu,
+		taint |= check_update_ftr_reg(SYS_MVFR0_EL1, cpu,
 					info->reg_mvfr0, boot->reg_mvfr0);
-	taint |= check_update_ftr_reg(SYS_MVFR1_EL1, cpu,
+		taint |= check_update_ftr_reg(SYS_MVFR1_EL1, cpu,
 					info->reg_mvfr1, boot->reg_mvfr1);
-	taint |= check_update_ftr_reg(SYS_MVFR2_EL1, cpu,
+		taint |= check_update_ftr_reg(SYS_MVFR2_EL1, cpu,
 					info->reg_mvfr2, boot->reg_mvfr2);
+	}
 
 	/*
 	 * Mismatched CPU features are a recipe for disaster. Don't even
diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
index 212ae63..8cc2a86 100644
--- a/arch/arm64/kernel/cpuinfo.c
+++ b/arch/arm64/kernel/cpuinfo.c
@@ -213,23 +213,26 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
 	info->reg_id_aa64pfr0 = read_cpuid(ID_AA64PFR0_EL1);
 	info->reg_id_aa64pfr1 = read_cpuid(ID_AA64PFR1_EL1);
 
-	info->reg_id_dfr0 = read_cpuid(ID_DFR0_EL1);
-	info->reg_id_isar0 = read_cpuid(ID_ISAR0_EL1);
-	info->reg_id_isar1 = read_cpuid(ID_ISAR1_EL1);
-	info->reg_id_isar2 = read_cpuid(ID_ISAR2_EL1);
-	info->reg_id_isar3 = read_cpuid(ID_ISAR3_EL1);
-	info->reg_id_isar4 = read_cpuid(ID_ISAR4_EL1);
-	info->reg_id_isar5 = read_cpuid(ID_ISAR5_EL1);
-	info->reg_id_mmfr0 = read_cpuid(ID_MMFR0_EL1);
-	info->reg_id_mmfr1 = read_cpuid(ID_MMFR1_EL1);
-	info->reg_id_mmfr2 = read_cpuid(ID_MMFR2_EL1);
-	info->reg_id_mmfr3 = read_cpuid(ID_MMFR3_EL1);
-	info->reg_id_pfr0 = read_cpuid(ID_PFR0_EL1);
-	info->reg_id_pfr1 = read_cpuid(ID_PFR1_EL1);
-
-	info->reg_mvfr0 = read_cpuid(MVFR0_EL1);
-	info->reg_mvfr1 = read_cpuid(MVFR1_EL1);
-	info->reg_mvfr2 = read_cpuid(MVFR2_EL1);
+	/* Update the 32bit ID registers only if AArch32 is implemented */
+	if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0)) {
+		info->reg_id_dfr0 = read_cpuid(ID_DFR0_EL1);
+		info->reg_id_isar0 = read_cpuid(ID_ISAR0_EL1);
+		info->reg_id_isar1 = read_cpuid(ID_ISAR1_EL1);
+		info->reg_id_isar2 = read_cpuid(ID_ISAR2_EL1);
+		info->reg_id_isar3 = read_cpuid(ID_ISAR3_EL1);
+		info->reg_id_isar4 = read_cpuid(ID_ISAR4_EL1);
+		info->reg_id_isar5 = read_cpuid(ID_ISAR5_EL1);
+		info->reg_id_mmfr0 = read_cpuid(ID_MMFR0_EL1);
+		info->reg_id_mmfr1 = read_cpuid(ID_MMFR1_EL1);
+		info->reg_id_mmfr2 = read_cpuid(ID_MMFR2_EL1);
+		info->reg_id_mmfr3 = read_cpuid(ID_MMFR3_EL1);
+		info->reg_id_pfr0 = read_cpuid(ID_PFR0_EL1);
+		info->reg_id_pfr1 = read_cpuid(ID_PFR1_EL1);
+
+		info->reg_mvfr0 = read_cpuid(MVFR0_EL1);
+		info->reg_mvfr1 = read_cpuid(MVFR1_EL1);
+		info->reg_mvfr2 = read_cpuid(MVFR2_EL1);
+	}
 
 	cpuinfo_detect_icache_policy(info);
 
-- 
1.7.9.5



From suzuki.poulose at arm.com  Thu Feb 25 01:52:47 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Thu, 25 Feb 2016 09:52:47 +0000
Subject: [PATCH v2 7/8] arm64: compat: Check for AArch32 state
In-Reply-To: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
References: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456393968-17386-8-git-send-email-suzuki.poulose@arm.com>

From: Yury Norov <ynorov at caviumnetworks.com>

Make sure we have AArch32 state available for running COMPAT
binaries and also for switching the personality to PER_LINUX32.

Signed-off-by: Yury Norov <ynorov at caviumnetworks.com>
[ Added checks for ELF HWCAP, Use cap bit in cap_hwcaps ]
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm64/include/asm/elf.h   |    3 ++-
 arch/arm64/kernel/cpufeature.c |    7 +++++--
 arch/arm64/kernel/sys.c        |    4 ++++
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index faad6df..a1946f2 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -173,7 +173,8 @@ typedef compat_elf_greg_t		compat_elf_gregset_t[COMPAT_ELF_NGREG];
 
 /* AArch32 EABI. */
 #define EF_ARM_EABI_MASK		0xff000000
-#define compat_elf_check_arch(x)	(((x)->e_machine == EM_ARM) && \
+#define compat_elf_check_arch(x)	(system_supports_32bit_el0() && \
+					 ((x)->e_machine == EM_ARM) && \
 					 ((x)->e_flags & EF_ARM_EABI_MASK))
 
 #define compat_start_thread		compat_start_thread
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 8f6b674..1ae545e 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -929,7 +929,8 @@ void verify_local_cpu_capabilities(void)
 
 	verify_local_cpu_features(arm64_features);
 	verify_local_elf_hwcaps(arm64_elf_hwcaps);
-	verify_local_elf_hwcaps(compat_elf_hwcaps);
+	if (system_supports_32bit_el0())
+		verify_local_elf_hwcaps(compat_elf_hwcaps);
 }
 
 static void __init setup_feature_capabilities(void)
@@ -946,7 +947,9 @@ void __init setup_cpu_features(void)
 	/* Set the CPU feature capabilies */
 	setup_feature_capabilities();
 	setup_elf_hwcaps(arm64_elf_hwcaps);
-	setup_elf_hwcaps(compat_elf_hwcaps);
+
+	if (system_supports_32bit_el0())
+		setup_elf_hwcaps(compat_elf_hwcaps);
 
 	/* Advertise that we have computed the system capabilities */
 	set_sys_caps_initialised();
diff --git a/arch/arm64/kernel/sys.c b/arch/arm64/kernel/sys.c
index 817d860..26fe8ea 100644
--- a/arch/arm64/kernel/sys.c
+++ b/arch/arm64/kernel/sys.c
@@ -25,6 +25,7 @@
 #include <linux/sched.h>
 #include <linux/slab.h>
 #include <linux/syscalls.h>
+#include <asm/cpufeature.h>
 
 asmlinkage long sys_mmap(unsigned long addr, unsigned long len,
 			 unsigned long prot, unsigned long flags,
@@ -38,6 +39,9 @@ asmlinkage long sys_mmap(unsigned long addr, unsigned long len,
 
 SYSCALL_DEFINE1(arm64_personality, unsigned int, personality)
 {
+	if (personality(personality) == PER_LINUX32 &&
+		!system_supports_32bit_el0())
+		return -EINVAL;
 	return sys_personality(personality);
 }
 
-- 
1.7.9.5



From suzuki.poulose at arm.com  Thu Feb 25 01:52:48 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Thu, 25 Feb 2016 09:52:48 +0000
Subject: [PATCH v2 8/8] arm64: kvm: Check support for AArch32 for 32bit guests
In-Reply-To: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
References: <1456393968-17386-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1456393968-17386-9-git-send-email-suzuki.poulose@arm.com>

Add a check to make sure the system supports AArch32 state
before initialising a 32bit guest.

Cc: Christoffer Dall <christoffer.dall at linaro.org>
Cc: Marc Zyngier <marc.zyngier at arm.com>
Cc: kvmarm at lists.cs.columbia.edu
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>

---

I really wanted to pass kvm_vcpu down to the helpers. But then, I can't
define the arch specific helper in asm/kvm_host.h due to lack of kvm_vcpu's
definition yet:

 In file included from include/linux/kvm_host.h:35:0,
                  from arch/arm64/kernel/asm-offsets.c:24:
 ./arch/arm64/include/asm/kvm_host.h: In function ?kvm_arch_vcpu_validate_features?:
 ./arch/arm64/include/asm/kvm_host.h:344:48: error: dereferencing pointer to incomplete type
   return  !test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features) ||
---
 arch/arm/include/asm/kvm_host.h   |    5 +++++
 arch/arm/kvm/arm.c                |    3 +++
 arch/arm64/include/asm/kvm_host.h |    8 ++++++++
 3 files changed, 16 insertions(+)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index f9f2779..945c23a 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -238,6 +238,11 @@ static inline void kvm_arch_sync_events(struct kvm *kvm) {}
 static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
 static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
 
+static inline bool kvm_arch_vcpu_validate_features(struct kvm_vcpu_arch *arch_vcpu)
+{
+	return true;
+}
+
 static inline void kvm_arm_init_debug(void) {}
 static inline void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) {}
 static inline void kvm_arm_clear_debug(struct kvm_vcpu *vcpu) {}
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dda1959..fc4ea37 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -787,6 +787,9 @@ static int kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
 			set_bit(i, vcpu->arch.features);
 	}
 
+	if (!kvm_arch_vcpu_validate_features(&vcpu->arch))
+		return -EINVAL;
+
 	vcpu->arch.target = phys_target;
 
 	/* Now we know what it is, we can reset it. */
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 689d4c9..9d60a6c 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -24,6 +24,8 @@
 
 #include <linux/types.h>
 #include <linux/kvm_types.h>
+#include <asm/cpufeature.h>
+#include <asm/kvm_arm.h>
 #include <asm/kvm.h>
 #include <asm/kvm_mmio.h>
 
@@ -338,6 +340,12 @@ static inline void kvm_arch_sync_events(struct kvm *kvm) {}
 static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu) {}
 static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
 
+static inline bool kvm_arch_vcpu_validate_features(struct kvm_vcpu_arch *arch_vcpu)
+{
+	return  !test_bit(KVM_ARM_VCPU_EL1_32BIT, arch_vcpu->features) ||
+		system_supports_32bit_el0();
+}
+
 void kvm_arm_init_debug(void);
 void kvm_arm_setup_debug(struct kvm_vcpu *vcpu);
 void kvm_arm_clear_debug(struct kvm_vcpu *vcpu);
-- 
1.7.9.5



From nicolas.ferre at atmel.com  Thu Feb 25 02:01:07 2016
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 25 Feb 2016 11:01:07 +0100
Subject: [PATCH v2] tty/serial: at91: restore dynamic driver binding
In-Reply-To: <1456392221-30401-1-git-send-email-romain.izard.pro@gmail.com>
References: <1456392221-30401-1-git-send-email-romain.izard.pro@gmail.com>
Message-ID: <56CED0E3.5070308@atmel.com>

Le 25/02/2016 10:23, Romain Izard a ?crit :
> In commit c39dfebc7798956fd2140ae6321786ff35da30c3, the modular support
> code for atmel_serial was removed, as the driver cannot be built as a
> module. Because no use case was proposed, the dynamic driver binding
> support was removed as well.
> 
> The atmel_serial driver can manage up to 7 serial controllers, which are
> multiplexed with other functions. For example, in the Atmel SAMA5D2, the
> Flexcom controllers can work as USART, SPI or I2C controllers, and on
> all Atmel devices serial lines can be reconfigured as GPIOs.
> 
> My use case uses GPIOs to transfer a firmware update using a custom
> protocol on the lines used as a serial port during the normal life of
> the device. If it is not possible to unbind the atmel_serial driver, the
> GPIO lines remain reserved and prevent this case from working.
> 
> This patch reinstates the atmel_serial_remove function, and fixes it as
> it failed to clear the "clk" field on removal, triggering an oops when
> a device was bound again after being unbound.
> 
> Signed-off-by: Romain Izard <romain.izard.pro at gmail.com>

Even if you didn't follow my advice for not including unneeded changes
in of the last patch chunk, there's no use delaying the patch just for
this. So, here is my:

Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>

Thanks, bye.

PS: another advice: please include linux-arm-kernel as well in your CC
list for work on the AT91 platforms: most of the reviewers are there.

> ---
> Changelog:
> v2: Add the rationale for keeping the "remove" function as a comment.
> 
> 
>  drivers/tty/serial/atmel_serial.c | 39 ++++++++++++++++++++++++++++++++++++---
>  1 file changed, 36 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 1c0884d8ef32..b1f3a5b26830 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -2759,14 +2759,47 @@ err:
>  	return ret;
>  }
>  
> +/*
> + * Even if the driver is not modular, it makes sense to be able to
> + * unbind a device: there can be many bound devices, and there are
> + * situations where dynamic binding and unbinding can be useful.
> + *
> + * For example, a connected device can require a specific firmware update
> + * protocol that needs bitbanging on IO lines, but use the regular serial
> + * port in the normal case.
> + */
> +static int atmel_serial_remove(struct platform_device *pdev)
> +{
> +	struct uart_port *port = platform_get_drvdata(pdev);
> +	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> +	int ret = 0;
> +
> +	tasklet_kill(&atmel_port->tasklet);
> +
> +	device_init_wakeup(&pdev->dev, 0);
> +
> +	ret = uart_remove_one_port(&atmel_uart, port);
> +
> +	kfree(atmel_port->rx_ring.buf);
> +
> +	/* "port" is allocated statically, so we shouldn't free it */
> +
> +	clear_bit(port->line, atmel_ports_in_use);
> +
> +	clk_put(atmel_port->clk);
> +	atmel_port->clk = NULL;
> +
> +	return ret;
> +}
> +
>  static struct platform_driver atmel_serial_driver = {
>  	.probe		= atmel_serial_probe,
> +	.remove		= atmel_serial_remove,
>  	.suspend	= atmel_serial_suspend,
>  	.resume		= atmel_serial_resume,
>  	.driver		= {
> -		.name			= "atmel_usart",
> -		.of_match_table		= of_match_ptr(atmel_serial_dt_ids),
> -		.suppress_bind_attrs    = true,
> +		.name	= "atmel_usart",
> +		.of_match_table	= of_match_ptr(atmel_serial_dt_ids),
>  	},
>  };
>  
> 


-- 
Nicolas Ferre


From andre.przywara at arm.com  Thu Feb 25 02:04:59 2016
From: andre.przywara at arm.com (Andre Przywara)
Date: Thu, 25 Feb 2016 10:04:59 +0000
Subject: [PATCH v3 00/10] arm64: Introduce Allwinner A64 and Pine64 support
In-Reply-To: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
References: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
Message-ID: <56CED1CB.8040807@arm.com>

Hi Maxime,

can you give me a quick assessment on how we can progress from here?

Is it already too late for at least some of the patches to go into 4.6?
If not, can you at least merge the Kconfig patch (3/10) and the pinctrl
driver (if that goes via your tree at all)? Do you need more reviews or
Acks?
Of the prerequisite patches for a clean arm64 compile I see that the
sunxi-rsb is in your for-next branch, but not in -next itself. Also I
got a message about the sunxi-ss Kconfig patch to be applied, but cannot
find it in -next either. All the other patches have made it into -next
as of today.

Also are you happy with the PLL6 reuse patch I sent on Monday and can I
base the A64's PLL7 clock on that?
Or do you prefer another approach here? I am happy to discuss this on
the list then.

Cheers,
Andre.

On 22/02/16 18:20, Andre Przywara wrote:
> Hi,
> 
> another update of the Allwinner A64 / Pine64 support series.
> I added a solution for the PLL6 reuse issue (the same patch I posted
> yesterday). Also I addressed the comments I got from Rob and Chen-Yu.
> For a changelog see below.
> 
> This series provides initial support for the Allwinner A64 SoC,
> which is based on four ARM Cortex-A53 cores implementing the ARMv8
> 64-bit architecture.
> On top of this there is also initial support for the Pine64 board,
> for which you can find more information and links in the linux-sunxi
> Wiki [1].
> The resulting kernel boots fine on my development samples I have
> here, though the actual boot process is a bit involved at the moment.
> You can find more information and a ready-to-flash image here [2].
> 
> Patch 1/10 removes the hardcoded "pll6" name for the PLL6 clock, so
> it can be reused for the A64's PLL7, patch 2/10 uses that facility
> for the Allwinner H3 SoC's PLL8.
> Patch 3/10 enables the Allwinner/sunxi platform for the arm64
> architecture, so one can select the required drivers during
> configuration.
> Patch 4/10 adds the pinctrl driver, which has been on the list before.
> Patch 5 and 6 add a new generic driver for the bus clock gates which
> relies on DT for providing the parent relationship. That makes adding
> new SoCs much easier, since there should be no more kernel code
> changes necessary.
> Patch 7-9 add the new vendor name and the device tree files, the former
> for the SoC itself, the latter for the Pine64 boards.
> The final patch 10 updates defconfig, so that the generic arm64 kernel
> supports the basic SoC drivers out of the box.
> 
> In the moment we support the basic peripherals like GIC, timer, clocks,
> GPIOs, UARTs and (since v2) I2C.
> The MMC IP block has changed a bit compared to previous SoCs, so the
> existing driver is not 100% compatible. However the default delays seem
> to work fine for the SD cards, so I included all the necessary bits in
> here, since working MMC makes this series indefinitely more usable.
> We can fix both the MMC driver and the DT in a compatible way later.
> 
> Please have a look and comment on the patches. We might want to split
> the series if some patches seem too controversial for being merged
> soonish, please let me know if this is the case and I am happy to
> rearrange the series.
> 
> The patches are based on mripard/sunxi/for-next (since linux-next is
> a bit messy atm). A working repo can be found over here[3].
> 
> Cheers,
> Andre
> 
> Changelog v1 .. v2:
> - Change the naming of DT nodes, identifiers and file names to include
>   the wonderful Allwinner architecture prefix everywhere. You asked
>   for it, you got it, enjoy!
> - Drop SUNXI_MMC to be selected automatically, instead put it in the
>   defconfig.
> - Add a binding documentation for the new multi-bus-gates driver.
> - Add a defconfig update patch.
> - Lots of changes in the DTs, see the respective patches for details.
> 
> Changelog v2 .. v3:
> - Reordered sunxi section in ARM64 platform config.
> - Add PLL6 reuse patch and rework the .dtsi to use the existing binding.
> - Drop unneeded module boilerplate for the pinctrl driver.
> - Rename "owa" pin to "spdif".
> - Rename pll8 to pll7 in the DT.
> - Remove leading 0 in DT node address parts.
> - Added Acks from Rob.
> 
> [1] http://linux-sunxi.org/Pine64
> [2] https://github.com/apritzel/pine64
> [3] https://github.com/apritzel/linux/commits/a64-v3
> 
> Andre Przywara (10):
>   clk: sunxi: allow PLL6 clock to be reused
>   ARM: dts: sunxi: make PLL8 in the H3 a proper clock
>   arm64: Introduce Allwinner SoC config option
>   drivers: pinctrl: add driver for Allwinner A64 SoC
>   DT: clk: sunxi: add binding doc for the multi-bus-gates clock
>   clk: sunxi: add generic multi-parent bus clock gates driver
>   arm64: dts: add Allwinner A64 SoC .dtsi
>   of: add vendor prefix for Pine64
>   arm64: dts: add Pine64 support
>   arm64: add defconfig options for Allwinner SoCs
> 
>  Documentation/devicetree/bindings/arm/sunxi.txt    |   1 +
>  Documentation/devicetree/bindings/clock/sunxi.txt  |   7 +
>  .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt   |   1 +
>  .../devicetree/bindings/vendor-prefixes.txt        |   1 +
>  arch/arm/boot/dts/sun8i-h3.dtsi                    |  18 +-
>  arch/arm64/Kconfig.platforms                       |   6 +
>  arch/arm64/boot/dts/Makefile                       |   1 +
>  arch/arm64/boot/dts/allwinner/Makefile             |   5 +
>  .../dts/allwinner/sun50i-a64-pine64-common.dtsi    |  80 +++
>  .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  |  59 ++
>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |  58 ++
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      | 624 +++++++++++++++++++++
>  arch/arm64/configs/defconfig                       |   7 +
>  drivers/clk/sunxi/Makefile                         |   1 +
>  drivers/clk/sunxi/clk-factors.c                    |   3 +-
>  drivers/clk/sunxi/clk-factors.h                    |   1 +
>  drivers/clk/sunxi/clk-multi-gates.c                | 105 ++++
>  drivers/clk/sunxi/clk-sunxi.c                      |   4 +-
>  drivers/pinctrl/sunxi/Kconfig                      |   4 +
>  drivers/pinctrl/sunxi/Makefile                     |   1 +
>  drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c         | 602 ++++++++++++++++++++
>  21 files changed, 1577 insertions(+), 12 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-common.dtsi
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>  create mode 100644 drivers/clk/sunxi/clk-multi-gates.c
>  create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c
> 


From tim at krieglstein.org  Thu Feb 25 02:05:05 2016
From: tim at krieglstein.org (Tim Sander)
Date: Thu, 25 Feb 2016 11:05:05 +0100
Subject: [PATCH v2] dts: add specific compatible type for Terasic DE0-NANO-SoC
 Board
In-Reply-To: <alpine.DEB.2.02.1602241048100.3815@linux-builds1>
References: <8416439.76b9YNhpgR@dabox>
 <alpine.DEB.2.02.1602241048100.3815@linux-builds1>
Message-ID: <2186741.ZYdHdfu2ug@dabox>

From: Tim Sander <tim at krieglstein.org>

Add a more specific compatible string:"terasic,de0-nano-soc" for respective board.
Background: when checking for bootspec entries, some board specific fixups are
not apropriate for board of the same platform ("altr,socfpga-cyclone5").
The same aproach is taken with the EBV-Socrates board.

Signed-off-by: Tim Sander <tim at krieglstein.org>
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts     | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 72e2c5a..d1f7803 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -230,6 +230,7 @@ synology	Synology, Inc.
 tbs	TBS Technologies
 tcl	Toby Churchill Ltd.
 technologic	Technologic Systems
+terasic	Terasic Inc.
 thine	THine Electronics, Inc.
 ti	Texas Instruments
 tlm	Trusted Logic Mobility
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
index afea364..704aa9d 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
@@ -18,7 +18,7 @@
 
 / {
 	model = "Terasic DE-0(Atlas)";
-	compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+	compatible = "terasic,de0-nano-soc","altr,socfpga-cyclone5", "altr,socfpga";
 
 	chosen {
 		bootargs = "earlyprintk";
-- 
1.9.1


From antoine.tenart at free-electrons.com  Thu Feb 25 02:14:53 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Thu, 25 Feb 2016 11:14:53 +0100
Subject: [PATCH 3/7] arm64: defconfig: enable the Alpine family
In-Reply-To: <1456395297-6505-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1456395297-6505-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1456395297-6505-4-git-send-email-antoine.tenart@free-electrons.com>

Enable the Alpine SoC family in the arm64 defconfig.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 18ca9fb9e65f..10387947a164 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -31,6 +31,7 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_ARCH_ALPINE=y
 CONFIG_ARCH_BCM_IPROC=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_ARCH_EXYNOS7=y
-- 
2.7.1



From antoine.tenart at free-electrons.com  Thu Feb 25 02:14:50 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Thu, 25 Feb 2016 11:14:50 +0100
Subject: [PATCH 0/7] arm/arm64: Alpine patches for 4.6
Message-ID: <1456395297-6505-1-git-send-email-antoine.tenart@free-electrons.com>

Hi Arnd, Olof and Kevin,

Here are the Alpine patches for 4.6. As seen with Olof these patches are
sent to you as a series as there are only 7 of them. I'll get my gpg key
signed and setup a git tree somewhere for next time.

The first 3 patches introduce a basic arm64 Alpine support, by adding
the Alpine v2 EVP board. The last 4 patches add an MSIX node in both
Alpine v1 (arm) and Alpine v2 (arm64) dtsi and select the Alpine MSI
controller driver.

Thanks!

Antoine

Antoine Tenart (7):
  arm64: add Alpine SoC family
  arm64: dts: add the Alpine v2 EVP
  arm64: defconfig: enable the Alpine family
  arm64: dts: alpine: add the MSIX node in the Alpine v2 dtsi
  ARM: dts: alpine: add the MSIX node
  arm64: alpine: select the Alpine MSI controller driver
  ARM: alpine: select the Alpine MSI controller driver

 arch/arm/boot/dts/alpine.dtsi            |  10 ++
 arch/arm/mach-alpine/Kconfig             |   1 +
 arch/arm64/Kconfig.platforms             |   7 +
 arch/arm64/boot/dts/Makefile             |   1 +
 arch/arm64/boot/dts/al/Makefile          |   5 +
 arch/arm64/boot/dts/al/alpine-v2-evp.dts |  53 +++++++
 arch/arm64/boot/dts/al/alpine-v2.dtsi    | 236 +++++++++++++++++++++++++++++++
 arch/arm64/configs/defconfig             |   1 +
 8 files changed, 314 insertions(+)
 create mode 100644 arch/arm64/boot/dts/al/Makefile
 create mode 100644 arch/arm64/boot/dts/al/alpine-v2-evp.dts
 create mode 100644 arch/arm64/boot/dts/al/alpine-v2.dtsi

-- 
2.7.1



From antoine.tenart at free-electrons.com  Thu Feb 25 02:14:54 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Thu, 25 Feb 2016 11:14:54 +0100
Subject: [PATCH 4/7] arm64: dts: alpine: add the MSIX node in the Alpine v2
 dtsi
In-Reply-To: <1456395297-6505-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1456395297-6505-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1456395297-6505-5-git-send-email-antoine.tenart@free-electrons.com>

Following the addition of the Alpine MSIX controller driver, add the
corresponding node in the Alpine v2 device tree.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 arch/arm64/boot/dts/al/alpine-v2.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/al/alpine-v2.dtsi b/arch/arm64/boot/dts/al/alpine-v2.dtsi
index c021e077343b..5b7bef684256 100644
--- a/arch/arm64/boot/dts/al/alpine-v2.dtsi
+++ b/arch/arm64/boot/dts/al/alpine-v2.dtsi
@@ -139,6 +139,16 @@
 			/* 32 bit non prefetchable memory space */
 			ranges = <0x2000000 0x0 0xfe000000 0x0 0xfe000000 0x0 0x1000000>;
 			bus-range = <0x00 0x00>;
+			msi-parent = <&msix>;
+		};
+
+		msix: msix at fbe00000 {
+			compatible = "al,alpine-msix";
+			reg = <0x0 0xfbe00000 0x0 0x100000>;
+			interrupt-controller;
+			msi-controller;
+			al,msi-base-spi = <160>;
+			al,msi-num-spis = <160>;
 		};
 
 		io-fabric {
-- 
2.7.1



From antoine.tenart at free-electrons.com  Thu Feb 25 02:14:51 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Thu, 25 Feb 2016 11:14:51 +0100
Subject: [PATCH 1/7] arm64: add Alpine SoC family
In-Reply-To: <1456395297-6505-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1456395297-6505-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1456395297-6505-2-git-send-email-antoine.tenart@free-electrons.com>

This patch introduces ARCH_ALPINE to add the support of the Alpine SoC
family for the arm64 architecture.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm64/Kconfig.platforms | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f674bde..bfbefa3e0dbe 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -1,5 +1,11 @@
 menu "Platform selection"
 
+config ARCH_ALPINE
+	bool "Annapurna Labs Alpine platform"
+	help
+	  This enables support for the Annapurna Labs Alpine
+	  Soc family.
+
 config ARCH_BCM_IPROC
 	bool "Broadcom iProc SoC Family"
 	help
-- 
2.7.1



From antoine.tenart at free-electrons.com  Thu Feb 25 02:14:52 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Thu, 25 Feb 2016 11:14:52 +0100
Subject: [PATCH 2/7] arm64: dts: add the Alpine v2 EVP
In-Reply-To: <1456395297-6505-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1456395297-6505-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1456395297-6505-3-git-send-email-antoine.tenart@free-electrons.com>

This patch adds the initial support for the Alpine v2 EVP board from
Annapurna Labs (Amazon).

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Barak Wasserstrom <barak at annapurnalabs.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
Acked-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm64/boot/dts/Makefile             |   1 +
 arch/arm64/boot/dts/al/Makefile          |   5 +
 arch/arm64/boot/dts/al/alpine-v2-evp.dts |  53 ++++++++
 arch/arm64/boot/dts/al/alpine-v2.dtsi    | 226 +++++++++++++++++++++++++++++++
 4 files changed, 285 insertions(+)
 create mode 100644 arch/arm64/boot/dts/al/Makefile
 create mode 100644 arch/arm64/boot/dts/al/alpine-v2-evp.dts
 create mode 100644 arch/arm64/boot/dts/al/alpine-v2.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index f832b8a7453a..fd80617a9c6f 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,3 +1,4 @@
+dts-dirs += al
 dts-dirs += altera
 dts-dirs += amd
 dts-dirs += apm
diff --git a/arch/arm64/boot/dts/al/Makefile b/arch/arm64/boot/dts/al/Makefile
new file mode 100644
index 000000000000..8a6cde4f9b23
--- /dev/null
+++ b/arch/arm64/boot/dts/al/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_ALPINE)	+= alpine-v2-evp.dtb
+
+always		:= $(dtb-y)
+subdir-y	:= $(dts-dirs)
+clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/al/alpine-v2-evp.dts b/arch/arm64/boot/dts/al/alpine-v2-evp.dts
new file mode 100644
index 000000000000..a079d7b3063e
--- /dev/null
+++ b/arch/arm64/boot/dts/al/alpine-v2-evp.dts
@@ -0,0 +1,53 @@
+/*
+ * Copyright 2016 Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ *
+ * Antoine Tenart <antoine.tenart at free-electrons.com>
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * BSD license below:
+ *
+ *     Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *      - Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *
+ *      - Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include "alpine-v2.dtsi"
+
+/ {
+	model = "Annapurna Labs Alpine v2 EVP";
+	compatible = "al,alpine-v2-evp", "al,alpine-v2";
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+};
+
+&uart0 { status = "okay"; };
diff --git a/arch/arm64/boot/dts/al/alpine-v2.dtsi b/arch/arm64/boot/dts/al/alpine-v2.dtsi
new file mode 100644
index 000000000000..c021e077343b
--- /dev/null
+++ b/arch/arm64/boot/dts/al/alpine-v2.dtsi
@@ -0,0 +1,226 @@
+/*
+ * Copyright 2016 Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ *
+ * Antoine Tenart <antoine.tenart at free-electrons.com>
+ *
+ * This software is available to you under a choice of one of two
+ * licenses.  You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * BSD license below:
+ *
+ *     Redistribution and use in source and binary forms, with or
+ *     without modification, are permitted provided that the following
+ *     conditions are met:
+ *
+ *      - Redistributions of source code must retain the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer.
+ *
+ *      - Redistributions in binary form must reproduce the above
+ *        copyright notice, this list of conditions and the following
+ *        disclaimer in the documentation and/or other materials
+ *        provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	model = "Annapurna Labs Alpine v2";
+	compatible = "al,alpine-v2";
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			compatible = "arm,cortex-a57", "arm,armv8";
+			device_type = "cpu";
+			reg = <0x0 0x0>;
+			enable-method = "psci";
+		};
+
+		cpu at 1 {
+			compatible = "arm,cortex-a57", "arm,armv8";
+			device_type = "cpu";
+			reg = <0x0 0x1>;
+			enable-method = "psci";
+		};
+
+		cpu at 2 {
+			compatible = "arm,cortex-a57", "arm,armv8";
+			device_type = "cpu";
+			reg = <0x0 0x2>;
+			enable-method = "psci";
+		};
+
+		cpu at 3 {
+			compatible = "arm,cortex-a57", "arm,armv8";
+			device_type = "cpu";
+			reg = <0x0 0x3>;
+			enable-method = "psci";
+		};
+	};
+
+	psci {
+		compatible = "arm,psci-0.2", "arm,psci";
+		method = "smc";
+		cpu_suspend = <0x84000001>;
+		cpu_off = <0x84000002>;
+		cpu_on = <0x84000003>;
+	};
+
+	sbclk: sbclk {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <1000000>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+
+		interrupt-parent = <&gic>;
+		ranges;
+
+		timer {
+			compatible = "arm,armv8-timer";
+			interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+				     <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+				     <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+				     <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+		};
+
+		pmu {
+			compatible = "arm,armv8-pmuv3";
+			interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		gic: gic at f0100000 {
+			compatible = "arm,gic-v3";
+			reg = <0x0 0xf0200000 0x0 0x10000>,	/* GIC Dist */
+			      <0x0 0xf0280000 0x0 0x200000>,	/* GICR */
+			      <0x0 0xf0100000 0x0 0x2000>,	/* GICC */
+			      <0x0 0xf0110000 0x0 0x2000>,	/* GICV */
+			      <0x0 0xf0120000 0x0 0x2000>;	/* GICH */
+			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+		};
+
+		pci at fbc00000 {
+			compatible = "pci-host-ecam-generic";
+			device_type = "pci";
+			#size-cells = <2>;
+			#address-cells = <3>;
+			#interrupt-cells = <1>;
+			reg = <0x0 0xfbc00000 0x0 0x100000>;
+			interrupt-map-mask = <0xf800 0 0 7>;
+			/* add legacy interrupts for SATA only */
+			interrupt-map = <0x4000 0 0 1 &gic 0 53 4>,
+					<0x4800 0 0 1 &gic 0 54 4>;
+			/* 32 bit non prefetchable memory space */
+			ranges = <0x2000000 0x0 0xfe000000 0x0 0xfe000000 0x0 0x1000000>;
+			bus-range = <0x00 0x00>;
+		};
+
+		io-fabric {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0x0 0x0 0xfc000000 0x2000000>;
+
+			uart0: serial at 1883000 {
+				compatible = "ns16550a";
+				device_type = "serial";
+				reg = <0x1883000 0x1000>;
+				interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+				clock-frequency = <500000000>;
+				reg-shift = <2>;
+				reg-io-width = <4>;
+				status = "disabled";
+			};
+
+			uart1: serial at 1884000 {
+				compatible = "ns16550a";
+				device_type = "serial";
+				reg = <0x1884000 0x1000>;
+				interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+				clock-frequency = <500000000>;
+				reg-shift = <2>;
+				reg-io-width = <4>;
+				status = "disabled";
+			};
+
+			uart2: serial at 1885000 {
+				compatible = "ns16550a";
+				device_type = "serial";
+				reg = <0x1885000 0x1000>;
+				interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
+				clock-frequency = <500000000>;
+				reg-shift = <2>;
+				reg-io-width = <4>;
+				status = "disabled";
+			};
+
+			uart3: serial at 1886000 {
+				compatible = "ns16550a";
+				device_type = "serial";
+				reg = <0x1886000 0x1000>;
+				interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+				clock-frequency = <500000000>;
+				reg-shift = <2>;
+				reg-io-width = <4>;
+				status = "disabled";
+			};
+
+			timer0: timer at 1890000 {
+				compatible = "arm,sp804", "arm,primecell";
+				reg = <0x1890000 0x1000>;
+				interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&sbclk>;
+			};
+
+			timer1: timer at 1891000 {
+				compatible = "arm,sp804", "arm,primecell";
+				reg = <0x1891000 0x1000>;
+				interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&sbclk>;
+				status = "disabled";
+			};
+
+			timer2: timer at 1892000 {
+				compatible = "arm,sp804", "arm,primecell";
+				reg = <0x1892000 0x1000>;
+				interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&sbclk>;
+				status = "disabled";
+			};
+
+			timer3: timer at 1893000 {
+				compatible = "arm,sp804", "arm,primecell";
+				reg = <0x1893000 0x1000>;
+				interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&sbclk>;
+				status = "disabled";
+			};
+		};
+	};
+};
-- 
2.7.1



From antoine.tenart at free-electrons.com  Thu Feb 25 02:14:55 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Thu, 25 Feb 2016 11:14:55 +0100
Subject: [PATCH 5/7] ARM: dts: alpine: add the MSIX node
In-Reply-To: <1456395297-6505-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1456395297-6505-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1456395297-6505-6-git-send-email-antoine.tenart@free-electrons.com>

With the newly available MSIX driver for Alpine, add the corresponding
node in the Alpine device tree.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
---
 arch/arm/boot/dts/alpine.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/alpine.dtsi b/arch/arm/boot/dts/alpine.dtsi
index 9af2d60e9a7f..db8752fc480e 100644
--- a/arch/arm/boot/dts/alpine.dtsi
+++ b/arch/arm/boot/dts/alpine.dtsi
@@ -155,6 +155,16 @@
 			ranges = <0x02000000 0x0 0xfe000000 0x0 0xfe000000 0x0 0x1000000>;
 
 			bus-range = <0x00 0x00>;
+			msi-parent = <&msix>;
+		};
+
+		msix: msix at fbe00000 {
+			compatible = "al,alpine-msix";
+			reg = <0x0 0xfbe00000 0x0 0x100000>;
+			interrupt-controller;
+			msi-controller;
+			al,msi-base-spi = <96>;
+			al,msi-num-spis = <64>;
 		};
 	};
 };
-- 
2.7.1



From antoine.tenart at free-electrons.com  Thu Feb 25 02:14:56 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Thu, 25 Feb 2016 11:14:56 +0100
Subject: [PATCH 6/7] arm64: alpine: select the Alpine MSI controller driver
In-Reply-To: <1456395297-6505-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1456395297-6505-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1456395297-6505-7-git-send-email-antoine.tenart@free-electrons.com>

Select the Alpine MSI controller driver when using an Alpine platform.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index bfbefa3e0dbe..6761e12e5e13 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -2,6 +2,7 @@ menu "Platform selection"
 
 config ARCH_ALPINE
 	bool "Annapurna Labs Alpine platform"
+	select ALPINE_MSI
 	help
 	  This enables support for the Annapurna Labs Alpine
 	  Soc family.
-- 
2.7.1



From antoine.tenart at free-electrons.com  Thu Feb 25 02:14:57 2016
From: antoine.tenart at free-electrons.com (Antoine Tenart)
Date: Thu, 25 Feb 2016 11:14:57 +0100
Subject: [PATCH 7/7] ARM: alpine: select the Alpine MSI controller driver
In-Reply-To: <1456395297-6505-1-git-send-email-antoine.tenart@free-electrons.com>
References: <1456395297-6505-1-git-send-email-antoine.tenart@free-electrons.com>
Message-ID: <1456395297-6505-8-git-send-email-antoine.tenart@free-electrons.com>

Select the Alpine MSI controller driver when using an Alpine platform.

Signed-off-by: Antoine Tenart <antoine.tenart at free-electrons.com>
Signed-off-by: Tsahee Zidenberg <tsahee at annapurnalabs.com>
---
 arch/arm/mach-alpine/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-alpine/Kconfig b/arch/arm/mach-alpine/Kconfig
index 5c2d54f59f53..b41838a58ae4 100644
--- a/arch/arm/mach-alpine/Kconfig
+++ b/arch/arm/mach-alpine/Kconfig
@@ -1,6 +1,7 @@
 config ARCH_ALPINE
 	bool "Annapurna Labs Alpine platform"
 	depends on ARCH_MULTI_V7
+	select ALPINE_MSI
 	select ARM_AMBA
 	select ARM_GIC
 	select GENERIC_IRQ_CHIP
-- 
2.7.1



From thomas.petazzoni at free-electrons.com  Thu Feb 25 02:31:37 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 25 Feb 2016 11:31:37 +0100
Subject: [PATCH 1/2] ARM: mvebu: change order of ethernet DT nodes on
 Armada 38x
In-Reply-To: <20160224184114.GB2292@1wt.eu>
References: <1453907300-28283-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1453907300-28283-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160127193143.GF10826@n2100.arm.linux.org.uk>
 <20160127194512.GA16638@1wt.eu>
 <20160129114853.GQ10826@n2100.arm.linux.org.uk>
 <20160224184114.GB2292@1wt.eu>
Message-ID: <20160225113137.317ac08f@free-electrons.com>

Willy,

On Wed, 24 Feb 2016 19:41:14 +0100, Willy Tarreau wrote:

> Thus could we please get Thomas' patch to ensure that the board boots
> with similar interface naming with both the original and mainline kernel ?

My patch has already been applied by the mvebu maintainers in
the mvebu/dt branch:
http://git.infradead.org/linux-mvebu.git/commit/cb4f71c4298853db0c6751b1209e4535956f136c.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From thomas.petazzoni at free-electrons.com  Thu Feb 25 02:32:25 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 25 Feb 2016 11:32:25 +0100
Subject: [PATCH 1/2] ARM: mvebu: change order of ethernet DT nodes on
 Armada 38x
In-Reply-To: <op.ydcptvss2s3iss@ecaz>
References: <1453907300-28283-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1453907300-28283-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160127193143.GF10826@n2100.arm.linux.org.uk>
 <20160127194512.GA16638@1wt.eu>
 <20160129114853.GQ10826@n2100.arm.linux.org.uk>
 <20160224184114.GB2292@1wt.eu> <op.ydcptvss2s3iss@ecaz>
Message-ID: <20160225113225.036d1d5f@free-electrons.com>

Dear Imre Kaloz,

On Wed, 24 Feb 2016 20:02:09 +0100, Imre Kaloz wrote:

> Shouldn't this change be device specific then instead of messing up the  
> dtsi?

It's the order in which the nodes are defined at the top-most level
that counts. So if you change the order of the nodes in the .dts files,
it won't change anything.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From blogic at openwrt.org  Mon Feb 22 04:56:56 2016
From: blogic at openwrt.org (John Crispin)
Date: Mon, 22 Feb 2016 13:56:56 +0100
Subject: [PATCH V7 1/2] regulator: Add document for MT6323 regulator
Message-ID: <1456145817-12741-1-git-send-email-blogic@openwrt.org>

Signed-off-by: John Crispin <blogic at openwrt.org>
Cc: devicetree at vger.kernel.org
---
This patch needs to be merged post-rc1 as it depends on the MFD series of
the PMIC which is already inside Lee's tree pending the PR.

Changes in V7
* remove another compatible string
* small wording changes

Changes in V6
* remove the compatible string

Changes in V5
* regulator vs regulators

Changes in V4
* regulator is a subnode and not a property

 .../bindings/regulator/mt6323-regulator.txt        |  239 ++++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/mt6323-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
new file mode 100644
index 0000000..9fd95e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
@@ -0,0 +1,239 @@
+Mediatek MT6323 Regulator Driver
+
+All voltage regulators are defined as subnodes of the regulators node. A list
+of regulators provided by this controller are defined as subnodes of the
+PMIC's node. Each regulator is named according to its regulator type,
+buck_<name> and ldo_<name>. The definition for each of these nodes is defined
+using the standard binding for regulators at
+Documentation/devicetree/bindings/regulator/regulator.txt.
+
+The valid names for regulators are::
+BUCK:
+  buck_vproc, buck_vsys, buck_vpa
+LDO:
+  ldo_vtcxo, ldo_vcn28, ldo_vcn33_bt, ldo_vcn33_wifi, ldo_va, ldo_vcama,
+  ldo_vio28, ldo_vusb, ldo_vmc, ldo_vmch, ldo_vemc3v3, ldo_vgp1, ldo_vgp2,
+  ldo_vgp3, ldo_vcn18, ldo_vsim1, ldo_vsim2, ldo_vrtc, ldo_vcamaf, ldo_vibr,
+  ldo_vrf18, ldo_vm, ldo_vio18, ldo_vcamd, ldo_vcamio
+
+Example:
+
+	pmic: mt6323 {
+		compatible = "mediatek,mt6323";
+
+		mt6323regulator: regulators {
+			mt6323_vproc_reg: buck_vproc{
+				regulator-name = "vproc";
+				regulator-min-microvolt = < 700000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <12500>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vsys_reg: buck_vsys{
+				regulator-name = "vsys";
+				regulator-min-microvolt = <1400000>;
+				regulator-max-microvolt = <2987500>;
+				regulator-ramp-delay = <25000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vpa_reg: buck_vpa{
+				regulator-name = "vpa";
+				regulator-min-microvolt = < 500000>;
+				regulator-max-microvolt = <3650000>;
+			};
+
+			mt6323_vtcxo_reg: ldo_vtcxo{
+				regulator-name = "vtcxo";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <90>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcn28_reg: ldo_vcn28{
+				regulator-name = "vcn28";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <185>;
+			};
+
+			mt6323_vcn33_bt_reg: ldo_vcn33_bt{
+				regulator-name = "vcn33_bt";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3600000>;
+				regulator-enable-ramp-delay = <185>;
+			};
+
+			mt6323_vcn33_wifi_reg: ldo_vcn33_wifi{
+				regulator-name = "vcn33_wifi";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3600000>;
+				regulator-enable-ramp-delay = <185>;
+			};
+
+			mt6323_va_reg: ldo_va{
+				regulator-name = "va";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcama_reg: ldo_vcama{
+				regulator-name = "vcama";
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vio28_reg: ldo_vio28{
+				regulator-name = "vio28";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vusb_reg: ldo_vusb{
+				regulator-name = "vusb";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-boot-on;
+			};
+
+			mt6323_vmc_reg: ldo_vmc{
+				regulator-name = "vmc";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+				regulator-boot-on;
+			};
+
+			mt6323_vmch_reg: ldo_vmch{
+				regulator-name = "vmch";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+				regulator-boot-on;
+			};
+
+			mt6323_vemc3v3_reg: ldo_vemc3v3{
+				regulator-name = "vemc3v3";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+				regulator-boot-on;
+			};
+
+			mt6323_vgp1_reg: ldo_vgp1{
+				regulator-name = "vgp1";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vgp2_reg: ldo_vgp2{
+				regulator-name = "vgp2";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vgp3_reg: ldo_vgp3{
+				regulator-name = "vgp3";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vcn18_reg: ldo_vcn18{
+				regulator-name = "vcn18";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vsim1_reg: ldo_vsim1{
+				regulator-name = "vsim1";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vsim2_reg: ldo_vsim2{
+				regulator-name = "vsim2";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vrtc_reg: ldo_vrtc{
+				regulator-name = "vrtc";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcamaf_reg: ldo_vcamaf{
+				regulator-name = "vcamaf";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vibr_reg: ldo_vibr{
+				regulator-name = "vibr";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+			};
+
+			mt6323_vrf18_reg: ldo_vrf18{
+				regulator-name = "vrf18";
+				regulator-min-microvolt = <1825000>;
+				regulator-max-microvolt = <1825000>;
+				regulator-enable-ramp-delay = <187>;
+			};
+
+			mt6323_vm_reg: ldo_vm{
+				regulator-name = "vm";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vio18_reg: ldo_vio18{
+				regulator-name = "vio18";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcamd_reg: ldo_vcamd{
+				regulator-name = "vcamd";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vcamio_reg: ldo_vcamio{
+				regulator-name = "vcamio";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+		};
+	};
-- 
1.7.10.4


From blogic at openwrt.org  Mon Feb 22 04:56:57 2016
From: blogic at openwrt.org (John Crispin)
Date: Mon, 22 Feb 2016 13:56:57 +0100
Subject: [PATCH V7 2/2] regulator: mt6323: Add support for MT6323 regulator
In-Reply-To: <1456145817-12741-1-git-send-email-blogic@openwrt.org>
References: <1456145817-12741-1-git-send-email-blogic@openwrt.org>
Message-ID: <1456145817-12741-2-git-send-email-blogic@openwrt.org>

From: Chen Zhong <chen.zhong at mediatek.com>

The MT6323 is a regulator found on boards based on MediaTek MT7623 and
probably other SoCs. It is a so called pmic and connects as a slave to
SoC using SPI, wrapped inside the pmic-wrapper.

Signed-off-by: Chen Zhong <chen.zhong at mediatek.com>
Signed-off-by: John Crispin <blogic at openwrt.org>

---
This patch needs to be merged post-rc1 as it depends on the MFD series of
the PMIC which is already inside Lee's tree pending the PR.

Changes in V6
* add back the set/get mode callbacks

Changes in V5
* remove the code that modifies constraints
* remove the code allows mode changes

Changes in V4:
* add id_table and of_match_table
* use short GPL text
* change MODULE_LICENSE to GPL V2

Changes in V3:
* none

Changes in V2:
* send to the the proper maintainer

 drivers/regulator/Kconfig                  |    9 +
 drivers/regulator/Makefile                 |    1 +
 drivers/regulator/mt6323-regulator.c       |  432 ++++++++++++++++++++++++++++
 include/linux/regulator/mt6323-regulator.h |   52 ++++
 4 files changed, 494 insertions(+)
 create mode 100644 drivers/regulator/mt6323-regulator.c
 create mode 100644 include/linux/regulator/mt6323-regulator.h

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 8155e80..5e49568 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -462,6 +462,15 @@ config REGULATOR_MT6311
 	  This driver supports the control of different power rails of device
 	  through regulator interface.
 
+config REGULATOR_MT6323
+	tristate "MediaTek MT6323 PMIC"
+	depends on MFD_MT6397
+	help
+	  Say y here to select this option to enable the power regulator of
+	  MediaTek MT6323 PMIC.
+	  This driver supports the control of different power rails of device
+	  through regulator interface.
+
 config REGULATOR_MT6397
 	tristate "MediaTek MT6397 PMIC"
 	depends on MFD_MT6397
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 980b194..8fb55640 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
 obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
 obj-$(CONFIG_REGULATOR_MC13XXX_CORE) +=  mc13xxx-regulator-core.o
 obj-$(CONFIG_REGULATOR_MT6311) += mt6311-regulator.o
+obj-$(CONFIG_REGULATOR_MT6323)	+= mt6323-regulator.o
 obj-$(CONFIG_REGULATOR_MT6397)	+= mt6397-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
diff --git a/drivers/regulator/mt6323-regulator.c b/drivers/regulator/mt6323-regulator.c
new file mode 100644
index 0000000..28ebbda
--- /dev/null
+++ b/drivers/regulator/mt6323-regulator.c
@@ -0,0 +1,432 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Chen Zhong <chen.zhong at mediatek.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.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/mfd/mt6397/core.h>
+#include <linux/mfd/mt6323/registers.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/mt6323-regulator.h>
+#include <linux/regulator/of_regulator.h>
+
+#define MT6323_LDO_MODE_NORMAL	0
+#define MT6323_LDO_MODE_LP	1
+
+/*
+ * MT6323 regulators' information
+ *
+ * @desc: standard fields of regulator description.
+ * @qi: Mask for query enable signal status of regulators
+ * @vselon_reg: Register sections for hardware control mode of bucks
+ * @vselctrl_reg: Register for controlling the buck control mode.
+ * @vselctrl_mask: Mask for query buck's voltage control mode.
+ */
+struct mt6323_regulator_info {
+	struct regulator_desc desc;
+	u32 qi;
+	u32 vselon_reg;
+	u32 vselctrl_reg;
+	u32 vselctrl_mask;
+	u32 modeset_reg;
+	u32 modeset_mask;
+};
+
+#define MT6323_BUCK(match, vreg, min, max, step, volt_ranges, enreg,	\
+		vosel, vosel_mask, voselon, vosel_ctrl)			\
+[MT6323_ID_##vreg] = {							\
+	.desc = {							\
+		.name = #vreg,						\
+		.of_match = of_match_ptr(match),			\
+		.ops = &mt6323_volt_range_ops,				\
+		.type = REGULATOR_VOLTAGE,				\
+		.id = MT6323_ID_##vreg,					\
+		.owner = THIS_MODULE,					\
+		.n_voltages = (max - min)/step + 1,			\
+		.linear_ranges = volt_ranges,				\
+		.n_linear_ranges = ARRAY_SIZE(volt_ranges),		\
+		.vsel_reg = vosel,					\
+		.vsel_mask = vosel_mask,				\
+		.enable_reg = enreg,					\
+		.enable_mask = BIT(0),					\
+	},								\
+	.qi = BIT(13),							\
+	.vselon_reg = voselon,						\
+	.vselctrl_reg = vosel_ctrl,					\
+	.vselctrl_mask = BIT(1),					\
+}
+
+#define MT6323_LDO(match, vreg, ldo_volt_table, enreg, enbit, vosel,	\
+		vosel_mask, _modeset_reg, _modeset_mask)		\
+[MT6323_ID_##vreg] = {							\
+	.desc = {							\
+		.name = #vreg,						\
+		.of_match = of_match_ptr(match),			\
+		.ops = &mt6323_volt_table_ops,				\
+		.type = REGULATOR_VOLTAGE,				\
+		.id = MT6323_ID_##vreg,					\
+		.owner = THIS_MODULE,					\
+		.n_voltages = ARRAY_SIZE(ldo_volt_table),		\
+		.volt_table = ldo_volt_table,				\
+		.vsel_reg = vosel,					\
+		.vsel_mask = vosel_mask,				\
+		.enable_reg = enreg,					\
+		.enable_mask = BIT(enbit),				\
+	},								\
+	.qi = BIT(15),							\
+	.modeset_reg = _modeset_reg,					\
+	.modeset_mask = _modeset_mask,					\
+}
+
+#define MT6323_REG_FIXED(match, vreg, enreg, enbit, volt,		\
+		_modeset_reg, _modeset_mask)				\
+[MT6323_ID_##vreg] = {							\
+	.desc = {							\
+		.name = #vreg,						\
+		.of_match = of_match_ptr(match),			\
+		.ops = &mt6323_volt_fixed_ops,				\
+		.type = REGULATOR_VOLTAGE,				\
+		.id = MT6323_ID_##vreg,					\
+		.owner = THIS_MODULE,					\
+		.n_voltages = 1,					\
+		.enable_reg = enreg,					\
+		.enable_mask = BIT(enbit),				\
+		.min_uV = volt,						\
+	},								\
+	.qi = BIT(15),							\
+	.modeset_reg = _modeset_reg,					\
+	.modeset_mask = _modeset_mask,					\
+}
+
+static const struct regulator_linear_range buck_volt_range1[] = {
+	REGULATOR_LINEAR_RANGE(700000, 0, 0x7f, 6250),
+};
+
+static const struct regulator_linear_range buck_volt_range2[] = {
+	REGULATOR_LINEAR_RANGE(1400000, 0, 0x7f, 12500),
+};
+
+static const struct regulator_linear_range buck_volt_range3[] = {
+	REGULATOR_LINEAR_RANGE(500000, 0, 0x3f, 50000),
+};
+
+static const u32 ldo_volt_table1[] = {
+	3300000, 3400000, 3500000, 3600000,
+};
+
+static const u32 ldo_volt_table2[] = {
+	1500000, 1800000, 2500000, 2800000,
+};
+
+static const u32 ldo_volt_table3[] = {
+	1800000, 3300000,
+};
+
+static const u32 ldo_volt_table4[] = {
+	3000000, 3300000,
+};
+
+static const u32 ldo_volt_table5[] = {
+	1200000, 1300000, 1500000, 1800000, 2000000, 2800000, 3000000, 3300000,
+};
+
+static const u32 ldo_volt_table6[] = {
+	1200000, 1300000, 1500000, 1800000, 2500000, 2800000, 3000000, 2000000,
+};
+
+static const u32 ldo_volt_table7[] = {
+	1200000, 1300000, 1500000, 1800000,
+};
+
+static const u32 ldo_volt_table8[] = {
+	1800000, 3000000,
+};
+
+static const u32 ldo_volt_table9[] = {
+	1200000, 1350000, 1500000, 1800000,
+};
+
+static const u32 ldo_volt_table10[] = {
+	1200000, 1300000, 1500000, 1800000,
+};
+
+static int mt6323_get_status(struct regulator_dev *rdev)
+{
+	int ret;
+	u32 regval;
+	struct mt6323_regulator_info *info = rdev_get_drvdata(rdev);
+
+	ret = regmap_read(rdev->regmap, info->desc.enable_reg, &regval);
+	if (ret != 0) {
+		dev_err(&rdev->dev, "Failed to get enable reg: %d\n", ret);
+		return ret;
+	}
+
+	return (regval & info->qi) ? REGULATOR_STATUS_ON : REGULATOR_STATUS_OFF;
+}
+
+static int mt6323_ldo_set_mode(struct regulator_dev *rdev, unsigned int mode)
+{
+	int ret, val = 0;
+	struct mt6323_regulator_info *info = rdev_get_drvdata(rdev);
+
+	if (!info->modeset_mask) {
+		dev_err(&rdev->dev, "regulator %s doesn't support set_mode\n",
+			info->desc.name);
+		return -EINVAL;
+	}
+
+	switch (mode) {
+	case REGULATOR_MODE_STANDBY:
+		val = MT6323_LDO_MODE_LP;
+		break;
+	case REGULATOR_MODE_NORMAL:
+		val = MT6323_LDO_MODE_NORMAL;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	val <<= ffs(info->modeset_mask) - 1;
+
+	ret = regmap_update_bits(rdev->regmap, info->modeset_reg,
+				  info->modeset_mask, val);
+
+	return ret;
+}
+
+static unsigned int mt6323_ldo_get_mode(struct regulator_dev *rdev)
+{
+	unsigned int val;
+	unsigned int mode;
+	int ret;
+	struct mt6323_regulator_info *info = rdev_get_drvdata(rdev);
+
+	if (!info->modeset_mask) {
+		dev_err(&rdev->dev, "regulator %s doesn't support get_mode\n",
+			info->desc.name);
+		return -EINVAL;
+	}
+
+	ret = regmap_read(rdev->regmap, info->modeset_reg, &val);
+	if (ret < 0)
+		return ret;
+
+	val &= info->modeset_mask;
+	val >>= ffs(info->modeset_mask) - 1;
+
+	if (val & 0x1)
+		mode = REGULATOR_MODE_STANDBY;
+	else
+		mode = REGULATOR_MODE_NORMAL;
+
+	return mode;
+}
+
+static struct regulator_ops mt6323_volt_range_ops = {
+	.list_voltage = regulator_list_voltage_linear_range,
+	.map_voltage = regulator_map_voltage_linear_range,
+	.set_voltage_sel = regulator_set_voltage_sel_regmap,
+	.get_voltage_sel = regulator_get_voltage_sel_regmap,
+	.set_voltage_time_sel = regulator_set_voltage_time_sel,
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.is_enabled = regulator_is_enabled_regmap,
+	.get_status = mt6323_get_status,
+};
+
+static struct regulator_ops mt6323_volt_table_ops = {
+	.list_voltage = regulator_list_voltage_table,
+	.map_voltage = regulator_map_voltage_iterate,
+	.set_voltage_sel = regulator_set_voltage_sel_regmap,
+	.get_voltage_sel = regulator_get_voltage_sel_regmap,
+	.set_voltage_time_sel = regulator_set_voltage_time_sel,
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.is_enabled = regulator_is_enabled_regmap,
+	.get_status = mt6323_get_status,
+	.set_mode = mt6323_ldo_set_mode,
+	.get_mode = mt6323_ldo_get_mode,
+};
+
+static struct regulator_ops mt6323_volt_fixed_ops = {
+	.list_voltage = regulator_list_voltage_linear,
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.is_enabled = regulator_is_enabled_regmap,
+	.get_status = mt6323_get_status,
+	.set_mode = mt6323_ldo_set_mode,
+	.get_mode = mt6323_ldo_get_mode,
+};
+
+/* The array is indexed by id(MT6323_ID_XXX) */
+static struct mt6323_regulator_info mt6323_regulators[] = {
+	MT6323_BUCK("buck_vproc", VPROC, 700000, 1493750, 6250,
+		buck_volt_range1, MT6323_VPROC_CON7, MT6323_VPROC_CON9, 0x7f,
+		MT6323_VPROC_CON10, MT6323_VPROC_CON5),
+	MT6323_BUCK("buck_vsys", VSYS, 1400000, 2987500, 12500,
+		buck_volt_range2, MT6323_VSYS_CON7, MT6323_VSYS_CON9, 0x7f,
+		MT6323_VSYS_CON10, MT6323_VSYS_CON5),
+	MT6323_BUCK("buck_vpa", VPA, 500000, 3650000, 50000,
+		buck_volt_range3, MT6323_VPA_CON7, MT6323_VPA_CON9,
+		0x3f, MT6323_VPA_CON10, MT6323_VPA_CON5),
+	MT6323_REG_FIXED("ldo_vtcxo", VTCXO, MT6323_ANALDO_CON1, 10, 2800000,
+		MT6323_ANALDO_CON1, 0x2),
+	MT6323_REG_FIXED("ldo_vcn28", VCN28, MT6323_ANALDO_CON19, 12, 2800000,
+		MT6323_ANALDO_CON20, 0x2),
+	MT6323_LDO("ldo_vcn33_bt", VCN33_BT, ldo_volt_table1,
+		MT6323_ANALDO_CON16, 7, MT6323_ANALDO_CON16, 0xC,
+		MT6323_ANALDO_CON21, 0x2),
+	MT6323_LDO("ldo_vcn33_wifi", VCN33_WIFI, ldo_volt_table1,
+		MT6323_ANALDO_CON17, 12, MT6323_ANALDO_CON16, 0xC,
+		MT6323_ANALDO_CON21, 0x2),
+	MT6323_REG_FIXED("ldo_va", VA, MT6323_ANALDO_CON2, 14, 2800000,
+		MT6323_ANALDO_CON2, 0x2),
+	MT6323_LDO("ldo_vcama", VCAMA, ldo_volt_table2,
+		MT6323_ANALDO_CON4, 15, MT6323_ANALDO_CON10, 0x60, -1, 0),
+	MT6323_REG_FIXED("ldo_vio28", VIO28, MT6323_DIGLDO_CON0, 14, 2800000,
+		MT6323_DIGLDO_CON0, 0x2),
+	MT6323_REG_FIXED("ldo_vusb", VUSB, MT6323_DIGLDO_CON2, 14, 3300000,
+		MT6323_DIGLDO_CON2, 0x2),
+	MT6323_LDO("ldo_vmc", VMC, ldo_volt_table3,
+		MT6323_DIGLDO_CON3, 12, MT6323_DIGLDO_CON24, 0x10,
+		MT6323_DIGLDO_CON3, 0x2),
+	MT6323_LDO("ldo_vmch", VMCH, ldo_volt_table4,
+		MT6323_DIGLDO_CON5, 14, MT6323_DIGLDO_CON26, 0x80,
+		MT6323_DIGLDO_CON5, 0x2),
+	MT6323_LDO("ldo_vemc3v3", VEMC3V3, ldo_volt_table4,
+		MT6323_DIGLDO_CON6, 14, MT6323_DIGLDO_CON27, 0x80,
+		MT6323_DIGLDO_CON6, 0x2),
+	MT6323_LDO("ldo_vgp1", VGP1, ldo_volt_table5,
+		MT6323_DIGLDO_CON7, 15, MT6323_DIGLDO_CON28, 0xE0,
+		MT6323_DIGLDO_CON7, 0x2),
+	MT6323_LDO("ldo_vgp2", VGP2, ldo_volt_table6,
+		MT6323_DIGLDO_CON8, 15, MT6323_DIGLDO_CON29, 0xE0,
+		MT6323_DIGLDO_CON8, 0x2),
+	MT6323_LDO("ldo_vgp3", VGP3, ldo_volt_table7,
+		MT6323_DIGLDO_CON9, 15, MT6323_DIGLDO_CON30, 0x60,
+		MT6323_DIGLDO_CON9, 0x2),
+	MT6323_REG_FIXED("ldo_vcn18", VCN18, MT6323_DIGLDO_CON11, 14, 1800000,
+		MT6323_DIGLDO_CON11, 0x2),
+	MT6323_LDO("ldo_vsim1", VSIM1, ldo_volt_table8,
+		MT6323_DIGLDO_CON13, 15, MT6323_DIGLDO_CON34, 0x20,
+		MT6323_DIGLDO_CON13, 0x2),
+	MT6323_LDO("ldo_vsim2", VSIM2, ldo_volt_table8,
+		MT6323_DIGLDO_CON14, 15, MT6323_DIGLDO_CON35, 0x20,
+		MT6323_DIGLDO_CON14, 0x2),
+	MT6323_REG_FIXED("ldo_vrtc", VRTC, MT6323_DIGLDO_CON15, 8, 2800000,
+		-1, 0),
+	MT6323_LDO("ldo_vcamaf", VCAMAF, ldo_volt_table5,
+		MT6323_DIGLDO_CON31, 15, MT6323_DIGLDO_CON32, 0xE0,
+		MT6323_DIGLDO_CON31, 0x2),
+	MT6323_LDO("ldo_vibr", VIBR, ldo_volt_table5,
+		MT6323_DIGLDO_CON39, 15, MT6323_DIGLDO_CON40, 0xE0,
+		MT6323_DIGLDO_CON39, 0x2),
+	MT6323_REG_FIXED("ldo_vrf18", VRF18, MT6323_DIGLDO_CON45, 15, 1825000,
+		MT6323_DIGLDO_CON45, 0x2),
+	MT6323_LDO("ldo_vm", VM, ldo_volt_table9,
+		MT6323_DIGLDO_CON47, 14, MT6323_DIGLDO_CON48, 0x30,
+		MT6323_DIGLDO_CON47, 0x2),
+	MT6323_REG_FIXED("ldo_vio18", VIO18, MT6323_DIGLDO_CON49, 14, 1800000,
+		MT6323_DIGLDO_CON49, 0x2),
+	MT6323_LDO("ldo_vcamd", VCAMD, ldo_volt_table10,
+		MT6323_DIGLDO_CON51, 14, MT6323_DIGLDO_CON52, 0x60,
+		MT6323_DIGLDO_CON51, 0x2),
+	MT6323_REG_FIXED("ldo_vcamio", VCAMIO, MT6323_DIGLDO_CON53, 14, 1800000,
+		MT6323_DIGLDO_CON53, 0x2),
+};
+
+static int mt6323_set_buck_vosel_reg(struct platform_device *pdev)
+{
+	struct mt6397_chip *mt6323 = dev_get_drvdata(pdev->dev.parent);
+	int i;
+	u32 regval;
+
+	for (i = 0; i < MT6323_MAX_REGULATOR; i++) {
+		if (mt6323_regulators[i].vselctrl_reg) {
+			if (regmap_read(mt6323->regmap,
+				mt6323_regulators[i].vselctrl_reg,
+				&regval) < 0) {
+				dev_err(&pdev->dev,
+					"Failed to read buck ctrl\n");
+				return -EIO;
+			}
+
+			if (regval & mt6323_regulators[i].vselctrl_mask) {
+				mt6323_regulators[i].desc.vsel_reg =
+				mt6323_regulators[i].vselon_reg;
+			}
+		}
+	}
+
+	return 0;
+}
+
+static int mt6323_regulator_probe(struct platform_device *pdev)
+{
+	struct mt6397_chip *mt6323 = dev_get_drvdata(pdev->dev.parent);
+	struct regulator_config config = {};
+	struct regulator_dev *rdev;
+	int i;
+	u32 reg_value;
+
+	/* Query buck controller to select activated voltage register part */
+	if (mt6323_set_buck_vosel_reg(pdev))
+		return -EIO;
+
+	/* Read PMIC chip revision to update constraints and voltage table */
+	if (regmap_read(mt6323->regmap, MT6323_CID, &reg_value) < 0) {
+		dev_err(&pdev->dev, "Failed to read Chip ID\n");
+		return -EIO;
+	}
+	dev_info(&pdev->dev, "Chip ID = 0x%x\n", reg_value);
+
+	for (i = 0; i < MT6323_MAX_REGULATOR; i++) {
+		config.dev = &pdev->dev;
+		config.driver_data = &mt6323_regulators[i];
+		config.regmap = mt6323->regmap;
+		rdev = devm_regulator_register(&pdev->dev,
+				&mt6323_regulators[i].desc, &config);
+		if (IS_ERR(rdev)) {
+			dev_err(&pdev->dev, "failed to register %s\n",
+				mt6323_regulators[i].desc.name);
+			return PTR_ERR(rdev);
+		}
+	}
+	return 0;
+}
+
+static const struct platform_device_id mt6323_platform_ids[] = {
+	{"mt6323-regulator", 0},
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(platform, mt6323_platform_ids);
+
+static const struct of_device_id mt6323_of_match[] = {
+	{ .compatible = "mediatek,mt6323-regulator", },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mt6323_of_match);
+
+static struct platform_driver mt6323_regulator_driver = {
+	.driver = {
+		.name = "mt6323-regulator",
+		.of_match_table = of_match_ptr(mt6323_of_match),
+	},
+	.probe = mt6323_regulator_probe,
+	.id_table = mt6323_platform_ids,
+};
+
+module_platform_driver(mt6323_regulator_driver);
+
+MODULE_AUTHOR("Chen Zhong <chen.zhong at mediatek.com>");
+MODULE_DESCRIPTION("Regulator Driver for MediaTek MT6397 PMIC");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/regulator/mt6323-regulator.h b/include/linux/regulator/mt6323-regulator.h
new file mode 100644
index 0000000..67011cd
--- /dev/null
+++ b/include/linux/regulator/mt6323-regulator.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Chen Zhong <chen.zhong at mediatek.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.
+ */
+
+#ifndef __LINUX_REGULATOR_MT6323_H
+#define __LINUX_REGULATOR_MT6323_H
+
+enum {
+	MT6323_ID_VPROC = 0,
+	MT6323_ID_VSYS,
+	MT6323_ID_VPA,
+	MT6323_ID_VTCXO,
+	MT6323_ID_VCN28,
+	MT6323_ID_VCN33_BT,
+	MT6323_ID_VCN33_WIFI,
+	MT6323_ID_VA,
+	MT6323_ID_VCAMA,
+	MT6323_ID_VIO28 = 9,
+	MT6323_ID_VUSB,
+	MT6323_ID_VMC,
+	MT6323_ID_VMCH,
+	MT6323_ID_VEMC3V3,
+	MT6323_ID_VGP1,
+	MT6323_ID_VGP2,
+	MT6323_ID_VGP3,
+	MT6323_ID_VCN18,
+	MT6323_ID_VSIM1,
+	MT6323_ID_VSIM2,
+	MT6323_ID_VRTC,
+	MT6323_ID_VCAMAF,
+	MT6323_ID_VIBR,
+	MT6323_ID_VRF18,
+	MT6323_ID_VM,
+	MT6323_ID_VIO18,
+	MT6323_ID_VCAMD,
+	MT6323_ID_VCAMIO,
+	MT6323_ID_RG_MAX,
+};
+
+#define MT6323_MAX_REGULATOR	MT6323_ID_RG_MAX
+
+#endif /* __LINUX_REGULATOR_MT6323_H */
-- 
1.7.10.4


From thomas.petazzoni at free-electrons.com  Thu Feb 25 02:36:10 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 25 Feb 2016 11:36:10 +0100
Subject: [PATCH 1/2] ARM: mvebu: change order of ethernet DT nodes on
 Armada 38x
In-Reply-To: <20160224223350.GP19428@n2100.arm.linux.org.uk>
References: <1453907300-28283-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1453907300-28283-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160127193143.GF10826@n2100.arm.linux.org.uk>
 <20160127194512.GA16638@1wt.eu>
 <20160129114853.GQ10826@n2100.arm.linux.org.uk>
 <20160224184114.GB2292@1wt.eu>
 <20160224223350.GP19428@n2100.arm.linux.org.uk>
Message-ID: <20160225113610.351149bf@free-electrons.com>

Hello,

On Wed, 24 Feb 2016 22:33:50 +0000, Russell King - ARM Linux wrote:

> I didn't say no to it, I merely asked a few pertinent questions and
> made some pertinent points.
> 
> Let me restate:
> 
> * Today, people who switch between mainline and vendor kernels
>   experience some pain due to the NIC order changing.
> 
> * Mainline has had support for Armada 38x for 2 years now, which is
>   long enough for it to have gained users.  AFAICS, there haven't been
>   any complaints about the different NIC ordering.  Changing the NIC
>   ordering is going to cause breakage to these users when they migrate
>   across the change.
> 
> By making the change, we're effectively telling these mainline-only
> users "we don't care about your setups, we're going to break them"
> because that's exactly what we're going to do.
> 
> Of course, if no one complains about the change, you've got away
> with it.

I agree with you that the change isn't perfect, it's really a matter of
trade-off. The perfect change would be to be able to help the network
subsystem in its naming of network interfaces, but this has always been
rejected. It would have indeed been better to add this DT node ordering
work-around earlier, but we didn't do it, and we're in the present.

So again, yes the proposed change is not "great", but I believe it's
relatively reasonable. If we indeed get feedback that it's breaking
things for too many people, I guess we'll just revert. I don't mind if
things remain as they are today, i.e with a weird ordering of the
network interfaces. It's just annoying for new people using the
platform, but it's not horrible either.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From blogic at openwrt.org  Thu Feb 25 02:37:10 2016
From: blogic at openwrt.org (John Crispin)
Date: Thu, 25 Feb 2016 11:37:10 +0100
Subject: [PATCH V7 1/2] regulator: Add document for MT6323 regulator
Message-ID: <1456396631-12788-1-git-send-email-blogic@openwrt.org>

Signed-off-by: John Crispin <blogic at openwrt.org>
Cc: devicetree at vger.kernel.org
---
This patch needs to be merged post-rc1 as it depends on the MFD series of
the PMIC which is already inside Lee's tree pending the PR.

Changes in V7
* remove another compatible string
* small wording changes

Changes in V6
* remove the compatible string

Changes in V5
* regulator vs regulators

Changes in V4
* regulator is a subnode and not a property

 .../bindings/regulator/mt6323-regulator.txt        |  239 ++++++++++++++++++++
 1 file changed, 239 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/mt6323-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
new file mode 100644
index 0000000..9fd95e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
@@ -0,0 +1,239 @@
+Mediatek MT6323 Regulator Driver
+
+All voltage regulators are defined as subnodes of the regulators node. A list
+of regulators provided by this controller are defined as subnodes of the
+PMIC's node. Each regulator is named according to its regulator type,
+buck_<name> and ldo_<name>. The definition for each of these nodes is defined
+using the standard binding for regulators at
+Documentation/devicetree/bindings/regulator/regulator.txt.
+
+The valid names for regulators are::
+BUCK:
+  buck_vproc, buck_vsys, buck_vpa
+LDO:
+  ldo_vtcxo, ldo_vcn28, ldo_vcn33_bt, ldo_vcn33_wifi, ldo_va, ldo_vcama,
+  ldo_vio28, ldo_vusb, ldo_vmc, ldo_vmch, ldo_vemc3v3, ldo_vgp1, ldo_vgp2,
+  ldo_vgp3, ldo_vcn18, ldo_vsim1, ldo_vsim2, ldo_vrtc, ldo_vcamaf, ldo_vibr,
+  ldo_vrf18, ldo_vm, ldo_vio18, ldo_vcamd, ldo_vcamio
+
+Example:
+
+	pmic: mt6323 {
+		compatible = "mediatek,mt6323";
+
+		mt6323regulator: regulators {
+			mt6323_vproc_reg: buck_vproc{
+				regulator-name = "vproc";
+				regulator-min-microvolt = < 700000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <12500>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vsys_reg: buck_vsys{
+				regulator-name = "vsys";
+				regulator-min-microvolt = <1400000>;
+				regulator-max-microvolt = <2987500>;
+				regulator-ramp-delay = <25000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vpa_reg: buck_vpa{
+				regulator-name = "vpa";
+				regulator-min-microvolt = < 500000>;
+				regulator-max-microvolt = <3650000>;
+			};
+
+			mt6323_vtcxo_reg: ldo_vtcxo{
+				regulator-name = "vtcxo";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <90>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcn28_reg: ldo_vcn28{
+				regulator-name = "vcn28";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <185>;
+			};
+
+			mt6323_vcn33_bt_reg: ldo_vcn33_bt{
+				regulator-name = "vcn33_bt";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3600000>;
+				regulator-enable-ramp-delay = <185>;
+			};
+
+			mt6323_vcn33_wifi_reg: ldo_vcn33_wifi{
+				regulator-name = "vcn33_wifi";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3600000>;
+				regulator-enable-ramp-delay = <185>;
+			};
+
+			mt6323_va_reg: ldo_va{
+				regulator-name = "va";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcama_reg: ldo_vcama{
+				regulator-name = "vcama";
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vio28_reg: ldo_vio28{
+				regulator-name = "vio28";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vusb_reg: ldo_vusb{
+				regulator-name = "vusb";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-boot-on;
+			};
+
+			mt6323_vmc_reg: ldo_vmc{
+				regulator-name = "vmc";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+				regulator-boot-on;
+			};
+
+			mt6323_vmch_reg: ldo_vmch{
+				regulator-name = "vmch";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+				regulator-boot-on;
+			};
+
+			mt6323_vemc3v3_reg: ldo_vemc3v3{
+				regulator-name = "vemc3v3";
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+				regulator-boot-on;
+			};
+
+			mt6323_vgp1_reg: ldo_vgp1{
+				regulator-name = "vgp1";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vgp2_reg: ldo_vgp2{
+				regulator-name = "vgp2";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vgp3_reg: ldo_vgp3{
+				regulator-name = "vgp3";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vcn18_reg: ldo_vcn18{
+				regulator-name = "vcn18";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vsim1_reg: ldo_vsim1{
+				regulator-name = "vsim1";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vsim2_reg: ldo_vsim2{
+				regulator-name = "vsim2";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vrtc_reg: ldo_vrtc{
+				regulator-name = "vrtc";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcamaf_reg: ldo_vcamaf{
+				regulator-name = "vcamaf";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vibr_reg: ldo_vibr{
+				regulator-name = "vibr";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-enable-ramp-delay = <36>;
+			};
+
+			mt6323_vrf18_reg: ldo_vrf18{
+				regulator-name = "vrf18";
+				regulator-min-microvolt = <1825000>;
+				regulator-max-microvolt = <1825000>;
+				regulator-enable-ramp-delay = <187>;
+			};
+
+			mt6323_vm_reg: ldo_vm{
+				regulator-name = "vm";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vio18_reg: ldo_vio18{
+				regulator-name = "vio18";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+				regulator-always-on;
+				regulator-boot-on;
+			};
+
+			mt6323_vcamd_reg: ldo_vcamd{
+				regulator-name = "vcamd";
+				regulator-min-microvolt = <1200000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+
+			mt6323_vcamio_reg: ldo_vcamio{
+				regulator-name = "vcamio";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-enable-ramp-delay = <216>;
+			};
+		};
+	};
-- 
1.7.10.4


From blogic at openwrt.org  Thu Feb 25 02:37:11 2016
From: blogic at openwrt.org (John Crispin)
Date: Thu, 25 Feb 2016 11:37:11 +0100
Subject: [PATCH V7 2/2] regulator: mt6323: Add support for MT6323 regulator
In-Reply-To: <1456396631-12788-1-git-send-email-blogic@openwrt.org>
References: <1456396631-12788-1-git-send-email-blogic@openwrt.org>
Message-ID: <1456396631-12788-2-git-send-email-blogic@openwrt.org>

From: Chen Zhong <chen.zhong at mediatek.com>

The MT6323 is a regulator found on boards based on MediaTek MT7623 and
probably other SoCs. It is a so called pmic and connects as a slave to
SoC using SPI, wrapped inside the pmic-wrapper.

Signed-off-by: Chen Zhong <chen.zhong at mediatek.com>
Signed-off-by: John Crispin <blogic at openwrt.org>

---
This patch needs to be merged post-rc1 as it depends on the MFD series of
the PMIC which is already inside Lee's tree pending the PR.

Changes in V6
* add back the set/get mode callbacks

Changes in V5
* remove the code that modifies constraints
* remove the code allows mode changes

Changes in V4:
* add id_table and of_match_table
* use short GPL text
* change MODULE_LICENSE to GPL V2

Changes in V3:
* none

Changes in V2:
* send to the the proper maintainer

 drivers/regulator/Kconfig                  |    9 +
 drivers/regulator/Makefile                 |    1 +
 drivers/regulator/mt6323-regulator.c       |  432 ++++++++++++++++++++++++++++
 include/linux/regulator/mt6323-regulator.h |   52 ++++
 4 files changed, 494 insertions(+)
 create mode 100644 drivers/regulator/mt6323-regulator.c
 create mode 100644 include/linux/regulator/mt6323-regulator.h

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 8155e80..5e49568 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -462,6 +462,15 @@ config REGULATOR_MT6311
 	  This driver supports the control of different power rails of device
 	  through regulator interface.
 
+config REGULATOR_MT6323
+	tristate "MediaTek MT6323 PMIC"
+	depends on MFD_MT6397
+	help
+	  Say y here to select this option to enable the power regulator of
+	  MediaTek MT6323 PMIC.
+	  This driver supports the control of different power rails of device
+	  through regulator interface.
+
 config REGULATOR_MT6397
 	tristate "MediaTek MT6397 PMIC"
 	depends on MFD_MT6397
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 980b194..8fb55640 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
 obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
 obj-$(CONFIG_REGULATOR_MC13XXX_CORE) +=  mc13xxx-regulator-core.o
 obj-$(CONFIG_REGULATOR_MT6311) += mt6311-regulator.o
+obj-$(CONFIG_REGULATOR_MT6323)	+= mt6323-regulator.o
 obj-$(CONFIG_REGULATOR_MT6397)	+= mt6397-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
diff --git a/drivers/regulator/mt6323-regulator.c b/drivers/regulator/mt6323-regulator.c
new file mode 100644
index 0000000..28ebbda
--- /dev/null
+++ b/drivers/regulator/mt6323-regulator.c
@@ -0,0 +1,432 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Chen Zhong <chen.zhong at mediatek.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.
+ */
+
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/mfd/mt6397/core.h>
+#include <linux/mfd/mt6323/registers.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+#include <linux/regulator/mt6323-regulator.h>
+#include <linux/regulator/of_regulator.h>
+
+#define MT6323_LDO_MODE_NORMAL	0
+#define MT6323_LDO_MODE_LP	1
+
+/*
+ * MT6323 regulators' information
+ *
+ * @desc: standard fields of regulator description.
+ * @qi: Mask for query enable signal status of regulators
+ * @vselon_reg: Register sections for hardware control mode of bucks
+ * @vselctrl_reg: Register for controlling the buck control mode.
+ * @vselctrl_mask: Mask for query buck's voltage control mode.
+ */
+struct mt6323_regulator_info {
+	struct regulator_desc desc;
+	u32 qi;
+	u32 vselon_reg;
+	u32 vselctrl_reg;
+	u32 vselctrl_mask;
+	u32 modeset_reg;
+	u32 modeset_mask;
+};
+
+#define MT6323_BUCK(match, vreg, min, max, step, volt_ranges, enreg,	\
+		vosel, vosel_mask, voselon, vosel_ctrl)			\
+[MT6323_ID_##vreg] = {							\
+	.desc = {							\
+		.name = #vreg,						\
+		.of_match = of_match_ptr(match),			\
+		.ops = &mt6323_volt_range_ops,				\
+		.type = REGULATOR_VOLTAGE,				\
+		.id = MT6323_ID_##vreg,					\
+		.owner = THIS_MODULE,					\
+		.n_voltages = (max - min)/step + 1,			\
+		.linear_ranges = volt_ranges,				\
+		.n_linear_ranges = ARRAY_SIZE(volt_ranges),		\
+		.vsel_reg = vosel,					\
+		.vsel_mask = vosel_mask,				\
+		.enable_reg = enreg,					\
+		.enable_mask = BIT(0),					\
+	},								\
+	.qi = BIT(13),							\
+	.vselon_reg = voselon,						\
+	.vselctrl_reg = vosel_ctrl,					\
+	.vselctrl_mask = BIT(1),					\
+}
+
+#define MT6323_LDO(match, vreg, ldo_volt_table, enreg, enbit, vosel,	\
+		vosel_mask, _modeset_reg, _modeset_mask)		\
+[MT6323_ID_##vreg] = {							\
+	.desc = {							\
+		.name = #vreg,						\
+		.of_match = of_match_ptr(match),			\
+		.ops = &mt6323_volt_table_ops,				\
+		.type = REGULATOR_VOLTAGE,				\
+		.id = MT6323_ID_##vreg,					\
+		.owner = THIS_MODULE,					\
+		.n_voltages = ARRAY_SIZE(ldo_volt_table),		\
+		.volt_table = ldo_volt_table,				\
+		.vsel_reg = vosel,					\
+		.vsel_mask = vosel_mask,				\
+		.enable_reg = enreg,					\
+		.enable_mask = BIT(enbit),				\
+	},								\
+	.qi = BIT(15),							\
+	.modeset_reg = _modeset_reg,					\
+	.modeset_mask = _modeset_mask,					\
+}
+
+#define MT6323_REG_FIXED(match, vreg, enreg, enbit, volt,		\
+		_modeset_reg, _modeset_mask)				\
+[MT6323_ID_##vreg] = {							\
+	.desc = {							\
+		.name = #vreg,						\
+		.of_match = of_match_ptr(match),			\
+		.ops = &mt6323_volt_fixed_ops,				\
+		.type = REGULATOR_VOLTAGE,				\
+		.id = MT6323_ID_##vreg,					\
+		.owner = THIS_MODULE,					\
+		.n_voltages = 1,					\
+		.enable_reg = enreg,					\
+		.enable_mask = BIT(enbit),				\
+		.min_uV = volt,						\
+	},								\
+	.qi = BIT(15),							\
+	.modeset_reg = _modeset_reg,					\
+	.modeset_mask = _modeset_mask,					\
+}
+
+static const struct regulator_linear_range buck_volt_range1[] = {
+	REGULATOR_LINEAR_RANGE(700000, 0, 0x7f, 6250),
+};
+
+static const struct regulator_linear_range buck_volt_range2[] = {
+	REGULATOR_LINEAR_RANGE(1400000, 0, 0x7f, 12500),
+};
+
+static const struct regulator_linear_range buck_volt_range3[] = {
+	REGULATOR_LINEAR_RANGE(500000, 0, 0x3f, 50000),
+};
+
+static const u32 ldo_volt_table1[] = {
+	3300000, 3400000, 3500000, 3600000,
+};
+
+static const u32 ldo_volt_table2[] = {
+	1500000, 1800000, 2500000, 2800000,
+};
+
+static const u32 ldo_volt_table3[] = {
+	1800000, 3300000,
+};
+
+static const u32 ldo_volt_table4[] = {
+	3000000, 3300000,
+};
+
+static const u32 ldo_volt_table5[] = {
+	1200000, 1300000, 1500000, 1800000, 2000000, 2800000, 3000000, 3300000,
+};
+
+static const u32 ldo_volt_table6[] = {
+	1200000, 1300000, 1500000, 1800000, 2500000, 2800000, 3000000, 2000000,
+};
+
+static const u32 ldo_volt_table7[] = {
+	1200000, 1300000, 1500000, 1800000,
+};
+
+static const u32 ldo_volt_table8[] = {
+	1800000, 3000000,
+};
+
+static const u32 ldo_volt_table9[] = {
+	1200000, 1350000, 1500000, 1800000,
+};
+
+static const u32 ldo_volt_table10[] = {
+	1200000, 1300000, 1500000, 1800000,
+};
+
+static int mt6323_get_status(struct regulator_dev *rdev)
+{
+	int ret;
+	u32 regval;
+	struct mt6323_regulator_info *info = rdev_get_drvdata(rdev);
+
+	ret = regmap_read(rdev->regmap, info->desc.enable_reg, &regval);
+	if (ret != 0) {
+		dev_err(&rdev->dev, "Failed to get enable reg: %d\n", ret);
+		return ret;
+	}
+
+	return (regval & info->qi) ? REGULATOR_STATUS_ON : REGULATOR_STATUS_OFF;
+}
+
+static int mt6323_ldo_set_mode(struct regulator_dev *rdev, unsigned int mode)
+{
+	int ret, val = 0;
+	struct mt6323_regulator_info *info = rdev_get_drvdata(rdev);
+
+	if (!info->modeset_mask) {
+		dev_err(&rdev->dev, "regulator %s doesn't support set_mode\n",
+			info->desc.name);
+		return -EINVAL;
+	}
+
+	switch (mode) {
+	case REGULATOR_MODE_STANDBY:
+		val = MT6323_LDO_MODE_LP;
+		break;
+	case REGULATOR_MODE_NORMAL:
+		val = MT6323_LDO_MODE_NORMAL;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	val <<= ffs(info->modeset_mask) - 1;
+
+	ret = regmap_update_bits(rdev->regmap, info->modeset_reg,
+				  info->modeset_mask, val);
+
+	return ret;
+}
+
+static unsigned int mt6323_ldo_get_mode(struct regulator_dev *rdev)
+{
+	unsigned int val;
+	unsigned int mode;
+	int ret;
+	struct mt6323_regulator_info *info = rdev_get_drvdata(rdev);
+
+	if (!info->modeset_mask) {
+		dev_err(&rdev->dev, "regulator %s doesn't support get_mode\n",
+			info->desc.name);
+		return -EINVAL;
+	}
+
+	ret = regmap_read(rdev->regmap, info->modeset_reg, &val);
+	if (ret < 0)
+		return ret;
+
+	val &= info->modeset_mask;
+	val >>= ffs(info->modeset_mask) - 1;
+
+	if (val & 0x1)
+		mode = REGULATOR_MODE_STANDBY;
+	else
+		mode = REGULATOR_MODE_NORMAL;
+
+	return mode;
+}
+
+static struct regulator_ops mt6323_volt_range_ops = {
+	.list_voltage = regulator_list_voltage_linear_range,
+	.map_voltage = regulator_map_voltage_linear_range,
+	.set_voltage_sel = regulator_set_voltage_sel_regmap,
+	.get_voltage_sel = regulator_get_voltage_sel_regmap,
+	.set_voltage_time_sel = regulator_set_voltage_time_sel,
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.is_enabled = regulator_is_enabled_regmap,
+	.get_status = mt6323_get_status,
+};
+
+static struct regulator_ops mt6323_volt_table_ops = {
+	.list_voltage = regulator_list_voltage_table,
+	.map_voltage = regulator_map_voltage_iterate,
+	.set_voltage_sel = regulator_set_voltage_sel_regmap,
+	.get_voltage_sel = regulator_get_voltage_sel_regmap,
+	.set_voltage_time_sel = regulator_set_voltage_time_sel,
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.is_enabled = regulator_is_enabled_regmap,
+	.get_status = mt6323_get_status,
+	.set_mode = mt6323_ldo_set_mode,
+	.get_mode = mt6323_ldo_get_mode,
+};
+
+static struct regulator_ops mt6323_volt_fixed_ops = {
+	.list_voltage = regulator_list_voltage_linear,
+	.enable = regulator_enable_regmap,
+	.disable = regulator_disable_regmap,
+	.is_enabled = regulator_is_enabled_regmap,
+	.get_status = mt6323_get_status,
+	.set_mode = mt6323_ldo_set_mode,
+	.get_mode = mt6323_ldo_get_mode,
+};
+
+/* The array is indexed by id(MT6323_ID_XXX) */
+static struct mt6323_regulator_info mt6323_regulators[] = {
+	MT6323_BUCK("buck_vproc", VPROC, 700000, 1493750, 6250,
+		buck_volt_range1, MT6323_VPROC_CON7, MT6323_VPROC_CON9, 0x7f,
+		MT6323_VPROC_CON10, MT6323_VPROC_CON5),
+	MT6323_BUCK("buck_vsys", VSYS, 1400000, 2987500, 12500,
+		buck_volt_range2, MT6323_VSYS_CON7, MT6323_VSYS_CON9, 0x7f,
+		MT6323_VSYS_CON10, MT6323_VSYS_CON5),
+	MT6323_BUCK("buck_vpa", VPA, 500000, 3650000, 50000,
+		buck_volt_range3, MT6323_VPA_CON7, MT6323_VPA_CON9,
+		0x3f, MT6323_VPA_CON10, MT6323_VPA_CON5),
+	MT6323_REG_FIXED("ldo_vtcxo", VTCXO, MT6323_ANALDO_CON1, 10, 2800000,
+		MT6323_ANALDO_CON1, 0x2),
+	MT6323_REG_FIXED("ldo_vcn28", VCN28, MT6323_ANALDO_CON19, 12, 2800000,
+		MT6323_ANALDO_CON20, 0x2),
+	MT6323_LDO("ldo_vcn33_bt", VCN33_BT, ldo_volt_table1,
+		MT6323_ANALDO_CON16, 7, MT6323_ANALDO_CON16, 0xC,
+		MT6323_ANALDO_CON21, 0x2),
+	MT6323_LDO("ldo_vcn33_wifi", VCN33_WIFI, ldo_volt_table1,
+		MT6323_ANALDO_CON17, 12, MT6323_ANALDO_CON16, 0xC,
+		MT6323_ANALDO_CON21, 0x2),
+	MT6323_REG_FIXED("ldo_va", VA, MT6323_ANALDO_CON2, 14, 2800000,
+		MT6323_ANALDO_CON2, 0x2),
+	MT6323_LDO("ldo_vcama", VCAMA, ldo_volt_table2,
+		MT6323_ANALDO_CON4, 15, MT6323_ANALDO_CON10, 0x60, -1, 0),
+	MT6323_REG_FIXED("ldo_vio28", VIO28, MT6323_DIGLDO_CON0, 14, 2800000,
+		MT6323_DIGLDO_CON0, 0x2),
+	MT6323_REG_FIXED("ldo_vusb", VUSB, MT6323_DIGLDO_CON2, 14, 3300000,
+		MT6323_DIGLDO_CON2, 0x2),
+	MT6323_LDO("ldo_vmc", VMC, ldo_volt_table3,
+		MT6323_DIGLDO_CON3, 12, MT6323_DIGLDO_CON24, 0x10,
+		MT6323_DIGLDO_CON3, 0x2),
+	MT6323_LDO("ldo_vmch", VMCH, ldo_volt_table4,
+		MT6323_DIGLDO_CON5, 14, MT6323_DIGLDO_CON26, 0x80,
+		MT6323_DIGLDO_CON5, 0x2),
+	MT6323_LDO("ldo_vemc3v3", VEMC3V3, ldo_volt_table4,
+		MT6323_DIGLDO_CON6, 14, MT6323_DIGLDO_CON27, 0x80,
+		MT6323_DIGLDO_CON6, 0x2),
+	MT6323_LDO("ldo_vgp1", VGP1, ldo_volt_table5,
+		MT6323_DIGLDO_CON7, 15, MT6323_DIGLDO_CON28, 0xE0,
+		MT6323_DIGLDO_CON7, 0x2),
+	MT6323_LDO("ldo_vgp2", VGP2, ldo_volt_table6,
+		MT6323_DIGLDO_CON8, 15, MT6323_DIGLDO_CON29, 0xE0,
+		MT6323_DIGLDO_CON8, 0x2),
+	MT6323_LDO("ldo_vgp3", VGP3, ldo_volt_table7,
+		MT6323_DIGLDO_CON9, 15, MT6323_DIGLDO_CON30, 0x60,
+		MT6323_DIGLDO_CON9, 0x2),
+	MT6323_REG_FIXED("ldo_vcn18", VCN18, MT6323_DIGLDO_CON11, 14, 1800000,
+		MT6323_DIGLDO_CON11, 0x2),
+	MT6323_LDO("ldo_vsim1", VSIM1, ldo_volt_table8,
+		MT6323_DIGLDO_CON13, 15, MT6323_DIGLDO_CON34, 0x20,
+		MT6323_DIGLDO_CON13, 0x2),
+	MT6323_LDO("ldo_vsim2", VSIM2, ldo_volt_table8,
+		MT6323_DIGLDO_CON14, 15, MT6323_DIGLDO_CON35, 0x20,
+		MT6323_DIGLDO_CON14, 0x2),
+	MT6323_REG_FIXED("ldo_vrtc", VRTC, MT6323_DIGLDO_CON15, 8, 2800000,
+		-1, 0),
+	MT6323_LDO("ldo_vcamaf", VCAMAF, ldo_volt_table5,
+		MT6323_DIGLDO_CON31, 15, MT6323_DIGLDO_CON32, 0xE0,
+		MT6323_DIGLDO_CON31, 0x2),
+	MT6323_LDO("ldo_vibr", VIBR, ldo_volt_table5,
+		MT6323_DIGLDO_CON39, 15, MT6323_DIGLDO_CON40, 0xE0,
+		MT6323_DIGLDO_CON39, 0x2),
+	MT6323_REG_FIXED("ldo_vrf18", VRF18, MT6323_DIGLDO_CON45, 15, 1825000,
+		MT6323_DIGLDO_CON45, 0x2),
+	MT6323_LDO("ldo_vm", VM, ldo_volt_table9,
+		MT6323_DIGLDO_CON47, 14, MT6323_DIGLDO_CON48, 0x30,
+		MT6323_DIGLDO_CON47, 0x2),
+	MT6323_REG_FIXED("ldo_vio18", VIO18, MT6323_DIGLDO_CON49, 14, 1800000,
+		MT6323_DIGLDO_CON49, 0x2),
+	MT6323_LDO("ldo_vcamd", VCAMD, ldo_volt_table10,
+		MT6323_DIGLDO_CON51, 14, MT6323_DIGLDO_CON52, 0x60,
+		MT6323_DIGLDO_CON51, 0x2),
+	MT6323_REG_FIXED("ldo_vcamio", VCAMIO, MT6323_DIGLDO_CON53, 14, 1800000,
+		MT6323_DIGLDO_CON53, 0x2),
+};
+
+static int mt6323_set_buck_vosel_reg(struct platform_device *pdev)
+{
+	struct mt6397_chip *mt6323 = dev_get_drvdata(pdev->dev.parent);
+	int i;
+	u32 regval;
+
+	for (i = 0; i < MT6323_MAX_REGULATOR; i++) {
+		if (mt6323_regulators[i].vselctrl_reg) {
+			if (regmap_read(mt6323->regmap,
+				mt6323_regulators[i].vselctrl_reg,
+				&regval) < 0) {
+				dev_err(&pdev->dev,
+					"Failed to read buck ctrl\n");
+				return -EIO;
+			}
+
+			if (regval & mt6323_regulators[i].vselctrl_mask) {
+				mt6323_regulators[i].desc.vsel_reg =
+				mt6323_regulators[i].vselon_reg;
+			}
+		}
+	}
+
+	return 0;
+}
+
+static int mt6323_regulator_probe(struct platform_device *pdev)
+{
+	struct mt6397_chip *mt6323 = dev_get_drvdata(pdev->dev.parent);
+	struct regulator_config config = {};
+	struct regulator_dev *rdev;
+	int i;
+	u32 reg_value;
+
+	/* Query buck controller to select activated voltage register part */
+	if (mt6323_set_buck_vosel_reg(pdev))
+		return -EIO;
+
+	/* Read PMIC chip revision to update constraints and voltage table */
+	if (regmap_read(mt6323->regmap, MT6323_CID, &reg_value) < 0) {
+		dev_err(&pdev->dev, "Failed to read Chip ID\n");
+		return -EIO;
+	}
+	dev_info(&pdev->dev, "Chip ID = 0x%x\n", reg_value);
+
+	for (i = 0; i < MT6323_MAX_REGULATOR; i++) {
+		config.dev = &pdev->dev;
+		config.driver_data = &mt6323_regulators[i];
+		config.regmap = mt6323->regmap;
+		rdev = devm_regulator_register(&pdev->dev,
+				&mt6323_regulators[i].desc, &config);
+		if (IS_ERR(rdev)) {
+			dev_err(&pdev->dev, "failed to register %s\n",
+				mt6323_regulators[i].desc.name);
+			return PTR_ERR(rdev);
+		}
+	}
+	return 0;
+}
+
+static const struct platform_device_id mt6323_platform_ids[] = {
+	{"mt6323-regulator", 0},
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(platform, mt6323_platform_ids);
+
+static const struct of_device_id mt6323_of_match[] = {
+	{ .compatible = "mediatek,mt6323-regulator", },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mt6323_of_match);
+
+static struct platform_driver mt6323_regulator_driver = {
+	.driver = {
+		.name = "mt6323-regulator",
+		.of_match_table = of_match_ptr(mt6323_of_match),
+	},
+	.probe = mt6323_regulator_probe,
+	.id_table = mt6323_platform_ids,
+};
+
+module_platform_driver(mt6323_regulator_driver);
+
+MODULE_AUTHOR("Chen Zhong <chen.zhong at mediatek.com>");
+MODULE_DESCRIPTION("Regulator Driver for MediaTek MT6397 PMIC");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/regulator/mt6323-regulator.h b/include/linux/regulator/mt6323-regulator.h
new file mode 100644
index 0000000..67011cd
--- /dev/null
+++ b/include/linux/regulator/mt6323-regulator.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Chen Zhong <chen.zhong at mediatek.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.
+ */
+
+#ifndef __LINUX_REGULATOR_MT6323_H
+#define __LINUX_REGULATOR_MT6323_H
+
+enum {
+	MT6323_ID_VPROC = 0,
+	MT6323_ID_VSYS,
+	MT6323_ID_VPA,
+	MT6323_ID_VTCXO,
+	MT6323_ID_VCN28,
+	MT6323_ID_VCN33_BT,
+	MT6323_ID_VCN33_WIFI,
+	MT6323_ID_VA,
+	MT6323_ID_VCAMA,
+	MT6323_ID_VIO28 = 9,
+	MT6323_ID_VUSB,
+	MT6323_ID_VMC,
+	MT6323_ID_VMCH,
+	MT6323_ID_VEMC3V3,
+	MT6323_ID_VGP1,
+	MT6323_ID_VGP2,
+	MT6323_ID_VGP3,
+	MT6323_ID_VCN18,
+	MT6323_ID_VSIM1,
+	MT6323_ID_VSIM2,
+	MT6323_ID_VRTC,
+	MT6323_ID_VCAMAF,
+	MT6323_ID_VIBR,
+	MT6323_ID_VRF18,
+	MT6323_ID_VM,
+	MT6323_ID_VIO18,
+	MT6323_ID_VCAMD,
+	MT6323_ID_VCAMIO,
+	MT6323_ID_RG_MAX,
+};
+
+#define MT6323_MAX_REGULATOR	MT6323_ID_RG_MAX
+
+#endif /* __LINUX_REGULATOR_MT6323_H */
-- 
1.7.10.4


From s.trumtrar at pengutronix.de  Thu Feb 25 02:38:20 2016
From: s.trumtrar at pengutronix.de (Steffen Trumtrar)
Date: Thu, 25 Feb 2016 11:38:20 +0100
Subject: [PATCH v2] dts: add specific compatible type for Terasic
 DE0-NANO-SoC  Board
In-Reply-To: <2186741.ZYdHdfu2ug@dabox>
References: <8416439.76b9YNhpgR@dabox>
 <alpine.DEB.2.02.1602241048100.3815@linux-builds1>
 <2186741.ZYdHdfu2ug@dabox>
Message-ID: <20160225103820.GB747@pengutronix.de>

Hi Tim!

On Thu, Feb 25, 2016 at 11:05:05AM +0100, Tim Sander wrote:
> From: Tim Sander <tim at krieglstein.org>
> 
> Add a more specific compatible string:"terasic,de0-nano-soc" for respective board.
> Background: when checking for bootspec entries, some board specific fixups are
> not apropriate for board of the same platform ("altr,socfpga-cyclone5").
> The same aproach is taken with the EBV-Socrates board.
> 
> Signed-off-by: Tim Sander <tim at krieglstein.org>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts     | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 72e2c5a..d1f7803 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -230,6 +230,7 @@ synology	Synology, Inc.
>  tbs	TBS Technologies
>  tcl	Toby Churchill Ltd.
>  technologic	Technologic Systems
> +terasic	Terasic Inc.
>  thine	THine Electronics, Inc.
>  ti	Texas Instruments
>  tlm	Trusted Logic Mobility

You should IMHO split this up in two patches.
First patch: add terasic

> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
> index afea364..704aa9d 100644
> --- a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
> +++ b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
> @@ -18,7 +18,7 @@
>  
>  / {
>  	model = "Terasic DE-0(Atlas)";
> -	compatible = "altr,socfpga-cyclone5", "altr,socfpga";
> +	compatible = "terasic,de0-nano-soc","altr,socfpga-cyclone5", "altr,socfpga";

Second patch: this.

>  
>  	chosen {
>  		bootargs = "earlyprintk";

The naming of this board still confuses me though.
It has 3 different names now:

	- de0_sockit.dts
	- Terasic DE-0(Atlas)
	- de0-nano-soc

And according to Terasic DE0-Nano-SoC is the same as Atlas-SoC with a different software?!
So all three names are actually correct ?! Weird.

Regards,
Steffen

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


From w at 1wt.eu  Thu Feb 25 02:40:40 2016
From: w at 1wt.eu (Willy Tarreau)
Date: Thu, 25 Feb 2016 11:40:40 +0100
Subject: [PATCH 1/2] ARM: mvebu: change order of ethernet DT nodes on
 Armada 38x
In-Reply-To: <20160225113137.317ac08f@free-electrons.com>
References: <1453907300-28283-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1453907300-28283-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160127193143.GF10826@n2100.arm.linux.org.uk>
 <20160127194512.GA16638@1wt.eu>
 <20160129114853.GQ10826@n2100.arm.linux.org.uk>
 <20160224184114.GB2292@1wt.eu> <20160225113137.317ac08f@free-electrons.com>
Message-ID: <20160225104040.GB2542@1wt.eu>

Hi Thomas,

On Thu, Feb 25, 2016 at 11:31:37AM +0100, Thomas Petazzoni wrote:
> My patch has already been applied by the mvebu maintainers in
> the mvebu/dt branch:
> http://git.infradead.org/linux-mvebu.git/commit/cb4f71c4298853db0c6751b1209e4535956f136c.

Ah thanks, I didn't notice!

Best regards,
willy



From georgi.djakov at linaro.org  Thu Feb 25 02:46:31 2016
From: georgi.djakov at linaro.org (Georgi Djakov)
Date: Thu, 25 Feb 2016 12:46:31 +0200
Subject: [PATCH v3 1/2] arm64: defconfig: Add Qualcomm sdhci and restart
 functionality
Message-ID: <1456397192-2407-1-git-send-email-georgi.djakov@linaro.org>

Enable sdhci and restart functionality for devices based on msm8916 platform.

Signed-off-by: Georgi Djakov <georgi.djakov at linaro.org>
---
Changes since v2:
 * Move the MMC_BLOCK_MINORS change into a separate patch.

Changes since v1:
 * Rebased onto arm-soc/next/arm64

 arch/arm64/configs/defconfig |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 774e51fda7fa..47b5dac96bfc 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -153,6 +153,7 @@ CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
 CONFIG_GPIO_PL061=y
 CONFIG_GPIO_RCAR=y
 CONFIG_GPIO_XGENE=y
+CONFIG_POWER_RESET_MSM=y
 CONFIG_POWER_RESET_XGENE=y
 CONFIG_POWER_RESET_SYSCON=y
 # CONFIG_HWMON is not set
@@ -195,6 +196,7 @@ CONFIG_MMC_ARMMMCI=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_SDHCI_TEGRA=y
+CONFIG_MMC_SDHCI_MSM=y
 CONFIG_MMC_SPI=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_EXYNOS=y


From georgi.djakov at linaro.org  Thu Feb 25 02:46:32 2016
From: georgi.djakov at linaro.org (Georgi Djakov)
Date: Thu, 25 Feb 2016 12:46:32 +0200
Subject: [PATCH v3 2/2] arm64: defconfig: Increase MMC_BLOCK_MINORS to 16
In-Reply-To: <1456397192-2407-1-git-send-email-georgi.djakov@linaro.org>
References: <1456397192-2407-1-git-send-email-georgi.djakov@linaro.org>
Message-ID: <1456397192-2407-2-git-send-email-georgi.djakov@linaro.org>

Increase the block minors from the default 8 to 16. The db410c board
by default has eMMC rootfs on the 10th partition.

Signed-off-by: Georgi Djakov <georgi.djakov at linaro.org>
---
 arch/arm64/configs/defconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 47b5dac96bfc..7787e4031a75 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -192,6 +192,7 @@ CONFIG_USB_MSM_OTG=y
 CONFIG_USB_ULPI=y
 CONFIG_USB_GADGET=y
 CONFIG_MMC=y
+CONFIG_MMC_BLOCK_MINORS=16
 CONFIG_MMC_ARMMMCI=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y


From will.deacon at arm.com  Thu Feb 25 02:48:18 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Feb 2016 10:48:18 +0000
Subject: [PATCH v13 01/20] ARM64: Move PMU register related defines to
 asm/perf_event.h
In-Reply-To: <56CE6098.8070001@huawei.com>
References: <1456290520-10012-1-git-send-email-zhaoshenglong@huawei.com>
 <1456290520-10012-2-git-send-email-zhaoshenglong@huawei.com>
 <20160224175247.GE12471@arm.com> <56CE6098.8070001@huawei.com>
Message-ID: <20160225104818.GB12784@arm.com>

On Thu, Feb 25, 2016 at 10:02:00AM +0800, Shannon Zhao wrote:
> On 2016/2/25 1:52, Will Deacon wrote:
> > On Wed, Feb 24, 2016 at 01:08:21PM +0800, Shannon Zhao wrote:
> >> From: Shannon Zhao <shannon.zhao at linaro.org>
> >>
> >> To use the ARMv8 PMU related register defines from the KVM code, we move
> >> the relevant definitions to asm/perf_event.h header file and rename them
> >> with prefix ARMV8_PMU_.
> >>
> >> Signed-off-by: Anup Patel <anup.patel at linaro.org>
> >> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> >> Acked-by: Marc Zyngier <marc.zyngier at arm.com>
> >> Reviewed-by: Andrew Jones <drjones at redhat.com>
> >> ---
> >>  arch/arm64/include/asm/perf_event.h | 35 +++++++++++++++++++
> >>  arch/arm64/kernel/perf_event.c      | 68 ++++++++++---------------------------
> >>  2 files changed, 52 insertions(+), 51 deletions(-)
> > 
> > Looks fine to me, but we're going to get some truly horrible conflicts
> > in -next.
> > 
> > I'm open to suggestions on the best way to handle this, but one way
> > would be:
> > 
> >   1. Duplicate all the #defines privately in KVM (queue via kvm tree)
> This way seems not proper I think.
> 
> >   2. Rebase this patch onto my perf/updates branch [1] (queue via me)
> While to this series, it really relies on the perf_event.h to compile
> and test, so maybe for KVM-ARM and KVM maintainers it's not proper.
> 
> >   3. Patch at -rc1 dropping the #defines from (1) and moving to the new
> >      perf_event.h stuff
> > 
> I vote for this way. Since the patch in [1] is small and nothing else
> relies on them, I think it would be simple to rebase them onto this series.

That was supposed to be a sequence of actions... :/

> > Thoughts?
> > 
> Anyway, there are only 3 lines which have conflicts. I'm not sure
> whether we could handle this when we merge them.

I think we're looking at different conflicts. I resolved it (see below),
but I'd really rather this didn't happen at the point where perf/updates
hits kvm-arm (i.e. torvalds).

Will

--->8

diff --cc arch/arm64/kernel/perf_event.c
index 1cc61fc321d9,212c9fc44141..000000000000
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@@ -776,11 -684,8 +741,12 @@@ static void armv8pmu_reset(void *info
                armv8pmu_disable_intens(idx);
        }
  
 -      /* Initialize & Reset PMNC: C and P bits. */
 -      armv8pmu_pmcr_write(ARMV8_PMU_PMCR_P | ARMV8_PMU_PMCR_C);
 +      /*
 +       * Initialize & Reset PMNC. Request overflow interrupt for
 +       * 64 bit cycle counter but cheat in armv8pmu_write_counter().
 +       */
-       armv8pmu_pmcr_write(ARMV8_PMCR_P | ARMV8_PMCR_C | ARMV8_PMCR_LC);
++      armv8pmu_pmcr_write(ARMV8_PMU_PMCR_P | ARMV8_PMU_PMCR_C |
++                          ARMV8_PMU_PMCR_LC);
  }
  
  static int armv8_pmuv3_map_event(struct perf_event *event)
@@@ -801,16 -706,9 +767,16 @@@ static int armv8_a57_map_event(struct p
  {
        return armpmu_map_event(event, &armv8_a57_perf_map,
                                &armv8_a57_perf_cache_map,
-                               ARMV8_EVTYPE_EVENT);
+                               ARMV8_PMU_EVTYPE_EVENT);
  }
  
 +static int armv8_thunder_map_event(struct perf_event *event)
 +{
 +      return armpmu_map_event(event, &armv8_thunder_perf_map,
 +                              &armv8_thunder_perf_cache_map,
-                               ARMV8_EVTYPE_EVENT);
++                              ARMV8_PMU_EVTYPE_EVENT);
 +}
 +
  static void armv8pmu_read_num_pmnc_events(void *info)
  {
        int *nb_cnt = info;
diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
index 5c77ef8bf5b5..152ad9cb9bb0 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -29,6 +29,7 @@
 #define ARMV8_PMU_PMCR_D       (1 << 3) /* CCNT counts every 64th cpu cycle */
 #define ARMV8_PMU_PMCR_X       (1 << 4) /* Export to ETM */
 #define ARMV8_PMU_PMCR_DP      (1 << 5) /* Disable CCNT if non-invasive debug*/
+#define ARMV8_PMU_PMCR_LC      (1 << 6) /* Overflow on 64 bit cycle counter */
 #define        ARMV8_PMU_PMCR_N_SHIFT  11       /* Number of counters supported */
 #define        ARMV8_PMU_PMCR_N_MASK   0x1f
 #define        ARMV8_PMU_PMCR_MASK     0x3f     /* Mask for writable bits */
@@ -42,8 +43,8 @@
 /*
  * PMXEVTYPER: Event selection reg
  */
-#define        ARMV8_PMU_EVTYPE_MASK   0xc80003ff      /* Mask for writable bits */
-#define        ARMV8_PMU_EVTYPE_EVENT  0x3ff           /* Mask for EVENT bits */
+#define        ARMV8_PMU_EVTYPE_MASK   0xc800ffff      /* Mask for writable bits */
+#define        ARMV8_PMU_EVTYPE_EVENT  0xffff          /* Mask for EVENT bits */
 
 /*
  * Event filters for PMUv3



From schwab at suse.de  Thu Feb 25 02:50:31 2016
From: schwab at suse.de (Andreas Schwab)
Date: Thu, 25 Feb 2016 11:50:31 +0100
Subject: [RFC5 PATCH v6 00/21] ILP32 for ARM64
In-Reply-To: <20160218223506.GA7816@yury-N73SV> (Yury Norov's message of "Fri, 
 19 Feb 2016 01:35:06 +0300")
References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com>
 <56AB3805.1040308@huawei.com> <20160129170929.GA3543@yury-N73SV>
 <56AC38F1.2030608@huawei.com> <20160218223506.GA7816@yury-N73SV>
Message-ID: <mvm8u29ukqw.fsf@hawking.suse.de>

Yury Norov <ynorov at caviumnetworks.com> writes:

> I have new glibc that follows new ABI:
> https://github.com/norov/glibc/tree/new-api

sysdeps/unix/sysv/linux/aarch64/ilp32/getdents64.c is wrong, struct
dirent64 is not the same as struct dirent.  The file needs to be renamed
to sysdeps/unix/sysv/linux/aarch64/ilp32/getdents.c so that __getdents64
comes from sysdeps/unix/sysv/linux/generic/getdents64.c.

sysdeps/unix/sysv/linux/aarch64/ilp32/*xstat*.c should not set errno,
INLINE_SYSCALL already does that, and returns -1 on error.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."


From rrichter at caviumnetworks.com  Thu Feb 25 03:02:42 2016
From: rrichter at caviumnetworks.com (Robert Richter)
Date: Thu, 25 Feb 2016 12:02:42 +0100
Subject: [PATCH 0/2] arm64, cma,
 gicv3-its: Use CMA for allocation of large device tables
Message-ID: <1456398164-16864-1-git-send-email-rrichter@caviumnetworks.com>

From: Robert Richter <rrichter at cavium.com>

This series implements the use of CMA for allocation of large device
tables for the arm64 gicv3 interrupt controller.

There are 2 patches, the first is for early activation of cma, which
needs to be done before interrupt initialization to make it available
to the gicv3. The second implements the use of CMA to allocate
gicv3-its device tables.

This solves the problem where mem allocation is limited to 4MB. A
previous patch sent to the list to address this that instead increases
FORCE_MAX_ZONEORDER becomes obsolete.

Robert Richter (2):
  mm: cma: arm64: Introduce dma_activate_contiguous() for early
    activation
  irqchip, gicv3-its, cma: Use CMA for allocation of large device tables

 arch/arm64/kernel/irq.c          |  4 ++++
 drivers/base/dma-contiguous.c    | 14 ++++++++++++++
 drivers/irqchip/irq-gic-v3-its.c | 30 +++++++++++++++++++++---------
 include/linux/cma.h              |  1 +
 include/linux/dma-contiguous.h   |  8 ++++++++
 mm/cma.c                         |  6 +++++-
 6 files changed, 53 insertions(+), 10 deletions(-)

-- 
2.7.0.rc3



From rrichter at caviumnetworks.com  Thu Feb 25 03:02:43 2016
From: rrichter at caviumnetworks.com (Robert Richter)
Date: Thu, 25 Feb 2016 12:02:43 +0100
Subject: [PATCH 1/2] mm: cma: arm64: Introduce dma_activate_contiguous() for
 early activation
In-Reply-To: <1456398164-16864-1-git-send-email-rrichter@caviumnetworks.com>
References: <1456398164-16864-1-git-send-email-rrichter@caviumnetworks.com>
Message-ID: <1456398164-16864-2-git-send-email-rrichter@caviumnetworks.com>

From: Robert Richter <rrichter at cavium.com>

For the arm64 gicv3 interrupt controller we need CMA to allocate large
blocks of physically contiguous memory. Usually page_alloc() is
limited by 2^(MAX_ORDER - 1), which is typically 4MB at 4k pagesize.
A current gicv3-its device table may have a size of up to 16MB.

Since the interrupt controller is initialized before other subsystems
(initcall functions), current dma activation (core_initcall) is too
late and makes it unusable for gicv3. On the other side, it is
generally possible to activate dma alloc right after the kernel's
memory initialization.

Now, this patch implements dma_activate_contiguous() to allow
architectures to enable dma alloc earlier. It also enables early dma
activation for the arm64 subsystem directly before interrupt
initialization and thus makes CMA usable for gicv3's memory
allocation.

Signed-off-by: Robert Richter <rrichter at cavium.com>
---
 arch/arm64/kernel/irq.c        |  4 ++++
 drivers/base/dma-contiguous.c  | 14 ++++++++++++++
 include/linux/cma.h            |  1 +
 include/linux/dma-contiguous.h |  8 ++++++++
 mm/cma.c                       |  6 +++++-
 5 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 9f17ec071ee0..913b32021f50 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -27,6 +27,7 @@
 #include <linux/init.h>
 #include <linux/irqchip.h>
 #include <linux/seq_file.h>
+#include <linux/dma-contiguous.h>
 
 unsigned long irq_err_count;
 
@@ -49,6 +50,9 @@ void __init set_handle_irq(void (*handle_irq)(struct pt_regs *))
 
 void __init init_IRQ(void)
 {
+	/* early activate cma since some gic controllers need it */
+	dma_activate_contiguous();
+
 	irqchip_init();
 	if (!handle_arch_irq)
 		panic("No interrupt controller found.");
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index e167a1e1bccb..1c73d4899e8d 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -212,6 +212,20 @@ bool dma_release_from_contiguous(struct device *dev, struct page *pages,
 	return cma_release(dev_get_cma_area(dev), pages, count);
 }
 
+/**
+ * dma_activate_contiguous() - activate reserved areas for contiguous
+ *			       memory handling
+ *
+ * This function enables contiguous memory allocation. It can be used
+ * by archs for early initialization right after the kernel memory
+ * subsystem (like slab allocator) is available and if the
+ * core_initcall for it is too late.
+ */
+int __init dma_activate_contiguous(void)
+{
+	return cma_init_reserved_areas();
+}
+
 /*
  * Support for reserved memory regions defined in device tree
  */
diff --git a/include/linux/cma.h b/include/linux/cma.h
index 29f9e774ab76..c2ab619769e6 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -23,6 +23,7 @@ extern int __init cma_declare_contiguous(phys_addr_t base,
 			phys_addr_t size, phys_addr_t limit,
 			phys_addr_t alignment, unsigned int order_per_bit,
 			bool fixed, struct cma **res_cma);
+extern int __init cma_init_reserved_areas(void);
 extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
 					unsigned int order_per_bit,
 					struct cma **res_cma);
diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index fec734df1524..07d542b8bb4d 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -111,6 +111,8 @@ static inline int dma_declare_contiguous(struct device *dev, phys_addr_t size,
 	return ret;
 }
 
+int __init dma_activate_contiguous(void);
+
 struct page *dma_alloc_from_contiguous(struct device *dev, size_t count,
 				       unsigned int order);
 bool dma_release_from_contiguous(struct device *dev, struct page *pages,
@@ -157,6 +159,12 @@ bool dma_release_from_contiguous(struct device *dev, struct page *pages,
 	return false;
 }
 
+static inline
+int dma_activate_contiguous(void)
+{
+	return -ENOSYS;
+}
+
 #endif
 
 #endif
diff --git a/mm/cma.c b/mm/cma.c
index ea506eb18cd6..be1f55782c25 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -142,10 +142,14 @@ static int __init cma_activate_area(struct cma *cma)
 	return -EINVAL;
 }
 
-static int __init cma_init_reserved_areas(void)
+int __init cma_init_reserved_areas(void)
 {
 	int i;
 
+	if (cma_area_count && cma_areas[0].bitmap)
+		/* Already activated */
+		return 0;
+
 	for (i = 0; i < cma_area_count; i++) {
 		int ret = cma_activate_area(&cma_areas[i]);
 
-- 
2.7.0.rc3



From rrichter at caviumnetworks.com  Thu Feb 25 03:02:44 2016
From: rrichter at caviumnetworks.com (Robert Richter)
Date: Thu, 25 Feb 2016 12:02:44 +0100
Subject: [PATCH 2/2] irqchip, gicv3-its,
 cma: Use CMA for allocation of large device tables
In-Reply-To: <1456398164-16864-1-git-send-email-rrichter@caviumnetworks.com>
References: <1456398164-16864-1-git-send-email-rrichter@caviumnetworks.com>
Message-ID: <1456398164-16864-3-git-send-email-rrichter@caviumnetworks.com>

From: Robert Richter <rrichter at cavium.com>

The gicv3-its device table may have a size of up to 16MB. With 4k
pagesize the maximum size of memory allocation is 4MB. Use CMA for
allocation of large tables.

Signed-off-by: Robert Richter <rrichter at cavium.com>
---
 drivers/irqchip/irq-gic-v3-its.c | 30 +++++++++++++++++++++---------
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 443ba8892f6f..c8914026d0e4 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -19,6 +19,7 @@
 #include <linux/bitmap.h>
 #include <linux/cpu.h>
 #include <linux/delay.h>
+#include <linux/dma-contiguous.h>
 #include <linux/interrupt.h>
 #include <linux/irqdomain.h>
 #include <linux/iort.h>
@@ -860,6 +861,7 @@ static int its_alloc_tables(struct its_node *its)
 		int alloc_pages;
 		u64 tmp;
 		void *base;
+		struct page *page;
 
 		if (type == GITS_BASER_TYPE_NONE)
 			continue;
@@ -881,13 +883,8 @@ static int its_alloc_tables(struct its_node *its)
 			 */
 			order = max(get_order((1UL << ids) * entry_size),
 				    order);
-			if (order >= MAX_ORDER) {
-				order = MAX_ORDER - 1;
-				pr_warn("ITS at 0x%lx: Device Table too large, reduce its page order to %u\n",
-					its->phys_base, order);
-			}
 		}
-
+retry_alloc:
 		alloc_size = (1 << order) * PAGE_SIZE;
 		alloc_pages = (alloc_size / psz);
 		if (alloc_pages > GITS_BASER_PAGES_MAX) {
@@ -897,8 +894,22 @@ static int its_alloc_tables(struct its_node *its)
 				its->phys_base, order, alloc_pages);
 		}
 
-		base = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
+		if (order >= MAX_ORDER) {
+			page = dma_alloc_from_contiguous(NULL, 1 << order, 0);
+			base = page ? page_address(page) : NULL;
+			if (!base) {
+				order = MAX_ORDER - 1;
+				pr_warn("ITS at 0x%lx: Device table too large, reduce its page order to %u\n",
+					its->phys_base, order);
+				goto retry_alloc;
+			}
+		} else {
+			base = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
+		}
+
 		if (!base) {
+			pr_err("ITS at 0x%lx: Failed to allocate device table\n",
+				its->phys_base);
 			err = -ENOMEM;
 			goto out_free;
 		}
@@ -970,11 +981,12 @@ static int its_alloc_tables(struct its_node *its)
 			goto out_free;
 		}
 
-		pr_info("ITS: allocated %d %s @%lx (psz %dK, shr %d)\n",
+		pr_info("ITS: allocated %d %s @%lx (psz %dK, shr %d)%s\n",
 			(int)(alloc_size / entry_size),
 			its_base_type_string[type],
 			(unsigned long)virt_to_phys(base),
-			psz / SZ_1K, (int)shr >> GITS_BASER_SHAREABILITY_SHIFT);
+			psz / SZ_1K, (int)shr >> GITS_BASER_SHAREABILITY_SHIFT,
+			order >= MAX_ORDER ? " using CMA" : "");
 	}
 
 	return 0;
-- 
2.7.0.rc3



From srinivas.kandagatla at linaro.org  Thu Feb 25 03:21:56 2016
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Thu, 25 Feb 2016 11:21:56 +0000
Subject: [PATCH v3 6/8] arm64: dts: qcom: fix usb digital voltage levels
In-Reply-To: <56CE3780.5060408@codeaurora.org>
References: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
 <1456246236-18341-1-git-send-email-srinivas.kandagatla@linaro.org>
 <56CE3780.5060408@codeaurora.org>
Message-ID: <56CEE3D4.3030407@linaro.org>



On 24/02/16 23:06, Stephen Boyd wrote:
> On 02/23/2016 08:50 AM, Srinivas Kandagatla wrote:
>> This patch updates the digital voltage levels from corner values to
>> microvolts as we are going to use s1 regulator directly for vddcx
>> instead of s1_corner.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
>> ---
>
> What's the plan for corners? Maybe we should remove the voltage setting
> from the usb driver or drop the usb node entirely on msm8916 until we
> resolve how we're going to handle corners. I'd like to avoid getting
> stuck into some DT binding ABI mess here.

Andy/Bjorn, any comments on plans on corner regulators?

Please note, that this is a patch to fix what is already in the 
mainline. Without this patch the regulator would be configured with 1uV 
or 5uV or 7uV which would obviously fail.

THB, it does not make sense to drop feature which is functional, and I 
also agree that we should cleanup some of this mess at some point in 
time once we all the bits and pieces ready.

I was surprised to see these usb bindings(qcom,vdd-levels) existed even 
before we had concept of corner regulators in mainline kernel. Which 
also suggests that this driver needs a proper relook once again.

Thanks,
srini


From m.grzeschik at pengutronix.de  Thu Feb 25 03:24:00 2016
From: m.grzeschik at pengutronix.de (Michael Grzeschik)
Date: Thu, 25 Feb 2016 12:24:00 +0100
Subject: [PATCH v2 2/2] ARM: mxs_defconfig: Enable initramfs support
In-Reply-To: <1456399440-3646-1-git-send-email-m.grzeschik@pengutronix.de>
References: <1456399440-3646-1-git-send-email-m.grzeschik@pengutronix.de>
Message-ID: <1456399440-3646-2-git-send-email-m.grzeschik@pengutronix.de>

From: Jan Luebbe <jlu at pengutronix.de>

This makes it possible to automatically boot-test this defconfig with
kernelci.org.

Signed-off-by: Jan Luebbe <jlu at pengutronix.de>
Signed-off-by: Michael Grzeschik <m.grzeschik at pengutronix.de>
---
 arch/arm/configs/mxs_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/mxs_defconfig b/arch/arm/configs/mxs_defconfig
index 3bd7cad..6c2550e 100644
--- a/arch/arm/configs/mxs_defconfig
+++ b/arch/arm/configs/mxs_defconfig
@@ -12,6 +12,7 @@ CONFIG_IKCONFIG_PROC=y
 # CONFIG_IPC_NS is not set
 # CONFIG_PID_NS is not set
 # CONFIG_NET_NS is not set
+CONFIG_BLK_DEV_INITRD=y
 CONFIG_PERF_EVENTS=y
 # CONFIG_COMPAT_BRK is not set
 CONFIG_MODULES=y
-- 
2.7.0



From m.grzeschik at pengutronix.de  Thu Feb 25 03:23:59 2016
From: m.grzeschik at pengutronix.de (Michael Grzeschik)
Date: Thu, 25 Feb 2016 12:23:59 +0100
Subject: [PATCH v2 1/2] ARM: mxs_defconfig: Cleanup mxs_defconfig
Message-ID: <1456399440-3646-1-git-send-email-m.grzeschik@pengutronix.de>

From: Jan Luebbe <jlu at pengutronix.de>

Regenerate mxs_defconfig by running:
make mxs_defconfig
- Manually disable EXT2_FS and EXT3_FS
make savedefconfig
mv defconfig arch/arm/configs/mxs_defconfig

Signed-off-by: Jan Luebbe <jlu at pengutronix.de>
Signed-off-by: Michael Grzeschik <m.grzeschik at pengutronix.de>
---
v2: Disabled EXT2_FS and EXT3_FS instead of EXT4_FS

 arch/arm/configs/mxs_defconfig | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/configs/mxs_defconfig b/arch/arm/configs/mxs_defconfig
index b47e7c6..3bd7cad 100644
--- a/arch/arm/configs/mxs_defconfig
+++ b/arch/arm/configs/mxs_defconfig
@@ -141,9 +141,6 @@ CONFIG_IIO=y
 CONFIG_IIO_SYSFS_TRIGGER=y
 CONFIG_PWM=y
 CONFIG_PWM_MXS=y
-CONFIG_EXT2_FS=y
-CONFIG_EXT2_FS_XATTR=y
-CONFIG_EXT3_FS=y
 CONFIG_EXT4_FS=y
 # CONFIG_DNOTIFY is not set
 CONFIG_FSCACHE=m
@@ -178,7 +175,6 @@ CONFIG_PROVE_LOCKING=y
 CONFIG_BLK_DEV_IO_TRACE=y
 CONFIG_STRICT_DEVMEM=y
 CONFIG_DEBUG_USER=y
-# CONFIG_CRYPTO_ANSI_CPRNG is not set
 CONFIG_CRYPTO_DEV_MXS_DCP=y
 CONFIG_CRC_ITU_T=m
 CONFIG_CRC7=m
-- 
2.7.0



From arnd at arndb.de  Thu Feb 25 03:37:40 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 12:37:40 +0100
Subject: [PATCH] spi: lp-8841: return correct error code from probe
Message-ID: <1456400265-3068525-1-git-send-email-arnd@arndb.de>

The spi_lp8841_rtc_probe() function misses an initialization of the
return code when it fails to get its memory resource, as gcc notices:

drivers/spi/spi-lp8841-rtc.c: In function 'spi_lp8841_rtc_probe':
drivers/spi/spi-lp8841-rtc.c:239:9: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This changes the code to propagate the error from devm_ioremap_resource().

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 7ecbfff6711f ("spi: master driver to enable RTC on ICPDAS LP-8841")
---
 drivers/spi/spi-lp8841-rtc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-lp8841-rtc.c b/drivers/spi/spi-lp8841-rtc.c
index 44bb69c3f1d6..faa577d282c0 100644
--- a/drivers/spi/spi-lp8841-rtc.c
+++ b/drivers/spi/spi-lp8841-rtc.c
@@ -217,8 +217,9 @@ spi_lp8841_rtc_probe(struct platform_device *pdev)
 	data = spi_master_get_devdata(master);
 
 	iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	data->iomem =  devm_ioremap_resource(&pdev->dev, iomem);
-	if (IS_ERR(data->iomem)) {
+	data->iomem = devm_ioremap_resource(&pdev->dev, iomem);
+	ret = PTR_ERR_OR_ZERO(data->iomem);
+	if (ret) {
 		dev_err(&pdev->dev, "failed to get IO address\n");
 		goto err_put_master;
 	}
-- 
2.7.0



From heikki.krogerus at linux.intel.com  Thu Feb 25 03:42:06 2016
From: heikki.krogerus at linux.intel.com (Heikki Krogerus)
Date: Thu, 25 Feb 2016 13:42:06 +0200
Subject: [PATCH 11/50] pinctrl: cherryview: Use devm_pinctrl_register()
 for pinctrl registration
In-Reply-To: <1456319775-3216-12-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-12-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160225114206.GA29434@kuha.fi.intel.com>

Hi,

On Wed, Feb 24, 2016 at 06:45:36PM +0530, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Mika Westerberg <mika.westerberg at linux.intel.com>
> Cc: Heikki Krogerus <heikki.krogerus at linux.intel.com>
> ---
>  drivers/pinctrl/intel/pinctrl-cherryview.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c b/drivers/pinctrl/intel/pinctrl-cherryview.c
> index 4251e07..1152b8a 100644
> --- a/drivers/pinctrl/intel/pinctrl-cherryview.c
> +++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
> @@ -1526,7 +1526,8 @@ static int chv_pinctrl_probe(struct platform_device *pdev)
>  	pctrl->pctldesc.pins = pctrl->community->pins;
>  	pctrl->pctldesc.npins = pctrl->community->npins;
>  
> -	pctrl->pctldev = pinctrl_register(&pctrl->pctldesc, &pdev->dev, pctrl);
> +	pctrl->pctldev = devm_pinctrl_register(&pdev->dev, &pctrl->pctldesc,
> +					       pctrl);
>  	if (IS_ERR(pctrl->pctldev)) {
>  		dev_err(&pdev->dev, "failed to register pinctrl driver\n");
>  		return PTR_ERR(pctrl->pctldev);

You missed one pinctrl_unregister() call inside chv_pinctrl_probe().
Check right below this point where chv_gpio_probe() is called.

> @@ -1548,7 +1549,6 @@ static int chv_pinctrl_remove(struct platform_device *pdev)
>  	struct chv_pinctrl *pctrl = platform_get_drvdata(pdev);
>  
>  	gpiochip_remove(&pctrl->chip);
> -	pinctrl_unregister(pctrl->pctldev);
>  
>  	return 0;
>  }
> -- 
> 2.1.4

Thanks,

-- 
heikki


From heikki.krogerus at linux.intel.com  Thu Feb 25 03:44:51 2016
From: heikki.krogerus at linux.intel.com (Heikki Krogerus)
Date: Thu, 25 Feb 2016 13:44:51 +0200
Subject: [PATCH 12/50] pinctrl: intel: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-13-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-13-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160225114451.GB29434@kuha.fi.intel.com>

On Wed, Feb 24, 2016 at 06:45:37PM +0530, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Mika Westerberg <mika.westerberg at linux.intel.com>
> Cc: Heikki Krogerus <heikki.krogerus at linux.intel.com>
> ---
>  drivers/pinctrl/intel/pinctrl-intel.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c
> index 85536b4..27bb21b 100644
> --- a/drivers/pinctrl/intel/pinctrl-intel.c
> +++ b/drivers/pinctrl/intel/pinctrl-intel.c
> @@ -1014,7 +1014,8 @@ int intel_pinctrl_probe(struct platform_device *pdev,
>  	pctrl->pctldesc.pins = pctrl->soc->pins;
>  	pctrl->pctldesc.npins = pctrl->soc->npins;
>  
> -	pctrl->pctldev = pinctrl_register(&pctrl->pctldesc, &pdev->dev, pctrl);
> +	pctrl->pctldev = devm_pinctrl_register(&pdev->dev, &pctrl->pctldesc,
> +					       pctrl);
>  	if (IS_ERR(pctrl->pctldev)) {
>  		dev_err(&pdev->dev, "failed to register pinctrl driver\n");
>  		return PTR_ERR(pctrl->pctldev);

The same as in pinctrl-cherryview.c. pinctrl_unregister() is also
called here inside intel_pinctrl_probe().

> @@ -1037,7 +1038,6 @@ int intel_pinctrl_remove(struct platform_device *pdev)
>  	struct intel_pinctrl *pctrl = platform_get_drvdata(pdev);
>  
>  	gpiochip_remove(&pctrl->chip);
> -	pinctrl_unregister(pctrl->pctldev);
>  
>  	return 0;
>  }
> -- 
> 2.1.4

Thanks,

-- 
heikki


From thunder.leizhen at huawei.com  Thu Feb 25 03:53:27 2016
From: thunder.leizhen at huawei.com (Zhen Lei)
Date: Thu, 25 Feb 2016 19:53:27 +0800
Subject: [PATCH 1/2] pci/of: to support explicitly declare interrupt pins
 unused
Message-ID: <1456401208-10136-1-git-send-email-thunder.leizhen@huawei.com>

Interrupt Pin register is read-only and optional. Some pci devices may use
msi/msix but leave the value of Interrupt Pin non-zero. In this case, the
driver will print information as below:
pci 0000:40:00.0: of_irq_parse_pci() failed with rc=-22

It's easily lead to misinterpret.

Signed-off-by: Zhen Lei <thunder.leizhen at huawei.com>
---
 drivers/of/of_pci_irq.c | 43 ++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
index 2306313..a6d51e0 100644
--- a/drivers/of/of_pci_irq.c
+++ b/drivers/of/of_pci_irq.c
@@ -4,6 +4,38 @@
 #include <linux/export.h>

 /**
+ * of_irq_skip_pci - Skip the interrupt pins for a PCI device
+ * @pdev: the device whose interrupt pins may be skipped
+ * @dn: device node of pdev or pdev's ancestral bus
+ *
+ * Interrupt Pin register is read-only and optional. Some pci devices may use
+ * msi/msix but leave the value of Interrupt Pin non-zero. This function give
+ * an opportunity to suppress the warning about of_irq_parse_pci() failed.
+ */
+static int of_irq_skip_pci(const struct pci_dev *pdev,
+			   const struct device_node *dn)
+{
+	const __be32 *skip_mask, *end;
+	u32 addr, mask;
+	int len;
+
+	skip_mask = of_get_property(dn, "interrupt-skip-mask", &len);
+	if (!skip_mask)
+		return 0;
+
+	end = skip_mask + (len / sizeof(__be32));
+	addr = (pdev->bus->number << 16) | (pdev->devfn << 8);
+
+	while (skip_mask < end) {
+		mask = be32_to_cpu(*(skip_mask++));
+		if ((addr & ~mask) == 0)
+			return 1;
+	}
+
+	return 0;
+}
+
+/**
  * of_irq_parse_pci - Resolve the interrupt for a PCI device
  * @pdev:       the device whose interrupt is to be resolved
  * @out_irq:    structure of_irq filled by this function
@@ -30,6 +62,9 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq
 		rc = of_irq_parse_one(dn, 0, out_irq);
 		if (!rc)
 			return rc;
+
+		if (of_irq_skip_pci(pdev, dn))
+			return -ENODEV;
 	}

 	/* Ok, we don't, time to have fun. Let's start by building up an
@@ -89,9 +124,11 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq
 	laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
 	laddr[1] = laddr[2] = cpu_to_be32(0);
 	rc = of_irq_parse_raw(laddr, out_irq);
-	if (rc)
-		goto err;
-	return 0;
+	if (!rc)
+		return 0;
+
+	if (of_irq_skip_pci(pdev, ppnode))
+		return -ENODEV;
 err:
 	dev_err(&pdev->dev, "of_irq_parse_pci() failed with rc=%d\n", rc);
 	return rc;
--
2.5.0




From thunder.leizhen at huawei.com  Thu Feb 25 03:53:28 2016
From: thunder.leizhen at huawei.com (Zhen Lei)
Date: Thu, 25 Feb 2016 19:53:28 +0800
Subject: [PATCH 2/2] PCI: generic: add description of property
 "interrupt-skip-mask"
In-Reply-To: <1456401208-10136-1-git-send-email-thunder.leizhen@huawei.com>
References: <1456401208-10136-1-git-send-email-thunder.leizhen@huawei.com>
Message-ID: <1456401208-10136-2-git-send-email-thunder.leizhen@huawei.com>

Interrupt Pin register is read-only and optional. Some pci devices may use
msi/msix but leave the value of Interrupt Pin non-zero. In this case, the
driver will print information as below:
pci 0000:40:00.0: of_irq_parse_pci() failed with rc=-22

It's easily lead to misinterpret.

Signed-off-by: Zhen Lei <thunder.leizhen at huawei.com>
---
 Documentation/devicetree/bindings/pci/host-generic-pci.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
index 3f1d3fc..0f10978 100644
--- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
+++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
@@ -70,6 +70,8 @@ Practice: Interrupt Mapping' and requires the following properties:

 - interrupt-map-mask : <see aforementioned specification>

+- interrupt-skip-mask: Explicitly declare which pci devices only use msi/msix
+but leave the value of Interrupt Pin non-zero.

 Example:

--
2.5.0




From lorenzo.pieralisi at arm.com  Thu Feb 25 04:07:50 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 25 Feb 2016 12:07:50 +0000
Subject: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
 HiSilicon SoCs Host Controllers
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1ECCD209@lhreml503-mbs>
References: <1455039260-6040-4-git-send-email-gabriele.paoloni@huawei.com>
 <20160209182429.GD4348@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1591@lhreml503-mbs>
 <20160210111234.GC2632@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1D30@lhreml503-mbs>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECC5F00@lhreml503-mbs>
 <20160224011418.GB13026@localhost>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECCAD6A@lhreml503-mbs>
 <20160224152538.GA19700@localhost>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECCD209@lhreml503-mbs>
Message-ID: <20160225120750.GA32016@red-moon>

On Thu, Feb 25, 2016 at 03:01:19AM +0000, Gabriele Paoloni wrote:

[...]

> > I think the relevant spec is the PCI Firmware Spec, r3.0, sec 4.1.2.
> > Note 2 in that section says the address range of an MMCFG region
> > must be reserved by declaring a motherboard resource, i.e., included
> > in the _CRS of a PNP0C02 or similar device.
> 
> I had a look a this. So yes the specs says that we should use the 
> PNP0C02 device if MCFG is not supported. 

AFAIK, PNP0C02 is a resource reservation mechanism, the spec says that
MCFG regions must be reserved using PNP0C02, even though its
current usage on x86 is a bit unfathomable to me, in particular
in relation to MCFG resources retrieved for hotpluggable bridges (ie
through _CBA, which I think consider the MCFG region as reserved
by default, regardless of PNP0c02):

see pci_mmcfg_check_reserved() arch/x86/pci/mmconfig-shared.c

Have a look at drivers/pnp/system.c for PNP0c02

> So probably I can use acpi_get_devices("PNP0C02",...) to retrieve it
> from the quirk match function, I will look into this... 
> 
> > 
> > > On the other side, since this is an exception only for the config
> > > space address of our host controller (as said before all the buses
> > > below the root one support ECAM), I think that it is right to put
> > > this address as a device specific data (in fact the rest of the
> > > config space addresses will be parsed from MCFG).
> > 
> > A kernel with no support for your host controller (and thus no
> > knowledge of its _DSD) should still be able to operate the rest of the
> > system correctly.  That means we must have a generic way to learn what
> > address space is consumed by the host controller so we don't try to
> > assign it to other devices.
> 
> This is something I don't understand much...
> Are you talking about a scenario where we have a Kernel image compiled
> without our host controller support and running on our platform?

I *think* the point here is that your host controller config space should be
reserved through PNP0c02 so that the kernel will reserve it through the
generic PNP0c02 driver even if your host controller driver (and related
_DSD) is not supported in the kernel.

I do not understand how PNP0c02 works, currently, by the way.

If I read x86 code correctly, the unassigned PCI bus resources are
assigned in arch/x86/pci/i386.c (?) fs_initcall(pcibios_assign_resources),
with a comment:

/**
 * called in fs_initcall (one below subsys_initcall),
 * give a chance for motherboard reserve resources
 */

Problem is, motherboard resources are requested through (?):

drivers/pnp/system.c

which is also initialized at fs_initcall, so it might be called after
core x86 code reassign resources, defeating the purpose PNP0c02 was
designed for, namely, request motherboard regions before resources
are assigned, am I wrong ?

As per last Tomasz's patchset, we claim and assign unassigned PCI
resources upon ACPI PCI host bridge probing (which happens at
subsys_initcall time, courtesy of ACPI current code); at that time the
kernel did not even register the PNP0c02 driver (drivers/pnp/system.c)
(it does that at fs_initcall). On the other hand, we insert MCFG
regions into the resource tree upon MCFG parsing, so I do not
see why we need to rely on PNP0c02 to do that for us (granted, the
mechanism is part of the PCI fw specs, which are x86 centric anyway
ie we can't certainly rely on Int15 e820 to detect reserved memory
on ARM :D)

There is lots of legacy x86 here and Bjorn definitely has more
visibility into that than I have, the ARM world must understand
how this works to make sure we have an agreement.

Thanks,
Lorenzo


From mark.rutland at arm.com  Thu Feb 25 04:20:35 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 25 Feb 2016 12:20:35 +0000
Subject: [PATCH 2/2] PCI: generic: add description of property
 "interrupt-skip-mask"
In-Reply-To: <1456401208-10136-2-git-send-email-thunder.leizhen@huawei.com>
References: <1456401208-10136-1-git-send-email-thunder.leizhen@huawei.com>
 <1456401208-10136-2-git-send-email-thunder.leizhen@huawei.com>
Message-ID: <20160225122035.GB10593@leverpostej>

Hi,

In future, please send the binding document first in a series, per point
3 of Documentation/devicetree/bindings/submitting-patches.txt. It makes
review easier/faster.

On Thu, Feb 25, 2016 at 07:53:28PM +0800, Zhen Lei wrote:
> Interrupt Pin register is read-only and optional. Some pci devices may use
> msi/msix but leave the value of Interrupt Pin non-zero.

Is that permitted by the spec? Surely 'optional' means it must be zero
if not implemented?

> In this case, the driver will print information as below: pci
> 0000:40:00.0: of_irq_parse_pci() failed with rc=-22
> 
> It's easily lead to misinterpret.

If this is limited to a subset of devices which we know are broken in
this regard, can we not handle these cases explicitly?

> Signed-off-by: Zhen Lei <thunder.leizhen at huawei.com>
> ---
>  Documentation/devicetree/bindings/pci/host-generic-pci.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> index 3f1d3fc..0f10978 100644
> --- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> @@ -70,6 +70,8 @@ Practice: Interrupt Mapping' and requires the following properties:
> 
>  - interrupt-map-mask : <see aforementioned specification>
> 
> +- interrupt-skip-mask: Explicitly declare which pci devices only use msi/msix
> +but leave the value of Interrupt Pin non-zero.

Unlike the rest of the interrupt mapping properties, this is not
described in  `Open Firmware Recommended Practice: Interrupt Mapping'.

This needs a far more complete description.

This also doesn't strike me as th right approach. The interrupt-map-mask
property describe as relationship between the host-controller-provided
interrupt lines and endpoints, while this seems to be a bug completely
contained within an endpoint.

Thanks,
Mark.

> 
>  Example:
> 
> --
> 2.5.0
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


From m.szyprowski at samsung.com  Thu Feb 25 04:26:17 2016
From: m.szyprowski at samsung.com (Marek Szyprowski)
Date: Thu, 25 Feb 2016 13:26:17 +0100
Subject: [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM
 architecture
In-Reply-To: <2724572.qtPjgumFDJ@wuerfel>
References: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com>
 <1455870164-25337-4-git-send-email-m.szyprowski@samsung.com>
 <2724572.qtPjgumFDJ@wuerfel>
Message-ID: <56CEF2E9.5040706@samsung.com>

Hello,

On 2016-02-19 11:30, Arnd Bergmann wrote:
> On Friday 19 February 2016 09:22:44 Marek Szyprowski wrote:
>> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation
>> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The
>> side-effect of this change is a switch from bitmap-based IO address space
>> management to tree-based code. There should be no functional changes
>> for drivers, which rely on initialization from generic arch_setup_dna_ops()
>> interface. Code, which used old arm_iommu_* functions must be updated to
>> new interface.
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski at samsung.com>
> I like the overall idea. However, this interface from the iommu
> subsystem into architecture specific code:
>
>> +/*
>> + * The DMA API is built upon the notion of "buffer ownership".  A buffer
>> + * is either exclusively owned by the CPU (and therefore may be accessed
>> + * by it) or exclusively owned by the DMA device.  These helper functions
>> + * represent the transitions between these two ownership states.
>> + *
>> + * Note, however, that on later ARMs, this notion does not work due to
>> + * speculative prefetches.  We model our approach on the assumption that
>> + * the CPU does do speculative prefetches, which means we clean caches
>> + * before transfers and delay cache invalidation until transfer completion.
>> + *
>> + */
>> +extern void __dma_page_cpu_to_dev(struct page *, unsigned long, size_t,
>> +				  enum dma_data_direction);
>> +extern void __dma_page_dev_to_cpu(struct page *, unsigned long, size_t,
>> +				  enum dma_data_direction);
>> +
>> +static inline void arch_flush_page(struct device *dev, const void *virt,
>> +			    phys_addr_t phys)
>> +{
>> +	dmac_flush_range(virt, virt + PAGE_SIZE);
>> +	outer_flush_range(phys, phys + PAGE_SIZE);
>> +}
>> +
>> +static inline void arch_dma_map_area(phys_addr_t phys, size_t size,
>> +				     enum dma_data_direction dir)
>> +{
>> +	unsigned int offset = phys & ~PAGE_MASK;
>> +	__dma_page_cpu_to_dev(phys_to_page(phys & PAGE_MASK), offset, size, dir);
>> +}
>> +
>> +static inline void arch_dma_unmap_area(phys_addr_t phys, size_t size,
>> +				       enum dma_data_direction dir)
>> +{
>> +	unsigned int offset = phys & ~PAGE_MASK;
>> +	__dma_page_dev_to_cpu(phys_to_page(phys & PAGE_MASK), offset, size, dir);
>> +}
>> +
>> +static inline pgprot_t arch_get_dma_pgprot(struct dma_attrs *attrs,
>> +					pgprot_t prot, bool coherent)
>> +{
>> +	if (coherent)
>> +		return prot;
>> +
>> +	prot = dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs) ?
>> +			    pgprot_writecombine(prot) :
>> +			    pgprot_dmacoherent(prot);
>> +	return prot;
>> +}
>> +
>> +extern void *arch_alloc_from_atomic_pool(size_t size, struct page **ret_page,
>> +					 gfp_t flags);
>> +extern bool arch_in_atomic_pool(void *start, size_t size);
>> +extern int arch_free_from_atomic_pool(void *start, size_t size);
>> +
>> +
> doesn't feel completely right yet. In particular the arch_flush_page()
> interface is probably still too specific to ARM/ARM64 and won't work
> that way on other architectures.
>
> I think it would be better to do this either more generic, or less generic:
>
> a) leave the iommu_dma_map_ops definition in the architecture specific
>     code, but make it call helper functions in the drivers/iommu to do all
>     of the really generic parts.
>
> b) clarify that this is only applicable to arch/arm and arch/arm64, and
>     unify things further between these two, as they have very similar
>     requirements in the CPU architecture.

Some really generic parts are already in iommu/dma-iommu.c and one can build
it's own, non-ARM CPU architecture based IOMMU/DMA-mapping code. Initially I
also wanted to use that generic code on both ARM and ARM64, but it 
turned out
that both archs, ARM and ARM64 will duplicate 99% of code, which use this
'generic' functions. This was the reason why I dedided to move all that
common code from arch/{arm,arm64}/mm/dma-mapping.c to
drivers/iommu/dma-iommu-ops.c

I'm not sure if I can design all the changes that need to be made to
drivers/iommu/dma-iommu-ops.c to make it more generic. Maybe when one will
try to use that code with other, non-ARM architecture based arch glue code,
a better abstraction can be developed. For now I would like to keep all this
code in a common place so both arm and arm64 will benefit from improvements
done there.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



From jason at lakedaemon.net  Thu Feb 25 04:31:59 2016
From: jason at lakedaemon.net (Jason Cooper)
Date: Thu, 25 Feb 2016 12:31:59 +0000
Subject: [PATCH] soc: dove: Make reset_control_ops const
In-Reply-To: <1456393568-28363-1-git-send-email-p.zabel@pengutronix.de>
References: <1456393568-28363-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <20160225123159.GB7219@io.lakedaemon.net>

Hi Philipp,

On Thu, Feb 25, 2016 at 10:46:08AM +0100, Philipp Zabel wrote:
> The pmu_reset_ops structure is never modified. Make it const.
> 
> Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
> ---
> Since commit 203d4f347d86 ("reset: Make reset_control_ops const") marked
> the ops pointer in struct reset_controller_dev as const, this struct can
> be made const, too. The commit is currently sitting in the
> arm-soc/for-next branch.

Please include this in the commit body.  All except the last sentence.

> ---
>  drivers/soc/dove/pmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

With that,

Acked-by: Jason Cooper <jason at lakedaemon.net>

thx,

Jason.


From monstr at monstr.eu  Thu Feb 25 05:04:23 2016
From: monstr at monstr.eu (Michal Simek)
Date: Thu, 25 Feb 2016 14:04:23 +0100
Subject: [PATCH v2] serial: xuartps: Enable OF earlycon support
In-Reply-To: <56C5F670.50005@hurleysoftware.com>
References: <09f2c419994281fca7968142e52d969542370d1c.1455782238.git.michal.simek@xilinx.com>
 <56C5F670.50005@hurleysoftware.com>
Message-ID: <56CEFBD7.40008@monstr.eu>

Hi Greg,

On 18.2.2016 17:50, Peter Hurley wrote:
> On 02/17/2016 11:57 PM, Michal Simek wrote:
>> Support early console setup via DT for all listed compatible strings.
>> Remove EARLYCON_DECLARE which was done by:
>> "Use common framework for earlycon declarations"
>> (sha1: 2eaa790989e03900298ad24f77f1086dbbc1aebd)
>> when OF_EARLYCON_DECLARE is defined.
> 
> Reviewed-by: Peter Hurley <peter at hurleysoftware.com>

Can you please add it your queue for 4.6?
Or can we merge it via arm-soc tree as was suggested by Arnd here?
https://lkml.org/lkml/2016/2/16/315

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/a8164c32/attachment.sig>

From monstr at monstr.eu  Thu Feb 25 05:12:53 2016
From: monstr at monstr.eu (Michal Simek)
Date: Thu, 25 Feb 2016 14:12:53 +0100
Subject: [GIT PULL] ARM64: Xilinx ZynqMP DT changes for v4.6
Message-ID: <56CEFDD5.2090704@monstr.eu>

Hi,

please pull these two patches to your tree.

Thanks,
Michal


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  https://github.com/Xilinx/linux-xlnx.git tags/zynqmp-dt-for-4.6

for you to fetch changes up to 5087bccb2f184bad0abfb0b5840279f1540ed44c:

  ARM64: zynqmp: Extract clock information from EP108 (2016-02-25
14:01:03 +0100)

----------------------------------------------------------------
arm: Xilinx ZynqMP dt patches for v4.6

- Extract clock information from EP108
- Sort GPIO node

----------------------------------------------------------------
Michal Simek (2):
      ARM64: zynqmp: Keep gpio node alphabetically sorted
      ARM64: zynqmp: Extract clock information from EP108

 arch/arm64/boot/dts/xilinx/zynqmp-ep108-clk.dtsi | 88
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts      |  1 +
 arch/arm64/boot/dts/xilinx/zynqmp.dtsi           | 61
++++++++++---------------------------------------------------
 3 files changed, 99 insertions(+), 51 deletions(-)
 create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-ep108-clk.dtsi


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/23dd89da/attachment-0001.sig>

From linus.walleij at linaro.org  Thu Feb 25 05:15:07 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 14:15:07 +0100
Subject: [PATCH 0/4] RealView boardfile endgame
Message-ID: <1456406111-18579-1-git-send-email-linus.walleij@linaro.org>

This patch set deletes the RealView board files and moves it
over to a pure Device Tree boot, deleting ~3500 LoC.

Prerequisites:
- The MTD driver patch handling the flash memory write
  protection and VPP enable must go into the MTD subsystem.
  http://marc.info/?l=linux-arm-kernel&m=145380689210787&w=2

- The CLCD device tree support patches (uncontroversial set)
  must go into the FBDEV subsystem.
  http://marc.info/?l=linux-fbdev&m=145622172219039&w=2

- I must queue the device tree patches for the Evaluation
  Boards and Platform Baseboard and Platform Baseboard
  Explore before these patches.

However this is how it will look once the above is in place,
and it will support everything the kernel already supports
today.

Tested on the real hardware for PB1176JZF-S and PB11MPCore.
Tested on QEMU for 1136, 1176, 11MPCore and Cortex-A9 EB,
Platform Baseboard for Cortex-A8 and Platform Baseboard Explore
for Cortex-A9 variants.

Linus Walleij (4):
  ARM: realview: delete the RealView board files
  ARM: realview: reduce the RealView Kconfig
  ARM: realview: imply Device Tree config
  ARM: realview: cut board options from defconfig

 arch/arm/configs/realview_defconfig      |  11 -
 arch/arm/mach-realview/Kconfig           | 144 +--------
 arch/arm/mach-realview/Makefile          |  12 +-
 arch/arm/mach-realview/board-eb.h        |  94 ------
 arch/arm/mach-realview/board-pb1176.h    |  81 -----
 arch/arm/mach-realview/board-pb11mp.h    |  96 ------
 arch/arm/mach-realview/board-pba8.h      |  71 -----
 arch/arm/mach-realview/board-pbx.h       | 106 -------
 arch/arm/mach-realview/core.c            | 404 -------------------------
 arch/arm/mach-realview/core.h            |  58 ----
 arch/arm/mach-realview/hardware.h        |  40 ---
 arch/arm/mach-realview/hotplug.h         |   1 +
 arch/arm/mach-realview/irqs-eb.h         | 114 -------
 arch/arm/mach-realview/irqs-pb1176.h     |  77 -----
 arch/arm/mach-realview/irqs-pb11mp.h     |  97 ------
 arch/arm/mach-realview/irqs-pba8.h       |  71 -----
 arch/arm/mach-realview/irqs-pbx.h        |  87 ------
 arch/arm/mach-realview/platform.h        | 247 ----------------
 arch/arm/mach-realview/platsmp-dt.c      |   3 +-
 arch/arm/mach-realview/platsmp.c         |  86 ------
 arch/arm/mach-realview/realview_eb.c     | 492 -------------------------------
 arch/arm/mach-realview/realview_pb1176.c | 395 -------------------------
 arch/arm/mach-realview/realview_pb11mp.c | 385 ------------------------
 arch/arm/mach-realview/realview_pba8.c   | 307 -------------------
 arch/arm/mach-realview/realview_pbx.c    | 402 -------------------------
 25 files changed, 16 insertions(+), 3865 deletions(-)
 delete mode 100644 arch/arm/mach-realview/board-eb.h
 delete mode 100644 arch/arm/mach-realview/board-pb1176.h
 delete mode 100644 arch/arm/mach-realview/board-pb11mp.h
 delete mode 100644 arch/arm/mach-realview/board-pba8.h
 delete mode 100644 arch/arm/mach-realview/board-pbx.h
 delete mode 100644 arch/arm/mach-realview/core.c
 delete mode 100644 arch/arm/mach-realview/core.h
 delete mode 100644 arch/arm/mach-realview/hardware.h
 create mode 100644 arch/arm/mach-realview/hotplug.h
 delete mode 100644 arch/arm/mach-realview/irqs-eb.h
 delete mode 100644 arch/arm/mach-realview/irqs-pb1176.h
 delete mode 100644 arch/arm/mach-realview/irqs-pb11mp.h
 delete mode 100644 arch/arm/mach-realview/irqs-pba8.h
 delete mode 100644 arch/arm/mach-realview/irqs-pbx.h
 delete mode 100644 arch/arm/mach-realview/platform.h
 delete mode 100644 arch/arm/mach-realview/platsmp.c
 delete mode 100644 arch/arm/mach-realview/realview_eb.c
 delete mode 100644 arch/arm/mach-realview/realview_pb1176.c
 delete mode 100644 arch/arm/mach-realview/realview_pb11mp.c
 delete mode 100644 arch/arm/mach-realview/realview_pba8.c
 delete mode 100644 arch/arm/mach-realview/realview_pbx.c

-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb 25 05:15:09 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 14:15:09 +0100
Subject: [PATCH 2/4] ARM: realview: reduce the RealView Kconfig
In-Reply-To: <1456406111-18579-1-git-send-email-linus.walleij@linaro.org>
References: <1456406111-18579-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1456406111-18579-3-git-send-email-linus.walleij@linaro.org>

We select all we need to the device tree boot and and do not
really need all the sub-options to get this running smoothly.
We will support the ARMv5, ARMv6, ARMv7 or ARMv6+ARMv7
build depending on what the user selects.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-realview/Kconfig | 127 +++--------------------------------------
 1 file changed, 8 insertions(+), 119 deletions(-)

diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig
index def40a0dd60c..cfb4c573638f 100644
--- a/arch/arm/mach-realview/Kconfig
+++ b/arch/arm/mach-realview/Kconfig
@@ -16,9 +16,13 @@ config REALVIEW_DT
 	bool "Support RealView(R) Device Tree based boot"
 	select ARM_GIC
 	select CLK_SP810
-	select HAVE_SMP
+	select CPU_ARM926T if ARCH_MULTI_V5
+	select HAVE_ARM_SCU if SMP
+	select HAVE_ARM_TWD if SMP
+	select HAVE_PATA_PLATFORM
+	select HAVE_SMP if ARCH_MULTI_V6
+	select HAVE_TCM
 	select ICST
-	select MACH_REALVIEW_EB if ARCH_MULTI_V5
 	select MFD_SYSCON
 	select POWER_RESET
 	select POWER_RESET_VERSATILE
@@ -26,129 +30,14 @@ config REALVIEW_DT
 	select SMP_ON_UP if SMP
 	select SOC_REALVIEW
 	select USE_OF
+	select ZONE_DMA
 	help
 	  Include support for booting the ARM(R) RealView(R) evaluation
 	  boards using a device tree machine description.
 
-config MACH_REALVIEW_EB
-	bool "Support RealView(R) Emulation Baseboard"
-	select ARM_GIC
-	select CPU_ARM926T if ARCH_MULTI_V5
-	help
-	  Include support for the ARM(R) RealView(R) Emulation Baseboard
-	  platform. On an ARMv5 kernel, this will include support for
-	  the ARM926EJ-S core tile, while on an ARMv6/v7 kernel, at least
-	  one of the ARM1136, ARM1176, ARM11MPCore or Cortex-A9MPCore
-	  core tile options should be enabled.
-
-config REALVIEW_EB_ARM1136
-	bool "Support ARM1136J(F)-S Tile"
-	depends on MACH_REALVIEW_EB && ARCH_MULTI_V6
-	select CPU_V6
-	help
-	  Enable support for the ARM1136 tile fitted to the
-	  Realview(R) Emulation Baseboard platform.
-
-config REALVIEW_EB_ARM1176
-	bool "Support ARM1176JZ(F)-S Tile"
-	depends on MACH_REALVIEW_EB && ARCH_MULTI_V6
-	help
-	  Enable support for the ARM1176 tile fitted to the
-	  Realview(R) Emulation Baseboard platform.
-
-config REALVIEW_EB_A9MP
-	bool "Support Multicore Cortex-A9 Tile"
-	depends on MACH_REALVIEW_EB && ARCH_MULTI_V7
-	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if SMP
-	select HAVE_SMP
-	select MIGHT_HAVE_CACHE_L2X0
-	help
-	  Enable support for the Cortex-A9MPCore tile fitted to the
-	  Realview(R) Emulation Baseboard platform.
-
-config REALVIEW_EB_ARM11MP
-	bool "Support ARM11MPCore Tile"
-	depends on MACH_REALVIEW_EB && ARCH_MULTI_V6
-	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if SMP
-	select HAVE_SMP
-	select MIGHT_HAVE_CACHE_L2X0
-	help
-	  Enable support for the ARM11MPCore tile fitted to the Realview(R)
-	  Emulation Baseboard platform.
-
-config REALVIEW_EB_ARM11MP_REVB
-	bool "Support ARM11MPCore RevB Tile"
-	depends on REALVIEW_EB_ARM11MP && ARCH_MULTI_V6
-	help
-	  Enable support for the ARM11MPCore Revision B tile on the
-	  Realview(R) Emulation Baseboard platform. Since there are device
-	  address differences, a kernel built with this option enabled is
-	  not compatible with other revisions of the ARM11MPCore tile.
-
-config MACH_REALVIEW_PB11MP
-	bool "Support RealView(R) Platform Baseboard for ARM11MPCore"
-	depends on ARCH_MULTI_V6
-	select ARM_GIC
-	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if SMP
-	select HAVE_PATA_PLATFORM
-	select HAVE_SMP
-	select MIGHT_HAVE_CACHE_L2X0
-	help
-	  Include support for the ARM(R) RealView(R) Platform Baseboard for
-	  the ARM11MPCore.  This platform has an on-board ARM11MPCore and has
-	  support for PCI-E and Compact Flash.
-
-# ARMv6 CPU without K extensions, but does have the new exclusive ops
-config MACH_REALVIEW_PB1176
-	bool "Support RealView(R) Platform Baseboard for ARM1176JZF-S"
-	depends on ARCH_MULTI_V6
-	select ARM_GIC
-	select CPU_V6
-	select HAVE_TCM
-	select MIGHT_HAVE_CACHE_L2X0
-	help
-	  Include support for the ARM(R) RealView(R) Platform Baseboard for
-	  ARM1176JZF-S.
-
-config REALVIEW_PB1176_SECURE_FLASH
-	bool "Allow access to the secure flash memory block"
-	depends on MACH_REALVIEW_PB1176
-	default n
-	help
-	  Select this option if Linux will only run in secure mode on the
-	  RealView PB1176 platform and access to the secure flash memory
-	  block (64MB @ 0x3c000000) is required.
-
-config MACH_REALVIEW_PBA8
-	bool "Support RealView(R) Platform Baseboard for Cortex(tm)-A8 platform"
-	depends on ARCH_MULTI_V7
-	select ARM_GIC
-	select HAVE_PATA_PLATFORM
-	help
-	  Include support for the ARM(R) RealView Platform Baseboard for
-	  Cortex(tm)-A8.  This platform has an on-board Cortex-A8 and has
-	  support for PCI-E and Compact Flash.
-
-config MACH_REALVIEW_PBX
-	bool "Support RealView(R) Platform Baseboard Explore for Cortex-A9"
-	depends on ARCH_MULTI_V7
-	select ARM_GIC
-	select HAVE_ARM_SCU if SMP
-	select HAVE_ARM_TWD if SMP
-	select HAVE_PATA_PLATFORM
-	select HAVE_SMP
-	select MIGHT_HAVE_CACHE_L2X0
-	select ZONE_DMA
-	help
-	  Include support for the ARM(R) RealView(R) Platform Baseboard
-	  Explore.
-
 config REALVIEW_HIGH_PHYS_OFFSET
 	bool "High physical base address for the RealView platform"
-	depends on MMU && !MACH_REALVIEW_PB1176
+	depends on MMU
 	default y
 	help
 	  RealView boards other than PB1176 have the RAM available at
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb 25 05:15:10 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 14:15:10 +0100
Subject: [PATCH 3/4] ARM: realview: imply Device Tree config
In-Reply-To: <1456406111-18579-1-git-send-email-linus.walleij@linaro.org>
References: <1456406111-18579-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1456406111-18579-4-git-send-email-linus.walleij@linaro.org>

This cuts the RealView DT Kconfig to be the same as
CONFIG_ARCH_REALVIEW and rids one Kconfig option.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/mach-realview/Kconfig  | 23 ++++++++---------------
 arch/arm/mach-realview/Makefile |  2 +-
 2 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig
index cfb4c573638f..1706adc5513a 100644
--- a/arch/arm/mach-realview/Kconfig
+++ b/arch/arm/mach-realview/Kconfig
@@ -1,22 +1,12 @@
 menuconfig ARCH_REALVIEW
 	bool "ARM Ltd. RealView family" if ARCH_MULTI_V5 || ARCH_MULTI_V6 || ARCH_MULTI_V7
 	select ARM_AMBA
-	select ARM_TIMER_SP804
-	select COMMON_CLK_VERSATILE
-	select GPIO_PL061 if GPIOLIB
-	select ICST
-	select PLAT_VERSATILE
-	select PLAT_VERSATILE_SCHED_CLOCK
-	help
-	  This enables support for ARM Ltd RealView boards.
-
-if ARCH_REALVIEW
-
-config REALVIEW_DT
-	bool "Support RealView(R) Device Tree based boot"
 	select ARM_GIC
+	select ARM_TIMER_SP804
 	select CLK_SP810
+	select COMMON_CLK_VERSATILE
 	select CPU_ARM926T if ARCH_MULTI_V5
+	select GPIO_PL061 if GPIOLIB
 	select HAVE_ARM_SCU if SMP
 	select HAVE_ARM_TWD if SMP
 	select HAVE_PATA_PLATFORM
@@ -24,6 +14,8 @@ config REALVIEW_DT
 	select HAVE_TCM
 	select ICST
 	select MFD_SYSCON
+	select PLAT_VERSATILE
+	select PLAT_VERSATILE_SCHED_CLOCK
 	select POWER_RESET
 	select POWER_RESET_VERSATILE
 	select POWER_SUPPLY
@@ -32,8 +24,9 @@ config REALVIEW_DT
 	select USE_OF
 	select ZONE_DMA
 	help
-	  Include support for booting the ARM(R) RealView(R) evaluation
-	  boards using a device tree machine description.
+	  This enables support for ARM Ltd RealView boards.
+
+if ARCH_REALVIEW
 
 config REALVIEW_HIGH_PHYS_OFFSET
 	bool "High physical base address for the RealView platform"
diff --git a/arch/arm/mach-realview/Makefile b/arch/arm/mach-realview/Makefile
index 97dab53daaf1..75826b2be82e 100644
--- a/arch/arm/mach-realview/Makefile
+++ b/arch/arm/mach-realview/Makefile
@@ -4,6 +4,6 @@
 ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
 	-I$(srctree)/arch/arm/plat-versatile/include
 
-obj-$(CONFIG_REALVIEW_DT)		+= realview-dt.o
+obj-$(CONFIG_ARCH_REALVIEW)		+= realview-dt.o
 obj-$(CONFIG_SMP)			+= platsmp-dt.o
 obj-$(CONFIG_HOTPLUG_CPU)		+= hotplug.o
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb 25 05:15:11 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 14:15:11 +0100
Subject: [PATCH 4/4] ARM: realview: cut board options from defconfig
In-Reply-To: <1456406111-18579-1-git-send-email-linus.walleij@linaro.org>
References: <1456406111-18579-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <1456406111-18579-5-git-send-email-linus.walleij@linaro.org>

This kills off the now unused board configuration symbols for
the different RealView boards from the RealView defconfig.

Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 arch/arm/configs/realview_defconfig | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/arch/arm/configs/realview_defconfig b/arch/arm/configs/realview_defconfig
index 9e77dc7b828f..7824b8bf9894 100644
--- a/arch/arm/configs/realview_defconfig
+++ b/arch/arm/configs/realview_defconfig
@@ -11,17 +11,6 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_IOSCHED_CFQ is not set
 CONFIG_ARCH_MULTI_V6=y
 CONFIG_ARCH_REALVIEW=y
-CONFIG_REALVIEW_DT=y
-CONFIG_MACH_REALVIEW_EB=y
-CONFIG_REALVIEW_EB_ARM1136=y
-CONFIG_REALVIEW_EB_ARM1176=y
-CONFIG_REALVIEW_EB_A9MP=y
-CONFIG_REALVIEW_EB_ARM11MP=y
-CONFIG_REALVIEW_EB_ARM11MP_REVB=y
-CONFIG_MACH_REALVIEW_PB11MP=y
-CONFIG_MACH_REALVIEW_PB1176=y
-CONFIG_MACH_REALVIEW_PBA8=y
-CONFIG_MACH_REALVIEW_PBX=y
 CONFIG_SMP=y
 CONFIG_AEABI=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb 25 05:18:44 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 14:18:44 +0100
Subject: [PATCH] ARM: sa1100: make sa1100_register_uart_fns a function
In-Reply-To: <1456238094-778916-1-git-send-email-arnd@arndb.de>
References: <1456238094-778916-1-git-send-email-arnd@arndb.de>
Message-ID: <CACRpkdbJpYD2Ke-f2QP+-fy_LcxhiV99OEH_D=CMtSvedEveVA@mail.gmail.com>

On Tue, Feb 23, 2016 at 3:34 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> Calling sa1100_register_uart_fns() leaves the port structure
> unused when CONFIG_SERIAL_SA1100 is disabled, and we get a
> compiler warning about that:
>
> arch/arm/mach-sa1100/badge4.c:317:31: warning: 'badge4_port_fns' defined but not used [-Wunused-variable]
>  static struct sa1100_port_fns badge4_port_fns __initdata = {
>
> This turns the two empty macros into empty inline functions,
> which has the same effect, but lets the compiler know that the
> variables are intentionally unused.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Acked-by: Linus Walleij <linus.walleij at linaro.org>

>  include/linux/platform_data/sa11x0-serial.h | 8 ++++++--

It looks like you should send this to Greg?

Yours,
Linus Walleij


From monstr at monstr.eu  Thu Feb 25 05:19:34 2016
From: monstr at monstr.eu (Michal Simek)
Date: Thu, 25 Feb 2016 14:19:34 +0100
Subject: [GIT PULL] ARM32: Xilinx Zynq SoC changes for v4.6
Message-ID: <56CEFF66.2090907@monstr.eu>

Hi,

Please pull these patches to your tree.

Thanks,
Michal

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  https://github.com/Xilinx/linux-xlnx.git tags/zynq-soc-for-4.6

for you to fetch changes up to 8fff2f752f2c9d31414f83170157701b59aec4c1:

  ARM: zynq: Move early printk virtual address to vmalloc area
(2016-02-25 14:06:03 +0100)

----------------------------------------------------------------
arm: Xilinx Zynq patches for v4.6

- SLCR early init
- Fix L2 cache data corruption
- Fix early printk uart setting

----------------------------------------------------------------
Josh Cartwright (2):
      ARM: zynq: initialize slcr mapping earlier
      ARM: zynq: address L2 cache data corruption

Michal Simek (1):
      ARM: zynq: Move early printk virtual address to vmalloc area

 arch/arm/include/debug/zynq.S | 4 ++--
 arch/arm/mach-zynq/common.c   | 3 +--
 arch/arm/mach-zynq/slcr.c     | 4 ++++
 3 files changed, 7 insertions(+), 4 deletions(-)



-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/68e5151c/attachment.sig>

From p.zabel at pengutronix.de  Thu Feb 25 05:23:12 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 25 Feb 2016 14:23:12 +0100
Subject: [PATCH v2] soc: dove: Make reset_control_ops const
Message-ID: <1456406592-24733-1-git-send-email-p.zabel@pengutronix.de>

Since the pmu_reset_ops structure is never modified, we can make it const
Since commit 203d4f347d86 ("reset: Make reset_control_ops const") marked
the ops pointer in struct reset_controller_dev as const, the pmu_reset_ops
structure, which is never modified, can be made const, too.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
Acked-by: Jason Cooper <jason at lakedaemon.net>
---
The prerequisite commit is currently sitting in the arm-soc/for-next branch.
Changes since v1:
 - Improved commit message.
---
 drivers/soc/dove/pmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/dove/pmu.c b/drivers/soc/dove/pmu.c
index 039374e..95d77ec 100644
--- a/drivers/soc/dove/pmu.c
+++ b/drivers/soc/dove/pmu.c
@@ -87,7 +87,7 @@ static int pmu_reset_deassert(struct reset_controller_dev *rc, unsigned long id)
 	return 0;
 }
 
-static struct reset_control_ops pmu_reset_ops = {
+static const struct reset_control_ops pmu_reset_ops = {
 	.reset = pmu_reset_reset,
 	.assert = pmu_reset_assert,
 	.deassert = pmu_reset_deassert,
-- 
2.7.0



From monstr at monstr.eu  Thu Feb 25 05:23:20 2016
From: monstr at monstr.eu (Michal Simek)
Date: Thu, 25 Feb 2016 14:23:20 +0100
Subject: [GIT PULL] ARM32: Xilinx Zynq DT changes for v4.6
Message-ID: <56CF0048.7060601@monstr.eu>

Hi,

please pull these two patches to your tree.

Thanks,
Michal

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  https://github.com/Xilinx/linux-xlnx.git tags/zynq-dt-for-4.6

for you to fetch changes up to 07bf429da13dfa3f0b40dce4ef2a1437544a6096:

  ARM: zynq: Use earlycon instead of earlyprintk (2016-02-25 14:01:34 +0100)

----------------------------------------------------------------
arm: Xilinx Zynq dt patches for v4.5

- Add usb phy for Zybo
- Use earlycon instead of earlyprintk

----------------------------------------------------------------
Michal Simek (1):
      ARM: zynq: Use earlycon instead of earlyprintk

Nathan Rossi (1):
      ARM: dts: zynq: Enable USB and USB PHY for ZYBO

 arch/arm/boot/dts/zynq-parallella.dts |  2 +-
 arch/arm/boot/dts/zynq-zc702.dts      |  2 +-
 arch/arm/boot/dts/zynq-zc706.dts      |  2 +-
 arch/arm/boot/dts/zynq-zed.dts        |  2 +-
 arch/arm/boot/dts/zynq-zybo.dts       | 13 ++++++++++++-
 5 files changed, 16 insertions(+), 5 deletions(-)


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/db667228/attachment.sig>

From linus.walleij at linaro.org  Thu Feb 25 05:24:48 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 14:24:48 +0100
Subject: [PATCH 00/61] gpio: Add and use devm_gpiochip_add_data()
In-Reply-To: <56CC7791.2000607@nvidia.com>
References: <1456150130-2668-1-git-send-email-ldewangan@nvidia.com>
 <CACRpkdbt+RiWMA74e40MNZVnDM0t0futtFnbyu9sRhv7p93-Tg@mail.gmail.com>
 <56CC1FD4.1080905@nvidia.com> <56CC7791.2000607@nvidia.com>
Message-ID: <CACRpkdYsG8X5XiV2+Ss2GLJkFnLFzLi0uy0yy8R5sdi0b_Y+qA@mail.gmail.com>

On Tue, Feb 23, 2016 at 4:15 PM, Laxman Dewangan <ldewangan at nvidia.com> wrote:

> I have made the repo in git hub as
>     https://github.com/ldewangan/linux-upstream.git

Awesome.

> branch name is devm_gpiochip.
>     https://github.com/ldewangan/linux-upstream/tree/devm_gpiochip

I've pulled this branch into my tree on a separate branch for
testing. I pushed the tree to kernel.org so that the zeroday
autobuilders can have a go at it.

If everything goes well I plan to merge this for v4.6, then we
can merge the changes in pin control and other subsystems
for v4.7.

Yours,
Linus Walleij


From joro at 8bytes.org  Thu Feb 25 05:25:39 2016
From: joro at 8bytes.org (Joerg Roedel)
Date: Thu, 25 Feb 2016 14:25:39 +0100
Subject: [GIT PULL] iommu/io-pgtable: Updates for 4.6
In-Reply-To: <20160218174918.GF16883@arm.com>
References: <20160218174918.GF16883@arm.com>
Message-ID: <20160225132539.GC22747@8bytes.org>

On Thu, Feb 18, 2016 at 05:49:18PM +0000, Will Deacon wrote:
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-joerg/io-pgtable

Pulled. Thanks Will.



From daniel.lezcano at linaro.org  Thu Feb 25 05:37:11 2016
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 25 Feb 2016 14:37:11 +0100
Subject: [PATCH 3/9] clocksource/drivers/lpc32xx: Don't use the prescaler
 counter for clockevents
In-Reply-To: <1456407438-6131-1-git-send-email-daniel.lezcano@linaro.org>
References: <56CF00F6.9010301@linaro.org>
 <1456407438-6131-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1456407438-6131-3-git-send-email-daniel.lezcano@linaro.org>

From: Ezequiel Garcia <ezequiel at vanguardiasur.com.ar>

This commit switches the clockevents one-shot current implementation
to avoid using the prescaler counter. The clockevents timer currently
uses MR0=1, PR=ticks; and after this commit is uses MR0=ticks, PR=0.

While using the prescaler with PR=1 works fine in one-shot mode,
it seems it doesn't work as expected in periodic mode.

By using the only match channel register (MR0) for the timer we make
the periodic mode introduction easier, and consistent with one-shot mode.

Signed-off-by: Ezequiel Garcia <ezequiel at vanguardiasur.com.ar>
Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Reviewed-by: Joachim Eastwood <manabian at gmail.com>
Tested-by: Joachim Eastwood <manabian at gmail.com>
---
 drivers/clocksource/time-lpc32xx.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/clocksource/time-lpc32xx.c b/drivers/clocksource/time-lpc32xx.c
index 1316876..50d1a63 100644
--- a/drivers/clocksource/time-lpc32xx.c
+++ b/drivers/clocksource/time-lpc32xx.c
@@ -60,14 +60,13 @@ static int lpc32xx_clkevt_next_event(unsigned long delta,
 		container_of(evtdev, struct lpc32xx_clock_event_ddata, evtdev);
 
 	/*
-	 * Place timer in reset and program the delta in the prescale
-	 * register (PR). When the prescale counter matches the value
-	 * in PR the counter register is incremented and the compare
-	 * match will trigger. After setup the timer is released from
-	 * reset and enabled.
+	 * Place timer in reset and program the delta in the match
+	 * channel 0 (MR0). When the timer counter matches the value
+	 * in MR0 register the match will trigger an interrupt.
+	 * After setup the timer is released from reset and enabled.
 	 */
 	writel_relaxed(LPC32XX_TIMER_TCR_CRST, ddata->base + LPC32XX_TIMER_TCR);
-	writel_relaxed(delta, ddata->base + LPC32XX_TIMER_PR);
+	writel_relaxed(delta, ddata->base + LPC32XX_TIMER_MR0);
 	writel_relaxed(LPC32XX_TIMER_TCR_CEN, ddata->base + LPC32XX_TIMER_TCR);
 
 	return 0;
@@ -210,13 +209,13 @@ static int __init lpc32xx_clockevent_init(struct device_node *np)
 
 	/*
 	 * Disable timer and clear any pending interrupt (IR) on match
-	 * channel 0 (MR0). Configure a compare match value of 1 on MR0
-	 * and enable interrupt, reset on match and stop on match (MCR).
+	 * channel 0 (MR0). Clear the prescaler as it's not used.
+	 * Enable interrupt, reset on match and stop on match (MCR).
 	 */
 	writel_relaxed(0, base + LPC32XX_TIMER_TCR);
+	writel_relaxed(0, base + LPC32XX_TIMER_PR);
 	writel_relaxed(0, base + LPC32XX_TIMER_CTCR);
 	writel_relaxed(LPC32XX_TIMER_IR_MR0INT, base + LPC32XX_TIMER_IR);
-	writel_relaxed(1, base + LPC32XX_TIMER_MR0);
 	writel_relaxed(LPC32XX_TIMER_MCR_MR0I | LPC32XX_TIMER_MCR_MR0R |
 		       LPC32XX_TIMER_MCR_MR0S, base + LPC32XX_TIMER_MCR);
 
-- 
1.9.1



From daniel.lezcano at linaro.org  Thu Feb 25 05:37:10 2016
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 25 Feb 2016 14:37:10 +0100
Subject: [PATCH 2/9] clocksource/drivers/rockchip: Add err handle for
 rk_timer_init
In-Reply-To: <1456407438-6131-1-git-send-email-daniel.lezcano@linaro.org>
References: <56CF00F6.9010301@linaro.org>
 <1456407438-6131-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1456407438-6131-2-git-send-email-daniel.lezcano@linaro.org>

From: Shawn Lin <shawn.lin at rock-chips.com>

Currently rockchip_timer doesn't do some basic cleanup work when
failing to init the timer. Let's add err handle routine to deal
with all the err cases.

Signed-off-by: Shawn Lin <shawn.lin at rock-chips.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 drivers/clocksource/rockchip_timer.c | 21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/clocksource/rockchip_timer.c b/drivers/clocksource/rockchip_timer.c
index 8c77a52..b991b28 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -122,23 +122,23 @@ static void __init rk_timer_init(struct device_node *np)
 	pclk = of_clk_get_by_name(np, "pclk");
 	if (IS_ERR(pclk)) {
 		pr_err("Failed to get pclk for '%s'\n", TIMER_NAME);
-		return;
+		goto out_unmap;
 	}
 
 	if (clk_prepare_enable(pclk)) {
 		pr_err("Failed to enable pclk for '%s'\n", TIMER_NAME);
-		return;
+		goto out_unmap;
 	}
 
 	timer_clk = of_clk_get_by_name(np, "timer");
 	if (IS_ERR(timer_clk)) {
 		pr_err("Failed to get timer clock for '%s'\n", TIMER_NAME);
-		return;
+		goto out_timer_clk;
 	}
 
 	if (clk_prepare_enable(timer_clk)) {
 		pr_err("Failed to enable timer clock\n");
-		return;
+		goto out_timer_clk;
 	}
 
 	bc_timer.freq = clk_get_rate(timer_clk);
@@ -146,7 +146,7 @@ static void __init rk_timer_init(struct device_node *np)
 	irq = irq_of_parse_and_map(np, 0);
 	if (!irq) {
 		pr_err("Failed to map interrupts for '%s'\n", TIMER_NAME);
-		return;
+		goto out_irq;
 	}
 
 	ce->name = TIMER_NAME;
@@ -164,10 +164,19 @@ static void __init rk_timer_init(struct device_node *np)
 	ret = request_irq(irq, rk_timer_interrupt, IRQF_TIMER, TIMER_NAME, ce);
 	if (ret) {
 		pr_err("Failed to initialize '%s': %d\n", TIMER_NAME, ret);
-		return;
+		goto out_irq;
 	}
 
 	clockevents_config_and_register(ce, bc_timer.freq, 1, UINT_MAX);
+
+	return;
+
+out_irq:
+	clk_disable_unprepare(timer_clk);
+out_timer_clk:
+	clk_disable_unprepare(pclk);
+out_unmap:
+	iounmap(bc_timer.base);
 }
 
 CLOCKSOURCE_OF_DECLARE(rk_timer, "rockchip,rk3288-timer", rk_timer_init);
-- 
1.9.1



From daniel.lezcano at linaro.org  Thu Feb 25 05:37:12 2016
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 25 Feb 2016 14:37:12 +0100
Subject: [PATCH 4/9] clocksource/drivers/lpc32xx: Support periodic mode
In-Reply-To: <1456407438-6131-1-git-send-email-daniel.lezcano@linaro.org>
References: <56CF00F6.9010301@linaro.org>
 <1456407438-6131-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1456407438-6131-4-git-send-email-daniel.lezcano@linaro.org>

From: Ezequiel Garcia <ezequiel at vanguardiasur.com.ar>

This commit adds the support for periodic mode. This is done by not
setting the MR0S (Stop on TnMR0) bit on MCR, thus allowing
interrupts to be periodically generated on MR0 matches.

In order to do this, move the initial configuration that is specific to
the one-shot mode to set_state_oneshot().

Signed-off-by: Ezequiel Garcia <ezequiel at vanguardiasur.com.ar>
Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Reviewed-by: Joachim Eastwood <manabian at gmail.com>
Tested-by: Joachim Eastwood <manabian at gmail.com>
---
 drivers/clocksource/time-lpc32xx.c | 39 +++++++++++++++++++++++++++++++++-----
 1 file changed, 34 insertions(+), 5 deletions(-)

diff --git a/drivers/clocksource/time-lpc32xx.c b/drivers/clocksource/time-lpc32xx.c
index 50d1a63..5694edd 100644
--- a/drivers/clocksource/time-lpc32xx.c
+++ b/drivers/clocksource/time-lpc32xx.c
@@ -43,6 +43,7 @@
 struct lpc32xx_clock_event_ddata {
 	struct clock_event_device evtdev;
 	void __iomem *base;
+	u32 ticks_per_jiffy;
 };
 
 /* Needed for the sched clock */
@@ -85,11 +86,39 @@ static int lpc32xx_clkevt_shutdown(struct clock_event_device *evtdev)
 
 static int lpc32xx_clkevt_oneshot(struct clock_event_device *evtdev)
 {
+	struct lpc32xx_clock_event_ddata *ddata =
+		container_of(evtdev, struct lpc32xx_clock_event_ddata, evtdev);
+
 	/*
 	 * When using oneshot, we must also disable the timer
 	 * to wait for the first call to set_next_event().
 	 */
-	return lpc32xx_clkevt_shutdown(evtdev);
+	writel_relaxed(0, ddata->base + LPC32XX_TIMER_TCR);
+
+	/* Enable interrupt, reset on match and stop on match (MCR). */
+	writel_relaxed(LPC32XX_TIMER_MCR_MR0I | LPC32XX_TIMER_MCR_MR0R |
+		       LPC32XX_TIMER_MCR_MR0S, ddata->base + LPC32XX_TIMER_MCR);
+	return 0;
+}
+
+static int lpc32xx_clkevt_periodic(struct clock_event_device *evtdev)
+{
+	struct lpc32xx_clock_event_ddata *ddata =
+		container_of(evtdev, struct lpc32xx_clock_event_ddata, evtdev);
+
+	/* Enable interrupt and reset on match. */
+	writel_relaxed(LPC32XX_TIMER_MCR_MR0I | LPC32XX_TIMER_MCR_MR0R,
+		       ddata->base + LPC32XX_TIMER_MCR);
+
+	/*
+	 * Place timer in reset and program the delta in the match
+	 * channel 0 (MR0).
+	 */
+	writel_relaxed(LPC32XX_TIMER_TCR_CRST, ddata->base + LPC32XX_TIMER_TCR);
+	writel_relaxed(ddata->ticks_per_jiffy, ddata->base + LPC32XX_TIMER_MR0);
+	writel_relaxed(LPC32XX_TIMER_TCR_CEN, ddata->base + LPC32XX_TIMER_TCR);
+
+	return 0;
 }
 
 static irqreturn_t lpc32xx_clock_event_handler(int irq, void *dev_id)
@@ -107,11 +136,13 @@ static irqreturn_t lpc32xx_clock_event_handler(int irq, void *dev_id)
 static struct lpc32xx_clock_event_ddata lpc32xx_clk_event_ddata = {
 	.evtdev = {
 		.name			= "lpc3220 clockevent",
-		.features		= CLOCK_EVT_FEAT_ONESHOT,
+		.features		= CLOCK_EVT_FEAT_ONESHOT |
+					  CLOCK_EVT_FEAT_PERIODIC,
 		.rating			= 300,
 		.set_next_event		= lpc32xx_clkevt_next_event,
 		.set_state_shutdown	= lpc32xx_clkevt_shutdown,
 		.set_state_oneshot	= lpc32xx_clkevt_oneshot,
+		.set_state_periodic	= lpc32xx_clkevt_periodic,
 	},
 };
 
@@ -210,17 +241,15 @@ static int __init lpc32xx_clockevent_init(struct device_node *np)
 	/*
 	 * Disable timer and clear any pending interrupt (IR) on match
 	 * channel 0 (MR0). Clear the prescaler as it's not used.
-	 * Enable interrupt, reset on match and stop on match (MCR).
 	 */
 	writel_relaxed(0, base + LPC32XX_TIMER_TCR);
 	writel_relaxed(0, base + LPC32XX_TIMER_PR);
 	writel_relaxed(0, base + LPC32XX_TIMER_CTCR);
 	writel_relaxed(LPC32XX_TIMER_IR_MR0INT, base + LPC32XX_TIMER_IR);
-	writel_relaxed(LPC32XX_TIMER_MCR_MR0I | LPC32XX_TIMER_MCR_MR0R |
-		       LPC32XX_TIMER_MCR_MR0S, base + LPC32XX_TIMER_MCR);
 
 	rate = clk_get_rate(clk);
 	lpc32xx_clk_event_ddata.base = base;
+	lpc32xx_clk_event_ddata.ticks_per_jiffy = DIV_ROUND_CLOSEST(rate, HZ);
 	clockevents_config_and_register(&lpc32xx_clk_event_ddata.evtdev,
 					rate, 1, -1);
 
-- 
1.9.1



From daniel.lezcano at linaro.org  Thu Feb 25 05:37:13 2016
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 25 Feb 2016 14:37:13 +0100
Subject: [PATCH 5/9] clocksource/drivers/lpc32xx: Support timer-based ARM delay
In-Reply-To: <1456407438-6131-1-git-send-email-daniel.lezcano@linaro.org>
References: <56CF00F6.9010301@linaro.org>
 <1456407438-6131-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1456407438-6131-5-git-send-email-daniel.lezcano@linaro.org>

From: Ezequiel Garcia <ezequiel at vanguardiasur.com.ar>

This commit implements the ARM timer-based delay timer for the
LPC32xx, LPC18xx, LPC43xx family of SoCs.

Also, add a dependency to restrict compiling this driver for
the ARM architecture.

Signed-off-by: Ezequiel Garcia <ezequiel at vanguardiasur.com.ar>
Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
Reviewed-by: Joachim Eastwood <manabian at gmail.com>
Tested-by: Joachim Eastwood <manabian at gmail.com>
---
 drivers/clocksource/Kconfig        |  1 +
 drivers/clocksource/time-lpc32xx.c | 12 ++++++++++++
 2 files changed, 13 insertions(+)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 56777f0..c9c4db6 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -153,6 +153,7 @@ config CLKSRC_EFM32
 config CLKSRC_LPC32XX
 	bool "Clocksource for LPC32XX" if COMPILE_TEST
 	depends on GENERIC_CLOCKEVENTS && HAS_IOMEM
+	depends on ARM
 	select CLKSRC_MMIO
 	select CLKSRC_OF
 	help
diff --git a/drivers/clocksource/time-lpc32xx.c b/drivers/clocksource/time-lpc32xx.c
index 5694edd..daae61e 100644
--- a/drivers/clocksource/time-lpc32xx.c
+++ b/drivers/clocksource/time-lpc32xx.c
@@ -18,6 +18,7 @@
 #include <linux/clk.h>
 #include <linux/clockchips.h>
 #include <linux/clocksource.h>
+#include <linux/delay.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
 #include <linux/kernel.h>
@@ -54,6 +55,15 @@ static u64 notrace lpc32xx_read_sched_clock(void)
 	return readl(clocksource_timer_counter);
 }
 
+static unsigned long lpc32xx_delay_timer_read(void)
+{
+	return readl(clocksource_timer_counter);
+}
+
+static struct delay_timer lpc32xx_delay_timer = {
+	.read_current_timer = lpc32xx_delay_timer_read,
+};
+
 static int lpc32xx_clkevt_next_event(unsigned long delta,
 				     struct clock_event_device *evtdev)
 {
@@ -192,6 +202,8 @@ static int __init lpc32xx_clocksource_init(struct device_node *np)
 	}
 
 	clocksource_timer_counter = base + LPC32XX_TIMER_TC;
+	lpc32xx_delay_timer.freq = rate;
+	register_current_timer_delay(&lpc32xx_delay_timer);
 	sched_clock_register(lpc32xx_read_sched_clock, 32, rate);
 
 	return 0;
-- 
1.9.1



From daniel.lezcano at linaro.org  Thu Feb 25 05:37:14 2016
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 25 Feb 2016 14:37:14 +0100
Subject: [PATCH 6/9] clocksource/drivers/arm_global_timer: Register delay timer
In-Reply-To: <1456407438-6131-1-git-send-email-daniel.lezcano@linaro.org>
References: <56CF00F6.9010301@linaro.org>
 <1456407438-6131-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1456407438-6131-6-git-send-email-daniel.lezcano@linaro.org>

From: Rabin Vincent <rabin.vincent at axis.com>

Provide a delay timer using the lower 32-bits of the global timer so
that we can use that instead of having to calibrating delays.

Signed-off-by: Rabin Vincent <rabin.vincent at axis.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 drivers/clocksource/arm_global_timer.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c
index d189d8c..36998fa 100644
--- a/drivers/clocksource/arm_global_timer.c
+++ b/drivers/clocksource/arm_global_timer.c
@@ -16,6 +16,7 @@
 #include <linux/clockchips.h>
 #include <linux/cpu.h>
 #include <linux/clk.h>
+#include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/io.h>
 #include <linux/of.h>
@@ -221,6 +222,21 @@ static u64 notrace gt_sched_clock_read(void)
 }
 #endif
 
+static unsigned long gt_read_long(void)
+{
+	return readl_relaxed(gt_base + GT_COUNTER0);
+}
+
+static struct delay_timer gt_delay_timer = {
+	.read_current_timer = gt_read_long,
+};
+
+static void __init gt_delay_timer_init(void)
+{
+	gt_delay_timer.freq = gt_clk_rate;
+	register_current_timer_delay(&gt_delay_timer);
+}
+
 static void __init gt_clocksource_init(void)
 {
 	writel(0, gt_base + GT_CONTROL);
@@ -317,6 +333,7 @@ static void __init global_timer_of_register(struct device_node *np)
 	/* Immediately configure the timer on the boot CPU */
 	gt_clocksource_init();
 	gt_clockevents_init(this_cpu_ptr(gt_evt));
+	gt_delay_timer_init();
 
 	return;
 
-- 
1.9.1



From daniel.lezcano at linaro.org  Thu Feb 25 05:37:16 2016
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 25 Feb 2016 14:37:16 +0100
Subject: [PATCH 8/9] clockevents/drivers/arm_global_timer: Implement
 ->set_state_oneshot_stopped()
In-Reply-To: <1456407438-6131-1-git-send-email-daniel.lezcano@linaro.org>
References: <56CF00F6.9010301@linaro.org>
 <1456407438-6131-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1456407438-6131-8-git-send-email-daniel.lezcano@linaro.org>

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

set_state_oneshot_stopped() is called by the clkevt core, when the next
event is required at an expiry time of 'KTIME_MAX'. This normally
happens with NO_HZ_{IDLE|FULL} in both LOWRES/HIGHRES modes.

This patch makes the clockevent device to stop on such an event, to
avoid spurious interrupts, as explained by: commit 8fff52fd5093
("clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state").

Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 drivers/clocksource/arm_global_timer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c
index 36998fa..9df0d16 100644
--- a/drivers/clocksource/arm_global_timer.c
+++ b/drivers/clocksource/arm_global_timer.c
@@ -175,6 +175,7 @@ static int gt_clockevents_init(struct clock_event_device *clk)
 	clk->set_state_shutdown = gt_clockevent_shutdown;
 	clk->set_state_periodic = gt_clockevent_set_periodic;
 	clk->set_state_oneshot = gt_clockevent_shutdown;
+	clk->set_state_oneshot_stopped = gt_clockevent_shutdown;
 	clk->set_next_event = gt_clockevent_set_next_event;
 	clk->cpumask = cpumask_of(cpu);
 	clk->rating = 300;
-- 
1.9.1



From daniel.lezcano at linaro.org  Thu Feb 25 05:37:17 2016
From: daniel.lezcano at linaro.org (Daniel Lezcano)
Date: Thu, 25 Feb 2016 14:37:17 +0100
Subject: [PATCH 9/9] clockevents/drivers/exynos_mct: Implement
 ->set_state_oneshot_stopped()
In-Reply-To: <1456407438-6131-1-git-send-email-daniel.lezcano@linaro.org>
References: <56CF00F6.9010301@linaro.org>
 <1456407438-6131-1-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <1456407438-6131-9-git-send-email-daniel.lezcano@linaro.org>

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

set_state_oneshot_stopped() is called by the clkevt core, when the next
event is required at an expiry time of 'KTIME_MAX'. This normally
happens with NO_HZ_{IDLE|FULL} in both LOWRES/HIGHRES modes.

This patch makes the clockevent device to stop on such an event, to
avoid spurious interrupts, as explained by: commit 8fff52fd5093
("clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state").

Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
---
 drivers/clocksource/exynos_mct.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index ff44082..be09bc0 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -313,6 +313,7 @@ static struct clock_event_device mct_comp_device = {
 	.set_state_periodic	= mct_set_state_periodic,
 	.set_state_shutdown	= mct_set_state_shutdown,
 	.set_state_oneshot	= mct_set_state_shutdown,
+	.set_state_oneshot_stopped = mct_set_state_shutdown,
 	.tick_resume		= mct_set_state_shutdown,
 };
 
@@ -452,6 +453,7 @@ static int exynos4_local_timer_setup(struct mct_clock_event_device *mevt)
 	evt->set_state_periodic = set_state_periodic;
 	evt->set_state_shutdown = set_state_shutdown;
 	evt->set_state_oneshot = set_state_shutdown;
+	evt->set_state_oneshot_stopped = set_state_shutdown;
 	evt->tick_resume = set_state_shutdown;
 	evt->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
 	evt->rating = 450;
-- 
1.9.1



From linus.walleij at linaro.org  Thu Feb 25 05:43:46 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 14:43:46 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <B8A82546-46C7-4A21-92D8-62418E49FBB6@konsulko.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
 <56CC546A.9070705@ti.com>
 <20160224104638.GL19428@n2100.arm.linux.org.uk>
 <56CD924F.50108@ti.com>
 <B8A82546-46C7-4A21-92D8-62418E49FBB6@konsulko.com>
Message-ID: <CACRpkdZ=PR6O28NQusUEipCYwRZyuhbeAJO_ZK80+4H7Zakt=g@mail.gmail.com>

On Wed, Feb 24, 2016 at 1:13 PM, Pantelis Antoniou
<pantelis.antoniou at konsulko.com> wrote:

> IMHO DT+overlays handle all your cases just fine.
>
> As far as I see these are the cases which we need to handle:
>
> 1) The expansion board in question has some means of identification, whether it?s an
> EEPROM or a GPIO keying combination etc. In that case it is the kernel?s job to match this
> id value with a dtbo firmware file and apply it. The blob is located via means of request_firmware().

Since the dawn of time the x86 people used that console to display
the early boot crawl and collect crash data. What you're suggesting
is that we can't get the console up until after the filesystems and mounts
are up so the kernel can read firmware files.

This kills of early boot graphics and getting crash logs on the fbdev
console until that has happened.

It also means there is no way to get the console up without the right
firmware files in the filesystem. I think that is really crap compared
to what we have today where the display will always come up, and
basically a regression.

I understand the stance with respect to things like add-on hardware
like a Bluetooth board or WLAN or whatnot. But the fbdev console
is just too basic, like a serial port IMO.

Sure in the ARM world we usually have a serial console, but this is
seriously breaking current practice.

Yours,
Linus Walleij


From kaloz at openwrt.org  Thu Feb 25 05:48:16 2016
From: kaloz at openwrt.org (Imre Kaloz)
Date: Thu, 25 Feb 2016 14:48:16 +0100
Subject: [PATCH 1/2] ARM: mvebu: change order of ethernet DT nodes on
 Armada 38x
In-Reply-To: <20160225113610.351149bf@free-electrons.com>
References: <1453907300-28283-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1453907300-28283-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160127193143.GF10826@n2100.arm.linux.org.uk>
 <20160127194512.GA16638@1wt.eu>
 <20160129114853.GQ10826@n2100.arm.linux.org.uk>
 <20160224184114.GB2292@1wt.eu>
 <20160224223350.GP19428@n2100.arm.linux.org.uk>
 <20160225113610.351149bf@free-electrons.com>
Message-ID: <op.ydd5yqmx2s3iss@ecaz>

On Thu, 25 Feb 2016 11:36:10 +0100, Thomas Petazzoni  
<thomas.petazzoni at free-electrons.com> wrote:

> Hello,
>
> On Wed, 24 Feb 2016 22:33:50 +0000, Russell King - ARM Linux wrote:
>
>> I didn't say no to it, I merely asked a few pertinent questions and
>> made some pertinent points.
>>
>> Let me restate:
>>
>> * Today, people who switch between mainline and vendor kernels
>>   experience some pain due to the NIC order changing.
>>
>> * Mainline has had support for Armada 38x for 2 years now, which is
>>   long enough for it to have gained users.  AFAICS, there haven't been
>>   any complaints about the different NIC ordering.  Changing the NIC
>>   ordering is going to cause breakage to these users when they migrate
>>   across the change.
>>
>> By making the change, we're effectively telling these mainline-only
>> users "we don't care about your setups, we're going to break them"
>> because that's exactly what we're going to do.
>>
>> Of course, if no one complains about the change, you've got away
>> with it.
>
> I agree with you that the change isn't perfect, it's really a matter of
> trade-off. The perfect change would be to be able to help the network
> subsystem in its naming of network interfaces, but this has always been
> rejected. It would have indeed been better to add this DT node ordering
> work-around earlier, but we didn't do it, and we're in the present.
>
> So again, yes the proposed change is not "great", but I believe it's
> relatively reasonable. If we indeed get feedback that it's breaking
> things for too many people, I guess we'll just revert. I don't mind if
> things remain as they are today, i.e with a weird ordering of the
> network interfaces. It's just annoying for new people using the
> platform, but it's not horrible either.

I can check during the weekend if the mainlined Linksys boards get broken  
because of this.


Imre


From tomi.valkeinen at ti.com  Thu Feb 25 05:56:48 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Thu, 25 Feb 2016 15:56:48 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CACRpkdZ=PR6O28NQusUEipCYwRZyuhbeAJO_ZK80+4H7Zakt=g@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
 <56CC546A.9070705@ti.com> <20160224104638.GL19428@n2100.arm.linux.org.uk>
 <56CD924F.50108@ti.com> <B8A82546-46C7-4A21-92D8-62418E49FBB6@konsulko.com>
 <CACRpkdZ=PR6O28NQusUEipCYwRZyuhbeAJO_ZK80+4H7Zakt=g@mail.gmail.com>
Message-ID: <56CF0820.1010602@ti.com>

On 25/02/16 15:43, Linus Walleij wrote:
> On Wed, Feb 24, 2016 at 1:13 PM, Pantelis Antoniou
> <pantelis.antoniou at konsulko.com> wrote:
> 
>> IMHO DT+overlays handle all your cases just fine.
>>
>> As far as I see these are the cases which we need to handle:
>>
>> 1) The expansion board in question has some means of identification, whether it?s an
>> EEPROM or a GPIO keying combination etc. In that case it is the kernel?s job to match this
>> id value with a dtbo firmware file and apply it. The blob is located via means of request_firmware().
> 
> Since the dawn of time the x86 people used that console to display
> the early boot crawl and collect crash data. What you're suggesting
> is that we can't get the console up until after the filesystems and mounts
> are up so the kernel can read firmware files.

You can build firmware images into the kernel image. No, I don't like
that either.

The 2.2) option in Pantelis' mail can be used for 1) too, although then
the bootloader needs to know which dtbos to add.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/35dfa506/attachment.sig>

From mcoquelin.stm32 at gmail.com  Thu Feb 25 06:00:04 2016
From: mcoquelin.stm32 at gmail.com (Maxime Coquelin)
Date: Thu, 25 Feb 2016 15:00:04 +0100
Subject: [PATCH 27/50] pinctrl: stm32: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-28-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-28-git-send-email-ldewangan@nvidia.com>
Message-ID: <CALszF6Bq4gK1bOJFVE3VAWjnX9eYpQeEVVO-_g2kv0O=iePJyA@mail.gmail.com>

2016-02-24 14:15 GMT+01:00 Laxman Dewangan <ldewangan at nvidia.com>:
> Use devm_pinctrl_register() for pin control registration.
>
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
> Cc: Patrice Chotard <patrice.chotard at st.com>
> ---
>  drivers/pinctrl/stm32/pinctrl-stm32.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)

Acked-by: Maxime Coquelin <mcoquelin.stm32 at gmail.com>

Thanks!
Maxime


From linus.walleij at linaro.org  Thu Feb 25 06:04:52 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 15:04:52 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56CC60C4.6040908@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <3695074.sKSIyOjpjD@wuerfel>
 <CACRpkdZjfjOCFUucF1U5yVZBxSwa41GKEMv-HHQE=ymF2NZ21g@mail.gmail.com>
 <6859810.tb1t0IEONi@wuerfel> <56CC57FC.20707@ti.com>
 <CACRpkdYNaNtQQJ-tsBe5ksa4-z380ZQj-zN8ZnK0ED2kNPUwvg@mail.gmail.com>
 <56CC60C4.6040908@ti.com>
Message-ID: <CACRpkdZd8TLdsi7_cOrqzcqWKJrfdp4Vz2sx5ozpwJXOj0fa+Q@mail.gmail.com>

On Tue, Feb 23, 2016 at 2:38 PM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:

> Maybe Versatile is different. If CLCD is only used on that board, or a
> small family of boards, from one vendor, I guess it is maintainable to
> have board specific driver parts for CLCD. But if CLCD can be used by
> many vendors in many different boards, I'd steer clear of board specific
> driver code.

OK I think at this point we would say that CLCD is a legacy driver.
It is a PrimceCell (IP block) made by ARM Ltd for their reference
designs, and intended for demonstration purposes. It is used in
these:
arch/arm/mach-integrator/
arch/arm/mach-versatile/
arch/arm/mach-realview/
arch/arm/mach-vexpress/

At the last iteration of their reference designs, ARM invented a
new display driver called HDLCD, which you can find in
drivers/gpu/drm/arm in linux-next. Thus the CLCD is now legacy.

As part of signing a deal with ARM to synthesize their silicon,
vendors get copies of the IP blocks to jumpstart design work.
Sometimes they will design their own display controller, sometimes
they will take the ARM CLCD and synthesize it right off
and not innovate around it at all. That is why CLCD also
appears in:
arch/arm/configs/axm55xx_defconfig
arch/arm/configs/lpc18xx_defconfig
arch/arm/boot/dts/lpc18xx.dtsi
arch/arm/configs/lpc32xx_defconfig
arch/arm/boot/dts/lpc32xx.dtsi
arch/arm/configs/netx_defconfig
arch/arm/configs/spear3xx_defconfig

Sometimes the vendors will tweak the CLCD. St Microelectronics
did the latter, and that is why I add support for that variant as
well.

HOWEVER: the ARM Versatile is the *only* platform I have
seen of these that have plug'n'play for the display.

*All* the others
will be very happy with *ONE* display defined as panel in the
device tree, and off they go. Usually VGA. And that will look
much like arch/arm/boot/dts/vexpress-v2m.dtsi already look
like today, using "panel-dpi" to define their displays.

They and their displays may need some board-specific or SoC
specific tweaks though, just like the Nomadik. The Vexpress is
happy to be able to go without, because I guess it is hard-coded
to just use the DVI output, so no path for the signal needs to be
set up.

I add support for doing this for the Integrator and RealView in
the patch set, by grabbing a handle to the system controller
where they have a few "misc registers". However if you look at
it:

static void integrator_clcd_enable(struct clcd_fb *fb)
{
        struct fb_var_screeninfo *var = &fb->fb.var;
        u32 val;

        dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");

        val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
                INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
        if (var->bits_per_pixel <= 8 ||
            (var->bits_per_pixel == 16 && var->green.length == 5))
                /* Pseudocolor, RGB555, BGR555 */
                val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
        else if (fb->fb.var.bits_per_pixel <= 16)
                /* truecolor RGB565 */
                val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
        else
                val = 0; /* no idea for this, don't trust the docs */

        regmap_update_bits(versatile_syscon_map,
                           INTEGRATOR_HDR_CTRL_OFFSET,
                           0,
                           INTEGRATOR_CLCD_MASK);
}

This is stuff that is so closely tied in to the fbdev driver that even
if it is SoC-specific (and reside in arch/arm/mach-integrator etc
today) it would be hard to argument that it should not be part
of the fbdev driver: what it does is connect the lines out of the
CLCD block to the physical VGA encode chip in different ways
depending on how the pixels were set up.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Feb 25 06:13:26 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 15:13:26 +0100
Subject: [PATCH 00/50] pinctrl: Add and use devm_ apis for
 pinctrl_{register, unregister}
In-Reply-To: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
Message-ID: <CACRpkdZjv2KZ0AtC9oBytmSdS+=T+kC8PoJVt-RawE8Np8p40w@mail.gmail.com>

On Wed, Feb 24, 2016 at 2:15 PM, Laxman Dewangan <ldewangan at nvidia.com> wrote:

> Add resource manageemnt APIs fro pinctrl_register() and pinctrl_unregister()
> and use these new APIs on hw driver to reduce the error path code and
> remove callback for driver.

As you can probably guess I like this too, so wait a while, collect ACKs
and send me a branch to pull for this too.

Yours,
Linus Walleij


From slemieux.tyco at gmail.com  Thu Feb 25 06:14:34 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Thu, 25 Feb 2016 09:14:34 -0500
Subject: [GIT PULL] NXP LPC32xx Platform Updates for v4.6 #1
In-Reply-To: <20160224213633.GF10126@localhost>
References: <56BBE6E6.4080802@mleia.com>  <20160224213633.GF10126@localhost>
Message-ID: <1456409674.25197.9.camel@localhost>

Hi Olof,

On Wed, 2016-02-24 at 13:36 -0800, Olof Johansson wrote:
> Hi!
> 
> On Thu, Feb 11, 2016 at 03:41:58AM +0200, Vladimir Zapolskiy wrote:
> > Hi Arnd, Olof, Kevin,
> > 
> > please consider to include NXP LPC32xx platfrom updates (#1) for v4.6.
> > 
> > The main change is a switchover to a common clock framework driver
> > for LPC32xx, this also allows to reuse a shared LPC32xx clockevent
> > driver, and hence remove legacy clock and timer drivers from
> > arch/arm/mach-lpc32xx.
> > 
> > I'm adding an official LPC32xx maintainer Roland to Cc, however
> > he seems to be unresponsive for a quite long time (since 2014).
> > 
> > ----------------------------------------------------------------
> > 
> > The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> > 
> >   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> > 
> > are available in the git repository at:
> > 
> >   https://github.com/vzapolskiy/linux.git lpc32xx/soc
> > 
> > for you to fetch changes up to 0ac1a101f5dd28c3894be3c0230ee7ea2e05e8aa:
> > 
> >   arm: lpc32xx: remove direct control of GPIOs from shared mach file (2016-02-11 02:27:04 +0200)
> 
> In the future, please use the decription you wrote above as part of a tag
> description, and sign your tags. For extra credit, get other kernel developers
> to sign your key (easiest done at conferences, but maybe there are other
> developers in your local area that you can meet up with).
> 
> It indeed seems like Roland has gone silent lately. This happens from time to
> time, but it's always good to know if it's intentional (and if he's coming
> back) or not. Meanwhile, we can merge patches after review but I don't have
> hardware to test on so I'd have to rely on you getting that right. If we get
> regression reports we'll have to re-evaluate the approach. :)
> 
I am running this patchset and the LPC32xx DT update patchset on a 
custom LPC32xx board; I did have any problem while running 
those changes.

I am trying to run the major changes for the LPC32xx platform before 
the pull request take place; see the 2 link below:
http://permalink.gmane.org/gmane.linux.drivers.devicetree/155413
http://permalink.gmane.org/gmane.linux.drivers.devicetree/155560


Sylvain Lemieux

> Roland, any chance we can get a word from you on this? Thanks!
> 
> 
> -Olof
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel




From linus.walleij at linaro.org  Thu Feb 25 06:16:46 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 15:16:46 +0100
Subject: [PATCH v6] Fix sun7i pin assignment for IRQ's
In-Reply-To: <20160225005412.GB4736@lukather>
References: <1456161251-2303-1-git-send-email-henry@nitronetworks.nl>
 <20160225005412.GB4736@lukather>
Message-ID: <CACRpkdYmf8-ZPV5q9H3cdZtQDUkbx=bcrVg9a8M3zEAifXxF9A@mail.gmail.com>

On Thu, Feb 25, 2016 at 1:54 AM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
>
> Usually, the patch title should be prefixed by the subsystem it
> applies to so that maintainer and reviewers can spot it more
> easily. In this case, it would be something like
>
> pinctrl: sunxi: Fix sun7i pin assignment for IRQ's
>
> On Mon, Feb 22, 2016 at 06:14:07PM +0100, Henry Paulissen wrote:
>> After testing IRQ pins we found some bugs in the pinctrl declaration.
>> Both PI* and PC* pins didn't work. PI* pins seemed to be connected
>> to the wrong mux and PC* pins waren't working at all.
>>
>> Please note that the A20 soc manual is contradicting between version
>> and even within the same document for both the PI and PC pins.
>
> Which sections are in contradiction?
>
>> Patch is based on testing with the hardware itself.
>
> How did you test it? Using the sysfs API, or did you have any hardware
> connected to it?

I'm taking this patch out of my tree now following Maxime's comments.

I'm a bit annoyed that it is iterating too quickly as well, I will
wait and see for a while.

Yours,
Linus Walleij


From gregory.clement at free-electrons.com  Thu Feb 25 06:22:26 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 25 Feb 2016 15:22:26 +0100
Subject: [GIT PULL] ARM: mvebu: arm64 for v4.6 (#1)
In-Reply-To: <20160225005543.GA29055@localhost> (Olof Johansson's message of
 "Wed, 24 Feb 2016 16:55:43 -0800")
References: <878u2js4cn.fsf@free-electrons.com>
 <20160225005543.GA29055@localhost>
Message-ID: <87wppsoonx.fsf@free-electrons.com>

Hi Olof,
 
 On jeu., f?vr. 25 2016, Olof Johansson <olof at lixom.net> wrote:

> On Wed, Feb 17, 2016 at 05:12:40PM +0100, Gregory CLEMENT wrote:
>> Hi,
>> 
>> Here is the first pull request for arm64 for mvebu for v4.6. It is even
>> the first pull request ever for arm64 for us. Let me know if I am doing
>> it wrong.
>> 
>> I split my initial series[1] in two parts: device tree related and non
>> device tree related. I will also let the driver maintainers directly
>> take the related patch for ATA and serial.
>> 
>> For this non device tree part I have a dependency with the irchip
>> subsystem. For this I based on the irqchip/mvebu immutable branch form
>> Jason Cooper located at git://git.infradead.org/users/jcooper/linux.git.
>> 
>> Thanks,
>> 
>> Gregory
>> 
>> [1]: https://lkml.org/lkml/2016/2/16/735
>> 
>> The following changes since commit 63131b636a0ec969e8b98122c1a928b5a2649d3b:
>> 
>>   irqchip/armada-370-xp: Do not enable it by default when ARCH_MVEBU is selected (2016-02-16 18:11:39 +0000)
>
> PLease do this by explicit merge instead in the future, so it's obvious that
> there is an external branch merged in history later.
>
> That way, doing the full diffstat including the merge is just fine too.

Actually I did an explicite merge but my start commit for the pull
request was the last commit of the merged branch. So if I undrestand
well, I sould have used the v4.5-rc2 here as start commit.

Thanks,

Gregory
>
>
>> are available in the git repository at:
>> 
>>   git://git.infradead.org/linux-mvebu.git tags/mvebu-arm64-4.6-1
>> 
>> for you to fetch changes up to e772ca05cceb1480bdc7a7579e042b18558d0959:
>> 
>>   arm64: defconfig: enable Armada 3700 related config (2016-02-17 16:23:20 +0100)
>
> Merged, thanks!
>
>
> -Olof

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From gregory.clement at free-electrons.com  Thu Feb 25 06:23:18 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 25 Feb 2016 15:23:18 +0100
Subject: [GIT PULL] ARM: mvebu: dt64 for v4.6 (#1)
In-Reply-To: <20160225005608.GB29055@localhost> (Olof Johansson's message of
 "Wed, 24 Feb 2016 16:56:08 -0800")
References: <877fi3s48z.fsf@free-electrons.com>
 <20160225005608.GB29055@localhost>
Message-ID: <87si0goomh.fsf@free-electrons.com>

Hi Olof,
 
 On jeu., f?vr. 25 2016, Olof Johansson <olof at lixom.net> wrote:

> On Wed, Feb 17, 2016 at 05:14:52PM +0100, Gregory CLEMENT wrote:
>> Hi,
>> 
>> Here is the first pull request for dt64 for mvebu for v4.6.
>> 
>> This is the second part of the Armada 3700 series[1]. This part is
>> easier to handle as there is no dependency. As for the other one, let me
>> know if I should do it in a different way.
>> 
>> Thanks,
>> 
>> Gregory
>> 
>> [1]: https://lkml.org/lkml/2016/2/16/735
>> 
>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>> 
>>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>> 
>> are available in the git repository at:
>> 
>>   git://git.infradead.org/linux-mvebu.git tags/mvebu-dt64-4.6-1
>> 
>> for you to fetch changes up to adbc3695d9e487fa07214140a46b68ac3156fb78:
>> 
>>   arm64: dts: add the Marvell Armada 3700 family and a development board (2016-02-17 16:09:55 +0100)
>> 
>> ----------------------------------------------------------------
>> mvebu dt64 for 4.6 (part 1)
>> 
>> Device tree part of the Armada 3700 support:
>> - binding for the Armada 3700 SoCs
>> - device tree files for the SoCs and a board
>> - tidy up the Marvell related files
>> 
>> ----------------------------------------------------------------
>> Gregory CLEMENT (4):
>>       Documentation: dt-bindings: Add a new compatible for the Armada 3700
>>       Documentation: dt: Tidy up the Marvell related files
>>       devicetree: bindings: add DT binding for the Marvell Armada 3700 SoC family
>>       arm64: dts: add the Marvell Armada 3700 family and a development board
>
> Merged, thanks.
>
> In the future, please use arm64: dts: marvell: ...

OK, I will do it for the next PR.

Thanks,

Gregory

>
>
> -Olof
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From arnd at arndb.de  Thu Feb 25 06:23:27 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 15:23:27 +0100
Subject: [PATCH 3/4] ARM: realview: imply Device Tree config
In-Reply-To: <1456406111-18579-4-git-send-email-linus.walleij@linaro.org>
References: <1456406111-18579-1-git-send-email-linus.walleij@linaro.org>
 <1456406111-18579-4-git-send-email-linus.walleij@linaro.org>
Message-ID: <2805017.I27kg8jfk6@wuerfel>

On Thursday 25 February 2016 14:15:10 Linus Walleij wrote:
> @@ -32,8 +24,9 @@ config REALVIEW_DT
>         select USE_OF
>         select ZONE_DMA

The 'select USE_OF' can now be dropped, I guess this was left over
from the multiplatform patches, but also fits in here.

>         help
> -         Include support for booting the ARM(R) RealView(R) evaluation
> -         boards using a device tree machine description.
> +         This enables support for ARM Ltd RealView boards.
> +
> +if ARCH_REALVIEW
>  
>  config REALVIEW_HIGH_PHYS_OFFSET
>         bool "High physical base address for the RealView platform"
> 

REALVIEW_HIGH_PHYS_OFFSET can go away as well, as it is only used
in 'realview_fixup', which in turn is called by the removed board
files.

	Arnd


From blogic at openwrt.org  Thu Feb 25 06:24:49 2016
From: blogic at openwrt.org (John Crispin)
Date: Thu, 25 Feb 2016 15:24:49 +0100
Subject: [PATCH 39/50] pinctrl: lantiq: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-40-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-40-git-send-email-ldewangan@nvidia.com>
Message-ID: <56CF0EB1.304@openwrt.org>



On 24/02/2016 14:16, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>

Acked-by: John Crispin <blogic at openwrt.org>




> ---
>  drivers/pinctrl/pinctrl-lantiq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-lantiq.c b/drivers/pinctrl/pinctrl-lantiq.c
> index fc38a85..a4d6474 100644
> --- a/drivers/pinctrl/pinctrl-lantiq.c
> +++ b/drivers/pinctrl/pinctrl-lantiq.c
> @@ -336,7 +336,7 @@ int ltq_pinctrl_register(struct platform_device *pdev,
>  	desc->pmxops = &ltq_pmx_ops;
>  	info->dev = &pdev->dev;
>  
> -	info->pctrl = pinctrl_register(desc, &pdev->dev, info);
> +	info->pctrl = devm_pinctrl_register(&pdev->dev, desc, info);
>  	if (IS_ERR(info->pctrl)) {
>  		dev_err(&pdev->dev, "failed to register LTQ pinmux driver\n");
>  		return PTR_ERR(info->pctrl);
> 


From arnd at arndb.de  Thu Feb 25 06:29:08 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 15:29:08 +0100
Subject: [PATCH 0/4] RealView boardfile endgame
In-Reply-To: <1456406111-18579-1-git-send-email-linus.walleij@linaro.org>
References: <1456406111-18579-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <5411123.nOOnE7uo7z@wuerfel>

On Thursday 25 February 2016 14:15:07 Linus Walleij wrote:
> This patch set deletes the RealView board files and moves it
> over to a pure Device Tree boot, deleting ~3500 LoC.
> 
> Prerequisites:
> - The MTD driver patch handling the flash memory write
>   protection and VPP enable must go into the MTD subsystem.
>   http://marc.info/?l=linux-arm-kernel&m=145380689210787&w=2
> 
> - The CLCD device tree support patches (uncontroversial set)
>   must go into the FBDEV subsystem.
>   http://marc.info/?l=linux-fbdev&m=145622172219039&w=2
> 
> - I must queue the device tree patches for the Evaluation
>   Boards and Platform Baseboard and Platform Baseboard
>   Explore before these patches.
> 
> However this is how it will look once the above is in place,
> and it will support everything the kernel already supports
> today.
> 
> Tested on the real hardware for PB1176JZF-S and PB11MPCore.
> Tested on QEMU for 1136, 1176, 11MPCore and Cortex-A9 EB,
> Platform Baseboard for Cortex-A8 and Platform Baseboard Explore
> for Cortex-A9 variants.
> 

Awesome!

This leaves the question whether we should do all the preparation
in 4.6 and then only take these for 4.7, or do them all at
once. I can see good reasons either way, but none of them
particularly strong. What did you have in mind here?

	Arnd


From arnd at arndb.de  Thu Feb 25 06:33:46 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 15:33:46 +0100
Subject: [PATCH] serial: sa1100: make sa1100_register_uart_fns a function
Message-ID: <1456410835-3808962-1-git-send-email-arnd@arndb.de>

Calling sa1100_register_uart_fns() leaves the port structure
unused when CONFIG_SERIAL_SA1100 is disabled, and we get a
compiler warning about that:

arch/arm/mach-sa1100/badge4.c:317:31: warning: 'badge4_port_fns' defined but not used [-Wunused-variable]
 static struct sa1100_port_fns badge4_port_fns __initdata = {

This turns the two empty macros into empty inline functions,
which has the same effect, but lets the compiler know that the
variables are intentionally unused.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Acked-by: Linus Walleij <linus.walleij at linaro.org>
---
 include/linux/platform_data/sa11x0-serial.h | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/linux/platform_data/sa11x0-serial.h b/include/linux/platform_data/sa11x0-serial.h
index 4504d5d592f0..009e1d83fe39 100644
--- a/include/linux/platform_data/sa11x0-serial.h
+++ b/include/linux/platform_data/sa11x0-serial.h
@@ -26,8 +26,12 @@ struct sa1100_port_fns {
 void sa1100_register_uart_fns(struct sa1100_port_fns *fns);
 void sa1100_register_uart(int idx, int port);
 #else
-#define sa1100_register_uart_fns(fns) do { } while (0)
-#define sa1100_register_uart(idx,port) do { } while (0)
+static inline void sa1100_register_uart_fns(struct sa1100_port_fns *fns)
+{
+}
+static inline void sa1100_register_uart(int idx, int port)
+{
+}
 #endif
 
 #endif
-- 
2.7.0



From joro at 8bytes.org  Thu Feb 25 06:34:03 2016
From: joro at 8bytes.org (Joerg Roedel)
Date: Thu, 25 Feb 2016 15:34:03 +0100
Subject: [PATCH v2 00/13] SYSMMU driver update and support for Exynos 5433
In-Reply-To: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
References: <1455804780-9616-1-git-send-email-m.szyprowski@samsung.com>
Message-ID: <20160225143403.GC16675@8bytes.org>

On Thu, Feb 18, 2016 at 03:12:47PM +0100, Marek Szyprowski wrote:
> Marek Szyprowski (13):
>   iommu: exynos: rework iommu group initialization
>   iommu: exynos: add support for IOMMU_DOMAIN_DMA domain type
>   iommu: exynos: remove ARM-specific cache flush interface
>   iommu: exynos: simplify master clock operations
>   iommu: exynos: refactor code (no direct register access)
>   iommu: exynos: refactor fault handling code
>   iommu: exynos: refactor init config code
>   iommu: exynos: unify code for fldp cache invalidation
>   iommu: exynos: add support for SYSMMU controller with bogus version
>     reg
>   iommu: exynos: update device tree documentation
>   iommu: exynos: add support for v5 SYSMMU
>   iommu: exynos: add Maintainers entry for Exynos SYSMMU driver
>   iommu: exynos: support multiple attach_device calls
> 
>  .../devicetree/bindings/iommu/samsung,sysmmu.txt   |  22 +-
>  MAINTAINERS                                        |   6 +
>  drivers/iommu/Kconfig                              |   2 +-
>  drivers/iommu/exynos-iommu.c                       | 598 ++++++++++++---------
>  4 files changed, 372 insertions(+), 256 deletions(-)

Applied all patches and changed the subjects to:

Marek Szyprowski (13):
      iommu/exynos: Rework iommu group initialization
      iommu/exynos: Add support for IOMMU_DOMAIN_DMA domain type
      iommu/exynos: Remove ARM-specific cache flush interface
      iommu/exynos: Simplify master clock operations
      iommu/exynos: Refactor code (no direct register access)
      iommu/exynos: Refactor fault handling code
      iommu/exynos: Refactor init config code
      iommu/exynos: Unify code for fldp cache invalidation
      iommu/exynos: Add support for SYSMMU controller with bogus version reg
      iommu/exynos: Update device tree documentation
      iommu/exynos: Add support for v5 SYSMMU
      iommu/exynos: Add Maintainers entry for Exynos SYSMMU driver
      iommu/exynos: Support multiple attach_device calls

Please make sure you follow this sheme for future iommu patches too.

Thanks,

	Joerg



From arnd at arndb.de  Thu Feb 25 06:34:37 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 15:34:37 +0100
Subject: [PATCH] ARM: sa1100: make sa1100_register_uart_fns a function
In-Reply-To: <CACRpkdbJpYD2Ke-f2QP+-fy_LcxhiV99OEH_D=CMtSvedEveVA@mail.gmail.com>
References: <1456238094-778916-1-git-send-email-arnd@arndb.de>
 <CACRpkdbJpYD2Ke-f2QP+-fy_LcxhiV99OEH_D=CMtSvedEveVA@mail.gmail.com>
Message-ID: <133317017.7Cfvjc5WMX@wuerfel>

On Thursday 25 February 2016 14:18:44 Linus Walleij wrote:
> On Tue, Feb 23, 2016 at 3:34 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> 
> > Calling sa1100_register_uart_fns() leaves the port structure
> > unused when CONFIG_SERIAL_SA1100 is disabled, and we get a
> > compiler warning about that:
> >
> > arch/arm/mach-sa1100/badge4.c:317:31: warning: 'badge4_port_fns' defined but not used [-Wunused-variable]
> >  static struct sa1100_port_fns badge4_port_fns __initdata = {
> >
> > This turns the two empty macros into empty inline functions,
> > which has the same effect, but lets the compiler know that the
> > variables are intentionally unused.
> >
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> 
> Acked-by: Linus Walleij <linus.walleij at linaro.org>
> 
> >  include/linux/platform_data/sa11x0-serial.h | 8 ++++++--
> 
> It looks like you should send this to Greg?

Yes, good point.

The file was traditionally under arch/arm (or include/asm-arm before
that), but considering it as part of the driver makes slightly
more sense now.

Sent out with a modified subject and your Ack to Greg now.

	Arnd


From pantelis.antoniou at konsulko.com  Thu Feb 25 06:35:00 2016
From: pantelis.antoniou at konsulko.com (Pantelis Antoniou)
Date: Thu, 25 Feb 2016 16:35:00 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CACRpkdZ=PR6O28NQusUEipCYwRZyuhbeAJO_ZK80+4H7Zakt=g@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
 <56CC546A.9070705@ti.com> <20160224104638.GL19428@n2100.arm.linux.org.uk>
 <56CD924F.50108@ti.com> <B8A82546-46C7-4A21-92D8-62418E49FBB6@konsulko.com>
 <CACRpkdZ=PR6O28NQusUEipCYwRZyuhbeAJO_ZK80+4H7Zakt=g@mail.gmail.com>
Message-ID: <DF3259B0-8A3A-4AB0-A805-F5A8F7295E5C@konsulko.com>

Hi Linus,

> On Feb 25, 2016, at 15:43 , Linus Walleij <linus.walleij at linaro.org> wrote:
> 
> On Wed, Feb 24, 2016 at 1:13 PM, Pantelis Antoniou
> <pantelis.antoniou at konsulko.com> wrote:
> 
>> IMHO DT+overlays handle all your cases just fine.
>> 
>> As far as I see these are the cases which we need to handle:
>> 
>> 1) The expansion board in question has some means of identification, whether it?s an
>> EEPROM or a GPIO keying combination etc. In that case it is the kernel?s job to match this
>> id value with a dtbo firmware file and apply it. The blob is located via means of request_firmware().
> 
> Since the dawn of time the x86 people used that console to display
> the early boot crawl and collect crash data. What you're suggesting
> is that we can't get the console up until after the filesystems and mounts
> are up so the kernel can read firmware files.
> 
> This kills of early boot graphics and getting crash logs on the fbdev
> console until that has happened.
> 
> It also means there is no way to get the console up without the right
> firmware files in the filesystem. I think that is really crap compared
> to what we have today where the display will always come up, and
> basically a regression.
> 
> I understand the stance with respect to things like add-on hardware
> like a Bluetooth board or WLAN or whatnot. But the fbdev console
> is just too basic, like a serial port IMO.
> 
> Sure in the ARM world we usually have a serial console, but this is
> seriously breaking current practice.
> 

As Tomi mentioned firmware files can be located in the kernel image; there is no
requirement to be in a filesystem, and that application can be performed really
early, before even early init.

The comparison with x86 is not absolutely valid, since on x86 you know that
the video hardware is going to be present, always.

This is not so in ARM world, especially in the case we?re talking about, an add-on board.

> Yours,
> Linus Walleij

Regards

? Pantelis



From joro at 8bytes.org  Thu Feb 25 06:38:55 2016
From: joro at 8bytes.org (joro at 8bytes.org)
Date: Thu, 25 Feb 2016 15:38:55 +0100
Subject: RFC: extend IOMMU attributes
In-Reply-To: <HE1PR04MB1641F22E38710B68F4ED891F8DAF0@HE1PR04MB1641.eurprd04.prod.outlook.com>
References: <HE1PR04MB1641F22E38710B68F4ED891F8DAF0@HE1PR04MB1641.eurprd04.prod.outlook.com>
Message-ID: <20160225143855.GD16675@8bytes.org>

On Thu, Feb 18, 2016 at 04:16:26PM +0000, Stuart Yoder wrote:
>  #define IOMMU_READ            (1 << 0)
>  #define IOMMU_WRITE           (1 << 1)
> -#define IOMMU_CACHE           (1 << 2) /* DMA cache coherency */
> +#define IOMMU_CACHE_COHERENT  (1 << 2) /* cacheable and coherent */
>  #define IOMMU_NOEXEC          (1 << 3)
>  #define IOMMU_MMIO            (1 << 4) /* e.g. things like MSI doorbells */
> +#define IOMMU_CACHEABLE       (1 << 5) /* cacheable, not coherent */
> +#define IOMMU_CACHE_ALLOCATE  (1 << 6) /* hint to allocate in the cache */

Hmm, this might be a valid use-case to introduce the
map_attr()/unmap_attr() calls to the IOMMU-API. I have been resistant to
these functions until now because the proposed use-cases were not
convincing, but for hardware-specific map-attributes like this one it
could make sense.


	Joerg



From arnd at arndb.de  Thu Feb 25 06:44:44 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 15:44:44 +0100
Subject: [RFC 3/3] iommu: dma-iommu: use common implementation also on ARM
 architecture
In-Reply-To: <56CEF2E9.5040706@samsung.com>
References: <1455870164-25337-1-git-send-email-m.szyprowski@samsung.com>
 <2724572.qtPjgumFDJ@wuerfel> <56CEF2E9.5040706@samsung.com>
Message-ID: <4895295.FP9RzJmAYS@wuerfel>

On Thursday 25 February 2016 13:26:17 Marek Szyprowski wrote:
> >> +}
> >> +
> >> +extern void *arch_alloc_from_atomic_pool(size_t size, struct page **ret_page,
> >> +                                     gfp_t flags);
> >> +extern bool arch_in_atomic_pool(void *start, size_t size);
> >> +extern int arch_free_from_atomic_pool(void *start, size_t size);
> >> +
> >> +
> > doesn't feel completely right yet. In particular the arch_flush_page()
> > interface is probably still too specific to ARM/ARM64 and won't work
> > that way on other architectures.
> >
> > I think it would be better to do this either more generic, or less generic:
> >
> > a) leave the iommu_dma_map_ops definition in the architecture specific
> >     code, but make it call helper functions in the drivers/iommu to do all
> >     of the really generic parts.
> >
> > b) clarify that this is only applicable to arch/arm and arch/arm64, and
> >     unify things further between these two, as they have very similar
> >     requirements in the CPU architecture.
> 
> Some really generic parts are already in iommu/dma-iommu.c and one can build
> it's own, non-ARM CPU architecture based IOMMU/DMA-mapping code. Initially I
> also wanted to use that generic code on both ARM and ARM64, but it 
> turned out
> that both archs, ARM and ARM64 will duplicate 99% of code, which use this
> 'generic' functions. This was the reason why I dedided to move all that
> common code from arch/{arm,arm64}/mm/dma-mapping.c to
> drivers/iommu/dma-iommu-ops.c
> 
> I'm not sure if I can design all the changes that need to be made to
> drivers/iommu/dma-iommu-ops.c to make it more generic. Maybe when one will
> try to use that code with other, non-ARM architecture based arch glue code,
> a better abstraction can be developed. For now I would like to keep all this
> code in a common place so both arm and arm64 will benefit from improvements
> done there.

Fair enough. Let's stay with your approach then.

	Arnd


From p.zabel at pengutronix.de  Thu Feb 25 06:46:50 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 25 Feb 2016 15:46:50 +0100
Subject: [PATCH 01/50] pinctrl: Add devm_ apis for pinctrl_{register,
 unregister}
In-Reply-To: <1456319775-3216-2-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-2-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456411610.3268.13.camel@pengutronix.de>

Hi Laxman,

Am Mittwoch, den 24.02.2016, 18:45 +0530 schrieb Laxman Dewangan:
> Add device managed APIs devm_pinctrl_register() and
> devm_pinctrl_unregister() for the APIs pinctrl_register()
> and pinctrl_unregister().
> 
> This helps in reducing code in error path and sometimes
> removal of .remove callback for driver unbind.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> ---
>  drivers/pinctrl/core.c          | 69 +++++++++++++++++++++++++++++++++++++++++
>  include/linux/pinctrl/pinctrl.h |  6 ++++
>  2 files changed, 75 insertions(+)
> 
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> index 2686a44..ea4a7e6 100644
> --- a/drivers/pinctrl/core.c
> +++ b/drivers/pinctrl/core.c
> @@ -1861,6 +1861,75 @@ void pinctrl_unregister(struct pinctrl_dev *pctldev)
>  }
>  EXPORT_SYMBOL_GPL(pinctrl_unregister);
>  
> +static void devm_pinctrl_dev_release(struct device *dev, void *res)
> +{
> +	struct pinctrl_dev *pctldev = *(struct pinctrl_dev **)res;
> +
> +	pinctrl_unregister(pctldev);
> +}
> +
> +static int devm_pinctrl_dev_match(struct device *dev, void *res, void *data)
> +{
> +	struct pctldev **r = res;
> +
> +	if (!r || !*r) {
> +		WARN_ON(!r || !*r);
> +		return 0;
> +	}


This could be simplified to

	if (WARN_ON(!r || !*r))
		return 0;

> +
> +	return *r == data;
> +}
> +
> +/**
> + * devm_pinctrl_register() - Resource manager pinctrl_register()

Should that be "Resource managed" ?

> + * @dev: parent device for this pin controller
> + * @pctldesc: descriptor for this pin controller
> + * @driver_data: private pin controller data for this pin controller
> + *
> + * Returns an error pointer if pincontrol register failed. Otherwise
> + * it returns valid pinctrl handle.
> + *
> + * The pinctrl device will be automatically released when the device is unbound.
> + */
> +struct pinctrl_dev *devm_pinctrl_register(struct device *dev,
> +					  struct pinctrl_desc *pctldesc,
> +					  void *driver_data)
> +{
> +	struct pinctrl_dev **ptr, *pctldev;
> +
> +	ptr = devres_alloc(devm_pinctrl_dev_release, sizeof(*ptr), GFP_KERNEL);
> +	if (!ptr)
> +		return ERR_PTR(-ENOMEM);
> +
> +	pctldev = pinctrl_register(pctldesc, dev, driver_data);
> +	if (IS_ERR(pctldev)) {
> +		devres_free(ptr);
> +		return pctldev;
> +	}
> +
> +	*ptr = pctldev;
> +	devres_add(dev, ptr);
> +
> +	return pctldev;
> +}
> +EXPORT_SYMBOL_GPL(devm_pinctrl_register);
> +
> +/**
> + * devm_pinctrl_unregister() - Resource manager of pinctrl_unregister()

Should that be "Resource managed version of" ?

> + * @dev: device for which which resource was allocated
> + * @pctldev: the pinctrl device to unregister.
> + */
> +void devm_pinctrl_unregister(struct device *dev, struct pinctrl_dev *pctldev)
> +{
> +	int ret;
> +
> +	ret = devres_release(dev, devm_pinctrl_dev_release,
> +			     devm_pinctrl_dev_match, pctldev);
> +	if (!ret)
> +		WARN_ON(ret);
> +}
> +EXPORT_SYMBOL_GPL(devm_pinctrl_unregister);
> +
>  static int __init pinctrl_init(void)
>  {
>  	pr_info("initialized pinctrl subsystem\n");
> diff --git a/include/linux/pinctrl/pinctrl.h b/include/linux/pinctrl/pinctrl.h
> index 9ba59fc..a42e57d 100644
> --- a/include/linux/pinctrl/pinctrl.h
> +++ b/include/linux/pinctrl/pinctrl.h
> @@ -144,6 +144,12 @@ struct pinctrl_desc {
>  extern struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
>  				struct device *dev, void *driver_data);
>  extern void pinctrl_unregister(struct pinctrl_dev *pctldev);
> +extern struct pinctrl_dev *devm_pinctrl_register(struct device *dev,
> +				struct pinctrl_desc *pctldesc,
> +				void *driver_data);
> +extern void devm_pinctrl_unregister(struct device *dev,
> +				struct pinctrl_dev *pctldev);
> +
>  extern bool pin_is_valid(struct pinctrl_dev *pctldev, int pin);
>  extern void pinctrl_add_gpio_range(struct pinctrl_dev *pctldev,
>  				struct pinctrl_gpio_range *range);

With those addressed,
Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>

regards
Philipp



From p.zabel at pengutronix.de  Thu Feb 25 06:47:18 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 25 Feb 2016 15:47:18 +0100
Subject: [PATCH 09/50] pinctrl: imx: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-10-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-10-git-send-email-ldewangan@nvidia.com>
Message-ID: <1456411638.3268.14.camel@pengutronix.de>

Am Mittwoch, den 24.02.2016, 18:45 +0530 schrieb Laxman Dewangan:
> Use devm_pinctrl_register() for pin control registration and remove
> need of .remove callback.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Shawn Guo <shawnguo at kernel.org>
> Cc: Stefan Agner <stefan at agner.ch>
> Cc: Adrian Alonso <aalonso at freescale.com>
> Cc: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de>
[...]

Reviewed-by: Philipp Zabel <p.zabel at pengutronix.de>

regards
Philipp



From chf.fritz at googlemail.com  Thu Feb 25 06:47:47 2016
From: chf.fritz at googlemail.com (Christoph Fritz)
Date: Thu, 25 Feb 2016 15:47:47 +0100
Subject: [PATCH v3 0/2] Add PCIe driver support for imx6sx
Message-ID: <1456411669-4699-1-git-send-email-chf.fritz@googlemail.com>

v3:
 * adapt devicetree bindings documentation fsl,imx6q-pcie.txt
v2:
 * leave out regulator handling from driver, will be done later
   in PM subsystem 
 * use BIT() macro for MFD

Christoph Fritz (2):
  MFD: imx6sx: Add PCIe register definitions for iomuxc gpr
  PCI: imx6: add initial imx6sx support

 .../devicetree/bindings/pci/fsl,imx6q-pcie.txt     |   6 +-
 drivers/pci/host/pci-imx6.c                        | 130 ++++++++++++++-------
 include/linux/mfd/syscon/imx6q-iomuxc-gpr.h        |   5 +
 3 files changed, 101 insertions(+), 40 deletions(-)

-- 
2.1.4



From chf.fritz at googlemail.com  Thu Feb 25 06:47:48 2016
From: chf.fritz at googlemail.com (Christoph Fritz)
Date: Thu, 25 Feb 2016 15:47:48 +0100
Subject: [PATCH v3 1/2] MFD: imx6sx: Add PCIe register definitions for iomuxc
 gpr
In-Reply-To: <1456411669-4699-1-git-send-email-chf.fritz@googlemail.com>
References: <1456411669-4699-1-git-send-email-chf.fritz@googlemail.com>
Message-ID: <1456411669-4699-2-git-send-email-chf.fritz@googlemail.com>

This patch adds macros to define masks and bits for imx6sx
PCIe registers. This is based on a patch by Richard Zhu.

Signed-off-by: Christoph Fritz <chf.fritz at googlemail.com>
---
 include/linux/mfd/syscon/imx6q-iomuxc-gpr.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
index 558a485..238c8db 100644
--- a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
+++ b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
@@ -422,6 +422,7 @@
 #define IMX6SX_GPR5_VADC_TO_CSI_CAPTURE_EN_MASK		(0x1 << 26)
 #define IMX6SX_GPR5_VADC_TO_CSI_CAPTURE_EN_ENABLE	(0x1 << 26)
 #define IMX6SX_GPR5_VADC_TO_CSI_CAPTURE_EN_DISABLE	(0x0 << 26)
+#define IMX6SX_GPR5_PCIE_BTNRST_RESET			BIT(19)
 #define IMX6SX_GPR5_CSI1_MUX_CTRL_MASK			(0x3 << 4)
 #define IMX6SX_GPR5_CSI1_MUX_CTRL_EXT_PIN		(0x0 << 4)
 #define IMX6SX_GPR5_CSI1_MUX_CTRL_CVD			(0x1 << 4)
@@ -435,6 +436,10 @@
 #define IMX6SX_GPR5_DISP_MUX_DCIC1_LVDS			(0x1 << 1)
 #define IMX6SX_GPR5_DISP_MUX_DCIC1_MASK			(0x1 << 1)
 
+#define IMX6SX_GPR12_PCIE_TEST_POWERDOWN		BIT(30)
+#define IMX6SX_GPR12_PCIE_RX_EQ_MASK			(0x7 << 0)
+#define IMX6SX_GPR12_PCIE_RX_EQ_2			(0x2 << 0)
+
 /* For imx6ul iomux gpr register field define */
 #define IMX6UL_GPR1_ENET1_CLK_DIR		(0x1 << 17)
 #define IMX6UL_GPR1_ENET2_CLK_DIR		(0x1 << 18)
-- 
2.1.4



From chf.fritz at googlemail.com  Thu Feb 25 06:47:49 2016
From: chf.fritz at googlemail.com (Christoph Fritz)
Date: Thu, 25 Feb 2016 15:47:49 +0100
Subject: [PATCH v3 2/2] PCI: imx6: add initial imx6sx support
In-Reply-To: <1456411669-4699-1-git-send-email-chf.fritz@googlemail.com>
References: <1456411669-4699-1-git-send-email-chf.fritz@googlemail.com>
Message-ID: <1456411669-4699-3-git-send-email-chf.fritz@googlemail.com>

This patch adds initial PCIe support for the imx6 SoC derivate imx6sx.
PCI_MSI support is untested as its necessary suspend/resume quirk is
left out of this patch.
This patch is heavily based on patches by Richard Zhu.

Signed-off-by: Christoph Fritz <chf.fritz at googlemail.com>
---
 .../devicetree/bindings/pci/fsl,imx6q-pcie.txt     |   6 +-
 drivers/pci/host/pci-imx6.c                        | 130 ++++++++++++++-------
 2 files changed, 96 insertions(+), 40 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
index 6fbba53..c4323be 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
@@ -4,7 +4,7 @@ This PCIe host controller is based on the Synopsis Designware PCIe IP
 and thus inherits all the common properties defined in designware-pcie.txt.
 
 Required properties:
-- compatible: "fsl,imx6q-pcie"
+- compatible: "fsl,imx6q-pcie", "fsl,imx6sx-pcie"
 - reg: base addresse and length of the pcie controller
 - interrupts: A list of interrupt outputs of the controller. Must contain an
   entry for each entry in the interrupt-names property.
@@ -13,6 +13,10 @@ Required properties:
 - clock-names: Must include the following additional entries:
 	- "pcie_phy"
 
+Additional required properties for imx6sx-pcie:
+- clock names: Must include the following additional entries:
+	- "pcie_inbound_axi"
+
 Example:
 
 	pcie at 0x01000000 {
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index fe60096..7e634a6 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -35,9 +35,11 @@ struct imx6_pcie {
 	struct gpio_desc	*reset_gpio;
 	struct clk		*pcie_bus;
 	struct clk		*pcie_phy;
+	struct clk		*pcie_inbound_axi;
 	struct clk		*pcie;
 	struct pcie_port	pp;
 	struct regmap		*iomuxc_gpr;
+	bool			is_imx6sx;
 	void __iomem		*mem_base;
 };
 
@@ -214,35 +216,46 @@ static int imx6_pcie_assert_core_reset(struct pcie_port *pp)
 	struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
 	u32 val, gpr1, gpr12;
 
-	/*
-	 * If the bootloader already enabled the link we need some special
-	 * handling to get the core back into a state where it is safe to
-	 * touch it for configuration.  As there is no dedicated reset signal
-	 * wired up for MX6QDL, we need to manually force LTSSM into "detect"
-	 * state before completely disabling LTSSM, which is a prerequisite
-	 * for core configuration.
-	 *
-	 * If both LTSSM_ENABLE and REF_SSP_ENABLE are active we have a strong
-	 * indication that the bootloader activated the link.
-	 */
-	regmap_read(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, &gpr1);
-	regmap_read(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, &gpr12);
-
-	if ((gpr1 & IMX6Q_GPR1_PCIE_REF_CLK_EN) &&
-	    (gpr12 & IMX6Q_GPR12_PCIE_CTL_2)) {
-		val = readl(pp->dbi_base + PCIE_PL_PFLR);
-		val &= ~PCIE_PL_PFLR_LINK_STATE_MASK;
-		val |= PCIE_PL_PFLR_FORCE_LINK;
-		writel(val, pp->dbi_base + PCIE_PL_PFLR);
-
+	if (imx6_pcie->is_imx6sx) {
 		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
-	}
+				IMX6SX_GPR12_PCIE_TEST_POWERDOWN,
+				IMX6SX_GPR12_PCIE_TEST_POWERDOWN);
+		/* Force PCIe PHY reset */
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR5,
+					IMX6SX_GPR5_PCIE_BTNRST_RESET,
+					IMX6SX_GPR5_PCIE_BTNRST_RESET);
+	} else {
+		/*
+		 * If the bootloader already enabled the link we need some
+		 * special handling to get the core back into a state where
+		 * it is safe to touch it for configuration.  As there is no
+		 * dedicated reset signal to manually force LTSSM into "detect"
+		 * state before completely disabling LTSSM, which is a
+		 * prerequisite for core configuration.
+		 *
+		 * If both LTSSM_ENABLE and REF_SSP_ENABLE are active we have
+		 * a strong indication that the bootloader activated the link.
+		 */
+		regmap_read(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, &gpr1);
+		regmap_read(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12, &gpr12);
+
+		if ((gpr1 & IMX6Q_GPR1_PCIE_REF_CLK_EN) &&
+				(gpr12 & IMX6Q_GPR12_PCIE_CTL_2)) {
+			val = readl(pp->dbi_base + PCIE_PL_PFLR);
+			val &= ~PCIE_PL_PFLR_LINK_STATE_MASK;
+			val |= PCIE_PL_PFLR_FORCE_LINK;
+			writel(val, pp->dbi_base + PCIE_PL_PFLR);
+
+			regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+				IMX6Q_GPR12_PCIE_CTL_2, 0);
+		}
 
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
-			IMX6Q_GPR1_PCIE_TEST_PD, 1 << 18);
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
-			IMX6Q_GPR1_PCIE_REF_CLK_EN, 0 << 16);
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
+			IMX6Q_GPR1_PCIE_TEST_PD,
+			IMX6Q_GPR1_PCIE_TEST_PD);
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
+			IMX6Q_GPR1_PCIE_REF_CLK_EN, 0);
+	}
 
 	return 0;
 }
@@ -270,18 +283,30 @@ static int imx6_pcie_deassert_core_reset(struct pcie_port *pp)
 		goto err_pcie;
 	}
 
-	/* power up core phy and enable ref clock */
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
-			IMX6Q_GPR1_PCIE_TEST_PD, 0 << 18);
-	/*
-	 * the async reset input need ref clock to sync internally,
-	 * when the ref clock comes after reset, internal synced
-	 * reset time is too short, cannot meet the requirement.
-	 * add one ~10us delay here.
-	 */
-	udelay(10);
-	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
-			IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16);
+	if (imx6_pcie->is_imx6sx) {
+		ret = clk_prepare_enable(imx6_pcie->pcie_inbound_axi);
+		if (ret) {
+			dev_err(pp->dev, "unable to enable pcie_axi clock\n");
+			goto err_inbound_axi;
+		}
+
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			IMX6SX_GPR12_PCIE_TEST_POWERDOWN, 0);
+	} else {
+		/* power up core phy and enable ref clock */
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
+				IMX6Q_GPR1_PCIE_TEST_PD, 0);
+		/*
+		 * the async reset input need ref clock to sync internally,
+		 * when the ref clock comes after reset, internal synced
+		 * reset time is too short , cannot meet the requirement.
+		 * add one ~10us delay here.
+		 */
+		udelay(10);
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
+			IMX6Q_GPR1_PCIE_REF_CLK_EN,
+			IMX6Q_GPR1_PCIE_REF_CLK_EN);
+	}
 
 	/* allow the clocks to stabilize */
 	usleep_range(200, 500);
@@ -292,8 +317,15 @@ static int imx6_pcie_deassert_core_reset(struct pcie_port *pp)
 		msleep(100);
 		gpiod_set_value_cansleep(imx6_pcie->reset_gpio, 1);
 	}
+
+	if (imx6_pcie->is_imx6sx)
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR5,
+			IMX6SX_GPR5_PCIE_BTNRST_RESET, 0);
+
 	return 0;
 
+err_inbound_axi:
+	clk_disable_unprepare(imx6_pcie->pcie);
 err_pcie:
 	clk_disable_unprepare(imx6_pcie->pcie_bus);
 err_pcie_bus:
@@ -307,6 +339,12 @@ static void imx6_pcie_init_phy(struct pcie_port *pp)
 {
 	struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
 
+	if (imx6_pcie->is_imx6sx) {
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+			IMX6SX_GPR12_PCIE_RX_EQ_MASK,
+			IMX6SX_GPR12_PCIE_RX_EQ_2);
+	}
+
 	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
 			IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
 
@@ -571,6 +609,9 @@ static int __init imx6_pcie_probe(struct platform_device *pdev)
 	pp = &imx6_pcie->pp;
 	pp->dev = &pdev->dev;
 
+	imx6_pcie->is_imx6sx = of_device_is_compatible(pp->dev->of_node,
+					"fsl,imx6sx-pcie");
+
 	/* Added for PCI abort handling */
 	hook_fault_code(16 + 6, imx6q_pcie_abort_handler, SIGBUS, 0,
 		"imprecise external abort");
@@ -606,6 +647,16 @@ static int __init imx6_pcie_probe(struct platform_device *pdev)
 		return PTR_ERR(imx6_pcie->pcie);
 	}
 
+	if (imx6_pcie->is_imx6sx) {
+		imx6_pcie->pcie_inbound_axi = devm_clk_get(&pdev->dev,
+			"pcie_inbound_axi");
+		if (IS_ERR(imx6_pcie->pcie_inbound_axi)) {
+			dev_err(&pdev->dev,
+				"pcie_incbound_axi clock missing or invalid\n");
+			return PTR_ERR(imx6_pcie->pcie_inbound_axi);
+		}
+	}
+
 	/* Grab GPR config register range */
 	imx6_pcie->iomuxc_gpr =
 		 syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
@@ -632,6 +683,7 @@ static void imx6_pcie_shutdown(struct platform_device *pdev)
 
 static const struct of_device_id imx6_pcie_of_match[] = {
 	{ .compatible = "fsl,imx6q-pcie", },
+	{ .compatible = "fsl,imx6sx-pcie", },
 	{},
 };
 MODULE_DEVICE_TABLE(of, imx6_pcie_of_match);
-- 
2.1.4



From linus.walleij at linaro.org  Thu Feb 25 06:49:13 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 15:49:13 +0100
Subject: [PATCH 01/14] pinctrl: sunxi: Add A83T R_PIO controller support
In-Reply-To: <20160225005644.GC4736@lukather>
References: <1454203266-4450-1-git-send-email-vishnupatekar0510@gmail.com>
 <1454203266-4450-2-git-send-email-vishnupatekar0510@gmail.com>
 <CACRpkdbCgOBQw28d=qc1fAURY3x8UdoWqiMtXMZ=uWLaQj-nbg@mail.gmail.com>
 <20160211123648.GN31506@lukather>
 <CACRpkdaGZ4-S1A9zUUaBXXEazyJf_uZ4ESiBhw-CpozXMxfDHg@mail.gmail.com>
 <20160211151246.GO31506@lukather>
 <CACRpkdb7=x2bJP1nXpF2bP3U0t+NUHiuw_aeTAhbR8OXOrHn6A@mail.gmail.com>
 <20160225005644.GC4736@lukather>
Message-ID: <CACRpkdYQasUpLhJU16F3_GG7-wKt=wvb1Qqu2cJ62pCHLSii=g@mail.gmail.com>

On Thu, Feb 25, 2016 at 1:56 AM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:

> Hi Linus,
> On Tue, Feb 16, 2016 at 12:23:37AM +0100, Linus Walleij wrote:
>> On Thu, Feb 11, 2016 at 4:12 PM, Maxime Ripard
>> <maxime.ripard at free-electrons.com> wrote:
>> > On Thu, Feb 11, 2016 at 02:47:57PM +0100, Linus Walleij wrote:
>>
>> >> Can you guys supply a MAINTAINERS entry for the sunxi
>> >> stuff?
>> >
>> > We have one, and Chen-Yu is listed as co-maintainer:
>> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n911
>>
>> Modified request:
>> can you put in F: wildcards there to match the files pertaining to
>> the sunxi platform, so that scripts/find-maintainer.pl finds them.
>
> I don't really know what you mean, on my laptop, if I run it, I get
> the following result:

OK the file is listed under SoC support, that works too.

Yours,
Linus Walleij


From peter.ujfalusi at ti.com  Thu Feb 25 06:50:17 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 25 Feb 2016 16:50:17 +0200
Subject: [PATCH 01/11] ARM: DTS: dra7: Move the sDMA crossbar node under
 l4_cfg/scm
In-Reply-To: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
References: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1456411827-23962-2-git-send-email-peter.ujfalusi@ti.com>

Move the sDMA xbar nodes under the L4 interconnect node.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/boot/dts/dra7.dtsi | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8ea153aa46f6..114286dbee25 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -161,6 +161,15 @@
 					compatible = "syscon";
 					reg = <0x1c24 0x0024>;
 				};
+
+				sdma_xbar: dma-router at b78 {
+					compatible = "ti,dra7-dma-crossbar";
+					reg = <0xb78 0xfc>;
+					#dma-cells = <1>;
+					dma-requests = <205>;
+					ti,dma-safe-map = <0>;
+					dma-masters = <&sdma>;
+				};
 			};
 
 			cm_core_aon: cm_core_aon at 5000 {
@@ -315,15 +324,6 @@
 			dma-requests = <127>;
 		};
 
-		sdma_xbar: dma-router at 4a002b78 {
-			compatible = "ti,dra7-dma-crossbar";
-			reg = <0x4a002b78 0xfc>;
-			#dma-cells = <1>;
-			dma-requests = <205>;
-			ti,dma-safe-map = <0>;
-			dma-masters = <&sdma>;
-		};
-
 		gpio1: gpio at 4ae10000 {
 			compatible = "ti,omap4-gpio";
 			reg = <0x4ae10000 0x200>;
-- 
2.7.1



From peter.ujfalusi at ti.com  Thu Feb 25 06:50:16 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 25 Feb 2016 16:50:16 +0200
Subject: [PATCH 00/11] ARM: DTS/clk: DRA7 family: enable eDMA and audio updates
Message-ID: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>

Hi,

On dra7 family we have two DMA engine available: sDMA (omap-dma) and eDMA.
For some peripherals the use of eDMA is better due to L3 interconnect limitation
when using sDMA. Such peripherals are McASP1/2/3. By switching to eDMA we can
enable the AFIFO which will help to avoid under or overruns in audio.

This set will:
- add the hwmod data for eDMA TPCC and TPTCs
- add the needed DT nodes for eDMA and the crossbar
- we will enable the AFIFO use for audio
- add hwmod data and DT nodes for all McASP ports
- Fix the beagle-x15's clkout2 parent setting for the codec

The patch set has been tested on top of linux-next.

Regards,
Peter
---
Misael Lopez Cruz (1):
  ARM: DTS: dra7: Use eDMA and add DAT port address for McASP3

Peter Ujfalusi (10):
  ARM: DTS: dra7: Move the sDMA crossbar node under l4_cfg/scm
  ARM: DRA7: hwmod: Add data for eDMA tpcc, tptc0, tptc1
  ARM: DTS: dra7: Enable eDMA
  ARM: DTS: dra7-evm: Enable AFIFO use for McASP3
  ARM: DTS: dra72-evm: Enable AFIFO use for McASP3
  ARM: DTS: am57xx-beagle-x15: Move clkout2 source selection to codec
    node
  ARM: DTS: am57xx-beagle-x15: Enable AFIFO use for McASP3
  ARM: clk: dra7xx: Correct mcasp8_ahclkx_mux name
  ARM: DRA7: hwmod: Add data for McASP1/2/4/5/6/7/8
  ARM: DTS: dra7: Add nodes for McASP1/2/4/5/6/7/8

 arch/arm/boot/dts/am57xx-beagle-x15.dts   |   7 +-
 arch/arm/boot/dts/dra7-evm.dts            |   2 +
 arch/arm/boot/dts/dra7.dtsi               | 181 ++++++++++++++++-
 arch/arm/boot/dts/dra72-evm.dts           |   2 +
 arch/arm/boot/dts/dra7xx-clocks.dtsi      |   2 +-
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 323 ++++++++++++++++++++++++++++++
 drivers/clk/ti/clk-7xx.c                  |   2 +-
 7 files changed, 505 insertions(+), 14 deletions(-)

-- 
2.7.1



From peter.ujfalusi at ti.com  Thu Feb 25 06:50:19 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 25 Feb 2016 16:50:19 +0200
Subject: [PATCH 03/11] ARM: DTS: dra7: Enable eDMA
In-Reply-To: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
References: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1456411827-23962-4-git-send-email-peter.ujfalusi@ti.com>

DRA7 family has eDMA available along with the sDMA and in some cases it is
better suited for servicing peripherals.

Add the needed nodes for eDMA to be usable:
edma-tpcc, edma-tptc0/1 and the edma-xbar.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/boot/dts/dra7.dtsi | 48 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 114286dbee25..d2d2568b5695 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -170,6 +170,15 @@
 					ti,dma-safe-map = <0>;
 					dma-masters = <&sdma>;
 				};
+
+				edma_xbar: dma-router at c78 {
+					compatible = "ti,dra7-dma-crossbar";
+					reg = <0xc78 0x7c>;
+					#dma-cells = <2>;
+					dma-requests = <204>;
+					ti,dma-safe-map = <0>;
+					dma-masters = <&edma>;
+				};
 			};
 
 			cm_core_aon: cm_core_aon at 5000 {
@@ -324,6 +333,45 @@
 			dma-requests = <127>;
 		};
 
+		edma: edma at 43300000 {
+			compatible = "ti,edma3-tpcc";
+			ti,hwmods = "tpcc";
+			reg = <0x43300000 0x100000>;
+			reg-names = "edma3_cc";
+			interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "edma3_ccint", "emda3_mperr",
+					  "edma3_ccerrint";
+			dma-requests = <64>;
+			#dma-cells = <2>;
+
+			ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 0>;
+
+			/*
+			 * memcpy is disabled, can be enabled with:
+			 * ti,edma-memcpy-channels = <20 21>;
+			 * for example. Note that these channels need to be
+			 * masked in the xbar as well.
+			 */
+		};
+
+		edma_tptc0: tptc at 43400000 {
+			compatible = "ti,edma3-tptc";
+			ti,hwmods = "tptc0";
+			reg =	<0x43400000 0x100000>;
+			interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "edma3_tcerrint";
+		};
+
+		edma_tptc1: tptc at 43500000 {
+			compatible = "ti,edma3-tptc";
+			ti,hwmods = "tptc1";
+			reg =	<0x43500000 0x100000>;
+			interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "edma3_tcerrint";
+		};
+
 		gpio1: gpio at 4ae10000 {
 			compatible = "ti,omap4-gpio";
 			reg = <0x4ae10000 0x200>;
-- 
2.7.1



From peter.ujfalusi at ti.com  Thu Feb 25 06:50:18 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 25 Feb 2016 16:50:18 +0200
Subject: [PATCH 02/11] ARM: DRA7: hwmod: Add data for eDMA tpcc, tptc0, tptc1
In-Reply-To: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
References: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1456411827-23962-3-git-send-email-peter.ujfalusi@ti.com>

Add hwmod data for the eDMA blocks:
 - TPCC: Third-party channel controller
 - TPTC0: Third-party transfer controller 0
 - TPTC1: Third-party transfer controller 1

The TPCC is following it's clock and power domain. This means that
the hwmod can not control it's status.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 88 +++++++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index b61355e2a771..3953ad031c43 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -430,6 +430,67 @@ static struct omap_hwmod dra7xx_dma_system_hwmod = {
 };
 
 /*
+ * 'tpcc' class
+ *
+ */
+static struct omap_hwmod_class dra7xx_tpcc_hwmod_class = {
+	.name		= "tpcc",
+};
+
+static struct omap_hwmod dra7xx_tpcc_hwmod = {
+	.name		= "tpcc",
+	.class		= &dra7xx_tpcc_hwmod_class,
+	.clkdm_name	= "l3main1_clkdm",
+	.main_clk	= "l3_iclk_div",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs = DRA7XX_CM_L3MAIN1_TPCC_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3MAIN1_TPCC_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/*
+ * 'tptc' class
+ *
+ */
+static struct omap_hwmod_class dra7xx_tptc_hwmod_class = {
+	.name		= "tptc",
+};
+
+/* tptc0 */
+static struct omap_hwmod dra7xx_tptc0_hwmod = {
+	.name		= "tptc0",
+	.class		= &dra7xx_tptc_hwmod_class,
+	.clkdm_name	= "l3main1_clkdm",
+	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+	.main_clk	= "l3_iclk_div",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs = DRA7XX_CM_L3MAIN1_TPTC1_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3MAIN1_TPTC1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/* tptc1 */
+static struct omap_hwmod dra7xx_tptc1_hwmod = {
+	.name		= "tptc1",
+	.class		= &dra7xx_tptc_hwmod_class,
+	.clkdm_name	= "l3main1_clkdm",
+	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+	.main_clk	= "l3_iclk_div",
+	.prcm		= {
+		.omap4	= {
+			.clkctrl_offs = DRA7XX_CM_L3MAIN1_TPTC2_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L3MAIN1_TPTC2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_HWCTRL,
+		},
+	},
+};
+
+/*
  * 'dss' class
  *
  */
@@ -2563,6 +2624,30 @@ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__dma_system = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l3_main_1 -> tpcc */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__tpcc = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_tpcc_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU,
+};
+
+/* l3_main_1 -> tptc0 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__tptc0 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_tptc0_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU,
+};
+
+/* l3_main_1 -> tptc1 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__tptc1 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_tptc1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU,
+};
+
 static struct omap_hwmod_addr_space dra7xx_dss_addrs[] = {
 	{
 		.name		= "family",
@@ -3380,6 +3465,9 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
 	&dra7xx_l3_main_1__mcasp3,
 	&dra7xx_gmac__mdio,
 	&dra7xx_l4_cfg__dma_system,
+	&dra7xx_l3_main_1__tpcc,
+	&dra7xx_l3_main_1__tptc0,
+	&dra7xx_l3_main_1__tptc1,
 	&dra7xx_l3_main_1__dss,
 	&dra7xx_l3_main_1__dispc,
 	&dra7xx_l3_main_1__hdmi,
-- 
2.7.1



From peter.ujfalusi at ti.com  Thu Feb 25 06:50:20 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 25 Feb 2016 16:50:20 +0200
Subject: [PATCH 04/11] ARM: DTS: dra7: Use eDMA and add DAT port address for
 McASP3
In-Reply-To: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
References: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1456411827-23962-5-git-send-email-peter.ujfalusi@ti.com>

From: Misael Lopez Cruz <misael.lopez at ti.com>

McASP3 does not support constant addressing mode on the DAT
port, so increment transfers must be used instead.  This
restriction is also applicable for McASP1 and McASP2.

This DMA addressing constraint poses a major problem for sDMA
where constant addressing mode is used on the peripheral side.
Unfortunately, using increment transfers in sDMA comes with
important side effects.

The addressing mode used in eDMA is INC, so the silicon limitation
described above has no impact and the McASP3 DAT port can be
safely added by switching to eDMA instead of sDMA.

Signed-off-by: Misael Lopez Cruz <misael.lopez at ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/boot/dts/dra7.dtsi | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d2d2568b5695..258e6712a76b 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1467,12 +1467,13 @@
 		mcasp3: mcasp at 48468000 {
 			compatible = "ti,dra7-mcasp-audio";
 			ti,hwmods = "mcasp3";
-			reg = <0x48468000 0x2000>;
-			reg-names = "mpu";
+			reg = <0x48468000 0x2000>,
+			      <0x46000000 0x1000>;
+			reg-names = "mpu","dat";
 			interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "tx", "rx";
-			dmas = <&sdma_xbar 133>, <&sdma_xbar 132>;
+			dmas = <&edma_xbar 133 1>, <&edma_xbar 132 1>;
 			dma-names = "tx", "rx";
 			clocks = <&mcasp3_aux_gfclk_mux>, <&mcasp3_ahclkx_mux>;
 			clock-names = "fck", "ahclkx";
-- 
2.7.1



From peter.ujfalusi at ti.com  Thu Feb 25 06:50:21 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 25 Feb 2016 16:50:21 +0200
Subject: [PATCH 05/11] ARM: DTS: dra7-evm: Enable AFIFO use for McASP3
In-Reply-To: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
References: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1456411827-23962-6-git-send-email-peter.ujfalusi@ti.com>

Since we switched to use eDMA we can now safely enable the FIFO in McASP.
This will reduce the chance of McASP level under/overflow.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/boot/dts/dra7-evm.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index cfc24e52244e..ebdbfcc96a6f 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -901,6 +901,8 @@
 	serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
 		1 2 0 0
 	>;
+	tx-num-evt = <32>;
+	rx-num-evt = <32>;
 };
 
 &mailbox5 {
-- 
2.7.1



From peter.ujfalusi at ti.com  Thu Feb 25 06:50:22 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 25 Feb 2016 16:50:22 +0200
Subject: [PATCH 06/11] ARM: DTS: dra72-evm: Enable AFIFO use for McASP3
In-Reply-To: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
References: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1456411827-23962-7-git-send-email-peter.ujfalusi@ti.com>

Since we switched to use eDMA we can now safely enable the FIFO in McASP.
This will reduce the chance of McASP level under/overflow.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/boot/dts/dra72-evm.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 00b12002c07c..18711124616a 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -831,6 +831,8 @@
 	serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
 		1 2 0 0
 	>;
+	tx-num-evt = <32>;
+	rx-num-evt = <32>;
 };
 
 &mailbox5 {
-- 
2.7.1



From peter.ujfalusi at ti.com  Thu Feb 25 06:50:24 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 25 Feb 2016 16:50:24 +0200
Subject: [PATCH 08/11] ARM: DTS: am57xx-beagle-x15: Enable AFIFO use for McASP3
In-Reply-To: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
References: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1456411827-23962-9-git-send-email-peter.ujfalusi@ti.com>

Since we switched to use eDMA we can now safely enable the FIFO in McASP.
This will reduce the chance of McASP level under/overflow.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 86351372174f..7e1d11177732 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -813,6 +813,8 @@
 	serial-dir = <	/* 0: INACTIVE, 1: TX, 2: RX */
 		1 2 0 0
 	>;
+	tx-num-evt = <32>;
+	rx-num-evt = <32>;
 };
 
 &mailbox5 {
-- 
2.7.1



From peter.ujfalusi at ti.com  Thu Feb 25 06:50:23 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 25 Feb 2016 16:50:23 +0200
Subject: [PATCH 07/11] ARM: DTS: am57xx-beagle-x15: Move clkout2 source
 selection to codec node
In-Reply-To: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
References: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1456411827-23962-8-git-send-email-peter.ujfalusi@ti.com>

The assigned-clock* needs to be in the root of the device's node. If it is
in the sub-node the CCF will ignore it.
Since the clkout2 is used by the codec as MCLK, move the clock parent
selection to that node.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index b25d68496c7d..86351372174f 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -173,8 +173,6 @@
 
 		sound0_master: simple-audio-card,codec {
 			sound-dai = <&tlv320aic3104>;
-			assigned-clocks = <&clkoutmux2_clk_mux>;
-			assigned-clock-parents = <&sys_clk2_dclk_div>;
 			clocks = <&clkout2_clk>;
 		};
 	};
@@ -584,6 +582,9 @@
 		pinctrl-names = "default", "sleep";
 		pinctrl-0 = <&clkout2_pins_default>;
 		pinctrl-1 = <&clkout2_pins_sleep>;
+		assigned-clocks = <&clkoutmux2_clk_mux>;
+		assigned-clock-parents = <&sys_clk2_dclk_div>;
+
 		status = "okay";
 		adc-settle-ms = <40>;
 
-- 
2.7.1



From peter.ujfalusi at ti.com  Thu Feb 25 06:50:26 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 25 Feb 2016 16:50:26 +0200
Subject: [PATCH 10/11] ARM: DRA7: hwmod: Add data for McASP1/2/4/5/6/7/8
In-Reply-To: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
References: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1456411827-23962-11-git-send-email-peter.ujfalusi@ti.com>

Add missing data for all McASP ports for the dra7 family

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 235 ++++++++++++++++++++++++++++++
 1 file changed, 235 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 3953ad031c43..3bd067afa702 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1374,6 +1374,50 @@ static struct omap_hwmod_class dra7xx_mcasp_hwmod_class = {
 	.sysc	= &dra7xx_mcasp_sysc,
 };
 
+/* mcasp1 */
+static struct omap_hwmod_opt_clk mcasp1_opt_clks[] = {
+	{ .role = "ahclkx", .clk = "mcasp1_ahclkx_mux" },
+};
+
+static struct omap_hwmod dra7xx_mcasp1_hwmod = {
+	.name		= "mcasp1",
+	.class		= &dra7xx_mcasp_hwmod_class,
+	.clkdm_name	= "ipu_clkdm",
+	.main_clk	= "mcasp1_aux_gfclk_mux",
+	.flags		= HWMOD_SWSUP_SIDLE,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_IPU_MCASP1_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_IPU_MCASP1_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= mcasp1_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(mcasp1_opt_clks),
+};
+
+/* mcasp2 */
+static struct omap_hwmod_opt_clk mcasp2_opt_clks[] = {
+	{ .role = "ahclkx", .clk = "mcasp2_ahclkx_mux" },
+};
+
+static struct omap_hwmod dra7xx_mcasp2_hwmod = {
+	.name		= "mcasp2",
+	.class		= &dra7xx_mcasp_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "mcasp2_aux_gfclk_mux",
+	.flags		= HWMOD_SWSUP_SIDLE,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER2_MCASP2_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER2_MCASP2_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= mcasp2_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(mcasp2_opt_clks),
+};
+
 /* mcasp3 */
 static struct omap_hwmod_opt_clk mcasp3_opt_clks[] = {
 	{ .role = "ahclkx", .clk = "mcasp3_ahclkx_mux" },
@@ -1396,6 +1440,116 @@ static struct omap_hwmod dra7xx_mcasp3_hwmod = {
 	.opt_clks_cnt	= ARRAY_SIZE(mcasp3_opt_clks),
 };
 
+/* mcasp4 */
+static struct omap_hwmod_opt_clk mcasp4_opt_clks[] = {
+	{ .role = "ahclkx", .clk = "mcasp4_ahclkx_mux" },
+};
+
+static struct omap_hwmod dra7xx_mcasp4_hwmod = {
+	.name		= "mcasp4",
+	.class		= &dra7xx_mcasp_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "mcasp4_aux_gfclk_mux",
+	.flags		= HWMOD_OPT_CLKS_NEEDED,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER2_MCASP4_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER2_MCASP4_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= mcasp4_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(mcasp4_opt_clks),
+};
+
+/* mcasp5 */
+static struct omap_hwmod_opt_clk mcasp5_opt_clks[] = {
+	{ .role = "ahclkx", .clk = "mcasp5_ahclkx_mux" },
+};
+
+static struct omap_hwmod dra7xx_mcasp5_hwmod = {
+	.name		= "mcasp5",
+	.class		= &dra7xx_mcasp_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "mcasp5_aux_gfclk_mux",
+	.flags		= HWMOD_OPT_CLKS_NEEDED,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER2_MCASP5_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER2_MCASP5_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= mcasp5_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(mcasp5_opt_clks),
+};
+
+/* mcasp6 */
+static struct omap_hwmod_opt_clk mcasp6_opt_clks[] = {
+	{ .role = "ahclkx", .clk = "mcasp6_ahclkx_mux" },
+};
+
+static struct omap_hwmod dra7xx_mcasp6_hwmod = {
+	.name		= "mcasp6",
+	.class		= &dra7xx_mcasp_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "mcasp6_aux_gfclk_mux",
+	.flags		= HWMOD_OPT_CLKS_NEEDED,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER2_MCASP6_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER2_MCASP6_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= mcasp6_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(mcasp6_opt_clks),
+};
+
+/* mcasp7 */
+static struct omap_hwmod_opt_clk mcasp7_opt_clks[] = {
+	{ .role = "ahclkx", .clk = "mcasp7_ahclkx_mux" },
+};
+
+static struct omap_hwmod dra7xx_mcasp7_hwmod = {
+	.name		= "mcasp7",
+	.class		= &dra7xx_mcasp_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "mcasp7_aux_gfclk_mux",
+	.flags		= HWMOD_OPT_CLKS_NEEDED,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER2_MCASP7_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER2_MCASP7_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= mcasp7_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(mcasp7_opt_clks),
+};
+
+/* mcasp8 */
+static struct omap_hwmod_opt_clk mcasp8_opt_clks[] = {
+	{ .role = "ahclkx", .clk = "mcasp8_ahclkx_mux" },
+};
+
+static struct omap_hwmod dra7xx_mcasp8_hwmod = {
+	.name		= "mcasp8",
+	.class		= &dra7xx_mcasp_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "mcasp8_aux_gfclk_mux",
+	.flags		= HWMOD_OPT_CLKS_NEEDED,
+	.prcm = {
+		.omap4 = {
+			.clkctrl_offs = DRA7XX_CM_L4PER2_MCASP8_CLKCTRL_OFFSET,
+			.context_offs = DRA7XX_RM_L4PER2_MCASP8_CONTEXT_OFFSET,
+			.modulemode   = MODULEMODE_SWCTRL,
+		},
+	},
+	.opt_clks	= mcasp8_opt_clks,
+	.opt_clks_cnt	= ARRAY_SIZE(mcasp8_opt_clks),
+};
+
 /*
  * 'mmc' class
  *
@@ -2703,6 +2857,38 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_per2 -> mcasp1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp1 = {
+	.master		= &dra7xx_l4_per2_hwmod,
+	.slave		= &dra7xx_mcasp1_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> mcasp1 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mcasp1 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_mcasp1_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per2 -> mcasp2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp2 = {
+	.master		= &dra7xx_l4_per2_hwmod,
+	.slave		= &dra7xx_mcasp2_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l3_main_1 -> mcasp2 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mcasp2 = {
+	.master		= &dra7xx_l3_main_1_hwmod,
+	.slave		= &dra7xx_mcasp2_hwmod,
+	.clk		= "l3_iclk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l4_per2 -> mcasp3 */
 static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp3 = {
 	.master		= &dra7xx_l4_per2_hwmod,
@@ -2719,6 +2905,46 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__mcasp3 = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_per2 -> mcasp4 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp4 = {
+	.master		= &dra7xx_l4_per2_hwmod,
+	.slave		= &dra7xx_mcasp4_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per2 -> mcasp5 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp5 = {
+	.master		= &dra7xx_l4_per2_hwmod,
+	.slave		= &dra7xx_mcasp5_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per2 -> mcasp6 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp6 = {
+	.master		= &dra7xx_l4_per2_hwmod,
+	.slave		= &dra7xx_mcasp6_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per2 -> mcasp7 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp7 = {
+	.master		= &dra7xx_l4_per2_hwmod,
+	.slave		= &dra7xx_mcasp7_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_per2 -> mcasp8 */
+static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp8 = {
+	.master		= &dra7xx_l4_per2_hwmod,
+	.slave		= &dra7xx_mcasp8_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l4_per1 -> elm */
 static struct omap_hwmod_ocp_if dra7xx_l4_per1__elm = {
 	.master		= &dra7xx_l4_per1_hwmod,
@@ -3461,8 +3687,17 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
 	&dra7xx_l4_wkup__dcan1,
 	&dra7xx_l4_per2__dcan2,
 	&dra7xx_l4_per2__cpgmac0,
+	&dra7xx_l4_per2__mcasp1,
+	&dra7xx_l3_main_1__mcasp1,
+	&dra7xx_l4_per2__mcasp2,
+	&dra7xx_l3_main_1__mcasp2,
 	&dra7xx_l4_per2__mcasp3,
 	&dra7xx_l3_main_1__mcasp3,
+	&dra7xx_l4_per2__mcasp4,
+	&dra7xx_l4_per2__mcasp5,
+	&dra7xx_l4_per2__mcasp6,
+	&dra7xx_l4_per2__mcasp7,
+	&dra7xx_l4_per2__mcasp8,
 	&dra7xx_gmac__mdio,
 	&dra7xx_l4_cfg__dma_system,
 	&dra7xx_l3_main_1__tpcc,
-- 
2.7.1



From peter.ujfalusi at ti.com  Thu Feb 25 06:50:25 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 25 Feb 2016 16:50:25 +0200
Subject: [PATCH 09/11] ARM: clk: dra7xx: Correct mcasp8_ahclkx_mux name
In-Reply-To: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
References: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1456411827-23962-10-git-send-email-peter.ujfalusi@ti.com>

rename the mcasp8_ahclk_mux to mcasp8_ahclkx_mux.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/boot/dts/dra7xx-clocks.dtsi | 2 +-
 drivers/clk/ti/clk-7xx.c             | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 357bedeebfac..8be2cbe0e7e4 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1856,7 +1856,7 @@
 		reg = <0x1908>;
 	};
 
-	mcasp8_ahclk_mux: mcasp8_ahclk_mux {
+	mcasp8_ahclkx_mux: mcasp8_ahclkx_mux {
 		#clock-cells = <0>;
 		compatible = "ti,mux-clock";
 		clocks = <&abe_24m_fclk>, <&abe_sys_clk_div>, <&func_24m_clk>, <&atl_clkin3_ck>, <&atl_clkin2_ck>, <&atl_clkin1_ck>, <&atl_clkin0_ck>, <&sys_clkin2>, <&ref_clkin0_ck>, <&ref_clkin1_ck>, <&ref_clkin2_ck>, <&ref_clkin3_ck>, <&mlb_clk>, <&mlbp_clk>;
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index a911d7de3377..6b5a309d9939 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -223,7 +223,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
 	DT_CLK(NULL, "mcasp6_aux_gfclk_mux", "mcasp6_aux_gfclk_mux"),
 	DT_CLK(NULL, "mcasp7_ahclkx_mux", "mcasp7_ahclkx_mux"),
 	DT_CLK(NULL, "mcasp7_aux_gfclk_mux", "mcasp7_aux_gfclk_mux"),
-	DT_CLK(NULL, "mcasp8_ahclk_mux", "mcasp8_ahclk_mux"),
+	DT_CLK(NULL, "mcasp8_ahclkx_mux", "mcasp8_ahclkx_mux"),
 	DT_CLK(NULL, "mcasp8_aux_gfclk_mux", "mcasp8_aux_gfclk_mux"),
 	DT_CLK(NULL, "mmc1_fclk_mux", "mmc1_fclk_mux"),
 	DT_CLK(NULL, "mmc1_fclk_div", "mmc1_fclk_div"),
-- 
2.7.1



From peter.ujfalusi at ti.com  Thu Feb 25 06:50:27 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Thu, 25 Feb 2016 16:50:27 +0200
Subject: [PATCH 11/11] ARM: DTS: dra7: Add nodes for McASP1/2/4/5/6/7/8
In-Reply-To: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
References: <1456411827-23962-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <1456411827-23962-12-git-send-email-peter.ujfalusi@ti.com>

Add nodes to represent all McASP ports in the dra7 family.
For system consistency use the eDMA for audio operations. sDMA would be
fine for 4/5/6/7/8 since their DAT port is not through L3 interconnect.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
---
 arch/arm/boot/dts/dra7.dtsi | 112 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 112 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 258e6712a76b..700382093922 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1464,6 +1464,38 @@
 			status = "disabled";
 		};
 
+		mcasp1: mcasp at 48460000 {
+			compatible = "ti,dra7-mcasp-audio";
+			ti,hwmods = "mcasp1";
+			reg = <0x48460000 0x2000>,
+			      <0x45800000 0x1000>;
+			reg-names = "mpu","dat";
+			interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "tx", "rx";
+			dmas = <&edma_xbar 129 1>, <&edma_xbar 128 1>;
+			dma-names = "tx", "rx";
+			clocks = <&mcasp1_aux_gfclk_mux>, <&mcasp1_ahclkx_mux>;
+			clock-names = "fck", "ahclkx";
+			status = "disabled";
+		};
+
+		mcasp2: mcasp at 48464000 {
+			compatible = "ti,dra7-mcasp-audio";
+			ti,hwmods = "mcasp2";
+			reg = <0x48464000 0x2000>,
+			      <0x45c00000 0x1000>;
+			reg-names = "mpu","dat";
+			interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "tx", "rx";
+			dmas = <&edma_xbar 131 1>, <&edma_xbar 130 1>;
+			dma-names = "tx", "rx";
+			clocks = <&mcasp2_aux_gfclk_mux>, <&mcasp2_ahclkx_mux>;
+			clock-names = "fck", "ahclkx";
+			status = "disabled";
+		};
+
 		mcasp3: mcasp at 48468000 {
 			compatible = "ti,dra7-mcasp-audio";
 			ti,hwmods = "mcasp3";
@@ -1480,6 +1512,86 @@
 			status = "disabled";
 		};
 
+		mcasp4: mcasp at 4846c000 {
+			compatible = "ti,dra7-mcasp-audio";
+			ti,hwmods = "mcasp4";
+			reg = <0x4846c000 0x2000>,
+			      <0x48436000 0x1000>;
+			reg-names = "mpu","dat";
+			interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "tx", "rx";
+			dmas = <&edma_xbar 135 1>, <&edma_xbar 134 1>;
+			dma-names = "tx", "rx";
+			clocks = <&mcasp4_aux_gfclk_mux>, <&mcasp4_ahclkx_mux>;
+			clock-names = "fck", "ahclkx";
+			status = "disabled";
+		};
+
+		mcasp5: mcasp at 48470000 {
+			compatible = "ti,dra7-mcasp-audio";
+			ti,hwmods = "mcasp5";
+			reg = <0x48470000 0x2000>,
+			      <0x4843a000 0x1000>;
+			reg-names = "mpu","dat";
+			interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "tx", "rx";
+			dmas = <&edma_xbar 137 1>, <&edma_xbar 136 1>;
+			dma-names = "tx", "rx";
+			clocks = <&mcasp5_aux_gfclk_mux>, <&mcasp5_ahclkx_mux>;
+			clock-names = "fck", "ahclkx";
+			status = "disabled";
+		};
+
+		mcasp6: mcasp at 48474000 {
+			compatible = "ti,dra7-mcasp-audio";
+			ti,hwmods = "mcasp6";
+			reg = <0x48474000 0x2000>,
+			      <0x4844c000 0x1000>;
+			reg-names = "mpu","dat";
+			interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "tx", "rx";
+			dmas = <&edma_xbar 139 1>, <&edma_xbar 138 1>;
+			dma-names = "tx", "rx";
+			clocks = <&mcasp6_aux_gfclk_mux>, <&mcasp6_ahclkx_mux>;
+			clock-names = "fck", "ahclkx";
+			status = "disabled";
+		};
+
+		mcasp7: mcasp at 48478000 {
+			compatible = "ti,dra7-mcasp-audio";
+			ti,hwmods = "mcasp7";
+			reg = <0x48478000 0x2000>,
+			      <0x48450000 0x1000>;
+			reg-names = "mpu","dat";
+			interrupts = <GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "tx", "rx";
+			dmas = <&edma_xbar 141 1>, <&edma_xbar 140 1>;
+			dma-names = "tx", "rx";
+			clocks = <&mcasp7_aux_gfclk_mux>, <&mcasp7_ahclkx_mux>;
+			clock-names = "fck", "ahclkx";
+			status = "disabled";
+		};
+
+		mcasp8: mcasp at 4847c000 {
+			compatible = "ti,dra7-mcasp-audio";
+			ti,hwmods = "mcasp8";
+			reg = <0x4847c000 0x2000>,
+			      <0x48454000 0x1000>;
+			reg-names = "mpu","dat";
+			interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "tx", "rx";
+			dmas = <&edma_xbar 143 1>, <&edma_xbar 142 1>;
+			dma-names = "tx", "rx";
+			clocks = <&mcasp8_aux_gfclk_mux>, <&mcasp8_ahclkx_mux>;
+			clock-names = "fck", "ahclkx";
+			status = "disabled";
+		};
+
 		crossbar_mpu: crossbar at 4a002a48 {
 			compatible = "ti,irq-crossbar";
 			reg = <0x4a002a48 0x130>;
-- 
2.7.1



From gregory.clement at free-electrons.com  Thu Feb 25 06:54:52 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 25 Feb 2016 15:54:52 +0100
Subject: [PATCH 0/3] ARM: mvebu: randconfig warning fixes
In-Reply-To: <1456236403-115511-1-git-send-email-arnd@arndb.de> (Arnd
 Bergmann's message of "Tue, 23 Feb 2016 15:06:36 +0100")
References: <1456236403-115511-1-git-send-email-arnd@arndb.de>
Message-ID: <87lh68on5v.fsf@free-electrons.com>

Hi Arnd,
 
 On mar., f?vr. 23 2016, Arnd Bergmann <arnd at arndb.de> wrote:

> Here are three more warning fixes for orion/mv78xx0/mvebu. All
> are really harmless and I'm just shutting up the warnings
> as the current code is basically ok.

Applied on mvebu/soc with the Reviewed-by flag by Andrew Lunn and the
Acked-by flag by Jason Cooper.

Thanks,

Gregory

>
> 	Arnd
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From linus.walleij at linaro.org  Thu Feb 25 06:58:58 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 15:58:58 +0100
Subject: [PATCH 3/4] ARM: realview: imply Device Tree config
In-Reply-To: <2805017.I27kg8jfk6@wuerfel>
References: <1456406111-18579-1-git-send-email-linus.walleij@linaro.org>
 <1456406111-18579-4-git-send-email-linus.walleij@linaro.org>
 <2805017.I27kg8jfk6@wuerfel>
Message-ID: <CACRpkdZCqNH-cuoXbZaJ2Uw5-0UvLZ+vo0Lz9Nq+7AaawEp6-A@mail.gmail.com>

On Thu, Feb 25, 2016 at 3:23 PM, Arnd Bergmann <arnd at arndb.de> wrote:

> On Thursday 25 February 2016 14:15:10 Linus Walleij wrote:
>> @@ -32,8 +24,9 @@ config REALVIEW_DT
>>         select USE_OF
>>         select ZONE_DMA
>
> The 'select USE_OF' can now be dropped, I guess this was left over
> from the multiplatform patches, but also fits in here.
>
>>         help
>> -         Include support for booting the ARM(R) RealView(R) evaluation
>> -         boards using a device tree machine description.
>> +         This enables support for ARM Ltd RealView boards.
>> +
>> +if ARCH_REALVIEW
>>
>>  config REALVIEW_HIGH_PHYS_OFFSET
>>         bool "High physical base address for the RealView platform"
>>
>
> REALVIEW_HIGH_PHYS_OFFSET can go away as well, as it is only used
> in 'realview_fixup', which in turn is called by the removed board
> files.

OK I updated the patch cutting these too.

Yours,
Linus Walleij


From will.deacon at arm.com  Thu Feb 25 07:00:54 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Feb 2016 15:00:54 +0000
Subject: RFC: extend IOMMU attributes
In-Reply-To: <20160225143855.GD16675@8bytes.org>
References: <HE1PR04MB1641F22E38710B68F4ED891F8DAF0@HE1PR04MB1641.eurprd04.prod.outlook.com>
 <20160225143855.GD16675@8bytes.org>
Message-ID: <20160225150053.GA15330@arm.com>

On Thu, Feb 25, 2016 at 03:38:55PM +0100, joro at 8bytes.org wrote:
> On Thu, Feb 18, 2016 at 04:16:26PM +0000, Stuart Yoder wrote:
> >  #define IOMMU_READ            (1 << 0)
> >  #define IOMMU_WRITE           (1 << 1)
> > -#define IOMMU_CACHE           (1 << 2) /* DMA cache coherency */
> > +#define IOMMU_CACHE_COHERENT  (1 << 2) /* cacheable and coherent */
> >  #define IOMMU_NOEXEC          (1 << 3)
> >  #define IOMMU_MMIO            (1 << 4) /* e.g. things like MSI doorbells */
> > +#define IOMMU_CACHEABLE       (1 << 5) /* cacheable, not coherent */
> > +#define IOMMU_CACHE_ALLOCATE  (1 << 6) /* hint to allocate in the cache */
> 
> Hmm, this might be a valid use-case to introduce the
> map_attr()/unmap_attr() calls to the IOMMU-API. I have been resistant to
> these functions until now because the proposed use-cases were not
> convincing, but for hardware-specific map-attributes like this one it
> could make sense.

So this particular use-case is completely insane, but something like
read/write allocation hints could make sense for arm-smmu systems.

Will


From jroedel at suse.de  Thu Feb 25 07:00:55 2016
From: jroedel at suse.de (Joerg Roedel)
Date: Thu, 25 Feb 2016 16:00:55 +0100
Subject: [GIT PULL] iommu/arm-smmu: Updates for 4.6
In-Reply-To: <20160223123322.GL3966@arm.com>
References: <20160223123322.GL3966@arm.com>
Message-ID: <20160225150055.GC2280@suse.de>

On Tue, Feb 23, 2016 at 12:33:22PM +0000, Will Deacon wrote:
> Please pull the following arm-smmu updates for 4.6. This lays the
> foundations for a functional IOMMU_DOMAIN_DMA for the two drivers,
> although we haven't yet thrown the switch since we need to ensure
> that the DMA ops all point in the right direction first. Hopefully we'll
> get that going for 4.7.

Pulled, thanks Will.



From gregory.clement at free-electrons.com  Thu Feb 25 07:04:49 2016
From: gregory.clement at free-electrons.com (Gregory CLEMENT)
Date: Thu, 25 Feb 2016 16:04:49 +0100
Subject: [PATCH 1/3] dt-bindings: arm/marvell: ABI unstability warning
 about Marvell 7K/8K
In-Reply-To: <20160225090927.13492cfb@free-electrons.com> (Thomas Petazzoni's
 message of "Thu, 25 Feb 2016 09:09:27 +0100")
References: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1456327007-31008-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160224172545.GC9137@leverpostej>
 <20160224211045.379352d3@free-electrons.com>
 <CAL_JsqLevrujSeYNBvSJA-5T0Ho8y7c0fKid7QvVm8LLvYLotw@mail.gmail.com>
 <20160225090927.13492cfb@free-electrons.com>
Message-ID: <87h9gwompa.fsf@free-electrons.com>

Hi Thomas,
 
 On jeu., f?vr. 25 2016, Thomas Petazzoni <thomas.petazzoni at free-electrons.com> wrote:

>
> Gregory, can you skip patch 1/3, and merge patches 2/3 and 3/3, once
> the new clock DT binding has been approved.

I applied patch 2 and 3 on mvebu/dt64 and I amended the title by using
"arm64: dts : marvell:" instead of "arm64: marvell:" as requested by
Olof on ly first mvebu/dt64 pull request.

Thanks,

Gregory

>
> Best regards,
>
> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


From helgaas at kernel.org  Thu Feb 25 07:24:17 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Thu, 25 Feb 2016 09:24:17 -0600
Subject: [PATCH 3/3] arm/arm64: pci: remove arch specific
 pcibios_enable_device()
In-Reply-To: <20160120162215.GE13437@red-moon>
References: <1447779838-15585-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1447779838-15585-3-git-send-email-lorenzo.pieralisi@arm.com>
 <20151123134921.GB4236@arm.com> <20160120162215.GE13437@red-moon>
Message-ID: <20160225152417.GB8120@localhost>

Hi Lorenzo,

On Wed, Jan 20, 2016 at 04:22:15PM +0000, Lorenzo Pieralisi wrote:
> On Mon, Nov 23, 2015 at 01:49:21PM +0000, Will Deacon wrote:
> > On Tue, Nov 17, 2015 at 05:03:58PM +0000, Lorenzo Pieralisi wrote:
> > > The arm/arm64 pcibios_enable_device() implementations exist solely
> > > to prevent enabling PCI resources on PROBE_ONLY systems, since
> > > on those systems the PCI resources are currently not claimed (ie
> > > validated and inserted in the PCI resource tree) therefore they can
> > > not be enabled since this would trigger PCI set-ups failures.
> > > 
> > > By introducing resources claiming in the PCI host controllers set-ups
> > > that have PROBE_ONLY as a probe option, there is no need for arch specific
> > > pcibios_enable_device() implementations anymore in that the kernel can
> > > rely on the generic pcibios_enable_device() implementation without
> > > resorting to arch specific code to work around the missing resources
> > > claiming enumeration step.
> > > 
> > > This patch removes the pcibios_enable_device() implementations from
> > > the arm/arm64 arch back-ends.
> > > 
> > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > > Cc: Arnd Bergmann <arnd at arndb.de>
> > > Cc: Will Deacon <will.deacon at arm.com>
> > > Cc: Bjorn Helgaas <bhelgaas at google.com>
> > > Cc: Russell King <linux at arm.linux.org.uk>
> > > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > > ---
> > >  arch/arm/kernel/bios32.c | 12 ------------
> > >  arch/arm64/kernel/pci.c  | 13 -------------
> > >  2 files changed, 25 deletions(-)
> > 
> > Acked-by: Will Deacon <will.deacon at arm.com>
> 
> Thanks, unfortunately I spotted that ARM platforms can set
> PCI_PROBE_ONLY also via command line (pcibios_setup()), which means
> that I have to add resource claiming to all ARM PCI controllers that
> check PCI_PROBE_ONLY (inclusive of ARM bios32) to really make sure we
> can apply this patch or alternatevely we add the resource claiming
> to the pcibios_fixup_bus() callback (but we can claim resources only if
> PCI_PROBE_ONLY is set lest we trigger regressions) which would be the
> simpler solution.

So where are we?  The above response sounds like this series still
needs a little tweaking?

Bjorn


From linus.walleij at linaro.org  Thu Feb 25 07:26:21 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 16:26:21 +0100
Subject: [PATCH] pinctrl: mediatek/7623: delete unnecessary .owner
Message-ID: <1456413981-26089-1-git-send-email-linus.walleij@linaro.org>

This is set by the device core.

Cc: John Crispin <blogic at openwrt.org>
Reported-by: kbuild test robot <fengguang.wu at intel.com>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
 drivers/pinctrl/mediatek/pinctrl-mt7623.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7623.c b/drivers/pinctrl/mediatek/pinctrl-mt7623.c
index bf0d05b6e7dc..67895f8234e3 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt7623.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7623.c
@@ -367,7 +367,6 @@ static struct platform_driver mtk_pinctrl_driver = {
 	.probe = mt7623_pinctrl_probe,
 	.driver = {
 		.name = "mediatek-mt7623-pinctrl",
-		.owner = THIS_MODULE,
 		.of_match_table = mt7623_pctrl_match,
 	},
 };
-- 
2.4.3



From linus.walleij at linaro.org  Thu Feb 25 07:29:31 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 16:29:31 +0100
Subject: [PATCH 0/4] RealView boardfile endgame
In-Reply-To: <5411123.nOOnE7uo7z@wuerfel>
References: <1456406111-18579-1-git-send-email-linus.walleij@linaro.org>
 <5411123.nOOnE7uo7z@wuerfel>
Message-ID: <CACRpkdZ_oyJNTzC6Ji+19aRy3Ex47u2Khqd7_RwuGdK+TLTy_A@mail.gmail.com>

On Thu, Feb 25, 2016 at 3:29 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 25 February 2016 14:15:07 Linus Walleij wrote:
>> This patch set deletes the RealView board files and moves it
>> over to a pure Device Tree boot, deleting ~3500 LoC.
(...)
> This leaves the question whether we should do all the preparation
> in 4.6 and then only take these for 4.7, or do them all at
> once. I can see good reasons either way, but none of them
> particularly strong. What did you have in mind here?

If the dependencies in CLCD and MTD make it in we'll just
merge the whole thing IMO.

If these drag out, we merge the device trees and wait with
removing the board files until v4.7.

I will still have some remaining cleanup for Integrator, Versatile
and also Versatile Express however, but that is for later.

Yours,
Linus Walleij


From thomas.petazzoni at free-electrons.com  Thu Feb 25 07:27:26 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 25 Feb 2016 16:27:26 +0100
Subject: [PATCH 1/3] dt-bindings: arm/marvell: ABI unstability warning
 about Marvell 7K/8K
In-Reply-To: <87h9gwompa.fsf@free-electrons.com>
References: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1456327007-31008-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160224172545.GC9137@leverpostej>
 <20160224211045.379352d3@free-electrons.com>
 <CAL_JsqLevrujSeYNBvSJA-5T0Ho8y7c0fKid7QvVm8LLvYLotw@mail.gmail.com>
 <20160225090927.13492cfb@free-electrons.com>
 <87h9gwompa.fsf@free-electrons.com>
Message-ID: <20160225162726.6ad4a224@free-electrons.com>

Hello,

On Thu, 25 Feb 2016 16:04:49 +0100, Gregory CLEMENT wrote:

> > Gregory, can you skip patch 1/3, and merge patches 2/3 and 3/3, once
> > the new clock DT binding has been approved.
> 
> I applied patch 2 and 3 on mvebu/dt64 and I amended the title by using
> "arm64: dts : marvell:" instead of "arm64: marvell:" as requested by
> Olof on ly first mvebu/dt64 pull request.

Thanks, I'll try to remember this convention for the next patches!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From sudeep.holla at arm.com  Thu Feb 25 07:33:05 2016
From: sudeep.holla at arm.com (Sudeep Holla)
Date: Thu, 25 Feb 2016 15:33:05 +0000
Subject: [PATCH -next] mm: fix build for arm64 hugetlbpage
Message-ID: <1456414385-13775-1-git-send-email-sudeep.holla@arm.com>

Commit ("mm: cleanup *pte_alloc* interfaces") redefined pte_alloc_map()
using pte_alloc() and fixed all the callsites. However arm64 callsite
seem to have got missed. This patch fixes the same and thereby fixing
the following build error.

arch/arm64/mm/hugetlbpage.c: In function 'huge_pte_alloc':
arch/arm64/mm/hugetlbpage.c:127:42: error: macro "pte_alloc_map" passed 4 arguments, but takes just 3
   pte = pte_alloc_map(mm, NULL, pmd, addr);
                                          ^
arch/arm64/mm/hugetlbpage.c:127:9: error: 'pte_alloc_map' undeclared (first use in this function)
   pte = pte_alloc_map(mm, NULL, pmd, addr);
         ^
Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
---
 arch/arm64/mm/hugetlbpage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Hi,

Since it's from -mm tree, I have not put the commit id causing the
breakage. Also since I don't have the original patch in my inbox, I am
posting this separately. It would be good to squash this into original
commit.

Regards,
Sudeep

diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 82d607c3614e..bb6b4c7bfab3 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -124,7 +124,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
 		 * will be no pte_unmap() to correspond with this
 		 * pte_alloc_map().
 		 */
-		pte = pte_alloc_map(mm, NULL, pmd, addr);
+		pte = pte_alloc_map(mm, pmd, addr);
 	} else if (sz == PMD_SIZE) {
 		if (IS_ENABLED(CONFIG_ARCH_WANT_HUGE_PMD_SHARE) &&
 		    pud_none(*pud))
-- 
1.9.1



From blogic at openwrt.org  Thu Feb 25 07:34:39 2016
From: blogic at openwrt.org (John Crispin)
Date: Thu, 25 Feb 2016 16:34:39 +0100
Subject: [PATCH] pinctrl: mediatek/7623: delete unnecessary .owner
In-Reply-To: <1456413981-26089-1-git-send-email-linus.walleij@linaro.org>
References: <1456413981-26089-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <56CF1F0F.1060407@openwrt.org>



On 25/02/2016 16:26, Linus Walleij wrote:
> This is set by the device core.
> 
> Cc: John Crispin <blogic at openwrt.org>
> Reported-by: kbuild test robot <fengguang.wu at intel.com>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>

Thanks, i was just going to send it to you and then i saw you and feng
had already sent me a version, 2 is already more than needed so i wont
spin up a 3rd version ;)

can you fold this please ?

> ---
>  drivers/pinctrl/mediatek/pinctrl-mt7623.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7623.c b/drivers/pinctrl/mediatek/pinctrl-mt7623.c
> index bf0d05b6e7dc..67895f8234e3 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mt7623.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt7623.c
> @@ -367,7 +367,6 @@ static struct platform_driver mtk_pinctrl_driver = {
>  	.probe = mt7623_pinctrl_probe,
>  	.driver = {
>  		.name = "mediatek-mt7623-pinctrl",
> -		.owner = THIS_MODULE,
>  		.of_match_table = mt7623_pctrl_match,
>  	},
>  };
> 


From maitysanchayan at gmail.com  Thu Feb 25 07:30:45 2016
From: maitysanchayan at gmail.com (maitysanchayan at gmail.com)
Date: Thu, 25 Feb 2016 21:00:45 +0530
Subject: [PATCH v3 2/2] iio: dac: vf610_dac: Add IIO DAC driver for
 Vybrid SoC
In-Reply-To: <56CE18AC.6020603@kernel.org>
References: <cover.1456121233.git.maitysanchayan@gmail.com>
 <1a70acdd3ffae273bbfe2f80c5e3952d152921df.1456121233.git.maitysanchayan@gmail.com>
 <20160223205437.GA27366@rob-hp-laptop>
 <56CE18AC.6020603@kernel.org>
Message-ID: <20160225153045.GA15913@Sanchayan-Arch>

Hello,

On 16-02-24 20:55:08, Jonathan Cameron wrote:
> On 23/02/16 20:54, Rob Herring wrote:
> > On Mon, Feb 22, 2016 at 11:48:37AM +0530, Sanchayan Maity wrote:
> >> Add driver support for DAC peripheral on Vybrid SoC.
> >>
> >> Signed-off-by: Sanchayan Maity <maitysanchayan at gmail.com>
> >> ---
> >>  Documentation/ABI/testing/sysfs-bus-iio-vf610      |   9 +
> >>  .../devicetree/bindings/iio/dac/vf610-dac.txt      |  20 ++
> > 
> > For the binding:
> > 
> > Acked-by: Rob Herring <robh at kernel.org>
> Applied to the togreg branch of iio.git - initially pushed out as testing
> for the autobuilders to play with it.

Thanks Jonathan.

> 
> Note the dts change probably wants to go via the relevant arch trees.
> I can take it with an appropriate ack if not.

Generally shawn picks up the device tree changes once the driver makes
it to his for-next branch. I will ping shawn to pick this up once the
driver lands in shawn's for-next branch.

Regards,
Sanchayan.


From linus.walleij at linaro.org  Thu Feb 25 07:36:17 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 16:36:17 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <DF3259B0-8A3A-4AB0-A805-F5A8F7295E5C@konsulko.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
 <56CC546A.9070705@ti.com>
 <20160224104638.GL19428@n2100.arm.linux.org.uk>
 <56CD924F.50108@ti.com>
 <B8A82546-46C7-4A21-92D8-62418E49FBB6@konsulko.com>
 <CACRpkdZ=PR6O28NQusUEipCYwRZyuhbeAJO_ZK80+4H7Zakt=g@mail.gmail.com>
 <DF3259B0-8A3A-4AB0-A805-F5A8F7295E5C@konsulko.com>
Message-ID: <CACRpkdbi+cJFP8gUvuLKEWVVU_LScZDvnWH59RC7ug-xt2PK4Q@mail.gmail.com>

On Thu, Feb 25, 2016 at 3:35 PM, Pantelis Antoniou
<pantelis.antoniou at konsulko.com> wrote:
>> On Feb 25, 2016, at 15:43 , Linus Walleij <linus.walleij at linaro.org> wrote:

>> It also means there is no way to get the console up without the right
>> firmware files in the filesystem. I think that is really crap compared
>> to what we have today where the display will always come up, and
>> basically a regression.
>>
>> I understand the stance with respect to things like add-on hardware
>> like a Bluetooth board or WLAN or whatnot. But the fbdev console
>> is just too basic, like a serial port IMO.
>>
>> Sure in the ARM world we usually have a serial console, but this is
>> seriously breaking current practice.
>
> As Tomi mentioned firmware files can be located in the kernel image; there is no
> requirement to be in a filesystem, and that application can be performed really
> early, before even early init.

Are you thinking about exploiting an appended DT with
CONFIG_ARM_APPENDED_DTB or something else?

Yours,
Linus Walleij


From pantelis.antoniou at konsulko.com  Thu Feb 25 07:40:21 2016
From: pantelis.antoniou at konsulko.com (Pantelis Antoniou)
Date: Thu, 25 Feb 2016 17:40:21 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CACRpkdbi+cJFP8gUvuLKEWVVU_LScZDvnWH59RC7ug-xt2PK4Q@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <1454594660-7532-12-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbnLgVsrSAu87wxSwktK3ftJzbQLXjU8y65tq=9Ynxicw@mail.gmail.com>
 <56CC2D39.80909@ti.com>
 <CAFEAcA9U3V04o2_93bS5G7+k=UT7kTWt4=v7t1Ju0X9W=5oo9A@mail.gmail.com>
 <56CC546A.9070705@ti.com> <20160224104638.GL19428@n2100.arm.linux.org.uk>
 <56CD924F.50108@ti.com> <B8A82546-46C7-4A21-92D8-62418E49FBB6@konsulko.com>
 <CACRpkdZ=PR6O28NQusUEipCYwRZyuhbeAJO_ZK80+4H7Zakt=g@mail.gmail.com>
 <DF3259B0-8A3A-4AB0-A805-F5A8F7295E5C@konsulko.com>
 <CACRpkdbi+cJFP8gUvuLKEWVVU_LScZDvnWH59RC7ug-xt2PK4Q@mail.gmail.com>
Message-ID: <35045C01-7051-4589-894E-A3C1C31E5550@konsulko.com>

Hi Linus,

> On Feb 25, 2016, at 17:36 , Linus Walleij <linus.walleij at linaro.org> wrote:
> 
> On Thu, Feb 25, 2016 at 3:35 PM, Pantelis Antoniou
> <pantelis.antoniou at konsulko.com> wrote:
>>> On Feb 25, 2016, at 15:43 , Linus Walleij <linus.walleij at linaro.org> wrote:
> 
>>> It also means there is no way to get the console up without the right
>>> firmware files in the filesystem. I think that is really crap compared
>>> to what we have today where the display will always come up, and
>>> basically a regression.
>>> 
>>> I understand the stance with respect to things like add-on hardware
>>> like a Bluetooth board or WLAN or whatnot. But the fbdev console
>>> is just too basic, like a serial port IMO.
>>> 
>>> Sure in the ARM world we usually have a serial console, but this is
>>> seriously breaking current practice.
>> 
>> As Tomi mentioned firmware files can be located in the kernel image; there is no
>> requirement to be in a filesystem, and that application can be performed really
>> early, before even early init.
> 
> Are you thinking about exploiting an appended DT with
> CONFIG_ARM_APPENDED_DTB or something else?
> 

It?s not much of a problem to scan for extra blobs appended to the booting blob.

If found, you just apply them and that?s it.

The concatenation operation can either be made off-line on the host, or by the bootloader
if it?s capable of doing so.

If the bootloader is not smart enough to do it, just put the concatenated dtb in place
of the original.

> Yours,
> Linus Walleij

Regards

? Pantelis



From steve.capper at linaro.org  Thu Feb 25 07:49:33 2016
From: steve.capper at linaro.org (Steve Capper)
Date: Thu, 25 Feb 2016 15:49:33 +0000
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160223184658.GA27281@arm.com>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160223103221.GA1418@node.shutemov.name>
 <20160223191907.25719a4d@thinkpad> <20160223184658.GA27281@arm.com>
Message-ID: <CAPvkgC3gfmgA9aCvCeqReKhjpkT5Y-qk-2fNO8puDjUs9EWzVw@mail.gmail.com>

On 23 February 2016 at 18:47, Will Deacon <will.deacon at arm.com> wrote:
> [adding Steve, since he worked on THP for 32-bit ARM]

Apologies for my late reply...

>
> On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
>> On Tue, 23 Feb 2016 13:32:21 +0300
>> "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
>> > The theory is that the splitting bit effetely masked bogus pmd_present():
>> > we had pmd_trans_splitting() in all code path and that prevented mm from
>> > touching the pmd. Once pmd_trans_splitting() has gone, mm proceed with the
>> > pmd where it shouldn't and here's a boom.
>>
>> Well, I don't think pmd_present() == true is bogus for a trans_huge pmd under
>> splitting, after all there is a page behind the the pmd. Also, if it was
>> bogus, and it would need to be false, why should it be marked !pmd_present()
>> only at the pmdp_invalidate() step before the pmd_populate()? It clearly
>> is pmd_present() before that, on all architectures, and if there was any
>> problem/race with that, setting it to !pmd_present() at this stage would
>> only (marginally) reduce the race window.
>>
>> BTW, PowerPC and Sparc seem to do the same thing in pmdp_invalidate(),
>> i.e. they do not set pmd_present() == false, only mark it so that it would
>> not generate a new TLB entry, just like on s390. After all, the function
>> is called pmdp_invalidate(), and I think the comment in mm/huge_memory.c
>> before that call is just a little ambiguous in its wording. When it says
>> "mark the pmd notpresent" it probably means "mark it so that it will not
>> generate a new TLB entry", which is also what the comment is really about:
>> prevent huge and small entries in the TLB for the same page at the same
>> time.
>>
>> FWIW, and since the ARM arch-list is already on cc, I think there is
>> an issue with pmdp_invalidate() on ARM, since it also seems to clear
>> the trans_huge (and formerly trans_splitting) bit, which actually makes
>> the pmd !pmd_present(), but it violates the other requirement from the
>> comment:
>> "the pmd_trans_huge and pmd_trans_splitting must remain set at all times
>> on the pmd until the split is complete for this pmd"
>
> I've only been testing this for arm64 (where I'm yet to see a problem),
> but we use the generic pmdp_invalidate implementation from
> mm/pgtable-generic.c there. On arm64, pmd_trans_huge will return true
> after pmd_mknotpresent. On arm, it does look to be buggy, since it nukes
> the entire entry... Steve?

pmd_mknotpresent on arm looks inconsistent with the other
architectures and can be changed.

Having had a look at the usage, I can't see it causing an immediate
problem (that needs to be addressed by an emergency patch).
We don't have a notion of splitting pmds (so there is no splitting
information to lose), and the only usage I could see of
pmd_mknotpresent was:

pmdp_invalidate(vma, haddr, pmd);
pmd_populate(mm, pmd, pgtable);

In mm/huge_memory.c, around line 3588.

So we invalidate the entry (which puts down a faulting entry from
pmd_mknotpresent and invalidates tlb), then immediately put down a
table entry with pmd_populate.

I have run a 32-bit ARM test kernel and exacerbated THP splits (that's
what took me time), and I didn't notice any problems with 4.5-rc5.

Cheers,
-- 
Steve

>
> Will
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont at kvack.org"> email at kvack.org </a>


From joro at 8bytes.org  Thu Feb 25 07:50:07 2016
From: joro at 8bytes.org (Joerg Roedel)
Date: Thu, 25 Feb 2016 16:50:07 +0100
Subject: [PATCH v10 0/5] MT8173 IOMMU SUPPORT
In-Reply-To: <1456161651-6136-1-git-send-email-yong.wu@mediatek.com>
References: <1456161651-6136-1-git-send-email-yong.wu@mediatek.com>
Message-ID: <20160225155007.GA19092@8bytes.org>

On Tue, Feb 23, 2016 at 01:20:46AM +0800, Yong Wu wrote:
> Yong Wu (5):
>   dt-bindings: iommu: Add binding for mediatek IOMMU
>   dt-bindings: mediatek: Add smi dts binding
>   memory: mediatek: Add SMI driver
>   iommu/mediatek: Add mt8173 IOMMU driver
>   dts: mt8173: Add iommu/smi nodes for mt8173
> 
>  .../devicetree/bindings/iommu/mediatek,iommu.txt   |  68 ++
>  .../memory-controllers/mediatek,smi-common.txt     |  24 +
>  .../memory-controllers/mediatek,smi-larb.txt       |  25 +
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi           |  81 +++
>  drivers/iommu/Kconfig                              |  16 +
>  drivers/iommu/Makefile                             |   1 +
>  drivers/iommu/mtk_iommu.c                          | 737 +++++++++++++++++++++
>  drivers/memory/Kconfig                             |   8 +
>  drivers/memory/Makefile                            |   1 +
>  drivers/memory/mtk-smi.c                           | 273 ++++++++
>  include/dt-bindings/memory/mt8173-larb-port.h      | 111 ++++
>  include/soc/mediatek/smi.h                         |  58 ++
>  12 files changed, 1403 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>  create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
>  create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
>  create mode 100644 drivers/iommu/mtk_iommu.c
>  create mode 100644 drivers/memory/mtk-smi.c
>  create mode 100644 include/dt-bindings/memory/mt8173-larb-port.h
>  create mode 100644 include/soc/mediatek/smi.h

Applied all, thanks.



From aleksey.makarov at linaro.org  Thu Feb 25 07:53:35 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Thu, 25 Feb 2016 18:53:35 +0300
Subject: [PATCH v2 1/8] arm64: move acpi/dt decision earlier in boot
 process
In-Reply-To: <56CDF4D4.6000506@suse.com>
References: <1456333819-13482-1-git-send-email-aleksey.makarov@linaro.org>
 <1456333819-13482-2-git-send-email-aleksey.makarov@linaro.org>
 <56CDF4D4.6000506@suse.com>
Message-ID: <56CF237F.6090706@linaro.org>

Hi Matthias,

On 02/24/2016 09:22 PM, Matthias Brugger wrote:
> 
> 
> On 24/02/16 18:10, Aleksey Makarov wrote:
>> From: Leif Lindholm <leif.lindholm at linaro.org>
>>
>> In order to support selecting earlycon via either ACPI or DT, move
>> the decision on whether to attempt ACPI configuration into the
>> early_param handling. Then make acpi_boot_table_init() bail out if
>> acpi_disabled.
>>
>> Signed-off-by: Leif Lindholm <leif.lindholm at linaro.org>
>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
>> ---
>>   arch/arm64/kernel/acpi.c | 62 +++++++++++++++++++++++-------------------------
>>   1 file changed, 30 insertions(+), 32 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index d1ce8e2..3faa323 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -41,26 +41,8 @@ EXPORT_SYMBOL(acpi_disabled);
>>   int acpi_pci_disabled = 1;    /* skip ACPI PCI scan and IRQ initialization */
>>   EXPORT_SYMBOL(acpi_pci_disabled);
>>
>> -static bool param_acpi_off __initdata;
>>   static bool param_acpi_force __initdata;
>>
>> -static int __init parse_acpi(char *arg)
>> -{
>> -    if (!arg)
>> -        return -EINVAL;
>> -
>> -    /* "acpi=off" disables both ACPI table parsing and interpreter */
>> -    if (strcmp(arg, "off") == 0)
>> -        param_acpi_off = true;
>> -    else if (strcmp(arg, "force") == 0) /* force ACPI to be enabled */
>> -        param_acpi_force = true;
>> -    else
>> -        return -EINVAL;    /* Core will print when we return error */
>> -
>> -    return 0;
>> -}
>> -early_param("acpi", parse_acpi);
>> -
>>   static int __init dt_scan_depth1_nodes(unsigned long node,
>>                          const char *uname, int depth,
>>                          void *data)
>> @@ -74,6 +56,35 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
>>       return 0;
>>   }
>>
>> +static int __init parse_acpi(char *arg)
>> +{
>> +    if (!arg)
>> +        return -EINVAL;
>> +
>> +    /*
>> +     * Enable ACPI instead of device tree unless
>> +     * - ACPI has been disabled explicitly (acpi=off), or
>> +     * - the device tree is not empty (it has more than just a /chosen node)
>> +     *   and ACPI has not been force enabled (acpi=force)
>> +     */
>> +    if (strcmp(arg, "off") == 0)
>> +        return 0;
>> +    else if (strcmp(arg, "force") == 0)
>> +        param_acpi_force = true;
>> +    else if (of_scan_flat_dt(dt_scan_depth1_nodes, NULL))
> 
> I think we should strcmp for "on" here and return an error on other values. IMHO an update to Documentation/kernel-parameters.txt would be convenient.

Actually this patch is not correct at all.

on x86:
- if default is off then "acpi=force" enables it.
- if default is on  then "acpi=off"   disables it.

on ARM64 by default OF is preferred to ACPI, but ACPI is used if OF does not provide any nontrivial data.
So we need both "force" and "off"
- "acpi=force" forces ACPI,
- "acpi=off" disables ACPI

The patch makes incorrect code transformation, it changes the default behaviour.

This patch should just be dropped.  The rest of the patchset does not depend on it.

> I still wonder if we really want to change the default to ACPI disabled.
> But that's a decision the maintainers have to take.

I did not realize that the patch changes default.

Thank you
Aleksey Makarov

> Regards,
> Matthias
> 
>> +        return 0;
>> +
>> +    /*
>> +     * ACPI is disabled at this point. Enable it in order to parse
>> +     * the ACPI tables and carry out sanity checks
>> +     */
>> +    enable_acpi();
>> +
>> +    return 0;
>> +}
>> +
>> +early_param("acpi", parse_acpi);
>> +
>>   /*
>>    * __acpi_map_table() will be called before page_init(), so early_ioremap()
>>    * or early_memremap() should be called here to for ACPI table mapping.
>> @@ -181,23 +192,10 @@ out:
>>    */
>>   void __init acpi_boot_table_init(void)
>>   {
>> -    /*
>> -     * Enable ACPI instead of device tree unless
>> -     * - ACPI has been disabled explicitly (acpi=off), or
>> -     * - the device tree is not empty (it has more than just a /chosen node)
>> -     *   and ACPI has not been force enabled (acpi=force)
>> -     */
>> -    if (param_acpi_off ||
>> -        (!param_acpi_force && of_scan_flat_dt(dt_scan_depth1_nodes, NULL)))
>> +    if (acpi_disabled)
>>           return;
>>
>>       /*
>> -     * ACPI is disabled at this point. Enable it in order to parse
>> -     * the ACPI tables and carry out sanity checks
>> -     */
>> -    enable_acpi();
>> -
>> -    /*
>>        * If ACPI tables are initialized and FADT sanity checks passed,
>>        * leave ACPI enabled and carry on booting; otherwise disable ACPI
>>        * on initialization error.
>>


From troy.kisky at boundarydevices.com  Thu Feb 25 07:57:15 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Thu, 25 Feb 2016 08:57:15 -0700
Subject: [PATCH net-next V2 00/16] net: fec: cleanup and fixes
In-Reply-To: <87oab518wo.fsf@gmail.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
 <87oab518wo.fsf@gmail.com>
Message-ID: <56CF245B.8050504@boundarydevices.com>

On 2/25/2016 1:39 AM, Holger Schurig wrote:
> Hi Troy,
> 
> what is the general aim of your patches?  Stability?  Speed?  Cleanup?
> 

1. Stability
2. performance
3. easier to read
4. more debug info


The 2nd goal is very hard to measure. It seems function alignment changes swamp
most any other improvements. I think that if the same measurement that I did were done
with a different compiler, you would see different patches increased/decreased
the BPS. But at least the overall trend on the patch set is positive. And
each individual patch has been tested. I would like someone to test on a machine
with 3 queues though.


If you have a more accurate way to measure performance, please let me know.
Also, if you know why freescale's bsp has so much better performance
that would be a very welcome patch.

Troy



From helgaas at kernel.org  Thu Feb 25 07:59:11 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Thu, 25 Feb 2016 09:59:11 -0600
Subject: [PATCH v3 0/6] Xilinx AXI PCIe Host Bridge driver fixes
In-Reply-To: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>
References: <1454602213-967-1-git-send-email-paul.burton@imgtec.com>
Message-ID: <20160225155911.GF8120@localhost>

Hi Paul,

On Thu, Feb 04, 2016 at 04:10:07PM +0000, Paul Burton wrote:
> This series fixes a number of issues found using the Xilinx AXI PCIe
> Host Bridge IP on the Imagination Technologies MIPS Boston development
> board. It has been split out of the larger Boston board support series
> at Michal's request.
> 
> Applies atop v4.5-rc2.
> 
> Paul Burton (6):
>   PCI: xilinx: Keep references to both IRQ domains
>   PCI: xilinx: Unify INTx & MSI interrupt FIFO decode
>   PCI: xilinx: Always clear interrupt decode register
>   PCI: xilinx: Clear interrupt FIFO during probe
>   PCI: xilinx: Fix INTX irq dispatch
>   PCI: xilinx: Allow build on MIPS platforms
> 
>  drivers/pci/host/Kconfig       |   2 +-
>  drivers/pci/host/pcie-xilinx.c | 125 +++++++++++++++++++----------------------

Looks like Bharat has some IRQ concerns, so I'm guessing you'll be
posting a v4?

Bjorn


From kirill at shutemov.name  Thu Feb 25 08:01:11 2016
From: kirill at shutemov.name (Kirill A. Shutemov)
Date: Thu, 25 Feb 2016 19:01:11 +0300
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <CAPvkgC3gfmgA9aCvCeqReKhjpkT5Y-qk-2fNO8puDjUs9EWzVw@mail.gmail.com>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160223103221.GA1418@node.shutemov.name>
 <20160223191907.25719a4d@thinkpad> <20160223184658.GA27281@arm.com>
 <CAPvkgC3gfmgA9aCvCeqReKhjpkT5Y-qk-2fNO8puDjUs9EWzVw@mail.gmail.com>
Message-ID: <20160225160111.GB19707@node.shutemov.name>

On Thu, Feb 25, 2016 at 03:49:33PM +0000, Steve Capper wrote:
> On 23 February 2016 at 18:47, Will Deacon <will.deacon at arm.com> wrote:
> > [adding Steve, since he worked on THP for 32-bit ARM]
> 
> Apologies for my late reply...
> 
> >
> > On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> >> On Tue, 23 Feb 2016 13:32:21 +0300
> >> "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
> >> > The theory is that the splitting bit effetely masked bogus pmd_present():
> >> > we had pmd_trans_splitting() in all code path and that prevented mm from
> >> > touching the pmd. Once pmd_trans_splitting() has gone, mm proceed with the
> >> > pmd where it shouldn't and here's a boom.
> >>
> >> Well, I don't think pmd_present() == true is bogus for a trans_huge pmd under
> >> splitting, after all there is a page behind the the pmd. Also, if it was
> >> bogus, and it would need to be false, why should it be marked !pmd_present()
> >> only at the pmdp_invalidate() step before the pmd_populate()? It clearly
> >> is pmd_present() before that, on all architectures, and if there was any
> >> problem/race with that, setting it to !pmd_present() at this stage would
> >> only (marginally) reduce the race window.
> >>
> >> BTW, PowerPC and Sparc seem to do the same thing in pmdp_invalidate(),
> >> i.e. they do not set pmd_present() == false, only mark it so that it would
> >> not generate a new TLB entry, just like on s390. After all, the function
> >> is called pmdp_invalidate(), and I think the comment in mm/huge_memory.c
> >> before that call is just a little ambiguous in its wording. When it says
> >> "mark the pmd notpresent" it probably means "mark it so that it will not
> >> generate a new TLB entry", which is also what the comment is really about:
> >> prevent huge and small entries in the TLB for the same page at the same
> >> time.
> >>
> >> FWIW, and since the ARM arch-list is already on cc, I think there is
> >> an issue with pmdp_invalidate() on ARM, since it also seems to clear
> >> the trans_huge (and formerly trans_splitting) bit, which actually makes
> >> the pmd !pmd_present(), but it violates the other requirement from the
> >> comment:
> >> "the pmd_trans_huge and pmd_trans_splitting must remain set at all times
> >> on the pmd until the split is complete for this pmd"
> >
> > I've only been testing this for arm64 (where I'm yet to see a problem),
> > but we use the generic pmdp_invalidate implementation from
> > mm/pgtable-generic.c there. On arm64, pmd_trans_huge will return true
> > after pmd_mknotpresent. On arm, it does look to be buggy, since it nukes
> > the entire entry... Steve?
> 
> pmd_mknotpresent on arm looks inconsistent with the other
> architectures and can be changed.
> 
> Having had a look at the usage, I can't see it causing an immediate
> problem (that needs to be addressed by an emergency patch).
> We don't have a notion of splitting pmds (so there is no splitting
> information to lose), and the only usage I could see of
> pmd_mknotpresent was:
> 
> pmdp_invalidate(vma, haddr, pmd);
> pmd_populate(mm, pmd, pgtable);
> 
> In mm/huge_memory.c, around line 3588.
> 
> So we invalidate the entry (which puts down a faulting entry from
> pmd_mknotpresent and invalidates tlb), then immediately put down a
> table entry with pmd_populate.
> 
> I have run a 32-bit ARM test kernel and exacerbated THP splits (that's
> what took me time), and I didn't notice any problems with 4.5-rc5.

If I read code correctly, your pmd_mknotpresent() makes the pmd
pmd_none(), right? If yes, it's a problem.

It introduces race I've described here:

https://marc.info/?l=linux-mm&m=144723658100512&w=4

Basically, if zap_pmd_range() would see pmd_none() between
pmdp_mknotpresent() and pmd_populate(), we're screwed.

The race window is small, but it's there.

-- 
 Kirill A. Shutemov


From lorenzo.pieralisi at arm.com  Thu Feb 25 08:05:33 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 25 Feb 2016 16:05:33 +0000
Subject: [PATCH 3/3] arm/arm64: pci: remove arch specific
 pcibios_enable_device()
In-Reply-To: <20160225152417.GB8120@localhost>
References: <1447779838-15585-1-git-send-email-lorenzo.pieralisi@arm.com>
 <1447779838-15585-3-git-send-email-lorenzo.pieralisi@arm.com>
 <20151123134921.GB4236@arm.com> <20160120162215.GE13437@red-moon>
 <20160225152417.GB8120@localhost>
Message-ID: <20160225160533.GA3596@red-moon>

Hi Bjorn,

On Thu, Feb 25, 2016 at 09:24:17AM -0600, Bjorn Helgaas wrote:
> Hi Lorenzo,
> 
> On Wed, Jan 20, 2016 at 04:22:15PM +0000, Lorenzo Pieralisi wrote:
> > On Mon, Nov 23, 2015 at 01:49:21PM +0000, Will Deacon wrote:
> > > On Tue, Nov 17, 2015 at 05:03:58PM +0000, Lorenzo Pieralisi wrote:
> > > > The arm/arm64 pcibios_enable_device() implementations exist solely
> > > > to prevent enabling PCI resources on PROBE_ONLY systems, since
> > > > on those systems the PCI resources are currently not claimed (ie
> > > > validated and inserted in the PCI resource tree) therefore they can
> > > > not be enabled since this would trigger PCI set-ups failures.
> > > > 
> > > > By introducing resources claiming in the PCI host controllers set-ups
> > > > that have PROBE_ONLY as a probe option, there is no need for arch specific
> > > > pcibios_enable_device() implementations anymore in that the kernel can
> > > > rely on the generic pcibios_enable_device() implementation without
> > > > resorting to arch specific code to work around the missing resources
> > > > claiming enumeration step.
> > > > 
> > > > This patch removes the pcibios_enable_device() implementations from
> > > > the arm/arm64 arch back-ends.
> > > > 
> > > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> > > > Cc: Arnd Bergmann <arnd at arndb.de>
> > > > Cc: Will Deacon <will.deacon at arm.com>
> > > > Cc: Bjorn Helgaas <bhelgaas at google.com>
> > > > Cc: Russell King <linux at arm.linux.org.uk>
> > > > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > > > ---
> > > >  arch/arm/kernel/bios32.c | 12 ------------
> > > >  arch/arm64/kernel/pci.c  | 13 -------------
> > > >  2 files changed, 25 deletions(-)
> > > 
> > > Acked-by: Will Deacon <will.deacon at arm.com>
> > 
> > Thanks, unfortunately I spotted that ARM platforms can set
> > PCI_PROBE_ONLY also via command line (pcibios_setup()), which means
> > that I have to add resource claiming to all ARM PCI controllers that
> > check PCI_PROBE_ONLY (inclusive of ARM bios32) to really make sure we
> > can apply this patch or alternatevely we add the resource claiming
> > to the pcibios_fixup_bus() callback (but we can claim resources only if
> > PCI_PROBE_ONLY is set lest we trigger regressions) which would be the
> > simpler solution.
> 
> So where are we?  The above response sounds like this series still
> needs a little tweaking?

Yes, I rewrote the generic PCI layer for claiming resources (Tomasz's
posted it in its ACPI PCI ARM64 series):

https://lkml.org/lkml/2016/2/16/412

My only concern is removing PCI_PROBE_ONLY handling from arm 32 bit code,
since I noticed it can be set on the command line there, claiming
resources in pcibios arm 32 should do the trick, I will move the ARM
32-bit handling in a separate patch (hopefully someone can help me test
it on affected platforms (?), I will ask Russell the best way to do it).

Thanks,
Lorenzo


From troy.kisky at boundarydevices.com  Thu Feb 25 08:05:34 2016
From: troy.kisky at boundarydevices.com (Troy Kisky)
Date: Thu, 25 Feb 2016 09:05:34 -0700
Subject: [PATCH net-next V2 00/16] net: fec: cleanup and fixes
In-Reply-To: <5514193.TiF8b6rKpj@diplodocus>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
 <5514193.TiF8b6rKpj@diplodocus>
Message-ID: <56CF264E.2070903@boundarydevices.com>

On 2/24/2016 7:52 PM, Joshua Clayton wrote:
> Hello Troy,
> I'm replying here instead of to a particular commit because several of
> the commit messages seem inadequate.
> 
> The first line summaries all look good.
> 
> The descriptions should each also include the "user visible impact" of
> the patch and the justification for it (i.e. why you made the change).
> 
> For instance, patch 3 doesn't include either what will change
>  (nothing, I'm guessing?) or why we now pass in the structures
> instead of a queue_id. 

I can add to the commit message, that this is in preparation for
patch 4 which depends on it. Or I could squash patches 2/3/4
together, but I think it is easier to review smaller patches.


> 
> You've also got a few (e.g. patch 9, patch 14) where the substance
> of the patch is in the summary,
> 
> but missing from the message.
> 
> These kind of descriptions are very hard to review since the expression
> is split between the subject of the email and the body of the email, which
> are not close
> together in some email programs.
> 
> Better to reiterate or elaborate on the summary in the message.
> In patch 9, for instance, it would be more clear to say:
> 
> Move restart test to earlier in fec_txq() which saves one comparison. 


I can do this. And change patch 14 to read


Create subroutine reset_tx_queue to have one place
to release any queued tx skbs.

Any other commit messages you'd like to improve?


> P.S I'm a little confused, as I came looking for a v3 of the first 8 patches
> and found these instead. I'll try to give your first 8 a look when they show up.

The 1st 8 patches have already been applied. I added a patch to address your review there
at the end of the series. So, that patch will show up in my next set.


Thanks for the review

Troy


From will.deacon at arm.com  Thu Feb 25 08:07:15 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Feb 2016 16:07:15 +0000
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160225160714.GA16546@arm.com>

Hi Ard,

On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
> This adds support for emitting PLTs at module load time for relative
> branches that are out of range. This is a prerequisite for KASLR, which
> may place the kernel and the modules anywhere in the vmalloc area,
> making it more likely that branch target offsets exceed the maximum
> range of +/- 128 MB.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
> 
> In this version, I removed the distinction between relocations against
> .init executable sections and ordinary executable sections. The reason
> is that it is hardly worth the trouble, given that .init.text usually
> does not contain that many far branches, and this version now only
> reserves PLT entry space for jump and call relocations against undefined
> symbols (since symbols defined in the same module can be assumed to be
> within +/- 128 MB)
> 
> For example, the mac80211.ko module (which is fairly sizable at ~400 KB)
> built with -mcmodel=large gives the following relocation counts:
> 
>                     relocs    branches   unique     !local
>   .text              3925       3347       518        219
>   .init.text           11          8         7          1
>   .exit.text            4          4         4          1
>   .text.unlikely       81         67        36         17
> 
> ('unique' means branches to unique type/symbol/addend combos, of which
> !local is the subset referring to undefined symbols)
> 
> IOW, we are only emitting a single PLT entry for the .init sections, and
> we are better off just adding it to the core PLT section instead.
> ---
>  arch/arm64/Kconfig              |   9 +
>  arch/arm64/Makefile             |   6 +-
>  arch/arm64/include/asm/module.h |  11 ++
>  arch/arm64/kernel/Makefile      |   1 +
>  arch/arm64/kernel/module-plts.c | 201 ++++++++++++++++++++
>  arch/arm64/kernel/module.c      |  12 ++
>  arch/arm64/kernel/module.lds    |   3 +
>  7 files changed, 242 insertions(+), 1 deletion(-)

[...]

> +struct plt_entry {
> +	/*
> +	 * A program that conforms to the AArch64 Procedure Call Standard
> +	 * (AAPCS64) must assume that a veneer that alters IP0 (x16) and/or
> +	 * IP1 (x17) may be inserted at any branch instruction that is
> +	 * exposed to a relocation that supports long branches. Since that
> +	 * is exactly what we are dealing with here, we are free to use x16
> +	 * as a scratch register in the PLT veneers.
> +	 */
> +	__le32	mov0;	/* movn	x16, #0x....			*/
> +	__le32	mov1;	/* movk	x16, #0x...., lsl #16		*/
> +	__le32	mov2;	/* movk	x16, #0x...., lsl #32		*/
> +	__le32	br;	/* br	x16				*/
> +};

I'm worried about this code when CONFIG_ARM64_LSE_ATOMICS=y, but we don't
detect them on the CPU at runtime. In this case, all atomic operations
are moved out-of-line and called using a bl instruction from inline asm.

The out-of-line code is compiled with magic GCC options to force the
explicit save/restore of all used registers (see arch/arm64/lib/Makefile),
otherwise we'd have to clutter the inline asm with constraints that
wouldn't be needed had we managed to patch the bl with an LSE atomic
instruction.

If you're emitting a PLT, couldn't we end up with silent corruption of
x16 for modules using out-of-line atomics like this?

Will


From steve.capper at linaro.org  Thu Feb 25 08:08:28 2016
From: steve.capper at linaro.org (Steve Capper)
Date: Thu, 25 Feb 2016 16:08:28 +0000
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also
 on PowerPC and ARM)
In-Reply-To: <20160225160111.GB19707@node.shutemov.name>
References: <20160211192223.4b517057@thinkpad>
 <20160211190942.GA10244@node.shutemov.name>
 <20160211205702.24f0d17a@thinkpad>
 <20160212154116.GA15142@node.shutemov.name>
 <56BE00E7.1010303@de.ibm.com> <20160212181640.4eabb85f@thinkpad>
 <20160223103221.GA1418@node.shutemov.name>
 <20160223191907.25719a4d@thinkpad> <20160223184658.GA27281@arm.com>
 <CAPvkgC3gfmgA9aCvCeqReKhjpkT5Y-qk-2fNO8puDjUs9EWzVw@mail.gmail.com>
 <20160225160111.GB19707@node.shutemov.name>
Message-ID: <CAPvkgC3vbAG9f-MnVoZ_VwQMZNTbhS6Vx0FgcVGSCcOKgmqWkA@mail.gmail.com>

On 25 February 2016 at 16:01, Kirill A. Shutemov <kirill at shutemov.name> wrote:
> On Thu, Feb 25, 2016 at 03:49:33PM +0000, Steve Capper wrote:
>> On 23 February 2016 at 18:47, Will Deacon <will.deacon at arm.com> wrote:
>> > [adding Steve, since he worked on THP for 32-bit ARM]
>>
>> Apologies for my late reply...
>>
>> >
>> > On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
>> >> On Tue, 23 Feb 2016 13:32:21 +0300
>> >> "Kirill A. Shutemov" <kirill at shutemov.name> wrote:
>> >> > The theory is that the splitting bit effetely masked bogus pmd_present():
>> >> > we had pmd_trans_splitting() in all code path and that prevented mm from
>> >> > touching the pmd. Once pmd_trans_splitting() has gone, mm proceed with the
>> >> > pmd where it shouldn't and here's a boom.
>> >>
>> >> Well, I don't think pmd_present() == true is bogus for a trans_huge pmd under
>> >> splitting, after all there is a page behind the the pmd. Also, if it was
>> >> bogus, and it would need to be false, why should it be marked !pmd_present()
>> >> only at the pmdp_invalidate() step before the pmd_populate()? It clearly
>> >> is pmd_present() before that, on all architectures, and if there was any
>> >> problem/race with that, setting it to !pmd_present() at this stage would
>> >> only (marginally) reduce the race window.
>> >>
>> >> BTW, PowerPC and Sparc seem to do the same thing in pmdp_invalidate(),
>> >> i.e. they do not set pmd_present() == false, only mark it so that it would
>> >> not generate a new TLB entry, just like on s390. After all, the function
>> >> is called pmdp_invalidate(), and I think the comment in mm/huge_memory.c
>> >> before that call is just a little ambiguous in its wording. When it says
>> >> "mark the pmd notpresent" it probably means "mark it so that it will not
>> >> generate a new TLB entry", which is also what the comment is really about:
>> >> prevent huge and small entries in the TLB for the same page at the same
>> >> time.
>> >>
>> >> FWIW, and since the ARM arch-list is already on cc, I think there is
>> >> an issue with pmdp_invalidate() on ARM, since it also seems to clear
>> >> the trans_huge (and formerly trans_splitting) bit, which actually makes
>> >> the pmd !pmd_present(), but it violates the other requirement from the
>> >> comment:
>> >> "the pmd_trans_huge and pmd_trans_splitting must remain set at all times
>> >> on the pmd until the split is complete for this pmd"
>> >
>> > I've only been testing this for arm64 (where I'm yet to see a problem),
>> > but we use the generic pmdp_invalidate implementation from
>> > mm/pgtable-generic.c there. On arm64, pmd_trans_huge will return true
>> > after pmd_mknotpresent. On arm, it does look to be buggy, since it nukes
>> > the entire entry... Steve?
>>
>> pmd_mknotpresent on arm looks inconsistent with the other
>> architectures and can be changed.
>>
>> Having had a look at the usage, I can't see it causing an immediate
>> problem (that needs to be addressed by an emergency patch).
>> We don't have a notion of splitting pmds (so there is no splitting
>> information to lose), and the only usage I could see of
>> pmd_mknotpresent was:
>>
>> pmdp_invalidate(vma, haddr, pmd);
>> pmd_populate(mm, pmd, pgtable);
>>
>> In mm/huge_memory.c, around line 3588.
>>
>> So we invalidate the entry (which puts down a faulting entry from
>> pmd_mknotpresent and invalidates tlb), then immediately put down a
>> table entry with pmd_populate.
>>
>> I have run a 32-bit ARM test kernel and exacerbated THP splits (that's
>> what took me time), and I didn't notice any problems with 4.5-rc5.
>
> If I read code correctly, your pmd_mknotpresent() makes the pmd
> pmd_none(), right? If yes, it's a problem.
>
> It introduces race I've described here:
>
> https://marc.info/?l=linux-mm&m=144723658100512&w=4
>
> Basically, if zap_pmd_range() would see pmd_none() between
> pmdp_mknotpresent() and pmd_populate(), we're screwed.
>
> The race window is small, but it's there.

Ahhhh, okay, thank you Kirill.
I agree, I'll get a patch out.

Cheers,
--
Steve


From gregkh at linuxfoundation.org  Thu Feb 25 08:09:30 2016
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Thu, 25 Feb 2016 16:09:30 +0000
Subject: [PATCH v2] tty/serial: at91: restore dynamic driver binding
In-Reply-To: <56CED0E3.5070308@atmel.com>
References: <1456392221-30401-1-git-send-email-romain.izard.pro@gmail.com>
 <56CED0E3.5070308@atmel.com>
Message-ID: <20160225160929.GA20373@kroah.com>

On Thu, Feb 25, 2016 at 11:01:07AM +0100, Nicolas Ferre wrote:
> Le 25/02/2016 10:23, Romain Izard a ?crit :
> > In commit c39dfebc7798956fd2140ae6321786ff35da30c3, the modular support
> > code for atmel_serial was removed, as the driver cannot be built as a
> > module. Because no use case was proposed, the dynamic driver binding
> > support was removed as well.
> > 
> > The atmel_serial driver can manage up to 7 serial controllers, which are
> > multiplexed with other functions. For example, in the Atmel SAMA5D2, the
> > Flexcom controllers can work as USART, SPI or I2C controllers, and on
> > all Atmel devices serial lines can be reconfigured as GPIOs.
> > 
> > My use case uses GPIOs to transfer a firmware update using a custom
> > protocol on the lines used as a serial port during the normal life of
> > the device. If it is not possible to unbind the atmel_serial driver, the
> > GPIO lines remain reserved and prevent this case from working.
> > 
> > This patch reinstates the atmel_serial_remove function, and fixes it as
> > it failed to clear the "clk" field on removal, triggering an oops when
> > a device was bound again after being unbound.
> > 
> > Signed-off-by: Romain Izard <romain.izard.pro at gmail.com>
> 
> Even if you didn't follow my advice for not including unneeded changes
> in of the last patch chunk, there's no use delaying the patch just for
> this. So, here is my:

Yes there is, I'm not going to take this, Romain please fix it properly.

greg k-h



From arnd at arndb.de  Thu Feb 25 08:10:42 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 17:10:42 +0100
Subject: [PATCH 0/4] RealView boardfile endgame
In-Reply-To: <CACRpkdZ_oyJNTzC6Ji+19aRy3Ex47u2Khqd7_RwuGdK+TLTy_A@mail.gmail.com>
References: <1456406111-18579-1-git-send-email-linus.walleij@linaro.org>
 <5411123.nOOnE7uo7z@wuerfel>
 <CACRpkdZ_oyJNTzC6Ji+19aRy3Ex47u2Khqd7_RwuGdK+TLTy_A@mail.gmail.com>
Message-ID: <3638303.456FExenOa@wuerfel>

On Thursday 25 February 2016 16:29:31 Linus Walleij wrote:
> On Thu, Feb 25, 2016 at 3:29 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Thursday 25 February 2016 14:15:07 Linus Walleij wrote:
> >> This patch set deletes the RealView board files and moves it
> >> over to a pure Device Tree boot, deleting ~3500 LoC.
> (...)
> > This leaves the question whether we should do all the preparation
> > in 4.6 and then only take these for 4.7, or do them all at
> > once. I can see good reasons either way, but none of them
> > particularly strong. What did you have in mind here?
> 
> If the dependencies in CLCD and MTD make it in we'll just
> merge the whole thing IMO.
> 
> If these drag out, we merge the device trees and wait with
> removing the board files until v4.7.
> 
> I will still have some remaining cleanup for Integrator, Versatile
> and also Versatile Express however, but that is for later.
> 
> 

Ok, sounds good.

	Arnd


From arnd at arndb.de  Thu Feb 25 08:08:24 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 17:08:24 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CACRpkdZd8TLdsi7_cOrqzcqWKJrfdp4Vz2sx5ozpwJXOj0fa+Q@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <56CC60C4.6040908@ti.com>
 <CACRpkdZd8TLdsi7_cOrqzcqWKJrfdp4Vz2sx5ozpwJXOj0fa+Q@mail.gmail.com>
Message-ID: <3564059.gK0TOyJAie@wuerfel>

On Thursday 25 February 2016 15:04:52 Linus Walleij wrote:
> 
> I add support for doing this for the Integrator and RealView in
> the patch set, by grabbing a handle to the system controller
> where they have a few "misc registers". However if you look at
> it:
> 
> static void integrator_clcd_enable(struct clcd_fb *fb)
> {
>         struct fb_var_screeninfo *var = &fb->fb.var;
>         u32 val;
> 
>         dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");
> 
>         val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
>                 INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
>         if (var->bits_per_pixel <= 8 ||
>             (var->bits_per_pixel == 16 && var->green.length == 5))
>                 /* Pseudocolor, RGB555, BGR555 */
>                 val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
>         else if (fb->fb.var.bits_per_pixel <= 16)
>                 /* truecolor RGB565 */
>                 val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
>         else
>                 val = 0; /* no idea for this, don't trust the docs */
> 
>         regmap_update_bits(versatile_syscon_map,
>                            INTEGRATOR_HDR_CTRL_OFFSET,
>                            0,
>                            INTEGRATOR_CLCD_MASK);
> }
> 
> This is stuff that is so closely tied in to the fbdev driver that even
> if it is SoC-specific (and reside in arch/arm/mach-integrator etc
> today) it would be hard to argument that it should not be part
> of the fbdev driver: what it does is connect the lines out of the
> CLCD block to the physical VGA encode chip in different ways
> depending on how the pixels were set up.

I think the nicest approach here would be to make this a layered
driver, where you have a separate platform_driver instance
that contains all the versatile specific add-ons, and this calls
into the common driver that handles everything that is not specific
to versatile.

It may not be worth investing much into a rework to get there
though, so simply putting it all into one module sounds like
a reasonable compromise.

	Arnd


From ard.biesheuvel at linaro.org  Thu Feb 25 08:12:01 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 25 Feb 2016 17:12:01 +0100
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <20160225160714.GA16546@arm.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160225160714.GA16546@arm.com>
Message-ID: <CAKv+Gu94LAAwj2f9Sj9imn68V0VTF+NOtUPsE3tQnVzNDhAATw@mail.gmail.com>

On 25 February 2016 at 17:07, Will Deacon <will.deacon at arm.com> wrote:
> Hi Ard,
>
> On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
>> This adds support for emitting PLTs at module load time for relative
>> branches that are out of range. This is a prerequisite for KASLR, which
>> may place the kernel and the modules anywhere in the vmalloc area,
>> making it more likely that branch target offsets exceed the maximum
>> range of +/- 128 MB.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> ---
>>
>> In this version, I removed the distinction between relocations against
>> .init executable sections and ordinary executable sections. The reason
>> is that it is hardly worth the trouble, given that .init.text usually
>> does not contain that many far branches, and this version now only
>> reserves PLT entry space for jump and call relocations against undefined
>> symbols (since symbols defined in the same module can be assumed to be
>> within +/- 128 MB)
>>
>> For example, the mac80211.ko module (which is fairly sizable at ~400 KB)
>> built with -mcmodel=large gives the following relocation counts:
>>
>>                     relocs    branches   unique     !local
>>   .text              3925       3347       518        219
>>   .init.text           11          8         7          1
>>   .exit.text            4          4         4          1
>>   .text.unlikely       81         67        36         17
>>
>> ('unique' means branches to unique type/symbol/addend combos, of which
>> !local is the subset referring to undefined symbols)
>>
>> IOW, we are only emitting a single PLT entry for the .init sections, and
>> we are better off just adding it to the core PLT section instead.
>> ---
>>  arch/arm64/Kconfig              |   9 +
>>  arch/arm64/Makefile             |   6 +-
>>  arch/arm64/include/asm/module.h |  11 ++
>>  arch/arm64/kernel/Makefile      |   1 +
>>  arch/arm64/kernel/module-plts.c | 201 ++++++++++++++++++++
>>  arch/arm64/kernel/module.c      |  12 ++
>>  arch/arm64/kernel/module.lds    |   3 +
>>  7 files changed, 242 insertions(+), 1 deletion(-)
>
> [...]
>
>> +struct plt_entry {
>> +     /*
>> +      * A program that conforms to the AArch64 Procedure Call Standard
>> +      * (AAPCS64) must assume that a veneer that alters IP0 (x16) and/or
>> +      * IP1 (x17) may be inserted at any branch instruction that is
>> +      * exposed to a relocation that supports long branches. Since that
>> +      * is exactly what we are dealing with here, we are free to use x16
>> +      * as a scratch register in the PLT veneers.
>> +      */
>> +     __le32  mov0;   /* movn x16, #0x....                    */
>> +     __le32  mov1;   /* movk x16, #0x...., lsl #16           */
>> +     __le32  mov2;   /* movk x16, #0x...., lsl #32           */
>> +     __le32  br;     /* br   x16                             */
>> +};
>
> I'm worried about this code when CONFIG_ARM64_LSE_ATOMICS=y, but we don't
> detect them on the CPU at runtime. In this case, all atomic operations
> are moved out-of-line and called using a bl instruction from inline asm.
>
> The out-of-line code is compiled with magic GCC options

Which options are those exactly?

> to force the
> explicit save/restore of all used registers (see arch/arm64/lib/Makefile),
> otherwise we'd have to clutter the inline asm with constraints that
> wouldn't be needed had we managed to patch the bl with an LSE atomic
> instruction.
>
> If you're emitting a PLT, couldn't we end up with silent corruption of
> x16 for modules using out-of-line atomics like this?
>

If you violate the AAPCS64 ABI, then obviously the claim above does not hold.


From ard.biesheuvel at linaro.org  Thu Feb 25 08:13:07 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 25 Feb 2016 17:13:07 +0100
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <CAKv+Gu94LAAwj2f9Sj9imn68V0VTF+NOtUPsE3tQnVzNDhAATw@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160225160714.GA16546@arm.com>
 <CAKv+Gu94LAAwj2f9Sj9imn68V0VTF+NOtUPsE3tQnVzNDhAATw@mail.gmail.com>
Message-ID: <CAKv+Gu93wj9P8Bxie7Yry5HO3pM2dL=-mLgd9tV=0UhdCbpVBw@mail.gmail.com>

On 25 February 2016 at 17:12, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 25 February 2016 at 17:07, Will Deacon <will.deacon at arm.com> wrote:
>> Hi Ard,
>>
>> On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
>>> This adds support for emitting PLTs at module load time for relative
>>> branches that are out of range. This is a prerequisite for KASLR, which
>>> may place the kernel and the modules anywhere in the vmalloc area,
>>> making it more likely that branch target offsets exceed the maximum
>>> range of +/- 128 MB.
>>>
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>>> ---
>>>
>>> In this version, I removed the distinction between relocations against
>>> .init executable sections and ordinary executable sections. The reason
>>> is that it is hardly worth the trouble, given that .init.text usually
>>> does not contain that many far branches, and this version now only
>>> reserves PLT entry space for jump and call relocations against undefined
>>> symbols (since symbols defined in the same module can be assumed to be
>>> within +/- 128 MB)
>>>
>>> For example, the mac80211.ko module (which is fairly sizable at ~400 KB)
>>> built with -mcmodel=large gives the following relocation counts:
>>>
>>>                     relocs    branches   unique     !local
>>>   .text              3925       3347       518        219
>>>   .init.text           11          8         7          1
>>>   .exit.text            4          4         4          1
>>>   .text.unlikely       81         67        36         17
>>>
>>> ('unique' means branches to unique type/symbol/addend combos, of which
>>> !local is the subset referring to undefined symbols)
>>>
>>> IOW, we are only emitting a single PLT entry for the .init sections, and
>>> we are better off just adding it to the core PLT section instead.
>>> ---
>>>  arch/arm64/Kconfig              |   9 +
>>>  arch/arm64/Makefile             |   6 +-
>>>  arch/arm64/include/asm/module.h |  11 ++
>>>  arch/arm64/kernel/Makefile      |   1 +
>>>  arch/arm64/kernel/module-plts.c | 201 ++++++++++++++++++++
>>>  arch/arm64/kernel/module.c      |  12 ++
>>>  arch/arm64/kernel/module.lds    |   3 +
>>>  7 files changed, 242 insertions(+), 1 deletion(-)
>>
>> [...]
>>
>>> +struct plt_entry {
>>> +     /*
>>> +      * A program that conforms to the AArch64 Procedure Call Standard
>>> +      * (AAPCS64) must assume that a veneer that alters IP0 (x16) and/or
>>> +      * IP1 (x17) may be inserted at any branch instruction that is
>>> +      * exposed to a relocation that supports long branches. Since that
>>> +      * is exactly what we are dealing with here, we are free to use x16
>>> +      * as a scratch register in the PLT veneers.
>>> +      */
>>> +     __le32  mov0;   /* movn x16, #0x....                    */
>>> +     __le32  mov1;   /* movk x16, #0x...., lsl #16           */
>>> +     __le32  mov2;   /* movk x16, #0x...., lsl #32           */
>>> +     __le32  br;     /* br   x16                             */
>>> +};
>>
>> I'm worried about this code when CONFIG_ARM64_LSE_ATOMICS=y, but we don't
>> detect them on the CPU at runtime. In this case, all atomic operations
>> are moved out-of-line and called using a bl instruction from inline asm.
>>
>> The out-of-line code is compiled with magic GCC options
>
> Which options are those exactly?
>
>> to force the
>> explicit save/restore of all used registers (see arch/arm64/lib/Makefile),
>> otherwise we'd have to clutter the inline asm with constraints that
>> wouldn't be needed had we managed to patch the bl with an LSE atomic
>> instruction.
>>
>> If you're emitting a PLT, couldn't we end up with silent corruption of
>> x16 for modules using out-of-line atomics like this?
>>
>
> If you violate the AAPCS64 ABI, then obviously the claim above does not hold.

IOW, yes, x16 will be corrupted unexpectedly if it you are expecting
it to be preserved across a bl or b instruction that is exposed to a
jump/call relocation


From will.deacon at arm.com  Thu Feb 25 08:16:30 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Feb 2016 16:16:30 +0000
Subject: [PATCH v3 2/2] arm64: Mark kernel page ranges contiguous
In-Reply-To: <1455903983-23910-3-git-send-email-jeremy.linton@arm.com>
References: <1455903983-23910-1-git-send-email-jeremy.linton@arm.com>
 <1455903983-23910-3-git-send-email-jeremy.linton@arm.com>
Message-ID: <20160225161630.GB16546@arm.com>

On Fri, Feb 19, 2016 at 11:46:23AM -0600, Jeremy Linton wrote:
> With 64k pages, the next larger segment size is 512M. The linux
> kernel also uses different protection flags to cover its code and data.
> Because of these requirements, the vast majority of the kernel code and
> data structures end up being mapped with 64k pages instead of the larger
> pages common with a 4k page kernel.
> 
> Recent ARM processors support a contiguous bit in the
> page tables which allows a TLB to cover a range larger than a
> single PTE if that range is mapped into physically contiguous
> RAM.
> 
> So, for the kernel its a good idea to set this flag. Some basic
> micro benchmarks show it can significantly reduce the number of
> L1 dTLB refills.
> 
> Signed-off-by: Jeremy Linton <jeremy.linton at arm.com>
> ---
>  arch/arm64/mm/mmu.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 58 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 7711554..ab69a99 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1,3 +1,4 @@
> +
>  /*
>   * Based on arch/arm/mm/mmu.c
>   *
> @@ -103,17 +104,49 @@ static void split_pmd(pmd_t *pmd, pte_t *pte)
>  		 * Need to have the least restrictive permissions available
>  		 * permissions will be fixed up later
>  		 */
> -		set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC));
> +		set_pte(pte, pfn_pte(pfn, PAGE_KERNEL_EXEC_CONT));
>  		pfn++;
>  	} while (pte++, i++, i < PTRS_PER_PTE);
>  }
>  
> +static void clear_cont_pte_range(pte_t *pte, unsigned long addr)
> +{
> +	int i;
> +
> +	pte -= CONT_RANGE_OFFSET(addr);
> +	for (i = 0; i < CONT_PTES; i++) {
> +		if (pte_cont(*pte))
> +			set_pte(pte, pte_mknoncont(*pte));
> +		pte++;
> +	}
> +	flush_tlb_all();

Do you still need this invalidation? I thought the table weren't even
live at this point?

> +}
> +
> +/*
> + * Given a range of PTEs set the pfn and provided page protection flags
> + */
> +static void __populate_init_pte(pte_t *pte, unsigned long addr,
> +			       unsigned long end, phys_addr_t phys,
> +			       pgprot_t prot)
> +{
> +	unsigned long pfn = __phys_to_pfn(phys);
> +
> +	do {
> +		/* clear all the bits except the pfn, then apply the prot */
> +		set_pte(pte, pfn_pte(pfn, prot));
> +		pte++;
> +		pfn++;
> +		addr += PAGE_SIZE;
> +	} while (addr != end);
> +}
> +
>  static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
> -				  unsigned long end, unsigned long pfn,
> +				  unsigned long end, phys_addr_t phys,
>  				  pgprot_t prot,
>  				  phys_addr_t (*pgtable_alloc)(void))
>  {
>  	pte_t *pte;
> +	unsigned long next;
>  
>  	if (pmd_none(*pmd) || pmd_sect(*pmd)) {
>  		phys_addr_t pte_phys = pgtable_alloc();
> @@ -127,10 +160,29 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
>  	BUG_ON(pmd_bad(*pmd));
>  
>  	pte = pte_set_fixmap_offset(pmd, addr);
> +
>  	do {
> -		set_pte(pte, pfn_pte(pfn, prot));
> -		pfn++;
> -	} while (pte++, addr += PAGE_SIZE, addr != end);
> +		next = min(end, (addr + CONT_SIZE) & CONT_MASK);
> +		if (((addr | next | phys) & ~CONT_MASK) == 0) {
> +			/* a block of CONT_PTES	 */
> +			__populate_init_pte(pte, addr, next, phys,
> +					    prot | __pgprot(PTE_CONT));
> +		} else {
> +			/*
> +			 * If the range being split is already inside of a
> +			 * contiguous range but this PTE isn't going to be
> +			 * contiguous, then we want to unmark the adjacent
> +			 * ranges, then update the portion of the range we
> +			 * are interrested in.
> +			 */
> +			clear_cont_pte_range(pte, addr);
> +			__populate_init_pte(pte, addr, next, phys, prot);

I don't understand the comment or the code here... the splitting is now
done seperately, and I can't think of a scenario where you need to clear
the cont hint explicitly for adjacent ptes.

What am I missing?

Will


From mark.rutland at arm.com  Thu Feb 25 08:16:47 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 25 Feb 2016 16:16:47 +0000
Subject: [PATCH 1/3] dt-bindings: arm/marvell: ABI unstability warning
 about Marvell 7K/8K
In-Reply-To: <20160225090927.13492cfb@free-electrons.com>
References: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1456327007-31008-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160224172545.GC9137@leverpostej>
 <20160224211045.379352d3@free-electrons.com>
 <CAL_JsqLevrujSeYNBvSJA-5T0Ho8y7c0fKid7QvVm8LLvYLotw@mail.gmail.com>
 <20160225090927.13492cfb@free-electrons.com>
Message-ID: <20160225161642.GC10593@leverpostej>

On Thu, Feb 25, 2016 at 09:09:27AM +0100, Thomas Petazzoni wrote:
> Hello Rob,
> 
> On Wed, 24 Feb 2016 16:07:04 -0600, Rob Herring wrote:
> 
> > You should fix the incomplete information problem. I pushed back on
> > this, you got more information and already the binding is closer to
> > reality.
> 
> "You should fix the incomplete information problem". You seem to think
> that it is a simple thing that can be fixed with a magic wand. But it's
> not.
> 
> Either because the internal processes are complicated, or simply
> because the Linux kernel support is done without cooperation from the
> HW vendor (it's not the case of this Marvell platform, but it's the
> case of many other platforms).

Yes, this is a problem in some cases, and that should be considered in
those cases. There are always shades of grey.

Per the above, that isn't relevant in this case. This is a pretty
black-and-white stand against the usual rules.

> > Mark didn't say don't submit. First, there is value in submitting even
> > if not accepted immediately and you have to carry some patches for
> > some time. It was also suggested that you err on the side of less
> > information in DT if things are uncertain and you have not done that.
> 
> Submitting without merging is useless. The point of submitting is to
> get the code merged, to reduce the amount of out-of-tree patches we
> have to carry, and to allow users of the platform to simply run
> mainline on their platform.

Submitting prototypes and RFCs is the usual way we get things reviewed
early, and to allow maintainers and others to get a feel for things
earlier. Submitting patches _for merging_ when you're not sure about
things and don't want to agree to support them is what's being pushed
back on.

> So this proposal really doesn't make any sense. Just like Mark initial
> statement of not submitting code so early.

As what I said was evidently ambiguous, I'm on about code being _merged_
prior to being ready. Code and bindings should certainly be posted for
review as soon as possible. However, it should be recognised when things
aren't quite ready for mainline.

Even if something's unclear about a device, you can highlight more
general issues (e.g. problematic edge cases in common subsystem code),
and that's possible to have merged even if the binding isn't ready.

If you're unsure about something, but still want it merged, then you
have to commit to maintaining that as far as reasonably possible, even
if it turns out to not be quite right.

> > > So please get to an agreement between DT binding maintainers. And stop
> > > saying this ridiculous statement that HW vendors should stop submitting
> > > their code to the mainline.
> > 
> > You want us to agree, then you won't like the answer. Bindings must be
> > stable. I'll allow exceptions to that, but not without push back.
> > 
> > In general, if there is disagreement about whether stability is
> > required, then it is required. See the recent sunxi discussion. That's
> > more between users and platform maintainers though.
> 
> Do you realize that this all DT binding stuff is today the *biggest* to
> getting HW support in the Linux kernel? It has become more complicated
> to merge a 4 properties DT binding than to merge multiple thousands of
> lines of driver code. 

As times have changed, pain points have moved around.

To some extent that is unavoidable; more up-front effort is required
where crutches we previously relied on are not applicable.

Elsewhere we can certainly do better.

Throwing your hands up and stating "this is unstable, it might change"
is a crutch. It prevents any real solution to the pain points you
encounter, and creates pain points for others. It only provides the
_illusion_ of support.

Deliberately violating the rules and then complaining that the rules
don't work because you don't care for them is a terrible argument.

Thanks,
Mark.


From linux at arm.linux.org.uk  Thu Feb 25 08:22:33 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 25 Feb 2016 16:22:33 +0000
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CACRpkdZd8TLdsi7_cOrqzcqWKJrfdp4Vz2sx5ozpwJXOj0fa+Q@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <3695074.sKSIyOjpjD@wuerfel>
 <CACRpkdZjfjOCFUucF1U5yVZBxSwa41GKEMv-HHQE=ymF2NZ21g@mail.gmail.com>
 <6859810.tb1t0IEONi@wuerfel> <56CC57FC.20707@ti.com>
 <CACRpkdYNaNtQQJ-tsBe5ksa4-z380ZQj-zN8ZnK0ED2kNPUwvg@mail.gmail.com>
 <56CC60C4.6040908@ti.com>
 <CACRpkdZd8TLdsi7_cOrqzcqWKJrfdp4Vz2sx5ozpwJXOj0fa+Q@mail.gmail.com>
Message-ID: <20160225162232.GS19428@n2100.arm.linux.org.uk>

On Thu, Feb 25, 2016 at 03:04:52PM +0100, Linus Walleij wrote:
> HOWEVER: the ARM Versatile is the *only* platform I have
> seen of these that have plug'n'play for the display.

And Realview, at least Realview EB, which is the same format board as
Versatile and carries the same LCD connector.

> *All* the others
> will be very happy with *ONE* display defined as panel in the
> device tree, and off they go. Usually VGA. And that will look
> much like arch/arm/boot/dts/vexpress-v2m.dtsi already look
> like today, using "panel-dpi" to define their displays.

Versatile Express only has a DVI connector.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From cory.tusar at pid1solutions.com  Thu Feb 25 08:24:43 2016
From: cory.tusar at pid1solutions.com (Cory Tusar)
Date: Thu, 25 Feb 2016 11:24:43 -0500
Subject: [PATCH] ARM: dts: vf610-zii-dev: Add ZII development board.
In-Reply-To: <c67c93683d9440bd050386df0e200881@agner.ch>
References: <1456084314-9871-1-git-send-email-andrew@lunn.ch>
 <c67c93683d9440bd050386df0e200881@agner.ch>
Message-ID: <56CF2ACB.7080301@pid1solutions.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/23/2016 02:36 PM, Stefan Agner wrote:
> Hi Andrew,
> 
> Some comments below:
> 
> On 2016-02-21 11:51, Andrew Lunn wrote:
>> From: Cory Tusar <cory.tusar at pid1solutions.com>
>>
>> This commit adds support for Rev. B of a Zodiac Inflight Innovations
>> development board, mainly intended for DSA and ARINC 429 development
>> work.
>>
>> Signed-off-by: Cory Tusar <cory.tusar at pid1solutions.com>
>> Signed-off-by: Andrew Lunn <andrew at lunn.ch>

[snip]

>> +&L2 {
>> +	arm,data-latency = <2 1 2>;
>> +	arm,tag-latency = <3 2 3>;
>> +};
> 
> Are you sure about that?
> 
> With 9c17190595 ("ARM: dts: vf610: use reset values for L2 cache
> latencies") we have reasonable values in the base device tree
> vf610.dtsi, I think therefor this is not necessary anymore, even if you
> use 500MHz as CPU clock.

Hi Stefan,

We'd had some pretty serious instability on our platform with the older
values (prior to the commit mentioned above).  I recall seeing that
change go in, and reviewed the discussion on Freescale's support forum,
but left things as they were pending official comment from Freescale.

"If it isn't broken...."

We can certainly try the new defaults and see if it crops up again.

FWIW, yes, we're running at 500 MHz.

Best regards,
- -Cory


- -- 
Cory Tusar
Principal
PID 1 Solutions, Inc.


"There are two ways of constructing a software design.  One way is to
 make it so simple that there are obviously no deficiencies, and the
 other way is to make it so complicated that there are no obvious
 deficiencies."  --Sir Charles Anthony Richard Hoare

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlbPKssACgkQHT1tsfGwHJ8acwCbB0/2AZrfGzRlIrr01igdDbGH
Q7QAoKtZcm0eyQNQxO3IlZUA6dSY+GEf
=sdAe
-----END PGP SIGNATURE-----


From will.deacon at arm.com  Thu Feb 25 08:26:23 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Feb 2016 16:26:23 +0000
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <CAKv+Gu94LAAwj2f9Sj9imn68V0VTF+NOtUPsE3tQnVzNDhAATw@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160225160714.GA16546@arm.com>
 <CAKv+Gu94LAAwj2f9Sj9imn68V0VTF+NOtUPsE3tQnVzNDhAATw@mail.gmail.com>
Message-ID: <20160225162622.GC16546@arm.com>

On Thu, Feb 25, 2016 at 05:12:01PM +0100, Ard Biesheuvel wrote:
> On 25 February 2016 at 17:07, Will Deacon <will.deacon at arm.com> wrote:
> > On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
> >> +struct plt_entry {
> >> +     /*
> >> +      * A program that conforms to the AArch64 Procedure Call Standard
> >> +      * (AAPCS64) must assume that a veneer that alters IP0 (x16) and/or
> >> +      * IP1 (x17) may be inserted at any branch instruction that is
> >> +      * exposed to a relocation that supports long branches. Since that
> >> +      * is exactly what we are dealing with here, we are free to use x16
> >> +      * as a scratch register in the PLT veneers.
> >> +      */
> >> +     __le32  mov0;   /* movn x16, #0x....                    */
> >> +     __le32  mov1;   /* movk x16, #0x...., lsl #16           */
> >> +     __le32  mov2;   /* movk x16, #0x...., lsl #32           */
> >> +     __le32  br;     /* br   x16                             */
> >> +};
> >
> > I'm worried about this code when CONFIG_ARM64_LSE_ATOMICS=y, but we don't
> > detect them on the CPU at runtime. In this case, all atomic operations
> > are moved out-of-line and called using a bl instruction from inline asm.
> >
> > The out-of-line code is compiled with magic GCC options
> 
> Which options are those exactly?

# Tell the compiler to treat all general purpose registers as
# callee-saved, which allows for efficient runtime patching of the bl
# instruction in the caller with an atomic instruction when supported by
# the CPU. Result and argument registers are handled correctly, based on
# the function prototype.
lib-$(CONFIG_ARM64_LSE_ATOMICS) += atomic_ll_sc.o
CFLAGS_atomic_ll_sc.o	:= -fcall-used-x0 -ffixed-x1 -ffixed-x2		\
		   -ffixed-x3 -ffixed-x4 -ffixed-x5 -ffixed-x6		\
		   -ffixed-x7 -fcall-saved-x8 -fcall-saved-x9		\
		   -fcall-saved-x10 -fcall-saved-x11 -fcall-saved-x12	\
		   -fcall-saved-x13 -fcall-saved-x14 -fcall-saved-x15	\
		   -fcall-saved-x16 -fcall-saved-x17 -fcall-saved-x18

> > to force the
> > explicit save/restore of all used registers (see arch/arm64/lib/Makefile),
> > otherwise we'd have to clutter the inline asm with constraints that
> > wouldn't be needed had we managed to patch the bl with an LSE atomic
> > instruction.
> >
> > If you're emitting a PLT, couldn't we end up with silent corruption of
> > x16 for modules using out-of-line atomics like this?
> >
> 
> If you violate the AAPCS64 ABI, then obviously the claim above does not hold.

Indeed, but this is what mainline is doing today and I'm not keen on
breaking it. One way to fix it would be to generate a different type of
plt for branches to the atomic functions that would use the stack
instead of x16.

Will


From arnd at arndb.de  Thu Feb 25 08:27:48 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 17:27:48 +0100
Subject: [PATCH] ARM: prima2: always enable reset controller
Message-ID: <1456417673-2115511-1-git-send-email-arnd@arndb.de>

The atlas7 clock controller driver registers a reset controller
for itself, which causes a link error when the subsystem is
disabled:

drivers/built-in.o: In function `atlas7_clk_init':
drivers/clk/sirf/clk-atlas7.c:1681: undefined reference to `reset_controller_register'

As the clk driver does not have a Kconfig symbol for itself
but it always built-in when the platform is enabled, we have
to ensure that the reset controller subsystem is also built-in
in this case.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 301c5d29402e ("clk: sirf: add CSR atlas7 clk and reset support")
---
 arch/arm/mach-prima2/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-prima2/Kconfig b/arch/arm/mach-prima2/Kconfig
index 59cafaf097c0..86b7c859784f 100644
--- a/arch/arm/mach-prima2/Kconfig
+++ b/arch/arm/mach-prima2/Kconfig
@@ -2,6 +2,7 @@ menuconfig ARCH_SIRF
 	bool "CSR SiRF"
 	depends on ARCH_MULTI_V6_V7
 	select ARCH_HAS_RESET_CONTROLLER
+	select RESET_CONTROLLER
 	select ARCH_REQUIRE_GPIOLIB
 	select GENERIC_IRQ_CHIP
 	select NO_IOPORT_MAP
-- 
2.7.0



From arnd at arndb.de  Thu Feb 25 08:31:32 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 17:31:32 +0100
Subject: [PATCH] modsign: hide openssl output in silent builds
Message-ID: <1456417901-2192433-1-git-send-email-arnd@arndb.de>

When a user calls 'make -s', we can assume they don't want to
see any output except for warnings and errors, but instead
they see this for a warning free build:

 ###
 ### Now generating an X.509 key pair to be used for signing modules.
 ###
 ### If this takes a long time, you might wish to run rngd in the
 ### background to keep the supply of entropy topped up.  It
 ### needs to be run as root, and uses a hardware random
 ### number generator if one is available.
 ###
 Generating a 4096 bit RSA private key
 .................................................................................................................................................................................................................................++
 ..............................................................................................................................++
 writing new private key to 'certs/signing_key.pem'
 -----
 ###
 ### Key pair generated.
 ###

The output can confuse simple build testing scripts that just check
for an empty build log.

This patch silences all the output:
 - "echo" is changed to "@$(kecho)", which is dropped when "-s" gets
   passed
 - the openssl command itself is only printed with V=1, using the
   $(Q) macro
 - The output of openssl gets redircted to /dev/null on "-s" builds.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 certs/Makefile | 33 +++++++++++++++++++--------------
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/certs/Makefile b/certs/Makefile
index 28ac694dd11a..2773c4afa24c 100644
--- a/certs/Makefile
+++ b/certs/Makefile
@@ -36,29 +36,34 @@ ifndef CONFIG_MODULE_SIG_HASH
 $(error Could not determine digest type to use from kernel config)
 endif
 
+redirect_openssl	= 2>&1
+quiet_redirect_openssl	= 2>&1
+silent_redirect_openssl = 2>/dev/null
+
 # We do it this way rather than having a boolean option for enabling an
 # external private key, because 'make randconfig' might enable such a
 # boolean option and we unfortunately can't make it depend on !RANDCONFIG.
 ifeq ($(CONFIG_MODULE_SIG_KEY),"certs/signing_key.pem")
 $(obj)/signing_key.pem: $(obj)/x509.genkey
-	@echo "###"
-	@echo "### Now generating an X.509 key pair to be used for signing modules."
-	@echo "###"
-	@echo "### If this takes a long time, you might wish to run rngd in the"
-	@echo "### background to keep the supply of entropy topped up.  It"
-	@echo "### needs to be run as root, and uses a hardware random"
-	@echo "### number generator if one is available."
-	@echo "###"
-	openssl req -new -nodes -utf8 -$(CONFIG_MODULE_SIG_HASH) -days 36500 \
+	@$(kecho) "###"
+	@$(kecho) "### Now generating an X.509 key pair to be used for signing modules."
+	@$(kecho) "###"
+	@$(kecho) "### If this takes a long time, you might wish to run rngd in the"
+	@$(kecho) "### background to keep the supply of entropy topped up.  It"
+	@$(kecho) "### needs to be run as root, and uses a hardware random"
+	@$(kecho) "### number generator if one is available."
+	@$(kecho) "###"
+	$(Q)openssl req -new -nodes -utf8 -$(CONFIG_MODULE_SIG_HASH) -days 36500 \
 		-batch -x509 -config $(obj)/x509.genkey \
 		-outform PEM -out $(obj)/signing_key.pem \
-		-keyout $(obj)/signing_key.pem 2>&1
-	@echo "###"
-	@echo "### Key pair generated."
-	@echo "###"
+		-keyout $(obj)/signing_key.pem \
+		$($(quiet)redirect_openssl)
+	@$(kecho) "###"
+	@$(kecho) "### Key pair generated."
+	@$(kecho) "###"
 
 $(obj)/x509.genkey:
-	@echo Generating X.509 key generation config
+	@$(kecho) Generating X.509 key generation config
 	@echo  >$@ "[ req ]"
 	@echo >>$@ "default_bits = 4096"
 	@echo >>$@ "distinguished_name = req_distinguished_name"
-- 
2.7.0



From mathieu.poirier at linaro.org  Thu Feb 25 08:32:17 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 25 Feb 2016 09:32:17 -0700
Subject: [PATCH] drivers: perf: arm: implement CPU_PM notifier
In-Reply-To: <20160225094417.GB31728@red-moon>
References: <1456251759-24768-1-git-send-email-lorenzo.pieralisi@arm.com>
 <7hsi0hr3wj.fsf@baylibre.com> <20160225094417.GB31728@red-moon>
Message-ID: <CANLsYkzq_oFLZ-ijBtxHp2rU=NR5R1PLb0znv2zPTv=4Z2isGA@mail.gmail.com>

On 25 February 2016 at 02:44, Lorenzo Pieralisi
<lorenzo.pieralisi at arm.com> wrote:
> On Wed, Feb 24, 2016 at 05:10:20PM -0800, Kevin Hilman wrote:
>> Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> writes:
>>
>> > When a CPU is suspended (either through suspend-to-RAM or CPUidle),
>> > its PMU registers content can be lost, which means that counters
>> > registers values that were initialized on power down entry have to be
>> > reprogrammed on power-up to make sure the counters set-up is preserved
>>
>> This assumes that the PMUs are always sharing a power rail with a
>> specific CPU, not the cluster.  Is that a reliable assumption?
>
> As reliable as assuming the GIC HW state needs save/restore on idle-state
> entry, if we have no power domains information linked to CPU PM
> notifiers saving/restoring everything every time an idle state deeper
> than wfi is entered is the best we can do.
>
> As far as this patch is concerned, if the PMU is on a different power
> domain than the CPU, I agree that stopping/resetting/restoring the
> PMU registers is a waste of cycles (I will test it also by triggering
> the notifiers on wfi, to make sure the reset is not disruptive on
> a cpu that is not powered off), I see no alternative other than disabling
> idle to carry out profiling sanely (or implement CPU PM notifiers with
> runtime PM).

I totally understand - I'm faced with the same problem on Coresight.
To me the ultimate solution is still to integrate CPU power domain
management with runtime PM (like we talked about many times before).
I know Lina is working on something that will get us close to that but
it's not finished yet.

>
> Thanks,
> Lorenzo


From ard.biesheuvel at linaro.org  Thu Feb 25 08:33:25 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 25 Feb 2016 17:33:25 +0100
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <20160225162622.GC16546@arm.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160225160714.GA16546@arm.com>
 <CAKv+Gu94LAAwj2f9Sj9imn68V0VTF+NOtUPsE3tQnVzNDhAATw@mail.gmail.com>
 <20160225162622.GC16546@arm.com>
Message-ID: <CAKv+Gu8Qx21M=ymne1S4CQUFrXKHTnWFygGBLtXbxiUD9GkiWw@mail.gmail.com>

On 25 February 2016 at 17:26, Will Deacon <will.deacon at arm.com> wrote:
> On Thu, Feb 25, 2016 at 05:12:01PM +0100, Ard Biesheuvel wrote:
>> On 25 February 2016 at 17:07, Will Deacon <will.deacon at arm.com> wrote:
>> > On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
>> >> +struct plt_entry {
>> >> +     /*
>> >> +      * A program that conforms to the AArch64 Procedure Call Standard
>> >> +      * (AAPCS64) must assume that a veneer that alters IP0 (x16) and/or
>> >> +      * IP1 (x17) may be inserted at any branch instruction that is
>> >> +      * exposed to a relocation that supports long branches. Since that
>> >> +      * is exactly what we are dealing with here, we are free to use x16
>> >> +      * as a scratch register in the PLT veneers.
>> >> +      */
>> >> +     __le32  mov0;   /* movn x16, #0x....                    */
>> >> +     __le32  mov1;   /* movk x16, #0x...., lsl #16           */
>> >> +     __le32  mov2;   /* movk x16, #0x...., lsl #32           */
>> >> +     __le32  br;     /* br   x16                             */
>> >> +};
>> >
>> > I'm worried about this code when CONFIG_ARM64_LSE_ATOMICS=y, but we don't
>> > detect them on the CPU at runtime. In this case, all atomic operations
>> > are moved out-of-line and called using a bl instruction from inline asm.
>> >
>> > The out-of-line code is compiled with magic GCC options
>>
>> Which options are those exactly?
>
> # Tell the compiler to treat all general purpose registers as
> # callee-saved, which allows for efficient runtime patching of the bl
> # instruction in the caller with an atomic instruction when supported by
> # the CPU. Result and argument registers are handled correctly, based on
> # the function prototype.
> lib-$(CONFIG_ARM64_LSE_ATOMICS) += atomic_ll_sc.o
> CFLAGS_atomic_ll_sc.o   := -fcall-used-x0 -ffixed-x1 -ffixed-x2         \
>                    -ffixed-x3 -ffixed-x4 -ffixed-x5 -ffixed-x6          \
>                    -ffixed-x7 -fcall-saved-x8 -fcall-saved-x9           \
>                    -fcall-saved-x10 -fcall-saved-x11 -fcall-saved-x12   \
>                    -fcall-saved-x13 -fcall-saved-x14 -fcall-saved-x15   \
>                    -fcall-saved-x16 -fcall-saved-x17 -fcall-saved-x18
>

Yikes. Is that safe?

>> > to force the
>> > explicit save/restore of all used registers (see arch/arm64/lib/Makefile),
>> > otherwise we'd have to clutter the inline asm with constraints that
>> > wouldn't be needed had we managed to patch the bl with an LSE atomic
>> > instruction.
>> >
>> > If you're emitting a PLT, couldn't we end up with silent corruption of
>> > x16 for modules using out-of-line atomics like this?
>> >
>>
>> If you violate the AAPCS64 ABI, then obviously the claim above does not hold.
>
> Indeed, but this is what mainline is doing today and I'm not keen on
> breaking it. One way to fix it would be to generate a different type of
> plt for branches to the atomic functions that would use the stack
> instead of x16.
>

AFAIK, gcc never uses x18 (the platform register) so we may be able to
use that instead. We'd need confirmation from the toolchain guys,
though ...


From mathieu.poirier at linaro.org  Thu Feb 25 08:37:16 2016
From: mathieu.poirier at linaro.org (Mathieu Poirier)
Date: Thu, 25 Feb 2016 09:37:16 -0700
Subject: [PATCH] drivers: perf: arm: implement CPU_PM notifier
In-Reply-To: <20160224173511.GF25385@red-moon>
References: <1456251759-24768-1-git-send-email-lorenzo.pieralisi@arm.com>
 <CANLsYkzvB0GbPeYHrcLtUz8DMHJh4FA5RVwVZ-UAm3BCznB_3w@mail.gmail.com>
 <20160224173511.GF25385@red-moon>
Message-ID: <CANLsYkwYjPeQ=syGk7ofb_yWtzDYoNK6Yf8MLPxhMkN31+xE3g@mail.gmail.com>

On 24 February 2016 at 10:35, Lorenzo Pieralisi
<lorenzo.pieralisi at arm.com> wrote:
> On Wed, Feb 24, 2016 at 09:20:22AM -0700, Mathieu Poirier wrote:
>> On 23 February 2016 at 11:22, Lorenzo Pieralisi
>
> [...]
>
>> > +static int cpu_pm_pmu_notify(struct notifier_block *b, unsigned long cmd,
>> > +                            void *v)
>> > +{
>> > +       struct arm_pmu *armpmu = container_of(b, struct arm_pmu, cpu_pm_nb);
>> > +       struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
>> > +       int enabled = bitmap_weight(hw_events->used_mask, armpmu->num_events);
>> > +
>> > +       if (!cpumask_test_cpu(smp_processor_id(), &armpmu->supported_cpus))
>> > +               return NOTIFY_DONE;
>> > +
>> > +       /*
>> > +        * Always reset the PMU registers on power-up even if
>> > +        * there are no events running.
>> > +        */
>> > +       if (cmd == CPU_PM_EXIT && armpmu->reset)
>> > +               armpmu->reset(armpmu);
>>
>> I think this patch does the right thing but I can't get the above
>> reset.  Wouldn't it be better to do the reset as part of the
>> CPU_PM_EXIT case below?  At this point nothing tells us the CPU won't
>> go back down before the event is enabled, wasting the cycle needed to
>> reset the PMU.
>
> The logic goes, if the cpu is woken up and it has no events enabled,
> if we do not reset it (mind, ->reset here sets the PMU register values
> to a sane default, some of them are architecturally UNKNOWN on reset, it
> does NOT reset the PMU) _and_ we subsequently install an event on it we
> do have a problem, that's why whenever a core gets out of low-power we
> have to reset its pmu.
>
> Does it make sense ?

Ok, I understand the context and your solution will work.

Isn't there a flag somewhere in the PMU registers that indicate the
status has been lost due a loss of power?  If so I think the best
solution is to probe that flag when an event gets installed.  If the
unit has gone through a power down the reset can be done before
installing the event.

Mathieu

>
> Thanks,
> Lorenzo
>
>>
>> Thanks,
>> Mathieu
>>
>> > +
>> > +       if (!enabled)
>> > +               return NOTIFY_OK;
>> > +
>> > +       switch (cmd) {
>> > +       case CPU_PM_ENTER:
>> > +               armpmu->stop(armpmu);
>> > +               cpu_pm_pmu_setup(armpmu, cmd);
>> > +               break;
>> > +       case CPU_PM_EXIT:
>> > +               cpu_pm_pmu_setup(armpmu, cmd);
>> > +       case CPU_PM_ENTER_FAILED:
>> > +               armpmu->start(armpmu);
>> > +               break;
>> > +       default:
>> > +               return NOTIFY_DONE;
>> > +       }
>> > +
>> > +       return NOTIFY_OK;
>> > +}
>> > +
>> > +static int cpu_pm_pmu_register(struct arm_pmu *cpu_pmu)
>> > +{
>> > +       cpu_pmu->cpu_pm_nb.notifier_call = cpu_pm_pmu_notify;
>> > +       return cpu_pm_register_notifier(&cpu_pmu->cpu_pm_nb);
>> > +}
>> > +
>> > +static void cpu_pm_pmu_unregister(struct arm_pmu *cpu_pmu)
>> > +{
>> > +       cpu_pm_unregister_notifier(&cpu_pmu->cpu_pm_nb);
>> > +}
>> > +#else
>> > +static inline int cpu_pm_pmu_register(struct arm_pmu *cpu_pmu) { return 0; }
>> > +static inline void cpu_pm_pmu_unregister(struct arm_pmu *cpu_pmu) { }
>> > +#endif
>> > +
>> >  static int cpu_pmu_init(struct arm_pmu *cpu_pmu)
>> >  {
>> >         int err;
>> > @@ -725,6 +813,10 @@ static int cpu_pmu_init(struct arm_pmu *cpu_pmu)
>> >         if (err)
>> >                 goto out_hw_events;
>> >
>> > +       err = cpu_pm_pmu_register(cpu_pmu);
>> > +       if (err)
>> > +               goto out_unregister;
>> > +
>> >         for_each_possible_cpu(cpu) {
>> >                 struct pmu_hw_events *events = per_cpu_ptr(cpu_hw_events, cpu);
>> >                 raw_spin_lock_init(&events->pmu_lock);
>> > @@ -746,6 +838,8 @@ static int cpu_pmu_init(struct arm_pmu *cpu_pmu)
>> >
>> >         return 0;
>> >
>> > +out_unregister:
>> > +       unregister_cpu_notifier(&cpu_pmu->hotplug_nb);
>> >  out_hw_events:
>> >         free_percpu(cpu_hw_events);
>> >         return err;
>> > @@ -753,6 +847,7 @@ out_hw_events:
>> >
>> >  static void cpu_pmu_destroy(struct arm_pmu *cpu_pmu)
>> >  {
>> > +       cpu_pm_pmu_unregister(cpu_pmu);
>> >         unregister_cpu_notifier(&cpu_pmu->hotplug_nb);
>> >         free_percpu(cpu_pmu->hw_events);
>> >  }
>> > diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
>> > index 83b5e34..9ffa316 100644
>> > --- a/include/linux/perf/arm_pmu.h
>> > +++ b/include/linux/perf/arm_pmu.h
>> > @@ -107,6 +107,7 @@ struct arm_pmu {
>> >         struct platform_device  *plat_device;
>> >         struct pmu_hw_events    __percpu *hw_events;
>> >         struct notifier_block   hotplug_nb;
>> > +       struct notifier_block   cpu_pm_nb;
>> >  };
>> >
>> >  #define to_arm_pmu(p) (container_of(p, struct arm_pmu, pmu))
>> > --
>> > 2.5.1
>> >
>>


From thomas.petazzoni at free-electrons.com  Thu Feb 25 08:38:11 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Thu, 25 Feb 2016 17:38:11 +0100
Subject: [PATCH 1/3] dt-bindings: arm/marvell: ABI unstability warning
 about Marvell 7K/8K
In-Reply-To: <20160225161642.GC10593@leverpostej>
References: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1456327007-31008-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160224172545.GC9137@leverpostej>
 <20160224211045.379352d3@free-electrons.com>
 <CAL_JsqLevrujSeYNBvSJA-5T0Ho8y7c0fKid7QvVm8LLvYLotw@mail.gmail.com>
 <20160225090927.13492cfb@free-electrons.com>
 <20160225161642.GC10593@leverpostej>
Message-ID: <20160225173811.23be5b05@free-electrons.com>

Hello Mark,

On Thu, 25 Feb 2016 16:16:47 +0000, Mark Rutland wrote:

> > Either because the internal processes are complicated, or simply
> > because the Linux kernel support is done without cooperation from the
> > HW vendor (it's not the case of this Marvell platform, but it's the
> > case of many other platforms).
> 
> Yes, this is a problem in some cases, and that should be considered in
> those cases. There are always shades of grey.

Sure.

> Per the above, that isn't relevant in this case. This is a pretty
> black-and-white stand against the usual rules.

I don't see why. The datasheets have not been completely written yet
for this particular chip. For other chips we've worked on where we
collaborated with the SoC vendor, we never had any datasheet, simply
because the SoC vendor doesn't have any. They have the digital logic
source code, and then tons of spreadsheets or text documents that are
not proper datasheets and that they generally cannot share with
third-parties.

Hence, even when the support for a SoC is being done in collaboration
with the SoC vendor, we don't always have a nice full datasheet that
tells us what all the registers are doing and how they are organized.
We discover things as we go.

Yes, this might be surprising to you, working at ARM, where the
technical documentation is awesome and very detailed. But trust me,
this is *NOT* what you get from many SoC vendors.

> > Submitting without merging is useless. The point of submitting is to
> > get the code merged, to reduce the amount of out-of-tree patches we
> > have to carry, and to allow users of the platform to simply run
> > mainline on their platform.
> 
> Submitting prototypes and RFCs is the usual way we get things reviewed
> early, and to allow maintainers and others to get a feel for things
> earlier. Submitting patches _for merging_ when you're not sure about
> things and don't want to agree to support them is what's being pushed
> back on.

This simply doesn't work. This initial support of a few patches (clock,
basic DT, irqchip, dmaengine) is going to be followed very soon by lots
of other patches to enable more aspects of the SoC. And we should keep
all of those patches out-of-tree, piling up hundreds of out-of-tree
patches ? Not practical at all.

And then when we'll submit them, they will all be accepted in one go,
in one kernel cycle ? Clearly not, so we would have to wait several
kernel cycles, which is clearly not what we want.

Instead, what we want is to submit the basic stuff early, and then
progressively build on top of this basic stuff by merging more and more
features. This way:

 * We don't have to pile up hundreds of out of tree patches;

 * We have a support in the mainline kernel that is progressively
   getting better as we enable more and more feature. We can show that
   4.6 has this small set of features, 4.7 has this slightly extended
   set of features supported, and so on.

So no, we clearly do not want to keep things out of tree.

> > So this proposal really doesn't make any sense. Just like Mark initial
> > statement of not submitting code so early.
> 
> As what I said was evidently ambiguous, I'm on about code being _merged_
> prior to being ready. Code and bindings should certainly be posted for
> review as soon as possible. However, it should be recognised when things
> aren't quite ready for mainline.
> 
> Even if something's unclear about a device, you can highlight more
> general issues (e.g. problematic edge cases in common subsystem code),
> and that's possible to have merged even if the binding isn't ready.
> 
> If you're unsure about something, but still want it merged, then you
> have to commit to maintaining that as far as reasonably possible, even
> if it turns out to not be quite right.

We are perfectly fine with maintaining *code*. And we have been doing
so for several years on Marvell platforms: caring about older
platforms, converting old legacy code and legacy platforms to the
Device Tree, etc.

What we don't want to commit to is to maintain the DT stability
*before* the support for a given device is sufficiently stable/sane.

> > Do you realize that this all DT binding stuff is today the *biggest* to
> > getting HW support in the Linux kernel? It has become more complicated
> > to merge a 4 properties DT binding than to merge multiple thousands of
> > lines of driver code. 
> 
> As times have changed, pain points have moved around.
> 
> To some extent that is unavoidable; more up-front effort is required
> where crutches we previously relied on are not applicable.
> 
> Elsewhere we can certainly do better.
> 
> Throwing your hands up and stating "this is unstable, it might change"
> is a crutch. It prevents any real solution to the pain points you
> encounter, and creates pain points for others. It only provides the
> _illusion_ of support.

Could you please explicit which pain points it creates for others ?

Having unstable DT bindings specific to a platform does not create any
single pain point for anyone.

Why are you talking about "illusion" of support ? Sorry, but with
unstable DT bindings, as long as you use the DT that comes with the
kernel sources, everything works perfectly fine, and is perfectly
supported.

Even Fedora is installing DTBs in a directory that is kernel-version
specific!

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From will.deacon at arm.com  Thu Feb 25 08:42:08 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Feb 2016 16:42:08 +0000
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <CAKv+Gu8Qx21M=ymne1S4CQUFrXKHTnWFygGBLtXbxiUD9GkiWw@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160225160714.GA16546@arm.com>
 <CAKv+Gu94LAAwj2f9Sj9imn68V0VTF+NOtUPsE3tQnVzNDhAATw@mail.gmail.com>
 <20160225162622.GC16546@arm.com>
 <CAKv+Gu8Qx21M=ymne1S4CQUFrXKHTnWFygGBLtXbxiUD9GkiWw@mail.gmail.com>
Message-ID: <20160225164208.GD16546@arm.com>

On Thu, Feb 25, 2016 at 05:33:25PM +0100, Ard Biesheuvel wrote:
> On 25 February 2016 at 17:26, Will Deacon <will.deacon at arm.com> wrote:
> > On Thu, Feb 25, 2016 at 05:12:01PM +0100, Ard Biesheuvel wrote:
> >> On 25 February 2016 at 17:07, Will Deacon <will.deacon at arm.com> wrote:
> >> > On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
> >> >> +struct plt_entry {
> >> >> +     /*
> >> >> +      * A program that conforms to the AArch64 Procedure Call Standard
> >> >> +      * (AAPCS64) must assume that a veneer that alters IP0 (x16) and/or
> >> >> +      * IP1 (x17) may be inserted at any branch instruction that is
> >> >> +      * exposed to a relocation that supports long branches. Since that
> >> >> +      * is exactly what we are dealing with here, we are free to use x16
> >> >> +      * as a scratch register in the PLT veneers.
> >> >> +      */
> >> >> +     __le32  mov0;   /* movn x16, #0x....                    */
> >> >> +     __le32  mov1;   /* movk x16, #0x...., lsl #16           */
> >> >> +     __le32  mov2;   /* movk x16, #0x...., lsl #32           */
> >> >> +     __le32  br;     /* br   x16                             */
> >> >> +};
> >> >
> >> > I'm worried about this code when CONFIG_ARM64_LSE_ATOMICS=y, but we don't
> >> > detect them on the CPU at runtime. In this case, all atomic operations
> >> > are moved out-of-line and called using a bl instruction from inline asm.
> >> >
> >> > The out-of-line code is compiled with magic GCC options
> >>
> >> Which options are those exactly?
> >
> > # Tell the compiler to treat all general purpose registers as
> > # callee-saved, which allows for efficient runtime patching of the bl
> > # instruction in the caller with an atomic instruction when supported by
> > # the CPU. Result and argument registers are handled correctly, based on
> > # the function prototype.
> > lib-$(CONFIG_ARM64_LSE_ATOMICS) += atomic_ll_sc.o
> > CFLAGS_atomic_ll_sc.o   := -fcall-used-x0 -ffixed-x1 -ffixed-x2         \
> >                    -ffixed-x3 -ffixed-x4 -ffixed-x5 -ffixed-x6          \
> >                    -ffixed-x7 -fcall-saved-x8 -fcall-saved-x9           \
> >                    -fcall-saved-x10 -fcall-saved-x11 -fcall-saved-x12   \
> >                    -fcall-saved-x13 -fcall-saved-x14 -fcall-saved-x15   \
> >                    -fcall-saved-x16 -fcall-saved-x17 -fcall-saved-x18
> >
> 
> Yikes. Is that safe?

It seems to work, and x86 uses a similar trick for it's hweight code.

> >> > to force the
> >> > explicit save/restore of all used registers (see arch/arm64/lib/Makefile),
> >> > otherwise we'd have to clutter the inline asm with constraints that
> >> > wouldn't be needed had we managed to patch the bl with an LSE atomic
> >> > instruction.
> >> >
> >> > If you're emitting a PLT, couldn't we end up with silent corruption of
> >> > x16 for modules using out-of-line atomics like this?
> >> >
> >>
> >> If you violate the AAPCS64 ABI, then obviously the claim above does not hold.
> >
> > Indeed, but this is what mainline is doing today and I'm not keen on
> > breaking it. One way to fix it would be to generate a different type of
> > plt for branches to the atomic functions that would use the stack
> > instead of x16.
> >
> 
> AFAIK, gcc never uses x18 (the platform register) so we may be able to
> use that instead. We'd need confirmation from the toolchain guys,
> though ...

In fact, a better thing to do is probably for the atomic code to
save/restore those register explicitly and then remove them from the
cflags above.

I'll try hacking something together...

Will


From ard.biesheuvel at linaro.org  Thu Feb 25 08:43:35 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 25 Feb 2016 17:43:35 +0100
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <20160225164208.GD16546@arm.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160225160714.GA16546@arm.com>
 <CAKv+Gu94LAAwj2f9Sj9imn68V0VTF+NOtUPsE3tQnVzNDhAATw@mail.gmail.com>
 <20160225162622.GC16546@arm.com>
 <CAKv+Gu8Qx21M=ymne1S4CQUFrXKHTnWFygGBLtXbxiUD9GkiWw@mail.gmail.com>
 <20160225164208.GD16546@arm.com>
Message-ID: <CAKv+Gu-REUdVJF-_wGU=LRaVRZqsD9bgny9S52pMLp+Es4E-1A@mail.gmail.com>

On 25 February 2016 at 17:42, Will Deacon <will.deacon at arm.com> wrote:
> On Thu, Feb 25, 2016 at 05:33:25PM +0100, Ard Biesheuvel wrote:
>> On 25 February 2016 at 17:26, Will Deacon <will.deacon at arm.com> wrote:
>> > On Thu, Feb 25, 2016 at 05:12:01PM +0100, Ard Biesheuvel wrote:
>> >> On 25 February 2016 at 17:07, Will Deacon <will.deacon at arm.com> wrote:
>> >> > On Mon, Feb 01, 2016 at 02:09:31PM +0100, Ard Biesheuvel wrote:
>> >> >> +struct plt_entry {
>> >> >> +     /*
>> >> >> +      * A program that conforms to the AArch64 Procedure Call Standard
>> >> >> +      * (AAPCS64) must assume that a veneer that alters IP0 (x16) and/or
>> >> >> +      * IP1 (x17) may be inserted at any branch instruction that is
>> >> >> +      * exposed to a relocation that supports long branches. Since that
>> >> >> +      * is exactly what we are dealing with here, we are free to use x16
>> >> >> +      * as a scratch register in the PLT veneers.
>> >> >> +      */
>> >> >> +     __le32  mov0;   /* movn x16, #0x....                    */
>> >> >> +     __le32  mov1;   /* movk x16, #0x...., lsl #16           */
>> >> >> +     __le32  mov2;   /* movk x16, #0x...., lsl #32           */
>> >> >> +     __le32  br;     /* br   x16                             */
>> >> >> +};
>> >> >
>> >> > I'm worried about this code when CONFIG_ARM64_LSE_ATOMICS=y, but we don't
>> >> > detect them on the CPU at runtime. In this case, all atomic operations
>> >> > are moved out-of-line and called using a bl instruction from inline asm.
>> >> >
>> >> > The out-of-line code is compiled with magic GCC options
>> >>
>> >> Which options are those exactly?
>> >
>> > # Tell the compiler to treat all general purpose registers as
>> > # callee-saved, which allows for efficient runtime patching of the bl
>> > # instruction in the caller with an atomic instruction when supported by
>> > # the CPU. Result and argument registers are handled correctly, based on
>> > # the function prototype.
>> > lib-$(CONFIG_ARM64_LSE_ATOMICS) += atomic_ll_sc.o
>> > CFLAGS_atomic_ll_sc.o   := -fcall-used-x0 -ffixed-x1 -ffixed-x2         \
>> >                    -ffixed-x3 -ffixed-x4 -ffixed-x5 -ffixed-x6          \
>> >                    -ffixed-x7 -fcall-saved-x8 -fcall-saved-x9           \
>> >                    -fcall-saved-x10 -fcall-saved-x11 -fcall-saved-x12   \
>> >                    -fcall-saved-x13 -fcall-saved-x14 -fcall-saved-x15   \
>> >                    -fcall-saved-x16 -fcall-saved-x17 -fcall-saved-x18
>> >
>>
>> Yikes. Is that safe?
>
> It seems to work, and x86 uses a similar trick for it's hweight code.
>
>> >> > to force the
>> >> > explicit save/restore of all used registers (see arch/arm64/lib/Makefile),
>> >> > otherwise we'd have to clutter the inline asm with constraints that
>> >> > wouldn't be needed had we managed to patch the bl with an LSE atomic
>> >> > instruction.
>> >> >
>> >> > If you're emitting a PLT, couldn't we end up with silent corruption of
>> >> > x16 for modules using out-of-line atomics like this?
>> >> >
>> >>
>> >> If you violate the AAPCS64 ABI, then obviously the claim above does not hold.
>> >
>> > Indeed, but this is what mainline is doing today and I'm not keen on
>> > breaking it. One way to fix it would be to generate a different type of
>> > plt for branches to the atomic functions that would use the stack
>> > instead of x16.
>> >
>>
>> AFAIK, gcc never uses x18 (the platform register) so we may be able to
>> use that instead. We'd need confirmation from the toolchain guys,
>> though ...
>
> In fact, a better thing to do is probably for the atomic code to
> save/restore those register explicitly and then remove them from the
> cflags above.
>
> I'll try hacking something together...
>

That would be more correct, indeed. Also, the PLT can only use br
<reg> so it will always enter the callee with the preserved value
stacked, and so the callee needs to be modified in any case.


From will.deacon at arm.com  Thu Feb 25 08:43:54 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Feb 2016 16:43:54 +0000
Subject: [PATCH] drivers: perf: arm: implement CPU_PM notifier
In-Reply-To: <CANLsYkzq_oFLZ-ijBtxHp2rU=NR5R1PLb0znv2zPTv=4Z2isGA@mail.gmail.com>
References: <1456251759-24768-1-git-send-email-lorenzo.pieralisi@arm.com>
 <7hsi0hr3wj.fsf@baylibre.com> <20160225094417.GB31728@red-moon>
 <CANLsYkzq_oFLZ-ijBtxHp2rU=NR5R1PLb0znv2zPTv=4Z2isGA@mail.gmail.com>
Message-ID: <20160225164354.GE16546@arm.com>

On Thu, Feb 25, 2016 at 09:32:17AM -0700, Mathieu Poirier wrote:
> On 25 February 2016 at 02:44, Lorenzo Pieralisi
> <lorenzo.pieralisi at arm.com> wrote:
> > On Wed, Feb 24, 2016 at 05:10:20PM -0800, Kevin Hilman wrote:
> >> Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> writes:
> >>
> >> > When a CPU is suspended (either through suspend-to-RAM or CPUidle),
> >> > its PMU registers content can be lost, which means that counters
> >> > registers values that were initialized on power down entry have to be
> >> > reprogrammed on power-up to make sure the counters set-up is preserved
> >>
> >> This assumes that the PMUs are always sharing a power rail with a
> >> specific CPU, not the cluster.  Is that a reliable assumption?
> >
> > As reliable as assuming the GIC HW state needs save/restore on idle-state
> > entry, if we have no power domains information linked to CPU PM
> > notifiers saving/restoring everything every time an idle state deeper
> > than wfi is entered is the best we can do.
> >
> > As far as this patch is concerned, if the PMU is on a different power
> > domain than the CPU, I agree that stopping/resetting/restoring the
> > PMU registers is a waste of cycles (I will test it also by triggering
> > the notifiers on wfi, to make sure the reset is not disruptive on
> > a cpu that is not powered off), I see no alternative other than disabling
> > idle to carry out profiling sanely (or implement CPU PM notifiers with
> > runtime PM).
> 
> I totally understand - I'm faced with the same problem on Coresight.
> To me the ultimate solution is still to integrate CPU power domain
> management with runtime PM (like we talked about many times before).
> I know Lina is working on something that will get us close to that but
> it's not finished yet.

I've been waiting for that code for *years* now...

Ultimately, Juno-r2 loses its PMU state over idle if you run mainline
on it and, worse still, you end up getting junk numbers back to userspace,
so it's not even obvious what happened.

I'm not aware of any flags that indicate loss of state.

Will


From tomi.valkeinen at ti.com  Thu Feb 25 08:45:37 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Thu, 25 Feb 2016 18:45:37 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CACRpkdZd8TLdsi7_cOrqzcqWKJrfdp4Vz2sx5ozpwJXOj0fa+Q@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <3695074.sKSIyOjpjD@wuerfel>
 <CACRpkdZjfjOCFUucF1U5yVZBxSwa41GKEMv-HHQE=ymF2NZ21g@mail.gmail.com>
 <6859810.tb1t0IEONi@wuerfel> <56CC57FC.20707@ti.com>
 <CACRpkdYNaNtQQJ-tsBe5ksa4-z380ZQj-zN8ZnK0ED2kNPUwvg@mail.gmail.com>
 <56CC60C4.6040908@ti.com>
 <CACRpkdZd8TLdsi7_cOrqzcqWKJrfdp4Vz2sx5ozpwJXOj0fa+Q@mail.gmail.com>
Message-ID: <56CF2FB1.106@ti.com>


On 25/02/16 16:04, Linus Walleij wrote:
> On Tue, Feb 23, 2016 at 2:38 PM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> 
>> Maybe Versatile is different. If CLCD is only used on that board, or a
>> small family of boards, from one vendor, I guess it is maintainable to
>> have board specific driver parts for CLCD. But if CLCD can be used by
>> many vendors in many different boards, I'd steer clear of board specific
>> driver code.
> 
> OK I think at this point we would say that CLCD is a legacy driver.

Ok.

My biggest fear with this is the maintenance nightmare that comes if an
IP or panel is used in multiple SoCs and future designs. We have the
same display subsystem and panel drivers used from OMAP2 forward, and
it's been a constant struggle, so I've come to appreciate the effort to
split things up as much as possible, so that when the time comes when
the HW guys have decided to change a piece here or there, it's easier to
cope with.

Anyway, if it's likely that we're not seeing new CLCD boards, I think
it's fine if we don't go to any great lengths to clean things up there.
Let's just get it working.

> HOWEVER: the ARM Versatile is the *only* platform I have
> seen of these that have plug'n'play for the display.

Ok. And presumably no new boards will use that plug'n'play display, so
we can just consider it specific to versatile.

> *All* the others
> will be very happy with *ONE* display defined as panel in the
> device tree, and off they go. Usually VGA. And that will look

You keep mentioning VGA. So is there are VGA output? Or do you just mean
MIPI DPI panels, which happen to take the same video timings as VGA?

> I add support for doing this for the Integrator and RealView in
> the patch set, by grabbing a handle to the system controller
> where they have a few "misc registers". However if you look at
> it:
> 
> static void integrator_clcd_enable(struct clcd_fb *fb)
> {
>         struct fb_var_screeninfo *var = &fb->fb.var;
>         u32 val;
> 
>         dev_info(&fb->dev->dev, "enable Integrator CLCD connectors\n");
> 
>         val = INTEGRATOR_CLCD_LCD_STATIC1 | INTEGRATOR_CLCD_LCD_STATIC2 |
>                 INTEGRATOR_CLCD_LCD0_EN | INTEGRATOR_CLCD_LCD1_EN;
>         if (var->bits_per_pixel <= 8 ||
>             (var->bits_per_pixel == 16 && var->green.length == 5))
>                 /* Pseudocolor, RGB555, BGR555 */
>                 val |= INTEGRATOR_CLCD_LCDMUX_VGA555;
>         else if (fb->fb.var.bits_per_pixel <= 16)
>                 /* truecolor RGB565 */
>                 val |= INTEGRATOR_CLCD_LCDMUX_VGA565;
>         else
>                 val = 0; /* no idea for this, don't trust the docs */
> 
>         regmap_update_bits(versatile_syscon_map,
>                            INTEGRATOR_HDR_CTRL_OFFSET,
>                            0,
>                            INTEGRATOR_CLCD_MASK);
> }
> 
> This is stuff that is so closely tied in to the fbdev driver that even
> if it is SoC-specific (and reside in arch/arm/mach-integrator etc
> today) it would be hard to argument that it should not be part
> of the fbdev driver: what it does is connect the lines out of the
> CLCD block to the physical VGA encode chip in different ways
> depending on how the pixels were set up.

Hmm so is there an external VGA encoder on the board?

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/bd6de85d/attachment-0001.sig>

From will.deacon at arm.com  Thu Feb 25 08:46:31 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Feb 2016 16:46:31 +0000
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <CAKv+Gu-REUdVJF-_wGU=LRaVRZqsD9bgny9S52pMLp+Es4E-1A@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160225160714.GA16546@arm.com>
 <CAKv+Gu94LAAwj2f9Sj9imn68V0VTF+NOtUPsE3tQnVzNDhAATw@mail.gmail.com>
 <20160225162622.GC16546@arm.com>
 <CAKv+Gu8Qx21M=ymne1S4CQUFrXKHTnWFygGBLtXbxiUD9GkiWw@mail.gmail.com>
 <20160225164208.GD16546@arm.com>
 <CAKv+Gu-REUdVJF-_wGU=LRaVRZqsD9bgny9S52pMLp+Es4E-1A@mail.gmail.com>
Message-ID: <20160225164630.GF16546@arm.com>

On Thu, Feb 25, 2016 at 05:43:35PM +0100, Ard Biesheuvel wrote:
> On 25 February 2016 at 17:42, Will Deacon <will.deacon at arm.com> wrote:
> > On Thu, Feb 25, 2016 at 05:33:25PM +0100, Ard Biesheuvel wrote:
> >> AFAIK, gcc never uses x18 (the platform register) so we may be able to
> >> use that instead. We'd need confirmation from the toolchain guys,
> >> though ...
> >
> > In fact, a better thing to do is probably for the atomic code to
> > save/restore those register explicitly and then remove them from the
> > cflags above.
> >
> > I'll try hacking something together...
> >
> 
> That would be more correct, indeed. Also, the PLT can only use br
> <reg> so it will always enter the callee with the preserved value
> stacked, and so the callee needs to be modified in any case.

Wait -- why does the callee need to be modified here? It has no idea
about whether or not it was invoked via a PLT.

Also, can I rely on the PLT not clobbering the condition code?

Will


From ard.biesheuvel at linaro.org  Thu Feb 25 08:49:37 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 25 Feb 2016 17:49:37 +0100
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <20160225164630.GF16546@arm.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160225160714.GA16546@arm.com>
 <CAKv+Gu94LAAwj2f9Sj9imn68V0VTF+NOtUPsE3tQnVzNDhAATw@mail.gmail.com>
 <20160225162622.GC16546@arm.com>
 <CAKv+Gu8Qx21M=ymne1S4CQUFrXKHTnWFygGBLtXbxiUD9GkiWw@mail.gmail.com>
 <20160225164208.GD16546@arm.com>
 <CAKv+Gu-REUdVJF-_wGU=LRaVRZqsD9bgny9S52pMLp+Es4E-1A@mail.gmail.com>
 <20160225164630.GF16546@arm.com>
Message-ID: <CAKv+Gu8GYhPeXvgpAoHxYTYfqEHLqqLHVU9U6o3nvxew8dGo6A@mail.gmail.com>

On 25 February 2016 at 17:46, Will Deacon <will.deacon at arm.com> wrote:
> On Thu, Feb 25, 2016 at 05:43:35PM +0100, Ard Biesheuvel wrote:
>> On 25 February 2016 at 17:42, Will Deacon <will.deacon at arm.com> wrote:
>> > On Thu, Feb 25, 2016 at 05:33:25PM +0100, Ard Biesheuvel wrote:
>> >> AFAIK, gcc never uses x18 (the platform register) so we may be able to
>> >> use that instead. We'd need confirmation from the toolchain guys,
>> >> though ...
>> >
>> > In fact, a better thing to do is probably for the atomic code to
>> > save/restore those register explicitly and then remove them from the
>> > cflags above.
>> >
>> > I'll try hacking something together...
>> >
>>
>> That would be more correct, indeed. Also, the PLT can only use br
>> <reg> so it will always enter the callee with the preserved value
>> stacked, and so the callee needs to be modified in any case.
>
> Wait -- why does the callee need to be modified here? It has no idea
> about whether or not it was invoked via a PLT.
>

No, it doesn't, and that is exactly the problem: the PLT must end in a
br <reg> instruction because that is the only branch instruction with
unlimited range. That means you will always enter the callee with its
address in some register rather than the value that should have been
preserved. I don't see a way to manage that from the callee

> Also, can I rely on the PLT not clobbering the condition code?
>

For my particular implementation, yes.


From stillcompiling at gmail.com  Thu Feb 25 08:49:39 2016
From: stillcompiling at gmail.com (Joshua Clayton)
Date: Thu, 25 Feb 2016 08:49:39 -0800
Subject: [PATCH net-next V2 00/16] net: fec: cleanup and fixes
In-Reply-To: <56CF264E.2070903@boundarydevices.com>
References: <1456360619-24390-1-git-send-email-troy.kisky@boundarydevices.com>
 <5514193.TiF8b6rKpj@diplodocus>
 <56CF264E.2070903@boundarydevices.com>
Message-ID: <20160225084939.6504c412@jclayton-pc>

On Thu, 25 Feb 2016 09:05:34 -0700
Troy Kisky <troy.kisky at boundarydevices.com> wrote:

> On 2/24/2016 7:52 PM, Joshua Clayton wrote:
> > Hello Troy,
> > I'm replying here instead of to a particular commit because several
> > of the commit messages seem inadequate.
> > 
> > The first line summaries all look good.
> > 
> > The descriptions should each also include the "user visible impact"
> > of the patch and the justification for it (i.e. why you made the
> > change).
> > 
> > For instance, patch 3 doesn't include either what will change
> >  (nothing, I'm guessing?) or why we now pass in the structures
> > instead of a queue_id. 
> 
> I can add to the commit message, that this is in preparation for
> patch 4 which depends on it. Or I could squash patches 2/3/4
> together, but I think it is easier to review smaller patches.
> 

I agree that the smaller patches are better. Mentioning that a future
patch depends on the cleanup, (or the specific structure that is
depended on) is good.

> 
> > 
> > You've also got a few (e.g. patch 9, patch 14) where the substance
> > of the patch is in the summary,
> > 
> > but missing from the message.
> > 
> > These kind of descriptions are very hard to review since the
> > expression is split between the subject of the email and the body
> > of the email, which are not close
> > together in some email programs.
> > 
> > Better to reiterate or elaborate on the summary in the message.
> > In patch 9, for instance, it would be more clear to say:
> > 
> > Move restart test to earlier in fec_txq() which saves one
> > comparison. 
> 
> 
> I can do this. And change patch 14 to read
> 
Ok.

> 
> Create subroutine reset_tx_queue to have one place
> to release any queued tx skbs.
> 
That looks like a good message.

> Any other commit messages you'd like to improve?
> 
I'm trying to give guidance in keeping with
Documentation/SubmittingPatches
What I might rather suggest is to do a quick once over for
each commit message to make sure they are each in harmony
with that document.

You can do it with git rebase --interactive, or directly in the
patches.

> 
> > P.S I'm a little confused, as I came looking for a v3 of the first
> > 8 patches and found these instead. I'll try to give your first 8 a
> > look when they show up.
> 
> The 1st 8 patches have already been applied. I added a patch to
> address your review there at the end of the series. So, that patch
> will show up in my next set.
> 
Heh. I didn't see that. I'm used to maintainers waiting for comments to
be responded to before merging changes. That however is not your fault.
Thanks for considering my suggestion anyway.

> 
> Thanks for the review
> 
> Troy

You are welcome. Thanks for upstreaming these improvements.

Joshua


From ard.biesheuvel at linaro.org  Thu Feb 25 08:50:17 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 25 Feb 2016 17:50:17 +0100
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <CAKv+Gu8GYhPeXvgpAoHxYTYfqEHLqqLHVU9U6o3nvxew8dGo6A@mail.gmail.com>
References: <1454332178-4414-1-git-send-email-ard.biesheuvel@linaro.org>
 <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160225160714.GA16546@arm.com>
 <CAKv+Gu94LAAwj2f9Sj9imn68V0VTF+NOtUPsE3tQnVzNDhAATw@mail.gmail.com>
 <20160225162622.GC16546@arm.com>
 <CAKv+Gu8Qx21M=ymne1S4CQUFrXKHTnWFygGBLtXbxiUD9GkiWw@mail.gmail.com>
 <20160225164208.GD16546@arm.com>
 <CAKv+Gu-REUdVJF-_wGU=LRaVRZqsD9bgny9S52pMLp+Es4E-1A@mail.gmail.com>
 <20160225164630.GF16546@arm.com>
 <CAKv+Gu8GYhPeXvgpAoHxYTYfqEHLqqLHVU9U6o3nvxew8dGo6A@mail.gmail.com>
Message-ID: <CAKv+Gu_dXEQ1U2XY2=xX7R8MoPB0jKM7Vh3zgZB9tBuMfQYuGg@mail.gmail.com>

On 25 February 2016 at 17:49, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> On 25 February 2016 at 17:46, Will Deacon <will.deacon at arm.com> wrote:
>> On Thu, Feb 25, 2016 at 05:43:35PM +0100, Ard Biesheuvel wrote:
>>> On 25 February 2016 at 17:42, Will Deacon <will.deacon at arm.com> wrote:
>>> > On Thu, Feb 25, 2016 at 05:33:25PM +0100, Ard Biesheuvel wrote:
>>> >> AFAIK, gcc never uses x18 (the platform register) so we may be able to
>>> >> use that instead. We'd need confirmation from the toolchain guys,
>>> >> though ...
>>> >
>>> > In fact, a better thing to do is probably for the atomic code to
>>> > save/restore those register explicitly and then remove them from the
>>> > cflags above.
>>> >
>>> > I'll try hacking something together...
>>> >
>>>
>>> That would be more correct, indeed. Also, the PLT can only use br
>>> <reg> so it will always enter the callee with the preserved value
>>> stacked, and so the callee needs to be modified in any case.
>>
>> Wait -- why does the callee need to be modified here? It has no idea
>> about whether or not it was invoked via a PLT.
>>
>
> No, it doesn't, and that is exactly the problem: the PLT must end in a
> br <reg> instruction because that is the only branch instruction with
> unlimited range. That means you will always enter the callee with its
> address in some register rather than the value that should have been
> preserved. I don't see a way to manage that from the callee
>

*caller! dammit

>> Also, can I rely on the PLT not clobbering the condition code?
>>
>
> For my particular implementation, yes.


From slemieux.tyco at gmail.com  Thu Feb 25 08:50:23 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Thu, 25 Feb 2016 11:50:23 -0500
Subject: [PATCH v3 6/6] arm: lpc32xx: phy3250 remove restart hook
In-Reply-To: <2913764.6ZXbKHTUYJ@wuerfel>
References: <1456336018-6620-1-git-send-email-slemieux.tyco@gmail.com>
 <1456336018-6620-7-git-send-email-slemieux.tyco@gmail.com>
 <2913764.6ZXbKHTUYJ@wuerfel>
Message-ID: <1456419023.25197.16.camel@localhost>

Hi Arnd,

On Wed, 2016-02-24 at 22:20 +0100, Arnd Bergmann wrote:
> On Wednesday 24 February 2016 12:46:58 Sylvain Lemieux wrote:
> > From: Sylvain Lemieux <slemieux at tycoint.com>
> > 
> > Remove the restart hook assignment from phy3250;
> > this functionality is now managed by
> > the pnx4008 watchdog driver.
> > 
> > Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
> > ---
> > Note:
> > This patch was generated with the option "--unified=2" to ensure
> > it can be apply before or after the following git pull request
> > for the LPC32xx platform:
> > - http://permalink.gmane.org/gmane.linux.ports.arm.kernel/477137
> > - http://permalink.gmane.org/gmane.linux.ports.arm.kernel/477138
> 
> This patch really needs to come before patch 5 in the series, or
> you could combine the two into a single patch.
> 
There is more change coming to the LPC32xx platform that will 
modify "phy3250.c" (LPC32xx irqchip driver).

You can refer to the following link for details:
http://permalink.gmane.org/gmane.linux.drivers.devicetree/144683

I prefer to keep the change for "phy3250.c" in a separate patch.
I will submit a new revision later today to reverse patch order.


Sylvain Lemieux

> 	Arnd




From will.deacon at arm.com  Thu Feb 25 08:56:01 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Feb 2016 16:56:01 +0000
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <CAKv+Gu_dXEQ1U2XY2=xX7R8MoPB0jKM7Vh3zgZB9tBuMfQYuGg@mail.gmail.com>
References: <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160225160714.GA16546@arm.com>
 <CAKv+Gu94LAAwj2f9Sj9imn68V0VTF+NOtUPsE3tQnVzNDhAATw@mail.gmail.com>
 <20160225162622.GC16546@arm.com>
 <CAKv+Gu8Qx21M=ymne1S4CQUFrXKHTnWFygGBLtXbxiUD9GkiWw@mail.gmail.com>
 <20160225164208.GD16546@arm.com>
 <CAKv+Gu-REUdVJF-_wGU=LRaVRZqsD9bgny9S52pMLp+Es4E-1A@mail.gmail.com>
 <20160225164630.GF16546@arm.com>
 <CAKv+Gu8GYhPeXvgpAoHxYTYfqEHLqqLHVU9U6o3nvxew8dGo6A@mail.gmail.com>
 <CAKv+Gu_dXEQ1U2XY2=xX7R8MoPB0jKM7Vh3zgZB9tBuMfQYuGg@mail.gmail.com>
Message-ID: <20160225165601.GG16546@arm.com>

On Thu, Feb 25, 2016 at 05:50:17PM +0100, Ard Biesheuvel wrote:
> On 25 February 2016 at 17:49, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> > On 25 February 2016 at 17:46, Will Deacon <will.deacon at arm.com> wrote:
> >> On Thu, Feb 25, 2016 at 05:43:35PM +0100, Ard Biesheuvel wrote:
> >>> On 25 February 2016 at 17:42, Will Deacon <will.deacon at arm.com> wrote:
> >>> > On Thu, Feb 25, 2016 at 05:33:25PM +0100, Ard Biesheuvel wrote:
> >>> >> AFAIK, gcc never uses x18 (the platform register) so we may be able to
> >>> >> use that instead. We'd need confirmation from the toolchain guys,
> >>> >> though ...
> >>> >
> >>> > In fact, a better thing to do is probably for the atomic code to
> >>> > save/restore those register explicitly and then remove them from the
> >>> > cflags above.
> >>> >
> >>> > I'll try hacking something together...
> >>> >
> >>>
> >>> That would be more correct, indeed. Also, the PLT can only use br
> >>> <reg> so it will always enter the callee with the preserved value
> >>> stacked, and so the callee needs to be modified in any case.
> >>
> >> Wait -- why does the callee need to be modified here? It has no idea
> >> about whether or not it was invoked via a PLT.
> >>
> >
> > No, it doesn't, and that is exactly the problem: the PLT must end in a
> > br <reg> instruction because that is the only branch instruction with
> > unlimited range. That means you will always enter the callee with its
> > address in some register rather than the value that should have been
> > preserved. I don't see a way to manage that from the callee
> >
> 
> *caller! dammit

The caller can do:

save x16, 17
bl plt
restore x16, x17

the plt will do:

get_addr_of_callee_into_x16_and_clobber_x17_or_something
br callee

then the callee will be compiled with all those weird options, but *not*
the ones specifying x16 and x17. That means it can happily use those guys
as scratch, because the caller will take care of them.

Will


From linux at arm.linux.org.uk  Thu Feb 25 08:57:23 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Thu, 25 Feb 2016 16:57:23 +0000
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56CF2FB1.106@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <3695074.sKSIyOjpjD@wuerfel>
 <CACRpkdZjfjOCFUucF1U5yVZBxSwa41GKEMv-HHQE=ymF2NZ21g@mail.gmail.com>
 <6859810.tb1t0IEONi@wuerfel> <56CC57FC.20707@ti.com>
 <CACRpkdYNaNtQQJ-tsBe5ksa4-z380ZQj-zN8ZnK0ED2kNPUwvg@mail.gmail.com>
 <56CC60C4.6040908@ti.com>
 <CACRpkdZd8TLdsi7_cOrqzcqWKJrfdp4Vz2sx5ozpwJXOj0fa+Q@mail.gmail.com>
 <56CF2FB1.106@ti.com>
Message-ID: <20160225165723.GT19428@n2100.arm.linux.org.uk>

On Thu, Feb 25, 2016 at 06:45:37PM +0200, Tomi Valkeinen wrote:
> > *All* the others
> > will be very happy with *ONE* display defined as panel in the
> > device tree, and off they go. Usually VGA. And that will look
> 
> You keep mentioning VGA. So is there are VGA output? Or do you just mean
> MIPI DPI panels, which happen to take the same video timings as VGA?

There is a 15-pin VGA connector too.  No DDC though.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From dinguyen at opensource.altera.com  Thu Feb 25 08:56:28 2016
From: dinguyen at opensource.altera.com (Dinh Nguyen)
Date: Thu, 25 Feb 2016 10:56:28 -0600
Subject: [PATCH v2] dts: add specific compatible type for Terasic
 DE0-NANO-SoC Board
In-Reply-To: <20160225103820.GB747@pengutronix.de>
References: <8416439.76b9YNhpgR@dabox>
 <alpine.DEB.2.02.1602241048100.3815@linux-builds1> <2186741.ZYdHdfu2ug@dabox>
 <20160225103820.GB747@pengutronix.de>
Message-ID: <56CF323C.90202@opensource.altera.com>

On 02/25/2016 04:38 AM, Steffen Trumtrar wrote:
> Hi Tim!
> 
> On Thu, Feb 25, 2016 at 11:05:05AM +0100, Tim Sander wrote:
>> From: Tim Sander <tim at krieglstein.org>
>>
>> Add a more specific compatible string:"terasic,de0-nano-soc" for respective board.
>> Background: when checking for bootspec entries, some board specific fixups are
>> not apropriate for board of the same platform ("altr,socfpga-cyclone5").
>> The same aproach is taken with the EBV-Socrates board.
>>
>> Signed-off-by: Tim Sander <tim at krieglstein.org>
>> ---
>>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>>  arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts     | 2 +-
>>  2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index 72e2c5a..d1f7803 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -230,6 +230,7 @@ synology	Synology, Inc.
>>  tbs	TBS Technologies
>>  tcl	Toby Churchill Ltd.
>>  technologic	Technologic Systems
>> +terasic	Terasic Inc.
>>  thine	THine Electronics, Inc.
>>  ti	Texas Instruments
>>  tlm	Trusted Logic Mobility
> 
> You should IMHO split this up in two patches.
> First patch: add terasic
> 

That's right. That patch will go through the DTS maintainer's tree.

>> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
>> index afea364..704aa9d 100644
>> --- a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
>> +++ b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
>> @@ -18,7 +18,7 @@
>>  
>>  / {
>>  	model = "Terasic DE-0(Atlas)";
>> -	compatible = "altr,socfpga-cyclone5", "altr,socfpga";
>> +	compatible = "terasic,de0-nano-soc","altr,socfpga-cyclone5", "altr,socfpga";
> 

So perhaps, "terasic,de0-sockit"?

> Second patch: this.
> 

And I can take this one.

>>  
>>  	chosen {
>>  		bootargs = "earlyprintk";
> 
> The naming of this board still confuses me though.
> It has 3 different names now:
> 
> 	- de0_sockit.dts
> 	- Terasic DE-0(Atlas)
> 	- de0-nano-soc
> 
> And according to Terasic DE0-Nano-SoC is the same as Atlas-SoC with a different software?!
> So all three names are actually correct ?! Weird.
> 

I had a hard time understanding this myself. But from what I gather
from[1], I just name the file de0_sockit.

Dinh

[1]
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=13&List=Simple#Category167




From romain.izard.pro at gmail.com  Thu Feb 25 09:08:19 2016
From: romain.izard.pro at gmail.com (Romain Izard)
Date: Thu, 25 Feb 2016 18:08:19 +0100
Subject: [PATCH v2] tty/serial: at91: restore dynamic driver binding
In-Reply-To: <20160225160929.GA20373@kroah.com>
References: <1456392221-30401-1-git-send-email-romain.izard.pro@gmail.com>
 <56CED0E3.5070308@atmel.com> <20160225160929.GA20373@kroah.com>
Message-ID: <CAGkQfmOYEiXbQbe14iybu_4BFQYtoAj4QWoxdhPvUJOCOm6sbw@mail.gmail.com>

2016-02-25 17:09 GMT+01:00 Greg Kroah-Hartman
<gregkh at linuxfoundation.org>:
> On Thu, Feb 25, 2016 at 11:01:07AM +0100, Nicolas Ferre wrote:
>> Le 25/02/2016 10:23, Romain Izard a ?crit :
>> > In commit c39dfebc7798956fd2140ae6321786ff35da30c3, the modular
>> > support code for atmel_serial was removed, as the driver cannot be
>> > built as a module. Because no use case was proposed, the dynamic
>> > driver binding support was removed as well.
>> >
>> > The atmel_serial driver can manage up to 7 serial controllers,
>> > which are multiplexed with other functions. For example, in the
>> > Atmel SAMA5D2, the Flexcom controllers can work as USART, SPI or
>> > I2C controllers, and on all Atmel devices serial lines can be
>> > reconfigured as GPIOs.
>> >
>> > My use case uses GPIOs to transfer a firmware update using a custom
>> > protocol on the lines used as a serial port during the normal life
>> > of the device. If it is not possible to unbind the atmel_serial
>> > driver, the GPIO lines remain reserved and prevent this case from
>> > working.
>> >
>> > This patch reinstates the atmel_serial_remove function, and fixes
>> > it as it failed to clear the "clk" field on removal, triggering an
>> > oops when a device was bound again after being unbound.
>> >
>> > Signed-off-by: Romain Izard <romain.izard.pro at gmail.com>
>>
>> Even if you didn't follow my advice for not including unneeded
>> changes in of the last patch chunk, there's no use delaying the patch
>> just for this. So, here is my:
>
> Yes there is, I'm not going to take this, Romain please fix it
> properly.

Are we really arguing about the alignement of of_match_table in the
platform_driver initializer?

Among other things, Paul's patch changed the alignment to match the
width of the "suppress_bind_attrs" member. As I simply used 'git revert
-p' to revert the parts of the patch that bothered me, the alignment
returned to what it was before.

Or am I missing something else ?

-- 
Romain Izard


From ynvich at gmail.com  Thu Feb 25 09:09:43 2016
From: ynvich at gmail.com (Sergei Ianovich)
Date: Thu, 25 Feb 2016 20:09:43 +0300
Subject: [PATCH] spi: lp-8841: return correct error code from probe
In-Reply-To: <1456400265-3068525-1-git-send-email-arnd@arndb.de>
References: <1456400265-3068525-1-git-send-email-arnd@arndb.de>
Message-ID: <1456420183.23036.40.camel@gmail.com>

On Thu, 2016-02-25 at 12:37 +0100, Arnd Bergmann wrote:
> The spi_lp8841_rtc_probe() function misses an initialization of the
> return code when it fails to get its memory resource, as gcc notices:
> 
> drivers/spi/spi-lp8841-rtc.c: In function 'spi_lp8841_rtc_probe':
> drivers/spi/spi-lp8841-rtc.c:239:9: error: 'ret' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This changes the code to propagate the error from
> devm_ioremap_resource().
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 7ecbfff6711f ("spi: master driver to enable RTC on ICPDAS LP-
> 8841")

Tested-by: Sergei Ianovich <ynvich at gmail.com>


From nicolas.ferre at atmel.com  Thu Feb 25 09:24:14 2016
From: nicolas.ferre at atmel.com (Nicolas Ferre)
Date: Thu, 25 Feb 2016 18:24:14 +0100
Subject: [PATCH v2] tty/serial: at91: restore dynamic driver binding
In-Reply-To: <CAGkQfmOYEiXbQbe14iybu_4BFQYtoAj4QWoxdhPvUJOCOm6sbw@mail.gmail.com>
References: <1456392221-30401-1-git-send-email-romain.izard.pro@gmail.com>
 <56CED0E3.5070308@atmel.com> <20160225160929.GA20373@kroah.com>
 <CAGkQfmOYEiXbQbe14iybu_4BFQYtoAj4QWoxdhPvUJOCOm6sbw@mail.gmail.com>
Message-ID: <56CF38BE.9030304@atmel.com>

Le 25/02/2016 18:08, Romain Izard a ?crit :
> 2016-02-25 17:09 GMT+01:00 Greg Kroah-Hartman
> <gregkh at linuxfoundation.org>:
>> On Thu, Feb 25, 2016 at 11:01:07AM +0100, Nicolas Ferre wrote:
>>> Le 25/02/2016 10:23, Romain Izard a ?crit :
>>>> In commit c39dfebc7798956fd2140ae6321786ff35da30c3, the modular
>>>> support code for atmel_serial was removed, as the driver cannot be
>>>> built as a module. Because no use case was proposed, the dynamic
>>>> driver binding support was removed as well.
>>>>
>>>> The atmel_serial driver can manage up to 7 serial controllers,
>>>> which are multiplexed with other functions. For example, in the
>>>> Atmel SAMA5D2, the Flexcom controllers can work as USART, SPI or
>>>> I2C controllers, and on all Atmel devices serial lines can be
>>>> reconfigured as GPIOs.
>>>>
>>>> My use case uses GPIOs to transfer a firmware update using a custom
>>>> protocol on the lines used as a serial port during the normal life
>>>> of the device. If it is not possible to unbind the atmel_serial
>>>> driver, the GPIO lines remain reserved and prevent this case from
>>>> working.
>>>>
>>>> This patch reinstates the atmel_serial_remove function, and fixes
>>>> it as it failed to clear the "clk" field on removal, triggering an
>>>> oops when a device was bound again after being unbound.
>>>>
>>>> Signed-off-by: Romain Izard <romain.izard.pro at gmail.com>
>>>
>>> Even if you didn't follow my advice for not including unneeded
>>> changes in of the last patch chunk, there's no use delaying the patch
>>> just for this. So, here is my:
>>
>> Yes there is, I'm not going to take this, Romain please fix it
>> properly.
> 
> Are we really arguing about the alignement of of_match_table in the
> platform_driver initializer?
> 
> Among other things, Paul's patch changed the alignment to match the
> width of the "suppress_bind_attrs" member. As I simply used 'git revert
> -p' to revert the parts of the patch that bothered me, the alignment
> returned to what it was before.
> 
> Or am I missing something else ?

Romain,

We are just saying that a patch with:

-		.name			= "atmel_usart",
-		.of_match_table		= of_match_ptr(atmel_serial_dt_ids),
-		.suppress_bind_attrs    = true,
+		.name	= "atmel_usart",
+		.of_match_table	= of_match_ptr(atmel_serial_dt_ids),

Is less readable than a patch with only the relevant part, the single line:

-		.suppress_bind_attrs = true,

So, whichever is the history of the patch, it has to simply modify the needed
lines so that we don't even ask ourselves what is the purpose of some of the changes.

Bye,
-- 
Nicolas Ferre


From p.zabel at pengutronix.de  Thu Feb 25 09:25:32 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Thu, 25 Feb 2016 18:25:32 +0100
Subject: [PATCH] ARM: prima2: always enable reset controller
In-Reply-To: <1456417673-2115511-1-git-send-email-arnd@arndb.de>
References: <1456417673-2115511-1-git-send-email-arnd@arndb.de>
Message-ID: <1456421132.3268.16.camel@pengutronix.de>

Am Donnerstag, den 25.02.2016, 17:27 +0100 schrieb Arnd Bergmann:
> The atlas7 clock controller driver registers a reset controller
> for itself, which causes a link error when the subsystem is
> disabled:
> 
> drivers/built-in.o: In function `atlas7_clk_init':
> drivers/clk/sirf/clk-atlas7.c:1681: undefined reference to `reset_controller_register'
> 
> As the clk driver does not have a Kconfig symbol for itself
> but it always built-in when the platform is enabled, we have
> to ensure that the reset controller subsystem is also built-in
> in this case.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 301c5d29402e ("clk: sirf: add CSR atlas7 clk and reset support")

Acked-by: Philipp Zabel <p.zabel at pengutronix.de>

regards
Philipp



From ard.biesheuvel at linaro.org  Thu Feb 25 09:31:04 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 25 Feb 2016 18:31:04 +0100
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <20160225165601.GG16546@arm.com>
References: <1454332178-4414-2-git-send-email-ard.biesheuvel@linaro.org>
 <20160225160714.GA16546@arm.com>
 <CAKv+Gu94LAAwj2f9Sj9imn68V0VTF+NOtUPsE3tQnVzNDhAATw@mail.gmail.com>
 <20160225162622.GC16546@arm.com>
 <CAKv+Gu8Qx21M=ymne1S4CQUFrXKHTnWFygGBLtXbxiUD9GkiWw@mail.gmail.com>
 <20160225164208.GD16546@arm.com>
 <CAKv+Gu-REUdVJF-_wGU=LRaVRZqsD9bgny9S52pMLp+Es4E-1A@mail.gmail.com>
 <20160225164630.GF16546@arm.com>
 <CAKv+Gu8GYhPeXvgpAoHxYTYfqEHLqqLHVU9U6o3nvxew8dGo6A@mail.gmail.com>
 <CAKv+Gu_dXEQ1U2XY2=xX7R8MoPB0jKM7Vh3zgZB9tBuMfQYuGg@mail.gmail.com>
 <20160225165601.GG16546@arm.com>
Message-ID: <CAKv+Gu_Bv0CsMrCR=fiowZjtmmepjdLi7RX94wv_oDdrbjr3iw@mail.gmail.com>

On 25 February 2016 at 17:56, Will Deacon <will.deacon at arm.com> wrote:
> On Thu, Feb 25, 2016 at 05:50:17PM +0100, Ard Biesheuvel wrote:
>> On 25 February 2016 at 17:49, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>> > On 25 February 2016 at 17:46, Will Deacon <will.deacon at arm.com> wrote:
>> >> On Thu, Feb 25, 2016 at 05:43:35PM +0100, Ard Biesheuvel wrote:
>> >>> On 25 February 2016 at 17:42, Will Deacon <will.deacon at arm.com> wrote:
>> >>> > On Thu, Feb 25, 2016 at 05:33:25PM +0100, Ard Biesheuvel wrote:
>> >>> >> AFAIK, gcc never uses x18 (the platform register) so we may be able to
>> >>> >> use that instead. We'd need confirmation from the toolchain guys,
>> >>> >> though ...
>> >>> >
>> >>> > In fact, a better thing to do is probably for the atomic code to
>> >>> > save/restore those register explicitly and then remove them from the
>> >>> > cflags above.
>> >>> >
>> >>> > I'll try hacking something together...
>> >>> >
>> >>>
>> >>> That would be more correct, indeed. Also, the PLT can only use br
>> >>> <reg> so it will always enter the callee with the preserved value
>> >>> stacked, and so the callee needs to be modified in any case.
>> >>
>> >> Wait -- why does the callee need to be modified here? It has no idea
>> >> about whether or not it was invoked via a PLT.
>> >>
>> >
>> > No, it doesn't, and that is exactly the problem: the PLT must end in a
>> > br <reg> instruction because that is the only branch instruction with
>> > unlimited range. That means you will always enter the callee with its
>> > address in some register rather than the value that should have been
>> > preserved. I don't see a way to manage that from the callee
>> >
>>
>> *caller! dammit
>
> The caller can do:
>
> save x16, 17
> bl plt
> restore x16, x17
>

This is __LL_SC_CALL, right? So you just fold a stp/ldp in there?

> the plt will do:
>
> get_addr_of_callee_into_x16_and_clobber_x17_or_something
> br callee
>
> then the callee will be compiled with all those weird options, but *not*
> the ones specifying x16 and x17. That means it can happily use those guys
> as scratch, because the caller will take care of them.
>

Yes, that makes sense. But if you don't relax that restriction, you
only need the alternative __LL_SC_CALL for modules.


From lorenzo.pieralisi at arm.com  Thu Feb 25 09:38:22 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 25 Feb 2016 17:38:22 +0000
Subject: [PATCH] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot
 for X-Gene v1
In-Reply-To: <CADaLND=mrkxOWOzcEb8os16Rb=SDHfnn_8eSgB4bQYH3UguS3w@mail.gmail.com>
References: <1455069384-22323-1-git-send-email-dhdang@apm.com>
 <1456330151.5681.46.camel@redhat.com> <56CDD767.6020103@arm.com>
 <CADaLND=mrkxOWOzcEb8os16Rb=SDHfnn_8eSgB4bQYH3UguS3w@mail.gmail.com>
Message-ID: <20160225173822.GA6349@red-moon>

On Wed, Feb 24, 2016 at 02:28:10PM -0800, Duc Dang wrote:
> On Wed, Feb 24, 2016 at 8:16 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> > On 24/02/16 16:09, Mark Salter wrote:
> >> On Tue, 2016-02-09 at 17:56 -0800, Duc Dang wrote:
> >>> This patch makes pci-xgene-msi driver ACPI-aware and provides
> >>> MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode.
> >>>
> >>> Signed-off-by: Duc Dang <dhdang at apm.com>
> >>> ---
> >>>  drivers/pci/host/pci-xgene-msi.c | 35 ++++++++++++++++++++++++++++++++---
> >>>  1 file changed, 32 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/pci/host/pci-xgene-msi.c b/drivers/pci/host/pci-xgene-msi.c
> >>> index a6456b5..466aa93 100644
> >>> --- a/drivers/pci/host/pci-xgene-msi.c
> >>> +++ b/drivers/pci/host/pci-xgene-msi.c
> >>> @@ -24,6 +24,7 @@
> >>>  #include <linux/pci.h>
> >>>  #include <linux/platform_device.h>
> >>>  #include <linux/of_pci.h>
> >>> +#include <linux/acpi.h>
> >>>
> >>>  #define MSI_IR0                     0x000000
> >>>  #define MSI_INT0            0x800000
> >>> @@ -39,7 +40,7 @@ struct xgene_msi_group {
> >>>  };
> >>>
> >>>  struct xgene_msi {
> >>> -    struct device_node      *node;
> >>> +    struct fwnode_handle    *fwnode;
> >>>      struct irq_domain       *inner_domain;
> >>>      struct irq_domain       *msi_domain;
> >>>      u64                     msi_addr;
> >>> @@ -249,6 +250,13 @@ static const struct irq_domain_ops msi_domain_ops = {
> >>>      .free   = xgene_irq_domain_free,
> >>>  };
> >>>
> >>> +#ifdef CONFIG_ACPI
> >>> +static struct fwnode_handle *xgene_msi_get_fwnode(struct device *dev)
> >>> +{
> >>> +    return xgene_msi_ctrl.fwnode;
> >>> +}
> >>> +#endif
> >>> +
> >>>  static int xgene_allocate_domains(struct xgene_msi *msi)
> >>>  {
> >>>      msi->inner_domain = irq_domain_add_linear(NULL, NR_MSI_VEC,
> >>> @@ -256,7 +264,7 @@ static int xgene_allocate_domains(struct xgene_msi *msi)
> >>>      if (!msi->inner_domain)
> >>>              return -ENOMEM;
> >>>
> >>> -    msi->msi_domain = pci_msi_create_irq_domain(of_node_to_fwnode(msi->node),
> >>> +    msi->msi_domain = pci_msi_create_irq_domain(msi->fwnode,
> >>>                                                  &xgene_msi_domain_info,
> >>>                                                  msi->inner_domain);
> >>
> >> This doesn't work for me (ACPI probing on Mustang) unless I change this
> >> to be pci_msi_create_default_irq_domain(). The problem seems to be that
> >> the MSI probe happens after the PCIe RC is probed so there is no MSI domain
> >> at the time the PCIe root is initialized by ACPI.
> >
> > pci_msi_create_default_irq_domain is the wrong thing do use, specially
> > if you have multiple MSI controllers in the system. I certainly wouldn't
> > want to see it being used on arm64.
> >
> > This is the usual dependency hell. You try moving the probing earlier,
> > but that may break something else in the process.
> 
> Hi Mark and Marc,
> 
> I have modified Tianocore firmware to have MSI node declared before
> PCIe node in Dsdt table. With this modification, the MSI driver will
> be loaded before PCIe driver and MSI domain is available at the time
> PCIe root is initialized.

I am totally against this. We should not hack ACPI tables to make
the kernel work (on top of that with unwritten ordering rules that may
well require changes as kernel evolves), we should have a standard set
of bindings that people use to describe HW in the DSDT and the kernel(s)
has to cope with that. If there is a dependency problem in the description
we may solve it at bindings level, but I absolutely do not want to rely
on DSDT nodes ordering for things to work, that's fragile, no shortcuts
please.

Thanks,
Lorenzo


From maxime.ripard at free-electrons.com  Thu Feb 25 09:42:02 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Feb 2016 09:42:02 -0800
Subject: [PATCH v6] Fix sun7i pin assignment for IRQ's
In-Reply-To: <280e414e-546e-4a91-91a6-a4fa7157db49@googlegroups.com>
References: <1456161251-2303-1-git-send-email-henry@nitronetworks.nl>
 <20160225005412.GB4736@lukather>
 <CACRpkdYmf8-ZPV5q9H3cdZtQDUkbx=bcrVg9a8M3zEAifXxF9A@mail.gmail.com>
 <280e414e-546e-4a91-91a6-a4fa7157db49@googlegroups.com>
Message-ID: <20160225174202.GA31136@lukather>

Hi,

On Thu, Feb 25, 2016 at 06:26:22AM -0800, Henry Paulissen wrote:
> 
> 
> Op donderdag 25 februari 2016 15:16:49 UTC+1 schreef Linus Walleij:
> 
> >
> > I'm taking this patch out of my tree now following Maxime's comments. 
> >
> > I'm a bit annoyed that it is iterating too quickly as well, I will 
> > wait and see for a while. 
> >
> >  
> All of Maxime his questions where already answered in a reply to him at:
> Date: Sun, 21 Feb 2016 11:27:46 -0800 (PST)

And I was not among the recipients of that mail, please try to keep
everyone in Cc.

Commenting on it right now....

Maxime


-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/127a684d/attachment-0001.sig>

From suzuki.poulose at arm.com  Thu Feb 25 09:42:58 2016
From: suzuki.poulose at arm.com (Suzuki K Poulose)
Date: Thu, 25 Feb 2016 17:42:58 +0000
Subject: [PATCH] arm: fixmap: Annotate page flags with pgprot
Message-ID: <1456422178-1371-1-git-send-email-suzuki.poulose@arm.com>

With STRICT_MM_TYPECHECKS, the kernel build fails like :

  CC      mm/early_ioremap.o
mm/early_ioremap.c: In function ?early_ioremap?:
mm/early_ioremap.c:211:2: error: incompatible type for argument 3 of ?__early_ioremap?
mm/early_ioremap.c:98:1: note: expected ?pgprot_t? but argument is of type ?long long unsigned int?
mm/early_ioremap.c: In function ?early_memremap?:
mm/early_ioremap.c:219:13: error: incompatible type for argument 3 of ?__early_ioremap?
mm/early_ioremap.c:98:1: note: expected ?pgprot_t? but argument is of type ?long long unsigned int?
mm/early_ioremap.c: In function ?early_memremap_ro?:
mm/early_ioremap.c:225:2: error: incompatible type for argument 3 of ?__early_ioremap?
mm/early_ioremap.c:98:1: note: expected ?pgprot_t? but argument is of type ?long long unsigned int?
mm/early_ioremap.c:226:1: warning: control reaches end of non-void function [-Wreturn-type]
mm/early_ioremap.c: In function ?early_memremap?:
mm/early_ioremap.c:220:1: warning: control reaches end of non-void function [-Wreturn-type]
mm/early_ioremap.c: In function ?early_ioremap?:
mm/early_ioremap.c:212:1: warning: control reaches end of non-void function [-Wreturn-type]
make[1]: *** [mm/early_ioremap.o] Error 1
make: *** [mm] Error 2
make: *** Waiting for unfinished jobs....
  CC      arch/arm/mm/mmu.o
  CC      arch/arm/kernel/patch.o
arch/arm/kernel/patch.c: In function ?patch_map?:
arch/arm/kernel/patch.c:39:2: error: incompatible type for argument 3 of ?__set_fixmap?
./arch/arm/include/asm/fixmap.h:55:6: note: expected ?pgprot_t? but argument is of type ?long long unsigned int?
make[1]: *** [arch/arm/kernel/patch.o] Error 1

Fixes Commit a5f4c561b ("ARM: 8415/1: early fixmap support for earlycon").

Annotate the page flags properly using __pgprot.

Cc: Stefan Agner <stefan at agner.ch>
Cc: Arnd Bergmann <arnd at arndb.de>
Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <rmk+kernel at arm.linux.org.uk>
Cc: stable at vger.kernel.org	# v4.3+
Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
---
 arch/arm/include/asm/fixmap.h |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
index 5c17d2d..8d48d5a 100644
--- a/arch/arm/include/asm/fixmap.h
+++ b/arch/arm/include/asm/fixmap.h
@@ -39,13 +39,13 @@ static const enum fixed_addresses __end_of_fixed_addresses =
 	__end_of_fixmap_region > __end_of_early_ioremap_region ?
 	__end_of_fixmap_region : __end_of_early_ioremap_region;
 
-#define FIXMAP_PAGE_COMMON	(L_PTE_YOUNG | L_PTE_PRESENT | L_PTE_XN | L_PTE_DIRTY)
+#define FIXMAP_PAGE_COMMON	__pgprot(L_PTE_YOUNG | L_PTE_PRESENT | L_PTE_XN | L_PTE_DIRTY)
 
-#define FIXMAP_PAGE_NORMAL	(FIXMAP_PAGE_COMMON | L_PTE_MT_WRITEBACK)
-#define FIXMAP_PAGE_RO		(FIXMAP_PAGE_NORMAL | L_PTE_RDONLY)
+#define FIXMAP_PAGE_NORMAL	__pgprot(pgprot_val(FIXMAP_PAGE_COMMON) | L_PTE_MT_WRITEBACK)
+#define FIXMAP_PAGE_RO		__pgprot(pgprot_val(FIXMAP_PAGE_NORMAL) | L_PTE_RDONLY)
 
 /* Used by set_fixmap_(io|nocache), both meant for mapping a device */
-#define FIXMAP_PAGE_IO		(FIXMAP_PAGE_COMMON | L_PTE_MT_DEV_SHARED | L_PTE_SHARED)
+#define FIXMAP_PAGE_IO		__pgprot(pgprot_val(FIXMAP_PAGE_COMMON) | L_PTE_MT_DEV_SHARED | L_PTE_SHARED)
 #define FIXMAP_PAGE_NOCACHE	FIXMAP_PAGE_IO
 
 #define __early_set_fixmap	__set_fixmap
-- 
1.7.9.5



From andrew at lunn.ch  Thu Feb 25 09:44:44 2016
From: andrew at lunn.ch (Andrew Lunn)
Date: Thu, 25 Feb 2016 18:44:44 +0100
Subject: [Patch v2] ARM: dts: vf610-zii-dev: Add ZII development board.
Message-ID: <1456422284-11972-1-git-send-email-andrew@lunn.ch>

From: Cory Tusar <cory.tusar at pid1solutions.com>

This commit adds support for Rev. B of a Zodiac Inflight Innovations
development board, mainly intended for DSA and ARINC 429 development
work.

Signed-off-by: Cory Tusar <cory.tusar at pid1solutions.com>
Signed-off-by: Andrew Lunn <andrew at lunn.ch>
---
v2
 Add ZII Copyright
 Dual license
 Remove bootargs and extend stdout-path
 Remove address format from regulator nodes
 Remove extraneous space i2c_3 node
 Move iomuxc to end
 Remove L2 node
 Add missing gpio-controller to gpio6
 Removed unused fixed clocks
 Add an spi node
 Fix memory range
 Fix naming of GPIO i2c expanders
 Disable DMA on serial port, which appears to cause corrupt.

Documentation/devicetree/bindings/net/mdio-mux.txt says:

Required properties for child nodes:
- #address-cells = <1>;
- #size-cells = <0>;
- reg : The sub-bus number.

So i ignored the request to remove these properties.
---
 arch/arm/boot/dts/Makefile                |   3 +-
 arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 735 ++++++++++++++++++++++++++++++
 2 files changed, 737 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/vf610-zii-dev-rev-b.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70e8b26..47c4c2ff41de 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -372,7 +372,8 @@ dtb-$(CONFIG_SOC_VF610) += \
 	vf610m4-colibri.dtb \
 	vf610-cosmic.dtb \
 	vf610m4-cosmic.dtb \
-	vf610-twr.dtb
+	vf610-twr.dtb \
+	vf610-zii-dev-rev-b.dtb
 dtb-$(CONFIG_ARCH_MXS) += \
 	imx23-evk.dtb \
 	imx23-olinuxino.dtb \
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
new file mode 100644
index 000000000000..c2fb60b9b36c
--- /dev/null
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -0,0 +1,735 @@
+/*
+ * Copyright (C) 2015, 2016 Zodiac Inflight Innovations
+ *
+ * Based on an original 'vf610-twr.dts' which is Copyright 2015,
+ * Freescale Semiconductor, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License
+ *     version 2 as published by the Free Software Foundation.
+ *
+ *     This file is distributed in the hope that it will be useful
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "vf610.dtsi"
+
+/ {
+	model = "ZII VF610 Development Board, Rev B";
+	compatible = "zii,vf610dev-b", "zii,vf610dev", "fsl,vf610";
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	memory {
+		reg = <0x80000000 0x20000000>;
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+		pinctrl-0 = <&pinctrl_leds_debug>;
+		pinctrl-names = "default";
+
+		debug_1 {
+			label = "zii:green:debug1";
+			gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	mdio-mux {
+		compatible = "mdio-mux-gpio";
+		pinctrl-0 = <&pinctrl_mdio_mux>;
+		pinctrl-names = "default";
+		gpios = <&gpio0 8  GPIO_ACTIVE_HIGH
+			 &gpio0 9  GPIO_ACTIVE_HIGH
+			 &gpio0 24 GPIO_ACTIVE_HIGH
+			 &gpio0 25 GPIO_ACTIVE_HIGH>;
+		mdio-parent-bus = <&mdio1>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		mdio_mux_1: mdio at 1 {
+			reg = <1>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mdio_mux_2: mdio at 2 {
+			reg = <2>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mdio_mux_4: mdio at 4 {
+			reg = <4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		mdio_mux_8: mdio at 8 {
+			reg = <8>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+	};
+
+	dsa at 0 {
+		compatible = "marvell,dsa";
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		dsa,ethernet = <&fec1>;
+		dsa,mii-bus = <&mdio_mux_1>;
+
+		/* 6352 - Primary - 7 ports */
+		switch0: switch at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x00 0>;
+			eeprom-length = <512>;
+
+			port at 0 {
+				reg = <0>;
+				label = "lan0";
+			};
+
+			port at 1 {
+				reg = <1>;
+				label = "lan1";
+			};
+
+			port at 2 {
+				reg = <2>;
+				label = "lan2";
+			};
+
+			switch0port5: port at 5 {
+				reg = <5>;
+				label = "dsa";
+				phy-mode = "rgmii-txid";
+				link = <&switch1port6
+					&switch2port9>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+
+			port at 6 {
+				reg = <6>;
+				label = "cpu";
+				fixed-link {
+					speed = <100>;
+					full-duplex;
+				};
+			};
+
+		};
+
+		/* 6352 - Secondary - 7 ports */
+		switch1: switch at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x00 1>;
+			eeprom-length = <512>;
+			mii-bus = <&mdio_mux_2>;
+
+			port at 0 {
+				reg = <0>;
+				label = "lan3";
+			};
+
+			port at 1 {
+				reg = <1>;
+				label = "lan4";
+			};
+
+			port at 2 {
+				reg = <2>;
+				label = "lan5";
+			};
+
+			switch1port5: port at 5 {
+				reg = <5>;
+				label = "dsa";
+				link = <&switch2port9>;
+				phy-mode = "rgmii-txid";
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+
+			switch1port6: port at 6 {
+				reg = <6>;
+				label = "dsa";
+				phy-mode = "rgmii-txid";
+				link = <&switch0port5>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+
+		/* 6185 - 10 ports */
+		switch2: switch at 6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x00 2>;
+			mii-bus = <&mdio_mux_4>;
+
+			port at 0 {
+				reg = <0>;
+				label = "lan6";
+			};
+
+			port at 1 {
+				reg = <1>;
+				label = "lan7";
+			};
+
+			port at 2 {
+				reg = <2>;
+				label = "lan8";
+			};
+
+			port at 3 {
+				reg = <3>;
+				label = "optical3";
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+					link-gpios = <&gpio6 2
+						      GPIO_ACTIVE_HIGH>;
+				};
+			};
+
+			port at 4 {
+				reg = <4>;
+				label = "optical4";
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+					link-gpios = <&gpio6 3
+						      GPIO_ACTIVE_HIGH>;
+				};
+			};
+
+			switch2port9: port at 9 {
+				reg = <9>;
+				label = "dsa";
+				phy-mode = "rgmii-txid";
+				link = <&switch1port5
+					&switch0port5>;
+				fixed-link {
+					speed = <1000>;
+					full-duplex;
+				};
+			};
+		};
+	};
+
+	reg_vcc_3v3_mcu: reg_vcc_3v3_mcu {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_3v3_mcu";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
+
+	usb0_vbus: usb0_vbus {
+		compatible = "regulator-fixed";
+		pinctrl-0 = <&pinctrl_usb_vbus>;
+		regulator-name = "usb_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		regulator-always-on;
+		regulator-boot-on;
+		gpio = <&gpio0 6 0>;
+	};
+
+	spi0 {
+		compatible = "spi-gpio";
+		pinctrl-0 = <&pinctrl_gpio_spi0>;
+		pinctrl-names = "default";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		gpio-sck  = <&gpio1 12 GPIO_ACTIVE_HIGH>;
+		gpio-mosi = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+		gpio-miso = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+		cs-gpios  = <&gpio1  9 GPIO_ACTIVE_HIGH
+			     &gpio1  8 GPIO_ACTIVE_HIGH>;
+		num-chipselects = <2>;
+
+		m25p128 at 0 {
+			compatible = "m25p128", "jedec,spi-nor";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg = <0>;
+			spi-max-frequency = <1000000>;
+		};
+
+		at93c46d at 1 {
+			compatible = "atmel,at93c46d";
+			pinctrl-0 = <&pinctrl_gpio_e6185_eeprom_sel>;
+			pinctrl-names = "default";
+			#address-cells = <0>;
+			#size-cells = <0>;
+			reg = <1>;
+			spi-max-frequency = <500000>;
+			spi-cs-high;
+			data-size = <16>;
+			select-gpios = <&gpio4 4 GPIO_ACTIVE_HIGH>;
+		};
+	};
+};
+
+&fec0 {
+	phy-mode = "rmii";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec0>;
+	status = "okay";
+};
+
+&fec1 {
+	phy-mode = "rmii";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_fec1>;
+	status = "okay";
+
+	fixed-link {
+		   speed = <100>;
+		   full-duplex;
+	};
+
+	mdio1: mdio {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "okay";
+	};
+};
+
+&adc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_adc0_ad5>;
+	vref-supply = <&reg_vcc_3v3_mcu>;
+	status = "okay";
+};
+
+&edma0 {
+	status = "okay";
+};
+
+&esdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_esdhc1>;
+	bus-width = <4>;
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c0>;
+	status = "okay";
+
+	gpio5: pca9554 at 20 {
+		compatible = "nxp,pca9554";
+		reg = <0x20>;
+		gpio-controller;
+		#gpio-cells = <2>;
+
+	};
+
+	gpio6: pca9554 at 22 {
+		compatible = "nxp,pca9554";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_pca9554_22>;
+		reg = <0x22>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		interrupt-parent = <&gpio2>;
+		interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+	};
+
+	lm75 at 48 {
+		compatible = "national,lm75";
+		reg = <0x48>;
+	};
+
+	at24c04 at 50 {
+		compatible = "atmel,24c04";
+		reg = <0x50>;
+	};
+
+	at24c04 at 52 {
+		compatible = "atmel,24c04";
+		reg = <0x52>;
+	};
+
+	ds1682 at 6b {
+		compatible = "dallas,ds1682";
+		reg = <0x6b>;
+	};
+};
+
+&i2c1 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c1>;
+	status = "okay";
+};
+
+&i2c2 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+
+	tca9548 at 70 {
+		compatible = "nxp,pca9548";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+		reset-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
+
+		i2c2_0: i2c at 0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+
+			sfp1: at24c04 at 50 {
+				compatible = "atmel,24c02";
+				reg = <0x50>;
+			};
+		};
+
+		i2c2_1: i2c at 1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+
+			sfp2: at24c04 at 50 {
+				compatible = "atmel,24c02";
+				reg = <0x50>;
+			};
+		};
+
+		i2c2_2: i2c at 2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+
+			sfp3: at24c04 at 50 {
+				compatible = "atmel,24c02";
+				reg = <0x50>;
+			};
+		};
+
+		i2c2_3:	i2c at 3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+
+			sfp4: at24c04 at 50 {
+				compatible = "atmel,24c02";
+				reg = <0x50>;
+			};
+
+		};
+
+		i2c2_4: i2c at 4 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <4>;
+		};
+	};
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart0>;
+	status = "okay";
+	dmas = <>;
+	dma-names = "";
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart1>;
+	status = "okay";
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2>;
+	status = "okay";
+};
+
+&usbdev0 {
+	disable-over-current;
+	status = "okay";
+	vbus-supply = <&usb0_vbus>;
+	dr_mode = "host";
+};
+
+&usbh1 {
+	disable-over-current;
+	status = "okay";
+};
+
+&usbmisc0 {
+	status = "okay";
+};
+
+&usbmisc1 {
+	status = "okay";
+};
+
+&usbphy0 {
+	status = "okay";
+};
+
+&usbphy1 {
+	status = "okay";
+};
+
+&iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c_mux_reset>;
+
+	vf610-zii {
+		pinctrl_usb_vbus: pinctrl-usb-vbus {
+			fsl,pins = <
+				VF610_PAD_PTA16__GPIO_6	0x31c2
+			>;
+		};
+
+		pinctrl_i2c_mux_reset: pinctrl-i2c-mux-reset {
+			fsl,pins = <
+				 VF610_PAD_PTE14__GPIO_119	0x31c2
+				 >;
+		};
+
+		pinctrl_adc0_ad5: adc0ad5grp {
+			fsl,pins = <
+				VF610_PAD_PTC30__ADC0_SE5	0x00a1
+			>;
+		};
+
+		pinctrl_dspi0: dspi0grp {
+			fsl,pins = <
+				VF610_PAD_PTB18__DSPI0_CS1	0x1182
+				VF610_PAD_PTB19__DSPI0_CS0	0x1182
+				VF610_PAD_PTB20__DSPI0_SIN	0x1181
+				VF610_PAD_PTB21__DSPI0_SOUT	0x1182
+				VF610_PAD_PTB22__DSPI0_SCK	0x1182
+			>;
+		};
+
+		pinctrl_dspi2: dspi2grp {
+			fsl,pins = <
+				VF610_PAD_PTD31__DSPI2_CS1	0x1182
+				VF610_PAD_PTD30__DSPI2_CS0	0x1182
+				VF610_PAD_PTD29__DSPI2_SIN	0x1181
+				VF610_PAD_PTD28__DSPI2_SOUT	0x1182
+				VF610_PAD_PTD27__DSPI2_SCK	0x1182
+			>;
+		};
+
+		pinctrl_esdhc1: esdhc1grp {
+			fsl,pins = <
+				VF610_PAD_PTA24__ESDHC1_CLK	0x31ef
+				VF610_PAD_PTA25__ESDHC1_CMD	0x31ef
+				VF610_PAD_PTA26__ESDHC1_DAT0	0x31ef
+				VF610_PAD_PTA27__ESDHC1_DAT1	0x31ef
+				VF610_PAD_PTA28__ESDHC1_DATA2	0x31ef
+				VF610_PAD_PTA29__ESDHC1_DAT3	0x31ef
+				VF610_PAD_PTA7__GPIO_134	0x219d
+			>;
+		};
+
+		pinctrl_fec1: fec1grp {
+			fsl,pins = <
+				VF610_PAD_PTA6__RMII_CLKIN		0x30d1
+				VF610_PAD_PTC9__ENET_RMII1_MDC		0x30d2
+				VF610_PAD_PTC10__ENET_RMII1_MDIO	0x30d3
+				VF610_PAD_PTC11__ENET_RMII1_CRS		0x30d1
+				VF610_PAD_PTC12__ENET_RMII1_RXD1	0x30d1
+				VF610_PAD_PTC13__ENET_RMII1_RXD0	0x30d1
+				VF610_PAD_PTC14__ENET_RMII1_RXER	0x30d1
+				VF610_PAD_PTC15__ENET_RMII1_TXD1	0x30d2
+				VF610_PAD_PTC16__ENET_RMII1_TXD0	0x30d2
+				VF610_PAD_PTC17__ENET_RMII1_TXEN	0x30d2
+			>;
+		};
+
+		pinctrl_i2c0: i2c0grp {
+			fsl,pins = <
+				VF610_PAD_PTB14__I2C0_SCL	0x37ff
+				VF610_PAD_PTB15__I2C0_SDA	0x37ff
+			>;
+		};
+
+		pinctrl_i2c1: i2c1grp {
+			fsl,pins = <
+				VF610_PAD_PTB16__I2C1_SCL	0x37ff
+				VF610_PAD_PTB17__I2C1_SDA	0x37ff
+			>;
+		};
+
+		pinctrl_i2c2: i2c2grp {
+			fsl,pins = <
+				VF610_PAD_PTA22__I2C2_SCL	0x37ff
+				VF610_PAD_PTA23__I2C2_SDA	0x37ff
+			>;
+		};
+
+		pinctrl_i2c3: i2c3grp {
+			fsl,pins = <
+				VF610_PAD_PTA30__I2C3_SCL	0x37ff
+				VF610_PAD_PTA31__I2C3_SDA	0x37ff
+			>;
+		};
+
+		pinctrl_pwm0: pwm0grp {
+			fsl,pins = <
+				VF610_PAD_PTB0__FTM0_CH0	0x1582
+				VF610_PAD_PTB1__FTM0_CH1	0x1582
+				VF610_PAD_PTB2__FTM0_CH2	0x1582
+				VF610_PAD_PTB3__FTM0_CH3	0x1582
+			>;
+		};
+
+		pinctrl_uart0: uart0grp {
+			fsl,pins = <
+				VF610_PAD_PTB10__UART0_TX	0x21a2
+				VF610_PAD_PTB11__UART0_RX	0x21a1
+			>;
+		};
+
+		pinctrl_uart1: uart1grp {
+			fsl,pins = <
+				VF610_PAD_PTB23__UART1_TX	0x21a2
+				VF610_PAD_PTB24__UART1_RX	0x21a1
+			>;
+		};
+
+		pinctrl_uart2: uart2grp {
+			fsl,pins = <
+				VF610_PAD_PTD0__UART2_TX	0x21a2
+				VF610_PAD_PTD1__UART2_RX	0x21a1
+			>;
+		};
+
+		pinctrl_qspi0: qspi0grp {
+			fsl,pins = <
+				VF610_PAD_PTD7__QSPI0_B_QSCK	0x31c3
+				VF610_PAD_PTD8__QSPI0_B_CS0	0x31ff
+				VF610_PAD_PTD9__QSPI0_B_DATA3	0x31c3
+				VF610_PAD_PTD10__QSPI0_B_DATA2	0x31c3
+				VF610_PAD_PTD11__QSPI0_B_DATA1	0x31c3
+				VF610_PAD_PTD12__QSPI0_B_DATA0	0x31c3
+			>;
+		};
+
+		pinctrl_usb0_host: usb0-host-grp {
+			fsl,pins = <
+				VF610_PAD_PTD6__GPIO_85		0x0062
+			>;
+		};
+
+		pinctrl_mdio_mux: pinctrl-mdio-mux {
+			fsl,pins = <
+				VF610_PAD_PTA18__GPIO_8		0x31c2
+				VF610_PAD_PTA19__GPIO_9		0x31c2
+				VF610_PAD_PTB2__GPIO_24		0x31c2
+				VF610_PAD_PTB3__GPIO_25		0x31c2
+			>;
+		};
+
+		pinctrl_gpio_e6185_eeprom_sel: pinctrl-gpio-e6185-eeprom-spi0 {
+			fsl,pins = <
+				VF610_PAD_PTE27__GPIO_132	0x33e2
+			>;
+		};
+
+		pinctrl_gpio_spi0: pinctrl-gpio-spi0 {
+			fsl,pins = <
+				VF610_PAD_PTB22__GPIO_44	0x33e2
+				VF610_PAD_PTB21__GPIO_43	0x33e2
+				VF610_PAD_PTB20__GPIO_42	0x33e1
+				VF610_PAD_PTB19__GPIO_41	0x33e2
+				VF610_PAD_PTB18__GPIO_40	0x33e2
+			>;
+		};
+
+		pinctrl_fec0: fec0grp {
+			fsl,pins = <
+				VF610_PAD_PTC0__ENET_RMII0_MDC	0x30d2
+				VF610_PAD_PTC1__ENET_RMII0_MDIO	0x30d3
+				VF610_PAD_PTC2__ENET_RMII0_CRS	0x30d1
+				VF610_PAD_PTC3__ENET_RMII0_RXD1	0x30d1
+				VF610_PAD_PTC4__ENET_RMII0_RXD0	0x30d1
+				VF610_PAD_PTC5__ENET_RMII0_RXER	0x30d1
+				VF610_PAD_PTC6__ENET_RMII0_TXD1	0x30d2
+				VF610_PAD_PTC7__ENET_RMII0_TXD0	0x30d2
+				VF610_PAD_PTC8__ENET_RMII0_TXEN	0x30d2
+			>;
+		};
+
+		pinctrl_leds_debug: pinctrl-leds-debug {
+			fsl,pins = <
+				 VF610_PAD_PTD20__GPIO_74	0x31c2
+				 >;
+		};
+
+		pinctrl_pca9554_22: pinctrl-pca95540-22 {
+			fsl,pins = <
+				VF610_PAD_PTB28__GPIO_98	0x219d
+			>;
+		};
+	};
+};
+
-- 
2.7.0



From mark.rutland at arm.com  Thu Feb 25 09:56:04 2016
From: mark.rutland at arm.com (Mark Rutland)
Date: Thu, 25 Feb 2016 17:56:04 +0000
Subject: [PATCH 1/3] dt-bindings: arm/marvell: ABI unstability warning
 about Marvell 7K/8K
In-Reply-To: <20160225173811.23be5b05@free-electrons.com>
References: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1456327007-31008-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160224172545.GC9137@leverpostej>
 <20160224211045.379352d3@free-electrons.com>
 <CAL_JsqLevrujSeYNBvSJA-5T0Ho8y7c0fKid7QvVm8LLvYLotw@mail.gmail.com>
 <20160225090927.13492cfb@free-electrons.com>
 <20160225161642.GC10593@leverpostej>
 <20160225173811.23be5b05@free-electrons.com>
Message-ID: <20160225175603.GD10593@leverpostej>

Hi,

On Thu, Feb 25, 2016 at 05:38:11PM +0100, Thomas Petazzoni wrote:
> Hello Mark,
> 
> On Thu, 25 Feb 2016 16:16:47 +0000, Mark Rutland wrote:
> 
> > > Either because the internal processes are complicated, or simply
> > > because the Linux kernel support is done without cooperation from the
> > > HW vendor (it's not the case of this Marvell platform, but it's the
> > > case of many other platforms).
> > 
> > Yes, this is a problem in some cases, and that should be considered in
> > those cases. There are always shades of grey.
> 
> Sure.
> 
> > Per the above, that isn't relevant in this case. This is a pretty
> > black-and-white stand against the usual rules.
> 
> I don't see why. The datasheets have not been completely written yet
> for this particular chip. For other chips we've worked on where we
> collaborated with the SoC vendor, we never had any datasheet, simply
> because the SoC vendor doesn't have any. They have the digital logic
> source code, and then tons of spreadsheets or text documents that are
> not proper datasheets and that they generally cannot share with
> third-parties.
> 
> Hence, even when the support for a SoC is being done in collaboration
> with the SoC vendor, we don't always have a nice full datasheet that
> tells us what all the registers are doing and how they are organized.
> We discover things as we go.

So as and when you believe you need to break a binding, we can have a
discussion on that case-by-case basis.

That's different to stating that the usual rules don't apply at all,
which is black-and-white stand I'm referring to.

> > Submitting prototypes and RFCs is the usual way we get things reviewed
> > early, and to allow maintainers and others to get a feel for things
> > earlier. Submitting patches _for merging_ when you're not sure about
> > things and don't want to agree to support them is what's being pushed
> > back on.
> 
> This simply doesn't work. This initial support of a few patches (clock,
> basic DT, irqchip, dmaengine) is going to be followed very soon by lots
> of other patches to enable more aspects of the SoC. And we should keep
> all of those patches out-of-tree, piling up hundreds of out-of-tree
> patches ? Not practical at all.
> 
> And then when we'll submit them, they will all be accepted in one go,
> in one kernel cycle ? Clearly not, so we would have to wait several
> kernel cycles, which is clearly not what we want.
> 
> Instead, what we want is to submit the basic stuff early, and then
> progressively build on top of this basic stuff by merging more and more
> features. This way:
> 
>  * We don't have to pile up hundreds of out of tree patches;

Then _support_ what you have upstreamed already. Either it's ready to be
supported or it is not. If it is, there's no need for DT breakage, and
if it isn't, then it's not ready for mainline. That's all this boils
down to. 

If it must go in, then it must be supported.

>  * We have a support in the mainline kernel that is progressively
>    getting better as we enable more and more feature. We can show that
>    4.6 has this small set of features, 4.7 has this slightly extended
>    set of features supported, and so on.

It's not "progressively getting better", if DTBs are arbitrarily getting
broken.

It's possible to incrementally add support without having to break
existing DTBs.

> > If you're unsure about something, but still want it merged, then you
> > have to commit to maintaining that as far as reasonably possible, even
> > if it turns out to not be quite right.
> 
> We are perfectly fine with maintaining *code*. And we have been doing
> so for several years on Marvell platforms: caring about older
> platforms, converting old legacy code and legacy platforms to the
> Device Tree, etc.

The parsing and handling of the existing binding is code, which you are
arguing you do not need to support.

> What we don't want to commit to is to maintain the DT stability
> *before* the support for a given device is sufficiently stable/sane.

I do not follow what you mean by support being *not sane*. If it isn't
sane, why was it merged?

If it was previously considered sane, and the code was considered
supportable, why is it necessary to break a DT that it supported?

> > > Do you realize that this all DT binding stuff is today the *biggest* to
> > > getting HW support in the Linux kernel? It has become more complicated
> > > to merge a 4 properties DT binding than to merge multiple thousands of
> > > lines of driver code. 
> > 
> > As times have changed, pain points have moved around.
> > 
> > To some extent that is unavoidable; more up-front effort is required
> > where crutches we previously relied on are not applicable.
> > 
> > Elsewhere we can certainly do better.
> > 
> > Throwing your hands up and stating "this is unstable, it might change"
> > is a crutch. It prevents any real solution to the pain points you
> > encounter, and creates pain points for others. It only provides the
> > _illusion_ of support.
> 
> Could you please explicit which pain points it creates for others ?
> 
> Having unstable DT bindings specific to a platform does not create any
> single pain point for anyone.
> 
> Why are you talking about "illusion" of support ? Sorry, but with
> unstable DT bindings, as long as you use the DT that comes with the
> kernel sources, everything works perfectly fine, and is perfectly
> supported.

A few examples:

* Distro installation (in the absence of a stable DT and a consistent
  boot environment, you have no idea how to get a kernel up and
  running). Either your user has to be intimately familiar with the
  platform, or the distro needs a separate release for each and every
  platform.

* Distro maintenance. I just upgraded to a point-release kernel and now
  have to pull down the DTBs. That required the distro to _somehow_
  identify the relevant DTBs, how to install this in the correct
  location such that the firmware and/or bootloader can pick it up, etc.

* Other developers tracking down problems that inevitable crop up on the
  platform, who now have to jump through the hoops above. As the DTBs
  change, so may the user-facing elements and/or kernel behaviour, so
  bisecting is extremely painful (though admittedly possible).

  Notice that in this case, the user has to go back in time for their
  starting point. So it doesn't matter if they're not a user _yet_.

* Portable hypervisors, bootloaders, or other system-level software
  can't add any (DTB-aware) support for a platform until the kernel
  support is considered "sane" per your argument above. That time is an
  arbitrary unknown in the future (which may be at infinity), so they
  are either indefinitely delayed or end up having attempt to have
  stable support for a variety of unstable bindings anyway, which may or
  may not be possible depending on how bindings got broken.

These may not affect _you_ directly, but they do hinder realistic
user-facing support.

> Even Fedora is installing DTBs in a directory that is kernel-version
> specific!

This is a _symptom_ of the problem. Read this as:

	Even Fedora _have to_ install DTBs in a directory that is
	kernel-version specific!

Notice how that does not sound great. Distros are being _forced_ to do
this because stuff gets broken. As covered above, this doesn't always
work anyway, so it's really not an argument in favour of breaking
things.

Thanks,
Mark.


From maxime.ripard at free-electrons.com  Thu Feb 25 09:59:43 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Feb 2016 09:59:43 -0800
Subject: [linux-sunxi] Re: [PATCH v3] Fix sun7i pin assignment for IRQ's
In-Reply-To: <4cf9dbe3-faa6-4729-87fd-0e7d9ce463b0@googlegroups.com>
References: <1456060845-20692-1-git-send-email-henry@nitronetworks.nl>
 <20160221171830.GD19169@lukather>
 <4cf9dbe3-faa6-4729-87fd-0e7d9ce463b0@googlegroups.com>
Message-ID: <20160225175943.GD4736@lukather>

Hi,

On Sun, Feb 21, 2016 at 11:27:46AM -0800, Henry Paulissen wrote:
> 
> Op zondag 21 februari 2016 18:18:37 UTC+1 schreef Maxime Ripard:
> 
> >
> > Your commit log is going to need some work. Which bugs? What tests did 
> > you make? Why are you making these changes while the datasheet says 
> > otherwise? 
> >
> 
> Its a fix for a not yet existing bug. I was fiddling around with IRQ's and 
> couldn't get them to work.
> I took a dumpster dive into it and found a shitload of contradicting 
> manuals and datasheets.
> 
> 
> Take for example the A20 user manual:
> http://dl.linux-sunxi.org/A20/A20%20user%20manual%20v1.3%2020141010.pdf
> 
> (pin PI14)
> Page 237: EINT26 is on mux *5* in the pin overview.
> Page 288: EINT26 is on mux *6* in the registers.
>  
> Page 233: EINT12 is on pin PC19 mux6 in the pin overview.
> Page 236: EINT12 is on pin PH12 mux6 in the pin overview.
> Page 253: EINT12 is *not* on pin PC19 on the registers.
> Page 281: EINT12 is on pin PH12 mux6 in the registers.

Ok, so i guess you're actually fixing two different things: the first
one is that some interrupts are using the wrong function, while some
others are just not there at all. It would be great if you could make
two different patches for these.

I guess we could also change SUNXI_FUNCTION_IRQ to enforce the mux
value 6, since you're removing the last users of a different value,
but that can be done as a followup

> So manual may say otherwise, but I hope I have proven that the manual isn't 
> to be trusted.
> 
> My patch is based onto testing from both me and Andre (apritzel).
> He with a Banana PI M1 and me with a Cubietruck (both A20 soc).
> 
> We did a basic test by connecting a pulsing signal to a port and configure 
> kernel to use irq.
> 
> e.g.
> echo pin# > /sys/class/gpio/export
> echo in > /sys/class/gpio/gpio#/direction
> echo rising > /sys/class/gpio/gpio#/edge
> 
> and check on /proc/interrupts to see if a irq was attached and if it was 
> receiving.
> 
> Im not sure what andre his pulse source was, but mine was a 1pps coming 
> from a gps.

That's a great explanation overall, it should just be in the commit
log itself. A git commit is easy to find, the discussion that was
triggered by it not so much.

Thanks!
Maxime


-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/203d53f8/attachment.sig>

From maxime.ripard at free-electrons.com  Thu Feb 25 10:11:05 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Feb 2016 10:11:05 -0800
Subject: [PATCH] clk: sunxi: allow PLL6 clock to be reused
In-Reply-To: <56CAD72D.7050102@arm.com>
References: <1456105198-25295-1-git-send-email-andre.przywara@arm.com>
 <CAGb2v66Fkvpqay+pNYjN1KP_KSUmv-du+PVSsyeuK+Y7bzEt+g@mail.gmail.com>
 <56CAD72D.7050102@arm.com>
Message-ID: <20160225181105.GE4736@lukather>

On Mon, Feb 22, 2016 at 09:38:53AM +0000, Andre Przywara wrote:
> >> diff --git a/drivers/clk/sunxi/clk-factors.h b/drivers/clk/sunxi/clk-factors.h
> >> index 1e63c5b..3a7da86 100644
> >> --- a/drivers/clk/sunxi/clk-factors.h
> >> +++ b/drivers/clk/sunxi/clk-factors.h
> >> @@ -36,6 +36,7 @@ struct factors_data {
> >>         void (*getter)(struct factors_request *req);
> >>         void (*recalc)(struct factors_request *req);
> >>         const char *name;
> >> +       int name_idx;
> > 
> > I would drop the .name field. It was a bad workaround
> > due to limitations of the factors clk code at the time
> > by me. We really shouldn't hard-code the name if we want
> > to reuse the driver.
> 
> I know what you mean (my first thought, too) and I totally agree, but we
> need it still for PLL5, which does not carry the original name in the DT
> output names.
> So at least this workaround here does not work, I guess we have to come
> up with something different - which would be a different patch.
> I can take a look into this later.

Actually, it could be easily worked around. Always take the first
clock output name, take whatever is before '_', and you can remove the
name field entirely.

Jens did something along these lines here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/379900.html

Maybe we should simply rebase this patch, and remove the part that
falls back on the name field.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/aba3505b/attachment.sig>

From maxime.ripard at free-electrons.com  Thu Feb 25 10:12:45 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Feb 2016 10:12:45 -0800
Subject: [PATCH v3] ARM: dts: sun7i: Add dts file for the lamobo-r1 board
In-Reply-To: <1456265563-2940-1-git-send-email-hdegoede@redhat.com>
References: <1456265563-2940-1-git-send-email-hdegoede@redhat.com>
Message-ID: <20160225181245.GF4736@lukather>

Hi,

On Tue, Feb 23, 2016 at 11:12:43PM +0100, Hans de Goede wrote:
> From: Jelle de Jong <jelledejong at powercraft.nl>
> 
> The lamobo-r1 board, sometimes called the BPI-R1 but not labelled as such
> on the PCB, is meant as a A20 based router board. As such the board comes
> with a built-in switch chip giving it 5 gigabit ethernet ports, and it
> has a large empty area on the pcb with mounting holes which will fit a
> 2.5 inch harddisk. To complete its networking features it has a
> Realtek RTL8192CU for WiFi 802.11 b/g/n.
> 
> Signed-off-by: Jelle de Jong <jelledejong at powercraft.nl>
> Signed-off-by: Hans de Goede <hdegoede at redhat.com>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/ad6bd0b2/attachment.sig>

From will.deacon at arm.com  Thu Feb 25 10:29:03 2016
From: will.deacon at arm.com (Will Deacon)
Date: Thu, 25 Feb 2016 18:29:03 +0000
Subject: [PATCH v5sub2 1/8] arm64: add support for module PLTs
In-Reply-To: <CAKv+Gu_Bv0CsMrCR=fiowZjtmmepjdLi7RX94wv_oDdrbjr3iw@mail.gmail.com>
References: <CAKv+Gu94LAAwj2f9Sj9imn68V0VTF+NOtUPsE3tQnVzNDhAATw@mail.gmail.com>
 <20160225162622.GC16546@arm.com>
 <CAKv+Gu8Qx21M=ymne1S4CQUFrXKHTnWFygGBLtXbxiUD9GkiWw@mail.gmail.com>
 <20160225164208.GD16546@arm.com>
 <CAKv+Gu-REUdVJF-_wGU=LRaVRZqsD9bgny9S52pMLp+Es4E-1A@mail.gmail.com>
 <20160225164630.GF16546@arm.com>
 <CAKv+Gu8GYhPeXvgpAoHxYTYfqEHLqqLHVU9U6o3nvxew8dGo6A@mail.gmail.com>
 <CAKv+Gu_dXEQ1U2XY2=xX7R8MoPB0jKM7Vh3zgZB9tBuMfQYuGg@mail.gmail.com>
 <20160225165601.GG16546@arm.com>
 <CAKv+Gu_Bv0CsMrCR=fiowZjtmmepjdLi7RX94wv_oDdrbjr3iw@mail.gmail.com>
Message-ID: <20160225182902.GA29259@arm.com>

On Thu, Feb 25, 2016 at 06:31:04PM +0100, Ard Biesheuvel wrote:
> On 25 February 2016 at 17:56, Will Deacon <will.deacon at arm.com> wrote:
> > the plt will do:
> >
> > get_addr_of_callee_into_x16_and_clobber_x17_or_something
> > br callee
> >
> > then the callee will be compiled with all those weird options, but *not*
> > the ones specifying x16 and x17. That means it can happily use those guys
> > as scratch, because the caller will take care of them.
> >
> 
> Yes, that makes sense. But if you don't relax that restriction, you
> only need the alternative __LL_SC_CALL for modules.

Totally untested patch below, but I'll give it a whirl tomorrow.

It looks a bit mental.

Will

--->8

diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
index 197e06afbf71..5b595b32ab40 100644
--- a/arch/arm64/include/asm/atomic_lse.h
+++ b/arch/arm64/include/asm/atomic_lse.h
@@ -33,6 +33,8 @@ static inline void atomic_andnot(int i, atomic_t *v)
 	register atomic_t *x1 asm ("x1") = v;
 
 	asm volatile(ARM64_LSE_ATOMIC_INSN(__LL_SC_ATOMIC(andnot),
+	"	nop\n"
+	"	nop\n"
 	"	stclr	%w[i], %[v]\n")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
@@ -45,6 +47,8 @@ static inline void atomic_or(int i, atomic_t *v)
 	register atomic_t *x1 asm ("x1") = v;
 
 	asm volatile(ARM64_LSE_ATOMIC_INSN(__LL_SC_ATOMIC(or),
+	"	nop\n"
+	"	nop\n"
 	"	stset	%w[i], %[v]\n")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
@@ -57,6 +61,8 @@ static inline void atomic_xor(int i, atomic_t *v)
 	register atomic_t *x1 asm ("x1") = v;
 
 	asm volatile(ARM64_LSE_ATOMIC_INSN(__LL_SC_ATOMIC(xor),
+	"	nop\n"
+	"	nop\n"
 	"	steor	%w[i], %[v]\n")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
@@ -69,6 +75,8 @@ static inline void atomic_add(int i, atomic_t *v)
 	register atomic_t *x1 asm ("x1") = v;
 
 	asm volatile(ARM64_LSE_ATOMIC_INSN(__LL_SC_ATOMIC(add),
+	"	nop\n"
+	"	nop\n"
 	"	stadd	%w[i], %[v]\n")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
@@ -83,9 +91,9 @@ static inline int atomic_add_return##name(int i, atomic_t *v)		\
 									\
 	asm volatile(ARM64_LSE_ATOMIC_INSN(				\
 	/* LL/SC */							\
-	"	nop\n"							\
 	__LL_SC_ATOMIC(add_return##name),				\
 	/* LSE atomics */						\
+	"	nop\n"							\
 	"	ldadd" #mb "	%w[i], w30, %[v]\n"			\
 	"	add	%w[i], %w[i], w30")				\
 	: [i] "+r" (w0), [v] "+Q" (v->counter)				\
@@ -109,9 +117,9 @@ static inline void atomic_and(int i, atomic_t *v)
 
 	asm volatile(ARM64_LSE_ATOMIC_INSN(
 	/* LL/SC */
-	"	nop\n"
 	__LL_SC_ATOMIC(and),
 	/* LSE atomics */
+	"	nop\n"
 	"	mvn	%w[i], %w[i]\n"
 	"	stclr	%w[i], %[v]")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
@@ -126,9 +134,9 @@ static inline void atomic_sub(int i, atomic_t *v)
 
 	asm volatile(ARM64_LSE_ATOMIC_INSN(
 	/* LL/SC */
-	"	nop\n"
 	__LL_SC_ATOMIC(sub),
 	/* LSE atomics */
+	"	nop\n"
 	"	neg	%w[i], %w[i]\n"
 	"	stadd	%w[i], %[v]")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
@@ -144,9 +152,7 @@ static inline int atomic_sub_return##name(int i, atomic_t *v)		\
 									\
 	asm volatile(ARM64_LSE_ATOMIC_INSN(				\
 	/* LL/SC */							\
-	"	nop\n"							\
-	__LL_SC_ATOMIC(sub_return##name)				\
-	"	nop",							\
+	__LL_SC_ATOMIC(sub_return##name),				\
 	/* LSE atomics */						\
 	"	neg	%w[i], %w[i]\n"					\
 	"	ldadd" #mb "	%w[i], w30, %[v]\n"			\
@@ -174,6 +180,8 @@ static inline void atomic64_andnot(long i, atomic64_t *v)
 	register atomic64_t *x1 asm ("x1") = v;
 
 	asm volatile(ARM64_LSE_ATOMIC_INSN(__LL_SC_ATOMIC64(andnot),
+	"	nop\n"
+	"	nop\n"
 	"	stclr	%[i], %[v]\n")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
@@ -186,6 +194,8 @@ static inline void atomic64_or(long i, atomic64_t *v)
 	register atomic64_t *x1 asm ("x1") = v;
 
 	asm volatile(ARM64_LSE_ATOMIC_INSN(__LL_SC_ATOMIC64(or),
+	"	nop\n"
+	"	nop\n"
 	"	stset	%[i], %[v]\n")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
@@ -198,6 +208,8 @@ static inline void atomic64_xor(long i, atomic64_t *v)
 	register atomic64_t *x1 asm ("x1") = v;
 
 	asm volatile(ARM64_LSE_ATOMIC_INSN(__LL_SC_ATOMIC64(xor),
+	"	nop\n"
+	"	nop\n"
 	"	steor	%[i], %[v]\n")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
@@ -210,6 +222,8 @@ static inline void atomic64_add(long i, atomic64_t *v)
 	register atomic64_t *x1 asm ("x1") = v;
 
 	asm volatile(ARM64_LSE_ATOMIC_INSN(__LL_SC_ATOMIC64(add),
+	"	nop\n"
+	"	nop\n"
 	"	stadd	%[i], %[v]\n")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
@@ -224,9 +238,9 @@ static inline long atomic64_add_return##name(long i, atomic64_t *v)	\
 									\
 	asm volatile(ARM64_LSE_ATOMIC_INSN(				\
 	/* LL/SC */							\
-	"	nop\n"							\
 	__LL_SC_ATOMIC64(add_return##name),				\
 	/* LSE atomics */						\
+	"	nop\n"							\
 	"	ldadd" #mb "	%[i], x30, %[v]\n"			\
 	"	add	%[i], %[i], x30")				\
 	: [i] "+r" (x0), [v] "+Q" (v->counter)				\
@@ -250,9 +264,9 @@ static inline void atomic64_and(long i, atomic64_t *v)
 
 	asm volatile(ARM64_LSE_ATOMIC_INSN(
 	/* LL/SC */
-	"	nop\n"
 	__LL_SC_ATOMIC64(and),
 	/* LSE atomics */
+	"	nop\n"
 	"	mvn	%[i], %[i]\n"
 	"	stclr	%[i], %[v]")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
@@ -267,9 +281,9 @@ static inline void atomic64_sub(long i, atomic64_t *v)
 
 	asm volatile(ARM64_LSE_ATOMIC_INSN(
 	/* LL/SC */
-	"	nop\n"
 	__LL_SC_ATOMIC64(sub),
 	/* LSE atomics */
+	"	nop\n"
 	"	neg	%[i], %[i]\n"
 	"	stadd	%[i], %[v]")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
@@ -285,9 +299,7 @@ static inline long atomic64_sub_return##name(long i, atomic64_t *v)	\
 									\
 	asm volatile(ARM64_LSE_ATOMIC_INSN(				\
 	/* LL/SC */							\
-	"	nop\n"							\
-	__LL_SC_ATOMIC64(sub_return##name)				\
-	"	nop",							\
+	__LL_SC_ATOMIC64(sub_return##name),				\
 	/* LSE atomics */						\
 	"	neg	%[i], %[i]\n"					\
 	"	ldadd" #mb "	%[i], x30, %[v]\n"			\
@@ -312,12 +324,10 @@ static inline long atomic64_dec_if_positive(atomic64_t *v)
 
 	asm volatile(ARM64_LSE_ATOMIC_INSN(
 	/* LL/SC */
-	"	nop\n"
 	__LL_SC_ATOMIC64(dec_if_positive)
 	"	nop\n"
 	"	nop\n"
 	"	nop\n"
-	"	nop\n"
 	"	nop",
 	/* LSE atomics */
 	"1:	ldr	x30, %[v]\n"
@@ -350,9 +360,7 @@ static inline unsigned long __cmpxchg_case_##name(volatile void *ptr,	\
 									\
 	asm volatile(ARM64_LSE_ATOMIC_INSN(				\
 	/* LL/SC */							\
-	"	nop\n"							\
-		__LL_SC_CMPXCHG(name)					\
-	"	nop",							\
+		__LL_SC_CMPXCHG(name),					\
 	/* LSE atomics */						\
 	"	mov	" #w "30, %" #w "[old]\n"			\
 	"	cas" #mb #sz "\t" #w "30, %" #w "[new], %[v]\n"		\
@@ -404,8 +412,6 @@ static inline long __cmpxchg_double##name(unsigned long old1,		\
 	asm volatile(ARM64_LSE_ATOMIC_INSN(				\
 	/* LL/SC */							\
 	"	nop\n"							\
-	"	nop\n"							\
-	"	nop\n"							\
 	__LL_SC_CMPXCHG_DBL(name),					\
 	/* LSE atomics */						\
 	"	casp" #mb "\t%[old1], %[old2], %[new1], %[new2], %[v]\n"\
diff --git a/arch/arm64/include/asm/lse.h b/arch/arm64/include/asm/lse.h
index 3de42d68611d..8252dc6b3046 100644
--- a/arch/arm64/include/asm/lse.h
+++ b/arch/arm64/include/asm/lse.h
@@ -25,7 +25,10 @@ __asm__(".arch_extension	lse");
 #define __LL_SC_EXPORT(x)	EXPORT_SYMBOL(__LL_SC_PREFIX(x))
 
 /* Macro for constructing calls to out-of-line ll/sc atomics */
-#define __LL_SC_CALL(op)	"bl\t" __stringify(__LL_SC_PREFIX(op)) "\n"
+#define __LL_SC_CALL(op)						\
+	"stp	x16, x17, [sp, #-16]!\n"				\
+	"bl\t" __stringify(__LL_SC_PREFIX(op)) "\n"			\
+	"ldp	x16, x17, [sp], #16\n"
 
 /* In-line patching at runtime */
 #define ARM64_LSE_ATOMIC_INSN(llsc, lse)				\
diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
index 1a811ecf71da..c86b7909ef31 100644
--- a/arch/arm64/lib/Makefile
+++ b/arch/arm64/lib/Makefile
@@ -4,15 +4,16 @@ lib-y		:= bitops.o clear_user.o delay.o copy_from_user.o	\
 		   memcmp.o strcmp.o strncmp.o strlen.o strnlen.o	\
 		   strchr.o strrchr.o
 
-# Tell the compiler to treat all general purpose registers as
-# callee-saved, which allows for efficient runtime patching of the bl
-# instruction in the caller with an atomic instruction when supported by
-# the CPU. Result and argument registers are handled correctly, based on
-# the function prototype.
+# Tell the compiler to treat all general purpose registers (with the
+# exception of the IP registers, which are already handled by the caller
+# in case of a PLT) as callee-saved, which allows for efficient runtime
+# patching of the bl instruction in the caller with an atomic instruction
+# when supported by the CPU. Result and argument registers are handled
+# correctly, based on the function prototype.
 lib-$(CONFIG_ARM64_LSE_ATOMICS) += atomic_ll_sc.o
 CFLAGS_atomic_ll_sc.o	:= -fcall-used-x0 -ffixed-x1 -ffixed-x2		\
 		   -ffixed-x3 -ffixed-x4 -ffixed-x5 -ffixed-x6		\
 		   -ffixed-x7 -fcall-saved-x8 -fcall-saved-x9		\
 		   -fcall-saved-x10 -fcall-saved-x11 -fcall-saved-x12	\
 		   -fcall-saved-x13 -fcall-saved-x14 -fcall-saved-x15	\
-		   -fcall-saved-x16 -fcall-saved-x17 -fcall-saved-x18
+		   -fcall-saved-x18


From stefan at agner.ch  Thu Feb 25 10:26:40 2016
From: stefan at agner.ch (Stefan Agner)
Date: Thu, 25 Feb 2016 10:26:40 -0800
Subject: [PATCH] arm: fixmap: Annotate page flags with pgprot
In-Reply-To: <1456422178-1371-1-git-send-email-suzuki.poulose@arm.com>
References: <1456422178-1371-1-git-send-email-suzuki.poulose@arm.com>
Message-ID: <1b0356923b2008f3133580174abba4e8@agner.ch>

On 2016-02-25 09:42, Suzuki K Poulose wrote:
> With STRICT_MM_TYPECHECKS, the kernel build fails like :
> 
>   CC      mm/early_ioremap.o
> mm/early_ioremap.c: In function ?early_ioremap?:
> mm/early_ioremap.c:211:2: error: incompatible type for argument 3 of
> ?__early_ioremap?
> mm/early_ioremap.c:98:1: note: expected ?pgprot_t? but argument is of
> type ?long long unsigned int?
> mm/early_ioremap.c: In function ?early_memremap?:
> mm/early_ioremap.c:219:13: error: incompatible type for argument 3 of
> ?__early_ioremap?
> mm/early_ioremap.c:98:1: note: expected ?pgprot_t? but argument is of
> type ?long long unsigned int?
> mm/early_ioremap.c: In function ?early_memremap_ro?:
> mm/early_ioremap.c:225:2: error: incompatible type for argument 3 of
> ?__early_ioremap?
> mm/early_ioremap.c:98:1: note: expected ?pgprot_t? but argument is of
> type ?long long unsigned int?
> mm/early_ioremap.c:226:1: warning: control reaches end of non-void
> function [-Wreturn-type]
> mm/early_ioremap.c: In function ?early_memremap?:
> mm/early_ioremap.c:220:1: warning: control reaches end of non-void
> function [-Wreturn-type]
> mm/early_ioremap.c: In function ?early_ioremap?:
> mm/early_ioremap.c:212:1: warning: control reaches end of non-void
> function [-Wreturn-type]
> make[1]: *** [mm/early_ioremap.o] Error 1
> make: *** [mm] Error 2
> make: *** Waiting for unfinished jobs....
>   CC      arch/arm/mm/mmu.o
>   CC      arch/arm/kernel/patch.o
> arch/arm/kernel/patch.c: In function ?patch_map?:
> arch/arm/kernel/patch.c:39:2: error: incompatible type for argument 3
> of ?__set_fixmap?
> ./arch/arm/include/asm/fixmap.h:55:6: note: expected ?pgprot_t? but
> argument is of type ?long long unsigned int?
> make[1]: *** [arch/arm/kernel/patch.o] Error 1
> 
> Fixes Commit a5f4c561b ("ARM: 8415/1: early fixmap support for earlycon").
> 
> Annotate the page flags properly using __pgprot.

Acked-by: Stefan Agner <stefan at agner.ch>

--
Stefan

> 
> Cc: Stefan Agner <stefan at agner.ch>
> Cc: Arnd Bergmann <arnd at arndb.de>
> Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> Cc: Rob Herring <robh at kernel.org>
> Cc: Russell King <rmk+kernel at arm.linux.org.uk>
> Cc: stable at vger.kernel.org	# v4.3+
> Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
> ---
>  arch/arm/include/asm/fixmap.h |    8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
> index 5c17d2d..8d48d5a 100644
> --- a/arch/arm/include/asm/fixmap.h
> +++ b/arch/arm/include/asm/fixmap.h
> @@ -39,13 +39,13 @@ static const enum fixed_addresses __end_of_fixed_addresses =
>  	__end_of_fixmap_region > __end_of_early_ioremap_region ?
>  	__end_of_fixmap_region : __end_of_early_ioremap_region;
>  
> -#define FIXMAP_PAGE_COMMON	(L_PTE_YOUNG | L_PTE_PRESENT | L_PTE_XN |
> L_PTE_DIRTY)
> +#define FIXMAP_PAGE_COMMON	__pgprot(L_PTE_YOUNG | L_PTE_PRESENT |
> L_PTE_XN | L_PTE_DIRTY)
>  
> -#define FIXMAP_PAGE_NORMAL	(FIXMAP_PAGE_COMMON | L_PTE_MT_WRITEBACK)
> -#define FIXMAP_PAGE_RO		(FIXMAP_PAGE_NORMAL | L_PTE_RDONLY)
> +#define FIXMAP_PAGE_NORMAL	__pgprot(pgprot_val(FIXMAP_PAGE_COMMON) |
> L_PTE_MT_WRITEBACK)
> +#define FIXMAP_PAGE_RO		__pgprot(pgprot_val(FIXMAP_PAGE_NORMAL) | L_PTE_RDONLY)
>  
>  /* Used by set_fixmap_(io|nocache), both meant for mapping a device */
> -#define FIXMAP_PAGE_IO		(FIXMAP_PAGE_COMMON | L_PTE_MT_DEV_SHARED |
> L_PTE_SHARED)
> +#define FIXMAP_PAGE_IO		__pgprot(pgprot_val(FIXMAP_PAGE_COMMON) |
> L_PTE_MT_DEV_SHARED | L_PTE_SHARED)
>  #define FIXMAP_PAGE_NOCACHE	FIXMAP_PAGE_IO
>  
>  #define __early_set_fixmap	__set_fixmap


From computersforpeace at gmail.com  Thu Feb 25 10:31:39 2016
From: computersforpeace at gmail.com (Brian Norris)
Date: Thu, 25 Feb 2016 10:31:39 -0800
Subject: [PATCH v3] mtd: atmel_nand: move the hsmc_clk from nfc node to
 nand node
In-Reply-To: <56CC393B.6090801@atmel.com>
References: <1456207220-7757-1-git-send-email-wenyou.yang@atmel.com>
 <56CC393B.6090801@atmel.com>
Message-ID: <20160225183139.GL21465@google.com>

+ devicetree, Boris

Convenient you left devicetree off, since I expect you'd get a hearty NAK
from them...

On Tue, Feb 23, 2016 at 11:49:31AM +0100, Nicolas Ferre wrote:
> Le 23/02/2016 07:00, Wenyou Yang a ?crit :
> > From: Josh Wu <josh.wu at atmel.com>
> > 
> > For SAMA5D3, SAMA5D4 SoC family, PMECC becomes a part of HSMC, they
> > need the HSMC clock enabled to work.
> > The NFC is a sub feature for current nand driver, it can be disabled.
> > But if HSMC clock is controlled by NFC, so disable NFC will also disable
> > the HSMC clock. then, it will make the PMECC fail to work.
> > 
> > So the solution is move the HSMC clock out of NFC to nand node. When
> > nand driver probed, it will check whether the chip has HSMC, if yes then
> > it will require a HSMC clock.
> > 
> > Add a new "atmel,sama5d3-nand" compatiable string for SAMA5D3's nand.
> > 
> > Signed-off-by: Josh Wu <josh.wu at atmel.com>
> > Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> > ---
> > 
> > Changes in v3:
> >  - add "atmel,sama5d3-nand" compatiable string for SAMA5D3's nand.
> >  - revert the mail address of Josh's Signed-off to the original.
> 
> It seems okay now:
> Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> 
> Brian, can we take this patch (if you acknowledged it) with us (through
> the arm-soc tree) to keep the synchronization with the DT part of this work?
> I will also consider squashing the DT part in this one as well as they
> cannot be separated.

Doesn't that mean you have an illegal breakage of the device tree?

Also, if you're going to refactor the binding (and possibly even break
it like this), why don't you address the comments Boris made back on the
first version about a year ago?

http://patchwork.ozlabs.org/patch/438211/

Particularly, I agree that you seem to have the sub-node relationship
all backward. Why is the controller a sub-node of the flash node? And
you have no provision for multiple NAND chips?

Brian

> Bye,
> 
> > Changes in v2:
> >  - add missing .has_hsmc_clk assignment for sama5d2_caps.
> > 
> >  .../devicetree/bindings/mtd/atmel-nand.txt         |    4 +-
> >  drivers/mtd/nand/atmel_nand.c                      |   51 +++++++++++---------
> >  2 files changed, 30 insertions(+), 25 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > index d53aba9..29bee7c 100644
> > --- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > +++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > @@ -15,6 +15,7 @@ Required properties:
> >  - atmel,nand-cmd-offset : offset for the command latch.
> >  - #address-cells, #size-cells : Must be present if the device has sub-nodes
> >    representing partitions.
> > +- clocks: phandle to the peripheral clock
> >  
> >  - gpios : specifies the gpio pins to control the NAND device. detect is an
> >    optional gpio and may be set to 0 if not present.
> > @@ -43,7 +44,6 @@ Required properties:
> >  - reg : should specify the address and size used for NFC command registers,
> >          NFC registers and NFC SRAM. NFC SRAM address and size can be absent
> >          if don't want to use it.
> > -- clocks: phandle to the peripheral clock
> >  Optional properties:
> >  - atmel,write-by-sram: boolean to enable NFC write by SRAM.
> >  
> > @@ -100,13 +100,13 @@ nand0: nand at 40000000 {
> >  	compatible = "atmel,at91rm9200-nand";
> >  	#address-cells = <1>;
> >  	#size-cells = <1>;
> > +	clocks = <&hsmc_clk>
> >  	ranges;
> >          ...
> >          nfc at 70000000 {
> >  		compatible = "atmel,sama5d3-nfc";
> >  		#address-cells = <1>;
> >  		#size-cells = <1>;
> > -		clocks = <&hsmc_clk>
> >  		reg = <
> >  			0x70000000 0x10000000	/* NFC Command Registers */
> >  			0xffffc000 0x00000070	/* NFC HSMC regs */
> > diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
> > index 20cbaab..482251c 100644
> > --- a/drivers/mtd/nand/atmel_nand.c
> > +++ b/drivers/mtd/nand/atmel_nand.c
> > @@ -66,6 +66,7 @@ module_param(on_flash_bbt, int, 0);
> >  struct atmel_nand_caps {
> >  	bool pmecc_correct_erase_page;
> >  	uint8_t pmecc_max_correction;
> > +	bool has_hsmc_clk;
> >  };
> >  
> >  struct atmel_nand_nfc_caps {
> > @@ -106,8 +107,6 @@ struct atmel_nfc {
> >  	bool			use_nfc_sram;
> >  	bool			write_by_sram;
> >  
> > -	struct clk		*clk;
> > -
> >  	bool			is_initialized;
> >  	struct completion	comp_ready;
> >  	struct completion	comp_cmd_done;
> > @@ -132,6 +131,7 @@ struct atmel_nand_host {
> >  	struct dma_chan		*dma_chan;
> >  
> >  	struct atmel_nfc	*nfc;
> > +	struct clk		*clk;
> >  
> >  	const struct atmel_nand_caps	*caps;
> >  	bool			has_pmecc;
> > @@ -2157,6 +2157,19 @@ static int atmel_nand_probe(struct platform_device *pdev)
> >  	nand_chip->IO_ADDR_R = host->io_base;
> >  	nand_chip->IO_ADDR_W = host->io_base;
> >  
> > +	if (host->caps->has_hsmc_clk) {
> > +		host->clk = devm_clk_get(&pdev->dev, NULL);
> > +		if (IS_ERR(host->clk)) {
> > +			dev_err(&pdev->dev, "HSMC clock is missing, update your Device Tree");
> > +			res = PTR_ERR(host->clk);
> > +			goto err_nand_ioremap;
> > +		}
> > +
> > +		res = clk_prepare_enable(host->clk);
> > +		if (res)
> > +			goto err_nand_ioremap;
> > +	}
> > +
> >  	if (nand_nfc.is_initialized) {
> >  		/* NFC driver is probed and initialized */
> >  		host->nfc = &nand_nfc;
> > @@ -2321,6 +2334,9 @@ static int atmel_nand_remove(struct platform_device *pdev)
> >  	if (host->dma_chan)
> >  		dma_release_channel(host->dma_chan);
> >  
> > +	if (!IS_ERR(host->clk))
> > +		clk_disable_unprepare(host->clk);
> > +
> >  	platform_driver_unregister(&atmel_nand_nfc_driver);
> >  
> >  	return 0;
> > @@ -2334,11 +2350,19 @@ static int atmel_nand_remove(struct platform_device *pdev)
> >  static const struct atmel_nand_caps at91rm9200_caps = {
> >  	.pmecc_correct_erase_page = false,
> >  	.pmecc_max_correction = 24,
> > +	.has_hsmc_clk = false,
> > +};
> > +
> > +static struct atmel_nand_caps sama5d3_caps = {
> > +	.pmecc_correct_erase_page = false,
> > +	.pmecc_max_correction = 24,
> > +	.has_hsmc_clk = true,
> >  };
> >  
> >  static const struct atmel_nand_caps sama5d4_caps = {
> >  	.pmecc_correct_erase_page = true,
> >  	.pmecc_max_correction = 24,
> > +	.has_hsmc_clk = true,
> >  };
> >  
> >  /*
> > @@ -2348,11 +2372,13 @@ static const struct atmel_nand_caps sama5d4_caps = {
> >  static const struct atmel_nand_caps sama5d2_caps = {
> >  	.pmecc_correct_erase_page = true,
> >  	.pmecc_max_correction = 32,
> > +	.has_hsmc_clk = true,
> >  };
> >  
> >  static const struct of_device_id atmel_nand_dt_ids[] = {
> >  	{ .compatible = "atmel,at91rm9200-nand", .data = &at91rm9200_caps },
> >  	{ .compatible = "atmel,sama5d4-nand", .data = &sama5d4_caps },
> > +	{ .compatible = "atmel,sama5d3-nand", .data = &sama5d3_caps },
> >  	{ .compatible = "atmel,sama5d2-nand", .data = &sama5d2_caps },
> >  	{ /* sentinel */ }
> >  };
> > @@ -2363,7 +2389,6 @@ static int atmel_nand_nfc_probe(struct platform_device *pdev)
> >  {
> >  	struct atmel_nfc *nfc = &nand_nfc;
> >  	struct resource *nfc_cmd_regs, *nfc_hsmc_regs, *nfc_sram;
> > -	int ret;
> >  
> >  	nfc_cmd_regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >  	nfc->base_cmd_regs = devm_ioremap_resource(&pdev->dev, nfc_cmd_regs);
> > @@ -2401,31 +2426,12 @@ static int atmel_nand_nfc_probe(struct platform_device *pdev)
> >  	nfc_writel(nfc->hsmc_regs, IDR, 0xffffffff);
> >  	nfc_readl(nfc->hsmc_regs, SR);	/* clear the NFC_SR */
> >  
> > -	nfc->clk = devm_clk_get(&pdev->dev, NULL);
> > -	if (!IS_ERR(nfc->clk)) {
> > -		ret = clk_prepare_enable(nfc->clk);
> > -		if (ret)
> > -			return ret;
> > -	} else {
> > -		dev_warn(&pdev->dev, "NFC clock missing, update your Device Tree");
> > -	}
> > -
> >  	nfc->is_initialized = true;
> >  	dev_info(&pdev->dev, "NFC is probed.\n");
> >  
> >  	return 0;
> >  }
> >  
> > -static int atmel_nand_nfc_remove(struct platform_device *pdev)
> > -{
> > -	struct atmel_nfc *nfc = &nand_nfc;
> > -
> > -	if (!IS_ERR(nfc->clk))
> > -		clk_disable_unprepare(nfc->clk);
> > -
> > -	return 0;
> > -}
> > -
> >  static const struct atmel_nand_nfc_caps sama5d3_nfc_caps = {
> >  	.rb_mask = NFC_SR_RB_EDGE0,
> >  };
> > @@ -2447,7 +2453,6 @@ static struct platform_driver atmel_nand_nfc_driver = {
> >  		.of_match_table = of_match_ptr(atmel_nand_nfc_match),
> >  	},
> >  	.probe = atmel_nand_nfc_probe,
> > -	.remove = atmel_nand_nfc_remove,
> >  };
> >  
> >  static struct platform_driver atmel_nand_driver = {
> > 
> 
> 
> -- 
> Nicolas Ferre


From slemieux.tyco at gmail.com  Thu Feb 25 10:31:36 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Thu, 25 Feb 2016 13:31:36 -0500
Subject: [PATCH v4 2/6] watchdog: pnx4008: add restart handler
In-Reply-To: <1456425100-28136-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456425100-28136-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456425100-28136-3-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Add restart handler capability to the driver;
the restart handler implementation was taken from
"mach-lpc32xx" ("lpc23xx_restart" function).

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Changes from v3 to v4:
- none.

Changes from v2 to v3:
- remove explicit clock enable from restart handler.
- verify "register_restart_handler" return value.
- add call to unregister_restart_handler".
- do the restart handling directly in "pnx4008_restart_handler".

Changes from v1 to v2:
- new patch in v2.

 drivers/watchdog/pnx4008_wdt.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
index 88264a2..80ee4af 100644
--- a/drivers/watchdog/pnx4008_wdt.c
+++ b/drivers/watchdog/pnx4008_wdt.c
@@ -31,6 +31,8 @@
 #include <linux/slab.h>
 #include <linux/err.h>
 #include <linux/of.h>
+#include <linux/delay.h>
+#include <linux/reboot.h>
 #include <mach/hardware.h>
 
 /* WatchDog Timer - Chapter 23 Page 207 */
@@ -77,6 +79,7 @@
 
 static bool nowayout = WATCHDOG_NOWAYOUT;
 static unsigned int heartbeat = DEFAULT_HEARTBEAT;
+static struct notifier_block restart_handler;
 
 static DEFINE_SPINLOCK(io_lock);
 static void __iomem	*wdt_base;
@@ -124,6 +127,19 @@ static int pnx4008_wdt_set_timeout(struct watchdog_device *wdd,
 	return 0;
 }
 
+static int pnx4008_restart_handler(struct notifier_block *this,
+				   unsigned long mode, void *cmd)
+{
+	/* Instant assert of RESETOUT_N with pulse length 1mS */
+	writel(13000, WDTIM_PULSE(wdt_base));
+	writel(M_RES2 | RESFRC1 | RESFRC2, WDTIM_MCTRL(wdt_base));
+
+	/* Wait for watchdog to reset system */
+	mdelay(1000);
+
+	return NOTIFY_DONE;
+}
+
 static const struct watchdog_info pnx4008_wdt_ident = {
 	.options = WDIOF_CARDRESET | WDIOF_MAGICCLOSE |
 	    WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
@@ -157,6 +173,15 @@ static int pnx4008_wdt_probe(struct platform_device *pdev)
 	if (IS_ERR(wdt_base))
 		return PTR_ERR(wdt_base);
 
+	/* Register restart handler. */
+	restart_handler.notifier_call = pnx4008_restart_handler;
+	restart_handler.priority = 128;
+	ret = register_restart_handler(&restart_handler);
+	if (ret) {
+		dev_warn(&pdev->dev, "cannot register restart handler\n");
+		return ret;
+	}
+
 	wdt_clk = devm_clk_get(&pdev->dev, NULL);
 	if (IS_ERR(wdt_clk))
 		return PTR_ERR(wdt_clk);
@@ -189,6 +214,7 @@ disable_clk:
 
 static int pnx4008_wdt_remove(struct platform_device *pdev)
 {
+	unregister_restart_handler(&restart_handler);
 	watchdog_unregister_device(&pnx4008_wdd);
 
 	clk_disable_unprepare(wdt_clk);
-- 
1.8.3.1



From slemieux.tyco at gmail.com  Thu Feb 25 10:31:34 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Thu, 25 Feb 2016 13:31:34 -0500
Subject: [PATCH v4 0/6] watchdog: pnx4008: add restart handler
Message-ID: <1456425100-28136-1-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

The LPC32xx provide the capability to perform a soft or hard reset;
a soft reset will no reset the external peripheral
(i.e. RESOUT_N output not asserted).

This changeset migrate the restart code from the "mach-lpc32xx" to
the "pnx-4008" watchdog driver and add the soft reset capability.

The default behavior (i.e. hard reset) remain unchanged.

The core restart handler support added by this change:
2165bf524da5f5e496d - "watchdog: core: add restart handler support"
is not use in this changeset; it does not support the reboot mode.

Note:
Patch #5 was generated with the option "--unified=2" to ensure
it can be apply before or after the changes for the new 
LPC32xx irqchip driver:
- http://permalink.gmane.org/gmane.linux.drivers.devicetree/144683
---
Changes from v3 to v4:
* Update the patch as per the feedback received from:
  Arnd: http://permalink.gmane.org/gmane.linux.watchdog/3329
  - Switch patch #5 and #6 order.

Changes from v2 to v3:
* Update the patch as per the feedback received from:
  Joachim: http://permalink.gmane.org/gmane.linux.watchdog/3303
  - remove explicit clock enable from restart handler.
  - verify "register_restart_handler" return value.
  - add call to unregister_restart_handler".
  - do the restart handling directly in "pnx4008_restart_handler".
* Move the change to "phy3250.c" into a separate patch and generate
  the new patch with the "--unified=2" option.

Changes from v1 to v2:
* Rename patch title;
  was "arm: lpc32xx: restart: add support for soft reset"
* Update the patch as per the feedback received from:
  Joachim: http://permalink.gmane.org/gmane.linux.ports.arm.kernel/479791
  - migrate restart code from "mach-lpc32xx" to "pnx-4008" driver.
* Add soft reset support to "pnx-4008" driver instead of "mach-lpc32xx".
* Use define available in "pnx-4008" when writting to watchdog register.
* Remove restart handler from "mach-lpc32xx".
* Remove restart hook from "phy3250.c".
* Update driver logging during power-on. 

Sylvain Lemieux (6):
  watchdog: pnx4008: update logging during power-on
  watchdog: pnx4008: add restart handler
  watchdog: pnx4008: add support for soft reset
  watchdog: pnx4008: restart: support "cmd" from userspace
  arm: lpc32xx: phy3250 remove restart hook
  arm: lpc32xx: remove restart handler

 arch/arm/mach-lpc32xx/common.c  | 15 ------------
 arch/arm/mach-lpc32xx/common.h  |  1 -
 arch/arm/mach-lpc32xx/phy3250.c |  1 -
 drivers/watchdog/pnx4008_wdt.c  | 51 +++++++++++++++++++++++++++++++++++++++--
 4 files changed, 49 insertions(+), 19 deletions(-)

-- 
1.8.3.1



From slemieux.tyco at gmail.com  Thu Feb 25 10:31:35 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Thu, 25 Feb 2016 13:31:35 -0500
Subject: [PATCH v4 1/6] watchdog: pnx4008: update logging during power-on
In-Reply-To: <1456425100-28136-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456425100-28136-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456425100-28136-2-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

There is no need add the driver name in the text to display
on the console during the power-on:
pnx4008-watchdog 4003c000.watchdog: PNX4008 Watchdog Timer: heartbeat 19 sec

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Changes from v3 to v4:
- none.

Changes from v2 to v3:
- none.

Changes from v1 to v2:
- new patch in v2.

 drivers/watchdog/pnx4008_wdt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
index 313cd1c..88264a2 100644
--- a/drivers/watchdog/pnx4008_wdt.c
+++ b/drivers/watchdog/pnx4008_wdt.c
@@ -178,8 +178,7 @@ static int pnx4008_wdt_probe(struct platform_device *pdev)
 		goto disable_clk;
 	}
 
-	dev_info(&pdev->dev, "PNX4008 Watchdog Timer: heartbeat %d sec\n",
-		 pnx4008_wdd.timeout);
+	dev_info(&pdev->dev, "heartbeat %d sec\n", pnx4008_wdd.timeout);
 
 	return 0;
 
-- 
1.8.3.1



From slemieux.tyco at gmail.com  Thu Feb 25 10:31:37 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Thu, 25 Feb 2016 13:31:37 -0500
Subject: [PATCH v4 3/6] watchdog: pnx4008: add support for soft reset
In-Reply-To: <1456425100-28136-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456425100-28136-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456425100-28136-4-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Add support for explicit soft reset using the reboot mode.

The default reboot mode behavior is unchanged;
you can overwrite the default reboot type in the board specific file
"DT_MACHINE_START" definition using the "reboot_mode" parameter.

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Changes from v3 to v4:
- none.

Changes from v2 to v3:
- no logical change; updated to work with new revision of patch #2.

Changes from v1 to v2:
- Rename patch title;
  was "arm: lpc32xx: restart: add support for soft reset"
- Add change to "pnx-4008" driver instead of "mach-lpc32xx".
- Use define available in "pnx-4008" when writting to watchdog register.

 drivers/watchdog/pnx4008_wdt.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
index 80ee4af..fbf027e 100644
--- a/drivers/watchdog/pnx4008_wdt.c
+++ b/drivers/watchdog/pnx4008_wdt.c
@@ -130,9 +130,16 @@ static int pnx4008_wdt_set_timeout(struct watchdog_device *wdd,
 static int pnx4008_restart_handler(struct notifier_block *this,
 				   unsigned long mode, void *cmd)
 {
-	/* Instant assert of RESETOUT_N with pulse length 1mS */
-	writel(13000, WDTIM_PULSE(wdt_base));
-	writel(M_RES2 | RESFRC1 | RESFRC2, WDTIM_MCTRL(wdt_base));
+	if (mode == (unsigned long)REBOOT_SOFT) {
+		/* Force match output active */
+		writel(EXT_MATCH0, WDTIM_EMR(wdt_base));
+		/* Internal reset on match output (RESOUT_N not asserted) */
+		writel(M_RES1, WDTIM_MCTRL(wdt_base));
+	} else {
+		/* Instant assert of RESETOUT_N with pulse length 1mS */
+		writel(13000, WDTIM_PULSE(wdt_base));
+		writel(M_RES2 | RESFRC1 | RESFRC2, WDTIM_MCTRL(wdt_base));
+	}
 
 	/* Wait for watchdog to reset system */
 	mdelay(1000);
-- 
1.8.3.1



From slemieux.tyco at gmail.com  Thu Feb 25 10:31:39 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Thu, 25 Feb 2016 13:31:39 -0500
Subject: [PATCH v4 5/6] arm: lpc32xx: phy3250 remove restart hook
In-Reply-To: <1456425100-28136-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456425100-28136-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456425100-28136-6-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Remove the restart hook assignment from phy3250;
this functionality is now managed by
the pnx4008 watchdog driver.

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Note:
This patch was generated with the option "--unified=2" to ensure
it can be apply before or after the changes for the new 
LPC32xx irqchip driver:
- http://permalink.gmane.org/gmane.linux.drivers.devicetree/144683

Changes from v3 to v4:
- Switch patch #5 and #6 order.

Changes from v2 to v3:
- new patch in v3.

 arch/arm/mach-lpc32xx/phy3250.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-lpc32xx/phy3250.c b/arch/arm/mach-lpc32xx/phy3250.c
index a19071a..9e5c3db 100644
--- a/arch/arm/mach-lpc32xx/phy3250.c
+++ b/arch/arm/mach-lpc32xx/phy3250.c
@@ -211,4 +211,3 @@ DT_MACHINE_START(LPC32XX_DT, "LPC32XX SoC (Flattened Device Tree)")
 	.init_machine	= lpc3250_machine_init,
 	.dt_compat	= lpc32xx_dt_compat,
-	.restart	= lpc23xx_restart,
 MACHINE_END
-- 
1.8.3.1



From slemieux.tyco at gmail.com  Thu Feb 25 10:31:38 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Thu, 25 Feb 2016 13:31:38 -0500
Subject: [PATCH v4 4/6] watchdog: pnx4008: restart: support "cmd" from
 userspace
In-Reply-To: <1456425100-28136-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456425100-28136-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456425100-28136-5-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Added support to verify if a "cmd" is passed from the userspace program rebooting the system;
- if a valid "cmd" is available, handle it;
- If the received "cmd" is not supported, use the default reboot mode.

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Changes from v3 to v4:
- none.

Changes from v2 to v3:
- no logical change; updated to work with new revision of patch #2.

Changes from v1 to v2:
- Rename patch title;
  was "arm: lpc32xx: restart: support "cmd" from userspace"
- Add change to "pnx-4008" driver instead of "mach-lpc32xx".

 drivers/watchdog/pnx4008_wdt.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
index fbf027e..e97b611 100644
--- a/drivers/watchdog/pnx4008_wdt.c
+++ b/drivers/watchdog/pnx4008_wdt.c
@@ -130,6 +130,21 @@ static int pnx4008_wdt_set_timeout(struct watchdog_device *wdd,
 static int pnx4008_restart_handler(struct notifier_block *this,
 				   unsigned long mode, void *cmd)
 {
+	const char *boot_cmd = (const char *)cmd;
+
+	/*
+	 * Verify if a "cmd" passed from the userspace program rebooting
+	 * the system; if available, handle it.
+	 * - For details, see the 'reboot' syscall in kernel/reboot.c
+	 * - If the received "cmd" is not supported, use the default mode.
+	 */
+	if (boot_cmd) {
+		if (boot_cmd[0] == 'h')
+			mode = (unsigned long)REBOOT_HARD;
+		else if (boot_cmd[0] == 's')
+			mode = (unsigned long)REBOOT_SOFT;
+	}
+
 	if (mode == (unsigned long)REBOOT_SOFT) {
 		/* Force match output active */
 		writel(EXT_MATCH0, WDTIM_EMR(wdt_base));
-- 
1.8.3.1



From slemieux.tyco at gmail.com  Thu Feb 25 10:31:40 2016
From: slemieux.tyco at gmail.com (Sylvain Lemieux)
Date: Thu, 25 Feb 2016 13:31:40 -0500
Subject: [PATCH v4 6/6] arm: lpc32xx: remove restart handler
In-Reply-To: <1456425100-28136-1-git-send-email-slemieux.tyco@gmail.com>
References: <1456425100-28136-1-git-send-email-slemieux.tyco@gmail.com>
Message-ID: <1456425100-28136-7-git-send-email-slemieux.tyco@gmail.com>

From: Sylvain Lemieux <slemieux at tycoint.com>

Remove the restart handler from "mach-lpc32xx";
this functionality is now available in the
pnx4008 watchdog driver.

Signed-off-by: Sylvain Lemieux <slemieux at tycoint.com>
---
Changes from v3 to v4:
- Switch patch #5 and #6 order.

Changes from v2 to v3:
- move the change to "phy3250.c" into a separate patch.

Changes from v1 to v2:
- new patch in v2.

 arch/arm/mach-lpc32xx/common.c | 15 ---------------
 arch/arm/mach-lpc32xx/common.h |  1 -
 2 files changed, 16 deletions(-)

diff --git a/arch/arm/mach-lpc32xx/common.c b/arch/arm/mach-lpc32xx/common.c
index 716e83e..5b7a1e7 100644
--- a/arch/arm/mach-lpc32xx/common.c
+++ b/arch/arm/mach-lpc32xx/common.c
@@ -194,21 +194,6 @@ void __init lpc32xx_map_io(void)
 	iotable_init(lpc32xx_io_desc, ARRAY_SIZE(lpc32xx_io_desc));
 }
 
-void lpc23xx_restart(enum reboot_mode mode, const char *cmd)
-{
-	/* Make sure WDT clocks are enabled */
-	__raw_writel(LPC32XX_CLKPWR_PWMCLK_WDOG_EN,
-		LPC32XX_CLKPWR_TIMER_CLK_CTRL);
-
-	/* Instant assert of RESETOUT_N with pulse length 1mS */
-	__raw_writel(13000, io_p2v(LPC32XX_WDTIM_BASE + 0x18));
-	__raw_writel(0x70, io_p2v(LPC32XX_WDTIM_BASE + 0xC));
-
-	/* Wait for watchdog to reset system */
-	while (1)
-		;
-}
-
 static int __init lpc32xx_check_uid(void)
 {
 	u32 uid[4];
diff --git a/arch/arm/mach-lpc32xx/common.h b/arch/arm/mach-lpc32xx/common.h
index 1cd8853..2d90801 100644
--- a/arch/arm/mach-lpc32xx/common.h
+++ b/arch/arm/mach-lpc32xx/common.h
@@ -30,7 +30,6 @@ extern void lpc32xx_timer_init(void);
 extern void __init lpc32xx_init_irq(void);
 extern void __init lpc32xx_map_io(void);
 extern void __init lpc32xx_serial_init(void);
-extern void lpc23xx_restart(enum reboot_mode, const char *);
 
 
 /*
-- 
1.8.3.1



From manabian at gmail.com  Thu Feb 25 10:32:55 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Thu, 25 Feb 2016 19:32:55 +0100
Subject: [PATCH] pinctrl: lpc18xx: ensure ngroups is initialized at
 correct place
In-Reply-To: <1456335170-20718-1-git-send-email-colin.king@canonical.com>
References: <1456335170-20718-1-git-send-email-colin.king@canonical.com>
Message-ID: <CAGhQ9VykdYLA-ey2pzDVtccLPZvHNYLzmLHKyOnKr2TLLV+2yA@mail.gmail.com>

Hi Colin,

On 24 February 2016 at 18:32, Colin King <colin.king at canonical.com> wrote:
> From: Colin Ian King <colin.king at canonical.com>
>
> The initialization of ngroups is occurring at the end of the
> first iteration of the outer loop, which means that the
> assignment  pins[ngroups++] = i is potentially indexing into
> a region outside of array pins because ngroups is not initialized.
> Instead, initialize ngroups in the inner loop before the first
> inner loop iteration.
>
> Signed-off-by: Colin Ian King <colin.king at canonical.com>
> ---
>  drivers/pinctrl/pinctrl-lpc18xx.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-lpc18xx.c b/drivers/pinctrl/pinctrl-lpc18xx.c
> index f0bebbe..ed1cfa7 100644
> --- a/drivers/pinctrl/pinctrl-lpc18xx.c
> +++ b/drivers/pinctrl/pinctrl-lpc18xx.c
> @@ -1170,9 +1170,8 @@ static int lpc18xx_create_group_func_map(struct device *dev,
>         u16 pins[ARRAY_SIZE(lpc18xx_pins)];
>         int func, ngroups, i;
>
> -       for (func = 0; func < FUNC_MAX; ngroups = 0, func++) {
> -
> -               for (i = 0; i < ARRAY_SIZE(lpc18xx_pins); i++) {
> +       for (func = 0; func < FUNC_MAX; func++) {
> +               for (ngroups = 0, i = 0; i < ARRAY_SIZE(lpc18xx_pins); i++) {

Good catch!

Reviewed-by: Joachim Eastwood <manabian at gmail.com>


regards,
Joachim Eastwood


From eric at anholt.net  Thu Feb 25 10:41:00 2016
From: eric at anholt.net (Eric Anholt)
Date: Thu, 25 Feb 2016 10:41:00 -0800
Subject: [PATCH 4/5] ARM: bcm2835: Add a group for mapping pins 48-53 to
 sdhost.
In-Reply-To: <1456425661-26123-1-git-send-email-eric@anholt.net>
References: <1456425661-26123-1-git-send-email-eric@anholt.net>
Message-ID: <1456425661-26123-5-git-send-email-eric@anholt.net>

This pin group definition comes from downstream.  We don't have a
driver for sdhost integrated yet, but they've been experimenting with
it and it sounds useful to bring over.

Signed-off-by: Eric Anholt <eric at anholt.net>
---
 arch/arm/boot/dts/bcm283x.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 70a6814..0bb32cc 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -191,6 +191,10 @@
 				brcm,pins = <45>;
 				brcm,function = <BCM2835_FSEL_ALT0>;
 			};
+			sdhost_gpio48: sdhost_gpio48 {
+				brcm,pins = <48 49 50 51 52 53>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
 			i2c0_gpio44: i2c0_gpio44 {
 				brcm,pins = <44 45>;
 				brcm,function = <BCM2835_FSEL_ALT1>;
-- 
2.7.0



From eric at anholt.net  Thu Feb 25 10:41:01 2016
From: eric at anholt.net (Eric Anholt)
Date: Thu, 25 Feb 2016 10:41:01 -0800
Subject: [PATCH 5/5] ARM: bcm2835: Move most RPi default pin groups to their
 devices.
In-Reply-To: <1456425661-26123-1-git-send-email-eric@anholt.net>
References: <1456425661-26123-1-git-send-email-eric@anholt.net>
Message-ID: <1456425661-26123-6-git-send-email-eric@anholt.net>

This way we can get the duplicated pin group definitions out of each
RPi board file, and just leave the i2s variations in them.

Signed-off-by: Eric Anholt <eric at anholt.net>
---
 arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 14 +++-----------
 arch/arm/boot/dts/bcm2835-rpi-a.dts      | 14 +++-----------
 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 14 +++-----------
 arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 14 +++-----------
 arch/arm/boot/dts/bcm2835-rpi-b.dts      | 12 ------------
 arch/arm/boot/dts/bcm2835-rpi.dtsi       | 20 ++++++++++++++++++++
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts    | 14 +++-----------
 7 files changed, 35 insertions(+), 67 deletions(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
index 1db6835..a00cbbe 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
@@ -20,15 +20,7 @@
 	};
 };
 
-&gpio {
-	pinctrl-0 = <&i2c0_gpio0
-		     &i2c1_gpio2
-		     &gpclk0_gpio4
-		     &gpclk1_gpio5
-		     &spi0_gpio7
-		     &pcm_gpio18
-		     &pwm0_gpio40
-		     &pwm1_gpio45
-		     &emmc_gpio48
-		     &gpioout>;
+&i2s {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcm_gpio18>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a.dts b/arch/arm/boot/dts/bcm2835-rpi-a.dts
index 25d2114..23e6b6f 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a.dts
@@ -13,15 +13,7 @@
 	};
 };
 
-&gpio {
-	pinctrl-0 = <&i2c0_gpio0
-		     &i2c1_gpio2
-		     &gpclk0_gpio4
-		     &gpclk1_gpio5
-		     &spi0_gpio7
-		     &pcm_gpio28
-		     &pwm0_gpio40
-		     &pwm1_gpio45
-		     &emmc_gpio48
-		     &gpioout>;
+&i2s {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcm_gpio28>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index d8057b8..029b589 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -20,15 +20,7 @@
 	};
 };
 
-&gpio {
-	pinctrl-0 = <&i2c0_gpio0
-		     &i2c1_gpio2
-		     &gpclk0_gpio4
-		     &gpclk1_gpio5
-		     &spi0_gpio7
-		     &pcm_gpio18
-		     &pwm0_gpio40
-		     &pwm1_gpio45
-		     &emmc_gpio48
-		     &gpioout>;
+&i2s {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcm_gpio18>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
index e7dbff4..da1bc27 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
@@ -13,15 +13,7 @@
 	};
 };
 
-&gpio {
-	pinctrl-0 = <&i2c0_gpio0
-		     &i2c1_gpio2
-		     &gpclk0_gpio4
-		     &gpclk1_gpio5
-		     &spi0_gpio7
-		     &pcm_gpio28
-		     &pwm0_gpio40
-		     &pwm1_gpio45
-		     &emmc_gpio48
-		     &gpioout>;
+&i2s {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcm_gpio28>;
 };
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index d154049..df275d4 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -12,15 +12,3 @@
 		};
 	};
 };
-
-&gpio {
-	pinctrl-0 = <&i2c0_gpio0
-		     &i2c1_gpio2
-		     &gpclk0_gpio4
-		     &gpclk1_gpio5
-		     &spi0_gpio7
-		     &pwm0_gpio40
-		     &pwm1_gpio45
-		     &emmc_gpio48
-		     &gpioout>;
-};
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index eff27b0..b8efd41 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -31,6 +31,9 @@
 
 &gpio {
 	pinctrl-names = "default";
+	pinctrl-0 = <&gpclk0_gpio4
+		     &gpclk1_gpio5
+		     &gpioout>;
 
 	gpioout: gpioout {
 		brcm,pins = <6>;
@@ -39,11 +42,17 @@
 };
 
 &i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0_gpio0>;
+
 	status = "okay";
 	clock-frequency = <100000>;
 };
 
 &i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_gpio2>;
+
 	status = "okay";
 	clock-frequency = <100000>;
 };
@@ -53,14 +62,25 @@
 };
 
 &sdhci {
+	pinctrl-names = "default";
+	pinctrl-0 = <&emmc_gpio48>;
+
 	status = "okay";
 	bus-width = <4>;
 };
 
 &pwm {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm0_gpio40 &pwm1_gpio45>;
+
 	status = "okay";
 };
 
 &usb {
 	power-domains = <&power RPI_POWER_DOMAIN_USB>;
 };
+
+&spi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi0_gpio7>;
+};
diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index 3e9226f..ae2bc91 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -24,15 +24,7 @@
 	};
 };
 
-&gpio {
-	pinctrl-0 = <&i2c0_gpio0
-		     &i2c1_gpio2
-		     &gpclk0_gpio4
-		     &gpclk1_gpio5
-		     &spi0_gpio7
-		     &pcm_gpio18
-		     &pwm0_gpio40
-		     &pwm1_gpio45
-		     &emmc_gpio48
-		     &gpioout>;
+&i2s {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcm_gpio18>;
 };
-- 
2.7.0



From eric at anholt.net  Thu Feb 25 10:40:57 2016
From: eric at anholt.net (Eric Anholt)
Date: Thu, 25 Feb 2016 10:40:57 -0800
Subject: [PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the gpio
 node.
In-Reply-To: <1456425661-26123-1-git-send-email-eric@anholt.net>
References: <1456425661-26123-1-git-send-email-eric@anholt.net>
Message-ID: <1456425661-26123-2-git-send-email-eric@anholt.net>

The BCM2835-ARM-Peripherals.pdf documentation specifies what the
function selects do for the pins, and there are a bunch of obvious
groupings to be made.  With these created, we'll be able to replace
bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
references to specific groups we want enabled.

Signed-off-by: Eric Anholt <eric at anholt.net>
---
 arch/arm/boot/dts/bcm283x.dtsi | 170 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 170 insertions(+)

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 8aaf193..e91198e 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -110,6 +110,176 @@
 
 			interrupt-controller;
 			#interrupt-cells = <2>;
+
+			/* Defines pin muxing groups according to
+			 * BCM2835-ARM-Peripherals.pdf page 102.
+			 *
+			 * While each pin can have its mux selected
+			 * for various functions individually, some
+			 * groups only make sense to switch to a
+			 * particular function together.
+			 */
+			i2c0_gpio0: i2c0_gpio0 {
+				brcm,pins = <0 1>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			i2c1_gpio2: i2c1_gpio2 {
+				brcm,pins = <2 3>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			gpclk0_gpio4: gpclk0_gpio4 {
+				brcm,pins = <4>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			gpclk1_gpio5: gpclk1_gpio5 {
+				brcm,pins = <5>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			gpclk2_gpio6: gpclk2_gpio6 {
+				brcm,pins = <6>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			spi0_gpio7: spi0_gpio7 {
+				brcm,pins = <7 8 9 10 11>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			pwm0_gpio12: pwm0_gpio12 {
+				brcm,pins = <12>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			pwm1_gpio13: pwm1_gpio13 {
+				brcm,pins = <13>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			uart0_gpio14: uart0_gpio14 {
+				brcm,pins = <14 15>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			pcm_gpio18: pcm_gpio18 {
+				brcm,pins = <18 19 20 21>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			i2c0_gpio32: i2c0_gpio32 {
+				brcm,pins = <32 34>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			spio0_gpio35: spio0_gpio35 {
+				brcm,pins = <35 36 37 38 39>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			pwm0_gpio40: pwm0_gpio40 {
+				brcm,pins = <40>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			pwm1_gpio41: pwm1_gpio41 {
+				brcm,pins = <41>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			gpclk1_gpio42: gpclk1_gpio42 {
+				brcm,pins = <42>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			gpclk2_gpio43: gpclk2_gpio43 {
+				brcm,pins = <43>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			gpclk1_gpio44: gpclk1_gpio44 {
+				brcm,pins = <44>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			pwm1_gpio45: pwm1_gpio45 {
+				brcm,pins = <45>;
+				brcm,function = <BCM2835_FSEL_ALT0>;
+			};
+			i2c0_gpio44: i2c0_gpio44 {
+				brcm,pins = <44 45>;
+				brcm,function = <BCM2835_FSEL_ALT1>;
+			};
+			pcm_gpio28: pcm_gpio28 {
+				brcm,pins = <28 29 30 31>;
+				brcm,function = <BCM2835_FSEL_ALT2>;
+			};
+			uart1_gpio36: uart1_gpio36 {
+				brcm,pins = <36 37 38 39>;
+				brcm,function = <BCM2835_FSEL_ALT2>;
+			};
+			i2c1_gpio44: i2c1_gpio44 {
+				brcm,pins = <44 45>;
+				brcm,function = <BCM2835_FSEL_ALT2>;
+			};
+			/* Separate from the uart0_gpio14 group
+			 * because it conflicts with spi1_gpio16, and
+			 * people often run uart0 on the two pins
+			 * without flow contrl.
+			 */
+			uart0_ctsrts_gpio16: uart0_ctsrts_gpio16 {
+				brcm,pins = <16 17>;
+				brcm,function = <BCM2835_FSEL_ALT3>;
+			};
+			i2c_slave_gpio18: i2c_slave_gpio18 {
+				brcm,pins = <18 19 20 21>;
+				brcm,function = <BCM2835_FSEL_ALT3>;
+			};
+			emmc_gpio22: emmc_gpio22 {
+				brcm,pins = <22 23 24 25 26 27>;
+				brcm,function = <BCM2835_FSEL_ALT3>;
+			};
+			uart0_gpio30: uart0_gpio30 {
+				brcm,pins = <30 31>;
+				brcm,function = <BCM2835_FSEL_ALT3>;
+			};
+			uart0_ctsrts_gpio32: uart0_ctsrts_gpio32 {
+				brcm,pins = <32 33>;
+				brcm,function = <BCM2835_FSEL_ALT3>;
+			};
+			spi1_gpio16: spi1_gpio16 {
+				brcm,pins = <16 17 18 19 20 21>;
+				brcm,function = <BCM2835_FSEL_ALT4>;
+			};
+			jtag_gpio22: jtag_gpio22 {
+				brcm,pins = <22 23 24 25 26 27>;
+				brcm,function = <BCM2835_FSEL_ALT4>;
+			};
+			spi2_gpio40: spi2_gpio40 {
+				brcm,pins = <40 41 42 43 44 45>;
+				brcm,function = <BCM2835_FSEL_ALT4>;
+			};
+			jtag_gpio4: jtag_gpio4 {
+				brcm,pins = <4 5 6 12 13>;
+				brcm,function = <BCM2835_FSEL_ALT4>;
+			};
+			uart1_gpio14: uart1_gpio14 {
+				brcm,pins = <14 15>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
+			uart1_ctsrts_gpio16: uart1_ctsrts_gpio16 {
+				brcm,pins = <16 17>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
+			pwm0_gpio18: pwm0_gpio18 {
+				brcm,pins = <18>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
+			pwm1_gpio19: pwm1_gpio19 {
+				brcm,pins = <19>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
+			uart1_gpio32: uart1_gpio32 {
+				brcm,pins = <32 33>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
+			uart1_ctsrts_gpio30: uart1_ctsrts_gpio30 {
+				brcm,pins = <30 31>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
+			uart1_gpio40: uart1_gpio40 {
+				brcm,pins = <40 41>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
+			uart1_ctsrts_gpio42: uart1_ctsrts_gpio42 {
+				brcm,pins = <42 43>;
+				brcm,function = <BCM2835_FSEL_ALT5>;
+			};
 		};
 
 		uart0: serial at 7e201000 {
-- 
2.7.0



From maxime.ripard at free-electrons.com  Thu Feb 25 10:41:39 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Feb 2016 10:41:39 -0800
Subject: [PATCH] Add triggers for cubietruck leds
In-Reply-To: <1456304247-2481-1-git-send-email-henry@nitronetworks.nl>
References: <1456304247-2481-1-git-send-email-henry@nitronetworks.nl>
Message-ID: <20160225184139.GG4736@lukather>

Hi,

On Wed, Feb 24, 2016 at 09:57:25AM +0100, Henry Paulissen wrote:
> This (small) patch gives the same led trigger functionality
> as the 3.4 sunxi kernel and although mainline doesn't has
> to be the same, it helps in identifying and builds upon the
> user expectations about what those leds mean.
> 
> Signed-off-by: Henry Paulissen <henry at nitronetworks.nl>

We don't take these trigger patches because it should be left for the
user to decide, and everyone has a different opinion on that.

It's something that you can also very easily enforce from the
userspace through sysfs.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/01239aa6/attachment.sig>

From lorenzo.pieralisi at arm.com  Thu Feb 25 10:46:32 2016
From: lorenzo.pieralisi at arm.com (Lorenzo Pieralisi)
Date: Thu, 25 Feb 2016 18:46:32 +0000
Subject: [PATCH] drivers: perf: arm: implement CPU_PM notifier
In-Reply-To: <20160225164354.GE16546@arm.com>
References: <1456251759-24768-1-git-send-email-lorenzo.pieralisi@arm.com>
 <7hsi0hr3wj.fsf@baylibre.com> <20160225094417.GB31728@red-moon>
 <CANLsYkzq_oFLZ-ijBtxHp2rU=NR5R1PLb0znv2zPTv=4Z2isGA@mail.gmail.com>
 <20160225164354.GE16546@arm.com>
Message-ID: <20160225184632.GB5922@red-moon>

On Thu, Feb 25, 2016 at 04:43:54PM +0000, Will Deacon wrote:
> On Thu, Feb 25, 2016 at 09:32:17AM -0700, Mathieu Poirier wrote:
> > On 25 February 2016 at 02:44, Lorenzo Pieralisi
> > <lorenzo.pieralisi at arm.com> wrote:
> > > On Wed, Feb 24, 2016 at 05:10:20PM -0800, Kevin Hilman wrote:
> > >> Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> writes:
> > >>
> > >> > When a CPU is suspended (either through suspend-to-RAM or CPUidle),
> > >> > its PMU registers content can be lost, which means that counters
> > >> > registers values that were initialized on power down entry have to be
> > >> > reprogrammed on power-up to make sure the counters set-up is preserved
> > >>
> > >> This assumes that the PMUs are always sharing a power rail with a
> > >> specific CPU, not the cluster.  Is that a reliable assumption?
> > >
> > > As reliable as assuming the GIC HW state needs save/restore on idle-state
> > > entry, if we have no power domains information linked to CPU PM
> > > notifiers saving/restoring everything every time an idle state deeper
> > > than wfi is entered is the best we can do.
> > >
> > > As far as this patch is concerned, if the PMU is on a different power
> > > domain than the CPU, I agree that stopping/resetting/restoring the
> > > PMU registers is a waste of cycles (I will test it also by triggering
> > > the notifiers on wfi, to make sure the reset is not disruptive on
> > > a cpu that is not powered off), I see no alternative other than disabling
> > > idle to carry out profiling sanely (or implement CPU PM notifiers with
> > > runtime PM).
> > 
> > I totally understand - I'm faced with the same problem on Coresight.
> > To me the ultimate solution is still to integrate CPU power domain
> > management with runtime PM (like we talked about many times before).
> > I know Lina is working on something that will get us close to that but
> > it's not finished yet.
> 
> I've been waiting for that code for *years* now...
> 
> Ultimately, Juno-r2 loses its PMU state over idle if you run mainline
> on it and, worse still, you end up getting junk numbers back to userspace,
> so it's not even obvious what happened.

I hacked the idle driver to trigger notifiers on wfi (so PMU state is
kept intact on idle exit - to mimic idle states that do not destroy PMU
context) and still get some reasonable perf stats, this needs more testing
but it means that save/restore still work on idle states that do not destroy
PMU context (ok, we add a profile black out period between CPU PM entry and
exit, that can't be avoided).

> I'm not aware of any flags that indicate loss of state.

kvm notifier had to add a check (in hyp_init_cpu_pm_notifier()), since
restoring KVM hooks if the cpu was not reset triggers kernel errors,
point is, we need to have a hook (this is generic arm perf core, it has
to work on all arm pmus) that allows us detecting if a reset happened,
question is if we should bother (and if it is doable), given the test
above, I am happy to implement it.

I definitely agree it is time to fix this, it has been hanging in
the balance for too long.

Lorenzo


From maxime.ripard at free-electrons.com  Thu Feb 25 10:49:44 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Feb 2016 10:49:44 -0800
Subject: [PATCH v3 04/10] drivers: pinctrl: add driver for Allwinner A64
 SoC
In-Reply-To: <1456165255-31013-5-git-send-email-andre.przywara@arm.com>
References: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
 <1456165255-31013-5-git-send-email-andre.przywara@arm.com>
Message-ID: <20160225184944.GI4736@lukather>

Hi,

On Mon, Feb 22, 2016 at 06:20:49PM +0000, Andre Przywara wrote:
> Based on the Allwinner A64 user manual and on the previous sunxi
> pinctrl drivers this introduces the pin multiplex assignments for
> the ARMv8 Allwinner A64 SoC.
> Port A is apparently used for the fixed function DRAM controller, so
> the ports start at B here (the manual mentions "n from 1 to 7", so
> not starting at 0).
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
> Acked-by: Rob Herring <robh at kernel.org>

Acked-by: Maxime Ripard <maxime.ripard at free-electrons.com>

Linus, could you merge this patch for 4.6?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/f0ca1553/attachment-0001.sig>

From maxime.ripard at free-electrons.com  Thu Feb 25 10:52:02 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Feb 2016 10:52:02 -0800
Subject: [PATCH v3 10/10] arm64: add defconfig options for Allwinner SoCs
In-Reply-To: <1456165255-31013-11-git-send-email-andre.przywara@arm.com>
References: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
 <1456165255-31013-11-git-send-email-andre.przywara@arm.com>
Message-ID: <20160225185202.GJ4736@lukather>

On Mon, Feb 22, 2016 at 06:20:55PM +0000, Andre Przywara wrote:
> With the Allwinner platform now supported, enable it in the defconfig
> and add some options to give some decent out-of-the-box experience on
> those SoCs.
> 
> Signed-off-by: Andre Przywara <andre.przywara at arm.com>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/d891d8bc/attachment.sig>

From alexandre.belloni at free-electrons.com  Thu Feb 25 11:08:17 2016
From: alexandre.belloni at free-electrons.com (Alexandre Belloni)
Date: Thu, 25 Feb 2016 20:08:17 +0100
Subject: [PATCH v3] mtd: atmel_nand: move the hsmc_clk from nfc node to
 nand node
In-Reply-To: <20160225183139.GL21465@google.com>
References: <1456207220-7757-1-git-send-email-wenyou.yang@atmel.com>
 <56CC393B.6090801@atmel.com> <20160225183139.GL21465@google.com>
Message-ID: <20160225190817.GK12073@piout.net>

On 25/02/2016 at 10:31:39 -0800, Brian Norris wrote :
> + devicetree, Boris
> 
> Convenient you left devicetree off, since I expect you'd get a hearty NAK
> from them...
> 
> On Tue, Feb 23, 2016 at 11:49:31AM +0100, Nicolas Ferre wrote:
> > Le 23/02/2016 07:00, Wenyou Yang a ?crit :
> > > From: Josh Wu <josh.wu at atmel.com>
> > > 
> > > For SAMA5D3, SAMA5D4 SoC family, PMECC becomes a part of HSMC, they
> > > need the HSMC clock enabled to work.
> > > The NFC is a sub feature for current nand driver, it can be disabled.
> > > But if HSMC clock is controlled by NFC, so disable NFC will also disable
> > > the HSMC clock. then, it will make the PMECC fail to work.
> > > 
> > > So the solution is move the HSMC clock out of NFC to nand node. When
> > > nand driver probed, it will check whether the chip has HSMC, if yes then
> > > it will require a HSMC clock.
> > > 
> > > Add a new "atmel,sama5d3-nand" compatiable string for SAMA5D3's nand.
> > > 
> > > Signed-off-by: Josh Wu <josh.wu at atmel.com>
> > > Signed-off-by: Wenyou Yang <wenyou.yang at atmel.com>
> > > ---
> > > 
> > > Changes in v3:
> > >  - add "atmel,sama5d3-nand" compatiable string for SAMA5D3's nand.
> > >  - revert the mail address of Josh's Signed-off to the original.
> > 
> > It seems okay now:
> > Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
> > 
> > Brian, can we take this patch (if you acknowledged it) with us (through
> > the arm-soc tree) to keep the synchronization with the DT part of this work?
> > I will also consider squashing the DT part in this one as well as they
> > cannot be separated.
> 
> Doesn't that mean you have an illegal breakage of the device tree?
> 
> Also, if you're going to refactor the binding (and possibly even break
> it like this), why don't you address the comments Boris made back on the
> first version about a year ago?
> 
> http://patchwork.ozlabs.org/patch/438211/
> 
> Particularly, I agree that you seem to have the sub-node relationship
> all backward. Why is the controller a sub-node of the flash node? And
> you have no provision for multiple NAND chips?
> 

Yes, we plan to break that binding even more, we don't have much choice.
I would agree that it would be better to break it only once though.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From ard.biesheuvel at linaro.org  Thu Feb 25 11:10:42 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 25 Feb 2016 20:10:42 +0100
Subject: [PATCH] arm64: lse: deal with clobbered x16 register after branch via
 PLT
Message-ID: <1456427442-21023-1-git-send-email-ard.biesheuvel@linaro.org>

The LSE atomics implementation uses runtime patching to patch in calls
to out of line non-LSE atomics implementations on cores that lack hardware
support for LSE. To avoid paying the overhead cost of a function call even
if no call ends up being made, the bl instruction is kept invisible to the
compiler, and the out of line implementations preserve all registers, not
just the ones that they must preserve as per the AAPCS64.

However, commit fd045f6cd98e ("arm64: add support for module PLTs") added
support for routing branch instructions via veneers if the branch target
offset exceeds the range of the ordinary relative branch instructions.
Since this deals with jump and call instructions that are exposed to ELF
relocations, the PLT code uses register x16 to hold the address of the
branch target when it performs an indirect branch-to-register, something
which is explicitly allowed by the AAPCS64 (and compiler generated code
does not expect register x16 to retain its value across a bl instruction).

Since the lse runtime patched bl instructions don't adhere to the AAPCS64,
they don't deal with this clobbering of register x16. So add it to the
clobber list of the asm() statements that perform the call instructions,
and drop x16 from the list of registers that are caller saved in the out
of line non-LSE implementations.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
 arch/arm64/include/asm/atomic_lse.h | 38 ++++++++++----------
 arch/arm64/lib/Makefile             |  2 +-
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
index 197e06afbf71..5bb51340571e 100644
--- a/arch/arm64/include/asm/atomic_lse.h
+++ b/arch/arm64/include/asm/atomic_lse.h
@@ -36,7 +36,7 @@ static inline void atomic_andnot(int i, atomic_t *v)
 	"	stclr	%w[i], %[v]\n")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x30");
 }
 
 static inline void atomic_or(int i, atomic_t *v)
@@ -48,7 +48,7 @@ static inline void atomic_or(int i, atomic_t *v)
 	"	stset	%w[i], %[v]\n")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x30");
 }
 
 static inline void atomic_xor(int i, atomic_t *v)
@@ -60,7 +60,7 @@ static inline void atomic_xor(int i, atomic_t *v)
 	"	steor	%w[i], %[v]\n")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x30");
 }
 
 static inline void atomic_add(int i, atomic_t *v)
@@ -72,7 +72,7 @@ static inline void atomic_add(int i, atomic_t *v)
 	"	stadd	%w[i], %[v]\n")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x30");
 }
 
 #define ATOMIC_OP_ADD_RETURN(name, mb, cl...)				\
@@ -90,7 +90,7 @@ static inline int atomic_add_return##name(int i, atomic_t *v)		\
 	"	add	%w[i], %w[i], w30")				\
 	: [i] "+r" (w0), [v] "+Q" (v->counter)				\
 	: "r" (x1)							\
-	: "x30" , ##cl);						\
+	: "x16", "x30", ##cl);						\
 									\
 	return w0;							\
 }
@@ -116,7 +116,7 @@ static inline void atomic_and(int i, atomic_t *v)
 	"	stclr	%w[i], %[v]")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x30");
 }
 
 static inline void atomic_sub(int i, atomic_t *v)
@@ -133,7 +133,7 @@ static inline void atomic_sub(int i, atomic_t *v)
 	"	stadd	%w[i], %[v]")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x30");
 }
 
 #define ATOMIC_OP_SUB_RETURN(name, mb, cl...)				\
@@ -153,7 +153,7 @@ static inline int atomic_sub_return##name(int i, atomic_t *v)		\
 	"	add	%w[i], %w[i], w30")				\
 	: [i] "+r" (w0), [v] "+Q" (v->counter)				\
 	: "r" (x1)							\
-	: "x30" , ##cl);						\
+	: "x16", "x30" , ##cl);						\
 									\
 	return w0;							\
 }
@@ -177,7 +177,7 @@ static inline void atomic64_andnot(long i, atomic64_t *v)
 	"	stclr	%[i], %[v]\n")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x30");
 }
 
 static inline void atomic64_or(long i, atomic64_t *v)
@@ -189,7 +189,7 @@ static inline void atomic64_or(long i, atomic64_t *v)
 	"	stset	%[i], %[v]\n")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x30");
 }
 
 static inline void atomic64_xor(long i, atomic64_t *v)
@@ -201,7 +201,7 @@ static inline void atomic64_xor(long i, atomic64_t *v)
 	"	steor	%[i], %[v]\n")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x30");
 }
 
 static inline void atomic64_add(long i, atomic64_t *v)
@@ -213,7 +213,7 @@ static inline void atomic64_add(long i, atomic64_t *v)
 	"	stadd	%[i], %[v]\n")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x30");
 }
 
 #define ATOMIC64_OP_ADD_RETURN(name, mb, cl...)				\
@@ -231,7 +231,7 @@ static inline long atomic64_add_return##name(long i, atomic64_t *v)	\
 	"	add	%[i], %[i], x30")				\
 	: [i] "+r" (x0), [v] "+Q" (v->counter)				\
 	: "r" (x1)							\
-	: "x30" , ##cl);						\
+	: "x16", "x30", ##cl);						\
 									\
 	return x0;							\
 }
@@ -257,7 +257,7 @@ static inline void atomic64_and(long i, atomic64_t *v)
 	"	stclr	%[i], %[v]")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x30");
 }
 
 static inline void atomic64_sub(long i, atomic64_t *v)
@@ -274,7 +274,7 @@ static inline void atomic64_sub(long i, atomic64_t *v)
 	"	stadd	%[i], %[v]")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x30");
 }
 
 #define ATOMIC64_OP_SUB_RETURN(name, mb, cl...)				\
@@ -294,7 +294,7 @@ static inline long atomic64_sub_return##name(long i, atomic64_t *v)	\
 	"	add	%[i], %[i], x30")				\
 	: [i] "+r" (x0), [v] "+Q" (v->counter)				\
 	: "r" (x1)							\
-	: "x30" , ##cl);						\
+	: "x16", "x30", ##cl);						\
 									\
 	return x0;							\
 }
@@ -330,7 +330,7 @@ static inline long atomic64_dec_if_positive(atomic64_t *v)
 	"2:")
 	: [ret] "+&r" (x0), [v] "+Q" (v->counter)
 	:
-	: "x30", "cc", "memory");
+	: "x16", "x30", "cc", "memory");
 
 	return x0;
 }
@@ -359,7 +359,7 @@ static inline unsigned long __cmpxchg_case_##name(volatile void *ptr,	\
 	"	mov	%" #w "[ret], " #w "30")			\
 	: [ret] "+r" (x0), [v] "+Q" (*(unsigned long *)ptr)		\
 	: [old] "r" (x1), [new] "r" (x2)				\
-	: "x30" , ##cl);						\
+	: "x16", "x30", ##cl);						\
 									\
 	return x0;							\
 }
@@ -416,7 +416,7 @@ static inline long __cmpxchg_double##name(unsigned long old1,		\
 	  [v] "+Q" (*(unsigned long *)ptr)				\
 	: [new1] "r" (x2), [new2] "r" (x3), [ptr] "r" (x4),		\
 	  [oldval1] "r" (oldval1), [oldval2] "r" (oldval2)		\
-	: "x30" , ##cl);						\
+	: "x16", "x30", ##cl);						\
 									\
 	return x0;							\
 }
diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
index 1a811ecf71da..a2843ac38d7f 100644
--- a/arch/arm64/lib/Makefile
+++ b/arch/arm64/lib/Makefile
@@ -15,4 +15,4 @@ CFLAGS_atomic_ll_sc.o	:= -fcall-used-x0 -ffixed-x1 -ffixed-x2		\
 		   -ffixed-x7 -fcall-saved-x8 -fcall-saved-x9		\
 		   -fcall-saved-x10 -fcall-saved-x11 -fcall-saved-x12	\
 		   -fcall-saved-x13 -fcall-saved-x14 -fcall-saved-x15	\
-		   -fcall-saved-x16 -fcall-saved-x17 -fcall-saved-x18
+		   -fcall-saved-x17 -fcall-saved-x18
-- 
2.5.0



From computersforpeace at gmail.com  Thu Feb 25 11:24:41 2016
From: computersforpeace at gmail.com (Brian Norris)
Date: Thu, 25 Feb 2016 11:24:41 -0800
Subject: [PATCH] MAINTAINERS: add maintainer entry for FREESCALE GPMI
 NAND driver
In-Reply-To: <20160218043612.GA735@sha-win-210.asiapac.arm.com>
References: <1455767715-621-1-git-send-email-han.xu@nxp.com>
 <20160218043612.GA735@sha-win-210.asiapac.arm.com>
Message-ID: <20160225192441.GM21465@google.com>

On Thu, Feb 18, 2016 at 12:36:13PM +0800, Huang Shijie wrote:
> On Thu, Feb 18, 2016 at 03:55:15AM +0000, Han Xu wrote:
> > Add a maintainer entry for FREESCALE GPMI NAND driver and add myself as a
> > maintainer.
> >
> > Signed-off-by: Han Xu <han.xu at nxp.com>
> > ---
> >  MAINTAINERS | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 7bd927e..49baa5b 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4543,6 +4543,12 @@ L:     linuxppc-dev at lists.ozlabs.org
> >  S:   Maintained
> >  F:   drivers/dma/fsldma.*
> >
> > +FREESCALE GPMI NAND DRIVER
> > +M:   Han Xu <han.xu at nxp.com>
> > +L:   linux-mtd at lists.infradead.org
> > +S:   Maintained
> > +F:   drivers/mtd/nand/gpmi-nand/*
> > +
> >  FREESCALE I2C CPM DRIVER
> >  M:   Jochen Friedrich <jochen at scram.de>
> >  L:   linuxppc-dev at lists.ozlabs.org
> > --
> > 2.7.1
> >
> Acked-by: Huang Shijie <shijie.huang at arm.com>

Pushed to linux-mtd.git


From maxime.ripard at free-electrons.com  Thu Feb 25 11:25:48 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Feb 2016 11:25:48 -0800
Subject: [PATCH v3 00/10] arm64: Introduce Allwinner A64 and Pine64 support
In-Reply-To: <56CED1CB.8040807@arm.com>
References: <1456165255-31013-1-git-send-email-andre.przywara@arm.com>
 <56CED1CB.8040807@arm.com>
Message-ID: <20160225192548.GK4736@lukather>

Hi,

On Thu, Feb 25, 2016 at 10:04:59AM +0000, Andre Przywara wrote:
> Hi Maxime,
> 
> can you give me a quick assessment on how we can progress from here?
> 
> Is it already too late for at least some of the patches to go into 4.6?

I think we still have a major disagreement on the clocks part, and
yeah, it's too late for 4.6, I'm going to send the PR tomorrow, and am
merging the final patches that didn't have the attention they deserved
lately.

> If not, can you at least merge the Kconfig patch (3/10)

This one was already merged

> and the pinctrl driver (if that goes via your tree at all)? Do you
> need more reviews or Acks?

And I just gave my Acked-by for this one, but it will go through the
pinctrl tree, hopefully in time.

> Of the prerequisite patches for a clean arm64 compile I see that the
> sunxi-rsb is in your for-next branch, but not in -next itself. Also I
> got a message about the sunxi-ss Kconfig patch to be applied, but cannot
> find it in -next either. All the other patches have made it into -next
> as of today.

Great, I'll push the A64 kconfig patch in next today, and see if
there's any fallout.

> Also are you happy with the PLL6 reuse patch I sent on Monday and can I
> base the A64's PLL7 clock on that?
> Or do you prefer another approach here? I am happy to discuss this on
> the list then.

I just commented on it.

Sorry for the unresponsiveness lately,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/5d167351/attachment-0001.sig>

From maxime.ripard at free-electrons.com  Thu Feb 25 11:29:38 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Feb 2016 11:29:38 -0800
Subject: [PATCH v5 1/4] clk: sunxi: Add apb0 gates for H3
In-Reply-To: <1456146208-13890-2-git-send-email-k@japko.eu>
References: <1456146208-13890-1-git-send-email-k@japko.eu>
 <1456146208-13890-2-git-send-email-k@japko.eu>
Message-ID: <20160225192938.GL4736@lukather>

Hi,

On Mon, Feb 22, 2016 at 02:03:25PM +0100, Krzysztof Adamski wrote:
> This patch adds support for APB0 in H3. It seems to be compatible with
> earlier SOCs. apb0 gates controls R_ block peripherals (R_PIO, R_IR,
> etc).
> 
> Signed-off-by: Krzysztof Adamski <k at japko.eu>
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt | 2 ++
>  drivers/clk/sunxi/clk-simple-gates.c              | 4 ++++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index c09f59b..834436f 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -18,6 +18,7 @@ Required properties:
>  	"allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock
>  	"allwinner,sun4i-a10-axi-clk" - for the AXI clock
>  	"allwinner,sun8i-a23-axi-clk" - for the AXI clock on A23
> +	"allwinner,sun4i-a10-gates-clk" - for generic gates on all compatible SoCs
>  	"allwinner,sun4i-a10-axi-gates-clk" - for the AXI gates
>  	"allwinner,sun4i-a10-ahb-clk" - for the AHB clock
>  	"allwinner,sun5i-a13-ahb-clk" - for the AHB clock on A13
> @@ -46,6 +47,7 @@ Required properties:
>  	"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
>  	"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
>  	"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
> +	"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
>  	"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
>  	"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
>  	"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
> diff --git a/drivers/clk/sunxi/clk-simple-gates.c b/drivers/clk/sunxi/clk-simple-gates.c
> index 2cfc5a8..d7ec2dc 100644
> --- a/drivers/clk/sunxi/clk-simple-gates.c
> +++ b/drivers/clk/sunxi/clk-simple-gates.c
> @@ -98,6 +98,8 @@ static void __init sunxi_simple_gates_init(struct device_node *node)
>  	sunxi_simple_gates_setup(node, NULL, 0);
>  }
>  
> +CLK_OF_DECLARE(sun4i_a10_gates, "allwinner,sun4i-a10-gates-clk",
> +	       sunxi_simple_gates_init);
>  CLK_OF_DECLARE(sun4i_a10_apb0, "allwinner,sun4i-a10-apb0-gates-clk",
>  	       sunxi_simple_gates_init);
>  CLK_OF_DECLARE(sun4i_a10_apb1, "allwinner,sun4i-a10-apb1-gates-clk",
> @@ -132,6 +134,8 @@ CLK_OF_DECLARE(sun8i_a33_ahb1, "allwinner,sun8i-a33-ahb1-gates-clk",
>  	       sunxi_simple_gates_init);
>  CLK_OF_DECLARE(sun8i_a83t_apb0, "allwinner,sun8i-a83t-apb0-gates-clk",
>  	       sunxi_simple_gates_init);
> +CLK_OF_DECLARE(sun8i_h3_apb0, "allwinner,sun8i-h3-apb0-gates-clk",
> +	       sunxi_simple_gates_init);

You don't need this one anymore. I removed it, and applied the patch.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/42ea11bb/attachment.sig>

From linus.walleij at linaro.org  Thu Feb 25 11:30:35 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 20:30:35 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56CF2FB1.106@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <3695074.sKSIyOjpjD@wuerfel>
 <CACRpkdZjfjOCFUucF1U5yVZBxSwa41GKEMv-HHQE=ymF2NZ21g@mail.gmail.com>
 <6859810.tb1t0IEONi@wuerfel> <56CC57FC.20707@ti.com>
 <CACRpkdYNaNtQQJ-tsBe5ksa4-z380ZQj-zN8ZnK0ED2kNPUwvg@mail.gmail.com>
 <56CC60C4.6040908@ti.com>
 <CACRpkdZd8TLdsi7_cOrqzcqWKJrfdp4Vz2sx5ozpwJXOj0fa+Q@mail.gmail.com>
 <56CF2FB1.106@ti.com>
Message-ID: <CACRpkdYowXJinONTd2qREfCtEDCon+HSQtdd6t1QQA91f6PJdw@mail.gmail.com>

On Thu, Feb 25, 2016 at 5:45 PM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> On 25/02/16 16:04, Linus Walleij wrote:

>> *All* the others
>> will be very happy with *ONE* display defined as panel in the
>> device tree, and off they go. Usually VGA. And that will look
>
> You keep mentioning VGA. So is there are VGA output? Or do you just mean
> MIPI DPI panels, which happen to take the same video timings as VGA?

Russell beat me to it, yes there is an external VGA encoder.
It needs some bits set up through the "misc registers" system
controller as indicated. From the CLCD hardware point of view
it's no different than any other panel. So the DTS fragment looks
like so:

                        panel {
                                compatible = "panel-dpi";

                                port {
                                        clcd_panel: endpoint {
                                                remote-endpoint = <&clcd_pads>;
                                        };
                                };

                                /* Standard 640x480 VGA timings */
                                panel-timing {
                                        clock-frequency = <25175000>;
                                        hactive = <640>;
                                        hback-porch = <48>;
                                        hfront-porch = <16>;
                                        hsync-len = <96>;
                                        vactive = <480>;
                                        vback-porch = <33>;
                                        vfront-porch = <10>;
                                        vsync-len = <2>;
                                };
                        };


This is reported as the default display type if no LCD panel
is connected.

If a LCD panel is also connected, it take precedence.

Yours,
Linus Walleij


From linus.walleij at linaro.org  Thu Feb 25 11:32:18 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 20:32:18 +0100
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <56CF2FB1.106@ti.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <3695074.sKSIyOjpjD@wuerfel>
 <CACRpkdZjfjOCFUucF1U5yVZBxSwa41GKEMv-HHQE=ymF2NZ21g@mail.gmail.com>
 <6859810.tb1t0IEONi@wuerfel> <56CC57FC.20707@ti.com>
 <CACRpkdYNaNtQQJ-tsBe5ksa4-z380ZQj-zN8ZnK0ED2kNPUwvg@mail.gmail.com>
 <56CC60C4.6040908@ti.com>
 <CACRpkdZd8TLdsi7_cOrqzcqWKJrfdp4Vz2sx5ozpwJXOj0fa+Q@mail.gmail.com>
 <56CF2FB1.106@ti.com>
Message-ID: <CACRpkdZdGzxgZHAHwoSXZUSZGPf4MC+LUN0a97pyDyR4qxsS_g@mail.gmail.com>

On Thu, Feb 25, 2016 at 5:45 PM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:

> Anyway, if it's likely that we're not seeing new CLCD boards, I think
> it's fine if we don't go to any great lengths to clean things up there.
> Let's just get it working.

Do you think you could merge the other patch set I made, that doesn't
even deal with this plug-n-play-panel issue?

I have rebased the two approaches to autodetection on top of that.

Yours,
Linus Walleij


From maxime.ripard at free-electrons.com  Thu Feb 25 11:33:17 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Feb 2016 11:33:17 -0800
Subject: [PATCH v5 2/4] dts: sun8i-h3: Add APB0 related clocks and resets
In-Reply-To: <1456146208-13890-3-git-send-email-k@japko.eu>
References: <1456146208-13890-1-git-send-email-k@japko.eu>
 <1456146208-13890-3-git-send-email-k@japko.eu>
Message-ID: <20160225193317.GM4736@lukather>

On Mon, Feb 22, 2016 at 02:03:26PM +0100, Krzysztof Adamski wrote:
> APB0 is bearly mentioned in H3 User Manual and it is only setup in the
> Allwinners kernel dump for CIR. I have verified experimentally that the
> gate for R_PIO exists and works, though. There are probably other gates
> there but I don't know their order right now and I don't have access to
> their peripherals on my board to test them.
> 
> After some experiments and reviewing how this is organized on other
> sunxi SoCs, I couldn't actually find any way to disable clocks for R_PIO
> and they are working properly without doing anything so I assume they
> are connected straight to the 24Mhz oscillator for now.
> 
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/80559ed0/attachment.sig>

From linus.walleij at linaro.org  Thu Feb 25 11:34:06 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 20:34:06 +0100
Subject: [PATCH 4/7 v2] video: ARM CLCD: support pads connected in reverse
 order
Message-ID: <1456428846-6250-1-git-send-email-linus.walleij@linaro.org>

There are CLCDs connected with the pads in BGR rather than RGB
order. It really doesn't matter since the CLCD has a flag and
a bit to switch the position of the RGB and BGR components.
This is needed to put something logical into the
arm,pl11x,tft-r0g0b0-pads property of the device tree on the
Nomadik which will then be <16 8 0>.

Cc: Pawel Moll <pawel.moll at arm.com>
Cc: Rob Herring <robh at kernel.org>
Cc: Russell King <linux at arm.linux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
---
ChangeLog v1->v2:
- No changes. Just reposting.
---
 drivers/video/fbdev/amba-clcd.c |  8 ++++++++
 include/linux/amba/clcd.h       | 31 ++++++++++++++++++++++++-------
 2 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 8903a42c4122..9a631a8e2c04 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -681,6 +681,7 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
 	} panels[] = {
 		{ 0x110, 1,  7, 13, CLCD_CAP_5551 },
 		{ 0x110, 0,  8, 16, CLCD_CAP_888 },
+		{ 0x110, 16, 8, 0,  CLCD_CAP_888 },
 		{ 0x111, 4, 14, 20, CLCD_CAP_444 },
 		{ 0x111, 3, 11, 19, CLCD_CAP_444 | CLCD_CAP_5551 },
 		{ 0x111, 3, 10, 19, CLCD_CAP_444 | CLCD_CAP_5551 |
@@ -708,6 +709,13 @@ static int clcdfb_of_init_tft_panel(struct clcd_fb *fb, u32 r0, u32 g0, u32 b0)
 			fb->panel->caps = panels[i].caps;
 	}
 
+	/*
+	 * If we actually physically connected the R lines to B and
+	 * vice versa
+	 */
+	if (r0 != 0 && b0 == 0)
+		fb->panel->bgr_connection = true;
+
 	return fb->panel->caps ? 0 : -EINVAL;
 }
 
diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h
index e64c1ccebb76..c60f32e23a83 100644
--- a/include/linux/amba/clcd.h
+++ b/include/linux/amba/clcd.h
@@ -108,6 +108,12 @@ struct clcd_panel {
 				grayscale:1;
 	unsigned int		connector;
 	struct backlight_device	*backlight;
+	/*
+	 * If the B/R lines are switched between the CLCD
+	 * and the panel we need to know this and not try to
+	 * compensate with the BGR bit in the control register.
+	 */
+	bool			bgr_connection;
 };
 
 struct clcd_regs {
@@ -234,16 +240,27 @@ static inline void clcdfb_decode(struct clcd_fb *fb, struct clcd_regs *regs)
 	if (var->grayscale)
 		val |= CNTL_LCDBW;
 
-	if (fb->panel->caps && fb->board->caps &&
-	    var->bits_per_pixel >= 16) {
+	if (fb->panel->caps && fb->board->caps && var->bits_per_pixel >= 16) {
 		/*
 		 * if board and panel supply capabilities, we can support
-		 * changing BGR/RGB depending on supplied parameters
+		 * changing BGR/RGB depending on supplied parameters. Here
+		 * we switch to what the framebuffer is providing if need
+		 * be, so if the framebuffer is BGR but the display connection
+		 * is RGB (first case) we switch it around. Vice versa mutatis
+		 * mutandis if the framebuffer is RGB but the display connection
+		 * is BGR, we flip it around.
 		 */
-		if (var->red.offset == 0)
-			val &= ~CNTL_BGR;
-		else
-			val |= CNTL_BGR;
+		if (!fb->panel->bgr_connection) {
+			if (var->red.offset == 0)
+				val &= ~CNTL_BGR;
+			else
+				val |= CNTL_BGR;
+		} else {
+			if (var->blue.offset == 0)
+				val &= ~CNTL_BGR;
+			else
+				val |= CNTL_BGR;
+		}
 	}
 
 	switch (var->bits_per_pixel) {
-- 
2.4.3



From maxime.ripard at free-electrons.com  Thu Feb 25 11:34:05 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Feb 2016 11:34:05 -0800
Subject: [PATCH v5 3/4] ARM: dts: sun8i-h3: Add R_PIO controller node to
 the dtsi
In-Reply-To: <1456146208-13890-4-git-send-email-k@japko.eu>
References: <1456146208-13890-1-git-send-email-k@japko.eu>
 <1456146208-13890-4-git-send-email-k@japko.eu>
Message-ID: <20160225193405.GN4736@lukather>

On Mon, Feb 22, 2016 at 02:03:27PM +0100, Krzysztof Adamski wrote:
> Add the corresponding device node for R_PIO on H3 to the dtsi. Support
> for the controller was added in earlier commit.
> 
> Signed-off-by: Krzysztof Adamski <k at japko.eu>

Applied with Linus Ack.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/3715941b/attachment-0001.sig>

From linus.walleij at linaro.org  Thu Feb 25 11:35:31 2016
From: linus.walleij at linaro.org (Linus Walleij)
Date: Thu, 25 Feb 2016 20:35:31 +0100
Subject: [PATCH 0/7] video: ARM CLCD: non-controversial parts
In-Reply-To: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
References: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
Message-ID: <CACRpkdbGDXTbenOY_bsiuGqS3oBP3CKyjsOJuMPStaMFi=u3hw@mail.gmail.com>

On Tue, Feb 23, 2016 at 11:01 AM, Linus Walleij
<linus.walleij at linaro.org> wrote:

> This is a redux version of the previous patch set that strips out
> any attempts to auto-switch or rewrite the device tree to match
> the CLCD Versatile panel.

It seems patch #4 didn't make it out so I re-sent it.

Tell me if you want me to resend the entire v2 patch set.

This stuff would be really neat to get in as a starter.

Yours,
Linus Walleij


From maxime.ripard at free-electrons.com  Thu Feb 25 11:38:09 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Feb 2016 11:38:09 -0800
Subject: [PATCH v5 4/4] ARM: dts: sun8i: Add leds and switch on Orangepi
 Plus boards
In-Reply-To: <1456146208-13890-5-git-send-email-k@japko.eu>
References: <1456146208-13890-1-git-send-email-k@japko.eu>
 <1456146208-13890-5-git-send-email-k@japko.eu>
Message-ID: <20160225193809.GO4736@lukather>

Hi,

On Mon, Feb 22, 2016 at 02:03:28PM +0100, Krzysztof Adamski wrote:
> OrangePi Plus board has two leds - green ("pwr") and red ("status")
> and a switch ("sw4"). This patch describes them in a devicetree.
> 
> Signed-off-by: Krzysztof Adamski <k at japko.eu>
> ---
>  arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 63 ++++++++++++++++++++++++++++
>  1 file changed, 63 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
> index e67df59..5f159d0 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
> @@ -45,6 +45,7 @@
>  #include "sunxi-common-regulators.dtsi"
>  
>  #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
>  #include <dt-bindings/pinctrl/sun4i-a10.h>
>  
>  / {
> @@ -58,6 +59,68 @@
>  	chosen {
>  		stdout-path = "serial0:115200n8";
>  	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&leds_opc>;
> +
> +		status_led {
> +			label = "status:red:user";
> +			gpios = <&pio 0 15 GPIO_ACTIVE_HIGH>;
> +		};
> +	};
> +
> +	r_leds {
> +		compatible = "gpio-leds";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&leds_r_opc>;
> +
> +		tx {
> +			label = "pwr:green:user";
> +			gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
> +			default-state = "on";
> +		};
> +	};

You can merge the two gpio-leds nodes into a single one.

Plus, the label format is <board>:<colour>:<role>

In these case, it would be more "orangepi-plus:red:status" and
"orangepi-plus:green:pwr".

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/a0c53bfe/attachment.sig>

From maxime.ripard at free-electrons.com  Thu Feb 25 11:38:57 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Feb 2016 11:38:57 -0800
Subject: [PATCH 1/2] ARM: dts: sun8i: Add ir receiver nodes to H3 dtsi
In-Reply-To: <1456268597-13692-2-git-send-email-hdegoede@redhat.com>
References: <1456268597-13692-1-git-send-email-hdegoede@redhat.com>
 <1456268597-13692-2-git-send-email-hdegoede@redhat.com>
Message-ID: <20160225193857.GP4736@lukather>

On Wed, Feb 24, 2016 at 12:03:16AM +0100, Hans de Goede wrote:
> The H3 ir receiver is completely compatible with the one found in the A31.
> 
> Signed-off-by: Hans de Goede <hdegoede at redhat.com>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/230266bd/attachment.sig>

From ard.biesheuvel at linaro.org  Thu Feb 25 11:48:53 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 25 Feb 2016 20:48:53 +0100
Subject: [PATCH v2] arm64: lse: deal with clobbered x16 register after branch
 via PLT
Message-ID: <1456429733-20825-1-git-send-email-ard.biesheuvel@linaro.org>

The LSE atomics implementation uses runtime patching to patch in calls
to out of line non-LSE atomics implementations on cores that lack hardware
support for LSE. To avoid paying the overhead cost of a function call even
if no call ends up being made, the bl instruction is kept invisible to the
compiler, and the out of line implementations preserve all registers, not
just the ones that they are required to preserve as per the AAPCS64.

However, commit fd045f6cd98e ("arm64: add support for module PLTs") added
support for routing branch instructions via veneers if the branch target
offset exceeds the range of the ordinary relative branch instructions.
Since this deals with jump and call instructions that are exposed to ELF
relocations, the PLT code uses x16 to hold the address of the branch target
when it performs an indirect branch-to-register, something which is
explicitly allowed by the AAPCS64 (and ordinary compiler generated code
does not expect register x16 or x17 to retain their values across a bl
instruction).

Since the lse runtime patched bl instructions don't adhere to the AAPCS64,
they don't deal with this clobbering of registers x16 and x17. So add them
to the clobber list of the asm() statements that perform the call
instructions, and drop x16 and x17 from the list of registers that are
caller saved in the out of line non-LSE implementations.

In addition, since we have given these functions two scratch registers,
they no longer need to stack/unstack temp registers, and the only remaining
stack accesses are for the frame pointer. So pass -fomit-frame-pointer as
well, this eliminates all stack accesses from these functions.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
---
v2: added x17 and -fomit-frame-pointer

Before:
0000000000000000 <__ll_sc_atomic_add>:
   0:   a9be7bfd        stp     x29, x30, [sp,#-32]!
   4:   910003fd        mov     x29, sp
   8:   f9000be8        str     x8, [sp,#16]
   c:   f9800031        prfm    pstl1strm, [x1]
  10:   885f7c28        ldxr    w8, [x1]
  14:   0b000108        add     w8, w8, w0
  18:   881e7c28        stxr    w30, w8, [x1]
  1c:   35ffffbe        cbnz    w30, 10 <__ll_sc_atomic_add+0x10>
  20:   f9400be8        ldr     x8, [sp,#16]
  24:   a8c27bfd        ldp     x29, x30, [sp],#32
  28:   d65f03c0        ret
  2c:   d503201f        nop

After:
0000000000000000 <__ll_sc_atomic_add>:
   0:   f9800031        prfm    pstl1strm, [x1]
   4:   885f7c31        ldxr    w17, [x1]
   8:   0b000231        add     w17, w17, w0
   c:   88107c31        stxr    w16, w17, [x1]
  10:   35ffffb0        cbnz    w16, 4 <__ll_sc_atomic_add+0x4>
  14:   d65f03c0        ret

 arch/arm64/include/asm/atomic_lse.h | 38 ++++++++++----------
 arch/arm64/lib/Makefile             |  2 +-
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
index 197e06afbf71..7af60139f718 100644
--- a/arch/arm64/include/asm/atomic_lse.h
+++ b/arch/arm64/include/asm/atomic_lse.h
@@ -36,7 +36,7 @@ static inline void atomic_andnot(int i, atomic_t *v)
 	"	stclr	%w[i], %[v]\n")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x17", "x30");
 }
 
 static inline void atomic_or(int i, atomic_t *v)
@@ -48,7 +48,7 @@ static inline void atomic_or(int i, atomic_t *v)
 	"	stset	%w[i], %[v]\n")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x17", "x30");
 }
 
 static inline void atomic_xor(int i, atomic_t *v)
@@ -60,7 +60,7 @@ static inline void atomic_xor(int i, atomic_t *v)
 	"	steor	%w[i], %[v]\n")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x17", "x30");
 }
 
 static inline void atomic_add(int i, atomic_t *v)
@@ -72,7 +72,7 @@ static inline void atomic_add(int i, atomic_t *v)
 	"	stadd	%w[i], %[v]\n")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x17", "x30");
 }
 
 #define ATOMIC_OP_ADD_RETURN(name, mb, cl...)				\
@@ -90,7 +90,7 @@ static inline int atomic_add_return##name(int i, atomic_t *v)		\
 	"	add	%w[i], %w[i], w30")				\
 	: [i] "+r" (w0), [v] "+Q" (v->counter)				\
 	: "r" (x1)							\
-	: "x30" , ##cl);						\
+	: "x16", "x17", "x30", ##cl);					\
 									\
 	return w0;							\
 }
@@ -116,7 +116,7 @@ static inline void atomic_and(int i, atomic_t *v)
 	"	stclr	%w[i], %[v]")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x17", "x30");
 }
 
 static inline void atomic_sub(int i, atomic_t *v)
@@ -133,7 +133,7 @@ static inline void atomic_sub(int i, atomic_t *v)
 	"	stadd	%w[i], %[v]")
 	: [i] "+r" (w0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x17", "x30");
 }
 
 #define ATOMIC_OP_SUB_RETURN(name, mb, cl...)				\
@@ -153,7 +153,7 @@ static inline int atomic_sub_return##name(int i, atomic_t *v)		\
 	"	add	%w[i], %w[i], w30")				\
 	: [i] "+r" (w0), [v] "+Q" (v->counter)				\
 	: "r" (x1)							\
-	: "x30" , ##cl);						\
+	: "x16", "x17", "x30" , ##cl);					\
 									\
 	return w0;							\
 }
@@ -177,7 +177,7 @@ static inline void atomic64_andnot(long i, atomic64_t *v)
 	"	stclr	%[i], %[v]\n")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x17", "x30");
 }
 
 static inline void atomic64_or(long i, atomic64_t *v)
@@ -189,7 +189,7 @@ static inline void atomic64_or(long i, atomic64_t *v)
 	"	stset	%[i], %[v]\n")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x17", "x30");
 }
 
 static inline void atomic64_xor(long i, atomic64_t *v)
@@ -201,7 +201,7 @@ static inline void atomic64_xor(long i, atomic64_t *v)
 	"	steor	%[i], %[v]\n")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x17", "x30");
 }
 
 static inline void atomic64_add(long i, atomic64_t *v)
@@ -213,7 +213,7 @@ static inline void atomic64_add(long i, atomic64_t *v)
 	"	stadd	%[i], %[v]\n")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x17", "x30");
 }
 
 #define ATOMIC64_OP_ADD_RETURN(name, mb, cl...)				\
@@ -231,7 +231,7 @@ static inline long atomic64_add_return##name(long i, atomic64_t *v)	\
 	"	add	%[i], %[i], x30")				\
 	: [i] "+r" (x0), [v] "+Q" (v->counter)				\
 	: "r" (x1)							\
-	: "x30" , ##cl);						\
+	: "x16", "x17", "x30", ##cl);					\
 									\
 	return x0;							\
 }
@@ -257,7 +257,7 @@ static inline void atomic64_and(long i, atomic64_t *v)
 	"	stclr	%[i], %[v]")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x17", "x30");
 }
 
 static inline void atomic64_sub(long i, atomic64_t *v)
@@ -274,7 +274,7 @@ static inline void atomic64_sub(long i, atomic64_t *v)
 	"	stadd	%[i], %[v]")
 	: [i] "+r" (x0), [v] "+Q" (v->counter)
 	: "r" (x1)
-	: "x30");
+	: "x16", "x17", "x30");
 }
 
 #define ATOMIC64_OP_SUB_RETURN(name, mb, cl...)				\
@@ -294,7 +294,7 @@ static inline long atomic64_sub_return##name(long i, atomic64_t *v)	\
 	"	add	%[i], %[i], x30")				\
 	: [i] "+r" (x0), [v] "+Q" (v->counter)				\
 	: "r" (x1)							\
-	: "x30" , ##cl);						\
+	: "x16", "x17", "x30", ##cl);					\
 									\
 	return x0;							\
 }
@@ -330,7 +330,7 @@ static inline long atomic64_dec_if_positive(atomic64_t *v)
 	"2:")
 	: [ret] "+&r" (x0), [v] "+Q" (v->counter)
 	:
-	: "x30", "cc", "memory");
+	: "x16", "x17", "x30", "cc", "memory");
 
 	return x0;
 }
@@ -359,7 +359,7 @@ static inline unsigned long __cmpxchg_case_##name(volatile void *ptr,	\
 	"	mov	%" #w "[ret], " #w "30")			\
 	: [ret] "+r" (x0), [v] "+Q" (*(unsigned long *)ptr)		\
 	: [old] "r" (x1), [new] "r" (x2)				\
-	: "x30" , ##cl);						\
+	: "x16", "x17", "x30", ##cl);					\
 									\
 	return x0;							\
 }
@@ -416,7 +416,7 @@ static inline long __cmpxchg_double##name(unsigned long old1,		\
 	  [v] "+Q" (*(unsigned long *)ptr)				\
 	: [new1] "r" (x2), [new2] "r" (x3), [ptr] "r" (x4),		\
 	  [oldval1] "r" (oldval1), [oldval2] "r" (oldval2)		\
-	: "x30" , ##cl);						\
+	: "x16", "x17", "x30", ##cl);					\
 									\
 	return x0;							\
 }
diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
index 1a811ecf71da..d323a82c4ac3 100644
--- a/arch/arm64/lib/Makefile
+++ b/arch/arm64/lib/Makefile
@@ -15,4 +15,4 @@ CFLAGS_atomic_ll_sc.o	:= -fcall-used-x0 -ffixed-x1 -ffixed-x2		\
 		   -ffixed-x7 -fcall-saved-x8 -fcall-saved-x9		\
 		   -fcall-saved-x10 -fcall-saved-x11 -fcall-saved-x12	\
 		   -fcall-saved-x13 -fcall-saved-x14 -fcall-saved-x15	\
-		   -fcall-saved-x16 -fcall-saved-x17 -fcall-saved-x18
+		   -fcall-saved-x18 -fomit-frame-pointer
-- 
2.5.0



From akshay.bhat at timesys.com  Thu Feb 25 11:49:16 2016
From: akshay.bhat at timesys.com (Akshay Bhat)
Date: Thu, 25 Feb 2016 14:49:16 -0500
Subject: [PATCH v3 3/3] ARM: imx6: Fix procedure to switch the parent of, 
 LDB_DI_CLK
In-Reply-To: 1453461088-31549-4-git-send-email-p.zabel@pengutronix.de
Message-ID: <56CF5ABC.8040109@timesys.com>

Hi Fabio, Phillip,

Philipp Zabel <p.zabel <at> pengutronix.de> writes:

 >
 > From: Fabio Estevam <fabio.estevam <at> freescale.com>
 >

<snip>
 > +		sel[i][2] = sel[i][3] | 4;
 > +
 > +		pr_debug("ccm: switching ldb_di0_sel: %d->%d->%d->%d\n",
 > +			 sel[i][0], sel[i][1], sel[i][2], sel[i][3]);

Change ldb_di0_sel to ldb_di%d_sel

<snip>

 > +	if (sel[0][0] == sel[0][3] && sel[1][0] == sel[1][3])
 > +		return;
 > +
 > +	mmdc_ch1_disable(ccm_base);
 > +
 > +	for (i = 1; i < 4; i++) {
 > +		reg = readl_relaxed(ccm_base + CCM_CS2CDR);
 > +		reg &= ~((7 << CS2CDR_LDB_DI0_CLK_SEL_SHIFT) |
 > +			 (7 << CS2CDR_LDB_DI1_CLK_SEL_SHIFT));
 > +		reg |= ((sel[0][i] << CS2CDR_LDB_DI0_CLK_SEL_SHIFT) |
 > +			(sel[1][i] << CS2CDR_LDB_DI0_CLK_SEL_SHIFT));

Needs to be CS2CDR_LDB_DI1_CLK_SEL_SHIFT in the last line; otherwise the 
ldb_di1_clock is set to have incorrect source.

With the above change the patch works great for me. Without this patch 
we were having an issue on some boards where the LVDS would lockup 
sometimes when the clock source was being changed. This patch fixes our 
issue.

Thanks,
Akshay



From helgaas at kernel.org  Thu Feb 25 11:59:12 2016
From: helgaas at kernel.org (Bjorn Helgaas)
Date: Thu, 25 Feb 2016 13:59:12 -0600
Subject: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for
 HiSilicon SoCs Host Controllers
In-Reply-To: <20160225120750.GA32016@red-moon>
References: <20160209182429.GD4348@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1591@lhreml503-mbs>
 <20160210111234.GC2632@leverpostej>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECB1D30@lhreml503-mbs>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECC5F00@lhreml503-mbs>
 <20160224011418.GB13026@localhost>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECCAD6A@lhreml503-mbs>
 <20160224152538.GA19700@localhost>
 <EE11001F9E5DDD47B7634E2F8A612F2E1ECCD209@lhreml503-mbs>
 <20160225120750.GA32016@red-moon>
Message-ID: <20160225195912.GA4818@localhost>

On Thu, Feb 25, 2016 at 12:07:50PM +0000, Lorenzo Pieralisi wrote:
> On Thu, Feb 25, 2016 at 03:01:19AM +0000, Gabriele Paoloni wrote:
> 
> [...]
> 
> > > I think the relevant spec is the PCI Firmware Spec, r3.0, sec 4.1.2.
> > > Note 2 in that section says the address range of an MMCFG region
> > > must be reserved by declaring a motherboard resource, i.e., included
> > > in the _CRS of a PNP0C02 or similar device.
> > 
> > I had a look a this. So yes the specs says that we should use the 
> > PNP0C02 device if MCFG is not supported. 
> 
> AFAIK, PNP0C02 is a resource reservation mechanism, the spec says that
> MCFG regions must be reserved using PNP0C02, even though its
> current usage on x86 is a bit unfathomable to me, in particular
> in relation to MCFG resources retrieved for hotpluggable bridges (ie
> through _CBA, which I think consider the MCFG region as reserved
> by default, regardless of PNP0c02):
> 
> see pci_mmcfg_check_reserved() arch/x86/pci/mmconfig-shared.c

I don't know how _CBA-related resources would be reserved.  I haven't
personally worked with any host bridges that supply _CBA, so I don't
know whether or how they handled it.

I think the spec intent was that the Consumer/Producer bit (Extended
Address Space Descriptor, General Flags Bit[0], see ACPI spec sec
6.4.3.5.4) would be used.  Resources such as ECAM areas would be
marked "Consumer", meaning the bridge consumed that space itself, and
windows passed down to the PCI bus would be marked "Producer".

But BIOSes didn't use that bit consistently, so we couldn't rely on
it.  I verified experimentally that Windows didn't pay attention to
that bit either, at least for DWord descriptors:
https://bugzilla.kernel.org/show_bug.cgi?id=15701

It's conceivable that we could still use that bit in Extended Address
Space descriptors, or maybe some hack like pay attention if the bridge
has _CBA, or some such.  Or maybe a BIOS could add a PNP0C02 device
along with the PNP0A03 device that uses _CBA, with the PNP0C02 _CRS
describing the ECAM area referenced by _CBA.  Seeems hacky no matter
how we slice it.

> Have a look at drivers/pnp/system.c for PNP0c02
> 
> > So probably I can use acpi_get_devices("PNP0C02",...) to retrieve it
> > from the quirk match function, I will look into this... 
> > 
> > > 
> > > > On the other side, since this is an exception only for the config
> > > > space address of our host controller (as said before all the buses
> > > > below the root one support ECAM), I think that it is right to put
> > > > this address as a device specific data (in fact the rest of the
> > > > config space addresses will be parsed from MCFG).
> > > 
> > > A kernel with no support for your host controller (and thus no
> > > knowledge of its _DSD) should still be able to operate the rest of the
> > > system correctly.  That means we must have a generic way to learn what
> > > address space is consumed by the host controller so we don't try to
> > > assign it to other devices.
> > 
> > This is something I don't understand much...
> > Are you talking about a scenario where we have a Kernel image compiled
> > without our host controller support and running on our platform?
> 
> I *think* the point here is that your host controller config space should be
> reserved through PNP0c02 so that the kernel will reserve it through the
> generic PNP0c02 driver even if your host controller driver (and related
> _DSD) is not supported in the kernel.

Right.  Assume you have two top-level devices:

  PNP0A03  PCI host bridge
    _CRS     describes windows
    ????     describes ECAM space consumed
  PNPxxxx  another ACPI device, currently disabled
    _PRS     specifies possible resource settings, may specify no restrictions
    _SRS     assign resources and enable device
    _CRS     empty until device enabled

When the OS enables PNPxxxx, it must first assign resources to it
using _PRS and _SRS.  We evaluate _PRS to find out what the addresses
PNPxxxx can support.  This tells us things like how wide the address
decoder is, the size of the region required, and any alignment
restrictions -- basically the same information we get by sizing a PCI
BAR.

Now, how do we assign space for PNPxxxx?  In a few cases, _PRS has
only a few specific possibilities, e.g., an x86 legacy serial port
that can be at 0x3f8 or 0x2f8.  But in general, _PRS need not impose
any restrictions.

So in general the OS can use any space that can be routed to PNPxxxx.
If there's an upstream bridge, it may define windows that restrict the
possibilities.  But in this case, there *is* no upstream bridge, so
the possible choices are the entire physical address space of the
platform, except for other things that are already allocated: RAM, the
_CRS settings for other ACPI devices, things reserved by the E820
table (at least on x86), etc.

If PNP0A03 consumes address space for ECAM, that space must be
reported *somewhere* so the OS knows not to place PNPxxxx there.  This
reporting must be generic (not device-specific like _DSD).  The ACPI
core (not drivers) is responsible for managing this address space
because:

  a) the OS is not guaranteed to have drivers for all devices, and
  
  b) even it *did* have drivers for all devices, the PNPxxxx space may
  be assigned before drivers are initialized.

> I do not understand how PNP0c02 works, currently, by the way.
> 
> If I read x86 code correctly, the unassigned PCI bus resources are
> assigned in arch/x86/pci/i386.c (?) fs_initcall(pcibios_assign_resources),
> with a comment:
> 
> /**
>  * called in fs_initcall (one below subsys_initcall),
>  * give a chance for motherboard reserve resources
>  */
> 
> Problem is, motherboard resources are requested through (?):
> 
> drivers/pnp/system.c
> 
> which is also initialized at fs_initcall, so it might be called after
> core x86 code reassign resources, defeating the purpose PNP0c02 was
> designed for, namely, request motherboard regions before resources
> are assigned, am I wrong ?

I think you're right.  This is a long-standing screwup in Linux.
IMHO, ACPI resources should be parsed and reserved by the ACPI core,
before any PCI resource management (since PCI host bridges are
represented in ACPI).  But historically PCI devices have enumerated
before ACPI got involved.  And the ACPI core doesn't really pay
attention to _CRS for most devices (with the exception of PNP0C02).

IMO the PNP0C02 code in drivers/pnp/system.c should really be done in
the ACPI core for all ACPI devices, similar to the way the PCI core
reserves BAR space for all PCI devices, even if we don't have drivers
for them.  I've tried to fix this in the past, but it is really a
nightmare to unravel everything.

Because the ACPI core doesn't reserve resources for the _CRS of all
ACPI devices, we're already vulnerable to the problem of placing a
device on top of another ACPI device.  We don't see problems because
on x86, at least, most ACPI devices are already configured by the BIOS
to be enabled and non-overlapping.  But x86 has the advantage of
having extensive test coverage courtesy of Windows, and as long as
_CRS has the right stuff in it, we at least have the potential of
fixing problems in Linux.

If the platform doesn't report resource usage correctly on ARM, we may
not find problems (because we don't have the Windows test suite) and
if we have resource assignment problems because _CRS is lacking, we'll
have no way to fix them.

> As per last Tomasz's patchset, we claim and assign unassigned PCI
> resources upon ACPI PCI host bridge probing (which happens at
> subsys_initcall time, courtesy of ACPI current code); at that time the
> kernel did not even register the PNP0c02 driver (drivers/pnp/system.c)
> (it does that at fs_initcall). On the other hand, we insert MCFG
> regions into the resource tree upon MCFG parsing, so I do not
> see why we need to rely on PNP0c02 to do that for us (granted, the
> mechanism is part of the PCI fw specs, which are x86 centric anyway
> ie we can't certainly rely on Int15 e820 to detect reserved memory
> on ARM :D)
> 
> There is lots of legacy x86 here and Bjorn definitely has more
> visibility into that than I have, the ARM world must understand
> how this works to make sure we have an agreement.

As you say, there is lots of unpleasant x86 legacy here.  Possibly ARM
has a chance to clean this up and do it more sanely; I'm not sure
whether it's feasible to reverse the ACPI/PCI init order there or not.

Rafael, any thoughts on this whole thing?

Bjorn


From kamal.dasu at broadcom.com  Thu Feb 25 12:08:03 2016
From: kamal.dasu at broadcom.com (Kamal Dasu)
Date: Thu, 25 Feb 2016 15:08:03 -0500
Subject: [PATCH] i2c: brcmstb: allocate correct amount of memory for regmap
In-Reply-To: <56CB3A8A.9040401@gmail.com>
References: <1456064238-6294-1-git-send-email-wsa@the-dreams.de>
 <56CB3A8A.9040401@gmail.com>
Message-ID: <270d201d17008$3cae24f0$b60a6ed0$@broadcom.com>

> We want the size of the struct, not of a pointer to it. To be future 
> proof, just dereference the pointer to get the desired type.

Thanks for catching and fixing this.

>
> Signed-off-by: Wolfram Sang <wsa at the-dreams.de>

Reviewed-by: Kamal Dasu <kdasu.kdev at gmail.com>

Kamal



From ynorov at caviumnetworks.com  Thu Feb 25 12:19:26 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Thu, 25 Feb 2016 23:19:26 +0300
Subject: [PATCH 2/5] all: introduce COMPAT_WRAPPER option and enable it
 for s390
In-Reply-To: <20160225084943.GB3980@osiris>
References: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
 <1456338854-14901-3-git-send-email-ynorov@caviumnetworks.com>
 <20160225084943.GB3980@osiris>
Message-ID: <20160225201926.GA16123@yury-N73SV>

On Thu, Feb 25, 2016 at 09:49:43AM +0100, Heiko Carstens wrote:
> On Wed, Feb 24, 2016 at 09:34:11PM +0300, Yury Norov wrote:
> > Signed-off-by: Yury Norov <ynorov at caviumnetworks.com>
> > ---
> >  arch/Kconfig      | 4 ++++
> >  arch/s390/Kconfig | 1 +
> >  2 files changed, 5 insertions(+)
> > 
> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index f6b649d..6393093 100644
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -583,6 +583,10 @@ config HAVE_COPY_THREAD_TLS
> >  	  normal C parameter passing, rather than extracting the syscall
> >  	  argument from pt_regs.
> > 
> > +config COMPAT_WRAPPER
> > +	bool
> > +	depends on COMPAT
> > +
> >  #
> >  # ABI hall of shame
> >  #
> > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> > index 3be9c83..082b861 100644
> > --- a/arch/s390/Kconfig
> > +++ b/arch/s390/Kconfig
> > @@ -333,6 +333,7 @@ config COMPAT
> >  	select COMPAT_BINFMT_ELF if BINFMT_ELF
> >  	select ARCH_WANT_OLD_COMPAT_IPC
> >  	select COMPAT_OLD_SIGACTION
> > +	select COMPAT_WRAPPER
> >  	depends on MULTIUSER
> >  	help
> >  	  Select this option if you want to enable your system kernel to
> 
> Maybe merge this into patch 4/5?

Then bisectability will suffer, as next patch needs COMPAT_WRAPPER
enabled.

> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


From ynorov at caviumnetworks.com  Thu Feb 25 12:23:50 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Thu, 25 Feb 2016 23:23:50 +0300
Subject: [PATCH 3/5] all: s390: move wrapper infrastructure to generic
 headers
In-Reply-To: <20160225085140.GC3980@osiris>
References: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
 <1456338854-14901-4-git-send-email-ynorov@caviumnetworks.com>
 <20160225085140.GC3980@osiris>
Message-ID: <20160225202350.GB16123@yury-N73SV>

On Thu, Feb 25, 2016 at 09:51:40AM +0100, Heiko Carstens wrote:
> On Wed, Feb 24, 2016 at 09:34:12PM +0300, Yury Norov wrote:
> > diff --git a/include/linux/syscalls_structs.h b/include/linux/syscalls_structs.h
> > new file mode 100644
> > index 0000000..a920cbc
> > --- /dev/null
> > +++ b/include/linux/syscalls_structs.h
> > @@ -0,0 +1,60 @@
> > +#ifndef _LINUX_SYSCALL_STRUCTS_H
> > +#define _LINUX_SYSCALL_STRUCTS_H
> > +
> > +struct epoll_event;
> > +struct iattr;
> > +struct inode;
> > +struct iocb;
> > +struct io_event;
> > +struct iovec;
> > +struct itimerspec;
> > +struct itimerval;
> 
> This is not needed for s390, right? So might be worth a separate patch
> which moves the forward declarations?

This patch also introduces __SC_WRAP, not needed as well. The idea of
this patch is to introduce all the tricky machinery at once. If you
think we need split it, I'm OK, but maybe it's enough to add more
detailed description... What do you think?


From ynorov at caviumnetworks.com  Thu Feb 25 12:27:26 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Thu, 25 Feb 2016 23:27:26 +0300
Subject: [PATCH 4/5] all: s390: move compat_wrappers.c from
 arch/s390/kernel to kernel/
In-Reply-To: <1456338854-14901-5-git-send-email-ynorov@caviumnetworks.com>
References: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
 <1456338854-14901-5-git-send-email-ynorov@caviumnetworks.com>
Message-ID: <20160225202726.GC16123@yury-N73SV>

On Wed, Feb 24, 2016 at 09:34:13PM +0300, Yury Norov wrote:

[...]

> +COMPAT_SYSCALL_WRAP3(bpf, int, cmd, union bpf_attr *, attr, unsigned int, size);
> +COMPAT_SYSCALL_WRAP3(s390_pci_mmio_write, const unsigned long, mmio_addr, const void __user *, user_buffer, const size_t, length);
> +COMPAT_SYSCALL_WRAP3(s390_pci_mmio_read, const unsigned long, mmio_addr, void __user *, user_buffer, const size_t, length);

Oops... This one should stay in arch/s390, as it was in previous
version.

> 2.5.0


From ynorov at caviumnetworks.com  Thu Feb 25 12:28:55 2016
From: ynorov at caviumnetworks.com (Yury Norov)
Date: Thu, 25 Feb 2016 23:28:55 +0300
Subject: [RFC5 PATCH v6 00/21] ILP32 for ARM64
In-Reply-To: <mvm8u29ukqw.fsf@hawking.suse.de>
References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com>
 <56AB3805.1040308@huawei.com> <20160129170929.GA3543@yury-N73SV>
 <56AC38F1.2030608@huawei.com> <20160218223506.GA7816@yury-N73SV>
 <mvm8u29ukqw.fsf@hawking.suse.de>
Message-ID: <20160225202855.GD16123@yury-N73SV>

On Thu, Feb 25, 2016 at 11:50:31AM +0100, Andreas Schwab wrote:
> Yury Norov <ynorov at caviumnetworks.com> writes:
> 
> > I have new glibc that follows new ABI:
> > https://github.com/norov/glibc/tree/new-api
> 
> sysdeps/unix/sysv/linux/aarch64/ilp32/getdents64.c is wrong, struct
> dirent64 is not the same as struct dirent.  The file needs to be renamed
> to sysdeps/unix/sysv/linux/aarch64/ilp32/getdents.c so that __getdents64
> comes from sysdeps/unix/sysv/linux/generic/getdents64.c.
> 
> sysdeps/unix/sysv/linux/aarch64/ilp32/*xstat*.c should not set errno,
> INLINE_SYSCALL already does that, and returns -1 on error.
> 
> Andreas.
> 

Thank you. I'll fix it

> -- 
> Andreas Schwab, SUSE Labs, schwab at suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."


From joshua.henderson at microchip.com  Thu Feb 25 12:30:43 2016
From: joshua.henderson at microchip.com (Joshua Henderson)
Date: Thu, 25 Feb 2016 13:30:43 -0700
Subject: [PATCH 42/50] pinctrl: pic32: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-43-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-43-git-send-email-ldewangan@nvidia.com>
Message-ID: <56CF6473.4020804@microchip.com>

On 02/24/2016 06:16 AM, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>

Reviewed-by: Joshua Henderson <joshua.henderson at microchip.com>

Thanks,
Josh

> ---
>  drivers/pinctrl/pinctrl-pic32.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-pic32.c b/drivers/pinctrl/pinctrl-pic32.c
> index 0b07d4b..2a3fcd6 100644
> --- a/drivers/pinctrl/pinctrl-pic32.c
> +++ b/drivers/pinctrl/pinctrl-pic32.c
> @@ -2194,7 +2194,8 @@ static int pic32_pinctrl_probe(struct platform_device *pdev)
>  	pic32_pinctrl_desc.custom_params = pic32_mpp_bindings;
>  	pic32_pinctrl_desc.num_custom_params = ARRAY_SIZE(pic32_mpp_bindings);
>  
> -	pctl->pctldev = pinctrl_register(&pic32_pinctrl_desc, &pdev->dev, pctl);
> +	pctl->pctldev = devm_pinctrl_register(&pdev->dev, &pic32_pinctrl_desc,
> +					      pctl);
>  	if (IS_ERR(pctl->pctldev)) {
>  		dev_err(&pdev->dev, "Failed to register pinctrl device\n");
>  		return PTR_ERR(pctl->pctldev);
> 



From tchalamarla at caviumnetworks.com  Thu Feb 25 12:31:53 2016
From: tchalamarla at caviumnetworks.com (Tirumalesh Chalamarla)
Date: Thu, 25 Feb 2016 12:31:53 -0800
Subject: [PATCH V3] AHCI: Workaround for ThunderX Errata#22536
In-Reply-To: <alpine.DEB.2.11.1602171710350.19512@nanos>
References: <1455653329-4934-1-git-send-email-tchalamarla@caviumnetworks.com>
 <alpine.DEB.2.11.1602171710350.19512@nanos>
Message-ID: <56CF64B9.4080605@caviumnetworks.com>



On 02/17/2016 08:12 AM, Thomas Gleixner wrote:
> On Tue, 16 Feb 2016, tchalamarla at caviumnetworks.com wrote:
>> +#ifdef CONFIG_ARM64
>> +/* Due to ERRATA#22536, ThunderX need to handle
>> + * HOST_IRQ_STAT differently.
>> + * Work around is to make sure all pending IRQs
>> + * are served before leaving handler
>> + */
>> +static irqreturn_t ahci_thunderx_irq_handler(int irq, void *dev_instance)
>> +{
>> +	struct ata_host *host = dev_instance;
>> +	struct ahci_host_priv *hpriv;
>> +	unsigned int rc = 0;
>> +	void __iomem *mmio;
>> +	u32 irq_stat, irq_masked;
>> +	unsigned int handled = 1;
>> +
>> +	VPRINTK("ENTER\n");
>
> Come on. This VPRINK stuff is really pointless. Enable irq tracepoints, they
> already track the enter/exit of interrupt handlers ....
>

sure. waiting for some more comments if any.
> Thanks,
>
> 	tglx
>
>


From k at japko.eu  Thu Feb 25 12:42:35 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Thu, 25 Feb 2016 21:42:35 +0100
Subject: [PATCH v2] ARM: dts: sun8i: Add leds and switch on Orangepi Plus
 boards
Message-ID: <20160225204234.GA31610@box2.japko.eu>

OrangePi Plus board has dwo leds - green ("pwr") and red ("status")
and a switch ("sw4"). This patch describes them in a devicetree.

Signed-off-by: Krzysztof Adamski <k at japko.eu>
---

Changes compared to v1:
 - Fixed leds labels
 - Merged two led sections into one


 arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 57 ++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
index e67df59..d81eca6 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts
@@ -45,6 +45,7 @@
 #include "sunxi-common-regulators.dtsi"
 
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
 #include <dt-bindings/pinctrl/sun4i-a10.h>
 
 / {
@@ -58,6 +59,62 @@
 	chosen {
 		stdout-path = "serial0:115200n8";
 	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&leds_opc &leds_r_opc>;
+
+		status_led {
+			label = "orangepi-plus:red:status";
+			gpios = <&pio 0 15 GPIO_ACTIVE_HIGH>;
+		};
+
+		pwr_led {
+			label = "orangepi-plus:green:pwr";
+			gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+			default-state = "on";
+		};
+	};
+
+	r_gpio_keys {
+		compatible = "gpio-keys";
+		input-name = "sw4";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&sw_r_opc>;
+
+		sw4 at 0 {
+			label = "sw4";
+			linux,code = <BTN_0>;
+			gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
+		};
+	};
+};
+
+&pio {
+	leds_opc: led_pins at 0 {
+		allwinner,pins = "PA15";
+		allwinner,function = "gpio_out";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+};
+
+&r_pio {
+	leds_r_opc: led_pins at 0 {
+		allwinner,pins = "PL10";
+		allwinner,function = "gpio_out";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
+
+	sw_r_opc: key_pins at 0 {
+		allwinner,pins = "PL03";
+		allwinner,function = "gpio_in";
+		allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+		allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+	};
 };
 
 &mmc0 {
-- 
2.1.4



From jeremy.linton at arm.com  Thu Feb 25 12:46:54 2016
From: jeremy.linton at arm.com (Jeremy Linton)
Date: Thu, 25 Feb 2016 14:46:54 -0600
Subject: [PATCH v3 2/2] arm64: Mark kernel page ranges contiguous
In-Reply-To: <20160225161630.GB16546@arm.com>
References: <1455903983-23910-1-git-send-email-jeremy.linton@arm.com>
 <1455903983-23910-3-git-send-email-jeremy.linton@arm.com>
 <20160225161630.GB16546@arm.com>
Message-ID: <56CF683D.30003@arm.com>

On 02/25/2016 10:16 AM, Will Deacon wrote:
> On Fri, Feb 19, 2016 at 11:46:23AM -0600, Jeremy Linton wrote:

(trimming)

>> +static void clear_cont_pte_range(pte_t *pte, unsigned long addr)
>> +{
>> +	int i;
>> +
>> +	pte -= CONT_RANGE_OFFSET(addr);
>> +	for (i = 0; i < CONT_PTES; i++) {
>> +		if (pte_cont(*pte))
>> +			set_pte(pte, pte_mknoncont(*pte));
>> +		pte++;
>> +	}
>> +	flush_tlb_all();
>
> Do you still need this invalidation? I thought the table weren't even
> live at this point?

Well it continues to match the calls in alloc_init_p*.
	
I guess the worry is the extra flush that happens at 
create_mapping_late(), if mapping ranges aren't cont aligned? (because 
the loop won't actually be doing any set_pte's)

If this and the alloc_init_p* flushes are to be removed, there should 
probably be a way to detect any cases where the splits are happening 
after the tables have been activated. This might be a little less 
straightforward given efi_create_mapping().
>
>> +}
>> +
>> +/*
>> + * Given a range of PTEs set the pfn and provided page protection flags
>> + */
>> +static void __populate_init_pte(pte_t *pte, unsigned long addr,
>> +			       unsigned long end, phys_addr_t phys,
>> +			       pgprot_t prot)
>> +{
>> +	unsigned long pfn = __phys_to_pfn(phys);
>> +
>> +	do {
>> +		/* clear all the bits except the pfn, then apply the prot */
>> +		set_pte(pte, pfn_pte(pfn, prot));
>> +		pte++;
>> +		pfn++;
>> +		addr += PAGE_SIZE;
>> +	} while (addr != end);
>> +}
>> +
(trimming)
>> +
>>   	do {
>> -		set_pte(pte, pfn_pte(pfn, prot));
>> -		pfn++;
>> -	} while (pte++, addr += PAGE_SIZE, addr != end);
>> +		next = min(end, (addr + CONT_SIZE) & CONT_MASK);
>> +		if (((addr | next | phys) & ~CONT_MASK) == 0) {
>> +			/* a block of CONT_PTES	 */
>> +			__populate_init_pte(pte, addr, next, phys,
>> +					    prot | __pgprot(PTE_CONT));
>> +		} else {
>> +			/*
>> +			 * If the range being split is already inside of a
>> +			 * contiguous range but this PTE isn't going to be
>> +			 * contiguous, then we want to unmark the adjacent
>> +			 * ranges, then update the portion of the range we
>> +			 * are interested in.
>> +			 */
>> +			clear_cont_pte_range(pte, addr);
>> +			__populate_init_pte(pte, addr, next, phys, prot);
>
> I don't understand the comment or the code here... the splitting is now
> done seperately, and I can't think of a scenario where you need to clear
> the cont hint explicitly for adjacent ptes.

	
My understanding is that splitting is initially running this code path 
(via map_kernel_chunk, then again via create_mapping_late where splits 
won't happen). So, split_pmd() is creating cont ranges. When the ranges 
aren't sufficiently aligned then this is wiping out the cont mapping 
immediately after their creation.



From arnd at arndb.de  Thu Feb 25 12:47:57 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 21:47:57 +0100
Subject: [PATCH] serial: ifx6x60: avoid uninitialized variable use
Message-ID: <1456433283-3761559-1-git-send-email-arnd@arndb.de>

gcc warns about a potential use of an uninitialized variable in this driver:

drivers/tty/serial/ifx6x60.c: In function 'ifx_spi_complete':
drivers/tty/serial/ifx6x60.c:713:6: warning: 'more' may be used uninitialized in this function [-Wmaybe-uninitialized]
   if (more || ifx_dev->spi_more || queue_length > 0 ||

Unlike a lot of other such warnings, this one is correct and describes
an actual problem in the handling of the "IFX_SPI_HEADER_F" result code.

This appears to be a result from a restructuring of the driver that
dates back to before it was merged in the kernel, so it's impossible
to know where it went wrong. I also don't know what that result code
means, so I have no idea if setting 'more' to zero is the correct
solution, but at least it makes the behavior reproducible rather than
depending on whatever happens to be on the kernel stack.

This patch initializes the 'more' variable to zero in each of the
three code paths that could result in undefined behavior before,
which is more explicit than initializing it at the start of the
function.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/tty/serial/ifx6x60.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/tty/serial/ifx6x60.c b/drivers/tty/serial/ifx6x60.c
index 88246f7e435a..2085a6cfa44b 100644
--- a/drivers/tty/serial/ifx6x60.c
+++ b/drivers/tty/serial/ifx6x60.c
@@ -395,8 +395,10 @@ static int ifx_spi_decode_spi_header(unsigned char *buffer, int *length,
 
 	if (h1 == 0 && h2 == 0) {
 		*received_cts = 0;
+		*more = 0;
 		return IFX_SPI_HEADER_0;
 	} else if (h1 == 0xffff && h2 == 0xffff) {
+		*more = 0;
 		/* spi_slave_cts remains as it was */
 		return IFX_SPI_HEADER_F;
 	}
@@ -688,6 +690,7 @@ static void ifx_spi_complete(void *ctx)
 			ifx_dev->rx_buffer + IFX_SPI_HEADER_OVERHEAD,
 			(size_t)actual_length);
 	} else {
+		more = 0;
 		dev_dbg(&ifx_dev->spi_dev->dev, "SPI transfer error %d",
 		       ifx_dev->spi_msg.status);
 	}
-- 
2.7.0



From arnd at arndb.de  Thu Feb 25 12:57:43 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 21:57:43 +0100
Subject: [PATCH, RESEND] ssb: host_soc depends on sprom
Message-ID: <1456433869-3919332-1-git-send-email-arnd@arndb.de>

Drivers that use the SSB sprom functionality typically 'select SSB_SPROM'
from Kconfig, but CONFIG_SSB_HOST_SOC misses this, which results in
a build failure unless at least one of the other drivers that selects
it is enabled:

drivers/built-in.o: In function `ssb_host_soc_get_invariants':
(.text+0x459494): undefined reference to `ssb_fill_sprom_with_fallback'

This adds the same select statement that is used elsewhere.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: 541c9a84cd85 ("ssb: pick SoC invariants code from MIPS BCM47xx arch")
---
 drivers/ssb/Kconfig | 1 +
 1 file changed, 1 insertion(+)

I just noticed this hasn't shown up in linux-next yet, so I'm resending
it to ensure it's still on someone's radar. Please ignore the resend
if it's already in a tree that is not part of linux-next but will
be merged eventually.

See https://patchwork.linux-mips.org/patch/12091/ for the original
submission.

diff --git a/drivers/ssb/Kconfig b/drivers/ssb/Kconfig
index 0c675861623f..d8e4219c2324 100644
--- a/drivers/ssb/Kconfig
+++ b/drivers/ssb/Kconfig
@@ -83,6 +83,7 @@ config SSB_SDIOHOST
 config SSB_HOST_SOC
 	bool "Support for SSB bus on SoC"
 	depends on SSB && BCM47XX_NVRAM
+	select SSB_SPROM
 	help
 	  Host interface for a SSB directly mapped into memory. This is
 	  for some Broadcom SoCs from the BCM47xx and BCM53xx lines.
-- 
2.7.0



From lho at apm.com  Thu Feb 25 12:58:11 2016
From: lho at apm.com (Loc Ho)
Date: Thu, 25 Feb 2016 12:58:11 -0800
Subject: [PATCH v3] ARM64: kernel: implement ACPI parking protocol
In-Reply-To: <20160225092427.GA31728@red-moon>
References: <1453806638-23167-1-git-send-email-lorenzo.pieralisi@arm.com>
 <20160202182657.GC15706@e104818-lin.cambridge.arm.com>
 <20160203112112.GA18387@red-moon>
 <20160203161834.GB26487@MBP.local>
 <20160224141832.GA26630@red-moon> <56CE3C9E.7070505@riken.jp>
 <20160225092427.GA31728@red-moon>
Message-ID: <CAPw-ZTmMVMztB6GTZPCtgoUKt9J2xAo1vBREzFZPUpZiS12Z+A@mail.gmail.com>

Hi,

> -- >8 --
> diff --git a/arch/arm64/kernel/acpi_parking_protocol.c b/arch/arm64/kernel/acpi_parking_protocol.c

I applies this to 4.5.0-rc5-next-20160225+ and boot just fine on
Mustang and Merlin with 8 CPU's.

Tested-by: Loc Ho <lho at apm.com>

-Loc


From andre.przywara at arm.com  Thu Feb 25 12:58:05 2016
From: andre.przywara at arm.com (=?UTF-8?Q?Andr=c3=a9_Przywara?=)
Date: Thu, 25 Feb 2016 20:58:05 +0000
Subject: [PATCH] clk: sunxi: allow PLL6 clock to be reused
In-Reply-To: <20160225181105.GE4736@lukather>
References: <1456105198-25295-1-git-send-email-andre.przywara@arm.com>
 <CAGb2v66Fkvpqay+pNYjN1KP_KSUmv-du+PVSsyeuK+Y7bzEt+g@mail.gmail.com>
 <56CAD72D.7050102@arm.com> <20160225181105.GE4736@lukather>
Message-ID: <56CF6ADD.1000803@arm.com>

On 25/02/16 18:11, Maxime Ripard wrote:
> On Mon, Feb 22, 2016 at 09:38:53AM +0000, Andre Przywara wrote:
>>>> diff --git a/drivers/clk/sunxi/clk-factors.h b/drivers/clk/sunxi/clk-factors.h
>>>> index 1e63c5b..3a7da86 100644
>>>> --- a/drivers/clk/sunxi/clk-factors.h
>>>> +++ b/drivers/clk/sunxi/clk-factors.h
>>>> @@ -36,6 +36,7 @@ struct factors_data {
>>>>         void (*getter)(struct factors_request *req);
>>>>         void (*recalc)(struct factors_request *req);
>>>>         const char *name;
>>>> +       int name_idx;
>>>
>>> I would drop the .name field. It was a bad workaround
>>> due to limitations of the factors clk code at the time
>>> by me. We really shouldn't hard-code the name if we want
>>> to reuse the driver.
>>
>> I know what you mean (my first thought, too) and I totally agree, but we
>> need it still for PLL5, which does not carry the original name in the DT
>> output names.
>> So at least this workaround here does not work, I guess we have to come
>> up with something different - which would be a different patch.
>> I can take a look into this later.
> 
> Actually, it could be easily worked around. Always take the first
> clock output name, take whatever is before '_', and you can remove the
> name field entirely.

Yeah, I was thinking about that, too, but wanted to give an easy patch a
try first.

> Jens did something along these lines here:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/379900.html

Indeed, I stumbled upon this by accident today. Looks great on the first
glance: using .self first, then the stub till the underscore. I can
review and test this, if needed.

> Maybe we should simply rebase this patch, and remove the part that
> falls back on the name field.

I am totally fine with this!

Thanks!
Andre.



From abrestic at chromium.org  Thu Feb 25 13:07:43 2016
From: abrestic at chromium.org (Andrew Bresticker)
Date: Thu, 25 Feb 2016 13:07:43 -0800
Subject: [PATCH V2] ARM64: tegra: Add support for Google Pixel C
In-Reply-To: <1454949199-27050-1-git-send-email-jonathanh@nvidia.com>
References: <1454949199-27050-1-git-send-email-jonathanh@nvidia.com>
Message-ID: <CAL1qeaHVuvwTkctEMo6TFggPPgqaQZDnKZGYn1QRUROpJ9Dhrw@mail.gmail.com>

Jon,

On Mon, Feb 8, 2016 at 8:33 AM, Jon Hunter <jonathanh at nvidia.com> wrote:
> Add initial device-tree support for Google Pixel C (a.k.a. Smaug) based
> upon Tegra210 SoC with 3 GiB of LPDDR4 RAM.
>
> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>

Reviewed-by: Andrew Bresticker <abrestic at chromium.org>

... and I booted up my Smaug with v4.5-rc5 + this patch, so:

Tested-by: Andrew Bresticker <abrestic at chromium.org>

Thanks,
Andrew

> ---
>  arch/arm64/boot/dts/nvidia/Makefile           |  1 +
>  arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 60 +++++++++++++++++++++++++++
>  2 files changed, 61 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
>
> diff --git a/arch/arm64/boot/dts/nvidia/Makefile b/arch/arm64/boot/dts/nvidia/Makefile
> index a7e865da1005..0f7cdf3e05c1 100644
> --- a/arch/arm64/boot/dts/nvidia/Makefile
> +++ b/arch/arm64/boot/dts/nvidia/Makefile
> @@ -2,6 +2,7 @@ dtb-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra132-norrin.dtb
>  dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2371-0000.dtb
>  dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2371-2180.dtb
>  dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-p2571.dtb
> +dtb-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210-smaug.dtb
>
>  always         := $(dtb-y)
>  clean-files    := *.dtb
> diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
> new file mode 100644
> index 000000000000..59acdb6b4f23
> --- /dev/null
> +++ b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
> @@ -0,0 +1,60 @@
> +/dts-v1/;
> +
> +#include "tegra210.dtsi"
> +
> +/ {
> +       model = "Google Pixel C";
> +       compatible = "google,smaug-rev8", "google,smaug-rev7",
> +                    "google,smaug-rev6", "google,smaug-rev5",
> +                    "google,smaug-rev4", "google,smaug-rev3",
> +                    "google,smaug-rev1", "google,smaug", "nvidia,tegra210";
> +
> +       aliases {
> +               serial0 = &uarta;
> +       };
> +
> +       chosen {
> +               bootargs = "earlycon";
> +               stdout-path = "serial0:115200n8";
> +       };
> +
> +       memory {
> +               device_type = "memory";
> +               reg = <0x0 0x80000000 0x0 0xc0000000>;
> +       };
> +
> +       serial at 0,70006000 {
> +               status = "okay";
> +       };
> +
> +       pmc at 0,7000e400 {
> +               nvidia,invert-interrupt;
> +               nvidia,suspend-mode = <0>;
> +               nvidia,cpu-pwr-good-time = <0>;
> +               nvidia,cpu-pwr-off-time = <0>;
> +               nvidia,core-pwr-good-time = <12000 6000>;
> +               nvidia,core-pwr-off-time = <39053>;
> +               nvidia,core-power-req-active-high;
> +               nvidia,sys-clock-req-active-high;
> +               status = "okay";
> +       };
> +
> +       sdhci at 0,700b0600 {
> +               bus-width = <8>;
> +               non-removable;
> +               status = "okay";
> +       };
> +
> +       clocks {
> +               compatible = "simple-bus";
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               clk32k_in: clock at 0 {
> +                       compatible = "fixed-clock";
> +                       reg = <0>;
> +                       #clock-cells = <0>;
> +                       clock-frequency = <32768>;
> +               };
> +       };
> +};
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


From maxime.ripard at free-electrons.com  Thu Feb 25 13:09:06 2016
From: maxime.ripard at free-electrons.com (Maxime Ripard)
Date: Thu, 25 Feb 2016 13:09:06 -0800
Subject: [PATCH 1/3] dt-bindings: arm/marvell: ABI unstability warning
 about Marvell 7K/8K
In-Reply-To: <20160225161642.GC10593@leverpostej>
References: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1456327007-31008-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160224172545.GC9137@leverpostej>
 <20160224211045.379352d3@free-electrons.com>
 <CAL_JsqLevrujSeYNBvSJA-5T0Ho8y7c0fKid7QvVm8LLvYLotw@mail.gmail.com>
 <20160225090927.13492cfb@free-electrons.com>
 <20160225161642.GC10593@leverpostej>
Message-ID: <20160225210906.GS4736@lukather>

Hi,

On Thu, Feb 25, 2016 at 04:16:47PM +0000, Mark Rutland wrote:
> On Thu, Feb 25, 2016 at 09:09:27AM +0100, Thomas Petazzoni wrote:
> > Hello Rob,
> > 
> > On Wed, 24 Feb 2016 16:07:04 -0600, Rob Herring wrote:
> > 
> > > You should fix the incomplete information problem. I pushed back on
> > > this, you got more information and already the binding is closer to
> > > reality.
> > 
> > "You should fix the incomplete information problem". You seem to think
> > that it is a simple thing that can be fixed with a magic wand. But it's
> > not.
> > 
> > Either because the internal processes are complicated, or simply
> > because the Linux kernel support is done without cooperation from the
> > HW vendor (it's not the case of this Marvell platform, but it's the
> > case of many other platforms).
> 
> Yes, this is a problem in some cases, and that should be considered in
> those cases. There are always shades of grey.
> 
> Per the above, that isn't relevant in this case. This is a pretty
> black-and-white stand against the usual rules.

Unless your stance, at least on the sunxi discussion was pretty much
black-and-white too. You basically said that we were supposed to
maintain a stable ABI starting right now, even though we know for a
fact that we have bindings that are simply not working.

> > > Mark didn't say don't submit. First, there is value in submitting even
> > > if not accepted immediately and you have to carry some patches for
> > > some time. It was also suggested that you err on the side of less
> > > information in DT if things are uncertain and you have not done that.
> > 
> > Submitting without merging is useless. The point of submitting is to
> > get the code merged, to reduce the amount of out-of-tree patches we
> > have to carry, and to allow users of the platform to simply run
> > mainline on their platform.
> 
> Submitting prototypes and RFCs is the usual way we get things reviewed
> early, and to allow maintainers and others to get a feel for things
> earlier. Submitting patches _for merging_ when you're not sure about
> things and don't want to agree to support them is what's being pushed
> back on.

Just to make sure we're on the same page, are you saying that we must
not merge code unless we're 100% sure of how it works, in its
entirety?

> > So this proposal really doesn't make any sense. Just like Mark initial
> > statement of not submitting code so early.
> 
> As what I said was evidently ambiguous, I'm on about code being _merged_
> prior to being ready. Code and bindings should certainly be posted for
> review as soon as possible. However, it should be recognised when things
> aren't quite ready for mainline.
> 
> Even if something's unclear about a device, you can highlight more
> general issues (e.g. problematic edge cases in common subsystem code),
> and that's possible to have merged even if the binding isn't ready.
> 
> If you're unsure about something, but still want it merged, then you
> have to commit to maintaining that as far as reasonably possible, even
> if it turns out to not be quite right.

Except that *you* are forcing us to maintain code to deal with a use
case that simply doesn't happen, which is the definition of dead code.

Would you be ok to be forced to maintain dead code?

You've been talking about theorical use-cases, do you have any real
world one where someone actually made a case for this DT as an ABI
non-sense?

I mean, we've had the U-Boot sunxi maintainer saying they didn't care,
and actually arguing against it.

As it turns out, he's also involved in the Fedora port. If it was a
pain point for them, don't you think he would have raised it?

The only ones that seem to have a problem with it are the one not
involved in it in any way.

> 
> > > > So please get to an agreement between DT binding maintainers. And stop
> > > > saying this ridiculous statement that HW vendors should stop submitting
> > > > their code to the mainline.
> > > 
> > > You want us to agree, then you won't like the answer. Bindings must be
> > > stable. I'll allow exceptions to that, but not without push back.
> > > 
> > > In general, if there is disagreement about whether stability is
> > > required, then it is required. See the recent sunxi discussion. That's
> > > more between users and platform maintainers though.
> > 
> > Do you realize that this all DT binding stuff is today the *biggest* to
> > getting HW support in the Linux kernel? It has become more complicated
> > to merge a 4 properties DT binding than to merge multiple thousands of
> > lines of driver code. 
> 
> As times have changed, pain points have moved around.
> 
> To some extent that is unavoidable; more up-front effort is required
> where crutches we previously relied on are not applicable.
> 
> Elsewhere we can certainly do better.
> 
> Throwing your hands up and stating "this is unstable, it might change"
> is a crutch. It prevents any real solution to the pain points you
> encounter, and creates pain points for others. It only provides the
> _illusion_ of support.

https://kernelci.org/soc/mvebu/
https://kernelci.org/soc/sunxi/

I guess we should become magicians.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/749d2be4/attachment-0001.sig>

From arnd at arndb.de  Thu Feb 25 13:09:57 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 22:09:57 +0100
Subject: [PATCH, RESEND] drm: avoid uninitialized timestamp use in wait_vblank
Message-ID: <1456434600-4185759-1-git-send-email-arnd@arndb.de>

gcc warns about the timestamp in drm_wait_vblank being possibly
used without an initialization:

drivers/gpu/drm/drm_irq.c: In function 'drm_wait_vblank':
drivers/gpu/drm/drm_irq.c:1755:28: warning: 'now.tv_usec' may be used uninitialized in this function [-Wmaybe-uninitialized]
   vblwait->reply.tval_usec = now.tv_usec;
drivers/gpu/drm/drm_irq.c:1754:27: warning: 'now.tv_sec' may be used uninitialized in this function [-Wmaybe-uninitialized]
   vblwait->reply.tval_sec = now.tv_sec;

This can happen if drm_vblank_count_and_time() returns 0 in its
error path. To sanitize the error case, I'm changing that function
to return a zero timestamp when it fails.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: e6ae8687a87b ("drm: idiot-proof vblank")
---
 drivers/gpu/drm/drm_irq.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

I'm going through the maybe-unused warnings in randconfig builds, this one is
apparently not a false positive, although it only happens if something
else has already gone wrong.

Originally sent out on Jan 13, but I received no reply, so resending now.

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 881c5a6c180c..6f41ddfbe061 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -997,8 +997,10 @@ u32 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
 	int count = DRM_TIMESTAMP_MAXRETRIES;
 	u32 cur_vblank;
 
-	if (WARN_ON(pipe >= dev->num_crtcs))
+	if (WARN_ON(pipe >= dev->num_crtcs)) {
+		*vblanktime = (struct timeval) { 0 };
 		return 0;
+	}
 
 	/*
 	 * Vblank timestamps are read lockless. To ensure consistency the vblank
-- 
2.7.0



From arnd at arndb.de  Thu Feb 25 13:11:42 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 22:11:42 +0100
Subject: [PATCH, RESEND] drm/sti: use u32 to store DMA addresses
Message-ID: <1456434711-48393-1-git-send-email-arnd@arndb.de>

The STi drm driver correctly warns about invalid format strings
when built with 64-bit dma_addr_t:

sti_hqvdp.c: In function 'sti_hqvdp_vtg_cb':
sti_hqvdp.c:605:119: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
sti_hqvdp.c: In function 'sti_hqvdp_atomic_update':
sti_hqvdp.c:931:118: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]

This could be changed to using the %pad format string, but that
does not work when printing an rvalue, so instead I'm changing
the type in the sti_hqvdp structure to u32, which is what gets
written into the registers anyway.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 drivers/gpu/drm/sti/sti_hqvdp.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

I originally submitted this on Tue, 08 Dec 2015, but got no reply,
so resending the same patch now.

diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index 1d3c3d029603..7818d47bea43 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -349,7 +349,7 @@ struct sti_hqvdp {
 	unsigned int curr_field_count;
 	unsigned int last_field_count;
 	void *hqvdp_cmd;
-	dma_addr_t hqvdp_cmd_paddr;
+	u32 hqvdp_cmd_paddr;
 	struct sti_vtg *vtg;
 	bool xp70_initialized;
 };
@@ -372,8 +372,8 @@ static const uint32_t hqvdp_supported_formats[] = {
  */
 static int sti_hqvdp_get_free_cmd(struct sti_hqvdp *hqvdp)
 {
-	int curr_cmd, next_cmd;
-	dma_addr_t cmd = hqvdp->hqvdp_cmd_paddr;
+	u32 curr_cmd, next_cmd;
+	u32 cmd = hqvdp->hqvdp_cmd_paddr;
 	int i;
 
 	curr_cmd = readl(hqvdp->regs + HQVDP_MBX_CURRENT_CMD);
@@ -400,8 +400,8 @@ static int sti_hqvdp_get_free_cmd(struct sti_hqvdp *hqvdp)
  */
 static int sti_hqvdp_get_curr_cmd(struct sti_hqvdp *hqvdp)
 {
-	int curr_cmd;
-	dma_addr_t cmd = hqvdp->hqvdp_cmd_paddr;
+	u32 curr_cmd;
+	u32 cmd = hqvdp->hqvdp_cmd_paddr;
 	unsigned int i;
 
 	curr_cmd = readl(hqvdp->regs + HQVDP_MBX_CURRENT_CMD);
@@ -612,19 +612,21 @@ int sti_hqvdp_vtg_cb(struct notifier_block *nb, unsigned long evt, void *data)
 static void sti_hqvdp_init(struct sti_hqvdp *hqvdp)
 {
 	int size;
+	dma_addr_t dma_addr;
 
 	hqvdp->vtg_nb.notifier_call = sti_hqvdp_vtg_cb;
 
 	/* Allocate memory for the VDP commands */
 	size = NB_VDP_CMD * sizeof(struct sti_hqvdp_cmd);
 	hqvdp->hqvdp_cmd = dma_alloc_wc(hqvdp->dev, size,
-					&hqvdp->hqvdp_cmd_paddr,
+					&dma_addr,
 					GFP_KERNEL | GFP_DMA);
 	if (!hqvdp->hqvdp_cmd) {
 		DRM_ERROR("Failed to allocate memory for VDP cmd\n");
 		return;
 	}
 
+	hqvdp->hqvdp_cmd_paddr = (u32)dma_addr;
 	memset(hqvdp->hqvdp_cmd, 0, size);
 }
 
-- 
2.7.0



From rjw at rjwysocki.net  Thu Feb 25 13:24:34 2016
From: rjw at rjwysocki.net (Rafael J. Wysocki)
Date: Thu, 25 Feb 2016 22:24:34 +0100
Subject: [RFC PATCH v3 3/3] PCI/ACPI: hisi: Add ACPI support for HiSilicon
 SoCs Host Controllers
In-Reply-To: <20160225195912.GA4818@localhost>
References: <20160209182429.GD4348@leverpostej>
 <20160225120750.GA32016@red-moon> <20160225195912.GA4818@localhost>
Message-ID: <8105311.kD8XXIcipM@vostro.rjw.lan>

On Thursday, February 25, 2016 01:59:12 PM Bjorn Helgaas wrote:
> On Thu, Feb 25, 2016 at 12:07:50PM +0000, Lorenzo Pieralisi wrote:
> > On Thu, Feb 25, 2016 at 03:01:19AM +0000, Gabriele Paoloni wrote:
> > 
> > [...]
> > 
> > > > I think the relevant spec is the PCI Firmware Spec, r3.0, sec 4.1.2.
> > > > Note 2 in that section says the address range of an MMCFG region
> > > > must be reserved by declaring a motherboard resource, i.e., included
> > > > in the _CRS of a PNP0C02 or similar device.
> > > 
> > > I had a look a this. So yes the specs says that we should use the 
> > > PNP0C02 device if MCFG is not supported. 
> > 
> > AFAIK, PNP0C02 is a resource reservation mechanism, the spec says that
> > MCFG regions must be reserved using PNP0C02, even though its
> > current usage on x86 is a bit unfathomable to me, in particular
> > in relation to MCFG resources retrieved for hotpluggable bridges (ie
> > through _CBA, which I think consider the MCFG region as reserved
> > by default, regardless of PNP0c02):
> > 
> > see pci_mmcfg_check_reserved() arch/x86/pci/mmconfig-shared.c
> 
> I don't know how _CBA-related resources would be reserved.  I haven't
> personally worked with any host bridges that supply _CBA, so I don't
> know whether or how they handled it.
> 
> I think the spec intent was that the Consumer/Producer bit (Extended
> Address Space Descriptor, General Flags Bit[0], see ACPI spec sec
> 6.4.3.5.4) would be used.  Resources such as ECAM areas would be
> marked "Consumer", meaning the bridge consumed that space itself, and
> windows passed down to the PCI bus would be marked "Producer".
> 
> But BIOSes didn't use that bit consistently, so we couldn't rely on
> it.  I verified experimentally that Windows didn't pay attention to
> that bit either, at least for DWord descriptors:
> https://bugzilla.kernel.org/show_bug.cgi?id=15701
> 
> It's conceivable that we could still use that bit in Extended Address
> Space descriptors, or maybe some hack like pay attention if the bridge
> has _CBA, or some such.

Last time I asked the firmware vendor people in the ASWG about that,
the answer was that the Consumer/Producer bit was useless as they had
never paid any attention to it in general.

It may be good to update the spec to say something along these lines, actually.

Thanks,
Rafael



From arnd at arndb.de  Thu Feb 25 13:25:18 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 22:25:18 +0100
Subject: [PATCH, RESEND] xen: allocate gntdev_copy_batch dynamically
Message-ID: <1456435523-287763-1-git-send-email-arnd@arndb.de>

struct gntdev_copy_batch is arguably too large to fit on the kernel stack,
and we get a warning about the stack usage in gntdev_ioctl_grant_copy:

drivers/xen/gntdev.c:949:1: error: the frame size of 1240 bytes is larger than 1024 bytes

This changes the code to us a dynamic allocation instead.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: a4cdb556cae0 ("xen/gntdev: add ioctl for grant copy")
---
 drivers/xen/gntdev.c | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

I sent this in January, Boris sent an almost identical patch
as http://www.gossamer-threads.com/lists/xen/devel/414056
but the bug remains present in mainline and linux-next as of
Feb 25.

Could you apply one of the patches before the bug makes it
into v4.5?

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index dc495383ad73..cc753b3a7154 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -915,15 +915,16 @@ static int gntdev_grant_copy_seg(struct gntdev_copy_batch *batch,
 static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
 {
 	struct ioctl_gntdev_grant_copy copy;
-	struct gntdev_copy_batch batch;
+	struct gntdev_copy_batch *batch;
 	unsigned int i;
 	int ret = 0;
 
 	if (copy_from_user(&copy, u, sizeof(copy)))
 		return -EFAULT;
 
-	batch.nr_ops = 0;
-	batch.nr_pages = 0;
+	batch = kzalloc(sizeof(*batch), GFP_KERNEL);
+	if (!batch)
+		return -ENOMEM;
 
 	for (i = 0; i < copy.count; i++) {
 		struct gntdev_grant_copy_segment seg;
@@ -933,18 +934,20 @@ static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
 			goto out;
 		}
 
-		ret = gntdev_grant_copy_seg(&batch, &seg, &copy.segments[i].status);
+		ret = gntdev_grant_copy_seg(batch, &seg, &copy.segments[i].status);
 		if (ret < 0)
 			goto out;
 
 		cond_resched();
 	}
-	if (batch.nr_ops)
-		ret = gntdev_copy(&batch);
+	if (batch->nr_ops)
+		ret = gntdev_copy(batch);
+	kfree(batch);
 	return ret;
 
   out:
-	gntdev_put_pages(&batch);
+	gntdev_put_pages(batch);
+	kfree(batch);
 	return ret;
 }
 
-- 
2.7.0



From davem at davemloft.net  Thu Feb 25 13:25:48 2016
From: davem at davemloft.net (David Miller)
Date: Thu, 25 Feb 2016 16:25:48 -0500 (EST)
Subject: [PATCH] net: thunderx: Fix for Qset error due to CQ full
In-Reply-To: <1456312250-25694-1-git-send-email-sunil.kovvuri@gmail.com>
References: <1456312250-25694-1-git-send-email-sunil.kovvuri@gmail.com>
Message-ID: <20160225.162548.782902392289793973.davem@davemloft.net>

From: sunil.kovvuri at gmail.com
Date: Wed, 24 Feb 2016 16:40:50 +0530

> From: Sunil Goutham <sgoutham at cavium.com>
> 
> On Thunderx pass 1.x and pass2 due to a HW errata default CQ
> DROP_LEVEL of 0x80 is not sufficient to avoid CQ_WR_FULL Qset
> error when packets are being received at >20Mpps resulting in
> complete stall of packet reception.
> 
> This patch will configure it to 0x100 which is what is expected
> by HW on Thunderx. On future passes of thunderx and other chips
> HW default/reset value will be 0x100 or higher hence not overwritten.
> 
> Signed-off-by: Jerin Jacob <jerin.jacob at caviumnetworks.com>
> Signed-off-by: Sunil Goutham <sgoutham at cavium.com>

Applied, thank you.


From olof at lixom.net  Thu Feb 25 13:27:37 2016
From: olof at lixom.net (Olof Johansson)
Date: Thu, 25 Feb 2016 13:27:37 -0800
Subject: [GIT PULL] ARM: mvebu: arm64 for v4.6 (#1)
In-Reply-To: <87wppsoonx.fsf@free-electrons.com>
References: <878u2js4cn.fsf@free-electrons.com>
 <20160225005543.GA29055@localhost>
 <87wppsoonx.fsf@free-electrons.com>
Message-ID: <CAOesGMjKimrCW=z_s5g7pk5pAr7YOqQPoDukfxtWg-HfG=anrA@mail.gmail.com>

On Thu, Feb 25, 2016 at 6:22 AM, Gregory CLEMENT
<gregory.clement at free-electrons.com> wrote:
> Hi Olof,
>
>  On jeu., f?vr. 25 2016, Olof Johansson <olof at lixom.net> wrote:
>
>> On Wed, Feb 17, 2016 at 05:12:40PM +0100, Gregory CLEMENT wrote:
>>> Hi,
>>>
>>> Here is the first pull request for arm64 for mvebu for v4.6. It is even
>>> the first pull request ever for arm64 for us. Let me know if I am doing
>>> it wrong.
>>>
>>> I split my initial series[1] in two parts: device tree related and non
>>> device tree related. I will also let the driver maintainers directly
>>> take the related patch for ATA and serial.
>>>
>>> For this non device tree part I have a dependency with the irchip
>>> subsystem. For this I based on the irqchip/mvebu immutable branch form
>>> Jason Cooper located at git://git.infradead.org/users/jcooper/linux.git.
>>>
>>> Thanks,
>>>
>>> Gregory
>>>
>>> [1]: https://lkml.org/lkml/2016/2/16/735
>>>
>>> The following changes since commit 63131b636a0ec969e8b98122c1a928b5a2649d3b:
>>>
>>>   irqchip/armada-370-xp: Do not enable it by default when ARCH_MVEBU is selected (2016-02-16 18:11:39 +0000)
>>
>> PLease do this by explicit merge instead in the future, so it's obvious that
>> there is an external branch merged in history later.
>>
>> That way, doing the full diffstat including the merge is just fine too.
>
> Actually I did an explicite merge but my start commit for the pull
> request was the last commit of the merged branch. So if I undrestand
> well, I sould have used the v4.5-rc2 here as start commit.

Or use --no-ff so you get a merge commit instead of a fast-forward.


-Olof


From dan.carpenter at oracle.com  Thu Feb 25 13:31:16 2016
From: dan.carpenter at oracle.com (Dan Carpenter)
Date: Fri, 26 Feb 2016 00:31:16 +0300
Subject: [patch] soc: ti: wkup_m3_ipc: Fix an error code
Message-ID: <20160225213116.GB18267@mwanda>

We accidentally return success if we can't load firmware but we intended
to return a negative error code.

Fixes: cdd5de500b2c ('soc: ti: Add wkup_m3_ipc driver')
Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com>

diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
index 8823cc8..5bb3760 100644
--- a/drivers/soc/ti/wkup_m3_ipc.c
+++ b/drivers/soc/ti/wkup_m3_ipc.c
@@ -459,6 +459,7 @@ static int wkup_m3_ipc_probe(struct platform_device *pdev)
 
 	if (IS_ERR(task)) {
 		dev_err(dev, "can't create rproc_boot thread\n");
+		ret = PTR_ERR(task);
 		goto err_put_rproc;
 	}
 


From arnd at arndb.de  Thu Feb 25 13:34:27 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 22:34:27 +0100
Subject: [PATCH] pci: stub out some MSI functions
Message-ID: <1456436095-607394-1-git-send-email-arnd@arndb.de>

A bug fix to the MSIx handling in vfio added references
to functions that may not be defined if MSI is disabled in the kernel,
resulting in this link error:

drivers/built-in.o: In function `vfio_msi_set_vector_signal':
:(.text+0x450808): undefined reference to `get_cached_msi_msg'
:(.text+0x45080c): undefined reference to `write_msi_msg'

When MSI is disabled, we should never get into this code path,
so by adding stub implementations we can avoid the link error
without causing any other changes.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
Fixes: b8f02af096b1 ("vfio/pci: Restore MSIx message prior to enabling")
Link: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/294293.html
---
 include/linux/msi.h | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/include/linux/msi.h b/include/linux/msi.h
index 8b425c66305a..ae9a65cd6d43 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -17,7 +17,15 @@ struct msi_desc;
 struct pci_dev;
 struct platform_msi_priv_data;
 void __get_cached_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
+
+#ifdef CONFIG_PCI_MSI
 void get_cached_msi_msg(unsigned int irq, struct msi_msg *msg);
+#else
+static inline void get_cached_msi_msg(unsigned int irq,
+				      struct msi_msg *msg)
+{
+}
+#endif
 
 typedef void (*irq_write_msi_msg_t)(struct msi_desc *desc,
 				    struct msi_msg *msg);
@@ -125,7 +133,14 @@ struct msi_desc *alloc_msi_entry(struct device *dev);
 void free_msi_entry(struct msi_desc *entry);
 void __pci_read_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
 void __pci_write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
+
+#ifdef CONFIG_PCI_MSI
 void pci_write_msi_msg(unsigned int irq, struct msi_msg *msg);
+#else
+static inline void pci_write_msi_msg(unsigned int irq, struct msi_msg *msg)
+{
+}
+#endif
 
 u32 __pci_msix_desc_mask_irq(struct msi_desc *desc, u32 flag);
 u32 __pci_msi_desc_mask_irq(struct msi_desc *desc, u32 mask, u32 flag);
-- 
2.7.0



From ssantosh at kernel.org  Thu Feb 25 13:49:17 2016
From: ssantosh at kernel.org (Santosh Shilimkar)
Date: Thu, 25 Feb 2016 13:49:17 -0800
Subject: [GIT PULL v2] ARM: Keystone DTS for 4.6 
Message-ID: <1456436957-22836-1-git-send-email-ssantosh@kernel.org>

Find updated pull request renaming the newly added DTS files. 

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone_dts_for_4.6_v2

for you to fetch changes up to 5b7551db86884c54bf1d2e2a943d4ec3f5463da8:

  ARM: dts: keystone: Add minimum support for K2G evm (2016-02-25 09:27:39 -0800)

----------------------------------------------------------------
ARM: DTS: Add new bindings for K2G and the K2G evm

K2G SoC family is the newest version of the Keystone family of processors.

The technical reference manual for K2G can be found here:
http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf

----------------------------------------------------------------
Nishanth Menon (1):
      ARM: keystone: Create new binding for K2G SoC

Vitaly Andrianov (2):
      ARM: dts: keystone: Add Initial DT support for TI K2G SoC family
      ARM: dts: keystone: Add minimum support for K2G evm

 .../devicetree/bindings/arm/keystone/keystone.txt  |  5 ++
 arch/arm/boot/dts/Makefile                         |  3 +-
 arch/arm/boot/dts/keystone-k2g-evm.dts             | 32 ++++++++
 arch/arm/boot/dts/keystone-k2g.dtsi                | 89 ++++++++++++++++++++++
 arch/arm/mach-keystone/keystone.c                  |  1 +
 5 files changed, 129 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/keystone-k2g-evm.dts
 create mode 100644 arch/arm/boot/dts/keystone-k2g.dtsi


From khilman at baylibre.com  Thu Feb 25 13:55:23 2016
From: khilman at baylibre.com (Kevin Hilman)
Date: Thu, 25 Feb 2016 13:55:23 -0800
Subject: [PATCH] drivers: perf: arm: implement CPU_PM notifier
In-Reply-To: <20160225164354.GE16546@arm.com> (Will Deacon's message of "Thu, 
 25 Feb 2016 16:43:54 +0000")
References: <1456251759-24768-1-git-send-email-lorenzo.pieralisi@arm.com>
 <7hsi0hr3wj.fsf@baylibre.com> <20160225094417.GB31728@red-moon>
 <CANLsYkzq_oFLZ-ijBtxHp2rU=NR5R1PLb0znv2zPTv=4Z2isGA@mail.gmail.com>
 <20160225164354.GE16546@arm.com>
Message-ID: <7h7fhso3p0.fsf@baylibre.com>

Will Deacon <will.deacon at arm.com> writes:

> On Thu, Feb 25, 2016 at 09:32:17AM -0700, Mathieu Poirier wrote:
>> On 25 February 2016 at 02:44, Lorenzo Pieralisi
>> <lorenzo.pieralisi at arm.com> wrote:
>> > On Wed, Feb 24, 2016 at 05:10:20PM -0800, Kevin Hilman wrote:
>> >> Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> writes:
>> >>
>> >> > When a CPU is suspended (either through suspend-to-RAM or CPUidle),
>> >> > its PMU registers content can be lost, which means that counters
>> >> > registers values that were initialized on power down entry have to be
>> >> > reprogrammed on power-up to make sure the counters set-up is preserved
>> >>
>> >> This assumes that the PMUs are always sharing a power rail with a
>> >> specific CPU, not the cluster.  Is that a reliable assumption?
>> >
>> > As reliable as assuming the GIC HW state needs save/restore on idle-state
>> > entry, if we have no power domains information linked to CPU PM
>> > notifiers saving/restoring everything every time an idle state deeper
>> > than wfi is entered is the best we can do.
>> >
>> > As far as this patch is concerned, if the PMU is on a different power
>> > domain than the CPU, I agree that stopping/resetting/restoring the
>> > PMU registers is a waste of cycles (I will test it also by triggering
>> > the notifiers on wfi, to make sure the reset is not disruptive on
>> > a cpu that is not powered off), I see no alternative other than disabling
>> > idle to carry out profiling sanely (or implement CPU PM notifiers with
>> > runtime PM).
>> 
>> I totally understand - I'm faced with the same problem on Coresight.
>> To me the ultimate solution is still to integrate CPU power domain
>> management with runtime PM (like we talked about many times before).
>> I know Lina is working on something that will get us close to that but
>> it's not finished yet.
>
> I've been waiting for that code for *years* now...

It's still coming... ;)

But, I didn't mean to suggest this patch should wait for a PM domain
based solution, I just wanted to be clear about the assumptions.  I have
no objections to this patch as it fixes a long-standing issue.

Acked-by: Kevin Hilman <khilman at baylibre.com>

Kevin


From arnd at arndb.de  Thu Feb 25 14:02:04 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 23:02:04 +0100
Subject: [PATCH RESEND] ASoC: pxa: remove unused variable
Message-ID: <1456437736-732609-1-git-send-email-arnd@arndb.de>

As pointed out by Zhangfei Gao, the sspa_div variable in
brownstone_wm8994_hw_params() is completely unused, so as a cleanup
following a prior patch, this removes both the variable and the division.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
Submitted originally on Nov 23 2015, this apparently got lost,
resending it now.

 sound/soc/pxa/brownstone.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/sound/soc/pxa/brownstone.c b/sound/soc/pxa/brownstone.c
index 416ea646c3b1..ec522e94b0e2 100644
--- a/sound/soc/pxa/brownstone.c
+++ b/sound/soc/pxa/brownstone.c
@@ -52,7 +52,6 @@ static int brownstone_wm8994_hw_params(struct snd_pcm_substream *substream,
 	struct snd_soc_dai *codec_dai = rtd->codec_dai;
 	struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
 	int freq_out, sspa_mclk, sysclk;
-	int sspa_div;
 
 	if (params_rate(params) > 11025) {
 		freq_out  = params_rate(params) * 512;
@@ -63,7 +62,6 @@ static int brownstone_wm8994_hw_params(struct snd_pcm_substream *substream,
 		sysclk    = params_rate(params) * 512;
 		sspa_mclk = params_rate(params) * 64;
 	}
-	sspa_div = freq_out / sspa_mclk;
 
 	snd_soc_dai_set_sysclk(cpu_dai, MMP_SSPA_CLK_AUDIO, freq_out, 0);
 	snd_soc_dai_set_pll(cpu_dai, MMP_SYSCLK, 0, freq_out, sysclk);
-- 
2.7.0



From arnd at arndb.de  Thu Feb 25 14:04:50 2016
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 25 Feb 2016 23:04:50 +0100
Subject: [PATCH] ARM: s3c24xx: avoid warning for inb/outb
Message-ID: <1456437900-853667-1-git-send-email-arnd@arndb.de>

s3c24xx implements its own inb/outb macros, but the implementation
prints warnings when the port number argument is not a 32-bit scalar:

drivers/scsi/pas16.c: In function 'NCR5380_pwrite':
arch/arm/mach-s3c24xx/include/mach/io.h:193:68: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
 #define __ioaddrc(port) ((__PORT_PCIO(port) ? PCIO_BASE + (port) : (void __iomem *)(port)))

This slightly modifies the definition of the __ioaddrc macro to avoid
the warning.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
 arch/arm/mach-s3c24xx/include/mach/io.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-s3c24xx/include/mach/io.h b/arch/arm/mach-s3c24xx/include/mach/io.h
index 5dd1db4e2677..235c53647aa4 100644
--- a/arch/arm/mach-s3c24xx/include/mach/io.h
+++ b/arch/arm/mach-s3c24xx/include/mach/io.h
@@ -190,7 +190,7 @@ DECLARE_IO(int,l,"")
 	result;								\
 })
 
-#define __ioaddrc(port)	((__PORT_PCIO(port) ? PCIO_BASE + (port) : (void __iomem *)(port)))
+#define __ioaddrc(port)	((__PORT_PCIO(port) ? PCIO_BASE + (port) : (void __iomem *)0 + (port)))
 
 #define inb(p)		(__builtin_constant_p((p)) ? __inbc(p)	   : __inb(p))
 #define inw(p)		(__builtin_constant_p((p)) ? __inwc(p)	   : __inw(p))
-- 
2.7.0



From manabian at gmail.com  Thu Feb 25 14:04:45 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Thu, 25 Feb 2016 23:04:45 +0100
Subject: [PATCH 0/2] PINT irqchip driver for NXP LPC18xx family
Message-ID: <1456437887-24432-1-git-send-email-manabian@gmail.com>

The LPC1850 has no less than 3 GPIO interrupt blocks. One of these
blocks is called 'gpio pin interrupt' or just PINT. LPC1850 PINT can
handle up to 8 interrupts and these have a one-to-one relationship with
the main interrupt controller (NVIC).

The interrupts on PINT can be either level or edge trigger and supports
any polarity.

This patch set adds an irqchip driver for the PINT found on lpc18xx.

Joachim Eastwood (2):
  irqchip: add lpc18xx gpio pin interrupt driver
  devicetree: document NXP LPC1850 PINT irq controller binding

 .../interrupt-controller/nxp,lpc1850-gpio-pint.txt |  22 ++
 drivers/irqchip/Kconfig                            |   5 +
 drivers/irqchip/Makefile                           |   1 +
 drivers/irqchip/irq-lpc18xx-gpio-pint.c            | 238 +++++++++++++++++++++
 4 files changed, 266 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/nxp,lpc1850-gpio-pint.txt
 create mode 100644 drivers/irqchip/irq-lpc18xx-gpio-pint.c

-- 
1.8.0



From manabian at gmail.com  Thu Feb 25 14:04:46 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Thu, 25 Feb 2016 23:04:46 +0100
Subject: [PATCH 1/2] irqchip: add lpc18xx gpio pin interrupt driver
In-Reply-To: <1456437887-24432-1-git-send-email-manabian@gmail.com>
References: <1456437887-24432-1-git-send-email-manabian@gmail.com>
Message-ID: <1456437887-24432-2-git-send-email-manabian@gmail.com>

NXP LPC18xx has an interrupt controller called 'gpio pin interrupt'
or just PINT. The PINT can handle up to 8 interrupts and these have
a one-to-one relationship with the main interrupt controller (NVIC).
The interrupts on PINT can be either level or edge trigger and
supports any polarity.

Selection of which GPIOs that are connected to the PINT is done by
the lpc18xx pinctrl driver (SCU).

Signed-off-by: Joachim Eastwood <manabian at gmail.com>
---
 drivers/irqchip/Kconfig                 |   5 +
 drivers/irqchip/Makefile                |   1 +
 drivers/irqchip/irq-lpc18xx-gpio-pint.c | 238 ++++++++++++++++++++++++++++++++
 3 files changed, 244 insertions(+)
 create mode 100644 drivers/irqchip/irq-lpc18xx-gpio-pint.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 715923d5236c..4d26b2e82e0c 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -190,6 +190,11 @@ config KEYSTONE_IRQ
 		Support for Texas Instruments Keystone 2 IRQ controller IP which
 		is part of the Keystone 2 IPC mechanism
 
+config LPC18XX_GPIO_PINT
+	bool
+	select IRQ_DOMAIN
+	select GENERIC_IRQ_CHIP
+
 config MIPS_GIC
 	bool
 	select MIPS_CM
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 18caacb60d58..ae6e05e4347d 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_BCM7038_L1_IRQ)		+= irq-bcm7038-l1.o
 obj-$(CONFIG_BCM7120_L2_IRQ)		+= irq-bcm7120-l2.o
 obj-$(CONFIG_BRCMSTB_L2_IRQ)		+= irq-brcmstb-l2.o
 obj-$(CONFIG_KEYSTONE_IRQ)		+= irq-keystone.o
+obj-$(CONFIG_LPC18XX_GPIO_PINT)		+= irq-lpc18xx-gpio-pint.o
 obj-$(CONFIG_MIPS_GIC)			+= irq-mips-gic.o
 obj-$(CONFIG_ARCH_MEDIATEK)		+= irq-mtk-sysirq.o
 obj-$(CONFIG_ARCH_DIGICOLOR)		+= irq-digicolor.o
diff --git a/drivers/irqchip/irq-lpc18xx-gpio-pint.c b/drivers/irqchip/irq-lpc18xx-gpio-pint.c
new file mode 100644
index 000000000000..4dc791681016
--- /dev/null
+++ b/drivers/irqchip/irq-lpc18xx-gpio-pint.c
@@ -0,0 +1,238 @@
+/*
+ * Irqchip driver for GPIO Pin Interrupt (PINT) on NXP LPC18xx/43xx.
+ *
+ * Copyright (C) 2015 Joachim Eastwood <manabian at gmail.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.
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/init.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+
+/* LPC18xx GPIO pin interrupt register offsets */
+#define LPC18XX_GPIO_PINT_ISEL		0x000
+#define LPC18XX_GPIO_PINT_SIENR		0x008
+#define LPC18XX_GPIO_PINT_CIENR		0x00c
+#define LPC18XX_GPIO_PINT_SIENF		0x014
+#define LPC18XX_GPIO_PINT_CIENF		0x018
+#define LPC18XX_GPIO_PINT_IST		0x024
+
+struct lpc18xx_gpio_pint_chip {
+	struct irq_domain *domain;
+	void __iomem	  *base;
+	struct clk	  *clk;
+	int		  *irqmap;
+	int		  nrirqs;
+};
+
+static void lpc18xx_gpio_pint_handler(struct irq_desc *desc)
+{
+	struct lpc18xx_gpio_pint_chip *pint = irq_desc_get_handler_data(desc);
+	unsigned int irq = irq_desc_get_irq(desc);
+	int irq_no, i;
+
+	/* Find the interrupt */
+	for (i = 0; i < pint->nrirqs; i++) {
+		if (pint->irqmap[i] == irq) {
+			irq_no = irq_find_mapping(pint->domain, i);
+			generic_handle_irq(irq_no);
+		}
+	}
+}
+
+static void lpc18xx_gpio_pint_edge_ack(struct irq_data *d)
+{
+	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+	u32 mask = d->mask;
+
+	irq_gc_lock(gc);
+	irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_IST);
+	irq_gc_unlock(gc);
+}
+
+static void lpc18xx_gpio_pint_edge_mask(struct irq_data *d)
+{
+	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+	u32 mask = d->mask;
+
+	irq_gc_lock(gc);
+	irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_CIENR);
+	irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_CIENF);
+	irq_gc_unlock(gc);
+}
+
+static void lpc18xx_gpio_pint_edge_unmask(struct irq_data *d)
+{
+	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+	u32 type, mask = d->mask;
+
+	irq_gc_lock(gc);
+	type = irqd_get_trigger_type(d);
+	if (type & IRQ_TYPE_EDGE_RISING)
+		irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_SIENR);
+	if (type & IRQ_TYPE_EDGE_FALLING)
+		irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_SIENF);
+	irq_gc_unlock(gc);
+}
+
+static void lpc18xx_gpio_pint_level_mask(struct irq_data *d)
+{
+	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+	u32 mask = d->mask;
+
+	irq_gc_lock(gc);
+	irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_CIENR);
+	irq_gc_unlock(gc);
+}
+
+static void lpc18xx_gpio_pint_level_unmask(struct irq_data *d)
+{
+	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+	u32 mask = d->mask;
+
+	irq_gc_lock(gc);
+	irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_SIENR);
+	irq_gc_unlock(gc);
+}
+
+static int lpc18xx_gpio_pint_type(struct irq_data *data, unsigned int type)
+{
+	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+	u32 mask = data->mask;
+
+	irq_gc_lock(gc);
+	if (type & IRQ_TYPE_LEVEL_MASK)
+		gc->type_cache |= mask;
+	else
+		gc->type_cache &= ~mask;
+	irq_reg_writel(gc, gc->type_cache, LPC18XX_GPIO_PINT_ISEL);
+
+	switch (type) {
+	case IRQ_TYPE_LEVEL_HIGH:
+		irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_SIENF);
+		break;
+
+	case IRQ_TYPE_LEVEL_LOW:
+		irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_CIENF);
+		break;
+
+	/* IRQ_TYPE_EDGE_* is set in lpc18xx_gpio_pint_edge_unmask */
+	}
+
+	irqd_set_trigger_type(data, type);
+	irq_setup_alt_chip(data, type);
+	irq_gc_unlock(gc);
+
+	return 0;
+}
+
+static int lpc18xx_gpio_pint_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct lpc18xx_gpio_pint_chip *pint;
+	struct irq_chip_generic *gc;
+	struct resource *regs;
+	int i, ret;
+
+	pint = devm_kzalloc(&pdev->dev, sizeof(*pint), GFP_KERNEL);
+	if (!pint)
+		return -ENOMEM;
+
+	regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	pint->base = devm_ioremap_resource(&pdev->dev, regs);
+	if (IS_ERR(pint->base))
+		return PTR_ERR(pint->base);
+
+	pint->nrirqs = of_irq_count(np);
+	pint->irqmap = devm_kcalloc(&pdev->dev, pint->nrirqs, sizeof(int),
+				    GFP_KERNEL);
+	if (!pint->irqmap)
+		return -ENOMEM;
+
+	pint->clk = devm_clk_get(&pdev->dev, NULL);
+	if (IS_ERR(pint->clk)) {
+		dev_err(&pdev->dev, "input clock not found\n");
+		return PTR_ERR(pint->clk);
+	}
+
+	ret = clk_prepare_enable(pint->clk);
+	if (ret) {
+		dev_err(&pdev->dev, "unable to enable clock\n");
+		return ret;
+	}
+
+	pint->domain = irq_domain_add_linear(np, pint->nrirqs,
+					     &irq_generic_chip_ops, pint);
+	if (!pint->domain) {
+		dev_err(&pdev->dev, "unable setup irq domain\n");
+		ret = -EINVAL;
+		goto err_domain_add;
+	}
+
+	ret = irq_alloc_domain_generic_chips(pint->domain, pint->nrirqs, 2,
+					     "gpio_pint", handle_edge_irq,
+					     0, 0, 0);
+	if (ret) {
+		dev_err(&pdev->dev, "unable alloc irq domain chips\n");
+		goto err_alloc_domain_gc;
+	}
+
+	gc = irq_get_domain_generic_chip(pint->domain, 0);
+	gc->reg_base = pint->base;
+
+	gc->chip_types[0].type		    = IRQ_TYPE_EDGE_BOTH;
+	gc->chip_types[0].handler	    = handle_edge_irq;
+	gc->chip_types[0].chip.irq_ack	    = lpc18xx_gpio_pint_edge_ack;
+	gc->chip_types[0].chip.irq_mask	    = lpc18xx_gpio_pint_edge_mask;
+	gc->chip_types[0].chip.irq_unmask   = lpc18xx_gpio_pint_edge_unmask;
+	gc->chip_types[0].chip.irq_set_type = lpc18xx_gpio_pint_type;
+
+	gc->chip_types[1].type		    = IRQ_TYPE_LEVEL_MASK;
+	gc->chip_types[1].handler	    = handle_level_irq;
+	gc->chip_types[1].chip.irq_mask	    = lpc18xx_gpio_pint_level_mask;
+	gc->chip_types[1].chip.irq_unmask   = lpc18xx_gpio_pint_level_unmask;
+	gc->chip_types[1].chip.irq_set_type = lpc18xx_gpio_pint_type;
+
+	/* Disable and clear all interrupts */
+	writel(~0, pint->base + LPC18XX_GPIO_PINT_CIENR);
+	writel(~0, pint->base + LPC18XX_GPIO_PINT_CIENF);
+	writel(0,  pint->base + LPC18XX_GPIO_PINT_ISEL);
+	writel(~0, pint->base + LPC18XX_GPIO_PINT_IST);
+
+	for (i = 0; i < pint->nrirqs; i++) {
+		pint->irqmap[i] = platform_get_irq(pdev, i);
+		irq_set_chained_handler_and_data(pint->irqmap[i],
+						 lpc18xx_gpio_pint_handler,
+						 pint);
+	}
+
+	return 0;
+
+err_alloc_domain_gc:
+	irq_domain_remove(pint->domain);
+err_domain_add:
+	clk_disable_unprepare(pint->clk);
+	return ret;
+}
+
+static const struct of_device_id lpc18xx_gpio_pint_match[] = {
+	{ .compatible = "nxp,lpc1850-gpio-pint" },
+	{ }
+};
+
+static struct platform_driver lpc18xx_gpio_pint_driver = {
+	.probe	= lpc18xx_gpio_pint_probe,
+	.driver	= {
+		.name = "lpc18xx-gpio-pint",
+		.of_match_table = lpc18xx_gpio_pint_match,
+	},
+};
+builtin_platform_driver(lpc18xx_gpio_pint_driver);
-- 
1.8.0



From manabian at gmail.com  Thu Feb 25 14:04:47 2016
From: manabian at gmail.com (Joachim Eastwood)
Date: Thu, 25 Feb 2016 23:04:47 +0100
Subject: [PATCH 2/2] devicetree: document NXP LPC1850 PINT irq controller
 binding
In-Reply-To: <1456437887-24432-1-git-send-email-manabian@gmail.com>
References: <1456437887-24432-1-git-send-email-manabian@gmail.com>
Message-ID: <1456437887-24432-3-git-send-email-manabian@gmail.com>

Add binding documentation for NXP LPC1850 GPIO Pin Interrupt (PINT)
controller.

Signed-off-by: Joachim Eastwood <manabian at gmail.com>
---
 .../interrupt-controller/nxp,lpc1850-gpio-pint.txt | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/nxp,lpc1850-gpio-pint.txt

diff --git a/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc1850-gpio-pint.txt b/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc1850-gpio-pint.txt
new file mode 100644
index 000000000000..dc43f187ebda
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc1850-gpio-pint.txt
@@ -0,0 +1,22 @@
+NXP LPC18xx/43xx GPIO Pin Interrupt (PINT) controller
+
+Required properties:
+
+- compatible : should be "nxp,lpc1850-gpio-pint".
+- reg : Specifies base physical address and size of the registers.
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 2.
+- interrupts : Specifies the CPU interrupts the controller is connected to.
+- clocks: Must contain a reference to the functional clock.
+
+Example:
+
+pint: interrupt-controller at 40087000 {
+	compatible = "nxp,lpc1850-gpio-pint";
+	reg = <0x40087000 0x1000>;
+	interrupt-controller;
+	#interrupt-cells = <2>;
+	interrupts = <32 33 34 35 36 37 38 39>;
+	clocks = <&ccu1 CLK_CPU_GPIO>;
+};
-- 
1.8.0



From ard.biesheuvel at linaro.org  Thu Feb 25 14:09:18 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Thu, 25 Feb 2016 23:09:18 +0100
Subject: [PATCH v2] arm64: lse: deal with clobbered x16 register after
 branch via PLT
In-Reply-To: <1456429733-20825-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456429733-20825-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <CAKv+Gu_e7+PUu8YwWvEMVuHqpEo8NMYoAmyuOT3eU3cXhNOJGA@mail.gmail.com>

On 25 February 2016 at 20:48, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
> The LSE atomics implementation uses runtime patching to patch in calls
> to out of line non-LSE atomics implementations on cores that lack hardware
> support for LSE. To avoid paying the overhead cost of a function call even
> if no call ends up being made, the bl instruction is kept invisible to the
> compiler, and the out of line implementations preserve all registers, not
> just the ones that they are required to preserve as per the AAPCS64.
>
> However, commit fd045f6cd98e ("arm64: add support for module PLTs") added
> support for routing branch instructions via veneers if the branch target
> offset exceeds the range of the ordinary relative branch instructions.
> Since this deals with jump and call instructions that are exposed to ELF
> relocations, the PLT code uses x16 to hold the address of the branch target
> when it performs an indirect branch-to-register, something which is
> explicitly allowed by the AAPCS64 (and ordinary compiler generated code
> does not expect register x16 or x17 to retain their values across a bl
> instruction).
>
> Since the lse runtime patched bl instructions don't adhere to the AAPCS64,
> they don't deal with this clobbering of registers x16 and x17. So add them
> to the clobber list of the asm() statements that perform the call
> instructions, and drop x16 and x17 from the list of registers that are
> caller saved in the out of line non-LSE implementations.
>
> In addition, since we have given these functions two scratch registers,
> they no longer need to stack/unstack temp registers, and the only remaining
> stack accesses are for the frame pointer. So pass -fomit-frame-pointer as
> well, this eliminates all stack accesses from these functions.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> ---
> v2: added x17 and -fomit-frame-pointer
>

Actually, it appears the -fomit-frame-pointer is not even necessary:
the compiler will only generate the stack frame if it needs to stack
other registers as well, and with x16 and x17 available, it does not
need to preserve x30, resulting in the 'after' code below


> Before:
> 0000000000000000 <__ll_sc_atomic_add>:
>    0:   a9be7bfd        stp     x29, x30, [sp,#-32]!
>    4:   910003fd        mov     x29, sp
>    8:   f9000be8        str     x8, [sp,#16]
>    c:   f9800031        prfm    pstl1strm, [x1]
>   10:   885f7c28        ldxr    w8, [x1]
>   14:   0b000108        add     w8, w8, w0
>   18:   881e7c28        stxr    w30, w8, [x1]
>   1c:   35ffffbe        cbnz    w30, 10 <__ll_sc_atomic_add+0x10>
>   20:   f9400be8        ldr     x8, [sp,#16]
>   24:   a8c27bfd        ldp     x29, x30, [sp],#32
>   28:   d65f03c0        ret
>   2c:   d503201f        nop
>
> After:
> 0000000000000000 <__ll_sc_atomic_add>:
>    0:   f9800031        prfm    pstl1strm, [x1]
>    4:   885f7c31        ldxr    w17, [x1]
>    8:   0b000231        add     w17, w17, w0
>    c:   88107c31        stxr    w16, w17, [x1]
>   10:   35ffffb0        cbnz    w16, 4 <__ll_sc_atomic_add+0x4>
>   14:   d65f03c0        ret
>
>  arch/arm64/include/asm/atomic_lse.h | 38 ++++++++++----------
>  arch/arm64/lib/Makefile             |  2 +-
>  2 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
> index 197e06afbf71..7af60139f718 100644
> --- a/arch/arm64/include/asm/atomic_lse.h
> +++ b/arch/arm64/include/asm/atomic_lse.h
> @@ -36,7 +36,7 @@ static inline void atomic_andnot(int i, atomic_t *v)
>         "       stclr   %w[i], %[v]\n")
>         : [i] "+r" (w0), [v] "+Q" (v->counter)
>         : "r" (x1)
> -       : "x30");
> +       : "x16", "x17", "x30");
>  }
>
>  static inline void atomic_or(int i, atomic_t *v)
> @@ -48,7 +48,7 @@ static inline void atomic_or(int i, atomic_t *v)
>         "       stset   %w[i], %[v]\n")
>         : [i] "+r" (w0), [v] "+Q" (v->counter)
>         : "r" (x1)
> -       : "x30");
> +       : "x16", "x17", "x30");
>  }
>
>  static inline void atomic_xor(int i, atomic_t *v)
> @@ -60,7 +60,7 @@ static inline void atomic_xor(int i, atomic_t *v)
>         "       steor   %w[i], %[v]\n")
>         : [i] "+r" (w0), [v] "+Q" (v->counter)
>         : "r" (x1)
> -       : "x30");
> +       : "x16", "x17", "x30");
>  }
>
>  static inline void atomic_add(int i, atomic_t *v)
> @@ -72,7 +72,7 @@ static inline void atomic_add(int i, atomic_t *v)
>         "       stadd   %w[i], %[v]\n")
>         : [i] "+r" (w0), [v] "+Q" (v->counter)
>         : "r" (x1)
> -       : "x30");
> +       : "x16", "x17", "x30");
>  }
>
>  #define ATOMIC_OP_ADD_RETURN(name, mb, cl...)                          \
> @@ -90,7 +90,7 @@ static inline int atomic_add_return##name(int i, atomic_t *v)         \
>         "       add     %w[i], %w[i], w30")                             \
>         : [i] "+r" (w0), [v] "+Q" (v->counter)                          \
>         : "r" (x1)                                                      \
> -       : "x30" , ##cl);                                                \
> +       : "x16", "x17", "x30", ##cl);                                   \
>                                                                         \
>         return w0;                                                      \
>  }
> @@ -116,7 +116,7 @@ static inline void atomic_and(int i, atomic_t *v)
>         "       stclr   %w[i], %[v]")
>         : [i] "+r" (w0), [v] "+Q" (v->counter)
>         : "r" (x1)
> -       : "x30");
> +       : "x16", "x17", "x30");
>  }
>
>  static inline void atomic_sub(int i, atomic_t *v)
> @@ -133,7 +133,7 @@ static inline void atomic_sub(int i, atomic_t *v)
>         "       stadd   %w[i], %[v]")
>         : [i] "+r" (w0), [v] "+Q" (v->counter)
>         : "r" (x1)
> -       : "x30");
> +       : "x16", "x17", "x30");
>  }
>
>  #define ATOMIC_OP_SUB_RETURN(name, mb, cl...)                          \
> @@ -153,7 +153,7 @@ static inline int atomic_sub_return##name(int i, atomic_t *v)               \
>         "       add     %w[i], %w[i], w30")                             \
>         : [i] "+r" (w0), [v] "+Q" (v->counter)                          \
>         : "r" (x1)                                                      \
> -       : "x30" , ##cl);                                                \
> +       : "x16", "x17", "x30" , ##cl);                                  \
>                                                                         \
>         return w0;                                                      \
>  }
> @@ -177,7 +177,7 @@ static inline void atomic64_andnot(long i, atomic64_t *v)
>         "       stclr   %[i], %[v]\n")
>         : [i] "+r" (x0), [v] "+Q" (v->counter)
>         : "r" (x1)
> -       : "x30");
> +       : "x16", "x17", "x30");
>  }
>
>  static inline void atomic64_or(long i, atomic64_t *v)
> @@ -189,7 +189,7 @@ static inline void atomic64_or(long i, atomic64_t *v)
>         "       stset   %[i], %[v]\n")
>         : [i] "+r" (x0), [v] "+Q" (v->counter)
>         : "r" (x1)
> -       : "x30");
> +       : "x16", "x17", "x30");
>  }
>
>  static inline void atomic64_xor(long i, atomic64_t *v)
> @@ -201,7 +201,7 @@ static inline void atomic64_xor(long i, atomic64_t *v)
>         "       steor   %[i], %[v]\n")
>         : [i] "+r" (x0), [v] "+Q" (v->counter)
>         : "r" (x1)
> -       : "x30");
> +       : "x16", "x17", "x30");
>  }
>
>  static inline void atomic64_add(long i, atomic64_t *v)
> @@ -213,7 +213,7 @@ static inline void atomic64_add(long i, atomic64_t *v)
>         "       stadd   %[i], %[v]\n")
>         : [i] "+r" (x0), [v] "+Q" (v->counter)
>         : "r" (x1)
> -       : "x30");
> +       : "x16", "x17", "x30");
>  }
>
>  #define ATOMIC64_OP_ADD_RETURN(name, mb, cl...)                                \
> @@ -231,7 +231,7 @@ static inline long atomic64_add_return##name(long i, atomic64_t *v) \
>         "       add     %[i], %[i], x30")                               \
>         : [i] "+r" (x0), [v] "+Q" (v->counter)                          \
>         : "r" (x1)                                                      \
> -       : "x30" , ##cl);                                                \
> +       : "x16", "x17", "x30", ##cl);                                   \
>                                                                         \
>         return x0;                                                      \
>  }
> @@ -257,7 +257,7 @@ static inline void atomic64_and(long i, atomic64_t *v)
>         "       stclr   %[i], %[v]")
>         : [i] "+r" (x0), [v] "+Q" (v->counter)
>         : "r" (x1)
> -       : "x30");
> +       : "x16", "x17", "x30");
>  }
>
>  static inline void atomic64_sub(long i, atomic64_t *v)
> @@ -274,7 +274,7 @@ static inline void atomic64_sub(long i, atomic64_t *v)
>         "       stadd   %[i], %[v]")
>         : [i] "+r" (x0), [v] "+Q" (v->counter)
>         : "r" (x1)
> -       : "x30");
> +       : "x16", "x17", "x30");
>  }
>
>  #define ATOMIC64_OP_SUB_RETURN(name, mb, cl...)                                \
> @@ -294,7 +294,7 @@ static inline long atomic64_sub_return##name(long i, atomic64_t *v) \
>         "       add     %[i], %[i], x30")                               \
>         : [i] "+r" (x0), [v] "+Q" (v->counter)                          \
>         : "r" (x1)                                                      \
> -       : "x30" , ##cl);                                                \
> +       : "x16", "x17", "x30", ##cl);                                   \
>                                                                         \
>         return x0;                                                      \
>  }
> @@ -330,7 +330,7 @@ static inline long atomic64_dec_if_positive(atomic64_t *v)
>         "2:")
>         : [ret] "+&r" (x0), [v] "+Q" (v->counter)
>         :
> -       : "x30", "cc", "memory");
> +       : "x16", "x17", "x30", "cc", "memory");
>
>         return x0;
>  }
> @@ -359,7 +359,7 @@ static inline unsigned long __cmpxchg_case_##name(volatile void *ptr,       \
>         "       mov     %" #w "[ret], " #w "30")                        \
>         : [ret] "+r" (x0), [v] "+Q" (*(unsigned long *)ptr)             \
>         : [old] "r" (x1), [new] "r" (x2)                                \
> -       : "x30" , ##cl);                                                \
> +       : "x16", "x17", "x30", ##cl);                                   \
>                                                                         \
>         return x0;                                                      \
>  }
> @@ -416,7 +416,7 @@ static inline long __cmpxchg_double##name(unsigned long old1,               \
>           [v] "+Q" (*(unsigned long *)ptr)                              \
>         : [new1] "r" (x2), [new2] "r" (x3), [ptr] "r" (x4),             \
>           [oldval1] "r" (oldval1), [oldval2] "r" (oldval2)              \
> -       : "x30" , ##cl);                                                \
> +       : "x16", "x17", "x30", ##cl);                                   \
>                                                                         \
>         return x0;                                                      \
>  }
> diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
> index 1a811ecf71da..d323a82c4ac3 100644
> --- a/arch/arm64/lib/Makefile
> +++ b/arch/arm64/lib/Makefile
> @@ -15,4 +15,4 @@ CFLAGS_atomic_ll_sc.o := -fcall-used-x0 -ffixed-x1 -ffixed-x2         \
>                    -ffixed-x7 -fcall-saved-x8 -fcall-saved-x9           \
>                    -fcall-saved-x10 -fcall-saved-x11 -fcall-saved-x12   \
>                    -fcall-saved-x13 -fcall-saved-x14 -fcall-saved-x15   \
> -                  -fcall-saved-x16 -fcall-saved-x17 -fcall-saved-x18
> +                  -fcall-saved-x18 -fomit-frame-pointer
> --
> 2.5.0
>


From heiko.carstens at de.ibm.com  Thu Feb 25 14:10:18 2016
From: heiko.carstens at de.ibm.com (Heiko Carstens)
Date: Thu, 25 Feb 2016 23:10:18 +0100
Subject: [PATCH 2/5] all: introduce COMPAT_WRAPPER option and enable it
 for s390
In-Reply-To: <20160225201926.GA16123@yury-N73SV>
References: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
 <1456338854-14901-3-git-send-email-ynorov@caviumnetworks.com>
 <20160225084943.GB3980@osiris> <20160225201926.GA16123@yury-N73SV>
Message-ID: <20160225221018.GA5950@osiris>

On Thu, Feb 25, 2016 at 11:19:26PM +0300, Yury Norov wrote:
> On Thu, Feb 25, 2016 at 09:49:43AM +0100, Heiko Carstens wrote:
> > On Wed, Feb 24, 2016 at 09:34:11PM +0300, Yury Norov wrote:
> > > Signed-off-by: Yury Norov <ynorov at caviumnetworks.com>
> > > ---
> > >  arch/Kconfig      | 4 ++++
> > >  arch/s390/Kconfig | 1 +
> > >  2 files changed, 5 insertions(+)
> > > 
> > > diff --git a/arch/Kconfig b/arch/Kconfig
> > > index f6b649d..6393093 100644
> > > --- a/arch/Kconfig
> > > +++ b/arch/Kconfig
> > > @@ -583,6 +583,10 @@ config HAVE_COPY_THREAD_TLS
> > >  	  normal C parameter passing, rather than extracting the syscall
> > >  	  argument from pt_regs.
> > > 
> > > +config COMPAT_WRAPPER
> > > +	bool
> > > +	depends on COMPAT
> > > +
> > >  #
> > >  # ABI hall of shame
> > >  #
> > > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> > > index 3be9c83..082b861 100644
> > > --- a/arch/s390/Kconfig
> > > +++ b/arch/s390/Kconfig
> > > @@ -333,6 +333,7 @@ config COMPAT
> > >  	select COMPAT_BINFMT_ELF if BINFMT_ELF
> > >  	select ARCH_WANT_OLD_COMPAT_IPC
> > >  	select COMPAT_OLD_SIGACTION
> > > +	select COMPAT_WRAPPER
> > >  	depends on MULTIUSER
> > >  	help
> > >  	  Select this option if you want to enable your system kernel to
> > 
> > Maybe merge this into patch 4/5?
> 
> Then bisectability will suffer, as next patch needs COMPAT_WRAPPER
> enabled.

Oh, right. I didn't realize that you put the macros between an
#ifdef CONFIG_COMPAT_WRAPPER . It's not strictly needed, but it
doesn't hurt as well.



From sfr at canb.auug.org.au  Thu Feb 25 14:16:19 2016
From: sfr at canb.auug.org.au (Stephen Rothwell)
Date: Fri, 26 Feb 2016 09:16:19 +1100
Subject: linux-next: manual merge of the sunxi tree with Linus' and the
 arm-soc trees
Message-ID: <20160226091619.4568bc31@canb.auug.org.au>

Hi Maxime,

Today's linux-next merge of the sunxi tree got a conflict in:

  arch/arm64/configs/defconfig

between commit:

  531d3067314f ("arm64: defconfig: updates for 4.5")

from Linus' tree, commit:

  efdda175c07f ("arm64: defconfig: add spmi and usb related configs")

from the arm-soc tree and commit:

  22b0898e831b ("arm64: add defconfig options for Allwinner SoCs")

from the sunxi tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/configs/defconfig
index 894898f60925,7acadce74d4d..000000000000
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@@ -30,9 -31,10 +30,10 @@@ CONFIG_MODULES=
  CONFIG_MODULE_UNLOAD=y
  # CONFIG_BLK_DEV_BSG is not set
  # CONFIG_IOSCHED_DEADLINE is not set
+ CONFIG_ARCH_SUNXI=y
  CONFIG_ARCH_BCM_IPROC=y
  CONFIG_ARCH_BERLIN=y
 -CONFIG_ARCH_EXYNOS7=y
 +CONFIG_ARCH_EXYNOS=y
  CONFIG_ARCH_LAYERSCAPE=y
  CONFIG_ARCH_HISI=y
  CONFIG_ARCH_MEDIATEK=y
@@@ -134,22 -127,24 +135,25 @@@ CONFIG_SERIAL_TEGRA=
  CONFIG_SERIAL_SH_SCI=y
  CONFIG_SERIAL_SH_SCI_NR_UARTS=11
  CONFIG_SERIAL_SH_SCI_CONSOLE=y
 -CONFIG_SERIAL_TEGRA=y
  CONFIG_SERIAL_MSM=y
  CONFIG_SERIAL_MSM_CONSOLE=y
 -CONFIG_SERIAL_OF_PLATFORM=y
  CONFIG_SERIAL_XILINX_PS_UART=y
  CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
 +CONFIG_SERIAL_MVEBU_UART=y
  CONFIG_VIRTIO_CONSOLE=y
  # CONFIG_HW_RANDOM is not set
 -CONFIG_I2C=y
+ CONFIG_I2C_CHARDEV=y
+ CONFIG_I2C_MV64XXX=y
  CONFIG_I2C_QUP=y
 +CONFIG_I2C_UNIPHIER_F=y
  CONFIG_I2C_RCAR=y
  CONFIG_SPI=y
  CONFIG_SPI_PL022=y
  CONFIG_SPI_QUP=y
 +CONFIG_SPMI=y
  CONFIG_PINCTRL_MSM8916=y
 +CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
+ CONFIG_GPIO_SYSFS=y
  CONFIG_GPIO_PL061=y
  CONFIG_GPIO_RCAR=y
  CONFIG_GPIO_XGENE=y
@@@ -196,8 -179,12 +200,10 @@@ CONFIG_MMC_SDHCI=
  CONFIG_MMC_SDHCI_PLTFM=y
  CONFIG_MMC_SDHCI_TEGRA=y
  CONFIG_MMC_SPI=y
+ CONFIG_MMC_SUNXI=y
  CONFIG_MMC_DW=y
 -CONFIG_MMC_DW_IDMAC=y
 -CONFIG_MMC_DW_PLTFM=y
  CONFIG_MMC_DW_EXYNOS=y
+ CONFIG_MMC_BLOCK_MINORS=16
  CONFIG_NEW_LEDS=y
  CONFIG_LEDS_CLASS=y
  CONFIG_LEDS_SYSCON=y
@@@ -206,14 -193,12 +212,15 @@@ CONFIG_LEDS_TRIGGER_HEARTBEAT=
  CONFIG_LEDS_TRIGGER_CPU=y
  CONFIG_RTC_CLASS=y
  CONFIG_RTC_DRV_EFI=y
 +CONFIG_RTC_DRV_PL031=y
+ CONFIG_RTC_DRV_SUN6I=y
  CONFIG_RTC_DRV_XGENE=y
  CONFIG_DMADEVICES=y
 -CONFIG_RCAR_DMAC=y
  CONFIG_QCOM_BAM_DMA=y
  CONFIG_TEGRA20_APB_DMA=y
 +CONFIG_RCAR_DMAC=y
 +CONFIG_VFIO=y
 +CONFIG_VFIO_PCI=y
  CONFIG_VIRTIO_PCI=y
  CONFIG_VIRTIO_BALLOON=y
  CONFIG_VIRTIO_MMIO=y


From heiko.carstens at de.ibm.com  Thu Feb 25 14:20:47 2016
From: heiko.carstens at de.ibm.com (Heiko Carstens)
Date: Thu, 25 Feb 2016 23:20:47 +0100
Subject: [PATCH 3/5] all: s390: move wrapper infrastructure to generic
 headers
In-Reply-To: <20160225202350.GB16123@yury-N73SV>
References: <1456338854-14901-1-git-send-email-ynorov@caviumnetworks.com>
 <1456338854-14901-4-git-send-email-ynorov@caviumnetworks.com>
 <20160225085140.GC3980@osiris> <20160225202350.GB16123@yury-N73SV>
Message-ID: <20160225222047.GB5950@osiris>

On Thu, Feb 25, 2016 at 11:23:50PM +0300, Yury Norov wrote:
> On Thu, Feb 25, 2016 at 09:51:40AM +0100, Heiko Carstens wrote:
> > On Wed, Feb 24, 2016 at 09:34:12PM +0300, Yury Norov wrote:
> > > diff --git a/include/linux/syscalls_structs.h b/include/linux/syscalls_structs.h
> > > new file mode 100644
> > > index 0000000..a920cbc
> > > --- /dev/null
> > > +++ b/include/linux/syscalls_structs.h
> > > @@ -0,0 +1,60 @@
> > > +#ifndef _LINUX_SYSCALL_STRUCTS_H
> > > +#define _LINUX_SYSCALL_STRUCTS_H
> > > +
> > > +struct epoll_event;
> > > +struct iattr;
> > > +struct inode;
> > > +struct iocb;
> > > +struct io_event;
> > > +struct iovec;
> > > +struct itimerspec;
> > > +struct itimerval;
> > 
> > This is not needed for s390, right? So might be worth a separate patch
> > which moves the forward declarations?
> 
> This patch also introduces __SC_WRAP, not needed as well. The idea of
> this patch is to introduce all the tricky machinery at once. If you
> think we need split it, I'm OK, but maybe it's enough to add more
> detailed description... What do you think?

Ok, I see. Then the only change I'd like to request is to update the
comment in front of the COMPAT_SYSCALL_WRAPx macro which talks about 33/31
bit pointer sizes. This doesn't make too much sense for common code :)



From m-karicheri2 at ti.com  Thu Feb 25 14:23:04 2016
From: m-karicheri2 at ti.com (Murali Karicheri)
Date: Thu, 25 Feb 2016 17:23:04 -0500
Subject: [PATCH] PCI: keystone: fix msi code that retrieves the pp struct ptr
Message-ID: <1456438984-22111-1-git-send-email-m-karicheri2@ti.com>

Recent update to pcie-designware core driver,
commit "cbce79005 PCI: designware: Make driver arch-agnostic" broke the
keystone PCI driver. This is because, the way pp struct ptr is retrieved
from  msi desc has changed and require similar update in pci-keystone-dw.c
as well. This patch fix this issue. Here is the early boot crash log seen
on K2E EVM.

[    1.012999] pci 0000:00:00.0: PCI bridge to [bus 01]
[    1.018073] pci 0000:00:00.0:   bridge window [io  0x1000-0x1fff]
[    1.024308] pci 0000:00:00.0:   bridge window [mem 0x60000000-0x600fffff]
[    1.031216] pci 0000:00:00.0:   bridge window [mem 0x60100000-0x601fffff
pref]
[    1.038736] Unable to handle kernel NULL pointer dereference at virtual
address 00000030
[    1.046950] pgd = c0003000
[    1.049750] [00000030] *pgd=80000800004003, *pmd=00000000
[    1.055265] Internal error: Oops: 206 [#1] PREEMPT SMP ARM
[    1.060860] Modules linked in:
[    1.064013] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.2-00139-gb74f926 #2
[    1.071266] Hardware name: Keystone
[    1.074853] task: eb888000 ti: eb890000 task.ti: eb890000
[    1.080364] PC is at ks_dw_pcie_msi_irq_unmask+0x24/0x58
[    1.085785] LR is at ks_dw_pcie_msi_irq_unmask+0x18/0x58
[    1.091206] pc : [<c02f65c8>]    lr : [<c02f65bc>]    psr: 60000093
[    1.091206] sp : eb891bc8  ip : 00000000  fp : ebb15010
[    1.102915] r10: 00000051  r9 : 60000013  r8 : ebafaa20
[    1.108247] r7 : ebaa9f80  r6 : eb9fd0c0  r5 : ebafa9d0  r4 : ebafa9c0
[    1.114889] r3 : 00000051  r2 : 00000000  r1 : 00000001  r0 : ebb14c18
[    1.121533] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment
kernel
[    1.129049] Control: 30c5387d  Table: 00003000  DAC: fffffffd
[    1.134905] Process swapper/0 (pid: 1, stack limit = 0xeb890210)
[    1.141023] Stack: (0xeb891bc8 to 0xeb892000)

Signed-off-by: Murali Karicheri <m-karicheri2 at ti.com>
---
 - Need this fix in 4.4.4 as well
 drivers/pci/host/pci-keystone-dw.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/host/pci-keystone-dw.c b/drivers/pci/host/pci-keystone-dw.c
index ed34c95..6153853 100644
--- a/drivers/pci/host/pci-keystone-dw.c
+++ b/drivers/pci/host/pci-keystone-dw.c
@@ -58,11 +58,6 @@
 
 #define to_keystone_pcie(x)	container_of(x, struct keystone_pcie, pp)
 
-static inline struct pcie_port *sys_to_pcie(struct pci_sys_data *sys)
-{
-	return sys->private_data;
-}
-
 static inline void update_reg_offset_bit_pos(u32 offset, u32 *reg_offset,
 					     u32 *bit_pos)
 {
@@ -108,7 +103,7 @@ static void ks_dw_pcie_msi_irq_ack(struct irq_data *d)
 	struct pcie_port *pp;
 
 	msi = irq_data_get_msi_desc(d);
-	pp = sys_to_pcie(msi_desc_to_pci_sysdata(msi));
+	pp = (struct pcie_port *) msi_desc_to_pci_sysdata(msi);
 	ks_pcie = to_keystone_pcie(pp);
 	offset = d->irq - irq_linear_revmap(pp->irq_domain, 0);
 	update_reg_offset_bit_pos(offset, &reg_offset, &bit_pos);
@@ -146,7 +141,7 @@ static void ks_dw_pcie_msi_irq_mask(struct irq_data *d)
 	u32 offset;
 
 	msi = irq_data_get_msi_desc(d);
-	pp = sys_to_pcie(msi_desc_to_pci_sysdata(msi));
+	pp = (struct pcie_port *) msi_desc_to_pci_sysdata(msi);
 	ks_pcie = to_keystone_pcie(pp);
 	offset = d->irq - irq_linear_revmap(pp->irq_domain, 0);
 
@@ -167,7 +162,7 @@ static void ks_dw_pcie_msi_irq_unmask(struct irq_data *d)
 	u32 offset;
 
 	msi = irq_data_get_msi_desc(d);
-	pp = sys_to_pcie(msi_desc_to_pci_sysdata(msi));
+	pp = (struct pcie_port *) msi_desc_to_pci_sysdata(msi);
 	ks_pcie = to_keystone_pcie(pp);
 	offset = d->irq - irq_linear_revmap(pp->irq_domain, 0);
 
-- 
1.9.1



From eric at anholt.net  Thu Feb 25 14:24:50 2016
From: eric at anholt.net (Eric Anholt)
Date: Thu, 25 Feb 2016 14:24:50 -0800
Subject: [PATCH 1/5] ARM: bcm2835: Define standard pinctrl groups in the
 gpio node.
In-Reply-To: <1456425661-26123-2-git-send-email-eric@anholt.net>
References: <1456425661-26123-1-git-send-email-eric@anholt.net>
 <1456425661-26123-2-git-send-email-eric@anholt.net>
Message-ID: <8737sga0nh.fsf@eliezer.anholt.net>

Eric Anholt <eric at anholt.net> writes:

> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
> function selects do for the pins, and there are a bunch of obvious
> groupings to be made.  With these created, we'll be able to replace
> bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
> references to specific groups we want enabled.

Sigh.  The host I've been using for relaying SMTP apparently decided
this week that it doesn't like half my mail.

I'll be off fixing this, so for now if anyone wants to look at the
series it's just in my repo:

https://github.com/anholt/linux/tree/bcm2835-dt-gpio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160225/b9819c98/attachment.sig>

From sboyd at codeaurora.org  Thu Feb 25 14:27:06 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Feb 2016 14:27:06 -0800
Subject: [PATCHv2 14/16] clk: imx: add kpp clock for i.MX6UL
In-Reply-To: <1453284549-16363-15-git-send-email-LW@KARO-electronics.de>
References: <1452619291-13625-1-git-send-email-LW@KARO-electronics.de>
 <1453284549-16363-1-git-send-email-LW@KARO-electronics.de>
 <1453284549-16363-15-git-send-email-LW@KARO-electronics.de>
Message-ID: <20160225222706.GL4847@codeaurora.org>

On 01/20, Lothar Wa?mann wrote:
> Add the necessary clock to use the KPP interface on i.MX6UL.
> 
> Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
> ---

Acked-by: Stephen Boyd <sboyd at codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From sboyd at codeaurora.org  Thu Feb 25 14:27:10 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Feb 2016 14:27:10 -0800
Subject: [PATCHv2 13/16] clk: imx: whitespace cleanup; no functional change
In-Reply-To: <1453284549-16363-14-git-send-email-LW@KARO-electronics.de>
References: <1452619291-13625-1-git-send-email-LW@KARO-electronics.de>
 <1453284549-16363-1-git-send-email-LW@KARO-electronics.de>
 <1453284549-16363-14-git-send-email-LW@KARO-electronics.de>
Message-ID: <20160225222710.GM4847@codeaurora.org>

On 01/20, Lothar Wa?mann wrote:
> remove whitespace before TAB.
> 
> Signed-off-by: Lothar Wa?mann <LW at KARO-electronics.de>
> ---

Acked-by: Stephen Boyd <sboyd at codeaurora.org>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From colin.king at canonical.com  Thu Feb 25 14:28:59 2016
From: colin.king at canonical.com (Colin King)
Date: Thu, 25 Feb 2016 22:28:59 +0000
Subject: [PATCH] mt7601u: do not free dma_buf when ivp allocation fails
Message-ID: <1456439339-18458-1-git-send-email-colin.king@canonical.com>

From: Colin Ian King <colin.king at canonical.com>

If the allocation of ivp fails the error handling attempts to
free an uninitialized dma_buf; this data structure just contains
garbage on the stack, so the freeing will cause issues when the
urb, buf and dma fields are cleaned. Fix this by handling the
ivp check and

Signed-off-by: Colin Ian King <colin.king at canonical.com>
---
 drivers/net/wireless/mediatek/mt7601u/mcu.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt7601u/mcu.c b/drivers/net/wireless/mediatek/mt7601u/mcu.c
index fbb1986..06ac657 100644
--- a/drivers/net/wireless/mediatek/mt7601u/mcu.c
+++ b/drivers/net/wireless/mediatek/mt7601u/mcu.c
@@ -359,13 +359,13 @@ mt7601u_upload_firmware(struct mt7601u_dev *dev, const struct mt76_fw *fw)
 	struct mt7601u_dma_buf dma_buf;
 	void *ivb;
 	u32 ilm_len, dlm_len;
-	int i, ret;
+	int i, ret = -ENOMEM;
 
 	ivb = kmemdup(fw->ivb, sizeof(fw->ivb), GFP_KERNEL);
-	if (!ivb || mt7601u_usb_alloc_buf(dev, MCU_FW_URB_SIZE, &dma_buf)) {
-		ret = -ENOMEM;
+	if (!ivb)
+		goto error_ivb;
+	if (mt7601u_usb_alloc_buf(dev, MCU_FW_URB_SIZE, &dma_buf))
 		goto error;
-	}
 
 	ilm_len = le32_to_cpu(fw->hdr.ilm_len) - sizeof(fw->ivb);
 	dev_dbg(dev->dev, "loading FW - ILM %u + IVB %zu\n",
@@ -396,8 +396,9 @@ mt7601u_upload_firmware(struct mt7601u_dev *dev, const struct mt76_fw *fw)
 
 	dev_dbg(dev->dev, "Firmware running!\n");
 error:
-	kfree(ivb);
 	mt7601u_usb_free_buf(dev, &dma_buf);
+error_ivb:
+	kfree(ivb);
 
 	return ret;
 }
-- 
2.7.0



From dhdang at apm.com  Thu Feb 25 14:33:53 2016
From: dhdang at apm.com (Duc Dang)
Date: Thu, 25 Feb 2016 14:33:53 -0800
Subject: [PATCH v6 3/3] arm64: dts: mailbox device tree node for APM
 X-Gene platform.
In-Reply-To: <eeac516f6daa15b22a1c448160ed40991833035a.1455333720.git.dhdang@apm.com>
References: <CANLsYkxPnFCuJLyKsHnXKdbvAwNurtgQgJ-WF+bD26+8EjkfJw@mail.gmail.com>
 <cover.1455333720.git.dhdang@apm.com>
 <eeac516f6daa15b22a1c448160ed40991833035a.1455333720.git.dhdang@apm.com>
Message-ID: <CADaLNDkswDHbgX1T52ivniHojTpscGvF+vLinhTT3h_P20OMzw@mail.gmail.com>

On Fri, Feb 12, 2016 at 7:39 PM, Duc Dang <dhdang at apm.com> wrote:
>
> Mailbox device tree node for APM X-Gene platform.

Hi Jassi,

Will you take this patch to your mailbox tree or you want me to
include it into my git pull request to Olof/Arnd (arm-soc tree)?

Regards,
Duc Dang.
>
> Signed-off-by: Feng Kan <fkan at apm.com>
> Signed-off-by: Duc Dang <dhdang at apm.com>
> ---
> Changes since v5:
>         - None
>
> Changes since v4:
>         - Rebase over v4.5-rc1
>         - Change node name to mailbox at 10540000
>
> Changes since v3:
>         - Rebase over v4.4
>
>  arch/arm64/boot/dts/apm/apm-storm.dtsi | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> index fe30f76..d91338a 100644
> --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
> +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
> @@ -691,6 +691,20 @@
>                         msi-parent = <&msi>;
>                 };
>
> +               mailbox: mailbox at 10540000 {
> +                       compatible = "apm,xgene-slimpro-mbox";
> +                       reg = <0x0 0x10540000 0x0 0xa000>;
> +                       #mbox-cells = <1>;
> +                       interrupts =    <0x0 0x0 0x4>,
> +                                       <0x0 0x1 0x4>,
> +                                       <0x0 0x2 0x4>,
> +                                       <0x0 0x3 0x4>,
> +                                       <0x0 0x4 0x4>,
> +                                       <0x0 0x5 0x4>,
> +                                       <0x0 0x6 0x4>,
> +                                       <0x0 0x7 0x4>;
> +               };
> +
>                 serial0: serial at 1c020000 {
>                         status = "disabled";
>                         device_type = "serial";
> --
> 1.9.1
>


From fcooper at ti.com  Thu Feb 25 14:36:35 2016
From: fcooper at ti.com (Franklin S Cooper Jr)
Date: Thu, 25 Feb 2016 16:36:35 -0600
Subject: [PATCH v3 4/5] clk: ti: DRA7: Add tbclk data for ehrpwm
In-Reply-To: <1456439796-28546-1-git-send-email-fcooper@ti.com>
References: <1456439796-28546-1-git-send-email-fcooper@ti.com>
Message-ID: <1456439796-28546-5-git-send-email-fcooper@ti.com>

From: Vignesh R <vigneshr at ti.com>

tbclk is needed by ehrpwm to generate pwm waveforms. Hence, register
the required clock information.

Signed-off-by: Vignesh R <vigneshr at ti.com>
Acked-by: Michael Turquette <mturquette at baylibre.com>
---
Version 3 changes:
None

 drivers/clk/ti/clk-7xx.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index a911d7d..7fcf818 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -304,6 +304,9 @@ static struct ti_dt_clk dra7xx_clks[] = {
 	DT_CLK("4882a000.timer", "timer_sys_ck", "timer_sys_clk_div"),
 	DT_CLK("4882c000.timer", "timer_sys_ck", "timer_sys_clk_div"),
 	DT_CLK("4882e000.timer", "timer_sys_ck", "timer_sys_clk_div"),
+	DT_CLK("4843e200.ehrpwm", "tbclk", "ehrpwm0_tbclk"),
+	DT_CLK("48440200.ehrpwm", "tbclk", "ehrpwm1_tbclk"),
+	DT_CLK("48442200.ehrpwm", "tbclk", "ehrpwm2_tbclk"),
 	DT_CLK(NULL, "sys_clkin", "sys_clkin1"),
 	DT_CLK(NULL, "dss_deshdcp_clk", "dss_deshdcp_clk"),
 	{ .node_name = NULL },
-- 
2.7.0



From fcooper at ti.com  Thu Feb 25 14:36:31 2016
From: fcooper at ti.com (Franklin S Cooper Jr)
Date: Thu, 25 Feb 2016 16:36:31 -0600
Subject: [PATCH v3 0/5] Add support for PWMSS on DRA7
Message-ID: <1456439796-28546-1-git-send-email-fcooper@ti.com>

This patch series adds support for PWMSS on DRA7. The IP is same as that
present in AM33XX and AM43XX.

This is an updated version of the patch series originally sent by Vignesh.
The biggest difference is the removal of local clock gating support from
various drivers due to silicon issue.

Links to v2 series:
https://patchwork.ozlabs.org/patch/479933/ (already in mainline)
https://patchwork.ozlabs.org/patch/479932/
https://patchwork.ozlabs.org/patch/479931/
https://patchwork.ozlabs.org/patch/479930/
https://patchwork.ozlabs.org/patch/479929/

Franklin S Cooper Jr (1):
  pwms: pwm-ti*: Remove support for local clock gating

Vignesh R (4):
  ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS
  ARM: dts: DRA7: Add TBCLK for PWMSS
  clk: ti: DRA7: Add tbclk data for ehrpwm
  ARM: dts: DRA7: Add dt nodes for PWMSS

 .../devicetree/bindings/pwm/pwm-tiehrpwm.txt       |   8 +
 .../devicetree/bindings/pwm/pwm-tipwmss.txt        |  17 +-
 arch/arm/boot/dts/dra7.dtsi                        |  64 ++++++
 arch/arm/boot/dts/dra7xx-clocks.dtsi               |  24 +++
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c          | 239 +++++++++++++++++++++
 drivers/clk/ti/clk-7xx.c                           |   3 +
 drivers/pwm/pwm-tiecap.c                           |  28 ---
 drivers/pwm/pwm-tiehrpwm.c                         |  29 ---
 drivers/pwm/pwm-tipwmss.c                          |  49 -----
 drivers/pwm/pwm-tipwmss.h                          |  39 ----
 10 files changed, 354 insertions(+), 146 deletions(-)
 delete mode 100644 drivers/pwm/pwm-tipwmss.h

-- 
2.7.0



From fcooper at ti.com  Thu Feb 25 14:36:33 2016
From: fcooper at ti.com (Franklin S Cooper Jr)
Date: Thu, 25 Feb 2016 16:36:33 -0600
Subject: [PATCH v3 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS
In-Reply-To: <1456439796-28546-1-git-send-email-fcooper@ti.com>
References: <1456439796-28546-1-git-send-email-fcooper@ti.com>
Message-ID: <1456439796-28546-3-git-send-email-fcooper@ti.com>

From: Vignesh R <vigneshr at ti.com>

Add hwmod entries for the PWMSS on DRA7.

Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock
equal to L4PER2_L3_GICLK/2(l3_iclk_div/2).
As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4,
clock source to PWMSS is L4PER2_L3_GICLK. But it is actually
L4PER2_L3_GICLK/2. The TRM does not show the division by 2.

[1] www.ti.com/lit/ug/spruhz6/spruhz6.pdf

Signed-off-by: Vignesh R <vigneshr at ti.com>
---
Version 3 changes:
Switch from SYSC_HAS_RESET_STATUS to SYSC_HAS_SOFTRESET which is the
correct bitfield for that register.

 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 239 ++++++++++++++++++++++++++++++
 1 file changed, 239 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 848356e..4b2d68b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -383,6 +383,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
 	},
 };
 
+/* pwmss  */
+static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
+	.rev_offs	= 0x0,
+	.sysc_offs	= 0x4,
+	.sysc_flags	= SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET,
+	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+	.sysc_fields	= &omap_hwmod_sysc_type2,
+};
+
+struct omap_hwmod_class dra7xx_epwmss_hwmod_class = {
+	.name		= "epwmss",
+	.sysc		= &dra7xx_epwmss_sysc,
+};
+
+static struct omap_hwmod_class dra7xx_ecap_hwmod_class = {
+	.name		= "ecap",
+};
+
+static struct omap_hwmod_class dra7xx_eqep_hwmod_class = {
+	.name		= "eqep",
+};
+
+struct omap_hwmod_class dra7xx_ehrpwm_hwmod_class = {
+	.name		= "ehrpwm",
+};
+
+/* epwmss0 */
+struct omap_hwmod dra7xx_epwmss0_hwmod = {
+	.name		= "epwmss0",
+	.class		= &dra7xx_epwmss_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "l4_root_clk_div",
+	.prcm		= {
+		.omap4	= {
+			.modulemode	= MODULEMODE_SWCTRL,
+			.clkctrl_offs	= DRA7XX_CM_L4PER2_PWMSS1_CLKCTRL_OFFSET,
+			.context_offs	= DRA7XX_RM_L4PER2_PWMSS1_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/* ecap0 */
+struct omap_hwmod dra7xx_ecap0_hwmod = {
+	.name		= "ecap0",
+	.class		= &dra7xx_ecap_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "l4_root_clk_div",
+};
+
+/* eqep0 */
+struct omap_hwmod dra7xx_eqep0_hwmod = {
+	.name		= "eqep0",
+	.class		= &dra7xx_eqep_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "l4_root_clk_div",
+};
+
+/* ehrpwm0 */
+struct omap_hwmod dra7xx_ehrpwm0_hwmod = {
+	.name		= "ehrpwm0",
+	.class		= &dra7xx_ehrpwm_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "l4_root_clk_div",
+};
+
+/* epwmss1 */
+struct omap_hwmod dra7xx_epwmss1_hwmod = {
+	.name		= "epwmss1",
+	.class		= &dra7xx_epwmss_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "l4_root_clk_div",
+	.prcm		= {
+		.omap4	= {
+			.modulemode	= MODULEMODE_SWCTRL,
+			.clkctrl_offs	= DRA7XX_CM_L4PER2_PWMSS2_CLKCTRL_OFFSET,
+			.context_offs	= DRA7XX_RM_L4PER2_PWMSS2_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/* ecap1 */
+struct omap_hwmod dra7xx_ecap1_hwmod = {
+	.name		= "ecap1",
+	.class		= &dra7xx_ecap_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "l4_root_clk_div",
+};
+
+/* eqep1 */
+struct omap_hwmod dra7xx_eqep1_hwmod = {
+	.name		= "eqep1",
+	.class		= &dra7xx_eqep_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "l4_root_clk_div",
+};
+
+/* ehrpwm1 */
+struct omap_hwmod dra7xx_ehrpwm1_hwmod = {
+	.name		= "ehrpwm1",
+	.class		= &dra7xx_ehrpwm_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "l4_root_clk_div",
+};
+
+/* epwmss2 */
+struct omap_hwmod dra7xx_epwmss2_hwmod = {
+	.name		= "epwmss2",
+	.class		= &dra7xx_epwmss_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "l4_root_clk_div",
+	.prcm		= {
+		.omap4	= {
+			.modulemode	= MODULEMODE_SWCTRL,
+			.clkctrl_offs	= DRA7XX_CM_L4PER2_PWMSS3_CLKCTRL_OFFSET,
+			.context_offs	= DRA7XX_RM_L4PER2_PWMSS3_CONTEXT_OFFSET,
+		},
+	},
+};
+
+/* ecap2 */
+struct omap_hwmod dra7xx_ecap2_hwmod = {
+	.name		= "ecap2",
+	.class		= &dra7xx_ecap_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "l4_root_clk_div",
+};
+
+/* eqep2 */
+struct omap_hwmod dra7xx_eqep2_hwmod = {
+	.name		= "eqep2",
+	.class		= &dra7xx_eqep_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "l4_root_clk_div",
+};
+
+/* ehrpwm2 */
+struct omap_hwmod dra7xx_ehrpwm2_hwmod = {
+	.name		= "ehrpwm2",
+	.class		= &dra7xx_ehrpwm_hwmod_class,
+	.clkdm_name	= "l4per2_clkdm",
+	.main_clk	= "l4_root_clk_div",
+};
+
 /*
  * 'dma' class
  *
@@ -2676,6 +2819,90 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__gpio6 = {
 	.user		= OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+struct omap_hwmod_ocp_if dra7xx_l4_per2__epwmss0 = {
+	.master		= &dra7xx_l4_per2_hwmod,
+	.slave		= &dra7xx_epwmss0_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU,
+};
+
+struct omap_hwmod_ocp_if dra7xx_epwmss0__ecap0 = {
+	.master		= &dra7xx_epwmss0_hwmod,
+	.slave		= &dra7xx_ecap0_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU,
+};
+
+struct omap_hwmod_ocp_if dra7xx_epwmss0__eqep0 = {
+	.master		= &dra7xx_epwmss0_hwmod,
+	.slave		= &dra7xx_eqep0_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU,
+};
+
+struct omap_hwmod_ocp_if dra7xx_epwmss0__ehrpwm0 = {
+	.master		= &dra7xx_epwmss0_hwmod,
+	.slave		= &dra7xx_ehrpwm0_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU,
+};
+
+struct omap_hwmod_ocp_if dra7xx_l4_per2__epwmss1 = {
+	.master		= &dra7xx_l4_per2_hwmod,
+	.slave		= &dra7xx_epwmss1_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU,
+};
+
+struct omap_hwmod_ocp_if dra7xx_epwmss1__ecap1 = {
+	.master		= &dra7xx_epwmss1_hwmod,
+	.slave		= &dra7xx_ecap1_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU,
+};
+
+struct omap_hwmod_ocp_if dra7xx_epwmss1__eqep1 = {
+	.master		= &dra7xx_epwmss1_hwmod,
+	.slave		= &dra7xx_eqep1_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU,
+};
+
+struct omap_hwmod_ocp_if dra7xx_epwmss1__ehrpwm1 = {
+	.master		= &dra7xx_epwmss1_hwmod,
+	.slave		= &dra7xx_ehrpwm1_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU,
+};
+
+struct omap_hwmod_ocp_if dra7xx_l4_per2__epwmss2 = {
+	.master		= &dra7xx_l4_per2_hwmod,
+	.slave		= &dra7xx_epwmss2_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU,
+};
+
+struct omap_hwmod_ocp_if dra7xx_epwmss2__ecap2 = {
+	.master		= &dra7xx_epwmss2_hwmod,
+	.slave		= &dra7xx_ecap2_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU,
+};
+
+struct omap_hwmod_ocp_if dra7xx_epwmss2__eqep2 = {
+	.master		= &dra7xx_epwmss2_hwmod,
+	.slave		= &dra7xx_eqep2_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU,
+};
+
+struct omap_hwmod_ocp_if dra7xx_epwmss2__ehrpwm2 = {
+	.master		= &dra7xx_epwmss2_hwmod,
+	.slave		= &dra7xx_ehrpwm2_hwmod,
+	.clk		= "l4_root_clk_div",
+	.user		= OCP_USER_MPU,
+};
+
 /* l4_per1 -> gpio7 */
 static struct omap_hwmod_ocp_if dra7xx_l4_per1__gpio7 = {
 	.master		= &dra7xx_l4_per1_hwmod,
@@ -3452,6 +3679,18 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
 	&dra7xx_l3_main_1__vcp2,
 	&dra7xx_l4_per2__vcp2,
 	&dra7xx_l4_wkup__wd_timer2,
+	&dra7xx_l4_per2__epwmss0,
+	&dra7xx_epwmss0__ecap0,
+	&dra7xx_epwmss0__eqep0,
+	&dra7xx_epwmss0__ehrpwm0,
+	&dra7xx_l4_per2__epwmss1,
+	&dra7xx_epwmss1__ecap1,
+	&dra7xx_epwmss1__eqep1,
+	&dra7xx_epwmss1__ehrpwm1,
+	&dra7xx_l4_per2__epwmss2,
+	&dra7xx_epwmss2__ecap2,
+	&dra7xx_epwmss2__eqep2,
+	&dra7xx_epwmss2__ehrpwm2,
 	NULL,
 };
 
-- 
2.7.0



From fcooper at ti.com  Thu Feb 25 14:36:32 2016
From: fcooper at ti.com (Franklin S Cooper Jr)
Date: Thu, 25 Feb 2016 16:36:32 -0600
Subject: [PATCH v3 1/5] pwms: pwm-ti*: Remove support for local clock gating
In-Reply-To: <1456439796-28546-1-git-send-email-fcooper@ti.com>
References: <1456439796-28546-1-git-send-email-fcooper@ti.com>
Message-ID: <1456439796-28546-2-git-send-email-fcooper@ti.com>

The PWMSS local clock gating registers have no real purpose on OMAP ARM
devices. These registers were left over registers from DSP IP where the
PRCM doesn't exist. There is a silicon bug where gating and ungating clocks
don't function properly. TRMs will be update to indicate that these
registers shouldn't be touched.

Therefore, all code that accesses the PWMSS_CLKCONFIG or PWMSS_CLKSTATUS
will be removed by this patch with zero loss of functionality by the ECAP
and EPWM drivers.

Signed-off-by: Franklin S Cooper Jr <fcooper at ti.com>
---
Version 3 changes:
New patch

 drivers/pwm/pwm-tiecap.c   | 28 --------------------------
 drivers/pwm/pwm-tiehrpwm.c | 29 ---------------------------
 drivers/pwm/pwm-tipwmss.c  | 49 ----------------------------------------------
 drivers/pwm/pwm-tipwmss.h  | 39 ------------------------------------
 4 files changed, 145 deletions(-)
 delete mode 100644 drivers/pwm/pwm-tipwmss.h

diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
index 616af76..9e0865d7 100644
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@ -27,8 +27,6 @@
 #include <linux/pwm.h>
 #include <linux/of_device.h>
 
-#include "pwm-tipwmss.h"
-
 /* ECAP registers and bits definitions */
 #define CAP1			0x08
 #define CAP2			0x0C
@@ -206,7 +204,6 @@ static int ecap_pwm_probe(struct platform_device *pdev)
 	struct resource *r;
 	struct clk *clk;
 	struct ecap_pwm_chip *pc;
-	u16 status;
 
 	pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
 	if (!pc)
@@ -243,40 +240,15 @@ static int ecap_pwm_probe(struct platform_device *pdev)
 	}
 
 	pm_runtime_enable(&pdev->dev);
-	pm_runtime_get_sync(&pdev->dev);
-
-	status = pwmss_submodule_state_change(pdev->dev.parent,
-			PWMSS_ECAPCLK_EN);
-	if (!(status & PWMSS_ECAPCLK_EN_ACK)) {
-		dev_err(&pdev->dev, "PWMSS config space clock enable failed\n");
-		ret = -EINVAL;
-		goto pwmss_clk_failure;
-	}
-
-	pm_runtime_put_sync(&pdev->dev);
 
 	platform_set_drvdata(pdev, pc);
 	return 0;
-
-pwmss_clk_failure:
-	pm_runtime_put_sync(&pdev->dev);
-	pm_runtime_disable(&pdev->dev);
-	pwmchip_remove(&pc->chip);
-	return ret;
 }
 
 static int ecap_pwm_remove(struct platform_device *pdev)
 {
 	struct ecap_pwm_chip *pc = platform_get_drvdata(pdev);
 
-	pm_runtime_get_sync(&pdev->dev);
-	/*
-	 * Due to hardware misbehaviour, acknowledge of the stop_req
-	 * is missing. Hence checking of the status bit skipped.
-	 */
-	pwmss_submodule_state_change(pdev->dev.parent, PWMSS_ECAPCLK_STOP_REQ);
-	pm_runtime_put_sync(&pdev->dev);
-
 	pm_runtime_disable(&pdev->dev);
 	return pwmchip_remove(&pc->chip);
 }
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index 6a41e66..e09b1f0 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -27,8 +27,6 @@
 #include <linux/pm_runtime.h>
 #include <linux/of_device.h>
 
-#include "pwm-tipwmss.h"
-
 /* EHRPWM registers and bits definitions */
 
 /* Time base module registers */
@@ -437,7 +435,6 @@ static int ehrpwm_pwm_probe(struct platform_device *pdev)
 	struct resource *r;
 	struct clk *clk;
 	struct ehrpwm_pwm_chip *pc;
-	u16 status;
 
 	pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
 	if (!pc)
@@ -487,27 +484,9 @@ static int ehrpwm_pwm_probe(struct platform_device *pdev)
 	}
 
 	pm_runtime_enable(&pdev->dev);
-	pm_runtime_get_sync(&pdev->dev);
-
-	status = pwmss_submodule_state_change(pdev->dev.parent,
-			PWMSS_EPWMCLK_EN);
-	if (!(status & PWMSS_EPWMCLK_EN_ACK)) {
-		dev_err(&pdev->dev, "PWMSS config space clock enable failed\n");
-		ret = -EINVAL;
-		goto pwmss_clk_failure;
-	}
-
-	pm_runtime_put_sync(&pdev->dev);
 
 	platform_set_drvdata(pdev, pc);
 	return 0;
-
-pwmss_clk_failure:
-	pm_runtime_put_sync(&pdev->dev);
-	pm_runtime_disable(&pdev->dev);
-	pwmchip_remove(&pc->chip);
-	clk_unprepare(pc->tbclk);
-	return ret;
 }
 
 static int ehrpwm_pwm_remove(struct platform_device *pdev)
@@ -516,14 +495,6 @@ static int ehrpwm_pwm_remove(struct platform_device *pdev)
 
 	clk_unprepare(pc->tbclk);
 
-	pm_runtime_get_sync(&pdev->dev);
-	/*
-	 * Due to hardware misbehaviour, acknowledge of the stop_req
-	 * is missing. Hence checking of the status bit skipped.
-	 */
-	pwmss_submodule_state_change(pdev->dev.parent, PWMSS_EPWMCLK_STOP_REQ);
-	pm_runtime_put_sync(&pdev->dev);
-
 	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
 	return pwmchip_remove(&pc->chip);
diff --git a/drivers/pwm/pwm-tipwmss.c b/drivers/pwm/pwm-tipwmss.c
index 5cf65a1..829f499 100644
--- a/drivers/pwm/pwm-tipwmss.c
+++ b/drivers/pwm/pwm-tipwmss.c
@@ -22,32 +22,6 @@
 #include <linux/pm_runtime.h>
 #include <linux/of_device.h>
 
-#include "pwm-tipwmss.h"
-
-#define PWMSS_CLKCONFIG		0x8	/* Clock gating reg */
-#define PWMSS_CLKSTATUS		0xc	/* Clock gating status reg */
-
-struct pwmss_info {
-	void __iomem	*mmio_base;
-	struct mutex	pwmss_lock;
-	u16		pwmss_clkconfig;
-};
-
-u16 pwmss_submodule_state_change(struct device *dev, int set)
-{
-	struct pwmss_info *info = dev_get_drvdata(dev);
-	u16 val;
-
-	mutex_lock(&info->pwmss_lock);
-	val = readw(info->mmio_base + PWMSS_CLKCONFIG);
-	val |= set;
-	writew(val , info->mmio_base + PWMSS_CLKCONFIG);
-	mutex_unlock(&info->pwmss_lock);
-
-	return readw(info->mmio_base + PWMSS_CLKSTATUS);
-}
-EXPORT_SYMBOL(pwmss_submodule_state_change);
-
 static const struct of_device_id pwmss_of_match[] = {
 	{ .compatible	= "ti,am33xx-pwmss" },
 	{},
@@ -57,24 +31,10 @@ MODULE_DEVICE_TABLE(of, pwmss_of_match);
 static int pwmss_probe(struct platform_device *pdev)
 {
 	int ret;
-	struct resource *r;
-	struct pwmss_info *info;
 	struct device_node *node = pdev->dev.of_node;
 
-	info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
-	if (!info)
-		return -ENOMEM;
-
-	mutex_init(&info->pwmss_lock);
-
-	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	info->mmio_base = devm_ioremap_resource(&pdev->dev, r);
-	if (IS_ERR(info->mmio_base))
-		return PTR_ERR(info->mmio_base);
-
 	pm_runtime_enable(&pdev->dev);
 	pm_runtime_get_sync(&pdev->dev);
-	platform_set_drvdata(pdev, info);
 
 	/* Populate all the child nodes here... */
 	ret = of_platform_populate(node, NULL, NULL, &pdev->dev);
@@ -86,30 +46,21 @@ static int pwmss_probe(struct platform_device *pdev)
 
 static int pwmss_remove(struct platform_device *pdev)
 {
-	struct pwmss_info *info = platform_get_drvdata(pdev);
-
 	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
-	mutex_destroy(&info->pwmss_lock);
 	return 0;
 }
 
 #ifdef CONFIG_PM_SLEEP
 static int pwmss_suspend(struct device *dev)
 {
-	struct pwmss_info *info = dev_get_drvdata(dev);
-
-	info->pwmss_clkconfig = readw(info->mmio_base + PWMSS_CLKCONFIG);
 	pm_runtime_put_sync(dev);
 	return 0;
 }
 
 static int pwmss_resume(struct device *dev)
 {
-	struct pwmss_info *info = dev_get_drvdata(dev);
-
 	pm_runtime_get_sync(dev);
-	writew(info->pwmss_clkconfig, info->mmio_base + PWMSS_CLKCONFIG);
 	return 0;
 }
 #endif
diff --git a/drivers/pwm/pwm-tipwmss.h b/drivers/pwm/pwm-tipwmss.h
deleted file mode 100644
index 10ad804..0000000
--- a/drivers/pwm/pwm-tipwmss.h
+++ /dev/null
@@ -1,39 +0,0 @@
-/*
- * TI PWM Subsystem driver
- *
- * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#ifndef __TIPWMSS_H
-#define __TIPWMSS_H
-
-/* PWM substem clock gating */
-#define PWMSS_ECAPCLK_EN	BIT(0)
-#define PWMSS_ECAPCLK_STOP_REQ	BIT(1)
-#define PWMSS_EPWMCLK_EN	BIT(8)
-#define PWMSS_EPWMCLK_STOP_REQ	BIT(9)
-
-#define PWMSS_ECAPCLK_EN_ACK	BIT(0)
-#define PWMSS_EPWMCLK_EN_ACK	BIT(8)
-
-#ifdef CONFIG_PWM_TIPWMSS
-extern u16 pwmss_submodule_state_change(struct device *dev, int set);
-#else
-static inline u16 pwmss_submodule_state_change(struct device *dev, int set)
-{
-	/* return success status value */
-	return 0xFFFF;
-}
-#endif
-#endif	/* __TIPWMSS_H */
-- 
2.7.0



From fcooper at ti.com  Thu Feb 25 14:36:34 2016
From: fcooper at ti.com (Franklin S Cooper Jr)
Date: Thu, 25 Feb 2016 16:36:34 -0600
Subject: [PATCH v3 3/5] ARM: dts: DRA7: Add TBCLK for PWMSS
In-Reply-To: <1456439796-28546-1-git-send-email-fcooper@ti.com>
References: <1456439796-28546-1-git-send-email-fcooper@ti.com>
Message-ID: <1456439796-28546-4-git-send-email-fcooper@ti.com>

From: Vignesh R <vigneshr at ti.com>

tbclk is used by ehrpwm to generate PWM waveform on DRA7 SoC. Add Linux
clock to control ehrpwm tbclk.
The TRM says, tbclk is derived from SYSCLKOUT. SYSCLKOUT is nothing but
ehrpwm functional clock derived from the gateable interface and
functional clock of PWMSS(l4_root_clk_div).
Refer AM57x TRM SPRUHZ6[1], October 2014, Table 29-4 and Section 29.2.2.1,
Table 29-19 and the NOTE at the end of the table.

[1] www.ti.com/lit/ug/spruhz6/spruhz6.pdf

Signed-off-by: Vignesh R <vigneshr at ti.com>
---
Version 3 changes:
None

 arch/arm/boot/dts/dra7xx-clocks.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 357bede..d0bae06 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -2146,4 +2146,28 @@
 		ti,bit-shift = <0>;
 		reg = <0x558>;
 	};
+
+       ehrpwm0_tbclk: ehrpwm0_tbclk {
+		#clock-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&l4_root_clk_div>;
+		ti,bit-shift = <20>;
+		reg = <0x0558>;
+	};
+
+	ehrpwm1_tbclk: ehrpwm1_tbclk {
+		#clock-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&l4_root_clk_div>;
+		ti,bit-shift = <21>;
+		reg = <0x0558>;
+	};
+
+	ehrpwm2_tbclk: ehrpwm2_tbclk {
+		#clock-cells = <0>;
+		compatible = "ti,gate-clock";
+		clocks = <&l4_root_clk_div>;
+		ti,bit-shift = <22>;
+		reg = <0x0558>;
+	};
 };
-- 
2.7.0



From fcooper at ti.com  Thu Feb 25 14:36:36 2016
From: fcooper at ti.com (Franklin S Cooper Jr)
Date: Thu, 25 Feb 2016 16:36:36 -0600
Subject: [PATCH v3 5/5] ARM: dts: DRA7: Add dt nodes for PWMSS
In-Reply-To: <1456439796-28546-1-git-send-email-fcooper@ti.com>
References: <1456439796-28546-1-git-send-email-fcooper@ti.com>
Message-ID: <1456439796-28546-6-git-send-email-fcooper@ti.com>

From: Vignesh R <vigneshr at ti.com>

Add PWMSS device tree nodes for DRA7 SoC family and add documentation
for dt bindings.

Signed-off-by: Vignesh R <vigneshr at ti.com>
---
Version 3 changes:
None

 .../devicetree/bindings/pwm/pwm-tiehrpwm.txt       |  8 +++
 .../devicetree/bindings/pwm/pwm-tipwmss.txt        | 17 +++++-
 arch/arm/boot/dts/dra7.dtsi                        | 64 ++++++++++++++++++++++
 3 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
index 9c100b2..25d91ae 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
@@ -4,6 +4,7 @@ Required properties:
 - compatible: Must be "ti,<soc>-ehrpwm".
   for am33xx - compatible = "ti,am33xx-ehrpwm";
   for da850  - compatible = "ti,da850-ehrpwm", "ti,am33xx-ehrpwm";
+  for dra7xx - compatible = "ti,dra7xx-ehrpwm", "ti,am33xx-ehrpwm";
 - #pwm-cells: should be 3. See pwm.txt in this directory for a description of
   the cells format. The only third cell flag supported by this binding is
   PWM_POLARITY_INVERTED.
@@ -27,3 +28,10 @@ ehrpwm0: ehrpwm at 0 { /* EHRPWM on da850 */
 	#pwm-cells = <3>;
 	reg = <0x300000 0x2000>;
 };
+
+ehrpwm0: ehrpwm at 0 { /* EHRPWM on dra7xx */
+	compatible = "ti,dra7xx-ehrpwm", "ti,am33xx-ehrpwm";
+	#pwm-cells = <3>;
+	reg = <0x48440200 0x80>;
+	ti,hwmods = "ehrpwm0";
+};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt b/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
index f7eae77..9270ce6 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
@@ -1,7 +1,9 @@
 TI SOC based PWM Subsystem
 
 Required properties:
-- compatible: Must be "ti,am33xx-pwmss";
+- compatible: Must be "ti,<soc>-pwmss".
+  for am33xx - compatible = "ti,am33xx-pwmss"
+  for dra7xx - compatible = "ti,dra7xx-pwmss", "ti,am33xx-pwmss"
 - reg: physical base address and size of the registers map.
 - address-cells: Specify the number of u32 entries needed in child nodes.
 		  Should set to 1.
@@ -29,3 +31,16 @@ pwmss0: pwmss at 48300000 {
 
 	/* child nodes go here */
 };
+
+epwmss0: epwmss at 4843e000 { /* On DRA7xx */
+	compatible = "ti,dra7xx-pwmss", "ti,am33xx-pwmss";
+	reg = <0x4843e000 0x30>;
+	ti,hwmods = "epwmss0";
+	#address-cells = <1>;
+	#size-cells = <1>;
+	ranges = <0x4843e100  0x4843e100 0x80	/* ECAP */
+		  0x4843e180  0x4843e180 0x80	/* EQEP */
+		  0x4843e200  0x4843e200 0x80>; /* EHRPWM */
+
+	/* child nodes go here */
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index c4d9175..9143db0 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1597,6 +1597,70 @@
 				clock-names = "fck", "sys_clk";
 			};
 		};
+
+		epwmss0: epwmss at 4843e000 {
+			compatible = "ti,dra7xx-pwmss", "ti,am33xx-pwmss";
+			reg = <0x4843e000 0x30>;
+			ti,hwmods = "epwmss0";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			status = "disabled";
+			ranges = <0x4843e100  0x4843e100 0x80  /* ECAP */
+				  0x4843e180  0x4843e180 0x80  /* EQEP */
+				  0x4843e200  0x4843e200 0x80>;/* EHRPWM */
+
+			ehrpwm0: ehrpwm at 4843e200 {
+				compatible = "ti,dra7xx-ehrpwm",
+					     "ti,am33xx-ehrpwm";
+				#pwm-cells = <3>;
+				reg = <0x4843e200 0x80>;
+				ti,hwmods = "ehrpwm0";
+				status = "disabled";
+			};
+		};
+
+		epwmss1: epwmss at 48440000 {
+			compatible = "ti,dra7xx-pwmss", "ti,am33xx-pwmss";
+			reg = <0x48440000 0x30>;
+			ti,hwmods = "epwmss1";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			status = "disabled";
+			ranges = <0x48440100  0x48440100  0x80   /* ECAP */
+				  0x48440180  0x48440180  0x80   /* EQEP */
+				  0x48440200  0x48440200  0x80>; /* EHRPWM */
+
+			ehrpwm1: ehrpwm at 48440200 {
+				compatible = "ti,dra7xx-ehrpwm",
+					     "ti,am33xx-ehrpwm";
+				#pwm-cells = <3>;
+				reg = <0x48440200 0x80>;
+				ti,hwmods = "ehrpwm1";
+				status = "disabled";
+			};
+		};
+
+		epwmss2: epwmss at 48442000 {
+			compatible = "ti,dra7xx-pwmss", "ti,am33xx-pwmss";
+			reg = <0x48442000 0x30>;
+			ti,hwmods = "epwmss2";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			status = "disabled";
+
+			ranges = <0x48442100  0x48442100  0x80   /* ECAP */
+				  0x48442180  0x48442180  0x80   /* EQEP */
+				  0x48442200  0x48442200  0x80>; /* EHRPWM */
+
+			ehrpwm2: ehrpwm at 48442200 {
+				compatible = "ti,dra7xx-ehrpwm",
+					     "ti,am33xx-ehrpwm";
+				#pwm-cells = <3>;
+				reg = <0x48442200 0x80>;
+				ti,hwmods = "ehrpwm2";
+				status = "disabled";
+			};
+		};
 	};
 
 	thermal_zones: thermal-zones {
-- 
2.7.0



From lkp at intel.com  Thu Feb 25 14:54:29 2016
From: lkp at intel.com (kbuild test robot)
Date: Fri, 26 Feb 2016 06:54:29 +0800
Subject: [PATCH v2] ARM: dts: sun8i: Add leds and switch on Orangepi Plus
 boards
In-Reply-To: <20160225204234.GA31610@box2.japko.eu>
Message-ID: <201602260632.mOdfvVuL%fengguang.wu@intel.com>

Hi Krzysztof,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.5-rc5 next-20160225]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Krzysztof-Adamski/ARM-dts-sun8i-Add-leds-and-switch-on-Orangepi-Plus-boards/20160226-044640
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: arm-sunxi_defconfig (attached as .config)
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> Error: arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts:104.1-7 Label or path r_pio not found
   FATAL ERROR: Syntax error parsing input tree

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 17442 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160226/de271787/attachment-0001.obj>

From colin.king at canonical.com  Thu Feb 25 15:09:59 2016
From: colin.king at canonical.com (Colin King)
Date: Thu, 25 Feb 2016 23:09:59 +0000
Subject: [PATCH][V2] mt7601u: do not free dma_buf when ivp allocation fails
Message-ID: <1456441799-19266-1-git-send-email-colin.king@canonical.com>

From: Colin Ian King <colin.king at canonical.com>

If the allocation of ivp fails the error handling attempts to
free an uninitialized dma_buf; this data structure just contains
garbage on the stack, so the freeing will cause issues when the
urb, buf and dma fields are free'd. Fix this by not free'ing the
dma_buf if the ivp allocation fails.

Signed-off-by: Colin Ian King <colin.king at canonical.com>
---
 drivers/net/wireless/mediatek/mt7601u/mcu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt7601u/mcu.c b/drivers/net/wireless/mediatek/mt7601u/mcu.c
index fbb1986..70e4b5e 100644
--- a/drivers/net/wireless/mediatek/mt7601u/mcu.c
+++ b/drivers/net/wireless/mediatek/mt7601u/mcu.c
@@ -362,10 +362,10 @@ mt7601u_upload_firmware(struct mt7601u_dev *dev, const struct mt76_fw *fw)
 	int i, ret;
 
 	ivb = kmemdup(fw->ivb, sizeof(fw->ivb), GFP_KERNEL);
-	if (!ivb || mt7601u_usb_alloc_buf(dev, MCU_FW_URB_SIZE, &dma_buf)) {
-		ret = -ENOMEM;
+	if (!ivb)
+		return -ENOMEM;
+	if (mt7601u_usb_alloc_buf(dev, MCU_FW_URB_SIZE, &dma_buf))
 		goto error;
-	}
 
 	ilm_len = le32_to_cpu(fw->hdr.ilm_len) - sizeof(fw->ivb);
 	dev_dbg(dev->dev, "loading FW - ILM %u + IVB %zu\n",
-- 
2.7.0



From dianders at google.com  Thu Feb 25 15:14:03 2016
From: dianders at google.com (Doug Anderson)
Date: Thu, 25 Feb 2016 15:14:03 -0800
Subject: [PATCH v3 00/12] pwm: add support for atomic update
In-Reply-To: <CAD=FV=VM3cOQ0HqwLANBw9MVBCyFTrSyPe_dGzgPucuMUEWRKA@mail.gmail.com>
References: <20151110173416.GB21727@ulmo>
 <CAD=FV=WL3jYEgVe-m6QcAyQwfJgdX4J5OtKisKwyoKOrTSpEQA@mail.gmail.com>
 <20160125170855.GA10182@ulmo>
 <CAD=FV=Xvxeqo3imUmjukC5iYk3EZkrJ04G7C1B-w4xyr-r6-2Q@mail.gmail.com>
 <20160203145337.GD9650@ulmo>
 <CAD=FV=U_x1cxx6RrHuVgVV8GbOwm9DXXJcyiArbbQySUOaxrvQ@mail.gmail.com>
 <20160222175929.GA23899@ulmo>
 <CAD=FV=UCErW3EjYRtwt49_ztNR7cyY4U0o4R_dxdomer-Ac2Dg@mail.gmail.com>
 <20160223143859.GA27656@ulmo>
 <CAD=FV=UvxG3MYD4MKQJqN7W68uMjd-s+FH-e8tkrLCpS0RLmZQ@mail.gmail.com>
 <20160223181448.GA14754@ulmo.nvidia.com>
 <CAD=FV=VM3cOQ0HqwLANBw9MVBCyFTrSyPe_dGzgPucuMUEWRKA@mail.gmail.com>
Message-ID: <CAD=FV=VckTVD8b1g+f0G2kMeoTjvY0pAGhoDnWQN_dAmqSxBxg@mail.gmail.com>

Thierry,

On Tue, Feb 23, 2016 at 10:42 AM, Doug Anderson <dianders at google.com> wrote:
> Thierry,
>
> On Tue, Feb 23, 2016 at 10:14 AM, Thierry Reding
> <thierry.reding at gmail.com> wrote:
>>> pwm_get_period(): get the period of the PWM; if the PWM has not yet
>>> been configured by software this gets the default period (possibly
>>> specified by the device tree).
>>
>> No. I think we'll need a different construct for the period defined by
>> DT or board files. pwm_get_period() is the legacy API to retrieve the
>> "current" period, even if it was lying a little before the atomic API.
>
> Ah, got it.  I think I missed that you considered pwm_get_period()
> legacy and that you eventually wanted to get rid of it.  OK, then what
> you say makes sense.
>
>
>>> That should work with one minor problem.  If HW readout isn't
>>> supported then pwm_get_state() in probe will presumably return 0 for
>>> the duty cycle.  That means it will change the voltage.  That's in
>>> contrast to how I think things work today where the voltage isn't
>>> changed until the first set_voltage() call.  At least the last time I
>>> tested things get_voltage() would simply report an incorrect value
>>> until the first set_voltage().  I think existing behavior (reporting
>>> the wrong value) is better than new behavior (change the value at
>>> probe).
>>
>> That's exactly the point. Reporting a wrong value isn't really a good
>> option. Changing the voltage on boot is the only way to make the logical
>> state match the hardware state on boot. Chances are that if you don't
>> have hardware readout support you probably don't care what state your
>> regulator will be in.
>>
>> Then again, if we don't support hardware readout, setting up the logical
>> state with data from DT (or board files) and defaulting the duty cycle
>> to 0, we end up with exactly what we had before, even with the atomic
>> API, right? Maybe that's okay, too.
>
> IMHO this is a change in behavior that will break existing users.
> Anyone using a PWM regulator will suddenly find their voltage changing
> at bootup.  Certainly today all users of the PWM regulator don't seem
> to mind (apparently) the the voltage is reported incorrectly at bootup
> but I bet they'd mind if the voltage suddenly started changing for
> them at bootup.
>
> It seems better to preserve existing behavior and print a warning that
> the voltage will be reported incorrectly until HW Readout is
> supported.
>
> Of course, we're only talking about two real users in mainline here:
> Rockchip boards and the "stih407-family".  If we just fix both of
> those to support HW Readout before landing the change then I'm fine
> with doing what you say.
>
>
>>> ...and if set_voltage() remains untouched then we can solve my probe
>>> problem by renaming pwm_get_state() to pwm_get_hw_state() and having
>>> it return an error if HW readout is not supported.  Then we only call
>>> pwm_get_args() / pwm_apply_state() when we support HW readout.
>>
>> The problem is that we make the API clumsy to use. If we don't sync the
>> "initial" state (as defined by DT or board files) to hardware at any
>> point, then we need to add the pwm_args construct and always stick to
>> it. I think it weird to have to use the pwm_args.period instead of the
>> current period.
>>
>> So we're back to square one, really. That's exactly what Mark brought up
>> originally.
>
> I had missed the part where you wanted to deprecate pwm_get_period().
> Thus my points here aren't really valid.
>
> In my mind the old API was perfectly fine (and actually quite clean /
> simple to use) except in the special case of avoiding the PWM
> regulator glitches.  With that mindset I think my previous email make
> sense.  However, this is your subsystem to maintain and if you think
> moving everyone to a new atomic API makes more sense then you're in
> the best position to make that decision.  :)

So just to summarize:

* Add pwm_get_state(), pwm_apply_state(), pwm_get_args().
pwm_get_state() initially returns 0 for duty cycle if driver doesn't
support readout.

* Re-implement pwm_get_period() (and maybe other similar functions)
atop pwm_get_state() as you describe earlier in the thread.

* Document pwm_get_period() (and maybe other similar functions) as deprecated.

* Fix drivers for all current 2 users of PWM regulator to support
hardware readout.

* Update PWM regulator as you described earlier in the thread (Feb 23).

* If PWM regulator is ever used on a new board whose PWM doesn't
support hardware readout, the voltage will change at probe time.


Did I get all that right?  Thanks!

-Doug


From julian.calaby at gmail.com  Thu Feb 25 15:14:59 2016
From: julian.calaby at gmail.com (Julian Calaby)
Date: Fri, 26 Feb 2016 10:14:59 +1100
Subject: [PATCH][V2] mt7601u: do not free dma_buf when ivp allocation fails
In-Reply-To: <1456441799-19266-1-git-send-email-colin.king@canonical.com>
References: <1456441799-19266-1-git-send-email-colin.king@canonical.com>
Message-ID: <CAGRGNgX0323K81mi_7yyUu18-CB6=GTrMM0J72iuYPBv9JD88g@mail.gmail.com>

Hi Colin,

On Fri, Feb 26, 2016 at 10:09 AM, Colin King <colin.king at canonical.com> wrote:
> From: Colin Ian King <colin.king at canonical.com>
>
> If the allocation of ivp fails the error handling attempts to
> free an uninitialized dma_buf; this data structure just contains
> garbage on the stack, so the freeing will cause issues when the
> urb, buf and dma fields are free'd. Fix this by not free'ing the
> dma_buf if the ivp allocation fails.
>
> Signed-off-by: Colin Ian King <colin.king at canonical.com>
> ---
>  drivers/net/wireless/mediatek/mt7601u/mcu.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt7601u/mcu.c b/drivers/net/wireless/mediatek/mt7601u/mcu.c
> index fbb1986..70e4b5e 100644
> --- a/drivers/net/wireless/mediatek/mt7601u/mcu.c
> +++ b/drivers/net/wireless/mediatek/mt7601u/mcu.c
> @@ -362,10 +362,10 @@ mt7601u_upload_firmware(struct mt7601u_dev *dev, const struct mt76_fw *fw)
>         int i, ret;
>
>         ivb = kmemdup(fw->ivb, sizeof(fw->ivb), GFP_KERNEL);
> -       if (!ivb || mt7601u_usb_alloc_buf(dev, MCU_FW_URB_SIZE, &dma_buf)) {
> -               ret = -ENOMEM;
> +       if (!ivb)
> +               return -ENOMEM;
> +       if (mt7601u_usb_alloc_buf(dev, MCU_FW_URB_SIZE, &dma_buf))
>                 goto error;

Are you sure this is right? Isn't ret unset here and consequently
returned at the end of the error label?

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


From colin.king at canonical.com  Thu Feb 25 15:24:27 2016
From: colin.king at canonical.com (Colin King)
Date: Thu, 25 Feb 2016 23:24:27 +0000
Subject: [PATCH][V3] mt7601u: do not free dma_buf when ivp allocation fails
Message-ID: <1456442667-19751-1-git-send-email-colin.king@canonical.com>

From: Colin Ian King <colin.king at canonical.com>

If the allocation of ivp fails the error handling attempts to
free an uninitialized dma_buf; this data structure just contains
garbage on the stack, so the freeing will cause issues when the
urb, buf and dma fields are free'd. Fix this by not free'ing the
dma_buf if the ivp allocation fails.

Signed-off-by: Colin Ian King <colin.king at canonical.com>
---
 drivers/net/wireless/mediatek/mt7601u/mcu.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt7601u/mcu.c b/drivers/net/wireless/mediatek/mt7601u/mcu.c
index fbb1986..91c4b34 100644
--- a/drivers/net/wireless/mediatek/mt7601u/mcu.c
+++ b/drivers/net/wireless/mediatek/mt7601u/mcu.c
@@ -362,7 +362,9 @@ mt7601u_upload_firmware(struct mt7601u_dev *dev, const struct mt76_fw *fw)
 	int i, ret;
 
 	ivb = kmemdup(fw->ivb, sizeof(fw->ivb), GFP_KERNEL);
-	if (!ivb || mt7601u_usb_alloc_buf(dev, MCU_FW_URB_SIZE, &dma_buf)) {
+	if (!ivb)
+		return -ENOMEM;
+	if (mt7601u_usb_alloc_buf(dev, MCU_FW_URB_SIZE, &dma_buf)) {
 		ret = -ENOMEM;
 		goto error;
 	}
-- 
2.7.0



From julian.calaby at gmail.com  Thu Feb 25 15:31:06 2016
From: julian.calaby at gmail.com (Julian Calaby)
Date: Fri, 26 Feb 2016 10:31:06 +1100
Subject: [PATCH][V3] mt7601u: do not free dma_buf when ivp allocation fails
In-Reply-To: <1456442667-19751-1-git-send-email-colin.king@canonical.com>
References: <1456442667-19751-1-git-send-email-colin.king@canonical.com>
Message-ID: <CAGRGNgUq_YTi1h_FBxGSFGLUhHoz3xQguDU_5ZFhSyUKAruW1w@mail.gmail.com>

Hi,

On Fri, Feb 26, 2016 at 10:24 AM, Colin King <colin.king at canonical.com> wrote:
> From: Colin Ian King <colin.king at canonical.com>
>
> If the allocation of ivp fails the error handling attempts to
> free an uninitialized dma_buf; this data structure just contains
> garbage on the stack, so the freeing will cause issues when the
> urb, buf and dma fields are free'd. Fix this by not free'ing the
> dma_buf if the ivp allocation fails.
>
> Signed-off-by: Colin Ian King <colin.king at canonical.com>

Looks right to me.

Reviewed-by: Julian Calaby <julian.calaby at gmail.com>

> ---
>  drivers/net/wireless/mediatek/mt7601u/mcu.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt7601u/mcu.c b/drivers/net/wireless/mediatek/mt7601u/mcu.c
> index fbb1986..91c4b34 100644
> --- a/drivers/net/wireless/mediatek/mt7601u/mcu.c
> +++ b/drivers/net/wireless/mediatek/mt7601u/mcu.c
> @@ -362,7 +362,9 @@ mt7601u_upload_firmware(struct mt7601u_dev *dev, const struct mt76_fw *fw)
>         int i, ret;
>
>         ivb = kmemdup(fw->ivb, sizeof(fw->ivb), GFP_KERNEL);
> -       if (!ivb || mt7601u_usb_alloc_buf(dev, MCU_FW_URB_SIZE, &dma_buf)) {
> +       if (!ivb)
> +               return -ENOMEM;
> +       if (mt7601u_usb_alloc_buf(dev, MCU_FW_URB_SIZE, &dma_buf)) {
>                 ret = -ENOMEM;
>                 goto error;
>         }
> --
> 2.7.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/


From kubakici at wp.pl  Thu Feb 25 15:36:31 2016
From: kubakici at wp.pl (Kuba Kicinski)
Date: Thu, 25 Feb 2016 18:36:31 -0500
Subject: [PATCH][V3] mt7601u: do not free dma_buf when ivp allocation fails
In-Reply-To: <1456442667-19751-1-git-send-email-colin.king@canonical.com>
References: <1456442667-19751-1-git-send-email-colin.king@canonical.com>
Message-ID: <286FE43B-A725-4BE0-B490-E91A107F8D0B@wp.pl>

On 25 February 2016 18:24:27 GMT-05:00, Colin King <colin.king at canonical.com> wrote:
>From: Colin Ian King <colin.king at canonical.com>
>
>If the allocation of ivp fails the error handling attempts to
>free an uninitialized dma_buf; this data structure just contains
>garbage on the stack, so the freeing will cause issues when the
>urb, buf and dma fields are free'd. Fix this by not free'ing the
>dma_buf if the ivp allocation fails.
>
>Signed-off-by: Colin Ian King <colin.king at canonical.com>

LGTM, thanks.



From tim at krieglstein.org  Thu Feb 25 15:34:59 2016
From: tim at krieglstein.org (Tim Sander)
Date: Fri, 26 Feb 2016 00:34:59 +0100
Subject: [PATCH v2] dts: add specific compatible type for Terasic
 DE0-NANO-SoC Board
In-Reply-To: <56CF323C.90202@opensource.altera.com>
References: <8416439.76b9YNhpgR@dabox> <20160225103820.GB747@pengutronix.de>
 <56CF323C.90202@opensource.altera.com>
Message-ID: <1595377.ZIYnBnVf5Q@virgo>

Hi Dinh

On Thursday 25 February 2016 10:56:28 Dinh Nguyen wrote:
> On 02/25/2016 04:38 AM, Steffen Trumtrar wrote:
> > Hi Tim!
> > 
> > On Thu, Feb 25, 2016 at 11:05:05AM +0100, Tim Sander wrote:
> >> From: Tim Sander <tim at krieglstein.org>
> >> 
> >> Add a more specific compatible string:"terasic,de0-nano-soc" for
> >> respective board. Background: when checking for bootspec entries, some
> >> board specific fixups are not apropriate for board of the same platform
> >> ("altr,socfpga-cyclone5"). The same aproach is taken with the
> >> EBV-Socrates board.
> >> 
> >> Signed-off-by: Tim Sander <tim at krieglstein.org>
> >> ---
> >> 
> >>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> >>  arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts     | 2 +-
> >>  2 files changed, 2 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> >> b/Documentation/devicetree/bindings/vendor-prefixes.txt index
> >> 72e2c5a..d1f7803 100644
> >> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> >> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> >> @@ -230,6 +230,7 @@ synology	Synology, Inc.
> >> 
> >>  tbs	TBS Technologies
> >>  tcl	Toby Churchill Ltd.
> >>  technologic	Technologic Systems
> >> 
> >> +terasic	Terasic Inc.
> >> 
> >>  thine	THine Electronics, Inc.
> >>  ti	Texas Instruments
> >>  tlm	Trusted Logic Mobility
> > 
> > You should IMHO split this up in two patches.
> > First patch: add terasic
> 
> That's right. That patch will go through the DTS maintainer's tree.
Ah well for such a simple patch it turns out more complicated than thought :-)
Will do as soon as there is agreement on a name which does not seem that 
easy...
> 
> >> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
> >> b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts index
> >> afea364..704aa9d 100644
> >> --- a/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
> >> +++ b/arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dts
> >> @@ -18,7 +18,7 @@
> >> 
> >>  / {
> >>  
> >>  	model = "Terasic DE-0(Atlas)";
> >> 
> >> -	compatible = "altr,socfpga-cyclone5", "altr,socfpga";
> >> +	compatible = "terasic,de0-nano-soc","altr,socfpga-cyclone5",
> >> "altr,socfpga";
> So perhaps, "terasic,de0-sockit"?
> 
> > Second patch: this.
> 
> And I can take this one.
> 
> >>  	chosen {
> >>  	
> >>  		bootargs = "earlyprintk";
> > 
> > The naming of this board still confuses me though.
> > 
> > It has 3 different names now:
> > 	- de0_sockit.dts
> > 	- Terasic DE-0(Atlas)
> > 	- de0-nano-soc
> > 
> > And according to Terasic DE0-Nano-SoC is the same as Atlas-SoC with a
> > different software?! So all three names are actually correct ?! Weird.
> 
> I had a hard time understanding this myself. But from what I gather
> from[1], I just name the file de0_sockit.
As far as i remember there are different de0 and different sockit boards, so 
the name does not seem to be as concise? I don't care but i would say that
de0-nano-soc is the most concise and easier to search for than atlas which
might turn up more false postives?

But as long as there is a more selective name than cyclone5 everthing is fine
with me.

Best regards
Tim



From sboyd at codeaurora.org  Thu Feb 25 15:37:10 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Feb 2016 15:37:10 -0800
Subject: [PATCH v2 1/6] dt-bindings: arm/marvell: add DT bindings for
 AP806 DFX Server
In-Reply-To: <1456326866-30854-2-git-send-email-thomas.petazzoni@free-electrons.com>
References: <1456326866-30854-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1456326866-30854-2-git-send-email-thomas.petazzoni@free-electrons.com>
Message-ID: <20160225233710.GJ28849@codeaurora.org>

On 02/24, Thomas Petazzoni wrote:
> +Marvell AP806 DFX Server
> +------------------------
> +
> +The Marvell AP806 HW block (which is a core component of the Marvell
> +Armada 7K and 8K SOCs) has a set of registers called "DFX
> +Server". This set of registers contains miscellaneous registers, most
> +of them being used for silicon fine-tuning and manufacturing testing,
> +and as such are not publicly documented. However, this DFX server
> +register range also contains a few documented and useful registers,
> +for example for clock control.
> +
> +This Device Tree binding allows to represent the entire DFX server
> +register space as one single DT node.
> +
> +Required properties:
> +- compatible: the first and second values must be:
> +	"simple-mfd", "syscon"
> +- reg: address and length of following register sets for the DFX
> +  server

Example?

I would think the binding would be done in a way that we don't
have to describe every little register in this misc register
block. Instead, dfx server has a compatible:

 node at f00 {
 	reg = <0xf00 0x100>;
	compatible = "marvell,dfx-ap806";
	#clock-cells = <1>;
 };

And then a driver that probes this compatible string and
registers a handful of clks. If we ever get into a situation
where we want to expose non-clk functionality from this device
node, we would make some sort of mfd driver that probes based on
the same compatible string and creates platform devices in
software to register the clk device component and whatever other
device type is used. In that situation, we could assign a regmap
to the mfd device and the clk device would be a child of the mfd
and get a regmap through the dev->parent pointer.

TL;DR I'm still lost why we have to describe each clk in DT.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From sboyd at codeaurora.org  Thu Feb 25 15:42:15 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Feb 2016 15:42:15 -0800
Subject: [PATCH v9 2/6] clk: hisilicon: add CRG driver for hi3519 soc
In-Reply-To: <1456127280-23275-3-git-send-email-xuejiancheng@huawei.com>
References: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
 <1456127280-23275-3-git-send-email-xuejiancheng@huawei.com>
Message-ID: <20160225234215.GK28849@codeaurora.org>

On 02/22, Jiancheng Xue wrote:
> diff --git a/Documentation/devicetree/bindings/clock/hi3519-crg.txt b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
> new file mode 100644
> index 0000000..2d23950
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
> @@ -0,0 +1,46 @@
> +Example: CRG nodes
> +CRG: clock-reset-controller at 12010000 {
> +	compatible = "hisilicon,hi3519-crg";

Indentation is off here.

> +        reg = <0x12010000 0x10000>;
> +        #clock-cells = <1>;
> +        #reset-cells = <2>;
> +};
> +
> +Example: consumer nodes
> +i2c0: i2c at 12110000 {
> +	compatible = "hisilicon,hi3519-i2c";
> +        reg = <0x12110000 0x1000>;
> +        clocks = <&CRG HI3519_I2C0_RST>;*/
> +        resets = <&CRG 0xe4 0>;
> +};
> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
> index e434854..296371f 100644
> --- a/drivers/clk/hisilicon/Kconfig
> +++ b/drivers/clk/hisilicon/Kconfig
> @@ -1,3 +1,11 @@
> +config COMMON_CLK_HI3519
> +	tristate "Hi3519 Clock Driver"
> +	depends on ARCH_HISI || COMPILE_TEST
> +	select RESET_HISI
> +	default y

default ARCH_HISI

> +	help
> +	  Build the clock driver for hi3519.
> +
> diff --git a/drivers/clk/hisilicon/reset.c b/drivers/clk/hisilicon/reset.c
> new file mode 100644
> index 0000000..50e00e7
> --- /dev/null
> +++ b/drivers/clk/hisilicon/reset.c
> +
> +int hisi_reset_init(struct device_node *np)
> +{
> +	struct hisi_reset_controller *rstc;
> +
> +	rstc = kzalloc(sizeof(*rstc), GFP_KERNEL);
> +	if (!rstc)
> +		return -ENOMEM;
> +
> +	rstc->membase = of_iomap(np, 0);

Any reason why we can't pass the platform device here and map the
register space with platform device APIs?

> +	if (!rstc->membase)
> +		return -EINVAL;
> +
> +	spin_lock_init(&rstc->lock);
> +
> +	rstc->rcdev.owner = THIS_MODULE;
> +	rstc->rcdev.ops = &hisi_reset_ops;
> +	rstc->rcdev.of_node = np;
> +	rstc->rcdev.of_reset_n_cells = 2;
> +	rstc->rcdev.of_xlate = hisi_reset_of_xlate;
> +
> +	return reset_controller_register(&rstc->rcdev);
> +}
> +EXPORT_SYMBOL(hisi_reset_init);

Why not GPL?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From sboyd at codeaurora.org  Thu Feb 25 15:42:44 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Feb 2016 15:42:44 -0800
Subject: [PATCH v9 1/6] clk: hisilicon: export some hisilicon APIs to
 modules
In-Reply-To: <1456127280-23275-2-git-send-email-xuejiancheng@huawei.com>
References: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
 <1456127280-23275-2-git-send-email-xuejiancheng@huawei.com>
Message-ID: <20160225234244.GL28849@codeaurora.org>

On 02/22, Jiancheng Xue wrote:
> Change some arguments to constant type.
> Export some hisilicon APIs to modules.
> 
> Signed-off-by: Jiancheng Xue <xuejiancheng at huawei.com>
> ---
>  drivers/clk/hisilicon/clk.c | 23 +++++++++++++++--------
>  drivers/clk/hisilicon/clk.h | 14 +++++++-------
>  2 files changed, 22 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/clk/hisilicon/clk.c b/drivers/clk/hisilicon/clk.c
> index 9f8e766..06ec3fe 100644
> --- a/drivers/clk/hisilicon/clk.c
> +++ b/drivers/clk/hisilicon/clk.c
> @@ -37,7 +37,7 @@
>  
>  static DEFINE_SPINLOCK(hisi_clk_lock);
>  
> -struct hisi_clock_data __init *hisi_clk_init(struct device_node *np,
> +struct hisi_clock_data *hisi_clk_init(struct device_node *np,
>  					     int nr_clks)
>  {
>  	struct hisi_clock_data *clk_data;
> @@ -71,8 +71,9 @@ err_data:
>  err:
>  	return NULL;
>  }
> +EXPORT_SYMBOL(hisi_clk_init);

Why not EXPORT_SYMBOL_GPL?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From dinguyen at opensource.altera.com  Thu Feb 25 15:38:17 2016
From: dinguyen at opensource.altera.com (Dinh Nguyen)
Date: Thu, 25 Feb 2016 17:38:17 -0600
Subject: [PATCH v2] dts: add specific compatible type for Terasic
 DE0-NANO-SoC Board
In-Reply-To: <1595377.ZIYnBnVf5Q@virgo>
References: <8416439.76b9YNhpgR@dabox> <20160225103820.GB747@pengutronix.de>
 <56CF323C.90202@opensource.altera.com> <1595377.ZIYnBnVf5Q@virgo>
Message-ID: <56CF9069.4060505@opensource.altera.com>

On 02/25/2016 05:34 PM, Tim Sander wrote:

> As far as i remember there are different de0 and different sockit boards, so 
> the name does not seem to be as concise? I don't care but i would say that
> de0-nano-soc is the most concise and easier to search for than atlas which
> might turn up more false postives?
> 

I'm fine with "terasic,de0-nano-soc".

Dinh



From k.kozlowski at samsung.com  Thu Feb 25 15:46:55 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 26 Feb 2016 08:46:55 +0900
Subject: [PATCH] ARM: s3c24xx: avoid warning for inb/outb
In-Reply-To: <1456437900-853667-1-git-send-email-arnd@arndb.de>
References: <1456437900-853667-1-git-send-email-arnd@arndb.de>
Message-ID: <56CF926F.5040507@samsung.com>

On 26.02.2016 07:04, Arnd Bergmann wrote:
> s3c24xx implements its own inb/outb macros, but the implementation
> prints warnings when the port number argument is not a 32-bit scalar:
> 
> drivers/scsi/pas16.c: In function 'NCR5380_pwrite':
> arch/arm/mach-s3c24xx/include/mach/io.h:193:68: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>  #define __ioaddrc(port) ((__PORT_PCIO(port) ? PCIO_BASE + (port) : (void __iomem *)(port)))
> 
> This slightly modifies the definition of the __ioaddrc macro to avoid
> the warning.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>  arch/arm/mach-s3c24xx/include/mach/io.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Thanks, applied.

Krzysztof



From andy.gross at linaro.org  Thu Feb 25 15:48:49 2016
From: andy.gross at linaro.org (Andy Gross)
Date: Thu, 25 Feb 2016 17:48:49 -0600
Subject: [PATCH v3 6/8] arm64: dts: qcom: fix usb digital voltage levels
In-Reply-To: <CAPBZ5QfD4q4hDg2Vfj8E_2Hjoa80feFN4cM+LkhdGgHLDkKx_g@mail.gmail.com>
References: <1456246153-18087-1-git-send-email-srinivas.kandagatla@linaro.org>
 <1456246236-18341-1-git-send-email-srinivas.kandagatla@linaro.org>
 <56CE3780.5060408@codeaurora.org> <56CEE3D4.3030407@linaro.org>
 <CAPBZ5QfD4q4hDg2Vfj8E_2Hjoa80feFN4cM+LkhdGgHLDkKx_g@mail.gmail.com>
Message-ID: <CAPBZ5QeJGV5iqx5wwGP3mwr292-rkqmORnTe8qtHSX2DzVc97Q@mail.gmail.com>

I think the vdd-levels were an oversight.  The voltages definitely
need to be correct.  As for the corner regulators, I believe the CPR
driver was supposed to address this.  The USB requests a specific
voltage and frequency and based on this the CPR would set the corner
for the regulator.

Stephen, correct me if i am wrong.

On 25 February 2016 at 17:44, Andy Gross <andy.gross at linaro.org> wrote:
> I think the vdd-levels were an oversight.  The voltages definitely need to
> be correct.  As for the corner regulators, I believe the CPR driver was
> supposed to address this.  The USB requests a specific voltage and frequency
> and based on this the CPR would set the corner for the regulator.
>
> Stephen, correct me if i am wrong.
>
> On 25 February 2016 at 05:21, Srinivas Kandagatla
> <srinivas.kandagatla at linaro.org> wrote:
>>
>>
>>
>> On 24/02/16 23:06, Stephen Boyd wrote:
>>>
>>> On 02/23/2016 08:50 AM, Srinivas Kandagatla wrote:
>>>>
>>>> This patch updates the digital voltage levels from corner values to
>>>> microvolts as we are going to use s1 regulator directly for vddcx
>>>> instead of s1_corner.
>>>>
>>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla at linaro.org>
>>>> ---
>>>
>>>
>>> What's the plan for corners? Maybe we should remove the voltage setting
>>> from the usb driver or drop the usb node entirely on msm8916 until we
>>> resolve how we're going to handle corners. I'd like to avoid getting
>>> stuck into some DT binding ABI mess here.
>>
>>
>> Andy/Bjorn, any comments on plans on corner regulators?
>>
>> Please note, that this is a patch to fix what is already in the mainline.
>> Without this patch the regulator would be configured with 1uV or 5uV or 7uV
>> which would obviously fail.
>>
>> THB, it does not make sense to drop feature which is functional, and I
>> also agree that we should cleanup some of this mess at some point in time
>> once we all the bits and pieces ready.
>>
>> I was surprised to see these usb bindings(qcom,vdd-levels) existed even
>> before we had concept of corner regulators in mainline kernel. Which also
>> suggests that this driver needs a proper relook once again.
>>
>> Thanks,
>> srini
>
>


From horms+renesas at verge.net.au  Thu Feb 25 15:51:45 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:51:45 +0900
Subject: [GIT PULL] Renesas ARM64 Based SoC Defconfig Updates for v4.6
Message-ID: <cover.1456442918.git.horms+renesas@verge.net.au>

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM64 based SoC defconfig updates for v4.6.

This pull request is based on the previous round of
such requests, tagged as v4.5-rc2,
which I have already sent a pull-request for.

I based this pull request on v4.5-rc2 instead of rc1 to avoid
a minor conflict. However I believe this may have been in vein
as there appears to be a separate minor conflict present in linux-next.

That conflict is with:

efdda175c07f ("arm64: defconfig: add spmi and usb related configs")

The solution is to take both.


The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3:

  Linux 4.5-rc2 (2016-01-31 18:12:16 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-defconfig-for-v4.6

for you to fetch changes up to a9c42f02387ce8a231bce7c0901ef15fe4bfc3b4:

  arm64: defconfig: Add Renesas R-Car Gen3 USB 2.0 phy driver support (2016-02-24 09:44:34 +0900)

----------------------------------------------------------------
Renesas ARM64 Based SoC Defconfig Updates for v4.6

* Enable Renesas R-Car Gen3 USB 2.0 phy driver
  which is used on the r8a7795/salvator-x

----------------------------------------------------------------
Yoshihiro Shimoda (1):
      arm64: defconfig: Add Renesas R-Car Gen3 USB 2.0 phy driver support

 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)


From horms+renesas at verge.net.au  Thu Feb 25 15:51:57 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:51:57 +0900
Subject: [PATCH] arm64: defconfig: Add Renesas R-Car Gen3 USB 2.0 phy driver
 support
In-Reply-To: <cover.1456442918.git.horms+renesas@verge.net.au>
References: <cover.1456442918.git.horms+renesas@verge.net.au>
Message-ID: <a9c42f02387ce8a231bce7c0901ef15fe4bfc3b4.1456442918.git.horms+renesas@verge.net.au>

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 86581f793e39..eaf738a59927 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -213,6 +213,7 @@ CONFIG_QCOM_SMD_RPM=y
 CONFIG_ARCH_TEGRA_132_SOC=y
 CONFIG_ARCH_TEGRA_210_SOC=y
 CONFIG_HISILICON_IRQ_MBIGEN=y
+CONFIG_PHY_RCAR_GEN3_USB2=y
 CONFIG_PHY_XGENE=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:52:55 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:52:55 +0900
Subject: [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.6
Message-ID: <cover.1456442718.git.horms+renesas@verge.net.au>

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM64 based SoC SoC updates for v4.6.


The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-soc-for-v4.6

for you to fetch changes up to 2ee98234b88174f2bcafefb7918e2794a1fdbc98:

  arm64: renesas: Enable PM and PM_GENERIC_DOMAINS for SoCs with PM Domains (2016-02-19 14:55:18 +0900)

----------------------------------------------------------------
Renesas ARM64 Based SoC SoC Updates for v4.6

* Enable RENESAS_IRQC, and PM and PM_GENERIC_DOMAINS for SoCs with PM Domains

----------------------------------------------------------------
Geert Uytterhoeven (1):
      arm64: renesas: Enable PM and PM_GENERIC_DOMAINS for SoCs with PM Domains

Magnus Damm (1):
      arm64: renesas: Enable RENESAS_IRQC

 arch/arm64/Kconfig.platforms | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


From horms+renesas at verge.net.au  Thu Feb 25 15:52:55 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:52:55 +0900
Subject: [PATCH 1/2] arm64: renesas: Enable RENESAS_IRQC
In-Reply-To: <cover.1456442718.git.horms+renesas@verge.net.au>
References: <cover.1456442718.git.horms+renesas@verge.net.au>
Message-ID: <f7e020512e10a185d58d0f11faa57093345fd5b2.1456442718.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm+renesas at opensource.se>

Select RENESAS_IRQC for Arm64 SoCs from Renesas to enable
build of drivers/irqchip/irq-renesas-irqc.c.

Signed-off-by: Magnus Damm <damm+renesas at opensource.se>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/Kconfig.platforms | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 21074f674bde..757220cb1b7f 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -77,6 +77,7 @@ config ARCH_RENESAS
 	select ARCH_SHMOBILE
 	select PINCTRL
 	select PM_GENERIC_DOMAINS if PM
+	select RENESAS_IRQC
 	help
 	  This enables support for the ARMv8 based Renesas SoCs.
 
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:52:56 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:52:56 +0900
Subject: [PATCH 2/2] arm64: renesas: Enable PM and PM_GENERIC_DOMAINS for SoCs
 with PM Domains
In-Reply-To: <cover.1456442718.git.horms+renesas@verge.net.au>
References: <cover.1456442718.git.horms+renesas@verge.net.au>
Message-ID: <2ee98234b88174f2bcafefb7918e2794a1fdbc98.1456442718.git.horms+renesas@verge.net.au>

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

All supported Renesas ARM64 SoCs have clock and power domains. To ensure
proper operation of on-SoC modules, module clocks must be ungated, and
power domains must be powered up when needed.

Currently the user can choose to build a kernel with power management
enabled or disabled:
  - If CONFIG_PM=y, power domains and/or module clocks are handled
    dynamically by Runtime PM and the generic power domain.
  - If CONFIG_PM=n, power domains are assumed to be powered up by reset
    state or by the boot loader, and module clocks are handled by the
    legacy clock domain on driver (un)bind.
    The latter is implemented using a platform bus notifier, which
    applies not only to all on-SoC devices, but to all platform devices
    present in the system.

To remove the dependency on implicit assumptions, and to get rid of the
peculiarities of the legacy clock domain, enable CONFIG_PM and
CONFIG_PM_GENERIC_DOMAINS unconditionally.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/Kconfig.platforms | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 757220cb1b7f..e011ac0e17a3 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -76,7 +76,8 @@ config ARCH_RENESAS
 	bool "Renesas SoC Platforms"
 	select ARCH_SHMOBILE
 	select PINCTRL
-	select PM_GENERIC_DOMAINS if PM
+	select PM
+	select PM_GENERIC_DOMAINS
 	select RENESAS_IRQC
 	help
 	  This enables support for the ARMv8 based Renesas SoCs.
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:53:07 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:53:07 +0900
Subject: [GIT PULL] Second Round of Renesas ARM Based SoC DT Updates for v4.6
Message-ID: <cover.1456443769.git.horms+renesas@verge.net.au>

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these second round of Renesas ARM based SoC DT updates
for v4.6.

This pull request is based on the previous round of
such requests, tagged as renesas-dt-for-v4.6,
which you have already pulled.


The following changes since commit c3373b09ba0391bcd9e992b0a2ce52d48d33e47b:

  ARM: dts: silk: Enable SCIF_CLK frequency and pins (2016-02-09 19:43:28 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-dt2-for-v4.6

for you to fetch changes up to d92df7e59909940b2b65523981aa0ddb4327047a:

  ARM: dts: r8a7790: use fallback etheravb compatibility string (2016-02-25 13:12:37 +0900)

----------------------------------------------------------------
Second Round of Renesas ARM Based SoC DT Updates for v4.6

* Add L2 cache-controller nodes to r8a779[0134] and r8a73a4
* Add etheravb support to r8a7794
* Correct JP3 jumper description on Porter
* Enable thermal zone on  r8a779[013]
* Replace gpio-key, wakeup with wakeup-source property on r8a7794
* Use demuxer for IIC0/I2C0 on lager
* Use fallback etheravb, pci and pcie compatibility strings as appropriate

----------------------------------------------------------------
Geert Uytterhoeven (5):
      ARM: dts: r8a73a4: Add L2 cache-controller nodes
      ARM: dts: r8a7790: Add L2 cache-controller nodes
      ARM: dts: r8a7791: Add L2 cache-controller node
      ARM: dts: r8a7793: Add L2 cache-controller node
      ARM: dts: r8a7794: Add L2 cache-controller node

Kuninori Morimoto (3):
      ARM: dts: r8a7790: enable to use thermal-zone
      ARM: dts: r8a7791: enable to use thermal-zone
      ARM: dts: r8a7793: enable to use thermal-zone

Sergei Shtylyov (3):
      ARM: dts: porter: fix JP3 jumper description
      ARM: dts: r8a7794: add EtherAVB clock
      ARM: dts: r8a7794: add EtherAVB support

Simon Horman (7):
      ARM: dts: r8a7790: use fallback pcie compatibility string
      ARM: dts: r8a7791: use fallback pcie compatibility string
      ARM: dts: r8a7790: use fallback pci compatibility string
      ARM: dts: r8a7791: use fallback pci compatibility string
      ARM: dts: r8a7794: use fallback pci compatibility string
      ARM: dts: r8a7794: replace gpio-key, wakeup with wakeup-source property
      ARM: dts: r8a7790: use fallback etheravb compatibility string

Wolfram Sang (1):
      ARM: dts: r8a7790: lager: use demuxer for IIC0/I2C0

 arch/arm/boot/dts/r8a73a4.dtsi            | 17 +++++++++
 arch/arm/boot/dts/r8a7790-lager.dts       | 32 +++++++++++++++--
 arch/arm/boot/dts/r8a7790.dtsi            | 57 +++++++++++++++++++++++++++----
 arch/arm/boot/dts/r8a7791-porter.dts      |  4 +--
 arch/arm/boot/dts/r8a7791.dtsi            | 40 +++++++++++++++++++---
 arch/arm/boot/dts/r8a7793-gose.dts        | 22 ++++++------
 arch/arm/boot/dts/r8a7793.dtsi            | 33 ++++++++++++++++--
 arch/arm/boot/dts/r8a7794.dtsi            | 31 ++++++++++++++---
 include/dt-bindings/clock/r8a7794-clock.h |  1 +
 9 files changed, 203 insertions(+), 34 deletions(-)


From horms+renesas at verge.net.au  Thu Feb 25 15:52:52 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:52:52 +0900
Subject: [PATCH 03/19] ARM: dts: r8a7790: use fallback pci compatibility string
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <2d82c14460575bdf7ea78146d988c10db94d8343.1456443769.git.horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7790 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index db019f2619c7..76ddf5c6cca7 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1499,7 +1499,7 @@
 	};
 
 	pci0: pci at ee090000 {
-		compatible = "renesas,pci-r8a7790";
+		compatible = "renesas,pci-r8a7790", "renesas,pci-rcar-gen2";
 		device_type = "pci";
 		reg = <0 0xee090000 0 0xc00>,
 		      <0 0xee080000 0 0x1100>;
@@ -1534,7 +1534,7 @@
 	};
 
 	pci1: pci at ee0b0000 {
-		compatible = "renesas,pci-r8a7790";
+		compatible = "renesas,pci-r8a7790", "renesas,pci-rcar-gen2";
 		device_type = "pci";
 		reg = <0 0xee0b0000 0 0xc00>,
 		      <0 0xee0a0000 0 0x1100>;
@@ -1555,7 +1555,7 @@
 	};
 
 	pci2: pci at ee0d0000 {
-		compatible = "renesas,pci-r8a7790";
+		compatible = "renesas,pci-r8a7790", "renesas,pci-rcar-gen2";
 		device_type = "pci";
 		clocks = <&mstp7_clks R8A7790_CLK_EHCI>;
 		power-domains = <&cpg_clocks>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:53:01 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:53:01 +0900
Subject: [PATCH 12/19] ARM: dts: r8a7791: Add L2 cache-controller node
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <8ffe93a5b2cb55d4da9c285d9277699bdb828b47.1456443769.git.horms+renesas@verge.net.au>

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

Add a device node for the L2 cache, and link the CPU nodes to it.

The L2 cache for the Cortex-A15 CPU cores is 1 MiB large (organized as
64 KiB x 16 ways).

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index f1732dde114b..6439f0569fe2 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -51,6 +51,7 @@
 			voltage-tolerance = <1>; /* 1% */
 			clocks = <&cpg_clocks R8A7791_CLK_Z>;
 			clock-latency = <300000>; /* 300 us */
+			next-level-cache = <&L2_CA15>;
 
 			/* kHz - uV - OPPs unknown yet */
 			operating-points = <1500000 1000000>,
@@ -66,6 +67,7 @@
 			compatible = "arm,cortex-a15";
 			reg = <1>;
 			clock-frequency = <1500000000>;
+			next-level-cache = <&L2_CA15>;
 		};
 	};
 
@@ -88,6 +90,12 @@
 		};
 	};
 
+	L2_CA15: cache-controller at 0 {
+		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
+	};
+
 	gic: interrupt-controller at f1001000 {
 		compatible = "arm,gic-400";
 		#interrupt-cells = <3>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:52:53 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:52:53 +0900
Subject: [PATCH 04/19] ARM: dts: r8a7791: use fallback pci compatibility string
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <d4809689e6cb5961d9673cdb2c0b54f0f9141f18.1456443769.git.horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7791 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 4456f54a5005..8910236e64bf 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1530,7 +1530,7 @@
 	};
 
 	pci0: pci at ee090000 {
-		compatible = "renesas,pci-r8a7791";
+		compatible = "renesas,pci-r8a7791", "renesas,pci-rcar-gen2";
 		device_type = "pci";
 		reg = <0 0xee090000 0 0xc00>,
 		      <0 0xee080000 0 0x1100>;
@@ -1565,7 +1565,7 @@
 	};
 
 	pci1: pci at ee0d0000 {
-		compatible = "renesas,pci-r8a7791";
+		compatible = "renesas,pci-r8a7791", "renesas,pci-rcar-gen2";
 		device_type = "pci";
 		reg = <0 0xee0d0000 0 0xc00>,
 		      <0 0xee0c0000 0 0x1100>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:53:03 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:53:03 +0900
Subject: [PATCH 14/19] ARM: dts: r8a7794: Add L2 cache-controller node
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <d12a384a1b264efd66a50cd5cb311c0d56aff681.1456443769.git.horms+renesas@verge.net.au>

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

Add a device node for the L2 cache, and link the CPU nodes to it.

The L2 cache for the Cortex-A7 CPU cores is 512 KiB large (organized as
64 KiB x 8 ways).

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index df0861e84a4b..21a02df3609b 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -40,6 +40,7 @@
 			compatible = "arm,cortex-a7";
 			reg = <0>;
 			clock-frequency = <1000000000>;
+			next-level-cache = <&L2_CA7>;
 		};
 
 		cpu1: cpu at 1 {
@@ -47,9 +48,16 @@
 			compatible = "arm,cortex-a7";
 			reg = <1>;
 			clock-frequency = <1000000000>;
+			next-level-cache = <&L2_CA7>;
 		};
 	};
 
+	L2_CA7: cache-controller at 1 {
+		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
+	};
+
 	gic: interrupt-controller at f1001000 {
 		compatible = "arm,gic-400";
 		#interrupt-cells = <3>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:53:02 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:53:02 +0900
Subject: [PATCH 13/19] ARM: dts: r8a7793: Add L2 cache-controller node
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <fdd0dbd8a28612195dfbfb08c404ef5bcfa48e43.1456443769.git.horms+renesas@verge.net.au>

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

Add a device node for the L2 cache, and link the CPU node to it.

The L2 cache for the Cortex-A15 CPU cores is 1 MiB large (organized as
64 KiB x 16 ways).

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 9837f90f1718..b48215945241 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -51,6 +51,7 @@
 					   < 937500 1000000>,
 					   < 750000 1000000>,
 					   < 375000 1000000>;
+			next-level-cache = <&L2_CA15>;
 		};
 	};
 
@@ -73,6 +74,12 @@
 		};
 	};
 
+	L2_CA15: cache-controller at 0 {
+		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
+	};
+
 	gic: interrupt-controller at f1001000 {
 		compatible = "arm,gic-400";
 		#interrupt-cells = <3>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:53:05 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:53:05 +0900
Subject: [PATCH 16/19] ARM: dts: r8a7794: add EtherAVB clock
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <255a40424e2618610a2ad8d39e12b843b723959a.1456443769.git.horms+renesas@verge.net.au>

From: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

Add the EtherAVB clock to the R8A7794 device tree.

Based on the commit eaa870b30553 ("ARM: shmobile: r8a7791: add EtherAVB
clock").

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794.dtsi            | 7 ++++---
 include/dt-bindings/clock/r8a7794-clock.h | 1 +
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 21a02df3609b..042440b6dc8c 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -1112,13 +1112,14 @@
 		mstp8_clks: mstp8_clks at e6150990 {
 			compatible = "renesas,r8a7794-mstp-clocks", "renesas,cpg-mstp-clocks";
 			reg = <0 0xe6150990 0 4>, <0 0xe61509a0 0 4>;
-			clocks = <&zg_clk>, <&zg_clk>, <&p_clk>;
+			clocks = <&zg_clk>, <&zg_clk>, <&hp_clk>, <&p_clk>;
 			#clock-cells = <1>;
 			clock-indices = <
-				R8A7794_CLK_VIN1 R8A7794_CLK_VIN0 R8A7794_CLK_ETHER
+				R8A7794_CLK_VIN1 R8A7794_CLK_VIN0
+				R8A7794_CLK_ETHERAVB R8A7794_CLK_ETHER
 			>;
 			clock-output-names =
-				"vin1", "vin0", "ether";
+				"vin1", "vin0", "etheravb", "ether";
 		};
 		mstp9_clks: mstp9_clks at e6150994 {
 			compatible = "renesas,r8a7794-mstp-clocks", "renesas,cpg-mstp-clocks";
diff --git a/include/dt-bindings/clock/r8a7794-clock.h b/include/dt-bindings/clock/r8a7794-clock.h
index a7a7e0370968..f843de6bf377 100644
--- a/include/dt-bindings/clock/r8a7794-clock.h
+++ b/include/dt-bindings/clock/r8a7794-clock.h
@@ -84,6 +84,7 @@
 /* MSTP8 */
 #define R8A7794_CLK_VIN1		10
 #define R8A7794_CLK_VIN0		11
+#define R8A7794_CLK_ETHERAVB		12
 #define R8A7794_CLK_ETHER		13
 
 /* MSTP9 */
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:53:04 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:53:04 +0900
Subject: [PATCH 15/19] ARM: dts: r8a7794: replace gpio-key,
 wakeup with wakeup-source property
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <c816617e8b09c13b1b5a66de8a32db8e5e61dff1.1456443769.git.horms+renesas@verge.net.au>

Though the keyboard driver for GPIO buttons(gpio-keys) will continue to
check for/support the legacy "gpio-key,wakeup" boolean property to
enable gpio buttons as wakeup source, "wakeup-source" is the new
standard binding.

This patch replaces the legacy "gpio-key,wakeup" with the unified
"wakeup-source" property in order to avoid any further copy-paste
duplication.

Changelog text from a similar patch by Sudeep Holla.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Acked-by: Sudeep Holla <sudeep.holla at arm.com>
---
 arch/arm/boot/dts/r8a7793-gose.dts | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
index cfe142c2ba38..87e89ec9dd47 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -67,77 +67,77 @@
 		        gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_1>;
 		        label = "SW2-1";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-2 {
 		        gpios = <&gpio5 1 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_2>;
 		        label = "SW2-2";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-3 {
 		        gpios = <&gpio5 2 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_3>;
 		        label = "SW2-3";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-4 {
 		        gpios = <&gpio5 3 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_4>;
 		        label = "SW2-4";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-a {
 		        gpios = <&gpio7 0 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_A>;
 		        label = "SW30";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-b {
 		        gpios = <&gpio7 1 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_B>;
 		        label = "SW31";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-c {
 		        gpios = <&gpio7 2 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_C>;
 		        label = "SW32";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-d {
 		        gpios = <&gpio7 3 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_D>;
 		        label = "SW33";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-e {
 		        gpios = <&gpio7 4 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_E>;
 		        label = "SW34";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-f {
 		        gpios = <&gpio7 5 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_F>;
 		        label = "SW35";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 		key-g {
 		        gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
 		        linux,code = <KEY_G>;
 		        label = "SW36";
-		        gpio-key,wakeup;
+		        wakeup-source;
 		        debounce-interval = <20>;
 		};
 	};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:53:07 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:53:07 +0900
Subject: [PATCH 18/19] ARM: dts: r8a7790: lager: use demuxer for IIC0/I2C0
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <880cb5702471c4eb56b1af1c26e5273e48f50a32.1456443769.git.horms+renesas@verge.net.au>

From: Wolfram Sang <wsa+renesas at sang-engineering.com>

Make it possible to select which I2C IP core you want to run on the
EXIO-A connector. This is the reference how to use this feature. Update
the copyright while we are here.

Signed-off-by: Wolfram Sang <wsa+renesas at sang-engineering.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790-lager.dts | 32 ++++++++++++++++++++++++++++++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
index cdc0414f5f07..aa6ca92a9485 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -3,6 +3,7 @@
  *
  * Copyright (C) 2013-2014 Renesas Solutions Corp.
  * Copyright (C) 2014 Cogent Embedded, Inc.
+ * Copyright (C) 2015-2016 Renesas Electronics Corporation
  *
  * This file is licensed under the terms of the GNU General Public License
  * version 2.  This program is licensed "as is" without any warranty of any
@@ -49,6 +50,7 @@
 	aliases {
 		serial0 = &scif0;
 		serial1 = &scifa1;
+		i2c8 = "i2cexio";
 	};
 
 	chosen {
@@ -252,6 +254,23 @@
 		#clock-cells = <0>;
 		clock-frequency = <148500000>;
 	};
+
+	/*
+	 * IIC0/I2C0 is routed to EXIO connector A, pins 114 (SCL) + 116 (SDA) only.
+	 * We use the I2C demuxer, so the desired IP core can be selected at runtime
+	 * depending on the use case (e.g. DMA with IIC0 or slave support with I2C0).
+	 * Note: For testing the I2C slave feature, it is convenient to connect this
+	 * bus with IIC3 on pins 110 (SCL) + 112 (SDA), select I2C0 at runtime, and
+	 * instantiate the slave device at runtime according to the documentation.
+	 * You can then communicate with the slave via IIC3.
+	 */
+	i2cexio: i2c at 8 {
+		compatible = "i2c-demux-pinctrl";
+		i2c-parent = <&iic0>, <&i2c0>;
+		i2c-bus-name = "i2c-exio";
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
 };
 
 &du {
@@ -350,6 +369,11 @@
 		renesas,function = "msiof1";
 	};
 
+	i2c0_pins: i2c0 {
+		renesas,groups = "i2c0";
+		renesas,function = "i2c0";
+	};
+
 	iic0_pins: iic0 {
 		renesas,groups = "iic0";
 		renesas,function = "iic0";
@@ -537,10 +561,14 @@
 	cpu0-supply = <&vdd_dvfs>;
 };
 
+&i2c0	{
+	pinctrl-0 = <&i2c0_pins>;
+	pinctrl-names = "i2c-exio";
+};
+
 &iic0	{
-	status = "okay";
 	pinctrl-0 = <&iic0_pins>;
-	pinctrl-names = "default";
+	pinctrl-names = "i2c-exio";
 };
 
 &iic1	{
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:53:06 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:53:06 +0900
Subject: [PATCH 17/19] ARM: dts: r8a7794: add EtherAVB support
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <89aac8af1a607355710c7c954efec85a9302bc95.1456443769.git.horms+renesas@verge.net.au>

From: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

Define the generic R8A7794 part of the EtherAVB device node.

Based on the commit 46ece349aa54 ("ARM: shmobile: r8a7791: add EtherAVB DT
support").

Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 042440b6dc8c..eacb2b291361 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -544,6 +544,18 @@
 		status = "disabled";
 	};
 
+	avb: ethernet at e6800000 {
+		compatible = "renesas,etheravb-r8a7794",
+			     "renesas,etheravb-rcar-gen2";
+		reg = <0 0xe6800000 0 0x800>, <0 0xee0e8000 0 0x4000>;
+		interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp8_clks R8A7794_CLK_ETHERAVB>;
+		power-domains = <&cpg_clocks>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
 	/* The memory map in the User's Manual maps the cores to bus numbers */
 	i2c0: i2c at e6508000 {
 		compatible = "renesas,i2c-r8a7794";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:53:08 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:53:08 +0900
Subject: [PATCH 19/19] ARM: dts: r8a7790: use fallback etheravb compatibility
 string
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <d92df7e59909940b2b65523981aa0ddb4327047a.1456443769.git.horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7790 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm/boot/dts/r8a7790.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index ba4c2530d79f..38b706399a6b 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -773,7 +773,8 @@
 	};
 
 	avb: ethernet at e6800000 {
-		compatible = "renesas,etheravb-r8a7790";
+		compatible = "renesas,etheravb-r8a7790",
+			     "renesas,etheravb-rcar-gen2";
 		reg = <0 0xe6800000 0 0x800>, <0 0xee0e8000 0 0x4000>;
 		interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp8_clks R8A7790_CLK_ETHERAVB>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:52:54 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:52:54 +0900
Subject: [PATCH 05/19] ARM: dts: r8a7794: use fallback pci compatibility string
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <c99fbe6437cfe485d96c486b5aa4022c03ad8224.1456443769.git.horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7794 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7794.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 7d4c5597af5b..df0861e84a4b 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -681,7 +681,7 @@
 	};
 
 	pci0: pci at ee090000 {
-		compatible = "renesas,pci-r8a7794";
+		compatible = "renesas,pci-r8a7794", "renesas,pci-rcar-gen2";
 		device_type = "pci";
 		reg = <0 0xee090000 0 0xc00>,
 		      <0 0xee080000 0 0x1100>;
@@ -716,7 +716,7 @@
 	};
 
 	pci1: pci at ee0d0000 {
-		compatible = "renesas,pci-r8a7794";
+		compatible = "renesas,pci-r8a7794", "renesas,pci-rcar-gen2";
 		device_type = "pci";
 		reg = <0 0xee0d0000 0 0xc00>,
 		      <0 0xee0c0000 0 0x1100>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:52:55 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:52:55 +0900
Subject: [PATCH 06/19] ARM: dts: porter: fix JP3 jumper description
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <f3b063c8f443049fb484086d6a956a5270f137a0.1456443769.git.horms+renesas@verge.net.au>

From: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>

When finishing the Porter sound support patch, I managed to call the JP3
jumper SW3 in the comment.  Fix this  along with (also miscalled) jumper
positions...

Fixes: 493b4da7c10c ("ARM: dts: porter: add sound support")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov at cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791-porter.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
index ed1f6f884e2b..bf3a0d13cd35 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -11,8 +11,8 @@
 /*
  * SSI-AK4642
  *
- * SW3: 1: AK4642
- *      3: ADV7511
+ * JP3: 2-1: AK4642
+ *      2-3: ADV7511
  *
  * This command is required before playback/capture:
  *
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:52:57 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:52:57 +0900
Subject: [PATCH 08/19] ARM: dts: r8a7791: enable to use thermal-zone
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <cac68a56e34b9810e28dfd2e8645f278671d37ce.1456443769.git.horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

This patch enables to use thermal-zone on r8a7791.
This thermal sensor can measure temperature from -40000 to 125000,
but over 117000 can be critical on this chip.
Thus, default critical temperature is now set as 115000 (this driver
is using 5000 steps) (Current critical temperature is using it as
90000, but there is no big reason about it)

And it doesn't check thermal zone periodically (same as current
behavior). You can exchange it by modifying polling-delay[-passive]
property.

You can set trip temp if your kernel has CONFIG_THERMAL_WRITABLE_TRIPS,
but you need to take care to use it, since it will call
orderly_poweroff() it it reaches to the value.
echo $temp > /sys/class/thermal/thermal_zone0/trip_point_0_temp

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791.dtsi | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 8910236e64bf..f1732dde114b 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -69,6 +69,25 @@
 		};
 	};
 
+	thermal-zones {
+		cpu_thermal: cpu-thermal {
+			polling-delay-passive	= <0>;
+			polling-delay		= <0>;
+
+			thermal-sensors = <&thermal>;
+
+			trips {
+				cpu-crit {
+					temperature	= <115000>;
+					hysteresis	= <0>;
+					type		= "critical";
+				};
+			};
+			cooling-maps {
+			};
+		};
+	};
+
 	gic: interrupt-controller at f1001000 {
 		compatible = "arm,gic-400";
 		#interrupt-cells = <3>;
@@ -185,12 +204,15 @@
 		power-domains = <&cpg_clocks>;
 	};
 
-	thermal at e61f0000 {
-		compatible = "renesas,thermal-r8a7791", "renesas,rcar-thermal";
+	thermal: thermal at e61f0000 {
+		compatible =	"renesas,thermal-r8a7791",
+				"renesas,rcar-gen2-thermal",
+				"renesas,rcar-thermal";
 		reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
 		interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks R8A7791_CLK_THERMAL>;
 		power-domains = <&cpg_clocks>;
+		#thermal-sensor-cells = <0>;
 	};
 
 	timer {
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:52:56 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:52:56 +0900
Subject: [PATCH 07/19] ARM: dts: r8a7790: enable to use thermal-zone
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <a8b805f3606f7af7f2b44763d3d6cf05f7c15afd.1456443769.git.horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

This patch enables to use thermal-zone on r8a7790.
This thermal sensor can measure temperature from -40000 to 125000,
but over 117000 can be critical on this chip.
Thus, default critical temperature is now set as 115000 (this driver
is using 5000 steps) (Current critical temperature is using it as
90000, but there is no big reason about it)

And it doesn't check thermal zone periodically (same as current
behavior). You can exchange it by modifying polling-delay[-passive]
property.

You can set trip temp if your kernel has CONFIG_THERMAL_WRITABLE_TRIPS,
but you need to take care to use it, since it will call
orderly_poweroff() it it reaches to the value.
echo $temp > /sys/class/thermal/thermal_zone0/trip_point_0_temp

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 76ddf5c6cca7..24b773ae133a 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -112,6 +112,25 @@
 		};
 	};
 
+	thermal-zones {
+		cpu_thermal: cpu-thermal {
+			polling-delay-passive	= <0>;
+			polling-delay		= <0>;
+
+			thermal-sensors = <&thermal>;
+
+			trips {
+				cpu-crit {
+					temperature	= <115000>;
+					hysteresis	= <0>;
+					type		= "critical";
+				};
+			};
+			cooling-maps {
+			};
+		};
+	};
+
 	gic: interrupt-controller at f1001000 {
 		compatible = "arm,gic-400";
 		#interrupt-cells = <3>;
@@ -202,12 +221,15 @@
 		power-domains = <&cpg_clocks>;
 	};
 
-	thermal at e61f0000 {
-		compatible = "renesas,thermal-r8a7790", "renesas,rcar-thermal";
+	thermal: thermal at e61f0000 {
+		compatible =	"renesas,thermal-r8a7790",
+				"renesas,rcar-gen2-thermal",
+				"renesas,rcar-thermal";
 		reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
 		interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks R8A7790_CLK_THERMAL>;
 		power-domains = <&cpg_clocks>;
+		#thermal-sensor-cells = <0>;
 	};
 
 	timer {
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:52:58 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:52:58 +0900
Subject: [PATCH 09/19] ARM: dts: r8a7793: enable to use thermal-zone
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <57f9156bc620ac561ed46b2316de328e6b280023.1456443769.git.horms+renesas@verge.net.au>

From: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>

This patch enables to use thermal-zone on r8a7793.
This thermal sensor can measure temperature from -40000 to 125000,
but over 117000 can be critical on this chip.
Thus, default critical temperature is now set as 115000 (this driver
is using 5000 steps) (Current critical temperature is using it as
90000, but there is no big reason about it)

And it doesn't check thermal zone periodically (same as current
behavior). You can exchange it by modifying polling-delay[-passive]
property.

You can set trip temp if your kernel has CONFIG_THERMAL_WRITABLE_TRIPS,
but you need to take care to use it, since it will call
orderly_poweroff() it it reaches to the value.
echo $temp > /sys/class/thermal/thermal_zone0/trip_point_0_temp

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7793.dtsi | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 45dba1c79a43..9837f90f1718 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -54,6 +54,25 @@
 		};
 	};
 
+	thermal-zones {
+		cpu_thermal: cpu-thermal {
+			polling-delay-passive	= <0>;
+			polling-delay		= <0>;
+
+			thermal-sensors = <&thermal>;
+
+			trips {
+				cpu-crit {
+					temperature	= <115000>;
+					hysteresis	= <0>;
+					type		= "critical";
+				};
+			};
+			cooling-maps {
+			};
+		};
+	};
+
 	gic: interrupt-controller at f1001000 {
 		compatible = "arm,gic-400";
 		#interrupt-cells = <3>;
@@ -170,12 +189,15 @@
 		power-domains = <&cpg_clocks>;
 	};
 
-	thermal at e61f0000 {
-		compatible = "renesas,thermal-r8a7793", "renesas,rcar-thermal";
+	thermal: thermal at e61f0000 {
+		compatible =	"renesas,thermal-r8a7793",
+				"renesas,rcar-gen2-thermal",
+				"renesas,rcar-thermal";
 		reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
 		interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&mstp5_clks R8A7793_CLK_THERMAL>;
 		power-domains = <&cpg_clocks>;
+		#thermal-sensor-cells = <0>;
 	};
 
 	timer {
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:53:00 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:53:00 +0900
Subject: [PATCH 11/19] ARM: dts: r8a7790: Add L2 cache-controller nodes
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <fb1cecd40690e61e122d7249e7499c8d799feffb.1456443769.git.horms+renesas@verge.net.au>

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

Add device nodes for the L2 caches, and link the CPU nodes to them.

The L2 cache for the Cortex-A15 CPU cores is 2 MiB large (organized as
128 KiB x 16 ways).

The L2 cache for the Cortex-A7 CPU cores is 512 KiB large (organized as
64 KiB x 8 ways).

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 24b773ae133a..ba4c2530d79f 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -52,6 +52,7 @@
 			voltage-tolerance = <1>; /* 1% */
 			clocks = <&cpg_clocks R8A7790_CLK_Z>;
 			clock-latency = <300000>; /* 300 us */
+			next-level-cache = <&L2_CA15>;
 
 			/* kHz - uV - OPPs unknown yet */
 			operating-points = <1400000 1000000>,
@@ -67,6 +68,7 @@
 			compatible = "arm,cortex-a15";
 			reg = <1>;
 			clock-frequency = <1300000000>;
+			next-level-cache = <&L2_CA15>;
 		};
 
 		cpu2: cpu at 2 {
@@ -74,6 +76,7 @@
 			compatible = "arm,cortex-a15";
 			reg = <2>;
 			clock-frequency = <1300000000>;
+			next-level-cache = <&L2_CA15>;
 		};
 
 		cpu3: cpu at 3 {
@@ -81,6 +84,7 @@
 			compatible = "arm,cortex-a15";
 			reg = <3>;
 			clock-frequency = <1300000000>;
+			next-level-cache = <&L2_CA15>;
 		};
 
 		cpu4: cpu at 4 {
@@ -88,6 +92,7 @@
 			compatible = "arm,cortex-a7";
 			reg = <0x100>;
 			clock-frequency = <780000000>;
+			next-level-cache = <&L2_CA7>;
 		};
 
 		cpu5: cpu at 5 {
@@ -95,6 +100,7 @@
 			compatible = "arm,cortex-a7";
 			reg = <0x101>;
 			clock-frequency = <780000000>;
+			next-level-cache = <&L2_CA7>;
 		};
 
 		cpu6: cpu at 6 {
@@ -102,6 +108,7 @@
 			compatible = "arm,cortex-a7";
 			reg = <0x102>;
 			clock-frequency = <780000000>;
+			next-level-cache = <&L2_CA7>;
 		};
 
 		cpu7: cpu at 7 {
@@ -109,6 +116,7 @@
 			compatible = "arm,cortex-a7";
 			reg = <0x103>;
 			clock-frequency = <780000000>;
+			next-level-cache = <&L2_CA7>;
 		};
 	};
 
@@ -131,6 +139,18 @@
 		};
 	};
 
+	L2_CA15: cache-controller at 0 {
+		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
+	};
+
+	L2_CA7: cache-controller at 1 {
+		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
+	};
+
 	gic: interrupt-controller at f1001000 {
 		compatible = "arm,gic-400";
 		#interrupt-cells = <3>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:52:59 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:52:59 +0900
Subject: [PATCH 10/19] ARM: dts: r8a73a4: Add L2 cache-controller nodes
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <c86a4b621994dbe9361185362c4be6887f04b1a4.1456443769.git.horms+renesas@verge.net.au>

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

Add device nodes for the L2 caches, and link the CPU node to its L2
cache node.

The L2 cache for the Cortex-A15 CPU cores is 1 MiB large (organized as
64 KiB x 16 ways), and located in PM domain A3SM.

The L2 cache for the Cortex-A7 CPU cores is 512 KiB large (organized as
64 KiB x 8 ways), and located in PM domain A3KM.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a73a4.dtsi | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 138414a7d170..6583a1dfca1f 100644
--- a/arch/arm/boot/dts/r8a73a4.dtsi
+++ b/arch/arm/boot/dts/r8a73a4.dtsi
@@ -29,6 +29,7 @@
 			reg = <0>;
 			clock-frequency = <1500000000>;
 			power-domains = <&pd_a2sl>;
+			next-level-cache = <&L2_CA15>;
 		};
 	};
 
@@ -45,6 +46,22 @@
 			     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
 	};
 
+	L2_CA15: cache-controller at 0 {
+		compatible = "cache";
+		clocks = <&cpg_clocks R8A73A4_CLK_Z>;
+		power-domains = <&pd_a3sm>;
+		cache-unified;
+		cache-level = <2>;
+	};
+
+	L2_CA7: cache-controller at 1 {
+		compatible = "cache";
+		clocks = <&cpg_clocks R8A73A4_CLK_Z2>;
+		power-domains = <&pd_a3km>;
+		cache-unified;
+		cache-level = <2>;
+	};
+
 	dbsc1: memory-controller at e6790000 {
 		compatible = "renesas,dbsc-r8a73a4";
 		reg = <0 0xe6790000 0 0x10000>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 15:52:51 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:52:51 +0900
Subject: [PATCH 02/19] ARM: dts: r8a7791: use fallback pcie compatibility
 string
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <bbb45f69f7ae68f422a6aafccdc48e3637669c39.1456443769.git.horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7791 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7791.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 14aa62539ff2..4456f54a5005 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -1600,7 +1600,7 @@
 	};
 
 	pciec: pcie at fe000000 {
-		compatible = "renesas,pcie-r8a7791";
+		compatible = "renesas,pcie-r8a7791", "renesas,pcie-rcar-gen2";
 		reg = <0 0xfe000000 0 0x80000>;
 		#address-cells = <3>;
 		#size-cells = <2>;
-- 
2.7.0.rc3.207.g0ac5344



From k.kozlowski at samsung.com  Thu Feb 25 16:05:03 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 26 Feb 2016 09:05:03 +0900
Subject: [GIT PULL 2/2] ARM64: EXYNOS: mach/soc changes for v4.6, 2nd
In-Reply-To: <1456445103-23314-1-git-send-email-k.kozlowski@samsung.com>
References: <1456445103-23314-1-git-send-email-k.kozlowski@samsung.com>
Message-ID: <1456445103-23314-2-git-send-email-k.kozlowski@samsung.com>

Hi Arnd, Kevin and Olof,


Pull request for v4.6 with ARM64 mach/soc changes.

This depends on change in clk tree (removal of ARCH_EXYNOS7) which is
pulled here.


Kind regards,
Krzysztof


Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>
Cc: Stephen Boyd <sboyd at codeaurora.org>
Cc: Michael Turquette <mturquette at baylibre.com>



The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc64-4.6-2

for you to fetch changes up to c87b3e970c70d5e27f9eb9acd09c6b5b9d589860:

  arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS (2016-02-23 08:49:46 +0900)

----------------------------------------------------------------
Samsung Exynos ARM64 improvements for v4.6:
1. Remove separate ARCH_EXYNOS7 symbol and consolidate it into
   one ARCH_EXYNOS.
   This depends on clk tree: removal of last presence of ARCH_EXYNOS7.

----------------------------------------------------------------
Andi Shyti (4):
      clk: s2mps11: merge two for loops in one
      clk: s2mps11: allocate only one structure for clock init
      clk: s2mps11: remove redundant static variables declaration
      clk: s2mps11: remove redundant code

Axel Lin (1):
      clk: scpi: Fix checking return value of platform_device_register_simple()

Geliang Tang (1):
      clk: move the common clock's to_clk_*(_hw) macros to clk-provider.h

Heiko Stuebner (1):
      clk-divider: make sure read-only dividers do not write to their register

James Liao (2):
      clk: mediatek: Fix memory leak on clock init fail
      clk: Move vendor's Kconfig into CCF menu section

Krzysztof Kozlowski (4):
      clk: samsung: Enable COMPILE_TEST for Samsung clocks
      clk: samsung: Don't build ARMv8 clock drivers on ARMv7
      Merge branch 'clk-samsung' of git://git.kernel.org/.../clk/linux into next/soc64
      arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS

Loc Ho (2):
      Documentation: Update APM X-Gene clock binding for v2 hardware
      clk: xgene: Add SoC and PMD PLL clocks with v2 hardware

Marc Gonzalez (1):
      clk: tango4: rename ARCH_TANGOX to ARCH_TANGO

Stephen Boyd (2):
      clk: mvebu: Mark ioremapped memory as __iomem
      clk: xgene: Remove return from void function

 Documentation/devicetree/bindings/clock/xgene.txt |   2 +
 arch/arm/mach-s3c24xx/Kconfig                     |   1 +
 arch/arm64/Kconfig.platforms                      |  11 +--
 arch/arm64/boot/dts/exynos/Makefile               |   2 +-
 arch/arm64/configs/defconfig                      |   2 +-
 drivers/clk/Kconfig                               |   8 +-
 drivers/clk/Makefile                              |   2 +-
 drivers/clk/clk-composite.c                       |   2 -
 drivers/clk/clk-divider.c                         |  13 ++-
 drivers/clk/clk-fixed-factor.c                    |   2 -
 drivers/clk/clk-fixed-rate.c                      |   2 -
 drivers/clk/clk-fractional-divider.c              |   2 -
 drivers/clk/clk-gate.c                            |   2 -
 drivers/clk/clk-gpio.c                            |   2 -
 drivers/clk/clk-multiplier.c                      |   2 -
 drivers/clk/clk-mux.c                             |   2 -
 drivers/clk/clk-s2mps11.c                         | 108 +++++++---------------
 drivers/clk/clk-scpi.c                            |   2 +-
 drivers/clk/clk-xgene.c                           | 105 +++++++++++++--------
 drivers/clk/imx/clk-busy.c                        |   4 +-
 drivers/clk/imx/clk-fixup-div.c                   |   5 +-
 drivers/clk/imx/clk-fixup-mux.c                   |   2 -
 drivers/clk/imx/clk-gate-exclusive.c              |   2 +-
 drivers/clk/mediatek/clk-gate.c                   |   8 +-
 drivers/clk/mediatek/clk-gate.h                   |   2 +-
 drivers/clk/mediatek/clk-mtk.c                    |   6 +-
 drivers/clk/mvebu/common.c                        |   2 -
 drivers/clk/mvebu/dove-divider.c                  |   2 +-
 drivers/clk/mvebu/kirkwood.c                      |   2 -
 drivers/clk/mxs/clk-div.c                         |   2 +-
 drivers/clk/nxp/clk-lpc18xx-ccu.c                 |   4 +-
 drivers/clk/rockchip/clk.c                        |   4 +-
 drivers/clk/samsung/Kconfig                       |  19 ++--
 drivers/clk/samsung/Makefile                      |   4 +-
 drivers/clk/st/clkgen-mux.c                       |   9 +-
 drivers/clk/ti/composite.c                        |   2 -
 drivers/clk/ti/divider.c                          |   2 -
 drivers/clk/ti/gate.c                             |   2 -
 drivers/clk/ti/mux.c                              |   2 -
 include/linux/clk-provider.h                      |  19 ++++
 40 files changed, 178 insertions(+), 198 deletions(-)


From horms+renesas at verge.net.au  Thu Feb 25 15:52:50 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 08:52:50 +0900
Subject: [PATCH 01/19] ARM: dts: r8a7790: use fallback pcie compatibility
 string
In-Reply-To: <cover.1456443769.git.horms+renesas@verge.net.au>
References: <cover.1456443769.git.horms+renesas@verge.net.au>
Message-ID: <e670be8d31b22b2bc2def8097c0a2ddf309c0ab8.1456443769.git.horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7790 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm/boot/dts/r8a7790.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index c9583fa6cae7..db019f2619c7 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1590,7 +1590,7 @@
 	};
 
 	pciec: pcie at fe000000 {
-		compatible = "renesas,pcie-r8a7790";
+		compatible = "renesas,pcie-r8a7790", "renesas,pcie-rcar-gen2";
 		reg = <0 0xfe000000 0 0x80000>;
 		#address-cells = <3>;
 		#size-cells = <2>;
-- 
2.7.0.rc3.207.g0ac5344



From sboyd at codeaurora.org  Thu Feb 25 15:56:55 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Feb 2016 15:56:55 -0800
Subject: [PATCH 0/2] clk: imx6: add kpp clock for i.MX6UL
In-Reply-To: <1452619759-14474-1-git-send-email-LW@KARO-electronics.de>
References: <1452619759-14474-1-git-send-email-LW@KARO-electronics.de>
Message-ID: <20160225235655.GN28849@codeaurora.org>

On 01/12, Lothar Wa?mann wrote:
> This patchset adds the clock which is necessary to operate the KPP
> unit on i.MX6UL.
> The first patch removes bogus whitespace before TABs in indentation.
> The second patch adds the clock definition.
> 

Both look fine. Shawn?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From k.kozlowski at samsung.com  Thu Feb 25 16:05:02 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 26 Feb 2016 09:05:02 +0900
Subject: [GIT PULL 1/2] ARM: EXYNOS: mach/soc changes for v4.6, 2nd
Message-ID: <1456445103-23314-1-git-send-email-k.kozlowski@samsung.com>

Hi Arnd, Kevin and Olof,


Second pull request for v4.6 with mach/soc changes. This does
not contain any external dependencies.

It includes movement of PMU code to separate driver (drivers/soc) but
it does not have commits doing the same for the SROM controller driver
(that part I will send separately).


Kind regards,
Krzysztof


Cc: Pankaj Dubey <pankaj.dubey at samsung.com>



The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-4.6-2

for you to fetch changes up to 15925cfcf83361b4eb8c7ffb51ad29b5f1e32a23:

  ARM: s3c24xx: Avoid warning for inb/outb (2016-02-26 08:44:52 +0900)

----------------------------------------------------------------
Samsung Exynos (and older platforms) improvements for v4.6:
1. Split out Exynos PMU driver implementation from arm/mach-exynos
   to the drivers/soc/samsung which will allow re-use of it on ARM64.
2. Use generic DT cpufreq driver on Exynos542x/5800.
3. Minor cleanups.

----------------------------------------------------------------
Arnd Bergmann (1):
      ARM: s3c24xx: Avoid warning for inb/outb

Bartlomiej Zolnierkiewicz (2):
      ARM: EXYNOS: Use generic cpufreq driver for Exynos5420
      ARM: EXYNOS: Use generic cpufreq driver for Exynos5422/5800

Geliang Tang (1):
      ARM: plat-samsung: use to_platform_device()

Krzysztof Kozlowski (1):
      drivers: soc: samsung: Enable COMPILE_TEST

Masahiro Yamada (1):
      ARM: s3c64xx: use "depends on" instead of "if" after prompt

Pankaj Dubey (12):
      ARM: EXYNOS: Remove unused static mapping of CMU for exynos5
      ARM: EXYNOS: Code cleanup in map.h
      ARM: EXYNOS: Correct header comment in Kconfig file
      ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung"
      ARM: EXYNOS: Split up exynos3250 SoC specific PMU data
      ARM: EXYNOS: Split up exynos4 SoC specific PMU data
      ARM: EXYNOS: Split up exynos5250 SoC specific PMU data
      ARM: EXYNOS: Split up exynos5420 SoC specific PMU data
      drivers: soc: Add support for Exynos PMU driver
      MAINTAINERS: Add maintainers entry for drivers/soc/samsung
      ARM: EXYNOS: Cleanup header files inclusion
      ARM: SAMSUNG: Remove unused register offset definition

 MAINTAINERS                                        |   1 +
 arch/arm/mach-exynos/Kconfig                       |   4 +-
 arch/arm/mach-exynos/Makefile                      |   2 +-
 arch/arm/mach-exynos/common.h                      |   1 -
 arch/arm/mach-exynos/exynos.c                      |  17 +-
 arch/arm/mach-exynos/firmware.c                    |   2 -
 arch/arm/mach-exynos/include/mach/map.h            |  14 +-
 arch/arm/mach-exynos/mcpm-exynos.c                 |   2 +-
 arch/arm/mach-exynos/platsmp.c                     |   3 +-
 arch/arm/mach-exynos/pm.c                          |   8 +-
 arch/arm/mach-exynos/pmu.c                         | 967 ---------------------
 arch/arm/mach-exynos/s5p-dev-mfc.c                 |   1 -
 arch/arm/mach-exynos/suspend.c                     |   4 +-
 arch/arm/mach-s3c24xx/include/mach/io.h            |   2 +-
 arch/arm/mach-s3c24xx/include/mach/map.h           |  11 -
 arch/arm/mach-s3c64xx/Kconfig                      |   3 +-
 arch/arm/plat-samsung/adc.c                        |   6 +-
 arch/arm/plat-samsung/include/plat/map-s3c.h       |   4 -
 arch/arm/plat-samsung/include/plat/map-s5p.h       |   5 -
 drivers/soc/Kconfig                                |   1 +
 drivers/soc/Makefile                               |   1 +
 drivers/soc/samsung/Kconfig                        |  13 +
 drivers/soc/samsung/Makefile                       |   2 +
 drivers/soc/samsung/exynos-pmu.c                   | 141 +++
 drivers/soc/samsung/exynos-pmu.h                   |  44 +
 drivers/soc/samsung/exynos3250-pmu.c               | 175 ++++
 drivers/soc/samsung/exynos4-pmu.c                  | 222 +++++
 drivers/soc/samsung/exynos5250-pmu.c               | 195 +++++
 drivers/soc/samsung/exynos5420-pmu.c               | 280 ++++++
 .../linux/soc/samsung}/exynos-pmu.h                |   6 +-
 .../linux/soc/samsung/exynos-regs-pmu.h            |   6 +-
 31 files changed, 1103 insertions(+), 1040 deletions(-)
 delete mode 100644 arch/arm/mach-exynos/pmu.c
 create mode 100644 drivers/soc/samsung/Kconfig
 create mode 100644 drivers/soc/samsung/Makefile
 create mode 100644 drivers/soc/samsung/exynos-pmu.c
 create mode 100644 drivers/soc/samsung/exynos-pmu.h
 create mode 100644 drivers/soc/samsung/exynos3250-pmu.c
 create mode 100644 drivers/soc/samsung/exynos4-pmu.c
 create mode 100644 drivers/soc/samsung/exynos5250-pmu.c
 create mode 100644 drivers/soc/samsung/exynos5420-pmu.c
 rename {arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h (81%)
 rename arch/arm/mach-exynos/regs-pmu.h => include/linux/soc/samsung/exynos-regs-pmu.h (99%)


From sboyd at codeaurora.org  Thu Feb 25 16:07:13 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Feb 2016 16:07:13 -0800
Subject: [PATCH v2] clk: uniphier: add clock drivers for UniPhier SoCs
In-Reply-To: <1451298003-28841-1-git-send-email-yamada.masahiro@socionext.com>
References: <1451298003-28841-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <20160226000713.GO28849@codeaurora.org>

On 12/28, Masahiro Yamada wrote:
> This is the initial commit for the UniPhier clock drivers, including
> support for PH1-sLD3, PH1-LD4, PH1-Pro4, PH1-sLD8, PH1-Pro5, and
> ProXstream2/PH1-LD6b.
> 
> To improve the code maintainability, the driver consists of common
> functions (clk-uniphier-core.c) and clock data arrays needed to
> support each SoC.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
> ---

Where's the DT binding? Also, can these clks be registered from a
platform device driver instead of from 
> 
> diff --git a/drivers/clk/uniphier/Kconfig b/drivers/clk/uniphier/Kconfig
> new file mode 100644
> index 0000000..7606f27
> --- /dev/null
> +++ b/drivers/clk/uniphier/Kconfig
> @@ -0,0 +1,35 @@
> +menuconfig CLK_UNIPHIER
> +	bool "Clock drivers for UniPhier SoCs"
> +	depends on ARCH_UNIPHIER

Can we have COMPILE_TEST here?

> +	depends on OF
> +	default y

And then default ARCH_UNIPHIER instead.

> +	help
> +	  Supports clock drivers for UniPhier SoCs.
> +
> +if CLK_UNIPHIER
> +
> +config CLK_UNIPHIER_PH1_SLD3
> +	bool "Clock driver for UniPhier PH1-sLD3 SoC"
> +	default y

These would all become default ARCH_UNIPHIER as well.
> +
> +config CLK_UNIPHIER_PH1_LD4
> +	bool "Clock driver for UniPhier PH1-LD4 SoC"
> +	default y
> +
> +config CLK_UNIPHIER_PH1_PRO4
> +	bool "Clock driver for UniPhier PH1-Pro4 SoC"
> +	default y
> +
> +config CLK_UNIPHIER_PH1_SLD8
> +	bool "Clock driver for UniPhier PH1-sLD8 SoC"
> +	default y
> +
> +config CLK_UNIPHIER_PH1_PRO5
> +	bool "Clock driver for UniPhier PH1-Pro5 SoC"
> +	default y
> +
> +config CLK_UNIPHIER_PROXSTREAM2
> +	bool "Clock driver for UniPhier ProXstream2/PH1-LD6b SoC"
> +	default y
> +
> +endif
> diff --git a/drivers/clk/uniphier/clk-uniphier-core.c b/drivers/clk/uniphier/clk-uniphier-core.c

Maybe this patch can be split between core code and SoC specific
data? That way we can focus on the core code without wading
through all the random clk data arrays.

> new file mode 100644
> index 0000000..8680101
> --- /dev/null
> +++ b/drivers/clk/uniphier/clk-uniphier-core.c
> @@ -0,0 +1,151 @@
> +/*
> + * Copyright (C) 2015 Masahiro Yamada <yamada.masahiro at socionext.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#define pr_fmt(fmt)		"uniphier-clk: " fmt
> +
> +#include <linux/clk-provider.h>
> +#include <linux/log2.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/slab.h>
> +
> +#include "clk-uniphier.h"
> +
> +static void __init uniphier_clk_update_parent_name(struct device_node *np,
> +						   const char **parent_name)
> +{
> +	const char *new_name;
> +	int index;
> +
> +	if (!parent_name || !*parent_name)
> +		return;
> +
> +	if (strncmp(*parent_name, UNIPHIER_CLK_EXT, strlen(UNIPHIER_CLK_EXT)))
> +		return;
> +
> +	index = of_property_match_string(np, "clock-names",
> +				*parent_name + strlen(UNIPHIER_CLK_EXT));

If possible please don't use clock-names to set up clock
hierarchy.

> +	new_name = of_clk_get_parent_name(np, index);
> +	if (new_name)
> +		*parent_name = new_name;
> +}
> +
> +static struct clk * __init uniphier_clk_register(struct device_node *np,
> +						 void __iomem *regbase,
> +					  struct uniphier_clk_init_data *idata)
> +{
> +	int i;
> +
> +	switch (idata->type) {
> +	case UNIPHIER_CLK_TYPE_FIXED_FACTOR:
> +		uniphier_clk_update_parent_name(np,
> +					&idata->data.factor.parent_name);
> +		return clk_register_fixed_factor(NULL, idata->name,
> +						 idata->data.factor.parent_name,
> +						 CLK_SET_RATE_PARENT,
> +						 idata->data.factor.mult,
> +						 idata->data.factor.div);
> +	case UNIPHIER_CLK_TYPE_FIXED_RATE:
> +		return clk_register_fixed_rate(NULL, idata->name, NULL,
> +					       CLK_IS_ROOT,
> +					       idata->data.rate.fixed_rate);
> +	case UNIPHIER_CLK_TYPE_GATE:
> +		uniphier_clk_update_parent_name(np,
> +						&idata->data.gate.parent_name);
> +		return clk_register_gate(NULL, idata->name,
> +					 idata->data.gate.parent_name,
> +					 idata->data.gate.parent_name ?
> +					 CLK_SET_RATE_PARENT : CLK_IS_ROOT,
> +					 regbase + idata->data.gate.reg,
> +					 idata->data.gate.bit_idx, 0, NULL);
> +	case UNIPHIER_CLK_TYPE_MUX:
> +		for (i = 0; i < idata->data.mux.num_parents; i++)
> +			uniphier_clk_update_parent_name(np,
> +					&idata->data.mux.parent_names[i]);
> +		return clk_register_mux(NULL, idata->name,
> +					idata->data.mux.parent_names,
> +					idata->data.mux.num_parents,
> +					CLK_SET_RATE_PARENT,
> +					regbase + idata->data.mux.reg,
> +					idata->data.mux.shift,
> +					ilog2(idata->data.mux.num_parents),
> +					0, NULL);
> +	default:
> +		WARN(1, "unsupported clock type\n");
> +		return ERR_PTR(-EINVAL);
> +	}
> +}
> +
> +int __init uniphier_clk_init(struct device_node *np,
> +			     struct uniphier_clk_init_data *idata)
> +{
> +	struct clk_onecell_data *clk_data;
> +	struct uniphier_clk_init_data *p;
> +	void __iomem *regbase;
> +	int max_index = 0;
> +	int ret;
> +
> +	regbase = of_iomap(np, 0);

If not a platform device, use of_io_request_and_map()?

> +	if (!regbase)
> +		return -ENOMEM;
> +
> +	for (p = idata; p->name; p++)
> +		max_index = max(max_index, p->output_index);
> +
> +	clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
> +	if (!clk_data)
> +		return -ENOMEM;
> +
> +	clk_data->clk_num = max_index + 1;
> +	clk_data->clks = kcalloc(clk_data->clk_num, sizeof(struct clk *),
> +				 GFP_KERNEL);
> diff --git a/drivers/clk/uniphier/clk-uniphier.h b/drivers/clk/uniphier/clk-uniphier.h
> new file mode 100644
> index 0000000..05277b6
> --- /dev/null
> +++ b/drivers/clk/uniphier/clk-uniphier.h
> @@ -0,0 +1,68 @@
> +/*
> + * Copyright (C) 2015 Masahiro Yamada <yamada.masahiro at socionext.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __CLK_UNIPHIER_H__
> +#define __CLK_UNIPHIER_H__
> +
> +#include <linux/kernel.h>

What's this include for?

> +
> +#define UNIPHIER_CLK_EXT	"[EXT]"
> +
> +enum uniphier_clk_type {
> +	UNIPHIER_CLK_TYPE_FIXED_FACTOR,
> +	UNIPHIER_CLK_TYPE_FIXED_RATE,
> +	UNIPHIER_CLK_TYPE_GATE,
> +	UNIPHIER_CLK_TYPE_MUX,
> +};
> +
> +struct uniphier_clk_fixed_factor_data {
> +	const char *parent_name;
> +	unsigned int mult;
> +	unsigned int div;
> +};
> +
> +struct uniphier_clk_fixed_rate_data {
> +	unsigned long fixed_rate;
> +};
> +
> +struct uniphier_clk_gate_data {
> +	const char *parent_name;
> +	unsigned int reg;
> +	u8 bit_idx;
> +};
> +
> +struct uniphier_clk_mux_data {
> +	const char *parent_names[4];
> +	u8 num_parents;
> +	unsigned int reg;
> +	u8 shift;
> +};
> +
> +struct uniphier_clk_init_data {
> +	const char *name;
> +	enum uniphier_clk_type type;
> +	int output_index;
> +	union {
> +		struct uniphier_clk_fixed_factor_data factor;
> +		struct uniphier_clk_fixed_rate_data rate;
> +		struct uniphier_clk_gate_data gate;
> +		struct uniphier_clk_mux_data mux;
> +	} data;
> +	struct clk *clk;

Probably need to forward declare this struct.

> +};
> +
> +int uniphier_clk_init(struct device_node *np,

Same for device_node.

> +		      struct uniphier_clk_init_data *idata);
> +
> +#endif /* __CLK_UNIPHIER_H__ */
> -- 
> 1.9.1
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From gnomes at lxorguk.ukuu.org.uk  Thu Feb 25 16:06:51 2016
From: gnomes at lxorguk.ukuu.org.uk (One Thousand Gnomes)
Date: Fri, 26 Feb 2016 00:06:51 +0000
Subject: [PATCH] serial: ifx6x60: avoid uninitialized variable use
In-Reply-To: <1456433283-3761559-1-git-send-email-arnd@arndb.de>
References: <1456433283-3761559-1-git-send-email-arnd@arndb.de>
Message-ID: <20160226000651.628e28fe@lxorguk.ukuu.org.uk>

On Thu, 25 Feb 2016 21:47:57 +0100
Arnd Bergmann <arnd at arndb.de> wrote:

> gcc warns about a potential use of an uninitialized variable in this driver:
> 
> drivers/tty/serial/ifx6x60.c: In function 'ifx_spi_complete':
> drivers/tty/serial/ifx6x60.c:713:6: warning: 'more' may be used uninitialized in this function [-Wmaybe-uninitialized]
>    if (more || ifx_dev->spi_more || queue_length > 0 ||
> 
> Unlike a lot of other such warnings, this one is correct and describes
> an actual problem in the handling of the "IFX_SPI_HEADER_F" result code.
> 
> This appears to be a result from a restructuring of the driver that
> dates back to before it was merged in the kernel, so it's impossible
> to know where it went wrong. I also don't know what that result code
> means, so I have no idea if setting 'more' to zero is the correct
> solution, but at least it makes the behavior reproducible rather than
> depending on whatever happens to be on the kernel stack.

Would it not be far simpler just to set more = 0 at the top of
ifx_spi_complete ?





From horms+renesas at verge.net.au  Thu Feb 25 16:07:32 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 09:07:32 +0900
Subject: [GIT PULL] Second Round of Renesas ARM64 Based SoC DT Updates for v4.6
Message-ID: <cover.1456445161.git.horms+renesas@verge.net.au>

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these second round of Renesas ARM64 based SoC DT updates
for v4.6.

This pull request is based on the previous round of
such requests, tagged as renesas-arm64-dt-for-v4.6,
which you have already pulled.


The following changes since commit a3fc85e27b7e3c29b30909929bc64737a19fd251:

  arm64: dts: salvator-x: Enable SCIF_CLK frequency and pins (2016-02-03 10:04:33 +0100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-dt2-for-v4.6

for you to fetch changes up to 474efcae3b78167d82def103fcf497152db17c95:

  arm64: dts: salvator-x: enable USB 2.0 Host of channel 1 and 2 (2016-02-26 08:55:32 +0900)

----------------------------------------------------------------
Second Round of Renesas ARM64 Based SoC DT Updates for v4.6

Updates for r8a7795/salvator-x
* Enable USB2.0, and SDHI0 & 3
* Add GIC-400 virtual interfaces
* Add INTC-EX and L2 cache-controller nodes
* Use fallback etheravb compatibility string
* Use GIC_* defines where appropriate

----------------------------------------------------------------
Ai Kyuse (2):
      arm64: dts: r8a7795: Add SDHI support to dtsi
      arm64: dts: r8a7795: salvator-x: enable SDHI0 & 3

Dirk Behme (2):
      arm64: dts: r8a7795: pmu: switch to Cortex specific device nodes
      arm64: dts: r8a7795: Add GIC-400 virtual interfaces

Geert Uytterhoeven (3):
      arm64: dts: r8a7795: Add L2 cache-controller nodes
      arm64: dts: r8a7795: Add missing properties to CA57 L2 cache node
      arm64: dts: r8a7795: Add CA53 L2 cache-controller node

Magnus Damm (1):
      arm64: dts: r8a7795: Add INTC-EX device node

Simon Horman (2):
      arm64: dts: r8a7795: use GIC_* defines
      arm64: dts: r8a7795: use fallback etheravb compatibility string

Yoshihiro Shimoda (4):
      arm64: dts: r8a7795: add usb2_phy device nodes
      arm64: dts: r8a7795: add USB2.0 Host (EHCI/OHCI) device nodes
      arm64: dts: salvator-x: enable usb2_phy of channel 1 and 2
      arm64: dts: salvator-x: enable USB 2.0 Host of channel 1 and 2

 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 123 +++++++++
 arch/arm64/boot/dts/renesas/r8a7795.dtsi           | 282 ++++++++++++++++-----
 2 files changed, 347 insertions(+), 58 deletions(-)


From sboyd at codeaurora.org  Thu Feb 25 16:07:48 2016
From: sboyd at codeaurora.org (Stephen Boyd)
Date: Thu, 25 Feb 2016 16:07:48 -0800
Subject: [PATCH] clk: bcm2835: added missing clock register definitions
In-Reply-To: <1450815189-3342-1-git-send-email-kernel@martin.sperl.org>
References: <1450815189-3342-1-git-send-email-kernel@martin.sperl.org>
Message-ID: <20160226000748.GP28849@codeaurora.org>

On 12/22, kernel at martin.sperl.org wrote:
> From: Martin Sperl <kernel at martin.sperl.org>
> 
> Added missing CTRL and DIV clock register definitions for:
> PCM, SLIM, TCNT, TEC, TD0, TD1
> 
> Register information taken from:
> https://rawgit.com/msperl/rpi-registers/master/rpi-registers.html#CM
> which extracted the information from the header files shared by
> Broadcom/rpi foundation in this file:
> http://www.broadcom.com/docs/support/videocore/Brcm_Android_ICS_Graphics_Stack.tar.gz
> 
> Signed-off-by: Martin Sperl <kernel at martin.sperl.org>
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


From horms+renesas at verge.net.au  Thu Feb 25 16:07:34 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 09:07:34 +0900
Subject: [PATCH 01/14] arm64: dts: r8a7795: Add L2 cache-controller nodes
In-Reply-To: <cover.1456445161.git.horms+renesas@verge.net.au>
References: <cover.1456445161.git.horms+renesas@verge.net.au>
Message-ID: <7b337e61a4104d5a0abde1e733916de2208800e6.1456445161.git.horms+renesas@verge.net.au>

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

Add device nodes for the L2 caches, and link the CPU node to its L2
cache node.

The L2 cache for the Cortex-A57 CPU cores is 2 MiB large (organized as
128 KiB x 16 ways).

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Dirk Behme <dirk.behme at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 9634e3a4858e..3f00e85641a8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -39,6 +39,7 @@
 			compatible = "arm,cortex-a57", "arm,armv8";
 			reg = <0x0>;
 			device_type = "cpu";
+			next-level-cache = <&L2_CA57>;
 			enable-method = "psci";
 		};
 
@@ -46,22 +47,29 @@
 			compatible = "arm,cortex-a57","arm,armv8";
 			reg = <0x1>;
 			device_type = "cpu";
+			next-level-cache = <&L2_CA57>;
 			enable-method = "psci";
 		};
 		a57_2: cpu at 2 {
 			compatible = "arm,cortex-a57","arm,armv8";
 			reg = <0x2>;
 			device_type = "cpu";
+			next-level-cache = <&L2_CA57>;
 			enable-method = "psci";
 		};
 		a57_3: cpu at 3 {
 			compatible = "arm,cortex-a57","arm,armv8";
 			reg = <0x3>;
 			device_type = "cpu";
+			next-level-cache = <&L2_CA57>;
 			enable-method = "psci";
 		};
 	};
 
+	L2_CA57: cache-controller at 0 {
+		compatible = "cache";
+	};
+
 	extal_clk: extal {
 		compatible = "fixed-clock";
 		#clock-cells = <0>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 16:07:35 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 09:07:35 +0900
Subject: [PATCH 02/14] arm64: dts: r8a7795: pmu: switch to Cortex specific
 device nodes
In-Reply-To: <cover.1456445161.git.horms+renesas@verge.net.au>
References: <cover.1456445161.git.horms+renesas@verge.net.au>
Message-ID: <3d0cd46889e0a57ce63dba1f34156b54dfdf0ad2.1456445161.git.horms+renesas@verge.net.au>

From: Dirk Behme <dirk.behme at gmail.com>

Instead of using the generic armv8-pmuv3 compatibility use the more
specific Cortex A57 compatibility.

Signed-off-by: Dirk Behme <dirk.behme at gmail.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 3f00e85641a8..b5e46e4ff72a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -246,8 +246,8 @@
 			power-domains = <&cpg>;
 		};
 
-		pmu {
-			compatible = "arm,armv8-pmuv3";
+		pmu_a57 {
+			compatible = "arm,cortex-a57-pmu";
 			interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>,
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 16:07:36 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 09:07:36 +0900
Subject: [PATCH 03/14] arm64: dts: r8a7795: use GIC_* defines
In-Reply-To: <cover.1456445161.git.horms+renesas@verge.net.au>
References: <cover.1456445161.git.horms+renesas@verge.net.au>
Message-ID: <52b541abbc02f64e2105dff278c8b4e7e75041f4.1456445161.git.horms+renesas@verge.net.au>

Use GIC_* defines for GIC interrupt cells in r8a7795 device tree.

Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 108 +++++++++++++++----------------
 1 file changed, 54 insertions(+), 54 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index b5e46e4ff72a..832a5665bb27 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -282,23 +282,23 @@
 		audma0: dma-controller at ec700000 {
 			compatible = "renesas,rcar-dmac";
 			reg = <0 0xec700000 0 0x10000>;
-			interrupts =	<0 350 IRQ_TYPE_LEVEL_HIGH
-					 0 320 IRQ_TYPE_LEVEL_HIGH
-					 0 321 IRQ_TYPE_LEVEL_HIGH
-					 0 322 IRQ_TYPE_LEVEL_HIGH
-					 0 323 IRQ_TYPE_LEVEL_HIGH
-					 0 324 IRQ_TYPE_LEVEL_HIGH
-					 0 325 IRQ_TYPE_LEVEL_HIGH
-					 0 326 IRQ_TYPE_LEVEL_HIGH
-					 0 327 IRQ_TYPE_LEVEL_HIGH
-					 0 328 IRQ_TYPE_LEVEL_HIGH
-					 0 329 IRQ_TYPE_LEVEL_HIGH
-					 0 330 IRQ_TYPE_LEVEL_HIGH
-					 0 331 IRQ_TYPE_LEVEL_HIGH
-					 0 332 IRQ_TYPE_LEVEL_HIGH
-					 0 333 IRQ_TYPE_LEVEL_HIGH
-					 0 334 IRQ_TYPE_LEVEL_HIGH
-					 0 335 IRQ_TYPE_LEVEL_HIGH>;
+			interrupts = <GIC_SPI 350 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "error",
 					"ch0", "ch1", "ch2", "ch3",
 					"ch4", "ch5", "ch6", "ch7",
@@ -314,23 +314,23 @@
 		audma1: dma-controller at ec720000 {
 			compatible = "renesas,rcar-dmac";
 			reg = <0 0xec720000 0 0x10000>;
-			interrupts =	<0 351 IRQ_TYPE_LEVEL_HIGH
-					 0 336 IRQ_TYPE_LEVEL_HIGH
-					 0 337 IRQ_TYPE_LEVEL_HIGH
-					 0 338 IRQ_TYPE_LEVEL_HIGH
-					 0 339 IRQ_TYPE_LEVEL_HIGH
-					 0 340 IRQ_TYPE_LEVEL_HIGH
-					 0 341 IRQ_TYPE_LEVEL_HIGH
-					 0 342 IRQ_TYPE_LEVEL_HIGH
-					 0 343 IRQ_TYPE_LEVEL_HIGH
-					 0 344 IRQ_TYPE_LEVEL_HIGH
-					 0 345 IRQ_TYPE_LEVEL_HIGH
-					 0 346 IRQ_TYPE_LEVEL_HIGH
-					 0 347 IRQ_TYPE_LEVEL_HIGH
-					 0 348 IRQ_TYPE_LEVEL_HIGH
-					 0 349 IRQ_TYPE_LEVEL_HIGH
-					 0 382 IRQ_TYPE_LEVEL_HIGH
-					 0 383 IRQ_TYPE_LEVEL_HIGH>;
+			interrupts = <GIC_SPI 351 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 346 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 348 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 349 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 382 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 383 IRQ_TYPE_LEVEL_HIGH>;
 			interrupt-names = "error",
 					"ch0", "ch1", "ch2", "ch3",
 					"ch4", "ch5", "ch6", "ch7",
@@ -804,52 +804,52 @@
 
 			rcar_sound,src {
 				src0: src at 0 {
-					interrupts = <0 352 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 352 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x85>, <&audma1 0x9a>;
 					dma-names = "rx", "tx";
 				};
 				src1: src at 1 {
-					interrupts = <0 353 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x87>, <&audma1 0x9c>;
 					dma-names = "rx", "tx";
 				};
 				src2: src at 2 {
-					interrupts = <0 354 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x89>, <&audma1 0x9e>;
 					dma-names = "rx", "tx";
 				};
 				src3: src at 3 {
-					interrupts = <0 355 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x8b>, <&audma1 0xa0>;
 					dma-names = "rx", "tx";
 				};
 				src4: src at 4 {
-					interrupts = <0 356 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x8d>, <&audma1 0xb0>;
 					dma-names = "rx", "tx";
 				};
 				src5: src at 5 {
-					interrupts = <0 357 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x8f>, <&audma1 0xb2>;
 					dma-names = "rx", "tx";
 				};
 				src6: src at 6 {
-					interrupts = <0 358 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x91>, <&audma1 0xb4>;
 					dma-names = "rx", "tx";
 				};
 				src7: src at 7 {
-					interrupts = <0 359 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x93>, <&audma1 0xb6>;
 					dma-names = "rx", "tx";
 				};
 				src8: src at 8 {
-					interrupts = <0 360 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x95>, <&audma1 0xb8>;
 					dma-names = "rx", "tx";
 				};
 				src9: src at 9 {
-					interrupts = <0 361 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 361 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x97>, <&audma1 0xba>;
 					dma-names = "rx", "tx";
 				};
@@ -857,52 +857,52 @@
 
 			rcar_sound,ssi {
 				ssi0: ssi at 0 {
-					interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x01>, <&audma1 0x02>, <&audma0 0x15>, <&audma1 0x16>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi1: ssi at 1 {
-					 interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>;
+					 interrupts = <GIC_SPI 371 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x03>, <&audma1 0x04>, <&audma0 0x49>, <&audma1 0x4a>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi2: ssi at 2 {
-					interrupts = <0 372 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x05>, <&audma1 0x06>, <&audma0 0x63>, <&audma1 0x64>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi3: ssi at 3 {
-					interrupts = <0 373 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x07>, <&audma1 0x08>, <&audma0 0x6f>, <&audma1 0x70>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi4: ssi at 4 {
-					interrupts = <0 374 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x09>, <&audma1 0x0a>, <&audma0 0x71>, <&audma1 0x72>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi5: ssi at 5 {
-					interrupts = <0 375 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x0b>, <&audma1 0x0c>, <&audma0 0x73>, <&audma1 0x74>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi6: ssi at 6 {
-					interrupts = <0 376 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x0d>, <&audma1 0x0e>, <&audma0 0x75>, <&audma1 0x76>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi7: ssi at 7 {
-					interrupts = <0 377 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x0f>, <&audma1 0x10>, <&audma0 0x79>, <&audma1 0x7a>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi8: ssi at 8 {
-					interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 378 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x11>, <&audma1 0x12>, <&audma0 0x7b>, <&audma1 0x7c>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
 				ssi9: ssi at 9 {
-					interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 379 IRQ_TYPE_LEVEL_HIGH>;
 					dmas = <&audma0 0x13>, <&audma1 0x14>, <&audma0 0x7d>, <&audma1 0x7e>;
 					dma-names = "rx", "tx", "rxu", "txu";
 				};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 16:07:37 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 09:07:37 +0900
Subject: [PATCH 04/14] arm64: dts: r8a7795: Add missing properties to CA57 L2
 cache node
In-Reply-To: <cover.1456445161.git.horms+renesas@verge.net.au>
References: <cover.1456445161.git.horms+renesas@verge.net.au>
Message-ID: <a528b4bf1a2ecb756aa65548fd5518fe82fb4648.1456445161.git.horms+renesas@verge.net.au>

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

Add the missing "cache-unified" and "cache-level" properties to the
Cortex-A57 cache-controller node.

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Acked-by: Dirk Behme <dirk.behme at de.bosch.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 832a5665bb27..ea56066c2260 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -68,6 +68,8 @@
 
 	L2_CA57: cache-controller at 0 {
 		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
 	};
 
 	extal_clk: extal {
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 16:07:38 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 09:07:38 +0900
Subject: [PATCH 05/14] arm64: dts: r8a7795: Add CA53 L2 cache-controller node
In-Reply-To: <cover.1456445161.git.horms+renesas@verge.net.au>
References: <cover.1456445161.git.horms+renesas@verge.net.au>
Message-ID: <8e1c3aa30c2c3a5f982da9365a1ef03a3ac7a815.1456445161.git.horms+renesas@verge.net.au>

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

Add a device node for the Cortex-A53 L2 cache-controller.

The L2 cache for the Cortex-A53 CPU cores is 512 KiB large (organized as
32 KiB x 16 ways).

Signed-off-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index ea56066c2260..e32b652c8fd0 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -72,6 +72,12 @@
 		cache-level = <2>;
 	};
 
+	L2_CA53: cache-controller at 1 {
+		compatible = "cache";
+		cache-unified;
+		cache-level = <2>;
+	};
+
 	extal_clk: extal {
 		compatible = "fixed-clock";
 		#clock-cells = <0>;
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 16:07:39 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 09:07:39 +0900
Subject: [PATCH 06/14] arm64: dts: r8a7795: Add INTC-EX device node
In-Reply-To: <cover.1456445161.git.horms+renesas@verge.net.au>
References: <cover.1456445161.git.horms+renesas@verge.net.au>
Message-ID: <9c6c053c9ea845d61d3f0a7f1ba656b8154c64d0.1456445161.git.horms+renesas@verge.net.au>

From: Magnus Damm <damm+renesas at opensource.se>

Add a single r8a7795 INTC-EX device node to support
external IRQ pins IRQ0 -> IRQ5.

Signed-off-by: Magnus Damm <damm+renesas at opensource.se>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index e32b652c8fd0..6da8f79f10df 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -356,6 +356,21 @@
 			reg = <0 0xe6060000 0 0x50c>;
 		};
 
+		intc_ex: interrupt-controller at e61c0000 {
+			compatible = "renesas,intc-ex-r8a7795", "renesas,irqc";
+			#interrupt-cells = <2>;
+			interrupt-controller;
+			reg = <0 0xe61c0000 0 0x200>;
+			interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH
+				      GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 407>;
+			power-domains = <&cpg>;
+		};
+
 		dmac0: dma-controller at e6700000 {
 			compatible = "renesas,dmac-r8a7795",
 				     "renesas,rcar-dmac";
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 16:07:40 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 09:07:40 +0900
Subject: [PATCH 07/14] arm64: dts: r8a7795: Add GIC-400 virtual interfaces
In-Reply-To: <cover.1456445161.git.horms+renesas@verge.net.au>
References: <cover.1456445161.git.horms+renesas@verge.net.au>
Message-ID: <4c811edf65e809e6ac6ec35f4818efba2b1c6163.1456445161.git.horms+renesas@verge.net.au>

From: Dirk Behme <dirk.behme at de.bosch.com>

Besides the distributor and the CPU interface the GIC-400 additionally
supports the virtual interface control blocks and the virtual CPU interfaces.

Add the physical base addresses and size for these.

See

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0471b/index.html
-> 3.2. GIC-400 register map

and Linux kernel's

Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt

for more details.

For the at GICH Virtual interface control blocks at 0xf1040000 cover the
whole 128kB (0x20000) range. This is done based on the advice from Marc
Zyngier http://www.spinics.net/lists/arm-kernel/msg483139.html

Signed-off-by: Dirk Behme <dirk.behme at de.bosch.com>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 6da8f79f10df..1072c681f8b4 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -137,7 +137,9 @@
 			#address-cells = <0>;
 			interrupt-controller;
 			reg = <0x0 0xf1010000 0 0x1000>,
-			      <0x0 0xf1020000 0 0x2000>;
+			      <0x0 0xf1020000 0 0x2000>,
+			      <0x0 0xf1040000 0 0x20000>,
+			      <0x0 0xf1060000 0 0x2000>;
 			interrupts = <GIC_PPI 9
 					(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
 		};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 16:07:41 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 09:07:41 +0900
Subject: [PATCH 08/14] arm64: dts: r8a7795: Add SDHI support to dtsi
In-Reply-To: <cover.1456445161.git.horms+renesas@verge.net.au>
References: <cover.1456445161.git.horms+renesas@verge.net.au>
Message-ID: <d9d67010e0c699c838ac84245ec6d8651420d337.1456445161.git.horms+renesas@verge.net.au>

From: Ai Kyuse <ai.kyuse.uw at renesas.com>

Signed-off-by: Ai Kyuse <ai.kyuse.uw at renesas.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>
[wsa: squashed some fixes and added mmc-caps]
Signed-off-by: Wolfram Sang <wsa+renesas at sang-engineering.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 38 ++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 1072c681f8b4..c2bffd160c18 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -985,5 +985,43 @@
 			#dma-cells = <1>;
 			dma-channels = <2>;
 		};
+
+		sdhi0: sd at ee100000 {
+			compatible = "renesas,sdhi-r8a7795";
+			reg = <0 0xee100000 0 0x2000>;
+			interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 314>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		sdhi1: sd at ee120000 {
+			compatible = "renesas,sdhi-r8a7795";
+			reg = <0 0xee120000 0 0x2000>;
+			interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 313>;
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		sdhi2: sd at ee140000 {
+			compatible = "renesas,sdhi-r8a7795";
+			reg = <0 0xee140000 0 0x2000>;
+			interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 312>;
+			power-domains = <&cpg>;
+			cap-mmc-highspeed;
+			status = "disabled";
+		};
+
+		sdhi3: sd at ee160000 {
+			compatible = "renesas,sdhi-r8a7795";
+			reg = <0 0xee160000 0 0x2000>;
+			interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 311>;
+			power-domains = <&cpg>;
+			cap-mmc-highspeed;
+			status = "disabled";
+		};
 	};
 };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 16:07:45 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 09:07:45 +0900
Subject: [PATCH 12/14] arm64: dts: r8a7795: add USB2.0 Host (EHCI/OHCI) device
 nodes
In-Reply-To: <cover.1456445161.git.horms+renesas@verge.net.au>
References: <cover.1456445161.git.horms+renesas@verge.net.au>
Message-ID: <a2bcdc287694842504255e47323bcf57bc8c0572.1456445161.git.horms+renesas@verge.net.au>

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 66 ++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index c6e379000e90..a7315ebe3883 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1052,5 +1052,71 @@
 			#phy-cells = <0>;
 			status = "disabled";
 		};
+
+		ehci0: usb at ee080100 {
+			compatible = "generic-ehci";
+			reg = <0 0xee080100 0 0x100>;
+			interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 703>;
+			phys = <&usb2_phy0>;
+			phy-names = "usb";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		ehci1: usb at ee0a0100 {
+			compatible = "generic-ehci";
+			reg = <0 0xee0a0100 0 0x100>;
+			interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 702>;
+			phys = <&usb2_phy1>;
+			phy-names = "usb";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		ehci2: usb at ee0c0100 {
+			compatible = "generic-ehci";
+			reg = <0 0xee0c0100 0 0x100>;
+			interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 701>;
+			phys = <&usb2_phy2>;
+			phy-names = "usb";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		ohci0: usb at ee080000 {
+			compatible = "generic-ohci";
+			reg = <0 0xee080000 0 0x100>;
+			interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 703>;
+			phys = <&usb2_phy0>;
+			phy-names = "usb";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		ohci1: usb at ee0a0000 {
+			compatible = "generic-ohci";
+			reg = <0 0xee0a0000 0 0x100>;
+			interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 702>;
+			phys = <&usb2_phy1>;
+			phy-names = "usb";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
+
+		ohci2: usb at ee0c0000 {
+			compatible = "generic-ohci";
+			reg = <0 0xee0c0000 0 0x100>;
+			interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 701>;
+			phys = <&usb2_phy2>;
+			phy-names = "usb";
+			power-domains = <&cpg>;
+			status = "disabled";
+		};
 	};
 };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 16:07:46 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 09:07:46 +0900
Subject: [PATCH 13/14] arm64: dts: salvator-x: enable usb2_phy of channel 1
 and 2
In-Reply-To: <cover.1456445161.git.horms+renesas@verge.net.au>
References: <cover.1456445161.git.horms+renesas@verge.net.au>
Message-ID: <e24250c008f0dbd5ce828898104bc96840dd9b1b.1456445161.git.horms+renesas@verge.net.au>

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>

This board has a MAX3355 chip. However, we cannot use the extcon/max3355
driver because the ID pin doesn't connect to a gpio pin (in other words,
it connects to the SoC specific pin).
And, the phy-rcar-gen3-usb2 driver cannot handle such a chip for now.
So, this patch enables usb2_phy of channel 1 and 2.

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 24 ++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 1af67579e07a..e415535d2b63 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -188,6 +188,16 @@
 				 "audio_clkout_a", "audio_clkout3_a";
 		renesas,function = "audio_clk";
 	};
+
+	usb1_pins: usb1 {
+		renesas,groups = "usb1";
+		renesas,function = "usb1";
+	};
+
+	usb2_pins: usb2 {
+		renesas,groups = "usb2";
+		renesas,function = "usb2";
+	};
 };
 
 &scif1 {
@@ -348,3 +358,17 @@
 &xhci0 {
 	status = "okay";
 };
+
+&usb2_phy1 {
+	pinctrl-0 = <&usb1_pins>;
+	pinctrl-names = "default";
+
+	status = "okay";
+};
+
+&usb2_phy2 {
+	pinctrl-0 = <&usb2_pins>;
+	pinctrl-names = "default";
+
+	status = "okay";
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 16:07:47 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 09:07:47 +0900
Subject: [PATCH 14/14] arm64: dts: salvator-x: enable USB 2.0 Host of channel
 1 and 2
In-Reply-To: <cover.1456445161.git.horms+renesas@verge.net.au>
References: <cover.1456445161.git.horms+renesas@verge.net.au>
Message-ID: <474efcae3b78167d82def103fcf497152db17c95.1456445161.git.horms+renesas@verge.net.au>

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>

We should set SW15 to pin 2-3 side on the board before we use CN9
as USB host or peripheral.

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index e415535d2b63..b992b1a3d956 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -372,3 +372,19 @@
 
 	status = "okay";
 };
+
+&ehci1 {
+	status = "okay";
+};
+
+&ehci2 {
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
+&ohci2 {
+	status = "okay";
+};
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 16:07:42 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 09:07:42 +0900
Subject: [PATCH 09/14] arm64: dts: r8a7795: salvator-x: enable SDHI0 & 3
In-Reply-To: <cover.1456445161.git.horms+renesas@verge.net.au>
References: <cover.1456445161.git.horms+renesas@verge.net.au>
Message-ID: <1c0e7b9a007311892d68c27d61c648fa1ca092b4.1456445161.git.horms+renesas@verge.net.au>

From: Ai Kyuse <ai.kyuse.uw at renesas.com>

Add the exposed SD card slots. The on-board eMMC needs to wait until we
fixed the 8bit support.

Signed-off-by: Ai Kyuse <ai.kyuse.uw at renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas at sang-engineering.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 83 ++++++++++++++++++++++
 1 file changed, 83 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index 31ace9c1f79d..1af67579e07a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -33,6 +33,7 @@
 
 /dts-v1/;
 #include "r8a7795.dtsi"
+#include <dt-bindings/gpio/gpio.h>
 
 / {
 	model = "Renesas Salvator-X board based on r8a7795";
@@ -61,6 +62,54 @@
 		clock-frequency = <24576000>;
 	};
 
+	vcc_sdhi0: regulator at 1 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "SDHI0 Vcc";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&gpio5 2 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vccq_sdhi0: regulator at 2 {
+		compatible = "regulator-gpio";
+
+		regulator-name = "SDHI0 VccQ";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
+		gpios-states = <1>;
+		states = <3300000 1
+			  1800000 0>;
+	};
+
+	vcc_sdhi3: regulator at 3 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "SDHI3 Vcc";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&gpio3 15 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+
+	vccq_sdhi3: regulator at 4 {
+		compatible = "regulator-gpio";
+
+		regulator-name = "SDHI3 VccQ";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpios = <&gpio3 14 GPIO_ACTIVE_HIGH>;
+		gpios-states = <1>;
+		states = <3300000 1
+			  1800000 0>;
+	};
+
 	audio_clkout: audio_clkout {
 		/*
 		 * This is same as <&rcar_sound 0>
@@ -119,6 +168,16 @@
 		renesas,function = "avb";
 	};
 
+	sdhi0_pins: sd0 {
+		renesas,groups = "sdhi0_data4", "sdhi0_ctrl";
+		renesas,function = "sdhi0";
+	};
+
+	sdhi3_pins: sd3 {
+		renesas,groups = "sdhi3_data4", "sdhi3_ctrl";
+		renesas,function = "sdhi3";
+	};
+
 	sound_pins: sound {
 		renesas,groups = "ssi01239_ctrl", "ssi0_data", "ssi1_data_a";
 		renesas,function = "ssi";
@@ -228,6 +287,30 @@
 	status = "okay";
 };
 
+&sdhi0 {
+	pinctrl-0 = <&sdhi0_pins>;
+	pinctrl-names = "default";
+
+	vmmc-supply = <&vcc_sdhi0>;
+	vqmmc-supply = <&vccq_sdhi0>;
+	cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
+	wp-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
+	bus-width = <4>;
+	status = "okay";
+};
+
+&sdhi3 {
+	pinctrl-0 = <&sdhi3_pins>;
+	pinctrl-names = "default";
+
+	vmmc-supply = <&vcc_sdhi3>;
+	vqmmc-supply = <&vccq_sdhi3>;
+	cd-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
+	wp-gpios = <&gpio4 16 GPIO_ACTIVE_HIGH>;
+	bus-width = <4>;
+	status = "okay";
+};
+
 &ssi1 {
 	shared-pin;
 };
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 16:07:43 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 09:07:43 +0900
Subject: [PATCH 10/14] arm64: dts: r8a7795: use fallback etheravb
 compatibility string
In-Reply-To: <cover.1456445161.git.horms+renesas@verge.net.au>
References: <cover.1456445161.git.horms+renesas@verge.net.au>
Message-ID: <2b953ccd0e11bc468ff7337c9ae66c97c7747396.1456445161.git.horms+renesas@verge.net.au>

Use recently added fallback compatibility string in r8a7795 device tree.

Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas at glider.be>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index c2bffd160c18..e9adb31cd48c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -473,7 +473,8 @@
 		};
 
 		avb: ethernet at e6800000 {
-			compatible = "renesas,etheravb-r8a7795";
+			compatible = "renesas,etheravb-r8a7795",
+				     "renesas,etheravb-rcar-gen3";
 			reg = <0 0xe6800000 0 0x800>, <0 0xe6a00000 0 0x10000>;
 			interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
 				     <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
-- 
2.7.0.rc3.207.g0ac5344



From horms+renesas at verge.net.au  Thu Feb 25 16:07:44 2016
From: horms+renesas at verge.net.au (Simon Horman)
Date: Fri, 26 Feb 2016 09:07:44 +0900
Subject: [PATCH 11/14] arm64: dts: r8a7795: add usb2_phy device nodes
In-Reply-To: <cover.1456445161.git.horms+renesas@verge.net.au>
References: <cover.1456445161.git.horms+renesas@verge.net.au>
Message-ID: <5923bb5227e5601a2e71da2b0d870b840bdfee9d.1456445161.git.horms+renesas@verge.net.au>

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>
Signed-off-by: Simon Horman <horms+renesas at verge.net.au>
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index e9adb31cd48c..c6e379000e90 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1024,5 +1024,33 @@
 			cap-mmc-highspeed;
 			status = "disabled";
 		};
+
+		usb2_phy0: usb-phy at ee080200 {
+			compatible = "renesas,usb2-phy-r8a7795";
+			reg = <0 0xee080200 0 0x700>;
+			interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_MOD 703>;
+			power-domains = <&cpg>;
+			#phy-cells = <0>;
+			status = "disabled";
+		};
+
+		usb2_phy1: usb-phy at ee0a0200 {
+			compatible = "renesas,usb2-phy-r8a7795";
+			reg = <0 0xee0a0200 0 0x700>;
+			clocks = <&cpg CPG_MOD 702>;
+			power-domains = <&cpg>;
+			#phy-cells = <0>;
+			status = "disabled";
+		};
+
+		usb2_phy2: usb-phy at ee0c0200 {
+			compatible = "renesas,usb2-phy-r8a7795";
+			reg = <0 0xee0c0200 0 0x700>;
+			clocks = <&cpg CPG_MOD 701>;
+			power-domains = <&cpg>;
+			#phy-cells = <0>;
+			status = "disabled";
+		};
 	};
 };
-- 
2.7.0.rc3.207.g0ac5344



From k.kozlowski at samsung.com  Thu Feb 25 16:09:38 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 26 Feb 2016 09:09:38 +0900
Subject: [GIT PULL 2/2] ARM64: EXYNOS: mach/soc changes for v4.6, 2nd
In-Reply-To: <1456445103-23314-2-git-send-email-k.kozlowski@samsung.com>
References: <1456445103-23314-1-git-send-email-k.kozlowski@samsung.com>
 <1456445103-23314-2-git-send-email-k.kozlowski@samsung.com>
Message-ID: <56CF97C2.5000305@samsung.com>

On 26.02.2016 09:05, Krzysztof Kozlowski wrote:
> Hi Arnd, Kevin and Olof,
> 
> 
> Pull request for v4.6 with ARM64 mach/soc changes.
> 
> This depends on change in clk tree (removal of ARCH_EXYNOS7) which is
> pulled here.
> 
> 
> Kind regards,
> Krzysztof
> 
> 
> Cc: Sylwester Nawrocki <s.nawrocki at samsung.com>
> Cc: Stephen Boyd <sboyd at codeaurora.org>
> Cc: Michael Turquette <mturquette at baylibre.com>
> 
> 
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc64-4.6-2
> 
> for you to fetch changes up to c87b3e970c70d5e27f9eb9acd09c6b5b9d589860:
> 
>   arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS (2016-02-23 08:49:46 +0900)

And for easier grepping through history, below is the pull request
for Exynos-specific change (no clk commits):


The following changes since commit 85997a7cba7bc1578eb554e88f82023d85fb499a:

  clk: samsung: Don't build ARMv8 clock drivers on ARMv7 (2016-02-22 10:20:24 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc64-4.6-2

for you to fetch changes up to c87b3e970c70d5e27f9eb9acd09c6b5b9d589860:

  arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS (2016-02-23 08:49:46 +0900)

----------------------------------------------------------------
Samsung Exynos ARM64 improvements for v4.6:
1. Remove separate ARCH_EXYNOS7 symbol and consolidate it into
   one ARCH_EXYNOS.
   This depends on clk tree: removal of last presence of ARCH_EXYNOS7.

----------------------------------------------------------------
Krzysztof Kozlowski (2):
      Merge branch 'clk-samsung' of git://git.kernel.org/.../clk/linux into next/soc64
      arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS

 arch/arm64/Kconfig.platforms        | 11 ++---------
 arch/arm64/boot/dts/exynos/Makefile |  2 +-
 arch/arm64/configs/defconfig        |  2 +-
 3 files changed, 4 insertions(+), 11 deletions(-)




From gregkh at linuxfoundation.org  Thu Feb 25 16:11:14 2016
From: gregkh at linuxfoundation.org (Greg KH)
Date: Fri, 26 Feb 2016 00:11:14 +0000
Subject: [PATCH] PCI: keystone: fix msi code that retrieves the pp struct
 ptr
In-Reply-To: <1456438984-22111-1-git-send-email-m-karicheri2@ti.com>
References: <1456438984-22111-1-git-send-email-m-karicheri2@ti.com>
Message-ID: <20160226001114.GA10923@kroah.com>

On Thu, Feb 25, 2016 at 05:23:04PM -0500, Murali Karicheri wrote:
> Recent update to pcie-designware core driver,
> commit "cbce79005 PCI: designware: Make driver arch-agnostic" broke the
> keystone PCI driver. This is because, the way pp struct ptr is retrieved
> from  msi desc has changed and require similar update in pci-keystone-dw.c
> as well. This patch fix this issue. Here is the early boot crash log seen
> on K2E EVM.
> 
> [    1.012999] pci 0000:00:00.0: PCI bridge to [bus 01]
> [    1.018073] pci 0000:00:00.0:   bridge window [io  0x1000-0x1fff]
> [    1.024308] pci 0000:00:00.0:   bridge window [mem 0x60000000-0x600fffff]
> [    1.031216] pci 0000:00:00.0:   bridge window [mem 0x60100000-0x601fffff
> pref]
> [    1.038736] Unable to handle kernel NULL pointer dereference at virtual
> address 00000030
> [    1.046950] pgd = c0003000
> [    1.049750] [00000030] *pgd=80000800004003, *pmd=00000000
> [    1.055265] Internal error: Oops: 206 [#1] PREEMPT SMP ARM
> [    1.060860] Modules linked in:
> [    1.064013] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.2-00139-gb74f926 #2
> [    1.071266] Hardware name: Keystone
> [    1.074853] task: eb888000 ti: eb890000 task.ti: eb890000
> [    1.080364] PC is at ks_dw_pcie_msi_irq_unmask+0x24/0x58
> [    1.085785] LR is at ks_dw_pcie_msi_irq_unmask+0x18/0x58
> [    1.091206] pc : [<c02f65c8>]    lr : [<c02f65bc>]    psr: 60000093
> [    1.091206] sp : eb891bc8  ip : 00000000  fp : ebb15010
> [    1.102915] r10: 00000051  r9 : 60000013  r8 : ebafaa20
> [    1.108247] r7 : ebaa9f80  r6 : eb9fd0c0  r5 : ebafa9d0  r4 : ebafa9c0
> [    1.114889] r3 : 00000051  r2 : 00000000  r1 : 00000001  r0 : ebb14c18
> [    1.121533] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment
> kernel
> [    1.129049] Control: 30c5387d  Table: 00003000  DAC: fffffffd
> [    1.134905] Process swapper/0 (pid: 1, stack limit = 0xeb890210)
> [    1.141023] Stack: (0xeb891bc8 to 0xeb892000)
> 
> Signed-off-by: Murali Karicheri <m-karicheri2 at ti.com>
> ---
>  - Need this fix in 4.4.4 as well

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

</formletter>


From ashwin.chaugule at linaro.org  Thu Feb 25 16:22:44 2016
From: ashwin.chaugule at linaro.org (Ashwin Chaugule)
Date: Thu, 25 Feb 2016 19:22:44 -0500
Subject: [PATCH] drivers: perf: arm: implement CPU_PM notifier
In-Reply-To: <20160224223128.GA30750@red-moon>
References: <1456251759-24768-1-git-send-email-lorenzo.pieralisi@arm.com>
 <CANLsYkzvB0GbPeYHrcLtUz8DMHJh4FA5RVwVZ-UAm3BCznB_3w@mail.gmail.com>
 <20160224173511.GF25385@red-moon>
 <CAJ5Y-ea3gxxOEGdJMPZAh78Ap0GBvzGePhBKzQRVoJBwwY6NzA@mail.gmail.com>
 <20160224223128.GA30750@red-moon>
Message-ID: <CAJ5Y-eYmYHU8Z+BBD0brmnx70ynWV8mhSrG36Bmu3yorsfk+4Q@mail.gmail.com>

On 24 February 2016 at 17:31, Lorenzo Pieralisi
<lorenzo.pieralisi at arm.com> wrote:
> On Wed, Feb 24, 2016 at 02:53:02PM -0500, Ashwin Chaugule wrote:
>> Hi Lorenzo,
>>
>> On 24 February 2016 at 12:35, Lorenzo Pieralisi
>> <lorenzo.pieralisi at arm.com> wrote:
>> > On Wed, Feb 24, 2016 at 09:20:22AM -0700, Mathieu Poirier wrote:
>> >> On 23 February 2016 at 11:22, Lorenzo Pieralisi
>> >
>> > [...]
>> >
>> >> > +static int cpu_pm_pmu_notify(struct notifier_block *b, unsigned long cmd,
>> >> > +                            void *v)
>> >> > +{
>> >> > +       struct arm_pmu *armpmu = container_of(b, struct arm_pmu, cpu_pm_nb);
>> >> > +       struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
>> >> > +       int enabled = bitmap_weight(hw_events->used_mask, armpmu->num_events);
>> >> > +
>> >> > +       if (!cpumask_test_cpu(smp_processor_id(), &armpmu->supported_cpus))
>> >> > +               return NOTIFY_DONE;
>> >> > +
>> >> > +       /*
>> >> > +        * Always reset the PMU registers on power-up even if
>> >> > +        * there are no events running.
>> >> > +        */
>> >> > +       if (cmd == CPU_PM_EXIT && armpmu->reset)
>> >> > +               armpmu->reset(armpmu);
>> >>
>> >> I think this patch does the right thing but I can't get the above
>> >> reset.  Wouldn't it be better to do the reset as part of the
>> >> CPU_PM_EXIT case below?  At this point nothing tells us the CPU won't
>> >> go back down before the event is enabled, wasting the cycle needed to
>> >> reset the PMU.
>> >
>> > The logic goes, if the cpu is woken up and it has no events enabled,
>> > if we do not reset it (mind, ->reset here sets the PMU register values
>> > to a sane default, some of them are architecturally UNKNOWN on reset, it
>> > does NOT reset the PMU) _and_ we subsequently install an event on it we
>> > do have a problem, that's why whenever a core gets out of low-power we
>> > have to reset its pmu.
>>
>> Dont we blow out the previous value in the counter when installing an
>> event? Or has that changed lately? IIRC, there was some initial value
>> we'd program into the counter to avoid missing the overflow event.
>> (sorry its been too long) ;)
>
> If you mean there is no need of resetting the value since we are
> overwriting it anyway you should see ->reset from a PMU unit POW
> not just an event. If you look at the ->reset method for eg v8, you
> will see that the reset method operates on all counters and the PMU
> unit as a whole, that's the only sane way of setting up the PMU unit
> before enabling single counters (some registers are UNKNOWN at reset).
>
> To make my reply to Mathieu clearer, the ->reset method contains
> operations (eg writing PMCR counters reset bits) that do carry out
> counters reset, what I wanted to say is that the ->reset method
> does not by itself drive the PMU HW reset signal, that's what the
> power controller does when it resets the CPU on power up.
>
> The PMU ->reset method must be called on a cpu on power-up, to make
> sure PMU HW is set-up to sane default values and ready to be used (ie
> install counters), for instance on v8 all counters must be disabled
> (irq inclusive) and reset, that's what armv8pmu_reset() does.
>
> I hope this makes things clearer.
>

Indeed. Thanks for the explanation. The patch looks good to me.

Acked-by: Ashwin Chaugule <ashwin.chaugule at linaro.org>


> Thanks,
> Lorenzo


From justinpopo6 at gmail.com  Thu Feb 25 16:19:07 2016
From: justinpopo6 at gmail.com (Justin Chen)
Date: Thu, 25 Feb 2016 16:19:07 -0800
Subject: [PATCH] bsp: add SoC device to brcmstb
Message-ID: <1456445947-9079-1-git-send-email-justinpopo6@gmail.com>

From: Justin Chen <justin.chen at broadcom.com>

Added SoC driver at drivers/soc/brcmstb/common.c. Added two
helper functions for getting family/product ID located at
include/linux/soc/brcmstb/brcmstb.h.

Assigned the values of soc_dev_attribute accordingly:
family = chip family id
soc_id = product id
revision = product revision

Signed-off-by: Justin Chen <justin.chen at broadcom.com>
---
 arch/arm/mach-bcm/Kconfig           |    1 +
 drivers/soc/brcmstb/common.c        |   68 +++++++++++++++++++++++++++++++++++
 include/linux/soc/brcmstb/brcmstb.h |    7 ++++
 3 files changed, 76 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 7ef1214..b95ea11 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -179,6 +179,7 @@ config ARCH_BRCMSTB
 	select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
 	select ARCH_WANT_OPTIONAL_GPIOLIB
 	select SOC_BRCMSTB
+	select SOC_BUS
 	help
 	  Say Y if you intend to run the kernel on a Broadcom ARM-based STB
 	  chipset.
diff --git a/drivers/soc/brcmstb/common.c b/drivers/soc/brcmstb/common.c
index c262c02..dd8cb42 100644
--- a/drivers/soc/brcmstb/common.c
+++ b/drivers/soc/brcmstb/common.c
@@ -12,10 +12,18 @@
  * GNU General Public License for more details.
  */
 
+#include <linux/io.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <linux/soc/brcmstb/brcmstb.h>
+#include <linux/sys_soc.h>
 
 #include <soc/brcmstb/common.h>
 
+static u32 family_id;
+static u32 product_id;
+
 static const struct of_device_id brcmstb_machine_match[] = {
 	{ .compatible = "brcm,brcmstb", },
 	{ }
@@ -31,3 +39,63 @@ bool soc_is_brcmstb(void)
 
 	return of_match_node(brcmstb_machine_match, root) != NULL;
 }
+
+u32 brcmstb_get_family_id(void)
+{
+	return family_id;
+}
+
+u32 brcmstb_get_product_id(void)
+{
+	return product_id;
+}
+
+static const struct of_device_id sun_top_ctrl_match[] = {
+	{ .compatible = "brcm,brcmstb-sun-top-ctrl", },
+	{ }
+};
+
+static int __init brcmstb_soc_device_init(void)
+{
+	struct soc_device_attribute *soc_dev_attr;
+	struct soc_device *soc_dev;
+	struct device_node *sun_top_ctrl;
+	void __iomem *sun_top_ctrl_base;
+
+	sun_top_ctrl = of_find_matching_node(NULL, sun_top_ctrl_match);
+	if (!sun_top_ctrl)
+		return -ENODEV;
+
+	sun_top_ctrl_base = of_iomap(sun_top_ctrl, 0);
+	if (!sun_top_ctrl_base)
+		return -ENODEV;
+
+	family_id = readl(sun_top_ctrl_base);
+	product_id = readl(sun_top_ctrl_base + 0x4);
+
+	soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+	if (!soc_dev_attr)
+		return -ENOMEM;
+
+	soc_dev_attr->family = kasprintf(GFP_KERNEL, "%x",
+					family_id >> 28 ?
+					family_id >> 16 : family_id >> 8);
+	soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "%x",
+					product_id >> 28 ?
+					product_id >> 16 : product_id >> 8);
+	soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%c%d",
+				    (char)(((product_id & 0xff) >> 4) + 65),
+				     product_id & 0xf);
+
+	soc_dev = soc_device_register(soc_dev_attr);
+	if (IS_ERR(soc_dev)) {
+		kfree(soc_dev_attr->family);
+		kfree(soc_dev_attr->soc_id);
+		kfree(soc_dev_attr->revision);
+		kfree(soc_dev_attr);
+		return -1;
+	}
+
+	return 0;
+}
+arch_initcall(brcmstb_soc_device_init);
diff --git a/include/linux/soc/brcmstb/brcmstb.h b/include/linux/soc/brcmstb/brcmstb.h
index 337ce41..ac10b0c 100644
--- a/include/linux/soc/brcmstb/brcmstb.h
+++ b/include/linux/soc/brcmstb/brcmstb.h
@@ -7,4 +7,11 @@
  */
 void brcmstb_biuctrl_init(void);
 
+/*
+ * Helper functions for getting family or product id from the
+ * SoC driver.
+ */
+u32 brcmstb_get_family_id(void);
+u32 brcmstb_get_product_id(void);
+
 #endif /* __BRCMSTB_SOC_H */
-- 
1.7.1



From itaru.kitayama at riken.jp  Thu Feb 25 16:23:56 2016
From: itaru.kitayama at riken.jp (Itaru Kitayama)
Date: Fri, 26 Feb 2016 09:23:56 +0900
Subject: [PATCH v3] ARM64: kernel: implement ACPI parking protocol
In-Reply-To: <20160225092427.GA31728@red-moon>
References: <1453806638-23167-1-git-send-email-lorenzo.pieralisi@arm.com>
 <20160202182657.GC15706@e104818-lin.cambridge.arm.com>
 <20160203112112.GA18387@red-moon> <20160203161834.GB26487@MBP.local>
 <20160224141832.GA26630@red-moon> <56CE3C9E.7070505@riken.jp>
 <20160225092427.GA31728@red-moon>
Message-ID: <56CF9B1C.6050303@riken.jp>

Hi Lorenzo,

I have applied your latest patch on top of today's HEAD of for-next/core 
(cac4b8cd),
and confirmed the kernel boots fine with acpi=force. No lockdep warning 
was seen,
all 8 CPUs were successfully brought up.

Itaru

On 2/25/16 6:24 PM, Lorenzo Pieralisi wrote:
> On Thu, Feb 25, 2016 at 08:28:30AM +0900, Itaru Kitayama wrote:
>> Lorenzo,
>>
>> On Mustang the lockdep warning I reported to you is disappeared and
>> the system gets to
>> the prompt as you implemented, however only 7 CPUs out of 8 brought up.
> It is because, as I mentioned in the other reply to this thread,
> the VA should be stashed before setting up the mailboxes, patch below,
> that should be final (I tested it on AMD Seattle too), please give it a go.
>
> Thanks,
> Lorenzo
>
> -- >8 --
> diff --git a/arch/arm64/kernel/acpi_parking_protocol.c b/arch/arm64/kernel/acpi_parking_protocol.c
> index 4b1e5a7..dd671ef 100644
> --- a/arch/arm64/kernel/acpi_parking_protocol.c
> +++ b/arch/arm64/kernel/acpi_parking_protocol.c
> @@ -21,7 +21,14 @@
>   
>   #include <asm/cpu_ops.h>
>   
> +struct parking_protocol_mailbox {
> +	__le32 cpu_id;
> +	__le32 reserved;
> +	__le64 entry_point;
> +};
> +
>   struct cpu_mailbox_entry {
> +	struct parking_protocol_mailbox __iomem *mailbox;
>   	phys_addr_t mailbox_addr;
>   	u8 version;
>   	u8 gic_cpu_id;
> @@ -59,12 +66,6 @@ static int acpi_parking_protocol_cpu_prepare(unsigned int cpu)
>   	return 0;
>   }
>   
> -struct parking_protocol_mailbox {
> -	__le32 cpu_id;
> -	__le32 reserved;
> -	__le64 entry_point;
> -};
> -
>   static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
>   {
>   	struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
> @@ -97,6 +98,12 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
>   	}
>   
>   	/*
> +	 * stash the mailbox address mapping to use it for further checks
> +	 * in postboot method
> +	 */
> +	cpu_entry->mailbox = mailbox;
> +
> +	/*
>   	 * We write the entry point and cpu id as LE regardless of the
>   	 * native endianness of the kernel. Therefore, any boot-loaders
>   	 * that read this address need to convert this address to the
> @@ -107,8 +114,6 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
>   
>   	arch_send_wakeup_ipi_mask(cpumask_of(cpu));
>   
> -	iounmap(mailbox);
> -
>   	return 0;
>   }
>   
> @@ -116,32 +121,15 @@ static void acpi_parking_protocol_cpu_postboot(void)
>   {
>   	int cpu = smp_processor_id();
>   	struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
> -	struct parking_protocol_mailbox __iomem *mailbox;
> +	struct parking_protocol_mailbox __iomem *mailbox = cpu_entry->mailbox;
>   	__le64 entry_point;
>   
> -	/*
> -	 * Map mailbox memory with attribute device nGnRE (ie ioremap -
> -	 * this deviates from the parking protocol specifications since
> -	 * the mailboxes are required to be mapped nGnRnE; the attribute
> -	 * discrepancy is harmless insofar as the protocol specification
> -	 * is concerned).
> -	 * If the mailbox is mistakenly allocated in the linear mapping
> -	 * by FW ioremap will fail since the mapping will be prevented
> -	 * by the kernel (it clashes with the linear mapping attributes
> -	 * specifications).
> -	 */
> -	mailbox = ioremap(cpu_entry->mailbox_addr, sizeof(*mailbox));
> -	if (!mailbox)
> -		return;
> -
>   	entry_point = readl_relaxed(&mailbox->entry_point);
>   	/*
>   	 * Check if firmware has cleared the entry_point as expected
>   	 * by the protocol specification.
>   	 */
>   	WARN_ON(entry_point);
> -
> -	iounmap(mailbox);
>   }
>   
>   const struct cpu_operations acpi_parking_protocol_ops = {



From k.kozlowski at samsung.com  Thu Feb 25 16:34:10 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 26 Feb 2016 09:34:10 +0900
Subject: [PATCH] arm64: defconfig: Enable exynos thermal config
In-Reply-To: <1456371249-10244-1-git-send-email-alim.akhtar@samsung.com>
References: <1456371249-10244-1-git-send-email-alim.akhtar@samsung.com>
Message-ID: <56CF9D82.9090808@samsung.com>

On 25.02.2016 12:34, Alim Akhtar wrote:
> This patch enables exynos thermal and related configs for the
> TMU found on exynos7 SoC. This also enables thermal emulation
> mode to test trip points.
> 
> Signed-off-by: Alim Akhtar <alim.akhtar at samsung.com>
> ---
>  arch/arm64/configs/defconfig |    3 +++
>  1 file changed, 3 insertions(+)

Thanks, applied.

Krzysztof



From k.kozlowski at samsung.com  Thu Feb 25 16:38:43 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 26 Feb 2016 09:38:43 +0900
Subject: [RESPIN/PATCH] arm64: dts: Add tmu node for exynos7
In-Reply-To: <1456391116-11553-1-git-send-email-alim.akhtar@samsung.com>
References: <1456391116-11553-1-git-send-email-alim.akhtar@samsung.com>
Message-ID: <56CF9E93.9090905@samsung.com>

On 25.02.2016 18:05, Alim Akhtar wrote:
> This patch adds tmu node, related temprature sensor and triping
> point data for Atlas cpu core found on exynos7 SoC.
> 
> Signed-off-by: Alim Akhtar <alim.akhtar at samsung.com>
> ---
> Change log:
> * no changes, just sending back from my email id.

All my comments from previous submission are still valid...

Best regards,
Krzysztof

> 
>  .../boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi   |   25 +++++++++
>  .../arm64/boot/dts/exynos/exynos7-trip-points.dtsi |   55 ++++++++++++++++++++
>  arch/arm64/boot/dts/exynos/exynos7.dtsi            |   20 +++++++
>  3 files changed, 100 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
>  create mode 100644 arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
> new file mode 100644
> index 0000000..1d6dcf2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
> @@ -0,0 +1,25 @@
> +/*
> + * Device tree sources for Exynos7 TMU sensor configuration
> + *
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + *		http://www.samsung.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.
> + *
> + */
> +
> +#include <dt-bindings/thermal/thermal_exynos.h>
> +
> +#thermal-sensor-cells = <0>;
> +samsung,tmu_gain = <9>;
> +samsung,tmu_reference_voltage = <17>;
> +samsung,tmu_noise_cancel_mode = <4>;
> +samsung,tmu_efuse_value = <75>;
> +samsung,tmu_min_efuse_value = <15>;
> +samsung,tmu_max_efuse_value = <100>;
> +samsung,tmu_first_point_trim = <25>;
> +samsung,tmu_second_point_trim = <85>;
> +samsung,tmu_default_temp_offset = <50>;
> +samsung,tmu_cal_type = <TYPE_ONE_POINT_TRIMMING>;
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
> new file mode 100644
> index 0000000..3970545
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
> @@ -0,0 +1,55 @@
> +/*
> + * Device tree sources for default Exynos7 thermal zone definition
> + *
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + *		http://www.samsung.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.
> + *
> + */
> +
> +trips {
> +	cpu-alert-0 {
> +		temperature = <75000>; /* millicelsius */
> +		hysteresis = <10000>; /* millicelsius */
> +		type = "passive";
> +	};
> +	cpu-alert-1 {
> +		temperature = <80000>; /* millicelsius */
> +		hysteresis = <10000>; /* millicelsius */
> +		type = "passive";
> +	};
> +	cpu-alert-2 {
> +		temperature = <85000>; /* millicelsius */
> +		hysteresis = <10000>; /* millicelsius */
> +		type = "passive";
> +	};
> +	cpu-alert-3 {
> +		temperature = <90000>; /* millicelsius */
> +		hysteresis = <10000>; /* millicelsius */
> +		type = "passive";
> +	};
> +	cpu-alert-4 {
> +		temperature = <95000>; /* millicelsius */
> +		hysteresis = <10000>; /* millicelsius */
> +		type = "passive";
> +	};
> +	cpu-alert-5 {
> +		temperature = <100000>; /* millicelsius */
> +		hysteresis = <10000>; /* millicelsius */
> +		type = "passive";
> +	};
> +	cpu-alert-6 {
> +		temperature = <110000>; /* millicelsius */
> +		hysteresis = <10000>; /* millicelsius */
> +		type = "passive";
> +	};
> +	/* HW Trip point */
> +	cpu-crit-0 {
> +		temperature = <115000>; /* millicelsius */
> +		hysteresis = <0>; /* millicelsius */
> +		type = "critical";
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> index c662f98..fc9d130 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -27,6 +27,7 @@
>  		pinctrl6 = &pinctrl_fsys0;
>  		pinctrl7 = &pinctrl_fsys1;
>  		pinctrl8 = &pinctrl_bus1;
> +		tmuctrl0 = &tmuctrl_0;
>  	};
>  
>  	cpus {
> @@ -538,6 +539,25 @@
>  			clocks = <&clock_peric0 PCLK_PWM>;
>  			clock-names = "timers";
>  		};
> +
> +		tmuctrl_0: tmu at 10060000 {
> +			compatible = "samsung,exynos7-tmu";
> +			reg = <0x10060000 0x200>;
> +			interrupts = <0 108 0>;
> +			clocks = <&clock_peris PCLK_TMU>,
> +				 <&clock_peris SCLK_TMU>;
> +			clock-names = "tmu_apbif", "tmu_sclk";
> +			#include "exynos7-tmu-sensor-conf.dtsi"
> +		};
> +
> +		thermal-zones {
> +			atlas_thermal: atlas-thermal {
> +				polling-delay-passive = <0>; /* milliseconds */
> +				polling-delay = <0>; /* milliseconds */
> +				thermal-sensors = <&tmuctrl_0>;
> +				#include "exynos7-trip-points.dtsi"
> +			};
> +		};
>  	};
>  };
>  
> 



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:08 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:08 +0100
Subject: [PATCH v3 00/52] mtd: rework ECC layout definition
Message-ID: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>

Hello,

This patchset aims at getting rid of the nand_ecclayout limitations.
struct nand_ecclayout is defining fixed eccpos and oobfree arrays which
can only be increased by modifying the MTD_MAX_ECCPOS_ENTRIES_LARGE and
MTD_MAX_OOBFREE_ENTRIES_LARGE macros.
This approach forces us to modify the macro values each time we add a
new NAND chip with a bigger OOB area, and increasing these arrays also
penalize all platforms, even those who only support small NAND devices
(with small OOB area).

The idea to overcome this limitation, is to define the ECC/OOB layout
by the mean of two functions: ->ecc() and ->free(), which will
basically return the same information has those stored in the
nand_ecclayout struct.

Another advantage of this solution is that ECC layouts are usually
following a repetitive pattern (i.e. leave X bytes free and put Y bytes
of ECC per ECC chunk), which allows one to implement the ->ecc()
and ->free() functions with a simple logic that can be applied
to any size of OOB.

Patches 1 to 4 are just cleanups or trivial fixes that can be taken
independently.

Also note that the last two commits are removing the nand_ecclayout
definition, thus preventing any new driver to use this structure.
Of course, this step can be delayed if some of the previous patches
are not accepted.

Best Regards,

Boris

Changes since v2:
- fixed a few bugs in the core and driver implementations

Changes since v1:
- unified the way of defining ECC and free bytes
- fixed a few bugs in some ->ecc()/->free() implementations
- added new helpers to ease ECC and free bytes manipulation
- separated driver changes in different commits to ease review
- dropped already applied patches

*** BLURB HERE ***

Boris Brezillon (52):
  mtd: kill the ecclayout->oobavail field
  mtd: create an mtd_oobavail() helper and make use of it
  mtd: mtdswap: remove useless if (!mtd->ecclayout) test
  mtd: nand: simplify nand_bch_init() usage
  mtd: add mtd_ooblayout_xxx() helper functions
  mtd: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: core: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: atmel: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: fsl_ifc: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: gpmi: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: lpc32xx: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: onenand: use mtd_ooblayout_xxx() helpers where appropriate
  mtd: add mtd_set_ecclayout() helper function
  mtd: use mtd_set_ecclayout() where appropriate
  mtd: nand: use mtd_set_ecclayout() where appropriate
  mtd: onenand: use mtd_set_ecclayout() where appropriate
  mtd: docg3: use mtd_set_ecclayout() where appropriate
  mtd: create an mtd_ooblayout_ops struct to ease ECC layout definition
  mtd: docg3: switch to mtd_ooblayout_ops
  mtd: nand: implement the default mtd_ooblayout_ops
  mtd: nand: bch: switch to mtd_ooblayout_ops
  mtd: nand: sharpsl: switch to mtd_ooblayout_ops
  mtd: nand: jz4740: switch to mtd_ooblayout_ops
  mtd: nand: atmel: switch to mtd_ooblayout_ops
  mtd: nand: bf5xx: switch to mtd_ooblayout_ops
  mtd: nand: brcm: switch to mtd_ooblayout_ops
  mtd: nand: cafe: switch to mtd_ooblayout_ops
  mtd: nand: davinci: switch to mtd_ooblayout_ops
  mtd: nand: denali: switch to mtd_ooblayout_ops
  mtd: nand: diskonchip: switch to mtd_ooblayout_ops
  mtd: nand: docg4: switch to mtd_ooblayout_ops
  mtd: nand: fsl_elbc: switch to mtd_ooblayout_ops
  mtd: nand: fsl_ifc: switch to mtd_ooblayout_ops
  mtd: nand: fsmc: switch to mtd_ooblayout_ops
  mtd: nand: fsmc: get rid of the fsmc_nand_eccplace struct
  mtd: nand: gpmi: switch to mtd_ooblayout_ops
  mtd: nand: hisi504: switch to mtd_ooblayout_ops
  mtd: nand: jz4780: switch to mtd_ooblayout_ops
  mtd: nand: lpc32xx: switch to mtd_ooblayout_ops
  mtd: nand: mxc: switch to mtd_ooblayout_ops
  mtd: nand: omap2: switch to mtd_ooblayout_ops
  mtd: nand: pxa3xx: switch to mtd_ooblayout_ops
  mtd: nand: s3c2410: switch to mtd_ooblayout_ops
  mtd: nand: sh_flctl: switch to mtd_ooblayout_ops
  mtd: nand: sm_common: switch to mtd_ooblayout_ops
  mtd: nand: sunxi: switch to mtd_ooblayout_ops
  mtd: nand: vf610: switch to mtd_ooblayout_ops
  mtd: onenand: switch to mtd_ooblayout_ops
  staging: mt29f_spinand: switch to mtd_ooblayout_ops
  mtd: nand: kill the ecc->layout field
  mtd: kill the nand_ecclayout struct

 arch/arm/mach-pxa/spitz.c                       |  55 +++-
 arch/mips/include/asm/mach-jz4740/jz4740_nand.h |   2 +-
 arch/mips/jz4740/board-qi_lb60.c                |  87 +++---
 drivers/mtd/devices/docg3.c                     |  51 +++-
 drivers/mtd/mtdchar.c                           | 123 ++++++--
 drivers/mtd/mtdconcat.c                         |   2 +-
 drivers/mtd/mtdcore.c                           | 358 ++++++++++++++++++++++++
 drivers/mtd/mtdpart.c                           |  28 +-
 drivers/mtd/mtdswap.c                           |  24 +-
 drivers/mtd/nand/atmel_nand.c                   | 130 ++++-----
 drivers/mtd/nand/bf5xx_nand.c                   |  51 ++--
 drivers/mtd/nand/brcmnand/brcmnand.c            | 262 ++++++++++-------
 drivers/mtd/nand/cafe_nand.c                    |  45 ++-
 drivers/mtd/nand/davinci_nand.c                 | 118 +++-----
 drivers/mtd/nand/denali.c                       |  51 +++-
 drivers/mtd/nand/diskonchip.c                   |  60 +++-
 drivers/mtd/nand/docg4.c                        |  34 ++-
 drivers/mtd/nand/fsl_elbc_nand.c                |  83 +++---
 drivers/mtd/nand/fsl_ifc_nand.c                 | 245 +++++-----------
 drivers/mtd/nand/fsmc_nand.c                    | 322 ++++++---------------
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c          |  61 ++--
 drivers/mtd/nand/hisi504_nand.c                 |  27 +-
 drivers/mtd/nand/jz4740_nand.c                  |   2 +-
 drivers/mtd/nand/jz4780_nand.c                  |  19 +-
 drivers/mtd/nand/lpc32xx_mlc.c                  |  50 ++--
 drivers/mtd/nand/lpc32xx_slc.c                  |  58 +++-
 drivers/mtd/nand/mxc_nand.c                     | 212 +++++++-------
 drivers/mtd/nand/nand_base.c                    | 344 ++++++++++++-----------
 drivers/mtd/nand/nand_bch.c                     |  46 ++-
 drivers/mtd/nand/omap2.c                        | 241 +++++++++-------
 drivers/mtd/nand/pxa3xx_nand.c                  | 104 ++++---
 drivers/mtd/nand/s3c2410.c                      |  32 ++-
 drivers/mtd/nand/sh_flctl.c                     |  87 ++++--
 drivers/mtd/nand/sharpsl.c                      |   2 +-
 drivers/mtd/nand/sm_common.c                    |  93 ++++--
 drivers/mtd/nand/sunxi_nand.c                   | 114 ++++----
 drivers/mtd/nand/vf610_nfc.c                    |  34 +--
 drivers/mtd/onenand/onenand_base.c              | 262 ++++++++---------
 drivers/mtd/tests/oobtest.c                     |  49 ++--
 drivers/staging/mt29f_spinand/mt29f_spinand.c   |  49 ++--
 fs/jffs2/wbuf.c                                 |   6 +-
 include/linux/mtd/fsmc.h                        |  18 --
 include/linux/mtd/mtd.h                         |  69 ++++-
 include/linux/mtd/nand.h                        |   5 +-
 include/linux/mtd/nand_bch.h                    |   8 +-
 include/linux/mtd/onenand.h                     |   2 -
 include/linux/mtd/sharpsl.h                     |   2 +-
 include/uapi/mtd/mtd-abi.h                      |   2 +-
 48 files changed, 2375 insertions(+), 1754 deletions(-)

-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:09 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:09 +0100
Subject: [PATCH v3 01/52] mtd: kill the ecclayout->oobavail field
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-2-git-send-email-boris.brezillon@free-electrons.com>

ecclayout->oobavail is just redundant with the mtd->oobavail field.
Moreover, it prevents static const definition of ecc layouts since the
NAND framework is calculating this value based on the ecclayout->oobfree
field.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/devices/docg3.c                   |  5 ++-
 drivers/mtd/mtdswap.c                         | 16 ++++-----
 drivers/mtd/nand/brcmnand/brcmnand.c          |  8 ++---
 drivers/mtd/nand/docg4.c                      |  1 -
 drivers/mtd/nand/hisi504_nand.c               |  1 -
 drivers/mtd/nand/nand_base.c                  | 14 ++++----
 drivers/mtd/onenand/onenand_base.c            | 16 ++++-----
 drivers/mtd/tests/oobtest.c                   | 49 +++++++++++++--------------
 drivers/staging/mt29f_spinand/mt29f_spinand.c |  1 -
 fs/jffs2/wbuf.c                               |  6 ++--
 include/linux/mtd/mtd.h                       |  1 -
 11 files changed, 53 insertions(+), 65 deletions(-)

diff --git a/drivers/mtd/devices/docg3.c b/drivers/mtd/devices/docg3.c
index c3a2695..e7b2e43 100644
--- a/drivers/mtd/devices/docg3.c
+++ b/drivers/mtd/devices/docg3.c
@@ -72,13 +72,11 @@ MODULE_PARM_DESC(reliable_mode, "Set the docg3 mode (0=normal MLC, 1=fast, "
  * @eccbytes: 8 bytes are used (1 for Hamming ECC, 7 for BCH ECC)
  * @eccpos: ecc positions (byte 7 is Hamming ECC, byte 8-14 are BCH ECC)
  * @oobfree: free pageinfo bytes (byte 0 until byte 6, byte 15
- * @oobavail: 8 available bytes remaining after ECC toll
  */
 static struct nand_ecclayout docg3_oobinfo = {
 	.eccbytes = 8,
 	.eccpos = {7, 8, 9, 10, 11, 12, 13, 14},
 	.oobfree = {{0, 7}, {15, 1} },
-	.oobavail = 8,
 };
 
 static inline u8 doc_readb(struct docg3 *docg3, u16 reg)
@@ -1438,7 +1436,7 @@ static int doc_write_oob(struct mtd_info *mtd, loff_t ofs,
 		oobdelta = mtd->oobsize;
 		break;
 	case MTD_OPS_AUTO_OOB:
-		oobdelta = mtd->ecclayout->oobavail;
+		oobdelta = mtd->oobavail;
 		break;
 	default:
 		return -EINVAL;
@@ -1860,6 +1858,7 @@ static int __init doc_set_driver_info(int chip_id, struct mtd_info *mtd)
 	mtd->_write_oob = doc_write_oob;
 	mtd->_block_isbad = doc_block_isbad;
 	mtd->ecclayout = &docg3_oobinfo;
+	mtd->oobavail = 8;
 	mtd->ecc_strength = DOC_ECC_BCH_T;
 
 	return 0;
diff --git a/drivers/mtd/mtdswap.c b/drivers/mtd/mtdswap.c
index fc8b3d1..d330eb1 100644
--- a/drivers/mtd/mtdswap.c
+++ b/drivers/mtd/mtdswap.c
@@ -346,7 +346,7 @@ static int mtdswap_read_markers(struct mtdswap_dev *d, struct swap_eb *eb)
 	if (mtd_can_have_bb(d->mtd) && mtd_block_isbad(d->mtd, offset))
 		return MTDSWAP_SCANNED_BAD;
 
-	ops.ooblen = 2 * d->mtd->ecclayout->oobavail;
+	ops.ooblen = 2 * d->mtd->oobavail;
 	ops.oobbuf = d->oob_buf;
 	ops.ooboffs = 0;
 	ops.datbuf = NULL;
@@ -359,7 +359,7 @@ static int mtdswap_read_markers(struct mtdswap_dev *d, struct swap_eb *eb)
 
 	data = (struct mtdswap_oobdata *)d->oob_buf;
 	data2 = (struct mtdswap_oobdata *)
-		(d->oob_buf + d->mtd->ecclayout->oobavail);
+		(d->oob_buf + d->mtd->oobavail);
 
 	if (le16_to_cpu(data->magic) == MTDSWAP_MAGIC_CLEAN) {
 		eb->erase_count = le32_to_cpu(data->count);
@@ -933,7 +933,7 @@ static unsigned int mtdswap_eblk_passes(struct mtdswap_dev *d,
 
 	ops.mode = MTD_OPS_AUTO_OOB;
 	ops.len = mtd->writesize;
-	ops.ooblen = mtd->ecclayout->oobavail;
+	ops.ooblen = mtd->oobavail;
 	ops.ooboffs = 0;
 	ops.datbuf = d->page_buf;
 	ops.oobbuf = d->oob_buf;
@@ -945,7 +945,7 @@ static unsigned int mtdswap_eblk_passes(struct mtdswap_dev *d,
 		for (i = 0; i < mtd_pages; i++) {
 			patt = mtdswap_test_patt(test + i);
 			memset(d->page_buf, patt, mtd->writesize);
-			memset(d->oob_buf, patt, mtd->ecclayout->oobavail);
+			memset(d->oob_buf, patt, mtd->oobavail);
 			ret = mtd_write_oob(mtd, pos, &ops);
 			if (ret)
 				goto error;
@@ -964,7 +964,7 @@ static unsigned int mtdswap_eblk_passes(struct mtdswap_dev *d,
 				if (p1[j] != patt)
 					goto error;
 
-			for (j = 0; j < mtd->ecclayout->oobavail; j++)
+			for (j = 0; j < mtd->oobavail; j++)
 				if (p2[j] != (unsigned char)patt)
 					goto error;
 
@@ -1387,7 +1387,7 @@ static int mtdswap_init(struct mtdswap_dev *d, unsigned int eblocks,
 	if (!d->page_buf)
 		goto page_buf_fail;
 
-	d->oob_buf = kmalloc(2 * mtd->ecclayout->oobavail, GFP_KERNEL);
+	d->oob_buf = kmalloc(2 * mtd->oobavail, GFP_KERNEL);
 	if (!d->oob_buf)
 		goto oob_buf_fail;
 
@@ -1454,10 +1454,10 @@ static void mtdswap_add_mtd(struct mtd_blktrans_ops *tr, struct mtd_info *mtd)
 		return;
 	}
 
-	if (!mtd->oobsize || oinfo->oobavail < MTDSWAP_OOBSIZE) {
+	if (!mtd->oobsize || mtd->oobavail < MTDSWAP_OOBSIZE) {
 		printk(KERN_ERR "%s: Not enough free bytes in OOB, "
 			"%d available, %zu needed.\n",
-			MTDSWAP_PREFIX, oinfo->oobavail, MTDSWAP_OOBSIZE);
+			MTDSWAP_PREFIX, mtd->oobavail, MTDSWAP_OOBSIZE);
 		return;
 	}
 
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c
index f7009c1..e052839 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -828,7 +828,8 @@ static struct nand_ecclayout *brcmnand_create_layout(int ecc_level,
 				    idx2 >= MTD_MAX_OOBFREE_ENTRIES_LARGE - 1)
 				break;
 		}
-		goto out;
+
+		return layout;
 	}
 
 	/*
@@ -879,10 +880,7 @@ static struct nand_ecclayout *brcmnand_create_layout(int ecc_level,
 				idx2 >= MTD_MAX_OOBFREE_ENTRIES_LARGE - 1)
 			break;
 	}
-out:
-	/* Sum available OOB */
-	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES_LARGE; i++)
-		layout->oobavail += layout->oobfree[i].length;
+
 	return layout;
 }
 
diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c
index df4165b..fb46fd7 100644
--- a/drivers/mtd/nand/docg4.c
+++ b/drivers/mtd/nand/docg4.c
@@ -225,7 +225,6 @@ struct docg4_priv {
 static struct nand_ecclayout docg4_oobinfo = {
 	.eccbytes = 9,
 	.eccpos = {7, 8, 9, 10, 11, 12, 13, 14, 15},
-	.oobavail = 5,
 	.oobfree = { {.offset = 2, .length = 5} }
 };
 
diff --git a/drivers/mtd/nand/hisi504_nand.c b/drivers/mtd/nand/hisi504_nand.c
index f8d37f3..96502b6 100644
--- a/drivers/mtd/nand/hisi504_nand.c
+++ b/drivers/mtd/nand/hisi504_nand.c
@@ -632,7 +632,6 @@ static void hisi_nfc_host_init(struct hinfc_host *host)
 }
 
 static struct nand_ecclayout nand_ecc_2K_16bits = {
-	.oobavail = 6,
 	.oobfree = { {2, 6} },
 };
 
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index f2c8ff3..9f49d3e 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2076,7 +2076,7 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
 	stats = mtd->ecc_stats;
 
 	if (ops->mode == MTD_OPS_AUTO_OOB)
-		len = chip->ecc.layout->oobavail;
+		len = mtd->oobavail;
 	else
 		len = mtd->oobsize;
 
@@ -2767,7 +2767,7 @@ static int nand_do_write_oob(struct mtd_info *mtd, loff_t to,
 			 __func__, (unsigned int)to, (int)ops->ooblen);
 
 	if (ops->mode == MTD_OPS_AUTO_OOB)
-		len = chip->ecc.layout->oobavail;
+		len = mtd->oobavail;
 	else
 		len = mtd->oobsize;
 
@@ -4325,11 +4325,11 @@ int nand_scan_tail(struct mtd_info *mtd)
 	 * The number of bytes available for a client to place data into
 	 * the out of band area.
 	 */
-	ecc->layout->oobavail = 0;
-	for (i = 0; ecc->layout->oobfree[i].length
-			&& i < ARRAY_SIZE(ecc->layout->oobfree); i++)
-		ecc->layout->oobavail += ecc->layout->oobfree[i].length;
-	mtd->oobavail = ecc->layout->oobavail;
+	mtd->oobavail = 0;
+	if (ecc->layout) {
+		for (i = 0; ecc->layout->oobfree[i].length; i++)
+			mtd->oobavail += ecc->layout->oobfree[i].length;
+	}
 
 	/* ECC sanity check: warn if it's too weak */
 	if (!nand_ecc_strength_good(mtd))
diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index 652d018..df47537 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1125,7 +1125,7 @@ static int onenand_mlc_read_ops_nolock(struct mtd_info *mtd, loff_t from,
 			(int)len);
 
 	if (ops->mode == MTD_OPS_AUTO_OOB)
-		oobsize = this->ecclayout->oobavail;
+		oobsize = mtd->oobavail;
 	else
 		oobsize = mtd->oobsize;
 
@@ -1230,7 +1230,7 @@ static int onenand_read_ops_nolock(struct mtd_info *mtd, loff_t from,
 			(int)len);
 
 	if (ops->mode == MTD_OPS_AUTO_OOB)
-		oobsize = this->ecclayout->oobavail;
+		oobsize = mtd->oobavail;
 	else
 		oobsize = mtd->oobsize;
 
@@ -1365,7 +1365,7 @@ static int onenand_read_oob_nolock(struct mtd_info *mtd, loff_t from,
 	ops->oobretlen = 0;
 
 	if (mode == MTD_OPS_AUTO_OOB)
-		oobsize = this->ecclayout->oobavail;
+		oobsize = mtd->oobavail;
 	else
 		oobsize = mtd->oobsize;
 
@@ -1887,7 +1887,7 @@ static int onenand_write_ops_nolock(struct mtd_info *mtd, loff_t to,
 		return 0;
 
 	if (ops->mode == MTD_OPS_AUTO_OOB)
-		oobsize = this->ecclayout->oobavail;
+		oobsize = mtd->oobavail;
 	else
 		oobsize = mtd->oobsize;
 
@@ -2063,7 +2063,7 @@ static int onenand_write_oob_nolock(struct mtd_info *mtd, loff_t to,
 	ops->oobretlen = 0;
 
 	if (mode == MTD_OPS_AUTO_OOB)
-		oobsize = this->ecclayout->oobavail;
+		oobsize = mtd->oobavail;
 	else
 		oobsize = mtd->oobsize;
 
@@ -4050,12 +4050,10 @@ int onenand_scan(struct mtd_info *mtd, int maxchips)
 	 * The number of bytes available for a client to place data into
 	 * the out of band area
 	 */
-	this->ecclayout->oobavail = 0;
+	mtd->oobavail = 0;
 	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES &&
 	    this->ecclayout->oobfree[i].length; i++)
-		this->ecclayout->oobavail +=
-			this->ecclayout->oobfree[i].length;
-	mtd->oobavail = this->ecclayout->oobavail;
+		mtd->oobavail += this->ecclayout->oobfree[i].length;
 
 	mtd->ecclayout = this->ecclayout;
 	mtd->ecc_strength = 1;
diff --git a/drivers/mtd/tests/oobtest.c b/drivers/mtd/tests/oobtest.c
index 3176212..1cb3f77 100644
--- a/drivers/mtd/tests/oobtest.c
+++ b/drivers/mtd/tests/oobtest.c
@@ -215,19 +215,19 @@ static int verify_eraseblock(int ebnum)
 			pr_info("ignoring error as within bitflip_limit\n");
 		}
 
-		if (use_offset != 0 || use_len < mtd->ecclayout->oobavail) {
+		if (use_offset != 0 || use_len < mtd->oobavail) {
 			int k;
 
 			ops.mode      = MTD_OPS_AUTO_OOB;
 			ops.len       = 0;
 			ops.retlen    = 0;
-			ops.ooblen    = mtd->ecclayout->oobavail;
+			ops.ooblen    = mtd->oobavail;
 			ops.oobretlen = 0;
 			ops.ooboffs   = 0;
 			ops.datbuf    = NULL;
 			ops.oobbuf    = readbuf;
 			err = mtd_read_oob(mtd, addr, &ops);
-			if (err || ops.oobretlen != mtd->ecclayout->oobavail) {
+			if (err || ops.oobretlen != mtd->oobavail) {
 				pr_err("error: readoob failed at %#llx\n",
 						(long long)addr);
 				errcnt += 1;
@@ -244,7 +244,7 @@ static int verify_eraseblock(int ebnum)
 			/* verify post-(use_offset + use_len) area for 0xff */
 			k = use_offset + use_len;
 			bitflips += memffshow(addr, k, readbuf + k,
-					      mtd->ecclayout->oobavail - k);
+					      mtd->oobavail - k);
 
 			if (bitflips > bitflip_limit) {
 				pr_err("error: verify failed at %#llx\n",
@@ -269,8 +269,8 @@ static int verify_eraseblock_in_one_go(int ebnum)
 	struct mtd_oob_ops ops;
 	int err = 0;
 	loff_t addr = (loff_t)ebnum * mtd->erasesize;
-	size_t len = mtd->ecclayout->oobavail * pgcnt;
-	size_t oobavail = mtd->ecclayout->oobavail;
+	size_t len = mtd->oobavail * pgcnt;
+	size_t oobavail = mtd->oobavail;
 	size_t bitflips;
 	int i;
 
@@ -394,8 +394,8 @@ static int __init mtd_oobtest_init(void)
 		goto out;
 
 	use_offset = 0;
-	use_len = mtd->ecclayout->oobavail;
-	use_len_max = mtd->ecclayout->oobavail;
+	use_len = mtd->oobavail;
+	use_len_max = mtd->oobavail;
 	vary_offset = 0;
 
 	/* First test: write all OOB, read it back and verify */
@@ -460,8 +460,8 @@ static int __init mtd_oobtest_init(void)
 
 	/* Write all eraseblocks */
 	use_offset = 0;
-	use_len = mtd->ecclayout->oobavail;
-	use_len_max = mtd->ecclayout->oobavail;
+	use_len = mtd->oobavail;
+	use_len_max = mtd->oobavail;
 	vary_offset = 1;
 	prandom_seed_state(&rnd_state, 5);
 
@@ -471,8 +471,8 @@ static int __init mtd_oobtest_init(void)
 
 	/* Check all eraseblocks */
 	use_offset = 0;
-	use_len = mtd->ecclayout->oobavail;
-	use_len_max = mtd->ecclayout->oobavail;
+	use_len = mtd->oobavail;
+	use_len_max = mtd->oobavail;
 	vary_offset = 1;
 	prandom_seed_state(&rnd_state, 5);
 	err = verify_all_eraseblocks();
@@ -480,8 +480,8 @@ static int __init mtd_oobtest_init(void)
 		goto out;
 
 	use_offset = 0;
-	use_len = mtd->ecclayout->oobavail;
-	use_len_max = mtd->ecclayout->oobavail;
+	use_len = mtd->oobavail;
+	use_len_max = mtd->oobavail;
 	vary_offset = 0;
 
 	/* Fourth test: try to write off end of device */
@@ -501,7 +501,7 @@ static int __init mtd_oobtest_init(void)
 	ops.retlen    = 0;
 	ops.ooblen    = 1;
 	ops.oobretlen = 0;
-	ops.ooboffs   = mtd->ecclayout->oobavail;
+	ops.ooboffs   = mtd->oobavail;
 	ops.datbuf    = NULL;
 	ops.oobbuf    = writebuf;
 	pr_info("attempting to start write past end of OOB\n");
@@ -521,7 +521,7 @@ static int __init mtd_oobtest_init(void)
 	ops.retlen    = 0;
 	ops.ooblen    = 1;
 	ops.oobretlen = 0;
-	ops.ooboffs   = mtd->ecclayout->oobavail;
+	ops.ooboffs   = mtd->oobavail;
 	ops.datbuf    = NULL;
 	ops.oobbuf    = readbuf;
 	pr_info("attempting to start read past end of OOB\n");
@@ -543,7 +543,7 @@ static int __init mtd_oobtest_init(void)
 		ops.mode      = MTD_OPS_AUTO_OOB;
 		ops.len       = 0;
 		ops.retlen    = 0;
-		ops.ooblen    = mtd->ecclayout->oobavail + 1;
+		ops.ooblen    = mtd->oobavail + 1;
 		ops.oobretlen = 0;
 		ops.ooboffs   = 0;
 		ops.datbuf    = NULL;
@@ -563,7 +563,7 @@ static int __init mtd_oobtest_init(void)
 		ops.mode      = MTD_OPS_AUTO_OOB;
 		ops.len       = 0;
 		ops.retlen    = 0;
-		ops.ooblen    = mtd->ecclayout->oobavail + 1;
+		ops.ooblen    = mtd->oobavail + 1;
 		ops.oobretlen = 0;
 		ops.ooboffs   = 0;
 		ops.datbuf    = NULL;
@@ -587,7 +587,7 @@ static int __init mtd_oobtest_init(void)
 		ops.mode      = MTD_OPS_AUTO_OOB;
 		ops.len       = 0;
 		ops.retlen    = 0;
-		ops.ooblen    = mtd->ecclayout->oobavail;
+		ops.ooblen    = mtd->oobavail;
 		ops.oobretlen = 0;
 		ops.ooboffs   = 1;
 		ops.datbuf    = NULL;
@@ -607,7 +607,7 @@ static int __init mtd_oobtest_init(void)
 		ops.mode      = MTD_OPS_AUTO_OOB;
 		ops.len       = 0;
 		ops.retlen    = 0;
-		ops.ooblen    = mtd->ecclayout->oobavail;
+		ops.ooblen    = mtd->oobavail;
 		ops.oobretlen = 0;
 		ops.ooboffs   = 1;
 		ops.datbuf    = NULL;
@@ -638,7 +638,7 @@ static int __init mtd_oobtest_init(void)
 	for (i = 0; i < ebcnt - 1; ++i) {
 		int cnt = 2;
 		int pg;
-		size_t sz = mtd->ecclayout->oobavail;
+		size_t sz = mtd->oobavail;
 		if (bbt[i] || bbt[i + 1])
 			continue;
 		addr = (loff_t)(i + 1) * mtd->erasesize - mtd->writesize;
@@ -673,13 +673,12 @@ static int __init mtd_oobtest_init(void)
 	for (i = 0; i < ebcnt - 1; ++i) {
 		if (bbt[i] || bbt[i + 1])
 			continue;
-		prandom_bytes_state(&rnd_state, writebuf,
-					mtd->ecclayout->oobavail * 2);
+		prandom_bytes_state(&rnd_state, writebuf, mtd->oobavail * 2);
 		addr = (loff_t)(i + 1) * mtd->erasesize - mtd->writesize;
 		ops.mode      = MTD_OPS_AUTO_OOB;
 		ops.len       = 0;
 		ops.retlen    = 0;
-		ops.ooblen    = mtd->ecclayout->oobavail * 2;
+		ops.ooblen    = mtd->oobavail * 2;
 		ops.oobretlen = 0;
 		ops.ooboffs   = 0;
 		ops.datbuf    = NULL;
@@ -688,7 +687,7 @@ static int __init mtd_oobtest_init(void)
 		if (err)
 			goto out;
 		if (memcmpshow(addr, readbuf, writebuf,
-			       mtd->ecclayout->oobavail * 2)) {
+			       mtd->oobavail * 2)) {
 			pr_err("error: verify failed at %#llx\n",
 			       (long long)addr);
 			errcnt += 1;
diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c b/drivers/staging/mt29f_spinand/mt29f_spinand.c
index 197d112..6728376 100644
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -49,7 +49,6 @@ static struct nand_ecclayout spinand_oob_64 = {
 		17, 18, 19, 20, 21, 22,
 		33, 34, 35, 36, 37, 38,
 		49, 50, 51, 52, 53, 54, },
-	.oobavail = 32,
 	.oobfree = {
 		{.offset = 8,
 			.length = 8},
diff --git a/fs/jffs2/wbuf.c b/fs/jffs2/wbuf.c
index 5a3da3f..b25d28a 100644
--- a/fs/jffs2/wbuf.c
+++ b/fs/jffs2/wbuf.c
@@ -1183,22 +1183,20 @@ void jffs2_dirty_trigger(struct jffs2_sb_info *c)
 
 int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
 {
-	struct nand_ecclayout *oinfo = c->mtd->ecclayout;
-
 	if (!c->mtd->oobsize)
 		return 0;
 
 	/* Cleanmarker is out-of-band, so inline size zero */
 	c->cleanmarker_size = 0;
 
-	if (!oinfo || oinfo->oobavail == 0) {
+	if (c->mtd->oobavail == 0) {
 		pr_err("inconsistent device description\n");
 		return -EINVAL;
 	}
 
 	jffs2_dbg(1, "using OOB on NAND\n");
 
-	c->oobavail = oinfo->oobavail;
+	c->oobavail = c->mtd->oobavail;
 
 	/* Initialise write buffer */
 	init_rwsem(&c->wbuf_sem);
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index cc84923..9cf13c4 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -105,7 +105,6 @@ struct mtd_oob_ops {
 struct nand_ecclayout {
 	__u32 eccbytes;
 	__u32 eccpos[MTD_MAX_ECCPOS_ENTRIES_LARGE];
-	__u32 oobavail;
 	struct nand_oobfree oobfree[MTD_MAX_OOBFREE_ENTRIES_LARGE];
 };
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:11 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:11 +0100
Subject: [PATCH v3 03/52] mtd: mtdswap: remove useless if (!mtd->ecclayout)
 test
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-4-git-send-email-boris.brezillon@free-electrons.com>

If the MTD device does not have OOB, the mtd->oobsize and mtd->oobavail
fields are set to zero, and we are testing those values in the following
test.
Remove the useless if (!mtd->ecclayout) test.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/mtdswap.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/mtd/mtdswap.c b/drivers/mtd/mtdswap.c
index d330eb1..cb06bdd 100644
--- a/drivers/mtd/mtdswap.c
+++ b/drivers/mtd/mtdswap.c
@@ -1417,7 +1417,6 @@ static void mtdswap_add_mtd(struct mtd_blktrans_ops *tr, struct mtd_info *mtd)
 	unsigned long part;
 	unsigned int eblocks, eavailable, bad_blocks, spare_cnt;
 	uint64_t swap_size, use_size, size_limit;
-	struct nand_ecclayout *oinfo;
 	int ret;
 
 	parts = &partitions[0];
@@ -1447,13 +1446,6 @@ static void mtdswap_add_mtd(struct mtd_blktrans_ops *tr, struct mtd_info *mtd)
 		return;
 	}
 
-	oinfo = mtd->ecclayout;
-	if (!oinfo) {
-		printk(KERN_ERR "%s: mtd%d does not have OOB\n",
-			MTDSWAP_PREFIX, mtd->index);
-		return;
-	}
-
 	if (!mtd->oobsize || mtd->oobavail < MTDSWAP_OOBSIZE) {
 		printk(KERN_ERR "%s: Not enough free bytes in OOB, "
 			"%d available, %zu needed.\n",
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:12 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:12 +0100
Subject: [PATCH v3 04/52] mtd: nand: simplify nand_bch_init() usage
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-5-git-send-email-boris.brezillon@free-electrons.com>

nand_bch_init() requires several arguments which could directly be deduced
from the mtd device. Get rid of those useless parameters.

nand_bch_init() is also requiring the caller to provide a proper eccbytes
value, while this value could be deduced from the ecc.size and
ecc.strength value. Fallback to eccbytes calculation when it is set to 0.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/nand_base.c |  6 ++----
 drivers/mtd/nand/nand_bch.c  | 27 +++++++++++++++++----------
 drivers/mtd/nand/omap2.c     | 28 ++++++++++++----------------
 include/linux/mtd/nand_bch.h |  8 ++------
 4 files changed, 33 insertions(+), 36 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ee89195..91672bf 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -4279,10 +4279,8 @@ int nand_scan_tail(struct mtd_info *mtd)
 		}
 
 		/* See nand_bch_init() for details. */
-		ecc->bytes = DIV_ROUND_UP(
-				ecc->strength * fls(8 * ecc->size), 8);
-		ecc->priv = nand_bch_init(mtd, ecc->size, ecc->bytes,
-					       &ecc->layout);
+		ecc->bytes = 0;
+		ecc->priv = nand_bch_init(mtd);
 		if (!ecc->priv) {
 			pr_warn("BCH ECC initialization failed!\n");
 			BUG();
diff --git a/drivers/mtd/nand/nand_bch.c b/drivers/mtd/nand/nand_bch.c
index a87c1b6..b585bae 100644
--- a/drivers/mtd/nand/nand_bch.c
+++ b/drivers/mtd/nand/nand_bch.c
@@ -107,9 +107,6 @@ EXPORT_SYMBOL(nand_bch_correct_data);
 /**
  * nand_bch_init - [NAND Interface] Initialize NAND BCH error correction
  * @mtd:	MTD block structure
- * @eccsize:	ecc block size in bytes
- * @eccbytes:	ecc length in bytes
- * @ecclayout:	output default layout
  *
  * Returns:
  *  a pointer to a new NAND BCH control structure, or NULL upon failure
@@ -123,14 +120,21 @@ EXPORT_SYMBOL(nand_bch_correct_data);
  * @eccsize = 512  (thus, m=13 is the smallest integer such that 2^m-1 > 512*8)
  * @eccbytes = 7   (7 bytes are required to store m*t = 13*4 = 52 bits)
  */
-struct nand_bch_control *
-nand_bch_init(struct mtd_info *mtd, unsigned int eccsize, unsigned int eccbytes,
-	      struct nand_ecclayout **ecclayout)
+struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
 {
+	struct nand_chip *nand = mtd_to_nand(mtd);
 	unsigned int m, t, eccsteps, i;
-	struct nand_ecclayout *layout;
+	struct nand_ecclayout *layout = nand->ecc.layout;
 	struct nand_bch_control *nbc = NULL;
 	unsigned char *erased_page;
+	unsigned int eccsize = nand->ecc.size;
+	unsigned int eccbytes = nand->ecc.bytes;
+	unsigned int eccstrength = nand->ecc.strength;
+
+	if (!eccbytes && eccstrength) {
+		eccbytes = DIV_ROUND_UP(eccstrength * fls(8 * eccsize), 8);
+		nand->ecc.bytes = eccbytes;
+	}
 
 	if (!eccsize || !eccbytes) {
 		printk(KERN_WARNING "ecc parameters not supplied\n");
@@ -158,7 +162,7 @@ nand_bch_init(struct mtd_info *mtd, unsigned int eccsize, unsigned int eccbytes,
 	eccsteps = mtd->writesize/eccsize;
 
 	/* if no ecc placement scheme was provided, build one */
-	if (!*ecclayout) {
+	if (!layout) {
 
 		/* handle large page devices only */
 		if (mtd->oobsize < 64) {
@@ -184,7 +188,7 @@ nand_bch_init(struct mtd_info *mtd, unsigned int eccsize, unsigned int eccbytes,
 		layout->oobfree[0].offset = 2;
 		layout->oobfree[0].length = mtd->oobsize-2-layout->eccbytes;
 
-		*ecclayout = layout;
+		nand->ecc.layout = layout;
 	}
 
 	/* sanity checks */
@@ -192,7 +196,7 @@ nand_bch_init(struct mtd_info *mtd, unsigned int eccsize, unsigned int eccbytes,
 		printk(KERN_WARNING "eccsize %u is too large\n", eccsize);
 		goto fail;
 	}
-	if ((*ecclayout)->eccbytes != (eccsteps*eccbytes)) {
+	if (layout->eccbytes != (eccsteps*eccbytes)) {
 		printk(KERN_WARNING "invalid ecc layout\n");
 		goto fail;
 	}
@@ -216,6 +220,9 @@ nand_bch_init(struct mtd_info *mtd, unsigned int eccsize, unsigned int eccbytes,
 	for (i = 0; i < eccbytes; i++)
 		nbc->eccmask[i] ^= 0xff;
 
+	if (!eccstrength)
+		nand->ecc.strength = (eccbytes * 8) / fls(8 * eccsize);
+
 	return nbc;
 fail:
 	nand_bch_free(nbc);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index c553f78..0749ca1 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1807,13 +1807,19 @@ static int omap_nand_probe(struct platform_device *pdev)
 		goto return_error;
 	}
 
+	/*
+	 * Bail out earlier to let NAND_ECC_SOFT code create its own
+	 * ecclayout instead of using ours.
+	 */
+	if (info->ecc_opt == OMAP_ECC_HAM1_CODE_SW) {
+		nand_chip->ecc.mode = NAND_ECC_SOFT;
+		goto scan_tail;
+	}
+
 	/* populate MTD interface based on ECC scheme */
 	ecclayout		= &info->oobinfo;
+	nand_chip->ecc.layout	= ecclayout;
 	switch (info->ecc_opt) {
-	case OMAP_ECC_HAM1_CODE_SW:
-		nand_chip->ecc.mode = NAND_ECC_SOFT;
-		break;
-
 	case OMAP_ECC_HAM1_CODE_HW:
 		pr_info("nand: using OMAP_ECC_HAM1_CODE_HW\n");
 		nand_chip->ecc.mode             = NAND_ECC_HW;
@@ -1861,10 +1867,7 @@ static int omap_nand_probe(struct platform_device *pdev)
 		ecclayout->oobfree->offset	= 1 +
 				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
 		/* software bch library is used for locating errors */
-		nand_chip->ecc.priv		= nand_bch_init(mtd,
-							nand_chip->ecc.size,
-							nand_chip->ecc.bytes,
-							&ecclayout);
+		nand_chip->ecc.priv		= nand_bch_init(mtd);
 		if (!nand_chip->ecc.priv) {
 			dev_err(&info->pdev->dev, "unable to use BCH library\n");
 			err = -EINVAL;
@@ -1925,10 +1928,7 @@ static int omap_nand_probe(struct platform_device *pdev)
 		ecclayout->oobfree->offset	= 1 +
 				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
 		/* software bch library is used for locating errors */
-		nand_chip->ecc.priv		= nand_bch_init(mtd,
-							nand_chip->ecc.size,
-							nand_chip->ecc.bytes,
-							&ecclayout);
+		nand_chip->ecc.priv		= nand_bch_init(mtd);
 		if (!nand_chip->ecc.priv) {
 			dev_err(&info->pdev->dev, "unable to use BCH library\n");
 			err = -EINVAL;
@@ -2002,9 +2002,6 @@ static int omap_nand_probe(struct platform_device *pdev)
 		goto return_error;
 	}
 
-	if (info->ecc_opt == OMAP_ECC_HAM1_CODE_SW)
-		goto scan_tail;
-
 	/* all OOB bytes from oobfree->offset till end off OOB are free */
 	ecclayout->oobfree->length = mtd->oobsize - ecclayout->oobfree->offset;
 	/* check if NAND device's OOB is enough to store ECC signatures */
@@ -2015,7 +2012,6 @@ static int omap_nand_probe(struct platform_device *pdev)
 		err = -EINVAL;
 		goto return_error;
 	}
-	nand_chip->ecc.layout = ecclayout;
 
 scan_tail:
 	/* second phase scan */
diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
index fb0bc34..98f20ef 100644
--- a/include/linux/mtd/nand_bch.h
+++ b/include/linux/mtd/nand_bch.h
@@ -32,9 +32,7 @@ int nand_bch_correct_data(struct mtd_info *mtd, u_char *dat, u_char *read_ecc,
 /*
  * Initialize BCH encoder/decoder
  */
-struct nand_bch_control *
-nand_bch_init(struct mtd_info *mtd, unsigned int eccsize,
-	      unsigned int eccbytes, struct nand_ecclayout **ecclayout);
+struct nand_bch_control *nand_bch_init(struct mtd_info *mtd);
 /*
  * Release BCH encoder/decoder resources
  */
@@ -58,9 +56,7 @@ nand_bch_correct_data(struct mtd_info *mtd, unsigned char *buf,
 	return -ENOTSUPP;
 }
 
-static inline struct nand_bch_control *
-nand_bch_init(struct mtd_info *mtd, unsigned int eccsize,
-	      unsigned int eccbytes, struct nand_ecclayout **ecclayout)
+static inline struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
 {
 	return NULL;
 }
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:19 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:19 +0100
Subject: [PATCH v3 11/52] mtd: nand: lpc32xx: use mtd_ooblayout_xxx() helpers
 where appropriate
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-12-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/lpc32xx_slc.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/lpc32xx_slc.c b/drivers/mtd/nand/lpc32xx_slc.c
index 3b8f373..10cf8e62 100644
--- a/drivers/mtd/nand/lpc32xx_slc.c
+++ b/drivers/mtd/nand/lpc32xx_slc.c
@@ -604,7 +604,8 @@ static int lpc32xx_nand_read_page_syndrome(struct mtd_info *mtd,
 					   int oob_required, int page)
 {
 	struct lpc32xx_nand_host *host = nand_get_controller_data(chip);
-	int stat, i, status;
+	struct mtd_oob_region oobregion = { };
+	int stat, i, status, error;
 	uint8_t *oobecc, tmpecc[LPC32XX_ECC_SAVE_SIZE];
 
 	/* Issue read command */
@@ -620,7 +621,11 @@ static int lpc32xx_nand_read_page_syndrome(struct mtd_info *mtd,
 	lpc32xx_slc_ecc_copy(tmpecc, (uint32_t *) host->ecc_buf, chip->ecc.steps);
 
 	/* Pointer to ECC data retrieved from NAND spare area */
-	oobecc = chip->oob_poi + chip->ecc.layout->eccpos[0];
+	error = mtd_ooblayout_ecc(mtd, 0, &oobregion);
+	if (error)
+		return error;
+
+	oobecc = chip->oob_poi + oobregion.offset;
 
 	for (i = 0; i < chip->ecc.steps; i++) {
 		stat = chip->ecc.correct(mtd, buf, oobecc,
@@ -666,7 +671,8 @@ static int lpc32xx_nand_write_page_syndrome(struct mtd_info *mtd,
 					    int oob_required, int page)
 {
 	struct lpc32xx_nand_host *host = nand_get_controller_data(chip);
-	uint8_t *pb = chip->oob_poi + chip->ecc.layout->eccpos[0];
+	struct mtd_oob_region oobregion = { };
+	uint8_t *pb;
 	int error;
 
 	/* Write data, calculate ECC on outbound data */
@@ -678,6 +684,11 @@ static int lpc32xx_nand_write_page_syndrome(struct mtd_info *mtd,
 	 * The calculated ECC needs some manual work done to it before
 	 * committing it to NAND. Process the calculated ECC and place
 	 * the resultant values directly into the OOB buffer. */
+	error = mtd_ooblayout_ecc(mtd, 0, &oobregion);
+	if (error)
+		return error;
+
+	pb = chip->oob_poi + oobregion.offset;
 	lpc32xx_slc_ecc_copy(pb, (uint32_t *)host->ecc_buf, chip->ecc.steps);
 
 	/* Write ECC data to device */
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:20 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:20 +0100
Subject: [PATCH v3 12/52] mtd: nand: omap2: use mtd_ooblayout_xxx() helpers
 where appropriate
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-13-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/omap2.c | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 0749ca1..4ebf16b 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1495,9 +1495,8 @@ static int omap_elm_correct_data(struct mtd_info *mtd, u_char *data,
 static int omap_write_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
 			       const uint8_t *buf, int oob_required, int page)
 {
-	int i;
+	int ret;
 	uint8_t *ecc_calc = chip->buffers->ecccalc;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 
 	/* Enable GPMC ecc engine */
 	chip->ecc.hwctl(mtd, NAND_ECC_WRITE);
@@ -1508,8 +1507,10 @@ static int omap_write_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
 	/* Update ecc vector from GPMC result registers */
 	chip->ecc.calculate(mtd, buf, &ecc_calc[0]);
 
-	for (i = 0; i < chip->ecc.total; i++)
-		chip->oob_poi[eccpos[i]] = ecc_calc[i];
+	ret = mtd_ooblayout_set_eccbytes(mtd, ecc_calc, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	/* Write ecc vector to OOB area */
 	chip->write_buf(mtd, chip->oob_poi, mtd->oobsize);
@@ -1536,10 +1537,7 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
 {
 	uint8_t *ecc_calc = chip->buffers->ecccalc;
 	uint8_t *ecc_code = chip->buffers->ecccode;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
-	uint8_t *oob = &chip->oob_poi[eccpos[0]];
-	uint32_t oob_pos = mtd->writesize + chip->ecc.layout->eccpos[0];
-	int stat;
+	int stat, ret;
 	unsigned int max_bitflips = 0;
 
 	/* Enable GPMC ecc engine */
@@ -1549,13 +1547,16 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
 	chip->read_buf(mtd, buf, mtd->writesize);
 
 	/* Read oob bytes */
-	chip->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_pos, -1);
-	chip->read_buf(mtd, oob, chip->ecc.total);
+	chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
+	chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
 
 	/* Calculate ecc bytes */
 	chip->ecc.calculate(mtd, buf, ecc_calc);
 
-	memcpy(ecc_code, &chip->oob_poi[eccpos[0]], chip->ecc.total);
+	ret = mtd_ooblayout_get_eccbytes(mtd, ecc_code, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	stat = chip->ecc.correct(mtd, buf, ecc_code, ecc_calc);
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:22 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:22 +0100
Subject: [PATCH v3 14/52] mtd: add mtd_set_ecclayout() helper function
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-15-git-send-email-boris.brezillon@free-electrons.com>

Add an mtd_set_ecclayout() helper function to avoid direct accesses to the
mtd->ecclayout field. This will ease future reworks of ECC layout
definition.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 include/linux/mtd/mtd.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index b141f26..6250dd8 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -286,6 +286,12 @@ int mtd_ooblayout_set_databytes(struct mtd_info *mtd, const u8 *databuf,
 int mtd_ooblayout_count_freebytes(struct mtd_info *mtd);
 int mtd_ooblayout_count_eccbytes(struct mtd_info *mtd);
 
+static inline void mtd_set_ecclayout(struct mtd_info *mtd,
+				     struct nand_ecclayout *ecclayout)
+{
+	mtd->ecclayout = ecclayout;
+}
+
 static inline void mtd_set_of_node(struct mtd_info *mtd,
 				   struct device_node *np)
 {
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:23 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:23 +0100
Subject: [PATCH v3 15/52] mtd: use mtd_set_ecclayout() where appropriate
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-16-git-send-email-boris.brezillon@free-electrons.com>

Use the mtd_set_ecclayout() helper instead of directly assigning the
mtd->ecclayout field.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/mtdconcat.c | 2 +-
 drivers/mtd/mtdpart.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c
index 239a8c8..481565e 100644
--- a/drivers/mtd/mtdconcat.c
+++ b/drivers/mtd/mtdconcat.c
@@ -777,7 +777,7 @@ struct mtd_info *mtd_concat_create(struct mtd_info *subdev[],	/* subdevices to c
 
 	}
 
-	concat->mtd.ecclayout = subdev[0]->ecclayout;
+	mtd_set_ecclayout(&concat->mtd, subdev[0]->ecclayout);
 
 	concat->num_subdev = num_devs;
 	concat->mtd.name = name;
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 08de4b2..f53d9d7 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -533,7 +533,7 @@ static struct mtd_part *allocate_partition(struct mtd_info *master,
 			part->name);
 	}
 
-	slave->mtd.ecclayout = master->ecclayout;
+	mtd_set_ecclayout(&slave->mtd, master->ecclayout);
 	slave->mtd.ecc_step_size = master->ecc_step_size;
 	slave->mtd.ecc_strength = master->ecc_strength;
 	slave->mtd.bitflip_threshold = master->bitflip_threshold;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:25 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:25 +0100
Subject: [PATCH v3 17/52] mtd: onenand: use mtd_set_ecclayout() where
 appropriate
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-18-git-send-email-boris.brezillon@free-electrons.com>

Use the mtd_set_ecclayout() helper instead of directly assigning the
mtd->ecclayout field.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/onenand/onenand_base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index 20fdf8c..d0fa505 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -3997,7 +3997,7 @@ int onenand_scan(struct mtd_info *mtd, int maxchips)
 
 	mtd->oobavail = ret;
 
-	mtd->ecclayout = this->ecclayout;
+	mtd_set_ecclayout(mtd, this->ecclayout);
 	mtd->ecc_strength = 1;
 
 	/* Fill in remaining MTD driver data */
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:26 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:26 +0100
Subject: [PATCH v3 18/52] mtd: docg3: use mtd_set_ecclayout() where appropriate
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-19-git-send-email-boris.brezillon@free-electrons.com>

Use the mtd_set_ecclayout() helper instead of directly assigning the
mtd->ecclayout field.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
Acked-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
 drivers/mtd/devices/docg3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/devices/docg3.c b/drivers/mtd/devices/docg3.c
index e7b2e43..6b516e1 100644
--- a/drivers/mtd/devices/docg3.c
+++ b/drivers/mtd/devices/docg3.c
@@ -1857,7 +1857,7 @@ static int __init doc_set_driver_info(int chip_id, struct mtd_info *mtd)
 	mtd->_read_oob = doc_read_oob;
 	mtd->_write_oob = doc_write_oob;
 	mtd->_block_isbad = doc_block_isbad;
-	mtd->ecclayout = &docg3_oobinfo;
+	mtd_set_ecclayout(mtd, &docg3_oobinfo);
 	mtd->oobavail = 8;
 	mtd->ecc_strength = DOC_ECC_BCH_T;
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:27 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:27 +0100
Subject: [PATCH v3 19/52] mtd: create an mtd_ooblayout_ops struct to ease ECC
 layout definition
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-20-git-send-email-boris.brezillon@free-electrons.com>

ECC layout definitions are currently exposed using the nand_ecclayout
struct which embeds oobfree and eccpos arrays with predefined size.
This approach was acceptable when NAND chips were providing relatively
small OOB regions, but MLC and TLC now provide OOB regions of several
hundreds of bytes, which implies a non negligible overhead for everybody
even those who only need to support legacy NANDs.

Create an mtd_ooblayout_ops interface providing the same functionality
(expose the ECC and oobfree layout) without the need for this huge
structure.

The mtd->ecclayout is now deprecated and should be replaced by the
equivalent mtd_ooblayout_ops. In the meantime we provide a wrapper around
the ->ecclayout field to ease migration to this new model.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/mtdchar.c   |   4 +-
 drivers/mtd/mtdconcat.c |   2 +-
 drivers/mtd/mtdcore.c   | 165 +++++++++++++++++++++++++++++++++++-------------
 drivers/mtd/mtdpart.c   |  23 ++++++-
 include/linux/mtd/mtd.h |  32 ++++++++--
 5 files changed, 174 insertions(+), 52 deletions(-)

diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index cd64ab7..3fad2c7 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -888,7 +888,7 @@ static int mtdchar_ioctl(struct file *file, u_int cmd, u_long arg)
 	{
 		struct nand_oobinfo oi;
 
-		if (!mtd->ecclayout)
+		if (!mtd->ooblayout)
 			return -EOPNOTSUPP;
 
 		ret = get_oobinfo(mtd, &oi);
@@ -982,7 +982,7 @@ static int mtdchar_ioctl(struct file *file, u_int cmd, u_long arg)
 	{
 		struct nand_ecclayout_user *usrlay;
 
-		if (!mtd->ecclayout)
+		if (!mtd->ooblayout)
 			return -EOPNOTSUPP;
 
 		usrlay = kmalloc(sizeof(*usrlay), GFP_KERNEL);
diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c
index 481565e..d573606 100644
--- a/drivers/mtd/mtdconcat.c
+++ b/drivers/mtd/mtdconcat.c
@@ -777,7 +777,7 @@ struct mtd_info *mtd_concat_create(struct mtd_info *subdev[],	/* subdevices to c
 
 	}
 
-	mtd_set_ecclayout(&concat->mtd, subdev[0]->ecclayout);
+	mtd_set_ooblayout(&concat->mtd, subdev[0]->ooblayout);
 
 	concat->num_subdev = num_devs;
 	concat->mtd.name = name;
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index ab3a7b6..3b1dc09 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1016,49 +1016,15 @@ EXPORT_SYMBOL_GPL(mtd_read_oob);
 int mtd_ooblayout_ecc(struct mtd_info *mtd, int section,
 		      struct mtd_oob_region *oobecc)
 {
-	int eccbyte = 0, cursection = 0, length = 0, eccpos = 0;
-
 	memset(oobecc, 0, sizeof(*oobecc));
 
 	if (!mtd || section < 0)
 		return -EINVAL;
 
-	if (!mtd->ecclayout)
+	if (!mtd->ooblayout || !mtd->ooblayout->ecc)
 		return -ENOTSUPP;
 
-	/*
-	 * This logic allows us to reuse the ->ecclayout information and
-	 * expose them as ECC regions (as done for the OOB free regions).
-	 *
-	 * TODO: this should be dropped as soon as we get rid of the
-	 * ->ecclayout field.
-	 */
-	for (eccbyte = 0; eccbyte < mtd->ecclayout->eccbytes; eccbyte++) {
-		eccpos = mtd->ecclayout->eccpos[eccbyte];
-
-		if (eccbyte < mtd->ecclayout->eccbytes - 1) {
-			int neccpos = mtd->ecclayout->eccpos[eccbyte + 1];
-
-			if (eccpos + 1 == neccpos) {
-				length++;
-				continue;
-			}
-		}
-
-		if (section == cursection)
-			break;
-
-		length = 0;
-		cursection++;
-	}
-
-	if (cursection != section || eccbyte >= mtd->ecclayout->eccbytes)
-		return -ERANGE;
-
-	oobecc->length = length + 1;
-	oobecc->offset = eccpos - length;
-
-	return 0;
+	return mtd->ooblayout->ecc(mtd, section, oobecc);
 }
 EXPORT_SYMBOL_GPL(mtd_ooblayout_ecc);
 
@@ -1087,16 +1053,10 @@ int mtd_ooblayout_free(struct mtd_info *mtd, int section,
 	if (!mtd || section < 0)
 		return -EINVAL;
 
-	if (!mtd->ecclayout)
+	if (!mtd->ooblayout || !mtd->ooblayout->free)
 		return -ENOTSUPP;
 
-	if (section >= MTD_MAX_OOBFREE_ENTRIES_LARGE)
-		return -ERANGE;
-
-	oobfree->offset = mtd->ecclayout->oobfree[section].offset;
-	oobfree->length = mtd->ecclayout->oobfree[section].length;
-
-	return 0;
+	return mtd->ooblayout->free(mtd, section, oobfree);
 }
 EXPORT_SYMBOL_GPL(mtd_ooblayout_free);
 
@@ -1395,6 +1355,123 @@ int mtd_ooblayout_count_eccbytes(struct mtd_info *mtd)
 }
 EXPORT_SYMBOL_GPL(mtd_ooblayout_count_eccbytes);
 
+/**
+ * mtd_ecclayout_ecc - Default ooblayout_ecc iterator implementation
+ * @mtd: MTD device structure
+ * @section: ECC section. Depending on the layout you may have all the ECC
+ *	     bytes stored in a single contiguous section, or one section
+ *	     per ECC chunk (and sometime several sections for a single ECC
+ *	     ECC chunk)
+ * @oobecc: OOB region struct filled with the appropriate ECC position
+ *	    information
+ *
+ * This function is just a wrapper around the mtd->ecclayout field and is
+ * here to ease the transition to the mtd_ooblayout_ops approach.
+ * All it does is convert the layout->eccpos information into proper oob
+ * region definitions.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+static int mtd_ecclayout_ecc(struct mtd_info *mtd, int section,
+			     struct mtd_oob_region *oobecc)
+{
+	int eccbyte = 0, cursection = 0, length = 0, eccpos = 0;
+
+	if (!mtd->ecclayout)
+		return -ENOTSUPP;
+
+	/*
+	 * This logic allows us to reuse the ->ecclayout information and
+	 * expose them as ECC regions (as done for the OOB free regions).
+	 *
+	 * TODO: this should be dropped as soon as we get rid of the
+	 * ->ecclayout field.
+	 */
+	for (eccbyte = 0; eccbyte < mtd->ecclayout->eccbytes; eccbyte++) {
+		eccpos = mtd->ecclayout->eccpos[eccbyte];
+
+		if (eccbyte < mtd->ecclayout->eccbytes - 1) {
+			int neccpos = mtd->ecclayout->eccpos[eccbyte + 1];
+
+			if (eccpos + 1 == neccpos) {
+				length++;
+				continue;
+			}
+		}
+
+		if (section == cursection)
+			break;
+
+		length = 0;
+		cursection++;
+	}
+
+	if (cursection != section || eccbyte >= mtd->ecclayout->eccbytes)
+		return -ERANGE;
+
+	oobecc->length = length + 1;
+	oobecc->offset = eccpos - length;
+
+	return 0;
+}
+
+/**
+ * mtd_ecclayout_ecc - Default ooblayout_free iterator implementation
+ * @mtd: MTD device structure
+ * @section: Free section. Depending on the layout you may have all the free
+ *	     bytes stored in a single contiguous section, or one section
+ *	     per ECC chunk (and sometime several sections for a single ECC
+ *	     ECC chunk)
+ * @oobfree: OOB region struct filled with the appropriate free position
+ *	     information
+ *
+ * This function is just a wrapper around the mtd->ecclayout field and is
+ * here to ease the transition to the mtd_ooblayout_ops approach.
+ * All it does is convert the layout->oobfree information into proper oob
+ * region definitions.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+static int mtd_ecclayout_free(struct mtd_info *mtd, int section,
+			      struct mtd_oob_region *oobfree)
+{
+	struct nand_ecclayout *layout = mtd->ecclayout;
+
+	if (!layout)
+		return -ENOTSUPP;
+
+	if (section >= MTD_MAX_OOBFREE_ENTRIES_LARGE ||
+	    !layout->oobfree[section].length)
+		return -ERANGE;
+
+	oobfree->offset = layout->oobfree[section].offset;
+	oobfree->length = layout->oobfree[section].length;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops mtd_ecclayout_wrapper_ops = {
+	.ecc = mtd_ecclayout_ecc,
+	.free = mtd_ecclayout_free,
+};
+
+/**
+ * mtd_set_ecclayout - Attach an ecclayout to an MTD device
+ * @mtd: MTD device structure
+ * @ecclayout: The ecclayout to attach to the device
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+void mtd_set_ecclayout(struct mtd_info *mtd, struct nand_ecclayout *ecclayout)
+{
+	if (!mtd || !ecclayout)
+		return;
+
+	mtd->ecclayout = ecclayout;
+	mtd_set_ooblayout(mtd, &mtd_ecclayout_wrapper_ops);
+}
+EXPORT_SYMBOL_GPL(mtd_set_ecclayout);
+
 /*
  * Method to access the protection register area, present in some flash
  * devices. The user data is one time programmable but the factory data is read
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index f53d9d7..1f13e32 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -317,6 +317,27 @@ static int part_block_markbad(struct mtd_info *mtd, loff_t ofs)
 	return res;
 }
 
+static int part_ooblayout_ecc(struct mtd_info *mtd, int section,
+			      struct mtd_oob_region *oobregion)
+{
+	struct mtd_part *part = mtd_to_part(mtd);
+
+	return mtd_ooblayout_ecc(part->master, section, oobregion);
+}
+
+static int part_ooblayout_free(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	struct mtd_part *part = mtd_to_part(mtd);
+
+	return mtd_ooblayout_free(part->master, section, oobregion);
+}
+
+static const struct mtd_ooblayout_ops part_ooblayout_ops = {
+	.ecc = part_ooblayout_ecc,
+	.free = part_ooblayout_free,
+};
+
 static inline void free_partition(struct mtd_part *p)
 {
 	kfree(p->mtd.name);
@@ -533,7 +554,7 @@ static struct mtd_part *allocate_partition(struct mtd_info *master,
 			part->name);
 	}
 
-	mtd_set_ecclayout(&slave->mtd, master->ecclayout);
+	mtd_set_ooblayout(&slave->mtd, &part_ooblayout_ops);
 	slave->mtd.ecc_step_size = master->ecc_step_size;
 	slave->mtd.ecc_strength = master->ecc_strength;
 	slave->mtd.bitflip_threshold = master->bitflip_threshold;
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 6250dd8..a38fe9a 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -101,6 +101,9 @@ struct mtd_oob_ops {
  * similar, smaller struct nand_ecclayout_user (in mtd-abi.h) that is retained
  * for export to user-space via the ECCGETLAYOUT ioctl.
  * nand_ecclayout should be expandable in the future simply by the above macros.
+ *
+ * This structure is now deprecated, you should use struct nand_ecclayout_ops
+ * to describe your OOB layout.
  */
 struct nand_ecclayout {
 	__u32 eccbytes;
@@ -123,6 +126,22 @@ struct mtd_oob_region {
 	u32 length;
 };
 
+/*
+ * struct mtd_ooblayout_ops - NAND OOB layout operations
+ * @ecc: function returning an ECC region in the OOB area.
+ *	 Should return -ERANGE if %section exceeds the total number of
+ *	 ECC sections.
+ * @free: function returning a free region in the OOB area.
+ *	  Should return -ERANGE if %section exceeds the total number of
+ *	  free sections.
+ */
+struct mtd_ooblayout_ops {
+	int (*ecc)(struct mtd_info *mtd, int section,
+		   struct mtd_oob_region *oobecc);
+	int (*free)(struct mtd_info *mtd, int section,
+		    struct mtd_oob_region *oobfree);
+};
+
 struct module;	/* only needed for owner field in mtd_info */
 
 struct mtd_info {
@@ -181,9 +200,12 @@ struct mtd_info {
 	const char *name;
 	int index;
 
-	/* ECC layout structure pointer - read only! */
+	/* [Deprecated] ECC layout structure pointer - read only! */
 	struct nand_ecclayout *ecclayout;
 
+	/* OOB layout description */
+	const struct mtd_ooblayout_ops *ooblayout;
+
 	/* the ecc step size. */
 	unsigned int ecc_step_size;
 
@@ -286,10 +308,12 @@ int mtd_ooblayout_set_databytes(struct mtd_info *mtd, const u8 *databuf,
 int mtd_ooblayout_count_freebytes(struct mtd_info *mtd);
 int mtd_ooblayout_count_eccbytes(struct mtd_info *mtd);
 
-static inline void mtd_set_ecclayout(struct mtd_info *mtd,
-				     struct nand_ecclayout *ecclayout)
+void mtd_set_ecclayout(struct mtd_info *mtd, struct nand_ecclayout *ecclayout);
+
+static inline void mtd_set_ooblayout(struct mtd_info *mtd,
+				     const struct mtd_ooblayout_ops *ooblayout)
 {
-	mtd->ecclayout = ecclayout;
+	mtd->ooblayout = ooblayout;
 }
 
 static inline void mtd_set_of_node(struct mtd_info *mtd,
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:28 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:28 +0100
Subject: [PATCH v3 20/52] mtd: docg3: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-21-git-send-email-boris.brezillon@free-electrons.com>

Replace the nand_ecclayout definition by the equivalent mtd_ooblayout_ops
definition.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
Acked-by: Robert Jarzmik <robert.jarzmik at free.fr>
---
 drivers/mtd/devices/docg3.c | 46 ++++++++++++++++++++++++++++++++++-----------
 1 file changed, 35 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/devices/docg3.c b/drivers/mtd/devices/docg3.c
index 6b516e1..b833e6c 100644
--- a/drivers/mtd/devices/docg3.c
+++ b/drivers/mtd/devices/docg3.c
@@ -67,16 +67,40 @@ module_param(reliable_mode, uint, 0);
 MODULE_PARM_DESC(reliable_mode, "Set the docg3 mode (0=normal MLC, 1=fast, "
 		 "2=reliable) : MLC normal operations are in normal mode");
 
-/**
- * struct docg3_oobinfo - DiskOnChip G3 OOB layout
- * @eccbytes: 8 bytes are used (1 for Hamming ECC, 7 for BCH ECC)
- * @eccpos: ecc positions (byte 7 is Hamming ECC, byte 8-14 are BCH ECC)
- * @oobfree: free pageinfo bytes (byte 0 until byte 6, byte 15
- */
-static struct nand_ecclayout docg3_oobinfo = {
-	.eccbytes = 8,
-	.eccpos = {7, 8, 9, 10, 11, 12, 13, 14},
-	.oobfree = {{0, 7}, {15, 1} },
+static int docg3_ooblayout_ecc(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	/* byte 7 is Hamming ECC, byte 8-14 are BCH ECC */
+	oobregion->offset = 7;
+	oobregion->length = 8;
+
+	return 0;
+}
+
+static int docg3_ooblayout_free(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	if (section > 1)
+		return -ERANGE;
+
+	/* free bytes: byte 0 until byte 6, byte 15 */
+	if (!section) {
+		oobregion->offset = 0;
+		oobregion->length = 7;
+	} else {
+		oobregion->offset = 15;
+		oobregion->length = 1;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops nand_ooblayout_docg3_ops = {
+	.ecc = docg3_ooblayout_ecc,
+	.free = docg3_ooblayout_free,
 };
 
 static inline u8 doc_readb(struct docg3 *docg3, u16 reg)
@@ -1857,7 +1881,7 @@ static int __init doc_set_driver_info(int chip_id, struct mtd_info *mtd)
 	mtd->_read_oob = doc_read_oob;
 	mtd->_write_oob = doc_write_oob;
 	mtd->_block_isbad = doc_block_isbad;
-	mtd_set_ecclayout(mtd, &docg3_oobinfo);
+	mtd_set_ooblayout(mtd, &nand_ooblayout_docg3_ops);
 	mtd->oobavail = 8;
 	mtd->ecc_strength = DOC_ECC_BCH_T;
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:30 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:30 +0100
Subject: [PATCH v3 22/52] mtd: nand: bch: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-23-git-send-email-boris.brezillon@free-electrons.com>

Replace the nand_ecclayout definition by the equivalent mtd_ooblayout_ops
definition.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/nand_bch.c | 33 +++++++++++----------------------
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/drivers/mtd/nand/nand_bch.c b/drivers/mtd/nand/nand_bch.c
index b3039de..e29e75f 100644
--- a/drivers/mtd/nand/nand_bch.c
+++ b/drivers/mtd/nand/nand_bch.c
@@ -32,13 +32,11 @@
 /**
  * struct nand_bch_control - private NAND BCH control structure
  * @bch:       BCH control structure
- * @ecclayout: private ecc layout for this BCH configuration
  * @errloc:    error location array
  * @eccmask:   XOR ecc mask, allows erased pages to be decoded as valid
  */
 struct nand_bch_control {
 	struct bch_control   *bch;
-	struct nand_ecclayout ecclayout;
 	unsigned int         *errloc;
 	unsigned char        *eccmask;
 };
@@ -124,7 +122,6 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
 {
 	struct nand_chip *nand = mtd_to_nand(mtd);
 	unsigned int m, t, eccsteps, i;
-	struct nand_ecclayout *layout = nand->ecc.layout;
 	struct nand_bch_control *nbc = NULL;
 	unsigned char *erased_page;
 	unsigned int eccsize = nand->ecc.size;
@@ -161,8 +158,17 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
 
 	eccsteps = mtd->writesize/eccsize;
 
+	/*
+	 * Rely on the default ecclayout to ooblayout wrapper provided by MTD
+	 * core if ecc.layout is not NULL.
+	 * FIXME: this should be removed when all callers have moved to the
+	 * mtd_ooblayout_ops approach.
+	 */
+	if (nand->ecc.layout)
+		mtd_set_ecclayout(mtd, nand->ecc.layout);
+
 	/* if no ecc placement scheme was provided, build one */
-	if (!layout) {
+	if (!mtd->ooblayout) {
 
 		/* handle large page devices only */
 		if (mtd->oobsize < 64) {
@@ -171,24 +177,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
 			goto fail;
 		}
 
-		layout = &nbc->ecclayout;
-		layout->eccbytes = eccsteps*eccbytes;
-
-		/* reserve 2 bytes for bad block marker */
-		if (layout->eccbytes+2 > mtd->oobsize) {
-			printk(KERN_WARNING "no suitable oob scheme available "
-			       "for oobsize %d eccbytes %u\n", mtd->oobsize,
-			       eccbytes);
-			goto fail;
-		}
-		/* put ecc bytes at oob tail */
-		for (i = 0; i < layout->eccbytes; i++)
-			layout->eccpos[i] = mtd->oobsize-layout->eccbytes+i;
-
-		layout->oobfree[0].offset = 2;
-		layout->oobfree[0].length = mtd->oobsize-2-layout->eccbytes;
-
-		nand->ecc.layout = layout;
+		mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
 	}
 
 	/* sanity checks */
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:31 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:31 +0100
Subject: [PATCH v3 23/52] mtd: nand: sharpsl: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-24-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 arch/arm/mach-pxa/spitz.c   | 55 ++++++++++++++++++++++++++++++++++++---------
 drivers/mtd/nand/sharpsl.c  |  2 +-
 include/linux/mtd/sharpsl.h |  2 +-
 3 files changed, 47 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 825f903..165a8db 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -763,14 +763,49 @@ static struct nand_bbt_descr spitz_nand_bbt = {
 	.pattern	= scan_ff_pattern
 };
 
-static struct nand_ecclayout akita_oobinfo = {
-	.oobfree	= { {0x08, 0x09} },
-	.eccbytes	= 24,
-	.eccpos		= {
-			0x05, 0x01, 0x02, 0x03, 0x06, 0x07, 0x15, 0x11,
-			0x12, 0x13, 0x16, 0x17, 0x25, 0x21, 0x22, 0x23,
-			0x26, 0x27, 0x35, 0x31, 0x32, 0x33, 0x36, 0x37,
-	},
+static int akita_ooblayout_ecc(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	if (section > 12)
+		return -ERANGE;
+
+	switch (section % 3) {
+	case 0:
+		oobregion->offset = 5;
+		oobregion->length = 1;
+		break;
+
+	case 1:
+		oobregion->offset = 1;
+		oobregion->length = 3;
+		break;
+
+	case 2:
+		oobregion->offset = 6;
+		oobregion->length = 2;
+		break;
+	}
+
+	oobregion->offset += (section / 3) * 0x10;
+
+	return 0;
+}
+
+static int akita_ooblayout_free(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 8;
+	oobregion->length = 9;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops akita_ooblayout_ops = {
+	.ecc = akita_ooblayout_ecc,
+	.free = akita_ooblayout_free,
 };
 
 static struct sharpsl_nand_platform_data spitz_nand_pdata = {
@@ -804,11 +839,11 @@ static void __init spitz_nand_init(void)
 	} else if (machine_is_akita()) {
 		spitz_nand_partitions[1].size = 58 * 1024 * 1024;
 		spitz_nand_bbt.len = 1;
-		spitz_nand_pdata.ecc_layout = &akita_oobinfo;
+		spitz_nand_pdata.ecc_layout = &akita_ooblayout_ops;
 	} else if (machine_is_borzoi()) {
 		spitz_nand_partitions[1].size = 32 * 1024 * 1024;
 		spitz_nand_bbt.len = 1;
-		spitz_nand_pdata.ecc_layout = &akita_oobinfo;
+		spitz_nand_pdata.ecc_layout = &akita_ooblayout_ops;
 	}
 
 	platform_device_register(&spitz_nand_device);
diff --git a/drivers/mtd/nand/sharpsl.c b/drivers/mtd/nand/sharpsl.c
index b7d1b55..064ca17 100644
--- a/drivers/mtd/nand/sharpsl.c
+++ b/drivers/mtd/nand/sharpsl.c
@@ -148,6 +148,7 @@ static int sharpsl_nand_probe(struct platform_device *pdev)
 	/* Link the private data with the MTD structure */
 	mtd = nand_to_mtd(this);
 	mtd->dev.parent = &pdev->dev;
+	mtd_set_ooblayout(mtd, data->ecc_layout);
 
 	platform_set_drvdata(pdev, sharpsl);
 
@@ -170,7 +171,6 @@ static int sharpsl_nand_probe(struct platform_device *pdev)
 	this->ecc.bytes = 3;
 	this->ecc.strength = 1;
 	this->badblock_pattern = data->badblock_pattern;
-	this->ecc.layout = data->ecc_layout;
 	this->ecc.hwctl = sharpsl_nand_enable_hwecc;
 	this->ecc.calculate = sharpsl_nand_calculate_ecc;
 	this->ecc.correct = nand_correct_data;
diff --git a/include/linux/mtd/sharpsl.h b/include/linux/mtd/sharpsl.h
index 25f4d2a..65e91d0 100644
--- a/include/linux/mtd/sharpsl.h
+++ b/include/linux/mtd/sharpsl.h
@@ -14,7 +14,7 @@
 
 struct sharpsl_nand_platform_data {
 	struct nand_bbt_descr	*badblock_pattern;
-	struct nand_ecclayout	*ecc_layout;
+	const struct mtd_ooblayout_ops *ecc_layout;
 	struct mtd_partition	*partitions;
 	unsigned int		nr_partitions;
 };
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:10 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:10 +0100
Subject: [PATCH v3 02/52] mtd: create an mtd_oobavail() helper and make use of
 it
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-3-git-send-email-boris.brezillon@free-electrons.com>

Currently, all MTD drivers/sublayers exposing an OOB area are
doing the same kind of test to extract the available OOB size
based on the mtd_info and mtd_oob_ops structures.
Move this common logic into an inline function and make use of it.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
Suggested-by: Priit Laes <plaes at plaes.org>
---
 drivers/mtd/mtdpart.c              |  5 +----
 drivers/mtd/nand/nand_base.c       | 16 ++++------------
 drivers/mtd/onenand/onenand_base.c | 19 +++----------------
 include/linux/mtd/mtd.h            |  5 +++++
 4 files changed, 13 insertions(+), 32 deletions(-)

diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 10bf304..08de4b2 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -126,10 +126,7 @@ static int part_read_oob(struct mtd_info *mtd, loff_t from,
 	if (ops->oobbuf) {
 		size_t len, pages;
 
-		if (ops->mode == MTD_OPS_AUTO_OOB)
-			len = mtd->oobavail;
-		else
-			len = mtd->oobsize;
+		len = mtd_oobavail(mtd, ops);
 		pages = mtd_div_by_ws(mtd->size, mtd);
 		pages -= mtd_div_by_ws(from, mtd);
 		if (ops->ooboffs + ops->ooblen > pages * len)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 9f49d3e..ee89195 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1723,8 +1723,7 @@ static int nand_do_read_ops(struct mtd_info *mtd, loff_t from,
 	int ret = 0;
 	uint32_t readlen = ops->len;
 	uint32_t oobreadlen = ops->ooblen;
-	uint32_t max_oobsize = ops->mode == MTD_OPS_AUTO_OOB ?
-		mtd->oobavail : mtd->oobsize;
+	uint32_t max_oobsize = mtd_oobavail(mtd, ops);
 
 	uint8_t *bufpoi, *oob, *buf;
 	int use_bufpoi;
@@ -2075,10 +2074,7 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
 
 	stats = mtd->ecc_stats;
 
-	if (ops->mode == MTD_OPS_AUTO_OOB)
-		len = mtd->oobavail;
-	else
-		len = mtd->oobsize;
+	len = mtd_oobavail(mtd, ops);
 
 	if (unlikely(ops->ooboffs >= len)) {
 		pr_debug("%s: attempt to start read outside oob\n",
@@ -2575,8 +2571,7 @@ static int nand_do_write_ops(struct mtd_info *mtd, loff_t to,
 	uint32_t writelen = ops->len;
 
 	uint32_t oobwritelen = ops->ooblen;
-	uint32_t oobmaxlen = ops->mode == MTD_OPS_AUTO_OOB ?
-				mtd->oobavail : mtd->oobsize;
+	uint32_t oobmaxlen = mtd_oobavail(mtd, ops);
 
 	uint8_t *oob = ops->oobbuf;
 	uint8_t *buf = ops->datbuf;
@@ -2766,10 +2761,7 @@ static int nand_do_write_oob(struct mtd_info *mtd, loff_t to,
 	pr_debug("%s: to = 0x%08x, len = %i\n",
 			 __func__, (unsigned int)to, (int)ops->ooblen);
 
-	if (ops->mode == MTD_OPS_AUTO_OOB)
-		len = mtd->oobavail;
-	else
-		len = mtd->oobsize;
+	len = mtd_oobavail(mtd, ops);
 
 	/* Do not allow write past end of page */
 	if ((ops->ooboffs + ops->ooblen) > len) {
diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index df47537..af28bb3 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1124,11 +1124,7 @@ static int onenand_mlc_read_ops_nolock(struct mtd_info *mtd, loff_t from,
 	pr_debug("%s: from = 0x%08x, len = %i\n", __func__, (unsigned int)from,
 			(int)len);
 
-	if (ops->mode == MTD_OPS_AUTO_OOB)
-		oobsize = mtd->oobavail;
-	else
-		oobsize = mtd->oobsize;
-
+	oobsize = mtd_oobavail(mtd, ops);
 	oobcolumn = from & (mtd->oobsize - 1);
 
 	/* Do not allow reads past end of device */
@@ -1229,11 +1225,7 @@ static int onenand_read_ops_nolock(struct mtd_info *mtd, loff_t from,
 	pr_debug("%s: from = 0x%08x, len = %i\n", __func__, (unsigned int)from,
 			(int)len);
 
-	if (ops->mode == MTD_OPS_AUTO_OOB)
-		oobsize = mtd->oobavail;
-	else
-		oobsize = mtd->oobsize;
-
+	oobsize = mtd_oobavail(mtd, ops);
 	oobcolumn = from & (mtd->oobsize - 1);
 
 	/* Do not allow reads past end of device */
@@ -1885,12 +1877,7 @@ static int onenand_write_ops_nolock(struct mtd_info *mtd, loff_t to,
 	/* Check zero length */
 	if (!len)
 		return 0;
-
-	if (ops->mode == MTD_OPS_AUTO_OOB)
-		oobsize = mtd->oobavail;
-	else
-		oobsize = mtd->oobsize;
-
+	oobsize = mtd_oobavail(mtd, ops);
 	oobcolumn = to & (mtd->oobsize - 1);
 
 	column = to & (mtd->writesize - 1);
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 9cf13c4..7712721 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -264,6 +264,11 @@ static inline struct device_node *mtd_get_of_node(struct mtd_info *mtd)
 	return mtd->dev.of_node;
 }
 
+static inline int mtd_oobavail(struct mtd_info *mtd, struct mtd_oob_ops *ops)
+{
+	return ops->mode == MTD_OPS_AUTO_OOB ? mtd->oobavail : mtd->oobsize;
+}
+
 int mtd_erase(struct mtd_info *mtd, struct erase_info *instr);
 int mtd_point(struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen,
 	      void **virt, resource_size_t *phys);
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:13 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:13 +0100
Subject: [PATCH v3 05/52] mtd: add mtd_ooblayout_xxx() helper functions
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-6-git-send-email-boris.brezillon@free-electrons.com>

In order to make the ecclayout definition completely dynamic we need to
rework the way the OOB layout are defined and iterated.

Create a few mtd_ooblayout_xxx() helpers to ease OOB bytes manipulation
and hide ecclayout internals to their users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/mtdcore.c   | 398 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/mtd/mtd.h |  33 ++++
 2 files changed, 431 insertions(+)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 3096251..ab3a7b6 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -997,6 +997,404 @@ int mtd_read_oob(struct mtd_info *mtd, loff_t from, struct mtd_oob_ops *ops)
 }
 EXPORT_SYMBOL_GPL(mtd_read_oob);
 
+/**
+ * mtd_ooblayout_ecc - Get the OOB region definition of a specific ECC section
+ * @mtd: MTD device structure
+ * @section: ECC section. Depending on the layout you may have all the ECC
+ *	     bytes stored in a single contiguous section, or one section
+ *	     per ECC chunk (and sometime several sections for a single ECC
+ *	     ECC chunk)
+ * @oobecc: OOB region struct filled with the appropriate ECC position
+ *	    information
+ *
+ * This functions return ECC section information in the OOB area. I you want
+ * to get all the ECC bytes information, then you should call
+ * mtd_ooblayout_ecc(mtd, section++, oobecc) until it returns -ERANGE.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_ecc(struct mtd_info *mtd, int section,
+		      struct mtd_oob_region *oobecc)
+{
+	int eccbyte = 0, cursection = 0, length = 0, eccpos = 0;
+
+	memset(oobecc, 0, sizeof(*oobecc));
+
+	if (!mtd || section < 0)
+		return -EINVAL;
+
+	if (!mtd->ecclayout)
+		return -ENOTSUPP;
+
+	/*
+	 * This logic allows us to reuse the ->ecclayout information and
+	 * expose them as ECC regions (as done for the OOB free regions).
+	 *
+	 * TODO: this should be dropped as soon as we get rid of the
+	 * ->ecclayout field.
+	 */
+	for (eccbyte = 0; eccbyte < mtd->ecclayout->eccbytes; eccbyte++) {
+		eccpos = mtd->ecclayout->eccpos[eccbyte];
+
+		if (eccbyte < mtd->ecclayout->eccbytes - 1) {
+			int neccpos = mtd->ecclayout->eccpos[eccbyte + 1];
+
+			if (eccpos + 1 == neccpos) {
+				length++;
+				continue;
+			}
+		}
+
+		if (section == cursection)
+			break;
+
+		length = 0;
+		cursection++;
+	}
+
+	if (cursection != section || eccbyte >= mtd->ecclayout->eccbytes)
+		return -ERANGE;
+
+	oobecc->length = length + 1;
+	oobecc->offset = eccpos - length;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_ecc);
+
+/**
+ * mtd_ooblayout_free - Get the OOB region definition of a specific free
+ *			section
+ * @mtd: MTD device structure
+ * @section: Free section you are interested in. Depending on the layout
+ *	     you may have all the free bytes stored in a single contiguous
+ *	     section, or one section per ECC chunk plus an extra section
+ *	     for the remaining bytes (or other funky layout).
+ * @oobfree: OOB region struct filled with the appropriate free position
+ *	     information
+ *
+ * This functions return free bytes position in the OOB area. I you want
+ * to get all the free bytes information, then you should call
+ * mtd_ooblayout_free(mtd, section++, oobfree) until it returns -ERANGE.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_free(struct mtd_info *mtd, int section,
+		       struct mtd_oob_region *oobfree)
+{
+	memset(oobfree, 0, sizeof(*oobfree));
+
+	if (!mtd || section < 0)
+		return -EINVAL;
+
+	if (!mtd->ecclayout)
+		return -ENOTSUPP;
+
+	if (section >= MTD_MAX_OOBFREE_ENTRIES_LARGE)
+		return -ERANGE;
+
+	oobfree->offset = mtd->ecclayout->oobfree[section].offset;
+	oobfree->length = mtd->ecclayout->oobfree[section].length;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_free);
+
+/**
+ * mtd_ooblayout_find_region - Find the region attached to a specific byte
+ * @mtd: mtd info structure
+ * @byte: the byte we are searching for
+ * @sectionp: pointer where the section id will be stored
+ * @oobregion: used to retrieve the ECC position
+ * @iter: iterator function. Should be either mtd_ooblayout_free or
+ *	  mtd_ooblayout_ecc depending on the region type you're searching for
+ *
+ * This functions returns the section id and oobregion information of a
+ * specific byte. For example, say you want to know where the 4th ECC byte is
+ * stored, you'll use:
+ *
+ * mtd_ooblayout_find_region(mtd, 3, &section, &oobregion, mtd_ooblayout_ecc);
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+static int mtd_ooblayout_find_region(struct mtd_info *mtd, int byte,
+				int *sectionp, struct mtd_oob_region *oobregion,
+				int (*iter)(struct mtd_info *,
+					    int section,
+					    struct mtd_oob_region *oobregion))
+{
+	int pos = 0, ret, section = 0;
+
+	memset(oobregion, 0, sizeof(*oobregion));
+
+	while (pos + oobregion->length <= byte) {
+		ret = iter(mtd, section++, oobregion);
+		if (ret)
+			return ret;
+
+		pos += oobregion->length;
+	}
+
+	/*
+	 * Adjust region info to make it start at the beginning at the
+	 * 'start' ECC byte.
+	 */
+	oobregion->offset += byte - pos;
+	oobregion->length -= byte - pos;
+	*sectionp = section;
+
+	return 0;
+}
+
+/**
+ * mtd_ooblayout_find_eccregion - Find the ECC region attached to a specific
+ *				  ECC byte
+ * @mtd: mtd info structure
+ * @eccbyte: the byte we are searching for
+ * @sectionp: pointer where the section id will be stored
+ * @oobregion: OOB region information
+ *
+ * Works like mtd_ooblayout_find_region() except it searches for a specific ECC
+ * byte.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_find_eccregion(struct mtd_info *mtd, int eccbyte,
+				 int *section,
+				 struct mtd_oob_region *oobregion)
+{
+	return mtd_ooblayout_find_region(mtd, eccbyte, section, oobregion,
+					 mtd_ooblayout_ecc);
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_find_eccregion);
+
+/**
+ * mtd_ooblayout_get_bytes - Extract OOB bytes from the oob buffer
+ * @mtd: mtd info structure
+ * @buf: destination buffer to store OOB bytes
+ * @oobbuf: OOB buffer
+ * @start: first byte to retrieve
+ * @nbytes: number of bytes to retrieve
+ * @iter: section iterator
+ *
+ * Extract bytes attached to a specific category (ECC or free)
+ * from the OOB buffer and copy them into buf.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+static int mtd_ooblayout_get_bytes(struct mtd_info *mtd, u8 *buf,
+				const u8 *oobbuf, int start, int nbytes,
+				int (*iter)(struct mtd_info *,
+					    int section,
+					    struct mtd_oob_region *oobregion))
+{
+	struct mtd_oob_region oobregion = { };
+	int section = 0, ret;
+
+	ret = mtd_ooblayout_find_region(mtd, start, &section,
+					&oobregion, iter);
+	if (ret)
+		return ret;
+
+	while (nbytes) {
+		int cnt;
+
+		ret = iter(mtd, section++, &oobregion);
+		if (ret)
+			return ret;
+
+		cnt = oobregion.length > nbytes ? nbytes : oobregion.length;
+		memcpy(buf, oobbuf + oobregion.offset, cnt);
+		buf += cnt;
+		nbytes -= cnt;
+	}
+
+	return !nbytes ? 0 : -ERANGE;
+}
+
+/**
+ * mtd_ooblayout_set_bytes - put OOB bytes into the oob buffer
+ * @mtd: mtd info structure
+ * @buf: source buffer to get OOB bytes from
+ * @oobbuf: OOB buffer
+ * @start: first OOB byte to set
+ * @nbytes: number of OOB bytes to set
+ * @iter: section iterator
+ *
+ * Fill the OOB buffer with data provided in buf. The category (ECC or free)
+ * is selected by passing the appropriate iterator.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+static int mtd_ooblayout_set_bytes(struct mtd_info *mtd, const u8 *buf,
+				u8 *oobbuf, int start, int nbytes,
+				int (*iter)(struct mtd_info *,
+					    int section,
+					    struct mtd_oob_region *oobregion))
+{
+	struct mtd_oob_region oobregion = { };
+	int section = 0, ret;
+
+	ret = mtd_ooblayout_find_region(mtd, start, &section,
+					&oobregion, iter);
+	if (ret)
+		return ret;
+
+	while (nbytes) {
+		int cnt;
+
+		ret = iter(mtd, section++, &oobregion);
+		if (ret)
+			return ret;
+
+		cnt = oobregion.length > nbytes ? nbytes : oobregion.length;
+		memcpy(oobbuf + oobregion.offset, buf, cnt);
+		buf += cnt;
+		nbytes -= cnt;
+	}
+
+	return !nbytes ? 0 : -ERANGE;
+}
+
+/**
+ * mtd_ooblayout_count_bytes - count the number of bytes in a OOB category
+ * @mtd: mtd info structure
+ * @iter: category iterator
+ *
+ * Count the number of bytes in a given category.
+ *
+ * Returns a positive value on success, a negative error code otherwise.
+ */
+static int mtd_ooblayout_count_bytes(struct mtd_info *mtd,
+				int (*iter)(struct mtd_info *,
+					    int section,
+					    struct mtd_oob_region *oobregion))
+{
+	struct mtd_oob_region oobregion = { };
+	int section = 0, ret, nbytes = 0;
+
+	while (1) {
+		ret = iter(mtd, section++, &oobregion);
+		if (ret) {
+			if (ret == -ERANGE)
+				ret = nbytes;
+			break;
+		}
+
+		nbytes += oobregion.length;
+	}
+
+	return ret;
+}
+
+/**
+ * mtd_ooblayout_get_eccbytes - extract ECC bytes from the oob buffer
+ * @mtd: mtd info structure
+ * @eccbuf: destination buffer to store ECC bytes
+ * @oobbuf: OOB buffer
+ * @start: first ECC byte to retrieve
+ * @nbytes: number of ECC bytes to retrieve
+ *
+ * Works like mtd_ooblayout_get_bytes(), except it acts on ECC bytes.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_get_eccbytes(struct mtd_info *mtd, u8 *eccbuf,
+			       const u8 *oobbuf, int start, int nbytes)
+{
+	return mtd_ooblayout_get_bytes(mtd, eccbuf, oobbuf, start, nbytes,
+				       mtd_ooblayout_ecc);
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_get_eccbytes);
+
+/**
+ * mtd_ooblayout_set_eccbytes - set ECC bytes into the oob buffer
+ * @mtd: mtd info structure
+ * @eccbuf: source buffer to get ECC bytes from
+ * @oobbuf: OOB buffer
+ * @start: first ECC byte to set
+ * @nbytes: number of ECC bytes to set
+ *
+ * Works like mtd_ooblayout_set_bytes(), except it acts on ECC bytes.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_set_eccbytes(struct mtd_info *mtd, const u8 *eccbuf,
+			       u8 *oobbuf, int start, int nbytes)
+{
+	return mtd_ooblayout_set_bytes(mtd, eccbuf, oobbuf, start, nbytes,
+				       mtd_ooblayout_ecc);
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_set_eccbytes);
+
+/**
+ * mtd_ooblayout_get_databytes - extract data bytes from the oob buffer
+ * @mtd: mtd info structure
+ * @databuf: destination buffer to store ECC bytes
+ * @oobbuf: OOB buffer
+ * @start: first ECC byte to retrieve
+ * @nbytes: number of ECC bytes to retrieve
+ *
+ * Works like mtd_ooblayout_get_bytes(), except it acts on free bytes.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_get_databytes(struct mtd_info *mtd, u8 *databuf,
+				const u8 *oobbuf, int start, int nbytes)
+{
+	return mtd_ooblayout_get_bytes(mtd, databuf, oobbuf, start, nbytes,
+				       mtd_ooblayout_free);
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_get_databytes);
+
+/**
+ * mtd_ooblayout_get_eccbytes - set data bytes into the oob buffer
+ * @mtd: mtd info structure
+ * @eccbuf: source buffer to get data bytes from
+ * @oobbuf: OOB buffer
+ * @start: first ECC byte to set
+ * @nbytes: number of ECC bytes to set
+ *
+ * Works like mtd_ooblayout_get_bytes(), except it acts on free bytes.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_set_databytes(struct mtd_info *mtd, const u8 *databuf,
+				u8 *oobbuf, int start, int nbytes)
+{
+	return mtd_ooblayout_set_bytes(mtd, databuf, oobbuf, start, nbytes,
+				       mtd_ooblayout_free);
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_set_databytes);
+
+/**
+ * mtd_ooblayout_count_freebytes - count the number of free bytes in OOB
+ * @mtd: mtd info structure
+ *
+ * Works like mtd_ooblayout_count_bytes(), except it count free bytes.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_count_freebytes(struct mtd_info *mtd)
+{
+	return mtd_ooblayout_count_bytes(mtd, mtd_ooblayout_free);
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_count_freebytes);
+
+/**
+ * mtd_ooblayout_count_freebytes - count the number of ECC bytes in OOB
+ * @mtd: mtd info structure
+ *
+ * Works like mtd_ooblayout_count_bytes(), except it count ECC bytes.
+ *
+ * Returns zero on success, a negative error code otherwise.
+ */
+int mtd_ooblayout_count_eccbytes(struct mtd_info *mtd)
+{
+	return mtd_ooblayout_count_bytes(mtd, mtd_ooblayout_ecc);
+}
+EXPORT_SYMBOL_GPL(mtd_ooblayout_count_eccbytes);
+
 /*
  * Method to access the protection register area, present in some flash
  * devices. The user data is one time programmable but the factory data is read
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 7712721..b141f26 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -108,6 +108,21 @@ struct nand_ecclayout {
 	struct nand_oobfree oobfree[MTD_MAX_OOBFREE_ENTRIES_LARGE];
 };
 
+/**
+ * struct mtd_oob_region - oob region definition
+ * @offset: region offset
+ * @length: region length
+ *
+ * This structure describes a region of the OOB area, and is used
+ * to retrieve ECC or free bytes sections.
+ * Each section is defined by an offset within the OOB area and a
+ * length.
+ */
+struct mtd_oob_region {
+	u32 offset;
+	u32 length;
+};
+
 struct module;	/* only needed for owner field in mtd_info */
 
 struct mtd_info {
@@ -253,6 +268,24 @@ struct mtd_info {
 	int usecount;
 };
 
+int mtd_ooblayout_ecc(struct mtd_info *mtd, int section,
+		      struct mtd_oob_region *oobecc);
+int mtd_ooblayout_find_eccregion(struct mtd_info *mtd, int eccbyte,
+				 int *section,
+				 struct mtd_oob_region *oobregion);
+int mtd_ooblayout_get_eccbytes(struct mtd_info *mtd, u8 *eccbuf,
+			       const u8 *oobbuf, int start, int nbytes);
+int mtd_ooblayout_set_eccbytes(struct mtd_info *mtd, const u8 *eccbuf,
+			       u8 *oobbuf, int start, int nbytes);
+int mtd_ooblayout_free(struct mtd_info *mtd, int section,
+		       struct mtd_oob_region *oobfree);
+int mtd_ooblayout_get_databytes(struct mtd_info *mtd, u8 *databuf,
+				const u8 *oobbuf, int start, int nbytes);
+int mtd_ooblayout_set_databytes(struct mtd_info *mtd, const u8 *databuf,
+				u8 *oobbuf, int start, int nbytes);
+int mtd_ooblayout_count_freebytes(struct mtd_info *mtd);
+int mtd_ooblayout_count_eccbytes(struct mtd_info *mtd);
+
 static inline void mtd_set_of_node(struct mtd_info *mtd,
 				   struct device_node *np)
 {
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:14 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:14 +0100
Subject: [PATCH v3 06/52] mtd: use mtd_ooblayout_xxx() helpers where
 appropriate
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-7-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/mtdchar.c | 107 +++++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 88 insertions(+), 19 deletions(-)

diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index 6d19835..cd64ab7 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -472,28 +472,101 @@ static int mtdchar_readoob(struct file *file, struct mtd_info *mtd,
  * nand_ecclayout flexibly (i.e. the struct may change size in new
  * releases without requiring major rewrites).
  */
-static int shrink_ecclayout(const struct nand_ecclayout *from,
-		struct nand_ecclayout_user *to)
+static int shrink_ecclayout(struct mtd_info *mtd,
+			    struct nand_ecclayout_user *to)
 {
-	int i;
+	struct mtd_oob_region oobregion;
+	int i, section = 0, ret;
 
-	if (!from || !to)
+	if (!mtd || !to)
 		return -EINVAL;
 
 	memset(to, 0, sizeof(*to));
 
-	to->eccbytes = min((int)from->eccbytes, MTD_MAX_ECCPOS_ENTRIES);
-	for (i = 0; i < to->eccbytes; i++)
-		to->eccpos[i] = from->eccpos[i];
+	to->eccbytes = 0;
+	for (i = 0; i < MTD_MAX_ECCPOS_ENTRIES;) {
+		u32 eccpos;
+
+		ret = mtd_ooblayout_ecc(mtd, section, &oobregion);
+		if (ret < 0) {
+			if (ret != -ERANGE)
+				return ret;
+
+			break;
+		}
+
+		eccpos = oobregion.offset;
+		for (; i < MTD_MAX_ECCPOS_ENTRIES &&
+		       eccpos < oobregion.offset + oobregion.length; i++) {
+			to->eccpos[i] = eccpos++;
+			to->eccbytes++;
+		}
+	}
 
 	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES; i++) {
-		if (from->oobfree[i].length == 0 &&
-				from->oobfree[i].offset == 0)
+		ret = mtd_ooblayout_free(mtd, i, &oobregion);
+		if (ret < 0) {
+			if (ret != -ERANGE)
+				return ret;
+
+			break;
+		}
+
+		to->oobfree[i].offset = oobregion.offset;
+		to->oobfree[i].length = oobregion.length;
+		to->oobavail += to->oobfree[i].length;
+	}
+
+	return 0;
+}
+
+static int get_oobinfo(struct mtd_info *mtd, struct nand_oobinfo *to)
+{
+	struct mtd_oob_region oobregion;
+	int i, section = 0, ret;
+
+	if (!mtd || !to)
+		return -EINVAL;
+
+	memset(to, 0, sizeof(*to));
+
+	to->eccbytes = 0;
+	for (i = 0; i < ARRAY_SIZE(to->eccpos);) {
+		u32 eccpos;
+
+		ret = mtd_ooblayout_ecc(mtd, section, &oobregion);
+		if (ret < 0) {
+			if (ret != -ERANGE)
+				return ret;
+
 			break;
-		to->oobavail += from->oobfree[i].length;
-		to->oobfree[i] = from->oobfree[i];
+		}
+
+		if (oobregion.length + i > ARRAY_SIZE(to->eccpos))
+			return -EINVAL;
+
+		eccpos = oobregion.offset;
+		for (; eccpos < oobregion.offset + oobregion.length; i++) {
+			to->eccpos[i] = eccpos++;
+			to->eccbytes++;
+		}
 	}
 
+	for (i = 0; i < 8; i++) {
+		ret = mtd_ooblayout_free(mtd, i, &oobregion);
+		if (ret < 0) {
+			if (ret != -ERANGE)
+				return ret;
+
+			break;
+		}
+
+		to->oobfree[i][0] = oobregion.offset;
+		to->oobfree[i][1] = oobregion.length;
+	}
+
+	to->useecc = MTD_NANDECC_AUTOPLACE;
+
 	return 0;
 }
 
@@ -817,14 +890,10 @@ static int mtdchar_ioctl(struct file *file, u_int cmd, u_long arg)
 
 		if (!mtd->ecclayout)
 			return -EOPNOTSUPP;
-		if (mtd->ecclayout->eccbytes > ARRAY_SIZE(oi.eccpos))
-			return -EINVAL;
 
-		oi.useecc = MTD_NANDECC_AUTOPLACE;
-		memcpy(&oi.eccpos, mtd->ecclayout->eccpos, sizeof(oi.eccpos));
-		memcpy(&oi.oobfree, mtd->ecclayout->oobfree,
-		       sizeof(oi.oobfree));
-		oi.eccbytes = mtd->ecclayout->eccbytes;
+		ret = get_oobinfo(mtd, &oi);
+		if (ret)
+			return ret;
 
 		if (copy_to_user(argp, &oi, sizeof(struct nand_oobinfo)))
 			return -EFAULT;
@@ -920,7 +989,7 @@ static int mtdchar_ioctl(struct file *file, u_int cmd, u_long arg)
 		if (!usrlay)
 			return -ENOMEM;
 
-		shrink_ecclayout(mtd->ecclayout, usrlay);
+		shrink_ecclayout(mtd, usrlay);
 
 		if (copy_to_user(argp, usrlay, sizeof(*usrlay)))
 			ret = -EFAULT;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:15 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:15 +0100
Subject: [PATCH v3 07/52] mtd: nand: core: use mtd_ooblayout_xxx() helpers
 where appropriate
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-8-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/nand_base.c | 183 +++++++++++++++++++------------------------
 drivers/mtd/nand/nand_bch.c  |   3 +-
 2 files changed, 82 insertions(+), 104 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 91672bf..17504f2 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1309,13 +1309,12 @@ static int nand_read_page_raw_syndrome(struct mtd_info *mtd,
 static int nand_read_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
 				uint8_t *buf, int oob_required, int page)
 {
-	int i, eccsize = chip->ecc.size;
+	int i, eccsize = chip->ecc.size, ret;
 	int eccbytes = chip->ecc.bytes;
 	int eccsteps = chip->ecc.steps;
 	uint8_t *p = buf;
 	uint8_t *ecc_calc = chip->buffers->ecccalc;
 	uint8_t *ecc_code = chip->buffers->ecccode;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 	unsigned int max_bitflips = 0;
 
 	chip->ecc.read_page_raw(mtd, chip, buf, 1, page);
@@ -1323,8 +1322,10 @@ static int nand_read_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
 	for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize)
 		chip->ecc.calculate(mtd, p, &ecc_calc[i]);
 
-	for (i = 0; i < chip->ecc.total; i++)
-		ecc_code[i] = chip->oob_poi[eccpos[i]];
+	ret = mtd_ooblayout_get_eccbytes(mtd, ecc_code, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	eccsteps = chip->ecc.steps;
 	p = buf;
@@ -1356,14 +1357,14 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip,
 			uint32_t data_offs, uint32_t readlen, uint8_t *bufpoi,
 			int page)
 {
-	int start_step, end_step, num_steps;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
+	int start_step, end_step, num_steps, ret;
 	uint8_t *p;
 	int data_col_addr, i, gaps = 0;
 	int datafrag_len, eccfrag_len, aligned_len, aligned_pos;
 	int busw = (chip->options & NAND_BUSWIDTH_16) ? 2 : 1;
-	int index;
+	int index, section = 0;
 	unsigned int max_bitflips = 0;
+	struct mtd_oob_region oobregion = { };
 
 	/* Column address within the page aligned to ECC size (256bytes) */
 	start_step = data_offs / chip->ecc.size;
@@ -1391,12 +1392,13 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip,
 	 * The performance is faster if we position offsets according to
 	 * ecc.pos. Let's make sure that there are no gaps in ECC positions.
 	 */
-	for (i = 0; i < eccfrag_len - 1; i++) {
-		if (eccpos[i + index] + 1 != eccpos[i + index + 1]) {
-			gaps = 1;
-			break;
-		}
-	}
+	ret = mtd_ooblayout_find_eccregion(mtd, index, &section, &oobregion);
+	if (ret)
+		return ret;
+
+	if (oobregion.length < eccfrag_len)
+		gaps = 1;
+
 	if (gaps) {
 		chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
 		chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
@@ -1405,20 +1407,23 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip,
 		 * Send the command to read the particular ECC bytes take care
 		 * about buswidth alignment in read_buf.
 		 */
-		aligned_pos = eccpos[index] & ~(busw - 1);
+		aligned_pos = oobregion.offset & ~(busw - 1);
 		aligned_len = eccfrag_len;
-		if (eccpos[index] & (busw - 1))
+		if (oobregion.offset & (busw - 1))
 			aligned_len++;
-		if (eccpos[index + (num_steps * chip->ecc.bytes)] & (busw - 1))
+		if ((oobregion.offset + (num_steps * chip->ecc.bytes)) &
+		    (busw - 1))
 			aligned_len++;
 
 		chip->cmdfunc(mtd, NAND_CMD_RNDOUT,
-					mtd->writesize + aligned_pos, -1);
+			      mtd->writesize + aligned_pos, -1);
 		chip->read_buf(mtd, &chip->oob_poi[aligned_pos], aligned_len);
 	}
 
-	for (i = 0; i < eccfrag_len; i++)
-		chip->buffers->ecccode[i] = chip->oob_poi[eccpos[i + index]];
+	ret = mtd_ooblayout_get_eccbytes(mtd, chip->buffers->ecccode,
+					 chip->oob_poi, index, eccfrag_len);
+	if (ret)
+		return ret;
 
 	p = bufpoi + data_col_addr;
 	for (i = 0; i < eccfrag_len ; i += chip->ecc.bytes, p += chip->ecc.size) {
@@ -1459,13 +1464,12 @@ static int nand_read_subpage(struct mtd_info *mtd, struct nand_chip *chip,
 static int nand_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
 				uint8_t *buf, int oob_required, int page)
 {
-	int i, eccsize = chip->ecc.size;
+	int i, eccsize = chip->ecc.size, ret;
 	int eccbytes = chip->ecc.bytes;
 	int eccsteps = chip->ecc.steps;
 	uint8_t *p = buf;
 	uint8_t *ecc_calc = chip->buffers->ecccalc;
 	uint8_t *ecc_code = chip->buffers->ecccode;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 	unsigned int max_bitflips = 0;
 
 	for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
@@ -1475,8 +1479,10 @@ static int nand_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
 	}
 	chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
 
-	for (i = 0; i < chip->ecc.total; i++)
-		ecc_code[i] = chip->oob_poi[eccpos[i]];
+	ret = mtd_ooblayout_get_eccbytes(mtd, ecc_code, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	eccsteps = chip->ecc.steps;
 	p = buf;
@@ -1521,12 +1527,11 @@ static int nand_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
 static int nand_read_page_hwecc_oob_first(struct mtd_info *mtd,
 	struct nand_chip *chip, uint8_t *buf, int oob_required, int page)
 {
-	int i, eccsize = chip->ecc.size;
+	int i, eccsize = chip->ecc.size, ret;
 	int eccbytes = chip->ecc.bytes;
 	int eccsteps = chip->ecc.steps;
 	uint8_t *p = buf;
 	uint8_t *ecc_code = chip->buffers->ecccode;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 	uint8_t *ecc_calc = chip->buffers->ecccalc;
 	unsigned int max_bitflips = 0;
 
@@ -1535,8 +1540,10 @@ static int nand_read_page_hwecc_oob_first(struct mtd_info *mtd,
 	chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
 	chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
 
-	for (i = 0; i < chip->ecc.total; i++)
-		ecc_code[i] = chip->oob_poi[eccpos[i]];
+	ret = mtd_ooblayout_get_eccbytes(mtd, ecc_code, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
 		int stat;
@@ -1637,14 +1644,17 @@ static int nand_read_page_syndrome(struct mtd_info *mtd, struct nand_chip *chip,
 
 /**
  * nand_transfer_oob - [INTERN] Transfer oob to client buffer
- * @chip: nand chip structure
+ * @mtd: mtd info structure
  * @oob: oob destination address
  * @ops: oob ops structure
  * @len: size of oob to transfer
  */
-static uint8_t *nand_transfer_oob(struct nand_chip *chip, uint8_t *oob,
+static uint8_t *nand_transfer_oob(struct mtd_info *mtd, uint8_t *oob,
 				  struct mtd_oob_ops *ops, size_t len)
 {
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int ret;
+
 	switch (ops->mode) {
 
 	case MTD_OPS_PLACE_OOB:
@@ -1652,31 +1662,12 @@ static uint8_t *nand_transfer_oob(struct nand_chip *chip, uint8_t *oob,
 		memcpy(oob, chip->oob_poi + ops->ooboffs, len);
 		return oob + len;
 
-	case MTD_OPS_AUTO_OOB: {
-		struct nand_oobfree *free = chip->ecc.layout->oobfree;
-		uint32_t boffs = 0, roffs = ops->ooboffs;
-		size_t bytes = 0;
-
-		for (; free->length && len; free++, len -= bytes) {
-			/* Read request not from offset 0? */
-			if (unlikely(roffs)) {
-				if (roffs >= free->length) {
-					roffs -= free->length;
-					continue;
-				}
-				boffs = free->offset + roffs;
-				bytes = min_t(size_t, len,
-					      (free->length - roffs));
-				roffs = 0;
-			} else {
-				bytes = min_t(size_t, len, free->length);
-				boffs = free->offset;
-			}
-			memcpy(oob, chip->oob_poi + boffs, bytes);
-			oob += bytes;
-		}
-		return oob;
-	}
+	case MTD_OPS_AUTO_OOB:
+		ret = mtd_ooblayout_get_databytes(mtd, oob, chip->oob_poi,
+						  ops->ooboffs, len);
+		BUG_ON(ret);
+		return oob + len;
+
 	default:
 		BUG();
 	}
@@ -1810,7 +1801,7 @@ read_retry:
 				int toread = min(oobreadlen, max_oobsize);
 
 				if (toread) {
-					oob = nand_transfer_oob(chip,
+					oob = nand_transfer_oob(mtd,
 						oob, ops, toread);
 					oobreadlen -= toread;
 				}
@@ -2108,7 +2099,7 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
 			break;
 
 		len = min(len, readlen);
-		buf = nand_transfer_oob(chip, buf, ops, len);
+		buf = nand_transfer_oob(mtd, buf, ops, len);
 
 		if (chip->options & NAND_NEED_READRDY) {
 			/* Apply delay or wait for ready/busy pin */
@@ -2267,19 +2258,20 @@ static int nand_write_page_swecc(struct mtd_info *mtd, struct nand_chip *chip,
 				 const uint8_t *buf, int oob_required,
 				 int page)
 {
-	int i, eccsize = chip->ecc.size;
+	int i, eccsize = chip->ecc.size, ret;
 	int eccbytes = chip->ecc.bytes;
 	int eccsteps = chip->ecc.steps;
 	uint8_t *ecc_calc = chip->buffers->ecccalc;
 	const uint8_t *p = buf;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 
 	/* Software ECC calculation */
 	for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize)
 		chip->ecc.calculate(mtd, p, &ecc_calc[i]);
 
-	for (i = 0; i < chip->ecc.total; i++)
-		chip->oob_poi[eccpos[i]] = ecc_calc[i];
+	ret = mtd_ooblayout_set_eccbytes(mtd, ecc_calc, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	return chip->ecc.write_page_raw(mtd, chip, buf, 1, page);
 }
@@ -2296,12 +2288,11 @@ static int nand_write_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
 				  const uint8_t *buf, int oob_required,
 				  int page)
 {
-	int i, eccsize = chip->ecc.size;
+	int i, eccsize = chip->ecc.size, ret;
 	int eccbytes = chip->ecc.bytes;
 	int eccsteps = chip->ecc.steps;
 	uint8_t *ecc_calc = chip->buffers->ecccalc;
 	const uint8_t *p = buf;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 
 	for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
 		chip->ecc.hwctl(mtd, NAND_ECC_WRITE);
@@ -2309,8 +2300,10 @@ static int nand_write_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
 		chip->ecc.calculate(mtd, p, &ecc_calc[i]);
 	}
 
-	for (i = 0; i < chip->ecc.total; i++)
-		chip->oob_poi[eccpos[i]] = ecc_calc[i];
+	ret = mtd_ooblayout_set_eccbytes(mtd, ecc_calc, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	chip->write_buf(mtd, chip->oob_poi, mtd->oobsize);
 
@@ -2338,11 +2331,10 @@ static int nand_write_subpage_hwecc(struct mtd_info *mtd,
 	int ecc_size      = chip->ecc.size;
 	int ecc_bytes     = chip->ecc.bytes;
 	int ecc_steps     = chip->ecc.steps;
-	uint32_t *eccpos  = chip->ecc.layout->eccpos;
 	uint32_t start_step = offset / ecc_size;
 	uint32_t end_step   = (offset + data_len - 1) / ecc_size;
 	int oob_bytes       = mtd->oobsize / ecc_steps;
-	int step, i;
+	int step, ret;
 
 	for (step = 0; step < ecc_steps; step++) {
 		/* configure controller for WRITE access */
@@ -2370,8 +2362,10 @@ static int nand_write_subpage_hwecc(struct mtd_info *mtd,
 	/* copy calculated ECC for whole page to chip->buffer->oob */
 	/* this include masked-value(0xFF) for unwritten subpages */
 	ecc_calc = chip->buffers->ecccalc;
-	for (i = 0; i < chip->ecc.total; i++)
-		chip->oob_poi[eccpos[i]] = ecc_calc[i];
+	ret = mtd_ooblayout_set_eccbytes(mtd, ecc_calc, chip->oob_poi, 0,
+					 chip->ecc.total);
+	if (ret)
+		return ret;
 
 	/* write OOB buffer to NAND device */
 	chip->write_buf(mtd, chip->oob_poi, mtd->oobsize);
@@ -2508,6 +2502,7 @@ static uint8_t *nand_fill_oob(struct mtd_info *mtd, uint8_t *oob, size_t len,
 			      struct mtd_oob_ops *ops)
 {
 	struct nand_chip *chip = mtd_to_nand(mtd);
+	int ret;
 
 	/*
 	 * Initialise to all 0xFF, to avoid the possibility of left over OOB
@@ -2522,31 +2517,12 @@ static uint8_t *nand_fill_oob(struct mtd_info *mtd, uint8_t *oob, size_t len,
 		memcpy(chip->oob_poi + ops->ooboffs, oob, len);
 		return oob + len;
 
-	case MTD_OPS_AUTO_OOB: {
-		struct nand_oobfree *free = chip->ecc.layout->oobfree;
-		uint32_t boffs = 0, woffs = ops->ooboffs;
-		size_t bytes = 0;
-
-		for (; free->length && len; free++, len -= bytes) {
-			/* Write request not from offset 0? */
-			if (unlikely(woffs)) {
-				if (woffs >= free->length) {
-					woffs -= free->length;
-					continue;
-				}
-				boffs = free->offset + woffs;
-				bytes = min_t(size_t, len,
-					      (free->length - woffs));
-				woffs = 0;
-			} else {
-				bytes = min_t(size_t, len, free->length);
-				boffs = free->offset;
-			}
-			memcpy(chip->oob_poi + boffs, oob, bytes);
-			oob += bytes;
-		}
-		return oob;
-	}
+	case MTD_OPS_AUTO_OOB:
+		ret = mtd_ooblayout_set_databytes(mtd, oob, chip->oob_poi,
+						  ops->ooboffs, len);
+		BUG_ON(ret);
+		return oob + len;
+
 	default:
 		BUG();
 	}
@@ -4116,10 +4092,10 @@ static bool nand_ecc_strength_good(struct mtd_info *mtd)
  */
 int nand_scan_tail(struct mtd_info *mtd)
 {
-	int i;
 	struct nand_chip *chip = mtd_to_nand(mtd);
 	struct nand_ecc_ctrl *ecc = &chip->ecc;
 	struct nand_buffers *nbuf;
+	int ret;
 
 	/* New bad blocks should be marked in OOB, flash-based BBT, or both */
 	BUG_ON((chip->bbt_options & NAND_BBT_NO_OOB_BBM) &&
@@ -4311,15 +4287,20 @@ int nand_scan_tail(struct mtd_info *mtd)
 	if (!ecc->write_oob_raw)
 		ecc->write_oob_raw = ecc->write_oob;
 
+	/* propagate ecc info to mtd_info */
+	mtd->ecclayout = ecc->layout;
+	mtd->ecc_strength = ecc->strength;
+	mtd->ecc_step_size = ecc->size;
+
 	/*
 	 * The number of bytes available for a client to place data into
 	 * the out of band area.
 	 */
-	mtd->oobavail = 0;
-	if (ecc->layout) {
-		for (i = 0; ecc->layout->oobfree[i].length; i++)
-			mtd->oobavail += ecc->layout->oobfree[i].length;
-	}
+	ret = mtd_ooblayout_count_freebytes(mtd);
+	if (ret < 0)
+		ret = 0;
+
+	mtd->oobavail = ret;
 
 	/* ECC sanity check: warn if it's too weak */
 	if (!nand_ecc_strength_good(mtd))
@@ -4393,10 +4374,6 @@ int nand_scan_tail(struct mtd_info *mtd)
 	mtd->_block_markbad = nand_block_markbad;
 	mtd->writebufsize = mtd->writesize;
 
-	/* propagate ecc info to mtd_info */
-	mtd->ecclayout = ecc->layout;
-	mtd->ecc_strength = ecc->strength;
-	mtd->ecc_step_size = ecc->size;
 	/*
 	 * Initialize bitflip_threshold to its default prior scan_bbt() call.
 	 * scan_bbt() might invoke mtd_read(), thus bitflip_threshold must be
diff --git a/drivers/mtd/nand/nand_bch.c b/drivers/mtd/nand/nand_bch.c
index b585bae..b3039de 100644
--- a/drivers/mtd/nand/nand_bch.c
+++ b/drivers/mtd/nand/nand_bch.c
@@ -196,7 +196,8 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
 		printk(KERN_WARNING "eccsize %u is too large\n", eccsize);
 		goto fail;
 	}
-	if (layout->eccbytes != (eccsteps*eccbytes)) {
+
+	if (mtd_ooblayout_count_eccbytes(mtd) != (eccsteps*eccbytes)) {
 		printk(KERN_WARNING "invalid ecc layout\n");
 		goto fail;
 	}
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:16 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:16 +0100
Subject: [PATCH v3 08/52] mtd: nand: atmel: use mtd_ooblayout_xxx() helpers
 where appropriate
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-9-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/atmel_nand.c | 48 ++++++++++++++++++++++++++-----------------
 1 file changed, 29 insertions(+), 19 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 20cbaab..ac3dd3f 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -836,13 +836,16 @@ static void pmecc_correct_data(struct mtd_info *mtd, uint8_t *buf, uint8_t *ecc,
 			dev_dbg(host->dev, "Bit flip in data area, byte_pos: %d, bit_pos: %d, 0x%02x -> 0x%02x\n",
 				pos, bit_pos, err_byte, *(buf + byte_pos));
 		} else {
+			struct mtd_oob_region oobregion;
+
 			/* Bit flip in OOB area */
 			tmp = sector_num * nand_chip->ecc.bytes
 					+ (byte_pos - sector_size);
 			err_byte = ecc[tmp];
 			ecc[tmp] ^= (1 << bit_pos);
 
-			pos = tmp + nand_chip->ecc.layout->eccpos[0];
+			mtd_ooblayout_ecc(mtd, 0, &oobregion);
+			pos = tmp + oobregion.offset;
 			dev_dbg(host->dev, "Bit flip in OOB, oob_byte_pos: %d, bit_pos: %d, 0x%02x -> 0x%02x\n",
 				pos, bit_pos, err_byte, ecc[tmp]);
 		}
@@ -931,7 +934,6 @@ static int atmel_nand_pmecc_read_page(struct mtd_info *mtd,
 	struct atmel_nand_host *host = nand_get_controller_data(chip);
 	int eccsize = chip->ecc.size * chip->ecc.steps;
 	uint8_t *oob = chip->oob_poi;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 	uint32_t stat;
 	unsigned long end_time;
 	int bitflips = 0;
@@ -953,7 +955,11 @@ static int atmel_nand_pmecc_read_page(struct mtd_info *mtd,
 
 	stat = pmecc_readl_relaxed(host->ecc, ISR);
 	if (stat != 0) {
-		bitflips = pmecc_correction(mtd, stat, buf, &oob[eccpos[0]]);
+		struct mtd_oob_region oobregion;
+
+		mtd_ooblayout_ecc(mtd, 0, &oobregion);
+		bitflips = pmecc_correction(mtd, stat, buf,
+					    &oob[oobregion.offset]);
 		if (bitflips < 0)
 			/* uncorrectable errors */
 			return 0;
@@ -967,8 +973,8 @@ static int atmel_nand_pmecc_write_page(struct mtd_info *mtd,
 		int page)
 {
 	struct atmel_nand_host *host = nand_get_controller_data(chip);
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
-	int i, j;
+	struct mtd_oob_region oobregion = { };
+	int i, j, section = 0;
 	unsigned long end_time;
 
 	if (!host->nfc || !host->nfc->write_by_sram) {
@@ -987,11 +993,12 @@ static int atmel_nand_pmecc_write_page(struct mtd_info *mtd,
 
 	for (i = 0; i < chip->ecc.steps; i++) {
 		for (j = 0; j < chip->ecc.bytes; j++) {
-			int pos;
+			if (!oobregion.length)
+				mtd_ooblayout_ecc(mtd, section++, &oobregion);
 
-			pos = i * chip->ecc.bytes + j;
-			chip->oob_poi[eccpos[pos]] =
+			chip->oob_poi[oobregion.offset++] =
 				pmecc_readb_ecc_relaxed(host->ecc, i, j);
+			oobregion.length--;
 		}
 	}
 	chip->write_buf(mtd, chip->oob_poi, mtd->oobsize);
@@ -1005,6 +1012,7 @@ static void atmel_pmecc_core_init(struct mtd_info *mtd)
 	struct atmel_nand_host *host = nand_get_controller_data(nand_chip);
 	uint32_t val = 0;
 	struct nand_ecclayout *ecc_layout;
+	struct mtd_oob_region oobregion;
 
 	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_RST);
 	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DISABLE);
@@ -1056,9 +1064,10 @@ static void atmel_pmecc_core_init(struct mtd_info *mtd)
 
 	ecc_layout = nand_chip->ecc.layout;
 	pmecc_writel(host->ecc, SAREA, mtd->oobsize - 1);
-	pmecc_writel(host->ecc, SADDR, ecc_layout->eccpos[0]);
+	mtd_ooblayout_ecc(mtd, 0, &oobregion);
+	pmecc_writel(host->ecc, SADDR, oobregion.offset);
 	pmecc_writel(host->ecc, EADDR,
-			ecc_layout->eccpos[ecc_layout->eccbytes - 1]);
+		     oobregion.offset + ecc_layout->eccbytes - 1);
 	/* See datasheet about PMECC Clock Control Register */
 	pmecc_writel(host->ecc, CLK, 2);
 	pmecc_writel(host->ecc, IDR, 0xff);
@@ -1359,12 +1368,12 @@ static int atmel_nand_read_page(struct mtd_info *mtd, struct nand_chip *chip,
 {
 	int eccsize = chip->ecc.size;
 	int eccbytes = chip->ecc.bytes;
-	uint32_t *eccpos = chip->ecc.layout->eccpos;
 	uint8_t *p = buf;
 	uint8_t *oob = chip->oob_poi;
 	uint8_t *ecc_pos;
 	int stat;
 	unsigned int max_bitflips = 0;
+	struct mtd_oob_region oobregion = {};
 
 	/*
 	 * Errata: ALE is incorrectly wired up to the ECC controller
@@ -1382,19 +1391,20 @@ static int atmel_nand_read_page(struct mtd_info *mtd, struct nand_chip *chip,
 	chip->read_buf(mtd, p, eccsize);
 
 	/* move to ECC position if needed */
-	if (eccpos[0] != 0) {
-		/* This only works on large pages
-		 * because the ECC controller waits for
-		 * NAND_CMD_RNDOUTSTART after the
-		 * NAND_CMD_RNDOUT.
-		 * anyway, for small pages, the eccpos[0] == 0
+	mtd_ooblayout_ecc(mtd, 0, &oobregion);
+	if (oobregion.offset != 0) {
+		/*
+		 * This only works on large pages because the ECC controller
+		 * waits for NAND_CMD_RNDOUTSTART after the NAND_CMD_RNDOUT.
+		 * Anyway, for small pages, the first ECC byte is at offset
+		 * 0 in the OOB area.
 		 */
 		chip->cmdfunc(mtd, NAND_CMD_RNDOUT,
-				mtd->writesize + eccpos[0], -1);
+			      mtd->writesize + oobregion.offset, -1);
 	}
 
 	/* the ECC controller needs to read the ECC just after the data */
-	ecc_pos = oob + eccpos[0];
+	ecc_pos = oob + oobregion.offset;
 	chip->read_buf(mtd, ecc_pos, eccbytes);
 
 	/* check if there's an error */
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:17 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:17 +0100
Subject: [PATCH v3 09/52] mtd: nand: fsl_ifc: use mtd_ooblayout_xxx() helpers
 where appropriate
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-10-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/fsl_ifc_nand.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 43f5a3a..2e970ac 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -257,18 +257,22 @@ static int is_blank(struct mtd_info *mtd, unsigned int bufnum)
 	u8 __iomem *addr = priv->vbase + bufnum * (mtd->writesize * 2);
 	u32 __iomem *mainarea = (u32 __iomem *)addr;
 	u8 __iomem *oob = addr + mtd->writesize;
-	int i;
+	struct mtd_oob_region oobregion = { };
+	int i, section = 0;
 
 	for (i = 0; i < mtd->writesize / 4; i++) {
 		if (__raw_readl(&mainarea[i]) != 0xffffffff)
 			return 0;
 	}
 
-	for (i = 0; i < chip->ecc.layout->eccbytes; i++) {
-		int pos = chip->ecc.layout->eccpos[i];
+	mtd_ooblayout_ecc(mtd, section++, &oobregion);
+	while (oobregion.length) {
+		for (i = 0; i < oobregion.length; i++) {
+			if (__raw_readb(&oob[oobregion.offset + i]) != 0xff)
+				return 0;
+		}
 
-		if (__raw_readb(&oob[pos]) != 0xff)
-			return 0;
+		mtd_ooblayout_ecc(mtd, section++, &oobregion);
 	}
 
 	return 1;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:18 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:18 +0100
Subject: [PATCH v3 10/52] mtd: nand: gpmi: use mtd_ooblayout_xxx() helpers
 where appropriate
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-11-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 8122c69..3a29b65 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1327,18 +1327,19 @@ static int gpmi_ecc_read_oob(struct mtd_info *mtd, struct nand_chip *chip,
 static int
 gpmi_ecc_write_oob(struct mtd_info *mtd, struct nand_chip *chip, int page)
 {
-	struct nand_oobfree *of = mtd->ecclayout->oobfree;
+	struct mtd_oob_region of = { };
 	int status = 0;
 
 	/* Do we have available oob area? */
-	if (!of->length)
+	mtd_ooblayout_free(mtd, 0, &of);
+	if (!of.length)
 		return -EPERM;
 
 	if (!nand_is_slc(chip))
 		return -EPERM;
 
-	chip->cmdfunc(mtd, NAND_CMD_SEQIN, mtd->writesize + of->offset, page);
-	chip->write_buf(mtd, chip->oob_poi + of->offset, of->length);
+	chip->cmdfunc(mtd, NAND_CMD_SEQIN, mtd->writesize + of.offset, page);
+	chip->write_buf(mtd, chip->oob_poi + of.offset, of.length);
 	chip->cmdfunc(mtd, NAND_CMD_PAGEPROG, -1, -1);
 
 	status = chip->waitfunc(mtd, chip);
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:21 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:21 +0100
Subject: [PATCH v3 13/52] mtd: onenand: use mtd_ooblayout_xxx() helpers where
 appropriate
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-14-git-send-email-boris.brezillon@free-electrons.com>

The mtd_ooblayout_xxx() helper functions have been added to avoid direct
accesses to the ecclayout field, and thus ease for future reworks.
Use these helpers in all places where the oobfree[] and eccpos[] arrays
where directly accessed.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/onenand/onenand_base.c | 75 ++++++++------------------------------
 1 file changed, 15 insertions(+), 60 deletions(-)

diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index af28bb3..20fdf8c 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1024,34 +1024,15 @@ static int onenand_transfer_auto_oob(struct mtd_info *mtd, uint8_t *buf, int col
 				int thislen)
 {
 	struct onenand_chip *this = mtd->priv;
-	struct nand_oobfree *free;
-	int readcol = column;
-	int readend = column + thislen;
-	int lastgap = 0;
-	unsigned int i;
-	uint8_t *oob_buf = this->oob_buf;
-
-	free = this->ecclayout->oobfree;
-	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES && free->length; i++, free++) {
-		if (readcol >= lastgap)
-			readcol += free->offset - lastgap;
-		if (readend >= lastgap)
-			readend += free->offset - lastgap;
-		lastgap = free->offset + free->length;
-	}
-	this->read_bufferram(mtd, ONENAND_SPARERAM, oob_buf, 0, mtd->oobsize);
-	free = this->ecclayout->oobfree;
-	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES && free->length; i++, free++) {
-		int free_end = free->offset + free->length;
-		if (free->offset < readend && free_end > readcol) {
-			int st = max_t(int,free->offset,readcol);
-			int ed = min_t(int,free_end,readend);
-			int n = ed - st;
-			memcpy(buf, oob_buf + st, n);
-			buf += n;
-		} else if (column == 0)
-			break;
-	}
+	int ret;
+
+	this->read_bufferram(mtd, ONENAND_SPARERAM, this->oob_buf, 0,
+			     mtd->oobsize);
+	ret = mtd_ooblayout_get_databytes(mtd, buf, this->oob_buf,
+					  column, thislen);
+	if (ret)
+		return ret;
+
 	return 0;
 }
 
@@ -1808,34 +1789,7 @@ static int onenand_panic_write(struct mtd_info *mtd, loff_t to, size_t len,
 static int onenand_fill_auto_oob(struct mtd_info *mtd, u_char *oob_buf,
 				  const u_char *buf, int column, int thislen)
 {
-	struct onenand_chip *this = mtd->priv;
-	struct nand_oobfree *free;
-	int writecol = column;
-	int writeend = column + thislen;
-	int lastgap = 0;
-	unsigned int i;
-
-	free = this->ecclayout->oobfree;
-	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES && free->length; i++, free++) {
-		if (writecol >= lastgap)
-			writecol += free->offset - lastgap;
-		if (writeend >= lastgap)
-			writeend += free->offset - lastgap;
-		lastgap = free->offset + free->length;
-	}
-	free = this->ecclayout->oobfree;
-	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES && free->length; i++, free++) {
-		int free_end = free->offset + free->length;
-		if (free->offset < writeend && free_end > writecol) {
-			int st = max_t(int,free->offset,writecol);
-			int ed = min_t(int,free_end,writeend);
-			int n = ed - st;
-			memcpy(oob_buf + st, buf, n);
-			buf += n;
-		} else if (column == 0)
-			break;
-	}
-	return 0;
+	return mtd_ooblayout_set_databytes(mtd, buf, oob_buf, column, thislen);
 }
 
 /**
@@ -4037,10 +3991,11 @@ int onenand_scan(struct mtd_info *mtd, int maxchips)
 	 * The number of bytes available for a client to place data into
 	 * the out of band area
 	 */
-	mtd->oobavail = 0;
-	for (i = 0; i < MTD_MAX_OOBFREE_ENTRIES &&
-	    this->ecclayout->oobfree[i].length; i++)
-		mtd->oobavail += this->ecclayout->oobfree[i].length;
+	ret = mtd_ooblayout_count_freebytes(mtd);
+	if (ret < 0)
+		ret = 0;
+
+	mtd->oobavail = ret;
 
 	mtd->ecclayout = this->ecclayout;
 	mtd->ecc_strength = 1;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:24 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:24 +0100
Subject: [PATCH v3 16/52] mtd: nand: use mtd_set_ecclayout() where appropriate
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-17-git-send-email-boris.brezillon@free-electrons.com>

Use the mtd_set_ecclayout() helper instead of directly assigning the
mtd->ecclayout field.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/nand_base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 17504f2..5093a3c 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -4288,7 +4288,7 @@ int nand_scan_tail(struct mtd_info *mtd)
 		ecc->write_oob_raw = ecc->write_oob;
 
 	/* propagate ecc info to mtd_info */
-	mtd->ecclayout = ecc->layout;
+	mtd_set_ecclayout(mtd, ecc->layout);
 	mtd->ecc_strength = ecc->strength;
 	mtd->ecc_step_size = ecc->size;
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:32 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:32 +0100
Subject: [PATCH v3 24/52] mtd: nand: jz4740: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-25-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 arch/mips/include/asm/mach-jz4740/jz4740_nand.h |  2 +-
 arch/mips/jz4740/board-qi_lb60.c                | 87 +++++++++++++++----------
 drivers/mtd/nand/jz4740_nand.c                  |  2 +-
 3 files changed, 53 insertions(+), 38 deletions(-)

diff --git a/arch/mips/include/asm/mach-jz4740/jz4740_nand.h b/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
index 398733e..7f7b0fc 100644
--- a/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
+++ b/arch/mips/include/asm/mach-jz4740/jz4740_nand.h
@@ -27,7 +27,7 @@ struct jz_nand_platform_data {
 
 	unsigned char banks[JZ_NAND_NUM_BANKS];
 
-	void (*ident_callback)(struct platform_device *, struct nand_chip *,
+	void (*ident_callback)(struct platform_device *, struct mtd_info *,
 				struct mtd_partition **, int *num_partitions);
 };
 
diff --git a/arch/mips/jz4740/board-qi_lb60.c b/arch/mips/jz4740/board-qi_lb60.c
index 934b15b..a1c1afb 100644
--- a/arch/mips/jz4740/board-qi_lb60.c
+++ b/arch/mips/jz4740/board-qi_lb60.c
@@ -50,20 +50,6 @@ static bool is_avt2;
 #define QI_LB60_GPIO_KEYIN8		JZ_GPIO_PORTD(26)
 
 /* NAND */
-static struct nand_ecclayout qi_lb60_ecclayout_1gb = {
-	.eccbytes = 36,
-	.eccpos = {
-		6,  7,	8,  9,	10, 11, 12, 13,
-		14, 15, 16, 17, 18, 19, 20, 21,
-		22, 23, 24, 25, 26, 27, 28, 29,
-		30, 31, 32, 33, 34, 35, 36, 37,
-		38, 39, 40, 41
-	},
-	.oobfree = {
-		{ .offset = 2, .length = 4 },
-		{ .offset = 42, .length = 22 }
-	},
-};
 
 /* Early prototypes of the QI LB60 had only 1GB of NAND.
  * In order to support these devices as well the partition and ecc layout is
@@ -86,25 +72,6 @@ static struct mtd_partition qi_lb60_partitions_1gb[] = {
 	},
 };
 
-static struct nand_ecclayout qi_lb60_ecclayout_2gb = {
-	.eccbytes = 72,
-	.eccpos = {
-		12, 13, 14, 15, 16, 17, 18, 19,
-		20, 21, 22, 23, 24, 25, 26, 27,
-		28, 29, 30, 31, 32, 33, 34, 35,
-		36, 37, 38, 39, 40, 41, 42, 43,
-		44, 45, 46, 47, 48, 49, 50, 51,
-		52, 53, 54, 55, 56, 57, 58, 59,
-		60, 61, 62, 63, 64, 65, 66, 67,
-		68, 69, 70, 71, 72, 73, 74, 75,
-		76, 77, 78, 79, 80, 81, 82, 83
-	},
-	.oobfree = {
-		{ .offset = 2, .length = 10 },
-		{ .offset = 84, .length = 44 },
-	},
-};
-
 static struct mtd_partition qi_lb60_partitions_2gb[] = {
 	{
 		.name = "NAND BOOT partition",
@@ -123,19 +90,67 @@ static struct mtd_partition qi_lb60_partitions_2gb[] = {
 	},
 };
 
+static int qi_lb60_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->length = 36;
+	oobregion->offset = 6;
+
+	if (mtd->oobsize == 128) {
+		oobregion->length *= 2;
+		oobregion->offset *= 2;
+	}
+
+	return 0;
+}
+
+static int qi_lb60_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	int eccbytes = 36, eccoff = 6;
+
+	if (section > 1)
+		return -ERANGE;
+
+	if (mtd->oobsize == 128) {
+		eccbytes *= 2;
+		eccoff *= 2;
+	}
+
+	if (!section) {
+		oobregion->offset = 2;
+		oobregion->length = eccoff - 2;
+	} else {
+		oobregion->offset = eccoff + eccbytes;
+		oobregion->length = mtd->oobsize - oobregion->offset;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops qi_lb60_ooblayout_ops = {
+	.ecc = qi_lb60_ooblayout_ecc,
+	.free = qi_lb60_ooblayout_free,
+};
+
 static void qi_lb60_nand_ident(struct platform_device *pdev,
-		struct nand_chip *chip, struct mtd_partition **partitions,
+		struct mtd_info *mtd, struct mtd_partition **partitions,
 		int *num_partitions)
 {
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
 	if (chip->page_shift == 12) {
-		chip->ecc.layout = &qi_lb60_ecclayout_2gb;
 		*partitions = qi_lb60_partitions_2gb;
 		*num_partitions = ARRAY_SIZE(qi_lb60_partitions_2gb);
 	} else {
-		chip->ecc.layout = &qi_lb60_ecclayout_1gb;
 		*partitions = qi_lb60_partitions_1gb;
 		*num_partitions = ARRAY_SIZE(qi_lb60_partitions_1gb);
 	}
+
+	mtd_set_ooblayout(mtd, &qi_lb60_ooblayout_ops);
 }
 
 static struct jz_nand_platform_data qi_lb60_nand_pdata = {
diff --git a/drivers/mtd/nand/jz4740_nand.c b/drivers/mtd/nand/jz4740_nand.c
index 673ceb2..df74408 100644
--- a/drivers/mtd/nand/jz4740_nand.c
+++ b/drivers/mtd/nand/jz4740_nand.c
@@ -476,7 +476,7 @@ static int jz_nand_probe(struct platform_device *pdev)
 	}
 
 	if (pdata && pdata->ident_callback) {
-		pdata->ident_callback(pdev, chip, &pdata->partitions,
+		pdata->ident_callback(pdev, mtd, &pdata->partitions,
 					&pdata->num_partitions);
 	}
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:33 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:33 +0100
Subject: [PATCH v3 25/52] mtd: nand: atmel: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-26-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/atmel_nand.c | 84 ++++++++++++++++++++-----------------------
 1 file changed, 38 insertions(+), 46 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index ac3dd3f..a922193 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -72,30 +72,44 @@ struct atmel_nand_nfc_caps {
 	uint32_t rb_mask;
 };
 
-/* oob layout for large page size
+/*
+ * oob layout for large page size
  * bad block info is on bytes 0 and 1
  * the bytes have to be consecutives to avoid
  * several NAND_CMD_RNDOUT during read
- */
-static struct nand_ecclayout atmel_oobinfo_large = {
-	.eccbytes = 4,
-	.eccpos = {60, 61, 62, 63},
-	.oobfree = {
-		{2, 58}
-	},
-};
-
-/* oob layout for small page size
+ *
+ * oob layout for small page size
  * bad block info is on bytes 4 and 5
  * the bytes have to be consecutives to avoid
  * several NAND_CMD_RNDOUT during read
  */
-static struct nand_ecclayout atmel_oobinfo_small = {
-	.eccbytes = 4,
-	.eccpos = {0, 1, 2, 3},
-	.oobfree = {
-		{6, 10}
-	},
+static int atmel_ooblayout_ecc_sp(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->length = 4;
+	oobregion->offset = 0;
+
+	return 0;
+}
+
+static int atmel_ooblayout_free_sp(struct mtd_info *mtd, int section,
+				   struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 6;
+	oobregion->length = mtd->oobsize - oobregion->offset;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops atmel_ooblayout_sp_ops = {
+	.ecc = atmel_ooblayout_ecc_sp,
+	.free = atmel_ooblayout_free_sp,
 };
 
 struct atmel_nfc {
@@ -163,8 +177,6 @@ struct atmel_nand_host {
 	int			*pmecc_delta;
 };
 
-static struct nand_ecclayout atmel_pmecc_oobinfo;
-
 /*
  * Enable NAND.
  */
@@ -483,22 +495,6 @@ static int pmecc_get_ecc_bytes(int cap, int sector_size)
 	return (m * cap + 7) / 8;
 }
 
-static void pmecc_config_ecc_layout(struct nand_ecclayout *layout,
-				    int oobsize, int ecc_len)
-{
-	int i;
-
-	layout->eccbytes = ecc_len;
-
-	/* ECC will occupy the last ecc_len bytes continuously */
-	for (i = 0; i < ecc_len; i++)
-		layout->eccpos[i] = oobsize - ecc_len + i;
-
-	layout->oobfree[0].offset = PMECC_OOB_RESERVED_BYTES;
-	layout->oobfree[0].length =
-		oobsize - ecc_len - layout->oobfree[0].offset;
-}
-
 static void __iomem *pmecc_get_alpha_to(struct atmel_nand_host *host)
 {
 	int table_size;
@@ -1010,8 +1006,8 @@ static void atmel_pmecc_core_init(struct mtd_info *mtd)
 {
 	struct nand_chip *nand_chip = mtd_to_nand(mtd);
 	struct atmel_nand_host *host = nand_get_controller_data(nand_chip);
+	int eccbytes = mtd_ooblayout_count_eccbytes(mtd);
 	uint32_t val = 0;
-	struct nand_ecclayout *ecc_layout;
 	struct mtd_oob_region oobregion;
 
 	pmecc_writel(host->ecc, CTRL, PMECC_CTRL_RST);
@@ -1062,12 +1058,11 @@ static void atmel_pmecc_core_init(struct mtd_info *mtd)
 		| PMECC_CFG_AUTO_DISABLE);
 	pmecc_writel(host->ecc, CFG, val);
 
-	ecc_layout = nand_chip->ecc.layout;
 	pmecc_writel(host->ecc, SAREA, mtd->oobsize - 1);
 	mtd_ooblayout_ecc(mtd, 0, &oobregion);
 	pmecc_writel(host->ecc, SADDR, oobregion.offset);
 	pmecc_writel(host->ecc, EADDR,
-		     oobregion.offset + ecc_layout->eccbytes - 1);
+		     oobregion.offset + eccbytes - 1);
 	/* See datasheet about PMECC Clock Control Register */
 	pmecc_writel(host->ecc, CLK, 2);
 	pmecc_writel(host->ecc, IDR, 0xff);
@@ -1289,11 +1284,8 @@ static int atmel_pmecc_nand_init_params(struct platform_device *pdev,
 			err_no = -EINVAL;
 			goto err;
 		}
-		pmecc_config_ecc_layout(&atmel_pmecc_oobinfo,
-					mtd->oobsize,
-					nand_chip->ecc.total);
 
-		nand_chip->ecc.layout = &atmel_pmecc_oobinfo;
+		mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
 		break;
 	default:
 		dev_warn(host->dev,
@@ -1641,19 +1633,19 @@ static int atmel_hw_nand_init_params(struct platform_device *pdev,
 	/* set ECC page size and oob layout */
 	switch (mtd->writesize) {
 	case 512:
-		nand_chip->ecc.layout = &atmel_oobinfo_small;
+		mtd_set_ooblayout(mtd, &atmel_ooblayout_sp_ops);
 		ecc_writel(host->ecc, MR, ATMEL_ECC_PAGESIZE_528);
 		break;
 	case 1024:
-		nand_chip->ecc.layout = &atmel_oobinfo_large;
+		mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
 		ecc_writel(host->ecc, MR, ATMEL_ECC_PAGESIZE_1056);
 		break;
 	case 2048:
-		nand_chip->ecc.layout = &atmel_oobinfo_large;
+		mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
 		ecc_writel(host->ecc, MR, ATMEL_ECC_PAGESIZE_2112);
 		break;
 	case 4096:
-		nand_chip->ecc.layout = &atmel_oobinfo_large;
+		mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
 		ecc_writel(host->ecc, MR, ATMEL_ECC_PAGESIZE_4224);
 		break;
 	default:
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:34 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:34 +0100
Subject: [PATCH v3 26/52] mtd: nand: bf5xx: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-27-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/bf5xx_nand.c | 51 ++++++++++++++++++++++++-------------------
 1 file changed, 28 insertions(+), 23 deletions(-)

diff --git a/drivers/mtd/nand/bf5xx_nand.c b/drivers/mtd/nand/bf5xx_nand.c
index 7f6b30e..b38f414 100644
--- a/drivers/mtd/nand/bf5xx_nand.c
+++ b/drivers/mtd/nand/bf5xx_nand.c
@@ -109,28 +109,33 @@ static const unsigned short bfin_nfc_pin_req[] =
 	 0};
 
 #ifdef CONFIG_MTD_NAND_BF5XX_BOOTROM_ECC
-static struct nand_ecclayout bootrom_ecclayout = {
-	.eccbytes = 24,
-	.eccpos = {
-		0x8 * 0, 0x8 * 0 + 1, 0x8 * 0 + 2,
-		0x8 * 1, 0x8 * 1 + 1, 0x8 * 1 + 2,
-		0x8 * 2, 0x8 * 2 + 1, 0x8 * 2 + 2,
-		0x8 * 3, 0x8 * 3 + 1, 0x8 * 3 + 2,
-		0x8 * 4, 0x8 * 4 + 1, 0x8 * 4 + 2,
-		0x8 * 5, 0x8 * 5 + 1, 0x8 * 5 + 2,
-		0x8 * 6, 0x8 * 6 + 1, 0x8 * 6 + 2,
-		0x8 * 7, 0x8 * 7 + 1, 0x8 * 7 + 2
-	},
-	.oobfree = {
-		{ 0x8 * 0 + 3, 5 },
-		{ 0x8 * 1 + 3, 5 },
-		{ 0x8 * 2 + 3, 5 },
-		{ 0x8 * 3 + 3, 5 },
-		{ 0x8 * 4 + 3, 5 },
-		{ 0x8 * 5 + 3, 5 },
-		{ 0x8 * 6 + 3, 5 },
-		{ 0x8 * 7 + 3, 5 },
-	}
+static int bootrom_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	if (section > 7)
+		return -ERANGE;
+
+	oobregion->offset = section * 8;
+	oobregion->length = 3;
+
+	return 0;
+}
+
+static int bootrom_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	if (section > 7)
+		return -ERANGE;
+
+	oobregion->offset = (section * 8) + 3;
+	oobregion->length = 5;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops bootrom_ooblayout_ops = {
+	.ecc = bootrom_ooblayout_ecc,
+	.free = bootrom_ooblayout_free,
 };
 #endif
 
@@ -800,7 +805,7 @@ static int bf5xx_nand_probe(struct platform_device *pdev)
 	/* setup hardware ECC data struct */
 	if (hardware_ecc) {
 #ifdef CONFIG_MTD_NAND_BF5XX_BOOTROM_ECC
-		chip->ecc.layout = &bootrom_ecclayout;
+		mtd_set_ooblayout(mtd, &bootrom_ooblayout_ops);
 #endif
 		chip->read_buf      = bf5xx_nand_dma_read_buf;
 		chip->write_buf     = bf5xx_nand_dma_write_buf;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:35 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:35 +0100
Subject: [PATCH v3 27/52] mtd: nand: brcm: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-28-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/brcmnand/brcmnand.c | 258 +++++++++++++++++++++--------------
 1 file changed, 157 insertions(+), 101 deletions(-)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c b/drivers/mtd/nand/brcmnand/brcmnand.c
index e052839..4c3c0a9 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -781,127 +781,183 @@ static inline bool is_hamming_ecc(struct brcmnand_cfg *cfg)
 }
 
 /*
- * Returns a nand_ecclayout strucutre for the given layout/configuration.
- * Returns NULL on failure.
+ * Set mtd->ooblayout to the appropriate mtd_ooblayout_ops given
+ * the layout/configuration.
+ * Returns -ERRCODE on failure.
  */
-static struct nand_ecclayout *brcmnand_create_layout(int ecc_level,
-						     struct brcmnand_host *host)
+static int brcmnand_hamming_ooblayout_ecc(struct mtd_info *mtd, int section,
+					  struct mtd_oob_region *oobregion)
 {
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct brcmnand_host *host = nand_get_controller_data(chip);
 	struct brcmnand_cfg *cfg = &host->hwcfg;
-	int i, j;
-	struct nand_ecclayout *layout;
-	int req;
-	int sectors;
-	int sas;
-	int idx1, idx2;
-
-	layout = devm_kzalloc(&host->pdev->dev, sizeof(*layout), GFP_KERNEL);
-	if (!layout)
-		return NULL;
-
-	sectors = cfg->page_size / (512 << cfg->sector_size_1k);
-	sas = cfg->spare_area_size << cfg->sector_size_1k;
-
-	/* Hamming */
-	if (is_hamming_ecc(cfg)) {
-		for (i = 0, idx1 = 0, idx2 = 0; i < sectors; i++) {
-			/* First sector of each page may have BBI */
-			if (i == 0) {
-				layout->oobfree[idx2].offset = i * sas + 1;
-				/* Small-page NAND use byte 6 for BBI */
-				if (cfg->page_size == 512)
-					layout->oobfree[idx2].offset--;
-				layout->oobfree[idx2].length = 5;
-			} else {
-				layout->oobfree[idx2].offset = i * sas;
-				layout->oobfree[idx2].length = 6;
-			}
-			idx2++;
-			layout->eccpos[idx1++] = i * sas + 6;
-			layout->eccpos[idx1++] = i * sas + 7;
-			layout->eccpos[idx1++] = i * sas + 8;
-			layout->oobfree[idx2].offset = i * sas + 9;
-			layout->oobfree[idx2].length = 7;
-			idx2++;
-			/* Leave zero-terminated entry for OOBFREE */
-			if (idx1 >= MTD_MAX_ECCPOS_ENTRIES_LARGE ||
-				    idx2 >= MTD_MAX_OOBFREE_ENTRIES_LARGE - 1)
-				break;
-		}
+	int sas = cfg->spare_area_size << cfg->sector_size_1k;
+	int sectors = cfg->page_size / (512 << cfg->sector_size_1k);
 
-		return layout;
-	}
+	if (section >= sectors)
+		return -ERANGE;
 
-	/*
-	 * CONTROLLER_VERSION:
-	 *   < v5.0: ECC_REQ = ceil(BCH_T * 13/8)
-	 *  >= v5.0: ECC_REQ = ceil(BCH_T * 14/8)
-	 * But we will just be conservative.
-	 */
-	req = DIV_ROUND_UP(ecc_level * 14, 8);
-	if (req >= sas) {
-		dev_err(&host->pdev->dev,
-			"error: ECC too large for OOB (ECC bytes %d, spare sector %d)\n",
-			req, sas);
-		return NULL;
-	}
+	oobregion->offset = (section * sas) + 6;
+	oobregion->length = 3;
+
+	return 0;
+}
+
+static int brcmnand_hamming_ooblayout_free(struct mtd_info *mtd, int section,
+					   struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct brcmnand_host *host = nand_get_controller_data(chip);
+	struct brcmnand_cfg *cfg = &host->hwcfg;
+	int sas = cfg->spare_area_size << cfg->sector_size_1k;
+	int sectors = cfg->page_size / (512 << cfg->sector_size_1k);
+
+	if (section >= sectors * 2)
+		return -ERANGE;
 
-	layout->eccbytes = req * sectors;
-	for (i = 0, idx1 = 0, idx2 = 0; i < sectors; i++) {
-		for (j = sas - req; j < sas && idx1 <
-				MTD_MAX_ECCPOS_ENTRIES_LARGE; j++, idx1++)
-			layout->eccpos[idx1] = i * sas + j;
+	oobregion->offset = (section / 2) * sas;
+
+	if (section & 1) {
+		oobregion->offset += 9;
+		oobregion->length = 7;
+	} else {
+		oobregion->length = 6;
 
 		/* First sector of each page may have BBI */
-		if (i == 0) {
-			if (cfg->page_size == 512 && (sas - req >= 6)) {
-				/* Small-page NAND use byte 6 for BBI */
-				layout->oobfree[idx2].offset = 0;
-				layout->oobfree[idx2].length = 5;
-				idx2++;
-				if (sas - req > 6) {
-					layout->oobfree[idx2].offset = 6;
-					layout->oobfree[idx2].length =
-						sas - req - 6;
-					idx2++;
-				}
-			} else if (sas > req + 1) {
-				layout->oobfree[idx2].offset = i * sas + 1;
-				layout->oobfree[idx2].length = sas - req - 1;
-				idx2++;
-			}
-		} else if (sas > req) {
-			layout->oobfree[idx2].offset = i * sas;
-			layout->oobfree[idx2].length = sas - req;
-			idx2++;
+		if (!section) {
+			/*
+			 * Small-page NAND use byte 6 for BBI while large-page
+			 * NAND use byte 0.
+			 */
+			if (cfg->page_size > 512)
+				oobregion->offset++;
+			oobregion->length--;
 		}
-		/* Leave zero-terminated entry for OOBFREE */
-		if (idx1 >= MTD_MAX_ECCPOS_ENTRIES_LARGE ||
-				idx2 >= MTD_MAX_OOBFREE_ENTRIES_LARGE - 1)
-			break;
 	}
 
-	return layout;
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops brcmnand_hamming_ooblayout_ops = {
+	.ecc = brcmnand_hamming_ooblayout_ecc,
+	.free = brcmnand_hamming_ooblayout_free,
+};
+
+static int brcmnand_bch_ooblayout_ecc(struct mtd_info *mtd, int section,
+				      struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct brcmnand_host *host = nand_get_controller_data(chip);
+	struct brcmnand_cfg *cfg = &host->hwcfg;
+	int sas = cfg->spare_area_size << cfg->sector_size_1k;
+	int sectors = cfg->page_size / (512 << cfg->sector_size_1k);
+
+	if (section >= sectors)
+		return -ERANGE;
+
+	oobregion->offset = (section * (sas + 1)) - chip->ecc.bytes;
+	oobregion->length = chip->ecc.bytes;
+
+	return 0;
 }
 
-static struct nand_ecclayout *brcmstb_choose_ecc_layout(
-		struct brcmnand_host *host)
+static int brcmnand_bch_ooblayout_free_lp(struct mtd_info *mtd, int section,
+					  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct brcmnand_host *host = nand_get_controller_data(chip);
+	struct brcmnand_cfg *cfg = &host->hwcfg;
+	int sas = cfg->spare_area_size << cfg->sector_size_1k;
+	int sectors = cfg->page_size / (512 << cfg->sector_size_1k);
+
+	if (section >= sectors)
+		return -ERANGE;
+
+	if (sas <= chip->ecc.bytes)
+		return 0;
+
+	oobregion->offset = section * sas;
+	oobregion->length = sas - chip->ecc.bytes;
+
+	if (!section) {
+		oobregion->offset++;
+		oobregion->length--;
+	}
+
+	return 0;
+}
+
+static int brcmnand_bch_ooblayout_free_sp(struct mtd_info *mtd, int section,
+					  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct brcmnand_host *host = nand_get_controller_data(chip);
+	struct brcmnand_cfg *cfg = &host->hwcfg;
+	int sas = cfg->spare_area_size << cfg->sector_size_1k;
+
+	if (section > 1 || sas - chip->ecc.bytes < 6 ||
+	    (section && sas - chip->ecc.bytes == 6))
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 0;
+		oobregion->length = 5;
+	} else {
+		oobregion->offset = 6;
+		oobregion->length = sas - chip->ecc.bytes - 6;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops brcmnand_bch_lp_ooblayout_ops = {
+	.ecc = brcmnand_bch_ooblayout_ecc,
+	.free = brcmnand_bch_ooblayout_free_lp,
+};
+
+static const struct mtd_ooblayout_ops brcmnand_bch_sp_ooblayout_ops = {
+	.ecc = brcmnand_bch_ooblayout_ecc,
+	.free = brcmnand_bch_ooblayout_free_sp,
+};
+
+static int brcmstb_choose_ecc_layout(struct brcmnand_host *host)
 {
-	struct nand_ecclayout *layout;
 	struct brcmnand_cfg *p = &host->hwcfg;
+	struct mtd_info *mtd = nand_to_mtd(&host->chip);
+	struct nand_ecc_ctrl *ecc = &host->chip.ecc;
 	unsigned int ecc_level = p->ecc_level;
+	int sas = p->spare_area_size << p->sector_size_1k;
+	int sectors = p->page_size / (512 << p->sector_size_1k);
 
 	if (p->sector_size_1k)
 		ecc_level <<= 1;
 
-	layout = brcmnand_create_layout(ecc_level, host);
-	if (!layout) {
+	if (is_hamming_ecc(p)) {
+		ecc->bytes = 3 * sectors;
+		mtd_set_ooblayout(mtd, &brcmnand_hamming_ooblayout_ops);
+		return 0;
+	}
+
+	/*
+	 * CONTROLLER_VERSION:
+	 *   < v5.0: ECC_REQ = ceil(BCH_T * 13/8)
+	 *  >= v5.0: ECC_REQ = ceil(BCH_T * 14/8)
+	 * But we will just be conservative.
+	 */
+	ecc->bytes = DIV_ROUND_UP(ecc_level * 14, 8);
+	if (p->page_size == 512)
+		mtd_set_ooblayout(mtd, &brcmnand_bch_sp_ooblayout_ops);
+	else
+		mtd_set_ooblayout(mtd, &brcmnand_bch_lp_ooblayout_ops);
+
+	if (ecc->bytes >= sas) {
 		dev_err(&host->pdev->dev,
-				"no proper ecc_layout for this NAND cfg\n");
-		return NULL;
+			"error: ECC too large for OOB (ECC bytes %d, spare sector %d)\n",
+			ecc->bytes, sas);
+		return -EINVAL;
 	}
 
-	return layout;
+	return 0;
 }
 
 static void brcmnand_wp(struct mtd_info *mtd, int wp)
@@ -2011,9 +2067,9 @@ static int brcmnand_init_cs(struct brcmnand_host *host, struct device_node *dn)
 	/* only use our internal HW threshold */
 	mtd->bitflip_threshold = 1;
 
-	chip->ecc.layout = brcmstb_choose_ecc_layout(host);
-	if (!chip->ecc.layout)
-		return -ENXIO;
+	ret = brcmstb_choose_ecc_layout(host);
+	if (ret)
+		return ret;
 
 	if (nand_scan_tail(mtd))
 		return -ENXIO;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:36 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:36 +0100
Subject: [PATCH v3 28/52] mtd: nand: cafe: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-29-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/cafe_nand.c | 45 ++++++++++++++++++++++++++++++++------------
 1 file changed, 33 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/nand/cafe_nand.c b/drivers/mtd/nand/cafe_nand.c
index aa1a616..0935b7c 100644
--- a/drivers/mtd/nand/cafe_nand.c
+++ b/drivers/mtd/nand/cafe_nand.c
@@ -459,10 +459,38 @@ static int cafe_nand_read_page(struct mtd_info *mtd, struct nand_chip *chip,
 	return max_bitflips;
 }
 
-static struct nand_ecclayout cafe_oobinfo_2048 = {
-	.eccbytes = 14,
-	.eccpos = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13},
-	.oobfree = {{14, 50}}
+static int cafe_ooblayout_ecc(struct mtd_info *mtd, int section,
+			      struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 0;
+	oobregion->length = chip->ecc.steps * chip->ecc.bytes;
+
+	return 0;
+}
+
+static int cafe_ooblayout_free(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int eccbytes = chip->ecc.steps * chip->ecc.bytes;
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = eccbytes;
+	oobregion->length = mtd->oobsize - eccbytes;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops cafe_ooblayout_ops = {
+	.ecc = cafe_ooblayout_ecc,
+	.free = cafe_ooblayout_free,
 };
 
 /* Ick. The BBT code really ought to be able to work this bit out
@@ -494,12 +522,6 @@ static struct nand_bbt_descr cafe_bbt_mirror_descr_2048 = {
 	.pattern = cafe_mirror_pattern_2048
 };
 
-static struct nand_ecclayout cafe_oobinfo_512 = {
-	.eccbytes = 14,
-	.eccpos = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13},
-	.oobfree = {{14, 2}}
-};
-
 static struct nand_bbt_descr cafe_bbt_main_descr_512 = {
 	.options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE
 		| NAND_BBT_2BIT | NAND_BBT_VERSION,
@@ -743,12 +765,11 @@ static int cafe_nand_probe(struct pci_dev *pdev,
 		cafe->ctl2 |= 1<<29; /* 2KiB page size */
 
 	/* Set up ECC according to the type of chip we found */
+	mtd_set_ooblayout(mtd, &cafe_ooblayout_ops);
 	if (mtd->writesize == 2048) {
-		cafe->nand.ecc.layout = &cafe_oobinfo_2048;
 		cafe->nand.bbt_td = &cafe_bbt_main_descr_2048;
 		cafe->nand.bbt_md = &cafe_bbt_mirror_descr_2048;
 	} else if (mtd->writesize == 512) {
-		cafe->nand.ecc.layout = &cafe_oobinfo_512;
 		cafe->nand.bbt_td = &cafe_bbt_main_descr_512;
 		cafe->nand.bbt_md = &cafe_bbt_mirror_descr_512;
 	} else {
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:37 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:37 +0100
Subject: [PATCH v3 29/52] mtd: nand: davinci: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-30-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/davinci_nand.c | 118 +++++++++++++++-------------------------
 1 file changed, 44 insertions(+), 74 deletions(-)

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 8cb821b..fe3fd29 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -54,7 +54,6 @@
  */
 struct davinci_nand_info {
 	struct nand_chip	chip;
-	struct nand_ecclayout	ecclayout;
 
 	struct device		*dev;
 	struct clk		*clk;
@@ -480,63 +479,46 @@ static int nand_davinci_dev_ready(struct mtd_info *mtd)
  * ten ECC bytes plus the manufacturer's bad block marker byte, and
  * and not overlapping the default BBT markers.
  */
-static struct nand_ecclayout hwecc4_small = {
-	.eccbytes = 10,
-	.eccpos = { 0, 1, 2, 3, 4,
-		/* offset 5 holds the badblock marker */
-		6, 7,
-		13, 14, 15, },
-	.oobfree = {
-		{.offset = 8, .length = 5, },
-		{.offset = 16, },
-	},
-};
+static int hwecc4_ooblayout_small_ecc(struct mtd_info *mtd, int section,
+				      struct mtd_oob_region *oobregion)
+{
+	if (section > 2)
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 0;
+		oobregion->length = 5;
+	} else if (section == 1) {
+		oobregion->offset = 6;
+		oobregion->length = 2;
+	} else {
+		oobregion->offset = 13;
+		oobregion->length = 3;
+	}
 
-/* An ECC layout for using 4-bit ECC with large-page (2048bytes) flash,
- * storing ten ECC bytes plus the manufacturer's bad block marker byte,
- * and not overlapping the default BBT markers.
- */
-static struct nand_ecclayout hwecc4_2048 = {
-	.eccbytes = 40,
-	.eccpos = {
-		/* at the end of spare sector */
-		24, 25, 26, 27, 28, 29,	30, 31, 32, 33,
-		34, 35, 36, 37, 38, 39,	40, 41, 42, 43,
-		44, 45, 46, 47, 48, 49, 50, 51, 52, 53,
-		54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
-		},
-	.oobfree = {
-		/* 2 bytes at offset 0 hold manufacturer badblock markers */
-		{.offset = 2, .length = 22, },
-		/* 5 bytes at offset 8 hold BBT markers */
-		/* 8 bytes at offset 16 hold JFFS2 clean markers */
-	},
-};
+	return 0;
+}
 
-/*
- * An ECC layout for using 4-bit ECC with large-page (4096bytes) flash,
- * storing ten ECC bytes plus the manufacturer's bad block marker byte,
- * and not overlapping the default BBT markers.
- */
-static struct nand_ecclayout hwecc4_4096 = {
-	.eccbytes = 80,
-	.eccpos = {
-		/* at the end of spare sector */
-		48, 49, 50, 51, 52, 53, 54, 55, 56, 57,
-		58, 59, 60, 61, 62, 63, 64, 65, 66, 67,
-		68, 69, 70, 71, 72, 73, 74, 75, 76, 77,
-		78, 79, 80, 81, 82, 83, 84, 85, 86, 87,
-		88, 89, 90, 91, 92, 93, 94, 95, 96, 97,
-		98, 99, 100, 101, 102, 103, 104, 105, 106, 107,
-		108, 109, 110, 111, 112, 113, 114, 115, 116, 117,
-		118, 119, 120, 121, 122, 123, 124, 125, 126, 127,
-	},
-	.oobfree = {
-		/* 2 bytes at offset 0 hold manufacturer badblock markers */
-		{.offset = 2, .length = 46, },
-		/* 5 bytes at offset 8 hold BBT markers */
-		/* 8 bytes at offset 16 hold JFFS2 clean markers */
-	},
+static int hwecc4_ooblayout_small_free(struct mtd_info *mtd, int section,
+				       struct mtd_oob_region *oobregion)
+{
+	if (section > 1)
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 8;
+		oobregion->length = 5;
+	} else {
+		oobregion->offset = 16;
+		oobregion->length = mtd->oobsize - 16;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops hwecc4_small_ooblayout_ops = {
+	.ecc = hwecc4_ooblayout_small_ecc,
+	.free = hwecc4_ooblayout_small_free,
 };
 
 #if defined(CONFIG_OF)
@@ -805,26 +787,14 @@ static int nand_davinci_probe(struct platform_device *pdev)
 		 * table marker fits in the free bytes.
 		 */
 		if (chunks == 1) {
-			info->ecclayout = hwecc4_small;
-			info->ecclayout.oobfree[1].length = mtd->oobsize - 16;
-			goto syndrome_done;
-		}
-		if (chunks == 4) {
-			info->ecclayout = hwecc4_2048;
+			mtd_set_ooblayout(mtd, &hwecc4_small_ooblayout_ops);
+		} else if (chunks == 4 || chunks == 8) {
+			mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
 			info->chip.ecc.mode = NAND_ECC_HW_OOB_FIRST;
-			goto syndrome_done;
-		}
-		if (chunks == 8) {
-			info->ecclayout = hwecc4_4096;
-			info->chip.ecc.mode = NAND_ECC_HW_OOB_FIRST;
-			goto syndrome_done;
+		} else {
+			ret = -EIO;
+			goto err;
 		}
-
-		ret = -EIO;
-		goto err;
-
-syndrome_done:
-		info->chip.ecc.layout = &info->ecclayout;
 	}
 
 	ret = nand_scan_tail(mtd);
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:38 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:38 +0100
Subject: [PATCH v3 30/52] mtd: nand: denali: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-31-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/denali.c | 51 +++++++++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 15 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 30bf5f6..b832375 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1374,13 +1374,42 @@ static void denali_hw_init(struct denali_nand_info *denali)
  * correction
  */
 #define ECC_8BITS	14
-static struct nand_ecclayout nand_8bit_oob = {
-	.eccbytes = 14,
-};
-
 #define ECC_15BITS	26
-static struct nand_ecclayout nand_15bit_oob = {
-	.eccbytes = 26,
+
+static int denali_ooblayout_ecc(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	struct denali_nand_info *denali = mtd_to_denali(mtd);
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = denali->bbtskipbytes;
+	oobregion->length = chip->ecc.bytes * chip->ecc.steps;
+
+	return 0;
+}
+
+static int denali_ooblayout_free(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct denali_nand_info *denali = mtd_to_denali(mtd);
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int eccbytes = chip->ecc.bytes * chip->ecc.steps;
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = eccbytes + denali->bbtskipbytes;
+	oobregion->length = mtd->oobsize - oobregion->offset;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops denali_ooblayout_ops = {
+	.ecc = denali_ooblayout_ecc,
+	.free = denali_ooblayout_free,
 };
 
 static uint8_t bbt_pattern[] = {'B', 'b', 't', '0' };
@@ -1561,7 +1590,6 @@ int denali_init(struct denali_nand_info *denali)
 			ECC_SECTOR_SIZE)))) {
 		/* if MLC OOB size is large enough, use 15bit ECC*/
 		denali->nand.ecc.strength = 15;
-		denali->nand.ecc.layout = &nand_15bit_oob;
 		denali->nand.ecc.bytes = ECC_15BITS;
 		iowrite32(15, denali->flash_reg + ECC_CORRECTION);
 	} else if (mtd->oobsize < (denali->bbtskipbytes +
@@ -1571,20 +1599,13 @@ int denali_init(struct denali_nand_info *denali)
 		goto failed_req_irq;
 	} else {
 		denali->nand.ecc.strength = 8;
-		denali->nand.ecc.layout = &nand_8bit_oob;
 		denali->nand.ecc.bytes = ECC_8BITS;
 		iowrite32(8, denali->flash_reg + ECC_CORRECTION);
 	}
 
+	mtd_set_ooblayout(mtd, &denali_ooblayout_ops);
 	denali->nand.ecc.bytes *= denali->devnum;
 	denali->nand.ecc.strength *= denali->devnum;
-	denali->nand.ecc.layout->eccbytes *=
-		mtd->writesize / ECC_SECTOR_SIZE;
-	denali->nand.ecc.layout->oobfree[0].offset =
-		denali->bbtskipbytes + denali->nand.ecc.layout->eccbytes;
-	denali->nand.ecc.layout->oobfree[0].length =
-		mtd->oobsize - denali->nand.ecc.layout->eccbytes -
-		denali->bbtskipbytes;
 
 	/*
 	 * Let driver know the total blocks number and how many blocks
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:39 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:39 +0100
Subject: [PATCH v3 31/52] mtd: nand: diskonchip: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-32-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/diskonchip.c | 60 ++++++++++++++++++++++++++++++++-----------
 1 file changed, 45 insertions(+), 15 deletions(-)

diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c
index f170f3c..4411e99 100644
--- a/drivers/mtd/nand/diskonchip.c
+++ b/drivers/mtd/nand/diskonchip.c
@@ -950,20 +950,50 @@ static int doc200x_correct_data(struct mtd_info *mtd, u_char *dat,
 
 //u_char mydatabuf[528];
 
-/* The strange out-of-order .oobfree list below is a (possibly unneeded)
- * attempt to retain compatibility.  It used to read:
- * 	.oobfree = { {8, 8} }
- * Since that leaves two bytes unusable, it was changed.  But the following
- * scheme might affect existing jffs2 installs by moving the cleanmarker:
- * 	.oobfree = { {6, 10} }
- * jffs2 seems to handle the above gracefully, but the current scheme seems
- * safer.  The only problem with it is that any code that parses oobfree must
- * be able to handle out-of-order segments.
- */
-static struct nand_ecclayout doc200x_oobinfo = {
-	.eccbytes = 6,
-	.eccpos = {0, 1, 2, 3, 4, 5},
-	.oobfree = {{8, 8}, {6, 2}}
+static int doc200x_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 0;
+	oobregion->length = 6;
+
+	return 0;
+}
+
+static int doc200x_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	if (section > 1)
+		return -ERANGE;
+
+	/*
+	 * The strange out-of-order free bytes definition is a (possibly
+	 * unneeded) attempt to retain compatibility.  It used to read:
+	 *	.oobfree = { {8, 8} }
+	 * Since that leaves two bytes unusable, it was changed.  But the
+	 * following scheme might affect existing jffs2 installs by moving the
+	 * cleanmarker:
+	 *	.oobfree = { {6, 10} }
+	 * jffs2 seems to handle the above gracefully, but the current scheme
+	 * seems safer. The only problem with it is that any code retrieving
+	 * free bytes position must be able to handle out-of-order segments.
+	 */
+	if (!section) {
+		oobregion->offset = 8;
+		oobregion->length = 8;
+	} else {
+		oobregion->offset = 6;
+		oobregion->length = 2;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops doc200x_ooblayout_ops = {
+	.ecc = doc200x_ooblayout_ecc,
+	.free = doc200x_ooblayout_free,
 };
 
 /* Find the (I)NFTL Media Header, and optionally also the mirror media header.
@@ -1537,6 +1567,7 @@ static int __init doc_probe(unsigned long physadr)
 	nand->bbt_md		= nand->bbt_td + 1;
 
 	mtd->owner		= THIS_MODULE;
+	mtd_set_ooblayout(mtd, &doc200x_ooblayout_ops);
 
 	nand_set_controller_data(nand, doc);
 	nand->select_chip	= doc200x_select_chip;
@@ -1548,7 +1579,6 @@ static int __init doc_probe(unsigned long physadr)
 	nand->ecc.calculate	= doc200x_calculate_ecc;
 	nand->ecc.correct	= doc200x_correct_data;
 
-	nand->ecc.layout	= &doc200x_oobinfo;
 	nand->ecc.mode		= NAND_ECC_HW_SYNDROME;
 	nand->ecc.size		= 512;
 	nand->ecc.bytes		= 6;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:40 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:40 +0100
Subject: [PATCH v3 32/52] mtd: nand: docg4: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-33-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/docg4.c | 33 ++++++++++++++++++++++++++++-----
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c
index fb46fd7..f5ca9a5 100644
--- a/drivers/mtd/nand/docg4.c
+++ b/drivers/mtd/nand/docg4.c
@@ -222,10 +222,33 @@ struct docg4_priv {
  * Bytes 8 - 14 are hw-generated ecc covering entire page + oob bytes 0 - 14.
  * Byte 15 (the last) is used by the driver as a "page written" flag.
  */
-static struct nand_ecclayout docg4_oobinfo = {
-	.eccbytes = 9,
-	.eccpos = {7, 8, 9, 10, 11, 12, 13, 14, 15},
-	.oobfree = { {.offset = 2, .length = 5} }
+static int docg4_ooblayout_ecc(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 7;
+	oobregion->length = 9;
+
+	return 0;
+}
+
+static int docg4_ooblayout_free(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 2;
+	oobregion->length = 5;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops docg4_ooblayout_ops = {
+	.ecc = docg4_ooblayout_ecc,
+	.free = docg4_ooblayout_free,
 };
 
 /*
@@ -1209,6 +1232,7 @@ static void __init init_mtd_structs(struct mtd_info *mtd)
 	mtd->writesize = DOCG4_PAGE_SIZE;
 	mtd->erasesize = DOCG4_BLOCK_SIZE;
 	mtd->oobsize = DOCG4_OOB_SIZE;
+	mtd_set_ooblayout(mtd, &docg4_ooblayout_ops);
 	nand->chipsize = DOCG4_CHIP_SIZE;
 	nand->chip_shift = DOCG4_CHIP_SHIFT;
 	nand->bbt_erase_shift = nand->phys_erase_shift = DOCG4_ERASE_SHIFT;
@@ -1217,7 +1241,6 @@ static void __init init_mtd_structs(struct mtd_info *mtd)
 	nand->pagemask = 0x3ffff;
 	nand->badblockpos = NAND_LARGE_BADBLOCK_POS;
 	nand->badblockbits = 8;
-	nand->ecc.layout = &docg4_oobinfo;
 	nand->ecc.mode = NAND_ECC_HW_SYNDROME;
 	nand->ecc.size = DOCG4_PAGE_SIZE;
 	nand->ecc.prepad = 8;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:41 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:41 +0100
Subject: [PATCH v3 33/52] mtd: nand: fsl_elbc: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-34-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/fsl_elbc_nand.c | 83 +++++++++++++++++++++++-----------------
 1 file changed, 47 insertions(+), 36 deletions(-)

diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 059d5f7..487eae0 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -79,32 +79,53 @@ struct fsl_elbc_fcm_ctrl {
 
 /* These map to the positions used by the FCM hardware ECC generator */
 
-/* Small Page FLASH with FMR[ECCM] = 0 */
-static struct nand_ecclayout fsl_elbc_oob_sp_eccm0 = {
-	.eccbytes = 3,
-	.eccpos = {6, 7, 8},
-	.oobfree = { {0, 5}, {9, 7} },
-};
+static int fsl_elbc_ooblayout_ecc(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct fsl_elbc_mtd *priv = nand_get_controller_data(chip);
 
-/* Small Page FLASH with FMR[ECCM] = 1 */
-static struct nand_ecclayout fsl_elbc_oob_sp_eccm1 = {
-	.eccbytes = 3,
-	.eccpos = {8, 9, 10},
-	.oobfree = { {0, 5}, {6, 2}, {11, 5} },
-};
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
 
-/* Large Page FLASH with FMR[ECCM] = 0 */
-static struct nand_ecclayout fsl_elbc_oob_lp_eccm0 = {
-	.eccbytes = 12,
-	.eccpos = {6, 7, 8, 22, 23, 24, 38, 39, 40, 54, 55, 56},
-	.oobfree = { {1, 5}, {9, 13}, {25, 13}, {41, 13}, {57, 7} },
-};
+	oobregion->offset = (16 * section) + 6;
+	if (priv->fmr & FMR_ECCM)
+		oobregion->offset += 2;
 
-/* Large Page FLASH with FMR[ECCM] = 1 */
-static struct nand_ecclayout fsl_elbc_oob_lp_eccm1 = {
-	.eccbytes = 12,
-	.eccpos = {8, 9, 10, 24, 25, 26, 40, 41, 42, 56, 57, 58},
-	.oobfree = { {1, 7}, {11, 13}, {27, 13}, {43, 13}, {59, 5} },
+	oobregion->length = chip->ecc.bytes;
+
+	return 0;
+}
+
+static int fsl_elbc_ooblayout_free(struct mtd_info *mtd, int section,
+				   struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct fsl_elbc_mtd *priv = nand_get_controller_data(chip);
+
+	if (section > chip->ecc.steps)
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 0;
+		if (mtd->writesize > 512)
+			oobregion->offset++;
+		oobregion->length = (priv->fmr & FMR_ECCM) ? 7 : 5;
+	} else {
+		oobregion->offset = (16 * section) -
+				    ((priv->fmr & FMR_ECCM) ? 5 : 7);
+		if (section < chip->ecc.steps)
+			oobregion->length = 13;
+		else
+			oobregion->length = mtd->oobsize - oobregion->offset;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops fsl_elbc_ooblayout_ops = {
+	.ecc = fsl_elbc_ooblayout_ecc,
+	.free = fsl_elbc_ooblayout_free,
 };
 
 /*
@@ -657,8 +678,8 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
 	        chip->ecc.bytes);
 	dev_dbg(priv->dev, "fsl_elbc_init: nand->ecc.total = %d\n",
 	        chip->ecc.total);
-	dev_dbg(priv->dev, "fsl_elbc_init: nand->ecc.layout = %p\n",
-	        chip->ecc.layout);
+	dev_dbg(priv->dev, "fsl_elbc_init: mtd->ooblayout = %p\n",
+		mtd->ooblayout);
 	dev_dbg(priv->dev, "fsl_elbc_init: mtd->flags = %08x\n", mtd->flags);
 	dev_dbg(priv->dev, "fsl_elbc_init: mtd->size = %lld\n", mtd->size);
 	dev_dbg(priv->dev, "fsl_elbc_init: mtd->erasesize = %d\n",
@@ -675,14 +696,6 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
 	} else if (mtd->writesize == 2048) {
 		priv->page_size = 1;
 		setbits32(&lbc->bank[priv->bank].or, OR_FCM_PGS);
-		/* adjust ecc setup if needed */
-		if ((in_be32(&lbc->bank[priv->bank].br) & BR_DECC) ==
-		    BR_DECC_CHK_GEN) {
-			chip->ecc.size = 512;
-			chip->ecc.layout = (priv->fmr & FMR_ECCM) ?
-			                   &fsl_elbc_oob_lp_eccm1 :
-			                   &fsl_elbc_oob_lp_eccm0;
-		}
 	} else {
 		dev_err(priv->dev,
 		        "fsl_elbc_init: page size %d is not supported\n",
@@ -780,9 +793,7 @@ static int fsl_elbc_chip_init(struct fsl_elbc_mtd *priv)
 	if ((in_be32(&lbc->bank[priv->bank].br) & BR_DECC) ==
 	    BR_DECC_CHK_GEN) {
 		chip->ecc.mode = NAND_ECC_HW;
-		/* put in small page settings and adjust later if needed */
-		chip->ecc.layout = (priv->fmr & FMR_ECCM) ?
-				&fsl_elbc_oob_sp_eccm1 : &fsl_elbc_oob_sp_eccm0;
+		mtd_set_ooblayout(mtd, &fsl_elbc_ooblayout_ops);
 		chip->ecc.size = 512;
 		chip->ecc.bytes = 3;
 		chip->ecc.strength = 1;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:43 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:43 +0100
Subject: [PATCH v3 35/52] mtd: nand: fsmc: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-36-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/fsmc_nand.c | 298 ++++++++++++-------------------------------
 1 file changed, 82 insertions(+), 216 deletions(-)

diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
index 1bdcd4f..275a98c 100644
--- a/drivers/mtd/nand/fsmc_nand.c
+++ b/drivers/mtd/nand/fsmc_nand.c
@@ -39,212 +39,6 @@
 #include <linux/amba/bus.h>
 #include <mtd/mtd-abi.h>
 
-static struct nand_ecclayout fsmc_ecc1_128_layout = {
-	.eccbytes = 24,
-	.eccpos = {2, 3, 4, 18, 19, 20, 34, 35, 36, 50, 51, 52,
-		66, 67, 68, 82, 83, 84, 98, 99, 100, 114, 115, 116},
-	.oobfree = {
-		{.offset = 8, .length = 8},
-		{.offset = 24, .length = 8},
-		{.offset = 40, .length = 8},
-		{.offset = 56, .length = 8},
-		{.offset = 72, .length = 8},
-		{.offset = 88, .length = 8},
-		{.offset = 104, .length = 8},
-		{.offset = 120, .length = 8}
-	}
-};
-
-static struct nand_ecclayout fsmc_ecc1_64_layout = {
-	.eccbytes = 12,
-	.eccpos = {2, 3, 4, 18, 19, 20, 34, 35, 36, 50, 51, 52},
-	.oobfree = {
-		{.offset = 8, .length = 8},
-		{.offset = 24, .length = 8},
-		{.offset = 40, .length = 8},
-		{.offset = 56, .length = 8},
-	}
-};
-
-static struct nand_ecclayout fsmc_ecc1_16_layout = {
-	.eccbytes = 3,
-	.eccpos = {2, 3, 4},
-	.oobfree = {
-		{.offset = 8, .length = 8},
-	}
-};
-
-/*
- * ECC4 layout for NAND of pagesize 8192 bytes & OOBsize 256 bytes. 13*16 bytes
- * of OB size is reserved for ECC, Byte no. 0 & 1 reserved for bad block and 46
- * bytes are free for use.
- */
-static struct nand_ecclayout fsmc_ecc4_256_layout = {
-	.eccbytes = 208,
-	.eccpos = {  2,   3,   4,   5,   6,   7,   8,
-		9,  10,  11,  12,  13,  14,
-		18,  19,  20,  21,  22,  23,  24,
-		25,  26,  27,  28,  29,  30,
-		34,  35,  36,  37,  38,  39,  40,
-		41,  42,  43,  44,  45,  46,
-		50,  51,  52,  53,  54,  55,  56,
-		57,  58,  59,  60,  61,  62,
-		66,  67,  68,  69,  70,  71,  72,
-		73,  74,  75,  76,  77,  78,
-		82,  83,  84,  85,  86,  87,  88,
-		89,  90,  91,  92,  93,  94,
-		98,  99, 100, 101, 102, 103, 104,
-		105, 106, 107, 108, 109, 110,
-		114, 115, 116, 117, 118, 119, 120,
-		121, 122, 123, 124, 125, 126,
-		130, 131, 132, 133, 134, 135, 136,
-		137, 138, 139, 140, 141, 142,
-		146, 147, 148, 149, 150, 151, 152,
-		153, 154, 155, 156, 157, 158,
-		162, 163, 164, 165, 166, 167, 168,
-		169, 170, 171, 172, 173, 174,
-		178, 179, 180, 181, 182, 183, 184,
-		185, 186, 187, 188, 189, 190,
-		194, 195, 196, 197, 198, 199, 200,
-		201, 202, 203, 204, 205, 206,
-		210, 211, 212, 213, 214, 215, 216,
-		217, 218, 219, 220, 221, 222,
-		226, 227, 228, 229, 230, 231, 232,
-		233, 234, 235, 236, 237, 238,
-		242, 243, 244, 245, 246, 247, 248,
-		249, 250, 251, 252, 253, 254
-	},
-	.oobfree = {
-		{.offset = 15, .length = 3},
-		{.offset = 31, .length = 3},
-		{.offset = 47, .length = 3},
-		{.offset = 63, .length = 3},
-		{.offset = 79, .length = 3},
-		{.offset = 95, .length = 3},
-		{.offset = 111, .length = 3},
-		{.offset = 127, .length = 3},
-		{.offset = 143, .length = 3},
-		{.offset = 159, .length = 3},
-		{.offset = 175, .length = 3},
-		{.offset = 191, .length = 3},
-		{.offset = 207, .length = 3},
-		{.offset = 223, .length = 3},
-		{.offset = 239, .length = 3},
-		{.offset = 255, .length = 1}
-	}
-};
-
-/*
- * ECC4 layout for NAND of pagesize 4096 bytes & OOBsize 224 bytes. 13*8 bytes
- * of OOB size is reserved for ECC, Byte no. 0 & 1 reserved for bad block & 118
- * bytes are free for use.
- */
-static struct nand_ecclayout fsmc_ecc4_224_layout = {
-	.eccbytes = 104,
-	.eccpos = {  2,   3,   4,   5,   6,   7,   8,
-		9,  10,  11,  12,  13,  14,
-		18,  19,  20,  21,  22,  23,  24,
-		25,  26,  27,  28,  29,  30,
-		34,  35,  36,  37,  38,  39,  40,
-		41,  42,  43,  44,  45,  46,
-		50,  51,  52,  53,  54,  55,  56,
-		57,  58,  59,  60,  61,  62,
-		66,  67,  68,  69,  70,  71,  72,
-		73,  74,  75,  76,  77,  78,
-		82,  83,  84,  85,  86,  87,  88,
-		89,  90,  91,  92,  93,  94,
-		98,  99, 100, 101, 102, 103, 104,
-		105, 106, 107, 108, 109, 110,
-		114, 115, 116, 117, 118, 119, 120,
-		121, 122, 123, 124, 125, 126
-	},
-	.oobfree = {
-		{.offset = 15, .length = 3},
-		{.offset = 31, .length = 3},
-		{.offset = 47, .length = 3},
-		{.offset = 63, .length = 3},
-		{.offset = 79, .length = 3},
-		{.offset = 95, .length = 3},
-		{.offset = 111, .length = 3},
-		{.offset = 127, .length = 97}
-	}
-};
-
-/*
- * ECC4 layout for NAND of pagesize 4096 bytes & OOBsize 128 bytes. 13*8 bytes
- * of OOB size is reserved for ECC, Byte no. 0 & 1 reserved for bad block & 22
- * bytes are free for use.
- */
-static struct nand_ecclayout fsmc_ecc4_128_layout = {
-	.eccbytes = 104,
-	.eccpos = {  2,   3,   4,   5,   6,   7,   8,
-		9,  10,  11,  12,  13,  14,
-		18,  19,  20,  21,  22,  23,  24,
-		25,  26,  27,  28,  29,  30,
-		34,  35,  36,  37,  38,  39,  40,
-		41,  42,  43,  44,  45,  46,
-		50,  51,  52,  53,  54,  55,  56,
-		57,  58,  59,  60,  61,  62,
-		66,  67,  68,  69,  70,  71,  72,
-		73,  74,  75,  76,  77,  78,
-		82,  83,  84,  85,  86,  87,  88,
-		89,  90,  91,  92,  93,  94,
-		98,  99, 100, 101, 102, 103, 104,
-		105, 106, 107, 108, 109, 110,
-		114, 115, 116, 117, 118, 119, 120,
-		121, 122, 123, 124, 125, 126
-	},
-	.oobfree = {
-		{.offset = 15, .length = 3},
-		{.offset = 31, .length = 3},
-		{.offset = 47, .length = 3},
-		{.offset = 63, .length = 3},
-		{.offset = 79, .length = 3},
-		{.offset = 95, .length = 3},
-		{.offset = 111, .length = 3},
-		{.offset = 127, .length = 1}
-	}
-};
-
-/*
- * ECC4 layout for NAND of pagesize 2048 bytes & OOBsize 64 bytes. 13*4 bytes of
- * OOB size is reserved for ECC, Byte no. 0 & 1 reserved for bad block and 10
- * bytes are free for use.
- */
-static struct nand_ecclayout fsmc_ecc4_64_layout = {
-	.eccbytes = 52,
-	.eccpos = {  2,   3,   4,   5,   6,   7,   8,
-		9,  10,  11,  12,  13,  14,
-		18,  19,  20,  21,  22,  23,  24,
-		25,  26,  27,  28,  29,  30,
-		34,  35,  36,  37,  38,  39,  40,
-		41,  42,  43,  44,  45,  46,
-		50,  51,  52,  53,  54,  55,  56,
-		57,  58,  59,  60,  61,  62,
-	},
-	.oobfree = {
-		{.offset = 15, .length = 3},
-		{.offset = 31, .length = 3},
-		{.offset = 47, .length = 3},
-		{.offset = 63, .length = 1},
-	}
-};
-
-/*
- * ECC4 layout for NAND of pagesize 512 bytes & OOBsize 16 bytes. 13 bytes of
- * OOB size is reserved for ECC, Byte no. 4 & 5 reserved for bad block and One
- * byte is free for use.
- */
-static struct nand_ecclayout fsmc_ecc4_16_layout = {
-	.eccbytes = 13,
-	.eccpos = { 0,  1,  2,  3,  6,  7, 8,
-		9, 10, 11, 12, 13, 14
-	},
-	.oobfree = {
-		{.offset = 15, .length = 1},
-	}
-};
-
 /*
  * ECC placement definitions in oobfree type format.
  * There are 13 bytes of ecc for every 512 byte block and it has to be read
@@ -274,6 +68,84 @@ static struct fsmc_eccplace fsmc_ecc4_sp_place = {
 	}
 };
 
+static int fsmc_ecc1_ooblayout_ecc(struct mtd_info *mtd, int section,
+				   struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 2;
+	oobregion->length = 3;
+
+	return 0;
+}
+
+static int fsmc_ecc1_ooblayout_free(struct mtd_info *mtd, int section,
+				    struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 8;
+
+	if (section < chip->ecc.steps - 1)
+		oobregion->length = 8;
+	else
+		oobregion->length = mtd->oobsize - oobregion->offset;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops fsmc_ecc1_ooblayout_ops = {
+	.ecc = fsmc_ecc1_ooblayout_ecc,
+	.free = fsmc_ecc1_ooblayout_free,
+};
+
+static int fsmc_ecc4_ooblayout_ecc(struct mtd_info *mtd, int section,
+				   struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->length = chip->ecc.bytes;
+
+	if (!section && mtd->writesize <= 512)
+		oobregion->offset = 0;
+	else
+		oobregion->offset = (section * 16) + 2;
+
+	return 0;
+}
+
+static int fsmc_ecc4_ooblayout_free(struct mtd_info *mtd, int section,
+				    struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 15;
+
+	if (section < chip->ecc.steps - 1)
+		oobregion->length = 3;
+	else
+		oobregion->length = mtd->oobsize - oobregion->offset;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops fsmc_ecc4_ooblayout_ops = {
+	.ecc = fsmc_ecc4_ooblayout_ecc,
+	.free = fsmc_ecc4_ooblayout_free,
+};
+
 /**
  * struct fsmc_nand_data - structure for FSMC NAND device state
  *
@@ -1084,23 +956,18 @@ static int __init fsmc_nand_probe(struct platform_device *pdev)
 	if (AMBA_REV_BITS(host->pid) >= 8) {
 		switch (mtd->oobsize) {
 		case 16:
-			nand->ecc.layout = &fsmc_ecc4_16_layout;
 			host->ecc_place = &fsmc_ecc4_sp_place;
 			break;
 		case 64:
-			nand->ecc.layout = &fsmc_ecc4_64_layout;
 			host->ecc_place = &fsmc_ecc4_lp_place;
 			break;
 		case 128:
-			nand->ecc.layout = &fsmc_ecc4_128_layout;
 			host->ecc_place = &fsmc_ecc4_lp_place;
 			break;
 		case 224:
-			nand->ecc.layout = &fsmc_ecc4_224_layout;
 			host->ecc_place = &fsmc_ecc4_lp_place;
 			break;
 		case 256:
-			nand->ecc.layout = &fsmc_ecc4_256_layout;
 			host->ecc_place = &fsmc_ecc4_lp_place;
 			break;
 		default:
@@ -1109,6 +976,8 @@ static int __init fsmc_nand_probe(struct platform_device *pdev)
 			ret = -EINVAL;
 			goto err_probe;
 		}
+
+		mtd_set_ooblayout(mtd, &fsmc_ecc4_ooblayout_ops);
 	} else {
 		switch (nand->ecc.mode) {
 		case NAND_ECC_HW:
@@ -1135,13 +1004,10 @@ static int __init fsmc_nand_probe(struct platform_device *pdev)
 		if (nand->ecc.mode != NAND_ECC_SOFT_BCH) {
 			switch (mtd->oobsize) {
 			case 16:
-				nand->ecc.layout = &fsmc_ecc1_16_layout;
-				break;
 			case 64:
-				nand->ecc.layout = &fsmc_ecc1_64_layout;
-				break;
 			case 128:
-				nand->ecc.layout = &fsmc_ecc1_128_layout;
+				mtd_set_ooblayout(mtd,
+						  &fsmc_ecc1_ooblayout_ops);
 				break;
 			default:
 				dev_warn(&pdev->dev,
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:42 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:42 +0100
Subject: [PATCH v3 34/52] mtd: nand: fsl_ifc: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-35-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/fsl_ifc_nand.c | 231 ++++++++++++----------------------------
 1 file changed, 67 insertions(+), 164 deletions(-)

diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 2e970ac..83331df 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -67,136 +67,6 @@ struct fsl_ifc_nand_ctrl {
 
 static struct fsl_ifc_nand_ctrl *ifc_nand_ctrl;
 
-/* 512-byte page with 4-bit ECC, 8-bit */
-static struct nand_ecclayout oob_512_8bit_ecc4 = {
-	.eccbytes = 8,
-	.eccpos = {8, 9, 10, 11, 12, 13, 14, 15},
-	.oobfree = { {0, 5}, {6, 2} },
-};
-
-/* 512-byte page with 4-bit ECC, 16-bit */
-static struct nand_ecclayout oob_512_16bit_ecc4 = {
-	.eccbytes = 8,
-	.eccpos = {8, 9, 10, 11, 12, 13, 14, 15},
-	.oobfree = { {2, 6}, },
-};
-
-/* 2048-byte page size with 4-bit ECC */
-static struct nand_ecclayout oob_2048_ecc4 = {
-	.eccbytes = 32,
-	.eccpos = {
-		8, 9, 10, 11, 12, 13, 14, 15,
-		16, 17, 18, 19, 20, 21, 22, 23,
-		24, 25, 26, 27, 28, 29, 30, 31,
-		32, 33, 34, 35, 36, 37, 38, 39,
-	},
-	.oobfree = { {2, 6}, {40, 24} },
-};
-
-/* 4096-byte page size with 4-bit ECC */
-static struct nand_ecclayout oob_4096_ecc4 = {
-	.eccbytes = 64,
-	.eccpos = {
-		8, 9, 10, 11, 12, 13, 14, 15,
-		16, 17, 18, 19, 20, 21, 22, 23,
-		24, 25, 26, 27, 28, 29, 30, 31,
-		32, 33, 34, 35, 36, 37, 38, 39,
-		40, 41, 42, 43, 44, 45, 46, 47,
-		48, 49, 50, 51, 52, 53, 54, 55,
-		56, 57, 58, 59, 60, 61, 62, 63,
-		64, 65, 66, 67, 68, 69, 70, 71,
-	},
-	.oobfree = { {2, 6}, {72, 56} },
-};
-
-/* 4096-byte page size with 8-bit ECC -- requires 218-byte OOB */
-static struct nand_ecclayout oob_4096_ecc8 = {
-	.eccbytes = 128,
-	.eccpos = {
-		8, 9, 10, 11, 12, 13, 14, 15,
-		16, 17, 18, 19, 20, 21, 22, 23,
-		24, 25, 26, 27, 28, 29, 30, 31,
-		32, 33, 34, 35, 36, 37, 38, 39,
-		40, 41, 42, 43, 44, 45, 46, 47,
-		48, 49, 50, 51, 52, 53, 54, 55,
-		56, 57, 58, 59, 60, 61, 62, 63,
-		64, 65, 66, 67, 68, 69, 70, 71,
-		72, 73, 74, 75, 76, 77, 78, 79,
-		80, 81, 82, 83, 84, 85, 86, 87,
-		88, 89, 90, 91, 92, 93, 94, 95,
-		96, 97, 98, 99, 100, 101, 102, 103,
-		104, 105, 106, 107, 108, 109, 110, 111,
-		112, 113, 114, 115, 116, 117, 118, 119,
-		120, 121, 122, 123, 124, 125, 126, 127,
-		128, 129, 130, 131, 132, 133, 134, 135,
-	},
-	.oobfree = { {2, 6}, {136, 82} },
-};
-
-/* 8192-byte page size with 4-bit ECC */
-static struct nand_ecclayout oob_8192_ecc4 = {
-	.eccbytes = 128,
-	.eccpos = {
-		8, 9, 10, 11, 12, 13, 14, 15,
-		16, 17, 18, 19, 20, 21, 22, 23,
-		24, 25, 26, 27, 28, 29, 30, 31,
-		32, 33, 34, 35, 36, 37, 38, 39,
-		40, 41, 42, 43, 44, 45, 46, 47,
-		48, 49, 50, 51, 52, 53, 54, 55,
-		56, 57, 58, 59, 60, 61, 62, 63,
-		64, 65, 66, 67, 68, 69, 70, 71,
-		72, 73, 74, 75, 76, 77, 78, 79,
-		80, 81, 82, 83, 84, 85, 86, 87,
-		88, 89, 90, 91, 92, 93, 94, 95,
-		96, 97, 98, 99, 100, 101, 102, 103,
-		104, 105, 106, 107, 108, 109, 110, 111,
-		112, 113, 114, 115, 116, 117, 118, 119,
-		120, 121, 122, 123, 124, 125, 126, 127,
-		128, 129, 130, 131, 132, 133, 134, 135,
-	},
-	.oobfree = { {2, 6}, {136, 208} },
-};
-
-/* 8192-byte page size with 8-bit ECC -- requires 218-byte OOB */
-static struct nand_ecclayout oob_8192_ecc8 = {
-	.eccbytes = 256,
-	.eccpos = {
-		8, 9, 10, 11, 12, 13, 14, 15,
-		16, 17, 18, 19, 20, 21, 22, 23,
-		24, 25, 26, 27, 28, 29, 30, 31,
-		32, 33, 34, 35, 36, 37, 38, 39,
-		40, 41, 42, 43, 44, 45, 46, 47,
-		48, 49, 50, 51, 52, 53, 54, 55,
-		56, 57, 58, 59, 60, 61, 62, 63,
-		64, 65, 66, 67, 68, 69, 70, 71,
-		72, 73, 74, 75, 76, 77, 78, 79,
-		80, 81, 82, 83, 84, 85, 86, 87,
-		88, 89, 90, 91, 92, 93, 94, 95,
-		96, 97, 98, 99, 100, 101, 102, 103,
-		104, 105, 106, 107, 108, 109, 110, 111,
-		112, 113, 114, 115, 116, 117, 118, 119,
-		120, 121, 122, 123, 124, 125, 126, 127,
-		128, 129, 130, 131, 132, 133, 134, 135,
-		136, 137, 138, 139, 140, 141, 142, 143,
-		144, 145, 146, 147, 148, 149, 150, 151,
-		152, 153, 154, 155, 156, 157, 158, 159,
-		160, 161, 162, 163, 164, 165, 166, 167,
-		168, 169, 170, 171, 172, 173, 174, 175,
-		176, 177, 178, 179, 180, 181, 182, 183,
-		184, 185, 186, 187, 188, 189, 190, 191,
-		192, 193, 194, 195, 196, 197, 198, 199,
-		200, 201, 202, 203, 204, 205, 206, 207,
-		208, 209, 210, 211, 212, 213, 214, 215,
-		216, 217, 218, 219, 220, 221, 222, 223,
-		224, 225, 226, 227, 228, 229, 230, 231,
-		232, 233, 234, 235, 236, 237, 238, 239,
-		240, 241, 242, 243, 244, 245, 246, 247,
-		248, 249, 250, 251, 252, 253, 254, 255,
-		256, 257, 258, 259, 260, 261, 262, 263,
-	},
-	.oobfree = { {2, 6}, {264, 80} },
-};
-
 /*
  * Generic flash bbt descriptors
  */
@@ -223,6 +93,58 @@ static struct nand_bbt_descr bbt_mirror_descr = {
 	.pattern = mirror_pattern,
 };
 
+static int fsl_ifc_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 8;
+	oobregion->length = chip->ecc.bytes * chip->ecc.steps;
+
+	return 0;
+}
+
+static int fsl_ifc_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int eccbytes = chip->ecc.bytes * chip->ecc.steps;
+
+	if (section > 1)
+		return -ERANGE;
+
+	if (mtd->writesize == 512 &&
+	    !(chip->options & NAND_BUSWIDTH_16)) {
+		if (!section) {
+			oobregion->offset = 0;
+			oobregion->length = 5;
+		} else {
+			oobregion->offset = 6;
+			oobregion->length = 2;
+		}
+
+		return 0;
+	}
+
+	if (!section) {
+		oobregion->offset = 2;
+		oobregion->length = 6;
+	} else {
+		oobregion->offset = eccbytes + 8;
+		oobregion->length = mtd->oobsize - oobregion->offset;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops fsl_ifc_ooblayout_ops = {
+	.ecc = fsl_ifc_ooblayout_ecc,
+	.free = fsl_ifc_ooblayout_free,
+};
+
 /*
  * Set up the IFC hardware block and page address fields, and the ifc nand
  * structure addr field to point to the correct IFC buffer in memory
@@ -812,8 +734,8 @@ static int fsl_ifc_chip_init_tail(struct mtd_info *mtd)
 							chip->ecc.bytes);
 	dev_dbg(priv->dev, "%s: nand->ecc.total = %d\n", __func__,
 							chip->ecc.total);
-	dev_dbg(priv->dev, "%s: nand->ecc.layout = %p\n", __func__,
-							chip->ecc.layout);
+	dev_dbg(priv->dev, "%s: mtd->ooblayout = %p\n", __func__,
+							mtd->ooblayout);
 	dev_dbg(priv->dev, "%s: mtd->flags = %08x\n", __func__, mtd->flags);
 	dev_dbg(priv->dev, "%s: mtd->size = %lld\n", __func__, mtd->size);
 	dev_dbg(priv->dev, "%s: mtd->erasesize = %d\n", __func__,
@@ -881,7 +803,6 @@ static int fsl_ifc_chip_init(struct fsl_ifc_mtd *priv)
 	struct fsl_ifc_regs __iomem *ifc = ctrl->regs;
 	struct nand_chip *chip = &priv->chip;
 	struct mtd_info *mtd = nand_to_mtd(&priv->chip);
-	struct nand_ecclayout *layout;
 	u32 csor;
 
 	/* Fill in fsl_ifc_mtd structure */
@@ -925,18 +846,9 @@ static int fsl_ifc_chip_init(struct fsl_ifc_mtd *priv)
 
 	csor = ifc_in32(&ifc->csor_cs[priv->bank].csor);
 
-	/* Hardware generates ECC per 512 Bytes */
-	chip->ecc.size = 512;
-	chip->ecc.bytes = 8;
-	chip->ecc.strength = 4;
-
 	switch (csor & CSOR_NAND_PGS_MASK) {
 	case CSOR_NAND_PGS_512:
-		if (chip->options & NAND_BUSWIDTH_16) {
-			layout = &oob_512_16bit_ecc4;
-		} else {
-			layout = &oob_512_8bit_ecc4;
-
+		if (!(chip->options & NAND_BUSWIDTH_16)) {
 			/* Avoid conflict with bad block marker */
 			bbt_main_descr.offs = 0;
 			bbt_mirror_descr.offs = 0;
@@ -946,35 +858,16 @@ static int fsl_ifc_chip_init(struct fsl_ifc_mtd *priv)
 		break;
 
 	case CSOR_NAND_PGS_2K:
-		layout = &oob_2048_ecc4;
 		priv->bufnum_mask = 3;
 		break;
 
 	case CSOR_NAND_PGS_4K:
-		if ((csor & CSOR_NAND_ECC_MODE_MASK) ==
-		    CSOR_NAND_ECC_MODE_4) {
-			layout = &oob_4096_ecc4;
-		} else {
-			layout = &oob_4096_ecc8;
-			chip->ecc.bytes = 16;
-			chip->ecc.strength = 8;
-		}
-
 		priv->bufnum_mask = 1;
 		break;
 
 	case CSOR_NAND_PGS_8K:
-		if ((csor & CSOR_NAND_ECC_MODE_MASK) ==
-		    CSOR_NAND_ECC_MODE_4) {
-			layout = &oob_8192_ecc4;
-		} else {
-			layout = &oob_8192_ecc8;
-			chip->ecc.bytes = 16;
-			chip->ecc.strength = 8;
-		}
-
 		priv->bufnum_mask = 0;
-	break;
+		break;
 
 	default:
 		dev_err(priv->dev, "bad csor %#x: bad page size\n", csor);
@@ -984,7 +877,17 @@ static int fsl_ifc_chip_init(struct fsl_ifc_mtd *priv)
 	/* Must also set CSOR_NAND_ECC_ENC_EN if DEC_EN set */
 	if (csor & CSOR_NAND_ECC_DEC_EN) {
 		chip->ecc.mode = NAND_ECC_HW;
-		chip->ecc.layout = layout;
+		mtd_set_ooblayout(mtd, &fsl_ifc_ooblayout_ops);
+
+		/* Hardware generates ECC per 512 Bytes */
+		chip->ecc.size = 512;
+		if ((csor & CSOR_NAND_ECC_MODE_MASK) == CSOR_NAND_ECC_MODE_4) {
+			chip->ecc.bytes = 8;
+			chip->ecc.strength = 4;
+		} else {
+			chip->ecc.bytes = 16;
+			chip->ecc.strength = 8;
+		}
 	} else {
 		chip->ecc.mode = NAND_ECC_SOFT;
 	}
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:44 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:44 +0100
Subject: [PATCH v3 36/52] mtd: nand: fsmc: get rid of the fsmc_nand_eccplace
 struct
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-37-git-send-email-boris.brezillon@free-electrons.com>

Now that mtd_ooblayout_ecc() returns the ECC byte position using the
OOB free method, we can get rid of the fsmc_nand_eccplace struct.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/fsmc_nand.c | 60 +++++++++++---------------------------------
 include/linux/mtd/fsmc.h     | 18 -------------
 2 files changed, 15 insertions(+), 63 deletions(-)

diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
index 275a98c..1372040 100644
--- a/drivers/mtd/nand/fsmc_nand.c
+++ b/drivers/mtd/nand/fsmc_nand.c
@@ -39,35 +39,6 @@
 #include <linux/amba/bus.h>
 #include <mtd/mtd-abi.h>
 
-/*
- * ECC placement definitions in oobfree type format.
- * There are 13 bytes of ecc for every 512 byte block and it has to be read
- * consecutively and immediately after the 512 byte data block for hardware to
- * generate the error bit offsets in 512 byte data.
- * Managing the ecc bytes in the following way makes it easier for software to
- * read ecc bytes consecutive to data bytes. This way is similar to
- * oobfree structure maintained already in generic nand driver
- */
-static struct fsmc_eccplace fsmc_ecc4_lp_place = {
-	.eccplace = {
-		{.offset = 2, .length = 13},
-		{.offset = 18, .length = 13},
-		{.offset = 34, .length = 13},
-		{.offset = 50, .length = 13},
-		{.offset = 66, .length = 13},
-		{.offset = 82, .length = 13},
-		{.offset = 98, .length = 13},
-		{.offset = 114, .length = 13}
-	}
-};
-
-static struct fsmc_eccplace fsmc_ecc4_sp_place = {
-	.eccplace = {
-		{.offset = 0, .length = 4},
-		{.offset = 6, .length = 9}
-	}
-};
-
 static int fsmc_ecc1_ooblayout_ecc(struct mtd_info *mtd, int section,
 				   struct mtd_oob_region *oobregion)
 {
@@ -105,6 +76,12 @@ static const struct mtd_ooblayout_ops fsmc_ecc1_ooblayout_ops = {
 	.free = fsmc_ecc1_ooblayout_free,
 };
 
+/*
+ * ECC placement definitions in oobfree type format.
+ * There are 13 bytes of ecc for every 512 byte block and it has to be read
+ * consecutively and immediately after the 512 byte data block for hardware to
+ * generate the error bit offsets in 512 byte data.
+ */
 static int fsmc_ecc4_ooblayout_ecc(struct mtd_info *mtd, int section,
 				   struct mtd_oob_region *oobregion)
 {
@@ -155,7 +132,6 @@ static const struct mtd_ooblayout_ops fsmc_ecc4_ooblayout_ops = {
  * @partitions:		Partition info for a NAND Flash.
  * @nr_partitions:	Total number of partition of a NAND flash.
  *
- * @ecc_place:		ECC placing locations in oobfree type format.
  * @bank:		Bank number for probed device.
  * @clk:		Clock structure for FSMC.
  *
@@ -175,7 +151,6 @@ struct fsmc_nand_data {
 	struct mtd_partition	*partitions;
 	unsigned int		nr_partitions;
 
-	struct fsmc_eccplace	*ecc_place;
 	unsigned int		bank;
 	struct device		*dev;
 	enum access_mode	mode;
@@ -582,8 +557,6 @@ static void fsmc_write_buf_dma(struct mtd_info *mtd, const uint8_t *buf,
 static int fsmc_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
 				 uint8_t *buf, int oob_required, int page)
 {
-	struct fsmc_nand_data *host = mtd_to_fsmc(mtd);
-	struct fsmc_eccplace *ecc_place = host->ecc_place;
 	int i, j, s, stat, eccsize = chip->ecc.size;
 	int eccbytes = chip->ecc.bytes;
 	int eccsteps = chip->ecc.steps;
@@ -606,9 +579,15 @@ static int fsmc_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
 		chip->read_buf(mtd, p, eccsize);
 
 		for (j = 0; j < eccbytes;) {
-			off = ecc_place->eccplace[group].offset;
-			len = ecc_place->eccplace[group].length;
-			group++;
+			struct mtd_oob_region oobregion;
+			int ret;
+
+			ret = mtd_ooblayout_ecc(mtd, group++, &oobregion);
+			if (ret)
+				return ret;
+
+			off = oobregion.offset;
+			len = oobregion.length;
 
 			/*
 			 * length is intentionally kept a higher multiple of 2
@@ -956,19 +935,10 @@ static int __init fsmc_nand_probe(struct platform_device *pdev)
 	if (AMBA_REV_BITS(host->pid) >= 8) {
 		switch (mtd->oobsize) {
 		case 16:
-			host->ecc_place = &fsmc_ecc4_sp_place;
-			break;
 		case 64:
-			host->ecc_place = &fsmc_ecc4_lp_place;
-			break;
 		case 128:
-			host->ecc_place = &fsmc_ecc4_lp_place;
-			break;
 		case 224:
-			host->ecc_place = &fsmc_ecc4_lp_place;
-			break;
 		case 256:
-			host->ecc_place = &fsmc_ecc4_lp_place;
 			break;
 		default:
 			dev_warn(&pdev->dev, "No oob scheme defined for oobsize %d\n",
diff --git a/include/linux/mtd/fsmc.h b/include/linux/mtd/fsmc.h
index c8be32e..ad3c348 100644
--- a/include/linux/mtd/fsmc.h
+++ b/include/linux/mtd/fsmc.h
@@ -103,24 +103,6 @@
 
 #define FSMC_BUSY_WAIT_TIMEOUT	(1 * HZ)
 
-/*
- * There are 13 bytes of ecc for every 512 byte block in FSMC version 8
- * and it has to be read consecutively and immediately after the 512
- * byte data block for hardware to generate the error bit offsets
- * Managing the ecc bytes in the following way is easier. This way is
- * similar to oobfree structure maintained already in u-boot nand driver
- */
-#define MAX_ECCPLACE_ENTRIES	32
-
-struct fsmc_nand_eccplace {
-	uint8_t offset;
-	uint8_t length;
-};
-
-struct fsmc_eccplace {
-	struct fsmc_nand_eccplace eccplace[MAX_ECCPLACE_ENTRIES];
-};
-
 struct fsmc_nand_timings {
 	uint8_t tclr;
 	uint8_t tar;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:45 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:45 +0100
Subject: [PATCH v3 37/52] mtd: nand: gpmi: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-38-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 52 ++++++++++++++++++++++++++--------
 1 file changed, 40 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 3a29b65..316b5ac 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -47,10 +47,44 @@ static struct nand_bbt_descr gpmi_bbt_descr = {
  * We may change the layout if we can get the ECC info from the datasheet,
  * else we will use all the (page + OOB).
  */
-static struct nand_ecclayout gpmi_hw_ecclayout = {
-	.eccbytes = 0,
-	.eccpos = { 0, },
-	.oobfree = { {.offset = 0, .length = 0} }
+static int gpmi_ooblayout_ecc(struct mtd_info *mtd, int section,
+			      struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct gpmi_nand_data *this = nand_get_controller_data(chip);
+	struct bch_geometry *geo = &this->bch_geometry;
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 0;
+	oobregion->length = geo->page_size - mtd->writesize;
+
+	return 0;
+}
+
+static int gpmi_ooblayout_free(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct gpmi_nand_data *this = nand_get_controller_data(chip);
+	struct bch_geometry *geo = &this->bch_geometry;
+
+	if (section)
+		return -ERANGE;
+
+	/* The available oob size we have. */
+	if (geo->page_size < mtd->writesize + mtd->oobsize) {
+		oobregion->offset = geo->page_size - mtd->writesize;
+		oobregion->length = mtd->oobsize - oobregion->offset;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops gpmi_ooblayout_ops = {
+	.ecc = gpmi_ooblayout_ecc,
+	.free = gpmi_ooblayout_free,
 };
 
 static const struct gpmi_devdata gpmi_devdata_imx23 = {
@@ -141,7 +175,6 @@ static int set_geometry_by_ecc_info(struct gpmi_nand_data *this)
 	struct bch_geometry *geo = &this->bch_geometry;
 	struct nand_chip *chip = &this->nand;
 	struct mtd_info *mtd = nand_to_mtd(chip);
-	struct nand_oobfree *of = gpmi_hw_ecclayout.oobfree;
 	unsigned int block_mark_bit_offset;
 
 	if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
@@ -229,12 +262,6 @@ static int set_geometry_by_ecc_info(struct gpmi_nand_data *this)
 	geo->page_size = mtd->writesize + geo->metadata_size +
 		(geo->gf_len * geo->ecc_strength * geo->ecc_chunk_count) / 8;
 
-	/* The available oob size we have. */
-	if (geo->page_size < mtd->writesize + mtd->oobsize) {
-		of->offset = geo->page_size - mtd->writesize;
-		of->length = mtd->oobsize - of->offset;
-	}
-
 	geo->payload_size = mtd->writesize;
 
 	geo->auxiliary_status_offset = ALIGN(geo->metadata_size, 4);
@@ -1841,6 +1868,7 @@ static void gpmi_nand_exit(struct gpmi_nand_data *this)
 static int gpmi_init_last(struct gpmi_nand_data *this)
 {
 	struct nand_chip *chip = &this->nand;
+	struct mtd_info *mtd = nand_to_mtd(chip);
 	struct nand_ecc_ctrl *ecc = &chip->ecc;
 	struct bch_geometry *bch_geo = &this->bch_geometry;
 	int ret;
@@ -1862,7 +1890,7 @@ static int gpmi_init_last(struct gpmi_nand_data *this)
 	ecc->mode	= NAND_ECC_HW;
 	ecc->size	= bch_geo->ecc_chunk_size;
 	ecc->strength	= bch_geo->ecc_strength;
-	ecc->layout	= &gpmi_hw_ecclayout;
+	mtd_set_ooblayout(mtd, &gpmi_ooblayout_ops);
 
 	/*
 	 * We only enable the subpage read when:
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:46 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:46 +0100
Subject: [PATCH v3 38/52] mtd: nand: hisi504: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-39-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/hisi504_nand.c | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/hisi504_nand.c b/drivers/mtd/nand/hisi504_nand.c
index 96502b6..7bf844c 100644
--- a/drivers/mtd/nand/hisi504_nand.c
+++ b/drivers/mtd/nand/hisi504_nand.c
@@ -631,8 +631,28 @@ static void hisi_nfc_host_init(struct hinfc_host *host)
 	hinfc_write(host, HINFC504_INTEN_DMA, HINFC504_INTEN);
 }
 
-static struct nand_ecclayout nand_ecc_2K_16bits = {
-	.oobfree = { {2, 6} },
+static int hisi_ooblayout_ecc(struct mtd_info *mtd, int section,
+			      struct mtd_oob_region *oobregion)
+{
+	/* FIXME: add ECC bytes position */
+	return -ENOTSUPP;
+}
+
+static int hisi_ooblayout_free(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 2;
+	oobregion->length = 6;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops hisi_ooblayout_ops = {
+	.ecc = hisi_ooblayout_ecc,
+	.free = hisi_ooblayout_free,
 };
 
 static int hisi_nfc_ecc_probe(struct hinfc_host *host)
@@ -668,7 +688,7 @@ static int hisi_nfc_ecc_probe(struct hinfc_host *host)
 	case 16:
 		ecc_bits = 6;
 		if (mtd->writesize == 2048)
-			chip->ecc.layout = &nand_ecc_2K_16bits;
+			mtd_set_ooblayout(mtd, &hisi_ooblayout_ops);
 
 		/* TODO: add more page size support */
 		break;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:47 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:47 +0100
Subject: [PATCH v3 39/52] mtd: nand: jz4780: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-40-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/jz4780_nand.c | 19 +++++--------------
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/drivers/mtd/nand/jz4780_nand.c b/drivers/mtd/nand/jz4780_nand.c
index e1c016c..b86a579 100644
--- a/drivers/mtd/nand/jz4780_nand.c
+++ b/drivers/mtd/nand/jz4780_nand.c
@@ -56,8 +56,6 @@ struct jz4780_nand_chip {
 	struct nand_chip chip;
 	struct list_head chip_list;
 
-	struct nand_ecclayout ecclayout;
-
 	struct gpio_desc *busy_gpio;
 	struct gpio_desc *wp_gpio;
 	unsigned int reading: 1;
@@ -165,8 +163,7 @@ static int jz4780_nand_init_ecc(struct jz4780_nand_chip *nand, struct device *de
 	struct nand_chip *chip = &nand->chip;
 	struct mtd_info *mtd = nand_to_mtd(chip);
 	struct jz4780_nand_controller *nfc = to_jz4780_nand_controller(chip->controller);
-	struct nand_ecclayout *layout = &nand->ecclayout;
-	u32 start, i;
+	int eccbytes;
 
 	chip->ecc.bytes = fls((1 + 8) * chip->ecc.size)	*
 				(chip->ecc.strength / 8);
@@ -201,23 +198,17 @@ static int jz4780_nand_init_ecc(struct jz4780_nand_chip *nand, struct device *de
 		return 0;
 
 	/* Generate ECC layout. ECC codes are right aligned in the OOB area. */
-	layout->eccbytes = mtd->writesize / chip->ecc.size * chip->ecc.bytes;
+	eccbytes = mtd->writesize / chip->ecc.size * chip->ecc.bytes;
 
-	if (layout->eccbytes > mtd->oobsize - 2) {
+	if (eccbytes > mtd->oobsize - 2) {
 		dev_err(dev,
 			"invalid ECC config: required %d ECC bytes, but only %d are available",
-			layout->eccbytes, mtd->oobsize - 2);
+			eccbytes, mtd->oobsize - 2);
 		return -EINVAL;
 	}
 
-	start = mtd->oobsize - layout->eccbytes;
-	for (i = 0; i < layout->eccbytes; i++)
-		layout->eccpos[i] = start + i;
-
-	layout->oobfree[0].offset = 2;
-	layout->oobfree[0].length = mtd->oobsize - layout->eccbytes - 2;
+	mtd->ooblayout = &nand_ooblayout_lp_ops;
 
-	chip->ecc.layout = layout;
 	return 0;
 }
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:48 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:48 +0100
Subject: [PATCH v3 40/52] mtd: nand: lpc32xx: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-41-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/lpc32xx_mlc.c | 50 ++++++++++++++++++++++++++++--------------
 drivers/mtd/nand/lpc32xx_slc.c | 41 +++++++++++++++++++++++++++-------
 2 files changed, 66 insertions(+), 25 deletions(-)

diff --git a/drivers/mtd/nand/lpc32xx_mlc.c b/drivers/mtd/nand/lpc32xx_mlc.c
index d8c3e7a..f668282 100644
--- a/drivers/mtd/nand/lpc32xx_mlc.c
+++ b/drivers/mtd/nand/lpc32xx_mlc.c
@@ -139,22 +139,37 @@ struct lpc32xx_nand_cfg_mlc {
 	unsigned num_parts;
 };
 
-static struct nand_ecclayout lpc32xx_nand_oob = {
-	.eccbytes = 40,
-	.eccpos = { 6,  7,  8,  9, 10, 11, 12, 13, 14, 15,
-		   22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
-		   38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
-		   54, 55, 56, 57, 58, 59, 60, 61, 62, 63 },
-	.oobfree = {
-		{ .offset = 0,
-		  .length = 6, },
-		{ .offset = 16,
-		  .length = 6, },
-		{ .offset = 32,
-		  .length = 6, },
-		{ .offset = 48,
-		  .length = 6, },
-		},
+static int lpc32xx_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand_chip = mtd_to_nand(mtd);
+
+	if (section >= nand_chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = ((section + 1) * 16) - nand_chip->ecc.bytes;
+	oobregion->length = nand_chip->ecc.bytes;
+
+	return 0;
+}
+
+static int lpc32xx_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand_chip = mtd_to_nand(mtd);
+
+	if (section >= nand_chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = 16 * section;
+	oobregion->length = 16 - nand_chip->ecc.bytes;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops lpc32xx_ooblayout_ops = {
+	.ecc = lpc32xx_ooblayout_ecc,
+	.free = lpc32xx_ooblayout_free,
 };
 
 static struct nand_bbt_descr lpc32xx_nand_bbt = {
@@ -713,6 +728,7 @@ static int lpc32xx_nand_probe(struct platform_device *pdev)
 	nand_chip->ecc.write_oob = lpc32xx_write_oob;
 	nand_chip->ecc.read_oob = lpc32xx_read_oob;
 	nand_chip->ecc.strength = 4;
+	nand_chip->ecc.bytes = 10;
 	nand_chip->waitfunc = lpc32xx_waitfunc;
 
 	nand_chip->options = NAND_NO_SUBPAGE_WRITE;
@@ -751,7 +767,7 @@ static int lpc32xx_nand_probe(struct platform_device *pdev)
 
 	nand_chip->ecc.mode = NAND_ECC_HW;
 	nand_chip->ecc.size = 512;
-	nand_chip->ecc.layout = &lpc32xx_nand_oob;
+	mtd_set_ooblayout(mtd, &lpc32xx_ooblayout_ops);
 	host->mlcsubpages = mtd->writesize / 512;
 
 	/* initially clear interrupt status */
diff --git a/drivers/mtd/nand/lpc32xx_slc.c b/drivers/mtd/nand/lpc32xx_slc.c
index 10cf8e62..219dd67 100644
--- a/drivers/mtd/nand/lpc32xx_slc.c
+++ b/drivers/mtd/nand/lpc32xx_slc.c
@@ -146,13 +146,38 @@
  * NAND ECC Layout for small page NAND devices
  * Note: For large and huge page devices, the default layouts are used
  */
-static struct nand_ecclayout lpc32xx_nand_oob_16 = {
-	.eccbytes = 6,
-	.eccpos = {10, 11, 12, 13, 14, 15},
-	.oobfree = {
-		{ .offset = 0, .length = 4 },
-		{ .offset = 6, .length = 4 },
-	},
+static int lpc32xx_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->length = 6;
+	oobregion->offset = 10;
+
+	return 0;
+}
+
+static int lpc32xx_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	if (section > 1)
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 0;
+		oobregion->length = 4;
+	} else {
+		oobregion->offset = 6;
+		oobregion->length = 4;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops lpc32xx_ooblayout_ops = {
+	.ecc = lpc32xx_ooblayout_ecc,
+	.free = lpc32xx_ooblayout_free,
 };
 
 static u8 bbt_pattern[] = {'B', 'b', 't', '0' };
@@ -886,7 +911,7 @@ static int lpc32xx_nand_probe(struct platform_device *pdev)
 	 * custom BBT marker layout.
 	 */
 	if (mtd->writesize <= 512)
-		chip->ecc.layout = &lpc32xx_nand_oob_16;
+		mtd_set_ooblayout(mtd, &lpc32xx_ooblayout_ops);
 
 	/* These sizes remain the same regardless of page size */
 	chip->ecc.size = 256;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:49 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:49 +0100
Subject: [PATCH v3 41/52] mtd: nand: mxc: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-42-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/mxc_nand.c | 212 ++++++++++++++++++++++----------------------
 1 file changed, 105 insertions(+), 107 deletions(-)

diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
index 854c832..628f834 100644
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -149,7 +149,7 @@ struct mxc_nand_devtype_data {
 	int (*check_int)(struct mxc_nand_host *);
 	void (*irq_control)(struct mxc_nand_host *, int);
 	u32 (*get_ecc_status)(struct mxc_nand_host *);
-	struct nand_ecclayout *ecclayout_512, *ecclayout_2k, *ecclayout_4k;
+	const struct mtd_ooblayout_ops *ooblayout;
 	void (*select_chip)(struct mtd_info *mtd, int chip);
 	int (*correct_data)(struct mtd_info *mtd, u_char *dat,
 			u_char *read_ecc, u_char *calc_ecc);
@@ -200,73 +200,6 @@ struct mxc_nand_host {
 	struct mxc_nand_platform_data pdata;
 };
 
-/* OOB placement block for use with hardware ecc generation */
-static struct nand_ecclayout nandv1_hw_eccoob_smallpage = {
-	.eccbytes = 5,
-	.eccpos = {6, 7, 8, 9, 10},
-	.oobfree = {{0, 5}, {12, 4}, }
-};
-
-static struct nand_ecclayout nandv1_hw_eccoob_largepage = {
-	.eccbytes = 20,
-	.eccpos = {6, 7, 8, 9, 10, 22, 23, 24, 25, 26,
-		   38, 39, 40, 41, 42, 54, 55, 56, 57, 58},
-	.oobfree = {{2, 4}, {11, 10}, {27, 10}, {43, 10}, {59, 5}, }
-};
-
-/* OOB description for 512 byte pages with 16 byte OOB */
-static struct nand_ecclayout nandv2_hw_eccoob_smallpage = {
-	.eccbytes = 1 * 9,
-	.eccpos = {
-		 7,  8,  9, 10, 11, 12, 13, 14, 15
-	},
-	.oobfree = {
-		{.offset = 0, .length = 5}
-	}
-};
-
-/* OOB description for 2048 byte pages with 64 byte OOB */
-static struct nand_ecclayout nandv2_hw_eccoob_largepage = {
-	.eccbytes = 4 * 9,
-	.eccpos = {
-		 7,  8,  9, 10, 11, 12, 13, 14, 15,
-		23, 24, 25, 26, 27, 28, 29, 30, 31,
-		39, 40, 41, 42, 43, 44, 45, 46, 47,
-		55, 56, 57, 58, 59, 60, 61, 62, 63
-	},
-	.oobfree = {
-		{.offset = 2, .length = 4},
-		{.offset = 16, .length = 7},
-		{.offset = 32, .length = 7},
-		{.offset = 48, .length = 7}
-	}
-};
-
-/* OOB description for 4096 byte pages with 128 byte OOB */
-static struct nand_ecclayout nandv2_hw_eccoob_4k = {
-	.eccbytes = 8 * 9,
-	.eccpos = {
-		7,  8,  9, 10, 11, 12, 13, 14, 15,
-		23, 24, 25, 26, 27, 28, 29, 30, 31,
-		39, 40, 41, 42, 43, 44, 45, 46, 47,
-		55, 56, 57, 58, 59, 60, 61, 62, 63,
-		71, 72, 73, 74, 75, 76, 77, 78, 79,
-		87, 88, 89, 90, 91, 92, 93, 94, 95,
-		103, 104, 105, 106, 107, 108, 109, 110, 111,
-		119, 120, 121, 122, 123, 124, 125, 126, 127,
-	},
-	.oobfree = {
-		{.offset = 2, .length = 4},
-		{.offset = 16, .length = 7},
-		{.offset = 32, .length = 7},
-		{.offset = 48, .length = 7},
-		{.offset = 64, .length = 7},
-		{.offset = 80, .length = 7},
-		{.offset = 96, .length = 7},
-		{.offset = 112, .length = 7},
-	}
-};
-
 static const char * const part_probes[] = {
 	"cmdlinepart", "RedBoot", "ofpart", NULL };
 
@@ -942,6 +875,99 @@ static void mxc_do_addr_cycle(struct mtd_info *mtd, int column, int page_addr)
 	}
 }
 
+static int mxc_v1_ooblayout_ecc(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand_chip = mtd_to_nand(mtd);
+
+	if (section >= nand_chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 6;
+	oobregion->length = nand_chip->ecc.bytes;
+
+	return 0;
+}
+
+static int mxc_v1_ooblayout_free(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand_chip = mtd_to_nand(mtd);
+
+	if (section > nand_chip->ecc.steps)
+		return -ERANGE;
+
+	if (!section) {
+		if (mtd->writesize <= 512) {
+			oobregion->offset = 0;
+			oobregion->length = 5;
+		} else {
+			oobregion->offset = 2;
+			oobregion->length = 4;
+		}
+	} else {
+		oobregion->offset = ((section - 1) * 16) +
+				    nand_chip->ecc.bytes + 6;
+		if (section < nand_chip->ecc.steps)
+			oobregion->length = (section * 16) + 6 -
+					    oobregion->offset;
+		else
+			oobregion->length = mtd->oobsize - oobregion->offset;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops mxc_v1_ooblayout_ops = {
+	.ecc = mxc_v1_ooblayout_ecc,
+	.free = mxc_v1_ooblayout_free,
+};
+
+static int mxc_v2_ooblayout_ecc(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand_chip = mtd_to_nand(mtd);
+	int stepsize = nand_chip->ecc.bytes == 9 ? 16 : 26;
+
+	if (section >= nand_chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = (section * stepsize) + 7;
+	oobregion->length = nand_chip->ecc.bytes;
+
+	return 0;
+}
+
+static int mxc_v2_ooblayout_free(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand_chip = mtd_to_nand(mtd);
+	int stepsize = nand_chip->ecc.bytes == 9 ? 16 : 26;
+
+	if (section > nand_chip->ecc.steps)
+		return -ERANGE;
+
+	if (!section) {
+		if (mtd->writesize <= 512) {
+			oobregion->offset = 0;
+			oobregion->length = 5;
+		} else {
+			oobregion->offset = 2;
+			oobregion->length = 4;
+		}
+	} else {
+		oobregion->offset = section * stepsize;
+		oobregion->length = 7;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops mxc_v2_ooblayout_ops = {
+	.ecc = mxc_v2_ooblayout_ecc,
+	.free = mxc_v2_ooblayout_free,
+};
+
 /*
  * v2 and v3 type controllers can do 4bit or 8bit ecc depending
  * on how much oob the nand chip has. For 8bit ecc we need at least
@@ -959,23 +985,6 @@ static int get_eccsize(struct mtd_info *mtd)
 		return 8;
 }
 
-static void ecc_8bit_layout_4k(struct nand_ecclayout *layout)
-{
-	int i, j;
-
-	layout->eccbytes = 8*18;
-	for (i = 0; i < 8; i++)
-		for (j = 0; j < 18; j++)
-			layout->eccpos[i*18 + j] = i*26 + j + 7;
-
-	layout->oobfree[0].offset = 2;
-	layout->oobfree[0].length = 4;
-	for (i = 1; i < 8; i++) {
-		layout->oobfree[i].offset = i*26;
-		layout->oobfree[i].length = 7;
-	}
-}
-
 static void preset_v1(struct mtd_info *mtd)
 {
 	struct nand_chip *nand_chip = mtd_to_nand(mtd);
@@ -1269,9 +1278,7 @@ static const struct mxc_nand_devtype_data imx21_nand_devtype_data = {
 	.check_int = check_int_v1_v2,
 	.irq_control = irq_control_v1_v2,
 	.get_ecc_status = get_ecc_status_v1,
-	.ecclayout_512 = &nandv1_hw_eccoob_smallpage,
-	.ecclayout_2k = &nandv1_hw_eccoob_largepage,
-	.ecclayout_4k = &nandv1_hw_eccoob_smallpage, /* XXX: needs fix */
+	.ooblayout = &mxc_v1_ooblayout_ops,
 	.select_chip = mxc_nand_select_chip_v1_v3,
 	.correct_data = mxc_nand_correct_data_v1,
 	.irqpending_quirk = 1,
@@ -1294,9 +1301,7 @@ static const struct mxc_nand_devtype_data imx27_nand_devtype_data = {
 	.check_int = check_int_v1_v2,
 	.irq_control = irq_control_v1_v2,
 	.get_ecc_status = get_ecc_status_v1,
-	.ecclayout_512 = &nandv1_hw_eccoob_smallpage,
-	.ecclayout_2k = &nandv1_hw_eccoob_largepage,
-	.ecclayout_4k = &nandv1_hw_eccoob_smallpage, /* XXX: needs fix */
+	.ooblayout = &mxc_v1_ooblayout_ops,
 	.select_chip = mxc_nand_select_chip_v1_v3,
 	.correct_data = mxc_nand_correct_data_v1,
 	.irqpending_quirk = 0,
@@ -1320,9 +1325,7 @@ static const struct mxc_nand_devtype_data imx25_nand_devtype_data = {
 	.check_int = check_int_v1_v2,
 	.irq_control = irq_control_v1_v2,
 	.get_ecc_status = get_ecc_status_v2,
-	.ecclayout_512 = &nandv2_hw_eccoob_smallpage,
-	.ecclayout_2k = &nandv2_hw_eccoob_largepage,
-	.ecclayout_4k = &nandv2_hw_eccoob_4k,
+	.ooblayout = &mxc_v2_ooblayout_ops,
 	.select_chip = mxc_nand_select_chip_v2,
 	.correct_data = mxc_nand_correct_data_v2_v3,
 	.irqpending_quirk = 0,
@@ -1346,9 +1349,7 @@ static const struct mxc_nand_devtype_data imx51_nand_devtype_data = {
 	.check_int = check_int_v3,
 	.irq_control = irq_control_v3,
 	.get_ecc_status = get_ecc_status_v3,
-	.ecclayout_512 = &nandv2_hw_eccoob_smallpage,
-	.ecclayout_2k = &nandv2_hw_eccoob_largepage,
-	.ecclayout_4k = &nandv2_hw_eccoob_smallpage, /* XXX: needs fix */
+	.ooblayout = &mxc_v2_ooblayout_ops,
 	.select_chip = mxc_nand_select_chip_v1_v3,
 	.correct_data = mxc_nand_correct_data_v2_v3,
 	.irqpending_quirk = 0,
@@ -1373,9 +1374,7 @@ static const struct mxc_nand_devtype_data imx53_nand_devtype_data = {
 	.check_int = check_int_v3,
 	.irq_control = irq_control_v3,
 	.get_ecc_status = get_ecc_status_v3,
-	.ecclayout_512 = &nandv2_hw_eccoob_smallpage,
-	.ecclayout_2k = &nandv2_hw_eccoob_largepage,
-	.ecclayout_4k = &nandv2_hw_eccoob_smallpage, /* XXX: needs fix */
+	.ooblayout = &mxc_v2_ooblayout_ops,
 	.select_chip = mxc_nand_select_chip_v1_v3,
 	.correct_data = mxc_nand_correct_data_v2_v3,
 	.irqpending_quirk = 0,
@@ -1576,7 +1575,7 @@ static int mxcnd_probe(struct platform_device *pdev)
 
 	this->select_chip = host->devtype_data->select_chip;
 	this->ecc.size = 512;
-	this->ecc.layout = host->devtype_data->ecclayout_512;
+	mtd_set_ooblayout(mtd, host->devtype_data->ooblayout);
 
 	if (host->pdata.hw_ecc) {
 		this->ecc.calculate = mxc_nand_calculate_ecc;
@@ -1649,12 +1648,11 @@ static int mxcnd_probe(struct platform_device *pdev)
 	/* Call preset again, with correct writesize this time */
 	host->devtype_data->preset(mtd);
 
-	if (mtd->writesize == 2048)
-		this->ecc.layout = host->devtype_data->ecclayout_2k;
-	else if (mtd->writesize == 4096) {
-		this->ecc.layout = host->devtype_data->ecclayout_4k;
-		if (get_eccsize(mtd) == 8)
-			ecc_8bit_layout_4k(this->ecc.layout);
+	if (!this->ecc.bytes) {
+		if (host->eccsize == 8)
+			this->ecc.bytes = 18;
+		else if (host->eccsize == 4)
+			this->ecc.bytes = 9;
 	}
 
 	/*
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:50 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:50 +0100
Subject: [PATCH v3 42/52] mtd: nand: omap2: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-43-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/omap2.c | 194 +++++++++++++++++++++++++++--------------------
 1 file changed, 113 insertions(+), 81 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 4ebf16b..50c5b42 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -169,8 +169,6 @@ struct omap_nand_info {
 	u_char				*buf;
 	int					buf_len;
 	struct gpmc_nand_regs		reg;
-	/* generated at runtime depending on ECC algorithm and layout selected */
-	struct nand_ecclayout		oobinfo;
 	/* fields specific for BCHx_HW ECC scheme */
 	struct device			*elm_dev;
 	struct device_node		*of_node;
@@ -1639,19 +1637,108 @@ static bool omap2_nand_ecc_check(struct omap_nand_info *info,
 	return true;
 }
 
+static int omap_ooblayout_ecc(struct mtd_info *mtd, int section,
+			      struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int off = chip->options & NAND_BUSWIDTH_16 ?
+		  BADBLOCK_MARKER_LENGTH : 1;
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = off;
+	oobregion->length = chip->ecc.bytes * chip->ecc.steps;
+
+	return 0;
+}
+
+static int omap_ooblayout_free(struct mtd_info *mtd, int section,
+			       struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int off = chip->options & NAND_BUSWIDTH_16 ?
+		  BADBLOCK_MARKER_LENGTH : 1;
+
+	if (section)
+		return -ERANGE;
+
+	off += chip->ecc.bytes * chip->ecc.steps;
+	if (off >= mtd->oobsize)
+		return -ERANGE;
+
+	oobregion->offset = off;
+	oobregion->length = mtd->oobsize - off;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops omap_ooblayout_ops = {
+	.ecc = omap_ooblayout_ecc,
+	.free = omap_ooblayout_free,
+};
+
+static int omap_sw_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int off = chip->options & NAND_BUSWIDTH_16 ?
+		  BADBLOCK_MARKER_LENGTH : 1;
+
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
+
+	/*
+	 * When SW correction is employed, one OMAP specific marker byte is
+	 * reserved after each ECC step.
+	 */
+	oobregion->offset = off + (section * (chip->ecc.bytes + 1));
+	oobregion->length = chip->ecc.bytes;
+
+	return 0;
+}
+
+static int omap_sw_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	int off = chip->options & NAND_BUSWIDTH_16 ?
+		  BADBLOCK_MARKER_LENGTH : 1;
+
+	if (section)
+		return -ERANGE;
+
+	/*
+	 * When SW correction is employed, one OMAP specific marker byte is
+	 * reserved after each ECC step.
+	 */
+	off += ((chip->ecc.bytes + 1) * chip->ecc.steps);
+	if (off >= mtd->oobsize)
+		return -ERANGE;
+
+	oobregion->offset = off;
+	oobregion->length = mtd->oobsize - off;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops omap_sw_ooblayout_ops = {
+	.ecc = omap_sw_ooblayout_ecc,
+	.free = omap_sw_ooblayout_free,
+};
+
 static int omap_nand_probe(struct platform_device *pdev)
 {
 	struct omap_nand_info		*info;
 	struct omap_nand_platform_data	*pdata;
 	struct mtd_info			*mtd;
 	struct nand_chip		*nand_chip;
-	struct nand_ecclayout		*ecclayout;
 	int				err;
-	int				i;
 	dma_cap_mask_t			mask;
 	unsigned			sig;
-	unsigned			oob_index;
 	struct resource			*res;
+	int				min_oobbytes;
+	int				oobbytes_per_step;
 
 	pdata = dev_get_platdata(&pdev->dev);
 	if (pdata == NULL) {
@@ -1810,7 +1897,7 @@ static int omap_nand_probe(struct platform_device *pdev)
 
 	/*
 	 * Bail out earlier to let NAND_ECC_SOFT code create its own
-	 * ecclayout instead of using ours.
+	 * ooblayout instead of using ours.
 	 */
 	if (info->ecc_opt == OMAP_ECC_HAM1_CODE_SW) {
 		nand_chip->ecc.mode = NAND_ECC_SOFT;
@@ -1818,8 +1905,6 @@ static int omap_nand_probe(struct platform_device *pdev)
 	}
 
 	/* populate MTD interface based on ECC scheme */
-	ecclayout		= &info->oobinfo;
-	nand_chip->ecc.layout	= ecclayout;
 	switch (info->ecc_opt) {
 	case OMAP_ECC_HAM1_CODE_HW:
 		pr_info("nand: using OMAP_ECC_HAM1_CODE_HW\n");
@@ -1830,19 +1915,8 @@ static int omap_nand_probe(struct platform_device *pdev)
 		nand_chip->ecc.calculate        = omap_calculate_ecc;
 		nand_chip->ecc.hwctl            = omap_enable_hwecc;
 		nand_chip->ecc.correct          = omap_correct_data;
-		/* define ECC layout */
-		ecclayout->eccbytes		= nand_chip->ecc.bytes *
-							(mtd->writesize /
-							nand_chip->ecc.size);
-		if (nand_chip->options & NAND_BUSWIDTH_16)
-			oob_index		= BADBLOCK_MARKER_LENGTH;
-		else
-			oob_index		= 1;
-		for (i = 0; i < ecclayout->eccbytes; i++, oob_index++)
-			ecclayout->eccpos[i]	= oob_index;
-		/* no reserved-marker in ecclayout for this ecc-scheme */
-		ecclayout->oobfree->offset	=
-				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
+		mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
+		oobbytes_per_step		= nand_chip->ecc.bytes;
 		break;
 
 	case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
@@ -1854,19 +1928,9 @@ static int omap_nand_probe(struct platform_device *pdev)
 		nand_chip->ecc.hwctl		= omap_enable_hwecc_bch;
 		nand_chip->ecc.correct		= nand_bch_correct_data;
 		nand_chip->ecc.calculate	= omap_calculate_ecc_bch;
-		/* define ECC layout */
-		ecclayout->eccbytes		= nand_chip->ecc.bytes *
-							(mtd->writesize /
-							nand_chip->ecc.size);
-		oob_index			= BADBLOCK_MARKER_LENGTH;
-		for (i = 0; i < ecclayout->eccbytes; i++, oob_index++) {
-			ecclayout->eccpos[i] = oob_index;
-			if (((i + 1) % nand_chip->ecc.bytes) == 0)
-				oob_index++;
-		}
-		/* include reserved-marker in ecclayout->oobfree calculation */
-		ecclayout->oobfree->offset	= 1 +
-				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
+		mtd_set_ooblayout(mtd, &omap_sw_ooblayout_ops);
+		/* Reserve one byte for the OMAP marker */
+		oobbytes_per_step		= nand_chip->ecc.bytes + 1;
 		/* software bch library is used for locating errors */
 		nand_chip->ecc.priv		= nand_bch_init(mtd);
 		if (!nand_chip->ecc.priv) {
@@ -1888,16 +1952,8 @@ static int omap_nand_probe(struct platform_device *pdev)
 		nand_chip->ecc.calculate	= omap_calculate_ecc_bch;
 		nand_chip->ecc.read_page	= omap_read_page_bch;
 		nand_chip->ecc.write_page	= omap_write_page_bch;
-		/* define ECC layout */
-		ecclayout->eccbytes		= nand_chip->ecc.bytes *
-							(mtd->writesize /
-							nand_chip->ecc.size);
-		oob_index			= BADBLOCK_MARKER_LENGTH;
-		for (i = 0; i < ecclayout->eccbytes; i++, oob_index++)
-			ecclayout->eccpos[i]	= oob_index;
-		/* reserved marker already included in ecclayout->eccbytes */
-		ecclayout->oobfree->offset	=
-				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
+		mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
+		oobbytes_per_step		= nand_chip->ecc.bytes;
 
 		err = elm_config(info->elm_dev, BCH4_ECC,
 				 mtd->writesize / nand_chip->ecc.size,
@@ -1915,19 +1971,9 @@ static int omap_nand_probe(struct platform_device *pdev)
 		nand_chip->ecc.hwctl		= omap_enable_hwecc_bch;
 		nand_chip->ecc.correct		= nand_bch_correct_data;
 		nand_chip->ecc.calculate	= omap_calculate_ecc_bch;
-		/* define ECC layout */
-		ecclayout->eccbytes		= nand_chip->ecc.bytes *
-							(mtd->writesize /
-							nand_chip->ecc.size);
-		oob_index			= BADBLOCK_MARKER_LENGTH;
-		for (i = 0; i < ecclayout->eccbytes; i++, oob_index++) {
-			ecclayout->eccpos[i] = oob_index;
-			if (((i + 1) % nand_chip->ecc.bytes) == 0)
-				oob_index++;
-		}
-		/* include reserved-marker in ecclayout->oobfree calculation */
-		ecclayout->oobfree->offset	= 1 +
-				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
+		mtd_set_ooblayout(mtd, &omap_sw_ooblayout_ops);
+		/* Reserve one byte for the OMAP marker */
+		oobbytes_per_step		= nand_chip->ecc.bytes + 1;
 		/* software bch library is used for locating errors */
 		nand_chip->ecc.priv		= nand_bch_init(mtd);
 		if (!nand_chip->ecc.priv) {
@@ -1949,6 +1995,8 @@ static int omap_nand_probe(struct platform_device *pdev)
 		nand_chip->ecc.calculate	= omap_calculate_ecc_bch;
 		nand_chip->ecc.read_page	= omap_read_page_bch;
 		nand_chip->ecc.write_page	= omap_write_page_bch;
+		mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
+		oobbytes_per_step		= nand_chip->ecc.bytes;
 
 		err = elm_config(info->elm_dev, BCH8_ECC,
 				 mtd->writesize / nand_chip->ecc.size,
@@ -1956,16 +2004,6 @@ static int omap_nand_probe(struct platform_device *pdev)
 		if (err < 0)
 			goto return_error;
 
-		/* define ECC layout */
-		ecclayout->eccbytes		= nand_chip->ecc.bytes *
-							(mtd->writesize /
-							nand_chip->ecc.size);
-		oob_index			= BADBLOCK_MARKER_LENGTH;
-		for (i = 0; i < ecclayout->eccbytes; i++, oob_index++)
-			ecclayout->eccpos[i]	= oob_index;
-		/* reserved marker already included in ecclayout->eccbytes */
-		ecclayout->oobfree->offset	=
-				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
 		break;
 
 	case OMAP_ECC_BCH16_CODE_HW:
@@ -1979,6 +2017,8 @@ static int omap_nand_probe(struct platform_device *pdev)
 		nand_chip->ecc.calculate	= omap_calculate_ecc_bch;
 		nand_chip->ecc.read_page	= omap_read_page_bch;
 		nand_chip->ecc.write_page	= omap_write_page_bch;
+		mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
+		oobbytes_per_step		= nand_chip->ecc.bytes;
 
 		err = elm_config(info->elm_dev, BCH16_ECC,
 				 mtd->writesize / nand_chip->ecc.size,
@@ -1986,16 +2026,6 @@ static int omap_nand_probe(struct platform_device *pdev)
 		if (err < 0)
 			goto return_error;
 
-		/* define ECC layout */
-		ecclayout->eccbytes		= nand_chip->ecc.bytes *
-							(mtd->writesize /
-							nand_chip->ecc.size);
-		oob_index			= BADBLOCK_MARKER_LENGTH;
-		for (i = 0; i < ecclayout->eccbytes; i++, oob_index++)
-			ecclayout->eccpos[i]	= oob_index;
-		/* reserved marker already included in ecclayout->eccbytes */
-		ecclayout->oobfree->offset	=
-				ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
 		break;
 	default:
 		dev_err(&info->pdev->dev, "invalid or unsupported ECC scheme\n");
@@ -2003,13 +2033,15 @@ static int omap_nand_probe(struct platform_device *pdev)
 		goto return_error;
 	}
 
-	/* all OOB bytes from oobfree->offset till end off OOB are free */
-	ecclayout->oobfree->length = mtd->oobsize - ecclayout->oobfree->offset;
 	/* check if NAND device's OOB is enough to store ECC signatures */
-	if (mtd->oobsize < (ecclayout->eccbytes + BADBLOCK_MARKER_LENGTH)) {
+	min_oobbytes = (oobbytes_per_step *
+			(mtd->writesize / nand_chip->ecc.size)) +
+		       (nand_chip->options & NAND_BUSWIDTH_16 ?
+			BADBLOCK_MARKER_LENGTH : 1);
+	if (mtd->oobsize < min_oobbytes) {
 		dev_err(&info->pdev->dev,
 			"not enough OOB bytes required = %d, available=%d\n",
-			ecclayout->eccbytes, mtd->oobsize);
+			min_oobbytes, mtd->oobsize);
 		err = -EINVAL;
 		goto return_error;
 	}
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:53 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:53 +0100
Subject: [PATCH v3 45/52] mtd: nand: sh_flctl: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-46-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/sh_flctl.c | 87 ++++++++++++++++++++++++++++++++++-----------
 1 file changed, 67 insertions(+), 20 deletions(-)

diff --git a/drivers/mtd/nand/sh_flctl.c b/drivers/mtd/nand/sh_flctl.c
index 4814402..fa46610 100644
--- a/drivers/mtd/nand/sh_flctl.c
+++ b/drivers/mtd/nand/sh_flctl.c
@@ -43,26 +43,73 @@
 #include <linux/mtd/partitions.h>
 #include <linux/mtd/sh_flctl.h>
 
-static struct nand_ecclayout flctl_4secc_oob_16 = {
-	.eccbytes = 10,
-	.eccpos = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9},
-	.oobfree = {
-		{.offset = 12,
-		. length = 4} },
+static int flctl_4secc_ooblayout_sp_ecc(struct mtd_info *mtd, int section,
+					struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 0;
+	oobregion->length = chip->ecc.bytes;
+
+	return 0;
+}
+
+static int flctl_4secc_ooblayout_sp_free(struct mtd_info *mtd, int section,
+					 struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 12;
+	oobregion->length = 4;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops flctl_4secc_oob_smallpage_ops = {
+	.ecc = flctl_4secc_ooblayout_sp_ecc,
+	.free = flctl_4secc_ooblayout_sp_free,
 };
 
-static struct nand_ecclayout flctl_4secc_oob_64 = {
-	.eccbytes = 4 * 10,
-	.eccpos = {
-		 6,  7,  8,  9, 10, 11, 12, 13, 14, 15,
-		22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
-		38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
-		54, 55, 56, 57, 58, 59, 60, 61, 62, 63 },
-	.oobfree = {
-		{.offset =  2, .length = 4},
-		{.offset = 16, .length = 6},
-		{.offset = 32, .length = 6},
-		{.offset = 48, .length = 6} },
+static int flctl_4secc_ooblayout_lp_ecc(struct mtd_info *mtd, int section,
+					struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 6;
+	oobregion->length = chip->ecc.bytes;
+
+	return 0;
+}
+
+static int flctl_4secc_ooblayout_lp_free(struct mtd_info *mtd, int section,
+					 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section >= chip->ecc.steps)
+		return -ERANGE;
+
+	oobregion->offset = section * 16;
+	oobregion->length = 6;
+
+	if (!section) {
+		oobregion->offset += 2;
+		oobregion->length -= 2;
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops flctl_4secc_oob_largepage_ops = {
+	.ecc = flctl_4secc_ooblayout_lp_ecc,
+	.free = flctl_4secc_ooblayout_lp_free,
 };
 
 static uint8_t scan_ff_pattern[] = { 0xff, 0xff };
@@ -987,10 +1034,10 @@ static int flctl_chip_init_tail(struct mtd_info *mtd)
 
 	if (flctl->hwecc) {
 		if (mtd->writesize == 512) {
-			chip->ecc.layout = &flctl_4secc_oob_16;
+			mtd_set_ooblayout(mtd, &flctl_4secc_oob_smallpage_ops);
 			chip->badblock_pattern = &flctl_4secc_smallpage;
 		} else {
-			chip->ecc.layout = &flctl_4secc_oob_64;
+			mtd_set_ooblayout(mtd, &flctl_4secc_oob_largepage_ops);
 			chip->badblock_pattern = &flctl_4secc_largepage;
 		}
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:52 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:52 +0100
Subject: [PATCH v3 44/52] mtd: nand: s3c2410: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-45-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/s3c2410.c | 32 +++++++++++++++++++++++++++-----
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
index 9c9397b..700c097 100644
--- a/drivers/mtd/nand/s3c2410.c
+++ b/drivers/mtd/nand/s3c2410.c
@@ -84,11 +84,33 @@
 
 /* new oob placement block for use with hardware ecc generation
  */
+static int s3c2410_ooblayout_ecc(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 0;
+	oobregion->length = 3;
+
+	return 0;
+}
+
+static int s3c2410_ooblayout_free(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = 8;
+	oobregion->length = 8;
+
+	return 0;
+}
 
-static struct nand_ecclayout nand_hw_eccoob = {
-	.eccbytes = 3,
-	.eccpos = {0, 1, 2},
-	.oobfree = {{8, 8}}
+static const struct mtd_ooblayout_ops s3c2410_ooblayout_ops = {
+	.ecc = s3c2410_ooblayout_ecc,
+	.free = s3c2410_ooblayout_free,
 };
 
 /* controller and mtd information */
@@ -919,7 +941,7 @@ static void s3c2410_nand_update_chip(struct s3c2410_nand_info *info,
 	} else {
 		chip->ecc.size	    = 512;
 		chip->ecc.bytes	    = 3;
-		chip->ecc.layout    = &nand_hw_eccoob;
+		mtd_set_ooblayout(nand_to_mtd(chip), &s3c2410_ooblayout_ops);
 	}
 }
 
-- 
2.1.4



From linux at arm.linux.org.uk  Thu Feb 25 17:06:58 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Feb 2016 01:06:58 +0000
Subject: [PATCH] dmaengine: omap-dma: Do not call omap_dma_callback()
 from tx_status()
In-Reply-To: <1456388939-15722-1-git-send-email-peter.ujfalusi@ti.com>
References: <1456388939-15722-1-git-send-email-peter.ujfalusi@ti.com>
Message-ID: <20160226010658.GN5783@n2100.arm.linux.org.uk>

On Thu, Feb 25, 2016 at 10:28:59AM +0200, Peter Ujfalusi wrote:
> When based on the CCR_ENABLE bit the channel is stopped we should not call
> omap_dma_callback(), only change the return value to DMA_COMPLETE. Client
> drivers will do the right thing to clean up the channel after the transfer
> has been completed.
> Check the CCR_ENABLE only if the channel is not paused since pause in sDMA
> means that the channel is stopped.
> This will fix one hard to reproduce race condition when the channel is
> terminated during transfer (affecting cyclic operation).
> 
> Fixes: 1a7cf7b26f25 ("dmaengine: omap-dma: Handle cases when the channel is polled for completion")
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> ---
>  drivers/dma/omap-dma.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> index f6bef0d93998..a6b189fdbbe6 100644
> --- a/drivers/dma/omap-dma.c
> +++ b/drivers/dma/omap-dma.c
> @@ -671,18 +671,22 @@ static enum dma_status omap_dma_tx_status(struct dma_chan *chan,
>  	struct omap_chan *c = to_omap_dma_chan(chan);
>  	struct virt_dma_desc *vd;
>  	enum dma_status ret;
> -	uint32_t ccr;
>  	unsigned long flags;
>  
> -	ccr = omap_dma_chan_read(c, CCR);
> -	/* The channel is no longer active, handle the completion right away */
> -	if (!(ccr & CCR_ENABLE))
> -		omap_dma_callback(c->dma_ch, 0, c);
> -
>  	ret = dma_cookie_status(chan, cookie, txstate);
>  	if (ret == DMA_COMPLETE || !txstate)
>  		return ret;
>  
> +	if (!c->paused) {
> +		uint32_t ccr = omap_dma_chan_read(c, CCR);
> +		/*
> +		 * The channel is no longer active, set the return value
> +		 * accordingly
> +		 */
> +		if (!(ccr & CCR_ENABLE))
> +			ret = DMA_COMPLETE;
> +	}
> +

This looks very much like a hack, and surely opens a race condition
up: what happens when a request submitted and pending but not yet
started?  If the channel is idle, requesting status will report
that the request has completed.

It's also wrong for another reason.  If txstate is NULL...

Your original commit adding the original hack that you're now removing
above says that this is to support polled operation: I'm not aware of
DMA engine supporting such a mode.  DMA_PREP_INTERRUPT is a mechanism
where requests can be queued without an interrupt to allow batching.
See the raid5/async_tx code, which queues a set of operations without
DMA_PREP_INTERRUPT, with the final operation with DMA_PREP_INTERRUPT
set.

As the driver is reliant on interrupts to move to the next transfer,
the patch which causes DMA_PREP_INTERRUPT to influence whether
interrupts are sent is actually buggy, and will prevent several
queued DMA operations to fail.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:54 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:54 +0100
Subject: [PATCH v3 46/52] mtd: nand: sm_common: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-47-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/sm_common.c | 93 ++++++++++++++++++++++++++++++++++++--------
 1 file changed, 77 insertions(+), 16 deletions(-)

diff --git a/drivers/mtd/nand/sm_common.c b/drivers/mtd/nand/sm_common.c
index c514740..5939dff 100644
--- a/drivers/mtd/nand/sm_common.c
+++ b/drivers/mtd/nand/sm_common.c
@@ -12,14 +12,47 @@
 #include <linux/sizes.h>
 #include "sm_common.h"
 
-static struct nand_ecclayout nand_oob_sm = {
-	.eccbytes = 6,
-	.eccpos = {8, 9, 10, 13, 14, 15},
-	.oobfree = {
-		{.offset = 0 , .length = 4}, /* reserved */
-		{.offset = 6 , .length = 2}, /* LBA1 */
-		{.offset = 11, .length = 2}  /* LBA2 */
+static int oob_sm_ooblayout_ecc(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	if (section > 1)
+		return -ERANGE;
+
+	oobregion->length = 3;
+	oobregion->offset = ((section + 1) * 8) - 3;
+
+	return 0;
+}
+
+static int oob_sm_ooblayout_free(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	switch (section) {
+	case 0:
+		/* reserved */
+		oobregion->offset = 0;
+		oobregion->length = 4;
+		break;
+	case 1:
+		/* LBA1 */
+		oobregion->offset = 6;
+		oobregion->length = 2;
+		break;
+	case 2:
+		/* LBA2 */
+		oobregion->offset = 11;
+		oobregion->length = 2;
+		break;
+	default:
+		return -ERANGE;
 	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops oob_sm_ops = {
+	.ecc = oob_sm_ooblayout_ecc,
+	.free = oob_sm_ooblayout_free,
 };
 
 /* NOTE: This layout is is not compatabable with SmartMedia, */
@@ -28,15 +61,43 @@ static struct nand_ecclayout nand_oob_sm = {
 /* If you use smftl, it will bypass this and work correctly */
 /* If you not, then you break SmartMedia compliance anyway */
 
-static struct nand_ecclayout nand_oob_sm_small = {
-	.eccbytes = 3,
-	.eccpos = {0, 1, 2},
-	.oobfree = {
-		{.offset = 3 , .length = 2}, /* reserved */
-		{.offset = 6 , .length = 2}, /* LBA1 */
+static int oob_sm_small_ooblayout_ecc(struct mtd_info *mtd, int section,
+				      struct mtd_oob_region *oobregion)
+{
+	if (section)
+		return -ERANGE;
+
+	oobregion->length = 3;
+	oobregion->offset = 0;
+
+	return 0;
+}
+
+static int oob_sm_small_ooblayout_free(struct mtd_info *mtd, int section,
+				       struct mtd_oob_region *oobregion)
+{
+	switch (section) {
+	case 0:
+		/* reserved */
+		oobregion->offset = 3;
+		oobregion->length = 2;
+		break;
+	case 1:
+		/* LBA1 */
+		oobregion->offset = 6;
+		oobregion->length = 2;
+		break;
+	default:
+		return -ERANGE;
 	}
-};
 
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops oob_sm_small_ops = {
+	.ecc = oob_sm_small_ooblayout_ecc,
+	.free = oob_sm_small_ooblayout_free,
+};
 
 static int sm_block_markbad(struct mtd_info *mtd, loff_t ofs)
 {
@@ -121,9 +182,9 @@ int sm_register_device(struct mtd_info *mtd, int smartmedia)
 
 	/* ECC layout */
 	if (mtd->writesize == SM_SECTOR_SIZE)
-		chip->ecc.layout = &nand_oob_sm;
+		mtd_set_ooblayout(mtd, &oob_sm_ops);
 	else if (mtd->writesize == SM_SMALL_PAGE)
-		chip->ecc.layout = &nand_oob_sm_small;
+		mtd_set_ooblayout(mtd, &oob_sm_small_ops);
 	else
 		return -ENODEV;
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:55 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:55 +0100
Subject: [PATCH v3 47/52] mtd: nand: sunxi: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-48-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/sunxi_nand.c | 114 +++++++++++++++++++-----------------------
 1 file changed, 52 insertions(+), 62 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index b5ea6b3..24cce87 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -212,12 +212,9 @@ struct sunxi_nand_chip_sel {
  * sunxi HW ECC infos: stores information related to HW ECC support
  *
  * @mode:	the sunxi ECC mode field deduced from ECC requirements
- * @layout:	the OOB layout depending on the ECC requirements and the
- *		selected ECC mode
  */
 struct sunxi_nand_hw_ecc {
 	int mode;
-	struct nand_ecclayout layout;
 };
 
 /*
@@ -1257,6 +1254,57 @@ static int sunxi_nand_chip_init_timings(struct sunxi_nand_chip *chip,
 	return sunxi_nand_chip_set_timings(chip, timings);
 }
 
+static int sunxi_nand_ooblayout_ecc(struct mtd_info *mtd, int section,
+				    struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand = mtd_to_nand(mtd);
+	struct nand_ecc_ctrl *ecc = &nand->ecc;
+
+	if (section >= ecc->steps)
+		return -ERANGE;
+
+	oobregion->offset = section * (ecc->bytes + 4) + 4;
+	oobregion->length = ecc->bytes;
+
+	return 0;
+}
+
+static int sunxi_nand_ooblayout_free(struct mtd_info *mtd, int section,
+				     struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *nand = mtd_to_nand(mtd);
+	struct nand_ecc_ctrl *ecc = &nand->ecc;
+
+	if (section > ecc->steps)
+		return -ERANGE;
+
+	/*
+	 * The first 2 bytes are used for BB markers, hence we
+	 * only have 2 bytes available in the first user data
+	 * section.
+	 */
+	if (!section && ecc->mode == NAND_ECC_HW) {
+		oobregion->offset = 2;
+		oobregion->length = 2;
+
+		return 0;
+	}
+
+	oobregion->offset = section * (ecc->bytes + 4);
+
+	if (section < ecc->steps)
+		oobregion->length = 4;
+	else
+		oobregion->offset = mtd->oobsize - oobregion->offset;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops sunxi_nand_ooblayout_ops = {
+	.ecc = sunxi_nand_ooblayout_ecc,
+	.free = sunxi_nand_ooblayout_free,
+};
+
 static int sunxi_nand_hw_common_ecc_ctrl_init(struct mtd_info *mtd,
 					      struct nand_ecc_ctrl *ecc,
 					      struct device_node *np)
@@ -1266,7 +1314,6 @@ static int sunxi_nand_hw_common_ecc_ctrl_init(struct mtd_info *mtd,
 	struct sunxi_nand_chip *sunxi_nand = to_sunxi_nand(nand);
 	struct sunxi_nfc *nfc = to_sunxi_nfc(sunxi_nand->nand.controller);
 	struct sunxi_nand_hw_ecc *data;
-	struct nand_ecclayout *layout;
 	int nsectors;
 	int ret;
 	int i;
@@ -1295,7 +1342,6 @@ static int sunxi_nand_hw_common_ecc_ctrl_init(struct mtd_info *mtd,
 	/* HW ECC always work with even numbers of ECC bytes */
 	ecc->bytes = ALIGN(ecc->bytes, 2);
 
-	layout = &data->layout;
 	nsectors = mtd->writesize / ecc->size;
 
 	if (mtd->oobsize < ((ecc->bytes + 4) * nsectors)) {
@@ -1303,9 +1349,7 @@ static int sunxi_nand_hw_common_ecc_ctrl_init(struct mtd_info *mtd,
 		goto err;
 	}
 
-	layout->eccbytes = (ecc->bytes * nsectors);
-
-	ecc->layout = layout;
+	mtd_set_ooblayout(mtd, &sunxi_nand_ooblayout_ops);
 	ecc->priv = data;
 
 	return 0;
@@ -1325,9 +1369,6 @@ static int sunxi_nand_hw_ecc_ctrl_init(struct mtd_info *mtd,
 				       struct nand_ecc_ctrl *ecc,
 				       struct device_node *np)
 {
-	struct nand_ecclayout *layout;
-	int nsectors;
-	int i, j;
 	int ret;
 
 	ret = sunxi_nand_hw_common_ecc_ctrl_init(mtd, ecc, np);
@@ -1336,40 +1377,6 @@ static int sunxi_nand_hw_ecc_ctrl_init(struct mtd_info *mtd,
 
 	ecc->read_page = sunxi_nfc_hw_ecc_read_page;
 	ecc->write_page = sunxi_nfc_hw_ecc_write_page;
-	layout = ecc->layout;
-	nsectors = mtd->writesize / ecc->size;
-
-	for (i = 0; i < nsectors; i++) {
-		if (i) {
-			layout->oobfree[i].offset =
-				layout->oobfree[i - 1].offset +
-				layout->oobfree[i - 1].length +
-				ecc->bytes;
-			layout->oobfree[i].length = 4;
-		} else {
-			/*
-			 * The first 2 bytes are used for BB markers, hence we
-			 * only have 2 bytes available in the first user data
-			 * section.
-			 */
-			layout->oobfree[i].length = 2;
-			layout->oobfree[i].offset = 2;
-		}
-
-		for (j = 0; j < ecc->bytes; j++)
-			layout->eccpos[(ecc->bytes * i) + j] =
-					layout->oobfree[i].offset +
-					layout->oobfree[i].length + j;
-	}
-
-	if (mtd->oobsize > (ecc->bytes + 4) * nsectors) {
-		layout->oobfree[nsectors].offset =
-				layout->oobfree[nsectors - 1].offset +
-				layout->oobfree[nsectors - 1].length +
-				ecc->bytes;
-		layout->oobfree[nsectors].length = mtd->oobsize -
-				((ecc->bytes + 4) * nsectors);
-	}
 
 	return 0;
 }
@@ -1378,9 +1385,6 @@ static int sunxi_nand_hw_syndrome_ecc_ctrl_init(struct mtd_info *mtd,
 						struct nand_ecc_ctrl *ecc,
 						struct device_node *np)
 {
-	struct nand_ecclayout *layout;
-	int nsectors;
-	int i;
 	int ret;
 
 	ret = sunxi_nand_hw_common_ecc_ctrl_init(mtd, ecc, np);
@@ -1391,15 +1395,6 @@ static int sunxi_nand_hw_syndrome_ecc_ctrl_init(struct mtd_info *mtd,
 	ecc->read_page = sunxi_nfc_hw_syndrome_ecc_read_page;
 	ecc->write_page = sunxi_nfc_hw_syndrome_ecc_write_page;
 
-	layout = ecc->layout;
-	nsectors = mtd->writesize / ecc->size;
-
-	for (i = 0; i < (ecc->bytes * nsectors); i++)
-		layout->eccpos[i] = i;
-
-	layout->oobfree[0].length = mtd->oobsize - i;
-	layout->oobfree[0].offset = i;
-
 	return 0;
 }
 
@@ -1411,7 +1406,6 @@ static void sunxi_nand_ecc_cleanup(struct nand_ecc_ctrl *ecc)
 		sunxi_nand_hw_common_ecc_ctrl_cleanup(ecc);
 		break;
 	case NAND_ECC_NONE:
-		kfree(ecc->layout);
 	default:
 		break;
 	}
@@ -1445,10 +1439,6 @@ static int sunxi_nand_ecc_init(struct mtd_info *mtd, struct nand_ecc_ctrl *ecc,
 			return ret;
 		break;
 	case NAND_ECC_NONE:
-		ecc->layout = kzalloc(sizeof(*ecc->layout), GFP_KERNEL);
-		if (!ecc->layout)
-			return -ENOMEM;
-		ecc->layout->oobfree[0].length = mtd->oobsize;
 	case NAND_ECC_SOFT:
 		break;
 	default:
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:56 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:56 +0100
Subject: [PATCH v3 48/52] mtd: nand: vf610: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-49-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/vf610_nfc.c | 34 ++++------------------------------
 1 file changed, 4 insertions(+), 30 deletions(-)

diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index 293feb1..da34de1 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -175,34 +175,6 @@ static inline struct vf610_nfc *mtd_to_nfc(struct mtd_info *mtd)
 	return container_of(mtd_to_nand(mtd), struct vf610_nfc, chip);
 }
 
-static struct nand_ecclayout vf610_nfc_ecc45 = {
-	.eccbytes = 45,
-	.eccpos = {19, 20, 21, 22, 23,
-		   24, 25, 26, 27, 28, 29, 30, 31,
-		   32, 33, 34, 35, 36, 37, 38, 39,
-		   40, 41, 42, 43, 44, 45, 46, 47,
-		   48, 49, 50, 51, 52, 53, 54, 55,
-		   56, 57, 58, 59, 60, 61, 62, 63},
-	.oobfree = {
-		{.offset = 2,
-		 .length = 17} }
-};
-
-static struct nand_ecclayout vf610_nfc_ecc60 = {
-	.eccbytes = 60,
-	.eccpos = { 4,  5,  6,  7,  8,  9, 10, 11,
-		   12, 13, 14, 15, 16, 17, 18, 19,
-		   20, 21, 22, 23, 24, 25, 26, 27,
-		   28, 29, 30, 31, 32, 33, 34, 35,
-		   36, 37, 38, 39, 40, 41, 42, 43,
-		   44, 45, 46, 47, 48, 49, 50, 51,
-		   52, 53, 54, 55, 56, 57, 58, 59,
-		   60, 61, 62, 63 },
-	.oobfree = {
-		{.offset = 2,
-		 .length = 2} }
-};
-
 static inline u32 vf610_nfc_read(struct vf610_nfc *nfc, uint reg)
 {
 	return readl(nfc->regs + reg);
@@ -781,14 +753,16 @@ static int vf610_nfc_probe(struct platform_device *pdev)
 		if (mtd->oobsize > 64)
 			mtd->oobsize = 64;
 
+		/*
+		 * mtd->ecclayout is not specified here because we're using the
+		 * default large page ECC layout defined in NAND core.
+		 */
 		if (chip->ecc.strength == 32) {
 			nfc->ecc_mode = ECC_60_BYTE;
 			chip->ecc.bytes = 60;
-			chip->ecc.layout = &vf610_nfc_ecc60;
 		} else if (chip->ecc.strength == 24) {
 			nfc->ecc_mode = ECC_45_BYTE;
 			chip->ecc.bytes = 45;
-			chip->ecc.layout = &vf610_nfc_ecc45;
 		} else {
 			dev_err(nfc->dev, "Unsupported ECC strength\n");
 			err = -ENXIO;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:57 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:57 +0100
Subject: [PATCH v3 49/52] mtd: onenand: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-50-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users. Modify the onenand drivers to switch to this
approach.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/onenand/onenand_base.c | 162 ++++++++++++++++++++++---------------
 include/linux/mtd/onenand.h        |   2 -
 2 files changed, 97 insertions(+), 67 deletions(-)

diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index d0fa505..a4b029a 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -68,21 +68,33 @@ MODULE_PARM_DESC(otp,	"Corresponding behaviour of OneNAND in OTP"
  * flexonenand_oob_128 - oob info for Flex-Onenand with 4KB page
  * For now, we expose only 64 out of 80 ecc bytes
  */
-static struct nand_ecclayout flexonenand_oob_128 = {
-	.eccbytes	= 64,
-	.eccpos		= {
-		6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
-		22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
-		38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
-		54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
-		70, 71, 72, 73, 74, 75, 76, 77, 78, 79,
-		86, 87, 88, 89, 90, 91, 92, 93, 94, 95,
-		102, 103, 104, 105
-		},
-	.oobfree	= {
-		{2, 4}, {18, 4}, {34, 4}, {50, 4},
-		{66, 4}, {82, 4}, {98, 4}, {114, 4}
-	}
+static int flexonenand_ooblayout_ecc(struct mtd_info *mtd, int section,
+				     struct mtd_oob_region *oobregion)
+{
+	if (section > 7)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 6;
+	oobregion->length = 10;
+
+	return 0;
+}
+
+static int flexonenand_ooblayout_free(struct mtd_info *mtd, int section,
+				      struct mtd_oob_region *oobregion)
+{
+	if (section > 7)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 2;
+	oobregion->length = 4;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops flexonenand_ooblayout_ops = {
+	.ecc = flexonenand_ooblayout_ecc,
+	.free = flexonenand_ooblayout_free,
 };
 
 /*
@@ -91,56 +103,77 @@ static struct nand_ecclayout flexonenand_oob_128 = {
  * Based on specification:
  * 4Gb M-die OneNAND Flash (KFM4G16Q4M, KFN8G16Q4M). Rev. 1.3, Apr. 2010
  *
- * For eccpos we expose only 64 bytes out of 72 (see struct nand_ecclayout)
- *
- * oobfree uses the spare area fields marked as
- * "Managed by internal ECC logic for Logical Sector Number area"
- */
-static struct nand_ecclayout onenand_oob_128 = {
-	.eccbytes	= 64,
-	.eccpos		= {
-		7, 8, 9, 10, 11, 12, 13, 14, 15,
-		23, 24, 25, 26, 27, 28, 29, 30, 31,
-		39, 40, 41, 42, 43, 44, 45, 46, 47,
-		55, 56, 57, 58, 59, 60, 61, 62, 63,
-		71, 72, 73, 74, 75, 76, 77, 78, 79,
-		87, 88, 89, 90, 91, 92, 93, 94, 95,
-		103, 104, 105, 106, 107, 108, 109, 110, 111,
-		119
-	},
-	.oobfree	= {
-		{2, 3}, {18, 3}, {34, 3}, {50, 3},
-		{66, 3}, {82, 3}, {98, 3}, {114, 3}
-	}
+ */
+static int onenand_ooblayout_128_ecc(struct mtd_info *mtd, int section,
+				     struct mtd_oob_region *oobregion)
+{
+	if (section > 7)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 7;
+	oobregion->length = 9;
+
+	return 0;
+}
+
+static int onenand_ooblayout_128_free(struct mtd_info *mtd, int section,
+				      struct mtd_oob_region *oobregion)
+{
+	if (section >= 8)
+		return -ERANGE;
+
+	/*
+	 * free bytes are using the spare area fields marked as
+	 * "Managed by internal ECC logic for Logical Sector Number area"
+	 */
+	oobregion->offset = (section * 16) + 2;
+	oobregion->length = 3;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops onenand_oob_128_ooblayout_ops = {
+	.ecc = onenand_ooblayout_128_ecc,
+	.free = onenand_ooblayout_128_free,
 };
 
 /**
- * onenand_oob_64 - oob info for large (2KB) page
+ * onenand_oob_32_64 - oob info for large (2KB) page
  */
-static struct nand_ecclayout onenand_oob_64 = {
-	.eccbytes	= 20,
-	.eccpos		= {
-		8, 9, 10, 11, 12,
-		24, 25, 26, 27, 28,
-		40, 41, 42, 43, 44,
-		56, 57, 58, 59, 60,
-		},
-	.oobfree	= {
-		{2, 3}, {14, 2}, {18, 3}, {30, 2},
-		{34, 3}, {46, 2}, {50, 3}, {62, 2}
+static int onenand_ooblayout_32_64_ecc(struct mtd_info *mtd, int section,
+				       struct mtd_oob_region *oobregion)
+{
+	if (section > 3)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 8;
+	oobregion->length = 5;
+
+	return 0;
+}
+
+static int onenand_ooblayout_32_64_free(struct mtd_info *mtd, int section,
+					struct mtd_oob_region *oobregion)
+{
+	int sections = (mtd->oobsize / 32) * 2;
+
+	if (section >= sections)
+		return -ERANGE;
+
+	if (section & 1) {
+		oobregion->offset = ((section - 1) * 16) + 14;
+		oobregion->length = 2;
+	} else  {
+		oobregion->offset = (section * 16) + 2;
+		oobregion->length = 3;
 	}
-};
 
-/**
- * onenand_oob_32 - oob info for middle (1KB) page
- */
-static struct nand_ecclayout onenand_oob_32 = {
-	.eccbytes	= 10,
-	.eccpos		= {
-		8, 9, 10, 11, 12,
-		24, 25, 26, 27, 28,
-		},
-	.oobfree	= { {2, 3}, {14, 2}, {18, 3}, {30, 2} }
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops onenand_oob_32_64_ooblayout_ops = {
+	.ecc = onenand_ooblayout_32_64_ecc,
+	.free = onenand_ooblayout_32_64_free,
 };
 
 static const unsigned char ffchars[] = {
@@ -3957,22 +3990,22 @@ int onenand_scan(struct mtd_info *mtd, int maxchips)
 	switch (mtd->oobsize) {
 	case 128:
 		if (FLEXONENAND(this)) {
-			this->ecclayout = &flexonenand_oob_128;
+			mtd_set_ooblayout(mtd, &flexonenand_ooblayout_ops);
 			mtd->subpage_sft = 0;
 		} else {
-			this->ecclayout = &onenand_oob_128;
+			mtd_set_ooblayout(mtd, &onenand_oob_128_ooblayout_ops);
 			mtd->subpage_sft = 2;
 		}
 		if (ONENAND_IS_NOP_1(this))
 			mtd->subpage_sft = 0;
 		break;
 	case 64:
-		this->ecclayout = &onenand_oob_64;
+		mtd_set_ooblayout(mtd, &onenand_oob_32_64_ooblayout_ops);
 		mtd->subpage_sft = 2;
 		break;
 
 	case 32:
-		this->ecclayout = &onenand_oob_32;
+		mtd_set_ooblayout(mtd, &onenand_oob_32_64_ooblayout_ops);
 		mtd->subpage_sft = 1;
 		break;
 
@@ -3981,7 +4014,7 @@ int onenand_scan(struct mtd_info *mtd, int maxchips)
 			__func__, mtd->oobsize);
 		mtd->subpage_sft = 0;
 		/* To prevent kernel oops */
-		this->ecclayout = &onenand_oob_32;
+		mtd_set_ooblayout(mtd, &onenand_oob_32_64_ooblayout_ops);
 		break;
 	}
 
@@ -3997,7 +4030,6 @@ int onenand_scan(struct mtd_info *mtd, int maxchips)
 
 	mtd->oobavail = ret;
 
-	mtd_set_ecclayout(mtd, this->ecclayout);
 	mtd->ecc_strength = 1;
 
 	/* Fill in remaining MTD driver data */
diff --git a/include/linux/mtd/onenand.h b/include/linux/mtd/onenand.h
index 4596503..0aaa98b 100644
--- a/include/linux/mtd/onenand.h
+++ b/include/linux/mtd/onenand.h
@@ -80,7 +80,6 @@ struct onenand_bufferram {
  * @page_buf:		[INTERN] page main data buffer
  * @oob_buf:		[INTERN] page oob data buffer
  * @subpagesize:	[INTERN] holds the subpagesize
- * @ecclayout:		[REPLACEABLE] the default ecc placement scheme
  * @bbm:		[REPLACEABLE] pointer to Bad Block Management
  * @priv:		[OPTIONAL] pointer to private chip date
  */
@@ -134,7 +133,6 @@ struct onenand_chip {
 #endif
 
 	int			subpagesize;
-	struct nand_ecclayout	*ecclayout;
 
 	void			*bbm;
 
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:58 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:58 +0100
Subject: [PATCH v3 50/52] staging: mt29f_spinand: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-51-git-send-email-boris.brezillon@free-electrons.com>

Replace the nand_ecclayout definition by the equivalent mtd_ooblayout_ops
definition.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/staging/mt29f_spinand/mt29f_spinand.c | 48 +++++++++++++++++----------
 1 file changed, 30 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c b/drivers/staging/mt29f_spinand/mt29f_spinand.c
index 6728376..b9f9347 100644
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -42,23 +42,33 @@ static inline struct spinand_state *mtd_to_state(struct mtd_info *mtd)
 static int enable_hw_ecc;
 static int enable_read_hw_ecc;
 
-static struct nand_ecclayout spinand_oob_64 = {
-	.eccbytes = 24,
-	.eccpos = {
-		1, 2, 3, 4, 5, 6,
-		17, 18, 19, 20, 21, 22,
-		33, 34, 35, 36, 37, 38,
-		49, 50, 51, 52, 53, 54, },
-	.oobfree = {
-		{.offset = 8,
-			.length = 8},
-		{.offset = 24,
-			.length = 8},
-		{.offset = 40,
-			.length = 8},
-		{.offset = 56,
-			.length = 8},
-	}
+static int spinand_ooblayout_64_ecc(struct mtd_info *mtd, int section,
+				    struct mtd_oob_region *oobregion)
+{
+	if (section > 3)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 1;
+	oobregion->length = 6;
+
+	return 0;
+}
+
+static int spinand_ooblayout_64_free(struct mtd_info *mtd, int section,
+				     struct mtd_oob_region *oobregion)
+{
+	if (section > 3)
+		return -ERANGE;
+
+	oobregion->offset = (section * 16) + 8;
+	oobregion->length = 8;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops spinand_oob_64_ops = {
+	.ecc = spinand_ooblayout_64_ecc,
+	.free = spinand_ooblayout_64_free,
 };
 #endif
 
@@ -883,7 +893,6 @@ static int spinand_probe(struct spi_device *spi_nand)
 
 	chip->ecc.strength = 1;
 	chip->ecc.total	= chip->ecc.steps * chip->ecc.bytes;
-	chip->ecc.layout = &spinand_oob_64;
 	chip->ecc.read_page = spinand_read_page_hwecc;
 	chip->ecc.write_page = spinand_write_page_hwecc;
 #else
@@ -908,6 +917,9 @@ static int spinand_probe(struct spi_device *spi_nand)
 
 	mtd->dev.parent = &spi_nand->dev;
 	mtd->oobsize = 64;
+#ifdef CONFIG_MTD_SPINAND_ONDIEECC
+	mtd_set_ooblayout(mtd, &spinand_oob_64_ops);
+#endif
 
 	if (nand_scan(mtd, 1))
 		return -ENXIO;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:59 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:59 +0100
Subject: [PATCH v3 51/52] mtd: nand: kill the ecc->layout field
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-52-git-send-email-boris.brezillon@free-electrons.com>

Now that all NAND drivers have switch to mtd_ooblayout_ops, we can kill
the ecc->layout field.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/nand_base.c | 7 -------
 drivers/mtd/nand/nand_bch.c  | 9 ---------
 include/linux/mtd/nand.h     | 2 --
 3 files changed, 18 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 71d5948..32a0f9e 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -4162,13 +4162,6 @@ int nand_scan_tail(struct mtd_info *mtd)
 	chip->oob_poi = chip->buffers->databuf + mtd->writesize;
 
 	/*
-	 * Set the provided ECC layout. If ecc->layout is NULL, the MTD core
-	 * will just leave mtd->ooblayout to NULL, if it's not NULL, it will
-	 * set ->ooblayout to the default ecclayout wrapper.
-	 */
-	mtd_set_ecclayout(mtd, ecc->layout);
-
-	/*
 	 * If no default placement scheme is given, select an appropriate one.
 	 */
 	if (!mtd->ooblayout && (ecc->mode != NAND_ECC_SOFT_BCH)) {
diff --git a/drivers/mtd/nand/nand_bch.c b/drivers/mtd/nand/nand_bch.c
index e29e75f..ca9b2a4 100644
--- a/drivers/mtd/nand/nand_bch.c
+++ b/drivers/mtd/nand/nand_bch.c
@@ -158,15 +158,6 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
 
 	eccsteps = mtd->writesize/eccsize;
 
-	/*
-	 * Rely on the default ecclayout to ooblayout wrapper provided by MTD
-	 * core if ecc.layout is not NULL.
-	 * FIXME: this should be removed when all callers have moved to the
-	 * mtd_ooblayout_ops approach.
-	 */
-	if (nand->ecc.layout)
-		mtd_set_ecclayout(mtd, nand->ecc.layout);
-
 	/* if no ecc placement scheme was provided, build one */
 	if (!mtd->ooblayout) {
 
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 82a005a..fdcc2b8 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -466,7 +466,6 @@ struct nand_hw_control {
  * @prepad:	padding information for syndrome based ECC generators
  * @postpad:	padding information for syndrome based ECC generators
  * @options:	ECC specific options (see NAND_ECC_XXX flags defined above)
- * @layout:	ECC layout control struct pointer
  * @priv:	pointer to private ECC control data
  * @hwctl:	function to control hardware ECC generator. Must only
  *		be provided if an hardware ECC is available
@@ -516,7 +515,6 @@ struct nand_ecc_ctrl {
 	int prepad;
 	int postpad;
 	unsigned int options;
-	struct nand_ecclayout	*layout;
 	void *priv;
 	void (*hwctl)(struct mtd_info *mtd, int mode);
 	int (*calculate)(struct mtd_info *mtd, const uint8_t *dat,
-- 
2.1.4



From heiko at sntech.de  Thu Feb 25 17:12:33 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 26 Feb 2016 02:12:33 +0100
Subject: [RESEND PATCH 1/8] clk: rockchip: add id of the tsadc clock found
 on rk3228 SoCs
In-Reply-To: <1455521613-27340-2-git-send-email-wxt@rock-chips.com>
References: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
 <1455521613-27340-2-git-send-email-wxt@rock-chips.com>
Message-ID: <2572098.0f5Ay4XA4n@phil>

Am Montag, 15. Februar 2016, 15:33:26 schrieb Caesar Wang:
> This patch adds 'SCLK_TSADC' and 'PCLK_TSADC' id found on rk3228 SoCs.
> That will be needed by TSADC controller.
> 
> Signed-off-by: Caesar Wang <wxt at rock-chips.com>

applied to my clk-branch with Mike's Ack


Thanks
Heiko


From heiko at sntech.de  Thu Feb 25 17:16:58 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 26 Feb 2016 02:16:58 +0100
Subject: [RESEND PATCH 0/8] Support and fixes the rk3228 SoCS for thermal
In-Reply-To: <3650760.H1YezDtoUE@phil>
References: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
 <3650760.H1YezDtoUE@phil>
Message-ID: <3480898.qXLEaXSdDG@phil>

Am Dienstag, 16. Februar 2016, 00:25:39 schrieb Heiko Stuebner:
> Am Montag, 15. Februar 2016, 15:33:25 schrieb Caesar Wang:
> > 1a6f334 clk: rockchip: add id of the tsadc clock found on rk3228 SoCs
> > 8cf2d1b clk: rockchip: add the tsadc clocks found on rk3228 SoCs
> > bdc79c0 ARM: dts: rockchip: add the thermal main info found on rk3228
> > 22ea3c3 ARM: dts: rockchip: enable the tsadc for rk3228 evb
> 
> clk and devicetree patches look good and I'll pick those up once Eduardo
> is
> ok with (and has taken) the thermal-specific changes:
> > bd2720c thermal: rockchip: fix a impossible condition caused by the
> > warning df9c1bd thermal: rockchip: fix calculation error for
> > code_to_temp
> > fb11fbd thermal: rockchip: the rename compatibles for rockchip SoCs
> > b907b75 thermal: rockchip: fix the tsadc sequence output on
> > rk3228/rk3399

@Eduardo: any opinion on the patches related to the thermal driver itself?


Thanks
Heiko



From heiko at sntech.de  Thu Feb 25 17:14:26 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 26 Feb 2016 02:14:26 +0100
Subject: [PATCH v1 0/4] Add clock ids for RK3228 HDMI/VOP modules
In-Reply-To: <1456308303-29706-1-git-send-email-ykk@rock-chips.com>
References: <1456308303-29706-1-git-send-email-ykk@rock-chips.com>
Message-ID: <2198453.NY4VYR4LaI@phil>

Am Mittwoch, 24. Februar 2016, 18:05:03 schrieb Yakir Yang:
> Add clocks ids for RK3228 HDMI/VOP modules which driver already have been
> posted.
> 
> RK3228 HDMI driver: https://patchwork.kernel.org/patch/7974671
> RK3228 VOP driver: https://patchwork.kernel.org/patch/7952591
> 
> Yakir Yang (4):
>   clk: rockchip: add the new clock ids for RK3228 VOP
>   clk: rockchip: set the clock ids for RK3228 VOP
>   clk: rockchip: add the new clock ids for RK3228 HDMI
>   clk: rockchip: set the clock ids for RK3228 HDMI

applied all 4 to my clk-branch


Thanks
Heiko


From heiko at sntech.de  Thu Feb 25 17:13:48 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 26 Feb 2016 02:13:48 +0100
Subject: [RESEND PATCH] clk: rockchip: include downstream muxes into
 fractional dividers on rk3368
In-Reply-To: <1456274651-23202-1-git-send-email-zhangqing@rock-chips.com>
References: <1456274651-23202-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <4704515.DI1k3PeUbF@phil>

Am Mittwoch, 24. Februar 2016, 08:44:11 schrieb Elaine Zhang:
> During the initial conversion to the newly introduced combined fractional
> dividers+muxes the rk3368 clocks were left out, so convert them now.
> 
> Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>

applied to my clk-branch

Thanks
Heiko


From heiko at sntech.de  Thu Feb 25 17:12:48 2016
From: heiko at sntech.de (Heiko Stuebner)
Date: Fri, 26 Feb 2016 02:12:48 +0100
Subject: [RESEND PATCH 2/8] clk: rockchip: add the tsadc clocks found on
 rk3228 SoCs
In-Reply-To: <1455521613-27340-3-git-send-email-wxt@rock-chips.com>
References: <1455521613-27340-1-git-send-email-wxt@rock-chips.com>
 <1455521613-27340-3-git-send-email-wxt@rock-chips.com>
Message-ID: <3957748.pD5OVbRLLS@phil>

Am Montag, 15. Februar 2016, 15:33:27 schrieb Caesar Wang:
> This patch adds the needed clocks for rk3228 tsadc.
> 
> Signed-off-by: Caesar Wang <wxt at rock-chips.com>

applied to my clk-branch with Mike's Ack


Thanks
Heiko


From boris.brezillon at free-electrons.com  Thu Feb 25 16:58:00 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:58:00 +0100
Subject: [PATCH v3 52/52] mtd: kill the nand_ecclayout struct
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-53-git-send-email-boris.brezillon@free-electrons.com>

Now that all MTD drivers have moved to the mtd_ooblayout_ops model we can
safely remove the struct nand_ecclayout definition, and all the remaining
places where it was still used.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/mtdchar.c      |  12 ++---
 drivers/mtd/mtdcore.c      | 117 ---------------------------------------------
 include/linux/mtd/mtd.h    |  20 --------
 include/uapi/mtd/mtd-abi.h |   2 +-
 4 files changed, 7 insertions(+), 144 deletions(-)

diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index 3fad2c7..2a47a3f 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -465,12 +465,12 @@ static int mtdchar_readoob(struct file *file, struct mtd_info *mtd,
 }
 
 /*
- * Copies (and truncates, if necessary) data from the larger struct,
- * nand_ecclayout, to the smaller, deprecated layout struct,
- * nand_ecclayout_user. This is necessary only to support the deprecated
- * API ioctl ECCGETLAYOUT while allowing all new functionality to use
- * nand_ecclayout flexibly (i.e. the struct may change size in new
- * releases without requiring major rewrites).
+ * Copies (and truncates, if necessary) OOB layout information to the
+ * deprecated layout struct, nand_ecclayout_user. This is necessary only to
+ * support the deprecated API ioctl ECCGETLAYOUT while allowing all new
+ * functionality to use mtd_ooblayout_ops flexibly (i.e. mtd_ooblayout_ops
+ * can describe any kind of OOB layout with almost zero overhead from a
+ * memory usage point of view).
  */
 static int shrink_ecclayout(struct mtd_info *mtd,
 			    struct nand_ecclayout_user *to)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 3b1dc09..c921bdbe 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -1355,123 +1355,6 @@ int mtd_ooblayout_count_eccbytes(struct mtd_info *mtd)
 }
 EXPORT_SYMBOL_GPL(mtd_ooblayout_count_eccbytes);
 
-/**
- * mtd_ecclayout_ecc - Default ooblayout_ecc iterator implementation
- * @mtd: MTD device structure
- * @section: ECC section. Depending on the layout you may have all the ECC
- *	     bytes stored in a single contiguous section, or one section
- *	     per ECC chunk (and sometime several sections for a single ECC
- *	     ECC chunk)
- * @oobecc: OOB region struct filled with the appropriate ECC position
- *	    information
- *
- * This function is just a wrapper around the mtd->ecclayout field and is
- * here to ease the transition to the mtd_ooblayout_ops approach.
- * All it does is convert the layout->eccpos information into proper oob
- * region definitions.
- *
- * Returns zero on success, a negative error code otherwise.
- */
-static int mtd_ecclayout_ecc(struct mtd_info *mtd, int section,
-			     struct mtd_oob_region *oobecc)
-{
-	int eccbyte = 0, cursection = 0, length = 0, eccpos = 0;
-
-	if (!mtd->ecclayout)
-		return -ENOTSUPP;
-
-	/*
-	 * This logic allows us to reuse the ->ecclayout information and
-	 * expose them as ECC regions (as done for the OOB free regions).
-	 *
-	 * TODO: this should be dropped as soon as we get rid of the
-	 * ->ecclayout field.
-	 */
-	for (eccbyte = 0; eccbyte < mtd->ecclayout->eccbytes; eccbyte++) {
-		eccpos = mtd->ecclayout->eccpos[eccbyte];
-
-		if (eccbyte < mtd->ecclayout->eccbytes - 1) {
-			int neccpos = mtd->ecclayout->eccpos[eccbyte + 1];
-
-			if (eccpos + 1 == neccpos) {
-				length++;
-				continue;
-			}
-		}
-
-		if (section == cursection)
-			break;
-
-		length = 0;
-		cursection++;
-	}
-
-	if (cursection != section || eccbyte >= mtd->ecclayout->eccbytes)
-		return -ERANGE;
-
-	oobecc->length = length + 1;
-	oobecc->offset = eccpos - length;
-
-	return 0;
-}
-
-/**
- * mtd_ecclayout_ecc - Default ooblayout_free iterator implementation
- * @mtd: MTD device structure
- * @section: Free section. Depending on the layout you may have all the free
- *	     bytes stored in a single contiguous section, or one section
- *	     per ECC chunk (and sometime several sections for a single ECC
- *	     ECC chunk)
- * @oobfree: OOB region struct filled with the appropriate free position
- *	     information
- *
- * This function is just a wrapper around the mtd->ecclayout field and is
- * here to ease the transition to the mtd_ooblayout_ops approach.
- * All it does is convert the layout->oobfree information into proper oob
- * region definitions.
- *
- * Returns zero on success, a negative error code otherwise.
- */
-static int mtd_ecclayout_free(struct mtd_info *mtd, int section,
-			      struct mtd_oob_region *oobfree)
-{
-	struct nand_ecclayout *layout = mtd->ecclayout;
-
-	if (!layout)
-		return -ENOTSUPP;
-
-	if (section >= MTD_MAX_OOBFREE_ENTRIES_LARGE ||
-	    !layout->oobfree[section].length)
-		return -ERANGE;
-
-	oobfree->offset = layout->oobfree[section].offset;
-	oobfree->length = layout->oobfree[section].length;
-
-	return 0;
-}
-
-static const struct mtd_ooblayout_ops mtd_ecclayout_wrapper_ops = {
-	.ecc = mtd_ecclayout_ecc,
-	.free = mtd_ecclayout_free,
-};
-
-/**
- * mtd_set_ecclayout - Attach an ecclayout to an MTD device
- * @mtd: MTD device structure
- * @ecclayout: The ecclayout to attach to the device
- *
- * Returns zero on success, a negative error code otherwise.
- */
-void mtd_set_ecclayout(struct mtd_info *mtd, struct nand_ecclayout *ecclayout)
-{
-	if (!mtd || !ecclayout)
-		return;
-
-	mtd->ecclayout = ecclayout;
-	mtd_set_ooblayout(mtd, &mtd_ecclayout_wrapper_ops);
-}
-EXPORT_SYMBOL_GPL(mtd_set_ecclayout);
-
 /*
  * Method to access the protection register area, present in some flash
  * devices. The user data is one time programmable but the factory data is read
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index a38fe9a..df8c116 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -96,21 +96,6 @@ struct mtd_oob_ops {
 
 #define MTD_MAX_OOBFREE_ENTRIES_LARGE	32
 #define MTD_MAX_ECCPOS_ENTRIES_LARGE	640
-/*
- * Internal ECC layout control structure. For historical reasons, there is a
- * similar, smaller struct nand_ecclayout_user (in mtd-abi.h) that is retained
- * for export to user-space via the ECCGETLAYOUT ioctl.
- * nand_ecclayout should be expandable in the future simply by the above macros.
- *
- * This structure is now deprecated, you should use struct nand_ecclayout_ops
- * to describe your OOB layout.
- */
-struct nand_ecclayout {
-	__u32 eccbytes;
-	__u32 eccpos[MTD_MAX_ECCPOS_ENTRIES_LARGE];
-	struct nand_oobfree oobfree[MTD_MAX_OOBFREE_ENTRIES_LARGE];
-};
-
 /**
  * struct mtd_oob_region - oob region definition
  * @offset: region offset
@@ -200,9 +185,6 @@ struct mtd_info {
 	const char *name;
 	int index;
 
-	/* [Deprecated] ECC layout structure pointer - read only! */
-	struct nand_ecclayout *ecclayout;
-
 	/* OOB layout description */
 	const struct mtd_ooblayout_ops *ooblayout;
 
@@ -308,8 +290,6 @@ int mtd_ooblayout_set_databytes(struct mtd_info *mtd, const u8 *databuf,
 int mtd_ooblayout_count_freebytes(struct mtd_info *mtd);
 int mtd_ooblayout_count_eccbytes(struct mtd_info *mtd);
 
-void mtd_set_ecclayout(struct mtd_info *mtd, struct nand_ecclayout *ecclayout);
-
 static inline void mtd_set_ooblayout(struct mtd_info *mtd,
 				     const struct mtd_ooblayout_ops *ooblayout)
 {
diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
index 763bb69..0ec1da2 100644
--- a/include/uapi/mtd/mtd-abi.h
+++ b/include/uapi/mtd/mtd-abi.h
@@ -228,7 +228,7 @@ struct nand_oobfree {
  * complete set of ECC information. The ioctl truncates the larger internal
  * structure to retain binary compatibility with the static declaration of the
  * ioctl. Note that the "MTD_MAX_..._ENTRIES" macros represent the max size of
- * the user struct, not the MAX size of the internal struct nand_ecclayout.
+ * the user struct, not the MAX size of the internal OOB layout representation.
  */
 struct nand_ecclayout_user {
 	__u32 eccbytes;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:51 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:51 +0100
Subject: [PATCH v3 43/52] mtd: nand: pxa3xx: switch to mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-44-git-send-email-boris.brezillon@free-electrons.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/pxa3xx_nand.c | 104 +++++++++++++++++++++++++----------------
 1 file changed, 64 insertions(+), 40 deletions(-)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index 56e8954..ebd1902 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -325,6 +325,62 @@ static struct pxa3xx_nand_flash builtin_flash_types[] = {
 	{ 0xba20, 16, 16, &timing[3] },
 };
 
+static int pxa3xx_ooblayout_ecc(struct mtd_info *mtd, int section,
+				struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct pxa3xx_nand_host *host = nand_get_controller_data(chip);
+	struct pxa3xx_nand_info *info = host->info_data;
+	int nchunks = mtd->writesize / info->chunk_size;
+
+	if (section >= nchunks)
+		return -ERANGE;
+
+	oobregion->offset = ((info->ecc_size + info->spare_size) * section) +
+			    info->spare_size;
+	oobregion->length = info->ecc_size;
+
+	return 0;
+}
+
+static int pxa3xx_ooblayout_free(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct pxa3xx_nand_host *host = nand_get_controller_data(chip);
+	struct pxa3xx_nand_info *info = host->info_data;
+	int nchunks = mtd->writesize / info->chunk_size;
+
+	if (section >= nchunks)
+		return -ERANGE;
+
+	if (!info->spare_size)
+		return 0;
+
+	oobregion->offset = section * (info->ecc_size + info->spare_size);
+	oobregion->length = info->spare_size;
+	if (!section) {
+		/*
+		 * Bootrom looks in bytes 0 & 5 for bad blocks for the
+		 * 4KB page / 4bit BCH combination.
+		 */
+		if (mtd->writesize == 4096 && info->chunk_size == 2048) {
+			oobregion->offset += 6;
+			oobregion->length -= 6;
+		} else {
+			oobregion->offset += 2;
+			oobregion->length -= 2;
+		}
+	}
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops pxa3xx_ooblayout_ops = {
+	.ecc = pxa3xx_ooblayout_ecc,
+	.free = pxa3xx_ooblayout_free,
+};
+
 static u8 bbt_pattern[] = {'M', 'V', 'B', 'b', 't', '0' };
 static u8 bbt_mirror_pattern[] = {'1', 't', 'b', 'B', 'V', 'M' };
 
@@ -348,41 +404,6 @@ static struct nand_bbt_descr bbt_mirror_descr = {
 	.pattern = bbt_mirror_pattern
 };
 
-static struct nand_ecclayout ecc_layout_2KB_bch4bit = {
-	.eccbytes = 32,
-	.eccpos = {
-		32, 33, 34, 35, 36, 37, 38, 39,
-		40, 41, 42, 43, 44, 45, 46, 47,
-		48, 49, 50, 51, 52, 53, 54, 55,
-		56, 57, 58, 59, 60, 61, 62, 63},
-	.oobfree = { {2, 30} }
-};
-
-static struct nand_ecclayout ecc_layout_4KB_bch4bit = {
-	.eccbytes = 64,
-	.eccpos = {
-		32,  33,  34,  35,  36,  37,  38,  39,
-		40,  41,  42,  43,  44,  45,  46,  47,
-		48,  49,  50,  51,  52,  53,  54,  55,
-		56,  57,  58,  59,  60,  61,  62,  63,
-		96,  97,  98,  99,  100, 101, 102, 103,
-		104, 105, 106, 107, 108, 109, 110, 111,
-		112, 113, 114, 115, 116, 117, 118, 119,
-		120, 121, 122, 123, 124, 125, 126, 127},
-	/* Bootrom looks in bytes 0 & 5 for bad blocks */
-	.oobfree = { {6, 26}, { 64, 32} }
-};
-
-static struct nand_ecclayout ecc_layout_4KB_bch8bit = {
-	.eccbytes = 128,
-	.eccpos = {
-		32,  33,  34,  35,  36,  37,  38,  39,
-		40,  41,  42,  43,  44,  45,  46,  47,
-		48,  49,  50,  51,  52,  53,  54,  55,
-		56,  57,  58,  59,  60,  61,  62,  63},
-	.oobfree = { }
-};
-
 #define NDTR0_tCH(c)	(min((c), 7) << 19)
 #define NDTR0_tCS(c)	(min((c), 7) << 16)
 #define NDTR0_tWH(c)	(min((c), 7) << 11)
@@ -1547,9 +1568,12 @@ static void pxa3xx_nand_free_buff(struct pxa3xx_nand_info *info)
 }
 
 static int pxa_ecc_init(struct pxa3xx_nand_info *info,
-			struct nand_ecc_ctrl *ecc,
+			struct mtd_info *mtd,
 			int strength, int ecc_stepsize, int page_size)
 {
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct nand_ecc_ctrl *ecc = &chip->ecc;
+
 	if (strength == 1 && ecc_stepsize == 512 && page_size == 2048) {
 		info->nfullchunks = 1;
 		info->ntotalchunks = 1;
@@ -1583,7 +1607,7 @@ static int pxa_ecc_init(struct pxa3xx_nand_info *info,
 		info->ecc_size = 32;
 		ecc->mode = NAND_ECC_HW;
 		ecc->size = info->chunk_size;
-		ecc->layout = &ecc_layout_2KB_bch4bit;
+		mtd_set_ooblayout(mtd, &pxa3xx_ooblayout_ops);
 		ecc->strength = 16;
 
 	} else if (strength == 4 && ecc_stepsize == 512 && page_size == 4096) {
@@ -1595,7 +1619,7 @@ static int pxa_ecc_init(struct pxa3xx_nand_info *info,
 		info->ecc_size = 32;
 		ecc->mode = NAND_ECC_HW;
 		ecc->size = info->chunk_size;
-		ecc->layout = &ecc_layout_4KB_bch4bit;
+		mtd_set_ooblayout(mtd, &pxa3xx_ooblayout_ops);
 		ecc->strength = 16;
 
 	/*
@@ -1613,7 +1637,7 @@ static int pxa_ecc_init(struct pxa3xx_nand_info *info,
 		info->ecc_size = 32;
 		ecc->mode = NAND_ECC_HW;
 		ecc->size = info->chunk_size;
-		ecc->layout = &ecc_layout_4KB_bch8bit;
+		mtd_set_ooblayout(mtd, &pxa3xx_ooblayout_ops);
 		ecc->strength = 16;
 	} else {
 		dev_err(&info->pdev->dev,
@@ -1704,7 +1728,7 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
 		ecc_step = 512;
 	}
 
-	ret = pxa_ecc_init(info, &chip->ecc, ecc_strength,
+	ret = pxa_ecc_init(info, mtd, ecc_strength,
 			   ecc_step, mtd->writesize);
 	if (ret)
 		return ret;
-- 
2.1.4



From boris.brezillon at free-electrons.com  Thu Feb 25 16:57:29 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 01:57:29 +0100
Subject: [PATCH v3 21/52] mtd: nand: implement the default mtd_ooblayout_ops
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <1456448280-27788-22-git-send-email-boris.brezillon@free-electrons.com>

Replace the default nand_ecclayout definitions for large and small page
devices with the equivalent mtd_ooblayout_ops.

Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com>
---
 drivers/mtd/nand/nand_base.c | 148 ++++++++++++++++++++++++++++---------------
 include/linux/mtd/nand.h     |   3 +
 2 files changed, 99 insertions(+), 52 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 5093a3c..71d5948 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -48,50 +48,6 @@
 #include <linux/mtd/partitions.h>
 #include <linux/of_mtd.h>
 
-/* Define default oob placement schemes for large and small page devices */
-static struct nand_ecclayout nand_oob_8 = {
-	.eccbytes = 3,
-	.eccpos = {0, 1, 2},
-	.oobfree = {
-		{.offset = 3,
-		 .length = 2},
-		{.offset = 6,
-		 .length = 2} }
-};
-
-static struct nand_ecclayout nand_oob_16 = {
-	.eccbytes = 6,
-	.eccpos = {0, 1, 2, 3, 6, 7},
-	.oobfree = {
-		{.offset = 8,
-		 . length = 8} }
-};
-
-static struct nand_ecclayout nand_oob_64 = {
-	.eccbytes = 24,
-	.eccpos = {
-		   40, 41, 42, 43, 44, 45, 46, 47,
-		   48, 49, 50, 51, 52, 53, 54, 55,
-		   56, 57, 58, 59, 60, 61, 62, 63},
-	.oobfree = {
-		{.offset = 2,
-		 .length = 38} }
-};
-
-static struct nand_ecclayout nand_oob_128 = {
-	.eccbytes = 48,
-	.eccpos = {
-		   80, 81, 82, 83, 84, 85, 86, 87,
-		   88, 89, 90, 91, 92, 93, 94, 95,
-		   96, 97, 98, 99, 100, 101, 102, 103,
-		   104, 105, 106, 107, 108, 109, 110, 111,
-		   112, 113, 114, 115, 116, 117, 118, 119,
-		   120, 121, 122, 123, 124, 125, 126, 127},
-	.oobfree = {
-		{.offset = 2,
-		 .length = 78} }
-};
-
 static int nand_get_device(struct mtd_info *mtd, int new_state);
 
 static int nand_do_write_oob(struct mtd_info *mtd, loff_t to,
@@ -103,6 +59,92 @@ static int nand_do_write_oob(struct mtd_info *mtd, loff_t to,
  */
 DEFINE_LED_TRIGGER(nand_led_trigger);
 
+/* Define default oob placement schemes for large and small page devices */
+static int nand_ooblayout_ecc_sp(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct nand_ecc_ctrl *ecc = &chip->ecc;
+
+	if (section > 1)
+		return -ERANGE;
+
+	if (!section) {
+		oobregion->offset = 0;
+		oobregion->length = 4;
+	} else {
+		oobregion->offset = 6;
+		oobregion->length = (ecc->bytes * ecc->steps) - 4;
+	}
+
+	return 0;
+}
+
+static int nand_ooblayout_free_sp(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	if (section > 1)
+		return -ERANGE;
+
+	if (mtd->oobsize == 16) {
+		if (section)
+			return -ERANGE;
+
+		oobregion->length = 8;
+		oobregion->offset = 8;
+	} else {
+		oobregion->length = 2;
+		if (!section)
+			oobregion->offset = 3;
+		else
+			oobregion->offset = 6;
+	}
+
+	return 0;
+}
+
+const struct mtd_ooblayout_ops nand_ooblayout_sp_ops = {
+	.ecc = nand_ooblayout_ecc_sp,
+	.free = nand_ooblayout_free_sp,
+};
+EXPORT_SYMBOL_GPL(nand_ooblayout_sp_ops);
+
+static int nand_ooblayout_ecc_lp(struct mtd_info *mtd, int section,
+				 struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct nand_ecc_ctrl *ecc = &chip->ecc;
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->length = ecc->bytes * ecc->steps;
+	oobregion->offset = mtd->oobsize - oobregion->length;
+
+	return 0;
+}
+
+static int nand_ooblayout_free_lp(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+	struct nand_ecc_ctrl *ecc = &chip->ecc;
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->length = mtd->oobsize - (ecc->bytes * ecc->steps) - 2;
+	oobregion->offset = 2;
+
+	return 0;
+}
+
+const struct mtd_ooblayout_ops nand_ooblayout_lp_ops = {
+	.ecc = nand_ooblayout_ecc_lp,
+	.free = nand_ooblayout_free_lp,
+};
+EXPORT_SYMBOL_GPL(nand_ooblayout_lp_ops);
+
 static int check_offs_len(struct mtd_info *mtd,
 					loff_t ofs, uint64_t len)
 {
@@ -4120,21 +4162,24 @@ int nand_scan_tail(struct mtd_info *mtd)
 	chip->oob_poi = chip->buffers->databuf + mtd->writesize;
 
 	/*
+	 * Set the provided ECC layout. If ecc->layout is NULL, the MTD core
+	 * will just leave mtd->ooblayout to NULL, if it's not NULL, it will
+	 * set ->ooblayout to the default ecclayout wrapper.
+	 */
+	mtd_set_ecclayout(mtd, ecc->layout);
+
+	/*
 	 * If no default placement scheme is given, select an appropriate one.
 	 */
-	if (!ecc->layout && (ecc->mode != NAND_ECC_SOFT_BCH)) {
+	if (!mtd->ooblayout && (ecc->mode != NAND_ECC_SOFT_BCH)) {
 		switch (mtd->oobsize) {
 		case 8:
-			ecc->layout = &nand_oob_8;
-			break;
 		case 16:
-			ecc->layout = &nand_oob_16;
+			mtd_set_ooblayout(mtd, &nand_ooblayout_sp_ops);
 			break;
 		case 64:
-			ecc->layout = &nand_oob_64;
-			break;
 		case 128:
-			ecc->layout = &nand_oob_128;
+			mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
 			break;
 		default:
 			pr_warn("No oob scheme defined for oobsize %d\n",
@@ -4288,7 +4333,6 @@ int nand_scan_tail(struct mtd_info *mtd)
 		ecc->write_oob_raw = ecc->write_oob;
 
 	/* propagate ecc info to mtd_info */
-	mtd_set_ecclayout(mtd, ecc->layout);
 	mtd->ecc_strength = ecc->strength;
 	mtd->ecc_step_size = ecc->size;
 
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 7604f4b..82a005a 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -740,6 +740,9 @@ struct nand_chip {
 	void *priv;
 };
 
+extern const struct mtd_ooblayout_ops nand_ooblayout_sp_ops;
+extern const struct mtd_ooblayout_ops nand_ooblayout_lp_ops;
+
 static inline void nand_set_flash_node(struct nand_chip *chip,
 				       struct device_node *np)
 {
-- 
2.1.4



From broonie at kernel.org  Thu Feb 25 17:18:27 2016
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Feb 2016 10:18:27 +0900
Subject: [PATCH RESEND] ASoC: pxa: remove unused variable
In-Reply-To: <1456437736-732609-1-git-send-email-arnd@arndb.de>
References: <1456437736-732609-1-git-send-email-arnd@arndb.de>
Message-ID: <20160226011827.GA18327@sirena.org.uk>

On Thu, Feb 25, 2016 at 11:02:04PM +0100, Arnd Bergmann wrote:

> Submitted originally on Nov 23 2015, this apparently got lost,
> resending it now.

You didn't really submit it, you pasted it into the middle of a reply to
a message on an existing thread for a patch that was already applied:

https://lkml.org/lkml/2015/11/23/88

That's not really submitting a patch as far as I'm concerned, something
that won't just apply with git am without special faffing isn't helping
and things in the middle of threads aren't good either (it gets
difficult to follow and there's every chance they'll never even get seen
if they're buried in the middle of a reply where you don't expect to see
a patch).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160226/77c700e0/attachment-0001.sig>

From ddaney at caviumnetworks.com  Thu Feb 25 17:26:34 2016
From: ddaney at caviumnetworks.com (David Daney)
Date: Thu, 25 Feb 2016 17:26:34 -0800
Subject: [PATCH v11 08/10] dt, numa: Add NUMA dt binding implementation.
In-Reply-To: <20160223193651.GA8491@rob-hp-laptop>
References: <1455930799-5371-1-git-send-email-ddaney.cavm@gmail.com>
 <1455930799-5371-9-git-send-email-ddaney.cavm@gmail.com>
 <20160223193651.GA8491@rob-hp-laptop>
Message-ID: <56CFA9CA.6090803@caviumnetworks.com>

On 02/23/2016 11:36 AM, Rob Herring wrote:
> On Fri, Feb 19, 2016 at 05:13:17PM -0800, David Daney wrote:
>> From: Ganapatrao Kulkarni <gkulkarni at caviumnetworks.com>
>>
>> ADD device tree node parsing for NUMA topology using device
>> "numa-node-id" property distance-map.
>
> I still want an adequate explanation why NUMA setup cannot be done with
> an unflattened tree. PowerPC manages to do that and should have a
> similar init flow being memblock based, so I would expect arm64 can too.

Many things could be done.  Really, we want to know what *should* be done.

In the context of the current arm64 memory initialization we (more or 
less) do:

  1) early_init_fdt_scan_reserved_mem();
  2) memory_present()
  3) sparse_init()
  4) other things
  5) unflatten_device_tree()

We are already reading information out of the FDT at #1.

This patch set adds a step between 1 and 2 where we read NUMA 
information out of the FDT.

Hypothetically, it might be possible to rewrite the arm64 setup code so 
that the ordering was different, and the NUMA setup was done on the 
unflattened tree, but that would certainly be a much more invasive patch.

If the arm64 maintainers would like a rewrite of:

   arch/arm64/kernel/setup.c
   arch/arm64/mm/init.c
   arch/arm64/mm/mm/mmu.c
   .
   .
   .

we can discuss doing NUMA setup with the unflattened tree.  With the 
current memory initialization code, I think it makes more sense to parse 
the NUMA information out of the flattened form.

David Daney




From stefan at agner.ch  Thu Feb 25 17:27:23 2016
From: stefan at agner.ch (Stefan Agner)
Date: Thu, 25 Feb 2016 17:27:23 -0800
Subject: [PATCH v3 00/52] mtd: rework ECC layout definition
In-Reply-To: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
Message-ID: <d968b867f4d7f603581a0ff83e07c15c@agner.ch>

Hi Boris,

On 2016-02-25 16:57, Boris Brezillon wrote:
> Hello,
> 
> This patchset aims at getting rid of the nand_ecclayout limitations.
> struct nand_ecclayout is defining fixed eccpos and oobfree arrays which
> can only be increased by modifying the MTD_MAX_ECCPOS_ENTRIES_LARGE and
> MTD_MAX_OOBFREE_ENTRIES_LARGE macros.
> This approach forces us to modify the macro values each time we add a
> new NAND chip with a bigger OOB area, and increasing these arrays also
> penalize all platforms, even those who only support small NAND devices
> (with small OOB area).
> 
> The idea to overcome this limitation, is to define the ECC/OOB layout
> by the mean of two functions: ->ecc() and ->free(), which will
> basically return the same information has those stored in the
> nand_ecclayout struct.
> 
> Another advantage of this solution is that ECC layouts are usually
> following a repetitive pattern (i.e. leave X bytes free and put Y bytes
> of ECC per ECC chunk), which allows one to implement the ->ecc()
> and ->free() functions with a simple logic that can be applied
> to any size of OOB.
> 
> Patches 1 to 4 are just cleanups or trivial fixes that can be taken
> independently.
> 
> Also note that the last two commits are removing the nand_ecclayout
> definition, thus preventing any new driver to use this structure.
> Of course, this step can be delayed if some of the previous patches
> are not accepted.

Is the patch set somewhere available to pull from?

Do I see things right that patch 21/52 contains the crucial function
nand_ooblayout_ecc_lp which calculate the ECC position? (for those who
do not provide mtd_ooblayout_ops anyway...)

--
Stefan

> 
> Best Regards,
> 
> Boris
> 
> Changes since v2:
> - fixed a few bugs in the core and driver implementations
> 
> Changes since v1:
> - unified the way of defining ECC and free bytes
> - fixed a few bugs in some ->ecc()/->free() implementations
> - added new helpers to ease ECC and free bytes manipulation
> - separated driver changes in different commits to ease review
> - dropped already applied patches
> 
> *** BLURB HERE ***
> 
> Boris Brezillon (52):
>   mtd: kill the ecclayout->oobavail field
>   mtd: create an mtd_oobavail() helper and make use of it
>   mtd: mtdswap: remove useless if (!mtd->ecclayout) test
>   mtd: nand: simplify nand_bch_init() usage
>   mtd: add mtd_ooblayout_xxx() helper functions
>   mtd: use mtd_ooblayout_xxx() helpers where appropriate
>   mtd: nand: core: use mtd_ooblayout_xxx() helpers where appropriate
>   mtd: nand: atmel: use mtd_ooblayout_xxx() helpers where appropriate
>   mtd: nand: fsl_ifc: use mtd_ooblayout_xxx() helpers where appropriate
>   mtd: nand: gpmi: use mtd_ooblayout_xxx() helpers where appropriate
>   mtd: nand: lpc32xx: use mtd_ooblayout_xxx() helpers where appropriate
>   mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
>   mtd: onenand: use mtd_ooblayout_xxx() helpers where appropriate
>   mtd: add mtd_set_ecclayout() helper function
>   mtd: use mtd_set_ecclayout() where appropriate
>   mtd: nand: use mtd_set_ecclayout() where appropriate
>   mtd: onenand: use mtd_set_ecclayout() where appropriate
>   mtd: docg3: use mtd_set_ecclayout() where appropriate
>   mtd: create an mtd_ooblayout_ops struct to ease ECC layout definition
>   mtd: docg3: switch to mtd_ooblayout_ops
>   mtd: nand: implement the default mtd_ooblayout_ops
>   mtd: nand: bch: switch to mtd_ooblayout_ops
>   mtd: nand: sharpsl: switch to mtd_ooblayout_ops
>   mtd: nand: jz4740: switch to mtd_ooblayout_ops
>   mtd: nand: atmel: switch to mtd_ooblayout_ops
>   mtd: nand: bf5xx: switch to mtd_ooblayout_ops
>   mtd: nand: brcm: switch to mtd_ooblayout_ops
>   mtd: nand: cafe: switch to mtd_ooblayout_ops
>   mtd: nand: davinci: switch to mtd_ooblayout_ops
>   mtd: nand: denali: switch to mtd_ooblayout_ops
>   mtd: nand: diskonchip: switch to mtd_ooblayout_ops
>   mtd: nand: docg4: switch to mtd_ooblayout_ops
>   mtd: nand: fsl_elbc: switch to mtd_ooblayout_ops
>   mtd: nand: fsl_ifc: switch to mtd_ooblayout_ops
>   mtd: nand: fsmc: switch to mtd_ooblayout_ops
>   mtd: nand: fsmc: get rid of the fsmc_nand_eccplace struct
>   mtd: nand: gpmi: switch to mtd_ooblayout_ops
>   mtd: nand: hisi504: switch to mtd_ooblayout_ops
>   mtd: nand: jz4780: switch to mtd_ooblayout_ops
>   mtd: nand: lpc32xx: switch to mtd_ooblayout_ops
>   mtd: nand: mxc: switch to mtd_ooblayout_ops
>   mtd: nand: omap2: switch to mtd_ooblayout_ops
>   mtd: nand: pxa3xx: switch to mtd_ooblayout_ops
>   mtd: nand: s3c2410: switch to mtd_ooblayout_ops
>   mtd: nand: sh_flctl: switch to mtd_ooblayout_ops
>   mtd: nand: sm_common: switch to mtd_ooblayout_ops
>   mtd: nand: sunxi: switch to mtd_ooblayout_ops
>   mtd: nand: vf610: switch to mtd_ooblayout_ops
>   mtd: onenand: switch to mtd_ooblayout_ops
>   staging: mt29f_spinand: switch to mtd_ooblayout_ops
>   mtd: nand: kill the ecc->layout field
>   mtd: kill the nand_ecclayout struct
> 
>  arch/arm/mach-pxa/spitz.c                       |  55 +++-
>  arch/mips/include/asm/mach-jz4740/jz4740_nand.h |   2 +-
>  arch/mips/jz4740/board-qi_lb60.c                |  87 +++---
>  drivers/mtd/devices/docg3.c                     |  51 +++-
>  drivers/mtd/mtdchar.c                           | 123 ++++++--
>  drivers/mtd/mtdconcat.c                         |   2 +-
>  drivers/mtd/mtdcore.c                           | 358 ++++++++++++++++++++++++
>  drivers/mtd/mtdpart.c                           |  28 +-
>  drivers/mtd/mtdswap.c                           |  24 +-
>  drivers/mtd/nand/atmel_nand.c                   | 130 ++++-----
>  drivers/mtd/nand/bf5xx_nand.c                   |  51 ++--
>  drivers/mtd/nand/brcmnand/brcmnand.c            | 262 ++++++++++-------
>  drivers/mtd/nand/cafe_nand.c                    |  45 ++-
>  drivers/mtd/nand/davinci_nand.c                 | 118 +++-----
>  drivers/mtd/nand/denali.c                       |  51 +++-
>  drivers/mtd/nand/diskonchip.c                   |  60 +++-
>  drivers/mtd/nand/docg4.c                        |  34 ++-
>  drivers/mtd/nand/fsl_elbc_nand.c                |  83 +++---
>  drivers/mtd/nand/fsl_ifc_nand.c                 | 245 +++++-----------
>  drivers/mtd/nand/fsmc_nand.c                    | 322 ++++++---------------
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c          |  61 ++--
>  drivers/mtd/nand/hisi504_nand.c                 |  27 +-
>  drivers/mtd/nand/jz4740_nand.c                  |   2 +-
>  drivers/mtd/nand/jz4780_nand.c                  |  19 +-
>  drivers/mtd/nand/lpc32xx_mlc.c                  |  50 ++--
>  drivers/mtd/nand/lpc32xx_slc.c                  |  58 +++-
>  drivers/mtd/nand/mxc_nand.c                     | 212 +++++++-------
>  drivers/mtd/nand/nand_base.c                    | 344 ++++++++++++-----------
>  drivers/mtd/nand/nand_bch.c                     |  46 ++-
>  drivers/mtd/nand/omap2.c                        | 241 +++++++++-------
>  drivers/mtd/nand/pxa3xx_nand.c                  | 104 ++++---
>  drivers/mtd/nand/s3c2410.c                      |  32 ++-
>  drivers/mtd/nand/sh_flctl.c                     |  87 ++++--
>  drivers/mtd/nand/sharpsl.c                      |   2 +-
>  drivers/mtd/nand/sm_common.c                    |  93 ++++--
>  drivers/mtd/nand/sunxi_nand.c                   | 114 ++++----
>  drivers/mtd/nand/vf610_nfc.c                    |  34 +--
>  drivers/mtd/onenand/onenand_base.c              | 262 ++++++++---------
>  drivers/mtd/tests/oobtest.c                     |  49 ++--
>  drivers/staging/mt29f_spinand/mt29f_spinand.c   |  49 ++--
>  fs/jffs2/wbuf.c                                 |   6 +-
>  include/linux/mtd/fsmc.h                        |  18 --
>  include/linux/mtd/mtd.h                         |  69 ++++-
>  include/linux/mtd/nand.h                        |   5 +-
>  include/linux/mtd/nand_bch.h                    |   8 +-
>  include/linux/mtd/onenand.h                     |   2 -
>  include/linux/mtd/sharpsl.h                     |   2 +-
>  include/uapi/mtd/mtd-abi.h                      |   2 +-
>  48 files changed, 2375 insertions(+), 1754 deletions(-)


From robert.jarzmik at free.fr  Thu Feb 25 17:33:49 2016
From: robert.jarzmik at free.fr (Robert Jarzmik)
Date: Fri, 26 Feb 2016 02:33:49 +0100
Subject: [PATCH 1/4] ASoC: wm9713: add binding for WM9713 codec
In-Reply-To: <20160221014920.GK18327@sirena.org.uk> (Mark Brown's message of
 "Sun, 21 Feb 2016 10:49:20 +0900")
References: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
 <20160220171459.GA18327@sirena.org.uk> <871t87z1gz.fsf@belgarion.home>
 <20160220195925.GF18327@sirena.org.uk> <87twl3xgud.fsf@belgarion.home>
 <20160220211659.GG18327@sirena.org.uk> <878u2fxbp9.fsf@belgarion.home>
 <20160221014920.GK18327@sirena.org.uk>
Message-ID: <87povkuuf6.fsf@belgarion.home>

Mark Brown <broonie at kernel.org> writes:

>> > It will eumerate the AC'97 bus by itself and does not need the CODEC to
>> > be described.
>
>> I think I still don't get it.
>
>> So let's rephrase it another way : how will the function wm9713_probe() be
>> called, ie. what is the possible function backtrace leading to that call ?
>
> It will not be called, the generic AC'97 code will be used.

Ok, if it's not called no code in sound/soc/codecs/wm9713.c will be used, right
?
In that case wm9713_set_dai_clkdiv() will never be used, nor will the
wm9713_audio_map or wm9713_dapm_widgets be created, which will break all
userspace programs relying on these mixers and DAPM routes.

Or am I missing something ?

>> Do you have a devicetree example somewhere, with (ac97 host, audio codec) pair I
>> can have a look at to understand ?
>
> Some Atmel boards do this IIRC, as does the AACI driver (via AMBA but
> same effect).
I suppose you mean sound/arm/aaci.c, which is more a platform_data like driver
(if I understood the integrator code correctly).

I suppose we can achieve comparable result with sound/arm/pxa2xx-ac97.c, but as
to know if the functionality will be comparable to sound/soc/pxa/pxa2xx-ac97.c,
it's hard to say. If I count the DMA requestors, I see 5 in the sound/soc
version, and 2 in sound/arm.

That makes me believe the sound/arm version is inferior.

Cheers.

-- 
Robert


From liguo.zhang at mediatek.com  Thu Feb 25 09:35:39 2016
From: liguo.zhang at mediatek.com (Liguo Zhang)
Date: Fri, 26 Feb 2016 01:35:39 +0800
Subject: [PATCH v2] i2c: mediatek: i2c multi transfer optimization
Message-ID: <1456421739-5450-1-git-send-email-liguo.zhang@mediatek.com>

Send the next transfer in the i2c irq handler, and only signal
complete() when the entire transaction has been completed.

Signed-off-by: Liguo Zhang <liguo.zhang at mediatek.com>
---
change in v2:
Remove the unused variable left_num in mtk_i2c_transfer().
---
 drivers/i2c/busses/i2c-mt65xx.c | 221 ++++++++++++++++++++++------------------
 1 file changed, 123 insertions(+), 98 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 453358b..3a498e1 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -139,6 +139,15 @@ struct mtk_i2c_compatible {
 	unsigned char support_33bits: 1;
 };
 
+struct mtk_i2c_transaction {
+	u32 num;
+	u32 index;
+	dma_addr_t wpaddr;
+	dma_addr_t rpaddr;
+	struct i2c_msg *msgs;
+	int result;
+};
+
 struct mtk_i2c {
 	struct i2c_adapter adap;	/* i2c host adapter */
 	struct device *dev;
@@ -161,6 +170,7 @@ struct mtk_i2c {
 	unsigned char auto_restart;
 	bool ignore_restart_irq;
 	const struct mtk_i2c_compatible *dev_comp;
+	struct mtk_i2c_transaction transac;
 };
 
 static const struct i2c_adapter_quirks mt6577_i2c_quirks = {
@@ -378,8 +388,7 @@ static inline u32 mtk_i2c_set_4g_mode(dma_addr_t addr)
 	return (addr & BIT_ULL(32)) ? I2C_DMA_4G_MODE : I2C_DMA_CLR_FLAG;
 }
 
-static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
-			       int num, int left_num)
+static int mtk_i2c_start_transfer(struct mtk_i2c *i2c)
 {
 	u16 addr_reg;
 	u16 start_reg;
@@ -388,15 +397,31 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 	u32 reg_4g_mode;
 	dma_addr_t rpaddr = 0;
 	dma_addr_t wpaddr = 0;
-	int ret;
+	struct i2c_msg *msg;
+	struct mtk_i2c_transaction *i2c_transac;
+	int num;
+	int left_num;
 
 	i2c->irq_stat = 0;
 
+	i2c_transac = &i2c->transac;
+	num = i2c_transac->num;
+	left_num = i2c_transac->num - i2c_transac->index - 1;
+	msg = &i2c_transac->msgs[i2c_transac->index];
+
+	if (!msg->buf)
+		return -EINVAL;
+
+	if (i2c->op == I2C_MASTER_WRRD)
+		left_num--;
+	else if (msg->flags & I2C_M_RD)
+		i2c->op = I2C_MASTER_RD;
+	else
+		i2c->op = I2C_MASTER_WR;
+
 	if (i2c->auto_restart)
 		restart_flag = I2C_RS_TRANSFER;
 
-	reinit_completion(&i2c->msg_complete);
-
 	control_reg = readw(i2c->base + OFFSET_CONTROL) &
 			~(I2C_CONTROL_DIR_CHANGE | I2C_CONTROL_RS);
 	if ((i2c->speed_hz > 400000) || (left_num >= 1))
@@ -413,7 +438,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 	else
 		writew(I2C_FS_START_CON, i2c->base + OFFSET_EXT_CONF);
 
-	addr_reg = msgs->addr << 1;
+	addr_reg = msg->addr << 1;
 	if (i2c->op == I2C_MASTER_RD)
 		addr_reg |= 0x1;
 
@@ -431,16 +456,16 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 	/* Set transfer and transaction len */
 	if (i2c->op == I2C_MASTER_WRRD) {
 		if (i2c->dev_comp->aux_len_reg) {
-			writew(msgs->len, i2c->base + OFFSET_TRANSFER_LEN);
-			writew((msgs + 1)->len, i2c->base +
+			writew(msg->len, i2c->base + OFFSET_TRANSFER_LEN);
+			writew((msg + 1)->len, i2c->base +
 			       OFFSET_TRANSFER_LEN_AUX);
 		} else {
-			writew(msgs->len | ((msgs + 1)->len) << 8,
+			writew(msg->len | ((msg + 1)->len) << 8,
 			       i2c->base + OFFSET_TRANSFER_LEN);
 		}
 		writew(I2C_WRRD_TRANAC_VALUE, i2c->base + OFFSET_TRANSAC_LEN);
 	} else {
-		writew(msgs->len, i2c->base + OFFSET_TRANSFER_LEN);
+		writew(msg->len, i2c->base + OFFSET_TRANSFER_LEN);
 		writew(num, i2c->base + OFFSET_TRANSAC_LEN);
 	}
 
@@ -448,8 +473,8 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 	if (i2c->op == I2C_MASTER_RD) {
 		writel(I2C_DMA_INT_FLAG_NONE, i2c->pdmabase + OFFSET_INT_FLAG);
 		writel(I2C_DMA_CON_RX, i2c->pdmabase + OFFSET_CON);
-		rpaddr = dma_map_single(i2c->dev, msgs->buf,
-					msgs->len, DMA_FROM_DEVICE);
+		rpaddr = dma_map_single(i2c->dev, msg->buf, msg->len,
+					DMA_FROM_DEVICE);
 		if (dma_mapping_error(i2c->dev, rpaddr))
 			return -ENOMEM;
 
@@ -459,12 +484,13 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 		}
 
 		writel((u32)rpaddr, i2c->pdmabase + OFFSET_RX_MEM_ADDR);
-		writel(msgs->len, i2c->pdmabase + OFFSET_RX_LEN);
+		writel(msg->len, i2c->pdmabase + OFFSET_RX_LEN);
+		i2c_transac->rpaddr = rpaddr;
 	} else if (i2c->op == I2C_MASTER_WR) {
 		writel(I2C_DMA_INT_FLAG_NONE, i2c->pdmabase + OFFSET_INT_FLAG);
 		writel(I2C_DMA_CON_TX, i2c->pdmabase + OFFSET_CON);
-		wpaddr = dma_map_single(i2c->dev, msgs->buf,
-					msgs->len, DMA_TO_DEVICE);
+		wpaddr = dma_map_single(i2c->dev, msg->buf, msg->len,
+					DMA_TO_DEVICE);
 		if (dma_mapping_error(i2c->dev, wpaddr))
 			return -ENOMEM;
 
@@ -474,20 +500,21 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 		}
 
 		writel((u32)wpaddr, i2c->pdmabase + OFFSET_TX_MEM_ADDR);
-		writel(msgs->len, i2c->pdmabase + OFFSET_TX_LEN);
+		writel(msg->len, i2c->pdmabase + OFFSET_TX_LEN);
+
+		i2c_transac->wpaddr = wpaddr;
 	} else {
 		writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_INT_FLAG);
 		writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_CON);
-		wpaddr = dma_map_single(i2c->dev, msgs->buf,
-					msgs->len, DMA_TO_DEVICE);
+		wpaddr = dma_map_single(i2c->dev, msg->buf, msg->len,
+					DMA_TO_DEVICE);
 		if (dma_mapping_error(i2c->dev, wpaddr))
 			return -ENOMEM;
-		rpaddr = dma_map_single(i2c->dev, (msgs + 1)->buf,
-					(msgs + 1)->len,
-					DMA_FROM_DEVICE);
+		rpaddr = dma_map_single(i2c->dev, (msg + 1)->buf,
+					(msg + 1)->len, DMA_FROM_DEVICE);
 		if (dma_mapping_error(i2c->dev, rpaddr)) {
-			dma_unmap_single(i2c->dev, wpaddr,
-					 msgs->len, DMA_TO_DEVICE);
+			dma_unmap_single(i2c->dev, wpaddr, msg->len,
+					 DMA_TO_DEVICE);
 			return -ENOMEM;
 		}
 
@@ -501,8 +528,11 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 
 		writel((u32)wpaddr, i2c->pdmabase + OFFSET_TX_MEM_ADDR);
 		writel((u32)rpaddr, i2c->pdmabase + OFFSET_RX_MEM_ADDR);
-		writel(msgs->len, i2c->pdmabase + OFFSET_TX_LEN);
-		writel((msgs + 1)->len, i2c->pdmabase + OFFSET_RX_LEN);
+		writel(msg->len, i2c->pdmabase + OFFSET_TX_LEN);
+		writel((msg + 1)->len, i2c->pdmabase + OFFSET_RX_LEN);
+
+		i2c_transac->wpaddr = wpaddr;
+		i2c_transac->rpaddr = rpaddr;
 	}
 
 	writel(I2C_DMA_START_EN, i2c->pdmabase + OFFSET_EN);
@@ -516,40 +546,6 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
 	}
 	writew(start_reg, i2c->base + OFFSET_START);
 
-	ret = wait_for_completion_timeout(&i2c->msg_complete,
-					  i2c->adap.timeout);
-
-	/* Clear interrupt mask */
-	writew(~(restart_flag | I2C_HS_NACKERR | I2C_ACKERR |
-	       I2C_TRANSAC_COMP), i2c->base + OFFSET_INTR_MASK);
-
-	if (i2c->op == I2C_MASTER_WR) {
-		dma_unmap_single(i2c->dev, wpaddr,
-				 msgs->len, DMA_TO_DEVICE);
-	} else if (i2c->op == I2C_MASTER_RD) {
-		dma_unmap_single(i2c->dev, rpaddr,
-				 msgs->len, DMA_FROM_DEVICE);
-	} else {
-		dma_unmap_single(i2c->dev, wpaddr, msgs->len,
-				 DMA_TO_DEVICE);
-		dma_unmap_single(i2c->dev, rpaddr, (msgs + 1)->len,
-				 DMA_FROM_DEVICE);
-	}
-
-	if (ret == 0) {
-		dev_dbg(i2c->dev, "addr: %x, transfer timeout\n", msgs->addr);
-		mtk_i2c_init_hw(i2c);
-		return -ETIMEDOUT;
-	}
-
-	completion_done(&i2c->msg_complete);
-
-	if (i2c->irq_stat & (I2C_HS_NACKERR | I2C_ACKERR)) {
-		dev_dbg(i2c->dev, "addr: %x, transfer ACK error\n", msgs->addr);
-		mtk_i2c_init_hw(i2c);
-		return -ENXIO;
-	}
-
 	return 0;
 }
 
@@ -557,21 +553,28 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
 			    struct i2c_msg msgs[], int num)
 {
 	int ret;
-	int left_num = num;
 	struct mtk_i2c *i2c = i2c_get_adapdata(adap);
+	struct mtk_i2c_transaction *i2c_transac = &i2c->transac;
+
+	i2c_transac->num = num;
+	i2c_transac->index = 0;
+	i2c_transac->msgs = msgs;
+	i2c_transac->result = 0;
+
+	reinit_completion(&i2c->msg_complete);
 
 	ret = mtk_i2c_clock_enable(i2c);
 	if (ret)
 		return ret;
 
+	i2c->op = 0;
 	i2c->auto_restart = i2c->dev_comp->auto_restart;
 
 	/* checking if we can skip restart and optimize using WRRD mode */
-	if (i2c->auto_restart && num == 2) {
-		if (!(msgs[0].flags & I2C_M_RD) && (msgs[1].flags & I2C_M_RD) &&
-		    msgs[0].addr == msgs[1].addr) {
-			i2c->auto_restart = 0;
-		}
+	if (num == 2 && !(msgs[0].flags & I2C_M_RD) &&
+	    (msgs[1].flags & I2C_M_RD) && msgs[0].addr == msgs[1].addr) {
+		i2c->op = I2C_MASTER_WRRD;
+		i2c->auto_restart = 0;
 	}
 
 	if (i2c->auto_restart && num >= 2 && i2c->speed_hz > MAX_FS_MODE_SPEED)
@@ -582,33 +585,33 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
 	else
 		i2c->ignore_restart_irq = false;
 
-	while (left_num--) {
-		if (!msgs->buf) {
-			dev_dbg(i2c->dev, "data buffer is NULL.\n");
-			ret = -EINVAL;
-			goto err_exit;
-		}
+	/* always use DMA mode. */
+	ret = mtk_i2c_start_transfer(i2c);
+	if (ret < 0)
+		goto err_exit;
 
-		if (msgs->flags & I2C_M_RD)
-			i2c->op = I2C_MASTER_RD;
-		else
-			i2c->op = I2C_MASTER_WR;
-
-		if (!i2c->auto_restart) {
-			if (num > 1) {
-				/* combined two messages into one transaction */
-				i2c->op = I2C_MASTER_WRRD;
-				left_num--;
-			}
-		}
+	ret = wait_for_completion_timeout(&i2c->msg_complete,
+					  i2c->adap.timeout);
 
-		/* always use DMA mode. */
-		ret = mtk_i2c_do_transfer(i2c, msgs, num, left_num);
-		if (ret < 0)
-			goto err_exit;
+	if (ret == 0) {
+		dev_dbg(i2c->dev, "addr: %x, transfer timeout\n", msgs->addr);
+		mtk_i2c_init_hw(i2c);
+		ret = -ETIMEDOUT;
+		goto err_exit;
+	}
 
-		msgs++;
+	if (i2c->irq_stat & (I2C_HS_NACKERR | I2C_ACKERR)) {
+		dev_dbg(i2c->dev, "addr: %x, transfer ACK error\n", msgs->addr);
+		mtk_i2c_init_hw(i2c);
+		ret = -ENXIO;
+		goto err_exit;
+	}
+
+	if (i2c_transac->result) {
+		ret = i2c_transac->result;
+		goto err_exit;
 	}
+
 	/* the return value is number of executed messages */
 	ret = num;
 
@@ -621,29 +624,51 @@ static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id)
 {
 	struct mtk_i2c *i2c = dev_id;
 	u16 restart_flag = 0;
-	u16 intr_stat;
+	struct i2c_msg *msg;
+	struct mtk_i2c_transaction *i2c_transac = &i2c->transac;
 
 	if (i2c->auto_restart)
 		restart_flag = I2C_RS_TRANSFER;
 
-	intr_stat = readw(i2c->base + OFFSET_INTR_STAT);
-	writew(intr_stat, i2c->base + OFFSET_INTR_STAT);
+	/* Clear interrupt mask */
+	writew(~(restart_flag | I2C_HS_NACKERR | I2C_ACKERR |
+	       I2C_TRANSAC_COMP), i2c->base + OFFSET_INTR_MASK);
 
-	/*
-	 * when occurs ack error, i2c controller generate two interrupts
-	 * first is the ack error interrupt, then the complete interrupt
-	 * i2c->irq_stat need keep the two interrupt value.
-	 */
-	i2c->irq_stat |= intr_stat;
+	i2c->irq_stat = readw(i2c->base + OFFSET_INTR_STAT);
+	writew(i2c->irq_stat, i2c->base + OFFSET_INTR_STAT);
 
 	if (i2c->ignore_restart_irq && (i2c->irq_stat & restart_flag)) {
 		i2c->ignore_restart_irq = false;
 		i2c->irq_stat = 0;
+		/* Enable interrupt */
+		writew(restart_flag | I2C_HS_NACKERR | I2C_ACKERR |
+		       I2C_TRANSAC_COMP, i2c->base + OFFSET_INTR_MASK);
 		writew(I2C_RS_MUL_CNFG | I2C_RS_MUL_TRIG | I2C_TRANSAC_START,
 		       i2c->base + OFFSET_START);
 	} else {
-		if (i2c->irq_stat & (I2C_TRANSAC_COMP | restart_flag))
+		msg = &i2c_transac->msgs[i2c_transac->index];
+
+		if (i2c->op == I2C_MASTER_WR || i2c->op == I2C_MASTER_WRRD) {
+			dma_unmap_single(i2c->dev, i2c_transac->wpaddr,
+					 msg->len, DMA_TO_DEVICE);
+		}
+
+		if (i2c->op == I2C_MASTER_WRRD)
+			dma_unmap_single(i2c->dev, i2c_transac->rpaddr,
+					 (msg + 1)->len, DMA_FROM_DEVICE);
+
+		if (i2c->op == I2C_MASTER_RD)
+			dma_unmap_single(i2c->dev, i2c_transac->rpaddr,
+					 msg->len, DMA_FROM_DEVICE);
+
+		if (i2c->irq_stat & ~restart_flag) {
 			complete(&i2c->msg_complete);
+		} else {
+			i2c_transac->index++;
+			i2c_transac->result = mtk_i2c_start_transfer(i2c);
+			if (i2c_transac->result)
+				complete(&i2c->msg_complete);
+		}
 	}
 
 	return IRQ_HANDLED;
-- 
1.8.1.1.dirty



From xuejiancheng at huawei.com  Thu Feb 25 17:54:25 2016
From: xuejiancheng at huawei.com (xuejiancheng)
Date: Fri, 26 Feb 2016 09:54:25 +0800
Subject: [PATCH v9 2/6] clk: hisilicon: add CRG driver for hi3519 soc
In-Reply-To: <20160225234215.GK28849@codeaurora.org>
References: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
 <1456127280-23275-3-git-send-email-xuejiancheng@huawei.com>
 <20160225234215.GK28849@codeaurora.org>
Message-ID: <56CFB051.3050809@huawei.com>

Hi Stephen,
    Thank you for your advice.  I'll fixed them in next version.

Regards,

Jiancheng.

On 2016/2/26 7:42, Stephen Boyd wrote:
> On 02/22, Jiancheng Xue wrote:
>> diff --git a/Documentation/devicetree/bindings/clock/hi3519-crg.txt b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
>> new file mode 100644
>> index 0000000..2d23950
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
>> @@ -0,0 +1,46 @@
>> +Example: CRG nodes
>> +CRG: clock-reset-controller at 12010000 {
>> +	compatible = "hisilicon,hi3519-crg";
> 
> Indentation is off here.
> 
>> +        reg = <0x12010000 0x10000>;
>> +        #clock-cells = <1>;
>> +        #reset-cells = <2>;
>> +};
>> +
>> +Example: consumer nodes
>> +i2c0: i2c at 12110000 {
>> +	compatible = "hisilicon,hi3519-i2c";
>> +        reg = <0x12110000 0x1000>;
>> +        clocks = <&CRG HI3519_I2C0_RST>;*/
>> +        resets = <&CRG 0xe4 0>;
>> +};
>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>> index e434854..296371f 100644
>> --- a/drivers/clk/hisilicon/Kconfig
>> +++ b/drivers/clk/hisilicon/Kconfig
>> @@ -1,3 +1,11 @@
>> +config COMMON_CLK_HI3519
>> +	tristate "Hi3519 Clock Driver"
>> +	depends on ARCH_HISI || COMPILE_TEST
>> +	select RESET_HISI
>> +	default y
> 
> default ARCH_HISI
> 
>> +	help
>> +	  Build the clock driver for hi3519.
>> +
>> diff --git a/drivers/clk/hisilicon/reset.c b/drivers/clk/hisilicon/reset.c
>> new file mode 100644
>> index 0000000..50e00e7
>> --- /dev/null
>> +++ b/drivers/clk/hisilicon/reset.c
>> +
>> +int hisi_reset_init(struct device_node *np)
>> +{
>> +	struct hisi_reset_controller *rstc;
>> +
>> +	rstc = kzalloc(sizeof(*rstc), GFP_KERNEL);
>> +	if (!rstc)
>> +		return -ENOMEM;
>> +
>> +	rstc->membase = of_iomap(np, 0);
> 
> Any reason why we can't pass the platform device here and map the
> register space with platform device APIs?
> 
>> +	if (!rstc->membase)
>> +		return -EINVAL;
>> +
>> +	spin_lock_init(&rstc->lock);
>> +
>> +	rstc->rcdev.owner = THIS_MODULE;
>> +	rstc->rcdev.ops = &hisi_reset_ops;
>> +	rstc->rcdev.of_node = np;
>> +	rstc->rcdev.of_reset_n_cells = 2;
>> +	rstc->rcdev.of_xlate = hisi_reset_of_xlate;
>> +
>> +	return reset_controller_register(&rstc->rcdev);
>> +}
>> +EXPORT_SYMBOL(hisi_reset_init);
> 
> Why not GPL?
> 



From broonie at kernel.org  Thu Feb 25 18:10:19 2016
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Feb 2016 11:10:19 +0900
Subject: [PATCH V7 2/2] regulator: mt6323: Add support for MT6323 regulator
In-Reply-To: <1456396631-12788-2-git-send-email-blogic@openwrt.org>
References: <1456396631-12788-1-git-send-email-blogic@openwrt.org>
 <1456396631-12788-2-git-send-email-blogic@openwrt.org>
Message-ID: <20160226021019.GD18327@sirena.org.uk>

On Thu, Feb 25, 2016 at 11:37:11AM +0100, John Crispin wrote:

> This patch needs to be merged post-rc1 as it depends on the MFD series of
> the PMIC which is already inside Lee's tree pending the PR.

Please resubmit when that has happened or arrange with Lee (who I've
added to the CC) for a tag I can pull with the required dependencies.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160226/b10afa9b/attachment.sig>

From xinliang.liu at linaro.org  Thu Feb 25 18:21:56 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri, 26 Feb 2016 10:21:56 +0800
Subject: [PATCH v5 01/11] drm/hisilicon: Add device tree binding for
 hi6220 display subsystem
In-Reply-To: <CAGd==06LUCn74K18njP8+R-83tJ6OOjmwqmx9MFS=AQyVioFZQ@mail.gmail.com>
References: <1456196431-19923-1-git-send-email-xinliang.liu@linaro.org>
 <1456196431-19923-2-git-send-email-xinliang.liu@linaro.org>
 <20160223183726.GA10246@leverpostej>
 <CAGd==06LUCn74K18njP8+R-83tJ6OOjmwqmx9MFS=AQyVioFZQ@mail.gmail.com>
Message-ID: <CAGd==04yQRamgTmd90LU=TOBCSz-AS-+ffpUyvO=y8dQ6d_L=g@mail.gmail.com>

On 25 February 2016 at 10:21, Xinliang Liu <xinliang.liu at linaro.org> wrote:
> On 24 February 2016 at 02:37, Mark Rutland <mark.rutland at arm.com> wrote:
> Hi Mark, thanks for review.
>
>> On Tue, Feb 23, 2016 at 11:00:21AM +0800, Xinliang Liu wrote:
>>> Add ADE display controller binding doc.
>>> Add DesignWare DSI Host Controller v1.20a binding doc.
>>>
>>> v5:
>>> - Remove endpoint unit address of dsi output port.
>>> - Add "hisilicon,noc-syscon" property for ADE NOC QoS syscon.
>>> - Add "resets" property for ADE reset.
>>> v4:
>>> - Describe more specific of clocks and ports.
>>> - Fix indentation.
>>> v3:
>>> - Make ade as the drm master node.
>>> - Use assigned-clocks to set clock rate.
>>> - Use ports to connect display relavant nodes.
>>> v2:
>>> - Move dt binding docs to bindings/display/hisilicon directory.
>>>
>>> Signed-off-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
>>> Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
>>> ---
>>>  .../bindings/display/hisilicon/dw-dsi.txt          | 72 ++++++++++++++++++++++
>>>  .../bindings/display/hisilicon/hisi-ade.txt        | 64 +++++++++++++++++++
>>>  2 files changed, 136 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>>>  create mode 100644 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>>> new file mode 100644
>>> index 000000000000..0d234b5e19af
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
>>> @@ -0,0 +1,72 @@
>>> +Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
>>> +
>>> +A DSI Host Controller resides in the middle of display controller and external
>>> +HDMI converter or panel.
>>> +
>>> +Required properties:
>>> +- compatible: value should be "hisilicon,hi6220-dsi".
>>> +- reg: physical base address and length of dsi controller's registers.
>>> +- clocks: the clocks needed.
>>> +- clock-names: the name of the clocks.
>>
>> You _must_ specify the precise set of clock names you expect here.
>>
>> Per the example, you seem to expect "pclk_dsi".
>>
>> Is that the name given in the DSI controller manual? Or is it just
>> "pclk"? It's already specific to the DSI controller...
>>

Yet, while reading the DSI controller manual. It is called "pclk".
Yes, you are right this is already specific to the DSI controller.
will use "pclk" instead in next version.

>
> I have read the SoC manual again, and it is the configuration clock.
> Maybe we can call it "cfg_clk".



>
>>> diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>>> new file mode 100644
>>> index 000000000000..c1844b3ff878
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
>>> @@ -0,0 +1,64 @@
>>> +Device-Tree bindings for hisilicon ADE display controller driver
>>> +
>>> +ADE (Advanced Display Engine) is the display controller which grab image
>>> +data from memory, do composition, do post image processing, generate RGB
>>> +timing stream and transfer to DSI.
>>> +
>>> +Required properties:
>>> +- compatible: value should be "hisilicon,hi6220-ade".
>>> +- reg: physical base address and length of the ADE controller's registers.
>>> +  Value should be "<0x0 0xf4100000 0x0 0x7800>".
>>
>> Get rid of the "Value should be ... " part. It is nonsensical to
>> describe this in the binding. Just describe what this is with relation
>> to _this_ IP block.
>
> OK, will fix all these parts in next version.
>
>>
>>> +- reg-names: name of physical base. Value should be "ade_base".
>>
>> That obviously doesn't apply to *-names propertiesm which must all be
>> specified in the binding (they're local to the device rather than
>> remote).
>>
>>> +- hisilicon,noc-syscon: ADE NOC QoS syscon. Value should be "<&medianoc_ade>"
>>> +- resets: The ADE reset controller node. Value should be "<&media_ctrl
>>> +  MEDIA_ADE>".
>>
>> Likewise.
>>
>>> +- interrupt: the ldi vblank interrupt number used.
>>> +- clocks: the clocks needed. Three clocks are used in ADE driver:
>>> +  ADE core clock, value should be "<&media_ctrl HI6220_ADE_CORE>";
>>> +  ADE pixel clok, value should be "<&media_ctrl HI6220_ADE_PIX_SRC>";
>>> +  media NOC QoS clock, value should be "<&media_ctrl HI6220_CODEC_JPEG>".
>>> +- clock-names: the name of the clocks. Values should be "clk_ade_core",
>>> +  "clk_codec_jpeg" and "clk_ade_pix".
>>
>> Likewise, don't specify the value.
>>
>> Jsut define clocks in terms of clock-names, e.g.
>>
>> - clocks: a list of phandle + clock-specifier pairs, one for each entry
>>   in clock-names.
>> - clock-names: should contain:
>>   * "clk_ade_core" for the ADE ciore clock
>>   * ...
>>   * ...
>
> All right, got it. Thanks for teaching me how to to.
>
>>
>>> +- assigned-clocks: clocks to be assigned rate.
>>> +- assigned-clock-rates: clock rates which are assigned to assigned-clocks.
>>> +  The rate of <&media_ctrl HI6220_ADE_CORE> could be "360000000" or
>>> +  "180000000";
>>> +  The rate of <&media_ctrl HI6220_CODEC_JPEG> could be less than "1440000000".
>>
>> Is this strictly necessary? Why can the druiver not configure this?
>>
>> Does this have to match some pre-existing boot-time configuration?
>
> This is the maximum configuration value due to the parent clk and divider.
> And there is no pre-existing boot-time configuration about this.
> Driver could configure the value according to the performance and
> power consumption.
>
> Thanks,
> -xinliang
>
>>
>> Thanks,
>> Mark.


From broonie at kernel.org  Thu Feb 25 18:30:21 2016
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Feb 2016 11:30:21 +0900
Subject: [PATCH 1/4] ASoC: wm9713: add binding for WM9713 codec
In-Reply-To: <87povkuuf6.fsf@belgarion.home>
References: <1455979079-9030-1-git-send-email-robert.jarzmik@free.fr>
 <20160220171459.GA18327@sirena.org.uk>
 <871t87z1gz.fsf@belgarion.home>
 <20160220195925.GF18327@sirena.org.uk>
 <87twl3xgud.fsf@belgarion.home>
 <20160220211659.GG18327@sirena.org.uk>
 <878u2fxbp9.fsf@belgarion.home>
 <20160221014920.GK18327@sirena.org.uk>
 <87povkuuf6.fsf@belgarion.home>
Message-ID: <20160226023021.GH18327@sirena.org.uk>

On Fri, Feb 26, 2016 at 02:33:49AM +0100, Robert Jarzmik wrote:
> Mark Brown <broonie at kernel.org> writes:

> > It will not be called, the generic AC'97 code will be used.

> Ok, if it's not called no code in sound/soc/codecs/wm9713.c will be used, right
> ?
> In that case wm9713_set_dai_clkdiv() will never be used, nor will the
> wm9713_audio_map or wm9713_dapm_widgets be created, which will break all
> userspace programs relying on these mixers and DAPM routes.

> Or am I missing something ?

No, you're not missing anything - that'll be what happens.  If you need
to preserve the userspace ABI on your board you'd need a much bigger
(but very welcome) refactoring of the AC'97 code to be less hacky and
use the device model more directly, or at least define a generic AC'97
binding somehow.  All the AC'97 support has never really been properly
moved over to the device model and unfortunately nobody's yet cared
about it for device tree except in the simple cases supported by the
generic AC'97 code.  I appreciate that this isn't very helpful, it's
an unfortunate consequence of DT as an ABI.

We probably want to end up with something like what the Intel folks have
been doing recently for HDA to get that working within ASoC.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160226/1af330dd/attachment.sig>

From broonie at kernel.org  Thu Feb 25 18:30:50 2016
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Feb 2016 11:30:50 +0900
Subject: [PATCH] ASoC: mediatek: Add I03/I04 widgets and corresponding
 routes
In-Reply-To: <1456384353-13041-1-git-send-email-pc.liao@mediatek.com>
References: <1456384353-13041-1-git-send-email-pc.liao@mediatek.com>
Message-ID: <20160226023050.GI18327@sirena.org.uk>

On Thu, Feb 25, 2016 at 03:12:33PM +0800, PC Liao wrote:

> Change-Id: Ib6804bbbde388830d8359245fe13bbb0f2bb36ba

Don't include noise like this in upstream submissions, we don't use your
gerritt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160226/a74cc38f/attachment.sig>

From xuejiancheng at huawei.com  Thu Feb 25 18:17:51 2016
From: xuejiancheng at huawei.com (xuejiancheng)
Date: Fri, 26 Feb 2016 10:17:51 +0800
Subject: [PATCH v9 2/6] clk: hisilicon: add CRG driver for hi3519 soc
In-Reply-To: <20160225234215.GK28849@codeaurora.org>
References: <1456127280-23275-1-git-send-email-xuejiancheng@huawei.com>
 <1456127280-23275-3-git-send-email-xuejiancheng@huawei.com>
 <20160225234215.GK28849@codeaurora.org>
Message-ID: <56CFB5CF.2050800@huawei.com>

Hi Stephen,

On 2016/2/26 7:42, Stephen Boyd wrote:
>> diff --git a/drivers/clk/hisilicon/reset.c b/drivers/clk/hisilicon/reset.c
>> new file mode 100644
>> index 0000000..50e00e7
>> --- /dev/null
>> +++ b/drivers/clk/hisilicon/reset.c
>> +
>> +int hisi_reset_init(struct device_node *np)
>> +{
>> +	struct hisi_reset_controller *rstc;
>> +
>> +	rstc = kzalloc(sizeof(*rstc), GFP_KERNEL);
>> +	if (!rstc)
>> +		return -ENOMEM;
>> +
>> +	rstc->membase = of_iomap(np, 0);
> 
> Any reason why we can't pass the platform device here and map the
> register space with platform device APIs?
> 
This function can be called by other clock drivers except clk-hi3519. Some
clock drivers may not be registered as platform drivers. Moreover this function
may be called early even before platform_bus_init.

Thank you!

Regards,
Jiancheng.



From pc.liao at mediatek.com  Thu Feb 25 18:41:56 2016
From: pc.liao at mediatek.com (PC Liao)
Date: Fri, 26 Feb 2016 10:41:56 +0800
Subject: [PATCH] ASoC: mediatek: Add I03/I04 widgets and corresponding
 routes
In-Reply-To: <20160226023050.GI18327@sirena.org.uk>
References: <1456384353-13041-1-git-send-email-pc.liao@mediatek.com>
 <20160226023050.GI18327@sirena.org.uk>
Message-ID: <1456454516.15436.2.camel@mtksdaap41>

Hi Mark,

On Fri, 2016-02-26 at 10:30 +0800, Mark Brown wrote:
> On Thu, Feb 25, 2016 at 03:12:33PM +0800, PC Liao wrote:
> 
> > Change-Id: Ib6804bbbde388830d8359245fe13bbb0f2bb36ba
> 
> Don't include noise like this in upstream submissions, we don't use your
> gerritt.

Sorry about that.
I will upload new version.
Thanks!




From boris.brezillon at free-electrons.com  Thu Feb 25 18:16:00 2016
From: boris.brezillon at free-electrons.com (Boris Brezillon)
Date: Fri, 26 Feb 2016 03:16:00 +0100
Subject: [PATCH v3 00/52] mtd: rework ECC layout definition
In-Reply-To: <d968b867f4d7f603581a0ff83e07c15c@agner.ch>
References: <1456448280-27788-1-git-send-email-boris.brezillon@free-electrons.com>
 <d968b867f4d7f603581a0ff83e07c15c@agner.ch>
Message-ID: <20160226031600.15ad27ba@bbrezillon>

On Thu, 25 Feb 2016 17:27:23 -0800
Stefan Agner <stefan at agner.ch> wrote:

> Hi Boris,
> 
> On 2016-02-25 16:57, Boris Brezillon wrote:
> > Hello,
> > 
> > This patchset aims at getting rid of the nand_ecclayout limitations.
> > struct nand_ecclayout is defining fixed eccpos and oobfree arrays which
> > can only be increased by modifying the MTD_MAX_ECCPOS_ENTRIES_LARGE and
> > MTD_MAX_OOBFREE_ENTRIES_LARGE macros.
> > This approach forces us to modify the macro values each time we add a
> > new NAND chip with a bigger OOB area, and increasing these arrays also
> > penalize all platforms, even those who only support small NAND devices
> > (with small OOB area).
> > 
> > The idea to overcome this limitation, is to define the ECC/OOB layout
> > by the mean of two functions: ->ecc() and ->free(), which will
> > basically return the same information has those stored in the
> > nand_ecclayout struct.
> > 
> > Another advantage of this solution is that ECC layouts are usually
> > following a repetitive pattern (i.e. leave X bytes free and put Y bytes
> > of ECC per ECC chunk), which allows one to implement the ->ecc()
> > and ->free() functions with a simple logic that can be applied
> > to any size of OOB.
> > 
> > Patches 1 to 4 are just cleanups or trivial fixes that can be taken
> > independently.
> > 
> > Also note that the last two commits are removing the nand_ecclayout
> > definition, thus preventing any new driver to use this structure.
> > Of course, this step can be delayed if some of the previous patches
> > are not accepted.
> 
> Is the patch set somewhere available to pull from?

Yes, it's here [1].

> 
> Do I see things right that patch 21/52 contains the crucial function
> nand_ooblayout_ecc_lp which calculate the ECC position? (for those who
> do not provide mtd_ooblayout_ops anyway...)

You're correct. This implementation is here for NAND controller drivers
relying on the linux default ECC layout (the one used when soft ECC is
selected, or when not layout is specified). This layout is just putting
all ECC bytes at the end of the OOB area.

[1]https://github.com/bbrezillon/linux-0day/tree/nand/ecclayout

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


From dhdang at apm.com  Thu Feb 25 18:51:58 2016
From: dhdang at apm.com (Duc Dang)
Date: Thu, 25 Feb 2016 18:51:58 -0800
Subject: [GIT PULL 1/2] arm64: X-Gene platforms DTS changes queued for v4.6 -
 part1
Message-ID: <CADaLND=vwMXG5EcWpnKYODABcXkToiW_kF6s_disLmUknZx_Vw@mail.gmail.com>

Hi Arnd, Olof,

This is the first part of DT changes on X-Gene platforms for v4.6 with
below information:

+ "arm64: dts: apm: Update Merlin DT PCP PLL clock node for v2
hardware" is the 3rd patch of the series
http://www.spinics.net/lists/arm-kernel/msg475481.html, which was also
accepted.

+ "arm64: dts: apm: Update X-Gene standby GPIO controller DTS entries"
is the 3rd patch of the series
http://www.spinics.net/lists/arm-kernel/msg483918.html, which was
already accepted.
The 3 remaining patches are the follow up of the same "Enable X-Gene
standby GPIO as  interrupt controller" series to update standby GPIO
controller for X-Gene v2 and power button GPIO on both X-Gene v1 and
v2 platforms

Regards,
Duc Dang.
------

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

  https://github.com/AppliedMicro/xgene-next.git tags/xgene-dts-for-v4.6-part1

for you to fetch changes up to edf21f271024ec6adb93c7b4e6c1dc928b6a7250:

  arm64: dts: apm: Update GPIO to control power-off on X-Gene v2
platforms (2016-02-25 17:14:00 -0800)

----------------------------------------------------------------
First part of X-Gene DT changes queued for v4.6

This patch set includes:
+ A change in compatible string of X-Gene v2 SoC
PLL DT node to reflect the v2 hardware
+ Update DT fields for X-Gene v1 and v2 standby
GPIO controllers
+ Update declaration of power button GPIO for
X-Gene v1 and X-Gene v2 platforms

----------------------------------------------------------------
Duc Dang (3):
      arm64: dts: apm: Update GPIO to control power-off on X-Gene v1 platforms
      arm64: dts: apm: Update GPIO standby controller DT node for
X-Gene v2 platforms
      arm64: dts: apm: Update GPIO to control power-off on X-Gene v2 platforms

Loc Ho (1):
      arm64: dts: apm: Update Merlin DT PCP PLL clock node for v2 hardware

Quan Nguyen (1):
      arm64: dts: apm: Update X-Gene standby GPIO controller DTS entries

 arch/arm64/boot/dts/apm/apm-merlin.dts     | 3 ++-
 arch/arm64/boot/dts/apm/apm-mustang.dts    | 3 ++-
 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 8 +++++++-
 arch/arm64/boot/dts/apm/apm-storm.dtsi     | 3 +++
 4 files changed, 14 insertions(+), 3 deletions(-)


From dhdang at apm.com  Thu Feb 25 18:51:59 2016
From: dhdang at apm.com (Duc Dang)
Date: Thu, 25 Feb 2016 18:51:59 -0800
Subject: [GIT PULL 2/2] arm64: X-Gene platforms DTS changes queued for v4.6 -
 part2
Message-ID: <CADaLNDkF8_DVYWPFtGU8tYsbbxDWZF9tozW=Zs3EuV4BqO6OuA@mail.gmail.com>

Hi Arnd, Olof,

This is the second part of DT changes on X-Gene platforms for v4.6,
which enables mailbox driver for X-Gene v2 platforms and also enable
SLIMpro Mailbox I2C driver (a client of the mailbox driver) for both
X-Gene v1 and v2 platforms.

This series depends on the 3rd patch
(http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/apm?id=be9c09bcca039d6df9ec736989cdafc68c93fed4)
of the series "mailbox: Add APM X-Gene platform mailbox driver"
(https://lkml.org/lkml/2016/2/12/749), which was already in linux-next
since Feb-15.

Hi Jassi,

Are you going to get the 3rd patch (dts patch) of series "mailbox: Add
APM X-Gene platform mailbox driver" to your tree? Otherwise, I will
need to create another pull request for Arnd and Olof.

Regards,
Duc Dang.
------

The following changes since commit b0e4563c2f6d939a124f06e10b205151bbac487c:

  arm64: dts: apm: mailbox device tree node for APM X-Gene platform.
(2016-02-25 17:14:01 -0800)

are available in the git repository at:

  https://github.com/AppliedMicro/xgene-next.git tags/xgene-dts-for-v4.6-part2

for you to fetch changes up to 406f5940549e78fd7d4d41413a7ed3e611bccc4f:

  arm64: dts: apm: Add DT node for X-Gene v2 SLIMpro Mailbox I2C
Driver (2016-02-25 17:14:04 -0800)

----------------------------------------------------------------
Second part of X-Gene DT changes queued for v4.6

This patch set includes:
+ X-Gene v2 Mailbox DT node
+ X-Gene v1 and X-Gene v2 SLIMpro Mailbox
I2C driver DT nodes

----------------------------------------------------------------
Duc Dang (3):
      arm64: dts: apm: Add DT node for X-Gene v1 SLIMpro Mailbox I2C Driver
      arm64: dts: apm: Mailbox device tree node for APM X-Gene v2 platform.
      arm64: dts: apm: Add DT node for X-Gene v2 SLIMpro Mailbox I2C Driver

 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 19 +++++++++++++++++++
 arch/arm64/boot/dts/apm/apm-storm.dtsi     |  5 +++++
 2 files changed, 24 insertions(+)


From broonie at kernel.org  Thu Feb 25 19:04:11 2016
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Feb 2016 12:04:11 +0900
Subject: next-20160225 build: 2 failures 44 warnings (next-20160225)
In-Reply-To: <E1aYsmb-0006qb-76@optimist>
References: <E1aYsmb-0006qb-76@optimist>
Message-ID: <20160226030411.GK18327@sirena.org.uk>

On Thu, Feb 25, 2016 at 10:04:29AM +0000, Build bot for Mark Brown wrote:

Today's -next fails to build an arm64 allmodconfig due to:

> 	arm64-allmodconfig
> ../drivers/pci/host/pci-mvebu.c:755:12: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
> ../drivers/pci/host/pci-mvebu.c:855:31: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
> ../drivers/pci/host/pci-mvebu.c:904:16: error: storage size of 'hw' isn't known
> ../drivers/pci/host/pci-mvebu.c:919:2: error: implicit declaration of function 'pci_common_init_dev' [-Werror=implicit-function-declaration]
> ../drivers/pci/host/pci-mvebu.c:1282:3: error: implicit declaration of function 'pci_ioremap_io' [-Werror=implicit-function-declaration]

caused by b4f596b19624 (arm64: add mvebu architecture entry) which
enables MVBEU on arm64, the commit was present for a little while and
the error cropped up but didn't get reported due to other things masking
it.  This looks like the driver needs modernization and probably ought
to have a !ARM64 dependency for now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160226/1f18ad67/attachment.sig>

From broonie at kernel.org  Thu Feb 25 19:09:49 2016
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Feb 2016 12:09:49 +0900
Subject: next-20160225 build: 2 failures 44 warnings (next-20160225)
In-Reply-To: <E1aYsmb-0006qb-76@optimist>
References: <E1aYsmb-0006qb-76@optimist>
Message-ID: <20160226030949.GL18327@sirena.org.uk>

On Thu, Feb 25, 2016 at 10:04:29AM +0000, Build bot for Mark Brown wrote:

Today's -next fails to build an arm64 allmodconfig due to:

> 	arm64-allmodconfig
> ../drivers/watchdog/orion_wdt.c:109:2: error: implicit declaration of function 'atomic_io_modify' [-Werror=implicit-function-declaration]

also caused by b4f596b19624 (arm64: add mvebu architecture entry) which
enables MVBEU on arm64, the commit was present for a little while and
the error cropped up but didn't get reported due to other things masking
it.  atomic_io_modify() is only available on ARM, I'm unsure if this
needs a driver change or if the driver is just specific to older
hardware anyway.  The code is only used in the init path accessing what
look to be device specific registers so I'm not 100% clear why it
specifically needs to be an atomic modify.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160226/23d7bd97/attachment.sig>

From broonie at kernel.org  Thu Feb 25 19:10:52 2016
From: broonie at kernel.org (Mark Brown)
Date: Fri, 26 Feb 2016 12:10:52 +0900
Subject: [PATCH] ASoC: mediatek: Add I03/I04 widgets and corresponding
 routes
In-Reply-To: <1456454516.15436.2.camel@mtksdaap41>
References: <1456384353-13041-1-git-send-email-pc.liao@mediatek.com>
 <20160226023050.GI18327@sirena.org.uk>
 <1456454516.15436.2.camel@mtksdaap41>
Message-ID: <20160226031052.GM18327@sirena.org.uk>

On Fri, Feb 26, 2016 at 10:41:56AM +0800, PC Liao wrote:
> On Fri, 2016-02-26 at 10:30 +0800, Mark Brown wrote:
> > On Thu, Feb 25, 2016 at 03:12:33PM +0800, PC Liao wrote:

> > > Change-Id: Ib6804bbbde388830d8359245fe13bbb0f2bb36ba

> > Don't include noise like this in upstream submissions, we don't use your
> > gerritt.

> Sorry about that.
> I will upload new version.

It's fine, I edited out - more for future reference.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160226/1a566e44/attachment.sig>

From jay.xu at rock-chips.com  Thu Feb 25 19:12:18 2016
From: jay.xu at rock-chips.com (Jianqun Xu)
Date: Fri, 26 Feb 2016 11:12:18 +0800
Subject: [PATCH v2 0/3] Rockchip: rk3399: Add core dtsi for rk3399
In-Reply-To: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
References: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1456456341-14282-1-git-send-email-jay.xu@rock-chips.com>

There is the new SoCs from Rockchip which named rk3399, the
patches are added to support them.

Jianqun Xu (1):
  ARM64: dts: rockchip: add core dtsi file for rk3399

Xing Zheng (2):
  dt-bindings: add bindings for rk3399 clock controller
  clk: rockchip: add dt-binding header for rk3399

 .../bindings/clock/rockchip,rk3399-cru.txt         |  82 ++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           | 950 +++++++++++++++++++++
 include/dt-bindings/clock/rk3399-cru.h             | 716 ++++++++++++++++
 3 files changed, 1748 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
 create mode 100644 include/dt-bindings/clock/rk3399-cru.h

-- 
changes in v2:
- remove applied grf patch (applied by Heiko)
- add "rockchip,grf = <&pmugrf>" for pmucru node (xing)
- add NR_CLK defination (xing)

1.9.1




From jay.xu at rock-chips.com  Thu Feb 25 19:12:19 2016
From: jay.xu at rock-chips.com (Jianqun Xu)
Date: Fri, 26 Feb 2016 11:12:19 +0800
Subject: [PATCH v2 1/3] dt-bindings: add bindings for rk3399 clock controller
In-Reply-To: <1456456341-14282-1-git-send-email-jay.xu@rock-chips.com>
References: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
 <1456456341-14282-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1456456341-14282-2-git-send-email-jay.xu@rock-chips.com>

From: Xing Zheng <zhengxing at rock-chips.com>

Add devicetree bindings for Rockchip cru which found on
Rockchip SoCs.

Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v2:
- none

 .../bindings/clock/rockchip,rk3399-cru.txt         | 82 ++++++++++++++++++++++
 1 file changed, 82 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt

diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
new file mode 100644
index 0000000..07bcc6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
@@ -0,0 +1,82 @@
+* Rockchip RK3399 Clock and Reset Unit
+
+The RK3399 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: PMU for CRU should be "rockchip,rk3399-pmucru"
+- compatible: CRU should be "rockchip,rk3399-cru"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+  If missing, pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "xin32k" - rtc clock - optional,
+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_gmac" - external GMAC clock - optional
+ - "ext_hsadc" - external HSADC clock - optional,
+ - "ext_isp" - external ISP clock - optional,
+ - "ext_jtag" - external JTAG clock - optional
+ - "ext_vip" - external VIP clock - optional,
+ - "usbotg_out" - output clock of the pll in the otg phy
+
+Example: General Register Files
+
+	pmugrf: syscon at ff320000 {
+		compatible = "rockchip,rk3399-pmugrf", "syscon";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+	};
+
+	grf: syscon at ff770000 {
+		compatible = "rockchip,rk3399-grf", "syscon";
+		reg = <0x0 0xff770000 0x0 0x10000>;
+	};
+
+Example: Clock controller node:
+
+	pmucru: pmu-clock-controller at ff750000 {
+		compatible = "rockchip,rk3399-pmucru";
+		reg = <0x0 0xff750000 0x0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at ff760000 {
+		compatible = "rockchip,rk3399-cru";
+		reg = <0x0 0xff760000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller:
+
+	uart0: serial at ff1a0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff180000 0x0 0x100>;
+		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+	};
-- 
1.9.1




From jay.xu at rock-chips.com  Thu Feb 25 19:12:20 2016
From: jay.xu at rock-chips.com (Jianqun Xu)
Date: Fri, 26 Feb 2016 11:12:20 +0800
Subject: [PATCH v2 2/3] clk: rockchip: add dt-binding header for rk3399
In-Reply-To: <1456456341-14282-1-git-send-email-jay.xu@rock-chips.com>
References: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
 <1456456341-14282-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1456456341-14282-3-git-send-email-jay.xu@rock-chips.com>

From: Xing Zheng <zhengxing at rock-chips.com>

Add the dt-bindings header for the rk3399, that gets shared between
the clock controller and the clock references in the dts.

Acked-by: Rob Herring <robh at kernel.org>
Signed-off-by: Xing Zheng <zhengxing at rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v2:
- add NR_CLK defination (xing)

 include/dt-bindings/clock/rk3399-cru.h | 716 +++++++++++++++++++++++++++++++++
 1 file changed, 716 insertions(+)
 create mode 100644 include/dt-bindings/clock/rk3399-cru.h

diff --git a/include/dt-bindings/clock/rk3399-cru.h b/include/dt-bindings/clock/rk3399-cru.h
new file mode 100644
index 0000000..77bb1ec
--- /dev/null
+++ b/include/dt-bindings/clock/rk3399-cru.h
@@ -0,0 +1,716 @@
+/*
+ * Copyright (c) 2015 Rockchip Electronics Co. Ltd.
+ * Author: Xing Zheng <zhengxing at rock-chips.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H
+#define _DT_BINDINGS_CLK_ROCKCHIP_RK3399_H
+
+/* core clocks */
+#define PLL_APLLL			1
+#define PLL_APLLB			2
+#define PLL_DPLL			3
+#define PLL_CPLL			4
+#define PLL_GPLL			5
+#define PLL_NPLL			6
+#define PLL_VPLL			7
+#define PLL_PPLL			8
+#define ARMCLKL				9
+#define ARMCLKB				10
+
+/* sclk gates (special clocks) */
+#define SCLK_I2C1			65
+#define SCLK_I2C2			66
+#define SCLK_I2C3			67
+#define SCLK_I2C5			68
+#define SCLK_I2C6			69
+#define SCLK_I2C7			70
+#define SCLK_SPI0			71
+#define SCLK_SPI1			72
+#define SCLK_SPI2			73
+#define SCLK_SPI4			74
+#define SCLK_SPI5			75
+#define SCLK_SDMMC			76
+#define SCLK_SDIO			77
+#define SCLK_EMMC			78
+#define SCLK_TSADC			79
+#define SCLK_SARADC			80
+#define SCLK_UART0			81
+#define SCLK_UART1			82
+#define SCLK_UART2			83
+#define SCLK_UART3			84
+#define SCLK_SPDIF_8CH			85
+#define SCLK_I2S0_8CH			86
+#define SCLK_I2S1_8CH			87
+#define SCLK_I2S2_8CH			88
+#define SCLK_I2S_8CH_OUT		89
+#define SCLK_TIMER00			90
+#define SCLK_TIMER01			91
+#define SCLK_TIMER02			92
+#define SCLK_TIMER03			93
+#define SCLK_TIMER04			94
+#define SCLK_TIMER05			95
+#define SCLK_TIMER06			96
+#define SCLK_TIMER07			97
+#define SCLK_TIMER08			98
+#define SCLK_TIMER09			99
+#define SCLK_TIMER10			100
+#define SCLK_TIMER11			101
+#define SCLK_MACREF			102
+#define SCLK_MAC_RX			103
+#define SCLK_MAC_TX			104
+#define SCLK_MAC			105
+#define SCLK_MACREF_OUT			106
+#define SCLK_VOP0_PWM			107
+#define SCLK_VOP1_PWM			108
+#define SCLK_RGA			109
+#define SCLK_ISP0			110
+#define SCLK_ISP1			111
+#define SCLK_HDMI_CEC			112
+#define SCLK_HDMI_SFR			113
+#define SCLK_DP_CORE_SRC		114
+#define SCLK_PVTM_CORE_L		115
+#define SCLK_PVTM_CORE_B		116
+#define SCLK_PVTM_GPU			117
+#define SCLK_PVTM_DDR			118
+#define SCLK_MIPIDPHY_REF		119
+#define SCLK_MIPIDPHY_CFG		120
+#define SCLK_HSICPHY			121
+#define SCLK_USBPHY480M			122
+#define SCLK_USB2PHY0_REF		123
+#define SCLK_USB2PHY1_REF		124
+#define SCLK_UPHY0_TCPDPHY_REF		125
+#define SCLK_UPHY0_TCPDCORE		126
+#define SCLK_UPHY1_TCPDPHY_REF		127
+#define SCLK_UPHY1_TCPDCORE		128
+#define SCLK_USB3OTG0_REF		129
+#define SCLK_USB3OTG1_REF		130
+#define SCLK_USB3OTG0_SUSPEND		131
+#define SCLK_USB3OTG1_SUSPEND		132
+#define SCLK_CRYPTO0			133
+#define SCLK_CRYPTO1			134
+#define SCLK_CCI_TRACE			135
+#define SCLK_CS				136
+#define SCLK_CIF_OUT			137
+#define SCLK_PCIEPHY_REF		138
+#define SCLK_PCIE_CORE			139
+#define SCLK_MO_PERILP			140
+#define SCLK_M0_PERILP_DEC		141
+#define SCLK_CM0S			142
+#define SCLK_DBG_NOC			143
+#define SCLK_DBG_PD_CORE_B		144
+#define SCLK_DBG_PD_CORE_L		145
+#define SCLK_DFIMON0_TIMER		146
+#define SCLK_DFIMON1_TIMER		147
+#define SCLK_INTMEM0			148
+#define SCLK_INTMEM1			149
+#define SCLK_INTMEM2			150
+#define SCLK_INTMEM3			151
+#define SCLK_INTMEM4			152
+#define SCLK_INTMEM5			153
+
+#define DCLK_VOP0			170
+#define DCLK_VOP1			171
+
+/* aclk gates */
+#define ACLK_PERIHP			192
+#define ACLK_PERIHP_NOC			193
+#define ACLK_PERILP0			194
+#define ACLK_PERILP0_NOC		195
+#define ACLK_PERF_PCIE			196
+#define ACLK_PCIE			197
+#define ACLK_INTMEM			198
+#define ACLK_TZMA			199
+#define ACLK_DCF			200
+#define ACLK_CCI			201
+#define ACLK_CCI_NOC0			202
+#define ACLK_CCI_NOC1			203
+#define ACLK_CCI_GRF			204
+#define ACLK_CENTER			205
+#define ACLK_CENTER_MAIN_NOC		206
+#define ACLK_CENTER_PERI_NOC		207
+#define ACLK_GPU			208
+#define ACLK_PERF_GPU			209
+#define ACLK_GPU_GRF			210
+#define ACLK_DMAC0_PERILP		211
+#define ACLK_DMAC1_PERILP		212
+#define ACLK_GMAC			213
+#define ACLK_GMAC_NOC			214
+#define ACLK_PERF_GMAC			215
+#define ACLK_VOP0_NOC			216
+#define ACLK_VOP0			217
+#define ACLK_VOP1_NOC			218
+#define ACLK_VOP1			219
+#define ACLK_RGA			220
+#define ACLK_RGA_NOC			221
+#define ACLK_HDCP			222
+#define ACLK_HDCP_NOC			223
+#define ACLK_HDCP22			224
+#define ACLK_IEP			225
+#define ACLK_IEP_NOC			226
+#define ACLK_VIO			227
+#define ACLK_VIO_NOC			228
+#define ACLK_ISP0			229
+#define ACLK_ISP1			230
+#define ACLK_ISP0_NOC			231
+#define ACLK_ISP1_NOC			232
+#define ACLK_ISP0_WRAPPER		233
+#define ACLK_ISP1_WRAPPER		234
+#define ACLK_VCODEC			235
+#define ACLK_VCODEC_NOC			236
+#define ACLK_VDU			237
+#define ACLK_VDU_NOC			238
+#define ACLK_PERI			239
+#define ACLK_EMMC			240
+#define ACLK_EMMC_CORE			241
+#define ACLK_EMMC_NOC			242
+#define ACLK_EMMC_GRF			243
+#define ACLK_USB3			244
+#define ACLK_USB3_NOC			245
+#define ACLK_USB3OTG0			246
+#define ACLK_USB3OTG1			247
+#define ACLK_USB3_RKSOC_AXI_PERF	248
+#define ACLK_USB3_GRF			249
+#define ACLK_GIC			250
+#define ACLK_GIC_NOC			251
+#define ACLK_GIC_ADB400_CORE_L_2_GIC	252
+#define ACLK_GIC_ADB400_CORE_B_2_GIC	253
+#define ACLK_GIC_ADB400_GIC_2_CORE_L	254
+#define ACLK_GIC_ADB400_GIC_2_CORE_B	255
+
+/* pclk gates */
+#define PCLK_PERIHP			320
+#define PCLK_PERIHP_NOC			321
+#define PCLK_PERILP0			322
+#define PCLK_PERILP1			323
+#define PCLK_PERILP1_NOC		324
+#define PCLK_PERILP_SGRF		325
+#define PCLK_PERIHP_GRF			326
+#define PCLK_PCIE			327
+#define PCLK_SGRF			328
+#define PCLK_INTR_ARB			329
+#define PCLK_CENTER_MAIN_NOC		330
+#define PCLK_CIC			331
+#define PCLK_COREDBG_B			332
+#define PCLK_COREDBG_L			333
+#define PCLK_DBG_CXCS_PD_CORE_B		334
+#define PCLK_DCF			335
+#define PCLK_GPIO2			336
+#define PCLK_GPIO3			337
+#define PCLK_GPIO4			338
+#define PCLK_GRF			339
+#define PCLK_HSICPHY			340
+#define PCLK_I2C1			341
+#define PCLK_I2C2			342
+#define PCLK_I2C3			343
+#define PCLK_I2C5			344
+#define PCLK_I2C6			345
+#define PCLK_I2C7			346
+#define PCLK_SPI0			347
+#define PCLK_SPI1			348
+#define PCLK_SPI2			349
+#define PCLK_SPI4			350
+#define PCLK_SPI5			351
+#define PCLK_UART0			352
+#define PCLK_UART1			353
+#define PCLK_UART2			354
+#define PCLK_UART3			355
+#define PCLK_TSADC			356
+#define PCLK_SARADC			357
+#define PCLK_GMAC			358
+#define PCLK_GMAC_NOC			359
+#define PCLK_TIMER0			360
+#define PCLK_TIMER1			361
+#define PCLK_EDP			362
+#define PCLK_EDP_NOC			363
+#define PCLK_EDP_CTRL			364
+#define PCLK_VIO			365
+#define PCLK_VIO_NOC			366
+#define PCLK_VIO_GRF			367
+#define PCLK_MIPI_DSI0			368
+#define PCLK_MIPI_DSI1			369
+#define PCLK_HDCP			370
+#define PCLK_HDCP_NOC			371
+#define PCLK_HDMI_CTRL			372
+#define PCLK_DP_CTRL			373
+#define PCLK_HDCP22			374
+#define PCLK_GASKET			375
+#define PCLK_DDR			376
+#define PCLK_DDR_MON			377
+#define PCLK_DDR_SGRF			378
+#define PCLK_ISP1_WRAPPER		379
+#define PCLK_WDT			380
+#define PCLK_EFUSE1024NS		381
+#define PCLK_EFUSE1024S			382
+#define PCLK_PMU_INTR_ARB		383
+#define PCLK_MAILBOX0			384
+
+/* hclk gates */
+#define HCLK_PERIHP			448
+#define HCLK_PERILP0			449
+#define HCLK_PERILP1			450
+#define HCLK_PERILP0_NOC		451
+#define HCLK_PERILP1_NOC		452
+#define HCLK_M0_PERILP			453
+#define HCLK_M0_PERILP_NOC		454
+#define HCLK_AHB1TOM			455
+#define HCLK_HOST0			456
+#define HCLK_HOST0_ARB			457
+#define HCLK_HOST1			458
+#define HCLK_HOST1_ARB			459
+#define HCLK_HSIC			460
+#define HCLK_SD				461
+#define HCLK_SDMMC			462
+#define HCLK_SDMMC_NOC			463
+#define HCLK_M_CRYPTO0			464
+#define HCLK_M_CRYPTO1			465
+#define HCLK_S_CRYPTO0			466
+#define HCLK_S_CRYPTO1			467
+#define HCLK_I2S0_8CH			468
+#define HCLK_I2S1_8CH			469
+#define HCLK_I2S2_8CH			470
+#define HCLK_SPDIF			471
+#define HCLK_VOP0_NOC			472
+#define HCLK_VOP0			473
+#define HCLK_VOP1_NOC			474
+#define HCLK_VOP1			475
+#define HCLK_ROM			476
+#define HCLK_IEP			477
+#define HCLK_IEP_NOC			478
+#define HCLK_ISP0			479
+#define HCLK_ISP1			480
+#define HCLK_ISP0_NOC			481
+#define HCLK_ISP1_NOC			482
+#define HCLK_ISP0_WRAPPER		483
+#define HCLK_ISP1_WRAPPER		484
+#define HCLK_RGA			485
+#define HCLK_RGA_NOC			486
+#define HCLK_HDCP			487
+#define HCLK_HDCP_NOC			488
+#define HCLK_HDCP22			489
+#define HCLK_VCODEC			490
+#define HCLK_VCODEC_NOC			491
+#define HCLK_VDU			492
+#define HCLK_VDU_NOC			493
+#define HCLK_SDIO			494
+#define HCLK_SDIO_NOC			495
+#define HCLK_SDIOAUDIO_NOC		496
+
+#define CLK_NR_CLKS			(HCLK_SDIOAUDIO_NOC + 1)
+
+/* pmu-clocks indices */
+#define SCLK_32K_SUSPEND_PMU		521
+#define SCLK_SPI3_PMU			522
+#define SCLK_TIMER12_PMU		523
+#define SCLK_TIMER13_PMU		524
+#define SCLK_UART4_PMU			525
+#define SCLK_PVTM_PMU			526
+#define SCLK_WIFI_PMU			527
+#define SCLK_I2C0_PMU			528
+#define SCLK_I2C4_PMU			529
+#define SCLK_I2C8_PMU			530
+
+#define PCLK_PMU			540
+#define PCLK_PMUGRF_PMU			541
+#define PCLK_INTMEM1_PMU		542
+#define PCLK_GPIO0_PMU			543
+#define PCLK_GPIO1_PMU			544
+#define PCLK_SGRF_PMU			545
+#define PCLK_NOC_PMU			546
+#define PCLK_I2C0_PMU			547
+#define PCLK_I2C4_PMU			548
+#define PCLK_I2C8_PMU			549
+#define PCLK_RKPWM_PMU			550
+#define PCLK_SPI3_PMU			551
+#define PCLK_TIMER_PMU			552
+#define PCLK_MAILBOX_PMU		553
+#define PCLK_UART4_PMU			554
+#define PCLK_WDT_M0_PMU			555
+
+#define FCLK_CM0S_PMU			560
+#define SCLK_CM0S_PMU			561
+#define HCLK_CM0S_PMU			562
+#define DCLK_CM0S_PMU			563
+#define PCLK_INTR_ARB_PMU		564
+#define HCLK_NOC_PMU			565
+
+#define CLKPMU_NR_CLKS			(HCLK_NOC_PMU - SCLK_32K_SUSPEND_PMU + 1)
+
+/* soft-reset indices */
+
+/* cru_softrst_con0 */
+#define SRST_CORE_L0			0
+#define SRST_CORE_B0			1
+#define SRST_CORE_PO_L0			2
+#define SRST_CORE_PO_B0			3
+#define SRST_L2_L			4
+#define SRST_L2_B			5
+#define SRST_ADB_L			6
+#define SRST_ADB_B			7
+#define SRST_A_CCI			8
+#define SRST_A_CCIM0_NOC		9
+#define SRST_A_CCIM1_NOC		10
+#define SRST_DBG_NOC			11
+
+/* cru_softrst_con1 */
+#define SRST_CORE_L0_T			16
+#define SRST_CORE_L1			17
+#define SRST_CORE_L2			18
+#define SRST_CORE_L3			19
+#define SRST_CORE_PO_L0_T		20
+#define SRST_CORE_PO_L1			21
+#define SRST_CORE_PO_L2			22
+#define SRST_CORE_PO_L3			23
+#define SRST_A_ADB400_GIC2COREL		24
+#define SRST_A_ADB400_COREL2GIC		25
+#define SRST_P_DBG_L			26
+#define SRST_L2_L_T			28
+#define SRST_ADB_L_T			29
+#define SRST_A_RKPERF_L			30
+#define SRST_PVTM_CORE_L		31
+
+/* cru_softrst_con2 */
+#define SRST_CORE_B0_T			32
+#define SRST_CORE_B1			33
+#define SRST_CORE_PO_B0_T		36
+#define SRST_CORE_PO_B1			37
+#define SRST_A_ADB400_GIC2COREB		40
+#define SRST_A_ADB400_COREB2GIC		41
+#define SRST_P_DBG_B			42
+#define SRST_L2_B_T			43
+#define SRST_ADB_B_T			45
+#define SRST_A_RKPERF_B			46
+#define SRST_PVTM_CORE_B		47
+
+/* cru_softrst_con3 */
+#define SRST_A_CCI_T			50
+#define SRST_A_CCIM0_NOC_T		51
+#define SRST_A_CCIM1_NOC_T		52
+#define SRST_A_ADB400M_PD_CORE_B_T	53
+#define SRST_A_ADB400M_PD_CORE_L_T	54
+#define SRST_DBG_NOC_T			55
+#define SRST_DBG_CXCS			56
+#define SRST_CCI_TRACE			57
+#define SRST_P_CCI_GRF			58
+
+/* cru_softrst_con4 */
+#define SRST_A_CENTER_MAIN_NOC		64
+#define SRST_A_CENTER_PERI_NOC		65
+#define SRST_P_CENTER_MAIN		66
+#define SRST_P_DDRMON			67
+#define SRST_P_CIC			68
+#define SRST_P_CENTER_SGRF		69
+#define SRST_DDR0_MSCH			70
+#define SRST_DDRCFG0_MSCH		71
+#define SRST_DDR0			72
+#define SRST_DDRPHY0			73
+#define SRST_DDR1_MSCH			74
+#define SRST_DDRCFG1_MSCH		75
+#define SRST_DDR1			76
+#define SRST_DDRPHY1			77
+#define SRST_DDR_CIC			78
+#define SRST_PVTM_DDR			79
+
+/* cru_softrst_con5 */
+#define SRST_A_VCODEC_NOC		80
+#define SRST_A_VCODEC			81
+#define SRST_H_VCODEC_NOC		82
+#define SRST_H_VCODEC			83
+#define SRST_A_VDU_NOC			88
+#define SRST_A_VDU			89
+#define SRST_H_VDU_NOC			90
+#define SRST_H_VDU			91
+#define SRST_VDU_CORE			92
+#define SRST_VDU_CA			93
+
+/* cru_softrst_con6 */
+#define SRST_A_IEP_NOC			96
+#define SRST_A_VOP_IEP			97
+#define SRST_A_IEP			98
+#define SRST_H_IEP_NOC			99
+#define SRST_H_IEP			100
+#define SRST_A_RGA_NOC			102
+#define SRST_A_RGA			103
+#define SRST_H_RGA_NOC			104
+#define SRST_H_RGA			105
+#define SRST_RGA_CORE			106
+#define SRST_EMMC_NOC			108
+#define SRST_EMMC			109
+#define SRST_EMMC_GRF			110
+
+/* cru_softrst_con7 */
+#define SRST_A_PERIHP_NOC		112
+#define SRST_P_PERIHP_GRF		113
+#define SRST_H_PERIHP_NOC		114
+#define SRST_USBHOST0			115
+#define SRST_HOSTC0_AUX			116
+#define SRST_HOST0_ARB			117
+#define SRST_USBHOST1			118
+#define SRST_HOSTC1_AUX			119
+#define SRST_HOST1_ARB			120
+#define SRST_SDIO0			121
+#define SRST_SDMMC			122
+#define SRST_HSIC			123
+#define SRST_HSIC_AUX			124
+#define SRST_AHB1TOM			125
+#define SRST_P_PERIHP_NOC		126
+#define SRST_HSICPHY			127
+
+/* cru_softrst_con8 */
+#define SRST_A_PCIE			128
+#define SRST_P_PCIE			129
+#define SRST_PCIE_CORE			130
+#define SRST_PCIE_MGMT			131
+#define SRST_PCIE_MGMT_STICKY		132
+#define SRST_PCIE_PIPE			133
+#define SRST_PCIE_PM			134
+#define SRST_PCIEPHY			135
+#define SRST_A_GMAC_NOC			136
+#define SRST_A_GMAC			137
+#define SRST_P_GMAC_NOC			138
+#define SRST_P_GMAC_GRF			140
+#define SRST_HSICPHY_POR		142
+#define SRST_HSICPHY_UTMI		143
+
+/* cru_softrst_con9 */
+#define SRST_USB2PHY0_POR		144
+#define SRST_USB2PHY0_UTMI_PORT0	145
+#define SRST_USB2PHY0_UTMI_PORT1	146
+#define SRST_USB2PHY0_EHCIPHY		147
+#define SRST_UPHY0_PIPE_L00		148
+#define SRST_UPHY0			149
+#define SRST_UPHY0_TCPDPWRUP		150
+#define SRST_USB2PHY1_POR		152
+#define SRST_USB2PHY1_UTMI_PORT0	153
+#define SRST_USB2PHY1_UTMI_PORT1	154
+#define SRST_USB2PHY1_EHCIPHY		155
+#define SRST_UPHY1_PIPE_L00		156
+#define SRST_UPHY1			157
+#define SRST_UPHY1_TCPDPWRUP		158
+
+/* cru_softrst_con10 */
+#define SRST_A_PERILP0_NOC		160
+#define SRST_A_DCF			161
+#define SRST_GIC500			162
+#define SRST_DMAC0_PERILP0		163
+#define SRST_DMAC1_PERILP0		164
+#define SRST_TZMA			165
+#define SRST_INTMEM			166
+#define SRST_ADB400_MST0		167
+#define SRST_ADB400_MST1		168
+#define SRST_ADB400_SLV0		169
+#define SRST_ADB400_SLV1		170
+#define SRST_H_PERILP0			171
+#define SRST_H_PERILP0_NOC		172
+#define SRST_ROM			173
+#define SRST_CRYPTO_S			174
+#define SRST_CRYPTO_M			175
+
+/* cru_softrst_con11 */
+#define SRST_P_DCF			176
+#define SRST_CM0S_NOC			177
+#define SRST_CM0S			178
+#define SRST_CM0S_DBG			179
+#define SRST_CM0S_PO			180
+#define SRST_CRYPTO			181
+#define SRST_P_PERILP1_SGRF		182
+#define SRST_P_PERILP1_GRF		183
+#define SRST_CRYPTO1_S			184
+#define SRST_CRYPTO1_M			185
+#define SRST_CRYPTO1			186
+#define SRST_GIC_NOC			188
+#define SRST_SD_NOC			189
+#define SRST_SDIOAUDIO_BRG		190
+
+/* cru_softrst_con12 */
+#define SRST_H_PERILP1			192
+#define SRST_H_PERILP1_NOC		193
+#define SRST_H_I2S0_8CH			194
+#define SRST_H_I2S1_8CH			195
+#define SRST_H_I2S2_8CH			196
+#define SRST_H_SPDIF_8CH		197
+#define SRST_P_PERILP1_NOC		198
+#define SRST_P_EFUSE_1024		199
+#define SRST_P_EFUSE_1024S		200
+#define SRST_P_I2C0			201
+#define SRST_P_I2C1			202
+#define SRST_P_I2C2			203
+#define SRST_P_I2C3			204
+#define SRST_P_I2C4			205
+#define SRST_P_I2C5			206
+#define SRST_P_MAILBOX0			207
+
+/* cru_softrst_con13 */
+#define SRST_P_UART0			208
+#define SRST_P_UART1			209
+#define SRST_P_UART2			210
+#define SRST_P_UART3			211
+#define SRST_P_SARADC			212
+#define SRST_P_TSADC			213
+#define SRST_P_SPI0			214
+#define SRST_P_SPI1			215
+#define SRST_P_SPI2			216
+#define SRST_P_SPI3			217
+#define SRST_P_SPI4			218
+#define SRST_SPI0			219
+#define SRST_SPI1			220
+#define SRST_SPI2			221
+#define SRST_SPI3			222
+#define SRST_SPI4			223
+
+/* cru_softrst_con14 */
+#define SRST_I2S0_8CH			224
+#define SRST_I2S1_8CH			225
+#define SRST_I2S2_8CH			226
+#define SRST_SPDIF_8CH			227
+#define SRST_UART0			228
+#define SRST_UART1			229
+#define SRST_UART2			230
+#define SRST_UART3			231
+#define SRST_TSADC			232
+#define SRST_I2C0			233
+#define SRST_I2C1			234
+#define SRST_I2C2			235
+#define SRST_I2C3			236
+#define SRST_I2C4			237
+#define SRST_I2C5			238
+#define SRST_SDIOAUDIO_NOC		239
+
+/* cru_softrst_con15 */
+#define SRST_A_VIO_NOC			240
+#define SRST_A_HDCP_NOC			241
+#define SRST_A_HDCP			242
+#define SRST_H_HDCP_NOC			243
+#define SRST_H_HDCP			244
+#define SRST_P_HDCP_NOC			245
+#define SRST_P_HDCP			246
+#define SRST_P_HDMI_CTRL		247
+#define SRST_P_DP_CTRL			248
+#define SRST_S_DP_CTRL			249
+#define SRST_C_DP_CTRL			250
+#define SRST_P_MIPI_DSI0		251
+#define SRST_P_MIPI_DSI1		252
+#define SRST_DP_CORE			253
+#define SRST_DP_I2S			254
+
+/* cru_softrst_con16 */
+#define SRST_GASKET			256
+#define SRST_VIO_GRF			258
+#define SRST_DPTX_SPDIF_REC		259
+#define SRST_HDMI_CTRL			260
+#define SRST_HDCP_CTRL			261
+#define SRST_A_ISP0_NOC			262
+#define SRST_A_ISP1_NOC			263
+#define SRST_H_ISP0_NOC			266
+#define SRST_H_ISP1_NOC			267
+#define SRST_H_ISP0			268
+#define SRST_H_ISP1			269
+#define SRST_ISP0			270
+#define SRST_ISP1			271
+
+/* cru_softrst_con17 */
+#define SRST_A_VOP0_NOC			272
+#define SRST_A_VOP1_NOC			273
+#define SRST_A_VOP0			274
+#define SRST_A_VOP1			275
+#define SRST_H_VOP0_NOC			276
+#define SRST_H_VOP1_NOC			277
+#define SRST_H_VOP0			278
+#define SRST_H_VOP1			279
+#define SRST_D_VOP0			280
+#define SRST_D_VOP1			281
+#define SRST_VOP0_PWM			282
+#define SRST_VOP1_PWM			283
+#define SRST_P_EDP_NOC			284
+#define SRST_P_EDP_CTRL			285
+
+/* cru_softrst_con18 */
+#define SRST_A_GPU_NOC			289
+#define SRST_A_GPU_GRF			290
+#define SRST_PVTM_GPU			291
+#define SRST_A_USB3_NOC			292
+#define SRST_A_USB3_OTG0		293
+#define SRST_A_USB3_OTG1		294
+#define SRST_A_USB3_GRF			295
+#define SRST_PMU			296
+
+/* cru_softrst_con19 */
+#define SRST_P_TIMER0_5			304
+#define SRST_TIMER0			305
+#define SRST_TIMER1			306
+#define SRST_TIMER2			307
+#define SRST_TIMER3			308
+#define SRST_TIMER4			309
+#define SRST_TIMER5			310
+#define SRST_P_TIMER6_11		311
+#define SRST_TIMER6			312
+#define SRST_TIMER7			313
+#define SRST_TIMER8			314
+#define SRST_TIMER9			315
+#define SRST_TIMER10			316
+#define SRST_TIMER11			317
+#define SRST_P_INTR_ARB_PMU		318
+#define SRST_P_ALIVE_SGRF		319
+
+/* cru_softrst_con20 */
+#define SRST_P_GPIO2			320
+#define SRST_P_GPIO3			321
+#define SRST_P_GPIO4			322
+#define SRST_P_GRF			323
+#define SRST_P_ALIVE_NOC		324
+#define SRST_P_WDT0			325
+#define SRST_P_WDT1			326
+#define SRST_P_INTR_ARB			327
+#define SRST_P_UPHY0_DPTX		328
+#define SRST_P_UPHY0_APB		330
+#define SRST_P_UPHY0_TCPHY		332
+#define SRST_P_UPHY1_TCPHY		333
+#define SRST_P_UPHY0_TCPDCTRL		334
+#define SRST_P_UPHY1_TCPDCTRL		335
+
+/* pmu soft-reset indices */
+
+/* pmu_cru_softrst_con0 */
+#define SRST_P_NOC			0
+#define SRST_P_INTMEM			1
+#define SRST_H_CM0S			2
+#define SRST_H_CM0S_NOC			3
+#define SRST_DBG_CM0S			4
+#define SRST_PO_CM0S			5
+#define SRST_P_SPI6			6
+#define SRST_SPI6			7
+#define SRST_P_TIMER_0_1		8
+#define SRST_P_TIMER_0			9
+#define SRST_P_TIMER_1			10
+#define SRST_P_UART4			11
+#define SRST_UART4			12
+#define SRST_P_WDT			13
+
+/* pmu_cru_softrst_con1 */
+#define SRST_P_I2C6			16
+#define SRST_P_I2C7			17
+#define SRST_P_I2C8			18
+#define SRST_P_MAILBOX			19
+#define SRST_P_RKPWM			20
+#define SRST_P_PMUGRF			21
+#define SRST_P_SGRF			22
+#define SRST_P_GPIO0			23
+#define SRST_P_GPIO1			24
+#define SRST_P_CRU			25
+#define SRST_P_INTR			26
+#define SRST_PVTM			27
+#define SRST_I2C6			28
+#define SRST_I2C7			29
+#define SRST_I2C8			30
+
+#endif
-- 
1.9.1




From jay.xu at rock-chips.com  Thu Feb 25 19:12:21 2016
From: jay.xu at rock-chips.com (Jianqun Xu)
Date: Fri, 26 Feb 2016 11:12:21 +0800
Subject: [PATCH v2 3/3] ARM64: dts: rockchip: add core dtsi file for rk3399
In-Reply-To: <1456456341-14282-1-git-send-email-jay.xu@rock-chips.com>
References: <1456210864-29037-1-git-send-email-jay.xu@rock-chips.com>
 <1456456341-14282-1-git-send-email-jay.xu@rock-chips.com>
Message-ID: <1456456341-14282-4-git-send-email-jay.xu@rock-chips.com>

This patch adds core dtsi file for rk3399 found on Rockchip new SoCs
rk3399, which integrates dual-core Cortex-A72 and quad-core Cortex-A53
with separately NEON coprocessor.

The dtsi file has been tested on rk3399 board with simple boot system,
the uart and spi IPs are same as from rk3288.

Separate pmu nodes should be added for the A72 and A53 PMUs, and more
nodes should be added later.

Signed-off-by: Jianqun Xu <jay.xu at rock-chips.com>
---
changes in v2:
- add "rockchip,grf = <&pmugrf>" for pmucru node (xing)

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 950 +++++++++++++++++++++++++++++++
 1 file changed, 950 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 0000000..deb96cb
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,950 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+#include <dt-bindings/clock/rk3399-cru.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+
+/ {
+	compatible = "rockchip,rk3399";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &uart0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu_l0>;
+				};
+				core1 {
+					cpu = <&cpu_l1>;
+				};
+				core2 {
+					cpu = <&cpu_l2>;
+				};
+				core3 {
+					cpu = <&cpu_l3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu_b0>;
+				};
+				core1 {
+					cpu = <&cpu_b1>;
+				};
+			};
+		};
+
+		cpu_l0: cpu at 0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x0>;
+		};
+
+		cpu_l1: cpu at 1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x1>;
+		};
+
+		cpu_l2: cpu at 2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x2>;
+		};
+
+		cpu_l3: cpu at 3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53", "arm,armv8";
+			reg = <0x0 0x3>;
+		};
+
+		cpu_b0: cpu at 100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x0 0x100>;
+		};
+
+		cpu_b1: cpu at 101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a72", "arm,armv8";
+			reg = <0x0 0x101>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH)>,
+			     <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	xin24m: xin24m {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <24000000>;
+		clock-output-names = "xin24m";
+	};
+
+	gic: interrupt-controller at fee00000 {
+		compatible = "arm,gic-v3";
+		#interrupt-cells = <3>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		interrupt-controller;
+
+		reg = <0x0 0xfee00000 0 0x10000>, /* GICD */
+		      <0x0 0xfef00000 0 0xc0000>, /* GICR */
+		      <0x0 0xfff00000 0 0x10000>, /* GICC */
+		      <0x0 0xfff10000 0 0x10000>, /* GICH */
+		      <0x0 0xfff20000 0 0x10000>; /* GICV */
+		interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH)>;
+		its: interrupt-controller at fee20000 {
+			compatible = "arm,gic-v3-its";
+			msi-controller;
+			reg = <0x0 0xfee20000 0x0 0x20000>;
+		};
+	};
+
+	amba {
+		compatible = "arm,amba-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		dmac_bus: dma-controller at ff6d0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x0 0xff6d0000 0x0 0x4000>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			clocks = <&cru ACLK_DMAC0_PERILP>;
+			clock-names = "apb_pclk";
+		};
+
+		dmac_peri: dma-controller at ff6e0000 {
+			compatible = "arm,pl330", "arm,primecell";
+			reg = <0x0 0xff6e0000 0x0 0x4000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			#dma-cells = <1>;
+			clocks = <&cru ACLK_DMAC1_PERILP>;
+			clock-names = "apb_pclk";
+		};
+	};
+
+	uart0: serial at ff180000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff180000 0x0 0x100>;
+		clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart1: serial at ff190000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff190000 0x0 0x100>;
+		clocks = <&cru SCLK_UART1>, <&cru PCLK_UART1>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart2: serial at ff1a0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff1a0000 0x0 0x100>;
+		clocks = <&cru SCLK_UART2>, <&cru PCLK_UART2>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart3: serial at ff1b0000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff1b0000 0x0 0x100>;
+		clocks = <&cru SCLK_UART3>, <&cru PCLK_UART3>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	spi0: spi at ff1c0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff110000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI0>, <&cru PCLK_SPI0>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi0_clk &spi0_tx &spi0_rx &spi0_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi1: spi at ff1d0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff120000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI1>, <&cru PCLK_SPI1>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi1_clk &spi1_tx &spi1_rx &spi1_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi2: spi at ff1e0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff130000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI2>, <&cru PCLK_SPI2>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi2_clk &spi2_tx &spi2_rx &spi2_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi4: spi at ff1f0000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff120000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI4>, <&cru PCLK_SPI4>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi4_clk &spi4_tx &spi4_rx &spi4_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	spi5: spi at ff200000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff130000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI5>, <&cru PCLK_SPI5>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi5_clk &spi5_tx &spi5_rx &spi5_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	pmugrf: syscon at ff320000 {
+		compatible = "rockchip,rk3399-pmugrf", "syscon";
+		reg = <0x0 0xff320000 0x0 0x1000>;
+	};
+
+	spi3: spi at ff350000 {
+		compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi";
+		reg = <0x0 0xff110000 0x0 0x1000>;
+		clocks = <&cru SCLK_SPI3>, <&cru PCLK_SPI3>;
+		clock-names = "spiclk", "apb_pclk";
+		interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&spi3_clk &spi3_tx &spi3_rx &spi3_cs0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		status = "disabled";
+	};
+
+	uart4: serial at ff370000 {
+		compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
+		reg = <0x0 0xff370000 0x0 0x100>;
+		clocks = <&cru SCLK_UART4_PMU>, <&cru PCLK_UART4_PMU>;
+		clock-names = "baudclk", "apb_pclk";
+		interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	pmucru: pmu-clock-controller at ff750000 {
+		compatible = "rockchip,rk3399-pmucru";
+		reg = <0x0 0xff750000 0x0 0x1000>;
+		rockchip,grf = <&pmugrf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	cru: clock-controller at ff760000 {
+		compatible = "rockchip,rk3399-cru";
+		reg = <0x0 0xff760000 0x0 0x1000>;
+		rockchip,grf = <&grf>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	grf: syscon at ff770000 {
+		compatible = "rockchip,rk3399-grf", "syscon";
+		reg = <0x0 0xff770000 0x0 0x10000>;
+	};
+
+	i2s0: i2s at ff880000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff880000 0x0 0x1000>;
+		interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 0>, <&dmac_bus 1>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S0_8CH>, <&cru SCLK_I2S0_8CH>;
+		status = "disabled";
+	};
+
+	i2s1: i2s at ff890000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff890000 0x0 0x1000>;
+		interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 2>, <&dmac_bus 3>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S1_8CH>, <&cru SCLK_I2S1_8CH>;
+		status = "disabled";
+	};
+
+	i2s2: i2s at ff8a0000 {
+		compatible = "rockchip,rk3399-i2s", "rockchip,rk3066-i2s";
+		reg = <0x0 0xff8a0000 0x0 0x1000>;
+		interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		dmas = <&dmac_bus 4>, <&dmac_bus 5>;
+		dma-names = "tx", "rx";
+		clock-names = "i2s_hclk", "i2s_clk";
+		clocks = <&cru HCLK_I2S2_8CH>, <&cru SCLK_I2S2_8CH>;
+		status = "disabled";
+	};
+
+	pinctrl: pinctrl {
+		compatible = "rockchip,rk3399-pinctrl";
+		rockchip,grf = <&grf>;
+		rockchip,pmu = <&pmugrf>;
+		#address-cells = <0x2>;
+		#size-cells = <0x2>;
+		ranges;
+
+		gpio0: gpio0 at ff720000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff720000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio1: gpio1 at ff730000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff730000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio2: gpio2 at ff780000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff780000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio3: gpio3 at ff788000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff788000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		gpio4: gpio4 at ff790000 {
+			compatible = "rockchip,gpio-bank";
+			reg = <0x0 0xff790000 0x0 0x100>;
+			clocks = <&xin24m>;
+			interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+
+			gpio-controller;
+			#gpio-cells = <0x2>;
+
+			interrupt-controller;
+			#interrupt-cells = <0x2>;
+		};
+
+		pcfg_pull_up: pcfg-pull-up {
+			bias-pull-up;
+		};
+
+		pcfg_pull_down: pcfg-pull-down {
+			bias-pull-down;
+		};
+
+		pcfg_pull_none: pcfg-pull-none {
+			bias-disable;
+		};
+
+		pcfg_pull_none_12ma: pcfg-pull-none-12ma {
+			bias-disable;
+			drive-strength = <12>;
+		};
+
+		pcfg_pull_up_8ma: pcfg-pull-up-8ma {
+			bias-pull-up;
+			drive-strength = <8>;
+		};
+
+		pcfg_pull_down_4ma: pcfg-pull-down-4ma {
+			bias-pull-down;
+			drive-strength = <4>;
+		};
+
+		pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+			bias-pull-up;
+			drive-strength = <2>;
+		};
+
+		pcfg_pull_down_12ma: pcfg-pull-down-12ma {
+			bias-pull-down;
+			drive-strength = <12>;
+		};
+
+		emmc {
+			emmc_pwr: emmc-pwr {
+				rockchip,pins =
+					<0 5 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		gmac {
+			rgmii_pins: rgmii-pins {
+				rockchip,pins =
+					<3 11 RK_FUNC_1 &pcfg_pull_none>,
+					<3 13 RK_FUNC_1 &pcfg_pull_none>,
+					<3 8 RK_FUNC_1 &pcfg_pull_none>,
+					<3 4 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 5 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 0 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 1 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 17 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 12 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 6 RK_FUNC_1 &pcfg_pull_none>,
+					<3 7 RK_FUNC_1 &pcfg_pull_none>,
+					<3 2 RK_FUNC_1 &pcfg_pull_none>,
+					<3 3 RK_FUNC_1 &pcfg_pull_none>,
+					<3 14 RK_FUNC_1 &pcfg_pull_none>,
+					<3 9 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			rmii_pins: rmii-pins {
+				rockchip,pins =
+					<3 11 RK_FUNC_1 &pcfg_pull_none>,
+					<3 13 RK_FUNC_1 &pcfg_pull_none>,
+					<3 8 RK_FUNC_1 &pcfg_pull_none>,
+					<3 4 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 5 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 12 RK_FUNC_1 &pcfg_pull_none_12ma>,
+					<3 6 RK_FUNC_1 &pcfg_pull_none>,
+					<3 7 RK_FUNC_1 &pcfg_pull_none>,
+					<3 9 RK_FUNC_1 &pcfg_pull_none>,
+					<3 10 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c0 {
+			i2c0_xfer: i2c0-xfer {
+				rockchip,pins =
+					<1 15 RK_FUNC_2 &pcfg_pull_none>,
+					<1 16 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c1 {
+			i2c1_xfer: i2c1-xfer {
+				rockchip,pins =
+					<4 2 RK_FUNC_1 &pcfg_pull_none>,
+					<4 1 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c2 {
+			i2c2_xfer: i2c2-xfer {
+				rockchip,pins =
+					<2 1 RK_FUNC_2 &pcfg_pull_none_12ma>,
+					<2 0 RK_FUNC_2 &pcfg_pull_none_12ma>;
+			};
+		};
+
+		i2c3 {
+			i2c3_xfer: i2c3-xfer {
+				rockchip,pins =
+					<4 17 RK_FUNC_1 &pcfg_pull_none>,
+					<4 16 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c4 {
+			i2c4_xfer: i2c4-xfer {
+				rockchip,pins =
+					<1 12 RK_FUNC_1 &pcfg_pull_none>,
+					<1 11 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2c5 {
+			i2c5_xfer: i2c5-xfer {
+				rockchip,pins =
+					<3 11 RK_FUNC_2 &pcfg_pull_none>,
+					<3 10 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c6 {
+			i2c6_xfer: i2c6-xfer {
+				rockchip,pins =
+					<2 10 RK_FUNC_2 &pcfg_pull_none>,
+					<2 9 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c7 {
+			i2c7_xfer: i2c7-xfer {
+				rockchip,pins =
+					<2 8 RK_FUNC_2 &pcfg_pull_none>,
+					<2 7 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		i2c8 {
+			i2c8_xfer: i2c8-xfer {
+				rockchip,pins =
+					<1 21 RK_FUNC_1 &pcfg_pull_none>,
+					<1 20 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2s0 {
+			i2s0_8ch_bus: i2s0-8ch-bus {
+				rockchip,pins =
+					<3 24 RK_FUNC_1 &pcfg_pull_none>,
+					<3 25 RK_FUNC_1 &pcfg_pull_none>,
+					<3 26 RK_FUNC_1 &pcfg_pull_none>,
+					<3 27 RK_FUNC_1 &pcfg_pull_none>,
+					<3 28 RK_FUNC_1 &pcfg_pull_none>,
+					<3 29 RK_FUNC_1 &pcfg_pull_none>,
+					<3 30 RK_FUNC_1 &pcfg_pull_none>,
+					<3 31 RK_FUNC_1 &pcfg_pull_none>,
+					<4 0 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		i2s1 {
+			i2s1_2ch_bus: i2s1-2ch-bus {
+				rockchip,pins =
+					<4 3 RK_FUNC_1 &pcfg_pull_none>,
+					<4 4 RK_FUNC_1 &pcfg_pull_none>,
+					<4 5 RK_FUNC_1 &pcfg_pull_none>,
+					<4 6 RK_FUNC_1 &pcfg_pull_none>,
+					<4 7 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		sdio0 {
+			sdio0_bus1: sdio0-bus1 {
+				rockchip,pins =
+					<2 20 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_bus4: sdio0-bus4 {
+				rockchip,pins =
+					<2 20 RK_FUNC_1 &pcfg_pull_up>,
+					<2 21 RK_FUNC_1 &pcfg_pull_up>,
+					<2 22 RK_FUNC_1 &pcfg_pull_up>,
+					<2 23 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_cmd: sdio0-cmd {
+				rockchip,pins =
+					<2 24 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_clk: sdio0-clk {
+				rockchip,pins =
+					<2 25 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			sdio0_cd: sdio0-cd {
+				rockchip,pins =
+					<2 26 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_pwr: sdio0-pwr {
+				rockchip,pins =
+					<2 27 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_bkpwr: sdio0-bkpwr {
+				rockchip,pins =
+					<2 28 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_wp: sdio0-wp {
+				rockchip,pins =
+					<0 3 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdio0_int: sdio0-int {
+				rockchip,pins =
+					<0 4 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		sdmmc {
+			sdmmc_bus1: sdmmc-bus1 {
+				rockchip,pins =
+					<4 8 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_bus4: sdmmc-bus4 {
+				rockchip,pins =
+					<4 8 RK_FUNC_1 &pcfg_pull_up>,
+					<4 9 RK_FUNC_1 &pcfg_pull_up>,
+					<4 10 RK_FUNC_1 &pcfg_pull_up>,
+					<4 11 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_clk: sdmmc-clk {
+				rockchip,pins =
+					<4 12 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			sdmmc_cmd: sdmmc-cmd {
+				rockchip,pins =
+					<4 13 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_cd: sdmcc-cd {
+				rockchip,pins =
+					<0 7 RK_FUNC_1 &pcfg_pull_up>;
+			};
+
+			sdmmc_wp: sdmmc-wp {
+				rockchip,pins =
+					<0 8 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi0 {
+			spi0_clk: spi0-clk {
+				rockchip,pins =
+					<3 6 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_cs0: spi0-cs0 {
+				rockchip,pins =
+					<3 7 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_cs1: spi0-cs1 {
+				rockchip,pins =
+					<3 8 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_tx: spi0-tx {
+				rockchip,pins =
+					<3 5 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi0_rx: spi0-rx {
+				rockchip,pins =
+					<3 4 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi1 {
+			spi1_clk: spi1-clk {
+				rockchip,pins =
+					<1 9 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_cs0: spi1-cs0 {
+				rockchip,pins =
+					<1 10 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_rx: spi1-rx {
+				rockchip,pins =
+					<1 7 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi1_tx: spi1-tx {
+				rockchip,pins =
+					<1 8 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi2 {
+			spi2_clk: spi2-clk {
+				rockchip,pins =
+					<2 11 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_cs0: spi2-cs0 {
+				rockchip,pins =
+					<2 12 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_rx: spi2-rx {
+				rockchip,pins =
+					<2 9 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi2_tx: spi2-tx {
+				rockchip,pins =
+					<2 10 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi3 {
+			spi3_clk: spi3-clk {
+				rockchip,pins =
+					<1 17 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_cs0: spi3-cs0 {
+				rockchip,pins =
+					<1 18 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_rx: spi3-rx {
+				rockchip,pins =
+					<1 15 RK_FUNC_1 &pcfg_pull_up>;
+			};
+			spi3_tx: spi3-tx {
+				rockchip,pins =
+					<1 16 RK_FUNC_1 &pcfg_pull_up>;
+			};
+		};
+
+		spi4 {
+			spi4_clk: spi4-clk {
+				rockchip,pins =
+					<3 2 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_cs0: spi4-cs0 {
+				rockchip,pins =
+					<3 3 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_rx: spi4-rx {
+				rockchip,pins =
+					<3 0 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi4_tx: spi4-tx {
+				rockchip,pins =
+					<3 1 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		spi5 {
+			spi5_clk: spi5-clk {
+				rockchip,pins =
+					<2 22 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_cs0: spi5-cs0 {
+				rockchip,pins =
+					<2 23 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_rx: spi5-rx {
+				rockchip,pins =
+					<2 20 RK_FUNC_2 &pcfg_pull_up>;
+			};
+			spi5_tx: spi5-tx {
+				rockchip,pins =
+					<2 21 RK_FUNC_2 &pcfg_pull_up>;
+			};
+		};
+
+		uart0 {
+			uart0_xfer: uart0-xfer {
+				rockchip,pins =
+					<2 16 RK_FUNC_1 &pcfg_pull_up>,
+					<2 17 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			uart0_cts: uart0-cts {
+				rockchip,pins =
+					<2 18 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			uart0_rts: uart0-rts {
+				rockchip,pins =
+					<2 19 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uart1 {
+			uart1_xfer: uart1-xfer {
+				rockchip,pins =
+					<3 12 RK_FUNC_2 &pcfg_pull_up>,
+					<3 13 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2a {
+			uart2a_xfer: uart2a-xfer {
+				rockchip,pins =
+					<4 8 RK_FUNC_2 &pcfg_pull_up>,
+					<4 9 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2b {
+			uart2b_xfer: uart2b-xfer {
+				rockchip,pins =
+					<4 16 RK_FUNC_2 &pcfg_pull_up>,
+					<4 17 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart2c {
+			uart2c_xfer: uart2c-xfer {
+				rockchip,pins =
+					<4 19 RK_FUNC_1 &pcfg_pull_up>,
+					<4 20 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uart3 {
+			uart3_xfer: uart3-xfer {
+				rockchip,pins =
+					<3 14 RK_FUNC_2 &pcfg_pull_up>,
+					<3 15 RK_FUNC_2 &pcfg_pull_none>;
+			};
+
+			uart3_cts: uart3-cts {
+				rockchip,pins =
+					<3 18 RK_FUNC_2 &pcfg_pull_none>;
+			};
+
+			uart3_rts: uart3-rts {
+				rockchip,pins =
+					<3 19 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		uart4 {
+			uart4_xfer: uart4-xfer {
+				rockchip,pins =
+					<1 7 RK_FUNC_1 &pcfg_pull_up>,
+					<1 8 RK_FUNC_1 &pcfg_pull_none>;
+			};
+		};
+
+		uarthdcp {
+			uarthdcp_xfer: uarthdcp-xfer {
+				rockchip,pins =
+					<4 21 RK_FUNC_2 &pcfg_pull_up>,
+					<4 22 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		pwm0 {
+			pwm0_pin: pwm0-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			vop0_pwm_pin: vop0-pwm-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
+		pwm1 {
+			pwm1_pin: pwm1-pin {
+				rockchip,pins =
+					<4 22 RK_FUNC_1 &pcfg_pull_none>;
+			};
+
+			vop1_pwm_pin: vop1-pwm-pin {
+				rockchip,pins =
+					<4 18 RK_FUNC_3 &pcfg_pull_none>;
+			};
+		};
+	};
+};
-- 
1.9.1




From pankaj.dev at st.com  Thu Feb 25 18:38:29 2016
From: pankaj.dev at st.com (Pankaj Dev)
Date: Fri, 26 Feb 2016 08:08:29 +0530
Subject: [RFC v1] clk: Add debugfs nodes for enable/disable/set-rate/set-parent
Message-ID: <1456454309-25037-1-git-send-email-pankaj.dev@st.com>

To enhance debug interface for clocks, we add the following
interfaces to the clock nodes created at
/sys/kernel/debug/clk/CLOCK_NAME

1. clk_set_rate : Set new rate to value. Reading returns the
current rate
2. clk_set_parent : Set new parent to parent-name. Reading
returns the current parent
3. clk_prepare_enable : Call clk_prepare_enable X times,
X is the input value
4. clk_disable_unprepare : Call clk_disable_unprepare X
times, X is the input value

This is particularly useful during SoC bring-up phase, and also when
drivers want to verify if some issue is caused by clocks turning off at
wrong moments.

Signed-off-by: Pankaj Dev <pankaj.dev at st.com>

---
 drivers/clk/clk.c |  143 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 143 insertions(+), 0 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index cbc72a1..aa08023 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -21,6 +21,7 @@
 #include <linux/device.h>
 #include <linux/init.h>
 #include <linux/sched.h>
+#include <linux/uaccess.h>
 
 #include "clk.h"
 
@@ -348,6 +349,128 @@ static const struct file_operations clk_dump_fops = {
 	.release	= single_release,
 };
 
+/* Debugfs set_rate entry */
+static int clk_debug_rate_get(void *data, u64 *rate)
+{
+	struct clk_core *c = data;
+
+	*rate = clk_get_rate(c->hw->clk);
+
+	return 0;
+}
+
+static int clk_debug_rate_set(void *data, u64 rate)
+{
+	struct clk_core *c = data;
+
+	return clk_set_rate(c->hw->clk, rate);
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(clk_debug_rate_fops, clk_debug_rate_get,
+			clk_debug_rate_set, "%lld\n");
+
+/* Debugfs prepare_enable entry */
+static int clk_debug_prep_enable(void *data, u64 count)
+{
+	struct clk_core *c = data;
+	int i, ret = 0;
+
+	for (i = 0; i < count; i++) {
+		ret = clk_prepare_enable(c->hw->clk);
+		if (ret)
+			return ret;
+	}
+
+	return ret;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(clk_debug_prep_enable_fops, NULL,
+			clk_debug_prep_enable, "%lld\n");
+
+/* Debugfs disable_unprepare entry */
+static int clk_debug_disable_unprep(void *data, u64 count)
+{
+	struct clk_core *c = data;
+	int i;
+
+	for (i = 0; i < count; i++)
+		clk_disable_unprepare(c->hw->clk);
+
+	return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(clk_debug_disable_unprep_fops, NULL,
+			clk_debug_disable_unprep, "%lld\n");
+
+/* Debugfs set_parent entry */
+static int clk_debug_parent_get(struct file *file,
+					char __user *user_buf,
+					size_t count, loff_t *ppos)
+{
+	struct clk_core *c = file->private_data;
+	struct clk *p;
+	int ret;
+
+	if (*ppos)		/* continued read */
+		return 0;
+
+	p = clk_get_parent(c->hw->clk);
+	count = min(strlen(__clk_get_name(p)), count);
+
+	ret = copy_to_user(user_buf, __clk_get_name(p), count);
+	if (ret) {
+		pr_err("%s: error reading data\n", __func__);
+		return -EINVAL;
+	}
+
+	/* Add \n */
+	ret = copy_to_user(user_buf + count, "\n", 1);
+	if (ret) {
+		pr_err("%s: error reading data\n", __func__);
+		return -EINVAL;
+	}
+	count++;
+
+	*ppos += count;
+
+	return count;
+}
+
+static int clk_debug_parent_set(struct file *file,
+					const char __user *user_buf,
+					size_t count, loff_t *ppos)
+{
+	struct clk_core *c = file->private_data;
+	struct clk *p;
+	char pname[50]; /* 50 char shud be enough for clock name + \0 */
+	int ret;
+
+	count = min(sizeof(pname), count);
+	strncpy_from_user(pname, user_buf, count);
+	pname[count - 1] = 0; /* NULL terminate */
+
+	p = __clk_lookup(pname);
+	if (!p) {
+			pr_err("%s: %s not found\n", __func__, pname);
+			return -EINVAL;
+	}
+
+	ret = clk_set_parent(c->hw->clk, p);
+	if (ret) {
+		pr_err("%s: %s Incorrect Argument\n", __func__, pname);
+		return -EINVAL;
+	}
+
+	return count;
+}
+
+static const struct file_operations clk_debug_parent_fops = {
+	.open = simple_open,
+	.read		= clk_debug_parent_get,
+	.write		= clk_debug_parent_set,
+};
+
+/* caller must hold prepare_lock */
 static int clk_debug_create_one(struct clk_core *clk, struct dentry *pdentry)
 {
 	struct dentry *d;
@@ -405,6 +528,26 @@ static int clk_debug_create_one(struct clk_core *clk, struct dentry *pdentry)
 			goto err_out;
 	}
 
+	d = debugfs_create_file("clk_set_rate", S_IRUGO | S_IWUSR, clk->dentry,
+				clk, &clk_debug_rate_fops);
+	if (!d)
+		goto err_out;
+
+	d = debugfs_create_file("clk_set_parent", S_IRUGO | S_IWUSR,
+				clk->dentry, clk, &clk_debug_parent_fops);
+	if (!d)
+		goto err_out;
+
+	d = debugfs_create_file("clk_prepare_enable", S_IWUSR, clk->dentry,
+				clk, &clk_debug_prep_enable_fops);
+	if (!d)
+		goto err_out;
+
+	d = debugfs_create_file("clk_disable_unprepare", S_IWUSR, clk->dentry,
+				clk, &clk_debug_disable_unprep_fops);
+	if (!d)
+		goto err_out;
+
 	ret = 0;
 	goto out;
 
-- 
1.7.5.4



From leo.yan at linaro.org  Thu Feb 25 19:43:42 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Fri, 26 Feb 2016 11:43:42 +0800
Subject: [PATCH v2 0/5] thermal: hisilicon: enable power allocator for Hi6220
Message-ID: <1456458227-12950-1-git-send-email-leo.yan@linaro.org>

Hi6220 has octa-core so it has quite high power consumption when run
benchmark and introduces high temperature for SoC. So need enable
thermal governor to control temperature and also cannot hurt much for
performance after impose cooling operations on CPU.

This patch series is to enable power allocator for Hi6220. Patch 1 is to
change "hysteresis" as optional property for trip points, so when enable
power allocator governor we can ignore this property.

During profiling also found two issues for thermal sensor's driver. The
power allocator just uses only one sensor, so patch 2 is to fix sensor
driver to let it can initialize driver successfully with only enabling
one sensor; patch 3 is to dismiss warning of IRQ imbalance enabling.

After profiling on Hikey, the power model has been simplized with only
dynamic coefficient, and now it's convienence to pass it from CPU node.
So patch 4 and 5 bind sensor and pass power model parameters.

This patch series have been tested on 96boards Hikey.

Changes from v1:
* According to Javi's review, removed unecessary properties for DT
* Add patch 1 for change "hysteresis" as optional property
* Add patch 3 to fix IRQ imbalance enabling issue


Leo Yan (5):
  thermal: change "hysteresis" as optional property
  thermal: hisilicon: support to use any sensor
  thermal: hisilicon: fix IRQ imbalance enabling
  arm64: dts: register Hi6220's thermal sensor
  arm64: dts: register Hi6220's thermal zone for power allocator

 .../devicetree/bindings/thermal/thermal.txt        |  9 ++---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi          | 42 ++++++++++++++++++++++
 drivers/thermal/hisi_thermal.c                     | 40 ++++++++++++---------
 drivers/thermal/of-thermal.c                       |  9 +++--
 4 files changed, 75 insertions(+), 25 deletions(-)

-- 
1.9.1



From leo.yan at linaro.org  Thu Feb 25 19:43:43 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Fri, 26 Feb 2016 11:43:43 +0800
Subject: [PATCH v2 1/5] thermal: change "hysteresis" as optional property
In-Reply-To: <1456458227-12950-1-git-send-email-leo.yan@linaro.org>
References: <1456458227-12950-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1456458227-12950-2-git-send-email-leo.yan@linaro.org>

The property "hysteresis" is mandatory for trip points, so if without
it the thermal zone cannot register successfully. But "hysteresis" is
ignored in the thermal subsystem and only inquired by several thermal
sensor drivers.

So change "hysteresis" as optional properties.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 Documentation/devicetree/bindings/thermal/thermal.txt | 9 +++++----
 drivers/thermal/of-thermal.c                          | 9 ++++-----
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
index 41b817f..7d79e77 100644
--- a/Documentation/devicetree/bindings/thermal/thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -89,10 +89,6 @@ Required properties:
   Type: signed		in millicelsius.
   Size: one cell
 
-- hysteresis:		A low hysteresis value on temperature property (above).
-  Type: unsigned	This is a relative value, in millicelsius.
-  Size: one cell
-
 - type:			a string containing the trip type. Expected values are:
 	"active":	A trip point to enable active cooling
 	"passive":	A trip point to enable passive cooling
@@ -100,6 +96,11 @@ Required properties:
 	"critical":	Hardware not reliable.
   Type: string
 
+Optional properties:
+- hysteresis:		A low hysteresis value on temperature property (above).
+  Type: unsigned	This is a relative value, in millicelsius.
+  Size: one cell
+
 * Cooling device maps
 
 The cooling device maps node is a node to describe how cooling devices
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 9043f8f..ab05500 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -689,11 +689,10 @@ static int thermal_of_populate_trip(struct device_node *np,
 	trip->temperature = prop;
 
 	ret = of_property_read_u32(np, "hysteresis", &prop);
-	if (ret < 0) {
-		pr_err("missing hysteresis property\n");
-		return ret;
-	}
-	trip->hysteresis = prop;
+	if (ret < 0)
+		pr_warning("missing hysteresis property\n");
+	else
+		trip->hysteresis = prop;
 
 	ret = thermal_of_get_trip_type(np, &trip->type);
 	if (ret < 0) {
-- 
1.9.1



From soren.brinkmann at xilinx.com  Thu Feb 25 19:45:15 2016
From: soren.brinkmann at xilinx.com (=?utf-8?B?U8O2cmVu?= Brinkmann)
Date: Thu, 25 Feb 2016 19:45:15 -0800
Subject: [PATCH 50/50] pinctrl: zynq: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-51-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-51-git-send-email-ldewangan@nvidia.com>
Message-ID: <20160226034515.GA3173@xsjsorenbubuntu>

On Wed, 2016-02-24 at 18:46:15 +0530, Laxman Dewangan wrote:
> Use devm_pinctrl_register() for pin control registration and
> remove the need of .remove callback.
> 
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Michal Simek <michal.simek at xilinx.com>
> Cc: S?ren Brinkmann <soren.brinkmann at xilinx.com>
> Cc: linux-gpio at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
Acked-by: S?ren Brinkmann <soren.brinkmann at xilinx.com>

	S?ren


From leo.yan at linaro.org  Thu Feb 25 19:43:44 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Fri, 26 Feb 2016 11:43:44 +0800
Subject: [PATCH v2 2/5] thermal: hisilicon: support to use any sensor
In-Reply-To: <1456458227-12950-1-git-send-email-leo.yan@linaro.org>
References: <1456458227-12950-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1456458227-12950-3-git-send-email-leo.yan@linaro.org>

In current code sensor driver registers all 4 sensors together and if
any of them has not bound to thermal zone successfully then driver will
return failure for driver's initialization. As a result, if DT binds
thermal zone with only one sensor, then the thermal driver will not work
well anymore.

So this patch is to fix this issue. It allows the thermal sensor driver
can register any number sensors at initialization phase, and fix up code
for other related code to skip related sensor's accessing if the sensor
has not been enabled in initialization phase.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 drivers/thermal/hisi_thermal.c | 33 ++++++++++++++++++++-------------
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 5e820b5..7a3e5d8 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -160,7 +160,7 @@ static int hisi_thermal_get_temp(void *_sensor, int *temp)
 	struct hisi_thermal_sensor *sensor = _sensor;
 	struct hisi_thermal_data *data = sensor->thermal;
 
-	int sensor_id = 0, i;
+	int sensor_id = -1, i;
 	long max_temp = 0;
 
 	*temp = hisi_thermal_get_sensor_temp(data, sensor);
@@ -168,12 +168,19 @@ static int hisi_thermal_get_temp(void *_sensor, int *temp)
 	sensor->sensor_temp = *temp;
 
 	for (i = 0; i < HISI_MAX_SENSORS; i++) {
+		if (!data->sensors[i].tzd)
+			continue;
+
 		if (data->sensors[i].sensor_temp >= max_temp) {
 			max_temp = data->sensors[i].sensor_temp;
 			sensor_id = i;
 		}
 	}
 
+	/* If no sensor has been enabled, then skip to enable irq */
+	if (sensor_id == -1)
+		return 0;
+
 	mutex_lock(&data->thermal_lock);
 	data->irq_bind_sensor = sensor_id;
 	mutex_unlock(&data->thermal_lock);
@@ -226,8 +233,12 @@ static irqreturn_t hisi_thermal_alarm_irq_thread(int irq, void *dev)
 		 sensor->thres_temp / 1000);
 	mutex_unlock(&data->thermal_lock);
 
-	for (i = 0; i < HISI_MAX_SENSORS; i++)
+	for (i = 0; i < HISI_MAX_SENSORS; i++) {
+		if (!data->sensors[i].tzd)
+			continue;
+
 		thermal_zone_device_update(data->sensors[i].tzd);
+	}
 
 	return IRQ_HANDLED;
 }
@@ -247,6 +258,7 @@ static int hisi_thermal_register_sensor(struct platform_device *pdev,
 				sensor, &hisi_of_thermal_ops);
 	if (IS_ERR(sensor->tzd)) {
 		ret = PTR_ERR(sensor->tzd);
+		sensor->tzd = NULL;
 		dev_err(&pdev->dev, "failed to register sensor id %d: %d\n",
 			sensor->id, ret);
 		return ret;
@@ -334,25 +346,17 @@ static int hisi_thermal_probe(struct platform_device *pdev)
 	for (i = 0; i < HISI_MAX_SENSORS; ++i) {
 		ret = hisi_thermal_register_sensor(pdev, data,
 						   &data->sensors[i], i);
-		if (ret) {
+		if (ret)
 			dev_err(&pdev->dev,
 				"failed to register thermal sensor: %d\n", ret);
-			goto err_get_sensor_data;
-		}
+		else
+			hisi_thermal_toggle_sensor(&data->sensors[i], true);
 	}
 
 	hisi_thermal_enable_bind_irq_sensor(data);
 	data->irq_enabled = true;
 
-	for (i = 0; i < HISI_MAX_SENSORS; i++)
-		hisi_thermal_toggle_sensor(&data->sensors[i], true);
-
 	return 0;
-
-err_get_sensor_data:
-	clk_disable_unprepare(data->clk);
-
-	return ret;
 }
 
 static int hisi_thermal_remove(struct platform_device *pdev)
@@ -363,6 +367,9 @@ static int hisi_thermal_remove(struct platform_device *pdev)
 	for (i = 0; i < HISI_MAX_SENSORS; i++) {
 		struct hisi_thermal_sensor *sensor = &data->sensors[i];
 
+		if (!sensor->tzd)
+			continue;
+
 		hisi_thermal_toggle_sensor(sensor, false);
 		thermal_zone_of_sensor_unregister(&pdev->dev, sensor->tzd);
 	}
-- 
1.9.1



From leo.yan at linaro.org  Thu Feb 25 19:43:45 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Fri, 26 Feb 2016 11:43:45 +0800
Subject: [PATCH v2 3/5] thermal: hisilicon: fix IRQ imbalance enabling
In-Reply-To: <1456458227-12950-1-git-send-email-leo.yan@linaro.org>
References: <1456458227-12950-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1456458227-12950-4-git-send-email-leo.yan@linaro.org>

When register sensors into thermal zone during initialization phase, it
reports error for IRQ imbalance enabling:

[    2.040713] WARNING: at kernel/irq/manage.c:513
[    2.040719] Modules linked in:
[    2.040721]
[    2.040729] CPU: 1 PID: 804 Comm: irq/33-hisi_the Not tainted 4.5.0-rc4+ #505
[    2.040732] Hardware name: HiKey Development Board (DT)
[    2.040736] task: ffffffc03ae82580 ti: ffffffc0379c8000 task.ti: ffffffc0379c8000
[    2.040745] PC is at __enable_irq+0x74/0x84
[    2.040749] LR is at __enable_irq+0x74/0x84

This warning is for IRQ imbalance enabling, which is caused by
enable_irq() twice. During sensor's initialization it tries to enable
IRQ, the driver will call thermal_zone_of_sensor_register() to bind
sensors and read sensor's temperature. But at this moment the flag
"data->irq_enabled" has been not initialized as correct state, so it
finally introduces the function enabled_irq() to be called twice. In
essentially this is caused by the flag "data->irq_enabled" is
inconsistent with real hardware IRQ enabling state.

So this patch is to fix this issue, firstly init "irq_enabled" flag
before binding sensors to thermal zone. Also change to use the function
irq_get_irqchip_state() to read back real interrupt line state.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 drivers/thermal/hisi_thermal.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
index 7a3e5d8..982ffd1 100644
--- a/drivers/thermal/hisi_thermal.c
+++ b/drivers/thermal/hisi_thermal.c
@@ -343,6 +343,10 @@ static int hisi_thermal_probe(struct platform_device *pdev)
 		return ret;
 	}
 
+	hisi_thermal_enable_bind_irq_sensor(data);
+	irq_get_irqchip_state(data->irq, IRQCHIP_STATE_MASKED,
+			      &data->irq_enabled);
+
 	for (i = 0; i < HISI_MAX_SENSORS; ++i) {
 		ret = hisi_thermal_register_sensor(pdev, data,
 						   &data->sensors[i], i);
@@ -353,9 +357,6 @@ static int hisi_thermal_probe(struct platform_device *pdev)
 			hisi_thermal_toggle_sensor(&data->sensors[i], true);
 	}
 
-	hisi_thermal_enable_bind_irq_sensor(data);
-	data->irq_enabled = true;
-
 	return 0;
 }
 
-- 
1.9.1



From leo.yan at linaro.org  Thu Feb 25 19:43:46 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Fri, 26 Feb 2016 11:43:46 +0800
Subject: [PATCH v2 4/5] arm64: dts: register Hi6220's thermal sensor
In-Reply-To: <1456458227-12950-1-git-send-email-leo.yan@linaro.org>
References: <1456458227-12950-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1456458227-12950-5-git-send-email-leo.yan@linaro.org>

Bind thermal sensor driver for Hi6220.

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index f588be9..50ba1b0 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -313,5 +313,14 @@
 			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
 			#mbox-cells = <3>;
 		};
+
+		tsensor: tsensor at 0,f7030700 {
+			compatible = "hisilicon,tsensor";
+			reg = <0x0 0xf7030700 0x0 0x1000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&sys_ctrl 22>;
+			clock-names = "thermal_clk";
+			#thermal-sensor-cells = <1>;
+		};
 	};
 };
-- 
1.9.1



From leo.yan at linaro.org  Thu Feb 25 19:43:47 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Fri, 26 Feb 2016 11:43:47 +0800
Subject: [PATCH v2 5/5] arm64: dts: register Hi6220's thermal zone for power
 allocator
In-Reply-To: <1456458227-12950-1-git-send-email-leo.yan@linaro.org>
References: <1456458227-12950-1-git-send-email-leo.yan@linaro.org>
Message-ID: <1456458227-12950-6-git-send-email-leo.yan@linaro.org>

With profiling Hi6220's power modeling so get dynamic coefficient and
sustainable power. So pass these parameters from DT.

Now enable power allocator with only one actor for CPU part, so directly
use cluster0's thermal sensor for monitoring temperature.

Reviewed-by: Javi Merino <javi.merino at arm.com>
Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 33 +++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 50ba1b0..d8b963c 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -6,6 +6,7 @@
 
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/hi6220-clock.h>
+#include <dt-bindings/thermal/thermal.h>
 
 / {
 	compatible = "hisilicon,hi6220";
@@ -87,6 +88,7 @@
 			cooling-max-level = <0>;
 			#cooling-cells = <2>; /* min followed by max */
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
+			dynamic-power-coefficient = <311>;
 		};
 
 		cpu1: cpu at 1 {
@@ -322,5 +324,36 @@
 			clock-names = "thermal_clk";
 			#thermal-sensor-cells = <1>;
 		};
+
+		thermal-zones {
+
+			cls0: cls0 {
+				polling-delay = <1000>;
+				polling-delay-passive = <100>;
+				sustainable-power = <3326>;
+
+				/* sensor ID */
+				thermal-sensors = <&tsensor 2>;
+
+				trips {
+					threshold: trip-point at 0 {
+						temperature = <65000>;
+						type = "passive";
+					};
+
+					target: trip-point at 1 {
+						temperature = <75000>;
+						type = "passive";
+					};
+				};
+
+				cooling-maps {
+					map0 {
+						trip = <&target>;
+						cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+					};
+				};
+			};
+		};
 	};
 };
-- 
1.9.1



From alim.akhtar at samsung.com  Thu Feb 25 20:05:01 2016
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Fri, 26 Feb 2016 09:35:01 +0530
Subject: [PATCH] arm64: dts: Add tmu node for exynos7
In-Reply-To: <56CE7DAC.4000803@samsung.com>
References: <1456370865-10086-1-git-send-email-pankaj.dubey@samsung.com>
 <56CE7DAC.4000803@samsung.com>
Message-ID: <56CFCEED.5080709@samsung.com>

Hi Krzysztof,

On 02/25/2016 09:36 AM, Krzysztof Kozlowski wrote:
> On 25.02.2016 12:27, Pankaj Dubey wrote:
>> From: Alim Akhtar <alim.akhtar at samsung.com>
>>
>> This patch adds tmu node, related temprature sensor and triping
>> point data for Atlas cpu core found on exynos7 SoC.
>>
>> Signed-off-by: Alim Akhtar <alim.akhtar at samsung.com>
>
> Yours Sob is missing.
>
> Cc-ed Lukasz Majewski.
>
Thanks
> Lukasz,
> Your review or ack would be appreciated.
>
>
>> ---
>>   .../boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi   |   25 +++++++++
>>   .../arm64/boot/dts/exynos/exynos7-trip-points.dtsi |   55 ++++++++++++++++++++
>>   arch/arm64/boot/dts/exynos/exynos7.dtsi            |   20 +++++++
>>   3 files changed, 100 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
>>   create mode 100644 arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
>> new file mode 100644
>> index 0000000..1d6dcf2
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
>> @@ -0,0 +1,25 @@
>> +/*
>> + * Device tree sources for Exynos7 TMU sensor configuration
>> + *
>> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
>> + *		http://www.samsung.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.
>> + *
>> + */
>> +
>> +#include <dt-bindings/thermal/thermal_exynos.h>
>> +
>> +#thermal-sensor-cells = <0>;
>> +samsung,tmu_gain = <9>;
>> +samsung,tmu_reference_voltage = <17>;
>> +samsung,tmu_noise_cancel_mode = <4>;
>> +samsung,tmu_efuse_value = <75>;
>> +samsung,tmu_min_efuse_value = <15>;
>> +samsung,tmu_max_efuse_value = <100>;
>> +samsung,tmu_first_point_trim = <25>;
>> +samsung,tmu_second_point_trim = <85>;
>> +samsung,tmu_default_temp_offset = <50>;
>> +samsung,tmu_cal_type = <TYPE_ONE_POINT_TRIMMING>;
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
>> new file mode 100644
>> index 0000000..3970545
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
>> @@ -0,0 +1,55 @@
>> +/*
>> + * Device tree sources for default Exynos7 thermal zone definition
>> + *
>> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
>> + *		http://www.samsung.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.
>> + *
>> + */
>> +
>> +trips {
>> +	cpu-alert-0 {
>> +		temperature = <75000>; /* millicelsius */
>> +		hysteresis = <10000>; /* millicelsius */
>> +		type = "passive";
>> +	};
>> +	cpu-alert-1 {
>> +		temperature = <80000>; /* millicelsius */
>> +		hysteresis = <10000>; /* millicelsius */
>> +		type = "passive";
>> +	};
>> +	cpu-alert-2 {
>> +		temperature = <85000>; /* millicelsius */
>> +		hysteresis = <10000>; /* millicelsius */
>> +		type = "passive";
>> +	};
>> +	cpu-alert-3 {
>> +		temperature = <90000>; /* millicelsius */
>> +		hysteresis = <10000>; /* millicelsius */
>> +		type = "passive";
>> +	};
>> +	cpu-alert-4 {
>> +		temperature = <95000>; /* millicelsius */
>> +		hysteresis = <10000>; /* millicelsius */
>> +		type = "passive";
>> +	};
>> +	cpu-alert-5 {
>> +		temperature = <100000>; /* millicelsius */
>> +		hysteresis = <10000>; /* millicelsius */
>> +		type = "passive";
>> +	};
>> +	cpu-alert-6 {
>> +		temperature = <110000>; /* millicelsius */
>> +		hysteresis = <10000>; /* millicelsius */
>> +		type = "passive";
>> +	};
>> +	/* HW Trip point */
>
> The comment looks unnecessary, all of these are HW trip points, right?
>
Ok will remove, on this SoC, only THRES_LEVEL_RISE7 support THERM_TRIP, 
rest are used for thermal throttling via a cooling device like cpu-freq.
>> +	cpu-crit-0 {
>> +		temperature = <115000>; /* millicelsius */
>> +		hysteresis = <0>; /* millicelsius */
>> +		type = "critical";
>> +	};
>> +};
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> index c662f98..fc9d130 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> @@ -27,6 +27,7 @@
>>   		pinctrl6 = &pinctrl_fsys0;
>>   		pinctrl7 = &pinctrl_fsys1;
>>   		pinctrl8 = &pinctrl_bus1;
>> +		tmuctrl0 = &tmuctrl_0;
>
> Why the alias is needed?
>
This is kept to add mutli-instance support of tmu, later ISP and G3D 
will get added.
>>   	};
>>
>>   	cpus {
>> @@ -538,6 +539,25 @@
>>   			clocks = <&clock_peric0 PCLK_PWM>;
>>   			clock-names = "timers";
>>   		};
>> +
>> +		tmuctrl_0: tmu at 10060000 {
>> +			compatible = "samsung,exynos7-tmu";
>> +			reg = <0x10060000 0x200>;
>> +			interrupts = <0 108 0>;
>> +			clocks = <&clock_peris PCLK_TMU>,
>> +				 <&clock_peris SCLK_TMU>;
>> +			clock-names = "tmu_apbif", "tmu_sclk";
>> +			#include "exynos7-tmu-sensor-conf.dtsi"
>> +		};
>> +
>> +		thermal-zones {
>> +			atlas_thermal: atlas-thermal {
>
> The atlas is a Exynos7 specific codename. The name of node should be a
> general class of the device, so maybe:
> 	atlas_thermal: cluster0-thermal
> ?
>
sounds good to me..will add.

> Best regards,
> Krzysztof
>


From jassisinghbrar at gmail.com  Thu Feb 25 20:28:03 2016
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Fri, 26 Feb 2016 09:58:03 +0530
Subject: [GIT PULL 2/2] arm64: X-Gene platforms DTS changes queued for
 v4.6 - part2
In-Reply-To: <CADaLNDkF8_DVYWPFtGU8tYsbbxDWZF9tozW=Zs3EuV4BqO6OuA@mail.gmail.com>
References: <CADaLNDkF8_DVYWPFtGU8tYsbbxDWZF9tozW=Zs3EuV4BqO6OuA@mail.gmail.com>
Message-ID: <CABb+yY2A6bLoNqak5Y8YVLgv=mL1Cx6axnD1trMhKx646NNWFw@mail.gmail.com>

On Fri, Feb 26, 2016 at 8:21 AM, Duc Dang <dhdang at apm.com> wrote:
> Hi Arnd, Olof,
>
> This is the second part of DT changes on X-Gene platforms for v4.6,
> which enables mailbox driver for X-Gene v2 platforms and also enable
> SLIMpro Mailbox I2C driver (a client of the mailbox driver) for both
> X-Gene v1 and v2 platforms.
>
> This series depends on the 3rd patch
> (http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/apm?id=be9c09bcca039d6df9ec736989cdafc68c93fed4)
> of the series "mailbox: Add APM X-Gene platform mailbox driver"
> (https://lkml.org/lkml/2016/2/12/749), which was already in linux-next
> since Feb-15.
>
> Hi Jassi,
>
> Are you going to get the 3rd patch (dts patch) of series "mailbox: Add
> APM X-Gene platform mailbox driver" to your tree? Otherwise, I will
> need to create another pull request for Arnd and Olof.
>
Please create the pull request, I don't think mailbox tree is the
right path for the patch.

Thanks.


From leo.yan at linaro.org  Thu Feb 25 21:28:34 2016
From: leo.yan at linaro.org (Leo Yan)
Date: Fri, 26 Feb 2016 13:28:34 +0800
Subject: [PATCH] arm64: dts: Add L2 cache topology to Hi6220
Message-ID: <1456464514-24380-1-git-send-email-leo.yan@linaro.org>

This patch adds the L2 cache topology on Hi6220. Hi6220 has two
clusters, every cluster has 512KiB L2 cache (32KiB x 16 ways).

Signed-off-by: Leo Yan <leo.yan at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index d8b963c..1746d50 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -82,6 +82,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x0>;
 			enable-method = "psci";
+			next-level-cache = <&CLUSTER0_L2>;
 			clocks = <&stub_clock 0>;
 			operating-points-v2 = <&cpu_opp_table>;
 			cooling-min-level = <4>;
@@ -96,6 +97,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x1>;
 			enable-method = "psci";
+			next-level-cache = <&CLUSTER0_L2>;
 			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
@@ -105,6 +107,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x2>;
 			enable-method = "psci";
+			next-level-cache = <&CLUSTER0_L2>;
 			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
@@ -114,6 +117,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x3>;
 			enable-method = "psci";
+			next-level-cache = <&CLUSTER0_L2>;
 			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
@@ -123,6 +127,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x100>;
 			enable-method = "psci";
+			next-level-cache = <&CLUSTER1_L2>;
 			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
@@ -132,6 +137,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x101>;
 			enable-method = "psci";
+			next-level-cache = <&CLUSTER1_L2>;
 			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
@@ -141,6 +147,7 @@
 			device_type = "cpu";
 			reg = <0x0 0x102>;
 			enable-method = "psci";
+			next-level-cache = <&CLUSTER1_L2>;
 			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
@@ -150,9 +157,18 @@
 			device_type = "cpu";
 			reg = <0x0 0x103>;
 			enable-method = "psci";
+			next-level-cache = <&CLUSTER1_L2>;
 			operating-points-v2 = <&cpu_opp_table>;
 			cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
 		};
+
+		CLUSTER0_L2: l2-cache0 {
+			compatible = "cache";
+		};
+
+		CLUSTER1_L2: l2-cache1 {
+			compatible = "cache";
+		};
 	};
 
 	cpu_opp_table: cpu_opp_table {
-- 
1.9.1



From plaes at plaes.org  Thu Feb 25 21:56:55 2016
From: plaes at plaes.org (Priit Laes)
Date: Fri, 26 Feb 2016 07:56:55 +0200
Subject: [PATCH RESEND 0/2] spi: sun4i: add DMA support
Message-ID: <1456466217-6793-1-git-send-email-plaes@plaes.org>

While trying to get SPI TFT screen working with Cubietruck, I noticed that
at current state driver didn't actually support SPI data bursts bigger than
n bytes (n is probably ~64 bytes).

Patches below were sent to mailinglists a while ago (May 2015) but apparently
were not addressed to correct maintainers and therefore were never applied.

With those patches, it's now possible to use TFT screens over SPI (fbtft
driver in staging), although there seems to be a possible issue where bigger
data bursts cause the driver to temporarily fall back to PIO mode:

spi_master spi32766: Using DMA mode for transfer
spi_master spi32766: Using PIO mode for transfer
spi_master spi32766: Using PIO mode for transfer
spi_master spi32766: Using PIO mode for transfer
spi_master spi32766: Using PIO mode for transfer
spi_master spi32766: Using PIO mode for transfer
spi_master spi32766: Using DMA mode for transfer
spi_master spi32766: Using PIO mode for transfer
spi_master spi32766: Using PIO mode for transfer
spi_master spi32766: Using PIO mode for transfer
spi_master spi32766: Using PIO mode for transfer
spi_master spi32766: Using PIO mode for transfer


Emilio L?pez (1):
  spi: sun4i: add DMA support

Michal Suchanek (1):
  ARM: sunxi: spi: add notice about SPI FIFO limit.

 drivers/spi/spi-sun4i.c | 142 ++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 130 insertions(+), 12 deletions(-)

-- 
2.7.2



From plaes at plaes.org  Thu Feb 25 21:56:56 2016
From: plaes at plaes.org (Priit Laes)
Date: Fri, 26 Feb 2016 07:56:56 +0200
Subject: [PATCH 1/2] spi: sun4i: add DMA support
In-Reply-To: <1456466217-6793-1-git-send-email-plaes@plaes.org>
References: <1456466217-6793-1-git-send-email-plaes@plaes.org>
Message-ID: <1456466217-6793-2-git-send-email-plaes@plaes.org>

From: Emilio L?pez <emilio at elopez.com.ar>

This patch adds support for 64 byte or bigger transfers on the
sun4i SPI controller. Said transfers will be performed via DMA.

Signed-off-by: Emilio L?pez <emilio at elopez.com.ar>
Tested-by: Michal Suchanek <hramrach at gmail.com>
Tested-by: Priit Laes <plaes at plaes.org>
---
 drivers/spi/spi-sun4i.c | 140 +++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 128 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index 1ddd9e2..78141a6 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -14,6 +14,8 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/device.h>
+#include <linux/dmaengine.h>
+#include <linux/dma-mapping.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/module.h>
@@ -34,6 +36,7 @@
 #define SUN4I_CTL_CPHA				BIT(2)
 #define SUN4I_CTL_CPOL				BIT(3)
 #define SUN4I_CTL_CS_ACTIVE_LOW			BIT(4)
+#define SUN4I_CTL_DMAMC_DEDICATED		BIT(5)
 #define SUN4I_CTL_LMTF				BIT(6)
 #define SUN4I_CTL_TF_RST			BIT(8)
 #define SUN4I_CTL_RF_RST			BIT(9)
@@ -51,6 +54,8 @@
 #define SUN4I_INT_STA_REG		0x10
 
 #define SUN4I_DMA_CTL_REG		0x14
+#define SUN4I_DMA_CTL_RF_READY			BIT(0)
+#define SUN4I_DMA_CTL_TF_NOT_FULL		BIT(10)
 
 #define SUN4I_WAIT_REG			0x18
 
@@ -130,6 +135,13 @@ static inline void sun4i_spi_fill_fifo(struct sun4i_spi *sspi, int len)
 	}
 }
 
+static bool sun4i_spi_can_dma(struct spi_master *master,
+			      struct spi_device *spi,
+			      struct spi_transfer *tfr)
+{
+	return tfr->len >= SUN4I_FIFO_DEPTH;
+}
+
 static void sun4i_spi_set_cs(struct spi_device *spi, bool enable)
 {
 	struct sun4i_spi *sspi = spi_master_get_devdata(spi->master);
@@ -172,14 +184,11 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
 				  struct spi_transfer *tfr)
 {
 	struct sun4i_spi *sspi = spi_master_get_devdata(master);
+	struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
 	unsigned int mclk_rate, div, timeout;
 	unsigned int tx_len = 0;
+	u32 reg, trigger = 0;
 	int ret = 0;
-	u32 reg;
-
-	/* We don't support transfer larger than the FIFO */
-	if (tfr->len > SUN4I_FIFO_DEPTH)
-		return -EINVAL;
 
 	reinit_completion(&sspi->done);
 	sspi->tx_buf = tfr->tx_buf;
@@ -189,7 +198,6 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
 	/* Clear pending interrupts */
 	sun4i_spi_write(sspi, SUN4I_INT_STA_REG, ~0);
 
-
 	reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
 
 	/* Reset FIFOs */
@@ -269,12 +277,65 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
 	sun4i_spi_write(sspi, SUN4I_BURST_CNT_REG, SUN4I_BURST_CNT(tfr->len));
 	sun4i_spi_write(sspi, SUN4I_XMIT_CNT_REG, SUN4I_XMIT_CNT(tx_len));
 
-	/* Fill the TX FIFO */
-	sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH);
-
 	/* Enable the interrupts */
 	sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, SUN4I_INT_CTL_TC);
 
+	if (sun4i_spi_can_dma(master, spi, tfr)) {
+		dev_dbg(&sspi->master->dev, "Using DMA mode for transfer\n");
+
+		if (sspi->tx_buf) {
+			desc_tx = dmaengine_prep_slave_sg(master->dma_tx,
+					tfr->tx_sg.sgl, tfr->tx_sg.nents,
+					DMA_TO_DEVICE,
+					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+			if (!desc_tx) {
+				dev_err(&sspi->master->dev,
+					"Couldn't prepare dma slave\n");
+				return -EIO;
+			}
+
+			trigger |= SUN4I_DMA_CTL_TF_NOT_FULL;
+
+			dmaengine_submit(desc_tx);
+			dma_async_issue_pending(master->dma_tx);
+
+		}
+
+		if (sspi->rx_buf) {
+			desc_rx = dmaengine_prep_slave_sg(master->dma_rx,
+					tfr->rx_sg.sgl, tfr->rx_sg.nents,
+					DMA_FROM_DEVICE,
+					DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+			if (!desc_rx) {
+				dev_err(&sspi->master->dev,
+					"Couldn't prepare dma slave\n");
+				return -EIO;
+			}
+
+			trigger |= SUN4I_DMA_CTL_RF_READY;
+
+			dmaengine_submit(desc_rx);
+			dma_async_issue_pending(master->dma_rx);
+		}
+
+		/* Enable Dedicated DMA requests */
+		reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
+		reg |= SUN4I_CTL_DMAMC_DEDICATED;
+		sun4i_spi_write(sspi, SUN4I_CTL_REG, reg);
+		sun4i_spi_write(sspi, SUN4I_DMA_CTL_REG, trigger);
+	} else {
+		dev_dbg(&sspi->master->dev, "Using PIO mode for transfer\n");
+
+		/* Disable DMA requests */
+		reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
+		sun4i_spi_write(sspi, SUN4I_CTL_REG,
+				reg & ~SUN4I_CTL_DMAMC_DEDICATED);
+		sun4i_spi_write(sspi, SUN4I_DMA_CTL_REG, 0);
+
+		/* Fill the TX FIFO */
+		sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH);
+	}
+
 	/* Start the transfer */
 	reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
 	sun4i_spi_write(sspi, SUN4I_CTL_REG, reg | SUN4I_CTL_XCH);
@@ -286,7 +347,12 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
 		goto out;
 	}
 
-	sun4i_spi_drain_fifo(sspi, SUN4I_FIFO_DEPTH);
+	if (sun4i_spi_can_dma(master, spi, tfr) && desc_rx) {
+		/* The receive transfer should be the last one to finish */
+		dma_wait_for_async_tx(desc_rx);
+	} else {
+		sun4i_spi_drain_fifo(sspi, SUN4I_FIFO_DEPTH);
+	}
 
 out:
 	sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, 0);
@@ -351,6 +417,7 @@ static int sun4i_spi_runtime_suspend(struct device *dev)
 
 static int sun4i_spi_probe(struct platform_device *pdev)
 {
+	struct dma_slave_config dma_sconfig;
 	struct spi_master *master;
 	struct sun4i_spi *sspi;
 	struct resource	*res;
@@ -386,7 +453,9 @@ static int sun4i_spi_probe(struct platform_device *pdev)
 		goto err_free_master;
 	}
 
+	init_completion(&sspi->done);
 	sspi->master = master;
+	master->can_dma = sun4i_spi_can_dma;
 	master->set_cs = sun4i_spi_set_cs;
 	master->transfer_one = sun4i_spi_transfer_one;
 	master->num_chipselect = 4;
@@ -409,7 +478,45 @@ static int sun4i_spi_probe(struct platform_device *pdev)
 		goto err_free_master;
 	}
 
-	init_completion(&sspi->done);
+	master->dma_tx = dma_request_slave_channel_reason(&pdev->dev, "tx");
+	if (IS_ERR(master->dma_tx)) {
+		dev_err(&pdev->dev, "Unable to acquire DMA channel TX\n");
+		ret = PTR_ERR(master->dma_tx);
+		goto err_free_master;
+	}
+
+	dma_sconfig.direction = DMA_MEM_TO_DEV;
+	dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	dma_sconfig.dst_addr = res->start + SUN4I_TXDATA_REG;
+	dma_sconfig.src_maxburst = 1;
+	dma_sconfig.dst_maxburst = 1;
+
+	ret = dmaengine_slave_config(master->dma_tx, &dma_sconfig);
+	if (ret) {
+		dev_err(&pdev->dev, "Unable to configure TX DMA slave\n");
+		goto err_tx_dma_release;
+	}
+
+	master->dma_rx = dma_request_slave_channel_reason(&pdev->dev, "rx");
+	if (IS_ERR(master->dma_rx)) {
+		dev_err(&pdev->dev, "Unable to acquire DMA channel RX\n");
+		ret = PTR_ERR(master->dma_rx);
+		goto err_tx_dma_release;
+	}
+
+	dma_sconfig.direction = DMA_DEV_TO_MEM;
+	dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
+	dma_sconfig.src_addr = res->start + SUN4I_RXDATA_REG;
+	dma_sconfig.src_maxburst = 1;
+	dma_sconfig.dst_maxburst = 1;
+
+	ret = dmaengine_slave_config(master->dma_rx, &dma_sconfig);
+	if (ret) {
+		dev_err(&pdev->dev, "Unable to configure RX DMA slave\n");
+		goto err_rx_dma_release;
+	}
 
 	/*
 	 * This wake-up/shutdown pattern is to be able to have the
@@ -418,7 +525,7 @@ static int sun4i_spi_probe(struct platform_device *pdev)
 	ret = sun4i_spi_runtime_resume(&pdev->dev);
 	if (ret) {
 		dev_err(&pdev->dev, "Couldn't resume the device\n");
-		goto err_free_master;
+		goto err_rx_dma_release;
 	}
 
 	pm_runtime_set_active(&pdev->dev);
@@ -436,6 +543,10 @@ static int sun4i_spi_probe(struct platform_device *pdev)
 err_pm_disable:
 	pm_runtime_disable(&pdev->dev);
 	sun4i_spi_runtime_suspend(&pdev->dev);
+err_rx_dma_release:
+	dma_release_channel(master->dma_rx);
+err_tx_dma_release:
+	dma_release_channel(master->dma_tx);
 err_free_master:
 	spi_master_put(master);
 	return ret;
@@ -443,8 +554,13 @@ err_free_master:
 
 static int sun4i_spi_remove(struct platform_device *pdev)
 {
+	struct spi_master *master = platform_get_drvdata(pdev);
+
 	pm_runtime_disable(&pdev->dev);
 
+	dma_release_channel(master->dma_rx);
+	dma_release_channel(master->dma_tx);
+
 	return 0;
 }
 
-- 
2.7.2



From plaes at plaes.org  Thu Feb 25 21:56:57 2016
From: plaes at plaes.org (Priit Laes)
Date: Fri, 26 Feb 2016 07:56:57 +0200
Subject: [PATCH 2/2] ARM: sunxi: spi: add notice about SPI FIFO limit.
In-Reply-To: <1456466217-6793-1-git-send-email-plaes@plaes.org>
References: <1456466217-6793-1-git-send-email-plaes@plaes.org>
Message-ID: <1456466217-6793-3-git-send-email-plaes@plaes.org>

From: Michal Suchanek <hramrach at gmail.com>

When testing SPI without DMA I noticed that filling the FIFO on the
spi controller causes timeout. This should never happen with DMA support
so just adding a comment.

Signed-off-by: Michal Suchanek <hramrach at gmail.com>
---
 drivers/spi/spi-sun4i.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index 78141a6..b750664 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -333,7 +333,9 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
 		sun4i_spi_write(sspi, SUN4I_DMA_CTL_REG, 0);
 
 		/* Fill the TX FIFO */
-		sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH);
+		/* Filling the fifo fully causes timeout for some reason - at least on spi2 on a10s */
+		/* The can_dma check is txlen >= SUN4I_FIFO_DEPTH so with DMA this should never happen anyway. */
+		sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH - 1);
 	}
 
 	/* Start the transfer */
-- 
2.7.2



From zhangqing at rock-chips.com  Thu Feb 25 22:10:21 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Fri, 26 Feb 2016 14:10:21 +0800
Subject: [PATCH v4 1/6] rockchip: power-domain: make idle handling optional
In-Reply-To: <1456467026-16030-1-git-send-email-zhangqing@rock-chips.com>
References: <1456467026-16030-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1456467026-16030-2-git-send-email-zhangqing@rock-chips.com>

Not all new socs need to handle idle states on domain state changes,
so add the possibility to make them optional.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 drivers/soc/rockchip/pm_domains.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 18aee6b..c46312d 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -68,9 +68,9 @@ struct rockchip_pmu {
 {						\
 	.pwr_mask = BIT(pwr),			\
 	.status_mask = BIT(status),		\
-	.req_mask = BIT(req),			\
-	.idle_mask = BIT(idle),			\
-	.ack_mask = BIT(ack),			\
+	.req_mask = (req >= 0) ? BIT(req) : 0,		\
+	.idle_mask = (idle >= 0) ? BIT(idle) : 0,	\
+	.ack_mask = (ack >= 0) ? BIT(ack) : 0,		\
 }
 
 #define DOMAIN_RK3288(pwr, status, req)		\
@@ -96,6 +96,9 @@ static int rockchip_pmu_set_idle_request(struct rockchip_pm_domain *pd,
 	struct rockchip_pmu *pmu = pd->pmu;
 	unsigned int val;
 
+	if (pd_info->req_mask == 0)
+		return 0;
+
 	regmap_update_bits(pmu->regmap, pmu->info->req_offset,
 			   pd_info->req_mask, idle ? -1U : 0);
 
-- 
1.9.1




From zhangqing at rock-chips.com  Thu Feb 25 22:10:22 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Fri, 26 Feb 2016 14:10:22 +0800
Subject: [PATCH v4 2/6] power-domain: allow domains only handling idle requests
In-Reply-To: <1456467026-16030-1-git-send-email-zhangqing@rock-chips.com>
References: <1456467026-16030-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1456467026-16030-3-git-send-email-zhangqing@rock-chips.com>

On some Rockchip SoC there exist child-domains only handling their
idle state with the actual power-state handled by a parent-domain.

So allow such types of domains. For them, we can determine their
state (on/of) by checking the inverse idle-state instead.

There exist one special case if both idle as well power handling
were set as not present, but as the domain-data is defined in the
code itself, we can expect the reasonable developer to define them

So allow such types of domains. For them, we can determine their
state (on/of) by checking the inverse idle-state instead.

There exist one special case if both idle as well power handling
were set as not present, but as the domain-data is defined in the
code itself, we can expect the reasonable developer to define them
in a correct, without adding more checks.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 drivers/soc/rockchip/pm_domains.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index c46312d..0465a06 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -66,8 +66,8 @@ struct rockchip_pmu {
 
 #define DOMAIN(pwr, status, req, idle, ack)	\
 {						\
-	.pwr_mask = BIT(pwr),			\
-	.status_mask = BIT(status),		\
+	.pwr_mask = (pwr >= 0) ? BIT(pwr) : 0,		\
+	.status_mask = (status >= 0) ? BIT(status) : 0,	\
 	.req_mask = (req >= 0) ? BIT(req) : 0,		\
 	.idle_mask = (idle >= 0) ? BIT(idle) : 0,	\
 	.ack_mask = (ack >= 0) ? BIT(ack) : 0,		\
@@ -119,6 +119,10 @@ static bool rockchip_pmu_domain_is_on(struct rockchip_pm_domain *pd)
 	struct rockchip_pmu *pmu = pd->pmu;
 	unsigned int val;
 
+	/* check idle status for idle-only domains */
+	if (pd->info->status_mask == 0)
+		return !rockchip_pmu_domain_is_idle(pd);
+
 	regmap_read(pmu->regmap, pmu->info->status_offset, &val);
 
 	/* 1'b0: power on, 1'b1: power off */
@@ -130,6 +134,9 @@ static void rockchip_do_pmu_set_power_domain(struct rockchip_pm_domain *pd,
 {
 	struct rockchip_pmu *pmu = pd->pmu;
 
+	if (pd->info->pwr_mask == 0)
+		return;
+
 	regmap_update_bits(pmu->regmap, pmu->info->pwr_offset,
 			   pd->info->pwr_mask, on ? 0 : -1U);
 
-- 
1.9.1




From zhangqing at rock-chips.com  Thu Feb 25 22:10:24 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Fri, 26 Feb 2016 14:10:24 +0800
Subject: [PATCH v4 4/6] dt/bindings: power: add RK3399 SoCs header for
 power-domain
In-Reply-To: <1456467026-16030-1-git-send-email-zhangqing@rock-chips.com>
References: <1456467026-16030-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1456467026-16030-5-git-send-email-zhangqing@rock-chips.com>

According to a description from TRM, add all the power domains

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 include/dt-bindings/power/rk3399-power.h | 53 ++++++++++++++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3399-power.h

diff --git a/include/dt-bindings/power/rk3399-power.h b/include/dt-bindings/power/rk3399-power.h
new file mode 100644
index 0000000..69fbd67
--- /dev/null
+++ b/include/dt-bindings/power/rk3399-power.h
@@ -0,0 +1,53 @@
+#ifndef __DT_BINDINGS_POWER_RK3399_POWER_H__
+#define __DT_BINDINGS_POWER_RK3399_POWER_H__
+
+/* VD_CORE_L */
+#define RK3399_PD_A53_L0	0
+#define RK3399_PD_A53_L1	1
+#define RK3399_PD_A53_L2	2
+#define RK3399_PD_A53_L3	3
+#define RK3399_PD_SCU_L		4
+
+/* VD_CORE_B */
+#define RK3399_PD_A72_B0	5
+#define RK3399_PD_A72_B1	6
+#define RK3399_PD_SCU_B		7
+
+/* VD_CENTER */
+#define RK3399_PD_CENTER	8
+#define RK3399_PD_VCODEC	9
+#define RK3399_PD_RGA		10
+#define RK3399_PD_IEP		11
+#define RK3399_PD_VDU		12
+
+/* VD_LOGIC */
+#define RK3399_PD_PERILP	13
+#define RK3399_PD_PERIHP	14
+#define RK3399_PD_VIO		15
+#define RK3399_PD_VO		16
+#define RK3399_PD_VOPB		17
+#define RK3399_PD_VOPL		18
+#define RK3399_PD_ISP0		19
+#define RK3399_PD_ISP1		20
+#define RK3399_PD_HDCP		21
+#define RK3399_PD_TCPD0		22
+#define RK3399_PD_TCPD1		23
+#define RK3399_PD_GIC		24
+#define RK3399_PD_ALIVE		25
+#define RK3399_PD_USB3		26
+#define RK3399_PD_SD		27
+#define RK3399_PD_CCI		28
+#define RK3399_PD_CCI0		29
+#define RK3399_PD_CCI1		30
+#define RK3399_PD_GMAC		31
+#define RK3399_PD_EMMC		32
+#define RK3399_PD_EDP		33
+#define RK3399_PD_SDIOAUDIO	34
+
+/* VD_GPU */
+#define RK3399_PD_GPU		35
+
+/* VD_PMU */
+#define RK3399_PD_PMU		36
+
+#endif
-- 
1.9.1




From zhangqing at rock-chips.com  Thu Feb 25 22:10:23 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Fri, 26 Feb 2016 14:10:23 +0800
Subject: [PATCH v4 3/6] rockchip: power-domain: add support for sub-power
 domains
In-Reply-To: <1456467026-16030-1-git-send-email-zhangqing@rock-chips.com>
References: <1456467026-16030-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1456467026-16030-4-git-send-email-zhangqing@rock-chips.com>

This patch adds support for making one power domain a sub-domain of
other domain. This is useful for modeling power dependences,
which needs to have more than one power domain enabled to be operational.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 drivers/soc/rockchip/pm_domains.c | 63 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 0465a06..fdb74f9 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -370,6 +370,62 @@ static void rockchip_configure_pd_cnt(struct rockchip_pmu *pmu,
 	regmap_write(pmu->regmap, domain_reg_offset + 4, count);
 }
 
+static int rockchip_pm_add_subdomain(struct rockchip_pmu *pmu,
+				     struct device_node *parent)
+{
+	struct device_node *np;
+	struct generic_pm_domain *child_domain, *parent_domain;
+	int error;
+
+	for_each_child_of_node(parent, np) {
+		u32 idx = ~0;
+
+		if (of_property_read_u32(parent, "reg", &idx)) {
+			dev_err(pmu->dev,
+				"%s: failed to retrieve domain id (reg)\n",
+				parent->name);
+			goto err_out;
+		}
+		parent_domain = pmu->genpd_data.domains[idx];
+
+		error = rockchip_pm_add_one_domain(pmu, np);
+		if (error) {
+			dev_err(pmu->dev, "failed to handle node %s: %d\n",
+				np->name, error);
+			goto err_out;
+		}
+
+		if (of_property_read_u32(np, "reg", &idx)) {
+			dev_err(pmu->dev,
+				"%s: failed to retrieve domain id (reg)\n",
+				np->name);
+			goto err_out;
+		}
+		child_domain = pmu->genpd_data.domains[idx];
+
+		if (pm_genpd_add_subdomain(parent_domain, child_domain)) {
+			dev_err(pmu->dev, "%s failed to add subdomain: %s\n",
+				parent_domain->name, child_domain->name);
+			goto err_out;
+		} else
+			dev_info(pmu->dev, "%s add subdomain: %s\n",
+				parent_domain->name, child_domain->name);
+
+		error = rockchip_pm_add_subdomain(pmu, np);
+		if (error < 0)
+			goto rm_sub_domain;
+	}
+	return 0;
+
+err_out:
+	of_node_put(parent);
+	of_node_put(np);
+	return -EINVAL;
+rm_sub_domain:
+	pm_genpd_remove_subdomain(parent_domain, child_domain);
+	return error;
+}
+
 static int rockchip_pm_domain_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -440,6 +496,13 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
 			of_node_put(node);
 			goto err_out;
 		}
+
+		error = rockchip_pm_add_subdomain(pmu, node);
+		if (error < 0) {
+			dev_err(dev, "failed to handle subdomain node %s: %d\n",
+				node->name, error);
+			goto err_out;
+		}
 	}
 
 	if (error) {
-- 
1.9.1




From zhangqing at rock-chips.com  Thu Feb 25 22:10:20 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Fri, 26 Feb 2016 14:10:20 +0800
Subject: [PATCH v4 0/6] rockchip: power-domain: fix pm domain for support
 RK3399 SoC
Message-ID: <1456467026-16030-1-git-send-email-zhangqing@rock-chips.com>

fix some idle handling
support sub-power domain
add rk3399-power.h
modify document for RK3399 Soc
modify power domain for RK3399 SoC

Elaine Zhang (6):
  rockchip: power-domain: make idle handling optional
  power-domain: allow domains only handling idle requests
  rockchip: power-domain: add support for sub-power domains
  dt/bindings: power: add RK3399 SoCs header for power-domain
  dt/bindings: rockchip: modify document of Rockchip power domains
  rockchip: power-domain: Modify power domain driver for rk3399

 .../bindings/soc/rockchip/power_domain.txt         |  41 ++++++
 drivers/soc/rockchip/pm_domains.c                  | 138 ++++++++++++++++++++-
 include/dt-bindings/power/rk3399-power.h           |  53 ++++++++
 3 files changed, 227 insertions(+), 5 deletions(-)
 create mode 100644 include/dt-bindings/power/rk3399-power.h

-- 
1.9.1




From zhangqing at rock-chips.com  Thu Feb 25 22:12:15 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Fri, 26 Feb 2016 14:12:15 +0800
Subject: [PATCH v4 5/6] dt/bindings: rockchip: modify document of Rockchip
 power domains
In-Reply-To: <1456467026-16030-1-git-send-email-zhangqing@rock-chips.com>
References: <1456467026-16030-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1456467135-16115-1-git-send-email-zhangqing@rock-chips.com>

Add binding documentation for the power domains
found on Rockchip RK3399 SoCs

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 .../bindings/soc/rockchip/power_domain.txt         | 41 ++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
index 13dc6a3..9eb43fa 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -7,6 +7,7 @@ Required properties for power domain controller:
 - compatible: Should be one of the following.
 	"rockchip,rk3288-power-controller" - for RK3288 SoCs.
 	"rockchip,rk3368-power-controller" - for RK3368 SoCs.
+	"rockchip,rk3399-power-controller" - for RK3399 SoCs.
 - #power-domain-cells: Number of cells in a power-domain specifier.
 	Should be 1 for multiple PM domains.
 - #address-cells: Should be 1.
@@ -16,6 +17,7 @@ Required properties for power domain sub nodes:
 - reg: index of the power domain, should use macros in:
 	"include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain.
 	"include/dt-bindings/power/rk3368-power.h" - for RK3368 type power domain.
+	"include/dt-bindings/power/rk3399-power.h" - for RK3399 type power domain.
 - clocks (optional): phandles to clocks which need to be enabled while power domain
 	switches state.
 
@@ -45,12 +47,45 @@ Example:
                 };
         };
 
+Example 2:
+
+	power: power-controller {
+		compatible = "rockchip,rk3399-power-controller";
+		#power-domain-cells = <1>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		/*parent domain*/
+		pd_vio {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <RK3399_PD_VIO>;
+
+			/*child domain of pd_vio*/
+			pd_vo {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <RK3399_PD_VO>;
+
+				/*child domain of pd_vo*/
+				pd_vopb {
+					reg = <RK3399_PD_VOPB>;
+				};
+
+				pd_vopl {
+					reg = <RK3399_PD_VOPL>;
+				};
+			};
+		};
+	};
+
 Node of a device using power domains must have a power-domains property,
 containing a phandle to the power device node and an index specifying which
 power domain to use.
 The index should use macros in:
 	"include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain.
 	"include/dt-bindings/power/rk3368-power.h" - for rk3368 type power domain.
+	"include/dt-bindings/power/rk3399-power.h" - for rk3399 type power domain.
 
 Example of the node using power domain:
 
@@ -65,3 +100,9 @@ Example of the node using power domain:
                 power-domains = <&power RK3368_PD_GPU_1>;
                 /* ... */
         };
+
+	node {
+		/* ... */
+		power-domains = <&power RK3399_PD_VOPB>;
+		/* ... */
+	};
-- 
1.9.1




From zhangqing at rock-chips.com  Thu Feb 25 22:12:50 2016
From: zhangqing at rock-chips.com (Elaine Zhang)
Date: Fri, 26 Feb 2016 14:12:50 +0800
Subject: [PATCH v4 6/6] rockchip: power-domain: Modify power domain driver for
 rk3399
In-Reply-To: <1456467026-16030-1-git-send-email-zhangqing@rock-chips.com>
References: <1456467026-16030-1-git-send-email-zhangqing@rock-chips.com>
Message-ID: <1456467170-16168-1-git-send-email-zhangqing@rock-chips.com>

This driver is modified to support RK3399 SoC.

Signed-off-by: Elaine Zhang <zhangqing at rock-chips.com>
---
 drivers/soc/rockchip/pm_domains.c | 55 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index fdb74f9..8d23fed 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -19,6 +19,7 @@
 #include <linux/mfd/syscon.h>
 #include <dt-bindings/power/rk3288-power.h>
 #include <dt-bindings/power/rk3368-power.h>
+#include <dt-bindings/power/rk3399-power.h>
 
 struct rockchip_domain_info {
 	int pwr_mask;
@@ -79,6 +80,9 @@ struct rockchip_pmu {
 #define DOMAIN_RK3368(pwr, status, req)		\
 	DOMAIN(pwr, status, req, (req) + 16, req)
 
+#define DOMAIN_RK3399(pwr, status, req)                \
+	DOMAIN(pwr, status, req, req, req)
+
 static bool rockchip_pmu_domain_is_idle(struct rockchip_pm_domain *pd)
 {
 	struct rockchip_pmu *pmu = pd->pmu;
@@ -534,6 +538,36 @@ static const struct rockchip_domain_info rk3368_pm_domains[] = {
 	[RK3368_PD_GPU_1]	= DOMAIN_RK3368(17, 16, 2),
 };
 
+static const struct rockchip_domain_info rk3399_pm_domains[] = {
+	[RK3399_PD_TCPD0]	= DOMAIN_RK3399(8, 8, -1),
+	[RK3399_PD_TCPD1]	= DOMAIN_RK3399(9, 9, -1),
+	[RK3399_PD_CCI]	= DOMAIN_RK3399(10, 10, -1),
+	[RK3399_PD_CCI0]	= DOMAIN_RK3399(-1, -1, 15),
+	[RK3399_PD_CCI1]	= DOMAIN_RK3399(-1, -1, 16),
+	[RK3399_PD_PERILP]	= DOMAIN_RK3399(11, 11, 1),
+	[RK3399_PD_PERIHP]	= DOMAIN_RK3399(12, 12, 2),
+	[RK3399_PD_CENTER]	= DOMAIN_RK3399(13, 13, 14),
+	[RK3399_PD_VIO]	= DOMAIN_RK3399(14, 14, 17),
+	[RK3399_PD_GPU]	= DOMAIN_RK3399(15, 15, 0),
+	[RK3399_PD_VCODEC]	= DOMAIN_RK3399(16, 16, 3),
+	[RK3399_PD_VDU]	= DOMAIN_RK3399(17, 17, 4),
+	[RK3399_PD_RGA]	= DOMAIN_RK3399(18, 18, 5),
+	[RK3399_PD_IEP]	= DOMAIN_RK3399(19, 19, 6),
+	[RK3399_PD_VO]	= DOMAIN_RK3399(20, 20, -1),
+	[RK3399_PD_VOPB]	= DOMAIN_RK3399(-1, -1, 7),
+	[RK3399_PD_VOPL]	= DOMAIN_RK3399(-1, -1, 8),
+	[RK3399_PD_ISP0]	= DOMAIN_RK3399(22, 22, 9),
+	[RK3399_PD_ISP1]	= DOMAIN_RK3399(23, 23, 10),
+	[RK3399_PD_HDCP]	= DOMAIN_RK3399(24, 24, 11),
+	[RK3399_PD_GMAC]	= DOMAIN_RK3399(25, 25, 23),
+	[RK3399_PD_EMMC]	= DOMAIN_RK3399(26, 26, 24),
+	[RK3399_PD_USB3]	= DOMAIN_RK3399(27, 27, 12),
+	[RK3399_PD_EDP]	= DOMAIN_RK3399(28, 28, 22),
+	[RK3399_PD_GIC]	= DOMAIN_RK3399(29, 29, 27),
+	[RK3399_PD_SD]	= DOMAIN_RK3399(30, 30, 28),
+	[RK3399_PD_SDIOAUDIO]	= DOMAIN_RK3399(31, 31, 29),
+};
+
 static const struct rockchip_pmu_info rk3288_pmu = {
 	.pwr_offset = 0x08,
 	.status_offset = 0x0c,
@@ -568,6 +602,23 @@ static const struct rockchip_pmu_info rk3368_pmu = {
 	.domain_info = rk3368_pm_domains,
 };
 
+static const struct rockchip_pmu_info rk3399_pmu = {
+	.pwr_offset = 0x14,
+	.status_offset = 0x18,
+	.req_offset = 0x60,
+	.idle_offset = 0x64,
+	.ack_offset = 0x68,
+
+	.core_pwrcnt_offset = 0x9c,
+	.gpu_pwrcnt_offset = 0xa4,
+
+	.core_power_transition_time = 24,
+	.gpu_power_transition_time = 24,
+
+	.num_domains = ARRAY_SIZE(rk3399_pm_domains),
+	.domain_info = rk3399_pm_domains,
+};
+
 static const struct of_device_id rockchip_pm_domain_dt_match[] = {
 	{
 		.compatible = "rockchip,rk3288-power-controller",
@@ -577,6 +628,10 @@ static const struct of_device_id rockchip_pm_domain_dt_match[] = {
 		.compatible = "rockchip,rk3368-power-controller",
 		.data = (void *)&rk3368_pmu,
 	},
+	{
+		.compatible = "rockchip,rk3399-power-controller",
+		.data = (void *)&rk3399_pmu,
+	},
 	{ /* sentinel */ },
 };
 
-- 
1.9.1




From ykk at rock-chips.com  Thu Feb 25 22:24:09 2016
From: ykk at rock-chips.com (Yakir Yang)
Date: Fri, 26 Feb 2016 14:24:09 +0800
Subject: [PATCH v1 0/4] Add clock ids for RK3228 HDMI/VOP modules
In-Reply-To: <2198453.NY4VYR4LaI@phil>
References: <1456308303-29706-1-git-send-email-ykk@rock-chips.com>
 <2198453.NY4VYR4LaI@phil>
Message-ID: <56CFEF89.7020003@rock-chips.com>


On 02/26/2016 09:14 AM, Heiko Stuebner wrote:
> Am Mittwoch, 24. Februar 2016, 18:05:03 schrieb Yakir Yang:
>> Add clocks ids for RK3228 HDMI/VOP modules which driver already have been
>> posted.
>>
>> RK3228 HDMI driver: https://patchwork.kernel.org/patch/7974671
>> RK3228 VOP driver: https://patchwork.kernel.org/patch/7952591
>>
>> Yakir Yang (4):
>>    clk: rockchip: add the new clock ids for RK3228 VOP
>>    clk: rockchip: set the clock ids for RK3228 VOP
>>    clk: rockchip: add the new clock ids for RK3228 HDMI
>>    clk: rockchip: set the clock ids for RK3228 HDMI
> applied all 4 to my clk-branch
Thanks

- Yakir
>
> Thanks
> Heiko
>
>
>




From lv.zheng at intel.com  Thu Feb 25 22:39:32 2016
From: lv.zheng at intel.com (Zheng, Lv)
Date: Fri, 26 Feb 2016 06:39:32 +0000
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <56CB21FA.1090302@linaro.org>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
 <56C470C5.2080203@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>
 <56C63FB5.2030907@hurleysoftware.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4D5A0@SHSMSX101.ccr.corp.intel.com>
 <56C6F660.9020407@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D949@SHSMSX101.ccr.corp.intel.com>
 <56CB21FA.1090302@linaro.org>
Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB5D340@SHSMSX101.ccr.corp.intel.com>

Hi, Aleksey

Though I promised you to have this done in 1 week:
https://github.com/zetalog/acpica/commit/a234569
I implemented the idea and tried the cleanup in Linux.
But unfortunately the cleanup triggered several locking issues inside of ACPICA table API users.
So it doesn't seem to be so easy and quick to make it upstreamed.
And I have to continue to test and improve the cleanup.

I'm sorry for that, hope you can find substitute solutions before the cleanup is upstreamed.

Thanks and best regards
-Lv

> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
> Sent: Monday, February 22, 2016 10:58 PM
> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
> early_acpi_os_unmap_memory()
> 
> Hi,
> 
> On 02/22/2016 05:24 AM, Zheng, Lv wrote:
> > Hi,
> >
> >> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
> >> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
> >> early_acpi_os_unmap_memory()
> >>
> >> Hi Lv,
> >>
> >> On 02/19/2016 05:58 AM, Zheng, Lv wrote:
> >>> Hi,
> >>>
> >>>> From: Peter Hurley [mailto:peter at hurleysoftware.com]
> >>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
> >>>> early_acpi_os_unmap_memory()
> >>>>
> >>>> On 02/17/2016 07:36 PM, Zheng, Lv wrote:
> >>>>> Hi,
> >>>>>
> >>>>>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
> >>>>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
> >>>>>> early_acpi_os_unmap_memory()
> >>>>>>
> >>>>>> Hi Lv,
> >>>>>>
> >>>>>> Thank you for review.
> >>>>>>
> >>>>>> On 02/17/2016 05:51 AM, Zheng, Lv wrote:
> >>>>>>
> >>>>>> [..]
> >>>>>>
> >>>>>>>>> early_acpi_os_unmap_memory() is marked as __init because it calls
> >>>>>>>>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap
> is
> >> not
> >>>>>> set.
> >>>>>>>>>
> >>>>>>>>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
> >>>>>>>>> so it is safe to call early_acpi_os_unmap_memory() from anywhere
> >>>>>>>>>
> >>>>>>>>> We need this function to be non-__init because we need access to
> >>>>>>>>> some tables at unpredictable time--it may be before or after
> >>>>>>>>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port
> >>>> Console
> >>>>>>>>> Redirection) table is needed each time a new console is registered.
> >>>>>>>>> It can be quite early (console_initcall) or when a module is inserted.
> >>>>>>>>> When this table accessed before acpi_gbl_permanent_mmap is set,
> >>>>>>>>> the pointer should be unmapped.  This is exactly what this function
> >>>>>>>>> does.
> >>>>>>>> [Lv Zheng]
> >>>>>>>> Why don't you use another API instead of
> >>>> early_acpi_os_unmap_memory()
> >>>>>> in
> >>>>>>>> case you want to unmap things in any cases.
> >>>>>>>> acpi_os_unmap_memory() should be the one to match this purpose.
> >>>>>>>> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
> >>>>>>
> >>>>>> As far as I understand, there exist two steps in ACPI initialization:
> >>>>>>
> >>>>>> 1. Before acpi_gbl_permanent_mmap is set, tables received with
> >>>>>> acpi_get_table_with_size()
> >>>>>>    are mapped by early_memremap().  If a subsystem gets such a pointer
> it
> >>>>>> should be unmapped.
> >>>>>>
> >>>>>> 2  After acpi_gbl_permanent_mmap is set this pointer should not be
> >>>> unmapped
> >>>>>> at all.
> >>>>>>
> >>>>> [Lv Zheng]
> >>>>> This statement is wrong, this should be:
> >>>>> As long as there is a __reference__ to the mapped table, the pointer
> should
> >>>> not be unmapped.
> >>>>> In fact, we have a series to introduce acpi_put_table() to achieve this.
> >>>>> So your argument is wrong from very first point.
> >>>>>
> >>>>>> That exactly what early_acpi_os_unmap_memory() does--it checks
> >>>>>> acpi_gbl_permanent_mmap.
> >>>>>> If I had used acpi_os_unmap_memory() after
> acpi_gbl_permanent_mmap
> >>>> had
> >>>>>> been set,
> >>>>>> it would have tried to free that pointer with an oops (actually, I
> checked
> >> that
> >>>>>> and got that oops).
> >>>>>>
> >>>>>> So using acpi_os_unmap_memory() is not an option here, but
> >>>>>> early_acpi_os_unmap_memory()
> >>>>>> match perfectly.
> >>>>> [Lv Zheng]
> >>>>> I don't think so.
> >>>>> For definition block tables, we know for sure there will always be
> >> references,
> >>>> until "Unload" opcode is invoked by the AML interpreter.
> >>>>> But for the data tables, OSPMs should use them in this way:
> >>>>> 1. map the table
> >>>>> 2. parse the table and convert it to OS specific structures
> >>>>> 3. unmap the table
> >>>>> This helps to shrink virtual memory address space usages.
> >>>>>
> >>>>> So from this point of view, all data tables should be unmapped right
> after
> >>>> being parsed.
> >>>>> Why do you need the map to be persistent in the kernel address space?
> >>>>> You can always map a small table, but what if the table size is very big?
> >>>>>
> >>>>>>
> >>>>>>>> And in fact early_acpi_os_unmap_memory() should be removed.
> >>>>>>
> >>>>>> I don't think so -- I have explained why.  It does different thing.
> >>>>>> Probably it (and/or other functions in that api) should be renamed.
> >>>>>>
> >>>>> [Lv Zheng]
> >>>>> Just let me ask one more question.
> >>>>> eary_acpi_os_unmap_memory() is not used inside of ACPICA.
> >>>>> How ACPICA can work with just acpi_os_unmap_memory()?
> >>>>> You can check drivers/acpi/tbxxx.c.
> >>>>> Especially: acpi_tb_release_temp_table() and the code invoking it.
> >>>>>
> >>>>>>> [Lv Zheng]
> >>>>>>> One more thing is:
> >>>>>>> If you can't switch your driver to use acpi_os_unmap_memory()
> instead
> >> of
> >>>>>> early_acpi_os_unmap_memory(),
> >>>>>>> then it implies that your driver does have a defect.
> >>>>>>
> >>>>>> I still don't understand what defect, sorry.
> >>>>> [Lv Zheng]
> >>>>> If you can't ensure this sequence for using the data tables:
> >>>>> 1. map the table
> >>>>> 2. parse the table and convert it to OS specific structure
> >>>>> 3. unmap the table
> >>>>> It implies there is a bug in the driver or a bug in the ACPI subsystem core.
> >>>>
> >>>> Exactly.
> >>> [Lv Zheng]
> >>> So it looks to me:
> >>> Changing __init to __ref here is entirely not acceptable.
> >>> This API should stay being invoked during early stage.
> >>> Otherwise, it may leave us untrackable code that maps tables during early
> >> stage and leaks maps to the late stage.
> >>> If Linux contains such kind of code, I'm afraid, it will become impossible to
> >> introduce acpi_put_table() to clean up the mappings.
> >>> Because when acpi_put_table() is called during the late stage to free a map
> >> acquired during the early stage, it then obviously will end up with panic.
> >>
> >> Can you please sugggest a common method to access ACPI tables that
> >> works both before *and* after acpi_gbl_permanent_mmap is set and __init
> >> code
> >> is removed?
> > [Lv Zheng]
> > Do not change __init for now.
> >
> > Currently you should:
> > 1. before acpi_gbl_permanent_mmap is set:
> > acpi_get_table_with_size()
> > parse the table
> > early_acpi_os_unmap_memory()
> > Do your driver early stuff here
> >
> > 2. after acpi_gbl_permanent_mmap is set:
> > acpi_get_table()
> > Parse the table
> > Do your driver late stuff here
> > <- note there is no API now being an inverse of acpi_get_table().
> 
> That's fine.  These are two different methods to access the table.
> I need one that works in both cases.  Of course, they could be combined,
> but I am not sure if I can access the acpi_gbl_permanent_mmap variable--it
> seems to be an implementation detail of ACPI code.
> 
> Instead I am going to use the 1st method once and cache the result like this:
> 
> 
> static int __init parse(void)
> {
> 	static bool parsed;
> 
> 	if (!parsed) {
> 		acpi_get_table_with_size()
> 		/* parse the table and cache the result */
> 		early_acpi_os_unmap_memory()
> 		parse = true;
> 	}
> }
> 
> arch_initcal(parse());
> 
> int __ref the_handler_where_I_need_the_parse_results(void)
> {
> 	parse();
> 
> 	/* use the data */
> }
> 
> I hope you are OK with it.
> 
> > Besides, I'm about to insert error messages between 1 and 2.
> > If an early map is not release, error message will be prompted to the
> developers.
> 
> AFAICS, there is such an error message and I saw it.
> Refer to check_early_ioremap_leak() at mm/early_ioremap.c
> 
> > And if you don't follow the above rules, it mean you are trying to lay a mine,
> waiting for me to step on it.
> > That's why this change is entirely not acceptable.
> 
> Ok, I see.
> 
> > I'm about to send out the cleanup series in 1 week, and will Cc you.
> > You can rebase your code on top of the cleanup series.
> 
> Thank you
> Aleksey Makarov
> 
> >
> > Thanks and best regards
> > -Lv
> >
> >>
> >>> Thanks and best regards
> >>> -Lv
> >>>
> >>>> The central problem here is the way Aleksey is trying to hookup a console.
> >>>>
> >>>> What should be happening in this series is:
> >>>> 1. early map SPCR
> >>>> 2. parse the SPCR table
> >>>> 3. call add_preferred_console() to add the SPCR console to the console
> >> table
> >>>> 4. unmap SPCR
> >>>>
> >>>> This trivial and unobtrusive method would already have a 8250 console
> >>>> running via SPCR. I've already pointed this out in previous reviews.
> >>>>
> >>>> Further, the above method *will be required anyway* for the DBG2 table
> to
> >>>> start an earlycon, which I've already pointed out in previous reviews.
> >>>>
> >>>> Then to enable amba-pl011 console via ACPI, add a console match()
> method
> >>>> similar to the 8250 console match() method, univ8250_console_match().
> >>>>
> >>>> FWIW, PCI earlycon + console support was already submitted once before
> >> but
> >>>> never picked up by GregKH. I think I'll just grab that and re-submit so
> >>>> you would know what to emit for console options in the
> >>>> add_preferred_console().
> >>>>
> >>>>
> >>>> Regards,
> >>>> Peter Hurley
> >>>>
> >>>>
> >>>>>>> There is an early bootup requirement in Linux.
> >>>>>>> Maps acquired during the early stage should be freed by the driver
> during
> >>>> the
> >>>>>> early stage.
> >>>>>>> And the driver should re-acquire the memory map after booting.
> >>>>>>
> >>>>>> Exactly.  That's why I use early_acpi_os_unmap_memory().  The point is
> >> that
> >>>>>> that code can be
> >>>>>> called *before* acpi_gbl_permanent_mmap is set (at early initialization
> >> of
> >>>> for
> >>>>>> example 8250 console)
> >>>>>> or *after* acpi_gbl_permanent_mmap is set (at insertion of a module
> >> that
> >>>>>> registers a console),
> >>>>>> We just can not tell if the received table pointer should or sould not be
> >> freed
> >>>>>> with early_memunmap()
> >>>>>> (actually __acpi_unmap_table() or whatever) without checking
> >>>>>> acpi_gbl_permanent_mmap,
> >>>>>> but that's all too low level.
> >>>>> [Lv Zheng]
> >>>>> The driver should make sure that:
> >>>>> Map/unmap is paired during early stage.
> >>>>> For late stage, it should be another pair of map/unmap.
> >>>>>
> >>>>>>
> >>>>>> Another option, as you describe, is to get this pointer early, don't free it
> >>>>> [Lv Zheng]
> >>>>> I mean you should free it early.
> >>>>>
> >>>>>> untill acpi_gbl_permanent_mmap is set, then free it (with
> >>>>>> early_acpi_os_unmap_memory(), that's
> >>>>>> ok because acpi_gbl_permanent_mmap is set in an init code), then get
> >> the
> >>>>>> persistent
> >>>>>> pointer to the table.  The problem with it is that we can not just watch
> >>>>>> acpi_gbl_permanent_mmap
> >>>>>> to catch this exact moment.  And also accessing
> >> acpi_gbl_permanent_mmap
> >>>> is
> >>>>>> not good as it probably is
> >>>>>> an implementation detail (i. e. too lowlevel) of the ACPI code.
> >>>>>> Or I probably miss what you are suggesting.
> >>>>>>
> >>>>> [Lv Zheng]
> >>>>> I mean, you should:
> >>>>> During early stage:
> >>>>> acpi_os_map_memory()
> >>>>> Parse the table.
> >>>>> acpi_os_unmap_memory().
> >>>>>
> >>>>>>> This is because, during early bootup stage, there are only limited slots
> >>>>>> available for drivers to map memory.
> >>>>>>> So by changing __init to __ref here, you probably will hide many such
> >>>> defects.
> >>>>>>
> >>>>>> What defects?  This funcions checks acpi_gbl_permanent_mmap.
> >>>>>> BTW, exactly the same thing is done in the beginning of
> >>>>>> acpi_os_unmap_memory() and than's ok,
> >>>>>> that function is __ref.
> >>>>>>
> >>>>>>> And solving issues in this way doesn't seem to be an improvement.
> >>>>>>
> >>>>>> Could you please tell me where I am wrong?  I still don't understand
> your
> >>>> point.
> >>>>> [Lv Zheng]
> >>>>> But anyway, the defect should be in ACPI subsystem core.
> >>>>> The cause should be the API itself - acpi_get_table().
> >>>>>
> >>>>> So I agree you can use early_acpi_os_unmap_memory() during the
> period
> >> the
> >>>> root causes are not cleaned up.
> >>>>> But the bottom line is: the driver need to ensure that
> >>>> early_acpi_os_unmap_memory() is always invoked.
> >>>>> As long as you can ensure this, I don't have objections for deploying
> >>>> early_acpi_os_unmap_memory()  for now.
> >>>>>
> >>>>> Thanks and best regards
> >>>>> -Lv
> >>>>>
> >>>>>>
> >>>>>> Thank you
> >>>>>> Aleksey Makarov
> >>>>>>
> >>>>>>>
> >>>>>>> Thanks and best regards
> >>>>>>> -Lv
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Thanks and best regards
> >>>>>>>> -Lv
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
> >>>>>>>>> ---
> >>>>>>>>>  drivers/acpi/osl.c | 6 +++++-
> >>>>>>>>>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>>>>>>>>
> >>>>>>>>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> >>>>>>>>> index 67da6fb..8a552cd 100644
> >>>>>>>>> --- a/drivers/acpi/osl.c
> >>>>>>>>> +++ b/drivers/acpi/osl.c
> >>>>>>>>> @@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void
> >> *virt,
> >>>>>>>>> acpi_size size)
> >>>>>>>>>  }
> >>>>>>>>>  EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
> >>>>>>>>>
> >>>>>>>>> -void __init early_acpi_os_unmap_memory(void __iomem *virt,
> >>>> acpi_size
> >>>>>>>> size)
> >>>>>>>>> +/*
> >>>>>>>>> + * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
> >>>>>>>>> + * so it is safe to call early_acpi_os_unmap_memory() from
> >> anywhere
> >>>>>>>>> + */
> >>>>>>>>> +void __ref early_acpi_os_unmap_memory(void __iomem *virt,
> >>>> acpi_size
> >>>>>>>> size)
> >>>>>>>>>  {
> >>>>>>>>>  	if (!acpi_gbl_permanent_mmap)
> >>>>>>>>>  		__acpi_unmap_table(virt, size);
> >>>>>>>>> --
> >>>>>>>>> 2.7.1
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> in
> >>>>>>>>> the body of a message to majordomo at vger.kernel.org
> >>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-
> >> info.html
> >>>>>>>> --
> >>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> >>>>>>>> the body of a message to majordomo at vger.kernel.org
> >>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-
> info.html
> >>>

From kvalo at codeaurora.org  Thu Feb 25 23:11:36 2016
From: kvalo at codeaurora.org (Kalle Valo)
Date: Fri, 26 Feb 2016 09:11:36 +0200
Subject: [PATCH, RESEND] ssb: host_soc depends on sprom
In-Reply-To: <1456433869-3919332-1-git-send-email-arnd@arndb.de> (Arnd
 Bergmann's message of "Thu, 25 Feb 2016 21:57:43 +0100")
References: <1456433869-3919332-1-git-send-email-arnd@arndb.de>
Message-ID: <8737sgndxz.fsf@purkki.adurom.net>

Arnd Bergmann <arnd at arndb.de> writes:

> Drivers that use the SSB sprom functionality typically 'select SSB_SPROM'
> from Kconfig, but CONFIG_SSB_HOST_SOC misses this, which results in
> a build failure unless at least one of the other drivers that selects
> it is enabled:
>
> drivers/built-in.o: In function `ssb_host_soc_get_invariants':
> (.text+0x459494): undefined reference to `ssb_fill_sprom_with_fallback'
>
> This adds the same select statement that is used elsewhere.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 541c9a84cd85 ("ssb: pick SoC invariants code from MIPS BCM47xx arch")
> ---
>  drivers/ssb/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> I just noticed this hasn't shown up in linux-next yet, so I'm resending
> it to ensure it's still on someone's radar. Please ignore the resend
> if it's already in a tree that is not part of linux-next but will
> be merged eventually.
>
> See https://patchwork.linux-mips.org/patch/12091/ for the original
> submission.

Sorry, I didn't notice that linux-wireless was not CCed and I missed the
patch because it was not in my patchwork queue. But the patch is now
there and I should get to it in few days:

https://patchwork.kernel.org/patch/8426571/

-- 
Kalle Valo


From yamada.masahiro at socionext.com  Thu Feb 25 23:16:06 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 16:16:06 +0900
Subject: [PATCH 0/2] ARM: uniphier: UniPhier updates for Linux 4.6-rc1 (2nd
 round)
Message-ID: <1456470968-7900-1-git-send-email-yamada.masahiro@socionext.com>

Hi Olof,

Here is a small patch series for UniPhier SoC updates.



Masahiro Yamada (2):
  ARM: uniphier: add missing of_node_put()
  ARM: uniphier: rework SMP code to support new System Bus binding

 arch/arm/mach-uniphier/platsmp.c | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)

-- 
1.9.1



From yamada.masahiro at socionext.com  Thu Feb 25 23:16:07 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 16:16:07 +0900
Subject: [PATCH 1/2] ARM: uniphier: add missing of_node_put()
In-Reply-To: <1456470968-7900-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456470968-7900-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456470968-7900-2-git-send-email-yamada.masahiro@socionext.com>

This node pointer is allocated by of_find_compatible_node() in this
function.  It should be put before exitting this function.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/mach-uniphier/platsmp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-uniphier/platsmp.c b/arch/arm/mach-uniphier/platsmp.c
index e1cfc1d..8d988f5 100644
--- a/arch/arm/mach-uniphier/platsmp.c
+++ b/arch/arm/mach-uniphier/platsmp.c
@@ -100,6 +100,7 @@ static int __init uniphier_smp_prepare_trampoline(unsigned int max_cpus)
 
 	np = of_find_compatible_node(NULL, NULL,
 				"socionext,uniphier-system-bus-controller");
+	of_node_put(np);
 	ret = of_address_to_resource(np, 1, &res);
 	if (ret) {
 		pr_err("failed to get resource of system-bus-controller\n");
-- 
1.9.1



From yamada.masahiro at socionext.com  Thu Feb 25 23:16:08 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 16:16:08 +0900
Subject: [PATCH 2/2] ARM: uniphier: rework SMP code to support new System Bus
 binding
In-Reply-To: <1456470968-7900-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456470968-7900-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456470968-7900-3-git-send-email-yamada.masahiro@socionext.com>

During the review process of the UniPhier System Bus driver
(drivers/bus/uniphier.c), the current binding of the System Bus
Controller turned out to be no good.  In order to use the driver,
some nodes in the device trees must be tweaked.  It would also have
impacts on the SMP code because the SMP related registers are
located in the System Bus Controller block.  This commit reworks
the smp_operations to support the new binding, but still supports
the old binding, too.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/mach-uniphier/platsmp.c | 25 ++++++++++++++++---------
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-uniphier/platsmp.c b/arch/arm/mach-uniphier/platsmp.c
index 8d988f5..6914135 100644
--- a/arch/arm/mach-uniphier/platsmp.c
+++ b/arch/arm/mach-uniphier/platsmp.c
@@ -30,7 +30,7 @@
  * The secondary CPUs check this register from the boot ROM for the jump
  * destination.  After that, it can be reused as a scratch register.
  */
-#define UNIPHIER_SBC_ROM_BOOT_RSV2	0x1208
+#define UNIPHIER_SMPCTRL_ROM_RSV2	0x208
 
 static void __iomem *uniphier_smp_rom_boot_rsv2;
 static unsigned int uniphier_smp_max_cpus;
@@ -98,17 +98,24 @@ static int __init uniphier_smp_prepare_trampoline(unsigned int max_cpus)
 	phys_addr_t rom_rsv2_phys;
 	int ret;
 
-	np = of_find_compatible_node(NULL, NULL,
-				"socionext,uniphier-system-bus-controller");
+	np = of_find_compatible_node(NULL, NULL, "socionext,uniphier-smpctrl");
 	of_node_put(np);
-	ret = of_address_to_resource(np, 1, &res);
-	if (ret) {
-		pr_err("failed to get resource of system-bus-controller\n");
-		return ret;
+	ret = of_address_to_resource(np, 0, &res);
+	if (!ret) {
+		rom_rsv2_phys = res.start + UNIPHIER_SMPCTRL_ROM_RSV2;
+	} else {
+		/* try old binding too */
+		np = of_find_compatible_node(NULL, NULL,
+					     "socionext,uniphier-system-bus-controller");
+		of_node_put(np);
+		ret = of_address_to_resource(np, 1, &res);
+		if (ret) {
+			pr_err("failed to get resource of SMP control\n");
+			return ret;
+		}
+		rom_rsv2_phys = res.start + 0x1000 + UNIPHIER_SMPCTRL_ROM_RSV2;
 	}
 
-	rom_rsv2_phys = res.start + UNIPHIER_SBC_ROM_BOOT_RSV2;
-
 	ret = uniphier_smp_copy_trampoline(rom_rsv2_phys);
 	if (ret)
 		return ret;
-- 
1.9.1



From yamada.masahiro at socionext.com  Thu Feb 25 23:18:27 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 16:18:27 +0900
Subject: [PATCH 0/9] ARM: dts: uniphier: UniPhier DT updates for Linux 4.6-rc1
 (2nd round)
Message-ID: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>


Hi Olof,

Here is a series for UniPhier DT updates.

It intentionally includes DT updates for ARM 32bit and ARM 64bit
in order to avoid conflicts and build errors.

(Some files in arch/arm64/boot/dts/socionext points to
arch/arm/boot/dts/* by symbolic links, so I needed to
change them atomically.)

Please apply the whole series to one branch.



Masahiro Yamada (9):
  arm64: dts: uniphier: rename PH1-LD10 to PH1-LD20
  ARM: dts: uniphier: factor out ranges property of support card
  ARM: dts: uniphier: rework UniPhier System Bus nodes
  ARM: dts: uniphier: add reference clock nodes
  ARM: dts: uniphier: add EEPROM node for ProXstream2 Gentil board
  ARM: dts: uniphier: enable I2C channel 2 of ProXstream2 Gentil board
  ARM: dts: uniphier: add PH1-Pro4 Ace board support
  ARM: dts: uniphier: add PH1-Pro4 Sanji board support
  ARM: dts: uniphier: add @{address} to EEPROM node

 arch/arm/boot/dts/Makefile                         |   2 +
 arch/arm/boot/dts/uniphier-common32.dtsi           |  27 +++--
 arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts         |   8 --
 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi            |   4 +
 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts        |   8 --
 arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts        | 113 +++++++++++++++++++++
 arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts        |   8 --
 arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts      | 108 ++++++++++++++++++++
 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi           |   4 +
 arch/arm/boot/dts/uniphier-ph1-pro5.dtsi           |   4 +
 arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts        |   8 --
 arch/arm/boot/dts/uniphier-ph1-sld3.dtsi           |  26 +++--
 arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts        |   8 --
 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi           |   4 +
 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts  |  10 ++
 arch/arm/boot/dts/uniphier-proxstream2.dtsi        |   4 +
 arch/arm/boot/dts/uniphier-ref-daughter.dtsi       |   2 +-
 arch/arm/boot/dts/uniphier-support-card.dtsi       |   6 +-
 arch/arm64/boot/dts/socionext/Makefile             |   2 +-
 ...-ph1-ld10-ref.dts => uniphier-ph1-ld20-ref.dts} |  16 +--
 ...iphier-ph1-ld10.dtsi => uniphier-ph1-ld20.dtsi} |  25 +++--
 21 files changed, 315 insertions(+), 82 deletions(-)
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts
 rename arch/arm64/boot/dts/socionext/{uniphier-ph1-ld10-ref.dts => uniphier-ph1-ld20-ref.dts} (88%)
 rename arch/arm64/boot/dts/socionext/{uniphier-ph1-ld10.dtsi => uniphier-ph1-ld20.dtsi} (94%)

-- 
1.9.1



From yamada.masahiro at socionext.com  Thu Feb 25 23:18:29 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 16:18:29 +0900
Subject: [PATCH 2/9] ARM: dts: uniphier: factor out ranges property of support
 card
In-Reply-To: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456471116-8140-3-git-send-email-yamada.masahiro@socionext.com>

This property is used in common by several boards.  Move it to the
common place (uniphier-support-card.dtsi).  If necessary, each board
can still override the property.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts              | 8 --------
 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts             | 8 --------
 arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts             | 8 --------
 arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts             | 8 --------
 arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts             | 8 --------
 arch/arm/boot/dts/uniphier-support-card.dtsi            | 3 +++
 arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts | 8 --------
 7 files changed, 3 insertions(+), 48 deletions(-)

diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
index f1e9d40..ec94b7a 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
@@ -72,14 +72,6 @@
 	};
 };
 
-&extbus {
-	ranges = <1 0x00000000 0x42000000 0x02000000>;
-};
-
-&support_card {
-	ranges = <0x00000000 1 0x01f00000 0x00100000>;
-};
-
 &ethsc {
 	interrupts = <0 49 4>;
 };
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
index 5baa9fc..b8134c6 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
@@ -74,14 +74,6 @@
 	};
 };
 
-&extbus {
-	ranges = <1 0x00000000 0x42000000 0x02000000>;
-};
-
-&support_card {
-	ranges = <0x00000000 1 0x01f00000 0x00100000>;
-};
-
 &ethsc {
 	interrupts = <0 52 4>;
 };
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
index 2462668..95f631a 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
@@ -74,14 +74,6 @@
 	};
 };
 
-&extbus {
-	ranges = <1 0x00000000 0x42000000 0x02000000>;
-};
-
-&support_card {
-	ranges = <0x00000000 1 0x01f00000 0x00100000>;
-};
-
 &ethsc {
 	interrupts = <0 50 4>;
 };
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
index b7a03215..acb4204 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
@@ -73,14 +73,6 @@
 	};
 };
 
-&extbus {
-	ranges = <1 0x00000000 0x42000000 0x02000000>;
-};
-
-&support_card {
-	ranges = <0x00000000 1 0x01f00000 0x00100000>;
-};
-
 &ethsc {
 	interrupts = <0 49 4>;
 };
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
index fc7250c..d594f40 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
@@ -72,14 +72,6 @@
 	};
 };
 
-&extbus {
-	ranges = <1 0x00000000 0x42000000 0x02000000>;
-};
-
-&support_card {
-	ranges = <0x00000000 1 0x01f00000 0x00100000>;
-};
-
 &ethsc {
 	interrupts = <0 48 4>;
 };
diff --git a/arch/arm/boot/dts/uniphier-support-card.dtsi b/arch/arm/boot/dts/uniphier-support-card.dtsi
index da271e3..fa807e8 100644
--- a/arch/arm/boot/dts/uniphier-support-card.dtsi
+++ b/arch/arm/boot/dts/uniphier-support-card.dtsi
@@ -43,10 +43,13 @@
  */
 
 &extbus {
+	ranges = <1 0x00000000 0x42000000 0x02000000>;
+
 	support_card: support_card {
 		compatible = "simple-bus";
 		#address-cells = <1>;
 		#size-cells = <1>;
+		ranges = <0x00000000 1 0x01f00000 0x00100000>;
 
 		ethsc: ethernet at 00000000 {
 			compatible = "smsc,lan9118", "smsc,lan9115";
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts
index 80f71ba..727ae5f 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts
@@ -74,14 +74,6 @@
 	};
 };
 
-&extbus {
-	ranges = <1 0x00000000 0x42000000 0x02000000>;
-};
-
-&support_card {
-	ranges = <0x00000000 1 0x01f00000 0x00100000>;
-};
-
 &ethsc {
 	interrupts = <0 48 4>;
 };
-- 
1.9.1



From yamada.masahiro at socionext.com  Thu Feb 25 23:18:28 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 16:18:28 +0900
Subject: [PATCH 1/9] arm64: dts: uniphier: rename PH1-LD10 to PH1-LD20
In-Reply-To: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456471116-8140-2-git-send-email-yamada.masahiro@socionext.com>

Due to the company's awful projecting, this chip has been renamed to
PH1-LD20.  It has not been shipped yet, this change would have no
impact on our customers.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm64/boot/dts/socionext/Makefile                            | 2 +-
 .../{uniphier-ph1-ld10-ref.dts => uniphier-ph1-ld20-ref.dts}      | 8 ++++----
 .../socionext/{uniphier-ph1-ld10.dtsi => uniphier-ph1-ld20.dtsi}  | 6 +++---
 3 files changed, 8 insertions(+), 8 deletions(-)
 rename arch/arm64/boot/dts/socionext/{uniphier-ph1-ld10-ref.dts => uniphier-ph1-ld20-ref.dts} (92%)
 rename arch/arm64/boot/dts/socionext/{uniphier-ph1-ld10.dtsi => uniphier-ph1-ld20.dtsi} (98%)

diff --git a/arch/arm64/boot/dts/socionext/Makefile b/arch/arm64/boot/dts/socionext/Makefile
index 8d72771..299b67e 100644
--- a/arch/arm64/boot/dts/socionext/Makefile
+++ b/arch/arm64/boot/dts/socionext/Makefile
@@ -1,4 +1,4 @@
-dtb-$(CONFIG_ARCH_UNIPHIER) += uniphier-ph1-ld10-ref.dtb
+dtb-$(CONFIG_ARCH_UNIPHIER) += uniphier-ph1-ld20-ref.dtb
 
 always		:= $(dtb-y)
 clean-files	:= *.dtb
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts
similarity index 92%
rename from arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
rename to arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts
index 3e53317..80f71ba 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20-ref.dts
@@ -1,5 +1,5 @@
 /*
- * Device Tree Source for UniPhier PH1-LD10 Reference Board
+ * Device Tree Source for UniPhier PH1-LD20 Reference Board
  *
  * Copyright (C) 2015 Masahiro Yamada <yamada.masahiro at socionext.com>
  *
@@ -43,12 +43,12 @@
  */
 
 /dts-v1/;
-/include/ "uniphier-ph1-ld10.dtsi"
+/include/ "uniphier-ph1-ld20.dtsi"
 /include/ "uniphier-support-card.dtsi"
 
 / {
-	model = "UniPhier PH1-LD10 Reference Board";
-	compatible = "socionext,ph1-ld10-ref", "socionext,ph1-ld10";
+	model = "UniPhier PH1-LD20 Reference Board";
+	compatible = "socionext,ph1-ld20-ref", "socionext,ph1-ld20";
 
 	memory {
 		device_type = "memory";
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
similarity index 98%
rename from arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
rename to arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
index 0296af9..e6871ea 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
@@ -1,5 +1,5 @@
 /*
- * Device Tree Source for UniPhier PH1-LD10 SoC
+ * Device Tree Source for UniPhier PH1-LD20 SoC
  *
  * Copyright (C) 2015 Masahiro Yamada <yamada.masahiro at socionext.com>
  *
@@ -43,7 +43,7 @@
  */
 
 / {
-	compatible = "socionext,ph1-ld10";
+	compatible = "socionext,ph1-ld20";
 	#address-cells = <2>;
 	#size-cells = <2>;
 	interrupt-parent = <&gic>;
@@ -262,7 +262,7 @@
 		};
 
 		pinctrl: pinctrl at 5f801000 {
-			compatible = "socionext,ph1-ld10-pinctrl", "syscon";
+			compatible = "socionext,ph1-ld20-pinctrl", "syscon";
 			reg = <0x5f801000 0xe00>;
 		};
 
-- 
1.9.1



From yamada.masahiro at socionext.com  Thu Feb 25 23:18:30 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 16:18:30 +0900
Subject: [PATCH 3/9] ARM: dts: uniphier: rework UniPhier System Bus nodes
In-Reply-To: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456471116-8140-4-git-send-email-yamada.masahiro@socionext.com>

During the review process of the UniPhier System Bus driver
(drivers/bus/uniphier.c), the current binding of the System Bus
Controller turned out to be no good.  In order to make the driver
really usable, we have to switch over to the new binding defined by
Documentation/devicetree/bindings/bus/uniphier-system-bus.txt.
The old binding will be still supported for a while to keep the
backward compatibility.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/uniphier-common32.dtsi             | 20 +++++++++++---------
 arch/arm/boot/dts/uniphier-ph1-sld3.dtsi             | 20 +++++++++++---------
 arch/arm/boot/dts/uniphier-support-card.dtsi         |  3 ++-
 arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi | 19 +++++++++++++------
 4 files changed, 37 insertions(+), 25 deletions(-)

diff --git a/arch/arm/boot/dts/uniphier-common32.dtsi b/arch/arm/boot/dts/uniphier-common32.dtsi
index ea9301a..f847e68 100644
--- a/arch/arm/boot/dts/uniphier-common32.dtsi
+++ b/arch/arm/boot/dts/uniphier-common32.dtsi
@@ -52,12 +52,6 @@
 		ranges;
 		interrupt-parent = <&intc>;
 
-		extbus: extbus {
-			compatible = "simple-bus";
-			#address-cells = <2>;
-			#size-cells = <1>;
-		};
-
 		serial0: serial at 54006800 {
 			compatible = "socionext,uniphier-uart";
 			status = "disabled";
@@ -98,9 +92,17 @@
 			clocks = <&uart_clk>;
 		};
 
-		system-bus-controller at 58c00000 {
-			compatible = "socionext,uniphier-system-bus-controller";
-			reg = <0x58c00000 0x400>, <0x59800000 0x2000>;
+		system_bus: system-bus at 58c00000 {
+			compatible = "socionext,uniphier-system-bus";
+			status = "disabled";
+			reg = <0x58c00000 0x400>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+		};
+
+		smpctrl at 59800000 {
+			compatible = "socionext,uniphier-smpctrl";
+			reg = <0x59801000 0x400>;
 		};
 
 		timer at 60000200 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
index 691a17d..4c746ea 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
@@ -94,12 +94,6 @@
 		ranges;
 		interrupt-parent = <&intc>;
 
-		extbus: extbus {
-			compatible = "simple-bus";
-			#address-cells = <2>;
-			#size-cells = <1>;
-		};
-
 		timer at 20000200 {
 			compatible = "arm,cortex-a9-global-timer";
 			reg = <0x20000200 0x20>;
@@ -216,9 +210,17 @@
 			clock-frequency = <400000>;
 		};
 
-		system-bus-controller at 58c00000 {
-			compatible = "socionext,uniphier-system-bus-controller";
-			reg = <0x58c00000 0x400>, <0x59800000 0x2000>;
+		system_bus: system-bus at 58c00000 {
+			compatible = "socionext,uniphier-system-bus";
+			status = "disabled";
+			reg = <0x58c00000 0x400>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+		};
+
+		smpctrl at 59800000 {
+			compatible = "socionext,uniphier-smpctrl";
+			reg = <0x59801000 0x400>;
 		};
 
 		usb0: usb at 5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-support-card.dtsi b/arch/arm/boot/dts/uniphier-support-card.dtsi
index fa807e8..51ecc9b9 100644
--- a/arch/arm/boot/dts/uniphier-support-card.dtsi
+++ b/arch/arm/boot/dts/uniphier-support-card.dtsi
@@ -42,7 +42,8 @@
  *     OTHER DEALINGS IN THE SOFTWARE.
  */
 
-&extbus {
+&system_bus {
+	status = "okay";
 	ranges = <1 0x00000000 0x42000000 0x02000000>;
 
 	support_card: support_card {
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
index e6871ea..e682a3f 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld20.dtsi
@@ -133,12 +133,6 @@
 		#size-cells = <1>;
 		ranges = <0 0 0 0xffffffff>;
 
-		extbus: extbus {
-			compatible = "simple-bus";
-			#address-cells = <2>;
-			#size-cells = <1>;
-		};
-
 		serial0: serial at 54006800 {
 			compatible = "socionext,uniphier-uart";
 			status = "disabled";
@@ -261,6 +255,19 @@
 			clock-frequency = <400000>;
 		};
 
+		system_bus: system-bus at 58c00000 {
+			compatible = "socionext,uniphier-system-bus";
+			status = "disabled";
+			reg = <0x58c00000 0x400>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+		};
+
+		smpctrl at 59800000 {
+			compatible = "socionext,uniphier-smpctrl";
+			reg = <0x59801000 0x400>;
+		};
+
 		pinctrl: pinctrl at 5f801000 {
 			compatible = "socionext,ph1-ld20-pinctrl", "syscon";
 			reg = <0x5f801000 0xe00>;
-- 
1.9.1



From kvalo at codeaurora.org  Thu Feb 25 23:18:04 2016
From: kvalo at codeaurora.org (Kalle Valo)
Date: Fri, 26 Feb 2016 09:18:04 +0200
Subject: [PATCH, RESEND] ssb: host_soc depends on sprom
In-Reply-To: <1456433869-3919332-1-git-send-email-arnd@arndb.de> (Arnd
 Bergmann's message of "Thu, 25 Feb 2016 21:57:43 +0100")
References: <1456433869-3919332-1-git-send-email-arnd@arndb.de>
Message-ID: <87twkwlz2r.fsf@purkki.adurom.net>

Arnd Bergmann <arnd at arndb.de> writes:

> Drivers that use the SSB sprom functionality typically 'select SSB_SPROM'
> from Kconfig, but CONFIG_SSB_HOST_SOC misses this, which results in
> a build failure unless at least one of the other drivers that selects
> it is enabled:
>
> drivers/built-in.o: In function `ssb_host_soc_get_invariants':
> (.text+0x459494): undefined reference to `ssb_fill_sprom_with_fallback'
>
> This adds the same select statement that is used elsewhere.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 541c9a84cd85 ("ssb: pick SoC invariants code from MIPS BCM47xx arch")

I'm planning to queue this to 4.5.

-- 
Kalle Valo


From yamada.masahiro at socionext.com  Thu Feb 25 23:18:33 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 16:18:33 +0900
Subject: [PATCH 6/9] ARM: dts: uniphier: enable I2C channel 2 of ProXstream2
 Gentil board
In-Reply-To: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456471116-8140-7-git-send-email-yamada.masahiro@socionext.com>

This is used for on-board inter-connection.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
index 0da3018..bf2619e 100644
--- a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
+++ b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
@@ -63,6 +63,7 @@
 		serial1 = &serial1;
 		serial2 = &serial2;
 		i2c0 = &i2c0;
+		i2c2 = &i2c2;
 		i2c4 = &i2c4;
 		i2c5 = &i2c5;
 		i2c6 = &i2c6;
@@ -81,3 +82,7 @@
 		reg = <0x54>;
 	};
 };
+
+&i2c2 {
+	status = "okay";
+};
-- 
1.9.1



From yamada.masahiro at socionext.com  Thu Feb 25 23:18:32 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 16:18:32 +0900
Subject: [PATCH 5/9] ARM: dts: uniphier: add EEPROM node for ProXstream2
 Gentil board
In-Reply-To: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456471116-8140-6-git-send-email-yamada.masahiro@socionext.com>

This board has an EEPROM (STMicroelectronics M24C64-WMN6TP) connected
to the I2C channel 0 of the SoC.  Its slave address is 0x54.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
index 9d7ec5c..0da3018 100644
--- a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
+++ b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
@@ -75,4 +75,9 @@
 
 &i2c0 {
 	status = "okay";
+
+	eeprom at 54 {
+		compatible = "st,24c64";
+		reg = <0x54>;
+	};
 };
-- 
1.9.1



From yamada.masahiro at socionext.com  Thu Feb 25 23:18:31 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 16:18:31 +0900
Subject: [PATCH 4/9] ARM: dts: uniphier: add reference clock nodes
In-Reply-To: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456471116-8140-5-git-send-email-yamada.masahiro@socionext.com>

Add master clock nodes generated by crystal oscillators.

  PH1-sLD3, PH1-LD4: 24.576 MHz
  PH1-Pro4, ProXstream2: 25.000 MHz
  PH1-Pro5: 20.000 MHz

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/uniphier-common32.dtsi    | 7 +++++++
 arch/arm/boot/dts/uniphier-ph1-ld4.dtsi     | 4 ++++
 arch/arm/boot/dts/uniphier-ph1-pro4.dtsi    | 4 ++++
 arch/arm/boot/dts/uniphier-ph1-pro5.dtsi    | 4 ++++
 arch/arm/boot/dts/uniphier-ph1-sld3.dtsi    | 6 ++++++
 arch/arm/boot/dts/uniphier-ph1-sld8.dtsi    | 4 ++++
 arch/arm/boot/dts/uniphier-proxstream2.dtsi | 4 ++++
 7 files changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/uniphier-common32.dtsi b/arch/arm/boot/dts/uniphier-common32.dtsi
index f847e68..61a0955 100644
--- a/arch/arm/boot/dts/uniphier-common32.dtsi
+++ b/arch/arm/boot/dts/uniphier-common32.dtsi
@@ -45,6 +45,13 @@
 /include/ "skeleton.dtsi"
 
 / {
+	clocks {
+		refclk: ref {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+		};
+	};
+
 	soc: soc {
 		compatible = "simple-bus";
 		#address-cells = <1>;
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index 34f0d8d..dadd860 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -173,6 +173,10 @@
 
 };
 
+&refclk {
+	clock-frequency = <24576000>;
+};
+
 &serial3 {
 	interrupts = <0 29 4>;
 };
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index d78142f..20f3f2a 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -195,6 +195,10 @@
 	};
 };
 
+&refclk {
+	clock-frequency = <25000000>;
+};
+
 &pinctrl {
 	compatible = "socionext,ph1-pro4-pinctrl", "syscon";
 };
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
index 2f389ea..24f6f66 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
@@ -189,6 +189,10 @@
 	};
 };
 
+&refclk {
+	clock-frequency = <20000000>;
+};
+
 &pinctrl {
 	compatible = "socionext,ph1-pro5-pinctrl", "syscon";
 };
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
index 4c746ea..03292f4 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
@@ -68,6 +68,12 @@
 	};
 
 	clocks {
+		refclk: ref {
+			#clock-cells = <0>;
+			compatible = "fixed-clock";
+			clock-frequency = <24576000>;
+		};
+
 		arm_timer_clk: arm_timer_clk {
 			#clock-cells = <0>;
 			compatible = "fixed-clock";
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
index 7d06a1c..6bfd29a 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
@@ -172,6 +172,10 @@
 	};
 };
 
+&refclk {
+	clock-frequency = <25000000>;
+};
+
 &serial3 {
 	interrupts = <0 29 4>;
 };
diff --git a/arch/arm/boot/dts/uniphier-proxstream2.dtsi b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
index 6bd353f..4ac484c 100644
--- a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
+++ b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
@@ -200,6 +200,10 @@
 	};
 };
 
+&refclk {
+	clock-frequency = <25000000>;
+};
+
 &pinctrl {
 	compatible = "socionext,proxstream2-pinctrl", "syscon";
 };
-- 
1.9.1



From yamada.masahiro at socionext.com  Thu Feb 25 23:18:36 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 16:18:36 +0900
Subject: [PATCH 9/9] ARM: dts: uniphier: add @{address} to EEPROM node
In-Reply-To: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456471116-8140-10-git-send-email-yamada.masahiro@socionext.com>

Just for consistent coding style.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/uniphier-ref-daughter.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/uniphier-ref-daughter.dtsi b/arch/arm/boot/dts/uniphier-ref-daughter.dtsi
index 3d29d28..f7df088 100644
--- a/arch/arm/boot/dts/uniphier-ref-daughter.dtsi
+++ b/arch/arm/boot/dts/uniphier-ref-daughter.dtsi
@@ -43,7 +43,7 @@
  */
 
 &i2c0 {
-	eeprom {
+	eeprom at 50 {
 		compatible = "microchip,24lc128";
 		reg = <0x50>;
 	};
-- 
1.9.1



From yamada.masahiro at socionext.com  Thu Feb 25 23:18:34 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 16:18:34 +0900
Subject: [PATCH 7/9] ARM: dts: uniphier: add PH1-Pro4 Ace board support
In-Reply-To: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456471116-8140-8-git-send-email-yamada.masahiro@socionext.com>

Initial commit for PH1-Pro4 Ace board support.

Note:
There are two variants for the amount of DDR memory; 1GB or 2GB.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/Makefile                  |   1 +
 arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts | 113 ++++++++++++++++++++++++++++
 2 files changed, 114 insertions(+)
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..d9d899f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -736,6 +736,7 @@ dtb-$(CONFIG_ARCH_U8500) += \
 dtb-$(CONFIG_ARCH_UNIPHIER) += \
 	uniphier-ph1-ld4-ref.dtb \
 	uniphier-ph1-ld6b-ref.dtb \
+	uniphier-ph1-pro4-ace.dtb \
 	uniphier-ph1-pro4-ref.dtb \
 	uniphier-ph1-sld3-ref.dtb \
 	uniphier-ph1-sld8-ref.dtb \
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts b/arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts
new file mode 100644
index 0000000..d343586
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts
@@ -0,0 +1,113 @@
+/*
+ * Device Tree Source for UniPhier PH1-Pro4 Ace Board
+ *
+ * Copyright (C) 2016 Masahiro Yamada <yamada.masahiro at socionext.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ "uniphier-ph1-pro4.dtsi"
+
+/ {
+	model = "UniPhier PH1-Pro4 Ace Board";
+	compatible = "socionext,ph1-pro4-ace", "socionext,ph1-pro4";
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x40000000>;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	aliases {
+		serial0 = &serial0;
+		serial1 = &serial1;
+		serial2 = &serial2;
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+		i2c5 = &i2c5;
+		i2c6 = &i2c6;
+	};
+};
+
+&serial0 {
+	status = "okay";
+};
+
+&serial1 {
+	status = "okay";
+};
+
+&serial2 {
+	status = "okay";
+};
+
+&i2c0 {
+	status = "okay";
+
+	eeprom at 54 {
+		compatible = "st,24c64";
+		reg = <0x54>;
+	};
+};
+
+&i2c1 {
+	status = "okay";
+};
+
+&i2c2 {
+	status = "okay";
+};
+
+&i2c3 {
+	status = "okay";
+};
+
+&usb2 {
+	status = "okay";
+};
+
+&usb3 {
+	status = "okay";
+};
-- 
1.9.1



From yamada.masahiro at socionext.com  Thu Feb 25 23:21:22 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 16:21:22 +0900
Subject: [PATCH 2/9] ARM: dts: uniphier: rework UniPhier System Bus nodes
In-Reply-To: <CAOesGMimq4Xf3sUB4bkkdr7whiaRDaL6JM1Nu2zN_QfJSHoQxg@mail.gmail.com>
References: <1455588911-9827-1-git-send-email-yamada.masahiro@socionext.com>
 <1455588911-9827-3-git-send-email-yamada.masahiro@socionext.com>
 <20160225002641.GC10126@localhost>
 <CAK7LNARSXAw42bU4x+rgbWVmoru_5C8CMUHvTN22qm4eCDSvKA@mail.gmail.com>
 <CAOesGMimq4Xf3sUB4bkkdr7whiaRDaL6JM1Nu2zN_QfJSHoQxg@mail.gmail.com>
Message-ID: <CAK7LNATZCG1mv5zjgVjXdftcDT8myK87=Y30DARvrk3fdSSo5A@mail.gmail.com>

Hi Olof,


2016-02-25 16:20 GMT+09:00 Olof Johansson <olof at lixom.net>:
> On Wed, Feb 24, 2016 at 6:22 PM, Masahiro Yamada
> <yamada.masahiro at socionext.com> wrote:
>> Hi Olof,
>>
>>
>> 2016-02-25 9:26 GMT+09:00 Olof Johansson <olof at lixom.net>:
>>> Hi,
>>>
>>> On Tue, Feb 16, 2016 at 11:15:04AM +0900, Masahiro Yamada wrote:
>>>
>>>> diff --git a/arch/arm/mach-uniphier/platsmp.c b/arch/arm/mach-uniphier/platsmp.c
>>>> index e1cfc1d..b53a8d9 100644
>>>> --- a/arch/arm/mach-uniphier/platsmp.c
>>>> +++ b/arch/arm/mach-uniphier/platsmp.c
>>>> @@ -30,7 +30,7 @@
>>>>   * The secondary CPUs check this register from the boot ROM for the jump
>>>>   * destination.  After that, it can be reused as a scratch register.
>>>>   */
>>>> -#define UNIPHIER_SBC_ROM_BOOT_RSV2   0x1208
>>>> +#define UNIPHIER_SMPCTRL_ROM_BOOT_RSV2       0x208
>>>>
>>>>  static void __iomem *uniphier_smp_rom_boot_rsv2;
>>>>  static unsigned int uniphier_smp_max_cpus;
>>>> @@ -98,15 +98,14 @@ static int __init uniphier_smp_prepare_trampoline(unsigned int max_cpus)
>>>>       phys_addr_t rom_rsv2_phys;
>>>>       int ret;
>>>>
>>>> -     np = of_find_compatible_node(NULL, NULL,
>>>> -                             "socionext,uniphier-system-bus-controller");
>>>> -     ret = of_address_to_resource(np, 1, &res);
>>>> +     np = of_find_compatible_node(NULL, NULL, "socionext,uniphier-smpctrl");
>>>> +     ret = of_address_to_resource(np, 0, &res);
>>>>       if (ret) {
>>>> -             pr_err("failed to get resource of system-bus-controller\n");
>>>> +             pr_err("failed to get resource of uniphier-smpctrl\n");
>>>>               return ret;
>>>>       }
>>>>
>>>> -     rom_rsv2_phys = res.start + UNIPHIER_SBC_ROM_BOOT_RSV2;
>>>> +     rom_rsv2_phys = res.start + UNIPHIER_SMPCTRL_ROM_BOOT_RSV2;
>>>>
>>>>       ret = uniphier_smp_copy_trampoline(rom_rsv2_phys);
>>>>       if (ret)
>>>
>>> The previous binding has already been released. You can update, but your driver
>>> should be able to handle the previous binding.
>>>
>>> So, you still need to keep the old code around.
>>>
>>> This has the benefit of breaking the dependency between the code change and the
>>> DT change, so you no longer have to change your platform code at the same time
>>> as the DT to avoid regressions.
>>>
>>>
>>> Please adjust and resend. I'll hold off applying the series until then, so we
>>> don't have a partially applied series.
>>
>>
>>
>> How long do I have to keep the support for the old binding?
>
> You know your platform best -- how many users do you think you have
> out there that might have built DTS files based on the old binding?
>
> If there's a good chance there are none, or if you're in good contact
> with them and can ask them to update, then you can be more flexible.
>
>> [1]
>> Everyone makes mistakes.
>> The constraint for the DT-binding is really really painful.
>>
>> This is how it happened.
>>
>> At first, I implemented uniphier-system-bus.c based on the old binding.
>> Then, during the review, Mark suggested me to change the driver design:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/387938.html
>>
>> I followed his suggestion, but I needed to changed the DT-binding as well.
>> Before that time, the DT and other support code for UniPhier had been
>> partially merged
>> in the mainline.  So, in the current tree exist two bindings that are
>> not compatible to
>> each other.  This situation is really a mess.
>> I want to clean up the code as soon as possible.
>
> Yeah, I understand that it's hard to come up with perfect bindings
> from day one, and that's why we sometimes have to play by ear.
>
> It's not a bad idea to get practice on how to solve it -- in this case
> it wouldn't really bad that bad. If you use variables to hold the base
> addresses, and get them from either binding, you'll only special-case
> during probe and not anywhere else in the driver.
>
> The general idea of decoupling DT changes from code changes is also a
> good habit.
>
>> [2]
>> For now, DT is mostly developed in the kernel tree in practice,
>> while DT is not theoretically only for Linux.
>> Everybody (at least every user of UniPhier SoCs) uses the combination
>> of a DTB and a kernel image
>> generated from the same Linux tree.
>> I see no reason to use a new DTB + an old kernel image, or vice versa.
>
> We're not aiming to support new DTB + old kernel image. The main
> problem is if someone has a product DTB that's not yet merged, and you
> change the binding, then their DTB might no longer work. It's not a
> huge deal, and for most changes it's fairly harmless, but the general
> principle still applies.
>
> As I said earlier, you know the users of your platform the best (I
> hope :), so you'll have the best feel for whether this is a breakage
> they will hurt from or not.
>
>> [3]
>> This binding is UniPhier-specific.  No impact on other SoC vendors.
>> Everything is under my control.
>>
>>
>>
>> For now, I will prepare the logic to support the old binding,
>> but for the reasons above, please let me drop the support for the old
>> one some time later.
>
> Yeah, I'm perfectly fine with not keeping it for a long time. For
> example, feel free to remove it next release if you think that will
> work for your downstream users.


OK, I split the series into two.  (DT and non-DT updates)

Thanks.


-- 
Best Regards
Masahiro Yamada


From thunder.leizhen at huawei.com  Thu Feb 25 23:19:55 2016
From: thunder.leizhen at huawei.com (Leizhen (ThunderTown))
Date: Fri, 26 Feb 2016 15:19:55 +0800
Subject: [PATCH 2/2] PCI: generic: add description of property
 "interrupt-skip-mask"
In-Reply-To: <20160225122035.GB10593@leverpostej>
References: <1456401208-10136-1-git-send-email-thunder.leizhen@huawei.com>
 <1456401208-10136-2-git-send-email-thunder.leizhen@huawei.com>
 <20160225122035.GB10593@leverpostej>
Message-ID: <56CFFC9B.20703@huawei.com>



On 2016/2/25 20:20, Mark Rutland wrote:
> Hi,
> 
> In future, please send the binding document first in a series, per point
> 3 of Documentation/devicetree/bindings/submitting-patches.txt. It makes
> review easier/faster.
Thank you for your reminding.

> 
> On Thu, Feb 25, 2016 at 07:53:28PM +0800, Zhen Lei wrote:
>> Interrupt Pin register is read-only and optional. Some pci devices may use
>> msi/msix but leave the value of Interrupt Pin non-zero.
> 
> Is that permitted by the spec? Surely 'optional' means it must be zero
> if not implemented?

In <PCI Local Bus Specification Revision 3.0>:
Devices (or device functions) that do not use an interrupt pin must put a 0 in this register. This register is read-only.

So, do you think this is a hardware bug? But these pci-devices are not produced by our company.

In function init_service_irqs, it try msix first, then msi, Interrupt PIN is the last attemption. But of_irq_parse_pci() happened before this.


In fact, there also a familiar problem exist. As below:
pci 0000:42:00.0: BAR 7: no space for [io  size 0x1000]
pci 0000:42:00.0: BAR 7: failed to assign [io  size 0x1000]

There no "io space" on arm64, maybe only exist on X86. And the Memory Space Indicator also read-only in BAR register.

> 
>> In this case, the driver will print information as below: pci
>> 0000:40:00.0: of_irq_parse_pci() failed with rc=-22
>>
>> It's easily lead to misinterpret.
> 
> If this is limited to a subset of devices which we know are broken in
> this regard, can we not handle these cases explicitly?
Actually, we have another way to block this warning. Use "interrupt-map" to map it to a pesudo IRQ. But I think it will also be misunderstanded.

> 
>> Signed-off-by: Zhen Lei <thunder.leizhen at huawei.com>
>> ---
>>  Documentation/devicetree/bindings/pci/host-generic-pci.txt | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
>> index 3f1d3fc..0f10978 100644
>> --- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
>> +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
>> @@ -70,6 +70,8 @@ Practice: Interrupt Mapping' and requires the following properties:
>>
>>  - interrupt-map-mask : <see aforementioned specification>
>>
>> +- interrupt-skip-mask: Explicitly declare which pci devices only use msi/msix
>> +but leave the value of Interrupt Pin non-zero.
> 
> Unlike the rest of the interrupt mapping properties, this is not
> described in  `Open Firmware Recommended Practice: Interrupt Mapping'.
> 
> This needs a far more complete description.
> 
> This also doesn't strike me as th right approach. The interrupt-map-mask
> property describe as relationship between the host-controller-provided
> interrupt lines and endpoints, while this seems to be a bug completely
> contained within an endpoint.

In <host-generic-pci.txt>:
// PCI_DEVICE(3)  INT#(1)  CONTROLLER(PHANDLE)  CONTROLLER_DATA(3)
    interrupt-map = <  0x0 0x0 0x0  0x1  &gic  0x0 0x4 0x1

PCI_DEVICE contain 3 cells. But only the first one be used in function of_irq_parse_pci.
laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
laddr[1] = laddr[2] = cpu_to_be32(0);

And for INT#, I don't think there will some Pins used but others unused on a pci-device. So I can ommit it.

So, only laddr[0] mask need to be described.
> 
> Thanks,
> Mark.
> 
>>
>>  Example:
>>
>> --
>> 2.5.0
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> .
> 



From yamada.masahiro at socionext.com  Thu Feb 25 23:22:59 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 16:22:59 +0900
Subject: [PATCH] arm64: dts: uniphier: rename PH1-LD10 to PH1-LD20
In-Reply-To: <1456202421-10857-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456202421-10857-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <CAK7LNAQ8smP1X613QCi2MXJ7M+v+bd4GmumXP84Ttt-40+jtUg@mail.gmail.com>

2016-02-23 13:40 GMT+09:00 Masahiro Yamada <yamada.masahiro at socionext.com>:
> Due to the company's awful projecting, this chip has been renamed to
> PH1-LD20.  It has not been shipped yet, this change would not give
> much impact on our customers.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
> ---
>
> Olof, Arnd,
>
> Please apply this patch along with my series
> "[PATCH 0/9] ARM: uniphier: UniPhier updates for Linux 4.6-rc1".
>
> If it goes to a different branch, it will cause a big merge conflict later.


Note:

This patch has been included in the series,
"ARM: dts: uniphier: UniPhier DT updates for Linux 4.6-rc1 (2nd round)"
in order to clarify the patch dependency.


-- 
Best Regards
Masahiro Yamada


From holgerschurig at gmail.com  Thu Feb 25 23:24:15 2016
From: holgerschurig at gmail.com (Holger Schurig)
Date: Fri, 26 Feb 2016 08:24:15 +0100
Subject: [RFC v1] clk: Add debugfs nodes for
 enable/disable/set-rate/set-parent
In-Reply-To: <1456454309-25037-1-git-send-email-pankaj.dev@st.com> (Pankaj
 Dev's message of "Fri, 26 Feb 2016 08:08:29 +0530")
References: <1456454309-25037-1-git-send-email-pankaj.dev@st.com>
Message-ID: <87fuwg9bog.fsf@gmail.com>

Pankaj Dev <pankaj.dev at st.com> writes:

> 1. clk_set_rate : Set new rate to value. Reading returns the
> current rate

If you can use this to set *and* read it, then "_set_" shouldn't be in
the name.

What is wrong with using the existing "clk_rate" for reading/setting the
rate?


From yamada.masahiro at socionext.com  Thu Feb 25 23:18:35 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 16:18:35 +0900
Subject: [PATCH 8/9] ARM: dts: uniphier: add PH1-Pro4 Sanji board support
In-Reply-To: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
References: <1456471116-8140-1-git-send-email-yamada.masahiro@socionext.com>
Message-ID: <1456471116-8140-9-git-send-email-yamada.masahiro@socionext.com>

Initial commit for PH1-Pro4 Sanji board support.

Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
---

 arch/arm/boot/dts/Makefile                    |   1 +
 arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts | 108 ++++++++++++++++++++++++++
 2 files changed, 109 insertions(+)
 create mode 100644 arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d9d899f..f2663ac 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -738,6 +738,7 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
 	uniphier-ph1-ld6b-ref.dtb \
 	uniphier-ph1-pro4-ace.dtb \
 	uniphier-ph1-pro4-ref.dtb \
+	uniphier-ph1-pro4-sanji.dtb \
 	uniphier-ph1-sld3-ref.dtb \
 	uniphier-ph1-sld8-ref.dtb \
 	uniphier-proxstream2-gentil.dtb \
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts b/arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts
new file mode 100644
index 0000000..7c3a1fc
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts
@@ -0,0 +1,108 @@
+/*
+ * Device Tree Source for UniPhier PH1-Pro4 Sanji Board
+ *
+ * Copyright (C) 2016 Masahiro Yamada <yamada.masahiro at socionext.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ "uniphier-ph1-pro4.dtsi"
+
+/ {
+	model = "UniPhier PH1-Pro4 Sanji Board";
+	compatible = "socionext,ph1-pro4-sanji", "socionext,ph1-pro4";
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x80000000>;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	aliases {
+		serial0 = &serial0;
+		serial1 = &serial1;
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		i2c3 = &i2c3;
+		i2c5 = &i2c5;
+		i2c6 = &i2c6;
+	};
+};
+
+&serial0 {
+	status = "okay";
+};
+
+&serial1 {
+	status = "okay";
+};
+
+&i2c0 {
+	status = "okay";
+
+	eeprom at 54 {
+		compatible = "st,24c64";
+		reg = <0x54>;
+	};
+};
+
+&i2c1 {
+	status = "okay";
+};
+
+&i2c2 {
+	status = "okay";
+};
+
+&i2c3 {
+	status = "okay";
+};
+
+&usb2 {
+	status = "okay";
+};
+
+&usb3 {
+	status = "okay";
+};
-- 
1.9.1



From k.kozlowski at samsung.com  Thu Feb 25 23:25:36 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 26 Feb 2016 16:25:36 +0900
Subject: [RESPIN 2/6] drivers: memory: Add support for exynos SROM driver
In-Reply-To: <1456389222-12738-3-git-send-email-pankaj.dubey@samsung.com>
References: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
 <1456389222-12738-3-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <56CFFDF0.9040107@samsung.com>

On 25.02.2016 17:33, Pankaj Dubey wrote:
> This patch adds Exynos SROM controller driver which will handle
> save restore of SROM registers during S2R.
> 
> Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
> Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> [p.fedin at samsung.com: tested on SMDK5410]
> Tested-by: Pavel Fedin <p.fedin at samsung.com>
> Signed-off-by: Kukjin Kim <kgene at kernel.org>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> ---
>  drivers/memory/Kconfig               |   1 +
>  drivers/memory/Makefile              |   1 +
>  drivers/memory/samsung/Kconfig       |  12 +++
>  drivers/memory/samsung/Makefile      |   1 +
>  drivers/memory/samsung/exynos-srom.c | 175 +++++++++++++++++++++++++++++++++++
>  drivers/memory/samsung/exynos-srom.h |  51 ++++++++++
>  6 files changed, 241 insertions(+)
>  create mode 100644 drivers/memory/samsung/Kconfig
>  create mode 100644 drivers/memory/samsung/Makefile
>  create mode 100644 drivers/memory/samsung/exynos-srom.c
>  create mode 100644 drivers/memory/samsung/exynos-srom.h
> 
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index 6f31546..bcb1982 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -114,6 +114,7 @@ config JZ4780_NEMC
>  	  the Ingenic JZ4780. This controller is used to handle external
>  	  memory devices such as NAND and SRAM.
>  
> +source "drivers/memory/samsung/Kconfig"
>  source "drivers/memory/tegra/Kconfig"
>  
>  endif
> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
> index 1c46af5..d100e40 100644
> --- a/drivers/memory/Makefile
> +++ b/drivers/memory/Makefile
> @@ -16,4 +16,5 @@ obj-$(CONFIG_MVEBU_DEVBUS)	+= mvebu-devbus.o
>  obj-$(CONFIG_TEGRA20_MC)	+= tegra20-mc.o
>  obj-$(CONFIG_JZ4780_NEMC)	+= jz4780-nemc.o
>  
> +obj-$(CONFIG_SAMSUNG_MC)	+= samsung/
>  obj-$(CONFIG_TEGRA_MC)		+= tegra/
> diff --git a/drivers/memory/samsung/Kconfig b/drivers/memory/samsung/Kconfig
> new file mode 100644
> index 0000000..c2cd45e
> --- /dev/null
> +++ b/drivers/memory/samsung/Kconfig
> @@ -0,0 +1,12 @@
> +config SAMSUNG_MC
> +	bool "SAMSUNG Exynos Memory Controller support" if COMPILE_TEST
> +	default y
> +	depends on ARCH_EXYNOS
> +	help
> +	  This driver supports the Memory Controller (MC) hardwares found on
> +	  SAMSUNG Exynos SoCs.
> +

if SAMSUNG_MC

> +config EXYNOS_SROM
> +	bool
> +	depends on (ARM && ARCH_EXYNOS && PM) || ((ARM || ARM64) && COMPILE_TEST)

(ARM && ARCH_EXYNOS && PM) || COMPILE_TEST

You don't need to limit compile testing to ARM/ARM64.

Rest is good.

If there are no comments from other people, then I can fix this while
applying. If there will be a comment or re-spin, then please apply my
comments.

Best regards,
Krzysztof




From k.kozlowski at samsung.com  Thu Feb 25 23:28:11 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 26 Feb 2016 16:28:11 +0900
Subject: [RESPIN 4/6] ARM: EXYNOS: Remove SROM related register settings
 from mach-exynos
In-Reply-To: <1456389222-12738-5-git-send-email-pankaj.dubey@samsung.com>
References: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
 <1456389222-12738-5-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <56CFFE8B.80002@samsung.com>

On 25.02.2016 17:33, Pankaj Dubey wrote:
> As now we have dedicated driver for SROM controller, it will take care
> of saving register banks during S2R so we can safely remove these
> settings from mach-exynos.
> 
> Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
> Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> Signed-off-by: Kukjin Kim <kgene at kernel.org>
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
> ---
>  arch/arm/mach-exynos/Kconfig                 |  2 ++
>  arch/arm/mach-exynos/exynos.c                | 17 ---------
>  arch/arm/mach-exynos/include/mach/map.h      |  3 --
>  arch/arm/mach-exynos/regs-srom.h             | 53 ----------------------------
>  arch/arm/mach-exynos/suspend.c               | 20 ++---------
>  arch/arm/plat-samsung/include/plat/map-s5p.h |  1 -
>  6 files changed, 4 insertions(+), 92 deletions(-)
>  delete mode 100644 arch/arm/mach-exynos/regs-srom.h
> 
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index c4989c2..8da01d1 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -18,6 +18,7 @@ menuconfig ARCH_EXYNOS
>  	select COMMON_CLK_SAMSUNG
>  	select EXYNOS_THERMAL
>  	select EXYNOS_PMU
> +	select EXYNOS_SROM if PM
>  	select HAVE_ARM_SCU if SMP
>  	select HAVE_S3C2410_I2C if I2C
>  	select HAVE_S3C2410_WATCHDOG if WATCHDOG
> @@ -30,6 +31,7 @@ menuconfig ARCH_EXYNOS
>  	select SRAM
>  	select THERMAL
>  	select MFD_SYSCON
> +	select MEMORY

select SAMSUNG_MC because otherwise the directory won't be build
(memory/Kconfig).

Rest looks good. No need to respin (I can fix this when applying),
unless other people will have some comments.

BR,
Krzysztof



From k.kozlowski at samsung.com  Thu Feb 25 23:36:05 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 26 Feb 2016 16:36:05 +0900
Subject: [RESPIN 2/6] drivers: memory: Add support for exynos SROM driver
In-Reply-To: <56CFFDF0.9040107@samsung.com>
References: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
 <1456389222-12738-3-git-send-email-pankaj.dubey@samsung.com>
 <56CFFDF0.9040107@samsung.com>
Message-ID: <56D00065.6030507@samsung.com>

On 26.02.2016 16:25, Krzysztof Kozlowski wrote:
> On 25.02.2016 17:33, Pankaj Dubey wrote:
>> This patch adds Exynos SROM controller driver which will handle
>> save restore of SROM registers during S2R.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey at samsung.com>
>> Reviewed-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
>> [p.fedin at samsung.com: tested on SMDK5410]
>> Tested-by: Pavel Fedin <p.fedin at samsung.com>
>> Signed-off-by: Kukjin Kim <kgene at kernel.org>
>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski at samsung.com>
>> ---
>>  drivers/memory/Kconfig               |   1 +
>>  drivers/memory/Makefile              |   1 +
>>  drivers/memory/samsung/Kconfig       |  12 +++
>>  drivers/memory/samsung/Makefile      |   1 +
>>  drivers/memory/samsung/exynos-srom.c | 175 +++++++++++++++++++++++++++++++++++
>>  drivers/memory/samsung/exynos-srom.h |  51 ++++++++++
>>  6 files changed, 241 insertions(+)
>>  create mode 100644 drivers/memory/samsung/Kconfig
>>  create mode 100644 drivers/memory/samsung/Makefile
>>  create mode 100644 drivers/memory/samsung/exynos-srom.c
>>  create mode 100644 drivers/memory/samsung/exynos-srom.h
>>
>> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
>> index 6f31546..bcb1982 100644
>> --- a/drivers/memory/Kconfig
>> +++ b/drivers/memory/Kconfig
>> @@ -114,6 +114,7 @@ config JZ4780_NEMC
>>  	  the Ingenic JZ4780. This controller is used to handle external
>>  	  memory devices such as NAND and SRAM.
>>  
>> +source "drivers/memory/samsung/Kconfig"
>>  source "drivers/memory/tegra/Kconfig"
>>  
>>  endif
>> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
>> index 1c46af5..d100e40 100644
>> --- a/drivers/memory/Makefile
>> +++ b/drivers/memory/Makefile
>> @@ -16,4 +16,5 @@ obj-$(CONFIG_MVEBU_DEVBUS)	+= mvebu-devbus.o
>>  obj-$(CONFIG_TEGRA20_MC)	+= tegra20-mc.o
>>  obj-$(CONFIG_JZ4780_NEMC)	+= jz4780-nemc.o
>>  
>> +obj-$(CONFIG_SAMSUNG_MC)	+= samsung/
>>  obj-$(CONFIG_TEGRA_MC)		+= tegra/
>> diff --git a/drivers/memory/samsung/Kconfig b/drivers/memory/samsung/Kconfig
>> new file mode 100644
>> index 0000000..c2cd45e
>> --- /dev/null
>> +++ b/drivers/memory/samsung/Kconfig
>> @@ -0,0 +1,12 @@
>> +config SAMSUNG_MC
>> +	bool "SAMSUNG Exynos Memory Controller support" if COMPILE_TEST
>> +	default y
>> +	depends on ARCH_EXYNOS

These two are not needed and they introduce issues (when COMPILE_TEST it
should not depend on exynos and should not be in such case enabled by
default).

>> +	help
>> +	  This driver supports the Memory Controller (MC) hardwares found on
>> +	  SAMSUNG Exynos SoCs.
>> +
> 
> if SAMSUNG_MC
> 
>> +config EXYNOS_SROM
>> +	bool

bool should be described with COMPILE_TEST

>> +	depends on (ARM && ARCH_EXYNOS && PM) || ((ARM || ARM64) && COMPILE_TEST)
> 
> (ARM && ARCH_EXYNOS && PM) || COMPILE_TEST
> 
> You don't need to limit compile testing to ARM/ARM64.
> 

So overall it should be like:

config SAMSUNG_MC
	bool "Samsung Exynos Memory Controller support" if COMPILE_TEST
	help
	  Support for the Memory Controller (MC) devices found on
	  Samsung Exynos SoCs.

if SAMSUNG_MC

config EXYNOS_SROM
	bool "Exynos SROM controller driver" if COMPILE_TEST
	depends on (ARM && ARCH_EXYNOS && PM) || COMPILE_TEST

endif



From linux at roeck-us.net  Thu Feb 25 23:41:50 2016
From: linux at roeck-us.net (Guenter Roeck)
Date: Thu, 25 Feb 2016 23:41:50 -0800
Subject: next-20160225 build: 2 failures 44 warnings (next-20160225)
In-Reply-To: <20160226030949.GL18327@sirena.org.uk>
References: <E1aYsmb-0006qb-76@optimist> <20160226030949.GL18327@sirena.org.uk>
Message-ID: <56D001BE.2090209@roeck-us.net>

Hi Mark,

On 02/25/2016 07:09 PM, Mark Brown wrote:
> On Thu, Feb 25, 2016 at 10:04:29AM +0000, Build bot for Mark Brown wrote:
>
> Today's -next fails to build an arm64 allmodconfig due to:
>
>> 	arm64-allmodconfig
>> ../drivers/watchdog/orion_wdt.c:109:2: error: implicit declaration of function 'atomic_io_modify' [-Werror=implicit-function-declaration]
>
> also caused by b4f596b19624 (arm64: add mvebu architecture entry) which
> enables MVBEU on arm64, the commit was present for a little while and
> the error cropped up but didn't get reported due to other things masking
> it.  atomic_io_modify() is only available on ARM, I'm unsure if this
> needs a driver change or if the driver is just specific to older
> hardware anyway.  The code is only used in the init path accessing what
> look to be device specific registers so I'm not 100% clear why it
> specifically needs to be an atomic modify.
>
Thierry already submitted a patch yesterday to restrict the driver to only
build on ARM. We can revisit if/when the driver is needed on ARM64.

Guenter



From Minghuan.Lian at nxp.com  Thu Feb 25 23:48:37 2016
From: Minghuan.Lian at nxp.com (Minghuan Lian)
Date: Fri, 26 Feb 2016 15:48:37 +0800
Subject: [PATCH 1/2 v4] dt/bindings: Add bindings for Layerscape SCFG MSI
Message-ID: <1456472918-16163-1-git-send-email-Minghuan.Lian@nxp.com>

Some Layerscape SoCs use a simple MSI controller implementation.
It contains only two SCFG register to trigger and describe a
group 32 MSI interrupts. The patch adds bindings to describe
the controller.

Signed-off-by: Minghuan Lian <Minghuan.Lian at nxp.com>
---
change log:
v4: add interrupt-parent description
v3-v1: no change
 
 .../interrupt-controller/fsl,ls-scfg-msi.txt       | 30 ++++++++++++++++++++++
 1 file changed, 30 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt

diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt
new file mode 100644
index 0000000..9e38949
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-msi.txt
@@ -0,0 +1,30 @@
+* Freescale Layerscape SCFG PCIe MSI controller
+
+Required properties:
+
+- compatible: should be "fsl,<soc-name>-msi" to identify
+	      Layerscape PCIe MSI controller block such as:
+              "fsl,1s1021a-msi"
+              "fsl,1s1043a-msi"
+- msi-controller: indicates that this is a PCIe MSI controller node
+- reg: physical base address of the controller and length of memory mapped.
+- interrupts: an interrupt to the parent interrupt controller.
+
+Optional properties:
+- interrupt-parent: the phandle to the parent interrupt controller.
+
+This interrupt controller hardware is a second level interrupt controller that
+is hooked to a parent interrupt controller: e.g: ARM GIC for ARM-based
+platforms. If interrupt-parent is not provided, the default parent interrupt
+controller will be used.
+Each PCIe node needs to have property msi-parent that points to
+MSI controller node
+
+Examples:
+
+	msi1: msi-controller at 1571000 {
+		compatible = "fsl,1s1043a-msi";
+		reg = <0x0 0x1571000 0x0 0x8>,
+		msi-controller;
+		interrupts = <0 116 0x4>;
+	};
-- 
1.9.1



From Minghuan.Lian at nxp.com  Thu Feb 25 23:48:38 2016
From: Minghuan.Lian at nxp.com (Minghuan Lian)
Date: Fri, 26 Feb 2016 15:48:38 +0800
Subject: [PATCH 2/2 v4] irqchip/Layerscape: Add SCFG MSI controller support
In-Reply-To: <1456472918-16163-1-git-send-email-Minghuan.Lian@nxp.com>
References: <1456472918-16163-1-git-send-email-Minghuan.Lian@nxp.com>
Message-ID: <1456472918-16163-2-git-send-email-Minghuan.Lian@nxp.com>

Some kind of NXP Layerscape SoC provides a MSI
implementation which uses two SCFG registers MSIIR and
MSIR to support 32 MSI interrupts for each PCIe controller.
The patch is to support it.

Signed-off-by: Minghuan Lian <Minghuan.Lian at nxp.com>
---
Change log
v4: 
1. do not register irq_enable irq_disable
2. shorten the chip name to "SCFG"
v3:
1. call of_node_to_fwnode()
v2:
1. rename ls1-msi to ls-scfg-msi
2. remove reg-names MSIIR MSIR 
3. remove calling set_irq_flags()

 drivers/irqchip/Kconfig           |   5 +
 drivers/irqchip/Makefile          |   1 +
 drivers/irqchip/irq-ls-scfg-msi.c | 242 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 248 insertions(+)
 create mode 100644 drivers/irqchip/irq-ls-scfg-msi.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index fb50911..0f2a3c3 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -218,3 +218,8 @@ config IRQ_MXS
 	def_bool y if MACH_ASM9260 || ARCH_MXS
 	select IRQ_DOMAIN
 	select STMP_DEVICE
+
+config LS_SCFG_MSI
+	def_bool y if SOC_LS1021A || ARCH_LAYERSCAPE
+	depends on PCI && PCI_MSI
+	select PCI_MSI_IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 18caacb..37e12de 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -59,3 +59,4 @@ obj-$(CONFIG_ARCH_SA1100)		+= irq-sa11x0.o
 obj-$(CONFIG_INGENIC_IRQ)		+= irq-ingenic.o
 obj-$(CONFIG_IMX_GPCV2)			+= irq-imx-gpcv2.o
 obj-$(CONFIG_PIC32_EVIC)		+= irq-pic32-evic.o
+obj-$(CONFIG_LS_SCFG_MSI)		+= irq-ls-scfg-msi.o
diff --git a/drivers/irqchip/irq-ls-scfg-msi.c b/drivers/irqchip/irq-ls-scfg-msi.c
new file mode 100644
index 0000000..48df920
--- /dev/null
+++ b/drivers/irqchip/irq-ls-scfg-msi.c
@@ -0,0 +1,242 @@
+/*
+ * NXP SCFG MSI(-X) support
+ *
+ * Copyright (C) 2016 NXP Semiconductor.
+ *
+ * Author: Minghuan Lian <Minghuan.Lian at nxp.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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/msi.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/spinlock.h>
+
+#define MSI_MAX_IRQS	32
+#define MSI_IBS_SHIFT	3
+#define MSIR		4
+
+struct ls_scfg_msi {
+	spinlock_t		lock;
+	struct platform_device	*pdev;
+	struct irq_domain	*parent;
+	struct irq_domain	*msi_domain;
+	void __iomem		*regs;
+	phys_addr_t		msiir_addr;
+	u32			nr_irqs;
+	int			irq;
+	DECLARE_BITMAP(used, MSI_MAX_IRQS);
+};
+
+static struct irq_chip ls_scfg_msi_irq_chip = {
+	.name = "MSI",
+	.irq_mask	= pci_msi_mask_irq,
+	.irq_unmask	= pci_msi_unmask_irq,
+};
+
+static struct msi_domain_info ls_scfg_msi_domain_info = {
+	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS |
+		   MSI_FLAG_USE_DEF_CHIP_OPS |
+		   MSI_FLAG_PCI_MSIX),
+	.chip	= &ls_scfg_msi_irq_chip,
+};
+
+static void ls_scfg_msi_compose_msg(struct irq_data *data, struct msi_msg *msg)
+{
+	struct ls_scfg_msi *msi_data = irq_data_get_irq_chip_data(data);
+
+	msg->address_hi = upper_32_bits(msi_data->msiir_addr);
+	msg->address_lo = lower_32_bits(msi_data->msiir_addr);
+	msg->data = data->hwirq << MSI_IBS_SHIFT;
+}
+
+static int ls_scfg_msi_set_affinity(struct irq_data *irq_data,
+				    const struct cpumask *mask, bool force)
+{
+	return -EINVAL;
+}
+
+static struct irq_chip ls_scfg_msi_parent_chip = {
+	.name			= "SCFG",
+	.irq_compose_msi_msg	= ls_scfg_msi_compose_msg,
+	.irq_set_affinity	= ls_scfg_msi_set_affinity,
+};
+
+static int ls_scfg_msi_domain_irq_alloc(struct irq_domain *domain,
+					unsigned int virq,
+					unsigned int nr_irqs,
+					void *args)
+{
+	struct ls_scfg_msi *msi_data = domain->host_data;
+	int pos, err = 0;
+
+	WARN_ON(nr_irqs != 1);
+
+	spin_lock(&msi_data->lock);
+	pos = find_first_zero_bit(msi_data->used, msi_data->nr_irqs);
+	if (pos < msi_data->nr_irqs)
+		__set_bit(pos, msi_data->used);
+	else
+		err = -ENOSPC;
+	spin_unlock(&msi_data->lock);
+
+	if (err)
+		return err;
+
+	irq_domain_set_info(domain, virq, pos,
+			    &ls_scfg_msi_parent_chip, msi_data,
+			    handle_simple_irq, NULL, NULL);
+
+	return 0;
+}
+
+static void ls_scfg_msi_domain_irq_free(struct irq_domain *domain,
+				   unsigned int virq, unsigned int nr_irqs)
+{
+	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+	struct ls_scfg_msi *msi_data = irq_data_get_irq_chip_data(d);
+	int pos;
+
+	pos = d->hwirq;
+	if (pos < 0 || pos >= msi_data->nr_irqs) {
+		pr_err("failed to teardown msi. Invalid hwirq %d\n", pos);
+		return;
+	}
+
+	spin_lock(&msi_data->lock);
+	__clear_bit(pos, msi_data->used);
+	spin_unlock(&msi_data->lock);
+}
+
+static const struct irq_domain_ops ls_scfg_msi_domain_ops = {
+	.alloc	= ls_scfg_msi_domain_irq_alloc,
+	.free	= ls_scfg_msi_domain_irq_free,
+};
+
+static void ls_scfg_msi_irq_handler(struct irq_desc *desc)
+{
+	struct ls_scfg_msi *msi_data = irq_desc_get_handler_data(desc);
+	unsigned long val;
+	int pos, virq;
+
+	chained_irq_enter(irq_desc_get_chip(desc), desc);
+
+	val = ioread32be(msi_data->regs + MSIR);
+	for_each_set_bit(pos, &val, msi_data->nr_irqs) {
+		virq = irq_find_mapping(msi_data->parent, (31 - pos));
+		if (virq)
+			generic_handle_irq(virq);
+	}
+
+	chained_irq_exit(irq_desc_get_chip(desc), desc);
+}
+
+static int ls_scfg_msi_domains_init(struct ls_scfg_msi *msi_data)
+{
+	/* Initialize MSI domain parent */
+	msi_data->parent = irq_domain_add_linear(NULL,
+						 msi_data->nr_irqs,
+						 &ls_scfg_msi_domain_ops,
+						 msi_data);
+	if (!msi_data->parent) {
+		dev_err(&msi_data->pdev->dev, "failed to create IRQ domain\n");
+		return -ENOMEM;
+	}
+
+	msi_data->msi_domain = pci_msi_create_irq_domain(
+				of_node_to_fwnode(msi_data->pdev->dev.of_node),
+				&ls_scfg_msi_domain_info,
+				msi_data->parent);
+	if (!msi_data->msi_domain) {
+		dev_err(&msi_data->pdev->dev, "failed to create MSI domain\n");
+		irq_domain_remove(msi_data->parent);
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+
+static int ls_scfg_msi_probe(struct platform_device *pdev)
+{
+	struct ls_scfg_msi *msi_data;
+	struct resource *res;
+	int ret;
+
+	msi_data = devm_kzalloc(&pdev->dev, sizeof(*msi_data), GFP_KERNEL);
+	if (!msi_data)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	msi_data->regs = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(msi_data->regs)) {
+		dev_err(&pdev->dev, "failed to initialize 'regs'\n");
+		return PTR_ERR(msi_data->regs);
+	}
+	msi_data->msiir_addr = res->start;
+
+	msi_data->irq = platform_get_irq(pdev, 0);
+	if (msi_data->irq <= 0) {
+		dev_err(&pdev->dev, "failed to get MSI irq\n");
+		return -ENODEV;
+	}
+
+	msi_data->pdev = pdev;
+	msi_data->nr_irqs = MSI_MAX_IRQS;
+	spin_lock_init(&msi_data->lock);
+
+	ret = ls_scfg_msi_domains_init(msi_data);
+	if (ret)
+		return ret;
+
+	irq_set_chained_handler_and_data(msi_data->irq,
+					 ls_scfg_msi_irq_handler,
+					 msi_data);
+
+	platform_set_drvdata(pdev, msi_data);
+
+	return 0;
+}
+
+static int ls_scfg_msi_remove(struct platform_device *pdev)
+{
+	struct ls_scfg_msi *msi_data = platform_get_drvdata(pdev);
+
+	irq_set_chained_handler_and_data(msi_data->irq, NULL, NULL);
+
+	irq_domain_remove(msi_data->msi_domain);
+	irq_domain_remove(msi_data->parent);
+
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static const struct of_device_id ls_scfg_msi_id[] = {
+	{ .compatible = "fsl,1s1021a-msi", },
+	{ .compatible = "fsl,1s1043a-msi", },
+	{},
+};
+
+static struct platform_driver ls_scfg_msi_driver = {
+	.driver = {
+		.name = "ls-scfg-msi",
+		.of_match_table = ls_scfg_msi_id,
+	},
+	.probe = ls_scfg_msi_probe,
+	.remove = ls_scfg_msi_remove,
+};
+
+module_platform_driver(ls_scfg_msi_driver);
+
+MODULE_AUTHOR("Minghuan Lian <Minghuan.Lian at nxp.com>");
+MODULE_DESCRIPTION("NXP Layerscape SCFG MSI controller driver");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1



From k.kozlowski at samsung.com  Thu Feb 25 23:51:40 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 26 Feb 2016 16:51:40 +0900
Subject: [RESPIN 0/6] Add support for Exynos SROM Controller driver.
In-Reply-To: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
References: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
Message-ID: <56D0040C.8020204@samsung.com>

On 25.02.2016 17:33, Pankaj Dubey wrote:
> This series is collection of patches already reviewed and merged in
> maintainer's tree, but could not make it thorugh main linus tree, due
> to last moment suggestion of proper location of driver should be
> "drivers/memory" instead of "drivers/soc". I have rebased all the patches
> and moved into "drivers/memory/samsung".
> 
> As this is just a movement without changing actual driver code,
> I have not removed "Reviewed-By", "Tested-By" or "Acked-By".
> 
> To make sure everything is fine, I have again tested it on Exynos5880 based
> Chromebook for normal boot, S2R functionality and its working fine.
> 
> This series has been prepared on top of next-soc branch of Krzysztof's tree.
> 
> Changes w.r.t. original merged patches:
>  - Moved exynos-srom driver into "drivers/memory/samsung"
>  - Moved DT binding documentation into "bindings/memory-controller"
>  - Added new patch for entry of new directory in MAINTAINERS file.
>  - Added new CONFIG as SAMSUNG_MC for grouping Samsung's memory controller drivers.
>  - Added my Signed-off-by for patch 5/6 and 6/6 for touching it.
> 
> Pankaj Dubey (4):
>   dt-bindings: EXYNOS: Add exynos-srom device tree binding
>   drivers: memory: Add support for exynos SROM driver
>   MAINTAINERS: Add maintainers entry for drivers/memory/samsung
>   ARM: EXYNOS: Remove SROM related register settings from mach-exynos
> 
> Pavel Fedin (2):
>   dt-bindings: EXYNOS: Describe SROMc configuration
>   drivers: memory: exynos-srom: Add support for bank configuration

Thanks!

The driver was put under samsung subdirectory of drivers/memory because
Pankaj has a plan to add more stuff there. This way we can avoid
unnecessary movements of files (making history reading more difficult).


I applied (with fixes mentioned in my comments) everything and pushed
here so everyone could play with it:
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=for-v4.6/drivers-soc-exynos-srom-2


It is also included in for-next.

If there is no comments then I will send it in pull request for v4.6.

Best regards,
Krzysztof



From pankaj.dev at st.com  Fri Feb 26 00:06:48 2016
From: pankaj.dev at st.com (Pankaj DEV)
Date: Fri, 26 Feb 2016 16:06:48 +0800
Subject: [RFC v1] clk: Add debugfs nodes for
 enable/disable/set-rate/set-parent
In-Reply-To: <87fuwg9bog.fsf@gmail.com>
References: <1456454309-25037-1-git-send-email-pankaj.dev@st.com>
 <87fuwg9bog.fsf@gmail.com>
Message-ID: <8B5B4FB66A982549A83D90C7791B761007F362D2E1@EAPEX1MAIL2.st.com>

Hey

The prime motive for clk_set_rate is to set new rate for a clock, since the 'clk_rate' currently available, allows only reading.
To provide reading rate from 'clk_set_rate' is just additional feature.

Regards
Pankaj

>-----Original Message-----
>From: Holger Schurig [mailto:holgerschurig at gmail.com]
>Sent: Friday, February 26, 2016 12:54 PM
>To: Pankaj DEV
>Cc: linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
>devicetree at vger.kernel.org; mturquette at linaro.org; kernel at stlinux.com;
>sboyd at codeaurora.org; Laurent MEUNIER; lee.jones at linaro.org; Maxime
>COQUELIN
>Subject: Re: [RFC v1] clk: Add debugfs nodes for enable/disable/set-rate/set-
>parent
>
>Pankaj Dev <pankaj.dev at st.com> writes:
>
>> 1. clk_set_rate : Set new rate to value. Reading returns the current
>> rate
>
>If you can use this to set *and* read it, then "_set_" shouldn't be in the name.
>
>What is wrong with using the existing "clk_rate" for reading/setting the rate?


From thomas.petazzoni at free-electrons.com  Fri Feb 26 00:08:30 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 26 Feb 2016 09:08:30 +0100
Subject: next-20160225 build: 2 failures 44 warnings (next-20160225)
In-Reply-To: <20160226030411.GK18327@sirena.org.uk>
References: <E1aYsmb-0006qb-76@optimist> <20160226030411.GK18327@sirena.org.uk>
Message-ID: <20160226090830.41a63a86@free-electrons.com>

Mark,

On Fri, 26 Feb 2016 12:04:11 +0900, Mark Brown wrote:

> Today's -next fails to build an arm64 allmodconfig due to:
> 
> > 	arm64-allmodconfig
> > ../drivers/pci/host/pci-mvebu.c:755:12: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
> > ../drivers/pci/host/pci-mvebu.c:855:31: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
> > ../drivers/pci/host/pci-mvebu.c:904:16: error: storage size of 'hw' isn't known
> > ../drivers/pci/host/pci-mvebu.c:919:2: error: implicit declaration of function 'pci_common_init_dev' [-Werror=implicit-function-declaration]
> > ../drivers/pci/host/pci-mvebu.c:1282:3: error: implicit declaration of function 'pci_ioremap_io' [-Werror=implicit-function-declaration]
> 
> caused by b4f596b19624 (arm64: add mvebu architecture entry) which
> enables MVBEU on arm64, the commit was present for a little while and
> the error cropped up but didn't get reported due to other things masking
> it.  This looks like the driver needs modernization and probably ought
> to have a !ARM64 dependency for now.

This has already been fixed by:

	[PATCH] PCI: mvebu: Restrict build to 32-bit ARM

submitted by Thierry Redding. I'm Cc'ing Bjorn, who is the one in
charge of merging this fix.

Thanks for reporting!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From thomas.petazzoni at free-electrons.com  Fri Feb 26 00:14:10 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 26 Feb 2016 09:14:10 +0100
Subject: next-20160225 build: 2 failures 44 warnings (next-20160225)
In-Reply-To: <20160226030949.GL18327@sirena.org.uk>
References: <E1aYsmb-0006qb-76@optimist> <20160226030949.GL18327@sirena.org.uk>
Message-ID: <20160226091410.5dad4306@free-electrons.com>

Mark,

On Fri, 26 Feb 2016 12:09:49 +0900, Mark Brown wrote:

> also caused by b4f596b19624 (arm64: add mvebu architecture entry) which
> enables MVBEU on arm64, the commit was present for a little while and
> the error cropped up but didn't get reported due to other things masking
> it.  atomic_io_modify() is only available on ARM, I'm unsure if this
> needs a driver change or if the driver is just specific to older
> hardware anyway.  The code is only used in the init path accessing what
> look to be device specific registers so I'm not 100% clear why it
> specifically needs to be an atomic modify.

atomic_io_modify() is also used in the ->start() and ->stop() hooks, so
not only during initialization. The reason we use atomic_io_modify()
here is because this TIMER_CTRL register is shared with the clocksource
drivers (time-orion.c, time-armada-370-xp.c). Indeed, the timers and
watchdogs share a single register that allows to enable/disable all
timers/watchdogs. Somewhat unfortunate choice, but that's how the HW is.

By far the easiest solution is to add "depends on ARM" to
ORION_WATCHDOG.

Another solution would be to provide an implementation of
atomic_io_modify() on arm64, though that would need the ACK from the
ARM64 maintainers.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From dcb314 at hotmail.com  Fri Feb 26 00:17:54 2016
From: dcb314 at hotmail.com (David Binderman)
Date: Fri, 26 Feb 2016 08:17:54 +0000
Subject: linux-4.5-rc5/arch/arm/mach-omap2/omap-mpuss-lowpower.c:297:
 pointless assignment ?
Message-ID: <DUB128-W59C6D827674EFD33E6CFB09CA70@phx.gbl>

Hello there,

[linux-4.5-rc5/arch/arm/mach-omap2/omap-mpuss-lowpower.c:297]: (style) Variable 'wakeup_cpu' is assigned a value that is never used.

$ fgrep wakeup_cpu linux-4.5-rc5/arch/arm/mach-omap2/omap-mpuss-lowpower.c
??? unsigned int wakeup_cpu;
??? wakeup_cpu = smp_processor_id();
$

Suggest either assign the variable to something or remove it.
Since there is a function call involved, option 1 looks more likely to me.

Regards

David Binderman

 		 	   		  

From vincent.abriou at st.com  Fri Feb 26 00:18:58 2016
From: vincent.abriou at st.com (Vincent ABRIOU)
Date: Fri, 26 Feb 2016 09:18:58 +0100
Subject: [PATCH, RESEND] drm/sti: use u32 to store DMA addresses
In-Reply-To: <1456434711-48393-1-git-send-email-arnd@arndb.de>
References: <1456434711-48393-1-git-send-email-arnd@arndb.de>
Message-ID: <56D00A72.10007@st.com>

Hi Arnd,


Your patch will be part of the next pull request for the STI driver that 
will be done by the end of next week.

Reviewed-by: Vincent Abriou <vincent.abriou at st.com>

On 02/25/2016 10:11 PM, Arnd Bergmann wrote:
> The STi drm driver correctly warns about invalid format strings
> when built with 64-bit dma_addr_t:
>
> sti_hqvdp.c: In function 'sti_hqvdp_vtg_cb':
> sti_hqvdp.c:605:119: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
> sti_hqvdp.c: In function 'sti_hqvdp_atomic_update':
> sti_hqvdp.c:931:118: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]
>
> This could be changed to using the %pad format string, but that
> does not work when printing an rvalue, so instead I'm changing
> the type in the sti_hqvdp structure to u32, which is what gets
> written into the registers anyway.
>
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> ---
>   drivers/gpu/drm/sti/sti_hqvdp.c | 14 ++++++++------
>   1 file changed, 8 insertions(+), 6 deletions(-)
>
> I originally submitted this on Tue, 08 Dec 2015, but got no reply,
> so resending the same patch now.
>
> diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
> index 1d3c3d029603..7818d47bea43 100644
> --- a/drivers/gpu/drm/sti/sti_hqvdp.c
> +++ b/drivers/gpu/drm/sti/sti_hqvdp.c
> @@ -349,7 +349,7 @@ struct sti_hqvdp {
>   	unsigned int curr_field_count;
>   	unsigned int last_field_count;
>   	void *hqvdp_cmd;
> -	dma_addr_t hqvdp_cmd_paddr;
> +	u32 hqvdp_cmd_paddr;
>   	struct sti_vtg *vtg;
>   	bool xp70_initialized;
>   };
> @@ -372,8 +372,8 @@ static const uint32_t hqvdp_supported_formats[] = {
>    */
>   static int sti_hqvdp_get_free_cmd(struct sti_hqvdp *hqvdp)
>   {
> -	int curr_cmd, next_cmd;
> -	dma_addr_t cmd = hqvdp->hqvdp_cmd_paddr;
> +	u32 curr_cmd, next_cmd;
> +	u32 cmd = hqvdp->hqvdp_cmd_paddr;
>   	int i;
>
>   	curr_cmd = readl(hqvdp->regs + HQVDP_MBX_CURRENT_CMD);
> @@ -400,8 +400,8 @@ static int sti_hqvdp_get_free_cmd(struct sti_hqvdp *hqvdp)
>    */
>   static int sti_hqvdp_get_curr_cmd(struct sti_hqvdp *hqvdp)
>   {
> -	int curr_cmd;
> -	dma_addr_t cmd = hqvdp->hqvdp_cmd_paddr;
> +	u32 curr_cmd;
> +	u32 cmd = hqvdp->hqvdp_cmd_paddr;
>   	unsigned int i;
>
>   	curr_cmd = readl(hqvdp->regs + HQVDP_MBX_CURRENT_CMD);
> @@ -612,19 +612,21 @@ int sti_hqvdp_vtg_cb(struct notifier_block *nb, unsigned long evt, void *data)
>   static void sti_hqvdp_init(struct sti_hqvdp *hqvdp)
>   {
>   	int size;
> +	dma_addr_t dma_addr;
>
>   	hqvdp->vtg_nb.notifier_call = sti_hqvdp_vtg_cb;
>
>   	/* Allocate memory for the VDP commands */
>   	size = NB_VDP_CMD * sizeof(struct sti_hqvdp_cmd);
>   	hqvdp->hqvdp_cmd = dma_alloc_wc(hqvdp->dev, size,
> -					&hqvdp->hqvdp_cmd_paddr,
> +					&dma_addr,
>   					GFP_KERNEL | GFP_DMA);
>   	if (!hqvdp->hqvdp_cmd) {
>   		DRM_ERROR("Failed to allocate memory for VDP cmd\n");
>   		return;
>   	}
>
> +	hqvdp->hqvdp_cmd_paddr = (u32)dma_addr;
>   	memset(hqvdp->hqvdp_cmd, 0, size);
>   }
>
>

From thomas.petazzoni at free-electrons.com  Fri Feb 26 00:21:59 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 26 Feb 2016 09:21:59 +0100
Subject: next-20160225 build: 2 failures 44 warnings (next-20160225)
In-Reply-To: <56D001BE.2090209@roeck-us.net>
References: <E1aYsmb-0006qb-76@optimist> <20160226030949.GL18327@sirena.org.uk>
 <56D001BE.2090209@roeck-us.net>
Message-ID: <20160226092159.2f7ef3c7@free-electrons.com>

Guenter,

On Thu, 25 Feb 2016 23:41:50 -0800, Guenter Roeck wrote:

> > also caused by b4f596b19624 (arm64: add mvebu architecture entry) which
> > enables MVBEU on arm64, the commit was present for a little while and
> > the error cropped up but didn't get reported due to other things masking
> > it.  atomic_io_modify() is only available on ARM, I'm unsure if this
> > needs a driver change or if the driver is just specific to older
> > hardware anyway.  The code is only used in the init path accessing what
> > look to be device specific registers so I'm not 100% clear why it
> > specifically needs to be an atomic modify.
> >
> Thierry already submitted a patch yesterday to restrict the driver to only
> build on ARM. We can revisit if/when the driver is needed on ARM64.

Ah, good, thanks. It isn't clear yet whether the driver will be needed
on ARM64 for the Marvell platforms. For Armada 7K/8K, there is a SBSA
compliant watchdog. For Armada 3700, I have only briefly looked, but it
seems to be a different IP than the one used on the 32 bits SoCs.

Thanks Thierry for fixing the issue!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From holgerschurig at gmail.com  Fri Feb 26 00:22:29 2016
From: holgerschurig at gmail.com (Holger Schurig)
Date: Fri, 26 Feb 2016 09:22:29 +0100
Subject: [RFC v1] clk: Add debugfs nodes for
 enable/disable/set-rate/set-parent
In-Reply-To: <8B5B4FB66A982549A83D90C7791B761007F362D2E1@EAPEX1MAIL2.st.com>
 (Pankaj DEV's message of "Fri, 26 Feb 2016 16:06:48 +0800")
References: <1456454309-25037-1-git-send-email-pankaj.dev@st.com>
 <87fuwg9bog.fsf@gmail.com>
 <8B5B4FB66A982549A83D90C7791B761007F362D2E1@EAPEX1MAIL2.st.com>
Message-ID: <87twkvj2yi.fsf@gmail.com>

Pankaj DEV <pankaj.dev at st.com> writes:

> The prime motive for clk_set_rate is to set new rate for a clock,
> since the 'clk_rate' currently available, allows only reading.
> To provide reading rate from 'clk_set_rate' is just additional feature.

Sure.

But my point is to combine things.


After your patch:

- read via clk_rate
- read via clk_set_rate
- write via clk_set_rate

My proposal:

- read via clk_rate
- write via clk_rate


From k at japko.eu  Fri Feb 26 00:24:20 2016
From: k at japko.eu (Krzysztof Adamski)
Date: Fri, 26 Feb 2016 09:24:20 +0100
Subject: [linux-sunxi] Re: [PATCH v2] ARM: dts: sun8i: Add leds and
 switch on Orangepi Plus boards
In-Reply-To: <201602260632.mOdfvVuL%fengguang.wu@intel.com>
References: <20160225204234.GA31610@box2.japko.eu>
 <201602260632.mOdfvVuL%fengguang.wu@intel.com>
Message-ID: <20160226082420.GD25658@box2.japko.eu>

On Fri, Feb 26, 2016 at 06:54:29AM +0800, kbuild test robot wrote:
>Hi Krzysztof,
>
>[auto build test ERROR on robh/for-next]
>[also build test ERROR on v4.5-rc5 next-20160225]

I posted this patch to early. Patches it depends on are only avaiable in 
next-20160226, not 25. It went through Maximes tree (
https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git/ 
sunxi/for-next). This build error can be ignored.

Best regards,
Krzysztof Adamski


From thomas.petazzoni at free-electrons.com  Fri Feb 26 00:32:27 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 26 Feb 2016 09:32:27 +0100
Subject: [PATCH v2 1/6] dt-bindings: arm/marvell: add DT bindings for
 AP806 DFX Server
In-Reply-To: <20160225233710.GJ28849@codeaurora.org>
References: <1456326866-30854-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1456326866-30854-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160225233710.GJ28849@codeaurora.org>
Message-ID: <20160226093227.5d4dc1a7@free-electrons.com>

Stephen,

Thanks for your feedback!

On Thu, 25 Feb 2016 15:37:10 -0800, Stephen Boyd wrote:

> I would think the binding would be done in a way that we don't
> have to describe every little register in this misc register
> block. Instead, dfx server has a compatible:
> 
>  node at f00 {
>  	reg = <0xf00 0x100>;
> 	compatible = "marvell,dfx-ap806";
> 	#clock-cells = <1>;
>  };
> 
> And then a driver that probes this compatible string and
> registers a handful of clks. If we ever get into a situation
> where we want to expose non-clk functionality from this device
> node, we would make some sort of mfd driver that probes based on
> the same compatible string and creates platform devices in
> software to register the clk device component and whatever other
> device type is used. In that situation, we could assign a regmap
> to the mfd device and the clk device would be a child of the mfd
> and get a regmap through the dev->parent pointer.
> 
> TL;DR I'm still lost why we have to describe each clk in DT.

I would entirely agree with you if this DFX Server was some sort of
"system control" IP block that provided clocks, resets, and all sort of
other features.

But this DFX server thing is just a bunch of registers with absolutely
no relation to clocks. Due to this, it would be completely awkward to
have clock references like:

	serial {
		clocks = <&dfxserver 42>;
	};

One will wonder "why the heck this UART controller is using a clock
from this really odd dfxserver thing" ? Currently we have:

	serial {
		clocks = <&coreclk 4>;
	};

which makes a *lot* more sense.

Also, your idea of just hiding everything behind a MFD bothers me quite
a bit. If I push this idea further, then why shouldn't I replace my
entire DT with a single node, that covers the entire register space of
my SoC, and then handle *everything* as a huge MFD. In a way, it would
be quite useful for me, as it would resolve the on-going dispute over
DT binding stability with Rob and Mark.

For sure, I wouldn't have any DT backward compatibility issue, because
everything is hidden in my big MFD. But in terms of the DT as a
representation of the different HW blocks and the relations between
then, such a choice would be quite a failure.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From p.fedin at samsung.com  Fri Feb 26 00:33:53 2016
From: p.fedin at samsung.com (Pavel Fedin)
Date: Fri, 26 Feb 2016 11:33:53 +0300
Subject: [RESPIN 0/6] Add support for Exynos SROM Controller driver.
In-Reply-To: <56D0040C.8020204@samsung.com>
References: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
 <56D0040C.8020204@samsung.com>
Message-ID: <00c701d17070$6de3d1b0$49ab7510$@samsung.com>

 Hello!

> I applied (with fixes mentioned in my comments) everything and pushed
> here so everyone could play with it:
> https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=for-v4.6/drivers-soc-
> exynos-srom-2

 I see the last patch (adding Ethernet chip to DT) is missing. Is it intentional, so that it goes later?

Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia




From acourbot at nvidia.com  Fri Feb 26 00:36:02 2016
From: acourbot at nvidia.com (Alexandre Courbot)
Date: Fri, 26 Feb 2016 17:36:02 +0900
Subject: [PATCH] ARM: dma-mapping: remove arm_dma_set_mask()
Message-ID: <1456475762-29511-1-git-send-email-acourbot@nvidia.com>

arm_dma_set_mask() implements exactly the same behavior as the fallback
that dma_set_mask() takes if the set_dma_mask op is not set. Remove it
and use that fallback instead like the dma_get_mask() counterpart
already does.

Signed-off-by: Alexandre Courbot <acourbot at nvidia.com>
---
 arch/arm/include/asm/dma-mapping.h |  2 --
 arch/arm/mm/dma-mapping.c          | 16 ----------------
 2 files changed, 18 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 6ad1ceda62a5..0f2034d28885 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -162,8 +162,6 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
 
 static inline void dma_mark_clean(void *addr, size_t size) { }
 
-extern int arm_dma_set_mask(struct device *dev, u64 dma_mask);
-
 /**
  * arm_dma_alloc - allocate consistent memory for DMA
  * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 9f996a3d79f7..0525076cae38 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -141,7 +141,6 @@ struct dma_map_ops arm_dma_ops = {
 	.sync_single_for_device	= arm_dma_sync_single_for_device,
 	.sync_sg_for_cpu	= arm_dma_sync_sg_for_cpu,
 	.sync_sg_for_device	= arm_dma_sync_sg_for_device,
-	.set_dma_mask		= arm_dma_set_mask,
 };
 EXPORT_SYMBOL(arm_dma_ops);
 
@@ -160,7 +159,6 @@ struct dma_map_ops arm_coherent_dma_ops = {
 	.get_sgtable		= arm_dma_get_sgtable,
 	.map_page		= arm_coherent_dma_map_page,
 	.map_sg			= arm_dma_map_sg,
-	.set_dma_mask		= arm_dma_set_mask,
 };
 EXPORT_SYMBOL(arm_coherent_dma_ops);
 
@@ -1004,16 +1002,6 @@ int dma_supported(struct device *dev, u64 mask)
 }
 EXPORT_SYMBOL(dma_supported);
 
-int arm_dma_set_mask(struct device *dev, u64 dma_mask)
-{
-	if (!dev->dma_mask || !dma_supported(dev, dma_mask))
-		return -EIO;
-
-	*dev->dma_mask = dma_mask;
-
-	return 0;
-}
-
 #define PREALLOC_DMA_DEBUG_ENTRIES	4096
 
 static int __init dma_debug_do_init(void)
@@ -1867,8 +1855,6 @@ struct dma_map_ops iommu_ops = {
 	.unmap_sg		= arm_iommu_unmap_sg,
 	.sync_sg_for_cpu	= arm_iommu_sync_sg_for_cpu,
 	.sync_sg_for_device	= arm_iommu_sync_sg_for_device,
-
-	.set_dma_mask		= arm_dma_set_mask,
 };
 
 struct dma_map_ops iommu_coherent_ops = {
@@ -1882,8 +1868,6 @@ struct dma_map_ops iommu_coherent_ops = {
 
 	.map_sg		= arm_coherent_iommu_map_sg,
 	.unmap_sg	= arm_coherent_iommu_unmap_sg,
-
-	.set_dma_mask	= arm_dma_set_mask,
 };
 
 /**
-- 
2.7.1



From xinliang.liu at linaro.org  Fri Feb 26 00:40:17 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri, 26 Feb 2016 16:40:17 +0800
Subject: [PATCH v6 00/11] Add DRM Driver for HiSilicon Kirin hi6220 SoC
Message-ID: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>

This patch set adds a new drm driver for HiSilicon Kirin hi6220 SoC.
Current testing and support board is Hikey board which is one of Linaro
96boards. It is an arm64 open source board. For more information about
this board, please access https://www.96boards.org.

Hardware Detail
---------------
  The display subsystem of Hi6220 SoC is shown as bellow:
 +-----+       +----------+     +-----+     +-------------+
 |     |       |          |     |     |     |             |             	
 | FB  |------>|   ADE    |---->| DSI |---->|   External  |
 |     |       |          |     |     |     |  HDMI/panel |
 +-----+       +----------+     +-----+     +-------------+

- ADE(Advanced Display Engine) is the display controller. It contains 7
channels, 3 overlay compositors and a LDI.
  - A channel looks like: DMA-->clip-->scale-->ctrans(or called csc).
  - Overlay compositor is response to compose planes which come from 7
  channels and pass composed image to LDI.
  - LDI is response to generate timings and RGB data stream.
- DSI converts the RGB data stream from ADE to DSI packets.
- External HDMI/panel module is connected with DSI bus. Now Hikey use a
  ADI's ADV7533 external HDMI chip.

Change History
-------------
Changes in v6:
- Cleanup values part of reg and clocks relevant properties.
- Change "pclk_dsi" clock name to "pclk".

Changes in v5:
- Remove endpoint unit address of dsi output port.
- Use syscon to access ADE media NOC QoS registers instread of directly
  writing registers.
- Use reset controller to reset ADE instead of directly writing registers.

Changes in v4:
- Describe more specific of clocks and ports of binding docs.
- Fix indentation of binding docs.

Changes in v3:
- Move and rename all the files to kirin sub-directory.
  So that we could separate different seires SoCs' driver.
- Make ade as the drm master node.
- Replace drm_platform_init, load, unload implementation.
- Use assigned-clocks to set clock rate.
- Use ports to connect display relavant nodes.
- Rename hisi_drm_dsi.c to dw_drm_dsi.c
- Make encoder type as DRM_MODE_ENCODER_DSI.
- A few cleanup on regs and code.

Changes in v2:
- Remove abtraction layer of plane/crtc/encoder/connector.
- Refactor atomic implementation according to Daniel Vetter's guides:
http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html
http://blog.ffwll.ch/2015/09/xdc-2015-atomic-modesetting-for-drivers.html
http://blog.ffwll.ch/2015/08/atomic-modesetting-design-overview.html
- Use bridge instead of slave encoder to connect external HDMI.
- Move dt binding docs to bindings/display/hisilicon directory.

Xinliang Liu (11):
  drm/hisilicon: Add device tree binding for hi6220 display subsystem
  drm/hisilicon: Add hisilicon kirin drm master driver
  drm/hisilicon: Add crtc driver for ADE
  drm/hisilicon: Add plane driver for ADE
  drm/hisilicon: Add vblank driver for ADE
  drm/hisilicon: Add cma fbdev and hotplug
  drm/hisilicon: Add designware dsi encoder driver
  drm/hisilicon: Add designware dsi host driver
  drm/hisilicon: Add support for external bridge
  MAINTAINERS: Add maintainer for hisilicon DRM driver
  arm64: dts: hisilicon: Add display subsystem DT nodes for hi6220

 .../bindings/display/hisilicon/dw-dsi.txt          |   72 ++
 .../bindings/display/hisilicon/hisi-ade.txt        |   64 ++
 MAINTAINERS                                        |   10 +
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts     |   40 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi          |   55 +
 drivers/gpu/drm/Kconfig                            |    2 +
 drivers/gpu/drm/Makefile                           |    1 +
 drivers/gpu/drm/hisilicon/Kconfig                  |    5 +
 drivers/gpu/drm/hisilicon/Makefile                 |    5 +
 drivers/gpu/drm/hisilicon/kirin/Kconfig            |   10 +
 drivers/gpu/drm/hisilicon/kirin/Makefile           |    5 +
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c       |  845 ++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h       |   83 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h    |  290 ++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c    | 1047 ++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c    |  382 +++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h    |   31 +
 17 files changed, 2947 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
 create mode 100644 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h

-- 
2.7.1



From xinliang.liu at linaro.org  Fri Feb 26 00:40:18 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri, 26 Feb 2016 16:40:18 +0800
Subject: [PATCH v6 01/11] drm/hisilicon: Add device tree binding for hi6220
 display subsystem
In-Reply-To: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
References: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456476028-36880-2-git-send-email-xinliang.liu@linaro.org>

Add ADE display controller binding doc.
Add DesignWare DSI Host Controller v1.20a binding doc.

v6:
- Cleanup values part of reg and clocks properties.
- Change "pclk_dsi" clock name to "pclk".
v5:
- Remove endpoint unit address of dsi output port.
- Add "hisilicon,noc-syscon" property for ADE NOC QoS syscon.
- Add "resets" property for ADE reset.
v4:
- Describe more specific of clocks and ports.
- Fix indentation.
v3:
- Make ade as the drm master node.
- Use assigned-clocks to set clock rate.
- Use ports to connect display relavant nodes.
v2:
- Move dt binding docs to bindings/display/hisilicon directory.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 .../bindings/display/hisilicon/dw-dsi.txt          | 72 ++++++++++++++++++++++
 .../bindings/display/hisilicon/hisi-ade.txt        | 64 +++++++++++++++++++
 2 files changed, 136 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
 create mode 100644 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt

diff --git a/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
new file mode 100644
index 000000000000..d270bfe4e4e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
@@ -0,0 +1,72 @@
+Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
+
+A DSI Host Controller resides in the middle of display controller and external
+HDMI converter or panel.
+
+Required properties:
+- compatible: value should be "hisilicon,hi6220-dsi".
+- reg: physical base address and length of dsi controller's registers.
+- clocks: contains APB clock phandle + clock-specifier pair.
+- clock-names: should be "pclk".
+- ports: contains DSI controller input and output sub port.
+  The input port connects to ADE output port with the reg value "0".
+  The output port with the reg value "1", it could connect to panel or
+  any other bridge endpoints.
+  See Documentation/devicetree/bindings/graph.txt for more device graph info.
+
+A example of HiKey board hi6220 SoC and board specific DT entry:
+Example:
+
+SoC specific:
+	dsi: dsi at f4107800 {
+		compatible = "hisilicon,hi6220-dsi";
+		reg = <0x0 0xf4107800 0x0 0x100>;
+		clocks = <&media_ctrl  HI6220_DSI_PCLK>;
+		clock-names = "pclk";
+		status = "disabled";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			/* 0 for input port */
+			port at 0 {
+				reg = <0>;
+				dsi_in: endpoint {
+					remote-endpoint = <&ade_out>;
+				};
+			};
+		};
+	};
+
+
+Board specific:
+	&dsi {
+		status = "ok";
+
+		ports {
+			/* 1 for output port */
+			port at 1 {
+				reg = <1>;
+
+				dsi_out0: endpoint at 0 {
+					remote-endpoint = <&adv7533_in>;
+				};
+			};
+		};
+	};
+
+	&i2c2 {
+		...
+
+		adv7533: adv7533 at 39 {
+			...
+
+			port {
+				adv7533_in: endpoint {
+					remote-endpoint = <&dsi_out0>;
+				};
+			};
+		};
+	};
+
diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
new file mode 100644
index 000000000000..38dc9d60eef8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
@@ -0,0 +1,64 @@
+Device-Tree bindings for hisilicon ADE display controller driver
+
+ADE (Advanced Display Engine) is the display controller which grab image
+data from memory, do composition, do post image processing, generate RGB
+timing stream and transfer to DSI.
+
+Required properties:
+- compatible: value should be "hisilicon,hi6220-ade".
+- reg: physical base address and length of the ADE controller's registers.
+- hisilicon,noc-syscon: ADE NOC QoS syscon.
+- resets: The ADE reset controller node.
+- interrupt: the ldi vblank interrupt number used.
+- clocks: a list of phandle + clock-specifier pairs, one for each entry
+  in clock-names.
+- clock-names: should contain:
+  "clk_ade_core" for the ADE core clock.
+  "clk_codec_jpeg" for the media NOC QoS clock, which use the same clock with
+  jpeg codec.
+  "clk_ade_pix" for the ADE pixel clok.
+- assigned-clocks: Should contain "clk_ade_core" and "clk_codec_jpeg" clocks'
+  phandle + clock-specifier pairs.
+- assigned-clock-rates: clock rates, one for each entry in assigned-clocks.
+  The rate of "clk_ade_core" could be "360000000" or "180000000";
+  The rate of "clk_codec_jpeg" could be or less than "1440000000".
+  These rate values could be configured according to performance and power
+  consumption.
+- port: the output port. This contains one endpoint subnode, with its
+  remote-endpoint set to the phandle of the connected DSI input endpoint.
+  See Documentation/devicetree/bindings/graph.txt for more device graph info.
+
+Optional properties:
+- dma-coherent: Present if dma operations are coherent.
+
+
+A example of HiKey board hi6220 SoC specific DT entry:
+Example:
+
+	ade: ade at f4100000 {
+		compatible = "hisilicon,hi6220-ade";
+		reg = <0x0 0xf4100000 0x0 0x7800>;
+		reg-names = "ade_base";
+		hisilicon,noc-syscon = <&medianoc_ade>;
+		resets = <&media_ctrl MEDIA_ADE>;
+		interrupts = <0 115 4>; /* ldi interrupt */
+
+		clocks = <&media_ctrl HI6220_ADE_CORE>,
+			 <&media_ctrl HI6220_CODEC_JPEG>,
+			 <&media_ctrl HI6220_ADE_PIX_SRC>;
+		/*clock name*/
+		clock-names  = "clk_ade_core",
+			       "clk_codec_jpeg",
+			       "clk_ade_pix";
+
+		assigned-clocks = <&media_ctrl HI6220_ADE_CORE>,
+			<&media_ctrl HI6220_CODEC_JPEG>;
+		assigned-clock-rates = <360000000>, <288000000>;
+		dma-coherent;
+
+		port {
+			ade_out: endpoint {
+				remote-endpoint = <&dsi_in>;
+			};
+		};
+	};
-- 
2.7.1



From xinliang.liu at linaro.org  Fri Feb 26 00:40:19 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri, 26 Feb 2016 16:40:19 +0800
Subject: [PATCH v6 02/11] drm/hisilicon: Add hisilicon kirin drm master driver
In-Reply-To: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
References: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456476028-36880-3-git-send-email-xinliang.liu@linaro.org>

Add kirin DRM master driver for hi6220 SoC which used in HiKey board.
Add dumb buffer feature.
Add prime dmabuf feature.

v6: None.
v5: None.
v4: None.
v3:
- Move and rename all the files to kirin sub-directory.
  So that we could separate different seires SoCs' driver.
- Replace drm_platform_init, load, unload implementation.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/Kconfig                         |   2 +
 drivers/gpu/drm/Makefile                        |   1 +
 drivers/gpu/drm/hisilicon/Kconfig               |   5 +
 drivers/gpu/drm/hisilicon/Makefile              |   5 +
 drivers/gpu/drm/hisilicon/kirin/Kconfig         |   9 +
 drivers/gpu/drm/hisilicon/kirin/Makefile        |   3 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 321 ++++++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  20 ++
 8 files changed, 366 insertions(+)
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b50ae60f5f50..f5c5656e2547 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -277,3 +277,5 @@ source "drivers/gpu/drm/imx/Kconfig"
 source "drivers/gpu/drm/vc4/Kconfig"
 
 source "drivers/gpu/drm/etnaviv/Kconfig"
+
+source "drivers/gpu/drm/hisilicon/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 61766dec6a8d..60554832079c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -74,3 +74,4 @@ obj-y			+= panel/
 obj-y			+= bridge/
 obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
+obj-y			+= hisilicon/
diff --git a/drivers/gpu/drm/hisilicon/Kconfig b/drivers/gpu/drm/hisilicon/Kconfig
new file mode 100644
index 000000000000..558c61b1b8e8
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/Kconfig
@@ -0,0 +1,5 @@
+#
+# hisilicon drm device configuration.
+# Please keep this list sorted alphabetically
+
+source "drivers/gpu/drm/hisilicon/kirin/Kconfig"
diff --git a/drivers/gpu/drm/hisilicon/Makefile b/drivers/gpu/drm/hisilicon/Makefile
new file mode 100644
index 000000000000..e3f6d493c996
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for hisilicon drm drivers.
+# Please keep this list sorted alphabetically
+
+obj-$(CONFIG_DRM_HISI_KIRIN) += kirin/
diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig b/drivers/gpu/drm/hisilicon/kirin/Kconfig
new file mode 100644
index 000000000000..3ac4b8edeac1
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
@@ -0,0 +1,9 @@
+config DRM_HISI_KIRIN
+	tristate "DRM Support for Hisilicon Kirin series SoCs Platform"
+	depends on DRM
+	select DRM_KMS_HELPER
+	select DRM_GEM_CMA_HELPER
+	select DRM_KMS_CMA_HELPER
+	help
+	  Choose this option if you have a hisilicon Kirin chipsets(hi6220).
+	  If M is selected the module will be called kirin-drm.
diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile b/drivers/gpu/drm/hisilicon/kirin/Makefile
new file mode 100644
index 000000000000..cb346de47d48
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -0,0 +1,3 @@
+kirin-drm-y := kirin_drm_drv.o
+
+obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
new file mode 100644
index 000000000000..789ebd1f5922
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -0,0 +1,321 @@
+/*
+ * Hisilicon Kirin SoCs drm master driver
+ *
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * Author:
+ *	Xinliang Liu <z.liuxinliang at hisilicon.com>
+ *	Xinliang Liu <xinliang.liu at linaro.org>
+ *	Xinwei Kong <kong.kongxinwei at hisilicon.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.
+ *
+ */
+
+#include <linux/of_platform.h>
+#include <linux/component.h>
+#include <linux/of_graph.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_gem_cma_helper.h>
+#include <drm/drm_fb_cma_helper.h>
+#include <drm/drm_atomic_helper.h>
+
+#include "kirin_drm_drv.h"
+
+static struct kirin_dc_ops *dc_ops;
+
+static int kirin_drm_kms_cleanup(struct drm_device *dev)
+{
+	dc_ops->cleanup(dev);
+	drm_mode_config_cleanup(dev);
+
+	return 0;
+}
+
+static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
+	.fb_create = drm_fb_cma_create,
+	.atomic_check = drm_atomic_helper_check,
+	.atomic_commit = drm_atomic_helper_commit,
+};
+
+static void kirin_drm_mode_config_init(struct drm_device *dev)
+{
+	dev->mode_config.min_width = 0;
+	dev->mode_config.min_height = 0;
+
+	dev->mode_config.max_width = 2048;
+	dev->mode_config.max_height = 2048;
+
+	dev->mode_config.funcs = &kirin_drm_mode_config_funcs;
+}
+
+static int kirin_drm_kms_init(struct drm_device *dev)
+{
+	int ret;
+
+	dev_set_drvdata(dev->dev, dev);
+
+	/* dev->mode_config initialization */
+	drm_mode_config_init(dev);
+	kirin_drm_mode_config_init(dev);
+
+	/* display controller init */
+	ret = dc_ops->init(dev);
+	if (ret)
+		goto err_mode_config_cleanup;
+
+	/* bind and init sub drivers */
+	ret = component_bind_all(dev->dev, dev);
+	if (ret) {
+		DRM_ERROR("failed to bind all component.\n");
+		goto err_dc_cleanup;
+	}
+
+	/* reset all the states of crtc/plane/encoder/connector */
+	drm_mode_config_reset(dev);
+
+	return 0;
+
+err_dc_cleanup:
+	dc_ops->cleanup(dev);
+err_mode_config_cleanup:
+	drm_mode_config_cleanup(dev);
+
+	return ret;
+}
+
+static const struct file_operations kirin_drm_fops = {
+	.owner		= THIS_MODULE,
+	.open		= drm_open,
+	.release	= drm_release,
+	.unlocked_ioctl	= drm_ioctl,
+#ifdef CONFIG_COMPAT
+	.compat_ioctl	= drm_compat_ioctl,
+#endif
+	.poll		= drm_poll,
+	.read		= drm_read,
+	.llseek		= no_llseek,
+	.mmap		= drm_gem_cma_mmap,
+};
+
+static int kirin_gem_cma_dumb_create(struct drm_file *file,
+				     struct drm_device *dev,
+				     struct drm_mode_create_dumb *args)
+{
+	return drm_gem_cma_dumb_create_internal(file, dev, args);
+}
+
+static struct drm_driver kirin_drm_driver = {
+	.driver_features	= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
+				  DRIVER_ATOMIC,
+	.fops			= &kirin_drm_fops,
+	.set_busid		= drm_platform_set_busid,
+
+	.gem_free_object	= drm_gem_cma_free_object,
+	.gem_vm_ops		= &drm_gem_cma_vm_ops,
+	.dumb_create		= kirin_gem_cma_dumb_create,
+	.dumb_map_offset	= drm_gem_cma_dumb_map_offset,
+	.dumb_destroy		= drm_gem_dumb_destroy,
+
+	.prime_handle_to_fd	= drm_gem_prime_handle_to_fd,
+	.prime_fd_to_handle	= drm_gem_prime_fd_to_handle,
+	.gem_prime_export	= drm_gem_prime_export,
+	.gem_prime_import	= drm_gem_prime_import,
+	.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
+	.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
+	.gem_prime_vmap		= drm_gem_cma_prime_vmap,
+	.gem_prime_vunmap	= drm_gem_cma_prime_vunmap,
+	.gem_prime_mmap		= drm_gem_cma_prime_mmap,
+
+	.name			= "kirin",
+	.desc			= "Hisilicon Kirin SoCs' DRM Driver",
+	.date			= "20150718",
+	.major			= 1,
+	.minor			= 0,
+};
+
+static int compare_of(struct device *dev, void *data)
+{
+	return dev->of_node == data;
+}
+
+static int kirin_drm_connectors_register(struct drm_device *dev)
+{
+	struct drm_connector *connector;
+	struct drm_connector *failed_connector;
+	int ret;
+
+	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+		ret = drm_connector_register(connector);
+		if (ret) {
+			failed_connector = connector;
+			goto err;
+		}
+	}
+
+	return 0;
+
+err:
+	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+		if (failed_connector == connector)
+			break;
+		drm_connector_unregister(connector);
+	}
+
+	return ret;
+}
+
+static int kirin_drm_bind(struct device *dev)
+{
+	struct drm_driver *driver = &kirin_drm_driver;
+	struct drm_device *drm_dev;
+	int ret;
+
+	drm_dev = drm_dev_alloc(driver, dev);
+	if (!drm_dev)
+		return -ENOMEM;
+
+	drm_dev->platformdev = to_platform_device(dev);
+
+	ret = kirin_drm_kms_init(drm_dev);
+	if (ret)
+		goto err_drm_dev_unref;
+
+	ret = drm_dev_register(drm_dev, 0);
+	if (ret)
+		goto err_kms_cleanup;
+
+	/* connectors should be registered after drm device register */
+	ret = kirin_drm_connectors_register(drm_dev);
+	if (ret)
+		goto err_drm_dev_unregister;
+
+	DRM_INFO("Initialized %s %d.%d.%d %s on minor %d\n",
+		 driver->name, driver->major, driver->minor, driver->patchlevel,
+		 driver->date, drm_dev->primary->index);
+
+	return 0;
+
+err_drm_dev_unregister:
+	drm_dev_unregister(drm_dev);
+err_kms_cleanup:
+	kirin_drm_kms_cleanup(drm_dev);
+err_drm_dev_unref:
+	drm_dev_unref(drm_dev);
+
+	return ret;
+}
+
+static void kirin_drm_unbind(struct device *dev)
+{
+	drm_put_dev(dev_get_drvdata(dev));
+}
+
+static const struct component_master_ops kirin_drm_ops = {
+	.bind = kirin_drm_bind,
+	.unbind = kirin_drm_unbind,
+};
+
+static const struct of_device_id kirin_drm_dt_ids[] = {
+	{ /* end node */ },
+};
+MODULE_DEVICE_TABLE(of, kirin_drm_dt_ids);
+
+static int kirin_get_dc_ops(struct device_node *np)
+{
+	const struct of_device_id *match_id;
+
+	match_id = of_match_node(kirin_drm_dt_ids, np);
+	if (!match_id) {
+		DRM_ERROR("failed to match dt id\n");
+		return -EINVAL;
+	}
+
+	dc_ops = (struct kirin_dc_ops *)match_id->data;
+	if (!dc_ops) {
+		DRM_ERROR("dt id data is null\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static struct device_node *kirin_get_remote_node(struct device_node *np)
+{
+	struct device_node *endpoint, *remote;
+
+	/* get the first endpoint, in our case only one remote node
+	 * is connected to display controller.
+	 */
+	endpoint = of_graph_get_next_endpoint(np, NULL);
+	if (!endpoint) {
+		DRM_ERROR("no valid endpoint node\n");
+		return ERR_PTR(-ENODEV);
+	}
+	of_node_put(endpoint);
+
+	remote = of_graph_get_remote_port_parent(endpoint);
+	if (!remote) {
+		DRM_ERROR("no valid remote node\n");
+		return ERR_PTR(-ENODEV);
+	}
+	of_node_put(remote);
+
+	if (!of_device_is_available(remote)) {
+		DRM_ERROR("not available for remote node\n");
+		return ERR_PTR(-ENODEV);
+	}
+
+	return remote;
+}
+
+static int kirin_drm_platform_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct component_match *match = NULL;
+	struct device_node *remote;
+	int ret;
+
+	ret = kirin_get_dc_ops(np);
+	if (ret)
+		return ret;
+
+	remote = kirin_get_remote_node(np);
+	if (IS_ERR(remote))
+		return PTR_ERR(remote);
+
+	component_match_add(dev, &match, compare_of, remote);
+
+	return component_master_add_with_match(dev, &kirin_drm_ops, match);
+
+	return 0;
+}
+
+static int kirin_drm_platform_remove(struct platform_device *pdev)
+{
+	component_master_del(&pdev->dev, &kirin_drm_ops);
+	dc_ops = NULL;
+	return 0;
+}
+
+static struct platform_driver kirin_drm_platform_driver = {
+	.probe = kirin_drm_platform_probe,
+	.remove = kirin_drm_platform_remove,
+	.driver = {
+		.name = "kirin-drm",
+		.of_match_table = kirin_drm_dt_ids,
+	},
+};
+
+module_platform_driver(kirin_drm_platform_driver);
+
+MODULE_AUTHOR("Xinliang Liu <xinliang.liu at linaro.org>");
+MODULE_AUTHOR("Xinliang Liu <z.liuxinliang at hisilicon.com>");
+MODULE_AUTHOR("Xinwei Kong <kong.kongxinwei at hisilicon.com>");
+MODULE_DESCRIPTION("hisilicon Kirin SoCs' DRM master driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
new file mode 100644
index 000000000000..75e9d82356d4
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -0,0 +1,20 @@
+/*
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __KIRIN_DRM_DRV_H__
+#define __KIRIN_DRM_DRV_H__
+
+/* display controller init/cleanup ops */
+struct kirin_dc_ops {
+	int (*init)(struct drm_device *dev);
+	void (*cleanup)(struct drm_device *dev);
+};
+
+#endif /* __KIRIN_DRM_DRV_H__ */
-- 
2.7.1



From xinliang.liu at linaro.org  Fri Feb 26 00:40:20 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri, 26 Feb 2016 16:40:20 +0800
Subject: [PATCH v6 03/11] drm/hisilicon: Add crtc driver for ADE
In-Reply-To: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
References: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456476028-36880-4-git-send-email-xinliang.liu@linaro.org>

Add crtc funcs and helper funcs for ADE.

v6:
- Cleanup reg-names dt parsing.
v5:
- Use syscon to access ADE media NOC QoS registers instread of directly
  writing registers.
- Use reset controller to reset ADE instead of directly writing registers.
v4: None.
v3:
- Make ade as the master driver.
- Use port to connect with encoder.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/Makefile        |   3 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 290 +++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 452 ++++++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  15 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |   8 +
 5 files changed, 767 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c

diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile b/drivers/gpu/drm/hisilicon/kirin/Makefile
index cb346de47d48..2a61ab006ddb 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Makefile
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -1,3 +1,4 @@
-kirin-drm-y := kirin_drm_drv.o
+kirin-drm-y := kirin_drm_drv.o \
+	       kirin_drm_ade.o
 
 obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
new file mode 100644
index 000000000000..eb444b899c7b
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
@@ -0,0 +1,290 @@
+/*
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __KIRIN_ADE_REG_H__
+#define __KIRIN_ADE_REG_H__
+
+/*
+ * ADE Registers
+ */
+#define MASK(x)				(BIT(x) - 1)
+
+#define ADE_CTRL			0x0004
+#define FRM_END_START_OFST		0
+#define FRM_END_START_MASK		MASK(2)
+#define ADE_CTRL1			0x008C
+#define AUTO_CLK_GATE_EN_OFST		0
+#define AUTO_CLK_GATE_EN		BIT(0)
+#define ADE_ROT_SRC_CFG			0x0010
+#define ADE_DISP_SRC_CFG		0x0018
+#define ADE_WDMA2_SRC_CFG		0x001C
+#define ADE_SEC_OVLY_SRC_CFG		0x0020
+#define ADE_WDMA3_SRC_CFG		0x0024
+#define ADE_OVLY1_TRANS_CFG		0x002C
+#define ADE_EN				0x0100
+#define ADE_DISABLE			0
+#define ADE_ENABLE			1
+#define INTR_MASK_CPU(x)		(0x0C10 + (x) * 0x4)
+#define ADE_FRM_DISGARD_CTRL		0x00A4
+/* reset and reload regs */
+#define ADE_SOFT_RST_SEL(x)		(0x0078 + (x) * 0x4)
+#define ADE_RELOAD_DIS(x)		(0x00AC + (x) * 0x4)
+#define RDMA_OFST			0
+#define CLIP_OFST			15
+#define SCL_OFST			21
+#define CTRAN_OFST			24
+#define OVLY_OFST			37 /* 32+5 */
+/* channel regs */
+#define RD_CH_PE(x)			(0x1000 + (x) * 0x80)
+#define RD_CH_CTRL(x)			(0x1004 + (x) * 0x80)
+#define RD_CH_ADDR(x)			(0x1008 + (x) * 0x80)
+#define RD_CH_SIZE(x)			(0x100C + (x) * 0x80)
+#define RD_CH_STRIDE(x)			(0x1010 + (x) * 0x80)
+#define RD_CH_SPACE(x)			(0x1014 + (x) * 0x80)
+#define RD_CH_PARTIAL_SIZE(x)		(0x1018 + (x) * 0x80)
+#define RD_CH_PARTIAL_SPACE(x)		(0x101C + (x) * 0x80)
+#define RD_CH_EN(x)			(0x1020 + (x) * 0x80)
+#define RD_CH_STATUS(x)			(0x1024 + (x) * 0x80)
+#define RD_CH_DISP_CTRL			0x1404
+#define RD_CH_DISP_ADDR			0x1408
+#define RD_CH_DISP_SIZE			0x140C
+#define RD_CH_DISP_STRIDE		0x1410
+#define RD_CH_DISP_SPACE		0x1414
+#define RD_CH_DISP_EN			0x142C
+/* clip regs */
+#define ADE_CLIP_DISABLE(x)		(0x6800 + (x) * 0x100)
+#define ADE_CLIP_SIZE0(x)		(0x6804 + (x) * 0x100)
+#define ADE_CLIP_SIZE1(x)		(0x6808 + (x) * 0x100)
+#define ADE_CLIP_SIZE2(x)		(0x680C + (x) * 0x100)
+#define ADE_CLIP_CFG_OK(x)		(0x6810 + (x) * 0x100)
+/* scale regs */
+#define ADE_SCL1_MUX_CFG		0x000C
+#define ADE_SCL2_SRC_CFG		0x0014
+#define ADE_SCL3_MUX_CFG		0x0008
+#define ADE_SCL_CTRL(x)			(0x3000 + (x) * 0x800)
+#define ADE_SCL_HSP(x)			(0x3004 + (x) * 0x800)
+#define ADE_SCL_UV_HSP(x)		(0x3008 + (x) * 0x800)
+#define ADE_SCL_VSP(x)			(0x300C + (x) * 0x800)
+#define ADE_SCL_UV_VSP(x)		(0x3010 + (x) * 0x800)
+#define ADE_SCL_ORES(x)			(0x3014 + (x) * 0x800)
+#define ADE_SCL_IRES(x)			(0x3018 + (x) * 0x800)
+#define ADE_SCL_START(x)		(0x301C + (x) * 0x800)
+#define ADE_SCL_ERR(x)			(0x3020 + (x) * 0x800)
+#define ADE_SCL_PIX_OFST(x)		(0x3024 + (x) * 0x800)
+#define ADE_SCL_UV_PIX_OFST(x)		(0x3028 + (x) * 0x800)
+#define ADE_SCL_COEF_CLR(x)		(0x3030 + (x) * 0x800)
+#define ADE_SCL_HCOEF(x, m, n)		(0x3100 + (x) * 0x800 + \
+					12 * (m) + 4 * (n))
+#define ADE_SCL_VCOEF(x, i, j)		(0x340C + (x) * 0x800 + \
+					12 * (i) + 4 * (j))
+/* ctran regs */
+#define ADE_CTRAN5_TRANS_CFG		0x0040
+#define ADE_CTRAN_DIS(x)		(0x5004 + (x) * 0x100)
+#define CTRAN_BYPASS_ON			1
+#define CTRAN_BYPASS_OFF		0
+#define ADE_CTRAN_MODE_CHOOSE(x)	(0x5008 + (x) * 0x100)
+#define ADE_CTRAN_STAT(x)		(0x500C + (x) * 0x100)
+#define ADE_CTRAN_CHDC0(x)		(0x5010 + (x) * 0x100)
+#define ADE_CTRAN_CHDC1(x)		(0x5014 + (x) * 0x100)
+#define ADE_CTRAN_CHDC2(x)		(0x5018 + (x) * 0x100)
+#define ADE_CTRAN_CHDC3(x)		(0x501C + (x) * 0x100)
+#define ADE_CTRAN_CHDC4(x)		(0x5020 + (x) * 0x100)
+#define ADE_CTRAN_CHDC5(x)		(0x5024 + (x) * 0x100)
+#define ADE_CTRAN_CSC0(x)		(0x5028 + (x) * 0x100)
+#define ADE_CTRAN_CSC1(x)		(0x502C + (x) * 0x100)
+#define ADE_CTRAN_CSC2(x)		(0x5030 + (x) * 0x100)
+#define ADE_CTRAN_CSC3(x)		(0x5034 + (x) * 0x100)
+#define ADE_CTRAN_CSC4(x)		(0x5038 + (x) * 0x100)
+#define ADE_CTRAN_IMAGE_SIZE(x)		(0x503C + (x) * 0x100)
+#define ADE_CTRAN_CFG_OK(x)		(0x5040 + (x) * 0x100)
+/* overlay regs */
+#define ADE_OVLY_ALPHA_ST		0x2000
+#define ADE_OVLY_CH_XY0(x)		(0x2004 + (x) * 4)
+#define ADE_OVLY_CH_XY1(x)		(0x2024 + (x) * 4)
+#define ADE_OVLY_CH_CTL(x)		(0x204C + (x) * 4)
+#define ADE_OVLY_OUTPUT_SIZE(x)		(0x2070 + (x) * 8)
+#define OUTPUT_XSIZE_OFST		16
+#define ADE_OVLY_BASE_COLOR(x)		(0x2074 + (x) * 8)
+#define ADE_OVLYX_CTL(x)		(0x209C + (x) * 4)
+#define ADE_OVLY_CTL			0x0098
+#define CH_OVLY_SEL_OFST(x)		((x) * 4)
+#define CH_OVLY_SEL_MASK		MASK(2)
+#define CH_OVLY_SEL_VAL(x)		((x) + 1)
+#define CH_ALP_MODE_OFST		0
+#define CH_ALP_SEL_OFST			2
+#define CH_UNDER_ALP_SEL_OFST		4
+#define CH_EN_OFST			6
+#define CH_ALP_GBL_OFST			15
+#define CH_SEL_OFST			28
+
+/*
+ * LDI Registers
+ */
+#define LDI_HRZ_CTRL0			0x7400
+#define HBP_OFST			20
+#define LDI_HRZ_CTRL1			0x7404
+#define LDI_VRT_CTRL0			0x7408
+#define VBP_OFST			20
+#define LDI_VRT_CTRL1			0x740C
+#define LDI_PLR_CTRL			0x7410
+#define FLAG_NVSYNC			BIT(0)
+#define FLAG_NHSYNC			BIT(1)
+#define FLAG_NPIXCLK			BIT(2)
+#define FLAG_NDE			BIT(3)
+#define LDI_DSP_SIZE			0x7414
+#define VSIZE_OFST			20
+#define LDI_INT_EN			0x741C
+#define FRAME_END_INT_EN_OFST		1
+#define LDI_CTRL			0x7420
+#define BPP_OFST			3
+#define DATA_GATE_EN			BIT(2)
+#define LDI_EN				BIT(0)
+#define LDI_ORG_INT			0x7424
+#define LDI_MSK_INT			0x7428
+#define LDI_INT_CLR			0x742C
+#define LDI_WORK_MODE			0x7430
+#define LDI_DE_SPACE_LOW		0x7438
+#define LDI_MCU_INTS			0x7450
+#define LDI_MCU_INTE			0x7454
+#define LDI_MCU_INTC			0x7458
+#define LDI_HDMI_DSI_GT			0x7434
+
+/*
+ * ADE media bus service regs
+ */
+#define ADE0_QOSGENERATOR_MODE		0x010C
+#define QOSGENERATOR_MODE_MASK		MASK(2)
+#define ADE0_QOSGENERATOR_EXTCONTROL	0x0118
+#define SOCKET_QOS_EN			BIT(0)
+#define ADE1_QOSGENERATOR_MODE		0x020C
+#define ADE1_QOSGENERATOR_EXTCONTROL	0x0218
+
+/*
+ * ADE regs relevant enums
+ */
+enum frame_end_start {
+	/* regs take effective in every vsync */
+	REG_EFFECTIVE_IN_VSYNC = 0,
+	/* regs take effective in fist ade en and every frame end */
+	REG_EFFECTIVE_IN_ADEEN_FRMEND,
+	/* regs take effective in ade en immediately */
+	REG_EFFECTIVE_IN_ADEEN,
+	/* regs take effective in first vsync and every frame end */
+	REG_EFFECTIVE_IN_VSYNC_FRMEND
+};
+
+enum ade_fb_format {
+	ADE_RGB_565 = 0,
+	ADE_BGR_565,
+	ADE_XRGB_8888,
+	ADE_XBGR_8888,
+	ADE_ARGB_8888,
+	ADE_ABGR_8888,
+	ADE_RGBA_8888,
+	ADE_BGRA_8888,
+	ADE_RGB_888,
+	ADE_BGR_888 = 9,
+	ADE_FORMAT_NOT_SUPPORT = 800
+};
+
+enum ade_channel {
+	ADE_CH1 = 0,	/* channel 1 for primary plane */
+	ADE_CH_NUM
+};
+
+enum ade_scale {
+	ADE_SCL1 = 0,
+	ADE_SCL2,
+	ADE_SCL3,
+	ADE_SCL_NUM
+};
+
+enum ade_ctran {
+	ADE_CTRAN1 = 0,
+	ADE_CTRAN2,
+	ADE_CTRAN3,
+	ADE_CTRAN4,
+	ADE_CTRAN5,
+	ADE_CTRAN6,
+	ADE_CTRAN_NUM
+};
+
+enum ade_overlay {
+	ADE_OVLY1 = 0,
+	ADE_OVLY2,
+	ADE_OVLY3,
+	ADE_OVLY_NUM
+};
+
+enum ade_alpha_mode {
+	ADE_ALP_GLOBAL = 0,
+	ADE_ALP_PIXEL,
+	ADE_ALP_PIXEL_AND_GLB
+};
+
+enum ade_alpha_blending_mode {
+	ADE_ALP_MUL_COEFF_0 = 0,	/* alpha */
+	ADE_ALP_MUL_COEFF_1,		/* 1-alpha */
+	ADE_ALP_MUL_COEFF_2,		/* 0 */
+	ADE_ALP_MUL_COEFF_3		/* 1 */
+};
+
+/*
+ * LDI regs relevant enums
+ */
+enum dsi_pclk_en {
+	DSI_PCLK_ON = 0,
+	DSI_PCLK_OFF
+};
+
+enum ldi_output_format {
+	LDI_OUT_RGB_565 = 0,
+	LDI_OUT_RGB_666,
+	LDI_OUT_RGB_888
+};
+
+enum ldi_work_mode {
+	TEST_MODE = 0,
+	NORMAL_MODE
+};
+
+enum ldi_input_source {
+	DISP_SRC_NONE = 0,
+	DISP_SRC_OVLY2,
+	DISP_SRC_DISP,
+	DISP_SRC_ROT,
+	DISP_SRC_SCL2
+};
+
+/*
+ * ADE media bus service relevant enums
+ */
+enum qos_generator_mode {
+	FIXED_MODE = 0,
+	LIMITER_MODE,
+	BYPASS_MODE,
+	REGULATOR_MODE
+};
+
+/*
+ * Register Write/Read Helper functions
+ */
+static inline void ade_update_bits(void __iomem *addr, u32 bit_start,
+				   u32 mask, u32 val)
+{
+	u32 tmp, orig;
+
+	orig = readl(addr);
+	tmp = orig & ~(mask << bit_start);
+	tmp |= (val & mask) << bit_start;
+	writel(tmp, addr);
+}
+
+#endif
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
new file mode 100644
index 000000000000..bb93616dcf3d
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -0,0 +1,452 @@
+/*
+ * Hisilicon Hi6220 SoC ADE(Advanced Display Engine)'s crtc&plane driver
+ *
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * Author:
+ *	Xinliang Liu <z.liuxinliang at hisilicon.com>
+ *	Xinliang Liu <xinliang.liu at linaro.org>
+ *	Xinwei Kong <kong.kongxinwei at hisilicon.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.
+ *
+ */
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <video/display_timing.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_crtc.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_atomic.h>
+#include <drm/drm_atomic_helper.h>
+
+#include "kirin_drm_drv.h"
+#include "kirin_ade_reg.h"
+
+#define to_ade_crtc(crtc) \
+	container_of(crtc, struct ade_crtc, base)
+
+struct ade_hw_ctx {
+	void __iomem  *base;
+	struct regmap *noc_regmap;
+	struct clk *ade_core_clk;
+	struct clk *media_noc_clk;
+	struct clk *ade_pix_clk;
+	struct reset_control *reset;
+	bool power_on;
+	int irq;
+};
+
+struct ade_crtc {
+	struct drm_crtc base;
+	struct ade_hw_ctx *ctx;
+	bool enable;
+	u32 out_format;
+};
+
+struct ade_data {
+	struct ade_crtc acrtc;
+	struct ade_hw_ctx ctx;
+};
+
+static void ade_update_reload_bit(void __iomem *base, u32 bit_num, u32 val)
+{
+	u32 bit_ofst, reg_num;
+
+	bit_ofst = bit_num % 32;
+	reg_num = bit_num / 32;
+
+	ade_update_bits(base + ADE_RELOAD_DIS(reg_num), bit_ofst,
+			MASK(1), !!val);
+}
+
+static u32 ade_read_reload_bit(void __iomem *base, u32 bit_num)
+{
+	u32 tmp, bit_ofst, reg_num;
+
+	bit_ofst = bit_num % 32;
+	reg_num = bit_num / 32;
+
+	tmp = readl(base + ADE_RELOAD_DIS(reg_num));
+	return !!(BIT(bit_ofst) & tmp);
+}
+
+static void ade_init(struct ade_hw_ctx *ctx)
+{
+	void __iomem *base = ctx->base;
+
+	/* enable clk gate */
+	ade_update_bits(base + ADE_CTRL1, AUTO_CLK_GATE_EN_OFST,
+			AUTO_CLK_GATE_EN, ADE_ENABLE);
+	/* clear overlay */
+	writel(0, base + ADE_OVLY1_TRANS_CFG);
+	writel(0, base + ADE_OVLY_CTL);
+	writel(0, base + ADE_OVLYX_CTL(ADE_OVLY2));
+	/* clear reset and reload regs */
+	writel(MASK(32), base + ADE_SOFT_RST_SEL(0));
+	writel(MASK(32), base + ADE_SOFT_RST_SEL(1));
+	writel(MASK(32), base + ADE_RELOAD_DIS(0));
+	writel(MASK(32), base + ADE_RELOAD_DIS(1));
+	/* for video mode, that ade registers
+	 * became effective at frame end
+	 */
+	ade_update_bits(base + ADE_CTRL, FRM_END_START_OFST,
+			FRM_END_START_MASK, REG_EFFECTIVE_IN_ADEEN_FRMEND);
+}
+
+static void ade_ldi_set_mode(struct ade_crtc *acrtc,
+			     struct drm_display_mode *mode,
+			     struct drm_display_mode *adj_mode)
+{
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->base;
+	u32 width = mode->hdisplay;
+	u32 height = mode->vdisplay;
+	u32 hfp, hbp, hsw, vfp, vbp, vsw;
+	u32 plr_flags;
+	int ret;
+
+	plr_flags = (mode->flags & DRM_MODE_FLAG_NVSYNC) ? FLAG_NVSYNC : 0;
+	plr_flags |= (mode->flags & DRM_MODE_FLAG_NHSYNC) ? FLAG_NHSYNC : 0;
+	hfp = mode->hsync_start - mode->hdisplay;
+	hbp = mode->htotal - mode->hsync_end;
+	hsw = mode->hsync_end - mode->hsync_start;
+	vfp = mode->vsync_start - mode->vdisplay;
+	vbp = mode->vtotal - mode->vsync_end;
+	vsw = mode->vsync_end - mode->vsync_start;
+	if (vsw > 15) {
+		DRM_DEBUG_DRIVER("vsw exceeded 15\n");
+		vsw = 15;
+	}
+
+	writel((hbp << HBP_OFST) | hfp, base + LDI_HRZ_CTRL0);
+	 /* the configured value is actual value - 1 */
+	writel(hsw - 1, base + LDI_HRZ_CTRL1);
+	writel((vbp << VBP_OFST) | vfp, base + LDI_VRT_CTRL0);
+	 /* the configured value is actual value - 1 */
+	writel(vsw - 1, base + LDI_VRT_CTRL1);
+	 /* the configured value is actual value - 1 */
+	writel(((height - 1) << VSIZE_OFST) | (width - 1),
+	       base + LDI_DSP_SIZE);
+	writel(plr_flags, base + LDI_PLR_CTRL);
+
+	/* Success should be guaranteed in mode_valid call back,
+	 * so failer shouldn't happen here
+	 */
+	ret = clk_set_rate(ctx->ade_pix_clk, mode->clock * 1000);
+	if (ret)
+		DRM_ERROR("failed to set pixel clk %dHz (%d)\n",
+			  mode->clock * 1000, ret);
+	adj_mode->clock = clk_get_rate(ctx->ade_pix_clk) / 1000;
+
+	/* ctran6 setting */
+	writel(CTRAN_BYPASS_ON, base + ADE_CTRAN_DIS(ADE_CTRAN6));
+	 /* the configured value is actual value - 1 */
+	writel(width * height - 1, base + ADE_CTRAN_IMAGE_SIZE(ADE_CTRAN6));
+	ade_update_reload_bit(base, CTRAN_OFST + ADE_CTRAN6, 0);
+
+	DRM_DEBUG_DRIVER("set mode: %dx%d\n", width, height);
+}
+
+static int ade_power_up(struct ade_hw_ctx *ctx)
+{
+	int ret;
+
+	ret = clk_prepare_enable(ctx->media_noc_clk);
+	if (ret) {
+		DRM_ERROR("failed to enable media_noc_clk (%d)\n", ret);
+		return ret;
+	}
+
+	ret = reset_control_deassert(ctx->reset);
+	if (ret) {
+		DRM_ERROR("failed to deassert reset\n");
+		return ret;
+	}
+
+	ret = clk_prepare_enable(ctx->ade_core_clk);
+	if (ret) {
+		DRM_ERROR("failed to enable ade_core_clk (%d)\n", ret);
+		return ret;
+	}
+
+	ade_init(ctx);
+	ctx->power_on = true;
+	return 0;
+}
+
+static void ade_power_down(struct ade_hw_ctx *ctx)
+{
+	void __iomem *base = ctx->base;
+
+	writel(ADE_DISABLE, base + LDI_CTRL);
+	/* dsi pixel off */
+	writel(DSI_PCLK_OFF, base + LDI_HDMI_DSI_GT);
+
+	clk_disable_unprepare(ctx->ade_core_clk);
+	reset_control_assert(ctx->reset);
+	clk_disable_unprepare(ctx->media_noc_clk);
+	ctx->power_on = false;
+}
+
+static void ade_set_medianoc_qos(struct ade_crtc *acrtc)
+{
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	struct regmap *map = ctx->noc_regmap;
+
+	regmap_update_bits(map, ADE0_QOSGENERATOR_MODE,
+			   QOSGENERATOR_MODE_MASK, BYPASS_MODE);
+	regmap_update_bits(map, ADE0_QOSGENERATOR_EXTCONTROL,
+			   SOCKET_QOS_EN, SOCKET_QOS_EN);
+
+	regmap_update_bits(map, ADE1_QOSGENERATOR_MODE,
+			   QOSGENERATOR_MODE_MASK, BYPASS_MODE);
+	regmap_update_bits(map, ADE1_QOSGENERATOR_EXTCONTROL,
+			   SOCKET_QOS_EN, SOCKET_QOS_EN);
+}
+
+static void ade_display_enable(struct ade_crtc *acrtc)
+{
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->base;
+	u32 out_fmt = acrtc->out_format;
+
+	/* display source setting */
+	writel(DISP_SRC_OVLY2, base + ADE_DISP_SRC_CFG);
+
+	/* enable ade */
+	writel(ADE_ENABLE, base + ADE_EN);
+	/* enable ldi */
+	writel(NORMAL_MODE, base + LDI_WORK_MODE);
+	writel((out_fmt << BPP_OFST) | DATA_GATE_EN | LDI_EN,
+	       base + LDI_CTRL);
+	/* dsi pixel on */
+	writel(DSI_PCLK_ON, base + LDI_HDMI_DSI_GT);
+}
+
+static void ade_crtc_enable(struct drm_crtc *crtc)
+{
+	struct ade_crtc *acrtc = to_ade_crtc(crtc);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	int ret;
+
+	if (acrtc->enable)
+		return;
+
+	if (!ctx->power_on) {
+		ret = ade_power_up(ctx);
+		if (ret)
+			return;
+	}
+
+	ade_set_medianoc_qos(acrtc);
+	ade_display_enable(acrtc);
+	acrtc->enable = true;
+}
+
+static void ade_crtc_disable(struct drm_crtc *crtc)
+{
+	struct ade_crtc *acrtc = to_ade_crtc(crtc);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+
+	if (!acrtc->enable)
+		return;
+
+	ade_power_down(ctx);
+	acrtc->enable = false;
+}
+
+static int ade_crtc_atomic_check(struct drm_crtc *crtc,
+				 struct drm_crtc_state *state)
+{
+	/* do nothing */
+	return 0;
+}
+
+static void ade_crtc_mode_set_nofb(struct drm_crtc *crtc)
+{
+	struct ade_crtc *acrtc = to_ade_crtc(crtc);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	struct drm_display_mode *mode = &crtc->state->mode;
+	struct drm_display_mode *adj_mode = &crtc->state->adjusted_mode;
+
+	if (!ctx->power_on)
+		(void)ade_power_up(ctx);
+	ade_ldi_set_mode(acrtc, mode, adj_mode);
+}
+
+static void ade_crtc_atomic_begin(struct drm_crtc *crtc,
+				  struct drm_crtc_state *old_state)
+{
+	struct ade_crtc *acrtc = to_ade_crtc(crtc);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+
+	if (!ctx->power_on)
+		(void)ade_power_up(ctx);
+}
+
+static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
+				  struct drm_crtc_state *old_state)
+
+{
+	struct ade_crtc *acrtc = to_ade_crtc(crtc);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->base;
+
+	/* only crtc is eanbled regs take effect */
+	if (acrtc->enable) {
+		/* flush ade regitsters */
+		writel(ADE_ENABLE, base + ADE_EN);
+	}
+}
+
+static const struct drm_crtc_helper_funcs ade_crtc_helper_funcs = {
+	.enable		= ade_crtc_enable,
+	.disable	= ade_crtc_disable,
+	.atomic_check	= ade_crtc_atomic_check,
+	.mode_set_nofb	= ade_crtc_mode_set_nofb,
+	.atomic_begin	= ade_crtc_atomic_begin,
+	.atomic_flush	= ade_crtc_atomic_flush,
+};
+
+static const struct drm_crtc_funcs ade_crtc_funcs = {
+	.destroy	= drm_crtc_cleanup,
+	.set_config	= drm_atomic_helper_set_config,
+	.page_flip	= drm_atomic_helper_page_flip,
+	.reset		= drm_atomic_helper_crtc_reset,
+	.set_property = drm_atomic_helper_crtc_set_property,
+	.atomic_duplicate_state	= drm_atomic_helper_crtc_duplicate_state,
+	.atomic_destroy_state	= drm_atomic_helper_crtc_destroy_state,
+};
+
+static int ade_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
+			 struct drm_plane *plane)
+{
+	struct kirin_drm_private *priv = dev->dev_private;
+	struct device_node *port;
+	int ret;
+
+	/* set crtc port so that
+	 * drm_of_find_possible_crtcs call works
+	 */
+	port = of_get_child_by_name(dev->dev->of_node, "port");
+	if (!port) {
+		DRM_ERROR("no port node found in %s\n",
+			  dev->dev->of_node->full_name);
+		return -EINVAL;
+	}
+	of_node_put(port);
+	crtc->port = port;
+
+	ret = drm_crtc_init_with_planes(dev, crtc, plane, NULL,
+					&ade_crtc_funcs, NULL);
+	if (ret) {
+		DRM_ERROR("failed to init crtc.\n");
+		return ret;
+	}
+
+	drm_crtc_helper_add(crtc, &ade_crtc_helper_funcs);
+	priv->crtc[drm_crtc_index(crtc)] = crtc;
+
+	return 0;
+}
+
+static int ade_dts_parse(struct platform_device *pdev, struct ade_hw_ctx *ctx)
+{
+	struct resource *res;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = pdev->dev.of_node;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	ctx->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(ctx->base)) {
+		DRM_ERROR("failed to remap ade io base\n");
+		return  PTR_ERR(ctx->base);
+	}
+
+	ctx->reset = devm_reset_control_get(dev, NULL);
+	if (IS_ERR(ctx->reset))
+		return PTR_ERR(ctx->reset);
+
+	ctx->noc_regmap =
+		syscon_regmap_lookup_by_phandle(np, "hisilicon,noc-syscon");
+	if (IS_ERR(ctx->noc_regmap)) {
+		DRM_ERROR("failed to get noc regmap\n");
+		return PTR_ERR(ctx->noc_regmap);
+	}
+
+	ctx->irq = platform_get_irq(pdev, 0);
+	if (ctx->irq < 0) {
+		DRM_ERROR("failed to get irq\n");
+		return -ENODEV;
+	}
+
+	ctx->ade_core_clk = devm_clk_get(dev, "clk_ade_core");
+	if (!ctx->ade_core_clk) {
+		DRM_ERROR("failed to parse clk ADE_CORE\n");
+		return -ENODEV;
+	}
+
+	ctx->media_noc_clk = devm_clk_get(dev, "clk_codec_jpeg");
+	if (!ctx->media_noc_clk) {
+		DRM_ERROR("failed to parse clk CODEC_JPEG\n");
+	    return -ENODEV;
+	}
+
+	ctx->ade_pix_clk = devm_clk_get(dev, "clk_ade_pix");
+	if (!ctx->ade_pix_clk) {
+		DRM_ERROR("failed to parse clk ADE_PIX\n");
+	    return -ENODEV;
+	}
+
+	return 0;
+}
+
+int ade_drm_init(struct drm_device *dev)
+{
+	struct platform_device *pdev = dev->platformdev;
+	struct ade_data *ade;
+	struct ade_hw_ctx *ctx;
+	struct ade_crtc *acrtc;
+	int ret;
+
+	ade = devm_kzalloc(dev->dev, sizeof(*ade), GFP_KERNEL);
+	if (!ade) {
+		DRM_ERROR("failed to alloc ade_data\n");
+		return -ENOMEM;
+	}
+	platform_set_drvdata(pdev, ade);
+
+	ctx = &ade->ctx;
+	acrtc = &ade->acrtc;
+	acrtc->ctx = ctx;
+	acrtc->out_format = LDI_OUT_RGB_888;
+
+	ret = ade_dts_parse(pdev, ctx);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+void ade_drm_cleanup(struct drm_device *dev)
+{
+	struct platform_device *pdev = dev->platformdev;
+	struct ade_data *ade = platform_get_drvdata(pdev);
+	struct drm_crtc *crtc = &ade->acrtc.base;
+
+	drm_crtc_cleanup(crtc);
+}
+
+const struct kirin_dc_ops ade_dc_ops = {
+	.init = ade_drm_init,
+	.cleanup = ade_drm_cleanup
+};
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 789ebd1f5922..055729c1889c 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -30,8 +30,12 @@ static struct kirin_dc_ops *dc_ops;
 
 static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
+	struct kirin_drm_private *priv = dev->dev_private;
+
 	dc_ops->cleanup(dev);
 	drm_mode_config_cleanup(dev);
+	devm_kfree(dev->dev, priv);
+	dev->dev_private = NULL;
 
 	return 0;
 }
@@ -55,8 +59,14 @@ static void kirin_drm_mode_config_init(struct drm_device *dev)
 
 static int kirin_drm_kms_init(struct drm_device *dev)
 {
+	struct kirin_drm_private *priv;
 	int ret;
 
+	priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	dev->dev_private = priv;
 	dev_set_drvdata(dev->dev, dev);
 
 	/* dev->mode_config initialization */
@@ -84,6 +94,8 @@ err_dc_cleanup:
 	dc_ops->cleanup(dev);
 err_mode_config_cleanup:
 	drm_mode_config_cleanup(dev);
+	devm_kfree(dev->dev, priv);
+	dev->dev_private = NULL;
 
 	return ret;
 }
@@ -221,6 +233,9 @@ static const struct component_master_ops kirin_drm_ops = {
 };
 
 static const struct of_device_id kirin_drm_dt_ids[] = {
+	{ .compatible = "hisilicon,hi6220-ade",
+	  .data = &ade_dc_ops,
+	},
 	{ /* end node */ },
 };
 MODULE_DEVICE_TABLE(of, kirin_drm_dt_ids);
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 75e9d82356d4..5a05ad6a81db 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -11,10 +11,18 @@
 #ifndef __KIRIN_DRM_DRV_H__
 #define __KIRIN_DRM_DRV_H__
 
+#define MAX_CRTC	2
+
 /* display controller init/cleanup ops */
 struct kirin_dc_ops {
 	int (*init)(struct drm_device *dev);
 	void (*cleanup)(struct drm_device *dev);
 };
 
+struct kirin_drm_private {
+	struct drm_crtc *crtc[MAX_CRTC];
+};
+
+extern const struct kirin_dc_ops ade_dc_ops;
+
 #endif /* __KIRIN_DRM_DRV_H__ */
-- 
2.7.1



From xinliang.liu at linaro.org  Fri Feb 26 00:40:21 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri, 26 Feb 2016 16:40:21 +0800
Subject: [PATCH v6 04/11] drm/hisilicon: Add plane driver for ADE
In-Reply-To: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
References: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456476028-36880-5-git-send-email-xinliang.liu@linaro.org>

Add plane funcs and helper funcs for ADE.

v6: None.
v5: None.
v4: None.
v3:
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 535 +++++++++++++++++++++++-
 1 file changed, 534 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index bb93616dcf3d..aa2cf75cab39 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -27,13 +27,23 @@
 #include <drm/drm_crtc_helper.h>
 #include <drm/drm_atomic.h>
 #include <drm/drm_atomic_helper.h>
+#include <drm/drm_plane_helper.h>
+#include <drm/drm_gem_cma_helper.h>
+#include <drm/drm_fb_cma_helper.h>
 
 #include "kirin_drm_drv.h"
 #include "kirin_ade_reg.h"
 
+#define PRIMARY_CH	ADE_CH1 /* primary plane */
+#define OUT_OVLY	ADE_OVLY2 /* output overlay compositor */
+#define ADE_DEBUG	1
+
 #define to_ade_crtc(crtc) \
 	container_of(crtc, struct ade_crtc, base)
 
+#define to_ade_plane(plane) \
+	container_of(plane, struct ade_plane, base)
+
 struct ade_hw_ctx {
 	void __iomem  *base;
 	struct regmap *noc_regmap;
@@ -52,11 +62,76 @@ struct ade_crtc {
 	u32 out_format;
 };
 
+struct ade_plane {
+	struct drm_plane base;
+	void *ctx;
+	u8 ch; /* channel */
+};
+
 struct ade_data {
 	struct ade_crtc acrtc;
+	struct ade_plane aplane[ADE_CH_NUM];
 	struct ade_hw_ctx ctx;
 };
 
+/* ade-format info: */
+struct ade_format {
+	u32 pixel_format;
+	enum ade_fb_format ade_format;
+};
+
+static const struct ade_format ade_formats[] = {
+	/* 16bpp RGB: */
+	{ DRM_FORMAT_RGB565, ADE_RGB_565 },
+	{ DRM_FORMAT_BGR565, ADE_BGR_565 },
+	/* 24bpp RGB: */
+	{ DRM_FORMAT_RGB888, ADE_RGB_888 },
+	{ DRM_FORMAT_BGR888, ADE_BGR_888 },
+	/* 32bpp [A]RGB: */
+	{ DRM_FORMAT_XRGB8888, ADE_XRGB_8888 },
+	{ DRM_FORMAT_XBGR8888, ADE_XBGR_8888 },
+	{ DRM_FORMAT_RGBA8888, ADE_RGBA_8888 },
+	{ DRM_FORMAT_BGRA8888, ADE_BGRA_8888 },
+	{ DRM_FORMAT_ARGB8888, ADE_ARGB_8888 },
+	{ DRM_FORMAT_ABGR8888, ADE_ABGR_8888 },
+};
+
+static const u32 channel_formats1[] = {
+	/* channel 1,2,3,4 */
+	DRM_FORMAT_RGB565, DRM_FORMAT_BGR565, DRM_FORMAT_RGB888,
+	DRM_FORMAT_BGR888, DRM_FORMAT_XRGB8888, DRM_FORMAT_XBGR8888,
+	DRM_FORMAT_RGBA8888, DRM_FORMAT_BGRA8888, DRM_FORMAT_ARGB8888,
+	DRM_FORMAT_ABGR8888
+};
+
+u32 ade_get_channel_formats(u8 ch, const u32 **formats)
+{
+	switch (ch) {
+	case ADE_CH1:
+		*formats = channel_formats1;
+		return ARRAY_SIZE(channel_formats1);
+	default:
+		DRM_ERROR("no this channel %d\n", ch);
+		*formats = NULL;
+		return 0;
+	}
+}
+
+/* convert from fourcc format to ade format */
+static u32 ade_get_format(u32 pixel_format)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(ade_formats); i++)
+		if (ade_formats[i].pixel_format == pixel_format)
+			return ade_formats[i].ade_format;
+
+	/* not found */
+	DRM_ERROR("Not found pixel format!!fourcc_format= %d\n",
+		  pixel_format);
+	return ADE_FORMAT_NOT_SUPPORT;
+}
+
 static void ade_update_reload_bit(void __iomem *base, u32 bit_num, u32 val)
 {
 	u32 bit_ofst, reg_num;
@@ -89,7 +164,7 @@ static void ade_init(struct ade_hw_ctx *ctx)
 	/* clear overlay */
 	writel(0, base + ADE_OVLY1_TRANS_CFG);
 	writel(0, base + ADE_OVLY_CTL);
-	writel(0, base + ADE_OVLYX_CTL(ADE_OVLY2));
+	writel(0, base + ADE_OVLYX_CTL(OUT_OVLY));
 	/* clear reset and reload regs */
 	writel(MASK(32), base + ADE_SOFT_RST_SEL(0));
 	writel(MASK(32), base + ADE_SOFT_RST_SEL(1));
@@ -147,6 +222,10 @@ static void ade_ldi_set_mode(struct ade_crtc *acrtc,
 			  mode->clock * 1000, ret);
 	adj_mode->clock = clk_get_rate(ctx->ade_pix_clk) / 1000;
 
+	/* set overlay compositor output size */
+	writel(((width - 1) << OUTPUT_XSIZE_OFST) | (height - 1),
+	       base + ADE_OVLY_OUTPUT_SIZE(OUT_OVLY));
+
 	/* ctran6 setting */
 	writel(CTRAN_BYPASS_ON, base + ADE_CTRAN_DIS(ADE_CTRAN6));
 	 /* the configured value is actual value - 1 */
@@ -219,6 +298,10 @@ static void ade_display_enable(struct ade_crtc *acrtc)
 	void __iomem *base = ctx->base;
 	u32 out_fmt = acrtc->out_format;
 
+	/* enable output overlay compositor */
+	writel(ADE_ENABLE, base + ADE_OVLYX_CTL(OUT_OVLY));
+	ade_update_reload_bit(base, OVLY_OFST + OUT_OVLY, 0);
+
 	/* display source setting */
 	writel(DISP_SRC_OVLY2, base + ADE_DISP_SRC_CFG);
 
@@ -232,6 +315,97 @@ static void ade_display_enable(struct ade_crtc *acrtc)
 	writel(DSI_PCLK_ON, base + LDI_HDMI_DSI_GT);
 }
 
+#if ADE_DEBUG
+static void ade_rdma_dump_regs(void __iomem *base, u32 ch)
+{
+	u32 reg_ctrl, reg_addr, reg_size, reg_stride, reg_space, reg_en;
+	u32 val;
+
+	reg_ctrl = RD_CH_CTRL(ch);
+	reg_addr = RD_CH_ADDR(ch);
+	reg_size = RD_CH_SIZE(ch);
+	reg_stride = RD_CH_STRIDE(ch);
+	reg_space = RD_CH_SPACE(ch);
+	reg_en = RD_CH_EN(ch);
+
+	val = ade_read_reload_bit(base, RDMA_OFST + ch);
+	DRM_DEBUG_DRIVER("[rdma%d]: reload(%d)\n", ch + 1, val);
+	val = readl(base + reg_ctrl);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_ctrl(0x%08x)\n", ch + 1, val);
+	val = readl(base + reg_addr);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_addr(0x%08x)\n", ch + 1, val);
+	val = readl(base + reg_size);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_size(0x%08x)\n", ch + 1, val);
+	val = readl(base + reg_stride);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_stride(0x%08x)\n", ch + 1, val);
+	val = readl(base + reg_space);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_space(0x%08x)\n", ch + 1, val);
+	val = readl(base + reg_en);
+	DRM_DEBUG_DRIVER("[rdma%d]: reg_en(0x%08x)\n", ch + 1, val);
+}
+
+static void ade_clip_dump_regs(void __iomem *base, u32 ch)
+{
+	u32 val;
+
+	val = ade_read_reload_bit(base, CLIP_OFST + ch);
+	DRM_DEBUG_DRIVER("[clip%d]: reload(%d)\n", ch + 1, val);
+	val = readl(base + ADE_CLIP_DISABLE(ch));
+	DRM_DEBUG_DRIVER("[clip%d]: reg_clip_disable(0x%08x)\n", ch + 1, val);
+	val = readl(base + ADE_CLIP_SIZE0(ch));
+	DRM_DEBUG_DRIVER("[clip%d]: reg_clip_size0(0x%08x)\n", ch + 1, val);
+	val = readl(base + ADE_CLIP_SIZE1(ch));
+	DRM_DEBUG_DRIVER("[clip%d]: reg_clip_size1(0x%08x)\n", ch + 1, val);
+}
+
+static void ade_compositor_routing_dump_regs(void __iomem *base, u32 ch)
+{
+	u8 ovly_ch = 0; /* TODO: Only primary plane now */
+	u32 val;
+
+	val = readl(base + ADE_OVLY_CH_XY0(ovly_ch));
+	DRM_DEBUG_DRIVER("[overlay ch%d]: reg_ch_xy0(0x%08x)\n", ovly_ch, val);
+	val = readl(base + ADE_OVLY_CH_XY1(ovly_ch));
+	DRM_DEBUG_DRIVER("[overlay ch%d]: reg_ch_xy1(0x%08x)\n", ovly_ch, val);
+	val = readl(base + ADE_OVLY_CH_CTL(ovly_ch));
+	DRM_DEBUG_DRIVER("[overlay ch%d]: reg_ch_ctl(0x%08x)\n", ovly_ch, val);
+}
+
+static void ade_dump_overlay_compositor_regs(void __iomem *base, u32 comp)
+{
+	u32 val;
+
+	val = ade_read_reload_bit(base, OVLY_OFST + comp);
+	DRM_DEBUG_DRIVER("[overlay%d]: reload(%d)\n", comp + 1, val);
+	writel(ADE_ENABLE, base + ADE_OVLYX_CTL(comp));
+	DRM_DEBUG_DRIVER("[overlay%d]: reg_ctl(0x%08x)\n", comp + 1, val);
+	val = readl(base + ADE_OVLY_CTL);
+	DRM_DEBUG_DRIVER("ovly_ctl(0x%08x)\n", val);
+}
+
+static void ade_dump_regs(void __iomem *base)
+{
+	u32 i;
+
+	/* dump channel regs */
+	for (i = 0; i < ADE_CH_NUM; i++) {
+		/* dump rdma regs */
+		ade_rdma_dump_regs(base, i);
+
+		/* dump clip regs */
+		ade_clip_dump_regs(base, i);
+
+		/* dump compositor routing regs */
+		ade_compositor_routing_dump_regs(base, i);
+	}
+
+	/* dump overlay compositor regs */
+	ade_dump_overlay_compositor_regs(base, OUT_OVLY);
+}
+#else
+static void ade_dump_regs(void __iomem *base) { }
+#endif
+
 static void ade_crtc_enable(struct drm_crtc *crtc)
 {
 	struct ade_crtc *acrtc = to_ade_crtc(crtc);
@@ -249,6 +423,7 @@ static void ade_crtc_enable(struct drm_crtc *crtc)
 
 	ade_set_medianoc_qos(acrtc);
 	ade_display_enable(acrtc);
+	ade_dump_regs(ctx->base);
 	acrtc->enable = true;
 }
 
@@ -303,6 +478,7 @@ static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
 
 	/* only crtc is eanbled regs take effect */
 	if (acrtc->enable) {
+		ade_dump_regs(base);
 		/* flush ade regitsters */
 		writel(ADE_ENABLE, base + ADE_EN);
 	}
@@ -359,6 +535,338 @@ static int ade_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
 	return 0;
 }
 
+static void ade_rdma_set(void __iomem *base, struct drm_framebuffer *fb,
+			 u32 ch, u32 y, u32 in_h, u32 fmt)
+{
+	struct drm_gem_cma_object *obj = drm_fb_cma_get_gem_obj(fb, 0);
+	u32 reg_ctrl, reg_addr, reg_size, reg_stride, reg_space, reg_en;
+	u32 stride = fb->pitches[0];
+	u32 addr = (u32)obj->paddr + y * stride;
+
+	DRM_DEBUG_DRIVER("rdma%d: (y=%d, height=%d), stride=%d, paddr=0x%x\n",
+			 ch + 1, y, in_h, stride, (u32)obj->paddr);
+	DRM_DEBUG_DRIVER("addr=0x%x, fb:%dx%d, pixel_format=%d(%s)\n",
+			 addr, fb->width, fb->height, fmt,
+			 drm_get_format_name(fb->pixel_format));
+
+	/* get reg offset */
+	reg_ctrl = RD_CH_CTRL(ch);
+	reg_addr = RD_CH_ADDR(ch);
+	reg_size = RD_CH_SIZE(ch);
+	reg_stride = RD_CH_STRIDE(ch);
+	reg_space = RD_CH_SPACE(ch);
+	reg_en = RD_CH_EN(ch);
+
+	/*
+	 * TODO: set rotation
+	 */
+	writel((fmt << 16) & 0x1f0000, base + reg_ctrl);
+	writel(addr, base + reg_addr);
+	writel((in_h << 16) | stride, base + reg_size);
+	writel(stride, base + reg_stride);
+	writel(in_h * stride, base + reg_space);
+	writel(ADE_ENABLE, base + reg_en);
+	ade_update_reload_bit(base, RDMA_OFST + ch, 0);
+}
+
+static void ade_rdma_disable(void __iomem *base, u32 ch)
+{
+	u32 reg_en;
+
+	/* get reg offset */
+	reg_en = RD_CH_EN(ch);
+	writel(0, base + reg_en);
+	ade_update_reload_bit(base, RDMA_OFST + ch, 1);
+}
+
+static void ade_clip_set(void __iomem *base, u32 ch, u32 fb_w, u32 x,
+			 u32 in_w, u32 in_h)
+{
+	u32 disable_val;
+	u32 clip_left;
+	u32 clip_right;
+
+	/*
+	 * clip width, no need to clip height
+	 */
+	if (fb_w == in_w) { /* bypass */
+		disable_val = 1;
+		clip_left = 0;
+		clip_right = 0;
+	} else {
+		disable_val = 0;
+		clip_left = x;
+		clip_right = fb_w - (x + in_w) - 1;
+	}
+
+	DRM_DEBUG_DRIVER("clip%d: clip_left=%d, clip_right=%d\n",
+			 ch + 1, clip_left, clip_right);
+
+	writel(disable_val, base + ADE_CLIP_DISABLE(ch));
+	writel((fb_w - 1) << 16 | (in_h - 1), base + ADE_CLIP_SIZE0(ch));
+	writel(clip_left << 16 | clip_right, base + ADE_CLIP_SIZE1(ch));
+	ade_update_reload_bit(base, CLIP_OFST + ch, 0);
+}
+
+static void ade_clip_disable(void __iomem *base, u32 ch)
+{
+	writel(1, base + ADE_CLIP_DISABLE(ch));
+	ade_update_reload_bit(base, CLIP_OFST + ch, 1);
+}
+
+static bool has_Alpha_channel(int format)
+{
+	switch (format) {
+	case ADE_ARGB_8888:
+	case ADE_ABGR_8888:
+	case ADE_RGBA_8888:
+	case ADE_BGRA_8888:
+		return true;
+	default:
+		return false;
+	}
+}
+
+static void ade_get_blending_params(u32 fmt, u8 glb_alpha, u8 *alp_mode,
+				    u8 *alp_sel, u8 *under_alp_sel)
+{
+	bool has_alpha = has_Alpha_channel(fmt);
+
+	/*
+	 * get alp_mode
+	 */
+	if (has_alpha && glb_alpha < 255)
+		*alp_mode = ADE_ALP_PIXEL_AND_GLB;
+	else if (has_alpha)
+		*alp_mode = ADE_ALP_PIXEL;
+	else
+		*alp_mode = ADE_ALP_GLOBAL;
+
+	/*
+	 * get alp sel
+	 */
+	*alp_sel = ADE_ALP_MUL_COEFF_3; /* 1 */
+	*under_alp_sel = ADE_ALP_MUL_COEFF_2; /* 0 */
+}
+
+static void ade_compositor_routing_set(void __iomem *base, u8 ch,
+				       u32 x0, u32 y0,
+				       u32 in_w, u32 in_h, u32 fmt)
+{
+	u8 ovly_ch = 0; /* TODO: This is the zpos, only one plane now */
+	u8 glb_alpha = 255;
+	u32 x1 = x0 + in_w - 1;
+	u32 y1 = y0 + in_h - 1;
+	u32 val;
+	u8 alp_sel;
+	u8 under_alp_sel;
+	u8 alp_mode;
+
+	ade_get_blending_params(fmt, glb_alpha, &alp_mode, &alp_sel,
+				&under_alp_sel);
+
+	/* overlay routing setting
+	 */
+	writel(x0 << 16 | y0, base + ADE_OVLY_CH_XY0(ovly_ch));
+	writel(x1 << 16 | y1, base + ADE_OVLY_CH_XY1(ovly_ch));
+	val = (ch + 1) << CH_SEL_OFST | BIT(CH_EN_OFST) |
+		alp_sel << CH_ALP_SEL_OFST |
+		under_alp_sel << CH_UNDER_ALP_SEL_OFST |
+		glb_alpha << CH_ALP_GBL_OFST |
+		alp_mode << CH_ALP_MODE_OFST;
+	writel(val, base + ADE_OVLY_CH_CTL(ovly_ch));
+	/* connect this plane/channel to overlay2 compositor */
+	ade_update_bits(base + ADE_OVLY_CTL, CH_OVLY_SEL_OFST(ovly_ch),
+			CH_OVLY_SEL_MASK, CH_OVLY_SEL_VAL(OUT_OVLY));
+}
+
+static void ade_compositor_routing_disable(void __iomem *base, u32 ch)
+{
+	u8 ovly_ch = 0; /* TODO: Only primary plane now */
+
+	/* disable this plane/channel */
+	ade_update_bits(base + ADE_OVLY_CH_CTL(ovly_ch), CH_EN_OFST,
+			MASK(1), 0);
+	/* dis-connect this plane/channel of overlay2 compositor */
+	ade_update_bits(base + ADE_OVLY_CTL, CH_OVLY_SEL_OFST(ovly_ch),
+			CH_OVLY_SEL_MASK, 0);
+}
+
+/*
+ * Typicaly, a channel looks like: DMA-->clip-->scale-->ctrans-->compositor
+ */
+static void ade_update_channel(struct ade_plane *aplane,
+			       struct drm_framebuffer *fb, int crtc_x,
+			       int crtc_y, unsigned int crtc_w,
+			       unsigned int crtc_h, u32 src_x,
+			       u32 src_y, u32 src_w, u32 src_h)
+{
+	struct ade_hw_ctx *ctx = aplane->ctx;
+	void __iomem *base = ctx->base;
+	u32 fmt = ade_get_format(fb->pixel_format);
+	u32 ch = aplane->ch;
+	u32 in_w;
+	u32 in_h;
+
+	DRM_DEBUG_DRIVER("channel%d: src:(%d, %d)-%dx%d, crtc:(%d, %d)-%dx%d",
+			 ch + 1, src_x, src_y, src_w, src_h,
+			 crtc_x, crtc_y, crtc_w, crtc_h);
+
+	/* 1) DMA setting */
+	in_w = src_w;
+	in_h = src_h;
+	ade_rdma_set(base, fb, ch, src_y, in_h, fmt);
+
+	/* 2) clip setting */
+	ade_clip_set(base, ch, fb->width, src_x, in_w, in_h);
+
+	/* 3) TODO: scale setting for overlay planes */
+
+	/* 4) TODO: ctran/csc setting for overlay planes */
+
+	/* 5) compositor routing setting */
+	ade_compositor_routing_set(base, ch, crtc_x, crtc_y, in_w, in_h, fmt);
+}
+
+static void ade_disable_channel(struct ade_plane *aplane)
+{
+	struct ade_hw_ctx *ctx = aplane->ctx;
+	void __iomem *base = ctx->base;
+	u32 ch = aplane->ch;
+
+	DRM_DEBUG_DRIVER("disable channel%d\n", ch + 1);
+
+	/* disable read DMA */
+	ade_rdma_disable(base, ch);
+
+	/* disable clip */
+	ade_clip_disable(base, ch);
+
+	/* disable compositor routing */
+	ade_compositor_routing_disable(base, ch);
+}
+
+static int ade_plane_prepare_fb(struct drm_plane *plane,
+				const struct drm_plane_state *new_state)
+{
+	/* do nothing */
+	return 0;
+}
+
+static void ade_plane_cleanup_fb(struct drm_plane *plane,
+				 const struct drm_plane_state *old_state)
+{
+	/* do nothing */
+}
+
+static int ade_plane_atomic_check(struct drm_plane *plane,
+				  struct drm_plane_state *state)
+{
+	struct drm_framebuffer *fb = state->fb;
+	struct drm_crtc *crtc = state->crtc;
+	struct drm_crtc_state *crtc_state;
+	u32 src_x = state->src_x >> 16;
+	u32 src_y = state->src_y >> 16;
+	u32 src_w = state->src_w >> 16;
+	u32 src_h = state->src_h >> 16;
+	int crtc_x = state->crtc_x;
+	int crtc_y = state->crtc_y;
+	u32 crtc_w = state->crtc_w;
+	u32 crtc_h = state->crtc_h;
+	u32 fmt;
+
+	if (!crtc || !fb)
+		return 0;
+
+	fmt = ade_get_format(fb->pixel_format);
+	if (fmt == ADE_FORMAT_NOT_SUPPORT)
+		return -EINVAL;
+
+	crtc_state = drm_atomic_get_crtc_state(state->state, crtc);
+	if (IS_ERR(crtc_state))
+		return PTR_ERR(crtc_state);
+
+	if (src_w != crtc_w || src_h != crtc_h) {
+		DRM_ERROR("Scale not support!!!\n");
+		return -EINVAL;
+	}
+
+	if (src_x + src_w > fb->width ||
+	    src_y + src_h > fb->height)
+		return -EINVAL;
+
+	if (crtc_x < 0 || crtc_y < 0)
+		return -EINVAL;
+
+	if (crtc_x + crtc_w > crtc_state->adjusted_mode.hdisplay ||
+	    crtc_y + crtc_h > crtc_state->adjusted_mode.vdisplay)
+		return -EINVAL;
+
+	return 0;
+}
+
+static void ade_plane_atomic_update(struct drm_plane *plane,
+				    struct drm_plane_state *old_state)
+{
+	struct drm_plane_state	*state	= plane->state;
+	struct ade_plane *aplane = to_ade_plane(plane);
+
+	ade_update_channel(aplane, state->fb, state->crtc_x, state->crtc_y,
+			   state->crtc_w, state->crtc_h,
+			   state->src_x >> 16, state->src_y >> 16,
+			   state->src_w >> 16, state->src_h >> 16);
+}
+
+static void ade_plane_atomic_disable(struct drm_plane *plane,
+				     struct drm_plane_state *old_state)
+{
+	struct ade_plane *aplane = to_ade_plane(plane);
+
+	ade_disable_channel(aplane);
+}
+
+static const struct drm_plane_helper_funcs ade_plane_helper_funcs = {
+	.prepare_fb = ade_plane_prepare_fb,
+	.cleanup_fb = ade_plane_cleanup_fb,
+	.atomic_check = ade_plane_atomic_check,
+	.atomic_update = ade_plane_atomic_update,
+	.atomic_disable = ade_plane_atomic_disable,
+};
+
+static struct drm_plane_funcs ade_plane_funcs = {
+	.update_plane	= drm_atomic_helper_update_plane,
+	.disable_plane	= drm_atomic_helper_disable_plane,
+	.set_property = drm_atomic_helper_plane_set_property,
+	.destroy = drm_plane_cleanup,
+	.reset = drm_atomic_helper_plane_reset,
+	.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
+	.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
+};
+
+static int ade_plane_init(struct drm_device *dev, struct ade_plane *aplane,
+			  enum drm_plane_type type)
+{
+	const u32 *fmts;
+	u32 fmts_cnt;
+	int ret = 0;
+
+	/* get  properties */
+	fmts_cnt = ade_get_channel_formats(aplane->ch, &fmts);
+	if (ret)
+		return ret;
+
+	ret = drm_universal_plane_init(dev, &aplane->base, 1, &ade_plane_funcs,
+				       fmts, fmts_cnt, type, NULL);
+	if (ret) {
+		DRM_ERROR("fail to init plane, ch=%d\n", aplane->ch);
+		return ret;
+	}
+
+	drm_plane_helper_add(&aplane->base, &ade_plane_helper_funcs);
+
+	return 0;
+}
+
 static int ade_dts_parse(struct platform_device *pdev, struct ade_hw_ctx *ctx)
 {
 	struct resource *res;
@@ -416,7 +924,10 @@ int ade_drm_init(struct drm_device *dev)
 	struct ade_data *ade;
 	struct ade_hw_ctx *ctx;
 	struct ade_crtc *acrtc;
+	struct ade_plane *aplane;
+	enum drm_plane_type type;
 	int ret;
+	int i;
 
 	ade = devm_kzalloc(dev->dev, sizeof(*ade), GFP_KERNEL);
 	if (!ade) {
@@ -434,6 +945,28 @@ int ade_drm_init(struct drm_device *dev)
 	if (ret)
 		return ret;
 
+	/*
+	 * plane init
+	 * TODO: Now only support primary plane, overlay planes
+	 * need to do.
+	 */
+	for (i = 0; i < ADE_CH_NUM; i++) {
+		aplane = &ade->aplane[i];
+		aplane->ch = i;
+		aplane->ctx = ctx;
+		type = i == PRIMARY_CH ? DRM_PLANE_TYPE_PRIMARY :
+			DRM_PLANE_TYPE_OVERLAY;
+
+		ret = ade_plane_init(dev, aplane, type);
+		if (ret)
+			return ret;
+	}
+
+	/* crtc init */
+	ret = ade_crtc_init(dev, &acrtc->base, &ade->aplane[PRIMARY_CH].base);
+	if (ret)
+		return ret;
+
 	return 0;
 }
 
-- 
2.7.1



From xinliang.liu at linaro.org  Fri Feb 26 00:40:22 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri, 26 Feb 2016 16:40:22 +0800
Subject: [PATCH v6 05/11] drm/hisilicon: Add vblank driver for ADE
In-Reply-To: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
References: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456476028-36880-6-git-send-email-xinliang.liu@linaro.org>

Add vblank irq handle.

v6: None.
v5: None.
v4: None.
v3:
- Remove hisi_get_crtc_from_index func.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 62 +++++++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 14 +++++-
 2 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index aa2cf75cab39..749382952ab7 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -292,6 +292,59 @@ static void ade_set_medianoc_qos(struct ade_crtc *acrtc)
 			   SOCKET_QOS_EN, SOCKET_QOS_EN);
 }
 
+static int ade_enable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+	struct kirin_drm_private *priv = dev->dev_private;
+	struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->base;
+
+	if (!ctx->power_on)
+		(void)ade_power_up(ctx);
+
+	ade_update_bits(base + LDI_INT_EN, FRAME_END_INT_EN_OFST,
+			MASK(1), 1);
+
+	return 0;
+}
+
+static void ade_disable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+	struct kirin_drm_private *priv = dev->dev_private;
+	struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	void __iomem *base = ctx->base;
+
+	if (!ctx->power_on) {
+		DRM_ERROR("power is down! vblank disable fail\n");
+		return;
+	}
+
+	ade_update_bits(base + LDI_INT_EN, FRAME_END_INT_EN_OFST,
+			MASK(1), 0);
+}
+
+static irqreturn_t ade_irq_handler(int irq, void *data)
+{
+	struct ade_crtc *acrtc = data;
+	struct ade_hw_ctx *ctx = acrtc->ctx;
+	struct drm_crtc *crtc = &acrtc->base;
+	void __iomem *base = ctx->base;
+	u32 status;
+
+	status = readl(base + LDI_MSK_INT);
+	DRM_DEBUG_VBL("LDI IRQ: status=0x%X\n", status);
+
+	/* vblank irq */
+	if (status & BIT(FRAME_END_INT_EN_OFST)) {
+		ade_update_bits(base + LDI_INT_CLR, FRAME_END_INT_EN_OFST,
+				MASK(1), 1);
+		drm_crtc_handle_vblank(crtc);
+	}
+
+	return IRQ_HANDLED;
+}
+
 static void ade_display_enable(struct ade_crtc *acrtc)
 {
 	struct ade_hw_ctx *ctx = acrtc->ctx;
@@ -967,6 +1020,15 @@ int ade_drm_init(struct drm_device *dev)
 	if (ret)
 		return ret;
 
+	/* vblank irq init */
+	ret = devm_request_irq(dev->dev, ctx->irq, ade_irq_handler,
+			       DRIVER_IRQ_SHARED, dev->driver->name, acrtc);
+	if (ret)
+		return ret;
+	dev->driver->get_vblank_counter = drm_vblank_no_hw_counter;
+	dev->driver->enable_vblank = ade_enable_vblank;
+	dev->driver->disable_vblank = ade_disable_vblank;
+
 	return 0;
 }
 
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 055729c1889c..723888feb760 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -32,6 +32,7 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
 	struct kirin_drm_private *priv = dev->dev_private;
 
+	drm_vblank_cleanup(dev);
 	dc_ops->cleanup(dev);
 	drm_mode_config_cleanup(dev);
 	devm_kfree(dev->dev, priv);
@@ -85,11 +86,22 @@ static int kirin_drm_kms_init(struct drm_device *dev)
 		goto err_dc_cleanup;
 	}
 
+	/* vblank init */
+	ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
+	if (ret) {
+		DRM_ERROR("failed to initialize vblank.\n");
+		goto err_unbind_all;
+	}
+	/* with irq_enabled = true, we can use the vblank feature. */
+	dev->irq_enabled = true;
+
 	/* reset all the states of crtc/plane/encoder/connector */
 	drm_mode_config_reset(dev);
 
 	return 0;
 
+err_unbind_all:
+	component_unbind_all(dev->dev, dev);
 err_dc_cleanup:
 	dc_ops->cleanup(dev);
 err_mode_config_cleanup:
@@ -123,7 +135,7 @@ static int kirin_gem_cma_dumb_create(struct drm_file *file,
 
 static struct drm_driver kirin_drm_driver = {
 	.driver_features	= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
-				  DRIVER_ATOMIC,
+				  DRIVER_ATOMIC | DRIVER_HAVE_IRQ,
 	.fops			= &kirin_drm_fops,
 	.set_busid		= drm_platform_set_busid,
 
-- 
2.7.1



From xinliang.liu at linaro.org  Fri Feb 26 00:40:23 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri, 26 Feb 2016 16:40:23 +0800
Subject: [PATCH v6 06/11] drm/hisilicon: Add cma fbdev and hotplug
In-Reply-To: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
References: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456476028-36880-7-git-send-email-xinliang.liu@linaro.org>

Add cma Fbdev, Fbdev is legency and optional, you can enable/disable it by
configuring DRM_FBDEV_EMULATION.
Add hotplug.

v6: None.
v5: None.
v4: None.
v3: None.
v2:
- Use CONFIG_DRM_FBDEV_EMULATION instead of CONFIG_DRM_HISI_FBDEV.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 34 +++++++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  3 +++
 2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 723888feb760..d57b9fa0ce3e 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -23,6 +23,7 @@
 #include <drm/drm_gem_cma_helper.h>
 #include <drm/drm_fb_cma_helper.h>
 #include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc_helper.h>
 
 #include "kirin_drm_drv.h"
 
@@ -32,6 +33,13 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
 	struct kirin_drm_private *priv = dev->dev_private;
 
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+	if (priv->fbdev) {
+		drm_fbdev_cma_fini(priv->fbdev);
+		priv->fbdev = NULL;
+	}
+#endif
+	drm_kms_helper_poll_fini(dev);
 	drm_vblank_cleanup(dev);
 	dc_ops->cleanup(dev);
 	drm_mode_config_cleanup(dev);
@@ -41,8 +49,28 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 	return 0;
 }
 
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+static void kirin_fbdev_output_poll_changed(struct drm_device *dev)
+{
+	struct kirin_drm_private *priv = dev->dev_private;
+
+	if (priv->fbdev) {
+		drm_fbdev_cma_hotplug_event(priv->fbdev);
+	} else {
+		priv->fbdev = drm_fbdev_cma_init(dev, 32,
+				dev->mode_config.num_crtc,
+				dev->mode_config.num_connector);
+		if (IS_ERR(priv->fbdev))
+			priv->fbdev = NULL;
+	}
+}
+#endif
+
 static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
 	.fb_create = drm_fb_cma_create,
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+	.output_poll_changed = kirin_fbdev_output_poll_changed,
+#endif
 	.atomic_check = drm_atomic_helper_check,
 	.atomic_commit = drm_atomic_helper_commit,
 };
@@ -98,6 +126,12 @@ static int kirin_drm_kms_init(struct drm_device *dev)
 	/* reset all the states of crtc/plane/encoder/connector */
 	drm_mode_config_reset(dev);
 
+	/* init kms poll for handling hpd */
+	drm_kms_helper_poll_init(dev);
+
+	/* force detection after connectors init */
+	(void)drm_helper_hpd_irq_event(dev);
+
 	return 0;
 
 err_unbind_all:
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 5a05ad6a81db..1a07caf8e7f4 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -21,6 +21,9 @@ struct kirin_dc_ops {
 
 struct kirin_drm_private {
 	struct drm_crtc *crtc[MAX_CRTC];
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+	struct drm_fbdev_cma *fbdev;
+#endif
 };
 
 extern const struct kirin_dc_ops ade_dc_ops;
-- 
2.7.1



From xinliang.liu at linaro.org  Fri Feb 26 00:40:24 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri, 26 Feb 2016 16:40:24 +0800
Subject: [PATCH v6 07/11] drm/hisilicon: Add designware dsi encoder driver
In-Reply-To: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
References: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456476028-36880-8-git-send-email-xinliang.liu@linaro.org>

Add DesignWare MIPI DSI Host Controller v1.02 encoder driver
for hi6220 SoC.

v6:
- Change "pclk_dsi" to "pclk".
v5: None.
v4: None.
v3:
- Rename file name to dw_drm_dsi.c
- Make encoder type as DRM_MODE_ENCODER_DSI.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
Signed-off-by: Xinwei Kong <kong.kongxinwei at hisilicon.com>
Signed-off-by: Andy Green <andy.green at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/Kconfig      |   1 +
 drivers/gpu/drm/hisilicon/kirin/Makefile     |   3 +-
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 743 +++++++++++++++++++++++++++
 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h |  83 +++
 4 files changed, 829 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h

diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig b/drivers/gpu/drm/hisilicon/kirin/Kconfig
index 3ac4b8edeac1..de0d454c5c13 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Kconfig
+++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
@@ -4,6 +4,7 @@ config DRM_HISI_KIRIN
 	select DRM_KMS_HELPER
 	select DRM_GEM_CMA_HELPER
 	select DRM_KMS_CMA_HELPER
+	select DRM_MIPI_DSI
 	help
 	  Choose this option if you have a hisilicon Kirin chipsets(hi6220).
 	  If M is selected the module will be called kirin-drm.
diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile b/drivers/gpu/drm/hisilicon/kirin/Makefile
index 2a61ab006ddb..5dcd0d4328b6 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Makefile
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -1,4 +1,5 @@
 kirin-drm-y := kirin_drm_drv.o \
-	       kirin_drm_ade.o
+	       kirin_drm_ade.o \
+	       dw_drm_dsi.o
 
 obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
new file mode 100644
index 000000000000..8329148cc89d
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -0,0 +1,743 @@
+/*
+ * DesignWare MIPI DSI Host Controller v1.02 driver
+ *
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * Author:
+ *	Xinliang Liu <z.liuxinliang at hisilicon.com>
+ *	Xinliang Liu <xinliang.liu at linaro.org>
+ *	Xinwei Kong <kong.kongxinwei at hisilicon.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.
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/component.h>
+#include <linux/of_graph.h>
+
+#include <drm/drm_of.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_encoder_slave.h>
+#include <drm/drm_atomic_helper.h>
+
+#include "dw_dsi_reg.h"
+
+#define MAX_TX_ESC_CLK		   (10)
+#define ROUND(x, y) ((x) / (y) + ((x) % (y) * 10 / (y) >= 5 ? 1 : 0))
+#define PHY_REF_CLK_RATE   19200000
+#define PHY_REF_CLK_PERIOD_PS (1000000000 / (PHY_REF_CLK_RATE / 1000))
+
+#define encoder_to_dsi(encoder) \
+	container_of(encoder, struct dw_dsi, encoder)
+#define host_to_dsi(host) \
+	container_of(host, struct dw_dsi, host)
+
+struct mipi_phy_params {
+	u32 clk_t_lpx;
+	u32 clk_t_hs_prepare;
+	u32 clk_t_hs_zero;
+	u32 clk_t_hs_trial;
+	u32 clk_t_wakeup;
+	u32 data_t_lpx;
+	u32 data_t_hs_prepare;
+	u32 data_t_hs_zero;
+	u32 data_t_hs_trial;
+	u32 data_t_ta_go;
+	u32 data_t_ta_get;
+	u32 data_t_wakeup;
+	u32 hstx_ckg_sel;
+	u32 pll_fbd_div5f;
+	u32 pll_fbd_div1f;
+	u32 pll_fbd_2p;
+	u32 pll_enbwt;
+	u32 pll_fbd_p;
+	u32 pll_fbd_s;
+	u32 pll_pre_div1p;
+	u32 pll_pre_p;
+	u32 pll_vco_750M;
+	u32 pll_lpf_rs;
+	u32 pll_lpf_cs;
+	u32 clklp2hs_time;
+	u32 clkhs2lp_time;
+	u32 lp2hs_time;
+	u32 hs2lp_time;
+	u32 clk_to_data_delay;
+	u32 data_to_clk_delay;
+	u32 lane_byte_clk_kHz;
+	u32 clk_division;
+};
+
+struct dsi_hw_ctx {
+	void __iomem *base;
+	struct clk *pclk;
+};
+
+struct dw_dsi {
+	struct drm_encoder encoder;
+	struct drm_display_mode cur_mode;
+	struct dsi_hw_ctx *ctx;
+	struct mipi_phy_params phy;
+
+	u32 lanes;
+	enum mipi_dsi_pixel_format format;
+	unsigned long mode_flags;
+	bool enable;
+};
+
+struct dsi_data {
+	struct dw_dsi dsi;
+	struct dsi_hw_ctx ctx;
+};
+
+struct dsi_phy_range {
+	u32 min_range_kHz;
+	u32 max_range_kHz;
+	u32 pll_vco_750M;
+	u32 hstx_ckg_sel;
+};
+
+static const struct dsi_phy_range dphy_range_info[] = {
+	{   46875,    62500,   1,    7 },
+	{   62500,    93750,   0,    7 },
+	{   93750,   125000,   1,    6 },
+	{  125000,   187500,   0,    6 },
+	{  187500,   250000,   1,    5 },
+	{  250000,   375000,   0,    5 },
+	{  375000,   500000,   1,    4 },
+	{  500000,   750000,   0,    4 },
+	{  750000,  1000000,   1,    0 },
+	{ 1000000,  1500000,   0,    0 }
+};
+
+static void dsi_get_phy_params(u32 phy_freq_kHz,
+			       struct mipi_phy_params *phy)
+{
+	u32 ui = 0;
+	u32 cfg_clk_ps = PHY_REF_CLK_PERIOD_PS;
+	u32 i = 0;
+	u32 q_pll = 1;
+	u32 m_pll = 0;
+	u32 n_pll = 0;
+	u32 r_pll = 1;
+	u32 m_n = 0;
+	u32 m_n_int = 0;
+	u64 f_kHz;
+	u64 temp;
+	u64 tmp_kHz = phy_freq_kHz;
+
+	do {
+		f_kHz = tmp_kHz;
+
+		/* Find the PLL clock range from the table */
+		for (i = 0; i < ARRAY_SIZE(dphy_range_info); i++)
+			if (f_kHz >= dphy_range_info[i].min_range_kHz &&
+			    f_kHz <= dphy_range_info[i].max_range_kHz)
+				break;
+
+		if (i == ARRAY_SIZE(dphy_range_info)) {
+			DRM_ERROR("%lldkHz out of range\n", f_kHz);
+			return;
+		}
+
+		phy->pll_vco_750M = dphy_range_info[i].pll_vco_750M;
+		phy->hstx_ckg_sel = dphy_range_info[i].hstx_ckg_sel;
+
+		if (phy->hstx_ckg_sel <= 7 &&
+		    phy->hstx_ckg_sel >= 4)
+			q_pll = 0x10 >> (7 - phy->hstx_ckg_sel);
+
+		temp = f_kHz * (u64)q_pll * (u64)cfg_clk_ps;
+		m_n_int = temp / (u64)1000000000;
+		m_n = (temp % (u64)1000000000) / (u64)100000000;
+
+		if (m_n_int % 2 == 0) {
+			if (m_n * 6 >= 50) {
+				n_pll = 2;
+				m_pll = (m_n_int + 1) * n_pll;
+			} else if (m_n * 6 >= 30) {
+				n_pll = 3;
+				m_pll = m_n_int * n_pll + 2;
+			} else {
+				n_pll = 1;
+				m_pll = m_n_int * n_pll;
+			}
+		} else {
+			if (m_n * 6 >= 50) {
+				n_pll = 1;
+				m_pll = (m_n_int + 1) * n_pll;
+			} else if (m_n * 6 >= 30) {
+				n_pll = 1;
+				m_pll = (m_n_int + 1) * n_pll;
+			} else if (m_n * 6 >= 10) {
+				n_pll = 3;
+				m_pll = m_n_int * n_pll + 1;
+			} else {
+				n_pll = 2;
+				m_pll = m_n_int * n_pll;
+			}
+		}
+
+		if (n_pll == 1) {
+			phy->pll_fbd_p = 0;
+			phy->pll_pre_div1p = 1;
+		} else {
+			phy->pll_fbd_p = n_pll;
+			phy->pll_pre_div1p = 0;
+		}
+
+		if (phy->pll_fbd_2p <= 7 && phy->pll_fbd_2p >= 4)
+			r_pll = 0x10 >> (7 - phy->pll_fbd_2p);
+
+		if (m_pll == 2) {
+			phy->pll_pre_p = 0;
+			phy->pll_fbd_s = 0;
+			phy->pll_fbd_div1f = 0;
+			phy->pll_fbd_div5f = 1;
+		} else if (m_pll >= 2 * 2 * r_pll && m_pll <= 2 * 4 * r_pll) {
+			phy->pll_pre_p = m_pll / (2 * r_pll);
+			phy->pll_fbd_s = 0;
+			phy->pll_fbd_div1f = 1;
+			phy->pll_fbd_div5f = 0;
+		} else if (m_pll >= 2 * 5 * r_pll && m_pll <= 2 * 150 * r_pll) {
+			if (((m_pll / (2 * r_pll)) % 2) == 0) {
+				phy->pll_pre_p =
+					(m_pll / (2 * r_pll)) / 2 - 1;
+				phy->pll_fbd_s =
+					(m_pll / (2 * r_pll)) % 2 + 2;
+			} else {
+				phy->pll_pre_p =
+					(m_pll / (2 * r_pll)) / 2;
+				phy->pll_fbd_s =
+					(m_pll / (2 * r_pll)) % 2;
+			}
+			phy->pll_fbd_div1f = 0;
+			phy->pll_fbd_div5f = 0;
+		} else {
+			phy->pll_pre_p = 0;
+			phy->pll_fbd_s = 0;
+			phy->pll_fbd_div1f = 0;
+			phy->pll_fbd_div5f = 1;
+		}
+
+		f_kHz = (u64)1000000000 * (u64)m_pll /
+			((u64)cfg_clk_ps * (u64)n_pll * (u64)q_pll);
+
+		if (f_kHz >= phy_freq_kHz)
+			break;
+
+		tmp_kHz += 10;
+
+	} while (1);
+
+	ui = 1000000 / f_kHz;
+
+	phy->clk_t_lpx = ROUND(50, 8 * ui);
+	phy->clk_t_hs_prepare = ROUND(133, 16 * ui) - 1;
+
+	phy->clk_t_hs_zero = ROUND(262, 8 * ui);
+	phy->clk_t_hs_trial = 2 * (ROUND(60, 8 * ui) - 1);
+	phy->clk_t_wakeup = ROUND(1000000, (cfg_clk_ps / 1000) - 1);
+	if (phy->clk_t_wakeup > 0xff)
+		phy->clk_t_wakeup = 0xff;
+	phy->data_t_wakeup = phy->clk_t_wakeup;
+	phy->data_t_lpx = phy->clk_t_lpx;
+	phy->data_t_hs_prepare = ROUND(125 + 10 * ui, 16 * ui) - 1;
+	phy->data_t_hs_zero = ROUND(105 + 6 * ui, 8 * ui);
+	phy->data_t_hs_trial = 2 * (ROUND(60 + 4 * ui, 8 * ui) - 1);
+	phy->data_t_ta_go = 3;
+	phy->data_t_ta_get = 4;
+
+	phy->pll_enbwt = 1;
+	phy->clklp2hs_time = ROUND(407, 8 * ui) + 12;
+	phy->clkhs2lp_time = ROUND(105 + 12 * ui, 8 * ui);
+	phy->lp2hs_time = ROUND(240 + 12 * ui, 8 * ui) + 1;
+	phy->hs2lp_time = phy->clkhs2lp_time;
+	phy->clk_to_data_delay = 1 + phy->clklp2hs_time;
+	phy->data_to_clk_delay = ROUND(60 + 52 * ui, 8 * ui) +
+				phy->clkhs2lp_time;
+
+	phy->lane_byte_clk_kHz = f_kHz / 8;
+	phy->clk_division = phy->lane_byte_clk_kHz / MAX_TX_ESC_CLK;
+	if (phy->lane_byte_clk_kHz % MAX_TX_ESC_CLK)
+		phy->clk_division++;
+}
+
+static u32 dsi_get_dpi_color_coding(enum mipi_dsi_pixel_format format)
+{
+	u32 val;
+
+	/* TODO: only support RGB888 now, to support more */
+	switch (format) {
+	case MIPI_DSI_FMT_RGB888:
+		val = DSI_24BITS_1;
+		break;
+	default:
+		val = DSI_24BITS_1;
+		break;
+	}
+
+	return val;
+}
+
+/*
+ * dsi phy reg write function
+ */
+static void dsi_phy_tst_set(void __iomem *base, u32 reg, u32 val)
+{
+	writel(reg, base + PHY_TST_CTRL1);
+	/* reg addr written at first */
+	wmb();
+	writel(0x02, base + PHY_TST_CTRL0);
+	/* cmd1 sent for write */
+	wmb();
+	writel(0x00, base + PHY_TST_CTRL0);
+	/* cmd2 sent for write */
+	wmb();
+	writel(val, base + PHY_TST_CTRL1);
+	/* Then write data */
+	wmb();
+	writel(0x02, base + PHY_TST_CTRL0);
+	/* cmd2 sent for write */
+	wmb();
+	writel(0x00, base + PHY_TST_CTRL0);
+}
+
+static void dsi_set_mipi_phy(void __iomem *base,
+			     struct mipi_phy_params *phy,
+			     u32 lanes)
+{
+	u32 delay_count;
+	u32 val;
+	u32 i;
+
+	/* set lanes value */
+	val = (lanes - 1) | (PHY_STOP_WAIT_TIME << 8);
+	writel(val, base + PHY_IF_CFG);
+
+	/* set phy clk division */
+	val = readl(base + CLKMGR_CFG) | phy->clk_division;
+	writel(val, base + CLKMGR_CFG);
+
+	/* clean up phy set param */
+	writel(0, base + PHY_RSTZ);
+	writel(0, base + PHY_TST_CTRL0);
+	writel(1, base + PHY_TST_CTRL0);
+	writel(0, base + PHY_TST_CTRL0);
+
+	/* clock lane Timing control - TLPX */
+	dsi_phy_tst_set(base, 0x10010, phy->clk_t_lpx);
+
+	/* clock lane Timing control - THS-PREPARE */
+	dsi_phy_tst_set(base, 0x10011, phy->clk_t_hs_prepare);
+
+	/* clock lane Timing control - THS-ZERO */
+	dsi_phy_tst_set(base, 0x10012, phy->clk_t_hs_zero);
+
+	/* clock lane Timing control - THS-TRAIL */
+	dsi_phy_tst_set(base, 0x10013, phy->clk_t_hs_trial);
+
+	/* clock lane Timing control - TWAKEUP */
+	dsi_phy_tst_set(base, 0x10014, phy->clk_t_wakeup);
+
+	/* data lane */
+	for (i = 0; i < lanes; i++) {
+		/* Timing control - TLPX */
+		dsi_phy_tst_set(base, 0x10020 + (i << 4), phy->data_t_lpx);
+
+		/* Timing control - THS-PREPARE */
+		dsi_phy_tst_set(base, 0x10021 + (i << 4),
+				phy->data_t_hs_prepare);
+
+		/* Timing control - THS-ZERO */
+		dsi_phy_tst_set(base, 0x10022 + (i << 4), phy->data_t_hs_zero);
+
+		/* Timing control - THS-TRAIL */
+		dsi_phy_tst_set(base, 0x10023 + (i << 4), phy->data_t_hs_trial);
+
+		/* Timing control - TTA-GO */
+		dsi_phy_tst_set(base, 0x10024 + (i << 4), phy->data_t_ta_go);
+
+		/* Timing control - TTA-GET */
+		dsi_phy_tst_set(base, 0x10025 + (i << 4), phy->data_t_ta_get);
+
+		/* Timing control - TWAKEUP */
+		dsi_phy_tst_set(base, 0x10026 + (i << 4), phy->data_t_wakeup);
+	}
+
+	/* physical configuration I */
+	dsi_phy_tst_set(base, 0x10060, phy->hstx_ckg_sel);
+
+	/* physical configuration pll II */
+	val = (phy->pll_fbd_div5f << 5) + (phy->pll_fbd_div1f << 4) +
+				(phy->pll_fbd_2p << 1) + phy->pll_enbwt;
+	dsi_phy_tst_set(base, 0x10063, val);
+
+	/* physical configuration pll II */
+	dsi_phy_tst_set(base, 0x10064, phy->pll_fbd_p);
+
+	/* physical configuration pll III */
+	dsi_phy_tst_set(base, 0x10065, phy->pll_fbd_s);
+
+	/* physical configuration pll IV */
+	val = (phy->pll_pre_div1p << 7) + phy->pll_pre_p;
+	dsi_phy_tst_set(base, 0x10066, val);
+
+	/* physical configuration pll V */
+	val = (phy->pll_vco_750M << 4) + (phy->pll_lpf_rs << 2) +
+					phy->pll_lpf_cs + BIT(5);
+	dsi_phy_tst_set(base, 0x10067, val);
+
+	writel(BIT(2), base + PHY_RSTZ);
+	udelay(1);
+	writel(BIT(2) | BIT(0), base + PHY_RSTZ);
+	udelay(1);
+	writel(BIT(2) | BIT(1) | BIT(0), base + PHY_RSTZ);
+	usleep_range(1000, 1500);
+
+	/* wait for phy's clock ready */
+	delay_count = 100;
+	while (delay_count--) {
+		val = readl(base +  PHY_STATUS);
+		if ((BIT(0) | BIT(2)) & val)
+			break;
+
+		udelay(1);
+	}
+
+	if (!delay_count)
+		DRM_INFO("phylock and phystopstateclklane is not ready.\n");
+
+	/* set lp and hs switching params
+	 */
+	dw_update_bits(base + PHY_TMR_CFG, 24, MASK(8), phy->hs2lp_time);
+	dw_update_bits(base + PHY_TMR_CFG, 16, MASK(8), phy->lp2hs_time);
+	dw_update_bits(base + PHY_TMR_LPCLK_CFG, 16, MASK(10),
+		       phy->clkhs2lp_time);
+	dw_update_bits(base + PHY_TMR_LPCLK_CFG, 0, MASK(10),
+		       phy->clklp2hs_time);
+	dw_update_bits(base + CLK_DATA_TMR_CFG, 8, MASK(8),
+		       phy->data_to_clk_delay);
+	dw_update_bits(base + CLK_DATA_TMR_CFG, 0, MASK(8),
+		       phy->clk_to_data_delay);
+}
+
+static void dsi_set_mode_timing(void __iomem *base,
+				u32 lane_byte_clk_kHz,
+				struct drm_display_mode *mode,
+				enum mipi_dsi_pixel_format format)
+{
+	u32 hfp, hbp, hsw, vfp, vbp, vsw;
+	u32 hline_time;
+	u32 hsa_time;
+	u32 hbp_time;
+	u32 pixel_clk_kHz;
+	int htot, vtot;
+	u32 val;
+	u64 tmp;
+
+	/* DSI color coding setting */
+	val = dsi_get_dpi_color_coding(format);
+	writel(val, base + DPI_COLOR_CODING);
+
+	/* DSI format and pol setting */
+	val = (mode->flags & DRM_MODE_FLAG_NHSYNC ? 1 : 0) << 2;
+	val |= (mode->flags & DRM_MODE_FLAG_NVSYNC ? 1 : 0) << 1;
+	writel(val, base +  DPI_CFG_POL);
+
+	/*
+	 * The DSI IP accepts vertical timing using lines as normal,
+	 * but horizontal timing is a mixture of pixel-clocks for the
+	 * active region and byte-lane clocks for the blanking-related
+	 * timings.  hfp is specified as the total hline_time in byte-
+	 * lane clocks minus hsa, hbp and active.
+	 */
+	pixel_clk_kHz = mode->clock;
+	htot = mode->htotal;
+	vtot = mode->vtotal;
+	hfp = mode->hsync_start - mode->hdisplay;
+	hbp = mode->htotal - mode->hsync_end;
+	hsw = mode->hsync_end - mode->hsync_start;
+	vfp = mode->vsync_start - mode->vdisplay;
+	vbp = mode->vtotal - mode->vsync_end;
+	vsw = mode->vsync_end - mode->vsync_start;
+	if (vsw > 15) {
+		DRM_DEBUG_DRIVER("vsw exceeded 15\n");
+		vsw = 15;
+	}
+
+	hsa_time = (hsw * lane_byte_clk_kHz) / pixel_clk_kHz;
+	hbp_time = (hbp * lane_byte_clk_kHz) / pixel_clk_kHz;
+	tmp = (u64)htot * (u64)lane_byte_clk_kHz;
+	hline_time = DIV_ROUND_UP(tmp, pixel_clk_kHz);
+
+	/* all specified in byte-lane clocks */
+	writel(hsa_time, base + VID_HSA_TIME);
+	writel(hbp_time, base + VID_HBP_TIME);
+	writel(hline_time, base + VID_HLINE_TIME);
+
+	writel(vsw, base + VID_VSA_LINES);
+	writel(vbp, base + VID_VBP_LINES);
+	writel(vfp, base + VID_VFP_LINES);
+	writel(mode->vdisplay, base + VID_VACTIVE_LINES);
+	writel(mode->hdisplay, base + VID_PKT_SIZE);
+
+	DRM_DEBUG_DRIVER("htot=%d, hfp=%d, hbp=%d, hsw=%d\n",
+			 htot, hfp, hbp, hsw);
+	DRM_DEBUG_DRIVER("vtol=%d, vfp=%d, vbp=%d, vsw=%d\n",
+			 vtot, vfp, vbp, vsw);
+	DRM_DEBUG_DRIVER("hsa_time=%d, hbp_time=%d, hline_time=%d\n",
+			 hsa_time, hbp_time, hline_time);
+}
+
+static void dsi_set_video_mode_type(void __iomem *base,
+				    unsigned long flags)
+{
+	u32 val;
+	u32 mode_mask = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+		MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
+	u32 non_burst_sync_pulse = MIPI_DSI_MODE_VIDEO |
+		MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
+	u32 non_burst_sync_event = MIPI_DSI_MODE_VIDEO;
+
+	/*
+	 * choose video type
+	 */
+	if ((flags & mode_mask) == non_burst_sync_pulse)
+		val = DSI_NON_BURST_SYNC_PULSES;
+	else if ((flags & mode_mask) == non_burst_sync_event)
+		val = DSI_NON_BURST_SYNC_EVENTS;
+	else
+		val = DSI_BURST_SYNC_PULSES_1;
+
+	writel(val, base + VID_MODE_CFG);
+}
+
+static void dsi_mipi_init(struct dw_dsi *dsi)
+{
+	struct dsi_hw_ctx *ctx = dsi->ctx;
+	struct mipi_phy_params *phy = &dsi->phy;
+	struct drm_display_mode *mode = &dsi->cur_mode;
+	u32 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
+	void __iomem *base = ctx->base;
+	u32 dphy_freq_kHz;
+
+	/* count phy params */
+	dphy_freq_kHz = mode->clock * bpp / dsi->lanes;
+	dsi_get_phy_params(dphy_freq_kHz, phy);
+
+	/* reset Core */
+	writel(0, base + PWR_UP);
+
+	/* set phy params */
+	dsi_set_mipi_phy(base, phy, dsi->lanes);
+
+	/* set dsi mode */
+	dsi_set_mode_timing(base, phy->lane_byte_clk_kHz, mode, dsi->format);
+
+	/* set video mode type and lp */
+	dsi_set_video_mode_type(base, dsi->mode_flags);
+
+	/* dsi wake up */
+	writel(DSI_VIDEO_MODE, base + MODE_CFG);
+	writel(BIT(0), base + LPCLK_CTRL);
+	writel(BIT(0), base + PWR_UP);
+
+	DRM_DEBUG_DRIVER("lanes=%d, pixel_clk=%d kHz, bytes_freq=%d kHz\n",
+			 dsi->lanes, mode->clock, phy->lane_byte_clk_kHz);
+}
+
+static void dsi_encoder_disable(struct drm_encoder *encoder)
+{
+	struct dw_dsi *dsi = encoder_to_dsi(encoder);
+	struct dsi_hw_ctx *ctx = dsi->ctx;
+	void __iomem *base = ctx->base;
+
+	if (!dsi->enable)
+		return;
+
+	writel(0, base + PWR_UP);
+	writel(0, base + LPCLK_CTRL);
+	writel(0, base + PHY_RSTZ);
+	clk_disable_unprepare(ctx->pclk);
+
+	dsi->enable = false;
+}
+
+static void dsi_encoder_enable(struct drm_encoder *encoder)
+{
+	struct dw_dsi *dsi = encoder_to_dsi(encoder);
+	struct dsi_hw_ctx *ctx = dsi->ctx;
+	int ret;
+
+	if (dsi->enable)
+		return;
+
+	/* mipi dphy clock enable */
+	ret = clk_prepare_enable(ctx->pclk);
+	if (ret) {
+		DRM_ERROR("fail to enable pclk: %d\n", ret);
+		return;
+	}
+
+	dsi_mipi_init(dsi);
+
+	dsi->enable = true;
+}
+
+static void dsi_encoder_mode_set(struct drm_encoder *encoder,
+				 struct drm_display_mode *mode,
+				 struct drm_display_mode *adj_mode)
+{
+	struct dw_dsi *dsi = encoder_to_dsi(encoder);
+
+	drm_mode_copy(&dsi->cur_mode, adj_mode);
+}
+
+static int dsi_encoder_atomic_check(struct drm_encoder *encoder,
+				    struct drm_crtc_state *crtc_state,
+				    struct drm_connector_state *conn_state)
+{
+	/* do nothing */
+	return 0;
+}
+
+static const struct drm_encoder_helper_funcs dw_encoder_helper_funcs = {
+	.atomic_check	= dsi_encoder_atomic_check,
+	.mode_set	= dsi_encoder_mode_set,
+	.enable		= dsi_encoder_enable,
+	.disable	= dsi_encoder_disable
+};
+
+static const struct drm_encoder_funcs dw_encoder_funcs = {
+	.destroy = drm_encoder_cleanup,
+};
+
+static int dw_drm_encoder_init(struct device *dev,
+			       struct drm_device *drm_dev,
+			       struct drm_encoder *encoder)
+{
+	int ret;
+	u32 crtc_mask = drm_of_find_possible_crtcs(drm_dev, dev->of_node);
+
+	if (!crtc_mask) {
+		DRM_ERROR("failed to find crtc mask\n");
+		return -EINVAL;
+	}
+
+	encoder->possible_crtcs = crtc_mask;
+	ret = drm_encoder_init(drm_dev, encoder, &dw_encoder_funcs,
+			       DRM_MODE_ENCODER_DSI, NULL);
+	if (ret) {
+		DRM_ERROR("failed to init dsi encoder\n");
+		return ret;
+	}
+
+	drm_encoder_helper_add(encoder, &dw_encoder_helper_funcs);
+
+	return 0;
+}
+
+static int dsi_bind(struct device *dev, struct device *master, void *data)
+{
+	struct dsi_data *ddata = dev_get_drvdata(dev);
+	struct dw_dsi *dsi = &ddata->dsi;
+	struct drm_device *drm_dev = data;
+	int ret;
+
+	ret = dw_drm_encoder_init(dev, drm_dev, &dsi->encoder);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static void dsi_unbind(struct device *dev, struct device *master, void *data)
+{
+	/* do nothing */
+}
+
+static const struct component_ops dsi_ops = {
+	.bind	= dsi_bind,
+	.unbind	= dsi_unbind,
+};
+
+static int dsi_parse_dt(struct platform_device *pdev, struct dw_dsi *dsi)
+{
+	struct dsi_hw_ctx *ctx = dsi->ctx;
+	struct resource *res;
+
+	ctx->pclk = devm_clk_get(&pdev->dev, "pclk");
+	if (IS_ERR(ctx->pclk)) {
+		DRM_ERROR("failed to get pclk clock\n");
+		return PTR_ERR(ctx->pclk);
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	ctx->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(ctx->base)) {
+		DRM_ERROR("failed to remap dsi io region\n");
+		return PTR_ERR(ctx->base);
+	}
+
+	return 0;
+}
+
+static int dsi_probe(struct platform_device *pdev)
+{
+	struct dsi_data *data;
+	struct dw_dsi *dsi;
+	struct dsi_hw_ctx *ctx;
+	int ret;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data) {
+		DRM_ERROR("failed to allocate dsi data.\n");
+		return -ENOMEM;
+	}
+	dsi = &data->dsi;
+	ctx = &data->ctx;
+	dsi->ctx = ctx;
+
+	ret = dsi_parse_dt(pdev, dsi);
+	if (ret)
+		return ret;
+
+	platform_set_drvdata(pdev, data);
+
+	return component_add(&pdev->dev, &dsi_ops);
+}
+
+static int dsi_remove(struct platform_device *pdev)
+{
+	component_del(&pdev->dev, &dsi_ops);
+
+	return 0;
+}
+
+static const struct of_device_id dsi_of_match[] = {
+	{.compatible = "hisilicon,hi6220-dsi"},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, dsi_of_match);
+
+static struct platform_driver dsi_driver = {
+	.probe = dsi_probe,
+	.remove = dsi_remove,
+	.driver = {
+		.name = "dw-dsi",
+		.of_match_table = dsi_of_match,
+	},
+};
+
+module_platform_driver(dsi_driver);
+
+MODULE_AUTHOR("Xinliang Liu <xinliang.liu at linaro.org>");
+MODULE_AUTHOR("Xinliang Liu <z.liuxinliang at hisilicon.com>");
+MODULE_AUTHOR("Xinwei Kong <kong.kongxinwei at hisilicon.com>");
+MODULE_DESCRIPTION("DesignWare MIPI DSI Host Controller v1.02 driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h b/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
new file mode 100644
index 000000000000..d3d44b7d2098
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
@@ -0,0 +1,83 @@
+/*
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * 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.
+ *
+ */
+
+#ifndef __DW_DSI_REG_H__
+#define __DW_DSI_REG_H__
+
+#define MASK(x)				(BIT(x) - 1)
+
+/*
+ * regs
+ */
+#define  PWR_UP                  0x04  /* Core power-up */
+#define  PHY_IF_CFG              0xA4  /* D-PHY interface configuration */
+#define  CLKMGR_CFG              0x08  /* the internal clock dividers */
+#define  PHY_RSTZ                0xA0  /* D-PHY reset control */
+#define  PHY_TST_CTRL0           0xB4  /* D-PHY test interface control 0 */
+#define  PHY_TST_CTRL1           0xB8  /* D-PHY test interface control 1 */
+#define  DPI_VCID                0x0C  /* DPI virtual channel id */
+#define  DPI_COLOR_CODING        0x10  /* DPI color coding */
+#define  DPI_CFG_POL             0x14  /* DPI polarity configuration */
+#define  VID_HSA_TIME            0x48  /* Horizontal Sync Active time */
+#define  VID_HBP_TIME            0x4C  /* Horizontal Back Porch time */
+#define  VID_HLINE_TIME          0x50  /* Line time */
+#define  VID_VSA_LINES           0x54  /* Vertical Sync Active period */
+#define  VID_VBP_LINES           0x58  /* Vertical Back Porch period */
+#define  VID_VFP_LINES           0x5C  /* Vertical Front Porch period */
+#define  VID_VACTIVE_LINES       0x60  /* Vertical resolution */
+#define  VID_PKT_SIZE            0x3C  /* Video packet size */
+#define  VID_MODE_CFG            0x38  /* Video mode configuration */
+#define  DPI_LP_CMD_TIM          0x18  /* Low-power command timing config */
+#define  PHY_TMR_CFG             0x9C  /* Data lanes timing configuration */
+#define  BTA_TO_CNT              0x8C  /* Response timeout definition */
+#define  PHY_TMR_LPCLK_CFG       0x98  /* clock lane timing configuration */
+#define  CLK_DATA_TMR_CFG        0xCC
+#define  LPCLK_CTRL              0x94  /* Low-power in clock lane */
+#define  PCKHDL_CFG              0x2C  /* Packet handler configuration */
+#define  EDPI_CMD_SIZE           0x64  /* Size for eDPI packets */
+#define  MODE_CFG                0x34  /* Video or Command mode selection */
+#define  PHY_STATUS              0xB0  /* D-PHY PPI status interface */
+
+#define	PHY_STOP_WAIT_TIME       0x30
+
+/*
+ * regs relevant enum
+ */
+enum dpi_color_coding {
+	DSI_24BITS_1 = 5,
+};
+
+enum dsi_video_mode_type {
+	DSI_NON_BURST_SYNC_PULSES = 0,
+	DSI_NON_BURST_SYNC_EVENTS,
+	DSI_BURST_SYNC_PULSES_1,
+	DSI_BURST_SYNC_PULSES_2
+};
+
+enum dsi_work_mode {
+	DSI_VIDEO_MODE = 0,
+	DSI_COMMAND_MODE
+};
+
+/*
+ * Register Write/Read Helper functions
+ */
+static inline void dw_update_bits(void __iomem *addr, u32 bit_start,
+				  u32 mask, u32 val)
+{
+	u32 tmp, orig;
+
+	orig = readl(addr);
+	tmp = orig & ~(mask << bit_start);
+	tmp |= (val & mask) << bit_start;
+	writel(tmp, addr);
+}
+
+#endif /* __DW_DRM_DSI_H__ */
-- 
2.7.1



From xinliang.liu at linaro.org  Fri Feb 26 00:40:25 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri, 26 Feb 2016 16:40:25 +0800
Subject: [PATCH v6 08/11] drm/hisilicon: Add designware dsi host driver
In-Reply-To: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
References: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456476028-36880-9-git-send-email-xinliang.liu@linaro.org>

Add DesignWare dsi host driver for hi6220 SoC.

v6: None.
v5: None.
v4: None.
v3: None.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 50 ++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index 8329148cc89d..f15798b61451 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -79,6 +79,7 @@ struct dsi_hw_ctx {
 
 struct dw_dsi {
 	struct drm_encoder encoder;
+	struct mipi_dsi_host host;
 	struct drm_display_mode cur_mode;
 	struct dsi_hw_ctx *ctx;
 	struct mipi_phy_params phy;
@@ -642,6 +643,51 @@ static int dw_drm_encoder_init(struct device *dev,
 	return 0;
 }
 
+static int dsi_host_attach(struct mipi_dsi_host *host,
+			   struct mipi_dsi_device *mdsi)
+{
+	struct dw_dsi *dsi = host_to_dsi(host);
+
+	if (mdsi->lanes < 1 || mdsi->lanes > 4) {
+		DRM_ERROR("dsi device params invalid\n");
+		return -EINVAL;
+	}
+
+	dsi->lanes = mdsi->lanes;
+	dsi->format = mdsi->format;
+	dsi->mode_flags = mdsi->mode_flags;
+
+	return 0;
+}
+
+static int dsi_host_detach(struct mipi_dsi_host *host,
+			   struct mipi_dsi_device *mdsi)
+{
+	/* do nothing */
+	return 0;
+}
+
+static const struct mipi_dsi_host_ops dsi_host_ops = {
+	.attach = dsi_host_attach,
+	.detach = dsi_host_detach,
+};
+
+static int dsi_host_init(struct device *dev, struct dw_dsi *dsi)
+{
+	struct mipi_dsi_host *host = &dsi->host;
+	int ret;
+
+	host->dev = dev;
+	host->ops = &dsi_host_ops;
+	ret = mipi_dsi_host_register(host);
+	if (ret) {
+		DRM_ERROR("failed to register dsi host\n");
+		return ret;
+	}
+
+	return 0;
+}
+
 static int dsi_bind(struct device *dev, struct device *master, void *data)
 {
 	struct dsi_data *ddata = dev_get_drvdata(dev);
@@ -653,6 +699,10 @@ static int dsi_bind(struct device *dev, struct device *master, void *data)
 	if (ret)
 		return ret;
 
+	ret = dsi_host_init(dev, dsi);
+	if (ret)
+		return ret;
+
 	return 0;
 }
 
-- 
2.7.1



From xinliang.liu at linaro.org  Fri Feb 26 00:40:26 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri, 26 Feb 2016 16:40:26 +0800
Subject: [PATCH v6 09/11] drm/hisilicon: Add support for external bridge
In-Reply-To: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
References: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456476028-36880-10-git-send-email-xinliang.liu@linaro.org>

Add support for external HDMI bridge.

v6: None.
v5: None.
v4: None.
v3:
- Fix a typo: s/exteranl/external.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 52 ++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index f15798b61451..c2c406446513 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -79,6 +79,7 @@ struct dsi_hw_ctx {
 
 struct dw_dsi {
 	struct drm_encoder encoder;
+	struct drm_bridge *bridge;
 	struct mipi_dsi_host host;
 	struct drm_display_mode cur_mode;
 	struct dsi_hw_ctx *ctx;
@@ -688,6 +689,25 @@ static int dsi_host_init(struct device *dev, struct dw_dsi *dsi)
 	return 0;
 }
 
+static int dsi_bridge_init(struct drm_device *dev, struct dw_dsi *dsi)
+{
+	struct drm_encoder *encoder = &dsi->encoder;
+	struct drm_bridge *bridge = dsi->bridge;
+	int ret;
+
+	/* associate the bridge to dsi encoder */
+	encoder->bridge = bridge;
+	bridge->encoder = encoder;
+
+	ret = drm_bridge_attach(dev, bridge);
+	if (ret) {
+		DRM_ERROR("failed to attach external bridge\n");
+		return ret;
+	}
+
+	return 0;
+}
+
 static int dsi_bind(struct device *dev, struct device *master, void *data)
 {
 	struct dsi_data *ddata = dev_get_drvdata(dev);
@@ -703,6 +723,10 @@ static int dsi_bind(struct device *dev, struct device *master, void *data)
 	if (ret)
 		return ret;
 
+	ret = dsi_bridge_init(drm_dev, dsi);
+	if (ret)
+		return ret;
+
 	return 0;
 }
 
@@ -719,8 +743,36 @@ static const struct component_ops dsi_ops = {
 static int dsi_parse_dt(struct platform_device *pdev, struct dw_dsi *dsi)
 {
 	struct dsi_hw_ctx *ctx = dsi->ctx;
+	struct device_node *np = pdev->dev.of_node;
+	struct device_node *endpoint, *bridge_node;
+	struct drm_bridge *bridge;
 	struct resource *res;
 
+	/*
+	 * Get the endpoint node. In our case, dsi has one output port1
+	 * to which the external HDMI bridge is connected.
+	 */
+	endpoint = of_graph_get_endpoint_by_regs(np, 1, -1);
+	if (!endpoint) {
+		DRM_ERROR("no valid endpoint node\n");
+		return -ENODEV;
+	}
+	of_node_put(endpoint);
+
+	bridge_node = of_graph_get_remote_port_parent(endpoint);
+	if (!bridge_node) {
+		DRM_ERROR("no valid bridge node\n");
+		return -ENODEV;
+	}
+	of_node_put(bridge_node);
+
+	bridge = of_drm_find_bridge(bridge_node);
+	if (!bridge) {
+		DRM_INFO("wait for external HDMI bridge driver.\n");
+		return -EPROBE_DEFER;
+	}
+	dsi->bridge = bridge;
+
 	ctx->pclk = devm_clk_get(&pdev->dev, "pclk");
 	if (IS_ERR(ctx->pclk)) {
 		DRM_ERROR("failed to get pclk clock\n");
-- 
2.7.1



From xinliang.liu at linaro.org  Fri Feb 26 00:40:27 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri, 26 Feb 2016 16:40:27 +0800
Subject: [PATCH v6 10/11] MAINTAINERS: Add maintainer for hisilicon DRM driver
In-Reply-To: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
References: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456476028-36880-11-git-send-email-xinliang.liu@linaro.org>

Add maintainer and reviewer for hisilicon DRM driver.

v6: None.
v5: None.
v4:
- Add Chen Feng <puck.chen at hisilicon.com> as Designated reviewer.
v3: First version.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 MAINTAINERS | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4978dc19a4d2..b94ac713916a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3774,6 +3774,16 @@ S:	Maintained
 F:	drivers/gpu/drm/gma500
 F:	include/drm/gma500*
 
+DRM DRIVERS FOR HISILICON
+M:	Xinliang Liu <z.liuxinliang at hisilicon.com>
+R:	Xinwei Kong <kong.kongxinwei at hisilicon.com>
+R:	Chen Feng <puck.chen at hisilicon.com>
+L:	dri-devel at lists.freedesktop.org
+T:	git git://github.com/xin3liang/linux.git
+S:	Maintained
+F:	drivers/gpu/drm/hisilicon
+F:	Documentation/devicetree/bindings/display/hisilicon
+
 DRM DRIVERS FOR NVIDIA TEGRA
 M:	Thierry Reding <thierry.reding at gmail.com>
 M:	Terje Bergstr?m <tbergstrom at nvidia.com>
-- 
2.7.1



From xinliang.liu at linaro.org  Fri Feb 26 00:40:28 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri, 26 Feb 2016 16:40:28 +0800
Subject: [PATCH v6 11/11] arm64: dts: hisilicon: Add display subsystem DT
 nodes for hi6220
In-Reply-To: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
References: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
Message-ID: <1456476028-36880-12-git-send-email-xinliang.liu@linaro.org>

Add ade, dsi and adv7533 DT nodes for hikey board.

Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 40 +++++++++++++++++++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi      | 55 ++++++++++++++++++++++++++
 2 files changed, 95 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 818525197508..40239fba0572 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -39,3 +39,43 @@
 &uart3 {
 	label = "LS-UART1";
 };
+
+&ade {
+	status = "okay";
+};
+
+&dsi {
+	status = "ok";
+
+	ports {
+		/* 1 for output port */
+		port at 1 {
+			reg = <1>;
+
+			dsi_out0: endpoint at 0 {
+				remote-endpoint = <&adv7533_in>;
+			};
+		};
+	};
+};
+
+&i2c2 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "ok";
+
+	adv7533: adv7533 at 39 {
+		compatible = "adi,adv7533";
+		reg = <0x39>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <1 2>;
+		pd-gpio = <&gpio0 4 0>;
+		adi,dsi-lanes = <4>;
+
+		port {
+			adv7533_in: endpoint {
+				remote-endpoint = <&dsi_out0>;
+			};
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index ad1f1ebcb05c..991568bb3ea1 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -162,6 +162,11 @@
 			#clock-cells = <1>;
 		};
 
+		medianoc_ade: medianoc_ade at f4520000 {
+			compatible = "syscon";
+			reg = <0x0 0xf4520000 0x0 0x4000>;
+		};
+
 		uart0: uart at f8015000 {	/* console */
 			compatible = "arm,pl011", "arm,primecell";
 			reg = <0x0 0xf8015000 0x0 0x1000>;
@@ -209,5 +214,55 @@
 			clock-names = "uartclk", "apb_pclk";
 			status = "disabled";
 		};
+
+		ade: ade at f4100000 {
+			compatible = "hisilicon,hi6220-ade";
+			reg = <0x0 0xf4100000 0x0 0x7800>;
+			reg-names = "ade_base";
+			hisilicon,noc-syscon = <&medianoc_ade>;
+			resets = <&media_ctrl MEDIA_ADE>;
+			interrupts = <0 115 4>; /* ldi interrupt */
+
+			clocks = <&media_ctrl HI6220_ADE_CORE>,
+				 <&media_ctrl HI6220_CODEC_JPEG>,
+				 <&media_ctrl HI6220_ADE_PIX_SRC>;
+			/*clock name*/
+			clock-names  = "clk_ade_core",
+				       "clk_codec_jpeg",
+				       "clk_ade_pix";
+
+			assigned-clocks = <&media_ctrl HI6220_ADE_CORE>,
+				<&media_ctrl HI6220_CODEC_JPEG>;
+			assigned-clock-rates = <360000000>, <288000000>;
+			dma-coherent;
+			status = "disabled";
+
+			port {
+				ade_out: endpoint {
+					remote-endpoint = <&dsi_in>;
+				};
+			};
+		};
+
+		dsi: dsi at f4107800 {
+			compatible = "hisilicon,hi6220-dsi";
+			reg = <0x0 0xf4107800 0x0 0x100>;
+			clocks = <&media_ctrl  HI6220_DSI_PCLK>;
+			clock-names = "pclk";
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				/* 0 for input port */
+				port at 0 {
+					reg = <0>;
+					dsi_in: endpoint {
+						remote-endpoint = <&ade_out>;
+					};
+				};
+			};
+		};
 	};
 };
-- 
2.7.1



From p.zabel at pengutronix.de  Fri Feb 26 00:48:30 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 26 Feb 2016 09:48:30 +0100
Subject: [PATCH v3 3/3] ARM: imx6: Fix procedure to switch the parent
 of, LDB_DI_CLK
In-Reply-To: <56CF5ABC.8040109@timesys.com>
References: <56CF5ABC.8040109@timesys.com>
Message-ID: <1456476510.3383.19.camel@pengutronix.de>

Hi Akshay,

Am Donnerstag, den 25.02.2016, 14:49 -0500 schrieb Akshay Bhat:
> Hi Fabio, Phillip,
> 
> Philipp Zabel <p.zabel <at> pengutronix.de> writes:
> 
>  >
>  > From: Fabio Estevam <fabio.estevam <at> freescale.com>
>  >
> 
> <snip>
>  > +		sel[i][2] = sel[i][3] | 4;
>  > +
>  > +		pr_debug("ccm: switching ldb_di0_sel: %d->%d->%d->%d\n",
>  > +			 sel[i][0], sel[i][1], sel[i][2], sel[i][3]);
> 
> Change ldb_di0_sel to ldb_di%d_sel
> 
> <snip>

Will do.

>  > +	if (sel[0][0] == sel[0][3] && sel[1][0] == sel[1][3])
>  > +		return;
>  > +
>  > +	mmdc_ch1_disable(ccm_base);
>  > +
>  > +	for (i = 1; i < 4; i++) {
>  > +		reg = readl_relaxed(ccm_base + CCM_CS2CDR);
>  > +		reg &= ~((7 << CS2CDR_LDB_DI0_CLK_SEL_SHIFT) |
>  > +			 (7 << CS2CDR_LDB_DI1_CLK_SEL_SHIFT));
>  > +		reg |= ((sel[0][i] << CS2CDR_LDB_DI0_CLK_SEL_SHIFT) |
>  > +			(sel[1][i] << CS2CDR_LDB_DI0_CLK_SEL_SHIFT));
> 
> Needs to be CS2CDR_LDB_DI1_CLK_SEL_SHIFT in the last line; otherwise the 
> ldb_di1_clock is set to have incorrect source.

Thanks for spotting this!

regards
Philipp



From dhdang at apm.com  Fri Feb 26 00:50:22 2016
From: dhdang at apm.com (Duc Dang)
Date: Fri, 26 Feb 2016 00:50:22 -0800
Subject: [GIT PULL 2/2] arm64: X-Gene platforms DTS changes queued for
 v4.6 - part2
In-Reply-To: <CABb+yY2A6bLoNqak5Y8YVLgv=mL1Cx6axnD1trMhKx646NNWFw@mail.gmail.com>
References: <CADaLNDkF8_DVYWPFtGU8tYsbbxDWZF9tozW=Zs3EuV4BqO6OuA@mail.gmail.com>
 <CABb+yY2A6bLoNqak5Y8YVLgv=mL1Cx6axnD1trMhKx646NNWFw@mail.gmail.com>
Message-ID: <CADaLNDnqRkOqam1Xt+Oc+7BXnQKr2EQqSL-1AGsn5fKOWEDnvw@mail.gmail.com>

On Thu, Feb 25, 2016 at 8:28 PM, Jassi Brar <jassisinghbrar at gmail.com> wrote:
> On Fri, Feb 26, 2016 at 8:21 AM, Duc Dang <dhdang at apm.com> wrote:
>> Hi Arnd, Olof,
>>
>> This is the second part of DT changes on X-Gene platforms for v4.6,
>> which enables mailbox driver for X-Gene v2 platforms and also enable
>> SLIMpro Mailbox I2C driver (a client of the mailbox driver) for both
>> X-Gene v1 and v2 platforms.
>>
>> This series depends on the 3rd patch
>> (http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/apm?id=be9c09bcca039d6df9ec736989cdafc68c93fed4)
>> of the series "mailbox: Add APM X-Gene platform mailbox driver"
>> (https://lkml.org/lkml/2016/2/12/749), which was already in linux-next
>> since Feb-15.
>>
>> Hi Jassi,
>>
>> Are you going to get the 3rd patch (dts patch) of series "mailbox: Add
>> APM X-Gene platform mailbox driver" to your tree? Otherwise, I will
>> need to create another pull request for Arnd and Olof.
>>
> Please create the pull request, I don't think mailbox tree is the
> right path for the patch.

Thanks for your confirmation, Jassi.

Regards,
Duc Dang.
>
> Thanks.


From christoffer.dall at linaro.org  Fri Feb 26 00:52:19 2016
From: christoffer.dall at linaro.org (Christoffer Dall)
Date: Fri, 26 Feb 2016 09:52:19 +0100
Subject: [PATCH v14 15/20] KVM: ARM64: Add PMU overflow interrupt routing
In-Reply-To: <1456324417-18992-1-git-send-email-shannon.zhao@linaro.org>
References: <1456290520-10012-16-git-send-email-zhaoshenglong@huawei.com>
 <1456324417-18992-1-git-send-email-shannon.zhao@linaro.org>
Message-ID: <20160226085219.GD9352@cbox>

On Wed, Feb 24, 2016 at 10:33:37PM +0800, Shannon Zhao wrote:
> When calling perf_event_create_kernel_counter to create perf_event,
> assign a overflow handler. Then when the perf event overflows, set the
> corresponding bit of guest PMOVSSET register. If this counter is enabled
> and its interrupt is enabled as well, kick the vcpu to sync the
> interrupt.
> 
> On VM entry, if there is counter overflowed and interrupt level is
> changed, inject the interrupt with corresponding level. On VM exit, sync
> the interrupt level as well if it has been changed.
> 
> Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
> Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
> Reviewed-by: Andrew Jones <drjones at redhat.com>
> ---
>  arch/arm/kvm/arm.c    |  5 ++++
>  include/kvm/arm_pmu.h |  5 ++++
>  virt/kvm/arm/pmu.c    | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++-
>  3 files changed, 78 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index dda1959..5c133ac 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -28,6 +28,7 @@
>  #include <linux/sched.h>
>  #include <linux/kvm.h>
>  #include <trace/events/kvm.h>
> +#include <kvm/arm_pmu.h>
>  
>  #define CREATE_TRACE_POINTS
>  #include "trace.h"
> @@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  		 * non-preemptible context.
>  		 */
>  		preempt_disable();
> +		kvm_pmu_flush_hwstate(vcpu);
>  		kvm_timer_flush_hwstate(vcpu);
>  		kvm_vgic_flush_hwstate(vcpu);
>  
> @@ -593,6 +595,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  		if (ret <= 0 || need_new_vmid_gen(vcpu->kvm) ||
>  			vcpu->arch.power_off || vcpu->arch.pause) {
>  			local_irq_enable();
> +			kvm_pmu_sync_hwstate(vcpu);
>  			kvm_timer_sync_hwstate(vcpu);
>  			kvm_vgic_sync_hwstate(vcpu);
>  			preempt_enable();
> @@ -641,6 +644,8 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  		kvm_guest_exit();
>  		trace_kvm_exit(ret, kvm_vcpu_trap_get_class(vcpu), *vcpu_pc(vcpu));
>  
> +		kvm_pmu_sync_hwstate(vcpu);
> +

nit: I think you should move this below the comment and update the
comment say "We must sync the timer and PMU state before ..."

>  		/*
>  		 * We must sync the timer state before the vgic state so that
>  		 * the vgic can properly sample the updated state of the
> diff --git a/include/kvm/arm_pmu.h b/include/kvm/arm_pmu.h
> index 8bc92d1..9c184ed 100644
> --- a/include/kvm/arm_pmu.h
> +++ b/include/kvm/arm_pmu.h
> @@ -35,6 +35,7 @@ struct kvm_pmu {
>  	int irq_num;
>  	struct kvm_pmc pmc[ARMV8_PMU_MAX_COUNTERS];
>  	bool ready;
> +	bool irq_level;
>  };
>  
>  #define kvm_arm_pmu_v3_ready(v)		((v)->arch.pmu.ready)
> @@ -44,6 +45,8 @@ u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu);
>  void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val);
> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu);
> +void kvm_pmu_sync_hwstate(struct kvm_vcpu *vcpu);
>  void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val);
>  void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
> @@ -67,6 +70,8 @@ static inline u64 kvm_pmu_valid_counter_mask(struct kvm_vcpu *vcpu)
>  static inline void kvm_pmu_disable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_enable_counter(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val) {}
> +static inline void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu) {}
> +static inline void kvm_pmu_sync_hwstate(struct kvm_vcpu *vcpu) {}
>  static inline void kvm_pmu_software_increment(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_handle_pmcr(struct kvm_vcpu *vcpu, u64 val) {}
>  static inline void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu,
> diff --git a/virt/kvm/arm/pmu.c b/virt/kvm/arm/pmu.c
> index cda869c..74e858c 100644
> --- a/virt/kvm/arm/pmu.c
> +++ b/virt/kvm/arm/pmu.c
> @@ -21,6 +21,7 @@
>  #include <linux/perf_event.h>
>  #include <asm/kvm_emulate.h>
>  #include <kvm/arm_pmu.h>
> +#include <kvm/arm_vgic.h>
>  
>  /**
>   * kvm_pmu_get_counter_value - get PMU counter value
> @@ -180,6 +181,71 @@ void kvm_pmu_overflow_set(struct kvm_vcpu *vcpu, u64 val)
>  		kvm_vcpu_kick(vcpu);
>  }
>  
> +static void kvm_pmu_update_state(struct kvm_vcpu *vcpu)
> +{
> +	struct kvm_pmu *pmu = &vcpu->arch.pmu;
> +	bool overflow;
> +
> +	if (!kvm_arm_pmu_v3_ready(vcpu))
> +		return;
> +
> +	overflow = !!kvm_pmu_overflow_status(vcpu);
> +	if (pmu->irq_level != overflow) {
> +		pmu->irq_level = overflow;
> +		kvm_vgic_inject_irq(vcpu->kvm, vcpu->vcpu_id,
> +				    pmu->irq_num, overflow);
> +	}
> +}
> +
> +/**
> + * kvm_pmu_flush_hwstate - flush pmu state to cpu
> + * @vcpu: The vcpu pointer
> + *
> + * Check if the PMU has overflowed while we were running in the host, and inject
> + * an interrupt if that was the case.
> + */
> +void kvm_pmu_flush_hwstate(struct kvm_vcpu *vcpu)
> +{
> +	kvm_pmu_update_state(vcpu);
> +}
> +
> +/**
> + * kvm_pmu_sync_hwstate - sync pmu state from cpu
> + * @vcpu: The vcpu pointer
> + *
> + * Check if the PMU has overflowed while we were running in the guest, and
> + * inject an interrupt if that was the case.
> + */
> +void kvm_pmu_sync_hwstate(struct kvm_vcpu *vcpu)
> +{
> +	kvm_pmu_update_state(vcpu);
> +}
> +
> +static inline struct kvm_vcpu *kvm_pmc_to_vcpu(struct kvm_pmc *pmc)
> +{
> +	struct kvm_pmu *pmu;
> +	struct kvm_vcpu_arch *vcpu_arch;
> +
> +	pmc -= pmc->idx;
> +	pmu = container_of(pmc, struct kvm_pmu, pmc[0]);
> +	vcpu_arch = container_of(pmu, struct kvm_vcpu_arch, pmu);
> +	return container_of(vcpu_arch, struct kvm_vcpu, arch);
> +}
> +
> +/**
> + * When perf event overflows, call kvm_pmu_overflow_set to set overflow status.
> + */
> +static void kvm_pmu_perf_overflow(struct perf_event *perf_event,
> +				  struct perf_sample_data *data,
> +				  struct pt_regs *regs)
> +{
> +	struct kvm_pmc *pmc = perf_event->overflow_handler_context;
> +	struct kvm_vcpu *vcpu = kvm_pmc_to_vcpu(pmc);
> +	int idx = pmc->idx;
> +
> +	kvm_pmu_overflow_set(vcpu, BIT(idx));
> +}
> +
>  /**
>   * kvm_pmu_software_increment - do software increment
>   * @vcpu: The vcpu pointer
> @@ -291,7 +357,8 @@ void kvm_pmu_set_counter_event_type(struct kvm_vcpu *vcpu, u64 data,
>  	/* The initial sample period (overflow count) of an event. */
>  	attr.sample_period = (-counter) & pmc->bitmask;
>  
> -	event = perf_event_create_kernel_counter(&attr, -1, current, NULL, pmc);
> +	event = perf_event_create_kernel_counter(&attr, -1, current,
> +						 kvm_pmu_perf_overflow, pmc);
>  	if (IS_ERR(event)) {
>  		pr_err_once("kvm: pmu event creation failed %ld\n",
>  			    PTR_ERR(event));
> -- 
> 2.1.0
> 

Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>


From ard.biesheuvel at linaro.org  Fri Feb 26 00:51:45 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 26 Feb 2016 09:51:45 +0100
Subject: arm64 defconfig currently broken in -next
Message-ID: <CAKv+Gu933t2DjBoHEfe=ZNcbrJMHHvT_F3Pug261w0WYTduVTw@mail.gmail.com>

arm64 defconfig is currently broken in -next, due to the way
early_memremap_ro() is compiled conditionally, based on a condition
that incorrectly resolves to false due to the inclusion order of
various header files

This fixes it for me

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 16438dd..c6ede6d 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -49,16 +49,6 @@

 #define FIRST_USER_ADDRESS     0UL

-#ifndef __ASSEMBLY__
-
-#include <asm/fixmap.h>
-#include <linux/mmdebug.h>
-
-extern void __pte_error(const char *file, int line, unsigned long val);
-extern void __pmd_error(const char *file, int line, unsigned long val);
-extern void __pud_error(const char *file, int line, unsigned long val);
-extern void __pgd_error(const char *file, int line, unsigned long val);
-
 #define PROT_DEFAULT           (PTE_TYPE_PAGE | PTE_AF | PTE_SHARED)
 #define PROT_SECT_DEFAULT      (PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S)

@@ -112,6 +102,16 @@
 #define __S110  PAGE_SHARED_EXEC
 #define __S111  PAGE_SHARED_EXEC

+#ifndef __ASSEMBLY__
+
+#include <asm/fixmap.h>
+#include <linux/mmdebug.h>
+
+extern void __pte_error(const char *file, int line, unsigned long val);
+extern void __pmd_error(const char *file, int line, unsigned long val);
+extern void __pud_error(const char *file, int line, unsigned long val);
+extern void __pgd_error(const char *file, int line, unsigned long val);
+
 /*
  * ZERO_PAGE is a global shared page that is always zero: used
  * for zero-mapped memory areas etc..


From p.zabel at pengutronix.de  Fri Feb 26 00:51:54 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 26 Feb 2016 09:51:54 +0100
Subject: [PATCH v4 3/3] ARM: imx6: Fix procedure to switch the parent of
 LDB_DI_CLK
In-Reply-To: <1456476714-11351-1-git-send-email-p.zabel@pengutronix.de>
References: <1456476714-11351-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1456476714-11351-4-git-send-email-p.zabel@pengutronix.de>

From: Fabio Estevam <fabio.estevam at freescale.com>

Due to incorrect placement of the clock gate cell in the ldb_di[x]_clk
tree, the glitchy parent mux of ldb_di[x]_clk can cause a glitch to
enter the ldb_di_ipu_div divider. If the divider gets locked up, no
ldb_di[x]_clk is generated, and the LVDS display will hang when the
ipu_di_clk is sourced from ldb_di_clk.

To fix the problem, both the new and current parent of the ldb_di_clk
should be disabled before the switch. This patch ensures that correct
steps are followed when ldb_di_clk parent is switched in the beginning
of boot. The glitchy muxes are then registered as read-only. The clock
parent can be selected using the assigned-clocks and
assigned-clock-parents properties of the ccm device tree node:

	&clks {
		assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
				  <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
		assigned-clock-parents = <&clks IMX6QDL_CLK_MMDC_CH1_AXI>,
					 <&clks IMX6QDL_CLK_PLL5_VIDEO_DIV>;
	};

Signed-off-by: Ranjani Vaidyanathan <Ranjani.Vaidyanathan at freescale.com>
Signed-off-by: Fabio Estevam <fabio.estevam at freescale.com>
Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
Changes since v3:
 - Fix LDB_DI1_SEL shift when setting divider and fix a debug printk,
   issues reported by Akshay Bhat.
---
 drivers/clk/imx/clk-imx6q.c | 275 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 270 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index cfcffa4..6ed41ae 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -138,9 +138,90 @@ static struct clk ** const uart_clks[] __initconst = {
 	NULL
 };
 
+static int ldb_di_sel_by_clock_id(int clock_id)
+{
+	switch (clock_id) {
+	case IMX6QDL_CLK_PLL5_VIDEO_DIV:
+		if (clk_on_imx6q() &&
+		    imx_get_soc_revision() == IMX_CHIP_REVISION_1_0)
+			return -ENOENT;
+		return 0;
+	case IMX6QDL_CLK_PLL2_PFD0_352M:
+		return 1;
+	case IMX6QDL_CLK_PLL2_PFD2_396M:
+		return 2;
+	case IMX6QDL_CLK_MMDC_CH1_AXI:
+		return 3;
+	case IMX6QDL_CLK_PLL3_USB_OTG:
+		return 4;
+	default:
+		return -ENOENT;
+	}
+}
+
+static void of_assigned_ldb_sels(struct device_node *node,
+				 unsigned int *ldb_di0_sel,
+				 unsigned int *ldb_di1_sel)
+{
+	struct of_phandle_args clkspec;
+	int index, rc, num_parents;
+	int parent, child, sel;
+
+	num_parents = of_count_phandle_with_args(node, "assigned-clock-parents",
+						 "#clock-cells");
+	for (index = 0; index < num_parents; index++) {
+		rc = of_parse_phandle_with_args(node, "assigned-clock-parents",
+					"#clock-cells", index, &clkspec);
+		if (rc < 0) {
+			/* skip empty (null) phandles */
+			if (rc == -ENOENT)
+				continue;
+			else
+				return;
+		}
+		if (clkspec.np != node || clkspec.args[0] >= IMX6QDL_CLK_END) {
+			pr_err("ccm: parent clock %d not in ccm\n", index);
+			return;
+		}
+		parent = clkspec.args[0];
+
+		rc = of_parse_phandle_with_args(node, "assigned-clocks",
+				"#clock-cells", index, &clkspec);
+		if (rc < 0)
+			return;
+		if (clkspec.np != node || clkspec.args[0] >= IMX6QDL_CLK_END) {
+			pr_err("ccm: child clock %d not in ccm\n", index);
+			return;
+		}
+		child = clkspec.args[0];
+
+		if (child != IMX6QDL_CLK_LDB_DI0_SEL &&
+		    child != IMX6QDL_CLK_LDB_DI1_SEL)
+			continue;
+
+		sel = ldb_di_sel_by_clock_id(parent);
+		if (sel < 0) {
+			pr_err("ccm: invalid ldb_di%d parent clock: %d\n",
+			       child == IMX6QDL_CLK_LDB_DI1_SEL, parent);
+			continue;
+		}
+
+		if (child == IMX6QDL_CLK_LDB_DI0_SEL)
+			*ldb_di0_sel = sel;
+		if (child == IMX6QDL_CLK_LDB_DI1_SEL)
+			*ldb_di1_sel = sel;
+	}
+}
+
 #define CCM_CCDR		0x04
+#define CCM_CCSR		0x0c
+#define CCM_CS2CDR		0x2c
 
-#define CCDR_MMDC_CH1_MASK	BIT(16)
+#define CCDR_MMDC_CH1_MASK		BIT(16)
+#define CCSR_PLL3_SW_CLK_SEL		BIT(0)
+
+#define CS2CDR_LDB_DI0_CLK_SEL_SHIFT	9
+#define CS2CDR_LDB_DI1_CLK_SEL_SHIFT	12
 
 static void __init imx6q_mmdc_ch1_mask_handshake(void __iomem *ccm_base)
 {
@@ -151,10 +232,184 @@ static void __init imx6q_mmdc_ch1_mask_handshake(void __iomem *ccm_base)
 	writel_relaxed(reg, ccm_base + CCM_CCDR);
 }
 
+/*
+ * The only way to disable the MMDC_CH1 clock is to move it to pll3_sw_clk
+ * via periph2_clk2_sel and then to disable pll3_sw_clk by selecting the
+ * bypass clock source, since there is no CG bit for mmdc_ch1.
+ */
+static void mmdc_ch1_disable(void __iomem *ccm_base)
+{
+	unsigned int reg;
+
+	clk_set_parent(clk[IMX6QDL_CLK_PERIPH2_CLK2_SEL],
+		       clk[IMX6QDL_CLK_PLL3_USB_OTG]);
+
+	/*
+	 * Handshake with mmdc_ch1 module must be masked when changing
+	 * periph2_clk_sel.
+	 */
+	clk_set_parent(clk[IMX6QDL_CLK_PERIPH2], clk[IMX6QDL_CLK_PERIPH2_CLK2]);
+
+	/* Disable pll3_sw_clk by selecting the bypass clock source */
+	reg = readl_relaxed(ccm_base + CCM_CCSR);
+	reg |= CCSR_PLL3_SW_CLK_SEL;
+	writel_relaxed(reg, ccm_base + CCM_CCSR);
+}
+
+static void mmdc_ch1_reenable(void __iomem *ccm_base)
+{
+	unsigned int reg;
+
+	/* Enable pll3_sw_clk by disabling the bypass */
+	reg = readl_relaxed(ccm_base + CCM_CCSR);
+	reg &= ~CCSR_PLL3_SW_CLK_SEL;
+	writel_relaxed(reg, ccm_base + CCM_CCSR);
+
+	clk_set_parent(clk[IMX6QDL_CLK_PERIPH2], clk[IMX6QDL_CLK_PERIPH2_PRE]);
+}
+
+/*
+ * We have to follow a strict procedure when changing the LDB clock source,
+ * otherwise we risk introducing a glitch that can lock up the LDB divider.
+ * Things to keep in mind:
+ *
+ * 1. The current and new parent clock inputs to the mux must be disabled.
+ * 2. The default clock input for ldb_di0/1_clk_sel is mmdc_ch1_axi, which
+ *    has no CG bit.
+ * 3. pll2_pfd2_396m can not be gated if it is used as memory clock.
+ * 4. In the RTL implementation of the LDB_DI_CLK_SEL muxes the top four
+ *    options are in one mux and the PLL3 option along with three unused
+ *    inputs is in a second mux. There is a third mux with two inputs used
+ *    to decide between the first and second 4-port mux:
+ *
+ *    pll5_video_div 0 --|\
+ *    pll2_pfd0_352m 1 --| |_
+ *    pll2_pfd2_396m 2 --| | `-|\
+ *    mmdc_ch1_axi   3 --|/    | |
+ *                             | |--
+ *    pll3_usb_otg   4 --|\    | |
+ *                   5 --| |_,-|/
+ *                   6 --| |
+ *                   7 --|/
+ *
+ * The ldb_di0/1_clk_sel[1:0] bits control both 4-port muxes at the same time.
+ * The ldb_di0/1_clk_sel[2] bit controls the 2-port mux. The code below
+ * switches the parent to the bottom mux first and then manipulates the top
+ * mux to ensure that no glitch will enter the divider.
+ */
+static void init_ldb_clks(struct device_node *np, void __iomem *ccm_base)
+{
+	unsigned int reg;
+	unsigned int sel[2][4];
+	int i;
+
+	reg = readl_relaxed(ccm_base + CCM_CS2CDR);
+	sel[0][0] = (reg >> CS2CDR_LDB_DI0_CLK_SEL_SHIFT) & 7;
+	sel[1][0] = (reg >> CS2CDR_LDB_DI1_CLK_SEL_SHIFT) & 7;
+
+	sel[0][3] = sel[0][2] = sel[0][1] = sel[0][0];
+	sel[1][3] = sel[1][2] = sel[1][1] = sel[1][0];
+
+	of_assigned_ldb_sels(np, &sel[0][3], &sel[1][3]);
+
+	for (i = 0; i < 2; i++) {
+		/* Warn if a glitch might have been introduced already */
+		if (sel[i][0] != 3) {
+			pr_warn("ccm: ldb_di%d_sel already changed from reset value: %d\n",
+				i, sel[i][0]);
+		}
+
+		if (sel[i][0] == sel[i][3])
+			continue;
+
+		/* Only switch to or from pll2_pfd2_396m if it is disabled */
+		if ((sel[i][0] == 2 || sel[i][3] == 2) &&
+		    (clk_get_parent(clk[IMX6QDL_CLK_PERIPH_PRE]) ==
+		     clk[IMX6QDL_CLK_PLL2_PFD2_396M])) {
+			pr_err("ccm: ldb_di%d_sel: couldn't disable pll2_pfd2_396m\n",
+			       i);
+			sel[i][3] = sel[i][2] = sel[i][1] = sel[i][0];
+			continue;
+		}
+
+		/*
+		 * It is unclear whether the procedure works for switching from
+		 * pll3_usb_otg to any other parent than pll5_video_div
+		 */
+		if (sel[i][0] > 3 && sel[i][0] != (sel[i][3] | 4)) {
+			pr_err("ccm: ldb_di%d_sel workaround only for top mux\n",
+			       i);
+			sel[i][3] = sel[i][2] = sel[i][1] = sel[i][0];
+			continue;
+		}
+
+		/* First switch to the bottom mux */
+		sel[i][1] = sel[i][0] | 4;
+
+		/* Then configure the top mux before switching back to it */
+		sel[i][2] = sel[i][3] | 4;
+
+		pr_debug("ccm: switching ldb_di%d_sel: %d->%d->%d->%d\n", i,
+			 sel[i][0], sel[i][1], sel[i][2], sel[i][3]);
+	}
+
+	if (sel[0][0] == sel[0][3] && sel[1][0] == sel[1][3])
+		return;
+
+	mmdc_ch1_disable(ccm_base);
+
+	for (i = 1; i < 4; i++) {
+		reg = readl_relaxed(ccm_base + CCM_CS2CDR);
+		reg &= ~((7 << CS2CDR_LDB_DI0_CLK_SEL_SHIFT) |
+			 (7 << CS2CDR_LDB_DI1_CLK_SEL_SHIFT));
+		reg |= ((sel[0][i] << CS2CDR_LDB_DI0_CLK_SEL_SHIFT) |
+			(sel[1][i] << CS2CDR_LDB_DI1_CLK_SEL_SHIFT));
+		writel_relaxed(reg, ccm_base + CCM_CS2CDR);
+	}
+
+	mmdc_ch1_reenable(ccm_base);
+}
+
+#define CCM_ANALOG_PLL_VIDEO	0xa0
+#define CCM_ANALOG_PFD_480	0xf0
+#define CCM_ANALOG_PFD_528	0x100
+
+#define PLL_ENABLE		BIT(13)
+
+#define PFD0_CLKGATE		BIT(7)
+#define PFD1_CLKGATE		BIT(15)
+#define PFD2_CLKGATE		BIT(23)
+#define PFD3_CLKGATE		BIT(31)
+
+static void disable_anatop_clocks(void __iomem *anatop_base)
+{
+	unsigned int reg;
+
+	/* Make sure PLL2 PFDs 0-2 are gated */
+	reg = readl_relaxed(anatop_base + CCM_ANALOG_PFD_528);
+	/* Cannot gate PFD2 if pll2_pfd2_396m is the parent of MMDC clock */
+	if (clk_get_parent(clk[IMX6QDL_CLK_PERIPH_PRE]) ==
+	    clk[IMX6QDL_CLK_PLL2_PFD2_396M])
+		reg |= PFD0_CLKGATE | PFD1_CLKGATE;
+	else
+		reg |= PFD0_CLKGATE | PFD1_CLKGATE | PFD2_CLKGATE;
+	writel_relaxed(reg, anatop_base + CCM_ANALOG_PFD_528);
+
+	/* Make sure PLL3 PFDs 0-3 are gated */
+	reg = readl_relaxed(anatop_base + CCM_ANALOG_PFD_480);
+	reg |= PFD0_CLKGATE | PFD1_CLKGATE | PFD2_CLKGATE | PFD3_CLKGATE;
+	writel_relaxed(reg, anatop_base + CCM_ANALOG_PFD_480);
+
+	/* Make sure PLL5 is disabled */
+	reg = readl_relaxed(anatop_base + CCM_ANALOG_PLL_VIDEO);
+	reg &= ~PLL_ENABLE;
+	writel_relaxed(reg, anatop_base + CCM_ANALOG_PLL_VIDEO);
+}
+
 static void __init imx6q_clocks_init(struct device_node *ccm_node)
 {
 	struct device_node *np;
-	void __iomem *base;
+	void __iomem *anatop_base, *base;
 	int i;
 	int ret;
 
@@ -167,7 +422,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[IMX6QDL_CLK_ANACLK2] = imx_obtain_fixed_clock("anaclk2", 0);
 
 	np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-anatop");
-	base = of_iomap(np, 0);
+	anatop_base = base = of_iomap(np, 0);
 	WARN_ON(!base);
 
 	/* Audio/video PLL post dividers do not work on i.MX6q revision 1.0 */
@@ -292,8 +547,6 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	base = of_iomap(np, 0);
 	WARN_ON(!base);
 
-	imx6q_mmdc_ch1_mask_handshake(base);
-
 	/*                                              name                reg       shift width parent_names     num_parents */
 	clk[IMX6QDL_CLK_STEP]             = imx_clk_mux("step",	            base + 0xc,  8,  1, step_sels,	   ARRAY_SIZE(step_sels));
 	clk[IMX6QDL_CLK_PLL1_SW]          = imx_clk_mux("pll1_sw",	    base + 0xc,  2,  1, pll1_sw_sels,      ARRAY_SIZE(pll1_sw_sels));
@@ -314,6 +567,18 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[IMX6QDL_CLK_GPU3D_SHADER_SEL] = imx_clk_mux("gpu3d_shader_sel", base + 0x18, 8,  2, gpu3d_shader_sels, ARRAY_SIZE(gpu3d_shader_sels));
 	clk[IMX6QDL_CLK_IPU1_SEL]         = imx_clk_mux("ipu1_sel",         base + 0x3c, 9,  2, ipu_sels,          ARRAY_SIZE(ipu_sels));
 	clk[IMX6QDL_CLK_IPU2_SEL]         = imx_clk_mux("ipu2_sel",         base + 0x3c, 14, 2, ipu_sels,          ARRAY_SIZE(ipu_sels));
+
+	disable_anatop_clocks(anatop_base);
+
+	imx6q_mmdc_ch1_mask_handshake(base);
+
+	/*
+	 * The LDB_DI0/1_SEL muxes are registered read-only due to a hardware
+	 * bug. Set the muxes to the requested values before registering the
+	 * ldb_di_sel clocks.
+	 */
+	init_ldb_clks(np, base);
+
 	clk[IMX6QDL_CLK_LDB_DI0_SEL]      = imx_clk_mux_ldb("ldb_di0_sel", base + 0x2c, 9,  3, ldb_di_sels,      ARRAY_SIZE(ldb_di_sels));
 	clk[IMX6QDL_CLK_LDB_DI1_SEL]      = imx_clk_mux_ldb("ldb_di1_sel", base + 0x2c, 12, 3, ldb_di_sels,      ARRAY_SIZE(ldb_di_sels));
 	clk[IMX6QDL_CLK_IPU1_DI0_PRE_SEL] = imx_clk_mux_flags("ipu1_di0_pre_sel", base + 0x34, 6,  3, ipu_di_pre_sels,   ARRAY_SIZE(ipu_di_pre_sels), CLK_SET_RATE_PARENT);
-- 
2.7.0



From p.zabel at pengutronix.de  Fri Feb 26 00:51:51 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 26 Feb 2016 09:51:51 +0100
Subject: [PATCH v4 0/3] i.MX6 LDB mux/divider glitch workaround
Message-ID: <1456476714-11351-1-git-send-email-p.zabel@pengutronix.de>

Hi,

the last version contained a bug when setting the muxes, which caused it
to OR the desired mux values for ldb_di0_sel and ldb_di1_sel and write the
result to the ldb_di0_sel bitfield. This is fixed now.
I think the mmdc_ch1 patch should be uncontroversial. The remaining two
could use some test feedback and somebody who can take a look at ERR009219
and EB821 and can confirm that this patch is in line with the suggested
workaround.

regards
Philipp

Changes since v3:
 - Fix LDB_DI1_SEL shift when setting divider and fix a debug printk,
   issues reported by Akshay Bhat.

Fabio Estevam (1):
  ARM: imx6: Fix procedure to switch the parent of LDB_DI_CLK

Philipp Zabel (2):
  ARM: imx6: Mask mmdc_ch1 handshake for periph2_sel and
    mmdc_ch1_axi_podf
  ARM: imx6: Make the LDB_DI0 and LDB_DI1 clocks read-only.

 drivers/clk/imx/clk-imx6q.c | 294 ++++++++++++++++++++++++++++++++++++++++++--
 drivers/clk/imx/clk.h       |   8 ++
 2 files changed, 292 insertions(+), 10 deletions(-)

-- 
2.7.0



From p.zabel at pengutronix.de  Fri Feb 26 00:51:52 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 26 Feb 2016 09:51:52 +0100
Subject: [PATCH v4 1/3] ARM: imx6: Mask mmdc_ch1 handshake for periph2_sel and
 mmdc_ch1_axi_podf
In-Reply-To: <1456476714-11351-1-git-send-email-p.zabel@pengutronix.de>
References: <1456476714-11351-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1456476714-11351-2-git-send-email-p.zabel@pengutronix.de>

MMDC CH1 is not used on i.MX6Q, so the handshake needed to change the
parent of periph2_sel or the divider of mmdc_ch1_axi_podf will never
succeed.
Disable the handshake mechanism to allow changing the frequency of
mmdc_ch1_axi, allowing to use it as a possible source for the LDB DI
clock.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 drivers/clk/imx/clk-imx6q.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index f0efc6f..871c905 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -138,6 +138,19 @@ static struct clk ** const uart_clks[] __initconst = {
 	NULL
 };
 
+#define CCM_CCDR		0x04
+
+#define CCDR_MMDC_CH1_MASK	BIT(16)
+
+static void __init imx6q_mmdc_ch1_mask_handshake(void __iomem *ccm_base)
+{
+	unsigned int reg;
+
+	reg = readl_relaxed(ccm_base + CCM_CCDR);
+	reg |= CCDR_MMDC_CH1_MASK;
+	writel_relaxed(reg, ccm_base + CCM_CCDR);
+}
+
 static void __init imx6q_clocks_init(struct device_node *ccm_node)
 {
 	struct device_node *np;
@@ -279,6 +292,8 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	base = of_iomap(np, 0);
 	WARN_ON(!base);
 
+	imx6q_mmdc_ch1_mask_handshake(base);
+
 	/*                                              name                reg       shift width parent_names     num_parents */
 	clk[IMX6QDL_CLK_STEP]             = imx_clk_mux("step",	            base + 0xc,  8,  1, step_sels,	   ARRAY_SIZE(step_sels));
 	clk[IMX6QDL_CLK_PLL1_SW]          = imx_clk_mux("pll1_sw",	    base + 0xc,  2,  1, pll1_sw_sels,      ARRAY_SIZE(pll1_sw_sels));
-- 
2.7.0



From p.zabel at pengutronix.de  Fri Feb 26 00:51:53 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 26 Feb 2016 09:51:53 +0100
Subject: [PATCH v4 2/3] ARM: imx6: Make the LDB_DI0 and LDB_DI1 clocks
 read-only.
In-Reply-To: <1456476714-11351-1-git-send-email-p.zabel@pengutronix.de>
References: <1456476714-11351-1-git-send-email-p.zabel@pengutronix.de>
Message-ID: <1456476714-11351-3-git-send-email-p.zabel@pengutronix.de>

Due to incorrect placement of the clock gate cell in the ldb_di[x]_clk
tree, the glitchy parent mux of ldb_di[x]_clk can cause a glitch to
enter the ldb_di_ipu_div divider. If the divider gets locked up, no
ldb_di[x]_clk is generated, and the LVDS display will hang when the
ipu_di_clk is sourced from ldb_di_clk.

To fix the problem, both the new and current parent of the ldb_di_clk
should be disabled before the switch. As this can not be guaranteed by
the clock framework during runtime, make the ldb_di[x]_sel muxes read-only.
A workaround to set the muxes once during boot could be added to the
kernel or bootloader.

Signed-off-by: Philipp Zabel <p.zabel at pengutronix.de>
---
 drivers/clk/imx/clk-imx6q.c | 10 ++--------
 drivers/clk/imx/clk.h       |  8 ++++++++
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index 871c905..cfcffa4 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -314,8 +314,8 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 	clk[IMX6QDL_CLK_GPU3D_SHADER_SEL] = imx_clk_mux("gpu3d_shader_sel", base + 0x18, 8,  2, gpu3d_shader_sels, ARRAY_SIZE(gpu3d_shader_sels));
 	clk[IMX6QDL_CLK_IPU1_SEL]         = imx_clk_mux("ipu1_sel",         base + 0x3c, 9,  2, ipu_sels,          ARRAY_SIZE(ipu_sels));
 	clk[IMX6QDL_CLK_IPU2_SEL]         = imx_clk_mux("ipu2_sel",         base + 0x3c, 14, 2, ipu_sels,          ARRAY_SIZE(ipu_sels));
-	clk[IMX6QDL_CLK_LDB_DI0_SEL]      = imx_clk_mux_flags("ldb_di0_sel", base + 0x2c, 9,  3, ldb_di_sels,      ARRAY_SIZE(ldb_di_sels), CLK_SET_RATE_PARENT);
-	clk[IMX6QDL_CLK_LDB_DI1_SEL]      = imx_clk_mux_flags("ldb_di1_sel", base + 0x2c, 12, 3, ldb_di_sels,      ARRAY_SIZE(ldb_di_sels), CLK_SET_RATE_PARENT);
+	clk[IMX6QDL_CLK_LDB_DI0_SEL]      = imx_clk_mux_ldb("ldb_di0_sel", base + 0x2c, 9,  3, ldb_di_sels,      ARRAY_SIZE(ldb_di_sels));
+	clk[IMX6QDL_CLK_LDB_DI1_SEL]      = imx_clk_mux_ldb("ldb_di1_sel", base + 0x2c, 12, 3, ldb_di_sels,      ARRAY_SIZE(ldb_di_sels));
 	clk[IMX6QDL_CLK_IPU1_DI0_PRE_SEL] = imx_clk_mux_flags("ipu1_di0_pre_sel", base + 0x34, 6,  3, ipu_di_pre_sels,   ARRAY_SIZE(ipu_di_pre_sels), CLK_SET_RATE_PARENT);
 	clk[IMX6QDL_CLK_IPU1_DI1_PRE_SEL] = imx_clk_mux_flags("ipu1_di1_pre_sel", base + 0x34, 15, 3, ipu_di_pre_sels,   ARRAY_SIZE(ipu_di_pre_sels), CLK_SET_RATE_PARENT);
 	clk[IMX6QDL_CLK_IPU2_DI0_PRE_SEL] = imx_clk_mux_flags("ipu2_di0_pre_sel", base + 0x38, 6,  3, ipu_di_pre_sels,   ARRAY_SIZE(ipu_di_pre_sels), CLK_SET_RATE_PARENT);
@@ -515,12 +515,6 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 
 	clk_register_clkdev(clk[IMX6QDL_CLK_ENET_REF], "enet_ref", NULL);
 
-	if ((imx_get_soc_revision() != IMX_CHIP_REVISION_1_0) ||
-	    clk_on_imx6dl()) {
-		clk_set_parent(clk[IMX6QDL_CLK_LDB_DI0_SEL], clk[IMX6QDL_CLK_PLL5_VIDEO_DIV]);
-		clk_set_parent(clk[IMX6QDL_CLK_LDB_DI1_SEL], clk[IMX6QDL_CLK_PLL5_VIDEO_DIV]);
-	}
-
 	clk_set_rate(clk[IMX6QDL_CLK_PLL3_PFD1_540M], 540000000);
 	if (clk_on_imx6dl())
 		clk_set_parent(clk[IMX6QDL_CLK_IPU1_SEL], clk[IMX6QDL_CLK_PLL3_PFD1_540M]);
diff --git a/drivers/clk/imx/clk.h b/drivers/clk/imx/clk.h
index c94ac5c..19a887c 100644
--- a/drivers/clk/imx/clk.h
+++ b/drivers/clk/imx/clk.h
@@ -136,6 +136,14 @@ static inline struct clk *imx_clk_mux_flags(const char *name,
 			&imx_ccm_lock);
 }
 
+static inline struct clk *imx_clk_mux_ldb(const char *name, void __iomem *reg,
+		u8 shift, u8 width, const char **parents, int num_parents)
+{
+	return clk_register_mux(NULL, name, parents, num_parents,
+			CLK_SET_RATE_NO_REPARENT | CLK_SET_RATE_PARENT, reg,
+			shift, width, CLK_MUX_READ_ONLY, &imx_ccm_lock);
+}
+
 static inline struct clk *imx_clk_fixed_factor(const char *name,
 		const char *parent, unsigned int mult, unsigned int div)
 {
-- 
2.7.0



From architt at codeaurora.org  Fri Feb 26 00:54:18 2016
From: architt at codeaurora.org (Archit Taneja)
Date: Fri, 26 Feb 2016 14:24:18 +0530
Subject: [PATCH v6 02/11] drm/hisilicon: Add hisilicon kirin drm master
 driver
In-Reply-To: <1456476028-36880-3-git-send-email-xinliang.liu@linaro.org>
References: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
 <1456476028-36880-3-git-send-email-xinliang.liu@linaro.org>
Message-ID: <56D012BA.9000509@codeaurora.org>

Hi,

I had some minor comments. Sorry about sharing this late. Otherwise,
the looks good to me.

On 02/26/2016 02:10 PM, Xinliang Liu wrote:
> Add kirin DRM master driver for hi6220 SoC which used in HiKey board.
> Add dumb buffer feature.
> Add prime dmabuf feature.
>
> v6: None.
> v5: None.
> v4: None.
> v3:
> - Move and rename all the files to kirin sub-directory.
>    So that we could separate different seires SoCs' driver.
> - Replace drm_platform_init, load, unload implementation.
> v2:
> - Remove abtraction layer.
>
> Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
> ---
>   drivers/gpu/drm/Kconfig                         |   2 +
>   drivers/gpu/drm/Makefile                        |   1 +
>   drivers/gpu/drm/hisilicon/Kconfig               |   5 +
>   drivers/gpu/drm/hisilicon/Makefile              |   5 +
>   drivers/gpu/drm/hisilicon/kirin/Kconfig         |   9 +
>   drivers/gpu/drm/hisilicon/kirin/Makefile        |   3 +
>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 321 ++++++++++++++++++++++++
>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  20 ++
>   8 files changed, 366 insertions(+)
>   create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
>   create mode 100644 drivers/gpu/drm/hisilicon/Makefile
>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index b50ae60f5f50..f5c5656e2547 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -277,3 +277,5 @@ source "drivers/gpu/drm/imx/Kconfig"
>   source "drivers/gpu/drm/vc4/Kconfig"
>
>   source "drivers/gpu/drm/etnaviv/Kconfig"
> +
> +source "drivers/gpu/drm/hisilicon/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 61766dec6a8d..60554832079c 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -74,3 +74,4 @@ obj-y			+= panel/
>   obj-y			+= bridge/
>   obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
>   obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
> +obj-y			+= hisilicon/
> diff --git a/drivers/gpu/drm/hisilicon/Kconfig b/drivers/gpu/drm/hisilicon/Kconfig
> new file mode 100644
> index 000000000000..558c61b1b8e8
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/Kconfig
> @@ -0,0 +1,5 @@
> +#
> +# hisilicon drm device configuration.
> +# Please keep this list sorted alphabetically
> +
> +source "drivers/gpu/drm/hisilicon/kirin/Kconfig"
> diff --git a/drivers/gpu/drm/hisilicon/Makefile b/drivers/gpu/drm/hisilicon/Makefile
> new file mode 100644
> index 000000000000..e3f6d493c996
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for hisilicon drm drivers.
> +# Please keep this list sorted alphabetically
> +
> +obj-$(CONFIG_DRM_HISI_KIRIN) += kirin/
> diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig b/drivers/gpu/drm/hisilicon/kirin/Kconfig
> new file mode 100644
> index 000000000000..3ac4b8edeac1
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
> @@ -0,0 +1,9 @@
> +config DRM_HISI_KIRIN
> +	tristate "DRM Support for Hisilicon Kirin series SoCs Platform"
> +	depends on DRM
> +	select DRM_KMS_HELPER
> +	select DRM_GEM_CMA_HELPER
> +	select DRM_KMS_CMA_HELPER
> +	help
> +	  Choose this option if you have a hisilicon Kirin chipsets(hi6220).
> +	  If M is selected the module will be called kirin-drm.
> diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile b/drivers/gpu/drm/hisilicon/kirin/Makefile
> new file mode 100644
> index 000000000000..cb346de47d48
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
> @@ -0,0 +1,3 @@
> +kirin-drm-y := kirin_drm_drv.o
> +
> +obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> new file mode 100644
> index 000000000000..789ebd1f5922
> --- /dev/null
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -0,0 +1,321 @@
> +/*
> + * Hisilicon Kirin SoCs drm master driver
> + *
> + * Copyright (c) 2016 Linaro Limited.
> + * Copyright (c) 2014-2016 Hisilicon Limited.
> + *
> + * Author:
> + *	Xinliang Liu <z.liuxinliang at hisilicon.com>
> + *	Xinliang Liu <xinliang.liu at linaro.org>
> + *	Xinwei Kong <kong.kongxinwei at hisilicon.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.
> + *
> + */
> +
> +#include <linux/of_platform.h>
> +#include <linux/component.h>
> +#include <linux/of_graph.h>
> +
> +#include <drm/drmP.h>
> +#include <drm/drm_gem_cma_helper.h>
> +#include <drm/drm_fb_cma_helper.h>
> +#include <drm/drm_atomic_helper.h>
> +
> +#include "kirin_drm_drv.h"
> +
> +static struct kirin_dc_ops *dc_ops;
> +
> +static int kirin_drm_kms_cleanup(struct drm_device *dev)
> +{
> +	dc_ops->cleanup(dev);
> +	drm_mode_config_cleanup(dev);
> +
> +	return 0;
> +}
> +
> +static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
> +	.fb_create = drm_fb_cma_create,
> +	.atomic_check = drm_atomic_helper_check,
> +	.atomic_commit = drm_atomic_helper_commit,
> +};
> +
> +static void kirin_drm_mode_config_init(struct drm_device *dev)
> +{
> +	dev->mode_config.min_width = 0;
> +	dev->mode_config.min_height = 0;
> +
> +	dev->mode_config.max_width = 2048;
> +	dev->mode_config.max_height = 2048;
> +
> +	dev->mode_config.funcs = &kirin_drm_mode_config_funcs;
> +}
> +
> +static int kirin_drm_kms_init(struct drm_device *dev)
> +{
> +	int ret;
> +
> +	dev_set_drvdata(dev->dev, dev);
> +
> +	/* dev->mode_config initialization */
> +	drm_mode_config_init(dev);
> +	kirin_drm_mode_config_init(dev);
> +
> +	/* display controller init */
> +	ret = dc_ops->init(dev);
> +	if (ret)
> +		goto err_mode_config_cleanup;
> +
> +	/* bind and init sub drivers */
> +	ret = component_bind_all(dev->dev, dev);
> +	if (ret) {
> +		DRM_ERROR("failed to bind all component.\n");
> +		goto err_dc_cleanup;
> +	}
> +
> +	/* reset all the states of crtc/plane/encoder/connector */
> +	drm_mode_config_reset(dev);
> +
> +	return 0;
> +
> +err_dc_cleanup:
> +	dc_ops->cleanup(dev);
> +err_mode_config_cleanup:
> +	drm_mode_config_cleanup(dev);
> +
> +	return ret;
> +}
> +
> +static const struct file_operations kirin_drm_fops = {
> +	.owner		= THIS_MODULE,
> +	.open		= drm_open,
> +	.release	= drm_release,
> +	.unlocked_ioctl	= drm_ioctl,
> +#ifdef CONFIG_COMPAT
> +	.compat_ioctl	= drm_compat_ioctl,
> +#endif
> +	.poll		= drm_poll,
> +	.read		= drm_read,
> +	.llseek		= no_llseek,
> +	.mmap		= drm_gem_cma_mmap,
> +};
> +
> +static int kirin_gem_cma_dumb_create(struct drm_file *file,
> +				     struct drm_device *dev,
> +				     struct drm_mode_create_dumb *args)
> +{
> +	return drm_gem_cma_dumb_create_internal(file, dev, args);
> +}
> +
> +static struct drm_driver kirin_drm_driver = {
> +	.driver_features	= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
> +				  DRIVER_ATOMIC,
> +	.fops			= &kirin_drm_fops,
> +	.set_busid		= drm_platform_set_busid,
> +
> +	.gem_free_object	= drm_gem_cma_free_object,
> +	.gem_vm_ops		= &drm_gem_cma_vm_ops,
> +	.dumb_create		= kirin_gem_cma_dumb_create,
> +	.dumb_map_offset	= drm_gem_cma_dumb_map_offset,
> +	.dumb_destroy		= drm_gem_dumb_destroy,
> +
> +	.prime_handle_to_fd	= drm_gem_prime_handle_to_fd,
> +	.prime_fd_to_handle	= drm_gem_prime_fd_to_handle,
> +	.gem_prime_export	= drm_gem_prime_export,
> +	.gem_prime_import	= drm_gem_prime_import,
> +	.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> +	.gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> +	.gem_prime_vmap		= drm_gem_cma_prime_vmap,
> +	.gem_prime_vunmap	= drm_gem_cma_prime_vunmap,
> +	.gem_prime_mmap		= drm_gem_cma_prime_mmap,
> +
> +	.name			= "kirin",
> +	.desc			= "Hisilicon Kirin SoCs' DRM Driver",
> +	.date			= "20150718",
> +	.major			= 1,
> +	.minor			= 0,
> +};
> +
> +static int compare_of(struct device *dev, void *data)
> +{
> +	return dev->of_node == data;
> +}
> +
> +static int kirin_drm_connectors_register(struct drm_device *dev)
> +{
> +	struct drm_connector *connector;
> +	struct drm_connector *failed_connector;
> +	int ret;
> +

This access needs to be protected by the dev->mode_config.mutex

> +	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {

The above can be replaced with:

drm_for_each_connector(connector, dev) {

> +		ret = drm_connector_register(connector);
> +		if (ret) {
> +			failed_connector = connector;
> +			goto err;
> +		}
> +	}
> +
> +	return 0;
> +
> +err:
> +	list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> +		if (failed_connector == connector)
> +			break;
> +		drm_connector_unregister(connector);
> +	}

Same points as above.

> +
> +	return ret;
> +}
> +
> +static int kirin_drm_bind(struct device *dev)
> +{
> +	struct drm_driver *driver = &kirin_drm_driver;
> +	struct drm_device *drm_dev;
> +	int ret;
> +
> +	drm_dev = drm_dev_alloc(driver, dev);
> +	if (!drm_dev)
> +		return -ENOMEM;
> +
> +	drm_dev->platformdev = to_platform_device(dev);
> +
> +	ret = kirin_drm_kms_init(drm_dev);
> +	if (ret)
> +		goto err_drm_dev_unref;
> +
> +	ret = drm_dev_register(drm_dev, 0);
> +	if (ret)
> +		goto err_kms_cleanup;
> +
> +	/* connectors should be registered after drm device register */
> +	ret = kirin_drm_connectors_register(drm_dev);
> +	if (ret)
> +		goto err_drm_dev_unregister;
> +
> +	DRM_INFO("Initialized %s %d.%d.%d %s on minor %d\n",
> +		 driver->name, driver->major, driver->minor, driver->patchlevel,
> +		 driver->date, drm_dev->primary->index);
> +
> +	return 0;
> +
> +err_drm_dev_unregister:
> +	drm_dev_unregister(drm_dev);
> +err_kms_cleanup:
> +	kirin_drm_kms_cleanup(drm_dev);
> +err_drm_dev_unref:
> +	drm_dev_unref(drm_dev);
> +
> +	return ret;
> +}
> +
> +static void kirin_drm_unbind(struct device *dev)
> +{
> +	drm_put_dev(dev_get_drvdata(dev));
> +}
> +
> +static const struct component_master_ops kirin_drm_ops = {
> +	.bind = kirin_drm_bind,
> +	.unbind = kirin_drm_unbind,
> +};
> +
> +static const struct of_device_id kirin_drm_dt_ids[] = {
> +	{ /* end node */ },
> +};
> +MODULE_DEVICE_TABLE(of, kirin_drm_dt_ids);
> +
> +static int kirin_get_dc_ops(struct device_node *np)
> +{
> +	const struct of_device_id *match_id;
> +
> +	match_id = of_match_node(kirin_drm_dt_ids, np);
> +	if (!match_id) {
> +		DRM_ERROR("failed to match dt id\n");
> +		return -EINVAL;
> +	}
> +
> +	dc_ops = (struct kirin_dc_ops *)match_id->data;
> +	if (!dc_ops) {
> +		DRM_ERROR("dt id data is null\n");
> +		return -EINVAL;
> +	}

We can use of_device_get_match_data to get the match data,
and move the kirin_drm_dt_ids table down where the driver is
defined.

<snip>

Thanks,
Archit

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation


From thomas.petazzoni at free-electrons.com  Fri Feb 26 00:55:10 2016
From: thomas.petazzoni at free-electrons.com (Thomas Petazzoni)
Date: Fri, 26 Feb 2016 09:55:10 +0100
Subject: [PATCH 1/3] dt-bindings: arm/marvell: ABI unstability warning
 about Marvell 7K/8K
In-Reply-To: <20160225175603.GD10593@leverpostej>
References: <1456327007-31008-1-git-send-email-thomas.petazzoni@free-electrons.com>
 <1456327007-31008-2-git-send-email-thomas.petazzoni@free-electrons.com>
 <20160224172545.GC9137@leverpostej>
 <20160224211045.379352d3@free-electrons.com>
 <CAL_JsqLevrujSeYNBvSJA-5T0Ho8y7c0fKid7QvVm8LLvYLotw@mail.gmail.com>
 <20160225090927.13492cfb@free-electrons.com>
 <20160225161642.GC10593@leverpostej>
 <20160225173811.23be5b05@free-electrons.com>
 <20160225175603.GD10593@leverpostej>
Message-ID: <20160226095510.28a056be@free-electrons.com>

Hello Mark,

On Thu, 25 Feb 2016 17:56:04 +0000, Mark Rutland wrote:

> > Hence, even when the support for a SoC is being done in collaboration
> > with the SoC vendor, we don't always have a nice full datasheet that
> > tells us what all the registers are doing and how they are organized.
> > We discover things as we go.
> 
> So as and when you believe you need to break a binding, we can have a
> discussion on that case-by-case basis.
> 
> That's different to stating that the usual rules don't apply at all,
> which is black-and-white stand I'm referring to.

This would at least be a somewhat reasonable compromise, if that's your
preference.

However, my proposal had the advantage that potential users of the
platform are *aware* that the DT bindings are in-flux and that they may
change.

With your proposal, there is no such statement, even if we reserve the
right, on case-by-case basis to have a discussion about potentially
breaking the DT bindings.

But if that's OK for you, I'm happy with that as well.

> > Instead, what we want is to submit the basic stuff early, and then
> > progressively build on top of this basic stuff by merging more and more
> > features. This way:
> > 
> >  * We don't have to pile up hundreds of out of tree patches;
> 
> Then _support_ what you have upstreamed already. Either it's ready to be
> supported or it is not. If it is, there's no need for DT breakage, and
> if it isn't, then it's not ready for mainline. That's all this boils
> down to. 
> 
> If it must go in, then it must be supported.

Supporting something has absolutely nothing to do with keeping the DT
bindings unchanged. Supporting something means that I'll watch for
build failures and fix them, I'll watch for bug reports and act on
them, I'll watch on subsystem/infrastructure changes and change my
driver code accordingly. This is what supporting means.

> >  * We have a support in the mainline kernel that is progressively
> >    getting better as we enable more and more feature. We can show that
> >    4.6 has this small set of features, 4.7 has this slightly extended
> >    set of features supported, and so on.
> 
> It's not "progressively getting better", if DTBs are arbitrarily getting
> broken.
> 
> It's possible to incrementally add support without having to break
> existing DTBs.

Except if:

 1/ Your final production chip has some differences from your test chip
    which do affect the DT representation. The kernel community has
    asked for years that HW vendors start submitting code as early as
    possible, and they are now doing it. In order to do it as soon as
    possible, they start doing it based on test chips, which may be
    slightly different from the final chips. The kernel community
    should then understand this and be a bit flexible in that the
    kernel support might change a bit, as the HW might change a bit
    before it reaches production.

 2/ You have no documentation for your HW, and you're simply
    discovering how it works progressively. Look at all the folks who
    write nice upstream code solely based on crappy vendor BSPs, with
    no datasheet whatsoever. Do you think they can sanely have a good
    overall understanding of the HW from day 1 ? Certainly not. They
    will discover that such or such HW block is not only a timer, but
    also a watchdog. That this other HW block not only contains
    clocks, but reset and pinctrl lines.

I don't like to self-promote my own stuff, but I think you should read
the slides of my talk "Device Tree as a stable ABI: a fairy
tale" (http://free-electrons.com/pub/conferences/2015/elc/petazzoni-dt-as-stable-abi-fairy-tale/petazzoni-dt-as-stable-abi-fairy-tale.pdf).
I will clearly not suggest you to watch the video recording, as I don't
want you to suffer from one hour of my terrible English accent.

> > We are perfectly fine with maintaining *code*. And we have been doing
> > so for several years on Marvell platforms: caring about older
> > platforms, converting old legacy code and legacy platforms to the
> > Device Tree, etc.
> 
> The parsing and handling of the existing binding is code, which you are
> arguing you do not need to support.

So you like to have tons and tons of essentially dead code to parse old
versions of DT bindings?

What really strikes me here is that the Linux kernel always had a
version strong position, detailed in
Documentation/stable_api_nonsense.txt, that the kernel developers don't
want to maintain a stable API for kernel modules, because keeping old
APIs around means keeping old code, that isn't tested, confuses people,
etc. Read the file if you've never done so.

And now, for something pretty much as complicated (if not more) as the
kernel module API, the DT bindings, you want to do *exactly* what this
stable_api_nonsense.txt says we shouldn't do ?

> > What we don't want to commit to is to maintain the DT stability
> > *before* the support for a given device is sufficiently stable/sane.
> 
> I do not follow what you mean by support being *not sane*. If it isn't
> sane, why was it merged?
> 
> If it was previously considered sane, and the code was considered
> supportable, why is it necessary to break a DT that it supported?

See above: the HW has changed, or the HW is not working as it was
originally understood when the DT binding was initially designed.

> > Why are you talking about "illusion" of support ? Sorry, but with
> > unstable DT bindings, as long as you use the DT that comes with the
> > kernel sources, everything works perfectly fine, and is perfectly
> > supported.
> 
> A few examples:
> 
> * Distro installation (in the absence of a stable DT and a consistent
>   boot environment, you have no idea how to get a kernel up and
>   running). Either your user has to be intimately familiar with the
>   platform, or the distro needs a separate release for each and every
>   platform.

Irrelevant: the distro shall just ship with all the Device Trees for
all supported platforms, and that's it. Exactly like the x86 kernels
shipped by distros have essentially all kernel drivers enabled in order
to be able to have a kernel that works on all platforms.

> * Distro maintenance. I just upgraded to a point-release kernel and now
>   have to pull down the DTBs. That required the distro to _somehow_
>   identify the relevant DTBs, how to install this in the correct
>   location such that the firmware and/or bootloader can pick it up, etc.

Same, irrelevant: the DTB comes with the distro kernel package, and like
kernel modules, they are installed in a per-kernel version directory.

> * Other developers tracking down problems that inevitable crop up on the
>   platform, who now have to jump through the hoops above. As the DTBs
>   change, so may the user-facing elements and/or kernel behaviour, so
>   bisecting is extremely painful (though admittedly possible).

Exactly like they have to change their kernel modules so that they are
compatible with the kernel version they run.

> * Portable hypervisors, bootloaders, or other system-level software
>   can't add any (DTB-aware) support for a platform until the kernel
>   support is considered "sane" per your argument above. That time is an
>   arbitrary unknown in the future (which may be at infinity), so they
>   are either indefinitely delayed or end up having attempt to have
>   stable support for a variety of unstable bindings anyway, which may or
>   may not be possible depending on how bindings got broken.

Those hypervisors, bootloaders or system-level should not hardcode the
platform DTB, but simply use the one that is provided together with the
kernel.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


From p.zabel at pengutronix.de  Fri Feb 26 00:55:55 2016
From: p.zabel at pengutronix.de (Philipp Zabel)
Date: Fri, 26 Feb 2016 09:55:55 +0100
Subject: [PATCH v10 0/5] MT8173 IOMMU SUPPORT
In-Reply-To: <20160225155007.GA19092@8bytes.org>
References: <1456161651-6136-1-git-send-email-yong.wu@mediatek.com>
 <20160225155007.GA19092@8bytes.org>
Message-ID: <1456476955.3383.21.camel@pengutronix.de>

Hi Joerg,

Am Donnerstag, den 25.02.2016, 16:50 +0100 schrieb Joerg Roedel:
> On Tue, Feb 23, 2016 at 01:20:46AM +0800, Yong Wu wrote:
> > Yong Wu (5):
> >   dt-bindings: iommu: Add binding for mediatek IOMMU
> >   dt-bindings: mediatek: Add smi dts binding
> >   memory: mediatek: Add SMI driver
> >   iommu/mediatek: Add mt8173 IOMMU driver
> >   dts: mt8173: Add iommu/smi nodes for mt8173
> > 
> >  .../devicetree/bindings/iommu/mediatek,iommu.txt   |  68 ++
> >  .../memory-controllers/mediatek,smi-common.txt     |  24 +
> >  .../memory-controllers/mediatek,smi-larb.txt       |  25 +
> >  arch/arm64/boot/dts/mediatek/mt8173.dtsi           |  81 +++
> >  drivers/iommu/Kconfig                              |  16 +
> >  drivers/iommu/Makefile                             |   1 +
> >  drivers/iommu/mtk_iommu.c                          | 737 +++++++++++++++++++++
> >  drivers/memory/Kconfig                             |   8 +
> >  drivers/memory/Makefile                            |   1 +
> >  drivers/memory/mtk-smi.c                           | 273 ++++++++
> >  include/dt-bindings/memory/mt8173-larb-port.h      | 111 ++++
> >  include/soc/mediatek/smi.h                         |  58 ++
> >  12 files changed, 1403 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> >  create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
> >  create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> >  create mode 100644 drivers/iommu/mtk_iommu.c
> >  create mode 100644 drivers/memory/mtk-smi.c
> >  create mode 100644 include/dt-bindings/memory/mt8173-larb-port.h
> >  create mode 100644 include/soc/mediatek/smi.h
> 
> Applied all, thanks.

Do you have a stable branch that I could base the mediatek-drm patches
on and that I may include in a pull request to be merged via drm-next?

regards
Philipp



From hs.liao at mediatek.com  Fri Feb 26 01:00:30 2016
From: hs.liao at mediatek.com (Horng-Shyang Liao)
Date: Fri, 26 Feb 2016 17:00:30 +0800
Subject: [RFC 3/3] CMDQ: Mediatek CMDQ driver
In-Reply-To: <CAGS+omABD93f3X0pfiFgaxa9Lob2txkJfUUomUvs+hiRkxSuHw@mail.gmail.com>
References: <8A0FDEEF9DBBD140A3857422D81DA20F867B19FD@mtkmbs01n1>
 <1454479333.11967.12.camel@mtksdaap41>
 <CAGS+omABD93f3X0pfiFgaxa9Lob2txkJfUUomUvs+hiRkxSuHw@mail.gmail.com>
Message-ID: <1456477230.17841.2.camel@mtksdaap41>

On Wed, 2016-02-03 at 14:40 +0800, Daniel Kurtz wrote:
> > Hi Dan,
> >
> > Thanks for your comment.
> > This solution looks good to me.
> > I will change it as your suggestion.
> >
> > But, I have a question about 'mask out the provided *device virtual*
> > address'.
> > Are lower 16-bits (or 24-bits for JUMP op) of device virtual address the
> > same as device physical address?
> 
> I'm not sure.  But I doubt it we can rely on this.
> My guess would be that the ioremap only preserves the lower 12 bits
> (4k page size).
> 
> > If not, we still need to pass in physical address into CMDQ driver.
> 
> Or, instead of the iommu/slot approach, we can just provide a
> registration function for the gce driver.
> Each gce consumer could then have a simple gce node, with no slot/address:
> 
>   mediatek,gce = <&gce>;
> 
> Then on probe, the gce consumer could pass in its (struct device *) to
> gce_register_device().  gce_register_device() could then access the
> device's of_node to extract its physical address range, and look up
> its physical address in its table of per-soc of
> "device_address:gce_subsys_address" entries.  If the physical address
> is in a valid subsys ranges, the gce_register_device would cache the
> subsys address, and an offset in a (struct gce_consumer).
> gce_register_device() could then add this struct to a struct list_head
> of gce_consumers, and finally return a pointer to it back to the
> caller.
> 
> Later, the gce consumer could pass in ths (struct gce_consumer *) when
> make gce calls, along with the *offset* (not the physical address or
> virtual address) for the register that it wishes to access.  Then the
> gce driver can simply use the gce_consumer->subsys entry to create a
> gce address from the passed in offset.
> 
> This will keep the binding very simple, and would remove the need to
> convert from device virtual to physical addresses by the gce consumer,
> but require a little more per-gce-consumer setup.
> 
> -Dan

Hi Dan,

When I try to implement this comment, I realize the only benefit from
this comment is to wrap physical address.

Recall from my previous reply: gce address = subsys + valid low bits.
So, CMDQ driver still need to do "(Base + offset) & valid mask" to get
gce valid low bits.
Current implementation let display driver do "base + offset".
This comment just transfers this calculation from display driver to CMDQ
driver.

However, this comment will let CMDQ interface (behavior) become more
complicated, e.g. gce_register_device(), struct gce_consumer, and int
cmdq_rec_write(struct cmdq_rec *handle, u32 value, struct gce_consumer
*consumer, u32 offset)

Do you think it is worth to do this effort to wrap physical address?

Thanks,
HS Liao




From dhdang at apm.com  Fri Feb 26 01:04:29 2016
From: dhdang at apm.com (Duc Dang)
Date: Fri, 26 Feb 2016 01:04:29 -0800
Subject: [GIT PULL v2 2/2] arm64: X-Gene platforms DTS changes queued for v4.6
 - part2
Message-ID: <CADaLND==AshC-syR3Tm93bPqB-vEyO3=AY+pM5r_ohgr4n-nBw@mail.gmail.com>

Hi Arnd, Olof,

This is the second part of DT changes on X-Gene platforms for v4.6,
which enables mailbox driver for X-Gene v1 and X-Gene v2 platforms and
also enable SLIMpro Mailbox I2C driver (a client of the mailbox
driver) for both X-Gene v1 and v2 platforms.

"arm64: dts: apm: mailbox device tree node for APM X-Gene platform"
patch is the 3rd patch
(http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/apm?id=be9c09bcca039d6df9ec736989cdafc68c93fed4)
of the series "mailbox: Add APM X-Gene platform mailbox driver"
(https://lkml.org/lkml/2016/2/12/749), which was already in linux-next
since Feb-15.

"arm64: dts: apm: Mailbox device tree node for APM X-Gene v2 platform"
is the follow up patch to enable mailbox on X-Gene v2 platform.

The remaining 2 patches enable SLIMpro Mailbox I2C driver on X-Gene v1
and v2 platforms.

Regards,
Duc Dang.
------
The following changes since commit edf21f271024ec6adb93c7b4e6c1dc928b6a7250:

  arm64: dts: apm: Update GPIO to control power-off on X-Gene v2
platforms (2016-02-25 17:14:00 -0800)

are available in the git repository at:

  https://github.com/AppliedMicro/xgene-next.git tags/xgene-dts-for-v4.6-part2

for you to fetch changes up to 406f5940549e78fd7d4d41413a7ed3e611bccc4f:

  arm64: dts: apm: Add DT node for X-Gene v2 SLIMpro Mailbox I2C
Driver (2016-02-25 17:14:04 -0800)

----------------------------------------------------------------
Second part of X-Gene DT changes queued for v4.6

This patch set includes:
+ X-Gene v1 and v2 Mailbox DT nodes
+ X-Gene v1 and X-Gene v2 SLIMpro Mailbox
I2C driver DT nodes

----------------------------------------------------------------
Duc Dang (4):
      arm64: dts: apm: mailbox device tree node for APM X-Gene platform.
      arm64: dts: apm: Add DT node for X-Gene v1 SLIMpro Mailbox I2C Driver
      arm64: dts: apm: Mailbox device tree node for APM X-Gene v2 platform.
      arm64: dts: apm: Add DT node for X-Gene v2 SLIMpro Mailbox I2C Driver

 arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 19 +++++++++++++++++++
 arch/arm64/boot/dts/apm/apm-storm.dtsi     | 19 +++++++++++++++++++
 2 files changed, 38 insertions(+)


From alim.akhtar at samsung.com  Fri Feb 26 01:06:30 2016
From: alim.akhtar at samsung.com (Alim Akhtar)
Date: Fri, 26 Feb 2016 14:36:30 +0530
Subject: [PATCH v2] arm64: dts: Add tmu node for exynos7
Message-ID: <1456477590-4530-1-git-send-email-alim.akhtar@samsung.com>

This patch adds tmu node, related temprature sensor and triping
point data for Atlas cpu core found on exynos7 SoC.

Signed-off-by: Alim Akhtar <alim.akhtar at samsung.com>
---
Changes since v1:
* Addressed krzysztof's review comments.

 .../boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi   |   25 +++++++++
 .../arm64/boot/dts/exynos/exynos7-trip-points.dtsi |   54 ++++++++++++++++++++
 arch/arm64/boot/dts/exynos/exynos7.dtsi            |   20 ++++++++
 3 files changed, 99 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi

diff --git a/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
new file mode 100644
index 0000000..1d6dcf2
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos7-tmu-sensor-conf.dtsi
@@ -0,0 +1,25 @@
+/*
+ * Device tree sources for Exynos7 TMU sensor configuration
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.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.
+ *
+ */
+
+#include <dt-bindings/thermal/thermal_exynos.h>
+
+#thermal-sensor-cells = <0>;
+samsung,tmu_gain = <9>;
+samsung,tmu_reference_voltage = <17>;
+samsung,tmu_noise_cancel_mode = <4>;
+samsung,tmu_efuse_value = <75>;
+samsung,tmu_min_efuse_value = <15>;
+samsung,tmu_max_efuse_value = <100>;
+samsung,tmu_first_point_trim = <25>;
+samsung,tmu_second_point_trim = <85>;
+samsung,tmu_default_temp_offset = <50>;
+samsung,tmu_cal_type = <TYPE_ONE_POINT_TRIMMING>;
diff --git a/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
new file mode 100644
index 0000000..0623583
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos7-trip-points.dtsi
@@ -0,0 +1,54 @@
+/*
+ * Device tree sources for default Exynos7 thermal zone definition
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *		http://www.samsung.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.
+ *
+ */
+
+trips {
+	cpu-alert-0 {
+		temperature = <75000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-1 {
+		temperature = <80000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-2 {
+		temperature = <85000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-3 {
+		temperature = <90000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-4 {
+		temperature = <95000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-5 {
+		temperature = <100000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-alert-6 {
+		temperature = <110000>; /* millicelsius */
+		hysteresis = <10000>; /* millicelsius */
+		type = "passive";
+	};
+	cpu-crit-0 {
+		temperature = <115000>; /* millicelsius */
+		hysteresis = <0>; /* millicelsius */
+		type = "critical";
+	};
+};
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index c662f98..19de742 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -27,6 +27,7 @@
 		pinctrl6 = &pinctrl_fsys0;
 		pinctrl7 = &pinctrl_fsys1;
 		pinctrl8 = &pinctrl_bus1;
+		tmuctrl0 = &tmuctrl_0;
 	};
 
 	cpus {
@@ -538,6 +539,25 @@
 			clocks = <&clock_peric0 PCLK_PWM>;
 			clock-names = "timers";
 		};
+
+		tmuctrl_0: tmu at 10060000 {
+			compatible = "samsung,exynos7-tmu";
+			reg = <0x10060000 0x200>;
+			interrupts = <0 108 0>;
+			clocks = <&clock_peris PCLK_TMU>,
+				 <&clock_peris SCLK_TMU>;
+			clock-names = "tmu_apbif", "tmu_sclk";
+			#include "exynos7-tmu-sensor-conf.dtsi"
+		};
+
+		thermal-zones {
+			atlas_thermal: cluster0-thermal {
+				polling-delay-passive = <0>; /* milliseconds */
+				polling-delay = <0>; /* milliseconds */
+				thermal-sensors = <&tmuctrl_0>;
+				#include "exynos7-trip-points.dtsi"
+			};
+		};
 	};
 };
 
-- 
1.7.10.4



From jonathanh at nvidia.com  Fri Feb 26 01:12:15 2016
From: jonathanh at nvidia.com (Jon Hunter)
Date: Fri, 26 Feb 2016 09:12:15 +0000
Subject: [PATCH V2] ARM64: tegra: Add support for Google Pixel C
In-Reply-To: <CAL1qeaHVuvwTkctEMo6TFggPPgqaQZDnKZGYn1QRUROpJ9Dhrw@mail.gmail.com>
References: <1454949199-27050-1-git-send-email-jonathanh@nvidia.com>
 <CAL1qeaHVuvwTkctEMo6TFggPPgqaQZDnKZGYn1QRUROpJ9Dhrw@mail.gmail.com>
Message-ID: <56D016EF.1000404@nvidia.com>


On 25/02/16 21:07, Andrew Bresticker wrote:
> Jon,
> 
> On Mon, Feb 8, 2016 at 8:33 AM, Jon Hunter <jonathanh at nvidia.com> wrote:
>> Add initial device-tree support for Google Pixel C (a.k.a. Smaug) based
>> upon Tegra210 SoC with 3 GiB of LPDDR4 RAM.
>>
>> Signed-off-by: Jon Hunter <jonathanh at nvidia.com>
> 
> Reviewed-by: Andrew Bresticker <abrestic at chromium.org>
> 
> ... and I booted up my Smaug with v4.5-rc5 + this patch, so:
> 
> Tested-by: Andrew Bresticker <abrestic at chromium.org>

Thanks. There is a V3 of this patch [0]. The main difference is that it
enables all 4 CPUs. Care of test/ack this version?

Cheers
Jon

[0] http://marc.info/?l=linux-arm-kernel&m=145502094332480&w=4


From xinliang.liu at linaro.org  Fri Feb 26 01:14:38 2016
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri, 26 Feb 2016 17:14:38 +0800
Subject: [PATCH v6 02/11] drm/hisilicon: Add hisilicon kirin drm master
 driver
In-Reply-To: <56D012BA.9000509@codeaurora.org>
References: <1456476028-36880-1-git-send-email-xinliang.liu@linaro.org>
 <1456476028-36880-3-git-send-email-xinliang.liu@linaro.org>
 <56D012BA.9000509@codeaurora.org>
Message-ID: <CAGd==0611feQcgMb3KTt_fgyo-2+mu3y_0AUvPwRBppvuKkE8g@mail.gmail.com>

Hi,

On 26 February 2016 at 16:54, Archit Taneja <architt at codeaurora.org> wrote:
> Hi,
>
> I had some minor comments. Sorry about sharing this late. Otherwise,
> the looks good to me.

Hi Archit,  you are welcome :-)
Thanks for review again.

>
>
> On 02/26/2016 02:10 PM, Xinliang Liu wrote:
>>
>> Add kirin DRM master driver for hi6220 SoC which used in HiKey board.
>> Add dumb buffer feature.
>> Add prime dmabuf feature.
>>
>> v6: None.
>> v5: None.
>> v4: None.
>> v3:
>> - Move and rename all the files to kirin sub-directory.
>>    So that we could separate different seires SoCs' driver.
>> - Replace drm_platform_init, load, unload implementation.
>> v2:
>> - Remove abtraction layer.
>>
>> Signed-off-by: Xinliang Liu <xinliang.liu at linaro.org>
>> ---
>>   drivers/gpu/drm/Kconfig                         |   2 +
>>   drivers/gpu/drm/Makefile                        |   1 +
>>   drivers/gpu/drm/hisilicon/Kconfig               |   5 +
>>   drivers/gpu/drm/hisilicon/Makefile              |   5 +
>>   drivers/gpu/drm/hisilicon/kirin/Kconfig         |   9 +
>>   drivers/gpu/drm/hisilicon/kirin/Makefile        |   3 +
>>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 321
>> ++++++++++++++++++++++++
>>   drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  20 ++
>>   8 files changed, 366 insertions(+)
>>   create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
>>   create mode 100644 drivers/gpu/drm/hisilicon/Makefile
>>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
>>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
>>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>>   create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index b50ae60f5f50..f5c5656e2547 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -277,3 +277,5 @@ source "drivers/gpu/drm/imx/Kconfig"
>>   source "drivers/gpu/drm/vc4/Kconfig"
>>
>>   source "drivers/gpu/drm/etnaviv/Kconfig"
>> +
>> +source "drivers/gpu/drm/hisilicon/Kconfig"
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 61766dec6a8d..60554832079c 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -74,3 +74,4 @@ obj-y                 += panel/
>>   obj-y                 += bridge/
>>   obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
>>   obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
>> +obj-y                  += hisilicon/
>> diff --git a/drivers/gpu/drm/hisilicon/Kconfig
>> b/drivers/gpu/drm/hisilicon/Kconfig
>> new file mode 100644
>> index 000000000000..558c61b1b8e8
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/Kconfig
>> @@ -0,0 +1,5 @@
>> +#
>> +# hisilicon drm device configuration.
>> +# Please keep this list sorted alphabetically
>> +
>> +source "drivers/gpu/drm/hisilicon/kirin/Kconfig"
>> diff --git a/drivers/gpu/drm/hisilicon/Makefile
>> b/drivers/gpu/drm/hisilicon/Makefile
>> new file mode 100644
>> index 000000000000..e3f6d493c996
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/Makefile
>> @@ -0,0 +1,5 @@
>> +#
>> +# Makefile for hisilicon drm drivers.
>> +# Please keep this list sorted alphabetically
>> +
>> +obj-$(CONFIG_DRM_HISI_KIRIN) += kirin/
>> diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig
>> b/drivers/gpu/drm/hisilicon/kirin/Kconfig
>> new file mode 100644
>> index 000000000000..3ac4b8edeac1
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
>> @@ -0,0 +1,9 @@
>> +config DRM_HISI_KIRIN
>> +       tristate "DRM Support for Hisilicon Kirin series SoCs Platform"
>> +       depends on DRM
>> +       select DRM_KMS_HELPER
>> +       select DRM_GEM_CMA_HELPER
>> +       select DRM_KMS_CMA_HELPER
>> +       help
>> +         Choose this option if you have a hisilicon Kirin
>> chipsets(hi6220).
>> +         If M is selected the module will be called kirin-drm.
>> diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile
>> b/drivers/gpu/drm/hisilicon/kirin/Makefile
>> new file mode 100644
>> index 000000000000..cb346de47d48
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
>> @@ -0,0 +1,3 @@
>> +kirin-drm-y := kirin_drm_drv.o
>> +
>> +obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
>> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> new file mode 100644
>> index 000000000000..789ebd1f5922
>> --- /dev/null
>> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> @@ -0,0 +1,321 @@
>> +/*
>> + * Hisilicon Kirin SoCs drm master driver
>> + *
>> + * Copyright (c) 2016 Linaro Limited.
>> + * Copyright (c) 2014-2016 Hisilicon Limited.
>> + *
>> + * Author:
>> + *     Xinliang Liu <z.liuxinliang at hisilicon.com>
>> + *     Xinliang Liu <xinliang.liu at linaro.org>
>> + *     Xinwei Kong <kong.kongxinwei at hisilicon.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.
>> + *
>> + */
>> +
>> +#include <linux/of_platform.h>
>> +#include <linux/component.h>
>> +#include <linux/of_graph.h>
>> +
>> +#include <drm/drmP.h>
>> +#include <drm/drm_gem_cma_helper.h>
>> +#include <drm/drm_fb_cma_helper.h>
>> +#include <drm/drm_atomic_helper.h>
>> +
>> +#include "kirin_drm_drv.h"
>> +
>> +static struct kirin_dc_ops *dc_ops;
>> +
>> +static int kirin_drm_kms_cleanup(struct drm_device *dev)
>> +{
>> +       dc_ops->cleanup(dev);
>> +       drm_mode_config_cleanup(dev);
>> +
>> +       return 0;
>> +}
>> +
>> +static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
>> +       .fb_create = drm_fb_cma_create,
>> +       .atomic_check = drm_atomic_helper_check,
>> +       .atomic_commit = drm_atomic_helper_commit,
>> +};
>> +
>> +static void kirin_drm_mode_config_init(struct drm_device *dev)
>> +{
>> +       dev->mode_config.min_width = 0;
>> +       dev->mode_config.min_height = 0;
>> +
>> +       dev->mode_config.max_width = 2048;
>> +       dev->mode_config.max_height = 2048;
>> +
>> +       dev->mode_config.funcs = &kirin_drm_mode_config_funcs;
>> +}
>> +
>> +static int kirin_drm_kms_init(struct drm_device *dev)
>> +{
>> +       int ret;
>> +
>> +       dev_set_drvdata(dev->dev, dev);
>> +
>> +       /* dev->mode_config initialization */
>> +       drm_mode_config_init(dev);
>> +       kirin_drm_mode_config_init(dev);
>> +
>> +       /* display controller init */
>> +       ret = dc_ops->init(dev);
>> +       if (ret)
>> +               goto err_mode_config_cleanup;
>> +
>> +       /* bind and init sub drivers */
>> +       ret = component_bind_all(dev->dev, dev);
>> +       if (ret) {
>> +               DRM_ERROR("failed to bind all component.\n");
>> +               goto err_dc_cleanup;
>> +       }
>> +
>> +       /* reset all the states of crtc/plane/encoder/connector */
>> +       drm_mode_config_reset(dev);
>> +
>> +       return 0;
>> +
>> +err_dc_cleanup:
>> +       dc_ops->cleanup(dev);
>> +err_mode_config_cleanup:
>> +       drm_mode_config_cleanup(dev);
>> +
>> +       return ret;
>> +}
>> +
>> +static const struct file_operations kirin_drm_fops = {
>> +       .owner          = THIS_MODULE,
>> +       .open           = drm_open,
>> +       .release        = drm_release,
>> +       .unlocked_ioctl = drm_ioctl,
>> +#ifdef CONFIG_COMPAT
>> +       .compat_ioctl   = drm_compat_ioctl,
>> +#endif
>> +       .poll           = drm_poll,
>> +       .read           = drm_read,
>> +       .llseek         = no_llseek,
>> +       .mmap           = drm_gem_cma_mmap,
>> +};
>> +
>> +static int kirin_gem_cma_dumb_create(struct drm_file *file,
>> +                                    struct drm_device *dev,
>> +                                    struct drm_mode_create_dumb *args)
>> +{
>> +       return drm_gem_cma_dumb_create_internal(file, dev, args);
>> +}
>> +
>> +static struct drm_driver kirin_drm_driver = {
>> +       .driver_features        = DRIVER_GEM | DRIVER_MODESET |
>> DRIVER_PRIME |
>> +                                 DRIVER_ATOMIC,
>> +       .fops                   = &kirin_drm_fops,
>> +       .set_busid              = drm_platform_set_busid,
>> +
>> +       .gem_free_object        = drm_gem_cma_free_object,
>> +       .gem_vm_ops             = &drm_gem_cma_vm_ops,
>> +       .dumb_create            = kirin_gem_cma_dumb_create,
>> +       .dumb_map_offset        = drm_gem_cma_dumb_map_offset,
>> +       .dumb_destroy           = drm_gem_dumb_destroy,
>> +
>> +       .prime_handle_to_fd     = drm_gem_prime_handle_to_fd,
>> +       .prime_fd_to_handle     = drm_gem_prime_fd_to_handle,
>> +       .gem_prime_export       = drm_gem_prime_export,
>> +       .gem_prime_import       = drm_gem_prime_import,
>> +       .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
>> +       .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
>> +       .gem_prime_vmap         = drm_gem_cma_prime_vmap,
>> +       .gem_prime_vunmap       = drm_gem_cma_prime_vunmap,
>> +       .gem_prime_mmap         = drm_gem_cma_prime_mmap,
>> +
>> +       .name                   = "kirin",
>> +       .desc                   = "Hisilicon Kirin SoCs' DRM Driver",
>> +       .date                   = "20150718",
>> +       .major                  = 1,
>> +       .minor                  = 0,
>> +};
>> +
>> +static int compare_of(struct device *dev, void *data)
>> +{
>> +       return dev->of_node == data;
>> +}
>> +
>> +static int kirin_drm_connectors_register(struct drm_device *dev)
>> +{
>> +       struct drm_connector *connector;
>> +       struct drm_connector *failed_connector;
>> +       int ret;
>> +
>
>
> This access needs to be protected by the dev->mode_config.mutex

thanks for pointing out this. will fix in next version.

>
>> +       list_for_each_entry(connector, &dev->mode_config.connector_list,
>> head) {
>
>
> The above can be replaced with:
>
> drm_for_each_connector(connector, dev) {

Great, this makes things more clear. will change in next version.

>
>> +               ret = drm_connector_register(connector);
>> +               if (ret) {
>> +                       failed_connector = connector;
>> +                       goto err;
>> +               }
>> +       }
>> +
>> +       return 0;
>> +
>> +err:
>> +       list_for_each_entry(connector, &dev->mode_config.connector_list,
>> head) {
>> +               if (failed_connector == connector)
>> +                       break;
>> +               drm_connector_unregister(connector);
>> +       }
>
>
> Same points as above.
>
>
>> +
>> +       return ret;
>> +}
>> +
>> +static int kirin_drm_bind(struct device *dev)
>> +{
>> +       struct drm_driver *driver = &kirin_drm_driver;
>> +       struct drm_device *drm_dev;
>> +       int ret;
>> +
>> +       drm_dev = drm_dev_alloc(driver, dev);
>> +       if (!drm_dev)
>> +               return -ENOMEM;
>> +
>> +       drm_dev->platformdev = to_platform_device(dev);
>> +
>> +       ret = kirin_drm_kms_init(drm_dev);
>> +       if (ret)
>> +               goto err_drm_dev_unref;
>> +
>> +       ret = drm_dev_register(drm_dev, 0);
>> +       if (ret)
>> +               goto err_kms_cleanup;
>> +
>> +       /* connectors should be registered after drm device register */
>> +       ret = kirin_drm_connectors_register(drm_dev);
>> +       if (ret)
>> +               goto err_drm_dev_unregister;
>> +
>> +       DRM_INFO("Initialized %s %d.%d.%d %s on minor %d\n",
>> +                driver->name, driver->major, driver->minor,
>> driver->patchlevel,
>> +                driver->date, drm_dev->primary->index);
>> +
>> +       return 0;
>> +
>> +err_drm_dev_unregister:
>> +       drm_dev_unregister(drm_dev);
>> +err_kms_cleanup:
>> +       kirin_drm_kms_cleanup(drm_dev);
>> +err_drm_dev_unref:
>> +       drm_dev_unref(drm_dev);
>> +
>> +       return ret;
>> +}
>> +
>> +static void kirin_drm_unbind(struct device *dev)
>> +{
>> +       drm_put_dev(dev_get_drvdata(dev));
>> +}
>> +
>> +static const struct component_master_ops kirin_drm_ops = {
>> +       .bind = kirin_drm_bind,
>> +       .unbind = kirin_drm_unbind,
>> +};
>> +
>> +static const struct of_device_id kirin_drm_dt_ids[] = {
>> +       { /* end node */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, kirin_drm_dt_ids);
>> +
>> +static int kirin_get_dc_ops(struct device_node *np)
>> +{
>> +       const struct of_device_id *match_id;
>> +
>> +       match_id = of_match_node(kirin_drm_dt_ids, np);
>> +       if (!match_id) {
>> +               DRM_ERROR("failed to match dt id\n");
>> +               return -EINVAL;
>> +       }
>> +
>> +       dc_ops = (struct kirin_dc_ops *)match_id->data;
>> +       if (!dc_ops) {
>> +               DRM_ERROR("dt id data is null\n");
>> +               return -EINVAL;
>> +       }
>
>
> We can use of_device_get_match_data to get the match data,
> and move the kirin_drm_dt_ids table down where the driver is
> defined.
>

Same, it is better to do like you said. will change in next version.

Thanks,
-xinliang

> <snip>
>
> Thanks,
> Archit
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation


From jszhang at marvell.com  Fri Feb 26 01:43:15 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Fri, 26 Feb 2016 17:43:15 +0800
Subject: [PATCH 8/9] clockevents/drivers/arm_global_timer: Implement
 ->set_state_oneshot_stopped()
In-Reply-To: <1456407438-6131-8-git-send-email-daniel.lezcano@linaro.org>
References: <56CF00F6.9010301@linaro.org>
 <1456407438-6131-1-git-send-email-daniel.lezcano@linaro.org>
 <1456407438-6131-8-git-send-email-daniel.lezcano@linaro.org>
Message-ID: <20160226174315.392a2b6d@xhacker>

Dear Daniel, Viresh,

On Thu, 25 Feb 2016 14:37:16 +0100 Daniel Lezcano wrote:

> From: Viresh Kumar <viresh.kumar at linaro.org>
> 
> set_state_oneshot_stopped() is called by the clkevt core, when the next
> event is required at an expiry time of 'KTIME_MAX'. This normally
> happens with NO_HZ_{IDLE|FULL} in both LOWRES/HIGHRES modes.
> 
> This patch makes the clockevent device to stop on such an event, to
> avoid spurious interrupts, as explained by: commit 8fff52fd5093
> ("clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state").

Inspired by this commit, I think dw_apb_timer also needs similar patch because
it only supports PERIODIC mode and the driver emulate ONESHOT over that" as
described in commit 8fff52fd5093. What do you think?

I'm cooking one patch for this purpose.

Thanks for the inspiration,
Jisheng

> 
> Signed-off-by: Viresh Kumar <viresh.kumar at linaro.org>
> Signed-off-by: Daniel Lezcano <daniel.lezcano at linaro.org>
> ---
>  drivers/clocksource/arm_global_timer.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c
> index 36998fa..9df0d16 100644
> --- a/drivers/clocksource/arm_global_timer.c
> +++ b/drivers/clocksource/arm_global_timer.c
> @@ -175,6 +175,7 @@ static int gt_clockevents_init(struct clock_event_device *clk)
>  	clk->set_state_shutdown = gt_clockevent_shutdown;
>  	clk->set_state_periodic = gt_clockevent_set_periodic;
>  	clk->set_state_oneshot = gt_clockevent_shutdown;
> +	clk->set_state_oneshot_stopped = gt_clockevent_shutdown;
>  	clk->set_next_event = gt_clockevent_set_next_event;
>  	clk->cpumask = cpumask_of(cpu);
>  	clk->rating = 300;



From will.deacon at arm.com  Fri Feb 26 01:47:21 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 26 Feb 2016 09:47:21 +0000
Subject: [PATCH] arm64/mm: remove unnecessary boundary check
In-Reply-To: <1456371874-19826-1-git-send-email-miles.chen@mediatek.com>
References: <1456371874-19826-1-git-send-email-miles.chen@mediatek.com>
Message-ID: <20160226094718.GA29125@arm.com>

On Thu, Feb 25, 2016 at 11:44:34AM +0800, miles.chen at mediatek.com wrote:
> From: Miles Chen <miles.chen at mediatek.com>
> 
> Remove the unnecessary boundary check since there is a huge
> gap between user and kernel address that they would never overlap.
> (arm64 does not have enough levels of page tables to cover 64-bit
> virtual address)
> 
> See Documentation/arm64/memory.txt
> 
> Signed-off-by: Miles Chen <miles.chen at mediatek.com>
> ---
>  arch/arm64/mm/init.c | 2 --
>  1 file changed, 2 deletions(-)

Acked-by: Will Deacon <will.deacon at arm.com>

Will


From jszhang at marvell.com  Fri Feb 26 01:45:57 2016
From: jszhang at marvell.com (Jisheng Zhang)
Date: Fri, 26 Feb 2016 17:45:57 +0800
Subject: [PATCH] clockevents/drivers/dw_apb_timer: Implement
 ->set_state_oneshot_stopped()
Message-ID: <1456479957-1561-1-git-send-email-jszhang@marvell.com>

The dw_apb_timer only "supports PERIODIC mode and their drivers emulate
ONESHOT over that" as described in commit 8fff52fd5093 ("clockevents:
Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state").

Inspired by Viresh, I think the dw_apb_timer also needs to implement
the set_state_oneshot_stopped() which is called by the clkevt core,
when the next event is required at an expiry time of 'KTIME_MAX'. This
normally happens with NO_HZ_{IDLE|FULL} in both LOWRES/HIGHRES modes.

This patch makes the clockevent device to stop on such an event, to
avoid spurious interrupts, as explained by the above commit.

Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
---
 drivers/clocksource/dw_apb_timer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
index 6334526..797505a 100644
--- a/drivers/clocksource/dw_apb_timer.c
+++ b/drivers/clocksource/dw_apb_timer.c
@@ -264,6 +264,7 @@ dw_apb_clockevent_init(int cpu, const char *name, unsigned rating,
 	dw_ced->ced.set_state_shutdown = apbt_shutdown;
 	dw_ced->ced.set_state_periodic = apbt_set_periodic;
 	dw_ced->ced.set_state_oneshot = apbt_set_oneshot;
+	dw_ced->ced.set_state_oneshot_stopped = apbt_shutdown;
 	dw_ced->ced.tick_resume = apbt_resume;
 	dw_ced->ced.set_next_event = apbt_next_event;
 	dw_ced->ced.irq = dw_ced->timer.irq;
-- 
2.7.0



From viresh.kumar at linaro.org  Fri Feb 26 01:54:56 2016
From: viresh.kumar at linaro.org (Viresh Kumar)
Date: Fri, 26 Feb 2016 15:24:56 +0530
Subject: [PATCH] clockevents/drivers/dw_apb_timer: Implement
 ->set_state_oneshot_stopped()
In-Reply-To: <1456479957-1561-1-git-send-email-jszhang@marvell.com>
References: <1456479957-1561-1-git-send-email-jszhang@marvell.com>
Message-ID: <20160226095456.GD5823@vireshk-i7>

On 26-02-16, 17:45, Jisheng Zhang wrote:
> The dw_apb_timer only "supports PERIODIC mode and their drivers emulate
> ONESHOT over that" as described in commit 8fff52fd5093 ("clockevents:
> Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state").
> 
> Inspired by Viresh, I think the dw_apb_timer also needs to implement
> the set_state_oneshot_stopped() which is called by the clkevt core,
> when the next event is required at an expiry time of 'KTIME_MAX'. This
> normally happens with NO_HZ_{IDLE|FULL} in both LOWRES/HIGHRES modes.
> 
> This patch makes the clockevent device to stop on such an event, to
> avoid spurious interrupts, as explained by the above commit.
> 
> Signed-off-by: Jisheng Zhang <jszhang at marvell.com>
> ---
>  drivers/clocksource/dw_apb_timer.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/clocksource/dw_apb_timer.c b/drivers/clocksource/dw_apb_timer.c
> index 6334526..797505a 100644
> --- a/drivers/clocksource/dw_apb_timer.c
> +++ b/drivers/clocksource/dw_apb_timer.c
> @@ -264,6 +264,7 @@ dw_apb_clockevent_init(int cpu, const char *name, unsigned rating,
>  	dw_ced->ced.set_state_shutdown = apbt_shutdown;
>  	dw_ced->ced.set_state_periodic = apbt_set_periodic;
>  	dw_ced->ced.set_state_oneshot = apbt_set_oneshot;
> +	dw_ced->ced.set_state_oneshot_stopped = apbt_shutdown;
>  	dw_ced->ced.tick_resume = apbt_resume;
>  	dw_ced->ced.set_next_event = apbt_next_event;
>  	dw_ced->ced.irq = dw_ced->timer.irq;

Reviewed-by: Viresh Kumar <viresh.kumar at linaro.org>

-- 
viresh


From will.deacon at arm.com  Fri Feb 26 02:03:26 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 26 Feb 2016 10:03:26 +0000
Subject: [PATCH v2] arm64: lse: deal with clobbered x16 register after
 branch via PLT
In-Reply-To: <1456429733-20825-1-git-send-email-ard.biesheuvel@linaro.org>
References: <1456429733-20825-1-git-send-email-ard.biesheuvel@linaro.org>
Message-ID: <20160226100325.GB29125@arm.com>

Hey Ard,

On Thu, Feb 25, 2016 at 08:48:53PM +0100, Ard Biesheuvel wrote:
> The LSE atomics implementation uses runtime patching to patch in calls
> to out of line non-LSE atomics implementations on cores that lack hardware
> support for LSE. To avoid paying the overhead cost of a function call even
> if no call ends up being made, the bl instruction is kept invisible to the
> compiler, and the out of line implementations preserve all registers, not
> just the ones that they are required to preserve as per the AAPCS64.
> 
> However, commit fd045f6cd98e ("arm64: add support for module PLTs") added
> support for routing branch instructions via veneers if the branch target
> offset exceeds the range of the ordinary relative branch instructions.
> Since this deals with jump and call instructions that are exposed to ELF
> relocations, the PLT code uses x16 to hold the address of the branch target
> when it performs an indirect branch-to-register, something which is
> explicitly allowed by the AAPCS64 (and ordinary compiler generated code
> does not expect register x16 or x17 to retain their values across a bl
> instruction).
> 
> Since the lse runtime patched bl instructions don't adhere to the AAPCS64,
> they don't deal with this clobbering of registers x16 and x17. So add them
> to the clobber list of the asm() statements that perform the call
> instructions, and drop x16 and x17 from the list of registers that are
> caller saved in the out of line non-LSE implementations.
> 
> In addition, since we have given these functions two scratch registers,
> they no longer need to stack/unstack temp registers, and the only remaining
> stack accesses are for the frame pointer. So pass -fomit-frame-pointer as
> well, this eliminates all stack accesses from these functions.

[...]

> diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
> index 197e06afbf71..7af60139f718 100644
> --- a/arch/arm64/include/asm/atomic_lse.h
> +++ b/arch/arm64/include/asm/atomic_lse.h
> @@ -36,7 +36,7 @@ static inline void atomic_andnot(int i, atomic_t *v)
>  	"	stclr	%w[i], %[v]\n")
>  	: [i] "+r" (w0), [v] "+Q" (v->counter)
>  	: "r" (x1)
> -	: "x30");
> +	: "x16", "x17", "x30");
>  }

The problem with this is that we potentially end up spilling/reloading
x16 and x17 even when we patch in the LSE atomic. That's why I opted for
the explicit stack accesses in my patch, so that they get overwritten
with NOPs when we switch to the LSE version.

Will


From ard.biesheuvel at linaro.org  Fri Feb 26 02:04:38 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 26 Feb 2016 11:04:38 +0100
Subject: [PATCH v2] arm64: lse: deal with clobbered x16 register after
 branch via PLT
In-Reply-To: <20160226100325.GB29125@arm.com>
References: <1456429733-20825-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160226100325.GB29125@arm.com>
Message-ID: <CAKv+Gu-AAu7LpbBMuEQSx7Kfg+gbD4eUf0yjP3oPwfx7V5ZiAQ@mail.gmail.com>

On 26 February 2016 at 11:03, Will Deacon <will.deacon at arm.com> wrote:
> Hey Ard,
>
> On Thu, Feb 25, 2016 at 08:48:53PM +0100, Ard Biesheuvel wrote:
>> The LSE atomics implementation uses runtime patching to patch in calls
>> to out of line non-LSE atomics implementations on cores that lack hardware
>> support for LSE. To avoid paying the overhead cost of a function call even
>> if no call ends up being made, the bl instruction is kept invisible to the
>> compiler, and the out of line implementations preserve all registers, not
>> just the ones that they are required to preserve as per the AAPCS64.
>>
>> However, commit fd045f6cd98e ("arm64: add support for module PLTs") added
>> support for routing branch instructions via veneers if the branch target
>> offset exceeds the range of the ordinary relative branch instructions.
>> Since this deals with jump and call instructions that are exposed to ELF
>> relocations, the PLT code uses x16 to hold the address of the branch target
>> when it performs an indirect branch-to-register, something which is
>> explicitly allowed by the AAPCS64 (and ordinary compiler generated code
>> does not expect register x16 or x17 to retain their values across a bl
>> instruction).
>>
>> Since the lse runtime patched bl instructions don't adhere to the AAPCS64,
>> they don't deal with this clobbering of registers x16 and x17. So add them
>> to the clobber list of the asm() statements that perform the call
>> instructions, and drop x16 and x17 from the list of registers that are
>> caller saved in the out of line non-LSE implementations.
>>
>> In addition, since we have given these functions two scratch registers,
>> they no longer need to stack/unstack temp registers, and the only remaining
>> stack accesses are for the frame pointer. So pass -fomit-frame-pointer as
>> well, this eliminates all stack accesses from these functions.
>
> [...]
>
>> diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
>> index 197e06afbf71..7af60139f718 100644
>> --- a/arch/arm64/include/asm/atomic_lse.h
>> +++ b/arch/arm64/include/asm/atomic_lse.h
>> @@ -36,7 +36,7 @@ static inline void atomic_andnot(int i, atomic_t *v)
>>       "       stclr   %w[i], %[v]\n")
>>       : [i] "+r" (w0), [v] "+Q" (v->counter)
>>       : "r" (x1)
>> -     : "x30");
>> +     : "x16", "x17", "x30");
>>  }
>
> The problem with this is that we potentially end up spilling/reloading
> x16 and x17 even when we patch in the LSE atomic. That's why I opted for
> the explicit stack accesses in my patch, so that they get overwritten
> with NOPs when we switch to the LSE version.
>

I see. But is that really an issue in practice? And the fact that the
non-LSE code is a lot more efficient has to count for something, I
suppose?
(/me thinks enterprise, distro kernels etc etc)


From yamada.masahiro at socionext.com  Fri Feb 26 02:06:29 2016
From: yamada.masahiro at socionext.com (Masahiro Yamada)
Date: Fri, 26 Feb 2016 19:06:29 +0900
Subject: [PATCH 31/50] pinctrl: uniphier: Use devm_pinctrl_register() for
 pinctrl registration
In-Reply-To: <1456319775-3216-32-git-send-email-ldewangan@nvidia.com>
References: <1456319775-3216-1-git-send-email-ldewangan@nvidia.com>
 <1456319775-3216-32-git-send-email-ldewangan@nvidia.com>
Message-ID: <CAK7LNATP6vBz3CvD5cJ+DwbL3g8e_UJ40W8zZJwzQrKXnWokkg@mail.gmail.com>

2016-02-24 22:15 GMT+09:00 Laxman Dewangan <ldewangan at nvidia.com>:
> Use devm_pinctrl_register() for pin control registration and remove
> need of .remove callback.
>
> Signed-off-by: Laxman Dewangan <ldewangan at nvidia.com>
> Cc: Masahiro Yamada <yamada.masahiro at socionext.com>
> ---

Acked-by: Masahiro Yamada <yamada.masahiro at socionext.com>


Thanks!



-- 
Best Regards
Masahiro Yamada


From will.deacon at arm.com  Fri Feb 26 02:14:35 2016
From: will.deacon at arm.com (Will Deacon)
Date: Fri, 26 Feb 2016 10:14:35 +0000
Subject: [PATCH v2] arm64: lse: deal with clobbered x16 register after
 branch via PLT
In-Reply-To: <CAKv+Gu-AAu7LpbBMuEQSx7Kfg+gbD4eUf0yjP3oPwfx7V5ZiAQ@mail.gmail.com>
References: <1456429733-20825-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160226100325.GB29125@arm.com>
 <CAKv+Gu-AAu7LpbBMuEQSx7Kfg+gbD4eUf0yjP3oPwfx7V5ZiAQ@mail.gmail.com>
Message-ID: <20160226101435.GC29125@arm.com>

On Fri, Feb 26, 2016 at 11:04:38AM +0100, Ard Biesheuvel wrote:
> On 26 February 2016 at 11:03, Will Deacon <will.deacon at arm.com> wrote:
> > Hey Ard,
> >
> > On Thu, Feb 25, 2016 at 08:48:53PM +0100, Ard Biesheuvel wrote:
> >> The LSE atomics implementation uses runtime patching to patch in calls
> >> to out of line non-LSE atomics implementations on cores that lack hardware
> >> support for LSE. To avoid paying the overhead cost of a function call even
> >> if no call ends up being made, the bl instruction is kept invisible to the
> >> compiler, and the out of line implementations preserve all registers, not
> >> just the ones that they are required to preserve as per the AAPCS64.
> >>
> >> However, commit fd045f6cd98e ("arm64: add support for module PLTs") added
> >> support for routing branch instructions via veneers if the branch target
> >> offset exceeds the range of the ordinary relative branch instructions.
> >> Since this deals with jump and call instructions that are exposed to ELF
> >> relocations, the PLT code uses x16 to hold the address of the branch target
> >> when it performs an indirect branch-to-register, something which is
> >> explicitly allowed by the AAPCS64 (and ordinary compiler generated code
> >> does not expect register x16 or x17 to retain their values across a bl
> >> instruction).
> >>
> >> Since the lse runtime patched bl instructions don't adhere to the AAPCS64,
> >> they don't deal with this clobbering of registers x16 and x17. So add them
> >> to the clobber list of the asm() statements that perform the call
> >> instructions, and drop x16 and x17 from the list of registers that are
> >> caller saved in the out of line non-LSE implementations.
> >>
> >> In addition, since we have given these functions two scratch registers,
> >> they no longer need to stack/unstack temp registers, and the only remaining
> >> stack accesses are for the frame pointer. So pass -fomit-frame-pointer as
> >> well, this eliminates all stack accesses from these functions.
> >
> > [...]
> >
> >> diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
> >> index 197e06afbf71..7af60139f718 100644
> >> --- a/arch/arm64/include/asm/atomic_lse.h
> >> +++ b/arch/arm64/include/asm/atomic_lse.h
> >> @@ -36,7 +36,7 @@ static inline void atomic_andnot(int i, atomic_t *v)
> >>       "       stclr   %w[i], %[v]\n")
> >>       : [i] "+r" (w0), [v] "+Q" (v->counter)
> >>       : "r" (x1)
> >> -     : "x30");
> >> +     : "x16", "x17", "x30");
> >>  }
> >
> > The problem with this is that we potentially end up spilling/reloading
> > x16 and x17 even when we patch in the LSE atomic. That's why I opted for
> > the explicit stack accesses in my patch, so that they get overwritten
> > with NOPs when we switch to the LSE version.
> >
> 
> I see. But is that really an issue in practice?

You'd need to ask somebody with silicon ;)

> And the fact that the non-LSE code is a lot more efficient has to count for
> something, I suppose?
> (/me thinks enterprise, distro kernels etc etc)

Right, but with my patch, we also get the nice code in the out-of-line
case:

0000000000000000 <__ll_sc_atomic_add>:
   0:   f9800031        prfm    pstl1strm, [x1]
   4:   885f7c31        ldxr    w17, [x1]
   8:   0b000231        add     w17, w17, w0
   c:   88107c31        stxr    w16, w17, [x1]
  10:   35ffffb0        cbnz    w16, 4 <__ll_sc_atomic_add+0x4>
  14:   d65f03c0        ret

and in the inline LSE case we have NOPs instead of stack accesses.

Will


From romain.izard.pro at gmail.com  Fri Feb 26 02:15:04 2016
From: romain.izard.pro at gmail.com (Romain Izard)
Date: Fri, 26 Feb 2016 11:15:04 +0100
Subject: [PATCH v3] tty/serial: at91: restore dynamic driver binding
Message-ID: <1456481704-18997-1-git-send-email-romain.izard.pro@gmail.com>

In commit c39dfebc7798956fd2140ae6321786ff35da30c3, the modular support
code for atmel_serial was removed, as the driver cannot be built as a
module. Because no use case was proposed, the dynamic driver binding
support was removed as well.

The atmel_serial driver can manage up to 7 serial controllers, which are
multiplexed with other functions. For example, in the Atmel SAMA5D2, the
Flexcom controllers can work as USART, SPI or I2C controllers, and on
all Atmel devices serial lines can be reconfigured as GPIOs.

My use case uses GPIOs to transfer a firmware update using a custom
protocol on the lines used as a serial port during the normal life of
the device. If it is not possible to unbind the atmel_serial driver, the
GPIO lines remain reserved and prevent this case from working.

This patch reinstates the atmel_serial_remove function, and fixes it as
it failed to clear the "clk" field on removal, triggering an oops when
a device was bound again after being unbound.

Acked-by: Nicolas Ferre <nicolas.ferre at atmel.com>
Signed-off-by: Romain Izard <romain.izard.pro at gmail.com>
---
Changelog:
v2: Add the rationale for keeping the "remove" function as a comment.
v3: Do not cleanup the spaces in the driver initializer, as requested by
  the maintainer

 drivers/tty/serial/atmel_serial.c | 35 ++++++++++++++++++++++++++++++++++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 1c0884d8ef32..969084455f94 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -2759,14 +2759,47 @@ err:
 	return ret;
 }
 
+/*
+ * Even if the driver is not modular, it makes sense to be able to
+ * unbind a device: there can be many bound devices, and there are
+ * situations where dynamic binding and unbinding can be useful.
+ *
+ * For example, a connected device can require a specific firmware update
+ * protocol that needs bitbanging on IO lines, but use the regular serial
+ * port in the normal case.
+ */
+static int atmel_serial_remove(struct platform_device *pdev)
+{
+	struct uart_port *port = platform_get_drvdata(pdev);
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	int ret = 0;
+
+	tasklet_kill(&atmel_port->tasklet);
+
+	device_init_wakeup(&pdev->dev, 0);
+
+	ret = uart_remove_one_port(&atmel_uart, port);
+
+	kfree(atmel_port->rx_ring.buf);
+
+	/* "port" is allocated statically, so we shouldn't free it */
+
+	clear_bit(port->line, atmel_ports_in_use);
+
+	clk_put(atmel_port->clk);
+	atmel_port->clk = NULL;
+
+	return ret;
+}
+
 static struct platform_driver atmel_serial_driver = {
 	.probe		= atmel_serial_probe,
+	.remove		= atmel_serial_remove,
 	.suspend	= atmel_serial_suspend,
 	.resume		= atmel_serial_resume,
 	.driver		= {
 		.name			= "atmel_usart",
 		.of_match_table		= of_match_ptr(atmel_serial_dt_ids),
-		.suppress_bind_attrs    = true,
 	},
 };
 
-- 
2.5.0



From tomi.valkeinen at ti.com  Fri Feb 26 02:20:33 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Feb 2016 12:20:33 +0200
Subject: [PATCH 0/7] video: ARM CLCD: non-controversial parts
In-Reply-To: <CACRpkdbGDXTbenOY_bsiuGqS3oBP3CKyjsOJuMPStaMFi=u3hw@mail.gmail.com>
References: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
 <CACRpkdbGDXTbenOY_bsiuGqS3oBP3CKyjsOJuMPStaMFi=u3hw@mail.gmail.com>
Message-ID: <56D026F1.1080009@ti.com>



On 25/02/16 21:35, Linus Walleij wrote:
> On Tue, Feb 23, 2016 at 11:01 AM, Linus Walleij
> <linus.walleij at linaro.org> wrote:
> 
>> This is a redux version of the previous patch set that strips out
>> any attempts to auto-switch or rewrite the device tree to match
>> the CLCD Versatile panel.
> 
> It seems patch #4 didn't make it out so I re-sent it.

Hmm, it was there in the series... Russell had comments to it, to which
you didn't reply.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160226/2bb28b03/attachment.sig>

From peter.ujfalusi at ti.com  Fri Feb 26 02:23:27 2016
From: peter.ujfalusi at ti.com (Peter Ujfalusi)
Date: Fri, 26 Feb 2016 12:23:27 +0200
Subject: [PATCH] dmaengine: omap-dma: Do not call omap_dma_callback() from
 tx_status()
In-Reply-To: <20160226010658.GN5783@n2100.arm.linux.org.uk>
References: <1456388939-15722-1-git-send-email-peter.ujfalusi@ti.com>
 <20160226010658.GN5783@n2100.arm.linux.org.uk>
Message-ID: <56D0279F.2050703@ti.com>

On 2016-02-26 03:06, Russell King - ARM Linux wrote:
> On Thu, Feb 25, 2016 at 10:28:59AM +0200, Peter Ujfalusi wrote:
>> When based on the CCR_ENABLE bit the channel is stopped we should not call
>> omap_dma_callback(), only change the return value to DMA_COMPLETE. Client
>> drivers will do the right thing to clean up the channel after the transfer
>> has been completed.
>> Check the CCR_ENABLE only if the channel is not paused since pause in sDMA
>> means that the channel is stopped.
>> This will fix one hard to reproduce race condition when the channel is
>> terminated during transfer (affecting cyclic operation).
>>
>> Fixes: 1a7cf7b26f25 ("dmaengine: omap-dma: Handle cases when the channel is polled for completion")
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
>> ---
>>  drivers/dma/omap-dma.c | 16 ++++++++++------
>>  1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
>> index f6bef0d93998..a6b189fdbbe6 100644
>> --- a/drivers/dma/omap-dma.c
>> +++ b/drivers/dma/omap-dma.c
>> @@ -671,18 +671,22 @@ static enum dma_status omap_dma_tx_status(struct dma_chan *chan,
>>  	struct omap_chan *c = to_omap_dma_chan(chan);
>>  	struct virt_dma_desc *vd;
>>  	enum dma_status ret;
>> -	uint32_t ccr;
>>  	unsigned long flags;
>>  
>> -	ccr = omap_dma_chan_read(c, CCR);
>> -	/* The channel is no longer active, handle the completion right away */
>> -	if (!(ccr & CCR_ENABLE))
>> -		omap_dma_callback(c->dma_ch, 0, c);
>> -
>>  	ret = dma_cookie_status(chan, cookie, txstate);
>>  	if (ret == DMA_COMPLETE || !txstate)
>>  		return ret;
>>  
>> +	if (!c->paused) {
>> +		uint32_t ccr = omap_dma_chan_read(c, CCR);
>> +		/*
>> +		 * The channel is no longer active, set the return value
>> +		 * accordingly
>> +		 */
>> +		if (!(ccr & CCR_ENABLE))
>> +			ret = DMA_COMPLETE;
>> +	}
>> +
> 
> This looks very much like a hack, and surely opens a race condition
> up: what happens when a request submitted and pending but not yet
> started?  If the channel is idle, requesting status will report
> that the request has completed.
> 
> It's also wrong for another reason.  If txstate is NULL...

True, I have fixed these up.

> Your original commit adding the original hack that you're now removing
> above says that this is to support polled operation: I'm not aware of
> DMA engine supporting such a mode.  DMA_PREP_INTERRUPT is a mechanism
> where requests can be queued without an interrupt to allow batching.

Also it is used to suppress DMA interrupts during audio playback for example.
In this case we will run w/o interrupts and the position is polled.

> See the raid5/async_tx code, which queues a set of operations without
> DMA_PREP_INTERRUPT, with the final operation with DMA_PREP_INTERRUPT
> set.

We only allow the interrupts to be disabled in cyclic or memcpy mode. With
slave_sg we have interrupts as it is needed to move to the next SG.

> As the driver is reliant on interrupts to move to the next transfer,
> the patch which causes DMA_PREP_INTERRUPT to influence whether
> interrupts are sent is actually buggy, and will prevent several
> queued DMA operations to fail.

Yes, the omap-dma only allows the interrupts to be actually disabled when it
is save to do so. slave_sg can not work w/o interrupts so there we don't
disable them.

> 


-- 
P?ter


From ard.biesheuvel at linaro.org  Fri Feb 26 02:25:15 2016
From: ard.biesheuvel at linaro.org (Ard Biesheuvel)
Date: Fri, 26 Feb 2016 11:25:15 +0100
Subject: [PATCH v2] arm64: lse: deal with clobbered x16 register after
 branch via PLT
In-Reply-To: <20160226101435.GC29125@arm.com>
References: <1456429733-20825-1-git-send-email-ard.biesheuvel@linaro.org>
 <20160226100325.GB29125@arm.com>
 <CAKv+Gu-AAu7LpbBMuEQSx7Kfg+gbD4eUf0yjP3oPwfx7V5ZiAQ@mail.gmail.com>
 <20160226101435.GC29125@arm.com>
Message-ID: <CAKv+Gu-F9gVmePmbQ=g4LpsrhHJyuSFUqe+_V12ELB1ivxtxHw@mail.gmail.com>

On 26 February 2016 at 11:14, Will Deacon <will.deacon at arm.com> wrote:
> On Fri, Feb 26, 2016 at 11:04:38AM +0100, Ard Biesheuvel wrote:
>> On 26 February 2016 at 11:03, Will Deacon <will.deacon at arm.com> wrote:
>> > Hey Ard,
>> >
>> > On Thu, Feb 25, 2016 at 08:48:53PM +0100, Ard Biesheuvel wrote:
>> >> The LSE atomics implementation uses runtime patching to patch in calls
>> >> to out of line non-LSE atomics implementations on cores that lack hardware
>> >> support for LSE. To avoid paying the overhead cost of a function call even
>> >> if no call ends up being made, the bl instruction is kept invisible to the
>> >> compiler, and the out of line implementations preserve all registers, not
>> >> just the ones that they are required to preserve as per the AAPCS64.
>> >>
>> >> However, commit fd045f6cd98e ("arm64: add support for module PLTs") added
>> >> support for routing branch instructions via veneers if the branch target
>> >> offset exceeds the range of the ordinary relative branch instructions.
>> >> Since this deals with jump and call instructions that are exposed to ELF
>> >> relocations, the PLT code uses x16 to hold the address of the branch target
>> >> when it performs an indirect branch-to-register, something which is
>> >> explicitly allowed by the AAPCS64 (and ordinary compiler generated code
>> >> does not expect register x16 or x17 to retain their values across a bl
>> >> instruction).
>> >>
>> >> Since the lse runtime patched bl instructions don't adhere to the AAPCS64,
>> >> they don't deal with this clobbering of registers x16 and x17. So add them
>> >> to the clobber list of the asm() statements that perform the call
>> >> instructions, and drop x16 and x17 from the list of registers that are
>> >> caller saved in the out of line non-LSE implementations.
>> >>
>> >> In addition, since we have given these functions two scratch registers,
>> >> they no longer need to stack/unstack temp registers, and the only remaining
>> >> stack accesses are for the frame pointer. So pass -fomit-frame-pointer as
>> >> well, this eliminates all stack accesses from these functions.
>> >
>> > [...]
>> >
>> >> diff --git a/arch/arm64/include/asm/atomic_lse.h b/arch/arm64/include/asm/atomic_lse.h
>> >> index 197e06afbf71..7af60139f718 100644
>> >> --- a/arch/arm64/include/asm/atomic_lse.h
>> >> +++ b/arch/arm64/include/asm/atomic_lse.h
>> >> @@ -36,7 +36,7 @@ static inline void atomic_andnot(int i, atomic_t *v)
>> >>       "       stclr   %w[i], %[v]\n")
>> >>       : [i] "+r" (w0), [v] "+Q" (v->counter)
>> >>       : "r" (x1)
>> >> -     : "x30");
>> >> +     : "x16", "x17", "x30");
>> >>  }
>> >
>> > The problem with this is that we potentially end up spilling/reloading
>> > x16 and x17 even when we patch in the LSE atomic. That's why I opted for
>> > the explicit stack accesses in my patch, so that they get overwritten
>> > with NOPs when we switch to the LSE version.
>> >
>>
>> I see. But is that really an issue in practice?
>
> You'd need to ask somebody with silicon ;)
>
>> And the fact that the non-LSE code is a lot more efficient has to count for
>> something, I suppose?
>> (/me thinks enterprise, distro kernels etc etc)
>
> Right, but with my patch, we also get the nice code in the out-of-line
> case:
>
> 0000000000000000 <__ll_sc_atomic_add>:
>    0:   f9800031        prfm    pstl1strm, [x1]
>    4:   885f7c31        ldxr    w17, [x1]
>    8:   0b000231        add     w17, w17, w0
>    c:   88107c31        stxr    w16, w17, [x1]
>   10:   35ffffb0        cbnz    w16, 4 <__ll_sc_atomic_add+0x4>
>   14:   d65f03c0        ret
>
> and in the inline LSE case we have NOPs instead of stack accesses.
>

True, so it is an improvement in the sense that you only stack x16/x17
rather than create a full stack frame. My concern is that you always
take the hit of the push/pop when you run a LSE enabled kernel on
non-LSE hardware, even if the calling code is not short of registers.
In that sense, I think it is a premature optimization, and we should
simply mark x16/x17 as clobbered until we can prove that not doing so
improves performance measurably on LSE capable hardware


From nsekhar at ti.com  Fri Feb 26 02:27:28 2016
From: nsekhar at ti.com (Sekhar Nori)
Date: Fri, 26 Feb 2016 15:57:28 +0530
Subject: [PATCH v3 1/5] pwms: pwm-ti*: Remove support for local clock
 gating
In-Reply-To: <1456439796-28546-2-git-send-email-fcooper@ti.com>
References: <1456439796-28546-1-git-send-email-fcooper@ti.com>
 <1456439796-28546-2-git-send-email-fcooper@ti.com>
Message-ID: <56D02890.8000003@ti.com>

+ Thierry, PWM subsystem maintainer.

On Friday 26 February 2016 04:06 AM, Franklin S Cooper Jr wrote:
> The PWMSS local clock gating registers have no real purpose on OMAP ARM
> devices. These registers were left over registers from DSP IP where the
> PRCM doesn't exist. There is a silicon bug where gating and ungating clocks
> don't function properly. TRMs will be update to indicate that these
> registers shouldn't be touched.
> 
> Therefore, all code that accesses the PWMSS_CLKCONFIG or PWMSS_CLKSTATUS
> will be removed by this patch with zero loss of functionality by the ECAP
> and EPWM drivers.
> 
> Signed-off-by: Franklin S Cooper Jr <fcooper at ti.com>
> ---
> Version 3 changes:
> New patch
> 
>  drivers/pwm/pwm-tiecap.c   | 28 --------------------------
>  drivers/pwm/pwm-tiehrpwm.c | 29 ---------------------------
>  drivers/pwm/pwm-tipwmss.c  | 49 ----------------------------------------------
>  drivers/pwm/pwm-tipwmss.h  | 39 ------------------------------------
>  4 files changed, 145 deletions(-)
>  delete mode 100644 drivers/pwm/pwm-tipwmss.h
> 
> diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
> index 616af76..9e0865d7 100644
> --- a/drivers/pwm/pwm-tiecap.c
> +++ b/drivers/pwm/pwm-tiecap.c
> @@ -27,8 +27,6 @@
>  #include <linux/pwm.h>
>  #include <linux/of_device.h>
>  
> -#include "pwm-tipwmss.h"
> -
>  /* ECAP registers and bits definitions */
>  #define CAP1			0x08
>  #define CAP2			0x0C
> @@ -206,7 +204,6 @@ static int ecap_pwm_probe(struct platform_device *pdev)
>  	struct resource *r;
>  	struct clk *clk;
>  	struct ecap_pwm_chip *pc;
> -	u16 status;
>  
>  	pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
>  	if (!pc)
> @@ -243,40 +240,15 @@ static int ecap_pwm_probe(struct platform_device *pdev)
>  	}
>  
>  	pm_runtime_enable(&pdev->dev);
> -	pm_runtime_get_sync(&pdev->dev);
> -
> -	status = pwmss_submodule_state_change(pdev->dev.parent,
> -			PWMSS_ECAPCLK_EN);
> -	if (!(status & PWMSS_ECAPCLK_EN_ACK)) {
> -		dev_err(&pdev->dev, "PWMSS config space clock enable failed\n");
> -		ret = -EINVAL;
> -		goto pwmss_clk_failure;
> -	}
> -
> -	pm_runtime_put_sync(&pdev->dev);
>  
>  	platform_set_drvdata(pdev, pc);
>  	return 0;
> -
> -pwmss_clk_failure:
> -	pm_runtime_put_sync(&pdev->dev);
> -	pm_runtime_disable(&pdev->dev);
> -	pwmchip_remove(&pc->chip);
> -	return ret;
>  }
>  
>  static int ecap_pwm_remove(struct platform_device *pdev)
>  {
>  	struct ecap_pwm_chip *pc = platform_get_drvdata(pdev);
>  
> -	pm_runtime_get_sync(&pdev->dev);
> -	/*
> -	 * Due to hardware misbehaviour, acknowledge of the stop_req
> -	 * is missing. Hence checking of the status bit skipped.
> -	 */
> -	pwmss_submodule_state_change(pdev->dev.parent, PWMSS_ECAPCLK_STOP_REQ);
> -	pm_runtime_put_sync(&pdev->dev);
> -
>  	pm_runtime_disable(&pdev->dev);
>  	return pwmchip_remove(&pc->chip);
>  }
> diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
> index 6a41e66..e09b1f0 100644
> --- a/drivers/pwm/pwm-tiehrpwm.c
> +++ b/drivers/pwm/pwm-tiehrpwm.c
> @@ -27,8 +27,6 @@
>  #include <linux/pm_runtime.h>
>  #include <linux/of_device.h>
>  
> -#include "pwm-tipwmss.h"
> -
>  /* EHRPWM registers and bits definitions */
>  
>  /* Time base module registers */
> @@ -437,7 +435,6 @@ static int ehrpwm_pwm_probe(struct platform_device *pdev)
>  	struct resource *r;
>  	struct clk *clk;
>  	struct ehrpwm_pwm_chip *pc;
> -	u16 status;
>  
>  	pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
>  	if (!pc)
> @@ -487,27 +484,9 @@ static int ehrpwm_pwm_probe(struct platform_device *pdev)
>  	}
>  
>  	pm_runtime_enable(&pdev->dev);
> -	pm_runtime_get_sync(&pdev->dev);
> -
> -	status = pwmss_submodule_state_change(pdev->dev.parent,
> -			PWMSS_EPWMCLK_EN);
> -	if (!(status & PWMSS_EPWMCLK_EN_ACK)) {
> -		dev_err(&pdev->dev, "PWMSS config space clock enable failed\n");
> -		ret = -EINVAL;
> -		goto pwmss_clk_failure;
> -	}
> -
> -	pm_runtime_put_sync(&pdev->dev);
>  
>  	platform_set_drvdata(pdev, pc);
>  	return 0;
> -
> -pwmss_clk_failure:
> -	pm_runtime_put_sync(&pdev->dev);
> -	pm_runtime_disable(&pdev->dev);
> -	pwmchip_remove(&pc->chip);
> -	clk_unprepare(pc->tbclk);
> -	return ret;
>  }
>  
>  static int ehrpwm_pwm_remove(struct platform_device *pdev)
> @@ -516,14 +495,6 @@ static int ehrpwm_pwm_remove(struct platform_device *pdev)
>  
>  	clk_unprepare(pc->tbclk);
>  
> -	pm_runtime_get_sync(&pdev->dev);
> -	/*
> -	 * Due to hardware misbehaviour, acknowledge of the stop_req
> -	 * is missing. Hence checking of the status bit skipped.
> -	 */
> -	pwmss_submodule_state_change(pdev->dev.parent, PWMSS_EPWMCLK_STOP_REQ);
> -	pm_runtime_put_sync(&pdev->dev);
> -
>  	pm_runtime_put_sync(&pdev->dev);
>  	pm_runtime_disable(&pdev->dev);
>  	return pwmchip_remove(&pc->chip);
> diff --git a/drivers/pwm/pwm-tipwmss.c b/drivers/pwm/pwm-tipwmss.c
> index 5cf65a1..829f499 100644
> --- a/drivers/pwm/pwm-tipwmss.c
> +++ b/drivers/pwm/pwm-tipwmss.c
> @@ -22,32 +22,6 @@
>  #include <linux/pm_runtime.h>
>  #include <linux/of_device.h>
>  
> -#include "pwm-tipwmss.h"
> -
> -#define PWMSS_CLKCONFIG		0x8	/* Clock gating reg */
> -#define PWMSS_CLKSTATUS		0xc	/* Clock gating status reg */
> -
> -struct pwmss_info {
> -	void __iomem	*mmio_base;
> -	struct mutex	pwmss_lock;
> -	u16		pwmss_clkconfig;
> -};
> -
> -u16 pwmss_submodule_state_change(struct device *dev, int set)
> -{
> -	struct pwmss_info *info = dev_get_drvdata(dev);
> -	u16 val;
> -
> -	mutex_lock(&info->pwmss_lock);
> -	val = readw(info->mmio_base + PWMSS_CLKCONFIG);
> -	val |= set;
> -	writew(val , info->mmio_base + PWMSS_CLKCONFIG);
> -	mutex_unlock(&info->pwmss_lock);
> -
> -	return readw(info->mmio_base + PWMSS_CLKSTATUS);
> -}
> -EXPORT_SYMBOL(pwmss_submodule_state_change);
> -
>  static const struct of_device_id pwmss_of_match[] = {
>  	{ .compatible	= "ti,am33xx-pwmss" },
>  	{},
> @@ -57,24 +31,10 @@ MODULE_DEVICE_TABLE(of, pwmss_of_match);
>  static int pwmss_probe(struct platform_device *pdev)
>  {
>  	int ret;
> -	struct resource *r;
> -	struct pwmss_info *info;
>  	struct device_node *node = pdev->dev.of_node;
>  
> -	info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
> -	if (!info)
> -		return -ENOMEM;
> -
> -	mutex_init(&info->pwmss_lock);
> -
> -	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -	info->mmio_base = devm_ioremap_resource(&pdev->dev, r);
> -	if (IS_ERR(info->mmio_base))
> -		return PTR_ERR(info->mmio_base);
> -
>  	pm_runtime_enable(&pdev->dev);
>  	pm_runtime_get_sync(&pdev->dev);
> -	platform_set_drvdata(pdev, info);
>  
>  	/* Populate all the child nodes here... */
>  	ret = of_platform_populate(node, NULL, NULL, &pdev->dev);
> @@ -86,30 +46,21 @@ static int pwmss_probe(struct platform_device *pdev)
>  
>  static int pwmss_remove(struct platform_device *pdev)
>  {
> -	struct pwmss_info *info = platform_get_drvdata(pdev);
> -
>  	pm_runtime_put_sync(&pdev->dev);
>  	pm_runtime_disable(&pdev->dev);
> -	mutex_destroy(&info->pwmss_lock);
>  	return 0;
>  }
>  
>  #ifdef CONFIG_PM_SLEEP
>  static int pwmss_suspend(struct device *dev)
>  {
> -	struct pwmss_info *info = dev_get_drvdata(dev);
> -
> -	info->pwmss_clkconfig = readw(info->mmio_base + PWMSS_CLKCONFIG);
>  	pm_runtime_put_sync(dev);
>  	return 0;
>  }
>  
>  static int pwmss_resume(struct device *dev)
>  {
> -	struct pwmss_info *info = dev_get_drvdata(dev);
> -
>  	pm_runtime_get_sync(dev);
> -	writew(info->pwmss_clkconfig, info->mmio_base + PWMSS_CLKCONFIG);
>  	return 0;
>  }
>  #endif
> diff --git a/drivers/pwm/pwm-tipwmss.h b/drivers/pwm/pwm-tipwmss.h
> deleted file mode 100644
> index 10ad804..0000000
> --- a/drivers/pwm/pwm-tipwmss.h
> +++ /dev/null
> @@ -1,39 +0,0 @@
> -/*
> - * TI PWM Subsystem driver
> - *
> - * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> - *
> - */
> -
> -#ifndef __TIPWMSS_H
> -#define __TIPWMSS_H
> -
> -/* PWM substem clock gating */
> -#define PWMSS_ECAPCLK_EN	BIT(0)
> -#define PWMSS_ECAPCLK_STOP_REQ	BIT(1)
> -#define PWMSS_EPWMCLK_EN	BIT(8)
> -#define PWMSS_EPWMCLK_STOP_REQ	BIT(9)
> -
> -#define PWMSS_ECAPCLK_EN_ACK	BIT(0)
> -#define PWMSS_EPWMCLK_EN_ACK	BIT(8)
> -
> -#ifdef CONFIG_PWM_TIPWMSS
> -extern u16 pwmss_submodule_state_change(struct device *dev, int set);
> -#else
> -static inline u16 pwmss_submodule_state_change(struct device *dev, int set)
> -{
> -	/* return success status value */
> -	return 0xFFFF;
> -}
> -#endif
> -#endif	/* __TIPWMSS_H */
> 



From tglx at linutronix.de  Fri Feb 26 02:26:23 2016
From: tglx at linutronix.de (Thomas Gleixner)
Date: Fri, 26 Feb 2016 11:26:23 +0100 (CET)
Subject: [PATCH 1/2] irqchip: add lpc18xx gpio pin interrupt driver
In-Reply-To: <1456437887-24432-2-git-send-email-manabian@gmail.com>
References: <1456437887-24432-1-git-send-email-manabian@gmail.com>
 <1456437887-24432-2-git-send-email-manabian@gmail.com>
Message-ID: <alpine.DEB.2.11.1602261122120.3638@nanos>

On Thu, 25 Feb 2016, Joachim Eastwood wrote:
> +static void lpc18xx_gpio_pint_handler(struct irq_desc *desc)
> +{
> +	struct lpc18xx_gpio_pint_chip *pint = irq_desc_get_handler_data(desc);
> +	unsigned int irq = irq_desc_get_irq(desc);
> +	int irq_no, i;
> +
> +	/* Find the interrupt */
> +	for (i = 0; i < pint->nrirqs; i++) {
> +		if (pint->irqmap[i] == irq) {

Why don't you have a reverse map for this?

> +			irq_no = irq_find_mapping(pint->domain, i);
> +			generic_handle_irq(irq_no);
> +		}
> +	}
> +}
> +
> +static void lpc18xx_gpio_pint_edge_ack(struct irq_data *d)
> +{
> +	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> +	u32 mask = d->mask;
> +
> +	irq_gc_lock(gc);
> +	irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_IST);
> +	irq_gc_unlock(gc);
> +}

How is that different from irq_gc_ack_set_bit ?

> +static void lpc18xx_gpio_pint_edge_mask(struct irq_data *d)
> +{
> +	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> +	u32 mask = d->mask;
> +
> +	irq_gc_lock(gc);
> +	irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_CIENR);
> +	irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_CIENF);
> +	irq_gc_unlock(gc);
> +}

If you use seperate irq types, then you can use the generic chip functions and
be done with it.

> +static void lpc18xx_gpio_pint_edge_unmask(struct irq_data *d)
> +{
> +	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> +	u32 type, mask = d->mask;
> +
> +	irq_gc_lock(gc);
> +	type = irqd_get_trigger_type(d);
> +	if (type & IRQ_TYPE_EDGE_RISING)
> +		irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_SIENR);
> +	if (type & IRQ_TYPE_EDGE_FALLING)
> +		irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_SIENF);
> +	irq_gc_unlock(gc);
> +}
> +
> +static void lpc18xx_gpio_pint_level_mask(struct irq_data *d)
> +{
> +	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> +	u32 mask = d->mask;
> +
> +	irq_gc_lock(gc);
> +	irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_CIENR);
> +	irq_gc_unlock(gc);
> +}
> +
> +static void lpc18xx_gpio_pint_level_unmask(struct irq_data *d)
> +{
> +	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> +	u32 mask = d->mask;
> +
> +	irq_gc_lock(gc);
> +	irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_SIENR);
> +	irq_gc_unlock(gc);
> +}

All the callbacks can go away.

> +static int lpc18xx_gpio_pint_type(struct irq_data *data, unsigned int type)
> +{
> +	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
> +	u32 mask = data->mask;
> +
> +	irq_gc_lock(gc);
> +	if (type & IRQ_TYPE_LEVEL_MASK)
> +		gc->type_cache |= mask;
> +	else
> +		gc->type_cache &= ~mask;
> +	irq_reg_writel(gc, gc->type_cache, LPC18XX_GPIO_PINT_ISEL);
> +
> +	switch (type) {
> +	case IRQ_TYPE_LEVEL_HIGH:
> +		irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_SIENF);
> +		break;
> +
> +	case IRQ_TYPE_LEVEL_LOW:
> +		irq_reg_writel(gc, mask, LPC18XX_GPIO_PINT_CIENF);
> +		break;
> +
> +	/* IRQ_TYPE_EDGE_* is set in lpc18xx_gpio_pint_edge_unmask */
> +	}
> +
> +	irqd_set_trigger_type(data, type);
> +	irq_setup_alt_chip(data, type);

So you already use an alt chip, but still implement your own callbacks?

WHY?

Thanks,

	tglx




From aleksey.makarov at linaro.org  Fri Feb 26 02:33:17 2016
From: aleksey.makarov at linaro.org (Aleksey Makarov)
Date: Fri, 26 Feb 2016 13:33:17 +0300
Subject: [PATCH v3 1/5] ACPI: change __init to __ref for
 early_acpi_os_unmap_memory()
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E883BB5D340@SHSMSX101.ccr.corp.intel.com>
References: <1455559532-8305-1-git-send-email-aleksey.makarov@linaro.org>
 <1455559532-8305-2-git-send-email-aleksey.makarov@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDBB@SHSMSX101.ccr.corp.intel.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4BDCF@SHSMSX101.ccr.corp.intel.com>
 <56C470C5.2080203@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D2DA@SHSMSX101.ccr.corp.intel.com>
 <56C63FB5.2030907@hurleysoftware.com>
 <1AE640813FDE7649BE1B193DEA596E883BB4D5A0@SHSMSX101.ccr.corp.intel.com>
 <56C6F660.9020407@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB4D949@SHSMSX101.ccr.corp.intel.com>
 <56CB21FA.1090302@linaro.org>
 <1AE640813FDE7649BE1B193DEA596E883BB5D340@SHSMSX101.ccr.corp.intel.com>
Message-ID: <56D029ED.6020406@linaro.org>



On 02/26/2016 09:39 AM, Zheng, Lv wrote:
> Hi, Aleksey
> 
> Though I promised you to have this done in 1 week:
> https://github.com/zetalog/acpica/commit/a234569
> I implemented the idea and tried the cleanup in Linux.
> But unfortunately the cleanup triggered several locking issues inside of ACPICA table API users.
> So it doesn't seem to be so easy and quick to make it upstreamed.
> And I have to continue to test and improve the cleanup.
> 
> I'm sorry for that, hope you can find substitute solutions before the cleanup is upstreamed.

That's fine, I use the approach I described in the last mail, it works.

Thank you
Aleksey Makarov

> 
> Thanks and best regards
> -Lv
> 
>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
>> Sent: Monday, February 22, 2016 10:58 PM
>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>> early_acpi_os_unmap_memory()
>>
>> Hi,
>>
>> On 02/22/2016 05:24 AM, Zheng, Lv wrote:
>>> Hi,
>>>
>>>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
>>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>>>> early_acpi_os_unmap_memory()
>>>>
>>>> Hi Lv,
>>>>
>>>> On 02/19/2016 05:58 AM, Zheng, Lv wrote:
>>>>> Hi,
>>>>>
>>>>>> From: Peter Hurley [mailto:peter at hurleysoftware.com]
>>>>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>>>>>> early_acpi_os_unmap_memory()
>>>>>>
>>>>>> On 02/17/2016 07:36 PM, Zheng, Lv wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>> From: Aleksey Makarov [mailto:aleksey.makarov at linaro.org]
>>>>>>>> Subject: Re: [PATCH v3 1/5] ACPI: change __init to __ref for
>>>>>>>> early_acpi_os_unmap_memory()
>>>>>>>>
>>>>>>>> Hi Lv,
>>>>>>>>
>>>>>>>> Thank you for review.
>>>>>>>>
>>>>>>>> On 02/17/2016 05:51 AM, Zheng, Lv wrote:
>>>>>>>>
>>>>>>>> [..]
>>>>>>>>
>>>>>>>>>>> early_acpi_os_unmap_memory() is marked as __init because it calls
>>>>>>>>>>> __acpi_unmap_table(), but only when acpi_gbl_permanent_mmap
>> is
>>>> not
>>>>>>>> set.
>>>>>>>>>>>
>>>>>>>>>>> acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>>>>>>>> so it is safe to call early_acpi_os_unmap_memory() from anywhere
>>>>>>>>>>>
>>>>>>>>>>> We need this function to be non-__init because we need access to
>>>>>>>>>>> some tables at unpredictable time--it may be before or after
>>>>>>>>>>> acpi_gbl_permanent_mmap is set.  For example, SPCR (Serial Port
>>>>>> Console
>>>>>>>>>>> Redirection) table is needed each time a new console is registered.
>>>>>>>>>>> It can be quite early (console_initcall) or when a module is inserted.
>>>>>>>>>>> When this table accessed before acpi_gbl_permanent_mmap is set,
>>>>>>>>>>> the pointer should be unmapped.  This is exactly what this function
>>>>>>>>>>> does.
>>>>>>>>>> [Lv Zheng]
>>>>>>>>>> Why don't you use another API instead of
>>>>>> early_acpi_os_unmap_memory()
>>>>>>>> in
>>>>>>>>>> case you want to unmap things in any cases.
>>>>>>>>>> acpi_os_unmap_memory() should be the one to match this purpose.
>>>>>>>>>> It checks acpi_gbl_ppermanent_mmap in acpi_os_unmap_iomem().
>>>>>>>>
>>>>>>>> As far as I understand, there exist two steps in ACPI initialization:
>>>>>>>>
>>>>>>>> 1. Before acpi_gbl_permanent_mmap is set, tables received with
>>>>>>>> acpi_get_table_with_size()
>>>>>>>>    are mapped by early_memremap().  If a subsystem gets such a pointer
>> it
>>>>>>>> should be unmapped.
>>>>>>>>
>>>>>>>> 2  After acpi_gbl_permanent_mmap is set this pointer should not be
>>>>>> unmapped
>>>>>>>> at all.
>>>>>>>>
>>>>>>> [Lv Zheng]
>>>>>>> This statement is wrong, this should be:
>>>>>>> As long as there is a __reference__ to the mapped table, the pointer
>> should
>>>>>> not be unmapped.
>>>>>>> In fact, we have a series to introduce acpi_put_table() to achieve this.
>>>>>>> So your argument is wrong from very first point.
>>>>>>>
>>>>>>>> That exactly what early_acpi_os_unmap_memory() does--it checks
>>>>>>>> acpi_gbl_permanent_mmap.
>>>>>>>> If I had used acpi_os_unmap_memory() after
>> acpi_gbl_permanent_mmap
>>>>>> had
>>>>>>>> been set,
>>>>>>>> it would have tried to free that pointer with an oops (actually, I
>> checked
>>>> that
>>>>>>>> and got that oops).
>>>>>>>>
>>>>>>>> So using acpi_os_unmap_memory() is not an option here, but
>>>>>>>> early_acpi_os_unmap_memory()
>>>>>>>> match perfectly.
>>>>>>> [Lv Zheng]
>>>>>>> I don't think so.
>>>>>>> For definition block tables, we know for sure there will always be
>>>> references,
>>>>>> until "Unload" opcode is invoked by the AML interpreter.
>>>>>>> But for the data tables, OSPMs should use them in this way:
>>>>>>> 1. map the table
>>>>>>> 2. parse the table and convert it to OS specific structures
>>>>>>> 3. unmap the table
>>>>>>> This helps to shrink virtual memory address space usages.
>>>>>>>
>>>>>>> So from this point of view, all data tables should be unmapped right
>> after
>>>>>> being parsed.
>>>>>>> Why do you need the map to be persistent in the kernel address space?
>>>>>>> You can always map a small table, but what if the table size is very big?
>>>>>>>
>>>>>>>>
>>>>>>>>>> And in fact early_acpi_os_unmap_memory() should be removed.
>>>>>>>>
>>>>>>>> I don't think so -- I have explained why.  It does different thing.
>>>>>>>> Probably it (and/or other functions in that api) should be renamed.
>>>>>>>>
>>>>>>> [Lv Zheng]
>>>>>>> Just let me ask one more question.
>>>>>>> eary_acpi_os_unmap_memory() is not used inside of ACPICA.
>>>>>>> How ACPICA can work with just acpi_os_unmap_memory()?
>>>>>>> You can check drivers/acpi/tbxxx.c.
>>>>>>> Especially: acpi_tb_release_temp_table() and the code invoking it.
>>>>>>>
>>>>>>>>> [Lv Zheng]
>>>>>>>>> One more thing is:
>>>>>>>>> If you can't switch your driver to use acpi_os_unmap_memory()
>> instead
>>>> of
>>>>>>>> early_acpi_os_unmap_memory(),
>>>>>>>>> then it implies that your driver does have a defect.
>>>>>>>>
>>>>>>>> I still don't understand what defect, sorry.
>>>>>>> [Lv Zheng]
>>>>>>> If you can't ensure this sequence for using the data tables:
>>>>>>> 1. map the table
>>>>>>> 2. parse the table and convert it to OS specific structure
>>>>>>> 3. unmap the table
>>>>>>> It implies there is a bug in the driver or a bug in the ACPI subsystem core.
>>>>>>
>>>>>> Exactly.
>>>>> [Lv Zheng]
>>>>> So it looks to me:
>>>>> Changing __init to __ref here is entirely not acceptable.
>>>>> This API should stay being invoked during early stage.
>>>>> Otherwise, it may leave us untrackable code that maps tables during early
>>>> stage and leaks maps to the late stage.
>>>>> If Linux contains such kind of code, I'm afraid, it will become impossible to
>>>> introduce acpi_put_table() to clean up the mappings.
>>>>> Because when acpi_put_table() is called during the late stage to free a map
>>>> acquired during the early stage, it then obviously will end up with panic.
>>>>
>>>> Can you please sugggest a common method to access ACPI tables that
>>>> works both before *and* after acpi_gbl_permanent_mmap is set and __init
>>>> code
>>>> is removed?
>>> [Lv Zheng]
>>> Do not change __init for now.
>>>
>>> Currently you should:
>>> 1. before acpi_gbl_permanent_mmap is set:
>>> acpi_get_table_with_size()
>>> parse the table
>>> early_acpi_os_unmap_memory()
>>> Do your driver early stuff here
>>>
>>> 2. after acpi_gbl_permanent_mmap is set:
>>> acpi_get_table()
>>> Parse the table
>>> Do your driver late stuff here
>>> <- note there is no API now being an inverse of acpi_get_table().
>>
>> That's fine.  These are two different methods to access the table.
>> I need one that works in both cases.  Of course, they could be combined,
>> but I am not sure if I can access the acpi_gbl_permanent_mmap variable--it
>> seems to be an implementation detail of ACPI code.
>>
>> Instead I am going to use the 1st method once and cache the result like this:
>>
>>
>> static int __init parse(void)
>> {
>> 	static bool parsed;
>>
>> 	if (!parsed) {
>> 		acpi_get_table_with_size()
>> 		/* parse the table and cache the result */
>> 		early_acpi_os_unmap_memory()
>> 		parse = true;
>> 	}
>> }
>>
>> arch_initcal(parse());
>>
>> int __ref the_handler_where_I_need_the_parse_results(void)
>> {
>> 	parse();
>>
>> 	/* use the data */
>> }
>>
>> I hope you are OK with it.
>>
>>> Besides, I'm about to insert error messages between 1 and 2.
>>> If an early map is not release, error message will be prompted to the
>> developers.
>>
>> AFAICS, there is such an error message and I saw it.
>> Refer to check_early_ioremap_leak() at mm/early_ioremap.c
>>
>>> And if you don't follow the above rules, it mean you are trying to lay a mine,
>> waiting for me to step on it.
>>> That's why this change is entirely not acceptable.
>>
>> Ok, I see.
>>
>>> I'm about to send out the cleanup series in 1 week, and will Cc you.
>>> You can rebase your code on top of the cleanup series.
>>
>> Thank you
>> Aleksey Makarov
>>
>>>
>>> Thanks and best regards
>>> -Lv
>>>
>>>>
>>>>> Thanks and best regards
>>>>> -Lv
>>>>>
>>>>>> The central problem here is the way Aleksey is trying to hookup a console.
>>>>>>
>>>>>> What should be happening in this series is:
>>>>>> 1. early map SPCR
>>>>>> 2. parse the SPCR table
>>>>>> 3. call add_preferred_console() to add the SPCR console to the console
>>>> table
>>>>>> 4. unmap SPCR
>>>>>>
>>>>>> This trivial and unobtrusive method would already have a 8250 console
>>>>>> running via SPCR. I've already pointed this out in previous reviews.
>>>>>>
>>>>>> Further, the above method *will be required anyway* for the DBG2 table
>> to
>>>>>> start an earlycon, which I've already pointed out in previous reviews.
>>>>>>
>>>>>> Then to enable amba-pl011 console via ACPI, add a console match()
>> method
>>>>>> similar to the 8250 console match() method, univ8250_console_match().
>>>>>>
>>>>>> FWIW, PCI earlycon + console support was already submitted once before
>>>> but
>>>>>> never picked up by GregKH. I think I'll just grab that and re-submit so
>>>>>> you would know what to emit for console options in the
>>>>>> add_preferred_console().
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Peter Hurley
>>>>>>
>>>>>>
>>>>>>>>> There is an early bootup requirement in Linux.
>>>>>>>>> Maps acquired during the early stage should be freed by the driver
>> during
>>>>>> the
>>>>>>>> early stage.
>>>>>>>>> And the driver should re-acquire the memory map after booting.
>>>>>>>>
>>>>>>>> Exactly.  That's why I use early_acpi_os_unmap_memory().  The point is
>>>> that
>>>>>>>> that code can be
>>>>>>>> called *before* acpi_gbl_permanent_mmap is set (at early initialization
>>>> of
>>>>>> for
>>>>>>>> example 8250 console)
>>>>>>>> or *after* acpi_gbl_permanent_mmap is set (at insertion of a module
>>>> that
>>>>>>>> registers a console),
>>>>>>>> We just can not tell if the received table pointer should or sould not be
>>>> freed
>>>>>>>> with early_memunmap()
>>>>>>>> (actually __acpi_unmap_table() or whatever) without checking
>>>>>>>> acpi_gbl_permanent_mmap,
>>>>>>>> but that's all too low level.
>>>>>>> [Lv Zheng]
>>>>>>> The driver should make sure that:
>>>>>>> Map/unmap is paired during early stage.
>>>>>>> For late stage, it should be another pair of map/unmap.
>>>>>>>
>>>>>>>>
>>>>>>>> Another option, as you describe, is to get this pointer early, don't free it
>>>>>>> [Lv Zheng]
>>>>>>> I mean you should free it early.
>>>>>>>
>>>>>>>> untill acpi_gbl_permanent_mmap is set, then free it (with
>>>>>>>> early_acpi_os_unmap_memory(), that's
>>>>>>>> ok because acpi_gbl_permanent_mmap is set in an init code), then get
>>>> the
>>>>>>>> persistent
>>>>>>>> pointer to the table.  The problem with it is that we can not just watch
>>>>>>>> acpi_gbl_permanent_mmap
>>>>>>>> to catch this exact moment.  And also accessing
>>>> acpi_gbl_permanent_mmap
>>>>>> is
>>>>>>>> not good as it probably is
>>>>>>>> an implementation detail (i. e. too lowlevel) of the ACPI code.
>>>>>>>> Or I probably miss what you are suggesting.
>>>>>>>>
>>>>>>> [Lv Zheng]
>>>>>>> I mean, you should:
>>>>>>> During early stage:
>>>>>>> acpi_os_map_memory()
>>>>>>> Parse the table.
>>>>>>> acpi_os_unmap_memory().
>>>>>>>
>>>>>>>>> This is because, during early bootup stage, there are only limited slots
>>>>>>>> available for drivers to map memory.
>>>>>>>>> So by changing __init to __ref here, you probably will hide many such
>>>>>> defects.
>>>>>>>>
>>>>>>>> What defects?  This funcions checks acpi_gbl_permanent_mmap.
>>>>>>>> BTW, exactly the same thing is done in the beginning of
>>>>>>>> acpi_os_unmap_memory() and than's ok,
>>>>>>>> that function is __ref.
>>>>>>>>
>>>>>>>>> And solving issues in this way doesn't seem to be an improvement.
>>>>>>>>
>>>>>>>> Could you please tell me where I am wrong?  I still don't understand
>> your
>>>>>> point.
>>>>>>> [Lv Zheng]
>>>>>>> But anyway, the defect should be in ACPI subsystem core.
>>>>>>> The cause should be the API itself - acpi_get_table().
>>>>>>>
>>>>>>> So I agree you can use early_acpi_os_unmap_memory() during the
>> period
>>>> the
>>>>>> root causes are not cleaned up.
>>>>>>> But the bottom line is: the driver need to ensure that
>>>>>> early_acpi_os_unmap_memory() is always invoked.
>>>>>>> As long as you can ensure this, I don't have objections for deploying
>>>>>> early_acpi_os_unmap_memory()  for now.
>>>>>>>
>>>>>>> Thanks and best regards
>>>>>>> -Lv
>>>>>>>
>>>>>>>>
>>>>>>>> Thank you
>>>>>>>> Aleksey Makarov
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks and best regards
>>>>>>>>> -Lv
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks and best regards
>>>>>>>>>> -Lv
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Aleksey Makarov <aleksey.makarov at linaro.org>
>>>>>>>>>>> ---
>>>>>>>>>>>  drivers/acpi/osl.c | 6 +++++-
>>>>>>>>>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
>>>>>>>>>>> index 67da6fb..8a552cd 100644
>>>>>>>>>>> --- a/drivers/acpi/osl.c
>>>>>>>>>>> +++ b/drivers/acpi/osl.c
>>>>>>>>>>> @@ -497,7 +497,11 @@ void __ref acpi_os_unmap_memory(void
>>>> *virt,
>>>>>>>>>>> acpi_size size)
>>>>>>>>>>>  }
>>>>>>>>>>>  EXPORT_SYMBOL_GPL(acpi_os_unmap_memory);
>>>>>>>>>>>
>>>>>>>>>>> -void __init early_acpi_os_unmap_memory(void __iomem *virt,
>>>>>> acpi_size
>>>>>>>>>> size)
>>>>>>>>>>> +/*
>>>>>>>>>>> + * acpi_gbl_permanent_mmap is set in __init acpi_early_init()
>>>>>>>>>>> + * so it is safe to call early_acpi_os_unmap_memory() from
>>>> anywhere
>>>>>>>>>>> + */
>>>>>>>>>>> +void __ref early_acpi_os_unmap_memory(void __iomem *virt,
>>>>>> acpi_size
>>>>>>>>>> size)
>>>>>>>>>>>  {
>>>>>>>>>>>  	if (!acpi_gbl_permanent_mmap)
>>>>>>>>>>>  		__acpi_unmap_table(virt, size);
>>>>>>>>>>> --
>>>>>>>>>>> 2.7.1
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
>> in
>>>>>>>>>>> the body of a message to majordomo at vger.kernel.org
>>>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-
>>>> info.html
>>>>>>>>>> --
>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>>>>>>>>>> the body of a message to majordomo at vger.kernel.org
>>>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-
>> info.html
>>>>>


From kirill at shutemov.name  Fri Feb 26 02:34:31 2016
From: kirill at shutemov.name (Kirill A. Shutemov)
Date: Fri, 26 Feb 2016 13:34:31 +0300
Subject: [PATCH -next] mm: fix build for arm64 hugetlbpage
In-Reply-To: <1456414385-13775-1-git-send-email-sudeep.holla@arm.com>
References: <1456414385-13775-1-git-send-email-sudeep.holla@arm.com>
Message-ID: <20160226103431.GB22450@node.shutemov.name>

On Thu, Feb 25, 2016 at 03:33:05PM +0000, Sudeep Holla wrote:
> Commit ("mm: cleanup *pte_alloc* interfaces") redefined pte_alloc_map()
> using pte_alloc() and fixed all the callsites. However arm64 callsite
> seem to have got missed. This patch fixes the same and thereby fixing
> the following build error.
> 
> arch/arm64/mm/hugetlbpage.c: In function 'huge_pte_alloc':
> arch/arm64/mm/hugetlbpage.c:127:42: error: macro "pte_alloc_map" passed 4 arguments, but takes just 3
>    pte = pte_alloc_map(mm, NULL, pmd, addr);
>                                           ^
> arch/arm64/mm/hugetlbpage.c:127:9: error: 'pte_alloc_map' undeclared (first use in this function)
>    pte = pte_alloc_map(mm, NULL, pmd, addr);
>          ^
> Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>

Sorry for that.

Acked-by: Kirill A. Shutemov <kirill.shutemov at linux.intel.com>

> ---
>  arch/arm64/mm/hugetlbpage.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Hi,
> 
> Since it's from -mm tree, I have not put the commit id causing the
> breakage. Also since I don't have the original patch in my inbox, I am
> posting this separately. It would be good to squash this into original
> commit.
> 
> Regards,
> Sudeep
> 
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 82d607c3614e..bb6b4c7bfab3 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -124,7 +124,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
>  		 * will be no pte_unmap() to correspond with this
>  		 * pte_alloc_map().
>  		 */
> -		pte = pte_alloc_map(mm, NULL, pmd, addr);
> +		pte = pte_alloc_map(mm, pmd, addr);
>  	} else if (sz == PMD_SIZE) {
>  		if (IS_ENABLED(CONFIG_ARCH_WANT_HUGE_PMD_SHARE) &&
>  		    pud_none(*pud))
> -- 
> 1.9.1
> 

-- 
 Kirill A. Shutemov


From tomi.valkeinen at ti.com  Fri Feb 26 02:34:34 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Feb 2016 12:34:34 +0200
Subject: [PATCH 3/7 v2] video: ARM CLCD: support DT signal inversion flags
In-Reply-To: <1456221704-5792-4-git-send-email-linus.walleij@linaro.org>
References: <1456221704-5792-1-git-send-email-linus.walleij@linaro.org>
 <1456221704-5792-4-git-send-email-linus.walleij@linaro.org>
Message-ID: <56D02A3A.6010701@ti.com>



On 23/02/16 12:01, Linus Walleij wrote:
> The device tree bindings from display-timing.txt allows us to
> specify if data enable, hsync, vsync or the pixed clock should be
> inverted on the way to the display. The driver does not currently
> handle this so add support for those flags as it is needed for
> the Versatile Sanyo LCD display.
> 
> Note that the previous behaviour was to invert the pixel clock
> for all displays, so unless the pixel clock polarity is
> explicitly defined in the device tree (i.e. the timings node
> has the "pixelclk-active" property) we fall back to inverting
> the pixel clock. This needs some extra compatibility code.
> 
> Since the timing flags have to be set up inside the struct
> clcd_panel, we need to refactor the code a bit to pass around
> the panel rather than just the mode.
> 
> Cc: Pawel Moll <pawel.moll at arm.com>
> Cc: Rob Herring <robh at kernel.org>
> Cc: Russell King <linux at arm.linux.org.uk>
> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> ---
> ChangeLog v1->v2:
> - No changes. Just reposting.
> ---
>  drivers/video/fbdev/amba-clcd.c | 41 ++++++++++++++++++++++++++++++++++-------
>  1 file changed, 34 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
> index c5d1e9ca81ab..8903a42c4122 100644
> --- a/drivers/video/fbdev/amba-clcd.c
> +++ b/drivers/video/fbdev/amba-clcd.c
> @@ -567,10 +567,11 @@ static int clcdfb_register(struct clcd_fb *fb)
>  
>  #ifdef CONFIG_OF
>  static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
> -		struct fb_videomode *mode)
> +		struct clcd_panel *clcd_panel)
>  {
>  	int err;
>  	struct display_timing timing;
> +	struct device_node *timnp;
>  	struct videomode video;
>  
>  	err = of_get_display_timing(node, "panel-timing", &timing);
> @@ -579,10 +580,34 @@ static int clcdfb_of_get_dpi_panel_mode(struct device_node *node,
>  
>  	videomode_from_timing(&timing, &video);
>  
> -	err = fb_videomode_from_videomode(&video, mode);
> +	err = fb_videomode_from_videomode(&video, &clcd_panel->mode);
>  	if (err)
>  		return err;
>  
> +	/* Set up some inversion flags */
> +	timnp = of_get_child_by_name(node, "panel-timing");
> +	if (timnp && of_property_read_bool(timnp, "pixelclk-active")) {

Hmm, why are you poking in the videomode DT properties directly? If the
pixelclk-active was not defined in the DT, you should see it in the
videomode struct as neither DISPLAY_FLAGS_PIXDATA_POSEDGE nor
DISPLAY_FLAGS_PIXDATA_NEGEDGE being set (I think, I didn't go through
the code in detail).

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160226/de0044c5/attachment.sig>

From andy.shevchenko at gmail.com  Fri Feb 26 02:43:15 2016
From: andy.shevchenko at gmail.com (Andy Shevchenko)
Date: Fri, 26 Feb 2016 12:43:15 +0200
Subject: [PATCH v2] mfd: Provide MACRO to declare commonly defined MFD
 cell attributes
In-Reply-To: <20160210153846.GB26950@x1>
References: <1455028027-1527-1-git-send-email-lee.jones@linaro.org>
 <20160210153846.GB26950@x1>
Message-ID: <CAHp75VfWdx6VfXLNt7iWSnUsD944cYv+6sa7uYD0KviJYa49oA@mail.gmail.com>

On Wed, Feb 10, 2016 at 5:38 PM, Lee Jones <lee.jones at linaro.org> wrote:
> mfd: Provide MACRO to declare commonly defined MFD cell attributes
>

Commit message?


> +#define MFD_ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))

What's wrong with ARRAY_SIZE() ?

> +
> +#define MFD_CELL_ALL(_name, _res, _pdata, _id, _compat, _match)                \

It misses pset. Which makes below set of macros is not sufficient.

> +       {                                                               \
> +               .name = (_name),                                        \
> +               .resources = (_res),                                    \
> +               .num_resources = MFD_ARRAY_SIZE((_res)),                \
> +               .platform_data = (_pdata),                              \
> +               .pdata_size = MFD_ARRAY_SIZE((_pdata)),                 \
> +               .of_compatible = (_compat),                             \
> +               .acpi_match = (_match),                                 \
> +               .id = _id,                                              \
> +       }
> +
> +#define OF_MFD_CELL(_name, _res, _pdata, _id, _compat)                 \
> +               MFD_CELL_ALL(_name, _res, _pdata, _id, _compat, NULL)   \
> +
> +#define ACPI_MFD_CELL(_name, _res, _pdata, _id, _match)                        \
> +               MFD_CELL_ALL(_name, _res, _pdata, _id, NULL, _match)    \
> +
> +#define MFD_CELL_BASIC(_name, _res, _pdata, _id)                       \
> +               MFD_CELL_ALL(_name, _res, _pdata, _id, NULL, NULL)      \
> +
> +#define MFD_CELL_NAME(_name)                                           \
> +               MFD_CELL_ALL(_name, NULL, NULL, 0, NULL, NULL)          \

-- 
With Best Regards,
Andy Shevchenko


From tomi.valkeinen at ti.com  Fri Feb 26 02:47:04 2016
From: tomi.valkeinen at ti.com (Tomi Valkeinen)
Date: Fri, 26 Feb 2016 12:47:04 +0200
Subject: [PATCH 11/11] ARM: versatile: move CLCD configuration to device
 tree
In-Reply-To: <CACRpkdYowXJinONTd2qREfCtEDCon+HSQtdd6t1QQA91f6PJdw@mail.gmail.com>
References: <1454594660-7532-1-git-send-email-linus.walleij@linaro.org>
 <3695074.sKSIyOjpjD@wuerfel>
 <CACRpkdZjfjOCFUucF1U5yVZBxSwa41GKEMv-HHQE=ymF2NZ21g@mail.gmail.com>
 <6859810.tb1t0IEONi@wuerfel> <56CC57FC.20707@ti.com>
 <CACRpkdYNaNtQQJ-tsBe5ksa4-z380ZQj-zN8ZnK0ED2kNPUwvg@mail.gmail.com>
 <56CC60C4.6040908@ti.com>
 <CACRpkdZd8TLdsi7_cOrqzcqWKJrfdp4Vz2sx5ozpwJXOj0fa+Q@mail.gmail.com>
 <56CF2FB1.106@ti.com>
 <CACRpkdYowXJinONTd2qREfCtEDCon+HSQtdd6t1QQA91f6PJdw@mail.gmail.com>
Message-ID: <56D02D28.9080109@ti.com>



On 25/02/16 21:30, Linus Walleij wrote:
> On Thu, Feb 25, 2016 at 5:45 PM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
>> On 25/02/16 16:04, Linus Walleij wrote:
> 
>>> *All* the others
>>> will be very happy with *ONE* display defined as panel in the
>>> device tree, and off they go. Usually VGA. And that will look
>>
>> You keep mentioning VGA. So is there are VGA output? Or do you just mean
>> MIPI DPI panels, which happen to take the same video timings as VGA?
> 
> Russell beat me to it, yes there is an external VGA encoder.
> It needs some bits set up through the "misc registers" system
> controller as indicated. From the CLCD hardware point of view
> it's no different than any other panel. So the DTS fragment looks
> like so:
> 
>                         panel {
>                                 compatible = "panel-dpi";
> 
>                                 port {
>                                         clcd_panel: endpoint {
>                                                 remote-endpoint = <&clcd_pads>;
>                                         };
>                                 };
> 
>                                 /* Standard 640x480 VGA timings */
>                                 panel-timing {
>                                         clock-frequency = <25175000>;
>                                         hactive = <640>;
>                                         hback-porch = <48>;
>                                         hfront-porch = <16>;
>                                         hsync-len = <96>;
>                                         vactive = <480>;
>                                         vback-porch = <33>;
>                                         vfront-porch = <10>;
>                                         vsync-len = <2>;
>                                 };
>                         };
> 
> 
> This is reported as the default display type if no LCD panel
> is connected.
> 
> If a LCD panel is also connected, it take precedence.

Ok. Well... It's all wrong, but I don't know how much time we want to
spend on fixing that.

Although one thing to consider is that if there is ever going to be a
DRM driver for CLCD, it would be good to have the device tree parts
correctly representing the hardware, so that the DRM driver could be
implemented in a cleaner, more generic way.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160226/2d0bbf63/attachment.sig>

From kvalo at codeaurora.org  Fri Feb 26 02:48:22 2016
From: kvalo at codeaurora.org (Kalle Valo)
Date: Fri, 26 Feb 2016 10:48:22 +0000 (UTC)
Subject: [RESEND] ssb: host_soc depends on sprom
In-Reply-To: <1456433869-3919332-1-git-send-email-arnd@arndb.de>
Message-ID: <20160226104822.921416089E@smtp.codeaurora.org>


> Drivers that use the SSB sprom functionality typically 'select SSB_SPROM'
> from Kconfig, but CONFIG_SSB_HOST_SOC misses this, which results in
> a build failure unless at least one of the other drivers that selects
> it is enabled:
> 
> drivers/built-in.o: In function `ssb_host_soc_get_invariants':
> (.text+0x459494): undefined reference to `ssb_fill_sprom_with_fallback'
> 
> This adds the same select statement that is used elsewhere.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>
> Fixes: 541c9a84cd85 ("ssb: pick SoC invariants code from MIPS BCM47xx arch")

Thanks, applied to wireless-drivers.git.

Kalle Valo


From alexandre.torgue at gmail.com  Fri Feb 26 02:51:48 2016
From: alexandre.torgue at gmail.com (Alexandre TORGUE)
Date: Fri, 26 Feb 2016 11:51:48 +0100
Subject: [PATCH v3 0/4] Add Ethernet support on STM32F429
Message-ID: <1456483912-32090-1-git-send-email-alexandre.torgue@gmail.com>

STM32F429 Chip embeds a Synopsys 3.50a MAC IP.
This series:
 -enhance current stmmac driver to control it (code already
available) and adds basic glue for STM32F429 chip.
 -Enable basic Net config in kernel.

Note that DT patches are not present because STM32 pinctrl code is not
yet avalaible.

Changes since v2:
 -Fix alphabetic order in Kconfig and Makefile.
 -Improve code according to Joachim review.
 -Binding: remove useless entry.

Changes since v1:
 -Fix Kbuild issue in Kconfig.
 -Remove init/exit callbacks. Suspend/Resume and remove driver is no more
driven in stmmac_pltfr but directly in dwmac-stm32 glue driver.
 -Take into account Joachim review.

Regards.

Alexandre.

Alexandre TORGUE (4):
  net: ethernet: dwmac: add Ethernet glue logic for stm32 chip
  Documentation: Bindings: Add STM32 DWMAC glue
  net: ethernet: stmmac: add support of Synopsys 3.50a MAC IP
  ARM: STM32: Enable Ethernet in stm32_defconfig

 .../devicetree/bindings/net/stm32-dwmac.txt        |  40 +++++
 arch/arm/configs/stm32_defconfig                   |   9 +
 drivers/net/ethernet/stmicro/stmmac/Kconfig        |  12 ++
 drivers/net/ethernet/stmicro/stmmac/Makefile       |   1 +
 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c  | 193 +++++++++++++++++++++
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |   1 +
 6 files changed, 256 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/stm32-dwmac.txt
 create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c

-- 
1.9.1



From alexandre.torgue at gmail.com  Fri Feb 26 02:51:50 2016
From: alexandre.torgue at gmail.com (Alexandre TORGUE)
Date: Fri, 26 Feb 2016 11:51:50 +0100
Subject: [PATCH v3 2/4] Documentation: Bindings: Add STM32 DWMAC glue
In-Reply-To: <1456483912-32090-1-git-send-email-alexandre.torgue@gmail.com>
References: <1456483912-32090-1-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <1456483912-32090-3-git-send-email-alexandre.torgue@gmail.com>

Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>

diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
new file mode 100644
index 0000000..67fceda
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
@@ -0,0 +1,40 @@
+STMicroelectronics STM32 / MCU DWMAC glue layer controller
+
+This file documents platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+The device node has following properties.
+
+Required properties:
+- compatible:  Should be "st,stm32-dwmac" to select glue, and
+	       "snps,dwmac-3.50a" to select IP vesrion.
+- clocks: Should contain the GMAC main clock, and tx clock
+- compatible:  Should be "st,stm32-dwmac" to select glue and
+	       "snps,dwmac-3.50a" to select IP version.
+- clocks: Should contain the MAC main clock
+- clock-names: Should contain the clock names "stmmaceth".
+- st,syscon : Should be phandle/offset pair. The phandle to the syscon node which
+	      encompases the glue register, and the offset of the control register.
+
+Optional properties:
+- clocks: Could contain:
+	- the tx clock,
+	- the rx clock
+- clock-names: Could contain the clock names "tx-clk", "rx-clk"
+
+Example:
+
+		ethernet0: dwmac at 40028000 {
+			compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
+			status = "disabled";
+			reg = <0x40028000 0x8000>;
+			reg-names = "stmmaceth";
+			interrupts = <0 61 0>, <0 62 0>;
+			interrupt-names = "macirq", "eth_wake_irq";
+			clock-names = "stmmaceth", "tx-clk", "rx-clk";
+			clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
+			st,syscon = <&syscfg 0x4>;
+			snps,pbl = <8>;
+			snps,mixed-burst;
+			dma-ranges;
+		};
-- 
1.9.1



From alexandre.torgue at gmail.com  Fri Feb 26 02:51:52 2016
From: alexandre.torgue at gmail.com (Alexandre TORGUE)
Date: Fri, 26 Feb 2016 11:51:52 +0100
Subject: [PATCH v3 4/4] ARM: STM32: Enable Ethernet in stm32_defconfig
In-Reply-To: <1456483912-32090-1-git-send-email-alexandre.torgue@gmail.com>
References: <1456483912-32090-1-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <1456483912-32090-5-git-send-email-alexandre.torgue@gmail.com>

Enable basic Ethernet support (IPV4) for stm32 defconfig.

Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index ec52505..8b8abe0 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -33,11 +33,20 @@ CONFIG_XIP_PHYS_ADDR=0x08008000
 CONFIG_BINFMT_FLAT=y
 CONFIG_BINFMT_SHARED_FLAT=y
 # CONFIG_COREDUMP is not set
+CONFIG_NET=y
+CONFIG_INET=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_IPV6 is not set
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_FW_LOADER is not set
 # CONFIG_BLK_DEV is not set
 CONFIG_EEPROM_93CX6=y
+CONFIG_NETDEVICES=y
+CONFIG_STMMAC_ETH=y
+# CONFIG_WLAN is not set
 # CONFIG_INPUT is not set
 # CONFIG_SERIO is not set
 # CONFIG_VT is not set
-- 
1.9.1



From alexandre.torgue at gmail.com  Fri Feb 26 02:51:49 2016
From: alexandre.torgue at gmail.com (Alexandre TORGUE)
Date: Fri, 26 Feb 2016 11:51:49 +0100
Subject: [PATCH v3 1/4] net: ethernet: dwmac: add Ethernet glue logic for
 stm32 chip
In-Reply-To: <1456483912-32090-1-git-send-email-alexandre.torgue@gmail.com>
References: <1456483912-32090-1-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <1456483912-32090-2-git-send-email-alexandre.torgue@gmail.com>

stm324xx family chips support Synopsys MAC 3.510 IP.
This patch adds settings for logical glue logic:
-clocks
-mode selection MII or RMII.

Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>

diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index cec147d..235d679 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -104,6 +104,18 @@ config DWMAC_STI
 	  device driver. This driver is used on for the STi series
 	  SOCs GMAC ethernet controller.
 
+config DWMAC_STM32
+	tristate "STM32 DWMAC support"
+	default ARCH_STM32
+	depends on OF && HAS_IOMEM
+	select MFD_SYSCON
+	---help---
+	  Support for ethernet controller on STM32 SOCs.
+
+	  This selects STM32 SoC glue layer support for the stmmac
+	  device driver. This driver is used on for the STM32 series
+	  SOCs GMAC ethernet controller.
+
 config DWMAC_SUNXI
 	tristate "Allwinner GMAC support"
 	default ARCH_SUNXI
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index b390161..5f7ff0a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_DWMAC_MESON)	+= dwmac-meson.o
 obj-$(CONFIG_DWMAC_ROCKCHIP)	+= dwmac-rk.o
 obj-$(CONFIG_DWMAC_SOCFPGA)	+= dwmac-socfpga.o
 obj-$(CONFIG_DWMAC_STI)		+= dwmac-sti.o
+obj-$(CONFIG_DWMAC_STM32)	+= dwmac-stm32.o
 obj-$(CONFIG_DWMAC_SUNXI)	+= dwmac-sunxi.o
 obj-$(CONFIG_DWMAC_GENERIC)	+= dwmac-generic.o
 stmmac-platform-objs:= stmmac_platform.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
new file mode 100644
index 0000000..036ac90
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
@@ -0,0 +1,193 @@
+/*
+ * dwmac-stm32.c - DWMAC Specific Glue layer for STM32 MCU
+ *
+ * Copyright (C) Alexandre Torgue 2015
+ * Author:  Alexandre Torgue <alexandre.torgue at gmail.com>
+ * License terms:  GNU General Public License (GPL), version 2
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_net.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+#include <linux/stmmac.h>
+
+#include "stmmac_platform.h"
+
+#define MII_PHY_SEL_MASK	BIT(23)
+
+struct stm32_dwmac {
+	struct clk *clk_tx;
+	struct clk *clk_rx;
+	u32 mode_reg;		/* MAC glue-logic mode register */
+	struct regmap *regmap;
+	u32 speed;
+};
+
+static int stm32_dwmac_init(struct plat_stmmacenet_data *plat_dat)
+{
+	struct stm32_dwmac *dwmac = plat_dat->bsp_priv;
+	u32 reg = dwmac->mode_reg;
+	u32 val;
+	int ret;
+
+	val = (plat_dat->interface == PHY_INTERFACE_MODE_MII) ? 0 : 1;
+	ret = regmap_update_bits(dwmac->regmap, reg, MII_PHY_SEL_MASK, val);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare_enable(dwmac->clk_tx);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare_enable(dwmac->clk_rx);
+	if (ret)
+		clk_disable_unprepare(dwmac->clk_tx);
+
+	return ret;
+}
+
+static void stm32_dwmac_clk_disable(struct stm32_dwmac *dwmac)
+{
+	clk_disable_unprepare(dwmac->clk_tx);
+	clk_disable_unprepare(dwmac->clk_rx);
+}
+
+static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
+				  struct device *dev)
+{
+	struct device_node *np = dev->of_node;
+	int err;
+
+	/*  Get TX/RX clocks */
+	dwmac->clk_tx = devm_clk_get(dev, "tx-clk");
+	if (IS_ERR(dwmac->clk_tx)) {
+		dev_warn(dev, "No tx clock provided...\n");
+		dwmac->clk_tx = NULL;
+	}
+	dwmac->clk_rx = devm_clk_get(dev, "rx-clk");
+	if (IS_ERR(dwmac->clk_rx)) {
+		dev_warn(dev, "No rx clock provided...\n");
+		dwmac->clk_rx = NULL;
+	}
+
+	/* Get mode register */
+	dwmac->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscon");
+	if (IS_ERR(dwmac->regmap))
+		return PTR_ERR(dwmac->regmap);
+
+	err = of_property_read_u32_index(np, "st,syscon", 1, &dwmac->mode_reg);
+	if (err)
+		dev_err(dev, "Can't get sysconfig mode offset (%d)\n", err);
+
+	return err;
+}
+
+static int stm32_dwmac_probe(struct platform_device *pdev)
+{
+	struct plat_stmmacenet_data *plat_dat;
+	struct stmmac_resources stmmac_res;
+	struct stm32_dwmac *dwmac;
+	int ret;
+
+	ret = stmmac_get_platform_resources(pdev, &stmmac_res);
+	if (ret)
+		return ret;
+
+	plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
+	if (IS_ERR(plat_dat))
+		return PTR_ERR(plat_dat);
+
+	dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
+	if (!dwmac)
+		return -ENOMEM;
+
+	ret = stm32_dwmac_parse_data(dwmac, &pdev->dev);
+	if (ret) {
+		dev_err(&pdev->dev, "Unable to parse OF data\n");
+		return ret;
+	}
+
+	plat_dat->bsp_priv = dwmac;
+
+	ret = stm32_dwmac_init(plat_dat);
+	if (ret)
+		return ret;
+
+	ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
+	if (ret)
+		stm32_dwmac_clk_disable(dwmac);
+
+	return ret;
+}
+
+static int stm32_dwmac_remove(struct platform_device *pdev)
+{
+	struct net_device *ndev = platform_get_drvdata(pdev);
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	int ret = stmmac_dvr_remove(ndev);
+
+	stm32_dwmac_clk_disable(priv->plat->bsp_priv);
+
+	return ret;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int stm32_dwmac_suspend(struct device *dev)
+{
+	struct net_device *ndev = dev_get_drvdata(dev);
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	int ret;
+
+	ret = stmmac_suspend(ndev);
+	stm32_dwmac_clk_disable(priv->plat->bsp_priv);
+
+	return ret;
+}
+
+static int stm32_dwmac_resume(struct device *dev)
+{
+	struct net_device *ndev = dev_get_drvdata(dev);
+	struct stmmac_priv *priv = netdev_priv(ndev);
+	int ret;
+
+	ret = stm32_dwmac_init(priv->plat);
+	if (ret)
+		return ret;
+
+	ret = stmmac_resume(ndev);
+
+	return ret;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+SIMPLE_DEV_PM_OPS(stm32_dwmac_pm_ops, stm32_dwmac_suspend, stm32_dwmac_resume);
+
+static const struct of_device_id stm32_dwmac_match[] = {
+	{ .compatible = "st,stm32-dwmac"},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, stm32_dwmac_match);
+
+static struct platform_driver stm32_dwmac_driver = {
+	.probe  = stm32_dwmac_probe,
+	.remove = stm32_dwmac_remove,
+	.driver = {
+		.name           = "stm32-dwmac",
+		.pm		= &stm32_dwmac_pm_ops,
+		.of_match_table = stm32_dwmac_match,
+	},
+};
+module_platform_driver(stm32_dwmac_driver);
+
+MODULE_AUTHOR("Alexandre Torgue <alexandre.torgue at gmail.com>");
+MODULE_DESCRIPTION("STMicroelectronics MCU DWMAC Specific Glue layer");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1



From alexandre.torgue at gmail.com  Fri Feb 26 02:51:51 2016
From: alexandre.torgue at gmail.com (Alexandre TORGUE)
Date: Fri, 26 Feb 2016 11:51:51 +0100
Subject: [PATCH v3 3/4] net: ethernet: stmmac: add support of Synopsys 3.50a
 MAC IP
In-Reply-To: <1456483912-32090-1-git-send-email-alexandre.torgue@gmail.com>
References: <1456483912-32090-1-git-send-email-alexandre.torgue@gmail.com>
Message-ID: <1456483912-32090-4-git-send-email-alexandre.torgue@gmail.com>

Adds support of Synopsys 3.50a MAC IP in stmmac driver.

Signed-off-by: Alexandre TORGUE <alexandre.torgue at gmail.com>

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 6a52fa1..6cca626 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -178,6 +178,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
 	 * once needed on other platforms.
 	 */
 	if (of_device_is_compatible(np, "st,spear600-gmac") ||
+		of_device_is_compatible(np, "snps,dwmac-3.50a") ||
 		of_device_is_compatible(np, "snps,dwmac-3.70a") ||
 		of_device_is_compatible(np, "snps,dwmac")) {
 		/* Note that the max-frame-size parameter as defined in the
-- 
1.9.1



From k.kozlowski at samsung.com  Fri Feb 26 02:55:50 2016
From: k.kozlowski at samsung.com (Krzysztof Kozlowski)
Date: Fri, 26 Feb 2016 19:55:50 +0900
Subject: [RESPIN 0/6] Add support for Exynos SROM Controller driver.
In-Reply-To: <00c701d17070$6de3d1b0$49ab7510$@samsung.com>
References: <1456389222-12738-1-git-send-email-pankaj.dubey@samsung.com>
 <56D0040C.8020204@samsung.com>
 <00c701d17070$6de3d1b0$49ab7510$@samsung.com>
Message-ID: <CAJKOXPdZ-5WYYvqiNTMUnP6WsxAK4gqsi4o5SMJF+_SJa1qbag@mail.gmail.com>

2016-02-26 17:33 GMT+09:00 Pavel Fedin <p.fedin at samsung.com>:
>  Hello!
>
>> I applied (with fixes mentioned in my comments) everything and pushed
>> here so everyone could play with it:
>> https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=for-v4.6/drivers-soc-
>> exynos-srom-2
>
>  I see the last patch (adding Ethernet chip to DT) is missing. Is it intentional, so that it goes later?
>

It was already merged into arm-soc:
https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/commit/?h=next/dt&id=a090435727f6ccf0c5e77793ca48681122e5b950

All DT changes (SROM, PMU) were accepted by arm-soc maintainers.

Best regards,
Krzysztof


From laurentiu.tudor at nxp.com  Fri Feb 26 03:01:57 2016
From: laurentiu.tudor at nxp.com (Laurentiu Tudor)
Date: Fri, 26 Feb 2016 11:01:57 +0000
Subject: [PATCH][RFC] arm64: kaslr: add pseudo-RNG in kernel
Message-ID: <56D030A4.5050205@nxp.com>

In case the bootloader doesn't provide randomness
(through device tree or by uefi protocol) generate
a pseudo-random seed based on the timer counter.
People might find this "week rng" approach convenient
as it gets rid of the bootloader dependency.

The patch tries to mimic the x86's rdtsc
based implementation authored by Kees Cook.

Signed-off-by: Laurentiu Tudor <laurentiu.tudor at nxp.com>
Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Cc: Kees Cook <keescook at chromium.org>
---
based on http://git.linaro.org/people/ard.biesheuvel/linux-arm.git,
branch arm64-kaslr-v6

 arch/arm64/kernel/kaslr.c | 44 ++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 42 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index 5829839..41e9cbd 100644
--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@ -13,6 +13,7 @@
 #include <linux/sched.h>
 #include <linux/types.h>
 
+#include <asm/arch_timer.h>
 #include <asm/fixmap.h>
 #include <asm/kernel-pgtable.h>
 #include <asm/memory.h>
@@ -20,9 +21,30 @@
 #include <asm/pgtable.h>
 #include <asm/sections.h>
 
+#include <generated/compile.h>
+#include <generated/utsrelease.h>
+
+/* Simplified build-specific string for starting entropy. */
+static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
+		LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
+
 u64 __read_mostly module_alloc_base;
 u16 __initdata memstart_offset_seed;
 
+static u64 rotate_xor(u64 hash, const void *area, size_t size)
+{
+	size_t i;
+	unsigned long *ptr = (unsigned long *)area;
+
+	for (i = 0; i < size / sizeof(hash); i++) {
+		/* Rotate by odd number of bits and XOR. */
+		hash = (hash << ((sizeof(hash) * 8) - 7)) | (hash >> 7);
+		hash ^= ptr[i];
+	}
+
+	return hash;
+}
+
 static __init u64 get_kaslr_seed(void *fdt)
 {
 	int node, len;
@@ -101,8 +123,26 @@ u64 __init kaslr_early_init(u64 dt_phys)
 	 * Retrieve (and wipe) the seed from the FDT
 	 */
 	seed = get_kaslr_seed(fdt);
-	if (!seed)
-		return 0;
+	if (!seed) {
+		u64 raw;
+		const u64 mix_const = 0x5d6008cbf3848dd3UL;
+
+		/*
+		 * Attempt to create a simple but unpredictable starting
+		 * entropy.
+		 */
+		seed = rotate_xor(seed, build_str, sizeof(build_str));
+		seed = rotate_xor(seed, fdt, size);
+
+		raw = arch_counter_get_cntvct();
+		seed ^= raw;
+
+		/* Circular multiply for better bit diffusion */
+		asm("mul %1, %2, %3; umulh %0, %2, %3"
+		    : "=&r" (raw), "=&r" (seed)
+		    : "r" (seed), "r" (mix_const));
+		seed += raw;
+	}
 
 	/*
 	 * Check if 'nokaslr' appears on the command line, and
-- 
1.8.3.1

From joro at 8bytes.org  Fri Feb 26 03:06:33 2016
From: joro at 8bytes.org (Joerg Roedel)
Date: Fri, 26 Feb 2016 12:06:33 +0100
Subject: [PATCH v10 0/5] MT8173 IOMMU SUPPORT
In-Reply-To: <1456476955.3383.21.camel@pengutronix.de>
References: <1456161651-6136-1-git-send-email-yong.wu@mediatek.com>
 <20160225155007.GA19092@8bytes.org>
 <1456476955.3383.21.camel@pengutronix.de>
Message-ID: <20160226110633.GE22747@8bytes.org>

Hi Philipp,

On Fri, Feb 26, 2016 at 09:55:55AM +0100, Philipp Zabel wrote:
> Do you have a stable branch that I could base the mediatek-drm patches
> on and that I may include in a pull request to be merged via drm-next?

You can base it on the arm/mediatek branch of the iommu tree. I'll push
it out in the next minutes.


	Joerg



From dhowells at redhat.com  Fri Feb 26 03:20:28 2016
From: dhowells at redhat.com (David Howells)
Date: Fri, 26 Feb 2016 11:20:28 +0000
Subject: [PATCH] modsign: hide openssl output in silent builds
In-Reply-To: <1456417901-2192433-1-git-send-email-arnd@arndb.de>
References: <1456417901-2192433-1-git-send-email-arnd@arndb.de>
Message-ID: <7539.1456485628@warthog.procyon.org.uk>

Arnd Bergmann <arnd at arndb.de> wrote:

> When a user calls 'make -s', we can assume they don't want to
> see any output except for warnings and errors, but instead
> they see this for a warning free build:
> 
>  ###
>  ### Now generating an X.509 key pair to be used for signing modules.
>  ###
>  ### If this takes a long time, you might wish to run rngd in the
>  ### background to keep the supply of entropy topped up.  It
>  ### needs to be run as root, and uses a hardware random
>  ### number generator if one is available.
>  ###
>  Generating a 4096 bit RSA private key
>  .................................................................................................................................................................................................................................++
>  ..............................................................................................................................++
>  writing new private key to 'certs/signing_key.pem'
>  -----
>  ###
>  ### Key pair generated.
>  ###
> 
> The output can confuse simple build testing scripts that just check
> for an empty build log.
> 
> This patch silences all the output:
>  - "echo" is changed to "@$(kecho)", which is dropped when "-s" gets
>    passed
>  - the openssl command itself is only printed with V=1, using the
>    $(Q) macro
>  - The output of openssl gets redircted to /dev/null on "-s" builds.
> 
> Signed-off-by: Arnd Bergmann <arnd at arndb.de>

Applied.

David


From jassisinghbrar at gmail.com  Fri Feb 26 03:22:43 2016
From: jassisinghbrar at gmail.com (Jassi Brar)
Date: Fri, 26 Feb 2016 16:52:43 +0530
Subject: [GIT PULL 2/2] arm64: X-Gene platforms DTS changes queued for
 v4.6 - part2
In-Reply-To: <CADaLNDnqRkOqam1Xt+Oc+7BXnQKr2EQqSL-1AGsn5fKOWEDnvw@mail.gmail.com>
References: <CADaLNDkF8_DVYWPFtGU8tYsbbxDWZF9tozW=Zs3EuV4BqO6OuA@mail.gmail.com>
 <CABb+yY2A6bLoNqak5Y8YVLgv=mL1Cx6axnD1trMhKx646NNWFw@mail.gmail.com>
 <CADaLNDnqRkOqam1Xt+Oc+7BXnQKr2EQqSL-1AGsn5fKOWEDnvw@mail.gmail.com>
Message-ID: <CABb+yY3cFCYZ3da4zp2UdCTMY6ubjfgMBEkMJ9pe+5OSE=p5+g@mail.gmail.com>

On Fri, Feb 26, 2016 at 2:20 PM, Duc Dang <dhdang at apm.com> wrote:
> On Thu, Feb 25, 2016 at 8:28 PM, Jassi Brar <jassisinghbrar at gmail.com> wrote:
>> On Fri, Feb 26, 2016 at 8:21 AM, Duc Dang <dhdang at apm.com> wrote:
>>> Hi Arnd, Olof,
>>>
>>> This is the second part of DT changes on X-Gene platforms for v4.6,
>>> which enables mailbox driver for X-Gene v2 platforms and also enable
>>> SLIMpro Mailbox I2C driver (a client of the mailbox driver) for both
>>> X-Gene v1 and v2 platforms.
>>>
>>> This series depends on the 3rd patch
>>> (http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/apm?id=be9c09bcca039d6df9ec736989cdafc68c93fed4)
>>> of the series "mailbox: Add APM X-Gene platform mailbox driver"
>>> (https://lkml.org/lkml/2016/2/12/749), which was already in linux-next
>>> since Feb-15.
>>>
>>> Hi Jassi,
>>>
>>> Are you going to get the 3rd patch (dts patch) of series "mailbox: Add
>>> APM X-Gene platform mailbox driver" to your tree? Otherwise, I will
>>> need to create another pull request for Arnd and Olof.
>>>
>> Please create the pull request, I don't think mailbox tree is the
>> right path for the patch.
>
> Thanks for your confirmation, Jassi.
>
I overlooked I had already applied it. Not sure if its better to revert it now.


From linux at arm.linux.org.uk  Fri Feb 26 03:25:25 2016
From: linux at arm.linux.org.uk (Russell King - ARM Linux)
Date: Fri, 26 Feb 2016 11:25:25 +0000
Subject: [PATCH] dmaengine: omap-dma: Do not call omap_dma_callback()
 from tx_status()
In-Reply-To: <56D0279F.2050703@ti.com>
References: <1456388939-15722-1-git-send-email-peter.ujfalusi@ti.com>
 <20160226010658.GN5783@n2100.arm.linux.org.uk>
 <56D0279F.2050703@ti.com>
Message-ID: <20160226112524.GP5783@n2100.arm.linux.org.uk>

On Fri, Feb 26, 2016 at 12:23:27PM +0200, Peter Ujfalusi wrote:
> On 2016-02-26 03:06, Russell King - ARM Linux wrote:
> > On Thu, Feb 25, 2016 at 10:28:59AM +0200, Peter Ujfalusi wrote:
> >> When based on the CCR_ENABLE bit the channel is stopped we should not call
> >> omap_dma_callback(), only change the return value to DMA_COMPLETE. Client
> >> drivers will do the right thing to clean up the channel after the transfer
> >> has been completed.
> >> Check the CCR_ENABLE only if the channel is not paused since pause in sDMA
> >> means that the channel is stopped.
> >> This will fix one hard to reproduce race condition when the channel is
> >> terminated during transfer (affecting cyclic operation).
> >>
> >> Fixes: 1a7cf7b26f25 ("dmaengine: omap-dma: Handle cases when the channel is polled for completion")
> >>
> >> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> >> ---
> >>  drivers/dma/omap-dma.c | 16 ++++++++++------
> >>  1 file changed, 10 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> >> index f6bef0d93998..a6b189fdbbe6 100644
> >> --- a/drivers/dma/omap-dma.c
> >> +++ b/drivers/dma/omap-dma.c
> >> @@ -671,18 +671,22 @@ static enum dma_status omap_dma_tx_status(struct dma_chan *chan,
> >>  	struct omap_chan *c = to_omap_dma_chan(chan);
> >>  	struct virt_dma_desc *vd;
> >>  	enum dma_status ret;
> >> -	uint32_t ccr;
> >>  	unsigned long flags;
> >>  
> >> -	ccr = omap_dma_chan_read(c, CCR);
> >> -	/* The channel is no longer active, handle the completion right away */
> >> -	if (!(ccr & CCR_ENABLE))
> >> -		omap_dma_callback(c->dma_ch, 0, c);
> >> -
> >>  	ret = dma_cookie_status(chan, cookie, txstate);
> >>  	if (ret == DMA_COMPLETE || !txstate)
> >>  		return ret;
> >>  
> >> +	if (!c->paused) {
> >> +		uint32_t ccr = omap_dma_chan_read(c, CCR);
> >> +		/*
> >> +		 * The channel is no longer active, set the return value
> >> +		 * accordingly
> >> +		 */
> >> +		if (!(ccr & CCR_ENABLE))
> >> +			ret = DMA_COMPLETE;
> >> +	}
> >> +
> > 
> > This looks very much like a hack, and surely opens a race condition
> > up: what happens when a request submitted and pending but not yet
> > started?  If the channel is idle, requesting status will report
> > that the request has completed.
> > 
> > It's also wrong for another reason.  If txstate is NULL...
> 
> True, I have fixed these up.
> 
> > Your original commit adding the original hack that you're now removing
> > above says that this is to support polled operation: I'm not aware of
> > DMA engine supporting such a mode.  DMA_PREP_INTERRUPT is a mechanism
> > where requests can be queued without an interrupt to allow batching.
> 
> Also it is used to suppress DMA interrupts during audio playback for example.
> In this case we will run w/o interrupts and the position is polled.
> 
> > See the raid5/async_tx code, which queues a set of operations without
> > DMA_PREP_INTERRUPT, with the final operation with DMA_PREP_INTERRUPT
> > set.
> 
> We only allow the interrupts to be disabled in cyclic or memcpy mode. With
> slave_sg we have interrupts as it is needed to move to the next SG.
> 
> > As the driver is reliant on interrupts to move to the next transfer,
> > the patch which causes DMA_PREP_INTERRUPT to influence whether
> > interrupts are sent is actually buggy, and will prevent several
> > queued DMA operations to fail.
> 
> Yes, the omap-dma only allows the interrupts to be actually disabled when it
> is save to do so. slave_sg can not work w/o interrupts so there we don't
> disable them.

I get the impression that you haven't taken in what I've said, because
each fragment of your reply is just repeating what the previous fragment
said.

Let me state that I don't believe you need any hacks here, and this patch
is not necessary: the final operation in a set of chained memcpy()s should
have DMA_PREP_INTERRUPT set.

For the periodic stuff for audio, it's irrelevant anyway: periodic
transfers never complete - you can start them, and they continue running
until terminated.  There's no completion.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


From zhaoshenglong at huawei.com  Fri Feb 26 03:29:19 2016
From: zhaoshenglong at huawei.com (Shannon Zhao)
Date: Fri, 26 Feb 2016 19:29:19 +0800
Subject: [PATCH v15 15/20] KVM: ARM64: Add PMU overflow interrupt routing
In-Reply-To: <1456324417-18992-1-git-send-email-shannon.zhao@linaro.org>
References: <1456324417-18992-1-git-send-email-shannon.zhao@linaro.org>
Message-ID: <1456486159-14564-1-git-send-email-zhaoshenglong@huawei.com>

From: Shannon Zhao <shannon.zhao at linaro.org>

When calling perf_event_create_kernel_counter to create perf_event,
assign a overflow handler. Then when the perf event overflows, set the
corresponding bit of guest PMOVSSET register. If this counter is enabled
and its interrupt is enabled as well, kick the vcpu to sync the
interrupt.

On VM entry, if there is counter overflowed and interrupt level is
changed, inject the interrupt with corresponding level. On VM exit, sync
the interrupt level as well if it has been changed.

Signed-off-by: Shannon Zhao <shannon.zhao at linaro.org>
Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
Reviewed-by: Andrew Jones <drjones at redhat.com>
Reviewed-by: Christoffer Dall <christoffer.dall at linaro.org>
---
 arch/arm/kvm/arm.c    |  8 ++++--
 include/kvm/arm_pmu.h |  5 ++++
 virt/kvm/arm/pmu.c    | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index dda1959..a7e50d7 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -28,6 +28,7 @@
 #include <linux/sched.h>
 #include <linux/kvm.h>
 #include <trace/events/kvm.h>
+#include <kvm/arm_pmu.h>
 
 #define CREATE_TRACE_POINTS
 #include "trace.h"
@@ -577,6 +578,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
 		 * non-preemptible context.
 		 */
 		preempt_disable();
+		kvm_pmu_flush_hwstate(vcpu);
 		kvm_timer_flush_hwstate(vcpu);
 		kvm_vgic_flush_hwstate(vcpu);
 
@@ -593,6 +595,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
 		if (ret <= 0 || need_new_vmid_gen(vcpu->kvm) ||
 			vcpu->arch.power_off || vcpu->arch.pause) {
 			local_irq_enable();
+			kvm_pmu_sync_hwstate(vcpu);
 			kvm_timer_sync